How Dave Does It: Increasing GroupWise ROI
Novell Cool Solutions: Trench
By Dave Muldoon
Digg This -
Posted: 1 Apr 2004
In this economy, IT staffers are often being asked to cut expenses and provide system improvements without spending money. If this is a situation that you find yourself in, you may want to consider bending some of Novell's age-old rules for managing GroupWise. To understand this article and the "radical new approach to GroupWise design" (which I know some of you have been doing for years), you need to know that this entire philosophy is based on a few things:
- You need to fully understand your GroupWise system thoroughly through trending and experience (Taking a pulse on your GroupWise system).
- You should have a solid understanding of how GroupWise operates and communicates and works within your environment.
- You should understand Novell's principles behind optimally configuring and designing GroupWise systems.
This last point is the rule that you may want to consider bending. I say "bending" because Novell has always stated that the optimal way to run a GroupWise system is with a dedicated server for each agent. This can become very expensive if not kept in check. And then there are always those questions where "arbitrary answers" are always provided:
Q: How many users can I put on a Post Office?
A: Well, that depends on how often those users access GroupWise, how they access GroupWise - web client, remote or cache mode, whether they receive a lot of email, whether they send a lot of email and so on and so forth.
Q: How many users per Domain should I have?
A: Well, again that depends on things like how much mail those users send and receive, where those users are geographically located (if you haven't consolidated your system), what other purposes your domain might serve (i.e. gateways) and so on and so forth.
By now you're probably thinking "get to the point! How do I increase my ROI?" Well here it is in a nutshell. If you know exactly how your GroupWise servers and agents are running and you understand how they communicate over IP (ports, etc), you should be able to identify whether or not two agents can be combined onto the same server without negative impact. As I mentioned before it's not unheard of in the user community for GroupWise administrators to have a design such as this. For others, it may seem that breaking away from Novell recommendations or consolidating systems in this manner is too confusing. Let's review this type of design in more detail:
Why would I ever want two GroupWise Agents on the same server?
In the past I have written about GroupWise Consolidation, those articles referred to the consolidation of GroupWise users onto larger Post Offices and/or moving entire Post offices to centralized data centers. What I'm now talking about is "server consolidation" in conjunction with GroupWise agents. This is because over time systems often become "bloated" with old servers (often underpowered) mixed in with newer, faster, bigger servers that many times are underutilized. In an environment such as this, or even in an environment where systems are all similar (new or older) you still may be able to identify ways to eliminate bloat - thus reducing expenses through things like:
- Less server patching
- Less upgrading
- Less vendor support problems for aging hardware (assuming you have newer hardware).
Freeing up resources
- Network hardware
- Network bandwidth/traffic
- Physical space
- Air conditioning
These types of reductions are where you can trim down the overall cost of GroupWise within your environment and potentially see some huge gains. If you're really lucky and all of your servers are newer you may even be able to re-deploy those servers that GroupWise was re from for other purposes - resulting in tangible savings.
Backup and Restore Times
Assuming that you can configure your backups as separate jobs per agent (and that each agent is on it's own volume), you will actually see shorter backup and restore windows as compared to further consolidating all users onto the same Post Office.
Access Mode Challenges
With the advancement of GroupWise, Novell now recommends running the GroupWise client in Cache-mode to increase a company's return on investment (ROI) - by then consolidating the users onto larger Post Offices. In theory this makes a lot of sense, but often organizations struggle with implementing this type of solution as the initial deployment can have very significant side effects to a dispersed corporate network, as well as, to end-users.
In many cases, based on Novell recommendations, this type of consolidation is not considered and yet if undertaken can save a considerable amount of time and dollars over time for a company. Up to this point all that I've mentioned above are factors that can be used to determine if server consolidation is right for the GroupWise system that you manage, now let's touch on the details of how to do it.
GroupWise: How do I do it?
As you're probably aware GroupWise runs (in most configurations) over TCP/IP and connects to a specified port depending on what agent and access method is being utilized. The main objective when planning to consolidate two or more agents to a single server is to make sure each agent has a unique port configuration. In short, you can't have two POAs on a single server both utilizing port 1677. The same things goes for Domains. These ports have to be unique for each agent and all ports for all agents running on a server. For example:
|IP Address: 10.0.10.2||IP Address: 10.0.10.2|
|Client server port: 1677||Client server port: 1678|
|HTTP Port: 7180||HTTP Port: 7181|
|Message Transfer Port: 7100||Message Transfer Port: 7150|
NOTE: If any of the ports are already used, both agents will not successfully load on the server.
One other very important item for a multi-post office configuration has to do with maintenance start times for each Post Office. This is something that was pointed out to me, when discussing this with the very knowledgeable Eric Raff. You can make things a little smoother for your server if you try to stagger the scheduled events that run per server, instead of the traditional means of thinking (per Post Office). For example, you may want to run nightly database checks on both POs but starting them both at 10:00PM could cause your server to be pushed too hard. Instead the start times should be configured so that at no one time would both POAs be processing this type of event. Instead, you may want to consider is creating two scheduled events such as; Nightly Database - 10PM and Nightly Database - 2AM. Then have one Post Office execute the 10PM process and the other execute the 2AM process, avoiding the conflict for server resources - nice tip huh? I thought so too.
In order to successfully move a Post Office from one server to another server, there is a relatively simple step-by-step process that you can follow. Some of these steps are done in preparation to the move and others are completed after the Post Office data has been moved to the new location. I have detailed these steps in a previous article found here: GroupWise Consolidation - Moving GroupWise over the WAN
Something that you should also keep in mind when making port and IP address changes, the GroupWise gateways sometimes do not successfully update. You should always manually check your Web Access gateway(s) and your GroupWise Internet Agents to make sure that the IP address, port information and access types are correct.
Servers: How do I do it?
One of the most significant factors here is the advancement in server technologies. Servers today, as I mentioned earlier, are smaller in size but much faster and more reliable than even just a few years ago. If you have recently acquired newer equipment, there is a good possibility that it's not being fully utilized by a single GroupWise agent. Another factor to newer hardware is the "upgradability". As long as your server model is current, upgrade components may be readily available through normal channels - resulting in lower costs and better vendor support.
In conjunction with advancement in hardware technology, newer technologies from Novell such as clustering provide additional benefits when consolidating servers. The use of protected memory is also something that should be considered when using multiple agents on the same server. This can help segregate the agents during agent-based problems that would normally crash a server. There are various restart options available through protected memory and each one fits a different purpose. Investigating these options thoroughly based on your needs is worthwhile.
Okay, I guess this article was short and to the point. As usual, I hope that this article has provided some useful information. Of course, before you try to undertake such a project, you should do the upfront analysis to understand your system and how a change in this direction can potentially impact end users. To provide you some perspective, I have analyzed a full year's worth of historical data for multiple Post Offices to determine specifically which Post Offices can be consolidated to the same server. That may seem a little overcautious but, one of our main objectives as administrators is to avoid end user impact.
More How Dave Does It articles
Watch for more articles by Dave Muldoon, under the resources link on GroupWise Cool Solutions - http://www.novell.com/coolsolutions/gwmag/features/trenches/tr_how_dave_does_it_gw.html.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com