MongoDB Ops Managerシステム要件
このセクションでは、 MongoDB Ops Managerコンポーネントを実行するホストのハードウェア、ソフトウェア、ネットワーク要件について説明します。
重要
ホストを展開する前に、インストール チェックリストを使用して構成を計画してください。
Ops Manager Application Database およびバックアップデータベースとして実行中の MongoDB インスタンスの要件については、「 Ops Manager Application Database とバックアップデータベースのインストール 」を参照してください。
ハードウェア要件
注意
このページで「ハードウェア」という用語を使用する場合、次のいずれかのアーキテクチャを使用するホストごとの仕様と理解する必要があります。
物理ハードウェア
仮想ホストに割り当てられたハードウェア コンポーネント
仮想コンテナに割り当てられたハードウェア コンポーネント、または
Kubernetes ワーカー ノードに割り当てられたハードウェア コンポーネント。
各ホストは、提供するすべてのRAM MongoDB Ops Managerコンポーネントの合計 と ディスク容量 の要件を満たしている必要があります。
MongoDB Ops Managerアプリケーション
MongoDB Ops Managerアプリケーション データベース
アクティブなバックアップデーモンのヘッドデータベース
バックアップ ブロックストア データベース
例
MongoDB Ops Managerアプリケーションと バックアップデーモンの両方を 1MongoDB Ops Manager つのホスト上で提供する場合。このMongoDB OpsMongoDB Ops Manager Manager構成により、300MongoDB MongoDBホストの管理とモニター、200 ホストのバックアップ、 FCV.4 2以降が実行されます。バックアップされるすべてのデータベースの合計ディスクキャパシティーは 4 TB です。合計要件は次のようになります。
MongoDB Ops Managerアプリケーションには 15 GBのRAMが必要です。
バックアップデーモンには少なくとも100 GB の使用可能なディスク容量も必要です。
このサンプルホストには、少なくとも15 GB の RAM と100 GB のディスク容量が必要です。
警告
本番環境障害の可能性
以下の構成に失敗すると、 MongoDB Ops Managerインスタンスが本番環境で失敗する可能性があります。
MongoDB Ops Managerは、 MongoDB Ops Managerシステム要件 ごとにホストします。
MongoDB マニュアルのプロダクション ノートに記載されている MongoDB ホスト。 MongoDBMongoDB のMongoDB Ops Manager インスタンスには、次のものが含まれます。
MongoDB Ops Managerハードウェア要件
MongoDB Ops Managerアプリケーションを提供するすべてのホストは、次のハードウェア要件を満たしている必要があります。
監視対象ホストの数 | CPU コア | 物理メモリ[1] | Disk |
---|---|---|---|
最大 400 の監視対象ホスト | 4+ | 15 GB | アプリケーションでは、{0 と ログ 用のストレージで 10GB MongoDB Ops Manager /opt [2] |
最大 2,000 台の監視対象ホスト | 8+ | 15 GB | アプリケーションの 10GB MongoDB Ops Manager /opt ( と ログ用ストレージ [2] |
2,000 台を超えるホスト | MongoDB アカウント マネージャーへの問い合わせ | MongoDB アカウント マネージャーへの問い合わせ | MongoDB アカウント マネージャーへの問い合わせ |
[1] | 物理メモリとは、このコンテキストで使用する場合、Linux プラットフォームでps コマンドの結果でRES として表示される常駐メモリを指します。 これは、物理メモリが仮想構造であっても、仮想マシンとコンテナにも適用されます。 |
[2] | ( 1 、 2 )ログに必要なストレージ容量は、ログ ローテーションの構成によって異なります。 デフォルトでは、ログは 1 ギガバイトごとと 24 時間ごとのいずれか早い方でローテーションします。 控えめな推定値では、保持するログの月ごとに 30 GB のディスクを割り当てる必要があります。 最適なディスク構成について、ディスク割り当てとログ ローテーションの設定を確認します。 |
Ops Manager Application Databaseのハードウェア要件
Ops Manager Application Databaseは、専用ホスト上で実行される 3 つのノードのレプリカセットとして動作します。
Ops Manager Application Database を提供するすべてのホストは、次のハードウェア(物理または仮想)要件を満たしている必要があります。
監視対象ホストの数 | RAM | ディスク容量 | CPU コア |
---|---|---|---|
最大 400 | 8 GB RAM と mongod アプリケーションに必要な RAM | 200 GB | 4 × 2 GHz+ |
最大 2,000 | 15 GB RAM と mongod アプリケーションに必要な RAM | 500 GB | 4 × 2 GHz+ |
2,000 より超え | MongoDB アカウント マネージャーに問い合わせてください | MongoDB アカウント マネージャーに問い合わせてください | MongoDB アカウント マネージャーに問い合わせてください |
最高のパフォーマンスを得るには、以下を使用します。
MongoDB Ops Manager Application Database を保存するための SSD 。
WiredTiger ストレージエンジン WiredTiger と MMAPv 1 storage engine の違いについては、MongoDB マニュアルの storage engine のタイプを参照してください。
ディスク容量の推定値はおおよそです。 必要なディスク容量は、監視対象のデータベースの数によって増減する可能性があります。
バックアップデーモンのハードウェア要件
重要
バックアップを開始する前に、MongoDB アカウント マネージャーに問い合わせて、バックアップデーモン ホストのストレージ要件を見積もります。
バックアップデーモンをアクティブ化する各ホストで、次の要件とMongoDB Ops Managerの要件を満たしている必要があります。
アクティブなバックアップデーモンを提供する各ホストには、次のハードウェア要件があります。
バックアップデーモンの使用可能なディスク容量は 100 GB 以上である必要があります。
ホスト数 | CPU コア | RAM |
---|---|---|
200まで | 4+ × 2 GHz+ | 15 GB の追加 RAM |
バックアップデーモンは、デーモンに割り当てられた各レプリカセットのデータを複製するヘッドデータベースを作成します。 通常、バックアップデーモンをアクティブ化する各ホストは、バックアップされたすべてのレプリカセットのディスク上のサイズの合計の合計を2.0から2.5に保存する必要があります。
具体的には、各ホストは次のものが必要です。
各ヘッドデータベースを維持するためのディスク容量と書込み容量、そして
ディスク容量とスループットの要件を確認するには、MongoDB アカウント マネージャーに問い合わせてください。
バックアップデータベースのハードウェア要件
MongoDB Ops Managerバックアップを使用する場合は、バックアップ データベースのホストをプロビジョニングする必要があります。
バックアップデータベースのホスト要件は、スナップショットの保存に ブロックストア データベースを使用するか、 ファイル システム ストレージを使用するかによって異なります。 バックアップデータベースには常にoplogデータが保持されます。
バックアップデータベースにスナップショットを保存する場合、そのホストは通常、バックアップされた本番データの合計サイズの 2 倍から 3 倍を保存するのに十分な容量を持っている必要があります。 スナップショットはブロックストア内のブロック レベルで圧縮され、重複が除外されます。
具体的な要件は、データの圧縮率と変化率によって異なります。 バックアップデータベース ホストのユースケースとワークロードに依存するストレージ要件を見積もるには、MongoDB アカウント マネージャーに問い合わせてください。
バックアップデータベースにスナップショットを保存する場合、データを保持する各ノードは次の要件を満たしている必要があります。
CPU コア | ディスク容量 | RAM |
---|---|---|
4 × 2 GHz+ | MongoDB Ops Managerブロックストアに必要な最小ディスク容量は、次の式を使用します。 ( 最小ディスク容量を正確に決定するには、 MongoDB サポートに問い合わせてください。 | ブロックストア ディスク 1 TB あたり 8 GB の RAM が必要で、スナップショットと復元速度が向上します。 MongoDB Ops Managerでは、1 TB のブロックストアは 1024 4バイトとして定義されます。 |
ディスク容量とスループットの要件を確認するには、MongoDB アカウント マネージャーに問い合わせてください。
バックアップデータベースにスナップショットを保存しない場合、データを保持する各ノードは次の要件を満たしている必要があります。
CPU コア | ディスク容量 |
---|---|
4 × 2 GHz+ | 構成された ポイント イン タイム ウィンドウに対して圧縮された oplog のサイズ。 デフォルトでは 24 時間です。 |
ネットワーク要件
インターネット サイト アクセス
MongoDB Ops MongoDB Ops ManagerManagerがインターネットから直接バイナリをダウンロードするように設定した場合、 MongoDB Ops Managerは、インターネットへのMongoDB Ops Manager IPv4 リクエストと IPv6 リクエストの両方を使用して、HTTPS 経由で次のインターネット サイトにアクセスする必要があります。
サイト | 目的 |
---|---|
ダウンロード.mongodb.com | MongoDB Enterprise Buildsをダウンロードするには、 |
opsmanager.mongodb.com | MongoDBバージョンマニフェストをダウンロードします。 |
fastdl.mongodb.org | MongoDB Community Buildsをダウンロードするには、 |
MongoDB Ops Managerとバッキングデータベースホスト間のレイテンシ
MongoDB Ops Managerアプリケーション ホストとそのアプリケーション データベース、 oplog 、および ブロックストア レプリカセット間の接続は、ネットワーク レイテンシを最小限に抑える必要があります。 200 個のMongoDBホストを超える配置では、 MongoDB Ops Managerアプリケーション コンポーネント間のレイテンシは 1 ミリ秒未満になる必要があります。 ネットワーク環境がこの要件を満たせないと予想される場合は、 MongoDB サポートにお問い合わせください。
TCP キープアライブ設定
多くのMongoDB Ops Managerコンポーネントは実行中のmongod
プロセスに接続します。 これには以下が含まれます。
アプリケーションデータベース
バックアップデータベース
MongoDB Agent が管理する MongoDB database。
The systems that host these components send data traffic to each other to verify an active connection. TCPキープアライブ設定によって、このチェックの実行頻度が決まります。 ほとんどのシステムでは、デフォルト値の7200秒(2 時間)が使用されます。
その時間枠内でネットワーク接続が切断される可能性があります。 既存の接続がない場合、MongoDB Ops Manager はそのmongod
プロセスへの新しい接続を作成する必要があります。 これにより、通信が遅延したり、ネットワーク タイムアウトやソケット エラーが発生したりする可能性があります。 この問題を防ぐには、キープアライブ値を減らして検証チェックを増やします。 すべての MongoDB Ops Manager コンポーネントは同じキープアライブ値を使用する必要があります。
これを推奨値に設定する方法については、 「 TCP キープアライブ時間が MongoDB デプロイに及ぼす影響」を参照してください。 MongoDB Server マニュアルを参照してください。
MongoDB および MongoDB Agent のホスト アクセス
MongoDB および MongoDB Agent の各ホストは、確実に接続を確保するためにFQDNとして自己識別する必要があります。
次のコマンドを使用して、ホストFQDNを見つけます。
hostname -f
結果は次のようになります。
mongodb.example.com
Windows ホストはインターネットに接続し、Active Directory ドメインに接続する必要があります。
次のコマンドを使用して、ホストFQDNを見つけます。
PS C:\> systeminfo | findstr /B /C:"Host" /C:"Domain"
結果は次のようになります。
Host Name: mongodb Domain: example.com
Host Name
とDomain
を.
と組み合わせてFQDNを取得します。 前の例では、 FQDNはmongoodb.example.com
です。
アクセス可能なポート
MongoDB Ops Managerアプリケーションは、MongoDB HTTPまたは HTTPS 経由 でユーザーと エージェントに接続できる必要があります。MongoDB エージェントは MongoDB クライアント MongoDB データベースに接続できる必要があります。
MongoDB Ops Managerでは、ユーザーとデータベースに接続するにはオープンなHTTP (またはHTTPS )とMongoDBネットワーク ポートのみが必要ですが、ファイアウォール上でどのポートが開かれるかは、暗号化、認証、モニタリングの機能が有効になっている場合に応じて異なります。
このページでは、どのシステムが他のシステムのどのポートに接続する必要があるかを定義します。
MongoDB Ops Managerは、さまざまなサービスと接続します。 このページでは、 MongoDB Ops Manager配置で使用されるさまざまなコンポーネントを配置するために開く必要があるポートについて説明します。
中間ファイアウォールで開く必要がある特定のポートは、暗号化、認証、モニタリングなどの機能が有効になっている場合によって異なります。
Tip
次のセクションにリストされているすべてのポートは、MongoDB インストールのドキュメントで指定されているポートまたは 既知のポート のいずれかです。 : IANA によって割り当てられた特定のサービス用。ポート番号を変更できる場合は、各セクションの 表の後に記載されます。
インターネット接続なしでMongoDB Ops Managerを実行するには、「配置構築でインターネット アクセスを制限する 」を参照して、インターネット接続なしで MongoDB Ops MongoDB Ops Managerを実行するために必要なバイナリがすべて確保されているようにします。
MongoDB Ops Managerにアクセスするにはポートを開きます
MongoDB Ops Managerには、少なくとも次のネットワーク ポート要件が必要です。
MongoDB Ops ManagerユーザーとMongoDB エージェントの両方がMongoDB Ops Manager HTTPまたは HTTPS 経由 で アプリケーションに接続できる必要があります。
MongoDB Ops Managermongodは、MongoDB Ops Manager アプリケーションMongoDB データベースを実行している に接続できる必要があります。
MongoDB エージェントは MongoDB Ops Manager プロジェクトごとに、すべてのクライアント MongoDB プロセス(
mongod
またはmongos
)に接続できる必要があります。MongoDB Ops Manager アプリケーションは、MongoDB Ops Manager ユーザーにメールを送信できる必要があります。
MongoDB Ops Managerを使用するには、指定されたホストに対して次のポートを開きます。
サービス | デフォルトポート | トランスポート | 方向 | 目的 | TLSを使用しますか。 | |||||
---|---|---|---|---|---|---|---|---|---|---|
HTTP | 8080 | TCP | インバウンド | ユーザーと MongoDB エージェントから MongoDB Ops Manager へのウェブ接続を提供します。 | No | |||||
HTTPS | 8443 | TCP | インバウンド | ユーザーと MongoDB エージェントから MongoDB Ops Manager への安全なウェブ接続を提供します。 | はい | |||||
HTTPまたはHTTPS | 8090 | TCP | インバウンド | 協定世界時は、 MongoDB Ops Managerを監視するためのヘルスチェック エンドポイントを提供します。 この機能は これを有効にするには、「ヘルスチェックエンドポイントの有効化 」を参照してください。 有効にすると、次のエンドポイントにアクセスできます。
重要:このポートは APIエンドポイントは、 HTTP Service からMongoDB Ops Manager Application Databaseおよびバックアップ スナップショット ストレージへの接続を確認する機能を提供します。 成功した応答は、以下を返します。
| 任意 | |||||
MongoDB | 27017 | TCP | アウトバウンド | MongoDB アプリケーション、バックアップ、クライアント データベースに接続します。 | 任意 | |||||
SMTP | 587 | TCP | アウトバウンド | から SMTP ホストまたは Amazon Web ServicesSES にメールを送信します。 。MongoDB Ops Manager | 任意 |
注意
MongoDB Ops Managerのデフォルト以外のポートを設定するには、「 MongoDB Ops Managerのホスト名とポートの管理 」を参照してください。
アプリケーション データベースに別のポートを構成するには、
mongo.mongoUri
を参照してください。クライアントデータベースに別のポートを構成するには、「 スタンドアロンのMongoDB インスタンス の配置 」、 「 レプリカセット の配置 」、または「 新しい配置の場合はシャーディングされた クラスター の配置 」、または「 既存の配置の場合 は に既存のMongoDB プロセスを追加 する 」を参照してください。MongoDB Ops Manager
MongoDB Ops ManagerとMongoDBホストにアクセスするにはポートを開きます
ほとんどのMongoDB Ops Manager管理は、ユーザー インターフェースを介して実行できます。 一部の手順では、オペレーティング システムへのアクセスが必要です。 管理者が MongoDB Ops Manager と MongoDB のホストにアクセスできるようにするには、それらのホストに対して次のポートを開きます。
サービス | デフォルトポート | トランスポート | 方向 | 目的 | TLSを使用しますか。 |
---|---|---|---|---|---|
ssh | 22 | TCP | インバウンド | Linux システム管理。 | はい |
RDP | 3389 | TCP | インバウンド | Windows システム管理。 | No |
を使用して インスタンスのバックアップ、復元、クエリを行うにはポートを開きますMongoDBMongoDB Ops Manager
MongoDB Ops Managerは、 MongoDBデータベースを 1 つ以上のストレージ システムにバックアップできます。
MongoDB database(ブロックストア)
S3 互換ストレージ バケット(S3 互換ストレージ ブロックストア)
ファイル システム(ファイル システム ストア)。
MongoDB ホストをバックアップするには、優先バックアップ ホスト(ブロックストア、S3 互換ストレージ スナップショット ストア、ファイルシステム スナップショット ストア)に次のポートを開きます。
サービス | デフォルトポート | トランスポート | 方向 | 目的 | TLSを使用しますか。 |
---|---|---|---|---|---|
MongoDB | 27017 | TCP | アウトバウンド | データベース全体のスナップショットをブロックストアにバックアップするか、スナップショットのメタデータを S3 互換ストレージのブロックストア メタデータデータベースにバックアップします。 | 任意 |
HTTPS | 443 | TCP | アウトバウンド | データベースのスナップショット データを S3 互換ストレージ バケットにバックアップします。 | はい |
NFS | 2049 | TCP | アウトバウンド | データベースのスナップショットを UNIX/Linux ベースのファイル システムにバックアップします。 | No |
CIFS | 3020 | TCP | アウトバウンド | データベースのスナップショットを Windows ベースのファイル システムにバックアップします。 | No |
プロキシ サーバー | 25999 | TCP | アウトバウンド | スナップショット バックアップ ホストをクエリします。 | No |
MongoDB Ops Managerアプリケーションに表示されるリンクを使用してスナップショットを復元することもできます。 ユーザーがスナップショットをダウンロードするには、 MongoDB Ops Managerを使用するのと同じポートを開く必要があります。
ダウンロード リンクを見つけるには、 Continuous Backupをクリックし、次にRestore Historyタブをクリックし、スナップショットの横にあるdownloadリンクをクリックします。
注意
ブロックストアに別のポートを構成するには、「 ブロックストアスナップショット ストレージの管理 」を参照してください。
S 3互換ストレージ スナップショット ストア メタデータ データベースに別のポートを構成するには、「 S 3スナップショット ストレージの管理 」を参照してください。
MongoDB 3.4.2 Enterprise 以降では、バックアップ スナップショットをクエリする機能が提供されます。 は、「 バックアップのクエリMongoDB Ops Manager 」で説明されているように、これらのクエリ可能なスナップショットを読み取り専用のMongoDB インスタンスとしてプロビジョニングします。バックアップ スナップショットをクエリするには、次のポートを開きます。
サービス | デフォルトポート | トランスポート | 方向 | 目的 | TLSを使用しますか。 |
---|---|---|---|---|---|
MongoDB | 27700-27719 | TCP | インバウンド | アプリホストとクエリ可能なバックアップスナップショットとの間の通信を有効にします。 | 任意 |
オープン ポートを使用してMongoDB Ops ManagerをMongoDB Ops Manager SNMP と統合
と SNMP Manager の間で次のポートを開き、MongoDB Ops ManagerMongoDB 配置から への SNMPMongoDB Ops Manager ラップ通知を送受信します。
重要
MongoDB Ops Manager 6.0.0 はSNMPアラートを廃止します。 MongoDB Ops Manager 7.0.0 にはSNMPアラートは含まれません。 その他のアラート オプションの詳細については、「サードパーティ サービスの統合 」を参照してください。
サービス | デフォルトポート | トランスポート | 方向 | 目的 | TLSを使用しますか。 |
---|---|---|---|---|---|
SNMP | 162 | UDP | アウトバウンド | SNMP マネージャーにラップを送信する。 | No |
SNMP | 11611 | UDP | インバウンド | SNMP マネージャーからのリクエストを受信します。 | No |
MongoDB Ops Managerは、 コミュニティベースの SNMPv2 (SNMPv2 c)を使用します。
重要
MongoDB Ops Manager 6.0.0 はSNMPアラートを廃止します。 MongoDB Ops Manager 7.0.0 にはSNMPアラートは含まれません。 その他のアラート オプションの詳細については、「サードパーティ サービスの統合 」を参照してください。
MongoDB Ops Managerアプリケーションは、次の 2 種類のSNMPマップを使用して構成できます。
ラップ タイプ | 内容 | 頻度 | ターゲット |
---|---|---|---|
ハートビート | MongoDB Ops Managerアプリケーションの内部健全性評価 | ユーザー セット | 1 つ以上のエンドポイント |
アラート | ユーザー セット | 1 つ以上のエンドポイント |
SNMPv2c ハートビートまたはアラート ラップを送信するようにMongoDB Ops Managerアプリケーションを構成するには、次の手順に従います。
SNMPv 2 cgroups を構成するには次の手順に従います。
LDAP を使用してMongoDB Ops Managerユーザーを認証するにはポートを開きますMongoDB Ops ManagerLDAP
MongoDB Enterpriseユーザーは、 LDAPを使用して ユーザーを認証できMongoDB Ops Manager ます。LDAPを使用して認証するには、 MongoDB Ops ManagerとLDAPホストで次のポートを開きます。
サービス | デフォルトポート | トランスポート | 方向 | 目的 | TLSを使用しますか。 |
---|---|---|---|---|---|
LDAP | 389 | UDP | 両方 | LDAPホストに対して MongoDB Ops Manager ユーザーを認証 および/または 認可 します。 | No |
LDAPS | 636 | UDP | 両方 | LDAPホストに対して MongoDB Ops Manager ユーザーを認証 および/または 認可 します。 | はい |
非標準ポートの構成を含むMongoDB Ops Manager LDAP URI文字列を構成するには、「ユーザー認証 」を参照してください。
MongoDB で認証するにはポートを開きます
MongoDB Enterprise ユーザーは、Kerberos またはLDAPを使用して MongoDB ユーザーを認証できます。 LDAPまたはKerberosを使用して認証するには、 MongoDBクライアント データベース、 MongoDB Ops Manager 、およびKerberosまたはLDAPホスト間で次のポートを開きます。
サービス | デフォルトポート | トランスポート | 方向 | 目的 | TLSを使用しますか。 |
---|---|---|---|---|---|
Kerberos | 88 | TCP / UDP | アウトバウンド | Kerberos ホストに対して MongoDB ユーザーの認証をリクエストします。 | No |
Kerberos | 88 | UDP | インバウンド | Kerberos ホストに対して MongoDB ユーザーの認証を受信します。 | No |
LDAP | 389 | UDP | 両方 | LDAPホストに対して MongoDB ユーザーを認証および/または認可します。 | No |
LDAPS | 636 | UDP | 両方 | LDAPホストに対して MongoDB ユーザーを認証および/または認可します。 | はい |
アプリケーション Kerberosデータベースへの認証用に構成するには、「 アプリケーション データベースで認証するように MongoDBMongoDB Ops Manager MongoDB Ops ManagerOps Manager を する 」を参照してください。
KMIP を使用して暗号化キーを管理するには、オープン ポート
WiredTiger ストレージ エンジンを使用した MongoDB Enterprise 配置では、ネイティブ暗号化オプションがサポートされます。 KMIPサービスを使用して、マスター暗号化キーを管理できます。 KMIP経由で暗号化されたストレージ エンジンをサポートするには、バックアップデーモン ホスト、MongoDB ホスト、およびKMIPホスト間で次のポートを開きます。
サービス | デフォルトのポート | トランスポート | 方向 | 目的 | TLSを使用しますか。 |
---|---|---|---|---|---|
KMIP | 5696 | TCP | アウトバウンド | MongoDB データベースとKMIPホスト間でメッセージを送信します。 | はい |
注意
KMIPホストのポートを変更する場合は、「暗号化されたバックアップ スナップショット」を参照して、その新しいポートを使用するようにMongoDB Ops Managerを構成します。
インターネット サイト アクセス
MongoDB Ops Managerがローカル モード用に構成されていない場合は、 HTTPS 経由で次のインターネット サイトにアクセスする必要があります。
サイト | 目的 |
---|---|
ダウンロード.mongodb.com | MongoDB Enterprise Buildsをダウンロードするには、 |
opsmanager.mongodb.com | MongoDBバージョンマニフェストをダウンロードします。 |
fastdl.mongodb.org | MongoDB Community Buildsをダウンロードするには、 |
解決可能なホスト名を使用する
MongoDB Agent および MongoDB Ops Manager の各インスタンスは、MongoDB インスタンスまたは MongoDB Agent をホストしている各ホストのホスト名を解決できる必要があります。
各ホストで、可能な限りホスト名を完全修飾ドメイン名( FQDN )に設定します。 ホスト名をFQDNとして検索して設定する方法については、オペレーティング システムのドキュメントを参照してください。
各ホストにFQDNを設定すると、そのホストにログインしたときにどのホストを使用しているかを把握するのに役立ちます。 他のホストが他のホストのホスト名を認識できるようにするには、それらのホストがホスト名を解決する方法を提供する必要があります。
ホスト名解決を構成するには 2 つの方法があります。
ドメイン ネーム サービスを使用する
ホストのホスト名を解決可能にするには、ドメイン名サービス( DNS )を使用してホストを実行します。 DNSは IP アドレスを特定のドメイン( example.com
など)のホスト名にマッピングします。 このDNSホストには、配置内の各ホスト( MongoDB Ops Manager 、 MongoDB Agent 、およびMongoDB )に対するエントリが必要です。 LDAP 、Kerberos、 SNMP 、電子メール ホストとロード バランサーのエントリが推奨されます。
重要
MongoDB Ops Manager 6.0.0 はSNMPアラートを廃止します。 MongoDB Ops Manager 7.0.0 にはSNMPアラートは含まれません。 その他のアラート オプションの詳細については、「サードパーティ サービスの統合 」を参照してください。
ホスト ファイルの編集
DNS設定が不可能な場合は、各システムのhosts
ファイルに各ホストのエントリを追加します。
オペレーティング システム | hosts ロケーション | ||
---|---|---|---|
Linux |
| ||
Mac OS X |
| ||
Windows |
これは通常、次のように解決されます。
|
hosts
ファイルはルートで読み取り可能なプレーンテキストであり、 root
またはAdministrator
権限で編集する必要があります。 エントリの形式は、次のように記述されます。
127.0.0.1 localhost 10.15.0.5 opsmgr.example.dev 10.15.10.15 rs1.example.dev 10.15.10.16 rs2.example.dev 10.15.10.17 rs3.example.dev
ソフトウェア要件
MongoDB Ops Managerコンポーネントを実行するホストは、次のソフトウェア要件を満たしている必要があります。
重要
MongoDB Ops Manager 5.0 以降には Bash 4.2 以降が必要です。
オペレーティング システムの互換性マトリクス
MongoDB Ops Managerと互換性のあるオペレーティング システム
MongoDB Ops Managerを実行するホストは、次のオペレーティング システムのいずれかの 64 ビット バージョンで実行する必要があります。
Intel/AMD(x86_64
)ハードウェア アーキテクチャ
オペレーティング システム | MongoDB Ops Manager 5.0 | MongoDB Ops Manager 6.0 |
---|---|---|
Amazon Linux | 2 | 2 |
Debian | 9, 10, 11 | 10, 11 |
RHEL / CentOS 1 | 7, 8 | 7, 8, 9 |
SUSE Linux Enterprise Server | 12, 15 | 12, 15 |
Ubuntu | 18.04, 20.04 | 18.04, 20.04 |
1 RHELはRHELサーバーとは異なります。 MongoDB Ops ManagerはRHELのみをサポートしています。
注意
MongoDB Agentは s390x
および PowerPC (ppc64le
) アーキテクチャにインストールできますが、 MongoDB Ops Managerアプリケーションはこれらのプラットフォームにインストールできません。 MongoDB Ops Managerアプリケーションは、前の表にリストされているプラットフォームのいずれかにインストールする必要があります。
MongoDB Agent と互換性のあるオペレーティング システム
MongoDB エージェントを実行するホストは、次のハードウェア アーキテクチャとオペレーティング システムのいずれかの 64 ビット バージョンで実行する必要があります。 次の表は、関連付けられているプラットフォームで MongoDB Agent を使用して配置できる MongoDB Server のバージョンを示しています。
アーキテクチャ | Distro/OS | 6.0 | 5.0 | 4.4 | 4.2 | 4.0 | 3.6 |
---|---|---|---|---|---|---|---|
x86_64 | RHEL/CentOS/Oracle Linux 7 1 | ||||||
RHEL/Rocky/Alma Linux/Oracle Linux 8 1 | |||||||
RHEL/Rocky/Alma Linux/Oracle Linux 9 1 | |||||||
Amazon Linux 2 | |||||||
SUSE 12 | |||||||
SUSE 15 | |||||||
Debian 9 | |||||||
Debian 10 | |||||||
Debian 11 | |||||||
Ubuntu 16.x | |||||||
Ubuntu 18.x | |||||||
Ubuntu 20.x | |||||||
Ubuntu 22.x 2 | |||||||
Windows | |||||||
ARM | RHEL/CentOS 8 | ||||||
RHEL/CentOS 9 | |||||||
Amazon Linux 2 | |||||||
PowerPC/ ppc64le | RHEL/ Centos 7 | ||||||
RHEL/ CentOS 8 | |||||||
zSeries/ 390x | RHEL 7 | ||||||
RHEL 8 |
1 MongoDB はRHCKのみを実行している Oracle Linux をサポートしています。 MongoDB はUEKを実行している Oracle Linux をサポートしていません。
2 MongoDB Connector for BIは Ubuntu 22.04ではサポートされていません。
Intel/AMD(x86_64
)ハードウェア アーキテクチャ
MongoDB AgentWindows2008 またはWindows Server 2008R2 で を実行するためのサポートは、MongoDB Ops Manager 5.0 以降で終了します。
MongoDB Agent は、Windows 2016、2019、2020 で実行される MongoDB 配置の管理を引き続きサポートします。
注意
MongoDB Ops Manager Server 4.0.11 以降、 Windows アーキテクチャには、 Visual Studio 用 Visual C++再頒布可能パッケージ2013 が必要です。
マウントの実行オプション/var
MongoDB Ops Managerでは、/var
ディレクトリをバックアップするボリュームに保存されている必要なバイナリを実行するために、基礎のホストマシンの /etc/fstab
で定義されたデフォルトの exec
オプションが必要です。
MongoDB Ops Managerアプリケーションの要件を制限します
MongoDB Ops Managerパッケージでは、次の ulimits
が自動的に発生します。
オープンするファイル
最大ユーザー プロセス
仮想記憶
RHELと CentOS 6 では、ユーザー プロセスの最大数が1024
に制限されています。 これにより、一般的なユーザー プロセス制限( ulimit -u
)の設定が上書きされます。
MongoDB Ops Manager を実行するユーザー(デフォルトではmongodb-mms
)の場合、 /etc/security/limits.d/99-mongodb-nproc.conf
ユーザー プロセス構成ファイルにsoft
とhard
nproc
(プロセス数)のエントリを追加します。 RHEL 1024
ユーザー プロセス制限より大きい値を使用します。
mongodb-mms soft nproc 200000 mongodb-mms hard nproc 500000
/etc/security/limits.d/99-mongodb-nproc.conf
が存在しない場合は、作成します。 /etc/security/limits.d/90-nproc.conf
ファイルの内容をテンプレートとして使用します。
MongoDB Ops Manager Application Databaseおよびバックアップデータベース用の MongoDB バージョン
次のMongoDB Ops Manager リリース シリーズの場合は、次のいずれかの バージョンでその バッキング データベース MongoDBを実行できます。
MongoDB Ops Managerリリース | MongoDB 4.2 | MongoDB 4.4 | MongoDB 5.0 | MongoDB 6.0 |
---|---|---|---|---|
MongoDB Ops Manager 5.0 | 非推奨 | サポートあり | サポートあり | |
MongoDB Ops Manager 6.0 | 非推奨 | サポートあり | サポートあり |
注意
非推奨バージョンは対応するMongoDB Ops Managerリリースでは引き続き動作しますが、次のリリースではこのバージョンのサポートを削除します。 MongoDB サポートでは、潜在的な非互換性の問題を回避するために、サポートされているバージョンに移行することをお勧めします。
詳細については、「MongoDB レガシー サポート ポリシー 」 と「MongoDB MongoDB ソフトウェア ライフサイクル スケジュールMongoDB Ops Manager 」を参照してください。
バージョン サポートは、最初から最後のリリースまでのフル リリース シリーズを対象としています。
MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理 」を参照してください。
重要
MongoDB Ops Managerバッキング データベースのみがこの要件を満たす必要があります。 MongoDB Ops Manager が管理する MongoDB 配置は管理されません。 マネージド MongoDB 配置に必要な最小バージョンについては、「 MongoDB 互換性マトリクス 」を参照してください。
バックアップデーモンとバッキングデータベースの要件を制限します
MongoDBulimit
MongoDBを実行するホスト(バックアップデーモンおよびMongoDB Ops Manager バッキング データベース ホスト)の 要件については、 マニュアルの次のページを参照してください。
メール サービス
メール サーバーをインストールして確認します。 MongoDB Ops Managerでは、アラートを送信し、ユーザー アカウントを回復するためにメール サーバーが必要です。 SMTP サーバーまたはAmazon Web Services SESサーバーを使用できます。 メールサーバーを構成するには、 Email Delivery Method Configuration
を参照してください。
の多くの Linux ホスト型ディストリビューションには、デフォルトでローカルSMTPサーバーが含まれています。 これらには以下が含まれますが、これらに限定されません。
Windows Server にはインターネット情報サーバー付きのSMTPリレーが含まれています。
また、 MongoDB Ops Managerを設定して、 サードパーティのプロバイダー経由でメールを送信する こともできます。 これらには以下が含まれますが、これらに限定されません。
SNMP
環境にSNMPが含まれている場合は、定期的なハートビート ラップを使用してSNMPラップレシーバーを構成して、 MongoDB Ops Managerの内部の健全性を監視できます。 MongoDB Ops ManagerはSNMP v2c を使用します。 詳細については、「 SNMP ハートビート サポートの構成 」を参照してください。
重要
MongoDB Ops Manager 6.0.0 はSNMPアラートを廃止します。 MongoDB Ops Manager 7.0.0 にはSNMPアラートは含まれません。 その他のアラート オプションの詳細については、「サードパーティ サービスの統合 」を参照してください。
Linux ホストへの ftconfig インストール
ホストに MongoDB Ops Managerバージョン 4.0.13Linux 以降をインストールする場合は、フォント構成パッケージをインストールして、 Statusタブから PDF または PNG 形式へのデータ エクスポートを有効にします。
クライアント Web ブラウザ
MongoDB Ops Managerを使用するには、 JavaScriptが有効になっている次のいずれかのサポート対象ブラウザを使用する必要があります。
サポートされているウェブブラウザ | サポートされているバージョン |
---|---|
latest stable | |
latest stable | |
latest stable | |
latest stable |
MongoDB Ops Managerにサポートされていないブラウザへの警告が表示されます。