2021年6月25日金曜日

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

みなさん、こんにちは

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

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

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

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

2.X-Rayを利用するときの構成

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

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

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

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

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

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

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

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

3.X-Rayのテストシナリオ

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

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

4.X-Rayの分析結果のダッシュボード



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

5.カスタムシナリオ

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

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

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

6.カスタムセットアップ

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

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

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

2021年6月23日水曜日

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

みなさん、こんにちは


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

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

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

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

1.DPIのイメージ


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

2.DPIの詳細


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

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

3.DPIの構成


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

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

4.マニュアル(手動)で解析するとどうなるのか?

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

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

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

5.パケット解析でわかること


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

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

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

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

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

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

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

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

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


2021年6月19日土曜日

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 

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

3. AOSのライフサイクル

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

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

アップグレードをチェックできるウェブサイトですが、以下のURLとなります。
https://portal.nutanix.com/#/page/upgradePaths
こちらで画面でSoftware TypesでAOSを指定して、現状のAOSバージョンを選択し、アップグレードしたいAOSバージョンを右側のBoxから選択すると、そのバージョンでアップグレード可能(SUPPORTEDと表示)かどうかが確認できます。

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

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に関してもライフサイクルの記載がありますので、ご利用されているお客様は定期的にアップグレードをお願いします。

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

2021年6月15日火曜日

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

みなさん、こんにちは


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

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

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

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


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

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

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


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

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

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

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


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

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

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

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


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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

よろしくお願いします。




2021年5月31日月曜日

ThinkAgile VXのAMDラインナップ

みなさん、こんにちは
本日はThinkAgile VXのAMD CPUが搭載されたモデルがリリースされたので、今回はその内容を紹介したいと思います。 

1.ThinkAgile VXラインナップ

今回リリースされたのはアプライアンス・認定ノード含めて以下の通りです

アプライアンスモデル:
    ThinkAgile VX3575-G (GPUモデル)
    ThinkAgile VX5575 (大容量モデル)
    ThinkAgile VX7575 (コンピュートモデル)

認定ノード:ThinkAgile VX 2U Node - AMD ⇒ ThinkAgile VX7576
                  (従来モデルはThinkAgile VX 2U Node - Intelになります) 

アプライアンスモデルについて上記3モデルでリリースされておりますが、認定ノードについてはフォームファクターごとに求められるので、今回は1つになります。
ただし、今回のAMD搭載モデルの認定ノードに関しては認定ノードであっても型番が振られており、ThinkAgile VX7576になります。

認定ノードについては、Intel/AMDで名称が異なるので注意が必要になります。

詳細スペックは以下のウェブページでも掲載されております。

それでは、前回のThinkAgile VXの記事と同様に、構成について説明していきたいと思います。(前回の記事は以下のURLをご参照ください)
https://tkomiya.blogspot.com/2020/12/thinkagilevx-vsan-sizer.html
https://tkomiya.blogspot.com/2020/12/thinkagilevx-vsan-sizer2vsan.html

2.ThinkAgile VX3575の構成

ThinkAgile VX3575-Gに関してですが、GPU搭載モデルのThinkAgile VX3520-Gと同様ですが、以下の2点が異なります。

・2.5インチの搭載本数が従来の16本から24本に増えている
・NVMeオールフラッシュ構成がサポート

その他サポートされているGPUの違いなどもありますが、そちらはスペックを見るとわかりますので、説明は割愛致します。

搭載本数が24本になってことから、キャパシティの本数が増えておりますので、イメージを見ていただければと思います。

ディスク構成について:キャパシティディスクの本数
1グループの場合:最大7本までサポート(最小は2本)
2グループの場合:最大14本までサポート(最小は4本)
3グループの場合:最大21本までサポート(最小は6本)
4グループの場合:最大20本までサポート(最小は8本)
5グループの場合:最大15本までサポート(最小は10本)

構成そのものはThinkAgile VX7520と同様です。例えば、アプライアンス構成でGPUをディスクを25本以上する場合は、アプライアンスでは選定できるモデルがありません。この場合、認定ノードのThinkAgile VX7576を選定する必要があります。

GPUを利用する際は是非注意して頂ければと思います。
vSAN Sizerなどでサイジングする場合は、VX7520と同様に実施して頂ければ対応可能です。

3.ThinkAgile VX5575の構成

ThinkAgile VX5575に関して、従来モデルのThinkAgile VX5520と同様ですが、以下の点が異なります。

・オールフラッシュ対応
・3.5インチで16本搭載可能
・ディスクグループが5つまでサポート

