Adding storage nodes
-
Dear FOG gods,
I recently upgraded my FOG VM to the current stable version and I’m planning to add two additional VMs configured as FOG Storage Nodes. A while back, I read somewhere (Wiki?) that having multiple storage nodes is recommended because it takes some of the performance load off the primary FOG server. In my current configuration I have the main FOG server NOT set as an active storage node and have a physical PC loaded up with 2 TB of storage set as an active storage node. I want to retire that PC, spin up two VMs and use them for image storage/distribution.
My question: If I do what I describe above, will the images stored on the existing (physical) storage node seed/replicate over to the new storage nodes automatically or will I need to manually copy the images over?
Apologies if my question has already been answered in a previous forum post or wiki entry, please include the url if that’s the case, no additional explanation required.
Thanks for all the great work you guys do to keep FOG the best-free imaging solution out there!
-LOF
-
@LOF Just wondering why you are using storage nodes at all? Can you elaborate more on why you chose to do so? Some scenarios call for using storage nodes but it’s not in every situation and it can make things just more complicated than it needs to be.
Probably best to discuss this before we talk about the other questions.
-
@LOF said in Adding storage nodes:
Lets try to break this down a bit.
that having multiple storage nodes is recommended because it takes some of the performance load off the primary FOG server.
Additional storage nodes only really help in 2 different scenarios.
- Your devices are located remote to your master fog server. In this situation you would place a storage node near the target systems. This allows local deployment of images instead of deploying images across a WAN link.
- You need to deploy many unicast images simultaneously at the same site as your main fog server. You will find that a 1 GbE link will saturate it with 3 simultaneous unicasts. You would add additional storage nodes to allow you to deploy images fast without saturating any single 1 GbE network link.
In my current configuration I have the main FOG server NOT set as an active storage node and have a physical PC loaded up with 2 TB of storage set as an active storage node.
This is a similar setup if when you use a NAS as an image store. It can work this way. The thing you have to remember is that only the master node in a storage group can capture images. All storage nodes are deploy only.
My question: If I do what I describe above, will the images stored on the existing (physical) storage node seed/replicate over to the new storage nodes automatically or will I need to manually copy the images over?
Replication will only happen from a server that has FOG loaded as a master (normal) node. Storage nodes don’t have the replication service loaded and running (because they are always the recipient of images).
-
Hi George, thanks for great explanation! So, even thought the primary FOG server isn’t set to deploy stored images, it still stores images that have been captured and will facilitate capturing any new images? i.e., I should see copies of all captured images in /images on the primary FOG server? Technically, the objective here is to create a new storage node as a VM so that we can safely retire the storage node running on physical PC hardware. If more than one node isn’t needed, I won’t create more than one.
Thanks!
-LOF
-
@LOF said in Adding storage nodes:
So, even thought the primary FOG server isn’t set to deploy stored images, it still stores images that have been captured and will facilitate capturing any new images?
Just for clarity, only the master node in a storage group can capture images. That master node doesn’t have to be a real fog server, it could be a nas like device. The only thing is if you want replication to happen the master node needs to be a real fog server with the files stored locally on that FOG server/master node.
As for the need of more storage nodes, you really need to ask your self how many simultaneous unicast images will you deploy at any one time vs what is your network bandwidth on your fog server. If you only deploy 5 images a week and they are all unicast at different times of the day I would not add any storage nodes. If you had to unicast send images to a class room of computers to reimage them between classes then I would either go multicasting the image or add more storage nodes to get more worker servers on the imaging job.
-
Thanks George, we’ve been using FOG to do mass deployments for new computers. We typically deploy to up around 20 new laptops simultaneously multiple times a day. Meaning that in a typical day we could image 60 or more laptops. This has been working fine using a single storage node and deploy tasks from groups. I tried using the multicast deployment method a while back but couldn’t get it to work properly and thought it was because of problems with old switches we were using. We’ve since upgraded our infrastructure, including switches so I may try it again to see how it goes. I like using the group-task deployment method because of the auto-shutdown option that we can select. It makes the process a lot easier because we can schedule the task, PXE-boot a couple racks of laptops, walk away after they all start receiving the image and come back to see them all powered off. I haven’t looked yet after the upgrade but it seems like I remember auto-shutdown not being an option with multicast deployments.
Anyway, based on my description above, would you recommend two storage nodes or just stay with one?
-
@LOF said in Adding storage nodes:
20 new laptops simultaneously multiple times a day
When you say this, do you actually stack up 20 laptops and then start imaging them all in a short period of time (looking at the workflow here).
Also what is your image push time?
On the surface if you “needed” to image 20 machines within a short period of time (such as a room full of computers between classes), I would say you need at least a fog server and a storage node or use multicast mode (I understand about infrastructure and it could cause issues).
-
Correct, we rack 20 - 22 laptops at a time and use a group deployment task to push images to them.
Image push time varies. I haven’t actually timed it but I’ll give a rough estimate and say it’s around 30 - 40 minutes for the first 6 - 10 laptops that we PXE-boot first but then the push time decreases quite a bit as soon as laptops receive the image and shut down. It seems like the last few remaining laptops that receive the image go really fast.
Based on the information you’ve provided, I’ll probably go with this plan: (1) Spin up a new storage node on our dedicated ESXi host, register it on the primary FOG VM and test to ensure deployments are working. (2) Power off the existing-physical storage node and remove it from the storage tab in the FOG console on the primary FOG VM. (3) Test deployments for a while and spin up/register an additional storage node or try multicast if we need faster deployments.
Let me know if you see any problems with that plan or have any other recommendations.
-
@LOF said in Adding storage nodes:
Image push time varies. I haven’t actually timed it but I’ll give a rough estimate and say it’s around 30 - 40 minutes for the first 6 - 10 laptops that we PXE-boot first but then the push time decreases quite a bit as soon as laptops receive the image and shut down. It seems like the last few remaining laptops that receive the image go really fast.
This sounds in line with my statement about flooding the 1GbE network link. You can mitigate this a bit by adding more network adapters to your FOG server, then creating a LAG group between your FOG server and the network infrastructure. If you need to go faster, also putting your /images directory on one or more flash drives (more meaning a raid configuration) will also help with speed.
For your esxi server, how many network links does it have into your networking infrastructure? 2? or is it 10GbE? The concern is of you are spinning up 2 vms on the same VM Host server your bottleneck will be where the esxi server interfaces with your network.
-
@george1421 said in Adding storage nodes:
For your esxi server, how many network links does it have into your networking infrastructure? 2? or is it 10GbE?
The ESXi host is on a segmented network and has 4 physical adapter connections but I don’t think all of them are being used. I’m pretty sure the number is two because I’ve been talking to our network team about the possibility of going to 10GbE which they say will be a possibility down the road but not right now. I’ll definitely test deployments thoroughly before pulling the plug on the current/physical node.
Thanks for the tips about adding a LAG group and/or changing the location of /images, good to know about those options.
