Configuring GroupWise WebAccess for More Scalability and Stability


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 System

With 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:

  1. If there is an agent specified in the URL field that is entered when a request reaches the Web server where the WebAccess Application is running, the Application performs no lookups and sends the user request directly to the agent that was defined in the URL. An example of how to construct the URL to do this follows:

    http://groupwise.wwwidgets.com/gw/webacc?GWAP.ip=137.65.55.211&GWAP.port=7205

    The IP address specified after GWAP.ip= would reflect the IP address of the server where the WebAccess Agent is running, and GWAP.port= is the port the WebAccess Agent is listening on.

  2. Generally the URL to access GroupWise WebAccess does not specify a certain WebAccess Agent. So if no agent is defined in the URL, the application performs a lookup to determine whether a default WebAccess Agent is defined at this user's post office. If so, the user is routed to this agent.

  3. If no default WebAccess Agent is defined at the user's post office, a lookup is performed on the user's domain for a defined default WebAccess object. If one is found here, the user is routed to this agent.

  4. If no default WebAccess Agent is defined at the domain, the application looks in the WEBACC.CFG file for the service provider that it is associated with and routes the user to the first agent defined as a Provider. Here is an example from the WEBACC.CFG file showing the first Provider:

    Provider.GWAP.Default.address.1=137.65.55.211:7205

  5. If no Provider agents are defined, the application reads the COMMGR.CFG file located in the WEBACCESS directory and routes the request to the one agent defined in this file. The method that the WebAccess Application uses to determine which agent to send the user is also a method that the application uses for failover if any agents are down. For example, if there is a default WebAccess Agent defined at the domain level, but it is unavailable, the application then rolls over to the next lookup method, which is the agents defined in WEBACC.CFG, and sends the request to the first agent there. In our case this is Provider.GWAP.Default.address.1=137.65.55.211:7205

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 1

Presume that you have three agents installed in your GroupWise system, all being serviced by one WebAccess Application:

DEFINITION

WEBACCESS AGENT

Entered URL

No agent defined in URL groupwise.wwwidgets.com.

Post office

Agent 1 defined as the default agent for this post office.

Domain

No agent defined.

Agents defined as Providers in the WEBACC.CFG file

Agents 1 and 2. The COMMGR.CFG file has a reference to Agent 3.


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:

APPLICATION LIST VALUE

GENERATED FROM

Agent 1

Post office definition

Agent 2

Service provider list

Agent 3

COMMGR.CFG file


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 2

Assume that you have four agents installed in your GroupWise system, all being serviced by one application:

DEFINITION

WEBACCESS AGENT

Entered URL

No agent defined in URL webmail.worldwidewidgets.com.

Post office

No default agent defined for the post office.

Domain

Agent 2 is defined as the default agent for this domain.

Agents defined as Providers in the WEBACC.CFG file

Agents 1 and 3. The COMMGR.CFG file has a reference to Agent 4.


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:

APPLICATION LIST VALUE

GENERATED FROM

Agent 2

Domain agent definition

Agent 1

Service provider list

Agent 3

Service provider list

Agent 4

COMMGR.CFG file


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 Keys

For 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 key


From 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 Office

To 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 List

To 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.

[View full width]

Search the file for Provider.GWAP.Default.address. If there is not a section already, just add the providers to the end of the WEBACC.CFG file, in the following manner: Provider .GWAP.Default.address.1=137.65.55.211:7205 Provider.GWAP.Default.address.2=137.65.55.212:7205 Provider.GWAP.Default.address.3=137.65.55.213:7205

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.



NOVELL GroupWise 7 Administrator Solutions Guide
Novell GroupWise 7 Administrator Solutions Guide
ISBN: 0672327880
EAN: 2147483647
Year: 2003
Pages: 320
Authors: Tay Kratzer

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net