雲與備份之（1）：VMware虛機備份和恢復

阿新 • • 發佈：2021-08-17

本系列文章會介紹雲與備份之間的關係，包括：

（1）VMware 虛機備份和恢復

（2）KVM 虛機備份和恢復

（3）雲與備份

（4）OpenStack 與備份

（5）公有云與備份

1. 與備份有關的VMWare基礎知識

1.1 VMware 虛機磁碟在 ESXi 宿主機上的檔案

簡單來說，虛機的每個虛擬磁碟由ESXi 宿主機上的三個檔案組成（這裡的虛機名字是 sammy-target-win-small，下面是其第一個磁碟對應的三個檔案）：

sammy-target-win-small.vmdk （配置檔案，大小 633 位元組）
sammy-target-win-small-flat.vmdk （二進位制檔案，大小 12884901888 位元組）

sammy-target-win-small-ctk.vmdk （二進位制檔案，大小 78694 位元組）

其中，

第一個檔案儲存的是該磁碟的元資料，其中包括另外兩個檔案的資訊

# Extent description
RW 25165824 VMFS "sammy-target-win-small-flat.vmdk"

# Change Tracking File
changeTrackPath="sammy-target-win-small-ctk.vmdk"

第二個檔案是 Extent description 檔案，二進位制資料儲存在這個檔案中。下面會介紹使用API獲取該檔案中資料的方法。

第三個檔案是 CTK 檔案。下面講到 CTK 的時候再說。

1.2 快照（Snapshot）

虛機的快照是虛機在某個時間點的狀態和資料，其中，狀態是指虛機的狀態，包括執行狀態，配置等；資料是指虛機的虛擬磁碟中的資料。快照的基本操作包括：

建立快照（create）
刪除快照（delete）
快照合併（consolidate）
恢復到快照（revert）

1.2.1 建立快照

對上面的虛機建立一個快照，除了快照定義檔案以外，對該磁碟，新增了三個檔案：

-rw-------    1 root     root        786944 Jul 11 10:55 sammy-target-win-small-000001-ctk.vmdk
-rw-------    1 root     root         28672 Jul 11 10:55 sammy-target-win-small-000001-delta.vmdk
-rw-------    1 root     root           428 Jul 11 10:55 sammy-target-win-small-000001.vmdk

第一個依然是 ctk 檔案，第二個是 delta 檔案，第三個是非二進位制檔案。然後再建立第二個快照，就成了這樣子：

（RW = 讀寫，RO = 只讀）

從資料的角度看：

（綠色部分是從虛機視角看資料；最下面的紅框是 base vmdk 中的資料；中間的紅框是 delta vmdk 中的資料）

現在可以簡單總結一下 VMware 快照的特點：

快照儲存虛機在某一個時間點的狀態和資料
對一個虛機做快照，相當於將虛機當前的磁碟設為只讀模式，然後建立 delta vmdk 檔案，它將會接受新的資料寫操作。在存在多個快照的情況下，之前的快照磁碟變為只讀。
寫損失：寫的時候，遵循 Copy-on-write 機制，按照資料分塊，當需要修改某一塊中的資料時，先將它從父vmdk 中拷貝到 delta vmdk，然後再對它修改。
讀損失：當讀取某一塊資料時，ESXi 需要判斷從哪裡去讀：對於沒有修改的資料塊，從父 vmdk 讀；對已經修改了的資料塊，從 delta vmdk 讀。可見，客戶端的一次讀操作，可能需要從不同的 vmdk 上讀取資料。
delta vmdk 的大小不會超過 base vmdk 的大小，因為極限情況是所有的資料都被拷貝到delta vmdk 並且都沒修改了。
因為快照會帶來讀和寫損失，因此一個虛機不能有太多的快照。vSphere 限定一個虛機最多有 32 個快照，但是建議最多隻有 2-3 個，而且快照的保留時間不超過一天。

1.2.2 刪除快照

顯然，快照只是內部資料，儲存的是過去某時間點虛機的狀態，對外部不可見，因此，刪除快照不能影響虛機當前的狀態和資料。因此，這裡有三種可能：

（1）快照是基於原始虛機的：delta vmdk 中的資料會向 base vmdk 合併，然後 delta vmdk 被刪除。（如下圖中的s1）

（2）待刪除快照在虛機的資料路徑上：delta vmdk 中的資料會想父快照的 vmdk 合併，然後delta vmdk 被刪除。（如下圖中的s2）

（3）待刪除快照不再虛機的資料路徑上：不需要合併，直接刪除。（如下圖中的 s3）

現在可以簡單總結一下刪除快照的特點：

