Nutanix ってナニ？

「ハイパーコンバージド」言われてもワカランのじゃ

フランちゃんウフフなしすてむえんじにあ

おおかわ かずひと

Nutanix = Software

分散ファイルシステムで実装された仮想ストレージソフトウェア

ハイパーバイザ上で仮想マシンとして動作する -> CVM(Controller VM)

VMware, Hyper-V, Acropolis(KVM)をサポート

主にCassandraを核として実装

あと付随した管理ツール群

NutanixのHardware

ソフトウェア実装なのでx86サーバならなんでも動く、本家はSupermicro製

DELLも公式サポート (レノボ？知らない子ですね…)

無料のOSS版(Nutanix CE)もある

ほとんどの機能が試せる（らしい）

イメージとして配布(*.img)

パブリッククラウドで動かそうとしている猛者も… (http://www.adventar.org/calendars/1124)

個人的に評価中

URL

http://www.nutanix.com/products/commu

nity-edition/

じゃあどうやって動いとるの？

Nutanixの構成について

構成イメージ その1

SATA DOM 16G HDD SSD

Hyper Visor

(ESXi, Hyper-V, KVM)

HyperVisorはSATA DOMに格納されていて

ここから起動する

※DOMは非冗長化 CVM

構成イメージ その2

SATA DOM 8G HDD SSD

Hyper Visor

(ESXi, Hyper-V, KVM)

• CVMはHV上で起動

• SSDとHDDを制御する

• HVと仮想スイッチで

接続してSANを構成

CVM

iSCSI

NFS

※192.168.5.0/32

決め打ち 分散仮想ストレージ領域

vSwitch

構成イメージ その3

SSD

Hyper Visor

クラスタ構成で冗長性を確保

CVM

HDD SSD HDD SSD HDD SSD HDD

Hyper Visor Hyper Visor Hyper Visor

CVM CVM CVM

分散仮想ストレージ領域

構成イメージ その4

1ノード論理構成

SATA DOM

boot

クラスタの構成

クラスタコンポーネントをしっかり覚えておくと障害対応のときに役立つはず…

クラスタを構成するコンポーネント

Zeus

全クラスタの設定を参照、変更する

Apache Zookeeperで実装されている

Zookeeper

クラスタ構成情報を管理する(コーディネーションサービス)

最低3ノードで構成され、そのうちの1

台が自動的にリーダーになる

リーダーノードは構成情報を各ノードにレプリケーションする

リーダーがダウンした場合は、自動的に次のリーダーが選出される

Stargate

全てのI/O操作を実行している ◦ HVからのI/O要求

◦ ローカルディスクのI/O処理

MedusaのメタデータとZeusの設定情報に依存しているので、これらが止まるとノードのI/O障害となる

ZookeeperがStargateの障害を検知した場合は自動で切り離される（=CVMとしての機能停止、Data Path Redundancyモードに）

Cassandra

Cassandra…う…頭が…

という記憶しかないけど、あれは当時使ってた人たちのせい（白目

メタデータを管理するデータベース

Zeusに構成管理を依存している

NutanixではMedusa経由でアクセスしている

個人的経験では何かあった時深淵の闇を見ることができるソリューション

Curator

メタデータのメンテナンスを実行している

◦ リバランス

◦ スクラビング

◦ データ整合性の確認

Curatorクラスタの中で1台がマスターとなりジョブやタスクの管理権限を受け持つ

MapReduceアルゴリズム

クラスタ障害時にデータの再分布もする

Medusa

Cassandra のメタデータにアクセスするためのフロントエンド

各ノードで起動している

Prism

UIとAPIを提供するゲートウェイ

各ノードで実行されているため、どこのCVM IPにつなげても使うことができる

全コンポーネントのステータス確認 nutanix@$ cluster status

2015-07-29 13:52:28 INFO cluster:1691 Executing action status on SVMs

The state of the cluster: start

Lockdown mode: Enabled

CVM: Up

Zeus UP [8475, 8488, 8489, 8490, 8498, 8511]

Scavenger UP [8717, 8734, 8735, 8763]

ConnectionSplicer UP [8784, 8799]

Hyperint UP [8805, 8817, 8818, 8819, 8825, 8829]

Medusa UP [8959, 8973, 8974, 8989, 9154]

DynamicRingChanger UP [9829, 9841, 9842, 9862]

Pithos UP [9844, 9857, 9858, 9885]

Stargate UP [9861, 9882]

Cerebro UP [10211, 10223, 10224, 10252]

Chronos UP [10226, 10238, 10239, 10245]

Curator UP [10312, 10332, 10333, 10450]

Prism UP [10342, 10355, 10356, 10392]

AlertManager UP [10358, 10370, 10371, 10442]

Arithmos UP [10373, 10385, 10386, 10476]

StatsAggregator UP [10389, 10409, 10410, 10472]

SysStatCollector UP [10411, 10431, 10432, 10526]

Nutanixクラスタの冗長 頭の運動・・・

いろいろ考えられる故障パターン

ノード障害

ブロック障害

上記の多重障害

ノード障害

障害

ブロック障害

障害

耐障害性

リング状トポロジー構造でレプリケーション ◦ 空き容量と必要なブロック/ノード数があれば永遠にレプリカを作成し続けられる

データの複製レベルで耐障害性を高められる ◦ Replication Factor 2(2 Replication)

◦ Replication Factor 3(3 Replication) CVMに24Gのメモリ割り当てが必要

最低5ノード

コンテナごとにRF3にするか選択できる(重要なやつだけとか可)

近々RF2コンテナをRF3にアップグレードできる変更がはいる予定

ブロック障害を考慮した Block awareness

Block awareness

ブロック障害からデータを保護する機能

Web Consoleから確認可能

ブロックのHW構成が大きく違うと有効にできない場合あり

◦ 容量差33%以内, 同じストレージ階層(HDD, SSD)

構成可能な状態でクラスタを組むと自動で有効になる

最低3ブロック必要(※Nutanix推奨最小構成)

RF2 + Block awareness

A B B A

障害

RF3 + Block awareness

障害

A B B A A B

障害

障害後

生き残ったノードでレプリケーションを再開する

リソースが足りなくなった時点でレプリケーションをあきらめる

◦ この時点で耐障害性がなくなるので早めに交換する

容量計算

RAID DISK = ノード/ブロックと同じ考え

異なる点は耐障害のための容量もユーザに見えてしまうこと

実効容量の目安

◦ RF2 クラスタの総容量 /2

◦ RF3 クラスタの総容量 /3

むずかしいからざっくりまとめ

要求する冗長レベルを上げていくとストレージ利用効率が低下する（使える実用量が減る）

障害発生時のために空き容量を残しておくという考え

どこまでの障害ケースを許容するかポリシーを決める

ポリシー内でのストレージ運用を行うことを徹底する

リングトポロジ構造、自動リバランスなのでユーザはノードやブロックの組み合わせを考える必要なし

データは保護されるけど、使えるCPUリソースは当然減るのでサイジングの際はこっちも重要

リングトポロジ構造

Block awareness フロー

Nutanixのバックアップ機能

システムバックアップはできません

ストレージバックアップのみサポート

VMのイメージ単位のバックアップのみサポート(ストレージだしね…)

◦ Local Backup

◦ Async DR(ゆっくりレプリケーション)

◦ Metro Availability(リアルタイム、制限かなり厳しめ)

◦ Cloud Connect(AWS/Azure) ※アクティブサイトして運用はできない

◦ VAAIやVSS等、標準的な機能は大体サポート

システムバックアップ等OSの中身の場合は従来通りバックアップソフト/サーバが必要

個人的に気になったこと 大型建造で武蔵と大和と大鳳が連続できてやばい

本番サイト(Nutanix) <-> 災対サイト(Nutanix CE)という使い方はできるのか(コスト重視)

スプリットブレインは起こり得るのか？

クラスタ外バックアップのベストプラクティス？

Acroporis どうなんじゃろ

Hyper-V どうなんじゃろ

CVMのための制約が慣れるまでめんどくさい

楽できるようなものでもないけどストレージ、 SANを1から覚えるよりかは学習コスト低めな印象

値段高い

ノード数が少ないと分散しているメリットが少ない

外部ストレージを無くすことではなく、固定ストレージレスによる拡張性がNutanixの真価である

過去のNOSでデータ不整合の不具合など起きているので一抹の不安は残る