ブログトップ 記事一覧 ログイン 無料ブログ開設

Simple is Beautiful このページをアンテナに追加 RSSフィード

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2017/04/20 (木)

[] vCenter Server Appliance のアップグレード 6.0 -> 6.5

SUSEベースからPhoton OSベースに変わるので、一時的に別IPアドレスで仮想アプライアンスをデプロイしてデータを移行することになるわけだけれども、まぁ色々とハマりどころはある。

が、色々ある中で、何をまずやっておけばいいかといえば、VCSA6.0仮想アプライアンスのrootアカウントのパスワード変更。vSphere 6.5のリリースノートにも下記のように記載があるので、おそらくこれが原因で上手くいかない場合が多く発生しているのではないかと推測している。

-Attempts to upgrade a vCenter Server Appliance or Platform Services Controller appliance with an expired root password fail with a generic message that cites an internal error

During the appliance upgrade, the installer connects to the source appliance to detect its deployment type. If the root password of the source appliance has expired, the installer fails to connect to the source appliance, and the upgrade fails with the error message: Internal error occurs during pre-upgrade checks.

Workaround:

  1. Log in to the Direct Console User Interface of the appliance.
  2. Set a new root password.
  3. Retry the upgrade.

日常操作的にはまったく問題なくrootアカウントでのSSHログインなどはできるので気付きづらいが、vCenterサービスに対するSingle Sign-onとしては有効期限が切れている場合、サービスの制御ができないのでアップグレード処理(Pre-upgrade check)に失敗する。

f:id:takaochan:20170420143703j:image

VCSAのrootパスワードそのものがわからん!もしくはログインすらできん!という場合はKB2069041参照。

この点以外にも、リリースノートに書かれている "Upgrade Issues" の項目はどれもアップグレード作業実施前に目を通しておいて損はない気がする。リリースからこれまでいろいろな人達が踏んできた課題の主な項目そのものだと思われるので。

2015/12/04 (金)

[] ACI本刊行記念!! ACIとNSX - vExpert Advent Calendar

vExpert Advent Calendar 12/4 エントリーです

本日、皆さま待望の『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』がついに発売されました!!

よく知りませんが本書は何千部もは刷られていないと思うので、大きな書店かAmazonなどオンラインでぜひお買い求めください(帰りに忘年会行く前に本屋さんへGo!)。なかなか技術書が売れないご時勢ではありますが、ACI関連本もVMware関連本ぐらいは売れる様になるといいんですけどね。

なお、本書の著者の一人 Lucien Avramov は大の日本好きでこれまでも何度も日本に訪問しております。まだ未定ですが、年明け2/24の開催を予定している ACI友の会#3 にもしかしたら…。乞うご期待。なお、Twitterでもつぶやきましたが、何らかのかたちで私とつながっている方で、本書を買ったという方には、ご希望であれば英語版の本書を差し上げます(私の手元に在庫がある限り…)。ACIの理解を深めるついでに英語の勉強にいかがですか?(^_^;) 何らかの方法でご連絡ください。

…と宣伝っぽい内容はそれくらいにして…vExpert Advent Calendarでこのネタはどうなんだってご意見もおありでしょうが…どなたか譲るよ!って書いたのに誰も手を上げないんだから仕方がない!縛りなしってルールだし!そして別に何かをディスるつもりもないし(^_^;)!!

そんなわけで、本エントリーでは『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』日本語版の出版を記念して?、いいとか悪いとかではない視点のCisco ACI (Application Centric Infrastructure) /VMware NSX論を少し書いてみたいと思います。お約束としては、あくまでも個人の意見、個人の視点です。会社の人間として喋るときにはちょっと別の言い方をしているかもしれません(^_^;)。また、あまりテクニカルに深くは踏み込みません。

本書『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』の英語版はほぼ1年前に出版されたものですので、ACIの情報としては残念ながらすでに最新の内容ではありません。原著が出版された時点ではまだ対応していなかった機能や構成が可能になっている部分もすでに沢山あります。今月リリース予定の新バージョンでも、すでにこちらのオフィシャルブログなどでも触れられている通り、かなり楽しみな機能が数多く追加・拡張されていく予定です。ACIは新しい製品ですので、まだまだ積極的に様々な機能が追加・拡張されているフェーズにありますが、そうした新機能の学習という目的には本書はあまり適していないかもしれません。しかしタイトルの通り、本書は主にはアーキテクチャ、コンセプト、メソドロジーなどといった、バージョンがあがったり機能が拡張されていったとしても陳腐化することのないそもそもの部分、つまりはACIの根本的な思想・考え方といった内容に比較的比重が多く割かれていますので、ACIを表面的な部分だけでなくしっかりと「どういう考え方に基づいてACIはデザインされているのか」といった基礎的な部分から理解されたい方にとっては、今読んでも十分にお役に立てる内容が詰まっているのではないかと思っています。

さて、本エントリーではACIそのものについてはあまり書くつもりはありません。そのあたりはぜひ本書をお読みください(しつこい?といっても、本書が売れても別に私には1円も入ってきませんけど)。このエントリーで書きたいテーマは「手段としてのネットワークを活用するために」といったようなふわっとした感じの内容です。

