Introducing: Copy-Free Transition

Clustered Data ONTAP 8.3.2RC1 was announced last week and included many enhancements to ONTAP, including a feature called Copy-Free Transition.

A number of people knew about this feature prior to the cDOT release because they attended Insight 2015 and witnessed either a live demo of the feature or the session presented by Jay White (CR-2845-2: Using the 7-Mode Transition Tool).

We talked a bit about CFT in Episode 15 of the Tech ONTAP Podcast.

There’s also a video demo of Copy-Free Transition available here:

If you’re not familiar with Copy-Free Transition (CFT), then here’s a brief rundown…

What is Copy-Free Transition?

Prior to cDOT 8.3.2, transition to clustered Data ONTAP involved copying your data from 7-Mode to clustered Data ONTAP using one of the many tools available. Architecturally and structurally clustered Data ONTAP is very different from 7-Mode which precluded the ability to upgrade in-place to clustered Data ONTAP.

Essentially, you would use one of the following migration options:

• Use the 7-Mode Transition Tool (7MTT) which leverages SnapMirror to replicate data from 7-Mode to clustered Data ONTAP
• An application-based migration option (such as Storage vMotion from VMware)
• File copy options such as ndmpcopy, RoboCopy, rsync, etc.
• Using Foreign LUN Import

As the above migration options are all methods that copy data, the general term used to describe them is Copy-Based Transition (CBT).

With CFT in 8.3.2 and later, the 7MTT can be used to migrate to clustered Data ONTAP by simply halting your 7-Mode systems, recabling your disk shelves to a cDOT system, then importing the data and configuration into the cluster.

Voilà! Transition simplified!

Why do we want to use CFT?

For starters, you’d use CFT because it allows you to move a large amount of data in a fraction of the time it would take you to copy it. This “big bang” type of transition does require a little extra planning to make sure the clustered Data ONTAP environment is functional post-CFT, but the 7MTT contains extensive pre-checks and assessment capabilities to assist you with your transition planning.

Our live demo at Insight involved a 2-node HA pair with 2 data aggregates and 4 volumes. These volumes served NFS, CIFS and iSCSI data. We were able to finish a live migration in less than 30 minutes, start to finish.

I wasn’t just wearing a Flash costume for giggles – I wanted to emphasize how fast CFT can be.

The guidance from engineering I’ve heard is 3-8 hours, but they’ve been *very* generous in the amount of time built in for cabling the shelves. The time to completion is also dictated by the overall number of objects in the system (ie, number of volumes, qtrees, quotas, exports, etc) and not the size of the dataset. That’s because the 7MTT has to build the configuration on the cDOT system and that takes a number of ZAPI calls. Fundamentally, the message here is that you can do CFT, and roll back if necessary, within a single maintenance window. The main contention for timing here will be how long it takes to re-cable or move disk shelves and reconnect clients.

The actual conversion of the 7-Mode volumes is relatively quick.

Anecdotally, I heard about a customer that did an early preview of CFT with multiple terabytes of data. The cutover after the shelves were moved took 30 minutes. That is… impressive.

That timing is not guaranteed, however – it’s a good idea to plan the 3-8 hours into your window.

Aside from the time it takes to transition, using CFT is also a bonus for people who did not want to purchase/rent swing gear to move data (aside from the minimal amount of equipment needed to bring the cDOT cluster up), or people that simply wanted to keep their existing shelves that they already had support on.

Rather than having to copy the data from 7-Mode to a swing system and then to a cDOT system, you can now simply use the existing gear you have.

The sweet spot for CFT is really unstructured NAS data, such as home directories. These datasets can potentially have thousands or millions of objects with corresponding ACLs. CFT allows for a massively simplified transition of this type of data.

 

What do I need for CFT?

This is a short list of what you currently need for CFT. Keep in mind that the product documentation for the cDOT release is the final word, so always check there.

Currently, you need:

• 7-Mode 8.1.4P4 – 8.1.4P9 (source system)
• Clustered Data ONTAP 8.3.2RC1 or later (destination)
• 7MTT 2.2 or later
• 64-bit aggregates
• A minimally pre-configured* storage virtual machine on the destination cluster – one per vFiler/node
• If using CIFS, a CIFS server on the destination
• An HA pair with no data on it other than the cluster config/SVM placeholders
• Functioning SP modules on the 7-Mode systems

*Minimally pre-configured here means you need a vsroot volume. If CIFS is involved, you need a data LIF, DNS configuration and a CIFS server pre-created in the same domain as the source CIFS server.

If you have a cluster with existing data on it, you can still use CFT, but you have to have a 4 node cluster with 2 of the HA nodes evacuated of all data. Otherwise, 7MTT won’t allow the CFT to continue.

