EucalyptusNetworking_v1.6

Eucalyptus Network Configuration (1.6)

Eucalyptusのネットワーク設定 (1.6)

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の仮想ネットワーク機能は大きく4つの「ネットワークモード」に分かれており、それぞれ固有の設定・機能・利点と制限を持っています。Eucalyptus管理者は4つのうち1つのネットワークモードを選択し適切に設定する必要があります。ネットワークモードの設定はフロントエンド・各ノードそれぞれの"eucalyptus.conf"設定ファイルに記述します。4つのネットワークモードについて、以下に簡単に内容を記述します。

  • SYSTEM Mode - This is the simplest networking mode, but also offers the smallest number of networking features. In this mode, Eucalyptus simply assigns a random MAC address to the VM instance before booting and attaches the VM instance's ethernet device to the physical ethernet through the node's local Xen bridge. VM instances typically obtain an IP address using DHCP, the same way any non-VM machine using DHCP would obtain an address. Note that in this mode, the Eucalyptus administrator (or the administrator that manages the network to which Eucalyptus components are attached) must set up a DHCP server that has a dynamic pool of IP addresses to hand out as VMs boot. In other words, if your laptop/desktop/server gets an IP address using DHCP on the same network as the Eucalyptus nodes, then your VMs should similarly obtain addresses. This mode is most useful for users who want to try out Eucalyptus on their laptops/desktops.
    SYSTEMモード:もっともシンプルなモードですが、提供される機能も最小限のモードです。SYSTEMモードでは、インスタンスは起動前にランダムなMACアドレスを割り当てられ、Xenのブリッジインターフェイスに接続されます。インスタンスは多くの場合(物理的なマシンと同じように)DHCP経由でIPアドレスを取得します。Eucalyptus管理者は払い出し可能なIPアドレスプールを持つDHCPサーバを構成する必要があります(いくつかの環境ではEucalyptusの管理者とネットワークの管理者は別の人であることがあるでしょう)。1つのDHCPサーバが到達可能な範囲に、DHCPでIPアドレスを取得する物理的なノートパソコン・デスクトップパソコン・サーバがあり、Eucalyptusの各マシン(フロントエンドや各ノード)が含まれているのであれば、インスタンスもまた同様に、同じDHCPサーバからIPアドレスの割り当てを受けます。SYSTEMモードはノートパソコンやデスクトップパソコンでEucalyptus環境を構築したい場合にもっとも役に立つでしょう。
  • STATIC Mode - This mode offers the Eucalyptus administrator more control over VM IP address assignment. Here, the administrator configures Eucalyptus with a 'map' of MAC address/IP Address pairs. When a VM is instantiated, Eucalyptus sets up a static entry within a Eucalyptus controlled DHCP server, takes the next free MAC/IP pair, assigns it to a VM, and attaches the VMs ethernet device to the physical ethernet through the Xen bridge on the nodes (in a manner similar to SYSTEM mode). This mode is useful for administrators who have a pool of MAC/IP addresses that they wish to always assign to their VMs.
    STATICモード:STATICモードはインスタンスへのIPアドレスにより柔軟性を持たせるモードです。Eucalyptus管理者はMACアドレスとIPアドレスが1対1で対応する「マップ」を作成します。Eucalyptusが独自に起動するDHCPサーバは「マップ」から未使用のペアを見つけ、MACアドレスを起動前のインスタンスに割り当てます。インスタンスのネットワークデバイスはSYSTEMモードと同様にXenのブリッジインターフェイスに接続されます。このモードはEucalyptus管理者がEucalyptusクラウドに属する各マシンに固定の範囲のIPアドレスを割り当てる場合に役に立つでしょう。
  • NOTE - Running Eucalyptus in SYSTEM or STATIC mode disables some key functionality such as the definition of ingress rules between collections of VMs (termed security groups in Amazon EC2), the user-controlled, dynamic assignment of IPs to instances at boot and run-time (elastic IPs in Amazon EC2), isolation of network traffic between VMs (that is, the root user within VMs will be able to inspect and potentially interfere with network traffic from other VMs), and the availability of the meta-data service (use of the http://169.254.169.254/ URL to obtain instance specific information).
    注意:EucalyptusクラウドをSYSTEMモードもしくはSTATICモードで実行した場合、インスタンスへのIPアドレス割り当てについてのいくつかの主要な機能が無効になります。無効になる機能は以下のものです。
    • 個々のVMのネットワークへのポートフィルタ機能(Amazon EC2でいうところのSecury Group機能)
    • 個々のユーザによるIPアドレス割り当て機能(Amazon EC2でいうところのElastic IP機能)
    • VM間のネットワーク分離機能(つまり、SYSTEMモードもしくはSTATICモードでは個々のVMのrootは、隣接する他のVMの通信内容を盗み見たり、潜在的には干渉できる可能性があるということを意味します)
    • メタデータサービス(インスタンス内部から http://169.254.169.254/ にアクセスすることで取得できる、インスタンスおよびEucalyptusクラウドに関する情報取得サービス)
  • MANAGED Mode - This mode is the most featureful of the three modes, but also carries with it the most potential constraints on the setup of the Eucalyptus administrator's network. In MANAGED mode, the Eucalyptus administrator defines a large network (usually private, unroutable) from which VM instances will draw their IP addresses. As with STATIC mode, Eucalyptus will maintain a DHCP server with static mappings for each VM instance that is created. Eucalyptus users can define a number of 'named networks', or 'security groups', to which they can apply network ingress rules that apply to any VM that runs within that 'network'. When a user runs a VM instance, they specify the name of such a network that a VM is to be a member of, and Eucalyptus selects a subset of the entire range of IPs that other VMs in the same 'network' can reside. A user can specify ingress rules that apply to a given 'network', such as allowing ping (ICMP) or ssh (TCP, port 22) traffic to reach their VMs. This capability allows Eucalyptus expose a capability similar to Amazon's 'security groups'. In addition, the administrator can specify a pool of public IP addresses that users may allocate, then assign to VMs either at boot or dynamically at run-time. This capability is similar to Amazon's 'elastic IPs'. Eucalyptus administrators that require security groups, elastic IPs, and VM network isolation must use this mode.
     
    MANAGEDモード:MANAGEDモードはEucalyptus管理者が選択できるネットワークモードのうち最も機能が豊富ですが、Eucalyptus管理者がネットワークを構築する上で、最も制約を受ける可能性もあります。MANAGEDモードでは、Eucalyptus管理者はプライベートアドレスで構成され、外部にルーティングされないネットワークを構築します(訳注:よく"浮島"と表現されるような隔離されたネットワーク環境)。このプライベートネットワークの中では全てのインスタンスはそのLAN内固有のIPアドレスの割り当てを受けます。
     
    MANAGEDモードではSTATICモードと同様に、Eucalyptusは自前のDHCPサーバを動作させ、MACアドレスとIPアドレスが1対1で対応する「マップ」を維持管理します。
     
    MANAGEDモードでは、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モードを使用しなくてはいけません。  
    (訳注:MANAGEDモードを使用するには、各マシンの物理インターフェイスおよびネットワークスイッチの接続ポートでVLANタグ付きパケットの取り扱いができることが必要です。ネットワークスイッチの選定には注意してください)
  • MANAGED-NOVLAN Mode - This mode is identical to MANAGED mode in terms of features (dynamic IPs and security groups) but does not provide VM network isolation. Admins who want dynamic assignable IPs and the security groups, but are not running on a network that is 'VLAN clean' or don't care if their VMs are isolated from one another on the network should choose this mode.
     
    MANAGED-NOVLANモード:MANAGED-NOVLANモードでは、MANAGEDモードと同じ機能(動的な IP アドレス割り当や secugiry groups)を持ちますが、仮想マシン・ネットワーク間で通信の隔離を行いません。管理を行う上で、IP アドレスを動的に割り当てる機能や security group を使いたい場合、「クリーンな VLAN(訳注:隣接するVM(Security Group)間で通信内容を盗み見たり、潜在的に干渉できる可能性のないネットワーク形態)」を求めない場合や、仮想マシン間のネットワークがお互いに隔離されているかどうかを気にしないのであれば、このモードを選ぶこともできるいでしょう。

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

Bridges

ネットワークブリッジの設定

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アドレスを取得することを想定しています。

Centos

CentOSでの設定例

# 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

OpenSUSE

OpenSUSEでの設定例

# 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 を選択
終了 を選択

Ubuntu and Debian

Ubuntu、Debianでの設定例

# 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'であることを前提に記述しています。

SYSTEM Mode

SYSTEMモード

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 を飛ばしてみてください。

STATIC Mode

STATICモード

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
フロントエンドに2つの物理ネットワークインターフェイスがあり、上記で記載したインターフェイスと異なるインターフェイスが外部ネットワーク(訳注: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で指定)を書くことを推奨します。

MANAGED Mode

MANAGEDモード

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 が動作するためには、ローカルなネットワーク及び設定において、幾つかの動作条件が必要となります。

Requirements for MANAGED mode

MANAGEDモードの動作条件

Before using 'MANAGED' mode, you must confirm that:
MANAGEDモードを使用する前に以下の事項を満たしていることを確認してください。

  • 1.) there is an available range of iP addresses that is completely unused on the network (192.168..., 10....., other).
    全く使用されていないIPアドレスの範囲があること
  • 2.) your network is 'VLAN clean', meaning that all switch ports that Eucalyptus components are connected to will allow and forward VLAN tagged packets.
    'VLANクリーン'であること。つまりスイッチのポートがタグVLANパケットを通すことができること。
  • 3.) you are not running a firewall on the front-end (CC) or your firewall is compatible with the dynamic changes that Eucalyptus will make to the front-end's netfilter rules.
    フロントエンドでファイアーウォールを実行していないか、実行していてもEucalyptusが生成するnetfilterルールの動的な生成・変更に対応できること

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モードを設定する前に、上記の3つが満たされていることを確認してください。満たされていない状態で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 起動時に特定のルールを読み込むように指定することもできます(詳細は後述します)。

