IBM

Front cover

Managing IBM Eserver BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1 How to configure an IBM Eserver BladeCenter using IBM software management tools Covers IBM EserverBladeCenter management strategy Includes examples of network configurations

Roberta Marchini

ibm.com/redbooks

Redpaper

International Technical Support Organization IBM Eserver BladeCenter Systems Management with IBM Director V4.1 and Remote Deployment Manager V4.1 January 2004

Note: Before using this information and the product it supports, read the information in “Notices” on page vii.

First Edition (January 2004) This edition applies to IBM Director V4.1 and Remote Deployment Manager V4.1. © Copyright International Business Machines Corporation 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

iii

iv

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x Chapter 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 BladeCenter overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 BladeCenter management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 A quick overview of the PXE protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 3 5

Chapter 2. Configuring systems management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Installing Director and RDM onto a dedicated server . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Configuring MM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1 Using Director Deployment Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.2 Using the Web interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Discovering the BladeCenter chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Running the RDM basic scan task against all blades . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5 Building an image to be deployed onto the blades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6 Running a deployment task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Chapter 3. Network scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Spanning tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 One single LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Separate management and production LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Multi-homed management server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 A more complex scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 22 22 22 23 24

Chapter 4. Advanced scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1 Environments with multiple chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2 Hot spare blades: myth or reality? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What the script does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to use the script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37 37 37 38

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39 39 39 39 39

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

© Copyright IBM Corp. 2004. All rights reserved.

v

vi

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

© Copyright IBM Corp. 2004. All rights reserved.

vii

Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: ibm.com® BladeCenter™ IBM® xSeries®

Asset ID™ Rational Software Corporation® Rational® Redbooks™

Eserver® Eserver® Redbooks (logo) eServer™

™

The following terms are trademarks of other companies: Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.

viii

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Preface This IBM® Redpaper describes how to install IBM Eserver® BladeCenter™ using IBM Director (Director) and IBM Remote Deployment Manager (RDM). It provides a concise set of instructions based on several existing documents and product publications. This Redpaper is the result of the author’s experiences. It contains suggestions and information about potential problems and their resolution, based on working with customers. It is suitable for system administrators who are planning to install a BladeCenter. To this end, it covers the various options to perform the same tasks, enabling administrators to plan and implement the management infrastructure for their BladeCenter. The Redpaper contains a list of steps to install the various pieces of software. It also includes references to other documents for further details. The paper focuses more on the concepts than on the detailed steps. Once you clearly grasp what you have to do, you can figure out how to do it quite easily.

The team that wrote this Redpaper This Redpaper was produced by a team of specialists from around the world working at the International Technical Support Organization, Raleigh Center. Roberta Marchini is an IT Specialist in the xSeries® presales technical support in Italy. She has been in this position for more than five years, working in the systems management and server consolidation areas, following various projects in the Intel® arena. She holds an MCSE certification (both NT 4.0 and 2000 track). She is co-author of the redbook Integrating IBM Director with Enterprise Management Solutions, SG24-5388. Thanks to the following IBM employees for their contributions to this project: Massimo Re Ferrè, xSeries Presales Technical Support, Italy David Watts, International Technical Support Organization, Raleigh

Become a published author Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners, and/or clients. Your efforts will help increase product acceptance and client satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: http://www.ibm.com/redbooks/residencies.html

© Copyright IBM Corp. 2004. All rights reserved.

ix

Comments welcome Your comments are important to us! We want our Redpapers to be as helpful as possible. Send us your comments about this Redpaper or other Redbooks™ in one of the following ways: 򐂰 Use the online Contact us review redbook form found at: http://www.ibm.com/redbooks 򐂰 Send your comments in an Internet note to: mailto:[email protected] 򐂰 Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HZ8 Building 662 P.O. Box 12195 Research Triangle Park, NC 27709-2195

x

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

1

Chapter 1.

Concepts This chapter is an introduction to the BladeCenter solution. It describes the following: 򐂰 1.1, “BladeCenter overview” on page 2 򐂰 1.2, “BladeCenter management” on page 3 򐂰 1.3, “A quick overview of the PXE protocol” on page 5

© Copyright IBM Corp. 2004. All rights reserved.

1

1.1 BladeCenter overview The BladeCenter has been designed as a solution rather than simply as a set of servers. In fact, it is comprised of a chassis that provides basic services (such as blowers, power supplies, CD-ROM and diskette drives, video switching, network, and fibre channel connectivity) into which you plug blade servers. These blade servers contain processors, memory, disk drives and Ethernet adapters, plus the basic server components. One or two Management Modules (MMs) are installed in a BladeCenter chassis. The MM is in charge of all the servers and switch modules installed in the chassis. It has a dedicated network interface, with its own Internet Protocol (IP) stack and HTTP server for connection. This is known as the external interface. There is also an internal interface, which is connected via an internal hub to the switch modules in the BladeCenter chassis. This arrangement is illustrated in Figure 1-1, which is taken from IBM xSeries Education course XTW14, “Blades.” For more information, see http://www.ibm.com/servers/eserver/education

Management LAN

Higher Security

Internal LAN conn. Production LAN

BladeCenterTM Drawer Management Module Web Browser

MM External Eth. Port

DHCP lease or 192.168.70.125

Any of the 4 Ext. Ports

Web Interface Switch Module 1

I2C bus

Always Static, default is 192.168.70.126

Internal 10/100Mb Eth. Default is 192.168.70.127*

Web Interface External Management disabled by default

Telnet Interface

*This is 192.168.70.128 If Module is plugged into 192.168.70.129 192.168.70.130

Rear Bay 2 Rear Bay 3 Rear Bay 4

Figure 1-1 BladeCenter connections

The internal interface is used to communicate with all of the I/O modules installed in bays one to four in the chassis. This allows you to completely separate the management network from the production network. For example, you can connect the MM external interface to one network segment. Then, you can connect the external Ethernet ports of the switches to

