在 Azure SQL 上為大型 SaaS 提供一百萬個數(shù)據(jù)庫

通過Azure SQL實現(xiàn)蓬勃發(fā)展

非常感謝來自Microsoft Dynamics團隊的同事Mahesh Sreenivas、Pranab Mazumdar、Karthick Pakirisamy Krishnamurthy、Mayank Mehta和Shovan Kar為本文所做的貢獻。

[概述]

Dynamics 365是一組智能的SaaS業(yè)務應用程序，可幫助來自各個行業(yè)的各種規(guī)模的公司運行其整個業(yè)務，并通過預測性的、由AI驅動的見解來提供更好的結果。Dynamics 365應用程序構建于Microsoft Power Platform之上，該平臺提供了可擴展的基礎，不僅可以運行Dynamics應用程序本身，還可以讓客戶、系統(tǒng)集成商和ISV創(chuàng)建針對特定行業(yè)的自定義內容，并將其業(yè)務流程連接到利用無代碼/低代碼方法的數(shù)百個現(xiàn)有連接器的其他解決方案和系統(tǒng)。

Microsoft Power Platform（還提供Power Apps、Power Automate、Power Virtual Agents和PowerBI等服務）建立在Azure SQL數(shù)據(jù)庫等Microsoft Azure服務基礎上，這些服務提供可擴展且可靠的底層計算、數(shù)據(jù)、管理和安全服務，為上圖中表示的整個堆棧提供支持。

[歷史背景]

Microsoft Dynamics 365的根是一套打包的業(yè)務解決方案，例如Dynamics AX、NAV和CRM，它們在全球各地的客戶數(shù)據(jù)中心的多個Windows Server和SQL Server版本上運行。

當軟件即服務范例開始在商業(yè)應用程序行業(yè)中占主導地位時，Dynamics CRM使得該產品包成為Microsoft最早的在線服務之一。在向SaaS方式轉變的初期，Dynamics服務在Microsoft本地數(shù)據(jù)中心中的裸機服務器上運行。隨著每天數(shù)百萬計的活動用戶所帶來的使用增長，部署和運行所有這些服務器、管理容量需求以及及時響應不斷增長的客戶數(shù)據(jù)量（對于最大規(guī)模的租戶而言，數(shù)據(jù)庫大小分布從100 MB增加到超過4 TB）所帶來的工作量最終將變得難以管理。

Dynamics是最早采用Microsoft SQL Server 2012 AlwaysOn來實現(xiàn)業(yè)務連續(xù)性平臺之一，它還通過創(chuàng)建額外副本以重新平衡利用率的方式提供了一種靈活的方法來將客戶數(shù)據(jù)庫移動到新的群集。

大規(guī)模管理如此眾多的數(shù)據(jù)庫顯然是一項復雜的任務，它涉及從初始資源配置到監(jiān)控、修補和運行這一龐大的系統(tǒng)的整個數(shù)據(jù)庫生命周期，同時還要保證可用性。團隊還學會了如何處理不在故障轉移-就緒狀態(tài)的仲裁丟失和副本等問題。從性能的角度來看，在共享基礎節(jié)點上運行的數(shù)據(jù)庫實例使得我們很難隔離性能問題，并且除了將單個實例移至新節(jié)點之外，它提供的擴展或適應突發(fā)工作負載的選項也很有限。

由于最終客戶可以在其環(huán)境中運行（高度定制的）應用程序的多個版本，導致產生明顯不同的工作負載，因此，聽到通用數(shù)據(jù)服務團隊的合作伙伴組工程經理Mahesh Sreenivas說在傳統(tǒng)平臺上管理和維護所有這些組件“對工程師和最終客戶都非常痛苦”也就不足為奇了。

轉向Azure和Azure SQL數(shù)據(jù)庫

Dynamics 365團隊決定將其平臺遷移到Microsoft Azure，以解決這些管理和運營難題，同時滿足客戶需求并確保平臺基礎性能（如可用性和可靠性），并讓工程團隊專注于添加創(chuàng)新功能。

從最初的設計到生產的工程工作花好幾年的時間，其中包括將客戶遷移到新的基于Azure的平臺，從在本地運行的整體代碼庫遷移到在Azure上運行的世界一流的行星級大規(guī)模服務。

[Azure SQL數(shù)據(jù)庫中的常用數(shù)據(jù)服務]

