Windows Azure 故障转移模式及高可用个模式探讨！



眼下国内非常多用户对于云服务的可用性存在误解，什么样子的误解呢？比方某云服务商，在华南某地有一个机房，在华东有一个机房。

这个客户就提到一个需求，你提供的99%可用性的概念是什么意思呢？是不是我的机器在南方机房出了问题。我的机器就自己主动的转到华东机房么？

从眼下在和客户的沟通与交流来看，貌似大部分用户都有这样的想法。觉得云服务应该从跨区域和跨网站的方向进行高可用，殊不知这个是一个非常难达到的目标。

在金融行业常常存在两地三中心的概念，在两地三中心的概念中。我们常常可以看到例如以下定义的描写叙述：

主数据中心

全部业务和数据的承载中心，为了保证较可靠的数据訪问和较高的可用性。一般来说数据中心距离我们的办公地点距离一公里以内。

数据中心内承载了全部的数据、数据库、訪问层的应用

辅助数据中心

辅助数据中心的业务相当于全部主承载数据中心的副本。为了保障数据的整体安全，我们的数据中心距离我们的主数据中心大概40公里左右，防止主数据中心发生了相似火灾和水淹等区域小规模灾害。

辅助数据中心在主数据中心出现相似小规模灾难后进行数据切换。大部分企业都是将辅助数据中心作为备用网站，也有非常多企业将同城的辅助数据中心作为他们的备用网站。

当启用了备用网站后，企业的业务数据中心大部分用户可以利用辅助数据中心的办公设施进行办公。

第三地的辅助数据中心

通常第三地的数据中心是作为同城数据中心由于大规模天灾造成无法短期内恢复业务。那么就必须启用第三地的数据中心来启动业务。保证业务的持续执行。通常异地的数据中心恢复执行须要做一些网络、业务和数据的切换须要时间，因此切换第三地的数据中心须要4个小时左右的时间，切换后，关键业务人员可以通过飞机的方式到异地办公，保证关键业务数据可以持续执行。

因此多数情况我们提到的SLA的 99%以上在多数情况下提到的是都是本地的高可用状况。

而基于两地三中心的模式我们相对来说投入也是非常巨大的，由于必须考虑到达到对应级别的SLA须要我们必须投入对应的硬件和软件成本，对于两地来说，要达到等同的应用等级，我们要保证至少我们的硬件投入是 2倍以上。而第三中心启用后。我们的成本也是对应的硬件成本至少是3倍或者数十倍以上。

而眼下大多数云提供的高可用性也不意味着提高高可用的SLA级别可以实现跨地域转移，而多数情况下也是本地应用的高可用性，而远程高可用则意味着不是採用单实例架构来实现的。

眼下微软云在华东和华北拥有两个不同的数据中心。眼下提供了99.95%的高可用。当然我们也必须设计出高可用的架构来保证我们的真个数据运维的正常。

这里面有个问题，当数据和应用出现故障了。我们怎么保证数据正常呢？这就要靠我们关键的Azure 提供的一个功能:

TrafficManager

Traffic Manager 中文翻译为流量控制。这个让非常多人会觉得是控制流量大小，事实上Traffic Manger 一个非常重要的功能就是控制我们的流量走向。

眼下Traffic 支持三种流量走向模式：

1. 故障转移

   他的工作模式是通过别名方式进行工作，将2个云服务或者多个云服务实现故障转移，系统内置的自己主动检測方式可以检測出相对应的网站和文件夹是否出现状况，一旦出现故障，他通过自己主动检測的机制来讲流量导向到訪问正常的网站。

2. 基于性能

   若要对分布在全球不同数据中心的终结点进行负载平衡，可以将传入的流量定向到最靠近的终结点，由于发出请求的client与该终结点之间的延迟最低。

   通常，"最靠近的"终结点对应于地理距离最短的终结点。使用"性能"负载平衡方法可以基于位置和延迟进行分发，但无法考虑网络配置或负载中的实时变化。

   流量管理器定期生成"Internet 延迟表"。流量管理器基础结构执行測试来确定全球不同点与托管着终结点的 Azure 数据中心之间的往返时间。

3. DNSRR

   这样的方式会将用户訪问依据訪问的应用的权重来分配用户訪问，或者在相同的权重以下实现用户的随机訪问，也就是基于DNS Round Robin 方式进行訪问的负载。

我们接下来的目的是实现应用訪问的故障转移。我们接下来分别依据应用的简单复杂度来实现应用和訪问的负载均衡。

我们接下来的样例会以简单的静态页面，基于SQL Azure 和SQL 虚拟机。还有Mysql 和Mysql虚拟机的多网站同步来完毕数据的多网站訪问和复制技术。

我们下一篇文章将会以拿到订阅后简单配置为操作方式，而且依据不同需求配置故障转移的模型。