Best Practices for Setting Up a New Google Compute Instance

Published in

Next Gen Technology Insider

5 min readMay 25, 2016

People use Compute Engine for various purposes such as servers for Dev, Staging or Prod services, while using them they get into some kind of problem or trouble in connecting and using them and are left with no option to recover from that situation.

There are 5 major areas we recommended for setting up a new instance:

These practices applies to both Linux as well as Windows instance.

Network and Security

Before creating a new instance, you should be aware of your project’s default security rules and network configurations. A network defines the address range and gateway address of all instances connected to it. It defines how instances communicate with each other, with other networks, and with the outside world.

Each instance belongs to a single network and any communication between instances in different networks must be through a public IP address. First thing to decide is over type of type of network you want to use. Is it a default network or whether you want to use VPN network.

If you are going to use Instances which ARE NOT going to get connected to any private network, outside your Google project network then it is recommended to use default network and if you want to securely connect your local or private existing network with your Google Compute Instances then recommended to use VPN

All incoming traffic to instances, even from other instances from same project is blocked by the firewall.

You need to make sure what IP addresses you need to allow on what protocols and ports. Other wise you will end up with access failure.

Regions and Zones

Network Latency and speed matters, so choose your Region and Zone based on users and customers accessing your instance.

Heads-up, All Compute Engine resources are either global, regional, or zonal. Compute Instance and Persistent Disk live in a zone and can not be moved within zone’s.

To attach a disk to an instance, both resources must be in the same zone. Similarly, if you want to assign a static IP address to an instance, the instance must be in the same region as the static IP.

On creating a new project using gcloud-compute for the first time, Compute Engine picks a default zone and region based on information from your project metadata and sets this property for your default configuration. Use “gcloud compute project-info describe” to view default properties by getting metadata information about the project. You can change your default zone and region in the metadata server any time.

You must decide your Region and Zone before creating a new compute instance and persistent disk. Leverage regions and zones to achieve appropriate service redundancy or to minimize latency by considering geography.

Resource Management

Use Labeling and Tagging to organize and indicate your different Compute Engine Resources.

Tags can be used to identify the instances when adding network firewall rules and can also be used to get firewall rules that already exist to be applied to the instance. Tag your instance to help you easily apply networking or firewall settings.

Tags are also reflected in the metadata server, so you can use them for applications running on your instances.

Labels can be used to organize and group together resources which are related or associated with each other. You can also use labels to build scripts that analyze costs or run bulk operations. Label your instances like production, staging or development, so can be easily searched.

You CAN NOT use labels for Networks and firewalls, but can recognize the label keys that are added as instance tags. On Updating tags or labels, the same changes are applied to the other property.

You should know your Google Compute Quota before using resources. Every Project has a default quota defined by Google Cloud Platform. You can proactively request quota adjustments from the Quotas page in the Cloud Platform Console under Compute Engine.

Storage

Root persistent disk storage. By default, each instance has a single root persistent disk that contains the operating system. You should add one or more additional storage disk to your instance for the better use.

Usually, users do not add additional disk storage to instance which sometime can create a bad situation in accessing instance. There can be many reasons in boot disk failure which will stop access to instance and/or can cause application or any other running service failure. Sometimes boot disk storage gets full from the deployed application on instance and/or different types of logs eat up some boot disk space.

I will recommend, adding an additional disk storage to your instance which will hold user application data and logs. It might be very useful later because your application data may evolve and scale in different ways and of course independent of chosen OS. You can do snapshots of that additional disk independently. With that you gain full flexibility of your data in the cloud and you don’t need to take OS with you data.

Make sure you know and select the right Region and Zone to attach a disk to an instance. Both resources must be in the same zone. Similarly, if you want to assign a static IP address to an instance, the instance must be in the same region as the static IP.

Backup and Disaster Recovery

Cloud can fall any time, so always be prepared.

Service-interrupting events can happen at any time. Your network could have an outage, or in rare cases you might even have to contend with a natural disaster. Before things go awry, it’s important to have a robust, targeted, and well-tested backup and disaster recovery for your Compute Engine resources.

Here are few things i would recommend to do for Backup and Disaster Recovery

Regularly backup your instance-disk by creating Snapshots. You can do this manually from Google Cloud Console or can schedule a script for taking Snapshots.
Deploy critical components of your application across multiple Availability Zones and replicate your instance data appropriately.
Regularly test the process of recovering your instance if they fail.
Monitor activities and respond to events.

Just to ensure again on creating Snapshots. If using additional disk with your instance, make sure you take separate snapshot for boot disk and additional mounted disk.

Usually instance boot disk always carry your OS, firewall settings, configurations and any installed software packages for which you should take a separate snapshot once when you are done with setup and configuration of your application. Take separate regular snapshots for additional mounted disk which carry your application data.
These practices are indeed to help you get maximum benefits for setting up a new Google Compute Instance

Originally published at Next Gen Technology Insider.