6.10.2 Reinstalling the
Old PDC
6.10.2 Reinstalling the
Old PDC
In our example domain D01 (shown in Figure 106), the file server (\\FS01) has 50 GB of hard disk on a RAID-5 partition. It also has Disk Limits (also known as DASD Limits) applied. The data is critical to the business and availability is a top priority. It is essential to perform a migration that minimizes system outages.
Completing the following steps described in the following sections will migrate the file server.
Invariably, some hardware set-up and configuration will be needed particularly where large RAID partitions are concerned. The configuration steps are not discussed in this redbook.
First, install OS/2 Warp Server for e-business on the system that has been chosen to become the new file server. The installation itself is not of special importance since, at this stage, the server is not active on the network.
Follow the steps outlined in Section 6.9.1 Installing OS/2 Warp Server for e-business to complete the installation. It can a be CD-ROM panel-based or CID-based installation. The most important thing is to make sure that the server is configured exactly the same as the existing file server \\FS01.
The access control profiles from the existing file server must be saved. This is so that, following migration and data restoration, they can be restored to the new system. If DASD Limits exist, save these too.
There are several ways to back up the access controls. They are described in detail in Section 3.13 Backup Access Control Information, as are the steps needed to back up DASD Limits (3.12 Backup Directory Limits).
| Note |
|---|
|
One issue of particular interest is that of drive lettering. The utilities BACKACC, RESTACC and PREPACL both record and use drive letter information in the backups that they save or restore. If disk re-partitioning is planned during the migration, possibly resulting in data residing on drive letters other than those they started out on, restoration of access control information might be impaired. |
If drive lettering is likely to be an issue, it is advisable to take one of two approaches.
LAN Server Management Tools, an IBM-written as-is utility, can be employed to move access controls to a different drive. It does this by extracting the data to a flat ASCII file that can be manipulated and then reapplied to a drive. Please refer to Appendix B. LAN Server Management Tools (LSMT) for further information about this.
The next step is to attach the new file server to the live network and add the required data.
| Note on Conflicts |
|---|
|
Attaching a server with a duplicate configuration raises conflict issues. Conflicts can arise with duplicate IP addresses, MAC network adapter addresses, communications definitions, and NetBIOS names. |
Since the server has been installed with exactly the same configuration (and hence, the same NetBIOS name COMPUTERNAME parameter) as the file server that already exists on the network, starting the server in this state will lead to a NetBIOS name in conflict condition. A workaround is needed to prevent this condition.
Before the server is attached to the network and powered up, the STARTUP.CMD file should be renamed to prevent any server services starting. This procedure is outlined in Section 6.9.1 Installing OS/2 Warp Server for e-business.
The new system can be attached to the network and started with a different workstation name. Since the new name is not known to the domain controller, it must first be defined.
Decide on a unique new name for the server to be known as on the network when started. In this example, the replacement file server is called \\FS11. We add the server as a User ID in the domain, and then add this User ID to the group SERVERS. Logged on as an administrator, we remotely issue the following commands:
NET ADMIN \\DC02 /C NET USER FS11 /ADD /PASSWORDREQ:NO
then press Enter. Then,
NET ADMIN \\DC02 /C NET GROUP SERVERS FS11 /ADD
then press Enter.
The new domain controller is \\DC02.
Now, on the new file server, the LAN requester service can be started using the /CO: parameter as follows:
NET START REQ /CO:FS11
then press Enter
where FS11 represents the unique NetBIOS name by which the workstation is known on the network.
The server service can then be started on the file server.
NET START SERVER
then press Enter.
In this scenario, the new file server \\FS01 now exists under the
name FS11 on the same network as the original file server
(\\FS01) for the purposes of restoring data even though the entry in
IBMLAN.INI states that it is FS01.
Figure 124: Introducing the File Server to the Network
Now that the server \\FS11 has been defined to the domain, it receives updates to the master User and Group accounts file, NET.ACC.
In a high volume, dynamic data environment, this approach helps to speed up the data restoration process. This is due to the fact that the new server can be installed and data restored while the original server is still running in production.
Once the new server \\FS11 is attached to the network, data can be copied to it from the existing file server. The decision on what method to employ to transfer this data rests with administrator performing the migration.
The data transfer can be achieved in a number of ways. We discuss some of
the possibilities in this section. When deciding which method to deploy to move
the data, consideration should be given to convenience, the ease of
implementation, and speed of data recovery. Business pressure will probably
dictate what is required.
Figure 125: Transferring Data
XCOPY is supplied natively with OS/2 Warp Server for e-business. It is a functionally rich program. In situations where data is very dynamic, or there is a large volume of it, XCOPY can be a little slow.
In our experience, average data throughput over Token Ring using XCOPY is around 12 MB per minute. If an XCOPY process is interrupted, the command needs to be restarted. For large data volumes, it can take a long time to complete.
The syntax for XCOPY is
XCOPY [drive:][path] filename [drive:][path] filename [/D:date]
[/S][/E][/P][/V][/A or /M][/H][/T][/R][/O][/F]
XCOPY is a widely used, very reliable program. However, in a migration scenario, we have found quicker and more convenient programs that achieve the same result. These alternatives are CCP and WREPL, discussed in Section 6.11.5.6 CCP Copy and Section 6.11.5.7 WREPL.
The award-winning ADSM family of software products is a comprehensive, Enterprise-wide solution integrating unattended network backup and archive with storage management and powerful disaster recovery.
Using ADSM, we have found that the average throughput of data transfer over Token Ring is approximately 12 - 20 MB per minute (your ADSM environment will obviously vary). In a migration scenario, a full or incremental ADSM backup taken on the original system prior to migrating can be restored to the replacement system once that system is present on the network.
Where this approach differs from a straightforward XCOPY is that the ADSM client code must be installed on the new system with any co-requisite software (such as TCP/IP or communications software) to facilitate the restoration.
It is also important to consider the identity of the systems on the network. While it is technically possible to force a restoration of data onto a system other than that from which the data was originally backed up, there is an implication on how the new system must be known on the network.
If the restoration occurs while both systems are attached to the network, their identities should be unique in order to avoid TCP/IP or communications conflicts between the two systems.
If the restoration occurs when only one system is on the network (the new one), then a conflict does not occur.
We do not discuss ADSM in detail in this redbook. If you are already familiar with ADSM, you should consider how you can integrate it into your migration plan. If are not familiar with it, and you want to know more, refer to the redbook titled Using ADSM to Back Up OS/2 LAN Server and Warp Server, SG24-4682, or also look on the World Wide Web at the following address:
http://www.storage.ibm.com/software/adsm/adsmhome.htm
Available in OS/2 Warp Server, Version 4, PSnS has an excellent GUI interface for defining backup and restore procedures. PSnS, Version 6.01, included in OS/2 Warp Server for e-business, contains new function as described in Section 1.3.9 Backup and Recovery Services. Normally, when executing backup and restore, these functions are done with the same version of the backup and restore software. However, Version 6.01 was written specifically to support backup sets taken with previous versions of the software. This may or may not be true for other backup software packages.
There are numerous tape backup systems on the market, and newer, removable backup media, such as optical drives and CD-ROMs, are becoming popular.
A backup taken before a migration can be restored after the migration provided OS/2 Warp Server for e-business supports the backup software. It will be necessary to install client backup software onto the new machine. This approach also assumes that the backup and restore program can handle restoring data onto a machine with a different NetBIOS name.
We recommend that before considering using your backup and restore application to transfer data, you should:
OS/2 Warp Server File and Print Services is supplied with a service that is similar to the DCDB Replication Service and is simply called the Replication Service. With this service it is possible to define one server as an Exporter and one server as an Importer. It is then possible to define a set of directories to replicate from the Exporter to the Importer.
Full details on setting up the Replication service in OS/2 Warp Server for e-business are found in the on-line documentation Network Administrator Tasks provided with the product.
This approach is not recommended for restoring large quantities of data. There is less control over the data transfer than with copy programs. For this reason, details have been omitted, but the possibility is presented for completeness.
CCP is a conditional copy program that copies files that match the source file specification(s), excluding those that also match the optional Xsource filename pattern(s), to the target directory. Source files are copied if they do not exist in the target directory or if they have a different time, date, or size in the target directory.
If for some reason a CCP copy is interrupted, it is much quicker to complete the copy of the remaining files with this program than with XCOPY because it is not necessary to start the copy over again.
We have included this tool on the CD ROM accompanying this Red Book.
The syntax for CCP is
CCP [ -flags ] source [ ! Xsource ] targetdir
WREPL is a replicator tool that conditionally copies data from one server to another including access controls. It can be used to synchronize data on two servers in either direction, exporter to importer or vice versa. We have included this tool on the CD ROM accompanying this Red Book.
The syntax for WREPL is
WREPL \\Server ServerPath LocalPath [SleepTime] [/R] [/D] [/L:logfile]
[/Q]
We found that an initial copy with CCP was very effective. On large data volumes, the data will have changed between the start and end of the copy process.
Following a successful transfer of initial data, initiating WREPL provides the final incremental copy of data that is new or changed since the original data transfer started. This ensures that all data is present on the new system prior to its being added to the network as a replacement, migrated system.
| Our Approach |
|---|
|
In our migration scenario, we initiated CPP to copy most of the data from the old to the new server. We found that this was very effective. On large data volumes, the data will change during the time taken to complete the copy. To synchronize the data, we then used WREPL. This procedure worked well in this and other previously experienced migrations. With the two utilities, we quickly transferred our data. |
Of course, there are negative effects to this approach that have to be weighed against the other methods of data restoration; namely, both servers are performing file I/O, and there is additional network traffic to contend with.
At this stage, two almost identical systems will exist on the network. The access controls must now be restored.
There are a number of utilities available to do this, as described in Section 3.13 Backup Access Control Information. To avoid problems, whatever utility was used to backup the access controls should be used to restore them.
RESTACC restores the permissions for 386 HPFS volumes, the user accounts database, and the audit file stored with BACKACC.
The following example shows the use of RESTACC in restoring access control profiles and restoring ACL information stored in the DRIVE_D.ACL file:
RESTACC D:\ /F:C:\BACKUP\DRIVE_D.ACL /S
The full syntax follows:
RESTACC [drive:] pathname [[drive:]newname] [/F:[drive:]source]
[/L1:[drive:] [path] [filename]] [/S] [/V]
where:
The final step in the file server migration is to switch over the servers. The old server must be removed, and the new server started using the name \\FS01.
Stop the server and requester services on both \\FS01 and the new server (currently \\FS11).
NET STOP SRV
then press Enter.
NET STOP REQ
then press Enter.
The server service can then be started on the new file server with:
NET START SERVER
then press Enter.
The replacement server will then start as \\FS01, as defined in its IBMLAN.INI file. The old file then becomes available for reinstallation. The migration of the file server is now complete.
6.12 Step 4: Migrating
the Print Server