IDCFクラウド上での環境構築を着々と進めている。構成管理ツールをansibleに切り替えてから、初めてのクラウド環境対応なので、わりと細かいところから修正している。そもそも自宅環境とクラウド環境をVPNで繋いで、仮想的なプライベート・ネットワークを作るかどうかも悩んだ。現時点ではクラウドの独立性を優先して、それぞれ個別に環境を作っている。chefではリッチなサーバ環境を安価なクラウドで用意できなかったので、この辺りはansibleの軽量さに感謝している。ansibleの処理そのものを別管理にするのはコストが大きいので、同じgitで管理してhostsファイルを自宅環境とクラウド環境で違える形を取った。処理ロジックの中では、ansible_domainを使って処理分岐や変数の変更を行っている。例えば、こんな感じ。

---
- hosts: hostserver
  roles:
  - host
  - grub
  - glusterfs
  - { role: lvs,  when: inventory_hostname in groups.lvs     }
  - { role: s3fs, when: ansible_domain == domains.idcf.name  }
  - { role: api,  when: ansible_domain == domains.idcf.name  }

GMOクラウドでもそうしたように、今回もサーバ1からサーバ2を構築、或いはその逆が可能な形で構築する。kickstart環境の準備とansibleでそれを実現する。GMOのときはメモリ不足でinstall方法を工夫する必要があったが、今回は特に問題なし。オブジェクトストレージを使ってcentosのbaseリポジトリをまるっと中に用意することもできた。サーバ1でもサーバ2でもオブジェクトストレージをs3fsマウントすれば、どちらにもローカルyumリポジトリがあるような状態になる。あとはどちらにもansible環境を入れておけば、kickstart後の起動処理内でansibleを呼び出して必要なセットアップを済ますことが出来る。

今回工夫したかったのは、yumリポジトリやkickstart処理内で参照するサーバのIPアドレスである。自宅と違ってDHCP環境はありものを使わないとならないため、DNSはクラウド内のものを使ってしまう。自前で用意したDNSは使えないので、IPアドレスでURL等のポインタを用意してあげる必要がある。まだ2台のみなので、サーバ1にはサーバ2のIP、サーバ2にはサーバ1のIPでkickstart処理を用意すれば、お互いに動作させることは可能だがスケールしないのも微妙。という訳で、LVSの利用を思い立った。

自分の記事を見返すと使っていたのは7年前くらいｗ 自宅環境でサービスを作らなくなってから使うシーンもなく、すっかりロストテクノロジーと化していた。それを見直し始めたのは他にも理由があって、その1つがDNSの冗長化だ。DNSの冗長化はresolv.confで何個かnameserverを記載する形で実現する。しかし、1番目のDNSが落ちている場合、そのタイムアウトを待ってから次に問い合わすので正直使い物にならない。IDCFクラウドの仮想ルータがUDPのロードバランスには対応していないようなので、丁寧な冗長化をやるならLVSかなと考えていた。

一応、今時のロードバランス事情も軽く調べてみたが、UDPのロードバランスを考えると他にはnginxのTCP/UDPプロキシくらいしか見当たらなかった。nginxはどうせ構成要素として含まれるので、そちらを試してみてもよかったのだが、少ないノード数で実現する場合、プロキシに本来のポートを取られてしまうのが嫌だった。ポートやIPアドレスをずらしてLISTENさせる運用は事故の元なので出来れば避けたい。その点、LVSはiptablesのNATで振り分けてくれるので、その辺りに融通が利く。LVSの利用に関しては、IDCFクラウドの紹介記事もあるので実現性は高そう。実際には少し異なる方法を取ったが、具体的な構成は次回にでも。