備份服務

  • 13 分鐘

資料遺失是 IT 人員最擔心的情況。 防止資料遺失的最有效策略，就是備份儲存資料的存放磁碟區、虛擬機器、資料庫以及其他系統，以便能還原其資料。 雲端服務提供者僅基於此目的提供備份服務。 一般而言，這些服務可用來備份儲存在內部部署及雲端中的資料，而備份可能會在異地複寫和散佈，以防範導致整個資料中心或全球區域發生資料遺失的事件。

公用雲端是大量流動資源的提供者，不僅是大量的儲存體，且是可高度擴充的儲存集區。 比起所取代的備份儲存系統和磁帶機，至少具備了同樣多元的功能，而且在某些情況下，甚至提供更廣泛的功能。 此外，還能為組織提供實作備援、容錯移轉和安全網路的新機會，在需以營運資本購買所有資產的時代，這些是許多組織根本負擔不起的。 公用雲端儲存選項可滿足資料中心一律迫切需要的角色，但直到最近才得以實現。

雲端式備份服務

公用雲端服務提供者 (CSP) 所提供新式備份服務的特性，是這些提供者擴充其客戶基礎結構的方式。 在這些服務出現之前，組織的一般備份策略有兩層：備份託管資料庫的資料磁碟區，以及備份託管重要工作負載的虛擬機器映像。 備份背後的理論是，當系統發生錯誤以致失敗時，該事件會讓伺服器關閉。 接下來會立即從備份映像還原伺服器的狀態。

雲端基礎結構淘汰了舊的備份理論。 在現代系統中，伺服器是由軟體而非硬體所組成。 虛擬伺服器是由 Hypervisor 虛擬基礎結構 (例如 VMware 的 NSX) 所裝載，或從容器組裝並交由虛擬化作業系統裝載。 無論哪種情況，應用程式和服務的工作負載軟體映像都會持續受控、更新及保護。 事實上，使用中軟體元件本身就是這些安全主機的複本，或是在容器化情境下，原始主機產品會儲存在容器存放庫中，且會視需要自動組合。 造成伺服器節點當機的硬體錯誤，只會讓該節點裝載的伺服器有一段時間無法運作；基礎結構只要重新路由節點周圍的流量，盡力在這段時間替換掉該節點即可。 基礎結構管理員並未執行在一般系統管理過程中還沒有執行的任何動作。

不過，粗略審視新式資料中心就會發現，並非所有新式基礎結構都是雲端式基礎結構。 服務仍裝載在內部部署資料中心的裸機上。 使用中介軟體完成的用戶端/伺服器網路仍然為數眾多。 在數年前與上個世紀的設計相連接的混合式系統中，仍需要儲存足夠的系統顧客群資訊，以便在發生災害時，能以任何務實而快速的手段在新位置重建系統，將對服務等級的影響降至最低。 有了新式備份策略，公用雲端可能就是這個位置，即使快照的系統位在雲端外也一樣。

AWS 備份

2019 年初，Amazon Web Services 為客戶的混合式雲端環境重新設計了雲端式備份服務。 新的 AWS 備份 (圖 2 顯示其瀏覽器式主控台) 以原則引擎為核心，與防火牆的規則仲裁程式不同。 透過這個引擎，備份管理員會寫入指定下列事項的規則：

  • 系統中哪些資源需要備份

  • 每次備份的執行方式及頻率

  • 備份映像的儲存位置

  • 如何監視備份映像的完整性，包括頻率在內

  • 備份映像的保留時間長短

  • 在何種情況下應執行復原和還原

涵蓋所有作用中原則的完整路線是備份方案。 在這裡，每項規則都是依其資源標籤值 (管理員指定的任意名稱) 來參考 AWS 雲端內需要備份的資源。 若要在備份方案中包含彈性區塊儲存體 (EBS) 磁碟區等資源，管理員只需為該資源提供 AWS 備份能辨識的標籤名稱。 如此一來，負責 AWS 資源的管理員或看管人就不需要使用 AWS 備份主控台，只要在看管人的權限範圍內建立資源，作為現有備份方案的一部分即可。

圖 2：AWS 備份主控台。[圖片由 Amazon 提供]

圖 2：AWS 備份主控台。 [圖片由 Amazon 提供]

