Prism Central

図は、複数のクラスタをモニタリングおよび管理している状態のPrism Centralダッシュボードの例です：

ここから、環境の全体的なステータスを監視し、アラートや気になる項目がある場合はさらに詳しく調べることができます。

Prism Centralには、以下の主要なページが含まれています（注：検索は、ナビゲーションにおいて優先、推奨される方法です）：

• ホームページ
  • サービスのステータス、キャパシティプラニング、パフォーマンス、タスクなどに関する詳細情報を含む、環境全体をモニターするためのダッシュボード。詳細な情報を取得するには、対象となる項目をクリックします。
• 仮想インフラ
  • 仮想エンティティ（VM、コンテナ、イメージ、カテゴリなど）
• ポリシー
  • ポリシーの管理と作成（セキュリティ（Flow）、保護（バックアップとレプリケーション）、リカバリ（DR）、NGTなど）
• ハードウェア
  • 物理デバイスの管理（クラスタ、ホスト、ディスク、GPUなど）
• アクティビティ
  • 環境全体のアラート、イベント、タスク
• オペレーション
  • 操作ダッシュボード、レポートおよびアクション（X-Play）
• 管理
  • 環境構成の管理（ユーザー、グループ、ロール、アベイラビリティ ゾーンなど）
• サービス
  • アドオンサービスの管理（例えば、Calm、Karbon）
• 設定
  • Prism Centralの設定

メニューにアクセスするには、ハンバーガーアイコンをクリックします：

メニューが展開され、使用可能なオプションが表示されます：

検索

検索は、Prism Central UIを移動するための主な手順になりました（メニューは引き続き使用可能です）。

検索バーを使用して移動するには、画面左上隅にあるメニューアイコンの横にある検索バーを使用します：

Prism Element

Prism Elementには、以下の主要なページが含まれています：

• ホーム (Home) ページ
  • アラート、キャパシティ、パフォーマンス、ヘルス、タスクなどに関する詳細情報を含む、ローカルクラスタをモニターするためのダッシュボードです。詳細な情報を取得する際には、対象となる項目をクリックします。
• Health ページ
  • 環境、ハードウェアおよび管理下にあるオブジェクトのヘルスと状態に関する情報。NCCヘルスチェックステータスも含まれています。
• VMページ
  • 完全なVM管理、モニタリングおよびCRUD (AOS)
• Storageページ
  • コンテナの管理、モニタリングおよびCRUD
• Hardware ページ
  • サーバー、ディスクおよびネットワークの管理、モニタリングおよびヘルスチェック。クラスタの拡張とノードおよびディスクの削除
• Data Protection ページ
  • DR、Cloud ConnectおよびMetro Availabilityの構成。PDオブジェクト、スナップショット、レプリケーションおよびリストアの管理
• Analysis ページ
  • クラスタおよび管理下のオブジェクトに対するイベントの相関関係を含む詳細なパフォーマンス分析
• Alerts ページ
  • ローカルクラスタおよび環境に関するアラート

ホームページでは、アラート、サービスステータス、キャパシティ、パフォーマンス、タスクなどに関する詳細な情報を提供します。詳細な情報を取得する際には、対象となる項目をクリックします。

この図は、ローカルクラスタの詳細を表示している状態のPrism Elementダッシュボードの例です。

異常検出（Anomaly Detection）

IT運用の世界には、多くのノイズがあります。 従来のシステムでは、大量のアラート、イベント、通知が生成されており、多くの場合にオペレーターは、 a) ノイズに紛れて重要なアラートが表示されないか、 b）アラートやイベントを無視していました。

Nutanixの異常検出により、システムは時系列データ（例えば、CPU使用率、メモリ使用率、レイテンシーなど）の季節的傾向を監視し、期待値の「バンド」を確立します。 「バンド」の外にあたる値のみがイベントやアラートをトリガーします。 エンティティまたはイベントのページから異常によるイベントやアラートを確認できます。

以下のグラフは、システムで大規模なバッチロードを実行した際の、多くのI/Oおよびディスク使用率の異常を示します：

以下は、サンプルメトリックと確立された「バンド」の時系列値を示します：

「通常」状態のアラートは望んでおらず、これにより不要なアラートが削減されます。 例えば、データベースシステムは、通常でもキャッシュなどにより95%を超えるメモリ使用率で実行されます。 万が一、これが低下して10%になると、それは何かよくない（データベースサービスのダウンなど）異常かもしれません。

別の例としては、週末のバッチ処理ワークロードがどのように実行されるかです。 例えば、平日にはI/O帯域幅が低く、しかしながらバッチ処理（例えば、バックアップ、レポートなど）が実行される週末には、I/Oに大きなスパイクが発生する場合があります。 システムはこれの季節性を検出して、週末でのバンドを上げます。

ここでは、値が予想される範囲外であるため、異常イベントが発生したことがわかります：

異常のもう1つの興味深いトピックは、季節性です。 例えば小売業者では、年間の他期間より、ホリデー期間中、または月末の終わりに高い需要が見られます。

異常検出ではこのような季節性を考慮し、以下の期間もとにミクロ（毎日）とマクロ（四半期）の傾向を比較します：

• 毎日（Daily）
• 毎週（Weekly）
• 毎月（Monthly）

独自のカスタムアラートまたは静的しきい値を設定することもできます：

Nutanixソフトウェアのアップグレード

Nutanixソフトウェアのアップグレードは非常に簡単で、システムを停止させる必要もありません。

最初に、Prismにログインし画面の右上にある歯車アイコン（設定）をクリックするか、「S」を押し「ソフトウェアのアップグレード (Upgrade Software)」を選択します：

「ソフトウェアアップグレード (Upgrade Software)」ダイアログが表示され、現在のソフトウェアバージョンと、使用可能なアップグレードバージョンが示されます。また、マニュアルでAOSバイナリファイルをアップロードすることも可能です。

これにより、クラウドからアップグレードバージョンをダウンロード、またはマニュアルでアップロードすることができます：

次に、Nutanix CVMにアップグレードソフトウェアをアップロードします：

ソフトウェアのロードが完了したら、「アップグレード (Upgrade)」をクリックし、アップグレード処理を開始します：

確認のためのボックスが表示されます：

アップグレードの事前チェックが行われ、続いてアップグレードが順次進行します。

アップグレードが完了すると、結果が表示され、全ての新しい機能が利用できるようになります：

ハイパーバイザーのアップグレード

Nutanixソフトウェアのアップグレードと同様に、ハイパーバイザーのアップグレードもPrism経由で順次自動的に進行します。

前述と同様に、「ソフトウェアのアップグレード (Upgrade Software)」ダイアログボックスを表示して、「ハイパーバイザー (Hypervisor)」を選択します。

これで、クラウドからハイパーバイザーのアップグレードバージョンをダウンロード、またはマニュアルでアップロードすることができます：

ハイパーバイザーにアップグレードソフトウェアがロードされます。ソフトウェアがロードされたら、「アップグレード (Upgrade)」をクリックしてアップグレード処理を開始します：

確認のためのボックスが表示されます：

システムがホストのプリアップグレードチェック を行い、ハイパーバイザーをアップロードし、クラスタをアップグレードします：

プリアップグレードチェックが完了すると、ハイパーバイザーアップグレードが順次進行します：

Nutanixソフトウェアのアップグレード同様、各ホストのアップグレードも稼動中のVMに影響を与えることなく、順次進行します。 VMは、現在のホストとは別にライブマイグレーションされ、ホストがアップグレードされる通りブートが行われます。 この処理は、クラスタ内の全てのホストのアップグレードが完了するまで、それぞれのホストに対して繰り返し実行されます。

アップグレードが完了すると結果が表示され、全ての新しい機能が利用できるようになります：

クラスタの拡張（ノードの追加）

Nutanixクラスタを動的に拡張できることは重要な機能です。Nutanixクラスタを拡張する際には、ノードをラックに格納、スタック後、ケーブルを接続して電源を供給します。ノードに電源が投入された後は、現在のクラスタからmDNSを使用してそれらを検知できるようになります。

図は、既存7ノードのクラスタにおいて新規の1ノードが検知された状態を示しています。

複数のノードについても検知が可能であり、クラスタに対して同時に追加することもできます。

ノードが検知された後、「ハードウェア (Hardware)」ページの右上にある「クラスタの拡張 (Expand Cluster)」をクリックすることで、拡張が開始されます：

クラスタの拡張処理は、歯車アイコンをクリックすることで、どのページからでも実行できます：

これをクリックすると、クラスタ拡張メニューが起動され、追加する（複数の）ノードを選択し、コンポーネントに対するIPアドレスを指定することができます：

ホストを選択すると、追加するノードで使用するハイパーバイザーイメージをアップロードするよう促されます。ハイパーバイザーがAHVの場合、またはイメージが既にFoundation インストーラーストア上に存在する場合、アップロードは必要ありません。

アップロードが完了し、「クラスタの拡張 (Expand Cluster)」をクリックするとイメージングと拡張処理が開始されます：

ジョブがサブミットされ、対応するタスクが表示されます：

タスクを開くと、詳細な進行状況を確認できます：

イメージングとノード追加処理が完了すると、更新されたクラスタサイズ通りソースを確認できます：

I/Oメトリクス

パフォーマンスに関するトラブルシューティングを実施する上では、まずボトルネックの特定が重要となります。この対応を支援するためにNutanixでは、新たな「I/Oメトリクス」セクションをVMページに追加しました。

レイテンシーは、様々な変数（キューの深さ、I/Oサイズ、システムの状態、ネットワーク速度など）の積として表現されます。このページでは、I/Oサイズ、レイテンシー、ソースおよびパターンに関するインサイトを提供します。

この新しいセクションを利用するためには、「VM」ページに入り、一覧から必要なVMを選択します。これで、ハイレベルな使用状況のメトリクスが表示されます：

一覧の下にあるセクションに、I/Oメトリクス (I/O Metrics) タブが表示されます：

「I/Oメトリクス」タブを選択すると、詳細ビューが表示されます。ここでは、同ページの詳細と使用方法について説明します。

最初のビューは「平均I/Oレイテンシー（Avg I/O Latency）」で、過去3時間の平均R/Wレイテンシーを表しています。デフォルトでは、対応する詳細メトリクスと共に、その時点での最新の値が表示されます。

また、グラフにポインタを合わせると、過去のレイテンシー値が表示され、グラフ上の時間をクリックすると、以下のようにメトリクスの詳細が表示されます。

これはスパイク、つまり突然数値が跳ね上がっている状態の確認に有効となります。このような状況が見られた場合には、そのスパイク表示をクリックして以下のような詳細情報を評価し、さらに調査を進めることができます。

レイテンシーに全て問題がなければ、それ以上の調査は必要ありません。

次のセクションは、READおよびWRITE I/Oサイズのヒストグラムを表示したものです：

ここでは、READ I/Oが、4Kから32Kのサイズ範囲にあることが分かります：

ここでは、WRITE I/Oについては、ほぼ16Kから64Kに収まっているものの、一部は512Kまでのサイズになっていることが分かります：

次のセクションは、READおよび WRITE I/OのI/Oレイテンシーヒストグラムを示したものです：

READレイテンシーヒストグラムを見ると、ほとんどのREAD I/Oがミリ秒未満 (<1ms) に収まっていますが、一部は2～5msに達していることが分かります。

「Readのソース (Read Source)」を見ると、ほとんどのI/OがSSD層で発生していることが分かります：

データが読み込まれると、ユニファイド キャッシュ（Unified Cache）内にリアルタイムで配置されます（詳しくは、「I/Oパスとキャッシュ」のセクションを参照）。 ここでは、データがキャッシュに配置され、DRAMから提供されている様子が理解できます：

基本的に、全てのREAD I/Oがミリ秒 (1ms) 未満のレイテンシーで行われていることが分かります：

ここでは、ほとんどのWRITE I/Oが、1～2ms未満のレイテンシーで行われていることが分かります：

以下の最後のセクションでは、I/Oのパターンとランダムとシーケンシャルの比較内容を示しています：

通常、I/Oのパターンはアプリケーションやワークロードによって、様々に異なるものとなっています（例えば、VDIはほとんどがランダムでHadoopは基本的にシーケンシャルなど）。さらに、2つをミックスしたワークロードも存在します。例えばデータベースは、インサートや一部のクエリではランダムですが、ETL処理中はシーケンシャルとなります。

キャパシティプラニング

キャパシティプラニングの詳細情報を取得する際には、Prism Centralにある「クラスタランウェイ (Cluster Runway)」セクションで、特定のクラスタをクリックしてください。

この画面は、クラスタランウェイに関する詳細情報や、最も切迫したリソース（制約的なリソース）に関する情報を表示しています。 また、リソースを大きく消費している対象に関する詳細情報や、キャパシティをクリーンアップできる可能性やクラスタ拡張のための適切なノードタイプに関する情報を得ることができます。

ACLI

AOS CLI (ACLI) は、Nutanix製品のAOS部分を管理するためのCLIです。本機能は、AOS 4.1.2以降のリリースで利用できます。

注意： 全ての操作は、HTML5 GUIおよびREST APIから実施可能です。私は、これらのコマンドをスクリプトやタスクの自動化のためにのみ使用しています。

ACLIシェルの起動

説明: ACLIシェルの起動（どのCVMでも可）

acli

または

説明： LinuxシェルからACLIコマンドを実行

acli <Command>

ACLIの結果をjsonフォーマットで出力

説明： クラスタ内のAOSノード一覧を出力

acli -o json

ホスト一覧

説明： クラスタ内のAOSノード一覧を出力

host.list

ネットワークの作成

説明： VLANベースのネットワークを作成

net.create <TYPE>.<ID>[.<VSWITCH>] ip_config=<A.B.C.D>/<NN>

例：

net.create vlan.133 ip_config=10.1.1.1/24

ネットワーク一覧

説明： ネットワーク一覧出力

net.list

DHCPスコープの作成

説明： DHCPスコープの作成

net.add_dhcp_pool <NET NAME> start=<START IP A.B.C.D> end=<END IP W.X.Y.Z>

注意： .254は予約されており、AOS DHCPサーバーのアドレスが、ネットワーク作成中に設定されなかった場合に、AOS DHCPによって使用されます。

例：

net.add_dhcp_pool vlan.100 start=10.1.1.100 end=10.1.1.200

既存のネットワーク詳細を取得

説明： ネットワークのVMとVM名、UUID、MACアドレスおよびIPを含む詳細を取得

net.list_vms <NET NAME>

例：

net.list_vms vlan.133

ネットワークのためのDHCP DNSサーバーを設定

説明： DHCP DNSの設定

net.update_dhcp_dns <NET NAME> servers=<COMMA SEPARATED DNS IPs> domains=<COMMA SEPARATED DOMAINS>

例：

net.set_dhcp_dns vlan.100 servers=10.1.1.1,10.1.1.2 domains=splab.com

仮想マシンの作成

説明： VMの作成

vm.create <COMMA SEPARATED VM NAMES> memory=<NUM MEM MB> num_vcpus=<NUM VCPU> num_cores_per_vcpu=<NUM CORES> ha_priority=<PRIORITY INT>

例：

vm.create testVM memory=2G num_vcpus=2

複数の仮想マシンを作成

説明： 複数VMの作成

vm.create  <CLONE PREFIX>[<STARTING INT>..<END INT>] memory=<NUM MEM MB> num_vcpus=<NUM VCPU> num_cores_per_vcpu=<NUM CORES> ha_priority=<PRIORITY INT>

例：

vm.create testVM[000..999] memory=2G num_vcpus=2

既存のVMからクローンを作成

説明： 既存のVMからクローンを作成

vm.clone <CLONE NAME(S)> clone_from_vm=<SOURCE VM NAME>

例：

vm.clone testClone clone_from_vm=MYBASEVM

既存のVMから複数のクローンを作成

説明： 既存のVMから複数のクローンを作成

vm.clone <CLONE PREFIX>[<STARTING INT>..<END INT>] clone_from_vm=<SOURCE VM NAME>

例：

vm.clone testClone[001..999] clone_from_vm=MYBASEVM

ディスクを作成してVMに追加

説明: OS のためのディスクを作成

vm.disk_create <VM NAME> create_size=<Size and qualifier, e.g. 500G> container=<CONTAINER NAME>

例：

vm.disk_create testVM create_size=500G container=default

VMにNICを追加

説明： NICを作成して追加

vm.nic_create <VM NAME> network=<NETWORK NAME> model=<MODEL>

例：

vm.nic_create testVM network=vlan.100

ディスクにVMのブートデバイスを設定

説明： VMのブートデバイスを設定

特定のディスクIDからブートするように設定

vm.update_boot_device <VM NAME> disk_addr=<DISK BUS>

例：

vm.update_boot_device testVM disk_addr=scsi.0

CD-ROMにVMのブートデバイスを設定

CD-ROMからブートするよう設定

vm.update_boot_device <VM NAME> disk_addr=<CD-ROM BUS>

例：

vm.update_boot_device testVM disk_addr=ide.0

CD-ROMにISOをマウント

説明： VM CD-ROMにISOをマウント

手順：

1. ISOをコンテナにアップロード
2. クライアントIPのホワイトリストを有効化
3. ISOをアップロードして共有

ISOでCD-ROMを作成

vm.disk_create <VM NAME> clone_nfs_file=<PATH TO ISO> cdrom=true

例：

vm.disk_create testVM clone_nfs_file=/default/ISOs/myfile.iso cdrom=true

CD-ROMを作成済みの場合はマウントのみを実行

vm.disk_update <VM NAME> <CD-ROM BUS> clone_nfs_file<PATH TO ISO>

例：

vm.disk_update atestVM1 ide.0 clone_nfs_file=/default/ISOs/myfile.iso

CD-ROMからISOをデタッチ

説明： CD-ROMからISOを削除

vm.disk_update <VM NAME> <CD-ROM BUS> empty=true

VMの起動

説明： VMを起動する

vm.on <VM NAME(S)>

例：

vm.on testVM

全てのVMを起動

例：

vm.on *

プリフィックスの一致するVMを起動

例：

vm.on testVM*

特定範囲のVMを起動

例：

vm.on testVM[0-9][0-9]

NCLI

注意： 全ての操作は、HTML5 GUIおよびREST APIから実施可能です。私は、これらのコマンドをスクリプトやタスクの自動化のためにのみ使用しています。

NFSホワイトリストにサブネットを追加

説明： NFSホワイトリストに特定のサブネットを追加

ncli cluster add-to-nfs-whitelist ip-subnet-masks=10.2.0.0/255.255.0.0

Nutanixのバージョンを表示

説明： Nutanixソフトウェアの現在のバージョンを表示

ncli cluster version

隠れたNCLIオプションを表示

説明： 隠れたNCLIコマンド/オプションを表示

ncli helpsys listall hidden=true [detailed=false|true]

ストレージ プール一覧

説明： 既存のストレージ プール一覧を表示

ncli sp ls

コンテナ一覧

説明： 既存のコンテナ一覧を表示

ncli ctr ls

コンテナの作成

説明： 新しいコンテナを作成

ncli ctr create name=<NAME> sp-name=<SP NAME>

VM一覧

説明： 既存のVM一覧を表示

ncli vm ls

パブリックキー一覧

説明： 既存のパブリックキー一覧を表示

ncli cluster list-public-keys

パブリックキーの追加

説明： クラスタアクセスのためのパブリックキーを追加

• パブリックキーをCVMにSCP
• パブリックキーをクラスタに追加

ncli cluster add-public-key name=myPK file-path=~/mykey.pub

パブリックキーの削除

説明： クラスタアクセスのためのパブリックキーを削除

ncli cluster remove-public-keys name=myPK

プロテクションドメインの作成

説明： プロテクションドメインの作成

ncli pd create name=<NAME>

リモートサイトの作成

説明： レプリケーションのためのリモートサイトを作成

ncli remote-site create name=<NAME> address-list=<Remote Cluster IP>

コンテナ内の全てのVM向けプロテクションドメインを作成

説明： 指定したコンテナ内の全てのVMを保護

ncli pd protect name=<PD NAME> ctr-id=<Container ID> cg-name=<NAME>

指定したVMに対するプロテクションドメインを作成

説明： 指定したVMを保護

ncli pd protect name=<PD NAME> vm-names=<VM Name(s)> cg-name=<NAME>

DSFファイル（またはvDisk）に対するプロテクションドメインを作成

説明： 指定したDSFファイルを保護

ncli pd protect name=<PD NAME> files=<File Name(s)> cg-name=<NAME>

プロテクションドメインのスナップショットを作成

説明： プロテクションドメインのワンタイムスナップショットを作成

ncli pd add-one-time-snapshot name=<PD NAME> retention-time=<seconds>

リモートサイトに対するスナップショットとレプリケーションスケジュールの作成

説明： n個のリモートサイトに対するスナップショットとレプリケーションの反復スケジュール作成

ncli pd set-schedule name=<PD NAME> interval=<seconds> retention-policy=<POLICY> remote-sites=<REMOTE SITE NAME>

レプリケーションステータスの表示

レプリケーションステータスのモニター

ncli pd list-replication-status

プロテクションドメインをリモートサイトに移行

説明： プロテクションドメインをリモートサイトにフェイルオーバー

ncli pd migrate name=<PD NAME> remote-site=<REMOTE SITE NAME>

プロテクションドメインの有効化

説明： リモートサイトでプロテクションドメインを有効にする

ncli pd activate name=<PD NAME>

DSFシャドウ クローンを有効化

説明： DSFシャドウ クローン機能を有効化

ncli cluster edit-params enable-shadow-clones=true

vDiskの重複排除機能を有効化

説明： 特定のvDiskに対するフィンガープリンティングと重複排除機能の両方、若しくはフィンガープリンティングのみを有効化

ncli vdisk edit name=<VDISK NAME> fingerprint-on-write=<true/false> on-disk-dedup=<true/false>

クラスタ回復機能 (resiliency) のステータスを確認

ノードのステータス

ncli cluster get-domain-fault-tolerance-status type=node

ブロックのステータス

ncli cluster get-domain-fault-tolerance-status type=rackable_unit

PowerShell コマンドレット

以下では、Nutanix PowerShell コマンドレットの使用方法、および前提となるWindows PowerShellについて説明します。

基本

Windows PowerShellは、.NETフレームワークに実装された（その名の通りの）強力なスクリプト言語です。 使い方は非常にシンプルかつ直観的でインタラクティブな操作が可能です。PowerShellには、いくつかの構成要素があります：

コマンドレット

コマンドレットは、特定の処理を行うためのコマンドまたは .NETのクラスです。 ほとんどの場合、Getter/Setterメッソドに従い、また通常 <Verb>-<Noun> という構文を使用します。 例えば、Get-ProcessやSet-Partitionなどが該当します。

パイプライン

パイプラインはPowerShellの重要な機能（同様な機能がLinuxにもあります）であり、正しく使えば様々なことがシンプルになります。 パイプラインを使用することで、一方の出力をもう一方の入力にすることができます。 パイプラインは必要に応じていくらでも連結することができます（パイプラインの出力が次のパイプラインの入力になる等）。 簡単な例として、現在のプロセス一覧を取得し、その特性でマッチングまたはフィルタリングし、最後にソートするという処理を以下に示します：

Get-Service | where {$_.Status -eq "Running"} | Sort-Object Name

パイプラインは、for-each文でも使用できます。例えば次のようになります：

# For each item in my array
$myArray | %{
  # Do something
}

主要なオブジェクトタイプ

以下にPowerShellの主要なオブジェクトタイプを示します。 オブジェクトタイプは、.getType() メッソドで確認できます。 例えば、$someVariable.getType() はオブジェクトタイプを返します。

変数 (Variable)

$myVariable = "foo"

注意： 変数には、一連のコマンドまたはパイプラインのアウトプットも設定できます。

