Glitch

MySQL, MongoDB, Python, Go

MongoDB Ops ManagerでSharded Cluster Automation Deployしてみた。

多分Cloud版MMSの人は既に使ってるかもしれないんですけど、On-Premises版のOps Managerが出たのでAutomationをやってみました。 いわゆる使ってみた系記事です。

やり方はOps ManagerのDocument通りなので、スクショ取りながら備考録。

Install直後

f:id:okdtsk:20150305153902p:plain

Automation, Backup, Monitoring なんか左から順番にやりたくなりがちですが、全て揃えなければいけないわけでなくて、Monitoringだけでも十分だと思います。 Automationは簡単に色々Deployできるのですけど、手動で作業しないといけなかったり、再起動がかかったりとかあるので、ちゃんと理解してから使ったほうがいいなと思いました。 既にMongoDBで色々運用されている場合は手助けになるかと思います。 BackupはCloudだと有料サービスだったと思うんですけど、On-PremisesだとStorageの見積もりとかいろいろ準備が必要なので、今回は試していません。

Automation configuration

今回はAutomationに絞って紹介するので、AutomationをGET STARTED。

Deploy Destination

f:id:okdtsk:20150305154343p:plain

Localは自分の今接続しているPCにAutomation AgentをInstallして、自分のlocalにMongoDB (cluster)をSetupします。テスト用ですね。 Remoteの他のいろんなServerにDeployする場合はOther Remoteを選択してください。 こんかいはこっち。

Deploy Type

f:id:okdtsk:20150305154636p:plain

次にSetupするMongoDBの種類を選びます。

  1. Standalone
    mongod1 Processだけインストールします。
  2. Replica Set mongod を奇数台インストールして、Replica Setを構築します。
  3. Sharded Cluster 指定したShard数分のReplica Setと、mongos、そしてConfig Serverを構築します。 立ち上がるProcess数は、mongod (replSet * shard + 3 config) + mongos (任意) 分です。 config serverはServer数によって1台となる時もあります。

今回はSharded Clusterを選択しました。

Sharded cluster configuration

f:id:okdtsk:20150305155203p:plain

Sharded cluster全体の設定を行います。 今回Cluster NameとShard Name Prefixを同じにしていますが、分けたほうが良かったかなーと思います。 dbPathが/data/mongodb/test-sharded/{Cluster Name}_{Shard Name Prefix}_{Shard num}_{ReplSet num}/となるためです。 ShardやNodeの数は後で増やせるので最小でもOKかと。（画像の設定が最小です）

Install automation agent

f:id:okdtsk:20150305155951p:plain

各ServerにAgentをInstallする画面です。 これは各Serverに入って手動でやることとなります。 まぁただ手順はコピペ+config file数行編集で終わります。

f:id:okdtsk:20150305161014p:plain

Server上でAutomation Agentが起動されて、Verifyされるとこんなかんじで●がついて、次のServerのAgentがDownloadできるようになります。 ちなみにI have [***] severs:の部分を変更すると、実際のServer数を変更できます。 Process数自体は先の手順である程度決まっていますが、MongoDBは同じServer上に複数のmongod/mongosを共存させることができるので、それぞれの環境に合わせて変更してください。 今回はtestなので、1にします。

f:id:okdtsk:20150305161407p:plain

Directoryについて

MongoDB binaryなどをインストールするディレクトリはDefaultで/var/lib/mongodb-mms-automationです。 これを変更する場合は[Administration] → [Agents] → [Binary Download Directory]で変更できます。 気づきにくいので変更する場合は注意してください〜。

Review & Deploy

f:id:okdtsk:20150305161440p:plain

Deploy確認画面です。 ここでどのServerにどのProcessをInstallするかをDrag&Dropで変更することができます。 （今回は1台しかないのでそのままです）

CNAME

この画面でCNAMEに関するWarningが出ています。 これはMongoDB Config ServerのHAに関するものです。 簡単に説明すると、障害などでConfig ServerをReplaceするときに、mongosのconfigDBで設定した値をOnlineで変更することができないため、同一のHostnameを持つようDNSなどで設定が必要になります。 もし、mongosのconfigDBを変更するとしたらCluster全体の再起動が必要となります。 このため、Production環境ではCNAMEをすべてのConfig Serverに割り当てておく必要があります。 （今回はTestのためCNAME割り当てずに進めています）

Deployment

f:id:okdtsk:20150305162435p:plain

Deployが開始されると、Ops Managerと各Server上のAutomation Agentで通信して、MongoDBのSetupが始まります。 しばらく待てば以下の様な画面でDeployが完了されます。 （大体2-3分程度で終わった）

f:id:okdtsk:20150305162649p:plain

この状態でview modeにするとMonitoringのSetupも既に完了されていることが確認できます。 あとは使うだけ、と言った感じですね。

とりあえず完全まっさらなServerに対して新規にMongoDB clusterを構築するところまでやりました。 昨今だといろんなToolでDeploy自動化されてたりすると思うんですけど、MongoDBは1つのServer上に色々なProcess走らせたりするので、こういう選択肢もあっていいかなと。

でも、先述したとおり変更に対する影響はしっかり考えなければいけないです。 「Deployおわらないｗｗｗ」で調べたら「データ消さないといけないｗｗｗｗｗｗｗｗ」になるパターンも簡単に再現できます。（当たり前ですけどStorage Engine変更とか）

現状だとConfigurationがDefaultのままなので、次はCluster全体にいろいろ設定を変更させてみようと思いますー。