|< Day Day Up >|| |
If you upgrade from Domino R4 or R5, then we recommend that you read the designated IBM Redbooks, such as Upgrading to Lotus Notes and Domino 6, SG24-6889, concerning upgrading to Domino 6. In addition, we highlight some important points for your upgrade project in the following sections.
Figure 14-1 on page 325 shows our recommended upgrade strategy. Begin with the administration clients, then check all your customized templates, and upgrade your Domino Directory. Next you should upgrade the administration and hub servers. When all those servers are stable, you can upgrade your remaining servers. Finally, upgrade the Notes clients.
Figure 14-1: Upgrade strategy to migrate to Domino 6
If you start from Domino 6.0.x, there should not be much to do. We suggest that you test your business-critical applications and your customized Lotus standard templates, such as pubnames.ntf. After successful testing, you can apply the new Domino 6.5.x version to your servers.
We strongly recommend that you do not change or customize any of the standard templates!
In general, all non-customized standard Lotus templates will work. That means you can just upgrade these databases to the new design. Also, your applications that only use "standard" LotusScript and @functions will work. However, you should be aware that the implementation or behavior of Lotus connectors such as LSX and DECS, or the use of the C/C++ toolkit, may be different from earlier Domino releases.
In addition to upgrading the Domino version, you also need to plan for a platform change. The easiest case is when you come from another UNIX flavor. Migrating from a Windows platform is slightly different from that. We discuss both scenarios in the next sections.
As mentioned before, it is very easy to migrate from one UNIX platform to another. You do not have to worry about code pages, case sensitivity, and new filesystems. For most of your Domino servers and databases, a simple transfer to the new platform should be sufficient. But before planning or doing a migration, verify that the prerequisites of your own applications are met by the desired platform. Not all Lotus products or third party products that your applications require might be available.
There is one exception to this. When migrating from Domino on zSeries from z/OS to Linux, there are changes to the way the filesystem is set up (DASD instead of HFS or zFS datasets), and of course the character set is a different one for z/OS and Linux (EBCDIC vs. ASCII).
Changing from a Windows platform to Linux is slightly more complicated than changing from UNIX to Linux. We discuss the high level issues here, and offer more detailed information in 4.3, "Brief introduction to Linux and UNIX filesystem" on page 53.
In Windows, filenames are not case sensitive—but in UNIX, they are. If your scripts call for the file log.nsf and the file is listed as LOG.NSF at the operating system level, the file will not be found when the script runs. We recommend that you name every file only using lower case. In this way it will be easier to find misspelled filenames.
The backslash (\) character, used to separate directories under windows, is not present in UNIX. Just as with Web addresses, use the forward slash (/) between directories.
In the Domino Directory, the Domino server uses the backslash \ for path names, and converts it when accessing the UNIX filesystem. However, it may be a good idea to use the forward slash / wherever possible. This automatic translation does not work for scripts, agents, and so on (so make sure they use the correct delimiter). But it does work for the Notes client, so the user can still use the backslash \, such as in the open database dialog.
Be aware of differences in code pages for Wintel and Linux. Linux is an ASCII-based operating system, so there normally is no need for a special code page translation, such as that required for exchange text files between z/OS and the rest of the world.
However, in some cases Windows and Linux may have different interpretations of special characters, so you should double-check critical files to make sure they look and work the way you want them to. Those differences do not affect text in normal Notes databases, but they might cause problems in detached files on the operating system level, as well as interpretations for Web sites (http task).
Chapter 4, "Disk configuration" on page 49, contains a detailed explanation of how to design the filesystem and mountpoints for Domino for Linux on zSeries. In this section, we offer a just a brief summary of tips and methods.
We recommend that you spread the databases equally over the data directories and servers. "Equally" in this context means trying to balance your database distribution in terms of size, grow rate, IO activity, workload, and other factors.
First - plan your new Domino infrastructure. And remember to plan for servers for testing and application development.
There are two scenarios for migrating your Domino infrastructure to Domino on Linux for zSeries:
Scenario 1 - with server consolidation (fewer Domino servers on Linux for zSeries)
Scenario 2 - without server consolidation (the same number of Domino servers as before)
In the following discussion we focus on scenario 1, because scenario 2 can be treated as a special case of scenario 1 with one exception: you can take the IP address and the server ID from your old server and move it to the new server (this way you do not have to worry about informing your users or the Notes client about a new server). Which scenario you choose depends mainly on your existing Domino infrastructure.
When you plan your new environment, it is a good time to rethink the way you use your Domino servers. We recommend that you separate your servers by function.
For example, have a dedicated server for Notes mail, for POP3 and SMTP mail, for Notes applications, for Web applications, and one admin server, as shown in Figure 14-2 on page 327. If possible, do not mix these kinds of workloads on one Domino server; it is easier to solve problems, maintain updates, and tune and administer servers that have dedicated workloads than servers with a mixed workload.
Figure 14-2: Ideal Domino Domain
Migrating from one Domino platform to another means moving a great deal of data. Most of this data will be contained in Domino databases. So the obvious method is to use replication as the preferred transport mechanism. A special sort of replication that can be very useful for migration is provided by a Domino cluster. But FTP is also a good, standardized, reliable data transportation method. In this section we discuss the pros and cons of both methods, and help you to decide when to use which method.
When using replication as a transport mechanism between your old and new Domino servers, you have to prepare some things before you can start. You have also decide whether you want to use the normal replication, or whether you want to set up a cluster for the migration and data transfer process. Here we list some of the tasks you have to perform in setting up the replication, and also mention special items for clustering.
First, you have to create the replica stubs on the new server for all the databases you want to move. Next, you should create a connection document pointing from your old Domino server to your new Domino server. Enable the replication and check the Domino log for possible replication errors. Finally, inform the users and their Notes clients about the new database location.
Here are some of the difficulties you might experience when using replication:
Private folders and views in databases will not replicate.
Some field settings for documents (author, reader fields, ...) can prevent the Domino server from replicating these documents.
ACL and replication settings for databases configured by a user may also prohibit the server from replicating.
If local encryption is enabled for a specific user ID, the server is not able to read, and therefore replicate, the database.
Keep these points in mind when using cluster replication:
Make sure that the "Server to run on" property in any agents is changed to the "new" server before you shut down the old one.
Are your applications cluster-enabled? What happens to data on non-cluster-enabled databases when clustered?
If your source server is overloaded, it may not be able to handle the additional workload generated by the cluster.
The maximum recommended number for servers in a cluster is six. Attempting to consolidate more than five "other" servers at one time onto your zSeries server can cause problems.
The great benefit of using clustering is that you do not have to worry about informing your users or their clients about the new server; that is automatically taken care by the cluster process. As a result, migrating is simple: as soon as the cluster is enabled and running for all the databases, wait until all clients have the cluster information. Then you can shut down the source server and the failover process will direct the clients and users to the new server.
FTP, on the other hand, is a fast transfer method that does not look inside the data. So FTP does not care about ACL, replication, or encryption settings. On the down side, normally you have to shut down your Domino server to use FTP, so you only can do this during your maintenance window.
There are two modes of file transfer in FTP - binary and ASCII:
If you are in ASCII mode when transferring a database, the database will be unreadable by Domino on the destination machine. Some versions of FTP start in ASCII mode. Therefore, you should always type: bin on the FTP command line to ensure that you are in binary mode before transferring any databases or templates.
If you using FTP as your transfer method, make sure that both the target and the source Domino servers are shut down. If you cannot shut down your target server, make sure you FTP the databases with different filenames.
As shown in Example 14-1, the local file log.nsf is stored as log.nsf.new on the remote system. (Be sure to rename the file after the transfer is complete.)
Example 14-1: Using different filenames during FTP
C:\Lotus\Notes\Data>ftp linuxa Connected to linuxa 220 ready User (linuxa:(none)): balu 331 Please specify the password. Password: 230 Login successful ftp> cd /domserva/notesdata 250 Directory successfully changed. ftp> bin 200 Binary mode selected. ftp> put log.nsf log.nsf.new 200 PORT command successful. 150 Go ahead send the data. 226 File receive OK. ftp: 1064448 bytes sent in 0.17Seconds 6261.46Kbytes/sec. ftp> bye 221 Goodbye.
Here is how to rename the file after the transfer:
linuxa:/domserva/notesdata # mv log.nsf.new log.nsf
This procedure is very important when you ftp into a transaction-logged server. Otherwise, the server would start transaction logging during FTP process, which could corrupt the transaction log.
After you finish the file transfer, check the setting of the file permission bits. In 4.3.6, "File permissions" on page 54, we list the typical permission bit settings for Domino servers. As mentioned, FTP does not care about ACL setting—but your target Domino server does. So make sure the ACL settings allow the new server to access the databases you transfer.
Many of the tasks we list here can be performed by the Domino server itself, using the adminp server task. However, success will depend not only on a well-configured adminp task, but also on the database template (special mail template) you use.
We discovered in some situations that "server-controlled" migration can fail if you are not using the original Lotus templates. With that in mind, we describe the migration steps in extreme detail.
There are two scenarios for migrating Domino servers: run the new and old Domino servers concurrently for a certain time, or replace the existing old server with the new Domino server. In the following section, we explain each scenario in detail.
This step can be automated!
Follow these steps:
Install and configure the new Domino server.
Copy the databases to the new Server.
Create a connection document for replication between the old and new Server and start the replication.
Inform your users about the new server and location of the databases. Make sure the Notes client gets updated with the new server and database information (Mailservers).
Shut down the old server after the expiration of the time limit.
Follow these steps:
Install the new server.
Copy the key datasets from the old server to the new one (notes.ini, cert.id, server.id, names.nsf, …). Customize notes.ini for directory entries.
Copy the Domino databases to the new server.
Switch the IP addresses from the old server to the new server.
Shut down the old server and start the new Domino server.
Both scenarios are valid; the one to choose depends on your individual situation. However, we recommend the first scenario because it is more fault-tolerant and there is a built-in fallback if things go wrong. Another advantage is that you can make your migration more granular and slowly ramp up the load on the new Domino server.
For migration and server consolidation, you might consider a contract with a services vendor. IBM Global Services and Tiassa Technologies have Domino migration experience , as do other vendors who might be available in your area.
IBM Global Services and Tiassa Technologies provided authors for this redbook.
|< Day Day Up >|| |