新闻报道中总是出现亲兄弟为了财产闹得反目成仇，今天讲一个WinCC冗余服务器的故事。
2010年下半年，一条处理线用到了比较特殊的自动化系统。一台S7-400，一台S7-300F，一台TDC，一对WinCC冗余服务器，四台WinCC客户机。特殊之处在于使用WinCC冗余服务器与TDC通讯。熟悉TDC的工程师应该知道，TDC与上位机走以太网通讯有两种途径：一是通过S7协议下的TCP/IP单元；再就是购买TDC PMC TCP/IP的软件加授权。我们采用前一种方式，WinCC与S7-400和S7-300F走S7协议下的Industrial Ethernet单元，这样工厂总线上就跑着两种协议。
项目调试到后期，服务器/客户机一直运行稳定，应客户要求组态变量归档，变量有S7-400的，也有TDC的。激活归档功能之后，运行正常。
第二天凌晨接到现场电话说四台客户机都连接不上服务器，服务器上弹出要求重启的对话框，因为不能停机太久，让现场维护人员截了屏幕，重启服务器后恢复正常。天亮后过去看了截图，第一反应是操作系统的原因，趁着停机查杀了病毒，很干净，保险起见，恢复了服务器操作系统。稳定运行至晚上下班。
第三天凌晨现场又来电话，再次出现了同样问题，重启后正常。故障是可重现的，那就好办了。我们用系统的事件查看器寻找，有一条错误信息比较显眼，大致意思是在故障发生时刻CCTlgServer.exe进程意外结束。CCTlgServer.exe是WinCC变量归档进程，为什么会意外结束呢？致电西门子热线，打包WinCC安装路径下Diagnose文件里的log文件，发送过去。当天下午就有工程师回电，说在log文件中找不到备用服务器的计算机名（两台冗余服务器的计算机名分别是ServerA和ServerB），系统是用GHOST镜像对拷后再改名的，西门子工程师建议我ServerB不要使用ServerA的完全镜像，PCS 7的文档里面也提到更改计算机名应该在安装SQL Server之前进行。虽然不太确定是不是这个原因，我们还是满怀信心地重新部署了ServerB的系统和软件。
第四天凌晨没来电话，高兴地去现场，问起维护人员，他们说故障又重现了，但重启就好了，也就没打电话吵我们。当时小小感动了一下，不过觉得压力更大了。这一次没有联系西门子，在诊断文件中寻找线索。在WinCC_Sys_01.log文件中找到一条冗余故障信息，同时在WinCC消息归档中也找到CCTlgServer出错消息。于是将故障源头锁定在变量归档设置上，联想到故障重现的周期是一天不到的时间，检查了归档片段大小、时间的设置，还使用网络监测软件检查了网络是否堵塞，减少了一些不是很必要的变量归档。能设置的地方都使用了最保守的选项。
又过了一天，问起维护人员，他们很轻松地说“挂了，重启就好了”，虽说是开玩笑的语气，但无形之中还是给了我们很大压力。变量归档的设置、跟冗余相关的选项都只有那么几个，按照文档的推荐，恢复默认值，减少归档变量，这些尝试都做过了。由于生产需要，我们也不再做更多的尝试，取消了变量归档，保生产为先。故障不再重现，我们的捉虫运动也陷入僵局。
生产期间，不断在西门子技术支持的英文论坛上搜索，碰到类似的案例，没有完全相同的，都没有较好的最终解决方案。偶然发现有位外国专家提供了PCS 7系统报警消息列表的Excel文件，下载之后打开，找到1012240消息的解释：内容是“因为某个应用出错，在应用程序健康性检查中触发冗余切换”，动作是“通知服务人员检查冗余服务器状态，应用程序健康性检查监视服务器的主要任务，一旦出错便弹出窗口要求重新启动”。这下算是找到弹窗故障的官方解释，但变量归档为什么会被检查为“不健康”呢？
一天闲着时，我呆坐在两台服务器前面，由于在生产，不能做任何尝试。前面说到TDC与WinCC是通过TCP/IP通讯的，我就在两台服务器的CMD里面输入命令ping 192.168.1.1 -t，比较两台服务器ping通TDC的结果，结果令人惊讶，每次ping的延时都在2~20ms之间，两台服务器之间差异更明显。会不会是延时波动太大导致两台服务器归档的变量不同呢？停机时，我再次激活了变量归档，但是删除了里面所有TDC传过来的变量，只留下S7-400的变量。这一次，我半开玩笑的对维护人员说，“放心吧，这一次再也不用你们凌晨来重启服务器了”。
经过一周时间的考验，服务器一直稳定运行。于是将需要归档的变量全部集中到S7-400中，算是解决了变量归档的问题。
后来不断分析总结，我认为：TDC传给两台服务器的变量因为TCP/IP延时波动，导致两者归档数据中出现“同时不同值”（尝试过打开SQL数据库对比，但WinCC数据库是经过压缩的，最终无果），一段时间后，WinCC冗余的“应用程序健康性检查”检查变量归档数据库时发现了这些差异，无法判断谁的数据库是正确的，于是报错，服务器挂掉后导致客户机瘫痪。
其实，一对冗余服务器就像一对双胞胎，有着不同的名字（计算机名），依靠着父母长辈（下位机）服务着弟弟妹妹（客户机），兄弟俩心有灵犀（冗余监控）、互通有无（冗余同步）、齐心协力（冗余切换），一旦父辈们厚此薄彼、沟通不畅，其结果兄弟互掐、晚辈遭殃。机器尚如此，又何况人呢。

后来了解到计算机领域对冗余服务器类似故障有专门的名词，更加拟人化。
1、主服务器当机后，备用服务器因为各种原因没有切换为主服务器，此时没有主服务器，客户机瘫痪。一般叫“无脑”NoHead或者LossHead。故事中就是这种现象。
2、备服务器监视着主服务器，如果突然检测不到对方，超时后认为对方当机，便自己切换为主服务器，但是原主服务器并未当机，此时客户机不知与哪台主服务器通讯，导致系统崩溃。一般叫“脑裂”SplitHead。也有戏称为“双头蛇”的。

文中提到的部分截图：
1.网络结构



2.网络结构2



3.弹窗故障



4.日志文件



5.消息系统



6.系统消息列表