SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

我可以將我的文件共享證人放在DFS共享上嗎？

by Leave a Comment

我可以將我的文件共享證人放在DFS共享上嗎？

我可以將我的文件共享證人放在DFS共享上嗎？

我一直被問到這個問題 – 哪裡可以將我的文件共享見證放在DFS共享上。人們擔心失去他們的文件共享證人。因此，與其他許多股票一樣，他們希望利用DFS獲得一些額外的可用性。這是一個非常糟糕的主意，不受支持。微軟最近發布了一篇很棒的博客文章，該文章描述了為什麼不支持DFS共享上的文件共享見證的原因。https://blogs.msdn.microsoft.com/clustering/2018/04/13/failover-cluster-file-share-witness-and-dfs/本文的大部分內容也適用於那些詢問是否可以使用DataKeeper將捲資源複製為磁盤共享。這說得通。對於任何其他工作負載，您可以使用DataKeeper卷資源代替物理磁盤資源，那麼為什麼不使用Disk Witness？此問題與DFS問題相同。如果兩台服務器之間的通信中斷，則無法保證兩台服務器上的捲都不會聯機。這將導致潛在的裂腦情況。物理磁盤資源通過使用SCSI保留克服了此問題。這將確保磁盤一次只能由一個群集節點訪問。好消息是，微軟已經阻止您嘗試使用複制的DataKeeper Volume資源。在Windows Server 2019中，看起來它們也會阻止您將DFS共享用作文件共享見證。

來自故障轉移群集和網絡負載平衡團隊博客文章“故障轉移群集文件共享見證和DFS [/ caption]

有關於將文件共享見證放在DFS共享上的問題嗎？閱讀我們的博客或聯繫我們！經ClusteringForMereMortals.com許可轉載

Azure區域與虛擬網絡對等連接的網絡速度

by Leave a Comment

Azure區域與虛擬網絡對等連接的網絡速度是多少？

這是我今天問自己的問題。 當然，我無法找到在任何地方記錄的與虛擬網絡對等連接的Azure區域之間的網絡速度背後的原因。我假設沒有保證。 它可能取決於當前的利用率等。如果我錯了，請有人指出說明可用速度的文檔。我主要看這里和這裡。所以我設置了兩個Windows 2016 D4s v3實例 – 一個在美國中部，一個在美國東部2。兩者都是配對區域。如果您不知道對等是什麼，它實際上可以讓您輕鬆連接兩個不同的Azure虛擬網絡。對等很容易設置。 只需確保從兩個虛擬網絡配置它。一旦配置正確，它將看起來像這樣。

做測試

Azure中正常運行的對等網絡[/ caption]

然後我在每台服務器上下載了iPerf3並開始測試。起初我有一些非常令人失望的結果。但是經過一些研究，我發現運行多個線程並增加窗口大小可以更準確地測量可用帶寬。我試了幾個不同的設置。它似乎平均最高只有1.9 Gbps，遠遠高於45 Mbps！我使用了客戶端參數並產生了最好的結果。見如下：

iperf3.exe -c 10.0.3.4 -w32M -P 4 -t 30

該輸出的示例看起來像這樣。

 -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - 
 [4] 2.00-3.00秒34.1 MBytes 286 Mbits / sec
 [6] 2.00-3.00秒39.2 MBytes 329 Mbits / sec
 [8] 2.00-3.00秒56.1 MBytes 471 Mbits / sec
 [10] 2.00-3.00秒73.2 MBytes 615 Mbits / sec
 [SUM] 2.00-3.00秒203 MBytes 1.70 Gbits / sec
  -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - 
 [4] 3.00-4.00秒37.5 MBytes 315 Mbits / sec
 [6] 3.00-4.00秒19.9 MBytes 167 Mbits / sec
 [8] 3.00-4.00秒97.0 MBytes 814 Mbits / sec
 [10] 3.00-4.00秒96.8 MBytes 812 Mbits / sec
 [SUM] 3.00-4.00秒251 MBytes 2.11 Gbits / sec
  -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - 
 [4] 4.00-5.00秒34.6 MBytes 290 Mbits / sec
 [6] 4.00-5.00秒24.6 MBytes 207 Mbits / sec
 [8] 4.00-5.00秒70.1 MBytes 588 Mbits / sec
 [10] 4.00-5.00秒97.8 MBytes 820 Mbits / sec
 [SUM] 4.00-5.00秒227 MBytes 1.91 Gbits / sec
  -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - 
 [4] 5.00-6.00秒34.5 MBytes 289 Mbits / sec
 [6] 5.00-6.00秒31.9 MBytes 267 Mbits / sec
 [8] 5.00-6.00秒73.9 MBytes 620 Mbits / sec
 [10] 5.00-6.00秒86.4 MBytes 724 Mbits / sec
 [SUM] 5.00-6.00秒227 MBytes 1.90 Gbits / sec
  -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   - 
 [4] 6.00-7.00秒35.4 MBytes 297 Mbits / sec
 [6] 6.00-7.00秒32.1 MBytes 269 Mbits / sec
 [8] 6.00-7.00秒80.9 MBytes 678 Mbits / sec
 [10] 6.00-7.00秒78.5 MBytes 658 Mbits / sec
 [SUM] 6.00-7.00秒227 MBytes 1.90 Gbits / sec

