*VMware Feed

2016/12/08

vRealize Network Insightができるネットワーク仮想化の見える化

皆さん、こんにちは。ソリューションアーキテクトをしている工藤です。この記事はvExperts Advent Calendar 2016に参加しています。

今日はは8月にリリースされたvRealize Network Insightを紹介します。
vRealize Network Insightは元々はスタートアップベンダーであるArkin社を2016年6月に買収して、vRealizeブランドとして製品化されたものになります。画面だけではなかなか伝えきれないこともあるため、各機能の動画を紹介しています。動画をご覧頂きvRealize Network Insightができることを理解いただければ幸いです。

■vRealize Network Insightとは?

vRealize Network Insightは、ざっくり言うとネットワーク版vRealize Operations Managerということができます。サーバ仮想化のリソースを見える化するのがvRealize Operations Managerだとすると、ネットワーク仮想化のリソースを見える化するのがvRealize Network Insightになります。何とかInsightというとvRealize Log Insightの印象がありますが、できることはvRealize Operations Managerに近いのです。

ざっくり言ってしまいましたが、もちろんvRealize Operations Managerだとネットワークの状態がわからない、vRealize Network Insightでは仮想マシンの状態がわからないといったことはありません。あくまでもvRealize Operations ManagerはvSphereのホストや仮想マシンを中心として、vRealize Network Insightはネットワークを中心にそれぞれ必要な機能にフォーカスしているだけですので安心してください。

vRealize Operations Managerは、性能情報仮想基盤のインベントリ情報を組み合わせて見える化します。

1_2

vRealize Log Insightは、ログ情報見える化します。

2_2

vRealize Network Insightは、パケット仮想基盤のインベントリ情報などを組み合わせて見える化することで仮想基盤のネットワーク管理にかかる運用工数を改善する製品です。

3

ではvRealize Network Insghtが実際にどんなアーキテクチャで、ネットワークの見える化を実現しているのか見ていきたいと思います。

■vRealize Network Insightのアーキテクチャ

vRealize Network Insightは現在2つの仮想アプライアンスから構成されます。

4

Proxy VMは、vCenterやNSX Manager、物理スイッチからインベントリ情報や設定を収集する役割と、vSphere上の分散スイッチのNetFlowで送られたフロー情報を収集する役割があります。

このときNetFlowでは通信パケット全てを送るわけではなく、パケットのヘッダ情報だけをやりとりしているためセキュリティ上も安心ですし、転送帯域も膨大には必要ありません。

Platform VMはProxy VMが収集したこれらの情報を解析して見える化する役割と、管理者にダッシュボードを提供する役割を提供します。

vRealize Operations Managerもそうですが、膨大な収集したデータを解析するため仮想アプライアンスに要求されるスペックが大きいので既存環境に追加する際には考慮が必要です。

■vRealize Network Insightで通信の可視化

vRealize Network Insightはこれまでの説明でもあったように、NetFlowを使った通信フローの可視化を行います。分散スイッチのレイヤで通信フローが収集されるため、ゲートウェイを介した通信だけでなく同一セグメントの通信はもちろん、同一ホスト内で物理的にはLANケーブルを流れていない通信まで可視化することが可能です。マイクロセグメンテーションを行う際に利用するVMware NSXの分散ファイアウォールのポリシー設計はもちろん、導入後のセキュリティ監査の目的で利用することができます。

5


YouTube: VMware vRealize Network Insight ネットワークフローの見える化

■vRealize Network InsightでNSX環境の健康診断

冒頭にvRealze Network Insightはネットワーク仮想化におけるvRealize Operations Managerのようなものですと説明しました。

vRealize Operations ManagerがvSphere環境の健康診断が行えるのと同じように、vRealize Network InsightではVMware NSX環境の健康診断を行うことができます。2016/12/1現在の最新版である3.1ではVMware社のベストプラクティスに基づいた40のチェック項目にわたる健全性確認を行い、ネットワーク仮想化基盤のトラブルを未然に防ぐことができます。

VMware vRealize Network Insight NSXの健康診断
YouTube: VMware vRealize Network Insight NSXの健康診断

■vRealize Network Insightで仮想基盤ネットワークのトラブルシューティング

vRealize Network InsightはNSXを導入した際の「NSXと物理ネットワークのトラブルシューティングが難しそう」といった相談を多くうけます。先ほど紹介したNSX環境の健康診断で安定したネットワーク仮想化基盤の維持ができます。

またvRealize Network InsightではNSXが構成するオーバーレイネットワークと物理スイッチが構成するアンダーレイのネットワークを一元的に管理することができます。


YouTube: VMware vRealize Network Insight 仮想ネットワークのトラブルシューティング

■まとめ

vRealize Network Insightを利用することで、VMware NSXが実現するネットワーク仮想化を低コストで運用していただくことが可能になります。
ご興味のある方は、VMware社が提供するオンラインラボを使ったハンズオン環境もありますので是非ご利用ください。
http://labs.hol.vmware.com/HOL/catalogs/lab/2894

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さんはもう次の記事に取り掛かっているそうです。次はタイムリーに公開できるようにがんばります!

2016/11/24

EMC UnityはVeeamファーストで行こう!

今年5月に「EMC VNX/VNXe」の後継として、日本で販売が開始された「EMC Unity」ですが、VMwareのストレージとして既に利用されている方やこれから導入しようと計画している方も多いと思います。そこで、Unityと相性ピッタリのバックアップソフトであるVeeam Backup & Replication (以下、VBR)を一緒に使うと、どのようなメリットがあるのかをご紹介します。


■Unityスナップショットからのリストア

Unity自体にスナップショット機能があり、CIFSのファイルサーバー用途では、WindowsのVSSと連携してファイル単位でのリストアが可能です。しかし、VMwareのデータストアとして利用している場合は、データストア丸ごとのリストアとなってしまい、1つのデータストア上に多数の仮想マシンがある環境では気軽に利用することができません。

Veeam14_7

 

 そんな時に便利なのが、VBRのVeeam Explorer for Storage Snapshotsです。Unityのスナップショットから仮想マシンの中のファイルをリストアすることができます。

Veeam02


Explorerから元の仮想マシンに対して直接リストアすることもできますし、任意の場所にファイルをコピーすることもできます。

Veeam15_3


更に、同様の手順で仮想マシンの中のアプリケーション単位(Active Directory,Exchange,SQL Server,SharePont Server,Oracle)でリストアすることも可能です。

Veeam03_2


例えば、Active Directoryのドメインコントローラの仮想マシンの場合には、ストレージスナップショットからユーザーやグループポリシー、DNSレコードをリストアできます。

Veeam04_3


短い間隔でスナップショットスケジュールの設定をしていれば、より最新のスナップショットデータから簡単にリストアすることができ、同じデータストア上の他の仮想マシンにも影響がないため、気軽にスナップショットを利用できます。


■Unityスナップショットの活用

Veeam Explorer for Storage Snapshotsのメリットは、Unityのスナップショットからのリストアだけではありません。インストタントVMリストア機能と組み合わせて、Unityのスナップショットから仮想マシンを直接起動することも可能です。これにより、仮想マシンに障害が発生した場合でも、リストアするよりも短時間で仮想マシンを立ち上げて、業務を継続することが可能です。

Veeam05


ストレージスナップショットから起動した仮想マシンはVBRのコンソールからStorage vMotionを実行することで、そのまま本番環境として利用することも可能です。

Veeam20_3

 
障害が発生していない場合でもスナップショットから起動した仮想マシンは、本番環境の完全に分離されたコピーになりますので、アプリケーションのインストールやパッチ適用のテスト環境、仮想マシン上で障害が発生している場合には、トラブルシューティング用の環境としての利用など、スナップショットを様々な用途で活用することができます。

最近では、バックアップデータから仮想マシンを直接起動できるバックアップ製品も増えてきていますが、VBRでは2010年にリリースされたバージョン5からインスタントVMリカバリ機能を提供しており、更に他社の上を行くストレージスナップショットからの起動を提供しています。


■Unityのスナップショットと連携したバックアップ

スナップショットは便利な機能ですが、ストレージ筐体そのものに障害が発生した場合には、全てのデータが消えてしまいます。そのため、別の媒体にデータを保存する”バックアップ”を行うことが重要ですが、バックアップにおいてもUnityにVBRを組み合わせるメリットがあります。

それは、Unityのスナップショットと連携してバックアップができることです。他社の仮想環境用のバックアップソフトでもUnity上の仮想マシンをバックアップすることはできますが、他社製品はストレージがUnityかどうかは見ていません。どのストレージを使っていても全て同じです。

しかし、VBRはデータストアがUnityのストレージであることを理解し、vSphereのスナップショットだけでなく、Unityのスナップショットと連携してバックアップをしてくれます。vSphereのスナップショットだけの場合、仮想マシンの容量が大きく、バックアップ時間がかかるケースや、バックアップ中に仮想マシンへの変更が多いケースでは、デルタファイル(Redoファイル)の肥大化やスナップショット削除時のマージ処理で問題が起きる可能性がありますが、Unityのスナップショットと組み合わせれば、このような問題を解決することができます。

バックアップジョブの設定もチェックを付けるだけです(デフォルトでチェックが付いています)ので、意識することなく簡単にストレージスナップショットと連携してのバックアップが可能です。

Veeam19_2

※Unityの接続(FC,iSCSI,NFS)にあわせて、VBRのサーバがUnityのストレージにアクセスできるようにUnity側やVBRのOS側の設定は必要になりますので、ご注意ください。

■どうやってUnityVeeamを組み合わせるの?

Unityと連携するには設定が難しいのでは?と思う方もいるかもしれませが、設定ウィザードに従い、Unityを登録するだけでVBRが自動的にストレージを検出してくれます。ウィザードの流れを見ていきましょう。

 ①[EMC]を選択します。

Veeam17_2


②[Unity]を選択します。

Veeam08_3

 
③Unity管理用のホスト名かIPアドレスを入力します。

Veeam09_2


④Unityの認証情報を入力します。

Veeam10_2


⑤自動でUnityが使用しているプロトコルを認識し、プロトコルにチェックが付きます。

Veeam11_2


⑥Unityの情報がサマリーで表示されますので、Finishで完了です。

Veeam12_2


⑦Unityの作成済みスナップショットと仮想マシンが表示されます。

Veeam13_3

このように簡単にUnityを登録できますが、vSphereとUnity、Veeamと複数の製品が絡むため不安だという方は、弊社の導入サービスをご利用いただければ、vSphere・Unity・VBR全て弊社で設定させていただきますので、ご安心ください!
http://www.networld.co.jp/support/introduction/


ご紹介した全ての機能はUnityだけでなく、VNXやVNXeでも利用できますので、VNX/VNXeを既にご利用の方は今からでも遅くありません。今のうちに、VBRを導入しておけば、何年後かにVNX/VNXeをUnityにリプレースする際にも、引き続き、VBRを利用することが可能です。

VMware環境でEMCストレージをご使用の際には、Veeamを真っ先に思い出していただければ幸いです。

 担当:臼井

2016/10/14

VMware Cloud™ on AWS – 詳細

本ブログエントリーは以前はPernixData社のテクノロジーエバンジェリストとして勤務し、現在はVMware社のSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud™ on AWS – A Closer Lookで閲覧可能です。

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

長きに渡る沈黙を経て、ようやく少しだけ、私がVMwareで何にフォーカスをしてきたかということをお話できるタイミングになりました。(この記事の内容はblogs.vmware.comに掲載した内容の再掲です。)

