Pre-requisite: Google Cloud Platform
In essence, when we discuss the cloud, we are also discussing hardware. We “rent” the Google infrastructure in the case of GCP. Due to the decreased danger of the system failing, Google hosts resources in many locations there is very little chance that a natural disaster or another issue will strike simultaneously in two separate places. The decrease in latency is a significant benefit of having several resource locations.
These places are grouped together as regions. In essence, a region is a Google data center. We can locate every tool needed to create a Google cloud application within a data center. A physical server, network elements, and a virtual machine are some of these resources. The region’s true location is either in central America, Western Europe, or East Asia. Each region is made up of several zones. A zone is where a cloud platform can be deployed. In our infrastructure, a zone should be viewed as a single point of failure.
What is the Need for Zones or Regions?
We must think about distributing our application across many zones and, maybe, various regions in order to achieve fault tolerance and high availability due to the possibility that a zone will experience downtime. We can design for comprehensive fault tolerance and high availability in the cloud thanks to the various regions and zones.
There is a name for the zone. This is made by combining the region’s name with a number that designates the zone’s number, for example, Europe-west2.
It’s crucial to consider availability when creating cloud applications. This ultimately has something to do with the choice we make regarding our deployment model. Either a regional application, like App Engine, or a managed multiregional application, like Cloud Storage, must be used if we want our service to have high availability.
We employ a multiregional-based service, such as Google Cloud Storage or Google Cloud Datastore, to create disaster recovery for the data that adheres to this plan. We take a snapshot of the data in a multi-regional resource if we use a zonal or regional service. Replicating the data in a separate zone or region is necessary. This will ensure that we have a backup zone in case one fails.
Use a zonal or regional resource for computing, like Google App Engine, but have a mechanism in place to spin up the application in a different zone or region in case of failure. Of course, in order to balance the resource throughout the zone or region and connect the data to a multiregional service, total high availability requires the use of a load balancer.
Types of Scopes for GCP Resources
Regional Resources
Across all zones of a given region, a regional resource can be redundantly delivered. A zonal resource is given high availability as a result. Any resources located in the same region as the regional resource can access it. For instance, if you reserve a static external IP address in a certain region, only instances located in that region will be able to use that static external IP address. Additionally, each area has one or more zones.
- Addresses: Any regional static external IP addresses that you have set up for your project are included in the Addresses collection. Static external IP addresses are a regional resource that is used for protocol forwarding, regional forwarding rules for regional load balancers, and instances that are in the same region as the address.
- Cloud Interconnect Attachments: A VLAN is assigned to your Cloud Interconnect through an interconnect attachment, and that VLAN is then connected to a VPC network. A Cloud Interconnect link is a global resource as opposed to an attachment, which is a local resource.
- Subnets: Regional network IP space is divided into prefixes (subnets) by subnets, which regulate which prefix an instance’s internal IP address is assigned from.
- Regional Managed Instance Groups: Groups of identical instances that span several zones make up regional managed instance groups. Instead of restricting your app to a single zone or having to manage several instance groups across different zones, regional managed instance groups allow you to distribute app load across multiple zones.
- Regional Persistent Disks: Regional persistent discs offer long-term data archiving and replication between two zones in a single region. You can force-attach a regional persistent disc to a different instance running in the same region in the event of a failover. A zonal persistent disc cannot be forced to be attached to an instance. You can choose to share disc resources amongst projects, allowing other projects to produce images and snapshots from these discs but preventing instances in other projects from attaching the discs to their instances disks
Zonal Resources
One zone is served by a zonal resource. The resource itself is rendered unavailable if the zone is unavailable. Per-zone resources are those that are hosted within a zone. Resources that are zone-specific or per-zone are exclusive to that zone and can only be used by other resources in that zone. A per-zone resource is, for instance, an instance. The zone in which the instance is located must be specified when creating the instance.
- Instances: A virtual machine (VM) instance that is situated within a zone has access to both global and zone-specific resources.
- Persistent Disk: Other instances inside the same zone can access persistent drives. Only instances located in the same zone as the disc are eligible for disc attachment. An instance in a different zone cannot have a disc attached to it. It is an option to share disc resources amongst projects, which prevents instances from other projects from attaching the discs but allows other projects to produce snapshots and pictures from these discs.
- Machine Types: Machine-type resources are zone-specific. Only machine types that are in the same zone can be used by instances and disks.
- Zone-Managed Instance Groups: A zonal-managed instance group creates a collection of identical instances inside a zone using an instance template. Instead of controlling individual VM instances, you manage the managed instance group as a whole.
- Cloud TPUs: Zonal resources are TPUs. See Availability for details on the zones where TPUs are accessible.
- Per-Zone Activities: An operation is a resource for each zone, each region, or the entire world. An operation is regarded as a per-zone operation if it is carried out on a resource that is specific to a given zone. Because it is being done on a resource specific to a zone, an instance, inserting an instance is an example of a per-zone operation.
Global Resources
Other resources may access this type of resource, regardless of zone or location. Typically, the global resource is a network, snapshot, or disc with preloaded settings. Any resource within the same project has access to global resources from any zone. A scope specification is not required when creating a global resource.
- Addresses: Any global static external IP addresses that you have set up for your project are included in the Addresses collection. Global load balancers use global static external IP addresses, which are global resources.
- Images: Any instance or disc resource in the same project as the image can use it. You can boot your instance using predefined images that Google offers. You can create your own image or modify one of these images.
- Snapshots: All discs included in the same project as the snapshot have access to persistent disc snapshots.
- Cloud Interconnects: A Cloud Interconnect connects your on-premises network to Google’s network through a highly available connection. This link is a worldwide resource. Interconnect attachments, however, which are included within this connection, are local resources.
- Instance Templates: VM instances and controlled instance groups can be built using an instance template. A global resource is an instance template. However, some zonal resources can be provided in an instance template, which limits the use of that template to the stated zonal resource’s location.
- Cloud Interconnect Locations: A Cloud Interconnect location is a real-world Cloud Interconnect connection point close to your network. For each possible colocation facility and edge availability domain, there is a single Cloud Interconnect location. The global resources at Cloud Interconnect locations are read-only.
- Regional Operations: An operation is a resource for each zone, each region, or the entire world. An operation is deemed a per-region operation if it is carried out on a regional resource. For instance, reserving an address is a regional action since addresses are a resource that is exclusive to a particular region.
Multi-Regional Resources
Google directly manages this cloud service to be redundant and dispersed across many zones and territories. A multiregional area stores data across multiple regions rather than in just one region or zone.
- Sites and Subnets: Depending on the location chosen, Google will automatically construct a network for each site. That network will also act as the site’s AD Replication subnet.
- Replicating Sites: To ensure that any modifications made in any site are known to the entire domain, each site/region will replicate the other AD sites.
- Replicating Networks: Replication subnets are built depending on the subnet associated with the region where each site is deployed. Each replication site is put into the appropriate replication subnet automatically.
- Website Links: Site linkages will be built between all of the sites, and the cost of each link will depend on the latency between the various geographic areas. During deployment, an automatic cost calculation is made for each link.
- Files RDP: Users can choose the size when downloading the RDP file, and if they connect from a site other than their default site, the RDP file is already set up to reroute to the closest broker, who can then transfer the connection to their default site while minimizing latency.
- User Profiles and the File System: On the file server, files, folders, and user profiles are stored in the user’s default location.
When deciding to implement our cloud architecture, it is crucial to understand the type of resource. This is so that it can effectively influence how the architecture is designed. Understanding the operation’s scope based on the type of resource we select is crucial while planning our design.
For instance, if we need to construct a network, we do it by creating a global resource that may be used by multiple zones and areas. However, because the IP address varies based on the zone, assigning an IP is effectively a zone action. We must base our decisions when considering the cloud on how effective the architecture is. As a result of the high latency, we never use a hard-drive resource from a separate location.
Correct resource planning makes all the difference between a successful and unsuccessful cloud project.