Bandwidth information showing incorrect node transmitting/receiving
-
Ok, so I’ve got two fog servers setup, both running Ubuntu 14.04 and did install from the fog installer script. Both are on version 8533 as of this writing.
I enabled the location plugin, added the storage members, made sure they were in the same storage group. I created the location, assigned the storage group and the node to them, and have it pulling inits and such from them.
However, when I actually imaged a client, it was pulling from the master node still.
Image Replicator log is as follows:
[07-12-16 5:50:23 pm] * Started sync for Image Win10HS
lftp -e ‘set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; mirror -c -R --ignore-time -vvv --exclude ‘dev/’ --exclude ‘ssl/’ --exclude ‘CA/’ --delete-first /images/Win10HS /images/Win10HS; exit’ -u fog,[Protected] 192.168.0.30
[07-12-16 5:50:23 pm] | CMD:
[07-12-16 5:50:23 pm] * Starting Sync Actions
[07-12-16 5:50:23 pm] | Files match
[07-12-16 5:50:23 pm] | Remote File size: 15619523591
[07-12-16 5:50:23 pm] | Local File size: 15619523591
[07-12-16 5:50:23 pm] | Remote File: /images/Win10HS/d1p2.img
[07-12-16 5:50:23 pm] | Local File: /images/Win10HS/d1p2.img
[07-12-16 5:50:23 pm] | Files match
[07-12-16 5:50:23 pm] | Remote File size: 10076807
[07-12-16 5:50:23 pm] | Local File size: 10076807
[07-12-16 5:50:23 pm] | Remote File: /images/Win10HS/d1p1.img
[07-12-16 5:50:23 pm] | Local File: /images/Win10HS/d1p1.img
[07-12-16 5:50:23 pm] | Files match
[07-12-16 5:50:23 pm] | Remote File size: 190
[07-12-16 5:50:23 pm] | Local File size: 190
[07-12-16 5:50:23 pm] | Remote File: /images/Win10HS/d1.partitions
[07-12-16 5:50:23 pm] | Local File: /images/Win10HS/d1.partitions
[07-12-16 5:50:23 pm] | Files match -
I don’t understand what the image replicator logs is going to show us.
Was the original image on the node you defined to the host?
The location plugin, as far as I can tell, is working properly at least within my limited test environment. I guess we need more information.
Image replication is completely separate from what the point of Location Plugin is.
-
@Bob-Henderson Did you set the host you were imaging to a location?
-
@Tom-Elliott My bad, I thought it would have something to do with it and wanted to pre-empt the request.
The original image was on the default master node, yes. It then replicated over to the secondary node in Audubon, which is where I’d like to pull from.
@Wayne-Workman
Yes, I have location defined and assigned. Pics of my current setup:
Host Page:
Location Page:
Storage Page:
-
@Bob-Henderson When you tried to image the host that was associated to Audubon, was the image already on the node defined as 192.168.0.30?
-
I also verified that during the boot process, it pulled it’s Init and such from 192.168.0.30, as I wanted to. It was only the imaging itself that it pulled from the default.
-
@Tom-Elliott How can I check? I just ssh’d into the box, and found the file under /images as expected, looking right. But is there somewhere else I should look?
sorry for needing my hand held on this one, it’s the first time I’ve worked with storage nodes and the location plugin.
-
@Bob-Henderson I guess a remote session wouldn’t hurt if at all possible, but about to help another person fairly soon. hit me up on chat and i can try to help you further.
There could be a problem with location setting and getting the storage node. If there is, it could be a couple of things. The storage group must, at the least, be defined with the location. If the tasking is an upload it will always choose to upload to the master node, regardless of location a host is defined to.
-
@Tom-Elliott I was unaware there was a chat option. Is it an IRC node or the like? I thought the forum was pretty much it these days.
-
to test a theory - try separating the storage nodes into separate storage groups. so create a storage group and move audubon storage node into it and then check location storage group /node both point to audubon storage node and new storage group.
and try to image at audubon again, remember to create new task and not use an existing task.
-
@Bob-Henderson How do you know the wrong node is being used?
I ask because I recently discovered a bug in the Bandwidth Graph, which displays bandwidth for the wrong node, when in reality another node is being used. Just as you, I thought it was the location plugin not working, but it was the graph reporting wrong. Read the thread here:
https://forums.fogproject.org/topic/8076/bandwidth-chart-and-location-plugin -
@Wayne-Workman That is exactly how I am saying it’s the wrong node, the bandwidth graph. I have some imaging to do today yet at that site, so I’ll start imaging and run iftop on the storage node, see where it’s actually coming from.
good to know!
-
I think this is incorrect phrasing and much prefer @dolf’s phrasing.
If I read the title it says Location plugin isn’t working properly, however when you read the posts it says Location is working properly, but bandwidth graph is not correct. Bandwidth graph is little to do with any real actions.
That said I hope this can be resolved now as I’m now sorting based on the keys as that’s how the data is passed and then expected to be returned.
-
@Tom-Elliott Before @Wayne-Workman confirmed the bandwidth graph had a bug not showing the correct source, it appeared to me that the location plugin was not functioning, as even though it was assigned to location B, it kept saying the traffic was coming from Location A. I apologize if this is confusing, but I’m using the data the application is providing me to judge what could be the cause. When the data is incorrect, incorrect assumptions based on the cause are only to be expected.
@Wayne-Workman same issue here. It’s pulling from the right location, bandwidth graph doesn’t reflect this.
-
@Bob-Henderson If you update, we think the bandwidth graph is fixed.
And, it’s fine - I was lost in outer space for months when I started messing with fog. I think I still am sometimes.