OpenStackでVIP冗長構成を作る

sozai.002

このエントリはOpenStack Advent Calender 2015の12/21のエントリです。今日はOpenStack運用ではまりがちなallowed-address-pairsについて書いてみようと思います。なお本エントリの内容はOpenStack Havanaを前提に記載しています。 allowed-address-pairsとは OpenStackでは各インスタンスにポートを紐付けることにより、インスタンスは外部と通信が可能となります。そしてポートは基本的に1ポートに1つのIP、1つのMACアドレスが割り当てられています。allowed-address-pairsとはそのポートに紐付ける拡張アドレスのようなもので、例えばAというポートに10.1.1.1のIPが紐付いている場合に、Aに対してallowed-address-pairs=10.1.1.2を紐付けると、ポートAは10.1.1.1と10.1.1.2の通信が可能になります。具体的な用途としてはkeepalivedなどを用いてVIPを使用した冗長構成を取る場合に、VIPをallowed-address-pairsとして利用することが多いです。 設定方法 python-neutronclientで下記のコマンドを発行することでallowed-address-pairsを追加することが出来ます。 neutron port-update xxxxx-xxxx-xxxxx --allowed-address-pairs type=dict list=true ip_address=10.1.1.2 また解除する場合は空白を設定します。 neutron port-update xxxxx-xxxx-xxxxx --allowed-address-pairs '' やっていはいけない落とし穴 一見便利に見えるこの機能ですが、SecurityGroup(SG)のremote-groupと組み合わせて使用する場合は注意が必要です。 allowed-address-pairsの実際の動きとしてはcompute-nodeのiptablesにallowed-address-pairsで指定したIPアドレスのPermitルールが追加されます。この設定を一つ間違えると全てのポリシーが許可されてしまうケースが有ります。下記の図はLAN内のinternal-serverがインターネット上のサービスexample-serviceと通信する際の通信とIPヘッダを記載しています。 往路のパケットに関しては特に特別なことはなく、通常のNAT通信です。しかし、戻りのパケットを見てみましょう。 注目すべきはnat → internal serverの通信です。ここでのfrom ipはexample serviceのipとなるため、natサーバのinterfaceからexample serviceのipで通信するためには、allowed-address-pairsに0.0.0.0/0を追加する必要があります。これはexample serviceはインターネット上のサービスであり、あらゆるIPになり得るためです。またallowed-address-pairsを追加しない場合、natサーバのinterfaceからOpenStackの管理しないIP(200.200.200.200)のパケットが送出されたことになり、デフォルトのポリシーでパケットが捨てられてしまいます。 さて、natサーバに0.0.0.0/0のallowed-address-pairsが追加されたことにより、natサーバが存在するcompute-nodeには0.0.0.0/0からのip通信が許可される設定が追加されています。この状態でSecurity Groupのremote-groupを利用した場合に、なんと0.0.0.0/0のipを持つホストからの通信が許可されてしまうという状態に陥るケースが有ります。 remote-groupとは 公式ドキュメント リモートグループは許可されたソースの CIDR を動的に定義する方法です。ユーザーがリモートグループ (セキュリティグループ名) を指定します。これにより、指定されたリモートグループを使用する、ユーザーの他のインスタンスが動的にすべて選択されます。この動的な選択により、クラスターのそれぞれの新しいメンバーを許可する、個別のルールの必要性を軽減できます。 通常Security Groupは例えば22番ポートを10.10.10.0/24のアドレス帯からのみ許可するといったSecurity Group定義を行うのですが、10.10.10.0/24の部分をSecurity Groupの名前で定義出来たりします。例として2つのポリシーを挙げてみます。 Security Group名:ssh ポート:22 許可IP: 10.10.10.0/24 Security Group名:proxy ポート:80 リモートグループ:ssh この定義をした場合、proxyルールを持つインスタンスはsshルールが割り当てられたインスタンス全てにポート80番の通信を許可すると言った挙動をします。しかし、これは裏の動きは単純にsshルールが割り当てられたインスタンスのIPから80番ポートに対して許可するiptablesが書かれているだけに過ぎません。先のnatサーバに話を戻しましょう。 natサーバの管理するアドレス eth0:100.100.100.100 eth1:10.10.10.10 allowed-address-pairs: 0.0.0.0/0 この状態でnatサーバにSecurity

More

Pecの最近のバージョンアップ事情

