Application Migration Service のカットオーバーまたはテスト起動後の EC2 Windows インスタンスでのインスタンスステータスチェックの失敗をトラブルシューティングする方法を教えてください。

簡単な説明

システムまたはインスタンスのステータスチェックが失敗すると、EC2 インスタンスにアクセスできなくなります。Application Migration Service を使用してカットオーバーまたはテスト起動を行った後、次の 1 つ以上の問題が原因でインスタンスのステータスチェックが失敗する可能性があります。

• オペレーティングシステム (OS) の起動に失敗
• ネットワーク障害
• CPU とメモリの枯渇
• 変換プロセスに関する問題
• インスタンスタイプは OS と互換性がありません

**メモ:**Windows が AWS 仮想ハードウェアに適応するため、Windows マシンの初回起動には最大 45 分かかる場合があります。

解決方法

ソースマシンが、起動テンプレートで選択したインスタンスタイプと互換性があることを確認します。

1.    ソースマシンに接続します。

2.    OSのバージョンを確認するには、次のいずれかの方法を使用してください。

[コントロールパネル]、[システム設定] を選択し、Windowsエディションとシステムタイプを確認して、32 ビットか 64 ビットかを確認します。

または

管理者として、コマンドプロンプトウィンドウでsysteminfo コマンドを実行します。コマンド出力には、OS名とシステムタイプが一覧表示されます。

3.    インスタンスタイプの互換性を確認してください。

32 ビットのソースマシン

ソースインスタンスが 32 ビットマシンの場合は、次のインスタンスタイプのいずれかを使用します。

• t2.nano
• t2.micro,
• t2.small
• t2.medium
• c3.large
• t1.micro
• m1.small
• m1.medium
• c1.medium

64 ビットマシン

ソースマシンが 64 ビットで、次の Windows エディションのいずれかを実行している場合は、XEN インスタンスタイプに移行します。

• Windows Server 2003
• Windows Server 2003 R2
• Windows Server 2008

XEN インスタンスタイプの詳細なリストについては、次の AWS Command Line Interface (AWS CLI) コマンドを実行してください。

aws ec2 describe-instance-types --filters Name=hypervisor,Values=xen --query InstanceTypes[].InstanceType

**メモ:**AWS CLI コマンドの実行中にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください。

ソースマシンが 64 ビットで Windows Server 2008 R2 以降を実行している場合は、Windows と互換性のある任意のインスタンスタイプを使用できます。

トラブルシューティング

ソースマシンでサードパーティ製アンチウイルスをオフにするか削除する

サードパーティのウイルス対策ソフトウェアが変換処理を妨げる可能性があります。ウイルス対策ソフトウェアをオフにするか、削除してから、ターゲットの起動を再試行してください。

セカンダリ ENI を接続します

サードパーティのファイアウォールがインスタンスのプライマリネットワークアダプタの接続をブロックし、ターゲットインスタンスがステータスチェックに失敗する可能性があります。この問題を回避するには、セカンダリ Elastic Network Interface をターゲットインスタンスにアタッチしてから、インスタンスに接続します。

さまざまなインスタンスタイプを使用する

XEN インスタンスは準仮想化ドライバー (PV)を使用し、Nitro インスタンスはAWS Elastic Network Adapter (ENA)とAWS NVMEドライバーを使用します。各インスタンスタイプが使用するドライバーのリストについては、「ネットワークとストレージ機能の概要」を参照してください。

前のセクションの手順に従って、ソースマシンがリストされている両方の Windows インスタンスタイプと互換性があるかどうかを判断します。ソースマシンが両方に対応している場合は、XEN インスタンスと Nitro インスタンスを使用してターゲットを起動してみてください。ターゲットインスタンスが 1 つのインスタンスタイプではステータスチェックに合格し、他のインスタンスタイプでは合格しなかった場合は、インスタンスのサイズを変更して成功するかどうかを確認します。問題がドライバーに関連している場合は、AWS Systems Manager Automation ランブックAWSupport-UpgradeWindowsAWSDrivers を実行して、ドライバーを強制的にインストールしてください。

または、他の EC2 Windows インスタンスと同様に、ターゲット起動のハーフステータスチェックをトラブルシューティングします。詳細については、ステータスチェックに失敗したインスタンスのトラブルシューティングを参照してください。

インスタンスログを確認する

新しいインスタンスがステータスチェックに合格しない場合は、インスタンスログを確認して原因を特定します。ログは、インスタンスステータスチェックの失敗の考えられる原因をトラブルシューティングするのに役立ちます。次のすべてのログがターゲットインスタンスに存在しない可能性があります。

• C:\Program Files (x86)\AWS Replication Agent\migrate_script.log
• C:\Program Files (x86)\AWS Replication Agent\migrate_script.log.sent
• C:\Program Files (x86)\AWS Replication Agent\aws_nvme\awsnvme_dism.log
• C:\Program Files (x86)\AWS Replication Agent\ena_2012R2_2016\ena_dism.log
• C:\Program Files (x86)\AWS Replication Agent\PVinstall.log
• C:\Windows\inf\setupapi.dev.log
• C:\Windows\inf\setupapi.offline.log
• C:\Program Files (x86)\AWS Replication Agent\SSMInstall.log

ログにアクセスするには、次の手順を実行します。

1.    ターゲットインスタンスを停止します。

**メモ:**インスタンスを停止すると、一部のデータが失われます。詳細については、インスタンスを停止するとどうなるかを参照してください。

2.    停止したインスタンスから Amazon Elastic Block Storage (Amazon EBS) ルートボリュームをデタッチします。

3.    セカンダリドライブとしてアクセスできるインスタンスに EBS ルートボリュームをアタッチし、使用できるようにします。

4.    上記のリストにある場所のログを収集します。ログを確認して、インスタンスステータスチェックの失敗の原因として考えられるものがないかどうかを確認します。

**メモ:**この方法を使用する場合、(C:\ ではなく) セカンダリドライブを使用しているため、ドライブ文字のマッピングがリストされているログの場所と異なる場合があります。

前述のトラブルシューティング手順で問題が解決しない場合は、AWS サポートにケースを作成してください。

関連情報

ステータスチェックに失敗したインスタンスのトラブルシューティング

システム情報 (マイクロソフトの Web サイトから)