EucalyptusNetworking_v1.5.2 のバックアップ(No.1)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
EucalyptusNetworking_v1.5.2 へ行く。
- 1 (2009-09-22 (火) 00:54:52)

EucalyptusAdministratorGuide_v1.5.2

ネットワーク設定

ネットワーク設定 †

はじめに †

Eucalyptus バージョン 1.5 以上には、様々なネットワーク環境に適応できるよう、高度な設定が可能な仮想マシン・ネットワークのサブシステムを備えています。サブシステムには、「モード(mode)」という、4つの高水準なネットワークがあります。各種設定パラメータ、機能、便益、場合によっては制限といった、ローカルなネットワークを構築する際に必要となるそれらを、1つのセットとして取り扱うことができるのです。管理者は、Eucalyptus を起動する前に、Eucalyptus コンポーネントを実行している各々のマシン上（フロントエンド、ノードいずれも）の 'eucalyptus.conf' の設定ファイルで、4つのモードのうちのどれかを選択しなくてはいけません。次に、各モードの概要を紹介します。

↑

SYSTEM Mode (システム・モード) †

最もシンプルなネットワーク・モードであるだけでなく、最小限のネットワーク機能を持ちます。このモードでは、 Eucalyptus は単純にランダムな MAC アドレスを仮想マシン・インスタンスに割り当てます。その際、仮想マシン・インスタンスのイーサネット・デバイスは、ノード自身のローカル Xen ブリッジを通し、物理イーサネット・デバイスに接続します。通常、仮想マシン・インスタンスは、DHCP を使って IP アドレスの割り当てを受けます。DHCP の割り当て手法そのものは、仮想マシンではない一般的なマシンに IP アドレスを割り振る方法と同じです。

SYSTEM Mode（システム・モード）で気をつけなくてはいけないのは、仮想マシンが起動できるように、Eucalyptus 管理者（あるいは、Eucalyptus コンポーネントが接続しているネットワーク管理者）が DHCP サーバ上の機能で、動的にプールされている IP アドレスを扱えるようにしなくてはいけません。つまり、現在利用中のノート PC・デスクトップ PC・サーバが、Eucalyptus ノードと同じネットワーク上に存在していて、かつ DHCP の割り当てを受けている場合、仮想マシンも DHCP で IP アドレスの割り当てを受けることになります。

なお、Eucalyptus をノート PC やデスクトップ PC で試してみたい場合は、SYSTEM Mode（モード）が一番お手ごろでしょう。

↑

STATIC Mode（静的モード） †

Eucalyptus 管理者が、仮想マシンに対して IP アドレスを割り振ることができるモードです。管理者は、Eucalyptus 上で MAC アドレスと IP アドレスが対応する 'map' を管理することになります。仮想マシンのインスタンスが生成されるとき、Eucalyptus は Eucalyptus が管理している DHCP サーバから、使用されていない MAC アドレスと IP アドレスのセットを仮想マシンに割り当てます。それから、仮想マシンのイーサネット・デバイスは、ノード自身の Xen ブリッジを通し、物理イーサネット・デバイスに接続します（そのような機能としては、システム・モードと同様の動作とも言えるでしょう）。

STATIC Mode（静的モード）は、仮想マシンに対して、あらかじめ割り当てる MAC アドレスと IP アドレスを決めておきたい管理者にとって便利でしょう。

SYSTEM Mode（システム・モード）と STATIC Mode（静的モード）における制約

Eucalyptus を SYSTEM 又は STATIC モードで動作させるときは、幾つかの鍵となる機能が使えなくなることに注意してください。具体的に使えなくなるのは、仮想マシンの集合体（Amazon EC2 で言うところの security group を指します）への接続ルールの定義や、インスタンスの起動・実行時に動的な IP アドレスを割り振る機能（Amazon EC2 における Elastic IP を指します）、仮想マシン間のネットワークの遮断（つまり、仮想マシン内の root ユーザであれば、ネットワーク上のほかの仮想マシンのトラフィック調査が、潜在的に可能なのです）、メタデータのサービス利用（インスタンス固有の情報については、http://169.254.169.254/ を御覧ください）といった各機能です。

↑

MANAGED Mode（管理モード） †

Eucalyptus の中で最も機能が多いのが、この MANAGED Mode （管理モード）なのですが、一方で、Eucalyptus 管理者がネットワークを構築する上で、最も制約を受ける可能性もあります。MANAGED Mode（管理モード）では、Eucalyptus 管理者は仮想マシン・インスタンスが使うための、大きなネットワークを定義します。ここでは、STATIC Mode（静的モード）と同様に、仮想マシン・インスタンスが作成されるごとに、Eucalyptus は、固定された MAC アドレスと IP アドレスのセットをDHCP サーバから取得します。

