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/09/06

HyperFlexのバックアップはVeeamにお任せ!2017

シスコ社のHCIであるHyperFlexのバックアップにはVeeam Backup & Replication(以下、VBR)で間違いないことは、前回お伝えしましたが、最新のVBR 9.5 Update 2では、更に進化し、HyperFlexのネイティブスナップショットとの連携が可能になりました!

VBRの特徴の1つであるストレージスナップショット連携は、これまでもDell EMC/NetApp/Nimble/HPE などのハードウェアストレージには対応しておりましたが、HCIのSDS(Software-Defined-Storage)としては、HyperFlexが初の対応です。

そんなHyperFlexですが、7月末にHyperFlexの最新バージョンである2.5がリリースされました。早速、HyperFlex 2.5(1b)とVBR 9.5 Update2の組み合わせでHyperFlexのネイティブスナップショットとの連携によるバックアップを試してみましたので、ちょっとご紹介しましょう。


まずは、HyperFlexの登録です。VBRの管理コンソールを起動し、[STORAGE INFRASTRUCTURE]で [Add Storage]をクリックします。 
Vbrhx01_3



「CISCO HYPERFLEX」をクリックします。
Vbrhx02_3



HyperFlexの管理用のIPアドレスを入力し、[Next]をクリックします。
Vbrhx03_3



HyperFlexの管理者ユーザー(admin)の認証情報を設定し、[Next]をクリックします。

Vbrhx04



そのまま[Next]をクリックします。

Vbrhx05



サマリーを確認して、[Next]をクリックします。HyperFlexのバージョン情報(2.5.1b-26284)も認識しています。
Vbrhx06



登録処理が実行され、登録が完了します。Vbrhx07_4



バックアップを実行してみたところ、HyperFlex スナップショットの作成と削除のメッセージが表示され、スナップショット連携のバックアップが成功しました。 

Vbrhx09

 

バックアップ中に仮想マシンのスナップショットを確認すると、「SENTINEL」というスナップショットが作成され、その下にVeeamによるテンポラリのスナップショットが作成されています。「SENTINEL」というスナップショットはHyperFlexのネイティブスナップショットを使う際に最初に作成されるスナップショットのため、VeeamからHyperFlexのスナップショットを呼び出していることが分かります。

Vbrhx10a_2


何故、HyperFlexのネイティブスナップショットと連携できると良いのか?HyperFlexとVBRを組み合わせるとどんなリットがあるのか?ピンと来ていない方は、下記のセミナーに参加いただけると、きっとお分かりいただけると思います。東京・名古屋・大阪・福岡で開催しますので、是非ご参加ください!

シスコの爆速堅牢なハイパーコンバージドインフラご紹介セミナー

https://networld.smartseminar.jp/public/seminar/view/814


このセミナーでは最新のHyperFlex 2.5の情報もお伝えします。HyperFlex 2.5では専用の管理ツールのHyperFlex Connectやレプリケーション機能など新機能が盛り沢山ですので、ご期待ください。これからHyperFlexを提案や導入しようとしている方は必見ですが、既にHyperFlexをご利用いただいている方のご参加もお待ちしております。

Vbrhx11_2



最後に、Ciscoと Veeamと言えば、アプライアンスの下記キャンペーンも好評につき、キャンペーン期間を延長しましたので、こちらも併せて宜しくお願い致します。http://www.networld.co.jp/campaign/cisco_veeam_backup/

 担当:臼井

より速く、より高密度に、より良く ー 拡張性による低遅延を再定義(Nutanix G6モデル)

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のPurush Lala Balaji氏 Amit Jain氏 そして Thenu Kittappa氏によるものです。原文を参照したい方はFaster, Denser, Better - Redefining Low Latency at Scaleをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

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

本日、Intel®社は登場が待ち望まれていたIntel® Xeon® スケーラブル プラットフォームを発表しました ー システムの今後のあり方を変えると我々が信じるテクノロジーのうちの一つが今後組み込まれ、販売されることになります。それと市場をリードするNutanixのソフトウェア定義のインフラストラクチャ組み合わせることで ー 皆様はより強靭なエンタープライズクラウドプラットフォームを手に入れることになるのです。