こちらの機種については、コンピュートのワークロードとしてはスペックが低いが容量の大きいワークロードに最適でありましたが、今回オールフラッシュをサポートすることで、コンピュート性能も必要なワークロードを動作させても問題はありません。ただし、vSAN Sizerなどではサイジングできない構成になっているため、コンピュートワークロードを搭載しすぎないように仮想マシンを配置する必要があります。

ディスク構成について:キャパシティディスクの本数
1グループの場合:最大7本までサポート(最小は2本)
2グループの場合:最大14本までサポート(最小は4本)
3グループの場合:最大12本までサポート(最小は6本)
4グループの場合:最大12本までサポート(最小は8本)
5グループの場合:最大10本までサポート(最小は10本)

上記のようなディスク構成になりますが、フロントが12本しか搭載できないため。残りの4本を搭載すると、背面のPCIスロットを利用するため、NICなどを搭載する場合に制限が出てしまいますので、ご注意ください。

4.ThinkAgile VX7575の構成
ThinkAgile VX7575に関してですが、ハイブリッド構成に関してはThinkAgile VX7520と構成は同じです。特に今までと変わりなく構成を組むことができます。

ただし、この機種に関してはオールフラッシュ構成において、今まで違う構成となります。
その理由として、こちらのThinkAgile VX7575については、ThinkSystem SR665のフォームファクターを利用しているため、オールフラッシュ構成におけるSSDの搭載できるスロットがハイブリッド構成に比べて多くなります。