$myVar2 = (Get-Process | where {$_.Status -eq "Running})

この例では、カッコの中のコマンドの結果がまず求められ、そのアウトプットが変数となります。

配列 (Array)

$myArray = @("Value","Value")

注意： 配列、ハッシュテーブルまたはカスタムオブジェクトの配列も使用できます。

ハッシュテーブル

$myHash = @{"Key" = "Value";"Key" = "Value"}

便利なコマンド

特定のコマンドレットのヘルプ内容を取得します（Linuxの manページと同様）。

Get-Help <コマンドレット Name>

例：

Get-Help Get-Process

コマンドまたはオブジェクトのプロパティとメソッド一覧を表示

<Some expression or object> | Get-Member

例：

$someObject | Get-Member

主要なNutanix コマンドレットと使用方法

Nutanix コマンドレットをダウンロードします。Nutanix コマンドレットは、Prism UI (4.0.1以降)の右上のドロップダウンリストから、直接ダウンロードすることが可能です。

Nutanix スナップインのロード

スナップインがダウンロードされているかどうかを確認し、実施されていなければダウンロードを行います。

if ( (Get-PSSnapin -Name NutanixCmdletsPSSnapin -ErrorAction SilentlyContinue) -eq $null )
{
    Add-PsSnapin NutanixCmdletsPSSnapin
}

Nutanix コマンドレットの一覧表示

Get-Command | Where-Object{$_.PSSnapin.Name -eq "NutanixCmdletsPSSnapin"}

Nutanixクラスタに接続

Connect-NutanixCluster -Server $server -UserName "myuser" -Password (Read-Host "Password: " -AsSecureString) -AcceptInvalidSSLCerts

検索文字列に一致するNutanix VM一覧

変数に対して出力

$searchString = "myVM"
$vms = Get-NTNXVM | where {$_.vmName -match $searchString}

インタラクティブ

Get-NTNXVM | where {$_.vmName -match "myString"}

インタラクティブおよびフォーマット設定

Get-NTNXVM | where {$_.vmName -match "myString"} | ft

Nutanix vDisk一覧

変数に対して出力

$vdisks = Get-NTNXVDisk

インタラクティブ

Get-NTNXVDisk

インタラクティブおよびフォーマット設定

Get-NTNXVDisk | ft

Nutanixコンテナ一覧

変数に対して出力

$containers = Get-NTNXContainer

インタラクティブ

Get-NTNXContainer

インタラクティブおよび書式設定

Get-NTNXContainer | ft

Nutanixプロテクションドメイン一覧

変数に対して出力

$pds = Get-NTNXProtectionDomain

インタラクティブ

Get-NTNXProtectionDomain

インタラクティブおよび書式設定

Get-NTNXProtectionDomain | ft

Nutanix整合性グループ一覧

変数に対して出力

$cgs = Get-NTNXProtectionDomainConsistencyGroup

インタラクティブ

Get-NTNXProtectionDomainConsistencyGroup

インタラクティブおよび書式設定

Get-NTNXProtectionDomainConsistencyGroup | ft

リソースおよびスクリプト：

• Nutanix Github - https://github.com/nutanix/Automation
• vDiskを手動でフィンガープリント - http://bit.ly/1syOqch
• vDiskに関するレポート -http://bit.ly/1r34MIT
• プロテクションドメインに関するレポート - http://bit.ly/1r34MIT
• PDリストアの並べ替え http://bit.ly/1pyolrb

注意： 上記のスクリプトの一部は保守対象外であるため、参考としてご利用ください。

Nutanix Githubには他にも多くのスクリプトが掲載されています： https://github.com/nutanix

Acropolisサービス

Acropolisワーカーは、全てのCVM上で、タスクのスケジューリング、実行、IPAMなどを行う選出されたAcropolisリーダーと共に稼動します。 他のリーダーを持つコンポーネントと同様、Acropolisリーダーに障害が発生した場合は、新しいリーダーが選出されます。

各機能の役割を以下に示します：

• Acropolisリーダー
  • タスクのスケジューリングと実行
  • 統計の収集とパブリッシング
  • ネットワーク コントローラー（ハイパーバイザー用）
  • VNCプロキシ（ハイパーバイザー用）
  • HA（ハイパーバイザー用）
• Acropolisワーカー
  • 統計の収集とパブリッシング
  • VNCプロキシ（ハイパーバイザー用）

以下は、Acropolisリーダーとワーカーの関係を概念的に図示したものです：

Dynamic Scheduler

リソースを効果的に使うためには、リソースの効率的なスケジューリングが重要となります。 AOS Dynamic Schedulerでは、サーバー使用状態（CPU/メモリ）を根拠にした従来のスケジューリング方法を拡張し、より正確な決定ができるようになっています。 ここでは、サーバーのみでなくストレージやその他の状態を見て、VMやボリューム（ABS）のプレースメント判断を行います。 これにより、リソースを効果的に使用し、エンドユーザーのパフォーマンスを最適化することができます。

リソースのスケジューリングは、2つの主要な部分に分かれます：

• 初期プレースメント
  • 起動時に対象をどこでスケジューリングするかを決定
• 実行時の最適化
  • 実行時の測定基準に従ってワークロードを移動

オリジナルのAOS Schedulerが最初にリリースされた際には、初期プレースメントのみを考慮していました。 AOS 5.0でのリリースにより、AOS Dynamic Schedulerは、実行時にもリソースの最適化が図られるよう拡張されました。

以下にスケジューラーのアーキテクチャーの概要を示します：

ダイナミックスケジューラー (Dynamic Scheduler) は、終日稼動し続けてプレースメントの最適化を行います （現在は15分毎 | Gflag: lazan_anomaly_detection_period_secs）。 推定要求値は、平滑化アルゴリズムを使って使用状況の遷移を計算します。 ワークロードの移動判断に推定要求値を使用することで、使用率のスパイク（一瞬の数値の跳ね上がり）に引きずられないようにします。

プレースメントの決定

以下の要因によってプレースメントの決定が行われます：

• サーバーの使用状況
  • Nutanixは、各ノードのサーバーの使用状況をモニターしています。 あるノードのCPU使用率がしきい値（現在は、ホストCPUの85％ | Gflag: lazan_host_cpu_usage_threshold_fraction）を超えると、 ワークロードのバランスを取るため、（複数の）VMをそのホストから他へ移行します。 ここで重要なのは、移行が実施されるのはコンテンション（リソース競合）が発生している場合に限定されるという点です。 仮にノードの使用率が偏っている場合（例えば3ノードが10％で、他の1ノードが50％）でも、コンテンションが発生していなければ、何のメリットも無いため移行は発生しません。
• ストレージのパフォーマンス
  • ハイパーコンバージド プラットフォームであるため、サーバーとストレージリソースは同時に管理されています。スケジューラーは、各ノードのStargateプロセスのCPU使用率を監視しています。Stargateの使用率がしきい値に達すると（現在は、CPUの85％がStargateに使用された場合 | Gflag: lazan_stargate_cpu_usage_threshold_pct）、ホットスポットの発生を回避するため、リソースを（複数の）ホスト間に分散させます。VMとABSボリュームのいずれについても、ホットなStargateの発生を避けるため移行させることが可能です。
• （アンチ）アフィニティルール
  • 特定のリソースをどこでスケジュールするかについては、環境内の他のリソースの状況を基に、アフィニティまたはアンチ アフィニティルールによって決定します。例えば、ライセンスの関係で複数のVMを同じノードで動かしたいケースがあります。この場合には、それぞれのVMが同じホストに配置 (affine) されます。また、可用性確保のために複数のVMを異なるホストで動かしたい場合には、それぞれのVMは別のホストに配置（anti-affine）されます。

スケジューラーは、前述のルールに従ってワークロードが最適なプレースメントとなるよう最善を尽くします。システムには、移行が過度に発生しないよう制限が設けられています。これによって、移行がワークロードに悪影響を及ぼさないようにしています。

移行完了後、その「効果」をシステムが判定して実際のメリットを確認します。この学習モデルによって自己最適化が可能となり、移行判定のための妥当性をより向上させることができます。

セキュリティと暗号化

セキュリティは、Nutanixプラットフォームのコアとなる部分であり、常に注意が払われています。 Nutanix Security Development Lifecycle（SecDL）は、開発プロセスの全てのステップで採用されています。 システムは、工場から出荷された時点でセキュリティが確保された状態にあり、 プラットフォームのNutanixによって制御されている部分は、箱から出したときに安全な状態で、エンドユーザーが後からセキュリティを「強化する」必要はありません。

セキュリティについて考えるとき、私たちは本当に達成しようとしているものは3つの核となること（CIAトライアドと呼ばれる）です：

1. 機密性（Confidentially）
   • 不正アクセスを防止することで、データを安全に保護する
2. 完全性（Integrity）
   • 不正な変更を防止することで、データの一貫性と正確性を確保する
3. 可用性（Availability）
   • 認可されたユーザーが回復力と冗長性のあるデータにアクセスできるようにする

これは単純な説明に簡略化でき、つまりは、ユーザーが悪意のある人を排除しながら仕事をできるようにします。 セキュリティを設計するときは、以下の図で強調されているいくつかの重要な領域を考慮する必要があります：

以降のセクションでは、前掲の図の各セクションを分類します。

システムと構成

従来、人々は「ハードニング（hardening）」と呼ばれる手法でシステム（OS +アプリ）のセキュリティを参照しています。 これは、ベースラインと呼ばれる特定の標準に構成することで、システムを安全にするプロセスです。

DoD（アメリカ国防総省）のIT組織（DISA）には、STIGと呼ばれるサンプルのハードニングガイドがあります（詳細は以降にあるSCMAセクションを参照してください）。 これには、ディレクトリのアクセス許可、ユーザーアカウント管理、パスワードの複雑さ、ファイアウォール、その他の多くの構成設定などが含まれます。

システムがその標準に設定されると「安全」と見なされますが、それはプロセスの始まりにすぎません。 システムのセキュリティは、その寿命を通して維持する必要があるものです。 例えば、標準のハードニングベースラインが確実に満たされるようにするには、構成自動化ツールを使用する必要があります。 これにより、システムは常にベースラインの「望ましい状態」を満たします。

Nutanixは、このセクションの後半で説明する、自身で開発したSCMAと呼ばれるツールを使用してCVMとAHVハイパーバイザーに対してこれを保証しています。

データ

データはあらゆるビジネスの中核であり、間違いなく会社の最も貴重な資産です。 セキュリティについて考えるとき、データのアクセシビリティ、品質、および盗難回避を確保することに焦点をあてる必要があります。

アクセシビリティの概念においては、意思決定を行うためにシステムとデータへのアクセスが常に必要です。 「ランサムウェア」と呼ばれる最近の攻撃手法は、データ暗号化によってデータにアクセスする能力を脅かし、ユーザーがアクセスを取り戻すための身代金を要求します。 これはさまざまな方法で回避できますが、バックアップの重要性を強調することにもなります。

データの品質についても、多くの決定またはアクションが依存するため重要な項目です。 例えば、攻撃者がシステムにアクセスすることで、悪意のある注文をしたり、配送先住所を自身の場所に変更して商品を流用したりします。 これは、データをクリーンな状態に保つために、ロギングとチェックサム確認が非常に重要となりうるところです。

最後に重要なことは、データをどのように安全または強固なものにするかです。 これは一般的に、暗号化によって行われ、データ復号化キーがない場合にはデータが役に立たなくなります。 この場合、誰かが暗号化されたファイルまたはディスクデバイスを盗むと、元となるデータにはアクセスできなくなります。

ネットワーク

ネットワークは、攻撃者がシステムにアクセスするために使用する典型的な通信経路です。 これには、境界セキュリティ（例えば、外部ファイアウォール）や、内部への侵入防止および検出が含まれます。

他の優れた設計と同様に常にセキュリティの層があるべきで、 同じことがネットワークにも当てはまります。 高セキュリティのネットワークを信頼できるネットワークからセグメント化する必要があり、それらを信頼できないネットワーク（例えば、業務やWi-Fiネットワーク）から保護します。 オフィスのローカルネットワークがセキュアであると想定することは決して安全ではありません。

複数層のネットワークを持つことにより、最も信頼されていないネットワークにアクセスする誰かが、安全なネットワークに向けて作業することをより困難にすることができます。 このプロセスにおいて、優れたIDPSシステムは、異常なアクセスや、nmapのようなスキャンツールを検出できます。

認証と認可

認証とは、Active Directoryやその他のIDP（IDプロバイダー）などの信頼できるソースによって、ユーザーの身元を認証することです。 MFA（多要素認証）や2FAのようなツールは、認証しようとしているユーザーがその人自身であることについて、さらに保証を追加します。

身元が確認されたら、次は、ユーザーが行うことが許可されているかどうか、ユーザーが何にアクセスできるかを決定します。これは認可の部分です。 ユーザーfooは、barでのxとy、basでのyとzを行うことを認可されているといったものです。

コンプライアンスとモニタリング

コンプライアンスとは、一般的にPCIやHIPAAのような特定の認定をするときに参照されるものです。 しかし、これはハードニングガイドや基準へのコンプライアンスを満たすことにまで拡張されます。 例えば、STIGはハードニングのベースラインとなるサンプルですが、各企業では追加のポリシーやルールを設けている場合があります。 安全なシステムを確保するためには、システムがこれらのポリシーを満たし、コンプライアンスを遵守した状態にしておかなければなりません。

伝統的に、コンプライアンスは遡及的に確認され、かなり手動によるプロセスです。 これは絶対に間違ったアプローチだと思います。 コンプライアンスは、潜在的な脅威ベクタ確実に制限したり、開いている可能性のあるものを閉じたりする唯一の方法であり、常に確保しなければならないものです。

ここでは、構成管理の自動化（別名は、desired state configuration - DSC）を処理するツールが重要なピースです。 これらにより、構成や設定が常にベースラインまたは目的の状態に設定されます。

監視と侵入のテストは、このコンプライアンスを検証および保証するために重要です。 Nessus、Nmap、metasploitのようなツールを使用して、システムのセキュリティをテストできます。 これらのテスト中、監視および検出システムは、これらを検出してアラート通知をする必要があります。

人間

どのシステムにおいても、人間は伝統的に最も弱いリンクです。 ユーザーがフィッシング攻撃やソーシャルエンジニアリングに陥らないようにするには、トレーニングと教育が重要です。 ユーザーが何を探すべきかを確実に把握して、不明な場合は既知のリソースを案内する必要があります。

教育の1つの方法は、実際にフィッシング攻撃をシミュレートすることであり、彼らに質問を投げかけることで何を探すべきかを学習できます。 また、ロック解除した状態やパスワードを書き留めたままでコンピューターを離れない、といった他のポリシーも強制する必要があります。

認証と認定

Nutanixでは、スタック（オンプレミスおよびオフプレミス）の部分にわたり次のようなセキュリティ認証や認定を有しています：

• コモンクライテリア（CC – Common Criteria*）
  • コモンクライテリアは、政府機関市場（主に国防や機密機関関係）に対してコンピューターを販売する企業が、ただ1つの標準に従えば済むよう策定されたものです。 CCはカナダ、フランス、ドイツ、オランダ、英国および米国によって作成されました。
  • *これは2020年3月現在では再認定中です。
• セキュリティ技術導入ガイド（Security Technical Implementation Guides - STIGs）
  • DOD IAおよびIAイネーブルなデバイスやシステムのための実装基準です。 1998年以来、DISA Field Security Operations (FSO) は、セキュリティ技術導入ガイド（STIG）を提供することで、DoD（米国国防総省）のセキュリティ システムの改善において重要な役割を果たしてきました。 STIGには、情報システムやソフトウェアが不正なコンピューター攻撃に対して脆弱性をさらさないよう、「厳重監視」するための技術指針が含まれています。
• FIPS 140-2
  • FIPS 140-2 基準は、暗号化のための情報テクノロジー セキュリティ適格性認定プログラムであり、取扱注意ではあるが機密ではない（SBU – sensitive but unclassified）政府機関や規制対象業界（金融やヘルスケア業界など）の情報の収集、蓄積、転送、共有および配布に関わる自社製品の認定を求める民間企業ベンダーによって作成されたものです。
• NIST 800-53
• NIST 800-131a
• ISO 27001
• ISO 27017
• ISO 27018

自動セキュリティ設定管理（SCMA － Security Configuration Management Automation）

Nutanixのセキュリティ エンジニアリング チームは、特定時点でしか対応できなかったセキュリティベースラインのチェックを刷新し、導入ライフサイクルのあらゆる局面を通じて、クラスタ内の全てのCVM/AHVホストが継続的なモニタリングを行い、ベースラインに対する自己修復をできるようにしました。 これによって、セキュリティ基準（STIG）に記載された全てのセキュリティベースラインのコンポーネントチェックが可能となり、未準拠となっている部分を検知して、ユーザーに影響を及ぼすことなく、サポートされたセキュリティ設定に戻すことができます。 SCMAはデフォルトで有効化されるので、有効化のための作業は不要です。

Nutanix Command Line Interface (NCLI) を使用することで、様々な設定が可能となり、厳しいセキュリティ要件にも対応することができます。

CVMセキュリティ設定

以下のコマンドは、クラスタ全体にSCMAポリシーを設定するためにNCLIに追加されたコマンドです。該当コマンドとその機能を以下に示します：

CVMセキュリティ設定の表示

ncli cluster get-cvm-security-config

このコマンドは、現状のクラスタ設定内容を出力します。デフォルトの出力内容は以下の通りです：

Enable Aide : false
Enable Core : false
Enable High Strength P... : false
Enable Banner : false
Enable SNMPv3 Only : false
Schedule : DAILY

それぞれの意味は以下のように定義しました:

• Aide
  • 「Advanced Intrusion Detection Environment」の定期実行を有効にします。
• Core
  • 問題がある、もしくは SCMA が修正できない場合に、スタック トレースを作成します。
• High Strength Passwords
  • 高い強度のパスワードを強制します。minlen（最小文字列）=15、difok（前回パスワードとは異なる文字数）=8、remember（過去何世代と異なるものにするか）=24。
  • 注意： 私個人としては、対話的ログインは無効化し、ロックダウン モードで鍵ベースのログインを強制させています。
• Banner
  • カスタム ログイン バナーを有効化します。
• SNMPv3 Only
  • SNMPv2の代わりに、SNMPv3を強制します。

CVMログインバナーの設定

このコマンドを使うことで、Nutanix CVMにログインする際に、DoD（米国防総省）の同意内容 (DoD knowledge of consent) に関するログインバナーを表示するかどうかを設定できます。

ncli cluster edit-cvm-security-params enable-banner=[yes|no]

• デフォルト： no

CVMパスワードの強度設定

このコマンドで、高強度パスワードポリシー (minlen=15,difok=8,remember=24) の適用を有効化または無効化できます。

ncli cluster edit-cvm-security-params enable-high-strength-password=[yes|no]

• デフォルト： no

Advanced Instruction Detection Environment (AIDE) の設定

このコマンドで、週次に実行するAIDEサービスを有効化または無効化できます。

ncli cluster edit-cvm-security-params enable-aide=true=[yes|no]

• デフォルト： no

SNMPv3限定の設定

このコマンドで、SNMPv3限定トラップを有効化または無効化できます。

ncli cluster edit-cvm-security-params enable-snmpv3-only=[true|false]

• デフォルト： false

SCMAスケジュールの設定

このコマンドでSCMAの実行頻度を設定できます。

ncli cluster edit-cvm-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY]

• デフォルト： HOURLY

ハイパーバイザーのセキュリティ設定

以下のコマンドは、SCMAポリシーをクラスタ全体に設定するためにNCLIに追加されたコマンドです。該当コマンドと機能を以下に示します：

ハイパーバイザーのセキュリティ設定を表示

ncli cluster get-hypervisor-security-config

このコマンドは、現状のクラスタの設定内容を出力します。デフォルトの出力内容は以下の通りです：

Enable Aide : false
Enable Core : false
Enable High Strength P... : false
Enable Banner : false
Schedule : DAILY

ハイパーバイザー ログインバナーの設定

このコマンドを使うことで、Nutanixハイパーバイザーにログインする際に、DoD（米国防総省）の同意内容 (DoD knowledge of consent) に関するログインバナーを表示するかどうかを設定できます。

ncli cluster edit-hypervisor-security-params enable-banner=[yes|no]

• デフォルト： no

ハイパーバイザー パスワード強度設定

このコマンドで、高強度パスワードポリシー (minlen=15,difok=8,remember=24) の適用を有効化または無効化できます。

ncli cluster edit-hypervisor-security-params enable-high-strength-password=[yes|no]

• デフォルト： no

Advanced Instruction Detection Environment (AIDE) の設定

このコマンドで、週次に実行されるAIDEサービスを有効化または無効化できます。

ncli cluster edit-hypervisor-security-params enable-aide=true=[yes|no]

• デフォルト： no

SCMAスケジュールの設定

このコマンドで、SCMAの実行頻度を設定できます。

ncli cluster edit-hypervisor-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY]

• デフォルト： HOURLY

クラスタ ロックダウン

クラスタ ロックダウン (Cluster lockdown) は、パスワードベースのCVMアクセスを無効化、またはキーベースのアクセスのみを有効化する機能です。

クラスタ ロックダウンの設定内容については、歯車アイコンのメニューにあるPrismから確認することができます：

現在の設定内容が表示され、アクセスに必要なSSHキーを追加、削除することができます：

キーを追加するためには「New Public Key（新規パブリックキー）」ボタンをクリックし、キーの詳細内容を入力します：

キーを作成し、これを使ってアクセスできることが確認されれば、「Enable Remote Login with Password（パスワードを使ったリモートログインを有効化する）」のチェックを外し、 パスワードベースのログインを無効化することが可能となります。確認のポップアップが表示されたら、「OK」をクリックしてロックダウンを有効化します。

データ暗号化とキー管理

データの暗号化とは、許可を受けた人のみがデータを理解でき、許可を受けていない人には意味不明なものにするためのデータのエンコード方法です。

例えば、誰かに送りたいメッセージがあり、その受け取り手のみがそれを読めるようにするためには、暗合（キー）を使ってメッセージ（プレーンテキスト）を暗号化（暗号文）してからメッセージとして送信します。 仮に、このメッセージが攻撃側に盗まれたり盗聴されたりしても、暗号化されたメッセージを、キーを使って復号化できなければ、暗号文を目にするだけとなります。 正しい相手がメッセージを受け取ると、送り手が提供したキーを使ってメッセージを復号化することができます。

データの暗号化には、いくつかの方法が存在します：

• 共通鍵暗号方式（プライベートキーを使った暗号化）：
  • 暗号化と復号化に同じキーを使用します
  • 例： AES、PGP*、Blowfish、Twofishなど
• 公開鍵暗号方式（パブリックキーを使った暗号化）：
  • 暗号化と複合化に別々のキー（それぞれパブリックキーとプライベートキー）を使用します
  • 例： RSA、PGP* など

注意： PGP（またはGPG）は、パブリリックキーとプライベートキーの両方を使用します。

データの暗号化は、主に次のような状況で使用されます：

• 転送中のデータ（In-transit）： 2つの関係者の間で転送されるデータ（ネットワーク経由のデータ転送など）
• 保管時のデータ（At-rest）： 静的なデータ（デバイスに保存されているデータなど）

Nutanixは、ネイティブなソフトウェアベースの暗号化によって、（SEDの有無にかかわらず）転送中*、および保存時における暗号化の両方を解決します。 SEDのみをベースとした暗号化では、Nutanixは保管時のデータ暗号化を解決します。 *注：転送中の暗号化は、現在、Nutanixクラスタ内のデータRFに適用できます。

以下のセクションでは、Nutanixのデータ暗号化の方法と、キー管理オプションについて説明します。

データの暗号化

Nutanixは、主に3つの方法でデータの暗号化をサポートしています：

• AOS 5.5でリリースされた、ネイティブなソフトウェアベースの暗号化 (FIPS-140-2 Level-1)
• 自己暗号化ドライブ (SED: Self-encrypting Drives) の利用 (FIPS-140-2 Level-2)
• ソフトウェア ＋ ハードウェアによる暗号化

暗号化は、ハイパーバイザーのタイプに応じて、クラスタまたはコンテナ単位で設定することが可能です：

• クラスタ単位の暗号化：
  • AHV、ESXi、Hyper-V
• コンテナ単位の暗号化：
  • ESXi、Hyper-V

注意： SEDを使用する場合、物理デバイスが自ら暗号化を行うため、暗号化の設定はクラスタ単位となります。

クラスタの暗号化の状況は、設定メニュー（歯車アイコン）から「Data-at-Rest Encription（保存データの暗号化）」を選択して確認できます。 ここで現在の状況確認と、暗号化の設定（現在有効化されていない場合）を行うことができます。

こちらは、クラスタ単位で暗号化が有効になっている例です：

この例では、一覧にある特定のコンテナで暗号化が有効になっています：

