Common Compute Engine actions
1. Common Compute Engine actions
Now that we have covered all the different compute, image, and disk options, let's look at some common actions that you can perform with Compute Engine. Every VM instance stores its metadata on a metadata server. The metadata server is particularly useful in combination with startup and shutdown scripts, because you can use the metadata server to programmatically get unique information about an instance, without additional authorization. For example, you can write a startup script that gets the metadata key/value pair for an instance's external IP address and use that IP address in your script to set up a database. Because the default metadata keys are the same on every instance, you can reuse your script without having to update it for each instance. This helps you create less brittle code for your application. Storing and retrieving instance metadata is a very common Compute Engine action. We recommend storing the startup and shutdown scripts in Cloud Storage, as you will explore in the upcoming lab of this module. Another common action is to move an instance to a new zone or region. For example, you might do so for geographical reasons or because a zone is being deprecated. To move your VM, you must shut down the VM, move it to the destination zone or region, and then restart it. After you move your VM, update any references that you have to the original resource, such as any target VMs or target pools that point to the earlier VM. During the move, some server-generated properties of your VM and disks change. At a high level, to move a VM across zones or regions, you can do the following: Create a machine image of your source VM. And create a VM from the machine image in a different zone or region. In this example, a VM named myinstance is to be moved from europe-west1-c to us-west1-b. The VM has two persistent disks named mybootdisk and mydatadisk. For more information in moving a VM instance between zones or regions, refer to the documentation. Snapshots have many use cases. For example, they can be used to back up critical data into a durable storage solution to meet application, availability, and recovery requirements. These snapshots are stored in Cloud Storage, which is covered later. Snapshots can also be used to migrate data between zones. We just discussed this when going over the manual process of moving an instance between two regions, but this can also be used to simply transfer data from one zone to another. For example, you might want to minimize latency by migrating data to a drive that can be locally attached in the zone where it is used. Which brings me to another snapshot use case of transferring data to a different disk type. For example, if you want to improve disk performance, you could use a snapshot to transfer data from a standard HDD persistent disk to a SSD persistent disk. Now that we've covered some of the snapshot use cases, let's explore the concept of a disk snapshot. First of all, this slide is titled persistent disk snapshots because snapshots are available only to persistent disks and not to local SSDs. Snapshots are different from public images and custom images, which are used primarily to create instances or configure instance templates, in that snapshots are useful for periodic backup of the data on your persistent disks. Snapshots are incremental and automatically compressed, so you can create regular snapshots on a persistent disk faster and at a much lower cost than if you regularly created a full image of the disk. You can create a snapshot schedule to regularly and automatically back up your zonal and regional persistent disks. As we saw with the previous examples, snapshots can be restored to a new persistent disk, allowing for a move to a new zone. To create a persistent disk snapshot, refer to the module PDF under Course Resources. Another common Compute Engine action is to resize your persistent disk. The added benefit of increasing storage capacity is to improve I/O performance. This can be achieved while the disk is attached to a running VM without having to create a snapshot. Now, while you can grow disks in size, you can never shrink them, so keep this in mind.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.