刪除快照意味著快照之後的改變會被合併進快照之前的資料，因此，虛機再也無法回到所做快照之時的狀態了。
刪除快照過程包括兩個非同步的操作：從 Snapshot manager 中將快照刪除，vmdk 資料合併。如果第一步成功而第二步失敗，那麼將有殘留的 delta 檔案被保留下來，這是就需要下面將介紹的手工合併操作。
刪除快照可能會打來大量的資料寫操作，這期間，虛機的效能會受到負面影響
刪除快照有時候要花費很長的時間，特別是對於長時間存在的大容量磁碟的快照。 VMware 專門出了一個KB來讓使用者估計所需要的時間：Estimating the time required to consolidate snapshots during the snapshot removal for VMware ESX and VMware ESXi (2053758)
當刪除所有快照時，自從 vSphere 4 Update 2 開始起過程有了優化，不再是重定向下一層一層地合併，而是各層都直接合併到 base disk。

1.2.3 快照合併（consolidation）

上面談到了快照刪除操作的資料合併可能會失敗。這種失敗會帶來很多問題，包括不必要的磁碟空間佔用，以及虛機效能下降。因此，當出現這種情況時，vCenter 會向用戶提示需要做 consolidation 了。該操作會檢查虛機當前所有的 vmdk 分層，將冗餘的 delta 檔案先合併再刪除。

1.2.4 恢復到快照

恢復到快照操作也比較好理解，就是將虛機的 base vmdk 指向目標快照的 vmdk，其結果是自從目標快照建立後的一切改動都沒有了。

1.3 VMware API

VMware 提供非常豐富的 API：

其中，我們可以將與與備份相關的API分為兩類，一類是控制平面的API，它們主要用做管理 vSphere 虛擬化環境；另一類是資料平面API，它們用於操作虛機的虛擬磁碟。

1.3.1 VMware API 和 SDK

VMware 通過 Web Service 向客戶端提供訪問介面，這些介面可用於管理虛機和其他虛擬設施，包括資料中心（datacenter），資料儲存（datastore）, 網路（network）等。它還提供了包括Java, .NET, Python, Perl, REST, 以及 Ruby 等幾種語言在內的 SDK。對於其他語言，則需要通過 SOAP 協議訪問其 web service，gSoap 是一種比較常見的用於C/C++語言編寫 web service 客戶端程式的套件。

詳細情況請閱讀https://www.vmware.com/support/pubs/sdk_pubs.html

1.3.2 VDDK 和 VADP

VDDK 全稱是 Virtual Disk Development Kit（虛擬磁碟開發包），它能幫助開發人員建立訪問虛機儲存的應用。VDDK 基於 Virtual disk API。

Virtual disk API，即 VixDiskLib，是一組操作 VMDK 格式的虛擬磁碟檔案的函式。它的主要功能包括：

create, convert, expand, defragment, shrink, and rename 虛擬磁碟檔案
建立 redo logs 和刪除 vmdk 檔案
訪問 vmdk 檔案中任意資料，以及讀取元資料
連線到遠端 vSphe 儲存，使用高階的傳輸方式，包括 SAN （備份程式所在的伺服器能夠直接通過 FC 或者 iSCSI 和虛機磁碟所在的儲存連線），hotadd （虛擬磁碟附加到備份程式所在虛機成為其一個磁碟）和 LAN （備份程式通過 LAN 訪問虛擬磁碟）。

VADP 全稱是 VMware Storage APIs - Data Protection（VMware 儲存API-資料保護），它使用 virtual disk API 和部分 vSphre API 來建立和管理虛機的快照，支援全量和增量備份。

1.4 CBT (Changed Block Tracking 塊修改跟蹤)

CBT 是 VMware 在 vSphere 4.0 版本引入的為了實現增量備份的一個功能。VDAP 使用該功能，使得基於它開發的各種虛機備份應用能夠做到增量備份。

相對於全量備份時將vmdk 的全部資料塊都儲存下來（左圖），基於 CBT 的增量備份只儲存自從上次備份以來的發生了變化了的資料塊（右圖）。ESXi 為每個開啟了 CBT 的虛機的虛擬磁碟都建立了一個 ctk 檔案，它用於儲存變化塊的元資料。該功能將會對磁碟帶來一點效能損失，因為，不使用的時候，可以關閉它，但是它對備份帶來的好處是顯而易見的。

獲取 CBT 變化塊的函式的定義為：QueryChangedDiskAreas(snapshot, deviceKey, startOffSet, changeID)。其中，

snapshot 代表當前的快照，也就是“變化”時間段的後端點；
deviceKey 是目標虛擬磁碟的 device ID；
startOffSet 是開始獲取變化塊的offset；
changeID 是指“變化”時間段的前端點，即老的快照的 changeID。

