2021年7月2日金曜日

Nutanixの⽤語を覚えてみよう!〜Nutanix の構成要素について 〜

みなさん、こんにちは

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

本日はNutanixの基本的な概念である、Nutanixの構成要素についてご紹介したいと思います。

Nutanixを覚えようとする人は、Nutanix Bibleなどを読まれるかと思いますが、こちらの内容も是非参考にして頂ければと思います。

1.Nutanixの用語について

Nutanixを構成する⽤語ついて、上記のイメージのようなものがございます。
それぞれの用語について説明していきたいと思います。

  • ノード

    ノードはNutanixクラスタの基本単位になります。各ノードは標準ハイパー    バイザー
    を実行し、SSDとHDDストレージの両方で構成されたプロセッサー、メモリおよび
    ローカルストレージを含むます

  • ブロック

    ブロックは最⼤4つのノードを含むNutanixラックマウント型ユニットです。
 
(2U4Nodesの⾼密度サーバーが対象になります)

  • クラスタ

    クラスタはAcropolis Distributed Storage Fabric(DSF)を形成するNutanixブロックと
    ノードのセットです。

  • データストア

    データストアは仮想マシン操作に必要なファイル論理コンテナです。

  • vDisk

    vDiskは仮想マシンにストレージを提供するコンテナ内の使⽤可能なストレージの
    サブセットです。コンテナがNFSボリュームとしてマウントされている場合、そ
    コンテナー内のvDiskの作成および管理
はクラスターによって⾃動的に処理されます。

  • コンテナ

    コンテナはストレージプールの論理的なセグメンテーションで、仮想マシンまた
    ファイルのグループ(vDisk)を含みます。コンテナは通常、NFSデータストアまたは
    SMB共有の形式で共有ストレージとしてホストにマッピングされます。

  • ストレージプール

    ストレージプールとは、クラスタ⽤のSSDやHDDなどの物理ストレージデバイスの
    グループです。
ストレージプールは複数のNutanixノードにまたがることができ、
    クラスターの規模が拡⼤するにつれて拡張されます。

  • ストレージティア

    ストレージティアでは、MapReduce階層化テクノロジーを利用して、データを最適な
    ストレージ階層(フラッシュまたはHDD)にインテリジェントに配置し、最速の
    パフォーマンスを実現します。

  • ラック(フォールトトレランス)

    ノード/ブロックをもう少し拡張したラック(フォールトトレランス)という概念も
    あります。


ラックフォールトトレランスはラックレベルの可用性ドメインを提供する機能です。
ラックの耐障害性により、データの冗長コピーが作成され同じラック内にないノードへ配置されます。ラックフォールトトレランス機能が有効になっている場合、クラスタはラック認識機能を備えており、1つのRack(RF2)または2つのRack(RF3)の障害でゲストVMを稼働させ続けることができます。
1つのRackに障害が発生すると、ゲストVMデータとメタデータの冗長コピーが他のRackでも存在します。

2.ノードについて

仮想マシンのホストのことを指しますが、Nutanixは通常のラックサーバと⾼密度のサーバーで構成されるため、それぞれのハードウェアでわかりやすく⽰してみました。⾼密度サーバーでは、筐体の中に収納されている⼀台のサーバーになります。

また、クラスタの基本単位はNutanixノードです。クラスタ内の各ノードは業界標準のハイパーバイザーを実行する標準x86サーバーで、低遅延SSDと経済的なHDDの両方で構成されるNutanixコントローラVM、プロセッサ、メモリ、およびローカルストレージを含みます。ノードは10GbEネットワークを介して連携して、NutanixクラスターとAcropolis Distributed Storage Fabric(DSF)と呼ばれる分散プラットフォームを形成します。

3.ブロック・クラスタについて

ブロックについては先に説明した通り、⾼密度サーバーのみに適応される概念です。4ノードを⼀つのブロックとして扱います。もちろん、筐体障害の場合はシステム停⽌になったりします。そこで、複数の筐体にまたがってデータを格納する⽅式(Block Awareness)を採⽤することが多いです。

4.Prism上での画面イメージ

Prism上からの画⾯で説明します。ハードウェアのメニューからDiagramを選択するとNutanixのクラスタを形成しているハードウェアが表⽰されます。(今回は2U4Nodeの筐体に3台分しか表⽰されておりませんが)

今回の構成では、クラスタとブロックが同じ枠で囲われておりますが、ノード数が多ければクラスタは組んでいる構成で表⽰されます。

⻘⾊で表⽰されているところはDiskになりますが、コンポーネントに障害が起きていれば、該当のパーツが⾚く表⽰されます。

5.Distributed Storage Fabric

Nutanixのノードがグループとなって、分散ストレージファブリックを形成されます。この分散ストレージがハイパーバイザーを動作させる基盤になり、またI/Oはローカルで処理された後に、データの冗⻑化を保つためにデータを分散配置します。

6.データの構造

DSFのデータ構造はこのようなイメージで構成されます。物理ディスクグループのストレージプールを作成され全体の容量が定義されます。そこからコンテナを定義して使⽤可能な領域を定義して、コンテナ内にvDisk(仮想マシン⽤の領域)を割り当てます。こちらについては、ハイパーバイザーによって、サポートするプロトコルも異なりますので、ご注意下さい。AHVについてはiSCSIになります。

