sureedge migrator white paper - sureline systems€¦ · of benefits like automation, ease of...

SURELINE SYSTEMS 2025 Gateway Place, Suite #480, San Jose, CA, 95110

SUREEDGE MIGRATOR TECHNICAL WHITE PAPER

©SURELINE SYSTEMS 2

OVERVIEW

Enterprise organizations are constantly adopting new paradigms for compute infrastructure such as cloud computing and hyper converged architectures. These transformative technologies promise a wide variety of benefits like automation, ease of management, scalability, risk mitigation and cost savings.

However, what’s often overlooked is the cost and effort of migrating existing deployments into these new environments. At the surface it would seem pretty easy - copy over the system disks and data, boot your new VMs and voila! You’re rolling. In reality, though, migration can be a complex and difficult operation, whether it’s migrating physical systems to newly deployed virtual infrastructures, on-premise systems to the cloud, VMs from one cloud to another, or cloud-based instances down to newly deployed on-site technology. System, application and data migration is a task that can involve significant work, cost and risk.

MIGRATION ISSUES AND OBSTACLES

Each migration is unique, and each system to be relocated can have its own quirks and difficulties; however, some problems apply generically for all emigrant systems. For example, different environments require systems and images be packaged in different formats, and moving between environments means transforming between these formats. And different virtualization technologies support different features related to the virtual environment - storage characteristics and networking capabilities, for example - and require translation when moving systems from one to another. Some environments require “guest tools” - OS-level software in the form of agents or drivers - specific to that environment in order for guests to take advantage of some features, or to operate at all; and moving a system between environments means knowing which tools are required (and which cannot be present) and adding and/or removing tools as appropriate.

Just the process of capturing and transferring a system’s data can be a difficult obstacle. Obtaining complete images of emigrant systems can be intrusive and resource-intensive, causing degradation of normal, sometimes critical operations. Obtaining stable images appropriate for creating a system copy can be a difficult and costly process. While existing backup processes might seem to be a solution, restoring a backup image in the new home can be a project in and of itself, requiring installation and licensing of backup servers, agents, etc. in the new environment. And once images are obtained, transferring them to the new environment can be lengthy, costly and vexing operation, requiring large amounts of data be moved along what’s typically your slowest and most expensive networking link. And unless extra measures are undertaken copying the data via the internet exposes you to data pilferage and other security issues.


Of course, none of these problems is insurmountable in and of itself, but dealing with even a few of them for a single system is at best tedious and prone to errors. And if you’re moving more than a few systems it’s downright drudgery and highly prone to failure, requiring extensive investigations to track down mistakes and then even more manual operations. Even simple things like your system’s network configuration can be a difficult issue: if you’re required to switch from static IP configuration to DHCP or to change subnets or subnet classes, doing it for a single system is viable; doing it for dozens of systems is time a consuming, mind-numbing process rife with potential missteps. Or perhaps you’re planning to change the resources assigned to some or all of the systems, such as tuning up or down the CPU or memory available. Just remembering the characteristics for all the new virtual machines to be created in the new environment can be a challenge; implementing those changes is a slogging toil.

And then there’s the exceptions: those special case systems that need some kind of unique operation to survive the migration or operate properly in its new home. Perhaps it’s a change to its hostname, or special software or drivers that need reconfiguring, or changing anti-virus software, or updating a software license. All these one-off operations exponentially complicate the process, especially large-scale migrations.

Finally, there’s always a clock on the migration. Whether it’s a pre-determined transition time or corporate deadline, the move needs to happen quickly and in a predictable amount of time. Of critical importance is the final cutover, when a critical service - CRM, online storefront, etc. - moves from the old environment to the new. Because it requires some amount of coordination and downtime the cutover must occur quickly and on schedule. Such deadlines and schedules are not likely to be successfully met using a large, complicated, manual migration process.

In order to successfully migrate even a moderate number of systems you want a process that is easily manageable, highly automated and resource efficient. It should be easy to set up and capable of unobtrusively capturing system images; efficiently and securely transferring them to the new environment; automatically determining and performing the required translations; allowing you to specify resource attributes for the new systems (CPU, memory, networking, etc.) and automatically applying them; incorporating special case operations into the automated process; minimizing cutover time and errors; and tracking all stages of these operations, even for a large number of emigrant systems.