其結果類似 “(117768192, 65536),(132120576, 65536),(145096704, 43122688),(265289728, 65536),(958398464, 65536)”，每項的格式為（offset，length），表示一個發生變化的資料塊。

1.5 Quiseced Snapshot 和 VMware Tools

虛機快照按照不同的一致性可以分為三種：

崩潰一致快照（crash-consistent snapshot）：當虛機上的應用還在執行，IO 還在進行時進行快照會得到這種快照。它相當於電腦突然斷電了磁碟時的狀態。
檔案系統一致快照（file-system-consistent snapshot）: 在做快照之前，虛機的檔案系統被暫時凍結，記憶體中的髒資料都被刷進磁碟；在快照做完之後，檔案系統被解凍。此時的快照是檔案系統一致的。
應用一致性（application-consistent snapshot）：在做快照之前，應用被暫時凍結，記憶體中應用的所有資料都被刷到磁碟，在快照做完之後，應用被解凍。

預設的快照是第一種，要得到後兩種快照，需要增加相應的步驟。其實現方式主要可以分為兩種：

在較新的 Windows 客戶機上，Windows 提供了 VSS（Volume Shadow Copy Service）服務，它可以通過 requester-writer 方式來實現有凍結需求的應用和檔案系統在快照之前進行凍結和快照之前進行解凍。Microsoft VSS 服務能夠通過協調商務應用（比如SQL Server，Exchange server 以及 Oracle 等），檔案系統，備份應用，快速恢復應用，以及儲存硬體等來提供一致的陰影複製（shadow copies）。
在老的 Windows， VMWare 提供了 SYNC 驅動；在 Linux 系統上，VMware 提供了 vmsync 核心模組來實現檔案系統一致性快照。
在非 Windows 客戶機上要實現應用一致性快照的話，需要編寫具體應用對應的指令碼，在呼叫後對應用進行凍結或者解凍。

那 VSS 服務，SYNC driver， vmsync 核心模組以及自定義指令碼由誰來呼叫呢？VMware 提供了 VMware Tools，它是一個獨立的程式，有不同的作業系統版本，它需要被安裝在客戶機內。以 VSS 為例，VMware tools 承擔 VSS Requester 的角色，在做這種快照之前和之後，它呼叫 VSS 服務，VSS 服務又呼叫已經註冊的 VSS Writer 來執行相應的操作。下圖是個簡單示例：

後面兩種型別的快照被稱為 quiseced snapshot，包括 filesytem-quiseced snapshot 和 applicaiton-quiseced snapshot。其完整的流程大概為：

使用者發出 quiesced snapshot 建立請求給 vCenter，vCenter 給虛機所在的 ESXi 的 hostd 服務發出指令
ESXi 上的 Hostd 將請求傳給客戶機內的 VMware tools
VMware tools 以 VSS Requester 的身份通知 VSS，VSS 再通知已經註冊的檔案系統以及各應用的 VSS writer 執行各自的資料下刷和凍結操作（應用的暫時凍結不能超過60秒）
一旦完成，VMware tools 將就結果告訴 hostd
Hostd 再執行快照操作
操作結束，按照前面的順序再對檔案系統和應用進行解凍

再說一下 VMware tools。在 Windows 系統上，它的安裝包裡面包括了很多的驅動，這些驅動能增強虛機的使用者體驗，比如滑鼠更加平滑，解析度更高，聲音效果更好等等；除了這些驅動以外，還有VSS support，它是 VMware tools 和 Windows VSS 之間互動的橋樑。要建立 quiseced snapshots，這項必須被安裝。

注意安裝 VMware tools 的時候，現在 VWC 裡面選擇 Guest->Install/Upgrade VMware Tools，然後登入虛機，找到前面步驟所掛接的磁碟，再雙擊安裝程式開始安裝過程。

在 vCenter 客戶端中，使用者可以選擇是否建立 quiesced snapshot：

不同的情況下，有如下幾種可能結果：

沒選擇，或者選擇了但是客戶機內沒有安裝 VMware tools：建立 crash-consistent snapshot
選擇了，客戶機安裝了 VMware tools，有 MS VSS 但沒有應用 vss writers，或者安裝了 vmware vmsync driver：建立 filesystem-consistent snapshot
選擇了，客戶機安裝了 VMware tools，有 MS VSS，也有應用 vss writers，或者編寫了應用一致性操作指令碼：建立 application-consistent snapshot

1.6 虛擬磁碟傳輸模式（Tranport modes)

