通过
如果你已经阅读了我们的运营经理的博客(2020年6月11日CDC断电)那么你就会知道我们几周前遇到了一个小问题，导致我们的主要数据中心停电了大约10秒。
我们在SAN上运行3个日立数据系统(现在是日立Vantara)磁盘阵列。一台G600在我们的主数据中心，一台G400在我们的容灾数据中心，一台G200在第三个站点。
在系统正常运行时，G600几乎为系统提供了全部磁盘存储。大约三分之一的容量然后复制到我们的容灾站点和G400上。G200的主要作用是在发生故障时提供仲裁投票，它通过单独的光纤通道路径连接到G600和G400，以确保至少两个阵列之间始终保持连接—相当标准的集群。G200还塞满了大磁盘，以提供离线在线磁盘备份服务，作为灾难时的第一行备份——谢天谢地，在这次宕机中不需要。
存储通过使用Hitachi Global Active Device (GAD)的私有光纤连接同步复制到容灾站点。这将维护副本，并在两个主磁盘阵列中的任意一个上提供对任何复制磁盘的读写访问。在发生故障的情况下，主机(现在几乎所有的ESXi主机)看到两个路径消失了，但它们仍然有两个到另一个数组的连接，因此它们完全不知道一个数组已经消失了。至少，这一直是理论，尽管几年前在调试期间进行了彻底的测试，但它从未在真正的DR情况下使用……直到几周前!
值得庆幸的是，一切都按照预期进行。一旦电源恢复(大约10秒)，Virtual服务器开始启动，并且可以看到它们的磁盘，并且完全不知道它们的磁盘来自城市的另一边。
作为“出了什么问题”练习的一部分，我们总是在这种重大事件之后进行，我们查看了从存储阵列中获得的报告，因为每个人都喜欢图表
首先，一个正常的交通周(嗯，像Covid-19周一样正常——比正常情况安静，因为大部分校园都关闭了，而且不是繁忙的学期)。
睡眠模式相当有规律——有些晚上比其他晚上高。有趣的是，磁盘阵列在晚上比在白天要忙得多。如今，夜间作业和备份对磁盘的影响远远大于对用户的影响。
接下来的一周，情况明显不同
当系统在周四下午开始恢复时，我们很快决定取消当天晚上的所有备份工作。我们在中断前一晚有一个很好的备份，并且考虑到系统是从远程站点的存储运行的，我们不想通过尝试备份而增加站点之间链路的负载——我们已经知道备份是阵列最繁忙的时间，因此删除负载似乎是一个明智的选择。我们还从16:00左右开始复制回主阵列—同样，这不是我们想要与备份流量竞争的事情。
备份在周五恢复——在图表上可以清楚地看到，这是一周中最繁忙的时间——峰值为6493MB/s，因为发生了比正常更大的备份(有效的两天，加上故障触发了比正常更大备份的服务的额外时间)。
灾备阵列通常处于一个相当稳定的速率，除了灾备站点中的几个小主机外，几乎所有的写流量都在正常使用中，它所做的只是从主阵列获取磁盘复制。来自这个DR阵列的停机周的图表显示了一个不寻常的流量模式!
很明显，在13:00到14:00之间，数组突然发现自己比以往任何时候都要忙(好吧，除了最初的副本播种，它已经全速运行了几个星期!)。峰值显著低于生产端的正常峰值，但显著高于正常的白天流量。1220MB/s的峰值显示大量的服务器几乎同时启动——这些是复制的磁盘，虚拟机启动时不知道它们的数据现在是由DR阵列提供的。前一周白天的正常峰值低于1000MB/s—这是针对更多服务器的(只有大约三分之一的服务器复制到灾备站点)。同时启动多个服务器会对数组造成严重影响，
周四下午，我们的电力有限，所以只有核心服务在运行。这表明，一旦引导风暴平息下来，服务开始运行，来自DR阵列的流量将达到相当稳定的300MB/s。
主阵列的任何故障都会导致DR阵列(使用来自第三个站点的G200仲裁阵列的投票，以避免典型的脑裂集群问题)立即接管并开始控制磁盘。这个过程会自动将主阵列中所有复制的磁盘标记为不干净，并且主机不能在没有干预的情况下使用这些磁盘——阵列会阻塞到这些磁盘的所有路径，并将所有流量定向到灾备阵列(现在是主阵列)。由于灾备站点容量有限，且发电机备份工作尚未启动，需要尽快将磁盘复制回主站点。
这项工作持续了整个周四晚上，从灾备阵列控制器出来的各个存储FC端口的图清楚地显示了从20:00左右到23:00左右发生的最终复制回主阵列的过程，此时存储再次被切换回主阵列，正常的服务(至少在存储级别上!)恢复了。
在站点之间存储失败的命令是我们从来不需要在生产阵列上运行的，通常情况下，我们至少会有两个人查看，挠头，在按下enter之前反复检查。由于新冠疫情的限制，这项工作都是远程进行的，一名工作人员负责执行这项相当冒险的任务。最后一张图表来自他当时佩戴的苹果手表，显示了他的心率。
我认为这两个图表之间的相关性是相当明显的!