Tech Sketch Bucket of Technical Chips by TIS Inc.

ネットワーク仮想化ソフトウェア MidoNet (2)

Pocket

前回の記事では、 MidoNetがSDNの中でどのような位置づけのプロダクトであり、何ができるものか、その上でOpenStackとどのように関わるのかを、順を追って紹介しました。 今回は、実際にMidoNetをインストールし、操作してみましょう。できることは沢山ありますが、基本となる仮想レイヤ2ネットワーク作成、およびその間のルーティングまでを試してみます。

前提

MidoNetのインストールに入る前に、今回の内容の前提を示します。

  • 前回の記事の最後で述べたとおり、今回はOpenStackとは連携せず、純粋にMidoNetだけを使って仮想ネットワークを構築してみます。
  • MidoNetは外部サービスと連携して認証・認可を行います。OpenStackには認証コンポーネント(Keystone)が存在し、MidoNetとOpenStackが連携する場合はKeystoneを利用することができますが、今回はOpenStackを利用しないため、MidoNetが持つテスト用のMockAuthService(模擬認証)を利用して認証・認可を行います。
  • Zookeeper自体やCassandra自体の詳細や設定は、それだけで長編記事になるほどボリュームがありますし、詳しく記載されたドキュメントが既に多数公開されているため、ここでは詳しく触れません。しかし、大規模データ処理の隆盛といった背景もあり分散処理を行うアーキテクチャが一般的になってきた現在、こういった分散コーディネーションサービスや分散データストアはますます重要性を増していますので、公式ドキュメント(ZookeeperCassandra)や他の詳解記事に一度は目を通しておいて損はありません。
  • MidoNetは、仮想ネットワーク構成情報を保持するNetwork State Database(NSDB)や、外部ネットワークとの通信を担うGateway Nodeにクラスタ構成をとることで可用性を向上させることができますが、今回は手軽に試すことができるよう、台数を少なくして試します。実際に利用する際は可用性などを考慮して構成すると良いでしょう。
  • 通常、MidoNetのコンポーネント間が通信する管理ネットワークと、ハイパーバイザホスト上のVM同士が通信するためのユーザネットワークは物理的に分けて構成しますが、今回は簡略化のため、1つだけで実施しています。そのため、実際に複数ネットワークで構成する場合は、MidoNetのtunnel zoneのメンバーには、ハイパーバイザホストのユーザネットワーク側のIPアドレスを指定します。

ホストの環境構成

NSDB兼APIサーバ用ホストを1台、ハイパーバイザホストを2台準備し、ハイパーバイザホスト上に構築したVMを同一の仮想レイヤ2ネットワークに所属させたり、仮想レイヤ2ネットワークの間をルーティングする構成にしてみます。 また、ハイパーバイザにはKVMを利用することにします。

それぞれのホストの詳細は以下のとおりとします。

ホスト 用途 OS メモリ IP
nsdb NSDB兼APIサーバ用ホスト CentOS7 4GB 10.108.123.195
compute1 ハイパーバイザホスト1 CentOS7 4GB 10.108.123.201
compute2 ハイパーバイザホスト2 CentOS7 4GB 10.108.123.207

インストールされるソフトウェアと役割

今回それぞれのホストにインストールされるソフトウェアとバージョン(執筆時点)、およびその役割を示します。

ホスト ソフトウェア バージョン 目的
nsdb Apache Zookeeper 3.4.5 仮想ネットワーク構成情報を保存
Apache Cassandra 2.0.16 NATなど一時的なネットワーク情報を保存
Apache Tomcat 7.0.54 midonet-apiを動作させるアプリケーションサーバ
midonet-api 2015.06.1 NSDBにネットワーク構成情報を設定
python-midonet-client 2015.06.1 midonet-apiのCLIクライアント
compute1 midolman 2015.06.1 VMのパケットをコントロールするエージェント
compute2
共通 OpenJDK 1.7.0.85 javaランタイム


上記のインストールを完了し、それぞれのハイパーバイザホストでVMを起動した直後の状態では、以下のような構成となります。まずはここを目指しましょう。

