Cool Blog: Alternate GWIA's
Novell Cool Solutions: Feature
By Alex Evans
Digg This -
Posted: 31 Jul 2007
I sat down tonight determined to figure out just how useful the Alternate GWIA option was in Internet addressing. I will admit that I spent quite some time lying on the floor, staring at the ceiling, trying to get my head around it - but I think I have it figured out. I have to say, it's a lot more useful then I first thought!
The key to making the most of it is ensuring that the first attempt to send a mail out of a GWIA will fail - this gets the MTA into "failover" mode. Getting this done is relatively simple, though it will increase the load on one of your MTA's quite significantly. In the domain that you want to handle this extra load, which can be a purpose created domain, create a dummy GWIA object.
1. Browse to that [domain]\wpgate dir and create a new, empty directory - for example, "gwia".
2. In ConsoleOne, right-click the domain object in the GroupWise view and select New > Gateway.3. Fill in the resulting dialog like in the picture below (click to see a bigger version) making special note of the radio button at the top.
4. On the GWIA Properties > Network Address, enter the server's IP address and a unique port on the Message Transfer port.
5. On the Internet Addressing tab on the domain, enter the Alternate GWIA that you actually do want to handle all the outbound mail.
You do not want to install any GWIA software or start this dummy GWIA. Now in GroupWise System Operations > Internet Addressing you want to specify this dummy GWIA as the default outbound GWIA for the entire system. What this just achieved is it gets all outbound Internet mail in the system to be routed to this domain for this dummy GWIA. The MTA will not be able to communicate to the GWIA on the port you specified, so it enters into (for want of a better term) "failover" mode.
Obviously, we need to get the rest of the system ready to handle the alternate GWIA setup. Here's how - on any domain that contains a functioning GWIA:
1. Set up the MTA > GWIA communications to use TCP/IP. This is simply achieved by entering the server's IP address and unique port on the GWIA Network Address tab, like we did above. Make sure of the following things:
- You pressed F6 on both the MTA and GWIA to get them to restart afterwards.
- The MTA shows the GWIA as open.
- F10 > Configuration on the MTA shows the GWIA on an IP address and not a UNC path.
2. On the Internet Addressing tab of the GWIA's domain, override the default outbound GWIA and select its own GWIA.
3. Also enter an alternate GWIA.
With planning, you can chain the failover. Let me explain how it works with an example - imagine we have 4 domains; DOM1, DOM2, DOM3 and DOM4. In DOM1 I create my dummy GWIA; DOM2 and DOM3 have real GWIAs and DOM4 has my post offices in it.
- On DOM1 I specify DOM2.GWIA as my alternate.
- On DOM2 I specify DOM2.GWIA as my default and DOM3.GWIA as my alternate.
- On DOM3 I specify DOM3.GWIA as my default and DOM2.GWIA as my alternate.
I am going to coin the term "chained group" here, to signify an initial dummy GWIA and a series of alternates.
Now, a user in DOM4 sends a mail to the Internet - as the system default outbound GWIA is DOM1.GWIA, the mail gets routed to DOM1. The MTA there will not be able to contact its (dummy) GWIA, so it checks what its alternate is. It sees that it's DOM2.GWIA, so it attempts to contact the Message Transfer Port of that GWIA directly (note that it's not going back across the domain links). If that works, then DOM2.GWIA will deliver the mail. Here's the smart part - if DOM2.GWIA is down, then the MTA at DOM1 will look up what DOM2's alternate GWIA is and attempt to contact that one instead - again, directly instead of across the domain links. You can chain as many as you want in this way.
Now, I do recognize that some of you have multiple outbound GWIA's - either based on load or geographic location. You can still do this, but you need to override a few more things. What you would need to change is the current default outbound GWIA to instead pointing to a local dummy GWIA. Then you specify a real alternate GWIA on that hub domain. You can essentially create a whole series of chained groups to handle geographies or whatever.
And now the why's ...
Why create the dummy GWIA in the first place?
Here's why. In most cases your GWIAs are installed on the same server as the domain, thus also the MTA - so if a GWIA goes down, usually the MTA is down, too. If this is your default outbound GWIA, then the mails never get to the MTA. So, the whole MTA "failover" mode never kicks in, and we don't hit the chained group. By having the dummy GWIA we are getting the mails to an MTA that is pretty much always going to be up (MTA's rarely abend). Also, the rest of the mail flow from that point doesn't really care if any of the other MTAs are up.
If you read between the lines above, you will have spotted that I am recommending that you don't put the domain with the dummy GWIA on the same server as a real GWIA - otherwise you have achieved nothing.
Why doesn't this do load balancing?
Load balancing is not the point of this - it's high availability. To load-balance you would specify different default outbound GWIAs on the different domains or POs to invoke different chained groups - load-balanced AND highly available. Granted, this is not true load balancing but hey, it's close.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com