SQL Azure的高可用性

by adonisy 18. 一月 2021 13:50

SQL Azure的高可用性

作者:楊先民

審稿:張智凱

 

雲端計算的主要優點之一是,平台高可用性是該體系結構的一部分。 

Azure 提供高級別的內建硬體、儲存和網路複寫。系統的高可用性通常以每年正常運行時間的百分比來衡量。

在下表中,可看到這些數字在時間方面的含義。


與 Azure 託管儲存結合使用時,單一一個 Azure 虛擬機可提供三個九 (99.9%) 的高可用性。這意味著,該服

務保證虛擬機可在高達 99.9% 的時間內具備高可用性,轉換成每年的故障時間不超過 8.77 小時。

除了預設數量的 9 之外,還可將其他功能納入到 Azure 虛擬機中的 SQL Server 中,以確保達到最大正常

運行時間。


Azure 平台可用性


除了內建的高可用性之外,Azure 平台還提供兩個選項,為 VM 和某些 PaaS 工作負載提供更高級別的可用性。

可用性區域和可用性集區可保護工作負載免受計劃內維護活動和潛在硬體故障的影響。

 

可用性區域

可用性區域是某個區內的惟一的實體位置。每個區域由一個或多個配備獨立電源、冷卻裝置和網路的資料中心組成。

在支援可用性區域的 Azure 區域內,在 VM 創建過程中選擇使用可用區時,可指定要將虛擬機駐留在哪個區域中。


每個受支持的 Azure 區域都有三個可用性區域。當將多個 VM 部署到不同區域時,可用性區域可提供高可用性

以防止資料中心發生故障。

此外,它們還為 Microsoft 提供一種在任何給定時間內,通過僅更新一個區域即可對每個區域執行維護的方法

(使用稱為更新域的分組)。


可將虛擬機生態系統分佈在該區域的三個區域中。將可用性區域和 Azure 虛擬機組合使用,可將運行時間提高到 99.99%

,這相當於每年最多 52.60 分鐘的故障時間。可通過 docs.microsoft.com 確定哪些 Azure 區域支持可用性區域 。


如果你所在地區有可用性區域,並且應用程式支持最小跨區域延遲,則可用性區域將為應用程式提供最高級別的可用性。

 

在上圖中,你可以看到可用性區域配置。將 VM 部署到具有可用性區域的地區時,會出現在區域 1、2 和3 中部署的選項。

這些區域是實體資料中心的邏輯表示,意味著在一個訂閱中部署到區域 1,並不代表區域 1 在另一個訂閱中表示相同的資料中心。


可用性集

可用性集類似於可用性區域,不同之處在於,可用性集不是在區域中的資料中心之間分散工作負載,而是在資料中心的服務器和

機架之間分散工作負載。

由於 Azure 中幾乎所有工作負載都是虛擬的,因此,可使用可用性集來保證包含Always On 可用性組成員的兩個 VM 不在同一實體主機上運行。

可用性集可提供高達 99.95% 的可用性,當某個地區的可用性區域不可用,或應用程序無法容忍區域內延遲時,應使用可用性集。


SQL Server 高可用性選項


SQL Server 提供兩個主要選項來實現高可用性:Always On 可用性組和故障轉移叢集實例。此外,為虛擬機使用可用性組還提供允許災難恢復的選項。


Always On 可用性組 (AG)


可在 Azure 虛擬機上或本地資料中心與 Azure 之間運行的兩個或更多(最多九個)SQL Server 實例之間實現 Always On 可用性組。

在可用性組中,將資料庫事務提交到主副本,然後將這些事務同步或異步發送到所有輔助副本。


服務器之間的實體距離(即它們是否在同一 Azure 區域)決定了應選擇哪種可用性模式。

通常,如果工作負載要求盡可能低的延遲,或要求輔助副本在地理位置上分散開,則建議使用非同步可用性模式。

如果副本位於同一 Azure 區域內,並且應用程式可承受一定程度的延遲,則同步提交模式將有助於確保在允許應用程式繼續之前,

將每個事務都提交給一個或多個輔助資料庫。 

Always On 可用性組同時提供高可用性和災難恢復,因為單個可用性組可同時支持同步和非同步可用性模式。

請注意,可用性組的故障轉移單位是一組資料庫,而不是整個實體。


SQL Server 故障轉移叢集實例


如果需要保護整個實體,則可使用 SQL Server 故障轉移群集實體 (FCI),該實例可在單個區域中為整個實例提供高可用性,

但不與其他功能(如可用性組或日誌傳送,將在之後中介紹)結合使用就無法提供災難恢復功能。 

FCI 還需要共享儲存,可通過使用共享文件儲存或使用 Windows Server 上的儲存空間直接在 Azure 上提供共享儲存。