2

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

another network segment without exposing the switch management IP address. This approach does not enable external management. In this case, you must bear in mind that you only will be able to reach the IP addresses that have been assigned to the switches from the management network if they are in the same logical network as the MM external Ethernet interface. This is the only interface physically connected to that network segment.

1.2 BladeCenter management IBM provides two pieces of software for BladeCenter management and deployment: 򐂰 IBM Director 4.1x (Director), which is provided for free to all IBM Intel-based servers customers 򐂰 Remote Deployment Manager 4.1x (RDM), which is provided for a fee to clients RDM 4.1x is integrated into Director 4.1x, which is a prerequisite for it. In this paper, we refer to the version numbers of Director and RDM version as V4.1. IBM software management tools are designed to make the BladeCenter deployment and management easier and faster. However, you can choose not to use them. In this case, you will use the MM Web interface (available via a standard Web browser). Then, you can deploy the operating systems onto the blade servers by using standard installation methods (for example, booting from CD and running setup or performing unattended network installations). To fully implement a BladeCenter strategy, we recommend that you use both Director and RDM to manage and deploy blades. Among its other features, Director manages the hardware; it talks directly to the BladeCenter MM through a special protocol, called Service Location Protocol (SLP). This makes it possible to register the BladeCenter chassis and the installed blades into the Director database. Once the BladeCenter is registered into Director, the chassis and the blades can be managed from the Director Console. Consequently, you can perform all the actions that are available through the MM Web interface through the Director Console (except for blade Remote Console Redirection and a few others). These include actions such as blades power on/off and hardware configuration. You are also notified of events coming from the chassis (such as hardware health and alerts, and blade insertion). On the other hand, RDM is responsible for deploying the operating system on brand new systems from scratch. RDM uses the Preboot eXecution Environment (PXE) protocol, a standard feature of the network adapter that also needs to be supported by the machine BIOS. With the PXE protocol, the server to be installed boots from the network and the RDM server provides the basic environment to start the installation of the operating systems OS (DOS for Microsoft® operating systems, Linux for Linux). One prerequisite is a Dynamic Host Configuration Protocol (DHCP) server, not necessarily on the same server used as RDM server. For more details refer to the RDM 4.1 Installation Guide. If you think about what each piece of software is doing, it is straightforward that while Director needs a Transmission Control Protocol/Internet Protocol (TCP/IP) connection to the BladeCenter MM, RDM needs a connection to the blade servers’ Ethernet adapters. This opens some considerations on the network configuration in a BladeCenter environment, which will be covered in Chapter 3, “Network scenarios” on page 21. In order to add management capabilities at the OS level, Director Agent can be installed on the deployed servers. Please note that this time the connection between the Director Server Chapter 1. Concepts

3

and the Director Agent is established through the blades’ Ethernet adapters (via the Ethernet switch module). The agent can be installed manually once the operating system has been installed on the Blade Servers. The agent also can be installed automatically, by appending the agent installation to the OS install task in RDM (both for Windows® and Linux). However, Linux requires RDM V4.11 or later. Note: Not all Linux distributions are supported with RDM. Check Remote Deployment Manager publications for details. The necessary network connections for proper management of a BladeCenter chassis are shown in Figure 1-2.

IBM Director Server

RDM Server

•Hardware Management link •RDM install link •IBM Director agent link

Integrated Network Blade Server Adapter

MM

OS

Eth Switch

IBM Director Agent

Figure 1-2 Network connections for proper management

Once you understand which connections are necessary, you can try and outline your preferred network layout based on your client needs. This is a difficult task because VLANs can be involved, but once you have it clear, you should be able to do it. We’ll try to discuss a few of these layouts in Chapter 3, “Network scenarios” on page 21. For more information about Director V4.1 and RDM V4.1, please refer to 򐂰 IBM Director V4.1 - Systems Management Guide, available from http://www.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50461 򐂰 Remote Deployment Manager V4.1 Publications, available from http://www.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50575 Tip: Always check the latest version publications. They are all available from http://www.pc.ibm.com/support

Select Online Publications and then the product you are interested in.

4

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

1.3 A quick overview of the PXE protocol To use RDM, you need to clearly understand how PXE works. The PXE client is the machine that is trying to boot from the network (our blade server). The steps involved in a network boot are as follows: 1. The PXE client issues a DHCP Discover request (broadcast). 2. The PXE client now waits for two answers: the DHCP Offer and a list of PXE servers. In order for this to happen, the DHCP Discover needs to be intercepted by both the DHCP Server and the PXE Server. Of course, if the PXE and DHCP servers are on the same machine, the list of boot servers will be received as option 60 (hence the need to add this option to the DHCP server configuration). 3. The PXE client starts receiving the DOS image and what is needed to perform the scheduled tasks. Please note that since the first request is broadcast, you should pay particular attention to this when routers are involved. The Remote Deployment Manager 4.1x Installation Guide contains a few examples of network configurations where routers are involved. For further details about PXE protocol, see the Intel specifications available from ftp://download.intel.com/labs/manage/wfm/download/pxespec.pdf

Chapter 1. Concepts

5

6

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

2

Chapter 2.

Configuring systems management You must perform this list of conceptual tasks when you set up a systems management for a BladeCenter chassis. 򐂰 2.1, “Installing Director and RDM onto a dedicated server” on page 8 򐂰 2.2, “Configuring MM” on page 8 򐂰 2.3, “Discovering the BladeCenter chassis” on page 17 򐂰 2.4, “Running the RDM basic scan task against all blades” on page 17 򐂰 2.5, “Building an image to be deployed onto the blades” on page 19 򐂰 2.6, “Running a deployment task” on page 20 This Redpaper does not provide a step-by-step guide to performing these tasks since that information can be found in the user guides for Director and RDM. The Redpaper is written under the assumption that its the readers have a basic knowledge of Director and RDM. Refer to “Related publications” on page 39 for the relevant product publications.

