S3 バックアップへの直接バックアップを有効にすると、 MongoDBエージェントは、Ops Manager が提供する事前署名された URL を使用して、スナップショット ブロックを S3 に直接アップロードします。 Ops Manager は、事前に署名された URL の生成、ブロックマニフェストの追跡、完了のシグナル送信など、アップロードのメタデータのみを処理します。スナップショット データ パスは Ops Manager をバイパスし、Ops Managerサーバーを通過しなくなりました。これにより、大規模な配置や頻繁なバックアップスケジュールのプロキシ ボトルネックが排除されます。
このトピックでは、S3 バックアップへの直接バックアップを有効にする方法と、そのオプション設定を構成する方法について説明します。
重要
S3 バックアップには、Ops Manager 9.0.0 以降、または Ops Manager 8.0.27 以降、およびバックアップを実行するすべてのホスト上のMongoDB Agent の最小バージョンが必要です。
MongoDB Ops Managerバージョン | MongoDB Agent の最小バージョン |
|---|---|
9.0 |
|
8.0 |
|
S3 バックアップへの直接接続方法
バックアップジョブで S3 バックアップへの直接アクセスが有効になっており、配置上のMongoDB Agent が最小バージョン要件を満たしている場合、Ops Manager は次のアクションを実行します。
Ops Manager は、 スナップショットブロックストア用に構成された S3 認証情報を使用して、事前に署名されたアップロード URL を生成します。 URL は、ブロックストアが使用するのと同じ S3バケットを点。
MongoDB Ops Manager はバックアップカーソルの説明 に
uploadPath=AGENT_DIRECT_S3を設定します。 MongoDB Agent はこの値を読み取り、ジョブのアップロード パスを固定し、スナップショット ブロックを S3 に直接アップロードします。Ops Manager は、 ブロックマニフェスト API を通じてアップロードの完了を追跡します。
/dataBlocksプロキシ アップロード呼び出しは発生しません。
MongoDB Agent がスナップショット データを S3 に直接アップロードするため、Ops Manager はバックアップのデータ パスに存在しなくなります。 Ops Manager は、バックアップメタデータのみを担当します。
共存とフォールバック
S3 バックアップと Ops Manager を介してデータをストリーミングする標準バックアップは混在できます。
S3 バックアップへの直接バックアップを有効にするジョブでは、 MongoDB Agent のバージョンが最小値を下回ると、Ops Manager は標準パスにフォールバックします。フォールバックはMongoDB Agent をアップグレードするまで残ります。混合バージョンのフリートは引き続き正常にバックアップされます。
バージョン要件を満たす配置では、 S3 バックアップへの直接使用が使用されます。
バージョン要件を満たさない配置では、標準データ パスが使用されます。 MongoDB Agent をアップグレードすると、ジョブは最初のスナップショットで S3 バックアップに自動的に切り替わり、それ以上のアクションは必要ありません。すでに進行中のスナップショットは、元のアップロード パスで完了します。
さらに、以下に説明するように、ジョブの S3 バックアップへの直接バックアップを手動で有効または無効にすることができます。
注意
S3 バックアップへの直接接続は、スナップショット ブロック データにのみ適用されます。ポイントインタイムリカバリ用の oplog データでは、構成されたoplogストアを通じて標準バックアップパスを引き続き使用します。
前提条件
Direct to S3 Backup を有効にする前に、以下を実行します。
Ops Manager 9.0.0 以降、または Ops Manager 8.0.27 以降を実行中いることを確認してください。
配置に S3 読み取り（ブロックストア）があることを確認します。 Ops Manager は、ブロックストアが使用するのと同じ S3 バケットと認証情報を使用します。
バックアップ ホスト ネットワーク アクセス
バックアップを実行する各ホストは、次の条件を満たす必要があります。
S3 または S3 互換エンドポイントとなる接続されたデバイスの DNS 名を解決する
そのエンドポイントとなる接続されたデバイスへのアウトバウンド HTTPS 接続を確立します
Ops Manager が生成する S3 事前署名付き URL を使用してデータをアップロードする
S3 バックアップへの直接バックアップを有効にすると、大容量のアップロード パスは Ops ManagerアプリケーションサーバーからMongoDB Agent を実行するすべてのホストに移動されます。以前は、Ops Manager サーバーのみが S3 へのネットワーク アクセスを必要としていました。機能を有効にする前に、バックアップホストから S3 エンドポイントへのアウトバウンド接続を検証してください。
MongoDBエージェントには S3 アクセス キーまたは IAM ロールは必要ありません。 Ops Manager は、読み取り用に構成された S3 認証情報を使用して、すべての事前署名付き URL を生成します。これらの認証情報では、読み取りのみではなく、バケットで事前に署名されたPUT 操作を許可する必要があります。
S3 バックアップへのダイレクトの有効化
S3 バックアップへの直接バックアップを有効にするには、次の手順を実行します。
Direct to S3 Backup 機能フラグを有効にします。
MongoDB Ops Manager Admin コンソールで、General と Ops Manager Config をクリックします。
[Custom] タブをクリックします。
次のキーと値のペアのいずれかを追加して、グローバル レベルまたはプロジェクトレベルで S3 バックアップへの直接バックアップを有効にします。
アクセス レベルキー値プロジェクト
mms.featureFlag.backup.d2s3controlledグローバル
mms.featureFlag.backup.d2s3enabled[Save] をクリックします。
（条件付き）プロジェクトで S3 バックアップへの直接接続を有効にします。
前の手順で フラグを controlled に設定した場合は、プロジェクト設定 で機能を有効にします。
MongoDB Ops Managerプロジェクトで、Settings をクリックします。
[Beta Featuresタブ]をクリックし、Backup D2s3 をクリックします。
（条件付き）既存のバックアップジョブで S3 バックアップへのダイレクトを有効にします。
S3 バックアップへのダイレクトを有効にしたプロジェクトでは、S3 バックアップへのダイレクトはすでに有効になっている状態で新しいバックアップジョブが開始されます。新しい各ジョブの最初のスナップショットは S3 に直接アップロードされるため、ジョブごとのアクションは必要ありません。
機能を有効にする前に存在していたバックアップ ジョブは、既存の 設定を維持します。任意のジョブで S3 バックアップへの直接バックアップを有効または無効にすることもできます。ジョブの 設定を変更するには以下を行います。
[Admin、Backup、Jobs をクリックします。
ターゲットジョブで、Direct S3 Backup 行を見つけます。行は、ジョブの読み取りが S3ブロックストアである場合にのみ表示されます。
Direct S3 Backup を Enabled または Disabled に設定します。
シャーディングされたクラスターの場合は、すべてのシャードとコンフィギュレーションサーバーで機能を有効にするには、Apply to all cluster members を選択します。
[Save] をクリックします。
次の表は、バックアップジョブがS3 バックアップに直接使用するタイミングをまとめたものです。
Scenario | アップロード パス |
|---|---|
プロジェクトで機能を有効にした後に作成されたジョブ | 最初のスナップショットから S3 バックアップに直接 |
プロジェクトで機能を有効にする前に作成されたジョブ | ジョブで S3 バックアップを有効にするまでの標準パス |
Direct to S3 Backup が有効になっており、 MongoDB Agent が最小バージョン未満のジョブ | MongoDB Agent をアップグレードするまでの標準パス。アップグレード後の最初のスナップショットで、ジョブは S3 バックアップに指示されます。 |
オプション設定の管理
次のオプション設定は、S3バックアップへのアップロードパフォーマンスを直接調整します。
mms.backup.d2s3.transfer.numWorkersMongoDB Agent が S3 バックアップへの直接アップロードに使用する並列アップロード ワーカーの数。デフォルト:
2。ジョブごとの上書きを設定することもできます。この設定は、Ops Manager の構成ファイルで他の
mms.backup.*プロパティと一緒に構成します。このプロパティを に設定すると、 MongoDB Agent はその正確な数のワーカーを使用し、独自の自動調整をスキップします。設定されていない場合、 MongoDB Agent はホストの CPU とメモリに基づいてワーカー数をサイズ設定します。mms.backup.d2s3.transfer.maxNumUnitOfWorkBlocksS3 への Direct へのアップロード パスのワーク ユニットあたりの最大ブロック数。設定されていない場合、 MongoDB Agent は内部デフォルトの
100にフォールバックします。次のいずれかを使用してこの設定を構成します。
Ops Manager インターフェースで、グローバル Ops Manager 構成設定を適用します。
注意
S3 への同時接続数は、同時に実行されるバックアップジョブの数に応じて増加します。配置で多くのバックアップジョブが同時に実行されている場合、S3 接続の合計数が高くなる可能性があります。
操作上の考慮事項
パフォーマンスとサイズ設定
Ops Manager 負荷: Ops Managerアプリケーションサーバーはスナップショット ブロック ペイロードを実行しなくなりましたが、事前署名、マニフェスト検証、ジョブ状態、メタデータ書込みは引き続き処理されます。コントロールプレーン ワークロードの Ops Manager のサイズ変更。
エージェント ホストのサイジング: S3 バックアップは、圧縮、ハッシュ、TLS、および並列 S アップロードを3 Ops Manager サーバーからMongoDB Agent を実行する各ホストに移動します。機能を有効にする前に、これらのホストに追加のワークロードに十分な CPU、メモリ、およびアウトバウンド ネットワークキャパシティーがあることを確認してください。ベースライン スナップショットの期間とリソース使用量を取得することで、 S3 への Direct を有効にした後の影響を比較できます。
mms.backup.d2s3.transfer.numWorkersが設定されていない場合、 MongoDB Agent は、ホストの使用が許可されている CPU とメモリに基づいて、バックアップワーカーの数を自動的にサイズ設定します。その権限の 4 vCPU ごとに約 1 つのワーカーから開始され、最大 16 ワーカーまで提供されます。各ワーカーはピーク時に約 1 つの CPU コアを使用できるため、バックアップ用にホストの許可された CPUキャパシティーの少なくとも 25% を保持するように計画します。スナップショット中に、 MongoDB Agent CPU 使用率とデータベースレイテンシを監視します。 MongoDB Agent が CPU バウンドであるか、データベースレイテンシが増加する場合は、キャパシティーを追加するか、
numWorkersを減らすことを検討してください。
ネットワーク パス:バックアップスループットの合計は、 MongoDB Agent3 から S へのすべてのパスの集計です。 S3 エンドポイント、 VPCエンドポイント、またはプロキシが、同時にバックアップされるすべてのホストで期待される同時実行性を処理できることを確認します。
セキュリティと IAM
Ops Manager 権限:読み取り用に構成された S3
PUT認証情報では、スナップショットに使用されるバケットとプレフィックスに対する事前署名付き 操作を許可する必要があります。MongoDB Agent の権限: MongoDB Agent には S3 認証情報がありません。 MongoDB Ops Manager は、すべてのブロックのアップロードと検証に対して署名付き URL を生成します。
不変性: S3 バックアップへの直接接続は S3 オブジェクト ロックと互換性があります。不変のスナップショットに必要なオブジェクト バージョン ID は、 ブロックマニフェスト に記録されます。
詳細
復元中に S からスナップショット データを直接ダウンロードするコンフィギュレーション機能の詳細については、「3 S3 復元からの直接 」を参照してください。
Ops Manager でのバックアップの仕組みについては、「 バックアップ プロセス 」を参照してください。
必要なバックアップ リソースの詳細については、「 S3 互換スナップショット ストレージの管理 」を参照してください。