云原生应用程序与传统应用程序或托管在云中的传统软件具有不同的存储需求。为了更加高效地工作，云原生需要高性能和低延迟的存储。在实践中，建议使用本地 NVMe® 闪存，而不管编排平台如何。 

云原生应用程序是设计用于在私有云或公共云上运行的软件，旨在利用云计算软件交付模型的先天能力。云原生应用程序通常部署为由 OpenStack、VMware vSphere® 管理的虚拟机 (VM) 或由 Kubernetes 管理的容器。 

从基础架构架构师的角度来看，存储提供的性能越多，就越有可能在无需对存储系统进行任何更改的情况下扩展云原生应用程序。如果存储是分散的（不直接连接到服务器），则尤是如此。在这种情况下，架构师可以将更多服务器添加到越来越多的应用程序中，而无需同时扩展存储。在这种情况下，网络连接的 NVMe 闪存存储是满足高性能和低延迟要求的理想选择。  

云原生应用程序的 NVMe-oF 协议对比

NVMe over Fabrics (NVMe-oF) 为云原生应用程序提供了最佳存储特性——将 NVMe over 网络的低延迟和高性能特性扩展到远程设备。NVMe-oF 存在多种传输选项。但是，最常用的是基于远程直接内存访问 (RDMA) 的 NVMe-oF、基于光纤通道的 NVMe-oF 和基于传输控制协议/互联网协议 (TCP/IP) 的 NVMe-oF。这三者都支持创建具有高性能和低延迟的端到端 NVMe 存储解决方案。 

• NVMe-oF over RDMA——提供了一种通过网络在两台计算机的主存储器之间交换信息的方法，而无需涉及任何一台计算机的操作系统 (OS) 处理器或缓存。
• NVMe over Fibre Channel — 使用标准光纤通道 (FC) 协议在存储阵列和服务器之间传输数据，该协议支持访问共享的 NVMe 闪存。
• NVMe over TCP/IP — 使用 TCP 传输协议跨 IP（以太网）网络传输数据。

比较基于 RDMA 的 NVMe-oF、基于 FC 的 NVMe-oF 和基于 TCP/IP 的 NVMe-oF，着眼于成本、基础架构考虑因素和云原生应用程序的可访问性。

上表比较了 NVMe-oF over RDMA、NVMe-oF over FC 和 NVMe-oF over TCP/IP 作为云原生应用程序的存储传输协议。在开销成本方面，基于 FC 的 NVMe-oF 成为三者中最昂贵的。这是因为光纤通道需要一个需要 FC 主机总线适配器 (HBA) 的专用网络。该协议还需要 FC 交换机。与 RDMA 或 TCP 相比，这些项目导致光纤通道的成本更高。

在这三者中，基于 RDMA 的 NVMe-oF 的开销成本介于光纤通道或 TCP 之间。RDMA 不需要专用网络，但该协议确实需要特殊的 RDMA 交换机。相比之下，基于 TCP/IP 的 NVMe-oF 不需要自己的交换机、适配器或网络。因此，在大多数情况下，它是成本最低的选择。

RDMA 和光纤通道速率在基础设施复杂性、易用性和可扩展性方面低于 TCP。由于需要 RDMA 交换机，RDMA 面临可扩展性的限制。由于对 FC 交换机、HBA 和专用网络的要求，光纤通道同样复杂。使用单个交换机扩展单个 RDMA 或 FC 存储机架是一个复杂的过程。在这种情况下，路由限制也会出现。

NVMe over TCP 相对简单。它只在标准以太网 TCP/IP 网络上运行。不需要特殊的网络适配器或交换机。而且，它具有更高的可扩展性和可路由性——易于跨多条路由和不同网络进行扩展。这种差异还与存储的可访问性有关。与 TCP 相比，云原生应用程序对 RDMA 和 FC 存储的访问相对较少。基于 TCP/IP 的 NVMe-oF 可在任何地方被云原生应用程序访问。

用于云原生应用程序的 NVMe-oF 和 Kubernetes 

Kubernetes 是一个开源容器编排系统，可自动执行软件部署、扩展和管理。运行云原生应用程序的服务器可能很容易让 Kubernetes 运行数十或数百个微服务，这显然会影响服务器与存储资源交互的方式。

许多云原生应用程序使用微服务架构，这种架构可以有效地将资源分配给为特定任务设计的较小（微）服务，从而使应用程序灵活且非常适合云软件架构。

一些云原生应用程序是输入/输出 (IO) 密集型应用程序。它们需要高带宽和低延迟，因此更加需要满足这些要求的存储解决方案和协议。其他时候，作为应用程序共同工作的容器可能不需要大量的每秒 I/O 操作 (IOPS) 和低延迟。在云中，可能有数百甚至数千个应用程序作为容器在许多物理服务器上并行运行。总而言之，它们对存储的高性能以及高带宽和低延迟提出了要求。 

由 Kubernetes 编排的云原生应用程序具有独特的存储需求，可以通过 NVMe-oF 来满足。大多数 Kubernetes 应用程序都是数据密集型应用程序，因此它们需要 NVMe-oF 提供的那种高性能存储。对于像数据库这样的有状态应用程序尤其如此，这就需要来自存储的低延迟，以满足应用程序对于性能的要求。如果应用程序本身要扩展，此类应用程序的存储也必须能够轻松扩展。 

当 Kubernetes 应用程序可以访问正确级别的资源时，它们也会表现出色。无论是计算、网络还是存储，支持 Kubernetes 应用程序的资源都应该以正确的比例提供。如果应用程序依赖连接到运行 Kubernetes 应用程序的服务器的直连存储 (DAS)，则这是不可能的。几乎可以保证服务器的 DAS 使用不足或过度使用。从性能或经济角度来看，两者都不是可取的。

在这种情况之下，如果存储不直接连接到运行 Kubernetes 应用程序的服务器，则可以实现计算和存储的动态、独立扩展。使用这种方法，Kubernetes 应用程序将始终可以以正确的比例和正确的性能特征使用存储。 

分类存储还使 Kubernetes 应用程序能够从任何地方访问数据。实际上，能够让应用程序和存储变得可移植，因为 Kubernetes 应用程序可以跨不同的服务器运行和移动。一些架构师通过将存储放置在集群中来解决这个问题，但必须在所有这些地方都可以访问数据。 

基于 TCP/IP 的 NVMe-oF 对云原生应用程序的好处

TCP/IP 上的 NVMe-oF 为云原生应用程序提供了许多好处，除了可访问性强、开销成本降低和复杂性降低之外。它提供可充当本地闪存存储的虚拟化和集中式存储池。通过这种方法，基于 TCP/IP 的 NVMe-oF 意味着加速的应用程序性能，以及简单高效的扩展。

对于 Kubernetes 应用程序，正确的基于 TCP/IP 的 NVMe-oF 实施可以提供 DAS 的性能，但通过具有以太网网络便利性和普遍性的集群存储解决方案。以太网已经存在于每个 IT 环境中，因此很容易部署便携式存储集群。

结论

NVMe 成为云原生应用程序的最佳存储介质，满足了 Kubernetes 应用程序和类似云原生软件的性能需求。在 NVMe 传输选项中，基于 TCP/IP 的 NVMe-oF 为云原生工作负载提供了最佳质量组合。与基于 RDMA 或光纤通道的 NVMe-oF 相比，它能够以更低的成本和复杂性实现高性能存储。 

原文链接：​​https://dzone.com/articles/accelerate-cloud-native-applications-with-nvme​​   原文作者：Carol Platz