Nutanixバイブル

Steven Poitras 著

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

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


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

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

序文

Dheeraj Pandey

Dheeraj Pandey, CEO, Nutanix

「Nutanixバイブル(The Nutanix Bible)」と命名された本書の序文を寄稿できることを大変名誉に思います。 最初に、「バイブル」という本書の名前ですが、神に関心のない方や、無神論者であるため自分には関係ないと思われる方もいらっしゃるかと思います。 しかし、辞書「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スケールな専門用語を使って会話するようになるだろうと考えています。

この初版において、私達はSteven Poitrasのブログを1冊の本としてまとめました。 本書への追記をやめる時が訪れたら、それはNutanixの終焉を意味します。私は全ての皆様に対し、これまでNutanixがやってきたことを、私達が常に記憶に留められるよう働きかけていただきたいと望んでいます。 その真実こそが、Nutanixを(自己満足や自信過剰から)解き放つものとなるからです。

いつも誠実たらんことを

-- Nutanix CEO、Dheeraj Pandey

Stuart Miniman

Stuart Miniman, Principal Research Contributor, Wikibon

今日のユーザーは、新しいテクノロジーによる集中砲火を受け続けています。 IT部門にとって「新しい優れた方法」を選択するチャンスは無限にあると言えますが、実際に新しいテクノロジーを導入し、さらに運用方法やプロセスを変えることは、決して容易ではありません。 適切なドキュメントの欠如がオープンソース テクノロジーの躍進さえも阻んできました。 Wikibonは、このようなコミュニティの問題解決を支援するために創立されました。 その意味で、Steven Poitrasによるブログの投稿から始まったNutanixバイブルは、ハイパーコンバージェンスやWebスケールの原則を学習したい、あるいはNutanixやハイパーバイザー アーキテクチャーを深く学びたい現場IT担当者にとって、様々な意味で参考になるものです。 Steven Poitrasが記述した概念は、優秀な業界のエンジニアが、高度なソフトウェアエンジニアリングの課題に応えるためのソリューションです。 本書は、こうしたテクノロジーを、現場のIT担当者が、技術的な正確性を損なうことなく理解できるように解説したものです。

現場のIT担当者にとって、分散システムやソフトウェア中心であるインフラストラクチャーの概念を理解することが重要です。Nutanixのお客様はもちろん、こうしたトレンドを理解したい方々にも本書はお勧めの1冊となります。 本書で説明されているテクノロジーは、複数の世界最大規模のデータセンターで採用されているものです。

-- Stuart Miniman, Principal Research Contributor, Wikibon

はじめに

Steven Poitras

Steven Poitras, Chief Architect, Digital Nutanix

Nutanixバイブルにようこそ! 私は毎日のようにNutanixプラットフォームに関わり、問題の解決に取り組み、その限界を押し広げてプラットフォームを進化させ続けています。 この「Nutanixバイブル」と呼ばれる作品は、私やNutanixの様々なエンジニアが日々利用しているヒントや技の概要を紹介し、 Nutanixプラットフォームのアーキテクチャー、設計上の考慮事項を説明する生きたドキュメントとして役立つように作成されています。

本書では、Nutanixの内部的な動作一般について説明しています。 説明されている全てのトピックは、Nutanixによって要約されておりますし、Nutanix環境を良好に動作させるために、全ての知識が必要となるわけでもありません。

それでは、お楽しみください!

-- Steven Poitras, Chief Architect, Digital Nutanix

歴史を振り返る

これまでのインフラストラクチャーの歴史と、現在の状況に至るまでのおおまかな流れを簡単に振り返ってみましょう。

データセンターの進化

データセンターは、過去十年で大きな進化を遂げています。以下のセクションで、各時代を詳しく見てみましょう。  

メインフレーム時代

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

  • 生来的に統合された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つのサービス形態に分類することができます(レベルの高い順に並べてあります):

  • SaaS (Software as a Service)
    • URLへのアクセスのみでソフトウェアやサービスが利用可能
    • 例: Workday、Salesforce.com、Google searchなど
  • PaaS (Platform as a Service)
    • 導入、開発のためのプラットフォーム提供
    • 例: 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タイプ別のレイテンシーを示します:

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上のソフトウェアとして稼動させています。

Note
サポート対象アーキテクチャー

Nutanixでは、現在、x86とIBM Powerアーキテクチャーの両方をサポートしています。

つまり:

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

メリットとしては:

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

最後の項目について: 古いハードウェアでも、最新の最も優れたソフトウェアを稼動させることができます。 つまり、減価償却サイクルに入ったハードウェアでも、最新版のソフトウェアや、今工場から出荷されている新しい製品と同等な機能が使用できるということです。

自律分散システム(Distributed Autonomous Systems)

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

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

つまり:

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

メリットとしては:

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

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

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

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

つまり:

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

メリットとしては:

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

ここまでで理解しておきたい内容

まとめ:

  1. (物理サーバーにおける)非効率な計算資源の利用が、仮想化への移行へとつながった
  2. vMotionやHA、DRSといった機能に対応できるよう集中型のストレージ装置が登場した
  3. VMの乱造がストレージへの負荷やリソース競合状態を増加させた
  4. SSDが問題を緩和したが、ネットワークやコントローラーがボトルネックとなった
  5. キャッシュ/メモリへのアクセスをネットワーク経由で行うと、大きなオーバーヘッドが発生し、メリットが失われる
  6. アレイ構成の複雑さは解決されることなく従来どおり
  7. サーバーサイドのキャッシュが、アレイの負荷やネットワークへの影響を軽減したが、ソリューション実現には、新たに別のコンポーネントが必要となる
  8. 処理をローカルで完結させれば、従来はネットワーク経由の処理により発生していたボトルネックやオーバーヘッドを軽減できる
  9. インフラストラクチャー自体よりも、管理の簡素化やスタックのシンプル化に、もっと目を向けるべきである
  10. それを実現できれば、Webスケールな世界のできあがりです!

Part 1: Core

Book of Basics

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

戦略とビジョン

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、そしてXenServerを使用することもできます)。

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

  • コアプラットフォーム (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、KVM、Hyper-V)およびNutanixコントローラーVM(CVM)を稼動させることができます。 Nutanix CVMは、Nutanixソフトウェアを稼動させ、ハイパーバイザーおよびその上で稼動する全てのVMに対するI/O処理の全てを受け持ちます。 VMware vSphereが稼動するNutanixのユニットの、SSDとHDDデバイスを管理するSCSIコントローラーは、VM-Direct Path(Intel VT-d)を利用して、CVMに直接パスされます。 Hyper-Vの場合、ストレージ デバイスは、CVMにパススルーされます。

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

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にパススルー接続されます。

Note
コントローラーの仮想化

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

  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
ソフトウェア デファインド コントローラー フレームワーク

クラスター コンポーネント

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

常にユーザーを主眼に置く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に渡されます。

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

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

アップグレードの問題が発生した場合は、アップグレードを停止して進行しません。 注: アップグレードが実際に開始される前に、アップグレード前のチェックでほとんどの問題が検出されるため、これは非常にまれです。 ただし、アップグレード前のチェックが成功して実際のアップグレード中に問題が発生した場合、クラスターで実行されているワークロードとユーザーの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(ファンデーション)は、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サービスが行うもので、アプレットではありません。

Note
プロからのヒント