Nutanixは真のエンタープライズクラウドのエクスペリエンスを提供することで、利用の簡単さ、統制の中でのパブリッククラウドの俊敏で迅速なイノベーションと経済性によるメリット、そしてオンプレミスで近くにおけるメリットを融合させることにフォーカスしてきました。我々はこの旅路をハイパーコンバージドインフラストラクチャ(HCI)の先駆者としてスタートさせ、それをさらに業界標準のプラットフォーム上へソフトウェア定義のスケールアウトソリューションを提供することでエンタープライズクラウドの提供をリードしています。Intel®アーキテクチャ、インテルのネットワーキング、インテルのソリッドステートストレージそして、オープンな管理によって、過去Nutanixはお客様の求める高い信頼性、堅牢性、そして性能に見合うまでスケールアウトできるソリューションの開発を実現し、それと同時に様々なフォームファクタでのアプライアンスを開発することで対象となるアプリケーションの要件に合うほどまでスケールアップできるようにしてきたのです。インテルとの緊密なパートナーシップとx86エコシステム内へ参加することで、Nutanixはインテルの殆どの新しいアーキテクチャ上の、そして一枚岩のイノベーションを活用できる状況です。

Fig275

我々はIntel® Xeon® スケーラブル プロセッサの初期の登場に立ち会え、さらに将来登場するG6シリーズのアプライアンスがこのプラットフォームをベースとして開発されたものであることを喜ばしく思います。Intel Xeon スケーラブルプラットフォームとIntel® Optane™ SSDをベースにしたストレージは今日のHCIが抱える根本的な問題を解決することができます:

コンピュート:
Intel Xeon スケーラブル プロセッサは最大それぞれのソケットあたり28Cという巨大なコア数(extreme core count - XCC)をもたらし、これによってNutanixは従来からのVDIから高トランザクションのデータベース、そしてインメモリデータベースに至るまでの無数のアプリケーションを対象とすることができるようになります。高密度なVDI、高いスループットのデータベース、低遅延のインメモリDBの動作を妨げる今日の仮想化高速化アーキテクチャをメモリの帯域とスピードを改善することで進化させています。Nutanixのコントローラーはプロセッサの効率性と、ユーザーがアプリケーションを動作させるためのコンピューティング能力をより多く返す先進的な命令セットを利用できるようになります。プロセッサはコンピューティング/メモリの密度というHCIの根本的な課題を解決するのにも役立ちます。

ストレージメディア:

本プラットフォームでは3D Xpoint™テクノロジーをベースとしたIntel Optane SSDと低遅延ストレージを実現するための高速なNVMeインターフェイスを融合されており、これはNutanixのサーバーにフラッシュを接続するというアプローチに合致し、業界最高のアプリケーションのキャッシュと階層化をこれまで以上に改善することができます。

ネットワーキング/インターコネクト:

Intel Xeon スケーラブルプラットフォームとそこに組み込まれたIntel® QuickAssist テクノロジーとDPDKのようなの高速化技術によって提供される広帯域、低遅延のファブリックは俊敏なNutanixのAMF、そして分散ストレージファブリックをより優れたものにしてくれます。

インテルの技術とイノベーションは強力な新しいコンピューティングの機会を提供します。その中にはハイパーコンバージェンスの幕開けの実現も含まれています。エンタープライズクラウドは日に日により多くの会社組織、そしてより多くのワークロードで利用されるようになっており、その成長は継続すると予想されています。この成長はインテルの最新のリリースのようなイノベーションを更に継続的にもたらすことでしょう。Nutanix AcropolisソフトウェアによってIntelのXeonスケーラブルプロセッサとそのプラットフォームが提供するテクノロジーはほとんど限界のないエンタープライズアプリケーションの可能性を提供することになるでしょう。新しいインテルプロセッサプラットフォーム上に構成された我々のG6シリーズのアプライアンスが登場すれば、Nutanixと我々のお客様は膨大なデータとコンピューティングを利用する分析やML/AIのような、更にビジネスクリティカルなワークロードを含む更にビジネスクリティカルなワークロードにも対応ができるようになります。もしもハイパーコンバージェンス上に構成されたエンタープライズクラウドからどのようなメリットを享受できるのかを検討しているものの、まだ踏み出せていない、もしくは更に今日までにやってきたことを拡張していくための追加の要因を探しているのであれば、ぜひ会話に加わって下さい。今こそがインテルの新しいイノベーションと.NEXTで先日発表された Nutanixのイノベーションを融合させてどんな先進的なことができるのかという議論を始めるべきタイミングだからです。

 

Forward Looking Statements

