如何在Azure中配置SQL Server 2008 R2故障轉移羣集實例

配置Azure實例
我不會在這裏詳細介紹一些屏幕截圖，特別是由於Azure門戶UI常常會常常更改，因此我拍攝的任何屏幕截圖都會很快變得陳舊。相反，我將只介紹您應該瞭解的重要主題。

故障域或可用區？
爲了確保您的SQL Server實例具備高可用性，您必須確保您的羣集節點位於不一樣的故障域（FD）或不一樣的可用區（AZ）中。您的實例不只須要駐留在不一樣的FD或AZ中，並且您的文件共享見證（見下文）也須要駐留在與您的羣集節點所在的FD或AZ不一樣的FD或AZ中。

這是個人見解。AZ是最新的Azure功能，但到目前爲止它們僅在少數幾個地區獲得支持。AZ提供比FD（99.95％）更高的SLA（99.99％），並保護您免受我在個人帖子Azure Outage Post-Mortem中描述的那種雲中斷 。若是您能夠在支持AZ的區域中部署，那麼我建議您使用AZ。

在本指南中，我使用了AZ，當您進入有關配置負載均衡器的部分時，您會看到它們。可是，若是使用FD，除了負載均衡器配置將引用可用性集而不是可用區以外，一切都將徹底相同。

你問什麼是文件共享見證？
Windows Server故障轉移羣集（WSFC）要求您配置「見證」以確保故障轉移正常運行，而無需詳細說明。WSFC支持三種見證：磁盤，文件共享和雲。因爲咱們在Azure中，所以沒法使用磁盤見證。Cloud Witness僅適用於Windows Server 2016及更高版本，所以咱們可使用文件共享見證。若是您想了解有關羣集仲裁的更多信息，請查看Microsoft Press博客上的帖子，來自MVP：瞭解Windows Server 2012 R2中的Windows Server故障轉移羣集仲裁。

將存儲添加到SQL Server實例
在配置SQL Server實例時，您須要爲每一個實例添加其餘磁盤。最低限度，您須要一個磁盤用於SQL數據和日誌文件，一個磁盤用於Tempdb。在雲中運行時，是否應該爲日誌和數據文件設置單獨的磁盤有些爭議。在後端，存儲所有來自同一個地方，您的實例大小限制了您的總IOPS。在我看來，分離日誌和數據文件確實沒有任何價值，由於您沒法確保它們在兩個物理磁盤集上運行。我會留給你決定，但我把日誌和數據所有放在同一捲上。

一般，SQL Server 2008 R2 FCI會要求您將tempdb放在羣集磁盤上。可是，SIOS DataKeeper有一個很是好的功能，稱爲DataKeeper非鏡像卷資源。本指南不包括將tempdb移動到此非鏡像卷資源，但爲了得到最佳性能，您應該執行此操做。真的沒有理由複製tempdb，由於它不管如何都是在故障轉移時從新建立的。

就存儲而言，您可使用任何存儲類型，但必須儘量使用託管磁盤。確保羣集中的每一個節點都具備相同的存儲配置。啓動實例後，您將須要附加這些磁盤並將它們格式化爲NTFS。確保每一個實例使用相同的驅動器號。

聯網
這不是一項艱難的要求，但若是可能的話，請使用支持加速網絡的實例大小。此外，請確保在Azure門戶中編輯網絡接口，以便您的實例使用靜態IP地址。要使羣集正常工做，您須要確保更新DNS服務器的設置，使其指向Windows AD / DNS服務器而不只僅是某個公共DNS服務器。

安全
默認狀況下，同一虛擬網絡中的節點之間的通訊是敞開的，但若是您已鎖定Azure安全組，則須要知道必須在羣集節點之間打開哪些端口並調整安全組。根據個人經驗，在Azure中構建羣集時遇到的幾乎全部問題都是由阻塞的端口引發的。

DataKeeper有一些端口須要在羣集實例之間打開。這些端口以下：

