（文章來源：51CTO）

不知您是否意識(shí)到，云計(jì)算讓那些提供關(guān)鍵性服務(wù)的SQL Server部署方案獲得了高可用性(HA)和災(zāi)難恢復(fù)(DR)能力。據(jù)此，Azure、AWS和Google都在全球范圍內(nèi)部署了最先進(jìn)的分布式數(shù)據(jù)中心，并以各種SLA的形式，向用戶承諾99.95%或更高的虛擬機(jī)(VM)可用水平。當(dāng)然，針對(duì)HA或DR的SQL Server配置，往往涉及到建立Windows服務(wù)器故障轉(zhuǎn)移群集(Windows Server Failover Cluster，WSFC)。通過此類群集，SQL Server不僅能夠保證其本身在不同主機(jī)上的高可用性，更重要的是那些與SQL Server交互的不同存儲(chǔ)設(shè)備上數(shù)據(jù)也具有極高的可用性。

在傳統(tǒng)的WSFC中，數(shù)據(jù)通常被存儲(chǔ)在存儲(chǔ)區(qū)域網(wǎng)絡(luò)(SAN)或SMB3(譯者注：Server Message Block是一種能夠被用于Web連接，以及客戶端與服務(wù)器之間進(jìn)行信息溝通的協(xié)議)中，并以共享的方式供WSFC中的所有服務(wù)器節(jié)點(diǎn)訪問。但是，云存儲(chǔ)無法以與傳統(tǒng)SAN相同的方式實(shí)現(xiàn)共享。為了克服這種局限性，人們不得不使用第三方的方法，或Windows原生的方法來克服此類共享存儲(chǔ)的限制性。

如果我們將HA反映到數(shù)字上，其實(shí)就是99.99%或更高的在線保證率。在數(shù)據(jù)中心的構(gòu)建過程中，我們可以將兩個(gè)或多個(gè)虛擬機(jī)(VM)群集配置到Azure數(shù)據(jù)中心的單獨(dú)機(jī)架中(常被稱為“可用性集合”)，以保證在99.95%的時(shí)間里至少有一個(gè)VM可用。同時(shí)，Azure和AWS也能夠讓您在多個(gè)數(shù)據(jù)中心間(常被稱為“可用區(qū)間”)實(shí)現(xiàn)VM的群集。通過此類SLA，您會(huì)在99.99%的時(shí)間內(nèi)擁有至少一個(gè)可用的VM。

不過，這些SLA保障的是VM本身的可用性，而不是SQL Server及其數(shù)據(jù)的可用性。也就是說，當(dāng)主VM出現(xiàn)故障，業(yè)務(wù)轉(zhuǎn)移到群集中的備用VM上時(shí)，為了讓服務(wù)能夠以最小的中斷狀態(tài)繼續(xù)進(jìn)行，備用VM必須能夠繼續(xù)運(yùn)行SQL Server，并能夠訪問到各種基礎(chǔ)數(shù)據(jù)庫(kù)的文件。可見，我們需要通過進(jìn)一步的配置，才能確保SQL Server及其基礎(chǔ)數(shù)據(jù)的可用性。

那么，我們?cè)撊绾未_保SQL Server和云端數(shù)據(jù)的高可用性呢？如果您主要使用的是Windows Server的原生服務(wù)(而不是第三方提供的產(chǎn)品)，那么您有兩種選擇：您既可以在Windows Server 2016或更高的企業(yè)版上使用直接存儲(chǔ)空間(Storage Spaces Direct)，也可以在SQL Server 2012或更高的企業(yè)版上創(chuàng)建AlwaysOn可用性組。

上述兩種方法各有優(yōu)缺點(diǎn)。Storage Spaces Direct(S2D)主要是在軟件中創(chuàng)建虛擬的存儲(chǔ)區(qū)域網(wǎng)絡(luò)(SAN)，以方便Windows Server故障轉(zhuǎn)移群集(Windows Server Failover Clustering，WSFC)中的任意VM進(jìn)行訪問。這種方式貌似針對(duì)傳統(tǒng)故障轉(zhuǎn)移群集的云端升級(jí)版本，但是由于我們必須將該群集配置為可用性集合，因此其中的所有VM都需要位于同一數(shù)據(jù)中心。在極端情況下，整個(gè)數(shù)據(jù)中心可能會(huì)由于破壞性事件而關(guān)閉，那么所有的VM及其存儲(chǔ)數(shù)據(jù)將隨之掉線。這就是為什么使用S2D的配置方式，是永遠(yuǎn)不會(huì)獲得超過99.95%可用性的原因。