インストール直後の状態

事前準備

SELinux、iptablesの無効化

Redhat Enterprise LinuxやCentOSでは、ホストのセキュリティ強化のための機能であるSELinuxが初期状態で有効になっています。また、Linuxには一般的にファイアウォールとしてiptables(netfilter)が存在します。 本来これらを適切に利用すべきですが、MidoNetをまず試してみる場合は、これら無効にしておくとトラブルが少なくて済みますので、今回は無効化しておきます。 セキュリティレベルが低下しますので、外部から接続できないネットワークで試す事をお勧めします。

恒久的に無効化する場合は、/etc/sysconfig/selinuxを下記のように編集し、サーバを再起動します。

次に、ファイアウォールを停止します。

こちらも恒久的に無効化する場合は、以下のコマンドを実行します。

インストール

それでは、MidoNetをインストールしてみましょう。インストールは、以下の手順で行っていきます。

  1. NSDB兼APIサーバホスト
    1. yumリポジトリの設定
    2. OpenJDK 1.7のインストール
    3. Apache Zookeeperのインストールと設定
    4. Apache Cassandraのインストールと設定
    5. midonet-apiのインストールと設定
    6. Apache Tomcatのインストールと設定
    7. midonet-api webアプリケーションの設定
    8. python-midonet-clientのインストールと設定
  2. ハイパーバイザホスト1、2
    1. yumリポジトリの設定
    2. OpenJDK 1.7のインストール
    3. midolmanのインストールと設定

沢山手順があるように見えますが、パッケージで配布されているものを利用でき、実際はyumでインストールして少し設定ファイルを編集するだけですので、さほど時間は掛かりません。 ソースコードからビルドする場合は、それなりに性能のあるマシンと、ある程度時間が必要です。

NSDB兼APIサーバ用ホストのインストール

最初に、NSDBとAPIサーバを準備します。

Apache Cassandra用 yumリポジトリの設定

Apache Cassandraのインストールを行うためのリポジトリを設定します。

MidoNet用 yumリポジトリの設定

midonet-api、 python-midonet-clientのインストールを行うためのリポジトリを設定します。

yum update

リポジトリ設定後、更新を行います。

OpenJDK 1.7のインストール

記事執筆時点では、MidoNetはjava7で動作させる形となっており、java8への移行は現在進行中のようです。このため、OpenJDK 1.7をインストールします。

Apache Zookeeperのインストール

NSDB用にApache Zookeeperをインストールします。

インストールが完了したら、zookeeperの設定ファイルにZooKeeperアンサンブル(クラスタ)の設定を追記します。今回はこの1台のみでNSDBを構築しますが、複数ある場合はここにserver.*の形で複数記述します。

また、zookeeperが永続データを保存するdataディレクトリを作成しておきます。

最後に、サーバの識別子を設定します。今回はこの1台のみでNSDBを構築しますが、複数ある場合はここが2、3、…となります。

編集が終わったら、zookeeperを有効にし、起動します。

ここまで完了したら、zookeeperが正しく起動したか確認してみましょう。

最後の行を実行した結果、imok と表示されれば正常動作しています。

Apache Cassandraのインストール

NSDB用にApache Cassandraをインストールします。この手順で利用するcassandraのバージョンは、記事執筆時点で2.0(最近は2.2)です。

インストールが完了したら、設定ファイルを編集します。listen_address、rpc_address、seedsにホストのIPアドレスを設定します。 今回はこの1台のみでNSDBを構築しますが、複数ある場合はseedsにカンマ区切りで複数のIPアドレスを指定します。

編集が終わったら、cassandraを有効にし、起動します。 systemctl enableで警告が出ますが、これはcassandraがsystemdに完全に対応していないためであり、この処理はchkconfigにリダイレクトされるため、問題はありません。

ここまで完了したら、cassandraがが正しく起動したか確認してみましょう。

