ADS(Acropolis Distributed Scheduler)およびAffinityポリシーについて

みなさん、こんにちは

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

今回はAcropolis Distributed Scheduler（以下ADSと省略させて頂きます）をご紹介します。

本機能については、VMwareのことをご存知の⽅はお気づき⽅と思いますが、こちらはDRS(Distributed Resource Scheduler)と同様の機能だと思って頂ければと思いますが、機能は非常にシンプルになっています。

1. Acropolis Distributed Scheduler(ADS)について

ADSの実現することは以下の通りです。

仮想マシンの初期配置

• 新しい仮想マシンを最適なホストに配置する

ホスト内のリソースの競合を避ける

• CPU（ホストのCPUが閾値85％を超えると移行が始まる）
• ストレージコントローラ（CVMのCPUが閾値を85%をStargateに利用されてしまうと移行が始まる）Nutanix Volumesも対象
• ルール違反のスケジューリング
  
• vGPUについてもAOS 6.0から対象となる

ホットスポットを検出するインテリジェントシステム

• ホットスポットの回避
• ワークロードの変化に反応しない
• ワークロードに必要なリソースを確保
• オペレータの介入なし
• 負荷分散しない

仮想マシン間のアンチアフィニティポリシー

• 異なるホスト上で仮想マシンの分離を保証

プロビジョニングした仮想マシンを最適なホストに配置して、ホスト内のリソース競合を避けるようにすることが目的であり、VMwareのDRSのように細かく設定を行うことはありません。アフィニティポリシーについても非常にシンプルなものとして設定可能になっています。

また、仮想マシン起動時の初期配置および15分間隔で状態をチェックします。

異常が見つかった場合は、次の方法で修復します。

1. 仮想マシン移行計画
2. Nutanix Volumes iSCSIセッションの再指示

異常検出

• 15分ごと
• ホストリソースが過負荷になっていないかを確認する
• 潜在的に十分なリソースを獲得できない仮想マシンがないかチェック
• ポリシーに違反していないかどうかをチェック

需要予測

• 競合するノード上のリソースの需要予測が困難
• 統計は現在どのくらいの割合で取得しているのか指定
• 現在の値を選択すると、移行がたらいまわしにされる可能性があります
• 現在の解決策はコンバージェンスがより迅速になるように固定比率（+20%）で需要を拡大すること

ストレージCPUの計算

• Stargateはスレッドカウンターを発行
• 各vdiskコントローラが費やした時間を指定（vdiskにマップされます）
• vdiskカウンタは対応する仮想マシンおよびSoSANを体解っとに集約
• StargateのCPU使用率に基づく割り当て
• Storage CPUが通常の仮想マシンCPUに追加
• I/Oヘビーな仮想マシンをコンピュートヘビーノードへの移行を妨げます
• ハイパーコンバージド環境での特定が重要

VMwareのDRSと異なり、仮想マシンと合わせてストレージパフォーマンスをモデル化しません。固定化されている機能であるため、特別にカスタマイズすることなく利用できます。

2. Affinity Policy for AHV

Acropolisの管理対象クラスターの管理者として、AHVクラスター上の仮想マシンのスケジューリングポリシーを指定できます。これらのポリシーを定義することで、クラスタ内のホスト上の仮想マシンの配置を制御できます。

これらのポリシーを定義することで、クラスタ内のホスト上の仮想マシンの 配置を制御できます。 2種類のアフィニティポリシーを定義できます。以下の内容を紹介します。

• VMホストアフィニティポリシー
• VM-VMアンチアフィニティポリシー
• アフィニティルールの制限

3. VMホストアフィニティポリシー

VMホストアフィニティポリシーはVMの配置を制御します。このポリシーを使⽤して選択したVMがアフィニティホストリストのメンバー上でのみ実⾏できるように指定できます。

このポリシーは、ユーザーがVMの電源を投⼊したとき、またはVMを移⾏したときに、VMをどこにホストできるかを確認して適⽤します。

注意︓

• VMホストアフィニティポリシーを適⽤することを選択した場合、アフィニティポリシーの要件に適合しないホストに 仮想マシンをパワーオンまたは移⾏できないように、Acropolis HAおよびAcropolis Distributed Scheduling（ADS）が 制限されます。この⽅針は強制的に施⾏されているため。
• VMホストのアンチアフィニティポリシーはサポートされていません。
• 以前のAOSリリースでは、ホストアフィニティ設定で構成されたVMはVMが新しいクラスターに移⾏されてもこれらの設定を保持します。通常、これらのVMの電源を⼊れようとしても失敗しました。このようなVMは、CBRに対応していない（バックアップとリカバリが可能）、保護されていない、保護ドメイン操作の⼀部として移⾏されていないなどのタグが付けられました。このVMタイプを選択すると、Webコンソールのメッセージが表⽰されます。このVMは バックアップとリカバリに対応していません。
  考えられる理由︓VMとホストのアフィニティが設定されている。

VMの作成またはアップデート操作中にPrismを使⽤して、VMとホストのアフィニティポリシーを定義可能

4. VM-VMアンチアフィニティポリシー

このポリシーを使⽤して仮想マシン間の⾮アフィニティを指定できます。VM-VMのアンチアフィニティポリシーでは、1台のホストで問題が発⽣したときに両⽅の仮想マシンを 失うことがないように、指定された仮想マシンを区別します。しかし、これは優先的な⽅針です。 このポリシーは、リソースの制約が発⽣した場合にAcropolisの動的スケジューリング（ADS）機能が必要な措置を講じることを制限するものではありません。

注意︓