どもー。 年末になり一層イケメンに磨きがかかってきました山下です。 今回は僕が開発し、メンテナンスしているOpenStackのインスタンス作成ラッパーのPecの最近のバージョンアップについてまとめてみました。 記事を書いた時点の最新バージョンは0.8.1です。 各コマンドに指定できるホスト名が動的に 例えばこれまでは、各コマンドに渡せるホスト名は一つでFQDNでした。 $ pec status example.foo.jp Current machine status: example.foo.jp ACTIVE muumuu m1.small nova comp-node.local 10.10.10.1 これが複数渡せるようになったり、 $ pec status example.foo.jp example.bar.jp Current machine status: example.foo.jp ACTIVE muumuu m1.small nova comp-node.local 10.10.10.1 example.bar.jp ACTIVE muumuu

More

openstackのkey-pairをAuthorizedKeysCommandに利用する

スクリーンショット 2015-08-09 18.04.36

どもっす。 夏休み2日目のP山です。 以前LDAP周りのログイン調べてた時にうっかり気づいた、sshd_configのAuthorizedKeysCommandで openstackのkey-pair(ユーザーに紐づくssh公開鍵)をそのまま使えたら便利じゃないのかということで goで書いてみました。 使い方 まず/etc/ssh/openstack-ssh.confを作成してください。 auth_url = "http://your-api-host:35357/v2.0" user = "your name" password = "your password" tenant = "your tenant" region = "your region"(default regionOne) あとは/etc/ssh/sshd_configに下記を追加 RSAAuthentication no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys AuthorizedKeysCommand /path/to/openstack-ssh AuthorizedKeysCommandUser nobody ChallengeResponseAuthentication no PasswordAuthentication

More

VMを作っては壊すPecというコマンドを作った。

どうも! イケメンの申し子P山です。 現在ペパボではOpenStackを用いてプライベートクラウドを絶賛構築中でして、 その中でVMををガンガン作ってガンガン壊してニヤニヤするためにコマンド作ってみました。 インストール $ gem install specific_install $ gem specific_install 'git@github.com:fog/fog.git' $ gem install pec specific_installを利用する理由はfogというgemを使用していて、 PRがmasterに取り込まれはしているのですが、 月に一回くらいのリリースのようなので、とりあえず今はgitからmasterブランチをインストールしてます。 (今時点でgem installされるfogだとSecurity Groupが適用されない) 追記 specific_installするとうまく動かないケースがあるので、その場合は抜いてください。 使い方 サンプル設定ファイルの作成と接続先の設定 pec initコマンドを実行すると対話式で接続先のAPIの設定を行ったり、 サンプルファイルが作成されます。 $ pec init Start Configure by OpenStack openstack auth_uri: http://your-api-url:35357/v2.0/tokens openstack username: pyama openstack api_key: your_password openstack tenant: your_tenant Configure Complete! create directry user_datas create configure

More

OpenStack上でLinuxルーター作る時の知見とか

スクリーンショット 2015-04-05 18.26.27

ども。 昨夜は17時から飲み始め、22時前には潰れるという最高な週末でした、 P山です。 週末にかけて、OpenStackでOpenVPNのスループット取ろうと思って、 VPNルーターを作った際にハマった知見をご紹介します。 構成図 ネットワーク 仮想インターネット 210.252.100.0/24 SiteA-Internal 192.168.0.0/24 SiteB-Internal 172.16.0.0/24 ホスト SiteA-vpn-host 210.252.100.2 / 192.168.0.7 SiteB-vpn-host 210.252.100.101 / 172.16.0.5 SiteB-host 172.16.0.8 やりたかったこと SiteA-vpn-hostとSiteB-vpn-hostを仮想Internet上でVPNセッションを結び、 それぞれのサイトにhostを設置して、SiteA-hostとSiteB-host間の通信のスループットを取ろうと思っていました。 ルーティング設定は正常に行われています。 切り分けをわかりやすくするため、SiteB-hostからSiteA-vpn-hostへの通信を、SiteB-vpn-hostを経由するルーティングへと変更します。 SiteB-hostのルーティング設定 この時点でSiteB-hostからSite-A-vpn-hostへpingを打つと、 疎通がありません。 SiteB-vpn-host上でのtcpdump 仮想インターネット側 SiteA-vpn-host(210.252.100.2)に対して確かにパケットを送信しています。 SiteA-vpn-host上でのtcpdump 少なくとも、SiteB-vpn-hostはSiteB-hostからのパケットをSiteA-vpn-hostに送っていますが、 SiteA-vpn-hostに到達していないことから、通信経路がこのパケットの送信を許可していないことがわかります。 このことから仮説として、OpenStackのネットワークは自身が管理していないサブネットをFromIPかDestIPに持つパケットの送信を許可していないのではないかと思えます。 仮説の検証として、SiteB-vpn-hostのインターネット向けの通信をIPマスカレードしてみます。 再度tcpdumpを取ると、 SiteB-vpn-host上でのtcpdump 仮想インターネット側 先ほどと状況が変わり、SiteA-vpn-host(210.252.100.2)からパケットが戻ってくるようになりました。 SiteA-vpn-host上でのtcpdump こちらも問題なくパケットが到達するようになりました。 ただやはり、FromIP 210.252.100.2 DestIp

