Migrating a NetWare Cluster to an Open Enterprise Server Linux Cluster

The presenters were the authors of Novell Cluster Services for Linux and NetWare.

The point of the presentation was to move the cluster resources from an existing cluster running on NetWare to one on Linux without having to recreate the cluster resources.

In Linux clustering you use YaST to configure cluster nodes. There are similar but not identical cluster commands on Linux to those on NetWare. On Linux, you manage the cluster from iManager, but you can’t use ConsoleOne. You can also have Linux native filesystems as cluster resources. In SLES9 there is no iSCSI target, just an initiator, so if you want an iSCSI target you need NetWare. If you are using a SAN or shared SCSI you don’t need any NetWare servers for the cluster.

Supported filesystems for cluster resources include NSS, ext3, reiserfs, polyserve, or ocfs2. NSS has the advantages of having ACLs, inheritance, quotas, visibility, salvage, and large numbers of files, and huge filesystems. It is the best for shared storage for NCP clients, but reiserfs can also have all these features except quotas and salvage when shared via NCP on Linux. The disadvantage of NSS is that the metadata richness makes it a bit slower than reiser and some of the other ones.

When migrating to Linux from NetWare clusters, use NSS if you have existing resources. For stuff like iFolder, iPrint, AMP, GroupWise, and Instant Messaging, use Reiserfs because the features of NSS are not needed and reiserfs is faster.

Use reiserfs if a cluster aware filesystem is not needed. If a cluster aware filesystem is required, use PolyServe or OCFS2 (SUSE10). That will be available in OES2 based on SUSE10.

For GroupWise, do not use ext3 because it gets slow with large numbers of files which are generated by GroupWise.

For migration, you can do an in-place upgrade. You cannot do an in-place upgrade and maintain your configuration. You can do an over-the-wire migration and maintain your settings. You can also do a mixed-mode cluster by adding your Linux nodes to your cluster, migrate your cluster resources to the Linux nodes, and then decommissioning your NetWare cluster nodes.

The best upgrade scenario is to use SP2 of OES Linux and OES NetWare 6.5 and do a rolling upgrade by adding your Linux nodes to the NetWare cluster. Using a mixed cluster is not a permanent solution, but only really for migrating to a Linux cluster configuration.

After adding Linux nodes to a NetWare cluster, you can no longer add NetWare nodes. Also, some types of shared filesystems are not visible between the two systems until one or the other reboots, so it is not practical for long term. Also, the way Linux stores rights in nss is via the xml trustee file, but on NetWare rights are stored on the filesystem, so if you migrate back and forth the trustees get out of synch between the two. Also, cluster resources created on Linux won’t run on NetWare. Cluster resources created on NetWare are automatically translated for running on a Linux node but not the other way around.

To do a rolling upgrade, migrate all your resources off one NetWare cluster node. Then remove the NetWare node, install Linux on it, and add it to the cluster. Then migrate resources to another node and continue.

They did a demo where they built shared storage on an iSCSI target on NetWare and had two NetWare cluster resources pointing at the shared iSCSI storage. Then the migrated the resources to one node, installed Linux on the other node, and then added it to the cluster, migrated the resources, and then did the other NetWare node upgrade to Linux. The cluster resources were maintained in service the whole time.

Some guy asked about licensing. If you add a third node, you need a license. For Linux, you don’t actually need to have a license file. It works on the honour system. It still only includes a two node cluster license, but it is not enforced by the software.

If you have a problem with time synchronization in VMware virtualized Linux severs, you can use the grub menu.lst file to set a kernel parameter that says clock=pit, and then turn on clock synchronization in vmware tools, which should resolve the problem. This tidbit was contributed by an audience member. Another option if you can’t run vmware tools, is to set the kernel parameter clock=pmtmr, which makes the kernel more carefully correct for wonky timing, resulting in a more accurate clock. In SUSE 9x kernels, the default clock setting is clock=tsc, which aggressivly overcorrects for lost ticks, which makes the clock wildly inaccurate in SLES-based virtual machines. Here’s a vmware knowledgebase article on the subject. Google is my friend.