Nutanix CE ce-2015.11.05-stable の HA機能

Nutanix CE
ce-2015.11.05-stable
のHA機能
19th Jan 2016
@hanakara_milk
NUTANIX COMMUNUTY MEETUP #7

01. 自己紹介
02. CE StableのHA機能
03. 恐ろしい何か
Nutanix CE ce-2015.11.05-stableのHA機能
Content
04. まとめ

About ME
01
FACT
自己紹介的な何か

あけまして，おめでとう御座います！
本年もよろしくお願いいたします！
謹賀新年 2016（遅）

about ME
5
はじめまして！
@hanakara_milkと申します
普段はコテコテのSierに偽装派遣されている営業職
普段は Word ト Excel ト PowerPoint ダケトモダチ
当然ながら仕事でインフラに触れる機会が全くありません。インフラ
に触ってみたい欲求をこじらせて，自宅にいっぱいサーバーをため込
んでいます（※）。
※ため込んでるだけです
マイブーム：
最近，3年ぶり4回目FFXIに復帰しました（Lakshim鯖：タルタル）。

How We Work (できるまで)
このスライドは，だいたいこんな感じで作られています
6
02. Designing
【正月明け】
プレゼンテーションの
デザインテンプレート
を探す
01. plot of a Slide
【正月終わり】
プロットが出来て安心
する
03. Writing
【3日前】
プロット，デザインが終
わって油断。慌てて書き
だす
05. presentation
【本日】
とても緊張しています，
助けて下さい
DONE
【明日】
ホッとします，
SlideShareに資料
アップしておきます
04. Checking
【1日前】
Nutanix中の人に忙し
い中チェックを依頼（無
茶振り）
IDEA
【年末】
安請け合いをした
ので，発表内容を
考えはじめる

ご注意
7
商用Nutanixについて，全く事前知識がないままNutanix CEに触り始めたの
で，既にNutanixをご存じの方は当たり前じゃん？的な内容もあるかと思います。
Nutanix初心者がHAのお話をする(無謀)と言うことで，間違っているかもしれ
ない内容もあり，発表中に唐突に発表者が中の人に質問をすることもあります。
上記を踏まえて，得物を放る場合はフェザータッチな感じ(重要)でお願いいたし
ます。
なお，本スライドは，Nutanix CE ce-2015.11.05-stableに基づいています。

02
FACT
Stables’
HA FunctionNutanix CE StableのHA機能

Nutanix CEのHA機能
Nutanix Community Meetup #4でマルチノードクラスターのお話をさせていただく機会がありましたが…
参考：Nutanix Community Meetup #4（Nutanix CE 入門 -Multi Node 構成編-）http://goo.gl/NKnLBS

HA機能については，試しておらず紹介できませんでしたので，今回改めまして…

HA機能を試す機会（強制）がっ！…
参考：Nutanix Advent Calendar 2015 http://goo.gl/V5JP2Z
えっ…？

そして，無慈悲な募集開始

結局，7日間を担当させていた
だきました。
なお，HA機能については、20
日と21日に投稿しています

Nutanix CEのHA機能おさらい
Nutanix CEは，無償のコミュニティエディションですが，ce-2015.07.16-betaから試験的に，ce-
2015.11.05-stableからはGAとしてHA機能が提供されています。
14
Nutanix CEの高機能なHAは，
コミュニティ版であるにも関わ
らず，無償で提供されていま
す。
Nutanix CEのHA
機能は無償で提供
される
Nutanix CEのHA機能は，一
切の設定を必要とせず，クラス
ターが構成されると同時に機
能し始めます。
Nutanix CEのHA
機能は標準で動作
する
標準
Free
無償

Nutanix CEのHA機能おさらい
ce-2015.11.05-stableからGAされたHA機能は，ベストエフォート型とマネージド型の2つのタイプがあり，
デフォルトでは，ベストエフォート型が有効になっています。
15
Nutanix CEのHA機能は，Acropolis Hypervisor（以下，AHV）に
よって提供される。
Nutanix CEのHA機能には，以下の2つのタイプがある。
Best Effort Basis
ベストエフォート型
Manage VM High Availability
マネージド型
2：デフォルトで無効
明示的に操作を行う必要がある（ただし1クリックのみ）モー
ドで、Best Effort Basisとは異なり可能な限りではなく、予
めHA用にVMの再起動分のメモリリソースを予約しておくこと
で、確実なVMのHAを行う機能。
1：デフォルトで有効
こちらのモードでは、ベストエフォートとあるとおり、ある
ノードで障害が発生し、VMの稼動が困難になった場合に、別
のノードにVMを再起動する空きリソースがあるならば、可能
な限り再起動するHA機能。

