Nutanixバイブル

Steven Poitras 著

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


他言語版はこちらからご覧ください:

序文

Dheeraj Pandey
図1-1. Nutanix CEO、Dheeraj Pandey

「Nutanixバイブル(The Nutanix Bible)」と命名された本書の序文を寄稿できることを大変名誉に思います。 最初に、「バイブル」という本書の名前ですが、神に関心のない方や、無神論者であるため自分には関係ないと思われる方もいらっしゃるかと思います。しかし、辞書「Merriam Webster」によれば、「バイブル」とは、たとえ宗教とは関係のない事柄であっても、聖書のように「高い権威や幅広い読者層を持つ傑出した出版物」という意味を持ちます。この表現によってNutanixバイブルの本質を理解することができます。本書は、Nutanixの中では、常に控えめな立場を取りながら、一方では最高レベルの知識を有する1人で、Nutanix最初のソリューションアーキテクトでもあるSteven Poitrasが最初に執筆を始めたものです。彼は「初期からの社員」という立場に甘んじることなく、この分野の権威であり続けています。彼の知識そのものがNutanixに力を与えているのではなく、自らの知識を共有しようという彼の行動力こそが、Nutanixという会社をより強いものにしています。この分野における彼の高い専門性、Power Shellや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
図 1-2.

Wikibon プリンシパルリサーチコントリビューター、Stuart Miniman

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

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

 

-- Wikibon プリンシパルリサーチコントリビューター、Stuart Miniman

はじめに

Steven Poitras
図 1-3.Nutanix プリンシパルソリューションアーキテクト、Steven Poitras

Nutanixバイブルにようこそ!私は毎日のようにNutanixプラットフォームに関わり、私自身の製品ベンチマークラボで、問題の発見や限界性能の試験を実施しています。本書では、私やNutanixの様々なエンジニアが日々利用しているヒントや技の概要を紹介し、随時内容を更新していきます。

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

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

 

-- Nutanix プリンシパルソリューションアーキテクト、Steven Poitras

パート I. これまでの歴史を振り返る

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

データセンターの進化

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

メインフレーム時代

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

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

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

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

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

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

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

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

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

集中型ストレージ

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

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

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

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

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

仮想化の登場

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

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

仮想化の問題点:

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

仮想化の成熟

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

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

問題点:

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

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

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

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

SSDの問題点:

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

レイテンシの重要性

以下の表に、各I/Oタイプ別のレイテンシを示します:

I/Oタイプ レイテンシ 補足
L1キャッシュ参照 0.5 ns
分岐予測失敗 (Branch Mispredict) 5 ns
L2キャッシュ参照 7 ns 14x L1 cache
相互排他 (Mutex) ロック/アンロック 25 ns
メインメモリ参照 100 ns L2キャッシュx 20、L1キャッシュx 200
Zippyを使った1KBの圧縮 3,000 ns
1Gbsネットワークで1KBを転送 10,000 ns 0.01 ms
SSDから4Kをランダム Read 150,000 ns 0.15 ms
メモリから1MBシーケンシャルRead 250,000 ns 0.25 ms
データセンター内のラウンドトリップ 500,000 ns 0.5 ms
SSDから1MBシーケンシャルRead 1,000,000 ns 1 ms, 4x memory
ディスクシーク 10,000,000 ns 10ms、データセンターラウンドトリップ x 20
ディスクから1MBシーケンシャルRead 20,000,000 ns 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)で実施されることが分かります。メインメモリに対するアクセスは ~100nsで、ローカルのSSDに対する4KのReadは、~150,000ns、つまり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 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%にも達することでしょう。

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

Webスケール

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

本セクションでは、「Webスケール」インフラストラクチャーの核となる概念と、なぜそれを採用するのかについて説明します。始める前に、Webスケールだからといって、GoogleやFacebook、Microsoftのような「超大規模なスケール」になる必要はないということを明言しておきます。Webスケールな構成はどんな規模(3ノードでも、数千ノードでも)でも可能であり、その恩恵を受けることができます。

これまでの課題は:

  • とにかく複雑
  • インクリメンタル(漸増的)な拡張が求められる
  • アジャイルでなければならない

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

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

その他の要素:

  • APIベースの自動化と豊富な分析機能
  • 自己修復機能

以下のセクションでは、これらの技術的な意味を説明します。

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

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

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

メリットとしては:

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

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

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

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

メリットとしては:

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

自律分散システム

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

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

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

メリットとしては:

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

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

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

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

つまり:

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

メリットとしては:

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

ここまでの理解

まとめ:

  1. サーバーの非効率的な利用状況が仮想化の利用を促進
  2. vMotionやHA、DRSといった機能に対応できるよう集中型のストレージが出現
  3. VMの乱造がストレージの負荷や競合を増長
  4. SSDが問題を緩和したが、ボトルネック自体はネットワークやコントローラに移動
  5. ネットワーク経由のキャッシュやメモリアクセスには大きなオーバーヘッドが発生し、メリットはほとんどない
  6. アレイ構成の複雑さは以前のまま
  7. サーバーのキャッシュが、アレイの負荷やネットワークへの影響を軽減したが、ソリューション実現には、新たに別のコンポーネントが必要となる
  8. 処理をローカルで完結させることで、従来ネットワーク経由で発生していたボトルネックやオーバーヘッドを軽減
  9. 焦点をインフラストラクチャーから、容易な管理とシンプルなスタックを実現することに移す
  10. そして、Webスケールな世界が誕生!

パート II. 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は分散リソース管理プラットフォームです。ユーザーはPrismを使って、Nutanix環境全体のオブジェクトやサービスを管理およびモニターすることができます。

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

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

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

High-Level Prism Architecture
図5-1.Prismアーキテクチャー概観

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

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

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

Prism Architecture
図5-2.Prismアーキテクチャー
Note
プロからのヒント

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

Prismのサービス

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

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

Prism Services - Request Handling
図5-3.Prismサービス - リクエスト処理
Note

Prismのポート

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

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

Note
プロからのヒント

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

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

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

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

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

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

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

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

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

