Novell Home

 

When it comes to discovering the key to a successful migration, it's not likely that experts in the IT realm will turn to the 19th Century children's classic, Alice in Wonderland. Regardless of how unlikely, that migration key reveals itself on the story's pages when a confused and lost Alice asks the Cheshire cat for directions. The cat responds, "That depends a good deal on where you want to get to." When Alice says she doesn't really care where she goes, the mischievous cat answers, "Then it doesn't matter which way you go."

Although Novell Senior Product Manager, Jason Williams, never once referenced the children's story in his BrainShare presentation on migrating from NetWare to Novell Open Enterprise Server 2 on Linux, he certainly echoed the Cheshire cat's words when emphatically declaring, "The key to a successful migration is to know where you are and where you want to go. In other words, before you start, you have to actually plan your migration." Some of the issues influencing your destination—issues Williams recommends you consider when planning a NetWare to Novell Open Enterprise Server migration—include:

  • Migration or Consolidation
  • Physical to Physical or Physical to Virtual
  • Directory Concerns
  • Clustering
  • Linux Considerations
  • Migration Tools.

> Migration or Consolidation
When planning a move to Novell Open Enterprise Server 2, are you upgrading, migrating, consolidating or doing a combination of all three? Part of this question deals with the additional questions, "Is your destination NetWare or Linux?" and "Are you moving from an older version of NetWare or the original Novell Open Enterprise Server?" Whether you're moving from NetWare to NetWare, Linux to Linux or NetWare to Linux, this might be a good time to consider taking advantage of today's more powerful hardware platforms and doing some server consolidation. This is especially true if you're moving from NetWare to Linux, as an inplace upgrade from NetWare to Linux is not supported.

Keep in mind that server consolidations require significantly more planning than basic one-to-one migrations. But in spite of the additional planning requirements, server consolidation pays off in lower hardware costs, as well as lower cooling, power consumption and rack space costs. To illustrate this savings, Williams indicated in his presentation that Novell recently consolidated 14 older file and print servers down to two new servers.

If you do consolidate, you need to consider whether you'll keep your services in their original tree or move them to a new tree. It'll take some planning to determine how to move user objects from one tree to another. One method that Williams suggested is to set up a Novell Identity Manager connection between your old tree and your new one. This will let you easily synchronize your user objects to the new tree. Doing so also presents an opportunity for you to redo the layout of your tree structure. Identity Manager will allow you to remap the location of all user objects in your new tree. As part of this process, you'll probably also want to get rid of any old user objects that are no longer being used.

Also, if you have multiple volumes that you want to consolidate to a single directory structure, it might be a good idea to take a look at using DFS junctions, which let you split and move your Novell Storage Services volumes. DFS also lets you create a single virtual directory view of multiple volumes to help you organize them the way you want. (see figure 1.) From within that virtual directory view, you can map drives to single volumes and then traverse your multiple volumes across the directory structure.

Of course, if you are planning on doing server consolidation as part of your migration efforts, you'll also need to decide if that consolidation will be from physical servers to physical servers, or physical servers to virtual servers.

> Physical to Physical, Physical to Virtual
Migration planning is a perfect time to examine the benefits of virtualization. Novell Open Enterprise Server supports both Xen and VMware virtualization, but each solution has a different set of requirements. You'll want to evaluate these requirements to see how each might affect your migration plans and your overall network infrastructure.

When virtualization becomes part of your migration planning, Williams recommends taking a close look at the types of workloads being carried out by the different servers you plan to consolidate. Server workload is key to determining the placement of your virtual machines. If you load up a single physical server with multiple virtual machines that are all extremely disk-intensive, you might use up the entire bandwidth of your disk array, or you could run into contention problems if the virtual machines use the same fibre channel or iSCSI array. Likewise, you might not want to stack on the same physical machine multiple virtual servers that are all very CPU-intensive. When leveraging virtualization for server consolidation, awareness of your server workloads can prevent you from overloading your box with multiple servers of the same type and potentially running out of CPU, memory or disk bandwidth.

