| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide |    
|
| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide |
|
| A P P E N D I X B |
|
Tutorial and Examples |
This appendix provides a tutorial for configuring the Sun Fire B10n blade. It includes the following sections:
A maximum of two load balancing configurations can be stored in the B10n blade. You can export any or all of this configuration to a remote host. You can also import a configuration residing on a remote host onto the B10n blade.
Before exporting a configuration directory, the right directory needs to be compressed using the tar command. The following table shows the files or directories to be compressed and exported as needed.
|
1. As admin, type the following command:
3. Enter the export file command and respond to the prompts:
|
1. As admin, type the following command:
2. Enter the import file command and respond to the prompts:
4. Reboot the system for the new configurations to take effect.
|
Caution - Do not do a commit before reboot because that would overwrite the imported configuration in flash with the one in memory. |
Use the following procedures to set up the networking configurations.
1. As admin in config mode, configure the IP address on interface 0:
2. As admin in config mode, configure the IP address on interface 1:
As admin in config mode, configure the default gateway:
As admin in config mode, configure the primary DNS server:
As admin in config mode, configure the DNS suffix:
1. As admin in config mode, configure a Layer 4 service:
2. Verify that the service is configured:
|
|
1. As admin in config mode, configure the default server:
puma(config){admin}# service lb-group default svcL4 server 192.50.50.10:80:tcp:5:1 192.50.50.11:80:tcp:2:0 |
2. Set the standby server to active:
puma(config){admin}# modify service lb-group server svcL4:default server 192.50.50.11:80:tcp mode active |
3. Verify that the servers are configured in the service:
5. Configure the VIP 199.99.9.1 on the loopback interface of the blade servers 192.50.50.10 and 192.50.50.11. Install the blade server load balancing packages and configure the blade server for load balancing. Refer to Configuring the Blade Servers.
1. As admin in config mode, add another server to the default load balancing group:
2. Verify that the server was added:
3. Configure the VIP 199.99.9.1 on the loopback interface of the blade servers 192.50.50.12.
1. As admin in config mode, remove a server from the default group:
2. Verify that the server has been removed:
1. As admin in config mode, add a Layer 4 rule to the system:
2. Verify that the rule was added:
4. Verify that the service was created:
5. Add two blade servers to the default load balancing group for the service:
puma(config){admin}# service lb-group default svcL4-r server 192.50.50.10:80:tcp:1:1 192.50.50.11:80:tcp:1:1 |
6. Configure the VIP 199.99.9.2 on the loopback interface of the blade servers 192.50.50.10 and 192.50.50.11.
7. Associate the Layer 4 service with a rule and a group of servers:
puma(config){admin}# service lb-group name IP-GRP service svcL4-r server 192.50.50.13:80:tcp:5:1 192.50.50.14:80:tcp:5:1 rule IP scheme wt-round-robin |
8. Configure VIP 199.99.9.2 on loopback interfaces of server 192.50.50.13 and 192.50.50.14.
9. Verify that the service is configured:
|
Note - Don't run traffic to this service yet, wait for the build to return with completion status. |
When the build is completed, the completion message is printed out. Once you receive the completion message, you are ready to run traffic.
You can now run traffic from clients to the Layer 4 service 199.99.9.2 and the load is balanced between the blade servers in the following fashion depending on the source IP address and Layer 4 port.
1. As admin in config mode, create a Layer 7 service:
2. Add 2 servers to the default group
puma(config){admin}# service lb-group default svcL7 server 192.50.50.15:80:tcp:10:1 192.50.50.16:80:tcp:10:1 scheme wt-round-robin |
4. Configure the VIP 199.99.9.3 on the loopback interface of the blade servers 192.50.50.15 and 192.50.50.16.
1. As admin in config mode, add a Layer 7 rule to the system:
2. Verify that the rule was added:
puma(config){admin}# service name svcL7-r vip 199.99.9.4:80:tcp interface 0 lb-layer 7 L7-proto http |
4. Add two servers to the default group:
puma(config){admin}# service lb-group default svcL7 server 192.50.50.10:80:tcp:1:1 192.50.50.13:80:tcp:1:1 |
5. Associate the Layer 7 service with a rule and a group of servers:
puma(config){admin}# service lb-group name URL-GRP service svcL7-r server 192.50.50.11:80:tcp:5:1 192.50.50.12:80:tcp:5:1 rule HTML scheme wt-round-robin |
6. Verify that the service was configured:
8. Configure the VIP 199.99.9.4 on the loopback interface of the blade servers 192.50.50.10, 192.50.50.13, 192.50.50.11 and 192.50.50.12.
|
Note - Don't run traffic to this service yet, wait for the build to return with completion status. |
When the build is completed, the completion message is printed out. Now we are ready to run traffic.
You can now run traffic from client(s) to the Layer 7 service 199.99.9.4. The service is load balanced between the blade servers in the following fashion depending on the URL of the HTTP request:
11. Add a CGI rule to the system:
12. Associate the Layer 7 service with the CGI rule and a group of servers:
puma(config){admin}# service lb-group name CGI-GRP service svcL7-r server 192.50.50.14:80:tcp:5:1 192.50.50.15:80:tcp:5:1 rule CGI scheme wt-round-robin |
13. Configure the VIP 199.99.9.4 on the loopback interface of the blade servers 192.50.50.14 & 192.50.50.15.
14. Add a Cookie rule to the system:
15. Associate the Layer 7 service with the Cookie rule and a group of servers:
puma(config){admin}# service lb-group name CK-GRP service svcL7-r server 192.50.50.16:80:tcp:5:1 192.50.50.17:80:tcp:5:1 rule COOKIE scheme wt-round-robin |
16. Configure the VIP 199.99.9.4 on the loopback interface of the blade servers
Rules do not take effect until you issue a build rules command.
After the build returns with the completion message, you can run traffic to this service in the following manner:
|
Note - If you plan to load balance SSL traffic using one or more SSL proxy blades with the Sun Fire B10n content load balancing blade, you MUST use VLANs on the Sun Fire B10n blade, the Sun Fire B100s, and the SSL proxy blades. Also note that a router is also required for the SSL proxy blade setup. Please refer to Setting Up VLAN and The Role of VLANs. |
|
2. Add a Port Pair to the SSL Device.
4. Check the SSL device configuration.
If you have an additional SSL device that needs to be created, repeat steps 1 to 4.
If more than 1 SSL devices was created, the additional SSL devices should be listed under this command also.
|
1. As admin in config mode, create a Layer 7 service with SSL:
puma(config){admin}# service name svcL7-SSL vip 199.99.9.4:443:tcp ssl 880 interface 0 LB-layer 7 L7-proto http |
2. Add servers to default group:
puma(config){admin}# service lb-group default svcL7-SSL server 192.50.50.17:443:tcp:10:1 192.50.50.18:443:tcp:10:1 scheme wt-round-robin |
|
1. Add the SSL device to the service:
2. Check the service to see if the SSL device has been added.
|
1. As admin in config mode, add IP persistence to a service:
This adds IP persistence to the service where the source IP mask is specified as 8 bits and the inactivity timeout is specified as 20 minutes.
You can now run traffic from client 192.50.50.200, and depending on the rules, it is load balanced to a particular blade server, for example, server 192.50.50.13.
Any subsequent traffic from any client in the subnet 192.50.50.0 is sent back to the same server, that is, 192.50.50.13, without any load balancing. Thus the service is now "persistent" for the subnet 192.50.50.0. If no traffic is received from the 192.50.50.0 subnet for svcL4-r for 10 minutes, then the persistence expires. Now the first connection from a client in the 192.50.50.0 subnet, say 192.50.50.185, is load balanced again and it goes to server 192.50.50.11.
|
Note - Short timeout values do not have the expected result. Timeout values should be at least 15-20 minutes, and the granularity of timing out entries is in the order of 10 minutes. |
|
As admin in config mode, remove IP persistence from a service:
|
As admin in config mode, add port tracking to a service:
This example adds port tracking to the service where the tracking port is specified as 443 and the inactivity timeout is specified as 20 minutes.
Now when you run traffic from client 192.50.50.200, depending on the request, it is load balanced to a particular back end server, for example, server 192.50.50.13. Any subsequent traffic from the same client destined to the VIP 199.99.9.4 and port 443 is sent back to the same server, that is, 192.50.50.13, without any load balancing. Thus the traffic to port 443 now tracks the primary service. If no traffic is received from 192.50.50.200 for svcL7-r on port 443 for 20 minutes, then the tracking expires. Now the first connection from 192.50.50.200 to the VIP 199.99.9.4 and port 80 will be load balanced to say server 192.50.50.10 and any subsequent connections from the same client, destined to either 199.99.9.4:80 or 199.99.9.4:443 go back to the same server.
|
As admin in config mode, remove port tracking:
|
1. As admin in config mode, add an end point tracking to a service:
This example adds end point tracking to the service where the tracking end point is specified with IP 199.99.9.5, port 8080 and protocol TCP, and the inactivity timeout is specified as 30 minutes.
2. Configure the end point VIP 199.99.9.5 on the loopback interface of all the blade servers.
Now when you run traffic from client 192.50.50.200, depending on the request, it is load balanced to a particular blade server, for example server 192.50.50.13. Any subsequent traffic from the same client destined to the vip 199.99.9.5 and port 8080 is sent back to the same server, that is, 192.50.50.13, without any load balancing. Thus the traffic to end point 199.99.9.5:8080:tcp now tracks the primary service. If no traffic is received from 192.50.50.200 for end point 199.99.9.5:8080:tcp for 30 minutes, then the tracking expires.
Now the first connection from 192.50.50.200 to the VIP 199.99.9.4 and port 80 will be load balanced to say server 192.50.50.10 and any subsequent connections from the same client, destined to either 199.99.9.4:80 or 199.99.9.5:8080 go back to the same server.
|
As admin in config mode, remove end point tracking:
Port tracking and end point tracking can also be added to a service configured with IP persistence in which case the tracking will be valid for any client from the subnet (as specified by the persistence mask) instead of one particular client.
|
As admin in config mode, enter the following command:
The cookie is set by the server on the client using the header
Set-cookie: PERSIST=xyzc03232axyz;\r\n
The client when it makes the next request sends this cookie in the header
Cookie: PERSIST=xyzc032320axyz;\r\n
If the cookie persistence is set as shown above, then the content load balancing blade parses and finds the string 'c032320a' in the cookie. The name is PERSIST and the offset is 3. The offset specifies how many bytes into the value to look for to find the start of the cookie. If the cookie matches the server the request is sent to server 192.50.50.10.
Currently, the delimiter value is ignored. If this configuration is saved and retrieved, the delimiter value is always set to ':'.
|
As admin in config mode, enter the following command:
|
The following restrictions apply to a UDP services:
|
Note - A UDP end point can be added for port/end-point tracking to a TCP service |
1. As admin in config mode, create a Layer 4 service:
2. Verify that the service was created:
3. Add two blade servers to the default load balancing group for the service:
puma(config){admin}# service lb-group default svcudp server 192.50.50.18:90:udp:1:1 192.50.50.19:90:udp:1:1 scheme static |
You can now run UDP traffic from clients to the UDP service 199.99.9.1 on port 90 and it is load balanced between the two blade servers 192.50.50.18 and 192.50.50.19 in a static fashion. With the current implementation of the static load balancing algorithm, all UDP traffic from the same client IP will go to the same server, as long as the server is available. If the server becomes unavailable, then the new traffic goes to the next available server.
|
Note - It is possible to add Layer 4 IP rules to a UDP service just like any other Layer 4 service. |
|
FTP service configuration on the Sun Fire B10n blade has the following restrictions:
When configuring an FTP service ensure the following:
1. As admin in config mode, create an FTP service:
2. Verify that the service was created:
3. Add two blade servers to the default load balancing group for the service:
puma(config){admin}# service lb-group default svcftp server 192.50.50.14:21:tcp:1:1 192.50.50.15:21:tcp:1:1 scheme wt-round-robin |
4. Configure the VIP 199.99.9.1 should be configured on the loopback interface of the blade servers 192.50.50.14 and 192.50.50.15.
5. Add IP persistence with mask length 0:
|
Note - Short timeout values do not have the expected result. Timeout values should be at least 15-20 minutes, and the granularity of timing out entries is in the order of 10 minutes. |
You can now run FTP client(s) from client machine(s) to the FTP service on 199.99.9.1 and the FTP sessions will be load balanced between the 2 blade servers 192.50.50.14 and 192.50.50.15 in a weighted round robin fashion (for different client IPs as client persistence is set).
|
Note - It is possible to add L4 (IP) rule(s) to an FTP service just like any other Layer 4 service. |
|
1. As admin in config mode, add an end point to a service:
This command adds an end point with VIP 199.99.9.30, port 80 and protocol TCP to the service svcL4. This end point inherits all properties of the service.
2. Configure the VIP for the new end point, that is, 199.99.9.30 in this case, on the loopback interface of all the blade servers included in the service (svcL4 in this case).
3. If your service has an SSL device (B10p), add another service with the VIP for the new end point.
Enter a new service name when prompted and the VIP for the new end point.
For this example, assume the following:
The Sun Fire B10n blade and all servers for the service must be members for all three VLANs mentioned above. The ports must be set up to forward traffic on these VLANs tagged.
Refer to the Sun Fire B1600 Blade System Chassis Software Setup Guide for the mechanism to set up the switch.
First, the VLAN database must be edited to include the VLANs to be used in the service.
Then, the port membership rules are set using the interface switch port setup.
|
Note - By default, VLAN 1 is forwarded on the ports untagged. In this example, the client side VLAN is forwarded tagged. |
|
The server must also be a member of all VLANs mentioned above. The management VLAN is used to exchange configuration messages between the content load balancing blade and the blade server. VLAN is also used for server health monitoring.
The service VLAN is used for all data plane traffic between the content load balancing blade and the blade server.
The route from the server to the client network must use the client side VLAN. For security reasons, the server cannot bind any services to its IP address on this interface.
1. Configure the client side VLAN interface:
2. Configure the management VLAN interface:
3. Configure the service VLAN interface:
4. 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.
5. Add all three interfaces to the load balanced interfaces:
# /opt/SUNWclb/bin/clbconfig add ce21000 # /opt/SUNWclb/bin/clbconfig add ce22000 # /opt/SUNWclb/bin/clbconfig add ce25000 |
6. Verify that the route to the default gateway uses interface ce21000.
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 ce21001, ce22001, and ce25001, 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
|
First, set up a service as described in (relevant chapters). Assume that the name of the service is SVC1.
1. As admin, in config mode, set the service VLAN:
3. Set the client side (default) VLAN:
4. Enable the client side VLAN:
This section provides a tutorial for configuring the blade failover and describes how to verify the basic failover functionality.
Before starting any of the failover commands, verify that there are no service configurations on the load balancer that require to run on the standby blade. See List of Configuration Commands for service configurations that must be local to the standby blade.
On the load balancer to be configured as local, you might want to configure the service related configurations prior to enabling failover, so that all configurations will be propagated to the standby load balancer once the failover synchronization is complete. Alternately, the commit or the failover config-sync commands can be used later.
As admin, use the following command:
As admin, use the following command:
As admin, use the following command:
As admin, use the following command:
In the preceding example, the path failover monitoring packet will be sent to the target address once in 5 seconds and will be retried 5 times before marking the interface as down.
As admin, use the following command:
As admin, use the following command:
As admin, use the following command:
As admin, use the following command:
The following set of minimum failover commands initially starts the failover. Each command must be entered from each load balancer in sequence in order for the failover monitoring and synchronization to work. The show failover command may be used to list the information about the current failover configuration, status, and state.
1. config failover peer {IP_address_0} {IP_address_1}
2. config enable failover-monitor
3. config failover start {local | remote}
Use the failover-monitor command to modify the default monitoring parameters.
Use the failover peer command:
Use the enable failover-monitor command:
Use the failover start command:
On each load balancer, Synchronizing Failover State ... will be displayed. Once the failover state is determined, Failover state is set to standby or Failover state is set to active will be printed.
|
Note - Enter the commit command if you want to save the failover configuration. |
Use the show failover command on the active peer:
Use the show failover command on the standby peer:
Use the no enable failover-monitor command:
|
Note - To enable monitoring, enable failover-monitor must be entered on each blade. |
Use the failover stop command:
|
|
Use the failover-monitor command:
Use the failover force-failover command:
Use the failover config-sync command:
Use the erase failover state-file command:
This command can be used to remove the failover state file if the two load balancer blades configured for failover goes out of sync for some reason. Erasing the state-file will initiate a synchronization process between the two blades. This command will not be allowed when both the load balancers are in sync. Also removing the failover configuration will remove this file automatically.
When removing the failover state-file, the Config number becomes -1 in the
show failover command output. Config number -1 indicates that the failover state-file does not exist. The following is an example:
|
|
Use the erase failover config-lb-mem command:
Use the remove failover-config command:
Use the show failover command on both load balancers to check the failover state and configuration file synchronization. If everything is configured properly, one blade should have a state of active while the other blade is set to standby. Both load balancers should have identical load balancing configurations.
You may run commands such as show service and show rule to confirm that both blades are configured identically.
If the commit command is executed on the active load balancer, the synchronization between these two active and standby load balancers will be done automatically.
If any of load balancing service related commands are issued on the active load balancer without being followed by the commit command, the standby load balancer will not be updated with any of those configurations.
Use the dump module failover command to dump the information regarding the failover module to the screen.
Use the dump module task command to dump information regarding the failover synchronization task and the failover monitoring task.
Use the dump module failover 1 command:
Use the dump module failover 2 command:
Use the dump module failover 3 command:
Use the dump module task 9 command:
Use the dump module task 10 command:
| Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide | 817-6210-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.
To Export the Entire Configuration