Hands-On Labs of the System Admin and Developer Community of OTN

This lab demonstrates how the Integrated Load Balancer feature of Oracle Solaris provides an easy and fast way to deploy a load-balancing system. It also shows how to use the different types of load-balancing modes offered by the Integrated Load Balancer.

Introduction and Lab Objective

This document details all the actions that were done during the Oracle OpenWorld Hands-On Lab 10181 session.

Note: You can also run this lab from your home or office on an x86 server, desktop, or laptop.

Oracle Solaris 11 provides an out-of-the-box layer 3 and layer 4 load-balancing feature known as the Integrated Load Balancer. This feature intercepts incoming requests and handles the redirection toward back-end servers based on customized load-balancing rules. The Integrated Load Balancer can turn any Oracle Solaris 11 server into a cost-effective yet powerful load-balancing system.

This hands-on lab was created for application architects or system administrators who need to deploy and manage a load-balancing system. It provides an overview of the entire process of enabling, configuring, and using the Integrated Load Balancer. As a concrete example, a simple Apache Tomcat web application is deployed on multiple Oracle Solaris Zones (another feature of Oracle Solaris), and the Integrated Load Balancer is used to showcase different load-balancing scenarios.

During this lab, you configure and use the Integrated Load Balancer inside an Oracle Solaris Zone to balance the load towards three Apache Tomcat web servers running a simple JavaServer Pages (JSP) application specially developed for this lab.

Prerequisites

The following actions need to be performed to prepare the lab environment before the actual lab can be started:

• Installing Oracle Solaris 11.1
• Creating virtual switches (etherstubs) and virtual NICs (VNICs)
• Configuring the global zone's VNIC (gz_1)
• Configuring four Oracle Solaris Zones: one to host the Integrated Load Balancer (ilb-zone) and three to host the web servers (web1, web2, and web3)
• Configuring ilb-zone, including installing the packages needed for the lab (for example, Apache Tomcat 6)
• Configuring the /etc/hosts file
• Enabling SSH connections as root
• Creating a JSP test file that can be used to test the Integrated Load Balancer
• Cloning ilb-zone to quickly install web1, web2, and web3
• Configuring the second VNIC of ilb-zone (public interface 10.5.1.1)
• Installing Apache JMeter and creating a test file that can be used as an alternative way to test the Integrated Load Balancer

To run this lab from your home or office, do the following:

1. Ensure the x86 machine you will use has the following:
   1. At least 8 GB of RAM and two cores CPU
   2. An x86 operating system supported by Oracle VM VirtualBox, for example, Oracle Solaris for x86, Microsoft Windows, most Linux distributions, or Apple Mac OSX
2. Perform the steps in "System Preparation (Prerequisites for the Lab)" section to prepare the lab environment by performing the actions described above.

Summary of the Lab Exercises

After you prepare the environment on your x86 machine by performing the steps in the "System Preparation (Prerequisites for the Lab)" section, you will execute the following lab exercises:

1. Start the Oracle Solaris 11 virtual machine in Oracle VM VirtualBox.
2. Log in to the Oracle Solaris 11 server.
3. Check the current environment.
4. Enable the Integrated Load Balancer.
5. Verify the web environments.
6. Configure and test the load balancer in Network Address Translation (NAT) mode.
7. Create and test a customized health check script.
8. Configure and test the load balancer in Direct Server Return (DSR) mode.
9. Add a server to and remove a server from the back-end server group.

Technologies Used in This Lab

In order to emulate on a simple x86 machine the network and server topography that is needed to test a load balancer, this lab relies on the following technologies, which are built into Oracle Solaris 11:

• Oracle Solaris Zones for server virtualization

  Oracle Solaris Zones technology offers the ability to create different isolated environments to suit the needs of particular applications, all on the same instance of Oracle Solaris. Each environment acts as a "real" server with its own host name, IP address, and IP stack. Table 1 shows some common commands used during this lab.

  Table 1. Common Oracle Solaris Zones commands.

  Purpose	Command
  List all zones and their status	zoneadm list -civ
  Log in to a zone	zlogin zone_name or ssh root@zone_host_name
  Boot a zone	zoneadm -z zone_name boot
  Reboot a zone	zoneadm -z zone_name reboot
  Shut down a zone	zoneadm -z zone_name shutdown

  The following zones are created for this lab:

  
  
  
  [root@kafka]# zoneadm list -civ
  ID NAME             STATUS     PATH                           BRAND    IP    
  0 global           running    /                              solaris  shared
  1 ilb-zone         running    /zones/ilb-zone                solaris  excl  
  2 web2             running    /zones/web2                    solaris  excl  
  4 web1             running    /zones/web1                    solaris  excl  
  - web3             installed  /zones/web3                    solaris  excl
  
  
  

  A zone's status can be running, installed (shut down), or configured (not installed).

  The host name of the global zone for this lab is kafka.

• Network virtualization

  Oracle Solaris 11 provides, among other network features, virtual network interface cards (VNICs) and virtual switching (etherstubs), which enable the creation of a virtual data center in a box. Table 2 shows some common commands used during this lab.

  Table 2. Common network virtualization commands.

  Purpose	Command
  List all physical NICs	dladm show-phys
  List all VNICs	dladm show-vnic
  List all etherstubs	dladm show-etherstub
  List all IP interfaces	ipadm show-if
  List all IP addresses	ipadm show-addr
  Show the routing table	netstat -rn