Eucalyptus ユーザは、ネットワークに名前をつけ、'security group'（セキュリティ・グループ）を定義することができます。ここで定義したそれぞれの「ネットワーク」上で動作する仮想マシンは、それぞれのネットワークに対するものと同じ接続ルールが適用されます。例えば、ユーザが仮想マシンを実行しようとする場合、その仮想マシンが Eucalyptus 上のどの「ネットワーク」にあるほかの仮想マシンと通信可能なのかを、IP アドレスの範囲で選択することになります。

また、ユーザは特定の「ネットワーク」に対してのみ適用される接続ルールを設けることもできます。例えば、仮想マシンに対する ping （ICMP）や SSH 接続（TCP ポート 22 番）のトラフィックを許可するといったものです。そのため、この機能は Amazon が提供するサービスで言うところの「security group」に該当するものと言えるでしょう。

更に、ユーザ自身が割り当て可能な公開用の（パブリックな） IP アドレスを、管理者があらかじめ設定しておくこともできます。IP アドレスは仮想マシンの起動時だけでなく、実行時であっても動的に割り当てることができます。つまり、Amazon が提供する「elastic IP」（エラスティック・IP ）のような機能なのです。

security group 、elastic IP 、仮想マシン・ネットワークの隔離を行いたい Eucalyptus 管理者は、この MANAGED Mode（管理モード）を使用しなくてはいけません。

↑

MANAGED-NOVLAN Mode（VLAN のない管理モード） †

VLAN のない管理モードというのは、MANAGED Mode（管理モード）と同じ機能（動的な IP アドレス割り当や secugiry groups）でありながら、仮想マシン・ネットワーク間で通信の隔離を行いません。管理を行う上で、IP アドレスを動的に割り当てる機能や security group を使いたい場合、「クリーンな VLAN」を求めない場合や、仮想マシン間のネットワークがお互いに隔離されているかどうかを気にしないのであれば、このモードを選ぶこともできるいでしょう。

Eucalyptus の各ネットワークモードには、それぞれで必要となるネットワークの条件や、個別の設定方法、注意事項があります。詳しくは、以下のセクションを御覧ください

↑

ブリッジ名 †

ほとんどのネットワーク・モードにおいて、システム上でブリッジする時の名前が必要になります。Xen 3.0 以前のバージョン（時々、ほかのバージョンでもあり得ますか）であれば、ブリッジ名は通常、

xenbr0

です。Xen 3.2 を使用時のブリッジ名は、

eth0

です。あとは、KVM を使っているのであれば（多くのディストリビューションでは）、

br0

となっているでしょう。

brctl show

このコマンドを実行することで、システム上で利用可能なブリッジのリストが表示されますので、Eucalyptus がシステム上で正常に動作しているかどうかを調べるときにも使うことができます。

注意：次のブリッジ名

virbr0

は、libvirt によって作成されるものですが、使用しません。

以降のドキュメントでは、使用するブリッジ名は br0 であると仮定して取り扱います。

↑

SYSTEM Mode（システム・モード）の詳細 †

Eucalyptus を SYSTEM Mode（システム・モード）で使う場合は、とても簡単な設定で済むため、Eucalyptus のほとんどの動作は、仮想マシンのネットワークに対して「邪魔にならない程度」にとどまります。'SYSTEM' モードとして使う場合、 'eucalyptus.conf' で適切な設定が必要になるのは、次の項目です。

フロント・エンド側：

VNET_MODE="SYSTEM"

ノード側：

VNET_MODE="SYSTEM"
VNET_BRIDGE

各 Eucalyptus のノード・コントローラ（NC）にある 'eucalyptus.conf' ファイルには、'VNET_BRIDGE' パラメータの部分に、ローカル・イーサネットでブリッジされているデバイス名がセットされている事を確認してください。

VNET_BRIDGE="br0"

この場所で指定しているものが、実際のブリッジに当たります。ブリッジは、ネットワーク上のどこかに設置されている DHCP サーバ（動的に IP アドレスを渡すためです）が動作しているサーバの、イーサネット・ネットワークに接続されているデバイス名を指します。

ところで、フロント・エンドのマシンはブリッジを設定する必要がないことを覚えておいてください。細かいことですが、VNET_BRIDGE はノード・コントローラに対してのみ設定可能な項目であり、フロント・エンドのコンポーネントでは無視されます。

正常に SYSTEM Mode が動作するかを確認するためには、ノードの動作をチェックする前に、設定したブリッジを通してインスタンスが実行可能かどうかを確認します。次の例のように、新しいインターフェースがブリッジされている事を確認します。

; brctl show eth0
bridge name  bridge id          STP enabled     interfaces
eth0         8000.000c29369858  no              peth0
                                                vif18.0

