MongoDB の構成
単一MongoDBインスタンスを使用する場合、簡単かつ素早く構成することができます。
しかし、もし、当該ホストおよびMongoDBインスタンスに対する予期せぬ問題により、プロセスがdownされるなどの障害が発生したり、データの流失が発生することがあります。
これに備えるために、様々な種類のDBMSと同様、MongoDBも複製構成によるDB HA(High Availability)機能を使用することができます。 こうして構成されたグループはReplica Setといい、さらに多数のReplica Setを一緒に構成してクエリーの分散処理とScale outに有利に構成した形をSharded Clusterと呼びます。
この章では、Replica SetとSharded Clusterに対する構成方法を説明します。
Replica Set(RS) の構成
一つのReplica Setはこれを構成する3つ以上のMemberで構成されており、個々のMemberは3つのうちrole(Primary、Secondary、Arbiter)の一つの役割をします。
(詳しくは https://docs.mongodb.com/manual/core/replica-set-members/index.htmlを参考)
それぞれのroleによってReplica Set構成に差があることがありますが、主に3つのMemberについてP-S-A(Primary-Secondary-Arbiter)またはP-S-S(Primary-Secondary-Secondary)構成が一般的です。
ここではP-S-A構成について説明します。
DBサーバーで使用するサーバー2台、そしてArbiterサーバーで使用する1台を準備します。
インストール型MongoDBがインストールされている状態、DBプロセスをshutdownした状態
- DBプロセスshutdownする方法 :
- ]$ mongod --shutdown –f /home/mongodb/db/config/mongod.conf
- DBプロセスshutdownする方法 :
Arbiterは、primaryおよびsecondaryのデータを複製せず、プロセスだけで存在し、primaryに問題が生じ、fali-overが発生した時に投票するだけの役割なので、高性能DBサーバーを使用しなくてもいいです。
後述するSharding構成時、Router、Config ServerのようなDBサーバー内に構成する場合も多いです。
MongoDB replica set 3代のデーモン設定ファイル(/home/mongodb/db/config/mongod.conf)を下記のように設定します。(YAML形態)
例: /home/mongodb/db/config/mongod.conf
systemLog: destination: file path: "/home/mongodb/db/log/mongod.log" logAppend: true logRotate: rename storage: engine: wiredTiger directoryPerDB: true wiredTiger: engineConfig: journalCompressor: snappy collectionConfig: blockCompressor: snappy indexConfig: prefixCompression: true dbPath: "/home/mongodb/db/data" journal: enabled: true commitIntervalMs: 300 processManagement: fork: true pidFilePath: "/tmp/mongod.pid" net: port: 27019 bindIpAll: true maxIncomingConnections: 20000 unixDomainSocket: enabled: false replication: oplogSizeMB: 10240 replSetName: "rstest01" setParameter: failIndexKeyTooLong: false同じReplica Setのメンバーで構成するためにはreplication項目の下のreplSetNameが同一しなければなりません。(例示ではrstest01という名で使用)
mongodb shard serverのポートは基本的に27019です。 基本ポート以外の他のポートを使用することをお勧めいたします。
設定が終わった後、MongoDBのデモンを駆動します。(3機すべて)
- ]$ numactl --interleave=all mongod -f /home/mongodb/db/config/mongod.conf &
駆動が終わったらprimaryDBとして使用するサーバーからmongod shellにアクセスします。(DB名:admin)
- mongoshell 接続方法: mongo < IP または localhost >:< PORT >/DB名
- ]$ mongo localhost:27019/admin
該当mongo shell内から下コマンドを通じてReplica Setを設定します。(ここではprimaryとsecondary、計2台)
> rs.initiate( { _id: "ReplicaSet명", version: 1, members: [ { _id: 0, host : "<primaryIP>:<PORT>" }, { _id: 1, host : "<SecondaryIP>:<PORT>" } ] } )この例題でprimary/secondary/arbiterで使用する装備のIP情報が以下のとおりで、27019 Portを使用する場合、
- Primary: 192.10.10.11
- Secondary: 192.10.10.12
- Arbiter: 192.10.10.13
シェルでは下記のように入力します。 (_id’ フィールド値は、上記のmongod.confのreplcation.replSetName値です。)
rs.initiate( { _id: "rstest01", version: 1, members: [ { _id: 0, host : "192.10.10.11:27019" }, { _id: 1, host : "192.10.10.12:27019" } ] } )実行結果のメッセージ 「ok」を確認しした後、しばらくしてprimary および secondary の MongoDB shell にアクセスし、prompt が変更されていることを確認します。
"rstest01:PRIMARY > " または "rstest02:SECONDARY> "
PrimaryおよびSecondaryの状態を確認後、下記のようにArbiterを追加します。(2つの方法すべて同じ動作であるため、この中に一つだけを実行すればいいです)
Arbiter 追加
rs.addArb("192.10.10.13:27019") または rs.add( { host: "192.10.10.13:27019", arbiterOnly: true } )
構成がうまく完了したか、下記のコマンドを確認します。**
RS 状態確認
rstest01:PRIMARY> rs.status()
root権限を持つ管理アカウントを作成します。
ユーザー作成
use admin db.createUser( { user: "<アカウント名>", pwd: "<パスワード>", roles: ["root" ] } )アカウントおよびパスワードを'user'/'0000'に作成する場合は、下記のように入力します。(admin DBで遂行)
use admin db.createUser( { user: "user", pwd: "0000", roles: ["root" ] } )
primaryで任意のデータをinsertし、secondaryでデータが入力されているかを確認します。
primary 接続後
db.testcol.insert("seq" : 1)Secondary 接続後
use test rs.slaveOk() db.testcol.find({})
Sharded Cluster の構成
もし使用したいmongodbで処理すべきデータ量が多く、分散処理が必要な場合など、一つのreplica Setだけでは運営に困難がある場合、mongodbで提供する「Sharding」機能を使用することができます。
Sharding機能を利用して多数のreplica setを分散構成した形態を"Sharded Cluster"と呼び、これはMongoDBの中核機能の1つです。
Sharded Clusterで必ず必要なmemberは以下の通りです。
① Router(= MongoS):応用またはユーザーが接続するポイント クエリーを受けて必要な時にはConfig Serverの分散情報を参照して適切なShard(Replica Set)で伝え、ユーザーに結果をリターンする役割
② Config Server: Sharded Clusterで、複数の分散されたShard情報を保存し、管理します。 一つのsharded clusterに config serverは、一つの setだけを構成すればよいでしょう。
③ 1つのグループ以上のShard(=Replica Set):複数のReplica SetにClusterを構成します。 それぞれのReplica SetをShardと呼びます。
ここでは以下のように構成する例を説明します。
Replica Setを構成します。
"Replica Set(RS)の構成"を参考にして2つのReplica Set(計6台)を構成します。 但し、設定ファイル(/home/mongodb/db/config/mongod.conf)内に下記の設定を追加して駆動します。
sharding: clusterRole: shardsvr例: /home/mongodb/db/config/mongod.conf
systemLog: destination: file path: "/home/mongodb/db/log/mongod.log" logAppend: true logRotate: rename storage: engine: wiredTiger directoryPerDB: true wiredTiger: engineConfig: journalCompressor: snappy collectionConfig: blockCompressor: snappy indexConfig: prefixCompression: true dbPath: "/home/mongodb/db/data" journal: enabled: true commitIntervalMs: 300 processManagement: fork: true pidFilePath: "/tmp/mongod.pid" net: port: 27019 bindIpAll: true maxIncomingConnections: 20000 unixDomainSocket: enabled: false replication: oplogSizeMB: 10240 replSetName: "rstest01" setParameter: failIndexKeyTooLong: false sharding: clusterRole: shardsvrMongodb駆動後、各Replica Setメンバーすべてに接続し、PRIMARY、SECONDARY、ARBITERの有無がすべて確認されれば、shardとして使われるreplica setのインストールが完了します。
config serverの構成
- 1.Config serverはSharded Cluster一つの中にたった一つのset万の構成します。 Config serverもreplica setと同様、互いに複製される構成です。 したがってインストール方法もreplica set構成と類似していて、上記の「Replica Set(RS)の構成」を参考にして1つのconfig server(計3台)を構成します。 但し、config server構成時には、P-S-Aではなく、P-S-Sの形で構成します。
ここではRouter(MongoS)がインストールされる装備3台にそれぞれConfig serverの各メンバーをP-S-S-の形で構成する例を説明します。
mongodb デモン設定ファイル(/home/mongodb/db/config/mongod.conf) とは別の設定ファイルを作成します。(/home/mongodb/db/config/configserver.conf)
例: /home/mongodb/db/config/configserver.conf
storage:
dbPath: "/home/mongodb/db/configdata"
journal:
enabled: true
systemLog:
destination: file
path: "/home/mongodb/db/log/configlog.log"
logAppend: true
processManagement:
fork: true
net:
bindIpAll: true
port: 27018
replication:
oplogSizeMB: 40960
replSetName: "cstest"
sharding:
clusterRole: "configsvr"
例題ではconfig serverのポートを基本ポートの27018に設定しました デフォルトポートではない他のポートに設定することをお勧めします。
sharding.clusterRoleは"configsvr"に設定します(上記の例示で、replica setに設定したDBサーバーのsharding.clusterRole値("shardsvr")と差があります。）
config serverで使用するmongodbデーモンが駆動されると、primaryで使用されるmongodb sheelの中で以下のように複製グループを設定します。
この例題でconfig serverで使用するprimary/secondary/secondaryで、使用する装備のIP情報が以下のとおりで、27017 portを使用する場合、
config server 構成情報(例示)
- Primary: 192.10.10.14
- Secondary: 192.10.10.15
- Secondary: 192.10.10.16
シェルでは以下のように入力します。('_id' フィールド値は上のconfigserver.confのreplication.replSetName値)
rs.initiate( { _id: "cstest", version: 1, members: [ { _id: 0, host : "192.10.10.14:27018" }, { _id: 1, host : "192.10.10.15:27018" }, { _id: 2, host : "192.10.10.16:27018" } ] } )上記のコマンドの実行後、結果が「ok」であるかを確認した後、しばらくしてprimaryおよびsecondary MongoDB shellにアクセスし、promptが変更されているかを確認します。
例: ]$ mongo localhost:27018/admin
“cstest:PRIMARY >” または “cstest:SECONDARY> “
Router(=MongoS) の構成
routerで使用されるサーバーの両方で(現在例示では3台)mongod.conf、configserver.confと同様に、同じディレクトリにrouter設定ファイルを作成します。(/home/mongodb/db/config/mongos.conf)
sharding項目はすでにインストールされたconfig server情報を入力し、net.port項目はrouterポート(ユーザ及びアプリが接続するポート)に使用する情報を入力します。(例示では27017)
sharding:
configDB: "cstest/192.10.10.14:27018,192.10.10.15:27018,192.10.10.16:27018"
systemLog:
destination: file
path: "/home/mongodb/db/log/mongos.log"
logAppend: true
processManagement:
fork: true
net:
port: 27017
bindIpAll: true
maxIncomingConnections: 30000
setParameter:
ShardingTaskExecutorPoolHostTimeoutMS : 3600000
ShardingTaskExecutorPoolMaxSize : 20
ShardingTaskExecutorPoolMinSize : 10
設定が終わった後routerのデモンを駆動します。(3機すべて駆動、mongodがなくmongosコマンドに注意)
- $] numacl --interleave=all mongos -f /home/mongodb/db/config/mongos.conf &
駆動が終わったら、primaryDBとして使用するサーバーからmongo shellへアクセスします。(DB名:admin)
mongo shellアクセス方法: mongo
: /DB名 例示) ]$ mongo localhost:27017/admin
Routerおよびconfig serverで管理するSharding情報(Replica Set)情報を入力します。
(routerのshell(ここでは port:27017) 接続後
sh.addShard("<replica_set>/<hostname><:port>,<hostname><:port>,…")
例:
// 第一のreplica set 入力(Arbiterを除外したPrimary及びSecondary情報だけ入力)
sh.addShard("rstest01/192.10.10.14:27019,192.10.10.15:27019")
// 第二のreplica set 入力(Arbiterを除外したPrimary及びSecondary情報だけ入力)
sh.addShard("rstest02/192.10.10.114:27019,192.10.10.115:27019")
root権限を持つ管理アカウントを作成します。
use admin db.createUser( { user: "<アカウント名>", pwd: "<パスワード>", roles: ["root" ] } )例:アカウントおよびパスワードを「user」/「0000」に作成する場合は、下記のように入力します。(admin DBで遂行)
use admin db.createUser( { user: "user", pwd: "0000", roles: ["root" ] } )その後、shardingに関するコマンドは下記の公式マニュアルにてご参考ください。
(https://docs.mongodb.com/manual/reference/method/js-sharding/)
認証モード適用
上記の構成段階までは、一種の「非認証モード」であり、ユーザーアカウント認証がなくても、ほぼすべての管理者権限を使用することができます。
セキュリティ面においてこれを防止し、ユーザー認証(アカウント/パスワード)モードを適用するためには、以下のような設定段階が追加的に行われなければなりません。
任意の装備からキーファイルを作成します。
例:
]$ openssl rand -base64 755 > /home/mongodb/db/config/mongodb-keyfile作成された派である(/home/mongodb/db/config/mongodb-keyfile)を全てのmongodbの装備にコピーします。
各設定ファイルに以下の項目を追加します。
shard 設定(/home/mongodb/db/config/mongod.conf)
security: keyFile: /home/mongodb/db/config/mongodb-keyfile authorization: enabledconfig server 設定(/home/mongodb/db/config/configserver.conf)
security: keyFile: /home/mongodb/db/config/mongodb-keyfile authorization: enabledrouter 設定(/home/mongodb/db/config/mongos.conf): authorization: enabled 項目除外
security: keyFile: /home/mongodb/db/config/mongodb-keyfile
すべての装備でプロセス再スタート
shard 再スタート**
mongod --shutdown -f /home/mongodb/db/config/mongod.conf numactl --interleave=all mongod \ -f /home/mongodb/db/config/mongod.conf &config server 再スタート
mongod --shutdown -f /home/mongodb/db/config/configserver.conf numactl --interleave=all mongod \ -f /home/mongodb/db/config/configserver.conf &router 再スタート(ps コマンドで mongosの PIDを確認後)
kill <PID> numactl --interleave=all mongod \ -f /home/mongodb/db/config/mongos.conf &
