IDCFクラウドに少しずつ環境を構築していっている。何よりもまずDNS環境を既存環境から移行させてしまいたい。クラウド上の2台のサーバにbindで立てたDNSをインターネット上からも問い合わせ出来るようにする。仮想ルータでのラウンドロビンはUDPに対応していないため設定できない。2台間のロードバランスはLVSに任せる。そのLVSのVIPにNATする形でインターネットからのアクセスを設定する。しかし、仮想ルータによるNATは仮想サーバのNICにアサインされているIPアドレスにしか繋げることが出来ない。なので、IDCFクラウドのAPIを利用してVIPに対するNATを設定する必要がある。
これらの方法もIDCFクラウドのブログにやり方が乗っているので、それを参考にする形で進めることが出来た。最初にcloudstack-apiのインストールを行うが、pythonで用意されたモジュールなので、pythonの環境から構築していく。pipに必要なパッケージをインストールして、pipを使ってcloudstack-apiをインストールする。インストールが出来たら、ホームディレクトリに.idcfrcというファイルを用意して、host情報やapi_key, secret_keyを記載しておく。
yum install --enablerepo=epel python-pip libxml2-devel libxslt-devel python-devel
pip install git+https://github.com/idcf/cloudstack-api
※以下のURLでapi_keyとsecret_keyを確認。
https://console.idcfcloud.com/user/apikey
vi ~/.idcfrc
:
[account]
host=https://compute.jp-east.idcfcloud.com/client/api
api_key=xxxx
secret_key=xxxx
chmod 600 ~/.idcfrc
以上で準備完了。続いて、cloudstack-apiコマンドを使用して、仮想サーバのidを確認。そのidからipaddressとNICのidを確認。確認したNICに対して、NAT用のVIPを付与する。NICのIP一覧を表示して、追加したIPアドレスが存在することを確認する。
cloudstack-api listVirtualMachines -t displayname,id
cloudstack-api listNics --virtualmachineid aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee -t ipaddress,id
cloudstack-api addIpToNic --nicid ffffffff-gggg-hhhh-iiii-jjjjjjjj --ipaddress 10.0.1.1
cloudstack-api listNics --nicid ffffffff-gggg-hhhh-iiii-jjjjjjjj --virtualmachineid aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
これでグローバルIPにNAT可能なVIP用のプライベートIPを払い出せた。このVIPをLVSでロードバランスするためのIPアドレスとして利用する。LVS側の準備が終わったら、実際にVIPに対してグローバルIPをNATする。グローバルIPのidを確認。そのidに対して先ほどのVIPのidを紐付ける。
cloudstack-api listPublicIpAddresses -t ipaddress,id
cloudstack-api createPortForwardingRule --ipaddressid kkkkkkkk-llll-mmmm-nnnn-vvvvvvvv --privateport 53 --protocol udp --publicport 53 --virtualmachineid aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee --vmguestip 10.0.1.1
これでNATの設定が完了。ウェブUIの仮想ルータ管理画面でも仮想サーバとのマッピングは確認できる。設定が正しければ、インターネット経由で名前を引く事も可能なはず。このNAT作業そのものは期待通りの動きだったが、LVSを挟んだが故の問題にすぐに気付いてしまった。
bindは外向け、中向け兼用でソースIPによって返すゾーンを切り替える形を取っている。いわゆるmatch-clientsを使ってviewを切り替えるという方法だ。しかし、LVSを経由するようにしたことで、すべてのリクエストソースがLVSのホストIPになってしまった。つまり、中向けのviewでしか処理されなくなってしまった。
bindはansibleで構築しているので機械的に外用のゾーンも生成されているため、自分のFQDNが引けなくなるという事態は起きなかったが、中向けのviewなのでローカルゾーンの名前を引く気になれば引けてしまう。更には中向けにresolverも開放しているので、完全にオープンリゾルバ状態。何かしらの修正を早々に打つ必要があった。方法は幾つかなくはなかったが、どれも構造を複雑化するものばかり。詳細は次回にでも。