*Nutanix Feed

2018/08/20

本日のFrame検証 : アプリケーション

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

今回もNutanixが買収したDaaS製品であるFrameの検証レポートをお送りいたします。

前回の記事はこちらです。

本日のFrame検証 : テストドライブの開始

この記事には以下の内容を記載しました。

・Frameでのアプリケーション起動と文字入力

・ブラウザーを「確認くん」で確認してみた

・アプリケーションの終了


【Frameでのアプリケーション起動と文字入力】

めでたくテストドライブが開始できるようになりますと、サンプルとなるアプリケーションが利用できる状態になっています。

Frameではこの画面をLaunchpadと呼びます。
015

さっそくLaunchpadからGoogle Chromeをクリックして起動してみました。

Initializing...と表示され、しばらく待つとGoogle Chromeが起動してきます。

016

手元のデバイス(私のパソコン)のChromeの中に、さらにChromeが表示されているのがお分かりいただけるかと思います。

017

デフォルトではウィンドウが最大化された状態で表示されますが、アプリケーションのウィンドウサイズを小さくすることも可能です。

018

ちなみに日本語入力はできないようですが、VDI側のIMEを利用する仕組みではなく、手元のデバイスのIMEをリダイレクトする方式です。

※手元のデバイスのIMEはGoogle IMEで、予測変換が機能しているようですが、残念ながら正常に入力することはできませんでした。

V003

YouTubeで動画再生を試してみたところ、再生自体は問題なくできました。

フレームレートや画質が特別良いというわけではありませんが、動画内の音声も含めてどんな動画かは十分に判別可能で視聴に耐え得る品質でした。

V005

【ブラウザーを「確認くん」で確認してみた】

みなさまは「確認くん」というWebサイトをご存知でしょうか。

ご自身のWebブラウザーがアクセス元としてどういった情報を持っているかを表示してくれるサイトですが、Frameから接続してどうなっているのかを確認してみました。

アクセス元のIPアドレスが18.179.42.0となっており、Frameからのアクセス元IPはAWSに割り当てられているレンジのものであることが分かります。

参考URL : ipinfo.io

V006

画面左下の[Click here to start]ボタンをクリックすると、別のアプリも同時に起動することが可能です。

V007

【アプリケーションの終了】

各アプリケーションの右上にある[X]ボタンをクリックすると自動的に終了します。

改めて別のアプリケーションを起動するにはLaunchpadに戻り、使いたいアプリケーションのアイコンをクリックするだけです。

023

記事担当者 : SI技術本部 海野航 (うんのわたる) @Nutanix_NTNX

2018/08/19

本日のFrame検証 : テストドライブの開始

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

先日、NutanixがDaaSを提供する企業であるFrame社の買収を発表し、当社のカッシー先輩もそれに関する記事をこのブログで公開しております。

Frameという製品はいわゆる DaaS (Desktop-as-a-Service) であり、今回は実際にそれをTest Driveで試してみた内容をお知らせします。

FrameがCitrixやVMware、Microsoft RDSなどとどう違うのかという点については、このFrame社ブログの記事が参考になるかと思います。

なお、Nutanixの島崎さんが上記の記事を翻訳して公開されています。


【Frameをテストドライブするには】

Frameはカンタンに試すことができます。

このFrame Test Driveというページへアクセスし、ご自身の情報を入力します。

001

テストしたい環境のデプロイ先を指定します。

今回はAWSの東京リージョンでテストすることにしました。005

次に電話番号を入力して認証をしますが、[SMS]によるテキスト通知と[Call me]による音声による通知が選択できます。

当初、私はSMSで試してみたのですがこれがうまくいかず、[Call me]を選択することで解決しました。

V001

認証が成功しますと、先ほど入力しているメールアドレスにFrameから確認のメールが送付されます。

010

[CREATE MY TEST DRIVE ACCOUNT]をクリックしますと、テスト用のアカウントの生成がスタートします。

私の場合は準備完了してログインできるようになるまで20分程度かかりました。

012_3

テストドライブではあらかじめ検証で利用できるようなアプリが用意されています。

2時間という限られた時間制限の中ではありますが、とてもカンタンにFrameを試せることがお分かりいただけるかと思います。

013

記事担当者 : SI技術本部 海野航 (うんのわたる) @Nutanix_NTNX

2018/08/15

Nutanix 回復性能 – パート7 – ハイパーバイザアップグレードの間のRead&Write I/O

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Resiliency – Part 7 – Read & Write I/O during Hypervisor upgradesをご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


まだパート1~4を読んでいない場合は前述したパートでは重要なRFと障害からの復旧スピード、RF2から3へ変更する事での回復性能の向上、同じくEC-Xを利用し同じRFを提供しながらの容量削減を記載していますので是非みてください。

パート5,6ではCVMがメンテナンスまたは障害時にどの様にリード・ライトI/Oを行うかを説明し、このパート7ではリード・ライト I/Oがあるハイパーバイザ(ESXi,Hyper-v,XenServer,AHV)のアップグレードにどの様な影響があるかを見てみます。

このブログはパート5,6と深く関係していますのでパート5,6を完全に理解して頂くことをお奨めします。

パート5,6を読むことで,CVMがどんな状況になったとしてもリード、ライト I/Oは継続され設定しているRFに従いデータが保持されるという事が解ります。

ハイパーバイザのアップグレードイベントで仮想マシンはまず移行され通常の操作が継続されます。

ハイパーバイザの障害では仮想マシンはHAのにより再起動され他のノードで稼働します。