• 現時点では、aCLIを使⽤してのみVM-VMのアンチアフィニティポリシーを定義できます
• VM-VMアフィニティポリシーはサポートされていません
• アフィニティポリシーが設定された仮想マシンのクローンが作成されている場合、ポリシーはクローン作成された仮想マシンに⾃動的には適⽤されません。ただし、VMがDRスナップショットから復元されると、ポリシーは⾃動的にVMに適⽤されます

5. アフィニティ ルールの制限

• ホストがクラスタから削除されても、ホストUUIDはVMのホストアフィニティリストから削除されません。
• 予約ホスト⽅式を使⽤してHAが構成されているクラスタでは、VMホストアフィニティを構成できません。
• 電源がオンになっているVMのVMホストアフィニティをPrismから削除することはできません。acliコマンドを使⽤してこの操作を実⾏できます。
  vm.affinity_unset vm_list

ここで、Affinityルールの設定をPrismの画⾯とacliで紹介したいと思います。

Nutanixのクラスタで1ホスト内でExchangeとSQLが動作している場合に、これらを同時に1ホストで動かさない設定（AntiAffinity）を設定したいと思います。

まずは、ExchangeのVMにおいて、Affinity設定を⾏います。VMのメニューからUpdateを選択して、Set Affinityをクリックして、動作するホストを選択します。

同様にSQLのVMについても同様の設定を⾏います。

ここで、⼀度SQL VMのマイグレーション設定を確認します。マイグレーションをクリックすると⻘い枠に注意書きがあり、先ほど設定したAffinityルールが適応されていることが確認できます。その後マイグレーションできるホストに関しても⾃動で移⾏する設定とホストA/Bが表⽰されています。

ここで、acliを利⽤してAntiAffinityの設定を⾏います。SSHでCVMにログインして設定します。以下は⼀例を記載します。

nutanix@NTNX-*******-A-CVM:~$ acli

<acropolis> vm_group.create SQL_Exch

<acropolis> vm_group.add_vms SQL_Exch vm_list=SQL,Exchange

<acropolis> vm_group.antiaffinity_set SQL_Exch

こちらを設定後にPrismの画⾯をしばらく⾒ていると、AntiAffinityを設定された条件でSQL VMがホストBにマイグレーションされることがわかります。

ここで、タスク画⾯にADS: Remove Resource Contentionと表⽰されます。

つまりリソースの競合を排除するという話になります。

Acropolisの管理対象クラスターでは、Acropolisの動的スケジューリング(ADS)機能により、 ⼀定期間にわたるコンピューティングおよび/またはストレージのI/Oの競合またはホット スポットについてクラスターを予防的に監視します。問題が検出された場合は、移⾏計画が 作成されて実⾏され、VMをあるホストから別のホストに移⾏することで、クラスタ内

の ホットスポットが排除されます。この機能は現在進⾏中の競合のみを検出します。これらの タスクは、Prism Webコンソールのタスクダッシュボードから監視できます。VMリンクを クリックして、移⾏先（AHVホストへの）移⾏パスを含む移⾏情報を表⽰できます。

ADS機能のその他の利点は次のとおりです。

• この機能は、VM構成に応じてVMの初期配置も改善します。
• アクロポリスのブロックサービス機能は、外部から⾒えるiSCSIターゲットのセッションのバランスをとるためにADS機能を使⽤します。

デフォルトではこの機能は有効になっています。Nutanixではこの機能を有効にしておくことを推奨しています。 ただし、aCLIを使⽤してこの機能を無効にすることができます。この機能を無効にしても、競合やホットスポットのチェックはバックグラウンドで実⾏され、何らかの異常が検出された場合は、3回⽬の通知後に[アラート]ダッシュ ボードにアラート

が表⽰されます。ただし、これらの競合を解決するためのADS機能による処理はありません。マニュアルで修正措置を取る必要があります。

6. Acropolisの動的スケジューリングの要件と制限

• すべてのホストがAOS 5.0以降で実⾏していること
• iSCSIターゲットは空のエンティティとして表⽰されます。ただし、iSCSIターゲットで何らかの操作が⾏われると、関連するメッセージが[タスク]ダッシュボードに表⽰されます。
• 問題が検出され、ADSがその問題を解決できない場合（たとえば、CPUまたはストレージリソースが 限られているため）、移⾏計画は失敗する可能性があります。このような場合、アラートが ⽣成されます。Prism Webコンソールの[アラート] ダッシュボードからこれらのアラートを監視し、 必要な修正措置を取る必要があります。
• ホスト、ファームウェア、またはAOSのアップグレードが進⾏中で、リソースの競合が発⽣した場合、アップグレード期間中はリソースの競合の再調整は⾏われません。

Acropolisの動的スケジューリングを無効にする

次の⼿順を実⾏してADS機能を無効にします。ADS機能を無効にすることは推奨していません

1. SSHセッションからクラスター内のコントローラーVMにログインし、acliでアクセスします
2. ADS機能を無効にします

        acli> ads.update enable = false

Acropolisの動的スケジューリングの有効化

ADS機能を無効状態で機能を有効にしたい場合は、次の⼿順を実⾏してください

1. SSHセッションからクラスター内のコントローラーVMにログインし、acliでアクセスします
2. ADS機能を有効にします

        acli> ads.update enable = true

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

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

みなさん、こんにちは

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

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

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

１．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）にインテリジェントに配置し、最速の
    パフォーマンスを実現します。

• ラック（フォールトトレランス）

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

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

２．ノードについて

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

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

３．ブロック・クラスタについて

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

４．Prism上での画面イメージ

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

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

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

5．Distributed Storage Fabric

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

6．データの構造

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

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

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

よろしくお願いします。

Nutanix Guest Toolsについて

みなさん、こんにちは

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

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

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

１．Nutanix Guest Toolsとは？

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

• 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対応の詳細については以下をご参照ください。

２．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の導⼊を忘れずにお願いします。

よろしくお願いします。

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

よろしくお願いします。