2017/02/01

Nutanix Acropolisブロックサービスについて知っておくべき10つの事

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のProduct Marketing Managerを務めるRohit Goyal氏によるものです。原文を参照したい方はTen Things you need to know about Nutanix Acropolis Block Servicesをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

さて、知っておくべき10つの理由のブログシリーズを続けていきましょう。次のステップはAcropolisブロックサービスです。Acropolis ブロックサービス(ABS)は4.7のリリースとともに発表されました(2016年6月)。それ以降、我々はその機能を継続的に改善し続けながら、更に顧客の要望に対応すべく、パフォーマンスの改善、そして認定するクライアントの種類を増やし続けています。さぁ、ABSについての「知っておくべき10つの事」のはじまりです:

  1. ABSは高可用性、拡張性、そしてパフォーマンスを阻害すること無く、ハイパーコンバージェンスと物理サーバのためのブロックレベルのiSCSIストレージを単一のソリューションとして解決できる共有インフラストラクチャの実装を可能にします。
  2. ABSはライセンス関連の制限、レガシーアプリケーションの移行の難しさ、既存の投資などの観点から、ベアメタル(物理)サーバ上に残ってしまっているワークロードであってもIT管理者がその既存サーバインフラストラクチャを存分に活用できるようにします。
  3. ABSを効率的なバックアップ、復元のテクノロジーのために利用し、本稼働データベースのクローンのシンプルをPrismのシンプルな運用を通して実現します。
  4. Nutanixは継続的にオペレーティング・システムやハイパーバイザーのサポートの幅を広げていきます:

    Fig177

  5. アプリケーションのパフォーマンスはフォークリフトアップグレード(訳注:インフラもしくはストレージの総取り替え)なしに、Nutanixクラスタのサイズと共にシームレスに拡張することが出来ます。新しいノードを追加すればパフォーマンスとキャパシティの両方を同時に追加でき、その場合でもクライアント側への再構成は必要ありません。
  6. キャパシティを追加している最中も運用を継続することが出来ます。新ヴァージョン(5.0)で追加のオンラインでのLUNのリサイズによって、環境への変更を最小に抑えながら、LUNのサイズの増強を行うことも簡単になります。
  7. 新ヴァージョン(5.0)でリリースされた動的なロードバランシングの機能によって、パフォーマンスのボトルネックを回避し、自動的にクラスタ内でトラフィックのリバランスが行われます。
  8. 新ヴァージョンではCHAP認証とIP/IQNベースのホワイトリストによる高セキュリティ化が実現され、認証されたクライアントのみが特定のiSCSIのLUNへとアクセス出来ることが保証されます。
  9. Microsoft Windows Server Failover Clusteringなどの高可用性アプリケーションは数秒以内にiSCSIのLUNをFail-over/Fail-Back可能です。
  10. ABSではOracle RACを含むOracleデータベースやMicrosoft SQLサーバ、IBM DB2などが動作しているNutanixクラスタ外のベアメタルサーバや仮想化サーバへとNutanixのストレージをエクスポートすることが出来ます。これによってNutanixのウェブスケールアーキテクチャの利点を用意に活用できるようになり、これらのアプリケーションのハイパーコンバージェンスへの移行をご自身のペースで行うことが可能となります。

Fig178

Forward-Looking Statements(原文よりそのまま転記)

This blog includes express and implied forward-looking statements concerning product features and technology that are under development or in process, capabilities of such product features and technology, and our plans to introduce product features, including support for certain third-party solutions, in a future release. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs.  The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; the introduction, or acceleration of adoption of, competing solutions; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our registration statement on Form S-1, as amended, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this blog and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.  Any future product or roadmap information is intended to outline general product directions, and is not a commitment, promise or legal obligation for Nutanix to deliver any material, code, or functionality.  This information should not be used when making a purchasing decision.  Further, note that Nutanix has made no determination as to if separate fees will be charged for any future product enhancements or functionality which may ultimately be made available.  Nutanix may, in its own discretion, choose to charge separate fees for the delivery of any product enhancements or functionality which are ultimately made available.

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

Ntc2017_2

今回は前回は11に増えてしまいましたが、また10に戻って10つの事シリーズ、今回はNutanixをブロックストレージとして使うことの出来る機能ABSについて知っておくべき10つの事です。管理する物は少ない方がいい!これは様々なものに共通することです。Nutanixに外部のストレージを接続できますか?というご質問をいただくこともまだ多いのですが、今後はその逆、外部のストレージが保守切れになるので、Nutanixを増設して外部ストレージの上のアプリケーションを延命したい、という話が増えてくるでしょう。

Nutanix(ABS)なら5年(または+α)で保守が切れてしまう従来型のストレージと違い、クラスタ内のノードは順次退役、新しいノードを追加して新陳代謝されますが、Nutanixクラスタとしては永遠に使い続けることが出来ます。5年毎のストレージ入れ替え(本文ではフォークリフトアップグレードと紹介されています)が将来に渡ってなくなることを歓迎しない方はいらっしゃらないでしょう。5年毎とは言え、あちこちにサイロがあれば結局毎年フォークリフトアップグレードしているかもしれません。一つづつこれを減らして管理の手のかからない真のプライベートクラウド(Nutanix流にいうとエンタープライズクラウドもしくはインビジブルインフラストラクチャ)を実現していきましょう。

2017/01/25

Nutanixが最高のオールフラッシュプラットフォームであるその11の理由

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のVP of Client Strategy at Nutanixを務めるSteve Kaplan氏によるものです。原文を参照したい方は11 Reasons why Nutanix is the Best All-Flash Platformをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

本ブログ記事に関連して、Nutanix社、Mellanox社に協賛をいただき、セミナーを実施致します。ここではお話できないもっともっとDeepな内容も!!

Nutanix x Mellanox 次世代フラッシュメモリと高速ネットワークセミナー

次世代フラッシュの登場でデータセンターアーキテクチャーに何が起ころうとしているのか?PernixData社を買収したNutanix社は何を目指しているのか?

お申込みはこちらから。ぜひ足をお運びください。

Fig166

オールフラッシュ装置 : 死刑囚が(処刑台に向かって)歩く

オールフラッシュ装置(AFA)を製造メーカーは確実な回転ディスクの陰りに感極まっていることでしょう、しかし、ハイパーコンバージドインフラストラクチャ(HCI)が全ストレージカテゴリーを逆さまに飲み込んでしまいそうにもなっています。AFAは従来型のストレージ装置に比べ高速で、管理が簡単ではあるものの、依然としてSANなのです。NutanixのエンタープライズクラウドはAFAよりも優れたフラッシュのためのプラットフォームであるだけでなく、その他のHCIソリューションよりも優れたものです。以下にその11の理由を挙げます :

1) ネットワークレイテンシの効果を劇的に削減

NutanixのHCIは既にネットワークのレイテンシを削減することで最高のAFAのパフォーマンスを誇っています(@vcdxnz001の記事を見てください。ネットワークは遅すぎる、どうしたら?)。NVMeや3D Xpointのような革新はハイパーコンバージド環境で、データをコンピューティングのすぐ傍らのフラッシュやもしくは他のストレージクラスメモリ(SCM)上に置くその効果をより強調することになります。従来型のモデルである、オールフラッシュ装置から低速のネットワークを経由してデータにアクセすることは高速なフラッシュ/SCMからのメリットを阻害することになります。

Fig167※訳注 NVMe = 30マイクロ秒のレイテンシ、40GbE = 40マイクロ秒のレイテンシ、ネットワークはフラッシュには遅すぎる!

コンピューティングの傍らではなく、ネットワークに接続された磁気メディアのレイテンシのために設計されたプロプライエタリの装置へとフラッシュを追加するということは全く意味をなしません。これは単に距離の問題であるという簡単な物理の問題へ帰結します。フラッシュはアクセスのために直接(ダイレクト)接続されるべきであり、複数のホップ、プロトコル、パフォーマンスを制約するコントローラが必要な間接(リモート)で接続されるべきではないということです。単なる物理です!

Fig168

NutanixとAFAのI/Oパスの長さの比較

AFAのベンダーは高速なネットワークとNVMeをファブリックに利用することで、低遅延で高帯域を実現できるという提案をしてくることも有ります。Nutanixはお客様へ高価で従来からの複雑性を継続させるような新しいストレージファブリックを買うこと無く、フラッシュのメリットを最適化して利用することを実現します。

Fig169

Michael Webster氏のLong Virtual White Cloudsからの引用画像

2) 統合率の優位性

Nutanixは全てのサーバのリソースに加え、92TBまでのフラッシュをたった2Uに積み込むことを実現しています。AFAはその装置以外にもコンピューティング、ストレージファブリック、そして、大抵は(※バックアップ用?)低コストのディスクストレージも必要とします。これははそれぞれ更に電源、ラック領域、空調が追加で必要です。

3) コモディティのハードウェア

PureなどのほとんどのAFAはプロプライエタリのハードウェアを利用しています、しかし、これは新しいハードウェアの革新を迅速に取り入れようとする場合には通行止め標識になってしまいます。オールフラッシュ装置はテクノロジの飛躍的な進化によって製品が古臭いものとなり、次にキャパシティが必要なタイミングでフォークリフトアップグレード(訳注 : 全てフォークリフトで取り外されて、別のものを入れ替えること)されてしまい、顧客が離れていくのを危険視しています。今日の早いペースのテクノロジ環境において、成功するのは世界で最も大きなコモディティハードウェアの製造メーカーによって駆り立てられた革新を活用したグローバル経済の規模での拡張を足がかりにした会社のみです。

サン・マイクロシステムズのケースを取り上げましょう。業界がよりコスト効率の良い、パーソナルコンピューターで人気を博したインテル互換のマイクロプロセッサへと舵を切っているにも関わらず、サンはプロプライエタリのハードウェアに賭けました。サンは投げ売り状態でOracleに買収される前にはその価値を80%も落としていました。

ヴァイオリンメモリがもう一つの例です。ヴァイオリンは市場へオールフラッシュメモリソリューションをいち早くもたらした最初の会社の一つです。これは非常にクールで、高速なテクノロジであり、優れたエンジニアリングに支えられて10年ほど前に創業しました。

しかし、コンシューマは別の考えを持っていました。彼らはソリッドステートドライブ(SSD)の速さと信頼性を愛し、今日ではほとんど全てのノートPC、デスクトップ、メモリ装置の中でそれが使われています。SSDの価格が急落しても、ヴァイオリンは自身のプロプライエタリのフィールド-プログラマブル ゲート装置(FPGA)を利用する設計を選択しました。洗練されたソリューションでしたが、おそらくは、SSDの急速な改善についていけなくなったのです。ヴァイオリンのプロプライエタリのハードウェアは急速に力を失い、会社はNYSEのリストから消えてしまうことになりました。

ハイパーコンバージドのビジネスはいみじくもコモディティハードウェア上で唯一、活況を呈しているエンタープライズテクノロジーであると言えるでしょう。すべての有力なクラウドプロバイダーもコモディティサーバを利用しています。プロプライエタリのハードウェアは一時的には会社の革新を保護する基盤となった時期もありますが、今は製造メーカーの競争力の邪魔に、もしくはその破壊すら行いつつ有ります。

4) 分散されたストレージコントローラ

ほとんどのAFAは物理の、分散されていないストレージコントローラを利用しており、これはトラフィックによって容易に飽和してしまいます。コントローラーがボトルネックになることによって、それ以降はいくらSSDのシェルフを追加してもパフォーマンスが向上することはありません。

単独のエンタープライズのSSDが最高で500MB/sほどのスループットが出ると仮定すると、デュアルの4GbのFCアダプタを利用している場合ではコントローラはSSDが2本でボトルネックとなります。デュアルの16Gb FCアダプタへとアップグレードしたとしても、8本をさばけるだけです。

これらの制限に打ち勝つために、AFAは複数のアダプタを用意する必要があり、結果としてファブリックの構成は複雑になります。しかし、これは確実にコントローラーの制限にかかってしまい、お客様は更にAFAシステムを購入しなくてはならず、さらなるサイロを生むことになります。

