使用 Storage Gateway 控制台配置自动缓存刷新计划使用 Amazon Lambda 和 Amazon CloudWatch 规则配置自动缓存刷新计划使用 Storage Gateway 控制台执行手动缓存刷新使用 Storage Gateway API 执行手动缓存刷新

刷新 Amazon S3 存储桶对象缓存

在 NFS 或 SMB 客户端执行文件系统操作时，您的网关会在与文件共享关联的 Amazon S3 对象缓存中维护一个对象清单。您的网关使用此缓存清单来减小 Amazon S3 请求的延迟和频率。此操作不会将文件导入 S3 文件网关缓存存储。仅更新缓存的清单，以反映 Amazon S3 对象缓存中对象清单的变化。

要刷新文件共享的 S3 存储桶对象缓存，请从以下列表中选择最适合您的使用案例的方法，然后完成以下相应步骤。

注意

无论您使用哪种方法，首次列出目录时都会对其进行初始化，从而使网关从 Amazon S3 中列出目录的元数据内容。初始化目录所需的时间与目录中的条目数成正比。

主题

使用 Storage Gateway 控制台配置自动缓存刷新计划
使用 Amazon Lambda 和 Amazon CloudWatch 规则配置自动缓存刷新计划
使用 Storage Gateway 控制台执行手动缓存刷新
使用 Storage Gateway API 执行手动缓存刷新

使用 Storage Gateway 控制台配置自动缓存刷新计划

以下过程根据您指定的生存时间（TTL）值配置自动缓存刷新计划。在配置基于 TTL 的缓存刷新计划之前，请考虑以下事项：

TTL 是指自从上次对给定目录进行缓存刷新以来所经过的时间长度。
仅当在指定的 TTL 期限到期后访问给定目录时，才会进行基于 TTL 的缓存刷新。
刷新是非递归的。仅在访问特定目录时才会刷新。
只有对那些自 TTL 过期以来尚未同步的目录进行刷新才会产生 Amazon S3 API 费用。
- 只有当 NFS 或 SMB 活动访问目录时，才会同步目录。
- 同步操作的频率不会高于您指定的 TTL 周期。
仅当您经常在网关和 Amazon S3 存储桶之间的工作流之外直接更新 Amazon S3 存储桶的内容时，才建议配置基于 TTL 的缓存刷新。
当网关刷新目录的内容时，系统会阻止 NFS 和 SMB 操作访问具有过期 TTL 的目录。

注意
由于缓存刷新会阻止目录访问操作，因此建议在不影响用户体验的情况下为您的部署配置尽可能长的 TTL 周期。

使用 Storage Gateway 控制台配置自动缓存刷新计划

打开 Storage Gateway 控制台，网址为 https://console.aws.amazon.com/storagegateway/home。
选择文件共享。
选择要为其配置刷新计划的文件共享。
对于操作，选择编辑文件共享设置。
对于以下时间之后从 S3 自动刷新缓存，请选中该复选框，并使用生存时间（TTL）以天、小时和分钟为单位设置文件共享缓存的刷新时间。TTL 是自上次刷新以来的时间长度，在此时间之后，对目录的访问将导致文件网关首先从 Amazon S3 存储桶刷新该目录的内容。
选择保存更改。

使用 Amazon Lambda 和 Amazon CloudWatch 规则配置自动缓存刷新计划

标识 S3 文件网关使用的 S3 存储桶。
确认事件部分为空。稍后会自动填充此部分。
创建 IAM 角色，并允许建立 Lambda lambda.amazonaws.com 的信任关系。

使用以下策略。

从 Lambda 控制台创建 Lambda 函数。

使用以下函数执行您的 Lambda 任务。


import json
import boto3
client = boto3.client('storagegateway')
def lambda_handler(event, context):
    print(event)
    response = client.refresh_cache(
        FileShareARN='arn:aws:storagegateway:ap-southeast-2:672406474878:share/share-E51FBS9C'
    )
    print(response)
    return 'Your FileShare cache has been refreshed'

对于执行角色，选择您创建的 IAM 角色。
可选：为 Amazon S3 添加触发器，然后选择事件 ObjectCreated 或 ObjectRemoved。

注意
RefreshCache 需要先完成一个进程，然后再开始另一个进程。当您在存储桶中创建或删除许多对象时，性能可能会降低。因此，我们不建议使用 S3 触发器。相反，请使用下文所述的 Amazon CloudWatch 规则。
在 CloudWatch 控制台上创建 CloudWatch 规则并添加计划。通常，建议使用 30 分钟的固定间隔。但是，您可以对大型 S3 存储桶使用 1-2 个小时的间隔。
为 CloudWatch 事件添加新的触发器，然后选择您刚刚创建的规则。
保存 Lambda 配置。选择测试。
选择 S3 PUT 并根据您的要求自定义测试。
测试应该会成功。如果未成功，请根据您的要求修改 JSON 并重新测试。
打开 Amazon S3 控制台，并确认您创建的事件和 Lambda 函数 ARN 存在。

使用 Amazon S3 控制台或 Amazon CLI 将对象上传到 S3 存储桶。

CloudWatch 控制台会生成与以下内容类似的 CloudWatch 输出。


