应用云平台的可用性——从新浪SAE看云平台设计.docVIP

一、可用性如何定义 可用性(availability)是关于系统可供使用时间的表述，以不可用的时间为衡量指标。不可用时间越短，可用性越高。通常用n个9来描述。比如4个9的可用性，则是指一年中不可用时间在52分钟内，平均每周不可用时间在1分钟。 可靠性(reliablity)是关于系统无故障时间间隔的描述，以发生故障的次数为衡量指标，故障次数越少，可靠性越高 可维护性(maintainability)系统发生故障后，恢复的时间来描述。时间越短，可维护性越高。 从上面三者关系看出，服务的可靠性、可维护性越高，可用性就越高。这就要求我们在服务开发和管理中做到：提高服务系统的稳定性、改善软件的可管理性和可维护性。 对于SAE云计算平台而言，可用性包含三个方面：SAE自身服务可用性、网络可用性、SAE平台上数据可用性。 二、如何打造高可用的平台 1、软件设计和系统架构 软件是互联网服务的载体。良好的软件对于服务的可用性至关重要。从可用性定义来看，我们在软件设计时，既要考虑可靠性，又要考虑可维护性。 可靠性：这主要体现在软件本身的稳定性和容错性上。软件的稳定性很大程度上取决于代码质量，设计再优良的系统都有可能在实现上质量控制不好而导致失 败。软件的容错则主要体现在两个方面：避免单点的高可用设计和自治独立原则。软件系统要做到足够健壮,在发生一些硬件或网络故障时就需要能够做到冗余，继 续提供服务。即发生故障的次数足够低 比如某个服务，可能有3个系统单元。每个单元都不应该存在单点，某个服务器宕机不应当导致服务不可用。由于IDC故障的频繁，现在越来越多的设计在 考虑当某个IDC不可用时，服务要能够继续提高服务，即跨IDC机房的高可用。另外软件设计时要求足够自治独立，不可过多依赖网络和其他服务单元，对于互 联网服务，阻塞是最大的敌人，在一个系统中由于一个微不足道的连接阻塞，而导致整个系统服务不可用，这样的例子实在是太多，所以对于互联网服务，需要牢 记：服务要足够自治独立，避免阻塞。 下图简单说明了SAE平台的负载均衡服务是如何避免单点故障的。 可维护性：软件要易于管理维护，能够和现有的运维系统整合，比如说配置管理、日志管理等，避免自立规范。软件的管理维护简单，对于发生故障时缩短恢复时长是有重要帮助的。 2、服务实施时引入破坏测试 好的软件设计开发完成后，在部署环节，一定要实际测试在设计时定下来的目标，比如说避免单点，就需要部署时，实际去破坏。对其他各种容错的处理是否 真的到位。我们常见的做法是关机测试、重启检验服务自恢复能力、拔网线等测试，同时观察软件系统是否运行正常。这主要仍然是围绕服务可靠性进行测试。 3、实时的、立体的、可视化监控 一个服务，除了自身软件外，还包含了监控，监控应当视为服务的一部分。服务上线一定是包含了监控。监控是最好的质量保证措施。SAE平台在Alpha版上线时就有了各种监控，监控是平台不可分离的一部分。对于监控，我们积累了一些经验. 实时：要能够及时发现问题、抢在用户的前面发现问题 立体：这要求我们的监控是多层次的立体式的，立体监控最大的好处是快速定位故障原因，有助于快速解决问题。毕竟同样的现象，背后可能有很多种可能。 我们的监控包含：系统监控(负载,磁盘IO等)、网络TCP三次握手监控(只要节点之间发生网络关系的都需要监控)、服务自身可用性监控、错误日志趋势监 控(当服务的错误数量突然增加时可以捕捉到) 可视化：这是从监控工具的易用性而言。可视化更加有利于发现和分析问题。 自我恢复：这主要体现在服务监控里。服务的监控包含两个部分，首先是根据服务所承诺的各项功能的黑盒测试，这主要是模拟用户发起。其次是服务所在的 节点上有部署自我检查自我修复的程序，当自我诊断认为有故障时，程序会尝试多种恢复方法。这极大降低了故障服务时长，有效提高了服务可用的时间。SAE平 台底层有这样一套系统在不间断地运行。 报警：监控是为了更快发现问题，能够自动处理的让机器自动完成，不能自动完成的就需要人工处理，这就需要有报警机制。SAE内部开发了一个叫“报警 网关”的系统，所有的监控都是直接对接该报警网关。网关的优点是可以做分析、排重，并且是有上下文的报警。我们报警的原则：过犹不及。当运维人员收到过多 报警，并且包含了大量的误报时，这样的报警时没有价值的，要坚决抵制。 故障响应：相关人员接到报警后，根据故障级别进行响应。 严重故障，影响到平台的稳定运行，白天要求5分钟内响应，夜间15分钟响应。 次级故障，不影响应用的运行，但可能影响到用户的管理和使用白天要求15分钟响应，夜间要求2小时响应 警告级别故障，这种报警不影响服务，不影响使用，但需要提示有隐患。白天要求1小时，夜间不要求响应，但要求早晨立刻处理，避免故障升级。 快速的故障发现、自我修复和故障响应