SlideShare a Scribd company logo

User Transparent Service Migration to the Cloud

•Download as PPTX, PDF•
•
Tim Mackey
Tim Mackey

Tim Mackey presented on migrating virtual machines and services to the cloud transparently without downtime. He discussed using Packer to build templates from existing virtual machines or ISO images and then migrate them to CloudStack or OpenStack. Key steps included taking snapshots, copying to shared storage, reconfiguring networking, running cleanse scripts, and importing as templates. With these tools, he was able to migrate a live Piwigo service to a new topology in the cloud within 10 minutes while maintaining network connectivity.

1 of 28
CloudOpen – Seattle 2015 Clone existing VMs to CloudStack/OpenStack templates without user downtime Transparent Service Migration to the Cloud
#whoami Name: Tim Mackey Current roles: XenServer Community Manager and Evangelist; occasional coder Cool things I’ve done • Designed laser communication systems • Early designer of retail self-checkout machines • Embedded special relativity algorithms into industrial control system Find me • Twitter: @XenServerArmy • SlideShare: slideshare.net/TimMackey • LinkedIn: https://www.linkedin.com/in/mackeytim • GitHub: https://github.com/xenserverarmy
Define “VM Migration” What people think • VM moves from source host to destination Why it doesn’t work “to the cloud” • Incompatible host micro-architecture • Lack of control over networking • Do we really want a VM_HALT? • Long distance ARP Really need “template migration” Template Template Template
CloudStack view of Templates
Template Management in CloudStack My first template • Existing VM or appliance in VHD format – compression optional • Need to have HTTP server • Set secstorage.allowed.internal.sites if private cloud Creation options • Register template in UI • Templates  Register Template • Upload using registerTemplate API • http://cloudstack.apache.org/docs/api/apidocs-4.5/user/registerTemplate.html • Clone from CloudStack instance • Stop instance  View Volumes  Create Template
Key Template Attributes Obvious • Hypervisor • Operating system type • Zone Not so obvious • IsDynamicallyScalable  Hypervisor tools • PasswordEnabled CloudStack sets root pwd • SSHKeyEnabled  Can post configure • RequiresHVM  Defines virtualization mode
VM Password and SSH Key Management Challenges Obtain information from Virtual Router • IP is obtained from leases • Scripts use wget • Assumes sysinit not systemd What to fix – varies by OS? • CentOS 7 defaults to curl not wget • CentOS 7 is systemd  need unit files • CentOS 7 may use NetworkManager
OpenStack view of Templates
Template Management in Horizon and Glance My first template • Existing VM or appliance in hypervisor specific disk format • XenServer: VHD format with file named 0.VHD and tgz Creation options • Register image in Horizon • System->Images->Create Image • Upload using Glance API • http://docs.openstack.org/developer/glance/glanceapi.html • Clone from running instance • Compute->Instances->Create Snapshot
Key Image Attributes Obvious (x-image-meta-) • Owner • Flavor information (Disk and RAM) • Region Not so obvious (x-image-meta-property) • hypervisor_type  Xen for XenServer • vm_mode PV vs. HVM • os_type  Linux or Windows for swap space
Handling Critical Initial VM Configuration Obtain information from instance configuration drive • ISO 9660 or VFAT drive assigned to instance at boot • Supported with libvirt, XenServer, vSphere and Hyper-V • Works with custom scripts and cloud-init Using a configuration drive • Specify per instance on nova boot --config-drive true • Force for all instances in nova config force_config_driver=true • Pass both meta information and userdata
How the tooling works
Packer is Awesome!! http://packer.io
Core Packer Concepts Builder • Responsible for creation of VM image • Connects to virtual infrastructure • Default supports vSphere, OpenStack, AMI, VirtualBox, QEMU, Docker • No XenServer  needed to fix that ;) Provisioner • Runs post-build activities Post-Processor • Takes VM image artifact and transforms it • In our case upload to CloudStack or OpenStack  needed to fix that too ;)
Key Activities Occurring During Template Build from ISO 1. Download ISO into ISO SR (if not already present) 2. Attach ISO to VM object and boot 3. Instruct installer to user kickstart file 4. Installer does its thing and shuts VM down 5. Upon shutdown, swap installer ISO for XenServer tools ISO 6. Install ISO and shutdown 7. Detect shutdown and run Provisioners 8. Export and import into the cloud as template
xenserver-iso builder Creates a new XenServer image from an ISO Key parameters • Host connection • ISO location • Boot commands Artifact output type • xva, vdi_raw, vhd, vhd_raw Known limitations • Linux only (uses SSH) • Requires NFS shared storage for export
xenserver-vm builder Creates a new XenServer image from existing running VM Key parameters • Host connection • VM name • Cleanse command • Cleanse scripts Artifact output type • xva, vdi_raw, vhd, vhd_raw Known limitations • Linux only (uses SSH) • Requires NFS shared storage for export
cloudstack-xenserver post-processor Creates a new CloudStack template from xenserver builders Key parameters • CloudStack API keys • Zone, OS type • Script configuration Artifact input • xenserver-iso, xenserver-vm
openstack-xenserver post-processor Creates a new OpenStack Glance image from xenserver builders Key parameters • Keystone URL and credentials • Project name, region, and instance name • Script configuration Artifact input • xenserver-iso, xenserver-vm
Key Activities Occurring During Service Migration 1. Snapshot of existing VM to minimize downtime 2. Detect if VM is PV or HVM and flag accordingly 3. Copy snapshot to NFS SR to collapse any snapshot chains 4. Connect primary network to HIMN to ensure no machine collision 5. Use VNC to reconfigure network and connect to XenServer DHCP server 6. Copy and run cleanse scripts which shutdown clone when complete 7. Detect shutdown and run Provisioners 8. Export and import into cloud as template
10 minutes to move a live service to the cloud (network willing) … Demo time ….
The Service to Migrate – Piwigo http://piwigo.org
The Original Topology
The Cloud Topology with Original Data Store Intact
My Cloud Bringing “Migration” all Together with an ADC Users
Confirm the Migration and Iterate 1. Verify service migrated correctly 2. Iterate and resolve any issues 3. Scale the service • Let’s add more capacity 4. Add service to original load balancer • Don’t forget to adjust session weights 5. Decommission original service
Questions?
User Transparent Service Migration to the Cloud