ターゲットとなる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の製品デザインリーダー、Jeremy Salleeのデザインメソドロジーと適用に関する素晴らしい投稿 http://salleedesign.com/stuff/sdwip/blog/nutanix-case-study/ をご覧ください(このサイトも彼がデザインしたものです)。

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

アーキテクチャー

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アーキテクチャー
Note
プロからのヒント

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

Prismのサービス

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

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

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

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

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

Note
プロからのヒント

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

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

認証

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

  • Prism Element (PE)
    • ローカル
    • Active Directory
    • LDAP
  • Prism Central (PC)
    • ローカル
    • Active Directory
    • LDAP
    • SAML認証 (IDP)
Note
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
Note
検索のセマンティクス

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 ‐ ダッシュボード
Note

キーボードのショートカット

アクセスの良さと使いやすさが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
Note
異常検出アルゴリズム

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

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

Upgrade Software - Main
ソフトウェアアップのグレード - メイン
Note
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
ソフトウェアのアップグレード - 完了
Note
注意

現状の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は、現在のホストとは別にライブマイグレーションされ、ホストがアップグレードされる通りブートが行われます。 この処理は、クラスター内の全てのホストのアップグレードが完了するまで、それぞれのホストに対して繰り返し実行されます。

Note
プロからのヒント

クラスター全体のアップグレードステータスは、いずれかの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サイズヒストグラム
Note
プロからのヒント

数値にスパイクが見られる場合には、まず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レイテンシーヒストグラム
Note
プロからのヒント

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
Note
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
  • スクリプトインターフェイス
Note
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のコール例
Note
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>

Example: net.create vlan.133 ip_config=10.1.1.1/24

ネットワーク一覧

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

net.list

DHCPスコープの作成

説明: DHCPスコープの作成

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

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

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

Example: net.list_vms vlan.133

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

説明: DHCP DNSの設定

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

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

仮想マシンの作成

説明: VMの作成

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

Example: vm.create testVM memory=2G num_vcpus=2

複数の仮想マシンを作成

説明: 複数VMの作成

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

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

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

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

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

Example: vm.clone testClone clone_from_vm=MYBASEVM

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

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

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

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

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

# Description: Create disk for OS

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

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

VMにNICを追加

説明: NICを作成して追加

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

Example: vm.nic_create testVM network=vlan.100

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

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

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

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

Example: vm.update_boot_device testVM disk_addr=scsi.0

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

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

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

Example: vm.update_boot_device testVM disk_addr=ide.0

CD-ROMにISOをマウント

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

手順:

1. ISOをコンテナにアップロード

2. クライアントIPのホワイトリストを有効化

3. ISOをアップロードして共有

ISOでCD-ROMを作成

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

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

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

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

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

CD-ROMからISOをデタッチ

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

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

VMの起動

説明: VMを起動する

vm.on <VM NAME(S)>

Example: vm.on testVM

全てのVMを起動

Example: vm.on *

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

Example: vm.on testVM*

特定範囲のVMを起動

Example: 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) のステータスを確認

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

# Block status
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>

Example: Get-Help Get-Process

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

<Some expression or object> | Get-Member

Example: $someObject | Get-Member

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

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

Prism コマンドレット Installer Link
Prism コマンドレット Installer Link
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 – アクロポリス – 名詞 – データプレーン
ストレージ、サーバー、仮想化プラットフォーム

アーキテクチャー

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

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

High-level AOS Architecture
High-level AOS Architecture

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

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

Note
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)。 推定要求値は、平滑化アルゴリズムを使って使用状況の遷移を計算します。 ワークロードの移動判断に推定要求値を使用することで、使用率のスパイク(一瞬の数値の跳ね上がり)に引きずられないようにします。

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

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

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

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

AOS Dynamic Schedulerでは、この問題に対応すべく、非対称性の発生ではなく想定したリソース競合が発生した場合に限りワークロードを移動させています。 注意: DFSは、ホットスポットの発生を回避したり、リビルドの速度を上げたりするために、データをクラスター全体に均一に分散させるという異なる方法を取っています。 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コンプライアンスとモニタリング
Note
一覧:
  • コンプライアンスは継続的な活動
  • 監視し、異常を探す

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

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

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

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

人間
Note
一覧:
  • 教育、教育、教育
  • 強力な慣行と練習を強制する(例えば、コンピューターのロック)

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

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

Note
アドホックなSCMAの実行

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

# Run on a single CVM
sudo salt-call state.highstate

# Run on all CVMs
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] #Default:no

Note
カスタムログインバナー

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

  1. 既存バナーのバックアップを取得
    • sudo cp -a /srv/salt/security/KVM/sshd/DODbanner /srv/salt/security/KVM/sshd/DODbannerbak
  2. viを使って既存バナーを編集
    • sudo vi /srv/salt/security/KVM/sshd/DODbanner
  3. 上記手順を全てのCVMに対して実施するか、または変更済みバナーを他の全てのCVMに対してSCP実行
  4. 上記コマンドを使用してバナーを有効化

CVMパスワードの強度設定

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

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

Advanced Instruction Detection Environment (AIDE) の設定

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

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

SNMPv3限定の設定

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

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

SCMAスケジュールの設定

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

ncli cluster edit-cvm-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY] #Default: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] #Default:no

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

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

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

Advanced Instruction Detection Environment (AIDE) の設定

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

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

SCMAスケジュールの設定

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

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

クラスター ロックダウン

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

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

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

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

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

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

Cluster Lockdown - Add Key
クラスター ロックダウン - キーの追加
Note
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
データの暗号化 - アプリケーションによるデータ変換
Note
暗号化とデータ効率

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

チェックサムの境界でディスクから読み込まれた暗号化データは、復号化されてゲストに返されます。 複合化/暗号化をチェックサムの境界ごとに実施することで、読み込み増幅 (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で割って小数点以下を切り上げた数)のノードが必要になります。

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

暗号化を有効にした場合、データ暗号化キー (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で構成されます。
Note
最大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の機能(現在は開発中)で、すべてがユーザー空間で処理される拡張可能なファイルシステムとブロック管理レイヤーを作成します。 これにより、デバイスからファイルシステムが排除され、ファイルシステムカーネルドライバーの呼び出しが削除されます。 新しいストレージメディア(例えば、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)と永続化(RFなどによる)のためのすべてのI/O処理を担当します。 書き込みリクエストがStargateに届くと、書き込みが、OpLog、エクステントストア、または自律型エクステントストアのどこに永続化されるかを判断する、書き込みキャラクタライザ(characterizer)があります。 同様に読み取りの場合には、読み取りキャラクタライザが読み取りの処理と、キャッシングや先読みの管理を担当します。

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

DSF I/O Path
DSF I/O Path

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

オールフラッシュノード構成の場合、SSDデバイスのみでエクステントストアが構成され、フラッシュ層のみの存在となるため、ILM層は形成されません。 ハイブリッドフラッシュが使用されている場合(例えば、NVMe、Intel Optaneなど、+ SATA SSD)、最高のパフォーマンスメディアはTier 0であり、低パフォーマンスメディアはTier 1です。 ハイブリッドの、オールフラッシュではないシナリオでは、フラッシュはTier 0で、HDDはTier 1です。

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

Oplogは共有リソースですが、割り当てはvDisk単位で行われます。これは、それぞれのvDiskが平等に利用できるようにするためです。 この値はvDiskごとのOpLogリミット(vDiskごとのOpLogの最大値)により決まります。 複数のvDiskを持つVMのOpLogサイズは、この値とvDisk数の積になります。

vDiskごとの OpLogリミットは現在6GB (4.6時点)です。以前のバージョンでは2GBでした

この値は、以下のGflagで決まります: vdisk_distributed_oplog_max_dirty_MB

エクステントストア
  • 主な役割: 永続的なデータストレージ
  • 説明: エクステントストアは、DSFの永続的な大容量ストレージとして、すべてのデバイス層(PCIe SSD、SATA SSD、HDD)に存在し、デバイス/層の追加を容易にできるよう拡張可能です。 エクステントストアに入っているデータは、 A) OpLogから排出されたもの、または、 B) シーケンシャル/サステインド処理によりOpLogを経由せずに直接投入されたもののいずれかです。 Nutanix ILMは、I/Oパターンに応じて動的に配置する層を決定し、データを層の間で移動させます。
