了解 Azure NetApp Files 中使用 NFS 的輔助/補充群組
NFS 對於單一 NFS 要求中可接受的最大輔助 GID (次要群組) 數目有特定限制。 AUTH_SYS/AUTH_UNIX 的最大值為 16。 AUTH_GSS (Kerberos) 的最大值為 32。 這是已知的 NFS 通訊協定限制。
Azure NetApp Files 可讓您將輔助群組數目上限增加到 1,024。 此作業的執行是從 LDAP 這類名稱服務預先擷取提出要求的使用者群組，以避免截斷 NFS 封包中的群組清單。
運作方式
擴充群組限制的選項運作方式與其他 NFS 伺服器的 -manage-gids 選項運作方式相同。 此選項會對檔案或資料夾查閱 GID 並改為傳回該值，而不是傾印使用者所屬的整個輔助 GID 清單。
mountd 的命令參考 附註：
-g or --manage-gids
Accept requests from the kernel to map user id numbers into lists of group id numbers for use in access control. An NFS request will normally except when using Kerberos or other cryptographic authentication) contains a user-id and a list of group-ids. Due to a limitation in the NFS protocol, at most 16 groups ids can be listed. If you use the -g flag, then the list of group ids received from the client will be replaced by a list of group ids determined by an appropriate lookup on the server.
提出存取要求時，封包的 RPC 部分只會傳遞 16 個 GID。
通訊協定會卸除超過限制 16 的任何 GID。 Azure NetApp Files 中的擴充 GID 只能與 LDAP 這類外部名稱服務搭配使用。
潛在的效能影響
擴充群組的效能負面影響最低，通常是低單位數百分比。 較高的中繼資料 NFS 工作負載可能會產生更大的影響，特別是在系統的快取上。 效能也會受到名稱服務伺服器的速度和工作負載所影響。 多載的名稱服務伺服器的回應速度會較慢，導致預先擷取 GID 的延遲。 為了獲得最佳結果，請使用多個名稱服務伺服器來處理大量要求。
[允許具有 LDAP 的本機使用者] 選項
使用者嘗試透過 NFS 來存取 Azure NetApp Files 磁碟區時，要求會以數值識別碼表示。 根據預設，Azure NetApp Files 支援 NFS 使用者的擴充群組成員資格 (超過標準 16 個群組的限制 1,024)。 因此，Azure NetApp Files 會嘗試在 LDAP 中查閱數值識別碼，以嘗試解析使用者的群組成員資格，而不是在 RPC 封包中傳遞群組成員資格。
因為該行為，所以如果該數值識別碼無法解析為 LDAP 中的使用者，則查閱會失敗，並拒絕存取，即使提出要求的使用者有權存取磁碟區或資料結構也是一樣。
Active Directory 連線中的允許具有 LDAP 的本機 NFS 使用者選項旨在停用擴充群組功能，以停用 NFS 要求的這些 LDAP 查閱。 其不會在 Azure NetApp Files 內提供「本機使用者建立/管理」。
如需此選項的詳細資訊 (包括其如何以 Azure NetApp Files 中的不同磁碟區安全性樣式運作)，請參閱了解 LDAP 與 Azure NetApp Files 的使用。