| Sun Fire B10n Content Load Balancing Blade Administartion Guide |    
|
| Sun Fire B10n Content Load Balancing Blade Administartion Guide |
|
| C H A P T E R 1 |
|
Product Overview |
This chapter describes the Sun Fire B10n content load balancing blade hardware and software and lists both its features and the requirements for using it.
This chapter contains the following sections:
The Sun Fire B10n content load balancing blade is a networking product that provides content load balancing for Sun's blade-based servers and other horizontally scaled Sun platforms. It is designed to work in the management framework of the Sun Fire
B1600 blade system chassis. As part of the Sun Fire B1600 blade system chassis, the Sun Fire B10n content load balancing blade connects to the Sun Fire B1600 blade system chassis midplane through two Gigabit Ethernet interfaces. The blade offers Layer 4 through Layer 7 load balancing. The server decision can be based on IP protocol and TCP/UDP ports (Layer 4) or URLs, cookies, and CGI scripts (Layer 7). Both these functions can operate up to the two Gigabit full-duplex line rate.
The Sun Fire B10n content load balancing blade implements hardware assisted triangular load balancing, which enables the switch capacity to be used for aggregate responses rather than individual link capacity to the blade. To enable triangular data flow, you must install the application software on each Sun Fire B10n content load balancing blade and the blade server module on each Sun Fire B100s blade server.
From a logical perspective, the following components make up a Sun Fire B10n content load balancing blade:
The Sun Fire B10n content load balancing blade provides optimized server to client response. To support this response and provide tight communications between the content load balancing blade and the B1600 blade servers a software module must be installed on each of these servers. This software module is referred to as the Blade Server Module and is loaded using the Solaris package add process.
The content load balancing blade is based on specialized hardware including a general purpose microprocessor that runs a real time operating system. The code that runs on this processor is called the Application Software and can be updated using a TFTP process.
In addition to the general purpose processor there is a micro controller called the Blade Support Controller (BSC). The BSC is the primary interface to the Sun Fire B1600 Service Controllers (SC) and performs the Advanced Lights-out Management (ALOM) function for a given blade. These functions include powering on and off of the blades as well as monitoring functions. This is referred to as the BSC Firmware and can be updated using the "flashupdate" command which involves using TFTP.
The Sun Fire B10n software components:
Check the following web site to ensure you have the latest Sun Fire B10n software:
http://wwws.sun.com/software/download/network.html
The B10n has the capability to hold two versions of the Application Software and a diagnostic image. This allows a new image to be loaded without overwriting the active image. The blade must be rebooted to activate an image. See Choosing the Boot Image.
The B10n specialized hardware includes a rule based classification engine. The rules are entered through the command line interface and then compiled using a build process. See Creating an HTTP Load Balancing Rule.
Before using the Sun Fire B10n content load balancing blade, make sure your system meets the following hardware and software requirements:
The Sun Fire B10n content load balancing blade uses the following protocols for its services or management functions:
The Sun Fire B10n content load balancing blade is a component within a larger system ultimately delivering highly available web services to a client population over an IP-based network. This section describes the role of such a highly integrated content load balancer within the larger system.
The minimal set of components comprising the system encompasses:
Additionally, the system may have:
In general terms, the intra-shelf network topology formed by connecting the Sun Fire B1600 system components is either a single or a dual redundant Layer 2 topology with blades "one-arm" connected to each of the switch fabrics. The switch fabric is VLAN partitionable for strict traffic isolation. SSC switches and uplinks can be used for a simple inter-shelf network, or connected to external distribution switches for larger configurations.
FIGURE 1-1 shows the intra-shelf network, where a Sun Fire B10n content load balancing blade (shown in slot S8) can reside in any slot (S0 through S15) and connect to both SSC0 and SSC1 switch fabrics. The uplinks are labeled NETP0 through NETP7.
The numerals associated with each port (either 1 or 2), represent the VLAN numbers programmed into the system by default. The numbers indicate that there is one data VLAN (1), and one management VLAN (2). Further VLAN partitioning might be desirable as shown in FIGURE 1-2. The actual VLAN-ID assignment can be coordinated with the VLANs used in the external switches, or its scope can be limited to the internal switches, by keeping the uplinks as untagged VLANs.
The role of the content load balancer is to present a set of highly available network services. These services can be transported over http, TCP, or UDP, and are addressable through one or more Virtual IP addresses (VIPs), that the content load balancer is responsible for:
VIPs are the routable IP addresses that clients obtain for the service though DNS lookups. A VIP address is "owned" by one content load balancer at a given time. VIPs are preserved through the content load balancer all the way to servers. Requests are directed to servers by re-writing their MAC addresses and their VLAN tags (and optionally the TCP/UDP port values).
A service is identified by a 3-tuple comprising the VIP, the Layer 4 protocol value (TCP or UDP), and TCP/UDP destination port. A multi-homed service can be associated with more than one 3-tuple.
To match the ample switching capacity of the SSC units in the Sun Fire B1600 Blade System the content load balancer solution is designed to direct server responses toward clients without passing through the content load balancer. This enables the outbound capacity of the system to scale in proportion to the number of servers deployed, and to exploit the natural web traffic asymmetry where most of the traffic is server outbound.
To combine the uncompromised Layer 7 service performance with the direct server response, the content load balancing blade relies on a software module in each server. This server module contributes to the solution's high degree of integration by providing other key attributes, for example, path failover functionality.
The Sun Fire B1600 blade system switches are separate networks, leaving the system designer the option to connect them externally and create a symmetrically configured redundant system where every blade is dual-homed, or to leave the switches segregated for a system where full redundancy is either not necessary (or achieved elsewhere in the system hierarchy), and blades are single-homed to separate networks. You can also create intermediate configurations where critical blades (content load balancers, proxies, and so on) reside on shelves with dual switches, but blade servers do not.
When you connect SSC switches to create redundant paths, it is best if:
The above connections help ensure that the SSC switches are indeed leaf switches within the network infrastructure, and enable the content load balancer to use the shortest path within the redundant fabric (that is, the path that involves only one fabric).
FIGURE 1-3 illustrates nine shelves connected using a combination of distribution switches and internal SSC switches. Note that the SSC0 versus SSC1 fabric correspondence is preserved throughout the Layer 2 network, and that the fabrics are interconnected at the distribution switch level. In asymmetrical (capacity and hops) topologies like the one shown, it is also appropriate to house the content load balancing blades in shelves directly connected to the distribution switches.
Routers are shown for completeness as they represents the boundary of the Layer 2 network on the path towards the service clients.
The Sun Fire B10p SSL proxy blade is a companion product to the Sun Fire B10n content load balancing blade, and as such its role is briefly described in this section. SSL proxy blades are used to:
For every service the content load balancer can be configured with one or more SSL proxy blades supporting the SSL sessions of the given service. SSL requests are delegated by the content load balancer and processed after decryption. Outbound encryption requests are directed from the servers to the corresponding SSL proxy blade without going through the content load balancing blade.
The content load balancing blade, along with its server-side module, are responsible for the appropriate path selection, failover, and VLAN tag selection for SSL traffic. The resulting functionality is summarized by:
This book covers the configuration of SSL services at the content load balancing blade. Refer to the Sun Fire B10p SSL Proxy Blade Administration Guide for more information.
The service availability obtainable from a given system is a function of the intrinsic failure rates of its components and the automatic failover capabilities of the system itself. A system designed around Sun Fire B1600 blade system product family has the following service failover aspects:
1. Server failover--This is the ability of any load balancer to remove non-responsive servers from service groups so that new requests go to functional servers. This capability is based on the server-monitoring function.
2. Path failover--This is the ability of the system to use an alternate network path whenever the current path does not appear to work, because of cable, switch, link, or end-point faults. This type of failover tends to be transparent, in the sense that session state at all endpoints is still valid and usable.
3. Blade failover--This is the ability to deploy content load balancing blades in high availability (HA) pairs that monitor each other. For a given service one of the load balancing blades is a standby blade, identically configured to the active blade, and responsible for taking over in if the active blade fails. SSL blades do not monitor each other, and their failover is rather controlled by the load balancing blade monitoring them as if they were servers.
The system designer can decide which level of failover to design into the system:
The Sun Fire B1600 blade system can use IEEE 802.1q VLANs configured into its SSC switches to create logical groups of endpoints that can communicate as if they were on the same LAN, and equally importantly to prevent or restrict traffic between endpoints on separate VLANs.
Switches are responsible for VLAN enforcement, based on the VLAN Identifiers present on Ethernet packets (explicitly or implicitly), as well as the physical ingress and egress switch ports involved.
To the simple examples of data versus management separation already mentioned, or the web traffic versus backend network separation, we can add that in a multi-tenant environment it is also appropriate to separate traffic based on the service 3-tuple. A VLAN Identifier can be assigned by the content load balancing blade to identify the tenant (that is, the service owner), and thus ensure that its requests can only go to said tenant servers. In combination with the server side VLAN configuration, you can use VLANs to separate:
Although this book describes the administration of the Sun Fire B10n content load balancing blade at the lowest possible level, you may want to approach system integration (that is via CLI and scripting), it is certainly possible and desirable to achieve higher levels of integration abstraction with other Sun software products like N1 deployment, and SunOne Web and Portal Servers.
When considering system integration, the main Sun Fire B10n content load balancing blade considerations are:
The Sun Fire B10n content load balancing blade has two levels of user access:
Some of the commands are accessible only with the right user access level. Even within a single user access level, there are different command modes.
The examples in this book use the following format:
hostname(command_mode){user_name}# command |
puma{admin}# show user |
puma(config){admin}# ip interface 0 192.50.50.134 mask 255.255.255.0 |
| Sun Fire B10n Content Load Balancing Blade Administartion Guide | 817-0627-10 |
|
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.