本日、VMwareとAmazon Web Services(AWS)は完全なVMwareのSoftware Defined Data Center(SDDC)を動作させることが可能なクラウドサービスをAWS上で提供開始するという戦略的なパートナーシップを発表しました。このサービスはvSphere、ESXi、VSAN、そしてNSXを含む皆様がよく親しんだ全てのエンタープライズツールが含まれています。この記事では新しいVMware Cloud on AWS(VMC)サービスの技術的なプレビューを行います、もうすぐリリースされるめちゃくちゃクールなこいつを覗き見していきましょう。

Fig001このアーキテクチャは言わずもがな、夢の取り合わせです。vSphereをこれまでに利用してきた管理者や設計者はアプリケーションを再設計することや、運用手順を再構成することなくAWSの俊敏性を活用することができようになるのです。vCenterが運用の中心となるプラットフォームになりますから、現在オンプレミスのvSphere環境で利用しているvCenterと連携して動作する全てのツールがクラウドのSDDC環境で動作するというのが一つの大きな目玉です。こうした何年もの月日を経て開発されてきたツールや機能が、今後はクラウドの間をワークロードが移動出来る環境で利用することが出来るようになり、その上、新しいレベルでのデータセンタの俊敏性までもが利用可能なのです。

つまり、サインアップを終えて、クラスタのサイズを選択すればご自身のSDDC環境が短時間で作成されるということです。VMware cloudはネイティブなESXが、次世代のAWSのベアメタルインフラストラクチャ上で動作しているということを強調(そして誤解を避けるためにも)しておきます。VMware cloudはAWSインフラストラクチャ上のvSphere ESXiホスト、VSAN、NSXを含むプライベートクラウドとして展開されます。これによって、エンタープライズワークロードがオンプレミスの環境と同じレベルのパフォーマンス、信頼性、そして可用性で今度はAWSアーキテクチャ上で動作するということになります。オンプレミスとクラウド環境の大きな違いはVMwareがVMware Cloud on AWSのインフラストラクチャを管理運用するということです。

Fig002

重要なので、これは完全なマネージドサービスであるということをしっかりとお伝えしておきます。つまり、VMwareがこれを支えるESXi、VSAN、vCenter、そしてNSXのインフラストラクチャをインストール、管理、維持するということです。パッチ適用やハードウェア障害の復旧というような一般的な運用はVMwareがサービス内で実施します。お客様はvCenterのパーミッションなどの権限を受け、管理的なタスクを行うことになりますが、パッチ適用などの特定のアクションについてはVMwareがサービスの一環として提供を行います。これはつまり、VMwareがAWSとのパートナーシップ内でインフラストラクチャのコア部分の面倒を見るということです。

VMware Cloud on AWSはスタンドアローン、ハイブリッドクラウド、そしてクラウド to クラウドの3つの環境で利用が可能です。ハイブリッドとクラウド to クラウドの環境ではvCenterはリンクモードを有効にして構成され、IT運用チームがSDDC環境を集中管理されたコンソールから一元管理できる状態で提供されます。NSXは様々な環境間のネットワークとセキュリティを一貫して俯瞰できるように拡張します。ただし、NSXは要件には含まれません! もしも現在NSXをオンプレミス側で利用していなかったとしてもVMware Cloud on AWSを利用することが出来、その場合にはNSXを利用するハイブリッドクラウドの機能を利用できないというだけです。ネットワークとクラウドにまで渡る機能によって、vMotionでワークロードを様々なクラウドに自在に出入りさせることが出来るようになっています。そう、読み間違えではありませんよ、現在のオンプレミスのvSphere環境からAWSへvMotionすることが出来るのです!

面白いコンセプトとしてイラスティックスケーリング(自在な拡張)があります。イラスティックスケーリングはIT設計者の直面するもっとも難しい課題であるキャパシティプランニングの解決に役立ちます。キャパシティプランニングの重要なポイントは現在と将来のリソース要件、障害復旧キャパシティ、そしてメンテナンスのためのキャパシティです。ワークロードのパフォーマンスと障害復旧のための予約キャパシティのCAPEXとOPEXの低減の適切なバランスを見つけ出すことは難しい問題です。イラスティックスケーリングがvSphereクラスタを俊敏性を備えた発電所へと変えると考えてください。時間のかかる調達を行い、プロセスを自身でインストールする代わりに、拡張性のあるITという考え方とAWSによって提供されるサービスのメリットを受けることが出来るのです。

ESXi4.0以降、vSphere HAはワークロードがクラスタ内の稼働中のホスト上で再起動する事を実現しています。しかし、ホストの不足が一時的なものではない場合、ホストのリソースは利用可能なホスト数の減少によって抑制を受けることになります。ESXiホストが不足している間にもホストのリソースが確保されるような自動修復機構をDRソリューション上に構築することも可能です。ホスト障害が検知された際に、自動修復はクラスタに自動的に別のホストを追加し、ワークロードのパフォーマンスが長期継続するホスト障害からの影響を受けないことを保証します。もしも(ハードウェアの)部分的な障害の場合、自動修復によってその機能不全のホストがクラスタから外れる前にVSANの必要な操作が行われることを保証します。

このフレームワークのもう一つのメリットはメンテナンス時にも同様にリソースを利用するということが出来るということです。メンテナンス運用の最中、クラスタのサイズが減ることはなく、ワークロードはリソースが減ることによる影響を受けずに、通常運用時と同じように動作継続することが出来るのです。

VMware Cloud on AWSサービスの一つの強みは管理者、運用チーム、そして設計者が既存のスキルセットとルールを利用してAWSインフラストラクチャを利用することが出来ることだと考えています。クラウドへワークロード動かす際に、そのクラウド流にプラットフォームを変更する必要も、仮想マシンの変換も、パッケージングの変換も、そして重要なポイントとして、過剰なまでの検証を行うこともなく、単に仮想マシンを移行させればよいのです。もう一つの強みは、AWSが取り揃えている優れた機能セットと現在のワークロードを組み合わせられるという点です。その結果、ITチームは自身のスキルセットを広大なAWSが提供しているサービスのカタログへと拡張していくことが出来るようになります。これによって、オンプレミスのプライベートクラウドと優れたAWSのパブリッククラウドサービスの両方でシームレス動作する環境を作り上げることが出来ます。

もっとご紹介したい素晴らしい機能がたくさんあるのですが、これについてはまた別の記事のために取っておきましょう。

VMworld

もし、今後リリースされるVMware Cloud on AWSサービスをもっと学びたいと思うのであれば、VMworld Europeで、ブレイクアウトセッションINF7849:VMware Cloud on AWS - a closer lookに参加してください。このセッションでAlex Jauchと私はもう少し深くこのサービスの詳細まで潜っていきます。もっと一般的な観点であればINF 7711 VMware Cloud Foundation on Public Cloudsのブレイクアウトセッションへご登録ください。

VMworld Europeでの私のMeet the Expertのスロットも少ないながら有りますので、もしもっとサービスにフォーカスした議論がしたいということであればご登録ください。

もし、ベータへ登録をしたいという場合にはこちらをクリックしてください:http://learn.vmware.com/37941_REG

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

ちょっと本日バタバタしており、タイムリーに翻訳記事を公開できませんでしたが、なんと、Frankのアニキこんなことになっていたのですね! VMwareに戻って活発に活動しているようなのでとても嬉しいです。VMwareがAWS上で動く、まさにFrankさんが言うように「夢の取り合わせ」です。私個人的にはこのところ活動が多角化していたVMwareが本来のソフトウェアカンパニーとしてのイノベーションという原点に回帰したようにも思え、今回の発表はなんだか、心が熱くなります。まだまだ語るべきことがたくさんある!と言う雰囲気ですのでFrankさんの記事はタイムリーに翻訳をかけていきたいと思います。

また、上で紹介されているVMworld Europeですが、今年もネットワールドのメンバーが参加予定になっていますので、また現地からのレポートが届くかも!? 乞うご期待です!

2016/10/12

VMwareさん、ご冗談でしょう?(FUDだ!) : Nutanix CVM/AHV と vSphere/VSANのオーバーヘッド

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はVMware you’re full of it (FUD) : Nutanix CVM/AHV & vSphere/VSAN overheadsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

訳注: 少々刺激的な表現が多用されますが、原文はもっと酷いです(笑) 真実は人と立場によって異なります。決して何かを煽るつもりもありませんし、そうならないように(特にインカーネルストレージIOパスPVSCSI)技術的な裏取りの記事をいくつも翻訳してきました。ぜひ、合わせてこの壮絶な宗教(?)争いの結果に生まれたとんでもない記事をお楽しみください。

長きに渡って、VMwareとEMCは他のベンダーとともにNutanixのコントローラーVM(CVM)についてのFUD(訳注:ネガティブキャンペーン、Fear-恐れ、Uncertainty-不安、Doubt-疑念を煽るような競合に対するマーケティング戦略のこと)を流し続けてきました。すなわち、CVMはI/Oを行うために多くのリソースを利用する、ですから仮想マシン(つまり、仮想化ストレージアプライアンス/VSA)はインカーネルで動作するのよりも効率が悪く、遅いと。

最近のFUDの例を挙げると、VCEの社長、Chad Sakac氏自らが書いた記事があるので引用します。

それ(VxRail)は完全に統合されたSDSスタックをカーネルに埋め込んだ唯一のHCIA(ハイパーコンバージドインフラストラクチャアプライアンス)です。VSANを利用するためにVxRailはvSphereを利用します。8vCPU、16GB以上のメモリをストレージスタックに利用するようなおかしなことはしません(これは他のHCIAを選んだ場合の「ストレージコントローラ」毎の値、もしくはノードあたりの値ですよ!)。

ですから、私は過去に書き連ねてきたNutanix CVMの提供する機能と、Chad氏のいう完全にSDSが統合されたスタックを並べて比較の記事を書いてみました。

さぁ、Acropolis分散ストレージファブリック(ADFS)とAcropolisハイパーバイザ(AHV)からなるNutanix Suiteに必要とされるリソースと、VMware社のvCenter、ESXi、VSANそして関連コンポーネントからなるVMwareのSuiteに必要とされるリソースの比較をしていきましょう。

こうすることで、Nutanixのプラットフォームをあまりご存知でない方がその機能とCVMが提供する価値を理解する事もできますし、様々な競合他社によって流されているFUDは正しくはどういうものかという事を理解することも出来ます。

初める前に、Nutanix CVMの標準のサイズを確認しておきましょう。

本日の時点ではCVMは標準で8vCPU、16GBのメモリを利用します。

CPUリソースについては当たり前のことですが、お客様のユースケースによって異なります。もしもI/O要件が低い場合には、CVMは8vCPUどころか、4vCPUも利用することはありません、ですが8vCPUが割り当てられています。

何年もの間に渡ってESXiのCPUスケジューリングは改善され、必要以上のvCPUを環境内の限られた数の仮想マシン(例えばCVM)に割り当てるという影響は無視できるほどになっています。でうが、CVMはしっかりとサイジングされているべきだということも常識です。

メモリの割当は重複排除を利用する場合には24GBが推奨です、そしてワークロードが大きくReadに偏っているような場合、メモリを増やすことで更に大きなReadキャッシュとして利用できます。

しかし、CVMのメモリをReadキャッシュ(拡張キャッシュ)として増やすのは今では昔の推奨事項とされています。これはAcropolisオペレーティングシステム(AOS)4.6のリリースでReadキャッシュを有効にしなくても優れたパフォーマンスが出るような改善がなされたからです。