ストレージについて画⾯イメージをこちらに載せておきます。ストレージメニューからTableを選択します。ストレージプールを選択すると、テーブル情報とサマリ情報が表⽰されます。こちらで、ストレージプールやコンテナの情報が確認できます。また、データをExportすることもできます。

以上で、Nutanixの構成要素の説明を終わります。

よろしくお願いします。

2021年7月1日木曜日

Nutanix Guest Toolsについて

みなさん、こんにちは

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

今回はNutanix Guest Tools(以下NGTと省略させて頂きます)をご紹介します。

VMwareなどをご利⽤されている⽅は(VMware Tools)ご存知かと思いますが、同様の機能でサービスとモジュールのセットです。このNGTを利用することにより、Nutanixの中で様々な機能を利⽤できるようになり、仮想マシンの管理性を向上させることができ、ユーザーとのシームレスなやりとりができるようになります。

1.Nutanix Guest Toolsとは?

NGTの機能は主に以下の5つの内容になります。

  • Nutanixゲストエージェント(NGA)サービス
  • ファイルレベルリストア⽤のCLIの提供
  • Nutanix VMモビリティドライバの提供
  • Windows VM⽤のVSSリクエスタとハードウェアプロバイダ
  • Linux VM⽤のアプリケーション⼀貫性のあるスナップショット

NGTをインストールし、CVMと通信可能にすることで機能を連携できるようにします。
VMのスナップショットからセルフサービスのリカバリ(ファイルレベルの復元とも呼ばれます)機能により、仮想マシン管理者の介⼊を最⼩限に抑えてNutanixデータ保護スナップショットからセルフサービス回復を実⾏できます。NGTを有効にして、VMにログインしてゲストVM管理者がディスクを接続すると、ゲストVM管理者はゲストOS内のファイルを回復できます。ゲストのVM管理者がディスクの切り離しに失敗した場合、24時間後に⾃動的にVMから切り離されます。

ESXiとAHV間のVMマイグレーションのためのドライバ、インプレースハイパーバイザ変換、およびクロスハイパーバイザディザスタリカバリ(CHDR)機能を提供することによってサポートします。NGTをインストールすることにより、クロスハイパーバイザディザスタリカバリ(CHDR)は、スナップショットからVMの保護、スナップショットの作成、スナ
ップショットの複製、およびVMの復旧という保護ドメインを使⽤することにより、あるハイパーバイザから別のハイパーバイザへのVMの移⾏(ESXiからAHV、AHVからAHVへの移⾏)できるようになります。

AHVまたはESXi Windows VMのアプリケーション⼀貫性のあるスナップショットを有効にします。NGTがVMにインストールされる前に作成されたハイパーバイザベースのスナップショットからNGTを実⾏しているVMが復元されると、VMはNGTなしで復元されます。

仮想マシン静⽌時に特定のスクリプトを実⾏することによってLinux仮想マシンのアプリケーション整合のスナップショットをサポートします。WindowsとLinuxのNGT対応の詳細については以下をご参照ください。

2.Nutanix Guest Toolsの要件と制限
NGTを使⽤するすべての機能は、次の要件を満たす必要があります

一般的な要件と制限
  • 仮想IPアドレスはNutanixクラスタで設定する必要があります。クラスタの仮想IPアドレスが変更されると、 クラスタ内で実⾏されているすべてのNGTインスタンスが影響を受けます。
  • VMにはISOを添付するための空のIDE CD-ROMスロットが少なくとも1つ必要。
  • NGT-Controller VMサービスと通信するには、ポート2074を開いておく必要があります。
  • ハイパーバイザー︓ESXi 5.1以降のリリース、AHV(20160215以降のバージョン)
  • VMはクラスタの仮想IPアドレスを使⽤してアクセスできるネットワークに接続する必要があります。
  • Windows Server版VMの場合、NGTのインストールを開始する前にMicrosoft VSSサービスが有効になっていること。
  • VM IQNを変更し、NGTのリフレッシュサイクル(現状5分)が発⽣する前に、VMのスナップショットを作成すると、 スナップショット操作がVM-VG接続をキャプチャできないため、NGTは⾃動復元機能を提供できません。 この問題を回避するには、Linux VMで$sudo service ngt_guest_agent restartコマンドを実⾏し、Windows VMのサービスタブでNGTを更新することでnutanixゲストエージェントサービスを⼿動で再起動できます。
  • PowershellのパスはNGTのインストール環境で利⽤できる必要があります。それ以外の場合、NGTのインストールは失敗します。
  • Linuxオペレーティングシステムの場合、NGTは/ usr / localにインストールされます。したがって、ユーザーにこの場所に対する書き込み権限があることを確認する必要があります。
オペレーティングシステムが特定の機能に対してサポートされているかどうかを確認するには、特定のNGT機能について、サポートされているオペレーティングシステム情報を参照。
その他の制限については以下に掲載しておきます。
Nutanix導⼊後は仮想マシンにNGTの導⼊を忘れずにお願いします。

よろしくお願いします。

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などの構成も組むことができます。
アプライアンスモデルの方が見た目ラインアップとして覚えやすいのですが、実は認定ノードを意識して構成すると、柔軟な構成を選択することができますので、是非覚えておきましょう。

よろしくお願いします。