OpenStackやDocker、そしてもちろんSDNなど、最近はコンピューティングの側面から見てもネットワーキングの側面から見てもITインフラストラクチャに求められることが大きく変化しつつあります。トレンドや技術動向をしっかりと把握しておくことは大切ですが、そうした情報に流されて「わが社もクラウドだ!」「SDNを導入しよう!」などとそれ自体を目的化させてしまわずに、ぜひ自社のIT基盤に求められているもの、ひいてはビジネスを支える要素として求められているものは何なのか、といった目的をしっかり踏まえたうえで、手段としてこれらの新しい流れを活用することができるのかどうか、冷静に検討頂ければと思います。

この流れを生み出したきっかけはやはりサーバ仮想化技術にあるでしょう。2000年代中ごろから現在にかけてのVMwareの飛躍はまさにそれを体現したものといえます。サーバ仮想化はITインフラリソースをソフトウェア的に構成することができる時代への入り口を開いたと言えます。その流れはインターネットの普及と高速化と相まってパブリッククラウドへとつながり、そして現在では雲の向こう側かこちら側かなどといった違いを超えて、どのような形態であろうとも、ITリソースは「必要なときに、必要な対象に対して、必要なリソースを、必要なだけ」提供することを可能とするサービス化された仕組みが求められるようになりつつあります。

サーバの役割を持つコンピュートリソースは物理サーバであろうと仮想マシンであろうと、そして最近ではコンテナであろうとその上で提供されるサービスという視点から見るとどのような形態で仕組みが作られていようと関係ないわけで、ITインフラリソースの要素の中で最も論理化が進みやすい要素でした。そしてまずは「それまで使われていた」タイプの企業が必要としているいわゆるクライアントサーバ型的なエンタープライズアプリケーションであっても問題なく使用できるサーバ仮想化が普及し、そして「これから使われていく」タイプのモジュール同士がAPIやQueueで結び付きながらブラウザやアプリを通じて柔軟にサービスを提供していく新しいカタチのアプリケーションが次第に広まっていく中で、Dockerのようなもはや仮想化ですらないアプリケーション実行環境そのものを展開する仕組みへと発展しつつあります。

このITリソースのサービス化の流れは当然ストレージやネットワークにも波及し、その流れの中でネットワークの範囲としてはCiscoのACIやVMwareのNSXが登場してきたと言えます。

そんなACIは確かにネットワークのソリューションではあるのですが、その根本的な製品思想はこれまでの企業ネットワーク製品とは大きく異なっています。そういう意味では、既存ネットワークの延長線上として「ソフトウェア的に論理的なネットワークを作ることによってネットワークの構成管理運用の柔軟さと展開の速さを高めよう」という、いわゆるSDNという括りにも収まるのだろうか?と思う部分も多くあります。まぁSDNという括り自体も人それぞれなので、括りに収まるもなにもないのかもしれませんが。

また、SDNをどう捉えるのか、という問題でもあるかと思うのですが、SDNをソフトウェア「だけ」で実現する新たなネットワークと考えるのだとしたら、物理的なハードウェアスイッチであるNexus 9000シリーズに依存したソリューションであるACIはそもそもSDNではないということになってしまいます。しかし、SDNをソフトウェア「によって」実現する新たなネットワークと考えるのであれば、ACIの論理的な側面は完全にAPIによって制御が可能なソフトウェアとしての側面を持ちます。ハードウェアによる処理性能・安定性と、ソフトウェアによる論理的なデザインと構成、その両面をACIは併せ持っています。

ACIは単に「これまでのネットワークの要素をソフトウェア化する」(=ネットワーク仮想化?)ものではありません。ネットワークリソースにサービス化が求められるなら、それはどうあるべきなのか?という根底から検討し、それを実現する手段として最適なかたちを目指して製品化されたソリューションです。そんなわけで、ACIに対しては、わかりづらい/よくわからない、既存のネットワーク管理のノウハウやナレッジが通用しないのではないか、アプリケーション視点のポリシー管理?これまでとまったく違う管理手法を取り入れるのには抵抗がある、など等のご意見が多数あることは事実かと思っていますし、そうであるからこそ、ACIのアーキテクチャ、コンセプト、メソドロジーといった部分をご理解いただくために本書のようなものが必要だと思っています。

会社としても、そして世の中としても、CiscoのACIとVMwareのNSXは競合であるとして色々なところで扱われています。確かに「新しいネットワークのカタチ」としてお客様がいわゆるSDNを検討された際に土俵に上げられるソリューション同士であるという意味では、競合といえる部分はあるかと思います。しかし、両者を見ているとおそらく次第にこの2つのソリューションは別のものであるという認識が少しずつ理解されていくのではないかとも思っています。

NSXの強みの1つは、やはりvSphere環境との高い密結合にあると思います。vSphere環境を前提としたNSX-vとNiciraの流れを持つNSX-MHがありますが、おそらく前者が次第に拡大していく方向で統合されていくことになるのではないかと思われます(中の人じゃないので知りませんけど)。NSXのコンポーネントには仮想アプライアンスとしていわば仮想マシンの一種として存在している要素(主にNorth-South方向の通信に関わる)と、ESXiのVMkernelの中に組み込まれる要素(主にEast-West方向の通信に関わる)の両方がありますが、NSXの肝はVMkernelに組み込まれて動作する分散仮想ルータや分散仮想ファイアウォールにあると思います。VMkernelに組み込まれるからこそ、vSphere環境の仮想マシンとの親和性が非常に高く、かつ他社にはまねできないソリューションを実現することができているわけです*1。NSXはサーバ仮想化のESX同様にハードウェアとしてのネットワークに依存しない(土管化?)仕組みを実現することを基本思想として持っているので、仮想アプライアンスとKernelモジュールでネットワーク機能を実現する仕組みはそれを体現する実装といえると思います。

