SCCM規劃 - 高可用及冗餘
本篇文章主要討論ConfigMgr站點、站點系統及客戶端的高可用，希望爲各位讀者對ConfigMgr高可用性提供較爲全面的瞭解。
ConfigMgr並不像Exchange、SfB此類應用主要以用戶和客戶端交互的形式存在從而使得應用對服務端可用性有非常高的要求，畢竟在ConfigMgr的場景下管理員想推送一個軟件、一個補丁到客戶端，這些行爲本身可能就是以靜默的方式運行在後臺的，且ConfigMgr本身也並不強調秒級甚至是分鐘級別的實時性，因此對於客戶端來說，某個服務節點出現故障後客戶端可以選擇切換到下一個相同功能的節點請求服務，這個過程對於用戶來說是不感知的；基於這種客觀情況，ConfigMgr中所謂的高可用其實從我個人的角度來說，更像是一種服務的冗餘，因爲這些高可用本身存在的形式並不像傳統意義上的高可用，畢竟很多時候當節點出現故障後，客戶端是可以感知到服務不可用的，但是它又和傳統的高可用那樣，對於用戶做到了透明。
可提供高可用的站點組件及角色
站點組件
-
站點數據庫：在ConfigMgr version 1602之前，站點數據庫通過SQL Server羣集實現高可用，ConfigMgr version 1602開始支持SQL Server Always On Availability Group作爲高可用方案；
輔助站點不支持使用SQL Server羣集以及SQL Server Always On Availability Group*
-
在ConfigMgr層級中引入中心管理站點將增加其下主要站點宕機時的恢復選項，這是因爲在層級中所有主要站點的數據都會複製到中心管理站點，因此當主要站點的備份不可用時，可以通過中心站點來恢復主要站點。
- SMS提供程序：可以通過部署多個SMS提供程序提高冗餘性。
站點系統角色
-
通過部署多個實例來實現冗餘的角色：管理點、分發點、狀態遷移點、系統健康驗證點、應用程序目錄Web服務點、應用程序目錄網站點、軟件更新點、Report Service點；
- 多實例站點系統角色同時也提供了負載均衡的能力。
- 多實例站點系統需要通過ConfigMgr客戶端的支持以體現其冗餘能力。
- 將服務信息發佈到多個位置實現冗餘：典型的是同時將管理點信息通過Active Directory整合發佈到Active Directory以及發佈到DNS的方式在多個位置提供冗餘信息；
無法提供高可用的站點組件及角色
站點組件
- 站點服務器：站點服務器目前沒有高可用方案，如果中心管理站點或是主要站點宕機，可以通過ConfigMgr自身的備份恢復機制恢復。如果輔助站點宕機，唯一的辦法就是重新安裝輔助站點；
站點系統角色
- 資產智能同步點
- Endpoint Protection點
- 註冊點
- 註冊代理點
- 回退狀態點
- 帶外服務點
這些角色本身不承擔關鍵服務或相關服務對高可用性的要求較低，因此一旦涉及到的角色宕機，可以在層級結構中刪除此角色並將此角色重新安裝到新的服務器上。
ConfigMgr客戶端
ConfigMgr客戶端也提供高可用方案以在服務節點或自身出現問題時，儘可能的維持各項功能的正常運行，主要有以下幾個方面：
-
客戶端自治運行：
- 客戶端和站點系統無需進行連續持久的信息交互，即使客戶端暫時無法和站點系統正常通信也會按照已收到的配置信息按計劃執行各類任務；
- 客戶端能夠感知到不可用的服務節點，並嘗試從服務節點列表中嘗試和餘下的節點進行通訊以維持各類任務的正常運行；
-
客戶端自我修復：客戶端會定期評估自身的狀態並在需要的時候自動修復各類組件；
- 客戶端緩存信息：客戶端會將配置信息和自身的歷史任務運行狀態等信息保存於本地的WMI命名空間內，並按照運行計劃在必要的時候評估當前狀態以執行客戶端任務；
爲讀者提煉SCCM涉及的基礎知識、注意事項、運行機制以及排錯方法等信息以便幫助讀者更好的理解系統是本系列文章的初衷，對於SCCM各組件及功能部署步驟方面的信息，網絡中已有較多文章可以參考，因此本系列文章並不側重於提供類似Step-by-Step的部署指南，還請見諒。同時由於個人能力和知識水平的限制，文中不免有紕漏和出錯的地方，還望大家可以指正，非常感謝。