SIOS SANless clusters High-availability Machine Learning monitoring
您是否知道在沒有原始設備映射（RDM）麻煩的情況下，您可以在VMware環境中為SQL提供高可用性（HA）保護？在VMware環境中創建共享存儲集群意味著使用RDM進行複雜的實施 – 並放棄重要的VMware功能，例如Vmotion。在本次網絡研討會中，SIOS集群專家Tony Tomarchio演示了在VMware環境中創建故障轉移群集的簡便方法，而沒有原始設備映射的複雜性或功能限制。通過SIOS了解有關VMWare高可用性的更多信息。註冊參加網絡研討會：無需原始設備映射的VMware高可用性
在Azure或任何云平台中部署SQL Server？考慮到Azure中的存儲與您可能訪問本地的存儲不完全相同，而不是像您為內部部署多年來那樣配置存儲。一些傳統的“最佳實踐”可能會花費你額外的錢，並給你不到最佳的性能。然而，一直沒有為您提供任何預期的好處。我將要討論的大部分內容也在SQL Server虛擬機中的Azure性能指南中進行了描述。
我不是要告訴您必須使用UltraSSD，Premium Storage或任何其他磁盤類型。您只需要知道您有選項，以及每種磁盤類型為錶帶來的內容。當然，就像雲中的其他任何東西一樣，您花費的錢越多，您將獲得的功率，速度，吞吐量等就越多。訣竅是找到適合您存儲考慮因素的最佳配置，這樣您就可以花費足夠的時間來達到預期的效果。
像雲中的許多東西一樣，某些規格是捆綁在一起的。對於服務器，如果你想要更多的RAM，你經常會獲得更多的CPU，即使你不需要更多的CPU。對於存儲，IOPS，吞吐量和大小都捆綁在一起。如果您想要更多IOPS，則需要更大的磁盤。如果您需要更多空間，您還可以獲得更多IOPS。當然，您可以在存儲類之間跳轉以在某種程度上規避這一點，但是如果您需要更多IOPS，您仍然可以在任何不同的存儲類型上獲得更多空間。虛擬機實例的大小也很重要。無論您最終使用哪種存儲配置，總體吞吐量都將限制在實例大小允許的範圍內。因此，再次，您可能需要支付比您需要的更多的RAM和CPU，只是為了實現您期望的存儲性能。確保您了解實例大小可以支持的最大IOPS和MBps吞吐量。很多時候，實例大小將成為Azure中感知存儲性能問題的瓶頸。
RAID 0傳統上是存儲配置選項的第三軌。雖然它提供了任何RAID選項的性能和存儲利用率的最佳組合，但它存在災難性故障的風險。當RAID 0條帶集中的單個磁盤發生故障時，整個條帶集將失敗。因此，傳統上RAID 0僅用於數據丟失可接受且需要高性能的情況。但是，在Azure軟件中，RAID 0是可取的，甚至在許多情況下也是推薦的。我們如何在Azure中使用RAID 0？答案很簡單。您呈現給Azure虛擬機實例的每個磁盤已在後端具有三重冗餘。這意味著在丟失條帶集之前需要多次失敗。通過使用RAID 0，您可以組合多個磁盤。對於添加到條帶集的每個附加磁盤，組合條帶集的整體性能將增加100％。因此，例如，您需要10,000 IOPS，您可能認為您需要UltraSSD，因為高級存儲使用P50最高可達7,500 IOPS。但是，通過將兩個P50放入RAID 0，您現在可以實現高達15,000 IOPS。假設您正在運行Standard_F16s_v2或類似的大型實例大小，支持那麼多IOPS。在Windows 2012及更高版本中，RAID 0是通過創建簡單存儲空間來實現的。在Windows Server 2008 R2中，您可以使用動態磁盤創建RAID 0條帶捲。只是提醒一句。如果您要使用本地存儲空間並使用DataKeeper配置可用性組或SANless故障轉移群集實例，則最好在創建群集之前配置存儲。 只是提醒。您只有兩個月的時間將SQL Server 2008 R2實例移動到Azure。查看我的帖子，了解如何在Azure上部署SQL Server 2008 R2 FCI以確保高可用性。
傳統上，日誌和數據文件將駐留在不同的物理磁盤上。日誌文件往往具有大量寫入活動，而數據文件往往具有更多讀取活動。因此，有時存儲將基於這些特徵進行優化。還希望將日誌和數據文件保存在不同的磁盤上以用於恢復目的。如果您丟失了一個或另一個，並且有適當的備份策略，您可以恢復數據庫而不會丟失數據。使用基於雲的存儲，只丟失一個卷的可能性非常低。現在您正考慮存儲注意事項。如果您偶然丟失了存儲空間，則可能是您的整個存儲群集以及三重冗餘都要去吃午餐。因此，雖然將日誌放入E： logs和F： data中的數據可能是正確的，但您確實在做自己的損害。例如，您為日誌配置了P20，為數據配置了P20。每個卷的大小為512 GiB，上限為2,300 IOPS。試想一下，你可能不需要那麼大的日誌文件。但它可能不會為您的數據文件增長留出太多空間。它最終需要轉移到更昂貴的P30，只是為了額外的空間。簡單地將這兩個卷組合成一個支持4,600 IOPS的漂亮的大1 TB卷不是更好嗎？通過這樣做，日誌和數據文件都可以利用增加的IOPS。而且，您還可以通過推遲數據文件的P30磁盤來優化存儲利用率並降低雲存儲成本。這同樣適用於真正的文件和文件組。真的很想你在做什麼。一旦你搬到雲端，它是否仍然有意義。 有意義的事情可能與你過去所做的事情相違背。如有疑問，請遵循KISS規則，Keep It Simple Stupid！雲的美妙之處在於您可以隨時添加更多存儲空間，增加實例大小，或者盡一切可能優化性能與成本。
使用本地SSD，也稱為D：驅動器。D驅動器將成為tempdb的最佳位置。 因為它是本地驅動器，所以數據被認為是“臨時的”。這意味著如果移動，重新啟動服務器等，它可能會丟失。沒關係。每次SQL啟動時都會重新創建Tempdb。本地SSD將很快並且具有低延遲。但是因為它是本地的，所以對它的讀取和寫入不會影響實例大小的總體存儲IOPS限制。所以有效它是免費的IOPS！為什麼不利用？如果要使用SIOS DataKeeper構建SANless SQL Server FCI，請確保創建D驅動器的非鏡像卷資源。這樣您就不必不必要地複制TempDB。
當在同一Windows群集上安裝多個SQL Server實例時，掛載點通常用於SQL Server FCI配置中。這降低了SQL Server許可證的總體成本。它可以通過提高服務器利用率來幫助節省成本。正如我們過去所討論的，通常可能有五個或更多驅動器與每個SQL Server實例相關聯。如果每個驅動器都必須使用驅動器號，那麼在大約三到四個實例中就會用完字母。因此，不是給每個驅動器一個字母，而是使用掛載點，以便每個實例只能由一個驅動器號（根驅動器）提供服務。根驅動器具有映射到沒有驅動器號的單獨物理磁盤的安裝點。但是，正如我們上面所討論的，使用一堆單獨磁盤的概念在雲中確實沒有多大意義。因此，掛載點在雲中變得過時。相反，我們如上所述創建RAID 0條帶。每個群集實例SQL Server都將擁有自己獨立的捲，該卷針對空間，性能和成本進行了優化。這解決了驅動器號耗盡的問題。此外，還可以提高存儲利用率和性能，同時還可以降低雲存儲的成本。
這篇文章是一個跳躍點，而不是權威指南。這篇文章的主要內容是讓您對雲和存儲注意事項有不同的看法，因為它與在Azure中運行SQL Server有關。不要簡單地採用您在本地進行的操作並在雲中重新創建它。這幾乎總會導致不太理想的性能和比必要的更大的存儲費用。經Clusteringformeremortals.com許可轉載
2019年7月9日，對SQL Server 2008和2008 R2的支持將結束。這意味著定期安全更新的結束。但是，如果將這些SQL Server實例移動到Azure，Microsoft將為您提供三年的擴展安全更新，無需額外費用。如果您當前正在運行SQL Server 2008/2008 R2並且在7月9日截止日期之前無法更新到SQL Server的更高版本，那麼您將希望利用此優惠而不是冒著面臨未來安全漏洞的風險。未修補的SQL Server實例可能導致數據丟失，停機或破壞性數據洩露。
在Azure中運行SQL Server 2008/2008 R2時將面臨的挑戰之一是確保高可用性。在本地，您可能正在運行SQL Server故障轉移群集（FCI）實例以實現高可用性，或者您可能正在虛擬機中運行SQL Server，並且依賴VMware HA或Hyper-V群集來獲取可用性。遷移到Azure時，這些選項都不可用。 Azure中的停機是非常可能的，您必須採取措施來緩解。
為了減少停機的可能性並獲得Azure 99.95％或99.99％SLA的資格，您必須利用SIOS DataKeeper。DataKeeper克服了Azure缺乏共享存儲的問題，並允許您在Azure中構建SQL Server FCI，利用每個實例上的本地連接存儲。SIOS DataKeeper不僅支持本指南中記錄的SQL Server 2008 R2和Windows Server 2008 R2，它支持從2008 R2到Windows Server 2019的任何版本的Windows Server以及從SQL Server 2008到SQL Server 2019的任何版本的SQL Server 。
本指南將介紹在Azure中創建在Windows Server 2008 R2上運行的雙節點SQL Server 2008 R2故障轉移群集實例（FCI）的過程。儘管SIOS DataKeeper還支持跨可用區或區域的群集，但本指南假設每個節點都位於同一個Azure區域，但位於不同的故障域中。將使用SIOS DataKeeper代替創建SQL Server 2008 R2 FCI通常所需的共享存儲。
本指南將利用Azure Marketplace中發布的Windows Server 2008R2映像上的SQL Server 2008R2SP3。
配置第一個實例時，您必須創建新的可用性集。在此過程中，請確保將Fault Domains的數量增加到3。這允許兩個群集節點和文件共享見證每個節點駐留在它們自己的故障域中。
為每個實例添加其他磁盤。建議使用Premium或Ultra SSD。禁用用於SQL日誌文件的磁盤上的緩存。在用於SQL數據文件的磁盤上啟用只讀緩存。有關存儲最佳實踐的其他信息，請參閱Azure虛擬機中的SQL Server性能指南。
如果尚未配置虛擬網絡，請允許創建嚮導為您創建新虛擬網絡。
創建實例後，請進入IP配置並使專用IP地址靜態。這是SIOS DataKeeper所必需的，也是群集實例的最佳實踐。
確保將虛擬網絡配置為將DNS服務器設置為本地Windows AD控制器。這是為了確保您能夠在以後的步驟中加入域。
按照上面的相同步驟。除了確保將此實例放在您使用第一個實例創建的同一虛擬網絡和可用性集中。
為了使Windows Server故障轉移群集（WSFC）以最佳方式工作，您需要創建另一個Windows Server實例並將其放在與SQL Server實例相同的可用性集中。通過將其置於同一可用性集中，可確保每個群集節點和FSW位於不同的故障域中。因此，如果整個故障域脫機，確保您的群集保持在線。此實例不需要SQL Server。它可以是一個簡單的Windows Server，因為它需要做的就是託管一個簡單的文件共享。
此實例將託管WSFC所需的文件共享見證。此實例不需要具有相同的大小，也不需要附加任何其他磁盤。它的唯一目的是託管一個簡單的文件共享。它實際上可以用於其他目的。在我的實驗室環境中，我的FSW也是我的域控制器。
配置的兩個SQL Server實例中的每一個都已經安裝了SQL Server 2008 R2。但是，它們作為獨立的SQL Server實例安裝，而不是群集實例。在我們安裝集群實例之前，必須從每個實例中卸載SQL Server。最簡單的方法是運行SQL安裝程序，如下所示。
運行setup.exe / Action-RunDiscovery時，您將看到所有預安裝的內容
setup.exe / Action-RunDiscovery
運行setup.exe / Action =卸載/ FEATURES = SQL，AS，RS，IS，工具/ INSTANCENAME = MSSQLSERVER啟動卸載過程
setup.exe / Action = Uninstall / FEATURES = SQL，AS，RS，IS，Tools / INSTANCENAME = MSSQLSERVER
運行setup.exe / Action-RunDiscovery確認卸載已完成
setup.exe / Action-RunDiscovery
在第二個實例上再次運行此卸載過程。
所有這三個實例都需要添加到Windows域中。
需要將故障轉移群集功能添加到兩個SQL Server實例中
Add-WindowsFeature故障轉移 - 群集
為簡單起見，請在安裝和配置SQL Server FCI期間關閉Windows防火牆。有關保護Azure資源的建議，請參閱Azure網絡安全最佳實踐。可以在此處找到所需Windows端口的詳細信息，此處的SQL Server端口和此處的SIOS DataKeeper端口，我們稍後將配置的內部負載均衡器還需要端口59999訪問。因此，請務必在安全配置中考慮到這一點。
NetSh Advfirewall設置allprofiles狀態
為了在Azure中配置Windows Server 2008 R2實例，需要進行關鍵更新（kb2854082）。該更新以及更多內容包含在Windows Server 2008 R2 SP1的便捷匯總更新中。在每個SQL Server實例上安裝此更新。
配置兩個SQL Server實例時附加的其他磁盤需要格式化。對每個實例上的每個卷執行以下操作。
微軟最佳實踐說如下……
“NTFS分配單元大小：格式化數據磁盤時，建議您對數據和日誌文件以及TempDB使用64 KB的分配單元大小。”
運行集群驗證以確保一切準備好進行集群。
您的報告將包含有關存儲和網絡的警告。您可以忽略這些警告，因為我們知道沒有共享磁盤，並且服務器之間只存在單個網絡連接。您可能還會收到有關網絡綁定順序的警告，該警告也可以忽略。如果您遇到任何錯誤，您必須在繼續之前解決這些錯誤。
在Azure中創建集群的最佳實踐是使用Powershell，如下所示。Powershell允許我們指定靜態IP地址，而GUI方法則不允許。不幸的是，Azure的DHCP實現與Windows Server Failover Clustering不兼容。如果您使用GUI方法，您將使用重複的IP地址作為群集IP地址。這不是世界末日，但你需要在我展示時解決這個問題。
正如我所說，Powershell方法通常效果最好。但是，出於某種原因，它似乎在Windows Server 2008 R2上失敗，如下所示。
New-Cluster -Name cluster1 -Node sql1，sql2 -StaticAddress 10.1.0.100 -NoStorage
您可以嘗試這種方法，如果它適合您 – 太棒了！我需要回過頭來再研究一下，看看它是不是僥倖。如果Powershell不工作，我需要探索的另一個選項是Cluster.exe。運行cluster / create /？使用不推薦使用的cluster.exe命令提供用於創建集群的正確語法。
但是，如果Powershell或Cluster.exe使您失敗，則以下步驟說明瞭如何通過Windows Server Failover Clustering UI創建群集，包括修復將分配給群集的重複IP地址。
請記住，您在此處指定的名稱只是群集名稱對象（CNO）。這不是SQL客戶端用於連接群集的名稱;我們將在稍後的步驟中定義SQL Server群集設置期間。
此時，已創建群集，但由於重複的IP地址問題，您可能無法使用Windows Server Failover Clustering UI連接到群集。
如前所述，如果使用GUI創建集群，則無法為集群選擇IP地址。由於您的實例配置為使用DHCP（Azure中需要），因此GUI希望使用DHCP自動為您分配IP地址。遺憾的是，Azure的DHCP實現無法按預期工作，並且群集將分配其中一個節點已使用的相同地址。雖然群集將正確創建，但在解決此問題之前，您將很難連接到群集。
要解決此問題，請從其中一個節點運行以下命令，以確保在該節點上啟動群集服務。
淨啟動clussvc / fq
在同一節點上，您現在應該能夠連接到Windows Server Failover Clustering UI，在那裡您將看到IP地址無法聯機。
打開群集IP地址的屬性並將其從DHCP更改為靜態，並為其分配未使用的IP地址。
將Name資源聯機
接下來我們需要添加文件共享見證。在我們配置為FSW的第三台服務器上，創建一個文件夾並共享它，如下所示。您需要在共享和安全級別授予群集名稱對象（CNO）讀/寫權限，如下所示。
創建共享後，在其中一個群集節點上運行“配置群集仲裁”嚮導，然後按照以下步驟操作。
我們幾乎準備好安裝DataKeeper。但是，在我們這樣做之前，您需要創建一個Domain帳戶並將其添加到每個SQL Server群集實例上的Local Administrators組。我們將在安裝DataKeeper時指定此帳戶。
在兩個SQL Server群集節點中的每個節點上安裝DataKeeper，如下所示。
這是我們將指定我們添加到每個本地域管理員組的域帳戶的位置。
在兩個群集節點中的每個節點上安裝DataKeeper後，即可配置DataKeeper。
注 – 以下步驟中遇到的最常見錯誤與安全性相關，通常由預先存在的Azure安全組阻止所需端口。請參閱SIOS文檔以確保服務器可以通過所需的端口進行通信。
首先，您必須連接到兩個節點中的每一個。
如果一切配置正確，您應該在“服務器概述”報告中看到以下內容。
接下來，創建一個新工作並按照下面說明的步驟
在此處選擇“是”以在“可用存儲”中註冊DataKeeper卷資源
為每個卷完成上述步驟。完成後，您應該在Windows Server故障轉移群集UI中看到以下內容。
您現在已準備好將SQL Server安裝到群集中。
注 – 此時，只能在當前託管可用存儲的節點上訪問複製卷。這是預期的，所以不要擔心！
在第一個節點上，運行SQL Server安裝程序。
選擇“新建SQL Server故障轉移群集安裝”，然後按照說明執行操作。
只選擇您需要的選項。
請注意，本文檔假定您使用的是SQL Server的默認實例。如果使用命名實例，則需要確保鎖定其偵聽的端口，並在配置負載平衡器時使用該端口。您還需要為SQL Server Browser服務（UDP 1434）創建負載平衡器規則，以便連接到命名實例。本指南不涉及這兩個要求。但是，如果您需要命名實例，那麼如果您執行這兩個額外步驟，它將起作用。
在這裡，您需要指定一個未使用的IP地址
轉到“數據目錄”選項卡並重定位數據和日誌文件。在本指南的最後，我們將討論將tempdb重定位到非鏡像DataKeeper卷以獲得最佳性能。現在，只需將其保留在其中一個群集磁盤上即可。
在第二個節點上再次運行SQL Server安裝程序。然後，選擇“將節點添加到SQL Server故障轉移群集”。
恭喜你，差不多完成了！但是，由於Azure缺乏對免費ARP的支持，我們需要配置內部負載均衡器（ILB）以協助客戶端重定向，如以下步驟所示。
為了使ILB正常運行，必須從其中一個集群節點運行以下命令。SQL Cluster IP使SQL Cluster IP地址能夠響應ILB運行狀況探測，同時還將子網掩碼設置為255.255.255.255，以避免IP地址與運行狀況探測衝突。
cluster res <IPResourceName> / priv enabledhcp = 0 address = <ILBIP> probeport = 59999 subnetmask = 255.255.255.255
注意 – 我不知道它是不是僥倖。有時候我運行了這個命令，它看起來很有效，但它沒有完成工作，我必須重新開始。我可以判斷它是否有效的方法是查看SQL Server IP資源的子網掩碼。如果它不是255.255.255.255那麼你知道它沒有成功運行。 它可能只是一個GUI刷新問題。請嘗試重新啟動群集GUI以驗證子網掩碼是否已更新。
成功運行後，使資源脫機並將其重新聯機以使更改生效。
最後一步是創建負載均衡器。在這種情況下，我們假設您正在運行SQL Server的默認實例，偵聽端口1433。
創建負載均衡器時定義的專用IP地址將與SQL Server FCI使用的地址完全相同。
僅將兩個SQL Server實例添加到後端池。不要將FSW添加到後端池。
在此負載平衡規則中，您必須啟用浮動IP。
最簡單的測試是在被動節點上打開SQL Server Management Studio並連接到群集。恭喜！你連接時你做的一切都正確！如果你無法連接，不要害怕。我寫了一篇博客文章來幫助解決問題。管理群集與管理傳統共享存儲群集完全相同。一切都通過故障轉移群集管理器控制。
為獲得最佳性能，建議將tempdb移至本地非複制SSD。但是，SQL Server 2008 R2要求tempdb位於群集磁盤上。SIOS有一個稱為非鏡像卷資源的解決方案，可以解決這個問題。建議創建本地SSD驅動器的非鏡像卷資源並在那裡移動tempdb。請注意，本地SSD驅動器是非持久性的。您必須注意確保每次服務器重新啟動時都會重新創建包含tempdb的文件夾和該文件夾的權限。
在創建本地SSD的非鏡像卷資源後，請按照本文中的步驟重新定位tempdb。必須將該文章中描述的啟動腳本添加到每個群集節點。
經Clusteringformeremortals.com許可轉載
在今年9月的Microsoft Ignite上，微軟圍繞Azure發布了一些聲明。其中一個公告是內部負載平衡器上的多個VIP的普遍可用性。為什麼這對SQL Server DBA如此重要？好吧，到目前為止，如果要在Azure中部署高可用性SQL Server，則每個群集或單個可用性組偵聽器僅限於一個SQL Server FCI。此限制強制您為要在故障轉移群集中保護的每個SQL Server實例部署新群集。如果您希望在AlwaysOn AG配置中進行自動故障轉移和客戶端重定向，它還會強制您將所有數據庫分組到單個可用性組中。
這些新的ILB功能現已解除了這些限制。在這篇文章中，我將引導您完成在Azure中部署包含兩個SQL Server實例的SQL Server FCI的過程。在以後的文章中，我將引導您完成SQL Server AlwaysOn AG的相同過程。
如我在Azure資源管理器中部署Microsoft SQL Server 2014故障轉移群集的帖子中所述，在Azure中構建基本的單實例SQL Server FCI。該帖子描述了創建多實例SQL Server故障轉移群集的過程。 使用DataKeeper創建群集中使用的複製卷資源，嘗試創建內部負載平衡器（ILB），然後修復SQL Server群集IP資源以使用ILB。如果您想跳過該過程并快速啟動配置，您可以始終使用Azure部署模板，使用SIOS DataKeeper創建雙節點SQL Server FCI假設您現在有一個基本的雙節點SQL Server FCI，添加第二個命名的步驟實例如下：
接下來，我們必須調整ILB以將流量重定向到第二個實例。以下是您需要遵循的步驟：添加前端IP地址，該地址與您用於第二個SQL Server實例的SQL群集IP地址相同，如下所示。
接下來，我們將需要添加另一個探測，因為實例可以在不同的服務器上運行。如下圖所示，我添加了一個探測端口59998（而不是通常的59999）的探測器。我們需要確保新規則引用此探針。我們還需要記住該端口號，因為我們需要在此過程的最後一步更新與此實例關聯的IP地址。
現在我們需要向ILB添加兩個新規則來引導目標為第二個SQL實例的流量。當然我們需要添加一個規則來重定向TCP端口1440（我用於SQL命名實例的端口），但由於我們現在使用的是命名實例，我們還需要一個端口來支持SQL Server Browser服務，UDP端口1434。在下面描述SQL Server Browser服務規則的圖片中，請注意前端IP地址引用了新的FrontendIP地址（10.0.0.201），端口和後端端口的UDP端口1434。在池中，您需要指定群集中的兩個服務器，最後確保選擇剛剛創建的新Health Probe。
我們現在將添加TCP / 1440規則。如下圖所示，為端口TCP 1440添加新規則，或為SQL Server的命名實例鎖定的任何端口。同樣，請務必選擇新的FrontEnd IP地址和新的Health Probe（59998）。此外，請確保啟用了浮動IP（直接服務器返回）。
現在已配置負載均衡器，最後一步是運行PowerShell腳本以更新與此第二個SQL Server實例關聯的新群集IP地址。此PowerShell腳本只需要在其中一個群集節點上運行。
＃定義變量
$ ClusterNetworkName =“”
＃群集網絡名稱
（在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名稱）
$ IPResourceName =“”
#SQL Server的第二個實例的IP地址資源名稱
$ ILBIP =“”
＃第二個SQL實例的IP地址，
它應該與新的前端IP地址相同
導入模塊FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName |
Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59998;
子網掩碼=“255.255.255.255”網絡= $ ClusterNetworkName; EnableDHCP時= 0}
＃如果您使用的是Windows Server 2008 R2，請使用以下命令：
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59998
子網掩碼= 255.255.255.255
您現在在Azure中擁有一個功能齊全的多實例SQL Server FCI。如果您有任何問題要構建具有從Clusteringformeremortals.com重現的新Azure ILB功能的多實例SQL Server故障轉移群集
在今年9月的Microsoft Ignite上，微軟圍繞Azure發布了一些聲明。其中一個公告是內部負載平衡器上的多個VIP的普遍可用性。為什麼這對SQL Server DBA如此重要？好吧，到目前為止，如果要在Azure中部署高可用性SQL Server，則每個群集或單個可用性組偵聽器僅限於一個SQL Server FCI。此限制強制您為要在故障轉移群集中保護的每個SQL Server實例部署新群集。如果您希望在AlwaysOn AG配置中進行自動故障轉移和客戶端重定向，它還會強制您將所有數據庫分組到單個可用性組中。
這些新的ILB功能現已解除了這些限制。在這篇文章中，我將引導您完成在Azure中部署包含兩個SQL Server實例的SQL Server FCI的過程。在以後的文章中，我將引導您完成SQL Server AlwaysOn AG的相同過程。
如我在Azure資源管理器中部署Microsoft SQL Server 2014故障轉移群集的帖子中所述，在Azure中構建基本的單實例SQL Server FCI。該帖子描述了創建多實例SQL Server故障轉移群集的過程。 使用DataKeeper創建群集中使用的複製卷資源，嘗試創建內部負載平衡器（ILB），然後修復SQL Server群集IP資源以使用ILB。如果您想跳過該過程并快速啟動配置，您可以始終使用Azure部署模板，使用SIOS DataKeeper創建雙節點SQL Server FCI假設您現在有一個基本的雙節點SQL Server FCI，添加第二個命名的步驟實例如下：
接下來，我們必須調整ILB以將流量重定向到第二個實例。以下是您需要遵循的步驟：添加前端IP地址，該地址與您用於第二個SQL Server實例的SQL群集IP地址相同，如下所示。 接下來，我們將需要添加另一個探測，因為實例可以在不同的服務器上運行。如下圖所示，我添加了一個探測端口59998（而不是通常的59999）的探測器。我們需要確保新規則引用此探針。我們還需要記住該端口號，因為我們需要在此過程的最後一步更新與此實例關聯的IP地址。 現在我們需要向ILB添加兩個新規則來引導目標為第二個SQL實例的流量。當然我們需要添加一個規則來重定向TCP端口1440（我用於SQL命名實例的端口），但由於我們現在使用的是命名實例，我們還需要一個端口來支持SQL Server Browser服務，UDP端口1434。在下面描述SQL Server Browser服務規則的圖片中，請注意前端IP地址引用了新的FrontendIP地址（10.0.0.201），端口和後端端口的UDP端口1434。在池中，您需要指定群集中的兩個服務器，最後確保選擇剛剛創建的新Health Probe。 我們現在將添加TCP / 1440規則。如下圖所示，為端口TCP 1440添加新規則，或為SQL Server的命名實例鎖定的任何端口。同樣，請務必選擇新的FrontEnd IP地址和新的Health Probe（59998）。此外，請確保啟用了浮動IP（直接服務器返回）。
現在已配置負載均衡器，最後一步是運行PowerShell腳本以更新與此第二個SQL Server實例關聯的新群集IP地址。此PowerShell腳本只需要在其中一個群集節點上運行。
＃定義變量
$ ClusterNetworkName =“”
＃群集網絡名稱
（在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名稱）
$ IPResourceName =“”
#SQL Server的第二個實例的IP地址資源名稱
$ ILBIP =“”
＃第二個SQL實例的IP地址，
它應該與新的前端IP地址相同
導入模塊FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName |
Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59998;
子網掩碼=“255.255.255.255”網絡= $ ClusterNetworkName; EnableDHCP時= 0}
＃如果您使用的是Windows Server 2008 R2，請使用以下命令：
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59998
子網掩碼= 255.255.255.255
您現在在Azure中擁有一個功能齊全的多實例SQL Server FCI。如果您有任何問題要構建具有從Clusteringformeremortals.com重現的新Azure ILB功能的多實例SQL Server故障轉移群集