[小ネタ]StatusCheckFailedのテスト方法(Windows、Linux)

EC2インスタンスのステータスチェックでのテスト方法を纏めてみました。

StatusCheckFailed

EC2インスタンスのステータスでは、AWSシステム側の障害やOS側の一部の障害を起点にアクション(復旧、再起動)を設定できます。この起点となるのステータスが2種類あります。

システムステータスのチェック

EC2インスタンスが起動するAWSシステム(物理)を監視しています。AWSシステムの異常(以下、例)を検知するとステータスが不合格として表示されます。また、CloudwatchメトリクスのStatusCheckFailed_Systemでカウントされます。

• ネットワーク接続の喪失
• システム電源の喪失
• 物理ホストのソフトウェアの問題
• ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

ステータスチェックに基づくアラームアクションを設定するときは、復元(EC2 Auto Recovery)を選択します。EC2インスタンスが稼働していたホスト以外で復元させる為です。なお、復元アクションは、システムステータスチェックだけ選択可能なアクションです。

インスタンスステータスのチェック

EC2インスタンスの異常(以下、例)を検知するとステータスが不合格として表示されます。また、CloudwatchメトリクスのStatusCheckFailed_Instanceでカウントされます。

• システムのステータスチェックの失敗
• ネットワークまたはスタートアップの設定が正しくない
• メモリの枯渇
• 破損したファイルシステム
• 互換性のないカーネル

インスタンスステータスはAWSシステム側の異常ではない為、ステータスチェックに基づくアラームアクションを設定するときは、再起動を選択します。

テストできるのはインスタンスステータスのチェック

前提としてテストできるのは、インスタンスステータスのチェックのみです。システムステータスのチェックはAWSシステム側のステータスなので私たちでどうやってもステータスをいじることができません。AutoRecoveryを設定するCloudwatchアラームで設定するシステムステータスチェックのメトリクスの閾値を調整してアラームを発生させることができますが、復元アクションはキャンセルしたとAWSから[Auto Recovery] Amazon EC2 instance recovery: No action taken [AWS Account: AWSアカウントID]という件名でメールが通知されます。

本文には、アクション実行前にAWSシステムを再検証した上でAWSシステムは正常と判断したからAutoRecoveryしないと書かれていました。Cloudwatchアラームを意図的にアラーム状態にした場合などは上記の通り正常と判断するとのことです。

執筆時点ではシステムステータスチェックのテストをJIS元する方法がありません。なのでインスタンスステータスチェックのテスト方法を紹介してきます。

インスタンスステータスのチェックによるテスト方法

StatusCheckFailed_Instanceで設定するアクションは、Cloudwatchアラームで設定します。Cloudwatchアラームを発生させる方法として

1. メトリクスの閾値を調整する
2. OS側でNICを無効化する

いずれかでテストできます。ただし「1.」はインスタンスステータスのチェックというよりCloudwatchアラームのアクションを確認するという意味なので「2.」でインスタンスステータスを不合格とするテスト方法をご紹介します。

Linux

Amazon Linux2をベースにご紹介します。

EC2インスタンスでAmazon Linux 2を起動してStatusCheckFailed_InstanceでCloudwatchアラームを作成しておきます。

上記の通り、ステータスチェック、アラームの状態が正常な状態であればOKです。

EC2インスタンスにログインし、NICを無効にします。

$ sudo ifdown eth0

NICを無効にするとログインセッションは何も操作できなくなります。EC2コンソールを見てみるとステータスチェック、アラームの状態が異常な状態であることが確認できます。

Cloudwatchアラームの履歴を見るとステータスがアラーム状態に変わった後、アクションが実行されています。

再び、EC2コンソールを見てみるとステータスチェック、アラームの状態が正常な状態戻っています。

EC2インスタンスにアクセスするとログインすることができます。Linux全般はインターフェイスの有効化はeth0などの設定ファイル内でONBOOT=yes|noで制御しているのでのがほとんどですが、アクセスできなくなった場合は、ネットワークインターフェイスを追加でアタッチすると自動でUPされます。万が一アクセスできなくなる場合も考えてAMIバックアップを取得してからテストすることを推奨します。

Windows

Windows2019で試してみます。

EC2インスタンスでWindows2019を起動してStatusCheckFailed_InstanceでCloudwatchアラームを作成しておきます。

EC2インスタンスにログインします。Linuxと違う点としてWindowsはDisable(無効)にしないとNICを停止できません。DisableはOS起動で自動で有効化されないたい為、OS起動時にNICを有効にするスクリプトを実行する必要があります。

任意の場所にNICを有効にするps1ファイルを作成します。内容は以下の通りです。

Enable-NetAdapter -Name "Name" -Confirm:$False

-Confirm:$Falseで対話形式によるコマンド要求確認を無効にします。"Name"は、Get-NetAdapterで表示されるNameに読み替えて修正してください。

ps1ファイルを用意できたらタスクスケジューラを登録します。インポート用のxmlファイルを用意しました。

enable-adapter.xml
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <URI>\enable-adapter</URI>
  </RegistrationInfo>
  <Triggers>
    <BootTrigger>
      <Enabled>true</Enabled>
    </BootTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>C:\Windows\System32\cmd.exe</Command>
      <Arguments>/C C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Unrestricted -File "C:\script\enable-netadapter.ps1"</Arguments>
    </Exec>
  </Actions>
</Task>

39行目のps1ファイルパスは環境に併せて修正してください。

タスクスケジューラを起動し、タスクのスケジューラライブラリに移動してタスクのインポートをクリックしてxmlファイルを開きます。

ここのポイントはタスク実行時のユーザーはSYSTEMを指定しています。パスワードが指定不要なのでSYSTEMで実行します。

これで準備が整いました。PowershellからNICを無効にしてみます。

Disable-NetAdapter -Name "Name" -Confirm:$False

EC2コンソールを見てみるとステータスチェック、アラームの状態が異常な状態であることが確認できます。

Cloudwatchアラームの履歴を見るとステータスがアラーム状態に変わった後、アクションが実行されています。

EC2コンソールを見てみるとステータスチェック、アラームの状態が正常な状態戻っています。

再度、EC2インスタンスにログインできること確認できたらテスト完了です。

ネットワークが正常にならない場合

Linux、WindowsどちらもAMIバックアップを取得してから実行いただくのが安全ですが、もしAMIバックアップを取得していなくてネットワークが正常にならない場合は、EC2でネットワークインターフェイスを作成し、アタッチするとOS側で自動でNICを有効にしてくれます。今回確認したAmazon Linux2、Windows2019は追加のネットワークインターフェイスが自動で有効化されました。

まとめ

今回のポイントを纏めました。

• システムステータスチェックのテストはできない
• NICをダウンさせる前にAMIバックアップの取得を推奨
• Windowsは無効化した後は有効化する必要がある
• どうしようもないときはENIをアタッチしてみる

EC2インスタンスのステータスによる復旧テストを実施する際の参考になれば幸いです。