SDN Feed

2017/11/08

AHVのネットワークの新機能 パート4

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のStaff Solutions ArchitectのJason Burns氏によるものです。原文を参照したい方はWhat’s New in AHV Networking Part 4をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig297

本シリーズの以前の記事で、我々はNutanixがどのように仮想化スイッチ内にアプリケーションポリシーを実装し、アプリケーションのトラフィックに対してセキュリティを提供しているのかを見てきました。AHVマイクロセグメンテーションはレイヤ2からレイヤ4までの与えられたポリシー定義をベースにしたルールを実装しています。つまり、定義からアドレスやプロトコルやポートを自動的に展開するのです。

しかし、幾つかのタイプのトラフィックではシンプルなルールでは提供ができない、内部的な検査が必要な場合もあり、そこではネットワークファンクション仮想化(NFV)が必要となってきます。トラフィックの中にウィルススキャンの機能やパケットを深く検査する機能を取り込んだりするためには、我々はもっとネットワークの高いレイヤへと目を向けなくてはなりません ー つまり、もっと多くのリソースを必要とすることになります。Nutanix AHVのネットワーキングスタックでは、ネットワークトラフィックフローを収集したり分析したりするために仮想化されたネットワークファンクションを挿入してこうした検査を行うことができます。

このブログのシリーズは遡ること6月にNutanix .NEXT DCでアナウンスされたワンクリックネットワーク実現するのに役立つAHVの機能を取り上げます。

パート 1: AHV ネットワーク 可視化 

パート 2: AHV ネットワーク 自動化と統合

パート 3: AHV ネットワーク マイクロセグメンテーション

パート 4: AHV ネットワーク ファンクションチェイン(本記事)

AHVネットワークファンクションチェイン

現在AHVの管理者はネットワークファンクションチェインをAHVネットワーク(AHVホスト上の単一VLANが対象です)全体からトラフィックをリダイレクトすることで作成します。例えば、Exchangeネットワークの全てのトラフィックをファイヤウォールアプライアンスへとリダイレクトすることができます。将来のリリースにおいてNutanixはファンクションチェインがもっときめ細やかなレベルで運用できるようにそしてPrismベースのUIからそれが行えるように計画をしています。こうした改善の計画についての幾つかについては以下で述べていきます。

直近の記事で、アプリケーションポリシーでサンノゼの人事部がExchangeのエッジトランスポート層と通信ができるように許可しました。この例を拡張して、「East West ファイヤウォール」サービスチェインを使って、ポリシーの作成中に特定のトラフィックをネットワークファンクション仮想マシンにリダイレクトするようにしてみましょう。そうすることで「East Westファイヤウォールアプリケーションの検査が終われば、サンノゼの人事がExchangeエッジトランスポート層にアクセスできるようにする」というポリシーを定義することができるのです。

Fig294

上の画像はPrism内のファンクションチェインの管理UIのもので、次のリリース時には利用ができるようになるものです。Redirect through service chain(訳注:サービスチェイン経由でリダイレクト)にチェックを入れることでただのワンクリックでトラフィックを特別なファイヤウォールサービス仮想マシンへとリダイレクトし、さらなる処理を行うことができます。トラフィックが常にこの経路を通ることを保証するために、我々はAHVホスト内の仮想化スイッチ内部にいくつものルールを実装しました。以下のダイアグラムはトラフィックパス内のEast Westファイヤウォールを顕しています。あらゆる仮想マシンへのまたは仮想マシンからのトラフィックは最も右のブリッジ br0 から内部のスイッチへと至ります。もしくは物理ネットワークへのアップストリームとしてスイッチされます。この例ではbr.nf ブリッジ(またはネットワークファンクションブリッジ)内のルールで人事の仮想マシンのトラフィックをリダイレクト ー 右または左へと ーしてネットワークファンクション仮想マシンへと導きます。

Fig295

br0.local ブリッジは一つの仮想マシンが他の仮想マシンと直接通信することを一切許しません。特定の仮想マシンからのトラフィックは残りのブリッジチェインを流れながら処理され、ブリッジチェインから仮想マシンへのトラフィックも同様です。

ルールを作成し、特定のトラフィックをネットワークファンクションチェイン経由で流せるようになったので、今度はどのようにサービスもしくはエージェント仮想マシンを展開するのかを見ていきましょう。それぞれのネットワークファンクションはそれぞれのAHVホスト上で動作させなくてはなりません。こうすることでサービスチェインをホスト上に構成し、ファンクション仮想マシンを展開して、チェインの中に引っ掛けることができます。もしもこの手順を手動ですべてのホスト場で行わなければならないとしたら、こうした手順内では多くのエラーが起こる可能性が含まれてきます。

ですが、それぞれのステップを手動で実施する必要はありません。なぜなら、次のリリースにはNutanix Calmが含まれており、これを助けてくれるからです。Calmはパロアルト社のVM-シリーズファイヤウォールをNutanix AHVホスト上にブループリントに沿って展開するだけでなく、必要に応じてコントローラーを構成することもできます。ですから上で示したように新しいEast Westファイヤウォールサービスを使い始める際にセキュリティポリシーが正しいことだけをチェックすればよいのです。

Fig296

AHV上で動作しているあらゆる仮想マシンがネットワークファンクション仮想マシンを利用することができます。上で紹介したパロアルトネットワークスのVM-シリーズのファイヤウォールはNutanix上に展開できるNFVの例のホンの一つです。お使いになりたい製品を自由に使うことができます。私のラボではオープンソースのツールを仮想マシンとして動作させ、ファンクションチェインではAHV上の全てのホストにパケットキャプチャとIDSの機能を提供しています。

シリーズのサマリ

今回のシリーズでは同時にどれだけ可視化自動化、そしてセキュリティが近年のデータセンタネットワーク戦略の中で重要なコンポーネントになったのかを述べてきました。Nutanix AHVは接続性とフローマッピングの両方をPrismで可視化しています。自動化はベンダーに依存しないライフサイクルイベント通知とCalmによる複雑なネットワークサービスの展開と構成の両方によって提供されます。複数の段階で階層化された絶妙なネットワークセキュリティを提供しています:

  • 接続性とフローの可視化によって怪しいものがないか見つけられる
  • トップオブラック(ToR)スイッチを統合することで、ほんとうに必要な接続性だけが有効になり、必要のなくなった接続性はすぐに削除される
  • 仮想化スイッチレベルのポリシーベースのマイクロセグメンテーションで正しいフローのみがネットワーク内で許可される
  • 先進的なセキュリティサービスとの統合でこうしたトラフィックをっ更に深く検査することができる
  • Calmの自動化によって管理上の手間を緩和し、先進的なセキュリティサービスまたはNFVのシンプルな展開を可能とする

こうしたネットワークの機能を組み合わせることでワンクリックネットワークは現実のものとなるでしょう。

今回のシリーズはお楽しみいただけましたか? コメント(※訳注、日本語版のコメントはぜひ当社のTwitterへ)かNutanixのTwitterにお願い致します。もしも技術的にもっと深く知りたいのであれば、今はまだここまでです。

議論を続け、皆でオンラインフォーラムでつながっていきましょう。

© 2017 Nutanix, Inc. All rights reserved. Nutanix, AHV, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

Forward-Looking Statements Disclaimer

This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology and our plans to introduce product features in future releases. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-K for the fiscal year ended July 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

今回はサービスチェインについてです。現時点ではVLANを全て引っ掛けてしまうよう実装のようでちょっともったいない感じもしますが、将来的にもっと細かい設定が・・・とあるので期待しましょう。そしてこちらも予想通りCalmでNFV仮想マシンを自動展開・構成できるようです。

Calmに対応したNFVであれば展開/構成までがワンクリック・・・本当にインフラに使う時間が削減されそうです。

以前も述べたようにNutanixを使う時間が少なければ少ないほどよい・・・そんな未来がネットワークの設定の分野でも間近に迫っています!

2017/09/20