ノード・コントローラで Xen 3.2 を実行している場合であれば、注意が必要です。Eucalyptus は、仮想マシンの 'eth0' インターフェース(vif18.0) をブリッジ（'br0'として）しますが、仮想マシンはブリッジをローカルのイーサネットとして用いる（'path0'）ことに気をつけてください。

KVM を使っている場合は、次のように表示されます。

; brctl show br0
bridge name	bridge id		STP enabled	interfaces
br0		8000.00005a00083d	no		eth0
                                                       vnet0

ここまで来ますと、仮想マシンはローカル・イーサネットに DHCP リクエストを送れるようになり、ネットワーク上の DHCP サーバは応答できるようになるでしょう。

警告 - SYSTEM モードでは、上記のように、仮想マシン間のネットワーク隔離されていないため、簡単にあらゆるローカル・イーサネットにイーサネット・インターフェースを経由して接続することができます。つまり、ネットワーク上の仮想マシンに対しては、ネットワーク上で（仮想ではない）実際のマシンと同様に取り扱わなければならない事を意味しています。Eucalyptus は、サード・パーティ製の DHCP サーバを経由して仮想マシンに割り当てられた IP アドレスを見つけ出そう努力しますが、ネットワークの設定によっては見つけられないこともあります（スイッチの種類や設定、ネットワーク上のクラウド・コントローラの位置などによります）。実際のところ、Eucalyptus が仮想マシンの　IP アドレスを特定できない場合、'describe-instanse' コマンドによって表示される IP アドレスは「0.0.0.0」（private 及び public の両方とも）となります。このような状況を避ける一番良い方法は、仮想マシンの起動時（正確には、起動後の IP アドレス取得時）に、フロントエンドに対して若干のネットワーク通信を発生させることです。Eucalyptus が仮想マシンの IP アドレスを発見できるようにするためには、仮想マシンの起動時、仮想マシンからフロントエンド側に数回の ping を飛ばしてみてください。

↑

STATIC Mode（静的モード）の詳細 †

このモードの Eucalyptus は、自分自身が持っている DHCP サーバを制御し、仮想マシン1つにつき、1つの静的エントリ（固定 IP アドレス）を割り当てるよう管理します。'STATIC' モードとして使う場合、 'eucalyptus.conf' で適切な設定が必要になるのは、次の項目です。

フロント・エンド側（'*'が付いているオプションは、インストール時に指定が必須です。詳細は後で記述します。）：

VNET_MODE="STATIC"
VNET_INTERFACE
VNET_DHCPDAEMON
*VNET_DHCPUSER
VNET_SUBNET
VNET_NETMASK
VNET_BROADCAST
VNET_ROUTER
VNET_DNS
VNET_MACMAP

ノード側：

VNET_MODE="STATIC"
VNET_BRIDGE

Eucalyptus 管理者は、まずはじめに、フロント・エンド側の 'eucalyptus.conf' で適切なイーサネット・デバイスに調整しなければなりません。ここでは、Eucalyptus のノードで指定するのと同じ物理イーサネットである必要があります。

VNET_INTERFACE="eth0"

次に管理者がすることは、フロント・エンド上に DHCP サーバのプログラムが間違いなくインストールされていることを確認し、Eucalyptus には、DHCP サーバがどこにあるか明示する必要があります。

VNET_DHCPDAEMON="/usr/sbin/dhcpd3"

もしも DHCP サーバのデーモンが 'root 以外のユーザ' によって実行されている場合（すなわち、Ubuntu 8.10 以上では、'dhcpd' として動作しているケースなど）、Eucalyptus を設定する上で、どのユーザ権限で実行されているかに注意を払ってください。VNET_DHCPUSER に、DHCP サーバのユーザ権限を記入します。

VNET_DHCPUSER="<dhcpusername>"

それから、管理者は使用するデバイスのために IP サブネットマスクの情報を入力しなくてはいけません。例えば、フロント・エンド側の「eht0」インターフェースの IP アドレスが「192.168.1.254」で、ネットワークが「192.168.1.0/24」、ゲートウェイ・アドレスが「192.168.1.1」、DNS が「192.168.1.2」の場合、'eucalyptus.conf'では次のように設定します。

VNET_SUBNET="192.168.1.0"
VNET_NETMASK="255.255.255.0"
VNET_BROADCAST="192.168.1.255"
VNET_ROUTER="192.168.1.1"
VNET_DNS="192.168.1.2"

最後に、管理者は、仮想マシン・インスタンスに対して、静的な MAC アドレスと IP アドレスがマッピングされたリストを、先着順に提供しなくてはいけません。なお、それぞれの IP アドレスは、これまで設定したネットワークのサブネット内に割り当てなくてはいけません。また、ネットワーク上でその IP アドレスをどのマシンも使用していないようにも注意すべきです。