これとは対象的にNutanixは常にクラスタにノードを追加する事になりますが、この度に仮想ストレージコントローラを追加することにもなります。これによってすぐさまパフォーマンスを上げることが出来ます。信頼性も著しく向上し、一つのコントローラが失われたとしても影響は非常に小さなものになります。これがNutanixが環境を破壊すること無く、1クリックで小さな影響のみでアップグレードとメンテナンスを行うことが出来る理由です。

5) データローカリティ

ロサンゼルス市内の車の75%が道路から突然なくなったとしたらなにが起きると思いますか? 渋滞があっという間に無くなるだけではなく、市は事故の減少、道路保全工事の削減、汚染の削減など他にも多くのメリットを得ることになるでしょう。

Nutanixのデータローカリティはデータセンタ環境においてこれと似たように作用します。ほとんどのReadのトラフィックをネットワークから削減し、そのかわりにReadはノード内のローカルSSDから提供されるようになります。Writeやエンドユーザーのアプリケーションが利用できるネットワーク帯域は効率的に増え、ストレージのパフォーマンスのみならず、ストレージが提供しているアプリケーションのパフォーマンスまでもが改善するのです。

Fig170

6) 拡張性

キャパシティパフォーマンス : AFAは大抵は2つの物理ストレージコントローラしか持ち合わせておらず、システム内に搭載されているRAM/NVRAMの総量によってメタデータのキャパシティの拡張がボトルネックとなってしまいます。SSDを追加しても、殆どの場合、パフォーマンスが向上することはありません。

同様に、AFAのお客様はもっと大きな処理能力をもつ多きなユニットへアップグレードするか、複雑なファブリックの相互接続を追加するか、もしくはサイロを作る以外に方法がありません。AFAの製造メーカーは既存のコントローラーを新しく高速なものに置き換え可能だとしていますが、その際の停止や出費を差し置いても、これはボトルネックをネットワークへと移動させるか、既存のフラッシュメディアに対してしか効果はありません。

Nutanixでは対象的に、AFAとは異なり、2つの物理ストレージコントローラによってボトルネックを生じることはありません。それぞれのノードの仮想マシンはそのノード上のコントローラー仮想マシン(CVM)によってサービス提供されます。クラスタにノードが追加される度に1つのCVMも追加されます、ですからキャパシティがリニアに拡張されるん見ならず、パフォーマンスと信頼性とが、管理スタック機能とともに拡張されていくのです。Acropolis ブロックサービス(ABS)とAcropolis ファイルサービス(AFS)はNutanixがお客様が拡張可能な物理と仮想のワークロードに使えるだけではなく、同じNutanixクラスタからファイルサーバとしても使えるということも実現しました。これによって非効率なサイロを削減できるのです。

Fig171

重複排除/圧縮パフォーマンス : Nutanixのユニークな重複排除と圧縮の実装はパフォーマンスへのオーバーヘッドを最小化します。Nutanixは物理リソースをより多く利用し、また結果に関係なくすべてのIOへ影響を及ぼす総当りでのすべてのデータの重複排除/圧縮は行いません。

信頼性 : 信頼性と高可用性の両方が全てのNutanixのスタックを通じて組み込まれています。レプリケーションファクター2(RF2)またはRF3をイレイジャーコーディング(EC-X)とともに利用することでディスクに対して優れた耐障害性を実現できます。ブロックアウェアネスはノード障害の回避を実現しますし、同期と非同期のレプリケーションはデータセンタ全体の信頼性を提供します。

オールフラッシュのストレージオンリーノード : ストレージオンリーノードによって、Nutanixのお客様はコンピューティングとストレージを別々に拡張することが出来るようになり、これによって自身のオールフラッシュ環境のコストを最小化することが出来ます。

7) シンプルさ

Nutanixのワンクリックアップグレードはアップグレードに関わる複雑さとリスクの両方を削減します。複雑な相互の組み合わせマトリックスや運用のガイドなどはありません。NutanixはフラッシュベースのアーキテクチャをLUNを排除し、ストレージの構造ではなく、その表示のフォーカスを仮想マシンにして、集中管理とキャパシティプランニングを含めることで、さらなるシンプルさを提供しています。

Fig172

8) ワークロードの統合

AFAはフラッシュ装置から情報をネットワーク越しに処理のためにコンピューティングまで送信する必要があります。以前に述べたレイテンシが追加される以外にも、これによってさらなるキュー管理とオーバーヘッドが追加されることになります。CPUはアプリケーションの要求で小さなブロックを同時に高いIOPSで受け取る、または大きなブロックを高いスループットでを受け取ると簡単に過負荷状態になります。一貫したパフォーマンスを保証するため、AFA管理者は頻繁に同じプラットフォームで動作しているOLTPとOLAPのワークロードを分離しなくてはなりません。

Nutanixはコンピューティングからダイレクトにアクセス可能なストレージを提供できます。限られたオーバーヘッドでリクエストをさばき、混在したワークロードに一貫した低遅延をもたらします。そして、Nutanix Acropolis ブロックサービスを利用すれば、Nutanixは異なるタイプのアプリケーションにたいしてまとめて対応が可能なストレージのバックプレーンとなります。お客様は物理のワークロードと下層のワークロードを同一クラスタ内で統合することさえできるようになるのです。

加えて、AFAはブロックのためのブロックストレージデバイスとファイルのためのフラッシュ装置を搭載しています。Nutanixでは、ストレージはブロックとファイルで共有されます。

Fig173

9) ミッションクリティカルアプリケーションの展開実績

Nutanixはたとえ、それが幾つかのワークロードの混在であったとしてもクリティカルアプリケーションのための適切なパフォーマンスを箱から出してすぐに提供することが出来ます。ストレージアクセスの障害回避、自己回復、常に行うデータの整合性のチェックなどを実装し単一障害点を排除しています。ストレージのパフォーマンスは想定通りで、複雑な構成やチューンングは不要です。

非破壊的なソフトウェアの更新で、計画的なダウンタイムを排除し、ミッションクリティカルアプリケーションをホストしているNutanixに新たな機能をもたらします。ソフトウェアのアップグレードや拡張のためのメンテナンスウィンドウはもはや過去のものとなりました。他の殆どのHCIとは異なり、NutanixはエンタープライズにSplunk、Oracle、SAP、SQLサーバ、Exchange、そして、他にも多くのミッションクリティカルアプリケーション(NutanixとVxRackのみがSAP認定を取得しています)での導入の数年もの実績と成熟が有ります。

Fig174

10) 総所有コスト(TCO)の低減

AFAは最終的にはコントローラーのキャパシティ不足に陥ります。テクノロジーは既存のAFAソリューションが比較しても経済的ではないと言うところまで進歩するか、もしくは、単に機材が古くなってしまうかです。いかなる場合であってもAFAを所持している場合にはフォークリフトアップグレード(完全入れ替え)ー その手順は大抵の場合、高価で複雑かつ、時間のかかるものですーに直面することになります。その結果として、AFAを所持していた人は殆どの場合、最初に必要な以上のキャパシティを購入し、4年か5年後に利用を終えるまで、要件に見合うリソースが充分かどうか、祈り続けることになるのです。

Nutanixを利用している人はフォークリフトアップグレードを今後経験することはなくなり、そのときに必要としている以上のノードを購入する必要はなくなります。テクノロジーが変化ても、新しいノードはクラスタにマウスクリックだけで追加が可能です、他の全てはソフトウェアが面倒を見てくれます。Nutanixはその下のリスクも排除してくれるのです。

ストレージ装置そしてストレージファブリックとそれに付帯して最初に購入しなくてはならない必要以上のキャパシティの必然性を完全に排除することで、Nutanixは導入コストの低減のお役に立ちます。プロジェクトがその後数年にわたって拡大したとしても、ムーアの法則とNutanixソフトウェアのパフォーマンス面での改善の両面に支えられ、ノードあたりの統合率は向上し、同じワークロードを動作させるのに必要なノード数は少なくなっているのです。

Fig175※ 訳注 : VDIのためのNutanixを4.5から4.7.2にアップグレードしたら、IOPSが40%向上し、レイテンシが50%も下がりました。ユーザーは「私のVDIセッションは今日はより早くなった」とコメントしています。私はhappy01です。

11) エンタープライズクラウドプラットフォームの先進性

最終的には、業務そのものについてだけではありません。どのようにそれを行うか、なのです。ウェブスケールアーキテクチャの利用はNutanixのユニークな差別化要素であり、ハイパーコンバージェンスをエンタープライズクラウドプラットフォームの一部へと昇華させています。Sassandra、NoSQL、MapReduce、そしてCuratorなどの分散テクノロジーはオールフラッシュ環境を最適化して、優れたパフォーマンスと効率性を実現しています。

データアクセス : 古くからある樹木構造でのメタデータのクエリアーキテクチャ(BtreeとR&B)はメタデータがそれぞれの物理コントローラに保存されているような装置環境では上手く動作しましたが、オールフラッシュのHCI環境では最適とはいえません。HCIでは、メタデータは多くのノードに分散されてー樹木構造での検索は非効率ですーいます。この非効率さに対処するため、NutanixはCassandraとNoSQLのようなビッグデータのテクノロジーを利用し、非常に高速な検索と、高い耐障害性を実現しています。単一障害点はありません。

データの保存 : 古の3階層や他のHCIのIOパス内でデータを並び替えるアプローチとは異なり、Nutanixはそれをバックグランド処理として行い、より高いパフォーマンスを実現します。ノードが追加される毎にシステムは拡張され、重複排除と圧縮はより高速になり、さらにデータのローカリティは増加します。シームレスな拡張性によって、データをメモリか利用可能なストレージ層に置くべきかという昇格、降格の評価も迅速になります。

分析 : オールフラッシュの環境であっても異なる階層のフラッシュ(パフォーマンスと耐久性)が存在します。メタデータは継続的に増え続けるため、メモリやもっとも高速な層へおいておくのはコスト効率的に難しくなります。

Nutanixはここでもビッグデータのアプローチでこの課題を解決しています。NutanixのためにカスタマイズされたヴァージョンのMapReduce/Curatorがデータのホットデータか否か、圧縮できるか否か、重複排除出来るか否かなどの主要素情報を決定するために利用されます。同様のフレームワークを用いて、ローカリティのために、どのデータを別のノードへ移すべきなのか、どのデータを消すべきなのか、どのデータが再配置または再均一化されるべきなのか決定されます。これは特に障害イベント時に利用されます。

こうした解析は傾向分析、リアルタイム分析、事前的な監視、根本原因の分析、アラートの発行のための深い知見を実現します。

タイミング : 最適とはいえない、インラインでの圧縮やプロプライエタリハードウェアによる重複排除などに依存している他のソリューションとは対象的に、NutanixはオフラインでのMapReduce/Curatorによるソートに対応しています。これによって圧縮するか、重複排除するかの判断をする以前に、より多くのWriteを実行でき、一極集中しているデータベースのパフォーマンス要件の制限を回避しています。

ユニファイドキャッシュ : キャッシュはローカリティを実現します。重複排除はより多くのデータをこのパフォーマンス層に格納することを可能にし、ローカルキャッシュのヒットの可能性を最大化します。パフォーマンスに制限をうけることなく効率性を最大化するため、Nutanixはインラインでコンテントキャッシュのローカルでの重複排除を行います。

Fig176

NVMe : 死刑囚が(処刑台に向かって)走っている?

少なくとも1つの従来からのストレージ製造ベンダーがNVMeをそれこそが未来だとしてプロモーションしています。しかし、NVMeへの移行は今まで以上にデータはコンピューティングの隣りにあるべきで、ネットワークの彼方ではないということを強調することになるでしょう。これはすべてのファブリックを延長しただけの一枚板の滅亡への道のりを早めるだけです。ーもちろん、AFAもそれに含まれます。

コンテンツと編集について以下のメンバーに謝辞を述べたいと思います。@joshodgers @briansuhr @_praburam @Priyadarshi_Pd @sudheenair @binnygill @vcdxnz001 @RohitGoyal

もっと詳しく

NutanixのFlash ForwardウェブサイトのランディングページとeBook

Ten Things You Need to Know About Nutanix Acropolis Block Services (後日翻訳予定)

Nutanix Acropolis ファイルサービスについて知っておくべき10つの事

