![[PukiWiki]](image/eucalyptus-j.png "[PukiWiki]")
Eucalyptus versions 1.5 and higher include a highly configurable VM networking subsystem that can be adapted to a variety of network environments. There are four high level networking "modes", each with its own set of configuration parameters, features, benefits and in some cases restrictions placed on your local network setup. The administrator must select one of these four modes before starting Eucalyptus on the front-end and nodes via modification of the 'eucalyptus.conf' configuration file on each machine running a Eucalyptus component. Brief descriptions of each mode follows:
Eucalyptus 1.5以降では、様々なネットワーク環境に適用でき高度にカスタマイズ可能な仮想ネットワーク機能が含まれています。Eucalyptusの仮想ネットワーク機能は大きく４つの「ネットワークモード」に分かれており、それぞれ固有の設定・機能・利点と制限を持っています。Eucalyptus管理者は４つのうち１つのネットワークモードを選択し適切に設定する必要があります。ネットワークモードの設定はフロントエンド・各ノードそれぞれの"eucalyptus.conf"設定ファイルに記述します。４つのネットワークモードについて、以下に簡単に内容を記述します。
Each Eucalyptus network mode has its own set of infrastructure requirements, configuration parameters, and caveats. These are described in more detail in the following sections.
Eucalyptus の各ネットワークモードには、それぞれで必要となるネットワークの条件や、個別の設定方法、注意事項があります。詳しくは、以下のセクションを御覧ください
For some of the network modes, you'll be required to set up an Ethernet bridge in order for the network mode to function. If you use Xen, the distros typically set up a bridge for you, and you'll simply have to find its name. For Xen versions 3.0 or earlier the bridge name is typically
いくつかのネットワークモードでは、イーサネットのブリッジを構成する必要があります。Xenを使っている場合、いくつかのディストリビューションでは自動的にブリッジインターフェイスが構成されており、やるべきことはそのデバイス名を特定することだけです。Xen 3.0以前では多くの場合は以下のようなデバイス名になっています。
xenbr0
while if you use Xen 3.2 the bridge name is typically
一方、Xen 3.2では以下のようなデバイス名になっています。
eth0
If you use KVM, or you wish to configure a bridge manually, the following describes how to set up a bridge on various distributions. In these examples, it is assumed that your bridge device will obtain its IP address using DHCP, and that your physical ethernet device is named 'eth0'.
KVMを使っていてブリッジネットワークを手動で構成する場合は、いくつかのディストリビューションでの設定方法を以下に記述しています。以下の例では、物理インターフェイスのデバイス名は'eth0'で、ブリッジインターフェイスはDHCPでIPアドレスを取得することを想定しています。
# create a new ethernet bridge configuration file '/etc/sysconfig/network-scripts/ifcfg-br0' # and populate it with the following # この記述を/etc/sysconfig/network-scripts.ifcfg-br0として記述します DEVICE=br0 BOOTPROTO=dhcp ONBOOT=yes TYPE=Bridge # add your physical ethernet device to the bridge by editing your physical ethernet device # configuration file (in this example, 'eth0') '/etc/sysconfig/network-scripts/ifcfg-eth0' # 以下のような記述を/etc/sysconfig/network-scripts/ifcfg-eth0に追加します DEVICE=eth0 TYPE=Ethernet BRIDGE=br0
# All network configuration is done using the 'yast2' configuration tool Run yast2 Network Devices Network Settings Add Device Type->Bridge Next Bridged Devices->select your pysical device (eth0) Next Ok Quit
# 'yast2'設定ツールで以下のように操作します yast2 を実行する Network Devices を選択 Network Settings を選択 追加 を選択 Device Type に Bridge を選択 次へ を選択 Bridged Devices に select your physical device (eth0) を選択 次へ を選択 Ok を選択 終了 を選択
# create a new ethernet bridge device and attach your physical
# ethernet device to the bridge by adding the following to '/etc/network/interfaces'
# 以下のような記述を/etc/network/interfacesに追加し、
# 新規にブリッジネットワークデバイスを作成し、物理ネットワークインターフェイスに接続します
auto br0
iface br0 inet dhcp
bridge_hello 2
bridge_fd 1
bridge_ports eth0
# and comment out your settings for 'eth0' in the same file
# 同じファイル内の'eth0'に関わる設定項目はコメントアウトします
When you are finished configuring a bridge, it is advised that you restart the machine (or, at least, restart the networking subsystem). Once it is back up and running, the
上記の設定が終わったら、マシンを再起動します(もしくは少なくともネットワークの再起動を行います)。再起動後、以下のようなコマンドを実行します。
brctl show
command will list all available bridges, which you can use to check that your system is properly configured to run Eucalyptus.
brctlコマンドは使用可能なブリッジインターフェイスの一覧を表示します。上記で設定したブリッジインターフェイスが表示されているかどうかを確認してください。
NOTE: the bridge name
virbr0
is created by libvirt is shouldn't not be used.
For the reminder of this document, we assume that you correctly identified the bridge and that such bridge is called
br0
注意：ブリッジインターフェイス 'virbr0' はlibvirtにより作成されたブリッジインターフェイスですが、使用できません。この手順では正しいブリッジインターフェイスは 'br0'であることを前提に記述しています。
There is very little Eucalyptus configuration to use SYSTEM mode, as in this mode, Eucalyptus mostly stays 'out of the way' in terms of VM networking. The options in 'eucalyptus.conf' that must be configured correctly in 'SYSTEM' mode are as follows:
EucalyptusクラウドをSYSTEMモードで動作させる場合の設定は非常にシンプルです。SYSTEMモードで動作する場合、インスタンスのネットワークについてEucalyptusはほとんど関与しません。EucalyptusをSYSTEMモードで動作させる場合、eucalyptus.confに以下のように記述します。
On the front-end:
フロントエンドでの記述内容
VNET_MODE="SYSTEM"
On each node:
ノードでの記述内容
VNET_MODE="SYSTEM" VNET_BRIDGE
In each Eucalyptus node controller's (NC) 'eucalyptus.conf' file, make sure that the parameter 'VNET_BRIDGE' is set to the name of the bridge device that is connected to your local ethernet
各ノード(ノード・コントローラが動作するマシン)のeucalyptus.confの 'VNET_BRIDGE' には正しく物理インターフェイスに接続されたブリッジインターフェイスを指定します。以下の例ではブリッジインターフェイス 'br0' を使用しています。
VNET_BRIDGE="br0"
Make sure that what you are specifying in this field is actually a bridge, and that it is the bridge that is connected to an ethernet network that has a DHCP server running elsewhere that is configured to hand out IP addresses dynamically. Note that your front-end machine does not need to have any bridges (this is fine, as VNET_BRIDGE is only a relevant for node controllers, and will be safely ignored by the front-end components).
この場所で指定しているものが、実際のブリッジに当たります。ブリッジ(と、それが接続されている物理ネットワークインターフェイス)は、同一LAN内に配置されているDHCP サーバと更新できる必要があります。
フロントエンドではブリッジを設定する必要がありません。VNET_BRIDGE はノード・コントローラに対してのみ設定可能な項目であり、フロントエンドでは無視されます。
To test whether this mode is working properly at run-time, you can check on a node before and after an instance is running the configure bridge. You should see a new interface associate with the bridge for example you could see
正常に SYSTEMモードが動作するかを確認するためには、brctl showコマンドを使用します。brctl showコマンドはEucalyptusを動作させる前でも、後でも実行することができます。(訳注：が、無用のトラブルを避けるためにも、Eucalyptus実行前に確認しておく方がよいでしょう)
; brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.000c29369858 no peth0
vif18.0
on a node controller running Xen 3.2: note that Eucalyptus has correctly attached the VM's 'eth0' interface (vif18.0) to the bridge ('br0') that is being used to attach VMs to the local ethernet ('peth0').
ノードがXen3.2で動作している場合、インスタンスのネットワークインターフェイス'eth0(vif18.0)'の接続先は'br0'ですが、上記例では物理ネットワークインターフェイスである'peth0'に接続されていることになります。
In the case of kvm you may see something like
KVMを使用している場合は出力は以下のようになります。
; brctl show bridge name bridge id STP enabled interfaces br0 8000.00005a00083d no eth0 vnet0
At this point, the VM should be sending DHCP requests to the local ethernet, and the DHCP server on the network should be sending a reply.
この時点で、インスタンスはDHCPリクエストを発行し、DHCPサーバの応答を受け取ることができる状態になっているはずです。
CAVEATS - In this mode, as mentioned previously, VMs are simply started with their ethernet interfaces attached to the local ethernet without any isolation. Practically, this means that you should treat a VM the same way that you would treat a non-VM machine running on the network. Eucalyptus does it's best to discover the IP address that was assigned to a running VM via a third-party DHCP server, but can be unsuccessful depending on the specifics of your network (switch types/configuration, location of CC on the network, etc.). Practically, if Eucalyptus cannot determine the VM's IP, then the user will see '0.0.0.0' in the output of 'describe-instances' in both the private and public address fields. The best workaround for this condition is to instrument your VMs to send some network traffic to your front end on boot (after they obtain an IP address). For instance, setting up your VM to ping the front-end a few times on boot should allow Eucalyptus to be able to discover the VMs IP.
警告 - SYSTEM モードでは、上記のように、仮想マシン間のネットワークは隔離されていません。インスタンスのネットワークの挙動は、インスタンスではない物理的なマシンと全く等価です。インスタンスは、DHCP サーバからのをIP アドレス割り当てを受けるよう努力しますが、ネットワークの設定によっては見つけられないこともあります（スイッチの種類や設定、ネットワーク上のクラウド・コントローラの位置などによります）。実際のところ、Eucalyptus が仮想マシンの IP アドレスを特定できない場合、'describe-instanse' コマンドによって表示される IP アドレスは「0.0.0.0」（private 及び public の両方とも）となります。このような状況を避ける一番良い方法は、仮想マシンの起動時（正確には、起動後の IP アドレス取得時）に、フロントエンドに対して若干のネットワーク通信を発生させることです。Eucalyptus が仮想マシンの IP アドレスを発見できるようにするためには、仮想マシンの起動時、仮想マシンからフロントエンド側に数回の ping を飛ばしてみてください。
In this mode, Eucalyptus will manage VM IP address assignment by maintaining its own DHCP server with one static entry per VM. The options in 'eucalyptus.conf' that must be configured correctly in 'STATIC' mode are as follows:
このモードでは、Eucalyptus自身が持っている DHCP サーバを制御し、仮想マシン1つにつき、1つの静的エントリ（固定 IP アドレス）を割り当てるよう管理します。'STATIC' モードとして使う場合、 'eucalyptus.conf' に以下のようなオプションを記述します。
On the front-end (options annotated with a '*' may be required depending on your installation, see below for details):
フロントエンドでの設定('*'が付いているオプションの記述内容は環境によって異なります。下の解説を参照してください。)
VNET_MODE="STATIC" VNET_PUBINTERFACE VNET_PRIVINTERFACE VNET_DHCPDAEMON *VNET_DHCPUSER [#ic567933] VNET_SUBNET VNET_NETMASK VNET_BROADCAST VNET_ROUTER VNET_DNS VNET_MACMAP
On each node:
ノードでの設定
VNET_MODE="STATIC" VNET_BRIDGE
The Eucalyptus administrator must configure the front-end's 'eucalyptus.conf' first with a valid, configured ethernet device that is attached to the same physical ethernet as the Eucalyptus nodes:
Eucalyptus 管理者は、まずはじめにフロントエンド側の 'eucalyptus.conf' で適切なプライベートネットワーク用のイーサネットデバイス名を記述します。ここで記述するデバイスは、各ノードが属するネットワークに接続された物理インターフェイスのデバイス名になります。
VNET_PRIVINTERFACE="eth0"
If the front-end has a second ethernet device which is used to access the public network, let's say eth1, then you need to configured it as
フロントエンドに２つの物理ネットワークインターフェイスがあり、上記で記載したインターフェイスと異なるインターフェイスが外部ネットワーク(訳注：Eucalyptusクライアントがアクセス可能なネットワーク)に接続されている場合、VNET_PUBINTERFACEをセットします。以下の例ではeth1をパブリックインターフェイスとしてセットしています。
VNET_PUBINTERFACE="eth1"
Next, the admin must ensure that there is a DHCP server binary installed on the front-end and Eucalyptus knows where it is located:
次に、フロントエンドのDHCPサーバのフルパスを指定します。
VNET_DHCPDAEMON="/usr/sbin/dhcpd3"
If your DHCP daemon binary is configured to run as 'non-root' (say, as the user 'dhcpd' as is the case in Ubuntu >= 8.10), then you must configure Eucalyptus to be aware of that user:
環境によってはDHCPサーバはroot以外で実行されます(例えば Ubuntu 8.10 以降では 'dhcpd'ユーザアカウントで実行されます)。その場合はVNET_DHCPUSERに実行するユーザアカウントをセットします。
VNET_DHCPUSER="<dhcpusername>"
Then, the admin must input IP subnet information for that device. For example, if the front-end's 'eth0' interface has the IP address '192.168.1.254' on the '192.168.1.0/24' network, with a gateway at '192.168.1.1' and a DNS at '192.168.1.2', the values in 'eucalyptus.conf' would look like so:
次に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"
Finally, the administrator must supply a list of static MAC/IP mappings that will be assigned, first come first served, to VM instances. Note that each IP must reside in the subnet defined above, and must not be in use by any other machine on the network.
最後に、仮想マシン・インスタンスに対して先着順に提供される、静的な 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"
On the nodes, you must ensure that the bridge is entered
ノードではブリッジインターフェイスを指定します。
VNET_BRIDGE="br0"
Once you have configured Eucalyptus properly, start up the node controllers and the front-end components. To test whether this mode is working properly at run-time, you can follow the last paragraph of the SYSTEM mode, in which the bridge is inspected.
適切に設定を行った後に、ノードとフロントエンドのEucalyptusを起動します。このモードが正常に実行しているかどうかを調べるためには SYSTEM モードの最後の段落にあるように、ブリッジがどのように表示されるかを確認します。
Make sure that the DHCP server has been started properly on the front-end ('ps axww | grep -i dhcpd | grep -i euca'). At this point, the VM should be sending DHCP requests to the local ethernet, and the DHCP server on the front-end should be sending a reply with one of the static MAC/IP mappings the admin has defined in 'eucalyptus.conf'.
DHCP サーバがフロント・エンド側で確実に動作しているかどうかを確認（'ps axww | grep -i dhcpd | grep -i euca'）してください。この段階で、仮想マシンはローカル・イーサネットに対して DHCP リクエストを送っていなければなりません。また、フロント・エンド上の DHCP サーバは、管理者が 'eucalyptus.conf' によって定めた、静的な（固定）MAC アドレス / IP アドレスをマッピングするセットのうち、1つを送り返している必要があります。
CAVEATS - In this mode, as mentioned previously, VMs are started with their ethernet interfaces attached to the local ethernet without any isolation. Practically, this means that you should treat a VM the same way that you would treat a non-VM machine running on the network. Eucalyptus does not verify that your settings are valid, thus, you must enter them correctly in order for your VMs to obtain IP addresses. Finally, we assume that the installed DHCP daemon is, or is compatible with, ISC DHCP Daemon version 3.0.X. If it is not, we recommend either installing a version that is (common in most distributions) or writing a wrapper script around your installed DHCP server and point Eucalyptus at it (via VNET_DHCPDAEMON in 'eucalyptus.conf').
警告 - STATIC モードでも、上記のように、仮想マシン間のネットワーク隔離されていないため、簡単にあらゆるローカル・イーサネットにイーサネット・インターフェースを経由して接続することができます。 つまり、ネットワーク上の仮想マシンに対しては、ネットワーク上で（仮想ではない）実際のマシンと同様に取り扱わなければならない事を意味しています。Eucalyptus 側では、設定されている内容が適切かどうかの判断を行えませんので、仮想マシンが IP アドレスを正しく取得できるよう、適切に設定を行わなくてはなりません。最後に、インストールされている DHCP デーモンは、ISC DHCP Daemon version 3.0.x 互換であることを想定しています。もしそうでないならば ICS DHCP Daemon 3.0.x をインストールするか（多くのディストリビューションで一般的なものです）、インストール済み DHCP サーバに対してラッパーとなるスクリプト（'eucalyptus.conf'のVNET_DHCPDAEMONで指定）を書くことを推奨します。
In this mode, Eucalyptus will fully manage the local VM instance network and provides all of the networking features Eucalyptus current supports (VM network isolation, user controllable VM firewalls (ingress rules/security groups), dynamic public IP assignment). The options in 'eucalyptus.conf' that must be configured correctly in 'MANAGED' mode are as follows:
このモードでは、Eucalyptus はローカルな仮想マシン・インスタンスのネットワークを完全に管理し、現時点の Eucalyptus がサポートしているすべての機能（仮想マシン間のネットワーク隔離、ユーザが制御可能な仮想マシン・ファイアウォール（接続ルールや security group）、ダイナミックな公開 IP アドレス(Elastic IP)の割り当て）を利用することができます。'MANAGED' モードとして使う場合、eucalyptus.conf' で適切な設定が必要になるのは、次の項目です。
On the front-end (options annotated with a '*' may be required depending on your installation, see below for details):
フロントエンドでの設定('*'が付いているオプションの記述内容は環境によって異なります。下の解説を参照してください。)
VNET_MODE="MANAGED" VNET_PUBINTERFACE VNET_PRIVINTERFACE VNET_DHCPDAEMON *VNET_DHCPUSER [#hc00988f] VNET_SUBNET VNET_NETMASK VNET_DNS VNET_ADDRSPERNET *VNET_PUBLICIPS [#z1d27057] *VNET_CLOUDIP [#mad9196c] *VNET_LOCALIP [#e767369d]
On each node:
ノードでの設定
VNET_MODE="MANAGED" VNET_PUBINTERFACE VNET_PRIVINTERFACE
Be advised that this mode requires that your local network/configuration conforms to certain requirements that Eucalyptus depends upon.
Managed モードで Eucalyptus が動作するためには、ローカルなネットワーク及び設定において、幾つかの動作条件が必要となります。
Before using 'MANAGED' mode, you must confirm that:
MANAGEDモードを使用する前に以下の事項を満たしていることを確認してください。
All three of these requirements must be met before MANAGED mode should be attempted. Failure to verify the above will, at least, result VM instances being unavailable on the network.
MANAGEDモードを設定する前に、上記の３つが満たされていることを確認してください。満たされていない状態でMANAGEDモードを使用した場合、VMインスタンスは利用できないでしょう。
For requirement '1', choose a IP range that you know is completely unused on your network. Choose a range that is as large as possible. Typical examples are:
上記の1.)を満たすために、IPアドレスの範囲を決定します。できるだけ大きな範囲を確保してください。一般的な例を以下に記述します。
if the network 10.0.0.0 - 10.255.255.255 is completely unused:
10.0.0.0 - 10.255.255.255(訳注：プライベートアドレス、クラスA)をEucalyptus用として指定する場合
VNET_MODE="MANAGED" VNET_SUBNET="10.0.0.0" VNET_NETMASK="255.0.0.0" VNET_DNS="<your DNS>" VNET_ADDRSPERNET="128"
or if the network 192.168.0.0 - 192.168.255.255 is completely unused:
192.168.0.0 - 192.168.255.255(訳注：プライベートアドレス、クラスC)をEucalyptus用として指定する場合
VNET_MODE="MANAGED" VNET_SUBNET="192.168.0.0" VNET_NETMASK="255.255.0.0" VNET_DNS="<your DNS>" VNET_ADDRSPERNET="64"
Next, the admin must verify that the local network will allow/forward VLAN tagged packets between machines running Eucalyptus components. To verify, perform the following test:
次にタグVLANパケットが正しく疎通しているかどうかを確認します。確認するためのテスト方法を以下に記述します。
on the front-end, choose the interface that is on the local ethernet (and will be set in eucalyptus.conf as VNET_PRIVINTERFACE), and run:
フロントエンドでは、ローカルのEthernetインターフェイス(eucalyptus.confのVNET_PRIVINTERFACEで指定したデバイス)で、以下のようなコマンドを実行します
vconfig add <interface> 10 ifconfig <interface>.10 192.168.1.1 up
replace '192.168.1.1' with an IP from the range you selected above.
'192.168.1.1'は上記で指定したIPアドレスの範囲のものを指定します。
On the node, choose the interface on the local network (will be set in eucalyptus.conf as VNET_PRIVINTERFACE and VNET_PUBINTERFACE), and run:
ノードではローカルのEthernetインターフェイス(eucalyptus.confのVNET_PRIVINTERFACEと、VNET_PUBINTERFACEで指定したデバイス)で、以下のようなコマンドを実行します
vconfig add <interface> 10 ifconfig <interface>.10 192.168.1.2 up
again, replace '192.168.1.2' with another IP in the range you selected above.
'192.168.1.2'は上記で指定したIPアドレスの範囲のものを指定します。
Then, try a ping between hosts. On the front-end:
その後、フロントエンドとノードの間でpingが疎通するかどうかを確認します。フロントエンドからは以下のようにpingコマンドを実行します。
ping 192.168.1.2
on the node:
ノードでは以下のようにpingコマンドを実行します。
ping 192.168.1.1
If this does not work, then your switch needs to be configured to forward VLAN tagged packets (if it is a managed switch, see your switch's documentation to determine how to do this).
もし疎通がないのであれば、スイッチ上でタグ付き VLAN のパケットが通過できるように設定を確認してください（スイッチが自分の管理下にある場合は、スイッチのドキュメントを参照し、どのように設定したらよいかを確認できます）。
Finally, you need to carefully inspect the firewall on the front-end to make sure that it will not interfere with Eucalyptus, or vice-versa. Eucalyptus will flush the 'filter' and 'nat' tables upon boot in MANAGED mode, but provides a way for the administrator to define special rules that are loaded when Eucalyptus starts (see below for details).
最後に、Eucalyptus がファイアウォールの影響を受けないか、あるいは逆に影響を与えていないかどうか、フロント・エンド上で慎重に設定を調べる必要があります。Eucalyptus は MANAGED モードで起動する際、'filter' と 'nat' の設定をリセット（flush）しますが、管理者向けとして Eucalyptus 起動時に特定のルールを読み込むように指定することもできます（詳細は後述します）。
The Eucalyptus administrator must configure the front-end's 'eucalyptus.conf' first with a valid, configured ethernet device that is attached to the same physical ethernet as the Eucalyptus nodes:
Eucalyptus 管理者は、まずはじめに、フロントエンド側の 'eucalyptus.conf' で適切なイーサネット・デバイスを指定します。このデバイスは、ノードと同じネットワークに接続されている物理イーサネットデバイスである必要があります。
VNET_PRIVINTERFACE="eth0"
If the front-end has a second ethernet device which is used to access the public network, let's say eth1, then you need to configured it as
フロントエンドに２つの物理ネットワークインターフェイスがあり、上記で記載したインターフェイスと異なるインターフェイスが外部ネットワーク(訳注：Eucalyptusクライアントがアクセス可能なネットワーク)に接続されている場合、VNET_PUBINTERFACEをセットします。以下の例ではeth1をパブリックインターフェイスとしてセットしています。
VNET_PUBINTERFACE="eth1"
Next, the admin ust ensure that there is a DHCP server binary installed on the front-end and Eucalyptus knows where it is located:
次に、フロントエンドのDHCPサーバのフルパスを指定します。
VNET_DHCPDAEMON="/usr/sbin/dhcpd3"
If your DHCP daemon binary is configured to run as 'non-root' (say, as the user 'dhcpd' as is the case in Ubuntu >= 8.10), then you must configure Eucalyptus to be aware of that user:
環境によってはDHCPサーバはroot以外で実行されます(例えば Ubuntu 8.10 以降では 'dhcpd'ユーザアカウントで実行されます)。その場合はVNET_DHCPUSERに実行するユーザアカウントをセットします。
VNET_DHCPUSER="<dhcpusername>"
Nodes must have VNET_PRIVINTERFACE and VNET_PUBINTERFACE set properly (they should be set with the same value, the device facing the CC). For example, with current Xen versions, this parameter (when your node's Xen bridge is 'eth0') is typically:
ノードでは、VNET_PRIVINTERFACE と VNET_PUBINTERFACEを適切に設定します(ここで指定するデバイス名は、クラスタ・コントローラ(CC)と疎通可能なインターフェイスを指定します。２つとも同じデバイス名をセットします)。例えばXen(ノードでセットされたブリッジインターフェイスが 'eth0' の場合)では以下のように設定します。
VNET_PUBINTERFACE="peth0" VNET_PRIVINTERFACE="peth0"
while for kvm it should be something like
KVMの場合は以下のようにセットします。
VNET_PUBINTERFACE="eth0" VNET_PRIVINTERFACE="eth0"
Once you have verified that your network configuration meets the requirements for running in MANAGED mode, the rest of the configuration is fairly simple. For example, if the 192.168.0.0/16 network is free and unused on your network:
ここまで設定がうまくいけば、あとの設定は非常にシンプルです。例えば192.168.0.0/16のIPアドレスをEucalyptus用に使用する場合は以下のように設定します。
VNET_MODE="MANAGED" VNET_SUBNET="192.168.0.0" VNET_NETMASK="255.255.0.0" VNET_DNS="<your dns>" VNET_ADDRSPERNET="64" VNET_PUBLICIPS="<publicIPa> <publicIPb> ... <publicIPn>"
SUBNET, NETMASK, and DNS have been described previously. VNET_ADDRSPERNET is used to control how many VM instances may simultaneously be part of an individual user's named network (called a 'security group' in Amazon EC2). Choosing the right value for this parameter depends on how many IPs you have made available using VNET_SUBNET/VNET_NETMASK, how many VLANs your network supports simultaneously, and how many concurrent active user networks the administrator wishes to support.
SUBNET、NETMASK、DNS については既に記述しました。VNET_ADDRSPERNET では、幾つの仮想マシン・インスタンスが、それぞれの名前がつけられたネットワーク（Amazon EC2 で言うところの「security group」）上に存在できるかという幅を設定するものです。ここでどのような値を設定すべきかどうかは、管理者がどの程度のネットワークを必要とするかによります。例えば、VNET_SUBNET や VNET_NETMASK の範囲内において、IP アドレスを幾つ使っているかや、同時に幾つの VLAN ネットワークを使いたいか、ネットワーク上を利用するのは何人ぐらいかといった、それぞれの状況を確認してください。
In the above example, there are 65536 addresses available (192.168.0.0/16). If we divide by the number of addresses per network (set to 64 above), we find the maximum number of simultaneous active named networks that can be in use at any one point in time (65536 / 64 == 1024). If your eucalyptus installation has 100 users, then each user could have at most 10 active security groups in operation at any point in time (of course, they can define as many as they wish, but can only have sets of running VMs residing in at most 10 networks).
上記の例では、ネットワーク全体では 65536 個の IP アドレス（192.168.0.0/16）が利用可能ですが、EucalyptusはIPアドレスを security group の単位に分割します（上記の例では1セキュリティ・グループあたり 64 個のIPアドレスを割り当てる）。結果、いくつの名前付けネットワーク(security group)が使用可能なのかを判別することができます（65536/64 = 1024 ）。この環境で100 人のユーザが Eucalyptus を使用した場合、個々のユーザが使えるセキュリティ・グループは、10 グループ程度になることがわかります。（もちろんユーザは可能な限り多くのセキュリティ・グループを使いたいのですが、(上記の試算より、)実際に使えるセキュリティ・グループの数は、多くても10個、ということになります）
Each security group could support up to 61 instances (64 addresses minus 1 address for the subnet, broadcast, and router IPs). If your installation favors more VMs per network and fewer active security groups per user, the administrator may adjust the VNET_ADDRSPERNET parameter accordingly. Setting it to '256' would result in each active user's security group supporting up to 253 VM instances, and each of 100 users could simultaneously have 2 active security groups.
上記の設定では、個々のセキュリティ・グループあたり61個のインスタンスが起動可能です(64個のIPアドレスから、サブネット、ブロードキャスト、ゲートウェイ用に使用されるIPアドレスをのぞいた残りがインスタンスに割り当て可能です)。もし１つのセキュリティ・グループあたりのVM数を多くし、１ユーザあたりのアクティブなセキュリティ・グループを減らすのであれば、VNET_ADDRSPERNETを変更します。例えばVNET_ADDRSPERNETを 256 にセットした場合、１つのセキュリティ・グループあたりのインスタンス起動可能数は253になり、100ユーザに均等にセキュリティ・グループを割り当てた場合は、１ユーザあたりのセキュリティ・グループの数は2(65536 / 256 / 100 = 2.56)になります。
If you would like users to log in to their instances from outside the cluster/cluster front-end, you must find a set of public IP addresses, that are not in use, and allow Eucalyptus to dynamically route them to VM instances at instance boot time or dynamically at run time. For each IP address you choose, your front-end must be capable of being configured with that IP address. To test, choose some free public IP addresses and perform the following test for each one:
ユーザがクラスタの外部からインスタンスにログインすることが必要であった場合、管理者は未使用のPublic IPを用意する必要があります。EucalyptusはPublic IPがインスタンスに届くように、インスタンスの起動時にフォワードルールを適用します。これにより外部からPublic IP宛に送信されたIPパケットはインスタンスに到達することができます。このような動作をするためには、フロントエンドはPublic IPを割り当てることができるようになっていることが必要です。テストするためには以下のようにします。
on the front-end:
フロントエンド側では以下のようにコマンドを実行します
ip addr add <publicIP>/32 dev <interface>
on some external machine representative of where users will wish to log into their VM instances:
外部のマシンから、Public IP宛のpingコマンドを実行します。
ping <publicIP>
if this works, then dynamic IP assignment to VM instances will work. Remove the assigned address with the following command:
上記のpingが疎通すれば、インスタンスに動的にPublic IPを割り当てても動作するでしょう。先ほどテストのために割り当てたPublic IPを解除します。
ip addr del <publicIP>/32 dev <interface>
Once you have compiled a list of available public IP addresses, allow Eucalyptus to use them by listing the IPs in 'eucalyptus.conf':
使用可能なPublic IPを決めたら、'eucalyptus.conf'の中に以下のように記述します。
VNET_PUBLICIPS="<publicIPa> <publicIPb> ... <publicIPn>"
or, you can specify a range of IPs with:
Public IPは範囲指定も可能です。以下のように記述します。
VNET_PUBLICIPS="<publicIPa>-<publicIPb>"
where publicIPa and publicIPb are in the same /24 subnet.
上記のpublicIPa と publicIPbは同一の24ビットサブネットに属するIPアドレスである必要があります。
If your cluster-controller and cloud-controller are running on separate hosts, you need to set:
クラスタ・コントローラとクラウド・コントローラが別のマシンで動作している場合は以下のように設定する必要があります。
VNET_CLOUDIP="<ip-of-cloud-controller>"
And, if you are running multiple clusters in your installation, and wish to manually specify the IP of the cluster-controller that all other cluster-controllers can reach, you may set:
マルチクラスタ構成を取っている場合は、以下のようにクラスタ・コントローラのIPアドレスをセットします。このIPアドレスは他のクラスタ・コントローラと疎通できる必要があります。
VNET_LOCALIP="<ip-of-cluster-controller"
The cluster-controller will attempt to determine this value automatically if it is not set.
上記の設定がない場合は、起動時に適切と思われるアドレスを自動的にセットします。
CAVEATS - When Eucalyptus is running in MANAGED mode, you cannot currently run an entire eucalyptus installation on a single machine as this mode depends upon traffic between named networks passing through a front-end router (instead of going through the loopback device). If you wish to run Eucalyptus on a single machine (laptop), you must use SYSTEM or STATIC mode. In MANAGED mode, Eucalyptus will flush the front-end's iptables rules for both 'filter' and 'nat'. Next, it will set the default policy for the 'FORWARD' chain in 'filter' to 'DROP'.
警告：EucalyptusをMANAGEDモードで動作する場合、１台のマシンで全てのコンポーネントを動作させることはできません。これはセキュリティ・グループ間のトラフィックがフロントエンドで動作するルーティングに依存しているためです。(訳がおかしい？) Eucalyptusを（ラップトップのような）１台のマシンで動作させる場合はSYSTEMモードか、STATICモードを使用するようにしてください。MANAGEDモードでは、Eucalyprusはフロントエンドのiptablesルールの'filter', 'nat'ルールを消去(flush)します。次に'filter'ルールの'FORWARD'チェインを'DROP'チェインに接続するよう、デフォルトルールをセットします。
At run time, the front-end will be adding and removing rules from 'FORWARD' as users add/remove ingress rules from their active security groups. In addition, the 'nat' table will be configured to allow VMs access to the external network using IP masquerading, and will dynamically add/remove rules in the 'nat' table as users assign/unassign public IPs to VMs at instance boot or run-time.
その後、動作中にセキュリティ・グループの設定に応じて、'FORWARD'チェインの内容を追加・削除します。加えて外部のネットワークと疎通できるように、'nat'ルール内にIPマスカレードの設定を追加します。またユーザがPublic IPを割り当てた場合には'nat'テーブルに動的にルールを追加・削除します。
If the administrator has some rules that they wish to apply o the front-end, they should perform the following procedure on the front-end, before eucalyptus is started or while eucalyptus is not running.
もしEucalyptusの動的なルール変更以上のルールを追加したい場合は以下のコマンドを実行します。以下のコマンドはEucalyptusが停止している時に実行してください。
WARNING if the admin chooses to perform this operation to define special iptables rules that are loaded when Eucalyptus starts, they could inadvertently cause Eucalyptus VM networking to fail. It is suggested that you only do this only if you are completely sure that it will not interfere with the operation of Eucalyptus.
注意：もし以下のコマンドを実行してiptablesに追加ルールをセットした場合、インスタンスのネットワークの疎通に不具合が出る可能性があります。以下のコマンドを実行する場合は、それ(iptablesへのルール追加)がEucalyptusに及ぼす影響について完全に把握している必要があります。
<use iptables to set up your iptables rules> <iptablesへの追加ルール設定方法> iptables-save > $EUCALYPTUS/var/run/eucalyptus/net/iptables-preload
If you start an instance believe that it is running but is not available on the network, here are some things to check.
インスタンスを起動したのにネットワークの疎通を確認できない場合(訳注：ノード・コントローラ上でxm list, xm consoleなどでインスタンスの起動・動作は確認できるがネットワーク経由のログインができない場合)は以下の事項を確認します。
First, verify that the requirements of MANAGED mode have been met as described above (unused range of IPs, VLAN capable network, no interfering firewall rules on the nodes or front-end).
まずMANEGEDモードを使うための前提条件が正しく満たされているかどうかを確認します。確認するのは以下の項目です。
Test whether you can get to the instance from the front-end using it's private address (from the range you specified). If you cannot, next, inspect the interfaces on the front-end and nodes:
フロントエンドから、プライベートIP(VNET_SUBNETで指定したもの)を使用してインスタンスと疎通できるかを確認します。もしできないのであれば、次にネットワークインターフェイスの状態を確認します。
on front-end:
フロントエンドで以下のコマンドを実行します。
ifconfig -a
You should see an interface '<interface>.<vlan>' with an IP address that is up and running. For instance, if may be 'eth0.10'. If it is not, check your VNET_PUBINTERFACE and VNET_PRIVINTERFACE parameter and inspect the eucalyptus log files for errors.
'<インターフェイス名>.<VLAN番号>'という名前のネットワークインターフェイスがありますか？それはIPアドレスを持ち、稼働中(UP)でしょうか？ネットワークインターフェイス名は、'eth0.10'のような名前になっているはずです。そうでないのであれば、'eucalyptus.conf'の VNET_PUBINTERFACE と VNET_PRIVINTERFACEを確認し、Eucalyptusのログファイルにエラーの出力があるかどうかを確認してください。
on the node:
次にノードで以下のコマンドを実行します。
brctl show
You should see a number of bridges called 'eucabr<vlan>', where '<vlan>' is a number that typically starts from '10'. The output should be similar (if VNET_PRIVINTERFACE="peth0") to:
出力に 'eucabr<VLAN番号>' という名前のブリッジインターフェイスはありますか？'<VLAN番号>'は一般的には 10 から始まっています。例えば以下のような出力になっていればOKです(VNET_PRIVINTERFACEが "peth0" の場合)。
; brctl show
bridge name bridge id STP enabled interfaces
eucabr10 8000.000c29369858 no peth0.10
vif18.0
If this is not the case, check your VNET_PRIVINTERFACE setting, and inspect the logfiles for details.
上記のような出力が見られない場合、'eucalyptus.conf'の VNET_PRIVINTERFACEの設定を確認し、Eucalyptusのログファイルにエラーの出力があるかどうかを確認してください。
Back on the front-end, make sure that 'dhcpd' is running:
もう一度フロントエンドに戻ります。DHCPサービスが動作しているかどうかを以下のコマンドで確認します。
ps axww | grep <dhcpd>
where '<dhcpd>' is what you have set for VNET_DHCPDAEMON.
上記の'<dhcpd>'は、'eucalyptus.conf'の VNET_DHCPDAEMON で設定した文字列にします。
Make sure that, in the output of 'ps', you see that the daemon is listening on the vlan tagged interface from above (<interface>.<vlan>).
grepでフィルタされたpsコマンドの出力の中に'<インターフェイス名>.<VLAN番号>' を含む行があるかどうかを確認してください。
If it is not running, check the eucalyptus logs for the reason why (if the command failed, you will see this information in 'cc.log', if the daemon failed at runtime, you can inspect the reason in the daemon's output itself in 'http-cc_error_log'.
ない場合はDHCPサービスは動作していません。Eucalyptusのログファイルを確認し原因を調べます。(DHCP起動コマンドの実行に失敗している場合は cc.log、DHCP起動コマンドは成功したが何か下の問題があった場合は http-cc_error_log に、それぞれエラーが出力されています)
If you can access the private IP of the instance from the front-end, but public IPs are not being forwarded properly, first confirm that the user's security group is set up properly by having them run 'euca-describe-group <group of instance>'.
フロントエンドからプライベートIPで経由でインスタンスにアクセスすることはできるが、外部からPublic IP経由でアクセスすることができない場合は、まずセキュリティ・グループが適切にセットされているかを確認します。'euca-describe-group <インスタンスの属するグループ名>'コマンドを実行します。
'<group of instance>' is set to 'default' by default or if unspecified when the instance was started.
インスタンスの属するグループ名>のデフォルト値は 'default' です。インスタンス起動時に属するグループを省略した場合は 'default' グループとして起動しています。
If the group has appropriate ingress rules set, check that the rules have been implemented on the front-end:
グループの設定として適切なアクセス許可がセットされている場合(訳注：例えばsshであれば22/tcpへのアクセスを許可するようセットされていればOKです)は、そのルールが正しくフロントエンドに適用されているかどうかを確認します。確認には以下のコマンドを実行します。(訳注：<username>はEucalyptusのユーザ名、<groupname>はインスタンスの属するグループ名に置き換えます)
iptables -L <username>-<groupname>
If there are no rules here, check the 'cc.log' for errors applying the table rules for more insight. Next, check the 'nat' table:
コマンドの出力が何もない場合、cc.log を確認し、iptablesへのルールセットが正しく行われているか、何かうまくいっていないところがないかを確認します。次に'nat'テーブルを以下のコマンドで確認します。
iptables -L -t nat
You should see one DNAT rule for routing traffic from a public IP to the instance IP, and one SNAT rule for setting the source IP of outgoing packets from that instance. If you do not, check 'cc.log' to determine the cause.
Public IPからインスタンスのIPアドレスへのDNATルールが１つ、インスタンスのIPアドレスから外部にフォワードされる際のSNATルールが１つ存在すれば正しい設定が行われています。そうでない場合は cc.log を確認してください。
If all of these checks pass and the instance still is experiencing network problems, please prepare the following information and send it along to the Eucalyptus discussion board:
上記の確認が全て正しいのにまだインスタンスのネットワーク疎通に問題がある場合は以下のコマンド出力と現象の記述をEucalyptusのディスカッショングループに投稿してください。
on front-end and one representative node, capture the output of the following commands:
フロントエンドとノード(現象が出ているものを１つ)での、以下のコマンドの出力。
netstat -rn ifconfig -a brctl show iptables-save
and send us 'cc.log', 'nc.log', 'httpd-cc_error_log' and 'httpd-nc_error_log'.
加えて cc.log, nc.log, httpd-cc_error_log, httpd-nc_error_logを私たちに送ってください。
In this mode, Eucalyptus will fully manage the local VM instance network and provides all of the networking features Eucalyptus current supports (user controllable VM firewalls (ingress rules/security groups), dynamic public IP assignment), but does not provide VM network isolation. The options in 'eucalyptus.conf' that must be configured correctly in 'MANAGED-NOVLAN' mode are as follows:
MANAGED-NOVLANモードでは、Eucalyptus はローカルな仮想マシン・インスタンスのネットワークを完全に管理し、現時点の Eucalyptus がサポートしているほとんどの機能（ユーザが制御可能な仮想マシン・ファイアウォール（接続ルールや security group）、ダイナミックな公開 IP アドレス(Elastic IP)の割り当て）を利用することができますが、仮想マシンネットワークの分離は使用できません。'MANAGED-NOVLAN' モードとして使う場合、eucalyptus.conf' で適切な設定が必要になるのは、次の項目です。
On the front-end (options annotated with a '*' may be required depending on your installation, see below for details):
フロントエンドでの設定('*'が付いているオプションの記述内容は環境によって異なります。下の解説を参照してください。)
VNET_MODE="MANAGED-NOVLAN" VNET_PRIVINTERFACE VNET_PUBINTERFACE VNET_DHCPDAEMON *VNET_DHCPUSER [#d7ee0a79] VNET_SUBNET VNET_NETMASK VNET_DNS VNET_ADDRSPERNET *VNET_PUBLICIPS [#b78249a3] *VNET_CLOUDIP [#s6f77bde] *VNET_LOCALIP [#ge23a724]
On each node:
ノードでの設定
VNET_MODE="MANAGED-NOVLAN" VNET_BRIDGE
Be advised that this mode requires that your local network/configuration conforms to certain requirements that Eucalyptus depends upon.
MANAGED-NOVLANモードで Eucalyptus が動作するためには、ローカルなネットワーク及び設定において、幾つかの動作条件が必要となります。
Before using 'MANAGED-NOVLAN' mode, you must confirm that:
MANAGED-NOVLANモードを使用する前に以下の事項を満たしていることを確認してください。
Both of these requirements must be met before MANAGED-NOVLAN mode should be attempted. Failure to verify the above will, at least, result VM instances being unavailable on the network.
MANAGED-NOVLANモードを設定する前に、上記の条件が満たされていることを確認してください。満たされていない状態でMANAGED-NOVLANモードを使用した場合、VMインスタンスはうまくネットワーク疎通ができません。
For requirement '1', choose a IP range that you know is completely unused on your network. Choose a range that is as large as possible. Typical examples are:
上記の1.)を満たすために、IPアドレスの範囲を決定します。できるだけ大きな範囲を確保してください。一般的な例を以下に記述します。
if the network 10.0.0.0 - 10.255.255.255 is completely unused:
10.0.0.0 - 10.255.255.255(訳注：プライベートアドレス、クラスA)をEucalyptus用として指定する場合
VNET_MODE="MANAGED-NOVLAN" VNET_SUBNET="10.0.0.0" VNET_NETMASK="255.0.0.0" VNET_DNS="<your DNS>" VNET_ADDRSPERNET="128"
or if the network 192.168.0.0 - 192.168.255.255 is completely unused:
192.168.0.0 - 192.168.255.255(訳注：プライベートアドレス、クラスC)をEucalyptus用として指定する場合
VNET_MODE="MANAGED-NOVLAN" VNET_SUBNET="192.168.0.0" VNET_NETMASK="255.255.0.0" VNET_DNS="<your DNS>" VNET_ADDRSPERNET="64"
You will need to carefully inspect the firewall on the front-end to make sure that it will not interfere with Eucalyptus, or vice-versa. Eucalyptus will flush the 'filter' and 'nat' tables upon boot in MANAGED-NOVLAN mode, but provides a way for the administrator to define special rules that are loaded when Eucalyptus starts (see below for details).
Eucalyptus がファイアウォールの影響を受けないか、あるいは逆に影響を与えていないかどうか、フロントエンド上で慎重に設定を調べる必要があります。Eucalyptus は MANAGED-NOVLANモードで起動する際、'filter' と 'nat' の設定をリセット（flush）しますが、管理者向けとして Eucalyptus 起動時に特定のルールを読み込むように指定することもできます（詳細は後述します）。
The Eucalyptus administrator must configure the front-end's 'eucalyptus.conf' first with a valid, configured ethernet device that is attached to the same physical ethernet as the Eucalyptus nodes:
Eucalyptus 管理者は、まずはじめに、フロントエンド側の 'eucalyptus.conf' で適切なイーサネット・デバイスを指定します。このデバイスは、ノードと同じネットワークに接続されている物理イーサネットデバイスである必要があります。
VNET_PRIVINTERFACE="eth0"
If the front-end has a second ethernet device which is used to access the public network, let's say eth1, then you need to configured it as
フロントエンドに２つの物理ネットワークインターフェイスがあり、上記で記載したインターフェイスと異なるインターフェイスが外部ネットワーク(訳注：Eucalyptusクライアントがアクセス可能なネットワーク)に接続されている場合、VNET_PUBINTERFACEをセットします。以下の例ではeth1をパブリックインターフェイスとしてセットしています。
VNET_PUBINTERFACE="eth1"
Next, the admin ust ensure that there is a DHCP server binary installed on the front-end and Eucalyptus knows where it is located:
次に、フロントエンドのDHCPサーバのフルパスを指定します。
VNET_DHCPDAEMON="/usr/sbin/dhcpd3"
If your DHCP daemon binary is configured to run as 'non-root' (say, as the user 'dhcpd' as is the case in Ubuntu >= 8.10), then you must configure Eucalyptus to be aware of that user:
環境によってはDHCPサーバはroot以外で実行されます(例えば Ubuntu 8.10 以降では 'dhcpd'ユーザアカウントで実行されます)。その場合はVNET_DHCPUSERに実行するユーザアカウントをセットします。
VNET_DHCPUSER="<dhcpusername>"
Nodes must have VNET_BRIDGE set properly:
ノードではVNET_BRIDGEを適切に設定します
VNET_BRIDGE="br0"
Once you have verified that your network configuration meets the requirements for running in MANAGED-NOVLAN mode, the rest of the configuration is fairly simple. For example, if the 192.168.0.0/16 network is free and unused on your network:
ここまで設定がうまくいけば、あとの設定は非常にシンプルです。例えば192.168.0.0/16のIPアドレスをEucalyptus用に使用する場合は以下のように設定します。
VNET_MODE="MANAGED-NOVLAN" VNET_SUBNET="192.168.0.0" VNET_NETMASK="255.255.0.0" VNET_DNS="<your dns>" VNET_ADDRSPERNET="64" VNET_PUBLICIPS="<publicIPa> <publicIPb> ... <publicIPn>"
SUBNET, NETMASK, and DNS have been described previously. VNET_ADDRSPERNET is used to control how many VM instances may simultaneously be part of an individual user's named network (called a 'security group' in Amazon EC2). Choosing the right value for this parameter depends on how many IPs you have made available using VNET_SUBNET/VNET_NETMASK, how many VLANs your network supports simultaneously, and how many concurrent active user networks the administrator wishes to support.
SUBNET、NETMASK、DNS については既に記述しました。VNET_ADDRSPERNET では、幾つの仮想マシン・インスタンスが、それぞれの名前がつけられたネットワーク（Amazon EC2 で言うところの「security group」）上に存在できるかという幅を設定するものです。ここでどのような値を設定すべきかどうかは、管理者がどの程度のネットワークを必要とするかによります。例えば、VNET_SUBNET や VNET_NETMASK の範囲内において、IP アドレスを幾つ使っているかや、同時に幾つの VLAN ネットワークを使いたいか、ネットワーク上を利用するのは何人ぐらいかといった、それぞれの状況を確認してください。
In the above example, there are 65536 addresses available (192.168.0.0/16). If we divide by the number of addresses per network (set to 64 above), we find the maximum number of simultaneous active named networks that can be in use at any one point in time (65536 / 64 == 1024). If your eucalyptus installation has 100 users, then each user could have at most 10 active security groups in operation at any point in time (of course, they can define as many as they wish, but can only have sets of running VMs residing in at most 10 networks).
上記の例では、ネットワーク全体では 65536 個の IP アドレス（192.168.0.0/16）が利用可能ですが、EucalyptusはIPアドレスを security group の単位に分割します（上記の例では1セキュリティ・グループあたり 64 個のIPアドレスを割り当てる）。結果、いくつの名前付けネットワーク(security group)が使用可能なのかを判別することができます（65536/64 = 1024 ）。この環境で100 人のユーザが Eucalyptus を使用した場合、個々のユーザが使えるセキュリティ・グループは、10 グループ程度になることがわかります。（もちろんユーザは可能な限り多くのセキュリティ・グループを使いたいのですが、(上記の試算より、)実際に使えるセキュリティ・グループの数は、多くても10個、ということになります）
Each security group could support up to 61 instances (64 addresses minus 1 address for the subnet, broadcast, and router IPs). If your installation favors more VMs per network and fewer active security groups per user, the administrator may adjust the VNET_ADDRSPERNET parameter accordingly. Setting it to '256' would result in each active user's security group supporting up to 253 VM instances, and each of 100 users could simultaneously have 2 active security groups.
上記の設定では、個々のセキュリティ・グループあたり61個のインスタンスが起動可能です(64個のIPアドレスから、サブネット、ブロードキャスト、ゲートウェイ用に使用されるIPアドレスをのぞいた残りがインスタンスに割り当て可能です)。もし１つのセキュリティ・グループあたりのVM数を多くし、１ユーザあたりのアクティブなセキュリティ・グループを減らすのであれば、VNET_ADDRSPERNETを変更します。例えばVNET_ADDRSPERNETを 256 にセットした場合、１つのセキュリティ・グループあたりのインスタンス起動可能数は253になり、100ユーザに均等にセキュリティ・グループを割り当てた場合は、１ユーザあたりのセキュリティ・グループの数は2(65536 / 256 / 100 = 2.56)になります。
If you would like users to log in to their instances from outside the cluster/cluster front-end, you must find a set of public IP addresses, that are not in use, and allow Eucalyptus to dynamically route them to VM instances at instance boot time or dynamically at run time. For each IP address you choose, your front-end must be capable of being configured with that IP address. To test, choose some free public IP addresses and perform the following test for each one:
ユーザがクラスタの外部からインスタンスにログインすることが必要であった場合、管理者は未使用のPublic IPを用意する必要があります。EucalyptusはPublic IPがインスタンスに届くように、インスタンスの起動時にフォワードルールを適用します。これにより外部からPublic IP宛に送信されたIPパケットはインスタンスに到達することができます。このような動作をするためには、フロントエンドはPublic IPを割り当てることができるようになっていることが必要です。テストするためには以下のようにします。
on the front-end:
フロントエンド側では以下のようにコマンドを実行します
ip addr add <publicIP>/32 dev <interface>
on some external machine representative of where users will wish to log into their VM instances:
外部のマシンから、Public IP宛のpingコマンドを実行します。
ping <publicIP>
if this works, then dynamic IP assignment to VM instances will work. Remove the assigned address with the following command:
上記のpingが疎通すれば、インスタンスに動的にPublic IPを割り当てても動作するでしょう。先ほどテストのために割り当てたPublic IPを解除します。
ip addr del <publicIP>/32 dev <interface>
Once you have compiled a list of available public IP addresses, allow Eucalyptus to use them by listing the IPs in 'eucalyptus.conf':
使用可能なPublic IPを決めたら、'eucalyptus.conf'の中に以下のように記述します。
VNET_PUBLICIPS="<publicIPa> <publicIPb> ... <publicIPn>"
or, you can specify a range of IPs with:
Public IPは範囲指定も可能です。以下のように記述します。
VNET_PUBLICIPS="<publicIPa>-<publicIPb>"
where publicIPa and publicIPb are in the same /24 subnet.
上記のpublicIPa と publicIPbは同一の24ビットサブネットに属するIPアドレスである必要があります。
If your cluster-controller and cloud-controller are running on separate hosts, you need to set:
クラスタ・コントローラとクラウド・コントローラが別のマシンで動作している場合は以下のように設定する必要があります。
VNET_CLOUDIP="<ip-of-cloud-controller>"
And, if you are running multiple clusters in your installation, and wish to manually specify the IP of the cluster-controller that all other cluster-controllers can reach, you may set:
マルチクラスタ構成を取っている場合は、以下のようにクラスタ・コントローラのIPアドレスをセットします。このIPアドレスは他のクラスタ・コントローラと疎通できる必要があります。
VNET_LOCALIP="<ip-of-cluster-controller"
The cluster-controller will attempt to determine this value automatically if it is not set.
上記の設定がない場合は、起動時に適切と思われるアドレスを自動的にセットします。
CAVEATS - When Eucalyptus is running in MANAGED-NOVLAN mode, you cannot currently run an entire eucalyptus installation on a single machine as this mode depends upon traffic between named networks passing through a front-end router (instead of going through the loopback device). If you wish to run Eucalyptus on a single machine (laptop), you must use SYSTEM or STATIC mode. In MANAGED-NOVLAN mode, Eucalyptus will flush the front-end's iptables rules for both 'filter' and 'nat'. Next, it will set the default policy for the 'FORWARD' chain in 'filter' to 'DROP'.
警告：EucalyptusをMANAGED-NOVLANモードで動作する場合、１台のマシンで全てのコンポーネントを動作させることはできません。これはセキュリティ・グループ間のトラフィックがフロントエンドで動作するルーティングに依存しているためです。(訳がおかしい？) Eucalyptusを（ラップトップのような）１台のマシンで動作させる場合はSYSTEMモードか、STATICモードを使用するようにしてください。MANAGED-NOVLANモードでは、Eucalyprusはフロントエンドのiptablesルールの'filter', 'nat'ルールを消去(flush)します。次に'filter'ルールの'FORWARD'チェインを'DROP'チェインに接続するよう、デフォルトルールをセットします。
At run time, the front-end will be adding and removing rules from 'FORWARD' as users add/remove ingress rules from their active security groups. In addition, the 'nat' table will be configured to allow VMs access to the external network using IP masquerading, and will dynamically add/remove rules in the 'nat' table as users assign/unassign public IPs to VMs at instance boot or run-time. If the administrator has some rules that they wish to apply o the front-end, they should perform the following procedure on the front-end, before eucalyptus is started or while eucalyptus is not running.
その後、動作中にセキュリティ・グループの設定に応じて、'FORWARD'チェインの内容を追加・削除します。加えて外部のネットワークと疎通できるように、'nat'ルール内にIPマスカレードの設定を追加します。またユーザがPublic IPを割り当てた場合には'nat'テーブルに動的にルールを追加・削除します。もしEucalyptusの動的なルール変更以上のルールを追加したい場合は以下のコマンドを実行します。以下のコマンドはEucalyptusが停止している時に実行してください。
WARNING if the admin chooses to perform this operation to define special iptables rules that are loaded when Eucalyptus starts, they could inadvertently cause Eucalyptus VM networking to fail. It is suggested that you only do this only if you are completely sure that it will not interfere with the operation of Eucalyptus.
注意：もし以下のコマンドを実行してiptablesに追加ルールをセットした場合、インスタンスのネットワークの疎通に不具合が出る可能性があります。以下のコマンドを実行する場合は、それ(iptablesへのルール追加)がEucalyptusに及ぼす影響について完全に把握している必要があります。
<use iptables to set up your iptables rules> iptables-save > $EUCALYPTUS/var/run/eucalyptus/net/iptables-preload
If you edit a networking related value in eucalyptus.conf, you will need to restart the CC ($EUCALYPTUS/etc/init.d/eucalyptus-cc restart) for changes to take effect. If you change the networking mode, you will need to perform a cleanrestart ($EUCALYPTUS/etc/init.d/eucalyptus-cc cleanrestart)
'eucalyptus.conf'の項目を変更した場合、クラスタ・コントローラ(CC)を再起動($EUCALYPTUS/etc/init.d/eucalyptus-cc restart)して変更を反映します。ネットワークモードを変更した場合は特別な再起動コマンド($EUCALYPTUS/etc/init.d/eucalyptus-cc cleanrestart)を実行してください。
If you are running Eucalyptus in multi-cluster mode, we strongly recommend that you configure all your clusters to have an identical networking mode. In addition we strongly recommend that you do not run multiple clusters in the same broadcast domain. Each cluster should be in a separate domain.
マルチクラスタ構成を取っている場合は、全てのクラスタを同一のネットワークモードにすることを強く勧めます。加えて個々のクラスタを異なるサブネット(ブロードキャストが異なるLAN)で構成することを強く勧めます。
Eucalyptus versions >= 1.6 support multiple clusters within a single Eucalyptus cloud installation. This section briefly describes how Eucalyptus manages the networking aspect of a multi-cluster setup.
Eucalyptusは 1.6 以降で１つのクラウドの中に複数のクラスタを含む、マルチクラスタ構成をサポートしています。このセクションではマルチクラスタ構成におけるネットワーク管理について簡単に記述しています。
First, in SYSTEM or STATIC networking modes, Eucalyptus does not perform any special configuration for a multi-cluster setup. In MANAGED and MANAGED-NOVLAN modes, Eucalyptus will set up layer two tunnels between your clusters, so that virtual machines that are in the same security group, but distributed across clusters (potentially each in their own broadcast domain), can communicate with one another. We use the 'vtun' package to handle all layer two tunneling between clusters.
SYSTEMモード・STATICモードでは、マルチクラスタ構成でも特に特別な動作はありません。MANAGEDモード・MANAGED-NOVLANモードでマルチクラスタ構成を取ると、Eucalyptusはクラスタ間に２つのトンネルを形成します。これによって同一のセキュリティ・グループに属し、異なるクラスタにある２つのインスタンスが相互に通信を行うことができます。クラスタ間のトンネルを形成するために、Eucalyptusは 'vtun' パッケージを使用します。
For the most part, as long as 'vtun' is installed on your cluster controllers, multi-cluster tunneling is handled automatically by the cluster controller software. There are a few caveats to be aware of, depending on your chosen networking mode and network topology.
ほとんどの場合、クラスタ・コントローラにインストールされた 'vtun' は、クラスタ・コントローラによって自動的に制御され、クラスタ間にトンネルを形成します。ただしネットワークモードとネットワークのトポロジによっては注意が必要です。
If you wish to disable tunneling altogether, set 'VNET_LOCALIP=0.0.0.0' in eucalyptus.conf.
トンネリングを無効にする場合は、eucalyptus.confの VNET_LOCALIP を '0.0.0.0' にセットします。
