故障診斷:檔案共用問題 - AWS Storage Gateway

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

故障診斷:檔案共用問題

如果您的檔案共享發生非預期問題,您可在下列資訊中找到應採取的動作。

您的檔案共享卡在 CREATING 狀態

當您的檔案共享正在建立時,其狀態為 CREATING (建立中)。檔案共享建立後,狀態會轉換為 AVAILABLE (可用) 狀態。如果您的檔案共享停滯在 CREATING (建立中) 狀態,請執行下列動作:

  1. 開啟位於 https://console.aws.amazon.com/s3/ 的 Amazon S3 主控台。

  2. 請確定您映射檔案共享的 S3 儲存貯體存在。如果儲存貯體不存在,請予以建立。儲存貯體建立後,檔案共享狀態會轉換為 AVAILABLE (可用)。如需如何建立 S3 儲存貯體的資訊,請參閱《Amazon Simple Storage Service 使用者指南》中的建立儲存貯體

  3. 請確定您的儲存貯體名稱符合 Amazon S3 中儲存貯體命名的規則。如需詳細資訊,請參閱 Amazon Simple Storage Service 使用者指南中的儲存貯體命名規則

    注意

    S3 File Gateway 不支援在儲存貯體名稱中包含句點 (.) 的 Amazon S3 儲存貯體。

  4. 請確定您用來存取 S3 儲存貯體的 IAM 角色具有正確的許可,並確認 S3 儲存貯體已列為 IAM 政策中的資源。如需詳細資訊,請參閱授予對 Amazon S3 儲存貯體的存取權

您無法建立檔案共享

  1. 如果您因為檔案共享卡在 CREATING 狀態而無法建立檔案共享,請確認您映射檔案共享的 S3 儲存貯體是否存在。如需如何執行作業的資訊,請參閱上一篇的您的檔案共享卡在 CREATING 狀態

  2. 如果 S3 儲存貯體存在,請確認 AWS Security Token Service 已在您建立檔案共享的區域中啟用。如果安全字符非作用中,您應該啟用它。如需有關如何使用 啟用權杖的資訊 AWS Security Token Service,請參閱《IAM 使用者指南》中的在 AWS 區域中啟用和停用 AWS STS

SMB 檔案共用不允許多種不同的存取方法

SMB 檔案共享有以下限制:

  1. 當相同的用戶端嘗試同時掛載 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.

  2. Windows 使用者不能保持連線到兩個訪客存取 SMB 檔案共享,當新的訪客存取連線建立時可能會中斷連線。

  3. Windows 用戶端無法同時掛載訪客存取和由相同閘道匯出的 Active Directory SMB 檔案共享。

多個檔案共享無法寫入映射的 S3 儲存貯體

我們不建議將 S3 儲存貯體設定為允許多個檔案共用寫入一個 S3 儲存貯體。這種方法會造成無法預測的結果。

相反地,我們建議您只允許一個檔案共享寫入一個 S3 儲存貯體。您建立一個儲存貯體政策,僅允許與您檔案共享相關聯的角色寫入儲存貯體。如需詳細資訊,請參閱檔案閘道的最佳實務

使用稽核日誌時已刪除日誌群組的通知

如果日誌群組不存在,使用者可以選取該訊息下方的日誌群組連結,以建立新日誌群組或使用現有日誌群組做為稽核日誌的目標

無法將檔案上傳至 S3 儲存貯體

如果您無法將檔案上傳至 S3 儲存貯體,請執行下列動作:

  1. 請確定您已授予 Amazon S3 File Gateway 將檔案上傳至 S3 儲存貯體所需的存取權。如需詳細資訊,請參閱授予對 Amazon S3 儲存貯體的存取權

  2. 確定建立儲存貯體的角色具有寫入 S3 儲存貯體的許可。如需詳細資訊,請參閱檔案閘道的最佳實務

  3. 如果您的檔案閘道使用 SSE-KMS 或 DSSE-KMS 進行加密,請確定與檔案共享相關聯的 IAM 角色包含 kms:Encryptkms:Decryptkms:ReEncrypt*kms:GenerateDataKeykms:DescribeKey 許可。如需詳細資訊,請參閱針對 Storage Gateway 使用以身分為基礎的政策 (IAM 政策)

無法將預設加密變更為使用 SSE-KMS 來加密存放在 S3 儲存貯體中的物件

如果您變更預設加密並將 SSE-KMS (使用 AWS KMS受管金鑰的伺服器端加密) 設為 S3 儲存貯體的預設值,Amazon S3 File Gateway 存放在儲存貯體中的物件不會使用 SSE-KMS 加密。根據預設,S3 File Gateway 在將資料寫入 S3 儲存貯體時,會使用由 Amazon S3 (SSE-S3) 管理的伺服器端加密。變更預設值不會自動變更您的加密。

若要將加密變更為使用 SSE-KMS 搭配您自己的 AWS KMS 金鑰,您必須開啟 SSE-KMS 加密。若要這樣做,當您建立檔案共享時要提供 KMS 金鑰的 Amazon Resource Name (ARN)。您也可以使用 UpdateNFSFileShareUpdateSMBFileShare API 操作,更新您檔案共享的 KMS 設定。此更新適用於更新後存放在 S3 儲存貯體中的物件。如需詳細資訊,請參閱使用 的資料加密 AWS KMS