{
    u'Records': [
        {u'eventVersion': u'2.0', u'eventTime': u'2018-09-10T01:03:59.217Z', u'requestParameters': {u'sourceIPAddress': u'MY-IP-ADDRESS'}, 
        u's3': {u'configurationId': u'95a51e1c-999f-485a-b994-9f830f84769f', u'object': {u'sequencer': u'00549CC2BF34D47AED', u'key': u'new/filename.jpeg'}, 
        u'bucket': {u'arn': u'arn:aws:s3:::amzn-s3-demo-bucket', u'name': u'MY-GATEWAY-NAME', u'ownerIdentity': {u'principalId': u'A3OKNBZ72HVPP9'}}, u's3SchemaVersion': u'1.0'}, 
        u'responseElements': {u'x-amz-id-2': u'76tiugjhvjfyriugiug87t890nefevbck0iA3rPU9I/s4NY9uXwtRL75tCyxasgsdgfsq+IhvAg5M=', u'x-amz-request-id': u'651C2D4101D31593'}, 
        u'awsRegion': u'MY-REGION', u'eventName': u'ObjectCreated:PUT', u'userIdentity': {u'principalId': u'AWS:AROAI5LQR5JHFHDFHDFHJ:MY-USERNAME'}, u'eventSource': u'aws:s3'}
    ]
}

Lambda 调用将提供类似于以下内容的输出。


{
    u'FileShareARN': u'arn:aws:storagegateway:REGION:ACCOUNT-ID:share/MY-SHARE-ID', 
        'ResponseMetadata': {'RetryAttempts': 0, 'HTTPStatusCode': 200, 'RequestId': '6663236a-b495-11e8-946a-bf44f413b71f', 
            'HTTPHeaders': {'x-amzn-requestid': '6663236a-b495-11e8-946a-bf44f413b71f', 'date': 'Mon, 10 Sep 2018 01:03:59 GMT', 
                'content-length': '90', 'content-type': 'application/x-amz-json-1.1'
        }
    }
}

您在客户端上挂载的 NFS 共享会反映此更新。

注意

对于在包含数百万个对象的大型存储桶中更新大型对象创建或删除的缓存，更新可能需要几个小时。

使用 Amazon S3 控制台或 Amazon CLI 手动删除对象。
查看您的客户端上挂载的 NFS 共享。确认您的对象已消失（因为您的缓存已刷新）。

检查 CloudWatch 日志，以便查看删除操作和事件 ObjectRemoved:Delete 的日志。


{
    u'account': u'MY-ACCOUNT-ID', u'region': u'MY-REGION', u'detail': {}, u'detail-type': u'Scheduled Event', u'source': u'aws.events', 
    u'version': u'0', u'time': u'2018-09-10T03:42:06Z', u'id':  u'6468ef77-4db8-0200-82f0-04e16a8c2bdb', 
    u'resources': [u'arn:aws:events:REGION:MY-ACCOUNT-ID:rule/FGw-RefreshCache-CW']
}

注意

对于 cron 作业或计划任务，您的 CloudWatch 日志事件为 u'detail-type': u'Scheduled Event'。

使用 Storage Gateway 控制台执行手动缓存刷新

打开 Storage Gateway 控制台，网址为 https://console.aws.amazon.com/storagegateway/home。
选择文件共享，然后选择要为其执行刷新的文件共享。
对于 Actions，选择 Refresh cache。

刷新过程所需的时间取决于在网关上缓存的对象数以及在 S3 存储桶中添加或删除的对象数。

使用 Storage Gateway API 执行手动缓存刷新

按照以下程序，使用 Storage Gateway API 来执行手动缓存刷新。在执行基于 API 的缓存刷新之前，请注意以下事项：

您可以指定递归刷新或非递归刷新。
递归刷新的资源密集度更高，成本也更高。
只有对您在请求中作为参数传递的目录以及这些目录的后代（如果指定了递归刷新）进行刷新才会产生 Amazon S3 API 费用。
当网关处于使用状态时，刷新与其他操作同时执行。
- 在刷新期间通常不会阻止 NFS 和 SMB 操作，除非操作正在访问的目录处于刷新状态。
- 网关无法确定当前缓存内容是否过时，并且无论新鲜度如何，都使用其当前内容进行 NFS 和 SMB 操作。
- 由于缓存刷新会利用网关虚拟硬件资源，因此在刷新过程中，网关性能可能会受到负面影响。
仅当您在网关和 Amazon S3 存储桶之间的工作流之外直接更新 Amazon S3 存储桶的内容时，才建议执行基于 API 的缓存刷新。

注意
如果您知道在网关工作流之外更新 Amazon S3 内容是在哪个特定目录进行，建议您在基于 API 的刷新请求中指定这些目录，以便降低 Amazon S3 API 成本和网关性能影响。

使用 Storage Gateway API 执行手动缓存刷新

发送 HTTP POST 请求，通过 Storage Gateway API 调用带有所需参数的 RefreshCache 操作。有关更多信息，请参阅《Amazon Storage Gateway API 参考》中的 RefreshCache。

注意
发送 RefreshCache 请求只会启动缓存刷新操作。在缓存刷新完成时，这并不一定表示文件刷新完成。要确定在检查网关文件共享上的新文件之前已完成文件刷新操作，请使用 refresh-complete 通知。为此，您可以订阅通过 Amazon CloudWatch 事件发送的通知。有关更多信息，请参阅获取有关文件操作的通知。

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

限制 NFS 文件共享访问

使用 S3 对象锁定