The problem: We needed to efficiently and rapidly deploy five identical systems with two large hard disks configured as a hardware-controlled RAID 1 running Linux on the ext3, a journaled file system that is commonly used by Linux.

The solution (attempt 1): For our first attempt, we used scripting technologies to install and configure one model system, added supplemental software and configuration information as needed by hand, used Ghost to create a hard disk image, and then distributed that image to the other four target systems simultaneously over the network.

The creation of the model system using a combination of KiXtart (a free-format scripting language) and manual tweaking went smoothly. The creation of the Ghost image took around 30 hours to complete due to Ghost's lack of ability to see and skip free space in the ext3 file system. The distribution of this image to the other four systems appeared to proceed as expected. This process also took 30 hours to complete. Unknown to me there was an error in the image that prevented any of the ghosted machines from booting. Not wanting to potentially waste another 30 to 60 hours, we decided to try something a little different.

The solution (attempt 2): For our second attempt, we used scripting technologies to install and configure one model system (SystemA), added supplemental software and configuration information as needed by hand, shut down the system, pulled both mirrored drives from the model system (A0 and A1), pulled one drive from slot 0 from two other systems in the group that need to be deployed and set aside, evoked hardware RAID controller's RAID rebuilding utility to rebuild to remaining disk in slot 1 on target systems SystemB and SystemC. Once the rebuild process completed, pulled the newly rebuilt disks from slot 1 on the two target systems, replaced them with the disks set aside earlier and initiated a new rebuild. With the two newly rebuilt disks or the original disks from the model system, replaced the disks in slot 0 on the two remaining target systems and rebuilt.

Given

SystemA:  A0     A1

Round 1   
SystemB:  A0 → B1
SystemC:  A1 → C1

Round 2
SystemD:  A0 → D1
SystemE:  A1 → E1

While

SystemB:  B0 ← B1
SystemC:  C0 ← C1

Round 3
SystemD:  D0 ← D1
SystemE:  E0 ← E1

Each round of rebuilding took 3.5 hours, and you could check success or failure at the end of each round with certainty. Using this technique, duplicating the model system to the four other systems took a total of 12 hours to complete versus 60+ hours it took with Ghost or similar technologies. What's more, while the machine was rebuilding its array, it remained online and available the entire time. Although you probably wouldn't want to change content on a system working off the original seed drives for this process, you could certainly change the content on Systems B-E during Round 2 and Round 3 above without worry. On the RAID controllers we used, it was also possible to give priority to rebuild requests or to normal I/O. Depending on your situation, you might want to tweak those settings to expedite the rebuild. On our systems, giving priority to the rebuild process under a normal system load only saved us about 10 minutes off the 3.5 hours

Conclusion

Although there are a number of techniques used to deploy a model system configuration to systems with identical hardware, some are much more time consuming, labor intensive, and prone to failure than others. Using RAID 1 members on our model Linux system as seed drives for all the other RAID 1s in the same group of systems proved to be an easy, rapid and reliable method for system deployment.

» posted by jnaze

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine