排查 NAS 配置和 NFS 存储目标的问题

项目
08/07/2024

本文针对一些常见配置错误，以及其他可能导致 Azure HPC 缓存无法将 NFS 存储系统添加为存储目标的问题提供解决方法。

本文详细说明了如何检查端口，以及如何启用所需的对 NAS 系统的访问权限。此外，其中还包含了有关可能导致 NFS 存储目标创建失败的不常见问题的详细信息。

提示

提供足够的连接线程

大型 HPC 缓存系统向一个存储目标发出多个连接请求。例如，如果存储目标使用 Ubuntu Linux nfs-kernel-server 模块，则默认的 NFS 守护程序线程数可以低至 8 个。将线程数增加到 128 或 256，这是支持中型或大型 HPC 缓存更合理的数量。

可以使用 /etc/init.d/nfs-kernel-server 中的 RPCNFSDCOUNT 值来检查或设置 Ubuntu 中的线程数。

检查端口设置

Azure HPC 缓存需要对后端 NAS 存储系统上的多个 UDP/TCP 端口拥有读/写访问权限。请确保 NAS 系统上的这些端口可访问，并且允许流量通过存储系统与缓存子网之间的任何防火墙进入这些端口。可能需要与数据中心的防火墙和网络管理员协作来验证此配置。

不同的供应商对存储系统使用的端口各不相同，因此在设置存储目标时请检查系统要求。

一般情况下，缓存需要访问以下端口：

协议	端口	服务
TCP/UDP	111	rpcbind
TCP/UDP	2049	NFS
TCP/UDP	4045	nlockmgr
TCP/UDP	4046	mountd
TCP/UDP	4047	状态

若要了解系统所需的具体端口，请使用以下 rpcinfo 命令。下面的这个命令列出了端口并在表格中对相关结果进行了格式设置。（请使用你的系统 IP 地址替代 <storage_IP> 占位符。）

可以从装有 NFS 基础结构的任何 Linux 客户端发出此命令。如果在群集子网内部使用客户端，该客户端也可以帮助验证子网与存储系统之间的连接。

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

确保 rpcinfo 查询返回的所有端口允许来自 Azure HPC 缓存子网的无限制流量。

在 NAS 本身中以及存储系统与缓存子网之间的任何防火墙中检查这些设置。

检查 Root Squash 设置

如果 Root Squash 设置配置不当，可能会中断文件访问。应检查对每个存储导出和匹配 HPC 缓存客户端访问策略的设置是否合适。

Root Squash 可防止客户端上本地超级用户根发送的请求被作为根发送到后端存储系统。它会将请求从根重新分配给非特权用户 ID (UID)，例如“nobody”。

提示

之前版本的 Azure HPC 缓存要求 NAS 存储系统允许从 HPC 缓存执行根访问。现在，无需允许“存储目标导出”的根访问权限，除非希望 HPC 缓存客户端对导出具有根访问权限。

可以在 HPC 缓存系统中的以下位置配置 Root Squash：

在 Azure HPC 缓存 - 使用客户端访问策略为匹配特定筛选规则的客户端配置 Root Squash。客户端访问策略是每个 NFS 存储目标命名空间路径的一部分。

默认客户端访问策略不会 squash 根。
在存储导出中 - 可以将存储系统配置为将传入请求从根重新分配给非特权用户 ID (UID)。

如果存储系统导出会将根 squash，则应更新 HPC 缓存客户端访问规则，以便该存储目标也将根 squash。否则，尝试通过 HPC 缓存读取或写入后端存储系统时，可能会遇到访问问题。

下表说明了当客户端请求作为 UID 0（根）发送时，针对不同根 squash 方案的行为。不建议采用有 * 标记的方案，因为可能会出现访问问题。

设置	从客户端发送的 UID	从 HPC 缓存发送的 UID	后端存储上的有效 UID
无根 Squash	0（根）	0（根）	0（根）
仅 HPC 缓存执行根 Squash	0（根）	65534 (nobody)	65534 (nobody)
*仅 NAS 存储执行根 Squash	0（根）	0（根）	65534 (nobody)
HPC 缓存和 NAS 执行根 Squash	0（根）	65534 (nobody)	65534 (nobody)

（UID 65534 就是一个例子；在客户端访问策略中启用根 Squash 时，可以自定义 UID。）

