C H A P T E R 11 |
Configuring IPMP for Network Resiliency on Solaris x86 Blades |
This chapter contains the following sections:
This chapter modifies and supplements the information available in Chapter 5 of the Sun Fire B1600 Blade System Chassis Software Setup Guide. Please read that chapter before following the instructions in this one.
The instructions in this chapter enable you to deploy a chassis containing Solaris x86 blades in a configuration that:
The next section (Section 11.2, How IPMP Works on B100x and B200x Blades) tells you how IPMP works on an x86 blade in the B1600 chassis. It states (and explains) the number of IP addresses each blade (B100x or B200x) needs for the type of configuration you require.
Before you can set up IPMP on a blade, you need to reconfigure the blade to make it stop using DHCP. The DHCP configuration was required to enable you to install the operating system; instructions for migrating the blade to a static IP configuration (in preparation for IPMP) are provided in Section 11.3, Migrating From DHCP to Static IP Addresses.
Finally, instructions for configuring IPMP on a blade are provided in:
The instructions in this chapter tell you how to use the Solaris IP Network Multipathing (IPMP) facility to take advantage of the redundant connections from each server blade to the switches in the chassis. A B100x blade's two 1000Mbps Ethernet interfaces are labeled respectively bge0 and bge1 (bge0 is connected to the switch in SSC0, and bge1 is connected to the switch in SSC1). A B200x blade's four 1000Mbps Ethernet interfaces are labeled respectively bge0, bge1, bge2, bge3 (bge0 and bge1 are connected to the switch in SSC0, and bge2 and bge3 are connected to the switch in SSC1). When the Sun Fire B1600 blade system chassis is fully operational, both switches are constantly active.
The IPMP driver on a server blade works by periodically pinging the default gateway from each Ethernet interface using a test IP address. The test addresses are used privately by the IPMP driver for the ping process. If for any reason one of the pings fails (indicating that the path to the network is no longer available on the interface that was used to perform the ping) the IPMP driver ensures that network traffic uses only the interface or interfaces that remains valid. Both interfaces on a B100x blade, or all interfaces on a B200x blade, can be active. This is referred to as an active/active configuration.
Alternatively the interfaces can be configured in an active/standby configuration in which one interface on the blade is active and the other one (on a B100x blade) is a standby interface, or (on a B200x blade) the other three are standby interfaces. In this type of configuration, if the failed interface is the active one, the driver assigns the IP address to the standby interface (or one of the standby interfaces), and that interface becomes the active one.
Because both switches inside the chassis are active (when the chassis is working normally), the instructions in this chapter tell you how to perform an active/active configuration. This maximises the performance of the chassis by ensuring that no interfaces are idle. For information about performing an active/standby configuration, refer to the IP Network Multipathing Administration Guide (816-0850).
The IP addresses you require for each blade to support the active/active configuration are:
The active IP addresses can be registered on a Name Server. They are the addresses by which other devices on the network communicate with the blade.
Test addresses are required (one per interface) for the ping process. These addresses are private to the IPMP driver (they are not registered on the Name Server).
In the next chapter, instructions are provided for setting up multiple pairs of virtual IPMP interfaces, each pair providing redundant virtual connections to separate VLANs.
To install Solaris x86 onto a blade, you need to use DHCP as described in Chapter 10 (the PXE installation process depends upon it). However, if you want to use IPMP, you must stop using DHCP because it is not possible to configure a DHCP Server to support IPMP data and test addresses and grouping.
This section tells you how to make the blades use static IP addresses instead of addresses assigned by DHCP.
1. Make sure the addresses you intend to use for the blade or blades are not already in use by another device.
The addresses you use must be ones that cannot be assigned to another device by a DHCP server on the same subnet as the blade you are configuring. Either reserve the addresses in your DHCP configuration or use addresses for the blade or blades that are outside the range of addresses managed by the DHCP server.
For information about reserving addresses on the DHCP server, refer to the Solaris DHCP Administration Guide.
2. On each blade for which you are configuring one or more static addresses, remove or rename the files /etc/dhcp.interface, where interface is bge0 and bge1 (plus bge2 and bge3 for a B200x blade).
3. Edit the /etc/hosts file on the blade to define the IP addresses for the interfaces on the blade.
For purposes of illustration, the instructions in this chapter assume a base hostname of "medusa" for the chassis being configured. Various suffixes are then added to this base hostname to indicate an individual component or a network interface on a particular blade.
For example, for a B100x blade you will need entries in the /etc/hosts file that are similar to those in CODE EXAMPLE 11-1:
127.0.0.1 local host 192.168.1.151 medusa-s1 loghost # first interface 192.168.1.152 medusa-s1-1 # second interface |
For a B200x blade you will need entries in the /etc/hosts file that are similar to those in CODE EXAMPLE 11-2:
4. On the blade, create an /etc/nodename file that contains the blade's hostname.
This will normally be the name used by the first network interface as specified in the /etc/hosts file (see Step 3). For example, if the blade's hostname is medusa-s1, the /etc/nodename file needs to contain the following information:
5. On the blade, create a hostname.interface file for each interface, where interface is bge0 and bge1 (plus bge2 and bge3 for a B200x blade).
For a B200x blade you will need hostname.bge2 and hostname.bge3 files as well.
6. Disable routing, because the server blade is not being used to perform routing:
7. If your network routers do not advertise their presence to network devices, create an /etc/defaultrouter by typing the following command:
8. where ip-address is the IP address of the router on the same subnet as the blade. For example, if the IP address of the default router were 123.123.123.8, you would type:
9. Reboot the blade to make it boot with its new static IP configuration:
This section tells you how to configure IPMP on a B100x server blade with two interfaces so that both interfaces actively transmit and receive data.
Note - Before following the instructions in this section, make sure you have performed the steps required in Section 11.3, Migrating From DHCP to Static IP Addresses. |
Note - You need to perform the instructions in this section on each B100x server blade that requires a redundant connection to the network. |
1. Log in as root to the console of the server blade whose interfaces you want to configure.
Type the following at the System Controller's sc> prompt:
where n is the number of the slot containing the server blade you want to log into.
2. Edit the /etc/hosts file on the server blade to add the blade's two test IP addresses.
3. Set the netmask in the server blade's /etc/netmasks file for the IP addresses of the interfaces on the blade.
4. If you have not already done so, disable routing because the server blade is not being used to perform routing:
5. In the /etc directory, create a hostname.bge0 and a hostname.bge1 file.
medusa-s1 netmask + broadcast + group medusa_grp0 up \ addif medusa-s1-test0 deprecated -failover netmask + broadcast + up |
medusa-s1-1 netmask + broadcast + group medusa_grp0 up \ addif medusa-s1-test1 deprecated -failover netmask + broadcast + up |
6. Reboot the blade so that it boots with its new IPMP configuration:
7. Inspect the configuration of the four network adapters:
The output above shows that four addresses have been defined. The two IPMP test addresses (associated with bge0:1 and bge1:1 respectively) are marked NOFAILOVER. This means that they will not be transferred to the surviving interface in the event of a failure.
8. Test that the IPMP configuration works by temporarily removing one SSC from the chassis.
This will cause error messages similar to the following to appear on the console:
This section tells you how to configure IPMP on a B200x server blade with four interfaces so that all interfaces actively transmit and receive data. The section provides two different methods of achieving network resiliency using an active/active configuration.
Note - that the achievement of network resilience (enabling a blade to recover from different hardware and network failures) depends upon each IPMP group containing one connection to each switch. A configuration in which both interfaces in a group of two were connected to the same switch would not continue to transport network traffic if that switch failed. In Section 11.2, How IPMP Works on B100x and B200x Blades, we saw that bge0 and bge1 are connected to switch 0, and bge2 and bge3 to switch 1. This is also shown in FIGURE 11-2. |
Note - Before following the instructions in this section, make sure you have performed the steps required in Section 11.3, Migrating From DHCP to Static IP Addresses. |
Note - You need to perform the instructions in this section on each B200x server blade that requires a redundant connection to the network. |
1. Log in as root to the console of the server blade whose interfaces you want to configure.
Type the following at the System Controller's sc> prompt:
where n is the number of the first slot (of the two) containing the double-width blade you want to log into.
2. Edit the /etc/hosts file on the server blade to add the blade's two test IP addresses.
3. Set the netmask in the server blade's /etc/netmasks file for the IP addresses of the interfaces on the blade.
4. If you have not already done so, disable routing because the server blade is not being used to perform routing:
5. In the /etc directory, create a hostname.bge0 and a hostname.bge1 file.