おじさんスペック
- 全盛期使っていたのはRHEL4~6時代
- KVMでホストOSに仮想マシンを4~10台立てて別のホストとPacemakerで冗長化したことある
- 各仮想マシンの中でもPacemakerでApp起動順序制御やリソース監視したことある
- 触ったことがあるPamcemakerは
crm_mon
時代
何をやるのか
現状の構成
- 1台のWindows Serverに以下の3つのコンポーネントが存在
-
Node.js
で作成したメインApp。RestAPI。 PostgreSQL Server
-
Flask(Python)
で作成した管理画面 onvenv
-
こうしたい
※まだDocker
とか何も学んでいないので正しい構成であるかは不明
- ホストOSは
Ubuntu
。いずれUbuntu
向けにしか提供されていないOSSを使う可能性があり、不慣れだがいまのうちから利用しておく -
PostgreSQL Server
はレプリケーションで同期する - 2つのホストは
IPaddr2
で論理IPをつけ外しする - ホストのIFは2~3
- 業務NW
- データ同期NW
- ハートビートNW
- いずれ他拠点にDRを構築し2:1構成もあり得るのでデータ同期NWは業務NWに乗せることも考えている。
- 業務NWは既設だが、データ同期NWは新規に作るためDR先まで伸ばすのしんどい
知識を身につけよう
k8sを知ろう
本当にPacemaker
使わなきゃいかんのか。Kubernetes
はクラスタリングソフトになる?Docker Engine
とContainer
の間のコントローラ?
を、ここ2~3日ずっと悩んでいた。調べるとクラスタソフトぽく見えるが、Kubernetes
自身の冗長化が考慮されていない。ただのコントローラなのか?コントローラであれば、使うべきなのか。
というのが記載されていると期待する資料がこちら。
コンテナを止めるな! PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは
読んだ感想は以下
-
Kubernetes
は安全な場所master
で稼働させる必要がある -
Kubernetes
は DB のようなStateful
なものを複数ノード上でACT/SBY
制御させるのに一工夫必要そう -
DB
などStateful
なコンポーネントがクラウドのサービスで起動しているシステムであれば良さそう
つーことで、草案の Pacemaker + Docker
は概ねあってそう。
PacemakerによるDockerの制御サポート状況を知ろう
Pacemaker
はデフォルトで様々なOSSを制御するコントローラ(Resource Agent
とか呼ばれているやつ。IPアドレスの着け外しをするIPaddr2
もその1つ)を持っている。きっとDocker
サポートもしてるんだろう、という予測を立ててそのあたり調べていく。
そして見つけたのがこちら。あ、Pacemaker
がDocker
をサポートするんじゃなくて、Docker
がPacemaker
をサポートするんだ?w
9.5. Docker コンテナーの Pacemaker サポート (テクノロジープレビュー)
読み始めると記憶にないPacemakerのBundle
という単語。なんだっけこれ。
いままさに知りたい情報だった。Pacemakerがコンテナを制御するためのツールキットで、内部的にはIPaddr2
など既存のリソースの寄せ鍋のようだ。
1点、コンテナの中にpacemaker_remote
なるものを入れないといけないらしい。これはBundle
を試すうちに通る道のようなのでいまはスルー。
PostgreSQL ServerのDBは何処に置く?
コンテナの中に入れてたんじゃ停止/起動で情報が消失してしまう認識。たぶんホストの指定したディレクトリをコンテナがマウントしてDBのデータ部分を置くんだろうな。と予想しながら調べていく。
もやぁ~んと見えてきたイメージは以下のとおり
-
docker
の種ディレクトリをホストOS上に作成 -
docker-compose.yml
というコンテナのレシピ帳をディレクトリに配置 - ディレクトリ内にコンテナがマウントしてデータを置くディレクトリを作る
-
Dockerfile
というものがある。使わなくてもいい
やっぱりホストの一部をマウントするんだね。じゃあホストOSインストール時にパーティション構成は真面目に考えておいたほうが良さそうだな。あんまり設定ファイル類とDB領域を同じパーティションに置きたくないんだけどなぁ。
docker-compose.ymlとは、Dockerfileとは
1つ目の参考URLがとてつもなくわかりやすいのでオススメ。今回、Node.js App
やFlask App
をコンテナ化する必要があるが、一度やりゃいいわけではなく継続して何度もコンテナ再構築が必要。なのでコンテナレシピ帳であるDockerfile
は絶対的に必要。
docker-compose.yml
は作成したコンテナのイメージをどう活用するか(環境設定など)なのでこれまた必要。どちらかではなく両方とも必要。
(再度)PacemakerによるDockerの制御サポート状況を知ろう
コンテナをPacemaker
で使う上ではBundle
というものを使うことはわかった。それはいつどうやって使う?コンテナに組み込む?
何やらPacemaker bundle
で扱うDocker
イメージにはpacemaker-remote
というもののを詰め込む必要があるらしい。ので、これについて調べる。
- 他ノードリソース制御機能「pacemaker_remote」とは?
- 9.4. pacemaker_remote サービス
- 30.3. Pacemaker リモートノードの設定
- 第30章 corosync 以外のノードのクラスターへの統合: pacemaker_remote サービス
- How to install pacemaker-remote on Ubuntu
私が現場でPacemaker
を扱っていた際は冒頭の自己紹介に書いたとおり、Pacemaker
をホストOS, ゲストOS両方に入れて、ホストOSがゲストOSのリソースを制御できるようリソースアダプタを自作していた(先輩が)。これがもう公式サポートされているようだ。ありがたい。
ホストOSとコンテナ(pacemaker_remote
が導入されている)の通信は/etc/pacemaker/authkey
に格納した情報をもとにTLS通信されるらしい。これらがセットアップされなければ通信はできないということ。
Ubuntuを知る
インフラ系で検索しているとよくヒットする。綺麗に中級~上級向けに書いていただいているので私にはピッタリ。らぶ。
作業計画を立てる
必要なアクションは見えてきた。これらを整理すると以下の検証が必要そうだ。
- Dockerイメージの作成
- Dockerイメージ作成環境の構築
- Dockerイメージ作成
- PostgreSQL Server
- Node.js App
- Flask App
- pacemaker_remote インストール
- Dockerイメージ起動検証
- Pacemakerホストの作成
- Ubuntuインストール
- Pacemakerインストール
- Dummyリソースで操作検証
- Bundleの作成
- 動作検証
後半の解像度が低いがだいたいこんなの。目安として2日ぐらいでなんとか片付けたい。