AHVのネットワークの新機能 パート3

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のStaff Solutions ArchitectのJason Burns氏によるものです。原文を参照したい方はWhat’s New in AHV Networking - Part 3をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig279

本シリーズの以前の投稿で、我々はネットワークの可視化と自動化がどのようにNutanixの管理者の人生をシンプルにしてくれるのかを見てきました。しかし、単に接続を実現して、またはアプリケーションの通信の様子を可視化するだけでは十分とはいえません ー 我々は外部、もしくは内部からのネットワーク攻撃両方に対しての保護を行わねばなりません。

セキュリティの提供方法で最も良い方法はレイヤー化されたアプローチです。そのレイヤのうちの一つがマイクロセグメンテーションです。これが今回の記事の主題です。そして次のレイヤも探検します。ネットワークファンクションチェインと呼ばれるもので、これは次の記事となります。マイクロセグメンテーションの機能は将来のリリースでリリースされる予定です。

このブログのシリーズはNutanix .NEXTでアナウンスされたAHVのワンクリックネットワーク、優れた可視化、自動化、そしてセキュリティを実現する機能を取り上げます。

パート 1: AHV ネットワーク 可視化 

パート 2: AHV ネットワーク 自動化と統合

パート 3: AHV ネットワーク マイクロセグメンテーション

パート 4: AHV ネットワーク ファンクションチェイン

AHVのネットワークマイクロセグメンテーション

期待する状態またはその意図を宣言するという、ポリシーベースのアプローチによって、NutanixのAHVのマイクロセグメンテーションでネットワークの実装の詳細を気にすること無く、アプリケーションの保護を行うことに集中することができるようになります。このアプローチは従来型のIPアドレスとポートをベースとしたトラフィックの許可/却下のリストを利用するルールベースのファイヤウォールとは根本的に異なっています。

我々がファイヤウォールのルールをポリシーへと抽象化する際に、私は単に「人事の本番系環境は人士の開発系の環境とは絶対に通信できちゃマズイ」というような具合に言います。このような直接的なコマンドをうまく使うために、AHVは管理者に柔軟な、カテゴリと呼ばれるテキストベースのタグを仮想マシンにアサインできるようにしています。例えば「Environment : Production(環境:本番環境)」や「Department : HR (組織:人事)」という具合です。単一の仮想マシンを複数のユーザー定義のカテゴリへアサインすることができます。仮想マシンにアサインされたカテゴリがどのポリシーをその仮想マシンへ適応するかを決定します。

ポリシーの定義にカテゴリを利用することで、どんなネットワークアドレスがその通信に利用されるのかということは気にする必要がなくなります。古いルールベースのアプローチでは手動で本番環境のアドレスと開発環境のアドレスを指定し、物理ファイヤウォールにどうにかして入れ込む必要がありました。もしもアドレスが変わったとしたら、ファイヤウォールを更新しなくてはなりませんでした。悪くすると、このルールをネットワークのレベルで物理サーバ間で適応しなければならなくなっていました。仮想化によって、同一ホスト内の1つの仮想マシンとそれとは別の仮想マシンを保護する方法を見つけなくてはならなかったのです。

Fig280

マイクロセグメンテーションは上のポリシーベースのアプローチをAHVホストの仮想化スイッチ内に実装された仮想マシンのNICレベルの分散ファイヤウォールとを結合します。すべての仮想マシンのトラフィックは必ずこのファイヤウォールを通らなければなりません。これによってネットワークは非常にきめ細やかなレベルでセグメント化することができるのです。ー ですから「マイクロセグメンテーション」なのです。

分散ファイヤウォールはアプリケーションレベルのポリシーを実現します。直接的な宣言、たとえば「サンノゼの人事はExchangeのエッジ転送ティアへアクセスできるべきである」というような表現もすぐさまAHVクラスタの全ての仮想化サーバ上のレイヤ2から4のファイヤウォールルール上に実装することができ、更にどんなIPアドレスかMACアドレスが人事に割り当てられており、どんなアドレスがExchangeに割り当てられているということは気にする必要はありませんし、注意深くトラフィックパスがファイヤウォールを通ることを確認する必要もありません。AHVは望むアプリケーションポリシーを検証したり、実装したりすることをシンプル化し、AHVのファイヤウォールは同一ホスト上にある仮想マシン間のトラフィックはもちろん、ネットワークアドレスが変わったとしてもトラフィックを監査することができます。重要なことは、ポリシーは仮想マシンのIPアドレスやMACアドレスが変わっただけでは廃棄されたりはしないということです。それぞれの変更はシステムで行われているからです。

Fig281

NutanixのAHVのマイクロセグメンテーションは2つの手順でこうしたアプリケーションのポリシーを作成します。最初の手順はルールを監視するだけで、それを強制することはしません。違反するものがログに書き出され、管理者へ表示されますが、完全に許可されています。この繰り返しのアプローチによって、自身のアプリケーションのプロファイルを正確に反映したポリシーを作ることができます。アプリケーションの実際の振る舞いをも勘定に加えたポリシーに満足した際に、Applyボタンを押して、次の手順へと進みます。つまり、ポリシーを強制します。ポリシーに関する違反は今後はログに書き出され、更にドロップされるようになります。

レイヤ2からレイヤ4までの現実世界でのアプリケーションの振る舞いをベースとしたポリシーを作成するツールが手に入りました。次の記事ではレイヤ4もしくはそれ以上の仮想化サービスとの統合について取り上げます。

議論をそして、皆さん同士のつながりをフォーラムで続けていきましょう。

Forward-Looking Statements Disclaimer

This blog includes forward-looking statements concerning our plans and expectations relating to the availability of new technology and product features. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. This information is for informational purposes only, and the development, release, and timing of any features or functionality described remains at our sole discretion. The information provided is not a commitment, promise or legal obligation to deliver any features or functionality and it should not be relied on in making a purchasing decision. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; adoption of new, or changes to existing, international laws and regulations; and other risks detailed in our quarterly report on Form 10-Q for the fiscal quarter ended April 30, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this press release and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

© 2017 Nutanix, Inc. All rights reserved. Nutanix, AHV, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

さぁ、いよいよマイセグが出てきました。大昔にこんな記事を書いていますが、考え方自身は大きく変わっていませんね。AHVというハイパーバイザーレイヤで実装されたファイヤウォールによって、アプリケーション(仮想マシン)一つ一つに柔軟なタグ付けを実現した上で、そのタグ同士の通信を制御する、SDNの強力なユースケースの一つです。もちろんNutanixはESXiハイパーバイザーに対応していますので、ESXiハイパーバイザーを利用している場合にはNSXを利用すればこれまでもこれが実現できていたわけですが、AHVにその機能が搭載されることによって遥かに低コストでこれを実現できるようになってきました。

VDI環境ではマルウェアの拡散防止に強力な効果を発揮しますので、VDI on AHVは非常に強力なセキュリティを備えた要塞環境と呼べるようになるのではないでしょうか。今後リリース後には当社でも様々なユースケースをテストしたいと考えています。

2017/09/13

AHVのネットワークの新機能 パート2

本記事の原文は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、パスワードの取得が必要です)。

Fig276

このブログのシリーズは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内の仮想マシンのイベントの通知を受けることができます。

Fig277_2

更に良いことに、仮想マシンの電源が落ちたり、クラスタ内の別のノードへ移行したときに、VLAN 100をスイッチのポートから取り除く事もできます。この機能はもはや手動でスイッチのポートにVLANを展開しなくても良いということを意味し、さらに、仮想マシンの移行を取り扱うために、VLANのトランクを過剰に実施する必要もないということも意味します。必要なだけのVLANを追加し、必要のなくなったときにそれが取り除かれます。この機能で、これまでのようなベストプラクティスは意味を持たなくなります。

