일반 문제해결

이 페이지에서는 Google 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

네트워크 트래픽-인스턴스가 중단된 경우

Google Compute Engine에서는 프로젝트의 방화벽 규칙에 의해 명시적으로 허용된 네트워크 트래픽만 사용자의 인스턴스에 도달할 수 있습니다. 기본적으로 모든 프로젝트에는 특정 종류의 연결을 허용하는 기본 네트워크가 자동으로 제공됩니다. 기본값으로 모든 트래픽을 거부할 경우 SSH 연결 및 모든 내부 트래픽도 거부됩니다. 자세한 내용은 방화벽 규칙 페이지를 참조하세요.

또한, 10분으로 기본 구성된 유휴 연결 제한시간을 변경하기 위해 TCP keep-alive 설정을 조정해야 할 수 있습니다. 자세한 내용은 인스턴스와 인터넷 간의 통신을 참조하세요.

인스턴스의 방화벽 규칙 또는 경로 관련 문제해결

GCP Console은 인스턴스의 각 네트워크 인터페이스에 대한 네트워크 세부정보를 제공합니다. 특정 인터페이스에 적용되는 모든 방화벽 규칙 또는 경로를 확인하거나, 특정 인터페이스가 사용하는 규칙 및 경로만 확인할 수 있습니다. 어느 경우에든 인스턴스에 적용되는 방화벽 규칙 및 경로와 실제로 사용 중인 방화벽 규칙 및 경로(우선순위 및 처리 순서가 다른 규칙 또는 경로보다 우선하는 경우)를 파악하여 문제를 해결하는 데 도움이 될 수 있습니다.

자세한 내용은 가상 사설 클라우드 문서의 다음 문제해결 정보를 참조하세요.

SSH 관련 문제해결

특정 조건에서는 Linux 인스턴스가 더 이상 SSH 연결을 허용하지 않을 수 있습니다. 여기에는 전체 디스크에서부터 의도치 않은 sshd 구성 오류까지 여러 가지 이유가 있습니다. 이 섹션에서는 일반적인 SSH 문제를 해결하는 다양한 도움말과 접근 방식에 대해 설명합니다.

방화벽 규칙 확인

Google Compute Engine은 각 프로젝트에 SSH 트래픽을 허용하는 방화벽 규칙 기본 세트를 제공합니다. SSH 연결을 허용하는 기본 방화벽 규칙이 제거될 경우 인스턴스에 액세스할 수 없습니다. gcloud compute 명령줄 도구로 방화벽 목록을 확인하고 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 파일에 대한 권한이 잘못 설정된 경우).

SSH 요청이 있는 다른 사용자 이름을 지정하여 gcloud 도구로 새로운 사용자로 로그인을 시도합니다. 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 문서