f:id:takaochan:20151204134109p:image

逆にACIは、特定のホスト側の仕組みには依存しない、ということを設計思想に持つ疎結合型のソリューションです。特定のHypervisor、特定のOS、物理仮想の違いなどに依存せずに、あらゆるコンピューティングの形態に対して統一されたポリシーを提供することができます。しかし逆にハードウェアとしてのネットワークには強く依存する実装であるため、物理スイッチであるNexus 9000、そして物理アプライアンスとして提供されているAPIC (Application Policy Infrastructure Controller)と、ACIを使用するためには前提としてハードウェアが必要です。ACIを多くの基盤でご利用いただきたいと考えていますが、誰もが必要とするものでもないとも考えています。論理的なネットワークを動的に追加・構成・管理・変更していく、いわばネットワークに柔軟性を求める使い方をしたいという場合にはACIはとても有用ですが、静的に安定して個々のスイッチが自立分散して動作していてシンプルに広帯域・低遅延の拡張性のあるネットワークが欲しいという場合には、ACIではなく、いわゆるイーサネットファブリック的な使い方の方が向いているかもしれません。また、これまでどおりの、各ネットワーク機器を個別に構成し、標準化されたルーティングプロトコルなどによって情報交換は行っても各機器は自立して動作する使われ方は、SDNの登場によって使われなくなるということもないと思います。これらの向き不向きは業種や規模というよりも、ネットワークに求めている「使い方」次第といえるでしょう。

f:id:takaochan:20151204135639p:image

この先しばらくの間はSDNという括りでCiscoのACIとVMwareのNSXについては両者の比較やら競り合いやら色々な情報がニュース記事や両社からの発表などによって出てくることになると思います。しかし、5年後ぐらいにはきっと、ルータとスイッチほどとは行かないまでも、CiscoのスイッチでいえばNexusとCatalystぐらいのカタチで目的や使われ方が違うものとして認知されるようになっているのではないでしょうか。

明日のvExpert Advent Calendarもなぜか私なので、明日はまったく今日とは正反対の感じで短めのエントリーでVMwareがらみの小ねたを紹介したいと思います。

*1VMware以外のいわゆるサードパーティベンダーがVMkernelに組み込まれて動作するソフトウェアを実装することができないわけではありませんが、vSphereそのものの進化にきちんとアラインされたかたちで継続的にリリースしていくことはVMware以外にはかなりハードルが高いといえます

2013/12/02 (月)

[][]分散スイッチングと分散ルーティング (1)

クリスマスシーズン到来ですね。vExpert Advent Calendar に参加することにしましたので、ちょっと怠け気味のこのBlogについても、一応4回以上、12月にエントリーをUpできれば…と考えております。果たして穴を開けずに乗り切る?ことができるのでしょうか(^_^;)。では、第1回の @mihochannel さんの エントリー『Fusion 6 で OSX Marvericks ゲストを立ててみた』 に続いて2日はこんな感じでまずは…。

分散ってどういうこと?

VXLANやNVGREなどのオーバーレイプロトコルが登場し、データセンターにおけるネットワークの考え方が変わってきたことに伴い、データセンターのネットワークでは分散スイッチングと分散ルーティングといった仕組みが一般化していくことになりそうです。分散スイッチングは、VMware vSphereでいえば いわゆるvDS / Nexus 1000Vで、すでに3年ぐらい前からありますのでだいぶ認知も広がっていますし、実際にご利用頂いている方も多くいらっしゃるのではないかと思います。

分散スイッチングは、下図のように実際のスイッチング処理は各Hypervisorに分散していながらも、管理的には全体が統合して論理的には1台の仮想スイッチであるかのように動作する「分散仮想スイッチ」と呼ばれる仕組みです。(分散仮想スイッチが構成された範囲内であれば)どこのHypervisorに仮想マシンが移動しても、対象の仮想マシンに紐付けられた論理ポートが変化しませんので、管理上も継続的な統計データを取得することができますし、構成としてもセキュリティや設定情報をHypervisor間で移動&再設定などをすることなく維持することが可能です*1

f:id:takaochan:20131201222919p:image

分散ルーティングは、分散仮想スイッチにおける機能をさらに拡張し、L2スイッチングに加えて、L3ルーティングまでエッジ部分で処理してしまおう、という仕組みです。分散仮想スイッチにおいては、数多くのセグメント内通信が処理されてきたわけですが、いざセグメント間で通信しようとするとルーティング処理が必要となり、分散仮想スイッチ内だけで処理を完結することができませんでした。分散ルーティングは、スイッチングのためのMACアドレステーブルだけでなく、ルーティングのためのルーティングテーブルまでエッジに提供し、いわばこれまでL2スイッチであった分散仮想スイッチをL3スイッチにグレードアップする仕組み、といってもよいかもしれません*2

