Ok then, that’s two. All that are interested please join this forums group:
https://forums.fogproject.org/groups/fog-hangouts

Being a member of that group means you’ll get email notifications about upcoming FOG Hangouts. I’m going to work on getting hangout 5 together.

@Joe-Schmitt I’ll do that Monday. 🙂

Added. There’s no indicator, sorry just to much like work for now. But I have tested it and it does work.

Moved to FOG Problems.

Just tested WOL on current trunk and all is working perfectly fine.

Last night Joe and I found a potential issue with the client in regards to the fog client having “bad” data and we patched it. With any luck, bad cycle data should no longer happen and this should be automatically fixed if it was a problem due to the bad cycle data.

@Tom-Elliott Thanks Tom, I’ll try to update again.

@Tom-Elliott We only have one group now, so yes.

@Tom-Elliott I guess. The graph appears to be exactly correct at the moment.

@Tom-Elliott said in Many storage nodes and bandwidth graph:

is remove the interface it’s reading from. That should leave a bit more room fo

I’m not asking for a change. This was more humorous than anything. 🙂

This issue should be fixed now. It was because I was parsing through direct elements (Ensuring integer’s were indeed integers, strings were indeed strings, etc…) But 0 is parsed out as a null/empty/false entry which on update wouldn’t show up. Since changing them back to strings all appears to be working properly.

Thanks for reporting.

This was cleared up by a hard refresh.

I updated last week and tried the import again, it’s working.

Tom figured out the problem was due to mis-matching storage node versions and main server version of fog. the main server is behind a little from the recent node installations. Tom was able to create a patch that solved the issue without me having to update the main server, it is working good.

@Tom-Elliott Ok I’ll look into that.

nfsiostat will be the tool I use to demonstrate how latencies can degrade network saturation. I’ll be highlighting the RTT (round trip time) with different numbers of unicast tasks running simultaneously. I’ll also highlight total overall NFS throughput. I predict that once HDD seek times are maxed and the HDD can no longer keep up with the number of simultaneous reads, that network performance will drop below 1Gbps, and latencies will skyrocket.

The man page:
http://man7.org/linux/man-pages/man8/nfsiostat.8.html

@ddavis I am sure you’ve gone through the tutorial on FTP issues, have you? https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@Tom-Elliott So far so good, given I also remade the image with a new definition to try to escape the problem too.

Please confirm if this is good to go with 0.11.3 please? Yes it’s basically impossible to expect this to work with 0.10.6 (and probably prior issues). I’ve renamed the heading to “FOG Client - not fully uninstalling” as making it rely on the specific version that will never be able to be fixed seems strange.

Since @Tom-Elliott doesn’t think it’d be a good thing to do additional polling (which I can understand), I’ve put together something which I feel is significantly lighter on the servers.

I’ve written a BASH script that will query the FOG DB for all storage nodes, and then send out a single lonesome regular-old ping to each one.

If the ping succeeds within the specified WaitTime, the node is enabled in the DB, and it’s bandwidth chart is enabled.
If the ping fails to return within the specified WaitTime, the node is disabled in the DB, and it’s bandwidth chart is disabled.

You can clone the project from here, it includes more instructions.
https://github.com/wayneworkman/MonitorFogStorageNodes

I’ll be implementing this at work on Tuesday with our 15-server FOG System, which is currently being plagued by power outages due to construction, maintenance, storms, and server moves.

Additionally, the script writes a simple html document that you can view by going to x.x.x.x/nodestatus.html
Here is sample outputs of what the html document looks like:

1_1467506022893_Fog Storage Node Status 2.png
0_1467506022892_Fog Storage Node Status 1.png

Well, it’s been explained to me that the activity reporting is per group, and was based on which node you had selected… that was really confusing. Now there’s a selector for the group on the activity pie so I think this is a non-issue now.