ベストエフォートのHA機能
ベストエフォート型は，ノードの障害でVMが停止してしまった場合に，リソースに空きがあれば正常稼動
しているノードにVMを再起動していきます。
16
ベストエフォート型のHA機能の挙動（リソースが十分にある場合）

17
残りVM許容数：2 残りVM許容数：2残りVM許容数：2
 正常に動作しているクラスターがあります

18
 障害が発生することで、ノード（ハイパーバイザー＋CVM）が1つ停止します。ノードが
停止したことで、その上で動作していたユーザーVMも停止します。

19
 特筆すべきことはなく，単純に，生きている他のノードにVMが再起動されます。

20
ベストエフォート型のHAの挙動（リソースが十分にない場合）

21
 正常に動作しているクラスターがあります。ただし、クラスター全体におけるリソース
の空きはほとんどありません。
残りVM許容数：1 残りVM許容数：0 残りVM許容数：0

22

23
 ノード障害に伴って停止してしまったVMのうち、1つは別のノードで再起動に成功しま
すが、クラスター全体でもリソースが完全に枯渇します。

24
 残り1つのVMを再起動しようとしますが、クラスター内のリソースが足りないため、再
起動ができません。
残りVM許容数：0 残りVM許容数：0
ムリー！
残りVM許容数：0

25
残りVM許容数：0 残りVM許容数：0
残りVM許容数：0

マネージドのHA機能
マネージド型は，予めHAによるVMの再起動を見越して，各ノードにHAで移動してくるVM分のリソースを予
約しておきます。そのため，ノード障害でVMが停止しても，他のノードで確実にVMを再起動できます。
26
マネージド型のHA機能の挙動

27
 正常に動作しているクラスターがあります。クラスター全体でまだリソースがある状態
ですが、あらかじめシステムがHA用のリソースを確保しているため、この時点で新規
に増やせるVM数は，ベストエフォート型に比べて減っています。
残りVM許容数：1 残りVM許容数：1 残りVM許容数：１
予約VM許容数：1 予約VM許容数：1 予約VM許容数：1

28
予約VM許容数：1 予約VM許容数：1 予約VM許容数：1

29
 ノード障害で停止してしまったVMは、HAのために用意された予約席で復活を果たし
ます。
予約VM許容数：1
予約VM許容数：0 予約VM許容数：0

ベストエフォート VS マネージド
比較してみよう
30
Best Effort
Basis
Manage VM
High
Availability
ベストエフォート
なるべくリソースを集約した
い，ゆるく管理，多少のVM停
止には目をつぶる環境向け。
平常時のリソースの空きは
大きく取れる
マネージド
絶対に落とせないVMがある！
そんなクリティカルな商用環
境向け。
リソース状況でVM再起動
が出来ない場合がある
SLAが厳しくないならベス
トエフォート型がお勧め
平常時のリソースの空きは
HA用の予約で多少減る
予約されたリソースで確実
にVMが再起動できる
SLAが厳しいクリティカル
な環境にお勧め

ベストエフォート VS マネージド
比較してみよう
31
 メモリリソース比較（参考）
ノード合計約440GBメモリを有するクラスターに30VM起動時

HA機能における復元能力
HA機能には，Nutanixのデータローカリティポリシーとノード間のリソースの平準化機能によって，自動
での復元力が備わっています。
32
Nutanix CEのHA機能には，もう1つ重要な効果がある。
障害からの復旧時に，VMが人手を介さずに自動で復旧したノードに戻る。
・復旧後，VMの再配置の手間いらず。
・リソースの空きがなく，HAによる再起動に失敗したVMも，ノードが復旧
すると自動的に復旧したノードに再起動される。
・データもNutanixの分散ストレージ機能によって保護されているため，
復旧作業いらず。

