Nutanixのデータ保護について（その２）

みなさん、こんにちは

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

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

今回は前回の投稿に続いてNutanixのデータ保護に関してご紹介します。

内容は若干長いため、2回に分けてご紹介しております。

(画像の⼀部はNutanix様の資料から拝借させて頂いております)

１．データ保護の⽅式について

データ保護の方式として代表的なものとしてレプリケーションがあります。

レプリケーションは、あらゆる企業のデータ保護ソリューションの基本コンポーネントで

あり、重要なデータとアプリケーションを確実にかつ効率的に別のサイトまたは別の

インフラストラクチャにレプリケートできるようにします。エンタープライズ

ITアーキテクトには多くのテクノロジオプションがありますが、成功したエンタープライズデータ保護イニシアチブに必要なレプリケーション機能があります。 

Nutanixのネイティブレプリケーションインフラストラクチャと管理は、現実の要件を

満たすためにさまざまなエンタープライズトポロジーをサポートします。 

それぞれのデータ保護方式について、以下にご紹介したいと思います。

２．双方向ミラーリング

すべてのサイトがアクティブトラフィックをサポートする必要がある環境では、複数のサイト間で仮想マシンの複製をミラーリングする機能が必要です。2サイトの例を挙げてみます。

サイト2は、サイト1で実行されている選択されたワークロードのターゲットとして使用されます。同時に、サイト1はサイト2で実行されている指定ワークロードのデータ保護ターゲットとして機能します。どちらの場所にもアイドルリソースはありません。

両方の場所でストレージ、コンピューティング、およびネットワーキングリソースを利用することは、将来のデータ災害の発生を見越してサーバーがアイドル状態にあるという従来のデータ保護の考え方よりも大きなメリットです。

３．１対多のレプリケーション

別のシナリオでは、複数のリモートロケーションを持つ1つの中央サイトがあるかもしれません。ティア１のワークロードがサイト1で実行され、サイト2と3がリモートバックアップロケーションとして機能する例を考えてみると、サイト1のワークロードを2箇所と3箇所の両方に複製できます。

データ障害が発生した場合、保護されたワークロードは、仮想マシン全体の可用性を高めるために、必要なレプリケーションサイトのいずれかで開始できます。

1対多トポロジは、サイト間の帯域幅を最適化するように設計することもできます。たとえば、サイト1と3の間で利用できるワイドエリアネットワーク（WAN）の帯域幅が、サイト1と2の間の帯域幅よりも大きいとします（サイト1と2は同じ都市にあり、サイト3は全国にあります）。

この場合、帯域幅を節約してパフォーマンスを向上させるために、サイト1で実行されているサイズの大きい仮想マシンがサイト2に複製されるように複製スケジュールを設定できます。同様に、小規模の仮想マシンはサイト3にバックアップされ、帯域幅の狭いリソースをより有効に活用できます。

４．多対１のレプリケーション

たとえば、ハブスポークアーキテクチャでは、サイト1と2で実⾏されているワークロードを中央 サイト3に複製できます。単⼀サイトへの複製の集中化により、地理的に分散した環境の運⽤効率が向上します。リモートオフィスとブランチオフィス（ROBO）は、多対1トポロジーの従来型の ユースケースです。

５．多対多のレプリケーション

このトポロジーは最も柔軟な設定を可能にします。ここで、IT部⾨はアプリケーションとサービスのレベルの継続性を保証するために最⼤限の制御と柔軟性を持っています。

６．データ保護のダッシュボード

データ保護のダッシュボードには、クラスター内のデータ保護の構成に関する動的に更新された情報が表⽰されます。ダッシュボードでの表⽰画⾯も含めて以下のイメージを紹介いたします。

ビューセレクタ

• 「概要」ボタンをクリックして、サマリービューにデータ保護と回復の情報を表示します
• 「テーブル」ボタンをクリックして、データ保護情報を表形式で表示します。テーブル画面はさらに保護ドメインビューとリモートサイトビューに分けられます。保護ドメイン情報を表示するにはAsync DRまたはMetro Availabilityタブをクリックし、リモートサイト情報を表示するにはRemote Siteタブをクリックします

ページセレクタ

テーブルビューでは、リモートサイトと保護ドメインはページあたり10個表示されます。リストに10項目を超える項目がある場合は、合計ページ数と現在のページのページ数とともに、左右のページング矢印が右側に表示されます。

テーブルの内容をエクスポート

テーブルビューでは、⻭⾞のアイコンをクリックしてCSVまたはJSON形式のいずれかのファイルにテーブル情報をエクスポートすることができます。プルダウンメニューから[Export CSV]または[Export JSON]を選択します。

テーブルの内容を検索

テーブルビューでは、検索フィールドに文字列を入力してテーブル内の特定のコンテンツを検索できます

７．Metro Availability Witness Option

Metro Availability構成にWitnessを追加することもできます。「Witness」とは、Metro Availabilityの設定状態を監視する特別な仮想マシンです。Witnessは別の障害ドメインに常駐し、Metro Availabilityサイト間のネットワーク障害とサイト障害を区別できる外部ビューを提供します。

Witnessの⽬的は、サイトの障害やサイト間のネットワーク障害が発⽣した場合にフェールオーバーを⾃動化することです。Witnessの主な機能は次のとおりです。（現状はESXiのみをサポート）

• サイトまたはサイト間のネットワークに障害が発⽣した場合にフェイルオーバーを決定する
• （たとえば）WAN障害のために両⽅のサイトで同じストレージコンテナーがアクティブに なっているスプリットブレイン状態を回避する
• 単⼀のストレージまたはネットワークドメインで障害が発⽣した場合の処理

Metro Availability 障害プロセス(Witnessなし)

プライマリサイトの障害（Metroストレージコンテナーが現在アクティブなサイト）またはサイト間のリンクがオフラインになった場合、Nutanix管理者はMetro Availabilityを⼿動で無効にしてリモートのターゲットストレージコンテナーを昇格する必要があります（または現在の）サイトをアクティブにします。

セカンダリサイトとの通信に障害が発⽣した場合（サイトの停⽌またはサイト間のネットワークリンクの停⽌による）、Metro Availabilityは設定に応じて次のいずれかを実⾏します（⾃動または⼿動）。

自動：指定した時間内にセカンダリサイトの接続が回復しない場合、システムは一時停止後にプライマリサイトのストレージコンテナのMetro Availabilityを自動的に無効にします

手動：システムは管理者が手動で処置をとるのを待ちます

Metro Availability 障害プロセス(Witnessあり)

Witnessを追加すると、サイトの機能停⽌やネットワーク障害が発⽣した場合にMetro Availabilityを 無効にしてストレージコンテナを昇格させるプロセスが完全に⾃動化されます。Witness機能は障害が発⽣した場合にのみ使⽤されます。つまり、Witness障害⾃体はどちらのサイトで実⾏されている仮想マシンにも影響しません。