我看到高達2.5 Gbps的峰值和低至1.3 Gbps的低點。

從Twitter更新

所以我收到了@jvallery的一些反饋，我必須嘗試一下。Azure區域與虛擬網絡對等連接的網絡速度是多少？ 我做的第一件事是將現有實例提升到D64sv3並使用-P 64。我看到了顯著的增長

iperf3.exe -c 10.0.3.4 -w32M -P 64 -t 30

[SUM] 0.00-1.00秒2.55 GBytes 21.8 Gbits / sec

然後我按照建議旋轉了一些F72v2實例，我看到了更好的結果。

iperf3.exe -c 10.0.2.5 -w32M -P 72 -t 30

[SUM] 0.00-1.00秒2.86 GBytes 24.5 Gbits / sec

  我在Linux上不夠精通。在使用對等網絡時，Azure區域之間似乎有合理數量的可用帶寬。如果有人想在@jvallery建議下使用Linux重複此測試，我很樂意在此發布您的結果！似乎確實可以改變連接虛擬網絡對等的Azure區域之間的網絡速度。

使用SIOS DataKeeper進行災難恢復

對於我的一個客戶，我選擇使用這兩個對等網絡來解決使用SIOS DataKeeper的SQL Server災難恢復，以便在區域之間異步複製SQL數據以進行災難恢復。

SIOS DataKeeper將數據從Azure EAST US 2複製到CENTRAL US [/ caption]

在這種特殊情況下，我們測量的是以毫秒為單位測量的RPO。正如您在下面的視頻中看到的，在DISKSPD測試期間，為了模擬典型的SQL Server工作負載，RPO <1秒。 我很樂意聽取您關於您在Azure中測量的任何網絡速度以及如何在Azure中使用對等網絡的經驗。是否有關於Azure區域與虛擬網絡對等連接的網絡速度的問題？閱讀我們的博客或聯繫我們！經ClusteringForMereMortals.com許可轉載

將Azure群集轉換為託管磁盤

by Leave a Comment

為什麼要將azure群集轉換為託管磁盤

為什麼要將Azure群集轉換為託管磁盤

你可能聽說過最近的存儲中斷在3月16日影響了美國東部地區的一些情況。此處發布了中斷的根本原因分析。 3月16日美國東部停電中斷

客戶影響力

在美國東部地區使用存儲的客戶子集在單個存儲規模單元中訪問其存儲帳戶時可能會遇到錯誤和超時。您可能會問，“什麼是單個存儲比例單位”。好吧，您可以將其視為單個存儲群集或單個SAN，或者您想要考慮它。我不認為Azure發布他們的確切基礎設施。雖然您可以假設在幕後他們使用橫向擴展文件服務器進行後端存儲。

以最短的停機時間生存停電

所以問題是，如何以最短的停機時間倖存下來？如果你進一步閱讀根本原因分析，你會遇到這個小塊金塊。

在此事件期間，使用可用性集中的託管磁盤的虛擬機將保持可用性。因此，是時候將Azure群集轉換為託管磁盤

什麼是託管磁盤？

