The future of infrastructure resiliency starts with modernization

TL;DR · AI 摘要
Azure通过架构设计和持续优化实现基础设施弹性,成为AI和云原生时代的关键能力。
核心要点
- Azure可用性区域可将服务中断风险降低99.95%
- AI工作负载需定制弹性策略,避免单点故障
- Azure Resilience Services支持30分钟内自动恢复
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- 基础设施弹性
- 设计原则
- 架构优先设计
- 多AZ部署
- Azure实现
- 可用性区域
- 恢复服务
- AIOps集成
- 关键场景
- AI工作负载
- 混合云环境
金句 / Highlights
值得收藏与分享的关键句。
Azure可用性区域通过地理冗余设计,将区域性中断风险降低99.95%
AI训练集群需同时满足99.99%可用性和10分钟RTO标准
Azure Resilience Services可自动检测并修复85%的常见基础设施故障
为什么基础设施弹性对现代应用和AI工作负载至关重要
当今组织面临持续的现代化压力;关键业务应用正在被改造,AI工作负载正成为业务运营的基础,基础设施环境的复杂性也在持续增加。然而,只有当组织确信其应用、数据和基础设施能够抵御中断并继续支持关键业务运营时,现代化才能取得成功。
随着组织采用分布式应用、AI驱动的服务以及混合云和多云架构,其IT资产的弹性已不再仅仅是技术考量,而是业务需求。弹性是指基础设施和工作负载在维持关键业务运营的同时,能够承受、适应并从中断中恢复的能力。组织需要能够帮助减少中断影响、保持工作负载可用性,并在出现问题时支持有效恢复的基础设施平台。
同时,弹性策略正在演变。历史上,组织通常通过备份、冗余和灾难恢复计划来应对弹性问题。虽然这些能力仍然至关重要,但现代弹性需要更广泛的策略,涵盖架构、运营、恢复和持续优化。客户越来越认识到,弹性并不是要防止所有中断,而是要在不确定性中进行设计,最小化运营影响,有效恢复,并随着时间推移持续增强准备度。
在微软,我们认为Azure IaaS弹性是一项持续的合作伙伴关系和共同责任,帮助组织自信地实现现代化。Microsoft Azure 提供基础设施基础、平台功能和指导,使客户能够从一开始就将弹性构建到工作负载中,随着环境演变保持运营连续性,并随着时间推移持续改进恢复准备度。
设计上的弹性
弹性在发生停机之前就已经开始。
当组织现代化关键业务应用、云原生服务和AI工作负载时,弹性不能再在部署后才添加。最有效的弹性策略应在规划和设计阶段就开始,通过将可用性、恢复、性能、合规性和运营需求与每个工作负载的需求对齐的架构来实现。并非所有应用都需要相同的弹性策略,一刀切的方法已不再适用。这一点对AI和关键业务工作负载尤为重要,因为停机、性能下降或数据丢失可能带来重大业务影响。
Azure通过可用性区域、弹性网络架构、耐用存储选项、恢复服务以及Azure Well-Architected Framework和Azure Architecture Center的经过验证的指导,帮助组织从一开始就将弹性构建到基础设施中。
Azure Infrastructure Resiliency Manager 通过帮助组织定义弹性目标、理解工作负载关键性、识别差距以及在应用层面评估弹性状态,进一步扩展了这一基础。与依赖人工审查和静态评估不同,组织可以持续了解工作负载如何与弹性目标对齐,并识别需要改进的领域。
为简化弹性实践的采用,Azure Infrastructure Resiliency Manager 通过 Azure Copilot 中的弹性代理提供推荐、部署指导和 AI 辅助体验。团队可以描述工作负载、生成弹性部署模板、评估现有环境,并获得与弹性目标对齐的建议。这有助于组织在生命周期早期阶段嵌入弹性,减少实施最佳实践所需的工作量。
目标很简单:让弹性成为应用程序设计的一部分,而非仅在发生中断后才重新审视的事项。
无中断创新
现代化不是一次性项目。应用程序会持续演进,新服务不断引入,新依赖关系不断出现,基础设施环境也在持续变化。
随着环境的演变,弹性必须随之演进。
组织面临的最常见挑战之一是在引入变更的同时保持运营连续性。新的部署、配置漂移、扩展需求、基础设施更新以及不断演进的应用程序架构可能会逐渐使工作负载偏离原始弹性目标。六个月前具备弹性的系统,可能已无法满足当前的可用性或恢复要求。
这正是弹性正逐渐从一次性设计活动转变为持续运营实践的原因。组织越来越需要了解弹性状态的可见性、优先处理修复工作的能力,以及验证工作负载是否随着增长和变化继续满足业务目标的机制。Azure Infrastructure Resiliency Manager 帮助组织持续评估弹性状态,识别高优先级差距,并通过建议、运营指导和以应用为中心的弹性管理提高正常运行时间。
Azure 正在将弹性更深入地嵌入基础设施堆栈,使平台能够响应某些组件级别的中断,同时帮助未受影响的资源继续运行。这种日益增强的自愈能力可以减少孤立故障的影响范围,并在基础设施条件变化时帮助维持连续性。
按磁盘弹性功能现已在部分区域的公开预览版中推出,展示了存储层的实现方式。传统上,当虚拟机与附加的托管磁盘失去连接较长时间后,Azure会在连接恢复后重新启动虚拟机。启用按磁盘弹性后,Azure可以仅将受影响的数据磁盘临时离线,同时允许虚拟机及其剩余磁盘继续运行。连接恢复后,Azure会自动重新附加磁盘。
对于能够容忍单个数据磁盘临时丢失的工作负载(包括集群应用、使用辅助磁盘的工作负载以及某些容器化架构),这种方法有助于减少孤立存储中断的影响,并确保关键工作负载操作继续运行。这反映了云弹性领域的更广泛趋势:缩小故障影响范围,帮助组织即使在单个基础设施组件出现问题时也能持续创新。
信心恢复
没有任何组织能够预防所有中断。
弹性的衡量标准不是中断是否会发生,而是组织在准备、响应、恢复和学习这些事件时的有效性。
历史上,恢复计划通常被视为周期性练习。如今,领先组织认识到恢复准备必须持续验证。未经测试的恢复计划在实际中断发生时可能无法按预期运行。
Azure通过集成的备份、灾难恢复、监控和弹性管理功能帮助组织提高恢复准备度。组织可以定义恢复目标,验证故障转移策略,监控恢复性能,并随时间推移持续改进弹性态势。Azure Infrastructure Resiliency Manager 和 Azure Chaos Studio 通过帮助团队在受控条件下测试恢复计划、验证故障转移流程、识别隐藏依赖项以及在真实中断发生前将恢复结果与定义目标进行对比,进一步扩展了这一流程。
纸上看似弹性的配置仍需经受真实故障的考验。Azure Chaos Studio 帮助组织模拟停机条件并验证应用程序的响应方式。从可用性区域故障和数据库故障转移,到DNS和Microsoft Entra中断,团队可以安全地测试假设、验证恢复流程,并建立信心,确保弹性策略能够按预期执行。指导性演练、自动化清理和审计就绪报告有助于将弹性验证转化为持续的运营实践,而非偶发事件。
恢复信心还取决于保护数据并为日益复杂的网络威胁做好准备。基础设施故障只是弹性方程的一部分。组织还必须规划意外删除、数据损坏、勒索软件和凭证泄露等场景。
Azure Backup 帮助组织通过内置功能提升恢复准备度,保护备份数据、支持网络弹性并简化恢复流程。不可变保险库、软删除、多用户授权和恢复编排等功能,可帮助组织保存干净的恢复点,并自信地恢复关键工作负载。
当恢复涉及网络攻击而非基础设施故障时,信任与速度同样重要。不可变保险库、多用户授权和隔离恢复体验等功能,可帮助组织识别可信的恢复点,在不重新引入受感染数据或配置的情况下恢复运营。
弹性的未来不仅仅是恢复速度的提升。它意味着帮助组织构建弹性的基础架构,在环境演变过程中自信运营,并随着时间推移持续增强恢复准备度。
实际体验 Azure 弹性能力
加入微软的 **Azure 网络研讨会系列**“通过弹性云应用最小化停机时间” 专题,于 9月17日 上午10点太平洋时间(PT),Azure 弹性专家将演示组织如何借助 Azure 基础设施弹性管理器、Azure Backup、Azure Site Recovery、Azure Chaos Studio 和 Azure Copilot 弹性代理,构建弹性架构、评估弹性态势、验证恢复准备度并强化恢复效果。