ハイパーバイザまたはノードの障害なのか、ハイパーバイザのアップグレードなのか

どちらにしても結果的には仮想マシンはほかのノードで稼働し、元のノード(下のダイアグラムでいうNode1)はある程度の期間オフラインとなりローカルディスクは利用できなくなります。

Hostfailurehypervisorupgradewriteio

リードI/Oのシナリオはどうでしょうか?パート5で説明した内容と同じでリードはリモートのデータを読みに行くか仮想マシンの移動先のノードに複製データがある場合、リードはローカルからとなります。

リモートに1MBのエクステントがローカライズされるとその後のリードはローカルとなります。

書込みはどうか?パート6であるように

書き込みは常に構成されたRFに順次し、たとえハイパーバイザのアップグレード、CVM、ハイパーバイザ、ノード、ネットワーク、ディスク、SSD障害がだとしても一つの複製とローカルへ残りの1つまたは2つの複製をクラスタの現在のパフォーマンス、ノードの使用量をベースに分散します。

それは本当にシンプルでこのレベルの回復性能を実現するのはADSFのおかげなのです。

Summary:

  1. A hypervisor failure never impacts the write path of ADSF
  2. Data integrity is ALWAYS maintained even in the event of a hypervisor (node) failure
  3. A hypervisor upgrade is completed without disruption to the read/write path
  4. Reads continue to be served either locally or remotely regardless of upgrades, maintenance or failure
  5. During hypervisor failures, Data Locality is maintained with writes always keeping one copy locally where the VM resides for optimal read/write performance during upgrades/failure scenarios.

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/08/08

Nutanix 回復性能 – パート6 – CVMがメンテナンスまたは障害時のWriteI/O

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Resiliency – Part 6 – Write I/O during CVM maintenance or failuresをご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


パート5ではCVMがメンテナンス中、または障害時にどの様にリードI/Oが行われるかを説明しました、今度は同じようにメンテナンス、障害のシナリオ期間中に発生するより重要な書込みI/Oについて知っておく必要があります。

パート5をお読みになった方は同じように感じるでしょう、まだパート5を読んでいないかたは是非パート5も読んでください。

さて、簡単にどのようにNutanix ADSFが書込みを行い、データ保護をしているか説明します。

下のダイアグラムでは3つのノードと一つの仮想マシンが存在しています。

仮想マシンは正常な状況では全ての書き込みは一つの複製と共に仮想マシンが稼働しているノード(ここではNode1)に書込み、他の複製(レプリカがRF3の場合も)をディスクの健全性を元にクラスタへ分散してデータ(a,b,c,d)を書き込みます。

ディスクの健全性(私が“Intelligent replica replacement”と呼んでいるもの)はデータはまず最も最適な場所にかかれます。

Rf2overview_2

1または複数のノードが追加されるとすれば、”Intelligent replica placement”はクラスタがバランスの状態になるまで、たとえ新しい書込みが発生していなくてもノードに比例して複製を送信します。

ADSFはバックグラウンド処理で低い優先順位としてディスクが全体的に均衡になるように処理をするのです。

どのようにしてNutanix が複数の複製(Resiliency Factorと呼んでいるもの)を利用してデータ保護を行っているかの基本を理解した所で、Nutanix ADSFのストレージ部分のアップグレード時にどんな事が起こるか見てみましょう。

アップグレードはワンクリックで始まり、それはRFEC-Xの構成にかかわらず一度に1つのCVMがアップデートされるローリングアップデートのスタイルとなります。

ローリングアップグレードはCVMを一度オフラインにし、アップグレードの実施を行い、自己診断後にクラスタに参加し次のCVMが同じ処理を行います。

NutanixのストレージがHypervisorと分離している(例:ストレージがカーネルのなかに組み込まれているものではない)多くのアドバンテージの一つがアップグレードとストレージレイヤーの障害が仮想マシンに何の影響も与えない事なのです。

仮想マシンは再起動を必要としません(HAのようなイベントは無しです)そして仮想マシンを他のノードに移動する必要もありません。

たとえローカルコントローラーが如何なる理由でオフラインになっても、仮想マシンはストレージトラフィックの中断無しに稼働します。

もしローカルにあるCVMがメンテナンスや他の障害でダウンしたら、I/Oは動的にクラスタ内へリダイレクトされます。

CVMの仮想マシンが如何なる理由であれオフラインになった際のWrite I/O処理をみてみましょう。

ローカルのCVMがオフラインになるという事はCVMが稼働しているサーバの物理ドライブ(NVMe,SSD,HDDなど)が利用できなくなる事を意味していて、それはローカルデータ(複製)が使用できないことになります。

全てのライトI/Oは一つの複製をローカルに置くという事より、RFに従う形で書き込みが継続されます。データはリネットワーク越しにリモートのCVMを通して複製します。

次の例では3つのノードでノード1にいる仮想マシンが”E”のデータをネットワーク越しにNode2 , 3に書き込みます。これがリモートのCVMによって新しいデータが書き込まれる方法です。

Photo

もっと多くのノードがクラスタに存在していれば書き込みはクラスタ内のすべてのノードに”Intelligent Replica Placement”によって下の図のように分散されます。

1

新しいデータとは反対に上書きが発生した場合、ローカルにあるデータはCVMのオフラインにより利用できません。

Nutanixは他の複製に上書きを行い次にそのデータの複製をRFに応じて別のノードに書き込むことによってデータの整合性が保たれます。

