面向大规模部署的ZNS SSD
支持“分区命名空间”（Zoned NameSpace，简称ZNS）的SSD，因其在成本效益和性能提升方面相较于传统SSD具有显著优势，正逐渐成为大规模存储部署领域的热门选择。这些优势涵盖了吞吐量增加三倍至四倍、SSD寿命延长，以及将QLC介质应用于I/O密集型工作负载。随着分区存储硬件生态的日渐成熟，与之相关的开源软件生态也蓬勃发展。我们因此正迈入一个为大规模云服务提供坚实支撑的新时代。
本次演讲将重点介绍支持分区命名空间的SSD，并探讨SNIA分区存储工作组（Zoned Storage TWG）在标准化ZNS SSD设备模型方面所做的努力。
此外，我们还将深入讨论在文件系统（如f2fs、btrfs、SSDFS）、数据库系统（如RocksDB、TerarkDB、MySQL）以及云编排平台（如OpenStack和Kubernetes + Mayastor、Longhorn、SPDK的CSAL）上迅速崛起的软件生态系统。
主讲人：Matias Bjørling，西部数据
-----
我想谈谈这些大规模部署的ZNS SSD，以及我们当前所处的位置和我们之前为生态系统所做的所有工作。首先，我想解释一下我们为何投入如此多时间来构建生态系统和这些ZNS SSD等的原因。
超大规模云服务商面临的一大挑战是处理海量数据。他们需要在保证成本效益的同时，提供高性能的存储解决方案，以满足客户的需求。因此，他们通常关注IOPS、高吞吐量、低延迟、优质服务等关键指标，以及这些部署在数据中心时对整个TCO的影响。
其中，一个特别引人关注的部分是关于SSD的寿命和每日写入次数。根据具体应用场景的不同，一些人可能将每天一次写入作为他们的目标。在五年的时间框架内，一些超大规模云服务商正在尝试将硬件在整个机群中的使用寿命从五年延长到七年或更长。因此，当我们进入QLC和PLC NAND时代时，能够延长这些使用寿命的技术变得尤为重要。这些NAND具有较低的每日写入次数，因此我们可以利用技术来延长其使用寿命，使其在机群中的运行时间更长，并更好地发挥作用。显然，他们有充分的理由这样做，如碳中和、减少排放等。事实上，他们发现，如果可能的话，他们甚至希望将使用寿命延长到10年以上。这与我们当前面临的气候等问题高度契合，确实引人关注。
从传统的SSD角度来看，它们实际上难以实现七年或更长的使用寿命，通常只能维持三到五年的寿命。为了延长使用寿命，有两种方法：一是采用TLC存储器，但这会增加成本；二是选择QLC，但这意味着每日的负载写入次数会减少。因此，他们急需一种解决方案，既能解决SSD的写入问题，又能提升整体性能。
ZNS技术和其独特的命名空间为应对这些挑战提供了一种途径。在这里，我们看到传统SSD位于底部，当我们选择TLC时需要支付更高的成本，而QLC则具有更优化的成本结构和每日负载写入次数。尽管有些厂商的QLC每日负载写入次数稍高，但至今我尚未见到任何传统的QLC驱动器，其每日负载写入次数能超过一次。
当我们在SSD的TLC上应用分区命名空间支持时，效率显著提升。具体来说，你可以每天进行3.5次写入，而无需额外的OP。如果你使用传统SSD并采用28%的OP，虽然可以达到相同的效果，但你需要为介质支付约30%的额外费用。QLC则提供了一种平衡方法，在这种方法中，其典型的每日负载写入次数大约在这个范围内。这就是看待存储介质的不同方式。你可以选择适合自己的方法来满足需求。
另一种看待问题的方式是，性能通常都需要付出高昂的代价。以Facebook描述的缓存翻转缓存引擎为例，在他们几年前的一篇关于缓存引擎的论文中，他们致力于在驱动器上尽可能减少慢写入。为了实现这一目标，针对这些工作负载，他们大约使用了100%的OP，并且仅使用了SSD约一半的容量。因此，如果采用这种方式，为了获得所需的性能，最终可能需要两倍的SSD容量。然而，与ZNS相比，如果使用ZNS技术，则只需要一半的容量。
那么，成本如何呢？对于SSD而言，主要成本在于NAND介质，当然还包括控制器、DRAM等其他成本。但是，当将更多的存储介质连接到一个控制器时，主导因素就变成了存储介质本身。这意味着，在Facebook的案例中，他们为这个特定的工作负载付出了两倍的存储成本。
当他们追求这些低写入端点时，他们会关注我们所做的事情。例如，某些支持分区命名空间的SSD具备哪些功能以及能够完成哪些任务。这些SSD实际上消除了SSD的写放大问题，这与基于垃圾的写入应用程序类似。尽管SSD内部仍然存在一些存储介质可靠性的问题，但它消除了主要源头，即在此情境下的写放大。这是通过修复存储接口与主机之间的不匹配来实现的。该接口是为主机提供的随机读取接口，当数据进入SSD时，它会进行匹配，以便可以协同处理数据放置。
吞吐量是其中的一个关键因素。以传统SSD为例，在特定情况下，OP可能会从7%下降到3倍。如果你使用28个OP，那么大约是2倍。因此，这种匹配是可行的。然而，如果你使用ZNS驱动器，那么它的表现将更为稳定，没有特别的波动。
另一种看待它的方式是从延迟的角度来看待它，你可以在x轴上添加写入操作，比如每秒写入200MB/s、400MB/s，随着写入量的增加，4K随机读取延迟也会逐渐上升。但这种增加是一种非常稳定的线性扩展。相比之下，传统的SSD在数据中心进行处理和激活时，读取延迟会有所增加。一旦达到最大值，例如对于这种情况来说是每秒写入400MB/s，驱动器的介质配置可以达到每秒1.1GB/s，但实际上在SSD内部只能实现这么多，而主机只能写入其中的360MB/s，其余部分会进行垃圾回收。这意味着驱动器上会发生很多活动，这正是我们想要避免的。因此，从吞吐量、延迟或驱动器的生命周期等任何你想要的角度来看，ZNS技术都带来了明显的优势。你可以根据自己的需求进行选择和评估。
我们是如何发展到现在的呢？在座的许多人都是这个生态系统的重要组成部分，许多人参与了ZNS的标准化工作。我们从2018年开始共同努力，历经一年半的时间，终于完成了完整的规范。这是一项由众多人共同参与、激动人心的工作。我们新增了一个规范文件，并在2020年6月完成了这项工作。现在，我们有了可以依据的规范，接下来需要为它提供支持。因为尽管ZNS的数字看起来很出色，但要想使用它，还需要软件的支持。因此，软件生态系统也增加了大量的支持，与规范发布同步进行。所有这些支持都被整合进了Linux内核。在Linux生态系统中，具体来说就是Linux内核，它们在规范发布后立即添加了对ZNS的原生支持。随后，我们对其进行了改进，并添加了SPDK报告。所以，如果你正在构建一个使用SPDK的项目，你可以利用SPDK提供的库函数来处理ZNS文件。
规范发布后不久，各大厂商就开始推出支持ZNS的SSD产品。因此，自2020年以来，这些工作一直在持续进行。我们正在逐步迈向ZNS驱动器的第二代，市场对此反应热烈。我们参与并推动了生态系统的发展，展示了ZNS的多种应用方式和部署方法。
关于ZNS和分区命名空间，我已经多次提及。那么，它们究竟是什么呢？简单来说，ZNS是一种具有区域抽象的NVMe命名空间。这些区域就像这个空间内的逻辑块，被划分为固定大小的单元，并传输给主机，使主机能够据此进行数据定位。这里的关键是，一个NVMe SSD就是一个命名空间。因此，在SSD中，你可以有一个分区命名空间，它包含这些区域指令；同时，你也可以让这个SSD成为传统的命名空间，即传统的SSD。
我们目前正在进行的基准测试对比了一个传统驱动器和一个具有分区命名空间报告的驱动器。它们是同一个驱动器，只是现在我们使用传统命名空间来展示分区命名空间，这样我们就可以进行真正的比较。我指的是我们从中获得的好处，因为这样可以进行直接的对比。这令我非常兴奋，因为我们可以消除通常会影响结果的各种干扰因素。这里的硬件相同，固件相似，固件内部的数据路径也非常接近。这真是一件很酷的事情。
另一个引人注目的部分是，这种接口模仿了为主机管理SMR驱动器所做的工作，Damian Lemole的团队多年来一直在致力于构建和强化这一生态系统。因此，我们在ZNS方面的工作并非从零开始，而是在此模型的基础上进行对齐。多年的工作已经为我们铺平了道路，使得我们能够顺利启用所有这些功能。我们不是从零开始，而是从已经在现场由最终用户部署并实际运行的东西出发，逐步添加和完善。
现在让我们来概览一下这个生态系统。开发工作始于2016年，甚至在此之前就已开始。2016年是实现通用Zone支持的关键一年，尽管之前的命令传递和其他方式也提供了支持，但这一年真正实现了稳定性。因此，这是一个长达十年的努力，我们现在正处于构建某种东西通常需要花费这么长时间的阶段，尤其是在当前构建文件存储器的背景下。各种主要发行版如Red Hat、CentOS、Debian、Ubuntu等都得到了支持，几乎涵盖了您提到的所有内容。换句话说，这些发行版都在某种程度上得到了支持。因此，如果您有一个特定的存储设备型号需要得到支持，我可以回去查看并插入相关信息，它就会顺利运行，并且还有相应的工具等可供使用。
另一个重要进展是我们现在支持本地文件系统。起初，我们主要支持f2fs，这是一种专为移动设备如手机和平板电脑设计的文件系统。但最近，我们的团队又增加了对btrfs的支持，这意味着企业级文件系统现在也能与ZNS和主机管理系统进行无缝交互了。这一进步非常令人振奋，因为它解决了围绕ZNS的许多难题。那么，我们如何利用这些功能呢？如果你有一个本地文件系统，通常只需简单安装，然后利用通用的文件API，你就可以进行随机写入，或者进行其他任何你需要的操作。
此外，我们还支持各种存储系统，如Ceph分布式存储系统以及其他一些可能会迁移到云端或作为分区存储的系统。还有一种名为SPDK的云存储加速层，它与SPDK中的CSAL FTL类似，适用于所有闪存阵列。同时，我们还提供了一系列库，包括libzbd、libnvme、SPDK、fio等。这些都是我们提供的通用支持。我所强调的焦点，以及我们团队当前努力的方向，是端到端应用程序的增强。这涉及到云编排、数据库、缓存等多个方面。
值得一提的是，这些技术已经在当今的云服务商中投入生产使用，并且规模庞大，特别是由SMR生态系统推动。因此，它们已经成为日常使用的一部分，并被数百万用户投入生产。这确实是一件令人自豪的事情。经过这10年的努力，我们取得了显著的成就，并且得到了很多人的支持。过去的十年里，我们的工作非常出色。大约有20人全职投入了这段时间，他们的努力令人赞叹。
我想谈谈客户如何部署这些存储解决方案。根据我们的观察，主要有两种方式。一种是通过存储阵列使用SSD，另一种则是通过本地存储。我们先来谈谈存储阵列。有些厂商提供了自己的专用解决方案，还有一些用户选择DIY的方式，结合办公室环境和其他技术，如流媒体SDS等。这些方案通常在阵列内部运行像FTL这样的技术，并对外提供统一的接口。另一种方式是使用本地存储，用户可以直接在这个本地文件系统上运行各种应用程序。我之前提到的支持就是这样，应用程序并不需要知道背后的具体实现。
对于存储阵列，尤其是全闪存阵列，我们通常通过像邮件传输协议、NFS、Samba等方式将其暴露给外部用户。在存储阵列内部，会有一些软件负责进行必要的转换工作，然后将传统的存储接口暴露给最终用户。这样的高性能存储系统非常适合用于AI、ML、流媒体和数据库等场景。
在推动这种解决方案的过程中，我们的一个目标是使用QLC SSD来替换部分HDD工作负载，并确保每天的写入次数大于1。实际上，我们越来越接近实现这一目标的能力。以阿里巴巴为例，他们与英特尔和我们一直保持着紧密的合作。在第三代云数据平台中，他们成功使用QLC SSD替换了硬盘。与旧系统相比，新系统的性能提升了两倍，同时密度也更高。当然，这背后还有很多细节，但大致情况就是这样。
这是人们部署这种存储的其中一种方式。另一种方式是，一些企业选择开发自己的专有解决方案。我们一直在关注这一趋势，尤其是Solidigm和阿里巴巴在QLC方面的研究进展。SPDK中的云存储加速层就是一个很好的例子，它作为一个翻译层，具备写入塑形功能，与QLC协同工作以实现更好的扩展性。Solidigm正与其合作伙伴共同努力，打造一个即插即用的参考平台和实现方案，这确实非常酷。用户只需部署这个镜像，就可以轻松拥有自己的解决方案，使用体验非常便捷。
另一种部署方式是使用本地存储和文件系统。这种方式适用于那些不需要分区存储的极致性能的场景。有些用户可能只是想要拥有存储设备，而他们的应用程序可能并不需要那么高的性能，或者尚未进行优化。通常，在使用这些存储器时，我们会将其作为文件系统的一部分来使用。因此，无论如何都会有一些数据存储在上面。为了获得最佳性能，建议将其放置在支持分区存储的文件系统上，例如f2fs和btrfs。现在，这些文件系统已经得到了启用。特别是从5.12版本开始，btrfs在SMR硬盘上已经非常稳定。在最新的内核发布版本中，我们在ZNS上也实现了稳定性。
我们从这次经验中得到的教训是，当我们观察这种集成时，它更像是一种比较。我们将一个带有ZNS支持的驱动器与一个普通驱动器进行比较，然后仅在具有这种支持的文件系统上运行测试。在基准测试期间，我们确实发现了一些改进。虽然并非完美无缺，但与没有ZNS支持的驱动器相比，性能提升了五到十个百分点。对于应用程序接口来说，它仍然只是一个标准的POSIX文件API。你不需要知道底层是分区存储，也无需关心这些细节。但由于你在底层使用了一个ZNS驱动器，你获得了这5~10%的额外吞吐量。
然而，真正令人印象深刻的是延迟方面的表现。你会明显看到传统驱动器的性能曲线急剧下降，而ZNS驱动器的性能则更加稳定。此外，你还可以节省28%的OP，这意味着在使用ZNS驱动器时，你可以充分利用整个驱动器的容量而不会出现减速。此外，你还获得了额外的存储容量。
另一值得一提的特点是，它原生支持基于提示的放置方式。这种方式与ZNS完美融合，无需在设备上安装任何软件或进行特殊配置，即可顺畅运行。你只需简单地插入驱动器、进行格式化（mkfs），然后将其指向相应的驱动器。随后，你可以部署应用程序，而无需关心其是否采用分区存储。它就像任何其他标准存储设备一样正常工作。
然而，当你们希望充分利用系统性能时，这就是我们提供的端到端应用程序集成堆栈发挥作用的地方。特别是在处理IO密集型应用程序和高写入吞吐量等场景时，我们的技术能够发挥巨大的优势。这类似于处理大规模存储系统，当你们处理EB级数据时，系统的效率至关重要。为此，我们正在研究各种应用程序，以确保在各种场景下都能实现最佳性能。
我们和社区已经付出了大量的努力，其中涉及了众多关键组件，如MySQL、Terark等。还有RocksDB，这是一个重要的upstream支持。此外，还有一个名为Longhorn的项目，它与各种发行版紧密相关。因此，当这些组件通过集成时，我们确实希望深入探讨它们，并分享相关的集成经验。
这个项目是与WD和Percona共同合作的成果。在这个项目中，我们选用了RocksDB作为核心组件，并成功将其集成到Percona MySQL中。现在，我们来看看是谁开发了这个NFS启动后端，并将其插入到RocksDB的upstream代码中。正是这一举措，让RocksDB能够在具备分区存储的驱动器上实现原生运行。
今天的工作内容是这样的：你获得了一个公共的容器镜像，这就像平常你拿到一个容器一样。你可能会说：“这是一个MySQL镜像，它支持多种存储引擎。”这些存储引擎并非简单的插件，而是与MySQL紧密集成，共同工作。
通过采用这种集成方式，我们获得了更高的吞吐量和更低的延迟。你可以获得相同的存储引擎，同时享受到卓越的插入性能，因为现在的写入操作变得非常高效。在读取方面也有所改进，但一个特别值得注意的地方是，虽然改进很微妙，但当你使用MySQL时，通常会选择NODB存储引擎。而当你切换到RocksDB时，它经过优化，能够更好地利用空间。
通常情况下，NODB在读取路径上可能稍逊一筹。但当你将RocksDB与ZNS和这些优化相结合时，你会发现它在性能上与InnoDB相差无几。因此，在处理以读取为主的工作负载或数据库工作负载时，你可能会选择NODB；而当你需要高效写入或写入密集的工作负载时，RocksDB将是更好的选择。
将这两个引擎结合在一起，我们可以实现多种性能优化。这确实令人兴奋，也是RocksDB之前所不具备的功能。当然，这并不是说其他存储引擎一无是处，而是RocksDB的这一特性为我们提供了更多的选择和灵活性。
我们一直在深入研究CacheLib，这一领域的工作仍然非常丰富。刚才我分享的只是冰山一角，这仅仅是论文评论中的一点内容。CacheLib是Facebook开发的一款通用开源缓存引擎，广泛应用于Facebook内部的多种存储服务中。令人称奇的是，它既可以利用DRAM，也能利用闪存。为了验证其性能，我们进行了一项基准测试，采用了Meta提供的五天跟踪数据。
关键在于，我们是在全容量状态下运行驱动器的，这意味着我们使用了7%~28%的OP。特别是在这个OP范围内，我们充分利用了整个驱动器的容量。如果在普通驱动器上这样做，性能会大打折扣。Facebook的做法通常是只使用驱动器的一半容量。但在这个特定场景中，我们选择了全容量使用。当然，这里涉及到一些技巧，虽然我不想深入讨论，但通过这种方式，我们可以在保证读取性能的同时，实现高效的写入性能。
在这个基准测试中，我们观察到了3倍的写入吞吐量提升，读取性能也翻倍。在延迟方面，我们实现了2倍到10倍的改进。这真是一个非常激动人心的成果，而且CacheLib即插即用，无需额外配置。目前，这一工作尚未整合到upstream项目中，但我们相信这将展示其巨大的潜力。由于相关论文尚未发表，我们仍在等待更多细节的披露。
另一个值得关注是Ceph Crimson。当你构建高性能计算（HPC）系统或大规模存储系统，如硬盘阵列时，Ceph Crimson可能会成为你的首选。像谷歌、暴雪这样的公司，他们使用Ceph，并有着惊人的部署规模，如1.1EB的遥测数据。这也是他们乐于分享的成功案例。Ceph现在已成为非常流行的文件系统，而Crimson作为Ceph的下一个版本，正在致力于对分区存储的原生支持。这意味着无论是管理更多的传统驱动器还是ZNS驱动器，Ceph都能轻松应对。
使用Ceph时，它的表现与传统存储系统类似，你无需关心底层的存储细节，它只需稳定工作即可。因此，即使你在顶部运行常规工作负载，Ceph仍能提供约30%的额外吞吐量，且整体表现优异。这也是Ceph的另一个优势所在，所有这些都得到了本地支持，你无需担心兼容性问题，它只需稳定工作即可。
最后要提到的是云集成。在部署应用程序开发等任务时，很多团队会选择使用云编排平台。现在，我们正在从无状态的容器向有状态容器转变，为此，我们看到了一种解决方案。我们希望将这些存储器暴露给容器，以便它们能够顺利使用。我们已经与Longhorn、OpenEBS以及CSAL进行了集成。在右侧的展示中，你可以看到我们支持的块存储解决方案，包括Longhorn和基于SPDK的CSAL工作。
实际上，我们为那些需要全方位快速响应的地方暴露了分区驱动器。整个工作负载都在一个容器中完成，所有相关组件都紧密相连。运行这些容器的应用程序无需关心分区存储的存在，它只需要专注于自己的工作，所有其他事情都由其他组件处理。
这有点像将今天的生态系统与2020年进行对比。我们可以看到，现在已经有大量的支持存在，专用命名空间命令集已经被广泛添加到各大供应商的产品中。我认为，Linux软件生态系统得到了很好的支持，并且受到了现有基金会的很大帮助。用于主机维护的基础设施也有所改进，这在本地文件系统和关系键值数据库系统方面尤为令人兴奋，因为这些领域的工作负载通常都非常I/O密集。
我们看到，这些供应商在打造SSD的同时，也在进行验证等工作。在发布后，我们意识到一个关键的问题：ZNS的不同版本实现导致了在Linux内核中的支持并不总是顺畅，甚至有时候客户拿到的驱动器也无法正常工作，因此他们并不清楚自己手中的设备到底是什么情况。
然而，值得欣喜的是，通过SNIA的努力，我们已经实现了标准化和通用的设备模型。这意味着，我们可以共同支持那些具有相同属性的存储设备，当我们在构建软件堆栈时，这些设备能够协同工作。此外，我们还致力于简化使用流程，让你无需关心存储的细节，只需专注于你的应用程序即可。我认为，这对于本地文件系统和云解决方案的本地支持来说，都是极其有益的。
在SNIA的这个模型中，我们成立了一个分区存储技术工作组，并已经投入了大量的时间和精力。我们的一项重要工作是定义了这些分区存储设备的共同需求，这在一定程度上颇具意义。通过这样做，我们可以吸引多个供应商参与，最终用户也可以从多个渠道购买到符合他们需求的设备。用户只需指定他们想要的型号，就可以获得具有相同功能但满足共同软件需求的设备，从而为他们提供了一些通用的构建方案。
具体而言，我们已经实现的一些标准化成果。高性能和高容量的模型得到了很好的描述，并明确了用例。我认为这非常出色。此外，添加了对分区存储设备的共同需求也令人兴奋不已。这一标准明确了可靠性是由主机还是驱动器来管理。在定义分区存储规范及其专用命名空间命令集规范时，我意识到稀有级别和可靠性通常都在驱动器上。出乎我意料的是，有些人认为这些应该在主机上。后来我发现，我们确实倾向于将事情放在主机上，并让主机负责可靠性。这一转变彻底改变了整个局面，使得软件设计更具挑战性。现在，我们需要考虑不同的软件策略。因此，我们可以将这种管理方式称为“驱动器上的驱动器管理”。即使主机不采取任何行动，数据也不会丢失，仍然安全地存储在驱动器上。
关于分区，还有一些要点需要说明。当你向分区写入数据时，其容量是静态且固定的，这一点至关重要。此外，还有一个叫做“无活动分区迁移”（No Active Zone Excursions）的技术性概念。在编程介质时，有时会出现损坏故障，这时你必须停止操作，之后就不能再向那个闪存块写入数据了。当SSD遇到这种情况时，它会告诉你：“没问题，我会修复的。”这意味着作为主机，你无需关心这些细节，可以继续进行写入操作。这就是分区所定义的特性。此外，还有一些关于寿命结束只读模式等方面的问题需要考虑。因此，这项工作确实非常令人兴奋，我们最近从七月份开始就一直在努力推进。
另一个值得关注的方面是嵌入式设备的存储。虽然我个人没有深入参与，但谷歌一直在推动存储支持进入移动设备。这在数据内部是一种重要趋势。谷歌与他们的合作伙伴一直在紧密合作，推动这一领域的发展。这是他们在Android硬件生态系统中考虑的关键用例。因此，我们看到了平板电脑、谷歌手机等设备的存储方案。这是向下一代移动平台迈进的重要一步。
一个令人兴奋的部分是，当我们进行ZNS工作时，我们首先需要获得所有文件系统的支持。对于一些不支持的存储文件系统，如ufs，我们需要付出额外努力。然而，主要的Android文件系统f2fs已经得到了很好的支持。最初由三星开发，后来华为也加入其中，现在谷歌是主要的开发者。这项工作已经取得了很大进展，现在非常稳定，分区支持也经过了长时间的测试。因此，当供应商交付这些驱动器时，他们只需将驱动器放入f2fs文件系统中，然后将其整合并交付出去。对于ZNS来说，我们可能需要更长的时间来获得完整的支持，但我们相信它最终会被部署到生产环境中。对于分区ufs来说，我相信交付时间会短得多，因为生态系统已经存在并且正在运行。这令人非常期待未来的发展
好的，这是本次演示的最后一页。对于分区命名空间来说，其初衷是满足客户的不断增长的需求，确保他们的系统能够稳定运行五年、七年甚至更久。
在我看来，软件生态系统目前已经相当成熟。我们拥有多种存储阵列和即插即用的解决方案。以CSAL和ZNS QLC为例，它们都配备了稳健的文件系统支持，无论是客户端还是嵌入式设备，如平板电脑和手机，还是企业工作负载所使用的btrfs，都能稳定运行。因此，您无需担心底层是否采用分区存储。
此外，我们还实现了端到端的集成，确保整个系统能够全速运行，同时尽可能地获取更多的资源。当然，我们也加速了数据库的性能，并提供了分布式文件系统、Kubernetes和OpenStack等解决方案。
---【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）