Chapter 10
Upgrading Clusters
In this chapter we describe how to upgrade existing clusters to newer versions of the Novell Cluster Services software. Both NetWare and Linux are covered in this chapter, as well as upgrading via the mixed-node cluster route. These are the upgrade scenarios that are covered in this chapter:
Upgrading a NetWare 5.1 cluster to NetWare 6.5
Upgrading a NetWare 6 cluster to NetWare 6.5
Upgrading a NetWare 6 or 6.5 cluster to Open Enterprise Server Linux
Migrating to a new cluster, for all versions of NetWare
Note
The code base of NetWare 6.5 with Support Pack 4a is effectively the same as Open Enterprise Server with Support Pack 1. Also, NetWare 6.5 with Support Pack 5 is identical to Open Enterprise Server (OES) with Support Pack 2. Therefore, where we talk about NetWare 6.5 you can also read “Open Enterprise Server NetWare.”
Tip
The method of migrating to a new cluster can also be used to move existing servers into a cluster if the existing servers cannot be added as regular nodes, or when servers will be consolidated.
We start this chapter by describing the available upgrade scenarios from a functional and practical point of view before diving into the technical details of each solution.
In general there are three upgrade methods available for upgrading servers, and these are also the methods for upgrading clusters:
Upgrading the existing hardware and software, also called an in-place upgrade
Upgrading to new hardware and software in the same environment, also called an across-the-wire migration
Installing completely new hardware and software from scratch
These three upgrade methods and their pros and cons are discussed in the text that follows. Every environment is different and many parameters are important to making a decision for your specific approach to upgrading, such as available budget, technical state of your existing environment, administrator knowledge level, and the knowledge and resources in your upgrade project team. We have tried to give you the guidelines to find your own best approach.
If this approach is technically possible, it is the fastest and simplest method to perform an upgrade. Just load the CD-ROM into the server, run the upgrade, and you are ready. But unfortunately this method is not always supported. Besides any technical limitations, it is also the most risky method, and it might not be possible if your current hardware and software are too old.
Let us start with the practical pros and cons before discussing the technical ramifications. The most important benefit is ease of installation and the short amount of time needed. An upgrade from a NetWare 6 cluster, for example, to a NetWare 6.5 cluster can be performed by starting the server upgrade from the NetWare 6 server’s graphical installation screen the same way as you would normally install a new product. The upgrade can be started while users are working, up to the point at which a reboot is required. This can be performed on all cluster nodes. When the first server is ready, it can be restarted, after which the upgrade will be completed. Per server, this process takes only a very short time. No data has to be copied via the network, which is always time-consuming. With some extra checking and maybe some manual tasks for upgrading services, such as backup software, the upgrade takes two to three hours per server, and some tasks can be performed simultaneously on multiple servers.
The largest disadvantage of this in-place upgrade method is that the risk is the highest. If during the upgrade a problem occurs that prevents you from moving forward, the path back to the original situation is the most complex and time-consuming. Because the software upgrade was written to your disks, it could even require a restore of your original server. Depending on the type of upgrade you are performing, the process might even have upgraded the storage area, such as when upgrading NetWare 5.1 with Novell Storage Services (NSS) version 2 to NetWare 6.5. In such a case a restore could even mean restoring all your data if you decide to roll back to your starting point.
When you want to perform such an upgrade, it can be a good idea to perform the upgrade in a test environment first. And, of course, create a backup before you start the upgrade procedure.
Tip
Setting up a test environment can be very time-consuming. But with the use of imaging software, such as Storage Manager from Portlock Software, setting up a test environment is nothing more than copying servers from the production machine to a test machine. For a cluster you will need to copy all nodes, of course. Using VMware virtualization software with a Physical to Virtual migration method in this process can save you a lot of hardware resources, all depending on the amount of data you need to copy to your test environment and the number of nodes you need to run in the test environment. If sufficient resources are available, you can also rent the hardware needed to set up the test environment.
Something very important to check and test if you are going to upgrade existing hardware to be used with a newer operating system is support for network and storage adapters and other hardware used in your environment. Make sure that drivers are available and that you have them on hand when you start the upgrade.
Besides these practical pros and cons, there are also technical issues to keep in mind. First of all, an upgrade might not be supported at all. A NetWare server cannot be upgraded to an Open Enterprise Server running Linux with an in-place upgrade. Other technical limitations can be the available hardware resources in the server to be upgraded. Whereas a NetWare 5.1 server could run with 512MB of RAM without too many problems, for NetWare 6.5 this really is the minimum and rarely enough. Also, disk space can be a problem. You should check for simple things before upgrading. A server with a 100MB DOS partition just cannot be upgraded to NetWare 6.5 without first making more disk space available. The NetWare 6.5 pre-upgrade check, available from Deployment Manager, can help you with these preparatory checks.
With this approach to upgrading to a new cluster environment, the original servers remain intact for the largest part of the migration process. The new servers are installed into the network with the new operating system and software, and can be thoroughly tested. After the new servers are found to be okay, the migration process can be started to copy the data to the new environment and replace the servers in the eDirectory tree with the new ones.
This procedure is safer than an in-place upgrade process because for a large part of the procedure, the original servers remain intact. If something goes wrong, you can easily revert to the original scenario. Only when you have reached a certain point does it become harder to revert to the original scenario. When you’re using the NetWare Migration Wizard, this is when the source and destination server’s identities are swapped. When a problem occurs in that step, it can be a very complex process to restore to the original situation. But even in that scenario the data will always still be available on the old server. When you’re using the Server Consolidation Utility or when you’re performing a manual migration with your own procedures, there will still be a point where you have to switch to the new servers. But if you have performed the migration yourself, you will probably be able to return to the original environment much easier.
In a clustered environment using the NetWare Migration Wizard is not impossible, but we suggest not to use it for upgrading to NetWare 6.5. If an in-place upgrade is not possible and you want to build new servers and do not want to add them to the existing cluster or even tree, we suggest that you use the Server Consolidation Utility or perform the migration manually. If you are also setting up a new SAN, copying the data will be the process that is the most time-consuming. For other tasks that need to be performed, when you want to perform the migration yourself without the available utilities from Novell, there are tools available, such as TRUSTEE.NLM, that can be used to create a list of trustee assignments on the source server and deploy them on the destination server. For Linux there is an equivalent tool available called metamig, available on OES Linux servers in the /opt/novell/nss/sbin directory. Other tasks that need to be performed include pointing users to the new cluster with their home directories. For that there are also many tools available, such as Homes from www.hbware.com. But even that step can be performed with tools you already have, when you know how to use them, for example with an LDIF export and import to modify the attributes.
When your new cluster is an Open Enterprise Server Linux cluster, we suggest that you take the mixed-cluster route to migrate your servers. How to do that is explained later in this chapter, in the section “Upgrading a NetWare 6.5 Cluster to Open Enterprise Server Linux.” The main advantage of this method is that all your data on your NSS volumes remains intact, and trustee assignments and server references, including home directories, stay in place if they were originally pointing to the cluster.
This will work only when your current environment is a NetWare 6.5 cluster. If you have an older environment with NetWare 5.1 or later, data and trustees can be transferred to OES Linux using the Server Consolidation Utility, which is part of the Server Consolidation and Migration Toolkit.
In the event that you have a Windows environment that you want to migrate to an Open Enterprise Server environment with either NetWare or Linux, you can use the Server Consolidation Utility to migrate your Windows server to Open Enterprise Server NetWare or Linux. The destination server can be a standalone server or a cluster node.
In the previous two topics we have described how to upgrade or migrate in the existing environment. This means that you keep your existing eDirectory tree with everything in it, including trustee assignments and other specific information in your storage environment. We have worked at customer sites where the decision was made to build a new environment alongside the existing one, complete with a new eDirectory tree, and to move to this new environment by pulling the plug of the old servers and having users log in to the new environment.
Such an upgrade path brings a lot of manual labor, and you will need much expertise. User objects and other eDirectory objects, such as application objects, must be re-created, and in many cases this requires exporting existing information and importing it into the new environment.
The reason to start with such a project is very often that customers see problems in their environment that they expect to remain there after the upgrade. For example, there may be application objects that contain a snapshot of a Windows environment that distributes unwanted settings to destination computers.
It is our belief that in all situations it is possible to migrate to a new environment with the existing eDirectory tree using the utilities supported by Novell such as the Server Consolidation Utility. It only requires you to have the right expertise in the project team. For example, you would need an engineer with eDirectory knowledge to analyze the existing environment, perform health checks, and prepare the environment for the new operating systems. And maybe a ZENworks specialist who prepares applications to be used in the new environment by moving snapshot applications to MSI-based distributions.
The bottom line here is that customers are sometimes afraid to migrate garbage into more garbage. But when cleaning up during the process is done by experienced garbage men, the new environment can run bright and shiny.
In this section we explain the technical procedures needed to upgrade clusters for NetWareto-NetWare upgrades and for NetWare-to-Linux upgrades. In the last part of this section, you learn how you can also use the Novell Consolidation and Migration Toolkit to migrate NetWare and even Windows servers to NetWare and Open Enterprise Server Linux.
This in-place upgrade is the only one from this chapter in which the service to your end users will be interrupted for a longer time. Clusters that run with NetWare 5.1 servers that need to be upgraded to NetWare 6.5 cannot stay online while being upgraded. A direct upgrade to OES Linux is not supported. If you want to take that giant leap forward then NetWare 6.5 is a required intermediate step.
A NetWare 5.1 cluster must be prepared with Deployment Manager. The reason for this preparatory step lies mostly in the fact that the upgrade will also be an upgrade from NSS version 2 to version 3. File-system trustee rights are handled differently in the new version used since NetWare 6. The local NDS database object ID for objects is no longer used; it is replaced by the object’s Global Unique Identifier (GUID).
Note
Because file-system rights were stored in the file system with local object identifiers from the NDS/eDirectory database, the rights had to be modified when the volume was migrated to another server. The trustmig process took care of that. Because the rights are now stored by using the GUID, which is not server-centric, the trustees are the same on every server and the trustmig process has become obsolete.
Before upgrading the cluster, you must check whether you meet the system requirements for your upgrade to NetWare 6.5. Check the items in the following list to determine whether you are ready for the upgrade:
Check the hardware requirements of the server to see whether you have sufficient storage space and memory available. Also verify that your hardware is supported for NetWare 6.5—check whether drivers are available for all devices and so forth.
Verify that all applications you run on the servers are supported on NetWare 6.5. If they need to be upgraded, uncomment them in the cluster load script before you start the upgrade. After the cluster upgrade, when you have upgraded the applications to the new version, uncomment them again. Do not forget to check your backup software.
Make sure that you obtain licenses for all nodes. NetWare 6.5 comes with two nodes, so when upgrading a cluster with three nodes or more, make sure that you have the extra licenses at hand.
To prepare the cluster for an upgrade, perform the following steps. Be aware that the cluster will be stopped by this process. So it really is a preparatory step you take right before upgrading the servers to NetWare 6.5.
Note
It is important to use the Server Health Utility from Deployment Manager before even considering upgrading your cluster. You first want to verify whether the servers can successfully be upgraded before you perform these steps. You do not want to find out halfway through the server upgrade that not enough disk space is available, for example.
Here’s what you should do:
1. Log in to the NetWare 5.1 cluster.
2. Start Deployment Manager (NWDEPLOY.EXE) from the root of the NetWare 6.5 operating system CD-ROM.
3. From Deployment Manager, under the first menu named Network Preparation, select the option Prepare a Cluster for an Upgrade.
4. Click the link Prepare a Cluster. This will start the cluster installation program.
5. When prompted, enter the required information: name of the cluster object, tree name, and context where the cluster object is located. Click Next to continue the upgrade. All cluster nodes will now be contacted by the Cluster Services Installation application. You can watch their loading from the server console on each node.
6. When the process is finished, a message will be displayed that Novell Cluster Services has successfully pre-upgraded. The command to load cluster services (LDNCS.NCF) will now be commented out in the server startup file on every node, and a command to not activate NSS volumes will be added (NSS /AutoDeactivateVolume=ALL). These commands will need to stay there until after the servers are upgraded and will be updated automatically after the cluster upgrade.
At this point you must upgrade the cluster nodes to NetWare 6.5. Follow the directions from Novell’s documentation website at www.novell.com/documentation.
Tip
You will not be able to mount the NetWare 6.5 operating system CD-ROM as a volume because this NSS feature has been disabled because of the preparatory step you have just taken. (Traditional volumes, so also SYS, will remain operational.) You could start a remote upgrade, but you can also copy the contents of the OS and product CD-ROMs to a subdirectory on your SYS volume. From the GUI installation you can point to that location. A local upgrade is faster than a remote upgrade.
From the server’s graphical screen select Install from the main menu to start the upgrade. A list of currently installed products will be displayed. Select Add and point to the installation files to start the upgrade.
Alternatively, the upgrade can be started with the server up and running from Deployment Manager on a workstation. In the menu Install/Upgrade Options select Upgrade to NetWare 6.5. Select Upgrade a Server Remotely to start the server upgrade. This remote upgrade will be slower than an upgrade started from the server’s graphical environment.
After all the servers are upgraded to NetWare 6.5 and are up and running, you can continue with upgrading the Cluster Services software:
1. From Deployment Manager in the Post-Install Tasks menu, select the option Install/Upgrade Cluster. Click the link Install or Upgrade a Cluster to start the Cluster Services installation program.
2. In the Cluster Services Installation Wizard select Upgrade Software in Existing Cluster and click Next.
3. When prompted, enter the required information: name of the cluster object, tree name, and context where the cluster object is located. Click Next to continue the upgrade. All cluster nodes will now be contacted by the Cluster Services installation application. You can watch their loading from the server console on each node.
4. Provide a master IP address for the cluster. This is a new feature compared to the clustering version of NetWare 5.1. This IP address must be an available address in the same subnet as the cluster nodes and the existing cluster resources.
5. When prompted to automatically start the cluster software after the upgrade, select Yes or No. If you select No, you must manually start the cluster software on each node with the LDNCS command before going to the next step.
6. Start ConsoleOne to upgrade the cluster configuration. Browse to the cluster container object of the cluster you have just upgraded.
7. Right-click the object and from the Views menu select Cluster State View.
8. You will now be prompted as to whether you want to complete the cluster upgrade. This process takes only one or maybe just several seconds. It updates the cluster volume resources that were updated before the upgrade with several temporary commands that were needed to perform the volume upgrades and restore the trustees. These commands will be deleted by this process. Also, the NSS pools in eDirectory will be renamed to reflect the name of the new cluster servers. NSS pools are new to NetWare 6.x and did not exist in NetWare 5.1.
The cluster upgrade is now complete. Post-upgrade tasks include upgrading any applications that require an update to run on NetWare 6.5, including your backup software.
For an in-place upgrade of a NetWare 6 cluster to NetWare 6.5, two methods are available: upgrading the cluster while it is not available to end users and upgrading while the cluster remains available. Which upgrade method you choose is up to you. If you have the time to bring down the cluster and upgrade the servers during off-hours, that will probably be your choice. In many cases maintenance windows have become smaller, and for administrators who have a family life, the live upgrade scenario, also called rolling upgrade, will be very welcome.
Before upgrading the cluster, you must check whether you meet the system requirements for your upgrade to NetWare 6.5. Check the items in the following list to determine whether you are ready for the upgrade:
Check the hardware requirements of the server to see whether you have sufficient storage space and memory available. Also verify that your hardware is supported for NetWare 6.5—check whether drivers arevailable for all devices and so forth.
Verify that all applications you run on the servers are supported on NetWare 6.5. Do not forget to check your backup software.
Make sure that you obtain licenses for all nodes. NetWare 6.5 comes with two nodes, so when upgrading a cluster with three nodes or more, make sure that you have the extra licenses at hand.
This in-place upgrade requires only one preparatory step: installing the cluster licenses. If you are running a two-cluster node, no licenses are needed and the servers can be upgraded. With three nodes or more, first install the cluster licenses from iManager.
When the licenses are installed in the tree, upgrade the servers individually to NetWare 6.5. Before starting the upgrade of the first server, stop the cluster with the cluster down command. This prevents a scenario in which a server would come online with the new software while the old cluster is still running. That is part of the rolling cluster upgrade scenario and not what we started here.
Tip
It is a good idea to disable the command that starts the cluster (LDNCS.NCF) before upgrading. This helps in the way that you can first focus on a successful upgrade of all your servers to NetWare 6.5. Check whether everything runs as it should and that all drivers work okay, and then load NCS to check whether your cluster comes online successfully. Do not forget to enable the LDNCS.NCF load command again.
After the first server is upgraded and brought online, it will start the cluster services software. There are no updates that need to be performed to the file system or cluster resources such as with the NetWare 5.1 upgrade, so the cluster will be available immediately after the upgrade.
With this in-place upgrade scenario, the servers will be upgraded one at a time, leaving the cluster up and running during the upgrade. Services to the end user will be interrupted for a minimal amount of time. Effectively the cluster resources will be brought offline and online, which has the same effect as migrating a resource from node to another node. So it depends on your applications whether the users will notice the upgrade at all.
Tip
You can also perform the entire upgrade operation during normal operating hours and then perform only the last step during off-hours.
Before the upgrade is started, the cluster licenses for the NetWare 6.5 cluster must be installed. If you are running a two-cluster node, no licenses are needed and the servers can be upgraded. With three nodes or more, first install the cluster licenses from iManager.
When the licenses are installed in the tree, perform the upgrade of your servers through the following steps:
1. Start the upgrade of the first server you want to upgrade to NetWare 6.5. Migrate any resources that are running on this server to other nodes. You can let the process do this automatically for you, but you might want to choose manually where to run these resources. Also, this guarantees that it happens when you want it to happen.
2. The upgrade can now be started as a normal upgrade, described in the NetWare 6.5 online documentation at www.novell.com/documentation.
3. After the upgrade of the server is finished, let it reboot (twice) until the upgrade is finished. The Cluster Services software will be started automatically after the second reboot.
4. Resources can now be migrated back to this server. At this time you will have a cluster that contains nodes running Novell Cluster Services version 1.6 (form NetWare 6) and version 1.7 or 1.8. Up to NetWare 6.5 sp3 version 1.7 was used, and for NetWare 6.5 sp4 and Open Enterprise Server version 1.8 was used. This mixed cluster runs without limitations, but of course it should not be a permanent setup. Keep the cluster static in terms of configuration. It is also not possible to reconfigure the storage during the upgrade procedure.
5. Continue with the upgrade of all other nodes in the cluster by performing the steps through step 4.
After the upgrade of the last server, the cluster that is running as the master node will finish the upgrade process of the shared disk resources with the cluster upgrade command. You can watch this process start at the server’s logger screen. A message will be displayed from the Media Manager regarding upgrading the volumes (MM_Upgrade). When the cluster upgrade has finished, a cyan blue message will be displayed: Operational Mode 0. The upgrade will also be listed in the cluster Event log. From the online documentation, this is the description of what the upgrade process performs:
1. All cluster resources on shared pools are temporarily brought offline.
2. Media Manager software is called to upgrade disk media on one server. Disk media is then refreshed on all remaining servers in the cluster.
3. All cluster resources on shared storage are moved back to their original nodes.
4. The load scripts for each cluster resource run and each cluster resource is brought online.
The cluster upgrade is now complete. Post-upgrade tasks include upgrading any applications that require an update to run on NetWare 6.5, including your backup software.
The upgrade procedure described in this section will always be an upgrade to new servers and not an in-place upgrade. The difference from the first upgrade described in this chapter, migrating to a new cluster, is that in the scenario described here the cluster remains intact, the Linux nodes are attached to the same shared storage, and in most cases service to your end users will not be interrupted. The migration scenario requires you to build a new cluster and move your data and applications to the new cluster. The migration scenario is supported for all versions of NetWare and even Windows and can also be used to build a cluster with the data and applications from a standalone server. The upgrade described here is supported only for clusters running NetWare 6.5.
Tip
Starting with Open Enterprise Server Linux Support Pack 2, this procedure also works for NetWare 6.0 clusters.
The upgrade path that we will walk you through in this section is that of extending the NetWare cluster with Linux nodes, which creates a mixed cluster. We will then later remove the NetWare nodes, leaving you with a Linux-only cluster.
When you start with a NetWare cluster and add a Linux server, we call that cluster a mixed cluster. Such a cluster runs fine. The two operating systems can coexist, and cluster resources can be migrated from NetWare to Linux and vice versa. That sounds like a great solution for environments where some applications would perform better on NetWare and others on Linux. It gives you the flexibility to have some applications available on the entire cluster, such as user data, while other applications run only on specific NetWare or Linux nodes. Such a cluster, however, has some limitations that we explain here. After you’ve read them, we hope you agree with us that running a mixed cluster is not a permanent solution. These are the limitations:
After you’ve added a Linux node to a NetWare cluster, it is no longer possible to add new NetWare nodes. Only Linux nodes can be added.
In a mixed environment you cannot add storage to the cluster or modify the existing storage pools. There is a workaround to create storage on NetWare with the Linux servers turned off in which they will identify new storage after the upgrade, but that really is not practical for normal operation.
File-system trustee assignments are calculated for NSS access via NCP the first time a volume is migrated to Linux. On Linux trustees are stored in an XML file on the volume. When rights are modified on NetWare, the Linux server will not automatically detect these changes in its XML file and vice versa. (There is a command for that.) So moving storage around from operating system to operating system is not something to work with in a highly active productive environment.
Not all applications can seamlessly migrate from NetWare to Linux. They need to be modified to run on Linux and must stay there after the conversion. Examples are GroupWise and iFolder 2.
Cluster resource scripts will automatically be translated from NetWare commands to Linux commands. But if a resource is created on a Linux node in a mixed cluster, the resource will not run on a NetWare node.
From the preceding information you can decide for yourself whether you want to work with this. But we strongly advise you to work with this mixed-cluster scenario only for the time it takes to upgrade to Linux. During the time the cluster is in a mixed mode, we suggest that you keep the configuration static. It should be a period during which no new applications will be added to the cluster and a clear project is defined to migrate the environment to Linux servers.
The online documentation for Novell Cluster Services for Linux describes an upgrade path called a rolling upgrade. This approach is to remove a NetWare server from the existing cluster and remove it from the eDirectory environment and install Linux on the same hardware. The Open Enterprise Linux server is then added to the NetWare cluster, and this process is repeated until all cluster nodes are upgraded.
The technical approach we use in this section is identical to that procedure, except that we do not start with deleting NetWare nodes, we start with adding new Linux servers. Especially for smaller environments, this might be a better approach, depending on the hardware requirements for the new cluster environment. With only two or three nodes, the level of fault tolerance could fall below an acceptable limit.
If you do not plan to buy new server hardware for your cluster and the hardware being used to run NetWare can be used for running Linux, you could also perform a regular rolling upgrade. In that case you start by deleting a NetWare node first and then start with our first step: installing the first Open Enterprise Linux server into your cluster.
In both scenarios the cluster effectively remains available to your end users and service is not interrupted.
Before adding new cluster nodes to an existing NetWare cluster, you must meet the system requirements and perform some preparatory steps. All existing cluster nodes must be the same version of NetWare 6 or NetWare 6.5. The new Linux servers that will be added to the cluster must be fully configured and added to the tree. They also must have the software packages installed for Novell Storage Services and Novell Cluster Services. The installation of these components is discussed in detail in Chapter 4, “Installation and Configuration.”
Another requirement is that the new Linux nodes have access to the shared storage, either through the Storage Area Network (SAN) or via iSCSI. If the latter is the case, also make sure that all iSCSI connections are up and running before starting the cluster services configuration. How to configure iSCSI is described in Chapter 7, “iSCSI.”
Last but not least, it is important to have eDirectory replicas in place that are needed for the cluster node to work efficiently or, depending on the application, to work at all. More information about eDirectory design guidelines can be found in Chapter 3, “Clustering Design.” The simple rule is that cluster nodes must have local access to objects that they need in order to function, such as the user objects of those that access the cluster.
As we described before, it is also possible to first remove a NetWare node from the cluster and reuse that hardware for this first server. Whatever method you choose, the steps are the same, and we have decided to first add a Linux node to the cluster. This procedure is also described in Chapter 4, but we will give you the short walkthrough here. We expect that at this point the new cluster node is part of the tree, has NSS and NCS installed, and has access to the shared storage.
Perform the following steps to add the server to the cluster:
1. On the Linux server start YaST.
2. In the System category select Novell Cluster Services.
3. When prompted to also configure NSS, if you have not already done that previously on this server, select Yes to configure that component too. It is a mandatory component to be installed on an NCS cluster server.
4. When prompted, enter the credentials for the administrative user.
5. Enter the full distinguished name of the cluster where this node will be added.
6. The IP address of this node will be displayed. Typically, this will be the primary IP address, unless more than one interface is configured. Select the address from the subnet where the other cluster nodes are.
Note
You can reuse the IP address of a removed NetWare node, but in that case upgrade one node at a time.
7. Leave the check box to Start Clustering Service Now enabled and click Next.
The new node will now join the cluster. When the configuration is finished, the configuration utility will be closed automatically and you will be returned to YaST. Open a terminal window on the Linux server and execute the cluster view command (as root or other superuser) to check that the new node is online in the cluster. You can also execute the sbdutil -v command to check that the new node has been added to the cluster. This command is equivalent to the SBD VIEW ALL command on NetWare.
At this point you can either add new Linux nodes to the cluster or first remove one of your NetWare nodes. It depends on your upgrade scenario which order you choose, as long as you keep in mind that you need to provide fault tolerance and high availability to your end users.
There is no fully automatic procedure for removing a node from a cluster. It is as simple as deleting the cluster object after disabling the cluster software.
Although leaving the cluster would automatically migrate any resources to other nodes, we advise you to migrate the resources manually. This gives you the chance to run them on the node of your choice and to watch the process more closely, resource by resource, which is harder when everything happens automatically at the server. Perform the following steps to remove a node from the cluster:
1. On the NetWare server console, type cluster leave.
2. Execute ULDNCS to unload Novell Cluster Services.
3. In iManager open the eDirectory Administration task and select to delete an object. Browse to the cluster container and delete the cluster node object of this node.
Tip
If you have problems removing the object from iManager, log in to iMonitor for your server and click the iMonitor logo at the upper-left corner. In the configuration screen that appears you can now enable the advanced mode. Browse to the object in iMonitor, and in the left panel you’ll see an extra Advanced Menu option, which allows you to delete the object.
4. Remove the command that loads Cluster Services (LDNCS) from AUTOEXEC.NCF.
At this point you can decide what to do with this server. If you are reusing the hardware to install another Linux node on the same box, you can leave the server attached to the shared storage and start the Linux installation. Otherwise, if the server will be reused as a NetWare server in the same eDirectory environment, disconnect the server from the shared storage, and reboot the server.
You now can add other Linux nodes to the cluster or, when you have removed the last NetWare cluster node, go to the next section to finish the cluster upgrade.
When all NetWare nodes are removed from the cluster and only Linux nodes are left, it is time to clean up and convert the cluster to a real Linux-only cluster.
During the period that the cluster is in mixed mode, the resource load and unload scripts are stored in the directory /etc/opt/novell/ncs. When changes are mode to the resource scripts, these files are automatically updated. When all NetWare cluster nodes have been removed, the Linux load and unload scripts can be moved into the corresponding eDirectory objects.
To finalize the cluster upgrade, follow these steps:
1. Run cluster convert preview resource_name at the server console of one Linux cluster node. Replace resource_name with the name of a resource that you want preview. This will show you what modifications will be made to the resource scripts. The preview command can work only with individual resources.
2. Run cluster convert commit at the server console of one Linux cluster node to finalize the conversion. This will convert all resources in the cluster.
The cluster container now contains only one legacy set of objects: the NetWare cluster resource template objects. When you’re installing a new Linux cluster, these templates would have been generated for you, but when you’re adding Linux nodes to a NetWare cluster, the old templates remain intact.
You can create the Linux-specific cluster resource templates by executing the following command on one of your Linux nodes:
/opt/novell/ncs/bin/ncs-configd.py -install_templates
In addition to generating Linux cluster resource templates, this command deletes all NetWare cluster resource templates. Because of this, use this command only after all nodes in the former NetWare cluster are converted to Linux.
Now that the entire cluster is upgraded, all applications can be upgraded to run in the new Linux environment.
All upgrade methods explained to this point were in-place upgrades and the mixed-mode upgrade in which data also remained in place in eDirectory (cluster configuration) and on the file system (files and rights). Sometimes it is not possible or wanted to perform an in-place upgrade. In those cases there is always the possibility to use a migration method to move your environment to new servers and to a new cluster.
The methods available for migrating servers to a cluster are not much different from those for migrating a single server. There are a few extra steps in a clustered environment that we will discuss with each available method.
Starting with Open Enterprise Server, Novell has bundled two migration utilities into one toolkit. The first utility already existed as the Migration Wizard, and the other one is called the Server Consolidation Utility. The first one is not really usable in a clustered environment. It can be used to upgrade the hardware of a server with which the server on the new hardware keeps the same identity throughout the entire eDirectory environment.
Note
The Migration Wizard replaces one server with another server, whereas the Server Consolidation Utility replaces one or more source servers with one or more destination servers.
Tip
Both utilities are available for all versions of NetWare and can also be used for servers that are of the same version, such as NetWare 6.5 to NetWare 6.5. The toolkit also supports migrations from Windows to NetWare and OES Linux.
This is important for security components, user home directories, and so forth that point to an NCP server object. And there are server applications and maybe scripts or other control files that point to that specific server. All of this is not an issue with a cluster because in general these configurations will point to a cluster virtual server. So to upgrade a server to new hardware, it is simple to remove the old server from the cluster and install the new server into the cluster as a cluster node. You probably want to do it in that order because of cluster licenses that allow only a maximum number of nodes in your cluster.
There can, however, also be scenarios in which you want to replace an entire cluster. Or when you want to consolidate existing servers into a cluster. Performing such a migration is not as simple as just copying the data. In a networking environment there are at least the following configuration items that also need to be copied or modified:
File-system rights
Disk and directory quotas
User home directories
Login scripts, batch files, and such
Application references, including UNC paths
The utilities that Novell delivers for migrations do not offer support for all of these configurations to be copied or changed. The Migration Wizard is the most complete because it places the new server in the identity of the old one, which keeps all server references and items named in the preceding list intact. But there is also the Server Consolidation Utility, which does not take care of everything. This utility merely copies the data from one server to another server, including the file-system rights. If you are moving data from one tree to another tree, it is also possible to copy the user objects to the new tree. There could be some objects that still would not be copied, such as ZENworks application objects and their user references.
The Server Consolidation Utility is part of the Novell Server Consolidation and Migration Toolkit. The software is located on the NetWare operating system CD-ROM (SCMT.EXE in the /products/Migration_Utilities directory). The utility runs from a Windows workstation.
It is not a topic of this book to explain how this utility works in detail. And for the most part the software is self-explanatory. As you can see in Figure 10.1, there are two panels that show the source and destination. Dragging data from the source to the destination volumes will structure the new environment. When the preparations are finished, a verification can be run, and when everything is guaranteed to work as planned, the actual data copy can be started.
The process of copying data from one server to another server is the same for standalone servers as for cluster servers. In a clustered environment you drag and drop the files to or from the cluster virtual server and its volumes.
Tip
When migrating to an OES Linux cluster, the source server might not be able to connect to the Storage Management Data Requester (SMDR) on the target server if that server is a cluster node. The project verification process will generate an error message if this problem occurs. In that case restart the SMDR daemon so that it loads the configuration of the virtual server and its resources. Execute this command to restart the daemon: /etc/init.d/novell-smdrd restart.
There are still a few items in your environment that will not be copied to the new servers, whether standalone or in a cluster—for example, user home directories that are not updated. The next section describes how simple tools can be used to update all necessary objects.
Copying the data and file-system rights from one server to another is one thing; updating any references in your environment that may still point to your old server to the new server is a completely different thing.
First of all, it is important to understand how these server references work. Your NetWare or OES Linux server is represented in eDirectory by an NCP server object. Other objects will contain attributes that point to that server object. Those attributes, also called properties, are not simple text fields that contain the server name; they are attributes of the type Distinguished Name that reference the actual object, regardless of its name. Because of this, when you rename a server all these references will automatically point to that renamed object. When you have an old server in your tree that is called FS1 and a new server called FS2, deleting FS1 and renaming FS2 will not update all references to server FS1. At the moment object FS1 is deleted, all references are lost. It is therefore very important to always update all references from the old server to the new server and only if all steps are completed to delete the old server from the tree.
A simple example of how server references can be updated to a new server is that of the Default Server property of users. Changing that to a new value is simple.
1. Go into ConsoleOne or iManager and perform an advanced search for all users with the given Default Server property.
2. In the results window, select all objects and choose Properties on Multiple Objects from the File menu.
3. Next, select the new Default Server property for these users and click OK to apply this setting to all the users who had the old server as their default server.
All objects that pointed to the old server will now point to the new server.
For user home directories it is not as simple as this. One reason is that it is a unique value for each user. They all have a common part, the server volume, but also a personal part, the actual directory. When data and users are being copied to another tree with the Server Consolidation Utility, a template object can be used to set the home directory attribute in the new tree. But when the server and data stay in the same tree, nothing will be updated.
User home directories can be modified to point to a new location in several ways. There are third-party tools available for purchase that can help you with the most complex scenarios for user home directories. But also with some simple tools you already have, much is possible.
Tip
There is a great product available from Novell called File System Factory. It allows for policybased management of home directories. When you have to move users on a regular basis, such as in case of a school at the start of each semester, this tool will make your job easier. More information can be found at www.novell.com/products/filesystemfactory.
One of the methods you can use to change the Home Directory attribute is to export it via LDAP and, after making the necessary modifications in the export file, import the information again. Creating an LDAP export can be done via the Import Conversion and Export (ICE) Wizard in ConsoleOne and iManager. There is also an ICE command-line executable available for NetWare, Windows, and Linux. Because of that platform-independent availability and the enormous flexibility of the command-line tools, we will show you the command that exports the information from an LDAP server. ICE can be found in the ConsoleOne directory under the bin directory.
The following command should be entered on one line (the arrows are simply code continuation characters):
ice -S LDAP -s 10.0.0.1 -p 636 -d cn=admin,o=oes -w novell -F (objectclass=user)
-a ndsHomeDirectory -b o=OES -L f:public
ootcert.der -D LDIF -f c: empuserhomedir.ldif
This command exports the information from the server at IP address 10.0.0.1 via secure port 636 by using the certificate in f:public
ootcert.der. The export function is performed as user Admin in the OES container, using the password novell. Only user objects are searched, -F (objectclass=user), and the search is performed, starting at the base of DA (-b o=OES). The only attribute that is exported is ndsHomeDirectory. The -S LDAP parameter tells the command that the operation uses LDAP as a source, and -D LDIF tells the command to use LDIF as the destination. In this case, it is writing the information to c: empuserhomedir.ldif.
The result of the LDIF operation should look like the following:
version: 1
dn: cn=Rob,o=OES
changetype: add
ndsHomeDirectory: cn=SRV1_DATA,ou=SRV1,o=OES#0#UsersRob
You can use your own favorite tool to modify the LDIF file. For a not-too-complex modification, you can even use a simple text editor and use the replace function to change the server name. However, if your modification is more complex, such as adding a directory path to every user’s setting, an editor that supports using macros is probably a better choice. Or use the powerful Linux commands in combination with regular expressions to modify the file.
The modified file, which imports the new home directory location into eDirectory, should look like the following:
version: 1
dn: cn=Rob,o=OES
changetype: modify
replace: ndsHomeDirectory
ndsHomeDirectory: cn=SRV2_DATA,ou=SRV2,o=OES#0#UsersRob
In this scenario the users are being moved from server SRV1 to server SRV2. The references to the volume on the source server have been modified to point to the destination server.
The import command for this new LDIF file is the following:
ice -S LDIF -f c: empuserhomedir.ldif -D LDAP -s 192.168.1.101 -p 636 -d cn=admin,o=OES -w novell -L D:public
ootcert.der
The command is constructed in the same way as the export command, except that we now use LDIF as the source and LDAP as the destination. In addition, we do not have to specify any search parameters because the full distinguished names are in the LDIF file.
Note
Before modifying the home directories, make sure that the files and trustees are also in place. Otherwise, your users will experience problems during the login process.
User home directories are a very common configuration item in many NetWare environments. That is the reason we described how to modify them in depth. There could be many more items that need to be modified, ranging from login scripts and batch files to ZENworks application objects that may contain UNC paths. If there are any other objects in eDirectory that contain a reference to the old server, there is a chance you can find them with the following export command:
ice -S LDAP -s 10.0.0.1 -p 636 -d cn=admin,o=oes -w novell -F (objectclass=*) -a * -b o=OES -L f:public
ootcert.der -D LDIF -f c: empallobjects.ldif
If you search the exported file for the old server name, you might find all entries that still point to that server. There is no guarantee that you will find all references because some attributes are not exported though LDAP, such as login scripts.