ENTER: SUREEDGE MIGRATOR

SUREedge Migrator is a product that enables mobility as an operation by simplifying and automating the process of moving systems across incompatible infrastructures. Migrator automatically handles the complex and error-prone transformations required to get an existing system image running in a new infrastructure - image format changes, driver and agent requirements, mapping virtual machine characteristics, etc. The end-to-end workflow, from configuration to capture to cutover, turns what would be a complex migration process with unpredictable downtime into a series of simple and repeatable steps on groups of servers. It replaces a lot of manual steps and tracking and eliminates a major source of migration errors and failures, while incorporating local customizations and special cases seamlessly into the process.

SUREEDGE MIGRATOR SOLUTION ARCHITECTURE

As shown below the SUREedge Migrator solution enlists two instances of the Migrator software: one in the source environment, where the systems to be migrated currently exist, and one in the target environment to which they are migrating. The two environments can be practically anything: a datacenter with physical systems to be migrated; a private or public cloud; a cluster of virtualization hardware; etc. The source Migrator instance is responsible for capturing and storing images of the emigrant systems and managing their transfer to the target Migrator instance. On the target side, the Migrator instance receives the images from the source site and performs the transformations necessary for the images to run for their new environment, allocating the virtual resources required and standing up the virtual machines that will take over for the source systems.

DestinationEnvironment

SourceEnvironment

Dedup

SourceSUREedgeInstance

DestinationSUREedgeInstance


The two-site architecture gives Migrator many advantages. At a high level it “decouples” the processes of capture, transfer and recovery; this limits the effect of any failures and makes the overall system more resilient and manageable. For example, if the connection between the sites goes down capture operations can continue uninterrupted, rather than causing captures to fail and require repeating because data cannot be streamed. It also means that data transfer between the sites and recoveries can be performed at any time, independent of the state of the source servers or source site overall; so maintenance (scheduled or otherwise), backups, etc. of the emigrant servers can occur without interrupting the overall progress of migration.

Another effect of the two-site architecture is that all inter-site communication occurs between the two Migrator instances, rather than between the source systems themselves and their counterparts at the target site. This means that, independent of the number of systems being migrated, only a single connection between the sites is needed. In turn this has a significant effect on the management and security of the migration process. To start with, it greatly simplifies the setup for migration: only a single connection needs opened and managed within any inter-site firewalls or other security provisions, as opposed to creating and managing one connection (or more) per system being migrated. This single connection also presents a smaller attack surface to bad actors in the network wilderness between the sites. Finally, the single-connection architecture insulates the source systems from exposure to the outside world, keeping them safely behind any firewalls and not subject to direct attack from the wilds of the internet.

Migrator’s decoupled architecture also gives better control over the consumption of bandwidth between the sites. Relative to the local network on each side, each site’s connectivity to the internet is a sparse and costly resource that is shared between many systems and processes. The migration process’ consumption of bandwidth may need to be managed to avoid starving other servers of internet connectivity; for example, limiting migration-related consumption during business-hours, or relegating it exclusively to off hours. Since Migrator only uses a single inter-site connection, there is only one schedule to define to avoid devouring all the bandwidth, rather than trying to formulate and implement a complex schedule to limit each emigrant server’s consumption and its relation to overall migration bandwidth usage.

Furthermore, if inter-site data transfers were performed as part of the capture process, it would mean that in turn capture times would be restricted by the bandwidth-usage schedule. However, the best points-in-time for capturing a server’s image are not really related to when it’s best to use internet bandwidth. By decoupling capture from transfer you can still get the best-quality point-in-time images of your serves and efficiently use your internet connection, rather than choosing over the other.


Another advantage of SE-M’s architecture is that only the Migrator instance is running at the target site until a recovery is actually started. Other architectures require that a virtual instance run at the target site for each server being migrated to receive the images being transferred. In on-demand environments, such as public clouds, this means running up CPU and memory costs for an emigrant system before you ever bring it up, just to receive data from the source site. With Migrator you’ll only pay for the target-side Migrator instance to transfer data; compute and memory costs for the migrating servers start only after you choose to recover them.