HA機能の復元能力によるVMの挙動のみに注目するとVMware RDSのリソースの平準化の動きに近しい動きを
しますが，Nutanixではそれ以外にデータローカリティのための意味合いの方が強いかもしれません。
33
 障害が発生し、VMが他のノードで再起動されています。
HA機能における復元能力

34
 障害を起こしたノードが取り除かれ治療先に搬送されます。

35
 システム管理者や保守員の涙ぐましい努力によってノードが復帰します。

36
 一時的に避難していたVM達は，遡上する鮭のように元いた場所に戻っていきます。

37
実際にNutanix CE StableのHA機能を試してみる
こちらで紹介する内容は，Nutanix Advent calendar 2015の「Nutanix Community
Edition（ce-2015.11.05-stable）のAcropolis HypervisorのHA機能（その2）」と重
複があります。
• Nutanix Advent calendar 2015
http:// goo.gl/V5JP2Z
• Nutanix Community Edition（ce-2015.11.05-stable）のAcropolis Hypervisor
のHA機能（その2）
http://goo.gl/9t3cFV

HA機能の設定操作
38
 2つのHA機能の切替方法は至って簡単
Best Effort Basis
設定不要で，標準で機能している
Manage VM High Availability
設定はチェックを入れるのみ
デフォルトでチェックはオフ
状態，この状態でベストエ
フォート型のHAが有効に
なっている。
Enable HAにチェックをいれ
るのみ。チェックを入れると，
システムで予約するメモリ量
が表示される。

HA機能の確認（確認内容）
39NUTANIX COMMUNUTY MEETUP #7
実際にHAの基本的な挙動を確認する。
確認内容は以下のとおり。
1. ノードに障害を発生させた場合にどうなるか？
• 期待する内容としては，VMが別のノードで再起動すること
2. ノードを復旧させた場合にどうなるか？
• 期待する内容としては，再起動されたVMが元のノードに戻ること
• なお，リソースに空きがある状態では，ベストエフォート型，マネージ
ド型共に動きは変わらないことから，今回はベストエフォート型のH
Aで動作を確認する。

HA機能の確認（実施環境）
HA機能の挙動を確認した環境は以下のとおり。
Acropolis Hypervisor （192.168.100.200）
AD/DNS/DHCP
（192.168.100.10）
.100 .101 .102 .103
10GbE SW
GbE SW
操作用PC
（192.168.100.240）
…
192.168.100.0/24
ハイブリッド式
加湿器
CVM CVM CVM

HA機能の確認（確認方法）
1．HA機能でVMが再起動したことの確認
• クラスター全体で30のユーザーVMを起動しておき、ノードのうちの
1つをダウンさせた後も30台のVMが動作していることを確認する。
2．正常なノードで再起動されたVMの追跡
• ノード復旧後のVMの再配置の確認を行うため，一時的に他のノード
で再起動されたVMを追跡する。
3．ノードの復旧時におけるHA機能の確認
• ノードを復旧させた後，クラスターの挙動と追跡対象のVMがどのよ
うな挙動をするか確認する。

HA機能の確認
検証開始前のVMの稼動状況
• Nutanix CEの4ノードクラスター全体で30台のVMが稼動中，障害状況を作り，
シャットダウンするノードは192.168.100.100
ノードIPアドレスノードID 検証時稼動VM数
192.168.100.100 NTNX-98448b07-A 10
192.168.100.101 NTNX-4ec1c789-A 5
192.168.100.102 NTNX-4125b3c8-A 5
192.168.100.103 NTNX-4bda71a1-A 10
Acropolis Hypervisor （192.168.100.200）
.101 .102 .103
…CVM CVM CVM
障害を発生させる
ターゲットノード
.100

HA機能の確認
障害予定のノード上で稼動しているVM
• うち，障害発生予定の192.168.100.100のノード上で稼動しているVMは以下
の10VM
VM名 IPアドレス OS
win10-05 192.168.100.29 Windows 10
centos7-02 192.168.100.44 CentOS 7
win7-10 192.168.100.37 Windows 7
win10-08 192.168.100.31 Windows 10
win7-06 192.168.100.36 Windows 7
win10-01 192.168.100.22 Windows 10
win7-01 192.168.100.20 Windows 7
win7-02 192.168.100.33 Windows 7
ubuntu14-05 192.168.100.52 Ubuntu 14.04
win10-10 192.168.100.30 Windows 10