ネットワークコントローラーは仮想マシンのイベントを受け取るだけではありません。ファイヤウォールやロードバランサーもが仮想マシンのイベントを知り、恩恵をうけることができます。メールサーバ仮想マシンのファームの上にロードバランサーとファイヤウォールがあることを考えてみて下さい。新しいメールサーバの電源が入る際には、我々はそれをどうにかしてロードバランシングのプールに追加し、そのアドレスのファイヤウォールのルールを更新しなくてはなりません。仮想マシンのライフサイクルイベントの通知があれば、ロードバランサーはその仮想マシンの電源が入った際にプールに追加し、電源が落ちた際にプールから削除することができます。こうした仮想マシンのイベントを受け取るファイヤウォールも新しいメール仮想マシンのアドレスに合致したルールに更新を行うことができます。

Fig278

これらのファイヤウォールとロードバランサーは物理でも、仮想のデバイスのいずれでも構いません。もしも仮想デバイスであれば、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

Ntc2017_2

今回はネットワークシリーズの第2段です。NuatnixのウェブフックAPIを経由して、仮想マシン(=アプリケーション)の起動、移行などに合わせてネットワークが自動的に構成される・・・ここまではSDNでは当たり前の世界ですが、なんと物理のネットワーク機器との連携も実現されています。Nutanixは本当に何でもかんでもシンプルにしてくれますし、上のトランクの話もあるように自動化しながら、合理的でリソースを浪費することも回避してくれます。

Calmのマーケットプレースにも多くのネットワーク系のVAが置かれることになるのでしょうか、とても楽しみですね。

2017/08/31

VMware Cloud on AWS 技術概要

本ブログエントリーはVMware社のR&DでSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud on AWS Technical Overviewで閲覧可能です。

ネットワールドのVMwareに関する情報はこちら

昨日我々はVMware Cloud on AWSサービスを立ち上げました。VMware Cloud on AWSはVMware vSphere上で動作するプライベート、パブリック、そしてハイブリッドクラウド環境上でのアプリケーションの稼働ををAWSサービスへの最適化されたアクセスと同時に実現します。このCloud SDDCはvSphere、NSXそしてvSANのテクノロジーによって構成され、みなさんが現状でお持ちのスキルセットで管理、運用できるため、非常に馴染み深いものとなります。AWSインフラストラクチャのベアメタルを活用し、このCloud SDDCはこれまでにない方法で拡張することができます。

VMware Cloud on AWSはサービスです。これはサービスに関して言及する際に製品のヴァージョンを利用しないということを意味します。その代わりに我々はこのサービスが最初に利用できるようになったものをファーストリリースと呼ぶことになります。その後の全てのリリースについてはフューチャーリリースと呼ぶことになります。VMware Cloud on AWSはVMwareによって運用されています。これは短く言うとVMwareがインフラストラクチャリソースに責任を負い、お客様はリソースの消費を担当するということです。この記事は最初に利用時のCloud SDDCのリソースキャパシティを探検するものとなります。

VMware Cloud on AWSのコンピューティング

最初の利用時、VMware Cloud on AWSの構成には4台のホストが含まれています。それぞれのホストは512GBのメモリと2つのCPUで構成されています。これらのCPUはカスタムビルドのIntel Xeon Processor E5-2686 v4 CPUです。それぞれのCPUは2.3GHzで動作する18のコアを内包しています。結果として物理クラスタのコア数は144となります。ハイパースレッディングが有効になっているため、仮想マシンは288のロジカルプロセッサを標準のCloud SDDCの構成として利用ができるようになっています。VMware Cloud on AWSは単一の固定のホスト構成で提供されており、ホスト構成へのコンポーネントの追加オプションは現時点では提供されていないことにご注意下さい。ですがスケールアウト型での拡張が最大で16ホストまで利用できるため、結果として576 CPUコア、8TBまでのメモリを利用することが可能です。

vSphere DRSとvSphere HAが有効になっており、最高の可用性とリソース利用効率を提供します。vSphere DRSは完全自動で、移行のしきい値は標準のvSphere DRSのレベルに設定されており、vSphere vMotion操作が過剰に行われないようになっています。クラスタリソースの高可用性がvSphere HAで提供されており、ハードウェアの自動復帰が行われます。

vSphereの高可用性はESXiホスト障害時の仮想マシンの再起動中にもリソースを保証するためにも利用されます。ESXiホストは監視されており、障害イベント時には障害ホスト上の仮想マシンが代替となるクラスタ内のESXiホストで再起動されます。オーバーヘッドを最小化しながら、生産性を最大化するため、クラスタのvSphere HAの設定は1台のESXiホスト分と等しく構成されています(%ベースのアドミッションコントロールポリシーで25%)。ホスト孤立時の対応は仮想マシンの電源を落とし、仮想マシンを再起動するにセットされています。

Vmcaws_fig1

ホスト障害の修復についてはVMwareが担当します。ホストの障害が恒久的なものであれば、VMwareはESXiホストの交換をユーザーを煩わせること無く行います。障害を起こしたハードウェアの自動的な交換は恒久的なホスト障害による長期間に渡るリソースの減少からの影響を削減します。Cloud SDDCは2つのDRSリソースプールで構成されています。一つ目のリソースプールはCloud SDDCを運用するための管理用の仮想マシンが置かれており、もう一つはお客様のワークロードを管理するためのリソースプールのトップレベルのプールです。お客様は子リソースプールを作成することができます。

Vmcrp720p

VMware Cloud on AWSのストレージ

SDDCクラスタはオールフラッシュのvSANを含んでおり、それぞれのホストは合計で仮想マシンが利用するための10TBの物理キャパシティを供給します。標準のCloud SDDCクラスタでは40TBの物理キャパシティを提供します。仮想マシンのキャパシティの消費は構成されているストレージポリシーに依存します。標準ではRAID-1障害許容の手法が適応されます。ですが、お客様はストレージプロファイルを作成し、よりオーバーヘッドの小さなRAID-5やRAID-6という障害許容手法を利用することもできます。RAID-6の障害許容手法を利用する際には最小でCloud SDDCクラスタ内に6ホストが必要となることにご注意下さい。

それぞれのESXiホストは8つのNVMeデバイスを保持しています。これらの8つのデバイスはvSANディスクグループをまたいで分散されています。単一のディスクグループ内では、1台のNVMeデバイスの1.7TBのストレージがWriteキャッシュ層として利用されます。ストレージキャパシティ層には他の3台のNVMeデバイスが利用され、合計すると5.1TBのストレージとなります。

Vmcaws_fig2

ストレージ暗号化

vSAN暗号化によるデータストアレベルの暗号化またはvSphereの仮想マシン暗号化による仮想マシンレベルの暗号化はVMware Cloud on AWSの最初のリリースでは利用できません。データセキュリティについては全てのストレージNVMeデバイスがAWSによってファームウェアレベルで暗号化されています。この暗号キーはAWSによって管理されており、公開されることも、VMwareやVMware Cloud on AWSのお客様が制御することもありません。

Cloud SDDCの構成

最初のリリースではCloud SDDCはAWSの単一のリージョンと可用性ゾーン(AZ)に限定されています。ハードウェア障害は自動的に検出され、自動修復によって、障害ホストは他のESXiホストへと入れ替えられます。もしも必要な場合にはvSANデータストアがユーザーを煩わせること無く自動的にリビルドを行います。

将来のVMware Cloud on AWSのリリースではVMwareとAWSのパートナーシップを通じてマルチ-AZでの可用性が2つの同一リージョン内の2つのAZをまたいでクラスタをストレッチすることで初めて実現される可能性があります。このまたとない機能によって、従来からのアプリケーションをAWSインフラストラクチャ上で高可用性を得るためにリファクタリングする必要はなくなります。その代わり、同期WriteレプリケーションがAZをまたいで活用されることになり、復元目標点(RPO - recovery point object)はゼロとなり、復元目標時間(RTO - recovery time object)はvSphere HAの再起動時間次第となります。

Spanningaz

VMware Cloud on AWSのネットワーク

