一、雲存儲

目前雲計算、雲存儲、雲備份等技術可謂是鋪天蓋地，其中不乏有很多是渾水摸魚的，本來沒有多少雲的性質，隻是打着雲的旗号來炒作而已。

目前市場對一款産品是否是雲，沒有明顯的界定。因為雲本來就沒有一個标準。

雲的是怎麼來的

國外在指代一堆設備的時候，一般使用Cluster這個詞，而中文翻譯一般是“簇”或者“集群”。雲這個詞來源已不可考，也許是某個人在講授PPT的時候，順口說了一句"The Servers in the cloud"的吧，這樣Cloud這個詞就誕生了。

對雲的幾種認識

目前人們對雲的認識基本就有4種不同的觀點：雲即設備、雲即集群、雲即IT系統、雲即服務

• 雲即設備：
• 這是最原始的觀點，也就是所謂的雲隻是指代一堆設備，因為沒有設備的支撐，哪來的雲。
• 雲即集群：
• 光有設備還不行，還需要這堆設備有機的聯系起來，相互協同，對外呈現為一個集群，這是在“雲即設備”上的一次發展。
• 雲即IT系統：
• 上面說到的集群，也隻是一堆服務器放在一起，可以協作，若要進一步發展，需要加上軟件作為靈魂，比如某企業的IT系統。
• 雲即服務：
• IT系統一般是用來支撐企業的業務的，但是我們能不能通過他來盈利呢？這就涉及到商業模式上面了。主要有如下幾種模式：
• 直接賣了：
• 如果像賣房子一樣，受衆很小，因為需要購買一整套IT系統的人很少。
• 租出去：
• 這就如同租房子一樣，受衆相對于賣房子大很多。但是盈利慢
• 利用IT系統來運營某種業務，用來賺錢：
• 這種方式受衆更大，像郵箱、網頁、博客，幾乎全民都是客戶，所以盈利面很大。這樣看來，能提供某種形式IT服務的一整套IT系統都是雲。從這個角度，所有的互聯網運營商，比如各大網站，都是雲運營商。

給雲下個定義

那麼雲目前最主流的定義是啥？

上面提到過，設備組成集群，集群搭上軟件稱為IT系統，IT系統用來服務，好了我們可以把之前的觀點結合起來下個定義：

雲是一個可運營的IT系統，

但是這個定義缺少最關鍵的東西，就是資源迅速靈活地部署和回收。所以雲當前最主流的定義為：

雲是一個智能IT系統，它是：

• 可運營的
• 可以迅速靈活部署
• 可迅速回收資源的

也就是

雲是一個可運營的，迅速靈活部署和回收資源的智能IT系統。

那麼雲應該具有如下性質：

• 雲提供商擁有一定規模的硬件基礎（計算、存儲、網絡）
• 作為服務進行交易，而不是實物交易，客戶隻是租用資源

也就是雲其實是一種商業模式，如果認為隻有底層使用了硬件集群和虛拟化技術的系統才是雲這種觀點是非常狹隘的。

誰催生了雲

誰催生了雲？當然是需求

傳統IT的問題

互聯網以及智能終端的普及，讓信息得到了爆發性的增長，那麼對IT基礎架構（計算、存儲、網絡）來說，正在快速被飽和。

我們可以看看傳統IT怎麼運作的？比如運營商部門分析出網頁遊戲業務會有20%的增長，所以需要擴容，比如增加Web服務器、數據庫服務器、存儲系統的數量或容量，然後需要采購設備，遵循一系列的流程，這樣周期非常的長，甚至慢于業務的變化周期。

但是另外一個部們的在線視頻業務因為業績不好，利用率不足60%。

當然最原始的想法是将在線視頻業務的的40%餘量分配給網遊部門，不過會存在大量的技術風險。比如兩種業務部署在同一個操作系統，會增加業務的粘度，不利于運維，然是如果把業務部署在不同的服務器上，更不利于運維。

加上現在數據中心中存在不同的協議、不同廠商的設備，如果靠手動來部署、管理和回收資源，效率低而且容易錯，業務上線的速度也不快。

我們總結一下，傳統的IT系統存在三個問題：

• 業務部署周期長
• 資源不能充分回收利用，存在孤島
• 手動部署無法滿足需求。

這就痛點。

雲其實是商業模式

不過上面的說法隻是雲誕生的一部分理由，實際上最初的雲，實際是一種商業模式，當商業模式與計算機技術結合之後，才産生了雲這個代名詞。這也是雲沒有外在的像技術一樣嚴格的标準的原因。

系統架構變化

要解決之前提到的業務部署周期長，無法實現自動化，資源不能方便的回收和複用等，最容易想到的技術手段自然是虛拟化。

服務器虛拟化，即虛拟機系統，充分利用了資源，再加上Vmotion,DRS(Distrubted Resource Scheduler)等技術，極大的增加了部署靈活性和資源均衡性。

我們來看看部署了虛拟機以後對之前的問題帶來的變化。

• 資源充分利用問題：舊業務餘量會自動回收，新業務所需的應用可以直接以虛拟機的形式部署在物理機，因為操作系統各用各的，粘合影響得以避免。
• 上線業務周期長的問題：部署虛拟機消耗的時間比物理機少了很多，上線速度加快
• 手動部署問題：使用一種資源自動化分配和回收平台來解決自動化部署問題。

那麼所謂虛拟化，其實就是在傳統的數據中心上加上一個彈性層，這樣整個數據中心就變成了軟數據中心了。

如果還能做到部署回收自動化、可度量化、服務化、可運營的數據中心，則就是一個雲數據中心了。

綜上所述，雲系統中重要的角色有：

• 虛拟化
• 集群化
• 自動化：實現資源自動部署、調度、分配、回收的管理者
• 對内可以與其他組件進行通信，管理資源
• 對外可以響應業務部署的需求，并且将這些需求轉化為對内的資源調度
• 這個模塊綜合起來就是“自動化”。
• 可度量化：
• 也就是用戶用了什麼資源，為期多少時間，耗費多少成本，毛利率幾何，報價幾合可以精确度量、定價。

縱觀雲發展的過程中，說不清到底是先有雲這種商業模式還是先有雲這種技術架構的，兩者其實是相互催生、相輔相成。

回顧存儲系統的技術發展過程。

• 最開始的時候，存儲系統隻需要關心數據存儲，隻要提供一塊空間，怎麼管，怎麼用，底層是不關心的，
• 後來，存儲系統開始注重數據管理，開發了諸如快照、重删、容災等功能。
• 再後來，又到了數據運營階段，還關心數據怎麼用的問題，此時需要更貼近用戶的應用，注重業務展現。

公有雲和私有雲

現在我們已經有了一個雲化的數據中心了，那麼可以按照數據中心的是對企業内部開放服務還是給任何人開放服務來分為私有雲和共有雲：

• 私有雲：數據中心對企業内部開發，提供雲服務，比如存儲空間申請、企業應用系統的快速部署等。
• 公有雲：對外營業，通過互聯網提供各種雲服務。
• 私有雲讓企業IT部門角色轉變
• 傳統的IT部門是一個支撐部門，始終處于業務部門的牽引之下，所有的采購、經費申請必須以業務需求為前提。
• 那麼怎麼提升IT部門的地位，隻要也得與業務部門處于平等的地位。雲中的“服務”兩字正好滿足了這種需求，比如IT部門可以通過建立規範的資源申請流程，然後建立電子工單審批系統，隻有通過審批以後才提供對應的服務。還可以統計某個部門在某段時間内使用了多少IT資源，消耗了多少成本。
• 這樣IT部門成為一個獨立的服務角色，其他部門向IT部門申請資源的時候，是以協商的态度而不是強勢的牽制的态度，而且因為資源可度量了，IT部門可以做出合理的預測，申請後續經費等資源變得更有說服性。
• 公有雲受制于互聯網帶寬發展
• 如今互聯網的接入速度還是比較低的，大量用戶的速度還是1Mbps，也就是隻有100KB/s的吞吐量的接入速度。此時，若給他一個iSCSI協議訪問的存儲空間是不現實的，最多提供網盤這樣的上傳下載服務。
• 常用的SaaS服務（網頁、聊天、視頻、網盤等）基本上可以基于低速網絡，但是IaaS就困難了，比如訪問虛拟機的時候，如果不是用xshell這種方式，而是使用虛拟桌面登錄，1Mbps非常勉強。而且，如果要安裝軟件，還得把安裝包傳上去。

綜上所述，雲目前最能被廣泛推進的地方就是新建數據中心，企業興建私有雲，運營商興建混合雲

雲系統架構及組成

下圖為雲具體的架構：

分為如下幾個層次