Upgrade Software - Main
図7-2. ソフトウェアアップのグレード - メイン

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Note
プロからのヒント

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

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

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

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

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

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

Add Node - Discovery
図7-14. ノードの追加 ‐ 検知

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

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

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

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

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

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

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

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

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

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

Expand Cluster - Execution
図7-19. クラスタの拡張 ‐ 実行

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

Expand Cluster - Execution
図7-20. クラスタの拡張 – 実行

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

Expand Cluster - Execution
図7-21. クラスタの拡張 – 実行

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

Expand Cluster - Execution
図7-22. クラスタの拡張 – 実行

キャパシティプラニング

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

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

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

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

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

以下のセクションでは、インターフェースと使用例について説明します。

APIとインターフェース

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

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

インターフェースで中心となるのが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
図8-1. Prism REST APIエクスプローラ

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

Prism REST API Sample Call
図8-2. Prism REST APIのコール例
Note
API認証スキーム

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

ACLI

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

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

ACLIシェルの起動

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

Acli

または

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

ACLI <Command>

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

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

Acli –o json

ホスト一覧

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

host.list

ネットワークの作成

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

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

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

ネットワーク一覧

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

net.list

DHCPスコープの作成

説明: DHCPスコープの作成

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

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

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

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

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

net.get <NET NAME>

Example: net.get vlan.133

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

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

net.list_vms <NET NAME>

Example: net.list_vms vlan.133

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

説明: DHCP DNSの設定

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

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

仮想マシンの作成

説明: VMの作成

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

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

複数の仮想マシンを作成

説明: 複数VMの作成

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

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

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

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

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

Example: vm.clone testClone clone_from_vm=MYBASEVM

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

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

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

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

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

# Description: Create disk for OS

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

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

VMにNICを追加

説明: NICを作成して追加

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

Example: vm.nic_create testVM network=vlan.100

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

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

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

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

Example: vm.update_boot_device testVM disk_addr=scsi.0

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

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

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

Example: vm.update_boot_device testVM disk_addr=ide.0

CD-ROMにISOをマウント

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

手順:

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

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

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

ISOでCD-ROMを作成

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

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

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

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

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

CD-ROMからISOをデタッチ

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

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

VMの起動

説明: VMを起動する

vm.on <VM NAME(S)>

Example: vm.on testVM

全てのVMを起動

Example: vm.on *

一定範囲のVMを起動

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

NCLI

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

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

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

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

Nutanixのバージョンを表示

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

ncli cluster version

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

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

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

ストレージプール一覧

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

ncli sp ls

コンテナ一覧

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

ncli ctr ls

コンテナの作成

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

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

VM一覧

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

ncli vm ls

パブリックキー一覧

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

ncli cluster list-public-keys

パブリックキーの追加

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

パブリックキーをCVMにSCP

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

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

パブリックキーの削除

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

ncli cluster remove-public-keys name=myPK

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

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

ncli pd create name=<NAME>

リモートサイトの作成

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

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

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

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

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

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

説明: 指定したVMを保護

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

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

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

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

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

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

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

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

説明: 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>

PowerShell コマンドレット

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

基本

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

コマンドレット

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

パイプライン

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

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

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

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

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

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

変数 (Variable)

$myVariable = "foo"

注意: バリアブル(変数)は、一連のコマンドまたはパイプラインのアウトプットとしても設定できます。

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

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

配列 (Array)

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

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

ハッシュテーブル

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

便利なコマンド

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

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

Example: Get-Help Get-Process

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

<Some expression or object> | Get-Member

Example: $someObject | Get-Member

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

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

Prism コマンドレット Installer Link
Figure 8-3. Prism コマンドレット Installer Link
Nutanix Snappinのロード

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

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

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

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

Acropolisクラスタに接続

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

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

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

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

変数に対して出力

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

インタラクティブ

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

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

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

Nutanix vDisk一覧

変数に対して出力

$vdisks = Get-NTNXVDisk

インタラクティブ

Get-NTNXVDisk

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

Get-NTNXVDisk | ft

Nutanixコンテナ一覧

変数に対して出力

$containers = Get-NTNXContainer

インタラクティブ

Get-NTNXContainer

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

Get-NTNXContainer | ft

変数に対して出力

$pds = Get-NTNXProtectionDomain

インタラクティブ

Get-NTNXProtectionDomain

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

Get-NTNXProtectionDomain | ft

Nutanixコンシステンシーグループ一覧

変数に対して出力

$cgs = Get-NTNXProtectionDomainConsistencyGroup

インタラクティブ

Get-NTNXProtectionDomainConsistencyGroup

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

Get-NTNXProtectionDomainConsistencyGroup | ft

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

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

統合

OpenStack

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

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

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

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

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

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

OpenStack + Acropolis OpenStack Driver
図9-1. OpenStack + Acropolis OpenStackドライバー
サポート対象となるOpenStackコントローラ

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

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

項目 役割 OpenStackコントローラ Acropolis OVM Acropolisクラスタ 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コントローラがホストしているものや、Acropolis OVMがホストしているものがあります。

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

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

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

OpenStack + Nutanix API Communication
図9-2. OpenStack + Nutanix API の通信

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

Nova

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

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

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

OpenStack Nova Services

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

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

以下に、処理ホストとしてのAcropolis OVMを図示します:

OpenStack Compute Host
図9-4. OpenStack処理ホスト

以下に、ハイパーバイザーホストとしてのAcropolisクラスタを図示します:

OpenStack Hypervisor Host
図9-5. OpenStackハイパーバイザーホスト

前の図で分かる通り、1つのハイパーバイザーホスト内で全てのクラスタリソースを確認することができます。

Swift

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

Cinder

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

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

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

OpenStack Cinder Services
図9-6. OpenStack Cinderサービス
Glance / Image Repo

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

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

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

Note
プロからのヒント

大規模な導入の場合、各サイトの少なくとも2つのAcropolisクラスタ上でGlanceを稼動させる必要があります。これによって、クラスタで障害が発生した場合にImage Repo HAを提供し、イメージがImage Cache内に存在しなくても、確実に使用できるようにします。

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

