Best way to image multiple machines at once?
-
I had been told several months ago that we will be getting a large volume of machines in that will need to be imaged. I built a FOG server in preparation for this, unfortunately it’s been sitting idle for a long time. The most I’ve done with it is backed up a few machines, and imaged just one at a time.
What is the difference between going through the host registration process, and simply doing “quick image” from the PXE menu? It seems that doing a full registration, going into the gui and associating an image and OS with the host, setting up the task ect, takes a lot longer than just booting and quick imaging, especially if it’s a large number of machines.
-
There are two things here.
Quick image / registration. The decision here is if you plan on managing these systems with FOG once the image is installed. FOG offers quite a few system management functions if you choose to use them. If you plan on using these functions you must register the device. Quick image just lays the image on the disk then the FOG server forgets about the system it just imaged.
How can I deploy to a large number of systems at one time. The short answer is to multicast (send a single image to multiple systems) the source image. Many educational users will image an entire lab with a single image push using multicasting. Understand that your network must be setup to support multicast traffice but that is the fastest way to do a large number of systems. With my FOG server I can push out a fat windows image (~25GB) in about 5 minutes. So if I only wanted one unicast streaming running at a time, I could launch a new image deploy every 5 minutes (to not tax my LAN infrastructure). This means I can deploy at lease 12 images per hour (understand a sysprep’d image will take about 12 minutes (beyond the 5 min image push) to become ready to move to the work site. But fog can’t control windows OOBE speed).
-
That makes sense. We won’t be using any of the management features.
Unfortunately multicast is not an option on the network. I will have to use unicast. This should still be much faster than our old method of doing clonezilla + external hard drive on each box, one at a time. I’ve been told in the past that there’s usually a tipping point where it really starts to get slow, over the network with unicast. My understanding is that you can limit the number of hosts that can be imaged at once, and then any additional units will be queued up and start imaging once one finishes. Is this correct? What I’d probably do is set up a flat 24 port switch and set the limit and fill the switch and let it go to town.
-
If you want the computers named for you and joined to the Domain for you, you must register.
Registration is one time per computer, and saves many hours of work in the future.
I can’t imagine managing all the computers at work without all of fogs features.
To put things in perspective - with Ghost, which has no auto naming, no domain joining, no automated post imaging processes, it took a team of 2 to 3 technicians to image and post - configure 30 computers in a lab. Keep in mind they are all in one room, not spread out. And we used multicast too. 3 to 4 hours.
With all that fog offers, it now takes one technician a few minutes to start it, they then go off and do something else, and come back to a completely ready to use lab - in 8 minutes total with multicast or 45 minutes with unicast.
1 person at work recently imaged 350 computers in a day - didn’t put physical hands on a single one of them. He played YouTube on his phone and some time later - done in total. You will never be able to do what he did without registration.
Imagine a virus hits all your computers. If you didn’t register - how long is it going to take you to image everything and post-configure? For me because all my computers are registered (500 at one site, 1200 at another) it’ll take me before lunch and I won’t leave my desk.
-
@mageta52 If you are going to setup a dedicated deployment environment (all systems being deployed are connected to a dedicated deployment switch) then multicasting is an option. Where you run into muticasting issues is when you have routers and vlans involved. For a single switch just enable igmp snooping and you are all set.
If you still want to run unicast imaging, then between your FOG server and your deployment switch use (4) 1 GbE nic ports setup in a team or LAG configuration. Use either a static LAG or 802.1ad (lacp) links. This will give you 4 GbE lanes to carry your traffic. During image deployment the actual load on the FOG server is low, all of the heavy lifting is being done by the FOS engine running on the target computer. If you still have a need for speed, place your images (on the FOG server) on a SSD disk. Your bottle neck will still be the target computer. But if you make the FOG server very fast and have multiple lanes to your deployment switch you can increase the number of unicast streams quite a bit.
-
@george1421 The situation is a bit odd.
Originally I wanted an isolated network, with FOG dishing out DHCP addresses. This did not work out, no matter what, the DHCP service would not hand out an address to more than one host. There was a pretty lengthy thread on this, and eventually the consensus was to just turn it off and leverage the existing DHCP server on our network, and configure it to point to FOG for any client looking for PXE boot.
In our lab, we have some really small 4 port switches, that go back to the core switch for connectivity. What I planned to do was stack all the 1RU boxes on a lab table, introduce a 24 port unmanaged switch to connect them all, then connect that up to the core switch. They’ll all be able to get addresses off of the existing Windows server, and that will point them to FOG to PXE boot. Then I can image them from there. The problem is that if I multicast, that traffic will reach the core switch, and the other engineers have said this absolutely cannot happen. I’ve been told it will hose up the phone system and bring traffic to a crawl. We don’t have QoS set up for VoIP traffic, and that core switch is not set up for IGMP snooping.
I’m not sure what the best option here if the FOG server is truly incapable of reliably handling DHCP, otherwise the solution would be an isolated network with the unmanaged switch.
-
@mageta52 what thread told you to use your existing dhcp? I happen to be really good with Linux ISC-DHCP. I can help you with that issue, easy.
-
@mageta52 We use somewhat of a similar setup in that we have (in the build up lab) a 24 port deployment switch with a single link back to the core switch. This allows the imaged systems to get dhcp from the root dhcp server, register with AD, and pull the KMS license. We have a 4 port LAG setup to the deployment switch. From there we have a dedicated physical FOG server. Our production environment is a bit different, but this is dedicated for the build up lab. All of the traffic stays on the deployment switch except for utility functions that are needed from the core network.
As for multicasting, if you have enterprise level networking gear the multicast traffic will only be sent to the ports where there are multicast subscribers. It should not flood your network with this unicast traffic, at least that is the design intent. But I would defer to your networking engineers since they “know” your network.
-
@george1421 Alright, so here’s what I’m going to do.
I’ve got an old PFsense box that I set up to handle DHCP, and it can hand the clients off to FOG. This will happen on a separate subnet on the FOG servers second NIC. I’ll still be hooked up to the core network via the first NIC for easy access and management to the box.
This way I can have my unmanaged switch, and be open to multicasting.
Now that it is an option, it kind of goes back to my original question; if I’m going to image via multicast, my understanding is that it takes some setup, with making the group and registering hosts. I won’t be able to use quick image for this will I?