This blog includes forward-looking statements concerning our plans and expectations relating to the development of a new hardware platform, called G6, and the capabilities and features to be included in the platform. 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; 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 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 blog 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, the Nutanix logo, and the Enterprise Cloud Platform are trademarks of Nutanix, Inc., registered or pending registration 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

今回はインテルとのエコシステムの記事からです。和訳時点では先日となりますがインテルのスケーラブルプラットフォームが発表され、そしていくつかのサーバーベンダーが既にそれをベースとしたプラットフォームを発表しています。Nutanixもその例に漏れず新しいG6プラットフォームをリリースする予定ですが、今回の記事はその新しいG6プラットフォームをちょっと覗き見るような内容になっています。

優れたプロセッサとその内部に融合されたチップセットにより様々な遅延要因が解消されており、メモリの帯域はもちろん、SSD(といってもNVMe接続ですので、実質メモリ扱い)へのアクセスも高速化されています。CPUの直ぐ側にデータを置いて処理するまさにそんなアーキテクチャで、ハイパーコンバージェンスのためのプラットフォームと言えるでしょう。

記事公開時点ではもうリリースされているかもしれませんが、G6プラットフォーム、期待しましょう!

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

2017/08/23

HCIとパフォーマンス計測の美学 ー パート2 ー Microsoft SQL Server

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Technical Marketing EngineerであるAndy Daniel氏によるものです。原文を参照したい方はHCI and the Art of Performance Measurement - Part II - Microsoft SQL Serverをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

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

Fig271

本シリーズのパート1で、Enterprise Strategy Group(ESG)と共同で行った、Nutanixエンタープライズクラウドプラットフォーム上での4つのエンタープライズクラスでミッションクリティカルなアプリケーションのワークロードについてのパフォーマンスの一貫性、予測性、そして拡張性についての背景を共有いたしました。他のベンダーが公開しているような人工的に生成された単純なI/Oを用いる「英雄の数字」とは異なり、我々は業界の標準となるアプリケーション検証ツールを利用して、現実的なワークロードを使うことにフォーカスしていたことを思い出して下さい。パート2では、我々はMicrosoft SQL Serverを利用した検証について、更に奥深く分け入りたいと思います。

検証のためのワークロードを選ぶ際に我々はデータとお客様からのフィードバックに大きく依存しています。SQL Serverは最も展開されているエンタープライズ・アプリケーションのリストのトップにおり、これは大した驚きでは無いでしょう。様々な場面で利用されていますから、そのパフォーマンスの要件も幅広いものとなります。ですから、検証のためにリファレンスとしての標準が必要となります。幸い、オンライントランザクション処理(OLTP)のような一般的なデータベースのワークロードのための優れたツールが開発されており、検証のパラメーターとそれがどのように実環境のワークロードとして適応されるのかを理解していればその実行はさほど難しいものではありません。最終的にはQuestのベンチマークファクトリーを利用することにし、更に業界標準のTPC-Eワークロードを利用することにしました。Questのドキュメントに検証のためのTPC自体の説明書きがあります:

「TPC-Eベンチマークはデータベースを証券ファームのお客様が利用することをモデルとしており、取引や会計審査、市場調査などのトランザクションを生成します。証券ファームは金融市場とやり取りし、お客様の代わりにオーダーを実行し、対応する金融情報を更新します。

このベンチマークは「拡張性」があります。つまり、証券ファームの顧客数は証券ファーム毎に様々に定義でき、ビジネスの規模はそれに応じて変化するのです。このベンチマークではベンチマーク内で実行されるトランザクションの混合具合も定義する必要があります。TPC-Eの計測は毎秒のドランザクション数(tps - tranaction per second)で与えられます。この値はサーバが一定の期間内でどれだけの取引結果のトランザクションを実行できたかという値となります。」

4台のWindows Server 2012 R2の仮想マシンで、SQL Server2016を稼働させた(物理ノードあたり1つずつ)後、我々はNutanix上におけるアプリケーションのベストプラクティスを参照して適切に構成を行いました。SQL Serverのための手引にはデータベースを作成する際に1つ以上のデータファイルを作成し、それぞれのデータファイルを別々のおライブへ割り当てます。完全な詳細についてはMicrosoft SQL Server Best Practices Guideをご参照下さい。オールフラッシュのNutanixクラスタが適切に構成されているため、OLTPデータベースの検証は大抵はCPUによって決まります。我々はホストのCPUに適切な余力を残しながら、仮想マシンに適切なvCPUの構成を入れることに重点的にフォーカスして、最大の毎秒のトランザクション数が一貫して提供ができるようにしました。ホストのCPUの利用率はほとんどの本稼働系システムの場合で最大でも80%であると考え、この閾値を下回ることが無いように検証をチューニングしました。