UDP：137,138
TCP：139,445,9999，以及10000到10025範圍內的端口
故障轉移羣集有本身的一組端口要求，我甚至不會嘗試在此處進行記錄。這篇文章彷佛涵蓋了這一點。

此外，稍後描述的Load Balancer將使用必須容許每一個節點上的入站流量的探測端口。本指南中經常使用和描述的端口是59999。

最後，若是您但願您的客戶端可以訪問您的SQL Server實例，您須要確保您的SQL Server端口是打開的，默認狀況下是1433。

請記住，Windows防火牆或Azure安全組能夠阻止這些端口，所以請務必檢查這兩個端口以確保它們可訪問。

加入域名
SQL Server 2008 R2 FCI的要求是實例必須駐留在同一Windows Server域中。所以，若是您尚未這樣作，請確保已將實例加入Windows域。

本地服務賬戶
安裝DataKeeper時，它會要求您提供服務賬戶。您必須建立域用戶賬戶，而後將該用戶賬戶添加到每一個節點上的本地管理員組。在DataKeeper安裝期間詢問時，請將該賬戶指定爲DataKeeper服務賬戶。注意：暫時不要安裝DataKeeper！

域全局安全組
安裝SQL 2008 R2時，系統會要求您指定兩個全局域安全組。您可能但願展望SQL安裝說明並當即建立這些組。您還須要建立域用戶賬戶並將其放在每一個安全賬戶中。您將指定此賬戶做爲SQL Server羣集安裝的一部分。

其餘先決條件
您必須在兩個羣集實例的每一個實例上啓用故障轉移羣集和.Net 3.5。啓用故障轉移羣集時，還要確保啓用可選的「故障轉移羣集自動化服務器」，由於Windows Server 2012 R2中的SQL Server 2008 R2羣集是必需的。

建立Cluster和DataKeeper卷資源
咱們如今準備開始構建集羣。第一步是建立基本羣集。因爲Azure處理DHCP的方式，咱們必須使用Powershell建立集羣，而不是集羣UI。咱們使用Powershell，由於它容許咱們在建立過程當中指定靜態IP地址。若是咱們使用UI，則會看到VM使用DHCP，而且它會自動分配重複的IP地址，所以咱們但願經過使用Powershell來避免這種狀況，以下所示。

New-Cluster - 名稱 cluster1 - 節點 sql1 ，sql2 - StaticAddress 10.0 .0 .100 - NoStorage

羣集建立後，運行Test-Cluster。這在SQL Server安裝以前是必需的。

測試- 集羣

您將收到有關存儲和網絡的警告，但您能夠忽略Azure中SANless羣集中的預期。若是有任何其餘警告或錯誤，您必須在繼續以前解決這些問題。

建立羣集後，您須要添加文件共享見證。在咱們指定爲文件共享見證的第三臺服務器上，建立一個文件共享，併爲咱們剛剛建立的集羣計算機對象提供讀/寫權限。在這種狀況下，$ Cluster1將是在共享和NTFS安全級別都須要讀/寫權限的計算機對象的名稱。

建立共享後，您可使用配置羣集仲裁嚮導（以下所示）配置文件共享見證。

安裝DataKeeper
在安裝DataKeeper以前等待建立基本集羣很是重要，由於DataKeeper安裝會在故障轉移羣集中註冊DataKeeper Volume Resource類型。若是你已經跳過槍並安裝了DataKeeper，那不要緊。只需再次運行安裝程序並選擇「修復安裝」。

下面的屏幕截圖將引導您完成基本安裝。首先運行DataKeeper安裝程序。

您在下面指定的賬戶必須是域賬戶，而且必須是每一個羣集節點上的本地管理員組的一部分。

當提供SIOS許可證密鑰管理器時，您能夠瀏覽到臨時密鑰，或者若是您有永久密鑰，則能夠複製系統主機ID並使用它來申請永久許可證。若是您須要刷新密鑰，SIOS許可證密鑰管理器是一個將安裝的程序，您能夠單獨運行以添加新密鑰。

