Azure NetApp Files 的 Linux NFS 掛接選項最佳做法
本文可協助您瞭解掛接選項，以及搭配 Azure NetApp Files 使用這些選項的最佳做法。
Nconnect
nconnect使用掛接選項可讓您指定應該在 NFS 用戶端與 NFS 端點之間建立的連線數目，限制為 16。 傳統上，NFS 用戶端會使用本身與端點之間的單一連線。 藉由增加網路流量數目，I/O 和輸送量的上限會大幅增加。 測試發現 nconnect=8 是效能最高的測試。
為生產環境準備多節點 SAS GRID 環境時，您可能會注意到執行時間從 8 小時減少到 5.5 小時可重複的 30% ：
| 掛接選項 | 作業執行時間 |
|---|---|
不 nconnect |
8 小時 |
nconnect=8 |
5.5 小時 |
這兩組測試都使用相同的 E32-8_v4 虛擬機器和 RHEL8.3，並預先設定為 15 MiB。
當您使用 nconnect 時，請記住下列規則：
nconnect所有主要 Linux 發行版本上的 Azure NetApp Files 都支援，但僅限於較新版本：Linux 版本 NFSv3 （最低版本） NFSv4.1 （最低版本） Redhat Enterprise Linux RHEL8.3 RHEL8.3 SUSE SLES12SP4或SLES15SP1 SLES15SP2 Ubuntu Ubuntu18.04 注意
SLES15SP2是 Azure NetApp Files for NFSv4.1 支援的最小 SUSE 版本
nconnect。 如指定的其他所有版本都是引進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 ，GSS 安全性內容會在與特定伺服器的所有 nconnect 連線之間共用。 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）。 您可能會發現使用 rsize 和 大於 256 KiB 時，延遲增加和 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 讀取前最佳做法。
下列考慮適用于 和 wsize 的使用 rsize ：
- 隨機 I/O 作業大小通常小於
rsize和wsize掛接選項。 因此，實際上，它們不會受到限制。 - 使用檔案系統快取時，除非檔案大小小於
rsize和wsize，否則會以 和wsize掛接選項所述rsize的大小發生循序 I/O。 - 略過檔案系統快取的作業，雖然仍然受到
rsize和wsize掛接選項的限制，但不一定會發出與 或wsize所rsize指定的最大值一樣大的問題。 當您使用具有 選項的directio工作負載產生器時，此考慮很重要。
Azure NetApp Files 的最佳作法是最佳整體輸送量和延遲，請設定 rsize 且 wsize 不超過 262,144 個位元組。
近距離開啟的一致性和快取屬性計時器
NFS 使用鬆散的一致性模型。 一致性是鬆散的，因為應用程式不需要移至共用儲存體並擷取每次使用它的資料，這種情況會對應用程式效能產生巨大影響。 有兩種機制可管理此程式：快取屬性計時器和接近開啟的一致性。
如果用戶端擁有資料的完整擁有權，也就是說，它不會在多個節點或系統之間共用，則保證一致性。 在此情況下，您可以關閉關閉接近開啟的 （ cto ） 一致性來 nocto 加速 getattr 應用程式的存取作業，以及開啟屬性快取管理的逾時（ actimeo=600 因為掛接選項會將計時器變更為 10m 與預設值 acregmin=3,acregmax=30,acdirmin=30,acdirmax=60 ）。 在某些測試中， nocto 減少大約 65-70% 的 getattr 存取呼叫，而調整 actimeo 會減少這些呼叫的另一個 20-25%。
屬性快取計時器的運作方式
屬性 acregmin 、 acregmax 、 acdirmin 和 acdirmax 控制快取的一致性。 前兩個屬性可控制信任檔案屬性的時間長度。 後兩個屬性可控制信任目錄檔案本身的屬性長度（目錄大小、目錄擁有權、目錄許可權）。 min和 max 屬性會定義目錄屬性、檔案屬性以及檔案快取內容分別視為可信任的最小和最大持續時間。 在 和 max 之間 min ，演算法可用來定義信任快取專案的時間量。
例如，分別考慮預設值 acregmin 和 acregmax 值 3 和 30 秒。 例如，會針對目錄中的檔案重複評估屬性。 3 秒之後，會查詢 NFS 服務以取得新鮮度。 如果屬性視為有效，用戶端會將信任的時間加倍為 6 秒、12 秒、24 秒，則最大值設定為 30、30 秒。 從該時間點開始，直到快取屬性視為過期為止（迴圈開始于此時間點），信任性定義為 30 秒，是 所 acregmax 指定的值。
在某些情況下，即使用戶端沒有完整的擁有權，如果用戶端使用資料做為唯讀，而且資料更新是透過另一個路徑進行管理，也有其他情況可以從類似的掛接選項中獲益。 對於使用 EDA、Web 裝載和電影轉譯等用戶端方格的應用程式，且具有相對靜態的資料集（EDA 工具或程式庫、Web 內容、紋理資料），一般行為是資料集基本上會快取于用戶端上。 讀取很少，沒有寫入。 將有許多 getattr /access 呼叫返回儲存體。 這些資料集通常會透過掛接檔案系統的另一個用戶端更新，並定期推送內容更新。
在這些情況下，挑選新內容有已知的延遲，而應用程式仍可搭配可能過時的資料運作。 在這些情況下， nocto 和 actimeo 可用來控制可管理過期日期的期間。 例如，在 EDA 工具和程式庫中，運作良好， actimeo=600 因為此資料通常不常更新。 對於用戶端在編輯其網站時需要及時查看其資料更新的小型 Web 主機， actimeo=10 可能可以接受。 對於將內容推送至多個檔案系統的大型網站， actimeo=60 可能可以接受。
在這些情況下，使用這些掛接選項可大幅減少工作負載至儲存體。 （例如，最近的 EDA 體驗會將 IOPS 縮減為工具磁片區，從 > 150 K 減少到 ~6 K。應用程式可以大幅加快執行速度，因為它們可以信任記憶體中的資料。 （記憶體存取時間是 nanoseconds，與快速網路上 /access 的數百微秒 getattr 。
接近開啟的一致性
近距離開啟一致性 （ cto 掛接選項） 可確保無論快取的狀態為何，開啟檔案的最新資料一律會呈現給應用程式。
- 編目目錄時（
lsls -l例如）發出一組特定 RPC（遠端程序呼叫）。
NFS 伺服器會共用其檔案系統檢視。 只要cto存取指定 NFS 匯出的所有 NFS 用戶端都使用，所有用戶端都會看到相同的檔案和目錄清單。 目錄中檔案屬性的新鮮度是由 屬性快取計時器 所控制。 換句話說，只要cto使用檔案，檔案就會在建立檔案且檔案降落在儲存體上時，就會出現在遠端用戶端上。 - 開啟檔案時，從 NFS 伺服器的觀點來看，保證檔案的內容是全新的。
如果當電腦 2 開啟檔案時，內容尚未完成從電腦 1 排清的競爭條件，則 Machine 2 只會在開啟時接收伺服器上存在的資料。 在此情況下，電腦 2 在到達計時器之前acreg，不會從檔案擷取更多資料，而且電腦 2 會再次檢查其快取一致性。 當檔案仍在從電腦 1 寫入時，可以使用 Machine 2 的尾端-f來觀察此案例。
沒有接近開啟的一致性
未使用接近開啟的一致性 （ nocto ） 時，用戶端會信任其檔案和目錄目前檢視的新鮮度，直到快取屬性計時器遭到入侵為止。
編目目錄時（
lsls -l例如）發出一組特定 RPC（遠端程序呼叫）。
用戶端只會在快取計時器值遭到入侵時acdir，發出目前檔案清單的伺服器呼叫。 在此情況下，最近建立的檔案和目錄不會出現，而且最近移除的檔案和目錄仍會出現。開啟檔案時，只要檔案仍在快取中，就會傳回其快取內容（如果有的話），而不會驗證與 NFS 伺服器的一致性。