解决由于意外断电引起的活动目录服务停止问题

背景：

    位于集团B座6楼的机房已经使用多年，很多硬件条件开始制约公司IT的发展。6月中旬一天，由于机房空调进行维修，工人师傅冒然拉断了电源总闸，导致机房内部分服务器意外断电。集团总部的两台用活动目录域控制器也不幸遇难。

现象：

    负责机房的工程师在第一时间进行了及时的处理。恢复供电之后马上启动因断电而停止的服务器。在绝大部分服务器启动运行之后，仍然发现多数客户端出现各种网络访问类问题。如某些网站无法访问，但用PING命令测试确能够返回正确信息；或者网络共享可以通过IP访问而无法通过机器名进行。

问题：

    综合大部分出现的现象，初步判断为DNS服务不可用。通过命令检测及日志分析，发现两台DC虽然已经启动，但并没有正常对外提供服务。

    经过仔细分析AD相关日志发现，由于两台DC均为突然断电，在一台DC停止服务时没有能够正常通知另外一台DC继续承担负载。并且，两台DC同时开机时，无法获取另外一台服务器状态信息。导致两台DC均认为自己是当前AD中最后一台DC，从而使两台DC之间的复制关系发生了冲突，进而导致最后的整个AD服务的不可用，这里就包括之前的DNS服务不可用。

解决办法：

    由于目前AD服务已经完全中断，所以考虑重启DC是否带来AD服务中断已经没有意义。

    关闭全部两台DC之后，先开启具有五种操作角色的DC-01。待完全启动之后，检查AD相关日志，确保AD各项服务均已正常启动。如遇到活动目录复制相关警告或报错，暂时不管。

    待第一台DC成功启动以后，开启第二台DC。完全启动之后，检查AD相关日志，确保AD各项服务均已正常启动。

    在DC-01上打开活动目录站点管理控制台，在所有的复制关系上手动进行立即复制，并监视事件日志。

    当日志中已发现站点复制成功完成之后，重启两台DC，以确保服务和数据的刷新。

    重启顺序为，在保证DC-01正常工作的同时，先重启DC-02；等DC-02重启完全并正常提供服务之后，再重启DC-01。

    如果此时发生站点复制失败，那问题就大了，这里还好我没遇到，所以也暂时排除这个问题。（站点复制失败，需要另案处理，请参考相关的标准排错流程，或者直接找微软GTSC开Case处理）

结果：

    在完成两台DC重启之后，从重启时间点算起，两台DC在之后的时间内均没有再次发生活动目录复制相关警告和错误。所有AD相关服务也全部正常启动。

    通过其他服务器及部分客户端进行测试，发现DNS解析服务已经恢复正常，用户登陆到域操作正常，用户之间文件夹共享访问正常，AD中搜索打印机、计算机、用户等AD对象也同样正常。

    在之后的一两周的运行中，没有再发生由AD服务引起的系统问题。

    至此，我们可以认为AD服务已经完全恢复正常工作。

总结：

    对于一个分布式系统而言，各个系统组件之间都存在着相互依赖的关系。整个系统的关闭和开启，都需要依照一定的顺序执行。无论是恶意还是无意，几乎同时的突然断电对于一个分布式系统而言，各组件之间没有任何的消息沟通就停止服务，会引起其它组件之间的服务停止，或者服务冲突，这种损害是极大的。

    值得庆幸的是，同时的电力中断，在大部分情况下，不会引起存储设备中的数据丢失。在这次事件中，至少AD数据经过检查之后，没有发生丢失的情况。但也不是完全绝对，运气的成分很大。

    所以，保证电力系统的高可用，是保证IT稳定运行的最为基本的准则。此外，万一出现电力系统失败，我们应该按照一定的启动顺序来依次开启分布式系统中的各个组件，而不能同时打开所有的服务器，特别是在某些存在有存储设备相连接的环境中显得尤为重要。

本文出自 “Bisheng.Hu” 博客，请务必保留此出处http://bisheng.blog.51cto.com/409831/171780