Project

General

Profile

How to Gateway » History » Version 9

Henning Blohm, 18.09.2012 17:21

1 2 Henning Blohm
h1. How to configure and use the Gateway module
2
3 9 Henning Blohm
The Gateway module implements a "zero-downtime-upgrade" feature in Z2. Specifically, it uses the worker process management of Z2 in conjunction with an intermediate reverse proxy style Web handler to implement the following feature: 
4 2 Henning Blohm
5
Upgrading a stateful Web application, i.e. a Web application that stores user data in its HTTP session typically implies downtime, and if the session state is not serializable and persisted during the upgrade, it does additionally imply that user state gets lost and typically that users need to log on again.
6
7
Using the Gateway, running sessions may be preserved and worker resources may still be assigned on the current software revision for as long as there are running sessions during a node upgrade and until all sessions have been terminated. The typical application of this feature is to roll out functional and user interface corrections without interrupting users. Users can switch over to post-upgrade software by terminating their session (e.g. via a log out) and starting a new one (e.g. by logging in again).
8
9
*Note:*
10
* This feature is relatively new and before you use it in production, you should have carefully tested your scenario.
11
* There are natural limitations to this feature. Upgrades that change the structure or semantics of persisted data or other resources that are shared across nodes cannot be handled this way.
12
13 6 Henning Blohm
h2. A sample on how to use Gateway
14 2 Henning Blohm
15
As described in [[How to run a sample]] please clone the repository "z2-samples.gateway":http://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-gateway and import the contained *environment* module. This module is holding a Gateway configuration as described below. After re-starting your Z2 installation, try the following:
16
17 3 Henning Blohm
1. Open a browser and navigate to http://localhost:8080/z_gateway. Use (by default) user "z*" with password "z".
18
19
You should see this:
20
21
!gateway1.png!
22
23
2. Open another browser window and navigate to http://localhost:8080/adm (same user). Choose the group "Workers" and update.
24
25 4 Henning Blohm
Check for the current worker process and their state. You should see something like this:
26 3 Henning Blohm
27
!admin1.png!
28 1 Henning Blohm
29 4 Henning Blohm
Both web applications application create a HTTP session. Now go back to the Gateway user interface and press "Detach environment/webWorker@0 and sync". On your console you will see that another worker process started (called environment/webWorker@1) and if you update the worker list in the admin interface you should see something like this:
30 1 Henning Blohm
31 4 Henning Blohm
!admin2.png!
32
33
That is: One worker was _detached_ while another one is in state _started_.
34
35
If you now refresh the Gateway user interface you will see that it is still served from *environment/webWorker@0*. Press "log off". You should find that it now switched to *environment/webWorker@1*.
36
37
38
Let's recap: Now we have a session on *environment/webWorker@0* via the admin user interface and one one *environment/webWorker@1* via the Gateway user interface.
39
40
3. Detach *environment/webWorker@1* by clicking "Detach environment/webWorker@1 and sync" on the Gateway user interface.
41
42
When checking the worker list you will now see something like this: 
43
44
!admin3.png!
45
46 5 Henning Blohm
Remember that it is the Gateway user interface that keeps *environment/webWorker@1* alive. If you click on "log off" the session will be terminated, worker *environment/webWorker@1* served its purpose and will terminate, and the Gateway user interface will be served from *environment/webWorker@2*. Checking the worker list you should see something like this:
47
48
!admin4.png!
49 1 Henning Blohm
50
Finally, if you wait 30 minutes until the session of the admin user interface has expired, also *environment/webWorker@0* will terminate.
51
52 7 Henning Blohm
h2. Enabling Gateway
53
54
The sample configuration in "z2-samples.gateway":http://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-gateway has a pre-configured Gateway setup. Here is how this differs from a regular non-Gateway setup:
55
56
h3. The Gateway Web server
57
58 8 Henning Blohm
As explained in the next section, when using Gateway, Z2 runs a Web server on the Home process in addition to Web servers in Web workers. All requests that go normally directly to the Web worker process will instead be handled on the Home process and forwarded appropriately to a Web worker process. 
59 7 Henning Blohm
60
In order to enable this Web server, uncomment the system state participation in "environment/gateway/z.properties":http://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-gateway/revisions/master/entry/environment/gateway/z.properties as done in the sample.
61
62 8 Henning Blohm
The Gateway Web server is configured in "environment/gateway/jetty.xml":http://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-gateway/revisions/master/entry/environment/gateway/jetty.xml. This is a regular Jetty configuration. Instead of being an ordinary Java Web container all requests are handled by a special Gateway Jetty handler. 
63 7 Henning Blohm
64 9 Henning Blohm
The only part of this configuration that could be of interest to be changed is the normal connector settings (ports and concurrency) - just as you normally would tune your Jetty Web server - and the name of the worker process that is to receive the forwarded requests - the _Web worker process_. The latter is defined in this section:
65 7 Henning Blohm
66
<pre><code class="xml">
67
<Set name="handler">
68
  <New id="Handlers" class="org.eclipse.jetty.server.handler.HandlerCollection">
