Azure門戶中的新Azure“SQL Server設置”刀片

創建新的SQL Server虛擬機時，Azure門戶中有一個新刀片。我一直在尋找關於這個新Azure門戶體驗的公告，但無濟於事。當我在4月19日在Azure上創建SQL Server 2008 R2 FCI的最後一篇文章中拍攝屏幕截圖時，此功能無法使用。我認為它必須是相對較新的。

Azure門戶網站上的新Azure“SQL Server設置”刀片[/ caption]

大多數設置都非常自我解釋。在“安全和網絡”下，您可以指定希望SQL偵聽的端口。它似乎也會更新Azure安全組以允許對SQL實例的不同級別的訪問：本地，私有或公共。此新SQL Server設置刀片中也公開了身份驗證選項。

安全，網絡和身份驗證選項是SQL Server部署的一部分[/ caption]

其餘功能包括許可，修補和備份選項。此外，如果要部署SQL Server 2016或更高版本的企業版，還可以選擇啟用SQL Server R服務以進行高級分析。

可以自動配置許可，修補，備份和R服務選項[/ caption]

在配置新的SQL Server實例時，所有這些選項都是Azure門戶體驗的受歡迎的補充。我確信經驗豐富的DBA可能會列出一些他們想要在SQL Server部署之前調整的其他選項，但這肯定是朝著正確方向邁出的一步。

存儲配置選項

我在此刀片上找到的最有趣的新功能是存儲配置選項。

單擊“更改配置”時，將獲得以下刀片。

向右滑動IOPS滑塊時，您將看到數據磁盤數量增加，存儲大小增加以及吞吐量增加。您將受限於該實例大小支持的最大IOPS和磁盤數。您可以在下面的屏幕截圖中看到，在為標準E64-16s_v3實例配置存儲時，我可以高達80,000 IOPS。

標準E64-16s_v3實例大小支持最高80,000 IOPS [/ caption]

還有一個“存儲優化”選項。我沒有嘗試所有不同的組合來確切知道存儲優化設置的作用。如果您知道不同選項如何更改存儲配置，請給我留言，或者我們將等待官方文檔發布。

對於我的測試，我配置了一個標準DS13 v2實例，最大化了25600的IOPS，即該實例大小的最大IOPS。我還優化了事務處理的存儲。

我發現在配置此實例時，會將六個P30高級磁盤附加到該實例。這是有道理的，因為每個P30提供5000 IOPS，因此至少需要六個才能提供所請求的25,600 IOPS。這也將存儲大小增加到6 TB，因為每個P30為您提供1 TB的存儲空間。還在這些磁盤上啟用了只讀主機緩存。

六個磁盤自動配置並附加到實例[/ caption]

我登錄到實例以查看Azure對這些磁盤所做的操作。幸運的是，他們完全按照我的意願行事;他們創建了一個帶有六個P30磁盤的單個存儲池，並創建了一個簡單（又稱為RAID 0）存儲空間並配置了一個6 TB F：驅動器。此存儲配置嚮導驗證了我在之前的博客文章“在Azure中運行SQL Server的存儲注意事項”中所做的一些雲存儲假設。在大多數情況下，似乎單個大磁盤應該足夠了。

每個Azure Marketplace產品中都不提供此存儲優化。例如，如果要將SQL Server 2008 R2移動到Azure以獲得擴展安全更新，則會發現此存儲優化在SQL2008R2 / Windows Server 2008 R2 Azure Marketplace映像中不可用。當然，直到Windows Server 2012才會引入存儲空間，因此這是有道理的。我確實在Windows Server 2012 R2Azure Marketplace產品上驗證了此選項適用於SQL Server 2012 SP4。然而，有一點點不便。除了在SQL Server設置刀片上添加此新的存儲配置選項外，它們還刪除了在磁盤刀片上添加數據磁盤的選項。假設我想在不創建存儲空間的情況下配置額外的存儲空間。為此，我必須首先創建實例，然後在配置虛擬機後返回並添加數據磁盤。

最後的想法

此新Azure刀片中的所有SQL Server配置選項都是受歡迎的附加功能。我希望看到列表可調設置增長。信息文本應包括有關每個可調參數的當前最佳實踐的指導。您希望將哪些SQL Server或Windows OS可調參數作為配置過程的一部分公開，以使您作為DBA的生活更輕鬆？這些可調參數讓您的生活更輕鬆。他們還會通過引導他們完成所有當前的SQL Server配置最佳實踐，使初級DBA看起來像一個季節專業人士。我認為新的存儲配置選項可能是最引人注目的新增功能。在存儲配置嚮導之前，用戶必須了解其實例大小的限制，以及他們添加的存儲限制。最重要的是，在簡單存儲空間中將多個磁盤綁定在一起以獲得最大IOPS。幾年前，我整理了一個簡單的Azure存儲計算器，以幫助人們做出這些決定。我的計算器目前已過時。也就是說，這個新的存儲配置選項可能會使它過時。我很想看到這個存儲配置嚮導作為每個Windows實例類型的磁盤刀片中的標準產品包含在內。而只是在SQL Server實例中。我會讓用戶選擇使用新的存儲配置“嚮導”體驗。甚至是手動添加和管理存儲的“經典”體驗。經Clusteringformeremortals.com許可轉載

在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許可轉載