VMware Cloud on AWSはNSXを中心として構成されています。このネットワークはCloud SDDC内の仮想マシンのネットワークの提供に最適化されている一方で、Amazon 仮想プライベートクラウド(VPC)ネットワークを抽象化しています。仮想マシンへの論理ネットワークの提供とクラスタスケールアウト時の新しいホストと論理ネットワークVMKernelネットワークとの自動的な接続によって簡単な管理を実現します。最初のリリースではユーザーはVMware Cloud on AWSにレイヤ3のVPN接続で接続します。しかし、将来のリリースのVMware Cloud on AWSではAWSのダイレクト接続とクロスクラウドのvSphere vMotion操作ができるようになります。

オンプレミスのvCenterサーバインスタンスとCloud SDDC内のクラスタ上で動作している管理コンポーネントとの接続にはIPsecのレイヤ3VPNがセットアップされます。またもう一つのIPsec レイヤ3 VPNが作成され、オンプレミスのワークロードとCloud SDDCのクラスタ内で動作している仮想マシンとの接続に利用されます。NSXは全てのネットワークとセキュリティに於いて利用され、Amazon VPCのネットワークから分離されています。コンピュートゲートウェイとDLRは暗黙的なネットワークトポロジの一部として事前に構成されており、お客様が変更することはできません。お客様はご自身のサブネットとIPの範囲を提供するだけです。

Vmcaws_fig4

VMware Cloud on AWSは皆様のワークロードに対応

VMware Cloud on AWSは皆様の現在のスキルセットとツールセットを使いながら利用できるクラウドのリソースを提供します。それぞれのCloud SDDCは今日最も要件の高いアプリケーションを動作できるだけの十分なリソースをご提供します。世界最高のエンタープライズソフトウェアが世界最高のクラウド事業者と融合し、これまでにない方法でデータセンタを稼働、拡張することを実現するのです。

更に詳しくは こちらへ https://cloud.vmware.com/vmc-aws/resources

記事担当者: マーケティング本部 三好哲生 (@miyo4i

Screenshot20141105at0820381

業界はVMworldで盛り上がっていますね。ちょっと時間がうまく取れなかったのでもっとタイムリーに翻訳記事を公開したかったのですが、少し遅れてのリリースです。これまではあまり語られてこなかった、VMware Cloud on AWSを契約するとどうしたリソースが利用できるのか?今回はこれが明らかになりました。すごいスペック・・・。2TB、288スレッドのクラスタ・・・以上に私がびっくりしたのはNVMeを8本も搭載し、うち2本=3.4TBもをWriteキャッシュに振り当てるという豪華っぷり!

NSXでAmazon VPCのネットワークをきれいに隠してしまうのもVMwareユーザーにはうれしいですね。マルチAZでのストレッチにもチャレンジしていくとのこと、ワクワクします。日本に来るのが待ち遠しいですね!

追記 : お値段は?という方がおられましたので、こちらです。米国の価格なのでそのまま日本に来るとは限りませんが、ご参考まで。 https://cloud.vmware.com/vmc-aws/pricing

2017/08/30

AHVのネットワークの新機能

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のStaff Solutions ArchitectであるJason Burns氏によるものです。原文を参照したい方はWhat's New in AHV Networkingをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

アプリケーションの展開にすごく時間がかかっていませんか? マニュアルでの手順と繰り返されるアプリケーションチームとネットワークチームの行ったり来たりのやり取りは単一のアプリケーションの展開の時間を数時間で済むものから数週間にまで引き伸ばしてしまうこともあります。もしもネットワークがブラックボックスのようなものだったら? もしくはアプリケーションの管理のプロジェクトがどんどん長引いているように思ったら? Nutanix AHVのネットワーキングのツールセットを利用することでネットワーク運用をシンプルにし、アプリケーションを迅速に、そしてセキュアに起動して稼働させることができます。

アプリケーションはこれまで以上にネットワークに依存するようになってきています。アプリケーションの設計のベストプラクティスは複数のコンテナ、仮想マシンもしくはホストを利用してそれ以上分けられない機能毎に分離することを呼びかけています。これによって拡張性と簡単なメンテナンスが実現するからです ー そしてこれらの分割されたかけらはネットワーク越しに相互に接続されるのです。アプリケーションを展開するプラットフォームに関係なく、ネットワークはアプリケーションの一部になっているのです。もしもネットワークに問題があればアプリケーションですぐにその問題が顕在化します。アプリケーションを成長させる、または新しいサービスを追加する必要がある祭に、物理の、そして仮想のネットワークを構成し、新しいコンポーネントが既存のコンポーネントと会話ができるようにしなくてはなりません。もしも攻撃者がアプリケーションの一部に入り込んだとしたら、攻撃者はその同じネットワークを通じてアプリケーションが接続されているすべてのコンポーネントにアクセスができてしまいます。

複雑さの絡むアプリケーションネットワークの展開と管理をうまく行うには3つのことがとても重要です:

  • 可視化
  • 自動化
  • セキュリティ

このブログのシリーズではこうしたネットワークの要件を紐解いていき、Nutanix .NEXTで発表されたワンクリックネットワークを作成するためのAHVの機能を取り上げていきます。

パート 1: AHV ネットワーク 可視化 (本記事)

パート 2: AHV ネットワーク 自動化と統合

パート 3: AHV ネットワーク マイクロセグメンテーション

パート 4: AHV ネットワーク ファンクションチェイン

 

パート 1: AHV ネットワーク 可視化

アプリケーションを仮想環境へと抽象化すると、アプリケーションのパーツ同士のネットワーク接続の可視性を失うことになります。この可視性は、問題を迅速に解決したり、ネットワークが期待通りに動作しているのかをひと目で確認したりするために非常に重要です。

AHVではネットワークのパスの統計や接続状況をPrism ウェブコンソールで追うことができるようにしてあります。単一のインターフェイスから管理者は仮想マシンを単独またはグループで仮想そして物理のネットワークパスに沿って確認することができます。Prismで仮想マシンの上の仮想NICからハイパーバイザーを経由して物理スイッチに至るまでを単一の見やすいポータルで確認することができます。この表示では異なる仮想マシン間の共通するパスを確認でき、以下の図に示すとおり、問題の切り分けを行うことができます。

Fig273

例えば、メールボックスサーバ1と2のネットワークパスがいずれも同じ物理スイッチを利用していることがわかります。パスの全てのホップにおいて、スループットとパケットエラーなどの統計情報を見ることができます。さらに、物理スイッチについてはSNMPを利用してその統計情報を取得し、情報をPrismインターフェイスで閲覧することができます。これらの統計情報によって、これらのメールサーバで共有されているスイッチ、上の例ではEthernet8がエラーを起こしているなどを見抜くことができ、ケーブルの交換を考えることができます。

パスと接続状況を確認することは可視化の素晴らしい第一歩です、そして、ネットワーク接続と状態についての概要をよく示してくれます。しかし、アプリケーションを本当に稼働させているのはネットワークのフローです。

ネットワークフローはIP、ポート、そしてプロトコルについて言及されることがほとんどで、アプリケーションとは完全に切り離されています(が、ファイヤウォールのルールを作るときには必要とされます)。Nutanixのアプリケーションポリシーとフローの可視化はこうしたフローをネットワークの文脈ではなくアプリケーションの文脈で言及してくれます。

以下の図にある通り、我々はExchangeアプリケーションへは定義されたグループからのトラフィックしか受け付けないというルールを作成しています。Nutanix AHVのフロー可視化はポリシーで定義されていないトラフィックの発生元が多くあることを示してくれます。ですから、ポリシーを変更して実際にアプリケーション内で送信、または受信すべきものだけに絞ることができます ー これは実際に有効にする前に実行できます。そして、ポリシーに違反するトラフィックのフローも簡単に見つけることができます。

Fig274

可視化によって、新しく定義しようとしているポリシーの影響範囲を確認することもできますので、実際にそれを適応する前に迅速に修正することもできます。 

後のマイクロセグメンテーションとセキュリティの記事でアプリケーションポリシーの作成については詳細をお話する予定です。 次の記事では自動化と統合を取り上げます。これを利用することでアプリケーションをネットワーク内に簡単に展開し、ネットワークと仮想化チームの間を長くたらい回しになるようなことにならずにすみます。

© 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

Ntc2017_2

さて、ネットワークについての記事です。NutanixのPrismが見やすい直感的なインターフェイスで、私がそれを大好きなことはこちらこちらでも取り上げています。特にネットワークについては近年の技術の革新も著しいですし、ネットワークの専門家でないのであれば、なかなかトラブルに出くわしたときにその問題の切り分けや原因を探していくことが難しいと思います。

そもそもネットワーク機器ベンダーさんの管理ツールが専門知識を前提にしすぎている、ということもあるかもしれません。

それを解決してくれるのがNutanix AHVのネットワーク可視化機能です。可視化されていることで何がどう間違っているのかはもちろんですし、フローの可視化の方はどんな通信が実際に行われているのかなどもわかりますのでとても直感的です。後の記事に出てくるようですが、表示されている本来は行われるべきでないトラフィックフローを遮断することもできます。非常に直感的ですね。

2016/11/29

Nutanix 5.0の機能概要(Beyond Marketing) パート1

本記事の原文はNutanix社のPartner Innovation and Vertical Alliances, Sr. Directorを務めるAndre Leibovici氏によるものです。原文を参照したい方はNutanix 5.0 Features Overview (Beyond Marketing) – Part 1をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

また、以下のセミナーでも本記事の内容を詳しくご説明しますので、是非ご来場ください!

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線
ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

AOS 4.7のリリースから5ヶ月が立ち、Nutanixは多くの新機能と改善点を備えたメジャーリリースヴァージョンをアナウンスしようとしています。AOS 5.0は社内ではエンジニアリングコードネーム「Asterix」と呼ばれていたものです。Nutanixによるその機能や改善のリリースのスピードはAWSやコンシューマー業界としか比べることが出来ないほどで、その素晴らしい更新のペースがユーザーを感動させています。このブログの記事ではもうしばらくでリリースされるNutanixのソフトウェアについてご紹介していきます。もしも以前のリリースについてのアナウンスを見たいのであれば以下を読んで下さい。

※訳注 4.7以外の記事についての和訳予定はありません。

本記事は本シリーズの1番目の記事です。2つ目3つ目4つ目

本記事では以下の機能についてご紹介していきます:

  • Cisco UCS B-シリーズ ブレード サーバ サポート
  • Acropolis アフィニティ と アンチ-アフィニティ
  • Acropolis ダイナミックスケジューリング (DRS++)
  • REST API 2.0 と 3.0
  • XenServerのサポート TechPreview
  • ネットワーク可視化
  • 新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)
  • ネイティブのセルフサービスポータル
  • スナップショット - セルフサービスリストアのUI
  • ネットワークパートナーインテグレーションフレームワーク
  • メトロアベイラビリティウィットネス
  • VMフラッシュモードの改善
  • Acropolis ファイルサービス 正式リリース (ESXi と AHV)
  • Acropolis ブロックサービス (CHAP認証)
  • AHVのOracle VM と Oracle Linuxへの認定
  • AHVのSAP Netweaver Stackへの認定
  • ・・・さらにパート2で