HA機能の確認（1. HA機能で再起動したことの確認）
障害状況の再現
障害予定のノードで # shutdown -h now を実行，その際あるVMをping監視
ノードが落ち，VMも落ちたため通信も途絶ノードが再起動されたため，通信も再開

ちなみに
• このシャットダウン操作は，シャットダウン対象のノードのハイパーバイザー，つま
りAcropolis Hypervisorに対して行っているが，この操作を行う前にCVMを先
にシャットダウンしている。
• CVMは，Nutanixの中枢機能が備わったVMで，各ノード上で1つだけ起動して，分
散ストレージ機能の提供，ユーザーVMのストレージとの通信，ネットワークの通信
を仲介している。
• CVMをシャットダウンした際、pingのタイミング次第で途切れる場合と途切れな
い場合があるくらいの間隔で，内部のvSwitchが切り替わり，通信が可能。つまり
CVMが落ちても，他のノード上で動いているCVMを通じてVMのストレージアクセ
スやネットワーク通信が可能になっていることがわかる。

Ping監視していたVMは192.168.100.29
• 障害発生予定のノード上で稼動しているVMの「win10-05」がping監視対象
VM名 IPアドレス OS
win10-05 192.168.100.29 Windows 10
centos7-02 192.168.100.44 CentOS 7
win7-10 192.168.100.37 Windows 7
win10-08 192.168.100.31 Windows 10
win7-06 192.168.100.36 Windows 7
win10-01 192.168.100.22 Windows 10
win7-01 192.168.100.20 Windows 7
win7-02 192.168.100.33 Windows 7
ubuntu14-05 192.168.100.52 Ubuntu 14.04
win10-10 192.168.100.30 Windows 10

Ping監視をしていたVMのイベント確認
• ping監視をしていたwin10-05のイベントをPRISMから確認
• 10:41:52pmにVmForcePowerOffのイベントで強制電源断しVMが停止
• 10:42:00pm（8秒後）にVmSetPowerStateで起動が開始
• また，VmSetPowerStateが「Node : NTNX-4ec1c789-A」で実施されたとあ
り，win10-05が192.168.100.101のノードで再起動されたことがわかる
イベントノードやVM 結果時間実施までの時間
VmForcePowerOff win10-05 Succeeded 12/18/15, 10:41:52pm Under 1 second
VmSetPowerState win10-05 Node : NTNX-4ec1c789-A Succeeded 12/18/15, 10:42:00pm Succeeded 8 seconds
ノードIPアドレスノードID
192.168.100.100 NTNX-98448b07-A
192.168.100.101 NTNX-4ec1c789-A
192.168.100.102 NTNX-4125b3c8-A
192.168.100.103 NTNX-4bda71a1-A
絶賛停止中

Ping監視をしていたVM以外もすべて同様のイベント
• ping監視をしていたwin10-05以外についても，すべて同様のイベントが発生
し，すべてのVMが生き残っているノードで再起動したことを確認
• シャットダウンが走って，VMが強制終了された8秒後には，再起動が掛かっている
ので，体感的にもHA機能のパフォーマンスは悪くない（個人的感想）
• win10-05以外のVMが，実際にどこで再起動されたかは後述

HA機能の確認（2. 正常なノードで再起動されたVMの追跡）
HA機能で再起動されたVMの追跡
• ping監視をしていたwin10-05以外のVMの動向を追跡
VM名移動先ノードID 移動先ノードIPアドレス
win10-05 NTNX-4ec1c789-A 192.168.100.101
centos7-02 NTNX-4ec1c789-A 192.168.100.101
win7-10 NTNX-4125b3c8-A 192.168.100.102
win10-08 NTNX-4bda71a1-A 192.168.100.103
win7-06 NTNX-4ec1c789-A 192.168.100.101
win10-01 NTNX-4bda71a1-A 192.168.100.103
win7-01 NTNX-4125b3c8-A 192.168.100.102
win7-02 NTNX-4125b3c8-A 192.168.100.102
ubuntu14-05 NTNX-4bda71a1-A 192.168.100.103
win10-10 NTNX-4bda71a1-A 192.168.100.103