実際のところ、AOS 4.6において4KのランダムのReadで 150K(15万)IOPS以上を記録したNX-9040-G4のノードはインメモリReadキャッシュを利用せずに開発チームがSSDの性能がどのぐらいのものなのかを示すために行ったテストでのものです。結果として、極端なほどのパフォーマンスであってもCVMのメモリをReadキャッシュとして増やすということはもはや必要ありません。ですから殆どのワークロードでは24GBのメモリで充分であり、メモリの要件を減らすということも可能なのです。

考察 : インカーネルのソリューションが優れたストレージパフォーマンスを提供できるということが事実であったとしても(今回はそういう話はしませんが)、これは全体からするととても小さな部分にしか過ぎません。管理についてはどうですか? VSANの管理はvSphere Web Client経由で行われますが、その仮想マシンはユーザースペース(空間)で動作しています(つまり、「インカーネル」ではない)し、更に同じくユーザー空間で動作している仮想マシンで動作しているvCenterに接続を行います、さらにvCenterはSQLやOracleデータベースを利用しており、これもユーザー空間で動作しています。

さて、続いてレプリケーションについて見ていきましょう。VSANはvSphere Replicationを利用します、これもご承知のとおり、ユーザー空間で動作している仮想マシンで動作します。キャパシティ/パフォーマンス管理において、VSANはvRealize Operations Manager(vROM)を利用しており、これもユーザースペースで動作しています。バックアップは? vSphere Data Protectionアプライアンスはこれもまた、ユーザー空間で動作している仮想マシン上のサービスです。

これらの全ての製品はデータをカーネル空間からユーザー空間へと取り出す必要があります。現時点では仮想マシンの基本的なI/Oを除くとすべての機能でVSANはユーザー空間で動作しているコンポーネントに依存していることになります(つまり、インカーネルではない)。

さぁ、VSAN自身の要件を見ていきましょう。

VSAN design and sizing guide(ページ56)によるとVSANはVSANのすべての機能を利用する場合には最大でホストのCPUの10%までと32GBのメモリを必要とすると有ります。もちろん、VSANが32GB全てを利用するということではなく、必要でなければNutanixのCVMが割り当てられたメモリを全て利用するということはないということと同じです。ですが、Nutanixでは最低推奨サイズの12GBまで減らすことができますし、16GBが今日では小さい方だと言わざるをえない192GBのメモリを搭載したノードにおいても標準的です。16GBというのはVSANであってもNutanixのCVMであっても10%未満で最小限のオーバーヘッドと言えるでしょう。

私が検証した結果によるとVSANのCPU利用率のオーバーヘッドは10%に制限されているようではないようです。これはVMware社自身が行ったSQLでの検証「VMware Virtual SAN™ Performance with Microsoft SQL Server」で確認が可能です。

かいつまんで説明をすると、検証は4vCPUで構成された3つの仮想マシンで実施され、デュアルソケットのIntel Xeon プロセッサE5-2650 v2(16コア、32スレッド@2.6GHz)を搭載したホストで動作しています。

仮想マシンが100%の利用率だと仮定しても、コア全体の75%(16のうちの12)しか利用しないはずです。ですから、以下のグラフを見ると仮想マシン以外の何者かがCPUを利用しているということがわかります。最低でもハイパーバイザが5%を利用するとして、VSANは20%ほどのCPUを利用していることになります。実際には仮想マシンは100%の利用率になることはありませんので、VSANは20%よりも多くオーバーヘッドがある事になります。

Fig032さて、I/OのためのCPU要件はわかりました。VSANが20%かそれよりも多くCPUを利用するとしても別段問題はありません。問題だと思うのはVMwareがお客様に10%しか利用しないというご案内をして、更にNutanixのような仮想アプライアンスを利用する他の仮想アプライアンスベンダーはリソースの大食漢だというFUDを撒き散らしていることです。

私の言葉をそのまま信じるのではなく、ご自身で検証したり、上で挙げられているようなドキュメントを読んでみてください。簡単な算数だけで、最大10%と言うのは神話であるということがわかると思います。

ここから、大体4vCPU(大抵のデュアルソケットの8コアのシステム上で)と最大で32GBのメモリがVSANに必要になるということがわかります。ですが、今回は平均的に16GBということにしておきましょう。殆どのシステムはディスクグループが5以上になることはありません。

上での検証は最新のVSAN 6.2でのものではありません。ですから、これは今では変わっている可能性があります。こうしたVSANの変更の中にソフトウェアのチェックサムがあります。これは実際にパフォーマンスを劣化させます(皆さんのご想像の通り)、というのもこの機能は全てのI/Oについてのデータの一貫性を提供するものであるため、上で述べてきたパフォーマンスの比較をNutanixと行うという意味ではこれを加えるほうがフェアになります。というのも、本稼働系のストレージソリューションとしてこの機能は必須の機能なため、Nutanixは常にソフトウェアでチェックサムを取得しているからです。

そして、思い出してください、VSANはストレージスタックの部分しか提供していないのです。ですから20%までのCPUの高負荷は単なるストレージスタックだけからのものです。NutanixのCVMではそれに加えて高可用性をもつ管理レイヤーも提供しており、比較をするのであれば(殆どの場合、それ以上の機能、可用性、拡張性を提供していますが)vCenter、VUM、vROM、vSphere Replication、vSphere Data Protection、vSphere Web Client、Platform Services Controller(PSC)そしてそれを支えるデータベースプラットフォーム(SQL/Oracle/Postgres)までをも提供しています。

ですから、VSANのCPU利用率とNutanixのCVMを正味で比較というのとは程遠いわけです。正味の比較を行うために、全てのvSphereの管理コンポーネントのリソース要件を見て、平等な比較を行いましょう。

vCenter Server

リソース要件:

Small | Medium | Large

4vCPUs | 8vCPUs | 16vCPUs
16GB | 24GB | 32GB RAM

参照:http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-D2121DC5-1FC8-48DC-A4BA-C3FD72D0BE77.html

Platform Services Controller

リソース要件:

2vCPUs
2GB RAM
参照:http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-D2121DC5-1FC8-48DC-A4BA-C3FD72D0BE77.html

vCenter Heartbeat (今では非推奨)

もしも正味で比較しようとするとvCenterに完全な分散と高可用性が必要になりますが、これは出来ません。vCenter Heatbeatは今では非推奨ですが、何かしらを加えなければなりません。vCenterやVUMなどのリソースを2倍することになるでしょう。非推奨ということですし、今回はVMwareさんの仰るとおり、管理コンポーネントの高可用性のためのリソースを勘定に入れないことにします。

vCenterのリンクモードについては?

これに関するドキュメントを見つけることは出来ませんでした。ですからVMwareさんのおっしゃるとおり、オーバーヘッドは一切ないということで行きたいと思います。ですが、オーバーヘッドはさておき、別製品としてインストール、検証、維持管理しなくてはなりません。

vSphere Web Client

完全なVSANの管理、昨日を利用するためにはWeb Clientが必要になりますが、これはそれ自身のリソース要件があります:

4vCPUs

2GB RAM (最低要件)
参照:https://pubs.vmware.com/vsphere-50/index.jsp#com.vmware.vsphere.install.doc_50/GUID-67C4D2A0-10F7-4158-A249-D1B7D7B3BC99.html

vSphere Update Manager (VUM)

VUMはvCenterサーバ上にインストールすることも出来ます(これはWindowsへのインストールを行っている場合)、これは管理仮想マシンやOSの管理の削減になりますが、もしも仮想アプライアンス版を利用している場合には別のWindowsインスタンスが必要となります。

リソース要件:

2vCPUs
2GB

NutanixのCVMはメジャー、マイナーのAHVはもちろんのことESXiのパッチアップデートの機能を有しています。

vRealize Operations Manager (vROM)

NutanixはPRISM Element内にvROMが提供しているような分析の機能を組み込みで提供しており、キャパシティ計画/管理を一元的に行うことが出来、「what if」シナリオによってノードのクラスタへの追加の機能を提供しています。ですから、正味で比較するためにはvROMを加えて比較するのが正しいと思います。

リソース要件:

Small | Medium | Large

4vCPUs | 8vCPUs | 16vCPUs
16GB | 32GB | 48GB
14GB ストレージ

リモートコレクタ Standard | Large

2vCPUs | 4vCPUs

4GB | 16GB
参照:https://pubs.vmware.com/vrealizeoperationsmanager-62/index.jsp#com.vmware.vcom.core.doc/GUID-071E3259-625A-437B-AB34-E6A58B87C65B.html

vSphere Data protection

Nutanixは組み込みのバックアップ/リカバリ/スナップショットの機能をVSSによるアプリケーションとの整合性をもって提供しています。vROMと同様にNutanixのCVMとの比較にはvSphere Dta Protectionを加えるべきです。

vSphere Data Protectionは以下の様に0.5TBから8TBにて展開されます:

Fig033

参照: http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vmware-data-protection-administration-guide-61.pdf

最小で4vCPUと4GBのメモリを利用しますが、それでは0.5TBしかサポートされません。平均的な4TBを利用しようとすると4vCPUと8GBのメモリが必要になります。

VDPアプライアンス1台あたりではもっとも良くても8TBであり、これはNutanixの(もしくはVSAN Ready)ノードの幾つかよりも小さい値です(例 : NX6035/NX8035/NX8150)。ですからVSANを利用している場合にはVDPアプライアンスを各ノードに一つずつ展開するという可能性も出てきます。これはNutanixのようにVSANにはバックアップの機能が組み込まれていないからです。

さて仮想マシンのレプリケーションをしたい場合や、Site Recovery Manager(SRM)を利用したいという場合はどうなるでしょうか?

vSphere Replication

vROMとvSphere Data Protectionと同じようにvSphere RepliactionはVSANにNutanixではCVMに組み込まれている機能を提供します。正味の比較のためにはvSphere Replicationも含める必要があります。

vSphere Replicationのリソース要件はかなり軽いものでは有りますが、もしも全てのレプリケーションがこのアプライアンス経由になるとするとそのVSANノードはストレージとネットワークのトラフィックのホットスポットになり、ネットワークとノードを逼迫させたり、ノード上のすべての仮想マシンにとってのノイジーネイバー(やかましいご近所さん)になってしまう可能性もあります。

リソース要件:

2vCPUs
4GB RAM
14GB Storage
制限:

vCenterあたり1つのvSphere replicationアプライアンス
2000仮想マシンが上限
参照: http://pubs.vmware.com/vsphere-replication-61/index.jsp?topic=%2Fcom.vmware.vsphere.replication-admin.doc%2FGUID-E114BAB8-F423-45D4-B029-91A5D551AC47.html

ですから2000仮想マシンを超えて拡張しようとした場合、別のvCenterが必要になり、それはまた、別のVUM、Heatbeat(もしもまだあったとしたら)、そして更にSQLかOracle上の別のデータベースが必要ということになります。

Nutanixはこうした制限はありませんが、VMwareがおっしゃる通りでの比較にしたいと思います。

サポートするデータベース

小さなSQLサーバであったとしても大抵は最低2vCPUと8GB以上のメモリになり、完全な正味の比較をしようとするとバックエンドのデータベースサーバもNutanix AHV/CVMがそうであるように高可用性のサポートを加味しなくてはなりません。

ですから、小さな環境であったとしても2vCPUと8GB以上のメモリの仮想マシンが2つ必要で、それは単にvCenter、VUM、SRMなどのバックエンドのデータベースの要件だけです。

環境が大きくなるにつれ、vCPU/vRAMとしてストレージ(キャパシティやIOPS)要件も大きくなることを覚えておいてください。

さて、VSANの小さな4ノードのクラスタのオーバーヘッドとして何が適切か?