建立DataKeeper卷資源
在每一個節點上安裝DataKeeper後，您就能夠建立第一個DataKeeper卷資源了。第一步是打開DataKeeper UI並鏈接到每一個羣集節點。

若是一切都正確完成，服務器概述報告應該以下所示。

您如今能夠建立第一個Job，以下所示。

選擇源和目標後，將顯示如下選項。對於同一區域中的本地目標，您惟一須要選擇的是同步。

選擇「是」並將此卷自動註冊爲羣集資源。

完成此過程後，打開故障轉移羣集管理器並查看磁盤。您應該在Available Storage中看到DataKeeper Volume資源。此時，WSFC將其視爲普通羣集磁盤資源。

SQL Server 2008 R2僅在帶有SQL Server SP2或更高版本的Windows Server 2012 R2上受支持。不幸的是，Microsoft從未發佈過包含SP2或SP3的SQL Server 2008 R2安裝介質。相反，您必須在安裝以前將Service Pack整合到安裝介質上。若是您嘗試使用標準SQL Server 2008 R2媒體進行安裝，則會遇到各類問題。我不記得你會看到的確切錯誤，但我記得他們並無真正指出確切的問題，你會浪費大量的時間來弄清楚出了什麼問題。

截至本文撰寫之日，Microsoft在Azure Marketplace中沒有帶有SQL Server 2008 R2產品的Windows Server 2012 R2，所以若是要在Windows Server 2012 R2上運行SQL 2008 R2，您將自帶SQL許可證在Azure中。若是他們稍後添加該圖像，或者您選擇在Windows Server 2008 R2映像上使用SQL 2008 R2，則必須先卸載現有的SQL Server獨立實例，而後再繼續。

我按照本文選項1中的指導將SP3整合到個人SQL 2008 R2安裝介質上。固然，您將不得不調整一些內容，由於本文引用的是SP2而不是SP3。確保在咱們將用於羣集的兩個節點的安裝介質上整合SP3。

使用帶有SP3的SQL Server 2008 R2媒體進行整理，運行安裝程序並安裝羣集的第一個節點，以下所示。

若是您使用除SQL Server的默認實例之外的任何其餘內容，則本指南中將介紹一些其餘步驟。最大的區別是您必須鎖定SQL Server使用的端口，由於默認狀況下，SQL Server的命名實例不使用1433.一旦鎖定端口，每當咱們引用端口時，您還須要指定該端口而不是1433本指南中的1433，包括防火牆設置和Load Balancer設置。

在這裏，請確保指定未使用的新IP地址。這是咱們稍後在配置內部負載均衡器時將使用的相同IP地址。

正如我以前提到的，SQL Server 2008 R2使用AD安全組。若是您尚未建立它們，請繼續建立它們，以下圖所示，而後再繼續執行SQL安裝中的下一步。

指定先前建立的安全組。

確保您指定的服務賬戶是關聯的安全組的成員。

在此處指定SQL Server管理員。

若是一切順利，您如今能夠在羣集的第二個節點上安裝SQL Server。

在第二個節點上，運行帶有SP3安裝的SQL Server 2008 R2，而後選擇「將節點添加到SQL Server FCI」。

繼續安裝，如如下屏幕截圖所示。

假設一切順利，您如今應該配置一個雙節點SQL Server 2008 R2羣集，其外觀以下所示。

可是，您可能會注意到只能從活動羣集節點鏈接到SQL Server實例。問題是Azure不支持免費ARP，所以您的客戶端沒法直接鏈接到羣集IP地址。相反，客戶端必須鏈接到Azure負載均衡器，該負載均衡器將鏈接重定向到活動節點。要使其工做，有兩個步驟：建立負載均衡器並修復SQL Server羣集IP以響應負載均衡器探測並使用255.255.255.255子網掩碼。這些步驟以下所述。

我將假設您的客戶端能夠直接與SQL集羣的內部IP地址通訊，所以咱們將在本指南中建立內部負載均衡器（ILB）。若是須要在公共Internet上公開SQL實例，則可使用公共負載均衡器。