检查目录路径上的访问权限

对于导出分层目录的 NAS 系统，请检查 Azure HPC 缓存是否对所使用的文件的路径中的每个导出级别具有适当的访问权限。

例如，某个系统可能显示如下所示的三个导出：

/ifs
/ifs/accounting
/ifs/accounting/payroll

导出 /ifs/accounting/payroll 是 /ifs/accounting 的子级，而 /ifs/accounting 本身是 /ifs 的子级。

如果你添加 payroll 导出作为 HPC 缓存存储目标，则缓存实际上会装载 /ifs/ 并从中访问 payroll 目录。因此，Azure HPC 缓存需要对 /ifs 拥有足够的访问权限才能访问 /ifs/accounting/payroll 导出。

此要求与缓存对文件编制索引的方式有关，使用存储系统提供的文件句柄来避免文件冲突。

如果文件是从不同的导出检索的，则包含分层导出的 NAS 系统可为同一文件提供不同的文件句柄。例如，某个客户端可能会装载 /ifs/accounting 并访问文件 payroll/2011.txt。而另一客户端会装载 /ifs/accounting/payroll 并访问该文件 2011.txt。根据存储系统分配文件句柄的方式，这两个客户端可能会收到具有不同文件句柄（一个用于 <mount2>/payroll/2011.txt，一个用于 <mount3>/2011.txt）的同一个文件。

后端存储系统保留文件句柄的内部别名，但 Azure HPC 缓存无法判断其索引中的哪些文件句柄引用了同一个项。因此，缓存中可能会为同一个文件缓存不同的写入内容，并错误地应用更改，因为它不知道这两个文件是相同的。

为了避免多个导出中的文件发生这种潜在的文件冲突，Azure HPC 缓存会自动装载路径中最浅级别的可用导出（在本示例中为 /ifs），并使用该导出提供的文件句柄。如果多个导出使用同一基路径，则 Azure HPC 缓存需要对该路径拥有访问权限。

调整 VPN 数据包大小限制

如果在缓存与 NAS 设备之间使用 VPN，VPN 可能会阻止完整大小为 1500 字节的以太网数据包。如果 NAS 与 Azure HPC 缓存实例之间的较大数据交换无法完成，而较小的更新可按预期方式传输，则可能表示出现了此问题。

除非你知道 VPN 配置的详细信息，否则不容易判断系统是否出现了此问题。下面是可以帮助你检查此问题的几种方法。

在 VPN 两端使用数据包探查器来检测哪些数据包可成功传输。
如果 VPN 允许执行 ping 命令，则你可以发送一个完整大小的数据包进行测试。

结合以下选项通过 VPN 对 NAS 运行 ping 命令。（请使用你的存储系统 IP 地址替代 <storage_IP> 值。）
```
ping -M do -s 1472 -c 1 <storage_IP>
```
命令中的选项如下：
- -M do - 不分段
- -c 1 - 仅发送一个数据包
- -s 1472 - 将有效负载的大小设置为 1472 字节。这是在考虑到以太网开销后一个 1500 字节数据包的最大有效负载。
成功响应如下所示：
```
PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms
```
如果发送 1472 字节后 ping 失败，则可能表示存在数据包大小问题。

若要解决该问题，可能需要在 VPN 中配置 MSS 钳制，使远程系统能够正确检测最大帧大小。有关详细信息，请参阅 VPN 网关 IPsec/IKE 参数文档。

在某些情况下，将 Azure HPC 缓存的 MTU 设置更改为 1400 可能会有帮助。但是，如果限制缓存中的 MTU，还必须限制与缓存交互的客户端和后端存储系统的 MTU 设置。有关详细信息，请参阅配置其他 Azure HPC 缓存设置。

检查 ACL 安全样式

某些 NAS 系统使用结合了访问控制列表 (ACL) 和传统 POSIX 或 UNIX 安全性的混合安全样式。

如果系统报告其安全样式为 UNIX 或 POSIX，但不包括首字母缩写词“ACL”，则此问题不会影响到你。

对于使用 ACL 的系统，Azure HPC 缓存需要跟踪其他特定于用户的值才能控制文件访问。这是通过启用一个访问缓存来实现的。没有任何面向用户的控件可用于启用访问缓存，但你可以开具支持票证，请求为缓存系统上的受影响存储目标启用访问缓存。

通过