• 物理架構層：比如供電、散熱等
• 基礎IT架構層：包括網絡、存儲、服務器等
• 需要注意的是這些服務器與存儲設備不是孤島，他們會組成集群，上面搭載虛拟化，并進行自動化的管理。
• 基礎架構/集群管理層
• 有了集群還不夠，需要在上面覆蓋虛拟化層來增加系統的彈性。
• 對于服務器就是VMware這樣的虛拟機平台。對于存儲，就隻能分布式文件系統或者分布式卷管理系統才能滿足這種需求。
• 資源部署層：
• 現在我們已經可以得到一個網絡、服務器、存儲的集群，還需要一個用來管理和驅動集群的角色。
• 比如VMware的VSphere可以進行計算資源的包裹，分布式系統可以進行存儲資源的包裹。
• 利用VSphere提供的Vmotion與DRS可以将虛拟機在集群節點中靈活移動，自動資源動态分配和回收。
• 中間件層
• 應用層與資源層需要一個中間層來适配，這就是中間件層
• 應用引擎層
• 這一層需要提供一個通用的業務開發平台，可以實現統一發布。
• 業務展現與運營層
• 現在數據中心的架構已經具有集群化、虛拟化、自動化的形态了，但是這隻是對自己有用，對用戶來說，他們不用關心底層用不用集群或者虛拟化，隻關心是否能得到快速的服務和響應
• 所以我們還需要一個業務展現界面，這就是雲服務。

那麼出租數據中心其實可以在以下幾個層次中進行：

• 基礎設施即服務（IaaS）
• 所謂基礎設施指的是雲系統中的硬件設施如服務器、網絡、存儲。所以IaaS隻是提供硬件平台，具體的計算任務由用戶自行部署。
• 如何賣存儲空間：
• 可以有多種方式，比如賣裸空間、文件存儲空間等。
• 裸空間就是最終用戶看到的是一塊硬盤，所有協議當然首選ISCSI，以便跨越IP網絡，這樣用戶可以通過ISCSI Initiator連接雲提供商的ISCSI Target，然後就可以獲得多個LUN。
• 對于雲中存儲系統，精簡重删這些特性應該是必須的，可以降低不必要的空間占用，而動态分級可以進一步節省存儲成本。
• 如何賣服務器、虛拟機
• 虛拟機平台需要考慮幾種功能：
• 一是動态遷移，即虛拟機可以在不影響應用系統的情況下在物理機之間進行遷移。
• 二是資源動态分配調度，
• 三是管理方便。
• Amazon在IaaS提供兩個産品：彈性計算雲（Elastic Compute Cloud , EC2）和簡單存儲服務(Simple Storage Service ,S3)，分别對應了主機計算集群和存儲集群
• 平台即服務
• 相對于IaaS，PaaS屏蔽而不出租基礎架構，轉而出租更高一層的軟件平台。用戶可以通過這個平台制作應用。因為這個平台是一種運行與硬件集群中的軟件，用戶實際上相當于租用了計算業務。
• 軟件即服務
• SaaS是雲服務中的最外層，直接出售業務級别的内容。比如Web網頁等。

實例說雲

下面使用3Tera Applogic的例子來說一下IaaS層

3Tera的IaaS平台名為Applogic，是一不可以實現IaaS功能的軟件虛拟化平台。我們可以看一下它的底層架構：

主要分為4大層次：

• 硬件層：
• 本層包含服務器、存儲、網絡設施等。
• Applogic不要求底層存儲必須是基于SAN的，可以是本地IDE。若幹服務器通過千兆以太網連接起來，形成集群。
• 然後在這個有限且分配不靈活的資源池上，實現一種管理方便、使用方便、資源靈活分配的虛拟化層。
• 分布式核心虛拟化層(Applogic OS)：
• 計算虛拟化：Distributed Virtual Machine Manager（DVM）
• 本層的核心是虛拟機技術，通過Hypervisor引擎來虛拟化成多個主機，比如說VMware的ESX Server就是實現這個目的的。隻不過Applogic使用的是Xen虛拟機平台。
• 存儲虛拟化：Global Volume Store(GVS)子層：
• Applogic使用的是自研分布式文件系統，在這個文件系統之上虛拟出Volume，而且Volume可以Mirror、Clone、Snapshot等。
• 每個Volume在多個物理主機上有鏡像以解決HA問題，并且可以提升讀性能。
• 而這些Volume對于最終的虛拟機就是裸磁盤，在這個虛拟化層上，每個節點将自己的本地存儲空間貢獻出來，所有節點的存儲被整合起來進行虛拟化。
• 網絡資源虛拟化：Logical Connection Manager(LCM):将物理網絡搞成虛拟網絡
• 一次性基礎設施虛拟層
• 所謂一次性基礎設施，其實就是虛拟機可以按需創建。每個應用程序可以分配一個獨立基礎設施，包括防火牆、負載均衡、Web服務器、數據庫服務器等。當要删除應用程序的時候，可以直接把虛拟機删除了。
• 這些角色可以虛拟成一個個對象，在圖形界面使用鼠标拖拽的方式建立對象

• 上圖創建了一個防火牆、負載均衡、2台Web防火牆、數據庫服務器，整個網格中的Volume按照Application進行隔離，不同的Application隻能看到自己的Volume。
• 防火牆、負載均衡、WebServer之間互聯的IP用戶不需要關心，系統自動分配，唯一需要配置的是整體Application的IP地址信息。
• 網絡控制層和應用程序管理層
• 以Application為單位向用戶交付。

Applogic帶來的革命是把複雜的底層硬件變得簡單，通過拖拽對象來狀态自己的基礎架構，最終以适合某中Application運行的整體服務器&存儲&網絡來交付。

雲的缺點

在看雲的缺點之前先看一下雲的優點：

• 避免資源的浪費：
• 節能
• 角色轉變

存在的問題：

• 穩定性和安全性：如何解決兩個存儲資源互通的問題，如何才能保證完全隔離。
• 平台遷移
• 怎麼樣才能在不影響業務的前提下遷移到雲平台上。
• 不兼容的問題：不同雲服務商提供的架構不同，接口也不同。

雲之後的發展

雲的本質

雲本質是一種服務，而不是一種物質，正因為此，它必須基于物質才能顯示功效，《易經》有雲：“形而上者謂之道，形而下者謂之器”。所以下器者，謂之服務器 存儲 部署管理軟件；上道者，謂之“雲”。所以雲是一種道，是一種方式和方法，而不是某種設備，某個軟件，當然雲需要由硬件 軟件來承載而已。

所以，雲和速度性能沒有直接關系。雲本身不一定就是一個高速高冗餘的東西，而是說底層硬件一般使用并行計算集群和存儲集群，在這個基礎上，雲才能表現出更大的效能。

而且雲也不是為了提速而生，它的主要目的是廉價高效的利用資源并降低硬件的應用成本和管理成本。

其實雲早就存在了，隻有近兩年才被炒作起來，互聯網服務器就是雲服務，所以有人提出IT服務即雲，Everything as a service。

其實在40年前，我們還是用集中分時計算，随後到了世紀相交的紀念，用戶各自購買基礎架構進行計算和存儲，然後又逐漸回到了集中計算的時代，實際上這既不是進化，又不是退化，是“分久必合，合久必分。萬物皆在輪回中不斷發展，到一定程度就回到當初的形态，但是承載它的物質是連續不斷的提升的。所輪回的隻是其上的那層能量，謂之道。

Micro、Mini、Normal、Huge、Grid彈性數據中心

彈性核或者軟數據中心：将若幹刀片與高密度的磁盤櫃以及微型交換機打包到一個或者幾個機櫃裡面，再覆蓋以彈性層，比如虛拟機管理系統以及分布式存儲系統，将這樣一個微型彈性軟核心做為一個可提供IaaS服務的整體交付給用戶。

或者再在這個軟核上覆蓋一層業務展現于管理層，直接交付到SaaS層。一櫃或者數櫃交付的彈性基礎設施，可以稱為Micro Cloud

二、數據容災

數據備份系統隻能保證實際上被安全複制了一份，如果生産系統故障，必須将備份數據盡快的恢複到生産系統中繼續生産，就叫容災。

容災可以分為四個級别：

• 數據級容災：隻是将生産站點的數據同步到遠端。
• 與應用結合的數據級容災：保證對應應用數據一緻性。
• 應用級容災：需要保證災難發生以後，需要保證原生成系統中的應用系統在災備站點可用。
• 業務級容災：除了保證數據、應用系統在災備站點可用，還要保證整個企業的業務系統仍對外可用，是最終層次的容災。

概述

如果要充分保證數據的安全，隻是在本地做備份是不夠的，所以需要在遠程建另一個系統，并包含當前生産系統的全部數據，這個系統須

• 要保證主生産系統的數據實時的傳輸到遠程備份系統上。
• 主故障後，必須将應用程序切換到遠程備份系統上。

那麼備份和容災有什麼區别呢？生産系統就好比手機，備份就是把手機上的數據備份到電腦上，但是如果這個手機壞了呢？要恢複數據需要大量的時間。

那麼容災就是我們有兩部手機，而且他們的數據是使用雲實時同步的，所以可以無縫切換。

如果我們預算充足，可以使用一直兩台手機，那還需要備份嗎？當然需要，比如某個時刻，我們把手機裡面的某個聯系人給誤删了，因為容災的手機是實時同步的，很難說能通過另一部手機找回來。但是如果之前有備份過數據，完全可以通過之前的備份進行恢複。

下面繼續談容災。對于一個企業IT生産系統，主要有4個組件：

• 生産資料：原始數據
• 生産工具：服務器等基礎架構
• 生産者：業務應用程序
• 産品：對外提供的服務信息

下面将對這四大組件的容災進行講解

生産資料容災

生産資源容災指的就是對原始數據進行容災。這最重要的，因為沒有生産資料一切等于從頭再來。

要設計這樣一套生産資料容災，需要注意的是