Configuring MANAGED mode

MANAGEDモードの設定

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
フロントエンドに2つの物理ネットワークインターフェイスがあり、上記で記載したインターフェイスと異なるインターフェイスが外部ネットワーク(訳注: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)と疎通可能なインターフェイスを指定します。2つとも同じデバイス名をセットします)。例えば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アドレスをのぞいた残りがインスタンスに割り当て可能です)。もし1つのセキュリティ・グループあたりのVM数を多くし、1ユーザあたりのアクティブなセキュリティ・グループを減らすのであれば、VNET_ADDRSPERNETを変更します。例えばVNET_ADDRSPERNETを 256 にセットした場合、1つのセキュリティ・グループあたりのインスタンス起動可能数は253になり、100ユーザに均等にセキュリティ・グループを割り当てた場合は、1ユーザあたりのセキュリティ・グループの数は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モードで動作する場合、1台のマシンで全てのコンポーネントを動作させることはできません。これはセキュリティ・グループ間のトラフィックがフロントエンドで動作するルーティングに依存しているためです。(訳がおかしい?) Eucalyptusを(ラップトップのような)1台のマシンで動作させる場合は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

Troubleshooting MANAGED Mode

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

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モードを使うための前提条件が正しく満たされているかどうかを確認します。確認するのは以下の項目です。

  • IPアドレスの範囲指定は正しいか?
  • スイッチは正しくタグVLANパケットを転送できるか?
  • firewallの動作を阻害するようなルールをセットしているかどうか?(フロントエンド、ノードともに)

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ルールが1つ、インスタンスのIPアドレスから外部にフォワードされる際のSNATルールが1つ存在すれば正しい設定が行われています。そうでない場合は 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:
フロントエンドとノード(現象が出ているものを1つ)での、以下のコマンドの出力。

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を私たちに送ってください。