這個傳輸模式是指虛機或者虛機快照的虛擬磁碟中的資料被傳送到備份程式的傳輸方式。VMware 在不同的環境中支援使用不同的傳輸模式，好的傳輸模式能大大增強傳輸傳輸效率。

1.6.1 SAN 模式

這種模式要求 VMware 備份程式所在的物理伺服器能夠通過 FC/iSCSI/SAS SAN 網路訪問到虛擬磁碟。對備份來說，這是效率最高的傳輸模式。這種傳輸模式下，VADP API 從vCenter 或者 ESXi 上獲取 VMFS LUN 的資訊，然後再基於這些資訊從 VMDK 所在的 FC/iSCSI/SAS LUN 中直接讀取資料。下圖是一個示例：

要使用這種模式：

備份程式需要執行在物理伺服器之內，該伺服器必須能夠通過SAN網路訪問到VMFS LUN。
SAN 模式對備份來說是最佳選擇，但是對恢復來說卻不是。

1.6.2 LAN(NBD) 模式

這種模式下，ESX/ESXi 主機從其儲存中讀取資料，再通過 LAN 網路發到備份程式所在的主機。這種模式支援任何型別的儲存。備份程式可以執行在一個虛機之內。需要的時候，可以使用 SSL 加密（NBDSSL）。

1.6.3 HotAdd 模式

當備份儲存執行在虛機之內時，可以利用 ESXi 的 SCSI HotAdd 特性來將虛擬磁碟直接掛在到該虛機上成為其一個本地磁碟。這種模式只能用於 SCSI 模式的虛擬磁碟，而不適用於 IDE 型別的。

如果虛機的快照有兩個虛擬磁碟，當備份程式在其所在的虛機（proxy）上使用 hotadd 模式連線到第一個磁碟後，你可以在 proxy 上看到該磁碟以及它的兩個分割槽：

Disk /dev/sdc: 12.9 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders, total 25165824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x836df02a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sdc2          206848    25163775    12478464    7  HPFS/NTFS/exFAT

然後 proxy 就可以象讀取自己的磁碟一樣從該磁碟讀取檔案了。簡單來說，hotadd 和你手工把一個快照的某個vmdk 掛接到另一個執行著的虛機的原理和要求是一樣的。你也可以通過手工的方式來確定hotadd是否能成功。hotadd 和 nbd(ssl)都走的是乙太網，但是區別在於，nbd 走的是管理網路，而這種網路的頻寬往往有限；而 hotadd 走的是資料/儲存網路，而這種網路往往被單獨出來，而且頻寬往往比較大。

關於各種傳輸模式的概念，使用，要求和最佳實踐等，請閱讀 MVware 的相關文件。

1.6.4 傳輸模式的選擇

備份程式都是呼叫 VDAP 的 Connect/ConnectEx 介面來建立和 vmdk 的連線的。如果不指定傳輸模式的話，在這個過程中，VADP API 會按照順序，依次嘗試 san，hotadd 和 nbd 三種模式，直到有一種成功或者全部失敗。當有成功時，客戶端程式可以呼叫 GetTransportMode() API 返回該連線所使用的傳輸模式。當然，客戶端程式也可以指定特定的傳輸模式。在操作結束後，客戶端程式需要呼叫 Disconnect API 來斷開已經建立的連線。

2. 傳統VMware環境的備份軟體的基本架構

3. 簡要 VMware 虛機映象備份和恢復流程

3.1 備份流程

簡要過程：

備份程式使用 vSphere API 建立和虛機的連線，並備份虛機的配置資訊
使用 vSphere API 建立快照，往往會建立 Quiseced 型別的快照，來保證應用或者檔案系統一致性
使用 VDDK API 建立和快照的第一個磁碟的連線，連線的傳輸模式將會是 san/hotadd/nbdssl/nbd 中的一種。
對該磁碟，呼叫QueryChangedDiskAreas 介面，獲取它與上次備份時磁碟之間發生了變化的資料塊列表
呼叫 VDDK API，讀取發生了變化的資料塊的內容並寫入儲存中的備份
依次處理其它磁碟
所有磁碟處理完畢後，刪除快照，並斷開與虛機的連線

特點：

利用快照功能，儲存虛機在某個時間點上的狀態和快照，很短時間之後虛機就可以照常執行。備份結束，快照會被刪除，這樣虛機的效能也就不受到影響了。
利用 VADP API，只讀取兩次備份之間磁碟上發生了變化的資料塊。當然了，第一次是必須做全備份。
只將變化的資料塊寫入後端儲存，也就是說後端儲存必須負責維護第一次全備份和以後每次delta備份之間的關係。其實相當於將 VMware 的 Snapshot manger 功能挪到了備份軟體的後端儲存。

3.2 恢復流程