A SUREEDGE MIGRATOR INSTANCE

Looking more closely, instead of a common “agent-based” architecture where software and drivers must be deployed on every system to be migrated, SUREedge Migrator simply deploys as two virtual machines: A Migration Controller (“MC”) system which handles scheduling and management and presents the user interface; and the Store Controller (“Store”) which manages storage of image data, receiving system images and saving them in deduplicated form and effecting transfers to other Migrator instances. The two components, MC and Store, work in tandem to perform all migration operations.

The MC VM is responsible for the management and organization of the migration process, as well as presenting the Migrator UI. It stores all the information related to which systems are to be migrated, how they are performed, parameters for recovery, their migration status, etc. It kicks off and controls all operations, overseeing and logging their progress, and generates graphs and reports so that large scale migrations can be easily followed and tracked. Through the MC’s job tracking mechanisms any failures can be easily spotted and investigated, leading to quick remediation and faster migration progress.

MC

Store

Control&Coordination

Dedup


The other half of a Migrator instance is the Store virtual machine which is responsible for data movement and management. On the source side, the Store VM is responsible for receiving image data captured from the source systems, and for efficiently transferring them to the destination Store. Each Store VM keeps all received data in it’s deduplicated storage area, or “dedupe store”, which significantly reduces the storage needs for keeping capture images. This deduplication allows Migrator to make all captured images available for recovery, rather than just the latest image captured, which can be useful when testing the migration process for a set of servers, debugging issues that come up during recovery, etc. It also means that capturing an image that turns out to be unusable doesn’t mean a full recapture is needed; you can simply go back to an earlier image.

Migrator’s deduplication algorithms are based on the Tiger hash. <details forthcoming> In addition to the advantages of Tiger, Migrator use of its deduplication hash makes it even more efficient. Migrator uses lookups before transferring any image data between instances, making each Store part of a global deduplication.

Using deduplication means the Store VM does not require storage equivalent to the sum of all systems to be migrated. As described, deduplication vastly reduces the storage required, and the more systems being migrated the more efficient deduplication becomes. Also, it is a rare circumstance for a very large number of systems to be “in flight” at a given time; typically in a large migration project the systems will be divided into groups of systems to be migrated together in waves. Usually only a few groups will be migrated simultaneously, and once those are completed, a few more groups are started, and so on until all systems


are migrated. The Migrator Store VM only needs enough storage to save the (deduplicated) images for the systems that are actively being migrated; it can reclaim space for systems already migrated, thus vastly reducing the storage resources required.

In addition to deduplication, the Store protects system images by encrypting them before they are saved in the dedupe store. Data are never stored persistently in any way in unencrypted form. Migrator uses AES-256 encryption algorithms (CBC mode) for maximum protection of the system image data. Data are also compressed using Google’s Snappy algorithm, further reducing the storage needs. Snappy is a very fast and efficient algorithm for data compression and along with

deduplication significantly reduces Migrator’s storage and bandwidth requirements.

Keeping images in a dedupe store also has another advantage: it means that a single image can be recovered multiple times without retransmitting the data between the sites. This give great flexibility and freedom to bring up copies of servers for any purpose, and is especially useful to test the migration process before committing to a cutover. In other architectures bringing up a migrated server “consumes” the server image, and bringing up another copy requires capturing and transferring a new image; this makes using a recovered server for testing (as well as any errors or failures in recovery) very costly in terms of time and resources. With SUREedge Migrator, to create a new server you simply spawn a new recovery operation, or even several new recovery operations simultaneously. These recovered servers can then be used for testing, refinement of the recovery process, practicing final cutover, etc. without the extreme expense of recapture or retransfer.

Once the Migrator instance’s two virtual machines have been deployed on each side the migration process can begin by identifying the servers to be migrated. Most notably no software needs to be installed on servers to be migrated. Migrator does not use long-running operations that require intrusive drivers on the emigrant servers, or that software of any kind be installed before you can migrate. This massively reduces the effort to prepare for a migration; imagine if in order to migrate hundreds of servers you had to install agents on each system. This would require hours of effort to perform the individual installs, or developing and configuring a complex system of automated installation. With SE-M, you simply identify the servers to migrate, and you’re ready to go.