2

これはとても重要な事で、もしデータがRF(VMware VSANでいうFTT)に常に準じていなければ次に起こりうるドライブ、ノード障害がデータ損失の原因になります。

vSANよりも優れたRFの大きなアドバンテージをNutanixにはるのは、全ての障害、メンテナンスシナリオに対してRF準拠する事です。

しかしvSANは全てのホストメンテナンス、障害シナリオのFTTを構成していません。

FTT1で構成されているvSAN上のVMはホストが提供している一つのvSANオブジェクトのメンテナンスでオフラインの場合、新しい上書きは保護されないため、一つのディスク障害がデータロスを引き起こす事があります。

VMware社のチーフテクノロジー Duncan Epping氏は最近に次の"VSAN:6.2でFTT=2がデフォルト"になる理由という記事を掲載しました。この記事によりDuncan Epping 氏はFTT=2をvSAN利用者のため、新しいデフォルト値として推奨したのです。

私はDuncan氏には同意です。しかしvSANをFTT=2にするべきとは言いません。

FTT=1はメンテナンス、または障害時の間の上書き処理に対する単一障害点となるのでFTT=2にしなければならないと考えます。これは多くの本番環境にとって受け入れがたい事です。

一方NutanixはvSANと同じアーキテクチャではないので、RF2は非常に優れ、このシリーズで説明したとおり、クリティカルな本番環境にも適しています。

そしてADSFはタイムリーにRFを復旧するのでRF2はvSANのFTT=1と比べても非常に優れていると言えるのです。

次はハイパーバイザのアップグレードで仮想マシンがどのように影響を受けるかを説明します。

Summary:

  1. Write I/O continues uninterrupted if the local CVM is offline
  2. Write I/O is distributed throughout the cluster evenly thanks to Intelligent Replica Placement
  3. All new data is written in compliance with the configured Resiliency Factor
  4. Overwrites of existing data is always written in compliance with the configured Resiliency Factor by writing a new replica where the original replica is not available.
  5. Data integrity is ALWAYS maintained regardless of a CVM being under maintenance or failure.
  6. Nutanix RF2 is more resilient than vSAN FTT=1 despite each claiming to maintain two copies of data.

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/08/06

クラウドロックインが無いFrameとNutanix Xi クラウドサービスによるDesktops-as-a-Service

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方は

Desktops-as-a-Service, With No Cloud Lock-In – Frame and Nutanix Xi Cloud Servicesご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

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


本日 私たちはfra.meNutanixのファミリーにむかえ、Nutanix Xi サービスDesktop-as-a-Serviceを提供できるようになることをお知らせします。

本サービスは、まず1クリックデスクトップの展開をAWSAzureする事をサポートし、そして全てのクラウドに拡張していきます。

NutanixのミッションはITスタックをシンプルにすることで、物理インフラから始まり徐々にデーターセンターインフラ基盤へ広げていきます。

Nutanix Xi サービスはハイブリットクラウドのパワーを企業へもたらし、ツールや企業システムの複雑な事に対して摩擦無しにクラウドファーストの消費モデルをサポートする為の戦略の進化となります。

このハイブリッドクラウドは純粋なパブリッククラウドパスの代わりとなるのです。

私たちが企業の収益創出をお手伝いする事ができず、もっとも便宜的で費用対効果の高い方法で全てを問題のすべてを取り除く事が出来ないとすれば、本当のアプリケーションとITの目的はなんでしょうか?

このミッションに鋭く焦点を当てる一方で、Nutanixはこのミッション、クリティカルなアプリケーション、高いパフォーマンス、トランザクション処理の入るデータベース、ビックデータで求められるデータレイクや他のすべてのアプリケーション(アナリストの用語でいう、モード1,モード2アプリケーション - オンプレミス vs クラウド - そしてインフラストラクチャ基盤のインビジブルがこれらのアプリケーションへ提供するように進化をしてきているのです。

このコンセプトは1クリック機能、インテリジェンスなアルゴリズム、ゼロタッチオペレーション、利用者向けのUX,Webスケール技術によって作られています。

お客様を基準としたNutanixの多様性はアプリケーションの本質を持ち、仮想デスクトップとAppsVDI)は依然として私たちにとって重要なものであり劇的に成長しているのです。

ハイパーコンバージドが斬新とされていた早い段階から、VDI環境はストレージ、ネットワーク、サーバと運用の境界をなくし、個々のサイロ化された専門性、高いOPEXを維持しながら続ける環境へどのようにゲームチェンが行われるかを知ることができる最初のものでした。

VDIはハイパーコンバージェンスを引っ張る要因となり、世界へこれが全てのアプリケーションの為のデーターセンターを構築する新しい方法だという事を示したのです。

その方法は純粋なパブリッククラウドを利用するよりもあるかに説得力のある方法だったのです。

現在の素晴らしいNutanixの上で稼働するVDIですが、VDIはかつてのように多くの負担をかけるものではなくなった一方、最も使われている2つのソリューションを組み合わせたものでビジネス全体では重要な部分です。

Nutanixが順調にアプリケーションスタックの下で革新したとしても、インビジブルな仮想化のAHV、ゼロタッチ運用の為のPrism Pro, ネットワークセキュリティの為のFlow、ソフトウェア定義のスケールアウトファイルサービスAFS、と共にVDIの提供を継続するのがより良い事となり、常にVDIにもっと良いことが出来るかと考えているのです。