VNET_MACMAP="AA:DD:11:CE:FF:ED=192.168.1.3 AA:DD:CE:FF:EE=192.168.1.4"

ノード側では、ブリッジの指定を次のようにする必要があります。 VNET_BRIDGE="br0" しっかりと Eucalyptus の設定を行っておけば、ノード・コントローラやフロント・エンドのコンポーネントは起動するでしょう。このモードが正常に実行しているかどうかを調べるためには SYSTEM モードの最後の段落にあるように、ブリッジがどのように表示されるか確認することができます。

DHCP サーバがフロント・エンド側で確実に動作しているかどうかを確認（'ps axww | grep -i dhcpd | grep -i euca'）しておいてください。この段階で、仮想マシンはローカル・イーサネットに対して DHCP リクエストを送っていなければなりません。また、フロント・エンド上の DHCP サーバは、管理者が 'eucalyptus.conf' によって定めた、静的な（固定）MAC アドレス / IP アドレスをマッピングするセットのうち、1つを送り返している必要があります。

警告 - STATIC モードでも、上記のように、仮想マシン間のネットワーク隔離されていないため、簡単にあらゆるローカル・イーサネットにイーサネット・インターフェースを経由して接続することができます。つまり、ネットワーク上の仮想マシンに対しては、ネットワーク上で（仮想ではない）実際のマシンと同様に取り扱わなければならない事を意味しています。Eucalyptus 側では、設定されている内容が適切かどうかの判断を行えませんので、仮想マシンが IP アドレスを正しく取得できるよう、適切に設定を行わなくてはなりません。最後に、インストールされている DHCP デーモンは、ISC DHCP Daemon version 3.0.x 又は互換性のあるものと仮定します。もし、そうでないならば ICS DHCP Daemon 3.0.x をインストールするか（多くのディストリビューションで一般的なものです）、インストール済み DHCP サーバに対してラッパーとなるスクリプト（'eucalyptus.conf'のVNET_DHCPDAEMONで指定）を書くことを推奨します。

↑

Managed モード（管理モード）の詳細 †

このモードでは、Eucalyptus はローカルな仮想マシン・インスタンスのネットワークを完全に管理していますので、現時点の Eucalyptus がサポートしているすべての機能（仮想マシン間のネットワーク隔離、ユーザが制御可能な仮想マシン・ファイアウォール（接続ルールや security group）、ダイナミックな公開 IP アドレスの割り当て）を利用することができます。'MANAGED' モードとして使う場合、eucalyptus.conf' で適切な設定が必要になるのは、次の項目です。

フロント・エンド側（'*'が付いているオプションは、インストール時に指定が必須です。詳細は後で記述します。）：

VNET_MODE="MANAGED"
VNET_INTERFACE
VNET_DHCPDAEMON
*VNET_DHCPUSER
VNET_SUBNET
VNET_NETMASK
VNET_DNS
VNET_ADDRSPERNET
*VNET_PUBLICIPS

ノード側：

VNET_MODE="MANAGED"
VNET_INTERFACE

Managed モードで Eucalyptus が動作するためには、ローカルなネットワーク及び設定において、幾つかの動作条件が必要となります。

↑

MANAGED mode の動作条件 †

'MANAGED' モードを利用する前に、次の項目を確認してください。

1.) ネットワーク上の特定の IP アドレスの範囲を、間違いなく利用可能であることを確認してください（192.168...., 10......, などなど）。

2.) ネットワークが 'VLAN clean' であることを確認してください。'VLAN clean' というのは、Eucalyptus コンポーネントが接続しているすべてのスイッチ及びポートで、VLAN タグ付きパケットの取り扱いが許可されていることを指します。

3.) フロント・エンド（CC）上でファイアウォールを動作させていないことと、ファイアウォールのルールがフロント・エンド側の netfilter(iptables) のルールの従って動的に変更可能であることを確認してください。

これら3つの条件すべてが満たされませんと、MANAGED モードとして Eucalyptus を使うことはできません。もし満たされていない項目があれば、少なくともネットワーク上で仮想インスタンスが応答できませんので、設定は間違いなく失敗するでしょう。

'1' の必要条件のためには、ネットワーク上で未使用の IP アドレスの範囲を指定します。その際、できるだけ幅広く範囲を指定してください。典型的な例を次に示します。

ネットワーク 10.0.0.0 ～ 10.255.255.255 が未使用の場合：

VNET_MODE="MANAGED"
VNET_SUBNET="10.0.0.0"
VNET_NETMASK="255.0.0.0"
VNET_DNS="<DNSサーバの IP アドレス>"
VNET_ADDRSPERNET="128"

