Microsoft Azure 托管服务可靠性设计

  • Article

服务的可靠性至关重要，而影响可靠性的因素多种多样，例如程序错误、硬件故障或依赖服务故障，以及人为失误。工程师们要对每个方面做出合理的设计来避免或容错各种故障，才能使服务达到高的可靠性。除此之外，当服务已经中断，如何快速定位问题并解决也是产品设计时就需要考虑的。这篇文章只以“CalculateCloud”为例，讨论一下托管服务的高可靠性设计。

拿出CalculateCloud的架构图看看，影响服务可靠性的有如下几方面：

  • 程序故障：这里只WebRole/WorkerRole代码出错。
  • 服务器故障：这里只运行角色代码的虚拟机发生故障。
  • 依赖外部服务的故障/维护：这里指托管服务所使用的Table或Queue发生故障。

接下来针对每种故障，我们逐个寻找对策：

程序故障

托管服务程序的调试和其他代码一样，在开发和测试阶段，可以使用模拟器在本地环境运行和调试代码。比如CalculateCloud非法字符输入的问题，在本地调试时，Visual Studio能够提示WorkerRole代码抛出异常。

 

对于此问题，使用try/catch来受理异常，问题就搞定了。需要留意的是，一旦部署到生产环境下，debug会比较困难。相比之下，丰富的程序日志能帮助用户监测服务状态和快速定位问题。下面的代码使用默认的 System.Diagnostics.Trace类来输出日志。

if (msg != null )

                {

string result = null ;

try

                    {

// handle job here.

var nums = msg.AsString.Split( ',' );

double answer = double .Parse (nums[0]) * double .Parse (nums[1]);

Thread .Sleep ( 10000);

                        result = string .Format ( "Job handled. {0}*{1}={2}" , nums[0], nums[1], answer);

                    }

catch ( FormatException )

                    {

                        result = "invalid input. msg=" + msg.AsString;

Trace .TraceError ( result);

                    }

catch ( Exception ex)

                    {

                        result = string .Format ( "failed to handle job. msg={0}" ,

                            msg.AsString);

Trace .TraceError ( result + ", error=" + ex);

                    }

finally

                    {

                        AddResultEntry(result);

                        queue.DeleteMessage(msg);

Trace .TraceInformation ( result);

                    }

                }

角色项目默认使用Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener来写日志。程序日志会以二进制形式写到虚拟机的本地磁盘C:下。由于角色可以运行在多台虚拟机上，那么日志也会分散在多台服务器上，登录每台虚拟机来查看日志会很麻烦，这里可以使用托管服务的一个组件“Windows Azure Diagnostics（WAD）”来解决问题。WAD会在每台虚拟机上启动两个额外进程，它们定期将虚拟机上的日志上传到Azure Storage上，用户可以从一个集中的地方访问所有日志。WAD的配置如下：

打开的Calculate.Worker的角色属性面板，在Diagnostics节中选择“Custom Plan”，然后设置存储日志信息的Azure Storage 连接字符串，再点击“Edit…”按钮，修改Application Logs的上传频率为1分钟。

 

WebRole同样需要添加Trace代码并配置WAD，这里不再重复。

WAD开启后，应用程序日志会被定期上传到Table Storage “WADLogsTable”表，大家可以用各种工具来查看日志，比如集成在VisualStudio “Server Explorer”中的Azure资源查看器。

WADLogsTable的索引键为”PartitionKey+RowKey”,其中PartitionKey格式为字符串 ” 0”+datetime.Tick。一个常用的查询语句如下，其含义为：查询部署ID为 08cd08dce90d4516b21be7bfe6936c75，在9/24/2014 1:00:00 AM UTC后，级别至少为“警告”的所有日志。

PartitionKey gt '0635471172000000000' and DeploymentId eq '08cd08dce90d4516b21be7bfe6936c75' and Level lt '4'

 

WAD提供了很多的功能，感兴趣的读者可以查看MSDN官方文档

https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-diagnostics/

https://msdn.microsoft.com/library/azure/gg433048.aspx

Storage服务故障

一个复杂系统必定会存在外部资源引用。当被依赖的资源发生故障时，往往会影响到系统的可靠性。在设计时，需要考虑到如何容错外部资源的故障，尽量降低对系统的影响，或者至少能快速定位出问题的资源，以便采取准确的恢复措施。

微软保证Azure Storage 在99.9%的时间内能正常运转，也就是说每个月最多可能offline 44分钟。因此，准备应对Storage故障是很有必要的。

