Walking the OS Migration Tightrope
Some steps and rules to keep in mind to prevent OS migration
from being a major headache. by Graeme K. Le Roux
Changing the operating system of the servers on your network is not something
you do without much planning.
In most cases you'll only do it if there's an overriding cost benefit, a business
requirement to deploy a new application environment which is not supported under
your existing OS, or you need to merge two dissimilar IT operations. Whatever
the reasons, there are a few constants in the OS migration process.
Firstly, you need to be very sure that the OS you're migrating to will actually
do the job.
This sounds obvious, but it is not.
If, for example, you have a particular application which is written for a database
engine that runs under both your current OS and the one you're migrating to,
you cannot assume that every function which exists in one OS exists in the other,
or that the functions which exist in both OSs work the same way on both of them.
The only way to be certain that all your applications will work under the new
OS is to test them. You do this by buying or renting a suitable platform, installing
your application environment, taking a copy of some or all your live data and
then running a series of tests to simulate your normal operations. You will
also need to test out your procedures for dealing with abnormal situations,
such as disaster recovery procedures, etc.
The next problem is working out the mechanics of migrating your data files.
If your data files are on a storage volume which is in an OS-specific format,
then you have to move them off that volume so that you can reformat it for the
new OS. After which you have to put the data back, which can be more of a problem
than you think.
This is because you have to consider how quickly you can move your data. Chances
are you will have a weekend to do the job at most, and you will still have to
do your normal end-of-day/week processing. Then there is the question of what
you move the data totape can have an OS-specific format, SANs based on
iSCSI or fiber channel may or may not need to be reformatted.
The simplest solution is often to use an OS independent NAS solution. If your
file formats are the same under both your source and target OSs, you can simply
copy your data to the NAS volume, reformat your servers/hosts and restore your
data. In fact, you may want to consider using NAS as your primary data store,
as an online backup, or both.
Once you have figured out the mechanics of migrating your data, you have to
work out the corresponding process for your application filesall the queries,
reports, and other server-based processes that you have written in-house or
had written for you.
Fortunately, the solution you used for your data files should work for your
application files as well. The application enginese.g. database engineswill
have to be replaced with the versions appropriate to the new OS.
When you have ascertained that the proposed migration will work and the mechanics
of moving your data and applications, you need to work out who the migration
will affect, how it will affect them and how you can prepare them for the changes
they will face.
After you have changed your system's OS, you will have to re-train your operations
personnel to work with the new OS.
However, the best training course in the world will not provide the sort of
experience you want in your senior operations personnel, especially when you
are doing something as complicated as an OS migration.
You will need to bring in contractors, who will be able to help test your applications
under the new OS, to provide extra manpower during the migration, and to act
as mentors/support to your re-trained operations staff, usually for a year.
This is not going to be cheap, but it is necessary.
Whenever possible, you should confine the effects of migrating from one OS to
another to the glass house rather than risking the effects of extending it to
your general user population. This is because the process is easier to control
in the glass house and it costs less.
It is also a good idea to use some volunteers during your testing process. This
will give you a good idea of what the practical effects of the migration will
be on your general user population, and thus what the effects will cost in terms
of required user training, extra support resources and lost productivity. Remember
to provide for the unexpected in your project budget too.
Unix and Windows Clients
One of the more difficult issues associated with mixing OSs in a single system
is dealing with Windows clients.
In fact, this problem has spawned an industry that supplied add-on software
to make Windows interact intelligently with Unix hosts, starting with basic
TCP/IP and telnet implementations and even including NFS and RPC add-ins.
Few of these add-on products exist today because both Windows and Unixespecially
Linuxhave evolved to be more compatible with each other. Windows defaults
to installing a TCP/IP suite and comes with a Java capable browser. Samba provides
SMB/ CIFS support on most Unix platforms. Windows supports FTP out of the box,
and both Windows and Unix platforms can use each other's printers.
Add-ons are still required, when you want to have a Windows server support Unix
clients, since Windows tends to assume that Unix is a legacy platform and that
all clients in a network will be Windows platforms.
Making Migration Easier
Even if you are not planning an OS migration soon, you can make any future OS
migration somewhat less of a drama by keeping a few simple design rules in mind
whenever you upgrade or expand (or shrink) your network:
* Keep your network transmission system simple. Use fiber for vertical (or
long) runs, single drop copper for horizontal runs and switches whenever you
have to join the two. If you use quality copper and fiber, this will allow you
to add new services without having to adjust server or client configurations
to account for wild variations in latency and available bandwidth. This approach
allows you to upgrade the QoS of particular paths in the network as required,
and segment groups of ports from your switches. This means that you don't have
to move a complex network configuration to your new OS platform.
* Standardize on the TCP/IP protocol suite. All OS platforms support TCP/IP
protocols and basic applications such as DNS and DHCP. Making sure that your
new OS platform supports your existing network protocols will obviously makes
migration a lot easier.
* Try to use standard Internet applications such as DNS, DHCP, SMTP, Web servers
and clients wherever possible, rather than proprietary equivalents. You can
be certain that any new OS will support existing standard services, but the
same can't be said for proprietary services.
* Wherever possible, separate data storage and backup from data processing.
For example, store files in a NAS box which is OS and client independent rather
than on a specific type of server which may or may not support any new OS platform.
Then when you migrate your application environment to a new OS platform you
should not have to worry about moving data.
* Try to limit the number of different processing platforms in your network.
If you have databases for example, try to use just one type of database engine
running on one type of OS. This cuts your testing and support costs, since if
you are mixing five different SQL engines in your network you have to test all
of them in the new environment or port code and data from all of them to any
new environment. This is a much more expensive task than testing a new version
of an SQL engine you are already using.
All these rules can be summed up as keeping your system simple, and can help
prevent any IT project from turning into a nightmare.
This article first appeared in Network Computing Asia
|* Operating systems in general:
see relevant vendors' Websites
* Linux: www.tldp.org
The Linux Documentation
* SANs: www.snia.org
The Storage Network Industry
Unix and Windows
WRQ's Reflections X and
Suite for X.
Look under "Connectivity"
in the products area.
Samba is an SMB/CIFS file
system implementation for a few versions of Unix/Linux.
Search under Mad Hatter.