掛接選項和用戶端 VM 設定

5 分鐘

在本課程模組中，我們會討論在 Azure NetApp Files 上執行 HPC 或 EDA 應用程式時，可改善效能的掛接選項和用戶端 VM 組態。

備註

NFS 用戶端的最佳做法取決於所使用的應用程式。下列建議並非絕對，可以依據應用程式的建議或工作負載測試結果進行調整。強烈建議您在生產環境中部署之前先測試這些做法。

使用 actimeo 和 nocto 掛接選項來改善效能

您可以使用下列掛接選項來改善相對靜態資料集和大量讀取案例的效能：

actimeo：控制目錄的 NFS 用戶端快取屬性。如果您未指定，NFS 用戶端會使用 60 秒的預設最大值。
nocto：代表「無需等寫入完成即可關閉」，這表示檔案可以在寫入完成之前關閉，以節省時間。根據預設， nocto 不會在NFS掛接選項中設定。這表示所有檔案都等候完成寫入，再允許關閉。

大部分的 HPC 應用程式，包括 EDA 在我們的案例中，都有相對靜態的數據集（這表示數據不會經常變更）。在此情況下，您可以使用 nocto 和 actimeo 來減少 getattr 或存取記憶體的作業，這有助於加速應用程式。

例如，我們建議為 EDA 工具和程式庫磁碟區設定 "nocto,actimeo=600"（600 秒或 10 分鐘）。因為這些檔案不會變更，所以不需要保持快取一致性。設定這些掛接選項可減少元數據呼叫，進而改善整體效能。

微調系統參數以獲得最佳效能

Tuned 是精靈，可用來監視及設定 Linux 用戶端上的連線裝置。在大部分情況下， tuned 預設會安裝。如果未安裝，則可以新增並啟用它，以使用內建預設範本簡化用戶端微調參數。

執行下列命令，以套用用戶端 VM 的基本伺服器微調和一般延遲微調：

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

下列部分或所有系統參數（/etc/sysctl.conf）在Linux用戶端 VM 上可能很有説明，以獲得最佳效能。如果您有具有大量 RAM 或更高網路頻寬的用戶端 VM，例如 InfiniBand，您可能想要設定一些甚至高於下列範例所示的值。

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

若要讓這些調整持續生效，請執行：

sudo sysctl -P

使用 nconnect 掛接選項，在適用時擴充網路連線

nconnectNFS 掛接選項在 Linux 內核 5.3 或更新版本中正式推出。若要檢查用戶端 VM 的 Linux 核心，請執行：

uname -r

的目的是 nconnect 在用戶端上為每個 TCP 連線或裝入點提供多個傳輸連線。這項技術有助於提高 NFS 掛載的並行性和效能。

用戶端數目越低，有助於提升效能的價值 nconnect 就越高，因為它可能會利用所有可用的網路頻寬。當客戶端數目增加時，其值會逐漸減少;總共只有一定數量的頻寬可以四處走動，而且 TCP 連線數目上限可以更快耗盡，這可能會導致拒絕服務，直到 TCP 連線釋出為止。

因為在產生節流之前，Azure NetApp 檔案允許每個 TCP 連線最多可以同時發出 128 個執行中要求 (其中新要求會排入佇列，直到資源可供使用)， nconnect 可協助擴充每個掛接點增加可用 TCP 連線所允許的執行中要求數目。例如，如果 nconnect 設定為使用八個 TCP 連線，則用戶端可能可以使用 1,024 （8x128）要求。

新式 Linux 用戶端允許每個連線最多 65,535 個要求（動態值）。這可能會超過 Azure NetApp 檔案磁碟區可用的執行中要求佇列，並導致不良的效能結果，其中用戶端傳送的要求多於給定時間所能滿足的要求。若要降低因此行為而造成的效能影響風險，請考慮將 sunrpc.tpc_max_slot_table_entries=256 設為較低的靜態值，或者如果您使用 512 或 nconnect=8、16 時，將它們設為較低的靜態值。請使用下表做為指引。

備註

不同的 Linux 用戶端 OS 類型可能有不同的方法來設定此值。如需詳細資訊，請參閱您的OS檔。

