使用 Storage Gateway 主控台設定自動快取重新整理排程使用 AWS Lambda 搭配 Amazon CloudWatch 規則設定自動快取重新整理排程使用 Storage Gateway 主控台執行手動快取重新整理使用 Storage Gateway API 執行手動快取重新整理

重新整理 Amazon S3 儲存貯體物件快取

當您的 NFS 或 SMB 用戶端執行檔案系統操作時，閘道會維護與檔案共享相關聯的 Amazon S3 物件快取中的物件清查。您的閘道使用此快取庫存來減少 Amazon S3 請求的延遲和頻率。此操作不會將檔案匯入 S3 File Gateway 快取儲存體。它只會更新快取的庫存，以反映 Amazon S3 物件快取中物件庫存的變更。

若要重新整理檔案共享的 S3 儲存貯體物件快取，請從下列清單中選取最適合您的使用案例的方法，然後完成以下對應的程序。

注意

無論您使用何種方法，首次列出目錄會將其初始化，這會導致閘道從 Amazon S3 列出目錄的中繼資料內容。初始化目錄所需的時間與目錄中的項目數量成正比。

主題

使用 Storage Gateway 主控台設定自動快取重新整理排程
使用 AWS 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 型快取重新整理。
閘道重新整理目錄內容時，將封鎖存取具有過期 TTLs目錄的 NFS 和 SMB 操作。

注意
由於快取重新整理可能會封鎖目錄存取操作，因此建議您設定適用於部署的最長 TTL 期間。

使用 Storage Gateway 主控台設定自動快取重新整理排程

前往 https://console.aws.amazon.com/storagegateway/home 開啟 Storage Gateway 主控台。
選擇檔案共享。
選擇您要為其設定重新整理排程的檔案共用。
針對動作，選擇編輯檔案共享設定。
對於之後 S3 的自動快取重新整理，請選取核取方塊，並使用存留時間 (TTL) 設定以天、小時和分鐘為單位的時間來重新整理檔案共享的快取。TTL 是自上次重新整理之後的時間長度，之後存取目錄會導致檔案閘道先從 Amazon S3 儲存貯體重新整理該目錄的內容。
選擇儲存變更。

使用 AWS 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 主控台或將物件上傳至 S3 儲存貯體 AWS CLI。 Amazon 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 主控台或手動刪除物件 AWS 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 主控台執行手動快取重新整理

前往 https://console.aws.amazon.com/storagegateway/home 開啟 Storage Gateway 主控台。
選擇檔案共享，然後選擇您要為其執行重新整理的檔案共享。
針對 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操作。如需詳細資訊，請參閱 AWS Storage Gateway API 參考中的 RefreshCache。

注意
傳送RefreshCache請求只會啟動快取重新整理操作。快取重新整理完成時，並不表示檔案重新整理已完成。若要判斷檔案重新整理操作是否已完成，在檢查閘道檔案共用上的新檔案之前，請使用 refresh-complete 通知。若要這樣做，您可以透過 Amazon CloudWatch 事件訂閱以收到通知。如需詳細資訊，請參閱收到有關檔案操作的通知。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

限制 NFS 檔案共享存取

使用 S3 物件鎖定