Sun Fire B1600 Blade System Chassis Software Setup Guide
|
   
|
| Sun Fire B1600 Blade System Chassis Software Setup Guide
|
|
| C H A P T E R 1 |
|
Preparing to Configure the System Chassis |
This chapter provides an overview of the procedures for setting up the system chassis. It then introduces the system chassis and explains the roles of the System Controller and the switches. The remainder of the chapter (except the last section) tells you what you need to do before you configure the system chassis.
The last section tells you how to transition between the different user interfaces by using the #. escape sequence.
This chapter contains the following sections:
This section summarizes the procedures for setting up the system chassis.
1. Create a Network Install Server (for Solaris) or a PXE boot environment (for Linux or Solaris x86) for loading the operating system onto the server blades.
To install the operating system onto a server blade you must boot the blade from the network. Therefore, before you proceed to set up the software on the chassis you must do the following:
If you want to use dynamically assigned IP addresses for the components of the blade system chassis, see:
and refer to the supplementary information in Appendix B to complete the configuration of both your Network Install Server and the DHCP server on the data network.
2. Make sure you have a serial connection set up to one of the System Controllers in the chassis.
Alternatively, configure a DHCP server to supply IP configuration information to the System Controller. You can then access the System Controller by using telnet.
To set up a serial connection to one of the System Controllers on the chassis, refer to the Sun Fire B1600 Blade System Chassis Hardware Installation Guide.
3. Log into the System Controller and set a password and the date and time
You need to set a password and the date and time (see Chapter 2).
4. Log into and set at least one password for each switch
For information on how to do this, see Chapter 2.
To give yourself a working setup that can be refined afterwards, follow the instructions in Chapter 3 and, for B100x and B200x server blades, refer to the Sun Fire B100x and B200x Server Blade Installation and Setup Guide.
7. Power on the blades in the chassis and, if required (and if diagnostics are available), perform initial diagnostics on the blades.
To do this for the B100s blade, follow the instructions in Chapter 4. For B100x and B200x server blades, refer to the Sun Fire B100x and B200x Server Blade Installation and Setup Guide.
8. If you require, set up the system chassis for use in an environment that separates the data and management networks.
For B100s Solaris blades, follow the instructions in Chapter 5. These instructions tell you how use IPMP to take advantage of the presence of two switches in the chassis (if you have two SSCs installed).
For B100x and B200x blades, to take advantage of the presence of two switches in the chassis, refer to the Sun Fire B100x and B200x Server Blade Installation and Setup Guide.
9. If you require, set up the system chassis so that each blade has both a redundant connection to the data network (as described in Chapter 5) and a redundant connection to the management network.
For B100s blades, follow the instructions in Chapter 6.
For B100x and B200x server blades running Linux or Solaris x86, refer to the Sun Fire B100x and B200x Server Blade Installation and Setup Guide.
10. If you require, set up the system chassis so that different server blades are assigned to different owners, each of whom can manage his or her own blades without being able to access the System Controller, switches, or any other owners' blades.
To do this, follow the instructions in Chapter 7.
The Sun Fire B1600 blade system chassis is a 3-U high, 16-server chassis designed primarily for use by internet service providers. It is also suitable for use within corporate customer networks, wherever there is a need to maximize the density of high-performance servers.
As well as having the capacity for up to 16 server blades, the chassis contains two Power Supply Units (PSUs) and either one or two Switch and System Controller (SSC) units.
This manual, plus the Sun Fire B1600 System Chassis Software Setup Quick Start poster, and the Sun Fire B100x and B200x Server Blade Installation and Setup Guide (supplied as hard copy with chassis containing B100x and B200x blades) are designed to enable you - in the first instance - to set up a blade system chassis without needing to refer to the online manuals on the documentation and drivers CD supplied in the ship kit.
However, as well as online versions of all the hardcopy documents you received in the chassis ship kit, this CD includes:
The three main software components of the blade system chassis are the software for:
As you can see from FIGURE 1-1, a chassis can contain up to two SSC units. If you have two SSCs installed, then they conduct themselves in an active-standby relationhsip.
In the factory configuration of a chassis with dual SSCs, the System Controller in SSC0 is the "active" one, and the System Controller in SSC1 is the "standby" one.
If the SSC containing the active System Controller is physically removed or if its main software application undergoes a major failure, the standby System Controller (in the remaining SSC) automatically becomes active.
It is also possible from the active System Controller's command line to cause the standby System Controller to become the active one. For information about how to do this, refer to the Sun Fire B1600 Blade System Chassis Administration Guide.
In a future release of the System Controller software, the standby System Controller will automatically take over from the active one if it judges (as a result of its constant monitoring of the standby System Controller) that it is less fit than the other to perform the active role.
The System Controllers share an alias IP address and they can also each have a private IP address. The alias IP address is the address of the active System Controller, whichever that System Controller is. This address needs to be specified in the Name Service. When a System Controller takes the role of active System Controller, it assigns to itself the alias address and advertises itself (in a broadcast containing both its MAC address and the alias IP address) to the wider network as the device that owns the alias IP address.
For information about the relationship between the active and standby System Controllers, see Section 1.5.1, The Role of the System Controllers, and Appendix E.
If you assign a private IP address to each System Controller, you can use the private IP address (as an alternative to the alias IP address) if you want to telnet into the active System Controller.
You cannot telnet into the standby System Controller, even if it has a private IP address. However, it is useful to assign private IP addresses to the System Controllers (see Chapter 3), because it enables you (as network administrator) to perform a quick check of their presence on the network by pinging them individually.
The chassis can be run with one or two Switch and System Controller units installed. Although only one System Controller can be active at a time, the switches inside both SSCs are active all the time. This is an important feature of the blade system chassis's design. Each server blade has either two Gigabit network interfaces (one for each switch) or four Gigabit network interfaces (two for each switch). Therefore, in the event of a failure of network connectivity on one interface of a two-port blade, the other interface continues to provide service. Similarly, if for example a switch failed and a blade with four interfaces were in use in the chassis, the two interfaces connected to the second switch would continue to provide service.
For information about how to take advantage of:
|
Note - that in a chassis containing two SSCs, both switches are active all the time, even though only one System Controller is active at any one time. |
The B100s server blades are logically equivalent to standard Sun entry-level SPARC Solaris servers. All standard methods for network and sysid configuration (for example, TFTP and DHCP) are available for them, and so are the following methods of network installation for the Solaris Operating Environment:
For information about these methods of installing Solaris, refer to Chapter 3 of the Solaris 8 Advanced Installation Guide (supplied with the Solaris 8 12/02 media kit).
The B100x and B200x server blades are logically equivalent to standard Linux or Solaris x86 servers. They are designed to receive either operating system from a PXE boot environment and, once having done so, to boot from their own hard disk.
For information about providing a PXE boot environment and configuring the blade to boot from it, refer to the Sun Fire B100x and B200x Server Blade Installation and Setup Guide.
To use the B100x or B200x server blades, you need to use System Controller firmware version 1.2 (or later).
Download the latest version of the firmware from the following website:
http://wwws.sun.com/software/download/network.html
To perform the upgrade of the System Controller firmware, follow the instructions in the Sun Fire B1600 Blade System Chassis Administration Guide.
The Sun Fire B10n Content Load Balancing Blade is now available to provide load balancing across server blades in the Sun Fire B1600 Blade System Chassis and other horizontally scaled Sun platforms.
To use the B10n Content Load Balancing Blade, you need to use System Controller firmware version 1.1 (or later).
Download the latest version of the firmware from the following website:
http://wwws.sun.com/software/download/network.html
To perform the upgrade of the System Controller firmware, follow the instructions in the Sun Fire B1600 Blade System Chassis Administration Guide.
To configure and use the B10n Content Load Balancing Blade, refer to the Sun Fire B10n Content Load Balancing Blade Administration Guide.
The Sun Fire B10p and B15p SSL proxy blades are now available. These are hardware acceleration network systems that offload the SSL handshake and encryption/decryption functions from servers. The SSL proxy blade receives SSL encrypted traffic (typically HTTPS) from the client, decrypts the data, and sends it to the server (or to a virtual server port of a load balancer or switch). The server responses are sent to the SSL proxy blade, where they are encrypted and returned to the client.
To use the B10p or B15p proxy blade, you need to be running System Controller firmware version 1.2 (or later).
Download the latest version of the System Controller firmware from the following website:
http://wwws.sun.com/software/download/network.html
To perform the upgrade of the System Controller firmware, follow the instructions in the Sun Fire B1600 Blade System Chassis Administration Guide.
To configure and use the B10n Content Load Balancing Blade, refer to the Sun Fire B10p and B15p SSL Proxy Blade Administration Guide.
The active System Controller does two things: it communicates with the sub-components of the system chassis to monitor their operational status; and it provides a command-line interface (available over a serial connection or via telnet) to the main chassis configuration software called the "Advanced Lights Out Management Software". This software is an application that runs on the active System Controller in the chassis.
Chapter 2 of this manual tells you how to log into the Advanced Lights Out Management Software on the System Controller.
When you are logged in, you have access to:
For a detailed discussion of the relationship between the active and standby System Controllers, and of the limitations of this relationship, see Appendix E.
FIGURE 1-2 shows all the Ethernet Ports on each switch plus the Ethernet interfaces on each server blade. Each server blade has one interface to the switch in SSC0 and one interface to the switch in SSC1. The individual switches have a single port for each server blade. These are labeled SNP0 through SNP15. The data network uplink ports are labeled NETP0 through NETP7.
The diagram also shows the external RJ-45 port that is labeled NETMGT on the back panel of the SSC. This port provides an Ethernet connection, via a mini-switch (see FIGURE 1-2), to both the System Controller (indicated in the diagram by SC) and the switch. The external label NETMGT therefore describes both the switch and the System Controller management ports.
However, the functionality of the switch's NETMGT port is largely internal to the switch component of the SSC; and furthermore this functionality is distributed among several hardware and software entities inside the switch, including:
This distributed NETMGT port functionality provides user access to the switch's management applications. These applications (which provide a command-line interface, a web GUI, and an SNMP interface) also run on the switch controller. They enable you to configure the switch parameters. They also control the working of the switch.
The switch controller communicates with the switching fabric via an internal PCI bus, and it communicates with the outside world (in other words, with your management network) via a 100BaseT ethernet card (this is the AN 983 NIC). The 100BaseT ethernet card is connected to an internal five-port mini-switch (a Marvell 6051). Only three of the five ports on the mini-switch are used (see FIGURE 1-2):
This three-way connectivity provided by the mini-switch, therefore, enables users to access both the System Controller and the switch from the management network.
The internal mini-switch auto-negotiates the speed and duplex mode for its three ports at boot time. You cannot view information about the state of these ports from any of the switch's management application interfaces, and you cannot configure the ports manually. However, it is possible to connect a 10BaseT link to the RJ45 port (the external NETMGT port), although, if you do this, the management applications will still configure (and describe) the connection to the management network as a 100BaseT full-duplex link.
The switch controller is effectively acting as a bridge between the managment network (attached to the RJ-45 external NETMGT port) and the main switching fabric. However, for security reasons, the pseudo-port within the switching fabric will not bridge traffic to or from any of the uplink data ports.
The numbers 1 and 2 inside the Ethernet ports and SC interface in FIGURE 1-2 indicate the factory default VLAN[1] configuration for the switch ports. The default VLAN for the data network is VLAN 1. The default VLAN for the management network is VLAN 2.
The SC's VLAN Id is not configurable from the switch; it is configured as part of the interactive process of setting up the System Controller using the setupsc command (see Chapter 3). When you run this command you are asked a series of questions, including whether you want to enable a VLAN for the SC. If you answer yes, you are then prompted to specify a VLAN Id for the SC interface; the default is VLAN 2 in accordance with the default management VLAN on the switch. The SC interface is not a switch port. The effect of enabling VLAN support on this interface is to cause it to accept and transmit only frames tagged for the VLAN you specify for it.
As stated above, for security reasons, the pseudo-port within the switching fabric will not bridge traffic to or from any of the uplink data ports. This switching policy is enforced by the fact that it is not possible for any uplink data port to be a member of the same VLAN as the NETMGT port. The switch controller will not permit you to add the NETMGT port to any VLAN containing an uplink data port, or to add any uplink data port to a VLAN containing the NETMGT port.
The packet filter in FIGURE 1-2 is in the first instance a barrier between the internal NETMGT port and all of the server blade ports. It protects your management network from attack by external users accessing the blades through the data network.
By default, no network traffic is allowed to pass between the server blades and the NETMGT port on the switch. However, you can permit certain traffic to pass through the packet filter by specifying rules concerning particular protocols. For information about how to do this, see Appendix A.
The server blades provide the computing power to run software applications. Their primary means of I/O (input/output) is the network, although you can console into them from the System Controller's command-line interface by means of an internal serial connection between the System Controller and each blade.
The single processor blades have one Gigabit Ethernet interface to each of the chassis's two internal switches; the dual-processor blades have two Gigabit Ethernet interfaces to each internal switch. The switches also provide Gigabit Ethernet interfaces to the external network.
Blades typically have local disk storage to hold Operating System software and configuration information. It is not expected that customers will store user data on the blades' local storage devices but will use remote storage facilities instead.
In their factory default state, the B100s (SPARC) Solaris blades boot using an Operating System stub stored on the local hard disk. When this has booted, the blade searches for a Network Install Server on your network from which to install the Operating System. When you have booted the first B100s server blade from the Network Install Server, you can add the application software you intend to run on the blade, then follow the instructions in the Solaris Advanced Installation Guide to create a Web Start Flash Archive. Using Web Start Flash Archives on the Sun Fire B100s Solaris server blades (in the Sun Fire B1600 Blade System Chassis) enables you to replicate one blade's operating system and application software on other blades. It therefore speeds up the process of configuring a whole chassis of server blades. For more information about using Web Start Flash Archives, see Appendix C.
In their factory default state, the B100x and B200x (Linux and Solaris x86) blades need to be configured to boot temporarily from the network (see Chapter 4 of this manual) so that they can install their operating system from a PXE boot environment. For instructions about installing Linux or Solaris x86 from a PXE boot environment, refer to the Sun Fire B100x and B200x Server Blade Installation and Setup Guide.
To perform the initial configuration when you have installed and applied power to the blade system chassis, you must either set up a serial connection to SSC0 (by default, the active System Controller) or you must set up a DHCP server to perform the IP configuration of the chassis's active System Controller automatically. If you set up a DHCP server to do this, you can then telnet into the active System Controller to set up the chassis for the first time.
For information about the cabling for setting up a serial connection, refer to the Sun Fire B1600 Blade System Chassis Hardware Installation Guide.
For information about using a DHCP server, see Section 1.8, Using a DHCP Server to Provide the SSC IP Addresses Automatically.
However, for day-to-day operation of the blade system chassis, we recommend you set up serial connections to both SSCs. This ensures that, if the active SSC fails for any reason, you do not lose serial connectivity to the chassis.
Chapter 2 and Chapter 3 of this manual tell you how to configure the chassis when you have set up a serial or telnet connection to SSC0 (assuming that SSC0 contains the active System Controller).
To enable your network environment to receive a Sun Fire B1600 blade system chassis, you need to configure it to provide an alias IP address for the active System Controller, plus an IP address, netmask, and default gateway for each of the Ethernet interfaces on the chassis.
The alias IP address for the System Controller is specified in the Name Service, but the System Controllers can also have a private IP address each (you do not need to specify this in the Name Service). When a System Controller takes the role of active System Controller, it assigns to itself the alias IP address and advertises itself (in a broadcast containing both its MAC address and the alias IP address) to the wider network as the device that owns the alias IP address.
A chassis that is fully populated with server blades and two SSCs uses at least 37 IP addresses (including the two private SC addresses):
1. An alias IP address for the active System Controller (this is the address used by the active System Controller, whether it is the System Controller in SSC0 or SSC1).
2. A private IP address for the System Controller in SSC0.
3. A private IP address for the System Controller in SSC1.
4. An IP address for the switch in SSC0.
5. An IP address for the switch in SSC1.
6. 16 IP addresses for the ce0 or bge0 primary (Gigabit Ethernet) interfaces on B100s or B100x blades (assuming 16 blades in the chassis), or eight IP addresses for the primary blade interfaces in a chassis full of B200x blades.
7. 16 IP addresses for the ce1 secondary (Gigabit Ethernet) interface on B100s blades (assuming 16 blades in the chassis), none for the bge1 secondary interface on B100x blades running Linux (the Linux "master driver" software that handles all interface management requires only a primary IP address), or eight IP addresses (assuming eight B200x blades in the chassis) for the second, third, and fourth interfaces on B200x blades running Solaris x86.
If you intend to perform any of the chassis configurations (using B100s blades) described in Chapter 5, Chapter 6, or Chapter 7, each of which involves the use of the Internet Multipathing (IPMP) facility, you will require more than 64 IP addresses for the blades in a fully populated chassis.
For information about configuring redundant network connections on Linux and Solaris x86 blades, refer to the Sun Fire B100x and B200x Server Blade Installation and Setup Guide.
By default, the System Controller inside the active SSC will attempt to discover from a DHCP server the IP configuration information both for itself and for the standby System Controller.
The switches inside each SSC will also by default attempt to discover their IP configuration information from a DHCP server.
The System Controllers use a maximum of three IP addresses:
Each switch requires one IP address.
|
Note - If you intend to enforce the separation of your data and management networks, the DHCP server you use to configure the SSCs needs to be on the management network, and the DHCP server you use to configure the server blades needs to be on the data network. For information about configuring a DHCP server to provide the IP addresses for the server blades, see Appendix B. |
The active System Controller sends a DHCP request for three IP addresses (SSC0, SSC1, and an alias IP address).
Each switch sends a DHCP request for one IP address.
If you want to use five "consistent" IP addresses (that is, five IP addresses that will not change), you must associate five specific addresses on the DHCP server with the client identifiers for the System Controllers and switches.
Client identifiers exist for the System Controllers individually (as well as for the active System Controller, whichever that one is) because the System Controllers can each have an optional private IP address. (It is useful to allocate private IP addresses, because it enables network administrators to ping them to check their presence on the network.)
The client identifiers for the System Controllers and switches in the chassis are listed in TABLE 1-1.
(An alternative way to find the chassis serial number is to run the showfru ch command on the System Controller's command line and inspect the field for /ManR/Sun_serial_No.)
Using the instructions in the Solaris DHCP Administration Guide for creating "consistent" IP addresses, configure a DHCP server on the same network as the SSCs to provide a block of five IP addresses mapped to the client identifiers listed above. Make a note of the IP address you map to each client identifier. You will need to know this in order to telnet into the active System Controller or into either of the switches. You will also need to know it if you want to access the web-based Graphical User Interface to the switches.
If you do not want to provide "consistent" IP addresses for the System Controllers and switches in the chassis, you can configure the DHCP server to provide a block of dynamic IP addresses. These will be bound to the client identifier after the devices have made their DHCP requests. For instructions on how to do this, refer to the Solaris DHCP Administration Guide (806-5529).
If you configure the DHCP server to provide a block of dynamic IP addresses, you will have to find out which IP address it has allocated to the System Controller and to the two switches, before you can telnet into the System Controller or either of the switches and before you can access the web-based Graphical User Interface to the switches (see Section 1.8.3, Finding out the Chassis's IP Addresses to Enable You to Use Telnet).
If you want to log into the active System Controller for the first time over telnet (instead of by using a serial connection), and you have allocated dynamic (instead of "consistent") IP addresses to the chassis components, you will need to find out the IP address that your DHCP server has allocated to the System Controller.
If the DHCP server you are using is a Solaris system, you can use the pntadm command to list all the devices, with their corresponding IP addresses, on the network containing the chassis.
Key to sample output:
1. Client ID of active System Controller
2. Client ID of switch in SSC0
3. Client ID of switch in SSC1
where network address is the network address of your management network. The devices in the list are each identified by a hexadecimal string representing their client identifiers.
In the example, the first device listed is the active System Controller (which is the one using the alias IP address), the second is the switch in SSC0, and the third is the switch in SSC1. You need to translate the hexadecimal strings in your output into their alpha-numeric equivalents in order to see which device has been allocated which client IP address.
(Note that in the sample output two columns of information to the right of the "Lease Expiration" column have been omitted for lack of space. These are the "Macro" and "Comments" columns.)
To telnet into the active System Controller when you have configured a DHCP server to provide the IP addresses required:
1. If your chassis is already powered, you need to power cycle the chassis by removing the IEC power cables.
2. When the chassis is powered, type the following at a remote terminal:
where alias ip address is the IP address of the active System Controller. (Alternatively you can specify a host name on the command line.)
Before proceeding to configure the chassis, you will find it useful to have a note of the escape sequence for returning to the System Controller's sc> prompt from a blade or switch console. The sequence is #. (that is, the hash `#' character, followed by the dot `.' character).
When you are following the instructions in this manual, it is from the sc> prompt that you will need to access the server blade and switch consoles.
Proceed to Chapter 2 to perform the preliminary setup tasks for the system chassis.
| Sun Fire B1600 Blade System Chassis Software Setup Guide
|
817-4603-11 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.