一般疑難排解

本頁面說明疑難排解步驟,解決您使用 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 是備用容量,因此可能無法在尖峰需求期間取得。
    • 如果您在要求新資源時收到 notFounddoes not exist in zone 錯誤,即表示區域不提供您要求的資源或機器類型。請參閱地區和區域一文,找出每個區域可用的功能。

假如往/返執行個體的網路流量遭到捨棄

Compute Engine 僅允許專案防火牆規則所明確允許的網路流量觸及您的執行個體。根據預設,所有專案都自動具有允許某種連線預設網路。如果您預設為拒絕所有流量,也會同時拒絕 SSH 連線和所有內部流量。詳情請參閱防火牆規則頁面。

此外,您可能需要調整 TCP 保持活動設定,以解決預設的 10 分鐘閒置連線逾時。詳情請參閱執行個體與網際網路之通訊一文。

疑難排解執行個體的防火牆規則或路徑

GCP 主控台可為執行個體的每個網路介面提供網路詳細資料。您可以查看套用到介面的所有防火牆規則或路徑,也可以僅查看介面使用的規則與路徑。每個視圖都可協助您疑難排解哪些防火牆規則與路徑套用至介面,以及實際使用哪個防火牆規則與路徑 (若優先順序與處理順序覆寫其他規則或路徑)。

詳情請參閱虛擬私人雲端說明文件中的疑難排解資訊:

排解 SSH 相關問題

在某些情況下,Linux 執行個體可能不再接受 SSH 連線。造成這種情況的原因有很多,從磁碟過滿到意外的 sshd 設定錯誤都有可能。針對 SSH 常見問題的疑難排解和解決方法,本節介紹了一些提示和方法。

檢查您的防火牆規則

Compute Engine 會為每個專案佈建一組預設的防火牆規則,該規則允許 SSH 流量。假如允許 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. 建立託管複製執行個體的新虛擬私人雲端網路:

    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 script為基礎,收集多數常見問題的診斷資訊。

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Compute Engine 說明文件