• 要把變化的實時同步到備用系統，方法是
• 将某時刻的數據傳送到備用系統
• 将此時候後變化數據同步到備用系統
• 這樣就做了一次同步了，之後隻需要在數據變化以後才把變化的數據傳送到備用系統。
• 數據必須至少保留額外一份。在容災的同時還需要數據備份（避免誤删等邏輯錯誤）

如下為相應的拓撲：

主備站點都有相同的生産工具，使用網絡相連。可以通過兩種方式來進行同步：

• 通過前端網絡進行同步
• 通過後端SAN網絡進行同步。

通過前端網絡同步

• 通過路由器連接到專線或者Internet
• 變化的數據通過路由器傳送到備站點的路由器上。
• 通過交換機傳到備服務器上，寫入磁盤陣列

那麼到底選擇專線還是Internet呢？專線可以保證數據同步的實時性，但是不适合大數量的傳輸。如果實時性要求不高，而且數據量大的時候，可以将主備站點接入100Mbps的Internet。

可以看出這種方式經過了前端網絡，所以必須在每台需要備份的服務器上安裝軟件進行同步，這種軟件可以監視目錄中的數據變化，然後與遠端的軟件進行通信，寫入相同的文件目錄中。

這種方式的同步一般都是文件級的同步，對底層卷的數據塊變化不做同步。

案例：DB2數據的HADR組件容災

DB2數據庫利用主備上的數據庫軟件模塊（HADR）來實現兩端的數據同步。而且同步的是不卷上的原始數據，而是對數據操作的描述，也就是日志。這樣的好處是，不需要傳輸數據，備份機收到日志以後，在備機的磁盤上重做操作即可。

HADR:High Availability Disaster Recovery，是數據庫級别的高可用性數據複制機制。需要兩台數據庫服務器：primary , standby

• 當主數據庫發生事務性操作，将日志通過TCP/IP傳送到備數據庫，然後備機對日志文件進行重放Replay，從而保持數據的一緻性。
• 當主數據庫故障，備機可以接管主數據庫，而客戶端應用程序的數據庫連接可以通過自動客戶端重新路由（Automatic Client Reroute）轉移到新的主服務器。
• 當原來的主數據庫服務器修複了，作為新的備用數據庫加入HADR。

需要注意的是處于備用角色的數據庫不能被訪問。

通過後端網絡實現同步

通過後端網絡進行同步，數據不會流經前端網絡，而全部通過後端網絡傳輸到備份的存儲上。所以需要将主站點和備站點的後端網絡設施連接起來。要麼直接拉光纖，要麼用專線。

如果用專線的話，需要增加額外的協議轉換設備，現在電信部門的光纖專線一般為SDH傳輸方式，接入到用戶端的時候，一般将信号調制成E1、OC3等編碼方式。

上圖中，FC協議，經過FCIP網關，變成基于以太網的IP協議，（FC over IP over ETH）。經過E1/以太網轉換器，承載到了E1協議上，然後多路E1信号彙聚到光端機，通過一條或者多條光纖，傳輸給電信部門的SDH交換設施進行傳輸。

這樣我們就将主站點和備站點的後端網絡打通了，此時主服務器就可以訪問到備份的磁盤陣列，也就是說主站點的服務器可以同時操作本地磁盤和備站點的磁盤陣列了。

我們來看一下這種方式的路徑：

本地磁盤 SAN交換——本地服務器内存——SAN網絡交換——電信部門網絡——遠端SAN網絡交換——遠端磁盤陣列

數據到了遠端SAN不需要再經過服務器，因為有了對方存儲設備的直接訪問權。但是整個過程中，仍然至少需要一台服務器，服務器上需要安裝一個軟件，可以将數據從本地卷A提取出來，然後直接通過SAN網絡寫到位于備份站點的卷B上。

但是試想一下，如果數據直接在内存中生成的，那麼同時在A和B上各寫一份，速度豈不是更快，這種方式又叫“卷鏡像”，因為可以時時刻刻保持兩個卷完全相同，它能保證數據同步的實時性，但是不适合大規模遠距離的數據同步。

同時還需要注意的是，卷鏡像的的同步軟件工作在卷這一層，可以感知數據塊的變化，而不是文件的變化。缺點在于對網絡速度要求更高，所以成本也更高。

通過數據存儲設備實現同步

之前講的通過前端網絡和通過後端網絡的方式，都使用了一個泵來提供動力。而如果将數據同步軟件安裝在存儲設備上，豈不是更省事。而且這樣徹底解放了服務器，所有工作都由磁盤陣列完成。

這種方式的同步，不會識别卷上的文件系統，所以同步的是塊。而且要求主和備的存儲設備型号一緻。因為不同廠家的産品無法實現直接同步。

這種方法的缺點是不能保證數據對應用程序的可用性。

因為存儲設備與應用程序之間還有操作系統這一層，操作系統也有自己的緩存機制，所有有可能造成數據的不一緻性。

總結：

• 使用前端網絡進行同步，路徑最長，但是成本也最低。
• 使用後端網絡進行同步，實時性強，但是對後端鍊路要求也高。不适合于數據量多的時候。
• 使用存儲設備直接進行同步，路徑最短，不占用服務器。但是仍然不适合于遠距離低速鍊路環境。而且還不能數據對應用程序的可用性。

容災中數據的同步複制和異步複制

同步複制

下圖是基于存儲設備的自主同步環境。

• 主向磁盤發出IO請求，向某LBA寫入數據，待寫數據入緩存，此時控制器不會給主的HBA驅動程序發送成功
• 主磁盤陣列将變化的數據從緩存中寫入LUN A，此時主的數據同步引擎感知，将變化的數據塊從緩存中通過SAN交換機發送到備的緩存中。
• 備磁盤陣列運行的同步引擎接收到數據後，在FC協議隐式的發一個ACK或者通過上層顯試的發給主站點
• 主收到應答，向服務器發一個FC協議的隐式ACK。服務器上的FC HBA驅動程序探測成功。
• 若備站點遲遲未收到數據，則不會返回成功，應用程序會等待。如果此時應用程序使用的是同步IO，則相關進程會挂起，稱為IO等待。
• 所以同步複制的特點是主站點必須等待備份站點的成功信号，保持嚴格的同步，一榮俱榮，一損俱損。

異步複制

相對于同步複制，兩邊的步調不需要一緻，要保證重要的事情先做完，所以會存在一定的數據不一緻。

• 主向磁盤發出IO請求，待寫數據進入控制器緩存，如果此時
• 主控制器設置為Write Back模式：則立刻返回應答。
• 主控制器設置為Write Through模式，則先寫入LUN A以後，再返回ACK。
• 主站點将數據通過SAN網絡發送到備站點的緩存。
• 備站點磁盤成功接收，則返回成功。

生産者容災——應用程序容災

之前講的都是生産資料的容災，也就是整個系統最重要的數據的容災。而對于生産者，無疑就是服務器上的應用程序，如果主發生故障，需要在備站點重新運行這些應用程序。最直觀的想法是，在備站點預備應用程序的安裝文件，一定主出現故障，在備上配置這些應用程序，但是實際上應用程序安裝和配置需要大量的時間。所以可以将備份站點預裝應用程序，但是不工作，這樣就可保證同一時刻整個IT系統隻有一個站點的生産者處理一份數據

既要求處理同一份數據，又要求發生事故的時候，備份站點的生産者立即啟動，要做到這點，需要讓備份站點的應用程序感知到主站點的應用程序狀态，一旦發現故障，立即啟動開始生産。

在之前的章節中，我們說到了高可用群集，在容災系統領域，群集的範圍擴大到了異地，主備可能相隔很遠，交換運行狀态的數據量很小，最好使用專線，這樣可以很好的保證QoS。

傳統的HA軟件是使用共享存儲的方式來作用的，即在HA系統中，共享一份物理存儲，不管誰來操作這份數據，最終隻有一份，而且是一緻，有上下文邏輯關系的。

所以HA軟件是基于資源切換的，把組件看作是資源，比如應用、IP地址、存儲卷等。

當故障時，

• 備份機HA軟件會檢測到對方的故障，
• 然後強行将資源遷移到本地，比如在備份機上修改網卡的IP地址，并發出ARP廣播來刷新所有廣播域的客戶端以及網關的ARP記錄
• 挂載共享存儲設備上的卷，
• 最後啟動備份應用系統。

這樣應用系統可以訪問共享卷，客戶端也可以使用原來的IP地址來訪問服務器，這樣生産就可以繼續下去。

但是在異地容災系統中，主備站點各有一份數據，所以必須保證數據的同步。這也是為什麼兩個站點同時隻有一個在工作，這樣的話才能以一邊數據為準，另一邊與之同步。

本地容災

本地HA系統中，多個節點如果共同擁有同一個卷，但是同一時刻隻有一個節點能挂載它，這種模式叫共享存儲模式

與之對應的是Share-Nothing模式，每個節點都有自己獨占的存儲卷，怎麼進行數據共享呢？可以通過同步複制技術同步到所有節點上。若某節點發生故障，這個節點對應的備份節點啟動應用程序。因為之前的數據已經同步過了，所以數據一定是一緻的。

在Share-Nothing模式下，不存在任何的接管問題，所以客戶端需要感知服務端群集這種切換動作，通過客戶端進行配置的切換即可。

可以對共享存儲和Share-Nothing兩種存儲模式進行對比。