© Copyright IBM Corp. 2004. All rights reserved.

7

2.1 Installing Director and RDM onto a dedicated server This step is only necessary if your customer is planning to use Director and RDM (which we recommend). As we discussed in 1.1, “BladeCenter overview” on page 2, the Director management server needs to be in the same network as the MM. On the other hand, the RDM server also needs to talk to the blades. We are not taking into account what network configuration you are using because this does not change our configuration steps. However, bear in mind that you can also take advantage of distributed RDM servers. This is particularly useful when you have slow links: for example, in a Wide Area Network (WAN). For more details refer to the RDM 4.1 Installation Guide, Chapter 1. Bear also in mind that if you are planning to use Director Deployment Wizard and want to append blade servers operating system installation, you need to have RDM profiles already configured and ready to use.

2.2 Configuring MM The first action you need to perform is to configure the BladeCenter MM. Its default behavior is to get an IP address from a DHCP server. If one is not found on the network, the MM assigns itself the 192.168.70.125/24 IP address on the external interface and 192.168.70.126/24 on the internal interface. Therefore if you connect the power to a brand new BladeCenter chassis and do not have a DHCP server, you should be able to ping the default IP address 192.168.70.125. Using a DHCP server should be easier in that you can use a single network both to manage your hardware (via Director) and to install the OS on your servers. However, you need a way to get the IP address that the MM got from the DHCP server. Methods for getting this address include the following: 򐂰 Check on the DHCP server itself to determine which IP address has been assigned. 򐂰 Configure the DHCP server register the IP in a Domain Name System (DNS) server, allowing you to look up the MM name. 򐂰 Using the Director automatic discovery feature. You must configure the MM IP address if, like most users, you do not use DHCP and you have planned to use a different IP addressing schema than the default. You also have to configure the MM IP address if you simply want to ensure that your BladeCenter chassis will have a static IP address. Remember that you have to configure both the internal and external IP address on the MM and on the switch modules installed in the chassis. In order for everything to work properly, both interfaces (internal and external) need to be on the same logical network, as well as the switch modules management Ethernet interfaces. You have two options for the MM configuration (as shown in Figure 2-1 on page 9): 򐂰 You can use Director Deployment Wizard. This allows you to configure all the options (using IP address ranges), including the Ethernet switch module IP addresses, and then to save your profile for later use (by dragging and dropping the saved profile to another brand-new chassis that will pick up the free IP addresses in the specified range). In order for this to work, Director needs to discover the chassis. You don’t need to know the IP address that has been allocated to the MM, but the MM network has to be reachable from the Director management server.

8

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

򐂰 The second option is to use the MM Web interface, which also allows you to save the configuration to a file and then apply it to a new chassis. See Figure 2-1 for an illustration of these configuration options.

2. Web Interface

1. Director Console

ethernet

Integrated Network Blade Server Adapter

MM

OS

Eth Switch

IBM Director Agent

Figure 2-1 MM configuration methods

You will realize in a few minutes that Director offers more automation than the Web interface. However, not all of your clients will be open to use Director. For example, they may not want to dedicate a server for systems management purposes. Other clients may already have a systems management tool and not be interested in adding the automatic deployment features at the cost of upgrading and maintaining their internal skills on an additional software product.

2.2.1 Using Director Deployment Wizard In order to use Director Deployment Wizard, you have to discover your BladeCenter Chassis first. In the Director Console, right-click the central column, Group Contents, and click Discover → BladeCenter Chassis. Allow some time (perhaps 60 seconds) for the discovery to complete. An icon representing your chassis should appear, as well as the blades. You should see a padlock next to the BladeCenter icon. We are not able to understand what the correct behavior should be. Sometimes the padlock automatically disappears. At other times, you have to right-click the BladeCenter and click Request Access task. Then, you must provide the MM user ID and password (the USERID/PASSW0RD pair). Sometimes, you get a pop-up message stating that the request failed. However, if you wait a few seconds, the padlock disappears anyway. Also, you should bear in mind that you can manage a BladeCenter chassis from one single Director server at a time. There are no hardware or software limitations. Thus, you can register a chassis in two different Director servers at the same time. However, you must be careful not to launch configuration tasks at the same time.

Chapter 2. Configuring systems management

9

At this point, you should have your BladeCenter and Blades in the central column, something like the screen shown in Figure 2-2.

Figure 2-2 BladeCenter and blades discovered by Director

Note that when Director requests access to the BladeCenter Chassis, it actually adds an entry to the Remote Alert Recipients list in the MM itself. This entry instructs the MM to forward all events to the Director server managing the system, as you can see from the MM Web interface in Figure 2-3 on page 11.

10

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Figure 2-3 Remote Alert Recipients in the MM Web interface

You will soon realize that if you have many systems in your director database, it’s going to be difficult (1) to find out which ones are actually blades and which ones are not or (2) to see which blades belong to which chassis. If you click Associations → Chassis Membership, the Director Console will show the blade servers under the chassis they belong to, as shown in Figure 2-4 on page 12.

Chapter 2. Configuring systems management

11

Figure 2-4 Blades viewed per chassis in Director Console