More

Ubuntu 13系から14系へバージョンアップとOpenStack構築

キャプチャ

やりたいこととか 先日書いたロードマップの検証やるために久しぶりに家のサーバを起動した。 作りたいのはWEBサーバとNginXを持ったテナントを自由に作ったり壊したり出来たりする環境が欲しくて。 ubuntuの13.10使っていたのだけど、14系だったらコマンド数発でopenstack入るらしいのでコマンド叩いて、バージョンアップした。 見ているとエラーがちらほら出ていましたが、家のサーバなのでガンガン進める。 再起動したところ、こんなメッセージで起動しなくなったorz [Shell] Nov 23 13:52:14 openstack dbus[449]: [system] Activated service \’org.freedesktop.ConsoleKit\’ failed: The permission of the setuid helper is not correct [/Shell] 休みの日に/var/log/syslog分析してトラブルシュートする活力なんて無いので、とりあえずyoutubeでテンション上げる。 1.テンション上がったので対処する パーミッションっぽいので、ネットで調べて下記を投入 [Shell] chmod u+s /usr/lib/dbus-1.0/dbus-daemon-launch-helper [/Shell] これで起きくるかな・・・なんて思ってたら、 [Shell] saned disabled; edit /etc/default/saned [/Shell] とかいって止まってる。 調べるとグラフィック系のドライバの問題らしかったです。 そもそも14系のアップデートで何個かエラー発生してたからそこが悪さしてるっぽい。 失敗してた分を強制的に入れて、グラフィックドライバの再インストールを試みる。 あとはとりあえず起きてきたらエラー対応すっかぐらいのスタンスで作業継続。 [Shell] apt-get -f install sudo apt-get purge nvidia-current sudo apt-get install nvidia-current [/Shell] 画面が起動してきたのであらためて、再度バージョンアップし直す。 [Shell] root@openstack:/etc/update-manager$ do-release-upgrade 新しい

More

Ubuntu 13.10にOpenStackインストール ~Glance編~

だいぶ停滞していましたが、時間が作れたので今日は Glanceをインストールしていきます。 Glanceというのは仮想マシンのイメージを管理するサービスらしいです。 実際の動きは今後確認していきたいと思います。 今日の動画は秦基博 鱗。 何度聞いてもいい声してますねー。 まずはDBの作成から 設定ファイルにDBの接続設定を追記 設定入れたらテーブルを作成する #商用に入れたらぶっ飛ばされそうなパスワードなのは仕様です(キリッ ここまで出来たら、次は先日構築したkeystoneにユーザーを作成して、 ロールを割り当てていきます。 ユーザーが無事作成できたら先ほど触ったglance-api.conf と glance-registry.conf に 認証情報を記載する項目があるので、編集していきます。 続いてkeystoneにサービスとして登録します。 先日も作成したエンドポイントの作成(APIのアクセスURL) 最後にサービスの再起動 ここから動作試験です。 cirrosという非常に軽量なLinuxOSで確認していきます。 root@openstack:~# mkdir images root@openstack:~# cd images/ root@openstack:~/images# wget http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img #glanceに標準出力を介してアップロードする root@openstack:~/images# glance image-create \ > –name=”CirrOS 0.3.2″ \ > –disk-format=qcow2 \ > –container-format=bare \ > –is-public=true < cirros-0.3.2-x86_64-disk.img +------------------+--------------------------------------+ | Property

More