Mais conteúdo relacionado
Semelhante a Azure 障害との上手な付き合い方 (20)
Azure 障害との上手な付き合い方
- 3. C# (浮気もありましたが) 大好き 8年
新機能開発、データベース監視マン
SNS は息してません
BTC 送金お待ちしております
竹井 悠人 萬藤 和久
C# 大好き一筋 15年
セキュリティ研究開発
Facebook は飯テロ アカウント
- 5. これまでお付き合いしてきた障害
● 2016/9/15, 20:48 JST
全世界で DNS 障害
● 2017/3/8, 21:42 JST
東日本のストレージ障害 (Redis)
● 2017/3/28, 3:04 JST
西日本のストレージ障害 (Redis)
● 2017/3/31, 22:28 JST
東日本のストレージ障害 (VM, DB…)
- 9. Storage (Blob, Queue, etc.)
レプリケーションの種類
● Locally Redundant Storage (LRS)
● Zone Redundant Storage (ZRS)
● Geo-Redundant Storage (GRS)
● Read-Access Geo-Redundant Storage (RA-GRS)
- 10. Storage (Blob, Queue, etc.)
対応できること
● ジオ冗長をうまく使いましょう
○ ( でも GRS は実は発動したことはないらしい )
● 同じアセットを別のストレージにデプロイしておく
○ 面倒だからデプロイ自動化しましょうね
○ 接続文字列を動的に変えられる内部の仕組みを
● CDN を使ってエッジ サーバに退避させるのも手
- 12. Azure DNS / その他 DNS がらみ
接続を切らない限りは死なないかも(だが確証はない)
対応できること
● DNS 自体の冗長系統を用意しておくしかない
● Traffic Manager を組み合わせるもよし
- 16. SQL Database のコピーについて補足
● 1 つの DB から同時コピーしてはいけない!
● コピーより geo リストア推奨
何らかの理由で Failover 出来ない場合も geo リストア
● 処理時間は容量とサービス レベルに影響うける
データ量が多ければ時間がかかる
あわせて、構築するサービスレベルのサイズに応じてコピー速度が変わる
今回は... (3/31)
同一サーバー内6時間38分、香港サーバー8時間1分かかったが、
コピー元 DB で reconfiguration が発生し、内部的にやり直ししていた
- 19. SLA
● 保証された稼働率に注意。99.9 % なのか? 99.99 % なのか?
○ Storage : 99.9 % (RA-GRS の場合は読み取り 99.99%)
○ VM / Cloud Service : 99.95 %
○ SQL Database / DNS : 99.99 %
● 正しい冗長構成でなければ、可用性が担保してもらえない
○ VM は可用性セット組んでますか
参考: エンタープライズ契約(EA)の SLA 返金手続きについて
https://blogs.msdn.microsoft.com/dsazurejp/2016/12/12/easla/
- 20. インシデントの上げ方
Azure ポータル ヘルプとサポート から上げる
● 基本
問題の種類、サブスクリプション、サービス リソース、
サポートプラン
● 問題
重要度、問題の種類、カテゴリ、詳細、 (問題発生日)、(添付ファイル)
● 連絡先情報
ご希望の連絡方法、名、性、メール、電話番号
を入れればOK! 、、、うん、面倒。仕方ないけど。
- 23. まとめ
● これまでの障害の紹介
○ ‘16/9/15 DNS 障害 (全世界)
○ ‘17/3/8 ストレージ障害 (東日本)
○ ‘17/3/31 ストレージ障害 (東日本, 西日本)
● システム構成部分ごとの障害対策
○ Storage / Redis … 冗長構成 / 接続文字列変更の仕組み用意
○ Cloud Service / VM … デプロイし直しが基本 / Managed Disk 併用
○ Database … 冗長構成 / スケールに注意
● その他
○ ペア リージョンについて
○ SLA / インシデント時の問い合わせ手順