以下のテーブルは上で述べてきたそれぞれのコンポーネントの最低要件を元にVSAN(完全に等価ではありませんが)とNutanix CVMの提供している機能を比較したものです。

Fig034

上は小さな、例えば4ノードの環境での最低要件しか採用していません。vSphere Data Protectionは複数インスタンス必要になるでしょうし、SQLは高可用性を実現するために常時稼働可用性グループ(AAG-always on availability Group)を利用しすべきで、2つ目のSQLサーバが必要になります。そして環境が大きくなればvCenter、vRealize Operations Manager、SQLのvCPU/vRAM要件も高くなります。

一方でNutanix AHV環境は以下のようになります:

Fig035

結果として4ノードクラスタのための32vCPUと64GBのメモリという値はvSphere/VSANの4ノードのソリューションに比べて8vCPUそして54GBも少ないということになります。

もしNutanixのスケールアウトファイルサーバ機能(オプションで有効にできます)を加えたとしても値は48vCPUと100GBのメモリで、vSphere/VSANと比べてvCPUが8つ多くなりますが、メモリは18GB少ないことになり、それでもNutanixはそれ以上の機能(例えばスケールアウトファイルサービス)を提供していますし、箱から取り出してたままで完全に分散された、高可用性のある、完全に統合された管理スタックを備えています。

NutanixのvCPUの数はすべてのvCPUを利用することを前提で数えており、これは殆どの場合起こりえません。ですからこの比較はNutanixと比べVSANを利用している際にvSphere/VSANに高いオーバーヘッドがあるということと、Nutanixは組み込まれた機能、例えばスケールアウトファイルサーバ(これもまた分散された高可用性のあるソリューションです)などの追加機能を提供しており、vSphere/VSANよりもちょっと多くのリソースを利用するだけで、vSphere/VSANの提供していないファイルサービス機能が利用できるということを上手く顕しています。

もし、こうしたvSphere/VSANのすべての機能を利用せず、つまりこれらの管理仮想マシンを展開しないとしたら、VSANのオーバーヘッドは低いというのは正しいのか?

すべてのvSphere/VSANの機能を利用しないので、展開する必要がないという議論もあると思います。それではそれによってvSphere/VSANの要件(やオーバーヘッド)は小さくなるのでしょうか?

同じ仮定はNutanixのコントローラVMについても同様のことが言えます。

お客様がすべての機能を利用する必要がなく、I/O要件も軽いという場合にはCVMを6vCPUにダウンサイズするということも少なくありません。私自身、今週とあるSQL/Exchangeを動作させているお客様でこれを実施しました。インライン圧縮を行いながら、ビジネスクリティカルアプリケーションを動作させている際にCVMは75%あたりで動作しており、これは大体4vCPUでした。

結局のところ、オーバーヘッドはワークロード次第で、標準のサイズはvSphere/VSANコンポーネントでもNutanix CVMでも変動するのです。

さて、インカーネルのくだらない話へと戻りましょう。

VMwareは自分自身のハイパーバイザーが非常に大きなオーバーヘッドがあるので、ストレージをそれを通して動作させるのは難しいというFUDを広めるのが好きなようです。これを見るたびにVMwareはこれまで市場に対してハイパーバイザのオーバーヘッドは小さい(実際に小さい)と言い続けていたので、変だなと感じます。けれどもVMwareは自身の商品のためにお天気のように言葉を翻しました。

こうしたFUDの例はVMwareのチーフテクノロジストDuncan Eppingのツイートです:

Fig036

訳注: どうしてインカーネルがいいのか?と聞く前に 幾つかのステップを省略できる!

ツイートにはハイパーバイザを経由して別の仮想マシン(この場合、Nutanix CVM)へアクセスするのは効率的ではないという意図で書かれています。これはいくつかの理由で非常に興味深いものです:

  1. もしもそんなにもハイパーバイザを経由して仮想マシンから別の仮想マシンへと通信するオーバーヘッドが高いというのであれば、どうしてVMwareはビジネスクリティカルな、高いI/Oを要求するようなアプリケーションで、仮想マシン同士(そしてESXi同士)がデータアクセスを相互に行うようなアプリケーションをカーネル上で動作させることを推奨しているのでしょうか? 例: Webサーバ仮想マシンはアプリケーションサーバ仮想マシンへアクセスし、さらにそこからデータベースへとアクセスするような構成、それぞれが各々仮想マシンでカーネルを通じて別の仮想マシンへとアクセスする。
  2. VSANは以下に上げるような機能でそれを利用している:
  • レプリケーション(vSphere Replication)
  • vRealize Operations Manager (vROM)
  • vSphere Data Protection (vDP)
  • vCenter と それをサポートするコンポーネント

VMwareのもう一つのFUDの例として今回はプリンシパルエンジニアである Jad Elzeinのもので、VSANはNutanix(BlockはNutanixの「Block」のことです)に比べてオーバーヘッドが小さいという事を意図したものです。

訳注: 10ブロック=40ノード = 40管理仮想マシン = 80vCPUと1TB以上のメモリが管理のためだけに! オーマイゴッド!

思うに、VSANの機能やvSphereの基本管理機能に必要な仮想マシンの数(とリソース)について忘れてしまったのだと思います。インカーネル(もしもまだ何らかの優位点があるということを信じているのであれば)の優位点の全てはハイパーバイザーとインカーネルではない管理仮想マシン間の恒常的なトラフィックによって以下の図のように殆ど消えてしまいます:

Fig038むしろ、#AHVisTheOnlyWay(AHVこそが進むべき道だ)そして#GoNutanix(Nutanixを使おう!)というのが正解です。AHVのオーバーヘッドはvSphere/VSANよりも小さいのですから!

まとめ:

  1. Nutanix CVMは完全に統合された、事前構成済みの、高可用性を備えた、自己修復管理スタックを提供します。vSphere/VSANは多くのアプライアンスやソフトウェアを追加でインストールする必要があります。
  2. Nutanix AHVの管理スタック(CVMによって提供される)は8vCPUと大抵は16GBのメモリのみで、その中で多くの場合vSphere/VSANを超える能力を提供します。vSphere/VSANは同等機能を提供しようとすると(実際には同等にならないことも多いですが)非常に多くのリソースを利用します。
  3. Nutanix CVMはこれらの機能を様々な多くの仮想アプライアンス、仮想マシン、またはサードパーティのデータベース製品に頼るのではなく組み込みで提供します(PRISM Centralだけは別の仮想アプライアンスで例外ですが)。
  4. Nutanixの管理スタックは競合製品に比べより優れた堅牢性/高可用性を備え、しかもすぐにそれが利用できます。クラスタが拡張されるにつれAcropolis管理スタックが自動的に管理機能を拡張し続け、リニアな拡張性と一貫したパフォーマンスを保証します。
  5. 次にVMware/EMCがNutanix コントローラVMについて、リソースの大食漢であるとか、そのたぐいのFUDを広げようとしていたら、それはどの機能についての話なのか聞いてください。おそらくここで述べたようなポイントは考慮していませんでしょうから、お勉強として上の記事を読むようにさせてください。
  6. Nutanix AHV管理は完全に分散されており、高可用性を備えています。VMwareにvSphere/VSANの管理コンポーネントを完全に高可用性を備えた状態にする方法を聞いてみてください。ついでに、設計、インストール、検証、維持管理のためのプロフェッショナルサービスにいくらかかるかも。
  7. 次の会話は「Nutanixと比べてVSANはどれだけのコストがかかるの?」です。今回全てのリソースのオーバーヘッドとvSphere/VSAN環境の設計、実装、検証が複雑であるということを知りましたが、vSphere HA以外にほとんど管理コンポーネントを守るすべがないということまではお話しませんでした。しかし、コストの話はELAやライセンシングコストの話をしなくてはなりません。あまり興味わかないですよね。

VMware/EMCにいるお友達へ、Nutanix CVMはこう言っていますよ。

「あっちへ行って、見くびっていてください。」

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

どうでしょう(笑)!? そもそもかなり偏った角度からの記事です。どうしてもFUDを払拭したかったのでしょう(ありがたいことに、全部引用元を明らかにしてリンクがついている・・・)。今後はCalm.ioを買収したのでvRealize Automationも加えないといけないとか、NutanixがPernixDataを買収したのでやっぱりインカーネルが必要・・・と思ったりしている人もいるかもしれません。

今回、この記事を取り上げたのは最近の翻訳記事で繰り返しお伝えしているとおり、変な色眼鏡で技術を誤解してほしくないということをお伝えしたかったからです。Guidoさんや今回のJoshさんのようにしっかりと技術的に確認して、何が正しいのか見極めてください。

2016/10/05

VMwareのSCSIコントローラのオプション

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はVMware SCSI Controller Optionsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

今回の記事ではVMware ESXi内の様々なSCSIコントローラについてと、なぜ最終的に他のものよりこのオプションが優れるのか、ということを解き明かして行きたいと思います。私は現職で様々なお客様と、どういう状況においてはLSI Logis SASやParallelがParavirtualized(準仮想化) SCSIアダプタ(PVSCSI)に対して優れるのかという様々な議論を交わしてきました。そしてその結果、私の考える本当の理解とその違いについて上手く説明しているブログの記事やKBが無いということに気が付きました。殆どの環境ではOS標準のアダプタが選択されており、多くの場合、それで良く、上手く動いています。問題が起きるのはどこかに制限があったときであって、どのようにそれを見つけるかではありません。でははじめていきましょう。現在のESXi 6.0のヴァージョンでは5つのSCSIコントローラを選ぶことが出来ます。それをまとめたのが以下のテーブルです。

SCSIコントローラの比較

アダプタタイプ
OSタイプ
最低要件
最大SCSIアダプタ数
ユースケース
BusLogic Parallel
サーバ
-
4
コントローラあたり15デバイス、64ビットOSと2TBのVMDKの問題、VMwareはこのアダプタからの移行を推奨している
LSI Logic Parallel (以前のLSI Logic)
サーバ/デスクトップ
-
4
コントローラあたり15デバイス、Microsoft Clusteringサービスに必要(Windows 2008より古い場合)
LSI Logic SAS
サーバ/デスクトップ
HWv7
4
コントローラあたり15デバイス、ほとんどのOSの標準のSCSIコントローラ、MSCS(Windows 2008以降で必要)
PVSCSI
サーバ
HWv7
4
コントローラあたり15デバイス、I/Oの多い殆どのユースケースにおいてはCPU利用率が低い、ESXi 5.5u2以前ではMSCSをサポートしない
AHCI SATA
サーバ/デスクトップ
HWv10
4 (既存のSCSIコントローラ上で)
コントローラあたり30デバイス、I/Oの多い環境では推奨されない、LSI Logic SASまたはPVSCSI程効率的ではない

アダプタタイプ

見るとおり、AHCI SATAコントローラはさほど大きなメリットを産んでいません。このコントローラは追加ディスクを大量に必要とするような場合を想定しており、パフォーマンスについては問題としていないのです。AHCI SATAコントローラは既に利用しているSCSIコントローラ上に追加することが可能です。

それぞれのアダプタがいつからサポートされているのか、ということを知るのも重要ですので、以下のテープルにまとめました。

機能
ESXi 6.0
ESXi 5.5
ESXi 5.1
ESXi 5.0
ESXi 4.x
ESXi 3.5
ハードウェアヴァージョン
11
10
9
8
7
4
サポートされるSCSIアダプタ
BusLogic
LSI Parallel
LSI SAS
PVSCSI
AHCI
BusLogic
LSI Parallel
LSI SAS
PVSCSI
AHCI
BusLogic
LSI Parallel
LSI SAS
PVSCSI
BusLogic
LSI Parallel
LSI SAS
PVSCSI
BusLogic
LSI Parallel
LSI SAS
PVSCSI
BusLogic
LSI Logic
ESXiのサポート

