Docs Menu
Docs Home
/
MongoDB Ops Manager
/
トラブルシューティング

オートメーション

項目一覧

  • オートメーションは 64 ビットのアーキテクチャでのみ実行
  • 独自のハードウェアの使用
  • ネットワーキング
  • オートメーション構成
  • サイズ設定
  • 頻繁に接続タイムアウトを行う
  • 配置
  • MongoDB Agent の権限
  • 問題のある MongoDB ホストの排除
  • TLS 証明書にサブジェクト代替名が含まれていることを確認する
  • 既存のクラスターのメモリに構成ファイルを保存する

MongoDB Ops ManagerAutomationMongoDB を使用すると、MongoDB Ops Manager UI を使用して 配置を配置、構成、および管理できます。MongoDB Ops Manager Automation はMongoDB Agentに依存します。このエージェントは、配置内のすべてのサーバーにインストールする必要があります。 MongoDB エージェントは MongoDB Ops Manager サービスを定期的にポーリングして現在のターゲットを決定し、そのステータスを MongoDB Ops Manager に継続的に報告します。

オートメーションは 64 ビットのアーキテクチャでのみ実行

MongoDB Ops Managerでは、 MongoDB Agentの 64 ビットダウンロードのみを提供します。

独自のハードウェアの使用

  • オートメーションを手動で配置する場合は、すべてのサーバー上に 1 つの MongoDB Agent があることを確認してください。

  • エージェントを手動で配置する場合は、MongoDB の dbPathと MongoDB バイナリのディレクトリを作成し、 エージェントを実行するユーザーがこれらのディレクトリを所有するようにする必要があります。

    rpmパッケージを使用してインストールすると、エージェントはmongodユーザーとして実行されます。 debパッケージを使用する場合、エージェントはmongodbユーザーとして実行されます。 tar.gzアーカイブ ファイルを使用してインストールする場合は、任意のユーザーとしてエージェントを実行できます。

ネットワーキング

MongoDB ポートへの接続

すべてのホストは MongoDB ポート間の通信を許可できる必要があります。 デフォルトは 27017 ですが、 MongoDB Ops Managerインターフェースで代替のポート範囲を構成できます。

MongoDB Agent 8080は、ポート （ HTTP ）またはポート8443 （ HTTPS ）で MongoDB Ops Manager に接続できる 必要 があります。ポートと IP アドレスへのアクセスの詳細については、 セキュリティの概要 を参照してください。

クラスター内接続の問題

ローリング更新を実行する場合、MongoDB Agent はダウンタイムを回避しようとします。 クラスターの他のノードから状態を収集する必要があります。 A connectivity issue (between mongods and mongoses), such as hostname resolution or misconfigured firewall, may prevent the MongoDB Agent from determining the remote processes state and completing the change.

クラスターのすべてのノードが相互に通信できるようにするには、次の操作を実行します。

  1. シャーディングされていないクラスターの場合：

    1. 各mongodにログインします。

    2. そのmongodホストから、レプリカセットの他のすべてのメンバーにログインします。

  2. シャーディングされたクラスターの場合：

    1. 各mongodにログインします。

    2. そのmongodホストから、シャードの他のすべてのノードにログインします。

    3. 各mongosにログインします。

    4. そのmongosホストは、次の操作を実行します。

      1. 他のmongosホストにログインします。

      2. 各シャードの他のすべてのノードにログインします。

頻繁にオートメーション接続を行う

MongoDB Agent は、クラスターの各ノードから 10 秒ごとに状態を収集し、環境が期待どおりの状態になることを確認します。 この評価の一部として、MongoDB Agent は接続を作成し、特定のファイルをチェックして状態を判断し、接続を閉じます。 このような頻繁で短時間の接続は MongoDB Agent のルーチン アクティビティの一部であり、パフォーマンスには影響しません。

オートメーション構成

自動化構成が完了したら、配置プランが配置のニーズを満たしていることを確認します。 配置を確認する前に、ホスト名とポートを確認してください。

サイズ設定

  • MongoDB を実行し、データセットの要件をサポートするのに十分なスペースのあるホストをプロビジョニングすることを確認します。

  • 配置を実行するのに十分な数のホストをプロビジョニングしたことを確認します。 各mongodは独自のホスト上で実行する必要があります。

頻繁に接続タイムアウトを行う

MongoDB Agent は、次の 1 つ以上の理由で、接続を頻繁にタイムアウトすることがあります。

  • 接続タイムアウト

  • 高ネットワーク レイテンシ

  • 高負荷

  • 大きな SSL キー

  • CPU 速度が不十分