Metro Availability 運用モード

Witnessを追加した後、3つのMetro Availability操作モード（Witnessモード（新）、⾃動再開モード、⼿動モード）から選択できます。障害シナリオに対するMetro Availabilityの応答は、選択されている 動作モードによって異なります。次の表に、動作シナリオに基づく障害シナリオと応答動作を詳しく⽰します。

Witnessの要件

Witnessを設定する際には、いくつかの要件があります。

• Witness VMには（少なくとも）以下の要件があります。

            2つのvCPU

            6 GBのメモリ

            25 GBのストレージ

• Witness VMは個別の障害ドメインに存在する必要があります。これは、各Metro Availabilityサイトからの独⽴した電源およびネットワーク接続を意味します。Witness VMは3番⽬の物理サイトに配置することをお勧めします。 このサイトでは、単⼀障害点を回避するために、サイト1と サイト2への専⽤ネットワーク接続が必要です。
• Metro Witnessとの通信はポートTCP 9440を介して⾏われるため、Witnessを使⽤するMetroクラスタ上の コントローラVMに対してこのポートを開く必要があります。
• 各Metro AvailabilityサイトとWitness VM間のネットワーク 遅延は、200ミリ秒未満でなければなりません。
• Witness VMは、サポートされている任意のハイパー バイザーに常駐することができ、NutanixまたはNutanix以外のハードウェアのどちらでも実⾏できます。
• 1つのWitness VMに複数の（異なる）Metroクラスタペアを 登録できますが、クラスタペアあたり50のWitnessed Metro 保護ドメインという制限があります。

以上がNutanixのデータ保護に関する説明になります。

よろしくお願いします。

Nutanixのデータ保護について(その 1)

みなさん、こんにちは

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

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

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

内容は若干長いため、2回に分けてご紹介します。

(画像の⼀部はNutanix様の資料から拝借させて頂いております)

１．Site Failover Operations

サイトがフェイルオーバーした時のオペレーションのことを考えてみましょう。

まず、スナップショットとレプリケーションのスケジュールを設定した後で、あるサイトから別のサイトにフェイルオーバーする必要があるかもしれません。 3つのフェイルオーバーシナリオが可能です。

計画的フェイルオーバー︓

両⽅のサイトが稼働していて、その構成が正しく機能することをテストしたい場合、または1次サイトの計画的保守またはサイト拡張の前にフェイルオーバーします

災害時フェイルオーバー︓

プライマリサイトが停⽌したときのフェイルオーバー

フェイルバック︓

システム停⽌を解決してプライマリサイトに戻したい場合に、復旧サイトから計画的フェイルオーバーを開始します

2．計画的なフェイルオーバーもしくはフェイルバック

この操作は以下のことを行います。 

• 保護ドメインのスナップショットを作成して複製します。 
• ローカルサイトのVMをシャットダウンします。 
• 保護ドメインの別のスナップショットを作成して複製します。 
• すべてのVMの登録を解除し、それらに関連付けられているファイルを削除します。 
• ローカルサイト保護ドメインを非アクティブとしてマークします。 
• 最後のスナップショットからすべてのVMファイルを復元し、それらをリモートサイトに登録します。 
• リモートサイト保護ドメインをアクティブとしてマークします。 

３．災害時フェイルオーバー/保護ドメイン

災害時フェイルオーバー操作は以下のことを行います。 

• 最後の完全複製スナップショットからすべてのVMファイルを復元します。
• 復旧サイトにVMを登録します。
• フェールオーバーサイト保護ドメインをアクティブとしてマークします。

保護ドメイン変更操作は以下のことを行います。 

既存の保護ドメインを変更するには、ドメインモードの変更（アクティブ/非アクティブ）、ドメインの複製、ドメインの移行、ドメイン設定の更新、またはドメインの削除を行います。 

４．保護ドメインのガイドライン

メトロアベイラビリティポリシーを適用するための一般的なガイドライン

保護ドメインは、ローカルクラスタ上のプライマリストレージコンテナと、リモートクラスタ上の同じ名前のスタンバイストレージコンテナを指定することによって作成されます。以下は、メトロアベイラビリティを適用するための設定とガイドラインです。 

• ストレージコンテナをメトロアベイラビリティで使用する場合、データストア名はストレージコンテナ名と同じである必要があります。 
• 2つのサイトにわたるデータストアの可用性を確保するには、両方のサイトにリアルタイムでデータが存在する必要があります。したがって、クラスタ間のラウンドトリップレイテンシは5ms未満である必要があります。
• ピーク書き込みに対応するために十分な帯域幅を維持します。サイト間に冗長な物理ネットワークを用意することをお勧めします。 
• 特定のVMに関連付けられているすべての仮想ディスクが、メトロアベイラビリティが有効になっているコンテナに存在することを確認します。 
• 保護されたVMは、アクティブストレージコンテナに関連付けられているNutanixクラスタまたはスタンバイストレージコンテナに関連付けられているクラスタのどちらでも実行できます。ただし、スタンバイストレージコンテナに関連付けられているクラスタ上でVMが実行されていると、アクティブストレージコンテナへのネットワークを介して読み取りと書き込みが行われます。したがって、ネットワークトラフィックとそれに関連するネットワークの待ち時間を減らすために、VMのデータが存在するアクティブコンテナに対してVMのデータがローカルに実行されるアクティブコンテナに対してVMをローカルに実行することをお勧めします。 
• メトロアベイラビリティポリシーはストレージコンテナ（クラスタではなく）ごとに適用されるため、クラスタはあるデータストアに対してアクティブで、別のデータストアに対してスタンバイになることができます。たとえば、ストレージコンテナ1にOracleデータストア（データストアA）、ストレージコンテナ2にExchangeデータストア（データストアB）を持つクラスタ構成を考えます。クラスタAはデータストアAに対してアクティブで、クラスタBはスタンバイです。データストアBに対してアクティブで、クラスタAをスタンバイにします。さらに、メトロアベイラビリティのストレージコンテナは、同じクラスタ内の通常のストレージコンテナと共存できます。 

５．VMセントリックのデータ保護

AOSは、ネイティブのオンサイトバックアップと、オフサイトバックアップおよびディザスタリカバリ用のリモートレプリケーションの両方に統合データ保護ソリューションを提供します。

これらの機能は、スナップショットがソースVMと同じクラスターに格納されるタイムストリームと、スナップショットがクラスター間で非同期に複製されるサイト間レプリケーションの2つのユースケースで使用できます。 

VMのスナップショットはクラッシュコンシステントです。つまり、VMDKのオンディスクイメージは一時点で一貫性を保っています。つまり、スナップショットはVMがクラッシュしたかのようにディスク上のデータを表します。状況によっては、スナップショットもアプリケーションと整合性があります。