免責事項: このブログはNutanix.com以外へのコンテンツへのリックが含まれています。Nutanixこうしたサイトへの統制は行うことが出来ないため、全ての外部サイトのコンテンツと正確性について、免責とさせていただきます。外部サイトへのリンクはこうしたサイトのコンテンツへの承認を表明するものではありません。

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

Ntc2017_2

さて、10つの事シリーズですが、いきなり11つあります。前回、前々回とMichael Webster氏の記事を翻訳してきたのはこの記事のための伏線だったわけです(単に、引用を辿っただけとも言う・・・)。Nutanixの(特にI/O周りの)技術を知れば知るほど「一つ一つの技術」ではなく、それを積み上げた「アーキテクチャ」であるということが言えると思います。特にストレージのパフォーマンスに関しては色々と痛い目を見てきたり、その技術自身の素晴らしさに夢中になって学んでしまったり(かくいう私もそうですが・・・)と、一筋縄ではいかない人間が集中しています。今回の記事はそんな方に読んでいただきたい内容です。若干いろいろなところで(理解のしやすさのために例を上げているのだと信じていますが)バチバチと火花を飛ばすような表現も有りますが、実によくまとめていると思います。ぜひセミナーへも足をお運びください!

2017/01/18

フラッシュにとってネットワークは遅すぎる、どうしたら?

Fig163


本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はYour Network Is Too Slow For Flash And What To Do About Itをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig162フラッシュの技術がデータセンタの形を変えつつあることに疑いを持つ方はもうおられないでしょう。ロックバンドのクイーンは30年以上も前にそれを理解していたようですが!フラッシュはハイパフォーマンスアプリケーションの展開のための経済性を変革しましたし、回転するディスクをベースとした従来型のストレージシステムには多くあったパフォーマンス上のボトルネックを取り除きました。実環境のデータでのハイブリッドストレージ(SSD+HDD)のデータの削減率という記事の中で示したとおり、データの削減のためにフラッシュを利用する必要はありません、ですが、データ削減とともにフラッシュストレージを利用すればフラッシュの容量の経済性を改善することが出来ます(ディスクを利用するよりも安く、フラッシュのパフォーマンスを利用することが出来ます)し、電源や空調を削減し、可動パートがないことによる信頼性の改善を同時に得ることが出来ます。みなさんはまだご存じないかもしれませんが、近年のSSDなどのフラッシュデバイスはハードドライブ以上の信頼性を誇っています。物理的な容量という観点からもSSDのキャパシティは期間あたりのでのダイあたりのトランジスタ数の収容量のおかげで、CPUのパフォーマンスが上がっていくのと同じようなスピードで増えていっています。あるベンダーは既に2.5インチのドライブで16TBという物を出荷開始しており、この価格は2.5インチのハードドライブよりも安くなっており、消費電力も低く、冷却コストも低く、スペースもより小さくすることが出来ます。記事の冒頭の画像はインテルのM.2デバイスのものですが、3.5TBものキャパシティをもち、恐ろしいほどの小さなフォームファクターを実現しています。では、ネットワークはこれにどう対処しなければならないのでしょうか?

ファイバーチャネルを利用しているのであれ、イーサーネットを利用しているのであれ、ネットワークはフラッシュの技術、そしてもっと重要なことにはアプリケーションを上手く動かすために大きな役割を担っています。この理由はとてもシンプルです。データベースの管理者にとっては随分前から知られていたことです。データがアプリケーションから遠くはなれてしまうことで、レイテンシが高くなり、スループットが落ちてしまい、それによってパフォーマンスとユーザーからのレスポンスタイムが劣化してしまうということが原因です。これはフラッシュによってより明確に浮かび上がります、特にキャパシティとパフォーマンスの技術がどんどん先へと進み、1本、もしくは数本のデバイスだけでネットワークのパフォーマンスを限界に追いやってしまうことになるからです。こうした理由は幾つかのエンジニアリングシステムがインフィニバンドのネットワークやRDMAを利用するための一つの理由ですが、それでさえ、遅いのです。以下は3つの異なるフラッシュデバイスと現在のイーサネットネットワーク技術のスループットを比較したグラフです。

Fig164

数多く目にする2.5インチのホットプラグ出来る一般的な形のフラッシュデバイスは今日では500MB/sのスループットを実現でき、最大で50K(5万)か、それ以上のIOPSを低遅延で実現することが出来ます。ですから、たったの2本のドライブで10GbEのイーサネットワークを飽和させますし、4本あれば16Gb/sのFCネットワークも飽和させてしまいます。幸いなことに、我々はサーバごとに複数のNICポートもしくはHBAを通常利用しています。しかし、これはストレージ装置が数十から数百のドライブもしくは、サーバ内、もしくはストレージシェルフで12~24のドライブを利用するようになると役には立ちません。もちろん、今日一般的なフラッシュの技術であったとしても、それをネットワークに接続するのであれば、そこがパフォーマンスのボトルネックとなり、全パフォーマンスに近い値をなし得ることはほとんど不可能です。

さて、今日のNVMeへと目を移しましょう。これは次世代のフラッシュテクノロジーであり、2016年の終わりまでには一層普及し、2017年にはメインストリームとなっていく技術です。それぞれのデバイスは40GbEのNICを飽和させるのに充分なスループットとIOPSになります。もし、システム内に2つのデバイスがあるとしても、デュアルポートの40GbEのNICを飽和させてしまいます。これがEMCのDSSDのようなNVMeベースのストレージシステムが従来型のネットワークでストレージとサーバを接続しない主な理由で、そのかわりにDSSDは多くの第3世代 PCIe接続を多く束ねて接続を実施しています。彼らは既にネットワークが大きなボトルネックで、NVMeベースのフラッシュが提供するようなパフォーマンス能力を届けるためにはおそすぎるということを認識しているのです。それぞれのNVMeデバイス自体は今日我々が目にする一般的なほとんどのエンタープライズストレージのフラッシュよりも6倍から8倍は高速です。今日どれだけのお客様が40GbEのNICや32Gb/sのFC HBAをデータセンタ内のサーバに搭載しているでしょうか?

SSDは速いです。NVMeをベースにしたSSDはもっと速いです、ですが、インテルとマイクロンが共同で開発している3D Xpointはブッたまげるほど速いのです。3D Xpointは2015年にアナウンスされ、エンタープライズのプラットフォームへの導入は2018年か2019年と期待されています。これは今日一般的なエンタープライズのシステムで利用されているSSDの1000倍高速です。3D Xpointが提供するパフォーマンスによって、マザーボード、プロセッサ技術、メモリバス、そしてそれ以外のすべてが強力にブーストされることになるでしょう。デバイス単独でもマルチポートの400GbEネットワーク(400GbEは100GbEの次に予定されています)を飽和させるのに充分です。これを今すぐにネットワークへと接続したとしても、ネットワークを1年は待たなくてはなりません。3D Xpointは150ナノ秒以下のレイテンシを提供すると予想されており、これは今日の40GbE、100GbEのスイッチポートよりも速いのです。Gen3/Gen4のPCIeを利用したとしてもこれほどのパフォーマンスへの対応には充分に速いとはいえません。インメモリデータベースの影響を考えなんて、とんでもない!これはDRAMのスピードで動作しているのです。

Fig165

上のCrehan Research Inc.のデータが示すように、10GbEと40GbEのポートの利用は増え続けており、100GbEのポートのコストも下がりつつ有ります。しかし、100GbEはまだ幅広く受け入れられているとは言い難く、今時点では40GbEのサーバもまだという状況です。Crehan Researchの2015年のレポートによると100GbEは2017年から広く利用され始めると予測しています。しかし、これはスイッチングやバックボーンでの話であり、サーバーでの利用ではありません。NVMeがメインストリームとなり、3D Xpointを数年先に控えても、それぞれのサーバ間のネットワーク接続はこの1000倍の隔たりを短い時間では吸収しきれません。本来でいえばデュアルポートのTbEの接続を備える必要があるのです。

ですから、こうした証拠からもしフラッシュをネットワークに接続するとしたら、パフォーマンスへ影響を与えるボトルネックと投資への有効性への制限をある程度は抱えてしまうことになるのです。それと同時にお持ちのフラッシュが叩き出す可能性があるスループットに近いレベルでのデータの保護についても保証がほしいと考えるでしょう。どうすれば両立できるのでしょうか? 高いパフォーマンス、低いレイテンシ、アプリケーションに可能な限り近いデータ、それでいてデータ保護を保証できる方法は?

簡単な答えはSSDをローカルのRAIDカードに接続する、ということになるでしょう。これは2.5インチのSSDであればうまくいくでしょう(もちろん、パフォーマンスの観点から複数のRAIDカードをサーバに搭載しなくてはなりません)、しかし、これはNVMeや3D Xpointでは上手く行きません。複数のローカルのRAIDコントローラーを全てのサーバに入れる、ということは個別に管理しなくてはならない数百、数千のストレージキャパシティのサイロを生み出します。我々は長い時間をかけてこの管理のオーバーヘッドを集中管理することで回避できるアーキテクチャを作り上げてきました。この新しいテクノロジーを活用すべきで、後戻りすべきではありません。

現実的な回答は2つです、一つ目は仮想化、そして二つ目は本来の意味で分散されているシステムアーキテクチャへの投資で、そのこころはデータローカリティという概念です。データローカリティを持つアーキテクチャはデータ保護のために分散しながら、一方でデータがアプリケーションにとってローカルにあるということを保証します。仮想化が必要な理由は膨大なまでの高いパフォーマンスを持つストレージがあり、単独のアプリケーションではそれを現実的に使いこなせないからです。仮想化を利用することで、コンピューティングとストレージのキャパシティとパフォーマンスを充分に利用することが出来るのです。幸福なことに、インテルはプロセッサの能力を毎年向上させ続けており、コンピューティングのためのコアを、ハイパフォーマンスストレージのためにも利用することが出来るようになっているのです(プロプライエタリなコンポーネントは必要ありません)。

データローカリティの概念は大きく成長し、拡張する必要がありながら、データ保護と高いパフォーマンスが必要となる多くのウェブスケールアプリケーションで利用されています。データローカリティの概念で、膨大なネットワーク負荷を減らすことが出来、それがボトルネックに成長することを防ぐことが出来て、新しいタイプのフラッシュテクノロジーの将来を保証することが出来るのです。データはアプリケーションからはローカルのPCIeバスを通じてメモリに読み込まれ、書き込み、もしくは変更だけがそのデータを保護するためにネットワークを経由します。データローカリティをベースとしたアーキテクチャが適切に実装されていれば、拡張はリニアに行え、想定通りの一貫したパフォーマンスが得られるのです。これによって多くの推測での作業やトラブルシューティング、ビジネスにおけるリスクを削減できます。これはアーキテクチャが環境へのシステムの追加や退役などの矢継ぎ早に変更される要件に適応する能力をより多く保持しているからです。

データローカリティをもつ分散アーキテクチャを利用して、カスタムメイドのアプリケーションや新しいウェブスケールのビッグデータアプリケーション(Hadoopやそれに準じるもの)へも対応が可能です。ですが、もしこうしたタイプのアーキテクチャからメリットを受けることが出来ない開発者がいない場合、どうしたメリットが有るのでしょうか?新しいストレージの技術に適応可能なアーキテクチャでかつ、変化の起こりつつあるデータセンタの将来を保証できるものは?その答えはSANではありません。ここで述べてきたとおり、フラッシュをネットワークの終端に接続するとしたら、その近く以外ではなにも実現ができないのです。現在存在する唯一のソリューションはハイパーコンバージドシステムで、サーバとストレージは単一のユニットに融合しており、それは分散アーキテクチャをなしているのです。

すべてのハイパーコンバージドシステムはデータローカリティの概念をその中に実装しているわけではありません。ですから、注意深くベンダーを選定してください。それぞれのベンダーをご自身の要件とビジネスのニーズにおいて評価し、どのベンダーが大きなアーキテクチャの変革無く、将来に渡って投資を保護してくれるのかをお考えください。幾つかのベンダーはアンチローカリティをプロモーションし、お客様へ単に多くのネットワークポートを購入しながらオールフラッシュを利用することを推奨しています。残念なことに、ネットワークカードはフラッシュのテクノロジーに対応ができません(400GbEでも遅いのです)。ですから、パフォーマンスは最高のものが保証されませんし、そのアーキテクチャではどんどんと変化していくフラッシュのテクノロジーをシームレスに採用していくことも出来ないのです。

