始めに
予備知識ほぼゼロの状態から、KVMの延長でOpenStackを勉強がてらセットアップしようとしたら、ハマりにハマりました。せっかくなので調査したことや、手順をまとめておきます。
概要
基本は下記公式ドキュメントに沿った作業手順になります。
https://openstack.redhat.com/Neutron_with_existing_external_network
https://openstack.redhat.com/Running_an_instance_with_Neutron
https://openstack.redhat.com/Floating_IP_range
ここから、下記のような構成を作ります。
![Network Diagram_.png](https://qiita-image-store.s3.amazonaws.com/0/62290/7575a30b-818d-b2fd-254c-f32c77fc50e8.png "Network Diagram_.png" "図1:構成概要")
図1:構成概要
VMは10.0.0.0/24のprivate subnetネットワーク配下に作り、その後にpublic subnetネットワークのfloatipを割り当てて、publicネットワークの物理マシンと通信します。
最初、KVMのノリで直接public subnetネットワーク配下にマシンを作ろうとして、他の物理マシンと通信できずハマってしまいました。構成図で、×のついているマシンにあたります。通信できなかった原因は後述します。
本手順のインストールにより構成される、CentOS7(以下、AllInOneノード)内部のネットワーク構造は下図のようになります。
![network-OpenStack.png](https://qiita-image-store.s3.amazonaws.com/0/62290/b33f8aec-12f0-1bbe-ce2d-5c38a11324f7.png "network-OpenStack.png" "図2:ネットワーク構造")
図2:AllInOneでのネットワーク構造
まず、以下のブリッジが作られます。
- qbrX: VMインスタンスごとに作成されるLinux Bridge
- br-int: integration用のOVSスイッチ
- br-tun: 他のノードと通信するためのOVSスイッチ。AllInOneでは使いません
- br-ex: 外部ネット接続用のOVSスイッチ
Linux BridgeがVMインスタンスごとに作成されるのは、インスタンスにセキュリティグループを適用するのに、OVSスイッチは使えないためのようです。
参考: http://www.slideshare.net/VirtualTech-JP/20140929-rev-r
VMが外に出る際は、下記のような流れになります。
- eth0 -> tapX: VMインスタンスがtapデバイスに通信します。
- qvbX(veth brige) -> qvoX(veth openvswitch): veth経由で、Linux BridgeからOpen vSwitch のbr-intに通信します。
- qrX(router) -> qgX(gateway): Open vSwitchの内部ポート同士で、qrouter namespaceのiptablesが転送します。
- enp6s0(物理NIC)から外に出ます。
ちにみに、図１でxの付いた箇所にVMをつくると、publicのIP(192.168.1.X)が割り当てられるものの、qvoXはbr-intに接続されているため、外と通信できません。br-intから無理矢理ポートを引き抜いて、br-exに接続したら、外と通信できました。
参考までに、KVMをLinux Bridgeで構成した際のネットワーク構造は下記のようになります。
図3:KVMとLinux Bridgeでのネットワーク構造
シンプルです。
インストールしたマシンは下記となります。NICは2枚必要かと思って増設しましたが、結局1つで大丈夫でした。
ML115 G1
CPU: Athlon 64 X2 4600+
Mem: 4GB
NIC: enp6s0 (オンボード)
enp1s9 (PCI,ifdown)
後述しますが、非力すぎてブート時のネットワークのコンポーネントのNeutronの起動が、たまに失敗します。
packstack / RDO / RHOSP について
インストールにはRDOを使います。公式のマニュアルは下記です。
https://openstack.redhat.com/Quickstart
RDOがfedoraのようなものだとすれば、REHLにあたるものがRed Hat Enterprise linux OpenStack Platform(RHOSP)になると思います。安定板のためOpenStackのバージョンは古いですが、日本語のドキュメントが豊富にあり、かなり参考になります。
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux_OpenStack_Platform/
エンタープライズ環境への導入マニュアルもあり、動かせて雰囲気がつかめたら、次のステップに読んでみるとよいかもしれません。
packstack実行におけるオプション指定や、answaerファイルの設定項目については、下記の日本語資料がとても参考になります。RHOSPのものですが、RDOでも使えるようです。
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux_OpenStack_Platform/5/html/Getting_Started_Guide/sect-Running_PackStack_Non-interactively.html
手順
インストール前の準備
NetworkManagerを無効化
そのままインストールすると、インストール後に下記のような警告がでます。
Warning: NetworkManager is active on 192.168.1.45 OpenStack networking currently does not work on systems that have the Network Manager service enabled.
これを防ぐため、NeworkManagerを無効にし、旧来のnetworkサービスを設定しておきます。
systemctl disable NetworkManager
systemctl stop NetworkManager
NM_CONTROLLED=no
ONBOOT=yes
GATEWAY=192.168.1.1
nameserver 192.168.1.1
service network start
chkconfig network on
###その他の設定
- SELINUXはpermissiveにしておきます。disableにしておくと、packstackインストール中のSELINUXの自動設定でコケます。enableでもインストールできますが、ネットワークノードを多ノード構成にし、VRRPでHAルータを作成しようとした際に、keepaliveが起動できなくてハマりました。
参考:http://www.slideshare.net/orimanabu/l3-ha-vrrp20141201 - Junoでは/etc/sysctl.conf のカーネルパラメータ設定は必要ないようです。packstackでpupetが自動設定してくれていました。
- CentOS7をMinimalでインストールした場合は、deltarpmを事前にインストールしておきます。
yum -y install deltarpm
RDOリポジトリの登録
チュートリアルによくある https://rdo.fedorapeople.org/rdo-release.rpm を指定すると、いつの間にか次のバージョンになってることがあり混乱するので、Junoを明示的に指定します。最初、チュートリアルに従ってCentOS6にOpenStack(icehouse)をインストールしようとしたら、既にJunoになっており、おまけにCentOS6用のパッケージが作られておらず、インストールがエラーになって混乱しました。
yum install -y http://rdo.fedorapeople.org/openstack-juno/rdo-release-juno.rpm
システムアップデート
CentOS6系でNeutronを使う際は、カーネルをOpenStack用のものに置換するため、アップデート作業が必須のようでしたが、CentOS7系で必須かどうかは未確認です。ただやっておいて損は無いかと思います。
yum -y update
reboot
参考:
https://openstack.redhat.com/Neutron-Quickstart
パッケージダウンロード
yum install -y openstack-packstack
monogodbインストールスクリプトの修正
そのままpackstackを実行すると、Ceilometerに必要なmongodbのインストールでコケます。(2014/12/12現在。修正されているかもしれません)
参考:https://ask.openstack.org/en/question/54015/mongodbpp-error-when-installing-rdo-on-centos-7/
class {
‘mongodb::server’: smallfiles => true,
bind_ip => [‘%(CONFIG_MONGODB_HOST)s’],
pidfilepath => '/var/run/mongodb/mongod.pid'
}
pidfileのパスを明示的に指定しておきます。
Cinderが使う容量の決定
packstackをそのまま実行すると、/var/lib/cinder/に20GBのcinder-volumes ファイルが作成されます。永続性のあるボリュームを作ると、このファイルから切り出されます。VMのブートを試すだけならあまり必要ありませんが、VMを削除したときにも消えない領域が必要であれば、多めに確保しておくと良いと思います。
packstack 実行
allinoneでインストールします。
packstack --allinone --provision-all-in-one-ovs-bridge=n --ntp-servers=ntp.nict.jp --cinder-volumes-size=50G
下記で指定されているように、外部ネットワークに繋げるのであれば、provision-all-in-one-ovs-bridgeをnとしておきます。
https://openstack.redhat.com/Neutron_with_existing_external_network
また、ntpサーバーも指定しておきます。
なお詳細は未確認ですが、packstack の実行は、AllInOneノードのローカルのターミナルか、screen経由で実行したほうがよさそうです。sshでAllInOneノードに接続したターミナルで実行した際は、インストールが途中で止まっていたことが何度かありました。packstack実行中のネットワークの構成変更が影響してるのかもしれません。
実行すると、カレントディレクトリにanswerファイルが作成されますが、消さずにとっておきます。Compute/Networkノードを追加するときに使います。
なおanswerファイルを見ると、
# Private interface for Flat DHCP on the Nova compute servers
CONFIG_NOVA_COMPUTE_PRIVIF=eth1
# Nova network manager
CONFIG_NOVA_NETWORK_MANAGER=nova.network.manager.FlatDHCPManager
# Public interface on the Nova network server
CONFIG_NOVA_NETWORK_PUBIF=eth0
# Private interface for network manager on the Nova network server
CONFIG_NOVA_NETWORK_PRIVIF=eth1
のように、CentOS7でもお構いなしにethXで設定されており、enp6s0のような名称に変える必要があるか不安になりましたが、調べてみると無視してよいようです。
参考:
https://ask.openstack.org/en/question/7844/what-are-the-nic-in-nova-config-file-used-for/
上記設定はNova Network(レガシーネットワーク)で使われるものであり、デフォルトではレガシーではなく、下記設定によりNeutronが選択されているため、結局使われない設定であるためです。
# Set to 'y' if you would like Packstack to install OpenStack
# Networking (Neutron). Otherwise Nova Network will be used.
CONFIG_NEUTRON_INSTALL=y
Neutronでプライベート通信用のIFを指定するには、下記を指定します。
# The interface for the OVS tunnel. Packstack will override the IP
# address used for tunnels on this hypervisor to the IP found on the
# specified interface. (eg. eth1)
CONFIG_NEUTRON_OVS_TUNNEL_IF=enp1s9
コマンドの引数で指定するには、下記のようにします。
packstack --allinone --provision-all-in-one-ovs-bridge=n --ntp-servers=ntp.nict.jp --cinder-volumes-size=50G --os-neutron-ovs-tunnel-if=enp1s9
これにより下記のような設定が行われ、br-tunの通信が、指定したIFで行われるようになります。
local_ip = (指定したIFのIPアドレス)
CONFIG_NEUTRON_OVS_TUNNEL_IF に何も指定しないと、パブリックと同じIFでプライベート(トンネル)通信が行われます。
物理ネットワークの設定
インストールが正常に完了したら、VMが外部ネットに接続できるように、物理ネットワーク,VXLANの設定を行います。
DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=192.168.1.45 # enp6s0に設定していたIP
NETMASK=255.255.255.0 # enp6s0に設定していた netmask
GATEWAY=192.168.1.1 # your gateway
DNS1=192.168.1.1 # your nameserver
ONBOOT=yes
DEVICE=enp6s0 #
HWADDR=52:54:00:92:05:AE # your hwaddr
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
network_vlan_ranges = physnet1
bridge_mappings = physnet1:br-ex
編集できたら、ネットワークサービスを再起動し、ブリッジを有効化します。
service network restart
仮想ネットワークの設定
デモで作成されるサブネットは、範囲が広すぎて物理環境に影響を及ぼしてしまうので、いったん削除します。
source keystonerc_admin
neutron router-gateway-clear router1
neutron subnet-delete public_subnet
IPの範囲を狭めて再作成します。
neutron subnet-create --name public_subnet --enable_dhcp=False --allocation-pool=start=192.168.1.50,end=192.168.1.150 --gateway=192.168.1.1 public 192.168.1.0/24 --dns-nameservers list=true 192.168.1.1
neutron router-gateway-set router1 public
ここでdnsのオプションを付け加えると、VMインスタンス起動時にdhcpエージェントから配布されるdns設定を指定することができます。dnsオプションが無いと、VMのnameserverに、dhcpエージェントのIPアドレスが指定されます。dhcpエージェントをDNSに使う場合は、dnsmasqの設定ファイルに上位dnsを加えておきます。
dnsmasq_dns_servers = 192.168.1.1
参考:
https://ask.openstack.org/en/question/5042/quantum-dnsmasq-and-resolvconf/
なお、JunoのPackStackでは、下記がデフォルトで設定されます。
dnsmasq_config_file =/etc/neutron/dnsmasq-neutron.conf
dhcp-option-force=26,1400
これによりVMのMTUが自動的に1400に設定されるため、VXLAN使用に伴うMTUの問題はとりあえず対策済みとなっているようです。
OS再起動
VMを作成する前に、AllInOneノードをリブートします。そのまま進めてマシンを作ると、以下のようなエラーがでましたが、リブートしたら直りました。ブート時に読み込むよう設定した何かが足りなかったのかもしれません。
connecting to monitor: Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
2014-12-13 08:47:52.724 23167 TRACE nova.compute.manager [instance: f94d997f-33bf-4b4e-bc93-63e27683836f] Could not access KVM kernel module: Permission denied
2014-12-13 08:47:52.724 23167 TRACE nova.compute.manager [instance: f94d997f-33bf-4b4e-bc93-63e27683836f] failed to initialize KVM: Permission denied
再起動後、各機能が正常にロードされているかを確認します。
openstack-status
下記のneutron-serverのようにfailedになってるものや、(disabled on boot)と記されていないのにinactiveになっているものが、異常状態です。
== neutron services ==
neutron-server: failed
neutron-dhcp-agent: inactive (disabled on boot)
私の環境では、neutronがタイムアウトで起動に失敗していたので、当該サービスだけ再起動しました。
systemctl restart neutron-server
マシンが非力すぎたようです。
https://ask.openstack.org/en/question/50379/neutron-serverservice-wont-start-at-os-boot-time/
また、図2のように、ブリッジbr-exに、物理NICが追加されていることを確認します。
[root@centos7 ~]# ovs-vsctl show
51655068-c399-4df6-995f-4a42d79b6fd7
Bridge br-ex
Port “enp6s0”
Interface “enp6s0”
Port br-ex
Interface br-ex
type: internal
qemuではなくKVMが設定されていることも確認しておきます。
# Libvirt domain type (valid options are: kvm, lxc, qemu, uml,
# xen) (string value)
#virt_type=kvm
virt_type=kvm
仮想ネットワークのセキュリティグループに、ICMPとSSHを許可
ここから先は下記公式ドキュメントを参考に、demoテナントで作業します。
https://openstack.redhat.com/Running_an_instance_with_Neutron
source /root/keystonerc_demo
neutron security-group-rule-create --protocol icmp --direction ingress default
neutron security-group-rule-create --protocol tcp --port-range-min 22 --port-range-max 22 --direction ingress default
なお、Adminテナントで上記を実行すると、下記のようなエラーがでます。
Multiple security_group matches found for name ‘default’, use an ID to be more specific.
defaultという名称のセキュリティグループが、adminテナント、demoテナント、serviceテナント分の３つあり、Adminアカウントだと全部が処理対象になって、名前指定だと一意に特定できないためのようです。
[root@centos7 ~(keystone_admin)]# neutron security-group-list
+———————————————————+————+——————+
| id | name | description |
+———————————————————+————+——————+
| 13a57a4e-a4f1-40ef-9195-f75f3bba161a | default | default |
| 9bf76c11-2f8f-4576-99e2-328de3ec3042 | default | default |
| d8121669-a665-41b3-bd6d-6235eade948e | default | default |
+———————————————————+————+——————+
セキュリティグループのIDを指定して設定すればよさそうですが、その方法がわかりませんでした。
SSHのキー作成＆インポート
SSHアクセスに使うキーを作成、登録します。1コマンドでできます。
nova keypair-add KEY_NAME_DEMO > MY_KEY_DEMO.pem && chmod 600 MY_KEY_DEMO.pem
CirrOSのインスタンスを作成
まずは手軽なCirrOSから作成して、動作確認します。
nova boot --flavor 1 --image cirros --key_name KEY_NAME_DEMO --security_group default --nic net-id=ce984965-c04a-423b-a666-8758bda8c971 cirros-01
net-idは下記コマンドで調べて、privateのものを使います。publicのものを最初から割り当てた方がラクのような気がしますが、demoテナントからでは設定できませんし、adminテナントでVM作って割り当てても、外には出られません。
neutron net-list
+--------------------------------------+---------+--------------------------------------------------+
| id | name | subnets |
+--------------------------------------+---------+--------------------------------------------------+
| ce984965-c04a-423b-a666-8758bda8c971 | private | c2f9bcd7-6bed-4378-943f-a7be786b3bf5 10.0.0.0/24 |
| b226c9e0-dbe5-4a8e-af06-d5b7416a13a6 | public | b5303cdc-d9d0-4e6e-bc89-30821246b86f |
+--------------------------------------+---------+--------------------------------------------------+
ブラウザでHorizonにdemoアカウントでログインします(パスワードは~/keystonerc_demoに記載されています）。作成したCirrOS-01のインスタンスの詳細を選択し、コンソールを開きます。ログインプロンプト画面に記載されているユーザ名、パスワードでログインし、適当に外部サイトにpingします。疎通できなかったら、下記を確認します。
- neutronのdhcpエージェントはまともに動いているか(dhcp)
- VMのeth0に、DHCPから割り当てられたIPアドレスが付与されているか
- ブリッジがまともに動いているか
- VMから10.0.0.1にpingし、router1にアクセスできるか。
- VMからGWの192.168.1.50にpingし、router1(gw側)にアクセスできるか。
- AllInOneノードから192.168.1.50にpingし、router1(gw側)にアクセスできるか。
- AllInOneノードでovs-vsctl showを実行し、qgXがbr-exに、qrXがbr-intにつながっているか
- neutronのdhcpエージェントはまともに動いているか(dns)
- VMの/etc/resolv.confは、サブネット作成時に指定したものか
- nslookupできるか
一度、neutron-serverが起動失敗したままVMを起動したら、おかしな状態になってしまい、neutron-serverを何回か再起動しても、router1に外部ネットからも、VMからもアクセスできなくなったときがありました。そのときはAllInOneノードをリブートしたら直りました。
なおCirrOSの操作は、Horizon経由でなくても下記のようにqrouterのnamespace経由で10.0.0.6のCirrOSにアクセスし、SSH接続して行うこともできます。
[root@centos7 ~(keystone_demo)]# ip netns
qrouter-96d6024d-2ad6-449f-b9bb-3d6c662c2b78
qdhcp-9ef70b7e-fdca-4792-8b2a-f7be3f47d3fb
[root@centos7 ~(keystone_demo)]# ip netns exec qrouter-96d6024d-2ad6-449f-b9bb-3d6c662c2b78 bash
[root@centos7 ~(keystone_demo)]# ssh -l cirros -i MY_KEY_DEMO.pem 10.0.0.6
floatipを付与し、物理マシンからSSH接続
作成したVMがsnatで外部ネットワークに繋げるようになることを確認したら、floatipを割り当てて、物理マシンからアクセスできようにします。Horizonから操作するとすぐできますが、コマンドによる方法も記載しておきます(分散ルータのDVRを試したときは、Horizonで操作するとポートが見つからなくて割当てできませんでしたが、コマンドからはできました)。
まずpublicネットワークからfloatipを払い出します。
source keystonerc_demo
neutron floatingip-create public
Created a new floatingip:
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| fixed_ip_address | |
| floating_ip_address | 192.168.1.51 |
| floating_network_id | b226c9e0-dbe5-4a8e-af06-d5b7416a13a6 |
| id | 42b954b9-d88a-4a32-95c3-ff7903cf22c4 |
| port_id | |
| router_id | |
| status | DOWN |
| tenant_id | 800e4a687e81412da3eb0712ed64cff8 |
+---------------------+--------------------------------------+
払い出されたfloatipのid 42b954b9-d88a-4a32-95c3-ff7903cf22c4 に、CirrOS-01のNICが接続している仮想L2スイッチのポートのidを関連づけます。
仮想L2スイッチのポートのリストを表示します。
neutron port-list
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------+
| id | name | mac_address | fixed_ips |
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------+
| 114cde45-34a7-4c4a-bc55-a6dd06f7a0f3 | | fa:16:3e:b2:ca:d9 | {"subnet_id": "c2f9bcd7-6bed-4378-943f-a7be786b3bf5", "ip_address": "10.0.0.4"} |
| 2714d4c8-5331-4498-88ed-124c7f6f5633 | | fa:16:3e:7d:84:51 | {"subnet_id": "c2f9bcd7-6bed-4378-943f-a7be786b3bf5", "ip_address": "10.0.0.1"} |
| 5b6e6d9e-61f2-48bf-afe6-fa46359a4d1c | | fa:16:3e:db:2f:fd | {"subnet_id": "c2f9bcd7-6bed-4378-943f-a7be786b3bf5", "ip_address": "10.0.0.6"} |
| 9e919cb8-b10e-420d-a5f6-7718c4a76ce2 | | fa:16:3e:64:31:71 | {"subnet_id": "c2f9bcd7-6bed-4378-943f-a7be786b3bf5", "ip_address": "10.0.0.3"} |
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------+
CirrOSのIPアドレスが"10.0.0.6"とすれば、ポートID 5b6e6d9e-61f2-48bf-afe6-fa46359a4d1c を、下記のようにfloatipに関連づけます。
neutron floatingip-associate 42b954b9-d88a-4a32-95c3-ff7903cf22c4 5b6e6d9e-61f2-48bf-afe6-fa46359a4d1c
外部ネットワークのマシンからpingして、反応が正常に帰ってきたら、秘密鍵を使ってSSHログインします。
ssh -l cirros -i MY_KEY_DEMO.pem 192.168.1.51
UbuntuのVM作成
イメージをダウンロードし、glanceに登録します。登録作業はadminアカウントで実行します。
wget http://cloud-images.ubuntu.com/releases/14.04/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img -P /var/kvm/images
source ~/keystonerc_admin
glance image-create --name="Ubuntu1404" --is-public=true --disk-format=qcow2 --container-format=bare < /var/kvm/images/ubuntu-14.04-server-cloudimg-amd64-disk1.img
上記イメージからVMを作成します。なお、フレーバにm1.tinyを指定してしまうと、ディスクサイズが足りなくてエラーになります。net-idは自環境のものを入力してください。
source ~/keystonerc_demo
nova boot --flavor 2 --image Ubuntu1404 --key_name KEY_NAME_DEMO --security_group default --nic net-id=ce984965-c04a-423b-a666-8758bda8c971 ubuntu-01
なお上記Ubuntuイメージは、CirrOSのイメージと違ってパスワードログインできないため、ブラウザのコンソールからはログインできません。コンソールログインするためには、VM作成時にrootパスワードを挿入する設定が必要です。
下記が参考になります。
http://docs.openstack.org/admin-guide-cloud/content/admin-password-injection.html
OPENSTACK_HYPERVISOR_FEATURE = {
...
‘can_set_password’: True,
}
...
...
[libvirt]
inject_password=true
...
必要があれば設定し、AllInOneノードをリブートして有効化します。
こうすると、HorizonからVMを作成する際、rootパスワードを設定できるようになります。(nova bootコマンドで指定できるかは分かりませんでした)
CirrOSと同じようにfloatipを割当て、sshで接続します。
ssh -l ubuntu -i MY_KEY_DEMO.pem 192.168.1.52
適当にpingなどをして、外に出れることを確認します。
その他
マルチノード構成も試してみました。概要だけ記載します。
Computeノードを追加
packstack の設定ファイルに、下記のように追加するComputeノードを追加して、再実行します。
CONFIG_COMPUTE_HOSTS=192.168.1.45,192.168.1.46
VM起動時、負荷の低いComputeノードでVMを起動できるようになります。追加したComputeノードがダウン中は、VMは別ノードで起動可能です。
Networkノードを追加
packstack の設定ファイルに、下記のように追加するNetworkノードを追加して、再実行します。
CONFIG_NETWORK_HOSTS=192.168.1.45,192.168.1.47
単にNetworkノードを追加しただけでは何も起きませんが、改めて仮想ルータを作成したときに、追加したNetworkノードで仮想ルータが動作するようになります。ただ、追加したNetworkノードがダウン中は、そこで動く仮想ルータは、別Networkノードでは動かせないようです。
複数のNetworkノードでVRRPを構成
仮想ルータを、複数のNetworkノードで冗長動作させます。追加Networkノードがダウン中でも、当該ルータは動作します。
下記がとても参考になりました。
http://www.slideshare.net/orimanabu/l3-ha-vrrp20141201
packstackでは自動的に設定することはできません。(少なくともJunoでは)
Networkノードへの負荷をDVRでComputeノードに分散する
ComputeノードとNetworkノードを切り離すと、VMの通信先によってはいちいちNetworkノードを介して通信することになるため、Networkノードに過剰な負荷がかかります。これを避けるため、Computeノードに仮想ルータの機能を分散し、Computeノード同士を直接通信させたり、Computeノードと外部LANを直結させたりして、通信負荷を分散できるようにします。
下記がとても参考になりました。
http://www.slideshare.net/ToruMakabe/20-openstack-neutron-deep-dive-dvr
packstackでは自動的に設定することはできません。(少なくともJunoでは)