- 初版：2018年12月
- 第二版：2019年12月
- 第三版：2019年12月
はじめに
本エントリーはMicrosoft Azure Stack Advent Calendar 2018の20日目です。
先日のエントリでは、Azure Stack Hub を診断する方法をまとめました。本日のエントリでは、異常と判断した後の直し方をまとめます。ただし、OEM ベンダによって修理の方法が異なる可能性があるため、OEM ベンダの責任範囲の部分を割愛します。
問い合わせる
Azure Stack Hub を異常と判断したものの自己解決が不可能な場合、サポートに対応してもらわなければなりません。Azure Stack Hub は、壊れた場所によって問い合わせ先が異なります。Azure Stack Hub というソフトウェアの部分に関する障害であれば、Azure のサポートに問い合わせます。EA サブスクリプションであれば問い合わせ先は Microsoft です。CSP サブスクリプションであれば、問い合わせ先は CSP ベンダのサポート窓口です。ハードウェアの部分に関する障害であれば、Azure Stack Hub を購入した OEM ベンダに問い合わせます。
ログを提供する
サポート担当が障害を調査するためにはログが必要です。Azure Stack Hub には 必要なログを Azure Stack Hub 自身が集めて Microsoft に送付する機能が存在しています。管理者向けのポータルから数クリックするだけで必要なログを Microsoft に提供できます。「このログを取り損ねた・・」「このログはどうやって集めるの・・？」といった困りごとは存在しません。
この機能は Connected な Azure Stack Hub でのみサポートされています。この便利機能を使うためにも、Azure Stack Hub を Connected deployment で導入しましょう。
なお、本機能で取得したログファイルのサイズは数Gバイトになります。取得するのにも時間がかかりますし、サポートに送るのにも時間がかかります。インターネット回線の帯域に注意しましょう。
一緒にトラブルシュートする
Microsoft のサポート担当者は、申告を受けたアラートの内容や受領したログファイルの内容から対応方法を決定します。ただし、対応方法を管理者だけで実施できない可能性があります。なぜなら、Azure Stack Hub が管理者の権限が制限しているためです。管理者に代わってMicrosoft のサポート担当が対応方法を実行しようにも、お客様のデータセンタに設置されている Azure Stack Hub に Microsoft のサポート担当者はアクセスできません。
そこで、障害対応で特権が必要な場合は、Azure Stack Hub にアクセスできる管理者と Microsoft のサポート担当者が連携してトラブルシュートします。具体的には、Teams や LogMeIn などのリモートサポートツールを使って、遠方にいる Microsoft 担当者に Azure Stack Hub を調査・修理してもらいます。具体的には、Microsoft のサポート担当と一緒に Azure Stack の認証認可で解説した方法で PEP を特権に切り替えたうえで、PowerShell を利用して問題を修正します。
リモートで直してもらう
一緒にトラブルシューティングする方法には次のような課題があります。
- 実機での調査や設定変更が必要になるたびに一緒にトラブルシューティングしなければならず Microsoft だけで調査・設定変更ができないため、障害の解決に時間がかかる可能性がある
- トラブルシュート中、Azure Stack Hub Operator が拘束されてしまう
そんな課題を解決するために 2108 Update で導入されたのが、リモートサポートという機能です。リモートサポートを利用すると、発生した障害によっては Microsoft に勝手に調査してもらう、勝手に直してもらうことが可能になります。
Microsoft のサポート担当に Azure Stack Hub をリモートで直してもらう
ハードウェア交換時の注意点
ハードウェアのトラブルでは、従来のサーバと同じように部品を交換します。ただし、部品に応じて Azure Stack Hub 特有の操作が発生します。
ディスク
Azure Stack Hub を構成する Host Node の Disk は、Host Node の OS が動作しているディスクを除いて Storage Spaces Direct で冗長化されています。そのため、ディスクを交換した後に、Storage Spaces Direct のステータスが正常であることを確認する必要があります。RAIDの再構築が終わるのを待つのと同じイメージです。
活性交換できない部品
活性交換できない部品を交換した場合、その Host Node を一から作り直します。「障害の結果どのような状態になったか分からない Host Node をそのまま使い続けるよりも、あるべき姿の Host Node に作りなおすほうが安全だ」という考え方だと思います。作り直す作業は Repair と呼ばれ、ボタンワンクリックで自動で Host Node が作り直されます。
Repair ボタン
全体の流れは、壊れた Host Node をクラスタから切り離して（=Drain）部品を交換、部品交換後にハードウェアとしての正常性を確認、確認出来たら Host Node を作り直して（=Repair ）、作り直した Host Node を再度クラスタに参加させる（=Resume）形です。
まとめ
本日のエントリーでは、Azure Stack Hub の直し方をまとめました。ソフトウェアの部分の修理は「とりあえずログを送って Microsoft のサポートエンジニアに解析してもらい、Microsoft のサポートエンジニアに直してもらう」というパターンになるが多いです。パブリッククラウドにおける「インフラの運用を全部任せられる」というレベルではありませんが、Azure Stack Hub を使えば、Microsoft のサポートエンジニアに仮想化レイヤのトラブルシュートをアウトソースできます。新機能であるリモートサポートが進化していけば、パブリッククラウドに近づいていくでしょう。Azure Stack Hub を利用して差別化要素になりにくいインフラ運用を Microsoft に任せることで、差別化要素に注力できますね。