Note
シーケンシャル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.11.1以降、AESを有効にするには、ノードには少なくとも8つのフラッシュデバイスが必要で、 任意の数のフラッシュデバイスで構成するには少なくとも1つのデバイスがNVMeである必要があります。
ユニファイド キャッシュ(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ユニファイド キャッシュ
Note
キャッシュの粒度とロジック

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

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

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

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

拡張可能メタデータ

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

メタデータは、インテリジェントなシステムの中心となるものですが、ファイルシステムやストレージアレイにとって非常に重要な存在となります。 「メタデータ」という用語についてわからないのであれば、本質的にメタデータは「データに関するデータ」です。 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ブロックマップ、エクステントとノードのマッピング、時系列の統計情報、構成情報など

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

前述のアーキテクチャーのセクションでも説明した通り、DFSはリング状のキーバリューストアを使用して他のプラットフォームデータ(例えばステータスデータなど)と同様に、不可欠なグローバルメタデータをストアしています。 グローバルメタデータの可用性と冗長性を確保するため、レプリケーション ファクタ(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
ブロック/ラック障害時のレプリカの配置方法
Note
ラック/ブロック アウェアネス対メトロクラスター

よくある質問として、クラスターを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より前のバージョンの場合、ブロック アウェアネスには以下の条件を満たすことが必要となります:

  • 各ブロックのSDDまたは 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ノード ブロック/ラック アウェアな配置
Note
メタデータ アウェアネスの条件

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

  • 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つコピーされています。

Note
データ分散の重要性

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

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

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

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

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

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

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

想定される障害レベル

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

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

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

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はリングに戻されます。

Note
プロからのヒント

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

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

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

# Block status
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が復旧すると、プライマリパスが役割を引き継ぎます。

キャパシティの最適化

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)とします。

Note
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
Note
プロからのヒント

クラスターサイズは、常にストライプサイズ(データ+パリティ)より最低でも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デコード済みストラプ – ポストセービング
Note
プロからのヒント

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

圧縮

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

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

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

Note
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)

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

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

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

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

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

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

下記に、オフライン圧縮とDFS 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はデータ取り込み時にインラインでフィンガープリントを取得します。キャパシティ層で重複排除が可能な重複データは、スキャンしたり再読み込みしたりする必要がないため、重複したデータは基本的に削除することが可能です。

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

Note
プロからのヒント

ベースイメージ(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パス概要セクション内の「ユニファイド キャッシュ」に関するサブセクションをご覧ください。

Note
フィンガープリント済み 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 ページ で確認することができます。

Note
重複排除 + 圧縮

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秒のサンプリングごとに複数の読み取りが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
データ ローカリティ
Note
データ移行のしきい値

キャッシュローカリティはリアルタイムに発生し、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は、ディスク デバイスがヒットされないため、ここではカウントされません。
  • 使用場面: キャッシュから提供した処理やディスクをヒットした処理の数を確認する場合に使用されます。
Note
メトリクスと統計情報の保持

メトリクスと時系列データは、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を使って外部と接続します。
Note
現在の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をダブルクリックし、インストール プロセスを開始します。

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

以下のコマンドを実行して、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のインストールが完了し、利用可能となりました。

Note
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

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

Example:
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) 機能を提供しており、ユーザーはDSF上で稼動するVMやオブジェクトをバックアップ、リストア、DRすることができます。

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

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

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

構成要素

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

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

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

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

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

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

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

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

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

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

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

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

DR Construct Mapping
DR構成要素の関係
Note
ポリシーベースの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(スケジュールを作成)」をクリックし、スケジュールを完成させます。

Note
複数のスケジュール

スナップショットやレプリケーションスケジュールは、複数作成することができます。例えば、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 - 移行

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

Note
プロからのヒント

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

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

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

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

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

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

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

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

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

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

Note
VmQueisced Snapshot Service (VSS)

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

サポート対象構成

本ソリューションは、以下のバージョンを含む、WindowsとLinuxゲスト双方に対応します。(以下の一覧が全てではありません。完全なサポート対象リストについては、ドキュメントをご覧ください)

  • ハイパーバイザー:
    • ESX
    • AHV
  • Windows
    • 2008R2, 2012, 2012R2
  • Linux
    • CentOS 6.5/7.0
    • RHEL 6.5/7.0
    • OEL 6.5/7.0
    • Ubuntu 14.04+
    • SLES11SP3+
前提

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(アプリケーション整合性スナップショットを使用)」を選択することで、 アプリケーション整合性のあるスナップショットを取得することができます。

Note
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
Note
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
レプリケーションアーキテクチャー

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

Note
プロからのヒント

プロキシを利用してリモートサイトの設定を行う場合には、常にPrism Leaerにホストされ、CVMが停止した場合でも使用可能な状態にするため、必ずクラスターIPを使用するようにします。

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

Replication Architecture - Proxy
レプリケーションアーキテクチャー – プロキシ

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

Note
注意
これは本番環境以外で使用するべきです。また、可用性を確保するためにクラスターIPを使用するようにします。

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

Replication Architecture - SSH Tunnel
レプリケーションアーキテクチャー – SSHトンネル
グローバル重複排除

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

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

Replication Deduplication
レプリケーションの重複排除
Note
注意

レプリケーションの重複排除を可能にするためには、ソースおよびターゲットとなるコンテナおよび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 - リンク障害

Cloud Connect

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

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

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

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

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

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

Cloud Connect - Region
Cloud Connect リージョン

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

Cloud Connect - Multi-region
Cloud Connect マルチリージョン

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

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

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

Cloud Connect - Restore
Cloud Connect – リストア

アドミニストレーション

重要なページ

一般的なユーザーインターフェイスに加え、高度な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アップグレードを実行

download .tar.gz into ~/tmp

tar xzf .tar.gz

cd ~/tmp

./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

または

特定のサービスを起動

Start single service: cluster start  <Service Name>

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

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

サービスを停止

genesis stop <Service Name>

サービスを起動

cluster start

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

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

cluster start #NOTE: This will start all stopped services

cmdlineクラスターにノードを追加

説明: 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フルスキャンを起動

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

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

# Refresh Usage
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"

NOSのバージョンを調査