2016年初め、NutanixCitrix社と提携し、非常に素晴らしいシンプルなCitrixの展開を行うため、AHVのインビジブルな仮想化基盤を活用し、お客様のこの統合における絶大な価値を認識頂いています。

2017年後半にはCitrix Cloud InstantONの導入がお客様のVDIの展開を簡単にし迅速に展開できる価値を提供しました。

インビジブルなインフラ基盤を全ての有名なVDI環境へ提供し、Nutanixは数千ものお客様の環境へ入ることで変化するお客様の意向が見えました。

この振舞は、利用されている殆どの期間が8時間 x 5日、またはすべてのアプリケーションがSaaSやクラウドへ移行した際のオンプレミスの仮想デスクトップ環境であったとしても24時間 x7日間仮想デスクトップのインスタンスを働し続けなければ行けないという疑問に向けられました。

クラウドネイティブなアーキテクチャ上でどの程度デスクトップやAppが使われてるか根本的に簡素化する必要が急速に高まっていることが明らかになったのです。

AWSはワークスペースの立ち上げをこれで開拓しましたが、市場の中で多くの需要がないニーズの機能を提供したのと同様に1つのクラウドへのロックインをしたのです。

それがこの機会となり、Frameの買収とNutanixと共に進むという交点がエンタープライズ環境の中でシンプルさへという道のりのなか衝撃をさらに広げる事になるのです。そして、今Nutanixはデスクトップとアプリケーションレイヤーを持ち合わせています。

Blog_frame01

想像してみてください。1クリックで簡単にNutanix Xi サービスにDaaSが提供しているFrameの魅力的なものを追加できるとしたら?クラウドロックインがされていなかったら?Frameは選択の考え、開放性、簡素性を統合する

もし何かが複雑すぎて1クリックが達成できない場合は振り出しに戻ってやり直し、アーキテクチャがクラウドスケールでない場合は技術スタック全体を再考、もしNutanixがしているようにNPSスコア90という一貫性が取れないほど魅力の無い場合は真の価値が提供されるまでそこに注力します。

この目的に向け、Frameは殆ど多くのクラウドへ展開できる”クラウド生まれのDaaSソリューション”として作られており、お客様が選択しているNutanix1クリック、シンプルという哲学と一貫しています。

これは、いかなるシングルクラウドのロックインを避けることが出来、ITの長期間リスクは最小限となります。

全ての企業の運用ツールを変更しないでNutanix Xiサービスが利用できる事は、クラウドパブリックをより身近にし、多くの機会を提供することになります。

アイシングはFrameの素晴らしいユーザーエクスペリエンスであり強力な展開プロトコルが最も要求の厳しいグラフィック-インテンシブアプリケーションでさえも完璧に利用者のネットワーク上で動作します。これはHTML5ブラウザになるので如何なるクライアントソフトウェアの必要もないのです。

私たちは素晴らしく才能がありハングリー精神のあるFrameチームがNutanixと一緒になる事に本当に興奮しているのです。Nutanix Xi サービスとしてFrameが実行できることはこの旅のエキサイティングな一歩であり、他のエンタープライズレイヤに1クリックでユーザー、管理者が利用者へクラウドスケールデスクトップとアプリケーショをもたらし他のエンタープライズのレイヤーの障壁を粉砕する事を楽しみにしています。

Frameがどのように簡単に利用が出来るのか?

当社のVDIを得意とする技術メンバーが検証し今後Blogで紹介したいと思いますので

お楽しみにしてください!

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

Forwarding-Looking Statements

This blog contains express and implied forward-looking statements, including but not limited to statements relating to the closing of the Frame acquisition, the impact of the Frame acquisition to our business, our plans to introduce product features in future releases, including Nutanix Xi Cloud Services and the integration of Frame into Nutanix Xi Cloud Services and our other offerings, and our ability to successfully integrate Frame and its employees and intellectual property. These forward-looking statements are not historical facts and instead are based on our current expectations, estimates, opinions, and beliefs. Consequently, you should not rely on these forward-looking statements. 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 close, or unexpected difficulties or delays in closing, the Frame acquisition; failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of desktops-as-a-service platforms or our new product features or technology; our ability to successfully integrate Frame’s employees and intellectual property; the possibility that we may not receive anticipated results from the Frame acquisition; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; and other risks detailed in our Quarterly Report on Form 10-Q for the quarter ended April 30, 2018, filed with the SEC on June 12, 2018. Our SEC filings are available on the Investor Relations section of the company’s website at ir.nutanix.com and on the SEC’s website at www.sec.gov. 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.

Disclaimer: This blog contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites, and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

2018/08/01

Nutanix 回復性能 – パート5 – CVMがメンテナンスまたは障害時のRead I/O

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Resiliency – Part 5 – Read I/O during CVM maintenance or failures?をご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


これまでにADSFノード障害からの復旧が早いという事、またどRF23にすることで回復性能を高めること、そして稼働したまま空き容量を効率化するためのEC-Xへの変更を話してきました。

今回はCVMAOSアップグレードの間のメンテナンス期間中、またはCVMの障害が発生している間、どのように仮想マシンが影響を受けるかというクリティカルで重要な話題をしていきます。

では簡単にADSFがどのように書込みを実施してデータを保護するか説明します。

次のダイアグラムでは3つのノードでクラスタが構成されており一つの仮想マシンが存在しています。

仮想マシンは正常な状況では全ての書き込みは一つの複製と共に仮想マシンが稼働しているノード(ここではNode1)に書込み、他の複製(レプリカがRF3の場合も)をディスクの健全性を元にクラスタへ分散してデータ(a,b,c,d)を書き込みます。

