GCP 常見問題與教學―掛載硬碟錯誤導致 VM 開機失敗

GCP 常見問題與教學―掛載硬碟錯誤導致 VM 開機失敗

「GCP 掛載硬碟錯誤,導致 VM 開機失敗怎麼辦?」許多企業剛把 VM 搬遷上雲時,面對開機失敗問題都會因為無法走到機房拯救主機而異常慌張。所以這次我們將模擬掛載硬碟錯誤的情境並示範2種救援教學,希望未來大家遇到類似狀況都能冷靜地成功救援主機!

GCP VM 開機失敗問題:掛載硬碟錯誤

我們剛開始使用雲端主機時,常會把 VM(虛擬機器)當成自家機房的主機在處理。但其實這兩者有一個非常大的差異,就是「你沒辦法走到機器前面排除問題」!如果是自家機房的主機,不論發生任何狀況我們都可以走進機房,使用救援模式或插入光碟(Live DVD)來拯救自家的主機。

但在雲端環境我們就沒辦法這麼做了,Google 的機房不像自家機房可以讓我們來去自如啊!而根據 Cloud Ace 自身後台數據統計,雲端 VM 最常被詢問的問題就是:「使用 Linux 主機,掛載硬碟(Disk)失敗導致無法開機成功!」所以今天我們就來示範一下這個問題該如何解決吧!

GCP VM 掛載硬碟錯誤狀況模擬

首先我們在 Google Cloud Platform(GCP)專案建一台作業系統為 Debian 的主機,並加掛一顆 50 GB 的 Disk,其他選項保持預設。建立之後我們直接 SSH 連線進去,輸入 lsblk 並查看目前 Disk 掛載的狀況。

現在我們知道有 sdb 這顆 50 GB 的 Disk,但到這邊還不能用!必須先輸入下方的指令進行格式化,完成後我們就能看到這顆 Disk 已成功格式化。上面這段過程,想更仔細了解的人可參考 GCP 官網上的《格式化並掛載非開機磁碟的操作步驟》喔!

sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/sdb
輸入指令進行 GCP 硬碟格式化_示意圖
截圖自:Google Cloud Shell 頁面
©2022 Google

接下來在我們要掛載 Disk 之前,還要先建立一個目錄當作掛載點(步驟1)。完成後再輸入指令進行正式掛載(步驟2),掛載成功後,還要記得更改目錄權限讓大家都能寫資料進去!(步驟3)

步驟1:sudo mkdir -p /mnt/disks/disk-data
步驟2:sudo mount -o discard,defaults /dev/sdb /mnt/disks/disk-data
步驟3:sudo chmod a+w /mnt/disks/disk-data

上述3個步驟完成後,我們可以看到更改權限前後的狀況如下圖。但這目前只是暫時掛載成功,重開機後又恢復到尚未掛載的狀態。如果想要開機自動掛載,必須要做接下來的設定,就是更改 /etc/fstab 這個檔案

GCP 掛載硬碟錯誤模擬_確認目錄權限前後更改狀況
截圖自:Google Cloud Shell 頁面
©2022 Google

這邊提醒大家千萬要注意一點,就是這個檔案只要有任何錯誤就會造成開機失敗,而且是無法進入命令列的那種!所以一定要記得先把檔案備份起來,萬一改錯就用下方的檔案覆蓋回去。

sudo cp /etc/fstab /etc/fstab.backup

然後在更改 fstab 之前,必須要先取得 Disk 的 UUID,所以要輸入下方步驟1的指令。而在得到 UUID 後,我們先把它複製起來並準備正式來修改 fstab,這邊請各位輸入步驟2的指令。在完成上2個步驟後,我們可看到檔案樣子呈現如下圖:

步驟1:sudo blkid /dev/sdb
步驟2:sudo vim /etc/fstab
GCP 掛載硬碟錯誤模擬_確認 fstab 檔案資訊
截圖自:Google Cloud Shell 頁面
©2022 Google

接著這邊我們要再加入新的一行(詳見範例)。相關參數的細節這邊不多做解釋,但各位記得多檢查一下標準格式喔!另外補充一點,我們可以使用 mount -a 來根據 fstab 一次掛載所有 disk ,這樣萬一 fstab 有寫錯,就能及時看到錯誤並修正!

範例:UUID=0f652379-a4d2-4d2a-a047-7bcd2ea73457 /mnt/disks/disk-data ext4 discard,defaults 0 2
GCP 掛載硬碟錯誤模擬_使用 mount -a 確認 fstab
fstab 錯誤範例
截圖自:Google Cloud Shell 頁面
©2022 Google

