Exclusive: BladeFrame EX slices, dices, dazzles
Egenera's flexible, modular server blade system takes a unique approach to the adaptive datacenterFollow @pvenezia
Each server instance, called a pServer, is initially configured through the Egenera PAN Manager, which is a Java interface accessed via a Web browser. The SAN must be configured with a suitable number of LUNs (logical unit numbers) that will be used as disks for each pServer. Building a pServer then becomes a matter of selecting an available LUN, selecting the number of virtual NICs, DVD-ROM drive mappings, and a single blade or a pool of blades that should run that pServer. When this has been done, the OS can be installed.
Egenera’s methods are far different from normal server hardware, so special steps are required to install and boot any OS. For Windows, Egenera supplies code that will combine a standard Windows Server 2003 installation and Egenera-specific drivers, producing an ISO image that is burned to a CD and used to install the OS. For Red Hat and Suse, Egenera supplies a boot image for each revision that includes the drivers necessary to boot the install image and performs post-install tasks to complete the picture. After an OS has been installed on a LUN, it can be duplicated and used to build another pServer, requiring Sysprep for Windows images.
One downside is that new OS installations must be performed from a physical CD for Windows, and via CD or network install for Linux and Solaris. Installations from ISO images aren’t possible, which is an unfortunate limitation.
After it has been installed, the pServer can then be booted on the BladeFrame on any available blade. Blades can be cut up into logical pools -- for instance, a pool might consist of six 2P blades, while another pool consists of six 4P blades. A pServer instance assigned to either pool could be booted on any blade in that pool and, in the event of a blade failure, be booted on another blade in that pool -- or a designated fail-over pool. An interesting feature introduced in the 5.0 release of PAN Manager is the ability to “warm boot” a blade. This basically pauses the blade’s boot cycle just after POST (Power On Self Test) but before an OS begins to load. Thus, a warm-booted blade boots far faster, reducing the time to bring up a pServer in the event of a blade failure.
Network I/O for each blade is delivered across the backplane and is represented to the OS as a standard NIC. In addition to any assigned NICs, the Egenera drivers and agents on the OS establish an internal network used for controller communications. With the NICs in place on the OS, each pServer is assigned to a virtual switch for intrachassis communication -- and potentially to a virtual switch for external communication if required. Servers that don’t need to contact systems outside the rack, such as database servers, need not have any form of external access available to them. My throughput measurement tests put this internal switching interconnect at roughly gigabit speeds.
Disk is delivered in a similar fashion, with the Egenera drivers presenting each SAN LUN to a pServer as a native SCSI drive. Thus, no HBA drivers or WWNN (World Wide Node Name) is required for any server; the controller handles all communications with the SAN. From the OS point of view, each connected disk is a local SCSI drive. On Linux OSes these drives may be added and removed at any time.
Through the looking glass