免责声明:以下内容旨在概述产品的总体发展方向。仅供参考,不可纳入任何合同。该内容不构成提供任何资料、代码或功能的承诺,并且不应该作为制定购买决策的依据。此处所述有关 Oracle 产品的任何特性或功能的开发、发布、时间计划及定价事宜均由 Oracle Corporation 自行决定。
此常见问题解答文档用于回答以下方面的常见问题:Oracle 如何实现核心基础设施服务和托管平台的可恢复性及持续可用性。OCI 客户可能会对这些解答感兴趣,因为:
我们不做出这样的区分。但是,我们按照依赖关系层、可用性范围以及数据层与控制层对服务进行了分类。利用这些类别,我们可以在可用性、持久性、性能和便捷性之间进行权衡,以提供各种有用的解决方案。
依赖关系层
您可以将这些层想象成架构示意图中的层。每层只依赖它下面的层。
由下至上:
可用性范围
为了实现服务的可用性及持久性目标,您可以为每个服务选择以下其中一个可用性范围:
控制平面与数据平面
服务的数据平面是数据处理接口和组件的集合,用于实施供各种应用使用的服务功能。例如,Virtual Cloud Network (VCN) 数据层包含网络数据包处理系统、虚拟路由器和网关;Block Volumes 数据层包含 iSCSI 协议实施,以及用于保存卷数据的具有容错能力的复制存储系统。
服务的控制平面是 API 和组件的集合,负责以下任务:
对于所有类型的服务,我们使用同一套工程设计原则来实现可恢复性及可用性,因为无论是哪种类型的服务,构建具有容错能力且可扩展的分布式系统所面临的基本工程难题都是相同的。
为了实现可恢复性及持续可用性,我们需要了解导致云级别系统不可用(性能降级和故障未处理)的所有原因,然后采取适当的措施。由于相关原因有很多,我们根据基本特性将原因进行分类.
过去,企业 IT 系统的可用性分析会重点关注硬件故障这一类别。但对于云系统,硬件故障相对而言是小问题,而且出现的问题都很容易理解。现在,大多数单点硬件故障都比较容易避免或缓解。例如,机架可以采用双供电装置并关联的电源分配单元,而且许多组件都是可热插拔的。当然,也有可能会发生大规模硬件故障和数据丢失,例如遭受自然灾害。然而,根据我们的经验以及其他云技术供应商公布的事后分析报告,与导致不可用的其他原因相比,整个数据中心发生故障或数据丢失的情况非常罕见。虽然仍有大规模的硬件故障需要处理(例如,使用灾难恢复和其他机制),但那绝对不是导致可用性问题的主要因素。
云级别系统不可用的主要原因如下:
这些挑战普遍存在,也是云级别分布式系统的一种“物理定律”,难以避免。
对于上述每种类别的问题,我们采用经过检验的工程设计战略来处理。其中的重点包括:
架构和系统设计原则
这类原则有很多,但我们只重点讨论与可恢复性和可用性紧密相关的几点。
面向恢复的计算
为了处理只在局部产生影响的软件错误和操作员错误,我们遵循面向恢复的计算1原则。在高层次上,这意味着,与其试图保证我们永远不会面对问题(这是无法测试的),不如专注于以一种可以测试的方式,不露痕迹地处理任何问题。特别是,我们致力于大幅缩短平均恢复时间 (Mean Time To Recovery, MTTR)。该时间是平均检测时间、平均诊断时间和平均缓解时间的总和。
我们的目标是尽快恢复,以确保问题不会给用户带来不便。以下几点可以帮助我们实现此目标:
尽可能减小问题的影响
为了处理可能造成大范围影响的软件错误和人工错误,我们构建了尽可能减小问题“影响范围”的机制。也就是说,我们致力于尽可能减少受问题影响的客户数、系统数或资源数,包括租户“相互干扰”、超载、容量降级和分布式抖动这些高难度的问题。为实现此目标,我们采用了各种隔离边界和更改管理做法(请参阅接下来的部分)。
从设计原则中衍生的架构概念
这类概念有许多,但这里我们只重点介绍限制影响范围的概念。
我们的公共 API 中引入的位置概念:区域、可用性域和容错域
容错域相对较新,我们会比较详细地介绍。
如果在主动更改系统(例如部署、打补丁、虚拟机管理程序重新启动和物理维护)时发生问题,容错域可以限制问题影响范围。
我们可以保证的是,在给定可用性域中,在任意时间点,至多只会有一个容错域中的资源发生更改。如果更改过程中出现问题,则该容错域中的部分或所有资源可能在一段时间内不可用,但可用性域中的其他容错域不受影响。每个可用性域至少包含三个容错域,目的就是为了确保在单个可用性域中托管的基于仲裁的复制系统(例如 Oracle Data Guard)具有高可用性。
这样,对于主要可用性问题(软件错误、配置错误、操作员错误和更改过程中出现的性能问题),每个容错域都可充当可用性域中的一个独立逻辑数据中心。
容错域还可以防范某些只在局部产生影响的硬件故障。容错域的特性可以充分有效地保证,位于不同容错域中的资源不会同时受到可用性域中任何潜在单点硬件故障的影响。例如,位于不同容错域中的资源不会共享同一“顶层”网络交换机,因为此类交换机的标准设计不具备冗余性。
然而,容错域只能够保护本地的硬件或物理环境。故障域与可用性域和区域不同,它不为基础设施提供任何大规模的物理隔离。在极少数情况下(发生自然灾害或可用性域范围的基础设施故障),多个容错域中的资源可能会同时受到影响。
我们内部服务使用容错域的方式与客户使用容错域的方式相同。例如,Block Volumes、Object Storage 和 File Storage 在三个独立容错域中存储数据副本。所有控制层和数据层的全部组件在这三个容错域中托管(在包含多个可用性域的区域中,在多个可用性域中托管)。
服务单元
服务单元用于限制不是在主动更改系统时发生的问题的影响范围。由于多租户云系统的工作负载随时可能发生巨大变化,并且大型分布式系统随时可能会发生复杂的局部故障,因此可能会出现此类问题。这些情况可能会触发不易察觉的隐藏错误或紧急的性能问题。
此外,对于在主动更改系统时发生的一些很少见但颇有难度的问题,服务单元也可以限制影响范围。这类问题的一个典型示例是,部署到单个容错域看起来已成功(未出现错误或性能变化),但更新第二个或最后一个容错域后,新交互在系统中(在运行生产负载的整个云范围内)引发了性能问题。
请注意,此处使用的服务单元是一种架构模式,并不是 Oracle Cloud API 或 SDK 中明确指定的概念。任何多租户系统都可以使用此架构模式,不需要从平台获得任何特殊支持。
服务单元的工作方式如下:
这样,每个服务单元是可用性域或区域中的另一种“逻辑数据中心”— 即用于实现性能隔离和故障隔离的一种逻辑分组。
概括地说,服务单元和容错域互为补充,具体表现在以下几个方面:
在执行部署和打补丁时,可以将容错域和服务单元的特性组合起来,形成统一的战略。
服务工程设计程序
出色的测试和运行对云系统的可靠性至关重要,为此我们提供了大量工程设计程序。以下是其中一些较为重要的程序,它们利用了前面部分中提到的概念:
可以。在每个区域中,所有可用性域提供一组相同的服务。
在包含单个可用性域的区域中,客户可以使用容错域(相互之间实现了故障隔离的逻辑组)来获得多个“逻辑数据中心”所具有的大多数特性。客户还可以使用多个区域来实现灾难恢复 (Disaster Recovery, DR)。
在包含多个可用性域的区域中,客户可以按相同的方式来使用容错域。客户还可以结合使用可用性域本地服务、可用性域间故障转移功能(例如 Data Guard 的 DBaaS)和区域服务(Object Storage、Streaming),在更高级别的“逻辑数据中心”(可用性域)实现完全的高可用性。此外,客户还可以使用多个区域实现 DR。
在所有情况下,客户都可以利用服务单元这一概念进一步隔离更严重的问题,例如分布式抖动。
我们通过容错域、服务单元以及用于增量部署和验证的操作程序来实现这一点。请参阅此文档前面部分的内容。
可以。所有类别的服务都跨多个逻辑数据中心(实现了故障隔离和性能隔离的独立逻辑分组)进行部署,以实现可恢复性及持续可用性。
如本文前面部分所述,在包含单个可用性域的区域中,我们提供了容错域机制来实现“多个逻辑数据中心”。
在包含多个可用性域的区域中,我们的服务和功能可以为同步复制的数据提供更高级别的物理持久性(由于区域中可用性域之间的距离和光速,会产生一定的性能损失和成本,但微乎其微)。
我们不提供跨区域的自动保持高可用性或故障转移机制,因为这需要在区域之间建立紧密耦合关系,从而带来多个区域同时出现问题的风险。但是,我们支持在区域之间进行各种形式的异步复制,并且还在不断增加功能(例如异步复制和备份)来实现跨区域的灾难恢复。
这个问题比较复杂。为了阐述清楚,我们从几个方面来说明:
答案分为两个部分。
我们利用架构原则来大幅减少存在依赖关系的服务发生相关性故障。在某些情况下,此方法可以大幅降低出现相关性故障的可能性,从可用性服务级别协议 (SLA) 的角度而言,甚至能达到可以忽略的程度。
特别是,我们还使用了服务单元,这一点在之前的部分已经介绍过了。单元有助于解决该问题 — 如果内部服务 A 所依赖的服务之一(即服务 B)发生问题会影响服务 A,那么服务 B 的问题很可能被限制在单个单元内。对于使用服务 B 的其他更高层服务和客户的自有应用,它们使用的可能是不受影响的其他单元。这是一个因单元数而异的概率问题,而单元数是一个必定会变化(增加)的内部隐藏参数,因此我们不对超出服务 A 和 B 的独立服务 SLA 的情况提供任何量化声明或保证。但实际上,服务单元确实可以显著减少服务之间的故障相关性。
我们的许多内部共享服务(例如,控制层的工作流和元数据服务,以及 Streaming/Messaging 服务)都使用服务单元来隔离故障,以保护使用它们的上游服务。
以下只是一些大方向的指导,因为服务的底层实施和具体情况会发生变化,而且一定会发生变化。但是,对于计算、存储、网络和身份验证/授权等主要方面,我们指明了以下依赖项。
对于控制层,常见依赖项如下:
一些控制层很明显具有特定于服务的依赖项。例如,当启动裸金属或 VM 实例时,计算控制层需要依赖:
对于核心服务数据层,一般设计原则是每个数据层应确保只有最少的依赖项,以实现高可用性、快速诊断和快速恢复。该原则产生的结果如下:
对于 IaaS 数据层,一般原则是仅依赖于核心或更低层的数据层(以避免出现循环依赖)。
可以,Oracle Cloud Infrastructure 服务的架构与区域无关,因此即使区域与其他 Oracle Cloud Infrastructure 区域和/或全局控制层隔离,Oracle Cloud Infrastructure 区域中的服务仍可以继续运行。即使区域处于隔离状态,数据平面和控制平面功能(包括服务 API 端点)仍然可用。
许多 Oracle Cloud Infrastructure 服务提供跨区域功能,例如 Oracle Cloud Infrastructure 对象存储提供的跨区域对象复制功能。Oracle Cloud Infrastructure 中的跨区域功能始终构建为核心服务之上的一层,因此即使跨区域功能受到影响,区域隔离也不会影响核心服务。例如,Oracle Cloud Infrastructure 对象存储跨区域复制功能被构建为对象存储服务之上的一层,因此,区域的隔离可能会影响相关的跨区域复制功能,但不会影响区域中的核心对象存储服务。
是的,即使在与相应的区域控制层隔离的情况下,Oracle Cloud Infrastructure 服务的架构使得每个逻辑数据中心中的数据层功能也能继续运行。例如,即使数据中心与计算、区块存储、VCN 和/或身份与访问管理的控制层功能隔离,逻辑数据中心中的 Oracle Cloud Infrastructure 计算实例将继续与附加的块存储卷和关联的虚拟网络功能一起运行。
可以。Oracle Cloud Infrastructure 通过所有商业区域的多个冗余提供商连接到互联网。这些连接使用 BGP(边界网关协议)。
注:为免疑义,本网页所用以下术语专指以下含义: