Changing the Metadata Server

Changing the Metadata Server in a Shared File System Environment

The procedures in this section describe how to change the host that is acting as the metadata server in a shared file system without using the automatic Membership Services feature of a software package.

You can change the metadata server system manually under the following circumstances:

• If the metadata server becomes unavailable

• If you want to change the metadata server or the potential metadata servers

For a metadata server change to succeed, the mount options of the existing metadata server and all potential metadata servers must be the same.

If the metadata server of a shared file system crashes, it is safe to change the metadata server only after rebooting the metadata server or otherwise ensuring that the server cannot issue any I/O before being rebooted. Do not use any of the following methods to stop the server, because these are likely to corrupt the file system:

• Issuing an L1-A key sequence

• Performing an involuntary failover to another host

• Issuing a go (continue) command, requesting a dump file, or issuing a sync command to the old metadata server

  Similarly, if the metadata server panics and drops into kernel adb command, do not change the metadata server and then issue a :c (continue) command on the server. This action causes the old metadata server to push stale buffers out to the now-active file system.

How to Change the Metadata Server When the Metadata Server Is Available

• On the existing metadata server, issue the samsharefs-s command to declare the new metadata server.

  For example:

  titan# samsharefs -s tethys sharefs1

  ---

  Note - In archiving environments, you should stop all archiving operations on the metadata server before you issue this command.

  ---

How to Change the Metadata Server When the Metadata Server Is Not Available

1. Ensure that the existing metadata server cannot restart without being rebooted.

   Specifically, ensure that the server is powered down, rebooted, halted, or disconnected from the metadata disks. Your goal is to bring down the old metadata server and flush or destroy all buffers or otherwise ensure that they cannot be rewritten.

   Use the following key sequence from the kadb prompt:

   kadb[1]: sync     # Forces a dump
   kadb[1]: $q       # Exits the debugger for prom

   Use the following key sequence from the PROM prompt:

   {0} > sync            # Forces the buffers out
   {0} > boot _args_     # Discards buffers

   For args, specify arguments for the boot command, such as the -r or the -v option. For more information, see the boot(1M) man page.

2. From the new (potential) metadata server, wait at least the period of the maximum lease time, and then issue the samsharefs command.

   For example:

   # samsharefs -R -s tethys sharefs1

   The wait ensures that all client leases expire before you issue the samsharefs command. If you are uncertain as to whether the lease time has expired, bring up the samu(1M) N display. For information about the samu command, see Chapter 13, Using the samu Operator Utility. For information about leases and their durations, see Using Leases in a Sun QFS Shared File System: (rdlease, wrlease, and aplease Options).

   ---

   Caution - If you use the -R option to the samsharefs command on a mounted file system to change the metadata server host, you must first stop, disable, and disconnect the active metadata server. Failure to do so can cause file system corruption.

   ---

3. (Optional) Unmount the file system.

   Perform this step only if you want to perform a file system check.

   Use the procedure in Unmounting File Systems in Sun QFS and Sun Storage Archive Manager 5.3 Installation Guide.

4. (Optional) Issue the samfsck command to perform a file system check.

   If the metadata server of a Sun QFS shared file system crashes, the server should be rebooted and the file system should be unmounted on all clients before the samfsck command is run. The server and clients preallocate blocks before changing the length of files. The samfsck command cleans up files that have extra blocks allocated, and these extra blocks might contain data. If this type of cleaned-up file is awaiting a size update from the client, the file will be missing those blocks when the client continues. As a result, the file will be missing data, and the missed data will read as zeroes.

Changing the Metadata Server in an Archiving Environment

The procedures in this section describe how to change the host that is acting as the metadata server in an archiving shared file system without using the automatic Membership Services feature of a software package.

You can change the metadata server system manually under the following circumstances:

• If the metadata server becomes unavailable

• If you want to change the metadata server or the potential metadata servers

For a metadata server change to succeed, the mount options of the existing metadata server and all potential metadata servers must be the same.

How to Change the Metadata Server in an Archiving Environment

Archiving functions can run only on one host at any time. This procedure assumes that both systems are running at the time of the transfer.This example moves archiving functions from host A to host B.

Before carrying out this procedure, verify that host B has access to the robot catalog from host A. The archiver.cmd file, mcf file, stager.cmd file, and other configuration files must be identical to those on host A.

1. Idle archiving processes on host A.
   1. Run the samcmd aridle and samcmd stidle commands to halt archiving and staging on host A.

      These commands will allow current archiving and staging to complete but will not start any new work.

   2. Idle all of the tape drives on host A.

      Use samcmd eq idle, where eq is the equipment number of the drive. This command will put the drives in an off state after any current I/O completes.

   3. When the archiver and stager are idle and the tape drives are all in the off state, run the samd stop command to halt all of the robot and tape-related daemons.
   4. If you have a cron job that runs the recycler, remove this entry from the crontab and verify that the recycler is not currently running.

      At this point, the archiving processes have been halted and file system failover to host B can be performed.

2. Start the archiving processes on host B by running the samd config command on host B.

   This command causes sam-fsd and its subprocesses (archiver, stager, and so on) to reconfigure and re-read the configuration files. It also causes sam-amld and the tape-library-related daemons to start. At this point all Sun QFS shared client applications waiting for stages must reissue the stage requests.

   Host B should now be fully functioning as the archiving process server and metadata server for all file systems.