Neutron

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

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

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

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

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

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

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

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

設計と導入

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

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

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

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

OpenStack - Deployment Layout
図9-8. OpenStack – 導入レイアウト

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

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

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

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

OpenStack Host Aggregates and Availability Zones
図9-10. OpenStackホスト統合とアベイラビリティゾーン

サービス設計と拡張

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

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

OpenStack - OVM Load Balancing
図9-11. OpenStack – OVM ロードバランシング

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

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

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

OpenStack - Multi-Site
図9-12. OpenStack - 複数サイト

導入

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

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

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

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

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

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

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

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

Note
OVMCTL ヘルプ

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

ovmctl --help

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

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

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

OVM-allinone

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

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

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

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

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

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

ovmctl --show

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

OVM-services

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

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

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

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

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

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

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

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

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

ovmctl --show

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

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

# enter keystonerc_admin source ./keystonerc_admin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主なログの所在
コンポーネント 主なログの所在
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*

*が付いたログは、Acropolis OVM のみが対象

Note
プロからのヒント

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

コマンド リファレンス

Keystoneソースのロード(他のコマンドより前に実行)

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>

パートIII. Acropolis

acropolis₋ 名詞 – データプレーン
ストレージ、サーバー、仮想化プラットフォーム

アーキテクチャー

Acropolisは、分散マルチリソース マネージャー、オーケストレーション プラットフォーム、そしてデータ プレーンです。

Acropolisは、以下3つの主要コンポーネントに分けられます:

  • 分散ストレージ ファブリック(DSF)
    • DSFは、Nutanixプラットフォームの核および源とも言えるコンポーネントであり、Nutanix分散ファイルシステム (NDFS) をさらに拡張するものです。今やNDFSは、単なるストレージ リソースをプールする分散システムから、より大規模かつ優れたストレージ プラットフォームへと進化しました。
  • アプリケーション モビリティ ファブリック (AMF)
    • ハイパーバイザーは、OSをハードウェアから分離して抽象化しますが、AFMは、ワークロード(VM、ストレージ、コンテナなど)をハイパーバイザーから分離して抽象化します。これにより、ワークロードをハイパーバイザー間やクラウド間で動的に移行させることができるようになり、Nutanixノードでハイパーバイザーを入れ換えることも可能になります。
  • ハイパーバイザー
    • CentOS KVMハイパーバイザーをベースとする多目的ハイパーバイザー

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

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

以下は、Acropolisの各レイヤの概念を図示したものです:

High-level Acropolis Architecture
図10-1. Acropolisアーキテクチャー概観
Note
VM管理の対象となるハイパーバイザー

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

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

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

 

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

