Moving workloads between instances is relatively common, regardless of the cloud provider. There are times when...
Google Compute Engine users need to move processes running on one virtual machine instance to another. For example, users may want to switch to a larger instance type or move an instance between zones. And while moving workloads between Google Compute Engine instances can be arduous, it doesn't have to be.
When moving an instance to a different machine type, first shutdown your instance. If you were using persistent disks with the original instance, attach them to the new instance. To create the new instance type, use the command "gcloud compute instances create." Specify the new instance type using the machine-type parameter.
To move an instance to another zone -- or a specific location within one of Google's hosting regions -- there are a couple of options. Google provides a command-line operation, "gcloud compute instances move," to migrate instances between zones. Additionally, enterprises can use an API method, MoveInstance, that uses a target instance and a destination zone as parameters.
To move disk content, the operation uses disk snapshots, which capture the state of disk storage attached to an instance. Once you have a snapshot, you can move it to another zone or attach it to another instance.
Google Compute Engine offers three disk types: standard persistent disks, solid-state persistent disks and local solid-state drives. However, only standard persistent disks and solid-state persistent disks support snapshotting for moving disk content. The former works well for sequential read and write operations, while the latter is well suited to random access I/O patterns. Local solid-state drives are optimized for low latency and high throughput, but do not support snapshotting.
After creating a snapshot, attach it to a new instance. If the new instance needs the same external IP address as the previous instance, assign it to the new instance.
Google documentation notes that no changes should be applied to resources during the move operation, as it will cause the move to fail. However, the state of disks is maintained in the snapshot and on persistent disks. Therefore, if the move operation fails, recovery is still possible.
About the author:
Dan Sullivan holds a master of science degree and is an author, systems architect and consultant with more than 20 years of IT experience. He has had engagements in advanced analytics, systems architecture, database design, enterprise security and business intelligence. He has worked in a broad range of industries, including financial services, manufacturing, pharmaceuticals, software development, government, retail and education. Dan has written extensively about topics that range from data warehousing, cloud computing and advanced analytics to security management, collaboration and text mining.
Google Compute Engine expectations for 2015
Demystifying Google Compute Engine pricing
How Google Compute Engine stacks up against Azure, AWS
Dig Deeper on Managing cloud infrastructure
Related Q&A from Dan Sullivan
Docker's recent upgrade introduced support for hardware signing and in the future, automated security analysis on Docker images. Expert Dan Sullivan ... Continue Reading
Cisco's new project Contiv automates operational policies for containerized applications in the cloud. Expert Dan Sullivan explains the benefits of ... Continue Reading
Dropbox API abused by attackers posing as legitimate users in a huge spear phishing campaign. Expert Dan Sullivan explains how to mitigate the risks ... Continue Reading