一般的なトラブルシューティング

このページでは、Compute Engine インスタンスの使用中に問題が発生した場合に役立つトラブルシューティング手順について説明します。

インスタンスに関する一般的な問題のトラブルシューティング

インスタンスが起動しない場合

永続ブートディスクが起動しない場合のヒントをいくつかご紹介します。

  • 仮想マシン インスタンスのシリアルポート出力を確認する。

    インスタンスの BIOS、ブートローダー、カーネルは、インスタンスのシリアルポート出力にデバッグ メッセージを出力します。そこには、インスタンスで発生したエラーや問題に関する貴重な情報が含まれています。Stackdriver へのシリアルポート出力ログを有効にすると、インスタンスが実行されていない場合でも、この情報にアクセスできます。シリアルポート出力の表示をご覧ください。

  • シリアル コンソールへのインタラクティブ アクセスを有効にする。

    インスタンスのシリアル コンソールへのインタラクティブ アクセスを有効にすると、インスタンスが完全に起動しなくても、インスタンスにログインして起動の問題をデバッグできます。詳しくは、シリアル コンソールとのやり取りをご覧ください。

  • ディスクに有効なファイル システムがあることを確認する。

    ファイル システムが破損しているなど、有効でない場合は、インスタンスを起動することはできません。ディスクのファイル システムを確認します。

    1. 問題のディスクを接続先のインスタンスから接続解除します(該当する場合)。

      gcloud compute instances delete old-instance --keep-disks boot
      
    2. Google が提供する最新のイメージを使用して新しいインスタンスを作成します。

      gcloud compute instances create debug-instance
      
    3. 問題のディスクを非ブートディスクとして接続します。マウントはしないでください。次の例の DISK を問題のディスクの名前に置き換えます。ここでは、ディスクをインスタンスで簡単に識別できるようにデバイス名も指定しています。

      gcloud compute instances attach-disk debug-instance --disk DISK --device-name debug-disk
      
    4. インスタンスに接続します。

      gcloud compute ssh debug-instance
      
    5. ディスクのルート パーティションを見つけます。part1 と記載されているのがルート パーティションです。この例では、ディスクのルート パーティションは /dev/sdb1 にあります。

      user@debug-instance:~$ ls -l /dev/disk/by-id
      total 0
      lrwxrwxrwx 1 root root  9 Jan 22 17:09 google-debug-disk -> ../../sdb
      lrwxrwxrwx 1 root root 10 Jan 22 17:09 google-debug-disk-part1 -> ../../sdb1
      lrwxrwxrwx 1 root root  9 Jan 22 17:02 google-persistent-disk-0 -> ../../sda
      lrwxrwxrwx 1 root root 10 Jan 22 17:02 google-persistent-disk-0-part1 -> ../../sda1
      lrwxrwxrwx 1 root root  9 Jan 22 17:09 scsi-0Google_PersistentDisk_debug-disk -> ../../sdb
      lrwxrwxrwx 1 root root 10 Jan 22 17:09 scsi-0Google_PersistentDisk_debug-disk-part1 -> ../../sdb1
      lrwxrwxrwx 1 root root  9 Jan 22 17:02 scsi-0Google_PersistentDisk_persistent-disk-0 -> ../../sda
      lrwxrwxrwx 1 root root 10 Jan 22 17:02 scsi-0Google_PersistentDisk_persistent-disk-0-part1 -> ../../sda1
      
    6. ルート パーティションでファイル システム チェックを実行します。

      user@debug-instance:~$ sudo fsck /dev/sdb1
      fsck from util-linux 2.20.1
      e2fsck 1.42.5 (29-Jul-2012)
      /dev/sdb1: clean, 19829/655360 files, 208111/2621184 blocks
      
    7. ファイル システムをマウントします。

      user@debug-instance:~$ sudo mkdir /mydisk
      
      user@debug-instance:~$ sudo mount /dev/sdb1 /mydisk
      
    8. ディスクにカーネル ファイルがあることを確認します。

      user@debug-instance~:$ ls /mydisk/boot/vmlinuz-*
      /mydisk/boot/vmlinuz-3.2.0-4-amd64
      
  • ディスクに有効なマスター ブートレコード(MBR)があることを確認する。

    永続ブートディスクが接続されたデバッグ インスタンス(/dev/sdb など)で次のコマンドを実行します。

    $ sudo parted /dev/sdb print
    

    MBR が有効であれば、ファイル システムに関する情報が表示されます。

    Disk /dev/sdb: 10.7GB
    Sector size (logical/physical): 512B/4096B
    Partition Table: msdos
    Disk Flags:
    
    Number  Start   End     Size    Type     File system  Flags
     1      2097kB  10.7GB  10.7GB  primary  ext4         boot
    

