Less known Solaris 11 features: Shadow Migration
In the ZFS Storage Appliance we have little nice feature enabling you to do migrations of data in the background. It’s called Shadow Migration. It’s a really useful feature. Imagine you have a RAIDZ. After a time you recognize that RAIDZ wasn’t a good decision for your workload and RAID10 would be much better choice. But how to transform it into a RAID10 and how to do it with minimal interruption? You can do this with the Shadow Migration feature. With the Shadow Migration feature, you can migrate the data from one local or remote filesystem to another, while you are already accessing the new one to get the data on the old ZFS filesystem. This feature is available in Solaris 11 as well.
For this demonstration we will use two zfs pools consisting out of files. So we have to create the files first:
Now the pools are created. At first our RAIDZ pool consisting out of 4 files. It’s named source
The second one is the future target of the shadow migration. It consists out of six “disks”
When you did a basic install, the tools and daemons needed for shadow-migration are not included. You have to install them and enable the shadowd
afterwards:
Now you should see the shadowd
daemon running.
Okay … to test the shadow migration we create a filesystem in the source pool:
Now we have to fill this file with a some data. Let’s create some play data.
This should yield a significant number of 128k files. Now we copy them to the newly created filesystem source/somestuff
We will copy the files into the zfs filesystem posing as our old filesystem:
Just to have something to compare, you could simply count the files and calculate the md5 checksum of a file.
Shadow migration will only works, when the source filesystem read-only. So we have to put the source filesystem into such a state:
Okay, now let’s configure the shadow migration:
That’s all. The command may take some moments to get back. The migration of data starts right in the moment you create the new filesystem. It runs in the background and starts to copy all data to the new filesystem. Important to know: You can do shadow migration via NFS as well and it can be an UFS filesystem as well. you just have to declare the source of the shadow migration like nfs://fileserver/directory
Okay. With shadowstat
we can check the process of migration.
The cool think about shadow migration is: You can already use the new filesystem. Despite the fact that the migration is still running, you will already see all files and when you access one file it will be migrated in the moment you access the file on the new filesystem. You don’t have to wait with the access, until the block would be migrated by the normal background migration. When you try to access data, that isn’t already migrated, it’s migrated in the moment you access it in the new filesystem.
Afterwards it proceeds with the further migration of all data in the pool. You can observe that with the shadowstat
command.
Successfuly migrated.
Do you want to learn more?
Docs</a>
docs.oracle.com: Migrating ZFS File Systems"
docs.oracle.com: Migrating File System Data to ZFS File Systems
Blogs</a>
blogs.oracle.com: What is Shadow Migration
blogs.oracle.com: Shadow Migration Internals
blogs.oracle.com: What is Shadow Migration
blogs.oracle.com: Shadow Migration Internals