翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ファイルゲートウェイのベストプラクティス
このセクションには、ゲートウェイ、ファイル共有、バケット、およびデータの操作に関するベスト プラクティスに関する情報を提供する次のトピックが含まれています。このセクションで説明されている情報を理解し、 AWS Storage Gatewayの問題を避けるためにこれらのガイドラインに従うことをお勧めします。デプロイで発生する可能性がある一般的な問題の診断と解決に関する追加のガイダンスについては、「[Storage Gateway のデプロイに関する問題のトラブルシューティング](troubleshooting-gateway-issues.md)」を参照してください。
**Topics**
+ [ベストプラクティス: データの復旧](#recover-data-from-gateway)
+ [ベストプラクティス: マルチパートアップロードの管理](#best-practices-managing-multi-part-uploads)
+ [ベストプラクティス: ゲートウェイにコピーする前に、圧縮ファイルをローカルで解凍する](#best-practices-unzipping-on-gateway)
+ [Windows Server からデータをコピーするときにファイル属性を保持する](#best-practices-copying-files-on-windows)
+ [ベストプラクティス: キャッシュディスクの適切なサイズ設定](#proper-sizing-of-cache-disks)
+ [複数のファイル共有と Amazon S3 バケットの使用](#prevent-multiple-writes)
+ [不要なリソースのクリーンアップ](#cleanup-file)
## ベストプラクティス: データの復旧
まれに、ゲートウェイで回復不可能な障害が発生する場合があります。そのような障害は、仮想マシン (VM)、ゲートウェイ自体、ローカルストレージなどの場所で発生する可能性があります。障害が発生した場合、データの回復に関する以下の該当するセクションの手順に従うことをお勧めします。
**重要**
Storage Gateway では、ハイパーバイザーによって作成されたスナップショットから、または Amazon EC2 Amazon マシンイメージ (AMI) からのゲートウェイ VM の復元はサポートされていません。ゲートウェイ VM が正しく機能しない場合、新しいゲートウェイをアクティブ化し、以下の手順を使用してデータをそのゲートウェイに復旧します。
### 予期しない仮想マシンのシャットダウンからの復旧
停電時など、VM が予期せずシャットダウンすると、ゲートウェイにアクセスできなくなります。電源とネットワーク接続が復旧されると、ゲートウェイは到達可能になり、通常の動作を開始します。データを回復するためにその時点で実行可能ないくつかのステップを以下に示します。
+ 停止によりネットワーク接続の問題が発生した場合、問題をトラブルシューティングできます。ネットワーク接続をテストする方法については、「[ゲートウェイのネットワーク接続をテストする](MaintenanceTestGatewayConnectivity-fgw.md)」を参照してください。
### 正しく機能していないキャッシュディスクからのデータの復旧
キャッシュディスクで障害が発生した場合、以下のステップを使用し、状況に応じてデータを復旧することをお勧めします。
+ キャッシュディスクがホストから削除されたために障害が発生した場合は、ゲートウェイをシャットダウンし、ディスクを再追加してゲートウェイを再起動します。
### アクセス不能なデータセンターからのデータの復旧
ゲートウェイまたはデータセンターが何らかの理由でアクセス不能である場合は、異なるデータセンターにある別のゲートウェイにデータを復元するか、Amazon EC2 インスタンスにホストされているゲートウェイに復元することができます。別のデータセンターへのアクセス権がない場合は、Amazon EC2 インスタンスにゲートウェイを作成することをお勧めします。手順は、データ復旧元のゲートウェイの種類によって異なります。
**アクセス不能なデータセンターのファイルゲートウェイからデータを復旧するには**
ファイルゲートウェイの場合、回復したいデータが格納されている Amazon S3 バケット に、新しいをマッピングします。
1. Amazon EC2 ホストで新しいファイルゲートウェイを作成してアクティブ化します。詳細については、「[S3 ファイルゲートウェイ用のデフォルトの Amazon EC2 ホストをデプロイするS3 ファイルゲートウェイ用にカスタマイズされた Amazon EC2 ホストをデプロイする](ec2-gateway-file.md)」を参照してください。
1. 作成した EC2 ゲートウェイに新しいを作成します。詳細については、「[ファイル共有の作成](https://docs.aws.amazon.com/filegateway/latest/files3/GettingStartedCreateFileShare.html)」「」を参照してください。
1. ファイル共有をクライアントにマウントし、復旧するデータが含まれている S3 バケット にこれをマッピングします。詳細については、「[ファイル共有をマウントして使用する](https://docs.aws.amazon.com/filegateway/latest/files3/getting-started-use-fileshare.html)」を参照してください。
## ベストプラクティス: マルチパートアップロードの管理
大きなファイルを転送する場合、S3 ファイルゲートウェイは Amazon S3 マルチパートアップロード特徴量を使用してファイルを小さな部分に分割し、効率を向上させるために並行して転送します。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[マルチパートアップロードを使用したオブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html)」を参照してください。
マルチパートアップロードが何らかの理由で正常に完了しなかった場合、ゲートウェイは通常転送を停止し、Amazon S3 から部分的に転送されたファイルをすべて削除して、転送を再試行します。まれに、ハードウェアまたはネットワーク障害により、マルチパートアップロードが失敗した後にゲートウェイがクリーンアップできない場合、部分的に転送されたファイルの一部が Amazon S3 に残り、ストレージ料金が発生する可能性があります。
不完全なマルチパートアップロードによる Amazon S3 ストレージコストを最小限に抑えるためのベストプラクティスとして、`AbortIncompleteMultipartUpload`API アクションを使用して失敗した転送を自動的に停止し、指定された日数後に関連するファイル部分を削除する Amazon S3 バケットライフサイクルルールの設定を推奨します。手順については、「*Amazon Simple Storage Service ユーザーガイド*」の「[不完全なマルチパートアップロードを削除するためのバケットライフサイクル設定の設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html)」を参照してください。
## ベストプラクティス: ゲートウェイにコピーする前に、圧縮ファイルをローカルで解凍する
ゲートウェイに保存されている間に数千のファイルを含む圧縮アーカイブを解凍しようとすると、パフォーマンス関連の大幅な遅延が発生する可能性があります。任意のタイプのネットワークファイル共有に多数のファイルを含むアーカイブを解凍するプロセスには、本質的に大量の入出力オペレーション、メタデータキャッシュ操作、ネットワークオーバーヘッド、レイテンシーが含まれます。さらに、Storage Gateway はアーカイブの各ファイルがいつ解凍が完了したかを判断できず、プロセスが完了する前にファイルのアップロードを開始できるため、パフォーマンスにさらに影響します。これらの問題は、アーカイブ内のファイルが多数あるが、サイズが小さい場合に複合されます。
ベストプラクティスとして、圧縮アーカイブを解凍する前に、まずゲートウェイからローカルマシンに転送することを推奨します。その後、必要に応じて、*robocopy* や *rsync* などのツールを使用して、解凍したファイルをゲートウェイに転送できます。
## Windows Server からデータをコピーするときにファイル属性を保持する
Microsoft Windows の基本的な `copy` コマンドを使用してファイルゲートウェイにファイルをコピーすることはできますが、このコマンドはデフォルトでファイルデータのみをコピーします。セキュリティ記述子などの特定のファイル属性は省略されます。対応するセキュリティ制限と随意アクセスコントロールリスト (DACL) 情報なしでファイルがゲートウェイにコピーされると、権限のないユーザーによってアクセスされる可能性があります。
Microsoft Windows サーバ でゲートウェイにファイルをコピーするときに、すべてのファイル属性とセキュリティ情報を保存するためのベストプラクティスとして、`robocopy` あるいは `xcopy` コマンドと、`/copy:DS` または `/o` フラグをそれぞれ使用することを推奨します。詳細については、Microsoft Windows Server コマンドリファレンスドキュメントの「[robocopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy)」と「[xcopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy)」を参照してください。
## ベストプラクティス: キャッシュディスクの適切なサイズ設定
最高のパフォーマンスを得るには、キャッシュディスクのサイズをアクティブな作業セットのサイズに合わせる必要があります。読み取り負荷の高いワークロードや読み書きが混在するワークロードにおいては、読み取りに対するキャッシュヒットの割合が高いことが望まれます。これは、S3 ファイルゲートウェイの `CacheHitPercent` メトリクスを使用してモニタリングできます。
書き込みが多いワークロード (バックアップやアーカイブなど) の場合、S3 ファイルゲートウェイは、このデータを Amazon S3 に非同期でコピーする前に、ディスクキャッシュで受信書き込みをバッファします。書き込まれたデータをバッファするのに十分なキャッシュ容量があることを確認する必要があります。`CachePercentDirty` メトリクスは、まだ保持されていないディスクキャッシュの割合を示します AWS。
`CachePercentDirty` の低い値をお勧めします。値が一貫して 100% に近い場合は、S3 ファイルゲートウェイが受信書き込みトラフィックの速度に対応できないことを示します。これを回避するには、プロビジョニングされたディスクキャッシュ容量を増やすか、S3 ファイルゲートウェイから Amazon S3 に利用できる専用ネットワーク帯域幅を増やすか、またはその両方を行います。
キャッシュディスクのサイズ設定の詳細については、Amazon Web Services の公式 YouTube チャンネルの「[Amazon S3 ファイルゲートウェイのキャッシュサイズ設定のベストプラクティス](https://www.youtube.com/watch?v=-ibL1eEcROI)」を参照してください。
## 複数のファイル共有と Amazon S3 バケットの使用
複数のゲートウェイまたはファイル共有に書き込みを許可するように単一の Amazon S3 バケットを設定すると、結果が予測不能になる可能性があります。予期しない結果を避けるために、バケットは 2 つの方法のいずれかで設定できます。以下のオプションから、ユースケースに最適な設定方法を選択します。
+ 各バケットに書き込むことができるファイル共有が 1 つだけになるように S3 バケットを設定します。異なるファイル共有を使用して、各バケットに書き込みます。
これを実現するには、特定のファイル共有で使用されているロール以外のすべてのロールによるバケット内のオブジェクトの追加および削除を拒否する S3 バケットポリシーを作成します。同様のポリシーを各バケットにアタッチし、各バケットに書き込む別のファイル共有を指定します。
次のポリシーの例では、S3 バケットに書き込むバケットを作成するロールを除くすべてのロールを拒否しています。`s3:DeleteObject` および `s3:PutObject` アクションは、`"TestUser"` を除くすべてのロールに対して拒否されます。このポリシーは、`"arn:aws:s3:::amzn-s3-demo-bucket/*"` バケット内のすべてのオブジェクトに適用されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyMultiWrite",
"Effect":"Deny",
"Principal":"*",
"Action":[
"s3:DeleteObject",
"s3:PutObject"
],
"Resource":"arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition":{
"StringNotLike":{
"aws:userid":"TestUser:*"
}
}
}
]
}
```
------
+ 複数のファイル共有を同じ Amazon S3 バケットに書き込む場合は、ファイル共有が同じオブジェクトに同時に書き込もうとしないようにする必要があります。
これを行うには、ファイル共有ごとに個別の一意のオブジェクトプレフィックスを設定します。つまり、各ファイル共有は対応するプレフィックスを持つオブジェクトにのみ書き込み、デプロイ内の他のファイル共有に関連付けられているオブジェクトには書き込みません。新しいファイル共有を作成するときに、**S3 プレフィックス名**フィールドでオブジェクトプレフィックスを設定します。
## 不要なリソースのクリーンアップ
ベストプラクティスとして、予期しない料金や不要な料金が発生しないように、Storage Gateway リソースのクリーンアップを推奨します。たとえば、デモンストレーション演習やテストとしてゲートウェイを作成した場合は、デプロイからゲートウェイとその仮想アプライアンスを削除することを検討してください。リソースをクリーンアップするには、次の手順に従います。
**不要なリソースをクリーンアップする**
1. ゲートウェイの使用を継続する予定がない場合は、ゲートウェイを削除します。詳細については、「[ゲートウェイおよび関連リソースの削除](deleting-gateway-common.md)」を参照してください。
1. オンプレミスホストから Storage Gateway VM を削除します。Amazon EC2 インスタンスにゲートウェイを作成した場合、インスタンスを終了します。