strategies for migrating workloads from vmware to openstack
TRANSCRIPT
Migrating workloads from VMware to
OpenStack
Alessandro Pilotti | CEO @ Cloudbase Solutions
Agenda
+ Migration strategies
+ Coriolis
+ Migrations
+ Replicas / DRaaS
+ Demo
+ Workload testing / validation
The context
+ Companies move to the next dev / ops generation
+ Physical Servers -> VMs -> IaaS -> Containers -> Serverless
+ Rewrite LoB next gen applications while retaining investments on existing
generation
+ Improve TCO
Why migrating workloads?
+ In general: improved TCO
+ New on-prem cloud infrastructure
+ New on-prem hardware
+ On-prem to public cloud
+ Public cloud to on-prem
+ On-prem redeployment
Rearchitect
Pros
Apps become scalable
Apps become high available
Decoupling
Improved development and testing methodology (legacy spaghetti code -> CI/DC)
Cons
Expensive
Time consuming (most corporate legacy apps spawn across many years of development)
Users learning curve
Repurchase
Pros
No need to write it or mantaining yourself!
Typical example: move to a SaaS
Pay as you go
Cons
Customizations to fit the requirements
Data migration from can be expensive / time consuming
Users leaning curve
Retire
Pros
Retire unused software following an auditing
Cons
None, housecleaning is a good thing
Retain
Pros
Not everything can migrated or can be improved
Cons
Not everything can migrated or can be improved
Replatform
Examples:
Move apps to a PaaS, e.g. an ASP.Net site from a local IIS server to Azure Web Sites
Move a SQL Server database to OpenStack Trove
Wrap legacy apps in containers and deploy them via Kubernetes / Magnum
Wrap legacy apps in a PaaS (e.g. Azure Service Fabric on OpenStack)
Pros
Apps become at least partially scalable / high available without a full rewrite
Reduced footprint (no dedicated servers needed)
Cons
Lots of hacking involved and not all applications can fit this model
Rehost (lift and shift)
Move VMs or bare metal hosts to the new cloud
Examples:
VMware to OpenStack, AWS to Azure, AWS to OpenStack, etc
Pros:
Servers are “black boxes”, no need for changes
Fastest option
Cons:
Won’t take full advantage of cloud model (e.g. scalability)
Target cloud solution might not have host level HA, so HA might be lost from source environment
Lots of steps
+ virtual disk format
+ synthetic kernel drivers (VirtIO, VMware tools, LIS, etc)
+ initrd
+ SELinux
+ PCI ids / network configuration
+ Provisioning agents (cloud-init / cloudbase-init, Azure WALinuxAgent, etc)
More on rehosting
+ Easy when moving between homogeneous architectures / platforms
• e.g. OpenStack + KVM to OpenStack + KVM
+ Tricky when moving between architectures / platforms:
• e.g. VMware vSphere to OpenStack + KVM,
Introducing Coriolis – Migration as a Service
+ Fully automated lift-and-shift migrations from and to any cloud /
virtualization solutions
+ Scalable: do 1 migration or 1000 at a time
+ Rest API for full automation
+ Keystone identity management
Coriolis architecture
OpenStack components
+ Oslo.*
+ Keystone
+ Barbican
+ Swift
Supported clouds / virtualization solutions
+ OpenStack
• KVM, Hyper-V, ESXi, Xen
+ Azure
+ AWS
+ VMware vSphere
+ Hyper-V and SCVMM
+ XenServer
+ oVirt + KVM
+ Oracle VM
+ GCE (soon)
Task based execution
+ Tasks are actions executed sequentially or in parallel based on
dependencies.
+ Tasks are resilient for transient failures and atomic
+ Examples:
• http://paste.openstack.org/show/602940
• http://paste.openstack.org/show/jvUV17eFqQVf2fGCuwIT
• http://paste.openstack.org/show/OtO8QT4k71jkIMIAgf7g
OS morphing
+ Needed when a guest instance moves between different platforms and
architectures
+ A worker VM detects the OS type / distro
+ Actions specific to that OS and target platform are executed (e.g. add VirtIO
driver, add cloud-init, etc)
Supported operating systems
+ Debian 7+
+ Ubuntu 12.04+
+ SUSE SLE 11+
+ RHEL / CentOS / Oracle Linux 6+
+ Fedora
+ OpenSuse
+ Windows 7, 8, 8.1, 10
+ Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016 (including Nano Server)
Coriolis REST API
Coriolis CLI
CLI is based on cliff, like the OpenStack client
migration cancel Cancel a migration
migration create Start a new migration
migration delete Delete a migration
migration list List migrations
migration show Show a migration
Coriolis CLI
replica create Create a new replica
replica delete Delete a replica
replica disks delete Delete replica target disks
replica execute Start a replica execution
replica execution cancel Cancel a replica execution
replica execution delete Delete a replica execution
replica execution list List replica executions
replica execution show Show a replica execution
replica list List replicas
replica show Show a replica
migration deploy replica Start a new migration from an existing replica
Coriolis GUI
+ Single page application
+ ReactJS
+ Open Source
What about downtime?
+ Coriolis introduces a DRaaS feature (disaster recovery as a service) called
replica
+ If the source cloud allows it, data is backed up incrementally to the target
while the source VM is running
+ Migration is performed as the last step directly on the target cloud
+ No need for the source VM to be available (useful in case of disaster)
How does it work?
+ Examples of backup technologies used:
• Cinder Backup
• VMware Change Block Tracking (CBT)
• Windows VSS (Hyper-V)
+ Some options like CBT and VSS allow app consistency
+ Stage 1: replica
+ Stage 2: migration
Coriolis DemoVMware to OpenStack
Validation and testing
+ Replica volumes can be snapshotted and duplicated to perform a test
migration
+ This allows fully automated Integration Testing to ensure the VMs work as
expected
+ Replica volumes are not changed: replicas can be executed in the meantime
+ Examples: test websites and databases
Get in touch
Twitter: @cloudbaseit
http://www.cloudbase.it/coriolishttp://ask.cloudbase.it
Questions?