メインフレーム時代

長年に渡りメインフレームは、世の中を支配し今日のシステムの中核的な基礎を築いていきました。多くの企業は主にメインフレームの次のような特性を活かすことができました：

• 生来的に統合されたCPU、メインメモリとストレージ
• 内部冗長性を持った設計

一方でまた、次のような問題も発生しています：

• 多額のインフラストラクチャー導入費用
• 固有の複雑性
• 柔軟性に欠けた、著しくサイロ化された環境

スタンドアローンサーバーへの移行

一部のユーザーは、メインフレームでは実現することができない数々の特徴を持つピザボックス型やスタンドアローン型のサーバーへと移行しました。スタンドアローンサーバーの主な特徴は：

• CPU、メインメモリ、DASストレージで構成
• メインフレームに比べ高い柔軟性
• ネットワーク越しのアクセスが可能

しかし、これらのスタンドアローンサーバーでは次のような問題が発生しました：

• サイロが増加
• 低い、またはバランスの悪いリソース利用率
• コンピュート(計算資源)とストレージの両方にとって、サーバーが単一障害点 (SPOF) になる

集中型ストレージ

ビジネスでは常に利益を生み出す必要があり、データはその重要な要素となります。直結ストレージ (DAS) を使用する場合、実際に使用する以上の容量が必要となり、またサーバー障害によってデータアクセス出来なくならないよう、データの高可用性 (HA) 対策が必要でした。

集中型ストレージは、メインフレームとスタンドアローンサーバーを共有可能な大規模なストレージプールで置き換え、同時にデータ保護機能も提供しました。集中型ストレージの主な特徴は：

• ストレージリソースをプールすることでストレージの使用率を向上
• RAIDによる集中データ保護でサーバー障害によるデータの損失発生を回避
• ネットワーク越しのストレージ処理を実現

集中型ストレージにおける問題点：

• 潜在的によりコストが高い。しかしデータはハードウェアよりもさらに価値がある
• 複雑性の増加（SANファブリック、WWPN、RAIDグループ、ボリューム管理、スピンドルカウントなど）
• 管理ツールや管理チームが別途必要

仮想化の登場

この時点では、サーバーの使用率は低く、リソース効率性が収益に影響を与えていました。そこに仮想化技術が登場し、1台のハードウェア上で複数のアプリケーションやオペレーティングシステム (OS) を仮想マシン (VM) として稼動させることができるようになりました。仮想化は、ピザボックスの使用率を向上させましたが、さらにサイロの数を増やし、機能停止が与える影響を増加させる結果となりました。仮想化の主な特徴は：

• ハードウェアからOSを抽象化 (VM)
• ワークロードを統合できるためサーバーの使用効率が非常に高い

仮想化の問題点：

• サイロの数が増え管理が複雑化
• (初期の仮想化では)VMの高可用性(HA)機能がないため、サーバーノードの障害がより大きな影響を及ぼす
• プールリソースの欠如
• 管理ツールや管理チームが別途必要

仮想化の成熟

ハイパーバイザーは、その効率が向上し機能も充実してきました。VMware vMotionやHA、DRといったツールの出現により、ユーザーは、VMの高可用性を手に入れることができるようになり、サーバーワークロードを動的に移行できるようになりました。しかし、1点注意しなければならないのは、集中型ストレージに対する依存性によって競合が発生することです。つまり、これまで以上のストレージアレイ負荷の増加と不要なVMの乱造がストレージI/Oの競合を招いているのです。主な特徴は：

• クラスタリングによるサーバーリソースのプール
• サーバーノード間で動的にワークロードを移行することが可能 (DRS / vMotion)
• サーバーノード障害に対するVM高可用性 (HA) の提供
• 集中型ストレージが不可欠

問題点：

• VMの乱造による更に大規模なストレージ容量の要求
• ストレージアレイの拡張要求によってサイロの数や複雑性が増加
• Higher $ / GB due to requirement of an array
• ストレージアレイによって1GBあたりの単価が増加
• ストレージアレイ上でリソースが競合する可能性
• 安全性確保のためストレージ構成がより一層複雑に：
  • VMのデータストア / LUN比率
  • I/O要求に対応するためのスピンドル数

ソリッドステートディスク (SSD)

SSDはI/Oのボトルネックを軽減します。より高いI/Oパフォーマンスを提供しますし、大量のディスク筐体も必要ありません。確かにパフォーマンスは非常に優れていますが、コントローラやネットワークは、その膨大なI/O処理に追い着いていません。SSDの主な特徴は：

• 従来のHDDに比べはるかに高速なI/O特性
• 基本的にシークタイムなし

SSDの問題点：

• ボトルネックがディスクのストレージI/Oからコントローラ/ネットワークに移動
• 依然としてサイロは残る
• ディスクアレイ構成の複雑さはそのまま

転送量について

従来のストレージの場合、I/Oのための主要なメディアタイプが幾つかあります：

• ファイバーチャネル (FC)
  • 4-、8- および 10-Gb
• イーサネット（FCoEを含む）
  • 1-、10-Gb、(40-Gb IB) など

以下の計算には、Intel S3700のRead 500MB/s、Write 460MB/sのバンド幅を使用します。

計算式は次の通りです：

numSSD = ROUNDUP((numConnections * connBW (in GB/s))/ ssdBW (R or W))

注意：  SSDを半端な区切りでは利用できないので、端数は切り上げ (ROUNDUP) しています。また、全てのI/Oの処理に必要なCPUが十分にあるものとし、また、コントローラCPUの能力も十分なものと想定しています。

この表に示したように、SSDの最大論理パフォーマンスを得ようとすると、ネットワークのタイプによって、1～9つのSSDいずれでもネットワークがボトルネックとなる可能性があります。

メモリレイテンシに対する影響

一般的にメインメモリのレイテンシは ～100ns (幅がある) なので、以下のように計算できます。

• ローカルメモリのReadレイテンシ = 100ns + [OS / ハイパーバイザーのオーバーヘッド]
• ネットワークメモリのReadレイテンシ = 100ns + ネットワーク・ラウンドトリップ (NW RTT) レイテンシ + [OS / ハイパーバイザーのオーバーヘッド x 2 ]

一般的なネットワークRTTを～0.5ms（スイッチベンダーにより異なる）、つまり～500,000nsと仮定すると：

• ネットワークメモリReadレイテンシ = 100ns + 500,000ns + [OS / ハイパーバイザーオーバーヘッド x 2]

非常に高速なネットワークで、RTTが10,000nsと理論的に仮定すると：

• ネットワークメモリReadレイテンシ = 100ns + 10,000ns + [OS / ハイパーバイザーオーバーヘッド x 2]

つまり、どんなに理論的に高速なネットワークであっても、ネットワークを介さないメモリアクセスに比べ、10,000％のオーバーヘッドがかかるということです。低速なネットワークなら、レイテンシオーバーヘッドは、500,000％にも達することでしょう。

このオーバーヘッドを軽減するために登場したのが、サーバーサイドでのキャッシュテクノロジーです。

ハイバーコンバージェンス

ハイパーコンバージェンスとは何か？という点については、複数の異なる見解が存在します。対象とするコンポーネント（例えば、仮想化、ネットワークなど）によっても異なります。しかし、中心となる概念は、「2つ以上のコンポーネントをネイティブに1つのユニットに統合すること」にあります。「ネイティブに」という点が重要となります。最大の効率を発揮するためには、該当コンポーネントは、単にひとまとめにする (bundle) だけではなく、ネイティブに統合される必要があります。Nutanixの場合、サーバーとストレージを1つのノードとしてアプライアンスとして統合しています。他のベンダーの場合には、ストレージとネットワークの統合という形態であったりします。ハイパーコンバージェンスとは、つまり：

• 2つ以上のコンポーネントを1つのユニットにネイティブに統合し、容易な拡張を可能にすること

メリットとしては：

• ユニット単位で拡張可能
• ローカルでI/Oが完了
• サーバーとストレージを統合することで、従来のようなサイロ化を避けることができる

ソフトウェアデファインド・インテリジェンス

ソフトウェアデファインド・インテリジェンスとは、プロプライエタリなハードウェア、あるいは特殊なハードウェア（例えばASIC やFPGA）のコアなロジックを抽出し、それをソフトウェアとしてコモディティハードウェア上で実装するものです。Nutanixの場合、従来のストレージロジック（例えばRAID、重複排除、圧縮機能など）を抽出し、標準的なx86ハードウェアで構成するNutanix CVM上のソフトウェアとして稼動させています。ソフトウェアデファインド・インテリジェンスとは、つまり：

• ハードウェアから主要なロジックを取り出し、コモディティハードウェア上でソフトウェアとして稼動させること

メリットとしては：

• 迅速なリリースサイクル
• プロプライエタリなハードウェアへの依存から脱却
• 経済効率のよいコモディティハードウェアの利用

自律分散システム