このように、分散スイッチングも分散ルーティングも、要は論理的には1台のスイッチであったり、1台のルータ/L3スイッチであったりする概念上のネットワークモジュールを、物理的・仮想的には分散されたかたちで実装する技術です。実装方式は2パターン。仮想スイッチを使った実装方式と、物理スイッチを使った実装方式です。

分散スイッチング

仮想スイッチを使ったパターンの分散スイッチは、VMware vSphereにおける分散仮想スイッチによって、概念が一般化したといえます。複数台のESXホストにまたがった仮想スイッチを論理的な1台のスイッチとして扱う仕組みです。VMware標準の分散仮想スイッチを使用することもできますし、サードパーティ製の仮想スイッチ機能を組み込むことも可能です。CiscoのNexus 1000Vは、VMwareの標準 分散仮想スイッチを置き換えるとともに、Microsoft Hyper-Vにおいても、同様に分散仮想スイッチを実現しています。今後、KVMに対してもOpen vSwitchを拡張するカタチで同様のNexus 1000Vとしての分散仮想スイッチ実装を提供する予定です。

物理スイッチを使ったパターンの分散スイッチは、要はファブリック型仮想ネットワークです。サーバからは普通のスイッチに対する接続とかわらない=意識しませんが、スイッチ間の通信は、これまでの一般的なL2スイッチングではなく、L2ルーティングともいえる実装構成とすることにより、ブロックされる経路を持たず、かつ全ての経路を使用する完全アクティブで可用性のあるネットワークをスイッチ同士が内部的に構成します。CiscoのFabricPathや、BrocadeのVCS Fabricなどの実装がすでに提供されています。スイッチ間通信はスイッチングされずに、入口のスイッチから出口のスイッチまでEthernetフレームがルーティングされるように送られるため、概念的には複数台の物理スイッチがまるで1台の論理的なスイッチであるかのように動作します。つまり、これも一種の分散スイッチ実装といえるでしょう。

f:id:takaochan:20131201222918p:image

分散ルーティング

仮想スイッチを使った分散ルーティングは、VMware NSXやMidokura Midonetなどのオーバーレイ型の、いわゆる「ネットワーク仮想化」と呼ばれる技術に含まれる要素となっています。同一のHypervisor上のVM間であれば、別セグメントと扱われるネットワーク間のルーティングであっても、上位のL3スイッチまでいったんパケットを送ってルーティングしてもらうことなく、仮想マシンと接続したエッジ部分の仮想スイッチがルーティング処理してしまいます。また、他のHypervisor上のVM間のスイッチング/ルーティングであった場合には、オーバーレイのためのトンネリングプロトコルでくるんで送受信を行うことで、Hypervisor間の物理ネットワークがL2であろうとL3であろうと、違いを生じさせない=意識させない仕組みを実装しています。分散ルーティングを実現するためには、中央で制御を行うController実装が(それ自体が分散実装だとしても)必ず必要であり、VMware NSXの場合はNSX Controllerが各HypervisorのNSX vSwitchにおける分散ルーティングを統合制御しています。また、ルータとしてネットワーク内の他の物理ルータなどとの間でOSPFやBGPなどといったダイナミックルーティングプロトコルのやりとりを行ったりするために、NSX Controllerとは別に、各セグメントのネットワークに組み込まれたカタチで、論理ルータの管理VMとして動作する仮想アプライアンスが別途必要となります。

f:id:takaochan:20131201222917p:image

物理スイッチを使った分散ルーティングは、CiscoのDynamic Fabric Automation (DFA)などが実装例として挙げられるでしょう。DFAもFabricPathと同様にエッジ接続を収容するスイッチ=Leafと、網内通信を中継するスイッチ=Spineの2段階でのメッシュネットワークを基本としますが、各LeafスイッチがDefault G/Wとしての応答を返す動作をすることにより、L3ルーティングの境界も各Leafスイッチに落とし込んでいる点が大きな違いといえます。仮想スイッチの場合と同様にDFAの場合でも分散ルーティングを実現するためには中央制御のControllerとなる要素が必要となり、その役割はDFAの場合にはDCNM (Data Center Network Manager)が担っています。

f:id:takaochan:20131201222916p:image

このように、分散スイッチングや分散ルーティングが普及してくると、さらなる自由度を得ることを目的としてオーバーレイプロトコルなどが検討されるようになるわけですが…次回は、分散スイッチングや分散ルーティングを「どこで」処理するかによって生じる「違い」について考えてみたいと思います。…毎度おきまりですが、たぶん。ですよ。

ところで、さっそく明日の vExpert Advent Calendar の担当者がこれを書いている時点で未決定です。誰かー!!!!(>_<)

*1VMware vSphere標準の分散仮想スイッチを使用する場合は、構成管理機能はvCenter Serverに統合されます。Cisco Nexus 1000Vを使用する場合は、構成管理機能はvCenter Serverとは別に、VSM(Virtual Supoervisor Module)の役割を持った仮想アプライアンスが担います。ただしその場合も、API連携先はvCenterサーバとなります。

*2:仮想スイッチ自体にルーティング機能を付加するだけですので、構成的な絵としては大きな違いはありません。

2013/09/18 (水)

