Docs Menu
Docs Home
/
MongoDB Ops Manager
/
Ops Manager のインストール
/
高度な構成オプション

高可用性MongoDB Ops Managerアプリケーションの構成

項目一覧

MongoDB Ops Managerアプリケーションは、ロードMongoDB Ops Manager バランサーの背後に複数の アプリケーション サーバーを使用し、 をホストするために レプリカセット を使用することで高可用性を提供します。Ops Manager Application Database

Considerations

ロード バランサー

MongoDB Ops Manager Application のコンポーネントは、リクエスト間でステートレスです。 任意のMongoDB Ops Managerアプリケーション サーバーは、すべてのサーバーが同じOps Manager Application Databaseから読み取る限り、リクエストを処理できます。 あるMongoDB Ops Managerアプリケーションが使用できなくなると、別の MongoDB Ops Manager アプリケーションがリクエストを処理します。

これを高可用性で活用するには、任意のロード バランサーを構成して、 MongoDB Ops Managerアプリケーション ホストのプール間でバランスをとります。 MongoDB Ops Managerでこれを行うには、次のアクションを実行します。

MongoDB Ops ManagerApplication は、IP の監査、ログ、 アクセス リストの設定 APIにクライアントの アドレスを使用します。

ロード バランサーが構成されて起動された後は、個々のホストURLから MongoDB Ops Manager アプリケーションにログインしないでください。

注意

各MongoDB Ops Managerアプリケーション サーバーへのアクセスを禁止するには、それに応じてファイアウォール ルールを構成します。

例

次のURLを提供する 2 つの MongoDB Ops Manager ホストがある場合:

  • ops1.example.com

  • ops2.example.com

次のURLのロード バランサーの背後にあります。

  • opsmanager.example.com

そのロード バランサーを設定して起動した後は、 ops1.example.comにログインしないでください。 代わりにopsmanager.example.comにログインしてください。

注意

構成ファイルを使用してこれらのパラメーターを設定する場合は、 mms.remoteIp.headerをロード バランサーのURLに変更し、 mms.centralUrlを MongoDB Ops Manager ホストとポートのURLに変更します。

ファイル システム スナップショットには共有ファイル システムが必要

または HTTPSHTTP ロード MongoDB Ops Managerバランサーの背後で複数のMongoDB Ops Manager アプリケーション サーバーを使用し、 ファイルシステムのスナップショット を使用するように を構成すると、 FCV4 .2 以降のバックアップ スナップショット ジョブは 1 つ以上のサーバーで並行して実行されます。各MongoDB Ops Managerサーバーに共有ファイル システムがマウントされていることを確認します。 MongoDB Ops Managerアプリケーション サーバーでは、同じファイルの異なるオフセットを開いて書き込む場合があります。 共有ファイル システムでこれが許可されていることを確認します。 付けない場合、アクセス エラーが発生します。

診断アーカイブ

MongoDB Ops Manager 診断アーカイブの生成時間を付与するには、ロード バランサーの HTTP idle timeoutパラメータを 180 秒に設定します。

アプライアンス ネットワーク レイヤーのサポート

すべてのロード バランシング アプライアンスは 7レイヤー をサポートする必要があります。 OSI モデルの（アプリケーション層）。

Ops Manager Application Database のレプリカセット

をホストするには、スタンドアロンではなく レプリカセットOps Manager Application Database を配置します。レプリカセットでは、 プライマリ が使用できなくなった場合の自動 フェイルオーバー が行われます。

レプリカセットで複数の施設にメンバーがいる場合は、必要に応じて 1 つの施設でプライマリを選出するのに十分な投票数があることを確認します。 コア アプリケーション システムをホストするファシリティを選択します。 投票メンバーの過半数と、プライマリになることができるすべてのメンバーをこの機能に配置します。 そうしないと、ネットワーク パーティションによってセットが過半数を形成できなくなる可能性があります。 レプリカセットによるプライマリの選出方法の詳細については、「レプリカセットの選挙 」を参照してください。

ファイルシステムのスナップショットを使用してレプリカセットをバックアップできます。 ファイルシステムのスナップショットはシステムレベルのツールを使用して、レプリカセットのデータファイルを保持するデバイスのコピーを作成します。

MongoDB Ops Manager Application Database をホストするレプリカセットを配置するには、 MongoDB インスタンスのバッキング を参照してください。

gen.keyファイル

gen.key ファイルは、 MongoDB Ops Managerの バッキング データベース と ユーザー認証情報 を暗号化および復号化するために使用される 24 バイトのバイナリ ファイルです。 同一の gen.key ファイルは、高可用性のMongoDB Ops Manager配置の一部であるすべてのサーバーに保存する必要があります。

gen.keyファイルは自動または手動で生成できます。

