Moving To The Cloud – Part One

As a company primarily comprised of engineers, we at CDS can be fairly skeptical of the hype surrounding “the cloud,” mostly due to the tendency for marketers and thought leaders to promote any new fad as perfect for any application under the sun.

But what if you’ve determined that certain elements of your fibre channel infrastructure – particularly ones that aren’t IOPS-intensive – really *could* benefit from a move to the cloud? After all, there are many use cases that justify such a move. The Cloud providers have plenty of propaganda to entice you to do so, and I won’t repeat that here. So let’s say that for whatever reason, you are finally convinced to do the move. How are you going to actually do it?

The days of bringing your apps down overnight to pack up the data and move it somewhere else are, of course, long gone. With the amount of data most small businesses and enterprises carry today, it could take days or even weeks to get the data moved to AWS, Microsoft Azure, Google Cloud Platform or IBM Cloud.

Most companies are connected to fast pipes these days, but even at a constant 50Mbps it will still take you over 18 days to move 10TB of data. Shutting down operations and sending everyone on vacation for a week or two might sound good to some of your employees, but it’s not really practical from a business standpoint.

So if you’re migrating data, you know you have to do it while your business is operational – meaning clients will be writing to your storage at the same time you’re trying to migrate the data. Obviously, there are more than a couple of issues with this.

First, you have to track data changes to the storage while moving it. Most storage isn’t really set up for this natively, so most migration solutions want you to install some software on each of your clients to track writes. Do you have any apps running on Linux? Solaris? OS/2? AIX? How about NetWare (that’s right, we said it)? Are you sure the migration software is available for each of these OS’? And even so, do you really want to install more software on these machines?

Secondly, can your clients even handle the extra load of the write-splitter?

You might say “sure, my environment is solid and installing some more software won’t hurt.” On the other hand, you might say “no thanks – my environment is being held together by paper clips, toothpicks and Elmer’s Glue as it is.”

If you’re dealing with the latter case, where you have a tricky SAN environment, migrating data without the proper tools will require complex planning and a great deal of human effort. What is the chance of error when migrating 10TB of data supporting 40 different app servers, 1000 fibre channel paths and who knows how many users? Well, if you’d rather not spend time awake at night thinking about specific percentages, we can certainly make it easier on you.

Cirrus Data has a patented technology called TDI that allows us to migrate your data volumes to the cloud while the environment is live, as clients are writing to it. You don’t have to install any software, and if you can install a telephone answering machine, you should be able to install the migrator. If you don’t trust your admins to install a phone answering machine, we can certainly assist.

Everything is self-discovered. We don’t ask how many LUNs you have, how the LUNs are associated with the host. We display such an accurate representation of your SAN in our GUI that you can use the product just to help you manage/trouble shoot your SAN if you wish. We can show you if you have LUNs zoned to the wrong host, if you still have a LUN that you were testing still assigned to the test server, etc. We discover the LUNs, we discover the destination, and will try to match up the LUNs for migration between legacy and new storage.

We’ve had a lot of success in the past two to three years in the Enterprise space with IBM’s service team, Fujitsu, etc. migrating live data from old storage to new storage and have successfully concluded many migration projects using our DMS solution – all with no downtime until cutover.

Now we’re offering this solution for cloud migration. We’re tremendously excited about it, and we’ll tell you all about it in our next blog post after the holiday weekend.

There is no other solution in the world can do this. Plug our DMS into your live SAN environment, identify SAN LUNs that are already discovered, pair them up with the Destination LUNs from the Cloud, define the migration sessions (when to migrate, how aggressive, etc), and let it go. Once you’re hooked up and migrating, it may take an hour, a day, a week, whatever. The important thing is: you keep your apps live and your clients usually don’t even know migration is occurring. Our migrator keeps tracks of all the changes to the migrated blocks and continually syncs those changes until you are ready to cut-over to the cloud.

We’ll cover the details next week in part two of this post. Until then, have a safe and happy July 4th holiday!

Cloud and rainbow image designed by Freepik