Gregg Hinchman has just written a new eBook that is now available at www.taykratzer.com. He has graciously shared Chapter 1 with Cool Solutions, and we presented it in a four-part series. The full title of this outstanding work is Success with Clustering GroupWise 7: A Guide to Building a Highly Available GroupWise 7 System on an OES NetWare Cluster. Enjoy!
Part 1
Part 2
Part 3
Part 4
Part 1
Email has shifted from a business application to a business necessity. Next to the network itself, end users demand constant access to their email. It was estimated that close to $9 billion dollars was lost in productivity when the Blaster virus took hold of email systems across the United States. Luckily for most of us, GroupWise is not often susceptible to viruses that destroy the integrity of the email system. However, GroupWise is at risk of downtime when servers fail, whether its hardware or software failure. More and more organizations are trying to secure their GroupWise systems and ultimately their businesses from downtime. Novell, seeing the growing demand for high availability, created clustering for its OES NetWare operating system.
Novell also realized the demands being placed on email systems - GroupWise in particular. They tasked themselves with making GroupWise one of the first truly cluster-enabled applications. The rest is history. GroupWise is notorious for being very stable outside of a cluster, and now with clustering, GroupWise can attain the five "9s" of uptime (99.999%).
Building a highly available GroupWise system requires detail-oriented planning, and a tenacious desire to implement the plan to perfection. There are many pitfalls along the way. This book, I hope, will expose those traps and help you smoothly plan and implement GroupWise in a clustered environment. My goal is for you to have success with clustering GroupWise.
I briefly want to touch on the term "best practice" which appears throughout this book. Best practices are the lessons learned either from implementing a solution or from supporting a solution. I am not alone in my delivery of best practices; I have a long list of fellow consultants, engineers and customers who have provided best practices to the GroupWise community. I have just gathered this wisdom, tested it in the field, and am presenting it here. This allows the reader to capitalize on my lessons. Now let's discuss the format of this book.
This book assumes you have a good understanding of Novell Cluster services (NCS), OES NetWare, and certainly GroupWise. I will review some clustering basics, but will not teach you how to build a cluster. The following will also be discussed: Open Enterprise Server (OES) NetWare service pack 1, NCS (Novell Clustering Services) 1.8, and GroupWise 7.0. Please understand that although GroupWise 6.0x and above are cluster-able, I will not address them in this book. Also, because GroupWise 5.5x is "end of life" by Novell, clustering it will not be discussed. Finally, because OES NetWare is the lead OS for Novell I will focus on it, NetWare 6.0x is end-of-life and therefore not discussed. Lastly, OES Linux will not be discussed within this book. OES Linux is an entirely different operating system and requires an entirely different forum, or book. Please stay tuned to www.TayKratzer.com and GroupWise Cool Solutions for word on success with Clustering GroupWise 7 on Linux, slated for a March 2006 release. So let's get started.
PLEASE READ THIS CHAPTER - If you are familiar with clustering, great -- most of this chapter will be a review. However, in this chapter, I have laid out some basic terms that will be important to understand as you read the book. I also include information on SAN design, LUN design, and Business Continuity Clustering. Finally, the basics of my GroupWise system design are presented within this chapter. I hope this chapter will be a guide for you, the reader, throughout this book.
This chapter is meant to help you assess your environment and perhaps make some changes to prepare for clustering. For example, you may decide you want to increase memory on the servers in your cluster or redesign your existing SAN hardware. Also, to provide the maximum benefit from reading this book, I have provided strategic checkboxes [ ] in places where you will want to perform an action. I call these "action items." Here is an example:
[ ] 1. Verify ConsoleOne Snapins version.
This section provides an overview of clustering. I consider this information to be the minimum knowledge a GroupWise administrator must have about clustering.
What is a cluster? Simply put, it's a bunch of servers gathered round a Storage Area Network (SAN) -- a.k.a., tons of hard drives and disk space -- with excellent communication and sharing skills. In NetWare Remote Manager (NRM) a cluster object looks like three red globes connected to one another with pipes. Figure 1.1 shows a cluster object in NetWare Remote Manager (NRM).
Figure 1.1 The Cluster Object in NetWare Remote Manager
A cluster node is a server that is participating in the cluster. Any cluster node (a server) can host any Novell Storage Services (NSS) Pool and its subsequent volume at any given time. A cluster node object in NetWare Remote Manager looks like a server object with a red globe next to it. Figure 1.2 shows a cluster node object in NRM.
Figure 1.2 The Cluster Node Object in NetWare Remote Manager
A cluster resource object is an NSS Pool, for sake of conversation, with some other attributes that make it a "cluster resource" and effectively a "virtual" server. Novell Cluster Services makes each cluster resource appear as a NetWare Core Protocol (NCP) server. Therefore a volume on a cluster resource (NSS Pool) becomes a server with its own IP address. Each NSS Pool should have only one NSS volume and together they are considered one cluster resource. A cluster resource object looks like a volume object with a small red globe next to it. Figure 1.3 shows a cluster resource object in NRM.
Figure 1.3 The Cluster Resource Object in NetWare Remote Manager
These cluster resources can travel between cluster node servers as needed. If one cluster node is down (failed) then the clustered resource hosted by that node can "fail over" to another node. If that node fails, the resource can fail to the next, and so on, until you are out of nodes. During all this fail-over activity, end users are unaware of the failures, because their services are available to them.
The cluster is managed through iManager, NetWare Remote Manager, or even ConsoleOne. In the case of ConsoleOne, you need the latest Novell Cluster Services (NCS) Snapins. NetWare Remote Manager (NRM) is loaded and configured automatically whenever an OES NetWare server is installed. NRM is the fastest and easiest of cluster administration tools. It provides all the basic functionality needed to manage a cluster. To access NetWare Remote Manager, use a web browser and point to the following:
https://ipaddress of server:8009.
iManager must be installed on at least one server in your eDirectory tree in order to be accessed. When installing an OES NetWare server, you can manually choose to have iManager installed and running on the server. If you do, iManager can be accessed using a web browser pointed to:
https://IPAddressOfServer/nps/servlet/webacc
There are two views for managing clustering in ConsoleOne: Cluster State View and Console View. Both views can be accessed by right-clicking on the cluster object, selecting View, then choosing either Cluster State View or Console View.
Note: To determine if you have the Clustering Snapins:
If for some reason you do not have these Snapins, you can obtain these Snapins as follows:
Note: At this time, there are no NCS 1.8 Snapins for ConsoleOne. This is primarily because iManager is now the main Administration console for all OES and clustering. You will however find a plug-in for iManager for NCS 1.8. However, if you have installed OES NetWare sp1, you will already have this plug-in.
[ ] 1. Verify ConsoleOne Snapins version.
The Console View allows you to manage all the current cluster resources configurations. You can also add cluster resources in Console View. Think of the Console View as the configuration view. There are cluster resource templates in Console View that make it easier to create cluster resources. There is even a GroupWise cluster resource template, but I recommend you ignore it. The cluster load/unload scripts are set up within the template to ease the clustering of GroupWise. However, these templates are not of much use. Luckily, you have this book - you will be given details on how to build the GroupWise cluster resource load/unload scripts. Figure 1.4 shows the Cluster Console View.
Figure 1.4 The Cluster Console View in ConsoleOne
You can modify or change cluster resources through Console View by right clicking on the resource and selecting Properties. Here, you can change the cluster resource IP address. What, you ask; a cluster resource has its own IP address? Yes it does. Essentially, a cluster resource "appears" to be a server. This is known as a "virtual server". Behold the magic of clustering. Each volume is known by eDirectory as a server (or, rather, a virtual server), therefore it must have its own IP address. This makes clustering GroupWise easy because GroupWise 6.0x and above are fully IP-enabled. Figure 1.5 shows the Cluster Resource object's IP address property page in ConsoleOne.
Other items available in the Properties of a cluster resource object are cluster load/unload scripts, policies, and nodes.
Cluster Load/Unload Scripts
The cluster load/unload scripts are like login scripts for cluster resources. OK, not quite the same, but you get the idea. When a cluster resource is loaded, it reads and runs the information in the load script; and when it unloads, it reads and runs the unload script. Within the cluster load script are all the commands to activate the NSS Pool that holds the cluster resource. For example: statements such as "CVSBIND" and "NUDP" (which are explained later). There is also a command to add the secondary IP address. It's this secondary IP address that is considered the "server" IP address; and it's this secondary IP address that is assigned to the clustered resource I use for clustering GroupWise. Figure 1.6 shows an example of a cluster load script for a GroupWise cluster source.
Figure 1.6 Cluster Load Script
Each line is numbered for ease of reference in this guide, but it would not be numbered in an actual load script.
1. nss /poolactivate=PMDOMVS
2. mount PMDOMVL VOLID=254
3. CLUSTER CVSBIND ADD PMDOMVS 192.168.20.101
4. NUDP ADD PMDOMVS 192.168.20.101
5. add secondary ipaddress 192.168.20.101
Line 1 activates the NSS pool, which is titled PMDOMVS.
Line 2 mounts the PMDOMVS volume and assigns it a volume ID of 254.
Line 3 performs the CVSBIND ADD. This is the Cluster Virtual Server statement.
Line 4 performs the NUDP ADD. This enables the service advertising for the resource.
Line 5 adds the secondary IP address and binds it to the OES NetWare server.
Here is an example of a cluster unload script for a GroupWise cluster resource. Each line is numbered for ease of reference in this guide, but it would not be numbered in an actual unload script. Figure 1.7 shows an example of a Cluster Unload Script for a GroupWise cluster source.
Figure 1.7 Cluster Unload Script for a GroupWise Cluster Source
1. del secondary ipaddress 192.168.20.101
2. CLUSTER CVSBIND DEL PMDOMVS 192.168.20.101
3. NUDP DEL PMDOMVS 192.168.20.101
4. nss /pooldeactivate=PMDOMVS /overridetype=question
Line 1 deletes the secondary IP address binding from the OES NetWare server.
Line 2 performs the CVSBIND delete.
Line 3 performs the NUDP delete to stop service advertisement. NUDP has changed to provide "more graceful" client disconnects. This change waits until all NCP connections have been terminated. This wait time can vary, so another parameter -- the ODEL parameter -- was added. The ODEL parameter change can be used to speed up the fail- over times of the cluster resources. This is specific to unload scripts only. The command looks like this: NUDP ODEL. See Novell Support Knowledgebase TID #: 10086057.
Line 4 deactivates the NSS pool and adds a switch to override any questions asked during the process.
Cluster Policies
Each cluster resource can have different policies. These policies state how the cluster resource will act during certain cluster events, such as fail over. It is important to note that GroupWise cluster resources Failback Mode should be set to Disable. It is better to manually failback a cluster resource to its starting node. In the case of the Fail-Over Mode, it should be set to Auto, otherwise the cluster resource will never fail over to its next node, GroupWise will never load on that node, and you will have downtime. Figure 1.8 shows the Cluster Resource object's Policies property page in ConsoleOne.
Figure 1.8 A Cluster Resource - Policies Property Page
Cluster Nodes
The Nodes property page is where you assign nodes (actual servers) to the cluster resources' fail-over list. You can add as many or as few as you require. The cluster resource and hence the GroupWise service will fail over to each node in the order they are listed. Figure 1.9 shows the Cluster Resource "PMDOMVS_SERVER" object's Nodes property page in ConsoleOne.
Figure 1.9 A Cluster Resource - Nodes Property Page
The Cluster State View is where you monitor the cluster; its nodes, and the cluster resources. You also load, unload, and migrate cluster resources in this view. Assuming you have configured your cluster resource with nodes as previously discussed, you can simply click on the cluster resource in the lower portion of the Cluster State View and, in the resulting dialog; select either the Offline or Migrate button. If you select Offline, the cluster resource unload script will run, GroupWise will unload, and the cluster resource will be offline. It's like dismounting a volume.
In the case of migrating the cluster resource, click on the resource, and in the resulting cluster resource management screen, select the cluster node that will be the Migration Target. Then select the Migrate button. At this point, the cluster resource unload script will run, GroupWise will unload, and the cluster resource will go offline (actually it is unassigned) for a moment. Then the cluster load script will run, the cluster resource will be assigned to the new node, and GroupWise will load. All of this can happen within 30-60 seconds and the user may never know. It is very important from a GroupWise clustering perspective to know how to online, migrate, and offline cluster resources. Before the GroupWise system can go live on the cluster, you must test your load and unload scripts. Figure 1.10 shows the Cluster State View in ConsoleOne.
Figure 1.10 The Cluster State View in ConsoleOne
NetWare Remote Manager let you work with all the same features that exist in Cluster State View, such as online, offline, and migration of a cluster resource. It also allows you to make configuration changes to the cluster resource, such as IP address and nodes. These tasks are handled under the Clustering Menu link in Remote Manager. There are two management selections under the Clustering Menu link: Cluster Config and Cluster Management.
Cluster Config is where you configure cluster resources. Cluster Config, shown in Figure 1.11 below, is similar to the ConsoleOne Cluster Console View. Cluster Management, shown in Figure 1.12 below, is where you manage the cluster. It is similar to the ConsoleOne Cluster State View in ConsoleOne. The beauty of Remote Manager is it talks directly to the server(s) without Snapins, which means you get the most aCurate information. Every once in a while, ConsoleOne Snapins may not function properly.
Figure 1.11 Cluster Config in NetWare Remote Manager
Figure 1.12 Cluster Management in NetWare Remote Manager
Accessing NetWare Remote Manager (NRM) is very easy. NRM is loaded and configured during the installation of the server. To access NetWare Remote Manager:
[ ] 2. access NetWare Remote Manager.
Yet a third option for administering a cluster is iManager. iManager is the newest of the Novell utilities for administering all Novell products. iManager must be installed either during the installation of a server, or afterward, in order to be used. iManager is a web-based administration tool that uses Apache2/Tomcat4. To access iManager:
Figure 1.13: iManager Clusters Link
iManager - Cluster Options
iManager's Cluster Options has the same features as NRM's Cluster Config and ConsoleOne's Console View. This means you can edit the cluster resource IP Address, nodes, load/unload scripts, and other settings.
Figure 1.13a iManager Cluster Administration - Cluster Options View
Figure 1.14 iManager Cluster Administration - Cluster Options View - Cluster Resource Properties
iManager -Cluster Manager
The iManager Cluster Management link, shown in Figure 1.15, provides all the same features as ConsoleOne Cluster State View, and NetWare Remote Manager's Cluster Management link. You can online/offline or migrate a cluster resource, and check the status of the cluster.
Note: In the past, in order to use all the features of iManager, you had to use Microsoft Internet Explorer. Not so anymore; I use Firefox 1.07 and it works beautifully.
Figure 1.15 iManager Cluster Administration -Cluster Manager View
[ ] 3. access iManager.
Those are my cluster administration tools. Of the three I have discussed, NetWare Remote Manager (NRM) is my favorite. It's the easiest to use, requires no configuring, and provides a well-rounded view of all the cluster components. Within this book I will use NRM for most tasks.
End Part 1
Gregg A. Hinchman is a self-employed consultant (www.HinchmanConsulting.com), and Novell Consulting Partner. He has supported GroupWise for more than 11 years. He specializes in GroupWise, Clustering, eDirectory, NetWare and GroupWise Document Management. He currently carries 18 Novell Certifications, including CDE, MCNE and CNE NetWare 6. He is also certified IT Project and regularly provides project management for clients. Gregg is the co-author of success with GroupWise Document Management and has spoken at Novell's Premiere Technology Conference "BrainShare" four years running in the United States and abroad as well as GroupWise Advisor Summit. He lives in Indianapolis, Indiana, and spends his vacation time seeking mountain summits "just for the view." He is always for hire at very reasonable rates. Gregg's modest website can be found at: http://www.hinchmanconsulting.com/.
Support
Documentation
Learning Services
Partner Programs