第3回:Eucalyptusのクラウドネットワーク


Eucalyputsの仮想ネットワーク構成

 今回は、Eucalyptusの仮想ネットワーク構成について見ていきます。「ユーカリプタス入門」第1回で触れられているように、Eucalyptusではネットワーク構成の種類(ネットワークモード)を選択することができます。

 ここでは、Amazon EC2に最も近いネットワーク環境を提供する「MANAGEDモード」を前提とします。MANAGEDモードでは、【図3-1】のようにクラスタコントローラがパブリックネットワークとプライベートネットワークを中継するルータの役割を果たします。iptablesによるNATとパケットフィルタリングに加えて、タグVLANの利用などLinuxのさまざまなネットワーク機能が活用されています。

【図3-1】MANAGEDモード

 【図3-1】では、クラウドコントローラ、Walrus、ストレージコントローラの各コンポーネントは省略されています。一般的な配置は、第1回の【図1-1】を参照してください。最も単純な構成では、これらのコンポーネントを【図3-1】のクラスタコントローラと同じサーバーに同居させる事も可能です。

 VMインスタンスのネットワーク通信には、プライベートネットワーク用のネットワークスイッチを介して行うVMインスタンス間のプライベートネットワーク通信と、クラスタコントローラをルータとしてパケットの中継を行うパブリックネットワーク通信があります。

 「ユーカリプタス入門」第2回のVMインスタンス起動手順にあるように、VMインスタンスの起動時には「セキュリティグループ」を指定します。セキュリティグループは、プライベートネットワーク通信とパブリックネットワーク通信のそれぞれに対して、次のような機能を提供します。

(1)同じセキュリティグループに属するVMインスタンス同士のみにプライベートネットワーク通信を許可する。
(2)セキュリティグループごとにパブリックネットワークからの接続に対するファイアウォール・ルールを設定する。

 Eucalyptusは、セキュリティグループごとに異なるプライベートネットワーク用のサブネットとVLAN番号をアサインすることで(1)を実現します。(2)については、ルータとして機能するクラスタコントローラ上でiptablesのパケットフィルタリングを利用します。

 

タグVLANによるプライベートネットワーク通信の分離

 ここでは、(1)の仕組みについて解説します。まずはじめに、タグVLANについて復習しておきます。もともとVLANは、1台のネットワークスイッチの内部に独立した複数の仮想ネットワーク(VLAN)を構成するための技術です。

【図3-2】ネットワークスイッチ間の接続にタグVLANを使用する例

 例えば、【図3-2】のスイッチ#1の内部には2種類のVLAN(VLAN100とVLAN200)が定義されています。この時、ポート1とポート2に対して「ポートVLAN100」の設定を行い、ポート3とポート4に対して「ポートVLAN200」の設定を行うと、各ポートはスイッチ内部で対応するVLANに接続されます。これにより、ポート1とポート2、ポート3とポート4のペアのみで通信が可能になります。ポート1とポート3に接続したサーバー同士は通信することはできません。

 次に、スイッチ#1と同じ設定を行ったスイッチ#2を用意して、この2台をそれぞれのポート5同士でカスケード接続します。この時、この1つのカスケード接続で、VLAN100とVLAN200の両方をスイッチ間接続するために利用するのがタグVLANです。それぞれのスイッチのポート5に対して「タグVLAN」の設定を行うと、ポート5はスイッチ内部でVLAN100とVLAN200の両方に接続されます。

 そして、スイッチ#1がVLAN100からやってきたパケットをスイッチ2に転送する際は、「VLAN100」というタグをパケットにつけてポート5から送出します。スイッチ#2がポート5でこのパケットを受け取ると「VLAN100」というタグを確認して、(このタグを一旦はずした上で)スイッチ内部のVLAN100にこのパケットを送ります。VLAN200についても同様です。

 この場合、VLANタグのついたパケットが流れるのは、カスケード接続したケーブル上だけである点に注意してください。ポートVLANの設定を行ったポートに出入りするパケットにはVLANタグはついていません。

 これはネットワークスイッチ間の接続にタグVLANを使用する例です。一方、サーバー仮想化環境では、同一の物理サーバー上で稼働する複数の仮想マシンについて、仮想マシンごとに異なるVLANに接続するためにタグVLANを使用することがあります。少し複雑ですが、まずは【図3-3】を見て下さい。この図はKVM仮想化環境を想定していますが、ホストLinuxをドメイン0と読み替えればXen環境にもあてはまります。

