| Sun Fire B10n Content Load Balancing Blade Version 1.2 Update Product Notes |     |
| Sun Fire B10n Content Load Balancing Blade Version 1.2 Update Product Notes | |
|
Sun Fire B10n Content Load Balancing Blade Version 1.2 Update Product Notes |
This document contains important information about the Sun Fire
B10n Content Load Balancing Blade Version 1.2 Update application software and the new server modules. This version includes all the features from Version 1.1, 1.2, and 1.2 Update. The application software is not changed with this release; only new server modules are provided.
|
Note - The current Sun Fire B10n content load balancing blades are shipped with the Version 1.1 software. This document explains how to upgrade your software to the latest version. |
|
Note - This document describes all of the new features for the Sun Fire B10n Content Load Balancing Blade Version 1.2 Update release. The administration guide is not updated for this release. |
Additional issues may arise after the publication of this version of the product notes. For the latest information, refer to the latest version of this document available at:
http://wwws.sun.com/products-n-solutions/hardware/docs/Servers/Workgroup_Servers/Sun_Fire_Blade_Platform/Sun_Fire_b100s/index.html
Software release 1.2 Update provides support for the following hardware and software:
The Sun Fire B10n content load balancing blade application software release 1.1 adds high availability pair blade failover and path failover as well as support for the Sun Fire B10p SSL proxy blade.
The rule build performance has been improved. The performance increase is up to five times faster than previous versions.
Supports no VLAN mode for Red Hat Enterprise Linux AS 2.1.
Software release 1.2 Update includes support for the following operating systems listed in TABLE 1.
Zip files are available at the Sun Download Center at the following URL:
http://wwws.sun.com/software/download/network.html
Enter B10n and select Search the Download Center. Select Sun Fire B10n Content Load Balancing. Zip files listed in TABLE 2 are available.
The Sun Fire B10n blade is a component within a larger system ultimately delivering highly available network 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 shows the intra-shelf network, where a Sun Fire B10n 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 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 rewriting their MAC addresses and their VLAN tags.
A service is identified by a 3-tuple comprising of 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. For example, two different VIPs can point to the same service. One of the initial steps in setting up the load balancer is to configure a service through the command line interface. Configurations can be input through the console interface by manual command line entry, scripted command sets or importing config files.
Load balancing or the server forwarding decision for a particular service is controlled by one or more rules. There are three basic types of rules, IP rules (layer 4), static HTTP and dynamic HTTP. An IP rule consists of source IP and source port, both have associated masks which enable subnets or port groups to be defined. Static HTTP (Layer 7) provides direct URL matching where as dynamic HTTP provides wild carding of various parameters. Rule matching is based on a priority match where priority is determined by rule type or assigned priority. If IP rule priority is Low, the order is HTTP static, HTTP dynamic, and IP rule. If IP rule priority is set to High, the order is IP rule, HTTP static and HTTP dynamic. The number of bits configured determines order within a rule type.
The next parameter in the server decision is the type of load balancing scheme. The schemes currently supported are round robin, weighted round robin, and static.
A service, load balancing scheme and servers are associated by creating a load balancing group using the lb-group command. 
For more details on command syntax for creating services, rules, and load balancing groups, refer to the Sun Fire B10n Content Load Balancing Blade Administration Guide.
To match the ample switching capacity of the SSC units in the Sun Fire B1600 blade platform 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 platform 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 4 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 following defines some common load balancing terms, and provides examples of their use.
Defined by the destination 3-tuple, that is, the destination VIP, port, and protocol.
Examples: *.html, /subdir/*, /subdir/*.html
Example: 129.47.29.0:2333/255.255.255.0:0
The use of VLANs within the Sun Fire B1600 blade system is preferred when using the Sun Fire B10p SSL proxy blade. VLANs are configured at the SSC switches to create logical groups of endpoints that can communicate as if they were on the same LAN. VLANs also prevent or restrict traffic between endpoints on separate VLANs. However, some environments might not support VLANs. To disable VLAN operation for the Sun Fire B10p SSL proxy blade, use the set vlan filter disable command from the CLI interface.
If you choose to use VLANs, refer to the Sun Fire B10n Content Load Balancing Blade Administration Guide for detailed information.
Before using the Sun Fire B10n blade, ensure your system meets the hardware and software requirements listed in TABLE 3. If you need a server module for a later operating system release check the Sun Download Center at:
http://wwws.sun.com/software/download/network.html
You can download the latest version of the sc firmware from the following web site:
http://wwws.sun.com/software/download/network.html
You need to set up a TFTP boot server to update the sc firmware. See the "Setting up a TFTP Server" section of the Sun Fire B10n Content Load Balancing Blade Administration Guide.
You can access all the Sun Fire B1600 documentation from the following web site:
http://www.sun.com/products-n-solutions/hardware/docs/Servers/Workgroup_Servers/Sun_Fire_b100s/index.html
1. At the sc prompt, enter the following command:
In the following example, 10.4.128.25 is the IP address for your TFTP boot server and stiletto.1.1/c8/SunFireB1600-sc-v1.1.6.flashSSC0/SC is the path to the file:
2. Reset the system using resetsc to load the new image.
It is important to verify that you have the latest software for the Sun Fire B10n content load balancing blade. Check the following web site for the latest software and documentation:
http://wwws.sun.com/software/download/network.html
You need to set up a TFTP boot server to update the sc firmware. See the "Setting up a TFTP Server" section of the Sun Fire B10n Content Load Balancing Blade Administration Guide.
You also need to configure the management IP address and default gateway address. Refer to the "Configuring the Networking" section of the Sun Fire B10n Content Load Balancing Blade Administration Guide.
|
Note - If you are updating both the B10n application software and BSC firmware, be sure to update the B10n application software first. |
With the B10n blade in the booted and running state perform the following steps:
1. Access the Sun Fire B10n console. At the Sun Fire B1600 SC console SC> type:
Where n is the slot number of the B10n blade
3. Verify the boot image and versions:
The B10n software can be loaded with three different images and booted. The three images are image 1, image 2, and diag. These images denote software versions.
To load to image location 1, the blade expects image filename to be available in the TFTP server. Where filename is sunfire_b10n.1.2.3
4. Determine which image to update (image 1 or 2), and update the empty or oldest image.
5. Update the B10n application software
You can upgrade the software either interactively or noninteractively.
As admin, type the following command:
The following image uses the TFTP server with the IP address of 192.50.50.201, the image name of sunfire_b10n.1.2.3, and the image at location 1.
The system returns the following output, verifying the parameters entered:
file exist! will overwrite /RFA0/BOOTIMAGE/boot_image_1 Start downloading sunfire_b10n.1.2.3... using TFTP Transferring and writing to file /RFA0/BOOTIMAGE/boot_image_1... please wait. puma{admin}# |
The following image uses the tftp server with the IP address of 192.50.50.201, the image name of sunfire_b10n.1.2.3, and the image at location diag.
The system returns the following output, verifying the parameters entered:
See the "To Update the Software Interactively" section of the Sun Fire B10n Content Load Balancing Blade Version Administration Guide.
1. Configure the desired Boot Image. At the B10n console type:
Where x is the image you just updated
2. Save the updated image using the commit command:
3. Reboot to activate the new image:
1. Escape to the system controller console by typing the pound sign (#) and period (.) in rapid succession:
|
Note - If the two characters are not typed in rapid succession nothing happens. |
2. At the sc prompt, check the current version of the BSC firmware:
sc> showsc -v FRU Software Version Software Release Date -------------------------------------------------------- S0 v5.1.4-SUNW,B10n,NetBlade1 Aug 12 2003 15:31:48 |
3. At the sc prompt, enter the following command:
Where TFTP_ip-addr is the TFTP server IP address, n is the slot number, filename is the file name of the image
In the following example, 192.50.50.201 is the IP address for your TFTP boot server and /tftpboot/525-2018-05-t2.a37:
4. Reset the system using resetsc to load the new image.
The upgraded B10n blade has the following features:
2. Two B10n boot images--version 1.0.1 and 1.1. The default boot image is 1.1.
3. The B10n bootrom, version 1.1.
3. Export the config tar file:
1. Power off the old board and remove it from the chassis.
2. Install the upgraded board.
The board comes up with an empty configuration with the B10n 1.1 application image running.
3. Configure the network interface. Optionally, configure the management VLAN (if applicable).
5. Import the 1.0 or 1.1 configuration:
6. Untar the configuration file.
7. Reboot the B10n blade to get the imported configuration:
|
Note - To run traffic with B10n 1.2 Update application image, the blade server module has to be updated to version 1.2 Update. |
Use the appropriate instructions for updating your Solaris or Linux servers.
1. Download the 1.2 Update version of the server module software from the following site:
http://wwws.sun.com/software/download/network.html
3. Install the SPARC Solaris server module software packages:
4. Restart the Solaris server module:
1. Download the 1.2 Update version of the server module software from the following site:
http://wwws.sun.com/software/download/network.html
3. Install the x86 Solaris server module software packages:
4. Restart the Solaris server module:
1. Download the 1.2 Update version of the server module software from the following site:
http://wwws.sun.com/software/download/network.html
Different Linux OS subdirectories are available, such as, RHAS_2.1, SLES_8.0, ... additionally, hardware platforms such as B100x, B200x and V60_65x are available.
3. Install the Linux server module for RHAS 2.1 Update 2, for example:
4. Restart the Linux server module:
|
|
1. Download the 1.2 Update version of the server module software from the following site:
http://wwws.sun.com/software/download/network.html
Different Linux OS subdirectories are available, such as, RHAS_2.1, SLES_8.0, ... additionally, hardware platforms such as B100x, B200x and V60_65x are available.
3. Upgrade the Linux server module for RHAS 2.1 Update 2, for example:
4. Restart the Linux server module:
This section outlines the known problems with the current version of the software and describes workarounds to overcome these problems.
One failing server could cause an NPU failure on the B10n blade.
Work Around: Find and remove the failing server. Allow the B10n blade to remain in idle with no traffic for 10 to 30 minutes or untill you see that the cleanup counters (dump module analyze 10) are no longer counting up.
When IP persistence and application monitoring are configured for a service, the load balancer does not behave as expected.
When the monitored application on a server fails, but the server remains up, no new client will be sent to this server. However, clients that have connected to the server and whose persistence entry has not timed out will continue to be sent to the server. To them, the service may appear to be down.
Workaround: Do not configure IP persistence and application monitoring for the same service.
The following example shows a typical output from the show arp command:
In the ARP table the gateway and flags columns are improperly shown. In the example above, 405 in the first line should be aligned under the flags heading.
Due to errors in Wind River's Rapid Control software, the following commands print the same output:
In addition, the correct syntax for these "config no" commands is as follows:
puma{admin}# config remove dns server ip-addr puma{admin}# config remove service service-name puma{admin}# config remove ssl puma{admin}# config remove path-failover |
System may panic if the content load balancing module (clbmod) is added to a "down" ce interface
Be sure the ce interface is "up" before you load clbmod.
If the load balancer VIP address is mistakenly used on another device, the other device broadcasts a gratuitous ARP and forces all of the clients and routers to learn that ARP entry.
Use the config vip-broadcast VIP-address mask command to force the load balancer to send a gratuitous ARP and force the clients and routers to relearn the VIP ARP entry as that of the load balancer.
This problem indicates a bad network configuration. The VIP address cannot be the same as the path failover target IP address. A future release will check for this condition.
An unknown filter edge occurs when the classifier.pm file in the
config/config_x directory is corrupted. This should not happen during normal operation.
Boot using the alternate configuration and remove the file
config/config_x/classifier.pm where x is the configuration boot up that fails and has a value of 1 or 2.
When adding an SSL service, using the same VIP address with a different port, but the same SSL port is not allowed. The new SSL service must have a unique port number. For example, if an initial SSL service is running on SSL port 880, you must specify a different SSL port number for each new SSL service such as SSL port 881, 882, and so on.
If a blade failover system comes up with an unknown failover state and without any rules or services, one of the following might have caused it:
Remove the failover configuration from the system with the following commands as admin in config mode:
puma(config){admin}# config remove failover puma(config){admin}# rm /RFA0/config/failover/config_x/failover/failover_cmd.conf |
If you still want to keep the blade failover configuration after the reboot, please refer to the "Configuring Failover" chapter in the Sun Fire B10n Content Load Balancing Blade Version Administration Guide.
|
Note - In all of the references to config_x, the `x' is 1 or 2 depending on whether your load balancing is currently using configuration directory config_1 or config_2. |
At boot time, you have the option of skipping the blade failover synchronization. During boot the system prints the following message and waits for 5 seconds for you to respond:
If both interfaces of the B10n device are configured in the same subnet and if one of the interfaces is unconfigured, there might be loss of network connectivity from the B10n device. The device might not be able to switch all servers to the alternate interface. This can cause server/SSL devices to be marked down, and they will not be used in the load balancing.
After unconfiguring the interface. Do a commit and then reboot the system.
The B10n software provides the following diagnostic tests:
If you must use the Gallop test, be sure to run it at night or on a week end when the system is not in use.
You may notice the following behaviors, which might be interpreted as being problems. However, they are normal behaviors.
If another system in the subnet is configured with the IP address used in the VIP of a service configured on B10n the networking for that system will not work because the clients and routers will learn one machine's MAC and the other machine will not receive any traffic on that VIP.
Because this is normal behavior, the only workaround is to ensure that you do not use duplicate VIP addresses.
The B10n software still allows the commit command even though no changes have been made to the configuration.
This problem causes no ill effects, so it can be noted and ignored.
If both interfaces are configured in the same subnet then in some scenarios it is possible that the default route to a server/SSL device might be down and the devices might be unreachable (ping fails) from B10n, but the monitoring shows them as up.
This is not a bug. The monitoring will switch to the alternate interface and try to reach the device. ping will only try the one default interface.
This section provides an example for configuring the Sun Fire B10n blade with VLANs in the enterprise. This section also provides a review of the VLAN capabilities of the Sun Fire B1600 blade platform and its components including B10n content load balancing blades and B10p SSL proxy blades. An example is provided using VLANs in a typical enterprise configuration including the commands to configure the individual components of the B1600 blade platform. Some knowledge of the B1600 blade platform and its components is required.
The enterprise model is used in this example because it best represents a common configuration and provides concepts that can be expanded or simplified as required. Because security is best deployed throughout the datacenter, this example describes how the B1600 blade platform and its components best fit into a large framework.
This section does not include details on the SSL or TLS security protocols. The SSL proxy blade offloads servers from compute intensive cryptographic processing and provides a secure centralized location for key and certificate administration and configuration. The decrypted traffic can be protected using VLANs and this section describes a suggested configuration for implementing a VLAN architecture.
The B1600 blade platform employs both logical and physical separation features to enable protection and isolation. The first level is the separation of management and data traffic. Management access can be attained either by direct Ethernet or serial connection to the System Service Controller (SSC) ports, or inband over the Ethernet switch fabric. The SSC uses a Layer 3 filter between the internal switch fabric and the system controller. An SSH agent is employed on the System Controller (SC) to provide authentication and cryptographic protection. The SSC is connected to each B1600 blade by redundant point to point serial connections providing an out of band path to each blade. Individual blade consoles can be accessed inband over the switch fabric as well. IEEE 802.1Q VLANs are available to logically separate the management traffic from the data traffic as well to segregate data traffic from different users.
When using the Sun Fire B10n content load balancing blade traffic can be divided into loadblancing groups and packets are forwarded based on services. Services can then be assigned a unique VLAN ID and the loadbalancer will tag traffic to the servers. If https is one of the types of traffic within a service the Sun Fire B10p SSL Proxy will return the decrypted ingress traffic to the B10n for the loadbalancing decision and will add the service VLAN tag before sending them to the server. When data leaves the servers headed for the client the packets are tagged with the data VLAN ID thus isolating this traffic from the service and management traffic. The following figure shows the configuration for our example and highlights the concepts described above.
Once traffic leaves the B1600 switch toward the external network the data VLAN tag can be either stripped or left and extended to the next hop router or firewall. Traffic ingress to the B1600 can be tagged by the router or firewall or can be tagged by the SSC.
While the diagram above is useful in understanding the VLAN membership concepts and logical packet flow it does not show the actual physical port connections. For example the Loadbalancer has one physical interface per switch. Therefore the switch interface must be configured to allow all three VLANs in our example. This is true for the SSL Proxy as well. The Server (or loadbalance group) interfaces must be configured with the management, data and its service VLAN IDs. In this way the this server is isolated from the other service traffic through the switches. It is important to know that the links between the blades and the switch are point to point therefore, the switch vlan filtering can prevent other vlan traffic from being forwarded to a particular link.
User Access levels are provided to restrict features from different administration users. The B1600 Service controller allows multiple username and password accounts. Users are assigned up to four user access privileges types u, a, c, r which allow setting user accounts (u), administration of system controller configuration (a), console access to blades and switches (c) and the ability to power on/off blades and reset them (r).
Once you have console access, the server blades provide Unix access level options based on the type of OS you are running. In general root access is required to configure the VLAN parameters.
For the B10n Content Loadbalancing Blade there are two levels, Level 1 is limited to read access to system information and status, Level 2 is full access.
The B10p SSL Proxy blade employs three levels, Service Officer (SO)which provides full access, Administrator which allows access to network configuration but does not allow access to keys or certificates and third is User which allows read access to some system information.
1. Ingress (RX) - Packets/Frames entering the device or network being described. In data/center or server centric discussions sometimes referred to as client side or client traffic. That is traffic transmitted by the client and received by the data center.
2. Egress (TX) - Packets/Frames leaving the local device or network. In data/center or server centric discussion it is traffic transmitted by the device or network and received by the client.
3. Native - Provided to allow network control traffic (like IGMP) to travel through VLAN enabled fabrics. From a switch perspective untagged ingress packets are tagged with a specified value and egress packets with a specified ID are sent untagged.
4. Allowed - If ingress filtering is enabled the switch will allow only tagged packets specified in the list for that port. If tagged is specified it will leave tags on egress. If untagged is specified it will strip tags on egress.
5. GVRP - VLAN Registration Protocol defines the way for switches to exchange information in order to automatically register members on interfaces across a network.
IEEE 802.1Q - Up to 256 VLANs - GVRP and manual configuration
|
Note - The switch supports Port and Hybrid VLAN configurations. All configurations in this example use Hybrid mode where tagged and untagged VLAN IDs are specified. |
(Default is all VLANs disabled)
Role is to decrypt incoming SSL traffic and encrypt outgoing SSL.
FIGURE 6 provides an example VLAN configuration of four VLANs.
For the enterpise example figure xxx shows a physical view including network links, Loadbalancer blade (LB), SSL Proxy blade (SSL), and two server groups each with a unique service (SVC1 & SVC2). One for Internet access and the other for Intranet traffic. VLANs IDs are only shown for the end points of the management network as this is common to all blades and switch ports. The load balancer and SSL Interfaces must be a member of all four VLANs. The Server Interfaces are members of management, data and a service VLAN. Below is a example of commands to configure the B1600 and its components based on the figure xxxx. The exception being we will not extend VLANs to the external firewall but configure the switch to untag the egress Data VLAN packets and Tag the Ingress Data VLAN packets.
The following four VLANs IDs will be used.
2. Data (or client side) VLAN ID 30
To configure the system the first step will be configuring the VLANs for the SSC. The external network or "client side" uplink ports (NETPx), the internal (SNPx) ports and the management ports configurations will be shown. The approach we will use for the uplink (NETPx) ports is enable ingress filtering allowing only untagged VLAN IDs. The SSCs employ the concept of "native" VLANs which allow incoming untagged packets to be tagged with the VPID or native tag and untag egress packets that contain the VPID. The approach we will use for the internal (SNPx) ports is to allow both service VLANs as well as the management and data VLANs for the Load balancer and SSL Proxy blades. Server blade ports also allow management and data VLAN, but only one service VLAN is allowed. If all elements are in the same shelf, this contains the service VLANs (and thus cleartext and other service traffic) within the B1600. If external servers (or multiple shelves) are used, these VLANs can be extended by adding these VLAN IDs on those uplink ports connected to the additional servers or shelves. GVRP will be used in this example.
The interfaces to configured on the switch are:
For details on SSC switch configuration see the Sun Fire B1600 Blade System Chassis Switch Administration Guide.
1. Go to the SSC console from the SC prompt.
Where n is either 0 or 1 for systems with redundant switches.
2. Type your user name and password.
User access needs to at least have [a] administration privileges set.
3. Configure the Management port (this step can be skipped if default vlan 2 has not been changed)
Console(config)#interface ethernet NETMGT Console(config)#switchport allowed vlan add 2 Console(config)#switchport native 2 Console(config)#switchport allowed vlan remove vlan id |
Where vlan id is the previously configured value.
5. Configure the Uplink ports.
|
Note - By default the gvrp is disabled for all ports. Anytime you change the port configuration you must include the no switchport gvrp command to restore gvrp. |
6. Configure this uplink port to untag egress packets for these VLANs.
7. Configure this uplink port to tag ingress untagged packets with this PVID.
8. Remove the default data VLAN.
Console(config-if)#switchport allowed vlan remove 1 Console(config-if)#switchport ingress-filtering Console(config-if)#exit |
Repeat this step for all uplink ports you want to include in the shared Data VLAN (30).
9. Configure the internal port for the Loadbalancer and SSL proxy blades.
Repeat the above instructions (10) for the SSL Proxy changing snp0 to snp1.
10. Configure the internal ports for the servers.
Repeat this sequence for the second server changing snp3 to snp5.
Repeat this sequence for the second service group changing the firs allowed VLAN form 10 to 20.
Service VLANs The B10n load balancers must be a member of all four VLANs. The management VLAN must be the same for all blades to be loadbalanced as monitoring messages go between them and the B10n. The two services will be named SVC1 and SVC2 for the two loadbalancing groups.
The steps to configure VLANs on the B10n are as follows:
1. Go to the B10n console from the SC prompt.
Where n is the slot number of the load balancing blade.
2. Type your user name and password.
User access privileges must be Level 2.
3. Enter the B10n configuration mode.
4. Set the management vlan and enable.
5. Set the data vlan and enable.
6. Set the service VLAN for SVC1 and enable.
|
Note - The service SVC1 and SVC2 must be configured prior to these commands. See the Sun Fire B10n Content Loadbalancing Administration Guide for details. |
puma(config){admin}# service vlan SVC1 vlan 10 puma(config){admin}# enable service vlan SVC1 puma(config){admin}# enable service name SVC1 |
7. Set the service vlan for SVC2 and enable.
puma(config){admin}# service vlan SVC2 vlan 20 puma(config){admin}# enable service vlan SVC2 puma(config){admin}# enable service name SVC2 puma(config){admin}# exit |
The SSL Proxy blade must be configured for all four vlans. The default is VLANs are enabled. If the blade has been configured and you are just adding VLANs you will begin by enabling VLANs.
1. Access the SSL proxy blade console from the SC command line interface.
Where n is the slot number for the SSL proxy blade.
2. Type your user name and password.
User access needs to be Security Officer (SO) or Administrator (admin).
|
Note - Non-zero VLANs tags cannot be set before vlans are enabled |
4. Configure the management VLAN.
5. Configure the data (client side) VLAN.
6. Configure the SVC1 Service VLAN.
7. Configure the SVC1 Service VLAN.
CLI# show vlan client client vlan: 30 CLI# show vlan manage port 1: vlan: 2 port 2: vlan: 2 CLI# show vlan inband port 1: vlan: 10 port 2: vlan: 20 CLI# show vlan filter vlan filter: enabled |
The command example here is for Solaris if Linux is being used the syntax will vary slightly but the concepts are the same.
The server must also be a member of three VLANs, the management, the data (client side) and service VLAN. The management VLAN is used to exchange configuration and monitoring messages between the content load balancing blade and the blade server. The service VLAN is used for all data traffic between the content load balancing blade and the blade server.
The route from the server to the client network must use the data (client side) VLAN. For security reasons, the server cannot bind any services to its IP address on this interface.
1. Go to the server blade console from the SC prompt.
Where n is the slot number of the server blade.
2. Type your user name and password.
User access privileges must be superuser.
3. Configure the data VLAN interface.
4. Configure the management VLAN interface:
5. Configure the SVC1 service VLAN interface:
6. Configure the VIP on the loopback interface:
The IP address on the service VLAN is never used in any traffic, however, a valid IP address must be configured.
7. Add all three interfaces to the load balanced interfaces:
# /opt/SUNWclb/bin/clbconfig add ce2000 # /opt/SUNWclb/bin/clbconfig add ce10000 # /opt/SUNWclb/bin/clbconfig add ce30000 |
8. Verify that the route to the default gateway uses interface ce30000.
The netstat -r command displays the routing table, including the default route.
Remove any other default route shown by netstat -r. Note that there are other ways to set the default route to use this interface. See the Solaris Administration Guide.
|
Note - If the physical interface used were connected to ssc1, the virtual interfaces would be ce2001, ce10001, and ce30001, respectively. |
The interface number for VLAN n on physical interface i is determined by the following formula: 1000 * n + i
Hence, the interface name for VLAN 123 on physical interface ce0 is ce123000
These steps need to be repeated for the other servers in the loadbalancing group. For the second loadbalancing group the VIP must be different and the service vlan changes from ce10000 to ce20000.
To Update the System Controller Firmware