在Azure門戶中，按照屏幕截圖建立一個新的Load Balancer，以下所示。Azure門戶UI快速變化，但這些屏幕截圖應該爲您提供足夠的信息來完成您須要作的事情。隨着咱們的進展，我會召集重要的設置。

在這裏，咱們建立了ILB。在此屏幕上須要注意的重要事項是您必須選擇「靜態IP地址分配」並指定咱們在SQL羣集安裝期間使用的相同IP地址。

因爲我使用了可用區，我將Zone Redundant視爲一種選擇。若是您使用了可用性集，那麼您的體驗將略有不一樣。

在後端池中，確保選擇兩個SQL Server實例。您不但願在池中添加文件共享見證。

在這裏，咱們配置健康探測器。大多數Azure文檔都使用端口59999，所以咱們將堅持使用該端口進行配置。

在這裏，咱們將添加一個負載平衡規則。在咱們的示例中，咱們但願將全部SQL Server流量重定向到活動節點的TCP端口1433。選擇浮動IP（直接服務器返回）爲已啓用也很重要。

如今，咱們必須在其中一個羣集節點上運行Powershell腳本，以容許Load Balancer Probe檢測哪一個節點處於活動狀態。該腳本還將SQL羣集IP地址的子網掩碼設置爲255.255.255.255.255，以免與咱們剛剛建立的Load Balancer發生IP地址衝突。

＃ 定義 變量 $ ClusterNetworkName = 「」 ＃ 的 集羣 網絡 名稱（使用 優惠- ClusterNetwork 上 的Windows 服務器 2012 的 高 以 找到 該 名稱）$ IPResourceName = 「」 ＃ 的 IP 地址 資源 名稱 $ ILBIP = 「」 ＃ 的 IP 地址 的 在 內部 負載 平衡器（ILB）和 SQL 集羣 導入- 模塊 FailoverClusters ＃ 若是 您 正在 使用 的Windows 服務器 2012 或 更高：獲取- ClusterResource $ IPResourceName | Set - ClusterParameter - Multiple @ { Address = $ ILBIP ; ProbePort = 59999 ; SubnetMask = 「255.255.255.255」 ; 網絡= $ ClusterNetworkName; EnableDHCP時= 0 } ＃ 若是 您 正在 使用 的Windows 服務器 2008 R2 使用 此：#cluster RES $ IPResourceName / 私法 enable，使能= 0 地址= $ ILBIP probeport = 59999 子網掩碼= 255.255。255.255
若是正確運行，這就是輸出的樣子。

下一步
若是你到了這一點而且仍然沒法遠程鏈接到羣集，那麼你就不會是第一我的。在安全性，負載均衡器，SQL端口等方面，有不少問題可能出錯。我編寫本指南以幫助解決鏈接問題。

事實上，在這個很是安裝中，我在SQL Server配置管理器中的SQL Server TCP / IP屬性方面遇到了一些奇怪的問題。當我查看屬性時，我沒有看到SQL Server羣集IP地址是它正在偵聽的地址之一，因此我不得不手動添加它。我不肯定這是否是異常，但在我從遠程客戶端鏈接到集羣以前，這確定是我必須解決的問題。

正如我以前提到的，您能夠對此安裝進行的另外一項改進是爲TempDB 使用DataKeeper非鏡像卷資源。若是你設置了它，請注意人們常常遇到的如下兩個配置問題。

第一個問題是若是將tempdb移動到第一個節點上的文件夾，則必須確保在第二個節點上建立徹底相同的文件夾結構。若是在嘗試進行故障轉移時不這樣作，SQL Server將沒法聯機，由於它沒法建立TempDB

第二個問題發生在建立集羣后，將其餘DataKeeper卷資源添加到SQL集羣的任什麼時候候。您必須進入SQL Server羣集資源的屬性，並使其依賴於您添加的新DataKeeper Volume資源。對於TempDB卷和您在建立集羣后可能決定添加的任何其餘卷都是如此。

若是您對此配置或任何其餘羣集配置有任何疑問，請隨時與我聯繫或在下面發表評論。