StorageEngine

Storage Storage Storage Storage Storage StorageStorageStorage Storage Storage Storage Storage StorageStorage

DeDu

pe

Compressio

n

Encryptio

n

Replica

tionChunk

Store

HashDB

F I L EFullFiles

Incremental

NamespaceCatalog


SUREEDGE METHODOLOGY

CAPTURE

The first step in the migration process is to capture a complete system image of each emigrant server. Migrator uses snapshot technology on the source server to make a consistent image available for capture; this makes the captured image much more likely to be viable as the basis for recovery than an image based on a constantly changing, “live” source. This is also a significant savings in resources over other methods which constantly “drip” every data update on the source server across the wire and require setting up additional software and kernel drivers to capture these deltas. On Linux servers the SUREedge Migrator capture process uses LVM to create consistent images, when available. On Windows servers it uses built-in VSS technology to create images for capture. This has the advantage of allowing applications on the system to stabilize their own data beyond what the operating system can do, further ensuring that the captured image is clean and consistent. In cases where no snapshot technology is available for use Migrator will fall back to capturing a live system image.

To obtain and transport the system image SUREedge Migrator uses unique capture technology to obtain and stream the image data to the source site Migrator Store. The filesystem-based, file-delimited block-level capture process captures data and metadata for all files in a highly efficient manner: unused portions of the file system are ignored, sparse areas in files are skipped, complete file metadata is captured, etc. This unique patented process speeds the capture operation, minimizes impact on the source server and maximizes the deduplication capabilities of the Migrator Store.

Migrator also supports “sync” operations which only capture and stream file data that has been changed since a prior capture or sync, making the capture process even more efficient. This is similar to an incremental backup. Using sync operations can significantly reduce the capture time and impact on the source systems when a prior complete image is already present in the dedup store. Deduplication and compression further reduce the size of a sync-based image, in turn reducing storage overhead and bandwidth requirements to get the changed data across to the recovery site.


Migrator also supports another important feature: customized pre-capture and post-capture operations. These are scripted operations that you can add to the capture process that will be performed prior to and just after a capture is performed. This allows for a wide variety of customizations of the migration process to be added as needed to address issues and incorporate special cases. For example, it’s common to turn off virus scanning protection during backup operations in order to reduce the time required and to reduce impact on the server. With Migrator this step can be done automatically for every full or sync capture of a server or group of servers. Or, perhaps you have a custom application that does not participate in any OS-level image stabilization like VSS, but needs to freeze its data before creating a snapshot image; this can easily be handled by adding Migrator pre- and post-capture operations.

It’s important to note that by having a single dedupe store at the source site, data deduplication is applied across all servers to be migrated from the site. This greatly increases the efficiency of the dedupe process because, as opposed to architectures where individual systems are streamed directly to the target site, Migrator eliminates duplicate chunks across all source images. When combined with the unique hybrid capture algorithm this means that if, for example, you had fifty servers running Windows, you would in effect only store approximately a single copy of the operating system components. This represents a massive savings in storage resources.

TRANSFER

In turn, deduplication also greatly reduces transfers between the sites. When preparing to transfer a data chunk from a system image to the destination site, Migrator checks to see if the chunk already exists in the target dedupe store. If the chunk is already there there’s no need to transmit it again. Thus the same savings attained in the source storage is also saved in terms of transfer bandwidth. Again, if you have fifty copies of a Windows OS at the source, you will in effect only transfer one copy of it to the target site, and only transfer it one time - a huge savings in inter-site bandwidth. And: this deduplication occurs globally, across all Migrator instances that are transferring data. So if, for example, you had multiple source sites connected to a common target site, transfers are deduplicated across all the source sites. So: if you had 150 copies of Windows across three source sites, in effect only one copy would be transferred to the target site from any of the source sites, rather than one copy from each.