More Related Content

User Transparent Service Migration to the Cloud

  • 1. CloudOpen – Seattle 2015 Clone existing VMs to CloudStack/OpenStack templates without user downtime Transparent Service Migration to the Cloud
  • 2. #whoami Name: Tim Mackey Current roles: XenServer Community Manager and Evangelist; occasional coder Cool things I’ve done • Designed laser communication systems • Early designer of retail self-checkout machines • Embedded special relativity algorithms into industrial control system Find me • Twitter: @XenServerArmy • SlideShare: slideshare.net/TimMackey • LinkedIn: https://www.linkedin.com/in/mackeytim • GitHub: https://github.com/xenserverarmy
  • 3. Define “VM Migration” What people think • VM moves from source host to destination Why it doesn’t work “to the cloud” • Incompatible host micro-architecture • Lack of control over networking • Do we really want a VM_HALT? • Long distance ARP Really need “template migration” Template Template Template
  • 4. CloudStack view of Templates
  • 5. Template Management in CloudStack My first template • Existing VM or appliance in VHD format – compression optional • Need to have HTTP server • Set secstorage.allowed.internal.sites if private cloud Creation options • Register template in UI • Templates  Register Template • Upload using registerTemplate API • http://cloudstack.apache.org/docs/api/apidocs-4.5/user/registerTemplate.html • Clone from CloudStack instance • Stop instance  View Volumes  Create Template
  • 6. Key Template Attributes Obvious • Hypervisor • Operating system type • Zone Not so obvious • IsDynamicallyScalable  Hypervisor tools • PasswordEnabled CloudStack sets root pwd • SSHKeyEnabled  Can post configure • RequiresHVM  Defines virtualization mode
  • 7. VM Password and SSH Key Management Challenges Obtain information from Virtual Router • IP is obtained from leases • Scripts use wget • Assumes sysinit not systemd What to fix – varies by OS? • CentOS 7 defaults to curl not wget • CentOS 7 is systemd  need unit files • CentOS 7 may use NetworkManager
  • 8. OpenStack view of Templates
  • 9. Template Management in Horizon and Glance My first template • Existing VM or appliance in hypervisor specific disk format • XenServer: VHD format with file named 0.VHD and tgz Creation options • Register image in Horizon • System->Images->Create Image • Upload using Glance API • http://docs.openstack.org/developer/glance/glanceapi.html • Clone from running instance • Compute->Instances->Create Snapshot
  • 10. Key Image Attributes Obvious (x-image-meta-) • Owner • Flavor information (Disk and RAM) • Region Not so obvious (x-image-meta-property) • hypervisor_type  Xen for XenServer • vm_mode PV vs. HVM • os_type  Linux or Windows for swap space
  • 11. Handling Critical Initial VM Configuration Obtain information from instance configuration drive • ISO 9660 or VFAT drive assigned to instance at boot • Supported with libvirt, XenServer, vSphere and Hyper-V • Works with custom scripts and cloud-init Using a configuration drive • Specify per instance on nova boot --config-drive true • Force for all instances in nova config force_config_driver=true • Pass both meta information and userdata
  • 14. Core Packer Concepts Builder • Responsible for creation of VM image • Connects to virtual infrastructure • Default supports vSphere, OpenStack, AMI, VirtualBox, QEMU, Docker • No XenServer  needed to fix that ;) Provisioner • Runs post-build activities Post-Processor • Takes VM image artifact and transforms it • In our case upload to CloudStack or OpenStack  needed to fix that too ;)
  • 15. Key Activities Occurring During Template Build from ISO 1. Download ISO into ISO SR (if not already present) 2. Attach ISO to VM object and boot 3. Instruct installer to user kickstart file 4. Installer does its thing and shuts VM down 5. Upon shutdown, swap installer ISO for XenServer tools ISO 6. Install ISO and shutdown 7. Detect shutdown and run Provisioners 8. Export and import into the cloud as template
  • 16. xenserver-iso builder Creates a new XenServer image from an ISO Key parameters • Host connection • ISO location • Boot commands Artifact output type • xva, vdi_raw, vhd, vhd_raw Known limitations • Linux only (uses SSH) • Requires NFS shared storage for export
  • 17. xenserver-vm builder Creates a new XenServer image from existing running VM Key parameters • Host connection • VM name • Cleanse command • Cleanse scripts Artifact output type • xva, vdi_raw, vhd, vhd_raw Known limitations • Linux only (uses SSH) • Requires NFS shared storage for export
  • 18. cloudstack-xenserver post-processor Creates a new CloudStack template from xenserver builders Key parameters • CloudStack API keys • Zone, OS type • Script configuration Artifact input • xenserver-iso, xenserver-vm
  • 19. openstack-xenserver post-processor Creates a new OpenStack Glance image from xenserver builders Key parameters • Keystone URL and credentials • Project name, region, and instance name • Script configuration Artifact input • xenserver-iso, xenserver-vm
  • 20. Key Activities Occurring During Service Migration 1. Snapshot of existing VM to minimize downtime 2. Detect if VM is PV or HVM and flag accordingly 3. Copy snapshot to NFS SR to collapse any snapshot chains 4. Connect primary network to HIMN to ensure no machine collision 5. Use VNC to reconfigure network and connect to XenServer DHCP server 6. Copy and run cleanse scripts which shutdown clone when complete 7. Detect shutdown and run Provisioners 8. Export and import into cloud as template
  • 21. 10 minutes to move a live service to the cloud (network willing) … Demo time ….
  • 22. The Service to Migrate – Piwigo http://piwigo.org
  • 24. The Cloud Topology with Original Data Store Intact
  • 25. My Cloud Bringing “Migration” all Together with an ADC Users
  • 26. Confirm the Migration and Iterate 1. Verify service migrated correctly 2. Iterate and resolve any issues 3. Scale the service • Let’s add more capacity 4. Add service to original load balancer • Don’t forget to adjust session weights 5. Decommission original service