それぞれのノードで、業界の標準的なハイパーバイザー(現在は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
図10-3. コンバージド プラットフォーム

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

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

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

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

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

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

クラスタ コンポーネント

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

 

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

Nutanix Cluster Components
図10-5. Nutanixクラスタコンポーネント
Cassandra
  • 主な役割: 分散メタデータ ストア
  • 説明: Cassandraは、Apache Cassandraを大幅に改修した分散リング上に全てのクラスタ メタデータをストアして管理を行います。一貫性を厳格に保つため、Paxosアルゴリズムが使用されています。そして本サービスは、クラスタ内の全てのノードで稼動します。Cassandraは、Medusaと呼ばれるインターフェースを介してアクセスされます。 
Zookeeper
  • 主な役割: クラスタ構成マネージャー
  • 説明: Apache ZookeeperをベースにしたZookeeperは、ホスト、IP、状態など全てのクラスタ構成をストアします。本サービスは、クラスタ内の3つのノードで稼動し、その内の1つがリーダーとして選出されます。リーダーが全てのリクエストを受信し残りのサービスに転送します。リーダーからのレスポンスが無い場合、新しいリーダーが自動的に選択されます。Zookeeperは、Zeusと呼ばれるインターフェースを介してアクセスされます。
Stargate
  • 主な役割: データI/Oマネージャー
  • 説明: Stargateは、全てのデータ管理とI/O処理に対応し、ハイパーバイザーからの主なインターフェース(NFS、iSCSIまたはSMB経由)となります。該当サービスはクラスタ内の全てのノードで稼動し、ローカルI/Oを処理します。
Curator
  • 主な役割: MapReduceクラスタの管理とクリーンアップ
  • 説明: Curatorは、クラスタ全体のディスクのバランシング、事前スクラブといった多くのタスクの管理と分散を行います。Curatorは全てのノードで稼動し、タスクとジョブの委任を行う選択されたCuratorマスターによってコントロールされます。Curatorには、6時間毎に行うフルスキャンと、1時間毎に行う部分スキャンという2つのスキャンタイプがあります。
Prism
  • 主な役割: UIおよびAPI
  • 説明: Prismは、コンポーネントやアドミニストレータが、Nutanixクラスタを構成およびモニターするための管理ゲートウェイとしての役割を果たします。これにはHTML5 UI, Ncli, REST APIが含まれます。Prismは、全てのノードで稼動し、クラスタ内の全てのコンポ―ネントと同様に選出されたリーダーを使用します。
Genesis
  • 主な役割: クラスタのコンポーネントおよびサービス マネージャー
Chronos
  • 主な役割: ジョブとタスクのスケジューラ
  • 説明: Chronosは、Curatorスキャンされたジョブやタスクをノード間で実行するためのスケジューリングや調整を行います。Chronosは、全てのノードで稼動し、選出されたChronosマスターによってコントロールされます。Chronosマスターはタスクやジョブを委任し、Curatorマスターと同じノード上で稼働します。
Cerebro
  • 主な役割: レプリケーション/DRマネージャー
  • 説明: Cerebroは、DSFのレプリケーションとDR機能を担っています。これには、スナップショットのスケジューリング、リモートサイトへのレプリケーション、サイトの移行、そしてフェールオーバー機能が含まれています。CerebroはNutanixクラスタ内の全てのノードとリモート クラスタ/サイトへのレプリケーションに加わる全てのノードで稼動します。
Pithos
  • 主な役割: vDisk構成マネージャー
  • 説明: Pithosは、vDisk(DSFファイル)の構成データを担っています。Pithosは全てのノードで稼動し、Cassandraの上に構築されます。

Acropolisサービス

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

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

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

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

Acropolis Services
図10-2. Acropolisサービス

ドライブの構成

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

SSDデバイス

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

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

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

SSD Drive Breakdown
図10-6. SSDドライブの構成

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

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

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

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

  • Curator予約領域(Curatorストレージ)
  • エクステント ストア(永続的なストレージ)
HDD Drive Breakdown
図10-7. HDDドライブ構成

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

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

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

以下は、NutanixノードがDSFを形成する例を図示したものです:

Distributed Storage Fabric Overview
図11-1. 分散ストレージ ファブリック概要

データ ストラクチャ

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

ストレージ プール
  • 主な役割: 物理デバイスのグループ
  • 説明: ストレージ プールは、クラスタのPCIe SSD、SSD、HDDデバイスを含む物理ストレージ デバイスのグループです。ストレージ プールは、複数のNutanixノードにまたがることができ、クラスタの拡大に合わせ拡張することができます。ほとんどの構成で単一のストレージ プールが使用されます。
コンテナ
  • 主な役割: VM/ファイルの集合
  • 説明: コンテナは、ストレージ プールの論理的なセグメントであり、VMまたはファイル (vDisk) のグループを含みます。コンテナ レベルで複数の構成オプション(例えばRF)の利用が可能ですが、その適用は個別のVM/ファイル レベルになります。通常コンテナは、データストアと1対1の関係になります(NFS/SMBの場合)。
vDisk
  • 主な役割: vDisk
  • 説明: vDiskは、DSF上の512KB以上のファイルでvmdksおよびVMハードディスクを含みます。vDiskは、エクステント グループとしてディスク上でグループ化されストアされたエクステントで構成されます。

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

High-level Filesystem Breakdown
図11-2. ファイルシステム構成概観
エクステント
  • 主な役割: 論理的に連続したデータ
  • 説明: エクステントは、論理的に連続した1MBのデータであり、n個(ゲストOSのブロックサイズに依存)の連続ブロックで構成されます。細かな操作と効率を向上するため、エクステントは、サブエクステント(またはスライス)単位でWRITE/READ/MODIFYが可能です。エクステントのスライスは、READまたはキャッシュされるデータ量に応じて、キャッシュに移される際にトリムされる場合があります。
エクステント グループ
  • 主な役割: 物理的に連続したストアド データ
  • 説明: エクステント グループは、1MBまたは4MBの物理的に連続したストアド データです。データは、CVMがオーナーであるストレージ デバイス上のファイルとしてストアされます。エクステントは、パフォーマンス向上のため、ノード/ディスク間でストライピングされるよう、動的にエクステント グループに分散されます。注意:4.0の場合、データ重複排除機能に応じて、エクステント グループを1MBまたは4MBに設定できます。

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

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

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

Graphical Filesystem Breakdown
図11-4. ファイルシステムの構成図

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

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

 

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

DSF I/O Path
図11-5. DSF I/Oパス
OpLog
  • 主な役割: 永続的なWRITEバッファ
  •  説明: OpLogは、ファイルシステムジャーナルのような機能を持ち、大量のランダムWRITEを処理し、融合して(coalesce)、順次データをエクステントストアに送ります。WRITE処理の場合、可用性を高める目的で、データの書き込みが完了する前にOpLogは異なるn個のCVMのOpLogに同期的にレプリケートされます。全てのCVM OpLogが、レプリケーションを受ける対象となり、ロードに応じて動的に選択されます。OpLogは、CVMのSSDレイヤにストアされ、WRITE I/O、特にRANDOM I/Oワークロードに対して非常に優れたパフォーマンスを発揮します。シーケンシャルなワークロードの場合、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のための永続的なバルクストレージとしてSSDとHDD上に存在し、デバイスやレイヤを追加拡張することが可能です。エクステントストアに入っているデータは、A) OpLogから投入されたもの、または、B) シーケンシャル処理によりOpLogを経由せずに直接投入されたもののいずれかです。Nutanix ILMは、I/Oパターンに応じて動的に配置するレイヤを決定し、データをレイヤ間で移動させます。
Note
Sequential Write Characterization

Write IO is deemed as sequential when there is more than 1.5MB of outstanding write IO to a vDisk (as of 4.6). IOs meeting this will bypass the OpLog and go directly to the Extent Store since they are already large chunks of aligned data and won't benefit from coalescing.

This is controlled by the following Gflag: vdisk_distributed_oplog_skip_min_outstanding_write_bytes.

All other IOs, including those which can be large (e.g. >64K) will still be handled by the OpLog.

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

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

DSF Unified Cache
図11-6. DSF統合キャッシュ
Note
キャッシュの粒度とロジック

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

Each CVM has its own local cache that it manages for the vDisk(s) it is hosting (e.g. VM(s) running on the same node). When a vDisk is cloned (e.g. new clones, snapshots, etc.) each new vDisk has it's own block map and the orignial vDisk is marked as immutable. This allows us to ensure that each CVM can have it's own cached copy of the base vDisk with cache coherency.

In the event of an overwrite, that will be re-directed to a new extent in the VM's own block map. This ensures that there will not be any cache corruption.

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

拡張可能メタデータ

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

 

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

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

図11-7. Cassandra リング構造

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

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

図11-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つのノードが必要となります。

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

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

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

DSF Data Protection
図11-8. DSF データ保護

可用性ドメイン

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

 

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

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

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

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

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

Block Aware Replica Placement
図11-25. ブロック・アウェア レプリカの配置方法

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

Block Failure Replica Placement
図11-26. ブロック障害時のレプリカの配置方法
アウェアネスの条件とトレランス

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