x86アーキテクチャ

さて、もっとも面白そうなアダプタはLSI Logic SASとPVSCSIであるということに疑問はなくなりましたか? この「Paravirtual(準仮想化)」という言葉は一体どういうことを意味するのでしょうか?これについてお話する前に、ドライバがスタックのどこに位置しているのかを見ていきましょう。x86アーキテクチャでは常に4つのレベルもしくは特権を目にします。それらはリングまたは、CPUモードと呼ばれており、リング 0~3に分けられます。従来からのWindowsのようなOSはリングを2つだけ利用してきました。これはその時に利用できるプロセッサが2つ以上のモードをサポートしていなかったからです。あらゆるアプリケーションが利用する最低限の特権しか有しないリング3とすべての権限を利用できるリング0です。ですから、ユーザーアプリケーションがハードウェアを利用しようとする度にCPUはユーザーモードへと切り替わる必要があります。もし、もっと詳しく知りたいということであればカーネル vs ユーザーモードという記事を読んでみてください。次の図はx86アーキテクチャでの従来型のモードを顕しています。

Fig029従来型x86アーキテクチャ

VMMを利用したバイナリトランスレーション

仮想化された環境ではハイパーバイザ自身が物理ハードウェア上で動作します。ゲスト仮想マシンOSがリング 0で動作することは非常に難しくなります。これはリング 0をハイパーバイザー自身が利用しているからです。更に複雑なことに、特定の操作はリング 0で実行しなければ完了できないというものが有ります。では、どうやっているのでしょうか? VMwareはバイナリトランスレーションと呼ばれる手法を利用して、仮想マシンモニタ(VMM)をリング 0で動作させています。これによって仮想マシンがこうした操作を行う際にリング 0で動作しているVMMの力を借りて実行することが出来るようになります。アプリケーション自身にとっては何も変わってはいません。次の図にこれを顕します。

Fig030OSのリクエストでバイナリ変換

ESXi内のParavirtual(準仮想化)実装

Paravirtual SCSIアダプタという名前は意味合いで言うとちょっと間違っています、これは全てのゲスト仮想マシン内のすべての仮想化ハードウェアはparavirtual(準仮想化)だからです。全く同じことがVMXNET3ドライバという固有のVMwareのドライバについても当てはまります。いずれの場合もゲストOS内にドライバをインストールして、このアダプタを利用できるようにしなくてはなりません。VMXNET3ドライバについてはこれはVMwareツールがインストールされた際に既に完了しています。

paravirtualドライバを利用するとESXiカーネルへアクセスすることが出来るようになり、システムハードウェアと通信する際にVMMを経由しなくても良くなります。ESXiに対して「ハイパーコール」を実行し、スケジューリング、割り込み、メモリ管理などの重要な操作を実現します。ですから、これはドライバの観点からはカーネルとのダイレクトチャンネルのようなものです。PVSCSIアダプタは他のSCSIコントローラのオプションに比べ一般的には優れたパフォーマンスを低いCPU利用率で提供することが出来ます。ですが、全ては時と場合次第です。次のセクションではLSI Logic SASとPVSCSIをもっと比較します。以下の図は一般的な「ハイパーコール」を利用するparavirtualアダプタの実装を顕しています。

Fig031 ESXi内のParavirtual(準仮想化)実装

合成

合成(Coalescing)は融合(merge)、結合(join)、assemble(組み上げ)の類義語ですが、ゲスト仮想マシン内のSCSIコントローラではどういう意味を持つのか?とても簡単で、I/Oを非常にうまいやり方で最適化します。少しだけ合成がどういう意味を持つのかを挙げてみます。

  • ストレージドライバを効率化する手法
  • 合成はある種のバッファで、複数のイベントが同時実行の待ち行列していると考えると良い
  • 効率と割り込みを改善しますが、そのためにはI/Oは大きなバッチリクエストとして生成出来るようにある程度高速な流れでなくてはならない
  • もしも流入するI/Oがおそすぎて、タイムアウト期間まで待たなければいけない場合、I/Oは不必要に遅延が起きることになる
  • LSI Logic SASとPVSCSIの両方は合成に割り込みをかけるために2つの異なる方法を用いています:
    • 行われるI/O数(outstanding I/O) : 仮想マシンのI/O要求数
    • IOPS : ストレージシステムが提供できるI/O

では、この2つが双方のアダプタでどのように動作するのかを比較してみましょう。

  1. LSI SAS : ドライバは行われるI/O数(Outstanding I/O:OIO)とIOPSが増加するに連れて合成を増やし、OIOが殆ど無い場合やスループットが低い場合には合成を行いません。ですから、OIOとI/Oスループットが小さい際には非常に効率的です。
  2. PVSCSI : ドライバはOIOベースでのみ合成を行い、スループットは考慮しません。仮想マシンが多くのI/Oを行っているときでも、ストレージにそれがすぐに伝わるということはなく、PVSCSIドライバが合成の割り込みを行います。ストレージに一定の流量のI/Oが無い場合、もちろん合成のための割り込みは必要ありません。結果として、わずかばかりですが、レイテンシが上がることになり、PVSCSIコントローラではスループットの低い環境では得るものは無いということになります。
  3. CPUコスト : LSI Logic SASとPVSCSIコントローラの違いはIOPSが低い場合にはその差は図ることが出来ない程度ですが、多くの数のIOPSであればPVSCSIではCPUサイクルを劇的に削減することが出来ます。

VMwareによると、2,000IOPSのピークパフォーマンス、または4OIOあたりでの切り替えがよいということがKB107652に記載されています。さらに新しいヴァージョンのESXiに於いてはもっと低いIOPSやOIO要件においてもPVSCSIを利用することを推奨しています。

キューデプス(Queue Depth)

パフォーマンスを最大化するためには仮想化ディスクが出来る限り多くのvSCSIアダプタに分散しているのが良いということになります。最大で4つのvSCSIアダプタが仮想マシンに対して構成でき、一つのvSCSIアダプタ毎に最大で15の仮想化ディスクが利用できます。複数のvSCSIアダプタを利用することでより多くのI/Oキューを利用することが出来るということです。以下のテーブルはPVSCSIアダプタを利用したときと、LSI Logic SASアダプタを利用したときのキューデプスを比較したものです。

キュー
PVSCSI
LSI Logic SAS
アダプタのキューデプスの標準値
256
128
アダプタのキューデプスの最大値
1024
128
仮想ディスクのキューデプスの標準値
64
32
仮想ディスクのキューデプスの最大値
254
32
キューデプス

PVSCSIのチューニング

とてもよいKBがあります : VMware KB 2053145 理解すると仮想マシンだけでなく、ESXi自身の様々なパラメータを変更しながらチューニングを行えるようになります。2つの設定項目がチューニングできます:

  • ESXiホスト上のHBAのキューデプスの調整
  • WindowsもしくはLinuxゲスト内部からPVSCSIのキューを増やす

注意 : 標準のリングのページは8つで、それぞれが4KBのサイズとなっています。一回のI/Oのキューに関しては128バイトが必要とされます。つまり、32回で単一ページの4096バイトを利用することになり、結果として256回のIOができることなります(8x32)。WindowsのPVSCSIドライバアダプタのキューは以前のリリースではハードコーディングされていましたが、VMwareツールで提供されるヴァージョン以降では最大で32ページまで調整して増やすことが可能です。

ここにKBから抜き出した注意書きを書きましたが、これはどういう意味なのでしょうか?リングページとキューデプスが本当はどういう意味で、どのように誤解されているかを説明していきます。

リングページ :

128バイトと言う単位はI/Oのことを指しますが、これはI/Oが直接入出力される実際のメモリのことではありません。ページは実際のI/O操作を行うためのリングバッファによって利用されるメモリのことを指しています。実際のI/O自身にはこれは利用されません。これはDMA操作で利用されるポインターを格納しているページだと考えてください。ページのうちの一部分(非リングページ)があるI/Oに使われる場合がありますし、残りの部分(もちろん、かぶる場合もあります)が別のI/Oで利用される可能性があります。ですから、これ以降の操作が可能になるのです。

キューデプス :

キューデプスの数はPVSCSIの場合にはアダプタの制限を反映したものになります。アダプタは8つのリングページを利用するので、256のキューデプスをサポートします。PVSCSIは実際のデバイスではなく、VMwareの準仮想化SCSIデバイスですから、これは自然にはありえない値になっています。しかしながら、他のデバイス(実際のアダプタ)では、実際のハードウェア上の制限です。リングはハードウェア内にあり、制限を受けますので、そこでキューデプスです!キューデプスはアダプタ毎に存在します。ですから、もしもPVSCSIや他のLSIアダプタであれ、4倍の数のキューデプスを利用することが出来ます。つまり、それぞれ4つのリングページが有るのです。

LSI Logic :

構造は良く似ています。唯一の違いはハードウェアコントローラに実際のHBAのキューリソースによって上限が設定されていることです。ですが、ドライバーは恣意的にハードウェアが利用できる値よりも低い値で動作するようにします。もし、HBAが言う以上の高い値を設定したとすると、ESXi SCSI mid-layerのキューに行列するのではなく、ドライバ内に行列することになります。この場合、キューの遅延を考慮しなくてはなりません。

結論

さて、ここまででの結論はどうなるでしょうか? 人生における他のすべてと同じように、何を望んでいるかによってマチマチだ、ということになります。私が考えるには出来る限りはPVSCSIコントローラを利用するのが良いということになります。以前の会社では1500台以上の仮想マシンを動作させていました。あるとき、確か2010年だったと思いますが、既に80~90%の仮想化を終え、どこでLSIを利用すべきで、どこでPVSCSIを利用すべきなのかを環境の中で行っていくことは地獄のような作業になるということに気が付きました。加えて、当時のモニタリングツールは今日のものに比べとてもひどいものだったということもお伝えしておきます。結果として私はインフラストラクチャのアーキテクトとして3VMしか起動しないような小さな単独のESXiサーバであれ、集中管理されたデータセンタ内の巨大なERPシステムであれ例外なく全てのテンプレートで同じ構成のPVSCSIを利用するということにしました。既存で稼働していた仮想マシンについてもメンテナンス時間のタイミングで既存のSCSIコントローラからPVSCSIアダプタへの置き換えを行いました。おそらくはI/Oをほとんどしないような小さな仮想マシンにとっては全くメリットはなかったはずですが、I/O要件の高い仮想マシンにとってはもちろん、助けになったはずです。もちろんこれは私の過去の決断です。仮想マシン内のSCSIコントローラを変えるということは大きな労力となりますので、ダウンタイム時に変更するというのは正しい選択だったと思っています。