ディスクの健全性(私がIntelligent replica replacement”と呼んでいるもの)はデータはまず最も最適な場所にかかれます。

Rf2overview

1または複数のノードが追加されるとすれば、”Intelligent replica placement”はクラスタがバランスの状態になるまで、たとえ新しい書込みが発生していなくてもノードに比例して複製を送信します。

ADSFはバックグラウンド処理で低い優先順位としてディスクが全体的に均衡になるように処理をするのです。

どのようにしてNutanix が複数の複製(Resiliency Factorと呼んでいるもの)を利用してデータ保護を行っているかの基本を理解した所で、Nutanix ADSFのストレージ部分のアップグレード時にどんな事が起こるか見てみましょう。

アップグレードはワンクリックで始まり、それはRFEC-Xの構成にかかわらず一度に1つのCVMがアップデートされるローリングアップデートのスタイルとなります。

ローリングアップグレードはCVMを一度オフラインにし、アップグレードの実施を行い、自己診断後にクラスタに参加し次のCVMが同じ処理を行います。

NutanixのストレージがHypervisorと分離している(例:ストレージがカーネルのんかに組み込まれているものではない)多くのアドバンテージの一つがアップグレードとストレージレイヤーの障害が仮想マシンに何の影響も与えない事なのです。

仮想マシンは再起動を必要としません(HAのようなイベントは無しです)そして仮想マシンを他のノードに移動する必要もありません。

たとえローカルコントローラーが如何なる理由でオフラインになっても、仮想マシンはストレージトラフィックの中断無しに稼働します。

もしローカルにあるCVMがメンテナンスや他の障害でダウンしたら、I/Oは動的にクラスタ内へリダイレクトされます。

CVMの仮想マシンが如何なる理由であれオフラインになった際のRead I/O処理をみてみましょう。

ローカルのCVMがオフラインになるという事はCVMが稼働しているサーバの物理ドライブ(NVMe,SSD,HDDなど)が利用できなくなる事を意味していて、それはローカルデータ(複製)が使用できないことになります。

全てのリードI/Oはリダイレクトされクラスタ内のすべてのCVMによってリード処理は継続されます。

Readioservedremotelywhencvmifofflin

このメンテナンス・障害のシナリオは仮想マシンがストレージを提供できなくなってもネットワーク越しにストレージを利用できるノードは稼働するという点において3Tierアーキテクチャと比較ができます。

Nutanixはクラスタのすべてのノードでリードが提供できる分散アーキテクチャなので最悪のケースとして3ノードクラスタでノード障害、もしくはメンテナンスの期間中であってもデュアルコントローラーのストレージと同等の機能があるわけです。

繰り返しますと、3ノードクラスタで1ノードが障害または、メンテナンスとなる最悪のシナリオが発生しているクラスタのリードはリモートから読み込みます。

Nutanixの最も悪いデグレード状態は最適な状態のデュアルコントローラーのストレージにコンピュートノードがアクセスするのと同等なのです。

もしNutanix8ノードで構成しており、1台がメンテナンスまたはダウンしても7台のノードがVMへストレージアクセスを行うのです。

この処理は実際には何も新しくなく、Nutanixが昔から行っている方法なのです。

詳細はAcropolis Hypervisor (AHV) I/O Failover & Load Balancing 2015年の7月のBlogにも記載があります。

ローカルのCVMが一度オンラインになればリード I/Oは再びローカルのCVMによって提供され、リモートへの読み込みはデータがローカルに無い場合に発生します。

リモートの読み込みが発生するとそのデータを含む1MBのエクステントがローカライズされリードはローカルから読み込まれるようになります。

エクステントのデータがローカライズされることはリモートのリードを行うことに比べて追加のオーバーヘッド無く、ローカライズは追加のオーバーヘッド無しにパフォーマンスが良くなるという事を理解する事は非常に重要な事です。

Summary:

  1. ADSF writes data on the node where the VM resides to ensure subsequent reads are local.
  2. Read I/O is serviced by the local CVM and when the Local CVM is unavailable for any reason the read I/O is serviced by all CVMs in the cluster in a distributed manner
  3. Virtual machines do not need to be failed over or evacuated from a node when the local CVM is offline due to maintenance or failure
  4. In the worst case scenario of a 3 node cluster and a CVM down, a virtual machine running on Nutanix has it’s traffic serviced by at least two storage controllers which is the best case scenario for a Server + Dual Controller Storage Array (3 Tier) architecture.
  5. In clusters larger than three, Virtual machines on Nutanix enjoy more storage controllers serving their read I/O than an optimal scenario for a Server + Dual Controller Storage Array (3 Tier) architecture.

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/07/25

Nutanix 回復性能 – パート4 – RF3からイレージャーコーディングへ変換

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Resiliency – Part 4 – Converting RF3 to Erasure Coding (EC-X)をご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


このシリーズでクラスタはRF2からRF3に変換されている状態です。

いま、お客様は回復性能の影響なしに容量効率を良くしたいと思うとすると

イレージャーコーディングの有効化のプロセスとスピードを見る必要があります。

Nutanixのイレージャーコーディング(EC-X)はRFの構成が完了していて至上な状態のコールドデータに対してのみ実施されます。そしてEC-Xはポストプロセスで実行するため、クラスタに対するインラインの書き込みには影響が無いようになっています。

