azure vm の可用性を見直そう
TRANSCRIPT
Azure VM の可用性を見直そう～今更聞けない障害 / SLA / メンテナンスの仕組み～
Interact x Cloud Samurai 2016 Summer
2016/06/25
宇田 周平(うだ しゅうへい)
日本マイクロソフト株式会社カスタマー サービス&サポートサポート エンジニア
Windows (Hyper-V, Remote Desktop, Performance)
Azure (IaaS / Network)
Twitter: syuheiuda
Facebook: syuhei.uda
Blog: http://www.syuheiuda.com/
Raspberry Pi 2とWindows 10ではじめるIoTプログラミング (マイナビ出版刊)
余談ですが...
プライベート コンテナ データセンターが欲しいので、海上コンテナを見てきました
本セッションのゴール
Azure のインフラについてご理解いただく
可用性セットやメンテナンスなどの Azure 独自の概念や仕組みを正しくご理解をいただく
“芯” 機能を理解できれば、Azure は怖くない
アジェンダ
Azure のサポート契約
サービス レベル (SLA)
データセンタの裏側
障害・メンテナンス時の挙動
いつものお願い
コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
本セッションの内容は、本日 (2016/06) 時点でのものであり、今後予告なく変更される場合があります。
サポート契約についてサービス レベル / 重大度
Azure のサポート契約
https://azure.microsoft.com/ja-jp/support/plans/
中の人からのお願い
お問い合わせ時の重大度 A はサービス ダウンなどの即時対応が必要な場合にのみご利用ください（原則、重大度は B / C でお願いします）
重大度 A の場合… Microsoft 側は 24 時間対応の特別体制となり、一方で
お客様側にも 24 時間ご連絡がつく体制をとっていただきます
復旧が最優先のため、原因追及は緊急度 A の範囲外(復旧後、営業時間内にて緊急度 B での対応は可能)
Azure の SLA についてSLA を正しくご存知ですか？
SLA とは
機能毎に定められた稼働率の目標
稼働率は月単位で計算されます 99.99 % (約 4 分)
99.95 % (約 21 分)
99.9 % (約 43 分)
99 % (約 7.2 時間)
VM の SLA
インターネットに接続するすべての仮想マシンに、同じ可用性セットにデプロイした2 つ以上のインスタンスがある場合、マイクロソフトは、99.95% 以上の時間において外部接続が確保されることを保証します。
https://azure.microsoft.com/ja-jp/support/legal/sla/virtual-machines/v1_1/
StorageのSLA
マイクロソフトは、99.99% (クール アクセス レベルについては 99.9%) 以上の時間において、読み取りアクセス地理冗長ストレージ (RA-GRS) アカウントからのデータの読み取り要求が正しく処理されることを保証します。
ただし、プライマリ リージョンからのデータの読み取りに失敗した場合は、セカンダリ リージョンで読み取りを再試行します。
https://azure.microsoft.com/ja-jp/support/legal/sla/storage/v1_1/
ExpressRoute / VPN の SLA
マイクロソフトは、ExpressRoute の専用回線について 99.9% 以上の可用性を保証します。
マイクロソフトは、各 VPN Gateway について 99.9% の可用性を保証します。
https://azure.microsoft.com/ja-jp/support/legal/sla/expressroute/v1_0/https://azure.microsoft.com/ja-jp/support/legal/sla/vpn-gateway/v1_0/
ここからが本題
可用性を確保するには…
まずは「可用性セット」を組みましょう(残念ながら、そもそも可用性セットを組んでいないor 正しく使っていただけていないお客様が多いです)
Azure の裏側の仕組みがどうなっているか正しく理解しましょう
クラスタ
更新ドメイン (Update Domain)
障害ドメイン (Fault Domain)
個々のサービス・アプリでの可用性担保に関しては、また別の機会に...
可用性セットとは
仮想マシンを分散配置させるための仕組み(各仮想マシンを異なるラックや物理サーバに配置するためのパラメータ)
同じ役割を持つサーバ群を可用性セットでグループ化しましょう
Web サーバ (x2 台以上) の可用性セット
DB サーバ (x2 台以上) の可用性セット
(Web サーバと DB サーバを一緒しないこと)
データセンタの裏側
Azure リージョン 場所
東アジア 香港
東南アジア シンガポール
東日本 東京、埼玉
西日本 大阪Azure のデータセンタ
Azure のデータセンタは実は 1 リージョンあたり複数ある
https://azure.microsoft.com/ja-jp/regions/
データセンタの中身
http://www.wired.com/2013/02/boydton/
Azure のクラスタ(≠ MSFC)
先の写真のような、サーバーのグループをクラスタという単位で読んでいます
クラスタ内は原則として同一の筐体ですがVM サイズごとにハードは異なります
A シリーズ: 様々なサーバー下で稼働可
D シリーズ: ローカル SSD
Dv2 シリーズ: Xeon E5-2673 v3
参考: https://channel9.msdn.com/Events/de-code/2016/INF-001
整理すると
東日本
東京
第一クラスタ
(A 専用)
約 20 ラック
第二クラスタ
(A / D 専用)
約 20 ラック
第三クラスタ
(A / D 専用)
約 20 ラック
第四クラスタ
(A / Dv2 専用)
約 20 ラック
第五クラスタ
(A / DS 専用)
約 20 ラック
埼玉
第一クラスタ
(A 専用)
約 20 ラック
※ あくまでもイメージです
障害ドメイン更新ドメイン
障害ドメイン更新ドメインの確認方法
障害ドメインとは何か…
電源とネットワーク スイッチを共有する仮想マシンのグループ
要は Azure のインフラにおける障害発生時の影響範囲 (あるラックが死んでも、隣のラックは影響を受けない)
VM 配置のイメージ
Windows Azure Internalshttps://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B402
ラック # 1 ラック # 2 ラック # 3 ラック # 4
物理サーバが故障したら…
可用性セットを組んだ VM 群
Azure VM
故障等で使えない物理サーバー
1. 物理サーバーで何らかハードウェア障害が発生
2. 障害を検知後、正常な物理サーバー自動で移動
(Kernel-Power 41)
3. 故障したサーバとしてマークし、運用から隔離
ラック # 1 ラック # 2 ラック # 3 ラック # 4ラック # 1 ラック # 2 ラック # 3 ラック # 4
電源障害が発生すると…
3. 故障したサーバーとしてマーク(これが障害ドメイン)
1. シャーシ全体がダウン
2. それぞれ、空いている正常な物理サーバに移動
可用性セットを組んだ VM 群
Azure VM
故障等で使えない物理サーバー
更新ドメインとは何か…
メンテナンス時に、作業タイミングが重複してダウンタイムが発生しないようにするための仕組み
メンテナンスにも色々ある
計画内メンテナンス通知のないもの (≒再起動が発生しない)
通知のあるもの (≒再起動が発生する)
シングル インスタンス対象
マルチ インスタンス対象
計画外メンテナンス(≒障害) 前述の自動復旧とか
メンテナンス通知メールは二種類ある
シングル インスタンス(12 時間中 15 分)
マルチ インスタンス(3 日間中 15 分、可用性を考慮)
Demoマルチ インスタンスを対象としたメンテナンスの流れ
最後に まずは正しく可用性セットを組みましょう
Q & A
ご清聴ありがとうございまいた。
個別のご相談もお気軽にどうぞ！
Appendix
可用性関連資料 仮想マシンの可用性管理
Azure での仮想マシンに対する計画的なメンテナンス
Azure VM のメンテナンス FAQ
Azure での高可用な基幹業務アプリケーションのデプロイ
Appendix
その他、目を通していただきたい情報 Azure 仮想マシンにおける不要な NIC を削除する方法
Azure VM のストレージ パフォーマンスに関する留意点と対処策
VPN ゲートウェイのリセットについて
IP アドレス 168.63.129.16 について
Appendix
おまけ Azure Subscription のサマリーを生成するスクリプトを公開
しました
Get-SubscriptionDetails