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

╰+攻爆jí腚メ 2022-12-01 05:15 322阅读 0赞

![format_png][]

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

**一  概述**

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

![format_png 1][]

**二  如何度量 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 分钟，如下表所示。

![format_png 2][]

典型如 阿里云 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 的请求错误率模型略微严格。

![format_png 3][]

**OSS 可用性 SLA 目标**

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

**三  OSS 可用性体系建设**

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

![format_png 4][]

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

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

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

![format_png 5][]

同城冗余存储（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）相比，女娲在性能、可扩展性、和可运维性上有明显的优势。

![format_png 6][]

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

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

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

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

**盘古分布式文件系统**

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

![format_png 7][]

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

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

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

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

![format_png 8][]

**对象服务 QoS**

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

![format_png 9][]

**网络负载均衡**

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

![format_png 10][]

4  安全防护

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

*  安全攻击的一个目的，就是让 OSS 之上的业务受损失，让整体的可用性降低。

*  安全攻击的两种方法，就是拥塞 OSS 有限的带宽入口（拥塞带宽）、耗尽 OSS 的计算资源（耗尽资源）。

*  安全攻击的三类攻击方式，针对拥塞带宽的网络流量型攻击（L3/L4 DDoS），针对耗尽资源的 4 层 CC 攻击（链接资源）、7 层 CC 攻击（应用资源）。

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

![format_png 11][]

5  管理机制

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

*  库存管理。公共云服务是重资产模式，需要自己管理供应链库存，智能预测资源需求，按需提供服务是可用性的基本保证。

*  水位管理。对象存储是云存储服务，监控容量水位、带宽水位、QPS 等水位能力，进行动态的智能调度，可以优化系统的可用性。

*  稳定性文化。从开发、设计、测试、运维等环节制定稳定性制度，追求卓越的可用性能力。

*  双十一锤炼和百万级用户打磨。OSS 长期参与阿里集群双十一业务支撑，在业务洪峰的不断锤炼下，持续淬炼产品的架构、特性、稳定性。在阿里云的公共云服务体系下，有百万级用户的打磨，支撑各行各业的负载。经年累月的技术积累，总结了持续提升可用性的机制。

**四  OSS 可用性未来工作**

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

[format_png]: /images/20221123/5f8508bba60a4a8d83ae73d987eff7c8.png
[format_png 1]: /images/20221123/1254eaad6ead4c5792e0ebe5b3231981.png
[format_png 2]: /images/20221123/a950c5ae2ef94613b9b983019810493a.png
[format_png 3]: /images/20221123/c4e4e3d5d2544109b256671064f512cc.png
[format_png 4]: /images/20221123/78c61bb684e1405ba6a100322fc986aa.png
[format_png 5]: /images/20221123/03b349350917492eb58c5b2168670f1d.png
[format_png 6]: /images/20221123/e320eb6e3ecc4e6e91df95b5a46f212c.png
[format_png 7]: /images/20221123/6d09f51cb7994816ba92d186683d77cc.png
[format_png 8]: /images/20221123/b17fd5905b41405b8a872ff20b692ac2.png
[format_png 9]: /images/20221123/73e255bd2e0a4b93b17eef58112e7db7.png
[format_png 10]: /images/20221123/1510e662fc67423aa640bab9a79311e9.png
[format_png 11]: /images/20221123/27523b52795f4e3183381a2487b29d56.png