內部部署資源可以透過 AWS 儲存體閘道併入備份方案。 為達到 AWS 備份的目的，儲存體閘道作為實體儲存體磁碟區和裝置的 API 包裝函式，以供 AWS 服務存取。

一開始，儲存體閘道使用相同介面，以雲端對應架構來替代現有的實體儲存體資產。 例如，現場 iSCSI 磁碟區可以包裝在 AWS 所稱的快取磁碟區中。 此包裝函式可讓現有內部部署應用程式存取雲端儲存體，客戶不用重新設計這些應用程式。 經常存取的資料可以繼續作為快取儲存在 iSCSI 磁碟區上，以減少產生的延遲。 或者，閘道磁碟區最近的內容變更也可以儲存為本機快照集。 但是，儲存體閘道也支援儲存的磁碟區，現場裝置在此繼續維護磁碟區的完整本機複本，儲存體閘道則在雲端維護其鏡像。 新 AWS 備份利用儲存體閘道與實體磁碟區的角色交換，在本機複製雲端磁碟區的備份，同時新增集中式原則管理主控台，以及管理如何維護兩個複本的規則。

針對災難復原，CSP 提供一項主要優勢，能夠快速將組織的重要資料封存在遙遠位置，以達到「異地備援」(geographical redundancy，簡稱 geo-redundancy) 的目的。 AWS 會為所有 CSP，在最多的可用性區域中運作雲端資料中心。 向裝載的應用程式通告其原生功能，以自動容錯移轉至替代區域，並將這項功能延伸至資料備份備援。 不過，容錯移轉區域已知位於相同的 AWS 區域內。 在極嚴重的災害情況下 (要考慮保險業者和風險管理員)，例如電力公司斷電，相鄰的可用性區域可能都會中斷服務。

具有開發人員經驗的軟體開發人員或 IT 操作員，可以使用 AWS 的低階路由服務 Route 53，為組織的特定異地備援路由撰寫自訂原則。 不過，這項技術需要投入大量的心力。 最近，AWS 提供了一項更平易近人的服務 AWS Global Accelerator，這是另一種原則引擎，會將流量和 Route 53 導向至應該託管服務和儲存體的位置。1 Global Accelerator 也可以作為一種「超級平衡器」，針對託管應用程式 (及其中重要資料)，將多個站台散發在分散的可用性區域中。

如 Amazon 技術人員所建議，另一種確保備份資料儲存在適當遠距區域的方式，是將儲存貯體 (AWS 的一般用途備份容器) 建立為初始備份目的地，然後將此儲存貯體複寫到任何指定可用性區域中的備援位置。 AWS 另提供跨區域複寫 (CRR) 服務。2 AWS 根據磁碟區的備份服務，依照儲存和還原的每 GB 制定價格。

從架構的觀點來看，AWS Backup 是專為 AWS 資源鏡像所設計。 讓內部部署資產成為該方案的一部分是透過如後門的兩道手續，首先，將這些本機資產轉換成遠端 AWS 磁碟區 (就 Amazon 而言為遠端)，然後再建立 Backup 與這些本機資產周圍包裝函式的介面。

Azure 備份

Azure 備份能備份內部部署資源 (伺服器和虛擬機器)，也能備份裝載在 Azure 的資源。 其目標不是變更資料中心現有的備份原則，只是要以雲端儲存體取代本機光碟和磁帶機。 Azure 的備份檔案和磁碟區雲端位置稱為「復原服務保存庫」，圖 3 所示為其瀏覽器主控台。 在透過 Azure 入口網站設定此保存庫的期間，管理員會下載並安裝稱為 Microsoft Azure 復原服務代理程式 (簡稱「MARS」) 的用戶端代理程式。在 Windows Server 中，MARS 會以應用程式的形式執行，看起來非常像 System Center 的附加元件。 (或者，管理員可能更偏好使用已內建 MARS 功能的 System Center Data Protection Manager。) 管理員在資料需要備份的網路中找到磁碟區和服務，MARS 則將代理程式散發給負責這些元件的伺服器位址。

圖 3：Azure 復原服務保存庫的主控台。[圖片由 Microsoft 提供]

圖 3：Azure 復原服務保存庫的主控台。 [圖片由 Microsoft 提供]

Azure Backup 的傳遞模型是以災害復原的「服務層級目標」為基礎，提供合理的計量以判斷組織在發生重大災害時，可承受多長時間無法存取業務引擎，以及可承受多少資料遺失。 這些特定目標 (RPO、RTO 和保留期) 將在下一堂課災害復原中討論。