インスタンスを作成できない場合

インスタンスが作成されない場合のヒントをご紹介します。

  • リソースのミューテーションまたは作成操作を同時に行うと、エラーが発生する可能性があります。たとえば、サブネットワークのセカンダリ範囲を変更し、同時に VM を作成すると、次のエラーが発生する場合があります。The resource 'projects/[PROJECT]/regions/[REGION]/subnetworks/default' is not ready。その際は、失敗した操作をやり直してください。

  • 新しいリソースをリクエストするときにリソースエラー(ZONE_RESOURCE_POOL_EXHAUSTEDZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS)を受け取った場合、ゾーンは現在リクエストに対応できないことを意味します。このエラーは、Compute Engine リソースの入手可能性によるものであり、Compute Engine の割り当てによるものではありません。

    解決するためのヒントをいくつか紹介します。

    • この状況は一時的なものであり、変動する需要に基づいて頻繁に変更される可能性があるため、しばらくしてからリクエストを再試行してください。
    • 可能であれば、リージョン内の別のゾーンか、または別のリージョンにリソースを作成します。
    • 可能であれば、リクエストする VM の形状を変更します。小さいマシンタイプの方が大きいタイプより簡単です。GPU の数を少なくする、メモリや vCPU の少ないカスタム VM を使用するなど、リクエストを変更することで、リクエストを続行できる場合があります。
    • Compute Engine の予約を使用して、ゾーン内のリソースを予約することで、必要なリソースをいつでも使うことができます。
    • プリエンプティブル インスタンスを作成しようとしている場合、プリエンプティブル VM は予備容量であるため、ピーク需要時に取得できない可能性があります。
    • 新しいリソースをリクエストするときに does not exist in zone または notFound エラーが発生した場合、リクエストしたリソースまたはマシンタイプがゾーンから提供されていないことを意味します。各ゾーンで利用可能な機能を確認するには、リージョンとゾーンをご覧ください。

インスタンスへの、またはインスタンスからのネットワーク トラフィックがドロップされている場合

Compute Engine では、プロジェクトのファイアウォール ルールで明示的に許可されているネットワーク トラフィックのみがインスタンスへのアクセスを許可されます。デフォルトの場合、すべてのプロジェクトに特定の種類の接続を許可するデフォルト ネットワークが用意されています。すべてのトラフィックをデフォルトで拒否すると、SSH 接続とすべての内部トラフィックも拒否されます。詳細については、ファイアウォール ルール ページをご覧ください。

その他に、TCP キープアライブの設定を調整して、アイドル状態の接続のデフォルト タイムアウト(10 分)を回避する必要がある場合もあります。詳しくは、インスタンスとインターネットの間の通信をご覧ください。

インスタンスに適用されるファイアウォール ルールまたはルートのトラブルシューティング

GCP Console では、インスタンスのネットワーク インターフェース別にネットワークの詳細を表示できます。インターフェースに適用されるすべてのファイアウォール ルールまたはルートを見ることも、インターフェースが使用するファイアウォール ルールとルートだけを見ることもできます。いずれも、インスタンスに適用されるファイアウォール ルールとルートのトラブルシューティングや、実際に使用されているファイアウォール ルールとルートのトラブルシューティング(優先順位と処理の順序が他のファイアウォール ルールやルートをオーバーライドしている場合)に役立ちます。

詳細については、Virtual Private Cloud ドキュメントに記載されているトラブルシューティングの情報をご覧ください。

SSH に関する問題のトラブルシューティング

一定の条件下で、Linux インスタンスが SSH 接続を受け付けなくなることがあります。これには、ディスクの容量不足から sshd の構成ミスまで、さまざまな理由が考えられます。このセクションでは、一般的な SSH の問題のトラブルシューティングと解決のためのヒントと方法をいくつかご紹介します。

ファイアウォール ルールを確認する

Compute Engine では、SSH トラフィックを許可するファイアウォール ルールのデフォルト セットが各プロジェクトに用意されます。このデフォルトのファイアウォール ルールがなんらかの理由で削除されると、インスタンスにアクセスできなくなります。gcloud コマンドライン ツールでファイアウォールのリストを調べて、default-allow-ssh ルールがあることを確認してください。

gcloud compute firewall-rules list

ない場合は追加し直してください。

gcloud compute firewall-rules create default-allow-ssh --allow tcp:22

シリアル コンソールで問題をデバッグする

インスタンスのシリアル コンソールへの読み取り / 書き込みアクセスを有効にして、コンソールにログインし、インスタンスの問題をトラブルシューティングできます。これは、SSH を使用してログインできない場合や、インスタンスがネットワークに接続していない場合に特に便利です。どちらの条件でも、シリアル コンソールには引き続きアクセスできます。