cassandra-cliで上記のように接続できれば、正しく起動しています。 なお、この手順ではcassandra2.0でNSDBを構成する形になっていますが、記事執筆時点での最新安定版は2.1.9です。 cassandraのバージョンが2.2系以上になるとコマンド体系も変更になるため、今後対応バージョンの変更があった場合は注意が必要です。

留意点

Cassandraをインストールした際に/var/run/cassandraが作成されますが、/varをtmpfsにしている場合、サーバを再起動するとこのディレクトリは消えてしまいますので、その場合は起動スクリプトにディレクトリを再作成する処理を追加しておきます。

midonet-apiのインストールと設定

NSDBに仮想ネットワーク情報を設定するため、midonet-apiをインストールします。

Apache Tomcatのインストール

midonet-apiはjavaサーバサイドアプリケーションですので、これを動作させるためのServlet ContainerとしてApache Tomcatをインストールします。 なお、この手順で利用するtomcatのバージョンは、記事執筆時点で7です。

tomcatのインストール後、コンテキスト設定ファイルを編集し、後述でインストールするmidonet-apiアプリケーションが動作するよう設定します。

これでtomcatの設定は完了です。

midonet-apiのインストール

上記で設定したtomcat上で動作させるmidonet-apiをインストールします。

インストール後、web.xmlを編集します。rest_api-base_uriには自ホストのIPアドレスとPortを指定します。 zookeeper-zookeeper_hostsにはNSDBのホストを設定しますが、今回は1台のため、そのIPアドレスとPortを設定します。 また、midobrain-properties_fileのパラメータを追記します。

最後に、認証・認可サービスのプロバイダを設定します。 冒頭で述べた通り、今回は外部の認証・認可サービスでなく、MockAuthServiceを利用することにします。

編集完了後、midonet-apiを有効化し、起動します。

ここまで完了したら、midonet-apiが正しく起動したか確認してみましょう。

curlでREST APIを実行した結果、上記のようなjsonデータが返却されていれば、正しく動作しています。

python-midonetclientのインストールと設定

midonet-apiをコマンドラインから実行できるpython-midonetclientをインストールします。

epelの有効化

python-midonetclientのインストールにはpython-httplib2とpython-eventletが必要であり、この依存関係の解決にはepelが必要であるため、epelを有効にします。

python-midonetclientのインストール

python-midonetclientをインストールします。

インストール完了後、python-midonetclientが読み込む、認証情報などを含んだ設定ファイルを編集します。

ここまで完了したら、python-midonetclientが正しく起動するかを確認してみましょう。コマンドは midonet-cli です。

上記のプロンプトが表示されれば、正しく起動しています。

留意点

MidoNetの認可はroleに基づいて行われます。roleにはauth-admin_role、auth-tenant_admin_role、auth-tenant_user_roleが存在し、 それぞれ以下のように定義されています。

role 権限
auth-admin_role 全ての操作が可能
auth-tenant_admin_role テナントとして指定された識別子に紐づく情報に対し読み書き可能
auth-tenant_user_role テナントとして指定された識別子に紐づく情報に対し読み取り可能


冒頭で説明したとおり、今回はMockAuthServiceを利用して模擬的な認証・認可を行いますが、 MockAuthServiceでは、認可に関して指定したトークンが送られた場合にどのroleとして振る舞うかを事前に定義しておくことができます。

midonet-cliからは模擬トークンの利用が確認できなかったため、curlからmidonet-apiを利用して、各roleのトークンを使った仮想ブリッジの作成ができるかを試してみます。

adminのroleでは仮想bridgeが作成でき、tenant_userでは作成できないことがわかります。

また、MidoNetはテナントの作成および削除を行う機能を持ちませんが、外部で管理されているテナントID(文字列)を、構成情報作成時に付与したり、検索時にフィルタリングしたりする機能を持っています。 例えば、midonet-cliの起動時に--tenantで文字列を指定するか、.midonetrcにtenantを定義するか、midonet-cliでsettコマンドを実行すると、その時のbridge作成などの操作結果は他の文字列を指定して起動した状態からは見えません。また、初期状態は指定なしで、全てのテナントのリソースが見えるようです。

