服务器ac重启和dc重启的核心区别在于：ac重启是应用层服务的重新加载，dc重启是域控角色的整体下线再上线，前者的影响范围通常局限在单一业务，后者的影响会波及相关域内所有成员服务器的认证和信任关系。
先搞清楚ac和dc分别是谁
很多运维同行在排查故障时，经常把ac重启和dc重启混为一谈,实际上这俩兄弟性格截然不同。
ac在大部分场景下指无线控制器，负责管理AP设备、下发配置、处理漫游和认证，常见的有H3C的AC、华为的AC、思科的无线控制器，你办公室里那些Wi-Fi信号能不能无缝切换，无线终端能不能正常拿到IP,基本都是ac在背后调度。
dc指的是域控制器，也就是Windows Active Directory环境中的核心角色，它负责整个域的账号认证、组策略下发、DNS解析以及域内信任关系的维护，你的员工登录电脑输入的域账号密码,就是由dc来验明正身的。
搞清楚这两者的身份定位，再去理解它们各自重启带来的影响,就顺理成章了。
ac重启和dc重启的本质差异
重启对业务连续性的影响范围不同
ac重启，波及的是无线网络覆盖下的所有终端，比如你在一家商场里面，ac重启的几十秒到几分钟内，所有连接Wi-Fi的收银机、访客手机都会出现短暂的断网或漫游重连，但好消息是，ac重启通常不涉及服务器端数据，业务系统本身不受影响,终端重新连上之后一切照旧。
dc重启，波及的是整个域环境下的所有成员服务器和客户端，域内每台服务器的Kerberos票据默认有效期是10小时左右，dc重启期间，已经拿到有效票据的机器还能继续干活，但新登录的请求、跨服务器的身份验证、组策略刷新这些动作基本上都会失败。
重启的故障恢复逻辑不同
ac重启更像是一次软件层面的重新初始化，把无线控制器的进程杀掉，重新加载配置文件，让AP重新建立CAPWAP隧道，业内专家指出，大多数ac设备重启后能在几分钟内恢复无线服务，配置通常在本地flash或远端服务器有备份,恢复逻辑相对简单。
dc重启则要复杂得多，域控制器重启后，需要等待AD数据库（NTDS.dit）完成一致性检查，SYSVOL目录需要和域内其他dc做复制同步，DNS服务需要重新加载区域文件，整个恢复到稳定可用的状态,往往需要比其他服务器更长的时间。
重启的风险等级完全不一样
| 对比维度 | ac重启 | dc重启 |
|---|---|---|
| 影响范围 | 无线终端 | 整个域内所有服务器和客户端 |
| 恢复时间 | 几分钟内 | 可能持续10-30分钟甚至更久 |
| 风险等级 | 低-中 | 高 |
| 常见触发方式 | 配置变更、固件升级、web管理界面操作 | 补丁安装、灾难恢复、系统迁移 |
| 是否影响服务器数据 | 一般不影响 | 可能影响AD数据库一致性 |
ac重启实操指南
什么时候需要重启ac
不是所有无线问题都靠重启ac解决，实际场景中,遇到以下情况才考虑动它：
- 无线终端大面积掉线，且AP侧排查没有问题
- ac设备web管理界面无响应，但设备还能ping通
- 配置变更后部分AP无法正常上线
- 固件升级或版本回退
ac重启的标准操作路径
H3C的AC设备,常见的重启方式有两种：
命令行方式：登录设备后执行reboot命令，系统会提示确认是否重启，输入Y确认即可，如果需要跳过配置保存提示，可以先执行save force强制保存当前配置,再进行重启操作。
Web管理方式：登录ac的web界面，通常在”系统管理”或”设备维护”菜单下，找到”重启设备”选项,点击后根据页面提示二次确认。
无论用哪种方式，重启前都建议先备份配置文件，H3C的AC可以用backup startup-configuration to tftp://服务器地址/文件名这样的命令把启动配置备份到TFTP服务器上。
ac重启后的验证清单
重启完成后，不要急着说搞定,按下面几步验证：
- 查看AC运行状态是否正常，用
display device确认没有报错 - 查看AP在线状态，
display wlan ap all确认所有AP是否已重新上线 - 检查无线用户是否能够正常关联和获取IP地址
- 用一台无线终端实际测试漫游和上网是否正常
dc重启的完整操作流程
什么时候必须重启dc
dc重启不是一个可以随意做的操作，必须谨慎,以下几种场景属于合理需求：
- 安装Windows补丁后系统要求重启完成更新
- 域控制器出现内存泄漏或系统资源耗尽
- 需要迁移或降级域控制器角色
- 执行灾难恢复流程中的部分操作
多dc环境下的重启顺序和策略
如果是多dc环境，重启前要先确认当前域内还有其他可用的域控制器，行业共识认为，在多dc环境中，一次只重启一台dc是最基本的安全原则,操作顺序如下：
- 用
net time /domain确认当前时间同步正常 - 用
repadmin /replsummary检查dc之间的复制状态，确保没有积压的错误 - 在计划时间内，选择业务低峰期执行重启操作
- 重启完成后，观察事件查看器中的Directory Service日志
- 用
dcdiag /test:replications验证复制功能恢复
如果只有一台dc，重启的影响就大得多了，所有域用户登录、DNS解析都会中断,所以这种场景下宁可选择深夜或者周末操作。
dc重启后容易踩的坑
坑一：SYSVOL共享没有完全就绪。 重启后如果SYSVOL共享还处于”正在初始化”状态，直接对外提供认证服务，有可能导致组策略应用不一致，正确做法是等待netlogon服务完全启动后再对外提供服务，可以使用net share查看SYSVOL共享是否已经发布。
坑二：长时间没有重启过，重启后反而出问题。 一台dc运行了数百天没重启过，AD数据库碎片积累、DNS缓存异常等问题可能会在重启后爆发，这种情况下，建议提前做好系统状态备份,确保可以回滚。
坑三：单dc环境下，重启前没有做系统状态备份。 系统状态备份包括AD数据库、SYSVOL、注册表和系统引导文件，没有这个备份兜底，一旦重启后AD库损坏,恢复难度极大。
从故障案例看ac和dc重启的不同应对方式
举个例子来说明两者的区别，在一家连锁零售企业的网络运维中，某天门店反馈收银系统大面积无法打单，POS机连接不上后台服务器，运维人员排查后发现，是总部机房的无线控制器ac出现了死机，导致门店的无线网络全部瘫痪，处理方式是重启ac设备，整个过程用了大约5分钟,收银系统恢复正常。
另一家企业的场景就没这么轻松了，某天早上员工们陆续反馈，办公电脑登录时一直提示”域不可用”，密码正确也进不去系统，排查发现是数据中心的一台域控制器dc在凌晨做过系统补丁自动更新后，重启时AD数据库出现了异常，导致整个域内的认证服务中断，这次故障处理持续了将近两个小时，期间所有依赖域账号登录的办公终端、文件服务器访问、邮件客户端全部受到影响。
同样是重启，ac重启影响的是无线链路的可用性，范围是局部且短时的；dc重启影响的是整个身份认证体系的根基，范围是全局且长时的，如果预算允许，或者你的业务本身就重度依赖无线网络和域环境，可以考虑采用双ac热备和双dc冗余部署,从根本上降低单台设备重启带来的业务风险。
关于服务器重启常见的三个疑问
ac重启和dc重启哪个更频繁
正常情况下，ac重启的频率会高于dc重启，ac设备因为承担着大量无线终端的接入管理，资源占用波动较大，偶尔出现异常需要重启来恢复；dc作为核心身份认证服务器，本身设计就是要求高稳定性的，不应频繁重启，一个健康的IT环境中，dc的重启频率应该控制在每年几次以内,且多数是因为补丁安装或系统升级。
重启ac或dc前必须备份哪些内容
ac重启前，备份配置文件就足够了，命令和路径在前面已经提过，dc重启前，除了备份系统状态之外，还需要记录当前域内的DNS区域配置、组策略对象数量、以及所有域管理员的账号信息，这些信息虽然不是直接备份内容,但重启后做一致性验证时用得到。
虚拟化环境中的dc重启和物理服务器dc重启有区别吗
两者没有本质区别，但虚拟化环境中的dc重启在某些情况下恢复更快，虚拟机快照功能可以在重启前打一个快照，如果重启后AD状态异常，可以快速回滚，需要注意的是，不建议直接对多台dc同时执行快照回滚，这容易引发USN回滚问题，导致域内复制混乱,操作时保持同一版本即可。