SOLVED Storage Node Disk stats not showing up on dashboard.
- FOG Version: 1.3.4
- OS: Ubuntu Server 16.04.2
- Service Version:
I am currently running one Fog server and one storage node. The are both on the same versions of Fog and OS.
The images on the Fog server are being replicated to the Storage Node. I have set the options to have the storage node graphed in setup under storage management, but the storage node refuses to display. I does not appear in the drop down so I am unable to check its disk usage.
Grateful for advice as where to check or if this has been covered in previous post somewhere in the forum.
Just a quick update. I am not sure why it happened but I am glad it has. I decided to rerun the installer script on my Storage node this morning and low and behold, when I logged into the management interface under the “storage node disk usage” drop down appear the storage node disk stats. I can not explain it may be some can but the problem is resolved.
@george1421 It is set up as a storage node when using ./installfog script.
@scouseboy99 Is your remote storage node, setup as a storage node or a Full FOG server acting like a storage node?
Thanks for the prompt response.
Yes I have posted before and was advised to have both the Fog Server and Storage Node on the same OS and Fog version, which I have now been able to do.
I am not trying to read graphs from one another I am just trying to get the storage node disk usage displayed on the main fog server dashboard.
Thanks for the advice on fixing this but before I go editing mysql I thought I would try to clear up what I see as a small issue.
Reading another of your earlier posts, are you doing two full servers and trying to have them read “graphs” from one another?
If this is the case, if the “remote” node is not looking at the “current” node, you will see some strange things.
When the pages go out to request the remote information, they pass along the remote’s identifier. If the other node is also a “local” server, the remote would be looking at it’s own database for this information rather than the “requesting” information.
Server’s have their own database.
If you have two servers you would have one server with storage node id of 1 and the other server with a storage node id of 1.
When you create a “new” entry on one of the server’s for the remote node, the new ID would be 2.
When fog goes out to reach the remote node, it will be sending the id of 2. If the remote node’s ID is not ID 2 in it’s database, the node doesn’t exist and therefore has nothing to send.
You could “fix” this by simply editing the mysql on the remote node and edit it’s nfsGroupMember ID to match what the “requesting” server is looking for.
Typically, this is because the checks are not able to “see” the other node.
This could be many things. Things to check might include, but are not limited to:
- Firewall. Is the firewall enabling port 80 on the servers? Is there another firewall (physical or software) between the two nodes that might be preventing communications?
- High use. When replication is happening it uses a lot of resources for many reasons. This can cause a high load on the systems involved as one side is sending and the other is receiving. It takes some processing to read and write all the data, so the systems can become heavily taxed during this process. Also, with 1.3.4 but others may be affected as well, the file checking uses resources as well. (We’re trying to grab a hash of the files to compare.) This will be limited to the system where the file is located, but it does mean the “sender” AND the receiver are hashing the files to communicate. 1.3.5 working branch has taken steps to limit the resource usages and should be much better as far as the hashing IO load is concerned.
- Can the remote node actually communicate to the main server presenting the GUI? (Similar to the firewall note above, but can entail such things as database connectivity.) If the server is unreachable in mysql or html, there’s nothing the remote server can send as it can’t communicate.
Hopefully these help along the way.