説明: NOSのバージョンを調査(注意: 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ノードのNOSバージョンをアップグレード

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

~/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 to the /home/nutanix directory

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
# NOTE: operation and entity_type should be all lowercase with k removed from the begining

指標値としきい値

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

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

異なるネットワークセグメント(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概要 - コンテンツキャッシュ
Note
プロからのヒント

理想的には、ワークロードが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ステータス
Note
プロからのヒント

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

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

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

2009/vdisk_stats ページの利用

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

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

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

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ソース
Note
プロからのヒント

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ステータス – 書き込み先
Note
プロからのヒント

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

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

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

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スキャンで削除するか否か)
  • 可変ステータス:mutable 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を導入した場合、コントローラー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を経由して通信します。

Note
プロセッサ世代間の互換性

異なるプロセッサ世代間で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つのチェーンに繋ぎ合わせることも可能です。

動作の仕組み

ストレージI/Oパス

AHVは、ESXiやHyper-Vのような従来のストレージ スタックを使用してはいません。 全てのディスクは、ロー(raw)SCSIブロックデバイスとしてVMに渡されます。 これによってI/Oパスを軽量化および最適化することができます。

Note
注意

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パスなのです。

Note
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> ...

Note
プロからのヒント

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つの「ホスト」に相当するリソース

ホストのメモリ容量に差がある場合、システムは最大のメモリ容量をもつホストを基準に、ホストあたりの予約量を決定します。

Note
5.0以降のリソース予約

リリース5.0より前には、ホストとセグメントベース両方の予約をサポートしていました。 リリース5.0以降は、セグメントベースの予約のみとなり、これは保証HAモードが選択されると自動的に設定されます。

予約セグメントは、クラスターの全てのホスト全体にリソースを分散させます。 この場合それぞれのホストは、HAのために予約されたメモリを共有することになります。 これによって、ホストに障害が発生した場合でも、VMを再起動するための十分なフェイルオーバー容量をクラスター全体で確保することができます。

以下の図は、予約セグメントの状態を示したものです:

HA - Reserved Segment
HA - 予約セグメント

ホストに障害が発生すると、VMはクラスターに残った正常なホストを使って再起動されます。

HA - Reserved Segment - Fail Over
HA - 予約セグメント - フェイルオーバー
Note
予約セグメントの計算

予約セグメントの総数と1ホストあたりの予約量は、システムが自動的に計算します。

必要な予約量の算出は、良く知られた「ナップサック問題」の解法に集約します。 最適な解は、NP困難 (NP-hard、指数関数的)ですが、実用的には発見的解法でも最適解に近いものを得ることができます。 Nutanixは、こうしたアルゴリズムの1つであるMTHMを採用しています。 Nutanixは、今後も配置アルゴリズムの改善に努めて参ります。

アドミニストレーション

近日公開!

重要なページ

近日公開!

コマンドリファレンス

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

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

2 – ネットワーク

Book of 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 時点の情報です。

Note
プロからのヒント

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ネットワーク概要
Note
Note
アップリンクとチーミングポリシー

デュアルToRスイッチを使用して、スイッチHAのために、両スイッチをクロスしたアップリンク構成をとることを推奨します。システムは、デフォルトでアップリックインターフェイスをアクティブ/パッシブモードで使用します。アップストリームのスイッチアーキテクチャーが、アクティブ/アクティブなアップリンクインターフェイス(例えば、vPCやMLAGなど)に対応していれば、より高いネットワークスループットを得るためにこれを使用することができます。

動作の仕組み

アレイオフロード - 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障害時

アドミニストレーション

重要なページ

近日公開!

コマンドリファレンス

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

説明: CLIからESXiホストの自動アップグレードを実行
#Nutanix NFSコンテナに、アップグレード オフライン バンドルをアップロード
# 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のローリングリブートを実行: PowerCLIの場合、自動ホス通りブート

ESXiホストサービスの再起動

説明: 各ESXiホストサービスを順次再起動

for i in `hostips`;do ssh root@$i "services.sh restart";done

ESXiホストの「Up」状態にあるNICを表示

説明: ESXiホストの「Up」状態にあるNICを表示

for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep Up;done

ESXiホストの10GbE NICとそのステータスを表示

説明: ESXiホストの10GbE NICとそのステータスを表示

for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep ixgbe;done

ESXiホストのアクティブなアダプターを表示

説明:ESXiホストのアクティブ、スタンドバイ、未使用状態にあるアダプターを表示

for i in `hostips`;do echo $i &&  ssh root@$i "esxcli network vswitch standard policy failover get --vswitch-name vSwitch0";done

ESXiホストのルーティングテーブルを表示

説明: ESXiホストのルーティングテーブルを表示

for i in `hostips`;do ssh root@$i 'esxcfg-route -l';done

データストアでVAAIが有効か否か確認

説明: データストアでVAAIが有効、サポートされているか否か確認

vmkfstools -Ph /vmfs/volumes/<Datastore Name>

VIBのアクセプタンスレベルをコミュニティサポートに設定

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

esxcli software acceptance set --level CommunitySupported

VIBのインストール

説明: 認証確認なしにvibをインストール

esxcli software vib install --viburl=/<VIB directory>/<VIB name> --no-sig-check

# または

esxcli software vib install --depoturl=/<VIB directory>/<VIB name> --no-sig-check

ESXiのramdiskスペースを確認

説明: ESXi ramdiskの空きスペースを確認

for i in `hostips`;do echo $i; ssh root@$i 'vdf -h';done

pynfsログのクリア

説明: 各ESXiホストのpynfsログをクリア

for i in `hostips`;do echo $i; ssh root@$i '> /pynfs/pynfs.log';done

指標値としきい値

近日公開!

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

近日公開!

Book of 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仮想スイッチネットワーク概要
Note
アップリンクとチーミングポリシー

デュアルToRスイッチを使用し、スイッチHAのために両スイッチをクロスしたアップリンク構成をとることを推奨します。システムは、デフォルトで特別な構成を必要としないスイッチ非依存モードでLBFOチームを形成します。

動作の仕組み

アレイオフロード – ODX

Nutanixプラットフォームは、Microsoft Offloaded Data Transfers(ODX)をサポートし、ハイパーバイザーのタスクをアレイにオフロードすることができます。 ハイパーバイザーが「仲介役」を果たす必要がなくなるため、より効率的になります。 現在Nutanixは、フルコピー(full copy)やゼロイング(zeroing)とSMBのためのプリミティブをサポートしています。 しかし、「ファストファイル (fast file)」クローン処理(書き込み可能なスナップショットを使用)が可能なVAAIとは異なり、ODXにはフルコピーを行うための同等なプリミティブが存在しません。 このため、現在nCLI、RESTまたはPowerShellコマンドレットから起動できるDSFクローン機能を利用する方がより効果的です。 現在のところ、ODXは以下の処理に使用されます。:

  • DSF SMBシェア上でのVM内のまたはVMからVMへのファイルコピー
  • SMBシェアファイルコピー

SCVMMライブラリ(DSF SMBシェア)からテンプレート導入 - 注意: シェアは、ショートネーム(つまりFQDNではない)を使用して、SCVMMクラスターに追加する必要があります。 これを簡単に行うには、クラスターのhostsファイル(つまり10.10.10.10 nutanix-130)にエントリーを追加します。

ODXは以下の処理には使用できません:

  • SCVMMによるVMのクローン
  • SCVMMライブラリ(非DSF SMBシェア)からテンプレート導入
  • XenDesktopクローンの導入

ODXの稼動状態は、Activity Traceページの「NFS Adapter」を使って確認できます(SMB経由で実行されますが、NFSです)。 vDiskのコピー状態は「NfsWorkerVaaiCopyDataOp」、ディスクのゼロイング(zeroing)状態は「NfsWorkerVaaiWriteZerosOp」で表示されます。

アドミニストレーション

重要なページ

近日公開!

コマンドリファレンス

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

説明: 特定のまたは複数のリモートホストで PowerShellを実行

$targetServers = "Host1","Host2","Etc"
Invoke-Command -ComputerName  $targetServers {
         <COMMAND or SCRIPT BLOCK>
}

使用可能なVMQオフロードを確認

説明: 指定したホストで使用可能なVMQオフロードの数を表示

gwmi –Namespace "root\virtualization\v2" –Class Msvm_VirtualEthernetSwitch | select elementname, MaxVMQOffloads

特定のプリフィックスに一致するVMのVMQを無効化

説明: 特定のVMに対するVMQを無効化

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 0

特定のプリフィックスに一致するVMのVMQを有効化

説明: 特定のVMに対するVMQを有効化

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 1

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

説明: 特定のプリフィックスに一致するVMを起動

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Stopped"} | Start-VM

特定のプリフィックスに一致するVMをシャットダウン

特定のプリフィックスに一致するVMをシャットダウン

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Running"}} | Shutdown-VM -RunAsynchronously

特定のプリフィックスに一致するVMを停止

特定のプリフィックスに一致するVMを停止

$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Stop-VM

Hyper-VホストRSSの設定の確認

説明: Hyper-VホストRSS (Receive Side Scaling) の設定の確認

Get-NetAdapterRss

WinshとWinRMのコネクティビティの確認

説明: WinshとWinRMのコネクティビティおよびステータスを、サンプルクエリを発行して確認。コンピューターシステムオブジェクトを返さない場合はエラーと判断。

allssh "winsh "get-wmiobject win32_computersystem"

指標値としきい値

近日公開!

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

近日公開!

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を体験することと同義です。

Note

試してみたいですか? 下記のリンクをクリックして試してみてください!

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 Clusters

Nutanix Clusters on AWS

Nutanix Clusters on AWSは、ターゲットクラウド環境のベアメタル リソースで実行される、オンデマンドのクラスターを提供します。 これにより、ご存知のNutanixプラットフォームのシンプルさで真のオンデマンドな収容能力を実現できます。 プロビジョニングさたクラスターは従来のAHVクラスターのように見えますが、クラウド プロバイダーのデータセンターで実行されています。

サポートされる構成

このソリューションは以下の構成に適用できます(このリストはおそらく不完全であり、完全なサポートされている構成のリストについては、ドキュメントを参照してください):

    主なユースケース:
  • オンデマンド / バースト容量
  • バックアップ / DR
  • クラウド ネイティブ
  • 地理的拡張 / DC統合
  • アプリケーションのマイグレーション
  • その他
    管理インターフェイス:
  • Nutanix Clusters Portal - プロビジョニング
  • Prism Central (PC) - Nutanixの管理
  • AWS Console - AWSの管理
    サポートされる環境:
  • クラウド:
    • AWS (EA)
  • EC2ベアメタル インスタンスの種類:
    • i3.metal
    • m5d.metal
    • z1d.metal
    アップグレード:
  • AOSの一部
    互換性のある機能:
  • AOSの機能
  • AWSのサービス
主な用語/構造

このセクションでの用語は、以下のように定義されています。

  • Nutanix Clusters Portal
    • Nutanix 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 Clusters Portalは、概観的にいうとNutanix Clusters on AWSをプロビジョニングし、AWSと対話するためのメイン インターフェイスです。

プロビジョニング手順は、おおまかに下記のステップとして要約できます。

  1. Nutanix Clusters Portalでクラスターを作成する
  2. 個別入力の展開(例えば、リージョン、AZ、インスタンスの種類、VPC/サブネットなど)
  3. Nutanix Cluster Orchestratorが、関連するリソースを作成する
  4. Nutanix AMIのHost agentが、Nutanix Clusters on AWSにチェックインする
  5. すべてのホストが起動すると、クラスターが作成される

以下は、Nutanix Clusters on AWSの相互作用における概要を示します:

Nutanix Clusters on AWS - Overview
Nutanix Clusters on AWS - 概要

以下は、Cluster Orchestratorによる入力と、作成されるリソースの概要を示します:

Nutanix Clusters on AWS - Cluster Orchestrator Inputs
Nutanix Clusters on AWS - Cluster Orchestratorのインプット

以下は、AWSでのノードの概要を示します:

Nutanix Clusters on AWS - Node Architecture
Nutanix Clusters on AWS - ノードのアーキテクチャー

ホストがベアメタルであるため、通常のオンプレミス展開と同様に、ストレージとネットワークのリソースを完全に制御できます。 CVMおよびAHVホストのブート領域では、EBSボリュームが使用されます。 注: EBSなどの特定のリソースとのやりとりは、AHVホストでNVMeコントローラーとして認識されるAWS Nitroカードを介して実行されます。

配置ポリシー

Nutanix Clusters on AWSは、デフォルトで7つのパーティションを持つ、パーティション配置ポリシーを使用します。 ホストは、Nutanixのラックに対応するパーティションに、ストライプ状に配置されています。 これにより、1~2箇所の「ラック」全体障害が発生しても、可用性を維持できます。

以下に、パーティションによる配置戦略および、ホストのストライピングの概要を示します:

Nutanix Clusters on AWS - Partition Placement
Nutanix Clusters on AWS - パーティション配置

複数種類のノードが利用されている場合(例えば、i3.metalやm5d.metalなど)、各ノードの種類ごとに、ノードがストライプ化された7つのパーティションがあります。

以下は、複数種類のインスタンスが使用されている場合の、パーティション配置戦略とホスト ストライピングについての概要です:

Nutanix Clusters on AWS - Partition Placement (Multi)
Nutanix Clusters on AWS - パーティション配置(複数種類)
ストレージ

Nutanix Clusters on AWSのストレージは、次の2つの領域に分類できます:

  1. コア / アクティブ
  2. ハイバネーション(Hibernation)

コア ストレージは、Nutanixクラスターで期待するものとまったく同じであり、「ローカル」ストレージデバイスをCVMに接続して、Stargateで活用します。

Note
インスタンスのストレージ

「ローカル」ストレージではAWSインスタンス ストアが使われており、 停電やノード障害が発生した場合の完全な復元力がなく、追加の考慮が必要になります。

たとえば、停電またはノード障害が発生した場合、ローカルのNutanixクラスターでは、ストレージはローカル デバイスに永続化されており、ノードや電源がオンラインに戻ると復旧します。 AWSインスタンス ストアの場合、このケースには当てはまりません。

ほとんどの場合、AZ全体が電源を失うまたはダウンするという可能性は低いですが、 センシティブなワークロードの場合は、次のことをお勧めします:

  • バックアップソリューションを活用してS3または永続性のあるストレージに保存する
  • 異なるAZ / リージョン / クラウド(オンプレミスまたはリモート)にある、別のNutanixクラスターにデータを複製する

Nutanix Clusters on AWSのユニークな機能の1つは、クラスターを「ハイバネート」状態にして、EC2コンピューティング インスタンスを停止している間もデータを永続化できることです。 これは、コンピューティング リソースが不要で、支払いを継続したくないが、データを永続化して後で復元できるようにしたいという場合に役立ちます。

クラスターがハイバネート状態になると、データはクラスターからS3にバックアップされます。 データがバックアップされると、EC2インスタンスが終了されます。 再開または復元の際には、新しいEC2インスタンスがプロビジョニングされ、データがS3からクラスターに読み込まれます。

ネットワーク

ネットワークは、いくつかの中核的な領域に分類できます:

  • ホスト / クラスターのネットワーク
  • ゲスト / UVMのネットワーク
  • WAN / L3ネットワーク
Note
ネイティブ対オーバーレイ

独自のオーバーレイ ネットワークを運用する代わりに、AWSサブネットでネイティブに運用することを決定しました。 これにより、プラットフォームで起動されているVMがパフォーマンス低下なくAWSサービスとネイティブに通信できるようになります。

Nutanix Clusters on AWSは、AWS VPCにプロビジョニングされます。以下に、AWS VPCの概要を示します:

Nutanix Clusters on AWS - AWS VPC
Nutanix Clusters on AWS - AWS VPC
Note
新規VPC対デフォルトVPC

AWSはデフォルトのVPCやサブネットなどを作成します。各リージョンには172.31.0.0/16のIPスキームを使用します。

企業のIPスキームに適合するサブネット、NATやインターネット ゲートウェイなどが関連付けられた、新規VPCを作成することを推奨します。 このことは、VPC(VPCピアリング)や既存のWANにネットワークを拡張する計画がある場合に重要です。 これはWAN上の他のサイトと同じように扱います。

ホスト ネットワーク

AWSのベアメタルで実行されているホストは従来のAHVホストであるため、同様にOVSベースのネットワーク スタックを利用します。

以下は、AWSでのAHVホストにおけるOVSスタックの概要を示しています:

Nutanix Clusters on AWS - OVS Architecture
Nutanix Clusters on AWS - OVSのアーキテクチャー

OVSスタックは、L3アップリンクブリッジが追加されていることを除いて、従来のAHVホストと同様です。

UVM(ゲストVM)のネットワークでは、VPCサブネットが使用されます。 UVMのネットワークは、クラスターの作成プロセス中、または下記の手順で作成できます:

AWSのVPCダッシュボードで、「subnets」をクリックし、「Create Subnet」をクリックして、ネットワークの詳細を入力します:

Nutanix Clusters on AWS - Create Subnet
Nutanix Clusters on AWS - OVS Architecture

注:CIDRブロックは、VPCのCIDR範囲のサブセットである必要があります。

サブネットはVPCからルート テーブルを継承します:

Nutanix Clusters on AWS - Route Table
Nutanix Clusters 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ピアリング接続を示します:

Nutanix Clusters on AWS - VPC Peering
Nutanix Clusters on AWS - VPCピアリング

各VPCのルートテーブルは、ピアリング接続を経由して他のVPCに向かうトラフィックをルーティングします(通信が双方向の場合、これは両側に存在する必要があります)。

Nutanix Clusters on AWS - Route Table
Nutanix Clusters on AWS - ルート テーブル

オンプレミスまたはWANへのネットワーク拡張では、VPNゲートウェイ(トンネル)またはAWS Direct Connectが利用できます。

セキュリティ

リソースがフル コントロール セキュリティ外であるクラウドで実行されている場合、データ暗号化とコンプライアンスは非常に重要な考慮事項です。

推奨事項は以下のように特徴付けられます:

  • データ暗号化を有効にする
  • プライベート サブネットのみを使用する(パブリックIP割り当てなし)
  • セキュリティ グループと許可ポートとIP CIDRブロックをロックダウンする
  • より詳細なセキュリティを実現するためには、Flowを活用する
使用法と構成

このセクションでは、Nutanix Clusters on AWSを構成して活用する方法について説明します。

おおまかなプロセスは、以下の手順となります:

  1. AWSアカウントの作成
  2. AWSネットワークリソースを構成する(必要な場合)
  3. Nutanix Clusters Portalを介してクラスターをプロビジョニングする
  4. プロビジョニングが完了したら、クラスターリソースを利用する

まだ続く!

Book of Storage Services

Volumes (ブロックサービス)

Nutanix Volumesは、バックエンドにあるDSFストレージを、iSCSI経由で外部ユーザー(ゲストOS、物理ホスト、コンテナなど)に提供する機能です。

本機能によって、オペレーティングシステムは、DSFにアクセスしてストレージ機能を利用できるようになります。この導入シナリオにおいて該当OSは、ハイパーバイザーを経由することなく、Nutanixに直接アクセスすることになります。

Volumesの主要なユースケース:

  • 共有ディスク
    • Oracle RAC、Microsoft Failover Clusteringなど
  • ファーストクラスのエンティティとしてのディスク
    • 実行コンテキストが短命かつデータが重要な場合
    • コンテナ、OpenStackなど
  • ゲスト内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 - フェイルバック
Note
ヘルス監視とデフォルト

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ログイン)、各ターゲットに対するロードバランシングが発生します。