69
    <Set name="handlers">
70
      <Array type="org.eclipse.jetty.server.Handler">
71
        <Item>
72
          <New id="Contexts" class="org.eclipse.jetty.server.handler.ContextHandlerCollection"/>
73
        </Item>
74
        <Item> 
75
          <Call class="com.zfabrik.gateway.GatewayFactory" name="getHandler">
76
            <Set name="workerProcessComponentName">environment/webWorker</Set>
77
          </Call>
78
        </Item>
79
      </Array>
80
    </Set>
81
  </New>
82
</Set>
83
</code></pre>
84
85 1 Henning Blohm
Unless you want to change the name of the target worker process, you do not need to touch Gateway's jetty.xml.
86
87 8 Henning Blohm
h3. The Web worker Jetty configuration
88
89
When enabling Gateway, Web workers should not listen on the same port (default 8080) as Gateway. Also, they should process Gateway requests - which are slightly different than normal HTTP requests. In order to facilitate that, the normal Web server jetty.xml needs to be modified to use the GatewayConnector rather than any of Jetty's normal HTTP connectors. This is done in "environment/webServer/jetty.xml":http://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-gateway/revisions/master/entry/environment/webServer/jetty.xml by commenting the default setting and uncommenting the Gateway configuration. The relevant section looks like this:
90
91
<pre><code class="xml">
92
<!-- Use the gateway connector, when using the Gateway feature. See also gateway/jetty.xml --> 
93
<Call name="addConnector">
94
  <Arg>
95
    <Call class="com.zfabrik.gateway.GatewayFactory" name="getConnector">
96
      <Set name="Acceptors">4</Set>
97
      <Set name="host">127.0.0.1</Set>
98
      <Set name="lowResourcesConnections">20000</Set>
99
      <Set name="lowResourcesMaxIdleTime">5000</Set>
100
    </Call>
101
  </Arg>
102
</Call>
103
</code></pre>
104
105
h3. Running the Gateway user interface
106
107
Finally, in order to actually trigger "Detach & Sync", you should enable the Gateway user interface by adding a dependency to *com.zfabrik.gateway/web* to "environment/webWorkerUp":http://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-gateway/revisions/master/entry/environment/webWorkerUp.properties.
108 1 Henning Blohm
109 6 Henning Blohm
h2. How does Gateway work
110 2 Henning Blohm
111 6 Henning Blohm
Gateway consists of two parts:
112 1 Henning Blohm
113 6 Henning Blohm
h3. The reverse proxy Gateway handler
114 1 Henning Blohm
115 9 Henning Blohm
When using Gateway, there is a Jetty Web server running on the Home process. This Web server maintains a mapping of sessions to Web worker nodes. Any newly created session will be assigned to the latest running Web worker process. All request will be routed to the Web worker process assigned to their session or, if there is no session id on the request, to the latest Web worker process.
116 1 Henning Blohm
117 9 Henning Blohm
On every Web worker process there is another Web server that accepts requests forwarded from the Home process and subsequently treats them as if they were ordinary HTTP requests in the first place.
118 1 Henning Blohm
119 6 Henning Blohm
h3. Detached worker processes
120
121
Apart from being stopped, starting, started, or stopping, Z2 worker processes can also be in _detached_ state. When a worker process is detached, it will terminate itself unless there is still unfinished work. Open Web application sessions is one type of such unfinished work. 
122
123 1 Henning Blohm
In other words, if a worker has no open sessions and is being detached, it will terminate itself right away. 
124
125 6 Henning Blohm
Finally, when the Home process runs a synchronization, detached worker processes do not count as running processes. That is, when the synchronization finds that there is only detached worker process instances of a worker process component, it will start another one.
126
127 9 Henning Blohm
That is why the Gateway user interface will not only detach a worker process but also trigger a synchronization. Here is a diagram illustrating the flow from detach and sync to worker process termination:
128
129
!steady_workers1.png!
130 6 Henning Blohm
131
h2. Ports of worker processes
132
133
Worker processes open ports to receive Web requests but also for JVM debugging and JMX access. These ports are configured in the worker process component definition. See for example "environment/webWorker":http://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-gateway/revisions/master/entry/environment/webWorker.properties. These ports are actually base port numbers and the real port to be used is computed from a _generation_ number that is also part of the worker process instance name that you saw above. I.e. the instance name *environment/webWorker@2* is generation 2 of the worker process component *environment/webWorker*.
134
135
The port configurations in worker process components are:
136
137
|_. Property |_. Description |_. Typical value |
138
|worker.debug.port| Base port of the JVM debug port to use. If the home process has remote debugging enabled, worker processes will also be configured for remote debugging.|5100 in environment/webWorker|
139
|worker.jmx.port|Base port of the remote JMX access. Will be ignored if no JMX access configured|7800 for environment/webWorker|
140
|com.zfabrik.gateway.port|Base port of the web worker side of Gateway. Will only listen to localhost and only be used, if Gateway is configured|8800 in environment/webWorker|