デフォルトでは、接続は 40 秒後にタイムアウトします。 MongoDB では、接続タイムアウトが頻繁に発生するのを防ぐために、 dialTimeoutSeconds MongoDB Agent の構成設定の値を徐々に増やしていくことをお勧めします。 ただし、この値を増やすと、将来の構成変更の配置に必要な時間も長くなります。 配置に最適な値を決定するまで、小さなインクリメンタル 増加 を試してください。

詳しくは、MongoDB Agent 接続設定のdialTimeoutSecondsを参照してください。

配置

特定の条件が適用されると、 We have detected a potential problem while deploying...を表示するバナーが表示されます。 以下はその例です。

配置の変更が完了できない、または進行しない

配置を追加または再起動し、配置が数分間In Progress状態のままの場合、バナーが表示されます。

この時点で、次の 4 つのオプションがあります。

  1. [View Diagnostics] をクリックします。

    View Diagnosticsモーダルには、デプロイ中に発生した可能性のあるエラーが表示されます。

  2. [View Status] をクリックします。

    Automation Statusモーダルには、配置プロセス、配置ステータス、完了しようとするタスク、配置ステータスが最後に報告された日時の配置プロセスが表示されます。 次の方法で結果をフィルタリングできます。

    • Filter processes検索バーにホスト名を入力します。

    • Process Typeドロップダウンから 1 つ以上のプロセスタイプを選択します。

    • Automation Stateドロップダウンから 1 つ以上のオートメーション状態を選択します。

    個々のプロセスのステータスの詳細については、省略記号アイコンをクリックし、 View DetailsまたはView Agent Logsのいずれかを選択します。

    • View Details は、プロセスのどの配置プランであり、MongoDB Agent が現在そのプランのどのステージにあるかを示します。

    • View Agent Logs 新しいブラウザ ウィンドウが開きますDeployment > Agents > Agent Logs画面が表示され、MongoDB Agent ログの内容がデフォルトで表示されます。 別のエージェント ログを選択するには、 Viewメニューをクリックします。

  3. [View Agent Logs] をクリックします。

    新しいブラウザ ウィンドウが開き、 Deployment > Agents > Agent Logs画面が表示され、MongoDB Agent ログの内容がデフォルトで表示されます。 別のエージェント ログを選択するには、 Viewメニューをクリックします。

  4. [Allow Override & Edit Configuration] をクリックします。

    エラーを診断し、配置構成を修正する必要がある場合は、配置を編集する手順に従ってください。

配置をシャットダウンしても解決策が見つからない場合は、 から 配置を削除してMongoDB Ops Manager ください。

MongoDB エージェントがダウンしているか通信していない

MongoDB Agentのオートメーション モジュールがMongoDB Ops ManagerアプリケーションAPI endpointまたはMongoDB Serverプロセスと通信できない場合、 MongoDB Ops Managerはプロジェクトに警告バナーを表示します。 これは、MongoDB エージェントが通信することが予想されているかどうかに応じて、2 つの方法のいずれかで解決できます。

MongoDB エージェントは通信する必要があります

MongoDB AgentがMongoDB Ops ManagerホストまたはMongoDBインスタンスと通信する必要がある場合は、各MongoDB Agentについて次の点を確認します。

  1. エージェントが各ホスト上で稼働中であること。

  2. エージェントとMongoDB Ops Manager Application APIエンドポイントは通信できます。

MongoDB エージェントは通信する必要はありません

MongoDB Agentのオートメーション モジュールがMongoDB Ops ManagerアプリケーションAPI endpointまたはMongoDB Serverプロセスと通信する必要がある場合は、 MongoDB Serverの自動配置ごとに次の点を確認します。

  1. 警告バナー内のAllow Editing & Override Current Configurationリンクをクリックします。

  2. 不要な MongoDB エージェントを提供するホストで実行されているすべてのプロセス（ mongodとmongos ）を削除します。

MongoDB Agent の権限

権限の問題により、オートメーションによる変更が完了しない可能性があります。 または View StatusView Diagnosticsが権限関連のエラー（open /data/db/mongod.lock: permission denied など）を報告した場合は、MongoDB Agent ユーザーが ファイルとdbpathlogpath ファイルを所有し、読み取りおよび書込み権限があることを確認します。

問題のある MongoDB ホストの排除

コンソールまたはAPIを使用して、古くなった、壊れた、または問題のあるホストをオートメーションから排除できます。 これには、 MongoDB Agent にアクセスできない環境が含まれる場合があります。

