Date: 8 5 月, 2019
在Azure中運行SQL Server的存儲注意事項
在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 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！雲的美妙之處在於您可以隨時添加更多存儲空間，增加實例大小，或者盡一切可能優化性能與成本。
如何處理TempDB
使用本地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許可轉載