自律分散システム (Distributed Autonomous System) は、特定のユニットがある処理に対応するという従来の概念を払拭し、その役割をクラスタ内の全てのノードで分散して受け持つというものです。これこそが本当の分散システムです。これまでベンダーは、ハードウェアは信頼性に足るものだと仮定し、ほとんどの場合それは正解でした。しかし、分散システムでは、いずれハードウェアは障害を起こすものと想定し、それに的確かつ停止なく対処できるということが重要だと考えます。

これらの分散システムは、障害への対応と修正が行なえるようデザインされており、自己修復あるいは自律的な回復が図られるようになっています。コンポーネントに障害が発生すると、システムはユーザーに意識させることなく障害を処理・修復し、想定通りに運用を継続します。ユーザーはアラートによって障害に気付きますが、急を要するものでない限り、アドミニストレータのスケジュールに沿って修復（例えば障害ノードの交換）を行うことができます。別の方法として、障害を置き換える（交換せずに再構築する）方法もあります。「マスター」に障害が発生した場合、新しいマスター選定プロセスが働き、該当する対象に割り当てられます。処理の分散については、MapReduceの概念が用いられます。つまり:

• 役割や責任をシステム内の全ノードに分散する
• タスクの分散処理に、MapReduceのような概念を採用する
• 「マスター」が必要な場合、選定プロセスを使用する

メリットとしては：

• 単一障害点 (SPOF) を排除
• ワークロードの分散によりボトルネックを排除

インクリメンタルかつリニアな拡張

インクリメンタル（漸増的）かつリニア（線形的）な拡張とは、当初は限定的なリソースからシステムを開始し、必要に応じてパフォーマンスをリニアに拡張していくことを意味します。この拡張性の実現には、前述した要素が全て不可欠となります。従来、仮想ワークロードを処理するためには、サーバー、ストレージ、ネットワークという3階層のコンポーネントが必要で、それぞれは個別に拡張する必要がありました。例えば、サーバー数を拡大しても、ストレージのパフォーマンスも拡張されるわけではありません。Nutanixのようなハイパーコンバージドプラットフォームでは、ノードを拡張すると同時に、以下の要素も拡張されます：

• ハイパーバイザーおよびサーバーノード数
• ストレージコントローラ数
• サーバーおよびストレージのパフォーマンスと容量
• クラスタ処理全体に参加させるノード数

つまり：

• ストレージとサーバーのパフォーマンスと能力を、インクリメンタルかつリニアに拡張することが可能

メリットとしては：

• スモールスタートから拡張が可能
• 規模によらず一律で堅実なパフォーマンスを実現

Prism Central

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

• ホーム (Home) ページ
  • サービスのステータス、キャパシティプラニング、パフォーマンス、タスクなどに関する詳細情報を含む、環境全体をモニターするためのダッシュボード。詳細な情報を取得するには、対象となる項目をクリックします。
• 調査 (Explore) ページ
  • サービス、クラスタ、VMおよびホストの管理とモニタリング
• 分析 (Analysis) ページ
  • クラスタおよび管理下のオブジェクトに対するイベントの相関関係を含む詳細なパフォーマンス分析
• アラート
  • 環境全体のアラート

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

ここから環境の概況をモニターして、アラートが上がっている、あるいは関心のある項目を詳細に調査することができます。

Prism Element

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ホストを選択すると、追加するノードで使用するハイパーバイザーイメージをアップグレードするよう促されます：

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

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

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

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

キャパシティプラニング

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

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

ACLI

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

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

ACLIシェルの起動

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

Acli

または

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

ACLI <Command>

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

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

Acli –o json

ホスト一覧

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

host.list

ネットワークの作成

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

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

Example: 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はリザーブされており、Acropolis DHCPサーバーのアドレスが、ネットワーク作成中に設定されなかった場合に、Acropolis DHCPによって使用されます。

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

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

説明： ネットワークのプロパティを取得

net.get <NET NAME>

Example: net.get vlan.133

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

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

net.list_vms <NET NAME>

Example: net.list_vms vlan.133

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

説明： DHCP DNSの設定

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

Example: 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>

Example: 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>

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

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

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

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

Example: vm.clone testClone clone_from_vm=MYBASEVM

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

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

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

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

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

# Description: Create disk for OS

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

class="codetext"Example: vm.disk_create testVM create_size=500G container=default

VMにNICを追加

説明： NICを作成して追加

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

Example: vm.nic_create testVM network=vlan.100

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

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

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

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

Example: vm.update_boot_device testVM disk_addr=scsi.0

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

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

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

Example: 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

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

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

vm.disk_update <VM NAME> <CDROM BUS> clone_nfs_file<PATH TO ISO>

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

CD-ROMからISOをデタッチ

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

vm.disk_update <VM NAME> <CDROM BUS> empty=true

VMの起動

説明： VMを起動する

vm.on <VM NAME(S)>

Example: vm.on testVM

全てのVMを起動

Example: vm.on *

一定範囲のVMを起動

Example: vm.on testVM[01..99]

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>

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

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

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>

PowerShell コマンドレット

以下でPowerShell コマンドレットの使用方法および前提を解説し、前提となるWindows PowerShellについても少しだけ触れます。

基本

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

コマンドレット

コマンドレットは、特定の処理を行うためのコマンドまたは .NETのクラスです。ほとんどの場合、Getter/Setterメッソドに従い、また通常 - という構文を使用します。例えば、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>

Example: Get-Help Get-Process

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

<Some expression or object> | Get-Member

Example: $someObject | Get-Member

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

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

Nutanix Snappinのロード

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

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

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

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

Acropolisクラスタに接続

Connect-NutanixCluster -Server $server -UserName "myuser" -Password "myuser" -AcceptInvalidSSLCerts

または、ユーザーにパスワードを求めるセキュアな方法

Connect-NutanixCluster -Server $server -UserName "myuser" -Password (Read-Host "Password: ") -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

OpenStack

OpenStackは、クラウドを構築・管理するためのオープンソースプラットフォームです。OpenStackは、大きくフロントエンド（ダッシュボードとAPI）とインフラストラクチャーサービス（サーバー、ストレージなど）に分けることができます。

OpenStackおよびNutanixソリューションは、いくつかの主要なコンポーネントで構成されています：

• OpenStackコントローラ（OSC）
  • 既存または新規に作成された、OpenStack UI、APIおよびサービスをホスティングするVMまたはホスト。全てのOpenStack APIコールを処理します。Acropolis OVMでは、Acropolis OpenStackドライバーと同じ場所に配置できます。
• Acropolis OpenStackドライバー
  • OpenStackコントローラからのOpenStack RPCを処理し、ネイティブなAcropolis APIコールに変換します。ドライバーは、OpenStackコントローラ、OVM（プリインストール）または新規VM上に展開できます。
• Acropolis OpenStackサービスVM（OVM）
  • OpenStackコントローラからのOpenStack RPCを処理し、ネイティブなAcropolis APIコールに変換するためのAcropolisドライバーを持つVM。

OpenStackコントローラは、既存のVMまたはホストであっても、NutanixソリューションのOpenStackの一部として導入することができます。Acropolis OVMは、Nutanix OpenStackソリューションの一部として導入されたヘルパーVMです。

クライアントは、適切なメソッド（Web UI、HTTP、SDK、CLIまたはAPI）を使ってOpenStackコントローラと通信し、OpenStackコントローラはAcropolis OVMと通信して、OpenStackドライバーを使って該当リクエストをネイティブなAcropolis REST APIコールに変換します。

以下に通信の概要を図示します：

以下の表は、それぞれの役割の概要を示したものです：

OpenStackコンポーネント

OpenStackは、様々なインフラストラクチャー機能を提供するための一連のコンポーネントで構成されています。これらの機能の中には、OpenStackコントローラがホストしているものや、Acropolis OVMがホストしているものがあります。

以下の表は、主要なOpenStackコンポーネントとその役割を示したものです：

コンポーネント	役割	OpenStack コントローラ	Acropolis OVM
Keystone	IDサービス	X
Horizon	ダッシュボードおよびUI	X
Nova	処理		X
Swift	オブジェクトストレージ	X	X
Cinder	ブロックストレージ		X
Glance	イメージサービス	X	X
Neutron	ネットワーキング		X
Heat	オーケストレーション	X
その他	その他全てのコンポーネント	X

以下の図は、OpenStackコンポーネントとコミュニケーションに関する詳細を示しています：

以下のセクションでは、主要なOpenStackコンポーネントとNutanixプラットフォームの連携方法について説明します。

Nova

Novaは、OpenStackプラットフォームの処理エンジンであり同時にスケジューラです。Nutanix OpenStackソリューションでは、各Acropolis OVMが処理ホストとして機能し、Acropolisクラスタは、OpenStackインスタンスをスケジュールするための1つのハイパーバイザーホストとして機能します。Acropolis OVMは、Nova処理サービスを実行します。

Novaサービスは、OpenStackポータルの 'Admin'->'System'->'System Information'->'Compute Services' から確認できます。

