Scaling GroupWise with a New Installation



A Forum reader recently asked:

"My boss has decided to license GroupWise for us for the first time, and I don't have a clear idea of how it scales now. What kind of server specs should I be looking at, and how many users could I expect to be able to run on one server? I expect to run all services off a single server, at least in the beginning. Eventually, we're looking at running 1500-2000 users on our Groupwise system, but we'll probably start off with around 250 or so and expand out from there."

And here's the response from Michael Bell ...


A typical box handles up to about 500 users of "normal usage" in standard Online mode in a PO.

If you enforce Caching mode - which means the mailbox will be cached to their local hard drive, and they'll only sync when they start up, delete stuff, or send/receive stuff - scaling to 2000 or more users should be possible. There's also the advantage that if GroupWise goes down, they barely notice - they continue working normally, and when it goes back up, they sync in the background. The negative of caching mode: it takes a long time to prime the mailbox on a fresh machine if the mailbox is large.

Having said that, I tend to recommend a 2-box setup minimum, The first has your POA and primary MTA. The second (which can be less powerful) has your GWIA/WebAccess gateways as children under a secondary domain/MTA linked to the primary via IP.

Here are the reasons for this specific set up:

1. Gateways are inherently much more likely (though still not likely, per se, I emphasize) to crash. Because they are exposed to the outside world, they get "weird foreign stuff," and that makes them more edgy, if you follow. Plus, it's a better security design to have these isolated. (They only need an MTA-MTA IP link, no other access).

2. The domain database is holy. You can corrupt a PO database and easily recover from it. You cannot recover from a domain database corruption, except to restore a backup (it's a good idea to back things up of course) OR from a secondary domain. So a secondary domain provides extra tolerance for a cheap cost (an extra MTA is minimal overhead).

3. Gateways should always be installed local to their parent domain. Novell docs don't necessarily say that. They are wrong, in my opinion.

To answer a question you haven't asked: The bottleneck for GW is usually NOT RAM or CPU (assuming reasonable modern server specs). It's DISK CHANNEL SPEED and DISK DRIVE SPEED. Good high RPM drives are worth it, as are professional server quality drive controller cards (SATA or high speed SCSI). SCSI is still preferable, AFAIK.

Another question you haven't asked - NOS Speed, from highest to lowest:

  • Linux

  • NetWare

  • Windows

(This is obviously affected by RAM, CPU, and tuning.)

And another question you haven't asked: Multiple POs on the same server do work, but they don't tend to load balance very well against each other, because each is not aware of the resources the others are using.

You can copy gateways off the main (only) box onto a second box, and you can make it the secondary domain for backup safety. Here's what you do:

1. Install a new domain/MTA on the second box and link via IP.

2. When this shows up "happy" on the MTA console of box 1, proceed.

3. Install a new GWIA and a new WebAccess under the secondary domain.

4. Test them.

5. Delete the old GWIA and WebAccess objects.


How To-Best Practice
Comment List