網路組態
建議變更
PDF
在執行 ONTAP 的系統上使用 vSphere 時、設定網路設定非常簡單、類似於其他網路組態。
以下是幾點需要考量的事項：
-
將儲存網路流量與其他網路區隔。使用專屬的VLAN或獨立的交換器來儲存、即可建立獨立的網路。如果儲存網路共用實體路徑（例如上行鏈路）、您可能需要QoS或額外的上行鏈路連接埠、以確保有足夠的頻寬。除非您的解決方案指南特別要求，否則請勿將主機直接連線至儲存設備；使用交換器來建立備援路徑，讓 VMware HA 在不需介入的情況下運作。
-
如果您的網路支援巨型框架，則應該使用巨型框架。如果使用、請確定在儲存設備和ESXi主機之間的路徑中、所有網路裝置、VLAN等上的設定都相同。否則、您可能會看到效能或連線問題。MTU也必須在ESXi虛擬交換器、VMkernel連接埠、以及每ONTAP 個節點的實體連接埠或介面群組上設定相同。
-
NetApp 僅建議停用 ONTAP 叢集內叢集互連連接埠上的網路流程控制。NetApp 對於用於資料流量的其餘網路連接埠的流量控制最佳實務做法，並無其他建議。您應該視需要啟用或停用它。如需流程控制的更多背景資訊、請參閱 "TR-4182"。
-
當ESXi和ONTAP VMware ESXi儲存陣列連接至乙太網路儲存網路時、NetApp建議將這些系統連接的乙太網路連接埠設定為快速擴充樹狀傳輸協定（RSTP）邊緣連接埠、或使用Cisco PortFast功能。NetApp建議在使用Cisco PortFast功能的環境中、啟用跨距樹狀結構PortFast主幹功能、並在ESXi伺服器或ONTAP VMware®儲存陣列上啟用802.1Q VLAN主幹連線。
-
NetApp建議下列連結集合最佳實務做法：
-
使用交換器、透過 Cisco 的 Virtual PortChannel （ VPC ）等多機箱連結集合群組方法、在兩個獨立的交換器機箱上支援連接埠的連結集合。
-
除非您使用已設定LACP的DVSwitches 5.1或更新版本、否則請停用連接至ESXi的交換器連接埠LACP。
-
使用LACP建立鏈路集合體、以動態ONTAP 多重模式介面群組搭配IP雜湊、以利支援靜態儲存系統。
-
在ESXi上使用IP雜湊群組原則。
-
下表提供網路組態項目的摘要、並指出套用設定的位置。
| 項目 | ESXi | 交換器 | 節點 | SVM |
|---|---|---|---|---|
IP 位址 |
VMkernel |
否* |
否* |
是的 |
連結集合體 |
虛擬交換器 |
是的 |
是的 |
否* |
VLAN |
VMkernel和VM連接埠群組 |
是的 |
是的 |
否* |
流程控制 |
NIC |
是的 |
是的 |
否* |
跨距樹狀結構 |
否 |
是的 |
否 |
否 |
MTU（用於巨型框架） |
虛擬交換器與VMkernel連接埠（9000） |
是（設為上限） |
有（9000） |
否* |
容錯移轉群組 |
否 |
否 |
是（建立） |
是（選取） |
-
SVM lifs連接到具有VLAN、MTU及其他設定的連接埠、介面群組或VLAN介面。不過、這些設定不會在SVM層級進行管理。
這些裝置擁有自己的IP位址進行管理、但這些位址並未用於ESXi儲存網路環境。
SAN （ FC ， NVMe / FC ， iSCSI ， NVMe / TCP ）， RDM
ONTAP 使用傳統的 iSCSI 和光纖通道傳輸協定（ FCP ）為 VMware vSphere 提供企業級的區塊儲存設備，並支援 NVMe / FC 和 NVMe / TCP ，提供高效率和高效能的次世代區塊傳輸協定 NVMe over Fabrics （ NVMe of ）。
如需使用 vSphere 和 ONTAP 實作 VM 儲存區塊傳輸協定的詳細最佳實務做法，請參閱"資料存放區和傳輸協定 - SAN"
NFS
vSphere可讓客戶使用企業級NFS陣列、同時存取ESXi叢集中所有節點的資料存放區。如一節所述"資料存放區"，在搭配 vSphere 使用 NFS 時，有一些易用性和儲存效率可見度的優點。
如需建議的最佳實務做法，請參閱"資料存放區和傳輸協定 - NFS"
直接連線網路
儲存管理員有時偏好從組態中移除網路交換器、以簡化其基礎架構。在某些情況下可能會支援這項功能。不過，有一些限制和注意事項需要注意。
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.5 的流量將繼續傳送至無法運作的網路連接埠。
第二個 OS NIC 可設定為 19 可以與故障的 over 192.168.1.50 位址進行通訊、但本機路由表預設會使用一個 * 且只有一個 * 位址來與 192.168.1.0/24 子網路通訊。系統管理員可以建立指令碼架構、以偵測失敗的網路連線、並變更本機路由表或使介面正常運作。具體程序取決於所使用的作業系統。
實際上、 NetApp 客戶確實有直接連線的 NFS 、但通常僅適用於容錯移轉期間 IO 暫停的工作負載。使用硬掛載時、在這類暫停期間不應有任何 IO 錯誤。IO 應該會凍結，直到服務還原為止，無論是透過容錯回復或手動介入，在主機上的 NIC 之間移動 IP 位址。
FC Direct Connect
無法使用 FC 傳輸協定將主機直接連接至 ONTAP 儲存系統。原因是使用 NPIV 。用於識別 FC 網路的 ONTAP FC 連接埠的 WWN 使用稱為 NPIV 的虛擬化類型。任何連接至 ONTAP 系統的裝置都必須能夠辨識 NPIV WWN 。目前沒有任何 HBA 廠商提供可安裝在能夠支援 NPIV 目標的主機上的 HBA 。