Single Node Replication Targetについて学んでみよう！

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのSingle Node Replication Target(以下SNRTと省略)についてご紹介します。

Nutanixは通常3ノードで構成しますが、バックアップ⽤のノードに限り1ノードで構成することができます。ただし、こちらについては仕様を理解した上で構成しないとプライマリノードのバックアップとして構成できないことがありますので、注意が必要です。

１．シングルノードレプリケーションターゲット（SNRT）とは︖

SNRTは、リカバリ場所として使⽤できるシングルノードクラスタです。中⼩企業（SMB）およびリモートオフィス/ブランチオフィス（ROBO）の展開では、DHCPサーバー、DNSサーバー、SQLサーバーなどのインフラストラクチャVMのバックアップと復元に単⼀のクラスターを使⽤できます。プライマリサイトのVMに障害が発⽣した場合は、それらのレプリケートスナップショットを使⽤して復旧できます。

では、こちらがNutanixのどのモデルで利⽤できるのかをこちらに記載しておりますが、全モデル利⽤できるわけではなく、NXシリーズでも限られたモデルとなっております。

１ノードで構成するため、通常のRF2などとは違い、ノード内での処理で⾏います。また、RF3などの構成は組むことができませんのでご注意下さい。

２．ディスク障害について

シングルノードレプリケーションターゲットクラスタは、ディスクレベルでデータの冗長性を提供します

したがって、ディスクに障害が発生した場合は、データを別のディスクに保存できます

メタデータは2つのSSD間で複製されます

SSDに障害が発生した場合は、2番目のSSDでデータとメタデータを利用できます

ディスク障害は2つのカテゴリに分類できます

• SSD障害：SSD障害が発生した場合またはSSDが削除対象としてマークされている場合、SNRTは読み取り専用クラスターになり、受信用のレプリケーショントラフィックの受け入れを停止します
  プライマリおよびシングルノードのレプリケーションターゲットクラスタにアラートが表示されます
  また、クラスターの回復力ステータスが[重大]に変わります。回復プロセスも遅くなります。したがって、新しいSSDをクラスターに追加して、クラスターを通常状態に戻すことをお勧めします
  障害のあるディスクを取り外して新しいSSDと交換すると、この新しいSSDが自動的に検出され、クラスタは通常の状態に戻ります（読み取り/書き込みモード）
• HDD障害：HDD障害は通常のクラスターと同じ方法で処理され、（前述のように）SSDが障害になったときに発生する状況は、HDD障害の場合には発生しません

３．データ回復力(Resiliency)のステータス

[データ回復⼒ステータス]ウィンドウには、より詳細なクラスター回復⼒のステータス情報が表⽰されます。このウィンドウには、クラスタが安全に耐えることができる障害の数と種類に関する情報が表⽰されます。SNRTのターゲットクラスタの場合、[Failures Tolerable]列には、許容できるそのコンポーネントタイプ（ホストとブロックではなくディスクとホスト）の同時障害数（0、1、または2）が表⽰されます。失敗を許容できない場合は、制限を

強調するためのメッセージが表⽰されます。

４．SNRTの要件と制限

要件と制限についての注意点としては、NXシリーズの場合は制限がSupport Portal上に記載されています。SNRTについては、仮想マシンをインプリすることができますが、搭載しても良い条件が5台まで、IOPSも1000以下にする必要があります。

また、重複排除やEraser Codingなどのサポートはありません。

プライマリ環境も確認の上で、是⾮ノードの構成をご検討下さい。

その他の制限も含めて、すべて以下に記載致します。

• 1:1のレプリケーションのみが推奨されます（n:1のレプリケーションではありません）
• プラットフォームNX-1175S-G7およびNX-8155-G7でサポートされています
• 各プラットフォームに2つのSSD（それぞれ最小400 GB）、2つのHDD、および単一ノードクラスタ上でVMを実行するのに十分なメモリを搭載することをお勧めします
• SNRTで最大5ユーザーVMを超えないようにすることをお勧めします
• SNRTで最大1000 IOPSを超えないようにすることをお勧めします
• 保護ドメインごとにVMまたはVGを1つだけにすることをお勧めします
• SNRTクラスタでは、AHVとESXiのみサポート
• 重複排除はSNRTクラスタではサポートされていません
• 重複排除が有効になっているコンテナ上の保護ドメインを単一ノードのレプリケーションターゲットクラスタに複製することはお勧めできません
• このクラスタでは、Eraser CodingおよびEraser Coding-Xはサポートされていません
• LCMはシングルノードクラスタではサポートされていません。ファームウェアの更新では通常サービスを停止する必要があるためです（シングルノードクラスタでは更新中のノードからワークロードを引き継ぐノードは他にありません）
• Nutanix Filesはこのクラスタではサポートされていません
• ファームウェアアップデート（BMCまたはBIOS）は、SNRTクラスタではサポートされていません
• このクラスタでは、Metro Availabilityはサポートされていません
• ノードを追加するためにクラスターを拡張することはできません
• Prism WebコンソールからRepair Host Boot Diskを使用してSATA DOMを修復することはできません
• Nutanixのネイティブスナップショットのみを取ることができます。このクラスタをVeeamやCommVaultのようなサードパーティ製の提供先として設定することはできません

４．SNRTクラスタのガイドライン

シングルノードレプリケーションのターゲットクラスタに関するいくつかのガイドラインは次のとおりです

• 単一ノード複製ターゲット・クラスターのRPOは6時間であり、1日の変更率は5TBのデータ・セットで約1％以下です
• 毎日7回、毎週4回、毎月3回のスナップショットのスケジュールを設定できます
• SNRTクラスタのRTOは、24時間以内に4〜5TB

