ONTAP SnapMirror S3について学ぶ
変更を提案
PDF
ONTAP 9.10.1以降では、SnapMirrorのミラーリングとバックアップの機能を使用してONTAP S3オブジェクト ストアのバケットを保護できます。標準のSnapMirrorとは異なり、SnapMirror S3を使うと、AWS S3などのNetApp以外のデスティネーションへのミラーリングとバックアップができます。
SnapMirror S3では、ONTAP S3バケットから次のデスティネーションへのアクティブなミラーとバックアップをサポートしています。
| ターゲット | アクティブなミラーとテイクオーバーのサポート | バックアップとリストアのサポート |
|---|---|---|
ONTAP S3
|
はい |
はい |
StorageGRID |
いいえ |
はい |
AWS S3 |
いいえ |
はい |
Cloud Volumes ONTAP for Azure |
はい |
はい |
Cloud Volumes ONTAP for AWS |
はい |
はい |
Cloud Volumes ONTAP for Google Cloud |
はい |
はい |
ONTAP S3サーバ上の既存のバケットを保護することも、新しく作成したバケットですぐにデータ保護を有効にすることもできます。
SnapMirror S3の要件
-
ONTAPのバージョン
ソースとデスティネーションのクラスタでONTAP 9.10.1以降が実行されている必要があります。
SnapMirror S3はMetroCluster構成ではサポートされていません。 -
ライセンス
"ONTAP One"ソフトウェア スイートで利用可能な次のライセンスは、ONTAPソース システムとデスティネーション システムで次の項目へのアクセスを提供するために必要です：
-
ONTAP S3プロトコルおよびストレージ
-
SnapMirror S3：NetAppの他のオブジェクト ストア（ONTAP S3、StorageGRID、Cloud Volumes ONTAP）をターゲットにするため
-
SnapMirror S3からAWS S3（"ONTAP One互換性バンドル"で利用可能）を含むサードパーティのオブジェクト ストアへ
-
クラスタでONTAP 9.10.1を実行している場合は、"FabricPoolライセンス"が必要です。
-
-
ONTAP S3
-
ソースとデスティネーションのSVMでONTAP S3サーバが実行されている必要があります。
-
TLSアクセス用のCA証明書はS3サーバをホストするシステムにインストールすることを推奨しますが、必須ではありません。
-
S3サーバの証明書への署名に使用されたCA証明書を、S3サーバをホストするクラスタの管理Storage VMにインストールする必要があります。
-
自己署名CA証明書または外部CAベンダーが署名した証明書を使用できます。
-
ソースまたはデスティネーションのStorage VMがHTTPSをリスンしていない場合、CA証明書をインストールする必要はありません。
-
-
-
ピアリング（ONTAP S3ターゲットの場合）
-
クラスタ間LIFが設定されている必要があります（リモートのONTAPターゲットの場合）。ソース クラスタとデスティネーション クラスタのクラスタ間LIFは、ソースとデスティネーションのS3サーバのデータLIFに接続できます。
-
ソースとデスティネーションのクラスタがピアリングされている必要があります（リモートのONTAPターゲットの場合）。
-
ソースとデスティネーションのStorage VMがピアリングされている必要があります（すべてのONTAPターゲットで必須）。
-
-
SnapMirrorポリシー
-
すべてのSnapMirror S3関係にS3固有のSnapMirrorポリシーが必要ですが、複数の関係に同じポリシーを使用することができます。
-
独自のポリシーを作成することも、次の値を含むデフォルトの Continuous ポリシーを受け入れることもできます：
-
スロットル（スループット / 帯域幅の上限）：無制限。
-
回復ポイント目標の時間：1時間（3600秒）。
-
-
|
|
2つのS3バケットがSnapMirror関係にある場合、現バージョンのオブジェクトの有効期限を定めた（削除するための）ライフサイクル ポリシーが存在すると、パートナー バケットにも同様の処理がレプリケートされることに注意してください。これは、パートナー バケットが読み取り専用またはパッシブである場合も同様です。 |
-
ルート ユーザ キー Storage VMルート ユーザ アクセス キーはSnapMirror S3関係に必要です。ONTAPではデフォルトで割り当てられません。SnapMirror S3関係を初めて作成する際は、ソースとデスティネーションの両方のStorage VMにキーが存在することを確認し、存在しない場合は再生成する必要があります。再生成が必要な場合は、アクセス キーとシークレット キーのペアを使用しているすべてのクライアントとすべてのSnapMirrorオブジェクト ストア設定が新しいキーで更新されていることを確認する必要があります。
S3サーバの設定については、次のトピックを参照してください。
クラスタおよびStorage VMのピアリングについては、次のトピックを参照してください。
サポートされるSnapMirror関係
SnapMirror S3はファンアウトとカスケード関係をサポートしています。概要については、"ファンアウト構成およびカスケード構成のデータ保護"をご覧ください。
SnapMirror S3では、ファンイン構成（複数のソース バケットと1つのデスティネーション バケットの間のデータ保護関係）はサポートされません。SnapMirror S3では、複数のクラスタから単一のセカンダリ クラスタへの複数のバケットのミラーはサポートされますが、各ソース バケットに対応する独自のデスティネーション バケットがセカンダリ クラスタに必要です。
SnapMirror S3はMetroCluster環境ではサポートされていません。
S3バケットへのアクセスの制御
新しいバケットを作成する際、ユーザとグループを作成してアクセスを制御できます。
SnapMirror S3 はソース バケットからデスティネーション バケットにオブジェクトを複製しますが、ソース オブジェクト ストアからデスティネーション オブジェクト ストアにユーザー、グループ、およびポリシーを複製しません。
フェイルオーバー イベント中にクライアントがデスティネーション バケットにアクセスできるように、ユーザー、グループ ポリシー、権限、および同様のコンポーネントをデスティネーション オブジェクト ストアで構成する必要があります。
移行元ユーザーと移行先ユーザーは、デスティネーション クラスタでユーザーが作成されるときに移行元キーが手動で提供される場合、同じアクセス キーとシークレット キーを使用できます。例：
vserver object-store-server user create -vserver svm1 -user user1 -access-key "20-characters" -secret-key "40-characters"
詳細については、次のトピックを参照してください。
S3 オブジェクトロックとSnapMirror S3によるバージョン管理を使用する
オブジェクト ロックとバージョン管理が有効になっているONTAPバケットでSnapMirror S3を使用できますが、いくつかの考慮事項があります：
-
Object Lockが有効になっているソースバケットをレプリケートするには、デスティネーションバケットでもObject Lockが有効になっている必要があります。さらに、ソースとデスティネーションの両方でバージョン管理が有効になっている必要があります。これにより、両方のバケットのデフォルトの保持ポリシーが異なる場合に、削除がデスティネーションバケットにミラーリングされる問題を回避できます。
-
S3 SnapMirrorはオブジェクトの過去のバージョンをレプリケートしません。オブジェクトの現在のバージョンのみがレプリケートされます。
オブジェクトロックされたオブジェクトが宛先バケットにミラーリングされると、元の保持期間が維持されます。ロックされていないオブジェクトが複製された場合は、宛先バケットのデフォルトの保持期間が適用されます。例：
-
バケットAのデフォルトの保持期間は30日間、バケットBのデフォルトの保持期間は60日間です。バケットAからバケットBに複製されたオブジェクトは、バケットBのデフォルトの保持期間よりも短いにもかかわらず、30日間の保持期間を維持します。
-
バケットAにはデフォルトの保持期間がなく、バケットBにはデフォルトの保持期間が60日間あります。ロック解除されたオブジェクトがバケットAからバケットBに複製されると、60日間の保持期間が適用されます。バケットAでオブジェクトが手動でロックされた場合、バケットBに複製される際に元の保持期間が維持されます。
-
バケットAのデフォルトの保持期間は30日間ですが、バケットBにはデフォルトの保持期間がありません。バケットAからバケットBに複製されたオブジェクトは、30日間の保持期間を維持します。