導入したHCI環境のパフォーマンスを調べてみよう！~Nutanix Benchmarkツール X-Rayのご紹介~

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのベンチマークツールであるX-Rayをご紹介したいと思います。
X-Rayは日本語に訳すと”X線”という意味になりますが、その名の通りレントゲンのように、Nutanixの中身がどのようになっているのかを調べるツールであるということです。まずは、X-Rayがどのようなシーンで利用するのか？をご説明したいと思います。

１．使用しているHCI環境が問題ないのか・・・

実際にNutanix環境を構築してみたものの、そのHCI環境が問題なく性能が出せているのか？仮想環境に何か悪影響を与えていないのか？実際に運用フェーズに移る前に確認しておきたいことがあるかと思います。
そこで、登場するのがベンチマークツールになります。通常のベンチマークツールはおれぞれのワークロードを想定して数値を自分でチューニングする必要があり、自分の好みに合うか合わないかがあると思います。こちらのX-RayはまさにNutanixの環境向けに作られたベンチマークツールと言っても過言ではありません。詳細は後ほど説明しますが、こちらのツールはNutanix以外にも他の仮想環境と比較しながらベンチマークの結果（シナリオが別途必要）を見ることができるようになっています。

２．X-Rayを利用するときの構成

ここでX-Rayについて少し説明致します。X-Rayはパフォーマンスを測定したい環境の外部から負荷をかけるツールになります。そのため、Nutanixの環境が一つしかない場合はご利用できません。VMwareの環境があればOVAファイルを展開することでX-Rayの仮想マシンが展開できます。（AHV用もあります）

X-Rayをインストールすると、いくつかの異なるシステムをテストおよび分析し、使用するための同等の情報を報告してくれます。
このアプリケーションは、実際のユースケースをカバーするテストシナリオを提供します。これらのユースケースはパフォーマンス、データの完全性、可用性などの領域が異なるため、ハイパーコンバージドプラットフォームに非常に適しています。

X-Rayのテストシナリオでは、次の領域がカバーされています。

注：X-Rayはターゲットごとに1度に１つのテストシナリオしか実行できません
注：X-Rayは4ノード未満のクラスターをサポートしていません

可用性
X-Rayのテストではワークロード中にハイパーコンバージドソリューションがノード障害をどのように許容するのかをテストします。一貫性のあるパフォーマンスと安定性により、システムの可用性と管理ファブリックの耐障害性がテストされます。

リアルなパフォーマンス
X-Rayはシステムのソリューションをテストして混在したワークロードを処理します。ソリューションには単一のノードでデータベースを実行し、複数ノードでVDIワークロードを同時に実行し、VMスナップショット、VDIブートストーム、VMプロビジョニング、および複数のワークロードまたは安定性を長期間にわたって混在させることができます。

機能セット
機能としてはVMプロビジョニング、重複排除、圧縮、VAAIサポート、ねいてぃj部VMレベルのレプリケーション、ワンクリックソフトウェア・ハイパーバイザーアップグレード、BIOS/ドライブ、複数のハイパーバイザーとの互換性、および同じソリューションによるハイパーバイザー間の移行および変換機能が含まれています。

データの整合性
データの整合性はデータの紛失や破損しないことが、ストレージデバイスやファイルシステムにとって重要です。このアプリケーションは停電時またはコンポーネント障害時のデータの安全性をテストします。

３．X-Rayのテストシナリオ

X-Rayのテストシナリオについてお話したいと思います。
X-Rayは通常は上記シナリオを用意しております。一般的なOLTP、VDI、DSSなどを用意していますが、これ以外にもカスタム化されたシナリオ（詳細は上のイメージをご参照ください）があります。X-Ray 3.0からはシナリオはオープン化されており、GitHubなどからダウンロードが可能です。

X-Rayでの出力結果を見てましょう。

４．X-Rayの分析結果のダッシュボード

良い結果と悪い結果を⾒⽐べるとわかりますが、負荷をかけたクラスタが正常であればIOPSも安定しますが、そうでなければ数値にばらつきが出ます。その原因を追究するためにも⼀度このツールを利⽤して環境を確認する必要があると思いますし、このツールを利用しないで本番環境でサービスインをして、パフォーマンスが足りません・・・など困らないようにならないためにも、X-Rayで事前に確認することも大切です。