同時障害に対するトレランス
ブロック数 アウェアネスタイプ クラスタ FT1 クラスタ FT2
<3 ノード シングルノード デュアルノード
3-5 ノード+ブロック シングルノード
(最大4ノード)
シングルブロック
(最大4ノード)
5+ ノード+ブロック シングルブロック
(最大4ノード)
デュアルブロック
(最大8ノード)

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

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

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

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

  • 例えば、RF2の場合は33%、RF3の場合は25%となります
メタデータ

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

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

12 Node Cassandra Ring
図12-27. 12ノードCassandraリング

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

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

Cassandra Node Block Aware Placement
図11-18. Cassandra ノードブロック・アウェアな配置

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

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

Full Cassandra Node Block Aware Placement
図11-29. 完全な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 Aware Placement
図11-30. Zookeeperのブロック・アウェアな配置

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

Zookeeper Placement Block Failure
図11-31. Zookeeperのブロック障害時の配置

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

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

データパスの回復性能

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

 

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

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

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

想定される障害レベル

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

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

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

VMの影響:

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

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

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

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

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

CVMの「障害」

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

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

VMの影響:

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

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

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

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

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

ノード障害

VMの影響:

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

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

また同様に、データ保護機能の再生措置がノード全体(関連する全てのディスク)で実施されます。

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

キャパシティの最適化

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

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

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

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

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

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

消失訂正符号 (Erasure Coding)

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

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

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

Note
プロからのヒント

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

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

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

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

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

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

Typical DSF RF Data Layout
図11-10. 典型的なDSF RFデータのレイアウト

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

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

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

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

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

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

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

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

圧縮

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

 

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

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

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

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

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

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

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

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

Offline Compression I/O Path
図11-14. ポストプロセス圧縮I/Oパス

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

Decompression I/O Path
図11-15. 解凍処理I/Oパス
Dashoboard ページ で確認することができます。

Elastic Dedupe Engine(弾力的重複排除エンジン)

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

 

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

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

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

Note
プロからのヒント

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

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

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

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

Elastic Dedupe Engine - Scale
図11-16. Elastic Dedupe Engine – 拡張

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

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

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

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

EDE I/O Path
図11-17. EDE I/Oパス

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

Note
重複排除 + 圧縮

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

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

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

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

DSF Tier Prioritization
図11-18. DSF階層の優先順位付け

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

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

DSF Cluster-wide Tiering
図11-19. DSF クラスタ全体の階層化

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

DSF Cluster-wide Tier Balancing
図11-20. 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
図11-21. DSF 階層ILM

DSF ILMは、I/Oのパターンを定常的にモニターし、必要に応じてデータを上層または下層に移動すると共に、その階層に関係なく、ホットなデータをローカルに移動させます。

ディスクバランシング

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

 

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

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

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

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

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

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

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

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

Disk Balancing - Storage Only Node
図11-24. ディスクバランシング – ストレージオンリーなノード

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

ビデオによる解説はこちらからご覧いただけます: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
図11-32. スナップショットブロックマップの例

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

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

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

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

Multi-Clone Block Maps
図11-34. マルチ・クローンのブロックマップ

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

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

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

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

レプリケーションとDR

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

 

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

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

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

Example Replication Topologies
図11-36. レプリケーショントポロジーの例

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

導入構成

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

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

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

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

希望するRPOやRTOに合わせた様々なサービスレベルを実現するため、複数のPDを作成します。ファイルの配布(例えばゴールデンイメージやISOなど)に向け、ファイルをレプリケーションするPDを生成することができます。

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

依存性のあるアプリケーションやVMをコンシステンシーグループでグループ化することで、互いの整合性が取れた状態でリカバリされるようにします(例えばアプリやDB)。

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

スナップショットのスケジュールは希望するRPOと同じである必要があります

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

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

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

DR Construct Mapping
図11-37. DR構成マッピング

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

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

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

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

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

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

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

Replication Architecture
図11-38. レプリケーションアーキテクチャー

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

Note
プロからのヒント

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

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

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

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

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

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

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

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

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

Replication Deduplication
図11-41.レプリケーションの重複排除
Note
注意

レプリケーションの重複排除を可能にするためには、ソースおよびターゲットとなるコンテナおよびvstoreで、フィンガープリントが有効化されている必要があります。

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
図11-42. Cloud Connect リージョン

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

Cloud Connect - Multi-region
図11-43. Cloud Connect マルチリージョン

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

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

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

Cloud Connect - Restore
図11-44. Cloud Connect – リストア

Metro Availability

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

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

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

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

Metro Availability - Normal State
図11-45. Metro Availability – 通常の状態

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

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

Metro Availability - Site Failure
図11-46. Metro Availability – サイト障害発生時

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

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

Metro Availability - Link Failure
図11-47. Metro Availability - リンク障害

Volumes API

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

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

Volumes APIの主な使用目的:

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

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

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

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

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

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

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

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

Volume API - Example
図11-48. Volume API – 例

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

MPIO Example - Normal State
Figure 11-49. MPIO Example - Normal State

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

MPIO Example - Multi-disk
図11-49. MPIOの例 – 通常の状態

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

MPIO Example - Path Failure
図11-50. MPIOの例 – マルチディスク

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

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

RAID / LVM Example - Single-path
図11-52. RAID / LVM の例 - シングルパス

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

RAID / LVM Example - Multi-path
図11-53. RAID / VLM の例 – マルチパス

ネットワークとI/O

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

 

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

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

DSF Networking
図11-54. DSF ネットワーク

 

データローカリティ

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

 

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

Data locality occurs in two main flavors:

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

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

Data Locality
図11-55. データローカリティ
Note
データ移行のスレッシュホールド(しきい値)

Cache locality occurs in real time and will be determined based upon vDisk ownership. When a vDisk / VM moves from one node to another the "ownership" of those vDisk(s) will transfer to the now local CVM. Once the ownership has transferred the data can be cached locally in the Unified Cache. In the interim the cache will be wherever the ownership is held (the now remote host). The previously hosting Stargate will relinquish the vDisk token when it sees remote I/Os for 300+ seconds at which it will then be taken by the local Stargate. Cache coherence is enforced as ownership is required to cache the vDisk data.