When data does actually need to be transferred to the target site it’s done in a highly efficient, resilient and secure manner. All data is transported in encrypted and compressed form, making it secure from tampering or pilferage and using a minimum of network bandwidth. Like all Migrator operations, there are


extensive error handling and retry mechanisms built into the data transport algorithms so that transient downtime or connectivity issues (which are distressingly common) do not cause image transfers to fail.

In the case of extended connectivity downtime, even if a transfer were to fail the impact is minimal: since the image is present in the source-side store, there is no need to recapture the image and drain more resources from the source system, since only transfer phase needs to be restarted. And since the transfer process uses deduplication to avoid sending duplicate data, no chunks that successfully arrived at the target side as part of the failed transfer will be sent again; the transfer effectively picks up where it left off.

RECOVERY

When an image arrives at the target side Migrator instance it is immediately available for use in recovery, where it is transformed into whatever format is needed to run in the target environment. There are an extensive number of transformations that Migrator handles for you automatically.

All storage is converted into the appropriate format for the target environment. For example, if you are migrating from VMware to Hyper-V, Migrator automatically transforms your system’s disks in VMDK format to VHDX format required by the target environment. Similar transformations are performed when migrating to public or private clouds, or into hyper converged infrastructure. Migrator even handles capturing physical devices on non-virtual systems (P2V). While there are some tools out there to perform all of these conversions, they are just that: tools, which are used by-hand for each device or virtual server, requiring you know exactly what you need and what options to use in your specific case. This becomes a tedious manual process that involves a lot of experimentation and introduces errors and failures. With Migrator all of this is taken care of automatically.

Another element of storage conversion is the presence of a logical volume manager on the source system (for example, LVM on Linux or Dynamic Disks on Windows.) In many cases a volume manager is used to address some characteristic of the underlying storage: striping to increase performance, mirroring or other RAID levels to increase redundancy, etc. However, in virtualized environments these issues are handled in the underlying virtual storage layer doing its own RAID; and in fact doing another level of storage virtualization on top it can result in decreased performance, or extra (costly) redundancy. Therefore in most cases you will want to “unwind” your logical volume management as part of the migration process. SUREedge Migrator will do this for you, turning your volumes into virtual disks in the environment’s virtual storage layer and using them directly. (Or, there’s the option to leave any logical volume management in place.)


Many virtualization environments require that VMs run “guest software” in order to run efficiently (or at all). These are rarely compatible across platforms - for example, VMWare’s “guest tools” are pointless in a VM in a Hyper-V environment - and in some cases having the wrong tools present will prevent the system from running at all. Addressing this requires removing software and drivers from the system images, knowing which tools the target environment requires, determining the correct versions for each guest, and installing them. Doing all this software manipulation is tricky and tedious in and of itself, especially without disrupting the source server. Doing it many times is drudgery and fraught with the opportunity for mistakes. SUREedge Migrator takes care of all this for you, automatically.

There are other transformations that can optionally be applied during migration. For example, Migrator allows you to change the allocation of virtual resources - such as virtual CPU or memory - as part of the migration process. This allows you to “right-size” your systems as part of the migration process, rather than having to schedule additional downtime or inaccessibility to do it.

Another common issue is the network configuration of emigrant systems. In some cases, the network environment at the target site will be significantly different than the source site, from the method of getting an address (DHCP or static configuration) to the actual IP address and other networking parameters (gateway, name servers, etc.) which are tedious to change on a per-system basis. Migrator will reconfigure the networking parameters for emigrant systems, vastly simplifying the process. It even supports bulk editing of network configuration, so you can easily change a large number of systems’ configuration; you can, for example, change the subnet and mask for a large group of servers, say from 192.168.x.x to 10.y.y.y, in a single operation, effectively “lifting and shifting” them into a new subnet in a single operation.

Then there are the features and attributes specific to a given virtualization environment that must be accounted for. Different virtualization products, clouds, and hyper converged infrastructures support different kinds of features, like compute zones, storage classes, security groups, disk types, etc. Migrator knows about all the options available in each environment, and allows you to specify values for the target environment and automatically accounts for and performs transformations to account for them. So, for migrating servers you can choose to convert disks to thin-provisioning, specify virtual network connections, and/or assign the security group membership and have it apply automatically, every time the system is recovered in the target environment.