５．カスタムシナリオ

カスタムシナリオについて説明したいと思います。

冒頭に他のHCIとの⽐較・・・という話もあったかと思いますが、他のHCIのシナリオは上記のURL(https://gitlab.com/nutanix/curie)にあります。URLにCurieという名前がついていますが、X線という名称がついていることを考えればキューリー夫⼈のことを指しているわけですね。

GitHubサイトのシナリオのフォルダとみるとYAMLのファイルがたくさんありますので、これらで必要なものをダウンロードして、X-Rayで設定すれば⾒ることができます。

６．カスタムセットアップ

こちらはファイルの中⾝になります。記載する内容はVMの種類やワークロードなどを設定するようになっています。

Nutanixセットアップして、本番前にX-Rayで負荷かけて環境チェックするのもよいと思いますので、是非一度お試しください。

よろしくお願い致します。

アプリ・ネットワー クの遅延をすぐに解決︕~DPI（Deep Packet Inspection） の機能紹介~

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

本日はDPI(Deep Packet Inspection)についてお話したいと思います。

よくあるトラブルの内容として、例えば「アプリケーションのレスポンスが悪いなぁ~」と思うことがあると思います。実際にその原因を調査するにもネットワークがボトルネックになって遅くなっているのか？それともサーバー側が遅いのかがわからないことがあります。その時に役立つのが今回紹介するDPI(Deep Packet Inspection)になります。

よく間違えるのは、APM(Application Performance Monitoring)を間違えてDPIを言われる方がいらっしゃいますのが、意味が違いますので十分注意して頂きDPIの機能を紹介したいと思います。

１．DPIのイメージ

DPIのイメージは上図のような感じになります。簡単に言うとネットワーク上でどのようなパケットが流れていて、そのパケットがどのように利用されているのかを分析するものです。例えば、社内用にPCから社内ネットワークを利用してSNS接続をしているアプリケーションやYouTubeのような動画サイトを閲覧してネットワークに不可を与えているケースなどが挙げられるかと思います。DPIはまさにネットワーク上で流れているパケットを詳細に分析して遅延の原因を特定できるようにするものだと思って頂ければと思います。

２．DPIの詳細

DPIの詳細に触れますが、上段のWikipediaの説明の方がネットワークに詳しい方は分かると思いますが、もう少しわかりやすくするために図にしてみました。

今までネットワークにおける障害を調査するにあたり、IPやTCPの情報でどこに流れているトラフィックがポート番号を⾒て識別することをやっていました。現在はHTTPでも様々はアプリケーションを動作しているため、ポート番号だけではどんなものが流れているのが分からないため、英語で⽰すとおりDeep（深く）パケットを調べることで詳細を把握することができます。つまり上図で言うところのアプリケーションデータ部分までしっかり分析することが原因の特定のつながります。

３．DPIの構成

DPIについて詳細を述べてきたものの、実際にどのような構成になるのか？と疑問に思う人がいるかと思いますので、わかりやすくイメージ化してみました。

クライアントからサーバーまでの通信をキャプチャを⾏います。分析をする端末（アナライザー）がクライアント〜サーバー間でパケットを収集できるようにしなければなりません。この場合、ネットワークが流れるスイッチにおいてクライアントが通信するポートに対して、通信ポートを（パケットキャプチャ用に）ミラー化する必要となります。こちらを設定していればアナライザーで分析を⾏うだけです。

４．マニュアル（手動）で解析するとどうなるのか？

パケット解析するソフトウェアについては、昔はsniferなどがありましたが現在はWireSharkが⼀番有名なソフトウェアだと思います。こちらを利⽤してパケットを⾒ることが出来ますが、ネットワークに流れるパケット量は通常は⽬で監視できるレベルではないほどに多いことと、パケットでフローを分析するにはネットワークに精通しているエンジニアでないと解析に時間を要することになります。

そのため、このようなケースではDPI⽤に処理できるようなソフトウェアを購⼊する必要がありますが、⾮常に⾼価になる可能性が⾼いです。

筆者の利⽤したことがDPIソフトウェアとしてはSolarwinds社のNPMという製品がありますが、製品そのものは⾼価ではないがかなりネットワークのことが理解していないと設定が出来ない製品となっております。

５．パケット解析でわかること

パケット解析を⾏うことでアプリが遅くなることの解決策についてお話したいと思います。パケット解析で分かることは上記内容ですが、ここで重要なのはネットワークの応答時間・アプリケーションの応答時間が分かります。また、クライアントが通信しているターゲットとそのプロトコルなども分かりますので、最終的にはネットワークが問題なのか︖アプ

リケーションなのかが判別できるところまで可能にします。

６．ネットワークレスポンス(NRT)の測定

アナライザーがネットワーク応答時間を測定することになるのですが、実際にTCPの3Wayハンドシェイクについて少し説明したいと思います。

クライアント〜サーバー間で通信するときには、このようなやり取りがあるわけですが、実際にネットワークレスポンスタイムがどの部分にあたるのかというと、RTT(Round Trip Time)に相当するところになります。ここについてはあくまでネットワークのみで応答時間を算出することになりますが、次にサーバ側のアプリケーションも含めて応答時間に⽬を向けてみましょう。

７．アプリケーションレスポンス(ART)の測定

こちらはアプリケーションの応答時間の測定についてです。クライアント側からサーバー側にGETの要求を送信して、最終的にサーバー側にパケットを送り始めるまでの時間がARTになります。サーバの応答が遅い場合には明らかにサーバを疑えばよいし、ネットワーク応答が悪い場合にはネットワーク側を調べればよいということになりますので、ネットワーク管理者とサーバ管理者とのたらいまわしもせずにトラブルシューティングが出来るようになります。

実際にこれがどのような出⼒結果については、先ほどコメントしたSolarwinds社のイメージがホームページ上にありましたので、リンクを貼り付けておきますので、参考程度に⾒ていただければと思います。

https://support.solarwinds.com/SuccessCenter/servlet/rtaImage?eid=ka12J000000kK1f&feoid=00N5000000AcxPm&refid=0EM2J000000ysRj

左側に出⼒されているのがApplicationResponse Time(ART)の内容で、右側がNetwork Response Time(NRT)の内容となります。

障害は発見に時間がかかることがあり、それに伴い障害復旧にも時間を要することが多々あります。そのようなときにこのようなお話を理解しておくことで、障害時に切り分けを迅速に行うことができます。

是非ご参考にしていただければと思います。

AOSのサポートポリシーについて

 みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

本⽇はNutanixのAOSのサポートポリシーについてお話したいと思います。
今後Nutanixを運用する際のAOSライフサイクル管理に是非お役に立てればと思います。

1. LTSとSTSについて

NutanixのAOSは2種類のサポート期間でソフトウェアのライフサイクルが提供されています。

新機能を備えた短期サポート（STS）【Short Term Support】のリリース：
定期的なアップグレードパスを提供します。すべての機能リリースバージョンのサポートはリリース日から6ヶ月間のみ有効で、その期間内に次の機能リリースバージョンにアップグレードする必要があります。

長い期間サポートされている長期サポート（LTS）【Long Term Support】のリリース：
主に特定のリリースファミリで長時間にわたってバグ修正を提供します

STSを利用するお客様は、主に検証環境などで新機能をいち早くテストしたいお客様で何度も環境をアップデートすることができるお客様に適しており、逆にLTSは本番環境で長期間サポートされるプラットフォームでアップデート後は基本次のLTSのバージョンまでそのまま利用するお客様に適しております。

日本のお客様の多くは、LTSのバージョンのリリースを待ってアップデートすることが多いと思います。

また、バージョンアップについては、常に新しいバージョンを適用する必要があり、ダウングレードはサポートされません。
バージョンアップは該当のバージョンに必ずしも一回でアップグレードできるわけではありません。アップグレードパスを確認できるURLもございますので、アップグレードを行う際は必ず以下のURLをご参照頂きますようよろしくお願いします。

https://portal.nutanix.com/#/page/upgradePaths

2. Nutanix AOSソフトウェア EOLスケジュール

2021年6月現在でリリースされているAOSソフトウェアのEOLスケジュールを記載致します。STS最新バージョンの6.0.ZおよびLTS最新バージョンの5.20.Zにおいて、「End of Maintenance」「End of Support Life」が記載されておりませんが、次期バージョンがリリースされてから、両項目のスケジュールが記載されることにあります。（以下のドキュメントを参照）

http://download.nutanix.com/misc/AOS_EOL/AOS_EOL.pdf　

注１：“End of Maintenance”および“End of Support Life”の記載については、その月末までがサポート範囲
注２：“End of Support Life”を過ぎたバージョンはワンクリックダウンロードが無効になります
注３：拡張子がついているリリースの場合、表の日付には拡張子は含まれます

3. AOSのライフサイクル

２で記載したEOLスケジュールを図式化したものになります。ソフトウェアリリース状況によりSTSの期間が長くなったりすることがあります。詳細はEOLが記載されているPDFファイルをご参照ください。

4. アップグレードパスについて

アップグレードパスについて、一部バージョンについて記載しております。

これでわかるように、最新のSTS/LTSバージョンにアップグレードできるものとできないものがあることがわかります。NutanixのLCMでどのバージョンにアップグレードできるのかは画面上に表示されますが、事前にウェブサイトでチェックすることをオススメします。

アップグレードをチェックできるウェブサイトですが、以下のURLとなります。
https://portal.nutanix.com/#/page/upgradePaths

こちらで画面でSoftware TypesでAOSを指定して、現状のAOSバージョンを選択し、アップグレードしたいAOSバージョンを右側のBoxから選択すると、そのバージョンでアップグレード可能(SUPPORTEDと表示)かどうかが確認できます。

表示結果として出てきたアップグレードについては、１クリックアップグレードが対応しております。

5. アップグレード手順について

アップグレード手順については非常にシンプルです。Prismの画面で右上の歯車をクリックし、左側のSettingのメニューで「Upgrade Software」を選択します。
右側の画面でAOSについて、どのバージョンへアップグレードできるのかが表示できます。こちらで、アップグレードするバージョンのソフトウェアをダウンロードすることでアップグレードを行うことができます。

アップグレードしたいバージョンのAOSを選択してInternet経由でAOSのイメージダウンロードしてオンラインでアップグレードする⽅法とAOSのイメージとAOSにMETADATAをアップロードしてオンラインでアップグレードする2種類があります。

オンラインのアップグレードについては、主にインターネットに接続されていない環境で利⽤します。

6. Prism Central / Nutanix Filesのサポート期間

現在はPrism CentralおよびNutanix Filesについてもサポート期間が明記されております。Prism Centralにおいては、2020年7月のリリースされたソフトウェアからバージョン管理が変更されております。AOS以外のソフトウェアのアップデートに関しても注意して運用しましょう
Nutanix Filesに関してもライフサイクルの記載がありますので、ご利用されているお客様は定期的にアップグレードをお願いします。

Prism Central: http://download.nutanix.com/misc/PC_EOL/PC_EOL.pdf

Nutanix Files: http://download.nutanix.com/misc/FILES_EOL/FILES_EOL.pdf

よろしくお願い致します。

HCIの容量増設時の注意事項について

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

本日投稿する内容は、HCIの容量増設時における注意事項について説明したいと思います。

⼀般的なHCIにおいて、リソースを増やす場合にノードを追加すると思います。ただし、ノードの増設⽅法によってはリソースを有効的に利⽤されないこともあります。そのため、今回は容量増設において注意点も含めてお話したいと思います。（今回は容量は効率的に利⽤されますが、運⽤上知っておいた⽅がよいお話になります）

1. HCIリソースが少なくなった場合のノード追加

HCI環境においてCPUおよびメモリリソースが不⾜した場合、通常はノード増設で対応すると思われます。こちらのイメージのようにHCIを構成しているクラスタに対して、ノードを追加することで、CPUおよびメモリリソースは追加されます。ホスト単位で利⽤可能なリソースは限られるもののクラスタ全体としては、CPUおよびメモリリソースが追加されているので特に問題ありません。また、異機種混在であっても、追加ノードのCPU・メモリリソースだけが多くなるだけで利⽤する分には問題ありません。（HAなどでリソース不⾜があった場合、仮想マシンが⽴ち上がらない場合はありますが、通常利⽤では問題ありません）

ただし、これがストレージのリソースについて、同様のことが⾔えるのかどうか説明したいと思います。

2. ストレージ容量を増設する場合

ストレージ容量を増やす場合、普通に追加作業するだけで果たして問題ないだろうか︖

実際に各社のHCIの仕様は様々でありますが、今回はNutanixのアーキテクチャを元にお話したいと思います。

イメージで確認する限り問題ないように思えますが、ここでNutanixのストレージの仕様について⼀度整理してみましょう。

３. データローカリティについて

まずまじめに、Nutanixのストレージアーキテクチャの基礎となるデータローカリティについて、お話したいと思います。

データローカリティにおいてホスト上の仮想マシンはホスト上のCVMを経由して、ローカルホスト上のSSDにデータを書き込みます。書き込み後はデータの冗⻑性を保つために、RF2であれば、他のホストにデータをコピーします。（RF3であれば２つのホストにコピー）

つまり、データをクラスタ内に⼆つが存在する状態がHCIであるべき姿になるため、これを踏まえて、ノード増設した場合にどのような動きになるのかを整理してみたいと思います。

4. 1台しか増設しなかった時のストレージ容量について

クラスター増設を1台しかしなかった場合において、二つのケースが考えられます。

・同⼀スペックでストレージ容量を増設した場合
・異なるスペックでストレージ容量を増設した場合

同⼀スペックでストレージ容量を増設した場合、Nutanixのクラスタ内で増設したノードの容量も含めてクラスタで管理している容量が⼤きくなる時にクラスタ内でデータが再配置されます。この時、クラスタ全体にデータが均等化して配置するようにNutanixが動作します。つまり同⼀スペックで増設するのであれば何も問題なく動作します。

それでは、異なるスペックでストレージ容量のノードを増設した場合はどのような動作をするのだろうか考えてみましょう。

例えば、はじめは1Uのラックサーバーで容量を少なく導⼊したものの、ストレージ容量が⾜りなくなり、2Uのノードを増設した場合はどうなるでしょうか︖

実際に同⼀スペックで増設した時と同様に2Uノードを追加した場合にもNutanixが均等にデータを再配置を⾏いますが、異なるスペックの場合、⽔⾊の部分も含めて均等にデータを再配置してくれるのでしょうか︖

5. 異なる容量を追加した時のデータの分散について

Nutanix Bibleに異なるスペックを増設した場合の動作について、イメージのように内容で書かれています。

NutanixはCuratorにて⼀定の閾値をもって動作しています。
その閾値を超えてデータの均等化がされていないことが判明した場合に、Curatorにて異なるスペックのノードとディスク使⽤率を⾒て容量のバランシングを⾏います。その場合にアクセス頻度が低いデータを他のノードに移動させようとします。これにより、ストレージ容量が⼤きいノードが増設された場合においても、均等化を図ろうとしてデータの再配置を⾏います。

異なる容量のノードを増設しても動作上何も問題はありません。

ストレージ専⽤のアプライアンスでも同様のことが⾔えます。ストレージ専⽤ノードの場合、ストレージ専⽤ノードにはCVM以外の仮想マシンは載せてはいけないことになっているため、基本的には他のノードのコールドデータ（アクセス頻度の少ないデータ）がストレージ専⽤ノードに保存されるようになります。

ここで、異なるスペックのノードを増設しても問題ないことはわかったが、容量の⼤きいノードが障害起きた場合はどうなるのか︖について考えてみましょう。

6. ノード障害はどうするの？

容量のバランシングで容量の⼤きいノードに⼀番多くデータが保存されることもあります。その時に、容量の多いノードが障害あった場合に他のノードで容量を受けきれない場合もあります。もちろんこれはサイジング上のお話もあるかと思いますが、基本ルールとして覚えていたほうがよいのは、障害が起きた場合にはデータの受け⽫として受け⼊れられるだけの容量を確保することが重要です。

7. 同一スペックのノードを増設時にもう1台購入

増設時にもう1台（2台以上）の増設ノードがあれば、障害時も問題なく運⽤できます。もちろんこれは予算の限りであると思いますが、ストレージ専⽤アプライアンスを購⼊した場合にはこの話を理解しておかないと容量だけ⾜せばよいという意⾒にもなりかねないため、是⾮頭に⼊れておいた⽅がよいと思います。

よろしくお願いします。