さらに、一度フラッシュに投資を行い、それをアプリケーションの近くへと配置すれば、CPUの利用率も上昇させることが出来るということも付け加えさせてください。特定のユースケースにおいてこれは劇的です。これはストレージがもはやボトルネックではなくなったということが原因です。アプリケーションはIOの完了を待つ必要がなくなりますので、ユーザーへのレスポンスが良くなりますし、バッチジョブはより早く完了しますし、より短い時間で多くのトランザクションからなるプロセスを実行できます。結果として、CPUのアイドルの時間がより少なくなるのです。究極的にはより短い時間でより多くの有益なしことをこなすことが出来ます。ですから、フラッシュを利用して急にCPUの利用率が80%を超えたとしてもビックリしないでください。これは期待通りです。投資がすべて良い方向へ使われた結果に他なりません。それとも、もっと沢山の機材を購入されますか?

終わりに

この話とそれ以外の話をビールを飲みながらNutanixの開発エンジニアであるTony Allen氏としているビデオを以下から見ることが出来ます。以下のビデオはエンジニアとビールを飲もう!シリーズの1つです。(訳注:字幕は入れておりません)

データローカリティは唯一の将来が保証されたデータセンタアーキテクチャであり、かつ、データセンタを継続的に破壊し続けるフラッシュテクノロジーの進化を取り込むことが出来るものです。Nutanix(私はそこで働いています)はデータローカリティをアーキテクチャのコア部分として本当に初期のリリースから取り入れています。この主な理由はアーキテクチャは拡張し続けられなくてはならないものであり、過去5年間に導入された異なる世代の環境にその下のアーキテクチャの変更無く受け入れられるものでなくてはならないからです。もちろん、起こりうる変化に対応して将来保証されていなくてはなりません。我々はお客様に様々なプラットフォームを組み合わせて使っていただくことが出来るようになっています。それでいてデータをアプリケーションにとってのローカルにし、データとアプリケーションの間のパスをできり短くし、アプリケーションのレイテンシを低くすることが出来るのです。

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

Ntc2017_2

さて、前回に引き続きオールフラッシュの内容ですが、その内容は衝撃ではありませんか? 今後はフラッシュデバイスがどんどん早くなり、SSDが安くなっていく・・・ここまでは様々なストレージベンダーもが口をそろえて同じ事を言いますが、フラッシュデバイスはもっと早くなり・・・SANでは対応ができなくなる(もしくは普及もしていないような高価な高速なNICを買い続ける?)ということです。

もちろん、普及しなければNIC値段は下がりませんのでジリ貧ですが、「データローカリティ」を備えたHCIであればこのネットワークを超えるスピードを持つフラッシュを効率的に(もちろん、Writeが極端に多いアプリケーションがあれば話は別ですが、いろいろな仮想マシンで負荷の平均化が出来るでしょう)データセンター内に取り込むことが出来るのです。

アプリケーションとデータを近くする以外にはネットワークのボトルネックを通さなければいけませんので、正にこの話はPernixDataが描いていたストーリーですし、それを買収したNutanixがどこを見ているのかが分かりやすい記事だと思いました。2017年、いよいよPernixDataのテクノロジーが入ったNutanixが楽しみです!

2017/01/11

実環境のデータでのハイブリッドストレージ(SSD+HDD)のデータの削減率

本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はReal World Data Reduction from Hybrid SSD + HDD Storageをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig149

オールフラッシュベンダーからそして、別のタイプのハイパーコンバージド(ストレージとサーバをハイパーバイザと1つのパッケージにした)ベンダーからも多くの話が出てきていますが、常に湧き上がる疑問はどのタイプのシステムがより多くのデータ削減を行うことが出来るのか、というものです。残念ながら、殆どの場合、例に上がるのは現実からある程度簡略化されたものばかりです。

ある人はオールフラッシュでなければデータ削減機能は意味が無いと言いますし、別の人はハードウェアカードがなければデータ削減機能は意味がないと言います、また別の方は従来型のSANが必要だと言うでしょう。様々な技術と様々な異なるシステムを組み合わせ、より良いデータ削減率を得ることも出来ます。じゃあ一体何が正しいと言うんだい?真実はデータ削減率は保存されているデータのタイプに大きく依存し、逆に、どのようにデータ削減を行うかにはさほど依存しないということです。既に圧縮されているイメージデータや暗号化されたデータベースシステムに対してはどうやったとしても非常に小さな削減効果しか得られません。重複排除が簡単なVDIのイメージのようなデータを保存しているのであれば、もしくはテキストのような圧縮可能なデータを保存しているのであれば、その効果は非常に良いものになります。

あるベンダーはこの数字を例えばスナップショットは重複排除される、であるとか、テンプレートから展開されたデータは重複排除される、など巧みに操作していますが、いずれも誤解を招くことになります。スナップショットを取るということはデータを削減することにはつながりません(そしてバックアップでもありません)、しかしながら、テンプレートからの展開をスマートなメタデータ操作で実行することはデータの削減になります、ですが、これは重複排除ではありません。重複排除は流入してくるデータが新しいパターンであるということが認識されて初めて適応されるもので、過去にすでにパターンがシステム内に保存されている際には必要が無いものなのです。重複排除は特定のタイプのアプリケーションでは非常に効果が高く、逆に他ではさほどでもありません。これは圧縮が特定のものにはうまくいくし、別のものではうまくいかないということと全く同じです。

もっとも最低の議論というのはオールフラッシュを使えば良いデータ削減率が得られる、であるとか、それがパフォーマンスに影響を及ぼすであるとか、であり、これはベンダーのプラットフォームの設計を理解していない場合には全くの間違いです。これを示すために、ハイブリッドのソフトウェア定義のシステムでSSDとHDDを搭載しているものでも優れたデータ削減率とパフォーマンスへの問題がないことをお見せいたしましょう。では実際のお客様のホンモノの環境の結果について見ていきます。

私がこれから共有するすべての結果は私自身、もしくは私のNutanixの同僚へと送られてきたものので、その環境はすべて標準のハイブリッドシステムのものであり、そのユースケースは様々に異なったものです。私はNutanixのデータしか持ち合わせていないので、結果はNutanixを利用した場合のものですが、他のシステムでも似たような結果が得られるか、その結果が異なる場合もあるでしょう。これは動作させているシステムが異なれば結果も様々だからです。

以下の結果はサーバーワークロードのもので、簡単に圧縮できるデータを多く保持している場合のものです。ですから、非常に良いデータ削減率を示しています:

Fig149_2

このケースではデータはExchangeのJetStressテストを用いたものです。JetStressのデータは容易に圧縮ができるもの(メールデータ)ですから、圧縮にチューニングされたあらゆるシステムにおいて不適切な(以上に高い圧縮率)な結果を提示することになります。ですから、JetStressでテストを行う場合には圧縮をオフにするのが良いと思います。もしもストレージシステムが圧縮をオフに出来ないような場合には、実環境での結果を得ることはできません(JetStressの結果ではなく、実際の場合の結果です)。

次なる結果はOracle RACデータベースのものです。データベースはTPCCのようなトランザクショナルデータを格納しています。ですから、非常に良いデータ削減率を得られます。しかし、単なるテキストほどではありません。

Fig150

次の例はVMware環境のための管理クラスタのものです。ここにはvCenter、vCenterデータベース、VMwareの管理ツール、Microsoft AD、DNS、そしてSQLサーバやPostgreSQLデータベースのような他のシステムのバックアップコピーがおかれています。

Fig151

既に圧縮されているバイナリデータが多くあり、上記の結果となります。データ削減の効果としてはわずかです。

では、実際に本稼働しているExchangeシステムの環境ではどうでしょうか? ここにはExchange環境をNutanixで運用されているお客様の例を持ってきました。20,000以上のメールボックスの環境です。あらゆるタイプのメールデータが含まれています。

Fig152

eメールのデータと言うものは環境によっては他の環境と全く異なるデータになりがちです。ここには別のeメールのサンプルがありますが、今回はEnronのEmailデータベースのデータになります。Enronは上場倒産をしてしまった会社で、その後、負のバランスシート遺産や借金を抱えていました。eメールデータベースは裁判所の処理のために公開されることになったのです。ですから、データ削減技術のためのテストにはまたとないデータです。

Fig153

今回は圧縮を利用しています。圧縮はデータに共通部分が見つからないようなデータの場合には良い選択です。しかし、重複排除、圧縮、そしてイレイジャーコーディングのような他の削減技術を同時に利用して、できうる最高の削減率を得ることも出来ます。そもそもプラットフォームは実際のデータを下にして、最高の技術を提供すべきです。

VDI環境を含む特定のタイプのワークロードはフルクローンでも、リンククローンでもいずれの場合も重複排除から非常に良いデータ削減結果を得ることが出来ます。フルクローンの環境ではほとんどすべてのデータを重複排除できるため、重複排除で最高の削減結果を得ることが出来ます。重複排除と圧縮の療法を使って、可能な限りのデータの削減を行うことも出来ます。しかし、ここでは2つのVDI環境の例を挙げましょう。

Fig154

Fig155

上の2つの例は2つの異なるVDI環境で少しだけ異なるワークロードを動作させた結果の例です。しかし、圧縮と重複排除の技術の組み合わせによって、非常に大きな削減を実現していることがわかります。ですが、これらの環境は殆どがリンククローンの環境です。フルクローンのデスクトップではないのです。以下にフルクローンのVDIの環境における重複排除でのデータ削減の結果を示します:

Fig156見て明らかな通り、別々のワークロードのデータでの共通事項がほとんどであれば、極端なほどのデータ削減率を期待することが出来、こうしたワークロードのための物理的なスペースは非常に小さくて済むのです。

今までのところ、さほど異なるタイプのワークロードをのみしかカバーできていませんし、比較的小さな規模のものです。では、大きな環境へとスケールアップして、更にエンタープライズで利用されるようなタイプのワークロードになるとどうでしょうか?

Fig157

上のイメージは10ホスト、70台の大きい仮想マシンを運用しているやや大きな環境からのもので、大きなIOを多く行っています。この例では、削減されたデータサイズは175TBです。ですが、私はこれ以上の値も実現出来ると考えています。さぁ、もうちょっとだけ大きな本か同環境を見ていきましょう。

Fig158

上の例はSQLサーバとアーカイブデータを含む混在ワークロード環境となっている大きなNutanixからの例です。今回は全体としてのデータ削減は570TBです。

Fig159

上の2つのサンプルはそれぞれ32ノードのNutanixからなる2つのクラスタの例です。ワークロードは一般的なサーバ仮想化で、一方はマイクロソフトのアプリケーション、もう一方ではLinuxベースのアプリケーションが動作しています。

Fig160

上の例はLenovo HXアプライアンスで動作している4台のオールフラッシュノードからなるクラスタものです。データはOracleとSQLサーバデータベース、それから僅かなVDIデスクトップの混在環境です。

Fig161

上のイメージは26ノードのハイブリッドクラスタで様々なノードが混在しており、20TB以上のデータベースと他のアプリケーションがまたがったものです。

終わりに

オールフラッシュはデータ削減に必要不可欠なものではありません。上で見てきたように、大きなデータ削減とそれなりのパフォーマンスを得るためにオールフラッシュを使う必要はないのです。ハイブリッドストレージ環境でも優れた削減効果を得ることが出来ますし、オールフラッシュにしたいということであれば、そこでも同じような優れたデータ削減効果を得ることが出来ます。ですが、ハイブリッド化、オールフラッシュか、という事を決めるのはあなた自身です。いずれのタイプの環境でも同じ削減効果を得ることが出来ます。理由はこれは保存されているデータそのもので決まるからです。

特殊なハードウェアを用いなければ優れた削減効果とパフォーマンスを彫らないとうこともありません。上のすべての結果はソフトウェアのみで得られる結果で、特殊なハードウェアは必要としません。パフォーマンスと削減効果はデータのタイプに依存します。パブリッククラウドは特殊なハードウェアには依存しません、どうしてプライベートクラウドでだけ、それが必要なのでしょうか?