以下にNovaサービス、ホストおよびステータスを図示します：

設計と導入

クラウド環境で大規模な導入を行う場合には、分散型でエンドユーザーの要件を満たしつつ、柔軟でローカリティのあるトポロジーを採用することが重要となります。

OpenStackでは、次のような構成を採用しています。

• リージョン (Region)
  • 地理的なまとまり、あるいは複数のアベイラビリティゾーン（サイト）が存在するエリアを指します。例えば、米国北西部や米国西部などがこれに該当します。
• アベイラビリティゾーン（AZ – Availability Zone）
  • クラウドサービスがホストされている特定のサイト、またはデータセンターの場所。例えば、米国北西部-1や米国西部-1などがこれに該当します。
• ホスト統合（Host Aggregate）
  • サーバーホストのグループ。ホストの横または縦の列、あるいはサイト/AZと同様です。
• 処理ホスト（Compute Host）
  • Nova処理サービスを実行しているAcropolis OVM
• ハイパーバイザーホスト (Hypervisor Host)
  • Acropolisクラスタ（単体のホストとして見える）

以下に、構成の概要を図示します：

以下に、アプリケーションの構成例を図示します：

ホストのビューや管理、ホストの統合、アベイラビリティゾーンは、OpenStackポータルの 'Admin'->'System'->'Host Aggregates' から確認できます。

以下の図は、ホスト統合、アベイラビリティゾーンとホストについて解説したものです：

サービス設計と拡張

大規模な導入の場合、複数のAcropolis OVMを、ロードバランサーで抽象化されたOpenStackコントローラに接続することを推奨します。これにより、OVM自身も含め高可用性（HA）が実現できると共に、トランザクションの分散が可能になります。OVM自体は、拡張に必要なステータス情報を持っていません。

以下は、単体サイトにおけるOVMの拡張例を図示したものです：

OVMによってこれを実現する方法の１つとして、KeepalivedおよびHAproxyの使用があります。

環境が複数のサイトにまたがる場合、OpenStackコントローラは、サイト間に存在する複数のAcropolis OVMと通信します。

以下は、複数サイトに対する導入例を図示したものです：

導入

OVMは、CentOS / Redhatディストリビューション上にスタンドアローンRPMとして、または完全なVMとして導入することができます。Acropolis OVMは、OpenStackコントローラおよびNutanixクラスタに対するネットワークコネクティビティがあれば、（Nutanixか否かを問わず）どんなプラットフォーム上にでも導入することが可能です。

Acropolis OVMのVMは、以降に示す手順でNutanix AHVクラスタに導入することができます。もしOVMが既に導入済みの場合、VM生成手順を省くことができます。完全なOVMイメージまたは、既存のCentOS / Redhat VM イメージを利用することが可能です。

最初に、提供されたAcropolis OVMのディスクイメージをAcropolisクラスタにインポートします。ディスクイメージのコピーについては、SCPを使うか、またはコピー元のURLを指定することが可能です。注意： このVMはどんな場所にでも導入できます。必ずしもAcropolisクラスタである必要はありません。

Images APIを使用してディスクイメージをインポートする際には、次のコマンドを実行します：

image.create <IMAGE_NAME> source_url=<SOURCE_URL> container=<CONTAINER_NAME>

次に、以下のACLIコマンドをいずれかのCVMで実行して、OVMのためのAcropolis VMを作成します。

vm.create <VM_NAME> num_vcpus=2 memory=16G
vm.disk_create <VM_NAME> clone_from_image=<IMAGE_NAME>
vm.nic_create <VM_NAME> network=<NETWORK_NAME>
vm.on <VM_NAME>

VMが生成され起動されると、指定された認証情報を使用してOVMでSSHが実行されます。

Note

OVMCTL ヘルプ

ヘルプテキストはOVM上で以下のコマンドを実行することにより表示されます:

ovmctl --help

OVMは２つのデプロイモードをサポートします:

• OVM-allinone
  • OVM はすべての Acropolis ドライバーとOpenStack コントローラを含みます
• OVM-services
  • OVM はすべての Acropolis ドライバーを含み、外部、リモートのOpenStack コントローラーと通信します

以下のセクションで、これら２つのデプロイモードについて説明します。どちらのモードも選択いただくことは可能です。またモードを切り替えることも可能です

OVM-allinone

OVM-allinoneのデプロイ手順を説明します。まず、OVM(s)にSSHで入り、以下のコマンドを実行します

# Register OpenStack Driver service
ovmctl --add ovm --name <OVM_NAME> --ip <OVM_IP>

# Register OpenStack Controller
ovmctl --add controller --name <OVM_NAME> --ip <OVM_IP>

# Register Acropolis Cluster(s) (run for each cluster to add)
ovmctl --add cluster --name <CLUSTER_NAME> --ip <CLUSTER_IP> --username <PRISM_USER> --password <PRISM_PASSWORD>

The following values are used as defaults:
Number of VCPUs per core = 4
Container name = default
Image cache = disabled, Image cache URL = None

次に以下のコマンドで構成を確認します:

ovmctl --show

この時点ですべて動作しているはずです。エンジョイ！

OVM-services

OVM-servicesのデプロイ手順を説明します。まず、OVM(s)にSSHで入り、以下のコマンドを実行します

# Register OpenStack Driver service
ovmctl --add ovm --name <OVM_NAME> --ip <OVM_IP>

# Register OpenStack Controller
ovmctl --add controller --name <OS_CONTROLLER_NAME> --ip <OS_CONTROLLER_IP> --username <OS_CONTROLLER_USERNAME> --password <OS_CONTROLLER_PASSWORD>

The following values are used as defaults:
Authentication: auth_strategy = keystone, auth_region = RegionOne
auth_tenant = services, auth_password = admin
Database: db_{nova,cinder,glance,neutron} = mysql, db_{nova,cinder,glance,neutron}_password = admin
RPC: rpc_backend = rabbit, rpc_username = guest, rpc_password = guest

# Register Acropolis Cluster(s) (run for each cluster to add)
ovmctl --add cluster --name <CLUSTER_NAME> --ip <CLUSTER_IP> --username <PRISM_USER> --password <PRISM_PASSWORD>

The following values are used as defaults:
Number of VCPUs per core = 4
Container name = default
Image cache = disabled, Image cache URL = None

もしOpenStackコントローラにデフォルト外のパスワードが設定されているならば、アップデートする必要があります:

# Update controller passwords (if non-default are used)
ovmctl --update controller --name <OS_CONTROLLER_NAME> --auth_nova_password <> --auth_glance_password <> --auth_neutron_password <> --auth_cinder_password <> --db_nova_password <> --db_glance_password <> --db_neutron_password <> --db_cinder_password <>

次に以下のコマンドで構成を確認します:

ovmctl --show

これでOVMがコンフィグされたので、次にOpenStack コントローラがGlanceとNeutronエンドポイントが認識できるように設定します

OpenStack コントローラーにログインし、keystonerc_admin sourceを入力します:

# enter keystonerc_admin source ./keystonerc_admin

最初にコントローラーをポイントしているGlanceのエンドポイントを削除します:

# Find old Glance endpoint id (port 9292) keystone endpoint-list # Remove old keystone endpoint for Glance
keystone endpoint-delete <GLANCE_ENDPOINT_ID>

次に新しいGlanceエンドポイントを作成しOVMをポイントするようにします

# Find Glance service id
keystone service-list | grep glance
# Will look similar to the following:
| 9e539e8dee264dd9a086677427434982 | glance | image |

# Add Keystone endpoint for Glance
keystone endpoint-create \
--service-id <GLANCE_SERVICE_ID> \
--publicurl http://<OVM_IP>:9292 \
--internalurl http://<OVM_IP>:9292 \
--region <REGION_NAME> \
--adminurl http://<OVM_IP>:9292

次にコントローラをポイントしているNeutronエンドポイントを削除します:

# Find old Neutron endpoint id (port 9696) keystone endpoint-list # Remove old keystone endpoint for Neutron
keystone endpoint-delete <NEUTRON_ENDPOINT_ID>

次にOVMをポイントする新しいGlanceエンドポイントを作ります

# Find Glance service id
keystone service-list | grep glance
# Will look similar to the following:
| f4c4266142c742a78b330f8bafe5e49e | neutron | network |

# Add Keystone endpoint for Neutron
keystone endpoint-create \
--service-id <NEUTRON_SERVICE_ID> \
--publicurl http://<OVM_IP>:9696 \
--internalurl http://<OVM_IP>:9696 \
--region <REGION_NAME> \
--adminurl http://<OVM_IP>:9696

エンドポイントの作成が終われば、NovaとCinderのコンフィグレーションファイルをGlanceホストのAcropolis OVM IPにアップデートします

最初に/etc/nova/nova.confにあるNova.confを以下のように編集します:

[glance]
...
# Default glance hostname or IP address (string value)
host=<OVM_IP>