Now you can start with the Deployment Wizard. Expand the BladeCenter Assistant task. You should find the Deployment Wizard task. Drag and drop the Deployment Wizard onto the discovered BladeCenter. Follow the menus to configure your MM; the wizard is largely self explanatory. Don’t be afraid to proceed because you are not applying the configuration yet and are just going through the wizard. Once finished, you will have the options to (1) save your profile for future use and (2) decide whether to apply it or not. Note, however, that if you do not have a working TCP/IP connection to the MM (if it is grayed out in the Director Console) you will not be able to proceed after the first page of the wizard. Note also that the wizard might be quite slow because it is communicating with the MM directly, even though it is not making any modification to its configuration. If the deployment wizard detects that RDM is installed, you are asked if you want to assign RDM tasks to blade slots in the chassis. (See Figure 2-5 on page 13.) The user interface here is a little misleading, since at first sight it looks like you can only configure one single profile for all the slots or a few selected slots. Actually this is not true. The correct way of proceeding would be to: 1. Select the blade slot(s) you want the same RDM profile to be assigned to. 2. Select the RDM profile from the pull-down list. (We recommend that you give your profiles easy-to-understand names). Click Apply. This should add a check box to the selected slots. (Look very carefully at Figure 2-5 on page 13. In Figure 2-6 on page 14, the check box is circled.) This means that you have selected the slot and assigned a profile to it once.

12

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

3. Repeat steps one and two until you are done. Notice that if you select a slot that is already assigned, the new profile overrides the existing one. Figure 2-5 depicts the profile selection wizard.

Figure 2-5 Profile selection wizard

The RDM profile is shown in Figure 2-6 on page 14.

Chapter 2. Configuring systems management

13

Figure 2-6 Blade policy configuration

4. When you are done, click Next. Note that the Next button is grayed out until no slots are selected. You will then be presented with the summary of the profile you have just created and be able to check the slots assignments you did, as shown in Figure 2-7 on page 15.

14

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Figure 2-7 Profile summary

Notice that one of the check boxes permits you to save the profile as the “detect and deploy profile.” This means that as soon as you discover a new BladeCenter chassis, the new configuration will be applied. This choice could be quite disastrous, so we do not recommend that you use it. One last comment: there is no opportunity to switch modules other than in the network switches in the deployment wizard. Therefore if, for example, you have Fibre Channel Storage Area Network (SAN) switches installed in the chassis, you have to configure their IP addresses from the Web interface. 5. Once you are done, click Finish. This is like dragging the profile onto the chassis, so you are asked if you want to execute the task now, schedule it, or cancel. If you click Cancel, you have your profile saved and will be able to drag and drop it onto a BladeCenter Chassis later. These options are depicted in Figure 2-8 on page 16.

Chapter 2. Configuring systems management

15

Figure 2-8 Schedule or Execute Choice when you complete the deployment wizard

If you select the option to execute the profile against the chassis, you see something similar to Figure 2-9 in the director log file. Bear in mind that this actually starts the blades’ installation. Tip: When you apply a new configuration to the BladeCenter and change its MM IP address, Director does not update the information in its database. (The Chassis Object will always be grayed out.) You will need to run a discovery task again to update the MM IP information.

Figure 2-9 BladeCenter Deployment Director log

2.2.2 Using the Web interface We are not going to describe this method with many details because the Web interface is self-explanatory. However, be sure you do the following: 1. Configure the proper external and internal IP addresses in the Management Module Control → Network Interface tab. Do not restart the MM until you have completed your configuration.

16

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

2. Configure the Ethernet switch modules IP addresses properly. 3. Make sure that the switch module external ports are enabled. (This is a flag in the Switch Management task into the MM Web interface, not in the switch Web interface. The default should be to have them enabled, but sometimes it does happen that the blades network interfaces are not working. We finally discovered that the switch external ports were disabled; this may happen especially when you add and remove the switches without allowing them time enough to initialize properly). 4. Decide whether to enable the Ethernet switch module management through external ports. 5. Enable your alert settings and trap forwarding destinations. 6. Change the default user ID settings and add new users as required. 7. Restart your management module and check whether you can ping the new IP address. If you find that something is wrong, you can still reset the configuration to the factory default settings using the button situated on the MM and start again!

2.3 Discovering the BladeCenter chassis If you use the deployment wizard, you are ready to work with RDM on your blade servers. Go to the next step directly. If you use the Web interface to configure the MM and still want to use RDM to deploy the operating system onto the blade servers, you now have to discover the chassis in Director. Refer to 2.2.1, “Using Director Deployment Wizard” on page 9 for details.

2.4 Running the RDM basic scan task against all blades Once the MM has been discovered by Director, every blade server is present into the Director database because the MM provides the basic information about what is inserted in the chassis. This information, however, is not enough for RDM to work. The information that is missing includes which hard disk drives are used and the amount of memory installed in the systems. Therefore, the first task you have to run against each blade server is Basic Scan, which simply collects inventory data. Drag the task to your blades, and select Run Systems, as shown in Figure 2-10 on page 18. You are asked whether you want to schedule for a later run or execute the task now.

Chapter 2. Configuring systems management

17

Figure 2-10 Basic scan task in RDM

Before starting to work with RDM, make sure that the startup sequence of the servers to be deployed is configured correctly: that is the server boots from the network before any hard drive. Please note that RDM behaves differently when dealing with blade servers than with respect to other server models. In fact, the PXE service running on the RDM server intercepts every “unknown” system that tries to boot from the network and runs a scan task against it. By “unknown” we mean a system that is not registered into Director. Since the blades are known to Director via the MM, this first task will never run automatically when the servers boot from the network, hence the need to run it manually. Also note that if you try to boot your blade servers (and the boot sequence is such that the server tries to boot from the network) bef ore the MM has been discovered in Director, the automatic scan task will be run because the servers are “unknown” to Director. This default RDM behavior can be changed by selecting from the Director Console Tasks → Remote Deployment Manager → RDM Options. This will pop up the window in

18

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Figure 2-11. If you select Scan Disabled, RDM will not scan unknown servers requesting PXE boot.

Figure 2-11 RDM options window

