GroupWise 8 Design Architecture

From CoolSolutionsWiki

GroupWise 8 Best Practices

GroupWise 8 Design

GroupWise 8 Design Architecture

Contents


Introduction


Like the Client brief to a building Architect, this is the basic layout and design element we need before we apply the configuration requirements of the System and Services. This guide serves as a set of considerations and guidelines for Novell GroupWise administrators. It is not a comprehensive instruction set, and it is not intended to replace product manuals. However, it is supposed to provide assistance in making decisions in deployment that need to be taken. Administrators using this guide should consult product documentation, technical information documents (TIDs), and online help for further instruction regarding each of the guidelines offered here.


Administrators and GroupWise Architects should also seriously consider sitting the GroupWise 8 ATT


This guide is based on the GroupWise 8 Documentation and BrainShare presentations. and is intended to carry out the promise of being the living document mentioned during the introduction. Being part of the Novell wiki, you can play a part in modifying this content with your experiences.


We recognise that administrators are often restricted in the changes they may make to their GroupWise Systems. Depending on the state of the existing Novell GroupWise system, some of the practices outlined in this document may be difficult or cost-ineffective to implement. However it may well prove to be worth while in the longer term. Use these guidelines wherever possible in expanding systems or creating new systems, but temper their application with your experience and knowledge of your organisation's unique computing environment.


You may also refer to the many Novell partners or the GroupWise 8 Active Partners page for more information, tools, and services.



The Basics

Assumptions


In order to keep this guide up to date, we need to assume that you're running the latest version of GroupWise - which is currently version 8.0.1 HP1. If you are running older versions of GroupWise, many of the principles will be the same, but the details may be different.

System Requirements


The base system requirements are provided in the [GroupWise 8 documentation].


Additional Requirement Considerations:


Post Office Agent

The amount of memory required for the POA is influenced by many factors, including the following:

Number of client/server connections being supported
Number of active client connections Vs. idle connections
Number of TCP handler threads
Number of message handler threads
Number of database maintenance threads

However the memory usage is by today's standard very small, the same applies to the CPU usage - GroupWise is very efficient from that perspective too. Where a GroupWise Post Office places its greatest demand is upon the Disk IO.


Message Transfer Agent

The amount of memory required for the MTA is influenced by many factors, including the following:

Number of post offices and domains
Volume of message traffic between post offices and domains
Volume of large messages (for example, large attachments, remote updates, and so on)
TCP/IP or mapped/UNC links between MTAs

As with the Post Office the memory usage is by today's standard very small. The same level of requirements applies to the CPU usage - GroupWise is very efficient from that perspective too. A Domain has no real pain points (IO is not the same issue as it is on a Post Office) however ensure that there are good LAN connections.


Internet Agent

Always place a secondary Domain on the same server as the GroupWise Internet Agent (GWIA)

When GroupWise 5.5 was released - back when the world was innocent and the GroupWise Internet Agent (GWIA) provided an LDAP interface so that third parties could look up your email address - there was a recommendation that you could separate the GWIA from its parent Domain. DO NOT DO THIS

Back then the GWIA consisted of 2 parts, the Agent and the SMTP engine. The SMTP engine accepted all inbound traffic and then the Agent did the verification of the recipient before conversion to GroupWise format and transmitting the message to the MTA. The upside of this was that undeliverable messages could be routed to the postmaster or to an alternative SMTP engine. The downside of this comes with unsolicited bulk email, more commonly known as spam. (Not to be confused with Spam)
Today, while the GWIA is still a two part system (Agent and SMTP engine) it is now the SMTP engine that does the user authentication. This requires that the SMTP engine has fast access to to the WPDOMAIN.DB to verify that the recipient exists (or transmit a 550 No such recipient) and hence the banning of the separation of the GWIA from its parent Domain.

Good reliable LAN connections are also important for a GWIA.

It is good practice for the GWIA to be placed in the DMZ, thus only port 7100 - 7100 would be required to route messages between MTAs (Domains) and only if POP3 or IMAP connections are supported by the GWIA would 1677 be required.

