Transferring frog to a new server.
-
I would like to be able to move my father’s server to a proper piece of server hardware instead of the optiplex 790 it’s running on right now. Problem I’m facing is the server requires raid to be configured. I’m really trying not to have to go through the fog configuration again because it took me like a week to get right last time. what would be a good way to hopefully this transfer my current installation on to this new box? Fog is contained on an SSD with a 1 TB hard drive set to a folder in fstab. Plan on creating an ext4 disk in the raid copying all of my images to it and pointing fstab there for that folder. made an external clone of the fog drive and tried to boot it on the server without going into the RAID controller and it would not let me the required I initialize it which of course wipes to drive. Am I just kind of stuck with having to do a full rebuild? Thanks.
-
@cammykool said in Transferring frog to a new server.:
made an external clone of the fog drive
What did you use to take the image/clone? From what you are saying I read between the lines that you made a disk to disk copy from the FOG server disk to one of the drives you want to put into the new hardware server (with RAID)? I’d rather take a image backup, save that to an external USB drive and then deploy that image backup to your new server. Of course it depends on the tool used, that is why I asked.
-
What I would recommend is you install your linux distribution on your new hardware. Make sure you manually provision the disk partitions and mount points to match what you have today to the old servers fstab structure. Once the new server’s OS is installed, fixed IP address is assigned, and all other FOG prerequisites are done, then do the following.
- Download the current FOG program using the git method (hopefully your old fog server and new fog server are the same versions of FOG)
- Run this command to make the FOG disk structure
mkdir -p /opt/fog - On your old fog server there is a hidden file called
/opt/fog/.fogsettingsCopy that file from your old fog server to the new fog server in the same location. You can use the linux command scp to copy the file from the old server to the new server. - Run this command on the new fog server to look at your network settings
ip addr showcollect the network interface name and the IP address of the new fog server. - On the new FOG server edit the
/opt/fog/.fogsettingsfile and update the network adapter name and IP address in that file and save it. This .fogsettings file contains all of the answers you answered the first time you installed fog on the old server. When we rerun the fog installer next it will not ask you in questions, but take the answers you provided the first time. This should make the new fog server the same configuration as the old fog server just running on new hardware. - Now change to the cloned git repository for FOG in the bin directory run
./installfog.shto reinstall FOG. We are doing this to use the installer to install FOG and make sure the permissions are set correctly on all files it needs.
Now at this point you should have an old FOG server with all of the configurations and a new fog server (functional but not configured). The next steps are covered in the wiki to moving your fog server to a new host: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
When you are done you will have the old fog server and the new fog server. So you might ask why I took you this route. The simple answer its a bit more fool proof than the faster but more likely way of breaking your new server’s linux install if you make one mistake of copying partitions around.
A fog install has 3 components.
- The FOG program code
- The mysql database
- The raw data files in /images directory.
This method takes you through rebuilding part 1, and then you can just copy the configuration and raw data files for parts 2 and 3.
And in the FWIW bucket.
That 790 is fast enough for a small SMB (< 50 workstations) environment as long as the /images directory are on an SSD drive. The OS can be hosted on a traditional HDD if needed. Where the 790 falls down is if you are using a traditional HDD for image storage. That traditional HDD is not fast enough to keep up with more than 2 simultaneous unicast images being send to the target computer. At the point of 3 simultaneous unicast images being transmitted you will run into issues with that single GbE network adapter (assuming you have the images on a SSD drive). But for a small SMB, how many times are you going to image 3 computers at the same time? Probably not very high. With image push time in the 4-6 minute range, just stagger the start times if you really NEED to image 3 computers at the same time. -
@george1421 this is deployed at a school district with about 1,000 machines. I have the OS on a 240gb SSD and the images are on a 1TB 7200RPM disk. The machine I want to move it to is all fast SAS 1tb drives and a SAS SSD for the OS. Fog works great till we get to like 5 or 6 machines. Then we are under a gb a minute. One device we average 8-9gb
-
@cammykool Knowing the scope is good because it adds context to the request. While this is a moot point since you are migrating to new hardware, but if I had to stay with your current setup I would put the OS on the 1 TB disk and the images on the SSD. You would be killing (figuratively) that single spindle HDD if you try to deploy more than 3 systems at a time, just because the read/write head will be bouncing around the platters trying to serve all of that data at the same time. Adding more spindles to the image store will help to spread the load over all disks in the array. In the case of the SSD it doesn’t matter since seek time is almost nil. In regards to having the OS on the SSD that ssd doesn’t add much value to a running system. Booting yes, running no. The linux OS is not like the windows OS it operates differently and its disk demands are different too.
If your plan is to deploy 5-6 systems at the same time using unicast you will hit another bottleneck even if your disk array is all flash based. A single 1GbE nic on the FOG server will saturate after the 2nd simultaneous unicast image deployment (on modern target hardware). That 3rd unicast image will begin to slow down all three with retransmits upticking sharply. One way to have an immediate impact is to upgrade to a 10GbE NIC. The second way is to team multiple 1GbE network adapters together to give you more network lanes to use. Each single 1 GbE link will saturate at 3 simultaneous unicast but overall you can extend this by the number of network adapter you can add to the team.
But my intuition is telling me if you are “really” imaging 6 machines all at the same time, maybe you need to look into multicasting (which brings in its own bag of issues) to deploy to an entire classroom in one image push instead of 30 individual image pushes.
-
@george1421 that’s one of the big benefits of this new system. Dual Gb nics. Other big one is more storage. We were going to try to run it off of a hyper-v on our super powerful main hyper-v server but fog and Linux did not appreciate that.
-
@george1421 I’m moving from a 790 to a 14tb 4 nic with a Xeon e5-2603 v3
-
@cammykool said in Transferring frog to a new server.:
14tb 4 nic with a Xeon e5-2603 v3
That will be a decent FOG server especially for 1000 computer environment, especially if the FOG Client is installed on those 1000 computers. If you are not using the fog client on your campus, that server is a bit overkill (IMO). While my intent isn’t to minimize your choice, but the FOG server really doesn’t do much during imaging. On your campus having many fog clients will have a larger impact on the FOG server as compared to imaging.
But either way that server will serve you well. So I would go ahead and install linux and then FOG as I outlined below. Since you have multiple nic adapters you will want to setup teaming in linux before installing FOG.
-
@george1421 I was looking I to bonding. Fog has a guide on it. Yeah. All of my images have the fog client on them. I haven’t really messed with it much. I was able to get fog to rename machines but not much else when it comes to the client. I’m currently struggling with getting the nice to play together
-
@cammykool I would search for bonding and your linux distro. Bonding or teaming (depends on which method you use) is setup at the OS level. You will also need to get with your infrastructure folks to setup the switch the fog server’s plugged into for bonding. I would suggest LACP also called 802.1ad. Both the switch and the server needs to be configured for the same bonding type. When you setup bonding on the linux side, it will create a new network adapter typically called bond0. That virtual network adapter will then talk to its slave interfaces (the real physical nics). You will apply the IP address to the bonding nic and not the physical nics. The bonding driver will manage the physical interfaces once its setup. When you configure FOG you will tell it to use bond0 (or what ever the bonding interface name that is created). Once you have bonding setup and WORKING at the linux level then you can forget about it and install FOG. Don’t install FOG without or before bonding setup.