Nutanix EC-Xについてもっと知りたいかたは Nutanix – Erasure Coding (EC-X) Deep Dive.を参照ください

どんなI/OがNutanixのEC-Xに有効なのですか? いい質問!です

書込みのコールドデータのみです。

EC-XはデータがコールドデータになったらNutanixADSF キューレーターが低優先のタスクとしてバックグラウンド処理でEC-Xを実施します。

どのくらい RF2/3 からEC-Xにするのは早いのですか?

簡潔にいうと全パートで示したように基盤のなるディスクは高速処理が可能ですが、EC-Xは容量削減を目的とした技術で、データにリスクが無いため、ドライブ障害やノード障害の様にスピードは必要ないので、“ErasureCode:Encode”タスクのプライオリティが下に示すように3となります。

ノード・ディスク障害はプライオリティは「1」となります。

Ecxpriority3tasks

もしお客様がこの処理をどんな方法を使ってもそれがキュレータをメンテナンスにしソフトリミットを削除して多くの処理を実施させることになったとしても、出来るだけ早く実施したい場合はサポート対応となりますので、ここでは方法を共有しません。

次にスループットとEC-X後のストレージプールの状態です。

途中で一部スループットが落ちているのは、バックグラウンドのキューレータースキャンを通してEC-Xを部分的に有効にしたたため、結果データのいくつかが変換されたものです、その後手動で他のフルスキャンを実施し、高いスループット(> 5GBps)を実現し完了しました。

Ecxsavingsandstoragepoolcapacityusa

次に示すのは理論的に最大値の2:1に近い、1.97:1の容量の最適化の結果です。

EC-Xがこのように最大値に近い結果にたどり着いたのはアクティブなワークロードがクラスタ内になるく、テストデータがすべてコールドとなりEC-Xがストライプ出来たからです。

Ecxsavingscompletedmultiplescans

だから37.7TB近いデータセットのリードと再書き込みを18TB近く使われているEC-Xへ行い、結果は18.54TBのデータ削減につながることになりました。

単純計算で37.7TBのデータがADSFで読み込まれ、18TBのEC-XストライプデータがADSFによる全体の56TBのIOサービスのため、90分以内で書かれたのです。

Summary:

  • Nutanix EC-X has no additional write penalty compared to RF3 ensuring optimal write performance while providing up to 2x capacity efficiency at the same resiliency level.
  • ADSF uses it’s distributed storage fabric to efficiently stripe data
  • Background EC-X striping is a low priority task to minimise the impact on front end virtual machine IO
  • ADSF can sustain very high throughput during EC-X (background) operations
  • Using RF3 and EC-X ensures maximum resiliency and capacity efficiency resulting in up to 66% usable capacity of RAW storage (up to 2:1 efficiency over RF3)

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/07/18

Nutanix 回復性能 – パート3 – RF3でのノード障害

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Resiliency – Part 3 – Node failure rebuild performance with RF3をご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


パート1ではAcropolis Distributed Storage Fabric (ADSF)のおかげで効率よく素早くノード障害からリビルドを行えるというNutanixAOSの能力について話し、一方パート2ではストレージコンテナがRF2からRF3へ変換し回復性能、どれくらい完了までに早くその処理が終わるかを議論しました。

パート2では12ノードクラスタで各ノードのディスクの利用率はこのようになっています。

Nodecapacityusage12nodeclusterrf31

障害をシュミレートするノードは5TBのディスクの使用率でこれはパート1で実施したノード障害のテストと近い状態です。

クラスタは現在12ノードのみで構成されているので、パート1と比べてリード・ライトを行うコントローラーが少ないことが解ります。

次にIPMI経由で”Power Off -Immediate”でノード障害をシュミレートします。

次が示すのは30分後に5TBのデータの再保護が完了する際のノードのリビルドのストレージプールのスループットです。

Rebuildperformanceandcapacityusager

まず、すぐに解るのは5TBのデータの再保護までに約30分かかるとことです。

5年前のハードウェアとすれば、他のSANやHCI製品と比べても上出来でしょう。

しかしもっと早くてもよいのではと感じたので調べてみました。

ノード試験当時クラスタがアンバランスな状態になっていることが解り、結果的にノードはまったく、または殆どデータを持たないため正常時のように全てのノードがリビルド処理を行っていなかったのです。

クラスタがアンバランス状態になったのは私が頻繁にノード障害のシュミレートを試しており正常にするためにノード追加の後にバランス処理が完了するのを待てないでノード障害のシュミレートを行ったのです。

通常メーカーは最適でない結果を投稿しませんが、私は透明性が重要と強く感じています。クラスタがアンバランスになる可能性があり、もしその様な状況でノード障害が発生した際にどの様な回復性能に影響があるかを知ることが大事です。

そこで、クラスタがバランスの状態である事を確認してテストを再度実施した結果が次の通りです。

Rf3nodefailuretest45tbnode

ここで解るのは5GBpsだったアンバランスと比べて6GBps以上のスループットが出ており、

1GBpsものパフォーマンス向上が凡そ12分間にわたって続いていたのです。

またアンバランスの状態で確認できたスループットの劣化は発生していません。

これはすべてのノードが均等にデータを持つことでリビルドの期間、全てのノードがリビルドを実施する事が出来たおかげなのです。