It's a good idea to put ACLs in place for Internet Agents whenever possible. If the agent(s) utilizes a relay host it would be reasonable to ensure that it only accepts and receives mail from those relay hosts. Similarly, if it the agent is not to serve as an open relay by design always disallow this behavior.

Do not place a GWIA on a Post Office Server - the GWIA interfaces with the outside world and can require restarting for many reasons. While the Post Offices are stable and may run for years without re-starting this is unlikely to be the case with the GWIA, and this co-hosting them on the same server can cause service interruptions.


WebAccess

As with the GWIA, it used to be suggested that the GroupWise WebAccess Agent could be separated from its parent Domain. DO NOT DO THIS

It is more than possible to separate the WebAccess Agent (the GWINTER) from the WebAccess Application (Tomcat/Apache) and this can be a good thing; the WebAccess Agent placed inside the LAN and the WebAccess Application in the DMZ talking back on port 7205.

The cross linking of WebAccess Applications and Agents described in the documentation is a good thing, providing high availability without using Clustering. Indeed as a rule of thumb clustering WebAccess is not considered an optimal configuration.


OS Platform Considerations


GroupWise is currently supported on NetWare (6.5), Windows (2003,2008) , SLES (10, 11) and OES2(Linux)

The relative performance of GroupWise on the different platforms can be ranked:
1: SLES / OES2 x86_64 (64 bit)
2: SLES / OES2 i586   (32 bit)
3: NetWare
4: Windows
The slowness of the Windows platform can mostly be attributed to the performance of the NFTS files system and its interaction with the GroupWise database structure.
If you're using NetWare, consider using this tuning NCF for your dedicated GroupWise servers.


Based on the performance ranking above, the recommended platform is therefore the 64 bit versions SLES/OES2


NOTE: In his blog entry of 11th April 2010, Dean Lythgoe made some statements about platform support for "Ascot" (the next release of GroupWise)

Ascot will be 64-bit ONLY. We are talking about servers/agents. The Windows Client will still be 32-bit.
Ascot will NOT support NetWare. NetWare entered extended support in March 2010. NetWare does not support 64-bit.


Virtualization Considerations

GroupWise components are fully supported in a virtualized environment. These environments include VMware and XEN, but not KVM or Hyper-V (according to the latest GroupWise 8 documentationNovell Documentation). When planning to virtualize any GroupWise components, consider the following :-

When determining which components to virtualize first, consider a "back to front" approach in terms of which agents require the most resources to run. From that perspective, the WebAccess agent and application are obvious candidates to virtualize first, followed by MTAs, GWIAs and POAs last. As you can see by this list, you should virtualize the agent with the lowest disk I/O requirements first.

Another good practice is to create separate virtual disks (VMDKs etc.) for mail volumes, especially domains and post offices. Customers whose GroupWise guest VMs crash and burn spectacularly have more success in recovering their post office or domain when the actual GroupWise data itself resides away from the core OS, as the VMDK can be attached to a new guest and the mean time to recovery is often much lower than with conventional DR techniques.


VMDK or RDM?

Another often asked question is "Should I use VMDKs for GroupWise, or use Raw Device Mappings? (RDM)". In terms of performance, VMware have published some white papers on the metrics seen when the two technologies were compared side by side in the lab VMware.com VMFS vs RDMs. Although this white paper is somewhat dated (2007 and uses ESX 3.01), it's reasonable to assume that since then, VMDK performance has been improved through versions 3.5 and 4.0. In conclusion, disk performance should be roughly equivalent when choosing VMDK or RDM, with a slight gain using VMDKs.


VMware Tools

It's amazing how many VMware customers do not realise what VMware Tools actually do. In many cases, it is assumed that the tools provide improved graphics and mouse performance, but this is only part of the story. The VMware Tools installation provides improved network drivers, it installs the memory balloon driver for VMware (vmmemctl), which forces the guest to use its assigned memory in a more aggressive way, especially when there is physical memory contention on the ESX host with other guests. The Tools also provides the guest heartbeat functionality, so that vSphere may accurately track when a guest is down for HA/vMotion purposes. In short, it's fundamental and it should always be installed and kept up to date each time ESX is upgraded.


