Clustering is simply a group of servers that share a centralized data store or Storage Area Network (SAN). These same servers work together as a "team," helping each other provide services for organizations. This "teamwork" benefits the organization in many ways. First, it lets the organization consolidate their many data centers and servers into one. This centrali- zation and consolidation has a second benefit of easing the administration of geographically separated networks. The third benefit of clustering is the potential for 99.999 percent uptime for all network services including data, and especially e-mail.

The demand for clustering

This is where GroupWise comes into play. After Novell introduced clustering, the immediate demand by organizations was to cluster GroupWise. Unfortunately, clustering has been cost-prohibitive. SANs and their related Fibre Channel hardware are expensive. One Fibre Channel card for a server currently costs US$1,000 on average. Early adopters of clustering believed the long-term savings to the organization -- via reduced network downtime and the related employee productivity increases -- were worth the short term costs. They were correct. They reaped the competitive advantages as their competition fell behind. These organizations protected their bottom line against the real threat to networks, daily downtime.

Once again, we're about to enter a new era in clustering. Internet Small Computer System Interface (iSCSI) will create a paradigm shift in the implementation of clustering. Boldly stated, it appears 2004 may be the year of iSCSI, to wit, the year of clustering. Novell is ready to hail in the new year with NetWare 6.5, Clustering 1.7, and GroupWise 6.5. NetWare 6.5 fully supports iSCSI.

Benefits of iSCSI

Before I go any further, let's look at iSCSI and its benefits to the organization. First, it's cheap, compared to SANs and Fibre Channel technologies. Second, it's easy to work with because it relies on current established technologies and isn't as sensitive to handling as Fibre Channel. Third, it can span the WAN in its basic implementation.

iSCSI is a standard of the networking industry (not be confused with other Novell technologies with names that start with an "i", such as iFolder). In simple terms, iSCSI is the ability to carry SCSI storage-based commands over an IP-based network.

Where does Novell come into play?

Everywhere. Here's an example. An organization with 10 servers -- five NetWare 5.1 and five NetWare 6 -- can implement iSCSI and clustering by simply adding one NetWare 6.5 server. This new server will become the SAN and all the older servers become the cluster nodes. This brings the potential for 5 nines (99.999 percent) down to an affordable level. Granted, the new server will require lots of disk space and RAM, not to mention RAID 5. But, this one server is far cheaper than one SAN -- so much so that this same organization may purchase a second server to provide redundancy at a remote site to hedge against disasters at the main site. This configuration is called a stretch cluster.

But, let's go back to GroupWise 6.5. Besides being an amazing collaboration product, it's fully clusterable. All domains, post offices, and gateways can run on the SAN, which means users are never aware of downtime caused by the hardware or due to preventive maintenance such as upgrades.

When properly implemented, clustering gives an organization a rock solid, highly available GroupWise system. The key is in the details of clustering. Take a look at cluster load scripts for a moment. Cluster load/unload scripts load and unload applications within a clustered environment, as well as configure the cluster resource. The funny thing is, these scripts have a size restriction with Novell Cluster Services. The formula is: Sum of Load scripts + Sum of Unload Scripts -100 > or = 1024 bytes. It's this kind of detailed information and improper implementations that has kept clustering out of the mainstream.

Moving to Novell Clustering Services

Following is a high-level view of the steps you would take to move your GroupWise environment to Novell Clustering Services.

The first steps to providing your organization with a highly available GroupWise system lie in the planning. Organizations must first evaluate the company financial situation to determine if clustering GroupWise is feasible and, second, if it protects the bottom line. Next, the IT department must step up and evaluate its GroupWise environment, making sure it's healthy before they introduce any changes.

Another part of the planning is determining how you want to cluster GroupWise. Do you want to cluster the entire system or just parts of it? After you determine this, it's time to document the planning. Each component of GroupWise requires a thorough review, followed by documenting such items as Message Transfer Agent IP addresses, Post Office IP addresses, and all their related ports.

After you complete all the planning, it's time to cluster GroupWise. Whether the organization is using iSCSI or Fibre Channel, you must build the cluster. Next, you must create the cluster resources and test the entire cluster. Remember, GroupWise is only as stable as the hardware on which it rests.

It's time to move GroupWise to its new home in the cluster. Novell has developed an incredible tool to assist in moving all kinds of data, including GroupWise, called the Novell Server Consolidation Utility. This simple utility can move data at speeds of 4GB per hour or better. After the GroupWise system is moved to the new cluster, it's just a matter of bringing up the respective agents, testing GroupWise, and setting the cluster load scripts.

Remember earlier I told you about the limits of the scripts? Well, now we have a solution. Call .NCF files from the cluster scripts to load or unload GroupWise. This has many benefits and only one downside. The downside is that the Cluster Resource Manager's error detection won't work for the lines inside the called NCF. What does this mean? It means that if the load line you typed in the NCF isn't correct, error detection won't know it, and will continue loading or unloading as the script requests. Is this a big deal? No, because the .NCF file will be tested before it's ever called from the script. The benefits of the .NCF files are many. First, it lets you separate the network administrators, who manage the cluster, from the GroupWise administrators, who manage GroupWise. Also, when a change is made to the way GroupWise is loaded or unloaded, you can run it from the server manually using the modified NCF, and the cluster scripts are never touched. Every time you change a cluster script, you must first take the cluster resource offline, then put it back online -- a tedious task, to be sure. Imagine having to do this for a large multi-domain GroupWise system. A third reason is the administrator. When you take a cluster resource offline, all files on that resource aren't available. This means if an administrator is troubleshooting a GroupWise issue, he has to remark out the load/unload script lines, move the resource offline for the changes to take effect, then put them back online to troubleshoot GroupWise loading issues. So, you can see the benefits of calling the .NCF file.

Now that GroupWise is up and on the cluster, you must set a failover path for the cluster resources. This should have been documented during the planning phase. But, if not, remember to try to keep two post offices from being on the same server node, at least during the first failover.

Another beauty of clustering is protected memory. Protected memory is an administrator-defined space where the NLMs will load. NLMs in this space can't cause other NLMs outside the protected memory space from performing, in essence ABENDing. Here's a simple analogy. Pretend you're an NLM. Now, pretend your office has four walls, a floor, and a ceiling; it's a protected memory space. Assuming your door is closed and you don't share your office, try to touch a person outside your office. You can't. This is how protected memory works. It isolates the NLMs from other NLMs. This means you can have two post offices running on one cluster node and they won't contend or corrupt each other.

That's it!

Clustering GroupWise is simple with the right training, planning, and attention to detail. Feel free to drop me a line at tkratzer@novell.com with any questions that come up.