共享存儲Share-Nothing數據本身是否容災×√軟硬件成本高低前端網絡資源消耗低高管理難度高低維護數據是否需要停機√×實現的複雜度高低是否需要第三方軟件√×故障因素數量3個2個

• 數據本身是否容災
• 共享存儲：數據損壞，必須使用鏡像進行還原。而且要停機。
• Share-Nothing：每個節點都有自己的數據拷貝，若損壞，可切換到另外的節點，不影響應用，不停機。修複後的節點可以重新加入容災系統。
• 軟硬成本
• 共享：需要外接磁盤陣列，為了保證數據訪問速度，必須自身實現RAID，主機也需要安裝适配器。成本高。需要HA軟件
• Share-Nothing:各個節點各自保存數據，不需要外接存儲系統，不需要額外的HA軟件
• 前端網絡耗費
• 共享存儲：前端隻需要交互控制信息，資源耗費較小。
• Share-Nothing:數據同步靠前端，對資源消耗很大。
• 管理難度：
• 共享：需要管理節點間的交互配置，還需要管理外部存儲，增加了管理難度
• Share-Nothing:隻需要管理節點配置。
• 是否停機
• 共享：需要将數據從單機轉移到共享存儲供其他節點使用，需要停機來保證一緻性。
• Share-Nothing：數據同步是動态的，不需要停機。
• 實現複雜度
• 共享存儲：有三種基本元素：節點、節點間的交互、共享數據。如果使用共享存儲模式做容災，需要将數據移動到共享存儲上，增加額外的工作量和不可控因素
• Share-Nothing：隻有兩種元素 節點&節點交互
• 第三方
• 共享存儲：備份節點需要通過HA軟件來監控主節點的狀态，發生故障的時候自動接管，如MSCS
• share-Nothing：不需要第三方軟件參與
• 故障因素
• 共享存儲：OS、應用程序、HA軟件
• Share-nothing：OS、應用程序

異地容災

如果主站點和備站點不在同一個機房中，這樣備份應用程序需要跨越很遠的距離來與主程序交互狀态。隻是說這種交互包很小，不需要擔心延時的問題。

IP切換

在異地容災系統，主服務器和備服務器不大可能在同一個廣播域，所以需要通過網關來轉發IP包，正因為此不能用資源切換的方式來切換IP地址。

如果想故障後，客戶端繼續使用原來的IP地址連接備份服務器，那麼可以在路由上做文章。動态修改路由器上的路由表，将IP包路由到備份站點而不是主站點。如果利用域名來訪問服務器，那麼可以直接在DNS設備上修改IP指向記錄來實現。

卷切換

異地容災系統在主站點和備站點各有卷，兩個卷通過前端或者後端網絡進行同步。

如果備的HA軟件檢測到主站點通信失敗，通過某種方式，斷開同步關系（若不斷開，卷會被鎖定而不可訪問）。然後就是重新挂載備站點的卷

此時同步引擎可以是運行在存儲設備上，也可以由HA來執行。

• 如果同步引擎是運行在存儲設備上的，必須由管理員手動利用存儲設備的配置工具來斷開同步關系。斷開了以後，本地的卷才可以被訪問，然後HA軟件可以在備份機上調用操作系統相關功能來挂載這個卷。
• 如果同步引擎本來就是HA來執行的，那麼HA軟件可以自動斷開同步關系，在備份機上挂載對應的卷。

異地容災的應用切換

應用，也就是生産者的切換，是所有HA容災系統在故障發生後所執行的最後一步。與共享存儲式的HA容災一樣，異地容災的應用切換，是有備機的HA軟件來執行腳本，或者調用相應的接口來啟動備份機的應用的。

三、數據保護和備份技術

從底層來分，數據保護可以分為文件級保護和塊級保護。

文件級備份

文件級備份：将磁盤上所有文件通過調用文件系統接口備份到另一個介質上。也就是把數據以文件形式讀出，然後存儲在另一個介質上面。

此時備份軟件隻能感知到文件這一層。

我們知道一般來說，文件在原來的介質上，可以是不連續存放的，通過文件系統來管理和訪問。當備份到新的介質上以後，文件完全可以連續存放。正因為如此，沒有必要備份元數據，因為利用新介質進行恢複的時候，反正會重構文件系統。

塊級備份

塊級備份就是不管塊上是否有數據，不考慮文件系統的邏輯，備份塊設備上的每個塊。

這樣好處是不通過調用文件系統接口，速度更快，缺點的是備份的時候會把所有的塊複制一遍，但是實際上很多扇區的數據是不對應真實文件的，也就是會備份很多僵屍扇區。而且備份之後，原來不連續的文件一樣是不連續的文件，有很多的碎片。

高級數據保護

遠程文件複制

遠程文件複制：通過網絡傳輸到異地容災點。典型的代表是rsync異步遠程文件同步軟件。可以監視文件系統的動作，将文件的變化，同步到異地站點。增量複制。

遠程卷鏡像

這是基于塊的遠程備份。與遠程文件複制不同的地方在于，是把塊數據備份到異地站點。又可以分為同步和異步複制。

• 同步複制：必須等數據複制到異地站點以後，才通報上層IO成功消息
• 異步複制：寫入成功即可回複成功，然後通過網絡傳輸到異地。不能保證一緻性，但是上層響應快。

基于塊的備份措施，一般都是在底層設備上進行，不耗費主機資源。

快照

遠程鏡像确實是對生産數據一種非常好的保護，但是需要鏡像卷一直在線，主卷有寫IO，那麼鏡像卷也需要有寫IO。

如果想對鏡像卷進行備份，需要将停止主卷的讀寫，然後将兩個卷的鏡像關系分離。所以當恢複主卷的IO的時候，鏡像卷不會再被讀寫。然後才可以備份鏡像卷的數據。

這樣會存在一個問題，主卷上還繼續有IO，将會導緻數據與備份的鏡像不一緻。所以主卷上所有的寫IO動作，會以位圖bitmap方式記錄下來，bitmap上的每個位表示卷上的一個塊，0表示未寫入，1表示已寫入，所以當拆分鏡像以後，被寫入了數據，程序将bitmap文件對應位從0變為1。備份完成以後，再做數據同步即可。

可以看出上述過程比較的繁瑣，而且需要占用一塊和主卷一樣大小的鏡像卷。

快照技術就是為了解決這種問題，其基本思想是抓取某一時間點磁盤卷上的所有數據。

快照分為：基于文件系統的快照和基于物理卷的快照

下面介紹一下快照的底層原理。

基于文件系統的快照

文件系統管理的精髓：鍊表、B樹、位圖，也就是元數據

文件系統

• 将扇區組合成更大的邏輯塊來降低管理規模。NTFS最大塊可以到4KB，也就是8個扇區一組一個簇（Block），這樣可以減少管理成本。
• 文件系統會創建所管理存儲空間上所有簇的位圖文件。每個位代表卷上的簇（或者物理扇區）是否被使用，如果被使用，則置1。
• 文件系統保存一份文件和其對應簇号的映射鍊。因為映射鍊本身和簇位圖也是文件，也有自己的映射鍊，所以針對重要的元數據，有一個固定的入口：root inode

寫入新數據

• 查找簇位圖，找位值為0的簇号，
• 計算所需空間， 分配簇号給文件
• 将數據寫入簇，再去文件——簇号映射圖更新
• 将對應的簇映射關系記錄下來，到簇位圖将對應位置改為1.

删除數據

• 直接在簇号映射鍊中抹掉，
• 簇位圖對應簇改為0

可以看出删除數據實際上不會抹掉實際的數據。

** 所以，最重要的不是數據，而是文件——簇号映射鍊和位圖等元數據。**

也就是說我們要做備份，隻需要把某時刻的文件系統中的映射圖表保存下來。但是必須保證卷上的數據不被IO寫入了，同時又要不應用還不能中斷。既然原來的空間不能再寫了，我們可以寫到其他的空閑區域。

• 思路一：Copy on First Write (CoFW)，
• 在覆蓋數據塊之前，需要将被覆蓋的數據塊内容複制出來，放到空閑的空間。
• 系統中将有兩套元數據鍊，原來的元數據指向當前，快照的元數據鍊指向曆史。原來的存儲空間永遠是最新的數據，曆史數據會逐漸搬出到空閑空間裡面。

• 思路二：Redirect on First Write,(RoFW)。
• 先複制元數據，然後将針對源文件的更改都重定向到空餘空間，同時更新元數據。
• 與CoFW不同的是，原來的數據塊不會被覆蓋。同樣的，系統也有兩套元數據，一套是快照保存下來的，永遠不更新，一套是源文件系統的，不斷的更新。
• 其實隻有首次覆蓋的時候，才重定向，因為重定向以後的數據塊，哪怕被覆蓋了，也不影響之前快照保存的數據了。

下圖為生成兩個快照之後系統處理流程。

到這一步，看上去挺完美，實際上存在一個問題：如果元數據特别大怎麼辦？對于海量龐大的文件系統，元數據量可能到GB級别。如果複制的話，時間上仍然太多。

我們可以回頭想想，實際上元數據可以看做指針，指向具體存儲的位置。我們複制到元數據，相當于複制了一堆指針。現在元數據太多了，我們能不能把這個元數據鍊的指針給複制了？當然可以，元數據有個根入口塊，或者稱為Super Block，這個塊是固定不變的，裡面存放有指向下一級元數據鍊塊的指針。

