azure 最佳实践 -- 保持冗余

时间:2023-07-01 18:04:56

保持冗余
确保你的应用的部署体系是有冗余的,以避免单一节点失败的情况。
一个弹性良好的系统可以灵活的绕过系统故障。找出应用中(请求执行)的关键路径。路径中的每个节点是否都有冗余?子系统失败时,系统能否有效的转移故障?
也要考虑到业务需求。每个(节点的)冗余都会导致额外的开销和复杂度。你的架构应该考虑到业务需求的标准,例如,目标恢复时间(Recovery time objective)。再如,多区域部署肯定比单区域部署开销大,并且更难管理。需要有相应的故障转移和故障恢复的方案。对于特殊业务需求,额外的开销是合理的。
把虚拟机部署在负载均衡器后面。不要使用单一节点来处理关键任务,要确保虚拟机的部署有负载均衡机制。如果任何一台虚拟机不可用,负载均衡器会把请求发送到现有的其他虚拟机上。关于部署的详细配置,可参见Multiple VMs for scalability and availability(https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/virtual-machines-windows/multi-vm)
azure 最佳实践 -- 保持冗余

复制数据库。azure SQL数据库和Cosmos DB会自动对区域内的数据进行复制,你也可以选择开启地理区域复制选项。如果你正在使用IAAS(infrastructure as a service)数据库方案,可以选择支持复制和故障转移的数据库,例如SQL SERVER Always On Availability Groups(https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server).

启用地理复制。azure SQL数据库(https://docs.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-overview)和Cosmos DB(https://docs.microsoft.com/en-us/azure/cosmos-db/distribute-data-globally)的地理复制功能会在一个或多个备用区域中创建备用副本。在中断情况下,数据库会自动切换到备用区域写数据。

根据可用性进行分区。数据库分区经常用于提高可扩展性,但是它也用于提高可用性。如果一个(数据库)分片失败,其他分片可以使用。一个分片的失败只会影响到整个事务的一部分。
azure 最佳实践 -- 保持冗余

部署到多区域。对于要求极高可用的系统,需要进行多区域部署。这样一来,当这个区域出问题的时候(虽然很少见),就可以把应用切换到可用的区域。下图展示了一个多区域部署的应用是如何使用azure traffic manager进行故障转移的。

同步前后端的故障切换。使用azure traffic manager来转移前端故障。如果前端在一个区域不可达,traffic manager就会把请求转移到备用区域。对于不同的数据库方案,可能还需要对数据库故障进行转移。

自动故障转移,手动故障恢复。使用traffic manager进行自动故障转移,而不是自动故障恢复。自动复制恢复是有风险的,在确保主区域完全正常之前,可能被(自动故障恢复)进行了区域切换。在进行手动恢复之前,要确保所有应用的子系统都是正常的。针对不同数据库,在进行恢复之前,可能要验证数据一致性。
为traffic manager加入冗余。traffic manager是容易发生失败的节点。要审查traffic manager的SLA,并考虑使用单一节点traffic manager是否满足高可用的业务需求。如果否,考虑为traffic manager添加冗余节点以备故障恢复。如果azure traffic manager服务失败了,修改你的DNS中CNAME记录,指向其他的traffic management服务即可。