换流站服务器系统

1、换流站服务器系统二次检修班 戴迪1.换流站服务器系统概述服务器指一个管理资源并为用户提供服务的计算机系统，通常分为文件服务器、数据库服务器和应用程序服务器。运行以上软件的计算机或计算机系统也被称为服务器。相对于普通PC来说，服务器在稳定性、安全性、性能等方面都要求更高，因此CPU、芯片组、内存、磁盘系统、网络等硬件和普通PC有所不同。换流站服务器系统是由服务器、磁盘阵列、网络通讯设备、控制保护主机等硬件构成的为站内运行人员提供设备运行信息的系统。目前，葛洲坝、龙泉、江陵使用同类型的服务器系统，团林站使用许继服务器系统。MACH2HCM200MACH2系统服务器与HCM200服务器区别1、MAC

2、H2系统服务器仅处理控制保护主机上送事件，HCM200服务器还需处理OWS与控制保护主机的事件交互。2、MACH2系统使用ODBC直接完成事件向数据系统的提交请求。HCM200通过解码控制保护主机的上送事件代码完成事件向数据库系统的提交。3、MACH2系统的服务器上程序可见，HCM200系统服务器程序不可见。2.服务器系统硬件结构1.CPU采用Intel至强Intel 至强处理器 和其他处理器的差别是，部分至强处理器带有QPI功能，可以多颗CPU协作。而I7之类的其他Desktop Computer处理器没有QPI。至强处理器和普通民用处理器的差别还有一个，至强支持内存智能纠错，就是ECC功能

3、，在大内存环境下，这个功能特性很显著，通常体现在24GB或者更高的内存下。1）MACH2主机的CPU是否支持以上特性？2）MACH2主机的多处理器系统与服务器上的多处理器系统有何差别、MACH2新型号主机与旧型号主机CPU有何差别？3）HCM200主机如何保证CPU内存数据交互的正确性？2.内存具有ECC纠错功能。ECC是“Error Correcting Code”的简写，中文名称是“错误检查和纠正”。ECC是一种能够实现“错误检查和纠正”的技术，ECC内存就是应用了这种技术的内存。1、MACH2主机内存是否支持ECC？3.存储采用磁盘阵列磁盘阵列（Redundant Arrays of I

4、nexpensive Disks，RAID。原理是利用数组方式来作磁盘组，配合数据分散排列的设计，提升数据的安全性。磁盘阵列是由很多便宜、容量较小、稳定性较高、速度较慢磁盘，组合成一个大型的磁盘组，利用个别磁盘提供数据所产生加成效果提升整个磁盘系统效能。同时利用这项技术，将数据切割成许多区段，分别存放在各个硬盘上。磁盘阵列还能利用同位检查（Parity Check）的观念，在数组中任一颗硬盘故障时，仍可读出数据，在数据重构时，将数据经计算后重新置入新硬盘中。1）MACH2及HCM200均使用数据卡存储数据，如何保证数据可靠性？4.配置两套冗余的服务器硬件上共配置两台相同的服务器，两台服务器互为

5、备用。2.服务器系统软件结构1.服务器操作系统MACH2系统使用的是Windows服务器操作系统。HCM200使用的是UNIX服务器操作系统。2.数据库系统MACH2系统使用的是SQL ServerHCM200系统使用的是Oracle3.服务器系统组成方式1）葛站、龙泉、团林服务器系统采用群集技术2）江陵站服务器系统采用镜像技术数据库镜像和故障转移群集最主要的差异就是提供了不同级别的冗余。数据库镜像提供的保护是数据库级别的，而群集提供的保护是服务器实例级别的。另一个主要差别就是在数据库镜像中，主服务器和镜像服务器是独立的 SQL SERVER实例，两个实例有不同的名称；而群集中的 SQL SE

