トラブルから学ぶAzure世渡り術

(全46枚)

2014/09/20

JAZUG 4周年総会

• 足利 惟 (Ashikaga Yui)

• 株式会社システムコンサルタント勤務 • 2009年からAzureやってるSIerです • Azureコンサルティングパートナー認定第一号 • Azureシステムのインフラ設計、構築、新機能の技術検証

• Twitter : @yuiashikaga • 趣味：カメラ (PENTAX K-5所有) • 9/11 第一子が産まれました！

http://www.microsoft.com/ja-jp/casestudies/movieticket.aspx

http://www.microsoft.com/ja-jp/casestudies/kinkos.aspx

課金編 サービス・環境編 番外編

課金編

• 開発時のお話 • 開発用に複数のサブスクリプションを管理 • 毎月Azureから発行される請求書の金額と クレジットカード会社から来る明細の管理をしている

• ちなみに今はEA契約なので、管理からは解放

• 相変わらずサブスクリプションの管理はしている・・・

• クレジットカードの請求額と請求書合計に差異があると経理から指摘が

• 調べてみると2012年5月の請求において、請求書上に記載されている(ポータル上で確認できる）金額と、実際に引き落とされている金額に差異がある

• 請求書再発行してもらえ (ﾟДﾟ)ｺﾞﾙｧ!

事象

• 課金サポートとやりとり

• 請求書の再発行を求めたが、再発行はシステム上無理

• 結局、経理に説明し納得してもらう

対応

• うるう年のサービス障害により、2012/2/29、2012/3/1が含まれている請求期間の請求額より33％のクレジット額を5月に適用

• 請求書発行後にクレジット額が適用された事により、実際に引き落とされる額に適用されてしまった

• 結果、請求書表記金額とクレジットカードへチャージされた金額に差異が生じた

原因

• クレジットカード請求書に記載されているAzure請求書番号-金額のペアと請求書に記載されている請求書番号が合致しない

• 請求金額は合っているが、該当の請求書番号が見つからない

• どうなってるんだ！！請求書再発行してもらえ (ﾟДﾟ)ｺﾞﾙｧ!

事象

• 課金サポートとやりとり

• 請求書の再発行を求めたが、再発行はシステム上無理

• 結局、経理に説明し納得してもらう

対応

• 課金システムの不備に起因して発生

• その後、請求書番号がクレジットカード請求書に載らなくなった(なぜ?)

原因

サービス・環境編 クラウドサービス、仮想マシン、仮想ネットワーク

• クラウドサービスではWAD(Azure診断)機能を利用し、各種ログの転送を行っている

• ある日、テーブルストレージへのログ出力が突如止まる

事象

• ストレージの大規模障害が発生した直後ということもあり、プレミアサポートに即連絡

• WADの設定ファイル(Diagnostics.wadcfg)の設定値が原因だったので修正

対応

• 一時ログファイルの量が閾値を超え、出力が自動的に停止 • Azureストレージへ転送する前にローカルストレージにログの中間ファイ

ルが作成される

• 既定の場合、ローカルストレージの最大容量は4096 MB

• 既定の設定の場合、4080 MB を閾値として（16MBの余裕を残して）中間ファイルの削除が行われる

• 一度に16MBを超える中間ファイルが作成され、閾値を超えたためファイル出力/削除の処理が停止した

• bufferQuotaInMBを適正な値に修正することで対応

原因

• 512 MB + 512 MB + 1024 MB + 1024 MB + 512 MB = 3584 MB

• 4096 MB - 3584 MB = 512 MBの余裕を残して中間ファイルを削除

• 一時データを格納する際、クラウドサービスではローカルストレージ領域を作成し、そこに格納

• ある日、クラウドサービス内のローカルストレージ書き込みエラー

事象

Access to the path

'C:¥Resources¥directory¥8a38cea5d1a843e0b3a4baee48f7f47b.XXX.XXXXX.ComTemp¥' is denied.

• 問題となっている事象が1インスタンスのみで発生

• サポートに問い合わせた際、事象が発生する原因として考えられるものを挙げてもらったがどれも該当無し • ロールの起動時にローカルストレージ領域を確保する際の、アクセス権設定処理失敗

• お客様のスタートアップ タスク中の何らかのコードによるアクセス権の上書き設定

⇒ いや、デプロイ後の話だし・・・

対応

• ログ収集ツール「AzureTools」を案内してもらったが、該当インスタンスをVIPスワップ後に消してしまったため、追跡出来ず

• 原因不明で終了

• 次回、同様の現象が発生した際はAzureToolsを使用しログ収集する感じで終了

原因

• インスタンスが生きてる時に使えるツール

• PaaSの各種ログ収集やREST APIが直接叩ける

• ログ収集後、自動的にZip化されるので、サポートに送付

ちなみにAzureToolsとは

http://blogs.msdn.com/b/kwill/archive/2013/08/26/azuretools-the-diagnostic-

utility-used-by-the-windows-azure-developer-support-team.aspx

• クラウドサービスをデプロイする際、ARRのインストールをWebPiCMD経由で行っている

• ある日の夜中、家にいると突然の電話

• デプロイは成功したが、URL書き換えが行われない

(この時は夜中にデプロイする運用だった)

事象

• 対象のクラウドサービスにリモートデスクトップ接続

• WebPiCMDのログを確認すると「External Cache 1.0」のインストールエラーとなっており、ARRがインストールされていなかった

• ブラウザで対象URLを参照、「ページが表示できません」だとーーー！！

• 夜中にプレミアサポートに緊急度Aで問合せ

• サポートとやり取りしているうちに、リンクが復旧

対応

• ARRの依存モジュールのインストールリンクのデータをMSが誤って削除した

原因

• スタンドアローンでのインストーラモジュールを使用

• WebpiがダウンロードするURLはカスタムが可能なので、関連モジュールをストレージに配置しそのURLからダウンロードするようにリンクファイルを修正

対策

• ARRは、お客様が取得した外部DNS経由(xxx.jp)の違うポートにURL書き換えを行う仕様

• ある日、突然ルーティングができなくなる

• 2 インスタンスのうち、1 インスタンスのみで現象が発生

事象

502 - Web server received an invalid response while acting as a gateway or proxy server.

• cloudapp.net(内部DNS)に書き換えルールを変更したところ、正常動作

• その後、原因をプレミアサポート経由で問い合わせ

• AzureToolで事前にログを取得していたので連携

（ログの収集内容は十分との回答を頂く)