チューニングを行う一方で、注意しておきたいのは、利用しているストレージシステムのパフォーマンスがどんな様子なのかということです。もしもそうでないのであればこうしたパラメータを変更しても全く変化はありません。数年前まで、私はコントローラもしくはSCSIコントローラのキューデプスを調整することで常にパフォーマンスが改善できると考えていましたが、実際にはストレージシステムとサーバとストレージの間のスタックに依存することがわかりました。もしもキューから溢れてしまったI/Oを処理するものがなければ、多くのI/Oでキューを埋めるということは全く意味をなしませんが、もしもストレージがそれでも高速に動くのであればボトルネックとなっている仮想マシン側の問題にはこれで対処が可能です。ストレージシステムのパフォーマンスが良いとはどういうことか? これは検証や調整の末に見つけ出さなければなりません。もっとも簡単な方法はWindowsのパフォーマンスモニタなどのローカルOSのツールを利用して、平均ディスクキューの長さがアダプタの制限に張り付いていないかを確認することです。さらに、PVSCSIアダプタの数を増やすことで効果があるのはストレージがその取り回しに苦労しているときだけです。以前出来る限り多くのディスクとコントローラにまたがって構成を行い、負荷を可能な限り分散しようとする同僚がいたのを思い出します。ですが、結局はストレージがボトルネックになり、単に構成が複雑になっただけでした。ですから、出来る限り増やすのが良いということではなく、98%のシステムにおいては出来る限りシンプルにしておくのが良いと思います。残った2%はその必要があれば集中して調整を掛けていくのが良いと思います。

もし、ご質問があればどうぞ。

情報ソース、インスピレーション:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1017652
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010398
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1037959
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1267


ブログ:
https://blogs.vmware.com/vsphere/2014/02/vscsi-controller-choose-performance.html
https://pelicanohintsandtips.wordpress.com/2015/09/23/vmware-paravirtual-scsi-adapter-pvscsi/
https://clearwaterthoughts.wordpress.com/2011/05/06/virtual-scsi-adapters-vs-para-virtual-scsi-pvscsi-adapters-vs-vm-direct-path-io/

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

さて、前回はカーネルの中のお話でしたが、今回はVMwareが提供している準仮想化ドライバを利用して仮想マシンのI/Oをチューニングしていくと言う話です。結果としてはPVSCSIに落ち着くということなのですが、SCSIドライバの中の話(リングページやキューデプス、またはIOの合成)などは特に理解せずに利用していた方が多いのではないかと思います。

この話を翻訳しようとしたのは「カーネル vs ユーザーモード」の話を宗教戦争ではなく掘り下げて理解していただきたかったことと、例えば、途中のPVSCSI(準仮想化ドライバ)の図のように、PVSCSIを利用すればVMMを経由せずにダイレクトにI/Oを実行できることなどを知った上で、議論に参加してほしいからです。VSANやPernixData(今はNutanix) FVPはVMMからコンテキストチェンジを発生させずにI/Oをフラッシュ(FVPの場合はメモリにも)に届けることでデータパスを短くしていますし、NutanixのCVMは今回ご紹介したようなテクニックを利用してデータパスを短くしています。どっちがいいのか? Guidoさんが言うように人生における他の全てと同じく、目指しているもの次第なわけです。

3回に渡ってGuidoさんの記事を翻訳し、カーネル vs ユーザーモードの話、特にI/O周りのアーキテクチャの話をしてきましたが、次回はI/O周りだけではなく、ソリューション全体での比較を取り上げたいと思います。

Stay Tuned!

2016/09/28

VMware ESXi ストレージ IO パス

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はVMware ESXi Storage I/O Pathをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

私にとってESXiの中をIOがどのように流れていくのは長い間謎に包まれたものでした。もちろん、私はパス選択ポリシー(PSP)がどういうもであるのかや、ストレージアレイタイププラグイン(SATP)がどういうものかということは知っていましたし、vSCSI statsについても聞いたことが有りましたが、それでもI/Oのフローについて深く説明するということは出来ませんでした。仮想マシンから出たI/Oがどうにかしてカーネルに入っていく、というぐらいしか知らないようなものだったのです。それでもESXTOPのようなstatsコマンドで特定のパフォーマンスの値を監視したり、PSPのレベルでベンダーが推奨する通りの設定を行い、パフォーマンスを監視するということは出来ます。そして、そう、RAWデバイスです。これはまた別のストレージプロトコルやキューが登場します。ですが、これは全体でどのようになっているのでしょうか?

このブログの記事はストレージ IO パスについて一定のレベルでの詳細をご説明します。エンジニアリング(製品開発部門)と緊密に動くことの良い点は日々非常に多くの事を知ることが出来ますが、それを自分のものにしていくことが難しくなるのです。ですから、この多くの情報をより深く調べ、最終的にはブログの記事にまとめることにしました。もちろん、ESXi 6 U1にはVAIO(vSphere API for IO Filtering)フレームワークが追加されていますが、これについては別の記事に後でまとめたいと思います。VAIOを利用すればベンダーはユーザーワールドのコンテキストで動作するフィルタドライバーを経由してしっかりとVMwareのコントロール下に置かれたやり方でI/Oに割り込む方法で開発を行うことが出来ます。今日の時点ではVAIOはまだ新しすぎて、殆どのベンダーはVAIOを利用する製品をリリースすることが出来ていません。どうしてこんなことを書くのかって? それはPernixDataの(そして、今はNutanixの)フラグシッププロダクトであるFVPとストレージ分析ソフトウェアであるArchitectはESXiのプラガブルストレージアーキテクチャ(PSA)で統合されています。更にVVOLによってストレージの管理は著しく簡単になろうとしています。ですが、私はテクニカルサポートエンジニアとして日々過ごす中で、VVOLについて考えはじめ、もしくはさらに次のインフラストラクチャが登場するのではないかと考え始めています。VMwareは既にVVOL以前にポリシードリブンストレージマイグレーションで素晴らしい結果を上げており、私の対峙している顧客は十分満足しています。結果として、VVOLについて考えるのが後回しになっているのです。

仮想マシンからの全てのIOはユーザーワールドのコンテキストでvCPU、VMX、MKS、SVGAなどのそれぞれから、異なるスレッド(ワールド)で開始します。ユーザーとカーネルモードのち我について理解するためには私の最初の記事カーネル vs. ユーザーモードをご参照ください。仮想マシン自身のマネージャーはVMM(仮想マシンモニタ)です。

それからIOは基本的にはVMkernelを通じてどんなアクションが行われるか、そのストレージ実装が利用されているかによって様々なジャンクションを通っていきます。

  • Block Storage(ブロックストレージ):
    • Fibre Channel (FC)
    • Internet Small Computer Systems Interface (iSCSI)
    • Fibre Channel over Ethernet (FCoE)
  • File Storage(ファイルストレージ):
    • Network File System (NFS)

すべてのI/OはVMMレベルで開始されるため、ここまではスキップしてvSCSIフロントエンドからのI/Oフローをご説明していきます。I/OがユーザーワールドからvSCSIフロントエンドへ流れていく部分は非常に面白いです。そして、VMXNETやPVSCSI実装などの準仮想化実装とどう違うのかがわかります。

ESXi I/O フロー

  • vSCSI フロントエンド:
    • フラットバックエンド(VMDK)またはRDMバックエンドのIOの両方が流れてきます。
    • それからI/OはFSS(ファイルシステムスイッチ)へと流れ、その後、DevFS(スナップショット関連のI/O)、VMFSレイヤ、NFSレイヤのいずれかへと導かれます。
    • NFSの場合、その後、ESXiのSUNRPC実装とTCP/IPスタックを経由してVMカーネルインターフェイス(vmk)へとI/Oが進んでいきます。
    • VMFSの場合、道はFDS(ファイルデバイススイッチ)へと続き、そこで、ディスク(通常のスナップショットのないI/O)、スナップショットドライバ、またはLVM(ロジカルヴォリュームマネージャー)へと分岐します。
      • ディスク : 通常のVMDKのI/O。
      • スナップショットドライバ : 仮想マシンがスナップショットを発行するか、スナップショット上で動作している場合、すべてのI/Oは再度FSSへと送られ、スナップショットの連鎖はDevFSの実装を通してマウントされます。
      • LVM : ディスクが作成、拡張、結合された場合。
    • I/OはPSA(プラガブルストレージアーキテクチャ)へと進んできます
      • デバイスキューは2つのエリアに別れます:
        • SCSIデバイス
        • SCSI Sched キュー
      • ここへ至ったIOは殆どの場合、NMP(ネイティブマルチパシングプラグイン)かEMCがPowerPathと呼んで提供している完全なプラグイン実装へと流れていきます。今回はNMPのみにフォーカスします。
        • SATP(ストレージアレイタイププラグイン) ストレージシステムとの連携を実現するコントロールプレーン
        • PSP (パス選択ポリシー) ストレージ自身へのI/Oを制御するデータプレーン
      • 最後にI/Oは物理的なHBA、キューイング、SCSIエラーを管理するSCSI Midlayerへと到達します。ESXiのSCSI Midlayerについてもっと詳しく知りたい場合にはこのリンク先のVMware SAN System Design and Deployment Guideの58ページもご参照ください。

以下の図はI/Oフローの詳細をそれぞれのパーツを結合して顕したものです。

Fig028

ESXiのストレージ実装

VMM:

仮想マシンモニタ(x86 CPU、SCSIコントローラをエミュレーション、等)

共有リング:

共有リングはVMMとVMカーネルの間の共有キューで、VMMもしくはVMカーネルの両者はパフォーマンスのペナルティなくこの共有リングへアクセスが可能です。共有リングのサイズは発生させられるI/Oの数を決めてしまいます。VMカーネルが共有リング内のI/Oを見つけるとすぐに、このI/Oをキューから取り出し、vSCSIフロントエンドへと送ります。もっと詳しく知りたい方は以下のKBを参考にしてください。

ソース : VMware KB: 2053145

vSCSI:

VMカーネルのSCSIフロントエンドで、SCSIリクエストと仮想化されたファイルへのI/Oリクエストを送信します。

Flat Backend(フラットバックエンド):

ファイルをエミュレーションします。

RDM Backend(RDMバックエンド):

RAWのLUNへのポインタ/シンボリックリンクです。リンク内に識別子が埋め込まれます。

FSS (ファイルシステムスイッチ):

ファイルシステムのドライバを実装する際に利用できます。APIは公開されていません。

DevFS:

殆どのUNIXベースのファイルシステムと非常によく似ており、実デバイス、非実デバイスをエミュレーションします。

VMFS:

VMFSの3と5の両方を実装した単独モジュール。

NFS:

NFSプロトコルを実装しています。

FDS (ファイルデバイススイッチ - ブロックストレージ):

ディスク、スナップショット、そしてLVMの切り替えに利用されます。

ディスク:

すべてのディスクベースのブロックデバイスをエミュレーションします。ストレージスタックと直接やり取りします。

スナップショットドライバ:

フィルタドライバとして実装されています。フィルタドライバによって、FSSへとIOが戻るため、ディスクが再帰的にDevFSへとマウントされます。

LVM (ロジカルヴォリュームマネージャ):

削除、結合、作成などが発生した場合にはLVMへと司令が送られます。LVMはヴォリュームの結合を行い、論理領域としてヴォリュームを上のレイヤへ見せます。VMFSとしてデータストアをフォーマットすると以下のように動作します:

  • はじめにLVMに論理ボリュームが作成される
  • それから、そのヴォリュームがVMFSでフォーマットされる

このようになる理由はディスクが異なるLUNをまたがって拡張、結合される可能性があるからです。もちろん、再署名 例えば、スナップショットされたLUNでは同一のUUIDが利用されているので、LVMによって再署名される可能性があります。

PSA (プラガブルストレージアーキテクチャ):

SCSI デバイス:

すべてのローカル、そしてリモートのデバイスはSCSIデバイス構造になっています。(ターゲットあたり256以上のLUNは存在し得ない)


SCSI スケジュールキュー:

ストレージスタックは比例型の共有スケジューラ(シェア)を実装しています。SIOC(ストレージ I/Oコントロール)はこれをクラスタベースで行うものですが、SCSIスケジューラーキューを利用しています。シェアの値には全てのSCSIディスクの数が利用されます。