今後の数週間でプロダクトマネージャやプロダクトマーケティングマネージャチームが数々のブログ記事を書き上げ、もっと詳細なAOS 5.0の情報が出てきます。その一つ目がShubhika TanejaによるTen Things you need to know about Nutanix Acropolis File Servicesです。

免責事項 : あらゆる将来の製品又はロードマップ情報は製品の方向性を示すことを意図しており、Nutanixが提供するあらゆる情報、コード、機能に対してコミット、お約束、法的な義務が生じるものではありません。この情報を用いて、購入を決めるべきではありません。また、Nutanixは将来の製品改善、機能が最終的に利用できるようになった際に追加での課金を行うことや、最終的に改善された製品や機能のために別途の課金を行うことを現時点では決定していません。

機能や時間軸についてのオフィシャルな情報についてはNutanixのオフィシャルなプレスリリースをご参照ください。(こちら)

さて、法的な免責事項に目を通したら、さぁ、初めましょう!

プラットフォーム

Cisco UCS B-シリーズ ブレード サーバ サポート

本日、 .NEXT EMEAの中でNutanixは今後のCisco UCS B-シリーズ ブレード サーバのサポートについてアナウンス致しました、以前にアナウンスしたC-シリーズのラックマウントサーバのサポートに加えてのサポートです。

Fig092

現在、UCS B200-M4ブレードは物理容量3.2TBのオールフラッシュストレージに限定されています。フラッシュの制限によってストレージ容量の要件に見合わないという事が多くの場合でいえます。Ciscoや他のハイパーコンバージド製造メーカーは結果としてそのソリューションをラックマウントサーバに限定してきました。

NutanixはB-シリーズブレードのストレージ容量の不足の問題をストレージ専用ノードをB-シリーズのブレードのクラスタに追加することで解決させました。リリース後はオールフラッシュのC240-M4SXのストレージ専用ノードをクラスタに追加することが出来、最大でノードあたり24本まで1.6TBのSSDを追加することが出来ます。Nutanix固有のコンピューティングとストレージを異なった割合で自由自在に組み合わせられるという能力がこれを実現しました。

ストレージ専用ノードはUCSのお客様のブレードとC240間でのバランスのチューニングも実現することになります。更にはコンピューティングとは独立したストレージの拡張も実現します。古い筐体が容量が一杯になる度に新しいストレージ装置に巨大な投資を行うのではなく、お客様は必要に応じて順次環境を拡張して行けるようになるのです。

ストレージ専用ノードはNutanix AHVを利用して動作しています、ですから、追加で仮想化ソフトウェアのライセンスのためのお金が必要になるということはありません。AHVのストレージ専用ノードはESXiのノードと同じクラスタ内に混在させることが可能です。

Fig093

AMF(Application Mobility Fabric - アプリケーション モビリティ ファブリック)

Acropolis アフィニティとアンチ-アフィニティ

仮想マシン-ホストの固定アフィニティ

管理者が特定のワークロードが同一ホスト内で動作する事を保証したいという場合。例えば、多くの会社では、アプリケーションを仮想マシン内で動作させていますが、特定のアプリケーションはライセンシングの規約から、特定のホストに紐付いているということが有ります。管理者は仮想マシンに対してホストアフィニティルールを設定し、これらの仮想マシンを特定のホストで動作させ、他のホストへと移行しないようにすることが出来ます。

  • Acropolisは以下のHAやメンテナンスモードの最中の仮想マシンをサポートすることが可能です。
    • 予約モードのHAでは、仮想マシンの再起動のためのリソースが別のアフィニティホスト上に予約されます。Acropolisはこの予約が保証されない場合には仮想マシンの電源が入ることを許可しません。
    • ベストエフォートのHAの場合、Acropolisは別のアフィニティホスト上で再起動が出来ない場合、仮想マシンの電源をオフにします。
    • メンテナンスモードの場合、Acropolisは仮想マシンが別のアフィニティホストへと退避できない場合には仮想マシンの退避を行いません。

仮想マシン-仮想マシン 優先的アンチ-アフィニティ

特定の仮想マシン同士が同じホストで動作するべきではないと言う場合です。例えば、殆どの組織ではドメインコントローラーはいかなる場合においても最低一つは残って稼働し続けて欲しいという要件があります。このために組織はパフォーマンスの観点からは同じホストで仮想マシンが動作するほうが良い結果になる場合であっても、仮想マシン同士にアンチ-アフィニティルールを設定し、仮想マシン同士が別々のホストで稼働するようにというルールを設定します。

  • 結果として
    • 仮想マシンは優先的アンチ-アフィニティポリシーを持つ。
    • スケジューラーによる配置の最中はポリシーに違反することもある。
    • もしDRSが違反を解消できない場合、警告が発報される。

アフィニティの説明はこちらも参照ください。http://www.virtualizationadmin.com/blogs/lowe/news/affinity-and-anti-affinity-explained.html

Acropolis ダイナミック スケジューリング(DRS++)

システム管理者はDRSのコンセプトは既にご理解いただいていると思います。DRSはコンピューティングワークロードを利用可能な仮想化環境内のリソースでバランスします。- 今日DRSはほとんどの仮想化スタックの一部といえるようになっています。