HA機能の確認（3.ノードの復旧時におけるHA機能の確認）
ノードを復旧させた際の挙動を確認する
• 障害状況を作り出すためにシャットダウンしたノードを復旧させ，まず，その際のク
ラスターの挙動をPRISMのログから確認する
• 上から4つのイベントがノードをシャットダウンさせたことで発生したイベント
• 一番下のイベントがノードを復旧させたことで発生したイベント
※10:41:32PM（つまり20:41頃）から翌日の24:28頃まで記事書きしてました
HaFailover Node (Uuid) : 873fa2e9-f0fe-
418b-92cd-63f0adbf031c
Succeeded 12/18/15, 10:40:46pm 2 minutes
StartHAFailover Node (Uuid) : 873fa2e9-f0fe-
Succeeded 12/18/15, 10:41:02pm 30 seconds
HostRestartAllVms Node (Uuid) : 873fa2e9-f0fe-
RestartVmGroup Node (Uuid) : 873fa2e9-f0fe-
Nutanix Advent Calendarの記事を書くために作業中断中※
HostRestoreVmLocality Node : NTNX-98448b07-A Succeeded 12/19/15, 12:28:20am 48 seconds

他のノードで再起動されたVMの追跡調査
• ノードを復旧させた際のVMの挙動をPRISMのログから確認する
Migrate win7-01
Node : NTNX-4ec1c789-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:29:03am 6 seconds
Migrate centos7-02
Migrate win10-05
Migrate win7-02
Node : NTNX-4125b3c8-A
Migrate win7-06
次ページに続く

• ノードを復旧させた際のVMの挙動をPRISMのログから確認する（続き）
※ノードやVMの列は，上から，イベント対象となったVM，次の行がイベントが発生したVMがいるノー
ド，次の行が発生したイベントの宛先のノード
Migrate win7-10
Migrate ubuntu14-05
Node : NTNX-4bda71a1-A
Migrate win10-01
Migrate win10-08
Migrate win10-10

• ノードの復旧に伴う「HostRestoreVmLocality」に連動して，他のノードで再起
動されたVMにおいて，一斉に「Migrate」イベントが発生している
• 「Migrate」イベントを見ると，ある共通点がある。ノード復旧に伴い生じる「Migr
ate」イベントは，全て同一のノード「Node : NTNX-98448b07-A」を宛先とし
たマイグレーションが発生している
• つまり，一時的に他のノードで再起動したVMが，復旧したノードにマイグレーショ
ンされていることがわかる
ノードIPアドレスノードID
192.168.100.100 NTNX-98448b07-A
192.168.100.101 NTNX-4ec1c789-A
192.168.100.102 NTNX-4125b3c8-A
192.168.100.103 NTNX-4bda71a1-A
祝！復活

HA機能の確認（確認結果）
1．HA機能で再起動したことの確認
• 30台のVMが稼動しているクラスターにおいて，ノード障害が発生
した後も，HA機能によって引き続き30台のVMの稼動が確認できた
2．正常なノードで再起動されたVMの追跡
• ノード障害を発生によって，再起動されたVMは全て別のノードで稼
動していることが確認できた
3．ノードの復旧時におけるHA機能の確認
• ノードを復旧後，再起動されたVMは全て障害発生前に稼動してい
たノードにマイグレーションされた

03
FACT
Something
terrible恐ろしい何か（直訳 by Google翻訳）

HA機能の確認作業中に起こった惨劇
Nutanix Advent Calendar 2015のHA機能に関する記事を書くための検証作業中の深夜，その惨劇は起こり
ました…
56
ここからは…
Nutanix CEのHA機能を意図
しない形で確認できた話し…

みなさんも普段，コレよく書いてますよ…ね…？！よね？
57
Nutanix Community Meetup
事務局様/参加者様
12月18日深夜に発生したクラスター全停止障害報告書
株式会社ホゲ・フガ
@Hanakara_milk
平成27年1月19日
【記】
2015年12月18日に弊社において，電源の供給に問題が発生したことに伴う影響で，
Nutanix CEクラスターが全停止し，多大なご迷惑をお掛け致しました事、深くお詫び申
し上げますと共に、本報告書にて障害内容の詳細と経緯・原因、今後の対応について報告
させて頂きま（ｒｙ