6、RVER实例则使用相同的虚拟服务器名称和IP地址，而且无论哪个节点主持群集实例，虚拟服务器名称和IP地址始终保持不变。 因此，在服务器一级的数据库保护（程序需要同时访问统一服务器上的多个数据库），故障转移群集将是更适合的选择。但是，如果每次只须为一个数据库提供可用性，那么数据库镜像具有更多优势。数据库镜像不像群集那样需要专门的硬件，也没有共享存储介质失败的潜在危险。数据库镜像可以在最短时间内让备用数据库开始提供服务，其速度快于任何其它的高可用技术。1）群集使用心跳线（心跳线断掉会怎样？）2）镜像使用见证服务器（见证服务器故障会怎样？）4.服务器数据库及事件传送原理2.1MACH2系统事件流结构

7、分析MACH2事件流的事件由板卡及主机自身产生，之后送至MACH2主机的事件队列中并经过事件转发进程将事件送往SQL Server服务器中，SQL Server服务器接收到事件后在转发给运行人员工作站的人机接口程序（HMI）。2.HMI与数据库系统事件流分析现有MACH2系统均采用Intouch作为HMI程序。HMI程序从数据库中获取各种事件必须依靠Intouch集成的SQL访问管理器。下面将对SQL访问管理器如何配合服务器完成事件的传递进行详细分析。在HMI使用SQL Server数据库的步骤可分为如下3步：1）连接数据库连接SQL Server数据库使用函数SQLConnect，其语法格式

8、如下：ResultCode=SQLConnect(ConnectionID, ConnectString); SQLConnect() 返回一个值给 ConnectionID 参数，后续的所有 SQL 函数都将它用作参数。2）填写SQL脚本填写SQL脚本的工作由函数SQLAppendStatement完成，其语法格式为：ResultCode=SQLAppendStatement(ConnectionID, SQLStatement); SQLAppendStatement() 函数使用字符串得内容来追加 SQL 语句。返回值指出在函数调用过程中是否发生了错误。3）执行SQL语句返回结果SQLE

9、xecute 函数在脚本中运行 SQL 查询。其语法为：SQLExecute(ConnectionID,BindList,StatementID); 如果语句包含 SELECT，则 BindList 参数指定用于绑定数据库列与 InTouch 标记的“绑定列表”的名称。如果“绑定列表”为 NULL，则不进行任何关联标记的操作。利用以上三个函数可以完成SQL的连接，SQL语句的填写以及SQL语句的执行，从而实现HMI程序对SQL Server服务器的查询操作。3数据库系统与MACH2主机事件流分析MACH2主机事件的上送是由主机事件转发进程MainCPU_Event完成。该进程通过ODBC将事件

10、队列中的事件分别插入到数据库中的Point表及Event表中。当MACH2主机事件队列中有新事件产生时，MainCPU_Event进程将按照事件队列的优先级将新事件进行转发。由于需要将事件写入数据库中的表，故转发进程需向服务器请求执行相应的SQL语句才能完成上述功能。下面为利用数据库监视程序查看到的MainCPU_Event进程向数据库请求事件插入的T-SQL语句。declare p1 intset p1=2129275exec sp_prepexecrpc p1 output,NLogEvent,GG.S1.-A.FP1.1.PCIB.NODE.50.0,A,2011.05.10,00:48

11、:57:087,1,2,251,1,0,0,0,3,709,1,0,0,1,0,1,1select p14.MACH2主机与IO板卡事件流分析各IO板卡及MACH2主机产生的事件必须首先送入 MACH2主机的事件队列中，MACH2主机的事件队列按优先级共分为7个事件队列，事件按照自身所属的优先级被送往相应的队列中。MACH2主机内部事件流图如下：Hidraw自带的Himon工具可以查看到主机内每个事件队列的事件内容，每个事件队列总共可以存放2000条事件。事件队列能否发送数据还依赖于主机系统状态，若主机处于测试状态，此时事件队列内事件将变为0，主机事件无法发送且无法用Himon工具进行观察。5

12、.服务器常见故障分析及处理方法MACH2主机事件的传递过程需经过板卡至主机，主机至服务器，服务器至运行人员工作站这3个过程。任一过程出现故障均会导致事件异常。下面将以2011年5月10日江陵换流站出现的一次运行人员工作站事件刷新异常为例，对整个事件流故障排查方法做详细的介绍。1 HMI程序至SQL Server服务器事件流检查2011年5月10日00：25，江陵换流站Intouch界面事件列表内出现大量异常事件，事件列表出现刷屏现象，影响正常监盘。刷屏故障如下图。出现故障后，按照事件流的传递过程从上而下的查找故障源，首先应检查运行人员工作站Intouch程序运行是否正常，与数据库通讯是否有异常