DRSはキャパシティプランニングと密接に関係しています - キャパシティプランニングはより長い時間軸を対象としたものであるという例外はありますが、DRSによる最適化はキャパシティの制約がある環境で、もっと短い間隔で実行されます。

AHVのダイナミックスケジューリングは最初は既存のDRSの実装とさほど大きく変わるものでは無いかもしれませんが、Nutanixは要素としてコンピューティング、メモリ、そしてストレージのパフォーマンスをも配置決定の考慮に加えます。Nutanixの管理者はAHVのDRSがリソース(CPU、メモリ、そしてストレージIO)の競合やその後の一時的なリソースCPU、メモリ、ストレージIOの競合を事前に回避(または、回避のための推奨事項の生成)して、仮想マシンの電源を入れてくれるので「心の平穏」をもって管理に当たることが出来ます。

REST API 2.0 と 3.0

NutanixのREST APIについての大きな変更が今回のヴァージョンに含まれており、これにはAPIのヴァージョン、後方互換性、APIの衛生化、そして標準化が含まれています。さらに、新しいREST 3.0もプラットフォームの一部として含まれています。

REST 3.0はスケールアウトを意図して作られているAPIであり、組み込みのロードバランサのゲートウェイとして動作します。実装の実際のスキーマ(これは変わる可能性があります)詳細を実現するのではなく、REST 3.0は高いレベルでのユーザーの意図する実際のユースケースのコンセプトを規定するものです。

ユーザーの意図をマッピングすることで ー つまりユーザーが実現したいことをマッピングすることで、NutanixはAPIをパラメーターをセットするだけで与えられた操作を実行できるようにする機会を得ることが出来るのです。Nutanixがここで実現したことは大変なNutanixに固有のビジネスロジックをその呼出元から削除し、Nutanix内部(あるべき場所)へ配置したということです。

新しいNutanix APIポータルは既に利用できるようになっており、開発者は古いものや新しいREST 3.0の意図する仕様を直ぐに見ることが可能です。ポータルではPython、Java、Go言語、PowerShellのサンプルが提供されており、http://developer.nutanix.comまたはhttps://nuapi.github.io/docsでアクセスできます。

Fig094

XenServerのサポート TechPreview

Fig095

これはアナウンスの再掲載となりますが、NutanixはXenServer上で動作しているXenApp、XenDesktop、NetScaler VPXそして、NetScalerを含むCitrixのアプリケーションに対するサポートをNutanixプラットフォームに上で提供することになります。AOS 5.0からXenServerのお客様はXenServer 7をテクニカルプレビューとしてNutanixプラットフォーム上で動作させることができるようになるのです。

プレスリリースについてはこちらをご参照ください。

Prism

ネットワーク可視化

もしもネットワークが誤って構成されたら、アプリケーションの仮想マシンは動作を止めるか、パフォーマンスの低下が起こります。例えばVLANが誤って構成された場合、アプリケーションはそれぞれお互いに通信ができなくなります。ネットワーク構成の不整合、例えばMTUの不整合やリンクスピードの不整合などが起こると、大量のパケットのドロップによってパフォーマンスの劣化が起こります。

ネットワークの問題のトラブルシューティングを難しくしているのは単一のネットワークのパス上にあるすべてのスイッチの構成のミスが原因を作り出す可能性があるからで、管理者はトラブルシューティングを行う際にネットワーク全体の構成を見なくてはならなくなるからです。

これがまさにネットワーク可視化が解決しようとしていることです。各々の仮想マシンから仮想スイッチ、物理ホストのネットワークカード、TOR(トップオブラック)スイッチなどに至るまでのネットワーク全体の表示を提供します。VLAN構成などのネットワーク構成の要素情報も直感的で使いやすいインターフェイスに表示します。管理者は例えば、ユーザーやプロジェクトやホストにグルーピングしながらネットワークを簡単に探索できます。

NutanixはLLDPと/もしくはSNMPを利用してネットワークトポロジを検証します。構成情報をスイッチから取得するためにSNMPを利用します。例えば、ネットワーク状態に加え、それぞれのポートのVLAN情報を収集するためにはSNMPを利用します。一旦仮想と物理のネットワーク要素から構成や統計とともにトポロジの情報を収集し終わると、Nutanixは利用しやすいインターフェイス上にその情報を表示します。(最初のリリースではAHVのみで動作します。)

Fig096

Fig097

新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)

Pay as you go(必要なだけ支払う)

  • クラスタ内であとどれだけの仮想マシンが動作するか?
  • もし1ヶ月後に新しくSQLサーバを追加するとしたら、クラスタは大丈夫か?
  • もし、現在のペースでワークロードが増え続けたらクラスタはいつまで大丈夫か?
  • 一定のワークロードがあり、新しくクラスタを作りたいがどのようなクラスタが必要か?

What-if分析は新しく将来に追加されるワークロードをその追加の時期とともに指定するものです。既存の仮想マシンを例えば、既存の仮想マシンと同じインスタンスが10個追加されたとしたら、という具合に指定することも出来ます。または、既存のワークロードとの差異を%で指定することも可能です。そして、ワークロードの拡張と縮退の両方を指定することが出来ます。そして、ついに、事前定義されたよくあるワークロードをその一つとして指定することが出来るようになりました。

たとえば、ビジネスクリティカルな中規模サイズのOLTPのSQLサーバのワークロードを指定したりすることが出来、what-ifツールはそのワークロードのサイズを見積もることが出来ます。what-if分析ツールは正確なサイジングの見積もりを行うことが出来る理由は、このツールが我々が最初の導入時に推奨構成を割り出すためのNutanixのSizerと統合されているからです。つまり、what-if分析ツールは様々な事前定義されたSQLサーバやVDI、Splunk、XenAppなどのワークロードを利用することができるのです。

Nutanixは既にランウェイ(将来予測)コンポーネント表示を提供していますが、これはキャパシティプランニングのアルゴリズムで異なる様々なリソースのランウェイ(将来予測)を予測し、クラスタ全体のランウェイ(将来予測)を予測しているのです。これを下に、what-if分析は管理者にどうしたノードを追加するべきだという推奨事項を、いつまでに追加するべきだという情報とともに提示することが出来、ランウェイ(将来予測)が本来のランウェイ(あるべき姿)にまで拡張されるようにすることが出来るのです。

一度ワークロードとハードウェアを追加すれば、システムは推奨事項を提示します。what-ifのUIに表示されるものを皮切りに変更やチューニングを行うことも可能です。例えば、様々なハードウェアの推奨構成の追加のタイミングを予算上の制限と調整を行い、ランウェイがどのように変化するのかを見たり、同様にワークロードの追加のタイミングを調整したりすることが出来ます。プライオリティの低いワークロードであれば後からということも有りますよね。あなたにとって最適なワークロードとハードウェアのプランが出来るまで好きなだけチューニングを行うことが出来ます。

Fig098

Fig099

Fig100

Fig101

Fig102

Fig103

Fig104

Fig105

Fig106

Fig107

Fig108

ネイティブのセルフサービスポータル

AOS 4.6ではAHVへのNova、Cinder、Glance、そしてNeutronのドライバーの提供によってOpenStackのサポートが導入されました。OpenStackはマーケットに広く受け入れられつつ有り、Nutanixと完璧に協調動作しますが、OpenStackはネイティブなNutanixソリューションではなく、OpenStackはそれを支えるあらゆるインフラストラクチャとともに動くように作られているため、多くのNutanixの先進的な機能を活用できるようにはなっていません。

NutanixのネイティブなセルフサービスポータルはPrismに統合されており、ITリソースへのアクセス、ポリシー、セキュアなテナントベースのアクセスを実現します。ポータルによってテナントはIT(情報システム部)の介在なくアプリケーションを展開でき、組織は開発者やテナントへAWSのセルフサービスに似たエクスペリエンスを提供することが出来るようになります。

