Nutanixバイブル

Copyright (c) 2022: The Nutanix Bible and NutanixBible.com, 2022. 本ブログの著者または所有者から書面による許可を受けることなしに、本著作物を無断で使用すること、またはコピーすることを固く禁じます。 本著作物を引用、または本著作物に対するリンクを設定することは許可されますが、 NutanixおよびNutanixBible.comの著作であることを明記し、かつ原著の内容を適切かつ明確に示すよう、該当箇所を提示することを前提とします。

日本語版に関して、誤植や不自然な翻訳など、お気づきの点がございましたら こちらのフォームよりお知らせください。


  • 他言語版はこちらからご覧ください。
  • For other languages, click the flag icon.
  • 다른 언어는 국기 아이콘을 클릭하십시오.
  • Для других языков щелкните значок флага.
  • 对于其他语言,请单击标记图标。

翻訳版について: Nutanixバイブルの原著(英語版)は頻繁に更新されるため、日本語版を含む各言語の翻訳版では最新の更新を反映しているとは限りません。 あらかじめご了承ください。 また、同じ理由によりPDFバージョンを提供していません。 ハードコピーを印刷したい場合には、「PDFに変換」などの手段をご利用ください。

Part 1: Core

Book of Basics

一般的に「Webスケール」の説明に用いられる原則を、Nutanixはスタック全体で活用しています。このセクションでは、これらの基本と、核となるアーキテクチャーの概念について説明します。

Webスケール – ウェブスケール – 名詞 – コンピューターアーキテクチャー
インフラストラクチャーおよびコンピューティングのための
新しいアーキテクチャー

Nutanix は、ソフトウェアスタックを通して「Webスケール」の原則を活用しています。 Webスケールだからといって、GoogleやFacebook、Microsoftのような「超大規模なスケール」になる必要はないということを明言しておきます。 Webスケールな構成はどんな規模でも(3ノードでも、数千ノードでも)適用可能であり、その恩恵を受けることができます。

Webスケールなインフラストラクチャーについて説明するために、いくつか重要な要素があります:

  • ハイパーコンバージェンス
  • ソフトウェア デファインド インテリジェンス
  • 自律分散システム
  • インクリメンタルかつリニアな拡張性

その他の要素:

  • APIベースの自動化と豊富な分析機能
  • セキュリティをコアに据えている
  • 自己修復機能

本書では、これらの基礎とアーキテクチャーコンセプト説明します。

戦略とビジョン

Nutanixは、ある一つの目標に焦点を当てて考案されました:

あらゆる場所のインフラストラクチャーコンピューティングを、存在を意識しなくていいくらい簡単(インビジブル)にする。

このシンプルさは、次の3つのコア領域に焦点を当てることで達成されました。

  1. 選択とポータビリティを可能にする。 (HCI/Cloud/Hypervisor)
  2. コンバージェンス、抽象化、インテリジェント ソフトウェア(AOS)による「スタック」のシンプル化。
  3. ユーザーエクスペリエンス(UX)とデザイン(Prism)を重視した、直感的なユーザーインターフェイス(UI)の提供。
HCI/クラウド/ハイパーバイザー:「選択」

私達は、単一のハイパーバイザー(ESXi)をサポートする単一のハードウェア プラットフォーム(NX)からスタートしましたが、常に単一のハイパーバイザー/プラットフォーム/クラウド企業以上の存在であることを認識していました。 これが、vCenter でプラグインではなく独自の UI をゼロから構築したり、カーネル内のネイティブなものではなくVM として実行したり、といった選択をした理由の1つです(他にも多くの理由があります)。 なぜでしょうか? と聞かれるかもしれません。

1つのハイパーバイザー、プラットフォーム、またはクラウドがすべてのお客様のニーズに適合するわけではありません。 同じプラットフォームで複数のハイパーバイザーをサポートすることによって、お客様に選択と活用の自由を与えます。 また、それらの間で移動できるようにすることで、お客様に柔軟性を与えます。 すべてがNutanixプラットフォームの一部であるため、同じ操作体験が提供されます。

現在、12種類以上のハードウェアプラットフォーム(Direct/OEM/サードパーティ)、複数のハイパーバイザー(AHV、ESXi、Hyper-Vなど)をサポートし、主要なクラウドベンダーすべて(AWS、Azure、GCP)とのインテグレーションを拡充しています。 これによりお客様は自分にとって最適なものを選択でき、ベンダーとの交渉目的としても利用できます。

注:プラットフォームとは、このセクション全体、そして一般的に使われている一つのキーワードです。 私たちはワンオフの製品を作ろうとしているのではなく、プラットフォームを構築しているのです。

以下に、Nutanixプラットフォームのアーキテクチャー概要を示します。

Nutanix Platform - Architecture
Nutanix Platform - Architecture
AOS + AHV/ハイパーバイザー:「ランタイム」

私たちは、分散ストレージ ファブリック(DSF。当時はNutanix Distributed Filesystem、別名NDFSとして知られていました)と呼ばれる機能でストレージをシンプル化することからこの旅をはじめて、 それは、ローカルストレージリソースとインテリジェントソフトウェアを組み合わせて「集中型ストレージ」のような機能を提供するものでした。

長年にわたり、私たちは多くの機能を追加してきました。 物事をシンプル化するために、私はこれらを2つの核となる領域に分解しました:

  1. コア サービス
    • 基礎的なサービス群
  2. プラットフォーム サービス
    • コア サービスをもとにしたサービス群であり、付加的な機能およびサービスを提供する

コア サービスは、ワークロード(VM/コンテナ)や他のよりハイレベルのNutanixサービスの実行を容易にする、基礎的なサービスとコンポーネントを提供します。 当初は単なるDSF製品でしたが、スタックのシンプル化と抽象化を支援するために、プラットフォームの機能を拡張し続けています。

以下に、AOSコア プラットフォームの概観を示します:

Nutanix Platform - AOS Core
Nutanix Platform - AOS Core

何年にもわたって、これは独自のハイパーバイザー(AHV)の導入による仮想化の抽象化(私達は、これは透過的なもので、システムの一部であるべきだと信じています)、アップグレードのシンプル化、セキュリティや暗号化のような他の重要なサービスの提供などにまで拡張してきました。

これらの機能により、私達は多くのインフラストラクチャーレベルの問題を解決しましたが、そこで止まりませんでした。 人々はまだ、ファイル共有、オブジェクトストレージ、コンテナのような追加サービスを必要としました。

いくつかのサービスについて、他ベンダーの製品を使用するようにお客様に要求するのではなく、どのサービスでパートナーと提携し、どのサービスを自社で構築するかを考えました。 バックアップについてはVeeamやHYCUなどのベンダーと提携し、ファイルやオブジェクトサービスのような他のサービスについてはプラットフォームサービスとして構築しました。

以下に、Nutanixプラットフォームサービスの概観を示します:

Nutanix Platform - Services
Nutanix Platform - Services
Prism:「インターフェイス」
Nutanix Platform - Prism
Nutanix Platform - Prism

端的にいうと、Appleのような企業が培ってきた、シンプルさ、一貫性、直観性にフォーカスを当てたデザイン原則を適用することです。 当初から、私達はNutanix製品の「フロントエンド」に多大な時間と労力を費やしてきました。 後回しにせず、UI/UXとデザインのチームは、常に限界に挑戦してきました。 例えば、私達は(SaaSプレイヤーを除けば)企業向けソフトウェア企業の中では、管理用UIをHTML5で作成した最初の企業の1つでした。

ここでのもう一つの核となる項目は、プラットフォームに単一のインターフェイスを提供し、その中で一貫した操作体験を維持することに重点を置いていることです。 私達の目標は、インフラストラクチャーを統合したようにUIを統合することです。 私達はPrismを、データセンターでの仮想化の管理、クラウドでのDesktop-as-a-Serviceの管理、または支出の可視性の提供など、 Nutanixプラットフォームの管理と利用ができる単一のインターフェイスとして提供したいと考えています。

これは、機能やサービスの創造と買収を通してプラットフォームを拡張し続ける上で重要なことです。 新しい機能をただ追加するのではなく、それらをプラットフォームにネイティブに統合するために時間を費やしたいと考えています。 その方が時間はかかりますが、長期的には一貫した操作体験を維持し、リスクを軽減することができます。

Nutanix:「プラットフォーム」

要約すると、私達のビジョンはシンプルです。 「どのようなアプリでも、どのような場所でも、1つのプラットフォーム」です。 注:私はこれをマーケティング担当から得ましたが、完璧にフィットしており、私達の目的を簡潔に述べています。

Nutanix Platform - Architecture
Nutanix Platform - Architecture

これは当初から私達の目標でした。 その証明として、ここに私が2014年の時点で作成した、Nutanixプラットフォームアーキテクチャーについて話すためのイメージがあります。 ご覧のように多くは変わっていませんが、私たちはただ拡大を続け、この目標に向かって努力を続けています。

Nutanix Platform - Circa 2014
Nutanix Platform - Circa 2014

製品とプラットフォーム

長年にわたり、Nutanixプラットフォームの機能セットとサービスは大幅に成長してきました。 これは、仮想化技術のシンプル化と抽象化、アップグレードと運用の自動化、その他多くのことを実現するために進化してきました。 このセクションでは、現在のポートフォリオとパートナーシップについて説明します。 注: 最新のポートフォリオと製品については、Nutanix のウェブサイトを参照してください。

長年にわたって製品ポートフォリオが成長してきたので、製品について話すよりも、むしろ私は結果とそれらを達成するための旅に焦点を当てたいと思っています。 以下のステップは、お客様の「旅」と、Nutanix が彼らの達成を支援できる結果をカバーしています。

Step 1: データセンターの近代化(Core)

コア(Core)には、複雑な3層(3-Tier)のインフラストラクチャーからシンプルなHCIプラットフォームへの移行を容易にする、基礎となるNutanix製品が含まれています。 AOSはすべてのコアサービス(ストレージ、アップグレード、レプリケーションなど)を提供し、 Prismはコントロールプレーンと管理コンソールを提供し、AHVは無償の仮想化プラットフォームを提供します(注:ESXi と Hyper-V を使用することもできます)。

コア機能に含まれるもの:

  • コアプラットフォーム (HCI)
  • ストレージサービス
  • 仮想化
  • 集中化された管理と運用
  • アップグレード
  • レプリケーション / DR
Products Ecosystem - Core
Products Ecosystem - Core
Step 2: プライベートクラウドの有効化 (Essentials)

エッセンシャル(Essentials)は、コア インフラストラクチャーをプライベートクラウドのように消費できるようにする機能を提供することに重点を置いています。 Flowはネットワークセグメンテーションとセキュリティを提供し、Filesはファイルサービスを提供し、Calmはセルフサービス、クォータ、そしてオーケストレーション機能を提供します。

エッセンシャル機能に含まれるもの:

  • 高度な分析と異常検出
  • 自動化とオーケストレーション
  • セルフサービスポータル(SSP)とクォータ
  • マイクロセグメンテーション
  • ファイルサービス
Products Ecosystem - Private Cloud
Products Ecosystem - Private Cloud
Step 3: ハイブリッドクラウドの有効化 (Enterprise)

エンタープライズ(Enterprise)は、クラウドとクラウドサービス間でワークロードを移行する機能を提供することに焦点を当てている。 これには、クラウドとオンプレミスを横断するコストガバナンスとコンプライアンスに焦点を当てたBeamのような機能や、Frame(DaaS)やXi Leap(DRaaS)といったクラウドサービスが含まれます。

エンタープライズ機能に含まれるもの:

  • ポリシーによるDR / Run-bookによる自動化
  • DRaaS
  • ハイブリッドクラウドでのコストガバナンスとコンプライアンス
  • Desktop as a Service(DaaS)
  • Database as a Service(RDS)
  • Kubernetes / Dockerサービス
  • オブジェクトストレージ
  • ブロックサービス
Products Ecosystem - Hybrid Cloud
Products Ecosystem - Hybrid Cloud
プラットフォーム

現在、Nutanixは以下のプラットフォームをサポートしています:

  • Nutanixアプライアンス
    • NX (Supermicro)
  • OEMアプライアンス
    • Nutanix on HPE ProLiant DX
    • Nutanix on Lenovo HX
    • Nutanix on Fujitsu XF
    • Nutanix on Dell XC
    • Nutanix on Inspur InMerge
  • サードパーティサーバーのサポート
    • Nutanix on HPE Apollo
    • Nutanix on Cisco UCS
    • Nutanix on Intel Data Center Blocks
    • Nutanix Tactical and Ruggedized platforms on Klas

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

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

ハイパーコンバージドシステムには、いくつかの核となる構造があります:

  • コンピューティングスタックの収束と崩壊が必要(例:コンピュート+ストレージ)
  • システム内のノード間でデータとサービスのシャード(分散)が必要
  • 集中型ストレージと同等の機能を備えていることが必要(例:HA、ライブマイグレーションなど)
  • データを可能な限り実行処理(コンピュート)に近づける必要 (Importance of Latency)
  • ハイパーバイザーに依存しない
  • ハードウェアに依存しない

以下の図は、典型的な3層スタック対ハイパーコンバージドの例を示しています:

3-Tier vs. HCI
3-Tier vs. HCI

ご覧のように、ハイパーコンバージドシステムは以下のことを行います:

  • コントローラーを仮想化してホストに移動する
  • コアサービスとロジックをソフトウェアによって提供する
  • システム内のすべてのノードにデータを分散(シャード)する
  • ストレージをコンピュートのローカルに移動する

Nutanixソリューションは、ローカルコンポーネントを活用してワークロードを実行するための分散プラットフォームを作成する、統合ストレージ+コンピューティングのソリューションです。

それぞれのノードで、業界の標準的なハイパーバイザー(現在はESXi、AHV、Hyper-V)およびNutanixコントローラーVM(CVM)を稼動させることができます。 Nutanix CVMは、Nutanixソフトウェアを稼動させ、ハイパーバイザーおよびその上で稼動する全てのVMに対するI/O処理の全てを受け持ちます。

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

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

Nutanix CVMは、コアとなるNutanixプラットフォームロジックを担当し、以下のようなサービスを処理します:

  • ストレージI/Oと変換(重複排除、圧縮、EC)
  • UI / API
  • アップグレード
  • DR / レプリケーション
  • その他

注: 一部のサービスや機能は、追加のヘルパーVMを作成したり、マイクロサービスプラットフォーム(MSP)を使用したりします。 例えば、Nutanix Filesは追加のVMをデプロイしますが、Nutanix ObjectsはMSPのためのVMをデプロイし、それらを活用します。

VMware vSphereが動作するNutanixユニットの場合、SSDやHDDデバイスを管理するSCSIコントローラーが、VM-Direct Path(Intel VT-d)を利用して直接CVMに接続されます。 Hyper-Vの場合は、ストレージデバイスがCVMにパススルー接続されます。

コントローラーの仮想化

Nutanixコントローラーをユーザー空間でのVMとして実行する主な理由は、以下の4領域に分類されます:

  1. 移動性
  2. 回復性
  3. 保守とアップグレード
  4. パフォーマンス(はい、本当ですよ)

はじめから、私達は単一のプラットフォーム企業ではないことを知っていました。 それ故に、ハードウェア、クラウド、ハイパーバイザーベンダーのいずれであっても、選択肢を持つことは常に私たちにとって重要でした。

ユーザー空間でVMとして実行することで、Nutanixソフトウェアをアンダーレイとなるハイパーバイザーおよびハードウェアプラットフォームから切り離します。 これにより、コアのコードベースをすべての運用環境(オンプレミスおよびクラウド)で同じに保ちながら、他のハイパーバイザーのサポートを迅速に追加できました。 そのうえ、ベンダー固有のリリースサイクルに縛られない柔軟性を提供しました。

ユーザー空間でVMとして実行する性質上、ハイパーバイザーの外部にあるため、アップグレードやCVMの「障害」といったものをエレガントに処理できます。 例えば、CVMがダウンするという破滅的な問題が発生した場合でも、ノード全体が、クラスタ内の他のCVMからのストレージI/Oとサービスで引き続き稼働します。 AOS(NutanixのCoreソフトウェア)のアップグレード中でも、そのホストで実行されているワークロードに影響を与えることなくCVMを再起動できます。

しかし、カーネル内にあるほうがより高速ではないでしょうか? 簡潔に答えると、NOです。

よく議論に上がるのは、カーネル内とユーザー空間のどちらにあるかについてです。 背景として、実際の内容とそれぞれの長所と短所を説明する「ユーザー空間とカーネル空間」のセクションを読むことをお勧めします。

要約すると、オペレーティングシステム(OS)には2つの実行空間があり、それは カーネル(特権のあるOSのコアでドライバーが常駐するような場所)とユーザー空間(アプリケーションやプロセスが常駐する場所)です。 慣例上、ユーザー空間とカーネルの間を移動すること(コンテキストスイッチとして知られる)は、CPUと時間(コンテキストスイッチあたり~1,000ns)の面でコストがかかる可能性があります。

その議論では、カーネルにいることは常にベターで速いということですが、これは誤りです。 何があっても、ゲストVMのOSには常にコンテキストスイッチがあります。

分散システム

分散システムとして不可欠な要素が3つあります:

  1. 単一障害点 (SPOF) を持たないこと
  2. 規模に関わりなくボトルネックが発生しないこと(リニアな拡張が可能であること)
  3. 並列処理を利用していること (MapReduce)

Nutanixの複数のノードから成るグループが、分散システム(Nutanixクラスタ)を形成し、PrismやAOSの機能を提供します。全てのサービスやコンポーネントは、クラスタ内の全てのCVMに分散され、高い可用性やリニアなパフォーマンスの拡張性能を提供します。

以下の図は、NutanixノードがどのようにNutanixクラスタを形成するのかを例示したものです:

Distributed Storage Fabric Overview
Nutanixクラスタ - 分散システム

これらのテクニックは、メタデータやデータにも同様に適用されています。全てのノードやディスクデバイスにメタデータやデータを分散することで、通常のデータ投入や再保護を行う際、最大のパフォーマンスが発揮されるようになっています。

これによって、クラスタの能力を最大限に引き出しながら、Nutanixが使用するMapReduceフレームワーク(Curator)が並列処理を行えるようになります。例えば、データの再保護や圧縮、消失訂正号、重複排除といった処理がこれに該当します。

以下の図は、それぞれのノードがどの程度の割合で処理を分担しているのかを示したもので、クラスタの規模が拡大するにつれ、分担割合が劇的に低下していることが分かります:

Work Distribution - Cluster Scale
処理の分散 - クラスタ規模との関係

重要な点: クラスタのノード数が増加(クラスタが拡大)すると、各ノードが負担すべき処理の割合が低下し、処理全体としての効率も向上します。

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

ソフトウェア デファインド システムには、4つの不可欠な要素があります:

  • プラットフォーム(ハードウェア、ハードウェア)間のモビリティ(可搬性)を提供できること
  • カスタムなハードウェアに依存しないこと
  • 迅速な開発(機能開発、バグ修正、セキュリティパッチ)を可能にすること
  • ムーアの法則の恩恵を活かせること

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

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

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

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

Software-Defined Controller Framework
ソフトウェア デファインド コントローラー フレームワーク

クラスタ コンポーネント

常にユーザーを主眼に置くNutanix製品は、その導入や使用が極めて容易です。 これは基本的に、抽象化や様々な自動化、さらにソフトウェアの連携機能によって実現されています。

以下にNutanix Clusterの主要コンポーネントを示します。(心配は無用です。全部記憶したり、個々の役割を全て理解したりする必要はありません)

Nutanix Cluster Components
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
  • 主な役割: クラスタのコンポーネントおよびサービス マネージャー
  • 説明: Genesisは全てのノードで稼動するプロセスで、サービスの初期設定と制御(開始、停止など)を行います。 Genesisは、クラスタから独立して稼動するプロセスで、クラスタの構成や稼動を必要としません。 Zookeeperが稼動していることがGenesisの動作要件になります。 cluster_initおよびcluster_statusページは、Genesisプロセスによって表示されます。
Chronos
  • 主な役割: ジョブとタスクのスケジューラー
  • 説明: Chronosは、Curatorスキャンされたジョブやタスクをノード間で実行するためのスケジューリングや調整を行います。 Chronosは、全てのノードで稼動し、選出されたChronosリーダーによってコントロールされます。 Chronosリーダーはタスクやジョブを委任し、Curatorリーダーと同じノード上で稼働します。
Cerebro
  • 主な役割: レプリケーション/DRマネージャー
  • 説明: Cerebroは、DSFのレプリケーションとDR機能を担っています。 これには、スナップショットのスケジューリング、リモートサイトへのレプリケーション、サイトの移行、そしてフェイルオーバー機能が含まれています。 CerebroはNutanixクラスタ内の全てのノードとリモート クラスタ/サイトへのレプリケーションに加わる全てのノードで稼動します。
Pithos
  • 主な役割: vDisk構成マネージャー
  • 説明: Pithosは、vDisk(DSFファイル)の構成データを担っています。Pithosは全てのノードで稼動し、Cassandraの上に構築されます。

無停止アップグレード

Book of Prismの「Nutanixソフトウェアのアップグレード」および「ハイパーバイザーのアップグレード」セクションで、AOSおよびハイパーバイザーバージョンのアップグレードを実行するために使用される手順を説明しました。 このセクションでは、さまざまなタイプのアップグレードを無停止で実行できるようにする方法について説明します。

AOSのアップグレード

AOSのアップグレードでは、いくつかの核となる手順が実行されます:

1 - アップグレード前のチェック

アップグレード前のチェックでは、以下の項目が確認されます。 注: アップグレードを続行するには、これが正常に完了する必要があります。

  • AOSとハイパーバイザーのバージョン互換性を確認する
  • クラスタの状態を確認する(クラスタのステータス、空き容量、Medusa、Stargate、Zookeeperなどコンポーネントのチェック)
  • すべてのCVMとハイパーバイザー間のネットワーク接続を確認する
2 - アップグレードソフトウェアの2ノードへのアップロード

アップグレード前のチェックが完了すると、システムはアップグレードソフトウェアバイナリをクラスタ内の2ノードにアップロードします。 これは、耐障害性のためであり、1つのCVMが再起動している場合に、他方のCVMからソフトウェアを取得できるようにします。

3 - アップグレードソフトウェアのステージング

ソフトウェアが2つのCVMにアップロードされると、すべてのCVMが並行してアップグレードソフトウェアをステージングします。

CVMには、AOSバージョンのための2つのパーティションがあります:

  • アクティブパーティション(現在実行中のバージョン)
  • パッシブパーティション(アップグレードがステージングされる場所)

AOSアップグレードは、非アクティブパーティションでアップグレードが実行されます。 アップグレードトークンを受信すると、アップグレードされたパーティションをアクティブパーティションとしてマークし、CVMを再起動してアップグレードされたバージョンにします。 これは、bootbankとaltbootbankに似ています。

注: アップグレードトークンはノード間で反復的に渡されます。 これにより、一度に1つのCVMのみが再起動します。 CVMが再起動して安定すると(サービスの状態と通信を確認して)、すべてのCVMがアップグレードされるまでトークンが次のCVMに渡されます。

アップグレードのエラー処理

よくある質問として、アップグレードが失敗した場合や、プロセスの途中で問題が発生した場合はどうなるか、というものがあります。

アップグレードの問題が発生した場合は、アップグレードを停止して進行しません。 注: アップグレードが実際に開始される前に、アップグレード前のチェックでほとんどの問題が検出されるため、これは非常にまれです。 ただし、アップグレード前のチェックが成功して実際のアップグレード中に問題が発生した場合、クラスタで実行されているワークロードとユーザーのI/Oへの影響はありません

Nutanixソフトウェアは、サポートされているアップグレードバージョン間の混在モードで無期限に動作するように設計されています。 例えば、クラスタがx.y.fooを実行していて、それをx.y.barにアップグレードしている場合、システムは両方のバージョンのCVMで無期限に実行できます。 これは、実際にアップグレードプロセス中に発生します。

例えば、x.y.fooの4ノードクラスタがあり、x.y.barにアップグレードを開始した場合、最初のノードをアップグレード開始すると、他のノードがx.y.fooである間にx.y.barが実行されます。 このプロセスは続行され、アップグレードトークンを受け取るとCVMはx.y.barで再起動します。

Foundation (イメージング)

Foundationイメージングのアーキテクチャー

Foundation(ファンデーション)は、Nutanixクラスタのブートストラップ、イメージング及び導入のためにNutanixが提供しているツールです。 イメージングプロセスにより、目的とするバージョンに対応するAOSソフトウェアやハイパーバイザーをインストールされます。

Nutanixノードには、デフォルトでAHVがプリインストールされており、異なるハイパーバイザーをインストールするためには、Foundationを使用して、該当ノード上に必要とされるハイパーバイザーを再イメージングする必要があります。 注意: 一部のOEMでは、事前に希望するハイパーバイザーがインストールされた形で出荷を行っています。

以下に、Foundationのアーキテクチャー概要を示します:

Foundation - Architecture
Foundation - アーキテクチャー

Foundationは、設定を容易にする目的でAOS 4.5からCVMに組み込まれました。 インストーラーの保存領域は、アップロードイメージを格納するためのディレクトリであり、初期のイメージングに加え、イメージングが必要になるクラスタ拡張でも使用されます。

Foundationディスカバリ アプレット(こちらからダウンロードできます)は、ノードをディスカバリしてユーザーが接続するノードを選択できるようにします。 ユーザーが接続ノードを選択すると、アプレットは localhost:9442のIPv4アクセスを、CVMのIPv6リンクローカルアドレスのポート8000にプロキシします。

以下にアプレットアーキテクチャーの概要を示します:

Foundation - Applet Architecture
Foundation - アプレットアーキテクチャー

注意: ディスカバリアプレットは、ディスカバリやノード上で稼動するFoundationサービスにプロキシする1つの手段に過ぎません。 実際のイメージングやコンフィグレーションは、Foundationサービスが行うもので、アプレットではありません。

プロからのヒント

ターゲットとなるNutanixノードとは異なる(L2)ネットワークを使用している(WAN経由など)場合はディスカバリアプレットが使用できません。 しかしCVMにIPv4アドレスが割り当てられていれば、(ディスカバリアプレットを使わずに)直接Foundationサービスに接続することができます。

直接接続する際には、 <CVM_IP>:8000/gui/index.htmlをブラウズします

インプット

Foundationには、以下の入力設定があります。 典型的な導入例では、1ノードあたり3つのIP(ハイパーバイザー、CVM、リモート管理(IPMI、iDRACなど))が必要となります。 さらに、各ノードに対し、クラスタとデータサービスIPアドレスを設定することを推奨します。

  • クラスタ
    • クラスタ名
    • IP*
    • NTP*
    • DNS*
  • CVM
    • CVM毎のIP
    • Netmask
    • Gateway
    • メモリ
  • ハイパーバイザー
    • ハイパーバイザーホスト毎のIP
    • Netmask
    • Gateway
    • DNS*
    • ホスト名のプリフィックス
  • IPMI*
    • ノード毎のIP
    • Netmask
    • Gateway

注意: (*) が付いた項目はオプションですが、設定することを強く推奨します

システムのイメージングと導入

最初に、ディスカバリアプレット経由で、FoundationUIに接続します。(同じL2にあればノードIPの入力などは不要です)

Foundation - Discovery Applet
Foundation - ディスカバリアプレット

目的とするノードが見つからない場合は、同じL2ネットワーク上に存在するかどうかを確認してください。

選択したノードのFoundationインスタンスに接続すると、FoundationUIが表示されます:

Foundation - Discovery Page
Foundation - ディスカバリページ

ここでは、検出した全てのノードとシャーシが表示されます。 必要なノードをクラスタから選択し「Next(次へ)」をクリックします。

Foundation - Node Selection
Foundation - ノードの選択

次のページで、クラスタとネットワーク情報を入力します:

Foundation - Cluster Information
Foundation - クラスタ情報
Foundation - Network Applet
Foundation - ネットワーク情報

詳細の入力が完了したら「Next(次へ)」をクリックします。

次のページで、ノードの詳細とIPアドレスを入力します:

Foundation - Node Setup
Foundation - ノード設定

必要に応じてホスト名とIPアドレスを上書きします:

Foundation - Hostname and IP
Foundation - ホスト名とIP

「Validate Network(ネットワークの検証)」をクリックし、ネットワーク設定を確認して次に進みます。 ここでは、IPアドレスに重複がないかを検証し、接続性を確認します。

Foundation - Network Validation
Foundation - ネットワークの確認

ネットワークの検証が正常に終了したら、次に必要なインストーラーイメージを選択します。

CVM上の現状のAOSを新しいバージョンにアップグレードするためには、ポータルからダウンロードし、tarball(.tar.gz ファイル)をアップロードします。 必要なAOSイメージを入手したらハイパーバイザーを選択します。

AHVの場合、そのイメージはAOSイメージに含まれています。 その他のハイパーバイザーの場合には、必要なハイパーバイザーのインストーラーイメージをアップロードする必要があります。 注意: AOSとハイパーバイザーのバージョンの組み合わせが、互換表 (リンク) に掲載されたものであることを確認してください。

必要なイメージが揃ったら、「Create(作成)」をクリックします:

Foundation - Select Images
Foundation - イメージの選択

イメージングが不要な場合、「Skip(スキップ)」をクリックすれば、イメージング工程を省略することができます。これによってハイパーバイザーあるいはNutanixクラスタが再イメージされることはありませんが、クラスタの設定(IPアドレスなど)は必要です。

次にFoundationは(必要に応じて)イメージングを行い、クラスタ作成プロセスに進みます。

Foundation - Cluster Creation Process
Foundation - クラスタ作成プロセス

作成が成功すると、完了スクリーンが表示されます:

Foundation - Cluster Creation Complete
Foundation - クラスタ作成完了画面

これでCVMまたはクラスタIPにログインし、Nutanixプラットフォームを利用できるようになりました!

ドライブの分割

本セクションでは、様々なストレージデバイス(パフォーマンス - NVMe/SSD、キャパシティ - SSD/HDD)がどのように分割および、パーティショニングされ、Nutanixプラットフォームで利用されるかを説明します。 注意: 説明で使用されているキャパシティは、10進法のギガバイト (GB) ではなく、すべて2進法のギガバイト (GiB) を使って表現されています。 また、ファイルシステムのためのドライブのフォーマッティングや、関連するオーバーヘッドも考慮に入れた値になっています。

パフォーマンス デバイス

パフォーマンス デバイスは、ノードで最もパフォーマンスの高いデバイスです。 これらは、NVMe、またはNVMeとSSDデバイスの混合で構成できます。 前述したいくつかの重要な情報が保存されます:

  • Nutanix Home(CVMコア)
  • メタデータ(Cassandra / AESストレージ)
  • OpLog(永続的書き込みバッファ)
  • エクステントストア(永続的ストレージ)

以下に示す図は、Nutanixノードのパフォーマンスデバイスの分割例です:

Performance Drive Breakdown
パフォーマンスドライブの分割

図の大きさは、実際の値の大きさと一致しているわけではありません。  残りの(Remaining)GiBキャパシティは、上から下方向に数値を計算していった残りで見積ります。  例えば、OpLogで使用可能な残りのGiBを計算する場合は、フォーマット済みSSDのキャパシティから、Nutanix HomeとCassandraのキャパシティを差し引いた値になります。

Nutanix Homeは可用性確保のため最初の2つのSSDにミラーされ、そして2つのデバイスに60GiBを予約します。

AOS 5.0の場合、Cassandraは、各ノードのSSD間(現在、最大4つまで)で、1つのSSDあたり15GiBの初期予約領域(メタデータの容量が増加した場合、一部のStargate SSDを使用可能)と一緒に共有されます。 デュアルSSDシステムの場合、メタデータはSSD間でミラーされます。 SSDあたりのメタデータ予約領域は15GiBとなります(デュアルSSDは30GiB、4つ以上のSSDの場合は60GiB)。

AOS 5.0より前は、Cassandraはデフォルトで最初のSSDにあり、そのSSDに障害発生した場合はCVMが再起動されてCassandraストレージは2番目にあるものになります。 この場合のSSDあたりのメタデータ予約は、最初の2つのデバイスでは30 GiBです。

OpLogはすべてのSSDデバイスに分散され、1ノードあたり最大12までとなります (Gflag: max_ssds_for_oplog)。 NVMe デバイスが使用可能な場合、OpLogはSATA SSDではなくそちら(NVMe デバイス)に配置されます。

ディスクあたりのOpLog予約は、次の式を使用して計算できます: MIN(((Max cluster RF/2)*400 GiB)/ numDevForOplog), ((Max cluster RF/2)*25%) x Remaining GiB)。 注意: リリース 4.0.1から、OpLogのサイズが動的に決定されるようになり、エクステントストアも動的に拡張されるようになりました。  ここで示す値は、OpLogが完全に使用されている状況を前提としています。

