*PernixData Feed

2016/12/12

最新鋭、IBM FlashSystem A9000を大解剖!

IBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。


驚きのデータ削減!あらゆる電力喪失に対応する究極の電源機構!
何処をとってもワンランク上のA9000ですが性能も機能も一味違います!!
その噂の真相を確かめるべく、検証も次のステージへっ。

7vocbqxlurq9an61481180153_148118042


ここからはお待ちかねのA9000の持つ機能や性能について
さらに切り込んでいこうと思うっ♪


で、今回はズバリ QoS ですっ♪

クラウド基盤好きには、ハズせないマストアイテムがこのQoS
このA9000!、次のスケジュールもパンパンで、お借りできる期間もあとわずかっ!
限られた時間内(いろいろな検証の合間を縫ってこっそり決行っ!)に出来る限りの検証をおこなってみたよっ♪

ちなみにQoSってなにっ?って人もいると思うので簡単に説明しようっ。
QoSとは Quality of Service(クオリティ・オブ・サービス) の略でザックリ言うと
その名の通り、「サービスの品質!」 要は「ユーザーを満足させられる度」みたいな意味になりますっ。

したがって、ここで言うQoSは「ストレージアクセスの品質」ですねっ♪
例えば、「社内で野放しのワークロードが蔓延りクリティカルアプリケーションに影響がでてる!」のような
他の利用者の大きなI/Oに影響を受けるいわゆる“ノイジーネイバー”問題っ。
QoS 機能はこういった問題を解消するために無くてはならない機能っ!。

A9000/A9000Rの
QoS機能は、接続先ごとのプライオリティーに応じて
柔軟できめ細やかな設定が可能ですっ。
例えばこの図ように「帯域」または「IOPS」を設定したり、また「その両方」を設定することもできます。
もちろん単一ボリューム単位だけでなく、複数のボリュームでシェアしたり
ストレージプール単位での設定だって出来ちゃいますっ♪

A9000qostest001


更にA9000/A9000Rは管理アカウントまで独立したマルチテナンシー機能も搭載され
クラウド基盤、クラウドサービス、そして流行のVDI環境にも最適な一台です!!

それでは、A9000の QoS機能の検証結果をご覧くださいっ♪

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

検証が進むにつれ

筆者はこの「グリッドコントローラー」の完成度の高さに驚いているっ。
特にパフォーマンスに関しては、驚きの結果(本当に想定外です。)を次々とたたき出してますので

そのへん、次回にでもお見せできればと思いますっ。


                        by:まいけル
        

2016/11/15

ウィーンから速報 : Nutanix .NEXT EUROPE 2016 番外編~PernixData記事最終章

本記事はウィーンから速報 : Nutanix .NEXT EUROPE 2016 前半ウィーンから速報 : Nutanix .NEXT EUROPE 2016 後半の続編です。是非、最初からお読みください。

すでに帰国しておりますが、最後にNutanix社に買収されたPernixData社の情報についてお伝え致します。PernixData関連の記事はフラッシュ仮想化プラットフォームの基本要素 パート1から100以上も更新してきました。今回の記事はその最終章になります。若干以上に自己満足な記事でもありますが、是非おつきあいください。

PernixData社のその後の情報を含め、もっと詳しく知りたいという方は以下のセミナーへ是非お申し込みください。

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線

ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

VMware と AWSの戦略的なパートナーシップ発表直後の10月17~20日で開催された「VMworld 2016 EMEA」参加メンバーによる VMware の最前線情報 と、Cisco UCS や Citrix XenDesktop ファイルサービスへの対応など矢継ぎ早に進化を続ける Nutanix 社の最新の「.NEXT」イベント「Nutanix .NEXT Conference EUROPE」参加メンバーによる、Nutanix 社の最新情報が2つまとめて聞ける日本で唯一のセミナーです。

「.Next on Tour Tokyo/Osaka」や「vForum Tokyo/Osaka」では語られなかったレアな情報や、より新しい情報が目白押し!両社の販売代理店必見の内容をお届け致します。

Nutanix社によるPernixData社の買収

PernixData社とNutanix社の間に何かありそうだ、という記事が出たのは2016年の7月1日のことです。当時はNutanix社も非上場企業ですし、PernixDataも創業から4年(製品出荷開始から2年半)を経ていますが、まだまだスタートアップ企業で詳しく詳細が語られることはありませんでした。そして後日明らかになりますが、PernixData社はオフィシャルには8月3日にNutanix社に買収されています。買収額は公表されていません。

なぜPernixDataを買収したのか? これに関しては開発責任者であるSunil Potti氏のブログにも記載が有ります。「データとアプリケーションを物理的に近づけるべきである」というアーキテクチャ的な思想が共有されており、更に「ハイパーバイザを通じて全てのIOの特徴を見ることができる」という点も買収の評価ポイントのようですが、何より「こうした思想を共有できており、かつ優れたメンバーがグループになっている」ことが重要ということが記載されています。

つまり、PernixDataはテクノロジーはもちろん、そのメンバーを含めて、業界の反乱者/革命者であるNutanixファミリーに足る会社であると言う理由で一緒になったのです。

今回の.NEXT EUROPEではそうしたメンバーがNutanixで元気にしている姿を目にすることが出来ました。

PernixDataのメンバーは?

まずオーストリアに出発前に確認できた情報ですと、PernixData社のCTOだったSatyam氏とVP Product ManagementだったBala氏はNutanix上にスケールアウト型のファイルサービスを提供するAcropolis File Serviceのセッションのスピーカーとして登録されていました。