管理者ポータル

  • プロジェクトの作成/管理
  • ユーザーとグループの作成/追加
  • リソースのアサイン
  • アクションのアサイン
  • ショーバックレポートの実行

テナントポータル

  • カタログ(仮想マシンテンプレート、vDisk、Docker Hubのイメージ、アプリケーションテンプレート)からのアプリケーションの展開
  • アプリケーションの監視
  • アプリケーションのリソース利用率の監視

Fig109

スナップショット - セルフサービスリストアのUI

Nutanix AOS 5.0はついに仮想マシンのユーザーがファイルレベルでリストアを行うためのユーザーベースのPrism UIを追加しました。この機能によってユーザーは自身の仮想マシンのファイルやフォルダの復元をセキュアにまた、管理者の手をわずらわせることなく行うことが出来ます。

Fig110

Fig111

Fig112

本日、ウィーンで実施された.NEXTカンファレンスでNutanixはネットワーク接続サービスとネットワークパケット処理サービスを統合、拡張された新しいネットワークのフレームワークについてもアナウンスを行いました。

ネットワーキング、セキュリティパートナーの製品を活用することが出来るサービスの挿入、チェイニングそしてウェブフックの組み合わせによって提供される壮大な可能性を秘めた機能です。

パートナーと共に現在開発中の幾つかのユースケースは:

  • ネットワーク展開のワークフローと対応するNutanix上のワークロード展開のワークフローの自動化
  • パートナースイッチへのオンデマンドでのVLAN展開の自動化
    • アプリケーション(幾つかの仮想マシンの組)がNutanix上で起動する際に、対応する物理ネットワークスイッチが自動的にそのワークロードのための適切なネットワーキングポリシーのもとに構成される
    • Nutanix上からアプリケーションが削除される際に、対応したネットワークポリシーが自動的に物理ネットワークスイッチから削除される
    • Nutanix上の仮想マシンがNutanixクラスタ内の別のホストにライブマイグレーションされる際(同じTORの別のポートや別のスイッチへ接続されている可能性がある)に、対応する以前利用していたスイッチとこれから利用するスイッチの両方に変更を適切にネットワーク構成を行う
  • ネットワークの「仮想マシンからみた表示」をNutanixに収集しパートナースイッチベンダーの情報を元に表示、つまりネットワーク管理者がパートナーのスイッチを管理できるように
  • 「仮想マシン中心」のネットワークの運用表示を提供し、ネットワーク管理者による物理ネットワークのトラブルシューティングをより迅速、より正確なものにする。ネットワーク管理者はパス、フローの追跡、仮想マシン名、タグ、ラベルに対応する統計情報によって根本原因の解析を迅速に行えるようになる。このインテリジェンスはNutanixによって、物理ネットワークデータベースへ仮想マシンの特徴(仮想マシン名と紐付けられたラベル、そして仮想マシンのIPアドレスとMACアドレス情報)として提供されます。
  • LLDPによるトポロジのディスカバリのサポート(Nutanixのノードと対応するTORスイッチノードとのマッピング)

Fig113

単一ネットワークパケット処理(Network Packet Processing - NPP)サービス挿入

NPPはクラスタ全体にサービス挿入し、ネット枠サービスがAHVクラスタ上で動作することを実現するネットワークのフレームワークの一つです。NPPは以下をサポートします:

  • パートナーサービスのイメージとプラグインの登録ワークフロー
  • サービスの展開 - クラスタ全体またはクラスタ内のサブセットに対して
  • ネットワークレベル挿入 - 通信内への割り込みとタップモードでの挿入モード
  • ゲストOSのライフサイクルイベントのプラグイン起動によるパートナーサービスへの通知
  • 対象となる仮想マシンのプロパティの通知 - ネイティブなプロパティ(IPとMACアドレス)とメタデータプロパティ(ラベル、カテゴリ、名前)の両方をサポート
  • サービスへの選択的なトラフィックのリダイレクト(ゲストOSの仮想NICの一部を指定)

パケット処理サービスチェイニングフレームワーク

Nutanixのネットワーキングパートナーは今日ではパケットがAHVネットワークを流れていく際にそれを検査し、変更するか、または廃棄してしまう機能を利用できます。サービスチェインフレームワークはAHVの仮想スイッチを自動構成し、パケットをNutanixパートナーによって提供されてるパケット処理(パケットプロセッサ)仮想マシンイメージやサービスへとリダイレクトするようにします。それによって利用できるサービスは:

  • インライン処理 - プロセッサが仮想スイッチ経由で流れてくるパケットの変更又は廃棄
  • タップ処理 - プロセッサが仮想スイッチ経由で流れてくるパケットを検査する
  • プロセッサチェイン - 複数のプロセッサを利用、同一ベンダまたは複数ベンダで利用できる、別々のサービスを提供するそれぞれをつなげて(チェインして)利用できる

ウェブフックベースのイベント通知(ネットワークオーケストレーション)

Nutanixのネットワーキングパートナーはいつであれウェブフックのイベント経由でクラスタ、ホスト、仮想マシンで発生したイベントの通知を受けとり、すぐに対応することが出来るようになりました。例えば、あるネットワーキングパートナーは仮想マシンネットワークのVLANが変更されたり、仮想マシンがライブマイグレーションして別のホストへ移動した際にパケット検査のポリシールールを適応するようにという警告を上げたいとします。ウェブフックを利用することでパートナーは非常に先進的な問題解決方法を実装し、そのワークフローによって全データセンタを自動化することが出来るようになります。

Fig114

既に統合の終わっているパートナーのデモを幾つか御覧ください。

Brocade

Mellanox

分散ストレージファブリック(Distributed Storage Fabric - DSF)

メトロアベイラビリティウィットネス

Nutanixのメトロアベイラビリティはデータセンタ全体に及ぶ復旧に対してもシングルクリックで優れた仕事をしてくれます。しかしながら、いくらかのお客様はサイト障害なのか、もしくはネットワーク接続障害なのかが明言できない問題であるため、自動的な復旧についての機能を欠いていると感じておられました。ビジネスクリティカルアプリケーションを利用しており、DR手順を実行できるITスタッフがいない場合にはことさらです。

以前はNutanixは自動復旧の機能を備えていませんでした。これはサイトの障害とネットワークのそれの区別を行うことができなかったからです。AOS5.0はこの問題をウィットネス(証言者)仮想マシンを障害ドメインの外側に置くことで解決しました。このウィットネス仮想マシンはそれぞれのメトロサイトとメトロサイトの内部通信とは異なる通信を行い、メトロアベイラビリティにおける復旧の決断の自動化に役立てます。ウィットネス仮想マシンはメトロクラスタ間で自動的にリーダー選出を行うことで、スプリットブレーンシナリオの回避にも役立ちます。

Fig115

VMフラッシュモードの改善

VMフラッシュモードはPrism UIに戻って、更に改善されました! 仮想マシンフラッシュモードは管理者がハイブリッドシステムにおいて、レイテンシが重要となるミッションクリティカルなアプリケーションが動作している特定の仮想マシンをSSD層に置くことを実現します。改善点はハイブリッドシステムにおいて、重要な仮想マシンにオールフラッシュの一貫したレイテンシとIOPS、サービスプロバイダのためのQoSによる階層化やより高いIOPSを提供することです。以前VMフラッシュモードについて記事を書いていますので、興味があれば詳細はそちらへ。

Fig116

Acropolis ファイルサービス(AFS)

Acropolis ファイルサービスがいよいよ正式リリース (ESXi と AHV)

Acroplis ファイルサービス(またの名をAFS)はDSFにネイティブに統合されたコンポーネントであり、Windows ファイルサーバや外部のNetAppやEMC IsilonなどのNASストレージ装置を不要にするものです。AFSはAOS 4.6、4.7ではTech Preview扱いでしたが、AOS 5.0ではいよいよESXiとAHVハイパーバイザ上で正式リリースとなり、Nutanixのサポート対象として本稼働環境で利用できるようになります。

Acropolis ファイルサービス (非同期-DR)

