SIOS SANless clusters High-availability Machine Learning monitoring
如果您是ARM和JSON的新手，並且想了解更多信息，那麼您可以參加一個演示文稿，以便開始使用。就我個人而言，我強烈建議您查看這篇內容豐富的報告。Freddy vs JSON：使用Azure資源管理器構建您的雲。它只是由微軟Ignite澳大利亞的詹姆斯·班南提出的。演示文稿包含了ARM模板的使用工具和結構。我希望在今年早些時候開始研究ARM和JSON的時候有過這個。轉載自https://clusteringformeremortals.com/2015/11/25/getting-started-with-azure-resource-manager-arm-and-json/的許可
當涉及Azure中的SQL Server存儲配置時，有幾個選項。如果您想知道，可以從Azure IAAS VM上的Windows Server故障轉移群集 – 第1部分（存儲）中獲得一些好主意。它討論了新發布的Azure文件服務，該服務可用於通過SMB 3.0託管SQL Server群集數據。請記住，Azure文件服務不支持高級存儲。每個文件共享約有1,000 IOPS或60 MB / s。考慮到這些限制，Azure文件服務可能將成為IO需求最小的數據庫選項。
所以這個計劃是測試一些不同的SQL Server存儲配置。我配置了DS4虛擬機並附加了一些高級存儲。接下來，我使用Azure File Service附加了SMB 3.0文件共享。以下是我配置SQL Server存儲配置的方式。
當您將存儲池配置為在群集中使用時請務必小心。您可以在群集啟動之前創建存儲池，也可以在Windows 2012 R2存儲空間中使用Sql Alwayson中的Powershell腳本（如果群集已經創建）。我創建了一個簡單鏡像（RAID o）請注意，由於Azure存儲在後端具有三重冗餘，因此我並不擔心冗餘。
要將存儲池配置為在群集中使用，您必須小心操作。您必須在創建群集之前創建存儲池，或者如果已創建群集，請使用Windows 2012 R2存儲空間中的Sql Alwayson中所述的Powershell腳本。為了提高性能，我創建的池是簡單鏡像（RAID 0）。由於後端的Azure存儲具有三重冗餘，因此我不擔心冗餘。
我應該得到單個磁盤性能的三倍，因為我在存儲池中有三個磁盤位於RAID 0中。現在，如果我選擇將更多磁盤添加到池中，我將享受更高的性能。一個P30磁盤給我5000 IOPS和200 MB / S。基於此，我預計我的游泳池可達到15000 IOPS和600 MB / S的吞吐量。
現在，我已經將存儲設置為存儲，我將Dskspd配置為在每個不同的捲上運行相同的測試。這是我用Dskspd做的參數。
Diskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M F： io.datDiskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M G： io.dat Diskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M Z： io.dat
不同SQL Server存儲配置的結果是相當可預測的，並在下面進行總結。
看看結果，這個特定的工作沒有推動任何這些存儲解決方案的理論最大值的上限。但是，延遲對此特定測試的整體性能有重大影響。該測試使用8k塊混合30％寫入和70％讀取來模擬典型的SQL Server OLTP工作負載。
當然，你想花更多的錢，你可以期望獲得更多的表現。這是相對的。
截至2015年11月24日，這裡顯示的最佳解決方案的價格（F：）將花費$ 1,216 /月。它承諾完全訪問3 TB存儲空間，並具有無限次的讀/寫。
第二個最佳解決方案（G：）會給你1TB的存儲空間，價格為每月405美元。Azure File Share的價格為0.10美元/ GB，另外還有額外的讀/寫操作費用。您只收取實際使用費用。因此估算實際成本將取決於您的使用情況。在讀/寫操作的額外費用之前，您約佔高級存儲成本的25％。
與雲中的其他產品一樣，價格也會迅速變化，以應對市場需求。請訪問https://azure.microsoft.com/en-us/pricing/details/storage/查看最新價格信息，了解最新價格信息。
從這個SQL Server存儲配置的編譯和價格概述中，Azure文件服務確實從價格的角度看起來很誘人。此時的延遲並不能使其成為任何嚴重SQL Server工作負載的可行選項。請考慮利用高級存儲並利用基於主機的複制解決方案（如SIOS DataKeeper）來構建SQL Server故障轉移群集實例（SQL標準版或企業版）或查看SQL Server企業版和AlwaysOn AG。
轉載https://clusteringformeremortals.com/2015/11/24/highly-available-sql-server-storage-options-in-azure-smb-3-0-file-service-or-premium-storage-一，看-AT-性能差異/
對於那些有興趣了解如何使用Azure資源管理器（ARM）以及如何將它用於在雲中部署SQL服務器的人，請註冊參加12月15日的網絡研討會：https：//www.mssqltips.com/webcastSignupPage。ASP？ID = 480 SRC = SIOS
ARM是與Microsoft Azure IaaS合作的最新最好的方式。與ARM合作有很多好處，包括模板部署，分組，簡化計費等等。借助這個新模型，可以發現一些新功能以及與Azure交互的新方法。在本次網絡研討會中，Microsoft雲和數據中心管理層MVP大衛伯明翰將介紹ARM並深入研究如何利用ARM在雲中部署高可用性和可伸縮的SQL Server部署。時間：12月15日
時間：美國東部時間下午1:00 /太平洋標準時間10:00
轉載https://clusteringformeremortals.com/2015/11/16/azure-resource-manager-and-highly-available-sql-server-webinar-sqltips/的許可
在本文中我們將要討論的是在資源管理器部署模型上配置SQL Server Alwayson內部負載平衡器。
如果您不知道，Azure有兩種部署模型：資源管理器（ARM）和經典部署。經典部署是做事的“老”方式，ARM是做事的新方式。如Azure文章理解資源管理器部署和經典部署中所述，使用ARM有許多好處。但是，我最喜歡的ARM新功能之一是可以為每個可用性集合提供三個故障域，而不僅僅是您使用Classic部署模型獲得的兩個故障域。這是SQL Server High Availability的一個重要功能。
通過三個故障域，可以確保雙節點群集中的每個群集節點和文件共享見證全部駐留在不同的故障域中。這消除了單個故障域的故障可能會影響集群中多個法定人數投票的可能性。
在具有兩個故障域的Classic Deployment模型中，只能將兩個群集節點放入可用性集中。為了獲得最大可用性，您確實需要將文件共享見證放在不同的地理位置。無法保證它不會像其中一個群集節點一樣處於相同的故障域，並且如果將它保存在同一地理位置。這意味著單個故障域的失敗可能會影響3個法定票數中的2個。它會降低你的整個群集。ARM的三個故障域消除了這種可能性。
由於僅在ARM中引入新的Azure功能，因此ARM無疑是最佳選擇。但是，文檔很輕，有些功能還沒有完成。 包括諸如ExpressRoute的文檔化支持等。這些問題幾乎每天都會好起來。 但是，早期採用者真的必須加倍努力，直到Azure趕上。另一個問題是您不能混用Classic和ARM部署。因此，如果您使用Classic部署開始走下坡路，那麼基本上您將不得不從資源管理器開始實施切換。如果你現在可以忍受一點痛苦，它會幫助你明年避免更大的頭痛。特別是，當你發現你想要一些僅在ARM中可用的新功能時。
我希望這篇文章能夠幫助您至少了解ARM部署的一個方面 – 部署高可用性的SQL Server。正如我在前面的文章中所記錄的，在Azure“Classic”中部署AlwaysOn可用性組和AlwaysOn故障轉移群集實例需要使用Azure負載平衡器（內部或外部）進行客戶端重定向。在Classic Azure中配置並不是直截了當的。但是已經很好地記錄下來，任何熟悉Azure，故障轉移群集，SQL Server和PowerShell的管理員都可以使其運行。
使用ARM部署模型的AlwaysOn可用性組和AlwaysOn故障轉移群集實例仍需要使用Azure負載均衡器進行客戶端重定向。但是，創建和配置負載平衡器的步驟完全不同。 截至今天，它也沒有被完全記錄得很好。
在本文中，我將重點介紹配置SQL Server AlwaysOn內部負載均衡器和更新SQL群集IP資源所需的步驟。在下一篇文章中，我將逐步介紹整個流程，從創建vNet到安裝SQL並創建集群。
在我們開始之前，我做了以下假設，你已經完成了以下工作：
既然您擁有完全配置的AlwaysOn AG或故障轉移群集實例，那麼您可能注意到無法從除當前承載SQL群集名稱資源的節點之外的任何服務器連接到群集名稱。我被告知這是因為Azure網絡不支持無償ARPS。因此，客戶端不能直接與群集IP地址通信。相反，客戶端需要與ILB通信，ILB會將流量重定向到主動節點。因此第1步是創建ILB。到目前為止，這無法通過Azure門戶完成，因此我們將使用以下Azure PowerShell命令。
[1/6/2016 Update – The directions below assume you are using Azure PowerShell pre-version 1. The script if you are using Azure PowerShell Version 1 or later is detailed in my blog post here.]
Switch-AzureMode -Name AzureResourceManager
Select-AzureSubscription -SubscriptionName“MSDN Azure”
＃名稱，無論您用於創建vNet和VM的訂閱
＃使用與您的部署相關的值來聲明您的變量
$ ResourceGroupName ='SIOS-EAST-RG'
＃資源組部署SQL節點的名稱
$ FrontEndConfigurationName ='FE'
＃無論你喜歡什麼，都可以撥打
$ BackendConfiguratioName ='BE'
＃無論你喜歡什麼，都可以撥打
$ LoadBalancerName ='ILB'
＃為內部本地餘額對象提供一個名稱
$ Location ='eastus2'
＃輸入SQL虛擬機的數據中心位置
$ subname ='PUBLIC'
＃提供放置SQL節點的子網名稱
$ ILBIP = '10 .0.0.201'
＃為監聽器或負載均衡器提供IP地址
$ subnet = Get-AzureVirtualNetwork -ResourceGroupName $ ResourceGroupName |
Get-AzureVirtualNetworkSubnetConfig -name $ subname
$ FEConfig = New-AzureLoadBalancerFrontendIpConfig
-Name $ FrontEndConfigurationName -PrivateIpAddress $ ILBIP -SubnetId $ subnet.Id
$ BackendConfig = New-AzureLoadBalancerBackendAddressPoolConfig
-Name $ BackendConfiguratioName
＃創建ILB
New-AzureLoadBalancer -Name $ LoadBalancerName -ResourceGroupName
$ ResourceGroupName -Location $ Location
-FrontendIpConfiguration $ FEConfig -BackendAddressPool $ BackendConfig如果我們列出資源組中的所有對象，我們應該在Azure門戶中看到它，如下所示。
我確信其餘的配置也可以通過PowerShell完成。但我將在我的示例中使用GUI。如果您想使用PowerShell，您可以通過查看使用Azure資源管理器開始配置內部負載平衡器的文章，將腳本拼湊在一起。 老實說那篇文章讓我很頭疼。我會在一天之內弄清楚它的存在並嘗試以用戶友好的格式記錄它。 現在我認為GUI對於接下來的步驟是很好的。
跟隨下面的屏幕截圖。如果您迷路了，請按照Azure門戶頂部的導航提示找出我們的位置。
點擊後台池設置標籤。 選擇後端池來更新可用性集和虛擬機。保存您的更改。
通過單擊探針選項卡上的添加來配置負載平衡器的探針。為探測器命名並將其配置為使用TCP端口59999。我已將探測間隔和不健康閾值設置為默認設置。這意味著ILB在故障切換後從被激活節點列表中移除被動節點需要10秒鐘的時間。這也意味著您的客戶可能需要長達10秒才能重定向到新的活動節點。一定要保存您的更改。
導航到“負載平衡規則”選項卡並添加新規則。給規則一個明智的名字（SQL1433或其他）。選擇TCP協議端口1433（假設您正在使用SQL Server的默認實例）。為後端端口選擇1433。對於後端池，我們將選擇我們之前創建的後端池（BE）。接下來，對於探針，我們將選擇我們之前創建的探針。我們不想啟用會話持久性，但我們希望啟用浮動IP（直接服務器返回）。我已將空閒超時設置為默認設置。但是你可能想考慮將其增加到最大值。每次連接斷開並需要重新建立時，我都會看到一些應用程序，例如SAP日誌錯誤消息。
此時配置ILB。只有最後一步需要進行。我們需要更新SQL IP群集資源，就像我們在Classic部署模型中所用的一樣。為此，您只需在其中一個群集節點上運行以下PowerShell腳本。並註意，SubnetMask =“255.255.255.255”不是一個錯誤。無論您的實際子網掩碼是什麼，都使用32位掩碼。
＃此腳本應在主群集節點上運行
內部負載均衡器已創建
＃定義變量
$ ClusterNetworkName =“群集網絡1”
＃群集網絡名稱
$ IPResourceName =“SQL IP地址1（SQLCluster1）”
＃IP地址資源名稱
$ CloudServiceIP =“10.0.0.201”
＃內部負載平衡器的IP地址
導入模塊故障轉移群集
＃如果您使用的是Windows 2012或更高版本，
使用Get-Cluster Resource命令。
如果您使用的是Windows 2008 R2，
使用已註釋掉的cluster res命令。
Get-ClusterResource $ IPResourceName
Set-ClusterParameter -Multiple @ {“Address”=“$ CloudServiceIP”;
“ProbePort”=“59999”;子網掩碼=“255.255.255.255”;
“網絡”=“$ ClusterNetworkName”;“OverrideAddressMatch”= 1;“EnableDHCP時”= 0}
#cluster res $ IPResourceName / priv enabledhcp = 0
overrideaddressmatch = 1 address = $ CloudServiceIP probeport = 59999
子網掩碼= 255.255.255.255
在我最初的測試中，即使完成了上述所有步驟後，仍然無法連接到SQL資源名稱。在將我的頭靠在牆上幾個小時後，我發現由於某種原因，SQL群集名稱資源未在DNS中註冊。我不確定這是怎麼發生的，或者是否會一直發生。 如果您在連接時遇到問題，我一定會檢查DNS。另外，如果SQL集群名稱和IP地址不在那裡，則將其添加為新的記錄。
當然，別忘了Windows防火牆。您必須為1433和59999制定例外規定，或者關閉它直到您像我一樣正確配置所有設置。您可能想要利用Azure網絡安全組而不是本地Windows防火牆，以獲得跨所有Azure資源的更加統一的體驗。
祝你好運，讓我知道你的經驗如何配置SQL Server AlwaysOn內部負載平衡器與資源管理器。
轉載https://clusteringformeremortals.com/2015/10/29/configuring-the-sql-server-alwayson-ilb-for-the-client-listener-in-azure-resource-manager-arm-deployment-模型sqlpass /
瞧，我非常高興看到一個變化 – 三個斷層域！今年夏天離開Azure一兩個月之後，我決定啟動Azure門戶。 我想看看最近在我準備關於Azure SQL Server高可用性的PASS演示文稿時已經實現了哪些更改。 他們終於開始提供每個可用性集的三個故障域作為默認設置。選擇“資源管理器”作為您的部署模型而不是“經典”。
到目前為止，在創建可用性集時，默認選項是為每個可用性集創建兩個故障域。部署群集時，至少有三個故障域非常重要。一個用於每個群集節點，另一個用於File Share Witness。這可確保單個故障域的故障在任何時候都不會影響您的法定票數以上。在GUI中實現此功能之前，有一種方法可以通過ARM模板實現。 但將它放入GUI中會使這些管理員很容易不能加快ARM模板的速度。
此功能現在完成了我之前記錄的有關如何在Azure中創建SQL Server FCI的步驟。
轉載自https://clusteringformeremortals.com/2015/09/08/three-fault-domains-in-azure-now-default-when-using-resource-manager-deployment-model/的許可