例えば、1TBのSSDデバイスが8つあるRF2(FT1)クラスタの結果は次のようになります:

  • MIN(((2/2)*400 GiB)/ 8), ((2/2)*25%) x ~900GiB) == MIN(50, 225) == デバイスごとにOplogのために50GiB予約

RF3(FT2)クラスタでは下記のようになります:

  • MIN(((3/2)*400 GiB)/ 8), ((3/2)*25%) x ~900GiB) == MIN(75, 337) == デバイスごとにOplogのために75GiB予約

1TBの4つのNVMeデバイスと8つのSSDデバイスによるRF2(FT1)クラスタの場合、結果は下記のようになります:

  • MIN(((2/2)*400 GiB)/ 4), ((2/2)*25%) x ~900GiB) == MIN(100, 225) == デバイスごとにOplogのために100GiB予約

エクステントストアの容量は、他のすべての予約が計算された後の残り容量になります。

HDDデバイス

HDDデバイスは、基本的に大容量ストレージとして利用されるため、その分割はよりシンプルになります:

  • Curator予約領域(Curatorストレージ)
  • エクステントストア(永続的ストレージ)
HDD Drive Breakdown
HDDドライブの分割

Book of Prism

Prism – プリズム – 名詞 - コントロールプレーン
データセンター運用をワンクリックで可能にするインターフェイス

洗練され、愛着を感じることができる直観的な製品を構築することは、Nutanixプラットフォームの核心であり、私達はそれに真剣に取り組んでいます。 本セクションでは、Nutanixのデザインメソドロジーとその適用について説明します。

また、NutanixのVisioのステンシルはこちらからダウンロードいただけます: http://www.visiocafe.com/nutanix.htm

Prismのアーキテクチャー

Prismは分散リソース管理プラットフォームであり、ローカルとクラウドのどちらでホストされているかにかかわらず、 ユーザーがNutanix環境全体のオブジェクトやサービスを管理およびモニターすることができます。

これらの機能は、以下2つの主要なカテゴリに分けられます:

  • インターフェイス
    • HTML5 UI、REST API、CLI、PowerShell コマンドレットなど
  • 管理
    • ポリシー定義とコンプライアンス、サービス設計とステータス、分析とモニタリング

以下は、Nutanixプラットフォームの一部としてのPrismを概念的に図示したものです:

High-Level Prism Architecture
Prismアーキテクチャー概観

Prismは、2つの主要コンポーネントに分けられます:

  • Prism Central (PC)
    • 複数のNutanix Clusterを、1つの集中管理インターフェイスから管理するためのマルチクラスタマネージャー。 Prism Centralは、AOS Clusterに追加導入し稼動することが可能な、オプションのソフトウェアアプライアンス (VM) です。
    • 1対多のクラスタマネージャー
  • Prism Element (PE)
    • 単一のクラスタの管理と運用のためのローカルクラスタマネージャー。全てのNutanix Clusterに、Prism Elementが組み込まれています。
    • 1対1のクラスタマネージャー

以下は、Prism CentralとPrism Elementの関係を概念的に図示したものです:

Prism Architecture
Prismアーキテクチャー
プロからのヒント

大規模な環境、あるいは分散環境(例えば1クラスタ以上あるいは複数のサイト)に導入する場合、運用のシンプル化を図るため、Prism Centralを使用し、 全てクラスタやサイトへの対応を1つの管理UIから実施できるようにすることを推奨します。

Prismのサービス

Prismのサービスは、HTTPリクエストに対応する特定のPrismリーダーと連携しながら、全てのCVM上で動作します。 「リーダー」を持っている他のコンポーネントと同様、Prismリーダーに障害が発生した場合、新しいリーダーが選定されます。 PrismリーダーではないCVMがHTTPリクエストを受け取ると、当該リクエストはPrismリーダーに、HTTPレスポンスステータスコード301を使用して、恒久的にリダイレクトされます。

以下は、PrismのサービスとHTTPリクエストの処理を概念的に図示したものです:

Prism Services - Request Handling
Prismサービス - リクエスト処理
Prismのポート

Prismは、ポート80と9440を使用します。HTTPトラフィックがポート80に到達した場合、ポート9440のHTTPS側にリダイレクトされます。

クラスタの外部IPを使用する場合(推奨)、同IPは常に現在のPrismリーダーによってホストされます。 Prismリーダーに障害が発生した場合、クラスタIPは新たに選択されたPrismリーダーが引継ぎ、gratuitous ARP(gARP)は、古くなったARP(stale ARP)のキャッシュ エントリーをクリアするために使用されます。 本シナリオの場合、常にクラスタIPがPrismのアクセスに使用され、既にPrismリーダー内に存在するため、リダイレクトする必要がありません。

プロからのヒント

最新のPrismリーダーを特定するためには、いずれかのCVMで ’curl localhost:2019/prism/leader’を実行します。

認証とアクセス制御(RBAC)

認証

Prismは現在、以下の認証プロバイダーとのインテグレーションをサポートしています:

  • Prism Element (PE)
    • ローカル
    • Active Directory
    • LDAP
  • Prism Central (PC)
    • ローカル
    • Active Directory
    • LDAP
    • SAML認証 (IDP)
SAMLと2要素認証(2FA)

SAML認証により、PrismはSAML準拠の外部IDプロバイダー(IDP、例えばOkta、ADFSなど)と統合できます。

これにより、プロバイダーサポートするPrismへのログインユーザーで、多要素認証(MFA)や2要素認証(2FA)機能を活用できます。

アクセス制御

近日公開

ナビゲーション

Prismの使用方法は極めて簡単ですが、いくつかの主要なページとその基本的な使用法をカバーしておきます。

Prism Central(導入されている場合)には、設定中に指定されたIPアドレス、または対応するDNSエントリーを使ってアクセスすることができます。 Prism Elementには、Prism Central(特定のクラスタをクリック)か、いずれかのNutanix CVMまたはクラスタIP(推奨)からアクセスできます。

ページがロードされると、ログインページが表示され、PrismまたはActive Directoryの認証情報を使ってログインすることができます。

Prismログインページ

ログインに成功すると、ダッシュボードページに遷移し、Prism Centralが管理している(複数の)クラスタ、またはPrism Elementが管理しているローカルクラスタに関する概要情報が表示されます。

Prism CentralとPrism Elementについては、以下のセクションで詳しく解説します。

Prism Central

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

Prism Central - Dashboard
Prism Central - ダッシュボード

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

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

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

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

Prism Central - Hamburger Menu
Prism Central - Hamburger

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

Prism Central - Menu Bar
Prism Central - Menu Bar

検索

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

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

Prism Central - Search
Prism Central - Search
検索のセマンティクス

PCの検索では、多くのセマンティクスを利用できます。例えば、次のようなものです:

ルール
Entity type vms
Entity type + metric perspective (io, cpu, memory) vms io
Entity type + alerts vm alerts
Entity type + alerts + alert filters vm alerts severity=critical
Entity type + events vm events
Entity type + events + event filters vm events classification=anomaly
Entity type + filters (both metric and attribute) vm “power state”=on
Entity type + filters + metric perspective (io, cpu, memory) vm “power state”=on io
Entity type + filters + alerts vm “power state”=on alerts
Entity type + filters + alerts + (alert filters) vm “power state”=on alerts severity=critical
Entity type + filters + events vm “power state”=on events
Entity type + filters + events + event filters vm “power state”=on events classification=anomaly
Entity instance (name, ip address, disk serial etc) vm1, 10.1.3.4, BHTXSPWRM
Entity instance + Metric perspective (io, cpu, memory) vm1 io
Entity instance + alerts vm1 alerts
Entity instance + alerts + alert filters vm1 alerts severity=critical
Entity instance + events vm1 events
Entity instance + events + event filters vm1 events classification=anomaly
Entity instance + pages vm1 nics, c1 capacity
Parent instance + entity type c1 vms
Alert title search Disk bad alerts
Page name search Analysis, tasks

上記はセマンティクスのほんの一部に過ぎず、慣れるための最善の方法は実行してみることです!

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ダッシュボードの例です。

Prism Element - Dashboard
Prism Element ‐ ダッシュボード
キーボードのショートカット

アクセスの良さと使いやすさがPrismの重要な構成概念です。エンドユーザーの操作をよりシンプル化し、キーボードから全てを操作できるようにショートカットが用意されています。

以下にキーショートカットの一部を示します:

ビューの変更(ページコンテキストの切り替え):

  • O – オーバービュー (Overview)
  • D – ダイアグラムビュー (Diagram View)
  • T – テーブルビュー (Table View)

アクティビティとイベント:

  • A – アラート
  • P – タスク

ドロップダウンおよびメニュー(矢印キーで選択)

  • M – メニューのドロップダウン
  • S – 設定(歯車アイコン)
  • F – 検索バー
  • U – ユーザードロップダウン
  • H – ヘルプ

使用方法とトラブルシューティング

次のセクションでは、典型的なPrismの使用方法と、一般的なトラブルシューティング方法について説明します。

異常検出(Anomaly Detection)

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

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

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

Prism - Anomaly Chart
Prism - Anomaly Chart

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

Prism - Anomaly Band
Prism - Anomaly Band

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

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

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

Prism - Anomaly Event
Prism - Anomaly Event

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

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

  • 毎日(Daily)
  • 毎週(Weekly)
  • 毎月(Monthly)

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

Prism - Anomaly Custom Event
Prism - Anomaly Custom Event
異常検出アルゴリズム

Nutanixは「Generalized Extreme Studentized Deviate検定」と呼ばれるバンドを決定する手法を利用しています。 これについて簡単に考えると、アルゴリズムによって確立された下限と上限の間にある、値の信頼区間に似ています。

アルゴリズムでは、季節性と期待されるバンドを計算するために、3倍の粒度(毎日、毎週、毎月など)が必要です。 例えばそれぞれの季節性に適応するには、以下の量のデータが必要になります:

  • Daily: 3 日間
  • Weekly: 3 週間 (21 日)
  • Monthly: 3 か月間 (90 日)

Twitterには、彼らがこれをどう活用しているかについての良いリソースがあり、ロジックをさらに詳しく説明しています: LINK

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

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

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

Prism - Settings - Upgrade Software
Prism – 設定 - ソフトウェアのアップグレード

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

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

Upgrade Software - Main
ソフトウェアアップのグレード - メイン
CVMからのソフトウェアのアップロード

場合によっては、ソフトウェアをダウンロードしたうえで、CVM自身からアップロードすることができます。 私は自分の環境で、ビルドをローカルダウンロードしてCVMにアップロードしたい場合に使用します。

最初にCVMにSSH接続し、Prismリーダーを見つけます:

curl localhost:2019/prism/leader && echo

PrismリーダーにSSH接続して、ソフトウェアバンドルとメタデータのJSONファイルをダウンロードします。

以下のコマンドを実行して、ソフトウェアをPrismに「アップロード」します:

ncli software upload file-path=<PATH_TO_SOFTWARE> meta-file-path=<PATH_TO_METADATA_JSON> software-type=<SOFTWARE_TYPE>

以下は、Prism Central の例を示します:

ncli software upload file-path=/home/nutanix/tmp/leader-prism_central.tar meta-file-path=/home/nutanix/tmp/leader-prism_central-metadata.json software-type=prism_central_deploy

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

Upgrade Software - Upload
ソフトウェアのアップグレード – アップロード

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

Upgrade Software - Upgrade Validation
ソフトウェアのアップグレード - アップグレードの検証

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

Upgrade Software - Confirm Upgrade
ソフトウェアのアップグレード - アップグレードの確認

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

Upgrade Software - Execution
ソフトウェアのアップグレード ‐ 実行

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

Upgrade Software - Complete
ソフトウェアのアップグレード - 完了
注意

現状のPrismリーダーでは、アップグレードの最中、Prismのセッションが一瞬切断されます。 但し、これによってVMやサービスが影響を受けることはありません。

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

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

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

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

Upgrade Hypervisor - Main
ハイパーバイザーのアップグレード – メイン

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

Upgrade Hypervisor - Upgrade Validation
ハイパーバイザーのアップグレード – アップグレードの検証

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

Upgrade Hypervisor - Confirm Upgrade
ハイパーバイザーのアップグレード – アップグレードの確認

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

Upgrade Hypervisor - Pre-upgrade Checks
ハイパーバイザーのアップグレード – プリアップグレードチェック

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

Upgrade Hypervisor - Execution
ハイパーバイザーのアップグレード – 実行

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

プロからのヒント

クラスタ全体のアップグレードステータスは、いずれかのNutanix CVMで、'host_upgrade --status' を実行することで確認できます。各ホストの詳細なステータスは、各CVMの ~/data/logs/host_upgrade.out にログされています。

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

Upgrade Hypervisor - Complete
ハイパーバイザーのアップグレード – 完了

クラスタの拡張(ノードの追加)

Cluster Expansion
Cluster Expansion

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

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

Add Node - Discovery
ノードの追加 ‐ 検知

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

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

Hardware Page - Expand Cluster
ハードウェア (Hardware) ページ ‐ クラスタの拡張

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

Gear Menu - Expand Cluster
歯車 (Gear) アイコンのメニュー ‐ クラスタの拡張

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

Expand Cluster - Host Selection
クラスタの拡張 - ホストの選択

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

Expand Cluster - Host Configuration
クラスタの拡張 ‐ ホストの設定

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

Expand Cluster - Execution
クラスタの拡張 ‐ 実行

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

Expand Cluster - Execution
クラスタの拡張 – 実行

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

Expand Cluster - Execution
クラスタの拡張 – 実行

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

Expand Cluster - Execution
クラスタの拡張 – 実行

I/Oメトリクス

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

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

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

VM Page - Details
VMページ - 詳細

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

VM Page - I/O Metrics Tab
VMページ - I/Oメトリクスタブ

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

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

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

I/O Metrics - Latency Plot
I/Oレイテンシー - レイテンシー―のプロット

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

I/O Metrics - Latency Plot
I/O メトリクス - レイテンシー―のプロット

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

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

I/O Metrics - I/O Size histogram
I/Oメトリクス - I/Oサイズヒストグラム

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

I/O Metrics - Read I/O Size histogram
I/Oメトリクス - READ I/Oサイズヒストグラム

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

I/O Metrics - Write I/O Size histogram
I/Oメトリクス - WRITE I/Oサイズヒストグラム
プロからのヒント

数値にスパイクが見られる場合には、まずI/Oサイズを確認します。大きなI/O(64Kから1MB)は、一般的に小さなI/O(4Kから32K)よりも大きなレイテンシーを示します。

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

I/O Metrics - Latency histogram
I/Oメトリクス - レイテンシーヒストグラム

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

I/O Metrics - Read Latency histogram
I/Oメトリクス - READレイテンシーヒストグラム

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

I/O Metrics - Read Source SSD
I/Oメトリクス - SSDがREADソース

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

I/O Metrics - Read Source DRAM
I/Oメトリクス - DRAMがREADソース

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

I/O Metrics - Read Latency histogram
I/Oメトリクス - READレイテンシーヒストグラム

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

I/O Metrics - Write Latency histogram
I/Oメトリクス - WRITEレイテンシーヒストグラム
プロからのヒント

READレイテンシーにスパイクが見られ、かつI/Oサイズが大きくない場合は、READ I/Oリクエストに対する結果がどこから返されているかを確認します。最初にHDDから読み込む場合は、DRAMキャッシュよりも大きなレイテンシーを示しますが、一度キャッシュに入れば、以降のREADはDRAMに対してヒットするようになり、レイテンシーが改善されます。

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

I/O Metrics - RW Random vs. Sequential
I/Oメトリクス - ランダムRW 対 シーケンシャルRW

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

キャパシティプラニング

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

Prism Central - Capacity Planning
Prism Central – キャパシティプラニング

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

Prism Central - Capacity Planning - Recommendations
Prism Central – キャパシティプラニング – 提案

クロスプレイ(X-Play)

日常的な活動を考えると、より多くのことを自動化できます。 私達は日常生活の中でこれを常にルーチンで行っており、テクノロジーによって他の分野と同様のことができます。 Prism ProのX-Playでは、Prismによって一般的なアクティビティのセットを自動化できます。 製品に飛び込む前に、まずは、何をしようとしているのかを説明します。

イベント駆動型の自動化は、以下のように動作します:

イベント → ロジック → アクション

このシナリオでは、一連のアクションまたは一連のアクションをトリガーする、ある種のイベント(または連なっているイベント)が発生します。 これの良い例は、IFTTT(「if this then that」の略語から)であり、イベントを受け取り、いくつかのロジックを適用し、その後いくつかのアクションを実行します。

例えば、家を出るときには家の明かりを消します。 イベント(例えば、家を出る、デバイスが存在しない)をプログラムして、システムがすべてのライトを自動的にオフにするようにトリガーできれば、私たちの生活がはるかに簡単になります。 私は個人的にこれを家中で使用しているので、生活をより簡単にし、他のより高い影響力のアクティビティに集中することができます。

これをIT運用のアクティビティと比較すると、同様のパターンが見られます。 イベントが発生(例えば、VMがより多くのディスク領域を必要とする)した際、次に一連のアクション(例えば、チケットの作成、ストレージの追加、チケットのクローズなど)を実行します。 これらの反復的なアクティビティは、自動化によって付加価値を付け、より有益なアクティビティに集中できるようにする完璧な例です。

X-Playを使用すると、一連のイベントやアラートを取得し、システムがそれらを捉えて一連のアクションを実行できるようになります。

開始するには、Prism Centralの「Operations」の下にある「Plays」セクションに移動します:

X-Play - Navigation
X-Play - Navigation

これにより、メインのX-Playページが開きます:

X-Play - Playbooks Overview
X-Play - Playbooks Overview

「Get Started」をクリックして現在のプレイを表示するか、新しいものを作成します:

X-Play - Playbooks
X-Play - Playbooks

ここから、最初にトリガーを定義して、新しいプレイブックを作成できます:

X-Play - Trigger
X-Play - Trigger

以下に、カスタムアラートをもとにしたトリガーの例を示します:

X-Play - Trigger - Custom Alert
X-Play - Trigger - Custom Alert

トリガーを定義したら、一連のアクションを指定します。以下に、いくつかのサンプルアクションを示します:

X-Play - Actions
X-Play - Actions

アクションの詳細を入力します。これは、REST APIコールのサンプルを示します:

X-Play - Sample REST Action
X-Play - Sample REST Action
REST APIアクションと外部システム

X-Playは、Eメールの送信、Slackメッセージの送信など多くのデフォルトアクションを提供します。REST APIコールの実行なども同様です。

これは、CMDBやチケット管理、自動化ツールのような外部システムとのインターフェイスを考えるときに重要です。 REST APIアクションを使用することは、チケットの作成や解決、ワークフロー開始などのインターフェイスになります。 これは、すべてのシステムを同期させることができるため非常に強力なオプションです。

エンティティやイベント固有の詳細については、「parameters」変数を使用して取得できます:

X-Play - Action Parameters
X-Play - Action Parameters

完了するとプレイを保存でき、定義どおりに実行開始されます。

以下は、複数のアクションが実行されるプレイのサンプルを示します:

X-Play - Sample Playbook
X-Play - Sample Playbook

Playsタブには、プレイの実行時間とステータスが表示されます:

X-Play - Plays Executed
X-Play - Plays Executed

すべてを自動化することを、忘れずに!

APIとインターフェイス

Prismが、シンプルで使いやすい管理インターフェイスを提供するためには、HTML5 UIが不可欠です。 しかし、自動化のためのAPIの提供もまた重要となります。 Nutanixプラットフォームにプログラムインターフェイス機能を提供するため、Prism UIで可能な操作は、REST APIを使っても実装が可能になっています。 お客様やパートナーは、APIを使って自動化を行なったり、サードパーティツールと連携させたり、あるいは独自のUIを作成することも可能です。 以下のセクションでは、インターフェイスと使用例について説明します。

動的な、あるいは「ソフトウェア デファインド」な環境に不可欠なものとして、Nutanixでは、様々なインターフェイスを提供することで、シンプルなプログラミングとインターフェイス機能を実現します。主なインターフェイスには、次のようなものがあります:

  • REST API
  • CLI ‐ ACLIおよびNCLI
  • スクリプトインターフェイス
developer.nutanix.com

API やサンプルコードの詳細については、developer.nutanix.comをご覧ください!

インターフェイスで中心となるのがREST APIであり、オーケストレーションや自動化ツールから、Prism UIとまったく同様な形で該当機能やデータを扱ってNutanixを制御することができます。 REST APIを使用することで、SaltStack、PuppetやvRealize Operations、System Center Orchestrator、Ansibleなどのツールで、容易にNutanixのカスタムワークフローを構築できます。 どんなサードパーティでも、REST APIを使うことで独自のUIを開発し、REST経由でNutanixデータを投入することができます。

以下は、Nutanix REST APIエクスプローラで、開発者がAPIで利用できるスニペットと必要なデータフォーマットを図示したものです:

Prism REST API Explorer
Prism REST APIエクスプローラ

演算子は、詳細とRESTコールの例を表示するよう展開できます。

Prism REST API Sample Call
Prism REST APIのコール例
API認証スキーム

4.5.xの時点で、クライアントおよびHTTPコールの認証には、HTTPS経由の基本認証が使用されています。

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以降)の右上のドロップダウンリストから、直接ダウンロードすることが可能です。

Prism のコマンドレット Installer Link
Prism にあるコマンドレットインストーラーのリンク
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

Book of AOS

Acropolis – アクロポリス – 名詞 – データプレーン
ストレージ、サーバー、仮想化プラットフォーム

AOSのアーキテクチャー

Acropolis Operating System(AOS)は、プラットフォーム上で実行されているワークロードやサービスによって利用される中核的な機能を提供します。 これには、ストレージサービス、アップグレードといったものが含まれますが、これらに限定されません。

この図は、様々なレイヤーにおけるAOSの概念的性質のイメージを示しています:

High-level AOS Architecture
High-level AOS Architecture

Nutanixでは、全てを分散するという設計方針に基づき、この考え方を仮想化とリソース管理の分野にまで拡張しました。 AOSは、ワークロードやリソースを管理、プロビジョニング、運用するためのバックエンド サービスです。 目的は、稼動しているワークロードをNutanixがサポートするリソース(ハイパーバイザー、オンプレミスやクラウドなど)から分離して抽象化し、運用する1つの「プラットフォーム」を提供しようというものです。

これによって、ワークロードをハイパーバイザー、クラウド プロバイダーやプラットフォーム間でシームレスに移動させることが可能となります。

VM管理の対象となるハイパーバイザー

AOS 4.7現在、VM管理機能がサポートするハイパーバイザーは、AHVとESXiに限定されていますが、将来的には拡大される予定です。 但し、Volumes APIとREADオンリーの操作は、現在でも全てがサポートされています。

Acropolisサービス

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

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

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

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

Acropolis Services
Acropolisサービス

Dynamic Scheduler

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

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

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

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

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

AOS Dynamic Scheduler
AOS Dynamic Scheduler

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

リソース最適化のための異なるアプローチ

既存のスケジューリングや最適化のためのプラットフォーム(VMware DRS、Microsoft PRO)を見ると、 全てワークロードのバランシングや、クラスタリソースに対するVMの配置平滑化に焦点を当てています。 注意: バランスの悪さをいかに積極的に解消するかは、バランシングの設定によります(例えば、manual -> none, conservative -> some, aggressive -> more)。

例えば、クラスタ内に3つのホストがあり、それぞれの使用率が50%、5%、5%だと想定します。典型的なソリューションは、ワークロードをリバランスして、それぞれが ~20%となるように調整します。なぜでしょうか?

私達が行おうとしているのは、リソースの競合が発生しないようにすることであり、非対称性を解消することではありません。リソースの競合がなければ、ワークロードを「バランシング」する積極的な理由は存在しません。実際に、ワークロードの不必要な移動を行おうとすると、必要な追加処理(メモリの転送、キャッシュの再ローカライズ等)が発生し、リソースを消費することになります。

AOS Dynamic Schedulerでは、この問題に対応すべく、非対称性の発生ではなく想定したリソース競合が発生した場合に限りワークロードを移動させています。 注意: DSFは、ホットスポットの発生を回避したり、リビルドの速度を上げたりするために、データをクラスタ全体に均一に分散させるという異なる方法を取っています。 DSFに関するより詳細な内容については、「ディスクバランシング」セクションをご覧ください。

ADSは起動時に、クラスタ全体でVM初期プレースメントのバランシングを行います。

プレースメントの決定

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

  • サーバーの使用状況
    • 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)
    • 認可されたユーザーが回復力と冗長性のあるデータにアクセスできるようにする

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

Security Layers
Security Layers

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

システムと構成
一覧:
  • 既知の脆弱性へのパッチ適用と削除
  • 強力なパスワードを強制し、デフォルトのアカウントを削除する
  • 権限とユーザー特権を構成する
  • 使用していないポートやプロトコルを閉じる
  • 自動化し、ベースラインを確保する

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

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

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

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

データ
一覧:
  • データへの安全なアクセス制御
  • 常にバックアップを取得する
  • データの暗号化と鍵の安全な管理

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

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

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

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

ネットワーク
一覧:
  • 信頼できる、または信頼できないネットワークをセグメント化する
  • 境界およびセグメント間のファイアウォール
  • IDPSを活用した異常検出

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

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

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

認証と認可
一覧:
  • 可能な場合はMFAや2FAを使用する
  • 詳細な権限を使用する

認証とは、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はデフォルトで有効化されるので、有効化のための作業は不要です。

アドホックなSCMAの実行

SCMAは、設定済みスケジュール(デフォルト:一時間毎)に従って実行されますが、オンデマンドで実行することも可能です。SCMAツールは、以下のコマンドを使ってCVMから実行することができます。

1台のCVMでの実行

sudo salt-call state.highstate

すべてのCVMでの実行

allssh "sudo salt-call state.highstate"

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
カスタムログインバナー

デフォルトでは、DoD同意内容バナーが使用されます。カスタムのバナーを使用したい場合は、以下の手順に従います(いずれのCVMについてもNutanixユーザーとして実行)。

  1. 既存バナーのバックアップを取得
  2. sudo cp -a /srv/salt/security/KVM/sshd/DODbanner /srv/salt/security/KVM/sshd/DODbannerbak

  3. viを使って既存バナーを編集
  4. sudo vi /srv/salt/security/KVM/sshd/DODbanner

  5. 上記手順を全てのCVMに対して実施するか、または変更済みバナーを他の全てのCVMに対してSCP実行
  6. 上記コマンドを使用してバナーを有効化

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から確認することができます:

Cluster Lockdown Menu
クラスタ ロックダウンメニュー

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

Cluster Lockdown Page
クラスタ ロックダウンページ

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

Cluster Lockdown - Add Key
クラスタ ロックダウン - キーの追加
SSHキーの処理

SSHキーを生成するためには、次のコマンドを実行します:

ssh-keygen -t rsa -b 2048

これで2つのキーペアが作成され、2つのファイルが生成されます:

  • id_rsa(プライベートキー)
  • id_rsa.pub(パブリックキー: クラスタにキーを追加する場合に使用します)

キーを作成し、これを使ってアクセスできることが確認されれば、「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(保存データの暗号化)」を選択して確認できます。 ここで現在の状況確認と、暗号化の設定(現在有効化されていない場合)を行うことができます。

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

Data Encryption - Enabled (cluster level)
データの暗号化 - クラスタ単位で有効化 (cluster level)

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

Data Encryption - Enabled (container level)
データの暗号化 - コンテナ単位で有効化

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

Data Encryption - Configure
データの暗号化 - 設定

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

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

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

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

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

Data Encryption - Transform Application
データの暗号化 - アプリケーションによるデータ変換
暗号化とデータ効率

重複排除と圧縮を行った後に暗号化を行うため、これらの手段によるスペースの節約状態はそのまま維持されます。 簡単に言えば、重複排除と圧縮の比率は、データを暗号化してもしなくてもまったく同じだということです。

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

SED Based Encryption

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

Data Encryption - Overview
データ暗号化 - 概要

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オプションを説明します。

Data Encryption - Key Management
データ暗号化 - キー管理

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

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

Data Encryption - Configure
データ暗号化 - 設定

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

キーのバックアップとローテーション

暗号化を有効にした場合、データ暗号化キー (DEK) のバックアップを取っておくことをお勧めします。 バックアップを取った場合、強力なパスワードを設定し、安全な場所に保管するようにしてください。

KEKとMEKのローテーション(キー更新)をシステムで行うことが可能です。 マスターキー (MEK) を毎年自動的にローテーションするほか、必要に応じていつでもローテーションすることができます。 ノードを追加または削除した場合も、マスターキーのローテーションが行われます。

分散ストレージ ファブリック

分散ストレージ ファブリック(DSF)は、ハイパーバイザーから集中ストレージアレイのように見えますが、全てのI/Oをローカルで処理することで最大のパフォーマンスを発揮します。 ノードがどのように分散システムを形成するかについての詳細は、次のセクションで説明します。

データ ストラクチャー

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 vDiskサイズ

DSF/Stargate側でvDiskのサイズに理論的な制限を加えることはありません。 AOS 4.6では、vDiskサイズは64ビット符号付整数を使ったバイト単位で表現されていました。 つまり、論理的なvDiskの最大サイズは、2^63-1 または 9E18 (9 Exabytes) となります。 この値を下回る制限があるとすれば、それはESXiの最大vmdkサイズなど、クライアント側の問題になります。

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

High-level Filesystem Breakdown
ファイルシステム構成概観
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に設定できます。

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

Low-level Filesystem Breakdown
ローレベルのファイルシステム構成

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

Graphical Filesystem Breakdown
ファイルシステムの構成図

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パスは、以下のコンポーネントで構成されています:

DSF I/O Path
DSF I/Oパス

通信とI/O

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

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

High-level I/O Path
High-level I/O Path

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

Stargate - Device I/O Path
Stargate - Device I/O Path

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

High-level I/O Path - BlockStore
High-level I/O Path - BlockStore

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

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

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

High-level I/O Path - RDMA
High-level I/O Path - RDMA

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

  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パスは、以下の大まかなコンポーネントで構成されます:

DSF I/O Path
DSF I/O Path

*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は、ハッシュスキームを使用して採取されるため、コンテンツキャッシュ内のフィンガープリントを元に重複排除を行うことができます。
動的なOpLogサイジング

Oplogは共有リソースですが、それぞれのvDiskが平等に利用できるように、vDisk単位での割り当てが行われます。 AOS 5.19より前は、OpLogのサイズはvDiskごとに6GBに制限されていました。 AOS 5.19以降は、個々のvDiskのOpLogは、IOパターンの要求に従ってノードごとに使用されるOpLogインデックスメモリの上限まで、6GBを超えて拡張し続けることができます。 この設計上の決定により、I/Oの観点でアクティブなvDiskが少ない仮想マシンがある場合、アクティブでない他のvDiskを費やして、必要に応じてOpLogを拡張できるという柔軟性が得られます。

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

vDiskに対する1.5MB以上の未処理I/Oが残っている場合、WRITE I/Oはシーケンシャル処理であると見なされます(AOS 4.6の時点)。 この条件に該当する場合、データは既に整列済みの大きなかたまりとなっており、データを融合させることで生じるメリットがないため、OpLogを経由することなく、エクステントストアに対して直接I/Oが行われます。

これは次の Gflagによって制御されます:: vdisk_distributed_oplog_skip_min_outstanding_write_bytes.

大きなサイズ(例えば > 64K)を含む、その他すべてのI/OはOpLogによって処理されます。

