test

Sun Java System Reference Configuration Series: Portal Service on Application Server Cluster

Implementing Load Balancing for the Gateway Service

This task consists of the following procedures:

ProcedureTo Configure the Load Balancer for the Gateway Service

This procedure describes how to configure the Gateway service load balancer (sra.pstest.com at IP address 10.0.5.10). The steps are relatively generic; the details depend on the load balancer you are using.

  1. Populate the load balancer's Hosts Table.

    Add the IP address for sra1.pstest.com and sra2.pstest.com to the load balancer's hosts table.

  2. Populate the load balancer's Real Service Table.

    Add the real services for sra1.pstest.com and sra2.pstest.com. A real service is identified by its IP address and port. Add 10.0.4.1:443 and 10.0.4.2:443.

  3. Populate the load balancer's Service Group Table.

    Add the service group for Gateway services. The service groups are sets of the real services that you defined in Step 2. The real services in the group must be capable of fulfilling the same type of request. The load balancer will distribute requests among the real services in the service group. When you define the service group for the sra.pstest.com, you add the real services that specify the Gateway instances, 10.0.4.1:443 and 10.0.4.2.443.

  4. Set the load balancer to perform certificate authentication.

    1. Generate an SSL key and certificate request.

      Use the certificate and key manager (CKM) on the load balancer.

    2. Obtain a valid X.509 certificate.

      Submit the certificate signing request (CSR) to an authorized certificate authority (CA). Alternatively, the load balancer might have a utility for generating a test certificate.

    3. Install the X.509 certificate.

      The method for installing the certificate depends on the load balancer.

  5. Populate the load balancer's Virtual IP Table.

    A virtual service definition includes the outward-facing IP address and the port at which the load balancer accepts requests for a service, as well as the service group that you specified in Step 3, which actually handles the requests. The load balancer will accept requests at the virtual service address and distribute them among the service group. The virtual service definition for the Gateway service should be sra.pstest.com, with the virtual IP address of 10.0.5.10:443, and with the service group consisting of the computers sra1.pstest.com and sra2.pstest.com.

  6. Configure the load balancer to use Layer-7 (HTTP layer) load balancing.

  7. Configure the load balancer with a scheduling type of either least connections or round robin.

    Both scheduling types initially distribute the connections evenly between the Portal Server instances. Both scheduling types keep the connections evenly distributed if the connections are restarted.

  8. Configure the load balancer for sticky routing.

    Although not mandatory, it is good practice to maintain a binding between the user's session and the Gateway instance that processed the user's initial request. Gateway instances keep, in cache, the Access Manager sessions that are associated with user requests. If there is no session persistence on the Gateway instances, user requests are routed randomly to the Gateway instances, and every instance caches every user session. This duplication creates additional network traffic whenever a Gateway instance needs to refresh a session. It also leads to unnecessary memory use by the Gateway instances.

    Configuring the Gateway service load balancer to maintain session persistence with the Gateway instances will prevent these problems.

    In the reference configuration, Internet users access the portal service over HTTPS connections to the Gateway service. When users connect over HTTPS, the requests, including any session persistence cookies that help a load balancer route the traffic to the correct instance, are encrypted. The information in the cookies is not available to the load balancer for routing purposes. The following are two ways of handling this situation in the Gateway service load balancer:

    • SSL termination

      If the load balancer supports SSL termination, then the load balancer can perform all the encryption and decryption work that is needed to terminate SSL at the load balancer. Terminating SSL at the load balancer reduces the load on the Gateway instances and improves performance. When the load balancer decrypts an HTTPS request, the session cookie is available to the load balancer. If the load balancer supports passive cookies, it can be configured to maintain session persistence. This approach is the preferred way to configure a load balancer for sticky routing.

      If the load balancer does not support passive cookies, session persistence can be maintained by using the client IP address. However, if multiple users are using a web proxy to reach the Gateway service load balancer, the IP address that the load balancer will see is the IP address of the web proxy. In this case, all users who are using the same web proxy will be routed to the same Gateway instance, possibly resulting in an uneven load on the Gateway instances.

    • SSL session ID

      If the load balancer does not support SSL termination, then it cannot read the session cookie. In this case, you can configure the load balancer to read the SSL session ID and make routing decisions based on the value of the session ID.

  9. Configure the health-check settings for the load balancer.

    The recommended settings are specified in Table 3–5.