第一個關鍵決定是從一組異構應用程序（每個應用程序都有自己的歷史和技術特點）轉移到一個通用的基礎平臺，在該平臺上，Dynamics應用程序成為常規(guī)應用程序，就像其他ISV公司可以構建和運行的應用程序一樣：因此引入了Microsoft Power Platform及其公共數(shù)據(jù)服務層。本質上，基于基礎Azure功能（如計算、存儲、網絡和Azure SQL數(shù)據(jù)庫等其他專門服務）構建的新的無代碼或低代碼平臺是一種從基礎平臺提取Dynamics應用程序的方法，讓Dynamics開發(fā)人員可以專注于向平臺轉移而無需管理數(shù)據(jù)庫實例等單個資源。

現(xiàn)在，該平臺還托管著PowerApps、Power Automate、Power Virtual Agents或PowerBI等其他服務，其他公司可以基于該平臺構建自己的SaaS應用程序，從無代碼的簡單解決方案到全代碼專用ISV應用程序都可以，且無需擔心如何管理計算和各種存儲設施等基礎資源。

通過將一個大約可管理100萬個數(shù)據(jù)庫實例的平臺遷移到Azure（截至2020年7月），Dynamics團隊學習了很多有關基礎服務工作原理的知識，還互惠互利地向其他Microsoft團隊提供了大量反饋，以使其服務更好。

從架構的角度來看，通用數(shù)據(jù)服務以邏輯戳（或規(guī)模組）進行組織，邏輯戳具有計算和數(shù)據(jù)兩層，其中關系數(shù)據(jù)存儲基于Azure SQL數(shù)據(jù)庫構建，因為團隊以前對SQL Server 2012和2016很熟悉。它提供了具有3（或更多）個9的SLA的經過預先配置的現(xiàn)成高可用性，具體取決于選擇的服務層。業(yè)務連續(xù)性也通過Geo-restore、Active Geo-replication和Auto Failover Groups等功能得到了保證。

與在共享的單個SQL Server實例本地運行多個數(shù)據(jù)庫相比，Azure SQL數(shù)據(jù)庫通過減少表、索引或備份級別的數(shù)據(jù)庫損壞事件而為團隊提供了很大的幫助。同樣，在物理計算機上的固件、操作系統(tǒng)和SQL Server上打補丁所需的若干工時已減少到僅需管理應用程序層及其數(shù)據(jù)。

鏈接：

過預先配置的現(xiàn)成高可用性

https://docs.microsoft.com/en-us/azure/azure-sql/database/high-availability-sla

業(yè)務連續(xù)性

https://docs.microsoft.com/en-us/azure/azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview

[Azure SQL數(shù)據(jù)庫彈性池]

登錄Azure SQL數(shù)據(jù)庫后，第二個關鍵決策是采用彈性池來托管其數(shù)據(jù)庫。Azure SQL數(shù)據(jù)庫彈性池是一款簡單且經濟高效的解決方案，可以管理和擴展多個具有不斷變化且無法預測的使用需求的數(shù)據(jù)庫。彈性池中的數(shù)據(jù)庫位于單個邏輯服務器上，并以固定價格共享給定數(shù)量的資源。SaaS應用程序開發(fā)人員可以在擬定的資源預算內優(yōu)化數(shù)百個數(shù)據(jù)庫的性價比，同時為每個數(shù)據(jù)庫提供性能彈性并通過為每個租戶設置最小-最大利用率閾值來控制多租戶。同時，它們通過為每個數(shù)據(jù)庫提供單獨的訪問控制策略來加強安全性和隔離。“通過遷移到Azure SQL數(shù)據(jù)庫彈性池，我們的團隊不需要在管理復制這方面進行過多投資，因為它由Azure SQL數(shù)據(jù)庫服務負責處理”，Mahesh解釋說。

Microsoft Power Platform為使用其產品組合中給定服務的每個租戶使用一個單獨的帳戶。

鏈接：

Azure SQL數(shù)據(jù)庫彈性池

https://docs.microsoft.com/en-us/azure/azure-sql/database/elastic-pool-overview

[“Spartan”資源管理層]

考慮到廣泛的客戶行業(yè)、規(guī)模和（定制的）工作負載，關鍵要求之一是能夠在一組彈性池中高效地分配和管理這些數(shù)據(jù)庫，從而最大程度地利用和管理資源。要實現(xiàn)此目的，必須滿足以下三點：

1.規(guī)模和容量規(guī)劃方面的靈活性

2.為單個租戶擴展資源的敏捷性

3.優(yōu)化的性價比