13、。检查方法如下：1）点击事件列表中的滚动条按钮，或来回切换事件列表，引起Intouch向数据库发送事件查询请求。2）查看日志记录工具，判断Intouch有无正常获取数据。Wonderware Log工具界面如下图：利用Wonderware Log工具可以在Message栏内可以查看到Intouch内部的调试信息，帮助判断Intouch在执行过程中是否出现故障，此时由于现场数据在大量刷屏，若事件确实由服务器传送过来应能在Wonderware Log中找到相应的日志信息。从现场日志情况来看，Intouch正常的从服务器中获取到了事件数据，并且全部运行人员工作站均出现事件异常问题，故可以确定服务器至

14、运行人员工作站事件传递过程正常。2 SQL Servre服务器至MACH2主机事件流检查下一步需检查MACH2主机至服务器事件传递是否出现异常。启动SQL Server自带的监视工具SQL Server Profile会弹出如下事件监视选择窗口，如下图：SQL Server Profile集成于SQL Server数据库系统内，通过SQL Server Profile可以对数据库进行全面的监视，在选择监视的事件内容时对于江陵站应着重监视SQL脚本的执行。由于需要找出数据库内的异常事件是如和产生的，所以应在显示列中选中client process id列，以此来区分MACH2主机。选择好后即可启

15、动SQL Server Profile的监视功能。下面对监视到的数据进行分析，第一栏为事件类型，由于MACH2主机均依靠调用服务器上的存储过程完成相应的操作，故事件类型应为远程过程调用（RPC），从监视到的实际事件信息可以看到，事件类型均为RPC。第二列TextData的内容非常重要，也是分析问题的重点，在TextData列内可以查看到MACH2主机向服务器提交上来的SQL语句，由提交的语句可以判断出MACH2主机想要在服务器上执行的操作。从监视界面中，可以找到关于ACP7B主机的事件提交记录如下：exec sp_execute 1,GG.S1.-A.CP7.1.B.PCIA.NODE.956

16、.39,B,2011.05.10,00:47:53:467,0,0,242,12,1,0,0,1,21,0,1,1,0,0,1,1这一串信息是存储过程LogEvent的参数，每个参数的意义均可以在Logevent中找到，在这里仅介绍与本次故障相关的参数并对以上语句进行简要分析。第一个1并非参数，它是Logevent存储过程进行预编译后的编号。故以上语句可以改写为：exec sp_execute LogEventGG.S1.-A.CP7.1.B.PCIA.NODE.956.39,B,2011.05.10,00:47:53:467,0,0,242,12,1,0,0,1,21,0,1,1,0,0,1

17、,1后面的参数中第一个参数为PointID，它是区分不同事件的唯一依据。从PointID内可以查看到该事件由ACP7B发出。结合现场实际，江陵站内并无ACP7B主机，故可以确定该事件属于异常事件。该事件类型为RPC，且执行成功，表明异常事件是由MACH2主机向服务器发出。另外，第8个参数为事件的内容，当事件为背景更新事件时该参数251，由于背景更新事件发送的频率很高，所以对该参数为251的事件应略过，本事件的参数为242，表明该事件不是背景更新事件，该事件会送往OWS上的人接口程序。由此判断本事件正是OWS上的异常刷屏事件。由于江陵站全站的MACH2主机均使用相同的Windows账户登录到SQL Server，故无法通过用户信息判断异常信息是由哪一台MACH2主机发出。仔细检查事件信息的其它列，发现仅能通过Client Process ID列区分出异常的MACH2主机。异常事件的提交者的本地进程ID号均为1972。此时已能确定异常事件是由转发进程号为1972的MACH2主机发出。现场对ACP71至ACP76共6台主机进行检查，发现ACP74主机的事件转发进程MainCPU_EVENT的本地进程ID号恰为1972，表明本次异常