MidoNetの認証、認可については、こちらの公式ドキュメントが参考になります。

ハイパーバイザホスト1、2の設定

NSDBのインストールが完了したら、ハイパーバイザホストを設定していきます。 この手順は、全てのハイパーバイザホストで共通です。 なお、これらのホストでは予めVMが稼働できる状態であるとします。

MidoNet用 yumリポジトリの設定

MidoNetのインストールを行うためのリポジトリを設定します。 設定内容はNSDB兼APIサーバと同様です。

yum update

設定内容はNSDB兼APIサーバと同様です。

OpenJDK 1.7のインストール

OpenJDK 1.7をインストールします。 設定内容はNSDB兼APIサーバと同様です。

midolmanのインストールと設定

各ホストにmidolmanをインストールします。

次に、midolmanの設定ファイルを環境に合わせ修正します。 zookeeperセクションのzookeeper_hostsにNSDBのIPアドレスとPort、 cassandraセクションのserversにNSDBのIPアドレス、およびclusterに先ほどNSDB側で設定したクラスタ名(midonet)を設定します。 今回はNSDBのホストが1台で構築されていますが、複数ある場合はzookeeper_hostsやserversにカンマ区切りでIPアドレスを複数記述します。 また、cassandraについては幾つのノードにデータをレプリケーションしておくかを示すreplication_factorも適切に設定して下さい。

編集完了後、midolmanを有効化し、起動します。

ここまで完了したら、midolmanが正しく起動したか確認してみましょう。この時点で、midonet datapathが作成されているはずです。

この状態になっていれば、midolmanが正しく起動しています。

留意点

midolmanが起動しない、幾つか要因が考えられますが、例えば以下の点を確認してみて下さい。

  • midolmanのバージョンが異なるハイパーバイザホストを、同一NSDBに繋ぐ形で起動した

異なるバージョンのmidolmanが既にNSDBに認識されている状況では、別バージョンのmidolmanは起動に失敗します。/var/log/midonet/midolman.logにバージョンに関するエラーが出ている場合は、バージョンを合わせて下さい。

  • NSDBでcassandraがダウンしている

NSDBはメモリの消費量が比較的多いため、cassandraがいつの間にかOut of memoryでダウンしてしまった可能性があります。/var/log/midonet/midolman.logに接続エラーに関するエラーが出ている場合は、cassandraが起動しているか確認し、ダウンしている場合はNSDBのメモリを多めに確保しましょう。

仮想レイヤ2ネットワークの作成と動作確認

インストールが完了したら、実際にVMをハイパーバイザホストでVMを起動し、仮想レイヤ2ネットワークを作成して接続してみましょう。 最初の例で実施する手順は、以下のとおりです。

  • ハイパーバイザホスト1、2
    1. VMの起動
  • NSDB兼APIサーバホスト
    1. tunnel zoneの作成
    2. MidoNetにハイパーバイザホストを登録
    3. 仮想bridgeの作成
    4. 仮想bridgeにportを作成
    5. 仮想bridgeに作成したportにに物理interfaceをマッピング

なお、今回は1ユーザのみ、かつ管理者roleでの利用とし、テナントは固定であるとします。

VMの構成と、VMの起動

今回は、VMを以下のように構築するとします。 各VMはsshで操作する為のネットワーク(virbr0)に繋がるinterface(vnet0)と、MidoNetで利用する仮想ネットワーク(virbr1)に繋がるのinterface(vnet1)を持ちますが、前者は接続できれば何でも良いため、記述は省略します。 下記の表で示す仮想ネットワーク上のIPアドレスは、ハイパーバイザホストのvnet1に繋がるinterface(vm1-1、vm2-1のeth1)に付与するIPアドレスです。

VM 起動するハイパーバイザホスト OS CPUコア数 メモリ 所属する仮想bridge 仮想ネットワーク上のIP
vm1-1 compute1 Ubuntu14.04 1 1GB bridge0 192.168.0.100/24
vm2-1 compute2 Ubuntu14.04 1 1GB bridge0 192.168.0.101/24