The key to a successful migration is to know where you are and where you want to go.

If you employ clustering, you can also use virtualization as part of this effort. For example, if you have an eight-node cluster, you might want to consider running three or four of those nodes as virtual cluster nodes. This can reduce power and physical space requirements, while still providing a level of high availability for your services. But don't even think about following the example of the guy that, as Williams quipped, said, "Wow, that's great. I can put all my cluster nodes on a single machine." While that can be done, it's obviously not a very bright idea.

As mentioned before, you can choose to go with Xen or VMware, but one of the benefits of Xen is that it's included with Novell Open Enterprise Server 2 as part of SUSE Linux Enterprise Server 10. Also, by going with Xen, whether you're running Linux or NetWare virtual machines, it can detect that they're virtual servers and then load them in paravirtualized mode to take full advantage of the AMD V and Intel VT chips for increased performance. You should also be aware that Novell does not support NetWare in full virtualization mode in Xen.

> Supporting Team Members
Directory Concerns
Directory services are an often-overlooked aspect of migration. When it comes to the directory, planning is once again critical to migration success. Before executing any migration or rollout, Williams recommends carrying out the following best-practice steps for your directory:

  • Understand the replication layout of your directory (for example, replica rings and partition structure).
  • Execute a directory health check before doing anything.
  • If directory expansion is planned, consider re-engineering your directory as part of the migration.
  • Determine what eDirectory version best fits your needs.

Before you migrate, you need to understand the replication layout of your directory and how you want it to look when you're done. Where are your replica rings located? What servers actually have partitions on them? Also, you need to know where you want your replication rings and partitions to be after you finish your migration, so you can design your network topology accordingly. If you fail to plan properly in this area, you can count on running into network replication problems.

 

In his BrainShare presentation, Williams pleaded with attendees, "Please, please, please, execute a directory health check before you do anything!" He went on to say how amazing it is that so many people doing a migration or consolidation call Novell, saying they can't get a new service to install or work, only to learn they had servers that hadn't been in contact with the directory tree for several months. As a result, the tree didn't migrate or a number of objects never properly synchronized. These problems, and many more, can be avoided by performing a simple health check of the directory before migrating. Williams also recommends setting up a master timeserver to make sure your entire directory tree has its time synchronized accurately.

If your directory is likely to expand in the future, a migration might be the ideal time to re-engineer your tree to accommodate that expansion. Maybe you want to create a flat tree structure so that LDAP can walk your tree more efficiently to find a user object. Novell Identity Manager can aid in this re-engineering effort, allowing you to synchronize your user objects to your new tree. If you plan to do this, it's a good idea to first create your new tree in a lab to make sure you understand its structure and that it's actually going to work the way you want it to before you put it into production.

In his BrainShare presentation, Williams pleaded with attendees, "Please, please, please, execute a directory health check before you do anything!"

Your migration planning effort must also include determining what Novell eDirectory version you will use. There are valid cases for both eDirectory 8.7 and eDirectory 8.8. You might already have version 8.7 in your organization and you might be comfortable with it. It's been in the market for about three years, and it also ships as part of Novell Open Enterprise Server 1. It's not a problem if you decide to stay with version 8.7, but there are some advantages to moving to eDirectory 8.8.

First of all, eDirectory 8.8 has enhanced features and scalability. It supports newer advances in Novell Identity Manager and Novell Access Manager. Also, if you're planning on taking advantage of the new Domain Services for Windows in Novell Open Enterprise Server 2, you'll need to deploy eDirectory 8.8 somewhere in your organization. This service enables Linux servers to integrate with Active Directory so your users can authenticate from Windows to Linux servers without the need for a Novell client on the desktop.

> Clustering
If clusters are part of your plan, how will your cluster environment impact your migration efforts? To begin with, Williams says, you need to understand the primary role of your cluster. Is it for GroupWise high availability? File and print services? Directory services? If you have one large cluster for all of these services, you might want to consider splitting your cluster into multiple smaller clusters. This could mean a six-node cluster for GroupWise, another six-node cluster for file and print, and finally a six-node cluster for directory services. By separating your clusters this way, problems in one service cluster won't spill over and potentially affect your other clustered services.

