![]()
阿里妹导读:对象存储被广泛应用于互联网应用中,当我们打开手机观看视频、收听音乐、分享图片、浏览网页、淘宝购物时,背后的数据基本都是存在对象存储中。应用使用卡、打不开就和对象存储的可用性 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,可以通过梳理业界可用性的来龙去脉,来理解背后的技术。
业界对可用性的描述,通常采用年故障时长。比如,数据中心机房划分为不同等级,如 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分钟有效总请求数*100%
计算请求错误率时,将计算请求的时间范围拉长,对云服务有利。因为时间越长,总请求数越多,会导致错误率降低。为了更好的从客户角度计算错误率,按照 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 提升到标准型存储(本地冗余存储)为 99.99%,标准型存储(同城冗余存储)为 99.995%。该目标比原有值提升了 10 倍,为此 OSS 构筑了大量核心技术并形成体系,下一章将进行详细解读。
阿里云对象存储 OSS 是历经十年研发的云服务,始终把可用性的建设作为核心竞争力来构建,从而形成了如下的可用性体系。
![]()
整个体系从架构、IDC 建设、分布式系统、安全防护、管理机制等纬度展开,可用性的核心就是冗余和容错能力,同时要做好安全防护和管理工作。
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 高可用能力。
要实现更高的可用性,就必须在物理层做好冗余设计,包括如下的技术:
1)同城冗余多 AZ(Available Zone) 的距离和时延设计。在公共云部署时,会遵循阿里云 IDC 与网络架构设计规则及 AZ 选址标准,特别是要满足 OSS 的多 AZ 设计要求时,会严格要求时延和距离。
2)供电、制冷冗余。OSS 对象存储是多区域部署的云服务,几乎每年都会遇到自然灾害、供电异常、空调设备故障等问题,在数据中心建设时要做好双路市电和柴油发电机备电的设计,以及连续制冷能力。
3)网络冗余。OSS 作为公共云服务,既要提供外部的互联网访问、VPC 网络访问,还要提供分布式系统的内部网络连接,它们都需要做好冗余设计。
-
内部网络。OSS 是分布式存储,由多台服务器组成,采用内部网络将多台服务器连通起来,通过数据中心的机柜级交换机、机柜间交换机、机房间交换机的分层设计实现冗余,即使某台网络设备故障,系统仍然能够正常工作。
4)服务器。OSS 采用貔貅服务器系列优化性价比,基于分布式系统和软件定义存储的需求,硬件上采用通用服务器(commodity server),并提供冗余的网络接口,无需采用传统存储阵列双控冗余设计的定制硬件。
硬件的冗余设计是 OSS 高可用的关键,但分布式系统软件层的高可用设计更是核心,下一章节将重点介绍 OSS 的分布式冗余核心设计。
OSS 的分布式系统核心冗余设计,包含女娲一致性服务、盘古分布式文件系统、有巢分布式 KV、QoS 保障、网络负载均衡设计等。
女娲是阿里云飞天系统底层核心模块之一,从 2009 年飞天建立起开始自主开发,女娲对外提供一致性,分布式锁,消息通知等服务。同业界类似功能的开源软件(ZooKeeper、ETCD)相比,女娲在性能、可扩展性、和可运维性上有明显的优势。
![]()
女娲服务采用两层架构,后端是一致性维护的功能模块,前端是达到分流效果的前端机。
因此,通过多 VIP 冗余、前端机透明切换、冗余的一致性仲裁 Paxos Group,实现故障时的快速切换,从而在一致性协调时提供高可用性。
盘古 2.0 是自主研发的第二代分布式存储系统,在高性能、大规模、低成本等方面深度挖掘了系统的极限能力,支持更丰富的接入形态,进一步提升了系统的部署运维自动化智能化能力,同时继承了 1.0 在高可靠、高可用、数据强一致性等方面的积累优势。
![]()
如上图描述的架构所示,各层元数据(RootServer、NameSpaceServer、MetaServer)都提供了冗余设计,故障时可以快速切换,对于数据(ChunkServer)来说通过 None-Stop-Write 特性解决服务器、磁盘故障时的快速切换,从而在分布式存储层提高可用性。
OSS 采用自研的分布式 Key-Value 来保存元数据,它构建在盘古分布式文件系统之上,其大规模集群历经多年的业务打磨,有着非常深厚的技术积累。
有巢分布式 KV 实现了多实例冗余的特性,把 KV 分解为由多个副本成的分区组(partition group),该分区组通过一致性协议选举出 Leader 节点对外提供服务,当 Leader 节点故障或出现网络分区时,能够快速选出新的 Leader 节点并接管该分区的服务,从而提升 OSS 元数据服务的可用性,如下图所示。
![]()
OSS 服务层聚焦数据组织和功能实现,由于底层盘古和有巢的分布式能力,OSS 服务层按照无状态方式设计,从而故障时可以快速切换,提高可用性。但是,由于 OSS 是多租户模型设计,做好 QoS 的监控和隔离,是保障租户可用性的关键。
![]()
OSS 要承接海量的访问请求,因此接入层采用负载均衡,通过绑定 VIP 提供高可用服务,并且和 OSS 的前端机(FrontEnd)集群对接,任何模块故障都能能够快速切换,保证可用性。OSS 基于阿里云网络团队的负载均衡技术,提供了大流量、高性能访问能力。
![]()
OSS 提供 HTTP/HTTPS 的数据访问服务,会受到来自“互联网和VPC网络”的安全攻击,典型为 DDoS (Distribution Deny of Service),安全攻击防护是保障 OSS 可用性的重要工作。
![]()
除了上述的各种技术保障外,还有如下的管理机制来提升可用性。
尽管 OSS 将可用性 SLA 提升 10 倍,但是技术无止境,未来将在升级异常、超级热点、高频攻击等场景下继续优化可用性。
送书啦
伏羲(Fuxi)作为阿里巴巴最初创立飞天平台时的三大服务之一,十年来经历了怎样的技术演进?9 位技术专家深度解析,全面介绍伏羲调度系统及各子领域的关键技术进展,并以双11为典型场景进行最佳实践的介绍,为你呈现大数据分布式调度技术的深水区玩法。
识别下方二维码加「阿里妹」好友,回复 “送书” 立即获取吧~
![]()