ここで注意するべき点としてはライセンス要件です。

プライマリクラスタに関してはStarterライセンスでも利用可能ですが、SNRTに関してはUltimateもしくはPro Editionをご利用の場合はAdvanced Replicationのアドオンライセンスが必要となります。

５．SNRTノードのイメージング

Controller VM FoundationとStandalone Foundation（※）の両⽅を使⽤して、SNRTノードをイメージングできます。

（※）注:Standalone Foundationを使⽤したイメージングは 、Nutanixのセールスエンジニア、サポートエンジニア、およびパートナーに限定されています。この⼿順については、Nutanixカスタマーサポートまたはパートナーにお問い合わせください。

Controller VM Foundation

• Controller VMファンデーションでは、ファンデーションプロセス中にプライマリクラスタノード （3つ以上のノード）とSNRTクラスタノード（1つのノード）をマップできます
• StandaloneのSNRTクラスタを作成することもできます プライマリクラスタとレプリケーションターゲットクラスタをマッピングしない場合は、 レプリケーションターゲットクラスタをリモートサイトとしてプライマリクラスタに追加が必要

Standalone Foundation

• Standalone Foundationを使⽤している場合、プライマリクラスタとレプリケーションターゲットクラスタのマッピングは実⾏できません。レプリケーションターゲットクラスタをリモートサイトとして主クラスタに追加する必要があります。

６．SNRTクラスタの設定

基本プロセス中にプライマルクラスタとレプリケーションターゲットクラスタをマッピングしていない場合は、このクラスタをリモートサイトターゲットとして手動で設定して、保護ドメインのデータレプリケーションを保存できます

シングルノードレプリケーションターゲットクラスタでリモートサイトを設定するプロセスは、バックアップのみの機能を使用してリモートサイトを設定する必要があることを除いて、通常のクラスタ用にリモートサイトを設定する方法と同じです

７．SNRTクラスタを使用したリカバリ手順

何らかの理由で主クラスタ上のエンティティに障害が発生した場合は、SNRTクラスタに複製されているスナップショットを使用してエンティティをリカバリできます

SNRTクラスタから保護エンティティを復元するプロセスは、通常のクラスタのエンティティを復元する方法と同じです

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

Nutanixのデータ保護について覚えてみよう～Metro AvailabilityとNear Syncの違いについて～

 みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのデータ保護についてご紹介します。

Nutanixのデータ保護については、Metro Availability （完全同期型）とNear Sync（ほぼ同期）の2種類があります。

今回はその違いについてお話するわけですが、まず⼀般的にビジネス継続性の観点でSLAを起点考えるわけですが、⼀般的にどのように定義するのか⾒ることにしましょう。

1. SLAベースの推奨事項

インシデントレベルでRPO（Recovery Point Objective）とRTO（Recovery Time Objective）決めていくわけですが、マイナーレベルであれば通常のバックアップのソリューションで対応できますが、重⼤インシデントでも停⽌がありえないシステムではDisaster Recoveyテクノロジー（同期レプリケーション）が必要となります。

ではNutanixにおいてはDRをどのように対応するのかを⾒てみましょう。

２. Nutanixのネイティブデータ保護はどこが適していますか？

DR施策としてマイナーインシデントであればローカルスナップショットやCloud Connectなどを利⽤すると良いでしょう。ただし重⼤インシデントについては、⾮同期レプリケーションもしくはNearSync（この⼆つは定義する時間が違います。後ほどご説明いたします）にな

ります。RPO/RTOゼロを求められる場合は、完全にMetro Availabilityしかありません。

バックアップについては、ローカルスナップショットもしくは3rdパーティのバックアップソフトウェアを使うしかありません。

こちらはあくまでデータのリカバリの観点のお話でしたので、実際にインフラ上で動いているアプリケーションやハイパーバイザー・ストレージの観点で⾒るとどうなるでしょうか︖

３. データ退避のテクノロジー

こちらにまとめているのが、それぞれの視点で⾒たデータ退避のテクノロジーになります。アプリケーション（特にデータベース系）についてはすでにベンダー側での実装がされています。ハイパーバイザーについてもマイクロソフト・VMwareとも同期レプリケーションのテクノロジーが対応できていますし、Nutanixにおいてもストレージにおいては対応できております。

ここでAHVの記載を書いておりませんが、AHVに関してはNear SyncベースでAOS6.0（STS)で同期レプリケーションが対応になっております。

それではここからはMetro AvailabilityとNear Syncについての説明します。

４. Metro Availabilityとは？

Metro Availabilityとは両サイト間で低遅延のネットワークで構成した上でお互いのコンテナでデータ同期処理を⾏うことができ、障害時にも⾃動に切り替えられる機能のことです。構成も⾮常にシンプルで同期するにあたりオーバーヘッドもないため、ストレージ部分のサイジングも苦労はありません。しかしながら、データの同期処理を⾏う必要があることから、5ms以内の遅延を要求されます。

（5ms以上の遅延でもNGになるわけではないが、保証はしない）

そのMetroAvailabilityについてどのような背景で必要になったのかを説明します。

５. なぜMetro Availabilityが必要なのか？

Metro Availabilityが必要になった背景は災害対策とワークロードのモビリティです。災害対策は当然のことでお分かりだと思いますが、NutanixはもともとApp Mobilityという概念の元で別サイトでのワークロード起動も考えています。

あとはミッションクリティカルのアプリケーションを動かすお客様にとっては運⽤停⽌時間は極⼒短くする必要がありますので、その実現も含めて考えなければいけません。

