高可用

高可用

高可用,英文叫High Availability(Wikipedia词条),基本上来说,就是要让我们的计算环境(包括软硬件)做到full-time的可用性。在设计上一般来说,需要做好如下的设计:

  • 对软硬件的冗余,以消除单点故障。任何系统都会有一个或多个冗余系统做standby
  • 对故障的检测和恢复。检测故障以及用备份的结点接管故障点。这也就是failover
  • 需要很可靠的交汇点(CrossOver)。这是一些不容易冗余的结点,比如域名解析,负载均衡器等。

细节之处全是魔鬼,冗余结点最大的难题就是对于有状态的结点的数据复制和数据一致性的保证(无状态结点的冗余相对比较简单)。冗余数据所带来的一致性问题是魔鬼中的魔鬼:

  • 如果系统的数据镜像到冗余结点是异步的,那么在failover的时候就会出现数据差异的情况。
  • 如果系统在数据镜像到冗余结点是同步的,那么就会导致冗余结点越多性能越慢。

高可用的定义和度量

高可用定义

  • 可用性(availability)是关于系统可供使用时间的表述,以不可用的时间为衡量指标。不可用时间越短,可用性越高。通常用 n 个 9 来描述。
  • 可靠性(reliability)是关于系统无故障时间间隔的描述,以发生故障的次数为衡量指标,故障次数越少,可靠性越高。
  • 可维护性(maintainability)是指系统发生故障后,恢复的时间来描述。时间越短,可维护性越高。

可用性7级图表

level description
1 Crash with data corruption, destruction. 崩溃造成数据丢失
2 Crash with new data loss. 崩溃造成新数据丢失
3 Crash without data loss. 崩溃不会造成数据丢失或损坏
4 No crash, but with no or very limited service, low service quality. 通过有限制的服务防止崩溃和低质量
5 Partial or limited service, with good to medium service quality. 部分或者限制级服务具有很好的媒介质量
6 Failover with significant user visible delay, near full quality of service. 对显著延迟故障转移提供全质量服务
7 Failover with minimal to none user visible delay, near full qualityof service. 对最小延迟故障转移提供全质量服务

高可用度量

PTO/PRO

RTO和RPO是传统数据库领域常见的两个衡量高可用的指标。

  • RTO(Recovery time objective):故障恢复耗时
  • RPO(Recovery point objective):恢复后数据对应的时间点,即丢失的数据量转换为时间

请求成功率

可用性=成功请求数/总请求数

SLI(Service Level Indicator 服务等级指标)

SLI是经过仔细定义的测量指标,常见测量指标:

  • 性能
    • 响应时间(latency)
    • 吞吐量(throughput)
    • 请求量(qps)
    • 实效性(freshness)
  • 可用性
    • 运行时间(uptime)
    • 故障时间/频率
    • 可靠性
  • 质量
    • 准确性(accuracy)
    • 正确性(correctness)
    • 完整性(completeness)
    • 覆盖率(coverage)
    • 相关性(relevance)
  • 内部指标
    • 队列长度(queue length)
    • 内存占用(RAM usage)
  • 因素人
    • 响应时间(time to response)
    • 修复时间(time to fix)
    • 修复率(fraction fixed)

SLO(Service level objective 服务等级目标)

指定服务所提供功能的一种期望状态,SLO是用SLI来描述的,如:每分钟平均qps > 100k/s、99% 访问延迟 < 500ms。

SLA

服务级别协议(service-level agreement,缩写SLA)也称服务等级协议、服务水平协议,用于在商业上定义系统的高可用。SLA = SLO + 后果

Percent of Uptime(平均服务时间)

  • MTBF(Mean time between Failures): 平均故障间隔
  • MTTR(Mean time to recover): 平均修复时间
  • MTTF (Mean Time To Failure): 平均故障时间

Availability = MTBF / (MTBF + MTTR)

  可用性 数据持久度 除外条款 赔偿条款
阿里云ECS 99.95% 99.9999999% (1)不可使用的服务时间低于5分钟的,不计入不可用时间;(2)阿里云预先通知用户后进行系统维护所引起的,包括割接、维修、升级和模拟故障演练; (3)不可抗力以及意外事件引起的; 不可用时间100倍
阿里云rds 99.95%   同上,高可用版和金融版为1分钟 不可用时间100倍,高可用版和金融版,服务费的15% - 30% - 100% (99.95%-99%-95%)  
AWS EC2 99.95%   无活跃链接,运维不算,不可抗力不算 低于99.95%,赔 10%;低于99%,赔30%
AWS RDS 99.95%   类似阿里,不计时间为1分钟 低于99.95%,赔 10%;低于99%,赔25%
AWS S3 99.99% 99.999999999%    
腾讯云云主机 99.95% 99.999% 5分钟以下不计费,无其他除外条款 不可用时间100倍

高可用解决方案

Google App Engine的co-founder Ryan Barrett在2009年的Google I/O上的演讲《Transaction Across DataCenter》(视频: http://www.youtube.com/watch?v=srOgpXECblk)

主要考虑以下几个问题:

  • 容灾:数据不丢、结点的故障转移Failover
  • 数据的一致性:事务处理
  • 性能:吞吐量 、 响应时间

Master-Slave

Master-Master

Two/Three Phase Commit(2PC 两段提交)

Paxos算法

影响高可用的因素

无计划的

  • 系统级的故障 – 包括主机、操作系统、中间件、数据库、网络、电源以及外围设备
  • 数据和中介的故障 – 包括人员误操作、硬盘故障、数据乱了
  • 还有:自然灾害、人为破坏、以及供电问题。

有计划的

  • 日常任务:备份,容量规划,用户和安全管理,后台批处理应用
  • 运维相关:数据库维护、应用维护、中间件维护、操作系统维护、网络维护
  • 升级相关:数据库、应用、中间件、操作系统、网络、包括硬件升级

真正决定高可用系统的本质原因

  • 一套科学的牛逼的软件工程的管理
  • 先进的自动化的运维工具
  • 技术能力很牛逼的工程师团队

Tags:

Updated: