Re: Load balancing ????

[sachin mahajan]

hello yes it is possible to do the load balancing in orion i am attching one html file just go through if. In case u want more help just reply me.   bye sachin ----- Original Message ----- From: Mahesh M Kagalkar To: Orion-Interest Sent: Friday, February 01, 2002 8:01 PM Subject: Load balancing ???? Dear Sir, Currently Iam working in a project which is using Orion server.This is for the first time Iam using this server.Can you please tell me how to do load balancing in Orion?Is load balancing possible in Orion? Waiting for your reply.. regds Mahesh K ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mahesh M Kagalkar Ionidea Enterprise Solutions pvt ltd. 38-40, Export Promotion IndustrialPark, Whitefield, Bangalore-560 066 Voice : 8411366-71 Fax : 8411391 E-mail :       [EMAIL PROTECTED]              [EMAIL PROTECTED]                           [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Title: Orion HTTP Clustering

Orion HTTP Clustering and Load Distribution $Revision: 1.0 $ This document will show you how to set up HTTP Clustering and Load Distribution using the Orion application server.  Note: This article assumes that you are familiar with how to use Orion. Introduction Before you start, make sure you have downloaded and installed the following software on at least 2 servers: Java Development Kit (1.2 or later) Orion (1.3.5 or later) You also need a network with operational multicast facilities. If you don't have access to 2 servers but want to test this, you can install 2 Orions on the same box and make sure that they are not using the same ports for the RMI server and for the HTTP server. This article has the following sections: Introduction Introduction to clustering State replication Cluster islands Load distribution Setting up a load distributed cluster with Orion Step 1: Install your web-application on all the Orions in your cluster Step 2: Set up your web-application to replicate its state Step 3: Configure your cluster islands Step 4: Tell the back-ends about the load balancer Step 5: Starting and using the load balancer Step 6: Start the back-ends Step 7: Test it To do If you already know about clustering and load distribution in general and just want to know the steps to set it up for Orion, you may skip to Setting up a load distributed cluster with Orion. Introduction to clustering For at least two reasons you often want your web site to be served by more than one web server: Fault tolerance Handling larger loads than one server can survive The act of letting two individual servers work together to perform one task is often referred to as clustering. Clustering is an essential piece to solving the needs for today's large websites. State replication Originally, HTTP was designed as a stateless protocol. Every request had all the info the server needed to perform a certain task. Doing clustering for a stateless system is trivial and only requires that a request can be handled by more than one server that share the same document hierarchy. In today's world, the picture is not as simple. The need for user sessions with data stored on the server about a specific website user resulted in the invention of the HTTP cookie. A cookie is a way for a web server to store data in the web browser. This cookie is passed back to the server on later requests. This is often used to associate some data on the server (state) with a specific user. A typical example is that of a webshop shopping cart. The user adds the goods he wish to purchase to the cart and the server associates the user's cookie with a certain cart stored on the server. As you might have guessed this means that clustering gets somewhat more complex. It is no longer enough that the document hierarchy is shared between the web servers, but now the state stored on a server will mean that requests sent to different servers will result in different results. Somehow we need to solve that. There are two obvious solutions to the problem: When a web site user has any state on the server associated with him, make sure that he always get directed to the server which holds his state. If the server can no longer respond, for any reason, let him log in again to a new server. Replicate all state on a server to at least one other server. Make sure the user gets send to a server that holds "his" state. If his original server goes down, he will transparently be redirected to a server that has the backup of his state. What we see is that option 1 does not provide maybe the most important reason for clustering, fault tolerance. When a server fails the user will have to start over, which might result in him giving up and leaving the site. For this reason option 2, state replication is often required. Cluster islands As mentioned in the previous section, state should be replicated to at least one other server. However, it is not necessary to replicate all state to every single server. For this reason we are using cluster islands, where an island means a set of servers that share the same state. In a system with 3 islands with 2 servers each, it means that the state for every server will be backup up to one other server. Load distribution Load distribution or load balancing (these terms will be used to mean the same thing in this document) means that some process (front-end) acts as a distributor of requests and send different requests off to different servers, or back-ends. As we discussed in the previous section, this might not be a simple task of just choosing a back-end at random but might involve identifying the user before knowing which backend will be suited to handle the specific request. We will later show how the Orion load balancer behaves to perform this task. Setting up a load distributed cluster with Orion Now we will set up Orion for clustering and load distribution step-by-step. Step 1: Install your web-application on all the Orions in your cluster First, make sure that the Orions you are using in your cluster has the same web-application installed. If you do not want this in two places, you can place the actual web-application on a shared drive that both servers access. When you have done this, start all your Orions and check that the web-applications are working correctly on all of them. Step 2: Set up your web-application to replicate its state Secondly, we want to make sure that the web-application to be clustered is replicating its state to the cluster. We do this by editing the orion-web.xml deployment descriptor for that web-app (orion/application-deployments/[application-name]/[web-app-name]/orion-web.xml). If you want to add clustering for the whole website (for all web-applications), edit the orion-web.xml of the global web-application (NOTE: it will not be applied to all web-applications previous to Orion 1.3.6). This file is normally located at orion/config/global-web-application.xml. All you need to do with this file is adding the following to the main body of the <orion-web-app> tag: <cluster-config/> And save the file. For complete syntax on the cluster-config tag, look here. The settings you can do it to Specify the multicast host/ip to transmit and receive cluster data on (default is 230.0.0.1) Specify the port to transmit and receive cluster data on (default is 9127) Specify the id (number) of this cluster node to identify itself with in the cluster. The default is based on local machine IP. Repeat this step for all the Orions in your cluster. Setting this up will mean that the following is replicated: The HttpSession data (as long as it is Serializable or an EJB reference). Note however, that if the EJBs are located on a server that goes down, the references might become invalid The ServletContext data When using multiple islands you might want to use different multicast IPs, to enable "smart" routing of multicast packets in your network and just send traffic on certain IPs to certain servers. Step 3: Configure your cluster islands Cluster islands are discussed in an earlier section. Cluster islands are connected to a certain site rather than to a web-application and to configure a cluster island, edit the web-site.xml file for the website your web-application is deployed on (for example default-web-site.xml if you are clustering the default web-application). Add the following to the <web-site> tag: cluster-island="1" If your cluster has more than one island, you will specify different island values for the servers that belong in different islands. Also, if you do not already specify what host the web-site is serving using the host="host/ip" attribute in the <web-site> tag you need to do that. This is because it is not reliable to get the IP of the local host on all platforms, so the back-end needs to tell the front-end about its IP in some other way. Step 4: Tell the back-ends about the load balancer In the same file, the web-site.xml for your web site, you also specify where the load distributor for this web-site is located. In the main body of the <website> tag, add: <frontend host="balancer-host" port="balancer-port" /> Where balancer-host should be replaced with the hostname of the server which will be running the load distributor and balancer-port with the port that will be used for the same. This host and port will make up the public hostname for the site, so port 80 is a good suggestion. Step 5: Starting and using the load balancer To start the load balancer, simply run java -jar loadbalancer.jar. This will start the load balancer on port 80 on all IP:s on the server its started on. The load balancer can be configured in a few ways. The settings can either be set in the load-balancer.xml file, or they can be given as arguments to the loadbalancer.jar application. The syntax for the configuration file is available here. The usage for loadbalancer.jar is: -host - host/address to listen to for HTTP connections (All by default) -port - port to listen to for HTTP connections (80 by default) -dontUseSessionID - tells the balancer not to scan for Servlet session IDs as a means of identifying clients (useful for instance balancing SSL sites) -dontUseIP - tells the balancer not to route connections based on IP if no session exists/is scanned for -dontUseKeepAlives - tells the balancer not to maintain keep-alives. This is useful if number of open sockets/used threads is a problem on the balancer but it will increase network traffic and CPU usage (and slow down client requests). -minimumIsland - the minimum island to add to alive servers list, useful when using several balancer instances -maximumIsland - the maximum island to add to alive servers list, useful when using several balancer instances -selectiontype - how to select servers, the default is random, options are: 'random', 'first' -debug - log information to the console regarding the progress of the load balancer. NOTE: Defining hosts in load-balancer.xml is not recommended unless it's during the testing phase or in a severely constrained environment. Doing so will make the system static rather than dynamic, and new/restarted servers will not be detected by the loadbalancer. The recommended setup is to have the servers register themselves in the loadbalancer dynamically as described below. This will take them out of service when they go down and make them available for requests once they come back up again as intended. The usage can also be gotten by typing java -jar loadbalancer.jar -?. By default the behavior of the load balancer is like this: If a new request is made from an IP that has not connected to the site before and that has no session associated with it, it will send off the user to a random back-end. If a request is made from an IP that has already been "talking" to the website, the request will get sent to the same server as the previous request, unless you have specified that requests will not be routed based on IP (-dontUseIP as command line option or use-ip="false" in load-balancer.xml If a request is made within a Keep-Alive socket, the request will get sent to the same server as the previous request, unless you have specified that Keep-Alives should not be used (-dontUseKeepalives as command line option or use-keepalives="false" in load-balancer.xml If a request if made from a user with a session. The request to the primary server for that session. If the primary server for the session does not respond, the request will be sent to another server in the same island. Since the state has been replicated the other server has the same user state. If a request to the proper server fails, the request will be sent to another server. The Load balancer (as does all clustering services) requires multicast to work, and to make sure that it works, the first time it might be a good idea to start the load balancer with the -debug switch to see that it receives messages correct on the multicast socket. When you are using -debug you will see extra information regarding the progress. Step 6: Start the back-ends Now start the Orions that acts as back-ends in the normal manner (java -jar orion.jar). Now you should soon see that the back-ends get registered with the load balancer. If they do not, a good thing to check is if you are using some dialup-connection from the server that blocks multicast sockets. To see additional info about the progress of the back-ends you can start them using java -Dhttp.cluster.debug=true -Dcluster.debug=true -jar orion.jar Step 7: Test it Now we are done with setting it up and we can test that it works. Access the loadbalancer's host and port with your web-browser and you will hopefully see how the request is sent off to one of the back-end servers. Now, if you request the same page again from the same client you will probably be sent to the same server again (see Step 5 about the behavior of the load balancer), but if you request the same page from different clients you will see that the requests get balanced. To test the state replication you can try accessing /servlet/SessionServlet. Request it one time first. Check which server that becomes the primary server for this session. Shut that server down, or try something ruder like removing the network cable from it or simply get out an axe and destroy its hard-drive (if the latter option is chosen, we will not be accepting any responsibility for any permanent damage this might cause to the hard-drive) and then try to request the /servlet/SessionServlet again. If everything works you will now get to the same session as before and the counter will be updated correctly. To do Provide more sample scenarios, and load balancing with SSL. Show how to use third party products, like Resonate's SLB-Now to perform the load balancing. Show how to use hardware, like the appliances from Alteon and Cisco to provide load balancing. Show how to enhance the load balancing by providing other load balancing algorithms and providing load data to the load balancer (not implemented yet). Explain how to combine the HTTP clustering with EJBs. Thanks go to Ernst de Haan for providing the layout used by this document $Revision: 1.0 $ $Date: 2000/09/08 22:10:08 $