MongoDB Ops Managerのシャーディングクラスター構築 #mongodb

MongoDB Enterprise Advanced(EA)では、クラスタ―の構成、ユーザ管理、監視、アラート、バックアップ&リストアなどのサービスをすべてOps Manager（GUI）で操作できます。これらのサービスをGUIで操作する場合のメリットは、熟練した技や経験がない人でも高度なオペレーションができることでしょう。今回は、MongoDBのシャーディングクラスターの構築方法をご紹介します。一般的にシャーディングクラスタ―は、レプリケーションクラスタ―よりも構成が複雑でであり、当然、構築手順も複雑だと言われています。

事前準備

通常、MongoDBのシャードは、最低2シャード（1シャードは最低3台のレプリケーションセット）で構成しますが、今回は1シャード構成にしてます。Ops Managerでシャードの追加は、クラスタ―構築後に簡単にできます。

• ここでは、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構成）

クラスタ―の作成開始

左メニューのデプロイメント(Deployment)をクリックし、クラスタ―作成を開始します。

ロケーションの選択

Deploy In Other Remoteを選択します。

デプロイタイプの選択

Create Sharded Clusterを選択します。

クラスタ―構成の設定

今回は、1シャード構成にします。シャード毎のノード数は3台にします。

• Shard Name Prefixは、与えた名称でshard_nのように複数のシャードに対しては一連番号を付けます。
• Data Directory Prefixは、MongoDBのデータベースファイルを格納するディレクトリを指定します。

バックアップオプションの選択

Ops Managerを利用してバックアップを取るかどうかはオプションであり、クラスタ―構築後にも設定できますので、ここでは「NO」で進みます。

オートメーションエージェントのインストール

クラスタ―を構築するノード（サーバ）に、それぞれオートメーションエージェントをインストールします。
次のようにサーバーの台数分のダイアログボックスが表示されます。

同じ設定を1台ずつ実行していきます。
OSを選択すると、インストール方法が表示されます。

1.Download the agent

この作業は、Ops Managerでガイドしている内容に従って、各サーバーにログインし、手動で実行します。

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=5b18bcbe8266061139991169
mmsApiKey=5b9647d88266060743c137fa228d83281940b7d5203abe2bdc97cb55
mmsBaseUrl=http://<Public IP>.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台ずつ、3台の設定を実行していきます。

次は、順次に3台を構成した状態です。

Continueをクリックすると、シャーディングクラスタ―構成の準備に入ります。

デプロイ実行

Continueをクリックすると、最後のデプロイ段階になります。既に、シャーディングクラスタ―の3大要素であるsyard、config、mongosの配置が見えているはずです。

• shard
  シャーディングキー(index)でデータを分散していくパーティションのようなものです。

• config
  クラスタ―の構成情報やメターデータを格納するMongoDBです。通常、レプリケーションセットで構成し、mongodのサーバーに相乗りさせます。ポート番号を分けることで干渉しないようにします。

• mongos
  MongoDBのドライバ―から分散シャードに接続するときにプロクシサーバーの役割を果たすシンプルなプロセスです。configを束ねて構成します。ここでは、クラスタ―の1ノードに相乗りさせるような配置になっていますが、クラスタ―構築後に変更可能です。
  mongosの配置は、クラスタ―のノード、アプリケーションサーバ、専用サーバーなどどちらでも良く、冗長化するのが推奨です。ただし、とても大規模のシャーディングクラスタ―ではなければ、専用サーバにする必要はありません。

  

デプロイを実行すると、しばらくの間、クラスタ―構築が行われます。ここでオートメーションエージェントは、Ops ManagerからMongoDBのインストールパッケージをダウンロードしてきます。デプロイが終了したら、次のように一覧が表示されます。

オプションの追加

メニュー[…]からMonitoring AgentとBackup Agentをインストールできます。

とちらもオプションですが、Monitoring Agentをインストールしないと各ノードからメトリックの収集が始まりません。Backup Agentのインストールは、バックアップ設定を行う時に実行すれば良いです。

オプションを選択するだけは、デプロイは実行されません。明示的にでデプロイを実行する必要があります。
次のようなメッセージが画面の上段に表示されます。

次は、デプロイが終わった状態です。

mongosへ接続

シャーディングクラスタ―でMongoDBに接続するときは、mongos(プロクシ)経由で行います。次のように接続文字列を取得します。

この文字列をメモ帳に控えて置きましょう。

sh1-repl1-node1.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net --port 27017

この接続文字列のURLは、MongoDBのクラスタ―を構成しているサーバーのなかでのみ有効になっています。
外部からの接続のためには、DNS登録が必要です。こちらのURLを参照してください。

https://docs.opsmanager.mongodb.com/v3.6/tutorial/connect-to-mongodb/

では、サーバーにログインし、MongoDBに接続してみます。
この段階では、認証モードをオンにしていないので、ノーパスワードでログインできるはずです。

 # mongo --host sh1-repl1-node1.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net --port 27017
MongoDB shell version v3.6.5
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.6.5
Server has startup warnings:
2018-06-23T14:13:14.085+0000 I CONTROL  [main]
2018-06-23T14:13:14.085+0000 I CONTROL  [main] ** WARNING: Access control is not enabled for the database.
2018-06-23T14:13:14.085+0000 I CONTROL  [main] **          Read and write access to data and configuration is unrestricted.
2018-06-23T14:13:14.085+0000 I CONTROL  [main]
mongos> show dbs
admin   0.000GB
config  0.001GB
mongos> db
test
mongos>
mongos> sh.status()
--- Sharding Status ---
  sharding version: {
        "_id" : 1,
        "minCompatibleVersion" : 5,
        "currentVersion" : 6,
        "clusterId" : ObjectId("5b2e55784443efb07ce17eb1")
  }
  shards:
        {  "_id" : "shard_0",  "host" : "shard_0/sh1-repl1-node1.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net:27000,sh1-repl1-node2.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net:27000,sh1-repl1-node3.yrsxoknhfgeebiaegsok4me0xc.lx.internal.cloudapp.net:27000",  "state" : 1 }
  active mongoses:
        "3.6.5" : 1
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  no
        Failed balancer rounds in last 5 attempts:  0
        Migration Results for the last 24 hours:
                No recent migrations
  databases:
        {  "_id" : "config",  "primary" : "config",  "partitioned" : true }
                config.system.sessions
                        shard key: { "_id" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                shard_0 1
                        { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : shard_0 Timestamp(1, 0)
mongos>

まとめ

このようにレプリケーションクラスター構築よりもはるかに複雑なはずのシャーディングクラスタ―の構築が簡単にできます。Ops Managerでシャーディングクラスタ―を構築すると、レプリケーションクラスター構築 の手順とも酷似しているし、しかもシンプルなので凄さが殆ど伝わらないのではないかと心配になるぐらいです。しかし、これらの手順をコマンドで実行する場合に比べると雲泥の差があります。クラスタ―の構築だけではなく、シャードの追加やパラメター設定(mongod.conf)、バージョン管理なども、一切、コマンドを打つ必要はありません。運用管理に携わる人に取って、何等かのメンテナンスのためにコマンドを実行したり、パラメータを変更したりする作業は、常にリスクを伴う作業であり、知識として維持管理するための努力も必要になります。Ops Managerは、運用管理に携わる人の負荷を大幅に軽減してくれるでしょう。