Note
アクティブパス

以下のコマンドを使って、仮想ターゲットをホストしている、有効なStargateを確認することができます(ホストしているStargateのCVM IPを表示):

# Windows
Get-NetTCPConnection -State Established -RemotePort 3205

# Linux
iscsiadm -m session -P 1

4.7では、簡単なハッシュ関数を使用してクラスターノード全体にターゲットを分散しています。 5.0では、これがDynamic Scheduleに統合され、必要に応じて再バランスを取るようになっています。 また、どのノードを使用するかについては、該当ノードが正常である限り自由に設定を行うことができます。

Note
SCSI UNMAP (TRIM)

Volumesでは、SCSI T10仕様にあるSCSI UNMAP (TRM) コマンドをサポートしています。 このコマンドを使用することで、削除済みブロックのスペース再利用が可能となります。

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詳細

Nutanix Files VMは、プラットフォームのエージェントVMとして稼動し、設定プロセスの途中で透過的に導入されます。

下図は、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エントリー
Note
ファイルサーバー生成のための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は、それぞれIPを持ちDFSとの通信に使用します。 DFS参照プロセスでは、DFSをそのフォルダーをホストしている正しい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がNuatnixプラットフォーム上にデプロイされると、重複排除、圧縮、レプリケーションなどのAOS機能を利用できます。 ObjectsはAOS 5.11で導入されました。