【図3-3】同一の物理サーバー上で稼働する複数の仮想マシンについて、仮想マシンごとに異なるVLANに接続するためにタグVLANを使用する例

 ホストLinux上の「VLANデバイス」は、VLANタグの付いたパケットを扱うための仮想NICです。このサーバーの物理NIC(eth0)は、スイッチ#1のタグVLANの設定をしたポートに接続していますので、スイッチからはVLANタグのついたパケットが送られてきます。この時、VLAN100のタグが付いたパケットを受け取ると、eth0.100のVLANデバイスに転送されて、VLANタグが取り外された後に仮想ブリッジを経由して、仮想マシン#1に送られます。

 逆に、仮想マシン#1から送信されたパケットは、eth0.100でVLAN100のタグを付与されて、eth0からスイッチ#1に送信されます。このようにして、仮想マシン#1は、スイッチ#1のVLAN100(ポート1、ポート2)に接続されたサーバーのみと通信を行います。VLAN200についても同様です。

 そしていよいよ、EucalyptusにおけるタグVLANの利用方法です。【図3-4】がその全体像です。【図3-2】と【図3-3】の説明を思い出しながら、どのような仕組みか想像してみてください。ここでは、2種類のセキュリティグループに属するVMインスタンス群が起動しています。VMインスタンス#1、#2、#5、#6は同じセキュリティグループに属しており、互いに通信が可能です。同様に、VMインスタンス#3、#4、#7、#8が同じセキュリティグループに属しています。

【図3-4】EucalyptusにおけるタグVLANの利用方法

 ノードコントローラ#1のVMインスタンス#1、#2は、仮想ブリッジeucabr10を経由して、VLAN10に属するVLANデバイス(eth0.10)に接続されています。したがって、これらから送信されたパケットは、ネットワークスイッチ内部のVLAN10を経由して、ノードコントローラ#2に転送されます。ノードコントローラ#2には、VLAN10のタグが付いたパケットが送られるので、eth0.10からeucabr10を経由してVMインスタンス#5、#6にパケットが到達します。

 このようにセキュリティグループごとに異なるVLANに接続することで、セキュリティグループ間で通信を分離しています。なお、VMインスタンス#1と#2が通信する際は、ノードコントローラ#1の仮想ブリッジeucabr10を経由して、直接、パケットを交換します。また、VLAN10とVLAN11は独立したネットワークですので、異なるサブネットのIPアドレスを使用する必要があります。Eucalyptusでは、セキュリティグループごとに使用するサブネットを自動的に決定して、該当するサブネットのIPアドレスをVMインスタンスに割り当てます。

 ここで、プライベートネットワーク用のネットワークスイッチの設定に関する注意点があります。【図3-4】からわかるように、ノードコントローラ(およびその他のEucalyptus関連サーバー)を接続するポートはタグVLANの設定を行い、Eucalyptusが使用する範囲のVLANを全て受け付けるように設定しておく必要があります。

 一方、家電量販店で販売されているようなVLAN機能を持たないスイッチングハブを使用する場合は、そのまま接続するだけでうまく動作する場合があります。これは、VLANタグ付きのパケットを受け取ったスイッチが、VLANタグを単純に無視して、VLANタグを付けたままパケットを転送するためです。とはいえ、あくまで結果的にうまくいっているだけで、全てのスイッチングハブがこのような動作を行う保証があるわけではありません。

 本番環境でEucalyptusを使用する場合は、VLAN機能を持ったネットワーク・スイッチをタグVLANの設定を適切に行った上で使用することをお勧めします。

 最後に、ノードコントローラ上で実際にVLANデバイスや仮想ブリッジが構成されている様子を見ておきます。次は、図3-4と同じ状態のノードコントローラ上でのコマンド実行結果です。

# ifconfig | grep eth0
eth0      Link encap:Ethernet  HWaddr 00:14:5E:16:1A:E4
eth0.10   Link encap:Ethernet  HWaddr 00:14:5E:16:1A:E4
eth0.11   Link encap:Ethernet  HWaddr 00:14:5E:16:1A:E4

# ifconfig | grep eucabr
eucabr10  Link encap:Ethernet  HWaddr 00:14:5E:16:1A:E4
eucabr11  Link encap:Ethernet  HWaddr 00:14:5E:16:1A:E4