つまり、スナップショットの時点でアプリケーションデータが静止します。アプリケーション整合性のあるスナップショットは、ESXiハイパーバイザーによってホストされているVMにインストールできる一連のユーティリティであるVMware Toolsを介して適用されます。この機能はVSSを起動してVM用のアプリケーション整合性のあるスナップショットを作成します。これは単一のVMを持つ整合性グループに限定されます。

スナップショットは、定義されたスケジュールまたは必要に応じて作成できます。作成されたすべてのスナップショットは有効期限に関連付けられており、有効期限が過ぎるとNutanixクラスタは自動的にスナップショットを削除します。重要ではないVMファイル（スワップファイルやログファイルなど）はスナップショットに含まれません。 

６．データ保護の概念

データ保護に関してはこちらのような概念があります。それぞれに関しての説明を行いたいと思います。

• 保護ドメイン

保護ドメインについては⾮同期DRとMetroAvailabilityの2種類でドメインが存在することを覚えて頂ければと思います。

保護ドメイン（非同期DR）：標準保護ドメインは、クラスター上でローカルにバックアップされ、オプションで1つ以上のリモートサイトに複製された定義済みのVMのグループです。このタイプの保護ドメインは、スナップショットを作成するために非同期データ複製Async D）を使用します。

保護ドメイン名はサイト間で一意である必要があります。 VMは最大1つの保護ドメインに属することができます。クラスタ上の保護ドメインは、次の2つのモードのいずれかにあります。 

アクティブ：稼働中のVMを管理します。スナップショットを作成、複製、およびExpireします。 

非アクティブ：リモートクラスタからスナップショットを受け取ります。 

保護ドメイン（メトロ可用性）：メトロ可用性保護ドメインは、メトロ可用性が有効になっているときに同期データ複製が行われるリモートサイトの同じ名前の（スタンバイ）コンテナにリンクされたローカルクラスタの指定（アクティブ）コンテナで構成されます。 

• 整合性グループ

整合性グループは、保護ドメイン内のVMのサブセットです。 （保護ドメインを作成するときに整合性グループが構成されます）。その保護ドメインのコンシステンシグループ内のすべてのVMは、クラッシュコンシステントな方法でスナップショットを取られます。コンシステンシグループ内のすべてのVMに対して、スナップショットはグループ内のすべてのVMに対して1つのスナップショットを作成します。 

データ保護を⾏う上で重要なのは、スナップショットを取ったデータが整合性を保っていることが重要です。リストア後に整合性が保った状態に戻すのはアプリケーション次第ではあるが、クラッシュコンシステントのバックアップで停電後でも仮想マシンの電源⼊れている状態に戻せるようにしておきましょう。仮想マシンには必ずNGT（Nutanix Guest Tools）を⼊れておきましょう。

• スナップショット

スナップショットについては、特に説明する内容はほとんどないので、画⾯イメージを載せておきます。

• タイムストリーム

タイムストリームについても、スナップショットと同様のお話ですので、画⾯イメージを掲載のみです。

• タイムストリーム

リモートサイトは、バックアップデータを複製するためのターゲットの場所として使用される独立したクラスタです。リモートサイトは、別の物理クラスタまたはパブリッククラウドにあるクラスタのどちらでもかまいません。 1つのクラスタに1つ以上のリモートサイトを設定できます。 

• レプリケーション

レプリケーションとは、スナップショットを1つのクラスタから1つ以上のリモートサイトに非同期的にコピーするプロセスです。いくつかのレプリケーションシナリオがサポート

レプリケーションについては、１つもしくは複数サイトにレプリカを作成することができます。注意事項としては、マルチサイトで複製取る場合には、ライセンスのエディションにご注意下さい。（UltimateもしくはPro Edition選択時はオプションのライセンスが必要になります）

• スケジュール

スケジュールは、スナップショットをとる間隔とスナップショットを保持する期間を指定する保護ドメインの特性です。 （保護ドメインを設定するときにスケジュールが設定されます）。スケジュールは、どのリモートサイトに複製するかをオプションで指定します。 

スケジューリングについては、⾮同期DRについては間隔が短い場合はNear Syncになりますので、その場合は仕様も含めて確認してから設定してください。

本⽇のデータ保護の説明は以上とさせて頂きます。

次回は、複製の⽅式についてご説明したいと思います。

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

Nutanixにおけるハイパーバイザーの変換プロセスについて

みなさん、こんにちは

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

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

今回はNutanixのハイパーバイザーの変換プロセスについてご紹介します。

NutanixではハイパーバイザーをESXiからAHVへの変換することができます。

ハイパーバイザーを変換する際のプロセスがいくつかあるので覚えて頂ければと思います。

1. ESXiからAHVへの変換について

変換プロセスを開始すると、クラスタ内のすべてのノードが1つずつAHVに変換されます

ESXiホストの現在の状態は、ESXiに戻すために保存されます。Foundation内部でESXiホストをAHVに変換します

最初に、すべてのコントローラーVMがAHVに移行されます。コントローラVMがAHV側で起動した後、ESXiで実行されているVMはAHVに移行されます

仮想マシンの移行が完了したら、AHVで仮想マシンを手動で起動する必要

すべてのホストと仮想マシンがAHVに移行されたら、AHVクラスターの使用を開始します。

2. 仮想マシンの変換

ハイパーバイザーの変換ということはつまり仮想マシンも変換することになります。

そのため、仮想マシンにNGT（Nutanix Guest Tools）をインストールして変換を開始すると、仮想マシンの変換も同時に行われます。変換プロセスは以下のようになります。

①検証

クラスタ内の仮想マシンが変換可能かどうか検証します。

②起動

変換を⾏います。変換のプロセスは記録されます。

③仮想マシン変換ためのノードを準備

ノード内の仮想マシンの情報はノードのUUIDに応じて収集され、仮想マシンが保護されているときには変換はできません。仮想マシンはマスター変換レコードに格納されていて、仮想マシンファイルは変更されません。

④仮想マシンの変換を実⾏

ノードの変換レコードを参照して、ハイパーバイザータイプを⽐較して、変換先のハイパーバイザーに変換します。仮想マシン変換後は仮想ネットワークなどもハイパーバイザーの情報に合わせて変換を⾏います。変換が完了すると変換元の仮想マシンファイルは削除されます。

3. ポートグループとVLANの変換およびAHVからESXiへの変換について

ポート仮想マシン変換ためのノードを準備

特定のグループに属するすべてのESXiポートグループ、すべてのVLAN ID、および仮想マシンがキャプチャされ、クラスタ上のすべての一意のESXiポートグループに対応するAcropolis仮想ネットワークが作成され、対応するVLAN IDが割り当てられてからVM正しい仮想ネットワークに転送されます。 

ESXiホストの管理ポートグループにVLANが設定されている場合は、変換後にAcropolis管理インターフェースとController VMパブリックインターフェースが同じVLANに配置されます。 