Summary:

  • Nutanix RF3 is vastly more resilient than RAID6 (or N+2) style architectures
  • ADSF performs continual disk scrubbing to detect and resolve underlying issues before they can cause data integrity issues
  • Rebuilds from drive or node failures are an efficient distributed operation using all drives and nodes in a cluster
  • A recovery from a >4.5TB node failure (in this case, the equivalent of 6 concurrent SSD failures) around 12mins
  • Unbalanced clusters still perform rebuilds in a distributed manner and can recover from failures in a short period of time
  • Clusters running in a normal balanced configuration can recover from failures even faster thanks to the distributed storage fabric built in disk balancing, intelligent replica placement and even distribution of data.

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/07/11

Nutanix 回復性能 – パート2 – RF2 から RF3へ変換する

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Resiliency – Part 2 – Converting from RF2 to RF3をご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


パート1ではAcropolis Distributed Storage Fabric (ADSF)のおかげで効率よく素早くノード障害からリビルドを行えるというNutanixAOSの能力について話しました。

パート2ではストレージコンテナがどのようにしてRF2からRF3に変換できるか、そして完了までにかかる速度をお見せしたいと思います。

このテストでは12台のノードでクラスタを作成しています。

Clustersize

ストレージプールの使用率を確認しながら始めましょう

Rf2usage

現在50TB以上のストレージがクラスタ内で利用されています。

RF3へするには単純にすべてのデータに3つ目の複製を追加するかです。

当然それを実施するだけの十分な容量を持っておく必要があります。

次にRedundancy FactorFTレベル)をRF3に増やします。

これによりRF3のコンテナがサポートできるようになり、少なくても2ノードの障害でも稼働できるようになります。

Reducdancyfactorcluster

次にストレージコンテナをRF3にします。

一度コンテナがRF3にセットしてまえば、CuratorがクラスタのRedundancy factorに従いバックグラウンド処理で追加の複製を作成します。

この例では凡そ50TBのデータがストレージプールにあるので、この処理では50%の複製が実施されることになるので75TBのデータ量になる事となります。

Rf2torf3on12nodecluster_2

3時間以内のプロセスでは7GBps以上のスループットが出ていることが確認でき、1h/8.3TBとなります。

クラスタが完全にRF2レベル冗長性を維持しながら、このRF3への変換プロセスの間に新しいデータが書き込みがされた場合、そのデータはRF3として作成され、保護されるという事が大切です。

下のチャートはストレージプール利用率がリニアに増えていくことを示しています。

Storagepoolcapacitygrowth

クラスタサイズが大きくなれば、この処理にかかる時間は早くなるという事が大事なことで、ADSFが本当の分散ストレージファブリックであり、ノードが増えれば増えるほどコントローラが多くの書き込みを処理できるです。

素晴らしいノード追加の例はScale out performance testing with Nutanix Storage Only Nodesをご覧ください(英語サイト)

処理が完了するとストレージプールは予想していた75TB程度になっています。

Storagepoolcapacitywithrf3

NutanixADSFがどの程度このドライブに対して処理をさせているか興味を持っている方の為に、実行中のいくつかのステータスを取得しました。

Stargateextentstorestats

解ることは物理ディスクが単一のキャッシュドライブでインテリジェントでないHCI環境のように容量のオフロードされているのではなく、最大限にリードライトをすべてのドライブにまたがって利用しているという事です。

Summary:

  • Nutanix ADSF can change between Redundancy levels (RF2 and RF3) on the fly
  • A compliance operation creating >25TB of data can complete in less than 3 hours (even on 5 year old equipment)
  • The compliance operation performed in a linear manner throughout the task.
  • A single Nutanix Controller VM (CVM) is efficient enough to drive 6 x physical SSDs at close to their maximum ability
  • ADSF reads and writes to all drives and does not use a less efficient cache and capacity style architecture.

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/07/04

Nutanix 回復性能 – パート1 – ノード障害のリビルドに関するパフォーマンス

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Resiliency – Part 1 – Node failure rebuild performanceをご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


2013年の中旬からNutanixでビジネスクリティカルアプリケーション、スケーラビリティ、回復力とパフォーマンスに注目しながら働いてきています。

私はよくお客様やパートナーの方とNutanix製品の回復力に関する事やNutanix Platformでどのように構成するのが一番良い方法か会話しています。

Nutanix Platformの数多くある強みの一つで私が多くの時間と努力を費やしてきた領域は回復力とデータの完全性、そして重要なのは障害シナリオとどのようにNutanixが障害時に動作するのかを理解する事です。

Nutanixは独自の分散ストレージファブリック(ADSF)で仮想マシン、コンテナのストレージの提供をします。そのRF2 または3で構成されている物理サーバでもあります。

単純な視点からRF2N+1(例えばRAID5)RF3 N+2 (例えばRAID6)を比較する事が出来ますが、RF23は分散ストレージファブリックの障害からの素早く再構築が出来き、障害発生の前に検知し解決するディスクスクラブにより回復力が従来のRAIDよりも非常に高いのです。

Nutanixはデータの完全性を確実にするための継続的なバックグラウンドでのスクラブの実施だけでなく、すべてのリード、ライトへチェックサムの実施をしています。

RF2が使われいるとしてもADSFの回復力の話をするときの重要な要素はRF2または3に準拠した形でドライブ、ノードフェイルに対する復旧のスピードです

リビルドはすべてのノード、ドライブをまたいだ完全な分散処理になるので、素早く、各ノードのボトルネックを最小減に抑え、稼働しているワークロードのインパクトを少なくすることが出来るのです。

どうして早いか? 当然、CPU世代、とネットワーク接続性、同様にクラスタのサイズ、どのようなドライブが搭載されているか(NVMe , SATA-SSD , DAS-sATA)に依存します。サンプルはこうです。