Azure Storage运行在普通的硬件上，硬件故障不可避免，另外由与系统维护，版本更新或者负载均衡等原因，都会造成某些Storage服务器短暂下线，而其正在执行的用户请求就会失败。对于此类型的访问失败，用户只需重试一次，请求就会被移交给健康的服务器节点进行受理。因此，微软强烈建议客户端收到错误（超时或HTTP500）时重试几下。实际上，Azure Storage .net library默认已经实现了重试机制，并默认开启。对于直接使用REST API来访问Storage的代码，务必捕获异常状态并重试。

虽然较少发生，不过有时候重试也会失败，开发者需要自己捕获失败并受理。检查CalculateCloud的WorkerRole.cs文件，你会发现一旦访问storage的重试机制失败，WorkerRole程序就会因为未受理的异常而crash，从而导致更严重的系统服务中断。解决办法就是try/catch storage异常。这里我把错误记录下来，查询日志时若发现大量Storage错误信息，则说明Storage存在问题，需要采取措施。

while ( true )

            {

try

                {

var msg = queue.GetMessage();

                    ……

                }

catch ( Exception ex)

                {

// write trace.

Trace .TraceError ( "error occured when access storage. " + ex);

                }

            }

另外，为了进一步提高Storage的可靠性，可以使用Storage的异地备份-只读（RA-GRS）的功能，此功能将用户的数据存放在相邻的两个数据中心上，当其中一个数据中心故障，用户可以读取另一个数据中心备份。此功能可以保证数据读取99.99% 的可靠性，而数据写入可靠性仍为99.9% 。需要注意的是：数据在两个数据中心间同步，会有几分钟的延迟。使用RA-GRS的方法如下。

在Azure管理网站上导航到Storage配置页，更改Replication模式到“READ-ACCESS GEO REDUNDANT”

 

除此之外，还要修改代码，让Storage客户端能够自动failover到异地备份上。以CalculateCloud显示运算结果为例，需要更改WebRole的Default.aspx.cs文件。