此外，S2D對(duì)于單個(gè)數(shù)據(jù)中心的要求，還消減了那些橫跨多個(gè)數(shù)據(jù)中心，并且部署在Azure、AWS、甚至是Google云平臺(tái)區(qū)域內(nèi)的SQL Server故障轉(zhuǎn)移群集實(shí)例(FCI)的高可用性。與直接存儲(chǔ)空間相反，AlwaysOn可用性組(AG)能夠支持地理位置不同的數(shù)據(jù)中心之間的AG拷貝。在位于不同數(shù)據(jù)中心的副本完成了適當(dāng)配置之后，與AG關(guān)聯(lián)的SLA會(huì)上升到99.99%。畢竟，AG的配置并不像SQL Server FCI那樣重度依賴共享式的存儲(chǔ)。

AG提供的服務(wù)可以自動(dòng)在各個(gè)副本之間同步SQL Server數(shù)據(jù)。也就是說，如果當(dāng)前active的SQL Server實(shí)例失敗了，那么被指定的副本服務(wù)器將接管，并開始主導(dǎo)已復(fù)制到該實(shí)例中的數(shù)據(jù)庫(kù)。當(dāng)然，這種方法也有著一定的缺點(diǎn)：AG雖然會(huì)復(fù)制用戶定義的數(shù)據(jù)庫(kù)，但是它不會(huì)復(fù)制關(guān)鍵的系統(tǒng)數(shù)據(jù)庫(kù)，例如：Master和MSDB。

這些關(guān)鍵系統(tǒng)數(shù)據(jù)庫(kù)包含了各種agent jobs、登錄名和密碼等?？梢姡绻捎诠收蠈?dǎo)致SQL Server的主實(shí)例掉線，那么這些數(shù)據(jù)庫(kù)均無法受到保護(hù)。另外，值得一提的是：Microsoft尚未測(cè)試超過100個(gè)SQL Server數(shù)據(jù)庫(kù)或10個(gè)AG的AlwaysOn可用性組。也就是說，如果需要同時(shí)保護(hù)大量的數(shù)據(jù)庫(kù)，那么AG可能會(huì)面臨著某種限制。

在上述各種原因的基礎(chǔ)上，基于云端的文件共享應(yīng)運(yùn)而生。您一定迫不及待地想知道：它是否可以超越Windows Server固有的限制，帶來高性能的基于云端的HA和DR解決方案呢？

我個(gè)人認(rèn)為：從長(zhǎng)遠(yuǎn)來看，答案是肯定的。AWS最近表示，用戶企業(yè)可以使用Amazon FSx(譯者注：Amazon基于Windows Server的文件系統(tǒng))來配置某個(gè)WSFC。由于WSFC中的所有節(jié)點(diǎn)都可以訪問文件共享，因此主節(jié)點(diǎn)一旦掉線，那么即便它在另一個(gè)數(shù)據(jù)中心，群集也會(huì)自動(dòng)轉(zhuǎn)移到備用節(jié)點(diǎn)上，以繼續(xù)使用在Amazon FSx文件共享中存儲(chǔ)著的SQL Server數(shù)據(jù)。Azure同時(shí)也表示：用戶企業(yè)可以使用Azure的高級(jí)文件共享在FCI中配置SQL Server。據(jù)此，我認(rèn)為：一直以來故障轉(zhuǎn)移群集的本地?cái)?shù)據(jù)中心模式會(huì)逐漸切換到云端模式。

不過在短期看來，答案也可能是否定的。其原因在于：當(dāng)今基于云端的共享文件產(chǎn)品主要存在著一個(gè)顯著的缺陷，即：現(xiàn)有云端文件共享服務(wù)的基本SLA只能保證99.9%的讀、寫操作可用性，而且遠(yuǎn)低于我們?cè)谡務(wù)摳呖捎眯詴r(shí)所要求的99.99%的SLA基準(zhǔn)線。至于其他方面的問題，我們客觀性地總結(jié)在了下表之中。

我們可以預(yù)測(cè)：基于云端的文件共享方式將成為S2D和AG有效的替代方案。在不久的將來，所有云服務(wù)提供商都能夠通過此類方案，針對(duì)SQL Server及其基礎(chǔ)數(shù)據(jù)可用性，提供99.99%或更高的SLA。讓我們拭目以待吧！
（責(zé)任編輯：fqj）