# Default glance port (integer value)
port=9292
...
# A list of the glance api servers available to nova. Prefix
# with https:// for ssl-based glance api servers.
# ([hostname|ip]:port) (list value)
api_servers=<OVM_IP>:9292

OpenStackコントローラのnova-computeを無効にします(まだ無効でなければ):

systemctl disable openstack-nova-compute.service
systemctl stop openstack-nova-compute.service
service openstack-nova-compute stop

/etc/cinder/cinder.confにあるCider.confを以下のように編集します:

# Default glance host name or IP (string value)
glance_host=<OVM_IP>
# Default glance port (integer value)
glance_port=9292
# A list of the glance API servers available to cinder
# ([hostname|ip]:port) (list value)
glance_api_servers=$glance_host:$glance_port

さらに、使用しないので、イネーブルなlvmバックエンドをコメントアウトします:

# Comment out the following lines in cinder.conf
#enabled_backends=lvm
#[lvm]
#iscsi_helper=lioadm
#volume_group=cinder-volumes
#iscsi_ip_address=
#volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver
#volumes_dir=/var/lib/cinder/volumes
#iscsi_protocol=iscsi
#volume_backend_name=lvm

OpenStackコントローラのcider ボリュームを無効にします(無効化されていない場合):

systemctl disable openstack-cinder-volume.service
systemctl stop openstack-cinder-volume.service
service openstack-cinder-volume stop

OpenStackコントローラのglance-imageを無効にします:

systemctl disable openstack-glance-api.service
systemctl disable openstack-glance-registry.service
systemctl stop openstack-glance-api.service
systemctl stop openstack-glance-registry.service
service openstack-glance-api stop
service openstack-glance-registry stop

これらのファイルの編集が終了後、Nova Ciderサービスを再起動し、新しいコンフィグレーションを読み込みます。再起動は以下のコマンドで行います。または、ダウンロード可能なスクリプトを起動することでも可能です

# Restart Nova services
service openstack-nova-api restart
service openstack-nova-consoleauth restart
service openstack-nova-scheduler restart
service openstack-nova-conductor restart
service openstack-nova-cert restart
service openstack-nova-novncproxy restart

# OR you can also use the script which can be downloaded as part of the helper tools:
~/openstack/commands/nova-restart

# Restart Cinder
service openstack-cinder-api restart
service openstack-cinder-scheduler restart
service openstack-cinder-backup restart

# OR you can also use the script which can be downloaded as part of the helper tools:
~/openstack/commands/cinder-restart

コンバージド プラットフォーム

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

Nutanixのソリューションは、どこでも手に入るストレージとサーバーを統合し、仮想化のための分散プラットフォーム（Virtual Computing Platform）として構成したものです。本ソリューションでは、ハードウェアとソフトウェアをバンドルし、2ノード（6000と7000シリーズ）または4ノード（1000、2000、3000および3500シリーズ）を２Uサイズに格納しています。

それぞれのノードで、業界の標準的なハイパーバイザー（現在はESXi、KVM、Hyper-V）およびNutanixコントローラVM（CVM）を稼動させることができます。Nutanix CVMは、Nutanixソフトウェアを稼動させ、ハイパーバイザーおよびその上で稼動する全てのVMに対するI/O処理の全てを受け持ちます。VMware vSphereが稼動するNutanixのユニットの、SSDとHDDデバイスを管理するSCSIコントローラは、VM-Direct Path（Intel VT-d）を利用して、CVMに直接パスされます。Hyper-Vの場合、ストレージ デバイスは、CVMにパススルーされます。

以下は、典型的なノードの論理構成例を図示したものです：

ソフトウェア・デファインド

既に何度か説明した通り、Nutanixプラットフォームは、ソフトウェアベースのソリューションであり、ソフトウェアとハードウェアをバンドルしたアプライアンスとして出荷されます。コントローラVMには、Nutanixソフトウェアとロジックの大半が組み込まれており、当初から拡張性を持つプラガブルなアーキテクチャーとして設計されたものです。ソフトウェア・デファインドとしてハードウェアの構成に依存しないメリットは、その拡張性にあります。製品を既に使用中の場合でも、拡張機能や新機能をいつでも取り入れることができます。

Nutanixは、カスタム仕様のASICやFPGA、またはハードウェア機能に依存しないことで、単にソフトウェア アップデートのみで新しい機能を開発・展開することができます。これは、データ重複排除などの新機能をNutanixソフトウェアのバージョンをアップグレードすることにより展開できることを意味します。また、レガシーなハードウェア モデルに対しても、新しい機能の導入を可能にします。例えば、Nutanixソフトウェアの古いバージョンと、前世代のハードウェア プラットフォーム（例えば2400）でワークロードを稼動させていたと仮定します。稼動中のソフトウェアバージョンでは、データ重複排除機能を提供しないため、ワークロードはその恩恵にあずかることができません。このデータ重複排除機能は、ワークロードが稼動中であっても、Nutanixソフトウェアのバージョンをローリング アップグレードすることで利用可能です。これは非常に簡単な作業です。

このような機能と同様に、新しい「アダプタ」あるいはインターフェースをDSFに向け作成できることも、非常に重要な性能です。製品が出荷された当初、サポートはハイパーバイザーからのI/Oに対するiSCSIに限定されていましたが、現在では、NFSとSMBもその対象になっています。将来的には、新しいアダプタを様々なワークロードやハイパーバイザー（HDFSなど）に向けて作成できるようになるでしょう。繰り返しますが、これらの対応は全てソフトウェアのアップデートで完了します。「最新の機能」を入手するために、ハードウェアを更改したりソフトウェアを購入したりする必要がある多くのレガシーなインフラストラクチャーとは対照的に、Nutanixではその必要がありません。全ての機能がソフトウェアで実装されているため、ハードウェア プラットフォームやハイパーバイザーを問わずに稼動させることが可能で、ソフトウェア アップグレードによって新たな機能を実装することができます。

以下は、ソフトウェア・デファインド・コントローラ フレームワークの論理的な構成を図示したものです：

クラスタ コンポーネント

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

Nutanixプラットフォームは、以下に示すコンポーネントで構成されています：

Cassandra

• 主な役割： 分散メタデータ ストア
• 説明： Cassandraは、Apache Cassandraを大幅に改修した分散リング上に全てのクラスタ メタデータをストアして管理を行います。一貫性を厳格に保つため、Paxosアルゴリズムが使用されています。そして本サービスは、クラスタ内の全てのノードで稼動します。Cassandraは、Medusaと呼ばれるインターフェースを介してアクセスされます。　

Zookeeper

• 主な役割： クラスタ構成マネージャー
• 説明： Apache ZookeeperをベースにしたZookeeperは、ホスト、IP、状態など全てのクラスタ構成をストアします。本サービスは、クラスタ内の3つのノードで稼動し、その内の1つがリーダーとして選出されます。リーダーが全てのリクエストを受信し残りのサービスに転送します。リーダーからのレスポンスが無い場合、新しいリーダーが自動的に選択されます。Zookeeperは、Zeusと呼ばれるインターフェースを介してアクセスされます。

Stargate

• 主な役割： データI/Oマネージャー
• 説明： Stargateは、全てのデータ管理とI/O処理に対応し、ハイパーバイザーからの主なインターフェース（NFS、iSCSIまたはSMB経由）となります。該当サービスはクラスタ内の全てのノードで稼動し、ローカルI/Oを処理します。

Curator

• 主な役割： MapReduceクラスタの管理とクリーンアップ
• 説明： Curatorは、クラスタ全体のディスクのバランシング、事前スクラブといった多くのタスクの管理と分散を行います。Curatorは全てのノードで稼動し、タスクとジョブの委任を行う選択されたCuratorマスターによってコントロールされます。Curatorには、6時間毎に行うフルスキャンと、1時間毎に行う部分スキャンという2つのスキャンタイプがあります。

Prism

• 主な役割： UIおよびAPI
• 説明： Prismは、コンポーネントやアドミニストレータが、Nutanixクラスタを構成およびモニターするための管理ゲートウェイとしての役割を果たします。これにはHTML5 UI, Ncli, REST APIが含まれます。Prismは、全てのノードで稼動し、クラスタ内の全てのコンポ―ネントと同様に選出されたリーダーを使用します。

Genesis

• 主な役割： クラスタのコンポーネントおよびサービス マネージャー

Chronos

• 主な役割： ジョブとタスクのスケジューラ
• 説明： Chronosは、Curatorスキャンされたジョブやタスクをノード間で実行するためのスケジューリングや調整を行います。Chronosは、全てのノードで稼動し、選出されたChronosマスターによってコントロールされます。Chronosマスターはタスクやジョブを委任し、Curatorマスターと同じノード上で稼働します。

Cerebro