最初の方にも示しましたが、ここまでで以下のような環境になっています。 インストール直後の状態

仮想ネットワーク設定

ここから、vm1-1とvm2-1が繋ぐMidoNetの仮想ネットワークを作成していきます。

tunnel zoneの作成

MidoNetは離れたハイパーバイザホスト上のインタフェースとはflow-based tunnelingによって通信しますが、トンネルの終端があるホストであればどことでも通信できてしまうため、認識しているホストとのみ通信する仕組みがあります。この機構がtunnel zoneです。

まず最初にtunnel zoneを作成します。作成するトンネルのタイプをgre、vxlanのどちらかから選ぶ事ができますが、今回はvxlanでトンネリングを行うようにしてみましょう。

留意点

midonet-cliの動作にはいくつかポイントがありますので、コマンドを打っていく際に引っかかった時は参考にしてみて下さい。

  • midonet-cliを一度終了すると、host0やhost1といったエイリアスが変更されることがある

これは、midonet-cliがNSDBから情報を取得した際にこの値を付与している為のようです。毎回list系のコマンドを打ち、操作対象のエイリアスが何を指しているかを確認するか、-e(Evaluate)オプションを付与し非対話型で利用すると良いようです。

  • midonet-cliにて、正しいコマンドを入力しているにも関わらず、Syntax errorメッセージが発生することがある

上記と同じ理由によるものと考えられますが、例えば一度midonet-cliを終了した後、もう一度起動してlist hostを行う前にhost host0 ... といったコマンドを実行した場合です。この時は、一度list hostを行うと正しく動作するようになります。

tunnel zoneにハイパーバイザホスト(midolmanが起動しているホスト)を登録

tunnel zoneを作成したら、そこにMidoNetでネットワークを制御するハイパーバイザホストを登録します。

まずは、どのハイパーバイザホストがMidoNetで制御できるかを確認しましょう。ここには、NSDBと繋がるmidolmanが存在するホストが表示されます。

ハイパーバイザホスト1,2がリストに表示されることが確認できます。次に各ハイパーバイザホストのinterfaceを確認してみます。

これらのうち、VMのinterfaceと繋がるものをMidoNetの管理下に置くことで、パケットをコントロールします。今回の例では、vnet1がVMのeth1と繋がる形になっています。 それでは、tunnel zoneに参加できるハイパーバイザホストを登録してみます。

これで、tzone0に、host0とhost1が登録されました。

仮想bridgeの作成

VMが接続する仮想的なbridgeを作成してみます。 SDNやSDIを扱っている方には説明するまでもない話かもしれませんが、 実際にbridgeの機能を持ったノードが構築されたりするわけではなく、このようなbridgeが実際に存在するかのようにmidolmanがパケットの送信元や送信先などを制御する、ということです。

これで、仮想bridgeが作成されました。この段階ではまだ、どのinterfaceから出たパケットがこのbridgeに流れるかが定義されていません。それは、この後で行います。

仮想bridgeにportを作成

次に、作った仮想bridgeにportを作成します。

仮想bridgeにportが作成されました。

作成したportに実際のインタフェースをbind

仮想的なportがどのVMのportに該当するのかを定義します。ここで初めて、今まで作成した仮想的なネットワーク装置と物理的なinterfaceをマッピングすることになります。 つまり、vm1-1のinterfaceと、vm2-1のinterfaceの2つをマッピングすれば、その時点で2つのVMが仮想スイッチに接続されていることになり、お互い通信可能になります。

仮想bridge0のport0にvm1-1のeth1(ハイパーバイザホスト1のvnet1)、port1にvm2-1のeth1(ハイパーバイザホスト2のvnet1)をそれぞれマッピングしました。

vnet1がmidonet datapathに追加されているのを確認

ここまでの操作を行うと、ハイパーバイザホストのmidonet datapathにvnet1が追加されます。つまり、vnet1はMidoNetの制御下に入ったということです。