與 Azure Backup 有關的復原類型 (相對於 Microsoft 的災害復原服務 Azure Site Recovery)，完全以資料複寫為中心，而不是服務還原。 例如，客戶會使用 Azure Backup 產生虛擬機器映像檔案 (VHD) 的複本。 但還原 VHD 只是再次重製封存在本機儲存體的映像檔案，卻不會根據該 VHD 重新開機虛擬伺服器。

Azure 備份只收取每月取用的儲存空間費用，還原不會加收額外費用。 儲存體計價模型與備援選項相關聯。 目前 Azure 提供兩個選項：最便宜的選項為本地備援儲存體 (LRS)，可在 Azure 資料中心內複寫資料三次；另一個是異地備援儲存體 (GRS)，可將資料複寫到地理位置距主要區域有相當距離的次要區域。

Google Cloud Storage 備份

Google 根據儲存的資料類別提供各種不同的 Cloud Storage 層，例如持續可用的檔案、虛擬機器映像的區塊儲存體、影片的物件儲存體。 雖然儲存體服務確實可用於 (實務上也用於) 備份和復原，但卻未明確以其中任何一層服務為產品名稱行銷備份服務。 而 Google 也認為備份將會是企業大量投資雲端儲存體的主要原因。

圖 4：Google Cloud Storage 值區的內容。[圖片由 Google 提供]

圖 4：Google Cloud Storage 值區的內容。 [圖片由 Google 提供]

如同 AWS，Google 也將其一般用途的儲存體容器稱為值區 (bucket)。 圖 4 顯示將資料從本機儲存體匯入 Google Cloud Storage (GCS) 值區的一個流程步驟。 類似 Azure 以三大參數為傳遞模型基礎，GCS 的主要參數如下：

  • 效能，在此內容中為可用性的同義詞 (伺服器回應客戶讀取資料要求的速度)

  • 保留期，再次表示客戶希望資料儲存在雲端的時間長短

  • 存取模式，與協助工具相關 (客戶預期讀取或重新叫用所儲存資料的頻率)

初始化值區時，GCS 客戶會選擇「儲存體類別」，以指定複寫原則。 此選擇會決定值區開始用於備份之後，儲存的資料會分散地多廣。 GCS 目前僅提供三個地理位置選項：

  • 單區域：只儲存在 Google 服務地區的一個選取區域

  • 雙區域：跨兩個選取的服務地區複寫

  • 多區域：跨多個服務地區域散發備援

接下來，GCS 會根據存取的頻率細分其值區儲存體類別：

  • 標準/高可用性：可供應用程式和使用者隨時存取的資料

  • Coldline：客戶每月的儲存體費用，有部分用於存取和傳輸費用，適用於每年只存取幾次的資料

  • Nearline：更近似中型交易，適用於每月計劃約存取一次的資料

Google 向企業行銷其雲端基礎結構的方法，是將服務提供為您看不到的設備。 就這一點而言，Google 可能事倍功半，一面提供設備，一面又要表示該設備如何作為個別的服務使用；就像賣了烤箱之後，又預定烹飪食物為其附加價值。

如此一來，GCS 的客戶組織就要為預想中工作選取所需基礎結構，並量身打造該基礎結構的設定，例如設備功能。 (如同 AWS 和 Azure，Google 也提供適用於資料中心的機架設備，供本機和雲端儲存體間的高速傳輸之用。) 這些功能可能會在一段時間後，隨儲存體的使用方式變更予以調校。 例如，假設製片公司需要大量的備份儲存體，以編輯電影的不同版本。 在編輯程序中，因為可能需要頻繁擷取這些複本，所以客戶會將值區設定為單區域地區的標準儲存體。 在影片完成並公開散發之後，即使不會經常存取，仍需要在下一年內保留複本。 在此情況下，基於封存與安全目的，標準值區可能會轉移到具有雙區域國家/地區的 Coldline 值區。

參考資料

  1. Amazon Web Services, Inc. Traffic management with AWS Global Accelerator (使用 AWS Global Accelerator 進行流量管理)https://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/。

  2. Amazon Web Services, Inc. Overview of Setting Up Replication (設定複寫概觀)https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html。

檢定您的知識

1.

雲端式備份服務的主要目標是：