2月8日，Corey Sanders宣布了管理磁盤的GA。託管磁盤可以幫助解決這種中斷問題。因為通過利用可用性集與託管磁盤相結合，可用性集中的每個實例都連接到不同的“存儲規模單元”。因此，在這種特殊情況下，只有一個集群節點發生故障，剩下的節點將接管工作負載。在託管磁盤可用之前（2016年2月8日之前部署的任何磁盤）之前，無法確保連接到服務器的存儲位於不同的存儲規模單元上。當然，您可以為每個實例使用不同的存儲帳戶。但實際上，並不能保證那些存儲帳戶在不同的存儲規模單元上配置存儲。將Azure群集轉換為託管磁盤的更多理由。因此，雖然可用性集確保您的實例駐留在不同的故障域和更新域中以確保實例本身的可用性，但是附加到每個實例的附加存儲確實代表單點故障。雖然存儲本身俱有高彈性，但有三個數據副本和地理冗餘選項可用，在這種情況下斷電時，整個存儲規模單元與連接到它的所有服務器一起關閉。長話短說……盡快將Azure群集轉換為託管磁盤，以幫助減少停機時間https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to管理磁盤如果您真的想最大限度地減少停機時間，您應該考慮跨雲提供商或云端部署的混合雲部署！經Clusteringformeremortals.com許可轉載

Cloud Witness在Azure中構建多實例SQL Server故障轉移群集

by Leave a Comment

新的Azure ILB功能允許您在Azure中構建多實例SQL Server故障轉移群集

新的Azure ILB功能允許您在Azure中構建多實例SQL Server故障轉移群集

新功能，Cloud Witness是我最喜歡的。在我們查看Windows Server 2016中的新仲裁功能之前，我認為了解它們的來源非常重要。在我之前的帖子了解Windows Server 2012 R2中的Windows Server故障轉移群集仲裁中，我詳細介紹了群集仲裁的歷史和演變。我建議您查看該帖子，以了解仲裁在Windows Server 2012 R2中的工作原理。此外，Windows Server 2016的新功能將如何使您的群集部署更具彈性。

雲見證人

Cloud Witness允許您利用Azure Blob存儲作為群集的見證。這個證人將代替磁盤見證或文件共享見證。Cloud Witness的配置非常簡單。根據我的經驗，幾乎沒有任何東西可以在Azure中託管。唯一的缺點是群集節點需要能夠通過Internet與Azure Blob存儲進行通信。通常，群集節點被禁止與公共互聯網通信。因此，如果要啟用Cloud Witness，則需要與安全團隊協調。使用Cloud Witness在Azure中構建多實例SQL Server故障轉移群集有許多令人信服的理由。但對我來說，它在三個非常特定的環境中最有意義：Azure中的故障轉移群集，分支機構群集和多站點群集。

仔細看看

讓我們來看看每個場景，看看Cloud Witness如何提供幫助。圖1 – 當您嘗試在Azure中構建多實例SQL Server故障轉移群集時，應始終配置雲見證存儲帳戶本地冗餘存儲（LRS）[/字幕]

高度可用的部署

如果您要遷移到Azure（或任何云提供商），您將需要確保您的部署具有高可用性。如果您正在使用傳統上與Windows Server故障轉移群集集群的SQL Server，文件服務器，SAP或其他工作負載，則需要使用文件共享見證或云見證，因為Azure中無法使用磁盤見證。對於Windows Server 2012 R2或Windows Server 2008 R2，您將需要使用文件共享見證。Windows Server 2016可以使用Cloud Witness。Cloud Witness的優勢在於您無需在Azure中維護另一個Windows實例來託管文件共享。相反，Microsoft允許您利用Blob存儲。 這為您提供了一種更便宜的解決方案，一種更易於管理且更具彈性的解決方案。

位置

在分支機構中查看集群部署時，始終需要考慮成本和維護。對於擁有數百或數千個位置的零售連鎖店而言，在每個位置都有SAN可能成本過高。每個位置可能在S2D Hyper-fusionged配置或第三方復制解決方案上運行雙節點Hyper-V群集以託管多個虛擬機。現在，Cloud Witness可以做的是幫助企業避免在每個位置添加額外的物理服務器以充當文件共享見證或向每個位置添加SAN的成本。

消除了對第三個數據中心的需求

最後，在部署多站點群集時，Cloud Witness無需第三個數據中心來託管文件共享見證。在引入Cloud Witness之前，最佳實踐將要求File Share Witness位於第3個位置。訪問第三個數據中心只是為了託管文件共享見證並不總是可行的，並且肯定會引入另一層複雜性。通過使用Cloud Witness，您無需維護第三個位置，並且可以通過公共互聯網訪問見證，從而最大限度地降低了網絡要求。

