一位平台架构师表示,他在2020年3月批准了一个HDInsight群集(微软公司提供的托管Hadoop产品)到我生产环境的部署。正在为期待已久的基于Azure的数据平台的下一阶段上线,当他突然从DevOps主管那里接到电话时,主管说,“我在新的生产群集上出现配置错误,无法部署。而群集无法扩展,无法获得足够的节点。虽然有足够的配额,但是没有足够的节点来扩展集群。”
事实证明,这种情况是微软Azure北欧地区数据中心容量已满。微软公司像所有云计算提供商一样,超额配置了其物理基础设施,也就是他们可以向客户提供虚拟机和CPU核心配额,因为他们知道客户不会全部尝试一次消耗掉所有容量,但却遇到了意外情况。
欧洲各国由于疫情持续蔓延而颁布出行禁令,企业必须对要求全体员工在家工作迅速做出反应。在发布出行禁令几天之后,IT部门必须应对对VDI和协作工具的空前高峰,并且他们大量地转向云计算,毕竟,这就是采用云计算技术的目的。
MicrosoftWindows虚拟桌面(基于云计算的Windows10远程工作解决方案)最近非常及时地进入了通用可用性,IT部门急于部署远程桌面解决方案。Microsoft Teams提供了可扩展且无缝的协作和电话会议解决方案,但是所有会议突然都变成了在线会议,这一峰值需要满足于某个地方的物理基础设施。
其结果是Azure数据中心对计算的需求激增,并且无法满足所有客户的需求。除了无法部署新资源之外,一些客户还难以启动现有资源,例如,一台虚拟机会在一夜之间关闭并按计划启动,而他们无法在早上再次启动。
该分析师为此与负责此特定客户的Microsoft客户团队进行了交谈,他们表示,其容量管理团队已了解情况,并正在为医疗保健和紧急服务的客户确定容量的优先级。当分析师得知有更多硬件在订购中时,情况看起来很暗淡,但供应链正在影响交货时间。
幸运的是,客户经理能够在每日容量管理会议上代表客户并提供必要容量的理由。还被告知微软公司将20,000个vCPU工作或内部工作负载移出了Azure北欧数据中心,并在一周后成功部署了HDInsight群集。
分析师目前正在为另一个客户端制定灾难恢复(DR)策略,该策略基于在一个Azure区域中发生的服务(如果不太可能发生区域性故障)的故障转移。这是一种基于微软公司自己的架构建议的标准模式。但是,如果整个Azure区域确实崩溃了,那么其余Azure区域中对资源的需求还会突然增加。在灾难恢复测试中可以实现的恢复时间目标(RTO),实际上可能由于容量限制而在实际事件中无法实现。
在设计Azure灾难恢复策略时,分析师为此提出的建议是:
- 尽管不能依靠配额来确保资源的可用性,但是需要确保在次要区域中增加配额
- 准备在发生故障转移时与Microsoft容量管理团队交谈以讨论容量问题
- 利用微软的客户团队,他们可以在发生故障转移时帮助保护容量,并根据对客户的影响和对微软公司的声誉影响来构建其案例。
- 了解在故障转移到云计算提供商时,客户的恢复时间目标(RTO)将处于优秀状态-最终您不拥有基础架构,云提供商可能无法满足需求。
- 考虑采用多云方法,使客户可以故障转移到AWS、谷歌云平台或其他云计算环境,甚至内部部署环境。