Analysis Services 中的高可用性和延展性
適用於：
SQL Server Analysis Services 
Azure Analysis Services Fabric/Power BI Premium
本文說明讓 Analysis Services 資料庫具有高可用性且可調整的最常見技術。 雖然每個目標都可以個別解決，但實際上，它們通常會交手：大型查詢或處理工作負載的可調整部署通常伴隨著高可用性的預期。
不過，反向案例不一定是 true。 高可用性，若沒有規模，當任務關鍵性、但適度的查詢工作負載存在嚴格的服務等級協定時，就可能成為唯一的目標。
讓 Analysis Services 高度可用且可調整的技術在所有伺服器模式中通常相同（多維度、表格式和 SharePoint 整合模式）。 除非另有具體說明，否則您應該假設本文中的資訊適用於所有模式。
要點
由於可用性和規模技術與關係資料庫引擎的技術不同，因此簡短的要點摘要是搭配 Analysis Services 使用之技術的有效簡介：
Analysis Services 利用 Windows Server 平臺內建的高可用性和延展性機制：網路負載平衡 （NLB）、視窗伺服器故障轉移叢集 （WSFC）或兩者。
注意
關係資料庫引擎的 AlwaysOn 功能不會延伸至 Analysis Services。 您無法將 Analysis Services 實例設定為在 Always On 可用性群組中執行。
雖然 Analysis Services 不會在 AlwaysOn 可用性群組中執行，但它可以從 AlwaysOn 關係資料庫擷取和處理數據。 如需如何設定高可用性關係資料庫以供 Analysis Services 使用的指示，請參閱 Analysis Services 與 AlwaysOn 可用性群組。
高可用性是唯一的目標，可透過故障轉移叢集中的伺服器備援來達成，而取代節點則假設其硬體和軟體設定與作用中節點相同。 WSFC 本身可提供高可用性，但不需要調整。
透過 NLB 透過唯讀資料庫達成延展性，無論是否具有可用性。 當查詢磁碟區很大或突然出現尖峰時，延展性通常是問題。
負載平衡，加上多個唯讀資料庫，可讓您同時調整和高可用性，因為所有節點都處於作用中狀態，而且當伺服器關閉時，要求會自動在其餘節點之間重新散發。 當您需要延展性和可用性時，NLB 叢集是正確的選擇。
為了處理，高可用性和延展性的目標較不關心，因為您可以控制作業的時間和範圍。 處理可以同時在模型的各個部分進行部分和累加處理，但在某些時候，您必須在單一伺服器上完整處理模型，以確保所有索引和匯總的數據一致性。 強固的可擴充架構依賴硬體，以因應所需的任何步調進行完整處理。 針對大型解決方案，此工作會結構化為獨立作業，並具有自己的硬體資源。
單一與多伺服器組態
在一般單一伺服器部署中，處理和查詢工作負載會同時執行，假設系統資源對這兩個活動都足夠。 Analysis Services 會在背景中處理更新的版本時，讓現有的數據結構保持不變，以取得查詢支援。 擁有足夠的記憶體和磁碟空間來處理暫存數據結構是所有伺服器模式存在的硬體需求，雖然每個模式都會對系統資源提出不同的需求，而且具有不同層級的NUMA感知。
單一伺服器和延展性
單一高階多核心伺服器可能會自行提供足夠的規模。 在具有大量核心、RAM 和磁碟空間的高階系統上，您可以在單一系統中相應增加。
針對多維度資料庫，您可以調整伺服器組態屬性，以在進程和處理器之間建立親和性。 如需詳細資訊，請參閱 線程集區屬性。
多伺服器部署
有時候作業需求會決定使用多部伺服器。 例如，故障轉移叢集依定義是多部伺服器，每個節點在相同的硬體和軟體組態上執行。
同樣地，對查詢工作負載高可用性的嚴重需求通常會呼叫多部伺服器。 在此案例中，Analysis Services 的建議組態是使用專用硬體上個別 Analysis Services 實例上執行的只讀和讀寫資料庫混合。 唯讀資料庫會處理查詢要求。 讀寫資料庫用於處理。 下一節會提供此常用技術的擴充描述。
虛擬機和高可用性
符合高可用性需求的另一個策略可能包括使用虛擬機。 如果可用性可以藉由在數小時內而非幾分鐘內站立取代伺服器來滿足，您可以使用可依需求啟動的虛擬機，並使用從中央位置擷取的更新資料庫載入。
使用唯讀和讀寫資料庫的延展性
建議將網路負載平衡用於高或呈報的查詢和處理工作負載。 NLB 解決方案中的 Analysis Services 資料庫會定義為唯讀資料庫，以確保查詢之間的一致性。
雖然使用只讀資料庫
方法摘要如下：
使用 Analysis Services 的專用硬體和實例來處理資料庫。 在處理完成之後，將資料庫設定為唯讀。 如需指示，請參閱 在 ReadOnly 和 ReadWrite 模式之間切換 Analysis Services 資料庫。
使用多個完全相同的查詢伺服器來執行相同唯讀 Analysis Services 資料庫的複本。 伺服器部署在 NLB 叢集中，可透過一個虛擬伺服器名稱存取，做為叢集的單一進入點。
使用 robocopy 將整個資料目錄從處理伺服器複製到每個查詢伺服器，並以唯讀模式將相同的資料庫附加至所有查詢伺服器。 您也可以使用 SAN 快照集、同步處理，或用於行動生產資料庫的任何其他工具或方法。
表格式和多維度工作負載的資源需求
下表摘要說明 Analysis Services 如何使用系統資源進行查詢和處理，並以伺服器模式和記憶體分隔。 此摘要可協助您了解在處理分散式工作負載的多伺服器部署中要強調的內容。
| 伺服器和儲存模式 | 對系統資源的影響 |
|---|---|
| 表格式記憶體內部（預設）查詢會當做記憶體內部數據結構的數據表掃描來執行。 | 強調具有快速時鐘速度的 RAM 和 CPU。 |
| DirectQuery 模式中的表格式，其中查詢會卸載至後端關係資料庫伺服器，而處理僅限於在模型中建構元數據。 | 專注於關係資料庫效能、降低網路等待時間，以及將輸送量最大化。 更快的 CPU 也可以改善 Analysis Services 查詢處理器的效能。 |
| 使用 MOLAP 記憶體的多維度模型 | 選擇平衡組態，以容納磁碟 IO，以便快速載入數據，並有足夠的 RAM 來快取數據。 |
| 使用 ROLAP 記憶體的多維度模型。 | 將磁碟 IO 最大化，並將網路等待時間降至最低。 |
透過 WSFC 的高可用性和備援
Analysis Services 可以安裝在現有的 Windows Server 故障轉移叢集 （WSFC） 中，以在最短時間內還原服務的高可用性。
故障轉移叢集會提供資料庫的完整存取權（讀取和回寫），但一次只能有一個節點。 輔助資料庫會在叢集中的其他節點上執行，因為第一個節點關閉時會取代伺服器。
故障轉移叢集的主要優點是從服務失敗快速復原。 這項優點具有某些限制。 就其中一個而言，如果不需要故障轉移，叢集中的專用資源就會閑置。 其次，在故障轉移時，所有連線都會遺失，且對應的未認可工作遺失。 大部分的用戶端應用程式都應該能夠處理這種情況;通常，在應用程式中按 [重新整理] 按鈕會讓結果恢復。
考慮 WSFC 時，請記住下列幾點：
- 目前不支援使用中/主動。 主動/被動（故障轉移）是 Analysis Services 唯一支援的 WSFC 組態。
- 在叢集 Analysis Services 時，請確定參與叢集的任何節點都以相同或高度類似的硬體執行，而且每個節點的操作內容在操作系統版本和 Service Pack、Analysis Services 版本和 Service Pack（或累積更新）和伺服器模式方面都相同。
- 避免將被動節點重新設為另一個工作負載的主動節點。 如果節點無法處理這兩個工作負載，當發生實際的故障轉移情況時，計算機使用率的任何短期收益都會遺失。
本白皮書提供在故障轉移叢集中部署 Analysis Services 的深入指示和背景資訊：如何叢集 SQL Server Analysis Services。 雖然針對 SQL Server 2012 撰寫，但本指南仍適用於較新版本的 Analysis Services。
另請參閱
同步處理 Analysis Services 資料庫
強制 Analysis Services 表格式資料庫的 NUMA 親和性
Analysis Services 案例研究：在大規模商業解決方案中使用表格式模型