ProcedureTo Configure the Gateway Service on sra1 for Load Balancing

If SSL sessions are terminated at the Gateway service load balancer, the traffic between the load balancer and the Gateway instances are plain HTTP. In that case, it is necessary to configure the Gateway instances to use the load balancer's virtual name (sra.pstest.com) and protocol (HTTPS) in all content that is rewritten.

You do so by configuring the attributes on the platform.conf file that is associated with the profile that the Gateway instance is using.

  1. Open the platform.conf file on sra1 in a text editor.

    The file is located at:

    /etc/opt/SUNWportal/platform.conf.default

  2. Modify the following properties as follows:


    gateway.enable.customurl=true 
gateway.enable.accelerator=true 
gateway.httpurl=https://sra.pstest.com:443 
gateway.httpsurl=https://sra.pstest.com:443
gateway.virtualhost=sra.pstest.com 10.0.5.10

  3. Restart the Gateway instance on sra1.

    1. Stop the Gateway instance on sra1.

      # /opt/SUNWportal/bin/psadmin stop-sra-instance -u amadmin -N default -t gateway

      When prompted, type the access-manager-admin-password.

    2. Start the Gateway instance on sra1.

      # /opt/SUNWportal/bin/psadmin start-sra-instance -u amadmin -N default -t gateway --restrictive

      When prompted, type the access-manager-admin-password.

  4. Verify that the Gateway instance is running in non-SSL mode.

    # telnet 10.0.4.1 443

    GET / HTTP/1.1 <carriage return>

    HOST:sra.pstest.com <carriage return>

    Connection:Close <carriage return>

    <carriage return>

    The response should resemble the following:


    HTTP/1.0 302 Moved Temporarily
Date: Fri. 08 Feb 2008 21:27:00 GMT
Server: Redirector
Location: https://sra.pstest.com/http://am.pstest.com/amserver/UI/Login?qw=&...

ProcedureTo Configure the Gateway Service on sra2 for Load Balancing

  1. Repeat the procedure in except for the following:

    • Replace all occurrences of sra1 with sra2.

    • Replace 10.0.4.1 with 10.0.4.2.

ProcedureTo Verify Load Balancing for the Gateway Service

This procedure verifies that you can interact with Gateway instances through the load balancer and that the load balancer provides service failover when a Gateway instance fails.

  1. Start the Gateway instances on sra1 and sra2, if they are not already running.

    # /opt/SUNWportal/bin/psadmin start-sra-instance -u amadmin -N default -t gateway --restrictive

    When prompted, type the access-manager-admin-password.

  2. Start a browser.

  3. Go to the Access Manager login page by using the load balancer URL

    http://sra.pstest.com

    The Access Manager login page opens.

  4. Log in to the portal by typing the following values and clicking Login.

    Input Field 

    Value 

    User ID 

    developer 

    Password 

    developer 

    The Developer Sample desktop opens, which confirms that the load balancer has routed the login request to one of the Gateway instances.

  5. Determine the Gateway instance handling the login request in Step 4.

    1. Open the log file on sra1.

      # cd /var/opt/SUNWportal/logs/sra/default

      # tail —f portal.gateway.0.0.log

    2. Open the log file on sra2.

      # cd /var/opt/SUNWportal/logs/sra/default

      # tail —f portal.gateway.0.0.log

    3. Note which log file displays more output.

      Whichever Gateway instance is servicing the request will cause more output to be generated.

  6. Simulate a failure of the Gateway instance that was noted in Step 5.

    In the configuration interface for your load balancer (sra.pstest.com), disable the Gateway instance that you identified in Step 5 (or otherwise remove it from the service group).

  7. Refresh the browser page.

    If service failover is working correctly, the Access Manager login page opens, confirming that the load balancer has routed the request to the remaining online Gateway instance.

  8. Recover the simulated failure of your original Portal Server instance.

    Return to the configuration interface for your load balancer, and replace the real server instance that you removed in Step 6 to the load balancer service group.