AFSはNOSの非同期-DR由来のネイティブのデータ保護を提供します。仮想マシンとヴォリュームグループは保護ドメインを利用して保護され、他のすべてのDR関連の操作と同様にスナップショットのスケジュールやポリシーを保護ドメイン自身に適応することが可能です。

Acropolis ファイルサービス (AFSクオータ)

AFSはハード、およびソフトのクオータ制限が利用でき、メールによる警告の設定もできるようになりました。ハード制限を利用している場合、クオータを超えることは出来ず、もしもクオータ制限を超えるようなファイルの書き込みが発行された場合、その書き込みは失敗に終わります。ソフトクオータ制限を利用している場合、警告が利用者に送信されますが、データの書き込みは許可されます。

クオータのポリシーはクオータがユーザーか又はグループに対するものか、クオータの制限(GBでのサイズ指定)、クオータのタイプ(ハード または ソフト)、そしてクオータイベントをユーザーに通知するかどうかというルールの組み合わせて指定します。ポリシーの適応は1人のユーザーまたはADグループを含む特定のグループのすべてのユーザーで行うことが出来、標準ポリシーはユーザーもグループも指定されていない場合に適応されます。

Fig118

Fig119

Acropolis ファイルサービス (アクセスベースの一覧 - ABE)

AFSのアクセスベースの一覧では、ユーザーがアクセスの出来る権限を持つファイルとフォルダのみが表示されます。もし、ユーザーがRead(もしくはそれ相当)の権限をフォルダに対して持っていない場合、Windowsは自動的にそのフォルダをユーザーの表示から隠します。ABEはユーザーの共有フォルダの表示をREADアクセス権限によってコントロールします:

  • FIND(ディレクトリ一覧)を利用した場合の応答でユーザーがアクセスできるファイルシステムオブジェクトのみを表示
  • 機微なファイル、フォルダのタイトルをREADアクセス権のないユーザーから隠す
  • 共有レベルの構成パラメーター("hide unreadable(Read権がなければ隠す)")
  • トップレベルフォルダであるHOMEシェアの特別な取り回し

Acropolis ファイルサービス(パフォーマンスと拡張)

AFSは4CPU/16GBの仮想マシンのVMFSあたり500以上の接続が出来るように最適化されました。小さな3ノードで構成されるAFSクラスタでも最大6千万のファイル/ディレクトリまでのファイルサーバにまで拡張することができます。

Acropolis ファイルサービス(パフォーマンス最適化の推奨)

AFSは分散システムとして実装されているため、他のFSVMはアイドル状態にあったとしても幾つかのノード(FSVM)に負荷が偏る可能性があります。そのアクセス不可をノード間または追加のリソースで再分配することでAFSはクライアントにより良いパフォーマンスを提供できます。AFSは平均CPU利用率、SMB接続の数、メモリ割り当て構成、ヴォリュームグループのRead/Writeの利用帯域などを含むの多くの計測値を利用して利用状況を把握し、負荷のバランスを取って解決方法を決定します。

解決策には以下の可能性がありえます:

  • ヴォリュームグループの移動 : いくつかのヴォリュームグループを「ホットな」FSVMから対比し、負荷を下げる
  • スケールアウト : 既存のFSVMが忙しい場合には新しいFSVMを作成しヴォリュームグループを保持させます
  • スケールアップ : CPUとメモリリソースを全てのFSVMに追加します

推奨事項が生成された後に、「Load Balancing」というボタンがファイルサーバタブのRecommendationカラムに表示されますが、管理者はその推奨事項を選択することも、別のもので上書きすることも出来ます:

  • ヴォリュームグループの移動をスケールアップで上書き
  • スケールアウトをスケールアップで上書き
  • スケールアップの推奨事項は上書きができません

一度ユーザーがロードバランスアクションを選択するとタスクが生成されアクションが実行されます。

Fig120

Fig121

Acropolis ブロックサービス(スケールアウトSAN)

Acropolisブロックサービスは高い可用性、拡張性、そして高パフォーマンスのiSCSIブロックストレージをゲストへと提供します。ABSはAcropolisヴォリュームグループサービス上に構成され、AOS 4.5以降利用が可能です。ヴォリュームグループはブロックストレージを提供し、NFSデータストアではサポートされない、もしくはブロックストレージのインスタンス間での「共有」が要件となるようなエンタープライズアプリケーションにとってはとても重要な機能です。ユースケースとしてはESXi上のMicrosoft Exchange、Windows 2008ゲストクラスタリング、Microsoft SQL 2008 クラスタリング、Oracle RACなどがあります。

Acropolis ブロックサービス (CHAP 認証)

  1. Challenge-Handshake Authentication Protocol(CHAP認証プロトコル)
  2. 共有の"秘密"の認証コードと接続元
  3. 相互のCHAP – クライアントがターゲットを認証
  • CHAPは識別子とその試行値を順次変更し、接続元が「録画再生」型の攻撃を仕掛けてくることに対する防御を提供します。CHAPを利用する場合、クライアントとサーバが平文の秘密鍵を知っている必要があり、もちろんこれはネットワーク経由で送っては絶対にいけません。
  • 相互のCHAP認証。ターゲットとイニシエータが相互に認証しあうというセキュリティのレベル。別々の秘密鍵を相互にターゲットとイニシエータにセットします。

その他のABSの改善点:

  • ダイナミックロードバランシング
  • ヴォリュームグループのフラッシュモード
  • IPベースのイニシエータのホワイトリスト
  • イニシエータの管理
  • 幅広いクライアントのサポート - RHEL 7, OL 7, ESXi 6
  • オンラインでのLUNのリサイズ

ワークロードの認定

NutanixはAHVがABS上でOracle VMとOracle Linuxの認定を得たこと、そしてSAP Netweaver stackの認定を得たこともアナウンス致しました。これはビジネスクリティカルアプリケーションをNutanixプラットフォーム上に移したいと考え、OracleとSAPのサポートを待っていたエンタープライズのお客様にとって恋い焦がれたニュースでした。

Fig122

また、本日NutanixはAHVの1-クリックでのネイティブなマイクロセグメンテーションをあなうんすしています。しかしながらこの機能は今後のリリースに含まれることになります。機能と公式な時間軸についての情報はNutanixの公式プレスリリースをご参照ください(こちら)。

Fig123

なんとまぁ、長い機能リストでしょうか、しかも、これで全部ではないのです・・・。直ぐに更に多くの機能で満載のこの記事の第2弾をリリースします。お楽しみに!

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

久しぶりのAndreさんの記事ですが、ようやく公開することが出来ました。先週までのPrismの記事ではとことんまで突き詰めるコダワリを感じさせるものでしたが、今回の内容は正に怒涛のようにリリースされる新機能の嵐。

記事の最初の方にも有りますが、これほどの機能追加はコンシューマー向けのアプリケーションやAmazon Web ServiceやSales Force.comなどのクラウドでしか見ることが出来ません。ストレージ機能はブロック、ファイルサービスと既存のストレージベンダーを置き換えるものになりつつありますし、新たに加わったネットワーキングについてもかゆいところに手が届いている感じ、これが一番必要だよね、というどストレートな機能を直球勝負です。エコシステムパートナーとの連携を見ているといよいよHCIというインフラを脱して完全に「プラットフォーム」になってきていると思います。

やっと訳し終えたのに、Andreさんはもう次の記事に取り掛かっているそうです。次はタイムリーに公開できるようにがんばります!

2014/09/22

VMware NSXの営業向け資格を取得しましょう! (VSP-NV)

皆様、いかがお過ごしですか? ネットワーク仮想化していますか?

コレまでかなり情報の提供先が制限されていたVMware NSXの営業向けの認定資格であるVSP-NVがe-learningでオープンになりました。

例によって、ネットワールドはどこよりも早く「日本語」で本資格の取得ブートキャンプをご提供いたします。本資格に加え、VTSP-NV, VCP-NVを取得したメンバーを揃えることでVMwareパートナー様は「ネットワーク仮想化ソリューションコンピテンシー」も取得できるようになる見込みです。

ぜひふるってご参加を!

Vspnv