2003r2 - Moving ressources to a new hardware and storage

Discussion in 'Clustering' started by Adrien Maugard, Jan 7, 2010.

  1. Hello,

    I'm looking for help on the following project:
    I've got some 2 nodes clusters with disk replication supported by Veritas
    Storage Foundation, each one hosting 3 to 6 ressources in A/P mode (obviously
    ;) )

    I'm looking to migrate the clusters to a new storage (SAN with inbound
    replication, thus far better than the actual solution), and as we really
    don't know how Veritas is integrated to the OS we can't re-use the actual
    servers in the clusters (without a format...)

    So how can I migrate a ressource from one cluster node to a new cluster new
    node (2 nodes with FSW cluster)?
    I planned to do it this way:
    1. Copy/move all files manually between storages
    2. destroy the ressources & virtual server from the old cluster
    3. Rebuild a new ressource & virtual server on the new cluster
    4. Rince/repeate until nothing is left on the old server
    5. uninstall clustering, remove services & computer account in AD
    6. Format the old server clusters and re-use the hardware for another
    cluster migration.

    I'm doing something wrong this way?

    Adrien Maugard, Jan 7, 2010
    1. Advertisements

  2. Adrien Maugard

    Gaurav Anand Guest

    Hi Adrien

    You can follow that approach or you can add a new node to existing cluster
    and then use cluster recovery software to migrate disk. Once disk resources
    are migrated along with data you can get rid of old disk resources managed by
    veritas and uninstall veritas software after removing veritas managed
    physical disk resources from cluster. This way you will not have to
    reconfigure everything from scartch.


    The cluster recovery utility allows a new disk, managed by a new physical
    disk resource to be substituted in the resource dependency tree and for the
    old disk resource (which now no longer has a disk associated with it) to be

    To replace a failed disk use the following procedure:
    · Add a new disk drive to the cluster. In a storage area network
    environment, adding a new disk drive may involve creating a new logical unit
    and exposing it to the server cluster nodes with appropriate LUN masking,
    security and zoning properties.
    · Make sure that the new disk is only visible to one node in the cluster.
    Until the Cluster service takes control of the new disk and a physical disk
    resource is created, there is nothing to stop all nodes that can see the disk
    from accessing it. To avoid file system issues, you should try to avoid
    exposing a disk to more than one node until it has been added to the cluster.
    In some cases (such as with low-end fiber channel RAID devices or devices in
    a shared SCSI storage cabinet) there is no way to avoid multiple machines
    from accessing the same disk. In these cases, a CHKDSK may run when the disk
    resource is brought online in step 5 of this procedure. Although this
    situation is recoverable through CHKDSK, you can avoid it by shutting down
    the other cluster nodes, although this may not be appropriate if the cluster
    is hosting other, currently functioning applications and services.
    · Partition and format the new disk drive as required. Note: For a disk
    drive to be considered as a cluster-capable disk drive, it must be an MBR
    format disk and must contain at least one NTFS partition. Assign it a drive
    letter other than the letter it is replacing for now.
    · Create a new physical disk resource for the new disk drive using Cluster
    Administrator (or the cluster.exe command line utility).
    · Make the disk drive visible to the same set of nodes as the disk drive
    that it is replacing (in a typical configuration, a disk driver is visible to
    all nodes in the server cluster). In the event that the device does not
    appear to the cluster nodes, you may perform a manual rescan for new hardware
    using the device manager. At this stage you should try to bring the disk
    resource online and then fail it over all nodes of the cluster in turn to
    ensure that the new physical disk is correctly configured and can be viewed
    from all nodes.
    · Use the Server Cluster Recovery Utility to substitute the newly created
    physical disk resource for the failed resource. Note: The Server Cluster
    Recovery Utility ensures that the old and new disk resources are in the same
    resource group. It will take the resource group offline and transfer the
    properties of the old resource (such as failover policies and chkdsk
    settings) to the new resource. It will also rename the old resource to have
    "(lost)" appended to the name and rename the new resource to be the same as
    the old resource. Any dependencies on the old resource will be changed to
    point to the new resource.
    · Change the drive letter of the new physical disk to match that of the
    failed disk. Note: The new physical disk resource must be brought online
    first and then the drive letter can be changed (on the node hosting the
    physical disk resource) using the Disk Management snap-in available via
    Computer Management.
    · Once you have validated that the new resource is correctly installed, you
    should delete the old physical disk resource as it no longer represents a
    real resource on the cluster.
    · Once the cluster is configured, you should restore the application data
    to the new disk drive.

    Gaurav Anand, Jan 8, 2010
    1. Advertisements

  3. Thanks, I will try this solution.

    Adrien Maugard, Jan 8, 2010
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.