[][]あなたのネットワークにVMware NSXは必要ですか? - (2)

(1)の続きです。

NSXにおいて、各Hypervisorに実装される論理ネットワーク機能(Kernelレベルでの機能)は分散仮想スイッチおよび分散仮想ルータの役割を担うものと思われます。マルチハイパーバイザー対応のために、NSXのオーバーレイスイッチ/ルータ機能はESXiにおいては標準のvSwitchとは分離されて実装されることになるかもしれません*1。一番シンプルに実装する方法としては、ESXに対して「Nicira NVPのためにKVMへの実装においてOpen vSwitchに施した拡張と同じもの」を既存の仮想スイッチとは別に、NSX vSwitchとして実装してしまうやり方でしょう。NSX vSwitchをVSSともVDSとも統合せずに別個の新しいネットワーク機能として実装することにより、vSphere的な管理を一切通さずにNSX Controllerから制御できることとなりますし、VSS/VDSにおけるこれまでの実装や拡張はNSXとは切り離しておくことで、「NSXを使わない構成における仮想スイッチ」であったり、「NSX管理範囲外の要素のための仮想スイッチ」であったりといった使用目的に使う場合には、これまでのやり方やノウハウ、ナレッジ、連携仕様・実装などをそのまま使うことができるからです*2

前述の通り、どうやらNSXでは(少なくとも初期リリース時点においては)標準機能として実装されるのはまずはL2とL3まで、となると思われます(TCPポート番号などに基づくACLなどのフィルタリング機能は含まれると思いますが)。L2の分散仮想スイッチは既存のESX vSwitchおよびOpen vSwitchなどですでにある意味で実現されているわけですがオーバーレイネットワーク関連の機能が追加され、さらにはL3の分散ルータ機能が論理ネットワークに対して提供されることになります。L3分散ルータとしてのデータプレーン実装は各エッジノード上のNSX vSwitchなりOpen vSwitchの拡張なりに落とし込まれるようですが、各テナント毎に既存物理ネットワークとのダイナミックルーティング*3によるルーティングテーブルをやりとりするためのコントロールプレーンとしての役割を持った仮想アプライアンス(NSX Edge)がNSX Controllerとは別に必要となります(NSX ControllerはNSX vSwitchとは管理接続で繋がっているとしても、各テナントのネットワーク自体に疎通できるとは限らないため)。

下図はVMwareウェブサイトのブログから拝借したものですが、NSXが提供するオーバーレイネットワークに接続したVM間でのL3通信がNSX vSwitchで折り返されていることが図示されています。

f:id:takaochan:20130914212636p:image

また、下図では別ホスト上のVM間でのNSXによるオーバーレイネットワークを通じたL3通信が、オーバーレイの下ではL2スイッチングとして処理されていることが図示されています。

f:id:takaochan:20130914212637p:image

また、L4以上の機能についてもNSX自身がオプションとして?用意するFirewallやVPN、Load Balancerなどの機能も提供されることとなりそうですが、それらについてはNSX APIに対応したサードパーティ製のネットワークにも対応する予定とされており、基本的には仮想アプライアンスを使った実装形態となるでしょう(VMware標準の機能に対する管理はNSX Edgeに統合される可能性もありますが)。NSX ControllerにPlug-inのようなカタチで管理機能が付加されるのか、もしくは別途各ベンダー独自の管理ポイントとの連携となるのかはまだ明確ではありませんが、実際のL4-7処理を行う機能を持った仮想アプライアンスが各エンドノードに分散配置される構成を取るのであれば、いくら中央制御するとはいえそれらの間でどのようにL4-7の機能が整合性を持って処理されるのかは興味深いところです(各種仮想アプライアンスに対して処理を渡すルール管理はできても、実際のL4-7処理そのものは各アプライアンス側での処理となるでしょう)。また、物理アプライアンスや、分散配置されない仮想アプライアンスにも対応するようですので、そうした場合は分散制御は不要となりますが、今度はそこへのトラフィックがボトルネックとならないように注意する必要がでてきます。

下図も同じくVMwareブログからの拝借ですが(^_^;)、ここではFirewall処理についてもNSX vSwitchで処理している図となっています。しかし標準機能としてのプロトコルおよびポート番号ベースの標準Firewall機能を超える様々な実装やIDS/IPS、アンチウィルス処理など、ネットワークにおけるL4-7処理すべてをエッジ処理することはできないのではないかと思われ、どのように実装されることとなるのでしょうか。

f:id:takaochan:20130914212638p:image

そもそもオーバーレイである以上、オーバーレイに対応していない物理ネットワークとの接点や、物理サーバおよびオーバーレイに対応していない仮想環境との通信には、オーバーレイを解除するゲートウェイが必要となります。L2 Bridge機能のゲートウェイは複数あっても問題ないと思いますが、L3ゲートウェイは基本的には各ネットワークで1箇所となるでしょう(冗長構成にはできるでしょうけど)。また、NSXに対応する物理スイッチをL2ゲートウェイとすることで物理サーバとの接続性は確保できると思われますが、L3以上の機能を提供する物理アプライアンス・ネットワーク機器と基本的にすべてがオーバーレイであることを前提とするNSXを果たして有機的に組み合わせることができるのか、その辺りがどうなるのかはまだ私もよくわかりません。

そんなこんなで、NSXを使うことによって物理的なネットワークに依存しない論理ネットワークを構成することは確かにできるでしょうが、その上にL3-7までの様々な機能を盛り込んだネットワークを頑張って作り上げていったら、結局、物理ネットワークとはまた違った複雑性を持った新たな論理ネットワークがもう一つ出来上がっただけだった…とかなるとしたら…(^_^;)

そろそろお後がよろしいようで…。

はたして、(3)はあるのかないのか…。

*1:対して、すでに直接的に拡張を組み込んでいるOpen vSwitchを使用するKVMやXenについてはそのままの実装となるでしょう

*2:NSX機能をvSphere Clientを通じて操作するハンズオンもありましたので、「vSphere的な管理」にあえて統合する形式が選択されることになるかもしれません。NSX Managerを通してのAPI実装なんでしょうけど…マルチハイパーバイザーでの管理性を統合したいのであればちょっとどうかとも思いますが、vSphereだけで使うのであればWeb Clientへの統合は必要と判断したのかとも思います。はてさて…。

*3:BGP, OSPF, IS-ISなどに対応する模様です。

2013/09/10 (火)

[][]あなたのネットワークにVMware NSXは必要ですか? - (1)

結局8月は1本もエントリー書けませんでした…。反省。

San Franciscoで8/25-29に開催されたVMworld 2013。やはり今年の目玉はVMware NSXということになりましたが、リリース予定はCY2013Q4。年内ではありますが、まだしばらくは待つ必要がありそうです。この段階で推測を多分に含んだカタチでエントリーを書くことはちょっと躊躇われるのですが、まぁ特に責任ある?企業ブログというわけでもなし、個人ブログに自由に書くなら盛り上がっているときでしょ!ということでタイトルもあえてちょっと挑発的にいってみることにします(^_^;)。

VMwareは2012年にNiciraを買収し、2013年3月にvCloud Network & SecurityとNicira NVPを統合するVMware NSXを発表、そして今回のVMworldにおいて製品としての提供開始予定時期が発表されるとともに各種ブレイクアウトセッションが行われ、さらにはβプレビューではありますがハンズオンラボなどで実際の動作を試すことができるようになりました。とはいえ、まだまだESXi側のNSX対応も開発途上なようで、NSXとひとくくりにしてはいてもNicira NVPなNSXと、Network & Securityの色を残したVMware的なNSXとではまだちょっと別物、といった感じでした。裏側の動作としてはNSXへのESXiの対応なども動作していましたので、おそらくリリースまでの数ヶ月で表側の見た目に対する開発が急ピッチで進められることになるのでしょう。そんなわけで、マルチハイパーバイザー対応をうたうVMware NSXですが、おそらく初期リリースではNicira NVPとして元々対応していたKVMとESXiへの対応というカタチとなるのではないかと個人的には推測しています。Open vSwitchを使用することが可能なXenはともかく、まだサードパーティ製のネットワーク機能の組み込みに制約の多いHyper-Vへの対応はなかなか難しいかもしれません。

さて、そんなNSX最大のメリットであり、考えようによってはデメリットでもあるとも思える点が「ネットワークの仮想化」を目的とした製品であるということ自体であると私は考えています。

f:id:takaochan:20130908044055p:image

全ての通信を基本的にはオーバーレイされた論理ネットワークで構成してしまおう、という考え方は OSにとっての仮想マシンと同じ様な発想に基づいています。VMware ESXはOSにとってのサーバを論理サーバ化してしまうことによって、物理的に固定化されていたサーバを動的なものとしてインフラの概念に根本的な革新をもたらしましたが、VMware NSXではこれと同じような変化をネットワークに対して実現しようとしています。

なるほど確かに、これまでのネットワーク機器は基本的には自律分散を基本としており、ダイナミックルーティングやVTPなど、仕様に基づいて相互に情報を交換することはあっても、基本的には各ノードが自律的に動作する仕組みが一般的です。この仕組みのメリットは、なんといっても中央制御されずともネットワークが成り立ち、部分的に障害が発生したとしても全体として調停する存在なく継続的に通信が維持される点です。しかし、この仕組みはエンドノードとしてのサーバが物理的に固定化されていた時代には十分に機能していたものの、過半数のサーバが仮想化された現在では、動的に変化していくサーバ群に対してより柔軟に対応するネットワークが求められており、そうした状況に対して様々な方法での対応が試みられている、というのが現在の状況といえるでしょう。そしてその試みの1つが、NSXが全面的に採用しているオーバーレイ方式のネットワークです。

f:id:takaochan:20130909233525p:image

L2(VLAN)/L3(Routing)の壁を超えたネットワークを実現するためにEndpoint間でのL2接続をオーバーレイによって実装する、というやり方は確かに非常に強力です。通信を必要としている動的な点と点を結びつけるために、その間のネットワーク全体を刻々と変化していく状況に追随してトポロジーを維持することはなかなか大変ですから、なのであれば通信を必要としている点を直下に持っているエンドノード同士が物理的なトポロジーに関係なくPoint to Pointでつながり合えばよい、という発想は たしかにネットワークにおける制約を乗り越えるために使うことができるやり方の1つであり、仮想環境を前提として考えるとある意味で必然ともいえる帰着点かもしれません。

しかしポイントは、オーバーレイ方式をネットワーク全体に適用することが果たして必要とされているのかどうか、という点です。会社のネットワークにはWANとLAN、有線と無線、様々なセグメントとそれらの間のFirewall、各種サーバやロードバランサ、データセンターとオフィス、さらにはサテライトオフィスやモバイルアクセスなどなど…様々な形態と要素が組み合わされています。サービスを提供する要素も、物理サーバや仮想サーバなどの汎用OS上にインストールされたソフトウェアベースのものだけではなく、各種センサーやアプライアンス製品、カメラやビデオなどのデバイス類、等々、とても多様です。オーバーレイはこれらエンドデバイス一歩手前の仮想スイッチや物理スイッチなどの段階でオーバーレイのエンドポイントを設けることで、各エンドデバイス自体でのオーバーレイ対応を不要としていますが、モバイル機器などの接続形態がLANに限定されないデバイスであったりなども多くオーバーレイ化が逆にネットワークの複雑性をもたらしてしまう場合も考えられます。また、物理的な接続ポイントはこれまでVLANであったりセグメントであったりなどの情報からロケーションを判断していたわけですが、オーバーレイによって物理的なネットワークとは別に、フラットな論理ネットワークが構成された場合にはどのように最短経路や最寄りのAD/DNSサーバ、各種キャッシュサーバなどを判断するかなどは新しい課題となるでしょう。

f:id:takaochan:20130909233526j:image

そもそも、オーバーレイ方式の論理ネットワークの下には必ず物理ネットワークが必要です。物理ネットワークはなくならないし、どちらかといえばオーバーレイなネットワークが上に構成されている場合には物理的にはどこにボトルネックが発生するか予測が付かなくなるが故に、基本的にはフルメッシュでActive/Activeで広帯域・低遅延なネットワークを実現するいわゆるFabric的なネットワークが必要となるでしょう。そして、それらの物理ネットワークの管理とステータスの把握は安定した通信を得るためには欠かせません。オーバーレイは完全に下回りとなるネットワークを切り離すため、上(オーバーレイネットワーク)からは下(物理ネットワーク)が、下からは上がお互いに把握できないが故に、ネットワークのトラブルシュート、特にパフォーマンスまわりについての切り分けはとても困難となることが想定されます。

まずはここまで!つづく。

なお、このシリーズは単なる批判というよりもちゃんと理解して、判断して、必要性をしっかり考えることを目的としたものですので、誤解なきよう!

...(^_^;)

2013/07/16 (火)

[][][] Nexus 1000V InterCloud ってなに?

ご存じ Nexus 1000V は Cisco が提供する仮想スイッチラインナップです。当初は VMware vSphere 向けの分散仮想スイッチを拡張・置き換える 3rd Party 製スイッチモジュール Nexus 1000V Switch for VMware vSphere だけが提供されていましたが、今年 次男坊として Nexus 1000V for Microsoft Hyper-V の提供が始まりました。今後 三男坊? Nexus 1000V for KVM の提供も予定されています。これらは各Hypervisorに対応するNexus 1000Vであるという意味で、共通の仕組みを持った仮想スイッチといえます。もちろん、各製品独自の実装に合わせるためであったり、想定される使われ方などにも基づいて、それぞれの構成に微妙な違いはありますが、可能な限りNexus 1000Vとしての共通性を維持するように実装されています。

そして今月、Nexus 1000V シリーズとしては兄弟というよりも従兄弟?的なラインナップとして、Nexus 1000V InterCloud の提供が開始されました。Hypervisorの範囲でL2スイッチ機能を提供する三兄弟に対して、Nexus 1000V InterCloud はその名の通り、Enterprise向けの仮想化環境とPublic Cloud環境を結びつけてL2ネットワークを構成することを目的とした仮想スイッチとなります。今回リリースされた最初のバージョンにおいては、VMware vSphere 5.x と Amazon AWS 間で使用することができます。

f:id:takaochan:20130714234207j:image

Nexus 1000V InterCloud は目的と役割が他のNexus 1000Vとはだいぶ異なるため、仕組みもちょっと異なります。まずNexus 1000V InterCloud を使用するために必要となるコンポーネントは、次の通りです*1

  • Cisco Nexus 1000V InterCloud VSM (Virtual Supervisor Module)
  • Cisco Nexus 1000V InterCloud VEM (Virtual Ethernet Module)
    • InterCloud Switch (ICS)
    • InterCloud Extender (ICE)
  • Cisco Prime Network Services Controller (PNSC)

まず、VSMによってパラメータ情報を定義するPort Profileが一元的に管理されている、という点はNexus 1000V共通の特徴です。この点は、Nexus 1000V InterCloud であっても違いはありません。対して、実際のスイッチング処理を担当するVEMの実装は、Hypervisorの中でL2スイッチ機能として動作する他のNexus 1000Vとは大きく異なります。Nexus 1000V InterCloudでは、VMware vSphere 環境と Amazon AWS 側にまたがってセキュアなL2ネットワークを構成することが役割となるため、両サイドにコンポーネントを配置する必要があります。現バージョンでは、VMware vSphere側にInterCloud Extender (ICE)を、Amazon AWS側にInterCloud Switch (ICS)を配置します。これらはネットワーク要素ではありますが、実体はいずれも仮想アプライアンスです。現バージョンではNexus 1000VのVSMはVMware vSphere側に配置する必要があるため、Nexus 1000V InterCloud構成要素でAWS側に配置されるコンポーネントはICSのみ、ということになります。

