📄 resin-clustering.xtp
字号:
<document><header><title>Resin Clustering</title><description><p>Resin's HTTP Web Server includes load balancing for scalabilityand reliability.</p></description></header><body><localtoc/><s1 name="resin" title="Using Resin as the Load Balancer"><p>Resin Professional includes a<a href="javadoc|com.caucho.servlets.LoadBalanceServlet">LoadBalanceServlet</a>that can balance requests to backend servers.Because it is implemented as a servlet,this configuration is the most flexible. A site might use 192.168.0.1 as the frontend load balancer, and send all requests for /foo to the backend host192.168.0.10 and all requests to /bar to the backend host 192.168.0.11. SinceResin has an integrated HTTP proxy cache, the web-tier machine can cacheresults for the backend servers.</p><p>Load balancing divides the Resin servers into two clusters:the web-tier and the app-tier. In Resin 3.1, all the cluster and load balance configuration is in a single resin.xml.The actual deployed server is selected with the "-server web-a"<a href="config-cmdline.xtp">command-line argument</a>.</p><p>Using Resin as the load balancing web server requires a minimumof two clusters: one for the load balancing server, and onefor the backend servers. The front cluster will dispatchto the backend servers, while the backend will actually serve therequests. Both clusters can be defined in the same resin.xml file.</p><figure src="cluster-load-balance.png"/><s2 title="The web-tier server does the load balancing"><p>In the following example, there are three servers and two clusters. Thefirst server "web-a" (192.168.0.1), which is in cluster "web-tier",is the load balancer. It has an <http> listener, receives requests from browsers, and dispatches them to the backendservers "app-a" and "app-b" (192.168.0.10 and 192.168.0.11).</p><example title="Example: resin.xml for load balancing"><resin xmlns="http://caucho.com/ns/resin"><cluster id="web-tier"> <server-default> <http port="80"/> </server-default> <server id="web-a" address="192.168.0.1" port="6800"/> <cache disk-size="1024M" memory-size="256M"/> <host id=""> <web-app id="/"> <!-- balance all requests to cluster app-tier --> <rewrite-dispatch> <load-balance regexp="" cluster="app-tier"/> </rewrite-dispatch> </web-app> </host></cluster><cluster id="app-tier"> <server id="app-a" address="192.168.0.10" port="6800"/> <server id="app-b" address="192.168.0.11" port="6800"/> <persistent-store type="cluster"> <init path="cluster"/> </persistent-store> <web-app-default> <session-config> <use-persistent-store/> </session-config> </web-app-default> <host id="www.foo.com"> ... </host></cluster></resin></example><p>TheLoadBalanceServlet selects a backend server using a round-robin policy.Although the round-robin policy is simple, in practice it is as effective ascomplicated balancing policies. In addition, because it's simple, round-robinis more robust and faster than adaptive policies. </p></s2><s2 title="The backend server respond to the requests"><p>The backend servers belong to the "app-tier" cluster.In this case, there are two backend servers, "app-a" and "app-b". Theserver names must be unique and also the <address,port> pair mustbe unique because TCP will not allow two processes to listen toexactly the same port and address combination. If you have twobackend servers on the same machine, they must have different ports,like 6801 and 6800. In other words, you can have <192.168.0.10,6800>and <192.168.0.11,6800> on separate machinesor you can have <192.168.0.10,6800> and <192.168.0.10,6801>on the same machine.</p><p>Because the backend cluster all serves the same content, the <host> and<web-app> configuration is identical. Only JVM-specific configurationlike ports, addresses, and memory configuration belongs to the server.</p><p>Sites using sessions willoften configure <a href="config-sessions.xtp">distributedsessions</a> to make that the load balancer's failover will ensure a smoothswitch of sessions from one backend to another.</p></s2><s2 title="Starting the servers"><example title="Starting each server">192.168.0.1> java -jar lib/resin.jar -server web-a start192.168.0.10> java -jar lib/resin.jar -server app-a start192.168.0.11> java -jar lib/resin.jar -server app-b start</example></s2></s1> <!-- resin --><s1 title="Dispatching"><p>In most cases, the web-tier will dispatcheverything to the app-tier servers. Because of Resin's<a href="proxy-cache.xtp">proxy cache</a>, the web-tier serverswill serve static pages as fast as if they were local pages.</p><p>In some cases, though, it may be important to send differentrequests to different backend clusters. The<<a href="rewrite-tags.xtp#load-balance">load-balance</a>> tag canchoose clusters based on URL patterns.</p><p>The following <<a href="rewrite-tags.xtp">rewrite-dispatch</a>>keeps all *.png, *.gif, and *.jpg files on the web-tier, sendseverything in /foo/* to the foo-tier cluster, everything in /bar/* tothe bar-tier cluster, and keeps anything else on the web-tier.</p><example title="split dispatching"><resin xmlns="http://caucho.com/ns/resin"> <cluster id="web-tier"> <server id="web-a"> <http port="80"/> </server> <cache memory-size="64m"/> <host id=""> <web-app id="/"> <rewrite-dispatch> <dispatch regexp="(\.png|\.gif|\.jpg)"/> <load-balance regexp="^/foo" cluster="foo-tier"/> <load-balance regexp="^/bar" cluster="bar-tier"/> </rewrite-dispatch> </web-app> </host> </cluster> <cluster id="foo-tier"> ... </cluster> <cluster id="bar-tier"> ... </cluster></resin></example></s1><s1 title="Distributed Sessions"><p>A session needs to stay on the same JVM that started it.Otherwise, each JVM would only see every second or third request andget confused.</p><p>To make sure that sessions stay on the same JVM, Resin encodes thecookie with the host number. In the previous example, the hosts wouldgenerate cookies like:</p><deftable><tr> <th>index</th> <th>cookie prefix</th></tr><tr> <td>1</td> <td><var>a</var>xxx</td></tr><tr> <td>2</td> <td><var>b</var>xxx</td></tr><tr> <td>3</td> <td><var>c</var>xxx</td></tr></deftable><p>On the web-tier, Resin will decode the cookie and send itto the appropriate host. So <var>bacX8ZwooOz</var> would go to app-b.</p><p>In the infrequent case that app-b fails, Resin will send therequest to app-a. The user might lose the session but that's a minorproblem compared to showing a connection failure error. To save sessions,you'll need to use <a href="config-sessions.xtp">distributed sessions</a>.Also take a look at <a href="tcp-sessions.xtp">tcp sessions</a>.</p><p>The following example is a typical configuration for a distributedserver using an external hardware load-balancer, i.e. where each Resin isacting as the HTTP server. Each server will be startedas <var>-server a</var> or <var>-server b</var> to grab its specific configuration.</p><p>In this example, sessions will only be stored when the server shuts down,either for maintenance or with a new version of the server. This is the mostlightweight configuration, and doesn't affect performance significantly.If the hardware or the JVM crashes, however, the sessions will be lost.(If you want to save sessions for hardware or JVM crashes,remove the <save-only-on-shutdown/> flag.)</p><example title="resin.xml"><resin xmlns="http://caucho.com/ns/resin"><cluster id="app-tier"> <server-default> <http port='80'/> </server-default> <server id='app-a' address='192.168.0.1'/> <server id='app-b' address='192.168.0.2'/> <server id='app-c' address='192.168.0.3'/> <persistent-store type="cluster"> <init path="cluster"/> </persistent-store> <web-app-default> <!-- enable tcp-store for all hosts/web-apps --> <session-config> <use-persistent-store/> <save-only-on-shutdown/> </session-config> </web-app-default> ...</cluster></resin></example></s1><s1 title="Choosing a backend server"><p>Requests can be made to specific servers in the app-tier. The web-tier usesthe value of the jsessionid to maintain sticky sessions. You can include anexplicit jsessionid to force the web-tier to use a particular server in the app-tier.</p><p>Resin uses the first character of the jsessionid to identify the backend serverto use, starting with `a' as the first backend server. If wwww.example.comresolves to your web-tier, then you can use:</p><ol><li>http://www.example.com/proxooladmin;jsessionid=abc</li><li>http://www.example.com/proxooladmin;jsessionid=bcd</li><li>http://www.example.com/proxooladmin;jsessionid=cde</li><li>http://www.example.com/proxooladmin;jsessionid=def</li><li>http://www.example.com/proxooladmin;jsessionid=efg</li><li>etc.</li></ol></s1><s1 title="<persistent-store>"><p>Configuration for persistent store usesthe <a href="resin-tags.xtp#persistent-store">persistent-store</a> tag.</p></s1><s1 title="File Based"><ul><li>For single-server configurations</li><li>Useful in development when classes change often</li></ul><p>Persistent sessions are configured in the <var>web-app</var>.File-based sessions use <var>file-store</var>.</p><example><web-app xmlns="http://caucho.com/ns/resin"> <session-config> <file-store>WEB-INF/sessions</file-store> </session-config></web-app></example><p>Sessions are stored as files in the <var>file-store</var>directory. When the session changes, the updates will be written tothe file. After Resin loads an Application, it will load the storedsessions.</p><p>File-based persistence is not useful in multi-serverenvironments. Although a network filesystem such as NFS will allow allthe servers to access the same filesystem, it's not designed for thefine-grained access. For example, NFS will cache pages. So if oneserver modifies the page, e.g. a session value, the other servers may not seethe change for several seconds.</p></s1><s1 title="Distributed Sessions"><p>Distributed sessions are intrinsically more complicated than single-serversessions. Single-server session can be implemented as a simple memory-basedHashtable. Distributed sessions must communicate between machines to ensurethe session state remains consistent.</p><p>Load balancing with multiple machines either uses <var>sticky sessions</var> or<var>symmetrical sessions</var>. Sticky sessions put more intelligence on theload balancer, and symmetrical sessions puts more intelligence on the JVMs.The choice of which to use depends on what kind of hardware you have,how many machines you're using and how you use sessions.</p><p>Distributed sessions can use a database as a backing store, or they candistribute the backup among all the servers using TCP.</p><s2 title="Symmetrical Sessions"><p>Symmetrical sessions happen with dumb load balancers like DNSround-robin. A single session may bounce from machine Ato machine B and back to machine B. For JDBC sessions, the symmetricalsession case needs the <var>always-load-session</var> attribute described below.Each request must load the most up-to-date version of the session.</p><p>Distributed sessions in a symmetrical environment are required to makesessions work at all. Otherwise the state will end up spread across the JVMs.However, because each request must update its session information, it isless efficient than sticky sessions.</p></s2><s2 title="Sticky Sessions"><p>Sticky sessions require more intelligence on the load-balancer, butare easier for the JVM. Once a session starts, the load-balancer willalways send it to the same JVM. Resin's load balancing, for example, encodesthe session id as 'aaaXXX' and 'baaXXX'. The 'aaa' session will always goto JVM-a and 'baa' will always go to JVM-b.</p><p>Distributed sessions with a sticky session environment add reliability.If JVM-a goes down, JVM-b can pick up the session without the usernoticing any change. In addition, distributed sticky sessions are moreefficient. The distributor only needs to update sessions when they change.So if you update the session once when the user logs in, the distributedsessions can be very efficient.</p></s2><s2 title="always-load-session"><p>Symmetrical sessions must use the 'always-load-session' flag toupdate each session data on each request. always-load-session is only⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -