甲骨文股份有限公司是否区分了不同的服务类别，例如关键服务、持续可用的服务或单个位置服务?
我们不做这样的区分。相反，我们根据依赖级别、可用性范围和数据平面与控制平面对服务进行分类。这些类别旨在可用性、持久性、性能和便利性之间提供各种有用的权衡。
依赖程度
这些层次可以被认为是体系结构框图中的层次。每一层可能只依赖于它下面的层。
从下到上:
核心服务:这些服务构成了甲骨文股份有限公司云基础设施的基础。它们包括身份和访问管理(IAM)、密钥管理、网络、计算、块卷、对象存储、遥测和几个共享的内部服务。它们被设计成具有最小的依赖性，甚至彼此之间也是如此。(有关依赖关系的详细信息，请参阅本文后面的部分)。
基础设施即服务:这一层提供了更多构建在核心之上的基础设施级功能。这一层的服务包括平台的文件存储、数据库和容器引擎。
软件即服务:这一层是以丰富的软件作为服务建立在下层。
可用性范围：
为满足服务的可用性和持久性目标，为每个服务选择下列可用性范围之一:
本地可用域:每个可用域包含一个独立的服务实例。通过使用相同可用域内的副本之间的同步复制，这些服务提供了存储数据的高持久性(有关详细信息，请参阅本文档后面关于故障域的部分)。这些服务可以允许可用性域中三分之一或更多基础设施的中断，这取决于服务的性质。可用性域本地服务通过在可用性域中使用两种不同的逻辑数据中心(故障隔离的逻辑组和性能隔离的逻辑组)来实现这种程度的错误。有关详细信息，请参阅本文档后面关于故障域和服务单元的部分。最后，即使可用性域不能与任何其他可用性域通信，这些服务仍然可以正常运行。因此，它们允许区域内其他可用域的丢失或广域网的完全故障。
多个可用性域:具有多个可用域的每个区域包含一个独立的服务实例，该服务的组件位于该区域的每个可用域中。这些服务通过对同一区域内的多个可用域进行同步复制，提供了非常高的存储数据持久性。这些服务可以允许该区域任何单个可用域的中断或无法通信。
区域可用性域:如果一个区域只包含一个可用性域，则区域服务的可观察特征与前面描述的可用性域本地服务的可观察特征相匹配。只有当通过添加一个或多个可用性域来扩展单个可用性域时，可用性域服务和单个可用性域服务之间的区别才变得相关。当这种情况发生时，每个区域服务都会自动扩展，以适当地使用新的可用性域，同时保留服务的单个实例。例如，对象存储数据平面将扩展到使用额外的可用性域来提高现有数据的持久性。然而，对于可用性域本地服务，每个新可用性域都接收自己的每个可用性域本地服务的单独实例。
跨区域分布:甲骨文股份有限公司云基础设施的一个基本原则是，每个区域在操作上尽可能独立于其他区域。这种资格尽可能反映出这样一个事实，即各区域必须至少共享某些基础设施，例如区域间骨干网络。否则，我们不会在区域之间构建紧密耦合机制，例如透明的高可用性或故障转移，这可能会导致同时影响多个区域的问题。相反，我们提供了两种机制来跨松散耦合的区域分发服务:
灾难恢复（dr）：让我们的客户能够建立具有dr特性的系统是我们的方法和在云网络上投资的基石。一些核心服务已经提供了DR机制——例如，块卷区域间备份和对象存储区域间复制。我们所有的服务都将DR功能作为其路线图中的高优先级项目。
区域间订阅：我们目前只为iam数据提供区域间订阅。 有悖于从概念上讲，IAM数据具有全局范围。客户可以订阅(opt-in)一组区域，我们自动将相关IAM数据和后续更新复制到指定的区域。为了避免紧密耦合，复制是异步的，并且最终是一致的。客户在他们指定的“home”区域修改他们的IAM数据。如果当前的home区域由于某种原因变得不可用或不适合，可以指定其他区域。
控制平面对抗数据平面
服务的数据平面是数据处理接口和组件的集合，这些接口和组件实现了应用程序要使用的服务的功能。例如，虚拟云网络(VCN)数据平面包括网络包处理系统、虚拟路由器和网关，而块卷数据平面包括iSCSI协议的实现和容错的卷数据复制存储系统。
? 服务的控制平面是负责以下任务的一组应用程序界面（api）和组件:
? 处理客户要求提供、重新配置、扩大/缩小或终止资源的请求
? 快速、安全地对大型车队进行自动修补
? 检测失败、降级或配置错误的资源
? 进行自动维修或传呼人工操作员以寻求协助
? 与其他控制平面协作(例如计算、VCN、在启动过程中是耦合的区块储存)
? 管理未使用的容量
? 与人员协调，例如新设备的到货，以及物理维修和保养
? 提供运作上的能见度和控制权
Oracle是如何确保服务具有弹性和持续可用性的?
对于所有类型的服务，我们都使用相同的工程原则来实现弹性和可用性，因为构建容错、可伸缩、分布式系统的基本工程所面临的挑战对于所有类型的服务都是相同的。
为了实现弹性和持续可用性，有必要了解并处理云级别系统中导致不可用性的全部原因——性能下降和无法处理的故障。这样的原因有很多，所以我们将根据它们的基本性质将它们分类。
传统上，对企业IT系统可用性的分析主要在于分析硬件故障的类别。然而，对于云系统来说，硬件故障是一个相对较小的问题，并且很容易理解。现在相对容易避免或减轻大多数单点硬件故障。例如，机架可以有双电源馈电和相关的配电单元，而且许多组件是可热切换的。大规模的硬件故障和丢失当然是可能的——例如，由于自然灾害。然而，我们的经验以及其他云供应商在公开验尸报告中显示，相对于其他不可用的原因，整个数据中心的故障或丢失发生得非常少。大规模的硬件故障仍然必须处理(例如，使用灾难恢复和其他机制) ，但是它还远远不是主要的可用性问题。
云计算系统不可用的主要原因如下:
1.软件缺陷
2.配置错误
3.人类操作员所犯的错误
注:在行业中所吸取的主要教训是，到目前为止，这三种形式的人为错误是不可用的最大原因。虽然可以通过工具、自动化和培训来减少它们的出现频率，但是不能消除它们。因此，必须将它们作为体系结构、设计和系统实现中的主要关注点来处理。
4.性能(延迟或吞吐量)因任何原因出现不可接受的差异，包括以下原因:
? 多种租户"吵闹的隔壁" (失败的服务质量机制)
? 无法在有效地拒绝超载的 (突发性的或者蓄意的) 同时继续做有效的工作
? 分散逆行, 信息风暴, 重试风暴, 和其他昂贵的"紧急"交互
? 在循环后的冷震 (虚无的高速缓存), 尤其是同时控制多个循环系统
? 缩放系统时高处被架空 (比如重新分区)
5.未能限制上述任何问题的 “爆炸半径” (受影响客户和系统的数量)
这些挑战是普遍的——它们是云级分布式系统的“物理定律”的一部分。
对于前面的每一个类别，我们都使用经过验证的工程策略来解决这个问题。其中最重要的是:
o架构及系统设计原则
o新的架构概念(通常源自应用这些原则)
o服务工程程序
架构原理与系统设计
这些原则中有许多是存在的，但我们将重点关注那些与恢复力和可用性最相关的原则。
以恢复为导向的计算
为了处理具有相对本地化效果的操作符的软件bug和错误，我们遵循面向恢复的计算原则。在更高的层次上，这意味着我们不是试图保证我们从来没有遇到过问题(这是不可能测试的)，而是专注于以一种可以测试的方式不引人注目地处理任何问题。我们特别关注最小化平均恢复时间(MTTR)，这是平均检测时间、平均诊断时间和平均缓解时间的组合。
我们的目标是恢复得如此之快，以至于人类用户不会因为这个问题而感到不便。以下几点可以帮助我们实现这个目标:
o通过在代码中广泛使用断言，以及在所有级别上进行主动监视和警告，快速和自动地检测操作人员的错误和错误症状。
o将功能打包成许多单独的细粒度隔离单元(线程、进程、纤维、状态机等等) ，这些单元是松散耦合的——也就是说，它们不会直接共享可能损坏的内存。
o在检测到操作人员的失误或错误后，应尽快自动重启封闭的隔离单元。重新启动是尝试从任何一种故障中恢复的一种实用方法，因为它试图重新建立经过测试的良好状态，从而恢复不变量。
o如果细粒度隔离级别的恢复不起作用(例如，断言在该级别继续过于频繁地触发，导致自旋崩溃) ，需要升级到下一个更大的单元(进程、运行时、主机、逻辑数据中心、人工操作符分页) 。
o建立机制，以启用 “全系统撤销” ，包括对所有持久性状态和配置进行版本控制，以便快速识别和撤销错误提交。
尽量减少问题的影响
为了处理可能产生更广泛影响的bug和错误，我们构建了一些机制来最小化任何问题的“爆炸半径”。也就是说，我们专注于最小化受任何问题影响的客户、系统或资源的数量，包括多租户“嘈杂邻居”的特别具有挑战性的问题，这些问题提供了过载、容量降低和分布式抖动。我们通过使用各种隔离边界和变更管理实践来实现这一点(请参阅以下部分)。
源于设计原则的建筑概念
这些概念中有许多是存在的，但我们将重点讨论限制爆炸半径(影响范围)的概念。我们的公共API(应用程序编程接口)中包含的放置概念:区域、可用性域和故障域 。因为断层域相对较新，所以我们将更详细地描述它们。故障域用于限制系统主动更改时发生问题的爆炸半径，例如部署、修补、管理程序重新启动和物理维护。
保证在给定的可用性域中，在任何时间点上，至多一个故障域中的资源都会被更改。如果更改过程出错，则该故障域中的部分或所有资源可能暂时不可用，但不影响可用性域中的其他故障域。每个可用性域至少包含三个容错域，以便允许基于仲裁的复制系统（例如，Oracle Data Guard）在单个可用性域中以高可用性承载。
因此，对于主要的可用性问题类别，软件错误、配置错误、操作员错误以及在更改过程中发生的性能问题，每个故障域在可用性域中充当单独的逻辑数据中心。
故障域还可以防止某些局部硬件故障。故障域的特性保证了放置在不同故障域中的资源不会在可用性域内共享任何潜在的单点硬件故障，这在最大程度上是可行的。例如，不同故障域的资源不共享同一个“顶层”网络交换机，因为这种交换机的标准设计缺乏冗余。
但是，故障域保护硬件或物理环境中的问题的能力在该本地级别停止。与可用性域和区域不同，故障域不提供任何大规模的基础设施物理隔离。在罕见的自然灾害或可用性域范围的基础设施故障情况下，多个故障域中的资源可能同时受到影响。
我们的内部服务使用故障域的方式与客户使用它们的方式相同。例如，块卷、对象存储和文件存储服务将数据的副本存储在三个单独的故障域中。所有控制平面和数据平面的所有组件都托管在所有三个故障域中（或者，在多个可用性域区域中，在多个可用性域中）。
服务单元
服务单元用于限制问题的爆炸半径，即使系统没有被主动更改。这样的问题可能出现，因为多租户云系统的工作负载在任何时候都会以极端的方式发生变化，而且任何大型分布式系统在任何时候都可能发生复杂的部分故障。这些场景可能会触发细微的隐藏错误或紧急的性能问题。
此外，在一些罕见但具有挑战性的场景中，当系统被积极更改时，服务单元也会限制爆炸半径。一个典型的例子是，当部署到单个故障域成功时，性能没有错误或变化，但是一旦第二个或最后一个故障域被更新，系统中的新交互（以生产工作负载的全云规模）就会导致性能问题。
请注意，服务单元的使用是一种体系结构模式，而不是在Oracle Cloud API或SDK （软件开发工具包）中显式命名的概念。任何多租户系统都可以使用这种体系结构模式；它不需要云平台的特殊支持。
服务单元的工作原理如下：
? 服务的每个实例（例如，在特定区域或特定可用性域中的可用性域本地服务）由服务软件堆栈的多个独立部署组成。每个单独的部署称为单元。每个单元尽可能多地托管在自己的基础设施上。单元至少不共享主机或虚拟机。
? 服务可能从每个可用性域或区域中的少数单元开始。随着服务规模的扩大，以满足日益增长的需求，增加了更多的单元，以保持对任何问题的爆炸半径大小的限制。一个流行的大型服务可能有许多单元。换句话说，单元提供客户工作负载的N到M多路复用，以分离宿主环境，分离资源隔离岛。单元格没有明显的基数，例如存在于故障域中。（如前所述，故障域基数的一个明显选择是每个可用性域三个，以使基于仲裁的复制系统能够在单个可用性域中以高可用性为宿主。）
? 客户工作负载的每个“自然单元”都分配给特定的单元。“自然单位”的定义取决于特定服务的性质。例如，对于我们的内部共享工作流服务（稍后描述），自然单元可能是“特定控制平面的此可用性域或区域中的所有工作流”。
? 在每一组单元之前，要么是一个最低限度的路由层，要么是一个用于发现单元端点的API。例如，流/消息系统有一个API来发现特定主题的当前数据平面端点，并且内部元数据存储区每个单元有一个单独的端点。但是，其他基于单元的服务有一个数据平面端点和一个共享路由层。路由层是多个信元相关故障的潜在原因，但通过保持路由层极其简单、可预测和性能（无昂贵的操作），并为其提供大量的净空容量和完善的QoS配额和限制机制，可以减轻这一问题。
? 服务所有者可以根据需要将工作负载从一个单元移动到另一个单元。以下是一些示例场景：
1. 通过移动繁重的工作负载来避免多租户“嘈杂的邻居”问题，从而避免影响小区的其他用户。
2. 帮助从可能由分布式拒绝服务攻击引起的过载或故障中恢复。我们有配额和限制机制来防御此类攻击，但有时会出现边缘情况，在这种情况下，服务的特定用例（API、访问模式）比配额或限制系统当前了解的更为繁重。细胞提供了一种短期缓解的机制。
3. 将关键工作负荷分为不同的单元，显著降低相关故障的概率。例如，对于控制平面的内部共享工作流，“关键核心”控制平面（例如，平台、计算、网络和块卷）都分配给不同的单元，因此与不使用单元或分配给同一个单元的情况相比，故障相关性要小得多。
?注意：这种单元的使用减少了客户为构建弹性应用程序而考虑服务的内部依赖性的需要。考虑到依赖关系图仍然是一个很好的实践（更多的是本文后面的内容），但是当去相关机制已经激活时，对它的需求就更少了。
结果是，每个服务单元都是另一种“逻辑数据中心”——在单个可用性域或区域内，性能隔离和故障隔离的逻辑分组。
总之，服务单元和故障域通过以下方式相互补充：
? 当一个系统被激活地改变时，故障域对问题的保护。
? 当系统遇到潜在的严重问题时，服务单元限制爆炸半径，无论是否正在积极地改变。
在执行部署和修补时，我们将故障域和服务单元的属性结合到一个统一的策略中。
服务工程程序
由于测试和卓越的运营对云系统的可靠性至关重要，因此我们有大量的工程流程。以下是利用前一节中提到的概念的一些更重要的概念：
? 我们以增量方式部署服务，在步骤之间进行仔细的验证，并在发生意外情况时进行自反回滚。具体过程如下：
1. 在每个可用性域中，我们一次部署到一个服务单元。对于每个单元，我们一次部署到一个故障域，直到完成该单元的所有故障域。然后，我们前进到该可用性域中的下一个单元。
2. 在部署的每个步骤之后（在每个故障域和单元之后），我们验证了更改的功能是预期的——也就是说，我们没有降低性能或引入任何内部或外部错误。如果有什么不对劲或意外，我们会反射性地回滚更改。我们非常强调回滚过程的准备和测试，包括自动测试，包括影响持久状态或模式的更改。
3. 以这种方式，我们将改变一个可用性域部署到每个区域，我们将区域部署到域中的所有区域，这样就不会同时修改客户可能用于主站点和灾难恢复站点的任何一对区域。
4. 我们定期验证错误处理机制和其他缓解机制是否如预期的那样工作，并且不会使问题在规模上变得更糟。如果没有这样的测试，错误处理机制(如重试、崩溃恢复算法和状态机重新配置算法)通常会出现错误、代价过高或以令人惊讶的方式交互，从而导致分布式抖动或其他严重的性能问题。
5. 如前所述，我们验证了快速安全地回滚到最后已知的良好软件和配置(包括持久状态和模式)的能力。
在包含多个可用域的Oracle区域中，是否所有关键服务都分布在可用域中？
是。 在每个区域中，所有可用域都提供相同的服务集。
Oracle及其客户如何避免使用依赖于单个逻辑数据中心的关键服务？
在单可用性域区域中，客户可以使用故障域（组之间具有解相关故障模式的逻辑组）来实现单独“逻辑数据中心”的大多数属性。客户还可以使用多个区域进行意外恢复（DR）。
在多可用性域区域中，客户可以以相同的方式使用故障域。客户还可以结合使用可用性域本地服务，可用性域间故障转移功能（例如DBaaS与Data Guard）和区域服务（对象存储，流式传输）来实现跨越更高级别“逻辑数据中心”的完整HA（可用性）域。 最后，客户还可以使用多个区域进行DR。
在所有情况下，客户都可以使用服务单元的概念来进一步隔离最严重的问题，例如分布式捶打。
Oracle如何在不使任何客户暂时无法使用任何关键服务的情况下执行维护活动？
我们通过故障域，服务单元以及增量部署和验证的操作程序来实现这一目标。 请参阅本文档前面的讨论。
跨多个逻辑数据中心是否部署了无服务器平台服务以提高可用性？
是。 所有类别的服务都部署在多个逻辑数据中心 - 故障隔离和性能隔离的单独逻辑分组 - 以实现弹性和连续可用性。
如果弹性不是默认配置，客户是否可以选择多逻辑数据中心部署（例如，多可用性域或跨区域配置）？
在单可用性域区域中，我们提供故障域作为“多个逻辑数据中心”的机制，如本文档中其他地方所述。
在多可用性域区域，我们提供的服务和功能可为同步复制的数据提供更高水平的物理持久性（由于区域中可用域之间的距离和光速，因此性能适中，成本较高）。
我们不提供跨区域的自动HA或故障转移机制，因为这会在区域之间创建紧密耦合关系，并且会产生多个区域可能同时遇到问题的风险。相反，我们在区域之间启用各种形式的异步复制，并提供不断增长的列表功能，例如异步复制和备份，以实现跨区域的意外恢复。
Oracle如何帮助客户避免因各种基础架构和平台服务之间的内部依赖性而导致的应用程序相关故障？
这是一个复杂的问题，所以为了澄清，我们将以几种不同的方式重申它：
? 如果客户想要使用两个Oracle服务（服务A和服务B）并且希望构建一个具有弹性的应用程序（如果其中任何一个服务失败），那么客户是否需要知道服务A内部是否依赖于服务B？内部依赖会导致相关失败吗？如果是这样，那么客户可能需要了解这些内部依赖关系，以便决定服务A和服务B的其他用途 - 或者是否为这些其他情况引入不相关的服务C - 在构建自己的弹性时 应用程序级别的机制。
? 客户如何最好地抵御Oracle服务的任何相关故障？
答案分为两部分。
建筑原理
我们使用架构原则来显著减少相关服务之间的相关故障。在某些情况下，从满足可用性服务水平协议（SLA）的角度来看，该技术将相关故障的可能性降低到可以忽略的程度。
特别是，我们使用服务单元，如本文档前面所述。单元有助于解决此问题，因为如果内部服务A受其依赖关系（服务B）中的问题影响，那么服务B的问题很可能仅限于单个单元。使用服务B的其他更高级别的服务和客户自己的应用程序可能正在使用其他不受影响的单元。这是一个概率论据，它随着单元格的数量而变化，这是一个隐藏的内部参数，它确实发生了变化（增加），因此除了服务A和B的独立服务SLA之外，没有给出量化或保证。但在实践中，这可能会显著降低服务之间的故障相关性。
我们共享的许多内部服务—例如，用于控制平面的工作流和元数据服务，以及流/消息传递服务—使用服务单元来解除使用它们的上游服务的中断。
依赖关系
下面的指导是高层次的，因为服务的底层实现和细节可以而且确实在变化。但是对于计算、存储、网络和身份验证/授权的关键维度，我们指出了以下依赖关系。
对于控制平面，常见的依赖关系如下:
1. 用于身份验证和授权的标识/平台数据平面
2. 审计跟踪服务
3. 提供内部服务，例如工作流、元数据存储和日志记录
4. 各种类型的负载平衡器
一些控制平面显然具有特定于服务的依赖关系。例如，当启动一个裸金属或VM实例时，计算控制平面取决于:
? 对象存储(检索指定的操作系统映像)
? 块卷控制平面(用于提供和附加引导卷)
? 网络控制平面(用于提供和附加vnic)
对于核心服务数据平面，一般原则是有意将每个数据平面设计为具有最小的依赖性，以便实现高可用性、快速诊断和快速恢复。该原则的结果如下:
? 网络数据平面是自包含的。
? 块卷数据平面是自包含的。
? 计算裸金属和VM实例依赖于块卷数据平面(用于引导卷)和网络数据平面。
? 对象存储数据平面依赖于身份/平台数据平面进行身份验证和授权(因为行业的期望)。对象存储数据平面不依赖于块卷或文件存储。
? 所有支持备份和恢复的服务都依赖于该特性的对象存储数据平面。
对于IaaS数据平面，一般原则是只依赖于核心或低层数据平面(以避免循环依赖)。
? 数据库多节点RAC取决于网络数据平面和块卷数据平面。
? Kubernetes的容器引擎显然依赖于Kubernetes及其传递依赖项(例如etcd)和网络数据平面。
? 所有对备份和恢复的支持都依赖于对象存储数据平面。
