For this section, the topic centers on shoring up the WebAccess system and making it more scalable and fault tolerant. With only one WebAccess Application and Agent running, users would be unable to access their mailboxes through WebAccess if either of these components fails. With multiple agents set up and being serviced by multiple applications, the overall WebAccess availability will be greatly enhanced. It also allows you to bring down pieces of the WebAccess system, without interrupting all access to users' mailboxes. This is useful for upgrades, or for maintenance on anything from the GroupWise system to servers to other applications running on the servers. This section begins by discussing what is involved in getting multiple agents and application services working together. Configuring Multiple Agents and Application Servers for a Fault-Tolerant WebAccess SystemWith WebAccess, administrators can set up multiple agents and applications that all work together. This section explores how to configure a single application to talk to multiple agents. It also discusses how configuring multiple agents can provide a fault-tolerant WebAccess system. With a simple install of WebAccess, you have only one WebAccess Application talking to a single WebAccess Agent. Very little changes when you consider setting up an application for talking to multiple agents. Consider the following sample scenario that discusses how to make it all work together. You want to have the WebAccess Application on your Web server communicate with two WebAccess Agents. These agents are installed in close proximity to the two major sections of your WAN. In this scenario, you will see how to configure and set this up. Before we explain exactly how to configure and set up this scenario, it is very important that you understand how a WebAccess Application determines which agent or agents it should communicate with. When there is more than one WebAccess Agent installed in your GroupWise system, the application must check to see which agent the user should be directed to. Chapter 5, "Working with GroupWise Objects," mentioned that you can configure a default WebAccess object for a domain or post office. Configuring a default WebAccess setting on users' domains or post offices is a key aspect of setting up multiple agents in a GroupWise system. In fact, we recommend that if you have slow WAN links, you install WebAccess Agents in close network proximity to GroupWise post offices. Sure you may need to create a special-purpose domain to house the WebAccess Agent, but that's no problem. One customer has some 30 post offices over slow WAN links. So they created 30 special-purpose domains just to accommodate the WebAccess Agents. Those domains actually reside on the same servers where the post offices are. Here is the order in which the application will check to determine which WebAccess Agent to log a particular user to:
If this agent is down, it cycles to the next defined Provider agent in the WEBACC.CFG. In our case it is Provider.GWAP.Default.address.2=137.65.55.212:7205 If none of the defined Provider agents is accessible, the last resort is to check the agent listed inside the COMMGR.CFG file. If this agent is down, the user cannot log in. Phew, that is quite a process! The next section breaks this process down into a few scenarios to make sure you understand how the lookup/failover model works. Lookup/Failover List: Scenario 1Presume that you have three agents installed in your GroupWise system, all being serviced by one WebAccess Application:
With this configuration, when a user logs in, the application builds a list of WebAccess Agents that it uses to send the user's request to. If any of these agents are down, the application cycles to the next agent in the list. The following table shows the list that the application builds regarding which agent this user should be sent/failed over to:
Because there is an agent defined for the user's post office (Agent 1), this is the first agent that the application tries to access. If this agent is down, it sends the user to the first agent listed in the service provider list (Agent 2). If both of these agents are down, it sends the request to the agent listed in the COMMGR.CFG file. Note Technically, two agents are listed as Providers in this example (Agent 1 and Agent 2). Because the Application finds the same Agent twice (Agent 1) from the post office override and as the first Provider, it removes the entry to Agent 1 found as a Provider. The Application does not list or use the same agent multiple times in this situation. Lookup/Failover List: Scenario 2Assume that you have four agents installed in your GroupWise system, all being serviced by one application:
Using the preceding table, the following table shows the list that the application builds regarding which agent this user should be sent/failed over to:
In this scenario, the user does not experience any interruption of service unless all four agents go down. If Agent 2 fails, the application automatically rolls the user over to Agent 1 and so on. With this information, you should carefully plan how you define the agents that the users are directed to. With the understanding you now have, you should be able to design a very reliable WebAccess system. There's one more little piece that is important. How does the application know whether there is a default WebAccess Agent defined at the domain or post office level? This information is not stored on the Web server, and the application was never designed to directly access a GroupWise domain database to discover this information. Here is what happens. To build the list of agents when a user logs in, the application must determine whether there is a default WebAccess gateway defined at the domain or post office level for the user. When the user ID and password are entered at the login page for WebAccess, the application sends this information to any one of the agents listed as Providers in the WEBACC.CFG file. The WebAccess Application uses these agents in a round-robin fashion for its initial query. Its initial query to the agent is to look in the domain database for a default WebAccess Agent defined at either the post office or the domain level. The agent answers the query with the results to the application. Now that the application knows whether the user has a default WebAccess Agent defined, it can build the correct list of agents to route the user to. Now that we have explained the lookup and failover model, the following section explains how to configure this type of setup. Matching Encryption KeysFor a single WebAccess Application to be able to talk to multiple agents, the encryption key between the application and all agents it communicates with must be the same. The WebAccess Application will read the COMMGR.CFG file located by default in the WEBACCESS directory on the Web server. The COMMGR.CFG file contains the encryption key that must match the encryption key stored in the COMMGR.CFG file located in the DOMAIN\WPGATE\WEBACCESS directory for each of the WebAccess Agents. The easiest way to facilitate seamless communication from the application to each agent is to make the encryption key the same for all agents that a single WebAccess Application will be configured to talk to. (A simple copy-and-paste procedure works great.) You do this by editing the WebAccess Agent that is directly associated with a particular GroupWise domain and accessing the WebAccess settings. Figure 31.1 shows this screen. Figure 31.1. Editing the WebAccess encryption keyFrom here, you should enter the same encryption key on all agents. The best method to use is to take the existing encryption key from your first WebAccess Agent and copy it to the new WebAccess Agent objects in ConsoleOne. Configuring the Default WebAccess Agents for a Domain or Post OfficeTo configure a default WebAccess Agent at the domain or post office level, you need to access the properties of the respective domain or post office object. From the respective property pages, choose the GroupWise, Default WebAccess properties page. From here, you click the override box to browse through the eDirectory tree and select the appropriate WebAccess Agent object. Configuring the WebAccess Application's Provider Agent Failover ListTo get the WebAccess Application to recognize the WebAccess Agents it should use for failover, you need to add these Agents as Providers in the WEBACC.CFG file. If you intend to have several WebAccess Agents, it's not necessary to have all of them listed in WEBACC.CFG. We recommend for most customers to have three. The fact that a WebAccess Agent is not listed as a Provider does not mean it will never be used, it just means it will never be used for failover. As you remember from the earlier explanation, a WebAccess Agent is used if it is assigned as the default WebAccess Agent for a domain or post office. So now you need to access the WEBACC.CFG file. On a NetWare server, the file is generally in SYS:SYSTEM\NOVELL\WEBACCESS. On our SLES9 server the webacc.cfg file is located in /opt/novell/groupwise/webaccess.
The syntax is important, so make sure that you make the syntax just as shown. After the changes are made to the WEBACC.CFG file, you must restart the WebAccess Application for the changes to take effect. On the NetWare 6.5 platform the commands to do this are as shown here: java killall java exit tomcat4 On our SLES9 server these are the commands: /var/opt/novell/tomcat4/bin/catalina.sh stop /var/opt/novell/tomcat4/bin/catalina.sh start Now with the Providers defined, the WebAccess Application will go down the list of Providers if a default WebAccess Agent either is not available or is not defined. |