網站意識

在構建多站點群集時，總會出現另一個常見問題。控制故障轉移始終優先選擇本地站點是不可能的。雖然您可以指定“首選所有者”，但“首選所有者”設置通常會被誤解。管理員可能沒有意識到這一點。但是，您知道即使他們沒有將服務器列為首選所有者，服務器也會自動附加到群集維護的首選所有者列表的末尾。這種誤解的結果是，雖然您可能只將本地服務器列為首選所有者，但您可能會將群集資源故障轉移到DR站點。即使在本地站點中有一個非常好的節點，這也是如此。顯然這不是您所期望的，使用Site Awareness將消除此問題。站點感知通過在決定將哪個節點聯機時始終優先選擇本地站點來解決此問題。因此，在正常情況下，除非您有完整的站點中斷，否則群集工作負載將始終故障轉移到本地節點。在這種情況下，其中一個DR節點將聯機。一旦您在災難恢復站點中運行，情況也是如此。如果先前在DR站點中的節點上運行，則群集將恢復DR站點中的服務器上的工作負載。站點意識總是更喜歡本地節點。

故障域

建立在站點上的意識是Fault Domains。Fault Domains更進一步，除了Site之外，還可以定義Node，Chasse和Rack位置。Fault Domains有三個好處：Stretch Cluster中的存儲親和性可以提高存儲空間的彈性。它通過包含有關引發警報的相關資源的位置的元數據來增強運行狀況服務警報。Storage Affinity將幫助確保您的群集工作負載和存儲在同一位置運行。您當然不希望您的VM讀取和寫入位於不同城市的CSV上的數據。但是，我認為這裡最大的贏家是Storage Spaces Direct（S2D）場景。SD2將利用您提供的有關群集節點位置（站點，機架，機箱）的信息，以確保為冗餘編寫的多個數據副本都存在於不同的故障域中。這有助於確保優化數據放置，以便單個節點，機箱，機架或站點的故障不會影響整個S2D部署。  Cosmos Darwin在第9頻道播放了一段精彩視頻，詳細解釋了這一概念。

概要

Windows Server 2016為群集仲裁添加了幾項新增強功能，這些增強功能將為群集部署提供一些直接的好處。此外，還可以查看其他一些新的集群增強功能，如滾動系統升級，虛擬機恢復能力，工作組和多域集群等。要閱讀其他提示，例如在Azure中使用Cloud Witness構建新的多實例SQL Server故障轉移群集，請閱讀我們的帖子。經Clusteringformeremortals.com許可轉載

S2D用於SQL Server故障轉移群集實例 

by Leave a Comment

存儲空間直接（S2D）用於SQL Server故障轉移群集實例

存儲空間直接用於SQL Server故障轉移群集實例

隨著Windows Server 2016 Datacenter Edition的推出，引入了一項名為Storage Spaces Direct（S2D）的新功能。在非常高的級別，S2D For SQL Server故障轉移群集實例允許您將本地連接的存儲池合併在一起，並將其作為CSV呈現給群集，以便在擴展文件服務器中使用。然後，它可以通過SMB 3訪問，並用於保存群集數據，如Hyper-V VMDK文件。這也可以以超融合（HCI）方式配置，使得應用程序和數據都可以在同一組服務器上運行。  這是一個非常簡化的描述，但有關詳細信息，您需要查看此處。

存儲空間直接堆棧 圖片取自https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview目標主要用例是Hyper-V部署的超融合基礎架構。但是，還有其他用例，包括利用此SMB存儲來存儲要在SQL Server故障轉移群集實例中使用的SQL Server數據

為什麼有人想這樣做？

那麼，對於初學者，您現在可以使用SQL Server標準版構建高度可用的2節點SQL Server故障轉移群集實例（FCI），而無需共享存儲。以前，如果您想要沒有SAN的HA，您幾乎可以購買SQL Server企業版並使用Always On Availability Groups或購買SIOS DataKeeper並利用第三方解決方案，該解決方案允許您使用任何版本的Windows構建SANless群集或SQL Server。SQL Server企業版可以真正提高項目成本，特別是如果您只是為可用性組功能購買它。除了與可用性組相關的成本之外，還有許多其他技術原因可能會使您更喜歡故障轉移群集而不是AG。應用程序兼容性，實例與數據庫級別保護，大量數據庫，DTC支持，經過培訓的人員等等，只是您可能希望堅持使用故障轉移群集實例的一些技術原因。

