Azure下一代块存储架构：深度技术解析
Azure Disk为Azure虚拟机提供块存储，并是Azure IaaS平台的核心支柱之一。在本次演讲中，我们将概述Direct Drive - Azure的下一代块存储架构。Direct Drive构建了一系列新的Azure Disk产品，首发产品是Ultra Disk（Azure性能最高的Disk）。将描述在云规模下提供持久、高可用、高性能Disk所面临的挑战，以及克服这些挑战的软件和硬件创新。
了解新的Azure块存储架构 - Direct Drive及其设计原则 了解由Direct Drive支持的Ultra Disk功能 识别Direct Drive实现与行业标准做法的不同以及理由
-----
我叫Greg Kramer，我是Microsoft Azure存储部门的软件架构师。今天我要和大家讨论Azure的下一代块存储架构，即"Direct Drive"。我们的演讲议程如下：首先进行一个简短的介绍，然后讨论"Direct Drive"的目的和动机，即我们为何要设计一种新的架构。接下来，我将详细介绍块存储架构的工作原理，然后谈论一些我们认为可能对听众有意思的设计要点。最后，我们将留出一些时间回答问题。
"Direct Drive"是Azure的新块存储架构的内部代号，目前它是一系列Disks产品的基础。"Ultra Disk"于2019年夏季发布，而"Azure Premium Disk v2"刚刚在今年夏季进入预览阶段。那么，为什么我们要花时间和精力设计一种新的块存储架构呢？
正如你们中的许多人所知，微软在存储领域已经有几十年的经验，我们在本地环境中使用Windows和Windows Server，当然还有在Azure中的公有云经验。因此，多年来我们积累了许多经验，见识了许多事情。此外，不断涌现新的工作负载和新技术，可以加以利用。因此，开始考虑如何将多年来积累的经验应用到设计中，以满足这些新工作负载并利用新兴技术变得非常有意思。那会是什么样子呢？
因此，我将逐步介绍一些我们在这里尝试构建的理念。其中，我们非常感兴趣的一个方向是创建适用于多种环境的解决方案。当然，我们在Azure上有大规模的部署，但如果我们能够将这个解决方案扩展到最小的单服务器部署，那将是理想的。实际上，这正是我们的开发人员目前在进行Direct Drive内部环境测试时采取的方法。我们可以将整个存储解决方案完全虚拟化，部署到开发人员台式机上，这对测试非常有帮助。但我们的目标是满足各种规模的需求，从小型部署一直到Azure的大规模部署。
另一个我们感兴趣的方面是为最终用户简化体验。在块存储中常见的模式是将多块Disks组合在一起以获得所需的性能或容量，但这对客户来说可能会有麻烦。这里有很多需要管理的内容，通常需要使用类似于Windows中的存储空间或Linux中的等效工具将它们组合成一个看起来像一个Disk的东西，以实现所需的功能。理想情况下，我们希望消除这一过程，如果客户需要特定大小和性能的Disk，那么他们应该能够直接配置。
此外，我们还希望确保不限制客户必须按特定单位购买容量或性能。如果您需要一个小而快速的Disk，那是可以的。如果您需要一个略大但速度较慢的Disk来满足工作负载，也是可以的。我们希望能够覆盖客户的各种场景。
同时，我们也希望确保用户不必为最坏情况进行过度预配。我相信这里的大多数人都熟悉这个问题，您需要尽量估算高峰工作负载可能的情况，然后确保您所配置的硬件可以满足这一需求。如果不得不一直保持最佳状态以应对潜在的高峰负载，那会变得非常昂贵。因此，我们还希望设计一种允许客户在高峰需求时提高性能目标，然后在低峰时段降低性能目标的架构。
我一开始提到的新技术也是我们考虑的重要因素。我们看到网络速度越来越快，我们有新的存储网络协议。我将在演讲稍后的部分讨论这一点。此外，存储硬件也有新的创新，存储类内存就是一个明显的例子，硬件卸载在某些方面变得非常流行，特别是在诸如加密和CRC等方面。这对我们非常有意思，因为当然，我们存储的所有客户数据都是加密的，我们提供端到端的完整性，CRC位于数据的整个生命周期中。因此，能够卸载这些操作是一个巨大的优势，因此我们希望设计一种架构，能够充分利用市场上出现的所有这些新技术。
最后，我们希望简化I/O路径。在左侧，我们展示了Azure存储中我们之前的架构。这里有很多层，是一个精心设计的多层解决方案，我之后的演讲将谈到我们从这个多层解决方案中获得的一些能力。但如果我们关注的是最佳和最一致的性能，我们需要去掉这些层，变成更薄的堆栈，因此我们希望我们的Disks客户能够直接访问它们的数据，这就是"Direct Drive"的"Direct"的含义。
这就是我们设计新架构的动机，接下来我们将深入了解这个架构的工作原理。
在深入探讨之前，我想提供一些警告或注意事项。"Direct Drive"架构非常灵活，我们有许多不同的部署方式、不同的形态和性能目标等。这次演讲专门讨论架构，而不是我们在其上构建的任何产品。因此，架构支持一些我们今天产品中未展示的功能，因此不应将其解释为对我们构建的产品的能力或限制做出任何官方声明。
好了，让我们从基础知识开始。我们希望能够支持两种类型的Disks，即4K原生Disk（逻辑和物理扇区都是4K）以及512e Disk。就像实际物理Disk一样，通过发出4K对齐的I/O请求，您可以获得最佳性能，这可以避免读-修改-写的性能惩罚。我们所追求的核心功能集包括不仅包括读写Disk，还包括支持共享Disk。因此，我们希望支持单个写入者多个读取者，以及多个写入者和多个读取者，以便您的Disk可以同时挂载到多个虚拟机上。我们需要支持崩溃一致性和增量快照，这意味着如果您创建一个快照，然后再创建一个第二个快照，我们占用的存储空间应该与您自上一个快照以来写入的数据量成比例。此外，我们需要支持Disk迁移，Disk迁移不一定是面向最终用户的功能，但它是我们在内部使用的重要功能。Disk迁移允许我们将一个Disk从一个存储节点集合移动到不同的存储节点集合，同时该Disk正在挂载并执行I/O操作。我们可以出于各种目的使用这项功能，包括将Disk移近客户、将Disk从一个繁忙的租户移到一个不太繁忙的租户，或者在停用已经到寿命终点的存储节点集合时，将Disk移动到一个仍然正常的存储节点集合。
那么，对于我们的后端来说，Disk是什么样的呢？显然，客户看到的是一个扁平的LVA空间，传统的Disk布局。我们实际上以固定大小的块单元来管理Disk，我们称之为"切片"。每个Disk的切片大小是固定的，但它们可以在不同的Disk之间变化。在这个示例中，我展示了64兆的切片大小。那么，什么情况下我们可能希望有更大的切片呢？如果我们有非常大的Disk，那么有一定量的元数据我们必须维护在每个切片上，因此在非常大的Disk上，我们可能选择增加切片大小以降低元数据开销。这只是一个可能的示例。
每个Disk切片由我们称之为"副本集"（replica set）来维护，副本集包括一个单一的变更协调服务（CCS）和多个块存储服务（BSS）。CCS负责对切片进行排序和复制更改，因此我们将存储数据的多个副本，它们需要保持同步，CCS执行此功能。
CCS在某种程度上是一个无状态服务，这意味着如果它崩溃或重新启动，它在启动时不会加载任何数据。因此，CCS的信息是在其加入集群时放入其中的，然后它会一直以这种方式运行，直到它退出，然后我们会选择另一个CCS。我们稍后会详细讨论这一点。块存储服务是有状态的，这是我们拥有带有SSD的节点的地方。除了读写Disk数据是它们的主要职责外，BSS还负责对数据进行检查。我提到我们的协议内置了端到端完整性，但如果您不主动对Disk进行I/O操作，那就没有人来检查数据是否仍然完好。因此，我们有后台检查程序，会不断检查数据，以防止没有I/O操作时修复问题。BSS还负责在必要时修复切片数据。例如，如果检查程序发现问题，那么BSS将报告错误，并被要求从副本集中的一个良好副本中修复数据。需要注意的一点是副本集中的BSS数量并非固定的，这个示例有四个，但BSS的数量实际上取决于您要提供的耐用性保证。我们可以有两个BSS，也可以像这个示例中一样有四个，还可以有七个，这完全取决于您，这就是架构的灵活性。
由于BSS是有状态的，我们需要确保没有相关的故障会导致多个数据副本丢失，因此BSS必须分布在多个故障域中。故障域是一个术语，其定义取决于您的具体需求，"Direct Drive"架构允许您在灵活的范围内选择。一个常见的示例是，副本集中的BSS不应该都连接到同一个交换机上，如果是这样，如果交换机崩溃，您将无法访问您的数据，但根据您的环境，您还可以将"副本集"的定义扩展到包括电源供应，这只是一个示例，定义已经编入我们稍后将讨论的元数据层，该元数据层了解这些定义的故障域，并会确保BSS分布在它们之间。
好了，让我们谈谈写入一个切片。当您对Disk发出写入请求时，写入会发送到变更协调服务（CCS）。CCS会为该写入分配一个序列号（LSN），在这个示例中，我们有一个未排序的写入请求到达，CCS已为这个写入分配了下一个序列号107。然后，CCS以并行方式将这个写入复制到副本集中的所有块存储服务（BSS），如图所示，在这个示例中，所有这些BSS目前都处于106状态。
BSS会接收该写入，它们会持久存储它，然后执行一种称为"承诺（promise）"的操作返回给CCS。"承诺"就是字面意思，如果您回到我这里并要求数据，我承诺我可以将其交还给您。在这个特定示例中，您可以看到BSS 0、1和3已成功地承诺了该写入，但在这种情况下，BSS 2稍显滞后，可能由于网络拥塞或当前速度较慢。"承诺"是指从CCS的角度来看，操作在得到m个BSS实例的成功"承诺"之后完成，这是架构中另一个灵活的领域。在这个示例中，我使用了四分之三的"法定承诺"，所以三个中的一个，但我们同样可以选择四分之四，或者任何其它值来满足您的耐久性需求。一旦CCS获得必需数量的"承诺"，它就可以自由地将该操作完成并返回给发起者，因此现在我们可以向发起者"承诺"写入确实发生了，然后如果您返回并读取它，我们就可以将其提供给您。
读操作可以直接发给副本集中的任何BSS。在这个示例中，我们向BSS 0发出了读请求，它有数据，因此可以成功读取。请注意，读操作会带有一个序列号，与写入不同，这是为了避免在配置基于法定承诺时返回过时的数据。在这个示例中，我们使用了四分之三的法定承诺，因此如果我们向滞后的BSS，即BSS 2发出读请求，它不能返回数据，或者不应该，否则将返回过去的数据，因此序列号允许该BSS失败I/O。在这种情况下，您可以重新向副本集中的任何其它BSS发出读请求，它将成功。在实际生产中，我们发现以这种方式重试的需求非常罕见。我们看到的大多数工作负载不具有发出写入然后立即读取刚刚写入的数据的模式，而且复制速度相当快，因此所有副本都赶上的时间不会很长。不过，如果这确实成为问题，您可以通过将n和m设置为相等，从基于法定承诺切换到全面承诺，这种情况下，您将永远不会看到写入完成，直到副本集的所有成员都具有数据。
现在，我们已经了解了副本集、CCS以及多个BSS是切片的一部分，但每个CCS和每个BSS在多个切片中扮演着这个角色。在这个示例中，您可以看到切片零具有CCS零和BSS零等，切片一与切片零共享CCS，还有几个BSS，以此类推。这样做的目的是允许我们将特定虚拟Disk的负载分布到许多后端存储元素中。
现在，我们一直在讨论如何在后端以切片方式管理Disk，但这并不完全是我们向Disk客户端自身公开的视图。如果我们这样做了，那么某些工作负载，比如顺序工作负载，可能会在相当长的时间内对某些副本集产生不利影响，直到它们切换到下一个切片，然后下一个切片，所以我们使用了一种非常常见的技术，我们从客户端的角度来看，数据是条带化的。条带化算法也非常灵活，这只是一个示例，所以我们有一个四路条带集，因此每个条带集包含四个切片，我们将宽度设置为256k，因此从客户端的角度来看，Disk的前256k将是切片零的前256k，而Disk的下一个256k将是切片1的前256k，依此类推。
关于Disk客户端，我们的Disk客户端被称为虚拟Disk客户端（VDC），实际上分为两个组件。所以VDC位于Hyper-V存储堆栈下面，链中的第一个组件是我们称之为VDC代理的组件。VDC代理对于在Disk处于活动状态时提供服务非常重要，也就是说在它们正在接收来自客户的I/O时。大多数情况下，VDC代理以直通模式运行，因此I/O会直接从虚拟机通过它流向下到VDC。然而，如果我们需要在下面的堆栈上提供服务，同时Disk已经存在并且I/O正在进行中，VDC代理会介入，开始积累来自其层中的虚拟机的I/O，并且还会序列化其下方VDC的内存状态，从而允许我们卸载下方的VDC堆栈，将其替换为更新的版本，然后我们可以重新加载所有状态到VDC并允许I/O通过。因此，最坏的情况下，虚拟机可能会经历短暂的I/O性能下降，而不知道我们已经替换了它们下面的整个存储堆栈。
VDC是大部分操作所在的地方，负责挂载和卸载Disks，报告错误，处理错误响应，对I/O执行限流，以及所有我们刚刚看过的Disk条带化逻辑都在其中。VDC与实际托管存储角色的节点之间有两个通信通道，一个是数据平面，一个是控制平面，稍后我们会更详细地讨论这些。
到目前为止，我们已经介绍了所有我们认为属于Direct Drive数据平面的组件，所以我们有我们的VDC客户端，有用于顺序操作的更改协调器，还有可靠地存储和检索I/O的块存储服务，所有这些都通过我们称为DDX的自定义存储网络协议连接在一起。我将推迟讨论DDX，直到稍后在这个讲座中。
到目前为止，我们还没有谈到的是控制平面。我们控制平面中的主要服务称为元数据服务或MDS。MDS是运营的大脑，它负责决定哪些CCS和VSS位于哪个副本集中，它处理Disk控制平面请求，如创建Disks、删除Disks、扩大Disks等。它还是所有错误报告的累加器，因此系统中的任何问题都将由代理报告给MDS，MDS将收集这些问题，检查它们，然后确定需要什么纠正措施，然后向其它存储元素发出纠正措施的命令。MDS还需要分布在多个故障域中，以避免相关的故障，我们使用Paxos来在它们之间复制状态，因此在任何给定时间都有一个主MDS和多个备用或次要MDS。如果主MDS失败，将进行选举，选择新的主MDS，然后继续执行。我们使用自定义RPC来进行簇内控制流量，这是MDS相互通信以及BSS和CCS之间通信的方式。
控制平面的另一个重要元素是我们的网关服务，网关服务位于我们的控制平面MDS和外部世界之间，所以所有额外的簇外流量都通过一个软件负载均衡器，经过网关进行身份验证，然后传递给主要MDS，使用我们的自定义RPC。
好了，把这一切放在一起，我们最终看到了整体视图，这是Direct Drive架构的高级块概述。你看到我们的数据平面在顶部，我们的控制平面在底部，我们有我们的Azure资源提供方，这些提供方将前置像Azure门户这样的东西，当您进入用户界面并单击创建Disks等操作时，这些请求来自这些资源提供方。
好的，那么我们挑选了一些我们认为可能会引起这个听众兴趣的显著设计元素，现在我们将逐个讨论其中的一些。
所以之前我提到我们有一个定制的数据平面存储网络协议，它是为Direct Drive数据平面构建的，其中的一个最初的问题是，为什么你不只是使用NVMe over Fabrics、iSCSI或其它现成的块协议，这是一个合理的问题。我们的答案是有三个主要原因，我们决定实施一个自定义协议，所以我们真的希望消除中间层，允许客户直接访问他们的数据，正如我们之前看到的，读写路径需要在存储元素和Disk客户端之间来回传输这些序列号，如果没有这些，我们无法高效地提供我们感兴趣的功能，如在分布式切片副本集上的一致读写、共享Disks、崩溃一致分布式快照、Disk迁移等。所以客户必须参与其中，而协议必须理解需要来回传输这些额外的元素。另一个非常重要但经常被忽视的属性是，我们是根据我们快速诊断问题的能力来生存和死亡的，特别是在Azure规模下，有太多的机器，无法让开发人员花费大量时间查看单个机器以弄清楚为什么某些事情可能不工作。所以我们的一种方法是，我们已经在协议中直接加入了诊断支持。这看起来的一种方式是，我们可以用我们所谓的活动ID为这些I/O标记，这样作为客户I/O穿越大网络中的多个元素，我们可以很容易进行分布式日志搜索，从每个相关节点迅速提取出在传递过程中每个节点上发生了什么。这对我们来说至关重要，以弄清事情是如何工作的，出了什么问题，但更重要的是，我们不希望不得不查看日志，如果不必要的话，我们在DDX中的一个重要的事情是允许响应消息携带来自响应方的重要诊断内容。一些例子，看起来是这样的，这个请求在我的节点上或者从我作为响应方的角度花了多长时间排队，从我自己的角度看，我在等待存储介质上处理这个I/O所花费了多长时间。如果我们传递这些信息并对其进行聚合，我们实际上可以编写一些相当复杂的自动诊断工具，它们将找到网络中的慢点，这使得我们更容易找到例如网线出现问题的节点，或者因某种原因开始出现故障，这样我们可以自动从我们的群集中逐出它，而不必让工程师去查看它。最后，我们希望保持我们的灵活性，云中的事情发展迅速，我们需要有能力来演进我们的协议，以满足客户的需求，实施对我们和我们的客户重要的新功能，并利用出现的机会。现在，这并不是说现成的协议不好，它们显然不是，它们作为通用标准非常有用，允许您不控制的客户访问存储，在这种情况下，我们控制客户，并且内置这些额外功能对我们有利。在接下来的谈话中，我们将讨论Azure X-Store架构，并将回到这些其它协议。
另一个有意思的事情是我们对RDMA的使用，如果你一直参加这个会议，你可能还记得我已经在这里多年了，谈论RDMA，主要是关于Windows文件服务器中的SMB Direct。当我们设计和构建SMB Direct时，起初是为了支持Windows文件服务器，我们本可以将该功能直接构建到SMB客户端和服务器中，但我们选择将其实现为其自己的层，希望有一天能够通用使用，作为RDMA传输协议，所以我们最终实现了这一愿景，Direct Drive，并且我们从Server 2012那里拿走了一部分，并将其插入到我们的DDX启动程序和目标之下，这意味着如果RDMA存在，我们可以利用它，如果它不存在或出现故障，我们可以退回到TCP，而无需再次实现更多的自定义RDMA协议，我们只是将其放在了现有的SMB Direct之上，实际上，今天绝大多数的Azure Disk流量都是使用SMB Direct进行传输的。
另一个有意思的特性是我们对SCM的使用，非易失性内存SSD是快速的，但不如我们希望的那么快，它们在与垃圾回收交互的读写方面有一些有意思的特性，因此，有时候您会不幸地观察到高延迟的I/O，因为在闪存转换层中会出现干扰，因此一致的性能对我们和客户非常重要，我们解决SSD的这些问题的方式之一是，BSS在使数据持久化后能够向CCS承诺。现在，在这个示例中，我展示了对于每个切片，我们都有一个构建在SCM中的日志序列数据结构，我们接受写入，只要我们用SCM的任何必要技术使它们持久化。我们在我们的软件中构建了一种抽象层，允许我们向CCS承诺。我们的目标是让这些写入在非易失性内存中停留尽可能长的时间，只要我们不将其填满。现在的好处是，如果稍后有读取，我们可能能够从NVDIMM中完全提供服务，这会比SSD快得多，即使在写入路径中我们也可以大大减少写入聚合的优势。如果您有写入和覆盖数据的工作负载，例如，如果您的工作负载覆盖了扇区0 100次，实际上我们不必对持久化介质执行100次I/O，我们只需写出最后一次，因此实际上所有这些都会被掩盖，我们对我们的SSD进行了更少的I/O。当NVDIMM开始填满时，我们将执行一项称为排出的操作，我们将I/O排放到SSD中，回收SCM中的空间，从而允许我们接受更多的操作。
最后一个值得注意的特性是我们的一种有意思的限流（Throttling）系统，所以在我们谈论它之前，我认为谈论传统的I/O限流是有益的，通常情况下，您将从虚拟机接收I/O，然后在启动路径中应用限流，换句话说，您将保留I/O，直到它们匹配为Disk配置的速率，然后将它们发送到后端进行处理，将I/O完成返回给客户端，然后通常尽快将它们返回到虚拟机。这种传统限流的潜在问题在于，一旦将I/O发送到后端，就必须立即进行处理，而任何可能减慢I/O处理速度的因素都会增加错过完成期限的机会。
让我们快速看一个例子。在这种情况下，我们看到虚拟机向VDC发出了一组I/O请求，如果我们执行传统的限流技术，VDC会保留它们，并将它们发送到后端，以匹配配置的IOPS，在这个简单的示例中为“世界上最慢的Disk”。后端会以尽可能快的速度处理这些I/O，并将它们返回给VDC，然后VDC会以尽可能快的速度将它们返回给虚拟机，如图所示，在此示例中，我们正在满足Disk的配置IOPS速率。
传统类型的限流的挑战可以在此处看到，因此我引入了一个延迟气泡（latency bubble），这可能是后端负载的峰值，也可能是网络拥塞的突发情况，无所谓，有很多导致速度变慢的方法，你可以看到，由于VDC保持了I/O并按计划将其发送到后端，任何减速都会导致我们错过了黄色I/O的完成目标。
我们所做的是一种称为“完成侧限流”的操作，所以我们颠倒了模式，VDC将从虚拟机接收I/O并尽可能快地将其发送到后端，然后延迟将这些I/O的完成发送给虚拟机，以匹配配置的IOPS速率，因此实际上我们允许后端在实际到期之前提前工作，您可以提前处理工作，使其不必立即完成。这是它看起来的样子，从虚拟机中出现相同的一组请求，此时VDC将它们尽可能快地发送到后端，后端会以其能够的速率处理这些I/O，然后VDC会保留这些完成并将它们间隔开以满足配置的IOPS。现在我要介绍相同的延迟气泡，而在这种情况下，由于我们提前处理了I/O，如果你愿意的话，那就没有关系，所以完成仍然会满足Disks的配置IOPS。当然，这并不能消除每一次延迟，但是希望系统的设计和我们实施这种架构的方式能够应对这个问题。
虚拟机发出的相同一组请求，在这种情况下，VDC会尽可能快地将它们发送到后端，后端会以其能够的速率处理这些I/O，然后VDC会保留这些完成，并将它们间隔开，以满足配置的IOPS。现在我要介绍相同的延迟气泡，而在这种情况下，由于我们提前处理了I/O，如果您愿意的话，那就没有关系，所以完成仍然会满足Disk的配置IOPS。当然，这不能让我们完全消除延迟，但希望通过以这种方式在硬件中实例化此架构的系统设计，延迟超过我们可接受限度的可能性很小。
-----
问题：所以问题是如果延迟...
Greg Kramer：如果我们将这个延迟阶段提高，绿色和黄色完成的两个完成发生在之后，我认为你的问题是它们应该发生在哪里，对吗？我明白你的意思了，是的，我们会知道I/O何时发出和何时到期，所以如果我们收到一个迟到的完成，我们不会对它进行限流，从某种意义上来说，它已经到期，不需要进行限流，我们会允许它通过。
问题：BBC是如何发现CCS的呢？
Greg Kramer：当VDC要挂载一个Disk时，它会发送一个控制平面请求给MDS，并提供一个授权令牌，令牌表示我断言我有权挂载这个Disk，MDS将进行检查，假设一切正常，MDS将返回给VDC的是切片映射，你会获得一个数据结构，其中包含了Disk的大小、属性等信息，以及所有切片，对于每个切片，它还包含了CCS和BSS，所以现在VDC拥有了这些信息，当它从虚拟机接收到I/O时，它可以查询切片映射，并确定对于写入，它必须前往哪个CCS，对于读，是否有BSS可以发出I/O，如果映射在将来发生了变化...
问题：如果映射发生变化，VDC如何意识到这一点呢？
Greg Kramer：如果映射发生变化，例如，这可能是为了处理错误而发生的。举个例子，假设某个BSS出现故障，如果后端首先发现了这个问题，而客户端尚未发现，那么我们会向MDS报告这一情况，MDS会告诉我们将其从复制集中删除，并用新的BSS替换它，但VDC可能不知道这一情况。如果VDC试图向该BSS发出I/O请求，但该BSS已经不再存在，VDC会向MDS报告错误，例如：“嘿，我无法与应该在那里的这个人通信。”如果该BSS仍然可以通过网络访问，那么我之前提到的LSN（日志序列号）排序之一将允许我们检测到您正在与复制集的过时成员进行通信，换句话说，该BSS将能够通知VDC：“嘿，你不是最新的，不再是你应该与之通信的人。”此时，VDC将再次请求更新的复制集，你推进的方式非常巧妙。
Greg Kramer：对不起，你能再重复一遍吗？复制拓扑是不是感知的？
Greg Kramer：我明白了，你是在指的类似链式复制，但在我们的系统中，至少在今天，我们的配置方式是出于性能原因采用并行复制，所以关于采用完成端限流，是否会增加对后端的压力，因为我们允许大量请求进入，不会有很大的压力。
Greg Kramer：你的问题是：通过完成端限流，我们是否看到对后端产生了增加的压力，因为我们允许一大批请求涌入？
Greg Kramer：不完全是。完成端限流是一项有趣的优化，但我们并不完全依赖它。事实上，我想我之前有一条脚注。如果它变得有问题，我们可以简单地开始应用传统的启动端限流。如果有一个虚拟机突然变得非常活跃，发出大量I/O请求，我们可以允许它使用这种优化一段时间，然后说：“好了，够了，你需要冷静一下，然后我们再让你恢复到这种模式。”所以我们有一些对策来解决这个问题。
问题：MDS可扩展性的限制是什么？
Greg Kramer：这是一个有意思的问题，通常情况下，MDS在正常运行中并不会执行太多操作，就像它只是在那里，知道哪些Disk存在，哪些复制集中有切片，但在大多数情况下，它只是在那里，等待Disk挂载请求到来，以便它能够返回映射或者等待错误报告到来，以便它能够采取纠正措施。即使在错误报告情况下，它也不会非常耗费CPU，它只是整理它获得的错误报告信息，然后决定将谁踢出复制集，谁需要从哪里重建。所以我们并没有看到MDS的可扩展性问题。不过，如果我们开始观察到这个问题，只要允许多个MDS环，CCS和BSS都不在乎，只要它们得到了经过身份验证的消息，它们就会乐意按照指令去做。
问题：如果一个MDS成了热点，它会如何处理？
Greg Kramer：通常我们处理这个问题的方式是在第一时间避免问题的发生。所以，如果我们部署了一组Direct Drive存储单元，我们知道我们打算总共承载多大的负载，然后我们会设计我们的MDS，使它们能够处理这个负载。现在，如果一个MDS因某种原因表现不佳，变慢，不能按照我们的要求执行，我们只需将其切换到环中的另一个MDS。抱歉，我没听清楚你说的话。
问题：后端做一些增值处理...
Greg Kramer：现在这是一个Disk子系统，至少我不知道有一个通用的Disk接口允许你做到这一点，或者至少没有我所知道的，不过，再次强调，我们有自己的自定义存储网络协议，因此如果我们有一个大规模的要求要执行某个特定操作，那么没有什么能阻止我们传输这个操作到网络中并执行它。
Greg Kramer：有意思的是，使用RDMA和NVDIMM，我们实际上发现后端节点的负载相当低。这些节点不会以90%的CPU运行。
问题：热点问题的故障转移……
Greg Kramer：我提到了RDMA和TCP的故障转移，你是在说这个吗？
Greg Kramer：就像Windows文件服务器一样，DDX层知道位于其下方的网络。因此，如果有RDMA功能，我们会尝试使用它们，但是如果我们发现某个后端组件无法通过RDMA访问，或者如果由于某种原因RDMA网络变得不稳定，我们的DDX启动器中内置了启发式和逻辑，允许它检测到这种情况，然后决定回退到TCP可能更好，然后它会进行探测，尝试回到RDMA，看起来非常像Windows文件服务器的多通道功能。
问题：支持什么类型的块存储？
Greg Kramer：是的，我们支持4K原生Disk和512e Disk。
问题：虚拟机能否附加元数据吗？
Greg Kramer：不，目前还没有。
问题：虚拟机看到的是什么接口？
Greg Kramer：当前，虚拟机将看到一个SCSI设备。我们之所以选择SCSI，是因为它是我们在云中看到的所有操作系统中最广泛支持的Disk接口，而且它显然非常成熟。是的，虚拟机会发出SCSI命令，这些SCSI命令将通过VDC代理传递到VDC，通过Hyper-V虚拟化存储堆栈，然后在VDC中，我们将SCSI命令转换成我们自己的内部命令集。
问题：将来我们会在Windows上看到这种Disk架构吗？
Greg Kramer：我不知道，我今天没有产品公告要发布。
Greg Kramer：当前，我们实际上所有的Direct Drive生产环境都使用NVDIMM，即使在我们的测试环境中，我们也可以使用虚拟化的NVDIMM，因此虚拟机认为它们真的有NVDIMM，而NVDIMM现在并不那么贵。你不需要很多NVDIMM，正如我之前提到的，我们允许数据尽可能长时间地保留在NVDIMM中，然后进行de-stage操作，只是为了防止它耗尽，但这是可以根据工作负载来进行适当调整的。所以如果你的集群非常小，你将有相应较小的工作负载，需要更少的NVDIMM来满足它。
问题：是否真的需要NVDIMM，或者只是在寻找快速块存储？
Greg Kramer：当前，我们依靠有字节寻址的非易失性内存，所以我们把放入我们的日志中的数据都需要存储在NVDIMM中，当然，我们需要存储顾客写入的实际数据。对于每个I/O，除了数据本身之外，我们还需要存储一些上下文信息，比如是哪个Disk、哪个切片、序列号等等。如果我们必须为此消耗整个块，这将变得非常低效，所以我们依赖有字节寻址的内存。
---【本文完】---
近期受欢迎的文章：
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解