This area is discussed further with conclusions on what do and do not virtualize here.

System Design

Domain Sizing and Configuration


There is no limitation to the number of Domains contained in a System. However, Novell Technical Services recommends as few as possible to limit the amount of admin traffic on the network. Synchronization traffic increases as the number of domains increases.


The exact number of domains in any GroupWise System needs to be determined on an individual basis by considering the following:


Carefully consider the number of post offices per domain, keeping these three objectives in mind:

  • Minimize the number of rebuilds that you may need to perform from a single domain
  • Avoid single points of failure
  • Minimize the MTA workload


You should assign no more than 20 full-size post offices per domain. Assuming that a well-configured MTA can sustain throughput of 100,000 messages per day and each user sends and receives 10 messages per day, then twenty 500 mailbox post offices will generate 100,000 messages.


  • The primary domain should not own any post offices, gateways, or users.
  • The MTA should be loaded on the same server as the domain it services.
  • The primary domain should have a direct TCP/IP link to all secondary domains where possible. This ensures that administration traffic is isolated from message delivery routes. It also ensures that administration changes are replicated as quickly as possible throughout the system.
  • The primary domain should not be used as a routing domain.
  • Messaging hub domains (a centralized domain for routing messages) should be used at WAN to LAN connection points and service the remote domains that come through these points.
  • If a messaging hub domain is used, it should have a dedicated server.
  • A messaging hub domain can service 60+ links depending on LAN/WAN traffic, speed and protocol (TCP/IP) used.
  • Secondary domains should be created based on topology with a goal to minimize network traffic.
  • All gateways should be assigned to a dedicated gateway secondary domain.
  • All high-traffic gateways should be assigned to a dedicated gateway secondary domain and placed on a dedicated server.
  • Additional domains for Internet traffic (primarily GWIA and Web Access) can be placed at WAN/LAN hub locations to reduce the time/cost for message delivery and network bandwidth.


Other considerations would include the use of dial-up routing where link scheduling could reduce costs and external synchronization with other GroupWise systems where there is a high volume of administrative traffic. This guideline assumes that all post offices are TCP-IP linked to the domain with message transfer ports and IP addresses. If UNC links are used, then a domain should support no more than six full-sized (500-mailbox online connected, 2500 caching mode connected) post offices.


Novell recommends clustering domains. The fault tolerance provided by clustering domains will provide maximum uptime for message routing between the domains in the Novell GroupWise system.


Links between Agents


LAN Domains

Link all LAN domains via IP in a mesh configuration. On a switched LAN, mesh-style linking provides the most efficient transfer of data. Indirect, hub-style linking can seriously burden the hub domain and presents a single-point-of failure as well.


Message Transfer Ports

Link all post offices to their domains with message transfer ports and IP addresses. IP connectivity between domains and post offices prevents the MTA from polling each post office directory in turn. This polling can severely impact performance and poses serious problems if there are post offices over WAN connections.


Routing Domains

Establish hub domains at WAN links. While mesh-style connectivity should be the rule on the LAN, it poses serious problems for domains across WAN connections. TCP connections may time out, and throughput may be erratic. Establishing a domain for routing at each WAN connection prevents these problems by bringing the store-and-forward aspect of communication up to the application level where time-outs are not an issue.


Note: Novell GroupWise agent communication (MTA to MTA and POA to MTA) has been enhanced to reduce the negative effect of slow or unreliable WAN links on messaging traffic.


Post Office Sizing and Configuration


With any messaging system, there are general characteristics of the overall network environment, such as backup and restore times, that come into play when sizing the information store. A primary consideration when sizing a GroupWise post office is the messaging habits of the user base (i.e. messaging utilization and client access mode). The correct sizing of GroupWise post offices also depends on several other factors, such as the overall GroupWise mailbox size, message database size, and size and number of attachments in the information store.