データ削減結果をきめるもっとも大きな要素は保存されているデータのタイプです。もちろん、データ削減の技術はベンダー毎に異なります、ですが、もっともデータ削減効果を決める最も大きな要素は保存されているデータのタイプです。スナップショットを利用してそうでもないのにそれを重複排除であると呼ぶようなおかしな比較はスルーして下さい。暗号化されたデータ、画像のような既に圧縮されているデータのような上手く削減ができないデータのタイプであればとても貧相な結果になってしまいます。同じOSや同じアプリケーション、ドキュメントとして保存されているデータ、テキストやデータベースのようなテキストタイプの削減のよく効くデータでは非常に優れた結果を得ることが出来ます。この結果から、システムは複数のデータ削減施術を利用できるということが重要な事になります。これによって実際に存在するデータに対して最高の削減効果を得ることが出来るからです。

圧縮が有効になっている場合、幾つかのベンチマークテストでは正しい結果が得られない場合があります。圧縮や重複排除をオフにすることが出来ないシステムの場合、Exchange JetStressのようなタイプのベンチマークテストでは正しい結果を得ることが出来ません。これはこうした結果を本稼働環境を選定する際には利用ができないということです。

スナップショットとクローンは上の結果には含めていません!スナップショットとクローンはメタデータ操作のみを利用し、データを増加させることはありません、ですから、データ削減の結果には含めておらず、Nutanixのプラットフォームではレポートしません。こうした操作では新しいデータを新しいWriteを受信するまではストレージの利用を増やすことはありません。ですから、いくらでもクローンやスナップショットを好きなだけ作ることが出来ますし、利用可能なストレージ容量に影響はありません。他のベンダーはデータ削減にこうしたデータを含めるという選択をしていることが有ります、しかしNutanixは実際のデータパターンに対しての現実の圧縮またはデータ重複排除の結果のみをレポートしています。

これらを全て加味してみてください。データ削減は保存しているデータ以外の何物にも依存しません。これによってご自身の環境での結果は様々になります。現実環境のデータと現実のワークロードで事前に検証をしてみる事をオススメ致します。そうでなければご自身の環境、ワークロードでの実際の削減効果を知ることは出来ません。記事内で匿名でイメージを送ってくださり、記事内での利用を許可してくださったお客様に大変感謝致します。

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

Ntc2017_2

本記事は実は、これから翻訳しようとしている記事からも引用されているのと、いよいよオールフラッシュの時代が到来しようとしている今だからこそ、読んでいただきたい内容です。オールフラッシュだから「重複排除や圧縮をやってもパフォーマンス的にOK!」という理論はこれは一見その通りに見えるのですが、実は非常に危険な誤解をはらんでいます。

上で述べられているとおり、削減効果はデータ次第なのですから、「オールフラッシュだから」というのはまったくもってナンセンスなのです。仮想マシンのためのIO(フロントエンド)さえ処理できてしまえば、後から遅延実行可能な重複排除や圧縮をおこなえますし、遅延実行しなくてはならないタスクが増えてきた場合でも、Nutanixのような分散アーキテクチャであれば、忙しいノードとは別のノードがその処理を行えばよいのです。(RF-2で冗長化している場合でも、データは仮想マシンが稼働しているホスト以外のノードにも必ず存在しますので、フロントエンド処理とバックエンド処理を分散できます。)

オールフラッシュなら重複排除や圧縮も可能! というのは何でもかんでも単一筐体の中で処理をしている従来型SANの理論で、逆を返すとオールフラッシュでないと重複排除や圧縮が間に合わない、ということになります。

どうでしょう? 実は、この話はPernixDataのストレージの「パフォーマンス」と「キャパシティ」と「データサービス」を分離すべきであるという思想と完全に一致します。しばらくオールフラッシュ系の翻訳を続けます。次回も乞うご期待!

2017/01/05

Nutanix関連記事まとめ

Nutanix関連記事が多くなってまいりましたので、まとめページを作成いたしました。

Nutanixの技術を知りたいといえば、まずここです。

翻訳をさせていただいている元記事のブログはこちら。

当社のNutanixチームのTwitterも是非フォローください!


Andre Leibovici氏のBeyond Marketingシリーズ和訳


Salle Designより: Nutanixの事例 ~Nutanix Prismが生まれるまで~シリーズ


知っておくべき10つの事シリーズ


エンタープライズクラウドソリューション


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


ファイルサービス関連


ネットワールドSEによるやってみた! シリーズ


.NEXTカンファレンスレポート


PernixData関連


その他

2016/12/28

NetBackupで仮想マシンの瞬間リカバリ!

はじめまして、宮内と申します。
普段は主にバックアップ製品を担当しています。以後お見知りおきを!

初めてのブログでご紹介するのはVeritas NetBackup
もともと高性能で有名なバックアップソフトウェアですが、最近はアプライアンスの新バージョン登場、ソフトウェア でも12月に新バージョン登場、と注目度が更にうなぎのぼり!(と思います)
こちらのブログでも、重複排除とアクセラレータ、 クラウド連携( API編クラウドゲートウェイ編 )、 SelfService など、過去に何度かホットな機能の紹介をさせていただいていますね。
一方で、便利なのに認知度の低い機能もちらほら。。
そこで!私からは、ちょっとニッチな便利機能を紹介したいと思います。

前置きが長くなりましたが、今回はインスタントリカバリ機能をご紹介します!

インスタントリカバリ(略称IR)とは:
バックアップデータを直接ESXiにマウントして仮想マシンを即座に起動させる機能

こんなイメージです↓

1

バックアップデータをESXiのデータストアに移動させることなく仮想マシンファイルを読み出すので、普通のリカバリよりも迅速に復旧できます。

IRは、以前のバージョンから搭載はされていたのですが、コマンドでしか操作できず、(GUIしか使えない初心者の私にとっては)ハードルの高いものでした。
NetBackup 7.7からはvSphere Web ClientからGUI操作でできるようになり使いやすくなったので、胸を張って紹介できます!
※8.0から搭載されたInstantRecovery for Hyper-Vは従来通りCLI操作です。

インスタントリカバリが使えるようになるまでの道のりはこちら↓

2 もうちょっと設定手順が簡単だといいんですが。。贅沢は言わない。

Webサーバーは既存のものがあればプラグインのインストールのためだけに作成しなくても大丈夫です。

それではインスタントリカバリをしていきましょう!
せっかくなのでNetBackupのプラグインは最新バージョンの 8.0 を入れてみました!!
※スクリーンショットには開発段階のものを含みます。


vSphere Web Client からのIRの流れはこちら↓

3

プラグインを入れた状態でvSphere Web Clientを起動します↓

4 赤いマークが目印です。

5つ並んだボタンの中から「Instant Recovery Wizard」を選んでリカバリ開始↓

5 あ、もちろんですが、リカバリの前に仮想マシンのバックアップはしておいてくださいね!

リカバリしたい仮想マシンを選びます↓

6 右下の"Add Virtual Machines"をクリックします。
左上に現在選んでいる仮想マシンの台数が表示されます。

リカバリするデータとか場所とか名前とか設定します↓

7

8

9

リカバリ前にはチェックが必要です↓

10 チェックが済んだらインスタントリカバリ実行!

すぐに起動してきました!↓

11 今回はIRしたマシンに「○○-irv」と名前をつけています。

12 こちらはNetBackupの管理画面。
今回は2分弱で2台の仮想マシンが起動したことが確認できます。

1台目は約30秒でリカバリできました。ちなみに、同じ仮想マシンを通常のリストアで復旧させたら、1台で約26分かかりました。
IRによって、リカバリ時間が1台あたり約25分の1まで短縮できましたね!
※本検証環境における参考値です。短縮できる時間は環境によって異なることがあります。

なお、NFSがうまく動作していないとリカバリに失敗することがあります。
リカバリ失敗時にNetBackupサーバーではステータスコード「5」が、Web-Clientのタスクでは「無効なデバイスです」といったメッセージがそれぞれ表示されていたら、NFSの不調を疑いましょう。
そんなときはバックアップサーバーで以下のコマンドを実行し、NFSの再起動を行ってみてください。

さて、IRは一時的にバックアップデータをマウントしており、起動した仮想マシンも一時的に使用することを前提としています。
そのため、このままではNetBackupのジョブが終了にならないので、必ずIRの終了処理が必要になります。

13 緑の走っている人のアイコンはジョブが実行中であることを示しています。

IRの終了処理には以下の2つがあります。

  • 仮想マシンを使い続ける:Initiate Instant Recovery Done
  • 仮想マシンを削除する:Deactive

"Initiate~"はvMotionで仮想マシンファイルをESXiのデータストアに移動させていないと選択できないので注意です。

終了処理はInstant Recovery Cleanupボタンから↓

14

ポップアップウィンドウの上部から仮想マシンへの処理を選択します↓

15 今回はvMotionを実行していないため、2台とも"Deactive"処理を行います。

16 リストに仮想マシンが表示されなくなったら全ての仮想マシンに対して処理が完了したサインです。

NetBackupの管理画面でも全てのアイコンが青色(ジョブ終了のマーク)になりました↓

17


以上でインスタントリカバリの操作は一通り終了です。いかがでしたか?

最後に、流れの中で紹介しきれなかったものも含め、インスタントリカバリのメリット・デメリットを書いて終わりにしようと思います。

メリット

  • とにかく仮想マシンの起動が早い
  • 一度に複数台の仮想マシンをリカバリできる(通常のリカバリは1台ずつ)
  • VM管理者(バックアップ管理者以外)がvSphere Web Clientからリストアできる

デメリット

  • インスタントリカバリが使えるようになるまでの設定が面倒
  • 復旧時の設定は通常のリカバリに比べて指定できる項目が少ない

ありがとうございました!皆様良いお年を!

宮内

Nutanix Acropolis ファイルサービスについて知っておくべき10つの事

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のProduct Marketing Managerを務めるShubhika Taneja氏によるものです。原文を参照したい方はTen Things you need to know about Nutanix Acropolis File Servicesをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

我々はすばらしい機能それぞれについて、将来のリリースで含まれる機能をご紹介する新しいブログシリーズ「10つの知っておくべき事」をスタートします。以前のリリースで、この将来のリリースの機能の登場は多くの素晴らしい機能、例えばAcropolis ファイルサービス、セルフサービスポータル、ネットワーク可視化、その他たくさんなど、は予告されていたものです。ではまずAcropolis ファイルサービス(AFS - Acroplis File Service)についての10つの知っておくべき事から初めましょう:

  1. AFSを利用すれば別途ネットワーク接続ストレージ(NAS)アプライアンスを用意する必要はなくなります。AFSはソフトウェア定義のスケールアウト型ファイルストレージソリューションでSMB/CIFSの幅広いユースケースをカバーできるように設計されており、Windowsユーザープロファイルの格納や、ホームディレクトリ、組織間での共有を実現できます。あらゆるAVHまたはESXiのクラスタ上で有効にすることが出来、Nutanixの管理ソリューションであるPrismから2,3回クリックするだけで利用することが出来ます。
  2. AFSは完全にNutanixのエンタープライズクラウドプラットフォームのコアコンポーネントと統合されています。既存のクラスター上に展開すること、スタンドアローンのクラスタに展開することの療法が可能です。スタンドアローンのNASアプライアンスとは異なり、AFSは仮想マシンとファイルストレージを統合することが出来るため、別々のインフラストラクチャのサイロを作る必要はなくなります。AFSも仮想マシンサービスと同様にNutanix Prismから管理を行うことが出来るため、管理の統合、簡素化を実現します。
  3. AFSはそれを支えるNutanixエンタープライズクラウドプラットフォームからインテリジェントな階層化、重複排除、イレイジャーコーディング、圧縮、そして分散化による自己治癒などの優れたエンタープライズストレージの機能を継承しています。
  4. AFSは最低で3台のファイルサーバ仮想マシンを必要とし、それぞれのファイルサーバ仮想マシンは最低 4 vCPU、12GBのメモリを必要とします。AFSクラスタのパフォーマンスは簡単にスケールアップ(vCPUとメモリをさらにファイルサーバ仮想マシンへ追加する)またはスケールアウト(ファイルサーバ仮想マシンを更に追加する)によって、改善することが出来ます。
  5. AFSはSMBをサポートし、Active Directoryと連携して動作します。
  6. AFSはユーザーと共有のクオータをサポートします。
  7. AFSはアクセスベースのイニューメレーション(Access Based Enumeration - ABE)をサポートします。
  8. AFSはWindowsの以前のヴァージョンの復元をサポートしており、ユーザーによるセルフサービスでの復元を実現します。
  9. 共有領域の3rd パーティによるバックアップについてはCommvault社などのベンダーから提供される従来からのファイルバックアップを利用することが出来ます。バックアップは別のNutanixクラスタまたは、パブリッククラウド(AWSとAzure)に対して行うことも出来ます。
  10. AFSでは別のNutanixクラスタへの統合された自動災害復旧を利用することが出来ます。

