网吧服务器配置

网吧服务器配置 一、概述 HACMP利用心跳报文来检测网卡故障。当确认网卡故障后必须检测是哪个节点的网卡 发生故障。如果节点的Local Network中有多块网卡，那么节点自己就可以检测网卡是否正 常。如果节点在network中只有一块网卡，也就是所谓的Single IP Adapter Node，那就需要 借助netmon.cf文件中定义的第三方IP地址来判断。 二、网卡故障检测和诊断 1， 网卡故障检测 HACMP利用心跳报文来检测网卡故障。根据HACMP的网络规划要求，同一个network 中的所有网卡，无论是否在同一个节点上，都必须连接到同一个VLAN。同一个节点上不同 网卡的base ip则在不同网段中，这样不同节点在同一个网段中的base ip就构成心跳环路。 所有节点向环路中的下一个节点发送心跳，并接收来自上一个节点的心跳。对于最常见的双 节点集群，就是相互发送心跳。 app db 环路boot1 net_ether_01 192.168.201.147 192.168.201.149 环路boot2 192.168.202.147 192.168.202.149 persistent ip 168.100.201.147 168.100.201.149 service ip 168.100.201.148 环路boot3 net_ether_02 168.10.200.147 168.10.200.149 tcpdump的输出如下，以环路app_boot2为例: 15:48:11.860869 IP app_boot2.topsvcs > db_boot2.topsvcs: UDP, length 76 15:48:11.860916 IP app_boot2.topsvcs > db_boot2.topsvcs: UDP, length 76 15:48:12.002725 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:48:12.861028 IP app_boot2.topsvcs > db_boot2.topsvcs: UDP, length 76 15:48:13.003120 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:48:13.861093 IP app_boot2.topsvcs > db_boot2.topsvcs: UDP, length 76 15:48:14.003417 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:48:14.861156 IP app_boot2.topsvcs > db_boot2.topsvcs: UDP, length 76 15:48:15.003812 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:48:15.003820 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 app_boot2和db_boot2周期性的向对方发送UDP心跳报文，告知对方自己还存活着。一 旦某块网卡发生故障，例如网线被拔出，则心跳环路中断。假设拔除app的环路boot2的网 线，db_boot2的tcpdump输出如下: 15:50:41.115013 IP app_boot2.topsvcs > db_boot2.topsvcs: UDP, length 76 15:50:41.248952 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:50:41.424412 IP app_boot2.filenet-nch > db_boot2.topsvcs: UDP, length 76 15:50:42.249006 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:50:42.249054 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:50:43.249154 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:50:43.919283 IP db_boot2.filenet-nch > app_boot2.topsvcs: UDP, length 76 15:50:44.249205 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 15:50:45.249260 IP db_boot2.topsvcs > app_boot2.topsvcs: UDP, length 76 从15:50:42.249006开始，只有db_boot2发向app_boot2的UDP报文，没有app_boot2 发给db_boot2的UDP报文，说明在这个时间点发生了故障。而app_boot2的tcpdump输出 如下: 15:51:09.268404 IP app_boot2.filenet-nch > db_boot2.topsvcs: UDP, length 76 15:51:09.268404是最后一条输出。说明在这个时间点发生了故障。db和app对于故障时 间点的误差来自于两者的时钟没有完全同步。通常检测网卡故障的时间大约为5秒 2， 网卡故障诊断 在检测到网卡故障后HACMP必须诊断是哪个节点的网卡发生故障，实际上是找到哪块 网卡无法和network中的其他网卡通信，无论它是否发生故障。因此仅仅判断网卡是否up 是不够的，可能up状态的网卡仍然无法和其他网卡通信。例如: SwitchASwitchB0012 en0en1en0en1NodeANodeB 图示中的SwitchA和SwitchB之间的连接如果中断，则NodeA的en0网卡就无法和其他 三块网卡通信，但是该网卡仍然处于up状态。 诊断网卡故障的基本方法是要求该网卡发送流量，并检测其他网卡是否能接收到该流 量。由于各个心跳环路之间无法路由，并且每个心跳环路中只有2个成员，因此就无法基于 IP协议来诊断，所以HACMP采用IP协议之下的ARP协议。每个节点的其他心跳环路中的 网卡发送ARP请求报文，要求本节点的另一块网卡，也就是有故障嫌疑的网卡应答。如果 没有收到应答，说明该网卡发生了故障。例如app_boot1的tcpdump的输出: 15:51:14.597228 ARP, Request who-has app_boot2 tell app_boot1, length 46 15:51:14.607445 ARP, Request who-has app_boot2 tell app_boot1, length 46 在发生故障大约5秒后，app的boot1网卡发送ARP请求报文，要求app的boot2应答， 但是始终没有收到期望的应答。而db_boot1和db_boot2的tcpdump的输出如下: boot1-->15:50:48.916923 ARP, Request who-has db_boot2 tell db_per, length 46 boot2-->15:50:48.916923 ARP, Request who-has db_boot2 tell db_per, length 46 boot2-->15:50:48.917140 ARP, Reply db_boot2 is-at 00:14:5e:db:15:8b (oui Unknown), length 46 boot1-->15:50:48.917140 ARP, Reply db_boot2 is-at 00:14:5e:db:15:8b (oui Unknown), length 46 因此HACMP就可以判断出是app_boot2发生了故障，将其上的persistent ip和service ip 切换到app_boot1。通常诊断网卡故障的时间大约为30秒。 3， Gratuitous ARP 在发生了网卡切换后必须通知同一网段的其他主机刷新ARP缓存，尤其是persistent ip 和service ip对应的MAC地址必须及时刷新。HACMP采用Gratuitous ARP技术来达成这一 目的。app_boot1的tcpdump输出如下: 15:51:32.607900 ARP, Request who-has app_per tell app_per, length 46 15:51:33.385751 ARP, Request who-has db_serv tell db_serv, length 46 app_boot1要求app_perv和db_serv应答ARP请求，而实际上它自己就是app_perv和 db_serv。 发送Gratuitous ARP的时间和hacmp.out中记载的swap_adapter事件的起始/终止时间吻 合: Aug 13 15:51:31 EVENT START: swap_adapter app net_ether_01 192.168.201.147 168.100.201.150 Aug 13 15:51:34 EVENT COMPLETED: swap_adapter app net_ether_01 192.168.201.147 168.100.201.150 0 4， 检测网卡恢复 在确认了故障网卡后就应该定期检测它是否恢复。db_boot2的tcpdump输出如下: 15:53:32.179352 ARP, Request who-has app_boot2 tell db_boot2, length 46 15:53:42.182777 ARP, Request who-has app_boot2 tell db_boot2, length 46 15:53:47.184554 ARP, Request who-has app_boot2 tell db_boot2, length 46 15:53:52.186235 ARP, Request who-has app_boot2 tell db_boot2, length 46 15:53:56.418150 ARP, Request who-has app_boot2 tell db_boot2, length 46 15:54:07.189705 ARP, Request who-has app_boot2 tell db_boot2, length 46 15:54:12.193176 ARP, Request who-has app_boot2 tell db_boot2, length 46 这可能并不是HACMP有意为之，因为app_boot2的MAC纪录被清空，所以在继续发 送UDP报文前必须先通过ARP协议获取app_boot2的MAC地址。 5， 三、Single IP Adapter Node 所谓Single IP Adapter Node就是在network中只有一个网卡的节点。IBM不建议采用这 种方法，除非配置了EtherChannel或者vritual Ethernet。 Single IP Adapter Node的问题之一在于无法区分Local Network Failure和Global Network Failure。由于节点在network中只有一块网卡，因此网卡故障就被升级为Network Failure。然而由于整个network中只有两块网卡，因此就无法区分是对方网卡发生故障，或 者是自己网卡发生故障，抑或是整个网络发生故障。因为所有这些故障的表现形式都是相同 的，都是无法接收到对方的心跳报文。为了处理这种情况，IBM要求配置netmon.cf。 netmon.cf不仅仅针对Single IP Adapter Node，也可以用于普通的HACMP配置，尤其 是双节点集群。network的每个网段在netmon.cf中都应该有一个仲裁IP地址，对于在network 中有N块网卡的节点，就应该有N+1个IP。其中多出来的那个IP地址就是service ip/persistent ip所在网段，通常也就是网关。netmon.cf在集群启动前就应该配置好，因为topsvcs只有在 启动时候才会读取这个文件。 四、