本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
排查文件共享问题
您可以在下面找到有关您遇到文件共享意外问题时要采取的措施的信息。
主题
您的文件共享卡在 CREATING 状态
当您创建文件共享时,状态为 CREATING。创建文件共享之后,状态变为 AVAILABLE。如果文件共享陷入 CREATING 状态,请执行以下操作:
-
通过以下网址打开 Amazon S3 控制台:https://console.amazonaws.cn/s3/
。 -
确保您将文件共享映射到的 S3 存储桶存在。如果此存储桶不存在,则创建存储桶。创建存储桶之后,文件共享状态变为 AVAILABLE。有关如何创建 S3 存储桶的信息,请参阅 https://docs.amazonaws.cn/AmazonS3/latest/gsg/CreatingABucket.html 中的创建存储桶Amazon Simple Storage Service 控制台用户指南。
-
确保您的存储桶名称符合 Amazon S3 中的存储桶命名规则。有关更多信息,请参阅 https://docs.amazonaws.cn/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules 中的存储桶命名规则Amazon Simple Storage Service 开发人员指南。
-
确保用于访问 S3 存储桶的 IAM 角色具有正确的权限,并验证 S3 存储桶是否在 IAM 策略中作为资源列出。有关更多信息,请参阅授权访问 Amazon S3 桶。
您无法创建文件共享
-
如果您由于文件共享卡在 CREATING 状态而无法创建文件共享,请验证文件共享所映射到的 S3 存储桶是否存在。有关如何执行此操作的信息,请参阅上述的 您的文件共享卡在 CREATING 状态。
-
如果 S3 存储桶存在,则验证要在其中创建文件共享的区域中启用了 AWS Security Token Service。如果安全令牌未启用,则应启用安全令牌。有关如何使用 AWS Security Token Service 启用令牌的信息,请参阅 中的AWS在 区域中激活和停用 AWS STS。IAM 用户指南
SMB 文件共享不允许多种不同的访问方法
SMB 文件共享具有以下限制:
-
当同一客户端尝试安装 Active Directory 和来宾访问 SMB 文件共享时,将显示以下错误消息:
Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.
-
一个 Windows 用户不能保持与两个来宾访问 SMB 文件共享的连接,并且在新的来宾访问连接建立后可能会断开连接。
-
Windows 客户端无法同时安装由同一网关导出的来宾访问和 Active Directory SMB 文件共享。
多个文件共享无法写入到映射的 S3 存储桶
我们建议不要将 S3 存储桶配置为允许多个文件共享写入到一个 S3 存储桶。此方法可能导致无法预测的结果。
相反,我们建议您只允许一个文件共享写入到每个 S3 存储桶。您可以创建存储桶策略,仅允许与文件共享相关联的角色写入到存储桶。有关更多信息,请参阅文件共享最佳实践。
Can 未将文件上传到 S3 存储桶
如果您无法将文件上传到 S3 存储桶,请执行以下操作:
-
确保您已为文件网关授予必要的访问权限,以将文件上传到 S3 存储桶。有关更多信息,请参阅授权访问 Amazon S3 桶。
-
确保创建存储桶的角色有权写入到 S3 存储桶。有关更多信息,请参阅文件共享最佳实践。
Can 不更改默认加密以使用 SSE-KMS 加密存储在 S3 存储桶中的对象
如果您更改默认加密并使 SSE-KMS(使用 AWS KMS 托管密钥的服务器端加密)成为 S3 存储桶的默认加密,则 – 存储在存储桶中的对象不会使用 SSE-KMS 加密。文件网关默认情况下,文件网关在将数据写入 S3 存储桶时使用 Amazon S3 (SSE-S3) 托管的服务器端加密。更改默认值不会自动更改您的加密。
要将加密更改为将 SSE-KMS 与您自己的 AWS KMS 密钥结合使用,则必须启用 SSE-KMS 加密。为此,您需要在创建文件共享时提供 KMS 密钥的 Amazon
资源名称 (ARN)。您也可以通过使用 UpdateNFSFileShare
或 UpdateSMBFileShare
API 操作来更新文件共享的 KMS 设置。更新后,此更新适用于存储在 S3 存储桶中的对象。有关更多信息,请参阅使用 AWS KMS 的数据加密。
在启用了对象版本控制的 S3 存储桶中直接所做的更改可能会影响您在文件共享中看到的内容
如果您的 S3 存储桶具有由其他客户端写入它的对象,则由于 S3 存储桶对象版本控制,S3 存储桶的视图可能不是最新的。您应始终先刷新缓存,然后再查看感兴趣的文件。
对象版本控制 是一项可选的 S3 存储桶功能,通过存储同名对象的多个副本来帮助保护数据。每个副本都有一个单独的 ID 值,例如 file1.jpg
:ID="xxx"
和 file1.jpg
:ID="yyy"
。 同名对象数及其生命周期由 Amazon S3 生命周期策略控制。有关这些 Amazon S3 概念的更多详细信息,请参阅 开发人员指南 中的使用版本控制和对象生命周期管理Amazon S3。
在删除受版本控制的对象时,会使用删除标记来标记该对象,但保留该对象。只有 S3 存储桶拥有者才能永久删除启用了版本控制的对象。
在文件网关中,所显示的文件是获取对象或刷新缓存时 S3 存储桶中的对象的最新版本。文件网关会忽略任何较旧版本或标记为删除的任何对象。在读取文件时,您从最新版本读取数据。在您编写文件共享中的文件时,文件网关将创建具有您所做更改的命名对象的新版本,并且该版本将成为最新版本。
如果新版本添加到了您的应用程序之外的 S3 存储桶中,则您的文件网关将继续从较早版本读取,并且您所做的更新将基于较早版本。要读取对象的最新版本,请使用 RefreshCache API 操作或从控制台刷新,如中所述。刷新 Amazon S3 存储桶中的对象
我们不建议对象或文件写入文件共享之外的文件网关 S3 存储桶中。
在写入已启用对象版本控制的 S3 存储桶时,文件网关可能会创建 S3 对象的多个版本
启用对象版本控制后,对于 NFS 或 SMB 客户端中的文件每次更新,您可能会在 Amazon S3 中创建多个版本的对象。下面是可能导致在 S3 存储桶中创建对象的多个版本的场景:
-
当 NFS 或 SMB 客户端将文件上传到 Amazon S3 后在文件网关中修改该文件时,文件网关将上传新的或修改后的数据,而不是上传整个文件。文件修改导致创建新版本的 Amazon S3 对象。
-
当 NFS 或 SMB 客户端将文件写入文件网关时,文件网关会将文件数据上传到 Amazon S3,后跟其元数据(所有权、时间戳等)。上传文件数据会创建一个 Amazon S3 对象,上传该文件的元数据将更新 Amazon S3 对象的元数据。此过程会创建对象的另一个版本,从而生成两个版本的对象。
-
当文件网关上传较大的文件时,可能需要上传较小的文件区块,然后再将客户端写入到文件网关。导致这种情况的一些原因包括释放缓存空间或高文件写入速率。这会导致 S3 存储桶中多个版本的对象。
您应该监控 S3 存储桶,以确定在设置生命周期策略以将对象移动到不同的存储类之前,存在对象版本数。您应该为以前的版本配置生命周期过期时间,以最大程度地减少 S3 存储桶中对象的版本数。在 S3 存储桶之间使用相同区域复制 (SRR) 或跨区域复制 (CRR) 将增加使用的存储。有关复制的更多信息,请参阅复制。
请勿在 S3 存储桶之间配置复制,直到您了解启用对象版本控制时正在使用的存储量。
使用受版本控制的 S3 存储桶会大大增加 Amazon S3 中的存储量,因为对文件进行的每次修改都会创建一个新版本的 S3 对象。默认情况下,Amazon S3
会继续存储所有这些版本,除非您专门创建一个策略来覆盖此行为并限制保留的版本数。如果您注意到启用对象版本控制后存储使用量异常大,请检查您是否正确设置了存储策略。浏览器请求的
HTTP 503-slow down
响应数的增加也可能是由于对象版本控制问题。
如果您在安装文件网关后启用了对象版本控制,则将保留所有唯一对象 (ID=”NULL”
),并且您可以在文件系统中查看所有对象。将为对象的新版本分配唯一 ID(保留较旧版本)。基于对象的时间戳,仅最新版本的对象可在 NFS 文件系统中查看。
在您启用对象版本控制后,您的 S3 存储桶将无法返回到不受版本控制的状态。但是,您可以暂停版本控制。在暂停版本控制时,会为新对象分配一个 ID。如果存在具有 ID=”NULL”
值的同名对象,则将覆盖较旧版本。但是,将保留包含非 NULL
ID 的任何版本。时间戳将新对象标识为最新对象,并且这是显示在 NFS 文件系统中的对象。
对 S3 存储桶的更改未反映在 Storage Gateway 中
当您使用文件共享在本地将文件写入缓存时,Storage Gateway 会自动更新文件共享缓存。但是,当您将文件直接上传到 Amazon S3 时,Storage
Gateway 不会自动更新缓存。在执行此操作时,您必须执行 RefreshCache
操作以查看文件共享上的更改。如果您有多个文件共享,则必须在每个文件共享上运行 RefreshCache
操作。
您可以使用 Storage Gateway 控制台和 AWS 命令行界面 (AWS CLI) 刷新缓存:
-
要使用 Storage Gateway 控制台刷新缓存,请参阅刷新 Amazon S3 存储桶中的对象。
-
使用 AWS CLI 刷新缓存:
-
运行命令
aws storagegateway list-file-shares
-
将文件共享的 Amazon 资源编号 (ARN) 与要刷新的缓存一起复制。
-
运行
refresh-cache
命令并将您的 ARN 作为--file-share-arn
的值:aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12
-
要自动执行 RefreshCache
操作,请参阅如何在 Storage Gateway 上自动执行 RefreshCache 操作?
ACL 权限未按预期工作
如果访问控制列表 (ACL) 权限未按预期与 SMB 文件共享一起运行,则您可以执行测试。
为此,请首先测试 Microsoft Windows 文件服务器或本地 Windows 文件共享上的权限。然后,将行为与您网关的文件共享进行比较。
在执行递归操作之后,网关性能下降
在某些情况下,您可能会执行递归操作(例如重命名目录或启用 ACL 的继承),并强制沿树向下执行递归操作。如果您这样做,文件网关通过递归方式将该操作应用于文件共享中的所有对象。
例如,假设您将继承应用于 S3 存储桶中的现有对象。您的文件网关通过递归方式将继承应用于存储桶中的所有对象。此类操作可能会导致网关性能下降。