MANAGED-NOVLAN Mode

MANAGED-NOVLANモード

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 が動作するためには、ローカルなネットワーク及び設定において、幾つかの動作条件が必要となります。

Requirements for MANAGED-NOVLAN mode

MANAGED-NOVLANモードの動作条件

Before using 'MANAGED-NOVLAN' mode, you must confirm that:
MANAGED-NOVLANモードを使用する前に以下の事項を満たしていることを確認してください。

  • 1.) there is an available range of iP addresses that is completely unused on the network (192.168..., 10....., other).
    全く使用されていないIPアドレスの範囲があること
  • 2.) you are not running a firewall on the front-end (CC) or your firewall is compatible with the dynamic changes that Eucalyptus will make to the front-end's netfilter rules.
    フロントエンドでファイアーウォールを実行していないか、実行していてもEucalyptusが生成するnetfilterルールの動的な生成・変更に対応できること

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 起動時に特定のルールを読み込むように指定することもできます(詳細は後述します)。

Configuring MANAGED-NOVLAN mode

MANAGED-NOVLANモードの設定

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
フロントエンドに2つの物理ネットワークインターフェイスがあり、上記で記載したインターフェイスと異なるインターフェイスが外部ネットワーク(訳注: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アドレスをのぞいた残りがインスタンスに割り当て可能です)。もし1つのセキュリティ・グループあたりのVM数を多くし、1ユーザあたりのアクティブなセキュリティ・グループを減らすのであれば、VNET_ADDRSPERNETを変更します。例えばVNET_ADDRSPERNETを 256 にセットした場合、1つのセキュリティ・グループあたりのインスタンス起動可能数は253になり、100ユーザに均等にセキュリティ・グループを割り当てた場合は、1ユーザあたりのセキュリティ・グループの数は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モードで動作する場合、1台のマシンで全てのコンポーネントを動作させることはできません。これはセキュリティ・グループ間のトラフィックがフロントエンドで動作するルーティングに依存しているためです。(訳がおかしい?) Eucalyptusを(ラップトップのような)1台のマシンで動作させる場合は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)で構成することを強く勧めます。