如果掛載沒錯誤當然就不會看到任何訊息,但我們也可以寫個檔案進目錄,確認這個 Disk 是可以用的。檔案範例如下,大家可以寫進自己的目錄試試看,而如果沒問題就可以放心地儲存離開。

cd /mnt/disks/disk-data/
echo "hellow_world" > hello.txt
cat hello.txt

一切確認無誤後,接下來就要進行第一次緊張的重開機!首先我們點擊 VM 右邊三小點裡面的 Reset。重開後再 SSH 進去,成功進入命令列然後再輸入 lsblk 確認 Disk 自動掛載成功。

那接著重頭戲來了,我們要故意弄壞它!首先把好的 fstab 檔案備份一次(步驟1),然後進去修改裡面的內容,例如把 UUID 和掛載點都改掉(步驟2)。這邊我故意把新 Disk 的 UUID 加上「-2」,掛載點也加上「-2」(詳見下圖)。

步驟1:sudo cp /etc/fstab /etc/fstab.backup
步驟2:sudo vim fstab
GCP 掛載硬碟錯誤模擬_設定錯誤的 fstab
截圖自:Google Cloud Shell 頁面
©2022 Google

上面修改的內容儲存好後,接著我們故意去卸載它(步驟3),然後再故意掛載錯的路徑(步驟4)。上面兩個步驟完成後,我們就能看到掛載點不存在的錯誤訊息。

步驟3:sudo umount /mnt/disks/disk-data
步驟4:sudo mount -o discard,defaults /dev/sdb /mnt/disks/disk-data-2
GCP 掛載硬碟錯誤模擬_確認掛載點不存在
截圖自:Google Cloud Shell 頁面
©2022 Google

所以接下來我們可以重開機並見證鋪陳已久的開機失敗時刻,深吸一口氣重開機後果不其然收到開機失敗的訊息。那接下來就讓我們一起來看看面對這樣的狀況,可以利用哪兩種方法救援吧!

GCP VM 開機失敗_示意圖
重開機見證掛載錯誤導致開機失敗
截圖自:Google Cloud Shell 頁面
©2022 Google

GCP 硬碟掛載錯誤救援教學一:使用 Serial Port 連到主機

開頭我們說過雲端主機和地端主機最大的差異是我們「沒辦法走到機器前面排除問題」,但其實我們進入主機後會看到的「CONNECT TO SERIAL CONSOLE」,就是模擬我們真的走到主機面前的樣子。

使用 Serial Port 連到 GCP VM_示意圖
使用 Serial Port 連到主機
截圖自:Google Cloud Platform Console 頁面
©2022 Google

補充一下,「Connecting to serial ports is enabled in project-wide metadata」這行字代表我們可以在 metadata 設定啟用這個功能。所以未來專案裡任何一台機器開不了,都可以用 Serial Console 進去救援。而回到救援主機這項任務,點擊按鈕後它一樣會開啟一個視窗,並告訴你按 Enter 可以進去。

但按了 Enter 後,它告訴我們 root account is locked,表示 root 沒有設密碼不能登入。其實這是常態,因為 root 權限非常大,預設都不給開,除非使用者平常有意識到這點然後已經設好了密碼,這樣才能正常進入 serial console。

GCP 硬碟掛載錯誤救援_root 帳號被鎖定
截圖自:Google Cloud Platform Console 頁面
©2022 Google

但其實我們通常還是建議不要啟用 root ,因為如果你的主機 IP 是直接曝露在網路上的,那真的無時無刻都有駭客在嘗試登入你的主機,說實話非常危險!所以這邊要再介紹主機救援的第二種方法給大家。

GCP 硬碟掛載錯誤救援教學二:主機 Boot Disk 重掛載+修改 fstab

這邊要介紹的第二個救援方法雖然有點麻煩,但幾乎都能成功。所以還是建議大家遇到這類型的開機失敗狀況可優先嘗試這個方法,下面就讓我們一起來看看要如何操作吧!首先我們把無法開機的主機關機,接著在找到 Boot Disk 後,點擊它進入 Disk 的頁面。

進入 Boot Disk 頁面後我們接著點擊「Create Snapshot」,然後在幫 Snapshot 完成命名後按下「CREATE」來進行快照備份。

