里妹導讀：數據安全性被提到了前所未有的高度，數據保護的話題越來越成為敏感。因為，業務的中斷時間對用戶造成的影響愈來愈大。阿里技術專家凡鈞從數據安全的形勢與發展，面臨的挑戰，問題的定義，傳統的解決方案，當前云廠商的解決方案，去闡述什么是連續數據保護并提出了彈性的可驗證的連續數據保護方案(Elastic Assured Continuous Data Protection)。
相比于傳統的連續數據保護等的解決方案，需要在Guest OS 層面或者在專有的存儲層面，進行寫時數據變化日志的獲取，或多或少對生產機的存儲性能有很大的影響，一旦上云，必將加重客戶的計算成本及存儲成本。即使是混合的架構部署，在網絡的帶寬，實施的復雜性層面也很難與云端實施相比，很難滿足傳統企業客戶的更低的RPO(Recovery Point Objective)及RTO(Recovery Time Objective)的訴求。雖然，連續數據保護的產品定位與快照，復制(Replication)的功能有所重合，但CDP的定位更加寬泛，注重數據的保護，恢復，更高效的業務連續性，不僅僅局限于快照的實現及數據的搬移。
新的Pangu2.0的塊存儲的全新的架構為實現云端連續性數據保護提供了契機，特別是日志結構塊設備(Log Structure Block Device)，其中包括：全新的數據寫入方式，日志存儲方式及快照方式等都極大地方便了連續數據保護的的實現。相信隨著企業上云的加速，在兼顧存儲性能的同時，將會滿足傳統高級企業用戶的低RTO及低RPO的數據保護的緊迫需求。但數據備份及數據備份在考慮可操作的同時，數據可恢復的操作性在很大程度上決定了數據保護的有效性。
在當今，數據安全性被提到了前所未有的高度，數據保護的話題越來越成為敏感。因為，業務的中斷時間對用戶造成的影響愈來愈大。在2017年，病毒，勒索軟件，如WannCry, Peta 及 Locky及頻繁的刪庫誤操作，甚至有些對用戶的備份軟件進行直接攻擊，使得云端用戶對數據安全及數據保護的期望愈來愈高。
數據變得越來越重要: 數據=資產 數據=資源
2017年1月，“Gitlab誤刪庫事件”引起業界對信息安全和重大風險的敏感神經。值得關注的是，在Gitlab恢復的過程中，發現只有db1.staging的數據庫可以用于恢復，而其它的5種備份機制都不可用。而db1.staging 是6小時前的數據，而且傳輸速率有限，導致恢復進程緩慢，Gitlab 最終丟掉了差不多6個小時的數據。
因此，如何降低數據丟失的風險，減小數據保護的窗口，降低用戶的損失，提供高效的恢復機制，是用戶的迫切需要。另外，從一個側面可以看出，低RTO及可驗證的恢復性，對數據保護的重要性；數據的可恢復性相對于存儲成本在此刻是及其重要的救命稻草。
存儲網絡協會(SNIA)對于連續性數據保護的定義為：連續數據保護是一套方法，它可以捕獲或跟蹤數據的變化，并將其獨立保存放在生產數據以外，以確保數據可以恢復到過去的任意時間點。連續數據保護，可以基于塊、文件或應用實現，可以為恢復提供足夠的恢復粒度，實現幾乎無限多的恢復時間點。
全球最具權威的IT研究與顧問咨詢公司(Gartner)的定義為：連續數據保護是一種恢復方法，它連續或者近似連續的捕獲或跟蹤數據文件或者數據塊的變化，同時以日志的形式進行保存。這種能力提供了更加細粒度的實時點，以減少數據的的丟失，并且使得任意的恢復點成為可能。一些CDP解決方案可以被配置去抓取連續的數據改變（真的CDP）或者以一定的時間抓取數據改變（準CDP)。
為了更好的表達CDP的狀態，需要引入兩個概念：RPO和RTO。
傳統的數據保護解決方案專注在對數據的周期性備份上，因此一直伴隨有備份窗口、數據一致性以及對生產系統的影響等問題。而CDP為用戶提供了新的數據保護手段，系統管理者無須關注數據的備份過程（因為CDP系統會不斷監測關鍵數據的變化，從而不斷地自動實現數據的保護），而是僅僅當災難發生后，簡單地選擇需要恢復到的數據備份時間點即可實現數據的快速恢復。
連續數據保護和傳統的災難恢復技術相比，連續數據保護具有如下明顯的特點：
1、首先可以大大提高數據恢復時間點目標(RPO)。備份技術實現的數據保護間隔一般為24小時（每天備份一次），因此用戶會面臨數據丟失多達24小時的風險，采用快照技術，可以將數據的丟失風險降低到幾個小時之內，而CDP能夠實現的數據丟失量可以降低到幾秒（當然，不同的CDP產品和解決方案提供的時間精度也不盡相同）。實際上，在傳統數據保護技術中采用的是對“單時間點（SinglePoint-In-Time）”的數據拷貝進行管理的模式，而連續數據保護保護可以實現對“任意時間點（Any Point-In-Time）”的數據保護。
2、雖然復制(Replication)技術可以通過與生產數據的同步獲得數據的最新狀態，但其無法規避由人為的邏輯錯誤或病毒攻擊所造成的數據丟失。當生產數據由于以上原因導致數據遭到破壞時（例如數據被誤刪除），復制技術會將遭到破壞的數據狀態同步到后備數據存儲系統，使后備數據也受到破壞。CDP系統可以使數據狀態恢復到數據遭到破壞之前的任意一個時間點，也就可以消除前者具有的風險。
3、由于恢復時間和恢復對象的粒度更細，所以連續數據保護保護的數據恢復也更加靈活。目前的部分產品和解決方案允許最終用戶（而不僅僅是系統管理員）直接對數據進行恢復操作，這在很大程度上方便了使用者。
連續數據保護實現的關鍵技術是對數據變化的記錄和保存，以便實現任意時間點的快速恢復。一般來講，有三種實現方式：
- 基準參考數據模式。建立參考數據拷貝，根據生產數據變化記錄數據差異日志，根據日志差異按需恢復數據。基準參考數據模式原理簡單，實現起來比較容易，但由于數據恢復時需要從最原始的參考數據開始，逐步進行數據恢復，因此恢復時間比較長，尤其是恢復時間點越靠近當前的時間，恢復所需要的時間就越長。
- 復制參考數據模式。生產數據和參考數據副本實時同步，在同步的同時記錄回退日志或事件，基于回退日志（Undo Log）差異實現數據按需恢復。復制參考數據模式和基準參考數據模式在實現原理上恰好相反。復制參考數據模式在數據恢復時，恢復的時間點越靠近當前，所需要的恢復時間越短。但在數據的保存過程中，需要同時進行數據和日志記錄的同步，需要較多的系統資源。
- 合成參考數據模式。合成參考數據模式是以上兩種模式的折衷，較好地實現了以上兩種模式的妥協，因此可以得到較好的資源占用和恢復時間效果。但需要復雜的軟件管理和數據處理功能，實現起來比較復雜。 連續數據保護技術或解決方案的實現有多種模式。
不同的傳統廠商建立了不同的連續數據保護保護模型，參考SNIA的存儲共享模型, 可以將實現連續數據保護的產品或解決方案分為基于應用、基于文件和基于數據塊的連續數據保護保護。本文主要從數據塊層面講CDP的實現。基于塊的CDP功能直接運行在物理的存儲設備或邏輯的卷管理器上，甚至也可以運行在數據傳輸層上。當數據塊寫入生產數據的存儲設備時，CDP系統可以捕獲數據的拷貝并將其存放在另外一個存儲設備中。 基于數據塊的數據保護又有基于主機層、基于傳輸層和基于存儲層三類實現方式。
下面以FalconStorCDP、VeeamCDP及EMC RecoverPoint這3個廠商，從不同背景進行分析，具有一定的代表性：飛康是傳統的連續數據保護產品的代表。EMC傳統的存儲廠商，收購以前的RecoverPoint打造自己的數據保護套件, 方案建立在自己的存儲上，提供物理機到虛擬機的保護方案。Veeam 是虛擬機保護的后起之秀，主打虛擬化平臺上，VMWARE 及 HYPERV的數據保護，擴展到云端，目前的方案依賴于VMWare的VAIO 虛擬化數據獲取框架。
EMCRecoverPoint/SE 是針對 EMC CLARiiON 系列陣列的全面解決方案，而 EMC RecoverPoint則是針對整個數據中心的全面解決方案。兩種產品都提供了使用連續數據保護 (CDP)的同步本地復制，以及具有任意時間點恢復功能的同步和異步連續遠程復制 (CRR)。在RecoverPoint 應用裝置上同時運行CDP和CRR實現本地和遠程(CLR) 數據保護，使您能夠用單個解決方案同時在本地和遠程保護相同數據。 飛康CDP解決方案整合了數據備份、系統恢復、災難恢復、本地及異地容災等多項功能。飛康CDP是基于磁盤的備份與容災一體化解決方案，實現文件/數據庫/操作系統的實時備份與瞬間恢復；實現了驗證、演練的本地/異地容災功能整合。
**
AWS僅提供原生的快照功能及幫助客戶上云的手段，數據備份等功能依賴于傳統的數據保護廠商；Azure提供基于虛擬機的基本的備份及恢復方式，沒有提供CDP等高級功能。
根據Gartner的描述的彈性的云備份引擎，其中規定的了成功彈性備份的幾個特征：
連續數據保護CDP本質上作為一種高級的數據保護方案，由云廠商進行，具有傳統備份所不具有的彈性。傳統廠商為了上云，必然需要將數據經過WAN傳輸到云端，必然耗費CPU資源，必然耗費IO資源。為了躲避資源的耗費，可能采取定時開啟的任務方式，連基本的彈性的備份都保證不了，更談不上CDP。可驗證性，強調了CDP方案的可靠性，可操作性。為了保證應用程序的數據的跨卷一致性，需要卷之間建立一致性組（Consistency Group）及應用程序的一致性(Application Consistency)。
數據保護不是亡羊補牢，需要未雨綢繆。隨著企業上云的快速增長，傳統企業對云端數據保護的訴求更加突出；隨著數據重要性的日益提高，用戶對數據丟失的敏感程度前所未有，從而使得云端數據保護與用戶需求之間的矛盾更加凸顯。傳統的基于塊存儲的連續數據保護因為大多依賴于特定的存儲設備，并不具有云端實現所具有的彈性，并不適應云端分布式環境的復雜性。連續數據保護作為傳統或者混合云數據保護的重要補充，定會以新的解決方案的出現而被企業用戶所重視。全新的Pangu2.0的塊存儲的架構為實現云端連續性數據保護提供了契機，隨著企業上云的加速，在兼顧存儲性能的同時，將會滿足傳統高級企業用戶的低RTO及低RPO的數據保護的緊迫需求。后續文章將會著重闡述基于基準參考數據模型的云端連續數據保護，該方案基于Pangu2.0的Block Storage實現連續性數據保護，著重描述連續數據保護的秒級數據恢復機制。
作者：凡鈞
準備工作
介紹
在第3部分中，介紹了你在第2部分中編寫的應用程序，并定義了它應該如何在生產環境中運行，將其轉化為服務，并在此過程中將其擴展5倍實例。
在第4部分中，將此應用程序部署到群集上，并在多臺機器上運行它。 通過將多臺機器連接到稱為swarm的“Dockerized”群集，使多容器，多機器應用成為可能。
理解Swarm clusters
Swarm是一組運行Docker并加入到集群中的機器。加入到集群中之后，你將繼續運行你習慣的Docker命令，但現在它現在在Docker Swarm的集群上執行。集群中的機器可以是物理的也可以是虛擬的。加入集群后，單個容器被稱為節點。
Swarm manager可以使用多種策略來運行容器，例如“emptiest node” - 它可以使用容器填充使用率最低的機器。或者“global”，它確保每臺機器只獲取指定容器的一個實例。swarm managerd的這些策略需要在Compose文件中指定。
Swarm manager是群體中唯一可以執行你的命令的機器，或者授權其他機器作為worker加入到群體中。workers只是在那里提供能力，并沒有權力告訴任何其他機器可以做什么和不可以做什么。
到目前為止，您已經在本地機器上以單主機模式使用Docker。但是Docker也可以切換到群集模式，這就是使用群集的原因。立即啟用群模式使當前的機器成為群管理器。從此，Docker將運行您在您管理的群集上執行的命令，而不僅僅是在當前機器上執行。
設置你的集群
一個swarm是由多個節點組成，節點可以是物理或者虛擬的機器。它的基本概念足夠簡單：運行docker swarm init 命令能夠開啟swarm模式，并且使你的當前機器成為swarm manager,運行docker swarm join命令能夠讓其他機器加入到 swarm 中成為worker機器。選擇的下面的選項卡，看看它是如何各自情況下發揮作用的。我們使用虛擬機快速創建一個雙機集群，并且將其變成swarm.
創建集群
你需需要一個可以創建虛擬機（VM）的虛擬機管理程序，因此請為你的計算機的操作系統安裝Oracle VirtualBox。
現在，創建兩個vm使用docker-machine ，使用VirtualBox 驅動：
docker-machine create --driver virtualbox myvm1
docker-machine create --driver virtualbox myvm2
查看vm列表并獲取它們的ip地址
你現在有2個vms創建，名字為myvm1和myvm2。
$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS myvm1 - virtualbox Running tcp://192.168.99.100:2376 v17.06.2-ce myvm2 - virtualbox Running tcp://192.168.99.101:2376 v17.06.2-ce
初始化swarm 并且添加節點
第一個機器扮演的是manager的角色，它可以執行管理命令并且驗證worker 加入到 swarm中去，第二個是worker。
你可能發送命令到您的vms通過docker-machine ssh。指示myvm1成為一個擁有docker swarm init的swarm manager并輸出如下：
$ docker-machine ssh myvm1 "docker swarm init --advertise-addr <myvm1 ip>"
Swarm initialized: current node <node ID> is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join \
--token <token> \
<myvm ip>:<port>
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
如您所見，對docker swarm init的響應包含一個預配置的docker swarm join命令，您可以在要添加的任何節點上運行該命令。 復制這個命令，并通過docker-machine ssh將它發送到myvm2，讓myvm2作為一個worker加入你的新群體：
$ docker-machine ssh myvm2 "docker swarm join \
--token <token> \
<ip>:2377"
This node joined a swarm as a worker.
恭喜，你已經成功創建了你的第一個swarm。
運行docker node ls在manager機器上去查看swarm 中的節點：
$ docker-machine ssh myvm1 "docker node ls" ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS brtu9urxwfd5j0zrmkubhpkbd myvm2 Ready Active rihwohkh3ph38fhillhhb84sk * myvm1 Ready Active Leader
發布你的應用到swarm cluster中去
最難的部分已經完結。現在你只需要重復再第三部分的過程將應用發布到你的swarm中去。請記住只有像myvm1這樣的群集管理器才能執行Docker命令; worker只是用來工作的。
配置一個docker-machine命令成為swarm manager
到目前為止，你已經在Docker-machine ssh中將Docker命令包裝為與虛擬機交談。 另一種選擇是運行docker-machine env 來獲取并運行一個命令，該命令將當前shell配置為與VM上的Docker守護進程進行通信。 此方法對下一步更好，因為它允許您使用本地docker-compose.yml文件“遠程”部署應用程序，而無需將其復制到任何位置。
鍵入docker-machine env myvm1，然后復制粘貼并運行作為輸出最后一行提供的命令，以將shell配置為與swarm管理器myvm1對話。
配置shell的命令根據你是Mac，Linux還是Windows而有所不同，因此下面的選項卡中顯示了每個命令的示例。
MAC或LINUX上的DOCKER MACHINE SHELL環境
運行docker-machine env myvm1命令去得到命令配置你的shell與myvm1交互。
$ docker-machine env myvm1
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/sam/.docker/machine/machines/myvm1"
export DOCKER_MACHINE_NAME="myvm1"
# Run this command to configure your shell:
# eval $(docker-machine env myvm1)
運行給定的命令來配置你的shell與myvm1進行通信。
eval $(docker-machine env myvm1)
運行docker-machine ls命令去校驗現在這個活動的機器，如旁邊的星號所示。：
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
myvm1 * virtualbox Running tcp://192.168.99.100:2376 v17.06.2-ce
myvm2 - virtualbox Running tcp://192.168.99.101:2376 v17.06.2-ce
在swarm manager中部署容器
現在你已經有了myvm1，你可以使用它的權利作為swarm manager器發布你的app通過使用第3部分中用于myvm1的相同docker stack deploy命令和docker-compose.yml的本地副本來部署您的應用程序。此命令可能需要幾秒鐘才能完成，部署的服務需要一段時間才能提供服務。在swarm管理器上使用docker service ps 命令驗證所有服務是否已被重新部署。
你通過docker-machine shell配置連接到myvm1，并且你仍然可以訪問本地主機上的文件。 確保你和之前操作在同一個目錄下，其中包括你在第3部分中創建的docker-compose.yml文件。
和之前一樣，運行下面的命令在mym1機器上部署應用。
docker stack deploy -c docker-compose.yml getstartedlab
正是這樣，應用在swarm 集群中國部署了！
現在，你可以使用第3部分中使用的相同docker命令。只有這一次，請注意，服務（及相關容器）已在myvm1和myvm2之間分配。
$ docker stack ps getstartedlab
ID NAME IMAGE NODE DESIRED STATE
jq2g3qp8nzwx getstartedlab_web.1 john/get-started:part2 myvm1 Running
88wgshobzoxl getstartedlab_web.2 john/get-started:part2 myvm2 Running
vbb1qbkb0o2z getstartedlab_web.3 john/get-started:part2 myvm2 Running
ghii74p9budx getstartedlab_web.4 john/get-started:part2 myvm1 Running
0prmarhavs87 getstartedlab_web.5 john/get-started:part2 myvm2 Running
訪問你的集群
你可以從myvm1或myvm2的IP地址訪問你的應用程序。
你創建的網絡在它們之間共享并負載平衡。 運行docker-machine ls來獲取虛擬機的IP地址，并在瀏覽器中訪問它們中的任何一個，并刷新（或者通過curl請求）。
有五個可能的容器ID全部隨機輪訓，來實現負載平衡。
兩個IP地址工作的原因是群中的節點參與入口路由網格。 這可以確保部署在群集中某個端口的服務始終將該端口保留給自己，而不管實際運行容器的節點是什么。 以下是三節點群上端口8080上發布的名為my-web的服務的路由網格示意圖：
迭代和擴展應用程序
從這里你可以完成你在第二部分和第三部分中學到的一切。
通過更改docker-compose.yml文件來擴展應用程序。
通過編輯代碼更改應用程序行為，然后重新構建并推送新鏡像。 （要做到這一點，請按照與之前構建應用程序和發布鏡像相同的步驟進行操作。
無論哪種情況，只需簡單地再次運行docker stack deploy來部署這些更改。
你可以使用你在myvm2上使用的相同docker swarm join命令將任何物理或虛擬機器加入此群集。之后只需運行Docker堆棧部署，并且你的應用可以利用新資源。
清除和重啟
Stacks and swarms（堆棧和集群）
你能通過docker stack rm卸載堆棧。例如：
docker stack rm getstartedlab
取消設置docker-machine shell變量設置
你可以使用給定的命令取消當前shell中的docker-machine環境變量。在mac或者linux環境中命令如下：
eval $(docker-machine env -u)
這將shell與docker-machine創建的虛擬機斷開連接，并允許您繼續在同一個shell中工作，現在使用本機docker命令（例如，在Docker for Mac或Docker for Windows上）。 要了解更多信息，請參閱關于取消設置環境變量的機器主題。
重啟Docker machines
如果不關閉你的本地主機，Docker machines將會停止運行。你能通過運行docker-machine ls命令來檢查機器的狀態。
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
myvm1 - virtualbox Stopped Unknown
myvm2 - virtualbox Stopped Unknown
要重新啟動已停止的計算機，請運行以下命令：
docker-machine start <machine-name>
例如：
$ docker-machine start myvm1 Starting "myvm1"... (myvm1) Check network to re-create if needed... (myvm1) Waiting for an IP... Machine "myvm1" was started. Waiting for SSH to be available... Detecting the provisioner... Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command. $ docker-machine start myvm2 Starting "myvm2"... (myvm2) Check network to re-create if needed... (myvm2) Waiting for an IP... Machine "myvm2" was started. Waiting for SSH to be available... Detecting the provisioner... Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command.
總結
在第4部分中，你了解了群體是什么，群體中的節點如何成為manager或workwer，創建群體并在其上部署應用程序。 你看到Docker的核心命令并沒有從第3部分改變，他們只需要將目標鎖定在swarm master上。 你還看到了Docker網絡的力量，即使它們運行在不同的機器上，也可以跨容器保持負載平衡請求。 最后，你學習了如何在集群上迭代和縮放應用程序。
以下是一些您可能想要運行的命令，以便與你的群集和虛擬機進行一點交互：