自律型エクステントストア(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

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

DSF Unified Cache
DSFユニファイド キャッシュ
キャッシュの粒度とロジック

データは、4Kの粒度でキャッシュに格納され、全てのキャッシングはリアルタイムで行われます(例えば、データをディレイ処理したり、バッチ処理でデータをキャッシュに格納したりするようなことはありません)。

それぞれのCVMには、CVMがホストする(例えば同じノードで稼動するVMのような)独自に管理されたvDiskのためのローカルキャッシュがあります。vDiskがクローン(新しいクローンやスナップショットなど)されると、それぞれの新しいvDiskに個別にブロックマップが生成され、元のvDiskは変更不可とマークされます。これによって各CVMは、キャッシュコヒーレンシを保ちながら、元となるvDiskのキャッシュコピーをそれぞれに持つことが可能になります。 

上書きが発生した場合、それは、VM自身のブロックマップにある新しいエクステントにリダイレクトされます。

単一vDiskのシャーディング

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

single vdisk controller
単一のvDiskコントローラー

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

vdisk sharding
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ノードクラスタでのグローバルメタデータの挿入/更新処理について示します:

Cassandra Ring Structure

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

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

Cassandra スケールアウト

データ保護

ビデオによる解説はこちらからご覧いただけます: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が発生しない場合でも一貫性を保つよう、データは継続的に監視されます。 ストレージのスクラブ処理は、エクステントグループを継続的にスキャンし、ディスクの使用率が低い時にチェックサムの検証を実施します。 これによって、ビットやセクターの毀損の発生からデータを保護します。

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

DSF Data Protection
DSF データ保護

可用性ドメイン

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

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

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

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

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

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

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

Rack Configuration
Rack Configuration

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

  • データ(VMデータ)
  • メタデータ(Cassandra)
  • 設定データ(Zookeeper)
データ

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

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

Block/Rack Aware Replica Placement
ブロック/ラック アウェア レプリカの配置方法

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

Block Failure Replica Placement
ブロック/ラック障害時のレプリカの配置方法
ラック/ブロック アウェアネス対メトロクラスタ

よくある質問として、クラスタを2つの場所(部屋、建物など)をまたぐように構成して、 ブロック/ラック アウェアネスを使用して、場所の障害に対する回復力を提供できるかどうかというものがあります。

理論的には可能ですが、これは推奨されるアプローチではありません。 まず、これで達成したいことについて考えてみましょう:

  1. 低いRPO
  2. 低いRTO(DRイベントではなくHAイベントにする)

最初のケースとして、0に近いRPOを達成しようとしている場合は、同期または同期に近い(near-synchronous)レプリケーションを利用することをお勧めします。 これにより、リスクの少ない同様のRPOを提供できます。

RTOを最小にするには、同期レプリケーション上でメトロクラスタを利用し、障害に対してDR復旧を実行する代わりにHAイベントとして処理します。

要約すると以下の理由により、同期レプリケーションやメトロクラスタリングを利用することが推奨されます:

  • Sync Repやメトロクラスタリングを使用して同様の結果を達成して、リスクを回避し、障害ドメインを隔離しておくことができます。
  • サポートされていない「ストレッチ」展開において2つの場所の間でのネットワーク接続がダウンした場合、クォーラムを維持する必要があるため、一方はダウンします (例えば、大多数の側はアップしたままとなります)。 メトロクラスタのシナリオでは、両側が独立して動作し続けることができます。
  • データの可用性ドメインへの配置は、不均等なシナリオでのベストエフォートです。
  • 両方のサイト間でのレイテンシーの追加やネットワーク帯域幅の減少は、「ストレッチ」展開のパフォーマンスに影響する可能性があります。
アウェアネスの条件とトレランス

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

要求されるアウェアネスの種類 FTレベル EC有効か? 最小ユニット 同時故障への
耐性
ノード 1 No 3 ノード 1 ノード
ノード 1 Yes 4 ノード 1 ノード
ノード 2 No 5 ノード 2 ノード
ノード 2 Yes 6 ノード 2 ノード
ブロック 1 No 3 ブロック 1 ブロック
ブロック 1 Yes 4 ブロック 1 ブロック
ブロック 2 No 5 ブロック 2 ブロック
ブロック 2 Yes 6 ブロック 2 ブロック
ラック 1 No 3 ラック 1 ラック
ラック 1 Yes 4 ラック 1 ラック
ラック 2 No 5 ラック 2 ラック
ラック 2 Yes 6 ラック 2 ラック

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リングを図示したものです:

12 Node Cassandra Ring
12ノードCassandraリング

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

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

Cassandra Node Block/Rack Aware Placement
Cassandra ノード ブロック/ラック アウェアな配置

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

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

Full Cassandra Node Block/Rack Aware Placement
完全なCassandraノード ブロック/ラック アウェアな配置
メタデータ アウェアネスの条件

以下に、一般的なシナリオと適用されるアウェアネスのレベルを示します:

  • FT1(データ RF2 / メタデータ RF3)がブロック アウェアとなる条件:
    • ブロック数 >=3 であること
    • Xを、最大ノードを持つブロックのノード数とします。残りのブロックには最低でも合計2Xのノード数が必要です。
      • 例:2、3、4および2つのノードを持つ4つのブロックの場合
        • 最大ノードを持つブロックのノード数は4なので、残り3ブロックで 2x4=8 ノードを持つ必要があります。 この場合の残りのブロックのノード数合計は7なので、ブロック アウェアとはなりません

      • 例: 3、3、4および3つのノードを持つ4つのブロックの場合
        • 最大ノードを持つノードのノード数は4なので、残り3ブロックで 2x4=8 ノードを持つ必要があります。 この場合の残りのブロックのノード数合計は9
          なので、最小必要値を上回り、ブロック アウェアになります
  • FT2(データ RF3 / メタデータ RF5)がブロック アウェアとなる条件:
    • ブロック数 >=5 であること
    • Xを、最大ノードを持つブロックのノード数とします。残りのブロックには合計最低でも4Xのノード数が必要です。
      • 例: 2、3、4、2、3および3つのノードを持つブロックの場合
        • 最大ノードを持つブロックのノード数は4なので、残り3ブロックで 4x4=16 ノードを持つ必要があります。 この場合の残りのブロックのノード数合計は13なので、ブロック アウェアになりません

      • 例: 2、4、4、4、4および4つのノードを持つブロックの場合
        • 最大ノードを持つノードのノード数は4なので、残り3ブロックで 4x4=16 ノードを持つ必要があります。 この場合の残りのブロックのノード数合計は18なので、最小必要値を上回りブロック アウェアになります
設定データ

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

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

Zookeeper Block/Rack Aware Placement
Zookeeperのブロック/ラック アウェアな配置

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

Zookeeper Placement Block/Rack Failure
Zookeeperのブロック/ラック障害時の配置

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

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

データパスの回復性能

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

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

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

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

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

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

Data Path Resiliency - Normal State
データパスの回復性能 - 通常の状態

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

データ分散の重要性

メタデータおよびデータを全てのノードとディスクデバイスに分散させることで、通常のデータ投入や再保護処理の際に最大のパフォーマンスを発揮できるようになります。

データがシステムに投入されると、プライマリとセカンダリのコピーがローカルおよび他の全てのリモートノードにコピーされます。これによってホットスポットの発生(ノードやディスクのスローダウン)を回避し、一定のWRITEパフォーマンスを得ることができます。

ノードを再度保護する必要があるディスクやノード自体に障害が発生した場合、クラスタの全能力を使ってリビルドを実施します。(障害発生ディスクのデータ検索およびレプリカの存在場所を特定するための)メタデータのスキャンは、CVM全体で均等に分散する形で実施されます。データのレプリカが特定できると、正常なCVMとディスクデバイス(SSDとHDD)、さらにホストネットワークのアップリンクを同時に使用してデータをリビルドします。

例えば、4ノードのクラスタでディスク障害が発生した場合、それぞれのCVMは、25%のメタデータのスキャンとリビルドを実施します。10ノードのクラスタの場合であれば、それぞれのCVMが10%、さらに50ノードのクラスタの場合であれば、それぞれのCVMは、2%分を担当することになります。

重要点: Nutanixは、データを均一に分散することによって一定のパフォーマンスを維持し、遙かに優れた再保護処理を実施できるようになっています。そして、これはクラスタ全体の処理(例えば、消失訂正符号や圧縮、重複排除など)にも適用されます。

HAのペアを使用したり、データの全てのコピーを単一のディスクに保存したりしている他のソリューションの場合には、ミラーノードやディスクが切迫した状態となった際(重いI/Oやリソース競合の発生などの際)に、フロントエンドでパフォーマンス問題が発生する可能性があります。

また、データを再保護する必要のある場所で障害が発生すると、単一のコントローラーやノードの単一のディスクリソース、そして単一のノードのアップリンクによって制約を受けることになります。 テラバイト級のデータを再度レプリケートしなければならない場合には、ローカルノードのディスクやネットワークのバンド幅について大きな制約を受けることになり、その間に別の障害が発生すると、データを喪失してしまう危険性が高まることになります。

想定される障害レベル

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

  • ディスク障害
  • CVMの「障害」
  • ノード障害
いつリビルドが始まるのか?

予期しない障害が発生した場合(正常に機能していない場合はプロアクティブにオフラインにして)、即座にリビルドプロセスを開始します。

60分待機しててリビルド開始し、その期間中に1つのコピーのみ維持する一部の他ベンダーとは異なり (非常に危険であり、何らかの障害が発生するとデータロスにつながる可能性があります)、 潜在的に高いストレージ使用率を犠牲にして、そのリスクを取るつもりはありません。

これができる理由は次の仕組みによります。 a)メタデータの粒度で、 b)書き込みRFのピアを動的に選択し(障害が発生している間、すべての新しいデータ(例えば、新しい書き込み/上書き)は構成された冗長性を維持します)、 c)リビルド中にオンラインに戻ってくるデータは検証されたら再収容できます。 このシナリオでは、データが「過剰複製」される可能性がありますが、Curatorスキャンが開始されると、過剰複製されたコピーが削除されます。

ディスク障害

ディスクが削除された場合、障害が発生した場合、応答がない場合、または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のログでエラーを監視します。

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

Data Path Resiliency - Disk Failure
データパスの回復性能 - ディスク障害

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

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

ノード障害

VMの影響:

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

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

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

Data Path Resiliency - Node Failure
データパスの回復性能 - ノード障害

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

プロからのヒント

データの回復機能状態(resiliency state)については、ダッシュボードページのPrismから確認することができます。

回復機能状態は、cliでも確認できます:

ノードのステータス

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

ブロックのステータス

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

これで最新の状態が表示されますが、データを更新するためにCuratorパーシャルスキャンを実行することもできます。

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障害からリビルドするために必要な容量」です。

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

同一構成のノードで構成されたクラスタの容量

  • 構成された可用性ドメイン: ノード
  • 最小の可用性ドメイン: ノード
  • FT=1
  • RF=2
  • ノードの容量: 10TB、10TB、10TB、10TB
  • レジリエントキャパシティ = (40-10)*0.95 = 28.5TB

    95%は、Stargateが読み取り専用モードになりユーザーの書き込みを実行できなくなるしきい値です。

同一構成ではないノードで構成されたクラスタの容量

  • 構成された可用性ドメイン: ブロック(1 ノード/ブロック)
  • 最小の可用性ドメイン: ノード
  • FT=1
  • RF=2
  • ノードの容量: 10TB、10TB、40TB、40TB
  • レジリエントキャパシティ = 40 * 0.95 = 38TB

    95%は、Stargateが読み取り専用モードになりユーザーの書き込みを実行できなくなるしきい値です。

この場合のレジリエントキャパシティは60TBではなく40TBであり、理由としては、40TBのブロックを失うと、クラスタにはノード可用性ドメイン(障害ドメイン)があるためです。 このレベル(ノード障害ドメイン)で2つのデータコピーを維持するには、使用可能容量は40TBであり、この場合のレジリエントキャパシティは全体で40TBになります。

容量と障害ドメインの観点から、クラスタは同一かつ均一の構成に保つことをお勧めします。

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

Resilient Capacity
レジリエントキャパシティ
Resilient Capacity Threshold
レジリエントキャパシティのしきい値

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

Resilient Capacity Detail
レジリエントキャパシティの詳細

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

Resilient Capacity Critical
レジリエントキャパシティがクリティカルな状態

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

キャパシティの最適化

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

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

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

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

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

データ変換 最も適したアプリケーション 補足
消失訂正符号 Nutanix Files/Objects に最適 従来のRFより少ないオーバーヘッドで高い可用性を提供。 通常のREAD/WRITE I/Oパフォーマンスに対し影響を与えない。 ディスク/ノード/ブロックに障害が発生しデータをデコードする必要がある場合には、READに若干のオーバーヘッドが発生。
インライン
圧縮
全て ランダムI/Oに影響を与えずストレージ層の使用効率を向上。レプリケーションやディスクから読み込むデータ量を減らすことで、大規模なI/OやシーケンシャルI/Oのパフォーマンスを向上。
オフライン
圧縮
なし インライン圧縮は、大規模またはシーケンシャルなWRITEに限りインラインで圧縮。ランダムI/Oや小規模なI/Oに対しては、オフライン圧縮を使用すべき。
パフォーマンス層
重複排除
P2V/V2V、Hyper-V (ODX)、クロスコンテナクローン クローンされなかったデータまたは効率的なAOSクローンを使用せずに作成されたデータに対して大幅なキャッシュ効率を提供。
キャパシティ層
重複排除
パフォーマンス層重複排除に同じ 上記の効果により、ディスクのオーバーヘッドを低減。

消失訂正符号 (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を使用する通常の環境は以下に図示するような内容となります:

Typical DSF RF Data Layout
典型的なDSF RFデータのレイアウト

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

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

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

DSF Encoded Strip - Pre-savings
DSF エンコード済みストライプ – プリセービング

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

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

DSF Encoded Strip - Post-savings
DSFデコード済みストラプ – ポストセービング
プロからのヒント

消失訂正符号はインライン圧縮機能と相性がよく、さらにストレージの節約ができます。私は、自分の環境でインライン圧縮と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パスとの関連を図示します:

Inline Compression I/O Path
インライン圧縮I/Oパス
プロからのヒント

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

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

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

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

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

Offline Compression I/O Path
オフライン圧縮の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リクエストの処理の関連を図示します:

Elastic Dedupe Engine - Scale
Elastic Dedupe Engine – 拡張

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パスの関係を図示します:

EDE I/O Path
EDE I/Oパス

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

重複排除 + 圧縮

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

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

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

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

DSF Tier Prioritization
DSF階層の優先順位付け

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

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

DSF Cluster-wide Tiering
DSF クラスタ全体の階層化

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

DSF Cluster-wide Tier Balancing
DSF クラスタ全体の階層バランシング

別のケースとして、階層全体の使用率が、一定のしきい値 [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 Tier ILM
DSF 階層ILM

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)で構成された「バランスが悪い」状態にあるクラスを図示しています:

Disk Balancing - Unbalanced State
ディスクバランシング - バランスが悪い状態

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

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

Disk Balancing - Balanced State
ディスクバランシング - バランスがとれた状態

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

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

Disk Balancing - Storage Only Node
ディスクバランシング – Storage Onlyノード

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

ビデオによる解説はこちらからご覧いただけます: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の説明が最も明解なものだったからです):

Example Snapshot Block Map
スナップショットブロックマップの例

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

Multi-snap Block Map and New Write
マルチ スナップ ブロックマップと新規書き込み

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

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

Multi-Clone Block Maps
マルチ クローンのブロックマップ

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

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

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

Clone Block Maps - New Write
クローンブロックマップ – 新規書き込み

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

DSF Networking
DSF ネットワーク

 

データ ローカリティ

コンバージド(サーバー+ストレージ)プラットフォームである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を「追いかけるか」を図示したものです:

Data Locality
データ ローカリティ
データ移行のしきい値

キャッシュローカリティはリアルタイムに発生し、vDiskの所有権に応じて決定されます。 vDiskやVMがあるノードから別のノードに移ると、vDiskの「所有権」もローカルCVMに移動します。 所有権が移動すると、データはユニファイド キャッシュ内でローカルにキャッシュされます。 その間、キャッシュは所有権がある場所(この場合はリモート ホスト)に格納されます。 それまでデータをホストしていたStargateは、リモートI/Oが300秒を超えた際にvDiskトークンを放棄し、それをローカルのStargateが引き継ぎます。 vDiskデータをキャッシュするには所有権が必要なため、キャッシュの統合処理が行われます。

egroupのローカリティは、サンプリングに基づく処理であり、エクステント グループの移行は以下の状況により発生します: 「10秒毎のサンプリング計測で、複数のRead処理が発生している10分間に、ランダム アクセスが3回、またはシーケンシャル アクセスが10回発生した場合」

シャドウ クローン

分散ストレージ ファブリックには「シャドウ クローン」と呼ばれる機能があり、「複数の読み手」のある特定の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>

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

Shadow Clones
シャドウ クローン

ストレージ層と監視

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

Storage Layers
ストレージ層

 

仮想マシン層
  • 主要な役割: 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は、ディスク デバイスがヒットされないため、ここではカウントされません。
  • 使用場面: キャッシュから提供した処理やディスクをヒットした処理の数を確認する場合に使用されます。
メトリクスと統計情報の保持

メトリクスと時系列データは、Prism Elementにローカルで90日間保存されます。Prism CentralやInsightsでは、データを (キャパシティが許す限り) 無期限に保存します。

サービス

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 Mapping
Guest Toolsの関係
Guest Tools Service

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

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

NGTリーダーをホストしているCVMのIPは、以下のコマンドにより確認することができます(どのCVM上でも実行可能)。

nutanix_guest_tools_cli get_leader_location

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

Guest Tools Service
Guest Tools Service
Guest Agent

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

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を有効化)」をクリックします。

Enable NGT for VM
VMでNGTを有効化

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

Enable NGT Prompt
Enable NGTプロンプト

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

Enable NGT - CD-ROM
NGTの有効化 - CD-ROM

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

Enable NGT - CD-ROM in OS
NGTの有効化 - OS内のCD-ROM

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

サイレント インストレーション

以下のコマンドを実行して、CD-ROMからNutanix Guest Toolsをサイレントインストレーションすることができます:

NutanixGuestTools.exe /quiet /l log.txt ACCEPTEULA=yes

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

Enable NGT - Installer
NGTの有効化 - インストーラー

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

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

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

Enable NGT - Installed Programs
NGTの有効化 - インストール済みプログラム

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

Enable NGT - Services
NGTの有効化 - サービス

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

NGTの一括導入

個々のVMにNGTをインストールするのではなく、ベースイメージにNGTを埋め込んで導入することも可能です。

ベースイメージでNGTを使用できるようにするためには、次の手順に従います:

  1. NGTをベースVMにインストールし、通信を可能にします
  2. ベースVMからクローンVMを作成します
  3. NGT ISOを各クローン上でマウントします(新しい証明書ペアが必要)
    • 例: ncli ngt mount vm-id=<CLONE_ID> またはPrismを使用
    • まもなく自動化された方法も可能になります :)
  4. クローンをパワーオン

クローンVMがブートされると、新しいNGT ISOを検知し、関連設定ファイルと新しい証明書をコピーして、Guest Tools Serviceとの通信を開始します。

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の作成またはクローニング処理の途中で指定します:

Custom Script - Input Options
カスタムスクリプト - 入力オプション

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

CloudInit実行結果の確認

CloudInitのログファイルは、/var/log/cloud-init.log および cloud-init-output.logにあります。

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とコンテナの簡単な比較を行っています:

比較基準 仮想マシン (VM) コンテナ
仮想化タイプ ハードウェアレベルの仮想化 OSカーネルの仮想化
オーバーヘッド 重い 軽い
プロビジョニングの速さ 遅い(数秒から数分) リアルタイム /
高速 (usからms)
パフォーマンス
オーバーヘッド
限定的なパフォーマンス ネイティブなパフォーマンス
セキュリティ 完全に独立(相対的に高い) プロセスレベルで独立
(相対的に低い)
サポート対象構成

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

    ハイパーバイザー:
  • 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と一緒にプラットフォーム上で稼動させることができます。

Docker - High-level Architecture
Docker – アーキテクチャー概要

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

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

Docker - Volumes
Docker - Volumes
前提

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

  • 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 - Host Creation Workflow
Docker - ホスト作成ワークフロー

次に、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

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

Docker - Container Creation Workflow
Docker - コンテナ作成ワークフロー

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

バックアップとディザスタリカバリ

Nutanixでは、ネイティブにバックアップとディザスタリカバリ (DR) 機能を提供しており、オンプレミスとクラウド環境(Xi)の両方で、ユーザーがDSF上で稼動する仮想マシンやオブジェクトをバックアップ、リストア、DRできるようにしています。 AOS 5.11 で、Nutanixはこれらの多くのコンセプトを抽象化するLeapとよばれる機能をリリースしました。 Leapについての追加情報は、Book of Backup / DR ServicesのLeapチャプターを参照してください。

次のセクションでは、以下の点について説明を行います:

  • 導入構成
  • 保護エンティティ
  • バックアップとリストア
  • レプリケーションとDR

注意: NutanixはネイティブにバックアップとDR機能を提供していますが、従来のソリューション(CommvaultやRubrikなど)についても、プラットフォームが提供するネイティブな機能(VSS、スナップショットなど)のいくつかを活用することで提供が可能です。

構成要素

NutanixバックアップとDRには、幾つかの主要な構成要素があります:

保護ドメイン (PD – Protection Domain)
  • 主な役割: 保護対象となるVMまたはファイルのマクログループ
  • 説明: 要求されたスケジュールに基づき、同時にレプリケートするVMまたはファイル(混在可)で構成された1つのグループ。 PDによってフルコンテナ、または選択した個別のVMまたはファイルを保護することができます。
プロからのヒント

希望するRPO/RTOに従って個々のサービス階層向けに複数のPDを作成します。 ファイル配布(ゴールデンイメージやISOなど)に対しては、レプリケーションするファイルを対象にPDを作成することができます。

整合性グループ(CG – Consistency Group)
  • 主な役割: キャッシュの一貫性を維持すべきPD内のVMまたはファイルのサブセット
  • 説明: クラッシュ整合性のある方法でスナップショットされる必要がある保護ドメイン(PD)のVMまたはファイル。 これによって、VMまたはファイルがリカバリされた場合、整合性のある状態で再生されます。 保護ドメインは、複数の整合性グループを持つことができます。
プロからのヒント

整合性グループ内で依存関係にあるアプリケーションやサービスVMをグループ化することで、これらを整合性のある状態でリカバーすることができます(例えばアプリとDBなど)

スナップショットスケジュール
  • 主な役割: スナップショットとレプリケーションのスケジュール
  • 説明: 特定のPDおよびCGにあるVMのスナップショットおよびレプリケーションのスケジュール
プロからのヒント

スナップショットのスケジュールは、希望するRPOと一致している必要があります

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

リテンションポリシーは、VMまたはファイル毎に必要となるリストアポイントの数と一致している必要があります

リモートサイト
  • 主な役割: リモートNutanixクラスタ
  • 説明: リモートNutanixクラスタは、バックアップまたはDRのターゲットとして使用することができます
プロからのヒント

ターゲットとなるサイトには、完全なサイト障害に備えた十分なキャパシティ(サーバー、ストレージ)が必要です。 このような場合には、単一サイト内のラック間でのレプリケーションも有効となります。

以下に、単一サイトのPD、CGおよびVMまたはファイルの関係を示します:

DR Construct Mapping
DR構成要素の関係
ポリシーベースのDRとランブック

ポリシーベースのDRとランブックは、VMベースのDRで定義されていた機能(PD、CGなど)を拡張し、ポリシー駆動モデルとして抽象化します。 重要な項目(例えばRPOや保持期限など)に焦点をあて、VMに直接ではなくカテゴリ割り当てにすることで、設定を簡素化します。 また、すべてのVMに適用できる「デフォルトポリシー」を設定することもできます。

注: これらのポリシーは、Prism Central(PC)で構成します。

エンティティの保護

以下の手順に従って、エンティティ(VM、VG、ファイル)を保護することができます:

Data Protection(データ保護)ページで、+ Protection Domain -> Async DR とします:

DR - Async PD
DR - 非同期PD

PD名を設定し、「Create(作成する)」をクリックします。

DR - Create PD
DR - PDの作成

保護するエンティティの選択:

DR - Async PD
DR - 非同期PD

「Protect Selected Entities(選択済みエンティティを保護)」をクリックします。

DR - Protect Entities
DR - エンティティの保護

保護されたエンティティは、「Protected Entities(保護されているエンティティ)」に表示されます。

DR - Protected Entities
DR - 保護されたエンティティ

「Next(次へ)」をクリックし、次に「Next Schedule(次回のスケジュール)」をクリックしてスナップショットとレプリケーションをスケジュールします。

スナップショットの頻度、保存方針、レプリケーションするリモートサイトを設定します。

DR - Create Schedule
DR - スケジュールの作成

「Create Schedule(スケジュールを作成)」をクリックし、スケジュールを完成させます。

複数のスケジュール

スナップショットやレプリケーションスケジュールは、複数作成することができます。例えば、1時間おきにローカルバックアップを取得し、日次でリモートサイトに対してレプリケーションを行うといった対応が可能です。

単純化するために、コンテナ全体を保護対象にできる点に留意してください。ただし、プラットフォーム自体は、VMやファイルといった粒度での保護が可能です。

バックアップとリストア

Nutanixのバックアップ機能は、Cerebroによって起動されるネイティブなDSFスナップショット機能を使用してStargateが実行します。スナップショット機能は、ゼロコピー (zero copy) であり、ストレージを効率的に使用してオーバーヘッドを低減しています。スナップショットの詳細については、「スナップショットとクローン」のセクションをご覧ください。

通常のバックアップとリストア操作には、次のようなものがあります:

  • スナップショット:ストアポイントとレプリケートを(必要に応じて)作成
  • リストア: VMやファイルを以前のスナップショット状態に戻す(元のオブジェクトを置き換える)
  • クローン: リストアに似ているが、元のオブジェクトは置き換えない(スナップショットから新しいオブジェクトを生成))

「エンティティの保護」セクションで作成した保護ドメイン (PD) は、Data Protection(データ保護)ページで確認することができます。

DR - View PDs
DR - PDの確認

一旦、対象となるPDを選択すると、いくつかのオプションを選択することができます:

DR - PD Actions
DR - PDアクション

「Take Snapshot(スナップショットの取得)」をクリックすると、選択済みPDのスナップショットをアドホックに取得し、必要に応じてリモートサイトにレプリケートすることができます。

DR - Take Snapshot
DR - スナップショットの取得

また、PDを「Migrate(移行)」して、リモートサイトにフェイルオーバーさせることも可能です:

DR - Migrate
DR - 移行

移行(コントロール下にあるフェイルオーバー)が発生すると、システムは新しいスナップショットを作成してレプリケートし、新しいナップショットが作成されたことを他のサイトに通知します。

プロからのヒント

AOS 5.0以降は、単一ノードのレプリケーションターゲットを使用して、データを保護することができます。

PDのスナップショットについても以下の一覧で確認することができます:

DR - Local Snapshots
DR - ローカルスナップショット

ここからPDスナップショットをリストアまたはクローンすることもできます:

DR - Restore Snapshot
DR - スナップショットのリストア

「Create new entities(新しくエンティティを作成)」を選択すると、指定したプリフィックスを持つ新しいエンティティにPDのスナップショットをクローンします。あるいは「Overwrite existing entities(既存エンティティに上書き)」を選択すると、現在のエンティティをスナップショット時にリプレースします。

ストレージ機能のみのバックアップターゲット

バックアップやアーカイブのみが目的であれば、バックアップ先として、ストレージ機能のみのNutanixクラスタをリモートサイトに構成することが可能です。 データは、ストレージ機能のみのクラスタへ(から)レプリケートすることができるようになります。

アプリケーション整合性スナップショット

NutanixのVmQuesced Snapshot Service (VSS) 機能によって、OSやアプリケーションの静止 (queiscing)操作を行い、アプリケーション整合性を保ったスナップショットを取得することができます。

VmQueisced Snapshot Service (VSS)

VSSと言えば、通常WindowsのVolume Shadow Copy Serviceを指します。 しかしこの機能は、WindowsとLinux双方に適用できるため、NutanixではVmQueisced Snapshot Serviceと呼んでいます。

サポート対象構成

本ソリューションは、WindowsとLinuxゲスト双方に対応します。 完全なサポート対象ゲストOSの一覧については、"Compatibility and Interoperability Matrix" にある "NGT Compatibility" をご覧ください: LINK

前提

Nutanix VSSスナップショットを使用するためには、以下が必要です:

  • Nutanixプラットフォーム
    • クラスタ仮想IP (VIP) が設定されていること
  • ゲストOS / UVM
    • NGTがインストールされていること
    • CVM VIPにポート2074でアクセスできること
  • ディザスタリカバリ設定
    • UVMが「Use application consistent snapshots(アプリケーション整合性スナップショットを使用)」が有効化された状態でPDにあること
バックアップのアーキテクチャー

AOS 4.6では、Nutanix Guest Toolsパッケージの一部としてインストールされる、ネイティブなNutanixハードウェアVSSプロバイダーを使用しています。

以下にVSSアーキテクチャー概要を示します:

Nutanix Hardware VSS Provider

通常のデータ保護ワークフローを踏襲し、VMの保護において「Use application consistent snapshots(アプリケーション整合性スナップショットを使用)」を選択することで、 アプリケーション整合性のあるスナップショットを取得することができます。

Nutanix VSSの有効化、無効化

UVMのNGTが有効されていれば、Nutanix VSSスナップショット機能もデフォルトで有効化されています。しかし、本機能は、以下のコマンドで無効化することができます。

ncli ngt disable-applications application-names=vss_snapshot vm_id=<VM_ID>

Windows VSSアーキテクチャー

Nutanix VSSソリューションは、Windows VSSフレームワークと連携しています。下図にそのアーキテクチャー概要を示します:

Nutanix VSS - Windows Architecture
Nutanix VSS - Windowsアーキテクチャー

一旦、NGTがインストールされると、NGTエージェントとVSS Hardware Providerサービスを確認することができます:

VSS Hardware Provider
VSS Hardware Provider
Linux VSSアーキテクチャー

LinuxソリューションもWindowsソリューションに似ていますが、Linuxディストリビューションの場合には、Microsoft VSSフレームワークに該当するような機能が存在しないため、スクリプトを使用します。

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

Nutanix VSS - Linux Architecture
Nutanix VSS - Linuxアーキテクチャー

pre-freezeとpost-thawスクリプトは、以下のディレクトリにあります:

  • Pre-freeze: /sbin/pre_freeze
  • Post-thaw: /sbin/post-thaw
ESXiのスタンをなくす

ESXiでは、VMware Toolsを使用した、ネイティブなアプリケーション整合性スナップショットをサポートしています。 しかし、この処理の途中で差分ディスクが生成されるため、ESXiは、仮想ディスクを新規のWRITE I/Oを処理する新しい差分ファイルにマップするためにVMをスタン(stun:一時停止)させます。 このスタン状態は、VMwareスナップショットを削除した場合にも発生します。

VMがスタン状態の間、OSは一切の処理を行うことができず、基本的には「スタック」した状態(pingが通らない、I/O処理ができないなど)になります。 このスタンの長さは、vmdksの数とデータストア メタデータ処理(新規差分ディスクの作成など)の速さに依存します。

Nutanix VSSを使用することで、VMwareスナップショット / スタン処理を完全にバイパスし、VMやOSのパフォーマンスや可用性にほとんど影響を与えないようにすることができます。

レプリケーションとDR

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

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

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

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

Example Replication Topologies
レプリケーショントポロジーの例

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

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

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

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

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

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

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

Replication Architecture
レプリケーションアーキテクチャー

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

プロからのヒント

プロキシを利用してリモートサイトの設定を行う場合には、常にPrism Leaerにホストされ、CVMが停止した場合でも使用可能な状態にするため、必ずクラスタIPを使用するようにします。

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

Replication Architecture - Proxy
レプリケーションアーキテクチャー – プロキシ

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

注意
これは本番環境以外で使用するべきです。また、可用性を確保するためにクラスタIPを使用するようにします。

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

Replication Architecture - SSH Tunnel
レプリケーションアーキテクチャー – SSHトンネル
グローバル重複排除

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

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

Replication Deduplication
レプリケーションの重複排除
注意

レプリケーションの重複排除を可能にするためには、ソースおよびターゲットとなるコンテナおよびvstoreで、フィンガープリントが有効化されている必要があります。

NearSync

Nutanixでは、先に説明した従来の非同期(async)レプリケーション機能をベースにした、同期に近いレプリケーション(NearSync: Near Syncronous Replication)の提供をはじめました。

NearSyncは、プライマリI/Oのレイテンシーに(非同期レプリケーションのような)影響を与えないことに加え、(同期レプリケーション(Metro)のような)非常に短いRPOを実現することが可能です。 これによってユーザーは、通常、同期レプリケーションの書き込みに必要となるオーバーヘッドなしに、非常に短いRPOを実現することが可能になります。

この機能には、「ライトウェイトスナップショット (LWS: Light-Weight Snapshot)」と呼ばれるテクノロジーが使用されています。 非同期で使用する従来のvDiskベースのスナップショットとは異なり、NearSyncは、マーカーを使用した完全にOpLogベースの機能となっています(一方、vDiskのスナップショットはエクステントストアで行われます)。

Mesosは、スナップショット層の管理と、フル / 増分スナップショットにおける複雑性の排除を目的に追加された新しいサービスです。 ハイレベルな構造とポリシー(整合性グループなど)については引き続きCerebroが管理する一方で、MesosはStargateとのやり取りや、LWSのライフサイクルコントロール機能を受け持ちます。

NearSyncのコンポーネント間のやり取りの例を以下に示します:

NearSync Components
NearSyncコンポーネント間でのやり取り