# brctl show
bridge name     bridge id               STP enabled     interfaces
eucabr10        8000.00145e161ae4       no              vnet2
                                                        vnet1
                                                        eth0.10
eucabr11        8000.00145e161ae4       no              vnet3
                                                        vnet0
                                                        eth0.11

 最初のコマンドから、物理NIC(eth0)に対して、VLAN10とVLAN11のVLANデバイス(eth0.10、eth0.11)が構成されていることがわかります。

 次のコマンドでは、仮想ブリッジeucabr10とeucabr11の存在がわかります。最後のコマンドは、それぞれの仮想ブリッジに接続しているデバイスを表示しています。vnetXはVMインスタンス内部の仮想NICに接続されたTAPデバイスですので、ちょうど【図3-4】のeucabr10、eucabr11に対応する状態になっていることがわかります。

 

NATによるパブリックネットワーク通信

 続いて、VMインスタンスとパブリックネットワークの通信について解説します。「ユーカリプタス入門」第2回でVMインスタンスを起動する例が紹介されています。そこでは、起動したVMインスタンスの情報がeuca-describe-instancesコマンドで次のように表示されています。

# euca-describe-instances
RESERVATION r-35CC06E6 vtaro default
INSTANCE i-410306FC emi-330411BE 192.168.32.200 10.1.2.2 pending key01 0 m1.small 2010-06-24T13:46:41.218Z cluster0 eki-5E491255 eri-596A123C

 これより、このVMインスタンスには、パブリックIPアドレス192.168.32.200とプライベートIPアドレス10.1.2.2が割り当てられていることがわかります。ところが、実際にVMインスタンスにログインしてifconfigコマンドでIPアドレスを確認すると、プライベートIPアドレスの10.1.2.2しか割り当てられていません。パブリックIPアドレスはどこにあるのでしょうか? 【図3-5】にその答えがあります。

 各VMインスタンスのパブリックIPアドレスは、実はクラスタコントローラのパブリックネットワーク側の物理NIC(eth0)に対して割り当てられています。図では、クラスタコントローラ自身のIPアドレス192.168.32.20に加えて、2個のVMインスタンスのパブリックIPアドレス192.168.32.200、192.168.32.201があります。

【図3-5】NATによるパブリックネットワーク通信

 クラスタコントローラは、パブリックネットワークからパブリックIPアドレス192.168.32.200宛のパケットを受信すると、DNAT(宛先アドレス変換)によって、このパケットの宛先を対応するVMインスタンス#1のプライベートIPアドレス10.1.2.2に変換して、ノードコントローラへと転送します。

 逆に、VMインスタンス#1がパブリックネットワーク宛のパケットを送信すると、クラスタコントローラはSNAT(送信元アドレス変換)によって、このパケットの送信元をパブリックIPアドレス192.168.32.200に変換した後にパブリックネットワークに送信します。

 この時、クラスタコントローラとVMインスタンス間の通信は、プライベートネットワークを通じて行われます。プライベートネットワーク上の通信はVLANを使用する必要がありますので、クラスタコントローラ上にも必要なVLAN番号のVLANデバイスとそれに接続する仮想ブリッジが構成されます。

 図の例では、eth1.10とeucabr10になります。この時、eucabr10に対してもIPアドレス10.1.2.1が割り当てられますので、VMインスタンス側では、このIPアドレスをデフォルト・ゲートウェイに指定します。VMインスタンスからこのゲートウェイに到達したパケットに対して、SNATの変換が行われます。

 それでは、クラスタコントローラ上で実際の設定の様子を見ておきます。まず、eth0に割り当てられたパブリックIPアドレスは次のコマンドで表示します。iproute2と呼ばれるツールで設定されているため、通常のifconfigコマンドでは表示されないので注意してください。パブリックネットワーク側の物理NIC(eth0)に図3-5と同じ3種類のIPアドレスが割り当てられていることがわかります。

# ip addr show eth0
2: eth0:mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1a:64:6e:4e:b9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.32.20/24 brd 10.255.255.255 scope global eth0
    inet 192.168.32.200/24 scope global eth0
    inet 192.168.32.201/24 scope global eth0
    inet6 fe80::21a:64ff:fe6e:4eb9/64 scope link
       valid_lft forever preferred_lft forever

 次に、プライベートネットワーク経由でVMインスタンスと通信するためのVLANデバイスと仮想ブリッジは、次のコマンドで確認できます。VLANデバイスeth1.10が仮想ブリッジeucabr10に接続されており、仮想ブリッジに対して、プライベートIPアドレス10.1.2.1が割り当てられていることがわかります。