また、こちらのMetro Availabilityについては、ESXiもしくはHyper-Vの環境が必須になります。

６. Metro Availabilityのガイドライン

保護ドメインは、ローカルクラスタ上にプライマリストレージコンテナを指定し、リモートクラスタ上に同じ名前のスタンバイストレージコンテナを指定することによって作成

• Metro Availabilityを備えたストレージコンテナを使用する場合、データストア名はストレージコンテナ名と同じでなければならない
• 2つのサイト間でデータストアの可用性を確保するには、両方のサイトにリアルタイムでデータが存在する必要がある。クラスタ間の応答時間は5ミリ秒未満である必要がある。ピーク書き込みに対応できるように適切な帯域幅をキープします。サイト間に冗長な物理ネットワークを持つことを推奨
• 特定の仮想マシンに関連付けられたすべての仮想ディスクが、Metro Availabilityが有効になっているコンテナに存在することを確認
• 保護された仮想マシンは、アクティブストレージコンテナに関連付けられたNutanixクラスタまたはスタンバイストレージコンテナに関連付けられたクラスタで実行できます。ただし、スタンバイ・ストレージ・コンテナに関連付けられたクラスタで仮想マシンが実行されている場合、アクティブなストレージ・コンテナへの読み書きが行われます。したがって、仮想マシンのデータが格納されているアクティブなコンテナに対して仮想マシンをローカルで実行して、ネットワークトラフィックおよび関連するネットワーク遅延を減らすことを推奨

７. Metro Availabilityのセットアップ

Metro Availabilityのセットアップについては上記のようにProtection Domainでコンテナ名を揃えておく必要があります。

８. アクティブ・スタンバイ状態で何が起きているのか？

アクティブ側からのRF2での書き込み(WRITE)の構造 

スタンバイサイトからのRF2での書き込み(WRITE)の構造 

スタンバイサイトからのRF2での読み込み（READ）の構造 

こちらの３つの図については、仮想マシンからWrite/Read要求をCVMがどのように応答しているのかを記載しております。Writeデータはデータローカリティとデータの冗⻑化でコンテナ内で同期を取りつつ、他サイトのコンテナでも同期処理を⾏います。

９. 計画的メンテナンス

計画的なメンテナンスを行う際に実施する必要があるのが以下の内容になります。

1. アフィニティルールのアップデート
2. 仮想マシンをサイト2へvMotion 
3. サイト２内のMetro Protection Domain(PD)の昇格 
4. サイト1のPDを無効化 
5. サイト2内のPDを再有効化

１０. 計画外の障害

計画外の障害のときの挙動について説明します。

サイト１が停電してしまった場合にどう機能するかを記載していますが、サイト２側がサイト１の停電を検出するとWitnessサーバがロックされてしまいます。ロックされた場合はスタンバイサイトのProtection Domainがプライマリに昇格することになります。ハイパーバイザーのHA機能で、サイト２側で仮想マシンが再起動しますが、この際管理者の操作は⼀切ありません。

ここまでがMetro Availabilityのお話になりますが、仮にMetro Availabilityが使えない場合はどうなるのか︖というお話もあると思いますので、以下に想定できる理由も含めて記載しておきます。

１１. Metro Availabilityが利用できないケース

Metro Availabilityに関して拠点間の距離に依存するため、長距離の場合はMetro Availabilityは利用できません。

またはシングルストレッチハイパーバイザークラスタにも適しません。

Metro Availabilityは構成する場合はRPOとRTOを考慮する必要があります。

１２. Near Syncレプリケーションについて

非同期連続レプリケーション

• 継続的なデータ保護のテクノロジー
• フルスナップショットの代わりに「マーカー」を使用する 
• 完全にOplogベースで、LWS（※） StoreはSSD上に存在します 

Near Syncレプリケーションとは⾮同期レプリケーションですが、間隔が短く連続的に⾏うレプリケーションになります。アーキテクチャは既存のNutanixのスナップショットの技術を利⽤していますが、スナップショット領域にあたるOplog領域を短い間隔で利⽤します。

１３. なぜNear Syncが必要なのか？

Near Syncの登場により同期できない環境でもほぼゼロに近いRPO/RTOを実現したいときに利⽤できます。データの損失は多少あるものの、それを最⼩限に抑えるのがこのソリューションの特徴になります。

リモートおよびローカルの災害対策（DISASTER RECOVERY）

• オーケストレーションされたワークフローによる最小のデータ損失距離を意識したレプリケーション
• アプリケーションパフォーマンスの影響を最小限に抑える 

• データ損失のコストを削減する 
• 運用停止時間の短縮
• テスト用のクローン/ dev / reporting

１４. Near Syncの設定条件

• サポートされるレプリケーションは1：1のみ
• NearSyncを有効にするには、プライマリサイトとリモートサイトの両方のクラスタに最低3つ以上のノードが必要
• 1〜15分のスケジュール設定がサポートされています。スケジュールは16〜59分に設定することはできません
• クラスタ内の各SSDは最小容量を1.2TBにする必要があります。十分な容量がない場合、クラスタはNearSyncを有効にできません。また、ノードまたはSSDを追加する場合は、各SSDの容量が1.2 TB以上であることを確認してください。最適なパフォーマンスを得るには、ハイブリッドストレージ構成の最小SSDサイジング要件は2 x 1.9 TBです。特定のSSDサイジング制限は、All Flashクラスタには適用されません（7%の空き領域がローカルのSSDとリモートにクラスタに必要）
• 各保護ドメインに最大10のエンティティ（仮想マシンまたはボリュームグループ）があることを確認してください。アプリケーションを構成する仮想マシンを単一の保護ドメインにグループ化して、特定のアプリケーションのフェイルオーバー精度を高めることをお勧めします
• 40TB以上のストレージ（すべてのSSD、SSDまたはHDDの組み合わせ）を持つノードを持つクラスタでは、NearSyncを有効にしないでください

