Shulou(Shulou.com)06/02 Report--

Starting from this article, Lao Wang will bring you several articles about cross-cluster migration. In the past, few people mentioned anything about cross-cluster migration in China. In fact, Microsoft clusters support cross-cluster migration. So what exactly is cross-cluster migration? what is the content of the migration? let's take a look at it.

At the beginning of 2008, when we right-click on the cluster name, we can see the migration service and application, and then a migration cluster wizard pops up, which is essentially a cross-cluster migration wizard designed to help us migrate from 2003 cluster or 2008 cluster to 2008R2 cluster.

In the 2008R2 era, for cross-cluster migration, it mainly refers to the migration of low-version cluster applications and the application cluster configuration. For example, for example, there is currently a file server cluster running on the 2003 cluster with the external name Fileserver. We migrated the file server cluster group. Not only can the file server be migrated between nodes within the 2003 cluster, but also the file server cluster group can be migrated directly to the 2008R2 cluster with the same external access name after the migration, but the role that should host the file server cluster is the 2008R2 node.

The key here is that when we run the cross-cluster migration wizard, we are actually migrating the configuration of the cluster application. The original 2003 cluster has this role, and this role has some configurations. What we do is to let the 2008R2 cluster also have this role, while retaining the relevant configuration, but the contents of the file server, the cross-cluster migration wizard will not help us copy the file server content. The contents of the file server need to be copied and completed by ourselves in advance, and the Cluster Migration Wizard is only responsible for helping us migrate cluster roles and cluster role configurations across clusters, and helping us complete role-to-disk mapping, that's all.

Some friends may say, under what circumstances will this kind of cross-cluster migration be used? Lao Wang thinks there are the following scenarios.

The cluster role hosted on the old cluster has been used all the time, and the name does not want to be changed, so the operation and downtime can be reduced as much as possible, so the cluster role can be migrated directly by running the Cluster Migration Wizard and the original access name can be retained.

For the cluster role, there are many on the old cluster, and each role has made a lot of personalized settings, do not want to rebuild, reset, you can choose to migrate the cluster role directly to the new cluster.

There are usually two forms of cross-cluster migration.

Many-to-many cross-cluster migration: directly 2003 one cluster does not move, 2008R2 one cluster does not move, and the role is migrated across the cluster between the two clusters

Two-node local migration: the hardware has only two servers. Currently, there is a set of two-node 2003 clusters. When migrating, you need to withdraw the other node from the cluster, redo the system, and then establish the cluster to achieve 1-node 2003 cluster and 1-node 2008R2 cluster on both sides. Migrate roles between such two single-node clusters.

If you are using this scenario of two-node in-place migration, it is important to note that when remaking one of the nodes into a 2008R2 cluster, Lao Wang suggested that first, the node normally exits the 2003 cluster, and then it is best to re-clean the installation when remaking the 2008R2 to prevent interference from the cluster configuration.

In this paper, Lao Wang will adopt the method of many-to-many cross-cluster migration to actually establish two sets of multi-node clusters.

In addition to the migration form, there is a distinction between two different migration storage forms.

The new cluster uses old storage

New cluster uses new storage

Lao Wang will explain both of these two forms of migration storage. First, let's take a look at the scenario where the new cluster uses the old storage.

Scene introduction

2003Cluster

03node1:lan 10.0.0.7 255.0.0.0 dns 10.0.0.2 heart:18.0.0.101

03node2:lan 10.0.0.8 255.0.0.0 dns 10.0.0.2 heart:18.0.0.102

Cluster IP:10.0.0.60 Cluster name: fscluster Cluster Group name: fileserver

Cluster network: lan network heart network

08dc&iscsi:lan:10.0.0.2 255.0.0.0 dns 127.0.0.1

2008Cluster

08node1:lan 10.0.0.3 255.0.0.0 dns 10.0.0.2 heart:18.0.0.1

08node2:lan 10.0.0.4 255.0.0.0 dns 10.0.0.2 heart:18.0.0.2

Cluster IP:10.0.0.99 Cluster name: devtest Cluster Network: lan Network heart Network

In implementation, we cut the migration node as follows

The file server cluster runs at 2003 with the external access name fileserver, and the current storage is allocated to 2003 two nodes

Storage is allocated to 2008R2 nodes, and 2008R2 can see the storage

2008R2 builds the cluster, but does not add storage to the cluster

2008R2 runs the Cross-Cluster Migration Wizard