Extent locality is a sampled operation and an extent group will be migrated when the following occurs: "3 touches for random or 10 touches for sequential within a 10 minute window where multiple reads every 10 second sampling count as a single touch".

シャドウクローン

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

 

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

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

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

Shadow Clones
図11-56. シャドウクローン

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

Nutanixプラットフォームは、VM/ゲストOSから物理ディスクデバイスに至るまで、スタックの複数のレイヤにおいて、ストレージをモニターしています。様々な階層とその関係を理解することが、ソリューションのモニタリングにおいて重要となり、操作の関連性を明確にすることにつながります。以下は、操作をモニターしている各レイヤとその粒度について図示したものです:

Storage Layers
図11-57. ストレージレイヤ

 

仮想マシンレイヤ
  • 主要な役割: ハイパーバイザーが提供する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処理の数と一致します。
  • 使用場面:キャッシュやディスクが提供した処理数を確認する場合に使用します
Note
指標とステータスの保存

指標と時系列データは、Prism Elementに90日間ローカルで保存されます。Prism CentralやInsightsでは、データを(キャパシティが許す限り)永久に保存します。

アプリケーション・モビリティファブリック – まもなく公開!

近日公開!

Acropolis Hypervisor (AHV)

ノードアーキテクチャー

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

Acropolis Hypervisor Node
図13-1. Acropolice Hypervisorノード

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

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

KVMのアーキテクチャー

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

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

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

KVM Component Relationship
図13-2. KVMコンポーネントの関係

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

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

VMを異なるプロセッサ世代間で移動できるVMwareのEnhanced vMotion Capability (EVC) と同様、Acropolice Hypervisorでは、クラスタ内の最も古いプロセッサの世代を特定し、全てのQEMUドメインをそのレベルで制約します。これによって、AHVクラスタ内に、異なる世代のプロセッサが混在している場合でも、ホスト間のライブマイグレーションが可能になります。

最大構成と拡張性

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

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

ネットワーク

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

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

Open vSwitch Network Overview
図13-3. Open vSwitchネットワーク概要

VM NIC Types

AHV supports the following interface types:

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

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

A trunked interface can be added with the following command:

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

Example:

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

動作の仕組み

iSCSIマルチパス

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

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

iSCSI Multi-pathing - Normal State
図13-4. iSCSIマルチパス - 通常状態

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

iSCSI Multi-pathing - Local CVM Down
図15-3. iSCSIマルチパス – ローカルCVMが停止した場合

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

iSCSI Multi-pathing - Local CVM Back Up
図13-6. iSCSIマルチパス – ローカルCVMが復旧した場合

IPアドレスの管理

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

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

IPAM - Local Acropolis Master
図13-7 IPAM – ローカルAcropolisマスター

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

IPAM - Remote Acropolis Master
図13-8. IPAM - リモートAcropolisマスター

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

VMの高可用性 (HA)

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

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

HA - Host Monitoring
図13-9. HA - ホストのモニタリング

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

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

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

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

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

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

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

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

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

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

ホスト予約

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

Note
プロからのヒント

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

acli ha.update num_reserved_hosts=<NUM_RESERVED>

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

HA - Reserved Host
図13-10. HA - 予約ホスト

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

HA - Reserved Host - Fail Over
図13-11. HA - 予約ホスト – フェールオーバー

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

HA - Reserved Host - Fail Back
図13-12. HA – 予約ホスト - フェールバック
セグメント予約

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

Note
プロからのヒント

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

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

HA - Reserved Segment
図13-13. HA – 予約セグメント

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

HA - Reserved Segment - Fail Over
図13-14. HA - 予約セグメント – フェールオーバー
Note
予約セグメントの計算

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

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

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

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

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

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

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

アドミニストレーション

近日公開!

重要なページ

近日公開!

コマンドリファレンス

OVSのみに対して10GbEリンクを有効化する

説明: ローカルホストのbond0に対してのみ10gを有効化する

manage_ovs --interfaces 10g update_uplinks

説明: クラスタ全体のovsアップリンクを表示

allssh "manage_ovs --interfaces 10g update_uplinks"

OVSアップリンクの表示

説明: ローカルホストに対するovsアップリンクを表示

manage_ovs show_uplinks

説明: クラスタ全体のovsアップリンクを表示

allssh "manage_ovs show_uplinks"

OVSインターフェースの表示

説明: ローカルホストのovsインターフェースを表示

manage_ovs show_interfaces

クラスタ全体のインターフェースを表示

allssh "manage_ovs show_interfaces"

OVSスイッチ情報を表示

説明:スイッチ情報を表示

ovs-vsctl show

OVSブリッジ一覧

説明: ブリッジ一覧を表示

ovs-vsctl list br

OVSブリッジ情報の表示

説明: OVSポート情報を表示

ovs-vsctl list port br0
ovs-vsctl list port <bond>

OVSインターフェース情報の表示

説明: インターフェース情報を表示

ovs-vsctl list interface br0

ブリッジのポート/インターフェースを表示

説明: ブリッジのポートを表示

ovs-vsctl list-ports br0

説明:ブリッジのインターフェースを表示

ovs-vsctl list-ifaces br0

OVSブリッジの作成

説明: ブリッジの作成

ovs-vsctl add-br <bridge>

ブリッジにポートを追加

説明: ブリッジにポートを追加

ovs-vsctl add-port <bridge> <port>

説明: ブリッジにボンドポートを追加

ovs-vsctl add-bond <bridge> <port> <iface>

OVSのボンド詳細を表示

説明: ボンド詳細を表示

ovs-appctl bond/show <bond>

例:

ovs-appctl bond/show bond0

ボンドモードを設定しボンドにLACPを構成

説明: ポートのLACPを有効化

ovs-vsctl set port <bond> lacp=<active/passive>

説明: 全ホストのbond0を有効化

for i in `hostips`;do echo $i; ssh $i source /etc/profile > /dev/null 2>&1; ovs-vsctl set port bond0 lacp=active;done

ボンドのLACP詳細を表示

説明: LACPの詳細を表示

ovs-appctl lacp/show <bond>

ボンドモードを設定

