跨多个数据中心在地理上扩展 Azure 云服务 [英] Scaling Azure cloud services geographically across multiple data centers

问题描述

我有一个部署到 Azure 的相当典型常见的应用程序，包含以下组件:

I have a fairly typical common application deployed to Azure, with the following components:

• 两种云服务 - Web 和 Worker
• Azure 服务总线
• Azure SQL 数据库
• Azure 存储

在 Azure 管理控制台中，您可以选择自动横向扩展每个云服务(意味着添加更多服务器)，这发生在同一个数据中心内.

In the Azure management console, you can choose to automatically scale out each cloud service (meaning more servers added), which happens within the same data center.

将完整云服务架构(如我们的)扩展到多个数据中心的最简单方法是什么?

What's the easiest way to scale a complete Cloud Service architecture (like ours) out across multiple data centers?

或者，如果将我们的云服务只是复制到另一个数据中心很容易(正确处理负载平衡等)，那么通过 Microsoft 的 SQL 和存储延迟/传输速率是否会相当快数据骨干"?

Alternatively, if it was easy enough to replicate just our Cloud Services across to another data centre (correctly handling load balancing etc), would the SQL and Storage lag/transfer rates be reasonably fast through Microsofts data "backbone"?

我问的原因是我们的服务器目前在欧洲，但我们即将在亚洲大举推进，并希望缓解网站(也托管我们的移动 API)的任何性能问题.

The reason I ask is that our servers are currently in Europe, but we are about to do a big push in Asia, and want to mitigate any performance issues for the website (which also hosts our mobile API).

我明白这是一个重要的问题，因为您需要考虑同步 SQL 数据库和 Azure 存储容器，但我希望 Microsoft 已经考虑过它:)

I appreciate that this is a non-trivial problem since you need to think synchronising SQL Databases and Azure Storage containers, but I was hoping Microsoft have thought about it already :)

我目前使用 Visual Studio Azure 项目中的发布"命令进行部署.这有一个 ServiceDefinition(包含我的两个云服务)和每个环境(实时/测试)的 ServiceConfiguration 文件.

I currently deploy using the "Publish" command from a Visual Studio Azure project. This has a single ServiceDefinition (containing my two Cloud Services) and a ServiceConfiguration file for each environment (Live/Test).

我真正想要的是这个(但可能来自 Visual Studio):

What I really want is something as easy as this (but maybe from Visual Studio):

>git push azure-NorthCentral master
>git push azure-SoutheastAsia master
>git push azure-WestEurope master

此示例使用 Azure 网站的 Git 部署，它比我们的更孤立云服务架构，例如无需考虑数据同步.

This example uses Git deployment for Azure Web Sites, which are more isolated than our Cloud Service architecture, e.g. no data synchronisation to consider.

推荐答案

我将这个问题标记为关闭，因为过于宽泛，因为老实说，在地理缩放方面没有正确的答案.但是，我想就 Azure 原生提供的与您的应用相关的内容(无论您是否选择合并它们)提供一个客观的答案.

I marked this question to be closed as too broad, because honestly, there's no right answer when it comes to geo-scaling. However, I wanted to offer an objective answer regarding what Azure provides natively, related to your app (whether you choose to incorporate them or not).

流量管理器专为根据特定规则(最近、循环、主要/故障转移)将您的流量路由到特定区域而设计.根据您的规范，这会将流量定向到您部署到的特定区域.

Traffic Manager is designed specifically for routing your traffic to a particular region, based on specific rules (nearest, round robin, primary/failover). This would direct traffic to a specific region you deployed to, per your specification.

Azure Storage 提供了具有异地复制二级存储的能力(您不能为二级存储选择区域；每个区域已经与另一个配对).然后您可以选择从次要区域而不是主要区域读取.您将不得不处理数据最终一致这一事实.

Azure Storage provides ability to have geo-replicated secondary storage (you cannot choose the region for the secondary; each region is already paired with another). You may then choose to read from the secondary region instead of primary. You will have to deal with the fact the data is eventually-consistent.

SQL 数据库服务提供主动异地复制，您将在其他区域拥有只读数据库(同样，这是异步复制，但您的辅助数据库在事务上保持一致).

SQL Database service provides active geo-replication, where you'll have read-only databases in additional regions (again, this is an async replication, though your secondaries remain transactionally consistent).

请记住:区域之间的带宽/吞吐量没有 SLA/性能指标.您需要进行一些基准测试.

Keep in mind: There is no SLA/performance metric around bandwidth/throughput between regions. You'll need to do some benchmarking.

这篇关于跨多个数据中心在地理上扩展 Azure 云服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！