SATP (ストレージアレイタイププラグイン - コントロールプレーン):

ベンダー固有の機能を有しています。例: Trespass : LUNで利用可能なSP(サービスプロセッサ - ストレージシステムのコントローラ)のアクティブ-パッシブを制御します。また、I/Oが異なるSPから流れ込み、そのためにその異なるSPへと接続してI/Oを受けたなどを状態を理解することも可能です。SATPは障害時にもストレージとのコミニュケーションを行います。

PSP (パス選択ポリシー - データプレーン):

PSPはバックエンドのストレージにどのようにReadとWriteを提供するかを司ります。PSPには3つのフレーバがあります : MRU(もっとも直近で利用したパス)、Fixed(固定)、そしてRR(ラウンドロビン)。

  • Most Recently Used (MRU): VMW_PSP_MRUポリシーは利用可能な最初のパスを選択します。このパスはシステムのブート時に検知されます。パスが利用できなくなった場合、ESXi/ESXホストは別のパスへとスイッチし、新しいパスが利用できる限りはそのパスを利用し続けます。これはアクティブ/パッシブのストレージ装置において論理ユニット数(LUNs)の標準ポリシーです。ESXi/ESXは万一、パスが復帰したとしても以前のパスへと復帰しようとはしません。利用している障害が起きないかぎりは、です。
  • Fixed (Fixed): VMW_PSP_FIXEDポリシーは指定された場合にはそのフラグが立っているパスを固定的に利用します。もし指定がない場合、システムのブート時に検知したパスの最初の利用可能なものを利用します。ESXi/ESXがその選択したパスを利用できない、もしくは出来なくなった場合、ESXi/ESXホストは別のパスを選択します。ホストは自動的に事前に定義されたパスが復帰するとすぐさまそのパスへと復帰します。このポリシーはアクティブ/アクティブのストレージ装置を接続したときのLUNsの標準ポリシーです。
  • Round Robin (RR): VMW_PSP_RRポリシーは自動的にパスを選択し、利用可能な全てのパスの中で負荷を分散しながら設定されたパスを利用します。
    • アクティブ/パッシブストレージ装置では、アクティブなコントローラのパスのみがこのラウンドロビンポリシー時には利用されます。
    • アクティブ/アクティブストレージ装置では、全てのパスがこのラウンドロビンポリシーで利用されます。

ソース: VMware KB 1011340

このブログの記事が少しでもあなたのお役に立てば。もちろん質問があれば、いつもどおり気軽にコンタクトください。

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

さて、前回に引き続き、Guidoさんの記事です。VMwareのカーネルの中(といっても、ストレージ部分だけですが・・・)をこんなに解説してくださっている記事はなかなか無いと思いましたので、前回のものと合わせて翻訳させていただきました。前回とは異なって、I/OがESXiの中をどう流れていく?ということを順を追って解説してくれています。さすが、カーネルの中でI/Oを捕まえてぶん回している会社(PernixData/今はNutanix)のサポートチーム・・・詳しい!もちろん、VSANについてはまた上の図の中に別の枝が出て実装されていますし、今後はVAIOでもっと面白い実装も出てくるのではないかと思いますが、あくまでベーシックということで。技術的に深すぎてNutanixもPernixDataもVSANも違いがなくなってきています・・・そんな技術を組み合わせてソリューションを生み出していく各社・・・。そして、我々はそれを理解した上で、お客様に最適なソリューションをご紹介するソリューションディストリビュータです。

次回もGuidoさんのふかーい記事を翻訳予定です。まだまだ続きます。

2016/09/21

カーネル vs ユーザーモード

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はKernel vs. Usermodeをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

私の生まれて初めてのブロク記事へようこそ! この記事はとても前に、ブロクを始めようと思った際に書いたものですが、その時にはいろいろな事情で公開しませんでした。 :) でも、ほら、ようやく公開することが出来ました。記事の内容についてはとても昔の内容から初まります。「ITインフラストラクチャ」という名前の大学の講義で、私がOSのカーネルの深みに初めて踏み入り、CPU内のキャッシュやCPUが実際にどのように計算を行っているとか、もちろんもっと多くの事を知った際の話からです。その時私はOSカーネルの中が非常なめらかで、その一方で非常に複雑であり、時には危険だということに驚きました。例えばメモリの上書き、C言語でのプログラミングで手続き上のオブジェクトが存在しないなどです。もちろん、あらゆるOSのハードウェアを利用するためのドライバーはRing 0で動作しています。ですから、複雑さは実際にはカーネル内で動作しているソフトウェアの機能によって大きく異なります。もちろん、品質についても同じです。さぁ、前置きはこれぐらいにして、記事の中身に入っていきましょう。

オペレーティングシステムは通常は非常に大きなプログラムで、コアコンポーネントはカーネルと呼ばれます。カーネルは全てのハードウェアリソースを司るオーナーでもっとも深いソフトウェアレイヤで動作しており、ハードウェアに直接アクセスを行うことが出来ます。カーネルが行っていることは:

  • アプリケーションへのインターフェイス(API)
  • CPU(中央演算装置)、ハードウェアデバイス、メモリ(スケジューラ、ドライバ、メモリ管理)のコントロール
  • リソースのスケジューリング 例 :アプリケーションの処理時間
  • リソースの構成 例 : ディスクのようなブロック指向のデバイスのファイルシステムへのマッピング
  • リソース競合の解消 例: リソースのキューイング、CPUリソースのロック
  • リソース~プロセッサ(をプロセスへ)、ディスク(をファイルへ)、メモリ(を仮想化メモリへ)~の仮想化
  • ファイルやデバイスのアクセスコントロールの監視

Exokernel、モノリシックカーネル、レイヤードカーネルなどのように、異なる目的に対して非常に多くの種類の異なるカーネルがありますが、それらの詳細の違いについて踏み入ることはしません。今日もっとも利用されている種類のカーネルはマイクロカーネルと呼ばれるものです。マイクロカーネルはすべてのWindowsワークステーション・サーバそして、LinuxをベースとしたOSやVMware ESXiでも利用されています。OSを様々なプロセスに分割、分けていく理由はクライアントが他のOSやアプリケーションでも良くしようというためです。ですからクライアントがリクエストを適切なサーバにメッセージを送信することで実行し、サーバは処理を実行します。マイクロカーネルは結果をクライアントに返します。以下の図にそれを示しました:

Fig026マイクロカーネル

マイクロカーネル固有の特性の幾つかは:

  • OSの一部を容易に置き換え可能
  • ドライバはユーザモードでもカーネルモードでも動作する
  • 物理I/Oアクセスの実装が難しい
  • コンテクストスイッチ(時にはタスクスイッチやプロセススイッチとも呼ばれる。単一のプロセスやプロセスのスレッドが別のCPUへと切り替わること)

ユーザーモード (ユーザープログラムで言う非特権モード) :

全てのユーザープログラムはこのモードで実行されます。ユーザーモードはメモリやハードウェアへの直接のアクセスを行いません。この理由はすべてのプログラムがそれぞれでメモリを書き換えると他のプログラム用のメモリを上書きしてしまい、衝突が起きてしまうからです。ユーザーモードのプログラムは通常はカーネルの観点からは信頼性のないソフトウェアとして取り扱われます。もし、ハードウェアリソースへのリソースが必要な場合にはその下のAPI(システムコール)を経由して手続きが行われます。

カーネルモード (システムモードとも呼ばれる):

このモードは全てのカーネルプログラムで利用されています。カーネルモードではプロセスがその下のすべてのハードウェアに直接アクセスを行います。CPUだけがカーネルとユーザーモードを同時に実行することが出来ます。ユーザーからカーネルモードへのスイッチは自動的に行われ、その際には割り込みが発生します。

マイクロカーネルの詳細への踏み込みはおこなわず、ここでは少々コンテクストスイッチにフォーカスしたいと思います。すべてのプロセスは単一、又は複数のスレッドで実行されます。プログラムはスレッドを利用して事実上の並立実行時間を設け、1つ以上のCPUで実行されます。上で述べたように、マイクロカーネルは全てのリソースを司ります。ですから、もしもプロセスがCPUで動作しようとするととても大きなオーバーヘッドが生じます。既存でCPU上で動作していた環境は以下によって抑制がかかります :

  • プロセスのステータス
  • プログラムカウンタ
  • スタックポインタ
  • ファイルのオープン状態
  • メモリ管理 : 実際の実行環境へのポインタ

メインメモリへの一回のアクセスの全てのステップで、CPU内のこのプロセスのキャッシュは全てが廃棄されます。これはもはや正しいキャッシュではなく、将来的にキャッシュのミスを引き起こすからです。すべてのプロセスがCPUを利用しようとする度にOSのスケジューラーはいつそのプロセスがCPUを利用するかを決め、実際にCPUを利用させるのです。

Fig027プロセスの状態

コンテクストスイッチはカーネル内でしか発生しません。ですから、もしアプリケーションがCPUのプロセスを利用したい場合には、ユーザーモードからカーネルモードへシステムコール経由で移行しなければなりません。ですから、ユーザーからカーネルモードへ恒久的にスイッチするということは非常にコストが高く、多くのCPUサイクルを利用します。カーネル内で直接動作するソフトウェアはオーバーヘッドを著しく減らし、パフォーマンスが向上します。仮想化の世界でのカーネル実装の2つの例は:

  • VMware VSAN
  • PernixData FVP

さぁ、まとめに入りましょう。アプローチの方法はその目的によって様々ですが、一般的には以下が言えるでしょう:

  • カーネルモードのドライバ/ソフトウェアは実際にOSのコアで動作する点や、加えてプログラムの方法も限定されているため非常に複雑ですが、実現できればパフォーマンス面からは非常に大きなメリットが有ります。セキュリティの面から考えても、カーネル内からは外からそれを行うよりはるかに簡単です。
  • ユーザーモードのソフトウェアは非常に強力で、それは安定性の実装が簡単であり、プログラミングフレームワークを数多く選べることからのメリットもあります。ユーザーモードとカーネルモードのソフトウェアを組み合わせた実装も目にすることが有ります。これはカーネルモジュールとのやり取りを必要とするようなケースがあるからです。これはユーザーモードで動作しているコアOS自身のデーモンプロセスなどで見られます。

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

いかがでしたでしょうか? OSの中身まで奥深く分け入らない、と言いながらもCPUの中で何が起きているか、などまで解説していますのでなかなかわかりにくいかもしれませんが、一昔前にある種の「宗教戦争」として勃発したインカーネル対仮想化ストレージアプライアンスをこれ以上ないぐらい低いレイヤからみた話としてご紹介しました。まとめのところにあるように、カーネル実装は強力ですが、複雑で、実装も難しい、けれどもパフォーマンスの観点からは大きくベネフィットが有ります。ユーザーモード実装はフレームワークを様々に選択できるため実装が簡単です。裏返しとしてコンテクストスイッチの発生の際にはCPUのキャッシュを廃棄したり、スケジューラーのサイクルを待たなくてはならないこともあります。また、私がとても気になったのは「ハイブリッド」の実装もあるよ、という一文です。

買収直後の記事ですし、深読みしてしまうところもありますが、宗教戦争のような絶対的な決着があるわけではなく、目的によってカーネル、ユーザーモードを使い分けるのが正しいということを覚えておいてください。そして、カーネルモードの実装例として上げられているPernixData FVPは現在はユーザーモードの実装例の代表格であるNutanix社の手の中にあるのです。さぁ、将来が楽しみですね。Guidoさんの記事は非常に深いレイヤからの知識を教えてくれ、いろいろな意味で面白いので今後も翻訳の対象にしていきます。お楽しみに!