ネットワーク 192.168.0.0 ～ 192.168.255.255 が未使用の場合：

VNET_MODE="MANAGED"
VNET_SUBNET="192.168.0.0"
VNET_NETMASK="255.255.0.0"
VNET_DNS="<DNSサーバの IP アドレス>"
VNET_ADDRSPERNET="64"

次に、管理者はローカルネットワーク上で、Eucalyptus コンポーネントを実行しているマシン間で、タグ付き VLAN パケットの通信が許可されていることを確認しなくてはいけません。確認を行うためには、次のようなテストを行います。

フロント・エンド側では、ローカル・イーサネット上（eucalyptus.conf では VNET_INTERFACE としてセットされているでしょう）にあるインターフェースを確認し、次のように実行します。

vconfig add <インターフェース名> 10
ifconfig <インターフェース名>.10 192.168.1.1 up

上記の '192.168.1.1' の部分は、それぞれ利用可能な IP アドレスの範囲内のものに置き換えてください。

ノード側でも、ローカル・イーサネット上（eucalyptus.conf では VNET_INTERFACE としてセットされているでしょう）にあるインターフェースを確認し、次のように実行します。

vconfig add <インターフェース名> 10
ifconfig <インターフェース名>.10 192.168.1.2 up

こちらも、先ほど同様、'192.168.1.2' に当たる部分は、それぞれ利用可能な IP アドレスの範囲内のものに置き換えてください。

その後、ホスト間で ping の確認を行います。

フロント・エンド側：

ping 192.168.1.2

ノード側：

ping 192.168.1.1

もし ping　の応答がないのでれば、設定を進めるためにも、スイッチ上でタグ付き VLAN のパケットが許可されているかどうか、設定を確認する必要があります（スイッチが自分の管理下にある場合は、スイッチのドキュメントを参照し、どのように設定したらよいかを確認できます）。

最後に、Eucalyptus がファイアウォールの影響を受けないか、あるいは逆に影響を与えていないかどうか、フロント・エンド上で慎重に設定を調べる必要があります。Eucalyptus は MANAGED モードで起動する際、'filter' と 'nat' の設定をリセット（flush）しますが、管理者向けとして Eucalyptus 起動時に特定のルールを読み込むように指定することもできます（詳細は後述します）。

↑

MANAGED モードの設定 †

VNET_INTERFACE="eth0"

VNET_DHCPDAEMON="/usr/sbin/dhcpd3"

VNET_DHCPUSER="<dhcpusername>"

ノード側では、VNET_INTERFACE をきちんとセットしておく必要があります。例えば、現在提供されている Xen のバージョンであれば、典型的なパラメータは次のようなものです（ノードの Xen ブリッジは 'eth0'とします）。

VNET_INTERFACE="peth0"

KVM で動作している場合であれば、

VNET_INTERFACE="eth0"

このようになるでしょう。

MANAGED モードで動作するために必要な条件を満たすことを確認できれば、後の設定はとても簡単なものでしょう。例えば、192.168.0.0/16 のネットワークを自由に使うことができる場合は、次のように指定します。

VNET_MODE="MANAGED"
VNET_SUBNET="192.168.0.0"
VNET_NETMASK="255.255.0.0"
VNET_DNS="<DNSサーバの IP アドレス>"
VNET_ADDRSPERNET="64"
VNET_PUBLICIPS="<公開IP a> <公開IP b> ... <公開 IPn>"

SUBNET、NETMASK、DNS については既に記述しました。VNET_ADDRSPERNET では、幾つの仮想マシン・インスタンスが、それぞれの名前がつけられたネットワーク（Amazon EC2 で言うところの「security group」）上に存在できるかという幅を設定するものです。ここでどのような値を設定すべきかどうかは、管理者がどの程度のネットワークを必要とするかによります。例えば、VNET_SUBNET や VNET_NETMASK の範囲内において、IP アドレスを幾つ使っているかや、同時に幾つの VLAN ネットワークを使いたいか、ネットワーク上を利用するのは何人ぐらいかといった、それぞれの状況を確認してください。

上記の例では、既にネットワークには 65536 個の IP アドレス（192.168.0.0/16 ）があります。ネットワークを IP アドレスの数に応じて分割することで（上記の例では 64 個で1セット）、1つのネットワーク名で幾つの IP アドレスが利用可能かを特定できます（65536/24 = 1024 ）。

100 人のユーザがいる環境に Eucalyptus を導入すると想定した場合、個々のユーザが遅延なく自由に使えるのは、アクティブなセキュリティ・グループが使えるのは、多くても 10 グループ程度でしょう（恐らくは、もっと多くのグループを使いたいでしょうが、仮想マシンが動作できるネットワークは、せいぜい 10 ネットワークまでです。）。

