Consultants Corner: Planning for GroupWise 7 on Linux Clusters
Novell Cool Solutions: Feature
By Gregg Hinchman
Digg This -
Posted: 17 Jul 2007
"Hey! Oh yeah! Ain't no way I'm sitting home tonight. I'll be out until the morning light. Just hangin' 'round the local parking lots." Images of a youth's summer ... summer time brings me memories of my youth; days spent at the beach, nights spent 'cruising' or just hanging out, all while soaking up sun, fun, and fresh air. Nowadays summer time brings freezing cold server rooms, fun GroupWise, and burning hot Linux clusters. During the summer, it seems that most organizations start their big projects, such as redesigning GroupWise, upgrades, or building new systems such as Linux clusters.
GroupWise 7 has been primed and ready for clustering for many years. But consider this: GroupWise 7 is the only enterprise collaboration system primed for Linux clusters. GroupWise 7 works on OES Linux and Novell Cluster Services, and it works with SLES 10 and Heartbeat 2 (Linux clustering). As many organization continue improving the stability of their GroupWise 7 system and do upgrades of hardware and operating systems, Linux clustering is gaining ground.
As with any project, clustering GroupWise 7 - whether on NetWare or Linux - requires attention to detail and proper planning. In this article, I would like to touch on a few things you should consider if you want to cluster GroupWise 7 on Linux. Let's take a look at the list.
All Things to Consider
As a consultant, before I ever start an implementation, I lay out a list of tasks - items to consider in order to properly build a plan for a successful implementation. In my book, "Success with Clustering GroupWise 7" for OES/NetWare (www.taykratzer.com), I go through painstaking detail on planning, devoting nearly 50 pages to the topic.
For Linux, it's much the same; the same details that is, but a few new considerations as well, such as file systems and mount points. So let me list out things you should consider in order to cluster GroupWise 7 on Linux:
- Number of Nodes - How many Linux servers?
- Naming Standards - What is everything going to be called?
- IP Address Scheme - What is your IP Address plan?
- Port Standards - Using standard or non-standard IP ports?
- Size of Disk - How much space do you need?
- File Systems - What Linux-supported file system to use?
Number of Nodes
There are several variables that go into deciding how many nodes are required for a cluster. First, consider the number of Post Offices you'll place on the cluster to get a base number. A two-node cluster isn't much of a cluster, because the loss of one node leads you to a stand-alone solution. So I recommend a minimum of 3 nodes.
Adding the third node increases the availability of servers for the Post Office to fail over on. The key to creating a high availability cluster is in the number of nodes. The more nodes you have, the more places a Post Office, gateway, or domain has to run in a fail-over situation.
Budget is always a consideration. Because a cluster requires a SAN, which is typically an expensive purchase, there may only be budget available for a few nodes. Most nodes are inexpensive servers with a single processor, three to four Gigabytes of RAM, a Network Interface Card (NIC) or two, and up to two Host Bus Adapters (HBAs). HBAs are the "communication cards" to the SAN.
Does the hardware support Linux? This part of planning is extremely important and may require an e-mail to your hardware vendor asking if the servers it wants to sell you support Linux. If so, what versions of Linux? All hardware must support Linux, even the SAN.
What's in a name? Well, frankly, a lot. I find naming is one of the most important but most overlooked parts of planning. In order to make administration easy, make the naming standards simple and logical. Here are a few things that need names:
- Cluster objects
- Cluster nodes
- Cluster resources
- Disk segments and mount points
The best naming standard is one that uniquely identifies the services running. Obviously, if you have only one cluster, then something simple such as the type of cluster will work. For example: OESLXC, short for Open Enterprise Server Linux Cluster. But what if you have several clusters, possibly for different services? You might consider something like OESLXCGW for Open Enterprise Server Linux Cluster GroupWise. Or, you could try OESLXCFP, where the "FP" stands for file and print.
Cluster nodes follow a similar path. If the node is running OES Linux, then a name like OESLXS1 for server one makes sense. If you are considering Novell Business Continuity Clustering (BCC is a cluster of clusters), you might consider node names like OESLXS101 (the first node in the first cluster) and OESLXS201 (the first node in the second cluster).
When it comes to cluster resources, disk segments, mount points and volumes, I prefer to give them each distinguished names so that I can tell which which is which at any moment in time. Try something like this:
- Cluster Resources (virtual servers) -?VS? on the end of the name for virtual server. Example: PODOMVS =Post Office Domain Virtual Server
- Disk Segments -?DS? on the end of the name of the disk segment created in EVMS Administration -Enterprise Volume Management System. Example: PODOMDS.
- Volumes -?VL? on the end of the name to denote its a volume. Example: PODOMVL.
- Mount Point -?VL? on the end of the name to denote its a mount point to a volume. Example: PODOMVL. This is a Linux thing: mount points are directories on the local system (node) that represent a different file system on the local box or another system.
IP Address Scheme
In clustering, you want every node to potentially be able to hold every GroupWise component. Because cluster resources are virtual servers with an IP address assigned to them, and because cluster resources can travel to any node in a cluster, it's the preferred IP address for GroupWise components stored on them.
You need only have IP address standards set for cluster nodes and cluster resources. Then the services (GroupWise POA, MTA, Gateways) use the cluster resource IP addresses. In most clustering implementations, organizations simply assign a completely new IP subnet for all things tied to the cluster. This practice allows for contiguous grouping and logical management of the cluster and all its services.
I like to bring order to IP Address standards by matching up the last octet, or a portion of it, with the node number, like this: OESLXS101 has an IP address of 192.168.20.101. I extend that to cluster resource IP Addresses as well but allow for growth. So, you might consider something like this for cluster resources and the GroupWise 7 components they hold:
- 192.168.20.11x -for Primary domain and Post Office domains
- 192.168.20.12x -for Post Offices
- 192.168.20.13x -for WebAccess domains and their gateways
- 192.168.20.14x -for GroupWise Internet Agent (GWIA) domains and gateways
With GroupWise 7 you can use the "Bind Exclusive" box on the agents to ensure the GroupWise component ONLY listens for ports on its assigned IP address on a node. This allows you to use the GroupWise 7 default ports. Or, with a bit of planning you can assign standards to the GroupWise 7 components and their ports to guarantee there will be NO port conflicts. I prefer and recommend this, to avoid any potential problems with port conflicts.
Here is an example for assigning port standards:
- 710x is for MTA MTP
- 720x is for WebAccess TCP Ports
- 730x is for POA MTP IN Ports
- 280x is for POA HTTP
- 380x is for MTA HTTP
- 480x is for Gateway HTTP
- 168x is for POA Client/Server
- 74xx is for WebAccess Document Viewer Ports
Size on Disk
How much disk space do you need for a GroupWise domain, Post Office, and gateway? There are many ways to figure this out, but I prefer an easy method that works well, based on my practical experience. Here it is: Determine the current disk space used and multiply that number by a factor of 2 or 3, depending upon the growth rate. Yeah, it's not scientific, but it's quick and easy - and it works. Remember, it's better to have more available disk space than you use - otherwise, you may find yourself reengineering.
OK, so Linux and GroupWise 7 users just scream the same thing every time I present on the topic or discuss with customers: What file system should we use? Well, let me see if I can give you the quick answer: It depends. Ouch! That was no help. Here is what I mean ...
NSS is supported on OES Linux and OES NetWare. Of these, NetWare, NSS and GroupWise have the best performance. This is truly due to the longevity and history of NetWare and GroupWise. But NSS performance is not as good on Linux as are the native Linux file systems.
Reiserfs is the recommended file system for GroupWise. Internal Novell Post Offices running on Linux use Reiserfs, and most testing has been done on this file system. It has an advantage over Ext3 in that it's optimized for handling large numbers of small files, and it efficiently uses disk space.
The Ext3 file system is a journaled file system and is quite robust, with performance similar to Reiserfs. However, it doesn't scale well to large volumes (the max is 2TB or large numbers of files). Recent changes, such as adding trees, allow for greater scalability. A recent update to Ext3 may have eliminated these few limitations, making Ext3 a potential better solution for GroupWise 7.
What do I recommend? Well, if you are using SLES 10 with Heartbeat, go with Ext3 or Reiserfs. If you are using OES Linux, I would stick with Ext3 or Reiserfs. If you're on NetWare, do NSS.
On a personal note: I have a feeling the future will find Ext3 preferred for GroupWise on Linux. (These are my feelings and thoughts only - as I sense them in the "Force.")
To sum it all up, planning for GroupWise 7 on Linux is similar in many ways to planning for NetWare. There are a few more items to consider and clustering increases the planning as well. Just remember: whatever your direction, take my advice and follow this simple 6-step program: Plan, Plan, Plan, Document, Document, Document. I guarantee it will make your implementation go smoother and help you to enjoy some hot "Summer Nights."
As always, I can be reached at: Gregg@HinchmanConsulting.com if you have any comments or article ideas, or just want to help a quirky consultant support his GroupWise habit.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com