2016/09/02

Platform9 OpenStackでの仮想マシンの高可用性

本記事の原文:Virtual Machine High Availability with Platform9 OpenStackの公開は2016年の8月24日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

Platform9について詳しく知りたい方は是非以下のWebセミナーへもアクセスください。

【Webセミナー】Platform9 Managed OpenStack Web&デモセミナー
話題!日本上陸直後のPlatform9 Managed OpenStackを徹底解説 & デモを実施

昨年、OpenStack Summit 東京での開催、先日開催OpenStack Summit Days Tokyo 2016の大成功、大規模な導入事例発表など、OpenStackの熱気はいよいよ日本国内へも押し寄せてきています。
しかし、OpenStackはオープンソースプロジェクトでそのものはフリーで提供されていますが、そもそもインストールが難しい、運用管理していく手間とコストが膨大になる、アップグレードがうまくいかないなど、一般的な企業のお客さまにとっては多くのハードルを抱えています。

本セミナーではOpenStackの5つの展開方法とそのメリット・デメリットを上げた上で、
Platform9社が提供するユニークなOpenStack-as-a-serviceについてご紹介致します。
これまでになかったアプローチでのOpenStackの利用開始、運用、そしてその効果についてあますところなくお伝え致します。
本セミナーへご参加方にのみ、Platform9 Managed OpenStackのフリートライアルアカウントをお渡し致します。是非奮ってご参加ください。

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

エンタープライズのためのあらゆるクラウド商品において、仮想マシンの高可用性(HA)はアプリケーションの可用性をインフラストラクチャの障害時にも維持するためになくてはならない機能です。高可用性を高所してクラウドを設計すればクラウドネイティブなアプリケーションだけでなく、従来型のアプリケーションの障害からの保護にも役立ちます。これまで、HAの機能はVMwareやHyper-Vなどといった、仮想化インフラストラクチャだけのものでした。Platform9 Managed OpenStackを利用することで同じ機能をKVM環境においても利用できるようになりました。

モダンアプリケーションは複数階層のアーキテクチャとデータ共有で障害時にも一貫したパフォーマンスの提供を保証します。アプリケーションはスケールアウト、もしくは負荷状況に応じて拡張することが可能になっています。各々のインスタンスの障害は大抵はモダンワークロードに影響をあたえることはありません。しかし、大規模なデータセンタの障害ともなると、こうしたアプリケーションの可用性にもまだ影響をおよぼすことが有ります。クラウドスケールのデータセンタはこうしたハードウェアの障害も考慮して設計されているべきなのです。OpenStackでは管理者が障害ドメインを指定して、可用性ゾーン(AZ)を構築することが出来るようになっています。Platform9 manged OpenStackはこうした障害から、クラウドネイティブアプリケーションを複数のAZにわたってワークロードを配置することで保護することが出来るようになっています。

従来型のアプリケーションはインフラストラクチャが常に利用できることを前提としています。アプリケーションのアーキテクチャはハードウェアの障害に耐性をもちません。仮想マシンやハイパーバイザーの障害はこうしたアプリケーションの可用性に影響を及ぼします。Platform9 managed OpenStackを利用すれば、こうしたアプリケーションをもほぼすることが可能です。もしアプリケーションの仮想マシンがクラッシュしたり、その下のハイパーバイザーノードがダウンした場合、こうした仮想マシンはPlatform9のHA機能によって新しいホストを再割当てすることが出来るのです。

クラウドネイティブアプリケーションを保護する

Platform9 Managed OpenStackでインフラストラクチャ管理者とアプリケーション開発者は大規模なハードウェア障害に備えることができます。データセンタの設計によって、AZはサーバのシャーシであったり、ラックであったり、データセンタ環境全体であったりします。アプリケーション開発社はクラウドネイティブアプリケーションをAZの障害に耐性を持つように設計することが出来ます。

OpenStackはクラウド対応アプリケ-ションをリソースの利用状況に応じて自動的に拡張させるためのオートスケーリンググループを構築することが出来るようになっています。Platform9のHA機能を用いれば、オートスケーリンググループに可用性ゾーンの要件を追加することも可能です。例えば、以下のテンプレートは可用性とともにオートスケーリンググループはを記述したものです。

Fig009可用性ゾーンを組み込んだHeatテンプレート

heatテンプレートはアプリケーションのスケールアウトの青写真を記載したものです。複数のインスタンスにまたがるワークロードが増加すれば、それに応じて追加でアプリケーションのインスタンスを展開します。Platform9では、開発者は可用性ゾーン(AZ)を指定してアプリケーションのインスタンスを展開することが出来ます。AZは"availability_zones"というプロパティにコンマで区切られたリストとして指定することが出来ます。Platform9 Managed OpenStackはアプリケーションのインスタンスがテンプレートで指定されたAZに最低1つずつ展開されることを保証します。以下の様な障害イベントに対応がなされます。

  • AZ内のホスト障害 : 同じAZの内の別のホストで新しいアプリケーションのインスタンスが開始される
  • AZ全域に及ぶ障害 : 他のAZ内のアプリケーションのインスタンスがユーザーリクエストに継続対応、クラウドネイティブアプリケーションとしては動作に影響が出ない

従来型アプリケーションを保護する

Platform9 Managed OpenStackはHAを従来型アプリケーションに拡張します。AZは古くからのアプリケーションの保護を構成するためにも利用ができるのです。クラウド管理者は以下のようにして可用性ゾーン上にHAを有効にすることが出来ます。

Fig010Platform9で仮想マシンのHAを管理

仮想マシンを障害ホストから復旧するためには共有ストレージが必要です。HAクラスタに参加する全てのホストは同一の共有ストレージに仮想マシンに固有のストレージパスを利用して接続することで、ノード障害時に適切に仮想マシンを復旧することが出来ます。OpenStackの可用性ゾーンにHAを有効にするため、Platform9は可用性ゾーン内のすべてのKVMホストに分散クラスタリングサービスを展開します。クラスタリングサービスはGossipプロトコルを利用してクラスタ内のすべてのノードの死活を監視します。従来からのハートビートを利用したノードの健全性の監視を行うアプローチと比べ、分散クラスタは以下の様な利点があります。

  • Gossipプロトコルはハートビートベースの手法に比べ、確実にそして素早く障害を検知、仮想マシンのダウンタイムもより短くなる
  • ネットワークパーティション(分断)のようなわかりにくく、ハートビートでは検知できない障害も検知

ホスト障害発生時にはそのホストは隔離され、クラスタから切り離されます。以下に示したように、そのノードで動作している全ての仮想マシンは同じAZ内の他のノードで再起動されます。

Fig011障害時の仮想マシンの避難

AZのサイズと起こりうる仮想マシンの障害の数によって、障害ホストの仮想マシンを復旧するための予備のキャパシティを展開しておく必要があります。

Platform9は分散クラスタを自動的に管理することが出来ます。障害時に手動で構成を行う必要はありません。クラスタはAZにハイパーバイザーのホストが追加されたり、削除されたりする毎に自動的にメンテナンスされます。まとめです。Platform9 Managed OpenStackは現在企業に必要とされるHAの機能を一元的に提供することが出来ます。クラウド対応のみならず、古くからのアプリケーションのための固有のHAの要件に応えることが出来るようにし、ワークロードの可用性について不安を抱えることなくクラウドへ簡単に移行できるようにしてあります。このHAの機能についてのデモは以下のビデオを御覧ください。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)

2016/08/30

VMworld 2016 Day1 General Session 国内最速レポート

皆さん こんにちは
5年連続5回目のVMworldに参加中の工藤です。
今年は私から現在開催中のVMworld 2016の初日のGeneral Sessionの速報をお送りします。

Image_2

このままクラウドの普及が続くと2021年に漸くトラディショナルなインフラが50%になる予測を披露しました。

Image

そんなクラウドとオンプレミスが共存するIT基盤においてFreedom とControlの両立を実現するHybrid Cloudを提供するのがVMwareのミッションであると発表されました。

そんなHybrid Cloudを実現するCross Cloud Archtectureとして以下のような発表がありました。

  • 統合基盤ソフトウェア「Cloud Foundation」の発表
  • マルチクラウド管理のSaaS「Cross-Cloud Services」の発表

今回は統合基盤ソフトウェア「Cloud Foundation」について紹介してみたいと思います。

■「Cloud Foundation」の発表
ITmediaの三木さんが既にこちらで紹介されていますが、最近のトレンドであるHyper Coverged Infrastructureの新しいモデルとして「Cloud Foundation」が発表されました。既にこちらに製品ページから発表された内容を確認することができます。

■「Cloud Foundation」って何?

「Cloud Foundation」は一言でいうと、vSphere + Virtual SAN + NSX + SDDC Managerで構成されたソフトウェア群の名称です。従来「EVO SDDC」として提供されていたものを置き換えるものとなります。以前のEVO:RAIL、現在のVSAN Ready NodeやEMC VxRAILのようなアプライアンスはvSphere + VSANだけの統合でしたが、NSXまで統合されることによってネットワークまで含めた提供のなっている点が異なります。Hyper Converged Infrastructure業界のリーダーであるNutanix社の掲げる「Enterprise Cloud」のビジョンとも似ていて、パブリッククラウドのようにシンプルにするにはオンプレミスのインフラもシンプルにする必要があり、それをソフトウェアで実現するVMware社のソリューションともいえるのはないでしょうか。

■「Cloud Foundation」ってソフトウェア単体で構築するのと何が違うの?

「Cloud Foundation」で追加された「SDDC Manager」は現在のところ物理リソースを管理して、サーバ仮想化の基盤(VI)と仮想デスクトップの基盤(VDI)を裏で展開を自動化し用途に応じて払いだすことができるそうです。そして展開されたソフトウェアコンポーネントを含むソフトウェア群のアップデートのライフサイクル管理が提供されます。

Sddcmanager_2

また今後Cloud FoundationがvRealize AutomationやvRealize Business、Integrated OpenStackに対応してDevOPSの基盤やvCloud Foundationのコスト管理などの機能追加がされる予定です。

Sddc

■「Cloud Foundation」はどうやって提供されるの?

今までのHyper Converged Infrastructureに対するVMware社のアプローチ同様VMware社からはソフトウェアだけを提供し、エコパートナーからHyper Converged Infrastructureとして提供される形をとっています。現在3つの提供形態が予定されています。

  1. 統合アプライアンスとしての提供
  2. Ready Nodeの提供
  3. パブリッククラウドとの連携

統合アプライアンスとしてはEMC社よりVCE VxRack1000 SDDCとして提供がされる予定です。Ready NodeとしてDELL社、HPE社、Quanta社より提供がされる予定です。そして最後のパブリッククラウドとの連携ではIBM Softlayer上で提供された後、vCloud Air、vCloud Air Networkが追加されていく予定です。

■まとめ

Cloud Foundationを実現することで、オンプレミスとパブリッククラウドをまたいだハイブリッドクラウドを実現することができるようになります。今回のGeneral Sessionで発表されたCross Cloud Serviceもこうした基盤がある前提になるような気がしています。オンプレミスのインフラをシンプルにするCloud Foundationに皆様ご注目ください。

また9/14,18にVMworldの内容をまとめてわかりやすく解説するフィードバックセミナーを予定しております。興味のある方は是非こちらにいらっしゃってください。

VMworld 2016 フィードバックセミナーhttps://networld.smartseminar.jp/public/seminar/view/668

次回はこのCross Cloud Serviceについて紹介していきたいと思います。