那麼操作系統每次載入元數據的時候，都需要從這個地址讀入Super Block，從而一層一層的遍曆。

下圖為隻複制Super Block以後的RoFW模式：

基于物理卷的快照

基于物理卷的快照比文件系統快照要簡單得多。因為LUN一般在底層磁盤上是恒定的，不像文件系統一樣可以随機細粒度的分布。所以可以認為LUN的元數據就是在底層磁盤的起始和結束地址

這樣在快照的時候，需要複制的元數據就更少了，但是完成了以後，需要按照一定粒度來做CoFW或者RoFW，還需要記錄更多數據映射指針，就比較難受了。

對于實現了塊級虛拟化的系統如NetApp,XIV,3PAR等，它們的LUN在底層位置是不固定的，LUN就相當于一個文件，存在元數據鍊來進行映射管理的維護，所以這些系統實現快照的原理與文件系統快照類似。

基于物理卷的快照，相當于給物理卷增加了“卷扇區映射管理系統”。在底層卷實現快照，可以減輕文件系統的負擔。

卷扇區方都是用LBA來編号的，實現快照的時候，程序首先保留一張初始LBA表，每當有新的寫入請求的時候，重定向到另一個地方，并在初始的LBA表中做好記錄。比如

原始LBA：卷A的10000号，映射到LBA：卷B的100号。

值得說明的是，文件系統無法感知重定向，文件系統在它的映射圖裡面還是記錄了原始的LBA地址。

此時如果來了新的寫IO，有兩種方式一種是Write Redirect 一種是Copy on Write

所謂Write Redirect就是将文件系統的讀寫請求，重定向到卷B，這樣每次IO其實都會查找快照映射表，降低了性能。所以引入了Copy on Write

所謂Copy on write，就是當寫請求來的時候，先把原來的扇區的數據複制一份到空閑卷，然後将新數據寫入原卷。不過這種複制操作隻發生在原卷某個或者快照之後從未更新過的塊上面，若是某個塊在快照之後更新過了，說明之前的數據已經轉移走了，可以放心的覆蓋。

所以Copy on Write實際上是讓舊數據先占着位置，等新數據來了以後先把原來的數據複制走，再更新，而且一旦更新了一次，可以直接覆蓋。

帶來的好處是 ，原卷上的數據随時是最新的狀态，每個IO可以直接訪問原卷的地址，而不需要遍曆映射表。

RoFW 方式與CoFW方式比較

不管是RoFW還是CoFW,隻要上層向快照後沒有更新過的數據塊進行寫，都需要占用一個新的塊。所以如果将所有扇區塊都更新了，新卷的容量和原來的容量應該一樣大，但是通常不會覆蓋百分之百，所以隻要預設原容量的30%即可。

IO資源消耗：

• CoFW方式下，如果要更新一個從未更新的塊，需要複制出來，寫到新卷，然後覆蓋原來的塊，需要：一次讀，2寫。
• RoFW方式下，隻需要一次寫即可，也就是直接重定向到新卷上，然後更新映射圖中的指針（在内存中進行）。

所以RoFW相對CoFW方式在IO資源消耗與IO延遲上有優勢。

由于隻有首次覆蓋才會Copy或者Redirect，那麼如何區分是否是首次覆蓋呢？可以使用記錄表（文件級快照）或者位圖（卷快照）來記錄每個塊是否被覆蓋過。

對于讀IO，

• CoFW：因為總是更新的源卷，所以源卷總是代表最新的狀态，所以任何讀IO都會發到源來執行
• RoFW：需要首先查詢位圖來确定目标地址是否被處理過，如果是，則轉向重定向後的地址。
• RoFW會影響讀性能，因為重定向出去以後，數據塊排布都是亂的，如果把快照删除後，不好清理戰場，嚴重影響後續的讀寫性能。

綜合來說，RoFW比較吃計算資源，而CoFW比較耗費IO資源。

我們知道其實一般來說讀比寫多，當覆蓋第二次以後

• CoFW不會發生IO懲罰，讀IO一直沒有懲罰
• 對于RoFW，就算完全被Redirect過了，對于讀或者寫IO，均需要遍曆位圖，永遠無法擺脫對計算資源的消耗。

尤其在LUN卷級快照下，原本卷在底層磁盤分布式是定死的，尋址非常迅速。但是RoFW引入了，LUN的塊随機定向到其他的空間的，所以需要記錄新的指針鍊，而且被寫出的塊不是連續排列的。對性能影響非常明顯的。

絕大多數的廠商使用的還是CoFW，但是一些本來就使用LUN随機分塊分布模式的存儲系統比如XIV,NetApp等，都使用RoFW，因為原本其LUN的元數據鍊就很複雜，而且原來就是随機分布的，RoFW的後遺症對它們反而是正常的。

快照的意義

快照所保存下來的卷數據，相當于一次意外掉電之後卷上的數據。怎麼理解?

上層應用和文件系統都有緩存，文件系統緩存的是文件系統的元數據和文件的實體數據。每隔一段時間（Linux一般是30s）批量Flush到磁盤上。而且不是隻做一次IO，有可能會對磁盤做多次IO。如果快照生成的時間恰恰在這連續的IO之間，那麼此時卷上的數據實際上有可能不一緻。

文件系統的機制是先寫入數據到磁盤，元數據保存在緩存裡面，最後再寫元數據。因為如果先寫元數據，突然斷電了，那麼元數據對應的僵屍扇區的數據會被認為是文件的，顯然後果不堪設想。

總之，快照極可能生成不一緻的數據。

那麼為什麼還要用快照呢？

• 因為快照可以任意生成，而且占用的空間又不大，更重要的是可以在線恢複，不用停機隻需要在内存中做IO重定向，那麼上層訪問就變成以前時間點的數據了。

但是快照會存在不一緻的問題，如何解決？

既然快照無異于一次磁盤掉電，那麼利用快照恢複數據之後，文件系統可以進行一緻性檢查，數據庫也會利用日志來使數據文件處于一緻。

另外，現在主流的快照解決方案是在主機上安裝一個代理，執行快照前，先通知文件系統将緩存中的數據全部Flush到磁盤，然後立即生成快照。

• 快照還可以預防數據邏輯損壞，也就是比如T1時刻，做了快照，T2時刻，因為管理員操作不當，誤删了一個文件，T3的時候，進行了全備份操作。此時，這個文件看似永久丢失了，其實，此時還可以通過快照恢複這個文件。
• 快照還可以降低一緻性備份的窗口。如果沒有快照，要對某個卷進行一緻性備份，需要暫停寫IO，所以備份窗口比較長，需要等待備份停止以後才能繼續寫IO。使用快照的話，隻需要複制元數據，然後在後台進行備份，降低了影響。
• 備份完畢以後，如何能檢測數據是否是真一緻的？若沒有快照，需要将備份數據恢複到獨立的物理空間裡面，挂載到另一台機器上。有了快照，可以将快照直接挂載到另一台主機，避免了數據物理恢複導入的過程。

卷Clone

快照類似于某時刻的影子，而克隆則是某時刻的實體。每時刻生成了一份可寫的快照，就叫對卷某時刻的一份Clone。然後這份Clone内容每被修改的部分是與源卷共享的，所以源卷沒了，則Clone就沒了，所以叫虛拟Clone

如果把數據複制出來，生成一個獨立的卷，則就叫Split Clone，也就是可以得到實Clone。

卷Clone最大的好處在于可以瞬間生成針對某個卷可寫的鏡像，而不管卷的數據量有多大。

數據備份系統的基本要件

• 備份對象：需要進行備份的備份源。
• 備份目的：磁盤、磁帶等介質
• 備份通路：網絡
• 備份執行引擎：備份軟件
• 備份策略

下面重點介紹一下備份目的、備份通路、備份引擎

備份目的

備份到本地磁盤

備份目的地是在本地的磁盤，則隻需要将數據備份到本地磁盤的另外分區中或者目錄中。

這樣不需要網絡，缺點是對備份對象自己的性能影響大。還會對其他的IO密集型程序造成影響。

這種方式一般用于不關鍵的應用和非IO密集型應用。比如E-mail，對轉發實時性要求不高。

備份到SAN上的磁盤

備份到SAN上的磁盤，就是将需要備份的數據，從本次磁盤讀入内存，再寫入HBA卡緩沖區，然後再通過線纜傳送到磁盤陣列上。

• 優點：隻耗費SAN公用網絡帶寬，對主體影響小。
• 缺點：對公共網絡資源和出口帶寬有影響。

備份到NAS目錄

備份到NAS目錄就是将數據備份到遠程共享目錄中。比如window中常用的文件夾共享。因為數據一般是通過以太網進行傳遞的，占用了前端的網絡帶寬，但是相對廉價，不需要部署SAN

備份到磁帶庫

現在出現一種虛拟磁帶庫，即用磁盤來模拟磁帶，對主機來說看到的是一台磁帶庫，實際上是一台磁盤陣列，主機照樣使用磁帶庫一樣來使用虛拟磁帶庫。要做到這點，就必須在磁盤陣列的控制器上做虛拟化操作，也就是實現協議轉換器的作用。

可以帶來了的好處是：

• 速度提升
• 避免機械手這種複雜的機械裝置
• 管理方便。

