Mais conteúdo relacionado Nutanix CE ce-2015.11.05-stable の HA機能2. 01. 自己紹介
02. CE StableのHA機能
03. 恐ろしい何か
Nutanix CE ce-2015.11.05-stableのHA機能
Content
04. まとめ
NUTANIX COMMUNUTY MEETUP #7
6. How We Work (できるまで)
このスライドは,だいたいこんな感じで作られています
6
02. Designing
【正月明け】
プレゼンテーションの
デザインテンプレート
を探す
01. plot of a Slide
【正月終わり】
プロットが出来て安心
する
03. Writing
【3日前】
プロット,デザインが終
わって油断。慌てて書き
だす
05. presentation
【本日】
とても緊張しています,
助けて下さい
DONE
【明日】
ホッとします,
SlideShareに資料
アップしておきます
04. Checking
【1日前】
Nutanix中の人に忙し
い中チェックを依頼(無
茶振り)
IDEA
【年末】
安請け合いをした
ので,発表内容を
考えはじめる
NUTANIX COMMUNUTY MEETUP #7
9. Nutanix CEのHA機能
Nutanix Community Meetup #4でマルチノードクラスターのお話をさせていただく機会がありましたが…
参考:Nutanix Community Meetup #4(Nutanix CE 入門 -Multi Node 構成編-)http://goo.gl/NKnLBS
NUTANIX COMMUNUTY MEETUP #7
30. ベストエフォート VS マネージド
比較してみよう
30
Best Effort
Basis
Manage VM
High
Availability
ベストエフォート
なるべくリソースを集約した
い,ゆるく管理,多少のVM停
止には目をつぶる環境向け。
平常時のリソースの空きは
大きく取れる
マネージド
絶対に落とせないVMがある!
そんなクリティカルな商用環
境向け。
リソース状況でVM再起動
が出来ない場合がある
SLAが厳しくないならベス
トエフォート型がお勧め
平常時のリソースの空きは
HA用の予約で多少減る
予約されたリソースで確実
にVMが再起動できる
SLAが厳しいクリティカル
な環境にお勧め
NUTANIX COMMUNUTY MEETUP #7
37. 37
実際にNutanix CE StableのHA機能を試してみる
NUTANIX COMMUNUTY MEETUP #7
こちらで紹介する内容は,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
38. HA機能の設定操作
38
2つのHA機能の切替方法は至って簡単
Best Effort Basis
設定不要で,標準で機能している
Manage VM High Availability
設定はチェックを入れるのみ
デフォルトでチェックはオフ
状態,この状態でベストエ
フォート型のHAが有効に
なっている。
Enable HAにチェックをいれ
るのみ。チェックを入れると,
システムで予約するメモリ量
が表示される。
NUTANIX COMMUNUTY MEETUP #7
39. HA機能の確認(確認内容)
39NUTANIX COMMUNUTY MEETUP #7
実際にHAの基本的な挙動を確認する。
確認内容は以下のとおり。
1. ノードに障害を発生させた場合にどうなるか?
• 期待する内容としては,VMが別のノードで再起動すること
2. ノードを復旧させた場合にどうなるか?
• 期待する内容としては,再起動されたVMが元のノードに戻ること
• なお,リソースに空きがある状態では,ベストエフォート型,マネージ
ド型共に動きは変わらないことから,今回はベストエフォート型のH
Aで動作を確認する。
40. HA機能の確認(実施環境)
40NUTANIX COMMUNUTY MEETUP #7
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
41. HA機能の確認(確認方法)
41NUTANIX COMMUNUTY MEETUP #7
1.HA機能でVMが再起動したことの確認
• クラスター全体で30のユーザーVMを起動しておき、ノードのうちの
1つをダウンさせた後も30台のVMが動作していることを確認する。
2.正常なノードで再起動されたVMの追跡
• ノード復旧後のVMの再配置の確認を行うため,一時的に他のノード
で再起動されたVMを追跡する。
3.ノードの復旧時におけるHA機能の確認
• ノードを復旧させた後,クラスターの挙動と追跡対象のVMがどのよ
うな挙動をするか確認する。
42. HA機能の確認
42NUTANIX COMMUNUTY MEETUP #7
検証開始前の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
43. HA機能の確認
43NUTANIX COMMUNUTY MEETUP #7
障害予定のノード上で稼動している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
45. HA機能の確認(1. HA機能で再起動したことの確認)
45NUTANIX COMMUNUTY MEETUP #7
ちなみに
• このシャットダウン操作は,シャットダウン対象のノードのハイパーバイザー,つま
りAcropolis Hypervisorに対して行っているが,この操作を行う前にCVMを先
にシャットダウンしている。
• CVMは,Nutanixの中枢機能が備わったVMで,各ノード上で1つだけ起動して,分
散ストレージ機能の提供,ユーザーVMのストレージとの通信,ネットワークの通信
を仲介している。
• CVMをシャットダウンした際、pingのタイミング次第で途切れる場合と途切れな
い場合があるくらいの間隔で,内部のvSwitchが切り替わり,通信が可能。つまり
CVMが落ちても,他のノード上で動いているCVMを通じてVMのストレージアクセ
スやネットワーク通信が可能になっていることがわかる。
46. HA機能の確認(1. HA機能で再起動したことの確認)
46NUTANIX COMMUNUTY MEETUP #7
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
47. HA機能の確認(1. HA機能で再起動したことの確認)
47NUTANIX COMMUNUTY MEETUP #7
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
絶賛停止中
48. HA機能の確認(1. HA機能で再起動したことの確認)
48NUTANIX COMMUNUTY MEETUP #7
Ping監視をしていたVM以外もすべて同様のイベント
• ping監視をしていたwin10-05以外についても,すべて同様のイベントが発生
し,すべてのVMが生き残っているノードで再起動したことを確認
• シャットダウンが走って,VMが強制終了された8秒後には,再起動が掛かっている
ので,体感的にもHA機能のパフォーマンスは悪くない(個人的感想)
• win10-05以外のVMが,実際にどこで再起動されたかは後述
49. HA機能の確認(2. 正常なノードで再起動されたVMの追跡)
49NUTANIX COMMUNUTY MEETUP #7
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
50. HA機能の確認(3.ノードの復旧時におけるHA機能の確認)
50NUTANIX COMMUNUTY MEETUP #7
ノードを復旧させた際の挙動を確認する
• 障害状況を作り出すためにシャットダウンしたノードを復旧させ,まず,その際のク
ラスターの挙動をPRISMのログから確認する
• 上から4つのイベントがノードをシャットダウンさせたことで発生したイベント
• 一番下のイベントがノードを復旧させたことで発生したイベント
※10:41:32PM(つまり20:41頃)から翌日の24:28頃まで記事書きしてました
イベント ノードやVM 結果 時間 実施までの時間
HaFailover Node (Uuid) : 873fa2e9-f0fe-
418b-92cd-63f0adbf031c
Succeeded 12/18/15, 10:40:46pm 2 minutes
StartHAFailover Node (Uuid) : 873fa2e9-f0fe-
418b-92cd-63f0adbf031c
Succeeded 12/18/15, 10:41:02pm 30 seconds
HostRestartAllVms Node (Uuid) : 873fa2e9-f0fe-
418b-92cd-63f0adbf031c
Succeeded 12/18/15, 10:41:32pm 60 seconds
RestartVmGroup Node (Uuid) : 873fa2e9-f0fe-
418b-92cd-63f0adbf031c
Succeeded 12/18/15, 10:41:32pm 37 seconds
Nutanix Advent Calendarの記事を書くために作業中断中※
HostRestoreVmLocality Node : NTNX-98448b07-A Succeeded 12/19/15, 12:28:20am 48 seconds
51. HA機能の確認(3.ノードの復旧時におけるHA機能の確認)
51NUTANIX COMMUNUTY MEETUP #7
他のノードで再起動されたVMの追跡調査
• ノードを復旧させた際のVMの挙動をPRISMのログから確認する
イベント ノードやVM 結果 時間 実施までの時間
Migrate win7-01
Node : NTNX-4ec1c789-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:29:03am 6 seconds
Migrate centos7-02
Node : NTNX-4ec1c789-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:56am 6 seconds
Migrate win10-05
Node : NTNX-4ec1c789-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:54am 9 seconds
Migrate win7-02
Node : NTNX-4125b3c8-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:50am 7 seconds
Migrate win7-06
Node : NTNX-4125b3c8-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:39am 14 seconds
次ページに続く
52. HA機能の確認(3.ノードの復旧時におけるHA機能の確認)
52NUTANIX COMMUNUTY MEETUP #7
他のノードで再起動されたVMの追跡調査
• ノードを復旧させた際のVMの挙動をPRISMのログから確認する(続き)
※ノードやVMの列は,上から,イベント対象となったVM,次の行がイベントが発生したVMがいるノー
ド,次の行が発生したイベントの宛先のノード
イベント ノードやVM 結果 時間 実施までの時間
Migrate win7-10
Node : NTNX-4125b3c8-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:37am 13 seconds
Migrate ubuntu14-05
Node : NTNX-4bda71a1-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:31am 5 seconds
Migrate win10-01
Node : NTNX-4bda71a1-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:30am 9 seconds
Migrate win10-08
Node : NTNX-4bda71a1-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:21am 10 seconds
Migrate win10-10
Node : NTNX-4bda71a1-A
Node : NTNX-98448b07-A
Succeeded 12/19/15, 12:28:21am 10 seconds
53. HA機能の確認(3.ノードの復旧時におけるHA機能の確認)
53NUTANIX COMMUNUTY MEETUP #7
他のノードで再起動されたVMの追跡調査
• ノードの復旧に伴う「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
祝!復活
54. HA機能の確認(確認結果)
54NUTANIX COMMUNUTY MEETUP #7
1.HA機能で再起動したことの確認
• 30台のVMが稼動しているクラスターにおいて,ノード障害が発生
した後も,HA機能によって引き続き30台のVMの稼動が確認できた
2.正常なノードで再起動されたVMの追跡
• ノード障害を発生によって,再起動されたVMは全て別のノードで稼
動していることが確認できた
3.ノードの復旧時におけるHA機能の確認
• ノードを復旧後,再起動されたVMは全て障害発生前に稼動してい
たノードにマイグレーションされた
62. 起点
Nutanix Advent Calendar 2015の記事書
きのための検証中,メモリ量をギリギリまで使
い切った状態で,HA機能を試そうとしていた
12/19 深夜
起爆
起動中のWindows 10 VMをそのままacliでク
ローン,次にacliでvm.on win10*でwin10の名
称を持つVMすべてを一斉起動した
12/19 02:47
Timeline
もう少し詳しい時系列 (物語のタイトル風に)
62
69. HA機能の確認作業中に起こった惨劇
ログから,どのようなことがNutanix CEクラスターで起こっていたのかを確認していきます。
69
ログから見た障害から復旧まで
• クラスターを構成する各ノードに関するイベント
• 3:15頃にサーバーが1台起動していないログを見つけて異常に気づく。これは先に起
動が完了した3台でクラスターが正常に復旧し,VMが既に動作し始めていたため。
• Nutanixは,最低3台のノードが正常であれば,クラスター的には正常と判断し動作し
続けるため,ログを見つけるまで見落としていた。
NUTANIX COMMUNUTY MEETUP #7
イベント ノードやVM 結果 時間 実施までの時間
Critical Controller VM 192.168.100.110 has been rebooted 12/19/15, 03:02:32am -
Critical Controller VM 192.168.100.113 has been rebooted 12/19/15, 03:05:07am -
Critical Controller VM 192.168.100.112 has been rebooted 12/19/15, 03:06:31am -
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 -
80. Nutanix CEのHA機能(再掲)
Nutanix Community Meetup #4でマルチノードクラスターのお話をさせていただく機会がありましたが…
参考:Nutanix Community Meetup #4(Nutanix CE 入門 -Multi Node 構成編-)http://goo.gl/NKnLBS
NUTANIX COMMUNUTY MEETUP #7
Nutanix CEにおける耐障害性や可用性のおさらい
• 再びNutanix Community Meetup #4で紹介した,Nutanix CEの耐障害
性と可用性について振り返ってみる
82. Nutanix CEの可用性と耐障害性
Nutanix Community Meetup #4で発表した内容の1スライドでまとめて振り返ると…
参考:Nutanix Community Meetup #4(Nutanix CE 入門 -Multi Node 構成編-)http://goo.gl/NKnLBS
NUTANIX COMMUNUTY MEETUP #7
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つが壊れた場合
において耐障害性を有する。