AHVからESXiへの変換プロセス

逆方向の変換（AHVからESXiへの変換）の間、変換のプロセスは類似しています。

また、クラスタにESXi ISOが保存されていない場合は、変換プロセス中にESXi ISOイメージを提供する必要があります。

注：提供するイメージは、ESXiからAHVへの変換中に使用したものと同じ主要なESXiバージョンのものである必要があります。

４. クラスタ変換作業の中止について

クラスタ変換作業も必ず成功するわけではありません。失敗してしまった時に戻せなくなるのではないかと⼼配する⽅もいらっしゃるかと思いますが、Nutanixの変換作業で失敗したときは失敗した内容のポップアップが表⽰されます。こちらで元の環境に戻すかどうか聞かれるので、「Yes」をクリックすると元の環境に戻すことが可能です。

ハイパーバイザーの変換は通常の変換作業以外にも、DR先にレプリケーションする時もクロスハイパーバイザーでDRするときも同様のことが⾏われます。

以上、参考情報として読んで頂ければと思います。

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

Nutanixの障害シナリオについて学んでみよう！

みなさん、こんにちは

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

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

今回はNutanixの障害シナリオについてご紹介します。

Nutanixはハードウェアおよびソフトウェアで構成されておりますが、ホストなどのハードウェアが障害があるケース、CVMなどのソフトウェアの障害またはネットワークなどの障害により挙動が違ってきます。今回はその想定される障害シナリオについていろいろとお話したいと思います。

1. 障害シナリオについて

上記イメージを見て頂ければと思いますが、この中で、⾼密度型で導⼊していないお客様については、ブロックに関する障害はあまり関係ありませんが、どのようなケースなのかを覚えて頂くことも良いかもしれません。

２. ノード障害について（コントローラVMの障害）

ノード障害は物理障害であるため、ホスト・CVMの両コンポーネントがアクセスできなくなります。そのため、正常な物理ホストのみでクラスタを構成できるようになります。

こちらのスライドはその障害判断プロセスを記載しています。

実際に障害あった場合、ユーザはどのようにして気が付くのでしょうか︖それを以下に記載します。

ユーザーには何が通知されるのでしょうか︖

切り替え処理中に障害が発⽣したコントローラVMを持つホストは、共有ストレージが使⽤できないと報告 することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」しているように⾒えます。ゲストVMデータのプライマリコピーは、障害が発⽣したコントローラVMにマップされたディスクに格納されているため使⽤できませんが、そのデータのレプリカにはまだアクセス できます。リダイレクトが⾏われるとすぐに、VMは読み取りと書き込みを再開できます。

I/Oが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10GbEネットワークを通過するため、 ほとんどのワークロードはユーザーに認識されるようには減少しません。

別のノードが障害になった場合はどうなりますか︖

2番⽬のコントローラVMの障害は他のホストのVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してI/O要求を送信します。しかし、さらに重要なことは、ゲストVMデータに追加のリスクがあることです。2つのコントローラVMを使⽤できないため、アクセス不能な2つの物理ディスクセットが存在するようになりました。RF2を持つクラスタでは

少なくとも1つのコントローラVMが動作を再開するまで、⼀部のVMデータエクステントが完全に⽋落する可能性があります。

３. ノード障害について（ホスト障害）

ホスト障害時の挙動についてはこちらをご覧ください。

ノード障害が発⽣すると、他のノードでVMが再起動しますが他のノードにデータが存在していれば、問題なくデータにアクセスすることができます。ただし、3ノードで構成した場合は、障害時は正常なクラスタではありませんので、早急に復旧が必要になります。

ユーザーには何が通知されるのでしょうか︖

HA保護されたVMにアクセスしているユーザーは、新しいホストでVMを再起動している間はそのVMを 使⽤できないことに気付きます。HAなしでは、VMを⼿動で再起動する必要があります。

別のノードが障害になった場合はどうなりますか︖

2番⽬のホストの障害により、残りのホストの処理能⼒が不⼗分になり、2番⽬のホストからVMを再起動 する可能性があります。ただし、負荷の軽いクラスタであってもゲストVMデータに対する追加のリスクが懸念されます。

アクセス不能な2組の物理ディスクを使⽤すると、⼀部のVMデータエクステントが完全に失われる可能性があります。

４. ドライブ障害について

ドライブには起動⽤の領域のブートドライブ、階層化データやOplog（書き込みデータ）がSSDおよびHDDなどのデバイスに格納されています。

コールド層の永続データは、ノードのハードディスク・ドライブに格納されます。ストレージメタデータ、ホットプラグ、ホットティア永続データ、コントローラVMブートファイルは、ドライブベイ1のSATA-SSDに保存されます。2つのSATA-SSDを搭載したシステムでは、追加のホット層DSFデータストレージに2台目のドライブを使用します。

オールフラッシュノードでは、すべてのタイプのデータがSATA-SSDに格納されます。

ブートドライブの障害

各コントローラVMはSATA-SSDもしくは2枚のM.2 SSDを利用して起動します。かつてはブートドライブの冗長化はされていなかったのですが、最近はRAID1構成の冗長化になっていることから、1枚のM.”デバイスの障害に耐えられる構成になっています。
クラスタの運用中は、このドライブにもコンポーネントログと関連ファイルが保存されます。

ブートドライブの故障により、最終的にはコントローラVMが異常終了します。ホストはブートドライブに直接アクセスしないため、他のゲストVMは引き続き実行できます。データパス冗長性は、ストレージパスを別のコントローラVMにリダイレクトします。

メタデータドライブの障害

メタデータドライブは多くの目的に役立ちます。各ホストのoplogを保持し、書き込み要求を送信するVMに高速応答を提供します。永続データ層として使用されます。また、Cassandraデータベースはクラスタメタデータに対する高速な読み書き応答を提供するためにも使用されます。これらのストレージ使用はすべて障害の可能性を考慮して設計されているため、クラスタ内の他のメタデータディスクに複製されます。

メタデータドライブ（SSD）とデータドライブ（HDD・オールフラッシュ構成はSSD）については、クラスタ全体で複製されているため、単⼀障害では特に影響できることはありません。

メタデータドライブに障害が発生した場合、問題を認識する最初のコンポーネントはCassandraです。

データベースのシェアにアクセスできなくなり、問題を解決するための再起動の継続的なサイクルが開始されます。

StargateはMedusaを通じてCassandraと依存関係にあるため、最終的にStargateは障害を起こしたことをクラスタによって検出され、パスはデータパスの冗長性に基づいて自動的にリダイレクトされます。まもなく、障害があったメタデータドライブを持つホストは、ネットワーク経由で別のStargateにリダイレクトされます。

Cassandraプロセスがノードで5分以上ダウンした場合、残りのCassandraノードはCassandraデータベースからノードを切り離し、使用できないメタデータを他のノードに複製することができます。データベースを修復するプロセスは約30〜40分かかります。

