Is there any flexibility in where a multi-region configuration of Spanner's replicas are placed? Spanner's documentation indicates that the standard (only?) multi-region configuration consists of us-central1 (RW), europe-west1 (RO), and asia-east1 (RO)?
https://cloud.google.com/spanner/docs/instances#configs-multi-region
there is no flexibility in replica placement, configurations are all pre-defined
there are 4 multi-regional configurations offered at the moment
Two such configurations are offered in North America, one in Europe and there is one which spans several continents - North America, Europe and Asia.
Related
What would be a good infrastructure setup to ensure the minimum latency for the users in the following conditions:
One single AKS cluster in Europe
Users from multiple regions: US, Europe, Australia
Latency around 50 milliseconds or less
Is there any way to use the Azure network backbone to ensure this? Any input is welcome. I know this is not the ideal setup in case of a regional failure, I just want to hear what would be the possible options to improve the latency.
You could look at Azure Virtual WAN but even that will not meet your 50ms or less criteria between Australia and the AKS cluster in Europe or US to Europe. The only way to get to those numbers that I know of would be to deploy multiple AKS clusters in multiple regions.
We publish our monthly round-trip latency figures and you can see leaving any continent is about 120-250 ms. That's just the pure physics of where technology is right now. Theoretical pings traveling at the speed of light from the US to Europe alone is 40 ms and that's if you only traverse one router.
https://learn.microsoft.com/en-us/azure/networking/azure-network-latency
In CosmosDB SDK v2 it is possible to setup preferred locations during client creation (via ConnectionPolicy.PreferredLocations setting). However, I don't see similar setting in Cosmos DB SDK v3. As per my understanding, the closest setting in v3 is CosmosClientOptions.ApplicationRegion, but it allows to provide single region only.
Is there a way to to setup list of preferred locations in SDK v3?
V3 SDK takes a different approach. By specifying the ApplicationRegion (the region where your app is actually running), it will automatically populate the priority of regions based on proximity and account availability (the regions your account is provisioned to) to optimize latency.
If your app runs in West US and your Cosmos DB account is in East US, Europe, and West US, when you set the ApplicationRegion to West US, it will automatically create the preferred list as West US, East US, and Europe (order of distance).
You just need to focus on defining which region your application runs.
I am studying about microsoft Azure. Not able to understand difference between availability zones and regions.
Actually azure has the doc to describe the details about what's Availability Zones.
Firstly check: What are Availability Zones in Azure?
Availability Zones is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking.
In another doc explains what's regions.
A region is a set of datacenters deployed within a latency-defined
perimeter and connected through a dedicated regional low-latency
network.
Availability Zones are part of regions.
Availability Zones are physically separate locations within an Azure region.
Azure Availability zone
An availability zone is one or more data centers that are independent of another (power, water, natural disasters). An availability zone could have 1, 2, 3, or a million data centers. Usually, 3 is a good number: since data can be replicated to the other 2 in case of failure, you still have more than one data center operating. But you can see Availability zones with any number of data centers. The more data centers, the more resilient against shutdowns. What it can be a little bit confusing, is that an availability zone is not a physical location per se as a datacenter, but a latency-defined perimeter.
Azure Region
Now scale that up. Imagine those datacenter are connected directly from one to the other, by low latency connections. AKA: private cable network.
Each Azure region features datacenters deployed within a latency-defined perimeter. They're connected through a dedicated regional low-latency network. This design ensures that Azure services within any region offer the best possible performance and security.
Look at this graph:
Now, a region that has more availability zones, is more resilient than one with fewer availability zones.
Azure Geography
It is an area with one or more Azure Regions—for example, India, the United States, United Kingdom.
Availability Zones are not available in all regions in Azure yet.
So, in the absence of this feature what are some HA alternatives adopted by customers ?
usually its combination of built-in geo redundancy with the one you implement on your own (say, Azure SQL replication + VMs in 2 regions) and traffic manager\azure front door on top of that.
That's correct, not all regions have Availability Zones. For VM's, you can use Availability Sets to get pretty close to the SLA for AZ's.
You should not really use multiple regions as an high-availability option if your workload is latency-sensitive. Regions should be considered for DR.
We have a database located in North Europe region with 2 nodes of AppServices on Azure (West Europe & North Europe). We use traffic manager to route traffic.
Our SQL database and storage are located in Northern Europe.
When we started the website, European locations were the closest to our customers.
However, we saw a shift and most of our customers now are from USA.
We have high CPU utilization on our processors although we have a lot of instances on each.
The question is:
Since most of our customers are from USA and it's hard to relocate the database, is it better to keep the app structure as it is (N. Europe & W. Europe) or create a new node in USA but this node will still need to communicate with the database in North Europe?
Thank you
Having you app in US region and Database in Europe is not recommended.
These are a few of the things you will run into:
1) High latency since the queries for data will have to round-trip to Europe to get this.
2) Higher resource utilization since in general each request that access the DB will take longer, this will increase memory usage while requests are waiting on data it will also make the impact of load a lot more severe on the app.
3) cross region data egress, you will need to pay for all the data moving from Europe to us every-time there is a query.
A better solution would be to do the following:
1) Setup a new DB in us region and hook up active geo-replication
At this point you will have a hot/cold configuration where any instance can be used to read data form the DB but only the primary instance can be used for write operations.
2) Create a new version of the App/App Service plan in US region
3) Adapt your code to understand your geo distributed topology.
You App should be able to send all reads to the "closest" region and all writes to the primary database.
4) Deploy the code to all regions
5) add the new region to TM profile
While this is not ideal since write operation might still have to jump the pond, most apps have a read write patter than is heavily askewed towards read operations (roughly 85% reads / 15% writes ) so this solution works out with the added benefit of giving you HA in case one of the regions goes down.
You might want to look at this talk where I go over how to setup a geo distributed app using App Service, SQL Azure and the technique outlined above.
Have you considered sharding your data based on the location of your users? In terms of performance it will be better, You can provide maintenance on off-peak hours of each region. Allow me to recommend you this article.