接続できないEC2へのトラブルシューティング記録【Windows】

記事タイトルとURLをコピーする

こんにちは、クラウドインテグレーション部 技術1課 宮形 です。

自分はなんでも手を動かさないと覚えられないタイプなので、AWS においても日々手を動かして検証・確認することを心掛けています。

そんな私ですが、先日いつものように AWS を検証をしていたところ、EC2 の起動エラーが表示され接続できなくなり、ヒヤリ(汗)としました。 その時のトラブルシューティングした内容をBLOGで紹介したいと思います。

EC2 起動エラーについて

「ステータスチェック:1/2のチェックに合格しました。」というエラーが出ました。

f:id:swx-miyagata:20220105114109p:plain

「合格しました」というわりには、ずいぶんの物々しい表記です。OSは Windows Server 2016 です。 案の定、リモートデスクトップで入れませんし、ping も応答ありません。セキュリティグループやルートテーブルを何度も見直しましたが、不備は見つかりません。

ステータスチェックのタブを開くと、下記のようになっていました。システムステータスは問題無いが、インスタンスステータスが問題のようです。

f:id:swx-miyagata:20220105114231p:plain

実はこの EC2 は、当社ラボで動いていて EC2 の AMI (Amazon マシンイメージ:EC2 仮想マシンの複製) から作成した EC2 です。いわゆるクローンです。AMI を取得する時点では、複製元の EC2 は問題なく動いており、接続もできていました。

EC2 を再起動してみたり、AMI から再作成してみたりしますが、いっこうに解決する気配がありません。

問題切り分け

サーバーエンジニアの方がこの状況に遭遇すると、先ず確認する点は「OS が起動しているのか否か」ではないでしょうか。 オンプレミスの物理サーバーであれば、コンソールモニターをみて調べます。仮想サーバーでしたら vSphere コンソール等からみて調べるのが一般的かと思います。

AWS ではシリアルコンソールとして EC2 の OS へ直接接続する方法が提供されております。今回は利用しませんでしたが、状況によっては役立つと思われます。

EC2 シリアルコンソールに接続する - Amazon Elastic Compute Cloud

とりあえずデフォルト設定でも利用できる「スクリーンショット」を試しました。AWSマネージメントコンソールより、 対象 EC2 を選択し、「モニタリングとトラブルシューティング」>「インスタンスのスクリーンショットを取得」をクリックします。

f:id:swx-miyagata:20220105114935p:plain

すると、下記のような画面が表示されました。

f:id:swx-miyagata:20220105115032p:plain

『え?動いている?』Windows Server 2016 のログイン画面が表示されているではありませんか。

サーバーエンジニアの方ですと、次の切り分けとして OS がネットワークに繋がっているか確認するのではないでしょうか。 ただ、残念ながらこのスクリーンショットの画面から OS の操作はできないので、確認できるのはここまでです。

次に私は OS のログをみたいと思いました。Windows ですので イベントビューアー の出番となります。

操作ができない OS のイベントビューアーをみるために、私が行ったのは「ディスクを抜き取り、正常に動いている別の EC2 に引っ付ける」ことです。下記のように行いました。

「EC2」>「ボリューム」の画面より、トラブルの EC2 の rootディスクとなる EBS を選択し、「アクション」>「スナップショットの作成」 をクリックします。

f:id:swx-miyagata:20220105115627p:plain

スナップショットに任意の名前を設定し「スナップショットの作成」を行います。

f:id:swx-miyagata:20220105115716p:plain

つづけて、「EC2」>「スナップショット」の画面より、今ほど作成したスナップショットを選択し、 「アクション」>「スナップショットからのボリュームを作成」をクリックします。

f:id:swx-miyagata:20220105115829p:plain

設定はデフォルトから変更せず「ボリュームの作成」を行います。これで、トラブルの EC2 の rootディスクのコピーが出来ます。

f:id:swx-miyagata:20220105115930p:plain

つづけて、「EC2」>「ボリューム」の画面より、今ほど作成された EBS を選択し、「アクション」>「ボリュームのアタッチ」をクリックします。

f:id:swx-miyagata:20220105120122p:plain

正常に動いている別 EC2 のインスタンスIDを選択し、「ボリュームのアタッチ」を行います。

f:id:swx-miyagata:20220105120305p:plain

正常に動いている別 EC2 で、ディスクが認識していることを確認します。今回の問題切り分けでは OS で 自動的にマウントされ、エクスプローラーに追加ドライブD として表示されました。 問題なく開くこともできます。EBS に問題がある可能性は低そうです。

f:id:swx-miyagata:20220105120357p:plain

追加したディスクはDドライブになりました。ここからイベントビューアーを見ていきます。 D:\Windows\System32\winevt\Logs 配下に実態となる EVTX ファイルが格納されております。 ダブルクリックで開きます。

f:id:swx-miyagata:20220105120452p:plain f:id:swx-miyagata:20220105120514p:plain

このようにトラブルの EC2 のイベントビューアーをみることができました。 もしSTOPエラー(BSOD:ブルースクリーン)系のトラブルであれば、Bugcheck を探したり、設定によってはメモリーダンプが吐かれているので調査に利用できると思います。

イベントビューアーをみたのですが、結局トラブルの原因はわかりませんでした(涙)。 ただ、ネットワークに繋がっていないようなメッセージが出ていたので、これが解決のヒントになりました。

私は『VPC 内での DHCP でのIPアドレス割り当てに問題があるのでは?』と推測しました。 ためしに、トラブルの EC2 に ENI (Elastic Network Interface) を追加で割り当てしました。

f:id:swx-miyagata:20220105120903p:plain f:id:swx-miyagata:20220105120929p:plain

作成した ENI を選択して「アクション」>「アタッチ」をクリックします。 インスタンスIDを選択して「アタッチ」をします。

f:id:swx-miyagata:20220105121100p:plain

トラブルの EC2 に2つ目のIPアドレスが割り当てられましたので、このIPアドレスに対して同一VPC内の EC2 からリモートデスクトップを試みます。

f:id:swx-miyagata:20220105121141p:plain

すると、無事 EC2 へログインできました。

f:id:swx-miyagata:20220105121242p:plain

トラブルの原因

OS のイーサーネットの設定を確認すると、固定IPアドレスが設定されていることがわかりました。 本来 EC2 の OS 上からIPアドレスを設定することは、トラブルの元なので避けるべきです。 社内検証を行った時の設定が残っていたためのようでした。DHCPの自動取得へ変更します。

f:id:swx-miyagata:20220105121918p:plain f:id:swx-miyagata:20220105121954p:plain

EC2 に対して、本来IPアドレスでの ping やリモートデスクトップが可能となり無事解決となりました。 AWSマネージメントコンソール上からもステータスチェックのエラーがなくなりました。 問題切り分けのために追加した EBS スナップショットや ENI は忘れずに削除しておきます。

f:id:swx-miyagata:20220105122103p:plain

あとがき

BLOGの内容としては、私が行ったトラブルシューティングの一例ですが、同じトラブル症状になった方がご覧になり解決の参考になれば幸いです。

クラウド上のサーバーに接続できなくなると、何から手を付けてよいかわからず不安になりますよね。 AWS にはトラブルシューティングするための機能や手法がいろいろありますので、使い方を覚えておいて、イザという時に迅速に問題解決できるようにしておきたいと思いました。

宮形純平(執筆記事の一覧)

クラウドインテグレーション部 技術1課

好きなお酒は缶チューハイと本格焼酎