OLTPデータベースを検証する際には様々な検証構成のパラメーターがあり、これが結果に大きく影響します。それらのうちの一つがデータベースのサイズであり、ベンチマークファクトリーでは「scale factor」として設定できます。非常に小さなデータベースを使って検証することでtpsのスコアを釣り上げることもできましたが、我々は現実的なサイズである300GB(scale-factorは32)をそれぞれのデータベースインスタンス毎に設定しました。データベースを完全利用するため、我々は最終的にはエージェント仮想マシンから各々のデータベースに対して80同時ユーザーで付加生成しました。テストのパラメーターとしては「no think time(考えている時間は加味しない)」を設定しています。

ハイパーコンバージドインフラストラクチャの検証においてパフォーマンスの拡張性は非常に重要です。ESGは特にOLTPのパフォーマンスの拡張性とより多くの仮想マシンとインスタンスをクラスタに追加した際のワークロードの分散に興味を持ちました。ですから、単一仮想マシンとSQLサーバインスタンスの最適な構成を決めるための様々な事前検証を終えた後、検証はそれぞれの仮想マシン数で実行されており(1から4)、仮想マシンとインスタンスを追加する毎に予測通りのパフォーマンスの拡張がなされることを確認しています。以下の画像で確認できるとおり、tpsがリニアに拡張されるだけでなく、平均トランザクション応答時間は低く、さらに特筆できるほどに安定しています。

Fig272

テストの結果、インスタンスあたりの毎秒のトランザクション数の総計は2,635~2,703と非常に狭い幅に収まっており、平均すると2,658です。ワークロードをスケールさせると、ESGは特にそのレスポンスタイムに感心していました。「ESGにとって更に印象的だったのは平均トランザクション応答時間でした、これは単なるストレージのレイテンシ以上のものだと考えることができますが、データベースの応答についてはコンピューティングが決定因子であるということがわかります。Nutanixのソリューションは一貫してワークロードが動作している4ノード全てで、0.031秒という超速のトランザクション時間を提供しているのです。」

パート1で言及したように、我々の検証はアプリケーションレベルでのパフォーマンスにフォーカスしていますが、その下のストレージのパフォーマンスに全てついても監視を行っており、平均のストレージのReadとWriteのレイテンシはそれぞれ0.95と1.59ミリ秒であったと記録されています。この低遅延によって、適切にCPUを稼働させることで最良の結果になるということがはっきりとわかります。この結果をより良い文脈で理解するために、これはOLTPでの検証だということを忘れてはいけません。すべての検証は継続的に行われたものです。言い方を変えるとターゲットとなるパフォーマンスは最高でかつ、少しの変動はありながらも安定的なものであるということです。もしも適切に構成されていればtpsの結果は狭い幅に「収まる」のであり、そのポイントに一貫してテストを停止するまであり続けます。これは実環境におけるパフォーマンスの能力を現実的に図っているといえることになります。

我々の検証に先駆けて、ESGは現在のハイパーコンバージドの市場を調査し、いくつかの結論に至っています。そのうちの一つが「コンピューティングおよびストレージの両方を活用するトランザクションヘビーなアプリケーションという観点からは、ハイパーコンバージドソリューションは予測性のある一貫したパフォーマンスを拡張時に提供することができない」というものでした。我々の検証をもとにすると、彼らは残念なことにその誤った概念を認めなくてはなりませんでした。つまり「・・・[Nutanixの]OLTPデータベース環境はデータベースインスタンス数が倍になっても予測性のあるパフォーマンスを提供できる、加えてクラスタ全体にIOPSが分散したとしても応答時間は一貫して低く、さらにデータがより大きくなったとしてもそれが実現できる」

個人的にこの結果を見直した際に、私は更に幾つか思うところがありました。自身のキャリアを最近はストレージのパフォーマンスやフラッシュ関連の現場に費やしているため、私はオールフラッシュのソリューションを導入することでデータセンタに一貫した、継続的なパフォーマンスをも足らせる可能性があるということは知っていました。しかし、このオールフラッシュを完全に利用するとなると、従来のメディアに加えてより多くのCPUサイクルが必要になります。CPUをより多く利用するSQL Serverのようなアプリケーションの要件を考えあわせるとこれはパフォーマンスについての麻薬のようなものになりかねません。最終的に我々は超低遅延をホスト内のストレージ(データローカリティ)で実現することができることを示し、さらにあらゆる他のオーバーヘッドを排除できることも示すことができました。ほぼリニアなIOPSと拡張しても低遅延を維持できることが合わさっていることがNutanixプラットフォームのパフォーマンスの秘伝のタレなのです。