在Azure SQL數(shù)據(jù)庫平臺為全面管理這些方面提供了基礎（例如，在線服務層擴展、在池之間移動數(shù)據(jù)庫的能力、從單個數(shù)據(jù)庫移至池的能力或反之、多種性價比選擇等）的同時，Dynamics團隊還創(chuàng)建了一個專用管理層，以根據(jù)應用程序定義的條件和策略自動執(zhí)行這些操作?！癝partan”就是這個管理層，其設計目的就是為了最大程度地減少手動操作。它具有可擴展的微服務平臺（以ARM資源提供程序方式實現(xiàn)），后者負責其數(shù)據(jù)庫的整哥生命周期。

鏈接：

ARM資源提供程序

https://docs.microsoft.com/en-us/azure/azure-resource-manager/custom-providers/overview

Spartan是一個API層，不僅負責數(shù)據(jù)庫CRUD操作（創(chuàng)建、讀取、更新和刪除），還負責所有其他操作，例如在彈性池之間移動數(shù)據(jù)庫以最大程度地利用資源，在池和邏輯服務器之間實現(xiàn)客戶工作負載的平衡，管理備份保留以及將數(shù)據(jù)庫還原到先前的時間點。平臺還自動管理分配給數(shù)據(jù)庫和池的底層存儲，以避免效率低下并最大化密度。在生產中收縮數(shù)據(jù)庫這樣的操作似乎很少見，但對于需要操作超過100萬個數(shù)據(jù)庫并優(yōu)化成本的平臺而言，卻是一項很常見的任務。

彈性池按“層”進行組織，其中每個層根據(jù)所使用的基礎服務層（通用、關鍵業(yè)務）和分配的計算大小提供不同的配置，以便最終客戶數(shù)據(jù)庫始終以最佳性價比運行。除防火墻設置等其他詳細信息外，每個層還控制關聯(lián)數(shù)據(jù)庫的最小-最大設置，并定義每個池的最佳數(shù)據(jù)庫密度。

圖1每個縮放組的Azure SQL數(shù)據(jù)庫布局

上圖將彈性池這種邏輯組織表示為多個層，并顯示了Dynamics團隊用來在粒度資源分配和成本優(yōu)化之間找到最佳折衷的DTU和vCore購買模型的組合。

對于非常大的客戶，該平臺還可以將這些數(shù)據(jù)庫從共享池移到專用的Azure SQL單一數(shù)據(jù)庫中，并能夠擴展到最大的計算大?。ɡ?，具有128個vCore實例的M系列）。

如果您認為Dynamics團隊有兩名專門的工程師來管理整個平臺，而這兩名工程師專注于操作和改進Spartan平臺，而不是管理單個的數(shù)據(jù)庫，那么該平臺的效率水平是令人難以置信的。

[Dynamics 365與Azure SQL數(shù)據(jù)庫相結合，功能更加強大！]

如前所述，在此過程中，來自Dynamics和Azure團隊的工程師們共同努力改進了底層平臺。Dynamics團隊大力倡導一些平臺范圍的改進（例如加速網絡）以顯著減少計算節(jié)點與其他Azure服務之間的網絡延遲，該團隊以數(shù)據(jù)為中心的數(shù)據(jù)密集型應用程序從這些改進中受益匪淺。

在Azure SQL數(shù)據(jù)庫中，Dynamics團隊影響了vCore模型的引入，從而找到了計算內核與數(shù)據(jù)庫存儲之間的正確比例，現(xiàn)在它們可以獨立擴展并優(yōu)化成本和性能。

為了更充分地利用Common Data Service中的關系數(shù)據(jù)庫資源，該團隊實施了讀取擴展，該服務通過通過分擔主要讀寫數(shù)據(jù)庫副本上的部分工作負載來幫助提高性能。像大多數(shù)以數(shù)據(jù)為中心的服務一樣，Common Data Service中的工作負載是讀取密集型的—這意味著它獲得的讀取比寫入要多很多。借助讀取擴展，如果對Common Data Service的調用會導致選擇與更新，我們可以將該請求路由到只讀副本，并擴展讀取工作量。

在考慮各種各樣的客戶工作負載和規(guī)模方面，Dynamics 365應用程序一直是一個出色的陪練伙伴，它通過自動計劃校正、自動索引管理和智能查詢處理功能集來調整和改進自動調整等功能。

想象一下，在一百萬個數(shù)據(jù)庫中出現(xiàn)查詢超時情況：是因為缺少正確的索引策略嗎？是查詢計劃回歸？還是其他原因？