對於 Azure 工作負載,可用性組是較新部署的首選解決方案,因為 FCI 的共享儲存要求增加了部署的複雜性。

但是,對於從本地解決方案的搬移,可能需要 FCI 才能獲得應用程式的支援。


SQL Server 災難恢復


儘管預設情況下 Azure 平台 99.9% 的時間正常運行,但仍可能發生災難並影響應用程式的正常運行時間。

進行任何類型的遷移時,必須有適當的災難恢復計劃。 

Azure 提供多種方法來確保在發生災難時保護虛擬機上的 SQL Server。這包括兩個組成部分:Azure 平台選項

(例如用於備份和 Azure Site Recovery的異地複寫儲存)(這是適合你所有工作負載的全面災難恢復解決方案),

和 SQL Server 特定的產品/服務(例如可用性組和備份)。



本機 SQL Server備份


我們通常將備份視為任何資料庫管理員的生命之源,與雲端解決方案一起使用時也是。

使用 Azure 虛擬機上的 SQL Server 時,你可以精細的控制備份的發生時間和儲存位置。

你可以利用 SQL 代理作業直接備份到鏈接到 Azure Blob 儲存的 URL。 

Azure 提供使用異地複製儲存 (GRS) 或讀取連接異地複製存儲 (RA-GRS)的選項,以確保你的備份文件安全地隱藏在整個地理環境中。

此外,可讓作為 Azure SQL VM 服務提供商的平台自動管理備份。



SQL Server 的 Azure 備份


Azure 備份解決方案要求在虛擬機上安裝代理。然後,代理與 Azure 服務進行通信,該服務管理 SQL Server 資料庫的自動備份。 

Azure 備份還提供中心位置,供你用於管理和監視備份,以確保滿足任何指定的 RPO/RTO 指標。

 

如上圖所示,Azure 備份解決方案是全面的企業備份解決方案,可長期保留資料、自動化管理和附加資料保護。

此選項不僅需要執行你自己的備份或使用適用於 SQL Server 的 Azure 資源提供程式,還需要提供更完整的備份功能集。

 

可用性組

除了上述高可用性方案外,Always On 可用性組還可用於災難恢復。你可在 Azure 區域中實現多達 9 個資料庫副本,

並通過分佈式可用性組進一步擴展此架構(將在之後介紹)。這可確保資料庫的可行副本位於主要區域外的其他位置。

這樣有助於你確保資料生態系統免受自然災害和人為災害的影響。

 

 

上圖顯示了在 Windows Server 故障轉移叢集上運行的 Always On 可用性組的邏輯圖。其中包括 1 個主副本和 4 個輔助副本。

在此情況下,所有 5 個副本可以同步的,或是同步與同步副本的某種組合。

請注意,如上所述,故障轉移的單位是資料庫組,而不是實例。故障轉移群集實例在實例級別提供 HA 時不提供災難恢復。


Azure Site Recovery (ASR)


Azure Site Recovery 是一種將對你的 Azure 虛擬機執行塊級複製的低成本解決方案。

該服務提供多種選項,包括測試和驗證災難恢復策略的能力。與事務資料庫虛擬機相比,此解決方案最適合於無狀態環境

(例如 Web 服務器)。 


Azure Site Recovery 支持 SQL Server 環境,但目前具有相對較高的恢復點目標(長達 1 小時),

使其更適合在允許的停機時間內遷移。更常見的用例是讓所有無狀態應用程序與 Azure 組一起使用 Azure Site Recovery,以提供較低的 RPO。


預配和部署


Azure 生態系統提供幾種不同的方法來在 Azure 虛擬機上預配新的 SQL Server 實體。每種方法都提供不同的功能,

例如具有可重複過程的能力(通過 PowerShell 等腳本語言)或通過 Azure Portal無需了解編程構造即可完成目標的方法。


Azure 市場


Azure 市場本質上是一個集中的位置,可基於預先設計的模板創建 Azure 資源。例如,可通過單擊幾下滑鼠以及一些基本訊息

(例如虛擬機名稱以及一些 SQL Server 配置訊息)在 Windows Server 2019 上快速創建 SQL Server 2019 實體。


提供後,Azure 資源管理器 (ARM) 將啟動虛擬機的創建,並在幾分鐘之內啟動並運行。


Azure 市場中 Windows Server 2019 上的 SQL Server 2019 邊欄選項卡如下圖所示。該邊欄選項卡提供支持 OLTP 或 Data Warehouse 

工作負載的預設配置選項,並允許指定儲存、修補更新和備份選項。

 

使用 Portal創建 Azure 資源的缺點是它不是一個容易重複的過程。但是,通過 Portal門戶入門很容易,並且新管理

員可藉此快速啟動並運行。


儲存注意事項