ユーザーがスナップショットの取得頻度を15分以下に設定すると、自動的にNearSyncが使用されます。この場合、初期のシードスナップショットが取得され、リモートサイトにレプリケーションされます。これが60分未満で完了すると、すぐに別のシードスナップショットが取得されてレプリケートされ、LWSスナップショットのレプリケーションが開始されます。2番目のシードスナップショットのレプリケーションが完了すると、既に存在する全てのLWSスナップショットが有効となり、システムは安定したNearSync状態となります。

以下に示す図は、NearSyncの有効化から実行までを時間の流れで追った例となります:

NearSync Replication Lifecycle
NearSyncのレプリケーションライフサイクル

安定した状態にある間、vDiskのスナップショットは、1時間おきに取得されます。LSWとスナップショットを一緒にリモートサイトに送る代わりに、リモートサイトでは、以前のvDiskのスナップショットと、その時点以降のLWSを組み合わせてvDiskのスナップショットを生成します。

NearSyncの同期状態が崩れる(例えばネットワークの停止やWANの遅延など)と、LWSのレプリケーションに60分以上を要する状態となり、システムはvDiskベースのスナップショットに自動的に切り替えを行います。これらの内の1つが60分未満で完成すると、LWSのレプリケーションを開始する場合と同様に、システムは瞬時に他のスナップショットを取得します。一旦完全なスナップショットが完成すると、LWSスナップショットは有効となり、システムは安定したNearSyncの同期状態となります。このプロセスは、初期のNearSyncの有効化と同様の内容になります。

LWSベースのスナップショットがリストア(またはクローン)されると、システムは最新のvDiskのクローンを取得し、目的のスナップショットに達するまで、順次LWSを適用していきます。

以下の図は、LWSベースのスナップショットをリストアする方法を示しています:

vDisk Restore from LWS
LWSからvDiskをリストアする

Metro Availability

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

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

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

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

Metro Availability - Normal State
Metro Availability – 通常の状態

サイトに障害が発生した場合、HAイベントを発行し、別のサイトでVMを再起動することが可能です。 通常、フェイルオーバー処理は手動での対応となります。 しかしAOS 5.0でリリースされたMetro Witnessの場合には、フェイルオーバーの自動化設定が可能です。 WitnessはポータルからダウンロードしてPrismを使って設定することができます。

以下に、サイト障害発生時の例を図示します:

Metro Availability - Site Failure
Metro Availability – サイト障害発生時

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

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

Metro Availability - Link Failure
Metro Availability - リンク障害

AOSのアドミニストレーション

重要なページ

一般的なユーザーインターフェイスに加え、高度な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テーブルにルールを追加する必要があります。

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

2009 Page - Stargate Overview
2009ページ – Stargate概要

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

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

2009 Page - Stargate Overview - Queues
2009ページ – Stargate概要 – Queue

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

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

2009 Page - Stargate Overview - Unified Cache
2009ページ – Stargate概要 - コンテンツキャッシュ
プロからのヒント

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

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

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

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

2009 Page - Cluster State - Disk Usage
2009ページ – クラスタステータス - ディスク使用状況

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

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

2009 Page - NFS Worker - vDisk Stats
2009ページ – NFSワーカー – vDiskステータス
プロからのヒント

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

  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のハイパーリンクを示しています:

2009 Page - Hosted vDisks
2009ページ – ホステッドvDisk

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

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

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

2009 Page - vDisk Stats - Ops and Randomness
2009ページ – vDiskステータス - オペレーションとランダムネス

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

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

2009 Page - vDisk Stats - Frontend Read Latency
2009ページ - vDiskステータス - フロントエンドREADレイテンシー

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

2009 Page - vDisk Stats - Frontend Write Latency
2009ページ - vDiskステータス - フロントエンドWRITEレイテンシー

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

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

2009 Page - vDisk Stats - Read I/O Size
2009ページ - vDiskステータス – READ I/Oサイズ

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

2009 Page - vDisk Stats - Write I/O Size
2009ページ - vDiskステータス – WRITE I/Oサイズ

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

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

2009 Page - vDisk Stats - Working Set
2009ページ - vDiskステータス – ワーキングセット

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

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

2009 Page - vDisk Stats - Read Source
2009ページ - vDiskステータス – READソース
プロからのヒント

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

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

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

2009 Page - vDisk Stats - Write Destination
2009ページ - vDiskステータス – 書き込み先
プロからのヒント

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

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

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

2009 Page - vDisk Stats - Extent Group Up-Migration
2009ページ - vDiskステータス – エクステントグループ上層移動

2010ページの利用 (Curator)

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

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

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

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

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

2010 Page - Curator Nodes
2010ページ – Curatorノード

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

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

スキャンはスケジュールに基づいて定期的に実行されますが、特定のクラスタイベントによっても起動されます。

ジョブが実行されるいくつかの理由を、以下に示します:

  • 定期実行(通常の状態)
  • ディスク、ノードまたはブロックの障害
  • ILMの不均衡
  • ディスクまたは階層の不均衡

以下が「Curatorジョブ」一覧になります:

2010 Page - Curator Jobs
2010ページ – Curatorジョブ

一覧には、各ジョブが実行したアクティビティの概要の一部が記載されています:

処理 フルスキャン パーシャルスキャン
ILM X X
ディスクバランシング X X
圧縮 X X
重複排除 X  
消失訂正符号 (EC) X  
ガベージクリーンアップ X  

「実行ID (Execution ID)」をクリックすると、ジョブの詳細ページに移り、生成されたタスクと同時にジョブの詳細情報が表示されます。

ページの上部に表示される一覧には、ジョブのタイプ、理由、タスク、デュレーションといった詳細が表示されます。

次のセクションには「バックグラウンドタスクステータス (Background Task Stats)」一覧があり、タスクのタイプ、生成された数量やプライオリティといった詳細が表示されます。

以下がジョブ詳細一覧になります:

2010 Page - Curator Job - Details
2010ページ – Curatorジョブ – 詳細

以下が「バックグラウンドタスクステータス」一覧になります:

2010 Page - Curator Job - Tasks
2010ページ – Curatorジョブ – タスク

次のセクションには「MapReduceジョブ」一覧があり、各Curatorジョブにより起動された、実際のMapReduceジョブが表示されます。パーシャルスキャンには単独のMapReduceジョブとなり、フルスキャンは4つのMapReduceジョブとなります。

以下が「MapReduceジョブ」一覧になります:

2010 Page - MapReduce Jobs
2010ページ – MapReduceジョブ

「ジョブID (Job ID)」をクリックすると、MapReduceジョブの詳細ページに移り、タスクステータス、各種カウンター、MapReduceジョブの詳細が表示されます。

以下に、ジョブのカウンターの例を図示します:

2010 Page - MapReduce Job - Counters
2010ページ – MapReduceジョブ – カウンター

メインページの次のセクションには、「QueueされたCuratorジョブ」および「最後に完了したCuratorスキャン」一覧があります。これらの一覧には、定期的なスキャンを実施すべき適切な時間と、最後に実行されたたスキャン詳細が表示されています。

以下が「QueueされたCuratorジョブ」および「最後に完了したCuratorスキャン」セクションになります:

2010 Page - Queued and Successful Scans
2010ページ –MapReduceジョブ– Queueされたスキャンおよび完了したスキャン

高度なCLIに関する情報

通常のトラブルシューティングやパフォーマンスの監視にあたっては、Prismがあれば全ての対応が可能です。しかし、これまで説明したバックエンドページやCLIで得た情報に関して、さらに詳細に把握したい場合もあるでしょう。

vdisk_config_printer

vdisk_config_printerは、クラスタの全てのvDiskに関する情報の一覧を表示するコマンドです。

以下に、主要なフィールドを列挙します:

  • vdisk_id
  • vDisk名 :vdisk_name
  • 親vDisk ID:parent_vdisk_id (クローンまたはスナップショットの場合)
  • vDiskサイズ:vdisk_size(バイト)
  • コンテナ ID:container_id
  • 削除ブール値:to_remove bool(Curatorスキャンで削除するか否か)
  • 可変ステータス:mutability_state(アクティブなr/w vDiskの場合は変更可、スナップショットは変更不可)

以下に、コマンドの出力例を示します:

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 ...

vdisk_usage_printer -vdisk_id=<VDISK ID>

vdisk_usage_printerは、vDiskの詳細、エクステント、egroupに関する情報の取得に使用します。

以下に、主要なフィールドを列挙します:

  • Egroup ID
  • egroupエクステントカウント:egroup extent count)
  • 未変換egroupサイズ:untransformed egroup size
  • 変換済みegroupサイズ:transformed egroup size
  • 変換率 :transform ratio
  • 変換タイプ :transformation type
  • egroupのレプリカのロケーション :egroup replica location
    (ディスク/CVM/ラック)

以下に、コマンドの出力例を示します:

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] ...

注意: 重複排除済みと非重複排除でのegroupのサイズの違い(1MB対4MB)にご注意下さい。 「データ構造」セクションで説明したように、重複排除の結果、重複排除後のデータにフラグメンテーションが発生しないようにするためには、egroupサイズが1MBの方を優先すべきです。

curator_cli display_data_reduction_report

curator_cli display_data_reduction_reportを使って、コンテナ別のストレージ削減量に関する詳細情報を、適用したトレージの変換テクニック(クローン、スナップショット、重複排除、圧縮、消失訂正符号など)別にレポートすることができます。

以下に、主要なフィールドを列挙します:

  • コンテナID :Container ID
  • テクニック:Technique(適用した変換)
  • 削減前のサイズ :Pre Reduction
  • 削減後のサイズ :Post Reduction
  • 削減容量 :Saved
  • 削減率 :Ratio

以下に、コマンドの出力例を示します:

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 | +---------------------------------------------------------------------------+

curator_cli get_vdisk_usage lookup_vdisk_ids=<COMMA SEPARATED VDISK ID(s)>

curator_cli display_data_reduction_reportを使って、カンマ区切りで指定したvDisk別のストレージ削減量に関する詳細情報を、変換テクニック(重複排除、スナップショット、クローンなど)別にレポートすることができます。

以下、主要なフィールドを列挙します:

  • Vdisk ID
  • 占有使用量 :Exclusive usage(該当するvDiskのみがアクセスするデータ)
  • 論理未継承量 :Logical Uninherited(vDiskに書き込まれたデータで、クローン時に子に継承されるもの)
  • 論理重複排除量 :Logical Dedup(重複排除されたvDiskデータの総量)
  • 論理スナップショット :Logical Snapshot(vDiskチェーンで共有されていないデータ)
  • 論理クローン :Logical Clone(vDiskチェーンで共有されているデータ)

以下に、コマンドの出力例を示します:

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 | ...

curator_cli get_egroup_access_info

curator_cli get_egroup_access_infoを使って、最新のアクセス(読み込み、変更(書き込みまたは上書き))を基に、各バケットのegroupの数に関する詳細な情報をレポートすることができます。この情報を使えば、消失訂正符号に適したegroupの数を推定することができます。

以下に、主要なフィールドを列挙します:

  • コンテナID(Container ID)
  • Access \ Modify (secs)

以下に、コマンドの出力例を示します:

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 .. +----------------------------------------------------------------------------.. ...

Book of AHV

AHVのアーキテクチャー

ノードアーキテクチャー

AHVを導入した場合、コントローラーVM(CVM)はひとつのVMとして稼動し、ディスクはPCIパススルーを使用するようになります。 これにより、PCIコントローラー(および付属デバイス)のパススルーが完全に実現され、ハイパーバイザーを迂回してCVMに直接繋がるようになります。 AHVは、CentOS KVMをベースに構築されています。 ゲストVM (HVM) に対しては、完全なハードウェアの仮想化を使用します。

AHV Node
AHVノード

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として稼動します

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

KVM Component Relationship
KVMコンポーネントの関係

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

プロセッサ世代間の互換性

異なるプロセッサ世代間でVMを移動できるVMwareのEnhanced vMotion Capability (EVC) と同様に、AHVでは、クラスタ内の最も古いプロセッサの世代を特定し、全てのQEMUドメインをそのレベルで取扱います。これによって、AHVクラスタ内に異なる世代のプロセッサが混在している場合でも、ホスト間のライブマイグレーションが可能となります。

最大構成と拡張性

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

  • 最大クラスタサイズ: 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 Network Overview
Open vSwitchネットワーク概要

上記の画像には、いくつかの種類のコンポーネントが表示されています。

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つの方式があります:

Service chain - Packet Processors
サービスチェーン - パケット処理
  • インライン (Inline) パケット処理
    • OVSを流れるパケットをインラインでインターセプト
    • パケットの変更、許可/拒否が可能
    • 一般的な適用例: ファイアウォールやロードバランサー
  • タップ (Tap) パケットプロセッサ
    • パケットフローにタップして読み込みを行い、パケットを検査
    • 一般的な適用例: IDS、IPS、ネットワーク監視

全てのサービスチェーン処理は、Flowのマイクロセグメンテーション ルールが適用された後、かつパケットがローカルOVSから出る前に完了します:

Service Chain - Flow
サービスチェーン - フロー

説明: 複数のパケットプロセッサを、1つのチェーンに繋ぎ合わせることも可能です。

仮想マシンテンプレート

AHVには、簡単にクローンできるように単一vDiskのデータキャプチャにフォーカスしたイメージライブラリが常に持っていましたが、CPU、メモリ、そしてネットワークの詳細を設定するプロセスを完了するには、管理者からの入力が必要でした。 仮想マシンテンプレートは、この概念を次のレベルのシンプルなものにして、他のハイパーバイザーでテンプレートを利用したことがある管理者に馴染みのある仕組みを提供します。

AHVの仮想マシンテンプレートは既存の仮想マシンから作成され、CPU、メモリ、vDisk、そしてネットワークの詳細など、定義する仮想マシンの属性を受け継ぎます。 テンプレートは、展開時にゲストOSをカスタマイズするように構成でき、オプションとしてWindowsライセンスキーを提供できます。 テンプレートでは複数のバージョンを維持できるため、新しいテンプレートを作成する必要なく、オペレーティングシステムやアプリケーションパッチなどの更新を簡単に適用できます。 管理者はどのテンプレートのバージョンがアクティブか選択できるため、更新を事前にステージングしたり、必要に応じて以前のバージョンに戻すことができます。

メモリオーバーコミット

仮想化の主な利点の1つは、コンピューティングリソースをオーバーコミットできることであり、これにより、サーバーホスト上に物理的に存在するよりも多くのCPUを仮想マシンにプロビジョニングできます。 ほとんどのワークロードは、割り当てられたすべてのCPUを100%必要とはしないため、ハイパーバイザーは、CPUサイクルを必要とするワークロードに各時点で動的に割り当てることができます。

CPUまたはネットワークリソースと同様に、メモリもオーバーコミットできます。 どの時点でも、ホスト上の仮想マシンでは、割り当てられたすべてのメモリを使用している場合も使用していない場合もあり、ハイパーバイザーは未使用のメモリを他のワークロードと共有できます。 メモリのオーバーコミットによって、未使用のメモリを組み合わせて必要とする仮想マシンに割り当てることで、管理者は各ホストにより多くの仮想マシンをプロビジョニングできるようになります。

AOS 6.1では、追加のメモリと仮想マシン密度が必要なテストや開発のような環境で、管理者が利用できるようにするオプションとしてメモリオーバーコミットをAHVにもたらします。 オーバーコミットはデフォルトで無効になっており、仮想マシン単位で定義できるため、クラスタ上の仮想マシンのすべてまたはサブセットのみで共有できます。

VMアフィニティポリシー

異なる種類のアプリケーションには、仮想マシンを同じホストで実行する必要があるか、または別のホストで実行する必要があるかを指示する要件があります。 これは通常、パフォーマンスもしくは可用性の利点のために行われます。 アフィニティ制御により、仮想マシンがどこで実行されるかを管理できるようになります。 AHVには、2種類のアフィニティ制御があります:

  • 仮想マシン-ホスト アフィニティ
    • 仮想マシンをホストまたはホストのグループに厳密に結び付けると、仮想マシンはそのホストまたはグループでのみで実行されます。 アフィニティは、ソフトウェアライセンスまたは仮想マシンアプライアンスが関係するユースケースで特に適用できます。 このようなケースでは、多くの場合でアプリケーションを実行できるホスト台数を制限したり、仮想アプライアンスを単一のホストに縛り付けしたりする必要があります。
  • アンチアフィニティ
    • AHVでは、与えられたリストの仮想マシンを同じホスト上で実行しないように宣言できます。 アンチアフィニティは、クラスタ化された仮想マシンまたは分散アプリケーションを実行している仮想マシンを異なるホスト上で実行するメカニズムを提供し、アプリケーションの可用性と復元力を向上させます。 仮想マシンの分離配置よりも仮想マシンの可用性を優先するため、クラスタが制約された際には、システムはこのタイプのルールを無効化します。

Nutanix AHVの動作の仕組み

ストレージI/Oパス

AHVは、ESXiやHyper-Vのような従来のストレージ スタックを使用してはいません。 全てのディスクは、ロー(raw)SCSIブロックデバイスとしてVMに渡されます。 これによってI/Oパスを軽量化および最適化することができます。

注意

AOSは、エンドユーザーに対してkvm、virsh、qemu、libvirtおよびiSCSIを抽象化する形で、全てのバックエンド構成を処理します。 これによってユーザーは、PrismやACLIを使って、そのスタックより上のみを意識すればよくなります。 なお以下は、情報提供を目的とした説明であるため、マニュアル操作でvirshやlibvirtに触らないことを推奨します。

各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(通常はローカルにある)にリダイレクトされます。

iSCSI Multi-pathing - Normal State
iSCSIマルチパス - 通常状態

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にリダイレクトします。

iSCSI Multi-pathing - Local CVM Down
iSCSIマルチパス – ローカルCVMが停止した場合

ローカルのStargateが復旧(かつNOP OUTコマンドにレスポンスを開始)した場合、iSCSIリダイレクターは、リモートStargateへのiSCSIセッションを終了します。 QEMUは、iSCSIログインを再度試み、同ログインはローカルのStargateにリダイレクトされます。

iSCSI Multi-pathing - Local CVM Back Up
iSCSIマルチパス – ローカルCVMが復旧した場合

従来のI/Oパス

全てのハイパーバイザーやOSと同様、ユーザー空間とカーネル空間のコンポーネントが相互にやり取りを行って、1つの処理を実行しています。 以下を読む前に「ユーザー空間とカーネル空間」のセクションを参照し、お互いがどういった関係でやり取りをしているかを理解することをお勧めします。

VMがI/Oを実行する場合、以下の処理が行われます(理解しやすくするため、一部の手順は省略してあります):

  1. VMのOSが仮想デバイスに対してSCSIコマンドを実行
  2. Virtio-SCSIがリクエストを受け取り、ゲストのメモリに保存
  3. QEMUメインループがリクエストを処理
  4. Libiscsiが各リクエストを検査して転送
  5. ネットワーク層がリクエストをローカルCVMに転送(ローカルCVMが利用できない場合は外部のCVM)
  6. Stargateがリクエストを処理

以下に、このフローの例を示します:

AHV VirtIO Data Path - Classic
AHV VirtIOデータパス - 従来の方式

ドメインの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パスなのです。

Pro tip

FrodoはAOS 5.5.X以降でパワーオンされたVMにおいてデフォルトで有効になります。

VMがI/Oを実行する場合、以下の処理が行われます(理解し易くするため、一部の手順は省略してあります):

  1. VMのOSが仮想デバイスに対してSCSIコマンドを実行
  2. Virtio-scsiがリクエストを受け取り、ゲストのメモリに保存
  3. Frodoがリクエストを処理
  4. カスタムlibiscsiがiscsiヘッダーを付加して転送
  5. ネットワーク層がリクエストをローカルCVMに転送(ローカルCVMが利用できない場合は外部のCVM)
  6. Stargateがリクエストを処理

以下に、このフローの例を示します:

AHV VirtIO Data Path - Classic
AHV VirtIOデータパス - 従来の方式

以下のパスは、いくつかの重要な点を除いて、従来の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> ...

プロからのヒント

Frodoのマルチスレッド / マルチコネクションの利点を活かすためには、VMが立ち上がった際に、1つのVMにつき2つ以上のvCPUを割り当てることが必要となります。

これは、以下のように特徴付けられます:

  • 1 vCPU UVM:
    • 1ディスクデバイスあたり1 Frodoスレッド / セッション
  • 2以上の vCPU UVM:
    • 1ディスクデバイスあたり2 Frodoスレッド / セッション

以下では、ローカルブリッジと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リクエストのオペレーション例です:

IPAM - Local Acropolis Leader
IPAM – ローカルAcropolisリーダー

Acropolisリーダーがリモートで稼動している場合には、ネットワークを超えたリクエストを処理するために、同じVXLANトンネルが使用されます。

IPAM - Remote Acropolis Leader
IPAM - リモートAcropolisリーダー

既存のDHCP / IPAM ソリューションも使用することが可能です。

VMの高可用性 (HA)

AHV VM HAは、ホストやブロックに障害が発生した場合に、VMの可用性を確保するための機能です。 ホストに障害が発生した場合、そのホストで稼動していたVMは、クラスタ内の他の正常なノードに移動し再起動されます。 Acropolisリーダーがこの役割を担っています。

Acropolisリーダーは、クラスタ内全てのホスト上のlibvirtへの接続状況をモニターし、ホストのヘルスチェックを行っています:

HA - Host Monitoring
HA - ホストモニタリング

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つの「ホスト」に相当するリソース

ホストのメモリ容量に差がある場合、システムは最大のメモリ容量をもつホストを基準に、ホストあたりの予約量を決定します。

5.0以降のリソース予約

リリース5.0より前には、ホストとセグメントベース両方の予約をサポートしていました。 リリース5.0以降は、セグメントベースの予約のみとなり、これは保証HAモードが選択されると自動的に設定されます。

予約セグメントは、クラスタの全てのホスト全体にリソースを分散させます。 この場合それぞれのホストは、HAのために予約されたメモリを共有することになります。 これによって、ホストに障害が発生した場合でも、VMを再起動するための十分なフェイルオーバー容量をクラスタ全体で確保することができます。

以下の図は、予約セグメントの状態を示したものです:

HA - Reserved Segment
HA - 予約セグメント

ホストに障害が発生すると、VMはクラスタに残った正常なホストを使って再起動されます。

HA - Reserved Segment - Fail Over
HA - 予約セグメント - フェイルオーバー
予約セグメントの計算

予約セグメントの総数と1ホストあたりの予約量は、システムが自動的に計算します。

必要な予約量の算出は、良く知られた「ナップサック問題」の解法に集約します。 最適な解は、NP困難 (NP-hard、指数関数的)ですが、実用的には発見的解法でも最適解に近いものを得ることができます。 Nutanixは、こうしたアルゴリズムの1つであるMTHMを採用しています。 Nutanixは、今後も配置アルゴリズムの改善に努めて参ります。

AHVのアドミニストレーション

コマンドリファレンス

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

Book of vSphere

VMware vSphereのアーキテクチャー

ノードアーキテクチャー

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

ESXi Node Architecture
ESXiノード アーキテクチャー

最大構成と拡張性

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

  • 最大クラスタサイズ:64
  • VMあたりの最大vCPU数: 128
  • VMあたりの最大メモリ: 4TB
  • 最大仮想ディスクサイズ: 62TB
  • ホストあたりの最大VM数: 1,024
  • クラスタあたりの最大VM数: 8,000(HAが有効な場合、データストアあたり2,048)

注意: vSphere 6.0 時点の情報です。

プロからのヒント

ESXiホストでベンチマークを行う場合、常にESXiホストのパワーポリシーを「ハイパフォーマンス(High performance)」に設定してテストを行います。 これで P-States および C-States を無効化し、テスト結果を人為的に制限しないようにします。

ネットワーク

各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アーキテクチャーの概念的な構造を図示したものです:

ESXi vSwitch Network Overview
ESXi vSwitchネットワーク概要
アップリンクとチーミングポリシー

デュアルToRスイッチを使用して、スイッチHAのために、両スイッチをクロスしたアップリンク構成をとることを推奨します。システムは、デフォルトでアップリックインターフェイスをアクティブ/パッシブモードで使用します。アップストリームのスイッチアーキテクチャーが、アクティブ/アクティブなアップリンクインターフェイス(例えば、vPCやMLAGなど)に対応していれば、より高いネットワークスループットを得るためにこれを使用することができます。

NutanixにおけるvSphereの動作の仕組み

アレイオフロード - 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の通信に使用されます。

以下にこの状態を図示しました:

ESXi Host Networking
ESXiホストネットワーク

ローカルCVMで障害が発生した場合、それまでローカルCVMにホストされていたローカルの192.168.5.2アドレスは使用不可能になります。DSFは自動的にこの障害を検知し、10GbE経由でI/Oをクラスタ内の異なるCVMにリダイレクトします。この経路変更は、そのホストで稼動するハイパーバイザーやVMに対して透過的に行われます。つまり、CVMが停止しても、VMは引き続きDSFにI/Oが可能だということです。ローカルCVMが復旧して利用可能になると、経路は透過的に元にもどされ、トラフィックはローカルCVMから提供されるようになります。

以下は、CVM障害時にどういった動きをするか図示したものです:

ESXi Host Networking - Local CVM Down
ESXi ホストネットワーク – ローカルCVM障害時

VMware ESXiのアドミニストレーション

仮想マシンの管理

基本的な仮想マシン管理操作は、ハイパーバイザーの管理インターフェイスを使用せずに、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

Book of Hyper-V

Microsoft Hyper-Vのアーキテクチャー

Nutanix Hyper-Vクラスタが生成されると、Hyper-Vホストは、指定されたWindows Active Directoryドメインに自動的に参加する形になります。 これらのホストは、VM HAのためフェイルオーバークラスタに組み入れられます。 以上が完了すると、それぞれのHyper-VホストとフェイルオーバークラスタにADオブジェクトが作られます。

ノードアーキテクチャー

Hyper-Vを導入した場合、コントローラーVM (CVM) は、VMとして稼動しディスクはディスクパススルーを使用して提供されます。

Hyper-V Node Architecture
Hyper-V ノードアーキテクチャー

最大構成と拡張性

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

  • 最大クラスタサイズ: 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ネットワークはいくつでも作成することができます。

以下は、仮想スイッチアーキテクチャーの概念的な構造を図示したものです:

Hyper-V Virtual Switch Network Overview
Hyper-V仮想スイッチネットワーク概要
アップリンクとチーミングポリシー

デュアルToRスイッチを使用し、スイッチHAのために両スイッチをクロスしたアップリンク構成をとることを推奨します。システムは、デフォルトで特別な構成を必要としないスイッチ非依存モードでLBFOチームを形成します。

NutanixにおけるHyper-Vの動作の仕組み

アレイオフロード – 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」で表示されます。

Microsoft Hyper-Vのアドミニストレーション

重要なページ

近日公開!

コマンドリファレンス

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

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

指標値としきい値

近日公開!

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

近日公開!

Part 2: Services

Book of Test Drive

ことわざにあるように「百聞は一見にしかず」以上のものはありえません。 このドキュメントは、製品の動作とそのアーキテクチャーについての基礎知識として役立ちます。 本質的に、製品の概念的な性質について詳しく説明しています。

ただし、本当に理解するためには、実際のハンズオン体験に加えて概念的な学習の両方が必要であると主張するかもしれません。以下に視覚化されるようにです:

Test Drive - Conceptual Architecture
Test Drive - Conceptual Architecture

Nutanix Test Driveは、人々がNutanix製品の動作を体験できるようにするサービスです。 これは、Coreにあたる製品の体験に焦点を当てたものとして提供開始されていますが、最終的にはあらゆるNutanix製品(例えばCore、Frame、Beamなど)を体験できるようになるでしょう。

簡単に言うと、Test DriveはNutanixを体験することと同義です。

試してみたいですか? 下記のリンクをクリックして試してみてください!

Test Drive

https://www.nutanix.com/testdrive

背景

私達の「試用版」での最初の試みは、Community Edition(CE)と呼ばれるものから始まりました。 CEにより、ユーザーはNutanixソフトウェアを限りあるハードウェアにでもインストールすることができました。 これは、手を動かしていじくり回すのが好きな一部の方にとっては良いことでしたが、私たちの目標である「誰もがNutanixプラットフォームを素早く体験できる」ということを完全に達成することはできませんでした。

これらの学びから、Test Driveには以下の要件を設定しました:

  1. 人々がNutanixプラットフォームを迅速に体験できるようにする必要がある
  2. 製品とそこでの行動をガイドする必要がある

これらの2つの主要な要件に基づくと、その体験には「環境とガイド」という2つの核となる項目で構成される必要があることは明らかでした。

体験のコンポーネント

Test Driveの体験には2つの核となるコンポーネントがあります:

  • 環境
    • どこで体験するのか
    • 「どこか」またはローカル環境でホストされる
    • 体験する場所に固有のデータや構成が含まれる場合がある
  • ガイド
    • 何が経験を分かりやすくするのか
    • ワークブック、Prismでのガイド、インストラクターなどが考えられる

以下の図は、これら2つのコンポーネントを示します:

Test Drive - High-Level Architecture
Test Drive - High-Level Architecture
体験