• 主な役割： レプリケーション/DRマネージャー
• 説明： Cerebroは、DSFのレプリケーションとDR機能を担っています。これには、スナップショットのスケジューリング、リモートサイトへのレプリケーション、サイトの移行、そしてフェールオーバー機能が含まれています。CerebroはNutanixクラスタ内の全てのノードとリモート クラスタ/サイトへのレプリケーションに加わる全てのノードで稼動します。

Pithos

• 主な役割： vDisk構成マネージャー
• 説明： Pithosは、vDisk（DSFファイル）の構成データを担っています。Pithosは全てのノードで稼動し、Cassandraの上に構築されます。

Acropolisサービス

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

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

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

以下は、Acropolisマスターとスレーブの関係を概念的に図示したものです：

ドライブの構成

このセクションでは、ストレージ デバイス (SSD/HDD) がどのように構成され、パーティショニングされてNutanixプラットフォームに使用されるのかについて説明します。注意： ここで使用されるドライブの容量は、10を基底とする Gigabyte (GB) ではなく、2を基底とする Gibityte (GiB) で表現します。ファイルシステムによるドライブのフォーマット形態や、関連するオーバーヘッドも考慮に入れています。

SSDデバイス

SSDデバイスは前述したいくつかの主要なアイテムをストアします：

• Nutanix Home（CVMコア）
• Cassandra（メタデータストレージ）
• OｐLog（永続的なWRITEバッファ）
• コンテンツ キャッシュ（SSDキャッシュ）
• エクステント ストア（永続的なストレージ）

以下は、NutanixノードのSSDストレージ構成例です：

注意： リリース4.0.1以降、OpLogのサイズは動的に決定され、エクステントストア領域が動的に拡張できるようになりました。この値は、OpLogが完全に領域を使用したものと仮定して算出されています。また、上図の数値と図の幅は一致するものではありません。残りのGiB容量を算出する場合、上から順に計算していきます。例えば、OpLogに使用可能なGiBの計算は、Nutanix HomeとCassandraのサイズを、フォーマット済みSSDの容量から差し引いたものが対象になります。

Nutanix Home は可用性を担保するために最初の２つのSSDでミラーされます。 Cassandra はデフォルトでは最初のSSD上にあります。もしこのSSDに障害があった際は、CVMは再起動され、Cassandraは２番目のSSD上に配置されます

ほとんどのモデルは1台または2台のSSDが搭載された形で出荷されますが、それ以上のSSD台数で出荷されるモデルに対しても、同様の計算方法が適用されます。例えば400GB SSD x 2 が搭載された3060または6060ノードにこれを適用すると、1ノードあたりのOpLogは100GiB、コンテンツ キャッシュは40GiB、エクステント ストアは ～440GiBのSSD容量となります。

HDDデバイスは基本的にバルク ストレージとして利用され、その構成は非常にシンプルです：

• Curator予約領域（Curatorストレージ）
• エクステント ストア（永続的なストレージ）

NOTE: 注意： 上記は4.0.1の場合であり、数値はリリースによって異なります。

データ ストラクチャ

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

ストレージ プール

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

コンテナ

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

vDisk

• 主な役割： vDisk
• 説明： vDiskは、DSF上の512KB以上のファイルでvmdksおよびVMハードディスクを含みます。vDiskは、エクステント グループとしてディスク上でグループ化されストアされたエクステントで構成されます。

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

エクステント

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

エクステント グループ

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

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

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

I/O I/Oパスとキャッシュ

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

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

OpLog

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

エクステントストア

• 主な役割： 永続的なデータストレージ
• 説明： エクステントストアは、DSFのための永続的なバルクストレージとしてSSDとHDD上に存在し、デバイスやレイヤを追加拡張することが可能です。エクステントストアに入っているデータは、A) OpLogから投入されたもの、または、B) シーケンシャル処理によりOpLogを経由せずに直接投入されたもののいずれかです。Nutanix ILMは、I/Oパターンに応じて動的に配置するレイヤを決定し、データをレイヤ間で移動させます。

統合キャッシュ

• 主な役割： 動的なREADキャッシュ
• 説明：コンテンツキャッシュは重複排除後のREADキャッシュで、CVMのメモリとSSDの両方に存在します。キャッシュに存在しない（または、特定のフィンガープリントが存在しない）データに対するREADリクエストが発生すると、メモリに常駐するコンテンツキャッシュのシングルタッチプール (single-touch pool) にデータが置かれ、キャッシュから削除されるまでの間はLRUを使用します。続くREADリクエストは、データをメモリとSSDの両方で構成されるマルチタッチプール (multi-touch Pool) のメモリ部分に「移動」（実際はデータが移動するのではなく、キャッシュメタデータを変更）します。ここからは、2つのLRUサイクルが存在することになります。１つは、インメモリ部分で、キャッシュの削除により、データはマルチタッチプールのSSD部分に移動させられ、そこで新しいLRUカウンターが指定されます。全てのマルチタッチプールに対するREADリクエストは、データをマルチタッチプールの最上部に移動させることになり、そこでは、新しいLRUカウンターが指定されます。

以下は、統合キャッシュ の概要を図示したものです：

エクステントキャッシュ

• 主な役割： インメモリREADキャッシュ
• 説明： エクステントキャッシュは、インメモリのREADキャッシュで、CVMのメモリ内に常駐します。ここには、フィンガープリントと重複排除が無効化されているコンテナの非フィンガープリントエクステントが格納されます。バージョン3.5では、エクステントキャッシュはコンテンツキャッシュと分離していましたが、4.5では統合キャッシュとしてまとめられています。

拡張可能メタデータ

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

メタデータは、インテリジェントなシステムの中心となるものですが、ファイルシステムやストレージアレイにとって非常に重要な存在となります。DSFという観点から、メタデータには幾つかの重要な要素があります。つまり、100％、いかなる場合でも正確であること（完全一致性）、拡張可能なこと、大規模でも問題なく機能することが求められます。前述のアーキテクチャーのセクションでも説明した通り、DFSはリング状のキーバリューストアを使用して他のプラットフォームデータ（例えばステータスデータなど）と同様に、不可欠なメタデータをストアしています。メタデータの可用性と冗長性を確保するため、RFノードの合計が奇数になるように（例えば、3や5）に設定します。メタデータに書き込みや更新が発生した場合、ロー（Row）データがリング上の特定ノードに書き込まれ、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つのノードが必要となります。

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

Data is also consistently monitored to ensure integrity even when active I/O isn't occurring. Stargate's scrubber operation will consistently scan through extent groups and perform checksum validation when disks aren't heavily utilized. This protects against things like bit rot or corrupted sectors.

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

可用性ドメイン

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

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

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

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

データ

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

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

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

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

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

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

4.5より前のversionの場合、以下の条件を満たすことが必要となります：

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

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

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

メタデータ

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

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

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

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

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

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

設定データ

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

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

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

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

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

データパスの回復性能

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

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

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

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

想定される障害レベル

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

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

ディスク障害

ディスク障害の内訳としては、ディスクの削除、ディスク上の物理エラー、I/Oエラーなどがありますが、障害は積極的に取り除く必要があります。

VMの影響：

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

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

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

ここで重要となるのは、Nutanixの場合、データは全てのノード、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を引き継いで処理します。

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

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

ノード障害

VMの影響：

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

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

キャパシティの最適化

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

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

• 消失訂正符号 (Erasure Coding)
• データ圧縮
• データ重複排除

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

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

消失訂正符号 (Erasure Coding)

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

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

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

Note

プロからのヒント

デフォルトのストライプサイズ（「RF2ライク」な4/1あるいは「RF3ライク」な4/2）は、NCLIで、「ctr [create / edit] … erasure-code=/」と設定することでオーバーライドできます。なお、Nはデータブロック数でKはパリティブロック数です。

想定されるオーバーヘッドは、<パリティブロック数 > / <データブロック数 >で計算できます。例えば、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	N/A	N/A
7+	4/1	1.25X	4/2	1.5X

Note

プロからのヒント

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

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

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

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

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

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

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

Note

プロからのヒント

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

圧縮

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

 

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

インライン圧縮では、ディスクに書き込みが行われる前に、シーケンシャルなデータや大きなサイズのI/Oをメモリ内で圧縮します。一方、ポストプロセス圧縮は、一旦データが通常の状態（圧縮されていない状態）で書き込まれた後、Curatorフレームワークを使用してクラスタ全体でデータの圧縮を行うものです。インライン圧縮が有効化されていても、I/Oがランダムな特性を持つ場合、データは圧縮されていない状態でOpLogに書き込まれて合成され、エクステントストアに書き込まれる前にインメモリで圧縮されます。Google Snappy圧縮ライブラリを使用することで、処理オーバーヘッドが少なく非常に高速な圧縮/解凍速度で、優れた圧縮率を得ることができます。

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

Note

プロからのヒント

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

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

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

以下に、ポストプロセス圧縮とDSF WRITE I/Oパスとの関係を図示します：

以下に、解凍処理とDSF I/OパスのREAD時の関連を図示します：

Dashoboard ページ で確認することができます。