Fig087

さすがウィーン、部屋の名前がマーラーとかブルックナーという作曲家になっています・・・ではなく、PernixDataの技術の中心にいたこの2名は既にNutanixの一大プロジェクトであるAcropolis File Serviceをリードするポジションで活躍しています。セッション内の詳しい情報はセミナーなどでお伝えしていきますが、仮想化サイロの統合の時代を経て、時代はストレージサイロの統合の時代へと移ってきています。Nutanixは仮想化のためのボックス(HCIまたはHCI++)から既にエンタープライズのためのボックス(エンタープライズクラウド)へとかじを切っており、ファイルサーバの統合(AFS)、ブロックストレージの統合(ABS)と矢継ぎ早に新しいテクノロジーを生み出しています。この重要なポジションがこの二人によってリードされているのは大変素晴らしいことだ!と思い私はウィーンへの旅路につきました。

再会、more big things!

ウィーンではいくつかブログを翻訳させていただいているサポートエンジニアのGuidoさん、そしてPernixData社の元CEOのPoojan氏と再会することが出来ました。見てください! せっかくなのでPernixProのTシャツを着ていきましたが、外気温4℃のウィーンでは寒かった!

Fig088

Poojan氏とはMeetingでいろいろなことをお話いたしましたが、PernixData社の製品についてはこちらのURLのレターのとおり、既存のお客様は安心して今後もFVP/Architectの利用、増設を行うことが出来ます。また、前半のレポートでお伝えしたとおり、Nutanixへの統合も進んでいるのでしょうか?これについては詳しいことはきくことは出来ませんでしたが、PernixDataの技術でNutanixはもっと早くなるし、新しいフラッシュ(メモリクラスストレージ)が出てきたらそれも取り込んで、どんどん上がっていくよ!とのことでした。今年はWikibonの予測によるとFlashとHDDの容量単価がクロスオーバーする年です。まさに今後のストレージは激変していく、その最前線のメンバーとしてNutanixに合流したのです。

Fig091

Poojan氏によるとPernixDataのメンバーはPernixDataの技術の統合はもちろん、ブロックサービス(ABS)とファイルサービス(AFS)に携わっているということです。ファイルサービスのみならず、そのバックエンドに利用されているブロックサービスもこれまでのストレージの常識の枠を超えた機能を持つストレージでエンタープライズのストレージサイロの統合に今後大きな役割を果たすことでしょう。まさにWikibonの予測のとおり、エンタープライズのストレージはNutanixのようなServerSANになっていくのです。

Fig090

AFSのセッション終了後は質問攻めで近づくことも出来ませんでしたが、BalaさんとSatyamさんも会場で見かけたので一緒に写真を取ってきました。

Fig089

PernixData社はNutanix社と合流しましたが、その思想、技術は今後より大きな変革のために既に動き始めていました。Nutanix社のディストリビュータとして日本でこれから起こる、もしくはもうはじまっているこの変革の一端でも担えればと、決意を新たに帰国の途についたのでした。

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

Nutanix .NEXT関連記事はこの番外編でオシマイです。残ったコンテンツはセミナーにてご披露しますので、是非足をお運びください。また、2年以上に渡って書き続けてきたPernixDataの記事もおそらく今回で最後になります。上で述べられているとおり製品の統合が進んでおりPoojan氏の言葉を借りると「PernixData will be invisible.」になっていきます。

さぁ、新しくPernixDataの技術が中にはいったNutanixの製品の登場を待ちましょう!

2016/11/10

ウィーンから速報 : Nutanix .NEXT EUROPE 2016 前半

みなさん、こんにちは。

今週はウィーンにお邪魔してNutanix社の.NOW/.NEXT EUROPEイベントに参加させていただいております。.NOWイベントについてはパートナー様Onlyの情報を多分に含むため、レポートが出来ませんでしたが、本日は.NEXTイベントについて速報(時差ボケのせいですっかり速報感がない時間帯になってしまいましたが・・・)をお届け致します。

きれいなスライドを使ってのご紹介ではなく、現地からのライブ感を重視して私の目線で撮影した写真を使ってご紹介致します。都合よく前から2番め、ど真ん中の椅子に座れましたのでかなりいいアングルでの写真になっています!

詳細については彼の記事が既に更新されていますので、こちらは帰国後早々にでも・・・。彼の記事もPart 1とあるとおり、分割でないと出せない規模になってきています。

.NOWの内容を含め、もっと詳しく知りたいという方は以下のセミナーへ是非お申し込みください。

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線

ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

VMware と AWSの戦略的なパートナーシップ発表直後の10月17~20日で開催された「VMworld 2016 EMEA」参加メンバーによる VMware の最前線情報 と、Cisco UCS や Citrix XenDesktop ファイルサービスへの対応など矢継ぎ早に進化を続ける Nutanix 社の最新の「.NEXT」イベント「Nutanix .NEXT Conference EUROPE」参加メンバーによる、Nutanix 社の最新情報が2つまとめて聞ける日本で唯一のセミナーです。

「.Next on Tour Tokyo/Osaka」や「vForum Tokyo/Osaka」では語られなかったレアな情報や、より新しい情報が目白押し!両社の販売代理店必見の内容をお届け致します。

ウィーンって?