MongoDB Ops Managerで ファイルを生成するには、次の手順に従います。
1 つのMongoDB Ops Managerサーバーを起動します。 MongoDB Ops Manager は、存在しない場合、 gen.keyファイルを作成します。
ファイルを手動で作成する方法は、次のとおりです。

24 バイトのバイナリ ファイルを生成します。

例

以下の例では、gen.key を使用してopenssl ファイルを作成しています。

openssl rand 24 > /<keyPath>/gen.key

gen.keyファイルを機密ファイルと同様に保護します。 MongoDB Ops Managerを実行しているユーザーに所有者を変更し、所有者のみの読み取りと書込み (write) 権限を設定します。

gen.keyファイル（自動または手動で作成）が作成されたら、他の MongoDB Ops Managerサーバーを起動する 前に 、 ファイルを現在のサーバー上の適切なディレクトリにコピーし、他のMongoDB Ops Manager MongoDB Manager サーバー上の適切なディレクトリにコピーします。

  • /etc/mongodb-mms/ RPM または Ubuntu インストールの場合

  • ${HOME}/.mongodb-mms/ アーカイブ（ .tar ）ファイルのインストール用

重要

  • gen.keyファイルを保存する共有ストレージ リソースは、潜在的な単一障害点が発生しないように、高可用性用に構成する必要があります。

  • gen.key ファイルがインストールされていないMongoDB Ops Managerサーバーは、バッキング データベースに接続し、HA MongoDB Ops Managerインスタンスの一部になることはできません。

  • 最初のMongoDB Ops ManagerサーバーでMongoDB Ops Managerインスタンスの gen.key を生成したら、gen.key ファイルを安全な場所にバックアップします。

アップグレード モード

MongoDB Ops Managerのインストールで、複数のMongoDB Ops Managerホストが同じアプリケーション データベースを指している場合は、監視ダウンタイムを発生させずにMongoDB Ops Managerを新しいバージョンにアップグレードできます。 高可用性のMongoDB Ops Manager配置の 1 つのMongoDB Ops Managerホストのアップグレードが完了すると、その配置はアップグレード モードと呼ばれる状態になります。 この状態では、アップグレード中にMongoDB Ops Managerが利用可能です。 このモードの利点は、アップグレード プロセス全体です。

  • アラートとモニタリングの動作

  • MongoDB Ops Manager インスタンスはライブのまま

  • MongoDB Ops Managerアプリケーションは読み取り専用モードでアクセスできます

  • データの書き込みまたは削除が無効になっているMongoDB Ops Manager API

すべてのMongoDB Ops Manager ホストがアップグレードされ再起動されるまで、 インスタンスは アップグレード モード MongoDB Ops Managerのままになります。一度に複数のMongoDB Ops Managerホストをアップグレードしないでください。

マルチリージョン配置におけるパフォーマンス

Application Database およびMongoDB Ops Managerインスタンスの地理的分散は、 MongoDB Ops Managerアプリケーションのパフォーマンスに影響を与える可能性があります。

マルチリージョン アプリケーション データベースのパフォーマンス

アプリケーション データベースを複数のリージョンにわたって複製する予定の場合は、 MongoDB Ops Managerの書込みワークロード操作の多くが w:2 書込み保証（ write concern ） を使用していることを考慮してください。これには、書込み操作ごとにレプリカセットのプライマリ ノードと 1 つのセカンダリ ノードからの確認応答が必要です。

そのため、プライマリ ノードと同じリージョンにアプリケーション データベースのセカンダリ レプリカ ノードがあると、読み取りおよび書込みのパフォーマンスが向上します。

たとえば、3 つのリージョンに 3 つのアプリケーション データベースのレプリカセット ノードを 1-1-1 の方法で配置すると、2 つのリージョンに 3 つのアプリケーション データベースのレプリカセット ノードを配置する場合に比べてパフォーマンスが低下する可能性があり、1 つのリージョンでは 2 つのアプリケーションがホストされます。データベースレプリカセット ノードと別のリージョンは 3 つ目のレプリカセット ノードをホストします。

MongoDB Ops Manager UI のパフォーマンス

MongoDB Ops Manager UI は、アプリケーションデータベースレプリカセットのアプリケーションデータベースプライマリノードと同じリージョンに配置された MongoDB Ops Manager アプリケーションインスタンスに接続すると、よりパフォーマンスが向上します。

つまり、 インスタンス自体が配置されているより近いMongoDB Ops Managerアプリケーション インスタンスに接続するのではなく、レプリカセットのアプリケーション データベース プライマリ ノードと同じリージョンでホストされているMongoDB Ops Managerアプリケーション インスタンスに接続することで、ユーザー エクスペリエンスが向上する可能性があります。は、高レイテンシを持つ別のリモート リージョンでホストされているプライマリ アプリケーション データベース レプリカセット ノードに接続する必要があります。

前提条件