「edit configuration（設定の編集）」ボタンをクリックすれば、設定を有効化または変更することができます。 暗号化に使用されているKMSの設定、または現在使用中のKMSのタイプを設定するメニューが表示されます。

外部のKMSを使用している場合は、このメニューのCSRリクエスト処理を使って、証明書を承認のためCA（認証局）に渡すことができます。

ネイティブなソフトウェアベースの暗号化

Nutanixのソフトウェア暗号化機能によって、保存データをAES-256でネイティブに暗号化することができます。 また、KMIPまたはTCG準拠の外部KMSサーバー（VormetricやSafeNetなど）や、AOS 5.8で発表されたNutanixネイティブのKMSともやり取りが可能です（以下に詳細）。 また、ソフトウェアによる処理の影響を最小限に抑えるため、システムはIntel AES-NIアクセラレータを使用して暗号化と復号化を行っています。

データが（OpLogやエクステントストアに）書き込まれると、チェックサムの境界でディスクに書き込まれる前に暗号化されます。 これは、データがローカルで暗号化され、そして暗号化されたデータがRFによってリモートのCVMに複製されることも意味します。

暗号化は、ディスクにデータが書き込まれる直前に実施されます。

チェックサムの境界でディスクから読み込まれた暗号化データは、復号化されてゲストに返されます。 複合化/暗号化をチェックサムの境界ごとに実施することで、読み込み増幅 (Read Amplification、余分な追加読み込み処理) が発生することはありません。 また、Intel AES-NIによって処理がオフロードされるため、パフォーマンスやレイテンシーにほとんど影響を与えることがありません。

SED Based Encryption

アーキテクチャーの概要を以下に図示します：

SED暗号化は、ストレージデバイスを安全な状態 (secured) または非安全な状態 (un-secured) のいずれかの状態にある、「データバンド (data bands)」に分解することで機能します。 Nutanixの場合には、ブートとNutanix Homeのパーティションを明示的に暗号化します。 全てのデータデバイスとバンドについては、Level-2に適合するよう、bit数の長いキー（big keys）を使った高度な暗号化が行われます。

クラスタが起動すると、KMSサーバーとのやり取りを行い、ドライブのロックを解除するためのキーを入手します。 安全性を確保するため、クラスタでキーをキャッシュすることはありません。コールドブートやIPMIリセットの場合、ノードはKMSサーバーをコールバックし、ドライブのロックを解除する必要があります。 CVMのソフトブートでは、この状況は発生しません。

キー管理 (KMS)

Nutanixは、他の専用KMSソリューションが提供する場合と同等の、キー管理機能（ローカルキー管理 - LKM）とストレージ機能（AOS 5.8から）をネイティブに提供しています。 これにより、専用のKMSソリューションが不要となり、システム環境をシンプル化できますが、外部のKMSのサポートも継続しています。

前のセクションで説明したように、キー管理はあらゆるデータ暗号化ソリューションにとって極めて重要な部分です。 非常にセキュアなキー管理ソリューションは、スタック全体で複数のキーを使用しています。

ソリューションで使用されるキーには、3つの種類があります：

• データ暗号化キー (DEK)
  • データの暗号化に使用するキーです
• キー暗号化キー (KEK)
  • DEKの暗号化に使用する暗号化キーです
• マスター暗号化キー (MEK)
  • KEKの暗号化に使用する暗号化キーです
  • ローカルキーマネージャーを使用している場合にのみ有効です

以下の図で、それぞれのキーの関係とKMSオプションを説明します。

ローカルキーマネージャー (LKM) サービスは、すべてのNutanixノードに分散され、各CVMでネイティブに稼動します。 このサービスでは、FIPS 140-2暗号モジュールを（承認のもと）使用し、あらゆるキーの管理（キーの更新、キーのバックアップなど）をエンドユーザーに透過的に行うことができます。

データ暗号化の設定を行う場合、「Cluster’s local KMS（クラスタのローカルKMS)」を選択すれば、ネイティブのKMSを使用することができます：

マスターキー (MEK) は、シャミアの秘密分散法を使って分割され、クラスタのノード全体に保存されることで、耐障害性とセキュリティが確保されます。 キーを再構成する際には、Nをクラスタのノード数とした場合、最低でも ROUNDUP(N/2) （ノード数を2で割って小数点以下を切り上げた数）のノードが必要になります。

データ ストラクチャー

Nutanix分散ストレージ ファブリック（DSF）は、以下の要素で構成されています：

ストレージ プール

• 主な役割： 物理デバイスのグループ
• 説明： ストレージ プールは、クラスタのPCIe SSD、SSD、HDDデバイスを含む物理ストレージ デバイスのグループです。 ストレージ プールは、複数のNutanixノードにまたがることができ、クラスタの拡大に合わせ拡張することができます。 ほとんどの構成で単一のストレージ プールが使用されます。

コンテナ

• 主な役割： VM/ファイルの集合
• 説明： コンテナは、ストレージ プールの論理的なセグメントであり、VMまたはファイル (vDisk) のグループを含みます。 コンテナ レベルで複数の構成オプション（例えばRF）の利用が可能ですが、その適用は個別のVM/ファイル レベルになります。 通常コンテナは、データストアと1対1の関係になります（NFS/SMBの場合）。

vDisk

• 主な役割： vDisk
• 説明： vDiskは、DSF上の512KB以上のファイルでvmdksおよびVMハードディスクを含みます。 vDiskは、論理的には「ブロックマップ」で作られたvBlockで構成されます。

以下は、DSFとハイパーバイザーの関係を図示したものです：

vBlock

• 主な役割： 1MBのvDiskアドレス空間のチャンク
• 説明： vBlockとは、vDiskを構成する仮想アドレス空間の1MBのチャンクのことです。 例えば、100MBのvDiskは100 x 1MBのvBlockを持ち、vBlock 0は0～1MB、vBlock 1は1～2MBといったものになります。 これらのvBlockはエクステントにマッピングされて、エクステントグループとして、ディスク上のファイルとして保存されます。

エクステント

• 主な役割： 論理的に連続したデータ
• 説明： エクステントは、論理的に連続した1MBのデータであり、n個（ゲストOSのブロックサイズに依存）の連続ブロックで構成されます。 細かな操作と効率を向上するため、エクステントは、サブエクステント（またはスライス）単位でWRITE/READ/MODIFYが可能です。 エクステントのスライスは、READまたはキャッシュされるデータ量に応じて、キャッシュに移される際にトリムされる場合があります。

エクステント グループ

• 主な役割： 物理的に連続したストアド データ
• 説明： エクステント グループは、1MBまたは4MBの物理的に連続したストアド データです。 データは、CVMがオーナーであるストレージ デバイス上のファイルとしてストアされます。 エクステントは、パフォーマンス向上のため、ノード/ディスク間でストライピングされるよう、動的にエクステント グループに分散されます。 注意：AOS 4.0の場合、データ重複排除機能に応じて、エクステント グループを1MBまたは4MBに設定できます。

以下は、前述の構成要素と各ファイルシスムの対応関係を図示したものです：

これらのユニットの関係は、以下のように図示することもできます：

I/Oパスとキャッシュ

ビデオによる解説はこちらからご覧いただけます： LINK

一般的なハイパーコンバージドなストレージI/Oパスは、以下の層に分類できます：

1. ゲストOS（UVM）から仮想ディスク
   • これはNutanixでも変更されていません。 ハイパーバイザーに応じて、ゲストOSはデバイスドライバーを使用して仮想ディスクデバイスと通信します。 ハイパーバイザーによって、virtio-scsi（AHV）、pv-scsi（ESXi）などになります。 仮想ディスク（例えば、vmdk、vhdなど）についても、ハイパーバイザーによって異なります。
2. ハイパーバイザーからDSF（CVM経由）
   • ハイパーバイザーとNutanix間の通信は、CVMとハイパーバイザーのローカルインターフェイスで、標準的なストレージプロトコル（例えば、iSCSI、NFS、SMBv3）によって行われます。 この時点で、すべての通信はホストに対してローカルです（I/Oがリモートになるシナリオもあります。例えば、ローカルCVMのダウンなど）。
3. Nutanix I/Oパス
   • これはハイパーバイザーとUVMに対してすべて透過的であり、Nutanixプラットフォームにネイティブなものです。

NutanixのI/Oパスは、以下のコンポーネントで構成されています：

通信とI/O

CVM内では、StargateプロセスがすべてのストレージI/Oリクエストと、他のCVMや物理デバイスとの相互作用の処理を担当します。 ストレージデバイスコントローラーは直接CVMにパススルー接続されるため、すべてのストレージI/Oはハイパーバイザーをバイパスします。

以下の図は、これまでのI/Oパスの概要を示します：

Nutanix BlockStore（AOS 5.18で出荷）はAOSの機能で、すべてがユーザー空間で処理される拡張可能なファイルシステムとブロック管理レイヤーを作成します。 これにより、デバイスからファイルシステムが排除され、ファイルシステムカーネルドライバーの呼び出しが削除されます。 新しいストレージメディア（例えば、NVMe）の導入により、 デバイスにはユーザー空間のライブラリが付属し、デバイスI/Oを直接処理（例えばSPDKで）することで、システムコール（コンテキストスイッチ）を行う必要がなくなりました。 BlockStoreとSPDKの組み合わせにより、すべてのStargateによるデバイスの相互作用がユーザー空間に移動し、コンテキストスイッチやカーネルドライバーの呼び出しが排除されました。

以下の図は、BlockStoreとSPDKを使用してアップデートされたI/Oパスの概要を示します：

データ複製を実行するために、CVMはネットワークを介して通信します。 デフォルトのスタックでは、これはカーネルレベルのドライバーが呼び出されます。

しかし、RDMAを使用するとNICはハイパーバイザーのすべてをバイパスしてCVMにパススルー接続されます。 また、CVM内では、RDMAを使用するすべてのネットワークトラフィックは制御パスにカーネルレベルのドライバーのみを使用するため、実際のすべてのデータI/Oは、コンテキストスイッチなしでユーザー空間にて行われます。

以下の図は、RDMAを使用したI/Oパスの概要を示します：

要約すると、拡張機能は以下のように最適化されます：

1. PCIパススルーのデバイスI/Oはハイパーバイザーをバイパスします
2. SPDKとBlockstoreは、カーネルストレージドライバーの相互作用を排除して、それらをユーザー空間に移動します
3. RDMAはハイパーバイザーをバイパスして、すべてのデータ転送はCVMのユーザー空間で行われます

StargateのI/Oロジック

CVM内のStargateプロセスは、ユーザーVM（UVM）からの全てのI/O処理と永続化（RFなどによる）をハンドリングする責任を持ちます。 書き込みリクエストがStargateに届くと、そこには書き込み特性化の機能があり、突発的なランダム書き込みであればOpLog、持続的なランダム書き込みまたはシーケンシャルな書き込みであればエクステントストアに永続化します。 読み取りリクエストは、リクエストされた際にデータが存在する場所によって、OpLogまたはエクステントストアから読み取られます。

NutanixのI/Oパスは、以下の大まかなコンポーネントで構成されます：

*AOS 5.10以降は、Autonomous Extent Store（AES）を使用して、必要条件が満たされたときにサステイン状態のランダムなワークロードを処理できます。

1. オールフラッシュノード構成（All NVMe SSD、All SATA/SAS SSD、NVMe + SATA/SAS SSD）の場合、エクステントストアがSSDデバイスのみで構成され、フラッシュ層のみの存在となるため、ILM層は形成されません。
2. Optaneが使用されている場合（例えば、Intel Optane + NVMe/SATA SSD）、最高パフォーマンスのメディアはTier 0になり、低パフォーマンスのメディアはTier 1になります。
3. ハイブリッドの、オールフラッシュではないシナリオでは、フラッシュはTier 0で、HDDはTier 1になります。
4. OpLogは、ハイブリッドクラスタでは常にSSD上にあり、Optane+NVMeのクラスタではOptaneとNVMe SSDの両方に存在します。
5. データは、アクセスパターンに基づくIntelligent Lifecycle Management（ILM）によって層の間を移動されます。

OpLog

• 主な役割： 永続的なWRITEバッファ
• 説明：OpLogは、ファイルシステムジャーナルのような機能を持ち、大量のランダムWRITEを処理し、融合して（coalesce）、順次データをエクステントストアに送ります。 WRITE処理の場合、可用性を高める目的で、データの書き込みが完了する前にOpLogは異なるn個のCVMのOpLogに同期的にレプリケートされます。 全てのCVM OpLogが、レプリケーションを受ける対象となり、ロードに応じて動的に選択されます。 OpLogは、CVMのSSD層にストアされ、WRITE I/O、特にRANDOM I/Oワークロードに対して非常に優れたパフォーマンスを発揮します。 全てのSSDデバイスが、OpLogストレージの一部の処理を受け持ちます。 シーケンシャルなワークロードの場合、OpLogはバイパスされ、WRITEはエクステントストアに直接渡されます。 既に該当データがOpLogに存在し、エクステントストアに渡されていない場合、全てのREADリクエストは、エクステントストアにデータが渡るまでの間、OpLogから直接データを取得します。 その後、エクステントストア/コンテンツキャッシュからデータが提供されるようになります。 フィンガープリンティング（または重複排除）が有効化されているコンテナの場合、全てのWRITE I/Oは、ハッシュスキームを使用して採取されるため、コンテンツキャッシュ内のフィンガープリントを元に重複排除を行うことができます。

エクステントストア

• 主な役割： 永続的なデータストレージ
• 説明： エクステントストアは、DSFの永続的な大容量ストレージとして、すべてのデバイス層（Optane SSD、SATA SSD、HDD）に存在し、デバイス/層の追加を容易にできるよう拡張可能です。 エクステントストアに入っているデータは、次のいずれかです。
  • A) OpLogから排出されたもの
  • B) シーケンシャル/継続的な処理によりOpLogを経由せずに直接投入されたもの
  Nutanix ILMは、I/Oパターンに応じて動的に配置する層を決定し、データへのアクセス回数と個々の層に与えられた重み付けによって、データを層の間で移動させます。

自律型エクステントストア（AES：Autonomous Extent Store）

• 主な役割： 永続的なデータストレージ
• 説明： 自律型エクステントストア（AES）は、AOS 5.10で導入された、エクステントストアへのデータ書き込みおよび格納のための新方式です。 主にローカルおよびグローバルのメタデータ（詳細は以降の「拡張可能メタデータ」セクションを参照）を組み合わせて、メタデータのローカリティにより、より効率的なパフォーマンス維持を可能にします。 継続的なランダム書き込みのワークロードの場合、これらはOpLogをバイパスし、AESを使用してエクステントストアに直接書き込まれます。 バースト性のランダムなワークロードの場合は従来からのOpLogのI/Oパスを使用し、可能な場合はAESを使用してエクステントストアに排出します。 AOS 5.20 (LTS)時点では、オールフラッシュクラスタ上に新規作成されるコンテナでは、AESがデフォルトで有効になります。 そして、AOS 6.1（STS）以降で要件が満たされている場合には、ハイブリッド（SSD + HDD）クラスタで作成された新規コンテナではAESが有効になります。

ユニファイド キャッシュ（Unified Cache）

• 主な役割： 動的なREADキャッシュ
• 説明：ユニファイド キャッシュはデータ、メタデータ、そして重複排除で利用されるREADキャッシュで、CVMのメモリに存在します。 キャッシュに存在しない（または、特定のフィンガープリントが存在しない）データに対するREADリクエストが発生すると、データはエクステントストアから読み取られ、メモリに常駐するユニファイド キャッシュのシングルタッチプール （single-touch pool）にも配置されます。そこでは、キャッシュから削除されるまでの間にLRU（least recently used）アルゴリズムを使用します。 続くREADリクエストは、マルチタッチプール（multi-touch Pool）に「移動」します（実際はデータが移動するのではなく、ただメタデータをキャッシュする）。 全てのマルチタッチプールに対するREADリクエストは、データをマルチタッチプールの最上部に移動させることになり、そこでは、新しいLRUカウンターが指定されます。 キャッシュサイズは、次の式で計算できます：

  ((CVM Memory - 12 GB) * 0.45)

  例えば、32GBのCVMのキャッシュサイズは次のようになります：

  ((32 - 12) * 0.45) == 9GB

以下は、ユニファイド キャッシュ の概要を図示したものです：

単一vDiskのシャーディング

AOSは、大規模なアプリケーションのパフォーマンスを提供できるように設計および構築されています。 Stargateの内部では、I/Oは、vDiskコントローラーと呼ばれるものによって、作成されたvDiskごとに処理されています。 全てのvDiskは、Stargate内部でvDiskのI/Oを受け持つ、それ自身のvDiskコントローラーを取得します。 期待されていたのは、ワークロードやアプリケーションが複数のvDiskを持ち、それぞれがシステムとして高いパフォーマンスを駆動できる自身のvDiskコントローラースレッドを持つことでした。

このアーキテクチャーは、単一の大きなvDiskを持つ仮想マシンによる、従来のアプリケーションやワークロードの場合を除いて、よく機能していました。 これらの仮想マシンでは、AOSの機能を最大限に活用できていませんでした。 AOS 6.1以降では、vDiskコントローラーが機能拡張され、それぞれが自身のスレッドを持つコントローラーのシャードを作成することで、単一のvDiskへの要求が、現在では複数のvDiskコントローラーに分散されるようになりました。 複数のコントローラーへのI/O分散は、プライマリコントローラーによって行われ、外部とのやりとりでは単一のvDiskのように見えます。 その結果、単一のvDiskを効果的にシャーディングしてマルチスレッドにします。 この機能拡張と前述にあるBlockStoreやAESのような他のテクノロジーによって、AOSは、単一のvDiskを使用する従来型のアプリケーションに対しても、一貫した高いパフォーマンスを大規模に提供できます。

拡張可能メタデータ

YouTubeビデオによる解説はこちらからご覧いただけます：Tech TopX by Nutanix University: Scalable Metadata

メタデータは、インテリジェントなシステムの中心となるものですが、ファイルシステムやストレージアレイにとって非常に重要な存在となります。 「メタデータ」という用語についてわからないのであれば、本質的にメタデータは「データに関するデータ」です。 DSFという観点から、メタデータにはいくつかの重要な要素があります：

• 100％いかなる場合も一致すること（完全一致性）
• ACID準拠であること
• どんな規模にも拡張可能であること
• どんな規模でもボトルネックが発生しないこと（リニアに拡張できること）

AOS 5.10 以降のメタデータは、グローバルメタデータとローカルメタデータの2つの領域に分かれています（以前はすべてのメタデータがグローバルでした）。 これの動機は、「メタデータのローカリティ」を最適化し、メタデータ検索のためのシステムネットワークトラフィックを制限することです。

この変更の根拠は、すべてのデータがグローバルである必要はないということです。 例えば、すべてのCVMが、どの物理ディスク上に特定のエクステントが配置されているかを把握している必要はありません。 ただ、どのノードがそのデータを保持しているかのみ把握し、そしてそのノードが、データをどのディスクに保持しているのかを把握している必要があります。

これにより、システムに保存されるメタデータの量を制限（ローカルのみのデータのメタデータRFを排除）し、「メタデータのローカリティ」を最適化できます。

以下に、4ノードクラスタにおけるメタデータの追加/更新の例を図示します：

ローカルメタデータ

• 説明：
  • ローカルノードでのみ必要な情報を含む、CVMごとのローカルメタデータストア。 これは、AOS 5.10で導入された自律型エクステントストア（AES）によって利用されます。
• ストレージのメカニズム：
  • AES DB（Rocksdbベース）
• 格納されるデータの種類：
  • 物理エクステントやエクステントグループの配置（例えば、egroupとディスクのマッピング）など

グローバルメタデータ

• 説明：
  • すべてのCVMでグローバルに使用でき、クラスタ内のCVM全体にシャーディングされたメタデータ。 AOS 5.10より前のすべてのメタデータ。
• ストレージのメカニズム：
  • Medusaストア（Cassandraベース）
• 格納されるデータの種類：
  • vDiskブロックマップ、エクステントとノードのマッピング、時系列の統計情報、構成情報など

以下のセクションでは、グローバルメタデータによる管理方法について説明します：

前述のアーキテクチャーのセクションでも説明した通り、DSFはリング状のキーバリューストアを使用して他のプラットフォームデータ（例えばステータスデータなど）と同様に、不可欠なグローバルメタデータをストアしています。 グローバルメタデータの可用性と冗長性を確保するため、レプリケーション ファクタ(RF)が奇数になるように（例えば、3や5に）設定します。 メタデータに書き込みや更新が発生した場合、ロー（Row）データが該当するキーを持つリング上の特定ノードに書き込まれ、n個（nはクラスタサイズに依存）のノードにレプリケートされます。 データをコミットする前に、Paxosアルゴリズムを使って、過半数のノードでのデータ一致を確認します。 このようにして、プラットフォームにストアするデータやグローバルメタデータの完全一致性を確保します。

以下の図は、4ノードクラスタでのグローバルメタデータの挿入/更新処理について示します：

DSFのグローバルメタデータにとって、大規模な構成におけるパフォーマンスも重要な要素です。 従来のデュアルコントローラーや「リーダー/ワーカー」方式のモデルとは異なり、プラットフォーム全体のメタデータの管理をNutanixの各ノードが分担して実施します。 クラスタの全てのノードにメタデータを配置して操作できるようにすることで、従来のボトルネックを排除することができます。 クラスタサイズに変更を加える（つまりノードを追加あるいは撤去する）場合、キーの再配布を最小限に抑えるためのキーのパーティショニングに、コンシステントハッシュ法を使用します。 クラスタを拡張（例えば4ノードから8ノードに）する場合、新しいノードは、「ブロック アウェアネス」と信頼性を確保するため、リングを構成しているノードの間に追加されます。

以下に、グローバルメタデータの「リング」とその拡張方法を図示します：

データ保護

ビデオによる解説はこちらからご覧いただけます：LINK

現在、Nutanixプラットフォームは、回復ファクタ (Resiliency Factor) あるいはレプリケーション ファクタ (RF – Replication Factor) と呼ばれる係数に加え、チェックサムを使用してノードまたはディスクの障害や破損時にデータの冗長性と可用性を確保するようになっています。 前述のように、OpLogは、取り込んだWRITEリクエストを低レイテンシーのSSD層で吸収するためのステージング領域として機能します。 データはローカルのOpLogに書き込まれると、ホストに書き込み完了のAckを返す前に、データを異なる1つまたは2つの Nutanix CVMのOpLog（その数はRFに依存）に同期的にレプリケートします。 これにより、データは少なくとも2つまたは3つの独立した場所に存在することになり、フォールトトレランシーが確保されます。 注意：RF3の場合、メタデータがRF5となるため、最低でも5つのノードが必要となります。

OpLogのピアが一定単位毎（1GBのvDiskデータ）に選択され、全てのノードがこれに積極的に関与します。 どのピアが選択されるかという点については、複数の要因があります（例えばレスポンスタイム、業務、キャパシティの使用状況など）。 これによってフラグメンテーションの発生を防ぎ、全てのCVM/OpLogを同時に使用できるようになります。

データRFについては、Prismからコンテナレベルで設定を行います。 「ホットノード」の発生を防ぎ、リニアな拡張性能を維持するため、全てのノードをOpLogのレプリケーションに参加させます。 データが書き込まれている間にチェックサムが計算され、メタデータの一部としてストアされます。 その後データは、非同期的にエクステントストアに移され、RFが維持されていきます。 ノードやディスクに障害が発生した場合、データはクラスタ内の全ノードで再度レプリケートされ、RFを維持します。 データにREADが発生すると常に、データの正当性を確認するためチェックサムが計算されます。 チェックサムとデータが一致しない場合、当該データのレプリカが読み込まれ、不正なデータを置き換えます。

アクティブI/Oが発生しない場合でも一貫性を保つよう、データは継続的に監視されます。 ストレージのスクラブ処理は、エクステントグループを継続的にスキャンし、ディスクの使用率が低い時にチェックサムの検証を実施します。 これによって、ビットやセクターの毀損の発生からデータを保護します。

以下は、上記の解説を論理的に図示したものです：  

可用性ドメイン

ビデオによる解説はこちらからご覧いただけます：LINK

可用性ドメイン（またはノード/ブロック/ラック アウェアネス）は、コンポーネントやデータの配置を決定づける、分散システムにおける重要な要素です。 Nutanixは「ブロック」を、1、2または4つのサーバー「ノード」を含むシャーシ（筐体）として、「ラック」を1つ以上の「ブロック」を含む物理ユニットとして定義しています。 注意：ブロック アウェアネスな状態にするためには、最低3つのブロックが使用されている必要があります。 それ以外の場合はノード アウェアネスとなります。