オーストリアの首都で日本からは直通便がありませんので、どこかで乗り換えていく必要があります。ちなみに我々はヘルシンキで乗り換えてウィーンの空港へ入りましたが、飛行時間だけで合計14時間、家を出てからホテルにチェックインするまでで20時間を超える強行軍でした。

ハプスブルク家の優雅な生活や財宝の話もあるのですが、ここでは割愛、街の雰囲気がわかる写真を一枚だけ。

Fig059

どうですか?こんな素晴らしい教会がある横で、いよいよNutanixの最新情報がリリースされるのです。

Nutanix .NEXT Day 1 Keynote

まずはChairman & CEOのDheeraj氏。IPOのご報告と御礼ですね。

Fig060

Nutanixは3h(humble,honest,hungry=謙虚、誠実、果敢)の会社だったということですが、上場を果たしたことも有り、社会的な責任を果たすため、この3つのhに加え、heartを加えたそうです。(実際に会場でもボランティアを募集して学生さんへのプレゼントのためにバックパックにいろいろな道具を詰める作業などが行われていました。)

そして、話はNutanixはどこへ向かうのか?と言う話になっていきます。

Fig061

HCI(ハイパーコンバージドインフラストラクチャ)はとうに卒業して、HCI++(HCIを超えるもの?)、そして今後はエンタープライズ・クラウドへと歩みを進めていきます。ここでバトンはCPDOのSunil氏へと渡ります。さて、エンタープライズ・クラウドとは?

Fig062

これです、企業のためのAWS。さて、ここから新しい発表が数珠つなぎに出てきます。

一つ目CiscoのブレードサーバとStorage Heavyノードのサポートについて。

Fig063

これまではVDI用、サーバ仮想化用、ハイパフォーマンス用の3構成のみだったCisco UCSに高密度実装(ブレードを利用するため、All Flash Only?)とストレージ重視用の構成が加わり、幅広い選択肢が生まれることになります。

続いてちょっとおもしろネタだったので以下の画像もご紹介します。

Fig064

AmazonはAmazon.com(販売)とAWSですというスライドで、NutanixはAmazon.comのワンクリックの手軽さもEnterpriseにもたらしますということでした。なるほど。

Fig065

このあたりは現在定期連載(?)中のPrismの記事もご参考ください。

Fig066

新しいアプリケーションのCertifyについては、SAPのNetweaverの対応に続いてCitrix社のCTO Christian氏が登壇します。まずは当社でもキャンペーンを行っているInstantON VDIについてのご紹介。

Fig067


これはキャンペーンページをぜひご覧ください。まさに夢のような価格のキャンペーンですし、いよいよVDIもここまで来たか!という気がします。

Fig068

続いてのアナウンスはCitrixの全てのEMMまたはEUC製品とNutanix(必要部分)をコントロールできるWorkspace Cloudが今後予定されているとのこと。NutanixはVDIのみならず、EUC全体のプラットフォームになりつつ有ります。続いてPuppet社がゲストで登壇。

Fig069

Puppetの技術を使えば、いろいろなことが、ワンクリックどころか、ゼロタッチに! 先日PernixDataとともに買収したCalm.io社との連携も今後は気になりますね。

続いてはじまったのがデモコーナー。Prism Proのサーチ機能や健全性の機能が紹介されます。こちらについては字幕入りたての以下のビデオもご参考ください。

Prism Pro from miyo4i on Vimeo.

検索しながら必要な情報にアクセスして、処理をしていく、こんな運用もあるんですね!まさにコンシューマー。欲しい情報を探して必要なら購入したりしていく、まさにそんな感じです。

Fig070

こっちは検索で各々のVMを分類したもの。ハイパーバイザーとvCPU数で色分けしています。こうしたレポートを簡単に作れるとインフラの整理や最適化が行いやすくなりますね。

Fig071

また、Prismはマルチハイパーバイザー対応を更に進めており、Prism UIのみですべての操作を完結できるように、つまりvCenterを管理者が利用しなくても良くなっています。

Fig072

やり過ぎ感ありすぎのデモでしたが、同じPrismのUI経由でESXiでのVMのクローンとAHVでのVMのクローンをやって、操作感は全く同じ、と言うデモもやっていました。しかもAHVのほうが圧倒的にクローンが早いというオマケ付き(笑) vCenter経由でコントロールしているESXiと直接コントロールしているAHVの違いもあるかもしれませんが、この話が次につながります。

Fig073

ハードウェアが進化してめちゃくちゃ速いSSD(3DXpointは現行SSDの1000倍と言われています)が登場してきて、そのSSDの速さをダイレクトに使えるような技術を創っているとのこと!

Fig074

みなさん!名前は出ていませんが、おそらくアレのテクノロジーじゃないでしょうか!? AHVに移植が進んでいるのでしょうか?楽しみです。

Fig075

こうした技術を使うとパフォーマンスは更に2倍になるそうです。

Fig076

そして、話はCertifyに戻りますが、Oracleがサポートされました!そして、そのOracleに十分なパフォーマンスが提供できる、つまりどんなアプリケーションもNutanix上でOKになる準備が着々と整っているのです!

Fig077

あらゆる企業のワークロード(仮想、物理、コンテナ、ファイルサービス)が動作し、更に様々なオプション(ハードウェア、ハイパーバイザー)が選べる。それがNutanixのエンタープライズ・クラウドなのです。

Fig078

後半に続きます。

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

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/14

ウェブスケールインフラストラクチャ上のオールフラッシュのパフォーマンス