Elastic Dedupe Engine（弾力的重複排除エンジン）

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

 

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

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

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

Note

プロからのヒント

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

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

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

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

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

Note

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

4.5より前のversionの場合、vDiskの最初の12GBのみがフィンガープリント採取に適しています。これは、比較的小さなメタデータを維持するためのものであり、通常OSが最も共通するデータだからです。4.5では、メタデータの効率性を高めるため、この領域が24GBに拡張されました。

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

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

Note

重複排除 ＋ 圧縮

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のパターンを定常的にモニターし、必要に応じてデータを上層または下層に移動すると共に、その階層に関係なく、ホットなデータをローカルに移動させます。

ディスクバランシング

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

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

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

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

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

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

以下は、ノードタイプミックスのクラスタにストレージオンリーなノードが存在する場合、ディスクバランシングがどのように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 (Base vDisk)」として機能し、クローニングが行われる場合ブロックマップがロックされ、2つの「クローン」が作成されます。1つはクローン元のVMで、もう一方は新しいクローンです。

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

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

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

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

レプリケーションとDR

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

Nutanixでは、スナップショットおよびクローンのセクションで説明した機能をベースにしたネイティブなDRとレプリケーション機能を提供しています。Cerebroは、DSFのDRとレプリケーション管理を担当するコンポーネントです。Cerebroは、全てのノードで稼動しますが、（NFSマスター同様に）Cereboroマスターが選択され、レプリケーション管理を担当します。Cerebroマスターに障害が発生し、CVMが代理で稼動している場合には、他のCerebroが選定され役割を引き継ぎます。Cerebroのページは :2020 にあります。DRの機能は、以下に示すいくつかの主要な領域に分解することができます：

• レプリケーショントポロジー
• 導入構成
• レプリケーションライフサイクル
• グローバル重複排除

レプリケーショントポロジー

以前から、サイト・ツー・サイト、ハブ・アンド・スポーク、フルまたは部分メッシュなど、レプリケーションのトポロジーはいくつか存在していました。Nutanixでは、従来のサイト・ツー・サイトやハブ・アンド・スポークだけが可能なソリューションとは異なり、フルメッシュあるいは多対多モデルも提供しています。

基本的に、企業のニーズに合わせたレプリケーション機能をシステム管理者が選択できるのです。

導入構成

Nutanix DRの場合、以下のような構成を取ることができます。

リモートサイト

• 主な役割： リモートNutanixクラスタ
• 説明： リモートNutanixクラスタは、バックアップまたはDRのターゲットに使用することができます。

プロテクションドメイン（PD）

• 主な役割： 保護対象となるVMまたはファイルのマクログループ
• 説明： 希望するスケジュールでレプリケートされるVMまたはファイルのグループ。PDでコンテナ全体、または、個別のVMやファイルを選択して保護することができます

コンシステンシーグループ (CG)

• 主な役割： クラッシュ・コンシステントな処理を同時に行うVMまたはファイルのグループ
• 説明： プロテクションドメイン内のVMまたはファイルをグループ化したものであり、クラッシュ・コンシステントな方法で同時にスナップショットされる対象です。VMまたはファイルがリカバリされた際に、コンシステンシーグループ内のVM/ファイル間では互いの整合性が取れた状態で復帰します。プロテクションドメインは、複数のコンシステンシーグループを持つことができます。

レプリケーションスケジュール

• 主な役割： スナップショットおよびレプリケーションのスケジュール
• 説明： 特定のPDおよびCGのVMに対するスナップショットおよびレプリケーションのスケジュール

リテンションポリシー

• 主な役割：保持するローカルおよびリモートスナップショットの数
• 説明： リテンションポリシーでは、保持するローカルおよびリモートスナップショットの数を定義します。注意：リモートサイトについては、リモートリテンション/レプリケーションポリシーに対応するよう設定する必要があります。

以下は、単一サイトのPD、CGおよびVM/ファイルの論理的な関係を図示したものです：

プラットフォームは、VMまたはファイル単位で保護をかけることが可能ですが、シンプル性を維持するため、コンテナは全体に保護をかけることが重要です。

レプリケーションライフサイクル

前述の通り、Nutanixのレプリケーション機能はCerebroサービスを利用しています。Cerebroサービスは、動的に選定されるCVMである「Cerebro Master」と、各CVMで稼動するCerebro Salveに分けられます。「Celerbro Master」となったCVMに障害が発生した場合は、新しい「Master」が選定されます。

Cerebro Masterは、ローカルにあるCerebro Salveに対するタスク委譲管理を行い、リモートレプリケーションが発生した場合、リモートにある（複数の）Cerebro Masterとのコーディネーションを行います。

レプリケーションが発生すると、Cerebro Masterはレプリケーションの対象となるデータを特定し、レプリケーションタスクをCerebro Salveに移譲し、Stargateにレプリケーションすべきデータとその場所を指示します。

レプリケーションされたデータは、プロセス全体の複数のレイヤ上で保護されます。エクステントが読み込んだソースは、ソースデータの整合性を確保するよう（DSFの読み込み同様に）チェックサムが取られ、新しいエクステントについてもレプリケーション先で（DSFの書き込み同様）チェックサムが取られます。ネットワークレイヤの整合性はTCPで確認します。

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

リモートサイトはプロキシを使って設定し、全てのコーディネーションやクラスタから到来するレプリケーショントラフィックの拠点として使用することもできます。

以下に、プロキシを使用したレプリケーションアーキテクチャーを図示します：

SSHトンネルを使用してリモートサイトを設定することも可能ですが、この場合トラフィックは、2つのCVM間を流れることになります。

以下に、SSHトンネルを使用したレプリケーションアーキテクチャーを図示します：

グローバル重複排除

Elastic Deduplication Engine（弾力的重複排除エンジン）のセクションで説明した通り、DSFではメタデータのポインタを更新するだけで重複排除ができるようになっています。同じ考え方がDRとレプリケーション機能にも適用されます。DSFは回線越しにデータを送出する前にリモートサイトにクエリをかけ、ターゲットに既にフィンガープリントが存在しているかどうか（つまりデータが存在しているかどうか）を確認します。存在している場合には、回線越しにデータを送出することなく、メタデータの更新だけが行われます。ターゲットサイトにデータが存在しない場合には、該当データが圧縮されに送出されます。この時点でデータは両方のサイトに存在することになり、重複排除の対象となり得ます。

以下は、1つ以上のプロテクションドメイン (PD) を有する3つのサイトからなる構成例を示しています：

Cloud Connect

DSFのネイティブなDRおよびレプリケーション機能をベースにしたCloud Connectでは、これらの機能をクラウドプロバイダー（現在、Amazon Web ServicesとMicrosoft Azure）にまで拡張しています。注意：本機能は現在のところ、バックアップとレプリケーションに限定されています。

ネイティブなDRやレプリケーションのために作成するリモートサイトと同様に、「クラウドリモートサイト」を作成することが可能です。新しいクラウドリモートサイトが作成されると、NutanixはEC2（現状、m1.xlarge）またはAzure Virtual Machines（現状、D3）で単一ノードのNutanixクラスタを自動的に立ち上げ、エンドポイントとして使用します。

クラウドインスタンスは、ローカルで稼動するクラスタのためのAcropolisのコードを元に構築されています。つまり、全てのネイティブなレプリケーション機能（例えば、重複排除や差分ベースレプリケーションなど）を使用できます。

複数のNutanixクラスタがCloud Connectを使用している場合、いずれも、A) リージョン内で稼動するインスタンスを共有する、または、B) 新しいインスタンスを立ち上げるかのどちらかを選択できます。

クラウドインスタンスのストレージは、S3 (AWS) またはBlobStore (Azure) による論理ディスクである「クラウドディスク」を使用して実現されます。

以下は、Cloud Connectに使用される「リモートサイト」の論理的な説明になります：

できます。クラウドによるリモートサイトは、他のNutanixリモートサイト同様に、より高度な可用性が必要な場合には（例えば、当該リージョン全体に障害が発生した場合のデータ可用性の確保など）、クラスタを複数のリージョンにレプリケートすることができます

Cloud Connectを使用することで、同様のレプリケーションおよびリテンションポリシーをデータのレプリケーションにも適用することができます。データやスナップショットが古くなったり期限切れになったりした場合、クラウドクラスタは必要に応じてデータを処分します。

頻繁にはレプリケーションが発生しない場合（例えば日次や週次など）、レプリケーションのスケジュール前にクラウドインスタンスを立ち上げ、終了後は停止させるようにプラットフォームを設定することができます。

クラウドリージョンにレプリケートされたデータは、クラウドリモートサイトに設定された既存のまたは新規で作成されたNutanixクラスタに取り込んだり、リストアしたりすることができます：

Metro Availability

Nutanixは、サーバーやストレージクラスタを複数の物理サイトに拡張する「ストレッチクラスタ」機能をネイティブで提供しています。この場合、サーバークラスタは2つのロケーションにまたがる形でストレージの共有プールへアクセスします。