Fig148

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

さて、ネットワールドらぼではNutanixコミュニティではじまった「10つの知っておくべきこと」シリーズの翻訳を行っていきます。まずはAFS。これ自体はファイルサーバの機能を提供するだけ(もちろん、Nutanix流にスケールアウトしますので、サーバ1台単位でのPay-as-you-growなのは魅力です!)なのですが、素晴らしいのはNutanixクラスタ内に共存させることが出来るということです。仮想マシン用のストレージとファイルサーバストレージ、ほとんど似たような(もしくはユニファイドで同じ筐体にすることもあるでしょうが・・・)ソリューションを別々に管理したいとは誰も思っていないはずです。Nutanixではこれに加えて更に仮想環境の管理も統合することが出来ますので、社内のITインフラの管理をあの優れたPrismだけで行うことが出来てしまうのです。

今後も様々なSMB/CIFSのユースケースに対応するようなロードマップがひかれているようですので、今後ファイルサーバ専用機はなくなっていく、、、正にWikibonのServer-SANについての予測を象徴するような機能についての10つの知っておくべきことでした。

2016/12/23

NutanixでのVDI/SBCサイジングの実践

こんにちは、ネットワールドの海野です。

Nutanix Advent Calendarということで、 ネットワールドらぼ には初めての投稿です。

今回の記事ではNutanix環境におけるVDIとSBCについて、実践的なサイジングへのアプローチをご紹介しようと思います。

※注1 : NutanixのSizerは定期的にアップデートが行われ、画面や設定内容が変更や調整されます。ご利用時点の最新版とは異なる可能性がございますので、ご了承ください。

※注2 : ここでご紹介する構成やスペック値はサンプルとしてご提供する情報であり、何らかの保証を行うものではございませんので、ご了承ください。

自己紹介

ネットワールド入社当初からCitrixの製品を担当しており、ふだんはXenDesktop(VDI)/XenApp(SBC)のプリセールスSEとしてお問い合わせ対応や構築作業のほか、トラブルシューティングに関するご相談を受けたり、当社で開催しているセミナーや無償ハンズオントレーニングの講師をしています。

よくいただくご相談 : サイジング

その中でよくご相談をいただくのが「XenApp/XenDesktopの推奨スペックとハードウェア構成を教えてください!」というものです。

いわゆるサイジングのお話です。

今年のNutanix Advent CalendarではNutanix島崎さんがSizerに関する記事を寄稿されていますが、このSizerを利用することで複雑と思われがちなVDIやSBCのサイジングや機器選定という課題をシンプルかつスマートに解決することができます。

基本的なSizerの概要や使い方については島崎さんの記事をご覧ください。

Sizerを使ったサイジングの前に…! 要件を整理しましょう

サイジングと機器選定というゴールに向かうためには要件の整理が必要です。

まずは要件を整理し、Sizerへのインプットに落とし込んでいく作業を行います。

私がご相談を受ける際にお客様へお伺いする主な内容としては、以下の項目が挙げられます。

・利用目的と利用形態

・想定負荷とユーザー数

・仮想マシンの展開方法

・冗長性

・接続元

今回のサイジングシナリオはこちら

というわけで、シナリオ(お客様のご要望)を以下のもので想定します。

・利用目的と利用形態 : テレワーク実現のためのXenDesktop(VDI)環境

・想定負荷とユーザー数 : Officeドキュメントの編集やブラウザー閲覧などの300ユーザー

・仮想マシンの展開方法 : Machine Creation Services (MCS)

・冗長性 : あり

・接続元 : テレワーク実現なので、社内以外に社外からも接続する

実践その1 : Sizerにどう入力していくか? (ユーザー用のリソース)

では、このシナリオをもとにSizerに入力していきます。

Sizerを起動し、シナリオの名前(SCENARIO NAME)を入力します。

ここでは「VDI for Telework 300 Users」としました。

01

まずはユーザーさんが業務で利用するためのVDIリソースをXenDesktopのワークロードとして追加します。

02

今回のシナリオでは「Officeドキュメントの編集やブラウザー閲覧など」という使い方を想定しています。

Sizerではその用途にピッタリの"Knowledge Worker"という選択肢がありますので、これが300ユーザー分という入力をします。

なお、ここではワークロードのカスタマイズなどは行わず、冗長性に関する内容もデフォルトのままで進めます。

03

すると、このような結果が表示されました。

今回のシナリオのVDIリソースを賄うには、このNutanixがよいという指針になります。

04

管理コンポーネントのリソースを追加する前に… (コンポーネントの整理と確認)

XenDesktopを利用するためには仮想デスクトップだけを用意すればよいというものではなく、さまざまな管理コンポーネントが必要です。

Sizerを利用して管理コンポーネントのリソースを追加していきましょう。

XenDesktopの管理コンポーネントとして代表的なものをここにピックアップします。

・Delivery Controller

・StoreFront

・SQL Server

・Citrix License Server

今回のシナリオでは、論理的な障害に備えて各コンポーネントを冗長化する方針とします。

さらに、可能な限りWindows Serverの台数を削減するべく、複数のコンポーネントを同居させる構成とします。

それを踏まえ、弊社の無償ハンズオントレーニングでは以下のサーバー構成案をご紹介しています。

・サーバー1 : Delivery Controller / StoreFront / Citrix License Serverを同居

・サーバー2 : Delivery Controller / StoreFront / ウィットネス用のSQL Expressを同居

・サーバー3 : ミラーリングされたSQL Server (プリンシパル)

・サーバー4 : ミラーリングされたSQL Server (ミラー)

では、この1~4のサーバーですがどれくらいのスペックでサイジングをすればよいでしょうか?

詳細は弊社の無償ハンズオントレーニングで解説しておりますが、それぞれ次のようなスペックが目安となります。

・サーバー1 : 4vCPU / メモリ8GB / ディスク100GB 以上

・サーバー2 : 4vCPU / メモリ8GB / ディスク100GB 以上 (サーバー1と同じ)

・サーバー3 : 2vCPU / メモリ4GB / ディスク100GB 以上

・サーバー4 : 2vCPU / メモリ4GB / ディスク100GB 以上 (サーバー3と同じ)

この情報を使ってワークロードを入力してみましょう。

※注3 : 上記のスペックはあくまで一例です。シトリックス社からはサイジングについて以下のホワイトペーパーが提供されていますので、こちらもご参考としてください。

Citrix VDI Best Practices for XenApp and XenDesktop 7.6 LTSR

実践その2 : 管理コンポーネント用のリソースを入力

ここでは入力をシンプルにするために、Workload Typeを「Server Virtualization」で進めます。

ワークロードの名前は「Management Resource」としました。

05

先ほど紹介したスペックの目安を満たすために、Server Profileは「Large」を選択します。

Server Profileについては島崎さんの記事に解説があります。

06

また、ここでもワークロードのカスタマイズなどは行わず、冗長性に関する内容もデフォルトのままで進めますと、入力した結果が反映された内容が表示されます。

07

実践その3 : NetScaler Gateway VPXのリソースを入力

社内でXenDesktopを利用する分には以上の内容で十分ですが、今回の想定シナリオは「テレワーク実現のためのVDI」ということで、社外から社内への接続を実現する仮想アプライアンスであるNetScaler Gateway VPX(以下、NS VPX)のリソースを追加していきます。

なお、NS VPXを利用する場合、ユーザーデバイスに対し画面転送データのみをやり取りするためファイルが手元の端末に残らないような使い方ができるなど、一般的なVPNと比較して非常にセキュアであるということが強力なメリットとして挙げられます。

ここでは、NS VPXのワークロードもServer Virtualizationで入力します。

08

NS VPX バージョン11.1のデフォルトの仮想マシンスペックは、Server Profile : Mediumで満たすことができます。

また、XenDesktop管理コンポーネントと同様に冗長化を考慮して、2台のNS VPXを配置します。

09

最終的なXenDesktop環境のサイジング結果

Sizing Summaryはこのようになりました。

リソースの使用率は上がりましたが、変わらず4ノード構成でOKという結果が表示されました。

検討に必要な材料(要件)があれば、とてもカンタンにサイジングと機器選定ができるということがお分かりいただけるかと思います。

10

XenAppはどうする?ユーザー数の変更はどうする? : シナリオのクローン

Sizerではシナリオのクローン機能を使うことで、簡単にいろいろなパターンを検討することができます。

いま作成したシナリオをそのままXenAppでの300ユーザー構成に置き換えてみましょう。

まず、作成したシナリオのクローンを行います。

ここでは「XenApp for Telework 300 Users」としました。

11

既存のWorkloadsからVDI用に設定した「User Resource」を削除し、新たに「XenApp Resource」を作成します。

Workload Typeは「RDSH/XenApp」を選択します。

12

Windows Server 2012 R2上で動作するXenAppの想定で入力を進めます。

13

ここではサンプルとして以下の値を入力しました。

なお、ドキュメントを編集するユーザーを想定していますので、ユーザープロファイルなどは大きめに見積もっています。

14

そのままデフォルト設定を前提とすると、数クリックでサイジングの結果が出力されます。

15

その他、ユーザー数の変更であれば同様にシナリオをクローンし、ユーザー数を調整するだけでサイジングを行うことが可能です。

まとめ

Sizerを使えばとてもカンタンに複数のサイジングや機器選定のプランニングをすることができます。

XenDesktopやXenAppの基盤をNutanixでご提案いただき、スピード感のあるサイジングと機器選定を試していただければと思います。

 

しかしながら、どのコンポーネントをどういったスペックで組むかというのは、ノウハウや経験が必要な部分であり、難しく感じている方もいらっしゃるのが実情かと思います。

当社では定期的にXenApp/XenDesktop/NetScalerの無償ハンズオントレーニングを実施しており、当社の経験に基づく最新情報をご提供しております。

さらにNutanixについてもイベントを開催しておりますので、今後も当社のイベントにもご期待いただければと思います。

2016/12/21

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

本記事はNutanix Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

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

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

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

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

すでに東京での開催は終了していますが、大阪での開催もございます!

これは本シリーズの4番目の記事です。最初の記事はこちら2つ目3つ目

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

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

以下はこのブログ記事でご紹介してきた機能です:

  • 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への認定
  • Prism サーチの改善(ブール表現のサポート)
  • I/O メトリクスの可視化
  • 1-クリックライセンシング
  • LCM – Lifecycle Manager(ライフサイクルマネージャー)
  • 追加のPrismの改善点
  • AHVの拡張性の改善
  • AHVのCPUとメモリのホットアド(Tech Preview)
  • コールドデータのアドバンスドコンプレッション
  • バックアップベンダーのためのAcropolis チェンジブロックトラッキング(CBT) 
  • 自発的なQoSによる期待通りのパフォーマンス
  • NCC 3.0 の Prism への統合
  • 1-ノード レプリケーションターゲット
  • QoSによる混在したワークロードのサポートの改善
  • SATADOMの交換ワークフローのシンプル化
  • 適応型レプリカ選定によるノード混在のサポート
  • 動的なイレイジャーコーディングのストライプの縮小 - ノードの削除時
  • メタデータ用のノード上の利用可能な複数のSSDをメタデータディスクとしてサポート
  • コンテナにおけるイレイジャーコーディング(EC)のレプリケーションファクタ(RF)の変更のサポート
  • OpLogのインライン圧縮
  • (New) Linux カーネルアップグレード