ウウウウオアアー！！
自宅でリアル重大障害発生

しばらく，暗闇の中で思考停止してました…
59
経緯
• クラスター全体のメモリリソース枯渇状態で，ベストエフォート型のHA機能
の確認を行うためにVMを大量クローン後に，クローンしたVMを一斉起動し
たことで，サーバーの電力消費量が急上昇し，ブレーカーがダウン
• さらに，ブレーカーをあげ直して復電した際に，停電によって停止した
Nutanix CEのマルチノードクラスターを構成する4台のサーバーが自動で
電源は入ったが，そのうちの1台がブート設定ミスで起動してこなかった

ブレーカーを戻して，PRISM上で状況確認しながらこんなことを考えてました。
60
次々に頭に浮かび上がる不安
• 全台，サーバーが再起動したところで，Nutanix CEのクラスター環境は問題
なく動いてくれるだろうか…（意訳：Nutanix Advent Calendar 2015の
記事穴あけちゃうかも…）
• VMはクラッシュの影響を受けてないだろうか…
（しかもサーバーが1台上がってこなかったことが判明）
• ちょｗｗｗｗまってｗｗｗｗ，せめて綺麗に全台あがって来てくれれば，クラ
スターも綺麗に復旧したかもしれないのにィイイイイ

しばらく，暗闇の中で思考停止してました…
61
もう少し詳しい経緯を時系列
と合わせて紹介

起点
Ｎｕｔａｎｉｘ Advent Calendar 2015の記事書
きのための検証中，メモリ量をギリギリまで使
い切った状態で，HA機能を試そうとしていた
12/19 深夜
起爆
起動中のWindows 10 VMをそのままacliでク
ローン，次にacliでvm.on win10*でwin10の名
称を持つＶＭすべてを一斉起動した
12/19 02:47
Timeline
もう少し詳しい時系列（物語のタイトル風に）
62

63
兆候
Waitなしで次々ＶＭが起動され，CPU，メモリ，
IOPS値が急上昇，消費電力の上昇と共にラック
マウントサーバーのファンが高回転状態になる
12/19 02:45頃
＼発破／
ブレーカーダウン，部屋が真っ暗，作業に使ってい
たメインPCもダウン，状況が全く見えなくなる
12/19 02:51（Zero Day）
静止
しばらく思考停止
12/19 02:52頃

64
再起
サーバーは復電後，自動起動設定，再びブレー
カーが落ちる危険性があるため，いくつかの家
電製品のコンセントを抜いてブレーカー再起動
12/19 03:00
仮初め
復電後，順調にサーバーが再起動し，PRISMも復
旧，最新の状況確認をすると50程度のVMが既に
再起動しているが…
12/19 03:01
苦難
クラスターも無事に復旧したように見えたがロ
グを確認していると，サーバーのうちの1台が起
動せず，クラスターに復帰してないことに気づく 12/19 03:16

65
後悔
起動していないサーバーを確認するとブートデ
バイス順の設定ミスで「System not found」，
しかし，クラスターは既に復旧を終えている…
12/19 03:21
本物
残り1台のサーバーのブートデバイス順の設定を
修正し，無事にクラスターに編入されるよう祈りな
がら，改めて起動し直す
12/19 03:23
歓喜
残り１台のサーバーは，既に復旧していた3ノー
ドクラスターに認識され，自動的にクラスターに
組み込まれることで4ノードクラスターが復帰
12/19 03:25

66
旅立ち
障害前の正常な4ノードクラスターになったこと
を確認し，本来の目的であるメモリ量をギリギリ
まで使い切った状態でのHA機能を試す時が…
12/19 04:30頃
オレ達の戦いはこれからだ！
Nutanix Advent Calendar 2105の記事に必要なHA機能の確認
が全て終わり，穏やかな日々が戻って来た。しかし，既にiSCSI機能の
確認が待っている。これからもオレ達の戦いは続いていく…
12/21 01:00頃