SQLの検証とパフォーマンスの数字の詳細についてはESGのレポートを入手して下さい。そして、Nutanix Nextコミュニティでどう思ったのか教えてください、そして更に会話を続けましょう。

レポートはこちらからダウンロードできます。

議論しましょう : 我々のコミュニティのフォーラムで会話をづづけましょう。  

© 2017 Nutanix, Inc.  All rights reserved. Nutanix 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

Andyさん、やっぱり訳しにくい!(笑) 今回は前回のパート1に引き続いて、SQL Serverのパフォーマンスについて更に詳細が明かされます。ですが、記事を読んで分かる通り、問題はストレージではなくCPUです。Nutanixには強力なCPUを搭載することができますが、その強力なCPUを用いてさえ、オールフラッシュ構成のNutanixのストレージパフォーマンスを圧倒することは(OLTPでは)できません。

Andyさんが言うように、アプリケーションのことを考えるとHCIをストレージとして評価することがどれだけ愚かなことなのか、そしてその評価でものを買ってしまうと・・・ゾッとしますね。

また、NutanixのスケーラビリティについてもESGの当初の想定を覆すほどの結果だったということも重要です。Nutanixはローカリティがありますので仮想マシンから見たときに、そのI/O性能を決めるノードはわずか、2(RF2の場合、RF3なら3)ノードです。どんなにクラスタが大きくなってもこの鉄則は崩れることがありません。スケーラビリティというより、実際にはスケールアウトしても影響範囲が限定的なのでリニアに性能を伸ばしていくことができるのです。この考え方はAndyさんの古巣のPernixDataと同様ですね。

2017/08/16

クローンの攻撃 - AFS 2.1.1のWhat's new

記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社の社員であるdlink7氏によるものです。原文を参照したい方はAttack of the Clones – What's new in AFS 2.1.1をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

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

Fig267

NutanixのAFSチームは新しい様々なユースケースに対するお客様の要求に答えるためノンストップでファイルサーバーのクローンのサポートのために活動しています。AFSはもともと全てのAFS環境が単一のバックグラウンドのストレージコンテナを利用するという1対1の関係性を前提として設計されていました。この1対1の関係性は最初は多くの点で理にかなっていると思っていました。というのもPrismからは単一のストレージコンテナだけを見れば私がやりたいことの全ての統計情報を見ることができるからです。これは更にAFSのバックグラウンドのヴォリュームグループがストレージコンテナ/AFSサーバと同じ名前で済んでしまうということでもあります。ファイルサーバ全体の構成をクローンできるようにするということは開発チームはAFSとそれに対応するヴォリュームグループの間の密結合を解き放つ必要が出てきました。

AFS 2.1.1以降、AHVとESXiの両方でファイルサーバのクローンを行うことが完全にサポートされます。これはまた、同一のストレージコンテナ内に1つ以上のファイルサーバが初めて同居して動作することも意味しています。ファイルサーバをクローンする以外に、クローンをしなくてもファイルサーバのリネームするという機能もAFS 2.1.1から搭載されています。

 

この改善によって以下のユースケースをサポートできるようになっています:

 

  • 開発と検証のために全環境のクローンを作成する
  • オリジナルのファイルサーバの動作中に完全なDRの検証を行う
  • アンチウィルススキャンの完全なオフロードを実現する
  • 本稼働系サーバを稼働している最中に分析を回す
  • ROBOサイトのバックアップ 例) オフショアの石油掘削機、リモートオフィスは自身のファイルサーバを本社にレプリケーションし、バックアップを行うためにクローンを作成できます

Fig268_2

稼働中のAFSのクローンを作成することで実現する新たなユースケース

その他のAFS 2.1.1での改善点

AFSのサイジングワークフロー : PrismでAFSクラスタを作成時にワークロードベースのサイジングが利用できるようになりました。マニュアルでの設定のオプションも引き続き利用できます。

Fig269