Nutanixは現在、次のレベルまたはアウェアネスをサポートしています：

• ディスク（常に）
• ノード（常に）
• ブロック（AOS 4.5 以降）
• ラック（AOS 5.9 以降）

ブロック アウェアネスを確実に有効にするためには、ブロックを均一に配置することを推奨します。 一般的なシナリオと適用されるアウェアネスのレベルについては、本セクションの最後で説明します。 3ブロック必要となるのは、クォーラムを確保するためです。例えば3450は、4ノードで構成されるブロックです。 ブロック横断的にロールやデータを分散するのは、ブロックに障害が発生した場合やメンテナンスが必要な場合でも、システムを停止することなく稼動を継続できるようにするためです。 注意：ブロック内で唯一共有されているコンポーネントは、冗長構成のPSUとファンのみになります。

注： ラック アウェアネスでは、管理者がブロックを配置する「ラック」を定義する必要があります。

以下は、これがPrismでどのように構成されるかを示します：

アウェアネスは、いくつかの重要な分野に分類されます：

• データ（VMデータ）
• メタデータ（Cassandra）
• 設定データ（Zookeeper）

データ

DSFによって、データのレプリカがクラスタ内の他の「ブロック/ラック」に書き込まれ、「ブロック/ラック」障害時や計画停止時でも、データは利用可能なままです。 これは、RF2とRF3の両方のシナリオで当てはまり、「ブロック/ラック」障害の場合も同様です。 考え方は、ノードに障害が発生した場合に備え、レプリカを異なるノードにレプリケーションしてデータを保護する「ノード アウェアネス」と同じです。 ブロックおよびラック アウェアネスは、「ブロック/ラック」停止した場合のデータの可用性を保証することにより、これをさらに拡張したものと言えます。

以下に、3ブロックの場合のレプリカの配置方法を図示します：

ブロック/ラックに障害が発生した場合でも、ブロック/ラック アウェアネスは維持され（可能であれば）、データブロックは、クラスタ内の異なるブロック/ラックにレプリケートされます。

アウェアネスの条件とトレランス

一般的なシナリオとトレランスのレベルについて以下に説明します：

AOS 4.5以降、ブロック アウェアネスはベストエフォートで実行され、厳しい実施条件などはありません。 これは、ストレージリソースが偏在（skew）している（ストレージが極端に大きいノードがある等）クラスタが、機能を無効にしないための措置です。 しかし、ストレージの偏在を最小に抑え、均一なブロックを用意する形が依然ベストプラクティスと言えます。

AOS 4.5より前のバージョンの場合、ブロック アウェアネスには以下の条件を満たすことが必要となります：

• 各ブロックのSSDまたは HDD層の数の相違が最大相違数を超える場合： ノード アウェアネス
• 各ブロックのSSDおよびHDD層の数の相違が最大相違数未満の場合： ブロック＋ノード アウェアネス

（層の）最大相違数は、100 / (RF+1) として計算します

• 例えば、RF2の場合は33％、RF3の場合は25％となります

メタデータ

前述の「拡張可能メタデータ」のセクションで説明したように、Nutanixでは、メタデータや他の主要な情報をストアするために、Cassandraプラットフォームに大幅に手をいれています。 Cassandraは、リング状の構造を持ち、データの整合性と可用性を保つよう、リング内にn個のピア（peer）をレプリケーションしています。

以下は、12ノードクラスタのCassandraリングを図示したものです：

Cassandraのピアのレプリケーションは、リングを時計回りに移動しながら実施されます。 ブロック/ラック アウェアネスの場合、同じブロック/ラックにピアが2つ存在しないよう、ブロック/ラック間に分散されます。

以下は、上記のリングをブロック/ラックベースの表現に置き替えた内容を図示しています：

ブロック/ラック アウェアの特性により、ブロック/ラックに障害が発生しても、最低2つのデータコピー（メタデータRF3、さらに大規模なクラスタではRF5も可能）が存在することになります。

以下は、リングを形成する全ノードのレプリケーショントポロジーを図示したものです（やや複雑ですが）：

設定データ

Nutanixは、Zookeeperを使用してクラスタの基本的な設定データをストアしています。 この機能ついてもまた、ブロック/ラックに障害が発生した場合の可用性を維持するため、ブロック/ラック アウェアな方法で分散が行われています。

以下は、ブロック/ラック アウェアな方法で3つのZookeeperノードに分散された場合を例示したものです：

ブロック/ラックに障害発生した場合、つまりZookeeperの1ノードが停止した場合、Zookeeperの役割は、以下に示すようにクラスタ内の他のノードに引き継がれます：

ブロック/ラックがオンラインに復帰した場合、ブロック/ラック アウェアネスを維持するためZookeeperの役割は元に戻されます。

注意： AOS 4.5より前のバージョンでは、この移行は自動的に実行されずマニュアルでの対応となります。

データパスの回復性能

DSFや従来のストレージプラットフォームの最も重要なコンセプトではないにしても、その信頼性と回復性能は最も重要な要素です。

Nutanixでは、ハードウェアの信頼性に重点を置いた従来のアーキテクチャーとは異なるアプローチを採用しています。 Nutanixは、ハードウェアがいずれは障害を起こすことを前提にしています。 従ってシステムは、このような障害に対して的確に、そして稼動を維持したままで対処できるようデザインされています。

注意： これはハードウェアの品質の問題ではなくコンセプトの変化です。 NutanixのハードウェアおよびQAチームは、徹底的な品質チェックと審査プロセスを実施しています。

前のセクションで説明した通り、メタデータおよびデータは、クラスタのFTレベルに基づくRFを使って保護されています。5.0では、FTレベルとしてFT1とFT2がサポートされ、それぞれがメタデータRF3とデータRF2に、またはメタデータRF5とデータRF3に対応しています。

メタデータの共有方法に関する詳細については、前述の「拡張可能メタデータ」セクションをご覧ください。また、データがどのように保護されるかに関する詳細は、前述の「データ保護」セクションをご覧ください。

通常状態におけるクラスタのデータレイアウトは、以下に示すようになります：

図に示す通り、VM/vDiskのデータがノード間に分散したディスクおよび関連するストレージデバイス上に、2つまたは3つコピーされています。

想定される障害レベル

DSFは分散システムとして、コンポーネント、サービス、そしてCVMの障害に対処するよう設計されていますが、障害は幾つかのレベルに分類できます：

• ディスク障害
• CVMの「障害」
• ノード障害

ディスク障害

ディスクが削除された場合、障害が発生した場合、応答がない場合、またはI/Oエラーが発生した場合には、ディスク障害と位置付けられます。 StargateのI/Oエラーやデバイス障害頻度が一定のしきい値を超えると、ディスクがオフライン状態にあると判断します。 この状態になると、HadesがS.M.A.R.Tを実行してデバイスの状態をチェックします。テストにパスすれば、ディスクはオンライン状態にあると認識し、そうでなければオフラインのままの状態とします。 Stargateが複数回（現在は1時間に3回）ディスクのオフラインを認識すると、S.M.A.R.Tのテストにパスしていても、ディスクはオンライン状態から外されます。

VMの影響：

• HAイベント： なし
• I/O障害： なし
• レイテンシー：影響なし

ディスク障害が発生した場合、Curatorスキャン（MapReduceフレームワーク）が直ちに実施されます。 そして、メタデータ（Cassandra）をスキャンし、障害が発生したディスクがホストしていたデータおよび、レプリカをホストしているノード / ディスクを検索します。

「再レプリケーション」が必要なデータを発見した場合、クラスタ内のノードに対してレプリケーションの指示を行います。

この処理の間に、Drive Self Test (DST) が不良ディスクに対して実行され、SMARTのログでエラーを監視します。

以下は、ディスク障害と再保護の例になります：

ここで重要となるのは、Nutanixの場合、データは全てのノード、CVM、ディスクにまたがって分散およびレプリケートされることと、全てのノード、CVM、ディスクが再レプリケーションに関わるということです。

このように、クラスタ全体の処理能力をフル活用することで、データ保護機能の再生に向け必要となる時間を大幅に削減することが可能となり、また、クラスタの規模が大きくなるほど再生が高速になります。

ノード障害

VMの影響:

• HAイベント：あり
• I/O障害：なし
• レイテンシー：影響なし

ノードに障害が発生した場合、VMのHAイベントにより、仮想化クラスタ全体の他のノードでVMの再起動が行われます。VMが再起動されると、I/Oは通常通りの形でローカルCVMによって処理され、VMはI/O処理を継続します。

前述のディスク障害と同様に、Curatorスキャンは、該当するノードでそれまでホストされていたデータに対応するレプリカを検索します。レプリカが見つかると、全てのノードが再保護に参加します。

ノードが長時間（AOS 4.6の場合30分間）停止した状態のままである場合、停止したCVMはメタデータリングから削除されます。ノードが復旧し一定時間経過して安定した後、停止していたCVMはリングに戻されます。

CVMの「障害」

CVMの「障害」は、CVMが一時的に使用できなくなるようなCVMの動作と見なすことができます。該当システムは、こうした障害を透過的に処理するよう設計されています。障害が発生した場合、I/Oはクラスタ内の別のCVMにリダイレクトされます。但し、実際の仕組みはハイパーバイザーによって異なります。

ローリングアップグレードは、実際にこの機能を利用して、CVMを一度に一つアップグレードし、クラスタ全体で繰り返します。

VMの影響：

• HAイベント： なし
• I/O障害：なし
• レイテンシー： ネットワークに高いI/O負荷を与える可能性あり

CVMに「障害」が発生した場合、該当するCVMが提供していたI/Oはクラスタ内の他のCVMに転送されます。 ESXiやHyper-Vは、HA.py（「Happy」に似ている）を使用したCVM Autopathing（CVM自動パス設定）と呼ばれるプロセス経由でこれを処理します。 CVM Autopathingは、内部アドレス（192.168.5.2）に向けられたトラフィックの転送パスを、クラスタの他のCVMの外部IPアドレスに向け変更します。 これにより、データストアは完全な状態を保つことができ、ただI/Oサービスを提供するCVMがリモートになるという違いのみになります。

ローカルのCVMが復旧して安定すると、転送パスは撤回され、ローカルCVMが全ての新しいI/Oを引き継いで処理します。

AHVは、プライマリなパスをローカルCVMとして、他の2つのパスをリモートに設定するというiSCSIマルチパスを使用しています。プライマリパスに障害が発生すると、残りのパスの1つがアクティブになります。

ESXiやHyper-VのAutopathingと同様、ローカルCVMが復旧すると、プライマリパスが役割を引き継ぎます。

レジリエントキャパシティ

使用されている用語の復習です：

• 障害/可用性ドメイン(FD): レプリカが配置されるエンティティの論理的なグループです。 ノード数が3以上のNutanixクラスタでは、ノードがデフォルトのドメインになります。 これは、可用性ドメインのセクションを参照してください。
• レプリケーションファクター（RF）： データ可用性のために、クラスタ上で維持されるデータのコピー数。
• 障害耐性（FT：Fault Tolerance）： 障害が発生したエンティティのデータが完全にリビルドされることを保証する、クラスタで扱える構成されたFDでのエンティティの障害数です。

レジリエントキャパシティは、可用性/障害ドメイン内でのFT障害の発生後に、自己修復能力で要求されたレプリケーションファクター（RF）に回復する最中の、最小状態の可用性/障害ドメインで利用可能なストレージ容量です。 簡単に言うと、「レジリエントキャパシティ = クラスタ全体の容量 - FT障害からリビルドするために必要な容量」です。

AOS 5.18以降は、レジリエントキャパシティがPrism ElementのStorage Summaryウィジェットに灰色の線で表示されます。 しきい値は、クラスタの使用容量がレジリエントキャパシティに到達したときに、エンドユーザーに警告するように設定できます。 デフォルトでそれは75%に設定されています。

Prismでは、管理者がノードごとでの復元力を理解しやすくするように、ノードごとに詳細なストレージ使用率を表示することもできます。 これは、ストレージ分散が偏っているクラスタで役立ちます。

クラスタの使用量がクラスタのレジリエントキャパシティを超えると、そのクラスタは障害に耐えられず、障害から回復できなくなる可能性があります。 レジリエントキャパシティは構成された障害ドメインによるものであるため、クラスタは下位の障害ドメインでも回復して障害に耐えられる可能性があります。 例えば、ノード障害ドメインを持つクラスタは、ディスク障害からの自己修復と回復ができる場合がありますが、ノード障害からの自己修復と回復はできません。

クラスタが適切に機能し、障害から自己修復で回復する能力を維持するために、どのような状況でもクラスタのレジリエントキャパシティを超えないようにすることを強くお勧めします。

キャパシティの最適化

Nutanixプラットフォームは、広範なストレージ最適化テクノロジーを組み合わせる形で採用し、全てのワークロードが使用可能なキャパシティを効率的に使用できるようにしています。このようなテクノロジーは、ワークロードの特性に合わせてインテリジェントに適応されるため、マニュアルによる設定やチューニングが不要となります。

使用されている最適化テクノロジーは以下の通りです：

• 消失訂正符号（Erasure Coding / EC-X）
• データ圧縮
• データ重複排除

それぞれの機能詳細については、次のセクションで説明します。

以下の表で、どのような最適化テクノロジーがどんなワークロードに適用可能かを説明します：

消失訂正符号 (Erasure Coding)

Nutanixプラットフォームでは、データ保護と可用性のためにレプリケーションファクター (RF) を利用しています。この方法では、1ヶ所を超えるストレージからデータ読み込んだり、障害時にデータの再計算を行なったりする必要がないため、極めて高い可用性を提供できます。 しかし、データの完全なコピーが必要となるため、ストレージリソースを消費することになります。

DSFでは、必要なストレージ容量を削減しつつ可用性とのバランスがとれるよう、消失訂正符号 (EC) を使用したデータのエンコードが可能になっています。

パリティを計算するRAID（レベル4、5、6など）の概念と同様、ECは、異なるノードに存在するデータブロックのストライプをエンコードしてパリティを計算します。 ホストまたはディスクに障害が発生すると、パリティを使用して消失したデータブロックの計算（デコーディング）を行います。 DSFの場合、データブロックはエクステントグループであり、また各データブロックはそれぞれ異なるノードに配置され、異なるvDiskに格納されている必要があります。

コールドで読み取られるデータの場合は、同じvDiskから、データブロックがノードを横断するよう分散してストライプ（同じvDiskのストライプ）を形成するようにします。 これにより、vDiskが削除された場合に完全なストライプを削除できるため、ガベージコレクション（GC）が簡素化されます。 ホットデータの読み取りでは、vDiskのデータブロックをノードに対してローカルに保ち、異なるvDiskのデータからストライプ（vDiskをまたぐストライプ）を形成します。 ローカルvDiskのデータブロックをローカルに配置できるため、別のVM/vDiskがストライプ内で別のデータブロックを構成でき、リモート読み取りが最小化します。 読み取るコールドストライプがホットになると、システムはストライプを再計算し、データブロックをローカル配置しようとします。

ストライプのデータやパリティのブロック数は、希望する障害耐性によって決定されます。 通常設定は、<データブロック>/<パリティブロック数> で計算します。

例えば、「RF2ライクな」可用性（つまりN+1）を求める場合は、3または4つのデータブロックとストライプに1つのパリティブロック（つまり3/1または4/1）とします。 「RF3ライクな」可用性（つまりN+2）を求める場合は、3ないしは4つのデータブロックとストライプに2つのパリティブロック（つまり3/2または4/2）とします。

EC + ブロック アウェアネス（認識）

AOS 5.8以降、ECはデータとパリティブロックをブロック認識する方法で配置できます（AOS 5.8より前はノードレベルで行われていました）。

既存のECコンテナは、AOS 5.8へのアップグレード後、すぐにはブロック認識の配置に変更されません。 クラスタ内で利用可能な十分なブロック（ストライプサイズ (k + n) + 1）がある場合、以前のノード認識ストライプはブロック認識になるよう移動します。 新しいECコンテナは、ブロック認識したECストライプを作成します。

想定されるオーバーヘッドは、<パリティブロック数> / <データブロック数> で計算できます。 例えば、4/1ストライプの場合、25%のオーバーヘッドまたはRF2の2Xに比べ1.25Xとなります。4/2ストライプの場合には、50％のオーバーヘッドまたはRF3の3Xに比べ1.5Xとなります。

以下の表に、エンコードされたストライプのサイズとオーバーヘッドの例を示します：

	FT1（RF2相当）		FT2（RF3相当）
クラスタサイズ（ノード数）	ECストライプサイズ（データ/パリティブロック）	ECオーバーヘッド（対 RF2の2X）	ECストライプサイズ（データ/パリティ）	ECオーバーヘッド（対 RF3の3X）
4	2/1	1.5X	N/A	N/A
5	3/1	1.33X	N/A	N/A
6	4/1	1.25X	2/2	2X
7	4/1	1.25X	3/2	1.6X
8+	4/1	1.25X	4/2	1.5X

プロからのヒント

クラスタサイズは、常にストライプサイズ（データ＋パリティ）より最低でも1ノード大きくなるように設定し、ノードに障害が発生した場合でも、ストライプの再構築が可能なようにしておくことが推奨されます。 こうすることで、（Curatorにより自動的に）ストライプが再構築されている場合でも、READにかかるオーバーヘッドを避けることができます。 例えば、4/1ストライプの場合は、クラスタに6ノードを確保すべきです。 前述の表は、このベストプラクティスを踏襲したものになっています。

エンコーディングは、ポストプロセスで実施され、Curator MapReduceフレームワークを使用してタスクの配布を行います。 ポストプロセスのフレームワークであるため、従来のWRITE I/Oパスが影響を受けることはありません。

RFを使用する通常の環境は以下に図示するような内容となります：

このシナリオの場合、RF2とRF3データが混在し、元のデータはローカルに存在し、レプリカはクラスタ全体の他のノードに分散されています。

Curatorスキャンが実行され、エンコードが可能な適切なエクステントグループを検索します。適切なエクステントグループとは、「write-cold」なもの、つまり一定の間書き込みが行われていないものを指します。この間隔はCurator Gflag、curator_erasure_code_threshold_secondsによってコントロールされます。適切な候補が見つかると、Chronosによってエンコーディングタスクが配布され実行されます。

以下に4/1および3/2ストライプの例を図示します：

データのエンコード（ストライプおよびパリティ計算）が成功すると、レプリカエクステントグループは削除されます。

以下は、ストレージセービングのためにECが実行された後の環境を図示したものです：

プロからのヒント

消失訂正符号はインライン圧縮機能と相性がよく、さらにストレージの節約ができます。私は、自分の環境でインライン圧縮とECを組み合わせて使用しています。

圧縮

ビデオによる解説はこちらからご覧いただけます：LINK

Nutanix Capacity Optimization Engine（COE – キャパシティ最適化エンジン）は、ディスクのデータ効率を上げるために、データ変換を行います。 現在、圧縮機能は、データの最適化を行うための重要な機能の1つとなっています。 DSFは、お客様のニーズやデータタイプに応じた対応ができるよう、インライン圧縮とポストプロセス圧縮の両方を提供しています。 AOS 5.1では、オフライン圧縮がデフォルトで有効化されています。

インライン圧縮では、エクステントストア (SSD + HDD) の書き込み時に、シーケンシャルなデータや大きなサイズのI/O（>64K）を圧縮します。 これには、OpLogからのデータドレイニングやOplogをスキップするシーケンシャルデータなどが含まれます。

OpLogの圧縮

AOS 5.0では、OpLogが4Kを超える全てのインカミングの書き込みについて圧縮を行うことで（Gflag：vdisk_distributed_oplog_enable_compression）、優れた圧縮効果が得られるようになりました。 これによって、さらに効率的にOpLogのキャパシティを活用し、安定したパフォーマンスが得られるようになります。

OpLogからエクステントストアに溢れたデータについては、一度解凍し、アラインメントした後に、32Kのユニットサイズに合わせて再圧縮が行われます（AOS 5.1の場合）。

この機能はデフォルトで有効となっており、ユーザーが設定する必要はありません。

オフライン圧縮の場合、最初は通常の状態（非圧縮状態）で書き込みが行なわれ、Curatorフレームワークを使用してクラスタ全体のデータを圧縮します。 インライン圧縮が有効化された場合、I/Oがランダムな特性を持っていても、データは圧縮されない状態でOpLogに書き込まれて合成され、エクステントストアに書き込まれる前にインメモリで圧縮されます。

Nutanixは、AOS 5.0以降、データ圧縮にLZ4とLZ4HCを使用しています。 AOS 5.0より前は、Google Snappy圧縮ライブラリを使用することで、処理オーバーヘッドが少なく高速な圧縮/解凍速度で、非常に優れた圧縮率を得ていました。

通常のデータに対しては、圧縮率とパフォーマンスのバランスが取れたLZ4を使用しています。 コールドデータに対しては、より圧縮率に優れたLZ4HCを使用しています。

コールドデータは、次のような2つのカテゴリに分類されます：

• 一般のデータ： 3日間R/Wアクセスがない (Gflag: curator_medium_compress_mutable_data_delay_secs)
• 不変データ（スナップショット）： 1日間R/Wアクセスがない (Gflag: curator_medium_compress_immutable_data_delay_secs)

以下に、インライン圧縮とDSF WRITE I/Oパスとの関連を図示します：

プロからのヒント

大規模またはシーケンシャルなWRITE処理のみが圧縮対象で、ランダムWRITEのパフォーマンスに影響を与えないため、ほとんどの場合インライン圧縮（圧縮遅延 ＝ 0）が使用されます。

これによってSSD層の実効容量を増やし、パフォーマンスを効果的に向上させ、より多くのデータをSSD層に格納しておくことができます。 書き込みやインライン圧縮された、より大容量またはシーケンシャルデータに対しては、RFによるレプリケーションの際に圧縮データが送られることで回線を通過するデータ量が低減され、さらなるパフォーマンスの向上につながります。

またインライン圧縮は、消失訂正符号との相性という面でも優れています。

オフライン圧縮の場合、全ての新しいWRITE I/Oが非圧縮状態で行われ、通常のDSF I/Oパスが適用されます。 圧縮遅延時間（設定可能）に達するとデータの圧縮が可能となります。 オフライン圧縮は、Curator MapReduceフレームワークを使用し、全ノードで圧縮タスクを実行します。 圧縮タスクはChronosによって起動されます。

下記に、オフライン圧縮とDSF WRITE I/Oの関係を示します。

READ I/Oの場合、最初にメモリ内で解凍を行ってからI/Oが実施されます。

現在の圧縮率は、PrismのStorage > Dashboardページで確認できます。

Elastic Dedupe Engine

ビデオによる解説はこちらからご覧いただけます：LINK

Elastic Dedupe Engineは、DSFにおけるソフトウェアベースの機能で、キャパシティ層（エクステントストア）とパフォーマンス層（ユニファイド キャッシュ）でデータの重複排除を行います。 データストリームは、16K粒度のSHA-1ハッシュを使用して取り込まれる間にフィンガープリントを残します。 フィンガープリントは、データの取り込み時にのみ収集され、書き込みブロックのメタデータの一部として永続的にストアされます。 注意：当初、フィンガープリントの収集に4Kの粒度が使用されていましたが、テストの結果、16Kの方がメタデータのオーバーヘッドを減らし、最大の重複排除効果が得られることが判明しました。 重複排除後のデータは、4Kの粒度でコンテンツキャッシュに取り込まれます。

データの再読み込みが必要となるバックグラウンドのスキャンを使用する従来の手法とは異なり、Nutanixはデータ取り込み時にインラインでフィンガープリントを取得します。キャパシティ層で重複排除が可能な重複データは、スキャンしたり再読み込みしたりする必要がないため、重複したデータは基本的に削除することが可能です。

メタデータのオーバーヘッドを効率化するため、フィンガープリントの参照カウントをモニターし、重複排除の可能性をトラッキングします。メタデータのオーバーヘッドを最小限にするため、参照数の低いフィンガープリントは廃棄されます。また、フラグメントを最小限にするためには、キャパシティ層の重複排除を最大限に使用することが望まれます。

プロからのヒント