時系列の先頭に「主人公達は」の一言を入れると，完全に物語風になります。
67
@hanakara_milk先生の
次回作にご期ｔ（ｒｙ

ネタパートはここまでにして，実際のシステム障害の事例に照らし合わせると，こんな状況ではないで
しょうか。ここからの復旧は，通常，容易ではありません。
68
障害の事例に照らし合わせると
• HA機能やフェイルオーバー機能で，単一の障害まではカバーできる
ハズだったが，停電に見舞われ，すべての機能が停止してしまった
• 意図しない障害が発生，しかも，うまく行ったと思われた障害復旧が
うまく行っておらず，ヒューマンエラーで二次障害が生じてしまった
典型的な，システム障害でどハマリするパターン

ログから，どのようなことがNutanix CEクラスターで起こっていたのかを確認していきます。
69
ログから見た障害から復旧まで
• クラスターを構成する各ノードに関するイベント
• 3:15頃にサーバーが1台起動していないログを見つけて異常に気づく。これは先に起
動が完了した3台でクラスターが正常に復旧し，VMが既に動作し始めていたため。
• Nutanixは，最低3台のノードが正常であれば，クラスター的には正常と判断し動作し
続けるため，ログを見つけるまで見落としていた。
Critical Controller VM 192.168.100.110 has been rebooted 12/19/15, 03:02:32am -
Warning Controller VM 192.168.100.111 down for 307 seconds 12/19/15, 03:06:58am -
Critical Controller VM 192.168.100.111 has been rebooted 12-19-15, 03:25:42am -

ログから，どのようなことがNutanix CEクラスターで起こっていたのかを確認していきます。
70
ログから見た障害から復旧まで
• VM関するイベント
• win10-83と言うVMをサンプルに確認すると，3:02に一旦，復旧した3ノードクラス
ター上でVMが再起動。
• その後，起動していなかった1台のサーバーを起動したところ，元々その復旧したサー
バーで稼動していたため，「Migrate」イベントが発生し，後から復旧したノードにマ
イグレーションしている。
VmSetPowerState win10-83 Succeeded 12/19/15, 03:02:41am 3 seconds
Migrate win10-83

PRISMで見る障害の様子
71
ＰＲＩＳＭに残る障害の爪痕
急激にＣＰＵとメモリー
が上がって，そして…
なんか，Ｃｒｉｔｉｃａｌとか
出てるんですけど…
復電後，ＶＭ再起動や
メタデータのチェック
等でＩＯＰＳも急上昇

Nutanix CEのクラスターを停電で全停止させてから，どのように復旧させてきたかについてみていきます
72
Nutanix CEクラスターの障害からの復旧作業
• 時系列やログから，どのようにNutanix CEのクラスターやVMが復旧して
いったかは分かったが，ではどうやって復旧させたのか？
• 次のスライドから，Nutanix CEクラスターが全停止した場合の復旧手順に
ついて確認していく

全停止したNutanix CEクラスターの復旧作業手順の確認
73
実は…

全停止したNutanix CEクラスターの復旧作業手順の確認
Nutanix CE復旧の具体的な
操作作業は何1つ行っていない

さすがに言い過ぎでしょう？
75
Nutanix CEクラスターの障害からの復旧作業
• 言い過ぎでした，やったことが1つだけあります。

さすがに言い過ぎでしょう？
私がブレーカーを上げました
＼(^o^)／

全停止したNutanix CEクラスターの復旧作業手順は…
77
本当に何もしてない？なぜ？

78
本当に何もしてない？なぜ？
答え

答え
Nutanix CEが，全自動で全て
復旧してくれたから

Nutanix CEのHA機能（再掲）
Nutanix Community Meetup #4でマルチノードクラスターのお話をさせていただく機会がありましたが…
Nutanix CEにおける耐障害性や可用性のおさらい
• 再びNutanix Community Meetup #4で紹介した，Nutanix CEの耐障害
性と可用性について振り返ってみる

Nutanix CEのHA機能（再掲）
ここで再度Nutanix Community Meetup #4でマルチノードクラスターの振り返り…

