ここまでで AlwaysOn の環境は構築できましたのでテストの実施方法などを少しまとめてみたいと思います。
Contents
■ネットワークのテスト
AlwaysOn では通常、以下のような用途でネットワークを使用します。
- アプリケーションとの通信
- データ同期のためのミラーリングエンドポイント間の通信
- WSFC のハードビートの通信
ネットワークトラフィックが多い場合には、それぞれの用途で専用のネットワークを用意することもあるかと思います。
現状の Azure VM では、ネットワークは一つしか用意することができません。
そのため上記のトラフィックがすべて一つのネットワークに集中することになります。
Azure のインスタンスはサイズによってネットワークの帯域が異なってきます。
Virtual Machine and Cloud Service Sizes for Windows Azure
ネットワークのテストをする場合にはインスタンスのサイズが AlwaysOn のトラフィックをさばけるかを負荷をかけてテストをするとよいかと思います。
# ミラーリングエンドポイント間のデータ同期のための通信は圧縮された状態で行われているので、実データ変更量がそのまま流れるということはないですが。
通常ですと、ネットワークのテストでは障害テストとしてアダプタを無効にしたり LAN ケーブルを抜いたりするのですが、Azure VM でネットワークを無効にしてしまうと接続ができずに八方ふさがりになってしまいますので障害系のテストは難しそうですね。
■インスタンス障害のテスト
こちらはインスタンスが停止した場合を想定してのテストになります。
Azure のインスタンスはデプロイをした状態では停止していても起動していても課金が発生しますので、停止したままにするというテストは通常必要ないかと思います。
実施しておいたほうがよいパターンとしては、
- Windows Update を実行した際の再起動
- インスタンスのスケールアウトをした際の再起動
- 予期せぬ障害 (BSOD) が発生しての再起動
- 予期せぬ障害が発生してサーバーが応答がなくなる
というところでしょうか。
インスタンスで応答がなくなった、再起動が発生した場合に AlwaysOn のリソースが正常にフェールオーバーされ、サービスを継続できるかを確認しておく必要が出てきます。
Azure VM のメンテナンスは契約者が実施する必要がありますので定期的な修正プログラムの適用を検討する必ようがあります。
Windows Update を実行した際の再起動すると正常にフェールオーバーされるかは確認をしておいたほうがよいかと思います。
また、ホスト OS がアップデートされた場合は Azure VM のインスタンスの再起動が行われる可能性がありますので、通常の再起動のテストもしておくとよいかもしれないですね。
Azure VM は任意のタイミングでスケールアップすることができます。
突発で負荷が上がった時のスケールアップをした場合の再起動についてもテストをしておいたほうがよいかと。
SLA の適用対象とするためには上記の画像のように同一の可用性セットに 2 つ以上のインスタンスを起動しておく必要があります。
スケールアップをする際にインスタンスのサイズを変えようとすると以下のようなエラーが発生します。
同一の可用性セットにした場合は、更新ドメインや障害ドメインが別れ、更新や障害の発生時のダウンタイムを分散させることになりますのでこの辺が考慮されて、排他アクセスのチェックがされるのでしょうね。
2 ノードで構成している場合は、インスタンスのサイズの変更は一台ずつ実施することになりますので、スケールアップされている際にフェールオーバーしサービスが継続できるかのテストをしておくとよいかと思います。
予期せぬシャットダウンのテストですが、ポータルで実施できるシャットダウンは、
Hyper-V マネージャーで実行できる以下のような操作となるかと思います。
シャットダウン / 再起動についてはホスト OS? からゲスト OS に対してシ命令を送る正規の処理になりますので予期せぬシャットダウンの発生とは少し異なります。
# 命令を受け付けなかったら強制的に落としているとは思いますが。
予期せぬ障害を発生させるためには、NotMyFault を使用するとよいかと思います。
このツールを使用することで強制的に BSOD を発生させることができます。
通常の設定ですと自動で再起動されますので、システムの詳細設定の起動と回復から [自動的に再起動する] を無効にしておけばサーバーは稼働しているが OS が応答しない状態を作ることができます。
これらの再起動や応答なしが発生した場合に正常にフェールオーバーが行われるかはサービス員前にテストをしておくとよいかと思います。
デフォルトではフェールオーバーは 6 時間に 1 回の障害で行われる設定になっているかと思いますので、テストを実施する際にはこのエラー数や時間を調整して、複数回フェールオーバーが発生できるようにしておくとよいかと。
このあたりの設定を把握しておかないと、フェールオーバーの上限回数を超えて障害になったのかの判断ができなくなりますので。
Windows Server 2012 で 2 ノードクラスターを組んだ場合は、Dynamic Node Weight による投票の動的管理になりますのでプライマリサーバーが予期せぬ障害が発生した場合にどのような挙動になるかは確認をしておくとよいと思います。
AlwaysOn は AD が必須ですので、動的な投票数調整で想定しているフェールオーバーにならない場合 (投票数が調整できず過半数に満たないためにクラスターを確立できない) には、AD に共有フォルダを作成して、ファイル共有監視を使用することを検討してもよいかもしれないですね。
AlwaysOn は耐障害性を高める目的で使用することが多いと思います。
どのような障害が発生したらフェールオーバーをするかは事前に確認をしておくといざというときに困らないかと。