To summarize, every server (blade or not) that has a hardware out of band management adapter (either the MM for blades, or the Remote Supervisor Adapter card for other models) can be discovered by Director by means of direct communication with the hardware device. If it has already been discovered, then you need to run a Basic Scan in order for RDM to work correctly; if you have not launched the discovery task, then the server is automatically scanned by RDM if it boots to the network. Bear also in mind that if you have two Ethernet switch modules installed in your BladeCenter chassis, the first network adapter that attempts the PXE boot is the one connected to Ethernet switch module number two. Take this into account when planning your installation.

2.5 Building an image to be deployed onto the blades Now that the inventory information is complete, you need to build an image to be installed onto the blade servers. This means either a Windows native install, a Windows clone install, or a Linux native install. (RDM means unattended by the term native.) Cloning Linux is not possible at the time of writing. This is due to the fact the RDM performs cloning operations using a cut-down version of PowerQuest that is limited to only one partition. Linux usually has four partitions, hence the limit.You might think of upgrading to the full version of PowerQuest, but you will need to modify the built-in RDM tasks. Alternatively, you might create a Custom Task to use any other imaging program (such as ghost), but this is going to be quite an effort. Please refer to RDM 4.1 Operations Guide for a detailed how-to on building RDM tasks. Please note that the Windows Clone Task profile has been created for usage with Microsoft Sysprep, which is a tool that removes all the specific information (such as Security Identifiers Chapter 2. Configuring systems management

19

and network names) and powers off the server against which you ran Sysprep. When you power that server on again, you are presented with a sort of Windows Setup asking you the information you removed running Sysprep. The clone task restores the previously cloned partition image to the new disk. Then it reboots the server and runs an unattended setup to answer sysprep questions. This means that if you did not run Sysprep prior to capturing the image of a donor computer, there will be no setup to run and the clone task will timeout because it will never complete this mini-setup. Also bear in mind that for some reason Sysprep does not delete the IP address of the donor machine. Therefore, if you deploy more than one server at a time using the same clone image, you can get an IP address conflict error message. We recommend you modify the donor system IP configuration to use a DHCP server prior to running sysprep.

2.6 Running a deployment task Now that the images and the tasks have been created, it is the time to run them. It is very straightforward; you just need to drag your task onto the system(s) on which you want to install the operating system. If you drag and drop the task to multiple systems, RDM automatically uses multicast to transfer the images. Please note that if you assigned RDM tasks to the BladeCenter slots using the Director Deployment Wizard, those tasks start automatically right after you apply the Deployment profile or every time a new blade server is inserted in a slot with a profile associated to it. You can still run RDM tasks at your choice. Remember, however, that if you change a blade server because of a hardware failure, the RDM task that has been associated in the deployment wizard will start.

20

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

3

Chapter 3.

Network scenarios The aim of this chapter is to outline a few of the options you have while setting up your network environment. As you may well imagine, there are thousands of different network scenarios based on the customer’s environment. If you have a thorough understanding of the way communication takes place, then you’ll be able to figure out what is the best solution for your real life cases. In the following sections, we report a few cases that are the most common. 򐂰 3.1, “Spanning tree” on page 22 򐂰 3.2, “One single LAN” on page 22 򐂰 3.3, “Separate management and production LAN” on page 22 򐂰 3.4, “Multi-homed management server” on page 23 򐂰 3.5, “A more complex scenario” on page 24

© Copyright IBM Corp. 2004. All rights reserved.

21

3.1 Spanning tree The very first hint that you need to bear in mind is that spanning tree might cause many problems when trying to use RDM. Spanning tree is a protocol that is used to avoid loops in a network topology. In order to do this, switches can actually disable ports that they “sense” to be creating loops. Unfortunately, prior to putting a port on line, the switch checks to determine whether no loops are present, and it might take a long time for the port to come on line. This time is often longer that the PXE timeout. The result is that the PXE client is not issued an IP address from DHCP because the port in the switch is not forwarding packets. You might be misled and think that your DHCP/RDM servers are not working. The simplest way to avoid this problem is to disable spanning tree, if at all possible.

3.2 One single LAN The simplest case is a single Local Area Network (LAN) arrangement. From a physical standpoint, all of the networks are connected together. Please note that because RDM works with the PXE protocol that is broadcast based, additional switch configuration may be needed if there is no direct connection (from a broadcast standpoint) from the blade server network adapter to the RDM server adapter. For example, you might need to configure parameters like IPHelper (in Cisco switches) to send the PXE request to the proper network segment (known by the switch). This single LAN is shown in Figure 3-1.

IBM Director Server

Production LAN RDM Server

Integrated Network Blade Server Adapter

MM

OS

Eth Switch2

Eth Switch1

IBM Director Agent

Figure 3-1 Management and production not separated

3.3 Separate management and production LAN Another very simple scenario is a separate management and production arrangement. This time one of the Gigabit Ethernet switches in the BladeCenter is completely dedicated to the management LAN, and you only have one interface for the production LAN for each blade. You also have a network interface that is dedicated to the Director Server/Agent communication. This scenario is shown in Figure 3-2 on page 23. 22

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

IBM Director Server

RDM Server

Management LAN

Production

Integrated Network Blade Server Adapter

MM

OS

Eth Switch2

Eth LAN Switch1

IBM Director Agent

Figure 3-2 Management and production LAN separated

3.4 Multi-homed management server Another option you have is to install two network adapters onto your management server. The purpose is to use one of them for RDM/PXE traffic and the other one for Director Server/MM traffic. The problem with this configuration is that you are not splitting the management LAN and the production LAN. Instead, you are splitting the hardware management from the software management. Therefore, if you want to install Director agent on your blades and have them talk to your director server, you must provide a routing path from the production LAN to the management LAN. This arrangement is depicted in Figure 3-3 on page 24.

Chapter 3. Network scenarios

23

IBM Director Server

Production LAN RDM Server

Integrated Network Blade Server Adapter

MM

OS

Eth Switch2

Eth Switch1

IBM Director Agent

Figure 3-3 Multi-homed management server