私はNutanix 5.0の新機能についてのアナウンスは全て終えたと思っていましたが、読者のうちの一人 Tom Hardy氏がAHVのLinuxカーネルアップグレードについて紹介し忘れているよ!と教えてくれました。間違いを犯したときに喜んでサポートしてくれたり、注意をしてくれる素晴らしい読者がいるのはありがたいことです。Tomさんありがとう! 

Linux カーネルのアップグレード

NutanixのAHV(またの名をAcropolisハイパーバイザ) はLinux カーネルをヴァージョン4.4.22へとアップグレードしました(現在のLinuxカーネルは2.6.1です 更新:これは間違いでした、現在AHVのLinuxカーネルは3.10.0-229.26.2でした)。Linux 4.4の全ての新しい機能と改善点はこちらをご参照ください。このリリースの素晴らしい機能はもちろん、様々なバグやセキュリティの修正がKVM、QEMU、そしてlibvirtへと含まれています。

Fig146

カーネルについてのヴァージョン3.10.0とヴァージョン4.4.22の間すべての変更についてはこちら。ですが、AHVの一部としてすべての機能を取り込んでいるわけではなく、NutanixはNutanixソリューションに必要な部分のモジュールのみを取り込んでいます。これは小さく固めることで、攻撃対象ととなりうる部分を減らし、ソリューションとしてより安定、よりセキュアにするためです。

個人的に、カーネルのアップグレードに付随して重要になると考えている幾つかの改善点を取り上げます。 

仮想GPUドライバーによる3Dのサポート