The Fileserver role is migrated to 2008R2 but not online

FileServer resource group above offline 2003

FileServer file server role on online 2008R2

Fileserver continues to provide services, but is provided by the 2008R2 server

If you open the 2003 cluster, you can see that a cluster group of FileServer is currently running, providing three shares of doc,txt,software, and two disks, data1,data2, all of which are hosted on data1 disks.

Access the\\ Fileserver cluster network name to see the following three shares

Allocate storage so that 2008R2 cluster nodes can also see it

Open 2008R2 disk Manager and rescan to see the two disks assigned to it.

Note that a key point here is that storage must not be allocated online to a new cluster in a hurry, and at this point, it is important to ensure that although storage is visible to the new cluster node, it cannot be added to the new cluster storage, otherwise it will interfere with the operation of the old cluster. Keep it this way, make sure that the new cluster can see the storage, and that storage should be added online to only one cluster at a time.

2008R2 has currently created a devtest cluster, and the cluster storage and cluster roles are empty

Execute the Cross-Cluster Migration Wizard on a 2008R2 cluster

Enter the 2003 cluster name within the same domain that can be accessed by the current 2008R2 cluster node, and check to ignore the drive number verification of the cluster node turned off

After clicking next, the Migration Wizard will evaluate which cluster groups on the old cluster can be migrated to the 2008R2 cluster according to the rules.

Click to view the report to see the detailed evaluation process. The migration wizard will give a report based on different cluster groups. If it is a special cluster group, you will also need to perform some manual configuration after the migration.

Enter the 2003 cluster service account and password (the predecessor of CNO), and then click next.

Start the cross-cluster migration, here we go!

Migrating cluster groups, run the progress bar

A summary will be given after completion. Click to view the report to see the detailed report.

After clicking finish, you can see that the cluster now has applications and disks, but they are all offline.

Next is the most important switching part. First of all, we need to take the cluster group above 2003 offline. Note that there is downtime now, and we need to plan the execution time of this part.

2008R2 cluster node online storage, you can see in disk Manager, the wizard has automatically helped us to complete the online storage on 2008R2.

Next, we need to online the cluster disk in Cluster Administrator. We can see that it has been automatically mapped to M and N disks after it is online. This is the magic of the migration wizard, which can also bring the configuration of the old cluster. Automatically help us complete the mapping of cluster storage!

Next, for the online file server resource, you can see that the same network name and resource IP address are still retained.

At this time, you can see the cluster disk above 2003 and the contents of the file server in the cluster disk on the 2008R2 cluster.

Here, Lao Wang has been tested many times, and the result is that if we migrate the application according to the default cross-cluster migration wizard, the file sharing settings will disappear after the migration. For companies where file sharing does not have many permissions, it may be acceptable to re-share, but for some file sharing clusters with many permissions within the enterprise, this may not be acceptable. After Lao Wang's research, I have found a feasible way at present.

Let's go back to time node 1. The current fileserver cluster group is still running on 2003, and access\\ fileserver is provided by 2003 nodes.

At this point, you can insert an extra disk, enter it as a temporary backup disk, or find another disk in the system and use manual copy or command copy to copy the folders that are important and need to be migrated to the backup disk. Here Lao Wang uses the xcopy command to copy a copy to disk C.

Manually share the copied folder, and the permissions remain default. Note here that since our system already has the same share name, which runs on the cluster and is called doc, our backup share here cannot be called the same name. I added an a to the name of each backup share.

At this point, we need to use a tool, permcopy, which is available in 2003 resource kit. The tool is mainly used to copy share permission settings.

Using the permcopy command, we manually set the share permissions on the cluster and copy a copy of the share permissions that are mapped to the backup on a single node of the cluster. Now open the backup share created on disk C, and you can see that the permissions have come.

At this time, run the Cluster Migration Wizard again to migrate the Fileserver cluster group. After the migration is completed, the 2008R2 is offline by default.

Offline 2003 cluster group

Online 2008R2 cluster role

Access\\ fileserver is now provided by the 2008R2 cluster

However, we can see that the sharing has not been migrated. We share each folder manually, and the permissions are kept by default.

Although the 2003 cluster group is offline and cannot be accessed at this time, because we have had a backup share, we can still use the access of the node IP to access the backup share above 2003\ 10.0.0.7

Then use permcopy to map backup sharing permissions on 2008R2.

Now you can see that not only the contents of the file server have been migrated from the 2003 cluster to 2008R2, but also the file permissions have been migrated.

