本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のProgram ManagerのKate Guillemette 氏とStaff Solutions ArchitectのJason Burns氏によるものです。原文を参照したい方はWhat’s New in AHV Networking - Part 2をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。
このブログのシリーズはNutanix .NEXTでアナウンスされたAHVのワンクリックネットワーク、優れた可視化、自動化、そしてセキュリティを実現する機能を取り上げます。
パート 1: AHV ネットワーク 可視化
パート 2: AHV ネットワーク 自動化と統合
パート 3: AHV ネットワーク マイクロセグメンテーション
パート 4: AHV ネットワーク ファンクションチェイン
AHV ネットワーク 自動化と統合
前回の記事ではネットワークの可視化によって、どのようなアプリケーション間の接続とトラフィックフローの知見が得られるかということを見てきました。トラフィックフローと接続を見る前に、我々はまずはアプリケーションをネットワークに接続しなくてはなりません。もちろん、アプリケーションが刻々と変わり続ける仮想化環境内でネットワークに接続され続けていることも保証しなくてはなりません。
まずはVLANの接続性について考えてみましょう。仮想化によって、サーバチームは必要とされるネットワークとVLANをハイパーバイザー上で設定しなくてはならなくなっており、その設定した値を逐一物理ネットワークチームへと伝達して、展開してもらわなければなりません。新しいネットワークについてのリクエストごとに、やりとりが2つのグループの間を行ったり来たりするのです。アプリケーションが接続されるのはこの行ったり来たりが終わってからになります。
悪いことに、我々は与えられた仮想マシンがどこで動作しているのかを知ることができなくなってきています。ある時はネットワークチームは全てのVLANを全てのスイッチのポートへトランクする事もできます。これはそれぞれのリクエストに答えるという意味では簡単だからです。ですがネットワークにおけるベストプラクティスは必要なVLANだけを単一のすいっとポートのみへトランクするべきであるとしています。これはブロードキャストドメインを制限し、セキュリティを向上させる糸がありますが、このベストプラクティスが実際の環境に持ち込むということをせず、しばしばそうならないことがあります。
もっといい方法があります。
Nutanixの仮想マシンのライフサイクルイベントは仮想マシンの詳細を直接ネットワークコントローラーへと通知します。ですから、コントローラーは適切なアクションを取ることができます。以下の会話のシナリオではmailboxという仮想マシンがAHVのノード1で起動して、mailネットワークに対してVLAN100でのアクセスをリクエストしています。ネットワークコントローラーは仮想マシンのイベントを受け取るようになっています。ですからAHVは標準のウェブフックAPIを利用してネットワークコントローラーにこの仮想マシンのイベントを通知します。このプロセスは標準APIを利用していますので、特定のベンダー要件やロックインなどはありません。あらゆるネットワークコントロールベンダーがAHV内の仮想マシンのイベントの通知を受けることができます。
更に良いことに、仮想マシンの電源が落ちたり、クラスタ内の別のノードへ移行したときに、VLAN 100をスイッチのポートから取り除く事もできます。この機能はもはや手動でスイッチのポートにVLANを展開しなくても良いということを意味し、さらに、仮想マシンの移行を取り扱うために、VLANのトランクを過剰に実施する必要もないということも意味します。必要なだけのVLANを追加し、必要のなくなったときにそれが取り除かれます。この機能で、これまでのようなベストプラクティスは意味を持たなくなります。
ネットワークコントローラーは仮想マシンのイベントを受け取るだけではありません。ファイヤウォールやロードバランサーもが仮想マシンのイベントを知り、恩恵をうけることができます。メールサーバ仮想マシンのファームの上にロードバランサーとファイヤウォールがあることを考えてみて下さい。新しいメールサーバの電源が入る際には、我々はそれをどうにかしてロードバランシングのプールに追加し、そのアドレスのファイヤウォールのルールを更新しなくてはなりません。仮想マシンのライフサイクルイベントの通知があれば、ロードバランサーはその仮想マシンの電源が入った際にプールに追加し、電源が落ちた際にプールから削除することができます。こうした仮想マシンのイベントを受け取るファイヤウォールも新しいメール仮想マシンのアドレスに合致したルールに更新を行うことができます。
これらのファイヤウォールとロードバランサーは物理でも、仮想のデバイスのいずれでも構いません。もしも仮想デバイスであれば、Calmのブループリントを利用して、自動的に展開することもできます。これについては本シリーズの最後でカバーします。
次の記事ではどのようにアプリケーションポリシーを作成し、トラフィックフローを許可するのかについてご紹介していきます。この柔軟なポリシーモデルによってマイクロセグメンテーションを実現することができ、アプリケーションのネットワーク側をセキュアにすることができます。
© 2017 Nutanix, Inc. All rights reserved. Nutanix, the Enterprise Cloud Platform, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries.
記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)
今回はネットワークシリーズの第2段です。NuatnixのウェブフックAPIを経由して、仮想マシン(=アプリケーション)の起動、移行などに合わせてネットワークが自動的に構成される･･･ここまではSDNでは当たり前の世界ですが、なんと物理のネットワーク機器との連携も実現されています。Nutanixは本当に何でもかんでもシンプルにしてくれますし、上のトランクの話もあるように自動化しながら、合理的でリソースを浪費することも回避してくれます。
Calmのマーケットプレースにも多くのネットワーク系のVAが置かれることになるのでしょうか、とても楽しみですね。
