FAQ: オートメーション
項目一覧
- はどのバージョンのMongoDB MongoDB Ops Managerを管理しますか?
- MongoDB Ops Managerバージョン 1.8.x および 2.0.x のアップグレード パス
- MongoDB Ops ManagerはMongoDB配置をどのように管理しますか。
- MongoDB Ops Managerはクラスター ノードのメンテナンスをどのように実行しますか。
- 必要なオートメーションの数
- エージェントによって転送される MongoDB データはありますか？
- MongoDB Ops Managerはアップグレード中に失敗を処理しますか。
- MongoDB Ops Managerではどのようなタイプの配置を作成できますか。
以下では、 MongoDB Ops Managerとそのオートメーション機能に関するよくある質問に対処します。
MongoDB Ops Managerは、監視対象の プロセスの管理操作を自動化でき、MongoDB MongoDBMongoDB Ops Managerインターフェースを通じて の再構成、停止、再起動が可能になります。
MongoDB Ops Manager Automation は 64 ビットのアーキテクチャでのみ実行できます。
はどのバージョンのMongoDB MongoDB Ops Managerを管理しますか?
特定のMongoDB Ops Manager関数とサポートされているMongoDBのバージョンについては、 MongoDB互換性マトリクス を参照してください。
MongoDB Ops Managerバージョン 1.8.x および 2.0.x のアップグレード パス
アップグレード パスについては、「 MongoDB Ops Managerのアップグレード 」を参照してください。
MongoDB Ops ManagerはMongoDB配置をどのように管理しますか。
MongoDB デプロイメントの環境にエージェントを配置すると、各エージェントは MongoDB Ops Manager と定期的に通信して必要な作業を実行します。
エージェントは、必要に応じて作業を調整するために環境を常に再利用します。 このルーチン アクティビティの一部として、エージェントはクラスター ノードへの頻繁に短時間の接続を確立します。 ネットワーク接続の問題や Ops Manager の障害など、エージェントが問題に発生した場合、エージェントは作業を調整して埋め込み、安全に目的の状態に到達します。
エージェントは、現在の状態から目的の状態に移行するためのプランを作成します。 プランは手順に従って実行されます。各ステップは独立して他のステップから独立しています。
例
インストールの場合、プランには MongoDB のダウンロード、適切なコマンドライン オプションでプロセスの開始、レプリカセットの初期化、正常な過半数の待機が含まれます。 レプリカセットがアクティブで、正常な過半数がある場合、構成は目的の状態に達します。
MongoDB Ops Managerはクラスター ノードのメンテナンスをどのように実行しますか。
クラスター内のノードのメンテナンスを実行すると、MongoDB Ops Manager はローリング再起動を実行します。 エージェントは、メンテナンス期間中にすべてのノードがアップデートされ、クラスターの可用性が維持されるまで、クラスター内のノードを 1 つずつ更新し、常にプライマリ ノードを維持します。
クラスター内の各セカンダリ ノードに対して、エージェントは次の操作を行います。
セカンダリ ノードが更新されると、 エージェントは次のことを行います。
rs.stepDown()コマンドを使用してプライマリを降格します。
新しいプライマリ ノードの選挙をトリガーします。
以前のプライマリ ノードでメンテナンス タスクを実行します。
以前のプライマリ ノードで実行されていた
mongodプロセスをreplSetモードで再起動し、クラスターをセカンダリ ノードとして参加させます。
MongoDB Ops Managerでは、エージェントは、次のようなメンテナンス タスクのためにクラスター ノードでローリング再起動を実行します。
KMIPキーをローテーションします。
キーファイルのローテーション。
mongod構成引数の変更TLS 、
auth、またはclusterAuthモードをアップグレードまたはダウングレードします。MongoDB のバージョンの変更。
oplog サイズの変更。
レプリカセットからプロセスを削除します。
バックアップからの復元をキャンセルします。
プロファイラーの有効化
必要なオートメーションの数
オートメーションを使用するには、管理対象の MongoDB インスタンスが実行されるすべてのホストで実行されているエージェントが必要です。
エージェントによって転送される MongoDB データはありますか？
エージェントは、MongoDB デプロイからデータ レコードを送信しません。 エージェントは配置構成情報と MongoDB ログのみを通信します。
MongoDB Ops Managerはアップグレード中に失敗を処理しますか。
一般的には、はい。 MongoDB Ops Managerのマネジメントとオートメーションのコンポーネントの設計は、すべての障害を考慮するものではありません。ただし、システムのアーキテクチャは多くのタイプの障害に回避できます。
MongoDB Ops Managerではどのようなタイプの配置を作成できますか。
MongoDB Ops Managerを使用すると、シャーディングされたクラスター、レプリカセット、スタンドアロンなど、すべてのMongoDB配置タイプを構成できます。
シャーディングされたクラスター内のシャードはレプリカセットである必要があります。 つまり、シャードはスタンドアロンmongodになることはできません。 シャードを単一のmongodとして実行する必要がある場合（冗長性またはフェイルオーバーを提供しない）は、シャードを単一ノードのレプリカセットとして実行します。
注意
配置でミラーリングされたmongodインスタンスがコンフィギュレーションサーバーとして使用されている場合は、シャーディングされた MongoDB 配置をバージョン3.4にアップグレードすることはできません。 シャーディングされた配置をアップグレードできるようにするには、「 コンフィギュレーションサーバーをレプリカセットに変換する」を参照してください。 変換には、シャーディングされた配置で MongoDB バージョン3.2.4以降を実行する必要があります。 以前のバージョンを実行している配置は、バージョン3にアップグレードする必要があります。 2 。 4 バージョン3へのアップグレードの前に。 4 。