Cassandraプロセスが再起動して5分間継続した場合、回復手順がまだ実行中の場合、ノードを切り離す手順はキャンセルされます。回復手順が完了してからプロセスが再開し安定した場合、nCLIコマンドを使用してノードを手動でデータベースに追加できます。

ncli> host enable-metadata-store id = cvm_id 

ユーザーには何が通知されるのでしょうか︖

スイッチング処理中に障害が発⽣したSSDのホストは、共有ストレージが使⽤できないと報告することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」するように⾒えます。

リダイレクトが⾏われるとすぐにVMは読み取りと書き込みを再開できます。I/Oが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10 GbEネットワークを経由するため、ほとんどのワークロードはユーザーに認識されるようには減少しません。

別のノードが障害になった場合はどうなりますか︖

2番⽬のメタデータドライブの障害は、他のホスト上のVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。

Cassandra Ringの回復機能は、第2の障害が回復プロセスが完了する前に起こらない限り、第2のノードを失うことに伴うリスクを軽減する。

データドライブの障害

各ノードはデータ・ドライブをクラスター・ストレージ・プールに提供します。

コールドデータはHDDに保存され、ホットデータはSSDに保存されて高速のパフォーマンスが得られます。

HDDには可動部品があり、他のハードウェアコンポーネントを上回っているため、故障が発生する可能性が最も高いコンポーネントです。データはクラスタ全体に複製されるため、単一のハードディスクドライブに障害が発生してもデータが失われることはありません。オールフラッシュノードでは、すべてのタイプのデータがSSDに格納されます。

クラスタソフトウェアは、ホストからデータドライブ（HDDまたはSSD）に障害が発生したハードウェアアラートを受信し、直ちに作業を開始して2回目の障害の影響を軽減します。Curatorはドライブに格納されているゲストVMデータの2番目のレプリカを作成するようにStargateに指示します。

５．ネットワークリンクの障害

各ホストの物理ネットワークアダプタは外部ネットワーク上でグループ化されています。両方の10GbEポートが顧客のネットワークに接続されている場合、ネットワークリンクの障害はユーザーに影響を与えずに許容されます。クラスタが1GbEリンクにフェイルオーバーする必要がある場合、書き込みパフォーマンスは低下します。

Nutanixを構成する際はほとんど10GbEの構成になると思いますので、現状気にする必要はないと考えられます。

６. ブロックフォールトトレランスについて

ブロックフォールトトレランスはNutanixクラスタが任意のデータの冗長コピーを作成し、同じブロックにないノードにデータを配置する機能です。また、メタデータはブロックフォールトトレラントでなければならない。

ブロックは、 1〜4個の2U4Nのノードを含むラックマウント型筐体です。電源装置、フロントコントロールパネル、バックプレーン、およびファンは、ブロック内のすべてのノードで共有されます。

ブロックフォールトトレランス機能を有効にすると、ゲストVMデータとメタデータの冗長コピーが他のブロックに存在するため、ゲストVMはブロック障害を発生したまま実行されます。

特定の条件が満たされると、Nutanixクラスタはブロックフォールトトレラントになります。ブロックフォールトトレランス機能は、クラスタ内の各ストレージ階層には、各ブロックに少なくとも1つのドライブが含まれています。

クラスタ内のすべてのストレージコンテナには、少なくとも2つのレプリケーションファクタがあります。

RF2の場合、クラスタには最低3つのブロックがあります。

クラスター内の少なくとも複製ファクター数のブロックには、すべての層に十分な空き領域があります。例えば、クラスタ内のストレージコンテナのレプリケーションファクタが2である場合、少なくとも2つのブロックに空き領域が必要です。

Eraser Codingは、どのストレージコンテナにおいても有効にしてはいけない。

（AOS5.8よりブロック環境においてもEraser Codingをサポート）

ブロックフォールトトレランスの状態は、Prism Web ConsoleおよびNutanix CLIで表示できます。

管理者はストレージ階層またはストレージコンテナを設定する必要がありますが、データの移行先は特定できません。AOSはデータの移行先を決定します。

ブロックフォールトトレランス条件が満たされると、クラスタは特定の数のブロック障害に耐えられます。

• 3つ以上のブロックを有するRF2またはRF3 クラスタは、1つのブロックの最大障害を許容することができる。
• 5つ以上のブロックを有するRF3クラスタは、2つのブロックの最大障害を許容することができる。

ブロックフォールトトレランスはResiliencyの一部です。インフラストラクチャのかなりの部分が利用できない状況では、ディスク領域とCPU /メモリリソースの可用性などの他の制約は取り除かれません。

ブロックのフォールトトレランスには、メタデータのブロック認識が必要です。RF2およびRF3に対してメタデータブロックのAwareness機能を有効にすることができます。メタデータブロックのフォールトトレランス機能を有効にするには、メタデータが上記のReplication Factorの要件を満たしている必要があります。

7. ブロックフォールトトレラントデータ配置

Stargateはブロック間でデータを配置する役割を果たし、CuratorはStargateにデータ配置要求を行いブロック耐障害性を維持します。

新しいクラスタと既存のクラスタは、ブロックフォールトトレラントな状態になります。新しいクラスタは構成がサポートしていれば、作成直後にフォールトトレラントにすることができます。以前はフォールトトレラントではなかった既存のクラスタは、ブロックフォールトトレランスをサポートする方法でクラスタを再構成することで耐性を持たせることができます。

ブロックフォールトトレラントクラスタ内の新しいデータは、ブロックフォールトトレランスを維持するために配置されます。ブロック耐障害状態にない既存のデータは、キュレーターによってブロックフォールトトレラント状態に移動およびスキャンされます。

再配置が必要なデータの量に応じて、ブロック間でデータを配信するために、キュレーターが数時間にわたって複数のスキャンを実行することがあります。

ブロックフォールトトレラントデータ配置はベストエフォートベースで行われますが保証はされません。ブロック間のディスク使用率が高いなどの条件により、クラスタがゲストVMの冗長コピーデータを他のブロックに配置できなくなる可能性があります。

以下にわかりやすいイメージを載せておきますので、参考にして頂ければ幸いです。

メタデータ/構成データ

Nutanix MedusaコンポーネントはCassandraを使用してメタデータを格納します。Cassandraはリング内のピアにデータをコピーしてデータの一貫性と可用性を確保するリング型の構造を採用しています。クラスタはメタデータの少なくとも3つの冗長コピーを保持します。少なくとも半分は一貫性を確保するために利用可能でなければなりません。

ブロック・フォールト・トレランスでは、Cassandraのピアはブロック間に分散され、同じブロックに2つのピアが存在

しないようにします。ブロックに障害が発生した場合、少なくとも2つのメタデータのコピーがクラスタに存在します。