本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はAll Flash Performance on Web Scale Infrastructureをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig020_2

オールフラッシュストレージアレイは今日では人気を博し、従来からのミッションクリティカルなファイバーチャネルのアレイから大きくビジネスを移行させつつ有ります。そして、従来型の3層構造のアーキテクチャは少しだけですが、シンプルになりました。僅かな数の仮想マシンが大きなパフォーマンスを必要とするようなスケールアップ型のワークロードに対し、優れたパフォーマンスを提供し、さらに、データ削減のテクニックを利用してキャパシティの削減も同時に提供しています。オールフラッシュシステムがさらに優れているのは大きな負荷がかかったり、キャパシティが限界に近い状態であったとしても一貫したパフォーマンスと低遅延を提供するということです。しかし、従来型のアーキテクチャに比べて少しだけシンプルだ、ということはまったくもってシンプルであるとは程遠いのも事実です(FCの管理オーバーヘッドだけ)。そして、まだインフラストラクチャがインビジブルであるともいえません。まだ幾つかの制限があります。オールフラッシュが欲しくて、更に制限のないスケールアウトも欲しい、数千の仮想マシンを動作・サポートしなくてはならない、でも管理を従来型の3層構造よりも簡単にしたいとなったらどうしますか? 効率よくインフラストラクチャをインビジブルにしたいのです。