サポートされる構成

ソリューションは以下の構成に適用できます(以下のリストは一部です。全てを確認する際には、ドキュメントをご覧ください):

    主なユースケース:
  • バックアップ
  • ビッグデータ/分析
    管理インターフェイス:
  • Prism Central (PC)
    ハイパーバイザー:
  • N/A - Nutanix MSPで実行(MSPがサポートするハイパーバイザーに依存)
    アップグレード:
  • LCM
    互換性のある機能:
  • 追記予定
    オブジェクトプロトコル:
  • S3 (version 4)
Note
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

Flow (マイクロセグメンテーション)

Flowは、分散かつステートフルなファイアウォールとして、AHVプラットフォームで稼動するエンティティ間やその外部とのきめ細かなネットワーク監視とエンフォースメントを可能にします。

サポートされている構成

このソリューションは以下の構成に適用できます(このリストはおそらく不完全であり、完全なサポートされている構成のリストについては、ドキュメントを参照してください):

    主なユースケース:
  • マイクロセグメンテーション
    管理インターフェイス:
  • Prism Central (PC)
    サポートされる環境:
  • オンプレミス:
    • AHV (AOS 5.10 現在)
  • クラウド:
    アップグレード:
  • AOSの一部
    互換性のある機能:
  • サービスチェイニング(Service Chaining)
  • Calm
  • Epoch