Nutanix Zeusコンポーネントは、Zookeeperを使用してクラスタの必須の構成データを格納します。Zookeeperの役割はブロックに障害が発生した場合の可用性を確保するためにブロック間で分散されます。

８. Redundancy Factor3

Redundancy Factor3はNutanixクラスタが2つのノードまたは異なるブロックのドライブの障害に耐えることを可能にする構成可能なオプションです。

デフォルトではNutanixクラスタはRedundancy Factor2を持ちます。つまり、単一のノードまたはドライブの障害を許容することができます。クラスタが大きいほど、複数の障害が発生する可能性が高くなります。Redundancy Factor3が

ないと複数の障害が発生すると、障害が修復されるまでクラスタが使用できなくなります。

Redundancy Factor3には次の要件があります。

• クラスタにはRedundancy Factor3を有効にするために、少なくとも5つのノードが必要
• ゲストVMが異なるブロック内の2つのノードまたはドライブの同時障害を許容するには、RF33のストレージコンテナにデータを格納する必要
• コントローラVMは少なくとも24GB以上のメモリで構成する必要があります。

Redundancy Factor3のイメージ

メタデータ/構成データ

メタデータの冗長コピーの少なくとも半分は、一貫性を確保するために利用可能でなければなりません。 Redundancy Factor3がない場合、クラスタはメタデータの3つのコピーを保持します。 Redundancy Factor3の場合、クラスタは5つのメタデータを保持し2つのノードに障害が発生した場合、少なくとも3つのコピーが使用可能になります。

Nutanix Zeusコンポーネントは、Zookeeperを使用してクラスタの必須の構成データを格納します。 Redundancy Factor3がない場合、クラスタは構成データの3つのコピーを保持します。 Redundancy Factor3の場合、クラスタは構成データのコピーを5つ保持し2つのノードに障害が発生した場合、少なくとも3つのコピーを使用できるようにします。

９. 劣化ノード (Degrade Node)

劣化ノードには、完全に応答しない状態ではないCVMが含まれていますが、正常なクラスタ操作を確実に実行することはできません。劣化した（または部分的に利用可能な）ノードはクラスタ全体のパフォーマンスに悪影響を及ぼします。劣化ノード検出は、劣化ノードの結果を軽減するために導入されています。劣化ノードを継続して実行するとクラスタ全体とユーザーVMのパフォーマンスに影響を与える可能性があります。劣化したノード検出を有効にすることにより、ZooKeeperはノードをメンテナンスモードにします。メンテナンスモードではノードをリーダーシップの位置から移動し、タスクを自動的に配布します。

劣化したノードのアラートは、Webコンソールの[アラート]ページに表示されます。

以下のイベントは、ノードの劣化に寄与する可能性があります。

• ネットワーク帯域幅の削減
• ネットワークパケットドロップ
• ソフトロックアップ
• 部分的に不良なディスク
• ハードウェアの問題（ECCエラーのある信頼性の低いDIMMなど）

劣化ノード検出は、ピア正常性グローバルデータベースで構成されます。これらのサービスは、クラスタの各ノードで実行されます。各ノードは、他のノードで実行されているサービスに対してスコア発行。ピア・スコアは、次のようなメトリックを評価します。

リモートプロシージャコール（RPC）の待ち時間

RPCの失敗またはタイムアウト

ネットワーク待ち時間

1つのノードが約10分間低いスコアを一貫して受信した場合、ピアはそのノードを劣化ノードとしてマークします。

クラスタリングアルゴリズムは、異常値を識別するために使用されます。

劣化ノードの検出

ノードが不良ピアスコアを受信し始めたときに、Webコンソールはユーザーに警告します。数分のスコアが悪いとノードは劣化しているとマークされます。

劣化したノード検出ソフトウェアは、障害の影響を緩和しクラスタ全体への影響を軽減します。影響を軽減するために、このソフトウェアは次のいずれかの操作を実行できます。プロンプトが表示されたら、

次のいずれかを選択します。

• 劣化したノードのコンポーネントがリーダーシップの役割を獲得できないようにする
• 劣化ノードCVMを保守モードにしてCVMを再起動し、サービスを停止します
• ホストをシャットダウンする

劣化ノードの検出の有効化

Webコンソールで劣化したノード検出設定を有効にします。

1. クラスタのWebコンソールにログインします。
2. ページの隅にある歯車のアイコンをクリックします。
3. Degraded Node Settingsをクリックします。劣化ノード設定ウィンドウが表示されます。
4. 劣化ノードの検出ステータスを「縮退ノード検出を有効にする」に設定します。　
   チェックボックスをオンにすると、劣化ノードの検出が有効になります。
   それ以外の場合は、劣化ノードの検出を無効にする場合は、ボックスをクリアしてください。
5. [保存]をクリックして設定を確定します。劣化ノード設定ウィンドウが閉じて、Webコンソールには、ポップアップの確認が表示されます。
6. アラートポリシーを更新し、アラートを有効または無効にするには：
   １．Webコンソールで、[アラート]をクリックします。
   ２．縮退ノードをクリックすると縮退ノードウィンドウが表示されます。
   ３．可能な劣化ノードのサイドバー、クリック可能な劣化のノードを。ノードは、数分間の不良ピア・スコアを受信した後、劣化とマークされます。
   ４．Update Policyポップアップが表示されます。
   ５．ポリシーを更新し、[保存]をクリックします。チェックボックスをオンにしてポリシーを有効にします。
   ６．チェックボックスをオフにしてポリシーを無効にします。

非常に長い文章になってしまいましたが、障害シナリオの紹介でした。

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

Nutanixのクラスタの コンポーネントを覚えてみよう︕

みなさん、こんにちは

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

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

今回はNutanixのクラスタのコンポーネントをご紹介します。

