こんにちは、クラウドインテグレーション部 技術1課 宮形 です。
自分はなんでも手を動かさないと覚えられないタイプなので、AWS においても日々手を動かして検証・確認することを心掛けています。
そんな私ですが、先日いつものように AWS を検証をしていたところ、EC2 の起動エラーが表示され接続できなくなり、ヒヤリ(汗)としました。 その時のトラブルシューティングした内容をBLOGで紹介したいと思います。
EC2 起動エラーについて
「ステータスチェック:1/2のチェックに合格しました。」というエラーが出ました。
「合格しました」というわりには、ずいぶんの物々しい表記です。OSは Windows Server 2016 です。 案の定、リモートデスクトップで入れませんし、ping も応答ありません。セキュリティグループやルートテーブルを何度も見直しましたが、不備は見つかりません。
ステータスチェックのタブを開くと、下記のようになっていました。システムステータスは問題無いが、インスタンスステータスが問題のようです。
実はこの EC2 は、当社ラボで動いていて EC2 の AMI (Amazon マシンイメージ:EC2 仮想マシンの複製) から作成した EC2 です。いわゆるクローンです。AMI を取得する時点では、複製元の EC2 は問題なく動いており、接続もできていました。
EC2 を再起動してみたり、AMI から再作成してみたりしますが、いっこうに解決する気配がありません。
問題切り分け
サーバーエンジニアの方がこの状況に遭遇すると、先ず確認する点は「OS が起動しているのか否か」ではないでしょうか。 オンプレミスの物理サーバーであれば、コンソールモニターをみて調べます。仮想サーバーでしたら vSphere コンソール等からみて調べるのが一般的かと思います。
AWS ではシリアルコンソールとして EC2 の OS へ直接接続する方法が提供されております。今回は利用しませんでしたが、状況によっては役立つと思われます。
EC2 シリアルコンソールに接続する - Amazon Elastic Compute Cloud
とりあえずデフォルト設定でも利用できる「スクリーンショット」を試しました。AWSマネージメントコンソールより、 対象 EC2 を選択し、「モニタリングとトラブルシューティング」>「インスタンスのスクリーンショットを取得」をクリックします。
すると、下記のような画面が表示されました。
『え?動いている?』Windows Server 2016 のログイン画面が表示されているではありませんか。
サーバーエンジニアの方ですと、次の切り分けとして OS がネットワークに繋がっているか確認するのではないでしょうか。 ただ、残念ながらこのスクリーンショットの画面から OS の操作はできないので、確認できるのはここまでです。
次に私は OS のログをみたいと思いました。Windows ですので イベントビューアー の出番となります。
操作ができない OS のイベントビューアーをみるために、私が行ったのは「ディスクを抜き取り、正常に動いている別の EC2 に引っ付ける」ことです。下記のように行いました。
「EC2」>「ボリューム」の画面より、トラブルの EC2 の rootディスクとなる EBS を選択し、「アクション」>「スナップショットの作成」 をクリックします。
スナップショットに任意の名前を設定し「スナップショットの作成」を行います。
つづけて、「EC2」>「スナップショット」の画面より、今ほど作成したスナップショットを選択し、 「アクション」>「スナップショットからのボリュームを作成」をクリックします。
設定はデフォルトから変更せず「ボリュームの作成」を行います。これで、トラブルの EC2 の rootディスクのコピーが出来ます。
つづけて、「EC2」>「ボリューム」の画面より、今ほど作成された EBS を選択し、「アクション」>「ボリュームのアタッチ」をクリックします。
正常に動いている別 EC2 のインスタンスIDを選択し、「ボリュームのアタッチ」を行います。
正常に動いている別 EC2 で、ディスクが認識していることを確認します。今回の問題切り分けでは OS で 自動的にマウントされ、エクスプローラーに追加ドライブD として表示されました。 問題なく開くこともできます。EBS に問題がある可能性は低そうです。
追加したディスクはDドライブになりました。ここからイベントビューアーを見ていきます。 D:\Windows\System32\winevt\Logs 配下に実態となる EVTX ファイルが格納されております。 ダブルクリックで開きます。
このようにトラブルの EC2 のイベントビューアーをみることができました。 もしSTOPエラー(BSOD:ブルースクリーン)系のトラブルであれば、Bugcheck を探したり、設定によってはメモリーダンプが吐かれているので調査に利用できると思います。
イベントビューアーをみたのですが、結局トラブルの原因はわかりませんでした(涙)。 ただ、ネットワークに繋がっていないようなメッセージが出ていたので、これが解決のヒントになりました。
私は『VPC 内での DHCP でのIPアドレス割り当てに問題があるのでは?』と推測しました。 ためしに、トラブルの EC2 に ENI (Elastic Network Interface) を追加で割り当てしました。
作成した ENI を選択して「アクション」>「アタッチ」をクリックします。 インスタンスIDを選択して「アタッチ」をします。
トラブルの EC2 に2つ目のIPアドレスが割り当てられましたので、このIPアドレスに対して同一VPC内の EC2 からリモートデスクトップを試みます。
すると、無事 EC2 へログインできました。
トラブルの原因
OS のイーサーネットの設定を確認すると、固定IPアドレスが設定されていることがわかりました。 本来 EC2 の OS 上からIPアドレスを設定することは、トラブルの元なので避けるべきです。 社内検証を行った時の設定が残っていたためのようでした。DHCPの自動取得へ変更します。
EC2 に対して、本来IPアドレスでの ping やリモートデスクトップが可能となり無事解決となりました。 AWSマネージメントコンソール上からもステータスチェックのエラーがなくなりました。 問題切り分けのために追加した EBS スナップショットや ENI は忘れずに削除しておきます。
あとがき
BLOGの内容としては、私が行ったトラブルシューティングの一例ですが、同じトラブル症状になった方がご覧になり解決の参考になれば幸いです。
クラウド上のサーバーに接続できなくなると、何から手を付けてよいかわからず不安になりますよね。 AWS にはトラブルシューティングするための機能や手法がいろいろありますので、使い方を覚えておいて、イザという時に迅速に問題解決できるようにしておきたいと思いました。