virtio-gpuは仮想化ゲストのためのドライバーで、ホストに搭載されたグラフィックスカードを効率的に利用できるようにするためのものです。今回のリリースでは仮想化ゲストがホストのCPUを3Dのレンダリングの高速化に利用できるようにする機能が含まれています。実際のところ、これは仮想化されたLinuxのゲストOSがOpenGLのゲームをホストのGPU高速化機能を使って動作させる事ができるようにする、というもので、こちらや tこちら でビデオを見ることが出来ます。 (重要 – GPUによる高速化はAOS 5.0ではまだサポートされていません、しかしこのアップグレードによってAHVは今後のサポートのための足がかりを作ることになります。

ヒュージ(巨大)ページのサポート (または ラージページのサポート)

ヒュージページはLinuxカーネルが近年のハードウェアアーキテクチャにおける複数のサイズのページを取り扱うことが出来るようにするメカニズムです。ヒュージページはオペレーティングシステムが標準(大抵の場合4KB)よりも大きなページのメモリをサポート出来るようにします。非常に大きなサイズのページを利用することで、システムリソースの総量を減らし、システムのパフォーマンスを向上させることが出来ます。

ヒュージページは32ビットでも64ビットの構成でも有効です。ヒュージページのサイズは2MBから256MBまで、カーネルのヴァージョンとハードウェアのアーキテクチャに合わせて変更することが出来ます。

One more thing!

ここで親愛なるPlexxiと共に作り上げた素晴らしいソリューションをご紹介したいと思います。Plexxiは自身のファブリックの利用率をNutanix Prismへ統合しまし、Prismを根本的にデータセンタ全体に渡るコンピューティング、ストレージ、そしてネットワークファブリックの単一コンソールにしてくれました。これは実際に非常に賢く、とても優れています。今後テクノロジーパートナーが新しいNutanixのヴァージョン3.0 APIを利用してもっと面白いソリューションが出てくることを期待しています。

Fig147_4

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

Part 3で終わりと思いきや、Part 4があるという。。。Nutanixの機能は底なしです!今回はLinuxカーネルについてのアップグレードですが、ラージページ、GPUなどオープンソースからの恩恵でどんどん良くなっていきますね。GPUについては現在はESXiしか選択肢がありませんが、XenServer、行く行くはAHVでも利用ができるようになりそうです。また、最後のソリューションのPlexxi、ウィーンの展示会場でも見てきましたが、なかなか面白いですね。もともとGoogleのために作っていた、ということでした。何よりPrismがプラットフォームとして他社の製品情報を表示するようになってきていますので、今後はこの美しいインターフェイスだけみていれば良くなる・・・と嬉しいなぁ。プラットフォーム連携しても統一感のあるインターフェイス、ユーザビリティを実現するのは難しいと思いますが、是非頑張ってほしい。

2016/12/20

VMware ESXi - 仮想化環境内のI/Oブロックサイズ

本記事はvExperts Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

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

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

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

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

この記事は仮想化環境内のI/Oサイズまたはブロックサイズに関するものです。これに会いたいする際にはデータベースや他のシステムへの対応のため、ということがほとんどでしょう。Microsoft SQLデータベースを利用する際には64KBでフォーマットされているヴォリュームを利用するか、NTFSにそのように割当を行うのがベストだということはよく知られていますが、これにストレージシステムまで考慮に入れているでしょうか?まだMicrosoft SQLサーバは64KBのブロックのみで操作を行っているとまだ信じているのであれば、これは間違いでです。実際にはSQLデータベースが何を行っているかによって様々なサイズのブロックが生成されています。I/OサイズとNTFSの割り当てサイズ、VMFSブロックサイズ、NFSブロックサイズの間には明確な誤解が有ります。ヴォリュームに関連付けられたそれを支えるストレージシステムはその更に下の物理ディスクやフラッシュを抽象化した構造になっています。このブロクの記事はこの部分に少しだけでも光を当てたいと思っています。以下の図は64KiBのWrite I/Oが仮想化環境の異なるレベルをどのように流れていくのかを示したものです。

Fig145

図1: I/Oのワークフロー

セクタとクラスタ

Windows NTFSファイルシステムに入る前に、セクタとクラスタを理解しておくことが重要です。セクタは物理ストレージのディスク上のもっとも小さな単位です。標準的なセクタのサイズは512バイトで、ハードディスクドライブの登場から利用されています。市場には4096バイトのセクタをもつドライブも有りますが、それでもほとんどのすべての回転ディスクはセクタのサイズとして512バイトを利用しています。

ディスクデータ構造のオーバーヘッドを取り除くため、ディスク上の継続したセクタのグループをクラスタと呼ぶという概念が導入されました。クラスタはファイルやディレクトリのためのディスク割り当ての単位で、アロケーションユニットとも呼ばれています。論理的には4 KiB(4096バイト)のクラスタには8つのセクタ(8 x 512バイト)が含まれています。

フラッシュデバイスはセクタに良く似たページ(サイズは8KiB)でグループ化されており、さらに物理ディスクの世界のプラッターやスピンドルの代わりにブロックやプレーンでグループ化されています。この後方互換性はフラッシュにFlash Translation Layer(FTL - フラッシュ翻訳レイヤ)という名前で組み込まれており、physical page number(PPN - 物理ページ番号)へとLogical Block Address(LBA - 論理ブロックアドレス)を変換されています。ブロックは通常2MiBのデータを格納しており、256 x 8 KiBのページからなっています。

Windows NTFS

WindowsファイルシステムのNTFSはその下のハードディスクのクラスタサイズ、つまり「アロケーションユニットサイズ」に関連付けられています。クラスタサイズの大きさはファイルが利用できるもっとも小さな領域となっています。標準のサイズは4KiBで、アロケーションユニットサイズはディスクフォーマット時に 512、1024、4096、8192、16384、32768、65536バイトで構成することが出来ます。この リンク をクリックしてマイクロソフトが標準のクラスタサイズについてどのように推奨しているかを確認することが出来ます。最後の3つの選択肢は 16K、32K、64Kとして表されていますが、これはKibibyteを簡略化して記載したものですから16Kは実際には16K(16,000)ではなく、16384バイトもしくは16KiB(2^14)であることに注意してください。アプリケーションが非常に小さな512バイトのファイルを継続的に書き込んでいるという例を見てみましょう。結果としてNTFSファイルシステムの容量は無駄になってしまいます。10,000のファイルがあり、ディスクが512バイトと4KiBのアロケーションユニットで作成されている場合を例に取ります。

  • 10,000 x 512 バイトのファイル =  5,120 KiB のスペース利用 / 4 KiBのアロケーションユニットサイズの場合、40,960KiBが利用される
  • 10,000 x 4 KiB のファイル = 40,960 KiB のスペース利用 / 4KiBのアロケーションユニットサイズの場合、40,960 KiB が利用される
最初の例では、たったの5,120 KiBのデータに40,960KiBが利用されます。これは単に4KiBのアロケーションユニットサイズであるからという理由で、2つ目の例ではファイルサイズが4KiBなので完全に一致します。
パフォーマンスの観点からは、回転するディスクは例えばデータベースなどが殆どの場合において64KiBのI/Oを行っており、アロケーションユニットサイズを64KiBに設定している場合には1つのブロックが1つのクラスタに合致するため、単一の64KiBのI/Oを多くの小さなクラスタに分散して処理する必要が無いために、メリットを得ることが可能です。また、メタデータについても効率がよくなり、オーバーヘッドが小さくなります。フラッシュデバイスの場合、パフォーマンスのペナルティを受けることはありません。アロケーションユニットサイズは4KiBですが、大きなファイルを利用するシステムではメタデータの総量はもっと大きくなります。一般的に、フラッシュではパフォーマンスの違いはさほど大きくなりません。私がお話をしてきたほとんどのお客様は標準のアロケーションユニットサイズを利用していました。私自身も出来る限り標準のままにしておくほうが良いと思っています。個人的な意見ですが、特別な理由がない限りアロケーションユニットサイズは4 KiBのままのほうが良いです。ご自身のヴォリュームのシリアル番号、セクター数、アロケーションユニットサイズなどを知りたい場合にはWindows Server上でfsutilを利用すれば以下のように表示されます:
C:\Windows\system32>fsutil fsinfo ntfsinfo c:
NTFS Volume Serial Number :       0x7498f02e98efed14
NTFS Version   :                  3.1
LFS Version    :                  2.0
Number Sectors :                  0x000000000634f7ff
Total Clusters :                  0x0000000000c69eff
Free Clusters  :                  0x000000000001dae3
Total Reserved :                  0x0000000000000fe0
Bytes Per Sector  :               512
Bytes Per Physical Sector :       512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0x0000000015fc0000
Mft Start Lcn  :                  0x00000000000c0000
Mft2 Start Lcn :                  0x0000000000000002
Mft Zone Start :                  0x00000000004f2340
Mft Zone End   :                  0x00000000004f2b40
Resource Manager Identifier :     BC106797-18B8-11E4-A61C-E413A45A8CC7

VMFS

Virtual Machine File System(VMFS - 仮想マシンファイルシステム)は仮想マシンをブロックストレージ上に格納できる高度な拡張が可能なシンメトリックなクラスタファイルシステムです。VMFSはSCSIコントローラを利用したDAS(Direct Attached Storage)と、サーバ内のディスク、またはiSCSI(Internet Small Compuer System Interface)、FC(Fibre Channel)そして、FCoE(Fibre Channel over Ethernet)のいずれもを利用する共有ブロックストレージでサポートされています。VMFSを更に深く知りたいと思った場合にはこのリンクの先のSatyam Vaghani氏(VMwareの元CTOであり、PernixDataの元CTO)の論文をご参照ください(VMFS-3をベースにしていますが、基本的には現在も同様です)。ESXi 5.0で導入されたVMFS-5とVMFS-3がどう違うのかという詳細には触れません。すべての人がVMFS-3からVMFS-5へアップグレードしていないとはわかっていますが、もしもアップグレードしていないのであれば、是非アップグレードしてください。これはVMFS-3には多くの制限があるからです。VMFS-3からのアップグレードですべての機能が利用できるわけではありませんが、殆どの重要なものは利用可能です。VMFS-3とVMFS-5の比較についてはVMwareのKB2003813をご参照ください。以下にVMFS-5の新しい機能の主なものをまとめておきます(ESXi 6.0での構成上の最大値はこちらにあります):

  • ブロックサイズの1 MiBへの統一。 以前のVMFS-3では1、2、4、または6MiBのブロックサイズを指定してヴォリュームの作成が可能でしたが、このブロックサイズによってVMDKの最大のサイズが決まっていました。
  • 大きな単一ヴォリューム。 VMFS-5は単一のVMFSファイルシステムとして64TiBをサポートしています(VMDKの最大サイズは 62TiB)。これは以前は2TiB(マイナス512バイト)でした。
  • より小さなサブブロック。 サブブロックは8KiBとなり、VMFS-3の64KiBと比べると、4,000から32,000までその数が増えています。
  • ファイルカウントの増加。 現行のVMFS-5では130,000ファイルがサポートされており、以前のVMFS-3の30,000と比べて大きく増加しています。
  • ATS の改善。 ATS (Atomic Test & Set)がVMFS-5に含まれており、これによってアトミックアルゴリズムによってロック機構が改善されています。ATS は VAAI (vSphere Storage APIs for Array Integration)の一部として含まれており、以前のVMFS-3のSCSI-2予約と比べて大きく改善されています。
上を見て明らかな通り、VMFS-5は1MiBのブロックを利用してファイルシステムを構成しており、そのサイズを変更することはできません。そして、VMDKの最大サイズは62TBです。1KiBよりもちいさい、メタデータなどを格納する非常に小さなファイルについてはファイルディスクリプタの場所(inodeとも呼ばれます)へ格納されます。サブブロックが1KiBの制限に達すると、最大で8KiBサイズのサブブロックが利用されます。8KiBのサイズが使われると1MiBの標準ブロックサイズへと移行が行われます。サブブロックの数は32,000(VMFS-3では4,000)までに制限されているということにはご注意ください。小さなファイルの例としては .VMSD.VMXF.VMX.NVRAM.LOGなどです。標準で1MiBであるから、ということによってVMDKについての多くの誤解であふれています。覚えておいていただきたいのはファイルシステム自身はファイルネームやファイルのタイプは問題にならず、単にサイズを見てファイルを適切に取り扱っているだけということです。当たり前ですが、ほとんどのVMDKにとってこれはファイルの作成時には行われますが、VMDK自身はflatファイルへのディスクリプタであるということを思い出してください。このファイルは1024バイトよりも大きなものになることはほとんどなく、このファイルの名前はVMDKのディスクリプタファイルですから、inodeに格納されるということは理にかなったことなのです。
ですから、順を追って説明すると:
  • 1024 バイト未満 = ファイルディスクリプタの場所(inode)
  • 1024 バイトより大きく、8192 バイト未満 = サブブロック
  • 8192 バイト以上 = 1 MiB のブロック

vmkfstoolsを利用して、ファイルとサブブロックがどのように利用されているかの他、様々な情報を得ることが出来ます :

~ # vmkfstools -Pv 10 /vmfs/volumes/<your_vmfs_volume_name>/
VMFS-5.60 file system spanning 1 partitions.
File system label (if any): <your_vmfs_volume_name>
Mode: public ATS-only
Capacity 805037932544 (767744 file blocks * 1048576), 468339130368 (446643 blocks) avail, max supported file size 69201586814976
Volume Creation Time: Mon Jun 22 16:38:25 2015
Files (max/free): 130000/129472
Ptr Blocks (max/free): 64512/64009
Sub Blocks (max/free): 32000/31668
Secondary Ptr Blocks (max/free): 256/256
File Blocks (overcommit/used/overcommit %): 0/321101/0
Ptr Blocks  (overcommit/used/overcommit %): 0/503/0
Sub Blocks  (overcommit/used/overcommit %): 0/332/0
Volume Metadata size: 807567360
UUID: 55883a01-dd413d6a-ccee-001b21857010
Logical device: 55883a00-77a0316d-8c4d-001b21857010
Partitions spanned (on "lvm"):
naa.6001405ee3d0593d61f4d3873da453d5:1
Is Native Snapshot Capable: YES
OBJLIB-LIB: ObjLib cleanup done.
WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0
findコマンドを利用することで、ファイルとディレクトリの数を知ることも出来ます:
  • 1024バイトより大きく、ファイルで8KiBより小さなファイル: ~ # find -size +1024c -size -8192c | wc -l
  • 1 Kibよりも小さなファイル: ~ # find -size -1024c | wc -l
  • ディレクトリ: ~ # find -type d | wc -l
vmkfstools -D(仮想マシンのディレクトリへ移動して)を利用して実際の個々のファイルのブロックサイズを調べることも出来ます(オーナーが0の並びとして表示されていることが有りますが、それはこのホストがそのファイルをロックしているという場合です)。以下では3つのファイル、vm-flat.vmdk(flat ディスク)、vm.ctk.vmdk(チェンジブロックトラッキング)、そしてvm.vmdk(ディスクリプタファイル)が表示されています。flatファイルは40GiBのサイズで、ctkファイルはおよそ2.6MiB、vmdkのディスクリプタファイルは608バイトです。様々な値を見ることが出来ますが、もっとも重要なものは"nb"であり、これは"New Block(新規ブロック)"という意味です。同様に"bs"はblock size(ブロックサイズ)という意味です。flatファイルは17425の新規ブロックと1MiBのブロックサイズ(おおよそ17425 x 1MiBが割り当て)、ctkファイルは3つの新規ブロックです(2621952 = 3 x 1MiB ブロックが割り当て)、そしてVMDKディスクリプタファイルは新規ブロックはありません。なぜ新しいブロックがないのか? それは1KiB未満の小さなファイルはinode自身を利用するからです。
~ # ls -lat *.vmdk*
-rw-------    1 root     root   42949672960 Nov  7 17:20 am1ifdc001-flat.vmdk
-rw-------    1 root     root       2621952 Nov  1 13:32 am1ifdc001-ctk.vmdk
-rw-------    1 root     root           608 Nov  1 13:32 am1ifdc001.vmdk
~ # vmkfstools -D am1ifdc001-flat.vmdk
Lock [type 10c00001 offset 189634560 v 45926, hb offset 3723264
gen 3447, mode 1, owner 5811dc4e-4f97b2d6-8112-001b21857010 mtime 282067
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 438, 131>, gen 45883, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 42949672960, nb 17425 tbz 0, cow 0, newSinceEpoch 17425, zla 3, bs 1048576
~ # vmkfstools -D am1ifdc001-ctk.vmdk
Lock [type 10c00001 offset 189646848 v 46049, hb offset 3723264
gen 3447, mode 1, owner 5811dc4e-4f97b2d6-8112-001b21857010 mtime 282071
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 438, 137>, gen 45888, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 2621952, nb 3 tbz 0, cow 0, newSinceEpoch 3, zla 1, bs 1048576
~ # vmkfstools -D am1ifdc001.vmdk
Lock [type 10c00001 offset 189636608 v 45998, hb offset 3723264
gen 3447, mode 0, owner 00000000-00000000-0000-000000000000 mtime 406842
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 438, 132>, gen 45884, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 608, nb 0 tbz 0, cow 0, newSinceEpoch 0, zla 4305, bs 8192
仮想マシンが行っているI/Oを理解しておくことは重要です。例えば、4KiBはVMFSファイルシステムのブロックサイズを反映しているものではありません。ファイルディスクリプタは固定長のデータアドレスを用いてデータブロックへアクセスします。ファイルサイズが増えるに従って、ファイルディスクリプタに含まれているものが変わっていき、ファイルディスクリプタはポインタブロックを利用して、間接アドレスを使ってアクセスを行います。それぞれのポインタブロックは4KiBのサイズで1024のアドレスを保持できますので、1 MiBのブロックサイズでは 1 GiBへ全体としてアクセス可能となります。VMFSファイルシステムを通り過ぎるとヴォリュームベースの構造と物理メディアへのアクセスが、本記事の最初の図1に記載されているとおりに行われます。この部分はすべてのストレージベンダーで異なっているため、ここでは詳細には取り上げません。

NFS

バックエンドのストレージへと仮想マシンのデータを格納するには様々な方法があります。NFSは定番の成熟した、高可用性を備えた高性能のストレージ実装です。コスト、パフォーマンス、そして管理の簡単さから非常に早くお客様に受け入れられるようになりました。VMFSと比較した際の機能についてもほとんど同等となり、機能がないためにNFSを利用しないということは殆どなくなっています。当たり前ですが、単一ESXiホストや単一ESXiクラスタ内でVMFSとNFSを一緒に使うということにも問題はありません。NFSは分散ファイルシステムプロトコルでもともとは1984年にSun Microsystemsによって開発されました。システムがネットワークを通じてストレージと接続することを非常に簡単に実現し、新たにFCベースのシステムのようにインフラストラクチャへ機材を追加すル必要もありません。vSphere 6.0では2つのヴァージョンのNFSがサポートされています。古いNFS 3とNFS 4.1です。しかし、殆どのお客様はNFS 3の機能がより完全てあるという理由からまだNFS 3を利用しています。NFS 4.1を使う理由はセキュリティ上の理由でしょう。ESXi内部のNFS ネットワークはレイヤ2のVLANを構成して利用されることが多く、外部から直接アクセスされる可能性はありません。これもNFS 3を使い続けるもう一つの理由です。この違いについては詳しくはこちらのVMware vSphere 6.0 ドキュメントセンターか、vmguru.comのNFSのベスト・プラクティスについての素晴らしい記事 をご参照ください。

ですが、この記事はブロックサイズとI/Oについての記事ですから、NFSベースのシステムのブロックサイズの話に切り替えましょう。VMFSとの違いはVMware自身がファイルシステムをフォーマットするのではないという点です。これはファイルシステムの実装自身がストレージベンダーによるもので、ブロックサイズはNFSサーバやNFS装置のもともとの実装によって異なってしまうからです。ブロックサイズ自身はVMFSと同じで、ゲスト仮想マシンへの依存もありません。これはVMDKが単にNFSサーバ/装置上の単独のファイルだからです。NFS上にはサブブロックもありません。VMFSと同様に、ブロックサイズについてはvmkfstoolsで知ることが出来ます。以下に見るようにNFSサーバは4KiBのブロックサイズを利用しています :

~ # vmkfstools -Pv 10 /vmfs/volumes/<your_nfs_volume_name>/
NFS-1.00 file system spanning 1 partitions.
File system label (if any): <your_nfs_volume_name>
Mode: public
Capacity 536870912000 (131072000 file blocks * 4096), 194154864640 (47401090 blocks) avail, max supported file size 18446744073709551615
UUID: fcf60a16-17ceaadb-0000-000000000000
Logical device: 10.14.5.21 /mnt/<your_nfs_mount>/<your_nfs_volume_name>
Partitions spanned (on "notDCS"):
nfs:<your_nfs_volume_name>
NAS VAAI Supported: NO
Is Native Snapshot Capable: NO
OBJLIB-LIB: ObjLib cleanup done.
WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0

結論

この記事が皆様のお役に立ち、ブロックサイズが様々異なるレベルで議論されていることや、アロケーションユニットサイズは実際にはアプリケーションのI/Oには何も介在しておらず、仮想マシン自身はVMFSのブロックサイズについてはまったく関知していないことなどをご理解いただけたとしたら幸いです。個人的な意見ですが、環境は可能な限り標準の設定のままにしておくということが良いと思います。アプリケーションごとにちょっとした容量を削減するためにアロケーションユニットサイズを変更したりするのはよした方が良いです。最終的には標準が理にかなっており、異なる構成を入れたとしても1%くらいしか変わらないのでは無いかと思います。いつもどおり、質問、推奨、懸念などがあればご連絡ください。

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

今回も前回に続きvExpertのAdvent Calenderということで、普段は絶対に訳さないようなテッキーな内容をお届け致しました。仮想化におけるブロックサイズはGuidoさんの言うとおり多くの階層でそれぞれ別々の議論になってしまい、そもそもそこを変えても・・・という話は多く出てきます。物理で役に立っていたベスト・プラクティスは仮想マシンの中でやるべきなのか、それともVMFSやNFSのレイヤでやるべきなのか、そもそもストレージシステムでやるべきなのか、、、そうした議論は尽きません。

Guidoさんの言う通り、ESXiという観点からすると、VMFSやNFSのレイヤを見回してもほとんどパフォーマンスに影響のあるようなパラメーターやチューニング操作はありません。アプリケーションの挙動をある程度変えながら、あとはストレージシステム側でのチューニングということに落ち着く事がほとんどです。

せっかくのアドベントカレンダーなので、よく考えずに今までの慣習でやってしまいがちなI/Oチューニングの間違いについての記事を翻訳致しました。いつもながら、Guidoさん、さすがです!