你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
了解 Azure NetApp 文档 中使用 NFS 的辅助/补充组
对于单个 NFS 请求中可以遵循的最大辅助 GID 数（辅助组），NFS 具有特定的限制。 AUTH_SYS/AUTH_UNIX的最大值为 16。 对于AUTH_GSS（Kerberos），最大值为 32。 这是 NFS 的已知协议限制。
Azure NetApp 文档提供将辅助组的最大数目增加到 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 文档中的扩展 GID 只能与外部名称服务（如 LDAP）一起使用。
潜在的性能影响
扩展组的性能损失最小，通常为低位数百分比。 较高的元数据 NFS 工作负荷可能会产生更大的影响，尤其是在系统的缓存上。 性能也可能受到名称服务服务器的速度和工作负荷的影响。 重载的名称服务服务器响应速度较慢，导致预提取 GID 时出现延迟。 为了获得最佳结果，请使用多个名称服务服务器来处理大量请求。
“允许具有 LDAP 的本地用户”选项
当用户尝试通过 NFS 访问Azure NetApp 文档卷时，请求将采用数字 ID。 默认情况下，Azure NetApp 文档支持 NFS 用户的扩展组成员身份（超出标准 16 组限制为 1,024）。 因此，Azure NetApp 文件会尝试在 LDAP 中查找数字 ID，以解析用户的组成员身份，而不是在 RPC 数据包中传递组成员身份。
由于该行为，如果无法将数字 ID 解析为 LDAP 中的用户，则即使请求用户有权访问卷或数据结构，查找也会失败并拒绝访问。
Active Directory 连接中具有 LDAP 选项的“允许本地 NFS 用户”旨在通过禁用扩展组功能来禁用这些 NFS 请求的 LDAP 查找。 它不提供Azure NetApp 文档中的“本地用户创建/管理”。
有关该选项的详细信息，包括它在 Azure NetApp 文件中不同卷安全样式的行为方式，请参阅了解 LDAP 与Azure NetApp 文档的使用。