信息生命周期管理

将使用不頻繁的數據移動到低速、低成本的設備上。比如隻給視頻應用分配20GB的空間，但是報告有500GB的空間，剩下的空間是在在磁帶庫上。

分級存儲

1. 一線磁盤陣列
2. 二線虛拟磁帶庫：近期不會被頻繁調度。利用大容量SATA盤，性能适中的控制器。
3. 帶庫或者光盤庫。幾年甚至幾十年都不訪問到。

備份通路

本地備份

數據流向：本地磁盤——總線——磁盤控制器——總線——内存——總線——磁盤控制器——總線——本地磁盤

也即數據從本地磁盤出發，經過本地的總線 和内存，經過CPU少量控制邏輯代碼之後，流回本地磁盤。

通過前端網絡備份

經過前端網絡備份的數據流向是：

本地磁盤——總線——磁盤控制器——總線——内存——總線——以太網卡——網線——以太網——網線——目标計算機的網卡——總線——内存——總線——目标計算機的磁盤。

數據從本地磁盤出發，流經本地總線和内存，然後流到本地網卡，通過網絡傳送到目标計算機磁盤。

• 前端網絡：服務器接受客戶端連接的網絡，也就是服務網絡，是服務器和客戶端連接的必經之路。
• 後端網絡：對客戶封閉，客戶的連接不用經過這個網絡，用與服務器和存儲、應用服務器、數據庫服務器的連接。可以是SAN，以太網

通過後端網絡備份

通過後端網絡備份的數據流向是：

本地磁盤——總線——控制器——總線——内存——總線——後端HBA卡——線纜——後端交換設備——線纜——備份目的的後端網卡——總線——内存——磁盤

LAN Free備份

備份的時候不經過LAN，也就是不流經前端網絡，也叫Frontend Free。這樣的好處是不耗費前端網絡的帶寬，對客戶終端接受服務器的數據不影響。。

因為前端網絡一般是是慢速網絡 ，資源非常珍貴。無論是本地、還是網絡，都需要待備份的服務器付出代價，即需要讀取備份源數據到自身的内存，然後從内存寫入備份的目的地。對主機CPU、内存都有浪費。

能否不消耗服務器的性能呢？可以，使用Server Free備份。

Server Free備份

Server Free備份：備份的時候，數據不用流經服務器的總線和内存，消耗極少，甚至不消耗主機資源。

備份源和備份目标都不會在服務器上，因為如果在服務器上，數據從磁盤讀出，要流将總線，然後到内存，這就不是Server Free

那怎麼做呢？

• 用SCSI的擴展複制命令，将這些命令發送給支持Server Free的存儲設備，然後這些設備會提取自身的數據寫入備份目的設備，而不是發送給主機。
• 使用另一台專門做數據移動的新服務器，來代替原來服務器移動備份數據。釋放運算壓力很大的生産服務器。

備份策略

備份引擎：決定整個數據備份系統應該怎麼運作，備份那些内容，什麼時候開始備份，備份時間有沒有限制等的策略。

備份服務器

備份引擎以什麼形式體現呢？當然是運行在主機上的程序，所以需要一台計算機來做引擎的執行者。

那麼備份服務器的備份策略和規則，怎麼傳給整個數據備份系統中的服務器？通過以太網，因為以太網擴展性好，适合節點間通信。相對于以太網，SAN更适合傳送大量的數據。所以常用前端網絡來連接待備份的服務器和備份服務器，因為備份策略的數據包不多。

備份服務器如何與每個待備份的服務器建立通話？怎麼通話？規則怎麼定？需要待備份服務器上運行一個代理程序，專門解釋備份服務器發來的命令，根據命令作出動作。

這個運行在待備份服務器上的程序，就叫備份代理，監聽端口，接收備份服務器發來的命令。

介質服務器

若數據備份系統中有一台SCSI磁帶機，且多台主機想備份到這台磁帶機上。而SCSI磁帶機隻能同時接到一台主機上。

那麼怎麼辦呢？可以引入一台專門的計算機，隻能由這台計算機來操作磁帶機。

需要備份的計算機通過以太網将數據發給這台掌管磁帶機的計算機，然後寫給磁帶機。

這樣磁帶機成為了公用設備，而在整個系統中，隻有一台計算機能掌管備份目标，它就類似于一個代理，代理其他服務器執行備份。我們把它稱為介質服務器

還有一個問題，如果有多台服務器向介質服務器發出請求，怎麼辦?當然需要一個協調員，也就是備份服務器，它可以指揮安裝在待備份服務器的代理，讓每台服務器按照順序有條理的使用介質服務器提供的備份介質進行備份。

三種備份方式

完全備份

不管文件多大，隻要要備份，都需要将文件都備份下來。

差量備份

差量備份：隻備份從上次完全備份以來發生變化的數據。

差量備份要求必須做一次完全備份，作為差量的基準點

增量備份

隻備份從上次備份以來這份文件中變化過的數據。** 上次備份**，不管是全備、差備，還是增量備份。

對于數據庫的備份，備份軟件想知道每個數據文件的變化是不可能的，因為數據庫文件内部格式非常複雜，隻有自己才能分析和檢測出來。所以數據庫管理軟件有自己的備份工具。第三方備份軟件隻能調用數據庫軟件自身提供的命令。

四、DAS , SAN和NAS

NAS

LUN隻是一個卷設備，對主機而言就是一塊硬盤，我們的操作系統集成了文件系統的功能，可以用來管理卷。而 NAS就是把文件系統從主機遷移到磁盤陣列上，自己來管理。使用者隻需要通過網絡告訴這個文件系統需要存取什麼文件而不需要向NAS傳遞LBA地址。

那麼NAS與SAN的區别是什麼？

SAN是網絡上的磁盤，NAS是網絡上的文件系統。

• SAN：存儲區域網絡，是網絡上的磁盤，其本質隻是一個網絡，包含了主機、适配器等一切後端存儲相關的内容。可以說SAN包含NAS。
• 一般把FC網絡上的磁盤叫做SAN，以太網上的文件系統叫NAS

另外， FTP服務器屬于NAS嗎？不屬于，為什麼？

我們知道網絡文件系統與本地文件系統最大的區别是傳輸方式從主闆的導線變成了以太網絡，也就是傳輸的距離可以更快了。但是FTP實際上必須把文件傳輸到本地的某個目錄才能執行，而網絡文件系統不需要将數據複制到本地再進行訪問，可以進行挂載。

NAS與SAN之争

誰更快

NAS主要實現虛拟目錄層與文件系統層的通信，使用的是“以太網 TCP/IP”，為了處理TCP/IP和以太網邏輯，增加了不少的CPU指令，同時使用的是以太網等低速介質。

而FC SAN中，FC邏輯有很大一部分由HBA卡完成，同時FC協議的速度比以太網更快，所以整體來說FC SAN肯定更快。

但是在大量随機小塊IO的場景下，因為NAS系統對并發IO進行了優化，而且文件系統邏輯由專門的設備處理，所以性能可能會比SAN更高。

既然這樣，為什麼還需要使用NAS呢？因為

• 最重要的原因是NAS成本更低，不需要昂貴的FC HBA卡和FC交換機。
• 基于以太網、TCP/IP，擴展性強
• 可以提供多種協議訪問。網絡文件系統通過HTTP、FTP等協議進行訪問，而SAN隻有SCSI協議。
• 采用專門的設備處理文件系統邏輯， 可以解放主機CPU和内存，适合在CPU密集的應用環境。
• NAS可以在一台盤陣上實現多台客戶端同時訪問。SAN的LUN一般隻能分配給某個主機，隻有通過集群系統對數據一緻性進行了保證以後，才能實現LUN共享

所以單純的讨論SAN好還是NAS好是沒有意義的，我們更需要的是根據場景、成本等要素來決定到底使用NAS還是SAN。

我們可以把目前的應用分為兩種：IO密集與CPU密集

• CPU密集：程序内部邏輯複雜，但是對磁盤IO訪問量不高。比如高性能運算
• IO密集：内部邏輯不複雜，但是需要随時存取硬盤的，比如Web應用
• IO和CPU同時密集：不适合單機運行，需要組成集群

對于高并發随機小塊IO，或者共享訪問文件的環境，因為NAS做了很多的優化，此時應該優選NAS。而對于大塊順序IO密集的環境，NAS比SAN慢，所以優選SAN。

與SAN和與NAS設備通信的過程

對主機而言，如果與SAN通信，必須通過文件系統。當應用程序發出指令後，文件系統會計算LBA地址，然後通過FC網絡告訴SAN。SAN取出數據，通過FC網絡傳送給主機，然後放入程序的緩沖區。

那與NAS設備通信呢？程序隻需要告訴NAS設備路徑 文件即可，也就是說通過操作系統的虛拟目錄與NAS進行對話，通過TCP/IP 以太網進行傳輸，後面的過程就都在NAS設備内部了，它會查找要取的文件的扇區位置，存儲數據。

其實NAS設備還可以進行拆分，它可以把硬盤拆分出去，隻是做為一個專門處理文件邏輯的設備而存在，這就是NAS網關

DAS、NAS、SAN

DAS：最原始的存儲：直接存儲。存儲設備隻用與獨立的主機。比如PC中的磁盤或者隻有一個外部SCSI接口的JBOD