他のハードウェアベンダーとNutanixのクラスタ間でNear Sync設定を行いことが可能になります

• ESXiとAHVをサポート
• IBM Power Systemsを除くすべてのプラットフォームがサポート
• この機能は、同種のクラスタでのみサポートされています。クラスタ内のすべてのノードは同じタイプのハイパーバイザを実行する必要がある
• リモートサイトコンテナには、プライマリサイトの保護されたエンティティの作業サイズセットと同じスペースが必要。たとえば、プライマリサイトのコンテナで30 GBの領域を使用している仮想マシンを保護する場合は、リモートサイトコンテナに同じ容量が必要
• 保護ドメインへのエンティティの追加または削除は、他のエンティティのリカバリポイントに影響を与えないようにこの機能を設定した場合は無効になります。この機能を使用して構成された保護ドメインを編集する場合は、まず、構成済みのNearSyncスケジュールを削除し、保護ドメインを編集して（エンティティの追加または削除）、新しいスケジュールを再構成します
• 遅延要件はありませんが、2つのサイト間の帯域幅は、保護されたエンティティの変化率とほぼ同じかそれ以上にする必要がある
• NearSyncスケジュールで構成され、リモートサイトに複製されるように構成された保護ドメインの場合は、対応するvStoreマッピングを構成する必要がある

１５. Near Syncの制限事項

