FAQ: オートメーション

Cloud Manager はどのバージョンの MongoDB を管理しますか?

特定の Cloud Manager 機能とサポートされている MongoDB のバージョンについては、 MongoDB 互換性マトリクス を参照してください。

Cloud Manager は MongoDB 配置をどのように管理しますか。

Cloud Manager でサーバーをプロビジョニングするか、MongoDB 配置の環境にエージェントを配置すると、各エージェントは定期的に Cloud Manager と通信して必要な作業を実行します。

エージェントは、必要に応じて作業を調整するために環境を常に再利用します。 このルーチン アクティビティの一部として、エージェントはクラスター ノードへの頻繁に短時間の接続を確立します。 ネットワーク接続の問題や Cloud Manager の障害など、エージェントが問題に発生した場合、エージェントは作業を調整して埋め込み、安全に目的の状態に到達します。

エージェントは、現在の状態から目的の状態に移行するためのプランを作成します。 プランは手順に従って実行されます。各ステップは独立して他のステップから独立しています。

Cloud Manager はクラスター ノードのメンテナンスをどのように実行しますか。

Cloud Manager は、クラスター内のノードのメンテナンスを実行すると、ローリング再起動を実行します。 エージェントは、メンテナンス期間中にすべてのノードがアップデートされ、クラスターの可用性が維持されるまで、クラスター内のノードを 1 つずつ更新し、常にプライマリ ノードを維持します。

クラスター内の各セカンダリ ノードに対して、エージェントは次の操作を行います。

1. ノード上で実行中の mongodプロセスをstandaloneモードで再起動します。

2. メンテナンス タスクを実行します。

3. ノード上で実行中のmongodプロセスをreplSetモードで再起動します。

セカンダリ ノードが更新されると、 エージェントは次のことを行います。

1. rs.stepDown()コマンドを使用してプライマリを降格します。

2. 新しいプライマリ ノードの選挙をトリガーします。

3. 以前のプライマリ ノードでメンテナンス タスクを実行します。

4. 以前のプライマリ ノードで実行されていたmongodプロセスをreplSetモードで再起動し、クラスターをセカンダリ ノードとして参加させます。

Cloud Manager では、エージェントはメンテナンス タスクのためにクラスター ノードのローリング再起動を実行します。これには次のものが含まれます。

• KMIPキーをローテーションします。

• キーファイルのローテーション。

• mongod構成引数の変更

• TLS 、 auth 、またはclusterAuthモードをアップグレードまたはダウングレードします。

• MongoDB のバージョンの変更。

• oplog サイズの変更。

• レプリカセットからプロセスを削除します。

• バックアップからの復元をキャンセルします。

• プロファイラーの有効化

必要なエージェントの数

オートメーションを使用するには、管理対象の MongoDB インスタンスが実行されるすべてのホストで実行されているエージェントが必要です。

エージェントによって転送される MongoDB データはありますか？

エージェントは、MongoDB デプロイからデータ レコードを送信しません。 エージェントは配置構成情報と MongoDB ログのみを通信します。

Cloud Manager はアップグレード中に失敗を処理しますか。

一般的には、はい。 Cloud Manager のマネジメントとオートメーションのコンポーネントの設計は、可能性のあるすべての障害を考慮するものではありません。ただし、システムのアーキテクチャは多くのタイプの障害に回避できます。

Cloud Manager ではどのようなタイプの配置を作成できますか。

Cloud Manager を使用すると、シャーディングされたクラスター、レプリカセット、スタンドアロンなど、すべての MongoDB 配置タイプを構成できます。

シャーディングされたクラスター内のシャードはレプリカセットである必要があります。 つまり、シャードはスタンドアロンmongodになることはできません。 シャードを単一のmongodとして実行する必要がある場合（冗長性またはフェイルオーバーを提供しない）は、シャードを単一ノードのレプリカセットとして実行します。