為了在故障排除和維護事件期間幫助Dynamics工程師和支持組織，我們開發(fā)了另一個名為數(shù)據(jù)管理服務（DAMS）的微服務來計劃和執(zhí)行維護任務和工作，例如創(chuàng)建或重建索引以動態(tài)優(yōu)化客戶工作負載的變化。這些任務可以涵蓋性能改進、事務管理、診斷數(shù)據(jù)收集和查詢計劃管理等領域。

圖2 DAMS架構

在Microsoft Research(MSR)的幫助下，Dynamics團隊已將SQL Server的Database Tuning Advisor(DTA)移植到Azure SQL，并將其集成到了微服務中。DTA是一個用于評估查詢并生成索引和統(tǒng)計建議以調整最關鍵數(shù)據(jù)庫工作負載的查詢性能的平臺。

與Azure SQL數(shù)據(jù)庫中的任何其他客戶數(shù)據(jù)庫一樣，Dynamics 365數(shù)據(jù)庫也具有默認處于啟用狀態(tài)的查詢存儲等功能。此功能提供有關查詢計劃選擇和性能的見解，并通過幫助它們快速發(fā)現(xiàn)由查詢計劃更改引起的性能差異來簡化性能故障排除。

除了這些功能，Dynamics團隊還創(chuàng)建了一個與最終用戶共享的優(yōu)化工具，以驗證他們的自定義設置是否正確實施，檢測諸如以可視化形式放置多少數(shù)據(jù)控件之類的內容，并提供符合其最佳做法的建議。

他們還主動監(jiān)視客戶的工作負載，以了解關鍵的用例并檢測客戶可能引入的新模式，并確保平臺可以有效地運行這些新模式。

Dynamics團隊與Azure SQL數(shù)據(jù)庫工程師并肩工作，幫助改進了數(shù)據(jù)庫引擎的許多方面。其中有一個與超大型查詢計劃緩存（超過10萬個計劃）相關的示例，這是復雜OLTP工作負載的常見問題，其中計劃重新編譯中的自旋鎖爭用導致較高的CPU利用率和很低的效率。此問題的解決為在同一平臺上運行的數(shù)以千計的其他Azure SQL數(shù)據(jù)庫客戶提供了很大的幫助。

他們幫助改進的其他領域還包括恒定時間恢復，使得數(shù)百萬個數(shù)據(jù)庫的故障轉移過程的效率大大提高，以及設定管理鎖定優(yōu)先級以減少自動索引創(chuàng)建期間的阻塞。

除了Azure SQL數(shù)據(jù)庫提供的現(xiàn)成功能外，Dynamics團隊還開發(fā)了針對客戶不斷升級的性能問題的特定故障排除工作流。例如，Dynamics支持工程師可以在有問題的客戶工作負載上運行Database Tuning Advisor，并了解可以用于減輕客戶問題的特定建議。

鏈接：

讀取擴展

https://docs.microsoft.com/en-us/azure/azure-sql/database/read-scale-out

自動調整

https://docs.microsoft.com/en-us/azure/azure-sql/database/automatic-tuning-overview

查詢存儲

https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-ver15

恒定時間恢復

https://www.microsoft.com/en-us/research/publication/constant-time-recovery-in-azure-sql-database/

故障轉移過程

https://docs.microsoft.com/en-us/azure/azure-sql/accelerated-database-recovery

[展望未來]

就某些最大型的最終客戶的規(guī)模而言，Dynamics 365是將Azure SQL數(shù)據(jù)庫最大實例大小從1TB增加到4TB的主要影響因素之一。也就是說，即使現(xiàn)在的4TB容量在擴展能力方面也是一個限制因素，因此Dynamics團隊正在將Azure SQL Database Hyperscale作為其服務的下一代關系存儲。團隊正在研究的最關鍵特性是：幾乎無限制的數(shù)據(jù)庫大小，結合計算和存儲大小之間的分隔以及利用只讀副本來擴展客戶工作負載的能力。

鏈接：

Azure SQL Database Hyperscale

https://docs.microsoft.com/en-us/azure/azure-sql/database/service-tier-hyperscale

Dynamics團隊與Azure SQL團隊并肩合作，在前面提到的所有具有挑戰(zhàn)性的方案上測試和驗證Azure SQL Database Hyperscale，這種協(xié)作不僅將分別在兩個團隊中繼續(xù)取得成功，而且對在平臺上運行的所有其他客戶也將繼續(xù)取得成功。