答えはとても簡単です。インフラストラクチャが将来そうなるのと同じで、Nutanixを選択すればよいのです。Nutanixは1年前にオールフラッシュソリューションを打ち出しました、そして一貫した高パフォーマンスと想定通りの低遅延優先度の高いワークロードに対して望むお客様に大きな人気を博しています。NX 9040ノードは6本のIntel S3700というエンタープライズクラスのSSDとE5 v2を2ソケット、最大で512GBのメモリを融合させています。このソリューションは2ラックユニットのスペースに2ノード(最大でラックあたり364TBの物理フラッシュストレージ)収めることが出来ます。これはOracleデータベースやSQLサーバ、SAP、Temnos T24 core Bankingなどにうってつけのプラットフォームで、これら全てを動作させているお客様までいます。特に、Nutanixのデータ削減機能やデータ回避機能と組み合わせると、同じ物理ストレージ内で更に多くのキャパシティを利用することが出来ます。Josh Odgers氏(NPX #001)はEC-Xと呼ばれる新しい機能(訳注:リンク先は英文、現在のところ翻訳予定なし)についての記事を公開しています。

Nutanixのデータ削減

データ削減には圧縮、データ重複排除そして、EC-Xなどが含まれます。データ回避機能は例えばVAAI統合、シンプロビジョニング、そしてスマートクローンとスナップショットなどで、不必要なデータや重複したデータを最初に作成しない機能です。データベースやビジネスクリティカルアプリケーションでは、圧縮は推奨されています。重複排除については大規模なデータで異なるデータが多い場合にはさほど効果的ではないというケースも有ります。こうした手法によってそのまま利用するよりも、もっと利用できるキャパシティが増える可能性がありますが、その効果はワークロードによって様々です。2:1、3:1もしくはもっと高い割合のことも有ります。単一の手法だけでも、ワークロードに向いている手法であればもっと高い割合になることもあるのです。

データベースにおいてSQLサーバで透過的データ暗号化(TDE)やOracleでアドバンスドセキュリティ暗号化を利用しているような場合、これほどには効果が出ない場合もあります。NX9040を含む、同じプラットフォームでデータ最終暗号化をサポートしており、これによってアプリケーション自身での暗号化を不要にする事も可能です。暗号化されたワークロードにおいてキャパシティを効率的に削減するのは難しいものです。以下のイメージはNX9040の単一クラスタでNutanixのPRISMユーザーインターフェイスから見た際のOracle RAC データベースがどれほどの削減がなされたかを表しています。これは実現出来ていることのほんの一例でもちろん、ワークロードに依存します。効果は様々なのです。

Fig021

上記のイメージからはデータベースが5.57TiBのキャパシティをデータ削減前に利用していたということが分かります。データベース自身は3TBですから、データ保護やデータ保全性のためのオーバーヘッドがあることが分かります。データ削減が行われた後のキャパシティは1.95TiBのみです。この削減効果は圧縮からの効果のみです。もしも圧縮とEC-Xを組み合わせれば、もっと大きな削減効果を得ることが出来るはずです。Nutanixクラスタが大きくなれば、データ削減の手法は更に効率的なものになります。

もう一つ圧縮の例を上げましょう。今回はExchangeにJetStress Databaseで負荷をかけたものです。(注意 : JetStressは実際の世界ではあり得ないワークロードでここでのデータ削減率は実際のExchange環境での物よりも高い可能性があります。)

Fig022

殆どの環境では検証・開発のワークロードが本稼動系とともに動作しています。Nutanixのやり方では、ワークロードのスナップショットの作成やクローンの作成してもストレージ消費は増えることはありません。これ等の操作ではデータに変更がないからです。これはテンプレートを展開する際にもESXiとVAAI(VMware API for Array Integration)で同様に実現されます。新しい仮想マシンを欲しいだけ展開しても、実際にデータが書き込まれるまではストレージの消費は増えないのです。

こうした手法を利用して、100%完全なデータを開発・検証環境で利用しながら、ストレージの消費を抑えることが可能です。高いレベルでコードが動くという確信を持ちながら、本稼動系へとワークロードを移行することができ、いつでも検証環境の状態へと戻ることも出来るのです。全ては数秒で追加ストレージキャパシティを消費するという心配は必要ありません。

Nutanixのデータ削減とデータ除外手法についてはNutanixバイブルの分散ストレージファブリックのセクションもご参照ください。

Nutanixのオールフラッシュのパフォーマンス

データ削減や回避の手法によってワークロードのパフォーマンスも様々に変化します。単一のアプリケーションからのIOパターンが単一であるということはほとんどありません。ですから、パフォーマンスを検証するのにもっともよい方法は実際のアプリケーションを利用することです。実際のアプリケーションは4KBサイズのIOだけを生成するということは一般的にはありません。ですから、今回はNutanixのオールフラッシュのパフォーマンスを検証するためにSLOB(SLOBのオフィシャルページはこちら)、SwingbenchBenchmark Factory for DatabaseHammerDBのようなツールを利用しました。ここではSLOBを利用して取得したイメージを例に提示します。

IOパフォーマンスを検証する際に、文脈を無視して、単独の計測値だけを見てはいけません、そうしなければ検証は意味が無いものになってしまいます。IOPSを例に取ると、IOサイズ、レイテンシ、スループットが異なれば劇的に値が変化します。ですから、IOPS単独だけでは確かな計測ができているとはいえません。今回のテストでは、Oracle RAC環境に対して、SLOBを利用して大量の小さなReadを生成しました。それぞれのReadは8Kで、これはデータベースの生のページサイズです。このIOパターンは100%ランダムです。トランザクションログのIOはかなり大きなIOサイズであり、当然シーケンシャルです。

以下のダイアグラムのテストを行ったシステムは2ノードのOracle RACクラスタ(それぞれのノードで 48 vCPU、192GBメモリ)を2台のNX4170(4 x E-4657L v2, 512GBメモリ)と4台のNX9040(2 x E5-2690 v2 512GBメモリ)で構成されたNutanixクラスタ上で動作させています。いずれのシステムも旧世代のIntelのIvy Bridgeのプロセッサ技術を利用しています。ハイパーバイザーはESXi 5.5を利用しており、後にESXi 6.0にアップグレードしたところ、更によいパフォーマンスを示しました。

Oracle RAC SLOB IOPS

Fig023

上のイメージでは2つのテストが行われています。一つ目は30%がupdate(更新、データ書き換え)であるというワークロード、もう一つは100% select(選択、データ参照)のワークロードです。updateのワークロードではきっかり70K IOPSが生成されています。

Oracle RAC SLOB レイテンシ

Fig024

異なるベンチマークの最中のレイテンシが上に表示されています。updateの多いテストではレイテンシは高くなり4ミリ秒ほどになっており、ピークでは7ミリ秒になっています。selectの多いワークロードに於いてはレイテンシは0.45ミリ秒です。2つ目のテストでのレイテンシが低いのはハイパーバイザーを最新ヴァージョンにアップグレードすることによって更に低くなりました。

Oracle RAC SLOB スループット

Fig025

上のグラフから読み取れるのはupdateが多いテストではスループットはカッチリ800MB/秒で、selectが多いテストでは1.13GB/秒でした。思い出して欲しいのはこれはNutanixのハイパーコンバージドアプライアンスであり、全体で8ラックユニットのスペースにコンピューティングとストレージの両方が収まっているということです。近い将来、Nutanixはもっとこうしたパフォーマンスを実現するための物理的なスペースと電源要件を削減する予定です。もっと小さなスペースで、そして、もっとシンプルな環境でオールフラッシュのワークロードを動作させることができる様になります。

オールフラッシュが必要なのか?

利用するか、利用しないかは当然皆様のご選択です。Nutanixは強力なオールフラッシュのオプションをNX9040で提供しています。将来のプラットフォームではこれをさらに推し進め、もっと極端なワークロードへも対応できるようにしていきます。Nutanixのプラットフォームではあらゆるノードのタイプでいくらかのフラッシュが搭載されています。データはフラッシュとハードディスクにおいてブロックレベルでのアクセス頻度に応じた階層がが行われます。オールフラッシュが必要か、そうでないかということは結局のところ、ソリューション全体のライフタイムの中で予想通りの結果を売ることが出来るか、というところに帰結します。アプリケーションがホットデータしかなく、フラッシュの上にすべてデータが有ることを保証したい場合にはオールフラッシュはそれに答えてくれます。オールフラッシュプラットフォームはオーバーヘッドが小さく、データ階層化の必要性がありません。ですが、ほとんどのワークロードにおいてはデータ階層化は非常に効率的で、充分です。

現段階で、オールフラッシュに向いているのはデータベースやアプリケーションサーバのような、低遅延サービスの保証が必要とされるものです。特に、パフォーマンス以外にも、仮想化によって物理ノードあたりのシステム数を上げることでライセンス上のメリットを受けられるような場合、更に多くのアプリケーションをノードに仮想化することが出来ます。OracleやSQLサーバを考えてみてください。

Nutanixは最近ハイブリッドのノードにおいても、フラッシュピンニングという機能をアナウンスしました。まだリリースされていません(原文執筆時、現在はリリース済み)が、リリースされた暁には仮想マシンや仮想化ディスクをフラッシュ層にピン留めすることが出来るようになります。この機能は標準のハイブリッドとオールフラッシュオプションの中間に位置するようなものです。時が経つにつれ、ほとんどのシステムはフラッシュの寡占状態になり、ハードディスクはスナップショットやバックアップ、アーカイブなどでのみ利用されるようになるのではないかと予想しています。

おわりに

今回の記事に掲載したイメージのとおり、ハイパーコンバージドのウェブスケールプラットフォームのオールフラッシュは特筆すべき管理の簡単さ、低遅延、制限のないスケールアウトが必要な環境において、優れたパフォーマンスを提供します。プラットフォームにより多くの利用可能なストレージキャパシティを提供するデータ削減と回避の手法は他のオールフラッシュアレイと同様にNutanixでも動作します。これが唯一上手くフィットしないところがあるとすれば単一の極端なワークロードまたは仮想マシンがアレイのパフォーマンスの全てを必要とするというようなケースでスケールアウトできない、計画もないというような場合だけです。こうした状況であればPure Storageのような物を選択する方が良いでしょう。それ以外のすべての場合、Nutanixは他のものに比べ遥かにシンプルなソリューションで優れたパフォーマンスと無制限の拡張性を提供することが出来ます。

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

いかがでしょうか? 既に様々なベンダーからオールフラッシュストレージソリューション、オールフラッシュハイパーコンバージドソリューションが提供されていますが、今回あえてこの記事を翻訳したのはいくつかのブロク/ニュースに記載されているように当社が国内で提供を行ってきた(そして私の大好きな!)PernixDataのテクノロジーが上でお見せしてきたような優れたパフォーマンスに加えて利用ができるようになるとの期待からです。PernixData社のソリューションはFlashだけではなく、メモリ、そしておそらくは今後多く登場してくるメモリクラスストレージ(または大容量不揮発性メモリ)のテクノロジーにまで利用することが出来るようになっています。Nutanix社のCVM(VSA)の実装とPernixData社のin-kernelの実装が今後どうなっていくかなど、興味はつきませんが、PernixData社が大好きな私以外の皆様の興味にも答えられるように、今後も面白い記事を選びながら更新していきたいと思います! 引き続きよろしくお願いいたします。

2016/09/01

大志が共有出来ているということ (Nutanix社によるPernixData買収関連記事)

ネットワールドはPernixData社のNutanix社への合流という経緯もあり、この9月1日より、Nutanix社の国内ディストリビューターとしての活動を開始いたします!

と、言うことで、引き続き、Nutanix社の情報、およびPernixData(だったもの)の行方についても本ブログにて公開してゆきますので、今後もお楽しみください。

本記事はNutanix社のオフィシャルブログの記事:Shared Ambitionをネットワールドが翻訳したものです。著作者はChief Product & Development OfficerのSunil Potti氏です。

このブログはNutanixがPernixDataCalm.ioと合流し、1つの会社となるという素晴らしいニュースについてのものです。

まずはNutanixとその大志についてお話させてください。これまでに働いてきて思うことは、私の全てのキャリアの中の会社の中でNutanixは間違いなくもっとも優れた会社、チームであるということです。以前の会社でもうまくまとまったチームと働くという経験はしてきましたが、毎朝起きる度に何故こんな気分なんだろうと自分自身に語りかけることはそう多くはありませんでした。他の多くの私の働いてきた会社のように、Nutanixは革新的なテクノロジーを生み出し、傑出した人材を育てるというコミットメントは同じです。何が違うのでしょうか? 何が私を毎日の仕事に駆り立てるのでしょうか? 以下の3つに分類されるのではないでしょうか :

一つ目には我々は調和と共感の正しいバランスをもたらす反乱者のチームであるということです。熱烈なまでに問題が発生した際にはお客様にフォーカスしたり、競合他社が我々の機能に圧力をかけてきた際には忠実にその任務をこなしたり、揺るぎない決断で厳しい状況でも諦めなかったりと様々ですが、こうしたやり方の積み上げが我々そのものを構成しています。

二つ目には我々はITの提供の方法、ビジネスがアプリケーションを利用する方法を完全に再想像しようという大きなビジョンによって結ばれています。我々のエンタープライズクラウドへの旅路では、ITはパブリックとプライベートのクラウドの融合の証人になるはずですが、非常に大きな変化が起こりつつ有ります。

そして、最後に、我々は「本能的な感」とも呼べるものを共有しています。ですから、競合が起きた際には常に心の奥にチームが一緒におり、またチームが負けそうなときには倍の共感を得ることが出来ます。

このユニークな組み合わせが我々をここまでの急成長に導き、さらに組織全体の強い安定性と結びつきを産んだのです。

しかし、マーケットにおいて常に勝ち続けるためには、成長に合わせて我々の能力を傑出させ、更にチームにこの大志を共有し続けなければなりません。この独特な空気に合う人を採用するのは非常に難しく、さらにそれがグループになっており、コアを幾つものコードベースに分けたり、水泳プールのレーンを行儀の悪く泳ぐような形にしなくても済むようなテクノロジーを持っているとなると、更に難しくなります。PernixDataとCalm.ioにおいて、我々はそれを2つも見つけることが出来たのです。

PernixData

PernixDataとNutanixはアーキテクチャ上の設計思想を共有しています。それは次世代のデータセンタファブリックは可能な限り高速なパフォーマンスと柔軟性の提供、コスト効率のよい拡張性を実現するためにデータとアプリケーションが近接していなければならないというものです。サーバサイドのストレージテクノロジーはIntelのNVMeやストレージクラスメモリの後押しで100倍も高速になろうとしています。一方で我々はアプリケーションとデータを同一のサーバで動作させていますので、さらにそれらをCPUの側へと押しこみ、ワークロードを様々なクラウドコンピューティング環境を超えて動かすための道筋の提供や、そしてもちろんハイパーバイザに依存しない環境も維持しなくてはなりません。

この4年以上にもわたって、Pernixは非常に強力なスケールアウト型のデータ高速化技術を構築してきました。更に重要な事に、彼らは全てのIOをデータの一貫性に影響を与えることなく「見る」ことが出来ます。これは我々にオンラインのアプリケーションのマイグレーションをNutanixがいつも言っているとおり、ワンクリックだけで成功させるための貴重な地盤となります。

2つのチームは共にこの透過的なIOの視認性を利用して集めたワークロードについてのインテリジェンスと先進的な分析機能をあらゆるワークロード、あらゆるクラウド環境へ提供していく事になります。

Calm.io

Calm.ioはSequoia Capitalが出資するスタートアップでアプリケーションについての深い知見とインフラストラクチャ展開のためのアプリケーションのワークフローのビジュアル設計を行っている会社です。8~9ヶ月もの求婚を経て、我々はCalm.ioの素晴らしさを深く理解することにしました。

Nutanixはその全てがトップダウン設計からインフラストラクチャをインビジブルに変えることです。Prismのデザインはインフラストラクチャのヒューマン化です。我々がITの日常から極端にいろいろなものを取り去ったその方法は、確実に動作、そしてシームレスにワンクリックアップグレードなどの優れた機能を作成することです。我々はCalmのチームがトップダウンのアプローチを変えずにこのインフラストラクチャをインビジブルにする機能をアプリケーションのオーケストレーションにまで開放し、更にその能力を拡張してくれると理解しました。Calmの単一コンソールでの管理はAWS、Azure、Docker、オンプレミスのウェブスケールインフラストラクチャ全てにわたってのアプリケーションの設計とオーケストレーションの手助けになります。優雅にNutanixに彼らのストーリーが統合された際には電球が頭の上で光るのを見ることになるでしょう。

ClamがPrismに統合され、お客様はついに適切なワークロードに対して、適切なクラウドを選択するということが出来るようになり、Nutanixを気に入っていただいたのと全く同じ、シンプルで苦痛のない、一貫したエクスペリエンスでシームレスにアプリケーションの移行が行えるようになるでしょう。

大志の共有

.NEXT 2016で明らかにしてから、我々はエンタープライズクラウドのビジョンの提供へと着実に歩みを進めています。それはエンタープライズのお客様に最高のパブリックとプライベートのクラウドを提供するというものです。そしてこの2つの会社で、我々は優れたテクノロジーを生み出し、それを先に進めようという気概を持った素晴らしい人々からなるチームに出会うことが出来ました。それぞれのチームは既にテクノロジーを持ち、それだけでも素晴らしいものです。今後は一緒に新しい想像力に触発され、次なる舞台を作り上げ、不可能とも思える夢に挑戦していきます。

PernixDataとClam.ioを迎えることを誇らしく思います。2社のそっくりの心、精神、希望をもったチームをファミリーに迎え、次に何が起こるのか待ちきれません。

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

2016/08/31

PernixDataはNutanixファミリーに合流しました

本ブログエントリーはNutanix社による買収が明らかとなったPernixData社のCEOであるPoojan Kumar氏のブログ記事を翻訳しています。 

本記事の原文はPernixData Joins the Nutanix familyで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

PernixData社がNutanixファミリーに合流することをアナウンスすることに身震いを禁じえません。このPernixDataを創業してからはまさに素晴らしい4年半でした。我々の従業員、お客様、パートナー、PernixProの皆さん、PernixPrimeの皆さん、そしてアナリストやブロガー、そしてもっともっと多くの皆さんなくしてはこれはあり得なかったでしょう。

多くの人は御存知の通り、Nutanixはエンタープライズクラウド分野におけるリーダーで、業界に強力な影響力を及ぼしています。我々は彼らと合流して、次世代のデータセンタをつくり上げるというビジョンを戦略的に分担していくことを考える興奮を禁じえません。2つの会社の間のシナジー、文化、チーム、優れた製品に対するコミットメント詳細への洞察、そして最後に大きな目標までもが本当に素晴らしいものです。我々2つの会社が一緒になることは1+1が3になるようなものだと考えています。

まだ、どのようにPernixDataのテクノロジーがNutanixファミリーと統合されていくのかをアナウンスすることは出来ませんが、我々の既存のお客様はいつものとおり、サポートを継続して受けていただくことが可能で、それはいつものPernixDataのワールドワイドクラスのサポート組織によって提供されます。(※訳注 : 国内のPernixDataのお客様はTEC-WORLDを利用して日本語でのサポートを継続して受けていただくことが可能です。) そして、今や、そのサポートチームはNutanixのサポート組織によって支えられることになります。

我々はNutanixの拡張性と分散性を活用して、我々のテクノロジーをもっと多くの人々に早くお届け出来る様になると考えています。この2つの要素が一緒になることで、お客様のエンタープライズクラウドへの旅路を加速することをお手伝いすることが出来るようになります。

全ての皆様と皆様からのサポートに大変感謝しています。そして、我々の旅の次なる章への前進を楽しみに見ていてください。

Poojan Kumar

Co-founder/CEO, PernixData

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

2016/07/25

PernixCloud データ : FVPのレイテンシとSANのレイテンシの比較

本ブログエントリーはPernixData社のテクノロジーエバンジェリストだったFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPernixCloud Data: FVP Latency Compared To SAN Latencyで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

地球全体の仮想化データセンタをポータル化ESXiホストのCPUとメモリの構成についての考察そして、仮想マシンの密度(統合率)についての考察などの記事の中で、我々のPernixCloudの中のデータについて述べてきました。我々は世界中の仮想化データセンタのデータを多く集めることで、様々なアーキテクチャ、会社、運用を理解しようとしています。ですが、もちろん、我々は我々の製品のパフォーマンスについて理解するためにもこのデータを利用します。今回キーとなるメトリックは我々のFVPがどれだけワークロードのレイテンシを改善したか、という点です。Satyam氏Woon Jung氏とSriram Sankaran氏にデータセットへとダイブし、どれだけのレイテンシが改善されたのかを明らかにするように命じました。以下はデータ取得時のSatyamによるコメントです:

データセット

Satyam :我々は日々91000ぐらいの仮想マシンを観察しています。仮想マシンのIOの特性は時刻や曜日によって変わり続けます。ドーナツチャートのそれぞれのセグメントごとの色はx-y%のレイテンシの改善がSANのレイテンシに対して見られた仮想マシンの割合を表しています。例えば、ドーナツチャートの左上の内側の(濃い)ブルーのセグメントはWrite-Thoroughに設定した仮想マシンの全体うち5%は0~19%のレイテンシの改善がFVPによって見られたということです。

以下の記事を読んで、FVPとWriteポリシーについて理解しておいてください:

我々は1382の仮想マシンの数年分のデータについて収集しました。データの表示は標準的に、一時間あたりでどれだけか、という値にしてあります。これはEC-2などのクラウドと比較しやすいようにするためです。

VMFS上のWrite Throughの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig421

NFS上のWrite Throughの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig422

VMFS上のWrite Backの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig423

NFS上のWrite Backの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig424

Satyam : さぁ、準備はいいかい? いっぱいあるけど、以下の様なところが見どころさ、それ以外は読者の楽しみとして取っておきます。

  • VMFS上の仮想マシンでWrite Throughに設定されている場合、35%もの場合で、100%以上のレイテンシの改善が見られています。つまり、SANのレイテンシよりも仮想マシンから見たレイテンシが半分以下になっているということです。
  • Write Throughに設定されている仮想マシンでも、ストレージに対する負荷が下がることで実際にはWriteのパフォーマンスを向上させることができています。14%ものWrite Throughの仮想マシンが80%~90%の割合でWriteのレイテンシの改善をしています。これはとーーーーっても大きい!!
  • NFSのチャートの右上、NFSの仮想マシンはより大きなレイテンシの改善がなされています。これはNFSはダメだからです(パフォーマンスの観点からはね・・・。)
  • Write Backに目を移しましょう。VMFSで動作している仮想マシンの半分はWriteBackで100%以上のレイテンシを改善しています。Write Backはすごいね!
  • 一般的にはほとんどの仮想マシンが50%以上のレイテンシの改善しています。Readでも、Writeでも、Write ThroughでもWrite Backでも、VMFSでもNFSでも。なんという強者っぷり!

実際のデータは見ていただいたとおりです、注目したいのはWrite ThroughでのSANのWriteレイテンシの改善です。これは実際の話しですし、オールフラッシュストレージの上でFVPでRAMによる高速化(DFTM)を実施したことを考えてみてください。最近、Ramboll社 ーグローバルで展開するエンジニアリング会社ー が何故Pureのオールフラッシュストレージの上で、DFTMを利用するFVPを導入したのかという理由を答えてくれています。レコーディングは以下から聞くことが出来ます。Maximize Your All Flash Array Investment With Analytics(訳注:英語ビデオ)

Chethan Kumar氏、我々のパフォーマンスエンジニアもSANのレイテンシがFVPを動作させる前よりも下がったということを述べています。帯域が削減されることにより、ストレージエリアネットワークとストレージコントローラーに対する負荷が下がるからです。もし90,000もの仮想マシンからのIOが発行されたとすると、レイテンシはもっと高いものになっているはずです。そうした意味では、このドーナツチャートで見るよりも実際の結果はもっと優れたものになるはずです。本当のドーナツでは殆どが紫になってしまい、上の方にちょこっと色が出てくるような状態のはずです。

Write Throughで削減される仮想マシンからの帯域の総量を甘く見てはいけません。今週私は32のデータベースを動作させている仮想マシンを高速化されているお客様をご訪問いたしましたが、1日辺りで145TBもの帯域が削減されていました。ストレージエリアネットワークでの帯域はストレージ装置自身のキャッシュにも影響をあたえるのです。

Fig425

我々がFVPによるメリットにどれだけの確信を持っているかを示すために、我々は「Fastest SAN alive(最速のSANの誕生)」キャンペーンを実施しています。最大で10倍の高速な仮想マシンのパフォーマンスをFVPが実現するということを是非チャレンジしてみてください。詳細はこちらです。

Fig426

訳注 : 残念ながら上記のキャンペーンは国内では展開されておりませんが、FVPのパフォーマンス改善とその効果に絶対の自信があるということは上記の統計からの実際のお客様の例からも明らかです。是非無料トライアルをお試しください!

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