ベースイメージ（vdisk_manipulatorを使用してマニュアルでフィンガープリント可能）に対しては、パフォーマンス層の重複排除を使用し、コンテンツキャッシュの優位性を活かすようにします。

Hyper-Vを使用してODXがデータの完全コピーを取得する場合、またはコンテナをまたがったクローンを実施（単一のコンテナが好ましいため通常は推奨しません）する場合、 P2V / V2Vに対してはキャパシティ層の重複排除を使用します。

ほとんどの場合、圧縮機能の方がより多くの容量削減が可能なため、重複排除の代わり使用されるべきでしょう。

以下に、Elastic Dedupe Engineの拡張と、ローカルVMのI/Oリクエストの処理の関連を図示します：

I/Oサイズが64K以上（初期のI/OまたはOpLogからのドレイニングの際）のデータを取り込む間にフィンガープリントが収集されます。 Intel accelerationが使用された、CPUのオーバーヘッドが極めて少ないSHA-1処理を行われます。 データ取り込み中にフィンガープリントが収集できない（例えばI/Oサイズが小さいなど）場合、フィンガープリントの収集は、バックグラウンドプロセスとして実行されます。 Elastic Dedupe Engineは、キャパシティ層（エクステントストア）とパフォーマンス層（ユニファイド キャッシュ）の両方に対応しています。 重複データが特定されると、同じフィンガープリントの複数のコピーに基づき、バックグラウンドプロセスが、DSF MapReduceフレームワーク (Curator)を使用して重複データを削除します。 読み込みデータは、複数階層を持つプールキャッシュであるDSFユニファイド キャッシュに取り込まれます。これ以降、同じフィンガープリントを持つデータリクエストは、キャッシュから直接データを取り込みます。 ユニファイド キャッシュとプールの階層構造の詳細については、I/Oパス概要セクション内の「ユニファイド キャッシュ」に関するサブセクションをご覧ください。

フィンガープリント済み vDisk のオフセット

AOS 4.6.1 では、vDisk全体で無制限にフィンガープリントと重複排除ができるようになりました。

AOS 4.6.1 以前では、メタデータの効率性を高めるため、この制限が24GBまで拡張されました。 AOS 4.5 以前では、vDiskの最初の12GBのみがフィンガープリント採取の対象でした。 これは、通常OSが最も共通的なデータであったため、維持するメタデータのフットプリントが比較的小さいためです。

以下に、Elastic Dedupe EngineとDSF I/Oパスの関係を図示します：

現在の重複排除率は、Prismの Storage > Dashoboard ページ で確認することができます。

重複排除 ＋ 圧縮

4.5では、重複排除と圧縮を同じコンテナに適用することができます。しかし、データが重複排除可能な場合（セクションの最初に述べた条件）を除き圧縮にこだわるべきでしょう。

ストレージの階層化と優先順位付け

ディスクバランシングのセクションでは、どのようにしてNutanixクラスタの全てのノードにまたがるストレージ キャパシティをプールし、また、どのようにしてILMがホットデータをローカルに維持するかについて解説しました。 同様の概念が、クラスタ全体のSSDやHDD層といったディスクの階層化にも適用されており、DSF ILMは、階層間でデータを移動させる役目を担います。 ローカルノードのSSD層は、そのノードで稼動するVMが生成する全てのI/Oに対して常に最高優先度となる階層であり、また、クラスタの全てのSSDリソースは、クラスタ内の全てのノードに対して提供されることになります。 SSD層は、常に最高のパフォーマンスを提供すると同時に、その管理はハイブリットアレイにとって非常に重要なものとなります。

階層の優先度は次のような分類が可能です：

同じタイプのリソース（例えばSSD、HDDなど）が、クラスタ全体のストレージ層から集められてプールされます。 つまり、ローカルにあるかどうかを問わず、クラスタ内の全てのノードが、その層のキャパシティ構築に利用されるということです。

以下は、このプールされた階層がどのように見えるかを図示したものです：

ローカルノードのSSDが一杯になるとどうなるのか？というのは一般によく聞かれる質問です。 ディスクバランシングのセクションで説明した通り、重要となるのは、ディスク層のデバイス間の使用率の平準化を図ることです。 ローカルノードのSSD使用率が高い場合、ディスクバランシングは、ローカルSSDに存在する最もコールドなデータをクラスタの他のSSDに移動するように機能します。 これにより、ローカルSSDに空きスペースを確保し、ローカルノードがネットワーク越しにではなく、ローカルのSSDに直接書き込めるようにします。 ここで重要な点は、全てのCVMとSSDがリモートI/Oに使用されることで、ボトルネックの発生を防ぎ、また、万が一発生した場合でも、ネットワーク経由でI/Oを実施してそれを修復できる点です。

別のケースとして、階層全体の使用率が、一定のしきい値 [curator_tier_usage_ilm_threshold_percent (デフォルト=75)] を超えた場合、 Curatorジョブの一部としてDSF ILMが起動され、データをSSD層からHDD層に下層移動させます。 これにより、使用率が上記のしきい値内になるか、または最小解放値 [curator_tier_free_up_percent_by_ilm (デフォルト=15)] の2者から、大きい方の値でスペースが解放されます。 下層移動の対象となるデータは、最後にアクセスのあった時間によって決定されます。 SSD層の使用率が95％の場合、SSD層にある20％のデータをHDD層に移動（95％ -> 75％）されます。

しかし、使用率が80％の場合は、階層の最小解放値に基づき、15％のデータのみがHDD層に移動することになります。

DSF ILMは、I/Oのパターンを定常的にモニターし、必要に応じてデータを上層または下層に移動すると共に、その階層に関係なく、ホットなデータをローカルに移動させます。 上層への移動（もしくは水平移動）のロジックは、egroupローカリティで定義されたものと同様です： 10分間に3回のランダムアクセス、または10回のシーケンシャルアクセスが発生した場合。ただし10秒間のサンプリング間隔内で発生した複数回のReadは1回としてカウントされます。

ディスクバランシング

ビデオによる解説はこちらからご覧いただけます：LINK

DSFは非常にダイナミックなプラットフォームとして、様々なワークロードに対応することが可能であると同時に、1つのクラスタをCPUに重点を置いた構成（3050など）や、ストレージに重点を置いた構成（60x0など）など、様々なノードタイプを組み合わせた構成が可能です。 大規模なストレージ容量を持ったノードを組み合わせた場合、データを均一に分散することが重要になります。 DSFには、クラスタ全体でデータを均一に分散するためのディスクバランシングと呼ばれるネイティブな機能が含まれています。 ディスクバランシングは、DSF ILMと連携しながらローカルにあるノードのストレージ キャパシティの使用率を調整します。 もし、使用率が一定のしきい値を超えた場合は、使用率の均一化を図ります。

注： ディスクバランシングのジョブは、プライマリI/O（UVMのI/O）とバックグラウンドI/O（例えばディスクバランシング）に異なる優先度キューを持つCuratorによって処理されます。 これは、ディスクバランシングやその他のバックグラウンド処理が、フロントエンドのレイテンシーやパフォーマンスに影響しないように行われます。 このときジョブのタスクは、タスク実行の抑制や制御をするChronosに渡されます。 また、ディスクバランシングのための移動は同じ層内で行われます。 例えば、HDD層に不均等なデータがある場合、ノード間の同じ層で移動します。

以下は、異なるタイプ（3050 ＋ 6050）で構成された「バランスが悪い」状態にあるクラスを図示しています：

ディスクバランシングは、DSF Curatorフレームワークを使用し、スケジュールプロセスとして、 または、しきい値を超えた場合（例えば、ローカルノードのキャパシティの使用率 > n%）に機能します。 データのバランスが悪い場合、Curatorはどのデータを移動すべきかを判断し、クラスタのノードにタスクを配分します。 ノードタイプが均一（例えば、3050のみ）の場合、データの分散もほとんどが均一な状態になります。 しかし、ノード上に他に比べ大量のデータ書き込みを行うVMが存在した場合には、該当ノードのキャパシティ使用率のみが突出したものになります。 このような場合、ディスクバランシングが機能し、そのノードの最もコールドな状態にあるデータをクラスタ内の他のノードに移動させます。 さらに、ノードタイプが不均一（例えば、3050 ＋ 6020/50/70など）な場合や、ストレージの利用のみに限定して使用されている（VMが動いていない状態）ノードが存在する場合にも、データを移動する必要があると考えられます。

以下に、ノードタイプが混在したクラスタで、ディスクバランシングが機能し、「バランスが取れた」状態を図示しました：

大量のストレージ キャパシティを確保するため、一部のノードを「Storage Only（ストレージとしてのみ利用する）」という状態で稼動させるお客様も存在します。 この場合、CVMのみがノード上で稼動することになります。 ノードの全てのメモリをCVMに割り当て、より大きなREADキャッシュを確保することができます。

以下は、ノードタイプ混在クラスタにStorage Onlyノードが存在する場合、ディスクバランシングがどのようにVMを稼動するノードからデータを移動させるかを図示したものです：

スナップショットとクローン

ビデオによる解説はこちらからご覧いただけます：LINK

DSFはオフロードされたスナップショットとクローンをネイティブにサポートし、VAAI、ODX、ncli、REST、Prismなどから使用することができます。 スナップショットもクローンも、最も効果的かつ効率的なリダイレクト オン ライト（redirect-on-write）アルゴリズムを採用しています。 データストラクチャのセクションで説明した通り、仮想マシンはNutanixプラットフォーム上のvDiskであるファイル（vmdk/vhdx）から構成されています。

vDiskは、論理的に連続したデータのかたまりであり、エクステントグループにストアされているエクステントで構成されています。エクステントグループは、ストレージデバイス上のファイルとしてストアされている物理的に連続したデータです。スナップショットやクローンが取得されると、元になるvDiskは変更不可とマークされ、一方のvDiskはREAD/WRITE可能な形で作成されます。この時点で、両方のvDiskは同じブロックマップ、すなわちvDiskに対応するエクステントをマップしたメタデータを持っています。スナップショットチェーンのトラバーサル（READに必要なレイテンシーの増加）が発生する従来のアプローチとは異なり、各vDiskがそれぞれのブロックマップを持っています。これによって、大きく深いスナップショットチェーンで一般的にみられるオーバーヘッドを排除し、パフォーマンスに影響を与えることなく、連続的にスナップショットを取得することができるようになります。

以下は、スナップショットを取得した際の動きを図示したものです（注意：この図はNTAPの図をもとに作成したものです。NTAPの説明が最も明解なものだったからです）：

既にスナップショットあるいはクローンが取得されたvDiskでスナップショットまたはクローンを取得する場合も、同じ方法が適用されます：

VMやvDiskに対するスナップショットやクローンも、同様の方法で取得します。 VMまたはvDiskがクローンされる場合、その時点のブロックマップをロックして、クローンが作成されます。 更新はメタデータのみに対して行われるため、実際にI/Oが発生することはありません。 さらにクローンのクローンについても同様です。 以前にクローン化されたVMは、「ベースvDisk（BasevDisk）」として機能し、クローニングが行われる場合ブロックマップがロックされ、2つの「クローン」が作成されます。 1つはクローン元のVMで、もう一方は新しいクローンです。 クローンの最大数に制限はありません。

いずれも以前のブロックマップを引き継ぎ、新規の書き込みや更新はそれぞれのブロックマップに対して行われます。

既にご説明した通り、各VM/vDiskはそれぞれブロックマップを持っています。上記の例では、ベースVMの全てのクローンがそれぞれのブロックマップを持つようになり、書き込みや更新はそこで発生します。

上書きが発生した場合、データを新しいエクステント/エクステントグループに移動します。 例えば、既存のデータが「エクステントe1のオフセットo1」にありそれが上書きされるとき、Stargateは新しいエクステントe2を作成し、新しいデータが「エクステントe2のオフセットo2」に書き込まれたことを追跡します。 vBlockマップは、これをバイトのレベルで追跡します。

以下にそのような状態を図示します：

VM/vDiskに引き続き、クローンやスナップショットを取得しようとすると、元のブロックマップがロックされ、R/Wアクセスできる新しい対象が作成されます。

ネットワークとI/O

Nutanixプラットフォームでは、ノード間通信においてバックプレーンを一切使用せず、標準的な10GbEネットワークのみを使用しています。 Nutanixノード上で稼動するVMの全てのストレージI/Oは、ハイパーバイザーによって専用のプライベート ネットワーク上で処理されます。 I/Oリクエストは、ハイパーバイザーによって処理され、ローカルCVM上のプライベートIPに転送されます。 CVMは、外部IPを使いパブリック10GbEネットワーク経由で、他のNutanixノードに対してリモートレプリケーションを行います。 つまり、パブリック10GbEを利用するトラフィックは、DSFリモートレプリケーションとVMネットワークI/Oのみということです。 但し、CVMが停止していたり、データがリモートに存在したりする場合、CVMはリクエストをクラスタ内の他のCVMに転送します。 さらに、ディスクバランシングなどクラスタ横断的なタスクは、10GbEネットワーク上で一時的にI/Oを発生させます。

以下は、VMのI/Oパスとプライベートおよびパブリック10GbEネットワークの関係を図示したものです：

データ ローカリティ

コンバージド（サーバー＋ストレージ）プラットフォームであるNutanixでは、I/Oとデータのローカリティが、クラスタおよびVMのパフォーマンスにおいて重要な要素となります。 前述のI/Oパスの通り、全てのRead/Write I/Oは、一般のVMに隣接した各ハイパーバイザー上に存在するローカルのコントローラーVM（CVM）によって処理されます。 VMのデータは、ローカルでCVMから提供され、CVMコントロール下のローカルディスクにストアされます。 VMが特定のハイパーバイザー ノードから他に移動する場合（あるいはHAイベント発生中）には、新たなローカルCVMによって移行されたVMのデータが処理されます。 古いデータ（リモート ノード/CVMに格納）を読み込む際、I/OはローカルCVMからリモートCVMに転送されます。 全てのWrite I/Oは、直ちにローカルで処理されます。 DSFは、異なるノードで発生したI/Oを検知し、バックグラウンドで該当データをローカルに移動し、全てのRead I/Oがローカルで処理されるようにします。 ネットワークに負荷を与えないようにするため、データの移動はRead処理が発生した場合にのみ実施されます。

データ ローカリティは、主に以下2つの状況で発生します：

• キャッシュ ローカリティ
  • リモートデータはローカルStargateのユニファイド キャッシュに取り込みます。 これは4Kの粒度で行われます。
  • ローカルレプリカがないインスタンスの場合、リクエストはレプリカを持っていてデータを戻せるStargateに転送され、ローカルStargateはこれをローカルに格納してからI/Oを返します。 そのデータに対するその後の全てのリクエストは、キャッシュから返されます。
• エクステントグループ（egroup）ローカリティ
  • vDiskエクステントグループ（egroup）を、ローカルStargateのエクステントストアに保存されように移行しています。
  • レプリカegroupが既にローカルにある場合、移動は必要ありません。
  • このシナリオでは、実際のレプリカegroupは一定のI/Oしきい値に到達すると再ローカライズされます。 ネットワークを効率的に利用するために、egroupを自動的に再ローカライズや移行することはありません。
  • AESが有効なegroupでも、レプリカがローカルではなくパターンが満たされている場合に、同様に水平移行が発生します。

以下は、VMがハイパーバイザー ノード間を移動した場合、データがどのようにVMを「追いかけるか」を図示したものです：

シャドウ クローン

分散ストレージ ファブリックには「シャドウ クローン」と呼ばれる機能があり、「複数の読み手」のある特定のvDiskやVMデータの分散キャッシングを行うことができます。 VDI導入中に、多くの「リンク クローン」がReadリクエストをセントラルマスター、つまり「ベースVM」に対して送信する場合などがこの典型例と言えます。 VMware Viewの場合、この仕組みはレプリカ ディスクと呼ばれ、全てのリンク クローンから読み込まれます。 XenDesktopの場合には、MCSマスターVMと呼ばれています。 これは複数の読み手が存在する場合（例えば展開サーバーやリポジトリ）などあらゆるシナリオで機能します。 データやI/Oのローカリティは、VMが最大パフォーマンスを発揮するために不可欠であり、またDSFの重要な構成要素となります。

