网络配置：
建议更改
PDF
在运行ONTAP的系统上使用vSphere时、配置网络设置非常简单、与其他网络配置类似。
需要考虑以下几点：
-
将存储网络流量与其他网络分开。可以通过使用专用 VLAN 或单独的存储交换机来实现单独的网络。如果存储网络共享上行链路等物理路径，您可能需要 QoS 或其他上行链路端口来确保带宽充足。除非您的解决方案指南明确要求、否则请勿将主机直接连接到存储；使用交换机提供冗余路径、并允许VMware HA在没有干预的情况下运行。
-
如果您的网络支持巨型帧、则应使用巨型帧。如果使用这些协议，请确保在存储和 ESXi 主机之间的路径中的所有网络设备， VLAN 等上对其进行相同的配置。否则，您可能会看到性能或连接问题。此外，还必须在 ESXi 虚拟交换机， VMkernel 端口以及每个 ONTAP 节点的物理端口或接口组上以相同的方式设置 MTU 。
-
NetApp仅建议在ONTAP集群中的集群互连端口上禁用网络流量控制。对于用于数据流量的其余网络端口的流量控制最佳实践、NetApp不提供任何其他建议。您应根据需要启用或禁用它。有关流量控制的更多背景信息、请参见 "TR-4182"。
-
当 ESXi 和 ONTAP 存储阵列连接到以太网存储网络时， NetApp 建议将这些系统连接到的以太网端口配置为快速生成树协议（ RSTP ）边缘端口或使用 Cisco PortFast 功能。NetApp 建议在使用 Cisco PortFast 功能且为 ESXi 服务器或 ONTAP 存储阵列启用了 802.1Q VLAN 中继的环境中启用生成树 PortFast 中继功能。
-
NetApp 建议采用以下链路聚合最佳实践：
-
使用支持在两个独立交换机机箱上对端口进行链路聚合的交换机、并采用多机箱链路聚合组方法、例如Cisco的虚拟端口通道(vPC)。
-
对连接到ESXi的交换机端口禁用LACP、除非您使用的是配置了LACP的dvSwitches 5.1或更高版本。
-
使用LACP为具有IP哈希的动态多模式接口组的ONTAP 存储系统创建链路聚合。
-
在ESXi上使用IP哈希绑定策略。
-
下表汇总了网络配置项，并指出了这些设置的应用位置。
| 项目 | ESXi | 交换机 | Node | SVM |
|---|---|---|---|---|
IP 地址 |
VMkernel |
否 |
否 |
是的。 |
链路聚合 |
虚拟交换机 |
是的。 |
是的。 |
否 * |
VLAN |
VMkernel 和 VM 端口组 |
是的。 |
是的。 |
否 * |
流量控制 |
NIC |
是的。 |
是的。 |
否 * |
生成树 |
否 |
是的。 |
否 |
否 |
MTU （适用于巨型帧） |
虚拟交换机和 VMkernel 端口（ 9000 ） |
是（设置为最大值） |
是（ 9000 ） |
否 * |
故障转移组 |
否 |
否 |
是（创建） |
是（选择） |
-
SVM LIF连接到具有VLAN、MTU和其他设置的端口、接口组或VLAN接口。但是、这些设置不会在SVM级别进行管理。
这些设备具有自己的 IP 地址进行管理，但这些地址不会在 ESXi 存储网络环境中使用。
SAN (FC、NVMe/FC、iSCSI、NVMe/TCP)、RDM
ONTAP使用传统iSCSI和光纤通道协议(Fibre Channel Protocol、FCP)以及高效率和高性能的下一代块协议基于网络结构的NVMe (NVMe-oF)为VMware vSphere提供企业级块存储、并支持NVMe/FC和NVMe/TCP。
有关在vSphere和ONTAP中为VM存储实施块协议的详细最佳实践、请参见"数据存储库和协议—SAN"
NFS
通过 vSphere ，客户可以使用企业级 NFS 阵列为 ESXi 集群中的所有节点提供对数据存储库的并发访问。如一节所述"数据存储库"、在vSphere中使用NFS具有一些易用性和存储效率可见性优势。
有关建议的最佳实践、请参见"数据存储库和协议—NFS"
直连网络
虚拟化管理员有时更愿意通过从配置中删除网络交换机来简化其基础架构。这样可以创建一个更加独立的解决方案，所需组件更少，占用的机架空间也更少。根据所使用的协议，存在一些重要限制。
光纤通道
从 ONTAP 9.19.1 开始，使用特定存储系统 FC 适配器的传统 FC-SAN (SCSI) 和 NVMe/FC 均支持直接连接 FC。HBA 将建立标准点对点 FC 连接。在 ONTAP 9.19.1 之前，ONTAP 存储系统需要 NPIV，这意味着存储系统必须连接到也支持 NPIV 的 FC 交换机。
iSCSI和NVMe/TCP
使用iSCSI或NVMe/TCP的主机可以直接连接到存储系统并正常运行。原因是路径问题。直接连接到两个不同的存储控制器会产生两条独立的数据流路径。丢失路径、端口或控制器不会阻止使用另一个路径。
NFS
可以使用直连NFS存储、但有一个重大限制—如果没有大量的脚本编写工作、故障转移将无法正常工作、这是客户的责任。
直连NFS存储的无中断故障转移之所以复杂、是因为本地操作系统上会发生路由。例如、假设主机的IP地址为192.168.1.1/24、并且直接连接到IP地址为192.168.1.50/24的ONTAP控制器。在故障转移期间、该192.168.1.50地址可以故障转移到另一个控制器、并且该地址可供主机使用、但主机如何检测到它的存在？原来的192.168.1.1地址仍然位于不再连接到操作系统的主机NIC上。发往192.168.1.50的流量将继续发送到无法运行的网络端口。
第二个 OS NIC 可以配置为 192.168.1.2，并且能够与故障转移的 192.168.1.50 地址进行通信，但本地路由表将默认使用*且仅使用一个*地址与 192.168.1.0/24 子网进行通信。系统管理员可以创建一个脚本框架，用于检测失败的网络连接，并更改本地路由表或启动和关闭接口。确切的步骤将取决于所使用的操作系统。
在实践中、NetApp客户确实使用直连NFS、但通常仅适用于故障转移期间IO暂停的工作负载。使用硬挂载时、暂停期间不应出现任何IO错误。在服务还原之前、IO应挂起、可以通过故障恢复或手动干预在主机上的NIC之间移动IP地址。