The IBM eServer BladeCenter is an exciting way to deploy and manage new solutions in your environment. A BladeCenter consists of individual blades, thin servers that slide into a BladeCenter chassis vertically like books in a shelf. Each blade is an independent server that contains its own processors, memory, storage, network controllers, operating system, and applications. The BladeCenter chassis supplies the power, cooling, floppy drive, and CD-ROM to each blade it contains, as well as advanced management of the blades. Additionally, the BladeCenter chassis can hold expansion modules that slide into the back to provide additional resources that are automatically shared across the individual blades. Common modules include a Gigabit Ethernet switch to provide a trunk of fast network connections for the blades to share, and a fibre switch that easily allows mass storage devices to be attached to the BladeCenter and shared across all blades. (For more information about BladeCenter, see its product page.)
The IBM Lotus Solutions Test team recently set up a BladeCenter to perform scalability analysis and operational profiling for Lotus Workplace 1.1 and other Lotus/IBM products. We did this to take advantage of several important BladeCenter features:
- Lower total cost of ownership (TCO). The BladeCenter significantly reduced the lab space required to host our servers, saving us a substantial amount of overhead costs.
- Simplified infrastructure. The Bladecenter is quick to install and easy to manage.
- Resiliency. Expanding the BladeCenter (for example, to accommodate an automatic failover system) is relatively painless.
In this article, we present a high-level overview of how we set up our BladeCenter. Our goal is to offer general advice and assistance to help guide system administrators to set up BladeCenters to run IBM/Lotus technology at their own sites. Even if you don't plan to perform any analysis or testing, this article should still be useful to help you set up a BladeCenter to host a production Lotus environment. We assume that you are at least moderately experienced with hardware, storage systems, and networking, and are familiar with Lotus software products.
Solution testing an integrated Domino/Lotus Workplace environment
Solutions Test is a new team at Lotus that examines software product interactions in a complex, integrated environment. When a new software product is developed, the Solutions Test team runs it in our labs and thoroughly test it to ensure smooth interoperability between all components. By performing this testing, we can better identify issues before the product is released to the public. We also identify any areas that need more complete documentation and record our experiences to help define best practices that customers can use when deploying similar solutions. Our first solution test effort involved integrating an existing Domino infrastructure (which also included Lotus Instant Messaging and Web Conferencing, Lotus Team Workspace, and Lotus Virtual Classroom) with Lotus Workplace 1.1 on WebSphere Portal 5.0. This integration was intended to consolidate access to these applications into a single Web browser window. We used a separate IBM DB2 8.1 server to store Lotus Workplace data and Tivoli Access Manager 5.1 to provide single sign-on for the environment. However, before we could execute the first line of code, we had to plan and build our hardware infrastructure. And our platform of choice was BladeCenter.
Setting up the testing environment
There were many issues involved in planning our hardware environment: space in the computer lab, mass storage, flexibility, easy administration, and (most importantly) whether or not the hardware solution helps our customers understand what is needed to deploy the software solution. But our first consideration was the existing environment where we would deploy and test the solution. This was our large test lab. The network within this lab is built upon a Cisco 6500 switch. This switch connects the lab to IBM's corporate network with two 1 GB fibre connections. It also serves as a trunk for a series of smaller switches that are placed in each rack of equipment. These smaller switches connect to the Cisco 6500 via Cat 6 cable running at 1 GB, but each machine in the switchâs rack is generally connected to it at 100 MB. All network traffic derived from automated test workloads remained exclusively within the lab network because it originates on driver machines that are also hosted within the lab. However, manual test traffic generally enters the lab network from the corporate intranet.
The core of our solution testing environment is the IBM eServer BladeCenter. This BladeCenter contains eight BladeCenter HS20 blades. Each blade is a dual processor Pentium Xeon running at 2.0 GHz with the Windows 2000 Service Pack 4 (SP4). Memory varies on each blade according to the server that it hosts (see Table 1 for detailed specifications later in this article). The BladeCenter is connected to the lab network via a single 1 GB Cat 6 network connection from the BladeCenter Ethernet switch to the Cisco 6500 switch. The blades communicate with the BladeCenter Ethernet switch via the internal backplane at 1 GB. An IBM FastT 600 provides additional storage on the BladeCenter with two Exp 700 expansion drawers. The connection to the FastT is made by a 2 GB fibre optic cable from the BladeCenter fibre switch to the host port on the FastT. The BladeCenter runs several software products in our environment, including:
- WebSphere Portal 5.0
- Lotus Workplace 1.1
- DB2 8.1
- Lotus Instant Messaging and Web Conferencing (Sametime) 6.5.1
- Lotus Team Workplace (QuickPlace) 6.5.1
- Lotus Domino 6.5.1
(Notice the rich array of Lotus products we're running on our BladeCenter--a point to consider when choosing the hardware platform upon which to run your integrated Lotus environment.)
In addition to the BladeCenter, our environment included eight other servers. Six of these servers were IBM eServer x330 servers--all of which run Windows 2000 SP4. On three of these servers, we ran Domino 6.5.1, which we used for Domino LDAP. These servers also ran Tivoli Access Manager 5.1 (for single sign-on) and Reverse Proxy Functions. Two other x330 servers hosted Lotus Virtual Classroom 1.1.1. On the last x330, we installed SuSe Linux 8.1 and ran Domino 6.5.1 as an application server. Each x330 was connected to a Cisco 2950 switch with Cat 5 cable at 100 MB; each Cisco 2950 was connected to the Cisco 6500 via Cat 6 cable at 1 GB.
Our configuration also included two IBM p630 servers running AIX 5.2. Each p630 ran two logical partitions (lpars) of two processors each (for a total of four lpars). We used one lpar to run Domino 6.5.1 as an application server. Another lpar ran DB2 8.1 as the database server to our blade-based WebSphere Portal 5.0. The following table lists each server in our environment:
| Computer | Operating system | Software | CPU | # CPUs/ speed | RAM (GB) | Internal HDDs (GB) |
| Blade | Windows 2000 SP4 | WebSphere Portal 5.0 with IBM HTTP Server 1.3.26 | Intel Xeon | 2 x 2.0 GHz (HT enabled) | 2.5 | 40 |
| Blade | Windows 2000 SP4 | Lotus Workplace 1.1 | Intel Xeon | 2 x 2.0 GHz (HT enabled) | 4 | 40 |
| Blade | Windows 2000 SP4 | DB2 8.1 | Intel Xeon | 2 x 2.0 GHz (HT enabled) | 2.5 | 40 |
| Blade | Windows 2000 SP4 | Lotus Workplace 1.1 | Intel Xeon | 2 x 2.0 GHz (HT enabled) | 4 | 40 |
| Blade | Windows 2000 SP4 | DB2 8.1 | Intel Xeon | 2 x 2.0 GHz (HT enabled) | 2.5 | 40 |
| Blade | Windows 2000 SP4 | Lotus Team Workplace 3.1 | Intel Xeon | 2 x 2.0 (GHz) | 2.5 | 40 |
| Blade | Windows 2000 SP4 | Domino 6.5 | Intel Xeon | 2 x 2.0 (GHz) | 1.5 | 40 |
| Blade | Windows 2000 SP4 | Lotus Instant Messaging and Web Conferencing 3.0.1 | Intel Xeon | 2 x 2.0 (GHz) | 1.5 | 40 |
| p630 | IBM AIX 5.2 | DB2 8.1 | Power4 | 2 x 1.2 GHz | 2 | 2 x 36 |
| p630 | IBM AIX 5.2 | Domino 6.5 | Power4 | 2 x 1.2 GHz | 2 | 2 x 36 |
| x330 | Windows 2000 SP4 | Lotus Team Workplace for LVC 1.1.1 | Intel Pentium 3 | 1 x 1.26 GHz | 1 | 18 |
| x330 | Windows 2000 SP4 | Lotus Team Workplace for LVC 1.1.1 | Intel Pentium 3 | 1 x 1.26 GHz | 1 | 18 |
| x330 | Windows 2000 SP4 | Tivoli Access Manager 5.1 | Intel Pentium 3 | 1 x 1.26 GHz | 1 | 18 |
| x330 | Windows 2000 SP4 | Domino 6.5 | Intel Pentium 3 | 1 x 1.26 GHz | 1 | 18 |
| x330 | Windows 2000 SP4 | Lotus Workplace Messaging 1.1 | Intel Pentium 3 | 1 x 1.26 GHz | 1 | 18 |
| x330 | Windows 2000 SP4 | DB2 8.1 | Intel Pentium 3 | 1 x 1.26 GHz | 1 | 18 |
When we selected the machines to be used for our infrastructure, physical space was a primary concern. We have a large test lab, but it is amazing how quickly seemingly abundant space is used up. With a large number of server blades within a single BladeCenter chassis, blade technology achieves high levels of density. In fact, our BladeCenter chassis only took seven rack units and could have contained six more blades, in addition to the eight we used, without requiring additional space. This means up to 14 powerful servers can be placed in only seven rack units. Even when we added the FastT 600 and two Exp 700 expansion drawers (for a total of 1.5 Terabytes of additional storage), we only consumed 28 rack units. The built-in fibre switch made sharing the FastT across all blades a simple matter of plugging in one cable. With the built-in Ethernet switch, only a single Cat 6 cable was needed to run all blades, saving ports on our Cisco 6500 switch for other purposes.
Fast deployment of our servers was another issue. While every member of the Solutions Test team enjoys playing with hardware as much as the next techie, our purpose is to test software, not spend our time struggling with mounting servers and running cables. The BladeCenter makes deploying new servers as easy as sliding blades in and out of the chassis. Each blade server connects to the infrastructure components in the chassis, so there is no need to run network and storage cables to each server when it is installed.
Other fast deployment features that we plan to use in the future include software management of operating system deployment. When a blade is inserted into a profiled chassis slot, the system can automatically load a designated operating system and application image onto the new blade; the server is designed to get up and running with no human intervention. On-demand needs are also met through software management. It is possible to keep a spare blade waiting to be repurposed: Under software control alone, the spare can replace a failing blade or help handle peak loads by having the proper image loaded to the machine and brought on-line.
Easy management of our servers is a key benefit of using the BladeCenter. Because the blade chassis hosts each independent blade server, administration of each server can be done via a browser interface. This includes monitoring each system's health for hardware failure, centralized logging of issues with each blade, and a central way to deploy firmware updates to each blade. As you can imagine, working with new software in its early pre-release stages presents challenges with system stability. There were many nights where instead of driving into the office to do a cold boot of an unstable system, it was possible to tell the BladeCenter to totally power down the system and then bring it back up from a simple browser interface. This saved time in getting the test systems back on-line (and reduced aggravation for the system administrators).
The last key issue for solutions testing is flexibility with the operating systems that we use. Each solution we design contains unique requirements that could require Windows, Linux, AIX, and so on. With BladeCenter, we now have the ability to deploy Windows or Linux quickly and easily side-by-side in the same chassis. In the future we also hope to use blades to deploy AIX with the same ease as Windows and Linux. This would gives us the potential for up to 14 blades in the same chassis with a mix of Windows, Linux, and AIX, while only taking seven rack units of space.
The following illustration shows our complete solutions test environment:
Figure 1. Solutions testing hardware configuration

As you can see, this configuration allowed us to run a sophisticated integrated software solution incorporating several different IBM and Lotus technologies, running on multiple servers, connections, and other hardware within a relatively modest amount of space and administration overhead. The key to this was our BladeCenter, which as we noted earlier let us set up eight powerful computers within a single small footprint.
We hope this article has given you some insight into the process of specifying hardware for a complex solution. There are many important factors to consider such as space, management, and flexibility. With BladeCenter, our Solutions Test team strongly believes we are extremely well equipped to perform thorough testing of solutions that will help enable our customers to solve their on-demand business needs. And our experience indicates BladeCenter can be a platform for you to consider when assessing the hardware needs for your own corporate business environment. Please let us know what areas of this article you found most useful, and feel free to suggest other topics you'd like to see us cover in the future.
- Read this interview to learn more about solution testing and the Common Services team.
- For more information about BladeCenter, see its product page.
- Get involved in the developerWorks community by participating in developerWorks blogs.
- Browse for books on these and other technical topics.
Michael Gazda has worked on projects involving network compression, IMAP, and Domino Web Access (iNotes). Previously, he spent over three years as a Senior Technical Support Analyst in Lotus Notes/Domino Technical Support where he handled a variety of support issues, including database design, mail routing, and server issues. He is a Certified Lotus Professional in both database design and server administration for both R4 and R5. When not at work, Michael attends Boston University part-time, earning his BA in Computer Science.




