Regions and Availability Zones

Cloud infrastructure concept has the term of a Region, which is a physical location around the world where we cluster data centers. We call each group of logical data centers an Availability Zone. Usually each region consists of multiple, isolated, and physically separate AZs within a geographic area.

A cloud region is a group of equipment located in a separate data center. Each region has a separate from other regions connection to electricity lines, autonomous power supply and cooling, as well as dedicated communication channels. Each region is isolated from hardware and software failures in other regions of the cloud.

Each AZ has independent power, cooling, and physical security and is connected via redundant, low-latency networks. Cloud customers focused on high availability can design their applications to run in multiple AZs to achieve even greater fault-tolerance. SIM-Cloud infrastructure Regions meet the highest levels of security, compliance, and data protection.

Regions resources

Regional resources are shared objects that can be used across the entire cloud region, in all availability zones of the region. These include:

  • Cloud management interfaces:

    • API (Service Endpoints)
    • Web interface - Dashboard

  • Keystone - the OpenStack Identity Service

  • Glance - the OpenStack Image Service

  • OpenStack Controllers: Nova, Cinder, Neutron

What is an availability zone

In the context of cloud computing, it is a public cloud provider’s data center that contains its own power and network connectivity. There are typically multiple Availability Zones in a region. Each region is a separate geographic area, and each region generally has multiple, isolated locations known as Availability Zones. A common misconception is that a single zone equals a single data center. In fact, each zone is usually backed by one or more physical data centers.

Availability zones benefits

  • Lower latency where multiple availability zones are implemented, it makes a sense to have the servers that provide a given application located relatively close to the end users that will access that application. Latency is a big issue in the application world, and many cloud providers address is this by distributing servers and storage, placing those resources closer to their customers’ end users.
  • Customers can deploy their applications and instances across availability zones, and design their environment so that if one availability zone fails, the instances in the other availability zone will become active, and continue the work of the servers in the failed availability zone, until such time as service can be restored.
../../_images/Availability-Zone-Diagram.png

Zone resources

Zone resources are resources that can only be used within the zone to which they belong. Typically, when creating a resource of this type, you must pass the name of the availability zone in which the resource is to be created.

These resources include:

  • Computing nodes;
  • Cinder clients;
  • Neutron clients;
  • Instance (virtual machines);
  • Storage and Volumes;
  • Cloud provider Router;
  • BaaS agents
  • Local and External private Networks

Note

If an availability zone is not selected when creating zonal objects such as:

  • Volumes
  • Instances
  • Cloud provider Router
  • Network

resources will be allocated and created in the default availability zone - eu-west-avz1.

Accounting and quotas

Availability zone objects have a common quota for all AZs. This means that the project resources in the SIM-Cloud are divided between availability zones. If the customer has available free project resources, he can create objects of his choice in any availability zone.

How availability zones may be implemented

  • Service synchronization You can increase the resiliency of your application by running it on virtual machines in different Availability Zones. With this architecture, if there is any failure in one of the Availability Zones - either electricity or network drives - virtual machines in the other Availability Zone will continue to operate without interruption.
  • HA APP Clusters
  • Monitoring The ability to monitor the main infrastructure site from an independent availability zone.
  • Test site The ability for using different sites for develop and production.

Each zone is isolated from hardware and software failures that may occur in other availability zones. By deploying your apps in multiple zones, you will ensure fault tolerance and significantly reduce the risk of data loss.

Our cloud infrastructure is hosted in high-end TelemaxX IPC-3 and TelemaxX IPC-4 Tier III+ data centers in Karlsruhe, Germany. The data centers have been in operation since 2009 and 2011 respectively. Their focus is on enterprise business and corporate clients with high expectations with regards to reliability and safety of various infrastructural projects.

List of available regions and zones

You can place your resources in the following availability zones:

“SIM-Cloud Regions and Zones”
Geographic location Country Region Zone
Europe Germany eu-west avz1
Europe Germany eu-west avz2
  • eu-west-avz1 (TelemaxX IPC-3)
  • eu-west-avz2 (TelemaxX IPC-4)

Restrictions

1) There is no option to create and launch an instance from a volume in opposite Availability Zones. This means that you will not be able to create an instance in the “eu-west-avz1” availability zone if the volume was created in AZ “eu-west-avz2”.

2) The option to migrate volumes between Availability Zones using standard cloud functions is not possible. This is because each AZ uses its own storage and data cannot be moved between storages in one click.

Solution: BaaS can be used to migrate data. Detailed instructions will be described in our article Migrating volumes between AZ.

  1. The process of migration of such AZ resources (objects) as:

    • Cloud provider Router
    • Network

is affordable. The specified objects must be recreated in the desired Availability Zone.

4) An instance can be moved to a different Availability Zone only after it is deleted and the volume is migrated to the desired AZ. Only then can a new instance be created from a volume that was migrated to AZ.

Note

Please note that when changing Availability Zones, the floating IP address is not saved.

To solve this case, you need to use a dedicated external network or use domain names, managing which the user’s service does not depend on IP addressing.

The process of migrating an instance to another Availability Zone is described in our article Migrating volumes between AZ..