Nutanix CEの可用性と耐障害性
Nutanix Community Meetup #4で発表した内容の1スライドでまとめて振り返ると…
1.Cluster
クラスターの耐障害性
Cluster Fault tolerance
VMの可用性
VM Availability
2.VM
データの耐障害性
Data Fault tolerance
3.DATA
• 4ノード以上で構成されるクラスターでは，ノード障害発生した場
合には，動的に障害ノードが除外されることでクラスターの健全性
が回復する。
• 障害ノードが除外されクラスターでは，クラスターの完全保護を可
能とする規程のノード数3をクリアしていれば，引き続きクラスター
は保護される。
• VMの可用性は，「Acropolis HA」と「Migrate」の2つの要素で
構成される。
• Acropolis HAは，ノード障害等で，そのノード上で動作していたV
Mが死んでしまった場合に，別のノードで自動起動する機能。
• Acropolis HAとMigrateはマルチノードクラスターを構成した時
点で利用可能で，特別な設定を必要としない。
• データの耐障害性はRF(Replication Factor)で設定され，マル
チノードクラスターの場合はデフォルトでRF2が設定される。
• クラスター内のPool及びContainerを構成するディスクが破損し
た場合でも，別のノードに接続されたディスクにコピーを持ち，ノー
ドの1つがディスクごと壊れた場合やディスクの1つが壊れた場合
において耐障害性を有する。

Nutanixの有する耐障害性と可用性に基づくと…
83
クラスター
• 3ノードあればクラスターの保護機能が完全に動作するため，同時に3台復
旧したことで，クラスターは復旧され正常動作モードになった
VM
• HA機能による既定の動作で，正常に動作するノード上でVMは再起動され，
またノードが復旧すると，ローカリティに基づいてマイグレーションされた
データ
• RF2によるデータ保護により，ノードが1台丸ごと欠けた状態でも，他のノー
ドに接続されたディスクにコピーがあるためデータは自動で保護された

04
FACT
Summary
まとめ

Nutanix CEのHA機能のまとめ
85
HA機能は無償で提供される
Nutanixは，無償のコミュニティ版でも
エンタープライズ環境で求められるレ
ベルのHA機能が利用できる
01
VMは，障害・復旧のタイミングで自動配置される
HA機能とNutanix，AHVのポリシーに
基づいて，VMは自動的に最適な場所に
配置され，人手を必要としない
04
HA機能は特別な設定を必要とせず機能する
HA機能を利用するのに，特別な設定は
一切必要とせず，クラスターが構成され
た時点で機能する
02
ノードやクラスターの復旧は自動で行われる
Nutanixの持つ耐障害性，可用性の機
能に基づき，障害からの復旧は人手を介
することなく自動で行われる
05
要件等に合わせて2つのHA機能を使い分ける
HA機能は，ベストエフォート型とマネー
ジド型があり，要件等に基づいて使い分
ける。設定変更もワンクリックで済む
03
全ノードが停止しても問題なく自動で復旧できる
ブレーカーが落ちようが，ノードが1つ
上がってなかろうが，一定の条件をクリ
アしていれば，自動復旧し正常動作する
06

86
補足
• 今回は，全自動で復旧できる条件（Nutanixの各種，耐障害性，可用性でカ
バーできる範囲）に当てはまったため，本当に何もすることなくブレーカーを
あげてサーバーが起動しただけで，すべて元通りに復旧した。
• しかし，当然ながら，Nutanixの各種，耐障害性，可用性でカバーできる範囲
を越えた場合は，相応の復旧作業が必要になる。
• しかし， Nutanixの各種，耐障害性，可用性でカバーできる範囲が大きいた
め，多少の障害ではシステム管理者の手を必要としない。

87
Nutanixの各種，耐障害性，可用性でカバーできる範囲外って？
例えば…
• 4ノード中2ノードが同時に上がってこなかった場合
• Cassandraのメタデータストアが不幸にも壊れた場合など
※他にどんなパターンがあるかは，中の人に聞いて下さい，ってゆーかどんなパターンがあります？
• さすがにこの辺だと，復旧は厳しい道のりになるかも…

Thanks for Your Time
ご静聴ありがとう
ございます

Nutanix CE ce-2015.11.05-stable の HA機能

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (15)

Dernier

Dernier (8)

Nutanix CE ce-2015.11.05-stable の HA機能