Note: The sizing recommendations in this guide are general guidelines based on many years of experience with many different environments. These are not exact recommendations for sizing GroupWise post offices in a particular environment due to the constant progress of server hardware and storage.

  • There are several general factors that affect the performance of a messaging system. Storage system design, Backup, restore, maintenance, OS and perceived performance of the messaging client are useful scaling factors. Addressing these factors is important to different components of a network.
  • The design of the storage system alone can make or break a GroupWise system. Never deploy a Post Office against a SATA hard drive as the performance hit can be insurmountable. RAID 5 implementations suffer from poor performance when faced with a workload which includes many writes which are smaller than the capacity of a single stripe. This is because parity must be updated on each write, requiring read-modify-write sequences for both the data block and the parity block. More complex implementations may include a non-volatile write back cache to reduce the performance impact of incremental parity updates.
  • Never use less than 5 disks in a RAID 5 to ensure an adequate IO level on read and write operations
  • When using a disk stripe to increase IO performance, always use RAID 1+0 (Also known as RAID 10) rather than RAID 0+1. RAID 0+1 is a mirror of stripes, RAID 10 is a stripe of mirrors and is thus inherently more resilient. According to [manufacturer specifications] and official [independent benchmarks], in most cases RAID 10 provides better performance than all other RAID levels except RAID 0
  • Where a RAID of any type is deployed, ensure that the RAID card has battery backup and will not cause a bottleneck - modern servers with inbuilt RAID systems do not come with high performance RAID cards.
Factors on System Performance
Factors Possible issues
Backup Backup engine, target service agents, CPU and IO throughput.
Restore Restore engine, target service agents, CPU and IO throughput.
Maintenance Database maintenance application: mode, location (client vs. server), and CPU and IO throughput.
Software Distribution Directories Capacity: 1.4 GB for all GroupWise components
User Performance Messaging client access mode to post office, server utilization, network traffic, and client workstation speed.


  • Once these factors have been taken into consideration, you can start to generalize the sizing of the number of mailboxes in a GroupWise post office. The following table shows approximate numbers of mailboxes in a single post office; based on messaging utilization, access mode, and sizing information.


Messaging Utilisation Mailbox Access Mode
Online Caching WebAccess/Wireless, IMAP4/POP3
Heavy 700 - 1,500 1,500 - 3,000 Do Not Deploy
Medium 1,000 - 2,000 4,000 - 5,000 Do not deploy
Light 1,500 - 3,000 10,000+ 5,000+


Messaging Utilization


Heavy: Heavy mail users are those who use nearly all of the features of Novell GroupWise 8 and rely on messaging for a large percentage of their day-to-day productivity. Numbers of messages sent and received are also high for heavy users. Typically, heavy users send 25 messages and receive 100 messages per day and have total mailbox sizes in excess of 300 MB.
Medium: Medium mail users rely on Novell GroupWise for communication via e-mail messages and managing their time with calendar events but do not use all of the features of GroupWise such as Proxy or Discussions. Typically, medium users send 10 messages and receive about 25 messages per day and have total mailbox sizes of up to 200 MB.
Light: Light users send and receive few e-mail messages each day, with limited use of attachments and almost no calendaring activity. These users will send an average of 25 messages per week and will have an average mailbox size of less than 50 MB.
  • Mailbox Access Modes