説明: ポートにボンドモードを設定

ovs-vsctl set port <bond> bond_mode=<active-backup, balance-slb, balance-tcp>

Show OpenFlow情報を表示

説明: OVS openflowの詳細を表示

ovs-ofctl show br0

説明: OpenFlowのルールを表示

ovs-ofctl dump-flows br0

QEMU PIDと上位情報を取得

説明: QEMU PIDを取得

ps aux | grep qemu | awk '{print $2}'

説明:指定したPIDの上位指標値を取得

top -p <PID>

QEMUプロセスに対してアクティブなStargateを取得

説明: 各QEMUプロセスのストレージI/Oに対するアクティブなStargateを獲得

netstat –np | egrep tcp.*qemu

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

近日公開!

トラブル対応と高度なアドミニストレーション

iSCSIリダイレクタログの確認

説明: 全ホストのiSCSIリダイレクタログを確認

for i in `hostips`; do echo $i; ssh root@$i cat /var/log/iscsi_redirector;done

単独ホストの場合

Ssh root@<HOST IP>
Cat /var/log/iscsi_redirector

Stolen (Steal) CPUのモニター

説明: CPUのSteal時間(Stolen CPU)をモニター

topを起動し %st(以下ではボールド表示)を探す

Cpu(s):  0.0%us, 0.0%sy,  0.0%ni, 96.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st

VMネットワークリソースのステータスをモニター

説明: VMリソースのステータスをモニター

virt-topを起動

Virt-top

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

2 – ネットワーク

アドミニストレーション

重要なページ

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

2009 ページ

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

2009/latency ページ

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

2009/vdisk_stats ページ

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

2009/h/traces ページ

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

2009/h/vars ページ

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

2010 ページ

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

2010/master/control ページ

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

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

 プロテクションドメイン、レプリケーションのステータス、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

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

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

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

パッケージを untar する

tar xzvf ~/tmp/nutanix*

アップグレードの実行

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

ステータスを確認

upgrade_status

ノードアップグレード

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

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

cluster -u <NODE_IP(s)> upgrade_node

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

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

host_upgrade --status

詳細ログ(各CVM上)

~/data/logs/host_upgrade.out

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

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

サービスを停止

cluster stop <Service Name>

停止したサービスを起動

cluster start  #NOTE: This will start all stopped services

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

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

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

vDiskの数を調査

Description: 説明: vDiskの数を表示

vdisk_config_printer | grep vdisk_id | wc -l

クラスタ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の数を調査

説明: DSF上のvDisk(ファイル)の数を調査

vdisk_config_printer | grep vdisk_id | wc -l

CLIからCuratorスキャンを起動

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

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

リングを圧縮

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

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

全てのクラスタノードに対し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

List tasks using progress monitor cli

progress_monitor_cli -fetchall

Remove task using progress monitor cli

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

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

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

Gflags

近日公開!

トラブルシューティングと高度なアドミニストレーション

Acropolisのログを調査

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

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

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

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

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

Stargateの例

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

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

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

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

Stargateの例

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

2009ページの利用 (Stargate)

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

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

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

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

2009 Page - Stargate Overview
図14-1. 2009ページ – Stargate概要

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

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

2009 Page - Stargate Overview - Queues
図14-2. 2009ページ – Stargate概要 – Queue

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

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

2009 Page - Stargate Overview - Unified Cache
図14-3. 2009ページ – Stargate概要 - コンテンツキャッシュ
Note
プロからのヒント

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

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

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

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

2009 Page - Cluster State - Disk Usage
図14-4. 2009ページ – クラスタステータス - ディスク使用状況

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

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

2009 Page - NFS Slave - vDisk Stats
図14-5. 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
図14-6. 2009ページ – ホステッドvDisk

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

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

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

2009 Page - vDisk Stats - Ops and Randomness
図14-7. 2009ページ – vDiskステータス - オペレーションとランダムネス

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

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

2009 Page - vDisk Stats - Frontend Read Latency
図14-8. 2009ページ - vDiskステータス - フロントエンドREADレイテンシ

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

2009 Page - vDisk Stats - Frontend Write Latency
図14-9. 2009ページ - vDiskステータス - フロントエンドWRITEレイテンシ

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

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

2009 Page - vDisk Stats - Read I/O Size
図14-10. 2009ページ - vDiskステータス – READ I/Oサイズ

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

2009 Page - vDisk Stats - Write I/O Size
図14-11. 2009ページ - vDiskステータス – WRITE I/Oサイズ

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

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

2009 Page - vDisk Stats - Working Set
図14-12. 2009ページ - vDiskステータス – ワーキングセット

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

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

2009 Page - vDisk Stats - Read Source
図14-13. 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
図14-14. 2009ページ - vDiskステータス – WRITE先
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
図14-15. 2009ページ - vDiskステータス – エクステントグループ上層移動

2010ページ (Curator) の利用

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

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

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

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

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

2010 Page - Curator Nodes
図14-16. 2010ページ – Curatorノード

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

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

スキャンはスケジュールに基づいて定期的に実行されますが、特定のクラスタイベントによっても起動されます。

ジョブが実行されるいくつかの理由を、以下に示します:

  • 定期実行(通常の状態)
  • ディスク、ノードまたはブロックの障害
  • ILMの不均衡
  • ディスクまたは階層の不均衡

以下が「Curatorジョブ」一覧になります:

2010 Page - Curator Jobs
図14-17. 2010ページ – Curatorジョブ

一覧には、各ジョブが実行したアクティビティの概要の一部が記載されています:

処理 フルスキャン パーシャルスキャン
ILM X X
ディスクバランシング X X
圧縮 X X
重複排除 X  
消失訂正符号 (EC) X  
ガベージクリーンアップ X  

「実行ID (Execution ID)」をクリックすると、ジョブの詳細ページに移り、生成されたタスクと同時にジョブの詳細情報が表示されます。

ページの上部に表示される一覧には、ジョブのタイプ、理由、タスク、デュレーションといった詳細が表示されます。