3.5 A more complex scenario In a more complex scenario, the blade servers are meant to be the front-end servers in a typical three-layer architecture. Two firewalls are configured to filter traffic from the internet to the front-end network and from the front-end network to the back-end. The management server and the MM are placed in the back-end segment; in order to allow the blades to talk to the RDM server, you need to either (1) configure the router/firewall DHCP relay agent to forward traffic to both the RDM and DHCP server or (2) install a software-based relay agent in the front end network. Please note that both the PXE (RDM) and DHCP server must be reachable by the initial DHCP Discover broadcast from the PXE client (if they are not on the same machine). This scenario is shown in Figure 3-4 on page 25.

24

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Internet

Firewall

FrontEnd

IBM Director / RDM Server

Integrated Network Blade Server Adapter

MM

OS

Eth Switch2

IBM Director Agent

Eth Switch1

Firewall

BackEnd

Figure 3-4 Complex scenario

Chapter 3. Network scenarios

25

26

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

4

Chapter 4.

Advanced scenarios This chapter describes more advanced utilization scenarios. The first part describes what needs to be done when you manage multiple BladeCenter chassis from the same director server. In the second part, we present a few considerations regarding the implementation of a hot spare blade server.

© Copyright IBM Corp. 2004. All rights reserved.

27

4.1 Environments with multiple chassis If you have several chassis with blades installed and you manage them using Director agent, you will soon realize that you can get lost in the Director interface. The problem here is that you cannot select multiple associations. Therefore, you do not have a view where you have the chassis with its members and the corresponding Director agent object. This problem might be fixed in the next version of Director. In the meantime, we thought to make use of the DIRCMD command line, which is available with Director V4.1, to create a Visual Basic Script that works on a Microsoft OS host. This script creates a dynamic group for each chassis that has been discovered in the Director database. The group contains all of the blades and the corresponding Director agent objects identified by their serial number. This way, you have one group for each chassis. That is not actually what you might have wanted, but it at least provides a way of separating your objects. The script does the following: 1. Looks for the BladeCenter chassis registered in Director database 2. Looks for Blades installed in each chassis 3. Extracts each Blade Server serial number from Director DB 4. Creates a dynamic group containing all the physical objects that belong to the chassis and all the Director agents with a serial number that matches one of the servers in the chassis The groups created are dynamic, meaning that you can install and register the Director agents later. If you add more blades to the chassis, you’ll have to run the script again. You can launch the script from a Microsoft-based machine by double clicking it. This machine is not necessarily the Director server installed, but it needs the DIRCMD command line utility. The script prompts you for the Director server IP address (that needs to be reachable) and a valid user ID/password pair. The vbscript code is shown below. The usage of the script is discussed in Appendix A, “Additional material” on page 37. The script can be downloaded from: ftp://www.redbooks.ibm.com/redbooks/REDP3776 Tip: The URL above is case-sensitive.

Example 4-1 VB script to create a dynamic group for each chassis that has been discovered

'****************************************************************************** * ' File name : CreateBladeGroups2.0.vbs ' Author: Roberta Marchini ' Date: August 29th 2003 ' ' '****************************************************************************** * Option Explicit Const MAXNUMCHASSIS = 100 Const BLADETYPE = "8678" 28

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Dim oFSO, oFile, strLine, arrObjId, string, index, counter, snPtr, sn, server, user, password, objShell, oExec Dim chassisId, arTemp, groupid, finalString, return, grouplist, arrStr, workingDir, filename Dim chassis(), ii

server = InputBox("Enter the IBM Director server hostname or IP address", "Input Required") user = InputBox("Enter the IBM Director server userid", "Input Required") password = InputBox("Enter the IBM Director server password", "Input Required")

' Find how many chassis we have discovered in director interface string = "dircmd -s " & server & " -u " & user & " -p " & password & " server listinventoryvalues -t PC_INV.CHASSIS_MEMBERSHIP.CHASSIS_MANAGED_OBJ_ID > chassisid.txt" Set objShell = WScript.CreateObject("WScript.Shell") Return = objShell.Run(string, 3, true) If Return 0 Then MsgBox("ERROR: Cannot access director server. Please Check Servername, userid and password") Wscript.Quit End if

' Now we have a list of the chassis objectid in file chassisid.txt and need to parse that list into an array Set oFSO = CreateObject("Scripting.FileSystemObject") Set oFile = oFSO.OpenTextFile("chassisid.txt",1) ' The first line is always garbage to me so I skip it strLine = oFile.ReadLine ' Now I want to read the line containing the chassisids strLine = oFile.ReadLine oFile.Close