• 仮想マシンのリンククローン機能は未サポート
• Light Weight Snapshotでは、チェンジブロックトラッキング(CBT）は未サポート
• ワンタイムスナップショットは未サポート
• シングルノードレプリケーションターゲットクラスタまたはシングルノードクラスタは未サポート
• Hyper-Vは未サポート
• Metro Availabilityの環境およびSRMで保護されたコンテナは未サポート
• セルフサービスの復元は未サポート
• Nutanix Files は未サポート
• NearSync保護ドメインにあるVMでは、ネイティブバックアップの統合（Commvault IntelliSnap, Rubrik）は未サポート。ただし、ESXiまたはVADPを介して撮影されたスナップショットはサポート。
• NearSyncスケジュールのNutanixネイティブスケジュールでは、アプリケーション整合性のあるスナップショットは未サポート
• 次の機能のための最小RPOは影響なし
• Cloud Connect：最低RPOは1時間
• 単一ノードおよび2ノードのクラスター：最小RPOは6時間
• Cross-Hypervisor DR：RPOの最小値は1時間

１6. Near Syncは非同期スナップショットからスタート

こちらはスナップショットの動きについて紹介をしております。vDiskがスナップショットを取るタイミングのDiskイメージになります。スナップショットを取るタイミングについては次のスライドで説明します。

１７. 伸縮自在のスケジューリング

こちらがスナップショットのスケジューリングです。たとえば1分間隔で15世代分で15分対応可能ですが、16分以降の設定はできません。ほかの時間間隔でも設定不可の領域はあります。

１８. データ保護のランブック（ワークフロー）の自動化

こちらはデータ保護したもののどうやって⾃動化するのか︖というところで、ワークフローを⾏うとこうなりますという図になります。先ほどのMetro Availabilityは⾃動化はシンプルにできますが、どのポイントに戻すのか︖などの時間の指定なども明確化しなければなりませんのでワークフローで⼀度定義して、それを⾃動化するというフローです。Metro Availabilityのような⾃動化とは若⼲異なります。

１9. Metro AvailabilityとNear Syncの違い

最後にMetro AvailabilityとNear Syncの違いを記載しておきました。

最後の項⽬以外は今までに説明してきた内容になりますので省略します。両機能

ともUltimate EditionもしくはPro Editionの場合はAdvanced Replication用のアドオンが必要となりますので、ご注意ください。

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

Nutanixクラスタの正常性の確認について～Health Monitoring～

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのヘルスモニタリングについてご紹介します。

まず、はじめにNutanixの正常性を確認するというが何を⾒ることができるのか︖ということをお話します。

１．ヘルスモニタリング

Nutanixはクラスターの正常性をモニターするための一連の状況チェックを行います。

• 仮想マシン、ホスト、およびディスクの状態をホームダッシュボードに表示
• 仮想マシン、ホスト、およびディスクの深刻度、ヘルス状態の情報をダッシュボードに表示
• スケジュールされたヘルスチェックの頻度と実行頻度をカスタマイズ
• Prismから直接NCCヘルスチェックを実行
• すべてのノードとコンポーネントのログを収集

ヘルスダッシュボード

ヘルスダッシュボードには、クラスタ内のVM、ホスト、およびディスクに関する更新された情報が表示します。

ヘルスダッシュボードを表示するには、メインメニューのプルダウンリストから[Health]を選択。

ヘルスチェックの設定

一連のヘルスチェックが定期的に実行され、一連のクラスタヘルスインジケータが提供され、実行する検査を指定し、スケジューリング可能な検査および各ヘルスチェックのための他のパラメータを構成することが可能。

NCC（Nutanix Cluster Check）の間隔の設定

NCCがPrismから指定された時間後に自動的に実行されるように設定するには、次の手順を実行。

Webコンソールを使用したチェックの実行

Prism WebコンソールのヘルスダッシュボードからNCCチェックを実行できるようになりました。すべてのチェックを一度に実行するように選択することができます。失敗したチェックや警告を表示したり、選択した特定のチェックを表示したりすることができます。

Webコンソールを使用したログの収集

Prism Webコンソールのダッシュボードから直接ログを収集可能。コントローラVM、ファイルサーバ、ハードウェア、アラート、ハイパーバイザ、およびシステムのログを収集可能。タスクが完了するとタスクダッシュボードからログバンドルをダウンロードできます。

２．ヘルスダッシュボード

ヘルスダッシュボードには、クラスタ内のVM、ホスト、およびディスクに関する動的に更新された正常性 情報が表⽰されます。ヘルスダッシュボードを表⽰するには、メインメニューの左側にあるプルダウンリストから[Health]を選択します。

• メニューオプション
  ヘルスダッシュボードには、メインメニュー以外のメニューオプションはありません
• 画面の詳細
  ヘルスダッシュボードは3つの列に分かれています。
• 左側の列には、各エンティティタイプ（VM、ホスト、ディスク、ストレージプール、ストレージコンテナ、クラスタ サービス、および[構成されている場合]保護ドメインとリモートサイト）のタブが表⽰されます。各タブには、クラスタのエンティティの合計（ディスクの総数など）と各正常性状態の数が表⽰されます。タブをクリックすると、表⽰された 情報が展開されます（次のセクションを参照）。
• 中央の列には、左側の列で選択されているものに関する詳細情報が表⽰されます。
• 右側の列には、すべてのヘルスチェックの要約が表⽰されます。また、チェックボタン（成功、警告、失敗、無効）から個々のチェックを表⽰するオプションもあります。
• [Summary]タブには、チェックステータスとチェックタイプに従って、すべてのヘルスチェックのSummaryが表⽰
• [Checks]タブには、個々のチェックに関する情報が表⽰されます。カーソルを項⽬の上に移動すると、そのヘルスチェックに関する詳細情報が表⽰されます（次の図を参照）。適切なフィールドタイプをクリックして[Apply]をクリックすると、チェックをフィルタリングできます。チェック内容は以下のように分類されます。

• ステータスでフィルタリング
  合格(Passed), 失敗(Failed), 警告(Warning), エラー(Error), オフ(Off), またはすべて(all)
• タイプでフィルタリング
  スケジュールされていない、スケジュールされていない、イベントトリガーされている、またはすべて
• エンティティタイプ別にフィルタリングする
  VM、ホスト、ディスク、ストレージプール、ストレージコンテナ、クラスタサービス、またはすべて

たとえば、Failureをチェックのみを表⽰する場合は、[ Failure ]オプションを選択してチェックをフィルタします。 特定のチェックをクリックすると、中央の列に、チェックが失敗した⽇時とチェック失敗の割合の詳細な履歴が 表⽰されます。バーをクリックすると、合格と失敗の履歴の詳細グラフが表⽰されます（上図参照）。

マウスをグラフの線に沿って動かすと、その時点に関する情報が表⽰されます。

また検索ボックスに⽂字列を⼊⼒することで、特定のチェックを検索することもできます。「Action」タブにはチェックを管理し、チェックを実⾏し、ログを収集するオプションがあります。

• フォーカスとフィルタリングのオプション
  ヘルスダッシュボードでは、さまざまなビューを通じてエンティティのヘルス情報を表示できます。左の列タブをクリックすると、そのタブが展開され、そのエンティティタイプ（VM、ホスト、またはディスク）のグループ化カテゴリが表示されます。また、中央のセクションは追加の詳細で拡張されます。チェックし右の列のタブには、そのエンティティタイプに関連するヘルスチェックを表示します。
  
  グループ化カテゴリをクリックすると、そのグループ化に関する詳細情報が表示されます。左側の列が展開され、グループ化とフィルタオプションのセットが表示されます。選択したグループが強調表示されます。そのグループをクリックすると、別のグループを選択できます。各グループエントリには、そのグループに含まれるカテゴリの数が表示され、中央のセクションにはそれらのカテゴリに関する情報が表示されます。次の例では、ディスクストレージ階層が選択されており、そのグループには2つのカテゴリ（SSDとHDD）があります。デフォルトでは、すべてのエンティティ（この例ではすべてのディスク）がカテゴリ情報に含まれています。1つまたは複数のフィルタをクリックすると、含まれているリストを絞り込むことができます。
  
  中央の列には、選択したグループ内の各カテゴリのフィールドが表示されます。各フィールドには、そのカテゴリの詳細が表示されます。特定のエントリにカーソルを置くと、追加情報が表示されます。フィルタリング用のドロップダウン選択リスト（グループ化フィルタと同じ）と、情報を並べ替えるためのリストによるドロップダウンソートがあります。
  
  右側の列には、そのエンティティタイプに関連するヘルスチェックが引き続き表示されます。

中央の列には、ダイアグラムビューとテーブルビュー（次ページ参照）の2つの表示オプションがあります。

テーブルビューは詳細な情報を表形式で提供します。列ヘッダーをクリックしてエントリを並べ替えることができます。

中央の列には、最上部にウォッチリスト情報（「現在見ているHDD」または「現在 IOPS total DISK IOPS」）も含まれています。

ヘルスダッシュボードは、現在のウォッチリスト内のエンティティに関する情報を反映するように動的に調整されます。

この画面では、ステータス情報（中央の列）と関連するヘルスチェック（右の列）が18個のディスクを反映するように、ウォッチリスト（現在は18/18個のディスクを合計しているディスク）ですべてのディスクが選択されています。

監視リストを現在のエンティティタイプ（単一ディスクなど）または別のエンティティタイプ（ホストなど）のサブセットに変更すると、ステータス情報と関連するヘルスチェックが新しいウォッチリストに応じてカスタマイズされます。

⼀連のヘルスチェックが定期的に実⾏され、⼀連のクラスタヘルスインジケータが提供されます。実⾏する検査を 指定し、スケジューリング可能な検査および各ヘルスチェックのための他のパラメータを構成することができます。

クラスターヘルスチェックは、AOS、ハイパーバイザー、およびハードウェアコンポーネントを含むさまざまな エンティティをカバーします。チェックのセットはデフォルトで有効になっていますが、いつでもチェックの実⾏、無効化、または再設定ができます。1つまたは複数のヘルスチェックを再設定するには、次の⼿順を実⾏します。

１．ヘルスのダッシュボードでは、Action > Manage Check でクリックします

ヘルスダッシュボードには、ヘルスチェックに関する情報が再表⽰されます。特定のヘルスチェックをクリックすると、その チェックが強調表⽰されます。ヘルスチェックを選択するか（最初に選択するか）、以前に選択したヘルスチェックが強調表⽰されます。次の情報が表⽰されます。

• 左側の列には、ハイライトされた状態が正常性チェックの⼀覧として表⽰されます。いずれかのエントリをクリックして、そのヘルスチェックを選択して強調表⽰します。
• 中央の列には、このヘルスチェックの機能が記載されており、影響を受けるエンティティ（ホスト、ディスク、またはVM）全体で実⾏スケジュールと履歴が提供されます。
• 右の列には、このヘルスチェックが失敗した原因（原因、解決、影響）が記載されています。

２．特定のチェックを実⾏するには、[Run Check]をクリックします。

３．ヘルスチェックをオフにする（またはオンにする）には、中央の列の上部にあるチェックオフ（またはチェックオン）リンクをクリックし、ダイアログボックスで[Yes]ボタンをクリックします。

４．パラメータの設定を変更するには（設定可能なパラメータがあるヘルスチェックの場合）、中央の列の上部にあるパラメータリンクをクリックし、ドロップダウンウィンドウでパラメータ値の1つ以上を変更して、[Update]ボタンをクリックします。このリンクは、ヘルスチェックに設定可能なパラメータが含まれている場合にのみ表⽰されます。設定可能

なパラメータは、そのヘルスチェックに固有です。たとえば、CPU Utilizationヘルスチェックには、ホスト平均CPU使⽤率のしきい値とホストピークCPU使⽤率のしきい値の割合を指定するパラメータが含まれています。

5. ヘルスチェックを実行するスケジュールを変更するには、中央の列の上部にあるスケジュール可能なチェックのスケジュールリンクをクリックし、ドロップダウンリストから間隔を選択します。1分から48時間までの間隔を選択できます。各Checkにはデフォルトの間隔があり、ヘルスチェックに応じて1分に1回から1日に1回まで変更可能。

ほとんどの場合、デフォルトの間隔が最適であり間隔を変更することは推奨されません（Nutanixのカスタマーサポートによって要求されない限り）。

３．NCC（Nutanix Cluster Checkの間隔）

Prismから指定された時間が経過した後にNCCを自動的に実行する設定を行うには、次の手順を実行ヘルスダッシュボードの[Action]ドロップダウンメニューから[Set NCC Frequency]を選択構成スケジュールを選択します。

→4時間ごと：4時間間隔でNCCチェックを実行するには、このオプションを選択

→毎日：NCCチェックを毎日実行するには、このオプションを選択します。開始時刻フィールドからチェックを実行する時刻を選択

→毎週：毎週 NCCチェックを実行するには、このオプションを選択します。あなたからのチェックを実行する曜日と時刻を選択しオンと開始時刻のフィールドを。たとえば、[オン]フィールドで日曜日と月曜日を選択し、[開始時刻]フィールドから午後3時を選択すると、毎週日曜日と午後3時にNCCチェックが自動的に実行します

電子メールのアラート設定を使用して設定した電子メールアドレスも表示されます。レポートはすべての受信者に電子メールとして送信します[Save]をクリックします。

４．Webコンソールを使用したCheckの実行

Prism WebコンソールのHealthダッシュボードからNCCチェックを実行可能

すべてのチェックを一度に実行するように選択することができます。失敗したチェックや警告を表示したり、選択した特定のチェックを表示したりすることができます。

1. ヘルスダッシュボードの[Action]ドロップダウンメニューからCheckを実行します。
2. クラスタに対して実行するチェックを選択します。
   a. すべてのチェック：すべてのチェックを一度に実行するには、このオプションを選択
   b. 失敗および警告チェックのみ（Only Failed and Warning Checks）：ヘルスチェックの実行中に、失敗または警告を出したCheckのみを実行するには、このオプションを選択
   c. 特定のチェック：このオプションを選択し、実行するテキストボックスにCheckまたはCheckの名前を入力します。
   このフィールドは、Checkの名前の入力を開始すると自動入力。
   この実行のために選択したすべてのチェックは、[Added Checks]ボックスに表示されます。
3. 選択した電子メールのクラスタチェックレポートを送信クラスタチェック後にレポートを受信するためのオプションを選択し、電子メール構成を受信するには、アラートの電子メール構成を構成していることを確認します。

実行のステータス（成功または中止）は、タスクダッシュボードで使用できます。デフォルトでは、すべてのイベントトリガーチェックが渡されます。また、ヘルスダッシュボードの[Summary]ページは、ヘルスチェックの実行状況に応じて更新

5．Webコンソールを使用したログの収集

Prism Webコンソールのホームダッシュボードから直接ログを収集可能。コントローラVM、ファイルサーバ、ハードウェア、アラート、ハイパーバイザ、およびシステムのログを収集可能。タスクが完了すると、タスクダッシュボードからログバンドルをダウンロード可能です。

1. 正常性ダッシュボードの[アクション]ドロップダウンメニューから[ログコレクタ]を選択します。
2. ログを収集します。
   a. Collect Logs starting nowを収集する：時間数または日数に基づいてログを収集するには、このオプションを選択します
   b. Custom Date Range：このオプションを選択すると、開始日と終了日のフィールドに日付範囲を指定します。時間フィールドは、現在の時間で自動的に更新されます。ただし、収集操作を開始する時刻を選択するオプションもあります。
3. [Run Now]をクリックして操作を開始します。

操作が終了すると、最後の2回分のログバンドルをタスクダッシュボードからダウンロードして、後で分析することができます。

参考にして頂ければ幸いです。よろしくお願い致します。

AHVの High Availability（⾼可⽤性）について

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はAHVの高可用性【High Availability】(以下HAで省略)についてご紹介します。

HAの⽅式については2種類存在します。

• ベストエフォート
• リザベーション

１．ベストエフォート方式について

HAの設定についてはFoundationでセットアップ後に組まれていますが、Prismのメニューで「Manage VM High Availablity」というメニューで「Enable HA Reservation」のチェックのON/OFFで設定が決まります。

設定をOFFのままであれば、ベストエフォートになり、ONにすればリザベーション（予約）になります。

• Acropolisは、ホストがダウンした場合に管理する仮想マシンの⾼可⽤性を提供
• 正常でないホストが修復されている間に、別の正常なホスト上で仮想マシンが再起動されます
• ホストが修復されている間、仮想マシンが⻑期間停⽌する⼼配はありません
• ストレージの⾼可⽤性の最⼤はRF-3であるため、最⼤2つのホスト障害をサポートします

ベストエフォートの場合、障害発⽣後は⾃動で再起動しますが、デフォルト設定なので、ノードで使⽤可能なリソースに基づいて、他のクラスタノード上の仮想マシンの復旧と電源投⼊を⾏います。エンタープライズクラスの機能を最初から有効にすることは⾮常に効果的ですが、ベストエフォート型のオプションでは、リソースの制限のために仮想マシンの電源がオンにならない状況が発⽣する可能性があります。

より定義された復旧モデルの場合、AHVは仮想マシンの⾼可⽤性を保証するために、クラスタ内に必要なリソースを予約することができます。デフォルトのベストエフォート機能と同様に、リザベーション（予約）モードも⽤意されており、ワンクリックで選択できます。

2．リザベーション（予約）方式について

チェックを⼊れることにより、AHVはNutanixクラスタを分析し、復旧に最適な⾼可⽤性ポリシーを選択します。現時点では、システムは、確⽴された⾼可⽤性ポリシーに基づいて新しいVMを確実に回復できるようにポリシーを設定します。

AHVは、ポリシーをクラスタ内の使⽤可能なメモリに基づいており、次の可⽤性ポリシーを提供します。

• ホストのCPUとメモリの使⽤状況を追跡します
• ホスト機能の対象となり、仮想マシンのポリシーに準拠した仮想マシンを配置
• 仮想マシンの⾼可⽤性を保証するリソースを予約

リザーブド・セグメント︓AHVは、単⼀ノードを専⽤ノードに割り当てるのではなく、クラスタ内のノード全体に⾼可⽤性リカバリ・ポイントを分散します。ハイアベイラビリティイベントが発⽣すると、障害の発⽣したホスト上で実⾏されている仮想マシンは、クラスタ内の他のノードで再起動します。

サポートするポリシーについて

• データローカリティを維持しますQoSを保証します
• 特定のリソースタイプとの相関関係を決定づける
• ハードウェア/ソフトウェアポリシーの制約に従う
• ワークロード間の⼲渉を避ける
• 集合的なリソース要件を優先する

予約された構成では、仮想マシンの⾼可⽤性設定は、確⽴されたNutanixクラスタのフォールトトレランスレベルに応じて、クラスタ全体でリソースを予約します。仮想マシンの⾼可⽤性の構成では、次のことから保護するために必要なリソースが予約されています。

1. NutanixコンテナがReplicationFactorが2で構成されている場合、1台のAHVホスト障害まで許容
2. NutanixコンテナがReplication Factorが3で構成されている場合、2台のAHVホスト障害まで許容

Nutanixは、クラスタから⼊⼿可能な詳細に基づいてリカバリオプションを⾃動的に選択することにより、⾼可⽤性のリカバリ⽅法の選択を簡素化します。ベストエフォート型のデフォルトを超えて仮想マシンの⾼可⽤性を有効にすると、新しい仮想マシンの⾼可⽤性に対応するのに⼗分なリソースがポリシーで確保できる限り、新しく作成された仮想マシンの電源を⼊れることができます。

仮想マシンの⾼可⽤性はハイパーバイザベースの⾼可⽤性のイベントでのみ、実⾏中の仮想マシンのリカバリ性を考慮した構成にする必要があります。ハイパーバイザベースのイベントは、Nutanixソリューション内のストレージまたはCVMイベントを含む⾼可⽤性とは異なります。

ストレージまたはCVMイベントには、（定義されたレプリケーションファクタに基づいて）データレプリケーションによるリカバリと、クラスタ内のリモートCVMへのリダイレクトが含まれます。

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

NutanixのREST APIについて

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのREST APIについてご紹介します。

REST APIについてご存じない⽅もいらっしゃると思いますので少しご説明したいと思います。

---------------------------------

REST (Representational State Transfer) APIは、Webシステムを外部から利⽤するためのプログラムの呼び出し規約（API）の種類の⼀つです。RESTそのものは適⽤範囲の広い抽象的なモデルであるが、⼀般的にはRESTの考え⽅をWeb APIに適⽤したものをRESTful APIと呼んでいる。

RESTful APIでは、URL/URIですべてのリソースを⼀意に識別し、セッション管理や状態管理などを⾏わない(ステートレス)。同じURLに対する呼び出しには常に同じ結果が返されることが期待される。

また、リソースの操作はHTTPメソッドによって指定(取得ならGETメソッド、書き込みならPOSTメソッド)され、結果はXMLやHTML、JSONなどで返される。また、処理結果はHTTPステータスコードで通知するという原則が含まれることもある。

引⽤︓IT⽤語辞典 e-Words

---------------------------------

NutanixにおいてはREST APIがどのように使われて、どのように利⽤するのかを今回お話したいと思います。

1. Nutanix REST API

Nutanix REST APIを使⽤すると、Nutanixクラスタに対してシステム管理コマンドを実⾏するスクリプトを作成できます。APIを使⽤すると、HTTP要求を使⽤してクラスターに関する情報を取得したり、構成変更可能になります。コマンドからの出⼒はJSON形式で返されます。

動作イメージについても合わせてご覧いただければと思いますが、送信側（クライアント）から受信側（Nutanixクラスタ）に対して、必要としているクラスタ情報を取得ししたり、作成・更新・削除する際にHTTPをベースに操作を⾏います。

HTTPで送信した命令を元に出⼒結果をHTTPのコードとJSONファイルで出⼒します。

このようにして、HTTPのリクエストからNutanix上の操作を⾏うことができるようになっているのが、Nutanix REST APIになっています。

2. Nutanix REST APIを利用するには

Nutanix REST APIを利⽤するには、Nutanix REST APIが何ができるのかを知る必要があります。Prismの管理画⾯の右上にあるアカウントのメニューからREST API Explorerがメニューにあるので、こちらをクリックします。

REST API Explorerが起動されるとNutanix APIが表⽰されますが、REST APIにはバージョンもございます。バージョンの指定は右側のプルダウンメニューから選択することができます。現状はVersion3まであります。

REST API ExplorerでAPIで管理できるクラスターオブジェクトとのリストを表⽰します。オブジェクトについては、ベースがURI形式の相対パスになって表⽰されます。該当のPrism（Nutanix クラスタ）のIPアドレスおよびREST APIのバージョンを指定することで利⽤できます。

今回はNutanixで利⽤できるREST APIでClusterのコマンドについて説明したいと思います。ここでClusterに関して操作を展開してみます。

3. オペレーションに関して

Clusterに関するオペレーションが表⽰されます。例えばGet clusterなどはNutanixのクラスタ情報をクライアント側から取得するAPIになっています。それ以外にも様々な変数をNutanixクラスタの情報を作成、更新するAPIもあります。

ここで、Get clusterをクリックするとクラスタの情報がウィンドウで展開されて表⽰されます。ここでウィンドウで表⽰されているのがクライアント側から送信するGet clusterのREST APIの中⾝になります。

４. APIをテストする

APIをテストには、「Try it out!」をクリックすることで、クラスタ内で使⽤するAPIを呼び出してテストできます。

クリックするとクラスタに設定されているIPアドレス情報やマシンのシリアル情報などが取得できるようになります。こちらはブラウザベースでテストしていますが、実際はクライアント側からコマンドを実⾏することになります。

CentOSがインストールされている仮想マシンからコマンドで、curl コマンドを利⽤することで、リモートのサーバーに対してコマンドを投⼊することができます。

$ curl -X GET --header 'Accept

application/json' 'http://NutanixクラスタのIPアドレス:9440/api/nutanix/v2.0/cluster'

このようなAPIを利⽤することにより、オペレーションがコードされて⾃動化するためのツールとして利⽤できます。以前こちらのブログで紹介したCalmなどはこのREST APIなどが連携されて構成されているソリューションだと思って頂ければと思います。

では、REST APIを利⽤するとどのようなことができるのかをまとめてみました。

５. APIを使用した完全なライフサイクルの自動化

利⽤できるようなシーンとして、イメージのようなものを想定しています。

例えばプロビジョニングについて説明します。

新⼊社員で研修などで開発環境をたくさん作成しなければいけない場合、管理者が⼀つずつ⼿動で構築するのは⾮常に効率が悪くなります。そこで、オペレーションをすべてコードしておくことで必要に作業がシンプル化し、作業時間もかからずに導⼊が終わります。

どのように対応するかについては、仮想マシンのプロビジョニングに必要なイメージを⽤意して、それを必要な台数分をPOSTで作成することで対応できます。

その結果、プロビジョニングの時間が数分程度で終了して、管理者が準備に費やす時間を削減することができます。

システムの最適化にこのAPIを使うためにはどうするのかをお話したいと思います。

例えば制約を受けるようなVMを常にシステムを更新することによって発⾒して、リソースに影響を与えるような仮想マシンを保護するようなものを探したい場合にもこちらのREST APIを利⽤することで対応可能になります。

発⾒⽅法については、Powershellなどの連携で対応できます。システム全体の情報はREST APIで取得し、仮想マシンへの指⽰はPowerShellなどでそれぞれでできる部分をうまく連携することでパフォーマンスおよびセキュリティなどからシステム守るようなことができるようになります。

NutanixはGUIですべてできるようななっているように⾒えますが、細かい操作が必要な場合は是⾮REST APIなども利⽤してみると良いと思います。

最後にNutanixのREST APIにおける簡単なアーキテクチャを紹介したいと思います。参考程度に⾒て頂ければと思います。

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