DAS（僅供自己使用）到SAN（出租倉庫給其他的租戶），到NAS(集中式理貨服務外包)

SAN是一種網絡，而不是某種設備。隻要是專門向服務器傳輸數據的網絡就可以稱為SAN。

NAS設備通過以太網向主機提供文件級别的數據訪問，以太網絡就是SAN。

習慣性的将FC SAN架構稱為SAN

NetApp的NAS

NetApp的NAS極大的借鑒了數據庫管理系統的設計，本小節主要講解一下NetApp的NAS的基本思想。

利用了數據庫管理系統的設計

我們知道數據庫管理系統是這樣記錄日志的，在某個時刻，數據庫管理系統接收到應用程序的SQL更新語句，首先将數據修改前的狀态以日志的形式保留在内存的日志緩存區，然後覆寫原來的數據。

因為日志緩存區是内存的一部分，所以如果掉電則數據丢失，所以每隔一段時間或者說程序進行提交事務時，管理系統會把日志推到磁盤中。同理，也會把緩存中更新過的數據塊寫入磁盤。

隻有當日志确實寫入到硬盤上的日志文件中的時候，才會對上層應用返回執行成功。

具體過程可以參見數據庫（五），事務。

NetApp借鑒了這種設計思想，它會将文件系統中的寫入請求作為操作日志寫入到NVRAM中保存。

NVRAM不用電池也可以在不供電的情況下保存數據，而NetApp使用的是帶電池保護的RAM，下文姑且稱其為NVRAM.

為什麼要使用NVRAM而不像數據庫一樣使用文件來保存日志的呢？

對于數據庫系統來說，先将日志寫入到内存中日志緩沖區，再在觸發條件下将日志寫入磁盤上的文件。一旦意外掉電，内存中的日志沒有來得及保存到硬盤就丢失，數據庫再次啟動的時候，會提取硬盤上的日志，對于沒有提交的操作進行回滾。這樣就保證了數據的一緻性。

不過如果應用程序頻繁提交，日志緩沖區的日志會頻繁的寫入到磁盤上，這時日志緩存就起不了什麼作用了。

對數據庫來說，上層的每個業務一般都算是一個交易，在尚未完成的時候，程序不會發送提交指令給數據庫系統的，所以頻繁提交的頻率不高。

而文件系統則不然，上層應用向文件系統寫入數據而言，每次請求都是完整的交易。也就是說提交會非常頻繁。如果将操作日志寫入磁盤，開銷大，所以利用了帶電池保護的RAM内存（NVRAM）。隻要成功寫入了RAM，就可以立即通知上層寫入成功。

一定要搞清楚日志和數據緩存的區别。

• 日志是記錄操作動作和數據内容，而非實際的數據塊。保存在NVRAM中
• 實際的數據塊保存在RAM中而非NVRAM中。

WAFL的做法是用RAM來保存日志，可以一次接收到上千條寫請求，而且可以直接返回成功。等到RAM半滿，由WAFL一次性批量連續寫入硬盤，保證高效率。

WAFL從不覆寫數據

當日志占了NVRAM空間的一半或者每10s，WAFL會将内存中已改寫的數據以及元數據批量寫入硬盤。同時清空日志，騰出空間。這個動作叫CheckPoint

WAFL不會覆蓋掉對應區塊中原來的數據，而是尋找空閑塊來存放被更改的塊。也就是說WAFL寫入的數據都會到空閑塊中，而不是覆蓋舊塊。另外，在Checkpoint沒有發生或者數據沒有Flush完全之前，WAFL從來不會寫入任何元數據到磁盤。

這樣可以保證CheckPoint沒發生之前，磁盤上的元數據對應的實際數據仍為上一個CheckPoint的狀态。如果此時斷電，就算新數據寫入了，但是元數據沒有寫入，所以磁盤上的元數據仍指向舊塊，數據就像沒有變化，所以不用執行文件系統檢查等工作。

當CheckPoint觸發時，先寫入數據，最後再寫元數據，然後新元數據指針指向方才寫入的新數據塊。對應的舊數據塊變為空閑塊。（此時塊中仍然有數據，但是沒有任何指針指向它）

IP SAN

以太網的可尋址容量大，比IP都大，而且地址是定長的，使用專用的電路完成交換，還可以使用光纖進行傳輸。最重要的一點是以太網非常的廉價。

但進入以太網有這麼多優點，現在FC SAN還是應用廣泛，這是因為以太網與FC相比，以太網是不可靠的網絡，不是端到端的協議，必須依靠上層協議。而且開銷也比較大。

IP SAN

TCP/IP在速度和性能上無法與FC相比，但是它最大的優點在于擴展性，SCSI都能嫁接到FC上，當然也可以與TCP/IP結合。這種新的協議系統叫ISCSI（Internet Small Computer System Interace ）。

這種協議的優點很明顯，隻要IP可達，兩個節點就可以通過ISCSI通信。所以擴展性非常強。

IP SAN ： 以ISCSI為代表的TCP/IP作為傳輸方式的網絡存儲系統，也就是基于IP的存儲區域網絡

當然IP SAN不一定用以太網作為鍊路層，可以用任何支持IP 的鍊路層，如 ATM 、PPP 、 HDLC 甚至是FC

同樣用TCP/IP來進行傳輸，NAS與IP SAN有什麼區别呢？

NAS傳輸的是文件系統語言。ISCSI傳輸是SCSI指令語言。所以IP SAN本質是SAN提供的是塊存儲

IP SAN相對于FC SAN最大的優勢在于：

• FC SAN 成本是IP SAN的十倍。
• FC是專用網絡，很難擴展
• 部署FC存儲網絡更複雜
• 兼容性：不同生産廠家的FC設備不一定完全兼容

五、Fibre Channnel協議

SAN的概念，SAN首先是個網絡，而不是存儲設備。這個網絡是專門來給主機連接存儲設備用的。

我們知道按照SCSI總線16個節點的限制，不可能接入很多的磁盤，要擴大SAN的規模，隻使用SCSI總線是不行的，所以必須找到一種可尋址容量大、穩定性強、速度塊、傳輸距離遠的網絡結構。FC網絡就應運而生。

FC網絡

Fibre Channnel也就是網狀通道，FC協議從1988年出現，最開始作為高速骨幹網技術。

任何互聯系統都逃不過OSI模型，所以我們可以用OSI來将FC協議進行斷層分析。

物理層

首先有較高的速度：1Gb/s,2Gb/s,4Gb/s，8Gb/s到16Gbps

為了實現遠距離傳輸，傳輸介質起碼是光纖

鍊路層

字符編碼及FC幀結構

FC協議的幀頭有24字節，比以太網幀頭（14字節）還要長。

比如下圖為以太網的報文格式。

為什麼FC協議需要這麼長的幀頭呢？因為24字節的幀頭不但包含了尋址功能，還包含了傳輸功能保障。也就是說網絡層和傳輸層的邏輯都用這24字節來傳輸。

這點就與TCP/IP 以太網不同，以太網基本上沒有傳輸功能保證功能，主要需要靠TCP來進行端到端的傳輸保障。

我們可以對比一下TCP/IP和FC協議的開銷：

基于以太網的TCP/IP網絡，開銷為：

14字節(以太網幀頭) 20字節（IP頭） 20字節（TCP頭） =54字節，或者把TCP幀頭變為UDP（8字節）一共是42字節

而FC協議就24字節，所以開銷比TCP/IP的要小。

網絡層

FC網絡中的節點要通信，無非也就是連、找、發三大要素。

• 連：通過FC交換機打通通路，主要的拓撲結構有FC-AL和Fabric兩種。
• 找：FC協議有一套于以太網不相同的編址方式，可以盡可能減少人為的幹預。
• 發：指的是與目标進行通信

從這個方面基本上就可以了解FC各節點交互的流程了。

連：拓撲

與以太網類似，FC也有兩種拓撲：FC-AL和Fabric

• FC-AL：類似以太網共享總線拓撲，但是連接方式不是總線，而是仲裁環（Arbitral loop）。每個FC -AL 設備首尾接成了一個環路。最多能接入128個節點，實際上隻用了8位的尋址容量。被廣播地址、專用地址占用之後，隻剩下127個實際可用的地址。

仲裁環是應該 由所有設備串聯而成的閉合環路，每個接口上都有一套旁路電路（Bypass Circuit）,一旦檢測到本地設備故障，就會自動将這個接口短路。

一跳一跳的傳輸，而且任何時候隻能按照一個方向向下遊傳輸。

• Fabric：與以太網交換拓撲類似。Fabric的意思是“網狀構造”，表明其實是一種網狀的交換矩陣

相對于仲裁環路來說轉發效率提升了很多，聯入矩陣所有節點可以同時進行點對點通信，加上包交換所帶來的并發和資源充分利用，可使得交換架構獲得的總帶寬為所有端口帶寬之和。

而AL架構下，不管接入的節點有多少，帶寬為恒定，即共享環路帶寬。

下圖為交換矩陣的示意圖。

FC終端設備接入矩陣端點，一個設備發給另一個設備數據幀被交換矩陣收到後，矩陣會撥動交叉處的開關，連通電路，傳輸數據。所以可以把交換矩陣是一個大的電路開關矩陣，根據通信的源和目的決定波動哪些開關。