• Oracle Solaris Service Management Facility

  The Service Management Facility feature of Oracle Solaris replaces the legacy init scripting mechanism for managing system and application services, and it is used in this lab to manage the Integrated Load Balancer and Tomcat services. Table 3 shows some common commands used during this lab.

  Table 3. Common Service Management Facility commands.

  Purpose	Command
  List all services	svcs -a
  List the status of a service	svcs service_name or svcs -l service_name (for more details)
  Enable a service	svcadm enable service_name
  Disable a service	svcadm disable service_name
  Restart a service	svcadm restart service_name
  Retry setting online a service that is in maintenance	svcadm clear service_name

  A service can be online (enabled), disabled, or in maintenance (it can't go online).

Global Lab Architecture

Figure 1 provides a global, detailed view of the architecture of the lab. The global zone hosts two networks and four zones.

Figure 1. Lab architecture.

Note: This is the global architecture used during the lab; however, the web1, web2, and web3 zones are connected only to the private (red) network at the beginning of the lab in order to use the load balancer in NAT mode. Later on, one of the exercises will consist of connecting them to the public (blue) network in order to operate the load balancer in DSR mode.

System Preparation (Prerequisites for the Lab)

This section explains how to prepare your x86 machine before starting the lab exercises. All commands are executed as root.

Install Oracle Solaris 11.1

The very first step is to install Oracle Solaris 11.1 in Oracle VM VirtualBox. (If you do not already have Oracle VM VirtualBox on your x86 machine, download and install it.)

You can download Oracle Solaris 11.1 here: http://www.oracle.com/solaris/solaris11/downloads/solaris-downloads.html.

Several installation media are available: Choose "Oracle Solaris 11.1 Live Media for x86" since this will install Oracle Solaris 11.1 with a full graphical environment. Although having a graphical environment is not a prerequisite for using the Integrated Load Balancer, it is recommended for this lab.

Create Virtual Switches and VNICs

Once you have installed Oracle Solaris 11, log in and then run the following commands to create the virtual switches (etherstubs) and VNICs.

[root@kafka]# dladm create-etherstub switch1 
[root@kafka]# dladm create-etherstub switch2 

[root@kafka]# dladm create-vnic -l switch1 gz_1 
[root@kafka]# dladm create-vnic -l switch1 ilb_1 
[root@kafka]# dladm create-vnic -l switch1 web1_1 
[root@kafka]# dladm create-vnic -l switch1 web2_1 
[root@kafka]# dladm create-vnic -l switch1 web3_1
[root@kafka]# dladm create-vnic -l switch2 ilb_2
[root@kafka]# dladm create-vnic -l switch2 web1_2 
[root@kafka]# dladm create-vnic -l switch2 web2_2 
[root@kafka]# dladm create-vnic -l switch2 web3_2

Configure the Global Zone's VNIC

An internal "public" network will be created; therefore, the global zone needs to be connected to a virtual switch (switch1) via a VNIC (gz_1). To accomplish this, run the following commands:

[root@kafka]# ipadm create-ip gz_1
[root@kafka]# ipadm create-addr -T static -a 10.5.1.6/24 gz_1/v4

Configure Four Oracle Solaris Zones

1. Create a zone configuration file called /root/ilb-zone.cfg using the content shown in Listing 1:

   
   
   
   create -b 
   set brand=solaris 
   set autoboot=true
   set zonepath=/zones/ilb-zone 
   set autoboot=true 
   set ip-type=exclusive 
   add net 
   set configure-allowed-address=true 
   set physical=ilb_1 
   end 
   add net 
   set configure-allowed-address=true 
   set physical=ilb_2 
   end
   
   
   

   Listing 1. Content for /root/ilb-zone.cfg file.

2. Create a web1 zone configuration file called /root/web1.cfg using the content shown in Listing 2:

   
   
   
   create -b 
   set brand=solaris 
   set autoboot=true
   set zonepath=/zones/web1
   set autoboot=true 
   set ip-type=exclusive 
   add net 
   set configure-allowed-address=true 
   set physical=web1_1 
   end 
   add net 
   set configure-allowed-address=true 
   set physical=web1_2 
   end
   
   
   

   Listing 2. Content for /root/web1.cfg file.

3. Create the two remaining zone configuration files (web2.cfg and web3.cfg) by using web1.cfg as a template and replacing "web1" with "web2" or "web3," respectively.
4. Configure the zones using the configuration files you just created:

   
   
   
   [root@kafka]# zonecfg -z  ilb-zone -f /root/ilb-zone.cfg 
   [root@kafka]# zonecfg -z  web1 -f /root/web1.cfg 
   [root@kafka]# zonecfg -z  web2 -f /root/web2.cfg 
   [root@kafka]# zonecfg -z  web3 -f /root/web3.cfg
   
   
   

Install and Configure ilb-zone

1. Install the ilb-zone zone:

   [root@kafka]# zoneadm -z ilb-zone install

2. Once the installation is done, boot the zone and log in to the console so you can perform the first-boot system configuration, as you would for any Oracle Solaris installation:

   
   
   [root@kafka]# zoneadm -z ilb-zone boot
   [root@kafka]# zlogin -C ilb-zone
   
   

3. In the System Configuration Tool (see Figure 2), press F2 so you can specify the required system configuration information, such as time zone, root password, and so on. The most important information concerns the network configuration.

   

   Figure 2. System configuration: Welcome screen.

   In the Network screen, set the computer name to ilb-zone and choose to configure the network manually (see Figure 3).

   

   Figure 3. System configuration: Network screen.

   In the Manually Configure screen (see Figure 4), choose the private interface ilb_2 and configure it with the following information:

   1. IP address: 192.168.1.10
   2. Netmask: 255.255.255.0
   3. Router (Gateway): 192.168.1.10

   

   Figure 4. System configuration: Manually Configure screen.

   No name services need to be configured (DNS or NIS).

   Finally, choose the time zone and the root password to finalize the system configuration.

   Note: Only one network interface card (NIC) can be configured using the system configuration tool; therefore, the public interface ilb_1 will be configured later by logging in to the zone.

4. Once you have completed the system configuration for ilb-zone, log in and add the extra packages needed for this lab (for example, Apache Tomcat):

   
   
   [root@kafka]# zlogin ilb-zone
   [root@ilb-zone]# pkg install solaris-large-server tomcat tomcat-examples
   
   

Configure the /etc/hosts File

Add the content code shown in Listing 3 to the /etc/hosts file in the global zone and in the ilb-zone zone.

::1             localhost
127.0.0.1       localhost loghost
10.5.1.6 kafka
10.5.1.10 ilb-zone
10.5.1.11 web1
10.5.1.12 web2
10.5.1.13 web3

10.5.1.50 vip

192.168.1.10 ilb-zone-priv
192.168.1.11 web1-priv
192.168.1.12 web2-priv
192.168.1.13 web3-priv

Listing 3. Content for the /etc/hosts file.

Allow SSH Connections as root

Edit the file /etc/ssh/sshd_config and change the line PermitRootLogin no to PermitRootLogin yes.

Create the JSP Test File

To test the load balancer, this lab uses a simple JSP file that will dynamically print the IP address of the back-end server that served our request.

Add the JSP code shown in Listing 4 to a file called ilbtest.jsp under the /var/tomcat6/webapps/ROOT directory in the ilb-zone zone.

Note: You might wonder why we install Tomcat and create a JSP file in ilb-zone zone, given that during the lab, this zone will act as a load balancer and not as a web server. The reason is that we will be using this first-created zone as a template for all the other zones. Therefore, creating the zones that will act as web servers will simply be a matter of cloning this zone. One advantage of using this method is that less disk space is consumed, but this method is also a huge time saver, because cloning an existing zone to create a new one takes only a matter of seconds.

<html>
<head>
<title>Solaris 11 ILB Lab</title>
</head>
<body>
<%@page import="java.net.InetAddress;" %>

<TABLE width=100% border="0" cellpadding="3">
<TR>
    <TH align="center"><h2>Client</h2></TH>
    <TH align="center"><h2>Load Balancer</h2></TH>
    <TH align="center"><h2>Server</h2></TH>
</TR>
<TR>
    <TD align="center">
    <TABLE cellpadding="2">
    <TR>
        <TD>Client Host name:</TD>
        <TD><b><%= request.getRemoteHost() %></b></TD>
    </TR>
    <TR>
        <TD>Client IP:</TD>
        <TD><b><%= request.getRemoteAddr() %></b></TD>
    </TR>
    <TR>
        <TD>Client Port:</TD>
        <TD><b><%= request.getRemotePort() %></b></TD>
    </TR>

    </TABLE>
    </TD>
    <TD align="center">
    <TABLE cellpadding="2">
    <TR>
        <TD>Virtual Host name:</TD>
        <TD><b>vip</b></TD>
    </TR>
    <TR>
        <TD>Virtual IP:</TD>
        <TD><b>10.5.1.50</b></TD>
    </TR>
    <TR>
        <TD>VIP Port:</TD>
        <TD><b><%= request.getServerPort() %></b></TD>
    </TR>
    </TABLE>
    </TD>
    <TD align="center">
    <TABLE cellpadding="2">
    <TR>
        <TD>Server Host name:</TD>
        <TD><b><%= InetAddress.getLocalHost().getHostName() %></b></TD>
    </TR>
    <TR>
        <TD>Server IP:</TD>
        <TD><b><%= request.getLocalAddr() %></b></TD>
    </TR>
    <TR>
        <TD>Server Port:</TD>
        <TD><b><%= request.getLocalPort() %></b></TD>
    </TR>
    </TABLE>
    </TD>
</TR>
</TABLE>
</body>
</html>

Listing 4. Content for the JSP file.

Clone Zone ilb-zone to Install web1, web2, and web3

1. Create the three web zones (web1, web2, and web3) by halting and then cloning ilb-zone, which is already installed. As noted previously, cloning not only reduces the required disk space, but it also creates the zones in a matter of seconds.

   
   
   
   [root@kafka]# zoneadm -z ilb-zone halt
   [root@kafka]# zoneadm -z web1 clone ilb-zone
   [root@kafka]# zoneadm -z web2 clone ilb-zone
   [root@kafka]# zoneadm -z web3 clone ilb-zone
   
   
   

2. As you did for ilb-zone, you need to boot each of the three web zones and configure it. To do this, repeat Step 2 and Step 3 of the "Install and Configure ilb-zone" section for each web zone.

   Note: When this lab was performed at Oracle OpenWorld, this process was fully automatized by using optional system configuration XML files to configure the newly created zones without any human interaction. A custom manifest file was also used to directly install all the extra packages (such as Tomcat) automatically without human interaction. Such automation greatly simplifies the process of creating and deploying zones, but it is out of the scope of this document.

   When you do the manual network configuration for web1, web2, and web3, use the information shown in Table 4.

   Table 4. Network configuration for the three web zones.

   Zone Name
   Computer Name	web1	web2	web3
   Network Interface	web1_2	web2_2	web3_2
   IP Address	192.168.1.11	192.168.1.12	192.168.1.13
   Netmask	255.255.255.0	255.255.255.0	255.255.255.0
   Router (Gateway)	192.168.1.10	192.168.1.10	192.168.1.10
   DNS/NIS Configuration	No	No	No

Configure the Second VNIC of ilb-zone (Public Interface 10.5.1)

Boot the ilb-zone zone (since it was previously halted so it could be cloned):

[root@kafka]# zoneadm -z ilb-zone boot

During the system configuration for ilb-zone, only the private IP address was configured. Since ilb-zone is the only zone connected to both the public and private networks (at least during the first part of this lab), you need to configure the public interface by running the following commands.

[root@kafka]# zlogin ilb-zone ipadm create-ip ilb_1
[root@kafka]# zlogin ilb-zone ipadm create-addr -T static -a 10.5.1.10/24 ilb_1/v4

Install Apache JMeter and Create a Test File

As an alternate way of testing the load balancer, we will use Apache JMeter. If you wish to use it (although this is optional) you need to download and install JMeter in the global zone. Then add the code shown in Listing 5 to a file called ILB_Test_Plan.jmx, which can be saved in any accessible directory.

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="2.4" jmeter="2.9 r1437961">
<hashTree>
<TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="ILB Test Plan" enabled="true">
<stringProp name="TestPlan.comments"></stringProp>
<boolProp name="TestPlan.functional_mode">false</boolProp>
<boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
<elementProp name="TestPlan.user_defined_variables" elementType="Arguments" 
guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
<collectionProp name="Arguments.arguments"/>
</elementProp>
<stringProp name="TestPlan.user_define_classpath"></stringProp>
</TestPlan>
<hashTree>
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="ILB Clients" enabled="true">
<stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
<elementProp name="ThreadGroup.main_controller" elementType="LoopController" 
guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
<boolProp name="LoopController.continue_forever">false</boolProp>
<stringProp name="LoopController.loops">20</stringProp>
</elementProp>
<stringProp name="ThreadGroup.num_threads">1</stringProp>
<stringProp name="ThreadGroup.ramp_time">10</stringProp>
<longProp name="ThreadGroup.start_time">1376915632000</longProp>
<longProp name="ThreadGroup.end_time">1376915632000</longProp>
<boolProp name="ThreadGroup.scheduler">false</boolProp>
<stringProp name="ThreadGroup.duration"></stringProp>
<stringProp name="ThreadGroup.delay"></stringProp>
</ThreadGroup>
<hashTree>
<CacheManager guiclass="CacheManagerGui" testclass="CacheManager" testname="HTTP Cache 
Manager" enabled="true">
<boolProp name="clearEachIteration">true</boolProp>
<boolProp name="useExpires">true</boolProp>
</CacheManager>
<hashTree/>
<ConfigTestElement guiclass="HttpDefaultsGui" testclass="ConfigTestElement" 
testname="HTTP Request Defaults" enabled="true">
<elementProp name="HTTPsampler.Arguments" elementType="Arguments" 
guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="User Defined Variables" 
enabled="true">
<collectionProp name="Arguments.arguments"/>
</elementProp>
<stringProp name="HTTPSampler.domain">vip</stringProp>
<stringProp name="HTTPSampler.port">80</stringProp>
<stringProp name="HTTPSampler.connect_timeout"></stringProp>
<stringProp name="HTTPSampler.response_timeout"></stringProp>
<stringProp name="HTTPSampler.protocol"></stringProp>
<stringProp name="HTTPSampler.contentEncoding"></stringProp>
<stringProp name="HTTPSampler.path"></stringProp>
<stringProp name="HTTPSampler.concurrentPool">4</stringProp>
</ConfigTestElement>
<hashTree/>
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" 
testname="ILB Jsp Test Page" enabled="true">
<elementProp name="HTTPsampler.Arguments" elementType="Arguments" 
guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="User Defined Variables" 
enabled="true">
<collectionProp name="Arguments.arguments"/>
</elementProp>
<stringProp name="HTTPSampler.domain"></stringProp>
<stringProp name="HTTPSampler.port"></stringProp>
<stringProp name="HTTPSampler.connect_timeout"></stringProp>
<stringProp name="HTTPSampler.response_timeout"></stringProp>
<stringProp name="HTTPSampler.protocol"></stringProp>
<stringProp name="HTTPSampler.contentEncoding"></stringProp>
<stringProp name="HTTPSampler.path">/ilbtest.jsp</stringProp>
<stringProp name="HTTPSampler.method">GET</stringProp>
<boolProp name="HTTPSampler.follow_redirects">true</boolProp>
<boolProp name="HTTPSampler.auto_redirects">false</boolProp>
<boolProp name="HTTPSampler.use_keepalive">false</boolProp>
<boolProp name="HTTPSampler.DO_MULTIPART_POST">false</boolProp>
<boolProp name="HTTPSampler.monitor">false</boolProp>
<stringProp name="HTTPSampler.embedded_url_re"></stringProp>
</HTTPSamplerProxy>
<hashTree/>
<ResultCollector guiclass="ViewResultsFullVisualizer" testclass="ResultCollector" 
testname="View Results Tree" enabled="true">
<boolProp name="ResultCollector.error_logging">false</boolProp>
<objProp>
<name>saveConfig</name>
<value class="SampleSaveConfiguration">
<time>true</time>
<latency>false</latency>
<timestamp>true</timestamp>
<success>true</success>
<label>true</label>
<code>true</code>
<message>true</message>
<threadName>true</threadName>
<dataType>false</dataType>
<encoding>false</encoding>
<assertions>false</assertions>
<subresults>false</subresults>
<responseData>true</responseData>
<samplerData>false</samplerData>
<xml>false</xml>
<fieldNames>false</fieldNames>
<responseHeaders>true</responseHeaders>
<requestHeaders>false</requestHeaders>
<responseDataOnError>false</responseDataOnError>
<saveAssertionResultsFailureMessage>false</saveAssertionResultsFailureMessage>
<assertionsResultsToSave>0</assertionsResultsToSave>
<hostname>true</hostname>
</value>
</objProp>
<stringProp name="filename"></stringProp>
</ResultCollector>
<hashTree/>
</hashTree>
</hashTree>
</hashTree>
</jmeterTestPlan>

Listing 5. Content for the Apache JMeter script.

At this point, the x86 system's lab environment has been configured and you are ready to run the lab.

Lab Exercises: Detailed Instructions

This section contains the lab exercises, which will walk you step by step through the process of configuring and using the Oracle Solaris 11 Integrated Load Balancer. All commands are executed as root.

Start the Oracle Solaris 11 Virtual Machine in Oracle VM VirtualBox

As previously explained, we will use Oracle VM VirtualBox to host the Oracle Solaris 11 server on your x86 machine.

1. Start the Oracle VM VirtualBox console by clicking the icon.

   

   Figure 5. Oracle VM VirtualBox console.

2. Select the VM that was automatically created when you installed Oracle Solaris in Oracle VM VirtualBox in the "Install Oracle Solaris 11.1" section, and then click the icon to start it.
3. Wait for the Oracle Solaris 11 login screen.

   

   Figure 6. Oracle Solaris login screen.

Log in to the Oracle Solaris Server

1. Log in using the credentials you defined when you installed Oracle Solaris 11.
2. Open a terminal window either by clicking the icon in the top menu bar or by right-clicking the desktop and choosing Open Terminal.

   

   Figure 7. Oracle Solaris terminal window.

Check the Current Environment

This exercise has you check the current environment to help you get familiar with the setup and with some commands that are used throughout the rest of the lab.

1. List the zones running on the system:

   
   
   
   [root@kafka]# zoneadm list -civ
   ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              solaris  shared
   1 ilb-zone         running    /zones/ilb-zone                solaris  excl  
   2 web2             running    /zones/web2                    solaris  excl  
   4 web1             running    /zones/web1                    solaris  excl  
   - web3             installed  /zones/web3                    solaris  excl
   
   
   

2. List the etherstubs of the global zone:

   
   
   
   [root@kafka]# dladm show-etherstub
   LINK
   switch1
   switch2
   
   
   

3. List the VNICs of the global zone:

   
   
   
   [root@kafka]# dladm show-vnic
   LINK                OVER         SPEED  MACADDRESS        MACADDRTYPE       VID
   gz_1                switch1      40000  2:8:20:7d:72:d7   random            0
   ilb_1               switch1      40000  2:8:20:35:d0:17   random            0
   ilb-zone/ilb_1      switch1      40000  2:8:20:35:d0:17   random            0
   web1_1              switch1      40000  2:8:20:c0:54:3d   random            0
   web1/web1_1         switch1      40000  2:8:20:c0:54:3d   random            0
   web2_1              switch1      40000  2:8:20:d8:eb:1d   random            0
   web3_1              switch1      40000  2:8:20:e3:cf:ff   random            0
   web3/web3_1         switch1      40000  2:8:20:e3:cf:ff   random            0
   ilb_2               switch2      40000  2:8:20:f6:6f:b3   random            0
   ilb-zone/ilb_2      switch2      40000  2:8:20:f6:6f:b3   random            0
   web1_2              switch2      40000  2:8:20:68:c7:73   random            0
   web1/web1_2         switch2      40000  2:8:20:68:c7:73   random            0
   web2_2              switch2      40000  2:8:20:43:ea:86   random            0
   web3_2              switch2      40000  2:8:20:ea:c2:10   random            0
   web3/web3_2         switch2      40000  2:8:20:ea:c2:10   random            0
   
   
   

4. List all IP addresses of the global zone:

   
   
   
   [root@kafka]# ipadm show-addr 
   ADDROBJ           TYPE     STATE        ADDR
   lo0/v4            static   ok           127.0.0.1/8
   net0/v4           dhcp     ok           192.168.0.7/24
   gz_1/v4           static   ok           10.5.1.6/24
   lo0/v6            static   ok           ::1/128
   net0/v6           addrconf ok           fe80::a00:27ff:fea3:34f1/10
   
   
   

Enable the Integrated Load Balancer

Some configuration and verification are necessary before using the Integrated Load Balancer. This section will walk you through this process.

1. Log in to ilb-zone:

   
   
   
   [root@kafka]# zlogin ilb-zone
   [Connected to zone 'ilb-zone' pts/3]
   Oracle Corporation  SunOS 5.11  11.1    September 2012
   You have new mail.
   [root@ilb-zone]#
   
   
   

   The NAT code path that is implemented in the Integrated Load Balancer differs from the code path that is implemented in the IP Filter feature of Oracle Solaris. We must not use both of these code paths simultaneously, so we will disable the IP Filter service. On the other hand, we must enable IP Forwarding. We will work only with IPv4 in this lab, but IPv6 could also be used.

2. Disable IP Filter and check its status:

   
   
   
   [root@ilb-zone]# svcadm disable ipfilter
   [root@ilb-zone]# svcs ipfilter 
   STATE          STIME    FMRI
   disabled        2:39:22 svc:/network/ipfilter:default
   
   
   

3. Enable IP Forwarding and verify the new settings:

   
   
   
   [root@ilb-zone]# ipadm set-prop -p forwarding=on  ipv4
   [root@ilb-zone]# routeadm
   
                 Configuration   Current              Current
                        Option   Configuration        System State
   ---------------------------------------------------------------
                  IPv4 routing   disabled             disabled
                  IPv6 routing   disabled             disabled
               IPv4 forwarding   enabled              enabled
               IPv6 forwarding   disabled             disabled
   
              Routing services   "route:default ripng:default"
   
   Routing daemons:
   
                         STATE   FMRI
                      disabled   svc:/network/routing/ripng:default
                      disabled   svc:/network/routing/legacy-routing:ipv4
                      disabled   svc:/network/routing/legacy-routing:ipv6
                        online   svc:/network/routing/ndp:default
                      disabled   svc:/network/routing/route:default
                      disabled   svc:/network/routing/rdisc:default
   
   

4. Verify that the Integrated Load Balancer is installed on the system:

   
   
   
   [root@ilb-zone]# pkg info ilb
             Name: service/network/load-balancer/ilb
          Summary: IP layer 3/4 load balancer
      Description: The Integrated Load Balancer (ILB) provides Layer 3 and Layer 4
                   load-balancing capabilities.  ILB intercepts incoming requests
                   from clients, decides which back-end server should handle the
                   request based on load-balancing rules, and then forwards the
                   request to the selected server. ILB performs optional health
                   checks and provides the data for the load-balancing algorithms
                   to verify if the selected server can handle the incoming
                   request.
         Category: System/Administration and Configuration
            State: Installed
        Publisher: solaris
          Version: 0.5.11
    Build Release: 5.11
           Branch: 0.175.1.0.0.24.2
   Packaging Date: September 19, 2012 06:45:40 PM
             Size: 523.55 kB
             FMRI: pkg://solaris/service/network/load-balancer/ilb@0.5.11,5.11-0.175.1.0.0.24.2:20120919T184540Z
   
   
   

5. Enable the Integrated Load Balancer service and verify that it's now online:

   
   
   
   [root@ilb-zone]# svcs ilb
   STATE          STIME    FMRI
   disabled        7:38:55 svc:/network/loadbalancer/ilb:default
   
   [root@ilb-zone]# svcadm enable ilb 
   
   [root@ilb-zone]# svcs ilb
   STATE          STIME    FMRI
   online          7:39:38 svc:/network/loadbalancer/ilb:default
   
   
   

Verify the Web Environments

1. From the global zone, log in to the web1 zone:

   
   
   
   [root@kafka]# zlogin web1
   [Connected to zone 'web1' pts/3]
   Oracle Corporation  SunOS 5.11  11.1    September 2012
   You have new mail.
   [root@web1]#
   
   
   
   

2. Check that Tomcat is online. If it is not, enable it:

   
   
   
   [root@web1]# svcs tomcat6
   STATE          STIME    FMRI
   disabled       3:01:56 svc:/network/http:tomcat6
   
   [root@web1]# svcadm enable tomcat6
   
   [root@web1]# svcs tomcat6
   STATE          STIME    FMRI
   online         3:02:28 svc:/network/http:tomcat6
   
   
   

3. Verify that the web zone is on the private network (192.168.1.0):

   
   
   
   [root@web1]# ipadm show-addr
   ADDROBJ           TYPE     STATE        ADDR
   lo0/v4            static   ok           127.0.0.1/8
   web1_2/v4         static   ok           192.168.1.11/24
   lo0/v6            static   ok           ::1/128
   web1_2/v6         addrconf ok           fe80::8:20ff:fe68:c773/10
   
   
   

4. Verify that the default gateway is set to the private interface of ilb-zone (192.168.1.10), which will, therefore, act as the router:

   
   
   
   [root@web1]# netstat -rn
   
   Routing Table: IPv4
     Destination           Gateway           Flags  Ref     Use     Interface
   -------------------- -------------------- ----- ----- ---------- ---------
   default              192.168.1.10         UG        1          0 web1_2
   127.0.0.1            127.0.0.1            UH        2         36 lo0       
   192.168.1.0          192.168.1.11         U         2          0 web1_2    
   
   Routing Table: IPv6
     Destination/Mask            Gateway                   Flags Ref   Use    If   
   --------------------------- --------------------------- ----- --- ------- -----
   ::1                         ::1                         UH      2      28 lo0   
   fe80::/10                   fe80::8:20ff:fe68:c773      U       2       0 web1_2
   
   
   

5. Repeat Step 1 through Step 4 for zones web2 and web3.

Configure and Test the Load Balancer in NAT Mode

1. From the global zone, log in to ilb-zone:

   
   
   
   [root@kafka]# zlogin ilb-zone
   [Connected to zone 'ilb-zone' pts/3]
   Oracle Corporation  SunOS 5.11  11.1    September 2012
   You have new mail.
   [root@ilb-zone]#
   
   
   

2. Execute the ilbadm command to see all the options. The commands used in this lab are highlighted in bold.

   
   
   
   [root@ilb-zone]# ilbadm
   ilbadm: the command line is incomplete (more arguments expected)
   Usage:
   ilbadm create-rule|create-rl [-e] [-p] -i vip=value,port=value[,protocol=value]
       -m lbalg=value,type=value[,proxy-src=ip-range][,pmask=mask]
       -h hc-name=value[,hc-port=value]]
       [-t [conn-drain=N][,nat-timeout=N][,persist-timeout=N]]
       -o servergroup=value name
   ilbadm delete-rule|delete-rl -a | name ...
   ilbadm enable-rule|enable-rl [name ... ]
   ilbadm disable-rule|disable-rl [name ... ]
   ilbadm show-rule|show-rl [-e|-d] [-f |[-p] -o key[,key ...]] [name ...]
   ilbadm create-servergroup|create-sg [-s server=hostspec[:portspec...]] groupname
   ilbadm delete-servergroup|delete-sg groupname
   ilbadm show-servergroup|show-sg [[-p] -o field[,field]] [name]
   ilbadm add-server|add-srv -s server=value[,value ...] servergroup
   ilbadm remove-server|remove-srv -s server=value[,value ...] servergroup
   ilbadm disable-server|disable-srv server ...
   ilbadm enable-server|enable-srv server ...
   ilbadm show-server|show-srv [[-p] -o field[,field...]] [rulename ... ]
   ilbadm show-healthcheck|show-hc [hc-name]
   ilbadm create-healthcheck|create-hc [-n] -h hc-test=value[,hc-timeout=value]
       [,hc-count=value][,hc-interval=value] hcname
   ilbadm delete-healthcheck|delete-hc name ...
   ilbadm show-hc-result|show-hc-res [rule-name]
   ilbadm export-config|export-cf [filename]
   ilbadm import-config|import-cf [-p] [filename]
   ilbadm show-statistics|show-stats [-p] -o field[,...]] [-tdAvi]
       [-r rulename|-s servername] [interval [count]]
   ilbadm show-nat|show-nat [count]
   ilbadm show-persist|show-pt [count]
   
   
   
   

