关于 Oracle Cloud Infrastructure 服务和平台可恢复性及持续可用性的常见问题解答

免责声明:以下内容旨在概述产品的总体发展方向。仅供参考,不可纳入任何合同。该内容不构成提供任何资料、代码或功能的承诺,并且不应该作为制定购买决策的依据。此处所述有关 Oracle 产品的任何特性或功能的开发、发布、时间计划及定价事宜均由 Oracle Corporation 自行决定。

此常见问题解答文档用于回答以下方面的常见问题:Oracle 如何实现核心基础设施服务和托管平台的可恢复性及持续可用性。OCI 客户可能会对这些解答感兴趣,因为:

  • 这些解答可以帮助客户在评估 Oracle 托管平台和服务时执行尽职调查。
  • 其中的许多解答讨论了所有云级别系统都面临的基本挑战和解决方案,并可以帮助客户确定他们希望在云中构建的系统的架构和设计。

关于 Oracle Cloud Infrastructure 服务和平台可恢复性及持续可用性的常见问题解答

全部展开 全部收起
    • Oracle 是否区分不同服务类别,例如关键服务、持续可用服务或单一位置服务?

      我们不做出这样的区分。但是,我们按照依赖关系层、可用性范围以及数据层与控制层对服务进行了分类。利用这些类别,我们可以在可用性、持久性、性能和便捷性之间进行权衡,以提供各种有用的解决方案。

      依赖关系层

      您可以将这些层想象成架构示意图中的层。每层只依赖它下面的层。

      由下至上:

      • 核心服务:这些服务构成了 Oracle Cloud Infrastructure 的基础。Identity and Access Management (IAM)、Key Management、Networking、Compute、Block Volumes、Object Storage、Telemetry 和一些内部共享服务都属于这一类。它们的依赖项很少,相互之间的依赖程度也很低。(有关依赖项的详细信息,请参阅本文后面的内容)。
      • IaaS:该层提供基于核心服务构建的更多基础设施层功能。该层中的服务包括 File Storage、Database 和 Container Engine for Kubernetes (OKE)。
      • SaaS:这是基于下面的层构建的功能丰富的软件即服务层。

      可用性范围

      为了实现服务的可用性及持久性目标,您可以为每个服务选择以下其中一个可用性范围:

      • 可用性域本地:每个可用性域包含一个独立的服务实例。此类服务通过对在同一可用性域中的副本进行同步复制,保证存储数据的高持久性(有关详细信息,请参阅本文后面有关故障域的部分)。这些服务可以承受可用性域中的第三个或其他基础设施出现故障,具体取决于服务的性质。为了实现这种级别的容错能力,可用性域本地服务在可用性域中使用两种类型的逻辑数据中心 — 故障隔离的逻辑组和性能隔离的逻辑组。有关详细信息,请参阅本文后面有关故障域和服务单元的部分。此外,即使可用性域无法与任何其他可用性域通信,这些服务仍将可以继续正常运行。因此,它们可以承受其他可用性域断开连接或者区域中的广域网完全无法通信。
      • 包含多个可用性域的区域:每个区域具有多个可用性域,且包含一个独立的服务实例。组件位于该区域内的每个可用性域中。这些服务将同步复制到同一区域中的多个可用性域,为所存储的数据提供非常高的持久性。这些服务能够容忍区域中的任何一个可用性域出现故障或无法通信。
      • 包含单个可用性域的区域:如果区域仅包含单个可用性域,则区域服务可观测到的特征与前面所述的可用性域本地服务一样。只有在通过添加一个或多个可用性域来扩展包含单个可用性域的区域时,才会看出包含单个可用性域的区域服务与可用性域本地服务之间的区别。在这种情况下,每个区域服务将自动扩展以适当地使用新可用性域,同时保留服务的单个实例。例如,Object Storage 数据层可以扩展来使用更多可用性域,以提高现有数据的持久性。但是,对于可用性域本地服务,每个新可用性域会收到每个可用性域本地服务的独立新实例。
      • 跨区域分布:Oracle Cloud Infrastructure 的基本原则是每个区域尽可能独立于其他区域运行。尽可能这个限定词反映了一个事实,即区域必定会至少共享某些基础设施,例如区域间干线网络。我们未在区域之间建立紧密耦合机制(例如,透明的高可用性或故障转移),这种机制可能会导致某些问题同时影响多个区域。相反,我们通过松散耦合提供了两种跨区域分布服务的机制:
        • 灾难恢复 (Disaster Recovery, DR):我们在云中大力投入和推行的基本方法是允许客户构建具有 DR 特征的系统。一些核心服务已提供 DR 机制,例如 Block Volumes 的区域间备份和对象存储的区域间复制。在我们所有服务的发展路线图中,DR 功能一直是重中之重。
        • 跨区域订阅:我们目前仅针对 IAM 数据提供跨区域订阅。从概念上讲,IAM 数据具有全局范围。客户可以订阅(选择加入)一组区域,然后系统自动将相关 IAM 数据和后续更新复制到指定的区域。为了避免紧密耦合,系统进行异步复制并确保一致。客户在他们指定的“主”区域中修改 IAM 数据。如果当前主区域不可用或不适用,则可以指定其他区域。

      控制平面与数据平面

      服务的数据平面是数据处理接口和组件的集合,用于实施供各种应用使用的服务功能。例如,Virtual Cloud Network (VCN) 数据层包含网络数据包处理系统、虚拟路由器和网关;Block Volumes 数据层包含 iSCSI 协议实施,以及用于保存卷数据的具有容错能力的复制存储系统。

      服务的控制平面是 API 和组件的集合,负责以下任务:

      • 处理客户请求,包括预配、重新配置、扩展/收缩或终止资源
      • 安全快速地自动执行批量打补丁
      • 检测出现故障、降级或配置错误的资源
      • 执行自动修复,或者联系人运营商以获取帮助
      • 与其他控制层协作(例如,在 LaunchInstance 期间,Compute、VCN、Block Storage 会协同工作)
      • 管理未使用的容量
      • 配合人工操作,例如连接新设备以及进行实体修复和维护
      • 帮助了解运行状况和进行控制
    • Oracle 如何确保服务的可恢复性及持续可用性?

      对于所有类型的服务,我们使用同一套工程设计原则来实现可恢复性及可用性,因为无论是哪种类型的服务,构建具有容错能力且可扩展的分布式系统所面临的基本工程难题都是相同的。

      为了实现可恢复性及持续可用性,我们需要了解导致云级别系统不可用(性能降级和故障未处理)的所有原因,然后采取适当的措施。由于相关原因有很多,我们根据基本特性将原因进行分类.

      过去,企业 IT 系统的可用性分析会重点关注硬件故障这一类别。但对于云系统,硬件故障相对而言是小问题,而且出现的问题都很容易理解。现在,大多数单点硬件故障都比较容易避免或缓解。例如,机架可以采用双供电装置并关联的电源分配单元,而且许多组件都是可热插拔的。当然,也有可能会发生大规模硬件故障和数据丢失,例如遭受自然灾害。然而,根据我们的经验以及其他云技术供应商公布的事后分析报告,与导致不可用的其他原因相比,整个数据中心发生故障或数据丢失的情况非常罕见。虽然仍有大规模的硬件故障需要处理(例如,使用灾难恢复和其他机制),但那绝对不是导致可用性问题的主要因素。

      云级别系统不可用的主要原因如下:

      • 软件错误
      • 配置错误
      • 人工操作员错误
        :到目前为止,业界总结出的主要教训是,这三种形式的人为错误是导致不可用的主要原因。虽然通过工具、自动化和培训可以减少出错频率,但无法根除。因此,在系统的架构、设计和实施时,我们必须重点关注这些方面。
      • 各种原因导致的性能出现不可接受的变化(延迟或吞吐量),包括:
        • 多租户“相互干扰”(QoS 机制出现故障)
        • 无法高效地拒绝超负荷(意外或恶意),同时继续完成有用的工作
        • 分布式抖动、消息风暴、重试风暴和其他开销很大的“紧急”交互
        • 关开机循环后进行冷冲击(清空缓存),特别是多个系统同时进行关开机循环
        • 扩展系统(例如重新分片)时超载
      • 无法限制上述问题的“影响范围”(受影响的客户和系统数)

      这些挑战普遍存在,也是云级别分布式系统的一种“物理定律”,难以避免。

      对于上述每种类别的问题,我们采用经过检验的工程设计战略来处理。其中的重点包括:

      • 架构和系统设计原则
      • 新架构概念(通常从原则中衍生而来)
      • 服务工程设计程序

      架构和系统设计原则

      这类原则有很多,但我们只重点讨论与可恢复性和可用性紧密相关的几点。

      面向恢复的计算

      为了处理只在局部产生影响的软件错误和操作员错误,我们遵循面向恢复的计算1原则。在高层次上,这意味着,与其试图保证我们永远不会面对问题(这是无法测试的),不如专注于以一种可以测试的方式,不露痕迹地处理任何问题。特别是,我们致力于大幅缩短平均恢复时间 (Mean Time To Recovery, MTTR)。该时间是平均检测时间、平均诊断时间和平均缓解时间的总和。

      我们的目标是尽快恢复,以确保问题不会给用户带来不便。以下几点可以帮助我们实现此目标:

      • 通过在代码中大量使用断言并在各个级别主动监视和发出警报,确保快速地自动检测软件错误和操作员错误的症状。
      • 将功能打包成许多独立的细粒度隔离单元(线程、进程、纤程、状态机等),并让这些单元松散耦合(即不直接共享有可能损坏的内存)。
      • 检测到软件错误或操作员错误的症状时,尽快地自动重新启动封闭的隔离单元。重新启动是尝试从任意故障中恢复的可行方式,因为它会尝试重建经过严格测试的状态,进而恢复不可变因素。
      • 如果在细粒度隔离级别进行恢复行不通(例如,断言在该级别持续频繁触发,从而导致循环崩溃),则升级到下一个更大的单元(进程、运行时、主机、逻辑数据中心、联系人工操作员)。
      • 构建允许“在系统范围内撤消”的机制,包括对所有持久状态和配置进行版本控制,以快速识别和撤消错误提交。

      尽可能减小问题的影响

      为了处理可能造成大范围影响的软件错误和人工错误,我们构建了尽可能减小问题“影响范围”的机制。也就是说,我们致力于尽可能减少受问题影响的客户数、系统数或资源数,包括租户“相互干扰”、超载、容量降级和分布式抖动这些高难度的问题。为实现此目标,我们采用了各种隔离边界和更改管理做法(请参阅接下来的部分)。

      从设计原则中衍生的架构概念

      这类概念有许多,但这里我们只重点介绍限制影响范围的概念。

      我们的公共 API 中引入的位置概念:区域、可用性域和容错域

      容错域相对较新,我们会比较详细地介绍。

      如果在主动更改系统(例如部署、打补丁、虚拟机管理程序重新启动和物理维护)时发生问题,容错域可以限制问题影响范围。

      我们可以保证的是,在给定可用性域中,在任意时间点,至多只会有一个容错域中的资源发生更改。如果更改过程中出现问题,则该容错域中的部分或所有资源可能在一段时间内不可用,但可用性域中的其他容错域不受影响。每个可用性域至少包含三个容错域,目的就是为了确保在单个可用性域中托管的基于仲裁的复制系统(例如 Oracle Data Guard)具有高可用性。

      这样,对于主要可用性问题(软件错误、配置错误、操作员错误和更改过程中出现的性能问题),每个容错域都可充当可用性域中的一个独立逻辑数据中心。

      容错域还可以防范某些只在局部产生影响的硬件故障。容错域的特性可以充分有效地保证,位于不同容错域中的资源不会同时受到可用性域中任何潜在单点硬件故障的影响。例如,位于不同容错域中的资源不会共享同一“顶层”网络交换机,因为此类交换机的标准设计不具备冗余性。

      然而,容错域只能够保护本地的硬件或物理环境。故障域与可用性域和区域不同,它不为基础设施提供任何大规模的物理隔离。在极少数情况下(发生自然灾害或可用性域范围的基础设施故障),多个容错域中的资源可能会同时受到影响。

      我们内部服务使用容错域的方式与客户使用容错域的方式相同。例如,Block Volumes、Object Storage 和 File Storage 在三个独立容错域中存储数据副本。所有控制层和数据层的全部组件在这三个容错域中托管(在包含多个可用性域的区域中,在多个可用性域中托管)。

      服务单元

      服务单元用于限制不是在主动更改系统时发生的问题的影响范围。由于多租户云系统的工作负载随时可能发生巨大变化,并且大型分布式系统随时可能会发生复杂的局部故障,因此可能会出现此类问题。这些情况可能会触发不易察觉的隐藏错误或紧急的性能问题。

      此外,对于在主动更改系统时发生的一些很少见但颇有难度的问题,服务单元也可以限制影响范围。这类问题的一个典型示例是,部署到单个容错域看起来已成功(未出现错误或性能变化),但更新第二个或最后一个容错域后,新交互在系统中(在运行生产负载的整个云范围内)引发了性能问题。

      请注意,此处使用的服务单元是一种架构模式,并不是 Oracle Cloud API 或 SDK 中明确指定的概念。任何多租户系统都可以使用此架构模式,不需要从平台获得任何特殊支持。

      服务单元的工作方式如下:

      • 每个服务实例(例如,在特定区域中,或者在可用性域本地服务的特定可用性域中)包含服务软件堆栈的多个独立部署。每个独立部署称为单元。每个单元应尽可能用自己的基础设施托管。至少,单元之间不共享主机或 VM。
      • 起初,服务在每个可用性域或区域中可能只有几个单元。随着服务不断扩展以满足不断增长的需求,越来越多的单元添加进来,以限制问题的影响范围。大型的热门服务可能有许多单元。换言之,单元提供 n 对 m 多路复用,以将客户负载分散到多个独立的托管环境中 — 也就是独立的资源隔离组。单元没有明确的基数,不像容错域那样。(如前所述,一种显而易见的容错域基数选择是每个可用性域三个容错域,这可以使在单个可用性域中托管的基于仲裁的复制系统具有高可用性。)
      • 系统会将客户工作负载的每个“天然单元”分配给一个特定单元格。“天然单元”的定义取决于特定服务的性质。例如,对于内部共享 Workflow 服务(稍后介绍),天然单元可以是“此可用性域或区域中特定控制层的所有工作流”。
      • 每组单元的前端是精简路由层或用于发现单元端点的 API。例如,Streaming/Messaging 系统具有用于发现当前数据层端点是否含有特定主题的 API,内部元数据存储在每个单元具有不同的端点。然而,其他一些基于单元的服务具有单一的数据层端点和共享路由层。路由层可能导致多个单元发生相关性故障,但这可以通过以下方式得到缓解:确保路由层精简、可预测且高性能(无开销很大的操作),为路由层预配较大的空闲容量,并精心设置 QoS 配额和限制机制。
      • 服务所有者可以根据需要在单元之间移动工作负载。以下是一些示例:
        • 通过迁移繁重的工作负载,使单元的其他用户不会受到影响,从而帮助避免多租户相互干扰的问题。
        • 有助于从超载或限流中恢复,这有可能是分布式拒绝服务攻击所导致的。我们提供了配额和限制机制来抵御此类攻击,但有时会发生特定用例(API、访问模式)对服务的需求超出系统当前确定的配额或限制的极端情况。单元提供了短期缓解机制来应对这种情况。
        • 将关键工作负载分散到不同的单元中,可以显著降低发生相关性故障的可能性。例如,对于控制层的内部共享 Workflow,Platform、Compute、Networking 和 Block Volumes 等“关键核心”控制层将分别分配给不同的单元。与不使用单元或所有控制层分配给同一单元相比,这可以显著减少相互关联的故障。
          :通过使用单元,客户在构建可恢复的应用时不需要那么多地考虑服务内部依赖关系。使用依赖关系图仍然是很好的做法(本文后面会详细介绍),但是在已存在解除相关性的机制时,这种需要减少了。

      这样,每个服务单元是可用性域或区域中的另一种“逻辑数据中心”— 即用于实现性能隔离和故障隔离的一种逻辑分组。

      概括地说,服务单元和容错域互为补充,具体表现在以下几个方面:

      • 在主动更改系统时,容错域可以防止出现问题。
      • 无论是否主动更改系统,当系统出现潜在的严重问题时,服务单元可以限制影响范围。

      在执行部署和打补丁时,可以将容错域和服务单元的特性组合起来,形成统一的战略。

      服务工程设计程序

      出色的测试和运行对云系统的可靠性至关重要,为此我们提供了大量工程设计程序。以下是其中一些较为重要的程序,它们利用了前面部分中提到的概念:

      • 按增量方式部署服务,对每个步骤进行仔细的验证,并在发生任何意外时自发地回滚。具体过程如下:
        • 在每个可用性域中,一次部署到一个服务单元。对于每个单元,一次部署到一个容错域,直至部署到该单元的所有容错域为止。接着,继续对该可用性域中的下一单元重复上述操作。
        • 完成所有部署步骤后(部署到每个容错域和单元后),验证更改是否能按预期工作 — 无论是内部还是外部,均未导致性能降级或未引入任何错误。如果出现任何错误或意外,将自发地回滚更改。我们尤其重视回滚程序(包括影响持久状态或 Schema 的更改)的编写和测试,其中包括自动测试。
        • 通过这种方式,我们在每个区域中,将更改一次部署到一个可用性域。在向领域内的所有区域部署时,我们可确保不会同时修改客户可能用于主要站点和灾难恢复站点的任何一对区域。
      • 我们定期验证错误处理机制和其他缓解机制是否能按预期工作,且不会使问题的影响范围扩大。如果不进行此类测试,各种错误处理机制(例如重试、崩溃恢复算法和状态机重新配置算法)常常会出现错误,开销过大或发生意外交互,并因此导致分布式抖动或其他严重的性能问题。
      • 我们将验证能否快速安全地回滚到上次已知的良好软件和配置,包括持久状态和 Schema(如前所述)。
    • 在包含多个可用性域的 Oracle 区域中,是否所有关键服务都跨可用性域分布?

      可以。在每个区域中,所有可用性域提供一组相同的服务。

    • Oracle 及其客户如何避免关键服务依赖于一个逻辑数据中心?

      在包含单个可用性域的区域中,客户可以使用容错域(相互之间实现了故障隔离的逻辑组)来获得多个“逻辑数据中心”所具有的大多数特性。客户还可以使用多个区域来实现灾难恢复 (Disaster Recovery, DR)。

      在包含多个可用性域的区域中,客户可以按相同的方式来使用容错域。客户还可以结合使用可用性域本地服务、可用性域间故障转移功能(例如 Data Guard 的 DBaaS)和区域服务(Object Storage、Streaming),在更高级别的“逻辑数据中心”(可用性域)实现完全的高可用性。此外,客户还可以使用多个区域实现 DR。

      在所有情况下,客户都可以利用服务单元这一概念进一步隔离更严重的问题,例如分布式抖动。

    • Oracle 如何在执行维护活动的同时确保关键服务对客户始终可用?

      我们通过容错域、服务单元以及用于增量部署和验证的操作程序来实现这一点。请参阅此文档前面部分的内容。

    • 是否跨多个逻辑数据中心部署无服务器平台服务以实现更高的可用性?

      可以。所有类别的服务都跨多个逻辑数据中心(实现了故障隔离和性能隔离的独立逻辑分组)进行部署,以实现可恢复性及持续可用性。

    • 如果可恢复性不是默认配置,客户是否可以选择包含多个逻辑数据中心的部署(例如多个可用性域配置或跨区域配置)?

      如本文前面部分所述,在包含单个可用性域的区域中,我们提供了容错域机制来实现“多个逻辑数据中心”。

      在包含多个可用性域的区域中,我们的服务和功能可以为同步复制的数据提供更高级别的物理持久性(由于区域中可用性域之间的距离和光速,会产生一定的性能损失和成本,但微乎其微)。

      我们不提供跨区域的自动保持高可用性或故障转移机制,因为这需要在区域之间建立紧密耦合关系,从而带来多个区域同时出现问题的风险。但是,我们支持在区域之间进行各种形式的异步复制,并且还在不断增加功能(例如异步复制和备份)来实现跨区域的灾难恢复。

    • 各种基础设施和平台服务之间存在的内部依赖关系可能会导致应用发生相关性故障,Oracle 如何帮助客户避免此问题?

      这个问题比较复杂。为了阐述清楚,我们从几个方面来说明:

      • 如果客户要使用两个 Oracle 服务(服务 A 和服务 B),并且希望在其中一个服务出现故障时,所构建的应用能够快速恢复,那么客户是否需要知道服务 A 是否在内部依赖于服务 B?内部依赖关系是否在很大程度上是导致相关性故障的原因?如果是,那么当客户在应用级别构建自己的可恢复性机制时,他们可能需要了解这些内部依赖关系,以决定服务 A 和服务 B 分别用于满足哪些其他用途,或者是否需要引入无关的服务 C 来满足这些其他用途。
      • 客户如何恰当地防止 Oracle 服务发生相关性故障?

      答案分为两个部分。

      架构原则

      我们利用架构原则来大幅减少存在依赖关系的服务发生相关性故障。在某些情况下,此方法可以大幅降低出现相关性故障的可能性,从可用性服务级别协议 (SLA) 的角度而言,甚至能达到可以忽略的程度。

      特别是,我们还使用了服务单元,这一点在之前的部分已经介绍过了。单元有助于解决该问题 — 如果内部服务 A 所依赖的服务之一(即服务 B)发生问题会影响服务 A,那么服务 B 的问题很可能被限制在单个单元内。对于使用服务 B 的其他更高层服务和客户的自有应用,它们使用的可能是不受影响的其他单元。这是一个因单元数而异的概率问题,而单元数是一个必定会变化(增加)的内部隐藏参数,因此我们不对超出服务 A 和 B 的独立服务 SLA 的情况提供任何量化声明或保证。但实际上,服务单元确实可以显著减少服务之间的故障相关性。

      我们的许多内部共享服务(例如,控制层的工作流和元数据服务,以及 Streaming/Messaging 服务)都使用服务单元来隔离故障,以保护使用它们的上游服务。

      依赖项

      以下只是一些大方向的指导,因为服务的底层实施和具体情况会发生变化,而且一定会发生变化。但是,对于计算、存储、网络和身份验证/授权等主要方面,我们指明了以下依赖项。

      对于控制层,常见依赖项如下:

      • 用于身份验证和授权的身份/平台数据层
      • 审计跟踪服务
      • 提供工作流、元数据存储和日志记录等的内部服务
      • 各种类型的负载平衡器

      一些控制层很明显具有特定于服务的依赖项。例如,当启动裸金属或 VM 实例时,计算控制层需要依赖:

      • 对象存储(用于检索指定的操作系统映像)
      • 块存储卷控制层(用于预配和连接引导卷)
      • 网络控制层(用于预配和连接 VNIC)

      对于核心服务数据层,一般设计原则是每个数据层应确保只有最少的依赖项,以实现高可用性、快速诊断和快速恢复。该原则产生的结果如下:

      • 网络数据平面是自包含的。
      • 块存储卷数据层是自包含的。
      • 计算裸金属和 VM 实例依赖于块存储卷数据平面(对于引导卷)和网络数据平面。
      • 对象存储数据层依赖于身份/平台数据层进行身份验证和授权(为了满足行业期望)。对象存储数据层不依赖于块存储卷或文件存储。
      • 支持备份和恢复的所有服务都依赖于对象存储数据平面来实现该功能。

      对于 IaaS 数据层,一般原则是仅依赖于核心或更低层的数据层(以避免出现循环依赖)。

      • 数据库多节点 RAC 取决于网络数据平面和块存储卷数据平面。
      • Container Engine for Kubernetes 显然依赖于 Kubernetes 及其传递依赖项(例如 etcd)以及网络数据平面。
      • 对备份和存储的所有支持都依赖于对象存储数据平面。
    • 区域中的 Oracle Cloud Infrastructure 服务(包括区域 API 端点)是否在与全局控制层功能隔离时继续运行?

      可以,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 服务是否会继续运行?

      是的,即使在与相应的区域控制层隔离的情况下,Oracle Cloud Infrastructure 服务的架构使得每个逻辑数据中心中的数据层功能也能继续运行。例如,即使数据中心与计算、区块存储、VCN 和/或身份与访问管理的控制层功能隔离,逻辑数据中心中的 Oracle Cloud Infrastructure 计算实例将继续与附加的块存储卷和关联的虚拟网络功能一起运行。

    • Oracle Cloud Infrastructure 区域是否具有冗余互联网连接以实现高可用性?

      可以。Oracle Cloud Infrastructure 通过所有商业区域的多个冗余提供商连接到互联网。这些连接使用 BGP(边界网关协议)。

注:为免疑义,本网页所用以下术语专指以下含义:

  1. 除Oracle隐私政策外,本网站中提及的“Oracle”专指Oracle境外公司而非甲骨文中国 。
  2. 相关Cloud或云术语均指代Oracle境外公司提供的云技术或其解决方案。