設定については、Prism Centralでポリシーを定義し、カテゴリに割り当てる形で行います。この手順によって、設定内容を集中管理し、複数のNutanixクラスターにプッシュできるようになります。それぞれのAHVホストについては、OpenFlowを使ってルールを導入します。

実装の構成

Nutanix Flowには、いくつかの重要な構成要素があります:

カテゴリ

カテゴリは、ポリシーや適用対象となるエンティティグループの定義に使用します。

  • キー/バリュー 「Tag」
  • 例: app | tier | group | location | subnet | etc.

例えば、商用環境のデータベースサービスを提供するVMには、以下のようにカテゴリが割り当てられる場合があります:

  • AppTier: Database
  • AppType: MySQL
  • Environment: Production

これらのカテゴリは、適用するルールやアクションを決定するために利用できます(Flow以外の機能でも利用されます)。

セキュリティルール

セキュリティルールは、定義済みのカテゴリ間で許可の内容を決定するためのルール定義です。

Flow - Microsegmentation - Rules
Flow - マイクロセグメンテーション - ルール

セキュリティルールには、以下に示すような幾つかのタイプが存在します:

  • アプリルール (App Rule)
    • 許可 (Allow) または拒否 (Deny) するトランスポート (TCP/UDP)、ポート、ソース / デスティネーションを共通のルールとして定義できます。
    • [Allow|Deny] Transport: Port(s) [To|From]
    • 例: Allow TCP 8080 from Category:Tier:Web to Category:Tier:App
  • 分離ルール (Isolation Rule)
    • カテゴリ間のトラフィックは拒否し、カテゴリ内のトラフィックについては許可します
    • 例: テナントAをテナントBとクローン環境から分離し、通常のネットワーク通信に影響を与えずに並列実行を可能にします。
  • 隔離ルール (Quarantine Rule)
    • 特定のVMまたはカテゴリへの全てのトラフィックを拒否します
    • 例: VM A、B、Cがウィルスに感染した場合、ウィルスのネットワーク感染を阻止するため、そのVMを隔離します

以下は、Flowマイクロセグメンテーションを使った、サンプルアプリケーションにおけるトラフィックコントロールの例です:

Flow - Microsegmentation - Example Application
Flow - マイクロセグメンテーション - サンプルアプリケーション
エンフォースメント

ルールが一致した場合にどんな対応を取るかという内容を、エンフォースメント (Enforcement) で決定します。AHVのFlowマイクロセグメンテーションには、2つのタイプのエンフォースメントがあります:

  • 適用(Apply)
    • ルールが一致した場合に、そのルールを適用します
  • Monitor
    • どのルールが一致するかを確認しながら、発生している通信を監視します

Flowマイクロセグメンテーション ルールは、パケットがUVMを出た時点で適用されます:

Flow - Microsegmentation - Flow
Flow - マイクロセグメンテーション - フロー

Book of Backup / DR Services

Leap (ポリシー駆動型DR / ランブック)

Note
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 現在)
  • クラウド:
    • 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年間の年次の回復ポイントを維持します。
Note
リニア保持ポリシー対ロールアップ保持ポリシー

保持期間が短い小さな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
Note
パワーオンのシーケンス

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
Note
フェイルオーバーおよびフェイルバックのネットワーク

ほとんどの場合で、テストネットワークには、ルーティング不可能な、または分離されたネットワークを使用します。 これにより、SIDの重複、ARPエントリーなどの問題が発生しなくなります。

Mine (バックアップソリューション)

近日公開!

Book of Orchestration Services

Calm (オーケストレーション / 自動化)

近日公開!

Book of Governance Services

Beam (コストガバナンス / コンプライアンス)

近日公開!

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」に入れられます(*訳注: 直訳すると「煉獄」(れんごく)。カトリックの教義における「この世のいのちの終わりと天国との間に多くの人が経ると教えられる清めの期間」だそうです。本番リリース前のテスト環境をそれに例えていると思われます)。 すべての本番システムへの変更は、自動化を使用して人的エラーの可能性を最小化しています。

シナリオ: マルチサイトのDR / レプリケーション

近日公開!

Part 4: インテグレーション

OpenStack

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

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

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

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

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

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

OpenStack + AOS OpenStack Driver
OpenStack + AOS OpenStackドライバー

これによって、複雑なOpenStackインフラストラクチャーやその管理を行う必要無しに、OpenStack PortalおよびAPI両方の良さを活かすことができます。 全てのバックエンド インフラストラクチャー サービス(サーバー、ストレージ、ネットワーク)は、ネイティブなNutanixサービスを活用します。 Nova Computeホスト等を導入する必要はありません。 本プラットフォームは、コントローラーと通信するサービスに対してAPIを提供し、ネイティブなAOS APIコールに変換します。 また、導入が容易なモデルとなっているため、OpenStack+Nutanixソリューションを、30分未満で完全に立ち上げることができます。

サポート対象となるOpenStackコントローラー

最新のソリューション(AOS 4.5.1時点)では、Kiloバージョン以降のOpenStackコントローラーが必要となります。

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

項目 役割 OpenStackコントローラー OVM Nutanixクラスター Prism
テナントダッシュボード ユーザーインターフェイスおよびAPI X
Admin Dashboard Infra monitoring and ops X X
オブジェクトCRUDおよびライフサイクル管理 X
クォータ リソースコントロールおよび制限 X
ユーザー、グループ およびロール ロールベースのアクセスコントロール(RBAC) X
SSO シングルサインオン X
プラットフォーム連携 OpenStackとNutanixの連携 X
インフラストラクチャー サービス ターゲット インフラストラクチャー(サーバー、ストレージ、ネットワーク) X
OpenStackコンポーネント

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

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

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

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

OpenStack + Nutanix API Communication
OpenStack + Nutanix API の通信

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

Nova

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

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

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

OpenStack Nova Services
OpenStack Novaサービス

Novaスケジューラーは、どの処理ホスト(つまりOVM)が、選択されたアベイラビリティ ゾーンをベースにインスタンスを配置するかを決定します。 該当リクエストは、選択されたOVMに送られ、さらにOVMがターゲットホスト(つまりNutanixクラスター)のAcropolisスケジューラーに同リクエストを転送します。 Acropolisスケジューラーは、クラスター内で最適なノード配置を決定します。OpenStackからクラスター内の各ノードが見えることはありません。

コンピュートおよびハイパーバイザーのホストは、OpenStackポータルの 'Admin'->'System'->'Hypervisors' から確認できます。

以下は、コンピュート ホストとしてのOVMです:

OpenStack Compute Host
OpenStack処理ホスト

以下は、ハイパーバイザー ホストとしてのNutanixクラスターです:

OpenStack Hypervisor Host
OpenStackハイパーバイザーホスト

