Docs Menu
Docs Home
/
MongoDB Cloud Manager
/

既存の MongoDB プロセスを Cloud Manager に追加する

項目一覧

  • Considerations
  • 前提条件
  • 手順

Cloud Manager では、既存の MongoDB 配置をモニタリングとマネジメントに追加するためのウィザードが提供されます。 ウィザードは を操作するプロンプトを表示します。

配置にはプロジェクト内で一意の名前が必要です。

重要

同じプロジェクト内のレプリカセット、シャーディングされたクラスター、およびシャード名は一意である必要があります。 配置名を一意のものにしないと、バックアップ スナップショットが中断されます。

オートメーションはすべての MongoDB オプションをサポートしていないため、インポートが失敗する可能性があります。 詳しくは、「 MongoDB 設定とオートメーション サポート 」を参照してください。

TLS を有効にする場合、MongoDB プロセスを提供するホストの FQDN は、そのホスト上の TLS 証明書の SAN と一致する必要があります。

重要

中間者攻撃(man-in-the-middle attack)を防ぐには、 TLS証明書の範囲をできるだけ小さくします。 多数の SAN で 1 つの TLS 証明書を使用することも、各ホストでワイルドカード TLS 証明書を使用することもできますが、 は使用しないでください 。詳しくは、 RFC2818 のセクション3 を参照してください。1 。

次の場合は、優先ホスト名を設定します。

  • MongoDB プロセスにアクセスするには、特定のホスト名、 FQDNIPv4アドレス、またはIPv6アドレスが必要です。または

  • 複数のエイリアスを持つホストに使用するホスト名を指定する必要があります。

詳しくは、プロジェクト設定 Preferred Hostnames設定を参照してください。

Windows サービスとして実行される既存の MongoDB プロセスをオートメーションに追加する場合、オートメーションは次のようになります。

  • 既存のサービスを停止して無効にします

  • 新しいサービスを作成して開始します

Cloud Manager プロジェクトで、その配置に対して MongoDB 認証設定が有効になっている場合、インポートする MongoDB 配置はプロジェクトの認証メカニズムをサポートしている必要があります。

実行中のプロセスがなく、認証が有効になっていない新しい宛先プロジェクトにインポートすることをお勧めします。

ソースクラスターが認証を使用しており、宛先の Cloud Manager プロジェクトに既存の管理対象プロセスがない場合、Cloud Manager は宛先プロジェクトで認証を有効にし、ソースクラスターから既存のキーファイルをインポートし、そのキーファイルを使用して実行するユーザーを認証します。インポート プロセス。

ソースクラスターと宛先 Cloud Manager プロジェクトの両方が認証を使用し、プロジェクトに プロセスがある場合、Cloud Manager はインポートプロセス中に宛先プロジェクトの既存の認証設定を使用しようとします。 インポート プロセスを成功させるには、ソースクラスターと Cloud Manager 宛先プロジェクトの認証情報が同じである必要があります。

インポートが成功するようにするには、インポートプロセスを開始する前に、ソースクラスターに Cloud Manager 宛先プロジェクトの認証情報を追加します。 詳しくは、「レプリカセットのキーのローテーション 」または「 シャーディングされたクラスターのキーのローテーション 」を参照してください。

MongoDB 配置で認証が必要な場合は、監視用に Cloud Manager に配置を追加するときに、必要な認証情報を提供する必要があります。

  • 配置でオートメーションを使用せに、バックアップ、モニタリング、またはその両方が使用されていた場合は、MongoDB Agent に更新する前に認証情報が であった、それらの認証情報を見つけることができます。

  • 配置でオートメーション使用せず、バックアップとモニタリングのいずれかを使用する場合、次のようにします。

    1. MongoDB 配置の認証情報を作成します。 詳細については、「モニタリング用の MongoDB Agent に必要なアクセス権 」および「 バックアップ用の MongoDB Agent に必要なアクセス権 」を参照してください。

    2. MongoDB プロセスを追加した後、それらの関数に付与した認証情報を Cloud Manager に追加します。 詳細については、「モニタリング用の認証情報の追加 」および「 バックアップ用の認証情報の追加 」を参照してください。

  • 配置でオートメーションを使用する場合、Cloud Manager は MongoDB Agent の認証情報を使用します。 レガシーバックアップとモニタリング エージェントから認証情報を削除できます。 MongoDB Agent は、オートメーション、バックアップ、モニタリング機能にこれらの認証情報を使用します。

  • 配置でオートメーション使用されるが、インポートする前にオートメーションが使用されなかった場合は、インポートしたデータベース プロセスに mms-automationユーザーを追加し、ユーザーの認証情報を Cloud Manager に追加します。

