云原生应用与云中托管的传统应用或传统软件具有不同的存储需求。为了高效地工作，云原生需要高性能和低延迟的存储。实际上，无论编排平台如何，都建议使用本地NVMe?闪存。云原生应用程序是设计用于在私有云或公共云上运行以利用云计算软件交付模型的固有功能的软件。云原生应用程序通常部署为由OpenStack、VMwarevSphere?管理的虚拟机(VM)或由Kubernetes管理的容器。从基础设施架构师的角度来看，存储提供的性能越多，就越有可能在不需要对存储系统进行任何更改的情况下扩展云原生应用程序。如果存储是分散的（不直接连接到服务器），则尤其如此。在这种情况下，架构师可以向越来越多的应用程序添加更多服务器，而无需同时扩展存储。在这种情况下，网络连接的NVMe闪存存储是满足高性能和低延迟要求的理想选择。用于云原生应用程序的NVMe-oF协议与NVMeoverFabrics(NVMe-oF)为云原生应用程序提供最佳存储特性——将NVMeover网络的低延迟和高性能特性扩展到远程设备。NVMe-oF存在各种传输选项。但是，最常用的是基于远程直接内存访问(RDMA)的NVMe-oF、基于光纤通道的NVMe-oF和基于传输控制协议/互联网协议(TCP/IP)的NVMe-oF。这三者都支持创建具有高性能和低延迟的端到端NVMe存储解决方案。NVMe-oFoverRDMA-提供一种通过网络在两台计算机的主内存之间交换信息的方法，而不涉及计算机的操作系统(OS)处理器或缓存。NVMeoverFibreChannel——使用标准光纤通道(FC)协议在存储阵列和服务器之间传输数据，该协议支持访问共享的NVMe闪存。NVMeoverTCP/IP-使用TCP传输协议通过IP（以太网）网络传输数据。标准NVMe-oFRDMANVMe-oF光纤通道NVMe-oFoverTCP(NVMe/TCP)开销中等高低基础设施考虑因素和复杂性，包括互操作性和易用性复杂-可扩展需要复杂的支持RDMA的交换机——需要专用网络、FC交换机和HBASimple——利用标准的TCP/IP网络。这是一种无需特殊开关的可扩展方法。随处受限且可访问性受限比较NVMe-oFoverRDMA、NVMe-oFoverFC和NVMe-oFoverTCP/IP，着眼于云原生应用程序的成本、基础设施考虑因素和可访问性。上表比较了NVMe-oFoverRDMA、NVMe-oFoverFC和NVMe-oFoverTCP/IP作为云原生应用程序的存储传输协议。在开销成本方面，基于FC的NVMe-oF成为三者中最昂贵的。这是因为光纤通道需要一个需要FC主机总线适配器(HBA)的专用网络。该协议还需要FC交换机。与RDMA或TCP相比，这些项目导致光纤通道的成本更高。在这三者中，基于RDMA的NVMe-oF的开销成本介于光纤通道或TCP之间。RDMA不需要专用网络，但该协议确实需要特殊的RDMA交换机。相比之下，NVMe-oFoverTCP/IP不需要自己的交换机、适配器或网络。因此，它在大多数情况下是成本最低的选择。RDMA和光纤通道速率在基础设施复杂性、易用性和可扩展性方面低于TCP。由于需要RDMA交换机，RDMA面临可扩展性限制。由于FC交换机、HBA和专用网络的要求，光纤通道同样复杂。使用单个交换机扩展单个RDMA或FC存储机架是一个复杂的过程。在这种情况下，路由限制也出现了。NVMeoverTCP相对简单。它仅在标准以太网TCP/IP网络上运行。不需要特殊的网络适配器或交换机。此外，它更具可扩展性和可路由性——可轻松扩展到多条路由和不同网络。这种差异还与存储可访问性有关。与TCP相比，云原生应用对RDMA和FC存储的访问相对较少。NVMe-oFoverTCP/IP可以在任何地方被云原生应用程序访问。用于云原生应用程序的NVMe-oF和KubernetesKubernetes是一种开源容器编排系统，可自动执行软件部署、扩展和管理。运行云原生应用程序的服务器很容易让Kubernetes运行数十或数百个微服务，这显然会影响服务器与存储资源的交互方式。许多云原生应用程序使用微服务架构，该架构可以有效地将资源分配给为特定任务设计的较小（微）服务，从而使应用程序具有灵活性并非常适合云软件架构。一些云原生应用程序是输入/输出(IO)密集型的。它们需要高带宽和低延迟，因此更加需要满足??这些要求的存储解决方案和协议。其他时候，作为应用程序一起工作的容器可能不需要高每秒I/O操作数(IOPS)和低延迟。在云端，可能有数百甚至数千个应用程序作为容器并行运行在许多物理服务器上。总之，它们对存储提出了高性能、高带宽和低延迟的要求。由Kubernetes编排的云原生应用程序具有独特的存储需求，而NVMe-oF可以满足这些需求。大多数Kubernetes应用程序都是数据密集型的，因此它们需要NVMe-oF提供的那种高性能存储。对于数据库等有状态应用程序尤其如此，这些应用程序需要低存储延迟才能满足应用程序的性能要求。如果应用程序本身要扩展，则此类应用程序的存储也必须易于扩展。当Kubernetes应用程序可以访问正确级别的资源时，它们也会表现良好。无论是计算、网络还是存储，都应该以正确的比例提供支持Kubernetes应用程序的资源。如果应用程序依赖于连接到运行Kubernetes应用程序的服务器的直连存储(DAS)，则这是不可能的。几乎可以肯定服务器的DAS未被充分利用或被过度利用。从性能或经济的角度来看，两者都不可取。在这种情况下，如果存储没有直接连接到运行Kubernetes应用程序的服务器，则可以动态、独立地扩展计算和存储。使用这种方法，Kubernetes应用程序将始终能够以正确的比例和正确的性能特征访问存储。分类存储还使Kubernetes应用程序能够从任何地方访问数据。实际上，使应用程序和存储可移植，因为Kubernetes应用程序可以在不同的服务器上运行和移动。一些架构师通过将存储放在集群中来解决这个问题，但数据必须在所有这些地方都可以访问。NVMe-oFoverTCP/IP为云原生应用程序带来的好处NVMe-oFoverTCP/IP为云原生应用程序提供了许多好处，此外还有更高的可访问性、更低的开销成本和更低的复杂性。它提供充当本地闪存存储的虚拟化和集中式存储池。通过这种方法，基于TCP/IP的NVMe-oF意味着加速的应用程序性能，以及简单高效的扩展。对于Kubernetes应用程序，正确的基于TCP/IP的NVMe-oF实施可以提供DAS的性能，但在集群存储解决方案上具有以太网网络的便利性和普遍性。以太网已经存在于每个IT环境中，使得部署便携式存储集群变得容易。结论NVMe成为云原生应用程序的最佳存储介质，满足Kubernetes应用程序和类似云原生软件的性能需求。在NVMe传输选项中，NVMe-oFoverTCP/IP为云原生工作负载提供了最佳质量组合。与RDMA或基于光纤通道的NVMe-oF相比，它能够以更低的成本和复杂性实现高性能存储。原文链接：https://dzone.com/articles/accelerate-cloud-native-applications-with-nvme原作者：CarolPlatz