テスト環境が16クラスタ 殆どが五年前のハードウェアのNX-6050 , NX-3050の混在構成でCPUIvy Bridge 2560( 2013Q3のもの)、各ドライブは6本のSATA-SSDを搭載し2x10GBのネットワーク接続とします

最初のテストではデータ削減技術(重複排除や圧縮またはいれージャーコーディング)を利用しないデータを利用しますが、データ削減がパフォーマンスを向上しデータ削減によりデータの再構築にかける時間を短縮できるので、このテストの結果はベストなケースシナリオではありません。

次に示す通りノードは5TBちょっとのデータがあり、測定するのは5TBのノード障害シナリオに対するリビルドの速度となります。

クラスタの半分のノードは約9TBの容量で他の半分は1.4TB 3TBの容量となります。

Nodefailure_capacityusage

ノード障害はIPMIの”Power off server  - immediate” にて実施します。

この操作は電源を引き抜く操作に相当します。

Ipmipoweroff

Acropolis Distributed Storage Fabric (ADSF)の回復力の良いところはノード障害中の各ノードの統計情報を見ると明らかにわかります。1GBpsのスループットがシングルノードで達成しクラスタのすべてのノードが容量に応じてほぼ同じスループットが出ているのがわかります

Diskionodefailure

半分のノードのスループットが低いのは容量が少なく、結果リビルドするデータが少ないからです。

もしすべてのノードが同じだったとしたらスループットは概ね最初の4つのリストにあ

RAIDに組まれているドライブが大きくなればなるほど、リビルドにかかる時間が多くなり、その間の障害発生に対しるデータロスのリスクが高くなります。

RAIDのリビルド中に発生するパフォーマンスの影響もドライブ一台の障害と一台のリビルド先しかないことかにより高くなります。

これは長いウィンドウのパフォーマンスインパクトとデータが保護されていない事を意味します。

るノード(1GBpsでているもの)と同じになるでしょう。

Nutanixが分散ストレージファブリックを使っていなければ、リビルドはリビルド元、RAID、または一般的なHCIのリビルド先のノードによって制約が発生するでしょう。

例えば、全てのノードが小さいエクステント(1MB)を多対多、効率的にクラスタ内で複製する事に反して、Node-Aは大きいオブジェクトをNode-Bへ複製するでしょう

これまでのRAID5を比較すると、リビルド元になるのは障害が発生した特定のドライブのみとなります。RAIDのドライブは324で構成されリビルド用に一つのスペアディスクを設定します。つまりリビルド操作は一つのディスクによるボトルネックがあります。

ほとんどすべてのITプロフェッショナルの方々はRAID5、たとえRAID6であったとしても 数時間から数日の長期間にわたるシングルドライブ障害の復旧にかかるRAID構成に対して“ゾッ”とする話をもっています。

これらの一般的な嫌な経験はN+1(そしてRF2)でさえ悪評となった大きな理由です。

RAID5 , 6のリビルドが数分以内で完了できたとしたら・・

大多数の次に発生する障害がダウンタイムやデータロスをもたらす結果にはならないでしょう。

ではNutanix ADSFのリビルドパフォーマンスにもどりましょう。

繰り返しですがADSFはレプリカ(データ)を1MBのサイズでクラスタ内に分散します。(すべてのデータが2つだけのノードに存在するペアスタイルではありません)

この分散がリビルド中の書込みのパフォーマンスを向上し、結果的に多くのコントローラー、CPU、ネットワーク幅をリビルドのために利用します。

簡単に言うと、クラスタが大きくなればなるほど、ノードはレプリカのRead, Writeが増えていき復旧にかかる時間が早くなります。

クラスタのサイズが大きいほど障害とリビルドに対するインパクトが下がり、大きなクラスタではRF2の構成でさえ素晴らしい回復力を提供できるのです。

下の画像はNutanixPrismから取得した分析のスクリーンショットです。

ノード障害を想定してからのリビルド期間中のストレージプールのスループットを表示しています。

Nodefailurerebuildperformance

このチャートではリビルドが20:26にそして終了したのは20:46で完了までの間 9GBpsを維持している事がわかります。

この例では5年前のノードで5TBの利用率でデータの完全なリストアに20分以下となるのです。

クラスタサイズが増えるか 新しいノードが速いNICNVMeドライブのようなストレージを使われているのであれば、リビルドはもっと早くなりRF2を利用していてもデータロスの可能性はとても少なくなるのです。

NutanixではCVMでデータ保護をしているのでノードが増えても処理できるマシンが増えリビルドにかかる時間は減りますし、早いCPU等を搭載したモデルでもリビルドにかかる時間が削減されます。

イメージ的にはRAIDコントローラ処理速度もOne-Clickで!といったところですね!

Summary:

  • Nutanix RF2 is vastly more resilient than RAID5 (or N+1) style architectures
  • ADSF performs continual disk scrubbing to detect and resolve underlying issues before they can cause data integrity issues
  • Rebuilds from drive or node failures are an efficient distributed operation using all drives and nodes in a cluster
  • A recovery from a >5TB node failure (in this case, the equivalent of 6 concurrent SSD failures) can be less than 20mins

Next let’s discuss how to convert from RF2 to RF3 and how fast this compliance task can complete.

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

アクセスランキング

お問い合わせ先
ネットワールド ブログ運営事務局
blog.doc-info@networld.co.jp
フォトアルバム