Amazon EFS 故障排查:一般问题 - Amazon Elastic File System
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Amazon EFS 故障排查:一般问题

使用该信息解决一般 Amazon EFS 问题。有关性能的信息,请参阅 Amazon EFS 性能

通常,如果您遇到难以解决的 Amazon EFS 问题,请确认您使用的是最新 Linux 内核。如果使用的是企业 Linux 发行版,我们建议您使用以下版本:

  • 内核版本为 4.3 或更高版本的 Amazon Linux 2

  • Amazon Linux 2015.09 或更高版本

  • RHEL 7.3 或更高版本

  • 所有 Ubuntu 16.04 版本

  • 具有内核 3.13.0-83 或更高版本的 Ubuntu 14.04

  • SLES 12 Sp2 或更高版本

如果使用其他发行版或自定义内核,我们建议您使用内核 4.3 或更高版本。

注意

由于并行打开多个文件时,性能不佳,RHEL 6.9 可能对于特定工作负载不够理想。

无法创建 EFS 文件系统

创建 EFS 文件系统的请求失败,并显示以下消息:

User: arn:aws:iam::111122223333:user/username is not authorized to perform: elasticfilesystem:CreateFileSystem on the specified resource.
要采取的操作

检查您的 Amazon Identity and Access Management (IAM) 策略,确认您有权创建具有指定资源条件的 EFS 文件系统。有关更多信息,请参阅适用于 Amazon Elastic File System 的 Identity and Access Management

拒绝访问 NFS 文件系统上允许的文件

当分配了超过 16 个访问组 ID(GID)的用户尝试在 NFS 文件系统上执行操作时,可能会拒绝他们访问文件系统上允许的文件。出现此问题是因为 NFS 协议支持每个用户最多 16 个 GID,并且根据 RFC 5531 中的定义,NFS 客户端请求中的任何其他 GID 都会被截断。

要采取的操作

重组您的 NFS 用户和组映射,以便为每个用户分配的访问组(GID)不超过 16 个。

访问 Amazon EFS 控制台时出错

本节介绍用户在访问 Amazon EFS 管理控制台时可能遇到的错误。

对的 ec2:DescribeVPCs 凭证进行身份验证时出错

访问 Amazon EFS 控制台时会显示以下错误消息:

AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.

此错误表示您的登录凭证未成功通过 Amazon EC2 服务的身份验证。在您选择的 VPC 中创建 EFS 文件系统时,Amazon EFS 控制台会代表您调用 Amazon EC2 服务。

要采取的操作

确保正确设置了客户端访问 Amazon EFS 控制台的时间。

Amazon EC2 实例挂起

Amazon EC2 实例挂起的原因可能是,您在未首先卸载文件系统的情况下删除了文件系统挂载目标。

要采取的操作

在删除文件系统挂载目标之前,请卸载文件系统。有关卸载您的 Amazon EFS 文件系统的更多信息,请参阅卸载文件系统

写入大量数据的应用程序挂起

将大量数据写入 Amazon EFS 的应用程序挂起,并导致实例重新启动。

要采取的操作

如果应用程序需要太长时间才能将其所有数据写入 Amazon EFS,则 Linux 可能会重新启动,因为进程似乎已没有响应。两个内核配置参数可定义此行为,即 kernel.hung_task_panickernel.hung_task_timeout_secs

在以下示例中,在实例重启之前,ps 命令将挂起的进程状态报告为 D,表明该进程正在等待 I/O。

$ ps aux | grep large_io.py root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py /efs/large_file

要防止重新启动,请增加超时期限或禁用检测到挂起任务时的内核崩溃。以下命令将禁用大多数 Linux 系统上的挂起任务内核崩溃。

$ sudo sysctl -w kernel.hung_task_panic=0

并行打开多个文件时,性能不佳

并行打开多个文件的应用程序的 I/O 并行化性能不会出现预期提升。

要采取的操作

此问题出现在网络文件系统版本 4 (NFSv4) 客户端以及使用 NFSv4.1 的 RHEL 6 客户端上,因为这些 NFS 客户端将序列化 NFS OPEN 和 CLOSE 操作。请使用 NFS 协议版本 4.1 和建议的 Linux 发行版(不存在此问题)之一。

如果无法使用 NFSv4.1,请注意,Linux NFSv4.0 客户端按用户 ID 和组 ID 序列化打开和关闭请求。即使多个进程或多个线程同时发出请求,也会发生此序列化。仅当所有 ID 均匹配时,客户端才一次向 NFS 服务器发送一个打开或关闭操作。要解决这些问题,可以执行下列任一操作:

  • 您可以在同一 Amazon EC2 实例上通过不同用户 ID 运行每个进程。

  • 您可以对所有打开请求使用相同的用户 ID,并修改组 ID 集。

  • 您可以从单独的 Amazon EC2 实例运行每个进程。

自定义 NFS 设置导致写入延迟

您可以自定义 NFS 客户端设置,Amazon EC2 实例需要最多三秒钟时间来查看通过其他 Amazon EC2 实例对文件系统执行的写入操作。

要采取的操作

如果遇到该问题,可以通过以下任一方法加以解决:

  • 如果 Amazon EC2 实例上读取数据的 NFS 客户端已激活属性缓存,请卸载文件系统。然后,使用 noac 选项重新挂载文件系统以禁用属性缓存。默认情况下,已启用 NFSv4.1 中的属性缓存。

    注意

    禁用客户端缓存可能会降低您的应用程序性能。

  • 您还可以通过使用与 NFS 过程兼容的编程语言来按需清除您的属性缓存。要执行该操作,您可以在发送 ACCESS 过程请求后立即发送读取请求。

    例如,您可以使用 Python 编程语言构造以下调用。

    # Does an NFS ACCESS procedure request to clear the attribute cache, given a path to the file import os os.access(path, os.W_OK)

使用 Oracle Recovery Manager 创建备份的速度很慢

如果在启动备份作业之前 Oracle Recovery Manager 暂停 120 秒,使用 Oracle Recovery Manager 创建备份的速度可能很慢。

要采取的操作

如果遇到该问题,请禁用 Oracle 直接 NFS,如 Oracle 帮助中心的启用和禁用 NFS 的直接 NFS 客户端控制中所述。

注意

Amazon EFS 不支持 Oracle 直接 NFS。