protectedvoid Button2_Click( object sender, EventArgs e)

        {

try

            {

var connstr = RoleEnvironment

                    .GetConfigurationSettingValue( "DataConnection" );

var storageAccount = CloudStorageAccount .Parse (connstr);

var tableClient = storageAccount.CreateCloudTableClient();

                tableClient.DefaultRequestOptions.LocationMode =
 LocationMode .PrimaryThenSecondary ;

           ……

 

服务器故障/维护

托管服务是PAAS层面的服务，服务器的可靠性由平台来负责。微软对托管服务可靠性保证（SLA）的定义为：当每个角色运行在至少两个实例（即虚拟机）时，保证托管服务99.95%的在线时间。这个SLA如何理解呢？我先解释一下Azure平台的可靠性设计。

托管服务下的每台虚拟机被同时分配到两种域：故障域和更新域。故障域是物理上的概念，数据中心上每组机柜既是一个物理域，它有独立的电源管理和网络组件，一般认为，多个故障域不会同时发生故障。更新域是逻辑上的概念，管理器(FC)按照规则，同一时间只会维护一个更新域中的虚拟机。在Azure平台上，运行同样角色的三台实例（即虚拟机）是这样分配的：

 

故障域1

故障域2

故障域3

更新域1

WebRole_IN_0

 

 

更新域2

 

WebRole_IN_1

 

更新域3

 

 

WebRole_IN_2

如此一来，无论是硬件故障还是系统维护，同一角色的虚拟机不会同时下线 。这样解释大家就明白了吧，托管服务SLA保证了角色实例不会同时下线，而开发者需要在这种机制上建立可靠的程序。

那么用户如何充分利用平台特性来实现服务的高可靠呢，David Chappell总结了Azure编程三原则：

  • 每个托管服务拥有至少一个角色
  • 每个角色需要运行至少两个实例
  • 即使部分实例故障，整个Azure托管服务仍可正常运行

大家若想了解更多信息，可以下载David所写的托管服务编程模型白皮书，或者翻看一下《Microsoft Azure开发与应用》。我这里用三原则来检查一下CalculateCloud项目。

第一原则是强制原则，显然满足。对于第二原则，目前每个角色只运行在一台虚拟机上。这个修改很方便，打开每个角色的属性面板，修改 Instance Count为 2。

 

第三原则比较复杂，具体讲就是要求同一角色的实例拥有同样的功能，并且保持无状态，其中一个实例下线后，另一个可以替代它执行任务。

对于WebRole，实例运行在负载均衡器（SLB）后，负载均衡会探测实例的状态，并将Request分配给健康的实例上。为保证第三原则，每个WebRole实例不应该将客户的状态（如Session）保存在本地（进程或磁盘），否则一旦虚拟机下线，运行在它上面的客户将遭遇信息丢失的问题。Calculate.Web角色访问的所有数据都保存在外部Azure Storage上，因此满足第三原则。

 

Calculate.Worker不在本地保存中间结果，运算结果也直接写到Azure Storage了，所以也满足地三原则。

 

大家可以把CalculateCloud部署到云端测试一下，当重启一个Calculate.Web实例和一个Calculate.Worker实例时，整个服务仍然正常运行。即使Calculate.Worker所有的实例都重启，得益于Azure Queue持久化消息通信，服务仍然可用，只是计算工作会有所延迟。

 

追求更高的可靠性

有些客户对服务可靠等级有更高的要求。比如发生数据中心级别的故障时，服务仍然可用。Azure平台能做到吗？当然能啊，只要愿意花更多的钱。

微软提供的另一个服务叫做Traffic Manager（简称TM），它工作在一组托管服务前，将客户的服务请求按照规则重定向到背后的某个托管服务上。以下图为例，解释一下流程。

 

  1. 客户要访问服务（www.contoso.com），首先发DNS解析请求到公网的DNS服务器。对于服务提供商，他需要事先从域名提供商那里购买一个公网域名consoto.com。
  2. DNS服务器将服务的域名（www.contoso.com）重定向到TM的域名（*.trafficmanager.net）。对于服务提供商，他需要事先配置子域名www.contoso.com的解析规则，将其CNAME到TM。
  3. DNS服务器访问TM的域名服务器来索要解析的IP地址。
  4. TM根据规则选择一个托管服务（现在TM支持所有公网服务）。TM会检测托管服务的状态，确保选择健康的服务。另外，用户可定义选择方式：根据性能，平均分配，或者故障迁移。
  5. TM域名服务器把选择的服务IP地址返回给公网DNS服务器，最后返回给客户。
  6. 客户得到服务IP后，直接访问服务地址，不再经过TM。

有了Traffic Manager，就可以做跨数据中心的服务备份了。以CalculateCloud为例，可以这样设计：在香港和新加坡各部署一个托管服务，然后在香港创建一个Azure Storage账号，并开启RA-GRS。香港的托管服务直接访问Azure Storage主地址，新加坡的托管服务访问Azure Storage主地址来写数据，而读取操作直接访问Azure Storage备份的地址（<accountname>-secondary.table.core.windows.net）。最后，创建一个Traffic Manger，将两个托管服务的地址添加到Endpoint Set中。

 

这种设计可以在单个托管服务下线时，保持整个系统的可用性。而当整个香港数据中心下线时，系统进入只读运行模式。具体实施步骤如下：

首先把托管服务部署到香港数据中心和新加坡数据中心。为了让新加坡的服务访问Storage备份，还需要更新Default.aspx.cs代码。

protectedvoid Button2_Click( object sender, EventArgs e)

        {

try

            {

var connstr = RoleEnvironment

                    .GetConfigurationSettingValue( "DataConnection" );

var storageAccount = CloudStorageAccount .Parse (connstr);

var tableClient = storageAccount.CreateCloudTableClient();

                tableClient.DefaultRequestOptions.LocationMode =

LocationMode .SecondaryThenPrimary ;

 

接下来，登录Azure管理网站，创建一个Traffic Manager。

 

然后，打开TM的Endpoint配置页，把我之前部署的两个托管服务添加进来。

 

搞定。Traffic Manager还有很多配置选项，感兴趣的朋友看看MSDN文档吧。

https://msdn.microsoft.com/en-us/library/azure/hh744833.aspx

 

当然，除了上面的设计方案外，咱还可以在每个数据中心创建单独的Azure Storage，这样即使数据中心故障，服务也完全可用。不过这需要对代码做更多的调整，确保客户访问每个托管服务都能得到一致的结果。

 

Traffic Manager是个结构简单的服务，它的可靠性保证（SLA）为99.99%。不过根据我的经验，从服务GA到目前为止，零故障。索契冬奥会官方网站的方案就用了TM，当时他们在四个数据中心部署了八个托管服务，用TM做负载平衡。

总结

文章并没有涵盖所有Azure服务，而提到的方案也并非可以套用到所有场景下，这里只当作为抛砖引玉，供大家参考。这里总结一下提到的方法。

故障类型

应对方法

代码故障
  • 本地模拟器调试
  • 用Windows Azure Diagnostics 收集日志

Azure Storage故障
  • 重试
  • 捕获和受理Storage Exception
  • 启用异地备份-只读（RA-GRS）功能

服务器故障
  • Azure托管服务编程三原则

数据中心大灾难
  • Traffic Manager
  • 多Azure Storage账户做Failover

另外，高可靠性意味着系统冗余，增加运营的成本和系统复杂度。用户需要在可靠性和各种指标之间找到合适的平衡点。