arrObjId = split(strLine, """") ' ATTENZIONE AL carattere di escape ' delete the file chassisid.txt objShell.Run "%comspec% del /f chassisid.txt" '********************************** ' Clean the array from empty spaces '********************************** 'Read the chassisids ii = 0 Redim chassis (MAXNUMCHASSIS) For Each chassisId in arrobjid if chassisId " " and chassisId "" Then chassis (ii) = chassisId ii = ii +1

Chapter 4. Advanced scenarios

29

end if Next Redim Preserve chassis(ii-1)

' ********************************* ' Main Loop for each chassisid ' ********************************* For Each chassisId in chassis ' create a temp group to contain the blades in that chassis, that will be deleted at the end string = "dircmd -s " & server & " -u " & user & " -p "& password & " server CreateDynamicGroup -f temp PC_INV.CHASSIS_MEMBERSHIP.CHASSIS_MANAGED_OBJ_ID = " & chassisId finalString = "dircmd -s " & server & " -u " & user & " -p "& password & " server CreateDynamicGroup -c -f " & chassisid & " PC_INV.CHASSIS_MEMBERSHIP.CHASSIS_MANAGED_OBJ_ID = " & chassisId return = objShell.Run(string, 3, true) If Return 0 Then MsgBox("ERROR: Cannot access director server. Please Check Servername, userid and password") wscript.quit End if ' execute dircmd to get a list of the content of the group string = "dircmd -s " & server & " -u " & user & " -p "& password & " server listgroups > grouplist.txt" return = objShell.Run(string, 3, true) If Return 0 Then MsgBox("ERROR: Cannot access director server. Please Check Servername, userid and password") wscript.quit End if ' ********************************* ' Now find the groupid correspoding to the temp group ' ********************************* filename = "grouplist.txt" Set oFile = oFSO.OpenTextFile(filename,1) Do While oFile.AtEndOfStream = False strLine = oFile.ReadLine ' search for the string temp arTemp = split(strLine, " ") For Each string In arTemp If string = "temp" Then groupid = arTemp(0) end if Next Loop ' delete the file grouplist.txt objShell.Run "%comspec% /c del /f grouplist.txt"

' *********************************

30

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

'now that we have the groupid we must create the file containing the objids of the members of the group string = "dircmd -s " & server & " -u " & user & " -p "& password & " server listgroupmembers " & groupid & " > objids.txt" Return = objShell.Run(string, 3, true) If Return 0 Then MsgBox("ERROR: Cannot access director server. Please Check Servername, userid and password") wscript.quit End if ' ********************************* 'now we have to parse the Serial numbers of each blade and create a new group ' ********************************* Set oFile = oFSO.OpenTextFile("objids.txt",1) index=0 Do While oFile.AtEndOfStream = False strLine = oFile.ReadLine 'search for the string BLADETYPE arrStr = split(strLine, " ") snPtr = 0 counter=0 For Each string In arrStr If Left(string, 4) = BLADETYPE Then snPtr = counter + 1 sn = arrStr(snPtr) end if If snPtr 0 Then FinalString = FinalString & " OR PC_INV.UMS_ASSETID.SerialNumber = " & sn snPtr = 0 index = index+1 end if counter = counter + 1 Next Loop Return = objShell.run(FinalString ,3, true) If Return 0 Then MsgBox("ERROR: Cannot access director server. Please Check Servername, userid and password") wscript.quit End if ' ********************************* ' remove the temp group ' ********************************* string = "dircmd -s " & server & " -u " & user & " -p "& password & " server deletegroups " & groupid Return = objShell.run(String ,3, true) If Return 0 Then MsgBox("ERROR: Cannot access director server. Please Check Servername, userid and password") wscript.quit End if

Chapter 4. Advanced scenarios

31

Next MsgBox("Group(s) successfully created")

'**************************** ' Final cleanup '**************************** objShell.Run "%comspec% /c del chassisid.txt" objShell.Run "%comspec% /c del grouplist.txt" objShell.Run "%comspec% /c del objids.txt"

In Figure 4-1, you can see the dynamic group criteria selected by the script for the group just created. As you can see, they consist of the chassis ID to which the object belongs and the Asset ID™ Serial Number matching the correct serial numbers of blades installed in the chassis itself.

Figure 4-1 Dynamic Group editor showing the criteria used to define the group

In Figure 4-2 on page 33, you can see the group content with the Platform Membership associations. Notice that you only have physical platform objects and Director agent objects that belong to the same chassis. The group name is set to the chassis ID assigned by Director (which is a number), but it can be easily renamed by the user to a more appropriate name.

32

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Figure 4-2 Dynamic group content

4.2 Hot spare blades: myth or reality? Many of us have seen a presentation containing the picture in Figure 4-3. The idea is very appealing. No matter what application your server is running, you can start building a new copy from scratch as soon as anything goes wrong. This new copy comes on line automatically. However, if you think about what real world factors apply, you will realize that this kind of implementation is very complicated.

•Web Solution (6 Blades) ƒ Caching appliance Blade ƒ Load balancing appliance Blade ƒ Linux Apache Blades ƒ AIX WebSphere App Blades

1 1 1 1 1 1 2

2

2

3

3

4

4

5

•Collaboration Solution (3 Blades) ƒ Windows 2000 Domino Blades •Terminal Serving Solution (2 Blades) ƒ Windows 2000 Citrix MetaFrame Blades •File Serving Solution (2 Blades) ƒ Novell Netware V6 Blade ƒ Storage Blade •Spare Blade

Figure 4-3 Hot-spare blade server in a chassis

Clients would like to implement this scenario in an effort to be fault tolerant: should any piece of hardware fail, they can be ready to replace that server (thus experiencing only a short denial of services time). Hardware failures that would prevent the blade server from restarting immediately are typically very rare. These include circumstances when Chapter 4. Advanced scenarios

33

򐂰 The system board fails. 򐂰 The only processor fails. 򐂰 Both hard disks fail (assuming a disk mirroring technique is used). If your blade server configuration and business require uptime even if these rare situations occur, then you should consider a hot spare. If you also take into account the fact that clients usually use application-based load balancing/fault tolerant techniques, having a spare blade makes even less sense. Take a Web server farm as an example: if you have five servers running a Web service (like Microsoft IIS or Apache), losing one of those would result in a theoretical 20% performance decrease. This decrease is theoretical because this would imply a 100% load on each server. This is not usually the case. On the contrary, Web farms are usually sized to accommodate one server failure. Having said this, we can discuss a couple of options you have to implement a hot spare mechanism. 1. The first option is to use Director deployment wizard, which allows you to assign a profile to a chassis. Now, the only case that forces you to reinstall the blade server is losing the content of the hard disk drives (hopefully an extremely rare event). If you unplug the blade server from the chassis and insert a brand new one in the same slot, the MM will communicate this event to the management server (Director /RDM). Then, the assigned task will be executed against the new blade server. This method assumes that the RDM task contains all that is needed to start the application as soon as the task is finished, which could not be easy to achieve. Not always cloning or performing completely unattended installations is an option. Please note that since the new blade is in the same slot as the failing blade, there might be no need to reconfigure VLANs in network switches. Bear in mind, however, that if you connect the blade server to a SAN and you change the fibre channel adapters, you must reconfigure zoning and/or partitions to reflect the new World Wide Names of the adapters. 2. The second option would be to take advantage of the DIRCMD command line utility available with Director. The idea here is to select an event that could be an indicator of a failing blade, then run the corresponding RDM task against the blade that has been selected to be the hot spare. The problem now is that you do not have an Director action in the Event Action Plan builder capable of running a task against a selectable Director Object. In fact you only have the action “Run a task on the “event” system,” which cannot be used in our case. Usually a hardware failure would be communicated to the Director Server by the MM (so that the “event” system is not the physical platform corresponding to the blade server experiencing the problem). On the other hand, a software failure would be communicated to the Director Server by the Director agent object, again not the blade server physical platform. Hence, you’ll need to use DIRCMD to run the RDM task against the desired physical platform object. The command line to run an RDM task is the following: dircmd -s server -u userid -p password server runtask



You need to know the task id corresponding to the RDM task and the objid corresponding to the hot spare blade physical platform. In order to find the right object ID, you need to run the following command line: dircmd -s server -u userid -p password server listobjects

34

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

This will return something like Example 4-2: Example 4-2 Object ID output

28B 28D 285 286 287 288 28A

192.168.0.139 86873RX-551218F IBM 867821X 550027X IBM 86771XX 550012M IDSERVER IBM 86694RX 551175Y IBM 867821X 550027B

The first part of each line is the object ID corresponding to the object name (on the right-hand side). The RDM task ID can be found by typing the following: dircmd -s server -u userid -p password server listnoninteractivetasks The output will be something like Example 4-3: Example 4-3 Task ID output

job-id=27 [System Firmware Flash][Remote Deployment Manager][Deploy latest system firmware] job-id=20 [Donor Image][Remote Deployment Manager][Get Donor] job-id=26 [RAID Custom Configuration][Remote Deployment Manager][Express RAID Configuration] job-id=02 [Inventory] job-id=21 [Scan][Remote Deployment Manager][Basic Scan] When you have selected the job id corresponding to the task you want to run, the command line can be created. You’ll now have to customize the action Start a program on the server so that you run the correct command line against the right server. This kind of configuration is not only time consuming. It also is quite dangerous because all of the configurations external to the server such as Virtual Local Area Network (VLAN) and Storage Partitions need to be changed accordingly. We would recommend less automation but less risk. If you take advantage of application load balancing, a server failure should not yield an unaffordable outage.

Chapter 4. Advanced scenarios

35

36

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

A

Appendix A.

Additional material This Redpaper refers to additional material that can be downloaded from the Internet as described below.

Locating the Web material The Web material associated with this Redpaper is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to: ftp://www.redbooks.ibm.com/redbooks/REDP3776

Tip: The URL above is case-sensitive.

The additional Web material that accompanies this Redpaper includes the following file: 򐂰 CreateBladeGroups.zip Contains a Visual Basic script and readme. The script is used in 4.1, “Environments with multiple chassis” on page 28.

What the script does A dynamic group is created for each chassis registered in the Director database. Its name is the object ID given by the Director server to the BladeCenter, usually a three-digit number. In each group, you will find all the physical objects installed in the chassis and the corresponding Director agents installed on the servers. Director agents can be installed after the script is run. If new blade servers are inserted in the chassis after the script is run, you'll need to run the script again in order to reflect the new configuration in the group.

© Copyright IBM Corp. 2004. All rights reserved.

37

How to use the script You need to have dircmd.exe in the path. Therefore, you need one of the Director components installed on the machine you are running the script onto. Do the following: 1. Double click the script on a system running Windows. 2. You will be prompted for – Hostname or IP address of Director Server – Director user ID – Password When the scripts finishes, you will be notified that everything worked properly by a pop-up window stating that groups were created properly. Otherwise, you will be notified that something went wrong. The constant BLADETYPE refers to the four digit machine type code of the HS20, 8678. If you have new BladeCenter servers, you should change this value to reflect this. It this is wrong, the script will not do what you expect.

38

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this Redpaper.

IBM Redbooks For information on ordering these publications, see “How to get IBM Redbooks” on page 39. Note that some of the documents referenced here may be available in softcopy only. 򐂰 Implementing Systems Management Solutions Using IBM Director, SG24-6188

Other publications These publications are also relevant as further information sources: 򐂰 Bladecenter Planning and Installation Guide (based on RDM 3.x), available from http://www.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50254 򐂰 BladeCenter Installation and User’s Guide, 3rd Edition (based on RDM 3.x), available from http://www.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-45152 򐂰 IBM Director 4.1 - Systems Management Guide, available from http://www.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50461 򐂰 Remote Deployment Manager V4.1 publications, available from http://www.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-50575

How to get IBM Redbooks You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site: http://www.ibm.com/redbooks

Help from IBM 򐂰 IBM Support and downloads http://www.ibm.com/support

򐂰 IBM Global Services http://www.ibm.comservices

© Copyright IBM Corp. 2004. All rights reserved.

39

40

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1

Abbreviations and acronyms DHCP

Dynamic Host Configuration Protocol

DNS

Domain Name System

IP

Internet Protocol

LAN

Local Area Network

MM

Management Module

OS

Operating System

PXE

Preboot eXecution Environment

RDM

Remote Deployment Manager

SAN

Storage Area Network

SLP

Service Location Protocol

TCP/IP

Transmission Control Protocol/Internet Protocol

VLAN

Virtual Local Area Network

WAN

Wide Area Network

© Copyright IBM Corp. 2004. All rights reserved.

41

42

Managing IBM eServer BladeCenter Systems with IBM Director V4.1 and Remote Deployment Manager V4.1