For platform support, please check the documentation, as those are subject to change.

Also keep in mind that this is a version 1.0 of the feature, so there will be more support for things as the feature matures.

What isn’t currently supported by CFT?

• SnapMirror sources and destinations are supported, but SnapVault currently is not.
• MetroCluster is currently not supported.
• 32-bit aggregates are not supported, but can be upgraded to 64-bit prior to running CFT.
• Systems containing traditional volumes (TradVols), but let’s be real – who uses those still? 🙂
• Currently, clusters with existing datasets are not supported (must have an evacuated HA pair)

What happens during the CFT process?

In our demo, we had the following graphic:

In that graphic, we have gear images for automated processes and M for manual processes. The good thing about CFT is that it’s super easy because it’s mostly automated. The 7MTT handles most of it for you – even the halting of the 7-Mode systems.

Here’s a rundown of each part of that flowchart. For more details, check the product documentation and TR-4052. (not updated yet, but should be updated in time for 8.3.2GA)

Keep in mind that during the 7MTT run, each section will have a window that shows exactly what is happening at each phase.

Start CFT Migration

This covers the start of the 7MTT and the addition of the 7Mode HA pair and cluster management LIF to the tool. This does not cover the initial up-front planning prior to the migration, so keep that in mind. That all has to take place before this part.

During the “Start CFT” portion, you will also populate the data LIFs you want to migrate, the volumes and define the volume paths. You will also map the vFilers you are migrating to the SVM placeholders on the cluster.

Planning and Pre-checks

This portion of CFT is an automated task that will look at a list of pre-canned checks of 7-Mode and cDOT to ensure the source and destination are ready. It checks compatibility via a series of pre-canned checks and looks to see if 7-Mode is doing things that are not currently supported in cDOT. If anything fails, the tool makes you correct the mistakes before you continue as not to allow you to shoot yourself in the foot.

Apply SVM Configuration

This automated process will take the information grabbed from 7-Mode and apply it to cDOT. This includes the data LIFS – they will get created on the SVM and then placed into a “down” state to avoid IP conflicts.

Test SVM Configuration

Here, you would manually ensure that the SVM configuration has been applied correctly. Check the data LIFs, etc.

Verify Cutover Readiness

This is another pre-check that is essentially in place in case you did the pre-check a week ago and need to verify nothing has changed since then.

Disconnect clients

This is a manual process and the start of the “downtime” portion of CFT – we don’t want clients attached to the 7-Mode system during the export/halt phase.

Export & Halt 7-Mode Systems

This is an automated process that is done by the 7MTT. It leverages the SP interfaces on the 7-Mode systems to do a series of halts and reboots, as well as booting into maintenance mode to remove disk ownership. We’re almost there!

Cable Disk Shelves

Another manual process – you essentially move the cables from the 7-Mode system to the cDOT system. You might even have to physically move shelves or heads, depending on  the datacenter layout.

Verify Cabling

This is an automated 7MTT task. It simply looks for the disks and ensures they can be seen. However, it’s a good idea to do some visual checks, as well as potentially make use of Config Advisor or the 7MTT Cabling Guide.

Import Data & Configuration

This automated phase will assign the disks to the cDOT systems, as well as import the remaining configuration that could not be added previously (we need volumes to attach to quotas, etc… volumes had to come over with the shelves). This is also where the actual conversion of the volumes from 7-Mode style to cDOT style takes place.

Pre-prod verification

This is where you need to check the cDOT cluster to ensure your transitioned data is in place and able to be accessed as expected.

Reconnect clients

This is the “all clear” signal to your clients to start using the cluster. Keep in mind that if you are intending on rolling back to 7-Mode at any time, the data written to the cluster from here could potentially be lost, as the roll back entails reverting to an aggregate level snapshot.

Commit

This is the point of difficult return – once you do this, the aggregate level snapshots you could use to roll back will be deleted. That means, if you plan on going back to 7-Mode, you will be using a copy-based method. Be sure to make your decision quickly!

Rolling back to 7-Mode

If, for some strange reason, you have to roll back to 7-Mode, be sure you decide on it prior to committing CFT. In our demo, roll back was simple, but not automated by the 7MTT. To make the process easy and repeatable, I actually scripted it out using a simple shell script. Worked pretty well every time, provided people followed the directions. 🙂

But, it is possible, and if you don’t commit, it’s pretty fast.

If you have any questions about CFT that I didn’t cover here, feel free to comment.

Also, check out this excellent summary blog on transition by Dimitris Krekoukias (@dkrek):

http://recoverymonkey.org/2016/02/05/7-mode-to-clustered-ontap-transition/