3. Create a server group and check that it was created correctly:

   
   
   
   [root@ilb-zone]# ilbadm create-sg -s servers=web1-priv:8080,web2-priv:8080 web_sg_2
   [root@ilb-zone]# ilbadm show-sg
   SGNAME         SERVERID            MINPORT MAXPORT IP_ADDRESS
   web_sg_2       _web_sg_2.0         8080    8080    192.168.1.11
   web_sg_2       _web_sg_2.1         8080    8080    192.168.1.12
   
   
   

4. Create a health check:

   [root@ilb-zone]# ilbadm create-hc -h hc-timeout=3,hc-count=2,hc-interval=8,hc-test=PING web_hc

5. Create a full-NAT rule on port 80 and a half-NAT rule on port 81:

   
   
   
   [root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=80 -m 
   lbalg=rr,type=NAT,proxy-src=192.168.1.10 -h hc-name=web_hc,hc-port=8080 -o 
   servergroup=web_sg_2 web_rule_fn
   
   
   [root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=81 -m 
   lbalg=rr,type=HALF-NAT -h hc-name=web_hc,hc-port=8080 -o servergroup=web_sg_2 
   web_rule_hn
   
   
   

   Table 5 explains the options used to create the rules. Option values are not case-sensitive.

   Table 5. Options for creating rules.

   Option	Explanation	Possible Values
   -e	Enables the rule once it is created. By default, the rule is disabled.
   vip	Specifies the virtual IP (VIP) address of the rule.
   port	Specifies the port number (or a port range).
   lbalg	Specifies the load-balancing algorithm.	roundrobin, hash-ip, hash-ip-port, hash-ip-vip
   type	Specifies the topology of the network.	NAT, HALF-NAT, DSR
   proxy-src	Required for full NAT only. Specifies the IP address range to use as the proxy source address range.	Limited to 10 IP addresses
   hc-name	Specifies the name of the predefined health check method (optional).
   hc-port	Specifies the port(s) for the health check test program to check (optional).	Keywords ALL or ANY, or a specific port number within the port range of the server group
   servergroup	Specifies a single server group as the target.	An existing server group

6. Check the created objects (server group, health check, and rules):

   
   
   
   [root@ilb-zone]# ilbadm show-sg
   SGNAME         SERVERID            MINPORT MAXPORT IP_ADDRESS
   web_sg_2       _web_sg_2.0         8080    8080    192.168.1.11
   web_sg_2       _web_sg_2.1         8080    8080    192.168.1.12
    
   [root@ilb-zone]# ilbadm show-hc
   HCNAME        TIMEOUT COUNT   INTERVAL DEF_PING TEST
   web_hc        3       2       8        Y        PING
    
   [root@ilb-zone]# ilbadm show-rl
   RULENAME            STATUS LBALG       TYPE    PROTOCOL VIP         PORT
   web_rule_fn         E      roundrobin  NAT     TCP  10.5.1.50       80
   web_rule_hn         E      roundrobin  HALF-NAT TCP 10.5.1.50       81
   
   

7. Check whether the back-end servers are reported as being alive:

   
   
   
   [root@ilb-zone]# ilbadm show-hc-res
   RULENAME      HCNAME        SERVERID      STATUS   FAIL LAST     NEXT     RTT
   web_rule_fn   web_hc        _web_sg_2.0   alive    0    08:13:23 08:13:34 681
   web_rule_fn   web_hc        _web_sg_2.1   alive    0    08:13:21 08:13:27 510
   web_rule_hn   web_hc        _web_sg_2.0   alive    0    08:13:22 08:13:34 615
   web_rule_hn   web_hc        _web_sg_2.1   alive    0    08:13:19 08:13:29 634
   
   
   
   

8. Find the MAC address of the public interface (ilb_1) on which the clients will send requests:

   
   
   
   [root@ilb-zone]# dladm show-vnic
   LINK                OVER         SPEED  MACADDRESS        MACADDRTYPE       VID
   ilb_1               ?            40000  2:8:20:35:d0:17   random            0
   ilb_2               ?            40000  2:8:20:f6:6f:b3   random            0
   
   
   
   

9. Add to the ARP table the VIP address associated with the MAC address found in the previous step:

   [root@ilb-zone]# arp -s 10.5.1.50 2:8:20:35:d0:17 pub permanent

10. Verify that you can ping the VIP address:

    
    
    
    [root@ilb-zone]# ping vip
    vip is alive
    
    
    

Test with Firefox

1. Launch Firefox in the global zone by clicking the icon in the top menu bar, and test the different rules we set up (full NAT and half NAT) by using the corresponding URLs:
   1. Full NAT: http://vip/ilbtest.jsp
   2. Half NAT: http://vip:81/ilbtest.jsp
2. Reload the page several times. You should see that upon each refresh, web1 and web2 respond alternately.

   Note: While refreshing the page, press the Shift key to override the Firefox caching mechanism and force it to re-fetch the page.

   Figure 8 shows the results of a test done in full-NAT mode. In this test, web2 responded to the client's request. Since it's full-NAT mode, the actual client IP address (10.5.1.6) was replaced by the IP address of the load balancer (192.168.1.10).

   

   Figure 8. Results of test done in full-NAT mode.

   In Figure 9, the test was done in half-NAT mode and back-end server web1 responded to the request. Notice the difference on the client IP address: this time the actual client IP address is sent to the back-end server.

   

   Figure 9. Results of test done in half-NAT mode.

Test with Apache JMeter

1. Launch Apache JMeter by double-clicking its icon on the desktop.

   

   Figure 10. Apache JMeter.

   Next, we will use the JMeter test file you created earlier, ILB_Test_Plan.jmx, in which five clients are simulated with each sending four requests to the load balancer.

2. To start the test, open the ILB_Test_Plan.jmx file by clicking the icon.

   

   Figure 11. Running the Apache JMeter test.

3. To see the results, click View Results Tree in the left frame. Then choose HTML in the list box at the bottom of the middle frame, and then click the Response data tab in the right frame.

   The middle frame lists the 20 requests sent to the load balancer, and by clicking each, you will see in the Response data tab which back-end server actually served the request. There should be as many requests served by web1 as by web2.

   To clear the results before a new test is run, click the icon.

Create and Test a Customized Health Check Script

All following commands are executed in the ilb-zone zone.

1. Check the status of the back-end servers according to the health check. Both back-end servers should be reported as alive.

   
   
   
   [root@ilb-zone]# ilbadm show-hc-res
   RULENAME      HCNAME        SERVERID      STATUS   FAIL LAST     NEXT     RTT
   web_rule_fn   web_hc        _web_sg_2.0   alive    0    12:40:14 12:40:25 4628
   web_rule_fn   web_hc        _web_sg_2.1   alive    0    12:40:14 12:40:18 2120
   web_rule_hn   web_hc        _web_sg_2.0   alive    0    12:40:09 12:40:18 669
   web_rule_hn   web_hc        _web_sg_2.1   alive    0    12:40:10 12:40:21 563
   
   
   

2. Stop the Tomcat server on web1:

   
   
   
   [root@ilb-zone]# ssh root@web1-priv svcadm disable tomcat6
   [root@ilb-zone]# ssh root@web1-priv svcs tomcat6
   
   

3. Check again the status of the web1 back-end server.

   Although the Tomcat server is stopped, the health check is not aware of this and keeps web1 as a potential back-end server. The problem with the current health check is that it is a simple ping on the server hosting Tomcat. As long as the server responds to the ping, health check considers the server alive.

   
   
   
   [root@ilb-zone]# ilbadm show-hc-res
   RULENAME      HCNAME        SERVERID      STATUS   FAIL LAST     NEXT     RTT
   web_rule_fn   web_hc        _web_sg_2.0   alive    0    12:50:48 12:50:53 570
   web_rule_fn   web_hc        _web_sg_2.1   alive    0    12:50:43 12:50:53 712
   web_rule_hn   web_hc        _web_sg_2.0   alive    0    12:50:43 12:50:54 671
   web_rule_hn   web_hc        _web_sg_2.1   alive    0    12:50:44 12:50:55 773
   
   
   

4. Create a custom health check script.

   To avoid the problem exposed above, a more application-aware health check script should be used. Create a file called /var/web_hc.sh with the content shown in Listing 6. This script uses a simple curl command to check whether the web server returns a response starting with the string "<meta". If it does, we are assured that the web server is running.

   
   
   
   #!/bin/bash
   
   result=`curl -s http://$2:8080`
   if [ "${result:0:5}" = "<meta" ]; then
           echo 0
   else
           echo -1
   fi
   
   
   

   Listing 6. Content for the custom health check script.

   Note: The health check custom script must be executable, so run the following command:

   [root@ilb-zone]# chmod 755 /var/web_hc.sh

5. Delete the current health check and delete the rules that use that health check, since updating health checks and rules is currently not supported.

   
   
   
   [root@ilb-zone]# ilbadm delete-rule web_rule_fn
   [root@ilb-zone]# ilbadm delete-rule web_rule_hn
   [root@ilb-zone]# ilbadm delete-hc web_hc
   
   
   
   

6. Now re-create the health check using the custom script. Also re-create the rules.

   
   
   
   [root@ilb-zone]# ilbadm create-hc -h 
   hc-timeout=3,hc-count=2,hc-interval=8,hc-test=/var/web_hc.sh web_hc 
   
   [root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=80 -m 
   lbalg=rr,type=NAT,proxy-src=192.168.1.10 -h hc-name=web_hc,hc-port=8080 -o 
   servergroup=web_sg_2 web_rule_fn 
   
   [root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=81 -m 
   lbalg=rr,type=HALF-NAT -h hc-name=web_hc,hc-port=8080 -o servergroup=web_sg_2 web_rule_hn
   
   
   

7. Now check the status of the web1 back-end server. This time, the health check works as expected, and web1 is reported as dead. No requests will be sent to web1 anymore.

   
   
   
   [root@ilb-zone]# ilbadm show-hc-res
   RULENAME      HCNAME        SERVERID      STATUS   FAIL LAST     NEXT     RTT
   web_rule_fn   web_hc        _web_sg_2.0   dead     3    12:55:07 12:55:16 586
   web_rule_fn   web_hc        _web_sg_2.1   alive    0    12:55:08 12:55:18 558
   web_rule_hn   web_hc        _web_sg_2.0   dead     2    12:55:02 12:55:14 524
   web_rule_hn   web_hc        _web_sg_2.1   alive    0    12:55:06 12:55:14 511
   
   
   

8. Using Firefox, test to check that only web2 responds.
9. Restart Tomcat on web1 and test again to check that the load balancer will send requests to web1 again.

   
   
   
   [root@ilb-zone]# ssh root@web1-priv svcadm enable tomcat6
   [root@ilb-zone]# ssh root@web1-priv svcs tomcat6
   
   
   

Configure and Test the Load Balancer in DSR Mode

In DSR mode, the back-end servers respond directly without going through the load balancer, so they should have a route to the client.

Prepare the Web Zones

To keep things simple, in this exercise we will simply connect the web zones to the public network (10.5.1.0).

1. Log in to web1 from the global zone:

   
   
   
   [root@kafka]# zlogin web1
   [Connected to zone 'web1' pts/3]
   Oracle Corporation  SunOS 5.11  11.1    September 2012
   You have new mail.
   [root@web1]#
   
   
   

2. Prior to starting the exercises, you configured the zones to have two IP interfaces, but one interface was not configured. Now, configure that interface to connect to our public network:

   
   
   
   [root@web1]# ipadm create-ip web1_1
       
   [root@web1]# ipadm create-addr -T static -a 10.5.1.11/24 web1_1/v4
       
   [root@web1]# ipadm show-addr
   
   
   

3. Define the default route to the public network:

   [root@web1]# route add default 10.5.1.6 -ifp web1_1

4. Now configure the web1 zone so that it responds to requests sent to the VIP address (10.5.1.50):

   
   
   
   [root@web1]# ipadm create-vni vni0
   [root@web1]# ipadm create-addr -T static -a 10.5.1.50/24 vni0/v4vip
   
   
   
   

5. Perform the same operations in zones web2 and web3 by adapting the parameters for the IP interface name and the IP address accordingly:

   
   
   
   [root@web2]# ipadm create-ip web2_1
   [root@web2]# ipadm create-addr -T static -a 10.5.1.12/24 web2_1/v4
   [root@web2]# ipadm show-addr
   [root@web2]# route add default 10.5.1.6 -ifp web2_1
   [root@web2]# ipadm create-vni vni0
   [root@web2]# ipadm create-addr -T static -a 10.5.1.50/24 vni0/v4vip
   
   [root@web3]# ipadm create-ip web3_1
   [root@web3]# ipadm create-addr -T static -a 10.5.1.13/24 web3_1/v4
   [root@web3]# ipadm show-addr
   [root@web3]# route add default 10.5.1.6 -ifp web3_1
   [root@web3]# ipadm create-vni vni0
   [root@web3]# ipadm create-addr -T static -a 10.5.1.50/24 vni0/v4vip
   
   
   

Configure a DSR Load-Balancing Rule in ilb-zone

1. Create a new server group: web_sg_1. The back-end servers are actually the same (web1 and web2), but this time we are using their public IP addresses.

   [root@ilb-zone]# ilbadm create-sg -s servers=web1,web2 web_sg_1

2. Add a load-balancing rule in DSR mode on port 8080:

   
   
   
   [root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=8080 -m 
   lbalg=hash-ip-port,type=DSR -h hc-name=web_hc,hc-port=8080 -o 
   servergroup=web_sg_1 web_rule_dsr
   
   

3. Test DSR mode with Firefox using the URL http://vip:8080/ilbtest.jsp.

   

   Figure 12. Results of testing a load-balancing rule in DSR mode.

   Refresh the page several times (pressing the Shift key to prevent caching).

   Note: In DSR mode, we are no longer using the round-robin algorithm; instead we are using the "source IP, port hash" algorithm. This means that we are not assured that each refresh will send requests to a different back-end server. So if you see the same server responding several times in a row, this is normal behavior.

Add a Server to and Remove a Server from the Back-End Server Group

In this exercise, we will first add the third web server to our server group and then remove one existing server.

Add web3 to the web_sg_1 Server Group

1. Add web3 to the web_sg_1 server group:

   [root@ilb-zone]# ilbadm add-server -s server=web3 web_sg_1

2. Test DSR mode with Firefox using the URL http://vip:8080/ilbtest.jsp.

   You should now see web3 responding to clients if you refresh the page several times.

   

   Figure 13. Test adding a server to the server group.

Remove a Server from the web_sg_1 Server Group

1. Remove web1 from the web_sg_1 server group:

   [root@ilb-zone]# ilbadm remove-server -s server=_web_sg_1.0 web_sg_1

2. Test DSR mode with Firefox using the URL http://vip:8080/ilbtest.jsp.

   You should now see that web1 is no longer responding to client requests and only web2 and web3 respond to client requests.

This ends our lab, but there is still much more to know about the Integrated Load Balancer. To get a deeper understanding of the subject, refer to the Oracle documentation (links are provided in the "See Also" section) and to Appendix A.

Appendix A: More About Network Virtualization and the Integrated Load Balancer

Oracle Solaris Network Virtualization

The Integrated Load Balancer is part of a much bigger picture. Oracle Solaris 11 network virtualization allows you to build any physical network topology inside the Oracle Solaris operating system, including virtual network cards (VNICs), virtual switches (vSwitches), and more-sophisticated network components (for example, load balancers, routers, and firewalls).

Benefits of network virtualization include reduced infrastructure costs and increased speed of infrastructure deployment, since all the network building blocks are based on software, not on hardware.

Figure 14. Example of infrastructure consolidation achieved through network virtualization.

Integrated Load Balancer Features and Capabilities

The Integrated Load Balancer does the following:

• Provides layer 3 and layer 4 load-balancing capabilities for Oracle Solaris 11 on SPARC and x86 systems
• Intercepts incoming requests sent from clients to a virtual IP address, and decides which back-end server should handle the request based on load-balancing rules
• Provides a command-line interface for administration and the libilb library, which enables third-party vendors to create software that uses the Integrated Load Balancer functionality
• Supports stateless Direct Server Return (DSR) and Network Address Translation (NAT) modes of operation for IPv4 and IPv6
• Provides server monitoring capabilities through health checks

The main features of the Integrated Load Balancer include the following:

• Ability to add or remove servers from a server group without interrupting service (NAT)
• Session persistence (stickiness)
• Connection draining
• Load-balancing of TCP and UDP ports
• Ability to specify independent ports for virtual services within the same server group
• Ability to load balance a simple port range
• Port range shifting and collapsing

Integrated Load Balancer Operation Modes

The Integrated Load Balancer provides three operation modes: DSR mode, half-NAT mode, and full-NAT mode.

Figure 15 shows DSR mode. The advantages of DSR mode are that it provides better performance than NAT mode, and it provides full transparency between the server and the client.

Disadvantages of DSR mode include the following:

• The back-end server must respond to both its own IP address (for health checks) and to the virtual IP address (for load-balanced traffic).
• Because it maintains no connection state, adding or removing servers will cause connection disruption.

Figure 15. DSR mode.

Figure 16 shows NAT mode. The following are the advantages of NAT mode:

• It works with all back-end servers by changing the default gateway to point to the load balancer.
• Because the load balancer maintains the connection state, adding or removing servers without connection disruption is possible.

Disadvantages of NAT are that it provides slower performance than DSR and all the back-end servers must use the load balancer as a default gateway.

Figure 16. NAT mode.

Integrated Load Balancer Algorithms

The following algorithms control traffic distribution and server selection:

• Round robin: Requests are assigned to a server group on a rotating basis.
• Source IP hash: A server is selected based on the hash value of the source IP address of the incoming request.
• Source IP, port hash: A server is selected based on the hash value of the source IP address and the source port of the incoming request.
• Source IP, VIP hash: A server is selected based on the hash value of the source IP address and the destination IP address of the incoming request.

See Also

In the Oracle Solaris 11.1 Information Library, you will find the documentation for the Integrated Load Balancer in the Managing Oracle Solaris 11.1 Network Performance manual.

Figure 17. Documentation for the Integrated Load Balancer.

Here are additional resources:

• Download Oracle Solaris 11
• Access Oracle Solaris 11 product documentation
• Access all Oracle Solaris 11 how-to articles
• Learn more with Oracle Solaris 11 training and support
• See the official Oracle Solaris blog
• Check out The Observatory blog for Oracle Solaris tips and tricks
• Follow Oracle Solaris on Facebook and Twitter

About the Author

Amir Javanshir is a Principal Software Engineer working in Oracle's global ISV Engineering team where he focuses on driving technology adoption and integration of Oracle systems technologies by strategic independent software vendors (ISVs). He is currently specializing in virtualization, cloud computing, and enterprise architecture (EA). Amir joined Oracle in 2010 as part of the Sun Microsystems acquisition.

Revision 1.0, 02/12/2014