適用於 Azure NetApp Files 的 Linux NFS 掛接選項最佳做法
本文協助您了解掛接選項及用於 Azure NetApp Files 時的最佳作法。
Nconnect
使用 nconnect 掛接選項可讓您指定在 NFS 用戶端與 NFS 端點之間應該建立的連線 (網路流程) 數目，上限為 16。 傳統上，NFS 用戶端在本身與端點之間只使用一個連線。 增加網路流程數目會大幅增加 I/O 和輸送量的上限。 經測試，已發現 nconnect=8 的效能最高。
為生產環境準備多節點 SAS GRID 環境時，您可能會發現執行時間持續縮短 30%，從 8 小時降到 5.5 小時：
| 掛接選項 | 工作執行時間 |
|---|---|
無 nconnect |
8 小時 |
nconnect=8 |
5.5 小時 |
這兩組測試都使用相同的 E32-8_v4 虛擬機器和 RHEL8.3，且預先讀取設定為 15 MiB。
當您使用 nconnect 時，請記住下列規則：
在所有主要 Linux 發行版本上 (但僅限於較新版本)，Azure NetApp Files 支援
nconnect：Linux 版本 NFSv3 (最低版本) NFSv4.1 (最低版本) Redhat Enterprise Linux RHEL8.3 RHEL8.3 SUSE SLES12SP4 或 SLES15SP1 SLES15SP2 Ubuntu Ubuntu18.04 注意
就 NFSv4.1 而言，SLES15SP2 是 Azure NetApp Files 支援
nconnect的最低 SUSE 版本。 所有其他指定的版本都是最先引進nconnect功能的版本。來自單一端點的所有掛接都會繼承
nconnect第一個已掛接導出的設定，如下列案例所示：案例 1：第一次掛接使用
nconnect。 因此，針對相同端點的所有掛接都使用nconnect=8。mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8mount 10.10.10.10:/volume2 /mnt/volume2mount 10.10.10.10:/volume3 /mnt/volume3
案例 2：
nconnect第一次掛接不會使用。 因此，針對相同端點的掛接都不使用nconnect，即使後來指定nconnect也一樣。mount 10.10.10.10:/volume1 /mnt/volume1mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8
案例 3：
nconnect設定不會傳播到不同的記憶體端點。 來自10.10.10.10的掛接使用nconnect，但來自10.12.12.12的掛接不使用。mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8mount 10.12.12.12:/volume2 /mnt/volume2
nconnect可用來增加來自任何特定用戶端的儲存體並行。
如需詳細資訊，請參閱 Azure NetApp Files 的 Linux 並行最佳做法。
Nconnect 考量
不建議同時使用 nconnect 和 sec=krb5* 掛接選項。 已發現這兩個選項並用時效能會降低。
一般安全性標準應用程式開發介面 (GSS-API) 有辦法讓應用程式保護傳送至對等應用程式的資料。 此資料可能從一部機器上的用戶端傳送到另一部機器上的伺服器。
在 Linux 中使用 nconnect 時，特定伺服器的所有 nconnect 連線之間會共用 GSS 安全性內容。 TCP 是可靠的傳輸，支援失序的封包傳遞，可使用一段滑動時間範圍的序號來處理 GSS 串流中失序的封包。 收到不在序列時間範圍內的封包時會捨棄安全性內容，並議定新的安全性內容。 在現已捨棄的內容中傳送的所有訊息都不再有效，因此需要再次傳送訊息。 如果 nconnect 設定中有大量封包，則會造成封包經常超出時間範圍，而引起上述行為。 無法具體指出此行為造成的惡化比例。
Rsize 和 Wsize
本節的範例提供如何微調效能的相關資訊。 您可能需要進行調整，以符合您的特定應用程式需求。
rsize 和 wsize 旗標設定 NFS 作業的傳輸大小上限。 如果 rsize 或 wsize 未在掛接上指定，客戶端和伺服器會交涉兩者所支援的大小上限。 目前，Azure NetApp Files 和新式 Linux 發行版本支援的讀取和寫入大小高達 1,048,576 位元組 (1 MiB)。 不過，為了獲得最佳的整體輸送量和延遲，Azure NetApp Files 建議 rsize 和 wsize 設定都不超過 262,144 位元組 (256 K)。 使用大於 256 KiB 的 rsize 和 wsize 時，您可能會發現延遲增加和輸送量減少。
例如，在 SUSE Linux Enterprise Server 上使用 Azure NetApp Files 於 Azure VM 上部署 SAP Hana 向外延展系統和待命節點顯示 256-KiB rsize 和 wsize 最大值，如下所示：
sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.4:/HN1-shared/shared /hana/shared nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
例如，SAS Viya 建議 256-KiB 讀取和寫入大小，而 SAS GRID 將 r/wsize 限制為 64 KiB，但加強預先讀取 NFS 掛接來提高讀取效能。 如需詳細資訊，請參閱 Azure NetApp Files 的 NFS 預先讀取最佳做法。
使用 rsize 和 wsize 時有下列考量：
- 隨機 I/O 作業大小通常小於
rsize和wsize掛接選項。 因此，它們不是條件約束。 - 使用檔案系統快取時，除非檔案小於
rsize和wsize，否則會對rsize和wsize指定的大小進行循序 I/O。 - 略過文件系統快取的作業，雖然仍然受限於
rsize和wsize掛接選項，但不會像 或wsize所rsize指定的最大值一樣大。 當您使用具有directio選項的工作負載產生器時，這項考量很重要。
為了獲得最佳的整體輸送量和延遲，Azure NetApp Files 的最佳做法是 rsize 和 wsize 設定不超過 262,144 位元組。
關閉到開啟一致性和快取屬性計時器
NFS 使用鬆散一致性模型。 一致性是鬆散的，因為應用程式不需要每次都移至共用記憶體並擷取數據，這種情況會對應用程式效能產生巨大影響。 管理此程序有兩種機制：快取屬性計時器和關閉到開啟一致性。
如果客戶端擁有數據的完整擁有權，也就是說，不會在多個節點或系統之間共用，則保證一致性。 在此情況下，您可以停用關閉到開啟 (cto) 一致性 (nocto 為掛接選項)，並啟用屬性快取管理的逾時 (actimeo=600 掛接選項將計時器變更為 10m，不採用預設值 acregmin=3,acregmax=30,acdirmin=30,acdirmax=60)，以減少對儲存體的 getattr 存取作業，並加快應用程式的速度。 在某些測試中，nocto 大約會減少 65-70% 的 getattr 存取呼叫，而調整 actimeo 可將這些呼叫再減少 20-25%。
屬性快取計時器的運作方式
屬性 acregmin、acregmax、acdirmin 和 acdirmax 控制快取的一致性。 前兩個屬性控制檔案的屬性可信任多久。 後兩個屬性控制目錄檔案本身的屬性可信任多久 (目錄大小、目錄擁有權、目錄權限)。 min 和 max 屬性定義目錄屬性、檔案屬性及檔案快取內容分別值得信任的最短和最長時間。 min 和 max 之間使用演算法來定義快取項目可信任多久。
以 acregmin 和 acregmax 預設值為例，分別為 3 和 30 秒。 例如，針對目錄中的檔案來反覆評估這些屬性。 3 秒之後會向 NFS 服務查詢時效性。 如果認為屬性有效，用戶端會將信任時間加倍為 6 秒、12 秒、24 秒，最長 30 秒 (因為最大值設定為 30)。 此後，直到認為快取屬性過期為止 (屆時會重新開始循環)，信任就定義為 30 秒 (acregmax 指定的值)。
其他情況也可受益於一組類似的掛接選項，即使用戶端沒有完整擁有權也一樣，例如，如果用戶端以唯讀方式使用資料，並透過另一個路徑來處理資料更新。 如果應用程式使用各種用戶端，例如 EDA、虛擬主機和電影繪製，且具有相當靜態的資料集 (EDA 工具或程式庫、Web 內容、紋理資料)，則通常會在用戶端快取大部分的資料集。 很少讀取，沒有寫入。 有許多 getattr/access 呼叫會返回記憶體。 通常透過另一個裝載檔案系統並定期推送內容更新的用戶端來更新這些資料集。
在這些情況下，已知挑選新內容時會延遲，而應用程式仍使用可能過期的資料。 在這些情況下，可使用 nocto 和 actimeo 來控制可處理過期資料的期間。 例如，在 EDA 工具和程式庫中，因為通常不常更新此資料，actimeo=600 很適合。 對於小型虛擬主機，由於用戶端在編輯網站時需要及時看到資料更新，actimeo=10 可能合理。 對於大型網站，由於內容推送至多個檔案系統，actimeo=60 可能合理。
在這些情況下，使用這些掛接選項可大幅減少儲存體的工作負載。 (例如，最近的 EDA 體驗將工具磁碟區的 IOPs 從 >150 K 減少到大約 6 K。)應用程式可大幅加快執行速度，因為可信任記憶體中的資料。 (記憶體存取時間是奈秒，而不是 getattr/存取在快速網路上的數百微秒。)
關閉到開啟一致性
不論快取的狀態為何，關閉到開啟一致性 (cto 掛接選項) 可確保開啟檔案時，應用程式一定會看到最新資料。
- 搜耙目錄時 (例如
ls、ls -l) 會發出一組特定 RPC (遠端程序呼叫)。 NFS 伺服器共用其檔案系統的檢視。 只要cto存取指定NFS匯出的所有NFS用戶端都會使用，所有客戶端都會看到相同的檔案和目錄清單。 目錄中的檔案屬性由屬性快取計時器控制時效性。 換句話說，只要使用cto，每當建立檔案並存放在儲存體時，遠端用戶端立即就會看到檔案。 - 開啟檔案時，從 NFS 伺服器的觀點來看，檔案的內容保證最新。
如果有競爭條件，當計算機 2 開啟檔案時，內容尚未從計算機 1 清除，則 Machine 2 只會在開啟時接收伺服器上存在的數據。 在此情況下，計算機 2 不會在到達定時器之前
acreg從檔案擷取更多數據，而且 Machine 2 會再次檢查其快取一致性。 仍然從機器 1 寫入檔案時，如果從機器 2 使用尾端-f，就會看到此情況。
沒有關閉到開啟一致性
未使用接近開啟的一致性 （nocto） 時，用戶端會信任其檔案和目錄目前檢視的新鮮度，直到快取屬性定時器遭到入侵為止。
搜耙目錄時 (例如
ls、ls -l) 會發出一組特定 RPC (遠端程序呼叫)。 當快取定時器值遭到入侵時acdir，用戶端只會對伺服器發出目前檔案清單的呼叫。 在此情況下，最近建立的檔案和目錄不會出現。 最近移除的檔案和目錄隨即出現。開啟檔案時，只要檔案仍在快取中，就會傳回其快取內容 (如果有)，而不會向 NFS 伺服器驗證一致性。