Online
Since the online mode still relies on the POA to deliver 100% of the content to the GroupWise client, the guidelines for previous versions of GroupWise apply. Experience shows that while some organizations have successfully implemented 1,000 mailbox or larger post offices, performance is consistently better for smaller numbers of mailboxes.
Post offices with heavy message flow, or where users are using Novell GroupWise for full collaboration (calendars, task lists, shared folders, document management, etc.), demand more resources than post offices where GroupWise is only used for e-mail.
Often, a very large post office will have excellent performance for an extended period before performance mysteriously begins to degrade. This is typically a function of increased user employment of the Novell GroupWise product. Adhering to the online-mode mailbox guideline of keeping mailboxes within the range of 700 to 1,000 should ensure that your users have the room to grow into the full collaboration GroupWise offers.
Novell recommends that the number of active online-mode users per post office does not exceed the range of 700 to 1,000. With the assumption that on average only 60% to 70% of users will be logged in and using mail at any given time, GroupWise could easily support a post office of 1,000+ total users.
Here are some things to consider when deciding on an acceptable number:
Consideration Description
LAN/WAN Speed and Topology The slower the network, and the more hops a packet has to make, the lower the performance will be.
Clean-Up Policies Without standard clean-up policies implemented, there is no way to control the size of the GroupWise databases or the users' mailboxes. As the databases get larger, maintenance routines and client display will take longer. In addition, as the number of messages the POA must query for Finds and/or indexing increases, the POA slows down.
Number and Size of Attachments The average user is expected to have a certain number and size of attachments. In Novell Technical Services, the post office has less than 300 users due to the size of attachments each user has; these include large databases and core dumps mailed from customers. Novell Technical Services needed to reduce the number of users on a post office to provide adequate disk space.
Backup and Restore Backup and restore can be an issue as the number users and messages increase. This issue requires that situation- specific decisions be made. Solutions will include limiting the number of users per post office, adding more disk space, implementing an e-mail policy, restricting the size of attachments, limiting the number of messages, or billing the user when limits are exceeded.
Caching / Remote
Since the Caching and Remote modes rely on the Novell GroupWise client acting upon a local disk store, the load on the POA is greatly reduced, while the performance of the client is greatly increased.
While keeping in mind the other factors involved in correctly sizing GroupWise post offices (such as GWCheck times, Backup, Restore, etc.), typical post offices that were previously sized to 500 to 700 mailboxes can now be potentially increased by a factor of about three (3) to five (5) using Caching mode. This would equate to a potential post office size with continued client performance of 1,500 to 5,000 mailboxes.
WebAccess / Wireless
Based on the assumption that a percentage of total users will access the system concurrently with these clients, a GroupWise post office with the majority (if not all) of the mailboxes being accessed with these clients can be larger (in terms of number of mailboxes) than one with the majority of online client access mailboxes.
A deskless client user will have messaging habits and practices similar to those of a light e-mail user as defined above (see Messaging Utilization). The features of the deskless clients, however, may appeal to all levels and types of users.
Important: Since these clients rely on the POA to supply 100% of the content to the WebAccess gateway, the performance of the POA is critical

.

POP3/IMAP4
Since these clients are limited to e-mail information only, post offices dedicated to POP3 or IMAP4 clients can hold many mailboxes; and since individual mailboxes will be smaller in size, they will operate more like the light mail users. Note however, that the POA has to deliver 100% of the content to the GWIA for delivery to the POP3/IMAP4 clients and that where a POA is serving a mixed use Post Office (POP3/IMAP4/GroupWise Client) it will not be operating at maximum efficiency.

Additional factors


Multiple external E-mail Accounts: POP3 or IMAP4

Multiple external POP3 or IMAP e-mail accounts that are consolidated within a GroupWise Mailbox can cause a post office store to grow quickly in size; the mailbox size limits available in GroupWise can help manage this. Additionally, the administrator can limit who has the ability to access multiple accounts from the GroupWise client.
Once messages are in the message store, the mailbox access mode (listed above) will be used to read messages.

NNTP

Internet news group information can also add to the size of the mailbox message store. In turn, this will add to the GWCheck, backup, and restore times. The mailbox size limits available in GroupWise can help manage this. Additionally, the administrator can limit who has the ability to access news groups from the GroupWise client.
Once the NNTP messages are in the message store, the mailbox access mode (listed above) will be used to read messages.


User Administration


It might sound strange, but when designing a GroupWise system it is important to know how some aspects of User Administration are intended to be carried out. When migrating from another collaboration platform the bulk creation is fine - as is creating single users via the help desk administrators.

What about Novell IDM I hear you say?

Novell IDM has good GroupWise drivers and if implemented in your network infrastructure should be incorporated into the GroupWise User Administration. Creating a dedicated IDM Administration Domain is also a good concept - similar to having a Domain for the help desk administration. There are a number of Cool Solutions articles that help in the design and configuration of GroupWise IDM drivers

A couple of examples would be:

Load Balancing User Placement in GroupWise Post Offices - Part 1 & Part 2
Troubleshooting GroupWise Driver External User Creation