| | 56 | |
| | 57 | = Availability = |
| | 58 | |
| | 59 | == Old situation == |
| | 60 | |
| | 61 | In the old situation the tomcat-clarin was running as a single instance behind apache. The path /mw/* is mounted in apache by mod_jk and all requests here are forwarded to the tomcat-clarin via the AJP13 protocol. The idp location “/discojuice/idp.html” is rewritten to “/mw/…” to provide a stable entry point for users of the service and remain flexible in the backend. This setup does not provide any redundancy and maintenance has to be performed in the running production service. |
| | 62 | |
| | 63 | == New situation == |
| | 64 | |
| | 65 | To overcome the effects of maintenance on the running production service we propose the following setup (with options for more enhancements in the future), as shown in Figure 2: new setup. |
| | 66 | |
| | 67 | In this setup two tomcat instances (tomcat-clarin1 and tomcat-clarin2) are mounted in apache with mod_jk as /mw1/* and /mw2/*. With the apache rewrite rule we can choose which of the two instance is active and this allows us to perform maintenance and testing on the other instance without disruption of the live instance. When maintenance is completed the rewrite rule is changed to point to the updated instance which then becomes live and we can easily update the other instance. |
| | 68 | |
| | 69 | == Future possibilities == |
| | 70 | |
| | 71 | The proposed setup can easily be improved by a number of steps: |
| | 72 | * Split the apache in tomcat instances over different (virtual) machines. Providing a working service if one of the tomcat machines would crash. |
| | 73 | * Make the apache instance redundant and configure a H/A solution (e.g. heartbeat + virtual IP) where the backup instance can take over if the live instance crashes. |
| | 74 | * Configure load balancing from apache to the tomcat-instances. |
| | 75 | * Configure load balancing in front of the apache instances (e.g. use ultramonkey ). |
| | 76 | |
| | 77 | Although these steps will increasingly provide high availability of the service we want to start simple and discuss what options are necessary to provide later on. |
| | 78 | Maintenance Policy |
| | 79 | |
| | 80 | Next to the technical changes we would like to propose two policies to improve communication about maintenance. |
| | 81 | |
| | 82 | 1. Maintenance on the WAYF and IDP services will be announced 1 week in advance on the (dev)mailing list. |
| | 83 | |
| | 84 | 2. We will plan maintenance in such a way that the day after a system administrator is available (unless something unexpected happens, e.g. breaking a leg or something). |
| | 85 | |
| | 86 | 3. Moreover in the case of a failure of the discojuice service we want to test the possibility to provide a rewrite of the production login endpoint to a backup (old-style) WAYF we host as well. |