今回の内容については、Nutanix Bible(http://nutanixbible.jp/)にも記載している内容になりますが、実際には単語レベルでの説明はあるものの各プロセスについての詳細に書かれていないため、筆者が理解できるようにいろいろとまとめてみました。

Nutanixクラスターには分散アーキテクチャーがあり、クラスター内の各ノードはクラスタリソースおよびその重要性を共有しています。各ノードにはクラスタ操作中に特定のタスクを実⾏するソフトウェアコンポーネントがあります。

すべてのコンポーネントは、クラスタ内の複数のノードで実⾏され、コンポーネントを実⾏する役割の間で接続が依存しています。ほとんどのコンポーネントは、他のコンポーネントにも依存しています。

Zeus

分散システムの重要な要素は、すべてのノードがクラスターの構成を保管して更新します。内容はホストやディスクなどのクラスタ内の物理コンポーネント、およびストレージコンテナなどの論理コンポーネントに関する詳細が含まれます。

これらのコンポーネントの状態（IPアドレス、容量、データ複製ルールなど）もクラスタ構成に格納されます。

Zeusは他のすべてのコンポーネントがクラスタ構成にアクセスするために使⽤するNutanixライブラリです。現在、Apache Zookeeperを使⽤して実装されています。

Cassandra

CassandraはNutanixデータストアに格納されているゲストVMデータに関するすべてのメタデータを格納している分散型の⾼性能でスケーラブルなデータベースです。NFSデータストアの場合、Cassandraはデータストアに保存された⼩さなファイルも保持します。ファイルのサイズが512Kに達すると、クラスタはデータを保持するvDiskを作成します。

Cassandraはクラスタのすべてのノードで実⾏されます。これらのノードはGossipプロトコルを使⽤して1秒に1回、互いに通信し、データベースの状態がすべてのノードで最新であることを保証します。

CassandraはZeusに依存して、クラスタ構成に関する情報を収集します。

ZooKeeper

Zookeeperはクラスタに適⽤される冗⻑度に応じて、3つ（RF2）または5つ（RF3）のノードで実⾏されます。複数のノードを使⽤すると失効したデータが他のコンポーネントに返されるのを防ぎます。⼀⽅、奇数を使⽤すると、2つのノードが異なる情報を持つ場合に繋ぎを解除する⽅法が提供されます。

これらの3つのノードのうち、1つのZooKeeperノードがリーダーとして選出されます。リーダは情報の要求をすべて受信し、2つのフォロワノードに付与します。リーダーが応答を停⽌すると、新しいリーダーが⾃動的に選出されます。

Zookeeperには依存関係がないため、他のクラスタコンポーネントを実⾏しなくても起動できます。

Medusa

他のシステム（仮想マシンをホストするハイパーバイザーなど）のデータを格納する分散システムには、そのデータの格納場所を把握する⽅法が必要です。

Nutanixクラスタの場合、そのデータのレプリカが格納されている場所を追跡することも重要です。

Medusaは、このメタデータを保持するデータベースの前に存在しているNutanixの抽象化レイヤーです。データベースは、Apache Cassandraの変更された形式を使⽤して、クラスタ内のすべてのノードに分散されます。

Stargate

他のシステム（ハイパーバイザなど）にストレージを提供する分散システムでは、受信するデータを受信し処理するための統合コンポーネントが必要です。

Nutanixクラスタには、この責任を管理するStargateという⼤きなソフトウェアコンポーネントがあります。

ハイパーバイザーの視点からStargateはNutanixクラスターの主要な接点です。すべての読み取りおよび書き込み要求は、NutanixのvSwitchを介して、そのノード上で実⾏されているStargateプロセスに送信されます。

Stargateはメタデータを収集するMedusaとクラスタ構成データを収集するZeusに依存します。

Curator

分散システムではプロセス全体を監視するコンポーネントを持つことが重要です。未使⽤のデータブロックを指すメタデータが蓄積されたり、ノード間またはディスク階層間でデータのアンバランスが発⽣する可能性があります。

Nutanixクラスタでは、各ノードがこれらの責任を扱うCuratorプロセスを実⾏します。Curatorのマスターノードは、メタデータデータベースを定期的にスキャンし、スターゲイトまたは他のコンポーネントが実⾏すべきクリーンアップおよび最適化タスクを識別します。メタデータの分析は、MapReduceアルゴリズムを使⽤して他のCuratorノード間で共有されます。

Curatorはどのノードが利⽤可能であるかを知るためにZeusに依存し、メタデータを収集するためにMedusaを使⽤します。その分析に基づいて、Stargateにコマンドを送信します。

Prism

ユーザーがアクセスできない場合、分散システムは役に⽴たない。Prismは管理者がNutanixクラスタを構成および監視するための管理ゲートウェイを提供します。

これには、nCLIおよびWebコンソールが含まれます。

Prismはクラスタ内のすべてのノードで動作し、他のコンポーネントと同様に、リーダーを選択します。すべてのリクエストは、Linux ip tablesを使⽤してフォロワーからリーダーに転送されます。これにより、管理者は任意のコントローラVMIPアドレスを使⽤してPrismにアクセスできます。Prismリーダーが失敗した場合、新しいリーダーが選出されます。

Prismはクラスタ構成データ⽤にZeusと通信し、統計情報はユーザーに提⽰するためにCassandraと通信します。また、VMステータスおよび関連情報についてESXiホストと通信します。

少し難しい内容になっておりますが、Nutanixの重要なコンポーネントであるため、今後Nutanix Bibleを読むときに役⽴てて頂ければ幸いです。

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

Nutanixで利用可能なCLI（Command Line Interface）を覚えてみよう！

みなさん、こんにちは

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

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

今回はNutanixで利用可能なCLI(Command Line Interface)をご紹介します。

普段Nutanixを運⽤する場合、Prismを利⽤してGUI上で操作することが多いと思います。
実際にたくさんの処理を実行するためにコマンドを利用したい人や⾃動化したい⼈などはどうしてもCLIが必要になります。Nutanixには複数CLIインタフェースが提供されており、運用者の使い勝手で選択することができます。

CLIの関する使い方も含めてご説明します。

1. Nutanixで利用可能なCLIについて

NutanixのCLIは以下の３つが用意されています。

• nCLI (Nutanix CLI)︓Nutanixのクラスタ（AOS）に対してコマンドで操作できます。主にクラスタやコンテナの情報の参照・設定などを⾏うときに利⽤します。
  （利⽤する場合はJREのインストールが必須になります）
• aCLI (Acropolis CLI)︓AHVのハイパーバイザーに対してコマンドで操作できます。仮想マシンや仮想ネットワークおよびイメージやサービスに関する内容を設定・変更するときに利⽤します。
• PowerShell Cmdlets︓Nutanixのクラスタに対してコマンドで操作できます。nCLIと同様の操作が可能です。（利⽤する場合は、Windows環境が必須になります）

また、CLIを利⽤する場合はCVMなどに直接ログインすることで利⽤することは可能ですが、root権限でオペレーションしてシステムをおかしくすることも考えられます。そのため、どうしても利⽤する場合は、リモートの端末に必要なツールをインストールして利⽤することをお薦めします。

aCLIについては、AHVにログインせずCVM経由でSSHでログインするで利⽤可能です。【192.168.5.1のアドレスでrootでログインすることで利⽤します】

コマンドラインでシステム停⽌もできますが、コマンドの打ち間違いで正常終了しないようなオペレーションしないためにも、通常はPrismでのオペレーションをお願いします。

２. Nutanix Command Line Interface(nCLI)について

Nutanixコマンドラインインターフェース（nCLI）を使⽤すると、次のいずれかのマシンからNutanixクラスターに対してシステム管理コマンドを実⾏できます。

• ローカルマシン（推奨）
• クラスタ内の任意のコントローラVM
  

ローカルマシンへのインストールを推奨しているのは、CVMに対してログインせずにIPアドレスなどの引数で操作ができます。これにより、クラスター全体にローカルマシンから操作できるようになります。

3. nCLIのインストール

1. ローカルマシンから利⽤するJavaRuntime Environment（JRE）のバージョンが5.0以上であることを確認最新版はこちら（http://www.java.com/en/download/installed.jsp）からダウンロード可能です
   
   
2. nCLIをダウンロードします
   ・Nutanix Webコンソールに接続します
   ・コンソール上部のユーザーアイコンをクリックし、[Download nCLI]を選択
   ・ローカルマシンにインストールします
   
   
3. Windowsの％PATH％またはLinuxの$ PATH環境変数を設定します
   ・ncliディレクトリ(例︓c:\ncli)
   ・JRE binディレクトリ（例︓c:\ProgramFiles\Java\jrexxxx\bin）

4. ローカルマシンからnCLIセッションを開始

ローカルマシンへのnCLIのインストール⼿順に従って、ローカルシステムにnCLIをインストールします

1. ローカルマシンでコマンドプロンプトを開きます（Linuxの場合はbash、Windowsの場合はCMDなど）
   
   
2. コマンドプロンプトで、次のいずれかのコマンドを使用してnCLIを起動
   
   lncli -s management_ip_addr -u' username ' -p ' user_password ‘
   この場合、コンソールにパスワードが表⽰されます
   
   lncli -s management_ip_addr -u ' ユーザー名 ' –p
   この場合、パスワードを指定するように求められます
   
   
3. management_ip_addrをクラスタ内のNutanixコントローラVMのIPアドレスに置き換えます
   
   
4. usernameをユーザーの名前に置き換えます（指定されていない場合、デフォルトはadminです）
   
   
5. （オプション）user_passwordをユーザーのパスワードに置き換えます

5. コマンドフォーマット

Nutanixのコマンドラインインターフェースコマンドは、次の形式と一致する必要があります

ncli> entity action parameter1=value parameter2=value ... 

エンティティはクラスタやディスクなどのNutanixエンティティに置き換えることができます。アクションは前のエンティティに対する有効なアクションに置き換えることができます。各エンティティには固有の一連のアクションがありますが、すべてのエンティティに共通のアクションはlistです。

たとえば、次のコマンドを入力してクラスタ内のすべてのストレージプールのリストを要求できます

ncli> storagepool list 

一部のアクションではコマンドの最後にパラメータが必要です。たとえば、NFSデータストアを作成するときは、ハイパーバイザーに表示されるデータストアの名前とソースストレージコンテナの名前の両方を指定する必要があります。

ncli> datastore create name = "NTNX-NFS" ctr-name = "nfs-ctr" 

パラメータと値のペアは、有効なエンティティとアクションが先行している限り、任意の順序で並べることができます。

6. 埋め込みのヘルプ

nCLIは、すべてのエンティティおよびアクションに対する支援を提供します。helpコマンドラインで入力することで、3つの詳細レベルのいずれかで追加情報を要求できます。 

help

エンティティとそれに対応するアクションのリストを提供します

entity help

エンティティに関連付けられているすべてのアクションとパラメータ、および必須のパラメータと任意のパラメータの一覧を提供します

entity action help

アクションに関連付けられているすべてのパラメータのリスト、および各パラメータの説明を提供します

nCLIは各レベルで追加の詳細を提供します。nCLIヘルプ出力の範囲を制御するには詳細パラメータを追加します。詳細パラメータは、trueまたはfalseに設定できます。

たとえば、clusterエンティティのすべてのアクションとパラメータの詳細な一覧を要求するには、次のコマンドを入力

ncli> cluster help detailed = true 

説明なしでcluster edit-paramsアクションのパラメーターのリストを表示する場合、次のコマンドを入力することも可能

ncli> cluster edit-params help detailed = false 

nCLIのエンティティの詳細はNutanix Support Portalのコマンドリファレンスをご参照下さい

７. Acropolis Command-Line Interface(aCLI)

Acropolisは、ホスト、ネットワーク、スナップショット、VMを管理するためのコマンドラインインターフェースを提供します

Acropolis CLIへのアクセス

Acropolis CLIにアクセスするには、SSHでクラスター内のController VMにログオンacliし、シェルプロンプトで⼊⼒

Acropolis CLIを終了してシェルに戻るには、<acropolis>プロンプトでexitと⼊⼒します

8. PowerShell Cmdlets

Nutanixはクラスターと対話するためのPowerShellのCmdletsを提供しています

CmdletsはNutanix クラスターからダウンロードされ、Windowsマシンにインストールされます。Cmdletsがインストールされたら、Nutanix CmdletsをクリックするとデスクトップのショートカットがロードされNutanix CmdletsがPowerShellウィンドウで起動します

PowerShell Cmdletsのインストール

利⽤する前に

PowerShellバージョン2以降および.NET Framework 4.0をワークステーションにインストールします

1. Nutanix Webコンソールにサインイン
2. Webコンソールの右上隅にあるユーザーアイコンをクリックして、[Download Cmdlets Installer]を選択
3. インストーラのダウンロードが完了したら、インストーラをダブルクリックして プロンプトに従います。コマンドレットがインストールされ、デスクトップショート カットNutanix Cmdletsが作成されます。ショートカットをダブルクリックして、Nutanix CmdletsがロードされたPowerShellウィンドウを起動します

９. PowerShell Cmdletsの使用方法

クラスタ接続について

コマンドを実⾏する前に、セッションを1つ以上のNutanixクラスタに接続する必要があります

> Connect-NutanixCluster -Server cluster_ip_address -UserName admin_username ` -Password admin_password'

• cluster_ip_addressをクラスターの仮想IPアドレスまたはコントローラーVMのIPアドレスに置き換えます
• 置き換えadmin_usernameNutanixのユーザー名（通常でadmin）
• admin_passwordをNutanixのユーザーパスワードに置き換えます

複数のConnect-NutanixClusterステートメントを使⽤して複数のクラスタに接続します。セッションが複数の クラスタに接続されている場合は、他のコマンドレットのServerパラメーターを使⽤してコマンドを実⾏するための クラスタを指定します

接続されているクラスターから切断するには、切断元のサーバーのIPアドレスを指定してDisconnect-NutanixClusterを実⾏します

接続クラスタ情報

セッションで接続しているクラスターの詳細を取得するには、Get-NutanixClusterコマンドレットを実⾏します 複数のクラスターに接続されている場合は、接続されているクラスターごとに同じ出⼒を取得するように実⾏できます

Get-NutanixCluster -Server cvm_ip_addr

Cmdletsのバージョン情報

実⾏しているコマンドレットのバージョン詳細を取得するには、Get-NutanixCmdletsInfoのCmdletsを実⾏します

Nutanixの環境を⾃動化したい⼈は利⽤⽅法に気をつけながら是⾮使ってみてください。

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