前のスクリーンショットで分かるように、全てのクラスター リソースは、1つのハイパーバイザーとして見えます。

Swift

オブジェクトストアにあるSwiftは、ファイルの保存と取得に使用されます。 現在のところSwiftは、スナップショットとイメージのバックアップおよびリストアにのみ使用されています。

Cinder

Cinderは、iSCSIターゲットを利用するためのOpenStackボリューム コンポーネントです。 Cinderは、Nutanixソリューション内にあるAcropolis Volumes APIを使用します。 ボリュームは、(ゲストとしてではなく)ブロックデバイスとしてインスタンスに直接接続されています。

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

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

OpenStack Cinder Services
OpenStack Cinderサービス
Glance / イメージ リポジトリ

Glanceは、OpenStackのためのイメージストアであり、プロビジョニングのために利用できるイメージを提示します。 イメージには、ISO、ディスクおよびスナップショットを含めることができます。

イメージ リポジトリは、Glanceが公開した利用可能なイメージの保管場所です。 これらは、Nutanix環境内または外部ソース上に配置することができます。 Nutanixプラットフォームがイメージをホストした場合、イメージ リポジトリは、OVM上のGlance経由でOpenStackコントローラーに公開されます。 イメージ リポジトリが外部ソース上にのみ存在する場合、Glanceは、OpenStackコントローラーによってホストされ、イメージ キャッシュはNutanixクラスター上で使用されます。

Glanceは、クラスター毎に有効化され、常にイメージ リポジトリと共存します。 Glanceが複数のクラスター上で有効化されている場合、イメージ リポジトリも該当するクラスター上に展開され、OpenStack経由で生成されたイメージは、Glanceを稼動させている全てのクラスター上に展開されます。 Glanceをホストしていないクラスターは、イメージ キャッシュを利用して、イメージをローカルにキャッシュします。

Note
プロからのヒント

大規模な導入の場合、各サイトの少なくとも2つのNutanixクラスター上でGlanceを稼動させる必要があります。 これによって、クラスターで障害が発生した場合にイメージ リポジトリの高可用性(HA)を提供し、イメージがイメージ キャッシュに存在しなくても、確実に使用できるようにします。

外部ソースでイメージ リポジトリ / Glanceをホストしている場合、外部ソースからターゲットとするNutanixクラスターへのデータの移動は、Novaが実施します。 この場合、ターゲットとなるNutanixクラスターはイメージ キャッシュを利用し、イメージをローカルにキャッシュして、後続のプロビジョニング リクエストに備えます。

Neutron

Neutronは、OpenStackのネットワーク コンポーネントで、ネットワークの構成(設定)に対して責任を負います。 OVMは、OpenStackポータルによるネットワークCRUD処理を許可し、Acropolisに対する必要な変更を可能とします。

Neutronサービスの詳細については、OpenStackポータルの 'Admin'->'System'->'System Information'->'Network Agents' で確認できます。

以下は、Neutronサービス、ホストおよびステータスを図示したものです:

OpenStack Neutron Services +現在、ローカルおよびVLANネットワークのみサポートされています。
OpenStack Neutronサービス

Neutronは、インスタンスがブートされた際にIPアドレスを割り当てます。 この場合、Acropolisは、割り当てられるVMで必要となるIPアドレスを受け取ります。 VMがDHCPリクエストを発行すると、通常、Acropolisリーダーが、DHCPリクエストに対するレスポンスをAHVのプライベートVXLANに返します。

Note
サポートするネットワークタイプ

現在、ローカル(local)およびVLAN(vlan)ネットワークのみがサポートされています。

KeystoneおよびHorizonコンポーネントは、OVMに対してインターフェイスを持つOpenStackコントローラー内で稼動します。 OVMにはOpenStackドライバーが存在し、OpenStack APIのコールをネイティブなAcropolis APIコールに変換します。

設計と導入

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

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

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

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

OpenStack - Deployment Layout
OpenStack – 導入レイアウト

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

OpenStack - Deployment Layout - Example
OpenStack – 導入レイアウト – 例

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

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

OpenStack Host Aggregates and Availability Zones
OpenStackのホスト アグリゲートとアベイラビリティ ゾーン
サービス設計と拡張

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

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

OpenStack - OVM Load Balancing
OpenStack – OVM ロードバランシング

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

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

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

OpenStack - Multi-Site
OpenStack - 複数サイト
導入

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

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

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

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

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

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

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

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

Note
OVMCTL ヘルプ

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

ovmctl --help

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

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

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

OVM-allinone

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

# Register OpenStack Driver service
ovmctl --add ovm --name <OVM_NAME> --ip <OVM_IP> --netmask <NET_MASK> --gateway <DEFAULT_GW> --domain <DOMAIN> --nameserver <DNS>

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

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

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

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

ovmctl --show

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

OVM-services

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

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

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

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

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

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

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

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

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

ovmctl --show

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

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

# enter keystonerc_admin
source ./keystonerc_admin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さらに、使用しないので、有効化されているlvmバックエンドをコメントアウトします:

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

OpenStackコントローラーのcinder-volumeを無効にします(無効化されていない場合):

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

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

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

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

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

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

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

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

トラブルシューティングと高度な管理
主なログの所在
コンポーネント 主なログの所在
Keystone /var/log/keystone/keystone.log
Horizon /var/log/horizon/horizon.log
Nova /var/log/nova/nova-api.log
/var/log/nova/nova-scheduler.log
/var/log/nova/nove-compute.log*
Swift /var/log/swift/swift.log
Cinder /var/log/cinder/api.log
/var/log/cinder/scheduler.log
/var/log/cinder/volume.log
Glance /var/log/glance/api.log
/var/log/glance/registry.log
Neutron /var/log/neutron/server.log
/var/log/neutron/dhcp-agent.log*
/var/log/neutron/l3-agent.log*
/var/log/neutron/metadata-agent.log*
/var/log/neutron/openvswitch-agent.log*

*が付いたログは、OVM のみが対象です。

Note
プロからのヒント

サービスがOVMで動いているにもかかわらず、OpenStack Manager(Admin UIまたはCLI)でサービスのステータスが「down」になっている場合には、NTPを確認します。 サービスの多くは、OpenStackコントローラーとOVMで同期を取るための時間を必要とします。

コマンド リファレンス

Keystone接続の設定をsourceコマンドでロード(他のコマンドより前に実行)

source keystonerc_admin

Keystoneサービス一覧

keystone service-list

Keystoneエンドポイント一覧

keystone endpoint-list

Keystoneエンドポイントの作成

keystone endpoint-create \
--service-id=<SERVICE_ID> \
--publicurl=http://<IP:PORT> \
--internalurl=http://<IP:PORT> \
--region=<REGION_NAME> \
--adminurl=http://<IP:PORT>

Novaインスタンス一覧

nova list

インスタンスの詳細

nova show <INSTANCE_NAME>

Novaハイパーバイザー ホスト一覧

nova hypervisor-list

ハイパーバイザー ホスト詳細

nova hypervisor-show <HOST_ID>

Glanceイメージ一覧

glance image-list

Glanceイメージ詳細

glance image-show <IMAGE_ID>

後書き

Nutanixバイブルをお読みいただき、ありがとうございました。これからも更新を続けていきますので、どうかお見逃しなく。そして、どうぞNutanixプラットフォームをお楽しみください!