SIOS SANless clusters High-availability Machine Learning monitoring
2016年6月21日 – 更新。自從我發布這篇文章以來，一位可靠的消息來源告訴我，有一個更新的PowerShell腳本可以更可靠地更改現有Azure VM的可用性集。我還沒有嘗試過。但我相信來源和Microsoft Premiere Support指導他閱讀本文。https://gallery.technet.microsoft.com/Azure-RM-Availability-Set-39e19d01我有點驚訝地發現，在創建虛擬機後，更改VM所在的可用性集並不容易。Azure門戶沒有將現有VM添加到可用性集的機制。幸運的是，我偶然發現了這個巨大的資源。設置Azure資源管理器VM可用性集通過利用該文章中可供下載的PowerShell腳本，我能夠將兩個現有VM添加到我創建的內容中。最後，我可以更改現有Azure VM的可用性集 – 真正的救命！
在本文中，我們將詳細介紹在Azure Resource Manager中部署SQL Server故障轉移群集所需的特定步驟。我將假設您熟悉基本的Azure概念以及基本的SQL Server故障轉移群集概念。使用Azure資源管理器在Azure的單個區域中部署雙節點SQL Server故障轉移群集並不是一門火箭科學。我將在本文中關注的是在Azure Resource Manager中部署SQL Server故障轉移群集的獨特性。如果您仍在使用Azure Classic並且需要在Classic中部署SQL Server故障轉移群集，請閱讀我的文章“STEP-BY-STEP：如何在MICROSOFT AZURE IAAS中配置SQL SERVER FAILOVER群集實例（FCI）#SQLSERVER #AZURE＃ SANLESS“在開始之前，讓我們熟悉Azure虛擬機中SQL Server的Windows Azure文章，高可用性和災難恢復。在該文章中概述了所有HA選項。這包括AlwaysOn AG，數據庫鏡像，日誌傳送，備份和還原以及最終故障轉移群集實例。假設由於與SQL Server企業版相關的成本或缺乏功能而忽略了其他選項，我們將重點關注最終選項 – SQL Server AlwaysOn故障轉移群集實例（FCI）。當您閱讀該文章時，很明顯Azure中缺少群集感知共享存儲是部署SQL Server故障轉移群集的障礙。但是，該文章中描述了一些替代方案。我們將專注於使用SIOS DataKeeper，以提供要在群集中使用的存儲。圖1 Microsoft對SQL Server故障轉移群集的支持策略https://azure.microsoft.com/en-us/documentation/articles/virtual-machines– windows-classic-sql-dr / [/ caption]使用DataKeeper Cluster Edition，您可以獲取本地連接的存儲，無論是Premium還是標準磁盤，並在兩個磁盤之間同步，異步或混合或同時復制這些磁盤或更多群集節點。此外，DataKeeper Volume資源在Windows Server故障轉移群集中註冊，該資源取代了物理磁盤資源。DataKeeper Volume不是像物理磁盤資源那樣控制SCSI-3保留，而是控製鏡像方向，確保活動節點始終是鏡像源。就SQL Server和故障轉移群集而言，它的外觀，感覺和氣味就像物理磁盤一樣，其使用方式與物理磁盤資源的使用方式相同。
如果您熟悉Azure資源管理器，您就會發現其中一項重要的新功能是能夠使用部署模板快速部署由相互關聯的Azure資源組成的應用程序。其中許多模板都是由Microsoft開發的，並且可以在Github上的社區中以“快速入門模板”的形式獲得。社區成員也可以自由擴展模板或在GitHub上發布自己的模板。SIOS Technology發布的一個名為“帶有SIOS DataKeeper Azure部署模板的SQL Server 2014 AlwaysOn故障轉移群集實例”的模板完全自動化了將2節點SQL Server FCI部署到新的Active Directory域的過程。要部署此模板，只需單擊模板中的“部署到Azure”按鈕即可。圖2-訪問https://github.com/SIOSDataKeeper/SIOSDataKeeper-SQL-Cluster以快速配置雙節點SQL群集[/ caption]
雖然自動Azure部署模板是一種快速簡便的方法，可以快速獲得雙節點SQL Server FCI，但存在一些限制。首先，它使用SQL Server的180天評估版本，因此除非升級SQL eval許可證，否則不能在生產中使用它。此外，它構建了一個全新的AD域，因此如果要與現有域集成，則必須手動構建它。要在Azure中構建一個雙節點SQL Server故障轉移群集實例，我們假設您有一個基於Azure資源管理器（而不是Azure Classic）的基本虛擬網絡，並且您至少有一個虛擬機已啟動並運行並配置為域控制器。配置虛擬網絡和域後，您將配置兩個新虛擬機，它們將充當群集中的兩個節點。我們的環境將如下所示：DC1 – 我們的域控制器和文件共享見證SQL1和SQL2 – 我們的SQL Server群集的兩個節點
使用Azure門戶，我們將以完全相同的方式配置SQL1和SQL2。有多種選擇可供選擇，包括實例大小，存儲選項等。本指南並不是在Azure中部署SQL Server的詳盡指南，因為有一些非常好的資源，每天都有更多的資源發布。但是，在創建實例時要記住幾個關鍵事項，尤其是在群集環境中。可用性集 – SQL1，SQL2和DC1都位於同一可用性集中非常重要。通過將它們放在相同的可用性集中，我們確保每個群集節點和文件共享見證駐留在不同的故障域和更新域中。這有助於確保在計劃維護和計劃外維護期間，群集將繼續能夠維持法定人數並避免停機。圖3 – 確保將兩個群集節點和文件共享見證添加到同一個可用性集[/ caption]
配置每個VM後，您將需要進入設置並更改設置，以使IP地址為靜態。我們不希望更改群集節點的IP地址。圖4 – 確保每個群集節點都使用靜態IP [/ caption]
就存儲而言，您將需要參考Azure虛擬機中SQL Server的性能最佳實踐。在任何情況下，您至少需要為每個群集節點添加至少一個額外的磁盤。DataKeeper可以使用基本磁盤，高級存儲甚至是存儲池中包含多個磁盤的存儲池。只需確保為每個群集節點添加相同數量的存儲並以相同方式對其進行配置。圖5 – 確保為每個群集節點添加額外的存儲空間[/ caption]
假設已按上述方式配置了兩個群集節點（SQL1和SQL2）並將其添加到現有域中，我們就可以創建群集了。在創建群集之前，需要啟用一些功能。這些功能是.Net Framework 3.5和故障轉移群集。需要在兩個群集節點上啟用這些功能。圖6 – 在兩個群集節點上啟用.Net Framework 3.5和故障轉移群集功能[/ caption]一旦啟用了這些功能，您就可以構建您的集群。我要向您展示的大多數步驟都可以通過PowerShell和GUI執行。但是，我將建議您在第一步中使用PowerShell創建群集。如果您選擇使用故障轉移群集管理器GUI來創建群集，您會發現群集正在發出重複的IP地址。在不詳細介紹的情況下，您會發現Azure VM必須使用DHCP。通過在Azure門戶中創建VM時指定“靜態IP”，我們所做的就是創建一種DHCP預留。它不完全是DHCP保留，因為真正的DHCP保留會從DHCP池中刪除該IP地址。相反，在Azure門戶中指定靜態IP只是意味著如果在VM請求它時該IP地址仍然可用，Azure將向其發出該IP。但是，如果您的VM處於脫機狀態且另一台主機在同一子網中聯機，則可能會發出相同的IP地址。Azure實施DHCP的方式還有另一個奇怪的副作用。在主機使用DHCP（必須使用DHCP）時使用Windows Server Failover Cluster GUI創建群集時，無法指定群集IP地址。相反，它依靠DHCP來獲取地址。奇怪的是，DHCP將發出重複的IP地址，通常與請求新IP地址的主機具有相同的IP地址。群集通常會完成，但您可能會遇到一些奇怪的錯誤，您可能需要從其他節點運行Windows Server Failover Cluster GUI才能運行它。一旦運行它，您將需要將群集IP地址更改為網絡上當前未使用的地址。只需通過Powershell創建集群並指定集群IP地址作為PowerShell命令的一部分來創建集群，就可以避免這種混亂。您可以使用New-Cluster命令創建集群，如下所示：
New-Cluster -Name cluster1 -Node sql1，sql2 -StaticAddress 10.0.0.101 -NoStorage
群集創建完成後，您還需要運行以下命令來運行群集驗證：
測試群集
圖7 – 集群創建的輸出和集群驗證命令[/ caption]
由於沒有共享存儲，因此您需要在與兩個群集節點相同的可用性集中的另一台服務器上創建文件共享見證。通過將其置於相同的可用性集中，您可以確保在任何給定時間僅從您的法定人數中失去一票。如果您不確定如何創建文件共享見證，可以查看本文http://www.howtonetworking.com/server/cluster12.htm。在我的演示中，我將文件共享見證放在域控制器上。我已經在https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-上發布了對群集仲裁的詳盡解釋。在窗口服務器-2012-R2 /在
創建集群後，就可以安裝DataKeeper了。在創建初始群集後安裝DataKeeper非常重要，這樣可以向群集註冊自定義群集資源類型。如果在創建群集之前安裝了DataKeeper，則只需再次運行安裝並執行修復安裝。圖8 – 創建集群後安裝DataKeeper [/ caption]在安裝過程中，您可以使用所有默認選項。 您使用的服務帳戶必須是域帳戶，並且位於群集中每個節點上的本地管理員組中。圖9 – 服務帳戶必須是每個節點上Local Admins組中的域帳戶[/ caption]一旦安裝DataKeeper並獲得許可您將需要重新啟動服務器的每個節點。
要創建DataKeeper Volume Resource，您需要啟動DataKeeper UI並連接到這兩個服務器。
連接到SQ
L1連接到S
QL2連接到每個服務器後，您就可以創建DataKeeper捲了。右鍵單擊Jobs並選擇“Creat
e Job”為作業命名和描述。
選擇源服務器，IP和卷。IP地址是複制流量是否會傳播。
選擇目標服務器。
選擇你的選擇。對於兩個VM位於同一地理區域的目的，我們將選擇同步複製。對於更長距離的複制，您將需要使用異步並啟用一些壓縮。
通過在上次彈出窗口中單擊“是”，您將在故障轉移群集中的可用存儲中註冊新的DataKeeper卷資源。
您將在可用存儲中看到新的DataKeeper卷資源。
您現在可以安裝第一個節點了。群集安裝將像您構建的任何其他SQL群集一樣繼續。我沒有復制每一個屏幕截圖，只是為了引導你一路走來。
您會看到DataKeeper Volume Resource被識別為可用磁盤資源，就像它是共享磁盤一樣。
記下您在此處選擇的IP地址。它必須是網絡上唯一的IP地址。我們稍後在創建內部負載均衡器時將使用相同的IP地址。
第一個節點成功安裝後，您將使用“將節點添加到SQL Server故障轉移群集”選項在第二個節點上開始安裝。再一次，安裝非常簡單，只需使用標準的最佳實踐，就像使用任何其他SQL群集安裝一樣。
以下是Azure中的故障轉移群集與傳統基礎結構的不同之處。Azure網絡堆棧不支持免費ARPS，因此客戶端無法直接連接到群集IP地址。相反，客戶端連接到內部負載平衡器並重定向到活動群集節點。我們需要做的是創建一個內部負載均衡器。這可以通過Azure門戶完成，如下所示。首先，創建一個新的Load Ba
lancer如果您的客戶端通過公共Internet連接，您可以使用公共負載均衡器。但假設您的客戶端位於同一個vNet中，我們將創建一個內部負載均衡器。需要注意的重要一點是，虛擬網絡與群集節點所在的網絡相同。此外，您指定的專用IP地址將與用於創建SQL群集資源的地址完全相同。
創建內部負載均衡器（ILB）後，您需要對其進行編輯。我們要做的第一件事就是添加一個後端池。通過此過程，您將選擇SQL Cluster VM所在的可用性集。但是，當您選擇要添加到後端池的實際VM時，請確保不要選擇文件共享見證。我們不希望將SQL流量重定向到您的文件共享見證。
接下來我們要做的就是添加一個Probe。我們添加的探針將探測端口59999。此探針確定群集中哪個節點處於活動狀態。
最後，我們需要一個負載平衡規則來重定向SQL Server流量。在我們的示例中，我們使用了一個使用端口1433的SQL默認實例。您可能還希望根據應用程序要求添加1434或其他規則。在下面的屏幕截圖中需要注意的重要事項是直接服務器返回已啟用。確保你做出改變。
在Azure資源管理器中部署SQL Server故障轉移群集的最後一步。 在其中一個群集節點上運行以下PowerShell腳本。這將允許群集IP地址響應ILB探測並確保群集IP地址和ILB之間不存在IP地址衝突。請注意;您需要編輯此腳本以適合您的環境。子網掩碼設置為255.255.255.255，這不是錯誤，保持原樣。這將創建一個特定於主機的路由，以避免與ILB發生IP地址衝突。
＃定義變量
$ ClusterNetworkName =“”
＃群集網絡名稱
（在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名稱）
$ IPResourceName =“”
#IP地址資源名稱
$ ILBIP =“”
＃內部負載均衡器的IP地址（ILB）
導入模塊FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName | SET-ClusterParameter
-Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“255.255.255.255”;
網絡= $ ClusterNetworkName; EnableDHCP時= 0}
＃如果您使用的是Windows Server 2008 R2，請使用以下命令：
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999
子網掩碼= 255.255.255.255
您現在應該具有正常運行的SQL Server故障轉移群集實例。面臨在Azure資源管理器中部署SQL Server故障轉移群集的問題？在Twitter @daveberm上聯繫我，我很樂意提供幫助。如果您需要DataKeeper評估密鑰，請填寫http://us.sios.com/clustersyourway/cta/14-day-trial上的表格，SIOS將發送一封發送給您的評估密鑰。
對於那些仍然不時使用IE 11的人，您可能已經註意到，在最近的更新中，您的默認搜索提供程序可能已更改為Bing。如果您想了解如何將Internet Explorer 11從Bing更改為Google，請繼續閱讀。微軟已經進行了安全性增強。它希望通過更改默認搜索引擎和主頁來阻止惡意軟件劫持瀏覽器。我是兩個十幾歲的“遊戲玩家”的父親，他們總是處於下載最新惡意軟件的邊緣。因此，雖然我很欣賞增加的安全性，但仍有一點點擔心。此安全更新的一個“好處”是默認搜索提供程序現在是Bing。將其切換回Google並不像1-2-3那麼容易。Microsoft在其文章中發布了有關如何將Bing Explorer 11從Bing更改為Google的步驟：http：//windows.microsoft.com/en-us/windows-10/internet-explorer-11-settings-protection不要請記住我 我喜歡微軟的產品。但不幸的是，Bing對我所做的搜索類型並不友好，因為它通常會尋找一些非常具體的技術內容。我認為Bing可能對消費者友好。然而，谷歌在給我答案的過程中贏得了搜索引擎大戰
要將Internet Explorer 11從Bing更改為Google，請按照本文中的這些步驟操作。下面的屏幕截圖顯示了步驟。
今天，我學到了一些新東西 – Azure門戶GUI上的不同名稱。我試圖幫助客戶在Azure Classic中部署一些具有兩個NIC卡的VM。沒問題我說，自從我使用Azure Classic以來已經有一段時間了。 我記得這很簡單，雖然它必須通過PowerShell完成，因為門戶網站中沒有用於部署兩個NIC的GUI選項。基本方向可以在這裡找到。https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-multiple-nics/然而，在我的頭撞牆幾個小時之後，我偶然發現了這個信息。https://thelonedba.wordpress.com/2015/07/17/new-azurevm-badrequest-the-virtual-network-foo-does-not-exist
看起來Azure門戶GUI關於虛擬網絡名稱的說法有時可能與運行Get-AzureVMNetSite時返回的實際名稱完全不同。選擇名稱。從本質上講，Azure門戶GUI上有一個不同的名稱。為什麼會這樣呢？請參閱下面的屏幕截圖。我創建的名為“Public-Azure-East”的虛擬網絡實際上稱為“Group Group Azure Public East”。如何發生這種情況以及為什麼Azure門戶GUI上有不同的名稱是我無法理解的。如您所見，我在創建虛擬機時的微弱嘗試失敗了。它說“BadRequest：虛擬網絡Public-Azure-East不存在。”我確信它與我使用的多個訂閱有關。但事實證明，這是一個在Azure門戶GUI上顯示不同名稱的錯誤。
為什麼像創建具有兩個NIC的VM這樣簡單的事情無法通過GUI實現完全是另一個故事。經Clusteringformeremortals.com許可轉載
使用SIOS DataKeeper Cluster Edition可以對SQL Server Standard Edition進行災難恢復。就是這樣。由於SQL Server Enterprise Edition的成本，許多人發現自己已經開始使用SQL Server Standard Edition。SQL Server標準版具有許多相同的功能，但它有一些限制。一個限制是它不支持AlwaysOn可用性組。此外，它僅支持群集中的兩個節點。由於數據庫鏡像已被棄用且僅支持標準版中的同步複製，因此您實際上具有有限的災難恢復選項。
其中一個選項是SIOS DataKeeper Cluster Edition。DataKeeper將與您現有的共享存儲群集配合使用。該軟件允許您使用同步或異步複製將其擴展到第3個節點。如果您使用的是SQL Server Enterprise，只需將該第3個節點添加為真正的多站點群集的另一個群集成員即可。但是，由於我們討論的是SQL Server Standard Edition，因此無法將第3個節點直接添加到群集中。好消息是DataKeeper將允許您將數據複製到第三個節點，以便您的數據受到保護。SQL Server Standard Edition的災難恢復意味著您將使用DataKeeper將第3個節點作為鏡像源聯機。接下來，使用SQL Server Management Studio裝載複製卷上的數據庫。您的客戶還需要重定向到第3個節點。但它是一種非常具有成本效益的解決方案，具有出色的RPO和合理的RTO。SIOS文檔討論瞭如何為SQL Server Standard Edition執行災難恢復。在這裡，我總結了一些客戶最近的步驟。
上述步驟假設您在所有三台服務器（PRIMARY，SECONDARY，DR）上安裝了SIOS DataKeeper Cluster Edition。PRIMARY和SECONDARY是一個雙節點共享存儲集群。您正在將數據複製到DR，這只是一個獨立的SQL Server實例（不是群集的一部分），只有本地附加存儲。災難恢復服務器將具有與共享群集卷大小和驅動器號相同的捲。這項工作相當不錯，如果您沒有配置自己的災難恢復站點，甚至可以讓您複製到雲中的目標。如果要完全消除SAN，還可以使用所有復制存儲構建相同的配置。這是一個很好的短視頻，演示了SQL Server Standard Edition的災難恢復的一些可能配置。 http://videos.us.sios.com/medias/aula05u2fl經Clusteringformeremortals.com許可轉載