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自身的备份恢复机制恢复。如果辅助站点宕机，唯一的办法就是重新安装辅助站点；
- 在SCCM 1806引入了独立主要站点服务器的高可用方案
- 在SCCM 1810引入了中心管理站点及子主要站点服务器的高可用方案
- 站点服务器的高可用通过引入一个被动站点服务器实例完成，被动站点服务器实例使用与活动站点服务器相同的站点数据库及相同的内容库(Content Library)
- 处于被动模式时，站点服务器不会对站点数据库写入任何数据
站点系统角色
- 资产智能同步点
- Endpoint Protection点
- 注册点
- 注册代理点
- 回退状态点
- 带外服务点
这些角色本身不承担关键服务或相关服务对高可用性的要求较低，因此一旦涉及到的角色宕机，可以在层级结构中删除此角色并将此角色重新安装到新的服务器上。
ConfigMgr客户端
ConfigMgr客户端也提供高可用方案以在服务节点或自身出现问题时，尽可能的维持各项功能的正常运行，主要有以下几个方面：
- 客户端自治运行：
- 客户端和站点系统无需进行连续持久的信息交互，即使客户端暂时无法和站点系统正常通信也会按照已收到的配置信息按计划执行各类任务；
- 客户端能够感知到不可用的服务节点，并尝试从服务节点列表中尝试和余下的节点进行通讯以维持各类任务的正常运行；
-
客户端自我修复：客户端会定期评估自身的状态并在需要的时候自动修复各类组件；
- 客户端缓存信息：客户端会将配置信息和自身的历史任务运行状态等信息保存于本地的WMI命名空间内，并按照运行计划在必要的时候评估当前状态以执行客户端任务；
为读者提炼SCCM涉及的基础知识、注意事项、运行机制以及排错方法等信息是本系列文章的初衷，对于SCCM各组件及功能部署步骤方面的信息，网络中已有较多文章可以参考，因此本系列文章并不侧重于提供类似Step-by-Step的部署指南，还请见谅。同时由于个人能力和知识水平的限制，文中不免有纰漏和出错的地方，还望大家可以指正，非常感谢。
