掛接選項和用戶端 VM 設定

已完成

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

注意

NFS 用戶端的最佳做法取決於所使用的應用程式。 下列建議並非絕對，可能因應用程式建議或工作負載測試而異。 強烈建議您在部署到生產環境之前，先測試這些做法。

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

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

• actimeo：控制目錄的 NFS 用戶端快取屬性。 如果您未指定，NFS 用戶端會使用 60 秒的預設最大值。
• nocto：代表 "no close-to-open"，這表示檔案可以在寫入動作完成之前關閉，以節省時間。 根據預設，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 的最佳效能。 如果您的用戶端 VM 具有大量 RAM 或較高的網路頻寬 (例如 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 掛接選項，展開網路連線 (若適用)

在 Linux 核心 5.3 或更新版本中，nconnect NFS 掛接選項已進入正式運作狀態。 若要檢查用戶端 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 用戶端作業系統類型可能有不同的方法來設定此值。 如需詳細資訊，請參閱您的作業系統文件。

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 檔案磁碟區可以在建立後設定為不同的通訊協定版本。

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

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

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

Azure NetApp 檔案會使用電池支援的 NVRAM 儲存體作為傳入 NFS 寫入的緩衝區快取。 NVRAM 中的資料會每隔 10 秒排清到磁碟，或直到緩衝區快取填滿為止 (以先到者為準)。 由於 NVRAM 受到電池的支援，因此在保留資料時，它至少可以維持 72 小時未預期的中斷，例如 Azure 資料中心斷電的罕見事件。 Azure NetApp 檔案的資料復原與使用 sync 掛接選項的效能影響組合，使得非同步處理在幾乎所有使用案例中都成為慣用的選擇。

瞭解 wsize 和 rsize 值的影響

透過 NFS 掛接時，wsize 和 rsize 值會決定每個 NFS 呼叫可傳送多少資料給 NFS 伺服器。 如果掛接選項中未指定，則值會設定為任何 NFS 伺服器已設定的内容。 Azure NetApp 檔案會針對 wsize 和 1 MB 的 rsize 使用最大移轉大小 (1048576)。 無法在 Azure NetApp 檔案中變更此值。 這表示如果 NFS 掛接未指定 wsize 和 rsize 值，則掛接預設為 1 MB。 EDA 工作負載中 NFS 掛接的建議 wsize 和 rsize 值為 256 K。

如果應用程式需要在 Azure NetApp 檔案 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)。 掛接不會停止回應，但執行中的作業可能會遺失。

將掛接指定為 hard 掛接 (例如 CTRL+C) 時，intr 掛接選項可讓 NFS 流程中斷。 當適用於資料可靠性和管理性的最佳組合時，建議您搭配 hard 掛接使用 intr。

考慮不變更 MTU

Azure VM 的預設最大傳輸單位 (MTU) 是 1500 個位元組。 不建議客戶針對 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。