# ifconfig eth1.10
eth1.10 Link encap:Ethernet HWaddr 00:1A:64:6E:4E:BA
inet6 addr: fe80::21a:64ff:fe6e:4eba/64 Scope:Link
(以下省略)

# ifconfig eucabr10
eucabr10 Link encap:Ethernet HWaddr 00:1A:64:6E:4E:BA
inet addr:10.1.2.1 Bcast:10.1.255.255 Mask:255.255.0.0
(以下省略)

# brctl show
bridge name     bridge id               STP enabled      nterfaces
eucabr10        8000.001a646e4eba       yes             eth1.10

 そして、DNAT/SNATの設定は、iptablesによって行われます。DNATとSNATは、それぞれnatテーブルのPREROUTINGチェーンとPOSTROUTINGチェーンに対して設定します。テーブルやチェーンなどiptablesの詳細は次回に改めて説明します。

 ここでは、まずは設定の状況を確認しておきます。次は、VMインスタンス#1、#2のそれぞれに対するDNAT/SNATの設定内容です。IPアドレス10.1.2.2、10.1.2.3を含む部分が該当する設定になります。その他にも管理目的用の設定が含まれています。

# iptables -t nat -nL PREROUTING
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  10.1.0.0/16          169.254.169.254     tcp dpt:80 to:169.254.169.254:8773
DNAT       all  --  0.0.0.0/0            192.168.32.200      to:10.1.2.2
DNAT       all  --  0.0.0.0/0            192.168.32.201      to:10.1.2.3

# iptables -t nat -nL POSTROUTING
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  10.1.2.2            !10.1.0.0/16         to:192.168.32.200
SNAT       all  --  10.1.2.3            !10.1.0.0/16         to:192.168.32.201
MASQUERADE  all  -- !127.0.0.0/8         !10.1.0.0/16

 

ファイアウォール・ルールによるアクセス制限

 最後に(2)の設定について説明します。これは、パブリックネットワークからVMインスタンスへの接続を制限するための仕組みですので、図3.5において、eth0からeucabr10にパケットを転送する部分にiptablesのパケットフィルタリングを適用すればよいことになります。これは、FORWARDチェーンに対して設定します。

 次は、adminユーザのdefaultグループに対して、22番ポートへの接続を許可した状態での設定状況です。FORWARDチェーンから「admin-default」というユーザ定義チェーンが呼び出されており、この中で22番ポートへの接続を許可しています。一般に、「ユーザ名-セキュリティグループ名」というユーザ定義チェーンが追加されていきます。

# iptables -nL FORWARD
Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           ctstate ESTABLISHED
ACCEPT     all  --  0.0.0.0/0           !10.1.0.0/16
ACCEPT    all  --  10.1.2.0/27          10.1.2.0/27
admin-default  all  --  0.0.0.0/0            0.0.0.0/0

# iptables -nL admin-default
Chain admin-default (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            10.1.2.0/27         tcp dpt:22

 

さいごに

 Eucalyptusの仮想ネットワークの構成には、さまざまなLinuxのネットワーク機能が活用されています。サーバーの処理能力が向上するに伴って、これまでは専用のハードウェア機器を必要とした技術がサーバー上のソフトウェアで実現できるようになってきました。Linuxのネットワーク機能はその代表例といえるでしょう。

 前回、LinuxサーバーをiSCSIストレージ装置として利用する方法を紹介しましたが、これもその一例かもしれません。これからもLinuxは新しい機能を取り入れながら、クラウドを支える基礎技術として活用されていくことでしょう。今回省略したiptablesの説明は、次回に行います。

 


中井 悦司
素粒子論の研究、予備校講師、外資系ベンダーのインフラSE、Linux/OSSエバンジェリストと堅実なのか奔放なのかよくわからない経歴を重ねた後、Linux/OSSを愛するあまりレッドハットに転職。オープンソースの「エンジニアを幸せにする力」を信じながら、企業システムにおけるLinux/OSSの活用促進に情熱を注いでいます。
関連情報