VM HAドメインは、単独のサイトから2つのサイトに拡張され、ニアゼロのRTOやゼロRPOを実現することができます。

この場合、各サイトにはそれぞれNutanixクラスタが存在することになりますが、コンテナはWRITE処理を認識する前に同期的にレプリケートされ、リモートサイトに「ストレッチ」されます。

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

サイトに障害が発生した場合、VMを他のサイトで再起動することが可能です

以下にサイト障害時の例を図示します：

2つのサイト間のリンクに障害が発生した場合、各クラスタはそれぞれ独立して運用されます。リンクが回復した時点で、両サイトで再同期が図られ（差分のみ）、同期レプリケーションが再開されます。

以下にリンク障害発生時の例を図示します：

Volumes API

Acropolis Volumes APIによって、バックエンドのDSFストレージを、外部利用者（ゲストOS、物理ホスト、コンテナなど）にiSCSI（現状）経由で提供することができます。

この機能を使うことで、あらゆるオペレーティングシステムがDSFにアクセスし、そのストレージ機能を利用できるようになります。このシナリオでは、該当OSは、ハイパーバイザーを経由せずに直接Nutanixとやり取りを行います。

Volumes APIの主な使用目的：

• 共有ディスク
  • Oracle RAC、Microsoft Failover Clusteringなど
• 最重要ディスク
  • 実行コンテキストが一時的でデータが重要な場合
  • コンテナ、OpenStackなど
• ゲスト起動iSCSI
  • ベアメタル利用者
  • vSphere上のExchange（Microsoft Support用）

Volumes API は以下によって構成されています：

• ボリュームグループ： iSCSIのターゲットおよびディスクデバイスのグループで集中管理やスナップショット、ポリシー適用が可能
• ディスク：ボリュームグループ内のストレージデバイス（iSCSIターゲットはLUNとして認識）
• アタッチメント： 指定イニシエータIQNでボリュームグループへのアクセスを可能に

注意： バックエンドではVGのディスクはDSF上のvDiskとなります

Volumes APIを使用する際には、以下の手順を踏襲します：

1. 新しいボリュームグループを作成
2. ディスクをボリュームグループに追加
3. イニシエータIQNをボリュームグループにアタッチ

以下に、通常のNutanixストレージ上にホステッドOSを持つNutanixのVMが、ボリュームを直接マウントしている状態を図示します：

Windowsの場合、Windows MPIO機能を使用してiSCSIマルチパスを構成できます。vDiskのオーナーが変更されないよう、「Failover Only」ポリシー（デフォルト）を使用することを推奨します。

ディスクが複数存在する場合、各ディスクはローカルCVMに対しアクティブ (Active) なパスを持ちます：

アクティブなCVMが停止した場合、他のパスがアクティブとなり、I/Oが再開されます：

Nutanixの調査では、MPIOが完了する迄に最大15～16秒必要ですが、その数値はWindowsのディスクI/Oタイムアウト（デフォルトで60秒）内に収まっています。

RAIDまたはLVMが必要な場合は、ダイナミックまたは論理ディスクにディスクデバイスを追加することができます：

ローカルCVMの使用率が高い場合、アクティブパスを他のCVMに振り向けることも可能です。これによって、複数のCVM間でI/Oのロードバランスを取ることができますが、一方でプライマリI/Oのためにネットワークのトラバースを行うことになります。

ネットワークとI/O

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

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ネットワークの関係を図示したものです：

データローカリティ

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

コンバージド（サーバー＋ストレージ）プラットフォームである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を検知し、バックグラウンドでデータをローカルに移動し、全てのI/Oがローカルで実行されるようにします。データの移動は、ネットワークに負荷を与えないよう、READ処理が発生した場合にのみ発生します。

Data locality occurs in two main flavors:

• Cache Locality
  • vDisk data stored locally in the Unified Cache. vDisk extent(s) may be remote to the node.
• Extent Locality
  • vDisk extents local on the same node as the VM

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

シャドウクローン

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

Acropolis分散ストレージには、「シャドウクローン」と呼ばれる機能があり、「複数の読み手」がある特定のvDiskやVMデータの分散キャッシングを行うことができます。VDI導入中に、多くの「リンククローン」がREADリクエストをセントラルマスター、つまり「ベースVM」に対して発行する場合などがこの典型例です。VMware Viewの場合、これはレプリカディスクと呼ばれ、全てのリンククローンから読み込まれます。XenDesktopの場合には、MCS Master 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=

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

ストレージレイヤとモニタリング

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処理の数と一致します。
• 使用場面：キャッシュやディスクが提供した処理数を確認する場合に使用します

ノードアーキテクチャー

Acropolis Hypervisorを導入した場合、コントローラVM (CVM) はひとつのVMとして稼動し、ディスクはPCIパススルーを使用するようになります。これで、PCIコントローラ（および付属デバイス）のパススルーが完全に可能となり、ハイパーバイザーを迂回してCVMに直接繋がるようになります。Acropolice Hypervisorは、CentOs KVMをベースにしています。

Acropolice Hypervisorは、CentOs KVMファンデーションをベースに基本的な機能を拡張し、HAやライブマイグレーションなどを可能にしたものです。

Acropolice Hypervisorは、Microsoft Server Virtualization Validation Programの認定を受け、またMicrosoft OS やアプリケーションの稼動検証を受けています。

KVMのアーキテクチャー

KVMの主要なコンポーネントは以下の通りです：

• KVM-kmod
  • KVMのカーネルモジュール
• Libvirtd
  • KVMとQEMUを管理するためのAPI、デーモン、管理ツール。AcropolisとKVM/QEMUはlibvirtdを経由して通信。
• Qemu-kvm
  • 全ての仮想マシン（ドメイン）上で稼動するマシンエミュレータおよびバーチャライザ。Acropolice Hypervisorでは、ハードウェアアシステッドな仮想化に利用され、VMはHVMとして稼動します。

以下に各コンポーネントの関連を図示します：

AcropolisとKVM/QEMUは、libvirtdを経由して通信します。

最大構成と拡張性

以下の最大構成と拡張制限が適用されます：

• 最大クラスタサイズ： N/A – Nutanixクラスタサイズと同じ
• VMあたりの最大vCPU数： ホストあたりの物理コア数
• VMあたりの最大メモリ： 2TB
• ホストあたりの最大VM数： N/A - メモリに依存
• クラスタあたりの最大VM数： N/A - メモリに依存

ネットワーク

Acropolice Hypervisorは、全てのVMネットワークにOpen vSwitch (OVS) を使用しています。VMネットワークは、PrismやACLIから設定可能で、各VM NICはタップインターフェースに接続されます。

以下に、OVSアーキテクチャーの概念的な構成を図示します：

VM NIC Types

AHV supports the following interface types:

• Access (default)
• Trunk (4.6 and above)

By default VM nics will be created as Access interfaces, however it is possible to expose a trunked interface.

A trunked interface can be added with the following command:

vm.nic_create <VM_NAME> vlan_mode=kTrunked trunked_networks=<ALLOWED_VLANS> network=<NATIVE_VLAN>

Example:

vm.nic_create fooVM vlan_mode=kTrunked trunked_networks=10,20,30 network=vlan.10

動作の仕組み

iSCSIマルチパス

各KVMホストには、iSCSIリダイレクタ・デーモンが常駐し、NOP OUTコマンドを使用して、クラスタのStargateのヘルスチェックを行います。

QEMUは、iSCSIリダイレクタがiSCSIターゲットポータルとなるよう設定されます。ログインリクエストがあるとリダイレクタが起動され、iSCSIログインは、健全なStargate（通常はローカルにある）にリダイレクトされます。

稼動中のStargateが停止した（つまりNOP OUTコマンドにレスポンスできない）場合、iSCSIリダイレクタはローカルのStargateに障害発生とマークします。QEMUがiSCSIログインを再試行した場合、リダイレクタはログインを他の健全なStargateにリダイレクトします。

ローカルのStargateが復旧（かつNOP OUTコマンドにレスポンスを開始）した場合、iSCSIリダイレクタはリモートStargateへの接続を終了するためTCPを切断します。QEMUはiSCSIログインを再度試み、ログインはローカルのStargateにリダイレクトされます。

IPアドレスの管理

Acropolis IPアドレス管理 (IPAM) ソリューションによって、DHCPスコープを確立し、VMにアドレスを割り当てることができます。この機能は、VXLANとOpenFlowルールを使用してDHCPリクエストをインターセプトし、DHCPレスポンスとしてレスポンスを返します。

Here we show an example DHCP request using the Nutanix IPAM solution where the Acropolis Master is running locally:

Acropolisマスターがリモートで稼動している場合、同じVXLANトンネルを使用して、ネットワーク越しにリクエストを処理します。

「アンマネージド」なネットワークでは、従来のDHCP / IPAM ソリューションも使用することができます。

VMの高可用性 (HA)