Splitting your clusters like this can also simplify administration efforts, since you can independently manage each cluster. Also, if you need to do a cluster update, a rolling upgrade of a six-node cluster is much easier than a rolling upgrade of a 32-node cluster.

Whether you're moving from NetWare to NetWare, Linux to Linux, or NetWare to Linux, this might be a good time to consider taking advantage of today's more powerful hardware platforms and doing some server consolidation.

If you plan to implement Novell Business Continuity Clustering to allow automated management of site-to-site failovers, how will this affect your migration efforts? What will be the impact on your network topology? Business Continuity Clustering allows you to define which of your resources are considered "vital" so only those services move to an off-site location rather than the entire cluster.

You also need to decide what clustering technology you'll be using. In a NetWare environment, you'll likely use Novell Cluster Services. On the Linux side, you can choose between Heartbeat 2 or Novell Cluster Services. Novell Cluster Services is typically the preferred choice due to its richer failover services. Also, if you plan to implement Business Continuity Clustering, you will need to use Novell Cluster Services.

> Linux Considerations
When migrating to Linux in your Novell Open Enterprise Server environment, you have to decide what file system you want to use. You have a choice of Novell Storage Services, ReiserFS and ext3. According to Williams, there isn't one right answer. In fact, it might make sense to have different servers using different file systems depending on those servers' primary roles. Of course if you are already running NetWare, you'll already have a lot of Novell Storage Services volumes. If you want to preserve all the rights, metadata and trustee information associated with the data on those volumes, it makes sense to stick with Novell Storage Services.

Also, if your volumes are already in a SAN environment with Novell Storage Services, migrating to a SAN environment that uses Novell Storage Services on Linux will be extremely easy. Using DFS junctions also requires Novell Storage Services to support volume moves and splits. And if business continuity clusters are in your plans, you might find them easier to implement if you're using Novell Storage Services.

Cases can be made for using ext3 or ReiserFS as well. ReiserFS is optimized for small files and performance. In fact, both Novell IS&T and the GroupWise engineering team recommend using ReiserFS for GroupWise servers, primarily due to performance increases and the fact that GroupWise doesn't utilize the advanced features of Novell Storage Services. The performance levels for ext3 are similar to that of ReiserFS.

Dynamic Storage Technology, formerly known as shadow volumes, works with Novell Storage Services, ReiserFS and ext3; however, be aware that it cannot move data from a Novell Storages Service volume to an ext3 or ReiserFS volume, or vice versa.

> Know Where You Want to Go
Other migration advice provided during Williams' BrainShare presentation on migrating from NetWare to Novell Open Enterprise Server on Linux included:

  • Understand what your target server will be used for and then only install the actual packages required to do its job.
  • Take advantage of AutoYaST to speed up your rollouts.
  • Familiarize yourself with the different migration tools and resources available from Novell (See Novell Open Enterprise Server Migration Tools).

But once again, the most important migration counsel echoed that old wisecracking, smiling cat, "Before you do anything, know where you are and where you want to go."

Novell Open Enterprise Server Migration Tools

For Novell Open Enterprise Server 2, Novell has taken a different approach to providing migration tools. Instead of creating one large migration toolkit, you'll be able to use individual programs for each major service you might want to migrate. (see figure 2.) This enables you to not only migrate a single service at a time (the method preferred by most customers), but it allowed Novell engineering to develop better migration tools since each tool focuses on doing one thing extremely well.

For more information on the migration tools and resources currently available from Novell, visit novell.com/oesmigration. This migration Web site, debuted at BrainShare in March, provides dynamic access to content from the Novell Open Enterprise Server Migration Support Forum and Cool Solutions Community, as well as collateral, documentation, articles, Web links, third-party resources and more. It also provides access to a community of users for the purpose of sharing migration best practices.


© 2014 Novell