Multi-cluster networking

マルチクラスタ構成のネットワーク

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 以降で1つのクラウドの中に複数のクラスタを含む、マルチクラスタ構成をサポートしています。このセクションではマルチクラスタ構成におけるネットワーク管理について簡単に記述しています。

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はクラスタ間に2つのトンネルを形成します。これによって同一のセキュリティ・グループに属し、異なるクラスタにある2つのインスタンスが相互に通信を行うことができます。クラスタ間のトンネルを形成するために、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' は、クラスタ・コントローラによって自動的に制御され、クラスタ間にトンネルを形成します。ただしネットワークモードとネットワークのトポロジによっては注意が必要です。

  • MANAGED mode: during normal operation, you will see many tunnel interfaces being created and destroyed as virtual networks are constructed and torn down.
    通常では、仮想ネットワークの形成・解除と同様に、多くのトンネルが形成・解除されます。
  • MANAGED-NOVLAN mode: your CC will need to be configured with a bridge as it's primary, public interface (VNET_PUBINTERFACE) in order for vtun tunneling to work in this mode.
    MANAGED-NOVLANモードでは、'vtun' が正常に動作するために、クラスタ・コントローラのプライマリかつパブリックインターフェイス(VNET_PUBINTERFACE)はブリッジインターフェイスである必要があります。
  • BOTH modes: the CC attempts to auto-discover it's list of local IP addresses upon startup, but if the IP that was used to register the CC is not locally available, you can override the CC's notion of 'self' by setting the 'VNET_LOCALIP' variable in eucalyptus.conf.
    MANAGEDおよびMANAGED-NOVLANモード:クラスタ・コントローラが起動する時に、使用可能なIPアドレスのリストを自動的に判別します。しかしクラスタ・コントローラを登録しようとしたIPアドレスが使用できない場合、eucalyptus.confの 'VNET_LOCALIP' に設定した値で上書きすることができます。
  • BOTH modes: do not run two CCs in the same broadcast domain with tunneling enabled, this will potentially lead to a broadcast storm as tunnels start forwarding packets in a loop on your local network.
    MANAGEDおよびMANAGED-NOVLANモード:同一のブロードキャストドメイン内で2つのクラスタ・コントローラをトンネリングをサポートした状態で動作させてはいけません。これをどうささせると、トンネルはそのLANの中でパケットをループさせ、ブロードキャスト・ストームが発生することになります。

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' にセットします。

戻る:Eucalyptusのバックアップ(1.6)

進む:Eucalyptusイメージの管理(1.6)


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2010-04-18 (日) 23:20:40 (3734d)