FC交換拓撲尋址容量是2的24次方個地址，比以太網理論值（2的48次方）少，但是對于專用的存儲網足夠。

找：編址

任何網絡都需要尋址機制，所以需要對FC網絡的每個設備定義一個唯一的标識。

• WWNN（World Wide Node Name）：每個設備自身有一個WWNN
• WWPN(World Wide Port Name)：FC設備的每個端口都一個WWPN，是世界上唯一的。

以太網交換設備的端口不需要有MAC地址，而FC交換機卻需要每個端口都有自己的WWPN。這是因為FC要做的工作比以太網交換機多，許多FC的邏輯都集成在了FC交換機。 需要處理到FC協議的最上層。而以太網相對簡單，因為上層邏輯都被交給TCP/IP這樣的上層協議來實現了。

WWPN：長度是64位，比MAC地址多16位。長度太長，速度低，所以在WWPN上映射一層尋址機制，分配一個Fabric ID，嵌入鍊路幀裡面來做路由

這樣WWPN被映射到了Fabric ID，一個24位的Fabric ID又被分為Domain ID、Area ID、Port ID三個亞尋址單元

• 高8位定義為Domain區分符，用來區分網絡中的FC交換機本身。Domain ID是自主交換機分配的。那主交換機怎麼來的？它是根據WWNN号來進行選舉，WWNN最小者獲勝，成為主交換機，它就有資格向其他交換機分配Domain ID
• 中8位定義為Area區分符，區分同一台交換機的不同端口組。如果一塊芯片可以管理1、2、3、4号FC端口，那麼芯片可以屬于一個Area
• 低8位定義為Port區分符，區分不同的Port

發：地址映射過程

如下的講解主要是針對Fabric 交換架構網絡。

既然要把WWPN映射到Fabric ID上，就一定要有映射機制，那麼每個端口如何獲得Fabric ID的呢？過程比較類似于RARP協議。

當一個端口接到FC網絡的時候，會向注冊服務器發送一個注冊申請，然後這個注冊服務器會返回給它動态分配一個Fabric ID。當然此時注冊服務器會記錄這個映射關系。

此後這個接口的幀不會攜帶WWPN，而是攜帶其被分配的ID作為源地址。這點就與以太網不同，我們知道 以太網既攜帶MAC又攜帶IP，所以在效率上打了折扣。

發：同步其他節點信息

不過還有一個問題，一個端口要與另一個端口通信，那麼怎麼知道要通信目标的Fabric ID是多少呢？

每個節點獲得自己的Fabric ID之後，還會進行名稱注冊。同樣也是向名稱服務器發送注冊幀，主動告知自己的Fabric ID等信息。然後名稱服務器其他節點的信息返回給它。這樣就知道了其他節點地址呢。

如果FC網絡比較大，則可能不隻一台FC交換機。也就是說有若幹FC交換機互聯。與IP網絡不同的是，FC網絡不需要太多的人工介入，它們會自動協商自己的Domain ID（可以回過去看看Fabric ID的結構），選舉出主交換機，由主交換機來為其他的交換機分配Domain ID。交換機之間會運行OSPF等路由協議，這樣可以交互節點信息，尋址各個節點。

現在我們可以與IP網絡對比一下，IP網絡需要很強的人為介入性，需要人來配置節點的IP地址、路由信息等，而FC網絡則可以自動分配和管理地址。最根本原因是因為FC協議一開始設計就是為了高速、高效的網絡，而不是給Internet使用的。所以自動分配地址當然适合。

發：與目标通信

此時每個節點已經獲得了Fabric ID了，同時還從名稱服務器得知網絡上其他節點的ID，萬事俱備，完全可以與其他節點進行通信了。

• 首先需要直接向目的端口發起一個N_PORT Login過程，目的協商一系列的參數
• 然後進行Process Login過程（類似TCP向端口發送握手包），即進行應用程序間的通信。比如FC可以承載SCSI協議，那麼此時Initiator端就需要向Target端發起請求了。
• 這些Login過程其實就是上三層的内容，屬于會話層。但是Login幀也必須通過下4層來封裝并傳輸到目的地，就像TCP握手一樣。

FC網絡中還有一中FC Control Service，如果節點向這個服務進行注冊了以後，一旦網絡狀态有變動，将會把最新的信息同步到這些節點。

最後一點

上面提到的名稱服務器、注冊服務器其實一般都是運行在交換機内部的，而不是物理上的服務器。

傳輸層

FC協議的傳輸層的作用與TCP相似，也也進行Segment以及通過端口号區分上層應用。

• 對上層數據流進行Segment。
• 每個Exchange（上層程序）發來的數據包，被FC傳輸層分割為Information Unit，類似于TCP的Segment。
• 然後下層協議為每個Segment分配一個Sequence ID，再分割為FC所适應的幀
• 區分上層程序。TCP是通過端口号，而FC協議是通過Exchange ID來區分。

FC适配器

要構建一個完整的FC網絡，除了需要FC交換機，還需要FC适配器(FC HBA,Host Bus Adapter)

HBA可以指代任何一種設備，隻要這個設備的作用是将一個外部功能接入主機總線，所以PCIE網卡、聲卡和顯卡都可以叫HBA。

下圖是用來接入FC網絡的各種線纜，有SC光纖，DB9銅線和RJ45/47線纜。可以看出FC不一定是光纖

FC适配器有自己的CPU、RAM、ROM。是一個嵌入式設備。與RAID卡類似，隻是不像RAID卡需要那麼多的RAM來做數據緩存。

SCSI遷移到FC

如何遷移

在上面一章我們把FC協議進行了簡單的介紹，現在是時候把SCSI遷移到FC上了。

回顧一下，為什麼要這麼做，因為SCSI總線隻能接16個節點，不利于擴展，同時傳輸的距離有限，而且不夠高效等。所以我們可以在主機與後端存儲之間使用FC協議，把基于并行SCSI總線的存儲網絡架構遷移到FC的網絡架構。

遷移的過程中存在一個問題，我們知道FC協議并沒有定義SCSI指令集這樣面向磁盤存儲數據的通用語言。那怎麼解決這個問題呢？

在【大話存儲】學習筆記（13章），協議融合中提到了協議融合，此時FC協議與SCSI協議有重疊，但是FC協議在某些方面可以做得更好，所以可以将SCSI語言承載于FC協議進行傳送。

将連接主機和磁盤陣列的通路從并行的SCSI總線替換為串行傳輸的FC通路。但是盤陣後端連接磁盤的接口還是SAS接口。

這樣單台盤陣所能接入的磁盤容量沒有提升，但是前端的性能提升了，因為使用FC協議，可以更為的高速。

好處

引入FC之後，帶來的好處為

• 如果一個盤陣隻有一個FC接口，那麼我們完全可以使用FC交換機來擴充端口。而且采用了這樣的包交換架構，可以實現多個節點向一個節點收發數據，傳輸效率大大提升。

這樣就實現了多台主機共享一個盤陣，提升了盤陣的利用率。

• 而且因為可以使用光纖，所以傳輸距離加長了。
• FC協議功能更為豐富，可以為每台主機劃分不同的LUN，保證了安全性。
• 既然所有的主機都挂在了盤陣上，怎麼保證每台主機能獨享一塊LUN呢？可以從FC交換機，磁盤陣列控制器入手。
• 在磁盤控制器上做手腳：
• 在SCSI協議中有這樣一個過程，此時Initiator想要與Target要進行通信，Initiator需要發一條Report LUN指令給Target，Target端在收到這條指令以後，需要返回自己的LUN信息。那麼磁盤控制器可以 LUN的時候，根據發起端的身份，提供相應的LUN給它。如果強行訪問其他的LUN，就會拒絕。這種方法就叫LUN masking
• 總的來說，可以把LUN當做蛋糕，磁盤控制器就是主人，他可以調查每個主機的身份，根據不同的身份來分配蛋糕。
• 注意，這是SCSI指令集的功能，隻要承載了SCSI指令集的協議就可以實現這個功能。
• 在FC交換機上做手腳：
• 我們知道以太網交換機可以劃分VLAN，也就是可以把某幾個端口劃分到一個邏輯上的LAN中。同樣FC交換機也可以實現類似的功能，不過名字叫ZONE。
• ZONE有軟ZONE和硬ZONE之分。
• 軟ZONE：在名稱服務器上做手腳，欺騙進行名稱注冊的節點，向他們通告其他節點信息。
• 硬ZONE：把交換機某端口歸為一個ZONE，底層完全隔離。如下

多路徑訪問目标

如果盤陣有兩個控制器，每個主機上都有兩塊FC适配卡，它們都連接到了FC交換機。

這樣會存在一個問題，因為主機有兩塊HBA卡，而每塊HBA可以識别兩塊LUN，所以整個主機會識别出4塊磁盤，這就有問題了，因為這樣磁盤就有重複了，造成了混亂。

那麼你可能會說，為啥要兩塊FC HBA卡呢？因為一塊HBA有單點故障，如果使用兩塊HBA卡，一旦一塊HBA卡出現了故障，另一塊卡依然可以維持主機到盤陣的通路。

那多路徑的問題怎麼解決：可以在操作系統中安裝多路徑軟件，它可以識别FC提交上來的LUN，向操作系統提交單份LUN。這個軟件還有個作用，如果某個控制器發生故障，通過這個軟件立即重定向到另一個控制器。

參考,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部