そして、Nexus 1000V InterCloudの管理は、全てCisco Prime Network Services Controller (PNSC) から行います。PNSCはこれまでVirtual Network Management Center (VNMC) と呼ばれていた製品の後継バージョンとしての位置づけとなり、このバージョンからNexus 1000V InterCloudに対する管理機能が追加されました。これまで通り、Virtual Security Gateway (VSG) や ASA 1000Vといった仮想アプライアンス群を管理する機能も実装されていますので、もちろんNexus 1000V InterCloud とそれらの仮想アプライアンスを連携させて使用することも可能です。

f:id:takaochan:20130715181015p:image

Nexus 1000V InterCloud を使用する上で、VSMのデプロイとPort Profileの作成、PNSCへの登録は必要となりますが、それ以降のICS/ICEのデプロイと構成などの処理は全て、PNSCから自動的に行われます。

f:id:takaochan:20130715181016p:image

また、InterCloudを活用する上で必要となるVMware vSphere環境からAmazon AWSへの仮想マシンの移行・複製やテンプレートの作成などについてもPNSCから行うことができる点がInterCloudの特徴といえます。OVAイメージをPNSCを通じてAWSのテンプレート(AMIイメージ)に変換することも可能です。さらには、vCenterサーバに登録されているVMを選択し、そのままAWSのEC2にVMとして変換することもできてしまいます。

f:id:takaochan:20130715181017p:image

Nexus 1000V InterCloudにおいては、ICSとICEの間と、ICSと対象VM(EC2 VM)の間のそれぞれでセキュアトンネルが構成されます。ICS - ICE間のトンネルでは複数のVLANがTrunkされて流れます。基本的には、1つのリージョンに対して1つのICSを配置すれば複数のVLANをL2延伸することが可能です。AWSのVPCには依存せずにPNCSによって一元的に管理・構成することができるL2ネットワークを構成するために、ICSに接続するVMに対してPNSCはInterCloud Agentを導入します。このAgentによって、ICSとVM間でもセキュアトンネルを張り、VMware vSphere側のVMとAWS側のVMとの間でL2接続を実現しています。

さて、まずはこんなところでしょうか。まだ最初のリリースですが、今後のNexus 1000Vの発展の広がりを感じさせてくれる重要な一歩ですね。

*1:ダウンロードするコンポーネントとしては、Nexus 1000V InterCloudのzipパッケージと、Cisco PNSCのzipパッケージの2つです。

2013/05/18 (土)

[][][] Nexus 1010/1100 ってなに?

面白い?エントリーを書いている時間が取れないので、今回は隙間埋めエントリーです(; ̄ェ ̄)

Ciscoが提供する仮想アプライアンス群には、Nexus 1000VのVSM (Virtual Supervisor Module) や、VSG (Virtual Security Gateway) などといった、仮想マシンとして動作するものが多数あります。こうした仮想アプライアンスは、単純にESXi上で実行してもよい*1のですが、管理対象であるvSphereとは切り離して実行させたい、という場合や必要性もあるかと思います。そうしたニーズに対応するために、CiscoはNexus 1010 / 1110 という仮想サービス用のプラットフォームを提供しています。

f:id:takaochan:20130518195457j:image

Nexus 1110は、CiscoのラックマウントサーバであるUCS C220M3をベースとして使用しています。1110-Sと1110-Xの2種類のフォームファクターが提供されており、それぞれ6(S)もしくは10(X)の仮想サービス=仮想アプライアンスを実行することができます。なお、これらの値は近いうちに9(S)と14(X)に拡張される予定です。

Nexus 1100を使用するメリットの1つが、ネットワーク管理者とサーバ管理者の担当範囲を明確に管理できるようになる点です。たとえばNexus 1000Vを使用する場合であれば、Nexus 1000VのVSMはNexus 1100に対してネットワーク管理者が、VEM (Virtual Ethernet Module) は各ESXiホストにサーバ管理者が導入することができます*2。また、その後の運用においても、ネットワーク管理者はNexus 1100上のNexus 1000V VSMに対して、NX-OS CLIを使って仮想マシンの通信仕様をPort Profileというかたちで作成し、サーバ管理者はvCenterを通じた操作において仮想マシンのネットワーク接続先として「ネットワーク管理者にとって作成されたPort Profile」=仮想スイッチ側としてはPort Groupを選択して割り当てればよい、というかたちで責任範囲と役割を明確化することができます。

Nexus 1100は、vSphere用のNexus 1000V VSMやVSGや、Hyper-V用のNexus 1000V VSMやVSGなどをまとめて実行することができますので、これらの仮想アプライアンス型サービスを使用する際に、サポートまでも含めて一元化できる仕組みとして、活用頂いてもよいかと思います。

*1:仮想アプライアンスの種類によっては、実行方式に制限のあるものもあるます。

*2:VEMはESXiに対して一般的なパッチ等と同じようにVIBパッケージ形式で提供されていますので、ESX管理者には慣れた操作で導入を行ってもらうことができます。