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 BladeFrame EX
Egenera, egenera.com
|
Very Good 8.3 |
 |
| criteria |
score |
weight |
| Interoperability |
9 |
25% |
 |
| Management |
8 |
20% |
 |
| Performance |
9 |
20% |
 |
| Configuration |
7 |
15% |
 |
| Scalability |
9 |
10% |
 |
| Value |
7 |
10% |
 |
|
 |
Cost: Starts at approximately $300,000
Platforms: Windows Server 2003, Red Hat Linux, Suse Linux, Solaris 10 for x86
Bottom Line: Egenera’s BladeFrame EX is a model of tightly coupled hardware engineering and great design concepts. The management UI is
functional but lacks panache, and the overall solution lacks some small features you might expect to be present. Nevertheless,
Egenera succeeds in delivering a modular, high-performance, and highly adaptive blade server system.
|
 |
About our Reviews and Scoring Methodology
|
|
|
|
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.