`nconnect` 值	建議的 TCP 最大插槽表條目
0-1	128
2-4	256
6-8	512
>8	不需要變更

備註

此選項 nconnect 僅適用於Linux核心5.3+ VM。升級核心時，您可能需要重新啟動 VM。這表示在某些情況下可能不適用。

當您只考慮效能時，請使用NFSv3 而不是 NFSv4.1

NFSv3 是無狀態通訊協定，這表示客戶端和伺服器不會與使用中的檔案彼此通訊。鎖定是由網路鎖定管理員（NLM）在通訊協定堆疊之外執行的，當鎖定變得不再有效時，這會帶來一些挑戰，且必須手動移除。鎖定只會在應用程式要求時建立，因此在某些情況下，不需要交涉鎖定。由於沒有用戶端標識碼、狀態標識碼、會話標識碼、鎖定狀態等可追蹤，因此 NFSv3 在某些工作負載中，執行效能會比 NFSv4.1 好一點，特別是在高檔案計數/高元數據工作負載中，例如 EDA 和軟體開發。

NFSv4.1 會追蹤檔案的狀態，包括鎖定。當許多檔案一次在 NFSv4.1 中使用時，每個檔案都會獲指派狀態標識碼並接收鎖定。具狀態會增加工作負載效能的額外負荷，因為 NFS 伺服器必須處理每個狀態和鎖定。在某些工作負載（例如 EDA）中，NFSv4.1 的效能可能會下降 25% 到 75%。其他工作負載，例如大型檔案、串流 IO 或資料庫在使用 NFSv4.1 時，不會看到效能降低，甚至可能受益於通訊協定所使用的複合作業。

Azure NetApp Files 同時支援 NFSv3 和 NFSv4.1。您應該透過比較 NFS 各版本的相似性和差異（以及進行測試）來驗證應用程式所需的版本，並使用適當的版本來建立磁碟區。如有必要，Azure NetApp Files 磁碟區可以在建立後設定為不同的通訊協定版本。

選擇 rsize 和 wsize 掛接選項的適當值

掛接選項 rsize （讀取大小）和 wsize （寫入大小）會決定每個已傳送封包的 NFS 用戶端與伺服器之間傳送的數據量。例如，將或 rsize 設定wsize為 65,536 表示每個封包最多可傳送 64 K 個數據。如果應用程式以較小的區塊傳送數據（例如8 K），則傳送的數據量取決於所使用的掛接選項（例如 sync）。

Azure NetApp Files 的最佳做法是將 rsize 和 wsize 設定為相同的值。我們通常會建議您在掛接選項中，將 rsize 和 wsize 值設定為 262144 (256 K)。

瞭解同步處理和異步掛接選項

如果使用 sync ，則會使用 WRITE 命令來傳送每個FILE_SYNC呼叫。這表示伺服器必須確認每個 WRITE，並認可至磁碟，才能發生下一個 WRITE。當應用程式必須保證所有資料都認可至磁碟時，會使用 Sync。 WRITE 呼叫只會傳送應用程式區塊大小所指定的數據量，這表示較小的區塊大小會產生更多NFS流量，而不論 wsize 掛接的和 rsize 值為何，都會造成效能影響。

如果您使用預設的async掛接操作，用戶端可以利用WRITE命令來透過NFS傳送多個UNSTABLE呼叫。在此案例中，資料會在逾時期間之後排清到磁碟。由於 NFS 用戶端不一定會在伺服器上等候資料認可到磁碟，然後再開始下一個 WRITE，因此寫入非同步掛接的作業完成時間會遠低於同步處理。當較小的區塊大小與較大的 rsize 和 wsize 值搭配使用時，WRITE 呼叫會傳送單一 NFS 呼叫中允許的資料量。例如，如果 8 K 區塊大小與 64 K wsize/rsize搭配使用，則每個 NFS WRITE 呼叫會傳送每個封包 8 個區塊（64 K/8 K）。當寫入排清到磁碟時，NFS 伺服器會將 FILE_SYNC 回覆傳回給 NFS 用戶端。這樣可減少透過完成作業所需的網路來電和回復總數 WRITE ，進而改善效能。