無論是本地實體還是安裝在 Azure VM 中,SQL Server 都需要良好的儲存性能來提供強大的應用程序性能。 

Azure 提供多種儲存解決方案來滿足工作負載需求。

儘管 Azure 提供各種類型的儲存(Blob、文件、佇列、表),但在大多數情況下,SQL Server 工作負載將使用 Azure 託管磁磁。

例外情況是,故障轉移叢集實例可在文件儲存上構建,而備份將使用 Blob 儲存。 


Azure 託管磁碟充當呈現給 Azure VM 的塊級儲存設備。託管磁碟具有許多優勢,包括 99.999% 的可用性、可擴展的部署

(每個區域每個訂閱最多可有 50,000 個 VM 磁碟),以及與可用性集和區域集成,以在發生故障時提供更高級別的復原能力。

 

Azure 託管磁碟均提供兩種類型的加密。


Azure 服務器端加密由儲存服務提供,並充當儲存服務提供的靜態加密。 

Azure 磁碟加密使用 Windows 上的 BitLocker,以及 Linux 上的 DM-Crypt 在 VM 內部提供操作系統和資料磁碟盤加密。


兩種技術都可與 Azure 金鑰保管庫集成,並允許你攜帶自己的加密金鑰。


每個 VM 至少具有兩個與之關聯的磁碟:操作系統磁碟盤和臨時磁碟。


操作系統磁碟 - 每個虛擬機將需要一個包含啟動卷的操作系統磁碟。這指的是 Windows 平台虛擬機上的“C:”驅動器,

或 Linux 上的“/dev/sda1”。操作系統會自動安裝到操作系統磁碟上。


臨時磁碟 – 每個虛擬機將包含一個用於臨時儲存的磁碟。此儲存用於非永久性的資料,例如頁面文件或交換文件。

由於該磁碟是臨時的,不應用於儲存任何關鍵資訊,例如資料庫或事務日誌文件,因為它們在虛擬機維護或重啟期間會遺失。


該驅動器會在 Windows 上安裝為“D:\”,在 Linux 上安裝為“/dev/sdb1”。


此外,可以並應該在運行 SQL Server 的 Azure VM 中添加其他資料磁碟。

資料磁碟 – 術語“資料磁碟”在 Azure Portal中使用,但實際上,這些只是添加到 VM 的其他託管磁碟。


借助 Windows 的儲存空間或 Linux 的邏輯捲管理,可共用這些磁碟以增加可用的 IOP 和存儲容量。

此外,每個磁盤可以是以下幾種類型之一:


標準 HDD 是 Azure 上的原始儲存產品,可為非 I/O 密集型工作負載提供經濟高效的儲存。

標準磁碟的常見用例是 SQL Server 備份。


● 標準 SSD 是固態驅動器,其延遲和 IOPS 與最大為 4 TB 的標準 HDD 驅動器類似;但是,這種類型

在大型捲上可顯著提高性能。標準 SSD 確實可提供保證的性能水平,而標準 HDD 磁碟則不可以。


● 高級 SSD 是 SQL Server 工作負載最常用的磁碟類型。它們在所有地區都可用,並支持各種 VM 類

型。高級磁碟在價格和性能之間取得了良好的平衡。


● 超級 SSD 提供最低的延遲(亞毫秒級)和最高的潛在 IOP。超級 SSD允許獨立配置 IOP、存儲捲和頻

寬,便於更精細的成本控制。


Azure 上 SQL Server 的最佳實踐建議使用池化的高級磁碟來增加 IOP 和儲存容量。


資料文件應通過 Azure 磁碟上的讀取暫存存儲存在其自己的池中。


事務日誌文件無法從此暫存中受益,這些文件應進入其自己的池中而非暫存。 


TempDB 可以選擇進入自己的池,也可以使用 VM 的臨時磁碟,由於其實際連接到運行 VM 的實體服務器,所以延遲低。

正確配置的高級 SSD 延遲僅為幾毫秒。對於需要更短的延遲時間的任務關鍵型工作負載,你應考慮使用超級 SSD。


以上就是本次的Azure高可用性,之後還會有更詳細的相關設定。

Tags:

SQL Server資料庫 | 楊先民Adonis Young

不允許評論

NET Magazine國際中文電子雜誌

NET Magazine國際中文電子版雜誌,由恆逸資訊創立於2000,自發刊日起迄今已發行超過500篇.NET相關技術文章,擁有超過40000名註冊讀者群。NET Magazine國際中文電子版雜誌希望藉於電子雜誌與NET Developer達到共同學習與技術新知分享,歡迎每一位對.NET 技術有興趣的朋友們多多支持本雜誌,讓作者群們可以有持續性的動力繼續爬文。<請加入免費訂閱>

月分類Month List