それぞれの security group は、最大で 61 個のインスタンスを作成できます（64個のアドレスから、サブネット、ブロードキャスト、ルータ用、それぞれ1つずつの IP アドレスを引きます）。

また、導入環境において、ネットワークごとの仮想マシンが増やしたく、かつ、security group でアクティブに使うユーザが少ないようであれば、管理者は VNET_ADDRSPERNET パラメータを調整しても構いません。'256' にセットした場合は、それぞれの security group において、253 個の仮想マシン・インスタンスを起動できます。100人のユーザが利用することを想定している場合であれば、2つの security group が動作し得るでしょう。

クラスタの外や、クラスタのフロント・エンド側からユーザがログインしようとする時は、公開 IP アドレスのセットを見つけ出さなくてはいけません。しかも、公開 IP アドレスは未使用で、Eucalyptus が仮想マシン・インスタンスの起動時や動作時に、動的に割り当てできる必要があります。

テストを行うには、幾つかの未使用の公開アドレスを使い、次のようにコマンドを実行してみてください。

フロント・エンド側：

ip addr add <公開IP>/32 dev <インターフェース名>

仮想マシン・インスタンスにログインしたい、外部のマシン側：

ping <公開IP>

この作業によって、仮想マシン・インスタンスへ動的な IP アドレスが割り当てられます。次に、以下のコマンドで割り当てられた IP アドレスを削除します。

ip addr del <公開IP>/32 dev <インターフェース名>

公開 IP アドレスの中で、どれを仮想マシン・インスタンスに割り当てることができるかは、'eucalyptus.conf' ファイルの中で調整することができます。

VNET_PUBLICIPS="<publicIPa> <publicIPb> ... <publicIPn>"

警告 - Eucalyptus が MANAGED モードで動作しているときは、フロント・エンド側のルータ配下では（ループバックデバイスを使用する代わりに指定）、1つのマシンしか Eucalyptus しか動作することはできません。これは、このモードのトラフィックがネットワーク名に依存しているためです。マシン1台（ノートPC）で Eucalyptus を実行したい場合は、SYSTEM モードか STATIC モードを使わなくてはいけません。

また、Eucalyptus は MANAGED モードで起動する際、'filter' と 'nat' の設定をリセット（flush）します。次は、標準ポリシーである 'FORWARD' チェインで、'DROP'（拒否）する 'filter'（フィルタ）の設定を追加します。フロント・エンドの実行するとき、アクティブなセキュリティ・グループに対する立ち入りルールの追加・削除を、'FORWARD' ルールに従って行います。

さらに、'nat' テーブルが設定されていることによって、仮想マシンから外部ネットワークへの IP マスカレードを使えるようになるほか、仮想マシン・インスタンスの起動時・稼働中に、動的に公開 IP アドレスを 'nat' テーブルによって割り当て・割り当て解除することもできます。

管理者がフロントエンド側に何らかのルールを設けたい時は、フロント・エンド側において、Eucalyptus 起動時か、あるいは起動していない状態で、次のようにコマンドを実行してください。

警告 - Eucalyptus 起動時に、何らかの特別な iptables のルールを適用させたい場合は、うっかりと Eucalyptus の仮想マシン・ネットワーク機能を停止しないよう注意してください。Eucalyptus に対して、全く問題ないと確証がとれている場合のみ、このようにして特別なルールを追加することを強く推奨します。

# <iptables を使って iptables のルールをセットします。その後に、次のように実行します>

# iptables-save > $EUCALYPTUS/var/run/eucalyptus/net/iptables-preload

↑

MANAGED モードのトラブルシューティング †

インスタンスを実行しようと思っていても、ネットワークの設定が適切でなければ正常に動作させることはできません。問題があった場合、どこをチェックすべきでしょうか。

まず初めに、MANAGED モード動作時の必要条件を満たしているかを確認します（未使用の IP アドレスの範囲、VLAN を利用可能なネットワーク、フロント・エンドとノードの通信を妨害するファイアウォールのルールがないこと）。フロント・エンドがプライベート・アドレス（指定した範囲内で）を使って、インスタンスを取得できるかどうかテストします。

もし、できない場合は、次に、フロント・エンドとノードのインターフェースを調査します。

フロント・エンド側：

ifconfig -a

インターフェースが正常に起動していれば、'<インターフェース名>.<vlan>' として IP アドレスと一緒に表示されます。例えば、多くの場合は 'eth0.10' のように表示されます。もし表示されないようであれば、VNET_INTERFACE パラメータを確認し、Eucalyptus のログファイルを調査してください。

ノード側

brctl show

ブリッジが 'eucabr<vlan>' として表示されるでしょう。'<vlan>' の場所は、通常 '10' が表示されます。コマンドの実行結果は次のようなものになるはずです（VNET_INTERFACE="peth0" と仮定します）。