例如，在一次測試中，使用 8 K 區塊大小建立 1-GiB 檔案時，會產生 262,144 個 WRITE 呼叫和回復，並在 70 秒內完成，這是使用 sync 掛接選項的情況。使用 8 K 區塊大小建立相同的檔案，而 async 掛接選項只會傳送 16,384 個 WRITE 呼叫和回復，並在六秒內完成。

Azure NetApp Files 使用具備電池支援的 NVRAM 儲存裝置作為緩衝快取，來處理傳入的 NFS 寫入。 NVRAM 中的數據會每隔 10 秒排清到磁碟，或直到緩衝區快取填滿為止（以第一個為準）。由於 NVRAM 受到電池的保護，因此即使在遇到未預期的斷電時，例如 Azure 資料中心不太可能發生的電力中斷事故，它仍然可以在保留數據的狀態下維持至少 72 小時。 Azure NetApp 檔案的資料復原與使用 sync 掛接選項的效能影響組合，使得非同步處理在幾乎所有使用案例中都成為慣用的選擇。

瞭解 wsize 和 rsize 值的影響

透過 NFS 掛接時， wsize 和 rsize 值會決定每個 NFS 呼叫可傳送多少數據給 NFS 伺服器。如果在掛載選項中未指定，則這些值將設定為 NFS 伺服器已配置的默認值。 Azure NetApp Files 對於 wsize 和 rsize 的最大傳輸大小均為 1 MB（1048576）。無法在 Azure NetApp Files 中變更此值。這表示如果 NFS 掛接未指定 wsize 和 rsize 值，則掛接預設為 1 MB。 EDA 工作負載中 NFS 掛接的建議 wsize 和 rsize 值是 256 K。

如果應用程式需要在 Azure NetApp Files NFS 掛接上建立 1-GiB 檔案，則需要將 1048,576 KiB 寫入記憶體。數學練習可以示範效能為何會以更有效率 wsize 或 rsize 值來改善。

wsize如果設定為 64 K，則寫入 1 GiB 檔案所需的作業/封包數目會1048576/64=16384。
wsize如果設定為 256 K，則寫入 1 GiB 檔案所需的作業/封包數目會1048576/256=4096。

封包/作業較少表示網路等待時間（這會影響 RTT）對工作負載的影響較小，這在雲端部署中相當重要。不過，如果應用程式寫入小於 wsize/rsize 值的檔案，則較大的 wsize/rsize 值不會影響效能。

較大的數據區塊表示客戶端和伺服器上更多的處理週期，但大多數新式 CPU 都足以有效率地處理這些要求。

Azure NetApp Files 的最佳做法是將 rsize 和 wsize 設定為相同的值。建議您在掛接選項中將 rsize 和 wsize 值都設定為 262144 （256K）。這個設定涵蓋應用程式讀取和寫入大小值的陣列。

針對 hard、soft 和 intr 掛接選項選擇適當的設定

hard和 soft 掛接選項會指定使用 NFS 之檔案的程式是否應該採取下列其中一個動作：

如果 NFS 伺服器無法使用，請停止並等候hard伺服器重新上線。此選項會顯示為用戶端上的掛接停止回應，但可確保在網路中斷時不會遺失執行中的作業。相反地，客戶端會繼續重試要求，直到伺服器可用或應用程式逾時為止。
回報錯誤（soft）。掛接不會停止回應，但執行中的作業可能會遺失。

intr掛接選項可讓 NFS 進程在將掛接指定為hard掛接時中斷（例如 CTRL+C）。我們建議在適用的情況下，使用intr搭配hard掛載，以達到數據可靠性和易於管理性的最佳組合。

考慮不變更 MTU

Azure VM 的預設最大傳輸單位（MTU）為 1,500 個字節。不建議客戶針對 Jumbo 框架增加 VM MTU。

掛載範例

下列範例程式碼會使用 actimeo、nocto、NFSv3、nconnect、rsize、wsize、hard、intr、tcp 和預設 MTU (1500) 的上述最佳做法，掛接 Azure NetApp Files 磁碟區：

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol

備註

Async 未指定，因為 NFS 掛接預設為 async。

意見反應

此頁面對您有幫助嗎？