コンソールを使用して問題のあるホストを削除するには、以下の手順に従います。

  1. プロジェクトに移動します。

  2. [Servers] をクリックします。

  3. 問題が発生しているホストを見つけます。

  4. をクリックします、次にRemove Server 。

    MongoDB Ops Manager にAre you sure you want to remove this server>モーダルが表示されます。

  5. このサーバーを削除する場合は、指定されたホスト名をEnter the host nameフィールドに入力し、 Removeをクリックします。

    警告

    MongoDB Ops Managerは、Remove をクリックすると、このホストのすべてのモニタリング データを削除します。 MongoDB Ops Manager は、このアクションの確認またはキャンセルを提供しません。

    サーバーを削除しない場合は、 Cancelをクリックします。

  6. 変更内容を確認するには、 Review & Deployをクリックします。

    MongoDB Ops Manager に提案された変更が表示されます。

    • 問題がなければ、[ Confirm & Deploy ] をクリックします。

      MongoDB Ops Managerは、この時点ですべてのプロセスとエージェントを削除します。

    • さらに設定変更を行う場合は、[ Cancel ] をクリックします。

APIを使用して問題のあるホストを削除するには、次の手順に従います。

  1. 現在のオートメーション構成を取得します。

  2. オートメーション構成のJSONファイルを編集します。

  3. プロセスとレプリカセットから古いノードを削除します。

  4. オートメーション構成ファイルを更新します。

  5. 数分間待ちます。

  6. Agentsビューを確認します。

  7. ホストがエージェントのリストに表示されなくなったことを確認します。

TLS 証明書にサブジェクト代替名が含まれていることを確認する

警告

バージョン 11.12.0.7384 からの MongoDB Agent では、 TLS証明書に サブジェクト代替名 フィールドに値が含まれている必要があります。 11.12.0.7384 にアップグレードする前に、MongoDB 配置で使用されるすべてのTLS証明書にSANが含まれていることを確認してください。 [1]

[1] MongoDB は MongoDB Agent を Go 言語で記述しました。 Go1.17 で X509 を使用する機能が削除されました。 CommonName フィールドがホスト名 として SAN が存在しない場合。クライアントが TLS 証明書を検証するときに、クライアントは、証明書の SAN またはサブジェクト識別名（DN）フィールドの値から証明書が適用されるホスト名を確認します。TLS証明書を作成するときに、ホスト名を保存するために CN（サブジェクトコモンネーム）フィールドを使用する人もあります。 CN には制限があるため、ホスト名を保存するには適していません。 これらの制限には、 64文字の最大長と 名前制約 のサポートがないことが含まれます。 RFC2818 は CN を使用してホスト名を保存することで非2000 になりました。この RFC では、証明書のSANフィールドに値がない場合、クライアントは CN にフォールバックする必要があります。 RFC6125 は2011 .Go1 で要件を削除しました。15RFC2818 への準拠を無効にします であり、 6125RFC を使用しています。 CN を任意にする仕組みです。実際には、この変更にはSAN値を追加するか、 CNs.Go 1の使用を有効にする必要があります。 17 SAN が存在しない場合に CN を使用する回避策を廃止します。MongoDB Agent の現在のバージョンでは、 SAN を使用する 必要 があります。詳細については 、このトピックに関する Fluser Twift のブログ記事 を 参照してください。

既存のクラスターのメモリに構成ファイルを保存する

MongoDB Ops Managerバージョン 4.2 またはバージョン 4.4.0 - 4.4.6 を使用する場合、 enableLocalConfigurationServerをtrueに設定して MongoDB Agent を再起動すると、 エラーが発生する可能性があります。

この問題は、クラスターの作成後にenableLocalConfigurationServerがtrueに設定されている既存のクラスターにのみ影響します。 クラスターを作成する前にこの値を設定しても、この問題はtriggerされません。

既存のクラスターのこの設定を安全に変更するには、次の手順に従います。

  1. MongoDB Agent の構成ファイルの末尾に、次のコマンドを追加します。

    enableLocalConfigurationServer=true

  2. MongoDB Agent によって管理されている各プロセスをシャットダウンします。

  3. 次のコマンドを実行して MongoDB Agent を再起動します。

    service mongodb-mms-automation-agent restart

  4. シャットダウンした MongoDB プロセスを再起動します。

  5. automation-mongod.confファイルに__rest展開ディレクティブがあることを確認します。

メモリに構成ファイルを保存する方法の詳細については、「 MongoDB Agent が構成ファイルとパスワードを管理する方法を構成する 」を参照してください。

戻る

認証

次へ

モニタリング