OpenStack は高度なネットワーク環境を提供します。本章では、クラウドを設計するときに考慮すべき要件と選択肢について詳細に説明します。
これがあなたの組織で初めてのクラウド基盤構築であれば、この章を読んだ後、最初にあなたの（組織の）ネットワーク管理チームと相談すべきです。クラウド運用におけるネットワークの使用は伝統的なネットワーク構築とはかなり異なり、接続性とポリシーレベルの両面で破壊的な結果をもたらす可能性があるからです。
例えば、管理インフラだけでなくゲストインスタンス用のIPアドレスの数も計画しなければなりません。加えて、プロキシサーバーやファイアウォールを経由してのクラウドネットワークの接続性を調査・議論する必要があります。
管理ネットワークを用意するのはお薦めの選択肢です。通常、管理ネットワークは専用のスイッチと NIC で構成します。ネットワークを分離することで、システム管理と監視システムアクセスが、ゲスト自身が生成するトラフィックによって邪魔されることがなくなります。
メッセージキューや OpenStack Compute といった OpenStack 内部のコンポーネント間の通信用に別のプライベートネットワークを作成することを検討して下さい。 VLAN はこれらのシナリオに非常に適しています。
ゲストの仮想マシン用の IP アドレスは、固定 IP とフローティング IP の2種類に大別できます。固定 IP はインスタンス起動時にインスタンスに割り当てられ、フローティング IP はユーザ操作によりインスタンスへの割り当てを変更できます。どちらのタイプの IP アドレスについても、パブリックアドレス、プライベートアドレスのいずれかをあなたの用途に合わせて選択することができます。
固定 IP アドレスは必須ですが、フローティング IP はなくても OpenStack を実行することができます。フローティング IP の最も一般的な用途の１つは、利用可能なIPアドレス数が限られているプライベートクラウドでパブリックIPアドレスを利用できるようにすることです。他の用途としては、パブリッククラウドのユーザが、インスタンスがアップグレードや移動した際でも割り当て直すことができる「静的」 IP アドレスを利用できるようにすることです。
固定IPアドレスは、プライベートクラウドではプライベートアドレスに、パブリッククラウドではパブリックアドレスにすることが出来ます。インスタンスが削除される際、そのインスタンスの固定IPは割当を解除されます。IPアドレスが使い終わったらすぐに解放されてしまうという動作に、クラウドコンピューティングの初心者がストレスを感じる可能性があることに注意しましょう。
OpenStack のインストールでは、潜在的に、多数のサブネットと、サブネット毎に異なる種類のサービスが存在する可能性があります。IPアドレス計画は、ネットワーク分割の目的とスケーラビリティに関する理解を共有するのに役立ちます。コントロールサービスはパブリックIPアドレスとプライベートIPアドレスを持つ場合があり、上記の通り、インスタンスのパブリックIPアドレスには2種類のオプションが存在します。
IPアドレス計画は以下のセクションに分類できるでしょう。
サブネットルータ |
このサブネットから出て行くパケットはこのアドレスを経由して出て行きます。このアドレスは、専用ルータにすることも、nova-network サービスにすることもできます。 |
コントロールサービスのパブリックインターフェース |
|
Object Storage クラスタ内の通信 |
object/account/container サーバー間、またはこれらのサーバーとプロキシサーバーの内側のインターフェースとの間の通信は、このプライベートネットワークを使用します。 |
コンピュートとストレージ間の通信 |
一時ディスクまたはブロックストレージがコンピュートノード以外にある場合、このネットワークが使用されます。 |
アウトバンドのリモート管理 |
専用のリモートアクセスコントローラーチップがサーバーに搭載されている場合、多くの場合、これらは独立したネットワーク上に置かれます。 |
インバンドのリモート管理 |
多くの場合、システム管理者や監視ツールからホストへのアクセスは、パブリックインタフェース経由ではなく、コンピュートノード、ストレージノードの (1Gbps などの) 追加のインタフェース経由で行われます。 |
将来の拡張用の予備のアドレス空間 |
パブリック側に置かれる制御サービスやゲストインスタンスのIPの追加は、必ずアドレス計画の一部として入れておくべきです。 |
例えば、OpenStack Compute と Object Storage の両方を使用し、プライベートアドレス範囲として 172.22.42.0/24 と 172.22.87.0/26 が利用できる場面を考えます。一例として、アドレス空間を以下のように分割することができます。
172.22.42.0/24 172.22.42.1 - 172.22.42.3 - subnet routers 172.22.42.4 - 172.22.42.20 - spare for networks 172.22.42.21 - 172.22.42.104 - Compute node remote access controllers (inc spare) 172.22.42.105 - 172.22.42.188 - Compute node management interfaces (inc spare) 172.22.42.189 - 172.22.42.208 - Swift proxy remote access controllers (inc spare) 172.22.42.209 - 172.22.42.228 - Swift proxy management interfaces (inc spare) 172.22.42.229 - 172.22.42.252 - Swift storage servers remote access controllers (inc spare) 172.22.42.253 - 172.22.42.254 - spare 172.22.87.0/26: 172.22.87.1 - 172.22.87.3 - subnet routers 172.22.87.4 - 172.22.87.24 - Swift proxy server internal interfaces (inc spare) 172.22.87.25 - 172.22.87.63 - Swift object server internal interfaces (inc spare)
パブリックIPアドレスの場合でも同様のアプローチが取れます。但し、ゲストインスタンス用のIPとして使用する場合には、大きなフラットなアドレスレンジの方が好まれることに注意した方がよいでしょう。また、OpenStack のネットワーク方式によっては、ゲストインスタンス用のパブリックIPアドレスレンジのうち一つが nova-compute ホストに割り当てられることも考慮する必要があります。
OpenStack Compute では、数種類のネットワークマネージャーが用意されており、それぞれ長所と短所があります。どのネットワークマネージャーを選択するかは利用するネットワークトポロジーにより変わります。そのため、慎重に選択する必要があります。
| 種別 | 長所 | 短所 |
|---|---|---|
Flat |
極めてシンプル。 DHCP ブロードキャストなし。 |
インスタンスに対するファイルインジェクションが必須。 特定の Linux ディストリビューションしか利用できない。 設定の難易度は高く、非推奨。 |
FlatDHCP |
比較的シンプルな構成。 標準的なネットワーク。 すべてのオペレーティングシステムが利用できる。 |
専用の DHCP ブロードキャストドメインが必要。 |
VlanManager |
各テナントが専用の VLAN で分離される。 |
少し複雑な構成。 専用の DHCP ブロードキャストドメインが必要。 一つのポートに多数の VLAN をトランクが必要。 標準的な VLAN 数の上限。 802.1q VLAN タギングに対応したスイッチが必要。 |
FlatDHCP Multi-host HA |
ネットワーク障害が影響を受けるハイパーバイザー上の VM に限定される。 DHCP トラフィックは個々のホスト内に閉じ込めることができる。 ネットワークトラフィックをコンピュートノード全体に分散できる。 |
少し複雑な構成。 デフォルトでは、各コンピュートノードにパブリック IP アドレスが必要となる。 ライブマイグレーションでネットワークが動作するようにするためは、オプションを慎重に設定する必要がある。 |
VLAN 設定は要求に応じて単純にも複雑にもなり得ます。 VLAN を使用すると、各プロジェクトのサブネットとブロードキャストを他のプロジェクトから分離できるというメリットがあります。 OpenStack が VLAN を効率的に利用できるようにするには、ある範囲の VLAN (1プロジェクト 1VLAN) を割り当て、各コンピュートノードのスイッチポートをトランクポートに設定する必要があります。
例えば、あなたのクラウドでサポートする必要があるプロジェクト数が最大で100と見込まれる場合、ネットワークインフラで現在使用されていない VLAN の範囲を選んで下さい (例えば VLAN 200 - 299)。この VLAN の範囲を OpenStack に設定するとともに、この範囲の VLAN トラフィックを許可するようにスイッチポートを設定しなければいけません。
OpenStack Compute には、一つのインスタンス複数の NIC を割り当てる機能があり、プロジェクト単位に制御できます。一般的には、これは高度な機能で、普段から必要になるものではありません。また、この機能をリクエスト単位で使うことも簡単にできます。しかしながら、2つ目のNICを使うと、サブネット、つまり VLAN が一つまるごと必要になる点に注意して下さい。これにより、全体で収容できるプロジェクト数が一つ減ることになるからです。
nova-network は、マルチホストモードでもシングルホストモードでも動作させることができます。マルチホストモードでは、各コンピュートノードで nova-network サービスを動作させ、コンピュートノード上のインスタンスはそのコンピュートノードをインターネットへのゲートウェイとして使用します。コンピュートノードはそのノード上のインスタンスに対してフローティングIPとセキュリティグループ機能も提供します。シングルホストモードでは、1台の中央のサーバー（例えば、クラウドコントローラー）で nova-network を動かします。全コンピュートノードがインスタンスからのトラフィックをクラウドコントローラーに転送し、クラウドコントローラーはトラフィックをインターネットに転送します。クラウドコントローラーは、クラウド上の全インスタンスに対してフローティングIPとセキュリティグループ機能を提供します。
どちらのモードにもメリットがあります。シングルホストモードには、単一障害点というマイナス面があります。クラウドコントローラーが利用できなくなると、インスタンスはネットワークと通信できなくなります。マルチホストモードでは、この状況にはなりませんが、各コンピュートノードはインターネットと通信するためのパブリックIPアドレスが必要となります。十分な大きさのパブリックIPアドレスブロックを取得できない場合には、マルチホストモードは選択肢にならないかもしれません。
OpenStack も、他のネットワークアプリケーション同様、 DNS や NTP など標準的に考慮すべき点が多くあります。
時刻同期は OpenStack のコンポーネントの継続的な動作を保証するためには不可欠な項目です。正しい時刻は、インスタンスのスケジューリング、オブジェクトストアでのオブジェクト複製や、デバッグ時のログのタイムスタンプの突き合わせなどでのエラーを避けるために必要です。
OpenStack のコンポーネントが動作している全てのサーバーから適切な NTP サーバにアクセスできるようにすべきです。 NTP サーバーは自分で用意するか、 http://www.pool.ntp.org/ に載っている公開 NTPサーバーを使うこともできます。