Test Driveを開始するには、MyNutanixページから起動するか、Nutanix.comからTest Driveのメインページ(https://nutanix.com/testdrive)に移動します。

Test Driveの環境に入ると、一般的なテーマのシリーズから選択できます:

Test Drive - Themes
Test Drive - Themes

テーマを選択すると、そのテーマの一部であるさまざまなアクティビティ(そしてサブアクティビティ)を確認できます:

Test Drive - Activities
Test Drive - Activities

アクティビティを選択すると、ガイド機能によりPrism画面に重ねられたアクティビティの手順を案内します。

Test Drive - Prism Guide
Test Drive - Prism Guide

アクティビティが完了するまでガイドを続けます。 完了すると、新しいアクティビティを開始できます:

Test Drive - Activity Complete
Test Drive - Activity Complete

以上が、Test Driveに関するアイデアと、私達が達成しようとしていることの紹介です。 簡単に言うと、私たちはNutanixプラットフォームを誇りに思っており、誰でもそれを試すことができるようにしたいと考えています。 次のセクションで、使用できるTest Driveホスティング環境の一部について説明します(今後さらに追加予定)。

Test Drive on GCP

Test Drive on GCPは、GCPで起動している仮想的なNutanixクラスタを使用できる、Test Drive環境の1つです。

仮想的な、あるいはネストされたクラスタのアイデアは、開発とQAの目的で大量のネストされた仮想化環境でのAHVを活用する、私達のエンジニアリング組織に由来しています。 これによりリソースを大幅にオーバーサブスクライブし、大量の過剰キャパシティを必要とせずに大規模なテストを実施できます。 これは、当初は「NullHV」と呼ばれていました。

Test Drive on GCPは、ネストされたAHVの概念を取り入れ、それをGCPのネストされた仮想化機能(LINK)の上に構築しました。 これにより、GCPでNutanixソフトウェアを実行し、完全にオンデマンドのインフラストラクチャーで大規模なスケーラビリティを提供できます。

以下の図は、概念的なNutanix Test Driveの「クラスタ」を示します:

Test Drive - GCP Environment
Test Drive - GCP Environment

仮想的なNutanixクラスタは、AHVホストとCVMを、ペアのネイティブGCP VMとして実行することで作成されます。 これらのVMが連携して、単一のNutanixノードをシミュレートします。 通常の展開と同様に、CVMはストレージを処理し、ローカル接続されたSSDを備えており、AHVホストはコンピュート(CPUとメモリー)をUVMに提供します。 PCが必要な場合は、環境を管理するために別のPC VMが起動されます。

Book of Nutanix Cloud Clusters(NC2)

パブリッククラウドを活用するということは、アプリケーションとデータをオンデマンドで数分以内に拡張できるということを意味します。 Nutanix Cloud Clusters(NC2)では、単一の管理プレーンを使用してNutanixによるプライベートクラウドとパブリッククラウドのリソースの両方が同じPrismインターフェイスで管理できるようになり、シームレスな体験になります。

本書では、アーキテクチャー、ネットワーキング、ストレージ、そしてNC2の稼働についてのその他の側面について、技術的な詳細について解説します。

NC2は、現在はAWS上でサポートされています。

NC2は、現在Azureでのカスタマーとのプライベートプレビューを実施しています。

Nutanix Cloud Clusters on AWS

Nutanix Cloud Clusters (NC2) on AWSは、ターゲットクラウド環境のベアメタル リソースで実行される、オンデマンドのクラスタを提供します。 これにより、ご存知のNutanixプラットフォームのシンプルさで、真のオンデマンドな収容能力を実現できます。 プロビジョニングされたクラスタは従来のAHVクラスタのように見えますが、クラウド プロバイダーのデータセンターで実行されています。

サポートされる構成

このソリューションは以下の構成に適用できます(このリストはおそらく不完全であり、完全なサポートされている構成のリストについては、ドキュメントを参照してください):

    主なユースケース:
  • オンデマンド / バースト容量
  • バックアップ / DR
  • クラウド ネイティブ
  • 地理的拡張 / DC統合
  • アプリケーションのマイグレーション
  • その他
    管理インターフェイス:
  • Nutanix Cloud Clusters Portal - プロビジョニング
  • Prism Central(PC) - Nutanixの管理
  • AWS Console - AWSの管理
    サポートされる環境:
  • クラウド:
    • AWS
  • EC2ベアメタル インスタンスの種類:
    • i3.metal
    • m5d.metal
    • z1d.metal
    • i3en.metal
    • g4dn.metal
    アップグレード:
  • AOSの一部
    互換性のある機能:
  • AOSの機能
  • AWSのサービス
主な用語/構造

このセクションでの用語は、以下のように定義されています。

  • Nutanix Cloud Clusters Portal
    • Nutanix Cloud Clusters Portalは、クラスタのプロビジョニング リクエストの処理を受け持ち、AWSやプロビジョニングされたホストとのやりとりを行います。 クラスタ個別の詳細設定を作成し、動的なCloudFormationスタックの作成を処理します。
  • リージョン
    • 複数のアベイラビリティ ゾーン(サイト)が配置されている地理的な土地または地域です。 リージョンには2つ以上のAZを含めることができます。 これらには、US-East-1やUS-West-1などのリージョンを含めることができます。
  • アベイラビリティ ゾーン(AZ)
    • AZは、低遅延リンクで相互接続された、1つ以上の個別のデータセンターで構成されます。 各サイトは、独自の冗長電源、冷却システム、ネットワークを持ちます。 AZは複数の独立したデータセンターで構成できるため、これらを従来のコロケーションやデータセンターと比較すると、より回復力があると見なされます。 これらには、US-East-1aやUS-West-1aなどのサイトを含めることができます。
  • VPC
    • テナント向けの、AWSクラウドの論理的に隔離されたセグメントです。 環境を他からセキュアに隔離するための仕組みを提供します。 インターネットや、他のプライベート ネットワーク セグメント(他のVPCやVPN)に公開できます。
  • S3
    • S3 APIを介してアクセスされる永続オブジェクト ストレージを提供するAmazonのオブジェクトサービスです。 これはアーカイブやリストアに使用されます。
  • EBS
    • AMIに接続できる永続的なボリュームを提供するAmazonのボリューム/ブロック サービスです。
  • CloudFormation Template (CFT)
    • Cloud Formation Templateはプロビジョニングを簡素化しますが、リソースと依存関係の「スタック」を定義できます。 このスタックは、個々のリソースごとではなく、全体としてプロビジョニングできます。
クラスタのアーキテクチャー

Nutanix Cloud Clusters Portalは、概観的にいうとNC2 on AWSをプロビジョニングし、AWSと対話するためのメイン インターフェイスです。

プロビジョニング手順は、おおまかに下記のステップとして要約できます。

  1. NC2 Portalでクラスタを作成する
  2. 個別入力の展開(例えば、リージョン、AZ、インスタンスの種類、VPC/サブネットなど)
  3. NC2 Portalが、関連するリソースを作成する
  4. Nutanix AMIのHost agentが、Nutanix Cloud Clusters on AWSにチェックインする
  5. すべてのホストが起動すると、クラスタが作成される

以下は、NC2 on AWSの相互作用における概要を示します:

NC2 on AWS - Overview
NC2 on AWS - 概要

以下は、NC2 Portalによる入力と、作成されるリソースの概要を示します:

NC2 on AWS - Cluster Orchestrator Inputs
NC2 on AWS - Cluster Orchestratorのインプット

以下は、AWSでのノードの概要を示します:

NC2 on AWS - Node Architecture
NC2 on AWS - ノードのアーキテクチャー

ホストがベアメタルであるため、通常のオンプレミス展開と同様に、ストレージとネットワークのリソースを完全に制御できます。 CVMおよびAHVホストのブート領域では、EBSボリュームが使用されます。

注: EBSなどの特定のリソースとのやりとりは、AHVホストでNVMeコントローラーとして認識されるAWS Nitroカードを介して実行されます。

配置ポリシー

NC2 on AWSは、デフォルトで7つのパーティションを持つ、パーティション配置ポリシーを使用します。 ホストは、Nutanixのラックに対応するパーティションに、ストライプ状に配置されています。 これにより、1~2箇所の「ラック」全体障害が発生しても、可用性を維持できます。

以下に、パーティションによる配置戦略および、ホストのストライピングの概要を示します:

NC2 on AWS - Partition Placement
NC2 on AWS - パーティション配置

複数種類のノードが利用されている場合(例えば、i3.metalやm5d.metalなど)、各ノードの種類ごとに、ノードがストライプ化された7つのパーティションがあります。

以下は、複数種類のインスタンスが使用されている場合の、パーティション配置戦略とホスト ストライピングについての概要です:

NC2 on AWS - Partition Placement (Multi)
NC2 on AWS - パーティション配置(複数種類)
ストレージ

Nutanix Cloud Clusters on AWSのストレージは、次の2つの領域に分類できます:

  1. コア / アクティブ
  2. ハイバネーション(Hibernation)

コア ストレージは、Nutanixクラスタで期待するものとまったく同じであり、「ローカル」ストレージデバイスをCVMに接続して、Stargateで活用します。

インスタンスのストレージ

「ローカル」ストレージではAWSインスタンス ストアが使われており、 停電やノード障害が発生した場合の完全な復元力がなく、追加の考慮が必要になります。

たとえば、停電またはノード障害が発生した場合、ローカルのNutanixクラスタでは、ストレージはローカル デバイスに永続化されており、ノードや電源がオンラインに戻ると復旧します。 AWSインスタンス ストアの場合、このケースには当てはまりません。

ほとんどの場合、AZ全体が電源を失うまたはダウンするという可能性は低いですが、 センシティブなワークロードの場合は、次のことをお勧めします:

  • バックアップソリューションを活用してS3または永続性のあるストレージに保存する
  • 異なるAZ / リージョン / クラウド(オンプレミスまたはリモート)にある、別のNutanixクラスタにデータを複製する

NC2 on AWSのユニークな機能の1つは、クラスタを「ハイバネート」状態にして、EC2コンピューティング インスタンスを停止している間もデータを永続化できることです。 これは、コンピューティング リソースが不要で、支払いを継続したくないが、データを永続化して後で復元できるようにしたいという場合に役立ちます。

クラスタがハイバネート状態になると、データはクラスタからS3にバックアップされます。 データがバックアップされると、EC2インスタンスが終了されます。 再開または復元の際には、新しいEC2インスタンスがプロビジョニングされ、データがS3からクラスタに読み込まれます。

ネットワーク

ネットワークは、いくつかの中核的な領域に分類できます:

  • ホスト / クラスタのネットワーク
  • ゲスト / UVMのネットワーク
  • WAN / L3ネットワーク
ネイティブ対オーバーレイ

独自のオーバーレイ ネットワークを運用する代わりに、AWSサブネットでネイティブに運用することを決定しました。 これにより、プラットフォームで起動されているVMがパフォーマンス低下なくAWSサービスとネイティブに通信できるようになります。

NC2 on AWSは、AWS VPCにプロビジョニングされます。以下に、AWS VPCの概要を示します:

NC2 on AWS - AWS VPC
NC2 on AWS - AWS VPC
新規VPC対デフォルトVPC

AWSはデフォルトのVPCやサブネットなどを作成します。各リージョンには172.31.0.0/16のIPスキームを使用します。

企業のIPスキームに適合するサブネット、NATやインターネット ゲートウェイなどが関連付けられた、新規VPCを作成することを推奨します。 このことは、VPC(VPCピアリング)や既存のWANにネットワークを拡張する計画がある場合に重要です。 これはWAN上の他のサイトと同じように扱います。

ホストのネットワーク

AWSのベアメタルで実行されているホストは従来どおりのAHVホストであるため、同様にOVSベースのネットワーク スタックを利用します。

以下は、AWSでのAHVホストにおけるOVSスタックの概要を示しています:

NC2 on AWS - OVS Architecture
NC2 on AWS - OVSのアーキテクチャー

OVSスタックは、L3アップリンクブリッジが追加されていることを除いて、従来のAHVホストと同様です。

UVM(ゲストVM)のネットワークでは、VPCサブネットが使用されます。 UVMのネットワークは、クラスタの作成プロセス中、または下記の手順で作成できます:

AWSのVPCダッシュボードで、「subnets」をクリックし、「Create Subnet」をクリックして、ネットワークの詳細を入力します:

NC2 on AWS - Create Subnet
NC2 on AWS - OVSのアーキテクチャーe

注:CIDRブロックは、VPCのCIDR範囲のサブセットである必要があります。

サブネットはVPCからルート テーブルを継承します:

NC2 on AWS - Route Table
NC2 on AWS - ルート テーブル

この場合、ピアVPC内部のトラフィックはVPCピアリング接続を経由し、外部トラフィックはインターネット ゲートウェイを経由します。

完了すると、ネットワークがPrismで使用できるようになります。

WAN / L3ネットワーク

ほとんどの場合の展開では、AWS内部のみでなく、外部の世界(他のVPC、インターネットまたはWAN)と通信する必要があります。

VPCを接続する場合(同じ、または異なるリージョン)、VPC間でトンネリングできるVPCピアリングを使用できます。 注:WAN IPスキームのベスト プラクティスに従っており、VPCとサブネットのCIDR範囲重複がないことを確認する必要があります。

以下は、eu-west-1およびeu-west-2リージョンの、VPC間のVPCピアリング接続を示します:

NC2 on AWS - VPC Peering
NC2 on AWS - VPCピアリング

各VPCのルートテーブルは、ピアリング接続を経由して他のVPCに向かうトラフィックをルーティングします(通信が双方向の場合、これは両側に存在する必要があります)。

NC2 on AWS - Route Table
NC2 on AWS - ルート テーブル

オンプレミスまたはWANへのネットワーク拡張では、VPNゲートウェイ(トンネル)またはAWS Direct Connectが利用できます。

セキュリティ

リソースがフル コントロール セキュリティ外であるクラウドで実行されている場合、データ暗号化とコンプライアンスは非常に重要な考慮事項です。

推奨事項は以下のように特徴付けられます:

  • データ暗号化を有効にする
  • プライベート サブネットのみを使用する(パブリックIP割り当てなし)
  • セキュリティ グループと許可ポートとIP CIDRブロックをロックダウンする
  • より詳細なセキュリティを実現するためには、Flowを活用する
使用法と構成

このセクションでは、NC2 on AWSを構成して活用する方法について説明します。

おおまかなプロセスは、以下の手順となります:

  1. AWSアカウントの作成
  2. AWSネットワークリソースを構成する(必要な場合)
  3. Nutanix Cloud Clusters Portalを介してクラスタをプロビジョニングする
  4. プロビジョニングが完了したら、クラスタリソースを利用する

まだ続く!

Nutanix Cloud Clusters on Azure

Nutanix Cloud Clusters (NC2) on Azureは、ターゲットクラウド環境のベアメタル リソースで実行される、オンデマンドのクラスタを提供します。 これにより、ご存知のNutanixプラットフォームのシンプルさで、真のオンデマンドな収容能力を実現できます。 プロビジョニングされたクラスタは従来のAHVクラスタのように見えますが、クラウドプロバイダーのデータセンターで実行されています。

サポートされる構成

このソリューションは以下の構成に適用できます(このリストはおそらく不完全であり、完全なサポートされている構成のリストについては、ドキュメントを参照してください):

    主なユースケース:
  • オンデマンド / バースト容量
  • バックアップ / DR
  • クラウド ネイティブ
  • 地理的拡張 / DC統合
  • アプリケーションのマイグレーション
  • その他
    管理インターフェイス:
  • Nutanix Cloud Clusters Portal - プロビジョニング
  • Prism Central(PC) - Nutanixの管理
  • Azure Portal - Azureの管理
    サポートされる環境:
  • クラウド:
    • Azure(プライベートプレビュー)
  • ベアメタル インスタンスの種類:
    • AN36
    • AN36P
    アップグレード:
  • AOSの一部
    互換性のある機能:
  • AOSの機能
  • Azureのサービス
主な用語/構造

このセクションでの用語は、以下のように定義されています:

  • Nutanix Cloud Clusters Portal
    • Nutanix Cloud Clusters Portalは、クラスタのプロビジョニング リクエストの処理を受け持ち、Azureやプロビジョニングされたホストとのやりとりを行います。 クラスタ個別の詳細設定を作成し、クラスタ作成処理をして、ハードウェアの問題を修正するのに役立ちます。
  • リージョン
    • 複数のアベイラビリティ ゾーン(サイト)が配置されている地理的な土地または地域です。 リージョンには2つ以上のAZを含めることができます。 これらには、East US(バージニア)やWest US 2(ワシントン)などのリージョンを含めることができます。
  • アベイラビリティ ゾーン(AZ)
    • AZは、低遅延リンクで相互接続された、1つ以上の個別のデータセンターで構成されます。 各サイトは、独自の冗長電源、冷却システム、ネットワークを持ちます。 AZは複数の独立したデータセンターで構成できるため、これらを従来のコロケーションやデータセンターと比較すると、より回復力があると見なされます。
  • VNet
    • テナント向けの、Azureクラウドの論理的に隔離されたセグメントです。 環境を他からセキュアに隔離するための仕組みを提供します。 インターネットや、他のプライベート ネットワーク セグメント(他のVNetやVPN)に公開できます。
クラスタのアーキテクチャー

Nutanix Cloud Clusters(NC2)Portalは、概観的にいうとNC2 on Azureをプロビジョニングし、Azureと対話するためのメイン インターフェイスです。

プロビジョニング手順は、おおまかに下記のステップとして要約できます:

  1. NC2 Portalでクラスタを作成する
  2. 個別入力の展開(例えば、リージョン、AZ、インスタンスの種類、VNet/サブネットなど)
  3. NC2 Portalが、関連するリソースを作成する
  4. Nutanix AHVのHost agentが、NC2 on Azureにチェックインする
  5. すべてのホストが起動すると、クラスタが作成される

以下に、NC2 on Azureの相互作用の概要を示します:

NC2 on Azure - Overview
NC2 on Azure - 概要

以下は、NC2 Portalによる入力と作成されるリソースの概要を示します:

NC2 on Azure - Cluster Orchestrator Inputs
NC2 on Azure - Cluster Orchestratorのインプット
ノードのアーキテクチャー

ホストがベアメタルであるため、通常のオンプレミス展開と同様に、ストレージとネットワークのリソースを完全に制御できます。 ビルディング ブロックとして、Azure Nutanix Ready Nodeを使用しています。 AWSとは異なり、Azureベースのノードは、CVMまたはAHVのための追加サービスを消費しません。

配置ポリシー

NC2 on Azureは、デフォルトで7つのパーティションを持つ、パーティション配置ポリシーを使用します。 ホストは、Nutanixのラックに対応するパーティションに、ストライプ状に配置されています。 これにより、1~2箇所の「ラック」全体障害が発生しても、可用性を維持できます。

以下に、パーティションによる配置戦略および、ホストのストライピングの概要を示します:

NC2 on Azure - Partition Placement
NC2 on Azure - パーティション配置
ストレージ

コア ストレージは、Nutanixクラスタで期待するものとまったく同じであり、「ローカル」ストレージデバイスをCVMに接続して、Stargateで活用します。

インスタンスのストレージ

「ローカル」ストレージとしてローカルフラッシュデバイスがバッキングされているため、停電が発生した場合でも完全に回復力があります。

ネットワーク

NC2は、AzureのFlow Virtual Networkingを利用してオーバーレイネットワークを作成することで、Nutanix管理者による管理作業を容易にし、クラウドベンダー間のネットワークの制約を軽減します。 Flow Virtual Networkingは、オーバーレイ仮想ネットワークを作成することにより、Azureのネイティブネットワークを抽象化するために使用されます。 これによりAzureの基盤となるネットワークが抽象化され、それと同時に、ネットワークの下地(およびそれに関連する機能や操作性)をカスタマーの持つオンプレミスのNutanix展開と整合させることができます。 使い慣れたPrism Centralのインターフェースで、Nutanix内に新しい仮想ネットワーク(仮想プライベートクラウドまたはVPCと呼ばれる)を作成し、RFC 1918の(プライベート)アドレス空間に含まれる任意のアドレス範囲からのサブネットによってDHCPを定義し、NAT、ルーティング、およびセキュリティポリシーを設定します。

Flow Virtual Networkingは、抽象化レイヤーを提供することによりクラウドの制約をマスキングまたは軽減できます。 例として、AzureではVNetごとに1つの委任されたサブネットのみが許可されます。 サブネットの委任により、仮想ネットワークに導入する必要があるAzure PaaSサービスに、特定のサブネットを指定できます。 NC2には、Microsoft.BareMetal/AzureHostedServiceに委任された管理サブネットが必要です。 サブネットがBareMetalサービスに委任されると、NC2 Portalではそのサブネットを使用してNutanixクラスタをデプロイできるようになります。 AzureHostedServiceは、NC2 Portalがベアメタルノードにデプロイとネットワーク構成をするために使用するものです。

ネイティブのユーザー仮想マシンのネットワーキングに使用される各サブネットも、同じサービスに委任する必要があります。 VNetが持てるのは1つの委任されたサブネットのみなので、通信を可能にするためにはVNetを相互にピアリングする必要があり、ネットワーク構成は手に負えなくなります。 Flow Virtual Networkingを使用することで、NC2とAzureで実行されているワークロードが通信できるようにするために必要なVNetの量を大幅に減らすことができます。 Flow Virtual Networkingでは、Azure VNetを1つ消費するだけで500を超えるサブネットを作成できます。

NC2 on Azure - Azure VNet
NC2 on Azure - Azure VNet

企業のIPスキームに適合するサブネット、NATやインターネット ゲートウェイなどが関連付けられた、新規VNetを作成することを推奨します。 このことは、VNet(VNetピアリング)や既存のWANにネットワークを拡張する計画がある場合に重要です。 これはWAN上の他のサイトと同じように扱います。

Prism Central(PC)は、展開後のNutanixクラスタにデプロイされます。 Prism Centralには、Flow Virtual Networkingのコントロールプレーンが含まれています。 PCのサブネットはMicrosoft.BareMetal/AzureHostedServiceに委任されるため、ネイティブのAzureネットワークを使用してPCのIPを配布できます。 PCがデプロイされると、Flow GatewayがPCと同じサブネットにデプロイされます。 Flow Gatewayを使用すると、Flow VPCを使用するユーザー仮想マシンがネイティブAzureサービスと通信できるようになり、仮想マシンが次のようにネイティブAzure仮想マシンと同等になります:

  • ユーザー定義のルート
    • Azureで、カスタムまたはユーザー定義(静的)のルートを作成して、Azureのデフォルトのシステムルートをオーバーライドしたり、サブネットのルートテーブルにルートを追加したりできます。 Azureでは、ルートテーブルを作成してから、ルートテーブルを0個以上の仮想ネットワークサブネットに関連付けます。
  • ロードバランサーのデプロイ
    • Azureネイティブのロードバランサーを使用して、ユーザー仮想マシンによってフロントエンドサービスを提供する機能。
  • ネットワークセキュリティグループ
    • ステートフルファイアウォールポリシーを作成する機能。

Flow Gateway VMは、クラスタからNorth-Southに向かう、すべての仮想マシンのトラフィックを担当します。 展開中に、必要な帯域幅に基づいてFlow Gateway VMのサイズを選択できます。 他のCVMやオンプレミスとの間でのCVMレプリケーションはFlow Gateway VMを介して流れないため、それらのトラフィックはサイジングする必要がないと理解することが重要です。

ネットワークアドレス変換(NAT): AHV/CVM/PC/Azureリソースと通信するユーザー仮想マシンは、Flow Gateway VMの外部ネットワークカードを経由します。 提供されるNATは、ネイティブのAzureアドレスを使用して、すべてのリソースへのルーティングを保証します。 NATの使用が望ましくない場合は、Azureのユーザー定義のルートを使用してAzureリソースと直接通信できます。 これにより、新規インストールでAzureとすぐに通信できるようになりますが、カスタマーにはより高度な構成のオプションも提供されます。

ホストのネットワーク

Azureのベアメタルで実行されているホストは従来どおりのAHVホストであるため、同様にOVSベースのネットワーク スタックを利用します。

以下は、AzureでのAHVホストにおけるOVSスタックの概要を示しています:

NC2 on Azure - OVS Architecture
NC2 on Azure - ホスト ネットワーク

NutanixのOpenv Switchの実装は、オンプレミスでの実装と非常によく似ています。 上の図は、ベアメタルに展開されるAHVの内部アーキテクチャを示しています。 br0ブリッジは、トラフィックをbr0.cluster(AHV/CVMのIP)とbr0.uvms(ユーザー仮想マシンのIP)の間で分割します。

br0.clusterを介したAHV/CVMトラフィックの場合、データパケットを変更せずに、br0.azureブリッジへの単純なパススルーになります。 トップオブラックのスイッチングは、br0.clusterトラフィックへのセキュリティを提供します。 ユーザー仮想マシンのIPトラフィックがbr0.uvmsを介して流れる場合、VLAN-ID変換およびbr0.azureへのパススルートラフィック用にOVSルールがインストールされます。

br0.azureは、OVSボンド(bond)のbr0.azure-upを持ち、ベアメタルに接続された物理NICとのボンドインターフェイスを形成します。 したがってbr0.azureは、ボンドインターフェイスをbr0.uvmsおよびbr0.clusterから隠します。

サブネットの作成

作成するサブネットはビルトインのIPAMを持ち、ネットワークをオンプレミスからAzureに拡張するオプションがあります。 外部アプリケーションがサブネット内のユーザー仮想マシンと直接通信する必要がある場合には、AzureのIPプールからフローティングIPを割り当てるオプションもあり、Flow Gatewayの外部ネットワークからのものです。

NC2 on Azure - OVS Architecture
NC2 on Azure - AzureのIPAM

展開を成功させるには、NC2は、NATゲートウェイまたはアウトバウンドアクセスのオンプレミスVPNを使用して、NC2 Portalへのアウトバウンドアクセスを必要とします。 Nutanixクラスタは、VPNからのみアクセスできるプライベートサブネットに配置できるため、環境への露出は制限されます。

WAN / L3ネットワーク

ほとんどの場合の展開では、Azure内部のみでなく、外部の世界(他のVNet、インターネットまたはWAN)と通信する必要があります。

VNetを接続する場合(同じ、または異なるリージョン)、VNet間でトンネリングできるVNetピアリングを使用できます。 注:WAN IPスキームのベスト プラクティスに従っており、VNetとサブネットのCIDR範囲重複がないことを確認する必要があります。

オンプレミスまたはWANへのネットワーク拡張では、VNetゲートウェイ(トンネル)またはExpress Routeが利用できます。

使用法と構成

このセクションでは、NC2 on Azureを構成して活用する方法について説明します。

おおまかなプロセスは、以下の手順となります:

  1. アクティブなサブスクリプションをセットアップする。
  2. My Nutanix アカウントの作成し、NC2をサブスクライブする。
  3. Azureリソースプロバイダーを登録する。
  4. 新しいサブスクリプションへの「Contributor(共同作成者)」アクセスがある、Azure ADでの「アプリの登録」を作成する。
  5. DNSを構成する。
  6. リソースグループを作成する、または既存リソースグループを再利用する。
  7. 必要なVNetとサブネットを作成する。
  8. 2つのNATゲートウェイを構成する。
  9. Nutanixクラスタに必要なVNetピアリングを確立する。
  10. AzureアカウントをNC2 Consoleに追加する。
  11. NC2 Consoleを使用してAzureにNutanixクラスタを作成する。

More to come!

Book of Storage Services

Volumes (ブロックサービス)

Nutanix Volumesは、バックエンドにあるDSFストレージを、iSCSI経由で外部ユーザー(ゲストOS、物理ホスト、コンテナなど)に提供する機能です。

本機能によって、オペレーティングシステムは、DSFにアクセスしてストレージ機能を利用できるようになります。この導入シナリオにおいて該当OSは、ハイパーバイザーを経由することなく、Nutanixに直接アクセスすることになります。

Volumesの主要なユースケース:

  • 共有ディスク
    • Oracle RAC、Microsoft Failover Clusteringなど
  • ファーストクラスのエンティティとしてのディスク
    • 実行コンテキストが短命かつデータが重要な場合
    • コンテナなど
  • ゲスト内iSCSIイニシエータ
    • ベアメタルのコンシューマ
    • vSphere上のExchange(Microsoftのサポートのため)
資格要件を満たしたオペレーティングシステム

本ソリューションは、iSCSI仕様に準拠しており、QAによって以下のオペレーティングシステムが検証済みとなっています。

  • Microsoft Windows Server 2008 R2, 2012 R2
  • Red Hat Enterprise Linux 6.0+
Volumesの構成

Volumesは、以下のエンティティで構成されています:

  • データサービスIP: iSCSIログイン リクエストで使用されるクラスタ全体のIPアドレス (4.7で導入)
  • ボリュームグループ: iSCSIのターゲットで、集中管理、スナップショット、ポリシーアプリケーションの対象となるディスクデバイスのグループ
  • ディスク: ボリュームグループ内のディスク(iSCSIターゲットのLUNとして見える)
  • アタッチメント: ボリュームグループに対する特定のイニシエータIQNアクセスを許可
  • シークレット: CHAP/Mutal CHAPの認証情報に使用するシークレット

注意: バックエンドでは、VGのディスクは単にDSF上のvDiskとなります。

前提

設定を行う前に、セントラルディスカバリ / ログインポータルとして機能するデータサービスIPを設定する必要があります。

設定は「Cluster Details(クラスタ詳細)」ページから行います。(歯車アイコン -> Cluster Details)

Volumes - Data Services IP
Volumes - データサービスIP

NCLI / API経由でも設定が可能です:

ncli cluster edit-params external-data-services-ip-address=<DATA SERVICES IP ADDRESS>

ターゲットの作成

Volumesを使用するためには、まずiSCSIのターゲットとなる「Volume Group(ボリュームグループ)」を作成する必要があります

「Storage(ストレージ)」ページの右側にある「+ Volume Group(ボリュームグループの追加)」をクリックします:

Volumes - Add Volume Group
Volumes - ボリュームグループの追加

VG詳細を設定するメニューが表示されます:

Volumes - Add VG Details
Volumes - VG詳細の設定

次に「+ Add new disk(ディスクの追加)」をクリックして、ターゲット(LUNとして見える)にディスクを追加します。

メニューが表示されたら、ターゲットとなるコンテナとディスクサイズを選択します:

Volumes - Add Disk
Volumes - ディスクの追加

「Add(追加)」をクリックし、必要に応じて繰り返しディスクを追加します。

詳細を設定し、ディスクを追加したら、ボリュームグループをVMまたはイニシエータIQNにアタッチします。これによって、VMがiSCSIターゲットにアクセスできるようになります(未知のイニシエータからのリクエストは拒否されます):

Volumes - Add Initiator IQN / VM
Volumes - イニシエータIQN / VM

「Save(保存)」をクリックします。これでボリュームグループの設定は完了です!

ACLI / API経由でも、同様の対応が可能です:

VGの作成

vg.create <VG Name>

VGにディスクを追加

vg.disk_create <VG Name> container=<CTR Name> create_size=<Disk size, e.g. 500G>

イニシエータIQNをVGにアタッチ

vg.attach_external <VG Name> <Initiator IQN>

パスの高可用性 (HA)

前述の通り、データサービスIPはディスカバリに使用されます。 これによって、個々のCVM IPアドレスを知る必要なく、1つのアドレスのみを使用できます。

データサービスIPは、現状のiSCSIリーダーに割り当てられます。 障害が発生すると、新しいiSCSIリーダーが選択され、データサービスIPが割り当てられます。 これにより、ディスカバリポータルは常時使用可能な状態になります。

iSCSIイニシエータは、データサービスIPによりiSCSIターゲットポータルとして設定されます。ログインリクエストが発生すると、プラットフォームはiSCSIログインを正常なStargateにリダイレクトします。

Volumes - Login Redirect
Volumes - ログインのリダイレクト

アクティブの(アフィニティがある) Stargateに障害が発生すると、イニシエータはデータサービスIPデータサービスIPへのiSCSIログインをリトライし、別の健全なStargateにリダイレクトされます。

Volumes - Failure Handling
Volumes - 障害対応

アフィニティがあるStargateが復旧して安定すると、現状アクティブとなっているStargateはI/Oを休止し、アクティブなiSCSIセッションを切断します。イニシエータが再度iSCSIログインを試みると、データサービスIPはそれをアフィニティがあるStargateにリダイレクトします。

Volumes - Failback
Volumes - フェイルバック
ヘルス監視とデフォルト

DSFに対するメカニズムと同様に、VolumesにZookeeperを使用して、Stargateのヘルス状態を監視します。

フェイルバックのデフォルト間隔は120秒となっています。つまり、元々接続していたStargateが2分間以上健全な状態を保てば、セッションを休止して切断するということです。他のログインも、接続中のStargateに戻されます。

この仕組みによって、パスのHAのためのクライアント側マルチパス(MPIO)設定はもはや必要ありません。 ターゲットに接続する場合、MPIOを有効化するために「Enable multi-path(マルチパスを有効化)」にチェックを入れる必要はありません。

Volumes - No MPIO
Volumes - MPIOは不要
マルチパス

iSCSIプロトコルに準拠するためには、イニシエータとターゲット間で1つターゲットに1つのiSCSIセッション(TCP接続)となる必要があります。つまり、Stargateとターゲットが、1:1の関係になるということです。

4.7では、1つのアタッチイニシエータに対して32(デフォルト)の仮想ターゲットが自動生成され、ボリュームグループ (VG) に追加された各ディスクデバイスに割り当てられます。これにより、1つのディスクデバイスに対して、1つのiSCSIターゲットが提供されます。以前は、複数のVGをそれぞれのディスクに対して作成することで実装を行っていました。

ACLIやAPIでVGの詳細を見てみると、各アタッチメントに対して、32の仮想ターゲットが作成されていることが分かります:

            

attachment_list { external_initiator_name: "iqn.1991-05.com.microsoft:desktop-foo" target_params { num_virtual_targets: 32 } }

例として、3つのディスクデバイスを追加したVGを作成しました。クライアントでディスカバリを実行すると、それぞれのディスクデバイスに対する個々のターゲットが確認できます。(サフィックスは -tgt[int])

Volumes - Virtual Target
Volumes - 仮想ターゲット

これでディスクデバイスは、自身のiSCSIセッションを持つことになり、これらのセッションは複数のStargateでホストすることが可能であるため、拡張性やパフォーマンスの向上につながります:

Volumes - Multi-Path
Volumes - マルチパス

iSCSIセッションが確立されている間(iSCSIログイン)、各ターゲットに対するロードバランシングが発生します。

アクティブパス

以下のコマンドを使って、仮想ターゲットをホストしている、有効なStargateを確認することができます(ホストしているStargateのCVM IPを表示):

Windows

Get-NetTCPConnection -State Established -RemotePort 3205

Linux

iscsiadm -m session -P 1

AOS 4.7では、簡単なハッシュ関数を使用してクラスタノード全体にターゲットを分散しています。 AOS 5.0では、これがDynamic Schedulerに統合され、必要に応じて再バランスを取るようになっています。 また、どのノードを使用するかについては、該当ノードが正常である限り自由に設定を行うことができます。

SCSI UNMAP (TRIM)

Volumesでは、SCSI T10仕様にあるSCSI UNMAP (TRIM) コマンドをサポートしています。 このコマンドを使用することで、削除済みブロックのスペース再利用が可能となります。

Files (ファイルサービス)

Nutanix Filesによって、Nutanixプラットフォームを高可用性ファイルサーバーとして利用することができます。 ユーザーは、単一のネームスペースにホームディレクトリやファイルをストアできます。

サポート対象構成

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

    主なユースケース:
  • ホームフォルダー / ユーザープロファイル
  • ファイルストレージ
  • メディアサーバー
    管理インターフェイス:
  • Prism Element (PE)
    ハイパーバイザー:
  • AHV
  • ESXi(AOS 5.0 以降)
    アップグレード:
  • Prism
    互換性のある機能:
  • Nutanix スナップショットとDR
  • Windowsの「以前のバージョン」 (WPV:Windows Previous Versions)を含む、ファイルレベルスナップショット
  • セルフサービスリストア
  • CFTバックアップ
    ファイルプロトコル:
  • CIFS 2.1
  • NFS v4
  • NFS v3 (AFS 3.5 現在)
Files の構成要素

本機能は、いくつかのハイレベルな要素から構成されています:

  • ファイルサーバー
    • ハイレベルな名前空間(namespace)。 各ファイルサーバーは、それぞれのFiles VM(FSVM)を持っています
  • シェア
    • シェア (Share) には、ユーザーがアクセスできます。ファイルサーバーは、複数のシェアを持つことができます(部門別シェアなど)
  • フォルダー
    • ファイルストレージのためのフォルダー。フォルダーは、FSVM全体で共有されます

下図は、構成要素の連関についての概要を示したものです:

Files Mapping
Files構成要素のマッピング

Nutanix Filesでは、Nutanixプラットフォームと同じ分散メソドロジーを踏襲することで、可用性と拡張性を保証しています。ファイルサーバーには、少なくても3つのFSVMが設定されます。

以下にコンポーネントの詳細を示します:

Files Detail
Files詳細

FSVMは、論理的なファイルサーバー インスタンスとして統合され、Filesクラスタと呼ばれることもあります。 ひとつのNutanixクラスタには、複数のFilesクラスタを作成できます。 FSVMは、設定プロセスの途中で透過的にデプロイされます。

下図は、AOSプラットフォームにおけるFSVMの詳細を示したものです:

Files Detail
FSVM 配置アーキテクチャー
認証と権限

Nutanix Files機能は、Microsoft Active Directory(AD)およびDNSと完全に連携を取ることができます。 このため、ADに関する全てのセキュアな認証と権限管理機能の活用が可能となります。 共有許可、ユーザーやグループの管理については、従来のWindows MMCを使用して実施されます。

インストレーションプロセスの途中で、以下のAD / DNSオブジェクトが生成されます:

  • ファイルサーバーのためのADコンピューターアカウント
  • ファイルサーバーと各FSVMのためのADサービスプリンシパル名 (SPN)
  • ファイルサーバーが全てのFSVMを示すDNSエントリー
  • 各FSVMのためのDNSエントリー
ファイルサーバー生成のためのADの権限

ファイルサービスを導入し、ADおよびDNSオブジェクトを生成するためには、ドメイン管理者または同等の権限を持ったユーザーアカウントを使用する必要があります。

高可用性 (HA)

各FSVMは、Volumes APIを使って、ゲスト内からのiSCSI経由でデータ ストレージにアクセスします。 これにより、FSVMに障害が発生した場合でも、iSCSIターゲットへの接続が可能となります。

以下にFSVMストレージの概要を示します:

FSVM Storage
FSVMストレージ

パスの高可用性を確保するために、FSVM内ではDM-MPIOを使用し、デフォルトでローカルCVMへのパスを有効にします:

FSVM MPIO
FSVM MPIO

ローカルCVMが利用できなくなった場合(パスの障害など)、DM-MPIOは、フェイルオーバーパスの1つを有効化してリモートCVMに接続し、I/Oを引き継ぎます。

FSVM MPIO Failover
FSVM MPIOフェイルオーバー

ローカルCVMが復旧して正常稼動すると、こちらがアクティブパスであると認識され、ローカルI/Oを提供するようになります。

通常の運用環境では、各FSVMのパッシブ接続されたデータスストレージとの通信は、それぞれのVGとの通信によって実現されます。 それぞれのFSVMは、クライアントがDFS Referral(分散ファイルシステム紹介)プロセスの一部としてFSVMと通信するためのIPを持ちます。 DFS Referralプロセスが共有フォルダーをホストしている正しいIPに接続するため、クライアントが個別のFSVMのIPを認識する必要がありません。

FSVM Normal Operation
FSVM通常の運用状態

FSVMに「障害」(メンテナンスや電源断など)が発生すると、該当FSVMのVGとIPは、他のFSVMに引き継がれて高可用性を維持します。

以下に、障害FSVMのIPとVMに関する引継ぎの流れを示します:

FSVM Failure Scenario
FSVM障害時のシナリオ

障害のあったFSVMが復旧し安定すると、再度IPとVGを取得してクライアントI/Oの処理を継続します。

Objects(オブジェクトサービス)

Nutanix Objectsは、S3準拠のAPIを介して非常にスケーラブルで耐久性のあるオブジェクトサービスを提供します(S3の補足情報: LINK)。 Nutanix ObjectsがNutanixプラットフォーム上にデプロイされると、重複排除、圧縮、レプリケーションなどのAOS機能を利用できます。 ObjectsはAOS 5.11で導入されました。

サポートされる構成

ソリューションは以下の構成に適用できます(以下のリストは一部です。全てを確認する際には、ドキュメントをご覧ください):

    主なユースケース:
  • バックアップ
  • ビッグデータ/分析
    管理インターフェイス:
  • Prism Central (PC)
    ハイパーバイザー:
  • N/A - Nutanix MSPで実行(MSPがサポートするハイパーバイザーに依存)
    アップグレード:
  • LCM
    互換性のある機能:
  • 追記予定
    オブジェクトプロトコル:
  • S3 (version 4)
Nutanix Microservices Platform (MSP)

Nutanix Objectsは、Nutanix Microservices Platform(MSP)を活用して実行される最初のコア サービスの1つです。

Nutanix MSPは、Identity and Access Management(IAM)やロードバランシング(LB)といった、Objectsのコンポーネントに関連付けられたコンテナとプラットフォームサービスをデプロイするための共通フレームワークとサービスを提供します。

主な用語

次のこのセクション全体で使用される主要な用語は、以下のように定義されています:

  • バケット
    • ユーザーに公開された組織単位であり、オブジェクトを含む。(ファイルサーバーでのファイルの共有とみなせる)。 デプロイメントには、複数のバケット(例えば、部門、区画など)を含めることができ、通常はそうなる。
  • Object
    • API(GET / PUT)をインターフェイスとするストレージとアイテムの実際の単位(blob)。
  • S3
    • アマゾンウェブサービス(AWS)で導入された、元のオブジェクトサービスを説明する用語。 現在は、オブジェクトサービスの同義語として使用されている。 S3は、プロジェクト全体で高度に活用されている、オブジェクトAPIの定義にも使用される。

この図は、概念構造のマッピングを示します:

Objects - Hierarchy
Objects - Hierarchy
Objectsの構成

この機能は、いくつかの大まかな構成要素で構成されています:

  • ロードバランサー
    • ロードバランサーはNutanix MSPの一部であり、サービスおよびデータ リクエストのプロキシとして働きます。 これによりサービスの高可用性が確保され、オブジェクトコンテナ間の負荷分散が行われます。
  • サービスマネージャー
    • サービスマネージャーは、すべてのUIリクエストのエンドポイントとして機能し、オブジェクトストアのインスタンスを管理します。 また、インスタンスから統計を収集する役割もあります。
  • メタデータサーバー
    • メタデータサーバーは、Nutanix Objectsのデプロイに関する、すべてのメタ情報(例えば、バケット、オブジェクトなど)を格納します。 NutanixがRocksDBをもとに開発したKey-ValueストアであるChakrDBを利用します。ChakrDBはストレージにNutanix ABSを使用します。
  • オブジェクトコントローラー
    • オブジェクトコントローラーは、オブジェクトデータを管理し、メタデータの更新をメタデータサーバーと調整します。 Storage Proxy APIを介してStargateのインターフェイスになります。
  • リージョンマネージャー
    • リージョンマネージャーは、DSF上にあるすべてのオブジェクトストレージ情報(リージョンなど)を管理します。
  • リージョン
    • リージョンは、オブジェクトと、それに対応するNutanix vDiskでの場所の高レベルでのマッピングを提供します。 vDisk ID、オフセット、および長さと同様のものです。
  • Atlasサービス
    • Atlasサービスは、オブジェクトへのライフサイクルポリシーの実施とガベージコレクションを担当します。

この図は、Objectsのサービス アーキテクチャーの詳細を示します:

Objects - Architecture
Objects - Architecture

Objects固有のコンポーネントは、Nutanix Greenで強調されています。 オブジェクトには「上書き」の概念がないため、CRUD(Create/Replace/Update/Delete)ではなくCxxD(Create/x/x/Delete)です。 一般的なオブジェクトの「上書き」の方法は、新しいリビジョンを作成するか、新しいオブジェクトを作成してそのオブジェクトをポイントすることです。

オブジェクトストレージとI/O

オブジェクトは、リージョンと呼ばれる論理構造に格納されます。 リージョンは、vDisk上の固定長セグメントの領域です。

この図は、vDiskとリージョンの関係についての例を示します:

Objects - vDisk Region
Objects - vDisk Region

小さいオブジェクトは単一のリージョンのチャンク(リージョンID、オフセット、長さ)に収まる場合がありますが、大きいオブジェクトはリージョンをまたいでストライプ化されることがあります。 ラージオブジェクトが複数のリージョンにストライプ化されている場合、それらのリージョンを複数のvDiskでホストして、複数のStargateにて同時に利用できます。

この図は、オブジェクト、チャンク、リージョンの関係についての例を示します:

Objects - Object Chunk
Objects - Object Chunk

オブジェクトサービス機能は、Nutanixプラットフォームと同じ分散方式によって、可用性と拡張性を保証します。 Objectsのデプロイでは、最低3台のオブジェクトVMがデプロイされます。

Book of Network Services

本書では、Nutanix によって提供されるネットワークとネットワークセキュリティのサービスについて説明します

  • Flow Network Security
  • Security Central
  • Flow Virtual Networking

これらの製品を別の名前で聞いたことがあるかたのために、ここで少し各製品の歴史と概要を示します。

我々は、カテゴリとポリシーベースマイクロセグメンテーションのソリューションとしてNutanix Flowをリリースしました。 以前はFlowとして知られていた、ステートフル、分散、そしてマイクロセグメンテーションのファイアウォールは、現在はFlow Network Securityと呼ばれています。

オンプレミスとクラウド環境の両方に対して、セキュリティプランニング、脅威検出、コンプライアンス監査を提供するために、NutanixはSaaSベースで提供されるBeamをリリースしました。 Beamのセキュリティコンポーネントは、現在はSecurity Centralとして知られています。

重複するIPアドレスに対応する本当のマルチテナントネットワーキングや、セルフサービスによるネットワークプロビジョニングのためにNutanixFlow Networkingをリリースしましたが、現在ではFlow Virtual Networkingと呼ばれています。

Flow Network Security

Flow Network Securityは、分散かつステートフルなファイアウォールとして、AHVプラットフォームで稼動する仮想マシン間や外部のエンティティとのきめ細かなネットワーク監視とエンフォースメントを可能にします。

サポートされている構成

このソリューションは以下の構成に適用できます:

    主なユースケース:
  • マイクロセグメンテーション
    管理インターフェイス:
  • Prism Central (PC)
    サポートされる環境:
  • オンプレミス:
    • AHV
  • クラウド:
    • Nutanix Cloud Clusters on AWS
    アップグレード:
  • Flow SecurityとしてLCMに組み込まれている
    互換性のある機能:
  • サービスチェイニング(Service Chaining)
  • Security Central
  • Calm

Flow Network Securityの設定については、Prism Centralでポリシーを定義し、仮想マシンにカテゴリを割り当てる形で行います。 Prism Centralは、接続されている多くのAHVクラスタのセキュリティーポリシーとカテゴリをひとつの場所で定義できます。 それぞれのAHVホストについては、分散適用するための要件によりOVSとOpenFlowを使用してルールを実装します。

実装の構成

Flow Network Securityには、いくつかの重要な構成要素があります:

カテゴリ

カテゴリとは、ポリシーの適用対象となる仮想マシングループを定義するために使用される、シンプルなキー/バリューのペアです。 一般的なカテゴリは、環境、アプリケーションの種類、そしてアプリケーションの層です。 仮想マシンの識別に役立つように任意のキー/バリュータグをカテゴリとして使用できますが、アプリケーションセキュリティポリシーのためにはAppTypeやAppTierといったカテゴリが必要です。

  • カテゴリ: 「キー: バリュー」形式のタグ
  • キーの例: AppType、AppTier、Group、Location

例えば、商用環境のデータベースサービスを提供する仮想マシンには、以下のようにカテゴリが割り当てられる場合があります:

  • AppTier: Database
  • AppType: Billing
  • Environment: Production

これらのカテゴリは、適用するルールやアクションを決定するためのセキュリティポリシーに利用できます。 カテゴリはFlow Network Securityだけでなく、保護ポリシー(Protection Policy)でも同じカテゴリが使用できます。

セキュリティポリシー

セキュリティポリシーは、定義済みのカテゴリ間で許可の内容を決定するためのルール定義です。

Flow Network Security - Rules
Flow Network Security - ルール

セキュリティポリシーには、以下に示すような幾つかのタイプが存在します:

  • 検疫ポリシー (Quarantine Policy)
    • 特定の仮想マシンまたはカテゴリへの全てのトラフィックを拒否します: Strict
    • 調査のための特定のトラフィックを除く全てのトラフィックを拒否します: Forensics
    • 例1: 仮想マシン A、B、Cがウィルスに感染した場合に、ウィルスのネットワーク感染を阻止するため、その仮想マシンを隔離します。
    • 例2: 仮想マシン A、B、Cが感染しました。それらを隔離しますが、解析のためにセキュリティチームの仮想マシンへの接続は許可します。
  • 分離ポリシー (Isolation Policy)
    • カテゴリ間のトラフィックは拒否し、カテゴリ内のトラフィックについては許可します
    • 例: テナントAをテナントBとクローン環境から分離し、通常のネットワーク通信に影響を与えずに並列実行を可能にします。
  • アプリケーションポリシー (App Policy)
    • これは一般的な5タプルのルールで、許可する通信を、トランスポート(TCP/UDP)、ポート、そしてソース/デスティネーションによって定義できます。
    • Allow Transport: Port(s) To,From
    • 例: Location:HQカテゴリを割り当てた仮想マシンから、AppTier:Webカテゴリを割り当てた仮想マシンへのTCP 443を許可します。
  • VDI Policy
    • ログインしたユーザのADグループに基づいてVDI仮想マシンにカテゴリを割り当てる、アイデンティティベースファイアウォールです。
    • 割り当てられたADグループを基にポリシーを実装します。

以下は、Flow Network Securityを使った、サンプルアプリケーションにおけるトラフィックコントロールの例です:

Flow Network Security - Example Application
Flow Network Security - サンプルアプリケーション
ポリシーの状態

ポリシーの状態(Policy State)は、ルールが一致した場合にどんなアクションを取るかを決定します。Flow Network Securityには、2種類のステートがあります:

  • Enforce
    • 定義されたフローのみを許可し、それ以外の全てをドロップするポリシーを適用します。
  • Monitor
    • 全てのフローを許可しますが、ポリシーを可視化するページで、ポリシーに違反してたであろうパケットをハイライト表示します。
ルールの適用

Flow Network Securityのポリシーは、パケットがUVMを出て、他の仮想マシンに到達する前に適用されます。 これは、AHVホストのマイクロセグメンテーションブリッジ(br.microseg)で発生します。

Flow Network Security - Rule Order Overview
Flow Network Security - ルール順序の概要

ポリシーはカテゴリを基に構築されますが、ルールの適用は検出された仮想マシンのIPアドレスをもとに行われます。 Flow Network Securityの役割は、全ての仮想マシンに割り当てられているカテゴリとポリシーを評価し、保護された仮想マシンの稼働しているホスト(またはホスト群)のbr.microsegブリッジに正しいルールをプログラムすることです。 Nutanix AHV IPAMを使用している仮想マシンは、仮想マシンがパワーオンされた際に、NICがプロビジョニングされるとすぐにIPアドレスが分かりルールがプログラムされます。 Nutanix Acropolisのプロセスは、スタティックIPまたは外部のDHCPを利用する仮想マシンのIPアドレスを検出するために、DHCPとARPのメッセージをインターセプトします。 それらの仮想マシンは、仮想マシンのIPアドレスが分かるとすぐにルールが適用されます。

検疫、アプリケーション、そしてVDIポリシーのルール評価は、検出したIPv4のアドレスをベースにしています。

隔離ポリシーのルール評価は、検出したIPv4のアドレスと、仮想マシンのMACアドレスの両方をベースにしています。

評価の順序は、次の順序での最初のマッチに基づきます。

  • 検疫(Quarantine)
  • 隔離(Isolation)
  • アプリケーション(App)
  • VDI
Flow Network Security - Policy Order
Flow Network Security - ポリシーの順序

最初にマッチしたポリシでアクションが実行され、それ以降の処理はすべて停止します。 たとえば、トラフィックがMonitorモードになっている隔離ポリシーに出会った場合は、転送するアクションが行われ、許可および監視されたことがログ出力されます。 たとえ、このトラフィックをブロックするアプリケーションやVDIのポリシーが以降にあったとしても、それ以上のルールは評価されません。

さらに、仮想マシンは1つのAppTypeカテゴリのみに所属することができ、 AppTypeカテゴリは、単一のAppTypeのみが設定できるポリシーのターゲットグループに入れることができます。 つまり、仮想マシンは1つのAppTypeポリシーのターゲットグループにのみに所属することができます。 仮想マシンで受信/送信する全てのトラフィックは、この単一のAppTypeポリシーで定義する必要があります。 現在、仮想マシンが複数のアプリケーションポリシーの中心にあるというコンセプトではなく、したがって、アプリケーションポリシー間で競合や評価順序が発生することはありません。

Security Central

Nutanix Security Centralは、マイクロセグメンテーションのセキュリティプランニング、脅威検出アラート、そして継続的なコンプライアンス監視を提供する、Software as a Service(SaaS)製品です。 複数の機械学習(ML)モデルと、Louvain法、ARIMA、ツリーベース、クラスタリングのようなアルゴリズムを使用し、Security Centralは500を超える監査チェックとセキュリティのベストプラクティスに基づいて、オンプレミスの展開へのセキュリティに関する洞察を提供します。

Security Central Portal(https://flow.nutanix.com/securitycentral)は、クラウドとオンプレミスインフラストラクチャーで一般的そしてリスクの高い構成間違いを調査するために、インベントリ(棚卸し)と構成アセスメントを提供します。 このインベントリとコンプライアンス追跡ツールを組み合わせることで、セキュリティポスチャ監視も提供されます。 Security Centralのユーザーは、システム定義されたSQLのようなカスタムクエリを使用することで、セキュリティの状態についてその瞬間の洞察を得ることもできます。

最後になりますが、オンプレミスのAHVクラスタから取り込んだネットワークフローの情報により、機械学習によるトラフィックパターン分析に基づくほぼリアルタイムでの脅威検出を提供します。

サポートされる環境

  • オンプレミスのNutanix
    • Flow Network Securityが有効化されたAHVを使用するプライベートクラウド
  • パブリッククラウド: AWSとMicrosoft Azure
    • パブリッククラウドインフラストラクチャー内のリソースとサービスを監視

管理インターフェース

  • Flow Security Central SaaS UI
  • Flow Security Central VM(FSC VM)
    • 初期構成と、必要に応じたアップグレード

実装の構成

Security Centralは、セキュリティ監視と管理フレームワークを提供するために、いくつかの新しい構成を導入しています。

導入された2つの要素は次のとおりです:

  • Flow Security Central VM(FSC VM)[オンプレミスのNutanixのみで必要]
    • 初期構成時のみ使用
    • IPFIXログ収集
    • インベントリ収集
    • セキュリティポリシー構成のプッシュ
  • Security Central SaaS
    • セキュリティポスチャ監視
    • ユーザーとネットワークの異常検知
    • コンプライアンスのレポーティング
    • マイクロセグメンテーションのセキュリティプランニング
    • マルチクラウドのインベントリ

アップグレード

  • Security CentralはSaaSプラットフォームであるため自動的
    • 新機能がリリースされると、次回のログインから利用可能になります。
  • 時折、機能強化のためにオンプレミスのFSC VMのアップグレードが必要になることがあります。
    • アップグレードは、Flow Security Central VM UIのSettingsページから実行できます。
  • 最新のFSC VMのイメージ("FSCVM Image with GUI"と"FSCVM Image Server only"の両方)は、Nutanix Portal にあります。

Security Centralアーキテクチャーの概観

Security Centralアーキテクチャーの概観
Security Centralアーキテクチャーの概観
Security Centralのハイレベルアーキテクチャーの詳細

Security CentralはFSC VMという新しいサービス仮想マシンを導入しており、これはオンプレミスのNutanixのためのセキュリティ監視を有効化するために必要です。 FSC VMはプロキシとして動作し、オンプレミスのクラスタからの情報を集約します。 それから、その情報を安全なネットワーク接続を介してSecurity Centralに送信します。

FSC VMは、環境と仮想マシン(メタデータ)についてのインベントリ情報を収集します。 Security Centralは、インストールされているソフトウェアパッケージやバージョンといった、仮想マシンが所有するデータの収集はしませんが、Qualysのようなパートナーのエージェントとのインテグレーションにより、利用可能なアラートを充実させられます。

インストールしたら、管理者はFSC VM UIに接続してネットワークログの収集を有効化します。 その後、FSC VMはPrism Centralに、そのPrism Centralインスタンスによって管理されるすべてのAHVクラスタでIPFIXエクスポーターを有効化するように指示します。

FSC VMはPrism Centralから、すべての登録されているクラスタと仮想マシンについてのクラスタインベントリ情報も収集します。 収集されるインベントリ情報には、仮想マシン名、接続されたネットワークの情報、構成情報、そしてPrism Centralが仮想マシンに割り当てられるカテゴリなどの項目が含まれます。 インベントリのポーリングは3時間ごとに繰り返され、SaaSポータルは変更の記録と分析を行えます。

インベントリとIPFIXログは、HTTPS/TLS接続を使用して安全にSecurity CentralのSaaS環境に送信されます。 IPFIXログを15分間隔で送信することで、FSC VMはバッチ単位の増分でデータを送信できるため、FSC VMに必要なストレージ容量が削減され、クラウドへのネットワークの制約が軽減されます。

管理者は必要に応じて、FSC VMを使用して、要求されたインベントリ更新を手動でクラウドにプッシュできます。

FSC VMは、Prism Central(PC)によって管理されるクラスタ数に関係なく、展開されたPCごとに必要です。 FSC VMは、Prism Centralへの内部通信と、FSC-SaaSポータルへのアウトバウンド通信を容易にします。 Security Centralは、コンポーネント間の通信で以下のTCPポートを使用します。

ファイアウォールで、次のポートが開放されていることを確認してください:

  • FSC VMがPrism Central VMに接続するためのTCP 9440ポート
  • FSC VMが*.nutanix.comと *.amazonaws.com に接続するためのTCP 443ポート

FSCのプラットフォームは、厳格なセキュリティ管理を受けています。 Flow Security Centralのコンプライアンス認定を参照してより詳細を知るためにNutanix Trustを訪れてください。

Flow Security Central VMを構成するための要件:

Flow Security Central VMの構成要件を確実に満たすためには、Security Central Guideを調べてください。

主なユースケース

  • 監視と可視化
    • マルチクラウドダッシュボード、資産インベントリ、レポート、アラート
    • 監査と修復
    • リアルタイムの自動セキュリティ監査を使用した、Nutanix環境とパブリッククラウドに関する洞察
  • コンプライアンス
    • 継続的な環境監視、自動化されたコンプライアンスチェック、STIG/PCI/HIPAAのためのアセスメント
  • セキュリティプランニング
    • 仮想マシン同士のネットワークトラフィックの視覚化、ワークロードの分類、自動化されたセキュリティポリシーの推奨
  • 違反の調査
    • SQLのようなクエリ言語を使用した詳細調査の実施
  • 脅威検出アラート
    • ネットワークおよびユーザーベースの異常検出。 EUBA(End user behavior analysis)が内部および外部のセキュリティ脅威の検出に役立つ

Security Centralの主な機能

メインダッシュボード

Security Centralへの正常なログインの後に表示される最初の画面は、メインダッシュボードです。 そのダッシュボードは、Security Centralによって監視および警告された多くの領域の概観を提供します。 より詳細な表示は、個々のウィジェットから起動できます。

Security Central Main Dashboard
Security Centralのメインダッシュボード
監査と修復

セキュリティ監査を利用することで、オンプレミス展開のセキュリティに関する深い洞察が提供されます。 Security Centralは、環境に500を超えるすぐに利用可能な(out-of-the-boxの)自動化されたセキュリティ監査を実行し、監査の失敗については修正手順とともに報告します。

Security Centralの監査チェックは、次のカテゴリとNutanixのセキュリティベストプラクティスに準拠しています:

  • アクセスセキュリティ
    • 非特権アクセスまたはアクセス監査欠如の可能性があるアイテムの構成とアラート
  • データセキュリティ
    • 保存データの暗号化(DARE:Data-at-Rest Encryption)が有効になっていないNutanixクラスタ。 DAREは、暗号化キーを所有していないシステムやユーザーによるデータへの許可されていないアクセスを防止するための、インフラストラクチャを保護するために非常に重要なコンポーネントです。
  • ホストセキュリティ
    • バックアップ保護が有効になっていないNutanix仮想マシンは、仮想マシンがランサムウェアに感染した場合の回復を困難にします。
  • ロギングと監視
    • Prism Centralの重要なアラートで確認対応がされておらず、アラートが無視されているか見逃されていることを示している可能性があります。 これらのアラートは、インフラストラクチャを危険にさらしうる潜在的なリスクを示している可能性があります。
  • ネットワークセキュリティ
    • 仮想マシンはすべての送信元からのすべてのトラフィックを許可しており、これにより悪意のある攻撃者が仮想マシンを危険にさらして環境に侵入するための非常に大きな攻撃対象領域が作られます。

常に更新される組み込みの監査に加えて、Security Centralは、Common Query Language(CQL)を使用して監査とレポートをカスタマイズする機能を提供しています。 これにより、さまざまな属性についてクラウドインベントリでCQLクエリを実行し、特定のユースケースのための監査チェックを作成できます。

コンプライアンス(Compliance)

Nutanixの多くのカスタマーにとって、コンプライアンスは非常に重要です。 コンプライアンスを維持することで、会社の運用環境が従うべき管理基準が満たされていることを検証できます。

コンプライアンスのために環境を監視することは、困難で時間がかかる場合があります。 絶えず変化する要件、規制、環境を常に把握するには、継続的なコンプライアンス監視機能が必要です。 カスタマーには、これらのチェックを自動化することで、コンプライアンス違反への対処において、簡潔なビューと解決時間の短縮という利益があります。

Security Centralは、PCI-DSS、HIPAA、NISTなどの一般的な規制フレームワークと、Nutanix STIGポリシーを使用したNutanixセキュリティベストプラクティスの監査チェックを提供します。

コンプライアンスダッシュボードは、監視されている各フレームワークのコンプライアンススコアを提供します。 スコアの要素をさらに調査して、監視および監査されているフレームワークの要素、合格したチェックの数、および失敗したチェックの数を表示できます。 コンプライアンスビューには、失敗したチェック、チェックが関連付けられているフレームワークのセクション、検出された問題などの、チェックの詳細が表示されます。 コンプライアンスレポートとその詳細は、オフラインでの使用および共有するためにエクスポートすることもできます。

Security Centralは、ビジネス要件に基づいたカスタム監査とカスタムコンプライアンスポリシーを作成する拡張機能も提供します。

調査とアラート(Findings and Alerts)

「問題をきちんと述べられれば、半分は解決したようなものだ」
- チャールズケタリング

脅威の状況は絶えず変化しているため、今日の環境ではセキュリティの監視とアラート発報が重要です。 ネットワーク、セキュリティコントロール、サーバー、エンドポイント、そしてユーザーアプリケーションで見つかった脅威と脆弱性を継続的に監視してアラート発報することで、全体的なセキュリティポスチャを強化し、問題が検出された際に解決時間を短縮するアラートへのプロアクティブなアプローチを可能にしています。

Security CentralにあるFindings and Alertsビューは、現在のセキュリティポスチャのビューを提供します。 このビューには、Security Centralによって監視されているNutanixクラスタで検出された構成の問題と観測された異常な動作が表示されます。 これらの調査結果は、選択した監査ポリシーに基づいています。 ユーザーにはこれらの問題の表示方法についてのカスタマイズ可能なオプションがあり、監査カテゴリ、リソース、役割、そしてビジネス要件ごとに調査結果を調整するための優れた柔軟性を提供します。

脅威検出のアラートは、Findings and Alertsビューに含まれています。 Security Centralは、NutanixのIPFIXネットワークログを分析して、監視対象のNutanixクラスタ内で発生する潜在的な脅威と異常な動作を検出してレポートします。 これらのアラートは、機械学習と観測されたデータポイントを使用してモデル化されます。

以下は、検出される潜在的な脅威と動作の一部と、異常の登録またはアラートをトリガーするために監視する必要のある最小日数またはデータポイントです:

  • ブラックリストに登録されたIP(既知の疑わしいIP)と通信する仮想マシン
    • 1 データポイント
  • 辞書攻撃の可能性がある仮想マシン
    • 1 データポイント
  • サービス拒否(DDoS)攻撃の可能性がある仮想マシン
    • 21 日
  • 異常なネットワーク動作のVLAN
    • 21 日
  • 異常なネットワーク動作をする仮想マシン
    • 21 日
  • ポートスキャン攻撃の可能性がある仮想マシン
    • 21 日
  • データ漏えい攻撃の可能性がある仮想マシン
    • 21 日
セキュリティプランニング(Security Planning)

アプリケーションのセキュリティ保護を計画する場合、効果的なセキュリティポリシーの作成に必要とされる、検出および情報収集する多くのコンポーネントがあります。 この情報を収集することは、非常に困難な場合があります。 多くの場合、アプリケーションの通信プロファイルを得るために、ファイアウォール、ネットワーク機器、アプリケーション、そしてオペレーティングシステムからログを収集する必要があります。 それらデータが収集および分析されたら、アプリケーションの所有者と相談して、観察された結果を、期待される動作と比較します。

Security CentralのMLベースのセキュリティプランニングは、アプリケーションのセキュリティポリシーの検出と計画に役立つ詳細な視覚化を提供します。 オンプレミスのNutanixクラスタ内のネットワークトラフィックフローを視覚化し、Security Centralがアプリケーションを分類して保護する方法についての推奨事項を作成します。

Security Planningセクションでは、アプリケーションと環境として、最大2レベルのグループ化を柔軟に利用できます。 この機能では、分析を特定のクラスタ、VLAN、仮想マシン、そしてカテゴリにドリルダウンできるため、アプリケーションの保護に集中することにおいて非常に役立ちます。 このグループ化により、観測またはフィルタリングされたすべてのネットワークトラフィックをダウンロードして、オフラインでの共有、検出、そして計画をさらに進めることができます。

備えられている機械学習機能を使用することで、Security Centralは観察されたネットワークフローに基づいて、カテゴリの推奨と仮想マシンへの割り当てを行うこともできます。 これは、新規のマイクロセグメンテーションまたはアプリケーションの展開で特に役立ちます。 アプリケーションの仮想マシンを分類することは、アプリケーションを保護するための重要なステップです。 さらに一歩進んで、Security Centralは、インバウンドおよびアウトバウンドのルール推奨を生成し、Nutanix AHVクラスタでのアプリケーションセキュリティポリシーをMonitorモードで作成することもできます。

Monitorモードのセキュリティポリシーを使用すると、ポリシーアクションを適用しなくても、セキュリティで保護されているアプリケーションの動作を監視できます。 Prism Centralを使用して、必要に応じてポリシーを適用する前にポリシーを編集できます。

統合(Integrations)

セキュリティアーキテクチャーは、多くの場合で、多層防御の姿勢を構築するために複数ベンダーのソリューションで構成されています。 エンドポイントの脅威と脆弱性、チケットシステム、ログ管理、脅威とイベントの分析を監視するソリューションは、すべてセキュリティアーキテクチャーの重要なコンポーネントになる可能性があります。 これらの製品は非常に重要ですが、多くの場合にスタンドアロンであり、セキュリティインフラストラクチャの他のコンポーネントとの統合に制限があります。 統合は、セキュリティアーキテクチャーの構築でセキュリティソリューションをまとめるための鍵となります。 これは、脅威の認識、分析、脅威の修復についての効率化および時間短縮となります。

Security Centralは、Nutanix以外のアプリケーションをSecurity Centralと直接統合する機能を提供します。 これらの統合は、OSレベルの監視と保護から、エンタープライズのチケットシステムや分析エンジンまで、複数のソリューションをカバーしています。

いくつかのサポートされている統合を以下に示します:

  • Splunk
  • Webhook
  • ServiceNow
  • Qualys

各統合の詳細情報については、Flow Security Central Guideを参照してください。

Flow Virtual Networking

Flow Virtual Networkingを使用すると、物理ネットワークから切り離され、完全に隔離された仮想ネットワークを作成できます。 重複するIPアドレスを持つマルチテナントネットワークプロビジョニング、セルフサービスでのネットワークプロビジョニング、IPアドレスの保持といったことが実行できます。

サポートされている構成

主なユースケース:

  • マルチテナントネットワーキング
  • ネットワーク隔離
  • IPアドレスの重複割り当て
  • セルフサービスでのネットワーク作成
  • 仮想マシンIPアドレスの移動
  • ハイブリッドクラウドの接続

管理インターフェイス:

  • Prism Central (PC)

サポートされる環境:

  • オンプレミス:
    • AHV

アップグレード:

  • 主な機能のアップグレードが依存するもの
    • Prism Central
    • AHV
  • 主な機能のアップグレードでLCMに含まれるもの
    • Advanced Network Controller
    • ネットワークゲートウェイ(VPN)

実装の構造

Flow Virtual Networkingは、完全なネットワーキングソリューションを提供するため、いくつかの新しい構造を導入しています。

  • 仮想プライベートクラウド(VPC)
  • オーバレイサブネット(Overlay Subnets)
  • ルート(Routes)
  • ポリシー(Policies)
  • 外部ネットワーク(External Networks)
    • NAT
    • Routed (NATなし)
  • ネットワークゲートウェイ
    • Layer 3 VPN
    • VXLANによるLayer 2延伸サブネット

仮想プライベートクラウド(VPC)

VPC(Virtual Private Cloud)は、Flow Virtual Networkingの基本単位です。 それぞれのVPCは、VPC内の全サブネットと接続するための仮想ルータインスタンスを持つ、隔離されたネットワーク名前空間です。 これにより、ひとつのVPC内にあるIPアドレスを、他のVPCや物理ネットワークと重複させることができます。 VPCは同一のPrism Centralで管理されているクラスタに拡張することができます。 しかし、通常はVPCが単一のAHVクラスタ内、もしくは同一のアベイラビリティ ゾーン内のクラスタに存在するべきです。 詳細については、外部ネットワークにて説明します。

Flow Virtual Networking - VPC
Flow Virtual Networking - VPC

オーバーレイサブネット(Overlay Subnets)

それぞれのVPCは1つ以上のサブネットを持つことができ、それらは全て同じVPC仮想ルータに接続されます。 内部では、VPCは、必要に応じてAHVホスト間のトラフィックをトンネリングするためにGeneveによるカプセル化を利用しています。 つまり、異なるホスト上の仮想マシンが通信するために、VPC内のサブネットは、作成したりトップオブラックスイッチに存在させたりする必要はありません。 VPCにある2つの異なるホスト上の2つの仮想マシンで相互通信する場合、パケットは最初のホストでGeneveでカプセル化され、別のホストに送信されるとカプセル化が解除されて宛先の仮想マシンに送信されます。

Flow Virtual Networking - Geneve Encapsulation
Flow Virtual Networking - Geneveのカプセル化

仮想マシンのNICを選択したときに、そのNICをオーバーレイサブネットまたは従来のVLANサブネットのどちらかに配置できます。 オーバーレイサブネットを選択した場合には、VPCも選択します。

Pro tip

それぞれの仮想マシンは、単一のVPCのみに配置できます。 仮想マシンは、VPCとVLANの両方に同時接続したり、異なる2つのVPCに同時接続したりすることはできません。

ルート(Routes)

全てのVPCには1つの仮想ルータが含まれており、いくつかの種類のルートが存在します:

  • 外部ネットワーク(External Networks)
  • 直接接続(Direct Connections)
  • リモート接続(Remote Connections)

外部ネットワークは、VPC全体に対しての、0.0.0.0/0ネットワークプリフィックスのデフォルトの宛先である必要があります。 使用する外部ネットワークごとに、代替のネットワークプリフィックスルートを選択できます。 完全に隔離されたVPCにするために、デフォルトルートを選択しないことも選択できます。

直接接続されたルートは、VPC内のサブネットごとに作成されます。 Flow Virtual Networkingは、それぞれのサブネットの最初のIPアドレスを、そのサブネットのデフォルトゲートウェイとして割り当てます。 デフォルトゲートウェイとネットワークプリフィックスはサブネット構成によって決定され、直接変更することはできません。 同一VPCの同一ホスト上にあって、異なるサブネットにある2つの仮想マシン間のトラフィックは、ホスト内でローカルにルーティングされます。

VPN接続のようなリモート接続や外部ネットワークは、ネットワークプリフィックスのネクストホップの宛先として設定できます。

Pro tip

VPCルーティングテーブル内のそれぞれのネットワークプリフィックスは、一意である必要があります。 同じ宛先プリフィックスを持つ2つの異なるネクストホップ宛先は設定しないでください。

ポリシー(Policies)

仮想ルータは、VPC内のトラフィックの制御ポイントとして動作します。 ここでは、シンプルなステートレスポリシーを適用でき、ルータを通過する全てのトラフィックはそのポリシーで評価されます。 同じサブネット内では、ある仮想マシンから別の仮想マシンへのトラフィックは、ポリシーを通過しません。

Flow Virtual Networking - Policies
Flow Virtual Networking - ポリシー

VPC内では、ポリシーは最高(1,000)から最低(10)の優先順位で評価されます。

次の値を基にトラフィックをマッチングします:

  • 送信元または宛先のIPv4アドレス
    • Any
    • External(外部からVPCに流入する全てのトラフィック)
    • Custom(IPプリフィックスを指定する)
  • プロトコル
    • Any
    • Protocol Number
    • TCP
    • UDP
    • ICMP
  • 送信元または宛先のポート番号

トラフィックがマッチすると、ポリシーは次のアクションを実行できます:

  • Permit
  • Deny
  • Reroute
    • トラフィックを別のサブネットにある/32のIPv4アドレスにリダイレクトします。

reroute(Re-route)ポリシーは、全てのインバウンドトラフィックをロードバランサーや、VPCの別のサブネットで稼働しているファイアウォール仮想マシンを経由するルーティングを実行するようなことに非常に役立ちます。 これは、ネットワーク機能を提供する仮想マシン(NFVM: Network Function VM)がAHVホストごとに必要になる従来のサービスチェインと比較して、VPC内の全てのトラフィックに対してNFVMが1つのみ必要だという付加価値があります。

Pro tip

ステートレスポリシーでは、許可(Permit)ルールがドロップルールを上書きする場合、往復の両方向で個別のルールが必要です。 この場合、復路のトラフィックはドロップルールによって定義されます。 これらの対応する往路と復路のエントリーは、同じ優先度を使用してグループ化します。

外部ネットワーク(External Networks)

外部ネットワークは、VPCにトラフィックが出入りするための主な方法です。 外部ネットワークは、Prism Centralで作成され、そして単一のPrism Elementクラスタのみに存在します。 このネットワークはVLAN、デフォルトゲートウェイ、IPアドレスプール、そして全てのVPCが使用するNATの種類を定義します。 1つの外部ネットワークは、複数のVPCが利用できます。

外部ネットワークは2種類あります:

  • NAT
  • Routed (NATなし)

PC.2022.1とAOS 6.1から、VPCでは最大2つの外部ネットワークが選択できるようになりました。 VPCは、最大で1つのNAT外部ネットワークと、最大で1つのRouted(NATなし)外部ネットワークを持つことができます。

NAT

NAT(Network Address Translation)外部ネットワークは、フローティングIPもしくはVPC SNAT(Source NAT)アドレスの背後にある、VPC内にある仮想マシンのIPアドレスを隠蔽します。 それぞれのVPCは外部ネットワークのIPプールからランダムに採番されたSNAT IPアドレスを持ち、VPCから出るトラフィックは、この送信元アドレスに書き換えられます。

Flow Virtual Networking - NAT External Network
Flow Virtual Networking - NAT外部ネットワーク

フローティングIPアドレスも、外部ネットワークのIPプールから採番され、入力トラフィックを許可するために、VPC内の仮想マシンに割り当てられます。 フローティングIPが割り当てられた仮想マシンは、出力トラフィックが、VPC SNAT IPの代わりにフローティングIPで書き換えられます。 これは、仮想マシンのプライベートIPアドレスを露出させることなく、VPCの外側にパブリックサービスを公開する際に役立ちます。

Routed

ルーティングされた(Routed)、もしくはNATなしの外部ネットワークにより、ルーティングを介してVPC内で物理ネットワークのIPアドレス空間を共有できます。 VPC SNAT IPアドレスの代わりに、VPCルータIPが外部ネットワークのプールからランダムに採番されます。 このVPCルータIPを物理ネットワークのチームと共有することで、VPC内でプロビジョニングされた全てのサブネットに、仮想ルータIPをネクストホップとして設定できます。

例えば、外部ネットワークが10.5.0.0/24のVPCには、仮想ルータIPとして10.5.0.200を割り当てることができます。 VPC内のサブネットが10.10.0.0/16のネットワークで作成されている場合には、物理ネットワークチームは、10.5.0.200経由で10.10.0.0/16へのルートを作成します。 10.10.0.0/16のネットワークは、VPCの外部へルーティング可能なプリフィックスになります。

Flow Virtual Networking - Routed External Network
Flow Virtual Networking - ルーティングされた外部ネットワーク

ネットワークゲートウェイ

ネットワークゲートウェイは、サブネット間のコネクタとして動作します。 これらのサブネットは、さまざまな種類と場所に配置できます。

  • サブネットの種類
    • ESXi VLAN
    • AHV VLAN
    • VPCオーバーレイ
    • 物理ネットワークのVLAN
  • サブネットの場所
    • オンプレミスのVLAN
    • オンプレミスのVPC
    • クラウドのVPC

ネットワークゲートウェイのサブネット接続には、いくつかの方法があります。

  • Layer 3 VPN
    • ネットワークゲートウェイからネットワークゲートウェイ
    • ネットワークゲートウェイから物理ファイアウォールまたはVPN
  • Layer 2 VXLAN VTEP
    • ネットワークゲートウェイからネットワークゲートウェイ
    • ネットワークゲートウェイから物理ルータまたはスイッチVTEP
  • Layer 2 VXLAN VTEP over VPN
    • ネットワークゲートウェイからネットワークゲートウェイ
Layer 3 VPN

Layer 3 VPNによる接続タイプでは、別の2つのネットワークプリフィックスを持っている2つのサブネットが接続されます。 例えば、ローカルサブネットである10.10.1.0/24を、リモートサブネットである10.10.2.0/24に接続できます。

Flow Virtual Networking - Layer 3 VPN
Flow Virtual Networking - Layer 3 VPN

2つのネットワークゲートウェイを使用する場合、それぞれのネットワークゲートウェイにはDHCPプールから外部IPアドレスが割り当てられ、それらのアドレスを介して通信できる必要があります。

ネットワークゲートウェイ仮想マシンを、リモートの物理ファイアウォール、またはVPNアプライアンスまたは仮想マシンに接続することもできます。 ローカルのネットワークゲートウェイは、リモートの物理アプライアンスまたは仮想アプライアンスと常に通信できる必要があります。

それぞれのサブネットからリモートサブネットへのトラフィックは、VPC内のIPルーティングを使用して作成されたVPN接続を介して転送されます。 ルートは静的に設定することも、BGPを使用してネットワークゲートウェイ間で共有することもできます。 このVPNトンネル内のトラフィックは、IPsecで暗号化されます。

Pro tip

サブネット間のトラフィックがインターネットのようなパブリックリンクを経由する場合は、IPsec暗号化でのVPNを使用します。

Layer 2 VXLAN VTEP

Layer 2 VXLAN VTEPの場合は、同じネットワークプリフィックスを共有する2つのサブネットが接続されます。 たとえば、ローカルサブネットの10.10.1.0/24が、同じく10.10.1.0/24を使用するリモートサブネットに接続されます。

Flow Virtual Networking - Layer 2 VXLAN VTEP
Flow Virtual Networking - Layer 2 VXLAN VTEP

2つのネットワークゲートウェイ仮想マシンを使用する場合、それぞれのネットワークゲートウェイには外部IPアドレスが割り当てられ、2つのネットワークゲートウェイ仮想マシンはこれらのアドレスを介して通信できる必要があります。

ローカルのネットワークゲートウェイは、物理スイッチなどのリモートにある物理VXLAN VTEP終端デバイスに接続することもできます。 物理デバイスは、Cisco、Arista、Juniperなどの一般的なベンダーの標準的なVXLANデバイスが利用できますが、これらに限定されません。 VXLAN VTEP接続には、リモート物理デバイスのIPアドレスを入力するだけです。

ローカルサブネットからリモートサブネットへのトラフィックは、レイヤー2スイッチ経由で交換され、暗号化されていないVXLANにカプセル化されます。 それぞれのネットワークゲートウェイはソースMACアドレステーブルを維持し、ユニキャストまたはフラッディングされたパケットをリモートサブネットに転送します。

Pro tip

トラフィックが暗号化されないため、VXLAN TEPはトラフィックがプライベートもしくはセキュアなリンクを通過する場合のみ使用します。

Layer 2 VXLAN VTEP over VPN

セキュリティを強化するために、VXLAN接続は、既存のVPN接続でトンネリングすることで暗号化できます。 このケースでは、ネットワークゲートウェイ仮想マシンがVXLANとVPN接続を提供するので、ネットワークゲートウェイ仮想マシンがローカルとリモートの両方のサブネットに必要です。

Flow Virtual Networking - Layer 2 VXLAN VTEP over VPN
Flow Virtual Networking - Layer 2 VXLAN VTEP over VPN
End of book of network services -->

Book of Backup / DR Services

確実なバックアップ戦略を持つことは、インフラストラクチャ設計において不可欠です。 本書では、ポリシー駆動型のバックアップ、DR、およびランブックによる自動化を提供するNutanix Leapの詳細について説明します。

Note: Nutanix Mine section coming soon!

Leap (ポリシー駆動型DR / ランブック)

Test Drive

ハンズオンに興味のある方は、Nutanix Test Driveを試してみてください!

https://www.nutanix.com/test-drive-disaster-recovery

Nutanix Leapの機能は、Prism Central(PC)に構成された、ポリシー駆動型のバックアップとDR、およびランブックによる自動化サービスを提供します。 この機能は、AOSで利用可能であり、PEで何年にもわたって構成されてきた、ネイティブなDRおよびレプリケーション機能に構築および拡張されています。 レプリケーションなどに活用されている実際のバックエンドメカニズムの詳細については、「Book of AOS」の「バックアップとディザスタリカバリ」セクションを参照してください。 LeapはAOS 5.10で導入されました。

サポートされる構成

ソリューションは以下の構成に適用できます(リストは不完全な場合があります。サポートされているものの完全なリストについては、ドキュメントを参照してください):

    主なユースケース:
  • ポリシーベースのバックアップとレプリケーション
  • ランブックによるDR自動化
  • DRaaS(Xiによる)
    管理インターフェイス:
  • Prism Central (PC)
    サポートされている環境:
  • オンプレミス:
    • AHV(AOS 5.10 時点)
    • ESXi(AOS 5.11 時点)
  • クラウド:
    • Xi (AOS 5.10 現在)
    アップグレード:
  • AOSの一部
    互換性のある機能:
  • AOSのBCおよびDR機能
主な用語

このセクション全体で使用される主な用語、以下のように定義されています:

  • 復旧時点目標(RPO:Recovery Point Objective)
    • 障害が発生した場合の許容可能なデータ損失を指します。 例えば、1時間のRPOが必要な場合は、1時間ごとにスナップショットを作成します。 復旧では、最大1時間前のデータをリストアします。 同期レプリケーションの場合、通常はRPOが0になります。
  • 目標復旧時間(RTO:Recovery Time Objective)
    • 障害発生からサービスの復旧までの期間を指します。 たとえば、障害が発生してから30分でバックアップを戻して稼働状態にする必要がある場合、RTOは30分になります。
  • 回復ポイント(Recovery Point)
    • 復元のポイントであり、別名はスナップショット。
実装の構造

Nutanix Leapには、いくつかの重要な構成要素があります:

保護ポリシー(Protection Policy)
  • 主な役割: カテゴリを割り当てる、バックアップとレプリケーションのポリシー
  • 説明: 保護ポリシーは、RPO(スナップショット頻度)、回復場所(リモートクラスタまたはXi)、スナップショット保持(ローカルクラスタ対リモートクラスタ)、そして割り当てるカテゴリを定義します。 保護ポリシーを使用すると、すべてがカテゴリレベルで適用されます(デフォルトでは、Any / Allに適用できます)。 これは、VMを選択する必要がある保護ドメイン(Protection Domain)とは異なります。

下記の図は、Nutanix Leapの保護ポリシーの構造を示します:

Leap - Protection Policy
Leap - Protection Policy
リカバリープラン
  • 主な役割: DR ランブック
  • 説明: リカバリープランは、パワーオンの順序(カテゴリまたはVMを指定可能)およびネットワークのマッピング(プライマリ、リカバリおよびテストサイトにおける、フェイルオーバーとフェイルバック)を定義するランブックです。 これはSRMを利用することと同義です。 注: リカバリープランを構成する前に、保護ポリシーを構成する必要があります。 これは、復旧のためには、データがリカバリサイトに存在する必要があるために必要です。

以下の図は、Nutanix Leapにおけるリカバリープランの構造を示します:

Leap - Recovery Plan
Leap - Recovery Plan
リニア保持ポリシー
  • 主な役割: 回復ポイントの保持ポリシー
  • 説明: リニア保存ポリシーは、保持する回復ポイントの数を指定します。 例えば、RPOが1時間で、保持が10に設定されている場合、10時間(10 x 1時間)の回復ポイント(スナップショット)を保持します。
ロールアップ保持ポリシー
  • 主な役割: 回復ポイントの保持ポリシー
  • 説明: ロールアップ保持ポリシーは、RPOと保存期間に応じて「ロールアップ」スナップショットを作成します。 例えば、RPOが1時間で保持期間が5日に設定されている場合、1日保持の1時間ごとの、そして4日間の1日ごとの回復ポイントが保持されます。 ロジックは次のようになります: 保持期間がn日の場合、RPOは1日で、n-1日の回復ポイントを保持します。 保存期間がn週間の場合、RPOは1日で、1週間の日次、n-1か月間の週次の回復ポイントを維持します。 保存期間がnか月の場合、RPOは1日で、1週間の日次、1か月間の週次、n-1か月間の月次の回復ポイントを維持します。 保存期間がn年の場合、RPOは1日で、1週間の日次、1か月間の週次、1年間の月次、n-1年間の年次の回復ポイントを維持します。
リニア保持ポリシー対ロールアップ保持ポリシー

保持期間が短い小さなRPOウィンドウや、常に特定のRPOウィンドウに復旧できるようにする必要がある場合には、リニア保持ポリシーを使用します。

保持期間が長いものにはロールアップ保持ポリシーを使用します。 柔軟性が高く、スナップショットのエージングやプルーニングを自動処理すると同時に、運用開始時むけの期間の細かいRPOを提供します。

以下に、Leapの構成の概要を示します:

Leap - Overview
Leap - Overview

以下は、LeapがオンプレミスとXiとの間でどのように複製できるかを示します:

Leap - topology
Leap - Topology
使用方法と構成

このセクションでは、Leapを構成して利用する方法について説明します。

おおまかなプロセスは、以下の手順となります:

  1. アベイラビリティ ゾーン(AZ)に接続する
  2. 保護ポリシーを構成する
  3. リカバリープランを構成する
  4. 実行またはテストとしての、フェイルオーバーとフェイルバック
アベイラビリティ ゾーンへの接続

最初の手順はAZに接続することで、これはXiのAZ、または別のPCです。 注: PC 5.11以降、少なくとも2つのPCが必要になります(各サイトに1台)。

PCで「Availability Zones」を検索するか、「管理」→「アベイラビリティ ゾーン」に移動します:

Leap - Connect to Availability Zone
Leap - Connect to Availability Zone

「アベイラビリティ ゾーンに接続」をクリックして、AZの種類(「Xi」またはPCインスタンスである「Physical Location」)を選択します:

Leap - Connect to Availability Zone
Leap - Connect to Availability Zone

PCまたはXiの資格情報を入力し、「接続」をクリックします:

Leap - Connect to Availability Zone
Leap - Connect to Availability Zone

接続されたAZが表示され、使用できるようになります。

保護ポリシーの構成

PCで「保護ポリシー」を検索するか、「ポリシー」→「保護ポリシー」に移動します:

Leap - Protection Policies
Leap - Protection Policies

「保護ポリシーを作成」をクリックします:

Leap - Protection Policy
Leap - Create Protection Policy

名前、リカバリロケーション、RPO、保存ポリシーの詳細を入力します(前述):

Leap - Protection Policy Inputs
Leap - Protection Policy Inputs

注:Xiの場合は、「ターゲットクラスタ」を選択する必要はありません:

Leap - Protection Policy Inputs - Xi
Leap - Protection Policy Inputs - Xi

次に、ポリシーを適用するカテゴリを選択します:

Leap - Protection Categories
Leap - Protection Policy Categories

「保存」をクリックすると、新しく作成された保護ポリシーが表示されます:

Leap - Protection Policies
Leap - Protection Policies
リカバリープランの構成

PCで「Recovery Plans」を検索するか、「ポリシー」→「リカバリープラン」に移動します:

Leap - Recovery Plans
Leap - Recovery Plans

最初の起動時に、最初のリカバリープランを作成するための画面が表示されます:

Leap - Create Recovery Plan
Leap - Create Recovery Plan

ドロップダウンを使用して「Recovery Location」を選択します:

Leap - Select Recovery Location
Leap - Select Recovery Location

注:これは、XiのAZまたはPhysical AZ(対応する管理対象クラスタを持つPC)のいずれかです。

リカバリープランの名前と説明を入力し、「Next」をクリックします:

Leap - Recovery Plan - Naming
Leap - Recovery Plan - Naming

次に「Add Entities」をクリックして、パワーオンのシーケンスを指定します:

Leap - Recovery Plan - Power On Sequence
Leap - Recovery Plan - Power On Sequence

VMまたはカテゴリを検索して、各ステージに追加します:

Leap - Recovery Plan - Power On Sequence
Leap - Recovery Plan - Power On Sequence

ステージのPower On Sequenceが適切になったら、「次へ」をクリックします:

Leap - Recovery Plan - Power On Sequence
Leap - Recovery Plan - Power On Sequence
パワーオンのシーケンス

Power On Sequenceを決定するときは、次のようにステージ設定する必要があります:

  • Stage 0: Core サービス (AD、DNSなど)
  • ステージ1: ステージ0サービスに依存し、ステージ2サービスに必要なサービス(例えばDB層)
  • ステージ2: ステージ1サービスに依存し、ステージ3サービスに必要なサービス(例えばApp層)
  • ステージ3: ステージ2サービスに依存し、ステージ4サービスに必要なサービス(例えばWeb層)
  • ステージ4-N: 依存関係に基づいて繰り返す

次に、ソースとターゲットの環境の間でネットワークをマッピングします:

Leap - Recovery Plan - Network Mapping
Leap - Recovery Plan - Network Mapping
フェイルオーバーおよびフェイルバックのネットワーク

ほとんどの場合で、テストネットワークには、ルーティング不可能な、または分離されたネットワークを使用します。 これにより、SIDの重複、ARPエントリーなどの問題が発生しなくなります。

Book of Cloud Native Services

CNCFでは、クラウドネイティブを「組織が、パブリック、プライベート、ハイブリッドクラウドといったモダンで動的な環境において、拡張可能なアプリケーションを構築および実行できるようにするテクノロジーのセット」と定義しています。 アプリケーションモダナイゼーションへの移行を推進する主要なテクノロジーには、コンテナ、マイクロサービス、そしてKubernetesが含まれます。

我々は、Nutanixのハイパーコンバージドインフラストラクチャー(HCI)は、大規模なKubernetesで実行されるクラウドネイティブワークロードの理想的なインフラストラクチャ基盤であると確信しています。 Nutanixはプラットフォームのモビリティを提供し、Nutanixプライベートクラウドと、パブリッククラウドとの両方でワークロードを実行するための選択肢を提供します。 Nutanixアーキテクチャーはハードウェア障害を念頭に置いて設計されており、それはKubernetesプラットフォームコンポーネントとアプリケーションデータの両方に、より良い回復力を提供します。 HCIノードを追加することで、Kubernetesコンピュートノードに拡張性と回復力が提供される恩恵を受けられます。 同様に重要なこととして、各HCIノードとともにデプロイされる追加のストレージコントローラーがあることで、ステートフルなコンテナ化されたアプリケーションのストレージパフォーマンスが向上することが挙げられます。

Nutanix Cloud Platformは、Nutanix Kubernetes Engine(NKE)によって組み込みのターンキーKubernetes体験を提供します。 NKEはエンタープライズグレードの製品であり、複数のクラスタにおけるプロビジョニングとライフサイクル管理を簡素化します。 Nutanixは顧客の選択に関するものであり、優れたフルスタックのリソース管理により、顧客はOpenShift、Rancher、Anthosなどの好みのディストリビューションを実行できます。 詳細については、以降のチャプターをご覧ください。

Nutanix Unified Storageは、永続的で拡張性のあるソフトウェアデファインドストレージをKubernetesクラスタに提供します。 これらには、Nutanix CSIドライバーを介したブロックおよびファイルストレージと、S3互換のオブジェクトストレージが含まれます。 さらに、Nutanix Database Serviceによって、大規模なデータベースのプロビジョンと操作が可能です。

以降のチャプターで、これらについて詳しく説明します。

Note: Nutanix Unified Data Services chapter coming soon!

Nutanix Kubernetes Engine(旧Nutanix Karbon)

Nutanix Kubernetes Engine(NKE)は、Kubernetesのターンキープロビジョニング、運用、そしてライフサイクル管理を可能にするNutanix認定エンタープライズKubernetes管理ソリューションです。

サポートされている構成

このソリューションは、以下の構成に適用できます:

主なユースケース:

  • コンテナ
  • マイクロサービス
  • アプリケーションモダナイゼーション

管理インターフェース:

  • Prism Central(PC)内のNKEコンソール

サポートされる環境:

  • ハイパーバイザー:
    • AHV
  • ロケーション:
    • オンプレミス:
      • 所有(Owned)
      • (マネージド)サービスプロバイダー

サポートされるノードOSイメージ:

  • Nutanixによって提供されるCentOS Linuxベースのもの

アップグレード:

  • LCMにKarbonとして含まれる

互換性のある機能:

  • ライフサイクル操作
  • ロールベースアクセス制御(RBAC)
  • クラスタ拡張
  • マルチクラスタ管理
  • ノードプール
  • GPUパススルー

Nutanix Kubernetes Engineは、Prism Centralで有効化できます。 NKEを有効化したPCに登録されているNutanix AOSクラスタは、Kubernetesクラスタをプロビジョニングするためのターゲットとして使用できます。

アーキテクチャー

NKEで有効化されているKubernetesクラスタは、複数のNutanixクラスタをまたぐことができません。

NKE Multi-cluster Architecture
NKEマルチクラスタアーキテクチャー

NKEアーキテクチャー

NKEはPrism Centralでコンテナ化されたサービスとして実行されます。 PCでNKEが有効化されると、次の2つのコンテナがプロビジョンされます: karbon-coreコンテナとkarbon-uiコンテナ

  • karbon-coreは、Kubernetesクラスタのライフサイクル管理を担当します。 プロビジョニング、ノードOSのアップグレード、クラスタ拡張などのタスクは、このコンテナによって実行されます。

  • karbon-uiは、Prism Centralを介して直感的なコンソールの提供を担当します。 この統合されたUIから、IT管理者はNKEインスタンスによって管理されるKubernetesランドスケープ全体を完全に制御できます。

エアギャップ環境

NKEは、エアギャップ環境でも有効化できます。(詳細はこちらをご覧ください

Kubernetesクラスタの構成

OSイメージ

NKEは、Kubernetesノードをインストールおよび拡張するためのOSイメージを提供します。 NKEは、NKEを有効化したKubernetesクラスタを作成するための、CentOS Linuxベースのオペレーティングシステムを使用します。 脆弱性を修正するパッチを含む、新しいOSイメージバージョンが定期的にリリースされます。 サポートされるOSイメージバージョンのリストについては、NKEのリリースノートを確認してください。 (詳細はこちらをご覧ください)

オペレーティングシステムイメージ

OSイメージの持ち込み(Bringing your own OS image)は、サポートされていません。

コンピュート

推奨される構成には2つの選択肢があります:

Development ClusterとProduction Cluster

  • Development Clusterを選択すると、高可用性のコントロールプレーンを持ちません。 コントロールプレーンノードがオフラインになった場合は、Kubernetesクラスタに影響があります。

    Developmentの最小クラスタサイズは3ノードです:

    • コントロールプレーンは、etcdノードとKubernetesコントロールプレーンノードの2ノードに分割されます。
    • ワーカーノードはシングルノードで、100ノードまで拡張できます。(NKEの構成の上限)。
  • Production Clusterを選択すると、高可用性のコントロールプレーンを持ちます。 この構成の選択には、単一障害点がありません。

    Productionの最小クラスタサイズは8ノードです:

    • コントロールプレーンは5ノードに分割され、これは3つのetcdノード(5ノードまでスケールアップ可能)と、2つのKubernetesコントロールプレーンノードで構成されます。 Kubernetesコントロールプレーンノードは、アクティブ-パッシブ(2ノード)、またはアクティブ-アクティブ(最大5ノード)で動作できます。 後者の場合は、外部のロードバランサーが必要です。
    • ワーカーノードプールは最小3ノードで、100ノードまで拡張できます。
ネットワーキング

Kubernetesクラスタに必要なネットワークは合計で3つあり、仮想マシンネットワークとKubernetesネットワークにグループ化できます。

  • 仮想マシンネットワークまたはノードネットワーク: これは、DHCP(Development Clusterのみ)またはIPAMが有効で管理されているネットワーク(関連するドメイン設定とIPアドレスプールを設定してある)のいずれかによって割り当てる必要があります。 Production構成では、アクティブ-パッシブモード、およびアクティブ-アクティブモードのために追加の静的IPアドレスが必要です。

  • Kubernetesネットワーク: クラスタには、少なくとも2つのClassless Inter-Domain Routing(CIDR)範囲が必要であり、1つはKubernetesのサービスネットワーク、もう1つはKubernetesのPodネットワークです。

    NKEは、Kubernetesのために2つのContainer Network Interface(CNI)プロバイダーをサポートしています: FlannelとCalico

    • Flannel: NKEは、VXLANモードを使用します。 host-gwのモードに変更することは可能ですが、非サポートです。
    • Calico: NKEは、Directモードを使用します。 IP in IPまたはVXLANにモードを変更することは可能ですが、非サポートです。
Pro tip

サービスCIDRとPod CIDRの範囲はデフォルトのままにできますが、クラスタ内のPodが外部ネットワークへのアクセスを必要とする場合は、お互いに、あるはデータセンター内の既存ネットワークと、範囲が重複したりしないようにする必要があります。

ネットワーキング

コントロールプレーンのモードがアクティブ-アクティブのProduction Clusterでは、外部のロードバランサーが必要です。

ストレージ

Kubernetesクラスタをデプロイする際には、一緒にNutanix Container Storage Interface(CSI)ドライバーもデプロイされます。

デプロイ処理の中でデフォルトのStorageClassも作成され、これはNutanix Volumesを使用します。 これは、監視用のPrometheusや、メトリックとログを保存するためのEFK(Elasticsearch、Fluent Bit、Kibana)ロギングスタックといった同梱されているアドオンで必要です。 デプロイ後に、同じCSIドライバーを使用してストレージクラスを追加できます (例はこちら)。

Nutanix Volumesとは別に、Nutanix Filesを使用してファイルストレージのためのStorageClassを作成することもできます。 StorageClassで構成されているストレージバックエンドに依存して、PersistentVolumeClaimを作成するときに異なるアクセスモードがサポートされます。

CSIドライバーとストレージバックエンドごとにサポートされるアクセスモード
ストレージバックエンド ReadWriteOnce
RWO
ReadOnlyMany
ROX
ReadWriteMany
RWX
ReadWriteOncePod
RWOP
Volumes
-
-
Files
-
セキュリティ
アクセスと認証

アクセスと認証に関して、覚えておくべき2つのコンポーネントがあります: PC内のNKEと、NKEが有効化されたKubernetesクラスタです。

  • NKEは、Prism Centralの認証とRBACを使用します。 Nutanixでは、NKEユーザーを、Microsoft Active DirectoryなどのPrism Centralのディレクトリサービスに設定する必要があります。 ユーザーはNKEコンソールにアクセスし、割り当てられたロールに基づいて特定のタスクを行えるようになります。

    PCの"User Admin"ロールのメンバーは、NKEとその機能に完全なアクセス権限を持ちます。

    "Prism Central Admin"ロールまたは"Viewer"ロールのメンバーは、kubeconfigのダウンロードのみが可能です。

  • NKEが有効化されたKubernetesクラスタは、デプロイした直後に(out-of-the-boxで)Prism Central認証で使用できるように、PCの"User Admin"ロールとKubernetesの"cluster-admin"ロールをマッピングしています。

    認証の視点では、KubernetesクラスタはPCのディレクトリサービスを使用するNKEに認証リクエストを送信します。 これは、デプロイした直後にActive Directoryでユーザー認証ができることを意味します。

    RBACの観点では、PCの"User Admin"ロールは、"cluster-admin"という名前のKubernetesのスーパー管理者にあたるロールにマッピングされます。 これは、PCの"User Admin"ロールのユーザーメンバーが、NKEインスタンスによって管理されるすべてのKubernetesクラスタのスーパーユーザーであることを意味します。 一方で、PCロールの"Prism Central Admin"と"Viewer"には、Kubernetesロールとのマッピングがありません。 つまり、これら2つのロールのいずれかのユーザーメンバーは、NKEからkubeconfigをダウンロードできますが、Kubernetesレベルでのアクションは実行できません。 スーパー管理者のユーザーは、Kubernetes内に正しいロールマッピングを作成する必要があります。

NKEによって生成されたkubeconfigは24時間有効であり、その後、ユーザーは新しいkubeconfigファイルを要求する必要があることに注意してください。 これは、NKE GUI、CLI、API、または kubectlプラグイン(推奨)を使用して実行できます。

ノード

KubernetesノードへのSSHアクセスは、一時的な証明書を使用してロックダウンされます。これは、NKEコンソールで入手でき、24時間後に有効期限が切れます。 ノードOSでのソフトウェアのインストールや設定の変更は非サポートであり、変更はアップグレードまたはノードプールのスケールアウトの際に永続化されません。 SSH経由でノードにアクセスする唯一の理由は、Nutanixサポートの裁量でのトラブルシューティングです。

CIS Benchmark for Kubernetes

Nutanixは、NKEが有効化されたKubernetesクラスタをCIS Kubernetes Benchmark 1.6にて評価しました。 コンプライアンスについては、GitHubで入手できる自動化されたオープンソースツールであるKube Benchで確認できます。 レポートは、こちら から確認できます。

アドオン

NKEアドオンは、デプロイしたクラスタに追加機能を提供するオープンソースソフトウェアによる拡張です。 Kubernetesクラスタをデプロイすると、アドオンは自動的にインストールされます。

Nutanix Kubernetes Engineには、以下のアドオンが含まれます:

  • Elasticsearch、Fluent Bit、and Kibana(EFK)によるロギングアドオン
  • Prometheusによる、モニタリングアドオン

これらのアドオンは、クラスタの内部のみで使用されます。 これらの構成は、Kubernetesクラスタで実行されているアプリケーションによって生成されたデータをサポートするようには設計されていません。 コンテナ化されたアプリケーションのログとメトリックを収集するには、EFKとPrometheusの専用インスタンスをデプロイするか、環境で利用可能な既存のものを再利用します。

ロギング

ロギングスタックは、Kubernetesノードからのすべてのオペレーティングシステムとインフラストラクチャのログを集約します。 Kibanaダッシュボードは、NKEコンソールからアクセスできます。

NKE 2.4以降、ロギングスタックを無効にでき(詳細はこちら)、Fluent Bitを外部の既存のロギングスタックへのログ転送に使用することができます(詳細はこちら)。

モニタリング

KubernetesクラスタにはPrometheus Operatorがインストールされており、インフラストラクチャのメトリックを収集するために1つのインスタンスがデプロイされています。 追加のPrometheusインスタンスは、例えばアプリケーションのモニタリングのために、Operatorを使用してデプロイできます(ブログ)。

NKE 2.4以降、電子メールアドレスへのSMTPベースのアラート転送を有効にできます(詳細はこちら)。

ライフサイクル管理

NKEのアップグレードには、2つの異なる種類があります:

  • ライフサイクル管理機能を使用したNKEバージョンのアップグレード
  • ノードOSイメージによるKubernetesクラスタと、Kubernetesバージョンのアップグレード
LCMによるNKEアップグレード

Karbonの現在のバージョンを確認する、もしくは新しいバージョンにアップグレードするには、LCMを使用してPrism Centralのインベントリ確認を実行します。 LCMは、以下のNKEコンポーネントをアップグレードします:

  • NKE core(karbon-coreコンテナ)
  • NKE UI(karbon-uiコンテナ)
NKEのアップグレード

最新バージョンのNKEにアップグレードする場合は、すべてのKubernetesクラスタが実行されているか、最初にアップデート先のNKEによってサポートされているバージョンにアップグレードしておく必要があることに注意してください。 サポートされているバージョンの更新については、Nutanixポータルを確認してください。

Kubernetesクラスタのアップグレード

Kubernetesクラスタのアップグレードには、次の2つの側面があります:

  • ノードオペレーティングシステムのアップグレード
  • Kubernetesとアドオンバージョンのアップグレード
Kubernetesクラスタのアップグレード

ノードOSまたはKubernetesバージョンのアップグレードは、KubernetesクラスタのDevelopmentまたはProductionといった種類によっては、破壊的でありうることに注意してください。

ノードOSのアップグレード

ノードOSイメージのアップグレードが利用可能な場合、NKEは"OS Images"タブに、新しいイメージをダウンロードするオプションを表示します。 NKEは、Clustersビューのクラスタの横に"Upgrade Available"アイコンも表示します。

Kubernetesとアドオンバージョンのアップグレード

アップグレード対象となるKubernetesバージョンがあるクラスタでは、テーブルで"Upgrade Available"アイコンが表示されます。 アップグレードプロセスの一環として、Kubernetesバージョンと、インストールされているアドオンで利用可能な更新版をアップグレードします。

NKE CLIとAPI

NKE CLI

NKE CLIであるkarbonctlを使用すると、ユーザーはNKEおよびKubernetesクラスタのライフサイクル管理タスクを実行できます。 特定の高度なタスクについては、karbonctlのみで実行できます。

karbonctlを使用するには、Prism CentralインスタンスにSSHで接続する必要があります。 バイナリのパスは、/home/nutanix/karbon/karbonctlです。

karbonctlで実行できる一般的なタスクは以下です:

  • エアギャップ展開の構成
  • GPUサポートの構成
  • 証明書の更新
  • アラート転送の有効化/無効化
  • プライベートレジストリの更新
  • kubeconfigファイルの再取得
karbonctl
karbonctl
NKE API

NKE APIを使用すると、ユーザーはNKEとKubernetesクラスタの管理タスクをプログラムによって実行できるようになります。 APIドキュメントは、https://www.nutanix.dev/reference/karbonで確認できます。

パートナーKubernetesディストリビューション

Nutanix Cloud Platformは、認定Kubernetesディストリビューションを実行するための理想的なソリューションです。 Nutanixは、大規模なモダンアプリケーションを正常実行するために必要なすべてのリソースを備えた、エンタープライズクラスのプラットフォームを提供します。

Kubernetesディストリビューションは、コンピューティング、ネットワーク、ストレージを必要とします。 Nutanixを使用することで、IT管理者や開発者はこれらのリソースに簡単にアクセスでき、好みのKubernetesディストリビューションを実行できます。 Red Hat OpenShift、Google Anthosなどを含むいくつかの主要なKubernetesディストリビューションプロバイダーは、ソリューションをNutanixで使用することを認定しています。 サポートされているパートナーソフトウェアソリューションは、Nutanixサポートポータルでオンラインで表示します。

OpenShift Anthos Rancher D2IQ

Kubernetesアーキテクチャー

すべてのKubernetesディストリビューションには、少なくとも以下のコンポーネントによる基本的なアーキテクチャーがあります:

  • etcd:すべてのKubernetesクラスタ構成データ、状態データ、そしてメタデータを保存するためのKey-Valueストア。
  • Kubernetesコントロールプレーン:これには、Podをスケジューリングし、クラスタイベントを検出して応答するためのKubernetes API Serverとその他のコンポーネントが含まれる。
  • Kubernetesワーカーノード:アプリケーションワークロードをホストするマシン。
Kubernetes Cluster Components
Kubernetesクラスタのコンポーネント

さらに、これらのコンポーネントがすべてのKubernetes コントロールプレーンとワーカーのノードで実行されます。

  • Kubelet
  • Kube-proxy
  • コンテナランタイム

これらのコンポーネントの詳細情報は、Kubernetes documentationで見つけることができます。

Part 3: シナリオ

このセクションでは、Nutanixプラットフォームにおけるさまざまなユースケース、考慮事項、サンプル実装について説明します。

シナリオ: 安全な分析プラットフォーム

このシナリオでは、さまざまな外部および内部のソースからデータを取り込んで、分析が実行されるデータレイクにETLを実行する安全な分析プラットフォームを設計します。 これは、私が個人的によく知っているシナリオで、内部プロジェクトとして取り組んでいるProject Earthと呼ばれるものです。

このスコープは非常に大きく独自仕様であるため、最初のイテレーションではプラットフォームのセキュリティの側面のみを説明します。

概要
  • 主な要件
    • 環境はすべてのレイヤー(ネットワーク、アプリケーションなど)を通して高度に保護されている必要がある
    • アクセスは特定の集団やユーザーに限定する必要がある
    • 内部ソースと外部ソースの両方からデータを使用する必要がある
    • 構成を自動化する必要がある
    • ユーザー管理とRBACは100%自動化する必要がある
    • データは暗号化する必要がある
  • ソリューションコンポーネント
    • フロントエンド: Tableau
    • サービスカタログ: Service Now
    • 承認: SlackまたはEmail → ServiceNow
    • 構成自動化: Puppet
    • データベース: Apache MySQL / extensible
    • ESB / ETL: カスタムアプリ + Apache Kafka
    • 分析: カスタムアプリ
  • プラットフォーム
    • ハイパーバイザー: Nutanix AHV
    • 暗号化: Nutanixによるソフトウェア暗号化
    • マイクロセグメンテーション: Nutanix Flow
    • コンピュート + ストレージ + ネットワーク(仮想化): Nutanix

以下に、ソリューションレイヤーとデータフローの概要を示します:

Scenario - Secure Analytics Platform
Scenario - Secure Analytics Platform
セキュリティアーキテクチャー

「セキュリティと暗号化」セクションで言及したように、 セキュリティは、データからシステム、そして人々まで複数のレベルで発生します。 以下は、これらの各コンポーネントをどのように強化したのか概要を説明します。

ネットワークと通信

ネットワークと通信に関しては、既知または安全な集団のみがシステムにアクセスできるようにして、外向きのデータフローが制限されていることを確認する必要があります。

これを実現するには、いくつかの項目を連携させて使用します:

  • すべての構成はPuppetを使用して100%自動化される
  • すべてのポリシーはホワイトリストのみ
  • 信頼された集団のみが特定ポートでの受信を許可される
  • すべての開発者アクセスが単一のジャンプボックスを通過する
  • MySQLのユーザーや権限割り当ては、特定のユーザーとIPアドレスの組み合わせの範囲にする
  • FirewalldルールによるLinuxファイアウォールで保護する
  • Nutanix Flowで仮想と物理ネットワーク層を保護する

以下は、開発、ステージング、本番環境のFlowポリシーを示します:

Scenario - Secure Analytics Platform - Flow Policies
Scenario - Secure Analytics Platform - Flow Policies

特定のポートとプロトコルのみがアプリケーション層と受信の間で許可されています:

Scenario - Secure Analytics Platform - Flow Policy Detail
Scenario - Secure Analytics Platform - Flow Policy Detail

カテゴリは、アプリの階層と環境を指定するために利用されます。特定ポート間のみが許可されています:

Scenario - Secure Analytics Platform - Policy Categories
Scenario - Secure Analytics Platform - Policy Categories

これは、許可されたinboundソースを示すDev環境でのFlowポリシーのサンプルです。 また、偶然にブロックされた内部の侵入テストツールからの接続も強調表示されます:

Scenario - Secure Analytics Platform - Flow Policy Detail
Scenario - Secure Analytics Platform - Flow Policy Detail
システムと構成

スタックに関していくつかの核となるレイヤーがあります:

  • アプリケーションとサービス
  • VMとコンテナ
  • インフラストラクチャー(Nutanix)

すべてのスタックは、Puppet、Nutanix SCMA、および環境のテンプレートを使用して100%自動化されました。 これにより、セキュリティや構成ベースラインとの確保と、それらの遵守ができました。 セキュリティの脆弱性が見つかった場合にパッケージを更新することもできます。

Nutanixプラットフォームでは、ネイティブのSCMAが活用され(デフォルトで有効化されている)、CVMとホストのSTIGに従った、安全な構成が保証されています。 クラスタのロックダウンモードが有効化(推奨)され、鍵ベースのアクセスが強制されています。

秘密情報(Secrets)

複数システムと統合しているプラットフォームでは、秘密情報の管理は非常に重要な項目です。 最初はPuppetで暗号化されたyaml(eyaml)の使用から始めましたが、最終的にはこれをより安全で管理しやすいHieraバックエンドに移動しました。 これにはHashiCorp Vaultなどの複数のオプションがあります。

データ暗号化

データ暗号化は、攻撃者がデータを盗んだり所有したりした場合に、データを理解できないようにするために重要です。

データ暗号化には、ネイティブなNutanixのソフトウェアベース暗号化が利用されました。 キーマネージャーが利用できないシナリオでは、local key manager (LKM)を利用できます。 外部キーマネージャー(EKM)を使用する場合は、キーをローテーションすることをお勧めします。これは、LKMではデフォルトで毎年行われます。

Scenario - Secure Analytics Platform - Data Encryption
Scenario - Secure Analytics Platform - Data Encryption
データスコープとRBAC

「スタック」が強化された後で最も重要なことの1つは、特定の個人のみがアクセスすべきデータにアクセスできるようにすることであり、すべてのアクセス、リクエスト、権限付与は完全に監査可能とします。 私の視点から、これを正確に行う唯一の方法は、完全に自動化されたシステムでアクセスの権限付与や承認をすることであり、自動化を通過して手動で行うことはできないようにします。 これはまさにProject Earthで行っていたことであり、管理者であっても、ユーザーのアクセスを上書きすることはできません。

これを分解すると、いくつかの核となるステージがあります:

  • アクセスの要求と継承
  • アクセスの承認と拒否
  • 検証とQ/A
  • 失効
  • 監査

すべてのリクエストとチケット管理で、ServiceNow(SNOW)を活用しています。 SNOWで、ユーザーが特定データのタイプへのアクセスを要求できるカスタムカタログを作成しました。 新しいデータソースや「ロール」が作成されるたびに、利用可能なロールのタイプやデータが自動的に生成され、SNOWに公開されます。

リクエストは、承認を得るためにマネージャーに送られ、そしてアクセスが許可される前に承認する必要がある2人の別の承認者に送られます。 この「デュアルキー」の承認により、適切なチェックとバランスが保証されます。 もう1つの重要な点は、人々がアクセスをリクエストできる時間は制限されており、いつでも取り消すことができるということです。 有効期限切れや失効時には、メンバーシップは自動的に削除されます。

リクエストが承認されると、ロールの割り当てやグループメンバーシップ構成は完全に自動処理されます。

以下の図は、フローの概要を示します:

Scenario - Secure Analytics Platform - Flow Policy Detail
Scenario - Secure Analytics Platform - RBAC / Role Assignment

検証のために、グループのメンバーがSNOWで「承認済み」状態に一致することを確認するチェックがあります。 すべての認証とアクセスのリクエストは記録され、中央のログシステムに保存されます。 このシステムを使用して、異常なアクセスや異常な事象を探すことができます。

変更管理

監査において重要なことは、システムのすべての側面にわたる適切な変更管理です。 リクエストや承認はすべてSNOWに保存されます。 Puppet、カスタムロジックとコードなど、その他すべてのアイテムは、特定の開発者かキーのみがアクセスできる、強化されたソース管理システムに保持されました。 すべての変更や新規コードは、最初にコードレビュープロセスやセキュリティ検証を通過します。 レビュー済みや承認された状態になると、開発またはステージング環境での検証が完了するまで、変更は「purgatory」に入れられます(*訳注: 直訳すると「煉獄」(れんごく)。カトリックの教義における「この世のいのちの終わりと天国との間に多くの人が経ると教えられる清めの期間」だそうです。本番リリース前のテスト環境をそれに例えていると思われます)。 すべての本番システムへの変更は、自動化を使用して人的エラーの可能性を最小化しています。

歴史を振り返る

これまでのインフラストラクチャーの歴史と、現在の状況に至るまでのおおまかな流れを簡単に振り返ってみましょう。

データセンターの進化

データセンターは、過去十年で大きな進化を遂げています。以下のセクションで、各時代を詳しく見てみましょう。  

メインフレーム時代

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

  • 生来的に統合された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の乱造による更に大規模なストレージ容量の要求
  • ストレージアレイの拡張要求によってサイロの数や複雑性が増加
  • ストレージアレイによって1GBあたりの単価が増加
  • ストレージアレイ上でリソースが競合する可能性
  • 安全性確保のためストレージ構成がより一層複雑に:
    • VMのデータストア / LUN比率
    • I/O リクエストに対応するためのスピンドル数

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

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

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

SSDの問題点:

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

クラウドについて

クラウドの定義は非常に曖昧なものです。 簡単に言えば、別の誰かがどこかでホストしているサービスを購入し活用できる機能ということです。

クラウドの登場によって、IT部門や業務部門、そしてエンドユーザーのあり方も変わってきています。

業務部門やITの利用者は、クラウドと同様の俊敏性や、価値実現までの早さをIT部門に求めます。 これがかなわない場合には、自ら直接クラウドを利用しようとさえします。 しかし、これがIT部門に別の問題をもたらすのです。 それはデータセキュリティという問題です。

クラウドサービスの柱となるもの:

  • セルフサービス / オンデマンド
    • 価値実現までの早さ (TTV – Time to Value) / 利用障壁の低さ
  • SLAに従ったサービス提供
    • 稼動時間、可用性、パフォーマンスを契約に基づいた保証
  • フラクショナル(より小規模な単位)な消費モデル
    • 使用する分のみの支払い(一部のサービスは無償)
クラウドの分類

一般的にクラウドは、主に以下の3つのサービス形態に分類することができます(レベルの高い順に並べてあります):

  • Software as a Service (SaaS)
    • URLへのアクセスのみでソフトウェアやサービスが利用可能
    • 例: Workday、Salesforce.com、Google searchなど
  • Platform as a Service (PaaS)
    • 導入、開発のためのプラットフォーム提供
    • 例: Amazon Elastic Beanstalk / Relational Database Services (RDS)、Google App Engineなど
  • Infrastructure as a Service (IaaS)
    • VM、コンテナ、NFV as a service
    • 例: Amazon EC2/ECS、Microsoft Azure、Google Compute Engine (GCE) など
IT部門の変化

クラウドは、IT部門に対して目をそむけることのできないジレンマをもたらしています。 IT部門自身がクラウドに取り組んだり、同様の機能を提供したりすることは可能です。 しかし、データは社内に確保したいと望むものの、クラウドのセルフサービス機能や迅速性を提供しなければならないのです。

このような変化によって、IT部門は、エンドユーザー(自社の社員)に対する合理的なサービスプロバイダーとなることを強いられています。

レイテンシーの重要性

以下の表に、各I/Oタイプ別のレイテンシーを示します:

項目 レイテンシー 補足
L1キャッシュ参照 0.5 ns
L2キャッシュ参照 7 ns L1キャッシュ×14
DRAMアクセス 100 ns L2キャッシュ×20、L1キャッシュ×200
3D XPointベースのNVMe SSD READ 10,000 ns(期待値) 10 us または 0.01 ms
NAND NVMe SSD R/W 20,000 ns 20 us または 0.02 ms
NAND SATA SSD R/W 50,000-60,000 ns 50-60 us または 0.05-0.06 ms
SSDから4KをランダムREAD 150,000 ns 150 us または 0.15 ms
P2P TCP/IPレイテンシー(物理から物理) 150,000 ns 150 us または 0.15 ms
P2P TCP/IPレイテンシー (仮想から仮想) 250,000 ns 250 us または 0.25 ms
メモリから1MBシーケンシャルREAD 250,000 ns 250 us または 0.25 ms
データセンター内のラウンドトリップ 500,000 ns 500 us または 0.25 ms
SSDから1MBシーケンシャルREAD 1,000,000 ns 1 ms, メモリ×4
ディスクシーク 10,000,000 nsまたは10,000 us 10 ms、データセンターラウンドトリップ x 20
ディスクから1MBシーケンシャルREAD 20,000,000 nsまたは 20,000 us 20 ms、メモリ x 80、SSD x 20
CAカリフォルニア州からパケット転送 -> オランダ -> カリフォルニア州 150,000,000 ns 150 ms

(典拠: Jeff Dean, https://gist.github.com/jboner/2841832)

上記の表から、CPUのキャッシュに対するアクセスは、 ~0.5-7ns(L1対L2)で実施されることが分かります。 メインメモリに対するアクセスは~100 nsで、ローカルのSSDに対する4KのReadは、~150,000 ns、つまり0.15msになります。

一般的なエンタープライズ向けSSD (この場合は、Intel S3700 - 仕様) を利用すれば、次のような性能が得られます:

  • ランダムI/Oパフォーマンス:
    • ランダム4K Read:最大75,000 IOPS
    • ランダム4K Write: 最大36,000 IOPS
  • シーケンシャルの転送量:
    • 持続的なシーケンシャルRead: 最大500MB/s
    • 持続的なシーケンシャルWrite: 最大460MB/s
  • レイテンシー:
    • Read: 50us
    • Write: 65us

転送量について

従来のストレージの場合、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の能力も十分なものと想定しています。

ネットワーク帯域幅 (BW) 帯域幅の飽和状態に必要なSSD本数
コントローラーの接続性 使用可能な帯域幅 Read I/O Write I/O
Dual 4Gb FC 8Gb == 1GB 2 3
Dual 8Gb FC 16Gb == 2GB 4 5
Dual 16Gb FC 32Gb == 4GB 8 9
Dual 32Gb FC 64Gb == 8GB 16 19
Dual 1Gb ETH 2Gb == 0.25GB 1 1
Dual 10Gb ETH 20Gb == 2.5GB 5 6

この表に示したように、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%にも達することでしょう。

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

ユーザー空間とカーネル空間

よく議論に上るのは、ユーザー空間とカーネル空間の分担についての話題です。ここでは、それぞれの意味とメリット、デメリットについて説明します。

どんなオペレーティングシステム (OS) にも、2つのコアとなる処理領域があります:

  • カーネル空間
    • OSで最も強い権限を持つ部分
    • スケジューリングやメモリ管理などを実施
    • 物理デバイスドライバーを包含しハードウェアとのやり取りを実施
  • ユーザー空間
    • 「その他の全て」
    • ほとんどのアプリケーションやプロセスがここに存在
    • メモリや実行が保護されている

これら2つの空間が連携することで、OSは機能します。先に進む前に、幾つかの重要な用語を定義しておきます:

  • システムコール
    • カーネルコールとも呼ばれます。アクティブなプロセスが、カーネルにより処理される何らかの機能を呼び出すための仕組みで、割り込み(詳細は後述)によって実行される
  • コンテキストスイッチ
    • 実行状態をプロセス側からカーネル側に、またはその逆に切り替える処理

例えば、データをディスクに書き込むような単純なアプリケーションの例を見てみましょう。ここでは次のような処理が行われます:

  1. アプリがディスクへのデータ書き込みをリクエスト
  2. システムコールを実行
  3. カーネルに対するコンテキストスイッチ
  4. カーネルがデータをコピー
  5. ドライバー経由でディスクに書き込み処理

以下にこのようなやり取りの例を示します。

User and Kernel Space Interaction
ユーザー空間とカーネル空間のやり取り

どちらの空間が優れているのでしょうか?実際には、それぞれにメリットとデメリットがあります:

  • ユーザー空間
    • 非常に柔軟
    • 障害の影響が限定的(プロセスまで)
    • 非効率的になり得る
      • コンテキストスイッチで時間を消費(~1,000ns)
  • カーネル空間
    • 固定的
    • 障害の影響範囲が広い
    • 効率的
      • コンテキストスイッチが不要

ポーリングと割り込み

もう1つのコアは、カーネル空間とユーザー空間のやり取りを実施するコンポーネントです。やり取りには2つタイプがあります:

  • ポーリング
    • 継続的に「ポーリング」、つまり何かを問い続ける
    • 例:マウス、モニターのリフレッシュなど
    • 一定のCPUを消費するがレイテンシーは大幅に低い
    • カーネルの割り込みハンドラを使用する必要がない
      • コンテキストスイッチが不要
  • 割り込み
    • 「ちょっとお願いできますか」
    • 例:手を上げて何かを頼むようなもの
    • 「CPU効率」は良いが、常にそうとは限らない
    • 通常は高いレイテンシー

ユーザー空間とポーリングへのシフト

昔に比べると、デバイスは遙かに高速になり(例えば、NVMe、Intel Optane、pMEMなど)、カーネルとデバイスのやり取りがボトルネックになってきています。 このようなボトルネックを排除するために、多くのベンダーが処理をカーネルからユーザー空間に移し、ポーリング方式を採用することで、より優れた結果を得ようとしています。

この良い例として、Storage Performance Development Kit (SPDK)Data Plane Development Kit (DPDK)が上げられます。これらのプロジェクトは、パフォーマンスを最大化し、レイテンシーを最大限縮小して、優れた結果を生みだしています。

このようなシフトは、2つの主要な変更によって可能となっています:

  1. デバイスドライバーを(カーネルではなく)ユーザー空間に移動
  2. (割り込みではなく)ポーリングを使用

この方式の場合には、以下を排除できるため、これまでのカーネルベースに比べて遙かにすぐれたパフォーマンスを得ることができます:

  • 処理負荷の高いシステムコールや割り込みハンドラ
  • データコピー
  • コンテキストスイッチ

ユーザー空間に置かれたドライバーを使用したデバイスとのやり取りを以下に示します:

User Space and Polling Interaction
ユーザー空間とポーリングの関係

実際に、NutanixがAHVのために開発したソフトウェアの一部 (vhost-user-scsi) が、IntelのSPDKプロジェクトで使用されています。

Webスケール

Webスケール – ウェブスケール – 名詞 – コンピューターアーキテクチャー
インフラストラクチャーおよびコンピューティングのための
新しいアーキテクチャー

本セクションでは、「Webスケール」インフラストラクチャーの核となる概念と、なぜそれを採用するのかについて説明します。 始める前に、Webスケールだからといって、GoogleやFacebook、Microsoftのような「超大規模なスケール」になる必要はないということを明言しておきます。 Webスケールな構成はどんな規模(3ノードでも、数千ノードでも)でも可能であり、その恩恵を受けることができます。

これまでの課題は:

  • とにかく複雑
  • インクリメンタル(漸増的)な拡張が求められる
  • アジャイルでなければならない

Webスケールなインフラストラクチャーについて説明する場合、いくつか重要な要素があります:

  • ハイパーコンバージェンス
  • ソフトウェア デファインド インテリジェンス
  • 自律分散システム
  • インクリメンタルかつリニアな拡張性

その他の要素:

  • APIベースの自動化と豊富な分析機能
  • セキュリティをコアに据えている
  • 自己修復機能

以下のセクションでは、これらの技術的な意味を説明します。

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

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

ハイパーコンバージェンスとは、つまり:

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

メリットとしては:

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

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

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

サポート対象アーキテクチャー

Nutanixでは、現在、x86とIBM Powerアーキテクチャーの両方をサポートしています。

つまり:

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

メリットとしては:

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

最後の項目について: 古いハードウェアでも、最新の最も優れたソフトウェアを稼動させることができます。 つまり、減価償却サイクルに入ったハードウェアでも、最新版のソフトウェアや、今工場から出荷されている新しい製品と同等な機能が使用できるということです。

自律分散システム

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

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

つまり:

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

メリットとしては:

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

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

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

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

つまり:

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

メリットとしては:

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

理解しておきたい内容

まとめ:

  1. (物理サーバーにおける)非効率な計算資源の利用が、仮想化への移行へとつながった
  2. vMotionやHA、DRSといった機能に対応できるよう集中型のストレージ装置が登場した
  3. VMの乱造がストレージへの負荷やリソース競合状態を増加させた
  4. SSDが問題を緩和したが、ネットワークやコントローラーがボトルネックとなった
  5. キャッシュ/メモリへのアクセスをネットワーク経由で行うと、大きなオーバーヘッドが発生し、メリットが失われる
  6. アレイ構成の複雑さは解決されることなく従来どおり
  7. サーバーサイドのキャッシュが、アレイの負荷やネットワークへの影響を軽減したが、ソリューション実現には、新たに別のコンポーネントが必要となる
  8. 処理をローカルで完結させれば、従来はネットワーク経由の処理により発生していたボトルネックやオーバーヘッドを軽減できる
  9. インフラストラクチャー自体よりも、管理の簡素化やスタックのシンプル化に、もっと目を向けるべきである
  10. それを実現できれば、Webスケールな世界のできあがりです!

Nutanixバイブルについて

Nutanixバイブルは、Dheeraj Pandey(元Nutanix CEO)とSteven Poitras(元 Nutanix Chief Architect)なしでは実現できませんでした。

Nutanixバイブルが誕生した理由と経緯について、Dheeraj の言葉を引用します。

最初に、「バイブル」という本書の名前ですが、神に関心のない方や、無神論者であるため自分には関係ないと思われる方もいらっしゃるかと思います。 しかし、辞書「Merriam Webster」によれば、「バイブル」とは、たとえ宗教とは関係のない事柄であっても、聖書のように「高い権威や幅広い読者層を持つ傑出した出版物」という意味を持ちます。 この表現によってNutanixバイブルの本質を理解することができます。 本書は、Nutanixの中では、常に控えめな立場を取りながら、一方では最高レベルの知識を有する1人で、Nutanix最初のソリューションアーキテクトでもあるSteven Poitrasが最初に執筆を始めたものです。 彼は「初期からの社員」という立場に甘んじることなく、この分野の権威であり続けています。 彼の知識そのものがNutanixに力を与えているのではなく、自らの知識を共有しようという彼の行動力こそが、Nutanixという会社をより強いものにしています。 この分野における彼の高い専門性、PowerShellやPythonを活用した面倒な作業の自動化、卓越した(そして内容と形態が美しくバランスされた)リファレンスアーキテクチャーの構築、YammerやTwitterに関して助けが必要なメンバーのリアルタイムな支援、内省や自己改善を必要としているエンジニアとの透明な関係、さらに、常に意欲的であることこそが、Nutanixという会社の文化を形成しているのです。

彼はブログを書き始めるにあたって、内容の透明性を維持し、デザインをオープンにすることで業界の支持を築きあげるという大きな夢を持っていました。 企業として考えた場合、彼がブログに書いたようなレベルでデザインやアーキテクチャーを公開することは稀です。 確かに、オープンソース企業は、ソースコードを公開しているため透明性が高いように思われますが、デザインの詳細や内部的な動作の仕組みについては、決して語ろうとはしません。 しかしNutanixの競合相手が製品やデザインの弱点を知れば、逆にそれはNutanixを強くすることにも繋がるのです。 なぜなら、Nutanixに隠すべきものがほとんどなく、特定の領域でピンポイントの批評が得られるなら、それはNutanixにとって役に立つものだからです。 機能やデザインに対する一般からの評価については、それが本当の弱みなのか、あるいは、本来は強みにもかかわらず誰かの恐怖心を煽っているだけなのかを、企業向けソーシャルネットワークであるYammerを通じて、遅かれ早かれ結論付けることができます。 つまりNutanixバイブルによって、自分達を過信するといったあやまちを避けることができるのです。 本Nutanixバイブルは、お客様やパートナーに対する誠実心の表明なのです。

この日々進歩し続ける記事の内容は、単に専門家だけでなく、世界中の読者を楽しませています。 アーキテクトやマネージャー、CIOまでがカンファレンス会場のロビーで私を呼び止め、鮮やかで明解な記述と詳細な解説図や図表についての賛辞を述べてくれます。 本書においてSteven Poitrasは、話の内容を省略することなくWebスケールについて語っています。 ほとんどの現場のITの担当者が、世の中の「スピード」に追随できず埋もれていく中で、誰もがNutanixの分散アーキテクチャーを活用できるようにすることは、決して容易ではありませんでした。本バイブルでは、コンピューターサイエンスとソフトウェアエンジニアリングのトレードオフを非常に分かりやすい言葉で表現しており、ITとDevOpsの間のギャップを埋めることができます。Nutanixは、この3~5年間で、IT担当者がDevOpsのWebスケールな専門用語を使って会話するようになるだろうと考えています。

いつも誠実たらんことを

-- 元 Nutanix CEO、Dheeraj Pandey

後書き

さらにNutanixを学ぶために、ご自身で Nutanix Test Drive をチェックしてください!

Nutanixバイブルをお読みいただき、ありがとうございました。これからも更新を続けていきますので、どうかお見逃しなく。そして、どうぞNutanixプラットフォームをお楽しみください!