MMC(Microsoft Management Console)のスナップインもAFSでサポートされています。これによってホームシェアのトップレベルディレクトリのリネーム、再帰的な削除、パーミッションの適用が可能になっています。これでpowershellのスクリプトを使う必要がなくなりました。Windowsエクスプローラーがホームディレクトリがうまく動かない理由は我々のDFSを利用してトップレベルフォルダの照会を行っているからで、他の製品ではこれが使われることはありません。こうした照会は多くのノードにまたがる数万のユーザーが利用する単一ネームスペースを提供することを実現しています。新たなMMCのスナップインはサポートポータルからダウンロードできます。

 

トップレベルディレクトリの管理

 

管理者とバックアップ管理者のサポート : 非ドメインのadminユーザーを管理者、そしてバックアップ管理者としてUIから追加できるようになり、cliを利用する必要はなくなりました。

短く言い換えるとAFS 2.1.1はマイナーリリースではあるものの、日々の運用に大きな影響を与えるものになるはずです。 

Fig270

トップレベルディレクトリの管理

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

Ntc2017_2

画像だけ見て、絶対訳さねばと思っていましたが、他にも色々訳したいものがあって日が空いてしまいました。ファイルサーバをクローンする、この考え方はどちらかと言うとコピーデータマネージメントに似ている気がします。物理のファイルサーバでシェアをクローンするということは当然できていたと思いますが、AFSは分散実装されているファイルサーバです。分散実装されていることならではのこれまでにない面白いユースケースが様々登場してきそうです。

2017/08/09

NVMeについて従来からのストレージベンダーがあなたに知ってほしくない5つの秘密

記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Manager, Technical Marketing EngineeringであるPaul Updike氏、およびSr. Technical Marketing EngineerであるAndy Daniel氏、およびSr. Product Marketing ManagerであるMarc Trouard-Riolle氏によるものです。原文を参照したい方はFive secrets traditional storage array vendors don’t want you to know about NVMeをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

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

Fig266

Non-Volatile Memory Express(NVMe)は、従来からのストレージ装置が膨大なストレージデバイスを利用し、その駆動のために製品への巨大な投資が必要になるというやり方を破壊しつつあります。どうしてかって? それはNVMeは従来型のストレージアーキテクチャではないからです。実際、フラッシュストレージの最初の波(SSD)もそうではありませんでした。しかし、製品をより市場に早く送り出し、幅広く浸透させるため、ドライブのインターフェイスとプロトコルは変更されませんでした。最初のSSDはフラッシュを従来型のストレージアーキテクチャで利用するために設計されていました。この要件を満たすために、SSDは従来型の回転するハードドライブを模倣しています。データの入出力はハードドライブのインターフェイスを通り、その先に回転するお皿があるかのように振る舞っており、その模倣の持つ制限に縛られているのです。これを心に留めて考えると、以下はNVMeについて従来型のストレージベンダーがあなたに知ってほしくないことなのです:

 

1. NVMe は最初はサーバテクノロジーとして提供される

殆どの新しいテクノロジーと同様に最初のドライブは一般的なデスクトップそしてサーバシステムの内部に搭載されます。今日ではNVMeテクノロジーはほとんどのメジャーなベンダーのサーバー内に搭載して購入することができます。もちろん、Best Buyで個別のユニットを買うということもできます。ゲーマーならそれをデスクトップに搭載しますし、もしも昨年購入したノートパソコンであれば、NVMeはすでに搭載されているかもしれません。残念なことにNVMeと他の多くのマスマーケットを対象にしたテクノロジーはサーバー内で利用されるために設計されており、ストレージ装置で利用されるようになるまでに長い時間がかかります。(Nutanixのハイパーコンバージドインフラストラクチャはサーバーベースのテクノロジーです)

 

2. 新しいアーキテクチャでは高可用性が必要とされる

従来型の装置はSASとSATAインターフェイスを利用するために設計されています。SASは元から1つ以上のコントローラーと同時に接続するためにデュアルポート構成で、装置ベンダーは特殊なトランスポーター(転送機)を利用してSATAでも同じことができるようにしています。NVMeのアーキテクチャはSASまたはSATAのコンポーネントを利用しません。そして、全く新しい設計が必要になります。最初のNVMe 1.1のスペックでは、U.2 デュアルポートのNVMeドライブが2016年の初期にアナウンスされました、しかし、このデュアルポートの能力を持つドライブを出荷しているメジャーなベンダーはありません。デュアルポートのU.2は複数のPCIeレーン(各コントローラーに2つ)が必要だということを覚えておいて下さい。これはスループットを制限する可能性があります。(Nutanix ハイパーコンバージドインフラストラクチャは高可用性のために複数箇所でドライブをマウントする必要はありません)

 