インタラクティブ アクセスを有効にして、インスタンスのシリアル コンソールに接続する方法については、シリアル コンソールとのやり取りをご覧ください。

ネットワークをテストする

netcat ツールを使用して、インスタンスのポート 22 に接続し、ネットワーク接続が機能していることを確認します。接続に成功して ssh のバナー(例: SSH-2.0-OpenSSH_6.0p1 Debian-4)が表示された場合は、ネットワーク接続が正常に動作しているため、ファイアウォールの問題を排除できます。まず、gcloud ツールを使用して、インスタンスの外部 natIP を取得します。

gcloud compute instances describe example-instance --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
198.51.100.8

nc コマンドを使用してインスタンスに接続します。

# Check for SSH banner
user@local:~$ nc [EXTERNAL_IP] 22
SSH-2.0-OpenSSH_6.0p1 Debian-4

新しいユーザーで試してみる

ログインできない問題の原因がアカウントにある可能性もあります(たとえば、インスタンスの ~/.ssh/authorized_keys ファイルのアクセス許可が正しく設定されていない場合)。

gcloud ツールを使用して新しいユーザーとしてログインし、SSH リクエストで別のユーザー名を指定してみてください。gcloud ツールはプロジェクトのメタデータを更新して新しいユーザーを追加し、SSH アクセスを許可します。

user@local:~$ gcloud compute ssh [USER]@example-instance

ここで、[USER] はログインするための新しいユーザー名です。

ディスクを新しいインスタンスで使用する

上記で説明した手順で問題が解決せず、目的のインスタンスが永続ディスクから起動される場合は、永続ディスクの接続を解除して、新しいインスタンスで使用するディスクを接続します。DISK をディスク名に置き換えてください。

gcloud compute instances delete old-instance --keep-disks=boot
gcloud compute instances create new-instance --disk name=DISK boot=yes auto-delete=no
gcloud compute ssh new-instance

インスタンスをシャットダウンせずに検査する

接続できないインスタンスで本番環境トラフィックが正常に処理されている場合もあります。その場合は、ユーザーにサービスを提供するインスタンスの機能を中断させずにディスクを検査できます。まず、インスタンスのブートディスクのスナップショットを作成して、そのスナップショットから新しいディスクを作成します。次に、一時インスタンスを作成し、その一時インスタンスに新しい永続ディスクを接続およびマウントして、ディスクのトラブルシューティングを行います。

  1. クローン インスタンスをホストする新しい VPC ネットワークを作成します。

    gcloud compute networks create debug-network
    
  2. SSH 接続を許可するファイアウォール ルールをそのネットワークに追加します。

    gcloud compute firewall-rules create debug-network-allow-ssh --allow tcp:22
    
  3. 問題のディスクのスナップショットを作成します。DISK をそのディスクの名前に置き換えてください。

    gcloud compute disks snapshot DISK --snapshot-name debug-disk-snapshot
    
  4. 作成したスナップショットを使用して新しいディスクを作成します。

    gcloud compute disks create example-disk-debugging --source-snapshot debug-disk-snapshot
    
  5. 外部 IP アドレスを持たない新しいデバッグ インスタンスを作成します。

    gcloud compute instances create debugger --network debug-network --no-address
    
  6. そのインスタンスにデバッグ ディスクを接続します。

    gcloud compute instances attach-disk debugger --disk example-disk-debugging
    
  7. 外部 IP アドレスを持たないインスタンスへの接続の手順に従います。

  8. デバッグ インスタンスにログインした後、インスタンスのトラブルシューティングを行います。たとえば、インスタンスのログを確認できます。

    $ sudo su -
    
    $ mkdir /mnt/myinstance
    
    $ mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/myinstance
    
    $ cd /mnt/myinstance/var/log
    
    # Identify the issue preventing ssh from working
    $ ls
    

起動スクリプトを使用する

これまでの手順で問題が解決しない場合は、起動スクリプトを作成してインスタンスの起動直後の情報を収集できます。起動スクリプトの実行の手順に従ってください。

その後、gcloud compute instances reset を実行して、メタデータが有効になる前にインスタンスをリセットする必要があります。代わりに、診断用起動スクリプトを使用してインスタンスを再作成することもできます。

  1. --keep-disks フラグを設定して gcloud compute instances delete を実行します。

    gcloud compute instances delete INSTANCE --keep-disks boot
    
  2. 同じディスクを使用して新しいインスタンスを追加し、起動スクリプトを指定します。

    gcloud compute instances create example-instance --disk name=DISK,boot=yes --startup-script-url URL
    

最初に compute-ssh-diagnostic スクリプトを使用すると、ほとんどの一般的な問題の診断情報を収集できます。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Compute Engine ドキュメント