Ops Manager Application Databaseを提供するレプリカセットを配置します。 レプリカセットを配置するには、MongoDB マニュアルの 「レプリカセットの配置」 を参照してください。

手順

次の手順では、MongoDB Ops Manager アプリケーション ホストの 1 つを使用して最初のgen.keyを生成したことを前提としています。 代わりに、独自のgen.keyを作成する場合は、MongoDB Ops Manager アプリケーションを起動する前に、それを MongoDB Ops Manager ホストに分散します。

重要

MongoDB Ops Manager アプリケーション サーバーの前に配置されたロード バランサーによって、キャッシュされたコンテンツが返されないようにする必要があります。 ロード バランサーではキャッシュが無効になっている必要があります。

負荷分散を使用して複数のMongoDB Ops Managerアプリケーションを構成するには、次の手順に従います。

1

MongoDB Ops Managerアプリケーション ホストのプールを使用してロード バランサーを構成します。

各MongoDB Ops ManagerヘルスAPIエンドポイントでヘルスチェックを実行するようにロード バランサーを設定します。

http://<OpsManagerHost>:<OpsManagerPort>/monitor/health

MongoDB Ops Manager は、次の 2 つのHTTPコードのいずれかで応答します。

HTTP Status Code
ヘルス ステータス
200
MongoDB Ops Managerのホストとアプリケーション データベースは正常に表示されます。
500

MongoDB Ops Managerホストまたはアプリケーション データベースが正常でないように表示される。

このエンドポイントがHTTP 500を頻繁に返す場合は、 「 トラブルシューティング 」セクションを確認してください。

ロード バランサーはキャッシュされたコンテンツを返してはなりません。

2

ロード バランサーを使用するようにMongoDB Ops Managerを構成します。

  1. MongoDB Ops Managerで、Admin、次に General タブ、次に Ops Manager Config をクリックします。

  2. ロード バランサー URL を指すようにURL to Access Ops Managerプロパティを設定します。

  3. ロード バランサーがクライアントの IP アドレスを識別するのに使用するLoad Balancer Remote IP Header HTTP ヘッダー フィールドの名前に プロパティを設定します。

    Load Balancer Remote IP Header が設定されると、MongoDB Ops Manager は次の HTTP ヘッダーを有効にします。

    HTTP ヘッダー
    Ops Manager に転送
    クライアントがホスト HTTP リクエスト ヘッダーで要求した元のホスト。
    HTTP リクエストを行うために使用されるプロトコル。
    プロキシ サーバーのホスト名。
    リクエストの HTTPS ステータス。
3

各 MongoDB Ops Manager アプリケーション ホストをレプリケーション ホスト情報で更新します。

各ホストで、 ファイルを編集して、conf-mms.properties mongo.mongoUriプロパティを のOps Manager Application Database 接続string に設定します。接続mongo.mongoUri には少なくとも 3ホストを指定する 必要string があります。

mongo.mongoUri=mongodb://<mms0.example.net>:<27017>,<mms1.example.net>:<27017>,<mms2.example.net>:<27017>/?maxPoolSize=100
4

MongoDB Ops ManagerURLURLMongoDB AgentMongoDB Agent構成ファイルで、 MongoDB Ops Manager URLを Load Balancer URLに変更します。

各 MongoDB Agent のホストで次の手順を実行します。

  1. MongoDB Agent の構成ファイルを開きます。

    vi /path/to/configurationFile.config

    オートメーション構成ファイルの場所は、プラットフォームによって異なります。

    /path/to/install/local.config
    /etc/mongodb-mms/automation-agent.config
    /etc/mongodb-mms/automation-agent.config
    /path/to/install/local.config

  2. mmsBaseUrlプロパティを編集してロード バランサーを指すようにし、変更を保存します。

    mmsBaseUrl=<LOAD-BALANCER-URL>:<PORT>

  3. MongoDB Agent を再起動します。

5

MongoDB Ops Managerアプリケーションの 1 つを起動します。

例

MongoDB Ops Managerアプリケーションを rpm または deb パッケージを使用してインストールした場合は、次のコマンドを実行します。

service mongodb-mms start
6

gen.keyファイルを各MongoDB OpsMongoDB Ops Manager Managerホストにコピーします。

gen.keyファイルは、パッケージ マネージャーからのインストールの場合は/etc/mongodb-mms/に、アーカイブからのインストールの場合は${HOME}/.mongodb-mms/にあります。

実行中のMongoDB Ops Manager Application のホストから gen.key ファイルを他のMongoDB Ops Manager Application ホスト上の適切なディレクトリにコピーします。

7

残りのMongoDB Ops Managerアプリケーションを起動します。

詳細情報

MongoDB Ops Managerバックアップの可用性を高レベルにするには、「高可用性MongoDB Ops Managerバックアップ サービスの構成 」を参照してください。

戻る

バッキング データベースのモニタリングの有効化

次へ

高可用性バックアップの配置

項目一覧