本文協助您了解掛接選項及用於 Azure NetApp Files 時的最佳作法。
Nconnect
使用 nconnect 掛載選項指定 NFS 用戶端與 NFS 端點之間的連線數（網路流），最多可達 16 個。 傳統上，NFS 用戶端在本身與端點之間只使用一個連線。 增加網路流程的數量會顯著提升 I/O 與吞吐量的上限。 為了找到最適合你環境的最佳設定，建議在將應用程式投入生產環境前，先測試 `nconnect` 的各種設定。 在大多數環境中，最佳結果為 nconnect=4。
為生產環境準備多節點 SAS GRID 環境時，您可能會發現執行時間持續縮短 30%，從 8 小時降到 5.5 小時：
| 掛接選項 | 工作執行時間 |
|---|---|
無 nconnect |
8 小時 |
nconnect=8 |
5.5 小時 |
這兩組測試都使用相同的 E32-8_v4 虛擬機器和 RHEL8.3，且預先讀取設定為 15 MiB。
當您使用 nconnect 時，請記住下列規則：
nconnect受 Azure NetApp Files 支援，可在所有主要 Linux 發行版本上使用，但僅限於較新的版本：Linux 發行版 NFSv3 (最低版本) NFSv4.1 (最低版本) Red Hat 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設定不會傳播到不同的儲存體端點。nconnect會被來自10.10.10.10的掛接使用，但不會被來自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掛接選項的值。 因此，它們不是條件約束。 - 使用檔案系統快取時，循序 I/O 將以
rsize和wsize掛載選項所指定的大小進行，除非檔案大小小於rsize和wsize。 - 略過檔案系統快取的作業，雖然仍然受限於
rsize和wsize掛接選項，但不如由rsize或wsize指定的最大值那麼大。 當您使用具有directio選項的工作負載產生器時，這項考量很重要。
為了獲得最佳的整體輸送量和延遲，對 Azure NetApp Files 而言，最佳做法是將 rsize 和 wsize 設定為不超過 262,144 位元組。
關閉到開啟的一致性和快取屬性計時器
NFS 使用鬆散一致性模型。 一致性是鬆散的，因為應用程式不需要每次使用時都前往共用儲存體擷取資料，否則這種情況會對應用程式效能產生巨大影響。 管理此流程有兩種機制：快取屬性計時器和 close-to-open 一致性。
如果客戶端擁有數據的完整擁有權，也就是說，不會在多個節點或系統之間共用，則保證一致性。 在此情況下，您可以停用關閉到開啟 (getattr) 一致性 (cto 為掛接選項)，並提高屬性快取管理的逾時設定 (nocto 掛接選項將計時器變更為 10m，不採用預設值 actimeo=600)，以減少對儲存體的 acregmin=3,acregmax=30,acdirmin=30,acdirmax=60 存取作業，並加快應用程式的速度。 在某些測試中，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)。 此後，直到認為快取屬性已過期為止 (屆時會重新開始循環)，可信度定義為 acregmax 指定的值 30 秒。
其他情況也可受益於一組類似的掛接選項，即使用戶端沒有完整擁有權也一樣，例如，如果用戶端以唯讀方式使用資料，並透過另一個路徑來處理資料更新。 如果應用程式使用用戶端網格，例如 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 伺服器共用其檔案系統的所見內容。 只要所有存取指定 NFS 匯出的 NFS 用戶端都使用cto，所有客戶端都會看到其中相同的檔案和目錄清單。 目錄中的檔案屬性新鮮度由屬性快取計時器控制。 換句話說，只要使用cto，每當建立檔案並存放在儲存體時，遠端用戶端立即就會看到檔案。 - 開啟檔案時，從 NFS 伺服器的觀點來看，檔案的內容保證最新。
如果有競爭條件，當計算機 2 開啟檔案時，內容尚未從 Machine 1 刷新完成，則 Machine 2 只會在開啟時接收伺服器上存在的數據。 在此情況下，計算機 2 直到到達
acreg計時器時間之前，不會從檔案擷取更多資料，而且 Machine 2 會再次從伺服器檢查其快取一致性。 仍然從機器 1 寫入檔案時，如果從機器 2 使用 tail-f，就會看到此情況。
沒有從關閉到開啟的一致性
未使用接近開啟的一致性（nocto）時，用戶端會信任其檔案和目錄目前檢視的新鮮度，直到快取屬性定時器到期為止。
檢索目錄時 (例如
ls、ls -l) 會發出一組特定 RPC (遠端程序呼叫)。 當快取定時器值已超過時acdir，用戶端只會對伺服器發出目前檔案清單的呼叫。 在此情況下，最近建立的檔案和目錄不會出現。 最近移除的檔案和目錄確實會出現。開啟檔案時，只要檔案仍在快取中，就會傳回其快取內容 (如果有)，且不會驗證其與 NFS 伺服器的一致性。