; brctl show で eucabr10 を確認
bridge name  bridge id          STP enabled     interfaces
eucabr10     8000.000c29369858  no              peth0.10
                                                vif18.0

もしこのように表示されない場合は、VNET_INTERFACE 設定を確認し、ログファイルで詳細を調査してください。

フロント・エンド側に戻り、'dhcpd' が動作しているか確認します。

ps axww | grep <dhcpd>

'<dhcpd>'の場所には、VNET_DHCPDAEMON としてセットされている値を入れてください。'ps' の出力結果から、デーモンがタグ付き VLAN のインターフェース(<interface>.<vlan>) として listen している事を確認します。もし実行していないのであれば、なぜ動作しないかを調べるために Eucalyptus のログファイルを確認します（コマンドの実行に失敗している場合は、 'cc.log' で状態を各印してください。デーモンの起動に失敗している場合は、'http-cc_error_log' の出力から調べることもできます）。

フロント・エンドからインスタンスのプライベートな IP アドレスにアクセスしたい時は、公開 IP アドレスから、ユーザの security group への通信が許可されていなければなりません。確認コマンドは、 'euca-describe-group <インスタンスのグループ名>' です。'<インスタンスのグループ名>'の部分が不明場合や、インスタンス起動時に未定義だった場合は 'devalut' がセットされます。グループに適切な接続ルールが適用された後は、フロント・エンド側でルールが適用されていることを確認してください。

iptables -L <ユーザ名>-<グループ名>

もし何もルールが表示されない場合は、より多くの状況を把握するために、テーブル規則のエラーが記録されている'cc.log'を確認してください。次は、'nat' テーブルをチェックします。

iptables -L -t nat

公開 IP アドレスからインスタンスの IP アドレスまで通信のルーティングを行うために、DNAT ルールを調べた方が良いでしょう。また、インスタンスから出て行くパケットのソース IP アドレスをセットするための SNAT ルールも確認した方がよいでしょう。あるいは、原因の特定のために 'cc.log' をチェックしてください。

以上の調査が問題なく、まだ何らかのネットワークの問題があると思われる場合は、以下の情報を集めて Eucalyptus の discussion board に送ってください。

フロント・エンドと1つのノードで、以下のコマンドの結果を記録してください。

netstat -rn
ifconfig -a
brctl show
iptables-save

また、'cc.log'、'nc.log'、'httpd-cc_error_log'、'httpd-nc_error_log'も送ってください。

↑

MANAGED-NOVLAN モードの詳細 †

このモードでは、Eucalyptus はローカルな仮想マシン・インスタンスのネットワークを完全に管理していますので、現時点の Eucalyptus がサポートしているすべての機能（ユーザが制御可能な仮想マシン・ファイアウォール（接続ルールや security group）、ダイナミックな公開 IP アドレスの割り当て）を利用することができます。ただし、仮想マシン間のネットワーク隔離は行えません。'MANAGED-VLAN' モードとして使う場合、eucalyptus.conf' で適切な設定が必要になるのは、次の項目です。

フロント・エンド側（'*'が付いているオプションは、インストール時に指定が必須です。詳細は後で記述します。）：

VNET_MODE="MANAGED-NOVLAN"
VNET_INTERFACE
VNET_DHCPDAEMON
*VNET_DHCPUSER
VNET_SUBNET
VNET_NETMASK
VNET_DNS
VNET_ADDRSPERNET
*VNET_PUBLICIPS

ノード側：

VNET_MODE="MANAGED-NOVLAN"
VNET_BRIDGE

このモードで Eucalyptus が動作するためには、ローカルなネットワーク及び設定において、幾つかの動作条件が必要となります。

↑

MANAGED-NOVLAN mode の動作条件 †

'MANAGED-NOVLAN' モードを利用する前に、次の項目を確認してください。

1.) ネットワーク上の特定の IP アドレスの範囲を、間違いなく利用可能であることを確認してください（192.168...., 10......, などなど）。

2.) フロント・エンド（CC）上でファイアウォールを動作させていないことと、ファイアウォールのルールがフロント・エンド側の netfilter(iptables) のルールの従って動的に変更可能であることを確認してください。

これら2つの条件すべてが満たされませんと、MANAGED-NOVLAN モードとして Eucalyptus を使うことはできません。もし満たされていない項目があれば、少なくともネットワーク上で仮想インスタンスが応答できませんので、設定は間違いなく失敗するでしょう。

ネットワーク 10.0.0.0 ～ 10.255.255.255 が未使用の場合：

VNET_MODE="MANAGED"
VNET_SUBNET="10.0.0.0"
VNET_NETMASK="255.0.0.0"
VNET_DNS="<DNSサーバの IP アドレス>"
VNET_ADDRSPERNET="128"

