提升 10 倍！阿里云对象存储 OSS 可用性 SLA 技术揭秘

导读：对象存储被广泛应用于互联网应用中，当我们打开手机观看视频、收听音乐、分享图片、浏览网页、淘宝购物时，背后的数据基本都是存在对象存储中。应用使用卡、打不开就和对象存储的可用性 SLA 有关，SLA 越高，应用体验越好。本文分享阿里云在对象存储 OSS(Open Storage Service) 的可用性 SLA (Service Level Agreement) 上的实践和技术沉淀。

一概述

阿里云对象存储 OSS 通过十年积累的技术红利，长期在双十一淘宝应用如丝般顺滑体验需求的打磨下，2020 年 6 月将可用性 SLA 提升 10 倍，其中 OSS 标准型（同城冗余）存储，SLA 从 99.95% 提升到 99.995%，简单理解能支持 10 万张图片最多只有 5 个显示卡，下一章有详细解释。

二如何度量 OSS 可用性 SLA

要想掌握 OSS 可用性 SLA，可以通过梳理业界可用性的来龙去脉，来理解背后的技术。

1 业界常见的可用性度量为年故障时长

业界对可用性的描述，通常采用年故障时长。比如，数据中心机房划分为不同等级，如 T1～T4 机房，它们的可用性指标如下所示：

T1 机房：可用性 99.671%、年平均故障时间 28.8 小时
T2 机房：可用性 99.741%、年平均故障时间 22 小时
T3 机房：可用性 99.982%、年平均故障时间 1.6 小时
T4 机房：可用性 99.995%、年平均故障时间 0.4 小时

网络服务的可用性，通常会折算为不能提供服务的故障时间长度来衡量，比如典型的 5 个 9 可用性就表示年故障时长为 5 分钟，如下表所示。

典型如阿里云 ECS 的实例型云服务，它提供了一台计算实例，该实例的可用性直接与可用时间相关，所以它也是采用年故障时长来定义可用性。

2 对象存储 OSS 可用性 SLA 采用更苛刻的度量

对象存储是资源访问型云服务，它不提供实例而是 Serverless 化的 API 调用，按照“年故障时长”计算可用性是不合适的。所以，阿里云对象存储 OSS 选择“失败请求数：总请求数”的错误率严苛逻辑来计算可用性，如下是详细的计算过程。

每 5 分钟粒度计算错误率

每5分钟错误率 = 每5分钟失败请求数/每5分钟有效总请求数*100%

计算请求错误率时，将计算请求的时间范围拉长，对云服务有利。因为时间越长，总请求数越多，会导致错误率降低。为了更好的从客户角度计算错误率，按照 5 分钟的粒度来计算。高可用系统设计关键是冗余，而 5 分钟是业界典型的机器故障恢复时间，能够快速修复机器，可以将降低系统的错误率。

基于服务周期内的 5 分钟错误率计算可用性

服务可用性 =（1-服务周期内∑每5分钟错误率/服务周期内5分钟总个数）*100%

对象存储 OSS 按月收费，因此服务周期就是自然月。服务可用性，就是将服务周期内的每 5 分钟错误率求和，然后除以服务周期内 5 分钟总个数（按照自然月 30 天算，该值为 30*24*60/5=8640），然后用 1 减去平均错误率，就可得到该月的可用性。

根据此公式，如果每 5 分钟错误率过高，将会导致可用性下降；因此，提升每 5 分钟的请求成功率，将是提升可用性关键。

模型对比

按照全年 26 分钟故障为基础，年故障时长模型可用性为 99.995%。而 OSS 的请求错误率模型下，全年 26 分钟平均到每月大约故障 2.16 分钟，按每5分钟错误率来算，如果请求在 2.16 分钟内则全部失败，按比例来说错误率为 (2.16/5)*100%，此时可用性为：

1-{(2.16/5)*100%}/8640=99.995%

可以看出，它和年故障市场模型的可用性相同，但 OSS 上主要是带宽型应用、大请求居多，因此在故障的 2.16 分钟前后的请求都会受影响，导致可用性会稍微小于 99.995%，从某种意义上讲 OSS 的请求错误率模型略微严格。

OSS 可用性 SLA 目标

基于上述计算模型，OSS 经过长期的技术打磨，可用性 SLA 提升到标准型存储(本地冗余存储)为 99.99%，标准型存储(同城冗余存储)为 99.995%。该目标比原有值提升了 10 倍，为此 OSS 构筑了大量核心技术并形成体系，下一章将进行详细解读。

三 OSS 可用性体系建设

阿里云对象存储 OSS 是历经十年研发的云服务，始终把可用性的建设作为核心竞争力来构建，从而形成了如下的可用性体系。

整个体系从架构、IDC 建设、分布式系统、安全防护、管理机制等纬度展开，可用性的核心就是冗余和容错能力，同时要做好安全防护和管理工作。

1 本地冗余和同城冗余架构

OSS 提供了本地冗余存储（部署在一个 AZ）、同城冗余（部署在三个 AZ）存储类型，它们的逻辑架构相同，主要包含如下模块：女娲一致性服务、盘古分布式文件系统、OSS 元数据（有巢分布式 KV 索引）、OSS 服务端、网络负载均衡等。