対策

• 原因不明

• URL 書き換えのルールの不備やアプリケーションに依存するものではない旨の回答を頂いたが、根本的な解決には至らず

• 現在まで同様の障害は発生していなので、まあOK？

原因

• 仮想マシンを削除したにもかかわらず、利用していたディスクがアタッチされたままに

• 削除して1日たっても仮想マシンが接続されているため、新しい仮想マシンを作成できない

事象

• プレミアサポートへ問い合わせ、速攻でアタッチ解除

対応

• アタッチを解除する部分に何等かの不具合が発生していた

• 対応していた方に聞いたが、この問題は問合せをしない限り解決することは無かった

原因

• ある日の夕方、仮想マシンの動きが突然おかしくなった

• 仮想マシンが知らぬ間に停止している

• リモートデスクトップもつながらない

事象

• プレミアサポートへ問い合わせ、仮想マシンの情報(サブスクリプションID、仮想マシン名等)を連携し障害対象であることが判明

• 他データセンターへの移行も考えたが、徐々に回復していったので待機

対応

• 香港データセンターのストレージの一部でUPSメンテナンス作業の際に必要であった電力の切り替え時に一部のサーバーが正常に復旧していなかった

• 特定リージョンの特定クラスターでエラー

原因

• データセンター内の物理マシンは「クラスター」という単位で分割されている

• 1つのクラスターは約1000台の物理マシンで構成

• 不具合の影響がクラスター内で閉じられるような設計

ちなみにクラスターとは？

@harutamaさんの「2013年版のInside Windows Azure」から引用

ファブリック

コントローラ

ファブリック

コントローラ

クラスター

• 仮想マシンの可用性セットを組んでいてもダメ • 可用性セットは同一クラスタ内の別ラック配置

• 今回はクラスタごと障害が発生

• 今回こそ、ジオレプリの力を発揮する時では！？ • 数日以内にプライマリのデータセンターの復旧が可能との見通し

• このため Geo Failover の実行は行わないという判断

⇒ジオレプリケーションは自動的に行われるが、ジオフェールオーバーは Azure中の人のさじ加減で決まる

※今はRA-GRSがあるので、部分復旧が可能

サポートとのやり取りで分かったこと

• 1があるということは、2もあります

• 某プライベートクラウドとS2S-VPNで接続し、データをやり取りしているが、VPN接続が突然死亡

• 管理ポータルから仮想ネットワークの状況を確認したが、表示上は正常

事象

• 夜中にプレミアサポートに緊急度Aで問合せ

• エラーが発生した際は、ヨーロッパ、アメリカ西部でVPN障害のアナウンスが出ていたが、アジアでは無し

• 対応しているうちに、東アジアでも同様の障害だということがわかり復旧待ちに

• 次の日に代休をもらったのは言うまでもない

対応

• すんません・・・忘れました

原因

• ある日の夕方、再びVPN接続が死亡

• サービスダッシュボード確認⇒オールグリーン

• 管理ポータルの表示確認⇒オールグリーン

• ping, tracert⇒まるで反応なし

• 管理ポータルは当然

事象

• 管理ポータルからゲートウェイの接続解除→再接続で解消

• 障害が発生してないかプレミアサポートに問い合わせ

対応

• VPN ゲートウェイ マネージャーの更新によって発覚したソフトウェアの不具合によるもの

原因

対策

• 以降、VPNの接続を確認するため監視ソフトでping監視を行う

番外編

管理ポータル？ Azure Powershell？

• リソースの整理をしようと、使途不明な仮想マシンをプロジェクトメンバーに案内

• メンバーが仮想マシンの削除を開始

• その際、間違って本番サーバーを削除

• VHDは残っているので再作成すればいいが、その頃内部IPの固定化が無かったためIPが変更

⇒IPで内部アクセスしているところも変更

それ以来、リソースの削除はPowerShellから行うように

まとめ