本文共 1831 字，大约阅读时间需要 6 分钟。

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

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

从目前在和客户的沟通与交流来看，貌似大部分用户都有这种想法，认为云服务应该从跨区域和跨站点的方向进行高可用，殊不知这个是一个很难达到的目标。

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

主数据中心

所有业务和数据的承载中心，为了保证较可靠的数据访问和较高的可用性，一般来说数据中心距离我们的办公地点距离一公里以内。数据中心内承载了所有的数据、数据库、访问层的应用

辅助数据中心

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

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

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

第三地的辅助数据中心

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

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

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

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

目前微软云在华东和华北拥有两个不同的数据中心，目前提供了99.95%的高可用，当然我们也必须设计出高可用的架构来保证我们的真个数据运维的正常。这里面有个问题，当数据和应用出现问题了，我们怎么保证数据正常呢？这就要靠我们关键的Azure 提供的一个功能:

TrafficManager

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

目前Traffic 支持三种流量走向模式：

1. 故障转移

   他的工作模式是通过别名方式进行工作，将2个云服务或者多个云服务实现故障转移，系统内置的自动检测方式能够检测出相对应的网站和目录是否出现状况，一旦出现问题，他通过自动检测的机制来讲流量导向到访问正常的网站。

2. 基于性能

   若要对分布在全球不同数据中心的终结点进行负载平衡，可以将传入的流量定向到最靠近的终结点，因为发出请求的客户端与该终结点之间的延迟最低。通常，"最靠近的"终结点对应于地理距离最短的终结点。使用"性能"负载平衡方法可以基于位置和延迟进行分发，但无法考虑网络配置或负载中的实时变化。

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

3. DNSRR

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

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

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

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

转载地址：https://databooming.blog.csdn.net/article/details/47192483 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！