做OpenStack運(yùn)維的人遲早會(huì)跟Nova的幾十條命令打交道。控制節(jié)點(diǎn)掛了可以重建網(wǎng)絡(luò)節(jié)點(diǎn)掛了可以恢復(fù)但計(jì)算節(jié)點(diǎn)上的每一臺(tái)實(shí)例出了問題以后能不能救、怎么救全靠Nova這一層的操作是否熟練。我剛上手OpenStack那會(huì)兒最頭疼的就是實(shí)例狀態(tài)和操作命令對(duì)不上號(hào)——明明想暫停卻執(zhí)行了掛起明明只是關(guān)機(jī)卻把實(shí)例數(shù)據(jù)弄丟了。后來把Nova的常見操作按“狀態(tài)-動(dòng)作”畫成一張圖之后整個(gè)思路才清晰起來。這篇文章就把我整理過的Nova 16種核心操作完整拆一遍順便把每個(gè)操作背后的原理、適用場景和踩過的坑都交代清楚。無論你是剛接觸OpenStack的運(yùn)維新人還是已經(jīng)扛著幾十臺(tái)計(jì)算節(jié)點(diǎn)的老兵這份清單都能幫你少走彎路。1. 先看全景Nova實(shí)例狀態(tài)機(jī)與16種操作的關(guān)系圖1.1 Nova實(shí)例的狀態(tài)先認(rèn)識(shí)這幾個(gè)關(guān)鍵節(jié)點(diǎn)很多人用Nova的時(shí)候習(xí)慣直接敲命令根本不看實(shí)例當(dāng)前處于什么狀態(tài)。這就是問題所在。Nova的每個(gè)操作幾乎都是“狀態(tài)依賴”的實(shí)例處于ACTIVE時(shí)你能做的大部分操作到了ERROR狀態(tài)就全被拒絕。想要真正理解這張操作圖必須先認(rèn)識(shí)幾個(gè)核心狀態(tài)。BUILD實(shí)例正在創(chuàng)建調(diào)度器剛把它交給某個(gè)計(jì)算節(jié)點(diǎn)libvirt正在準(zhǔn)備磁盤、網(wǎng)絡(luò)和CPU資源幾秒到幾十秒內(nèi)會(huì)轉(zhuǎn)到ACTIVE或ERROR。ACTIVE正常運(yùn)行g(shù)uest OS已經(jīng)跑起來對(duì)外提供服務(wù)。這是實(shí)例一生中停留最久的狀態(tài)。SHUTOFF實(shí)例被關(guān)機(jī)stop或者剛從開機(jī)狀態(tài)關(guān)機(jī)。注意SHUTOFF不代表實(shí)例被刪除它的磁盤文件、內(nèi)存配置都還在計(jì)算節(jié)點(diǎn)上。PAUSED暫停虛機(jī)的CPU被凍結(jié)但內(nèi)存還在物理內(nèi)存里。這種狀態(tài)很少見一般只在排障或臨時(shí)騰資源時(shí)用。SUSPENDED掛起內(nèi)存已經(jīng)被寫到宿主機(jī)本地磁盤虛機(jī)完全凍結(jié)CPU和內(nèi)存資源全部釋放。SHELVED“擱置”虛機(jī)關(guān)機(jī)后把系統(tǒng)盤快照上傳到Glance計(jì)算節(jié)點(diǎn)上的本地文件會(huì)被清理實(shí)例幾乎不占用計(jì)算資源。RESCUED救援模式原來的系統(tǒng)盤被掛成數(shù)據(jù)盤虛機(jī)改用救援鏡像啟動(dòng)。ERROR出錯(cuò)了?？赡苁钦{(diào)度失敗、鏡像拉取失敗、磁盤空間不足、網(wǎng)絡(luò)創(chuàng)建失敗等等一句話需要人工介入。VERIFY_RESIZE變配后的等待確認(rèn)狀態(tài)需要執(zhí)行confirm或revert確認(rèn)變更。MIGRATING遷移進(jìn)行中虛機(jī)還在源節(jié)點(diǎn)或目標(biāo)節(jié)點(diǎn)上運(yùn)行但調(diào)度和復(fù)制流程已經(jīng)啟動(dòng)。查看實(shí)例狀態(tài)最直接的方式就是openstack server show server_id里面會(huì)顯示OS-EXT-STS:vm_state和OS-EXT-STS:task_state兩個(gè)字段。vm_state是穩(wěn)定狀態(tài)task_state是當(dāng)前正在執(zhí)行的操作這兩個(gè)字段配合status字段一起看才能判斷實(shí)例當(dāng)前到底在干嘛。1.2 16種操作與狀態(tài)轉(zhuǎn)換對(duì)應(yīng)總表我把最常見的Nova操作按照“操作目的”歸成16類每一類都對(duì)應(yīng)一條或一組命令。下面的表格可以當(dāng)作日常速查卡來用也是整篇文章的“地圖”。操作分類典型命令狀態(tài)遷移效果適用場景創(chuàng)建實(shí)例openstack server createBUILD → ACTIVE/ERROR上線新業(yè)務(wù)、擴(kuò)容刪除實(shí)例openstack server delete任意狀態(tài) → 無釋放資源、下線業(yè)務(wù)開機(jī)openstack server startSHUTOFF → ACTIVE恢復(fù)關(guān)機(jī)實(shí)例關(guān)機(jī)openstack server stopACTIVE → SHUTOFF計(jì)劃維護(hù)、釋放CPU內(nèi)存軟重啟openstack server reboot --softACTIVE → REBOOT → ACTIVEguest OS可響應(yīng)時(shí)的重啟硬重啟openstack server reboot --hardACTIVE → HARD_REBOOT → ACTIVE系統(tǒng)無響應(yīng)、內(nèi)核卡死暫停/恢復(fù)openstack server pause/unpauseACTIVE ? PAUSED短時(shí)凍結(jié)不落盤掛起/恢復(fù)openstack server suspend/resumeACTIVE ? SUSPENDED宿主機(jī)休眠級(jí)維護(hù)擱置/恢復(fù)openstack server shelve/unshelveACTIVE ? SHELVED長期釋放計(jì)算資源鎖定/解鎖openstack server lock/unlock狀態(tài)不變防止誤操作創(chuàng)建快照openstack server image create狀態(tài)不變備份、模板復(fù)刻重建openstack server rebuildACTIVE/ERROR → REBUILD → ACTIVE系統(tǒng)盤被搞壞時(shí)恢復(fù)救援/取消救援openstack server rescue/unrescueACTIVE ? RESCUED進(jìn)救援系統(tǒng)修配置變配openstack server resizeACTIVE → VERIFY_RESIZE調(diào)整CPU/內(nèi)存規(guī)格遷移openstack server migrateACTIVE/SHUTOFF → MIGRATING宿主機(jī)維護(hù)、負(fù)載均衡疏散openstack server evacuateERROR → ACTIVE計(jì)算節(jié)點(diǎn)故障時(shí)救命這16類操作基本覆蓋了日常運(yùn)維90%以上的場景。下面我會(huì)按“存亡與電源管理”“凍結(jié)類操作”“恢復(fù)與重建”“遷移與變配”“外部資源聯(lián)動(dòng)”五個(gè)維度逐個(gè)深入拆解。2. 實(shí)例的存亡與電源管理創(chuàng)建、刪除、開關(guān)機(jī)、重啟2.1 create與delete實(shí)例從哪來到哪去創(chuàng)建實(shí)例是所有操作的起點(diǎn)。執(zhí)行openstack server create --flavor flavor --image image --network net name后Nova會(huì)先把請(qǐng)求交給調(diào)度器Scheduler調(diào)度器根據(jù)flavor的資源約束、AZ可用域、宿主機(jī)負(fù)載等策略選出一個(gè)合適的計(jì)算節(jié)點(diǎn)然后通知該節(jié)點(diǎn)上的nova-compute去準(zhǔn)備虛擬化資源。底層實(shí)際操作者是libvirt它根據(jù)鏡像和flavor配置生成域domain定義創(chuàng)建虛擬磁盤、虛擬網(wǎng)卡最后通過KVM/QEMU把虛機(jī)拉起來。創(chuàng)建實(shí)例時(shí)最容易踩的坑有三個(gè)。第一個(gè)是flavor的磁盤大小和鏡像實(shí)際大小不匹配如果系統(tǒng)盤是qcow2稀疏文件明明看鏡像只有幾百M(fèi)B創(chuàng)建后卻可能膨脹到幾十GB磁盤配額不足就會(huì)導(dǎo)致創(chuàng)建卡在BUILD狀態(tài)。第二個(gè)是網(wǎng)絡(luò)選擇如果指定了錯(cuò)誤的網(wǎng)絡(luò)虛機(jī)起來后網(wǎng)卡一直處于DOWN狀態(tài)業(yè)務(wù)根本無法訪問。第三個(gè)是忘記指定keypair或密碼注入方式導(dǎo)致創(chuàng)建完成后登不進(jìn)去。刪除實(shí)例openstack server delete遠(yuǎn)比創(chuàng)建看起來簡單但有幾個(gè)細(xì)節(jié)很容易被忽略。默認(rèn)情況下刪除實(shí)例會(huì)連同它的系統(tǒng)盤一起清理如果系統(tǒng)盤是臨時(shí)盤ephemeral數(shù)據(jù)徹底丟失無法找回。Cinder數(shù)據(jù)卷不會(huì)自動(dòng)刪除除非卷創(chuàng)建時(shí)設(shè)置了delete_on_terminationTrue。這個(gè)屬性在創(chuàng)建實(shí)例時(shí)指定很多運(yùn)維習(xí)慣把所有數(shù)據(jù)都放到臨時(shí)盤上刪完才發(fā)現(xiàn)數(shù)據(jù)全沒了這種教訓(xùn)我見過太多次。生產(chǎn)環(huán)境中刪除前一定要先確認(rèn)是否需要保留系統(tǒng)盤快照不放心的話就先做個(gè)snapshot再刪。2.2 start與stop關(guān)機(jī)不等于刪除很多剛接觸OpenStack的人會(huì)把“關(guān)機(jī)”理解為“停止服務(wù)”但Nova里的stop操作實(shí)際是向?qū)嵗l(fā)送ACPI關(guān)機(jī)信號(hào)讓guest OS正常走系統(tǒng)關(guān)機(jī)流程。執(zhí)行openstack server stop后實(shí)例的vm_state會(huì)從ACTIVE變成SHUTOFFCPU和內(nèi)存資源被釋放宿主機(jī)可以騰出資源給其他實(shí)例。注意這只是釋放計(jì)算資源實(shí)例的磁盤文件仍然留在計(jì)算節(jié)點(diǎn)的/var/lib/nova/instances目錄下。start操作則是在同一個(gè)計(jì)算節(jié)點(diǎn)上基于原有的磁盤文件重新把虛機(jī)拉起來。它比創(chuàng)建新實(shí)例快得多因?yàn)椴恍枰匦聹?zhǔn)備磁盤和網(wǎng)絡(luò)只需要啟動(dòng)QEMU進(jìn)程加載既有磁盤即可。這里有一個(gè)很容易被誤解的點(diǎn)關(guān)機(jī)再開機(jī)實(shí)例的IP地址會(huì)不會(huì)變正常情況下不會(huì)。因?yàn)閷?shí)例的虛擬網(wǎng)卡信息和端口port是綁定在實(shí)例上的只要實(shí)例沒被刪除網(wǎng)卡端口就不會(huì)被釋放IP也就保持不變。但有一種情況例外如果實(shí)例所在的計(jì)算節(jié)點(diǎn)故障你通過evacuate把實(shí)例遷移到別的節(jié)點(diǎn)那IP地址雖然在OpenStack層面沒變但guest OS里的網(wǎng)絡(luò)配置可能對(duì)不上需要手工調(diào)整。關(guān)機(jī)雖然簡單但有個(gè)實(shí)際問題很多應(yīng)用沒有優(yōu)雅處理ACPI關(guān)機(jī)的機(jī)制或者guest OS內(nèi)的acpid服務(wù)意外退出了這時(shí)候執(zhí)行stop狀態(tài)會(huì)長時(shí)間停留在ACTIVE或者任務(wù)超時(shí)。解決辦法是加--os-stop-hard強(qiáng)制關(guān)機(jī)或者到計(jì)算節(jié)點(diǎn)上直接執(zhí)行virsh destroy instance。但virsh destroy屬于“暴力斷電”客人機(jī)的文件系統(tǒng)可能損壞用之前一定要確認(rèn)業(yè)務(wù)已經(jīng)停止。2.3 reboot軟硬之間怎么選重啟是運(yùn)維用得最頻繁的操作。Nova的重啟分為軟重啟和硬重啟命令分別是openstack server reboot --soft和openstack server reboot --hard。軟重啟的本質(zhì)是讓guest OS走操作系統(tǒng)自身的重啟流程。實(shí)現(xiàn)上libvirt會(huì)向虛機(jī)發(fā)送ACPI reset信號(hào)內(nèi)核收到信號(hào)后正常關(guān)閉所有服務(wù)、卸載文件系統(tǒng)、然后重新啟動(dòng)。整個(gè)過程和你在機(jī)器上執(zhí)行reboot命令幾乎一樣。它適合系統(tǒng)還能正常響應(yīng)、需要清理內(nèi)存緩存或者應(yīng)用狀態(tài)時(shí)使用。硬重啟則完全不同。它不等guest OS響應(yīng)直接由hypervisor層把虛機(jī)電源切斷再重新通電。QEMU進(jìn)程被強(qiáng)制重啟CPU狀態(tài)重新初始化guest OS會(huì)經(jīng)歷一次非正常的斷電-通電過程。這種模式適合guest OS完全卡死、網(wǎng)絡(luò)不可達(dá)、軟重啟一直超時(shí)的情況下應(yīng)急。選擇軟硬重啟有個(gè)基本原則能軟不硬。硬重啟有極小概率導(dǎo)致文件系統(tǒng)損壞特別是在有大量未落盤寫入的時(shí)候。我遇到過幾次實(shí)例重啟后起不來最后檢查發(fā)現(xiàn)是mysql的binlog沒落盤硬重啟導(dǎo)致數(shù)據(jù)文件不一致只能做InnoDB恢復(fù)。所以如果你的實(shí)例跑的是數(shù)據(jù)庫這類對(duì)一致性敏感的服務(wù)盡量先軟重啟軟重啟超時(shí)后再考慮硬重啟。Nova默認(rèn)的重啟策略是軟重啟如果你確實(shí)需要硬重啟記得顯式加--hard參數(shù)。3. 凍結(jié)類操作暫停、掛起、擱置、鎖定3.1 pause與unpause最輕量的凍結(jié)暫停pause是一個(gè)被很多人忽略但實(shí)際很有用的操作。執(zhí)行openstack server pause后libvirt調(diào)用QEMU的pause命令把虛機(jī)的vCPU停止調(diào)度但整個(gè)虛機(jī)的內(nèi)存仍然保留在物理內(nèi)存中。實(shí)例進(jìn)入PAUSED狀態(tài)從guest OS的視角看就像時(shí)間被凍結(jié)了所有進(jìn)程原地停滯。這種凍結(jié)非常輕量恢復(fù)也極快unpause之后虛機(jī)立刻從上次暫停的位置繼續(xù)執(zhí)行。它適合臨時(shí)讓一個(gè)高占CPU的服務(wù)讓出資源或者做短時(shí)間的計(jì)算資源騰挪。比如你有幾臺(tái)實(shí)例在跑跑批任務(wù)白天占用大量CPU但不希望直接關(guān)機(jī)因?yàn)槿蝿?wù)進(jìn)度還在內(nèi)存里這時(shí)候pause一下等夜間再恢復(fù)非常合適。但pause有一個(gè)必須注意的致命缺陷PAUSED狀態(tài)不會(huì)被持久化。如果計(jì)算節(jié)點(diǎn)突然斷電或者nova-compute服務(wù)重啟宿主機(jī)上的libvirt會(huì)重新接管虛機(jī)PAUSED狀態(tài)大概率會(huì)丟失虛機(jī)可能直接恢復(fù)運(yùn)行也可能進(jìn)入ERROR。一旦節(jié)點(diǎn)故障你甚至無法確定虛機(jī)現(xiàn)在處于什么狀態(tài)。所以涉及長時(shí)間凍結(jié)優(yōu)先考慮suspend而不是pause。另外pause不支持跨節(jié)點(diǎn)遷移它是純粹基于本機(jī)物理內(nèi)存的凍結(jié)。3.2 suspend與resume內(nèi)存寫到本地盤掛起suspend和暫停pause看起來很像但底層原理完全不同。執(zhí)行openstack server suspend后nova-compute會(huì)調(diào)用libvirt的save操作把虛機(jī)的完整內(nèi)存狀態(tài)寫入宿主機(jī)本地磁盤默認(rèn)路徑通常是/var/lib/libvirt/qemu/save/寫入完成后虛機(jī)進(jìn)程被終止資源完全釋放。實(shí)例狀態(tài)變?yōu)镾USPENDED。因?yàn)閮?nèi)存鏡像寫到了磁盤上所以suspend狀態(tài)是持久的。只要宿主機(jī)磁盤沒壞不管nova-compute重啟多少次實(shí)例都能恢復(fù)?；謴?fù)動(dòng)作openstack server resume直接讀取內(nèi)存鏡像文件加載到內(nèi)存后繼續(xù)運(yùn)行?；謴?fù)速度雖然比pause慢需要讀盤但比reboot快得多因?yàn)榇疟P狀態(tài)完全不用重新初始化。suspend最適合的場景是宿主機(jī)計(jì)劃內(nèi)重啟。比如你要對(duì)某臺(tái)物理機(jī)做內(nèi)核升級(jí)、換硬件、調(diào)整BIOS先把上面所有實(shí)例suspend掉等機(jī)器重啟完成后再批量resume。我之前維護(hù)一批計(jì)算節(jié)點(diǎn)時(shí)就是用腳本批量遍歷實(shí)例執(zhí)行suspend節(jié)點(diǎn)重啟后再批量resume整個(gè)過程業(yè)務(wù)中斷時(shí)間只有幾分鐘遠(yuǎn)比一臺(tái)臺(tái)關(guān)系統(tǒng)再開系統(tǒng)快。使用suspend有個(gè)隱藏成本內(nèi)存鏡像文件占的磁盤空間約等于實(shí)例的物理內(nèi)存大小。如果一臺(tái)宿主機(jī)上跑了20臺(tái)16GB內(nèi)存的虛機(jī)同時(shí)掛起的話宿主機(jī)本地磁盤會(huì)瞬間多出320GB的占用。所以批量掛起前一定要檢查宿主機(jī)磁盤余量否則掛了一半磁盤寫滿剩下的實(shí)例直接卡在SUSPENDING狀態(tài)。3.3 shelve與unshelve數(shù)據(jù)上傳Glance資源釋放擱置shelve是這三種凍結(jié)方式里最“狠”的。執(zhí)行openstack server shelve后Nova會(huì)把實(shí)例的系統(tǒng)盤做成鏡像上傳到Glance然后把計(jì)算節(jié)點(diǎn)上的實(shí)例文件清理掉虛機(jī)進(jìn)程和本地磁盤全部消失只保留鏡像和實(shí)例元數(shù)據(jù)。如果還執(zhí)行了shelve_offload連計(jì)算節(jié)點(diǎn)上殘留的快照文件也會(huì)被清掉實(shí)例在計(jì)算節(jié)點(diǎn)上的占用量接近于零?；謴?fù)擱置實(shí)例要執(zhí)行openstack server unshelve。Nova會(huì)從Glance讀取shelve時(shí)創(chuàng)建的鏡像重新調(diào)度計(jì)算節(jié)點(diǎn)重新創(chuàng)建虛機(jī)。整個(gè)過程相當(dāng)于用“備份鏡像”重新創(chuàng)建了一臺(tái)同名同ID的實(shí)例。shelve最大的價(jià)值在于長期釋放計(jì)算資源。比如一批測試機(jī)周末沒人用直接shelve掉等周一再unshelve回來能省下大量內(nèi)存和CPU資源。如果測試機(jī)很多這個(gè)操作可以顯著降低宿主機(jī)資源壓力。但shelve有個(gè)大坑實(shí)例的臨時(shí)盤ephemeral和本地?cái)?shù)據(jù)盤不會(huì)保留。shelve時(shí)只上傳系統(tǒng)盤臨時(shí)盤的內(nèi)容會(huì)丟失。如果你的應(yīng)用把數(shù)據(jù)寫在本地盤上shelve之后這些數(shù)據(jù)就沒了。因此生產(chǎn)實(shí)例除非確認(rèn)所有數(shù)據(jù)都已經(jīng)落到Cinder卷或?qū)ο蟠鎯?chǔ)否則不建議shelve。另外unshelve之后實(shí)例的IP地址在網(wǎng)絡(luò)層面會(huì)保留端口還在但guest OS的配置可能需要重新檢查特別是自定義了網(wǎng)卡配置的鏡像。3.4 lock與unlock防手滑的保險(xiǎn)鎖定lock是一個(gè)很不起眼但非常實(shí)用的操作。執(zhí)行openstack server lock后實(shí)例處于LOCKED狀態(tài)所有修改型操作reboot、resize、delete、stop、start、rebuild等都會(huì)被Nova拒絕只有只讀操作和網(wǎng)絡(luò)查看操作可以執(zhí)行。這個(gè)操作特別適合生產(chǎn)環(huán)境。我見過不止一次因?yàn)檎`操作把線上數(shù)據(jù)庫實(shí)例給刪了或者重啟了。在OpenStack里加上lock之后即使有人拿著管理員的OpenRC環(huán)境變量誤敲了deleteAPI也會(huì)直接返回錯(cuò)誤相當(dāng)于給實(shí)例上了一道保險(xiǎn)。解鎖也很簡單openstack server unlock。如果你是管理員普通用戶鎖定的實(shí)例你也可以用openstack server unlock --force強(qiáng)制解鎖。但要注意lock保護(hù)的是OpenStack API層面的操作它擋不住管理員直接登錄計(jì)算節(jié)點(diǎn)執(zhí)行virsh destroy。換句話說lock是給“正常人”用的鎖不是給鐵了心想搞破壞的人用的。不過在常規(guī)運(yùn)維流程中給核心數(shù)據(jù)庫、核心業(yè)務(wù)實(shí)例加上lock就是個(gè)好習(xí)慣成本幾乎為零。4. 恢復(fù)與重建類操作快照、重建、救援4.1 snapshot操作前先留后路創(chuàng)建快照snapshot是Nova里最值得養(yǎng)成的習(xí)慣之一。執(zhí)行openstack server image create --name snapshot_name server會(huì)把當(dāng)前實(shí)例的系統(tǒng)盤制作成一個(gè)鏡像上傳到Glance之后可以用這個(gè)鏡像創(chuàng)建新實(shí)例也可以作為rebuild的底子?？煺盏牡讓釉韺?duì)qcow2系統(tǒng)盤來說是一個(gè)在線鏡像合并操作。libvirt會(huì)發(fā)起一個(gè)live snapshot先創(chuàng)建一個(gè)新的qcow2覆蓋層overlay然后把當(dāng)前系統(tǒng)的所有寫入引導(dǎo)到新層同時(shí)后臺(tái)將舊層的所有數(shù)據(jù)合并上傳到Glance。這個(gè)過程對(duì)運(yùn)行中的虛機(jī)影響很小業(yè)務(wù)基本無感知。但有一種情況需要注意如果你的系統(tǒng)盤數(shù)據(jù)量特別大比如200GB的數(shù)據(jù)庫系統(tǒng)盤快照過程會(huì)持續(xù)很久期間磁盤IO會(huì)明顯上升應(yīng)用寫入性能可能受到影響。為了保證快照一致性數(shù)據(jù)庫類實(shí)例建議先短暫pause快照完成后再unpause。這樣能避免系統(tǒng)盤在快照過程中有未落盤的臟頁。當(dāng)然pause會(huì)影響業(yè)務(wù)需要和業(yè)務(wù)方確認(rèn)停機(jī)窗口。如果沒有停機(jī)窗口也建議在業(yè)務(wù)低峰期做快照。快照還有一個(gè)非常常見的用途——成為“模板”。我經(jīng)常通過快照把一臺(tái)配置好的環(huán)境復(fù)制成多臺(tái)測試機(jī)比如初始化好的Web環(huán)境、裝好agent的監(jiān)控環(huán)境快照比從頭創(chuàng)建省時(shí)間得多。快照占用的存儲(chǔ)空間和系統(tǒng)盤實(shí)際使用量接近存儲(chǔ)不夠的話快照很容易失敗所以Glance存儲(chǔ)的容量規(guī)劃也要提前做好。4.2 rebuild保留實(shí)例身份的系統(tǒng)盤重置重建rebuild是Nova里最“神奇”的操作之一。執(zhí)行openstack server rebuild --image image server后實(shí)例會(huì)用指定的鏡像重新生成系統(tǒng)盤但實(shí)例的ID、IP地址、數(shù)據(jù)卷保持原樣guest OS收到“系統(tǒng)盤被整個(gè)替換”的處理方式。rebuild的本質(zhì)是Nova把實(shí)例的元數(shù)據(jù)保留重新創(chuàng)建一塊新的系統(tǒng)盤使用指定的鏡像然后把舊系統(tǒng)盤丟棄虛機(jī)用新盤重新啟動(dòng)。這和刪除重建完全不同——?jiǎng)h除重建會(huì)換ID、換IP而rebuild不會(huì)所以對(duì)業(yè)務(wù)感知來說更像是一次“系統(tǒng)重裝”。很多運(yùn)維會(huì)用rebuild來快速恢復(fù)被惡意篡改的系統(tǒng)、修復(fù)損壞的系統(tǒng)文件、解決啟動(dòng)障礙。rebuild有一個(gè)很關(guān)鍵的參數(shù)--preserve-ephemeral。如果實(shí)例有ephemeral盤默認(rèn)情況下rebuild會(huì)把臨時(shí)盤也一起清掉加上這個(gè)參數(shù)后臨時(shí)盤數(shù)據(jù)會(huì)保留。但即使加了保留臨時(shí)盤系統(tǒng)盤上所有改動(dòng)也會(huì)丟失所以rebuild前確認(rèn)系統(tǒng)盤上有沒有需要保留的文件如果沒有備份先做快照再rebuild。rebuild是最適合“系統(tǒng)盤中毒、配置全亂、內(nèi)核損壞”這類場景的武器。比如某個(gè)實(shí)例被勒索軟件加密了系統(tǒng)盤直接rebuild回鏡像初始化狀態(tài)比慢慢殺毒修復(fù)快得多。只要你的數(shù)據(jù)都在Cinder卷上rebuild就沒什么負(fù)擔(dān)。4.3 rescue進(jìn)救援模式修系統(tǒng)救援rescue是Nova里最被低估的操作。執(zhí)行openstack server rescue后Nova會(huì)把當(dāng)前實(shí)例關(guān)機(jī)然后用一個(gè)指定的救援鏡像默認(rèn)使用實(shí)例原本的鏡像啟動(dòng)一個(gè)“救援實(shí)例”原實(shí)例的系統(tǒng)盤作為數(shù)據(jù)盤掛載到救援實(shí)例上。此時(shí)原實(shí)例狀態(tài)變?yōu)镽ESCUED你可以通過VNC或者SSH登錄救援實(shí)例然后掛載原系統(tǒng)盤去修復(fù)里面的文件。這個(gè)場景太適合“啟動(dòng)不了”的實(shí)例了。比如某個(gè)實(shí)例開機(jī)直接進(jìn)入緊急模式grub損壞或者關(guān)鍵系統(tǒng)服務(wù)起不來你可以rescue進(jìn)去mount原盤刪掉有問題的配置文件、修復(fù)fstab、重裝引導(dǎo)然后執(zhí)行openstack server unrescue原實(shí)例會(huì)恢復(fù)為ACTIVE狀態(tài)并再次嘗試啟動(dòng)。rescue的默認(rèn)行為有幾個(gè)細(xì)節(jié)需要注意。第一rescue后的救援實(shí)例和原實(shí)例共享同一個(gè)計(jì)算節(jié)點(diǎn)網(wǎng)卡是新建的IP會(huì)變你需要通過openstack server show查看救援實(shí)例的IP地址再去登錄。第二原實(shí)例的系統(tǒng)盤掛載為數(shù)據(jù)盤路徑通常是/dev/vdb或/dev/vdc具體可以執(zhí)行l(wèi)sblk查看。第三如果實(shí)例處于ERROR狀態(tài)有時(shí)無法直接rescue需要先確認(rèn)是否能被nova-compute識(shí)別。救援模式是我在OpenStack排障里用得最多的功能之一。很多人遇到實(shí)例啟動(dòng)失敗第一反應(yīng)是刪了重建但這樣會(huì)丟失IP和本地配置。其實(shí)先用rescue進(jìn)去看一眼十有八九能救回來。5. 遷移與疏散類操作migrate、evacuate、resize5.1 migrate冷遷移與熱遷移的取舍遷移migrate是OpenStack運(yùn)維繞不開的話題。openstack server migrate默認(rèn)執(zhí)行冷遷移它要求實(shí)例處于SHUTOFF狀態(tài)Nova會(huì)將實(shí)例的磁盤文件從源計(jì)算節(jié)點(diǎn)復(fù)制到目標(biāo)計(jì)算節(jié)點(diǎn)然后在目標(biāo)節(jié)點(diǎn)重新啟動(dòng)。整個(gè)過程業(yè)務(wù)是中斷的但數(shù)據(jù)完整性最有保障。熱遷移live migrate則完全不同命令是openstack server migrate --live target-host或者通過nova live-migration操作。熱遷移基于KVM原生的live migration能力先把源節(jié)點(diǎn)的實(shí)例內(nèi)存狀態(tài)持續(xù)復(fù)制到目標(biāo)節(jié)點(diǎn)當(dāng)雙方內(nèi)存數(shù)據(jù)達(dá)到同步后瞬間切換網(wǎng)絡(luò)和磁盤IO業(yè)務(wù)幾乎無感知。整個(gè)過程中虛機(jī)不關(guān)機(jī)、不中斷非常適合數(shù)據(jù)庫、在線交易這類不能停的服務(wù)。熱遷移的工作機(jī)制是QEMU通過內(nèi)存預(yù)復(fù)制pre-copy流程循環(huán)迭代地把源節(jié)點(diǎn)虛機(jī)的內(nèi)存頁面復(fù)制到目標(biāo)節(jié)點(diǎn)同時(shí)跟蹤臟頁直到剩余臟頁足夠小再執(zhí)行停機(jī)拷貝stop-and-copy最后在目標(biāo)節(jié)點(diǎn)恢復(fù)運(yùn)行。如果你的實(shí)例內(nèi)存寫入非常頻繁比如每分鐘幾百M(fèi)B的寫入臟頁迭代可能永遠(yuǎn)追不上熱遷移直接掛在MIGRATING狀態(tài)。熱遷移還有兩個(gè)關(guān)鍵前提。第一源節(jié)點(diǎn)和目標(biāo)節(jié)點(diǎn)必須能訪問同一個(gè)系統(tǒng)盤文件最典型的就是共享存儲(chǔ)Shared Storage比如把系統(tǒng)盤放在Ceph或者NFS共享目錄上。沒有共享存儲(chǔ)時(shí)Nova會(huì)啟用塊遷移block migration把本地磁盤也一并復(fù)制過去復(fù)制大磁盤會(huì)讓遷移時(shí)間變得不可控。第二網(wǎng)絡(luò)必須互通虛機(jī)的虛擬網(wǎng)卡需要能在目標(biāo)節(jié)點(diǎn)上正常掛載到同一張網(wǎng)橋或虛擬交換機(jī)。我做熱遷移時(shí)最深的體會(huì)是遷移前一定先壓測或觀察實(shí)例的內(nèi)存寫頻率。如果instance的臟頁率太高熱遷移很可能永遠(yuǎn)完不成這時(shí)候?qū)幙赏C(jī)做冷遷移也別一個(gè)任務(wù)掛在MIGRATING上熬到半夜。另外熱遷移完成后記得檢查實(shí)例的新宿主有時(shí)因?yàn)槟繕?biāo)節(jié)點(diǎn)資源不足虛機(jī)被調(diào)度到意料之外的節(jié)點(diǎn)業(yè)務(wù)架構(gòu)的拓?fù)渚妥兞恕?.2 evacuate計(jì)算節(jié)點(diǎn)宕機(jī)時(shí)的救命操作疏散evacuate是所有OpenStack運(yùn)維最希望永遠(yuǎn)用不上、但必須熟練掌握的操作。當(dāng)某臺(tái)計(jì)算節(jié)點(diǎn)物理宕機(jī)或網(wǎng)絡(luò)隔離時(shí)它上面運(yùn)行的所有實(shí)例都會(huì)進(jìn)入ERROR狀態(tài)里面的虛機(jī)實(shí)際上已經(jīng)“死亡”了。普通Cold Migrate和熱遷移都要求源節(jié)點(diǎn)能正常通信一旦源節(jié)點(diǎn)失聯(lián)唯一恢復(fù)實(shí)例的方法就是evacuate。openstack server evacuate --host target-host server會(huì)通知nova-scheduler在其他可用計(jì)算節(jié)點(diǎn)上重新啟動(dòng)該實(shí)例。注意evacuate不是遷移它默認(rèn)不會(huì)保留原來的系統(tǒng)盤數(shù)據(jù)——除非你用了共享存儲(chǔ)。如果系統(tǒng)盤放在Ceph等共享存儲(chǔ)上新節(jié)點(diǎn)可以直接掛載同一份數(shù)據(jù)業(yè)務(wù)恢復(fù)后數(shù)據(jù)完好無損。如果系統(tǒng)盤是本地盤源節(jié)點(diǎn)都掛了本地?cái)?shù)據(jù)根本讀不出來evacuate后實(shí)例會(huì)從鏡像重新創(chuàng)建系統(tǒng)盤本地?cái)?shù)據(jù)等于全部丟失。這就是OpenStack架構(gòu)設(shè)計(jì)里一個(gè)非常重要的取舍生產(chǎn)環(huán)境的系統(tǒng)盤和數(shù)據(jù)盤到底放本地還是共享存儲(chǔ)。我的建議是核心業(yè)務(wù)一定要走共享存儲(chǔ)在Ceph上因?yàn)橹挥羞@樣才能在計(jì)算節(jié)點(diǎn)故障時(shí)做到快速恢復(fù)。如果為了省錢把系統(tǒng)盤全放本地一旦宿主機(jī)壞了只能和不完整的數(shù)據(jù)說再見。evacuate的恢復(fù)時(shí)間取決于鏡像大小、目標(biāo)節(jié)點(diǎn)資源、網(wǎng)絡(luò)復(fù)制速度但一般來說比重建快得多操作得當(dāng)幾分鐘內(nèi)就能恢復(fù)服務(wù)。evacuate有一個(gè)常見的坑如果實(shí)例配置了admin_pass或者自定義了密碼注入evacuate后可能需要重新通過VNC設(shè)置密碼新節(jié)點(diǎn)上的實(shí)例可能和舊實(shí)例的guest OS狀態(tài)不一致。所以每次evacuate后建議第一時(shí)間檢查實(shí)例的啟動(dòng)日志console log和網(wǎng)絡(luò)連通性確認(rèn)服務(wù)真正恢復(fù)再切換流量。5.3 resize變配不只是改flavor變配resize是Nova里最容易出問題的操作之一。openstack server resize --flavor new_flavor server會(huì)把實(shí)例遷移到能承載新flavor的計(jì)算節(jié)點(diǎn)也可能是同一臺(tái)節(jié)點(diǎn)然后重新定義虛機(jī)的CPU、內(nèi)存和磁盤大小。如果新flavor的磁盤比原來大系統(tǒng)盤會(huì)被擴(kuò)容如果比原來小系統(tǒng)盤文件不變但可能會(huì)有多余空間無法利用。resize完成后實(shí)例會(huì)進(jìn)入VERIFY_RESIZE狀態(tài)你需要手動(dòng)執(zhí)行openstack server resize confirm確認(rèn)變更或者openstack server resize revert回滾到原來的flavor。這里有個(gè)非常關(guān)鍵的時(shí)間窗口如果設(shè)置了resize_confirm_window比如24小時(shí)超過該時(shí)間后Nova會(huì)自動(dòng)confirm如果沒有設(shè)置實(shí)例可能一直停留在VERIFY_RESIZE狀態(tài)直到你手動(dòng)確認(rèn)。resize最坑的一點(diǎn)是默認(rèn)情況下resize會(huì)執(zhí)行冷遷移意味著實(shí)例會(huì)關(guān)機(jī)業(yè)務(wù)中斷時(shí)間可能在幾分鐘到幾十分鐘不等。你需要在變配窗口內(nèi)完成全部操作。如果業(yè)務(wù)不允許中斷可以考慮支持在線變配的版本或使用專門的縮擴(kuò)容方案但OpenStack社區(qū)版本默認(rèn)不提供CPU/內(nèi)存熱插拔。變配之前強(qiáng)烈建議先做快照因?yàn)閞esize過程如果失敗原實(shí)例的磁盤文件可能被重新調(diào)度到別的節(jié)點(diǎn)恢復(fù)起來非常麻煩。我在生產(chǎn)環(huán)境變配時(shí)有一個(gè)固定流程先看新flavor的磁盤大小是否足夠再看實(shí)例當(dāng)前所在宿主機(jī)的資源是否滿足新flavor有時(shí)候Nova不會(huì)遷移直接原地調(diào)整最后執(zhí)行resize等VERIFY_RESIZE狀態(tài)后檢查虛機(jī)狀態(tài)和業(yè)務(wù)確認(rèn)無誤再confirm。如果resize后業(yè)務(wù)異常就revert回滾。這個(gè)流程雖然保守但從來沒出過事故。6. 與外部資源聯(lián)動(dòng)的操作卷掛載與浮動(dòng)IP6.1 attach與detach volume數(shù)據(jù)盤怎么接實(shí)例只有一塊系統(tǒng)盤很多時(shí)候不夠用Cinder卷云硬盤就派上用場了。Nova這里對(duì)應(yīng)的操作是attach和detach。命令分別是openstack server add volume server volume和openstack server remove volume server volume。把Cinder卷掛到實(shí)例上之后它在guest OS里的表現(xiàn)就是一塊新的塊設(shè)備比如/dev/vdb或/dev/vdc。系統(tǒng)不會(huì)自動(dòng)分區(qū)、不會(huì)自動(dòng)格式化、也不會(huì)自動(dòng)掛載到某個(gè)目錄這一切都需要你進(jìn)入實(shí)例手動(dòng)完成。很多新手掛載完卷之后以為直接就能用了結(jié)果lsblk一查發(fā)現(xiàn)根本沒出現(xiàn)這是因?yàn)閴K設(shè)備需要在系統(tǒng)層面做分區(qū)、格式化、掛載。我會(huì)在卷掛載完成后用lsblk確認(rèn)設(shè)備已識(shí)別然后mkfs.ext4 /dev/vdb格式化如果新卷再mkdir /data mount /dev/vdb /data如果需要開機(jī)自動(dòng)掛載還要配置 /etc/fstab。如果掛載的是啟動(dòng)卷bootable volume你可以直接用這個(gè)卷作為實(shí)例的系統(tǒng)盤啟動(dòng)。這種情況在需要從快照卷恢復(fù)數(shù)據(jù)或者更換系統(tǒng)盤時(shí)特別有用。detach操作看起來簡單其實(shí)是個(gè)危險(xiǎn)動(dòng)作。如果guest OS還在讀寫這個(gè)卷直接detach會(huì)導(dǎo)致文件系統(tǒng)損壞或者IO錯(cuò)誤。正確的流程是先登錄實(shí)例執(zhí)行umount卸載掛載點(diǎn)確認(rèn)沒有進(jìn)程占用該設(shè)備然后再在OpenStack側(cè)執(zhí)行remove volume。如果實(shí)在無法登錄實(shí)例但又要強(qiáng)制下線數(shù)據(jù)盤需要在Nova側(cè)強(qiáng)制解綁這種做法有數(shù)據(jù)損壞風(fēng)險(xiǎn)不到萬不得已不要用。卷掛載還有一個(gè)常見問題掛載了多塊卷之后設(shè)備名在重啟后可能發(fā)生漂移。比如 /dev/vdb 重啟后變成了 /dev/vdc。這是因?yàn)長inux內(nèi)核枚舉設(shè)備的順序不完全固定。生產(chǎn)環(huán)境我建議通過UUID或者標(biāo)簽LABEL來掛載設(shè)備不要直接寫死/dev/vdb這樣可以避免啟動(dòng)后掛載失敗的尷尬。6.2 浮動(dòng)IP的關(guān)聯(lián)與解綁浮動(dòng)IPFloating IP是OpenStack里讓外部網(wǎng)絡(luò)訪問實(shí)例的標(biāo)準(zhǔn)方式。實(shí)例默認(rèn)可能只有內(nèi)網(wǎng)IP外部無法直接訪問。執(zhí)行openstack server add floating ip server floating_ip就把一個(gè)公網(wǎng)IP綁定到實(shí)例上解綁是openstack server remove floating ip server floating_ip。浮動(dòng)IP的本質(zhì)是iptables的DNAT規(guī)則在Neutron的路由節(jié)點(diǎn)或虛擬路由器上把浮動(dòng)IP的流量映射到實(shí)例的內(nèi)網(wǎng)IP。實(shí)例自身感知不到浮動(dòng)IP的存在它的網(wǎng)卡配置依然是內(nèi)網(wǎng)IP。所以解綁浮動(dòng)IP后實(shí)例的內(nèi)部網(wǎng)絡(luò)、內(nèi)網(wǎng)服務(wù)完全不受影響只是外部無法再通過那個(gè)公網(wǎng)IP訪問它。浮動(dòng)IP關(guān)聯(lián)和云主機(jī)本身的“多網(wǎng)卡配置”不要混淆。如果你需要多塊網(wǎng)卡、多個(gè)內(nèi)網(wǎng)IP應(yīng)該創(chuàng)建多個(gè)端口port然后附加到實(shí)例上。浮動(dòng)IP只是外網(wǎng)出入口的映射和網(wǎng)卡數(shù)量無關(guān)。實(shí)際運(yùn)維中我經(jīng)常用浮動(dòng)IP做“故障切換”。比如一臺(tái)Web實(shí)例掛了我可以先把浮動(dòng)IP從故障實(shí)例解綁再綁定到備用實(shí)例上實(shí)現(xiàn)秒級(jí)切換。這個(gè)操作比改DNS快得多非常適合對(duì)中斷時(shí)間敏感的場景。要注意的是浮動(dòng)IP解綁后原來實(shí)例的外網(wǎng)連接會(huì)立即斷開如果業(yè)務(wù)里有長連接比如數(shù)據(jù)庫的外網(wǎng)連接池全部重連的成本也要考慮到。7. 實(shí)戰(zhàn)速查故障場景操作組合與高頻坑位7.1 典型運(yùn)維場景的操作組合Nova的16種操作很少單獨(dú)使用實(shí)際運(yùn)維中經(jīng)常是組合拳。我挑幾個(gè)高頻場景把操作串聯(lián)起來講一遍。場景一宿主機(jī)計(jì)劃維護(hù)。比如要對(duì)計(jì)算節(jié)點(diǎn)做內(nèi)核升級(jí)。正確做法是先把該節(jié)點(diǎn)上所有實(shí)例都執(zhí)行openstack server migrate --live熱遷移出去如果熱遷移條件不滿足或者實(shí)例狀態(tài)不健康就改成suspend等節(jié)點(diǎn)維護(hù)完再批量resume。這里的決策順序是先看共享存儲(chǔ)是否可用再看實(shí)例是否允許短時(shí)間暫停。熱遷移最推薦因?yàn)樗鼘?duì)業(yè)務(wù)影響最小沒有共享存儲(chǔ)時(shí)才退而求其次用suspend。場景二實(shí)例系統(tǒng)盤被入侵或損壞嚴(yán)重。首先執(zhí)行openstack server image create創(chuàng)建快照留作證據(jù)或后續(xù)分析然后執(zhí)行openstack server rebuild --image 原鏡像快速恢復(fù)。如果rebuild后還是起不來再考慮openstack server rescue進(jìn)入救援模式修復(fù)。這個(gè)順序比較重要先保存現(xiàn)場再快速恢復(fù)最后才深入修復(fù)。場景三實(shí)例負(fù)載持續(xù)增長需要擴(kuò)大規(guī)格。執(zhí)行openstack server resize --flavor 大規(guī)格實(shí)例進(jìn)入VERIFY_RESIZE狀態(tài)后檢查業(yè)務(wù)是否正常確認(rèn)無誤再執(zhí)行openstack server resize confirm。如果異常執(zhí)行openstack server resize revert回滾。變配之前先做snapshot整個(gè)過程避免在業(yè)務(wù)高峰期進(jìn)行。場景四計(jì)算節(jié)點(diǎn)宕機(jī)。先確認(rèn)節(jié)點(diǎn)確實(shí)失聯(lián)然后用openstack server evacuate --host 其他節(jié)點(diǎn) server把實(shí)例一一疏散。如果系統(tǒng)盤在共享存儲(chǔ)上數(shù)據(jù)不會(huì)丟如果系統(tǒng)盤在本地要有數(shù)據(jù)丟失的心理準(zhǔn)備。疏散完成后檢查實(shí)例的console log和網(wǎng)絡(luò)連通性確認(rèn)服務(wù)恢復(fù)后再把流量切回。整個(gè)過程中可以利用浮動(dòng)IP解綁/綁定做流量切換。7.2 高頻問題排查速查表故障現(xiàn)象可能原因排查與解決辦法實(shí)例一直停留在BUILD狀態(tài)鏡像過大、資源不足、調(diào)度失敗檢查計(jì)算節(jié)點(diǎn)的可用內(nèi)存/CPU查看nova-compute日志確認(rèn)鏡像下載是否完成關(guān)機(jī)stop后狀態(tài)仍為ACTIVEguest OS沒有響應(yīng)ACPI關(guān)機(jī)信號(hào)檢查guest內(nèi)acpid服務(wù)或者用--os-stop-hard強(qiáng)制關(guān)機(jī)實(shí)例狀態(tài)為ERROR但task_state為空磁盤空間不足、鏡像損壞、網(wǎng)絡(luò)插件失敗查看nova-compute和neutron日志確認(rèn)是否磁盤滿清理空間后重置狀態(tài)pause之后計(jì)算節(jié)點(diǎn)重啟實(shí)例狀態(tài)異常PAUSED狀態(tài)不持久化之后盡量用suspend替代pause做長時(shí)間凍結(jié)resize后忘記confirm實(shí)例卡在VERIFY_RESIZEresize_confirm_window未設(shè)置或還沒到超時(shí)手動(dòng)執(zhí)行openstack server resize confirm或者根據(jù)業(yè)務(wù)情況revert熱遷移長時(shí)間卡在MIGRATING內(nèi)存臟頁率過高迭代無法收斂停止高寫入負(fù)載等待遷移完成或者取消遷移改為冷遷移evacuate后實(shí)例數(shù)據(jù)丟失系統(tǒng)盤放在本地盤而非共享存儲(chǔ)排查源節(jié)點(diǎn)是否能恢復(fù)數(shù)據(jù)不能恢復(fù)只能從鏡像重建后續(xù)建議系統(tǒng)盤遷移到共享存儲(chǔ)掛載卷后實(shí)例內(nèi)看不到設(shè)備卷掛載成功但guest OS未識(shí)別或未分區(qū)進(jìn)入實(shí)例執(zhí)行l(wèi)sblk檢查新卷需要分區(qū)、格式化、掛載快照成功但新實(shí)例創(chuàng)建失敗快照時(shí)系統(tǒng)盤不一致或鏡像元數(shù)據(jù)損壞檢查Glance鏡像狀態(tài)嘗試重新創(chuàng)建快照或者基于快照做rebuild驗(yàn)證lock之后還能被強(qiáng)制刪除管理員用了--force解鎖生產(chǎn)環(huán)境通過RBAC權(quán)限控制限制普通用戶對(duì)核心實(shí)例的管理權(quán)限7.3 最后再分享兩個(gè)經(jīng)驗(yàn)寫到這里收尾之前我還是想多說幾句個(gè)人體會(huì)。第一個(gè)是關(guān)于操作習(xí)慣。我見過太多人在OpenStack上直接敲命令完全不管當(dāng)前實(shí)例狀態(tài)結(jié)果就是各種奇奇怪怪的操作沖突。其實(shí)Nova的命令設(shè)計(jì)得很“講道理”大多數(shù)操作都有前置狀態(tài)要求你只要在操作前執(zhí)行openstack server show看一眼狀態(tài)絕大多數(shù)事故都能避免。我自己現(xiàn)在養(yǎng)成了習(xí)慣凡是生產(chǎn)實(shí)例操作前必看狀態(tài)和task_state寧可多花五秒查看也不愿花五小時(shí)處理誤操作。第二個(gè)是關(guān)于鏡像和備份的執(zhí)念。Nova再強(qiáng)大也擋不住存儲(chǔ)層面的物理故障和邏輯錯(cuò)誤。我的原則是所有核心實(shí)例至少保留最近一份快照所有數(shù)據(jù)卷定期做Cinder備份所有配置變更前先出快照。這個(gè)習(xí)慣救了我太多次甚至有一次整臺(tái)計(jì)算節(jié)點(diǎn)的磁盤陣列故障我硬是靠前一天晚上的快照把十幾臺(tái)實(shí)例全部恢復(fù)到了可用狀態(tài)。Nova的16種操作只是工具集真正的安全墊永遠(yuǎn)是備份意識(shí)和紀(jì)律性。希望這篇整理能幫你把工具用熟也把備份的習(xí)慣刻進(jìn)肌肉記憶里。