该问题的答案可以在宏观层面上找到。你需有计划应对可能影响区域服务的灾难一一地震、限风，等等。因此你需要把服务布署在分开的地理区域中。至关重要的是:当下次大地震毁掉硅谷的数据中心时，必须有自动的方式将你的流量切换到东部海岸。一旦你解决了这个问题，所有的小事情都变得不重要了。如果一个数据中心的配电装置、路由器或交换机失效，你的流量将自动地转移到其他的大都市。很明显，为了防止流量在不同的地方来回折腾，某种程度的本地冗余是需要的，但你不需要将之进行到收益减少或者负收益的程度。
与人们的普遍看法相反，数据中心的确会有故障，有时原因很古怪。有一天我在参加一个会议时，接到运维中心的电话，通知我说:一个主要的数据中心运行中断。担心在我们处理问题时，这个事事件会段掉我的会议，我立即打电话给我的同事了解影响的程度。使我放心的是:她告知，所有网站都已转出那个地点，流量已转移到另外的数据中心，她正期待着“烤松鼠”的晚餐，原因是一个坏蛋爬进了配电箱，咬穿了主要的配电电缆。松鼠没能活过那天，不过我们安然无恙地度过了那一天。
正如前面提到的，BCP对于不同的人有许多不同的含义。让我们看一下这些术语以及它们对你的站点而言意味着什么。开始时，我先去掉该术语的一大部分一一人员和地点。管理员工是一个完整BCP计划的重要组成部分。如果你的办公大楼烧毁了，所有的人到哪里工作?我是一个工程师，那不是我的领域，所以我将集中于BCP计划的高可用性部分:保证站点正常工作。即使在高可用性领域，也有各种各样的技术，从热/热(Hot/Hot)、热暖(Hot/Warn)、热冷(Hot/Cold)到灾难恢复。
热/热(Hot/Hot)是高可用性的最高级别。用户可以从任意的数据中心使用全部的应用程序。读和写可以发生在任何地方。这让自动的故障转移变得非常简单，但它不是万能的。
你必须认真思考如何处理数据一致性的问题。如果一个数据同时写入两个地点，在复制过程中将出现冲突。哪个写入是正确的?互联网是非常动态的媒介，在很多情况下这并不要紧，不过应确保你有所计划。
热/暖(Hot/Warm)是一种很好的方式，如果你不能容忍数据的不一致性的话。很多应用有大量的读操作，仅偶尔(但很重要)写一下。在这种情况下，区别处理这两种操作是有意义的。读操作使用热热的方式，可由任何数据中心提供，具有快速自动的故障转移，这使大部分应用具有很高的可靠性。但一次只写入一个数据中心，这保证了数据的一致性，代价是一小部分应用的故障转移会慢一些。假设可以降低网站性能的话，就不用同步数据复制。在2写操作发生时，尽最大努力将数据尽快传到其他地点，但没有担保。复制延迟可能是几秒、几分钟到几小时不等。因此，当在一个地点进行写操作而紧跟着在另一地点进行读取时，会发生什么呢?更新可能还没到达，你会得到过期的数据。我们称之为临界读(critical reads)。你需要识别，以及通过错误处理或将读操作引至源站点，来减少临界读。
热/冷(1 Hot/Cold)让我害怕。这种架构将读写流量送到单一地点，而让另一个相同的部署在遥远的地平线上闲置。它容易建立，但价值很低。当灾难袭来时，你就会质疑计划是否明智。它真的行得通吗?软件版本是最新的吗?最后一次登录到这个冷站点是什么时候?情况往往是，这个冷站点会被闲置不用一年或更长的时间。当你需要时，它可能已遗憾地过时了。担心、不确定和怀疑都不可避免地会延长宕机时间。我见过无数次的事故，其冷情况下你不能使用冷站点，其意义何在?
站点是如此不可信，以至于我们宁愿有几小时的宕机时间，也不用故障转移。如果在紧急灾难恢复是最差的技术，本质上是雾件(vaporware)。它的本意不是在平常的时候保护你，而是在大的灾难发生时给你提供重建的选项。我们收购的一家公司有灾难恢复计划，它每月需要向第三方公司付“保险”费，该第三方公司维护了一个大型的数据中心，里面充满了闲置的服务器和存储设备。如果我们们的数据中心发生故障，我们可以用他们的。当然，如果有大的灾难，我们就会和他们的其他所有客户竞争资源。并没有实际的计划，也没有做过任何测试。在开始探索实际的故障转移会怎么样的时候，我们发现了一些令人惊骇的问题。结果是服务器和存储有各自不同部门，网站建设服务器群在一栋楼，而存储在另一栋。两栋楼之间有一根千兆以太线路连接，这明显不能工作。在我们决定自己干时，他们允诺再建第二条千兆的以太线路。
本文地址：//www.xrqsnxx.com//article/3358.html
