提升 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 元数据服务的可用性，如下图所示。

对象服务 QoS

OSS 服务层聚焦数据组织和功能实现，由于底层盘古和有巢的分布式能力，OSS 服务层按照无状态方式设计，从而故障时可以快速切换，提高可用性。但是，由于 OSS 是多租户模型设计，做好 QoS 的监控和隔离，是保障租户可用性的关键。

网络负载均衡

OSS 要承接海量的访问请求，因此接入层采用负载均衡，通过绑定 VIP 提供高可用服务，并且和 OSS 的前端机（FrontEnd）集群对接，任何模块故障都能能够快速切换，保证可用性。OSS 基于阿里云网络团队的负载均衡技术，提供了大流量、高性能访问能力。

4 安全防护

OSS 提供 HTTP/HTTPS 的数据访问服务，会受到来自“互联网和VPC网络”的安全攻击，典型为 DDoS (Distribution Deny of Service)，安全攻击防护是保障 OSS 可用性的重要工作。

• 安全攻击的一个目的，就是让 OSS 之上的业务受损失，让整体的可用性降低。
• 安全攻击的两种方法，就是拥塞 OSS 有限的带宽入口（拥塞带宽）、耗尽 OSS 的计算资源（耗尽资源）。
• 安全攻击的三类攻击方式，针对拥塞带宽的网络流量型攻击（L3/L4 DDoS），针对耗尽资源的 4 层 CC 攻击（链接资源）、7 层 CC 攻击（应用资源）。

细化的攻击分类，如下表所示。

5 管理机制

除了上述的各种技术保障外，还有如下的管理机制来提升可用性。

• 库存管理。公共云服务是重资产模式，需要自己管理供应链库存，智能预测资源需求，按需提供服务是可用性的基本保证。
• 水位管理。对象存储是云存储服务，监控容量水位、带宽水位、QPS 等水位能力，进行动态的智能调度，可以优化系统的可用性。
• 稳定性文化。从开发、设计、测试、运维等环节制定稳定性制度，追求卓越的可用性能力。
• 双十一锤炼和百万级用户打磨。OSS 长期参与阿里集群双十一业务支撑，在业务洪峰的不断锤炼下，持续淬炼产品的架构、特性、稳定性。在阿里云的公共云服务体系下，有百万级用户的打磨，支撑各行各业的负载。经年累月的技术积累，总结了持续提升可用性的机制。

四 OSS 可用性未来工作

尽管 OSS 将可用性 SLA 提升 10 倍，但是技术无止境，未来将在升级异常、超级热点、高频攻击等场景下继续优化可用性。