ホストに障害が発生した場合、そのホストで稼動していたVMは、クラスタ内の他の健全なノードで再起動されます。Acropolisマスターは、健全なノードでVMを起動する役割を担っています。

Acropolisマスターは、クラスタの全てのホスト上のlibvirtとの接続をモニターすることで、ホストのヘルスチェックを行います：

Acropolisマスターがパーティション化された場合、ネットワーク隔離された場合、あるいは障害が発生した場合には、クラスタの健全な部分で新しいAcropolisマスターが選定されます。クラスタがパーティション化された場合（例えば、Xノードが他のYノードに通信不能）、クォーラムのある側が動作を継続し、VMはそのノードで再起動されます。

Note

デフォルトのVM再起動ポリシー

ホストに障害発生した場合、AHVはデフォルトでVMの再起動に最善を尽くします。このモードの場合、ホストが利用不能になると、それまで稼動していたVMは残りの健全なホスト上で再起動されます。これはベストエフォート（つまりそのためのリソースが事前に確保されてはいない）であるため、全てのVMを再起動できるかどうかは、使用可能なAHVのリソースに依存します。

HAのためのリソース予約には2つのタイプが存在します：

• ホスト予約
  • X個のホストを予約。Xは対応できる障害ホストの数（例えば１、2）になります。
  • これは、全てのホストが同じRAMサイズをもつ場合のデフォルトになります。
• セグメント予約
  • クラスタ内のN個のホストを横断的にYのリソースを予約。これは、クラスタFTレベルの機能で、稼動するVMのサイズとクラスタ内のノード数となります。
  • これは、RAMサイズが異なるホストが存在する場合のデフォルトになります

Note

プロからのヒント

ホスト予約を使用するケース：

• 均一な構成のクラスタの場合（全てのホストが同じサイズのRAMで構成されている必要あり）
• パフォーマンスよりも集約度が優先される場合

セグメント予約を使用するケース：

• 不均一な構成のクラスタの場合（全てのホストが同じサイズのRAMで構成されている必要なし）
• 集約度よりパフォーマンスを優先する場合

次のセクションでは、両方の予約オプションに関して説明します。

ホスト予約

デフォルトでは、障害対応可能数は、クラスタのFTレベルと同じ（例えば1ならFT1あるいはRF2、2ならFT3またはRF3など）になります。この数値はacliから変更することができます。

Note

プロからのヒント

予約フェールオーバーホストのデフォルト数の変更、またはマニュアルでの設定については、以下のACLIコマンドを使用します：

acli ha.update num_reserved_hosts=<NUM_RESERVED>

以下に予約ホストの例を図示します：

ホストに障害が発生すると、予約ホストでVMが再起動されます：

障害ホストが復旧すると、VMは元のホストにライブマイグレーションされ、データローカリティのためのデータ移動を最小限に抑えます：

セグメント予約

セグメント予約は、クラスタ内の全てのホストで横断的にリソースの予約を行います。各ホストはHAのために予約された部分を共有します。これにより、特定ホストで障害が発生しても、クラス全体としてVMを再起動するキャパシティを持つことが可能になります。

Note

プロからのヒント

セグメントベースの予約を行う場合、ホスト間でバランスを取る必要があります。バランスを取ることで、最大の使用効率が得られ、また、過剰にセグメント予約することもなくなります。

以下に予約セグメントの状態を図示します：

ホストに障害が発生すると、クラスタの残った健全なホスト全体でVMが再起動されます：

Note

予約セグメントの計算

システムが、予約セグメント数の合計と1ホストあたりの予約数を自動計算します。この計算方法の内部的な詳細について、以下に記述します。

Acropolis HAは、固定サイズのセグメントを使って、VMの再起動に十分な領域を予約し、ホストに障害が発生した場合に備えます。セグメントのサイズは、システムで最も大きなVMに対応します。Acropolis HAの優れている点は、複数の小型のVMを1つの固定サイズのセグメントにパックできるところにあります。サイズが異なるVMを持つクラスタにおいて、複数のVMを使用して1つのセグメントを形成することで、固定サイズのセグメントを使用することによるフラグメンテーションの発生を減少させることができます。

VMの最も効率的な配置（予約セグメントの最小数）は、コンピュータサイエンスにおいて、ビンパッキング問題 (bin-packing problem) としてよく知られています。最適なソリューションは、NP困難 (NP-hard、指数的) ですが、発見的解決方法が一般的なケースには有利です。Nutanixでは、継続的に設定アルゴリズムを改善していきます。Nutanixでは、一般的なケースに対する追加オーバーヘッドは、将来のバージョンで0.25程度になると期待しています。現在のフラグメンテーションによるオーバーヘッドは0.5から1の間にあり、1ホスト障害につき1.5から2のオーバーヘッドが生じています。

セグメントベースの予約を使用する場合、いくつかの考慮に入れるべき重要なポイントがあります：

• セグメントサイズ ＝ VMを稼動させるための最大メモリ容量（GB）
• 最大負荷ホスト ＝ 最大のメモリ容量 (GB) を必要とするVMを稼動するホスト
• フラグメンテーションオーバーヘッド ＝ 0.5 - 1

以上の情報をもとに、予約セグメント数を計算することができます：

• 予約セグメント数 ＝ (最大負荷ホスト / セグメントサイズ) x (1 + フラグメンテーションオーバーヘッド)

アドミニストレーション

近日公開！

重要なページ

近日公開！

コマンドリファレンス

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>

Show 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

ネットワークページに移動

2 – ネットワーク

重要なページ

一般的なユーザーインターフェースに加え、高度なNutanixページを参照して、詳細なステータスや指標をモニターすることができます。URLは、http://: という形式になります。例： http://MyCVM-A:2009 注意： 異なるサブネットを使用している場合、ページにアクセスするためにはIPtableを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コントロールのページです。

クラスタコマンド

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

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

cluster status

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

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

genesis status

Nutanixクラスタアップグレード

説明：CLIからローリング（またはライブ）クラスタアップグレードを実行

アップグレードパッケージを ~/tmp/ on one CVM にアップロード

パッケージを untar する

tar xzvf ~/tmp/nutanix*

アップグレードの実行

~/tmp/install/bin/cluster -i ~/tmp/install upgrade

ステータスを確認

upgrade_status

ノードアップグレード

説明： 指定したノード（複数可）を最新のクラスタバージョンにアップグレード

希望するバージョンを実行しているCVMから以下のコマンドを実行：

cluster -u <NODE_IP(s)> upgrade_node

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

説明： 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から停止したクラスタサービスを起動

指標とスレッシュホールド

以下のセクションでは、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ページは、:2009で見ることができます。

Note

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

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

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

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

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

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

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

Note

プロからのヒント

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

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

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

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

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

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

Note

プロからのヒント

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

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)」詳細になります：

Note

プロからのヒント

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

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

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

Note

プロからのヒント

ランダムまたは小規模な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://:2010から入ることができます。注意： Curatorマスターにいない場合は、「Curator Master：」の後の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スキャン」セクションになります：

ノードアーキテクチャー

ESXiを導入した場合、コントローラVM (CVM) はVMとして稼動し、ディスクはVMダイレクトパスI/Oを使用するようになります。これによって、PCIコントローラ（および付属デバイス）のパススルーが完全に可能となり、ハイパーバイザーを迂回してCVMに直接繋がるようになります。

最大構成と拡張性

以下の最大構成と拡張制限が適用されます：

• 最大クラスタサイズ：64
• VMあたりの最大vCPU数： 128
• VMあたりの最大メモリ： 4TB
• ホストあたりの最大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/

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障害時にどういった動きをするか図示したものです：

重要なページ

近日公開！

コマンドリファレンス

ESXiクラスタップグレード

説明： CLIからESXiホストの自動アップグレードを実行
#Nutanix NFSコンテナにアップグレードオフラインバンドルをアップロード
# Nutanix CVMにログイン
# アップグレードに実行

for i in `hostips`;do echo $i && ssh root@$i "esxcli software vib install -d /vmfs/volumes/<Datastore Name>/<Offline bundle name>";done

# 例

for i in `hostips`;do echo $i && ssh root@$i "esxcli software vib install -d /vmfs/volumes/NTNX-upgrade/update-from-esxi5.1-5.1_update01.zip";done

ESXiのローリングリブートを実行： PowerCLIの場合、自動ホス通りブート

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のアクセプタンスレベルをコミュニティサポートに設定

説明： vibのアクセプタンスレベルをコミュニティサポートに設定し、サードパーティのvibsをインストール可能にする

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
• ホストあたりの最大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のコピー状態は「NfsSlaveVaaiCopyDataOp」、ディスクのゼロイング (zeroing) 状態は「NfsSlaveVaaiWriteZerosOp」で表示されます。

重要なページ

近日公開！

コマンドリファレンス

複数のリモートホストでコマンドを実行

説明： 特定のまたは複数のリモートホストで 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"

指標とスレッシュホールド

近日公開！