MongoDB Ops Managerのレプリケーションクラスター構築 #mongodb
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
MongoDB Enterprise Advanced(EA)では、クラスタ―の構成、ユーザ管理、監視、アラート、バックアップ&リストアなどのサービスをすべてOps Manager(GUI)で操作できます。これらのサービスをGUIで操作する場合のメリットは、熟練した技や経験がない人でも高度なオプレーションができることでしょう。今回は、MongoDBのレプリケーションクラスタの構築方法をご紹介します。
事前準備
通常、MongoDBのレプリケーションセットは、最低3台のサーバーで構成します。
- ここでは、Azure CloudのVMでCentOS7.2を利用しています。
- 動作検証ぐらいであれば、サーバーのスペックはあまり気にする必要ありません(1vCPU以上, メモリ4G以上)。
ここでは、Standard D2s v3 (2 vcpu 数、8 GB メモリ)を利用しています。 - ネットワーク構成は、Ops Managerがインターネットに出られることが前提です。各サーバーはインターネットに繋がらない状況でも結構です。Ops Managerから必要なインストールパッケージをダウンロードするからです。
もちろん、Ops Managerもインターネットに出られない環境でも、手間はかかりますがOps Managerは利用できます。 - Ops Managerに関しては、「MongoDB Enterprise Advanced(EA)版の管理ツール、Ops Managerインストール」を参照してください。
プロジェクトの選択
Ops Managerでクラスタ―は、プロジェクトの配下に配置します。
- 既にクラスタ―が存在するプロジェクトの配下に新たなクラスタ―を追加することはできません。
- プロジェクトは、必要に応じて追加できます(関連記事:MongoDB Ops ManagerのGUI構成)
ここでは、プロジェクト1(Project1)を利用します。
クラスタ―の作成開始
左メニューのデプロイメント(Deployment)をクリックし、クラスタ―作成を開始します。
ロケーションの選択
Deploy In Other Remoteを選択します。
デプロイタイプの選択
Create Replica Setを選択します。
クラスタ―構成の設定
名称とレプリカ数、MongoDBのデータベースファイルの格納先(Data Directory)を設定します。
- Data Directory Prefixは、MongoDBのデータベースファイルを格納するディレクトリを指定します。
バックアップオプションの選択
Ops Managerを利用してバックアップを取るかどうかはオプションであり、クラスタ―構築後にも設定できますので、ここでは「NO」で進みます。
オートメーション・エージェントのインストール
クラスタ―を構築するノード(サーバ)に、それぞれオートメーションエージェントをインストールします。
次のようにサーバーの台数分のダイアログボックスが表示されます。
同じ設定を1台ずつ実行していきます。
OSを選択すると、インストール方法が表示されます。
1.Download the agent
この作業は、Ops Managerでガイドしている内容に従って、各サーバーにログインし、手動で実行します。
$ curl -OL http://39.39.39.14:8080/download/agent/automation/mongodb-mms-automation-agent-manager-4.5.14.5266-1.x86_64.rhel7.rpm $ sudo rpm -U mongodb-mms-automation-agent-manager-4.5.14.5266-1.x86_64.rhel7.rpm
2.Create Agent API key
APIキーを生成します。APIキーは、各サーバーがOps Managerに接続するときの認証キーです。
APIキーは、Ops Managerのプロジェクト毎に作成します。
APIキーの作成権限があるかどうか聞かれます。
ここには、Ops Managerのアカウントのパスワードを入力します。
[注意]
API Key作成は、同じクラスタ―内では1回でいいです。同グループのなかではキーを共有します。
3.Next, Open the config file
上記の2で、パスワードが正しければ、次のようにグループIDとパスワードが生成されます。
API Keyを/etc/mongodb-mms/automation-agent.configに格納してください。
/etc/mongodb-mms/automation-agent.config
mmsGroupId=5b98eec48266061f9dba9f1b mmsApiKey=5bd2df5e8266060687467421e9f99b4bf092bd7aac4c65396dffadb1 mmsBaseUrl=http://39.39.39.14:8080
この設定は、同プロジェクトのレプリケーションクラスタ―の仲間であることを識別するものです。
同レプリケーションクラスタ―の各サーバーには同じ設定を行います。
4.ディレクトリ作成
MongoDBのデータベースファイルの格納先を指定します。
/data/配下に、必要なフォルダは自動的に構成されます。
$ sudo mkdir -p /data $ sudo chown mongod:mongod /data
5.Start the Agent
オートメーションエージェントを起動します。
各サーバのオートメーションエージェントは、Ops Managerと連絡を取り合いながら様々なサービスを提供してくれます。
$ sudo systemctl start mongodb-mms-automation-agent.service $ sudo systemctl enable mongodb-mms-automation-agent.service
最後にVerify Agentをクリックすると、Ops Managerとのマッピンが行われます。
次は、1台が成功した状態です。
1台ずつ、3台の設定を実行していきます。
次は、3台にオートメーションエージェントの起動が成功した状態です。
Continueをクリックすると、レプリケーションクラスタ―の構成準備に入ります。
デプロイ実行
ここでオートメーションエージェントは、Ops ManagerからMongoDBのインストールパッケージをダウンロードして各サーバにインストール及びクラスタ―の構成を行います。
Deployを実行すると、しばるくの間、クラスターの構成が行われます。
クラスタ―構成が完了したら、次のような一覧表示になります。
オプションの追加
クラスタ―の構成直後では、オートメーションエージェントとMongoDBプロセスのみが有効になっています。
Ops Managerでクラスタ―の監視とデータバックアップを行うどうかはオプションです。
Ops Managerで監視やバックアップを実行するためには、各サーバー上でエージェントの起動が必要です。
Serversタブを選択してください。
メニュー[…]からMonitoring AgentやBackup Agentが構成できます。
対象選択するだけでは、デプロイは実行されません。明示的にデプロイを実行する必要があります。
次のようなメッセージが画面の上段に表示されます。クリックしてください。
デプロイが完了したエージェントは、次のように画面上で確認できます。
MongoDBへの接続
最後の締め括りとして、MongoDBに接続してみます。
レプリケーションクラスターのプロセス一覧からプライマリノードのメニュー[…]をクリックし、Connect to Instanceを選択します。
次ような接続文字列が表示されます。メモ帳に控えておきましょう。
$ mongo --host rep2.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net --port 27000
この接続文字列のURLは、MongoDBのクラスタ―を構成しているサーバーのなかでのみ有効になっています。
外部からの接続のためには、DNS登録が必要です。こちらのURLを参照してください。
https://docs.opsmanager.mongodb.com/v3.6/tutorial/connect-to-mongodb/
では、サーバーにログインし、MongoDBに接続してみます。
この段階では、認証モードをオンにしていないので、ノーパスワードでログインできるはずです。
[centos@rep1 ~]$ mongo --host rep2.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net --port 27000 MongoDB shell version v3.6.8 …略 myrepl1:PRIMARY> myrepl1:PRIMARY> show dbs admin 0.000GB config 0.000GB local 0.000GB myrepl1:PRIMARY> rs.config() { "_id" : "myrepl1", "version" : 1, "protocolVersion" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "rep1.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net:27000", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "rep2.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net:27000", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "rep3.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net:27000", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 1 }
まとめ
このようにOps Managerを利用することでMongoDBのレプリケーションクラスターが簡単に構築できます。クラスタ―の構築だけではなく、起動と停止、パラメター設定(mongod.conf)、バージョン管理などもすべてOps Manager上のメニュー(GUI)で実行できます。一切、コマンドを打つ必要はありません。運用管理に携わる人に取って、何等かのメンテナンスのためにコマンドを実行したり、パラメータを変更したりする作業は、常にリスクを伴うことであり、知識として維持管理するための努力も必要になります。Ops Managerは、運用管理に携わる人の負荷を大幅に軽減してくれるでしょう。