#はじめに
2020年10月22日、AWS東京リージョンに障害が起こり、Single AZ環境で利用しているAWS FSxが急遽接続不可になりました。慌ててサポートに確認したところ、FSxでは直接EC2との疎通接続に関するメトリクス、または障害を示すメトリクスがないようです。それで、私はEC2からFSxへの死活監視方法を考案してみました。
ちなみに、いままで私が遭ったEC2からFSxへの接続不可は2種類あります。
１．Microsoft ADパスワード有効期間切れによるアクセス不可
２．AWSリージョン障害によるアクセス不可
どちらもアクセス不可ですが、アクセス不可になる時点で、いちはやく障害を把握したく、通知を実現するため、下記のような監視方法を考えました。
#構成図
下記は構成図となります。ちょっと長く描きましたが、各プロセスをできるだけ細かく表示したいからです。
下記簡単な全体説明です。
１．FSx疎通確認スクリプトを作成し、EC2に格納します。
スクリプト内容はEC2からFSxへのファイル共有ポートに対する接続確認コマンドです。
２．EC2側Windowsの機能であるタスクスケジューラに、上記で書いたスクリプトを5分毎に実行させるよう登録します。
３．CloudWatch Agentの設定で、スクリプトで出力されたログファイルを、CloudWatch Logsに出力させるように設定します。
４．CloudWatchのメトリクスフィルター機能で、接続不可時のエラーログをフィルター設定をし、メトリクスフィルターをAWS SNSと組み合わせて、アラームをメールに発砲させます。
#１．FSx疎通確認スクリプト作成
作成した疎通確認スクリプトは下記となります。スクリプトをEC2に格納します。
@echo off
set yyyy=%date:~0,4%
set mm=%date:~5,2%
set dd=%date:~8,2%
set time2=%time: =0%
set hh=%time2:~0,2%
set mn=%time2:~3,2%
set ss=%time2:~6,2%
echo %yyyy%/%mm%/%dd%/%hh%:%mn%:%ss% Test Environment FSx Connection Result > FSxConnectLog.log
rem ------FSx connect test script-------
powershell -NoProfile -ExecutionPolicy Unrestricted -Command "& { Test-NetConnection <FSxのDNS名> -Port 445 }" >> FSxConnectLog.log
スクリプト説明：
・Test-NetConnection PowerShell コマンドレット を使用した疎通確認です。
もし接続OKの場合は、下記のようなメッセージが返してくれます。
XXXX/XX/XX/XX:XX:XX Test Environment FSx Connection Result
ComputerName : <FSｘのDNS名>
RemoteAddress : <FSｘのIPアドレス>
RemotePort : 445
InterfaceAlias : Ethernet 3
SourceAddress : <ローカルのIPアドレス>
TcpTestSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : True
もし接続NGの場合は、下記のようなメッセージが返してくれます。
XXXX/XX/XX/XX:XX:XX Test Environment FSx Connection Result
WARNING: TCP connect to (<FSx IP Address> : 445) failed
WARNING: Ping to <FSx IP Address> failed with status: TimedOut
ComputerName : <FSｘのDNS名>
RemoteAddress : <FSｘのIPアドレス>
RemotePort : 445
InterfaceAlias : Ethernet 3
SourceAddress : <ローカルのIPアドレス>
PingSucceeded : False
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False
これらのコマンドの実行結果を出力し、ログをEC2に溜まらないように、上書き方式でFSxConnectLog.logに格納していきます。
なぜ上書き方式を採用するかの理由は二つあります。
１．もしログを上書きをしない場合は、スクリプトが長くEC2に置いておくと、大量なログが発生してしまい、ドライブに溜まり続けてしまいそうからです。
２．CloudWatch Agentを利用し、出力されたFSxConnectLog.log内容をリアルタイムでCloudWatch Logsへ転送できるからです。なので、ログをEC2上に置く必要がありません。代わりにAWS CloudWatch Logsに置くことにしました。
CloudWatch Logs上に接続不可時のログを観測しましたら、SNSと連携し、アラームメールを発砲するプロセスです。詳細は下記に書いていきます。
※展開：その他に状態を監視する方法としては、describe-file-systems CLI/DescribeFileSystems API の出力結果：Lifecycle にてファイルシステムのステータスを確認することも可能です。今回は割愛させていただきます。
#２．スクリプトをタスクスケジューラに登録
上記作成したスクリプトを、Cドライブ配下のフォルダに格納します。
タスクスケジューラに登録していきます。
下記は「全般」の設定です。
下記は「トリガー」の設定です。
今回は5分間隔で設定しましたが、要件によっては1分間も変更できます。
下記は「操作」の設定です。
「プログラムノスクリプト」欄にスクリプトにある場所を選択します。
「開始」欄にスクリプト所在のフォルダ場所を記入します。
下記は「条件」の設定です。
下記は「設定」の設定です。
これでタスクスケジューラの登録が完了致しました。
5分後に、タスクスケジューラが確実にスクリプトを実行したかどうかを確認した結果、無事に実行され、ログを吐き出してくれました。
#３．CloudWatch Agent のパラメーターストア更新
EC2には既にCloudWatch Agentをインストールしており、本手順ではCloudWatch Agentのインストール方法は割愛させていただきまが、後日に公開します。
CloudWatch AgentはEC2上のログを、CloudWatch Logsへ収集することが出来ます。
AWS Systems Managerのパラメーターストアで、CloudWatch Agentのログ取得をする際のコンフィルファイルを定義しています。そこで上記の吐き出してくれるFSxConnectLog.logファイルを追加していきます。
「file_path」にログファイル所在のパスを記入します。
「log_group_name」はCloudWatch Logs上のロググループネームを定義します。
「log_stream_name」はCloudWatch Logsの「log_group_name」中に所属しているストリームネームを定義します。
{
"file_path": "C:\\FSx Monitoring\\FSxConnectLog.log",
"log_group_name": "XXXXXX-FSxConnect",
"log_stream_name": "FSxConnectLog"
},
全体は下記のようにログファイルパスを追加していきます。
パラメーターストアに修正が完了しましたら、今度はAWS Systems ManagerのRun Commandで、修正したコンフィルファイルを、EC2に更新をかけていきます。
（手順はここで省きますが、後日CloudWatch Agent実装手順公開する際に合わせて紹介予定）
下記はRun Commandで実行成功の画面です。
次はFSxConnectLog.logのログが、CloudWatch Logsに転送できているかどうかを確認します。
下記のようにログイベントがストリーム形式で出力されていれば、成功です。
#４．CloudWatch メトリクスフィルターでログをフィルター
上記「１」で書いてあるように、EC2からFSxへ接続成功時には「True」の文言を返してきますが、もしEC2からFSxへ疎通不可の場合は、ログに「False」文言が出現します。
つまり、接続不可時に「False」文言が出現するため、「False」文言をターゲットに、ログのフィルター設定を行います。
詳細の設定手順はここで省きますが、下記のようにフィルターパターンに「False」文言をターゲットとして追加しました。
メトリクスフィルター設定後に、CloudWatch Alarmに追加し、AWS SNSサービスを連携しました。
#５．確認テスト
わざとFSxConnectLog.logログに、「test-False」文言を入れました。その後すぐにCloudWatch Logs上に反映することができました。
すぐアラーム状態であることが観測できました。
合わせてアラームメールも発砲されました。これで成功です。
#６．考案：不足点
スクリプトは一定程度の監視はできますが、完璧な死活監視はできません。
現在作成したスクリプトは、EC2からFSxへの接続確認コマンドに基づいて、定期実行のスクリプトとなっております。
EC2からFSxへの接続には、中間に多くのサービスと関連付けしております。
例えばMicrosoft AD、OS側のユーザー認証などです。
もし万が一、全環境に予期せぬエラーがございましたら、スクリプトでは疎通確認が取れないと誤認識をしてしまい、メールに誤報を送信してしまう可能性はございます。
つまり、実際EC2からFSxへのアクセスは正常ではあるが、スクリプトではアクセスできないという誤認識をしうる可能性がございます。
その点については、少し不足点であると思います。
#７．最後に
長く書きましたが、この案で実施すると、CloudWatch周りの知識が必要とされます。
CloudWatchの使い方について、今後手順を公開します。
EC2からFSxへの死活監視機能について、ぜひAWS社が追加してほしいです。。。