写真のイメージが以下のURLに掲載されているので、ご参照ください。(Figure-8 Mid-chassis drive bays

ThinkAgile VX7575に関しては上記URL Figure-8 Mid-Chassis drive baysの2.5インチを利用しているため、SSDが35本・NVMeが32本搭載可能になります。
その構成を以下イメージで載せておきます。


ディスク構成について(SSD構成):キャパシティディスクの本数
1グループの場合:最大7本までサポート(最小は2本)
2グループの場合:最大14本までサポート(最小は4本)
3グループの場合:最大21本までサポート(最小は6本)
4グループの場合:最大28本までサポート(最小は8本)
5グループの場合:最大30本までサポート(最小は10本)

5グループ構成の場合、最大の35本まで搭載可能となります。
なお、こちらについては現状vSAN Sizerでサイジングできません。


ディスク構成について(SSD構成):キャパシティディスクの本数
1グループの場合:最大7本までサポート(最小は2本)
2グループの場合:最大14本までサポート(最小は4本)
3グループの場合:最大21本までサポート(最小は6本)
4グループの場合:最大28本までサポート(最小は8本)
5グループの場合:最大25本までサポート(最小は10本)

同様にこちらはNVMeの構成になりますが、4グループ構成時の32本が最大構成になります。
なお、こちらについては現状vSAN Sizerでサイジングできません。

5.ThinkAgile VX7576の構成

ThinkAgile VX7576については、冒頭にもお話した通り

アプライアンスモデル:
    ThinkAgile VX3575-G (GPUモデル)
    ThinkAgile VX5575 (大容量モデル)
    ThinkAgile VX7575 (コンピュートモデル)

上記3モデルを認定ノードにしたものになりますが、実はそれだけではありません。
ThinkAgile VX7576については、アプライアンスでは構成できないものがあります。
ThinkAgile VX7575の説明でFigure-8 Mid-Chassis drive baysがあったかと思いますが、VX7575では2.5インチしか選択できません。このVX7576においては、実は3.5インチも選択することができます。


ディスク構成について:キャパシティディスクの本数
1グループの場合:最大7本までサポート(最小は2本)
2グループの場合:最大14本までサポート(最小は4本)
3グループの場合:最大12本までサポート(最小は6本)
4グループの場合:最大12本までサポート(最小は8本)
5グループの場合:最大10本までサポート(最小は10本)

構成については、ThinkAgile VX5575と同様になります。
こちらについても、残念ながらvSAN Sizerでサイジングすることができません。

最後にコメントしますが、上記三つのモデルが一つの認定ノードになったこともあり、VX7575+GPUなどの構成も組むことができます。
アプライアンスモデルの方が見た目ラインアップとして覚えやすいのですが、実は認定ノードを意識して構成すると、柔軟な構成を選択することができますので、是非覚えておきましょう。

よろしくお願いします。

2020年12月25日金曜日

NutanixのROBO環境について

みなさん、こんにちは
本記事は、Nutanix Advent Calendar 2020の12月25日分としての投稿になります。

本日はNutanixのROBO環境についてのお話をしようと思います。
NutanixのROBO環境ですが、地方の拠点などのリモート環境で大規模なクラスター構成ではなく、3ノードまでのクラスター構成を環境です。

Nutanixが一般的に3ノードからと言われている中で、ROBO環境のメリットがあるのか?というところも含めて、ROBO環境のクラスターについて内容を説明したいと思います。

1.ROBO向けの1台構成について
1ノード構成の場合についてお話します。
1ノード構成の場合、1台の筐体内でRF2の構成を取ります。つまり、ノード内でメタデータおよび保存データを複数するため、本来必要とするデータ量の1/2となります。(RAID1と同様)
また、3ノード以上のスケールアウト型での拡張は考慮されていないことから、レプリケーションターゲットのような利用シーンが考えられます。通常の仮想化のノードとしては利用シーンもありますが、稼働させる仮想マシン数も少ない(冗長性も考慮しない)

参考程度にNutanixのNXシリーズとLenovoのHXシリーズでの構成可能なコンポーネントを記載しておきますが、NXシリーズは元々大規模なリソースを想定していないことから、CPUスペックは低いものしかラインナップしておりませんが、Lenovo社のスペックについてはROBOモデルでも最大28コアまでサポートされているCPUを搭載することができます。
ドライブ容量も12TBのNLSASは搭載可能ですが、本数も少ないことから高パフォーマンスのワークロードを想定しているものではありません。

2.ROBO向けの2台構成について
次に2ノード構成の場合についてお話します。

2ノード構成の場合、2台ノード全体でRF2の構成を取ります。つまり、一台のノードで障害が発生してももう一つのノードで動作するような仕組みになっております。つまり、HAの構成可能であるが、それだけであれば普通の仮想化環境と変わりません。実はNutanixの2ノード構成については振り舞いが異なる点があります。

データの冗長性についてお話します。メタデータはRF2ではなくRF4の仕組みで動いております。つまり、筐体内で複製も行いますが筐体外でも複製をおこなうため、実際メタデータ(SSD領域)に関しては余分に容量を見ておく必要があります。

つまり、ROBO環境においては仮想マシンの搭載台数も少なく、容量も少なめに構成されます。スケールアウトもできないことから、将来に向けてスケールアウトを拡張したいお客様は検討しないほうがよいと思います。

また、2ノード環境には構成する際にもう一つ必要なコンポーネントがあります。

3.2台クラスター環境にはWitnessサーバーが必須
2台のクラスター環境においては、それぞれのノードがスプリットブレーンを起こさないようにするために、2台のクラスターを外部から監視するサービス(Witness)が必要となります。Witnessサーバーを構築するためには、外部でNutanixのクラスターが必要となるため、2台のROBO用のクラスターを構築する前に本社もしくはデータセンター内に3台以上のクラスターを構築する必要があります。
Witnessサーバーは複数拠点のROBO環境を監視する機能があります。それ以外にWANの帯域幅、レイテンシなどの要件もありますので、WANで接続されているから構成できるわけではありませんので、環境をご確認の上で構成してください。
  • N個のクラスタに1台のWitness
  • WANの帯域幅、レイテンシ、可用性 に制限なし
  • 2ノードクラスタ上には構築不可
ROBO環境において、これ以上問題点はないのだろうか?と思いますが、さらに,
考慮点もございますので、次のイメージでご説明致します。

4.ROBOモデルおよびレプリケーションターゲットに関する仕様について
1ノード構成の説明時に
お話したレプリケーションターゲットに関連する内容をお話します。
1ノード/2ノード構成する際は機能制限があります。
  • スケールアウト(ノード増設)
  • Volumes
  • Metro Availability(メトロの可用性)
  • EC-X(イレージャーコーディング)
  • Deduplication(重複排除)
  • Hyper-V
スケールアウトに関しては先ほど記載しましたが、ブロックストレージのVolumesやMetro Availability、EC-X(イレージャーコーディング)や重複排除も未サポートになっています。
つまり、そのような制限がある場合に、3ノード以上のクラスターからそのままレプリケーションすると重複排除やイレージャーコーディングされたデータがあるクラスターから、そのままROBO環境の1,2ノードのクラスターにレプリケーションすることはできます。しかし、容量が削減されているクラスターから、容量を削減不可のクラスターへのレプリケーションになるため、容量を考慮して運用する必要がありますので、ご注意ください。

5.レプリケーションターゲットを考慮した増設に関して
また、レプリケーションターゲットを構成する際、イメージのように3ノードクラスターのバックアップとしてレプリケーションターゲットを構成するとします。
3ノードクラスター(ここではライセンスをStarterを想定
)の容量が大きくなり、バックアップ用のレプリケーションターゲットノードの容量が不足した場合、本来であればレプリケーションターゲット側をスケールアウトで構成したいと考えます。先ほど1ノード構成の際に説明した通り、スケールアウトで拡張することができません。そのため本番用のノード拡張に合わせてレプリケーションターゲットを追加する必要があります。このようにしてレプリケーションターゲットを増やすことにより増設対応できます。

ほとんどの人が、これで終わりだと思うところがあるのですが、またここで注意事項があります。

6.複数サイト(クラスター)へのDRはライセンスに注意
先ほどのイメージで本番サイトのエディションをStarterと書いてあったのがポイントです。Starterエディションの場合、1:1のレプリケーションを想定しております。そこで、複数のクラスターに対してレプリケーションを行う場合、Starterのライセンスでは対応できません。現状のNutanixにおいては、Proエディションで購入したライセンスに対しては、Advanced Replicationのライセンスが必要になります。(Ultimateライセンスであればそのまま利用可能)
このような話はレプリケーションターゲットに限ったお話ではありませんが、レプリケーションターゲットに関しては、陥りやすい罠となっております。

7.ROBOモデルの本来の利用用途
ROBOモデルの本来の利用用途は、本社もしくはデータセンターに導入したNutanixのクラスターのバックアップや支店などのサイトで利用する小規模のクラスターを構成することがz前提です。そのため、小規模クラスターだけを構築するためだけに導入するものではありません。
仮想マシン数が少ないからと言って、積極的に導入するものではないので、もし小規模でもNutanixを導入したいということであれば、是非小規模のモデルでも3ノードを構成可能なサーバーで購入した方が望ましいと思われます。

8.ROBOモデルは実用的ではない?
ここまで説明してきた内容からすると、ROBOモデルをオススメではないという結論になってしまいますが、今回は少し前向きな話をしたいと思います。
ROBOモデルも実は利用シーンを選べば活用できるモデルであります。それはIoTなどのエッジコンピューティングなど用途です。
エッジコンピューティングでは、エッジサイトで利用しているモバイルデバイスからデータを収集して、処理結果をクラウド上にアップロードしてビジネスに利用するケースがあります。(例えば、監視カメラなどで人などを感知して録画を撮り、人がいなくなったら録画を停止して、動画に情報を付加してクラウド上オブジェクトストレージに保存し、必要に応じて検索して閲覧する)
このような利用シーンであればで、稼働させる仮想マシンも少なく、時には冗長化も不要なケースもあります。
今回このような利用シーンに対応したNutanixのモデルがLenovo社からリリースされておりますので、ここでお話したいと思います。

今回お話するのは今月リリースされたLenovo社から発表されたThinkAgile HX1021になります。
こちらのモデルは昨年リリースされたエッジサーバーのThinkSystem SE350が今回Nutanix対応モデルとして発表されています。
こちらのモデルはエッジコンピューティングを前提にデザインされているため、AIなどの処理可能にするため、GPU(Tesla T4)が搭載されています。ThinkSystem SE350であればWiFiや5Gのモジュールもサポートされているのですが、今回のNutanix対応のHX1021に関しては、Wifiインタフェースおよび5Gモジュールは現状非対応となります。

詳細に関しては、Lenovo社のホームページに記載がありますので、そちらをご参照ください。
ThinkAgile HX1021の主な特徴は以下の3項目です。

  • 小規模環境の導入向け コンパクトなサイズのHCI 
  • グローバルに広がる エッジロケーションの コンシューマグレードの集中管理
  • エッジ環境での高信頼性があり、可用性を備えた安全で頑丈なシステム

ThinkAgile HX1021は1Uで2台のノードが搭載できるサーバーです。非常にコンパクトなボディにもかかわらず、ハイスペックなノードになっています。(コンパクトなボディではありますが、価格に関しては1Uサーバーより高額になる可能性があります)

ThinkAgile HX1021はリモートサイトに設置ちてもネットワークが接続されていれば、XCC(XClarity Controller)やPrismを利用してNutanixクラスターを管理することができます。

ThinkAgile HX1021はラック搭載しなくても利用することができるため、ノードそのものを盗難された場合に、ThinkShield SecureVaultでキー管理することでデータへの不正侵入や改ざんを防止することができます。

10.ROBOモデルにはROBO向けのライセンスを利用しよう
ROBOモデル向けには実はROBO向けのライセンスがリリースされております。
詳細はNutanix社のサイトに記載がございますが、簡単にこちらでもコメントしますと10VM以下の環境で利用する場合、ホストのCPUコアやフラッシュの容量などのスペックには関係なく利用可能なライセンスとなります。


そのため、テスト用途や今回のようなROBO環境では最適なライセンス体系になります。

最後にHX1021を2ノード構成する場合については、既存の3ノード以上のクラスター上にWitnessサーバーをデプロイして利用するようにしてください。

是非エッジコンピューティングなどを利用する際には、こちらの製品を選択することも検討してみてはいかがでしょうか。

以上、よろしくお願いいたします。