3. NVMe はホットスワップが難しい

NVMeはPCIe上でダイレクトに動作し、PCIeホットスワップがプラットフォームで完全にサポートされていなくてはなりません。ホットプラグ可能として販売されているNVMeドライブはありますが、それは特定の物理プラットフォーム、CPU、オペレーティングシステム、そしてドライバーが揃っている場合だけです。現在のドライバーはサーバープラットフォームとOSのために書かれたものです。繰り返しとなりますが、このサポートにはベンダーの専門性が必要とされます。(Nutanixではワークロードを移行させ、ノードレベルで停止無く修理を行うことができます)

 

4. リモートのNVMeデバイスを完全活用するためにはRDMAが必要となる

複雑怪奇なPCIeのスイッチの設計の他に、リモートのNVMeへ従来型のファブリック(イーサーネットやファイバーチャネル)経由でアクセスするためには遠隔ダイレクトメモリアクセス(remote direct memory access ー RDMA)とNVMe over Fabric(NVMeF)のような新しいプロトコルが必要になります。RDMAでスタックをバイパスせずに、単純なTCP/IPスタックを利用していてはNVMeによるレイテンシーの削減を台無しにしてしまいます。多くの業界のスタンダードと同じように、NVMeFの開発は遅く、現在殆どのストレージベンダーがこれを出荷していません。(NutanixはRDMAを活用する際にNVMeFを利用する必要はありません)

 

5. NVMe をストレージ装置上で利用する場合にはより多くのリスクが集中します

ストレージ装置ベンダーはデータをデータセンタ内で成長、統合させたいため、実際のところ多くのストレージベンダーがこれを推奨しています。多くのベンダーの目的は古い世代のハードウェアの定期的な交換です。これをより早くするため、大きなキャパシティを持つストレージでは同一システム内にデータを固めなくてはなりません。それは「バスケットの中の卵」のようなリスクで、より膨らんでいくのです。(Nutanix エンタープライズクラウドはノードの単位で成長していきます。リスクは集中するのではなく、より分散していきます)

 

NVMEを今すぐに活用するにはどうしたら…

Nutanixは新しいオールフラッシュノードを追加します。NX-9030シリーズプラットフォームはSATA SSDとNVMeを搭載しています。まとめにその方法を記載します: 

1. 我々のクラスターノードはサーバーの標準的なアーキテクチャです

2. 我々の障害と交換の対応はノードレベルで非常に簡単です。NVMeが障害を起こすことも想定済みです。

3. 我々はソフトウェアをNVMeを思慮深く利用するようにカスタマイズし、パフォーマンスを向上させています。

4. 我々は迅速に既存のRDMAテクノロジーを活用する方法を開発しました。これは新たな業界標準には依存しません。

5. 我々のエンタープライズクラウドはリスクを集中させるのではなく分散します。

 

究極的に、Nutanix製品は革新的なソフトウェアです。我々のハイパーコンバージドインフラストラクチャの哲学をベースとした障害前提ウェブスケール設計は迅速な革新的なハードウェアベンダーからの新しいハードウェアテクノロジーの適応を実現します。サーバの革新の波にのることで、我々はお客様がより早くポジティブなビジネス成果をあげることのお手伝いをすることができるのです。

 

© 2017 Nutanix, Inc.  All rights reserved. Nutanix 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

さて、抽象度の高い記事で、訳しにくいAndy Danielさんも共著のブログですが、割りと今回訳しやすかったです。

ストレージベンダーがNVMeについて知ってほしくない5つの秘密・・・ですが、以前翻訳した「フラッシュにとってネットワークは遅すぎる、どうしたら?」もその一つであると思います。今回はネットワークスピードではなく新たなNX-9030プラットフォームが登場しますので(Readはローカリティで回避、でもWriteでは不可避であった)ネットワークスピードの問題もRDMAで低減してきています。NVMeFを使うとどれぐらい良いのかはこちらなどでも結果が紹介されていますが、リモートへのWriteもローカルとほとんど変わらないようなスピードが実現されています。(これはNutanixを対象とした検証ではありませんし、単にネイティブとイーサーネット、インフィニバンドの比較を行うため、ファイルシステムなども加味されておりません、あくまでどれぐらいのレイテンシなのかということのご参考です)。