再來我們要另外建一台新的主機 instance-2。這邊的重點是要把剛剛那個 snapshot-1 掛成另一顆 Disk,然後去修復它的 fstab。加好舊機器的 Disk 後,我們接著要連進去 instance-2 。提醒一下掛載前一樣先用 lsblk 查看它的 ID 是多少!

這邊請大家特別注意,真正有資料的分割是9.9GB 的 sdb1 喔,小心不要掛載錯了!那現在一樣先建立掛載點並把 Boot Disk 掛起來。掛載成功後,我們進去該目錄確認一下,從 /mnt/disks/boot-disk 開始,就是原本開不起來那台機器的根目錄。

sudo mkdir -p /mnt/disks/boot-disk
sudo mount -o discard,defaults /dev/sdb1 /mnt/disks/boot-disk
GCP 硬碟掛載錯誤救援_確認原本 Boot Disk 的目錄
截圖自:Google Cloud Shell 頁面
©2022 Google

而我們從這裡去找 etc/fstab,應該就會看到下圖黃框裡那個寫錯的 fstab 檔案,那既然成功找到了,下一個步驟當然就是更改它啦!方法很簡單就是直接把寫錯的那一行刪掉。

sudo vim fstab 
GCP 硬碟掛載錯誤救援_找到寫錯的 fstab 檔
截圖自:Google Cloud Shell 頁面
©2022 Google

fstab 修改提醒
其實這次我們應該只要把 UUID 和掛載點的「-2」刪掉,讓最前面的 disk-data 可以再掛載回來就好了。但除非我們有信心 fstab 能改一次就正確,不然還是建議先不要掛載額外的 disk-data,等到 Boot Disk 開機成功後再重新掛 disk-data 也不遲喔!
(下圖截自:Google Cloud Shell 頁面 ©2022 Google)

fstab 改好之後,我們再來去修改 instance-2 這台機器,這邊首先把 boot-disk-2 卸載掉,接著再建立一台新機器,其中引用的 Boot disk 就是我們剛改過 fstab 的那一顆。然後在 Boot disk 裡選擇 CHANGE,用 boot-disk-2 當做 boot disk 來開機。

接著我們來確認主機相關資訊,沒問題的話按下建立。接著再點擊 instance-3 的 SSH 按鈕,看看剛剛救的主機能不能成功連進去。這邊讓我們一起深吸一口氣,緩和一下緊張的情緒來看結果吧!

成功了!恭喜各位我們的 Boot Disk 救援成功!那接著我們再去看看 fstab 檔案,確認一下是修改回來的樣子,如此一來就可以再重新掛回原本那顆 disk-data 啦。另外這裡提供一下 Google Cloud 官方文件《Recovering an inaccessible VM or a full boot disk》,當中有完整的教學。

各位若看到這裡,應該就知道未來如果碰到類似狀況,只要把相關 Disk 做 Snapshot ,然後想辦法在其他主機開起來即可。而同樣概念套用到任何 Disk 相關的異動,包含加新 Disk、Disk加大、掛載或卸載 Disk 等一律適用。又或者只要主機有重大的安裝或設定,都先做 Snapshot!這樣不論發生任何事情,我們手邊都有一個備份,要做什麼緊急處置都很方便。而 Snapshot 的教學可參考《如何輕鬆備份 GCP 上 VM 的資料?快照 Snapshot 自動備份設定教學》這篇文章喔!

如開頭所述,雲端主機無法讓我們來去自如,所以一遇到主機需要救援的狀況多數人都會很緊張!因此在這邊特別分享 Disk 掛載錯誤導致開機失敗的2種救援方法給大家。各位對以上內容如有任何問題歡迎留言詢問,有 GCP 相關需求或技術問題也都歡迎聯絡我們,喜歡這種常見問題解答系列的話也可以留言讓我們知道喔!

延伸閱讀:

【GCP教學】第一次開 Google VM 就上手 – Compute Engine 操作簡介
【GCP教學】第一次開Google VM要注意什麼?Compute Engine開機詳細介紹
使用 Google VM 的5大常見錯誤 – 有一種叫忘記關機!
【GCP教學】如何輕鬆備份 GCP 上 VM 的資料?快照 Snapshot 自動備份設定教學

Cloud Ace 研討會主頁

Aaron Lee

超過7年的 Google Cloud 經驗,服務過上百家 Google Workspace 與 GCP 客戶,擔任多次研討會主講人與教育訓練講師,提供架構諮詢與技術支援,幫助各大企業上雲。

發佈留言