詳細については、「オートメーション用の認証情報の追加 」を参照してください。

MongoDB 配置をオートメーションに追加すると、Cloud Manager プロジェクトと MongoDB 配置のセキュリティ設定に影響する可能性があります。

  • オートメーションにより、 プロジェクト セキュリティ設定 が有効になります。 MongoDB 配置に認証が必要であるが、Cloud Manager プロジェクトで認証設定が有効になっていない場合、MongoDB 配置をオートメーションに追加すると、Cloud Manager はプロジェクトのセキュリティ設定を、新しくインポートされた配置のセキュリティ設定に更新します。

    インポート プロセスでは、プロジェクトのセキュリティ設定が現在無効になっている場合にのみ、Cloud Manager プロジェクトのセキュリティ設定がアップデートされます。 インポートプロセスによって、プロジェクトのセキュリティ設定が無効になったり、有効な認証メカニズムが変更されたりすることはありません。

  • オートメーションは MongoDB ユーザーとロール をインポートします。 次のステートメントは、MongoDB の配置に認証が必要な場合、または Cloud Manager プロジェクトで認証設定が有効になっている状況に適用されます。

    MongoDB 配置にユーザーまたはユーザー定義のロールが含まれている場合は、Cloud Manager がこれらのユーザーとロールをインポートして管理することを選択できます。 インポートされたユーザーとロールは、Cloud Manager プロジェクト内のすべての管理対象配置にSyncedです。

    • プロジェクトのEnforce Consistent Set値をYesに設定すると、Cloud Manager はインポートされていないユーザーとロールを MongoDB 配置から削除します。

    • プロジェクトのEnforce Consistent Set値をNoに設定すると、Cloud Manager はプロジェクトにインポートされていないユーザーとロールの管理を停止します。 これらのユーザーとロールは MongoDB 配置に残ります。 これらのユーザーとロールを管理するには、MongoDB 配置に直接接続する必要があります。

    Cloud Manager プロジェクトで特定のユーザーとロールを管理しない場合は、変更を確認して配置する前に、 Authentication & UsersページとAuthentication & Rolesページを使用してインポート中にこれらのユーザーとロールを削除してください。 詳細については、「 MongoDB ユーザーの管理または非管理 」を参照してください。

    インポートされた MongoDB 配置の データベースにすでにmms-backup-agent mms-monitoring-agentユーザーとadmin ユーザーがすでに存在する場合、インポートmms-backup-agent mms-monitoring-agentプロセスはこれらのユーザーのロールを、Cloud Manager プロジェクトで設定されている ユーザーと ユーザーのロールで上書きします。

  • オートメーションは、 プロジェクト 内のすべての配置に適用されます。 Cloud Manager プロジェクトによって管理されているすべてのユーザーとロールを含む、プロジェクトの更新されたセキュリティ設定は、インポートされた MongoDB 配置を含むプロジェクト内のすべての配置に適用されます。

    Cloud Manager が、インポートされた MongoDB 配置を含む、プロジェクト内のすべての配置を新しい設定で再起動します。 インポート後は、プロジェクト内のすべての配置で再起動時に Cloud Manager オートメーションキーファイルが使用されます。

    インポートする配置では、宛先プロジェクトの既存のプロセスと同じキーファイルを使用する必要があります。そうしないと、インポート プロセスが続行されない可能性があります。 詳細については、 「ソースクラスターと宛先クラスターの認証情報」 を参照してください。

    プロジェクト内の既存の配置でインポートされたプロセスとは異なるセキュリティ プロファイルが必要な場合は、ソース MongoDB 配置をインポートできる新しいプロジェクトを作成します。

次の例は、MongoDB の配置で認証が必要な場合、または Cloud Manager プロジェクトで認証設定が有効になっている状況に適用されます。

MongoDB ユーザーとカスタムロールをインポートした場合、Cloud Manager プロジェクトが MongoDB 配置の管理を開始すると、 Enforce Consistent Setの値に関係なく、次の状況が発生します。

  • Cloud Manager プロジェクトは、認証を有効化し、インポートされたユーザーとロールを管理し、新しいユーザーとロールをすべての管理対象配置に同期します。

  • MongoDB 配置のアクセス制御が有効になっており、認証が必要です。 MongoDB 配置には、Cloud Manager プロジェクトが管理するすべてのユーザーとロールがあります。 これらのユーザーとロールでは、Synced Yesは に設定されています。