在開啟物件版本控制的 S3 儲存貯體中直接進行的變更可能會影響您在檔案共享中看到的內容

如果您的 S3 儲存貯體有另一個用戶端寫入的物件,則由於 S3 儲存貯體物件版本控制,您對 S3 儲存貯體的檢視可能不是up-to-date。您應一律先重新整理您的快取,再檢查感興趣的檔案。

物件版本控制是選用的 S3 儲存貯體功能,透過存放多個同名物件的副本以利保護資料。每個副本都有個別的 ID 值,例如 file1.jpgID="xxx"file1.jpgID="yyy"。相同名稱的物件數量及其生命週期由 Amazon S3 生命週期政策控制。如需這些 Amazon S3 概念的詳細資訊,請參閱《Amazon S3 開發人員指南》中的使用版本控制物件生命週期管理Amazon S3

當您刪除版本控制的物件時,該物件會以刪除標記加以標記並保留下來。只有 S3 儲存貯體擁有者才能永久刪除開啟版本控制的物件。

在您的 S3 檔案閘道中,顯示的檔案是擷取物件或重新整理快取時,S3 儲存貯體中物件的最新版本。S3 檔案閘道會忽略任何較舊版本或標記為刪除的任何物件。讀取檔案時,您讀取的資料是來自最新的版本。當您在檔案共享中寫入檔案時,S3 File Gateway 會在變更時建立新的具名物件版本,該版本會成為最新版本。

您的 S3 檔案閘道會繼續從較早版本讀取,而且如果您在應用程式外部將新版本新增至 S3 儲存貯體,則您所做的更新是根據較早版本。若要讀取最新版的物件,請從主控台使用 RefreshCache API 動作或重新整理,如 重新整理 Amazon S3 儲存貯體物件快取 中所述。

重要

我們不建議將物件或檔案從檔案共用外部寫入 S3 File Gateway S3 儲存貯體。

在開啟版本控制的情況下寫入 S3 儲存貯體時,Amazon S3 檔案閘道可能會建立多個版本的 Amazon S3 物件

開啟物件版本控制後,每次從 NFS 或 SMB 用戶端更新檔案時,您可能會擁有在 Amazon S3 中建立的多個物件版本。以下是可能導致在 S3 儲存貯體中建立多個物件版本的案例:

  • 當 NFS 或 SMB 用戶端在上傳到 Amazon S3 之後在 Amazon S3 檔案閘道中修改檔案時,S3 檔案閘道會上傳新的或修改的資料,而不是上傳整個檔案。檔案修改會導致建立新版本的 Amazon S3 物件。

  • 當 NFS 或 SMB 用戶端將檔案寫入 S3 檔案閘道時,S3 檔案閘道會將檔案的資料上傳到 Amazon S3,後面接著其中繼資料 (擁有者、時間戳記等)。上傳檔案資料會建立 Amazon S3 物件,並上傳檔案的中繼資料會更新 Amazon S3 物件的中繼資料。此程序會建立另一個版本的物件,進而產生兩個版本的物件。

  • 當 S3 檔案閘道上傳較大的檔案時,可能需要先上傳較小的檔案區塊,用戶端才能寫入檔案閘道。這的一些原因包括釋放快取空間或對檔案的高寫入速率。這可能會導致 S3 儲存貯體中有多個版本的物件。

在設定生命週期政策將物件移至不同的儲存類別之前,您應該監控 S3 儲存貯體,以判斷物件存在多少版本。您應該設定舊版的生命週期過期,將 S3 儲存貯體中物件的版本數量降至最低。在 S3 儲存貯體之間使用相同區域複寫 (SRR) 或跨區域複寫 (CRR) 會增加使用的儲存體。如需複寫的詳細資訊,請參閱複寫

重要

在您了解開啟物件版本控制時,請勿設定 S3 儲存貯體之間的複寫。

使用版本控制的 S3 儲存貯體可以大幅增加 Amazon S3 中的儲存量,因為每次修改檔案都會建立新的 S3 物件版本。根據預設,Amazon S3 會繼續存放所有這些版本,除非您特別建立政策來覆寫此行為,並限制保留的版本數量。如果您在開啟物件版本控制時發現異常大量的儲存體用量,請檢查儲存政策是否已正確設定。瀏覽器請求的 HTTP 503-slow down 回應數增加,也會導致物件版本控制問題。

如果您在安裝 S3 檔案閘道之後開啟物件版本控制,則會保留所有唯一的物件 (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 Command Line Interface 重新整理快取AWS CLI:

  • 若要使用 Storage Gateway 主控台重新整理快取,請參閱重新整理 Amazon S3 儲存貯體中的物件。

  • 若要使用 重新整理快取 AWS CLI:

    1. 執行 命令 aws storagegateway list-file-shares

    2. 使用您要重新整理的快取複製檔案共享的 Amazon Resource Number (ARN)。

    3. 使用 ARN 做為 的值來執行 refresh-cache命令--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 File Gateway 會以遞迴方式將操作套用至檔案共享中的所有物件。

例如,假設您將繼承套用至 S3 儲存貯體中的現有物件。您的 S3 File Gateway 會以遞迴方式將繼承套用至儲存貯體中的所有物件。這類操作可能會導致閘道的效能下降。