本系列文章會介紹雲與備份之間的關系，包括：
（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 恢復流程
簡要過程：
- 備份程序使用 vSphere API 建立和待恢復虛機的連接，並恢復虛機的配置信息
- 使用 vSphere API 創建快照，往往會創建 Quiseced 類型的快照，來保證應用或者文件系統一致性
- 使用 VDDK API 建立和快照的第一個磁盤的連接
- 對該磁盤，調用 QueryChangedDiskAreas 接口，獲取它與上次備份時磁盤之間發生了變化的數據塊列表
- 調用 VDDK API，從所存備份中讀取變化塊的數據，再寫入快照磁盤的相應位置。該磁盤的所有變化塊寫入完成后，關閉與磁盤的連接。
- 依次處理其它磁盤
- 將虛機revert到已恢復快照
- 刪除快照，並斷開與虛機的連接
特點：
- 在操作前，需要確保虛機處於關機狀態
- 同樣也利用快照，然后再利用 API 獲取本次快照和上次備份所對應快照之間發生變化了的數據塊，再使用已保存的備份中的數據將發生了變化的快照磁盤中相應的數據塊覆蓋掉
- 快照的磁盤 vmdk 文件都被恢復后，執行快照恢復
- 結束后，刪除快照
- 雖然備份時上傳的是 delta 數據塊，但是在做恢復時，需要讀取全部的數據塊。
參考資料：