ここまでの操作で、以下のような仮想ネットワークが設定されました。

仮想ネットワーク構成

留意点

libvirtでVMを起動した場合、NATやhostonlyのネットワークを指定したinterfaceは、ハイパーバイザホストのLinux bridgeなどに追加されているのが一般的ですが、この場合、midolmanがmidonet datapathにこのinterfaceを追加することができず、MidoNetの制御下に入りません。

今回は手動で行うため、イレギュラーですが、Linux bridgeから該当interfaceを外しておきます。

この状態でmidonet-cliからadd bindingするとログファイルに以下のメッセージが表示され、mm-dpctl --show-dp midonetを実行してもvnet1は表示されません。

これを回避するため、Linux bridgeからvnet1を削除します。

既にadd bindingしてある場合は、Linux bridgeからvnet1を削除すると、自動的にMidoNetの制御下に入ります。

疎通確認

VM間の疎通確認の前に、VMのIPアドレスとrouting tableを確認しておきましょう。

それでは、片方のVMから他方のVMに接続できるか試してみましょう。

問題なく接続できる事が確認できました。 この時、midonet datapathのパケット入出力を確認すると、tnvxlan-overlay interfaceのパケット数が増加していることがわかります。

tcpdumpで、実際にどのようなパケットが出ているか見てみましょう。 tunnel zoneにVXLANを設定しましたので、VXLANのパケットが流れているかを確認してみます。

VXLANのパケットで相手ホストと通信しているのがわかります。 また、今回は試していませんが、前回の記事で紹介したように、MidoNetはいくつハイパーバイザホストがあってもトンネル用のportは1つであり、ホスト数分増加することはありません。

複数のサブネットとルーティング

次は仮想ルータを作成し、2つのサブネットをルーティングしてみます。 先ほどの環境のハイパーバイザホストに1台ずつVMを追加し、以下の構成としてみます。

VM ハイパーバイザホスト OS CPUコア数 メモリ 所属する仮想bridge 仮想ネットワーク上のIP
vm1-1 compute1 Ubuntu14.04 1 1GB bridge0 192.168.0.100/24
vm1-2 compute1 Ubuntu14.04 1 1GB bridge1 192.168.1.100/24
vm2-1 compute2 Ubuntu14.04 1 1GB bridge0 192.168.0.101/24
vm2-2 compute2 Ubuntu14.04 1 1GB bridge1 192.168.1.101/24


VMのinterfaceと、ハイパーバイザホストのinterfaceは以下のような対応であるとします。

VMのinterface ハイパーバイザホストのinterface
vm1-1のeth1 vnet1
vm1-2のeth1 vnet3
vm2-1のeth1 vnet1
vm2-2のeth1 vnet3


図にすると、以下のようになります。先ほどまでの環境はそのままで、それぞれVMが1台ずつ追加されています。

l2_2origin

仮想ネットワーク作成と動作確認(2)

今回の例で実施する手順は、以下のとおりです。

  • ハイパーバイザホスト1、2
    1. 新たにVMを起動
  • NSDB兼APIサーバホスト
    1. 仮想bridgeを新たに作成
    2. 新たに作成した仮想bridgeにportを作成
    3. 仮想bridgeに作成したportにに物理interfaceをマッピング
    4. 仮想routerの作成
    5. 仮想routerにportを作成
    6. 仮想routerのportと仮想bridgeのportを接続
    7. 仮想routerに、パケットが2つのサブネットを相互に行き来できるためのrouteエントリを追加

仮想ネットワーク設定

新たに起動したvm1-2とvm2-2が繋ぐMidoNetの仮想ネットワークを作成していきます。 まず、ハイパーバイザホスト側のinterfaceを確認します。

今回は、vnet3が新たに作成したVMのinterfaceです。

仮想bridgeの作成

vm1-2、vm2-2が接続する仮想bridgeを新たに作成します。

新たに仮想bridgeが作成されました。

仮想bridgeにportを作成

新たに作成した仮想bridgeにportを作成します。