DSFは、シャドウ クローンを使って、データ ローカリティと同様にvDiskのアクセス傾向をモニターします。 しかし、2つ以上のリモートCVM（ローカルCVMも同様）からリクエストがあり、かつ全てがRead I/Oリクエストであった場合、vDiskは変更不可とマークされます。 一旦ディスクが変更不可とマークされると、vDiskはCVM毎にローカルにキャッシングされ、Readリクエストに対応できるようになります（ベースvDiskのシャドウクローンとも言います）。 これによって、各ノードのVMがベースVMのvDiskをローカルに読み込めるようになります。VDIの場合、レプリカディスクがノード毎にキャッシュされ、ベースに対する全てのReadリクエストがローカルで処理されるようになります。 注意： データの移動は、ネットワークに負荷を与えずに効率的なキャッシュ利用を可能にするため、Read処理が発生した場合にのみ実施されます。 ベースVMに変更があった場合、シャドウクローンは削除され、プロセスは最初からやり直しとなります。 シャドウ クローンは、デフォルトで有効化されており (4.0.2の場合）、以下のNCLIコマンドを使って有効化/無効化できます： ncli cluster edit-params enable-shadow-clones=<true/false>

以下に、シャドウ クローンの動作と分散キャッシングの方法を図示します：

ストレージ層と監視

Nutanixプラットフォームは、VM/ゲストOSから物理ディスク デバイスに至るまで、スタック全体にわたる複数の層でストレージを監視しています。 様々な階層とそれらの関係を十分理解することが、ソリューションの監視においては非常に重要となり、処理との関連性をより可視化することができます。 以下は、処理を監視している各層とその粒度について図示したものです：

仮想マシン層

• 主要な役割： VM用にハイパーバイザーがレポートするメトリクス
• 説明： 仮想マシンまたはゲスト レベルのメトリクスをハイパーバイザーから直接取得し、VMから見たパフォーマンスおよびアプリケーションから見たI/Oパフォーマンスを提示
• 使用場面： トラブル シューティングやVMレベルの詳細を把握したい場合に使用されます。

ハイパーバイザー層

• 主要な役割： ハイパーバイザーがレポートするメトリクス
• 説明： ハイパーバイザー レベルのメトリクスを直接ハイパーバイザーから取得し、最も正確なハイパーバイザーから見たメトリクスを提示します。 該当データは複数のハイパーバイザーまたはクラスタ全体で見ることができます。 この層は、プラットフォームから見たパフォーマンスを確認するという意味では最も正確なデータを提供するため、多くのケースで活用されるべきです。 シナリオによっては、ハイパーバイザーがVMからの処理を組み合わせる、または分解することで、VMとハイパーバイザーによって異なるメトリクスが提示される場合があります。 これらの数値には、Nutanix CVMが提供するキャッシュ ヒットも含まれています。
• 使用場面： 最も詳細で価値あるメトリクスを提供するため、ほとんどのケースで使用されます。

コントローラー層

• 主要な役割： Nutanixコントローラーがレポートするメトリクス
• 説明： NutanixコントローラーVM（例えばStargate 2009ページ）からコントローラー レベルのメトリクスを直接取得し、NFS/SMB/iSCSIやバックエンド処理（例えばIML、ディスク バランシングなど）からNutanixフロントエンドが見ている内容を提示します。 このデータは、複数のコントローラーVMまたはクラスタ全体を通じて見ることができます。 通常、コントローラー層から見たメトリクスは、ハイパーバイザー層から見たメトリクスと一致しますが、これにバックエンド処理（例えばILMやディスク バランシングなど）が含まれています。 また、これらの数値には、メモリが提供するキャッシュ ヒットも含まれています。 NFS/SMB/iSCSIクライアントが大規模なI/Oを複数の小さなI/O単位に分解していることもあるため、IOPSのようなメトリクスについては一致しない場合があります。 しかし、帯域幅のようなメトリクスについては一致します。
• 使用場面： ハイパーバイザー層と同様に、バックエンド処理の負荷を提示するために使用することができます。

ディスク層

• 主要な役割： ディスク デバイスがレポートするメトリクス
• 説明： 物理ディスク デバイスから (CVM経由で) ディスク レベルのメトリクスを直接取得し、バックエンドから見た状態を提示します。 これには、ディスクI/Oが発生するOpLogやエクステント ストアにヒットするデータが含まれています。 このデータは、複数のディスク、特定のノードのディスクまたはクラスタのディスク全体で見ることができます。 通常、ディスク処理は、受信するWriteおよびメモリ キャッシュから提供されないReadの数と一致します。 メモリ キャッシュによって提供される全てのReadは、ディスク デバイスがヒットされないため、ここではカウントされません。
• 使用場面： キャッシュから提供した処理やディスクをヒットした処理の数を確認する場合に使用されます。

Nutanix Guest Tools (NGT)

Nutanix Guest Tools (NGT) は、ソフトウェア ベースのゲストにインストールするエージェント フレームワークであり、Nutanixプラットフォームを介して高度なVM管理機能を提供します。

本ソリューションは、VMにインストールされたNGTインストーラーおよび、エージェントとNutanixプラットフォーム間の調整に使用されるGuest Tools Frameworkで構成されています。

NGTインストーラーには以下のコンポーネントが含まれています：

• Guest Agent Service
• セルフ サービス リストア（SSR）、またはファイル レベル リストア（FLR）のCLI
• VM Mobility Drivers（AHV用のVirtIOドライバー）
• Windows VM用の、VSSエージェントおよびハードウェア プロバイダー
• Linux VM用の、アプリケーション整合性（App Consistent）スナップショットのサポート（スクリプトによる静止状態の取得）

このフレームワークは少数のハイレベル コンポーネントで構成されています：

• Guest Tools Service
  • AOS、Nutanixサービス、そしてGuest Agent間のゲートウェイです。 現在の（クラスタVIPをホストしている）Prismリーダー上で稼動する選定されたNGTリーダーで、クラスタ内のCVMへ分散されます。
• Guest Agent
  • NGTインストール プロセスの一部として、VMのOSに展開されるエージェントおよび関連サービスです。 ローカル機能（VSS、セルフ サービス リストア - SSR など）を処理し、Guest Tools Serviceとのやり取りを行います。

以下に各コンポーネントの関係概要を示します：

Guest Tools Service

Guest Tools Serviceは、以下2つの主要機能で構成されています：

• NGTリーダー
  • NGTプロキシからのリクエストを処理し、AOSコンポーネントとのやり取りを行います。 クラスタ毎に1つのNGTリーダーが動的に選定され、現状のリーダーに障害が発生すると、新しいものが選定されます。 本サービスは、ポート2073を使用して内部と接続します。
• NGTプロキシ
  • 全てのCVM上で稼動し、NGTリーダーが必要な処理を実行するためにリクエストを転送します。 （VIPをホストしている）Prismリーダーとして稼動するVMが、Guest Agentからの通信を処理するCVMとなります。 ポート2074を使って外部と接続します。

以下に各ロールの概要を示します：

Guest Agent

前述の通り、Guest Agentは主に以下のようなコンポーネントで構成されています：

通信とセキュリティ

Guest Agent Serviceは、SSLを使用してNutanixクラスタIP経由でGuest Tools Serviceと通信します。 Nutanixクラスタ コンポーネントとUVMを異なるネットワーク上に導入している場合（全てそうであることが推奨）、以下が可能であることを確認してください：

• UVMネットワークからクラスタIPへのルーティング通信が可能なこと、
または
• UVMネットワークからポート2074 (推奨) 上のクラスタIPに通信が可能となるように、ファイアウォール規則 (及び関連するNAT) が生成されていること

Guest Tools Serviceは、認証局（CA – Certificate Authority）として機能し、NGTが有効なUVMのための証明書ペアを生成します。 この証明書は、UVMのために構成されたISOに埋め込まれ、NGT導入プロセスの一部として使用されます。 これらの証明書はインストール プロセスの一部としてUVM内部にインストールされます。

NGTエージェントのインストール

NGTエージェントのインストールは、PrismまたはCLI / スクリプト（ncli/REST/PowerShell）で実行できます。

PrismからNGTをインストールする場合は、「VM」ページでNGTをインストールするVMを選択し「Enable NGT（NGTを有効化）」をクリックします。

確認表示が出たら、「Yes」をクリックしてNGTのインストールを進めます：

ソフトウェアや独自の証明書を含むインストーラーがCD-ROM内にあるため、以下のようにVMからCD-ROMが利用可能になっている必要があります：

OSからNGTインストーラーCD-ROMが確認できます：

CDをダブルクリックし、インストール プロセスを開始します。

プロンプトに従い、ライセンスを承諾してインストールを完了させます：

インストール プロセスの過程で、Python、PyWinおよびNutanix Mobility（ハイパーバイザー間互換性）ドライバーがインストールされます。

インストール完了後には、リブートが必要となります。

インストールおよびリブートが完了すると、「Programs and Features (プログラムと機能)」に以下の項目が表示されます：

NGTエージェントおよびVSS ハードウェア プロバイダー用サービスもまた稼動しています：

以上でNGTのインストールが完了し、利用可能となりました。

OSのカスタマイズ

Nutanixでは、CloudInitおよびSysprepを使用してネイティブにOSをカスタマイズすることが可能です。 CloudInitは、Linuxクラウドサーバーのブートストラップを処理するパッケージです。 これにより短時間でLinuxインスタンスの初期化とカスタマイズを行うことができます。 Sysprepは、WindowsのOSカスタマイズ機能です。

例えば、次のようなケースで使用します：

• ホスト名の設定
• パッケージのインストール
• ユーザーの追加、キー管理
• カスタムスクリプト

サポート対象構成

本ソリューションは、以下のバージョンを含むAHV上で稼動するLinuxゲストで有効となります。 （以下のリストは一部です。全てを確認する際には、ドキュメントをご覧ください）

• ハイパーバイザー：
  • AHV
• オペレーティングシステム：
  • Linux － 最新のディストリビューション
  • Windows － 最新のディストリビューション

前提

CloudInitを利用するためには以下が必要となります：

• CloudInitパッケージがLinuxイメージにインストールされていること

Sysprepはデフォルトで有効となっており、Windowsにインストールされています。

パッケージのインストレーション

CloudInitは（もし未済の場合には）以下のコマンドでインストールすることができます：

Red Hatベースのシステム (CentOS、RHEL)

yum -y install CloudInit

Debianベースのシステム (Ubuntu)

apt-get -y update; apt-get -y install CloudInit

Sysprepは、Windowsインストレーションの一部となっています。

イメージのカスタマイズ

カスタムスクリプトを使用してOSのカスタマイズを行うためには、PrismのチェックボックスまたはREST APIに内容を記述します。このオプションは、VMの作成またはクローニング処理の途中で指定します：

Nutanixには、カスタムスクリプトパスを指定するいくつかの方法があります：

• ADSFパス
  • 先にADSFにアップロードしたファイルを使用
• ファイルをアップロード
  • 使用するファイルをアップロード
• スクリプトを手入力または貼り付ける
  • CloudInitスクリプトまたはUnattend.xmlテキスト

Nutanixは、スクリプトを含むCD-ROM作成によって、初回ブート中にCloudInitまたはSysprepプロセスにユーザーデータスクリプトを引き渡します。 処理が完了した時点でCD-ROMを取り外します。

入力フォーマット

本プラットフォームは、様々なデータ入力フォーマットをサポートしていますが、以下に主な対象を示します：

ユーザーデータスクリプト (CloudInit – Linux)

ユーザーデータスクリプトは、簡単なシェルスクリプトでブートスクリプトの最後で処理されます（例えば「rc.local-like」）。

本スクリプトは、bashスクリプトのように「#!」で開始します。

以下にユーザーデータスクリプトの例を示します：

#!/bin/bash
touch /tmp/fooTest
mkdir /tmp/barFolder

インクルードファイル (CloudInit – Linux)

インクルードファイルには、URLのリスト（一行に1つ）が含まれています。各URLが読み込まれ、他のスクリプト同様に処理されます。

本スクリプトは「#include」で開始します。

以下はインクルードスクリプトの例です：

#include
http://s3.amazonaws.com/path/to/script/1
http://s3.amazonaws.com/path/to/script/2

クラウド構成データ (CloudInit – Linux)

cloud-config入力タイプは、CloudInitで最もよく使用されています。

本スクリプトは「#cloud-config」で開始します。

以下にクラウド構成データスクリプトの例を示します：

#cloud-config

# Set hostname
hostname: foobar

# Add user(s)
users:
  - name: nutanix
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh-authorized-keys:
      - ssh-rsa: <PUB KEY>
    lock-passwd: false
    passwd: <PASSWORD>

# Automatically update all of the packages
package_upgrade: true
package_reboot_if_required: true

# Install the LAMP stack
packages:
  - httpd
  - mariadb-server
  - php
  - php-pear
  - php-mysql

# Run Commands after execution
runcmd:
  - systemctl enable httpd

Unattend.xml (Sysprep - Windows)

unattend.xmlファイルは、ブート時のイメージカスタマイズに使用するSysprepの入力ファイルであり、詳細はこちらで確認できます： LINK

本スクリプトは、「<?xml version="1.0" ?>」で開始します。

以下はunattend.xmlファイルの例です：

<?xml version="1.0" ?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
   <settings pass="windowsPE">
      <component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35"
language="neutral" versionScope="nonSxS" processorArchitecture="x86">
         <WindowsDeploymentServices>
            <Login>
               <WillShowUI>OnError</WillShowUI>
               <Credentials>
                     <Username>username</Username>
                     <Domain>Fabrikam.com</Domain>
                     <Password>my_password</Password>
                  </Credentials>
               </Login>
            <ImageSelection>
               <WillShowUI>OnError</WillShowUI>
               <InstallImage>
                  <ImageName>Windows Vista with Office</ImageName>
                  <ImageGroup>ImageGroup1</ImageGroup>
                  <Filename>Install.wim</Filename>
               </InstallImage>
                  <InstallTo>
                  <DiskID>0</DiskID>
                  <PartitionID>1</PartitionID>
               </InstallTo>
            </ImageSelection>
         </WindowsDeploymentServices>
         <DiskConfiguration>
            <WillShowUI>OnError</WillShowUI>
               <Disk>
                  <DiskID>0</DiskID>
                  <WillWipeDisk>false</WillWipeDisk>
                  <ModifyPartitions>
                     <ModifyPartition>
                        <Order>1</Order>
                        <PartitionID>1</PartitionID>
                        <Letter>C</Letter>
                        <Label>TestOS</Label>
                        <Format>NTFS</Format>
                        <Active>true</Active>
                        <Extend>false</Extend>
                     </ModifyPartition>
                  </ModifyPartitions>
            </Disk>
         </DiskConfiguration>
      </component>
      <component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35"
language="neutral" versionScope="nonSxS" processorArchitecture="x86">
         <SetupUILanguage>
            <WillShowUI>OnError</WillShowUI>
            <UILanguage>en-US</UILanguage>
         </SetupUILanguage>
         <UILanguage>en-US</UILanguage>
      </component>
   </settings>
</unattend>

Karbon (コンテナサービス)

Nutanixは、（現状では）Kubernetesを使用することで、永続的 (persistent) コンテナを利用することができます。以前もNutanixプラットフォームでDockerを動かすことは可能でしたが、短命なコンテナの特性によってデータの永続性確保が困難でした。

Dockerのようなコンテナテクノロジーは、ハードウェアの仮想化とは異なるアプローチと言えます。従来の仮想化では、それぞれのVM自体がオペレーティングシステム (OS) を持っていましたが、基盤となるハードウェアは共有されていました。アプリケーションやそれに必要な全てを含むコンテナは、オペレーティングシステム (OS) のカーネルを共有しながら、独立したプロセスとして実行されます。

以下の表では、VMとコンテナの簡単な比較を行っています：

サポート対象構成

本ソリューションでは、以下の構成をサポートします。（一部のみを掲載しています。完全なリストについてはドキュメントをご覧ください）

ハイパーバイザー：
• AHV

コンテナシステム*：
• Docker 1.13

*AOS 4.7の時点で本ソリューションがサポートする対象は、Dockerベースのコンテナとの連携に限定されていますが、他のコンテナシステムについても、Nutanixプラットフォーム上のVMとして稼動させることが可能です。

コンテナサービスの構成要素

Karbonコンテナサービスは、以下の要素で構成されています：

• Nutanix Docker Machine Driver： Docker MachineおよびAOSイメージサービス経由でDockerコンテナホストのプロビジョニングを行います
• Nutanix Docker Volume Plugin： AOS Volumesとやり取りを行い、必要なコンテナに対してボリュームを作成、フォーマット、アタッチします

Dockerは以下の要素から構成されています（注意：全てが必要となる訳ではありません）

• Docker Image: コンテナのベースとイメージ
• Docker Registry: Dockerイメージの保持領域
• Docker Hub: オンラインコンテナのマーケットプレイス（パブリックDockerレジストリ）
• Docker File: Dockerイメージの構成方法に関する説明テキストファイル
• Docker Container: Dockerイメージのインストールを実行
• Docker Engine: Dockerコンテナの作成、提供、実行
• Docker Swarm: Dockerホストクラスタ / スケジューリングプラットフォーム
• Docker Daemon: Docker Clientからのリクエストを処理し、コンテナを構成、実行、配布
• Docker Store: エンタープライズ向けの信頼性の高いコンテナのマーケットプレイス

サービスのアーキテクチャー

現在のところNutanixでは、Docker Machineを使用して生成されたVM内で稼動するDocker Engineを使用しています。これらのマシンは、通常のVMと一緒にプラットフォーム上で稼動させることができます。

Nutanixが開発したDocker Volume Pluginは、AOS Volumesの機能を利用して、コンテナ用にボリュームを作成、フォーマット、そしてアタッチします。 これによって、電源のオン・オフの繰り返しや移動において、データはコンテナとして永続性を保つことができます。

データの永続性は、AOS Volumesを活用してボリュームをホストやコンテナにアタッチするNutanix Volume Pluginを使用することで確保されます。

前提

コンテナサービスを使用するためには、以下の前提条件を満たす必要があります：

• NutanixクラスタがAOS 4.7以降であること
• CentOS 7.0またはRHEL 7.2以上のOSイメージを、iscsi-initiator-utilsパッケージと一緒にダウンロード済みであり、それがAOSイメージサービス内にイメージとして存在すること
• NutanixデータサービスIPが設定されていること
• Docker Toolboxがクライアントマシンにインストールされ設定可能なこと
• Nutanix Docker Machine DriverがクライアントのPATHに存在すること

Dockerホストの作成

上記前提条件が全て満たされた前提で、Docker Machine を使用してNutanix Dockerホストをプロビジョニングする最初の手順は：

docker-machine -D create -d nutanix \
--nutanix-username <PRISM_USER> --nutanix-password <PRISM_PASSWORD> \
--nutanix-endpoint <CLUSTER_IP>:9440 --nutanix-vm-image <DOCKER_IMAGE_NAME> \
--nutanix-vm-network <NETWORK_NAME> \
--nutanix-vm-cores <NUM_CPU> --nutanix-vm-mem <MEM_MB> \
<DOCKER_HOST_NAME>

下図にバックエンドのワークフロー概要を示します：

次に、docker-machine ssh経由で、新たに用意されたDockerホストに対してSSHを実行します：

docker-machine ssh <DOCKER_HOST_NAME>

以下を実行して、Nutanix Docker Volume Pluginをインストールします：

docker plugin install ntnx/nutanix_volume_plugin PRISM_IP=<PRISM-IP> DATASERVICES_IP=<DATASERVICES-IP> PRISM_PASSWORD=<PRISM-PASSWORD> PRISM_USERNAME=<PRISM-USERNAME> DEFAULT_CONTAINER=<Nutanix-STORAGE-CONTAINER> --alias nutanix

起動が完了したら、プラグインの有効化を確認します：

[root@DOCKER-NTNX-00 ~]# docker plugin ls
ID        	    Name              Description    		        Enabled
37fba568078d        nutanix:latest    Nutanix volume plugin for docker  true

Dockerコンテナの作成

Nutanix Dockerホストが導入され、ボリュームプラグインが有効化されると、永続的ストレージにコンテナをプロビジョニングすることができます。

通常のdocker volumeコマンド構造を使ってNutanix Volume Driverを指定することで、AOS Volumesを使用するボリュームを作成することができます。 以下に例を示します：

docker volume create \
<VOLUME_NAME> --driver nutanix

例：

docker volume create PGDataVol --driver nutanix

以下のコマンド構造を使って、作成したボリュームを使用するコンテナを作成できます。

docker run -d --name <CONTAINER_NAME> \
-p <START_PORT:END_PORT> --volume-driver nutanix \
-v <VOL_NAME:VOL_MOUNT_POINT> <DOCKER_IMAGE_NAME>

例：

docker run -d --name postgresexample -p 5433:5433 --volume-driver nutanix -v PGDataVol:/var/lib/postgresql/data postgres:latest

下図にバックエンド処理のワークフローを示します：

以上のように、永続的ストレージ上でコンテナを動かすことができました！

重要なページ

一般的なユーザーインターフェイスに加え、高度なNutanixページを参照して、詳細なステータスや指標をモニターすることができます。 URLは、http://<Nutanix CVM IP/DNS>:<Port/path（以下に説明）> という形式になります。
例： http://MyCVM-A:2009
注意： 異なるサブネットを使用している場合、ページにアクセスするためにはiptablesをCVMで無効化する必要があります。

2009 ページ

バックエンド ストレージ システムをモニターするためのページであり、上級ユーザー向けとなります。 2009ページの説明や内容について別途投稿があります。

2009/latency ページ

バックエンドのレイテンシーをモニターするためのStargateのページです。

2009/vdisk_stats ページ

I/Oサイズやレイテンシー、WRITEヒット（OpLog、eStoreなど）、READヒット（キャッシュ、SSD、HDDなど）その他のヒストグラムを含む、様々なvDiskステータスを提示する、Stargateのページです。

2009/h/traces ページ

オペレーション状況をトレースしモニターするための、Stargateのページです。

2009/h/vars ページ

各種カウンターをモニターするためのStargateのページです。

2010 ページ

Curatorの稼動状況をモニターするためのCuratorのページです。

2010/master/control ページ

Curatorジョブをマニュアルで起動するための、Curatorコントロールのページです。

2011 ページ

Curatorによってスケジューリングされたジョブやタスクをモニターするための、Chronosのページです。

2020 ページ

 プロテクションドメイン、レプリケーションのステータス、DRをモニターするための、Cerebroのページです。

2020/h/traces ページ

PD処理やレプリケーション状況をトレースしモニターするための、Cerebroのページです。

2030 ページ

Acropolisのメインとなるページで、環境内のホスト、稼動中のタスク、ネットワークなどの詳細を提示します。

2030/sched ページ

VMやリソース配分の計画に必要な情報を提示するAcropolisのページです。このページには、利用可能なホストのリソースと各ホストで稼動するVMが表示されます。

2030/tasks ページ

Acropolisのタスクとステータスに関する情報を提示するAcropolisのページです。タスクのUUIDをクリックすると、タスクに関するJSONの詳細情報が表示されます。

2030/vms ページ

AcropolisのVMとその詳細情報を提示するAcropolisのページです。VM名 (VM Name) をクリックすると、コンソールに接続されます。

クラスタコマンド

クラスタのステータを確認

説明： CLIからクラスタのステータスを確認

cluster status

ローカルCVMサービスのステータスを確認

説明： CLIから特定のCVMサービスのステータスを確認

genesis status

アップグレードのステータスを確認

upgrade_status

手動のCLIアップグレードを実行

• <NUTANIX INSTALLER PACKAGE>.tar.gzを~/tmpにダウンロード

cd ~/tmp

tar xzf <NUTANIX INSTALLER PACKAGE>.tar.gz

./install/bin/cluster -i ./install upgrade

ノードアップグレード

ハイパーバイザーのアップグレードステータス

説明： CVMのCLIから、ハイパーバイザーのアップグレードステータスを確認

host_upgrade_status

詳細ログ（各CVM上）

~/data/logs/host_upgrade.out

CLIからクラスタサービスを再起動

説明： CLIから特定のクラスタサービスを再起動

サービスを停止

cluster stop <Service Name>

停止したサービスを起動

cluster start  #NOTE: This will start all stopped services

CLIからクラスタサービスを起動

説明： CLIから停止したクラスタサービスを起動

停止したサービスを起動（注意： 全ての停止サービスが起動されます）

cluster start  #NOTE: This will start all stopped services

または

特定のサービスを起動

cluster start  <Service Name>

CLIからローカルサービスを再起動

説明： CLIから特定のクラスタサービスを再起動

サービスを停止

genesis stop <Service Name>

サービスを起動

cluster start

CLIからローカルサービスを起動

説明： CLIから停止したクラスタサービスを起動

cluster start #NOTE: This will start all stopped services

CLIでクラスタにノードを追加

説明： CLIからクラスタにノードを追加

ncli cluster discover-nodes | egrep "Uuid" | awk '{print $4}' | xargs -I UUID ncli cluster add-node node-uuid=UUID

クラスタIDを調査

説明： 現在のクラスタの、クラスタIDを調査

zeus_config_printer | grep cluster_id

ポートのオープン

説明： iptablesでポートを有効化

sudo vi /etc/sysconfig/iptables
-A INPUT -m state --state NEW -m tcp -p tcp --dport <PORT> -j ACCEPT
sudo service iptables restart

シャドウ クローンの確認

説明： シャドウ クローンを次の形式で表示： name#id@svm_id

vdisk_config_printer | grep '#'

レイテンシーページのステータスを初期化

説明： レイテンシーページ (:2009/latency) のカウンターを初期化

allssh "wget $i:2009/latency/reset"

vDisk情報を調査

説明: vDiskの情報や名前、ID、サイズ、IQNとして他を含む詳細を調査

vdisk_config_printer

vDiskの数を調査

説明： DSF上のvDisk（ファイル）の数を調査

vdisk_config_printer | grep vdisk_id | wc -l

vDiskの詳細情報の確認

説明： 指定したvDiskのegroup ID、サイズ、変換とセービング、ガベージ、レプリカ配置を表示

vdisk_usage_printer -vdisk_id=<VDISK_ID>

CLIからCuratorスキャンを起動

説明： CLIからCuratorフルスキャンを起動

フルスキャン

allssh "wget -O - "http://localhost:2010/master/api/client/StartCuratorTasks?task_type=2";"

部分的なスキャン

allssh "wget -O - "http://localhost:2010/master/api/client/StartCuratorTasks?task_type=3";"

使用量の更新

allssh "wget -O - "http://localhost:2010/master/api/client/RefreshStats";"

CLIからレプリケーション中のデータの確認

説明： curator_idでレプリケーション中のデータを確認

curator_cli get_under_replication_info summary=true

リングを圧縮

説明：メタデータリングを圧縮

allssh "nodetool -h localhost compact"

AOSのバージョンを調査

説明： AOSのバージョンを調査（注意： NCLIを使うことも可能）

allssh "cat /etc/nutanix/release_version"

CVMのバージョンを調査

説明： CVMのイメージのバージョンを調査

allssh "cat /etc/nutanix/svm-version"

vDiskをマニュアルでフィンガープリント

説明： (重複解除向けに) 特定のvDiskのフィンガープリントを作成。注意：コンテナの重複排除が有効になっている必要があります。

vdisk_manipulator -vdisk_id=<vDisk ID> --operation=add_fingerprints

全てのvDiskをマニュアルでフィンガープリント

説明：（重複排除向けに）全てのvDiskのフィンガープリントを作成。注意：コンテナの重複排除が有効になっている必要があります。

for vdisk in `vdisk_config_printer | grep vdisk_id | awk {'print $2'}`; do vdisk_manipulator -vdisk_id=$vdisk --operation=add_fingerprints; done

全てのクラスタノードに対しFactory_Config.json をエコー

説明： 全てのクラスタノードに対しFactory_Config.json をエコー

allssh "cat /etc/nutanix/factory_config.json"

特定のNutanixノードのAOSバージョンをアップグレード

説明： 特定のノードのAOSバージョンとクラスタに整合ようにアップグレード

~/cluster/bin/cluster -u <NEW_NODE_IP> upgrade_node

 DSFのファイル（vDisk）一覧

説明： ファイルとDSFにストアされているvDiskに関する情報一覧を表示

nfs_ls

ヘルプテキストの出力

nfs_ls --help

Nutanix Cluster Check (NCC) のインストール

説明： 潜在的問題やクラスタのヘルスをテストするためのヘルススクリプト、Nutanix Cluster Check (NCC) をインストール

• NCCをNutanixサポートポータル（portal.nutanix.com）からダウンロード
• SCPで.tar.gzを/home/nutanixディレクトリに転送する
• NCC .tar.gz を展開（untar）する

tar xzmf <ncc .tar.gz file name> --recursive-unlink

インストールスクリプトの実行

./ncc/bin/install.sh -f <ncc .tar.gz file name>

リンクを作成

source ~/ncc/ncc_completion.bash
echo "source ~/ncc/ncc_completion.bash" >> ~/.bashrc

Nutanix Cluster Check（NCC）の実行

説明：潜在的問題やクラスタのヘルスをテストするためのヘルススクリプト、Nutanix Cluster Check (NCC) を実行。 クラスタに問題が発見された場合のトラブルシューティングとして、最初に実行すべきことです。

• NCCがインストールされていることを確認（前述の手順）

NCCヘルスチェックを実行

ncc health_checks run_all

「progress monitor cli」を使用したタスク一覧の作成

progress_monitor_cli -fetchall

「progress monitor cli」を使用したタスクの削除

progress_monitor_cli --entity_id=<ENTITY_ID> --operation=<OPERATION> --entity_type=<ENTITY_TYPE> --delete

注意: operationとentity_typeは、先頭にある小文字のkをすべて削除する必要があります。

指標値としきい値

以下のセクションでは、Nutanixバックエンドに対する特定の指標や、しきい値について説明します。この内容は今後も適時更新します！

Gflags

近日公開！

トラブルシューティングと高度な管理

Acropolisのログを調査

説明： クラスタのAcropolisのログを調査

allssh "cat ~/data/logs/Acropolis.log"

クラスタのエラーログを調査

説明： クラスタのERRORログを調査

allssh "cat ~/data/logs/<COMPONENT NAME or *>.ERROR"

Stargateの例

allssh "cat ~/data/logs/Stargate.ERROR"

クラスタのフェータルログの調査

説明： クラスタのFATALログを調査

allssh "cat ~/data/logs/<COMPONENT NAME or *>.FATAL"

Stargateの例

allssh "cat ~/data/logs/Stargate.FATAL"

2009ページの利用 (Stargate)

ほとんどの場合、必要な情報やデータはPrismを使って得ることができます。 しかし、より詳細な情報を入手したいような場合は、Stargate（または2009ページと呼ばれる）を使用することができます。 2009ページは、<CVM IP>:2009 で見ることができます。

バックエンドページへのアクセス

異なるネットワークセグメント（L2サブネット）にいる場合、バックエンドページにアクセスするためには、IPテーブルにルールを追加する必要があります。

ページの最上部には、クラスタに関する様々な細部に関する概要が表示されます。

このセクションには、2つの重要な部分が含まれています。最初は処理待ち/未処理のI/O数を表すI/O Queueです。

以下は、概要セクションのQueueに関する部分です：

2つめは、コンテンツキャッシュのキャッシュサイズとヒット率に関する情報を表示する部分です。

以下は、概要セクションのコンテンツキャッシュに関する部分です：

プロからのヒント

理想的には、ワークロードがREAD中心型で、最大のREADパフォーマンスを発揮した場合、ヒット率は80～90％を超えるものになります。

注意： 以上は、Stargate / CVM あたりの数値です。

次は「クラスタステータス」に関するセクションで、クラスタ内のStargateとそのディスク使用状況に関する詳細を表示しています。

以下は、Stargateとディスク使用状況（利用可能/合計）を図示したものです：

次のは「NFSワーカー」に関するセクションで、vDisk単位で様々な詳細やステータスを表示しています。

以下は、vDiskとI/Oの詳細を図示したものです：

プロからのヒント

パフォーマンスに関する問題を調査する場合、以下の値を確認します：

1. 平均レイテンシー(Avg. latency)
2. 平均オペレーションサイズ(Avg. op size)
3. 平均処理待ち数

より詳細な情報が、vdisk_stats ページに多数含まれています。

2009/vdisk_stats ページの利用

2009 vdisk_statsページは、vDiskに関するより詳細なデータを提供するためのページです。このページにはランダムネス、レイテンシーヒストグラム、I/Oサイズ、ワーキングセットの詳細などが含まれています。

左の列にある「vDisk Id」をクリックするとvDisk_statsページに移ります。

以下は、セクションとvDisk IDのハイパーリンクを示しています：

vdisk_statsページに移ると、vDiskのステータス詳細が表示されます。注意： 表示されている値はリアルタイムなもので、ページをリフレッシュすることで更新することができます。

まず重要なセクションは、「オペレーションとランダムネス (Ops and Randomness)」で、I/Oパターンをランダムなものとシーケンシャルなものに分解しています。

以下は、「オペレーションとランダムネス (Ops and Randomness)」セクションを図示したものです：

次の部分には、フロントエンドのREADおよびWRITE I/Oのレイテンシー（あるいはVM/OSから見たレイテンシー）のヒストグラムが表示されています。

以下が、「フロントエンドREADレイテンシー」のヒストグラムになります：

以下が、「フロントエンドWRITEレイテンシー」のヒストグラムになります：

次の重要な領域は、I/Oサイズの分散で、READとWRITEのI/Oサイズのヒストグラムを表示しています。

以下が、「READサイズの分散」のヒストグラムになります：

以下が、「WRITEサイズの分散」のヒストグラムになります：

次の重要な領域は、「ワーキングセットサイズ」で、直近2分間と1時間におけるワーキングセットサイズに関する情報を提供しています。内容は、READとWRITE I/Oに分けられています。

以下が、「ワーキングセットサイズ」テーブルになります：

「READソース (Read Source)」は、READ I/Oに対する処理が行われた階層またはロケーションの詳細を示します。

以下が、「READソース (Read Source)」詳細になります：

プロからのヒント

READに高いレイテンシーが見られる場合、vDiskのREADソースを見て、I/O処理がどこで行われているかを確認します。 ほとんどの場合、READがHDD（Estore HDD）で処理されることでレイテンシーが高くなります。

「WRITE先 (Write Destination)」は、新規WRITE I/Oがどこに対して行われるかを示します。

以下が、「WRITE先 (Write Destination)」一覧になります：

プロからのヒント

ランダムまたは小規模なI/O (<64K) は、OpLogに書き込まれます。大規模あるいはシーケンシャルなI/OはOpLogをバイパスし、エクステントストア (Estore)に直接書き込まれます。

データの、HDDからSSDへの上層移動がILMによって行われます。 「エクステントグループ上層移動（Extent Group Up-Migration）」一覧は、直近300、3,600、86,400秒に上層移動したデータを示しています。

以下が、エクステントグループ上層移動（Extent Group Up-Migration）」一覧になります：

2010ページの利用 (Curator)

2010ページは、Curator MapReduceフレームワークの詳細をモニターするためのページです。このページは、ジョブ、スキャンおよび関連するタスクの詳細情報を提供します。

Curatorページには、http://<CVM IP>:2010 から入ることができます。 注意： Curatorリーダーにいない場合は、「Curator Leader：」の後のIPアドレスをクリックしてください。

ページの上部には、稼動時間、ビルドバージョンなど、Curatorリーダーに関する詳細な情報が表示されます。

次のセクションには、「Curatorノード」一覧があり、クラスタ内のノード、ロール、ヘルス状態といった詳細が表示されています。 これらは、Curatorが分散処理とタスクの移譲のために使用しているノードです。

以下が「Curatorノード」一覧になります：

次のセクションは「Curatorジョブ」一覧で、完了したジョブと現在実行中のジョブを表示しています。

ジョブには主に、60分に1回程度の実行が望ましいパーシャルスキャンと、6時間に1回程度の実行が望ましいフルスキャンという2つのタイプがあります。注意：実行タイミングは、使用率や他の処理状況により異なります。

スキャンはスケジュールに基づいて定期的に実行されますが、特定のクラスタイベントによっても起動されます。

ジョブが実行されるいくつかの理由を、以下に示します：

• 定期実行（通常の状態）
• ディスク、ノードまたはブロックの障害
• ILMの不均衡
• ディスクまたは階層の不均衡

以下が「Curatorジョブ」一覧になります：

一覧には、各ジョブが実行したアクティビティの概要の一部が記載されています：

処理	フルスキャン	パーシャルスキャン
ILM	X	X
ディスクバランシング	X	X
圧縮	X	X
重複排除	X
消失訂正符号 (EC)	X
ガベージクリーンアップ	X

「実行ID (Execution ID)」をクリックすると、ジョブの詳細ページに移り、生成されたタスクと同時にジョブの詳細情報が表示されます。

ページの上部に表示される一覧には、ジョブのタイプ、理由、タスク、デュレーションといった詳細が表示されます。

次のセクションには「バックグラウンドタスクステータス (Background Task Stats)」一覧があり、タスクのタイプ、生成された数量やプライオリティといった詳細が表示されます。

以下がジョブ詳細一覧になります：

以下が「バックグラウンドタスクステータス」一覧になります：

次のセクションには「MapReduceジョブ」一覧があり、各Curatorジョブにより起動された、実際のMapReduceジョブが表示されます。パーシャルスキャンには単独のMapReduceジョブとなり、フルスキャンは4つのMapReduceジョブとなります。

以下が「MapReduceジョブ」一覧になります：

「ジョブID (Job ID)」をクリックすると、MapReduceジョブの詳細ページに移り、タスクステータス、各種カウンター、MapReduceジョブの詳細が表示されます。

以下に、ジョブのカウンターの例を図示します：

メインページの次のセクションには、「QueueされたCuratorジョブ」および「最後に完了したCuratorスキャン」一覧があります。これらの一覧には、定期的なスキャンを実施すべき適切な時間と、最後に実行されたたスキャン詳細が表示されています。

以下が「QueueされたCuratorジョブ」および「最後に完了したCuratorスキャン」セクションになります：

nutanix@NTNX-13SM35210012-A-CVM:~$ vdisk_config_printer | more
...
vdisk_id: 1014400
vdisk_name: "NFS:1314152"
parent_vdisk_id: 16445
vdisk_size: 40000000000
container_id: 988
to_remove: true
creation_time_usecs: 1414104961926709
mutability_state: kImmutableSnapshot
closest_named_ancestor: "NFS:852488"
vdisk_creator_loc: 7
vdisk_creator_loc: 67426
vdisk_creator_loc: 4420541
nfs_file_name: "d12f5058-f4ef-4471-a196-c1ce8b722877"
may_be_parent: true
parent_nfs_file_name_hint: "d12f5058-f4ef-4471-a196-c1ce8b722877"
last_modification_time_usecs: 1414241875647629
...

nutanix@NTNX-13SM35210012-A-CVM:~$ vdisk_usage_printer -vdisk_id=99999
    Egid  # eids  UT Size    T Size ... T Type  Replicas(disk/svm/rack)
 1256878  64      1.03 MB   1.03 MB ... D,[73 /14/60][184108644 /184108632/60]
 1256881  64      1.03 MB   1.03 MB ... D,[73 /14/60][152 /7/25]
 1256883  64      1.00 MB   1.00 MB ... D,[73 /14/60][184108642 /184108632/60]
 1055651  4       4.00 MB   4.00 MB ... none[76 /14/60][184108643 /184108632/60]
 1056604  4       4.00 MB   4.00 MB ... none[74 /14/60][184108642 /184108632/60]
 1056605  4       4.00 MB   4.00 MB ... none[73 /14/60][152 /7/25]
 ...

  CVM:~$ curator_cli display_data_reduction_report
  Using curator leader: 99.99.99.99:2010
  Using execution id 68188 of the last successful full scan
  +---------------------------------------------------------------------------+
  | Container| Technique      | Pre        | Post       | Saved     | Ratio   |
  | Id       |                | Reduction  | Reduction  |           |         |
  +---------------------------------------------------------------------------+
  | 988      | Clone          | 4.88 TB    | 2.86 TB    | 2.02 TB   | 1.70753 |
  | 988      | Snapshot       | 2.86 TB    | 2.22 TB    | 656.92 GB | 1.28931 |
  | 988      | Dedup          | 2.22 TB    | 1.21 TB    | 1.00 TB   | 1.82518 |
  | 988      | Compression    | 1.23 TB    | 1.23 TB    | 0.00 KB   | 1       |
  | 988      | Erasure Coding | 1.23 TB    | 1.23 TB    | 0.00 KB   | 1       |
  | 26768753 | Clone          | 764.26 GB  | 626.25 GB  | 138.01 GB | 1.22038 |
  | 26768753 | Snapshot       | 380.87 GB  | 380.87 GB  | 0.00 KB   | 1       |
  | 84040    | Snappy         | 810.35 GB  | 102.38 GB  | 707.97 GB | 7.91496 |
  | 6853230  | Snappy         | 3.15 TB    | 1.09 TB    | 2.06 TB   | 2.88713 |
  | 12199346 | Snappy         | 872.42 GB  | 109.89 GB  | 762.53 GB | 7.93892 |
  | 12736558 | Snappy         | 9.00 TB    | 1.13 TB    | 7.87 TB   | 7.94087 |
  | 15430780 | Snappy         | 1.23 TB    | 89.37 GB   | 1.14 TB   | 14.1043 |
  | 26768751 | Snappy         | 339.00 MB  | 45.02 MB   | 293.98 MB | 7.53072 |
  | 27352219 | Snappy         | 1013.8 MB  | 90.32 MB   | 923.55 MB | 11.2253 |
  +---------------------------------------------------------------------------+

  Using curator leader: 99.99.99.99:2010
  VDisk usage stats:
  +------------------------------------------------------------------------+
  | VDisk Id  | Exclusive  | Logical      | Logical  | Logical   | Logical |
  |           | usage      | Uninherited  | Dedup    | Snapshot  | Clone   |
  +------------------------------------------------------------------------+
  | 254244142 | 596.06 MB  | 529.75 MB    | 6.70 GB  | 11.55 MB  | 214 MB  |
  | 15995052  | 599.05 MB  | 90.70 MB     | 7.14 GB  | 0.00 KB   | 4.81 MB |
  | 203739387 | 31.97 GB   | 31.86 GB     | 24.3 MB  | 0.00 KB   | 4.72 GB |
  | 22841153  | 147.51 GB  | 147.18 GB    | 0.00 KB  | 0.00 KB   | 0.00 KB |
...

Using curator leader: 99.99.99.99:2010
Container Id: 988
+----------------------------------------------------------------------------..
| Access \ Modify (secs) | [0,300) | [300,3600) | [3600,86400) | [86400,60480..
+----------------------------------------------------------------------------..
| [0,300)                | 345     | 1          | 0            | 0           ..
| [300,3600)             | 164     | 817        | 0            | 0           ..
| [3600,86400)           | 4       | 7          | 3479         | 7           ..
| [86400,604800)         | 0       | 0          | 81           | 7063        ..
| [604800,2592000)       | 0       | 0          | 15           | 22          ..
| [2592000,15552000)     | 1       | 0          | 0            | 10          ..
| [15552000,inf)         | 0       | 0          | 0            | 1           ..
+----------------------------------------------------------------------------..
...

ノードアーキテクチャー

AHVを導入した場合、コントローラーVM（CVM）はひとつのVMとして稼動し、ディスクはPCIパススルーを使用するようになります。 これにより、PCIコントローラー（および付属デバイス）のパススルーが完全に実現され、ハイパーバイザーを迂回してCVMに直接繋がるようになります。 AHVは、CentOS KVMをベースに構築されています。 ゲストVM (HVM) に対しては、完全なハードウェアの仮想化を使用します。

AHVは、CentOS KVMをベースに基本機能を拡張し、HAやライブ マイグレーションなどの機能を組み込んだものです。

AHVは、Microsoft Server Virtualization Validation Programの認定を受け、またMicrosoft OS やアプリケーションの稼動検証を受けています。

KVMアーキテクチャー

KVMの主要なコンポーネントは、以下に示す通りです：

• KVM-kmod
  • KVMのカーネルモジュール
• Libvirtd
  • KVMとQEMUを管理するためのAPI、デーモン、管理ツールです。AOSとKVM/QEMUはlibvirtdを経由して通信します
• Qemu-kvm
  • 全ての仮想マシン（ドメイン）上で稼動するマシンエミュレータおよびバーチャライザです。AHV内で本コンポーネントは、ハードウェア アシステッドな仮想化に利用され、VMはHVMとして稼動します

以下に各コンポーネントの関連を示します：

AOSとKVM/QEMUは、libvirtdを経由して通信します。

最大構成と拡張性

以下の最大構成と拡張制限が適用されます：

• 最大クラスタサイズ： N/A – Nutanixクラスタサイズと同じ
• VMあたりの最大vCPU数： ホストあたりの物理コア数
• VMあたりの最大メモリ： 最小4TBまたは使用可能な物理ノードメモリ
• 最大仮想ディスクサイズ： 9EB（Exabyte）
• ホストあたりの最大VM数： N/A - メモリに依存
• クラスタあたりの最大VM数： N/A - メモリに依存

*AHVには、ESXiやHyper-Vのような従来型のストレージ スタックはありません。 全てのディスクがロー（Raw）SCSIブロックデバイスとしてVMに提供されます。 このため、最大仮想ディスクサイズについては、最大DSF vDiskサイズ（9 エクサバイト）の制約を受けることになります。

ネットワーク

AHVは、全てのVMネットワークに対してOpen vSwitch (OVS) を活用しています。VMネットワークは、PrismやACLIから設定することが可能で、各VM NICは、Tapインターフェイスに接続されます。

以下に、OVSアーキテクチャーの概念構成を示します：

上記の画像には、いくつかの種類のコンポーネントが表示されています。

Open vSwitch (OVS)

OVSとは、Linuxカーネルに実装され、複数台のサーバー仮想化環境で動作するように設計されたオープンソースのソフトウェアスイッチです。 デフォルトでは、OVSはMACアドレステーブルを維持するレイヤー2ラーニングスイッチのように動作します。 ハイパーバイザーホストとVMはスイッチの仮想ポートに接続します。

OVSは、VLANタグ、Link Aggregation Control Protocol（LACP）、ポートミラーリング、Quality of Service（QoS）など、多くの一般的なスイッチの機能をサポートしています。 各AHVサーバーはOVSインスタンスを持ち、すべてのOVSインスタンスが結合して単一の論理スイッチを形成します。 ブリッジと呼ばれる構造は、AHVホストにあるスイッチのインスタンスを管理します。

ブリッジ

ブリッジとは、物理と仮想ネットワークインターフェイス間のネットワークトラフィックを管理する仮想スイッチとして機能します。 デフォルトのAHV構成には、br0と呼ばれるOVSブリッジとvirbr0と呼ばれるネイティブLinuxブリッジが含まれています。 virbr0 Linuxブリッジは、CVMとAHVホスト間の管理およびストレージ通信を運送します。 他のすべてのストレージ、ホスト、およびVMネットワークのトラフィックはbr0 OVSブリッジを通過します。 AHVホスト、VM、および物理インターフェイスは、ブリッジへの接続に「ポート」を使用します。

ポート

ポートとは、仮想スイッチへの接続を表す、ブリッジに作成された論理構造です。 Nutanixでは、internal、tap、VXLAN、ボンドを含む、いくつかのポートタイプを使用します。

• internalポート（デフォルトブリッジであるbr0と同じ名前のもの）は、AHVホストへのアクセスを提供します。
• tapポートは、VMに提供される仮想NICのブリッジ接続として機能します。
• VXLANポートは、Acropolisが提供するIPアドレス管理機能で使用されます。
• ボンドポートは、AHVホストの物理インターフェイスにNICチーミングを提供します。

ボンド（bond）

ボンドポートは、AHVホスト上の物理インターフェイスを束ねます。 デフォルトでは、br0-upという名前のボンドがbr0ブリッジに作成されます。 ノードをイメージングすると、すべてのインターフェイスは単一のボンド内に配置されます。これは、Foundationでのイメージング処理の要件によるものです。 デフォルトのボンド(AHVホストではbr0-up)に対して、(一般的なLinuxでは)bond0という名前がしばしば用いられますが、 Nutanixは、インターフェイスをブリッジbr0のアップリンクとして迅速に識別できるように、名前はbr0-upのまま使用することを推奨します。

OVSのボンドでは、active-backup、balance-slb、balance-tcpといった、いくつかの負荷分散モードが設定できます。 ボンドに対してLACPも有効化できます。 「bond_mode」の設定はインストール中に指定されないためデフォルトはactive-backupであり、これは推奨構成です。

アップリンクのロードバランシング

前のセクションで簡単に説明したように、ボンドアップリンク間でトラフィックを分散できます。

以下のボンドモードが使用できます：

• active-backup
  • デフォルトの構成で、単一のアクティブなアダプターを経由してすべてのトラフィックを送信します。 アクティブなアダプターが使用できなくなると、ボンド内の別のアダプターがアクティブになります。 スループットは単一のNICの帯域幅に制限されます。 （推奨構成）
• balance-slb
  • ボンド内のアダプター間で、VM NICごとに分散します（例えば、VM Aの持つnic1がeth0、nic2がeth1）。 VMのNICあたりのスループットは単一のNICの帯域幅に制限されますが、n個のNICを持つVMは「n * アダプター帯域幅」を活用できます（ボンド内のVMのNICと物理アップリンクアダプターの数が同じであると想定すると）。 注：マルチキャストトラフィックに関して注意事項があります。
• balance-tcp / LACP
  • ボンド内のアダプター間で、VM NICのTCPセッションごとで分散します。 NICごとのスループットは、ボンドの最大帯域幅（物理アップリンクアダプター数 * 速度）に制限されます。 Link Aggregationが必要で、そしてLACPが必要な場合に使用されます。

ボンドの詳細については、AHV Networkingのベストプラクティスガイド（LINK）を参照してください。

VM NICの種類

AHVは、以下のVMネットワークインターフェイスの種類をサポートします：

• Access（デフォルト）
• Trunk（AOS 4.6以上）

デフォルトで、VMのNICはAccessインターフェイスとして生成されますが、（ポートグループ上のVMのNIC同様に）VMのOSにTrunkインターフェイスとして提示することも可能です。 Trunk設定されたNICはプライマリVLANをタグなしで送信し、追加のすべてのVLANをタグ付けしてVM上の同じvNICで送信します。 これは、VMにvNICを追加せずに複数のネットワークを接続する場合に役立ちます。

Trunkインターフェイスは、以下のコマンドで追加することができます：

vm.nic_create <VM_NAME> vlan_mode=kTrunked trunked_networks=<ALLOWED_VLANS> network=<NATIVE_VLAN>

例:

vm.nic_create fooVM vlan_mode=kTrunked trunked_networks=10,20,30 network=vlan.10

サービスチェーン

AHVサービスチェーン（service chaining）によって、全てのトラフィックをインターセプトし、パケット処理機能（NFV、アプライアンス、仮想アプライアンスなど）に対してネットワークパスの延長として透過的に渡すことができます。

サービスチェーンの一般的な使用例：

• ファイアウォール（例えば、Palo Altoなど）
• ロードバランサー（例えば、NetScalerなど）
• IDS/IPS/ネットワークモニター（例えば、パケットキャプチャー）

サービスチェーンには、2つの方式があります：

• インライン (Inline) パケット処理
  • OVSを流れるパケットをインラインでインターセプト
  • パケットの変更、許可/拒否が可能
  • 一般的な適用例： ファイアウォールやロードバランサー
• タップ (Tap) パケットプロセッサ
  • パケットフローにタップして読み込みを行い、パケットを検査
  • 一般的な適用例： IDS、IPS、ネットワーク監視

全てのサービスチェーン処理は、Flowのマイクロセグメンテーション ルールが適用された後、かつパケットがローカルOVSから出る前に完了します:

説明: 複数のパケットプロセッサを、1つのチェーンに繋ぎ合わせることも可能です。

ストレージI/Oパス

AHVは、ESXiやHyper-Vのような従来のストレージ スタックを使用してはいません。 全てのディスクは、ロー（raw）SCSIブロックデバイスとしてVMに渡されます。 これによってI/Oパスを軽量化および最適化することができます。

各AHVホストには、iSCSIリダイレクター デーモンが常駐し、NOP OUTコマンドを使用してクラスタのStargateに関するステータスチェックを行います。

iscsi_redirectorログ（AHVホストの/var/log/に存在）によって、各Stargateの稼動状態を確認することができます：

2017-08-18 19:25:21,733 - INFO - Portal 192.168.5.254:3261 is up
...
2017-08-18 19:25:25,735 - INFO - Portal 10.3.140.158:3261 is up
2017-08-18 19:25:26,737 - INFO - Portal 10.3.140.153:3261 is up

注意: ローカルのStargateは、内部アドレス192.168.5.254で確認できます。

以下の内容を見ると、iscsi_redirectorが127.0.0.1:3261でリスニングしていることが分かります：

[root@NTNX-BEAST-1 ~]# netstat -tnlp | egrep tcp.*3261
Proto ... Local Address   Foreign Address   State     PID/Program name
...
tcp   ... 127.0.0.1:3261  0.0.0.0:*         LISTEN    8044/python
...

QEMUは、iSCSIリダイレクターがiSCSIターゲットポータルとなるよう設定されます。ログインリクエストがあるとリダイレクターが起動され、iSCSIログインは、正常なStargate（通常はローカルにある）にリダイレクトされます。

XMLのドメインを確認すると、その構成が分かります:

<devices>
...
<disk type='network' device='lun'>
  <driver name='qemu' type='raw' cache='none' error_policy='report' io='native'/>
  <source protocol='iscsi' name='iqn.2010-06.com.nutanix:vmdisk-16a5../0'>
    <host name='127.0.0.1' port='3261'/>
  </source>
  <backingStore/>
  <target dev='sda' bus='scsi'/>
  <boot order='1'/>
  <alias name='scsi0-0-0-0'/>
  <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
...
</devices>

推奨するコントローラータイプは、virtio-scsi（SCSIデバイスのデフォルト）です。 IDEも使用できますが、ほとんどの場合、お薦めできません。Windowsでvirtioを使用する場合には、virtioドライバー、Nutanixモビリティドライバー、またはNutanix Guest Toolsがインストールされている必要があります。 最新のLinuxディストリビューターは、virtioをプリインストールして出荷しています。

...
<controller type='scsi' index='0' model='virtio-scsi'>
 <driver max_sectors='2048'/>
 <alias name='scsi0'/>
 <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</controller>
...

稼動中のStargateが停止した（NOP OUTコマンドにレスポンスできない）場合、iSCSIリダイレクターは、ローカルのStargateを障害として判断します。そして、QEMUがiSCSIログインを再試行した時に、リダイレクターは、ログインオペレーションを他の正常なStargateにリダイレクトします。

ローカルのStargateが復旧（かつNOP OUTコマンドにレスポンスを開始）した場合、iSCSIリダイレクターは、リモートStargateへのiSCSIセッションを終了します。 QEMUは、iSCSIログインを再度試み、同ログインはローカルのStargateにリダイレクトされます。

従来のI/Oパス

全てのハイパーバイザーやOSと同様、ユーザー空間とカーネル空間のコンポーネントが相互にやり取りを行って、1つの処理を実行しています。 以下を読む前に「ユーザー空間とカーネル空間」のセクションを参照し、お互いがどういった関係でやり取りをしているかを理解することをお勧めします。

VMがI/Oを実行する場合、以下の処理が行われます（理解しやすくするため、一部の手順は省略してあります）：

1. VMのOSが仮想デバイスに対してSCSIコマンドを実行
2. Virtio-SCSIがリクエストを受け取り、ゲストのメモリに保存
3. QEMUメインループがリクエストを処理
4. Libiscsiが各リクエストを検査して転送
5. ネットワーク層がリクエストをローカルCVMに転送（ローカルCVMが利用できない場合は外部のCVM）
6. Stargateがリクエストを処理

以下に、このフローの例を示します：

ドメインのXMLに着目すると、qemu-kvmエミュレータが使用されていることが分かります。

...
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
...

またAHVホストを見ると、ローカルブリッジとIPを使用している正常なStargateを使って、qemu-kvmがセッションを確立しています。 外部との通信のため、外部ホストとStargate IPが使用されています。 注意： 1ディスクあたりのセッション数は、1つとなります（PID 24845をご覧ください）。

[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*qemu
Proto ... Local Address       Foreign Address     State       PID/Program name
tcp   ... 192.168.5.1:50410  192.168.5.254:3261   ESTABLISHED 25293/qemu-kvm
tcp   ... 192.168.5.1:50434  192.168.5.254:3261   ESTABLISHED 23198/qemu-kvm
tcp   ... 192.168.5.1:50464  192.168.5.254:3261   ESTABLISHED 24845/qemu-kvm
tcp   ... 192.168.5.1:50465  192.168.5.254:3261   ESTABLISHED 24845/qemu-kvm
...

メインループがシングルスレッドになっていたり、libiscsiがすべてのSCSIコマンドを検査したりするなど、このパスには幾つか非効率な部分が存在します。

Frodo I/Oパス（別名AHV Turbo Mode）

ストレージテクノロジーは、Nutanixと同様に進化を続け、その効率性をさらに高めています。 Nutanix自身の手でAHVやスタックを完全にコントロールできるようになった今こそ、絶好の機会です。

手短に言えば、Frodoはより優れたスループットや低レイテンシーの実現、さらにCPUのオーバーヘッドを減らすため、AHV向けに特別に最適化されたI/Oパスなのです。

VMがI/Oを実行する場合、以下の処理が行われます（理解し易くするため、一部の手順は省略してあります）：

1. VMのOSが仮想デバイスに対してSCSIコマンドを実行
2. Virtio-scsiがリクエストを受け取り、ゲストのメモリに保存
3. Frodoがリクエストを処理
4. カスタムlibiscsiがiscsiヘッダーを付加して転送
5. ネットワーク層がリクエストをローカルCVMに転送（ローカルCVMが利用できない場合は外部のCVM）
6. Stargateがリクエストを処理

以下に、このフローの例を示します：

以下のパスは、いくつかの重要な点を除いて、従来のI/Oと変わりが無いように見えます：

• Qemuのメインループを、Frodo（vhost-user-scsi）に置き換える
• Frodoは複数の仮想キュー (VQ) をゲスト（vCPUあたり1つ）に提供
• マルチスレッドを使用して、複数のvCPU VMに対応
• LibiscsiをNutanix独自のより軽いバージョンに置き換える

パフォーマンスが向上するのみでなく、ゲストからはディスクデバイスに複数のキューが存在しているように見えます。 I/O処理のCPUオーバーヘッドが25％も低下したり、Qemuに比べパフォーマンスが3倍になったりした例もあります！ 他のハイパーバイザーに比べても、I/O処理のCPUオーバーヘッドを最大3倍減らすことができます。

AHVホストを見ると、それぞれのVMに対してfrodoプロセス（qemu-kvmプロセス）が存在することが判ります。

[root@drt-itppc03-1 ~]# ps aux | egrep frodo
... /usr/libexec/qemu-kvm ... -chardev socket,id=frodo0,fd=3 \
  -device vhost-user-scsi-pci,chardev=frodo0,num_queues=16...

... /usr/libexec/frodo ... 127.0.0.1:3261 -t iqn.2010-06.com.nutanix:vmdisk...
...
 

またドメインのXMLがfrodoを使用していることも判ります：

...
<devices>
<emulator>/usr/libexec/frodo</emulator>
...

以下では、ローカルブリッジとIPを使用している正常なStargateを使って、Frodoがセッションを確立しています。外部との通信のため、外部ホストとStargate IPが使用されています。

[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*frodo
Proto ... Local Address       Foreign Address     State       PID/Program name
tcp   ... 192.168.5.1:39568  192.168.5.254:3261   ESTABLISHED 42957/frodo
tcp   ... 192.168.5.1:39538  192.168.5.254:3261   ESTABLISHED 42957/frodo
tcp   ... 192.168.5.1:39580  192.168.5.254:3261   ESTABLISHED 42957/frodo
tcp   ... 192.168.5.1:39592  192.168.5.254:3261   ESTABLISHED 42957/frodo
...

IPアドレスの管理

Acropolis IPアドレス管理 (IPAM) により、DHCPスコープを構成し、VMに自動的にIPアドレスを割り当てることができます。この機能は、VXLANとOpenFlowルールを使用してDHCPリクエストに割り込みを行い、DHCPレスポンスによりレスポンスを返します。

以下は、Acropolisリーダーがローカルで稼動している場合の、Nutanix IPAMを使用したDHCPリクエストのオペレーション例です：

Acropolisリーダーがリモートで稼動している場合には、ネットワークを超えたリクエストを処理するために、同じVXLANトンネルが使用されます。

既存のDHCP / IPAM ソリューションも使用することが可能です。

VMの高可用性 (HA)

AHV VM HAは、ホストやブロックに障害が発生した場合に、VMの可用性を確保するための機能です。 ホストに障害が発生した場合、そのホストで稼動していたVMは、クラスタ内の他の正常なノードに移動し再起動されます。 Acropolisリーダーがこの役割を担っています。

Acropolisリーダーは、クラスタ内全てのホスト上のlibvirtへの接続状況をモニターし、ホストのヘルスチェックを行っています：

libvirtの接続がダウンすると、HAによる再起動へのカウントダウンが開始されます。 libvirtの接続がタイムアウト期間内での再確立に失敗すると、Acropolisは切断されたホストで起動されていたVMを再起動します。 この場合、VMは120秒以内に再起動されるはずです。

Acropolisリーダーが分割された場合、またはネットワーク隔離された場合、さらに、障害が発生した場合には、クラスタ内の正常のノードが新しいAcropolisリーダーとして選定されます。 クラスタが分割された場合（例えば、Xノードが他のYノードに通信不能）には、クォーラムを持った方が動作を継続し、VMはそのノードで再起動されます。

VM HAには主に2つのモードがあります：

• デフォルト (Default)
  • AHVベースのNutanixクラスタをインストールした際に、デフォルトで含まれる設定不要のモードです。 AHVホストが使用できなくなった場合、障害の発生したAHVホストで稼動していたVMは、利用可能なリソースに応じて、残りのホストで再起動されます。 残りのホストに十分なリソースが存在しない場合には、停止したすべてのVMが再起動されるとは限りません。
• 保証 (Guarantee)
  • このモードは、クラスタ全体のAHVホストでスペースを予約しておき、ホストに障害が発生した場合にAHVクラスタの他のノードで、すべての停止したVMを再起動できるようにするものです。 保証モードを有効化する際には「Enable HA（HAを有効化）」チェックボックスを選択します。 予約されたメモリ量と、障害に絶えられるAHVホストの数がメッセージ表示されます。

リソース予約

VM HAを保証 (Guarantee) モードにすると、システムはVMのためにホストのリソースを予約します。 予約されるリソースの量は、以下のように要約することができます：

• 全てのコンテナがRF2 (FT1) の場合
  • 1つの「ホスト」に相当するリソース
• RF3 (FT2) のコンテナが存在する場合
  • 2つの「ホスト」に相当するリソース

ホストのメモリ容量に差がある場合、システムは最大のメモリ容量をもつホストを基準に、ホストあたりの予約量を決定します。

予約セグメントは、クラスタの全てのホスト全体にリソースを分散させます。 この場合それぞれのホストは、HAのために予約されたメモリを共有することになります。 これによって、ホストに障害が発生した場合でも、VMを再起動するための十分なフェイルオーバー容量をクラスタ全体で確保することができます。

以下の図は、予約セグメントの状態を示したものです：

ホストに障害が発生すると、VMはクラスタに残った正常なホストを使って再起動されます。

コマンドリファレンス

OVSで10GbE接続のみを有効化する

説明： ローカルホストのbond0に対してのみ10gを有効化する

manage_ovs --interfaces 10g update_uplinks

説明： クラスタ全体のovsアップリンクを表示

allssh "manage_ovs --interfaces 10g update_uplinks"

OVSアップリンクの表示

説明： ローカルホストのOVSアップリンクを表示

manage_ovs show_uplinks

説明： クラスタ全体のOVSアップリンクを表示

allssh "manage_ovs show_uplinks"

OVSインターフェイスの表示

説明： ローカルホストのOVSインターフェイスを表示

manage_ovs show_interfaces

説明： クラスタ全体のインターフェイスを表示

allssh "manage_ovs show_interfaces"

OVSスイッチ情報を表示

説明： スイッチ情報を表示

ovs-vsctl show

OVSブリッジ一覧

説明： ブリッジ一覧を表示

ovs-vsctl list br

OVSブリッジ情報の表示

説明： OVSポート情報を表示

ovs-vsctl list port br0
ovs-vsctl list port <bond>

OVSインターフェイス情報の表示

説明： インターフェイス情報を表示

ovs-vsctl list interface br0

ブリッジのポート/インターフェイスを表示

説明： ブリッジのポートを表示

ovs-vsctl list-ports br0

説明： ブリッジのインターフェイスを表示

ovs-vsctl list-ifaces br0

OVSブリッジの作成

説明： ブリッジの作成

ovs-vsctl add-br <bridge>

ブリッジにポートを追加

説明： ブリッジにポートを追加

ovs-vsctl add-port <bridge> <port>

説明： ブリッジにボンドポートを追加

ovs-vsctl add-bond <bridge> <port> <iface>

OVSのボンド詳細を表示

説明： ボンド詳細を表示

ovs-appctl bond/show <bond>

例：

ovs-appctl bond/show bond0

ボンドモードを設定してボンドにLACPを構成

説明： ポートのLACPを有効化

ovs-vsctl set port <bond> lacp=<active/passive>

説明： 全ホストのbond0を有効化

for i in `hostips`;do echo $i; ssh $i source /etc/profile > /dev/null 2>&1; ovs-vsctl set port bond0 lacp=active;done

ボンドのLACP詳細を表示

説明： LACPの詳細を表示

ovs-appctl lacp/show <bond>

ボンドモードを設定

説明： ポートにボンドモードを設定

ovs-vsctl set port <bond> bond_mode=<active-backup, balance-slb, balance-tcp>

OpenFlow情報を表示

説明： OVS openflowの詳細を表示

ovs-ofctl show br0

説明： OpenFlowのルールを表示

ovs-ofctl dump-flows br0

QEMU PIDと上位情報を取得

説明： QEMU PIDを取得

ps aux | grep qemu | awk '{print $2}'

説明： 指定したPIDの上位指標値を取得

top -p <PID>

QEMUプロセスに対してアクティブなStargateを取得

説明： 各QEMUプロセスのストレージI/Oに対するアクティブなStargateを獲得

netstat -np | egrep tcp.*qemu

指標値としきい値

近日公開！

トラブルシューティングと高度な管理

iSCSIリダイレクターログの確認

説明： 全ホストのiSCSIリダイレクターログを確認

for i in `hostips`; do echo $i; ssh root@$i cat /var/log/iscsi_redirector;done

単独ホストの例

ssh root@<HOST IP>
cat /var/log/iscsi_redirector

Stolen (Steal) CPUのモニター

説明： CPUのSteal時間（Stolen CPU）をモニター

topを起動して %st（以下ではボールド表示）を探す

Cpu(s):  0.0%us, 0.0%sy,  0.0%ni, 96.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st

VMネットワークリソースのステータスをモニター

説明： VMリソースのステータスをモニター

virt-topを起動

virt-top

ノードアーキテクチャー

ESXiを導入した場合、コントローラーVM (CVM) はVMとして稼動し、ディスクはVMダイレクトパスI/Oを使用するようになります。これによって、PCIコントローラー（および付属デバイス）のパススルーが完全に可能となり、ハイパーバイザーを迂回してCVMに直接繋がるようになります。

最大構成と拡張性

以下の最大構成と拡張制限が適用されます：

• 最大クラスタサイズ：64
• VMあたりの最大vCPU数： 128
• VMあたりの最大メモリ： 4TB
• 最大仮想ディスクサイズ： 62TB
• ホストあたりの最大VM数： 1,024
• クラスタあたりの最大VM数： 8,000（HAが有効な場合、データストアあたり2,048）

注意： vSphere 6.0 時点の情報です。

ネットワーク

各ESXiホストにはローカルvSwitchがあり、Nutanix CVMとホストの、ホスト内部通信に使用されます。 外部やVMとの通信には、標準のvSwitch（デフォルト）またはdvSwitchが使用されます。

ローカルvSwtich（vSWitchNutanix）は、Nutanix CVMとESXiホスト間の通信のためのものです。 ホスト上のこのvSwitchにはVMkernelインターフェイス（vmk1-192.168.5.1）があり、CVMにはこの内部スイッチのポートグループにバインドされるインターフェイス（svm-iscsi-pg - 192.168.5.2）があります。 これが基本的なストレージの通信パスになります。

外部接続するvSwitchは、標準のvSwitch（標準仮想スイッチ）またはdvSwitch（分散仮想スイッチ）です。 これはESXiホストとCVMの外部インターフェイスをホストすると同時に、ホスト上のVMに使用されるポートグループもホストします。 外部のvmkernelインターフェイスは、ホスト管理やvMotionなどに使用されます。 外部CVMインターフェイスは、他のNutanix CVMとの通信に利用されます。 トランク上でVLANが有効になっていれば、必要に応じてポートグループが作成できます。

以下は、vSwitchアーキテクチャーの概念的な構造を図示したものです：

アレイオフロード － VAAI

Nutanixプラットフォームは、VMware API for Array Integration（VAAI）をサポートし、ハイパーバイザーのタスクをアレイにオフロードすることができます。 ハイパーバイザーが「仲介役」を果たす必要がなくなるため、より効率的になります。 現在Nutanixでは、「フルファイルクローン（full file clone）」、「ファストファイルクローン（fast file clone）」および「リザーブスペース（reserve space）」プリミティブを含む、NAS向けVAAIプリミティブをサポートしています。 各種プリミティブの優れた説明がこちらにあります： http://cormachogan.com/2012/11/08/vaai-comparison-block-versus-nas/

フルクローンとファストファイルクローンの場合、DSFの「ファストクローン」が完了すると、 （re-direct on writeを使って）各クローンに対する書き込み可能なスナップショットが生成されます。 各クローンは自身のブロックマップを持っているので、チェーンの深さを気にする必要はありません。 VAAIを使用するか否かは、以下の要素で決まります。

• スナップショットありのVMのクローン → VAAIは使用しない
• スナップショットなしの未稼動のVMのクローン → VAAIを使用
• 異なるデータストア/コンテナに対するVMのクローン → VAAIは使用しない
• 稼動中のVMのクローン → VAAIは使用しない

VMware Viewの場合、次の方針になります：

• View Full Clone（スナップショットありのテンプレート） → VAAIは使用しない
• View Full Clone（スナップショットなしのテンプレート） → VAAIを使用
• View Linked Clone (VCAI) → VAAIを使用

VAAIの動作は、Activity Traceページの「NFS Adapter」を使って確認できます。

CVM AutopathingまたはHa.py

本セクションでは、CVMの「障害」がどのように処理されるかについて説明します（コンポーネントの障害対応については、後日説明を追加します）。 ここではCVMの「障害」とは、ユーザーによるCVMの停止、CVMのローリングアップグレードなど、CVMを停止させる全てのイベントを含みます。 DSFには自動パス切りかえ（autopathing）と呼ばれる機能があり、ローカルCVMが利用不可になった場合、I/Oはクラスタ上の異なるCVMによって透過的に処理されます。 ハイパーバイザーとCVMは、専用のvSwitch（詳細は前述参照）上のプライベートの192.168.5.0ネットワークを使って通信します。 つまり、全てのストレージI/Oは、CVMの内部IPアドレス（192.168.5.2）を使って行われるということです。 CVMの外部IPアドレスは、リモートレプリケーションやCVMの通信に使用されます。

以下にこの状態を図示しました：

ローカルCVMで障害が発生した場合、それまでローカルCVMにホストされていたローカルの192.168.5.2アドレスは使用不可能になります。DSFは自動的にこの障害を検知し、10GbE経由でI/Oをクラスタ内の異なるCVMにリダイレクトします。この経路変更は、そのホストで稼動するハイパーバイザーやVMに対して透過的に行われます。つまり、CVMが停止しても、VMは引き続きDSFにI/Oが可能だということです。ローカルCVMが復旧して利用可能になると、経路は透過的に元にもどされ、トラフィックはローカルCVMから提供されるようになります。

以下は、CVM障害時にどういった動きをするか図示したものです：

仮想マシンの管理

基本的な仮想マシン管理操作は、ハイパーバイザーの管理インターフェイスを使用せずに、Prismから直接実行できます。 NutanixノードをvCenterインスタンスに追加し、vCenterをNutanixクラスタに登録（Settings → vCenter Registration）すると、Prismからダイレクトに次の操作が実行できるようになります：

• 仮想マシンの作成、クローン、設定の編集、削除
• NICの作成、削除
• ディスクの接続、削除
• 仮想マシンの電源操作（パワーオン/パワーオフ、リセット、ゲストシャットダウン、ゲスト再起動、サスペンド）
• 仮想マシン コンソールの開始
• 仮想マシンゲストツールの管理（VMware ToolsまたはNutanix Guest Tools）

コマンドリファレンス

ESXiクラスタ アップグレード

説明： CLIとカスタム オフライン バンドルを使用した、ESXiホストの自動アップグレードを実行

• Nutanix CVMに、アップグレード オフライン バンドルをアップロード
• Nutanix CVMにログイン
• アップグレードを実行

cluster --md5sum=bundle_checksum --bundle=/path/to/<offline_bundle> host_upgrade

例：

cluster --md5sum=bff0b5558ad226ad395f6a4dc2b28597 --bundle=/tmp/VMware-ESXi-5.5.0-1331820-depot.zip host_upgrade

ESXiホストサービスの再起動

説明： 各ESXiホストサービスを順次再起動

for i in `hostips`;do ssh root@$i "services.sh restart";done

ESXiホストの「Up」状態にあるNICを表示

説明： ESXiホストの「Up」状態にあるNICを表示

for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep Up;done

ESXiホストの10GbE NICとそのステータスを表示

説明： ESXiホストの10GbE NICとそのステータスを表示

for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep ixgbe;done

ESXiホストのアクティブなアダプターを表示

説明： ESXiホストのアクティブ、スタンドバイ、未使用状態にあるアダプターを表示

for i in `hostips`;do echo $i &&  ssh root@$i "esxcli network vswitch standard policy failover get --vswitch-name vSwitch0";done

ESXiホストのルーティングテーブルを表示

説明： ESXiホストのルーティングテーブルを表示

for i in `hostips`;do ssh root@$i 'esxcfg-route -l';done

データストアでVAAIが有効化されているかを確認

説明： データストアでVAAIが有効化されているか、サポートされているかを確認

vmkfstools -Ph /vmfs/volumes/<Datastore Name>

VIBの許容レベル（Acceptance Level）をコミュニティサポートに設定

説明： VIBのアクセプタンスレベルをCommunitySupportedに設定し、サードパーティのVIBをインストール可能にする

esxcli software acceptance set --level CommunitySupported

VIBのインストール

説明： 署名確認なしでVIBをインストール

esxcli software vib install --viburl=/<VIB directory>/<VIB name> --no-sig-check

# または

esxcli software vib install --depoturl=/<VIB directory>/<VIB name> --no-sig-check

ESXiのramdiskスペースを確認

説明： ESXi ramdiskの空きスペースを確認

for i in `hostips`;do echo $i; ssh root@$i 'vdf -h';done

pynfsログのクリア

説明： 各ESXiホストのpynfsログをクリア

for i in `hostips`;do echo $i; ssh root@$i '> /pynfs/pynfs.log';done

ノードアーキテクチャー

Hyper-Vを導入した場合、コントローラーVM (CVM) は、VMとして稼動しディスクはディスクパススルーを使用して提供されます。

最大構成と拡張性

以下の最大構成と拡張制限が適用されます：

• 最大クラスタサイズ： 64
• VMあたりの最大vCPU数： 64
• VMあたりの最大メモリ： 1TB
• 最大仮想ディスクサイズ： 64TB
• ホストあたりの最大VM数： 1,024
• クラスタあたりの最大VM数： 8,000

注意： Hyper-V 2012 R2現在

ネットワーク

各Hyper-Vホストには、内部限定の仮想スイッチがあり、Nutanix CVMとホスト間の通信に使用されます。外部やVMとの通信には、外部仮想スイッチ（デフォルト）または論理スイッチが使用されます。

内部スイッチ (InternalSwitch) は、CVMとHyper-Vホスト間のローカル通信のためのものです。ホストは、内部スイッチ (192.168.5.1) 上に仮想イーサネットインターフェイス (vEth) を持ち、CVMは内部スイッチ (192.168.5.2) 上にvEthを持っています。これが基本的な通信パスとなります。

外部vSwitchは、標準的な仮想スイッチまたは論理スイッチでかまいません。外部vSwitchは、Hyper-VホストとCVMに加え、ホスト上のVMに使用される論理およびVMネットワークのためのインターフェイスをホストします。外部vEthインターフェイスはホスト管理、ライブマイグレーションなどに用いられます。外部CVMインターフェイスは、他のNutanix CVMとの通信に使用されます。トランク上でVLANが有効になっていれば、論理およびVMネットワークはいくつでも作成することができます。

以下は、仮想スイッチアーキテクチャーの概念的な構造を図示したものです：

アレイオフロード – ODX

Nutanixプラットフォームは、Microsoft Offloaded Data Transfers（ODX）をサポートし、ハイパーバイザーのタスクをアレイにオフロードすることができます。 ハイパーバイザーが「仲介役」を果たす必要がなくなるため、より効率的になります。 現在Nutanixは、フルコピー（full copy）やゼロイング（zeroing）とSMBのためのプリミティブをサポートしています。 しかし、「ファストファイル (fast file)」クローン処理（書き込み可能なスナップショットを使用）が可能なVAAIとは異なり、ODXにはフルコピーを行うための同等なプリミティブが存在しません。 このため、現在nCLI、RESTまたはPowerShellコマンドレットから起動できるDSFクローン機能を利用する方がより効果的です。 現在のところ、ODXは以下の処理に使用されます。：

• DSF SMBシェア上でのVM内のまたはVMからVMへのファイルコピー
• SMBシェアファイルコピー

SCVMMライブラリ（DSF SMBシェア）からテンプレート導入 － 注意： シェアは、ショートネーム（つまりFQDNではない）を使用して、SCVMMクラスタに追加する必要があります。 これを簡単に行うには、クラスタのhostsファイル（つまり10.10.10.10 nutanix-130）にエントリーを追加します。

ODXは以下の処理には使用できません：

• SCVMMによるVMのクローン
• SCVMMライブラリ（非DSF SMBシェア）からテンプレート導入
• XenDesktopクローンの導入

ODXの稼動状態は、Activity Traceページの「NFS Adapter」を使って確認できます（SMB経由で実行されますが、NFSです）。 vDiskのコピー状態は「NfsWorkerVaaiCopyDataOp」、ディスクのゼロイング（zeroing）状態は「NfsWorkerVaaiWriteZerosOp」で表示されます。

重要なページ

近日公開！

コマンドリファレンス

複数のリモートホストでコマンドを実行

説明： 特定のまたは複数のリモートホストで PowerShellを実行

$targetServers = "Host1","Host2","Etc"
Invoke-Command -ComputerName  $targetServers {
         <COMMAND or SCRIPT BLOCK>
}

使用可能なVMQオフロードを確認

説明： 指定したホストで使用可能なVMQオフロードの数を表示

gwmi -Namespace "root\virtualization\v2" -Class Msvm_VirtualEthernetSwitch | select elementname, MaxVMQOffloads

特定のプリフィックスに一致するVMのVMQを無効化

説明： 特定のVMに対するVMQを無効化

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 0

特定のプリフィックスに一致するVMのVMQを有効化

説明： 特定のVMに対するVMQを有効化

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 1

特定のプリフィックスに一致するVMを起動

説明： 特定のプリフィックスに一致するVMを起動

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Stopped"} | Start-VM

特定のプリフィックスに一致するVMをシャットダウン

特定のプリフィックスに一致するVMをシャットダウン

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Running"}} | Shutdown-VM -RunAsynchronously

特定のプリフィックスに一致するVMを停止

特定のプリフィックスに一致するVMを停止

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Stop-VM

Hyper-VホストRSSの設定の確認

説明： Hyper-VホストRSS (Receive Side Scaling) の設定の確認

Get-NetAdapterRss

WinshとWinRMのコネクティビティの確認

説明： WinshとWinRMのコネクティビティおよびステータスを、サンプルクエリを発行して確認。コンピューターシステムオブジェクトを返さない場合はエラーと判断。

allssh 'winsh "get-wmiobject win32_computersystem"'

指標値としきい値

近日公開！