2017/08/02

敢えて言おう、VeeamはvSANに対応していると!

VMwareのSoftware-Defined StorageであるVMware vSANは、vSphere 5.5 Update1でリリースされて以降、vSphereのバージョンアップに合わせて、何度かバージョンアップが行われています。最近ではvSphere 6.5dのリリースに合わせて、vSAN 6.6がリリースされました。

そんなvSANですが、vSphere6.5対応やvSAN対応を謳っていても、現在はvSAN 6.5以降には完全に対応できていないバックアップソフトが多い状況ではありますが、Veeam Backup & Replication(以下、VBR)は、前回ご紹介したVBR 9.5 Update1で既にvSAN 6.5に対応しており、更に、5月にリリースされたVBR 9.5 Update2でvSAN 6.6にも対応しているのです!

Release Notes for Veeam Backup & Replication 9.5 Update 2

 Platform support
   -VMware vSAN 6.6 support.

そこで、今回は実際に検証環境でVBR 9.5 Update2を使用してvSAN6.6上の仮想マシンのバックアップ・リストアを試してみました。


■検証構成

論理的には下記のような構成になっており、4ノードvSANで仮想マシンとして構成したVeamサーバがvSAN上の仮想マシンをData Domainにバックアップします。

 Config1_3

実際にはESXiはNestされた仮想マシンになっており、Data DomainもVirtual Edition(仮想アプライアンス)のため、全て仮想環境上で動作しています。vSpheer Web Clientで見ると下のような感じです。ESXiのビルドが5310538 になっていることから、ESXiが6.5.0dであること分かります。vSANは全てSSDでオールフラッシュ構成(エミュレーションですが…)で重複排除・データ圧縮が有効になっています。

Vsan1_3

■バックアップ

まずは、バックアップですが、バックアップ対象の仮想マシンの選択では、データストアでvSANのデータストアである[vsanDatastore]がきちんと見えています。

Vsan3_2

下の図がバックアップを実行した結果は下の図になりますが、「hotadd」と表示されていますので、仮想マシンのVeeamサーバがHotaddモードでのバックアップに成功しています。Nest環境のため、スループットが良くない点はご容赦ください。
 

Vsan4_2

■リストア

次にリストアをしてみましょう。リストアのウィザードではvSANデータストアの中に仮想マシンに別途、割り当てている仮想マシンストレージポリシー(Test-VM-Policy)が表示され、ストレージポリシーの情報含めてバックアップしていることが分かります。

Vsan5_2

リストアも問題なく成功しました。「hotadd」を表示され、リストアでもHotaddモードでvSANデータストアにリストアできていることが分かります。

Vsan6_2

リストアされた仮想マシンの仮想マシンの設定を確認してみると、割り当てていた仮想マシンストレージポリシー(Test-VM-Policy)も戻っていました。

Vsan7

仮想マシンストレージポリシーが戻るのは当たり前と思う方もいるかもしれませんが、vSAN対応を謳っているバックアップソフトでもStorage Policy-Based Management (SPBM) には対応できておらず、リストアすると、デフォルトの仮想マシンストレージポリシー(Virtual SAN Default Storage Policy)が割り当てられ、リストア後に手動で仮想マシンストレージポリシーの再割り当てが必要なものが多いのです。

vSAN環境では仮想マシンストレージポリシーで仮想マシンの冗長化を定義するため、バックアップソフトがSPBMに対応しているかどうかは重要です。また、他のバックアップソフトの場合、バックアップベンダーが独自にvSAN環境でテストを行い、vSAN対応を謳っていることがほとんどですが、VBRは独自にテストをしているだけでなく、VMware社のvSAN認定も取得し、VMware社のKBにも掲載されているほどです!

※vSAN データストアを使用した Veeam のバックアップと複製 (2150856) http://kb.vmware.com/kb/2150856


vSphere 6.5でvSANを利用するとなると、今後はvSAN6.6が前提になってきますが、VBRであれば、vSAN環境やvSANベースのハイパーコンバージドインフラ製品でも安心してバックアップできます。vSANの導入を検討している方や既にvSANを導入済みでvSAN 6.6へのバージョンアップを予定している方で、VBRを検証してみたいという方は、是非、評価版でお試しください!

■参考

Veeam Backup & Replication 評価版ダウンロード

VMware vSphere向け簡易手順書(日本語版評価ガイド)

Configuration for VMare VSAN

 担当 臼井