The current file server cluster role operates in node1. We manually move the role to node2 and find that sharing permissions are also applied.

As you can see, we moved the file server role from the 2003 cluster to the 2008R2 cluster through a simple wizard, and the whole process was smooth. The downtime only occurred during the resource exchange. The 2003 file server cluster group went offline and the 2008R2 file server role went online. Therefore, Lao Wang believes that the existing file server cluster migration can be done through the cross-cluster migration wizard. It helps us to automatically complete the mapping of cluster roles to disk, as well as configuration migration, which can prevent manual errors. For people who do not need to migrate shared permissions, this way of switching cluster groups is simply too convenient. After swapping, you can share it manually.

If sharing configuration permissions also need to be migrated, then you may need to do some additional operations. Lao Wang has tested here and found that this way of backup sharing is the most secure, but in practice, the file server in the enterprise is usually very large. It is sometimes not realistic to do this kind of backup sharing during migration. Lao Wang suggests that in practice, if you use Lao Wang's method, it is more important to set permissions only. Many shared folders can be backed up and shared. Other common shares, such as software and video, are directly migrated to manual sharing, and for key permissions, they are then mapped from backup sharing permcopy after migration.

Next, let's take a look at another form of migration storage, where the new cluster uses new storage and the old cluster uses old storage.

The migration node is cut as follows

The file server cluster runs at 2003, alias fileserver, and the current storage is allocated to 2003 two nodes

Create a new 2008R2 cluster, and the storage server allocates a new set of storage that is only visible to the 2008R2 cluster

2008R2 online new storage, assigning drive letters, adding to cluster storage

Manually copy the shared folder to the new storage

Execute the Cross-Cluster Migration Wizard to map the old cluster configuration to the new cluster disk

Offline 20003 cluster group

Online launch 2008R2 cluster group

Open the ISCSI target server and confirm that 2003 storage is allocated only to 2003 cluster nodes and 2008 storage is allocated only to 2008R2 cluster nodes

After the 2008R2 node rescan the disk, you can see the disk assigned to it.

Initialize the cluster disk and randomly assign a drive letter, which will be changed by the configuration of the old cluster anyway.

Add a new disk to 2008R2 cluster storage

As mentioned above, the Cross-Cluster Migration Wizard mainly helps us to complete the cluster group migration mapping to the new cluster, but the Cross-Cluster Migration Wizard does not involve specific content migration when migrating to 2008R2 for 2003. For example, if we want to perform a cross-cluster file server migration, both sides are using their own storage. At this time, we need to manually copy the contents of the old cluster file server to the new cluster storage.

Here, Lao Wang still uses orders to copy.

After the replication is complete, you can see that the contents of the file have appeared in the new cluster and new storage.

Run the Cross-Cluster Migration Wizard to specify the 2003 cluster name

Select the cluster group to migrate

Enter the cluster service account password

The point is, in the migration pattern in which both clusters use old storage, we can't see this step. When the new cluster has new storage, we can see this step. Storage mapping, we can manually select, to map the cluster disk of the old storage to the disk of the new cluster.

Old cluster data1 storage maps to new cluster disk 1

Data2 maps to cluster disk 2

Confirm the cluster mapping result

Start execution of the migration resource group progress bar

A summary report is given after completion, indicating the results of the migration and what should be done later. if you want further detailed information, you can view the report.

Offline 2003 cluster, downtime begins

Online 2008R2 File Server role

As you can see, no matter what drive letter we specified before, the cross-cluster migration wizard will be overwritten as the drive letter of the old cluster

Access\\ fileserver has been found to be accessible, which is provided by the 2008R2 cluster, but the sharing settings have not been migrated. By default, the administrator needs to reshare manually.

Referring to relevant Microsoft articles, I found that Microsoft deliberately pointed out that the drive letter and label of the new storage in the new cluster cannot be the same as that of the old cluster. Lao Wang did not find this problem in the actual test. No matter I used the MN drive letter or the PV drive letter in the new cluster, the migration results are consistent and will be completely overshadowed by the disk settings of the old cluster. After the migration is completed, you can modify the cluster drive letter on the new cluster.

As you can see, the result of the cross-cluster migration of file servers, whether using old storage or using new storage, is the same, and the sharing settings will not be migrated to the new cluster. If you don't care about permissions, you can re-share them after migration, but it will be painful if you set a lot of permissions.