次のセクションには「バックグラウンドタスクステータス (Background Task Stats)」一覧があり、タスクのタイプ、生成された数量やプライオリティといった詳細が表示されます。

以下がジョブ詳細一覧になります:

2010 Page - Curator Job - Details
図14-18. 2010ページ – Curatorジョブ – 詳細

以下が「バックグラウンドタスクステータス」一覧になります:

2010 Page - Curator Job - Tasks
図14-19. 2010ページ – Curatorジョブ – タスク

次のセクションには「MapReduceジョブ」一覧があり、各Curatorジョブにより起動された、実際のMapReduceジョブが表示されます。パーシャルスキャンには単独のMapReduceジョブとなり、フルスキャンは4つのMapReduceジョブとなります。

以下が「MapReduceジョブ」一覧になります:

2010 Page - MapReduce Jobs
図14-20. 2010ページ – MapReduceジョブ

「ジョブID (Job ID)」をクリックすると、MapReduceジョブの詳細ページに移り、タスクステータス、各種カウンター、MapReduceジョブの詳細が表示されます。

以下に、ジョブのカウンターの例を図示します:

2010 Page - MapReduce Job - Counters
図14-21. 2010ページ – MapReduceジョブ – カウンター

メインページの次のセクションには、「QueueされたCuratorジョブ」および「最後に完了したCuratorスキャン」一覧があります。これらの一覧には、定期的なスキャンを実施すべき適切な時間と、最後に実行されたたスキャン詳細が表示されています。

以下が「QueueされたCuratorジョブ」および「最後に完了したCuratorスキャン」セクションになります:

2010 Page - Queued and Successful Scans
図14-22. 2010ページ – MapReduceジョブ – Queueされたスキャンおよび完了したスキャン

パートIV. vSphere

アーキテクチャー

ノードアーキテクチャー

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

ESXi Node Architecture
図15-1. ESXiノードアーキテクチャー

最大構成と拡張性

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

  • 最大クラスタサイズ:64
  • VMあたりの最大vCPU数: 128
  • VMあたりの最大メモリ: 4TB
  • ホストあたりの最大VM数: 1,024
  • クラスタあたりの最大VM数: 8,000(HAが有効な場合、データストアあたり2,048)

注意: vSphere 6.0 時点

ネットワーク

各ESXiホストにはローカルvSwitchがあり、Nutanix CVMとホストのホスト間通信に使用されます。外部やVMとの通信には、標準のvSwitch(デフォルト)またはdvSwitchが使用されます。

ローカルvSwtich (vSWitchNutanix) は、Nutanix CVMとESXiホスト間の通信のためのものです。ホスト上のこのvSwitchにはvmkernelインターフェース(vmk1- 192.168.5.1) があり、CVMにはこの内部スイッチのポートグループにバインドされるインターフェース (svm-iscsi-pg - 192.168.5.2) があります。これが基本的なストレージの通信パスになります。

外部のvSwitchは、標準のvSwitchまたはdvSwitchです。これはESXiホストとCVMの外部インターフェースをホストすると同時に、ホスト上のVMに使用されるポートグループもホストします。外部のvmkernelインターフェースは、ホスト管理やvMotionなどに使用されます。外部CVMインターフェースは、他のNutanix CVMとの通信に利用されます。トランク上のVLANが有効になっていれば、ポートグループは必要なだけ生成できます。

以下は、vSwitchアーキテクチャーの概念的な構造を図示したものです:

ESXi vSwitch Network Overview
図: ESXi vSwitchネットワーク概要
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/

  • スナップショットありの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
図16-1. 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
図16-2. ESXi ホストネットワーク – ローカルCVM障害時

アドミニストレーション

重要なページ

近日公開!

コマンドリファレンス

ESXiクラスタップグレード

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

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

# 例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

esxcli software acceptance set --level CommunitySupported

VIBのインストール

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

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

# または

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

ESXiのramdiskスペースを確認

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

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

pynfsログのクリア

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

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

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

近日公開!

トラブルシューティングと高度なアドミニストレーション

近日公開!

パートV. Hyper-V

アーキテクチャー

ノードアーキテクチャー

Hyper-Vを導入した場合、コントローラVM (CVM) は、VMとして稼動しディスクはディスクパススルーを使用して提供されます。

Hyper-V Node Architecture
図18-1. Hyper-V ノードアーキテクチャー

最大構成と拡張性

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

  • 最大クラスタサイズ: 64
  • VMあたりの最大vCPU数: 64
  • VMあたりの最大メモリ: 1TB
  • ホストあたりの最大VM数: 1,024
  • クラスタあたりの最大VM数: 8,000

注意: Hyper-V 2012 R2現在

ネットワーク

各Hyper-Vホストには、内部限定の仮想スイッチがあり、Nutanix CVMとホスト間の通信に使用されます。外部やVMとの通信には、外部仮想スイッチ(デフォルト)または論理スイッチが使用されます。

内部スイッチ (InternalSwitch) は、CVMとHyper-Vホスト間のローカル通信のためのものです。ホストは、内部スイッチ (192.168.5.1) 上に仮想イーサネットインターフェース (vEth) を持ち、CVMは内部スイッチ (192.168.5.2) 上にvEthを持っています。これが基本的な通信パスとなります。

外部vSwitchは、標準的な仮想スイッチまたは論理スイッチでかまいません。外部vSwitchは、Hyper-VホストとCVMに加え、ホスト上のVMに使用される論理およびVMネットワークのためのインターフェースをホストします。外部vEthインターフェースはホスト管理、ライブマイグレーションなどに用いられます。外部CVMインターフェースは、他のNutanix CVMとの通信に使用されます。トランク上でVLANが有効になっていれば、論理およびVMネットワークはいくつでも作成することができます。

以下は、仮想スイッチアーキテクチャーの概念的な構造を図示したものです:

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

アドミニストレーション

重要なページ

近日公開!

コマンドリファレンス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Get-NetAdapterRss

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

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

allssh "winsh "get-wmiobject win32_computersystem"

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

近日公開!

トラブルシューティングと高度なアドミニストレーション

近日公開!

後書き

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