ネットワーク 192.168.0.0 ～ 192.168.255.255 が未使用の場合：

VNET_MODE="MANAGED"
VNET_SUBNET="192.168.0.0"
VNET_NETMASK="255.255.0.0"
VNET_DNS="<DNSサーバの IP アドレス>"
VNET_ADDRSPERNET="64"

最後に、Eucalyptus がファイアウォールの影響を受けないか、あるいは逆に影響を与えていないかどうか、フロント・エンド上で慎重に設定を調べる必要があります。Eucalyptus は MANAGED-VLAN モードで起動する際、'filter' と 'nat' の設定をリセット（flush）しますが、管理者向けとして Eucalyptus 起動時に特定のルールを読み込むように指定することもできます（詳細は後述します）。

↑

MANAGED-VLAN モードの設定 †

VNET_INTERFACE="eth0"

VNET_DHCPDAEMON="/usr/sbin/dhcpd3"

VNET_DHCPUSER="<dhcpusername>"

VNET_INTERFACE="peth0"

KVM で動作している場合であれば、

VNET_INTERFACE="eth0"

このようになるでしょう。

MANAGED-VLAN モードで動作するために必要な条件を満たすことを確認できれば、後の設定はとても簡単なものでしょう。例えば、192.168.0.0/16 のネットワークを自由に使うことができる場合は、次のように指定します。

VNET_MODE="MANAGED"
VNET_SUBNET="192.168.0.0"
VNET_NETMASK="255.255.0.0"
VNET_DNS="<DNSサーバの IP アドレス>"
VNET_ADDRSPERNET="64"
VNET_PUBLICIPS="<公開IP a> <公開IP b> ... <公開 IPn>"

SUBNET、NETMASK、DNS については既に記述しました。VNET_ADDRSPERNET では、幾つの仮想マシン・インスタンスが、それぞれの名前をつけられたネットワーク（Amazon EC2 で言うところの「security group」）上に存在できるかという幅を設定するものです。ここでどのような値を設定すべきかどうかは、管理者がどの程度のネットワークを必要とするかによります。例えば、VNET_SUBNET や VNET_NETMASK の範囲内において、IP アドレスを幾つ使っているかや、同時に幾つの VLAN ネットワークを使いたいか、ネットワーク上を利用するのは何人ぐらいかといった、それぞれの状況を確認してください。

テストを行うには、幾つかの未使用の公開アドレスを使い、次のようにコマンドを実行してみてください。

フロント・エンド側：

ip addr add <公開IP>/32 dev <インターフェース名>

仮想マシン・インスタンスにログインしたい、外部のマシン側：

ping <公開IP>

ip addr del <公開IP>/32 dev <インターフェース名>

公開 IP アドレスの中で、どれを仮想マシン・インスタンスに割り当てることができるかは、'eucalyptus.conf' ファイルの中で調整することができます。

VNET_PUBLICIPS="<publicIPa> <publicIPb> ... <publicIPn>"

警告 - Eucalyptus が MANAGED-VLAN モードで動作しているときは、フロント・エンド側のルータ配下では（ループバックデバイスを使用する代わりに指定）、1つのマシンしか Eucalyptus しか動作することはできません。これは、このモードのトラフィックがネットワーク名に依存しているためです。マシン1台（ノートPC）で Eucalyptus を実行したい場合は、SYSTEM モードか STATIC モードを使わなくてはいけません。

また、Eucalyptus は MANAGED-VLAN モードで起動する際、'filter' と 'nat' の設定をリセット（flush）します。次は、標準ポリシーである 'FORWARD' チェインで、'DROP'（拒否）する 'filter'（フィルタ）の設定を追加します。フロント・エンドの実行するとき、アクティブなセキュリティ・グループに対する立ち入りルールの追加・削除を、'FORWARD' ルールに従って行います。

警告 - Eucalyptus 起動時に、何らかの特別な iptables のルールを適用させたい場合は、うっかりと Eucalyptus の仮想マシン・ネットワーク機能に問題を発生させないように注意してください。Eucalyptus に対して、全く問題ないと確証がとれている場合のみ、このようにして特別なルールを追加することを強く推奨します。

# <iptables を使って iptables のルールをセットします。その後に、次のように実行します>

# iptables-save > $EUCALYPTUS/var/run/eucalyptus/net/iptables-preload

注意：eucalyptus.conf でネットワークに関連する設定を変更した後は、設定を有効にするために、CC の再起動（$EUCALYPTUS/etc/init.d/eucalyptus-cc restart）が必要です。

戻る：管理者ガイド (Administrator's Guide)

進む：イメージ管理

原文：http://open.eucalyptus.com/wiki/EucalyptusNetworking_v1.5.2