仮想bridgeにportが作成されました。

作成したportに実際のインタフェースをbind

最初の例と同様、仮想bridgeにportを2つ作成し、vm1-2、vm2-2のinterfaceとマッピングします。

ここまでの操作で、以下のような仮想ネットワークが設定されました。

l2_2

疎通確認

vm1-1とvm2-1は接続可能なままで、また、今回設定したvm1-2とvm2-2の間も通信できるようになっていますので、確認してみましょう。

それぞれの組み合わせで接続できることが確認できました。

サブネット間のルーティング

次に、ここまでで作成した2つのbridgeを仮想routerで接続し、相互に行き来できるようにしてみましょう。

仮想routerの作成

まずは、仮想routerを作成します。これも仮想bridge同様、実際にrouterの機能を持ったノードが構築されるのではなく、 このようなrouterが実際に存在するかのようにmidolmanがパケットを制御することを指します。

仮想routerにportを作成

作成した仮想routerにportを作成します。このportは、それぞれの仮想ネットワークのgatewayになるportです。

仮想routerと仮想bridgeを接続

前の例で作成した2つの仮想bridgeにrouterとつながるportを追加し、その間を接続します。 まずは、bridgeにportを追加します。

このportと、routerのportを接続します。

仮想routerにrouteエントリを追加

最後に、routerにrouteエントリを追加して、お互いのネットワークのパケットがルーティングされるよう設定します。

ここまででMidoNetの設定は完了です。以下のような仮想ネットワークが構成されました。

l3

疎通確認

これから疎通確認を行いますが、VM側のrouting tableには、今作成したgatewayが設定されているとします。

それでは、vm1-1から異なるホスト上、かつ異なる仮想ネットワークに存在するvm2-2へ接続を行ってみましょう。

問題なく接続できることが確認できました。

参考資料

今回インストールで参考とした資料はQuick Start Guideで、ここからOpenStackに関するインストールを除いたものです。

また、インストール後に実施した内容は、Operations Guideに概ね記載されています。この他の機能や操作については、そちらを参考にすると良いでしょう。

なお、各ドキュメントは現在日本語化が進められているようで、今後のリリースで日本語訳ドキュメントが付くと考えられ、 より利用の敷居を下げてくれそうです。

終わりに

今回はMidoNetのインストールから始まり、基本的な仮想ネットワークの操作を試してみました。 インストールは比較的容易で、ノードに対し複雑な操作をすることなく、コマンドやAPIから簡単にネットワークを操作できたのではないかと思います。

ところで、今回はパケット操作の対象となったVMの設定を人手で行う場所がいくつかありました。 VMの構築などもコントロールする場合、手作業ではVMの設定(xml)を変更したりと、様々なオペレーションが発生します。 これを全て一元的に管理する選択肢としては、自前でクラウドコントローラを構築するなどのほか、クラウドOSを活用するといったものが考えられ、 その1つがOpenStackです。今回手動で行ったような事を、ユーザが望んだタイミングで、ユーザ自身が画面から容易に、あるいはAPIでプログラムから実行することができます。

もちろん、様々なリソースを柔軟にコントロールできるOpenStackは、それだけに運用に必要な知識や知見の幅が広く、 バージョンも半年毎に上がり、仕様の変更や機能追加も活発に行われています。そのため、プロダクションでうまく活用するのは、高いスキルと、覚悟が必要とされると言われています。 そういった状況でも自前で運用できる、高い技術力をもった企業もありますし、ベンダのディストリビューションなどを活用し、サポートを受けながらうまく運用する企業もあります。

このように、OpenStack界隈は非常に活発で、情報がすぐに古くなってしまいますが、根本的なところや考え方はさほど変わっていません。 本blogでもOpenStackに関する記事を何度か扱っていますので、参考にして頂ければ幸いです。

また、MidoNetとOpenStackを合わせて試す場合、MidoStackを利用して、環境一式を構築することができるようですので、こちらを利用してみても良いでしょう。

エンジニア採用中!私たちと一緒に働いてみませんか?