MongoDB ユーザーとカスタムロールをインポートしない場合、Cloud Manager プロジェクトが MongoDB 配置の管理を開始すると、次の状況が発生します。

Enforce Consistent SetYesに設定されている場合 :

  • Cloud Manager プロジェクトは認証を有効にし、管理されているユーザーとロールは変更されません。

  • MongoDB 配置のアクセス制御が有効になっており、認証が必要です。

  • Cloud Manager は、インポートされていない MongoDB ユーザーとロールを配置から削除します。

  • MongoDB 配置には、Cloud Manager プロジェクトが管理するすべてのユーザーとロールがあります。 これらのユーザーとロールでは、Synced Yesは に設定されています。

Enforce Consistent SetNoに設定されている場合 :

  • Cloud Manager プロジェクトでは認証が有効になっており、ユーザーやロールなどのセキュリティ設定は変更されません。

  • MongoDB 配置のアクセス制御が有効になっており、認証が必要です。

  • インポートされていない MongoDB ユーザーとロールは、MongoDB 配置に残ります。

  • MongoDB 配置には、すべてのユーザーとロールが Cloud Manager プロジェクトによって管理されています。 これらのユーザーとロールでは、Synced Yesは に設定されています。

  • 配置でmongodがサービスとして有効になっている場合、競合状態が発生すると、オートメーションではなくsystemdが再起動時にmongodを起動する可能性があります。 この問題を防ぐには、オートメーションに配置を追加する前に、 mongodサービスが無効になっていることを確認します。

    1. mongodサービスが有効になっているかどうかを確認します。

      sudo systemctl is-enabled mongod.service
    2. サービスが有効になっている場合は、無効にします。

      sudo systemctl disable mongod.service
  • Cloud Manager プロジェクトで認証設定が有効になっていないが、MongoDB プロセスで認証が必要な場合は、適切なロールを持つ Cloud Manager プロジェクトの MongoDB Agent ユーザーを追加します。 インポート プロセスに、ユーザーに必要なロールが表示されます。 追加されたユーザーは、プロジェクトの MongoDB Agent ユーザーになります。

  • Cloud Manager プロジェクトで認証設定が有効になっている場合は、Cloud Manager プロジェクトの MongoDB Agent ユーザーを MongoDB プロセスに追加します。

    • MongoDB Agent ユーザーを見つけるには:

      1
      1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

      2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

      3. Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。

        配置ページが表示されます。

      2

      配置の [ Security ] タブをクリックします。

      [セキュリティ ]ページが表示されます。

      3
    • Cloud Manager プロジェクトの MongoDB Agent ユーザーのパスワードを見つけるには、次のいずれかの方法を使用します。

      MongoDB プロセスの追加 」手順の手順に従って、UI でウィザードを起動します。 Do you want to add automation to this deployment?と表示されるモーダルに到達したら以下の操作を行います。

      1. Add Automation and Configure Authentication を選択します。

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

      Automation Configuration Resourceエンドポイントを使用します。

      curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
      --header "Accept: application/json" \
      --include \
      --request GET "<host>/api/public/v1.0/groups/<Group-ID>/automationConfig"

      テキスト エディターでmmsConfigBackupファイルを開き、 autoPwd値を見つけます。

      Cloud Manager プロジェクトがユーザー名/パスワード認証を使用している場合は、プロジェクトの Cloud Manager MongoDB エージェント ユーザーmms-automationをインポートする MongoDB 配置のadminデータベースに追加します。

      db.getSiblingDB("admin").createUser(
      {
      user: "mms-automation",
      pwd: <password>,
      roles: [
      'clusterAdmin',
      'dbAdminAnyDatabase',
      'readWriteAnyDatabase',
      'userAdminAnyDatabase',
      'restore',
      'backup'
      ]
      }
  • Cloud Manager の下にクラスターを追加すると、Cloud Manager は自動的に ログローテーションを有効にします。これにより、 mongodまたはmongosログの既存のlogRotate構成と競合する可能性があります。 この衝突を防ぐには、次の操作を行います。

    • mongodまたはmongosプロセスのlogRotate構成を無効にします。

    • Cloud Manager のデフォルトを使用するには、 または プロセス 構成 から systemLog.logRotateおよびsystemLog.logAppend オプション を削除します。mongodmongos

  • インポートプロセスでは、ソースクラスターと宛先クラスターで認証情報とキーファイルが同じである必要があります。 詳細については、 「ソースクラスターと宛先クラスターの認証情報」 を参照してください。

  • 既存のレプリカセットを Cloud Manager に正常にインポートするには、インスタンスが正常である必要があります。

重要

シャーディングされたクラスターを追加する場合は、 mongosおよびすべてのシャードでこのユーザーを作成する必要があります。 つまり、 mongosを通じてユーザーをクラスター全体のユーザーとして作成するだけでなく、各シャードでシャード ローカル ユーザーとして作成します。

既存の MongoDB プロセスを Cloud Manager に追加するには、次の手順に従います。

1
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。

    配置ページが表示されます。

2
3

配置をインポートしたプロジェクトで認証が有効になっている場合は、既存の MongoDB プロセスを Cloud Manager に追加した後、新しい配置の認証情報を追加する必要があります。 新しい配置にオートメーション、モニタリング、またはバックアップの認証情報を追加する必要がある状況については、「認証のユースケース」を参照してください。

Atlas にライブ移行する配置を追加する場合は、モニタリングのみに配置(およびその認証情報)を追加する必要があります。

使用する認証メカニズムを選択します。

オートメーションを使用するが、Cloud Manager にインポートする前には使用していなかった配置の認証情報を追加するには、次の手順に従います。

1

MongoDB Agent ユーザーは、MongoDB データベースの自動化タスクを実行します。 この MongoDB ユーザーに適切な特権があることを確認します。

2
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。

    配置ページが表示されます。

3

配置の [ Security ] タブをクリックします。

[セキュリティ ]ページが表示されます。

4

次のいずれかのアクションを実行します。

  • このプロジェクトでTLS 、認証、または認可設定を初めて構成する場合は、 Get Startedをクリックします。

  • このプロジェクトのTLS認証または認可設定をすでに構成している場合は、[ Editをクリックします。

5
6
7
設定
MongoDB Agent Username
MongoDB Agent のユーザー名を入力します。
MongoDB Agent Password
MongoDB Agent ユーザー名 のパスワードを入力します。
設定
MongoDB Agent LDAP Username
LDAPユーザー名を入力します。
MongoDB Agent LDAP Password
MongoDB Agent のLDAPユーザー名 のパスワードを入力します。
MongoDB Agent LDAP Group DN

MongoDB Agent のLDAPグループの識別名を入力します。

LDAP 認可を使用する場合にのみ、MongoDB Agent の LDAP グループ DN を指定します。各MongoDB Agentは を持ち、独自のLDAPグループDNを使用する必要があります。

必要な値は、Linux 提供のKDCに接続するか、Windows Active Directory Server に接続するかによって異なります。

設定
Monitoring Kerberos Principal
Kerberos プリンシパル。
Monitoring Keytab Path
MongoDB Agent のキータブへの絶対ファイル Ppath
Monitoring LDAP Group DN

MongoDB Agent のLDAPグループの識別名を入力します。

次に、 LDAPグループ DN が MongoDB でロールとして作成され、MongoDB Agent に適切な権限が付与されます。

LDAP 認可を使用する場合は、LDAP グループ DN を指定する必要があります。

設定
MongoDB Agent Username
Active Directory ユーザー名。
MongoDB Agent Password
Active Directory のパスワード。
Domain
Active Directory ドメイン サービス内のドメインの NetBIOS 名。 すべて大文字でなくてはなりません。
設定
MongoDB Agent Username
MongoDB Agent の PEM キー ファイルから生成された LDAP v 識別名を入力します。3
TLS/SSL CA File Path
PEM形式の信頼できる認証局(CA)証明書を含むディスク上のパス。 これらの証明書は、 TLS / SSLを使用して実行されている MongoDB インスタンスから返されたサーバー証明書を検証します。 少なくとも 1 つのTLS / SSL CA ファイル パスを入力する必要があります。
MongoDB Agent PEM Key file
MongoDB 配置にクライアント証明書が必要な場合は、適切なオペレーティング システムの行で、サーバー上の MongoDB Agent のPEMキー ファイルで使用されるクライアント証明書のパスと.pemファイル名を指定します。 少なくとも 1 つの MongoDB Agent PEM キー ファイルに 値を入力する必要があります。
MongoDB Agent PEM Key Password
PEMキー ファイルが暗号化されている場合は、そのファイルにパスワードを入力します。
MongoDB Agent LDAP Group DN

MongoDB Agent のLDAPグループの識別名を入力します。

MongoDB Agent の LDAP グループ DN を指定する必要があるのは、LDAP 認証を使用する場合のみです。

オートメーションを使用せず、モニタリングを使用する配置の認証情報を追加するには、次の手順に従います。

1
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。

    配置ページが表示されます。

2

をクリックしますをクリックし、モニタリング設定を表示する配置の横にある [ Monitoring Settings ] をクリックします。

3
4
設定
Monitoring Username
監視ユーザー名を入力します。
Monitoring Password
監視ユーザー名用のパスワードを入力します。
設定
Monitoring LDAP Username
LDAPユーザー名を入力します。
Monitoring LDAP Password
モニタリングのLDAPユーザー名 のパスワードを入力します。
Monitoring LDAP Group DN

モニタリングのLDAPグループの識別名を入力します。

LDAP 認可 を使用する場合にのみ、モニタリングの LDAP グループ DN を指定します。各モニタリングは を持ち、独自のLDAPグループDNを使用する必要があります。

必要な値は、Linux 提供のKDCに接続するか、Windows Active Directory Server に接続するかによって異なります。

設定
Monitoring Kerberos Principal
Kerberos プリンシパル。
Monitoring Keytab Path
監視のキータブへの絶対ファイル P パス。
Monitoring LDAP Group DN

モニタリングのLDAPグループの識別名を入力します。

次に、モニタリング に適切な特権を付与するために、 LDAPグループ DN は MongoDB でロールとして作成されます。

LDAP 認可を使用する場合は、LDAP グループ DN を指定する必要があります。

設定
Monitoring Username
Active Directory ユーザー名。
Monitoring Password
Active Directory のパスワード。
Domain
Active Directory ドメイン サービス内のドメインの NetBIOS 名。 すべて大文字でなくてはなりません。
設定
Monitoring Username
モニタリングの PEM キー ファイルから生成された LDAP v 識別名を入力します。3
Monitoring PEM Key file
適切なオペレーティング システムの行で、サーバー上のモニタリングのPEMキー ファイルのパスとファイル名を指定します。
Monitoring PEM Key Password
PEMキー ファイルが暗号化されている場合は、そのファイルにパスワードを入力します。
Monitoring LDAP Group DN

モニタリングのLDAPグループの識別名を入力します。

LDAP 認可 を使用する場合は、モニタリングの LDAP グループ DN のみを指定する必要があります。

オートメーションを使用せず、バックアップを使用する配置の認証情報を追加するには、次の手順に従います。

1
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーの Continuous Backup をクリックします。

    [継続的なバックアップ ]ページが表示されます。

2
3
設定
Backup Username
バックアップ ユーザー名を入力します。
Backup Password
バックアップ ユーザー名のパスワードを入力します。
設定
Backup LDAP Username
LDAPユーザー名を入力します。
Backup LDAP Password
バックアップのLDAPユーザー名 のパスワードを入力します。
Backup LDAP Group DN

バックアップのLDAPグループの識別名を入力します。

LDAP 認可 を使用する場合にのみ、バックアップの LDAP グループ DN を指定します。各バックアップは を持ち、独自のLDAPグループDNを使用する必要があります。

必要な値は、Linux 提供のKDCに接続するか、Windows Active Directory Server に接続するかによって異なります。

設定
Monitoring Kerberos Principal
Kerberos プリンシパル。
Monitoring Keytab Path
バックアップのキータブへの絶対ファイル P パス。
Monitoring LDAP Group DN

バックアップのLDAPグループの識別名を入力します。

次に、バックアップに適切な特権を付与するために、 LDAPグループ DN はロールとして MongoDB で作成されます。

LDAP 認可を使用する場合は、LDAP グループ DN を指定する必要があります。

設定
Backup Username
Active Directory ユーザー名。
Backup Password
Active Directory のパスワード。
Domain
Active Directory ドメイン サービス内のドメインの NetBIOS 名。 すべて大文字でなくてはなりません。
設定
Backup Username
バックアップの PEM キー ファイルから生成された LDAP v3 識別名を入力します。
Backup PEM Key file
適切なオペレーティング システムの行で、サーバー上のバックアップのPEMキー ファイルのパスとファイル名を指定します。
Backup PEM Key Password
PEMキー ファイルが暗号化されている場合は、そのファイルにパスワードを入力します。
Backup LDAP Group DN

バックアップのLDAPグループの識別名を入力します。

LDAP 認可を使用する場合は、バックアップの LDAP グループ DN を指定する必要があります。

戻る

移行ホストの使用