SIOS DataKeeper解決方案VSS用於SQL Server故障轉移群集實例 

Microsoft在此處的文檔中列出了SIOS DataKeeper解決方案和S2D解決方案，作為SQL Server FCI支持的兩種解決方案。S2D用於SQL Server故障轉移群集實例  https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr比較這兩種解決方案時，你必須考慮到這一點自1999年以來，SIOS一直允許您構建SANless Clusters。但S2D for SQL Server故障轉移群集實例仍處於起步階段。  話雖如此，一定會有一些區域，S2D有一些趕上來做。或者，僅僅由於技術的限制，它們將永遠不會支持的功能。

在選擇SANless群集解決方案之前

有關在選擇SANless群集解決方案之前應考慮的一些事項的概述，請查看下表。S2D用於SQL Server故障轉移群集實例  如果我們瀏覽此圖表，我們會發現SIOS DataKeeper顯然具有一些顯著優勢。例如，DataKeeper支持更廣泛的平台，一直回到Windows Server 2008 R2和SQL Server 2008 R2。S2D解決方案僅支持最新版本的Windows和SQL Server 2016/2017。S2D還需要Windows的Datacenter Edition，這會顯著增加部署成本。此外，SIOS還為Linux上的SQL Server提供了唯一的HA / DR解決方案，既可以在本地也可以在雲中運行。

分析差異

但是，除了成本和平台限制之外，我認為當我們開始考慮SANless群集的災難恢復選項時，最明顯的差距就出現了。Allan Hirt，SQL Server集群大師以及Microsoft Cloud和Datacenter Management MVP，最近發布了有關此S2D限制的文章。在他的文章Revisiting Storage Spaces Direct和SQL Server FCI中，Allan指出，由於缺乏對跨站點拉伸S2D群集的支持，或者包括基於S2D的群集作為Always On Availability Group中的支路，因此，DR的最佳選擇是S2D場景是日誌傳送！別誤會我的意思。原木運輸已經永遠存在，並且可能在我離開後很長一段時間。但是，當我們考慮我們已經習慣的所有災難恢復解決方案時，例如多站點群集，可用性組等，這是向後邁出了巨大的一步。相比之下，SIOS DataKeeper解決方案完全支持Always On Availability Groups。更好的是 – 它可以讓您跨站點擴展您的FCI，為您提供您希望在RTO / RPO方面實現的最佳HA / DR解決方案。在Azure環境中，DataKeeper還支持Azure站點恢復（ASR），為您提供更多災難恢復選項。這個圖表的其餘部分非常自我解釋。它基本上包括在部署S2D群集之前必須滿足的列表硬件，存儲和網絡要求。這裡保留了詳細的S2D要求列表。  https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIOS Datakeeper。有什麼好的

SIOS DataKeeper解決方案更加寬鬆。它支持任何本地連接的存儲，只要硬件通過集群驗證，它就是受支持的集群配置。塊級複製解決方案一直運行良好，因為1 Gbps被認為是快速LAN並且T1 WAN連接被認為是奢侈品。SANless群集對於雲部署尤其有用。云不為集群提供傳統的共享存儲選項。因此，對於想要隨身攜帶群集的“升級並轉移”到雲中的用戶，他們必須查看備用存儲解決方案。對於雲部署，SIOS已通過Azure，AWS和Google認證，可在相關的雲市場中使用。雖然在Azure或Google中似乎沒有阻止基於S2D的群集部署的任何內容，但Microsoft對這些平台的文檔或支持性聲明顯然不足。

做出安全的選擇

SIOS DataKeeper自1999年以來一直在這樣做。SIOS已經聽取了所有功能請求，發現了所有的錯誤，並為SANless集群提供了堅如磐石的解決方案，經過時間測試和驗證。雖然微軟S2D是一種很有前景的技術，但作為第一代產品，我會等到塵埃落定並且一些功能差距關閉之後我會考慮將它用於我的業務關鍵應用程序。

要了解有關S2D對於SQL Server故障轉移群集實例的更多信息，請在此處查找SIOS DataKeeper經Clusteringformeremortals.com許可轉載