« 2017年7月 | メイン | 2017年9月 »

2017年8月

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

 担当 臼井

Nutanix on HPE® ProLiant® is NOW AVAILABLE

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSenior Product Marketing ManagerであるEJ Bodnar氏によるものです。原文を参照したい方はNutanix on HPE® ProLiant® is NOW AVAILABLEをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

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

Fig265

Nutanixは業界をリードするエンタープライズクラウドソフトウェアが最も幅広く展開されているエンタープライズサーバープラットフォーム上で利用可能になったということをアナウンスでき興奮を禁じえません。

HPE® ProLiant® サーバはNutanixによってNutanixエンタープライズクラウドソフトウェアの動作のための完全な検証そして認証を得ています。HPE® のお客様はNutanixソリューションを活用してエンタープライズクラウドを構築し、パブリッククラウドサービスのシンプルさ、俊敏さをプライベートクラウド環境に必要とされる統制、セキュリティとともに享受することができます。ProLiant®を利用しているお客様はNutanixを業界で最も利用されているハイパーコンバージドソリューションとしたのと同じ、Nutanixのコンピューティング、ストレージ、仮想化、そしてネットワークの機能 ー 更に加えて直感的なコンシューマーグレードの管理機能を手にすることができるのです。

Nutanix エンタープライズクラウドソフトウェアをHPE® ProLiant® ハードウェア上で動作させることでお客様は以下を実現できます:

  • HPE® ProLiant® サーバとNutanixエンタープライズクラウドソフトウェアで完全なインフラストラクチャのスタックを構築
  • 高価で複雑なSANを排除し、データセンタをProLiant® サーバのストレージリソースでシンプル化
  • ワンクリックでのソフトウェアアップグレード、インフラストラクチャの拡張、トラブルシューティングによって、インフラストラクチャの管理を劇的にシンプル化ー ITスタッフを開放し、インフラストラクチャではなく、ビジネスアプリケーションにフォーカスができるように
  • スモールスタートし、ProLiant®を一台ずつ追加することで制限のない拡張を実現
  • Nutanixがネイティブで提供するAHVハイパーバイザーによって仮想化についてのコストを削減、仮想化の管理を統合
  • アーキテクチャや運用を変更すること無くProLiant®サーバに簡単にNutanixのエンタープライズクラウドソフトウェアを追加

 

強い顧客、そしてパートナーからの要求:

NutanixのHPE® ProLiant® のサポートは強い顧客そしてチャネルパートナーからの要求に答えたものです。HPE®認定ディストリビューターそしてリセラーとNutanixはHPE®ハードウェアとNutanixソフトウェアを自身のファシリティまたはお客様先で統合します。IT専門家は他のすべてのNutanixがサポートするハードウェアプラットフォームと同様の素晴らしいエクスペリエンスを享受することができます。

 

サポートされるHPE® ProLiant® サーバには以下が含まれます:

  • ProLiant® DL360-G9  ー 1Uのラックマウントサーバで最大8つのスモールフォームファクタ(SFF ー small form factor)ドライブベイを保持します。これによってオールフラッシュ構成または2x SSD と 最大 6x HDDを組み合わせたハイブリッド構成を実現することができます。DL360はVDI、ミドルウェア、Webサーバそして一般的な仮想化のユースケースに最適です。
  • ProLiant® DL380-G9 12LFF ー 2Uのラックマウントサーバーで最大12のラージフォームファクタ(LFF - large form factor)のドライブベイを保持します。オールフラッシュまたは2x SSDと最大10x HDDでのハイブリッド構成を実現することが可能です。主としてストレージヘビーまたはサーバー仮想化ワークロードをターゲットとしています。
  • ProLiant® DL380-G9 24SFF ー 2Uのラックマウントサーバーでこちらは最大で24のSSFドライブベイを保持します。オールフラッシュ構成および4x SSDと最大20x HDDでのハイブリッド構成を実現することが可能です。MS Exchange、SQL Serverそして、大規模なデータベースユースケースに向いています。

 

どのようにサポートが行われるか:

  • Nutanixはエンタープライズクラウドソリューションが展開された認定済みHPE® ProLiant®システムすべてにおいて、最初のコールを受け付けます。これによってシンプルな、サポートの単一のコンタクトポイントをご提供します。お客様はもちろん、明らかにハードウェアの問題である場合にはもちろん、お客様がHPE® に最初にコールするという選択肢もあります。
  • 初期の切り分けの段階において、もし問題がハードウェア上にあるかもしれないという状況においても、Nutanixのサポートはお客様がHPE® へコンタクトをとることをアシストします。これは必要不可欠な情報をご提供するというための手段ということになります。NutanixはHPE® にお客様の代わりに直接TSANet (TSANet.org)経由でコンタクトをとるという手段もご用意しています。
  • もしも問題がソフトウェアに起因するものであれば、Nutanix サポートはその問題の解決のために稼働します。いずれに場合においても、Nutanixサポートは顧客との合意の元、受け入れ可能な解決がなされるまでケースをクローズしません。

 

ハイパーコンバージドインフラストラクチャを超え、エンタープライズクラウドへ:

ハイパーコンバージドインフラストラクチャはプライベートクラウドに劇的なシンプルさをもたらしました。しかし、エンタープライズのデータセンタがパブリッククラウドのちからを持つにはまだ多くのものが必要です。HPE® ProLiant® 上で動作するNutanix エンタープライズクラウドプラットフォームはパブリッククラウドインフラストラクチャの俊敏性とワンクリックのシンプルさとセキュリティ、統制、想定通りの経済性、そしてプライベートクラウドに必要とされるパフォーマンスも融合されています。ハイパーコンバージドインフラストラクチャををNutanixエンタープライズクラウドで超えていきましょう…

 

Nutanix on HPE® ProLiant® について更に詳しく知りたい場合は こちら: https://www.nutanix.com/dlserver/ そしてNutanixエンタープライズクラウドについて更に知りたい場合には こちら:https://www.nutanix.com/

 

 

© 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.

HPE® and ProLiant® are registered trademarks of Hewlett-Packard Development LP and/or its affiliates.  Nutanix is not associated with, sponsored or endorsed by Hewlett-Packard.

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

Ntc2017_2

5.1.1.1のリリースにひっそりと記載されておりましたが、なんとNutanix on HPE ProLiant、すでに正式にリリースされています!Nutanix Washinton D.C.でもひときわ拍手の大きかった発表ですし、本当にこれを待ち望んでいたパートナー、お客様が多くいらっしゃったのですね。年内に動けばいいと思っていましたが、大きく前倒しされてのリリースです。

当社もウェブセミナーのやってみたシリーズなどで取り上げていきたいと思っていますが、ProLiantはGen10もリリースされていますので、そちらがサポートされてからの検証になるかもしれません。

いずれにしてもNutanixは100%ソフトウェアカンパニーであるというその本来の姿を顕しつつありますね。

面白いのが冒頭のイメージです。HPE社のロゴはRectangle(四角)ですが、その外で考えよう!なかなかシャレが聞いています。