At first, Lao Wang thought of some relatively simple methods. Since the sharing permissions were set in the registry, I exported the registry directly from the old cluster node, and imported from the new cluster. But Lao Wang found that the shares in the file server cluster on 2008R2 could not see any records in the registry at all. I tried to import the exported sharing settings registry into all the nodes in 2008R2. It is found that the permissions still haven't come over, so the easiest way to import the shared settings registry is impossible.

There are still WSMT and FSMT left, but considering the need for additional installation tools, I also abandoned it. I finally thought of backup sharing, which is a bit troublesome, but it works all the time, and it will ensure that the permissions will come smoothly.

There are probably several ways to use backup sharing

Before the migration, the 2003 side inserts the backup disk or backs up to another disk, manually copies the file and gives it a different share name, then the permcopy share permission passes, and after the new cluster is migrated, the permcopy share permission comes back, and 2003 is retained until the share permission migration is completed.

Before migration, the 2003 side directly copies the file contents to the local disk of the 2008R2 node, the 2008R2 shared folder, and the share name cannot be the same as the real one. The permissions default first, then permcopy copy permissions to the local disk, 2008R2 establishes the cluster, executes the migration wizard, completes disk mapping, and then copies the contents to the cluster disk. At this time, the 2003 cluster can be completely offline. After the 2008R2 cluster completes the mapping, the files are shared manually. The permissions default. Then the 2008R2 cluster uses permcopy to copy the native disk backup sharing permissions to the official cluster disk

The difference between the two is that the offline time of the 2003 cluster, if the backup is on the 2003 side, then the migration may eventually need to be copied once from the 2003 side, and the 2003 cluster needs to operate at least up to this time. If the second kind, although it takes two permcopy, the 2003 cluster can be offline after completing the cluster migration wizard, depending on your resource situation and needs. Lao Wang personally thinks that 2003 will be fine for a while. At least once the configuration of the 2008 R2 side goes wrong and fails, then I still have a backup file sharing at least on the 2003 side. In practical operation, I can insert a backup disk directly on the 2003 node to do this, even after the permission transfer is completed. But my backup disk has always kept a backup.

There is another way of thinking, but this idea is specific to the scenario of new storage in a new cluster versus old storage in an old cluster.

After the time node returns to the completion of the Cluster Migration Wizard, the current cluster role is online on 2008R2, and file sharing is started manually. Permissions remain default and have not been migrated.

2003 the cluster group is currently offline

At this time, since we have two sets of clusters and two sets of storage, we can play like this. We modify the IP and network name of the old cluster, and then bring the old cluster online again!

After the modification is completed, the 2003 cluster will be online again. Haha, the old guy is alive again, and we can access it temporarily again. But at this time, users do not know this address. They only know the path\\ fileserver from the beginning to the end. At this time, they should visit\\ fileserver and go to the node of the 2008R cluster.

At this time, with this temporary path, we can do things, permcopy do it!

The permissions have all come through.

At this time, the 2003 old cluster can retire gloriously, keep it as it is or go offline, and observe the operation of the posterity 2008R2. Once there is a problem with the 2008R2 after the migration, the old cluster can change its name and come up again.

Why does Lao Wang say that the third way of thinking is only applicable to the scenario of new storage in new clusters and old storage in old clusters? because if we share the same storage in new and old clusters, then we have to find a time node to exchange storage. Once the storage is swapped to the new cluster, the old cluster can no longer go online, because the disk is shared in the disk and the disk has been swapped by the new cluster, so the new storage in the new cluster In the scene of old cluster and old storage, the third way of thinking that Lao Wang said is meaningful.

Above, for the beginning of the cluster migration series, I hope to open a brain for you, take a good start, and let more friends know that there is such a cross-cluster migration feature available in the cluster. When you migrate to the 2008R2 cluster in 2003, you can see that the cross-cluster migration wizard only migrates the application resources and cluster-related settings in the old cluster to the new cluster, but for the content of the file server. Cross-cluster migration is regardless, so I also said that the cross-cluster migration wizard is a light wizard from 2003 to 2008R2. It only migrates roles and configurations to new clusters, and the content and data of specific roles still have to be migrated on their own. In this article, Lao Wang takes a typical file server migration as an example, and uses some honest methods to migrate permissions. My idea may be limited for a while, and there should be more good ways. Lao Wang is just throwing a brick to attract jade here. If you are interested, you can try to migrate some characters for research. Lao Wang will continue to spend several articles on the cluster migration series until WSFC2016.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.