Saturday, January 24, 2015

Solaris 11.2 - Server Migration with ZFS “Shadow Migration”


Documentation: by Alexandre Borges

Imagine that we have some data on an older server running Oracle Solaris 11, and we need to migrate this data to a new server running Oracle Solaris 11.1. This is a classic case where we could use a new feature of Oracle Solaris 11 called Shadow Migration. Shadow Migration can also be used to migrate data from systems running Oracle Solaris 10 releases.


Using Shadow Migration is very easy; for example, we could migrate shared ZFS, UFS, or VxFS (Symantec) file systems through NFS or even through a local file system.


To simulate an example of using Shadow Migration to migrate data between two systems, we're going to use two virtual machines that have Oracle Solaris 11 installed (solaris11-1and solaris11-2) in a virtual environment provided by Oracle VM Virtual Box. Furthermore, in the solaris11-2 host, we're going to share a file system (/solaris11-2-pool/migrated-filesystem) and migrate the data inside this file system to the solaris11-1host.

The first step of this procedure is installing the shadow-migration package:


root@solaris11-1:~# pkg install shadow-migration
Packages to install: 1
Create boot environment: No
Create backup boot environment: No
Services to change: 1

DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 1/1 14/14 0.2/0.2 126k/s

PHASE ITEMS
Installing new actions 39/39
Updating package state database Done
Updating image state Done
Creating fast lookup database Done

 
As you can see, the shadows service is initially stopped:

root@solaris11-1:~# svcs -a | grep shadow
disabled 18:22:13 svc:/system/filesystem/shadowd:default

So we must start it:

root@solaris11-1:~# svcadm enable svc:/system/filesystem/shadowd:default
root@solaris11-1:~# svcs -a | grep shadow
online 18:23:17 svc:/system/filesystem/shadowd:default

On the second machine (from where we want to shadow the file system), the file system must be shared using the NFS service and with the read-only attribute (ro) to avoid changing its contents during the shadowing:

root@solaris11-2:~/SFHA601# share -F nfs -o ro /solaris11-2-pool/migrated-filesystem
root@solaris11-2:~/SFHA601# share
IPC$ smb - Remote IPC
solaris11-2-pool_migrated-filesystem /solaris11-2-pool/migrated-filesystem nfs sec=sys,ro

The advantage of using Shadow Migration is that when the data migration begins, any NFS clients that are accessing the source file system automatically migrate to accessing the target file system.
On the first machine (solaris11-1), we can confirm that solaris11-2 is offering the file system through NFS by running the following command:

root@solaris11-1:/# dfshares solaris11-2
RESOURCE SERVER ACCESS TRANSPORT
solaris11-2:/solaris11-2-pool/migrated-filesystem solaris11-2 - -

Now it's time to shadow the ZFS file system from the second machine (solaris11-2) to the first one (solaris11-1) by creating a file system named rpool/shadow_test:

root@solaris11-1:/rpool# zfs create -o shadow=nfs://solaris11-2/solaris11-2-pool/migrated-filesystem rpool/shadow_test

This can be a slow process. Afterwards, you should execute the shadowstat command:

root@solaris11-1:/rpool# shadowstat
EST
BYTES BYTES ELAPSED
DATASET XFRD LEFT ERRORS TIME
rpool/shadow_test 4.73M - - 00:00:04
rpool/shadow_test 46.0M - - 00:00:14
rpool/shadow_test 52.7M - - 00:00:24
rpool/shadow_test 55.1M - - 00:00:34
rpool/shadow_test 57.5M - - 00:00:44
rpool/shadow_test 58.1M - - 00:00:54
rpool/shadow_test 59.6M 128M - 00:01:04
rpool/shadow_test 62.8M 224M - 00:01:14
rpool/shadow_test 89.0M 187M - 00:01:24
rpool/shadow_test 92.7M 360M - 00:01:34
rpool/shadow_test 120M 168M - 00:01:44
rpool/shadow_test 163M 8E - 00:01:54
rpool/shadow_test 178M 8E - 00:02:04
rpool/shadow_test 178M 8E - 00:02:14
rpool/shadow_test 178M 8E - 00:02:24
rpool/shadow_test 178M 8E - 00:02:34
No migrations in progress

We can verify that the migration finished by running the following command:

root@solaris11-1:/rpool# zfs get -r shadow rpool/shadow_test
NAME PROPERTY VALUE SOURCE
rpool/shadow_test shadow none -

Perfect! Everything worked as expected.

The same procedure could be done using two ZFS file systems. For example, we could create a new file system namedrpool/filesystem_source and copy a directory that contains many files into it:

root@solaris11-1:~# cp -r NetBackup_7.5_Solaris_x86/ /rpool/filesystem_source/
root@solaris11-1:~# zfs set readonly=on rpool/filesystem_source
root@solaris11-1:~# zfs create -o shadow=file:///rpool/filesystem_source rpool/filesystem_target
root@solaris11-1:~# shadowstat
EST
BYTES BYTES ELAPSED
DATASET XFRD LEFT ERRORS TIME
rpool/filesystem_target 107K - - 00:00:04
rpool/filesystem_target 51.2M - - 00:00:14
rpool/filesystem_target 114M - - 00:00:24
rpool/filesystem_target 114M - - 00:00:34
rpool/filesystem_target 114M - - 00:00:44
rpool/filesystem_target 114M - - 00:00:54
rpool/filesystem_target 114M 8E - 00:01:04
rpool/filesystem_target 114M 8E - 00:01:14
rpool/filesystem_target 114M 8E - 00:01:24
rpool/filesystem_target 672M 8E - 00:01:34
rpool/filesystem_target 672M 8E - 00:01:44
rpool/filesystem_target 672M 8E - 00:01:54
rpool/filesystem_target 672M 8E - 00:02:04
rpool/filesystem_target 672M 8E - 00:02:14
rpool/filesystem_target 672M 8E - 00:02:24
rpool/filesystem_target 672M 8E - 00:02:34
No migrations in progress

Wow!!! We repeated the recipe, but we used the appropriate syntax for shadowing between two local ZFS file systems. In the same way, we're able to confirm that the shadowing operation has finished.

No comments:

Post a Comment