同城冗余存储（3AZ）则是在物理架构上是提供机房级别的容灾能力，将用户数据副本分散到同城多个可用区。当出现火灾、台风、洪水、断电、断网等灾难事件，导致某个机房不可用时，OSS 仍然可以提供强一致性的服务能力。故障切换过程用户业务不中断、数据不丢失，可以满足关键业务系统对于 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）为 0 的强需求。同城冗余存储，可以提供 99.9999999999%（12 个 9）的数据设计可靠性以及 99.995% 的服务设计可用性。

介绍了顶层架构的设计，接下来讨论 IDC 内的机房、供电、制冷、网络、服务器等冗余设计，从硬件层介绍 OSS 高可用能力。

2 IDC 冗余设计

要实现更高的可用性，就必须在物理层做好冗余设计，包括如下的技术：

1）同城冗余多 AZ(Available Zone) 的距离和时延设计。在公共云部署时，会遵循阿里云 IDC 与网络架构设计规则及 AZ 选址标准，特别是要满足 OSS 的多 AZ 设计要求时，会严格要求时延和距离。

2）供电、制冷冗余。OSS 对象存储是多区域部署的云服务，几乎每年都会遇到自然灾害、供电异常、空调设备故障等问题，在数据中心建设时要做好双路市电和柴油发电机备电的设计，以及连续制冷能力。

3）网络冗余。OSS 作为公共云服务，既要提供外部的互联网访问、VPC 网络访问，还要提供分布式系统的内部网络连接，它们都需要做好冗余设计。

外部网络。互联网接入多运营商的 BGP 和静态带宽，实现公网访问的冗余。同时，VPC 网络的接入则通过阿里云网络的冗余。

内部网络。OSS 是分布式存储，由多台服务器组成，采用内部网络将多台服务器连通起来，通过数据中心的机柜级交换机、机柜间交换机、机房间交换机的分层设计实现冗余，即使某台网络设备故障，系统仍然能够正常工作。

4）服务器。OSS 采用貔貅服务器系列优化性价比，基于分布式系统和软件定义存储的需求，硬件上采用通用服务器（commodity server），并提供冗余的网络接口，无需采用传统存储阵列双控冗余设计的定制硬件。

硬件的冗余设计是 OSS 高可用的关键，但分布式系统软件层的高可用设计更是核心，下一章节将重点介绍 OSS 的分布式冗余核心设计。

3 分布式系统设计

OSS 的分布式系统核心冗余设计，包含女娲一致性服务、盘古分布式文件系统、有巢分布式 KV、QoS 保障、网络负载均衡设计等。

女娲一致性服务

女娲是阿里云飞天系统底层核心模块之一，从 2009 年飞天建立起开始自主开发，女娲对外提供一致性，分布式锁，消息通知等服务。同业界类似功能的开源软件（ZooKeeper、ETCD）相比，女娲在性能、可扩展性、和可运维性上有明显的优势。

女娲服务采用两层架构，后端是一致性维护的功能模块，前端是达到分流效果的前端机。

前端机通过 VIP 做负载均衡。主要实现两个功能：第一点，负责维护众多客户端的长连接通信，从而保证客户端请求能够均衡到后端；第二点，向客户端隐藏后端的切换过程，同时提供高效的消息通知功能。

后端由多个服务器组成 PAXOS 组，形成一致性协议核心。对客户端提供的资源（文件，锁等），在后端都有归属的 Paxos Group仲裁，它采用 PAXOS 分布式一致性协议进行同步，保证资源的一致性和持久化。为了提供更好的扩展能力，后端提供了多个 Paxos Group。

因此，通过多 VIP 冗余、前端机透明切换、冗余的一致性仲裁 Paxos Group，实现故障时的快速切换，从而在一致性协调时提供高可用性。

盘古分布式文件系统

盘古 2.0 是自主研发的第二代分布式存储系统，在高性能、大规模、低成本等方面深度挖掘了系统的极限能力，支持更丰富的接入形态，进一步提升了系统的部署运维自动化智能化能力，同时继承了 1.0 在高可靠、高可用、数据强一致性等方面的积累优势。

如上图描述的架构所示，各层元数据（RootServer、NameSpaceServer、MetaServer）都提供了冗余设计，故障时可以快速切换，对于数据（ChunkServer）来说通过 None-Stop-Write 特性解决服务器、磁盘故障时的快速切换，从而在分布式存储层提高可用性。

有巢分布式 KV(Key-Value) 元数据

OSS 采用自研的分布式 Key-Value 来保存元数据，它构建在盘古分布式文件系统之上，其大规模集群历经多年的业务打磨，有着非常深厚的技术积累。

有巢分布式 KV 实现了多实例冗余的特性，把 KV 分解为由多个副本成的分区组（partition group），该分区组通过一致性协议选举出 Leader 节点对外提供服务，当 Leader 节点故障或出现网络分区时，能够快速选出新的 Leader 节点并接管该分区的服务，从而提升 OSS 元数据服务的可用性，如下图所示。