In addition to specifying transformation attributes you can also add your own operations to the recovery process by specifying a post-recovery operation. Like the pre- and post-capture operations these are scripted actions that you can specify that Migrator will automatically perform on a recovered system after


it is transformed and brought up in the new environment. And like pre- and post-capture operations this gives great flexibility for customizing the migration process. For example it can be used to remove or replace virus protection software that’s inappropriate in the new environment, or to change a host’s name, or to perform a post-migration transformation for a custom application. And these actions can be performed automatically by Migrator every time a server is recovered, eliminating any “by-hand” operations or changes that potentially introduce mistakes or increase migration time and cost.

The transformation process is handled in a few different ways. Any storage “format” changes, including changing/removing logical volume management, are done first when the target-side storage resources are created and then populated with the contents of a captured image. Once all storage has been created on most platforms they are then temporarily attached to a “proxy” system image which performs other operations: adding/removing drivers or agents and changing other system configuration required before the first boot of the actual copy of the emigrant system. These proxies are in fact small VMs in the target environment, created at the time of recovery explicitly for this purpose, and only exist for the duration of the transformation. Once the proxy has completed its work the emigrant system’s target-side counterpart VM is created as defined by the recovery parameters and the storage containing the transformed system image is attached; it is now ready to be booted for testing or to take over for the source-side system.

CUTOVER

Of particular importance to the migration process if the final cutover for a system, service or application. This is the point where the target-side copy of a source-side system takes over operations and becomes the canonical version for that system’s services and operations. A typical migration tactic is to first bring up a copy of an emigrant system based on a full-capture image and test that the copy operates properly. Any issues that arise can be addressed by fine-tuning the recovery parameters (changing resources or recovery parameters, adding recovery operations, etc.) and the process can be repeated until the resulting target-side copy operates as needed.

Once the recovery parameters are satisfactorily defined the final cutover step begins by placing the source system’s application(s) in a frozen or read-only mode so that no data changes can occur for the duration of the cutover time. The applications need not be shut down, just placed in a state so that no changes that would be required to be present on the target side can occur; for example, a fileserver could place its shares in read-only mode, or an application can suspend changes but still support queries. Once in this state an incremental image capture is kicked off, and the subsequent transfer makes the frozen image available at the target side. Finally a last recovery is performed, transforming the final system image and


bringing it up at the target site. At this point the services are “thawed” on the target-side system; it is now ready to take over for the original.

Of course, of critical importance in this process is the time taken between the freeze of services at the source side and the thaw on the target side. During this time the services are in read-only mode or, depending on the service, completely unavailable. While this can be a more serious issue for some applications than others, in nearly all cases it’s desirable that this time be reduced as much as possible. To keep this critical cutover time to a minimum, SUREedge Migrator has several features and options.

At the source the potentially time-consuming task is the capture of the latest, frozen image. The obvious time reduction strategy is to make sure this is done as a sync capture, and not a full-image capture; this can reduce the capture time by upwards of 90% right off the top. However, the size of an incremental, sync-based capture grows as data changes occur, so to keep the size (and in turn capture and transfer times) to a minimum it’s best to reduce the time since the last capture. The best practice is to perform a sync capture just prior to placing the system in read-only mode, which would result in the smallest possible incremental capture size while not extending the window of time that the application is in read-only mode.

On the target side the longest-running operation is usually extracting an image from the target deduplicated store and placing it into the transformed virtual storage. This is because the image in the virtual storage is being reconstituted from scratch, in-effect copying the entire system image from the Store into the virtual storage, even for an incremental image. To reduce this time Migrator supports image caching which maintains a copy of the latest captured system image in virtual storage at the target site, and updating it automatically as new images arrive. Most importantly, it can incrementally update the cached image, extracting only the changed files from the store and updating them in the cached image; think of it as an “incremental restore” which, like incremental capture, can massively reduce the image reconstitution time. When combined with incremental capture and deduplicated transfer this can reduce the critical cutover window from hours to just a few minutes.

sureedge migrator white paper - sureline systems€¦ · of benefits like automation, ease of...

Documents