如何应对云端数据存储故障

亚马逊云端资料储存服务Amazon S3（Amazon Simple Storage Service），在美国时间2月28 日上午发生故障一度中断，连带使数千个采用Amazon S3服务的网站受到波及，包括软件系统服务、新闻媒体、政府机构等网站皆无法正常运作，故障持续4小时。 根据统计机构SimilarTech分析，全球约有超过15万个网站采用Amazon S3服务。科技媒体《VentureBeat》报导称，受到Amazon S3故障影响的网站，包括亚马逊自家串流直播平台 Twitch、软件系统公司Adobe、通讯平台Slack、开源平台GitHub、美国证券管理委员会（SEC）；旅游订房平台 Airbnb、Expedia；媒体网站《Business Insider》《The Verge》时代公司（Time Inc.）等等。 几天后，Amazon发布关于 AWS S3 服务中断故障公告，称一名管理员执行命令时，输错了一个字母，结果删除了一大批本不该删除的服务器。而这些服务器还支持另外两个S3子系统。虽然事后Amazon团队最终成功解决故障，但“索引子系统的恢复时间仍超过了我们的预期”，Amazon官方称。 遭遇Amazon S3中断事件后的思考 即使云计算能够提供其承诺的“像自来水和电力”一样的随用随取的资源，但是别忘了还有不期而遇的“停水”、“停电”的烦恼。 此次Amazon S3服务中断撩动了企业运维人员那根紧绷的神经。解决这类问题的原理很简单，不要把鸡蛋放在同一个篮子里。但是在云的时代，这还可能吗？ Amazon提供了一个针对这种问题的建议：“将工作负载分散到多个可用区（AZ）“。但是，这个建议不那么实诚 – 因为我们的服务不尽人意，所以用户要多给我们点钱去买更多的服务。而且，依照这个逻辑，用户更合理的做法，不是将工作负载分散到不同的Amazon AZ，而是分散到不同的云提供商，在不同的云平台之间部署应用程序。市场上除了Amazon还有很多家云提供商提供的服务并不比Amazon差。  不过，这种终极保护方式有个问题。因为不同的云之间没有统一的标准，一旦选用了亚马逊，就几乎无法再选择微软Azure或者其他云。其中的关键障碍在于数据的跨云迁移。搞过企业存储的朋友一定对这个场景有点似曾相识，这不是跟企业存储上不同存储阵列之间的兼容性壁垒是一样的吗？ 有挑战就有应对方法，就像通过SDS解决了不同存储阵列间的迁移一样，FreeStor实现了云间跳转，可以将数据在不同的云，实现数据的复制、保护和迁移。 可以说“云间跳转”功能有助于在云运营商之间实现更充分的自由竞争。虽然将一份数据放在多个云上，但用户不需要担心成本问题。 用户可以让数实现在不同的云之间进行快照或者复制，一旦一个云出现故障，可以立刻用另一个云实现接管，而不会对业务产生重大影响。这种体验就跟用户一直在用的异地双活和容灾是一样的。 云间跳转的功能不但可以避免由于云服务商的停机造成损失，还有一个好处，就是可以给用户与这些云提供商议价的优势。如果云的服务质量不满足要求，或者云的价格不能让客户满意，用户随时点几下鼠标，就可以迁移到新的云上去。这就如同原来的多厂商采购策略一样，不会被任何一个供应商绑架。