磁盘柜双机热备硬件解决方案样本.doc

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。
磁盘柜双机热备硬件解决方案

磁盘柜双机热备硬件解决方案 　　　　　Linux下的高可用性方案　　　　　　　　
一、 概述:
　　IBM EXP300是IBM公司在SCSI产品上的主力存储设备, 它采用单独的RAID卡的方式, 有效的保障了数据的安全性。在双机热备方案是稳定性领先业内其它磁盘阵列及磁盘柜方式, 主要的优点表述如下:
双机双RAID卡方式能够有效的避免一个RAID卡或一个磁盘阵列控制器损坏带来的数据丢失, 安全性比同类产品要高。
　　同时IBM的Server RAID卡同其它RAID卡不同, 其它厂商的RAID卡在做双机的情况下能够在两台服务器上同时看到EXP300上的磁盘, 这样现在市场上的大部分双机热备软件就能够支持它。但它带来的问题依然严重, 一方面是硬件的兼容情, 其它厂商的RAID卡同EXP300存储一点兼容性方面的问题。
因此说, IBM的产品系列有着较高的可用性及安全性, 但由于存在这种两台主机只能由一台主机看到磁盘柜的原因, 因此市场上大部分双机热备软件不能支持IBM EXP300这样的系统。现在市场上能够支持此系统的是MS Advance Server Windows 本, 能够有效的支持IBM EXP存储系统, 从而使这样一套优秀的产品能发挥其应有的作用。

二、 双机热备的特色
一: 基于双机热备的方案的产品特色, 能够被CLUSTER保护的资源有:
1: 卷( Volume)
2: IP 地址
3: 共享文件
4: 管理器服务器名称
5: 应用程序(数据库)
6: IIS SERVER
7: Exchange Server (企业版)

二: 心跳故障检测
Cluster在集群节点间保持着间歇的通信信号, 也就是心跳信号, 是错误检测的一个机制。即经过优先级别的通信路径, 在两个对等系统之间进行周期性的握手,如果连续没有收到的心跳信号到了一定的数目, 就经过第二条路径确定是系统故障还是只是通信路径有问题。如果只是路径问题, 就会把第一条路径标示为失效。如果第二条路径检测仍失败就会自动实现磁盘柜和应用软件的接管功能。
一般情况下现在使用网络的接口作为通信路径, 一块网卡专门用来进行心跳检测, 而把局域网通信的网卡作为备用的路径。

三、 软件拓扑
以下是结合IBM EXP300产品的拓扑结构:

四、 硬件配置
序号 名称 型号 描述 单价 数量 总价
1 服务器 IBM X255
8685-CRX Xeon MP 3.0GHz/4MB,4-SMP 1GB Chipkill, 0HDD,12HDD ASMP 7Active PCI Lightpath 10/100/1000Ethernet 24XCD 7U Rack ￥101000 2 ￥20
CPU Xeon MP 3.0GHz/4MB Processor ￥46000 2 ￥9
内存 512MB PC1600 ECC DDR DIMM ￥ 4 ￥8000
RAID卡 IBM ServerRAID-4Mx Ultra160 Adapter ￥6000 2 ￥1
硬盘 73.4GB U160 10,000rpm Hot-Swap HDD ￥4200 4 ￥16800
网卡 Gigabit SX Ethernet Adapter ￥4000 2 ￥8000
小计: ￥338800
2 磁盘阵列柜( SCSI) EXP300 EXP 300 Storage Expansion Unit/HDD ￥21000 1 ￥21000
硬盘 73.4GB U160 10,000rpm Hot-Swap HDD ￥4200 8 ￥33600
SCSI线 2m SCSI Cable ￥800 1 ￥800
小计: ￥55400
合计: ￥394200
注: 以上价格仅供参考

Linux下的高可用性方案
　　保证持续稳定的系统运行时间变得越来越重要, 而传统意义上的小型机系统让普通用户望而却步。用户需要的是更高的可用性以及更低的成本。高可用性(HA)技术能自动检测服务器节点和服务进程错误、 失效, 而且当发生这种情况时能够自动适当地重新配置系统, 使得集群中的其它节点能够自动承担这些服务, 以实现服务不中断。

　　Cluster应用可分为三方面: High-Availability(HA)(高可用性集群)、 Load Balance(负载均衡集群)、 Scientific(科学集群)。在集群的这三种基本类型之间, 经常会发生混合与交杂。于是, 能够发现高可用性集群也能够在其节点之间均衡用户负载, 同时仍试图维持高可用性程度。同样, 能够从要编入应用程序的集群中找到一个并行群集, 它能够在节点之间执行负载均衡。而本文则侧重于介绍基于Linux的HA解决方案方面的问题。

　　基于LVS的HA方案 Linux要进入高端市场就必须在这方面有相应的措施, 因此许多公司都在这方面加大了研究力度。现在, 我们能够使用一些现存的软件去构筑具有高可用性的LVS系统。下面列出两种方案, 以供参考。 　　

［方案一］mon+heartbeat+ fake+coda

　　我们能够使用”mon”、 ”heart beat”、 ”fake”和”coda”四个软件来构筑具有高可用性的Virtual Server(虚拟服务器)。”mon”是一个大众化的资源管理系统, 用来监控网络上的服务器节点和网络服务。”heartbeat”实现在两台计算机间经过在串行线上使用UDP协议传送”心跳信息”。”Fake”是一个使用ARP欺骗的方法来实现IP接管。

　　当服务器故障时, 处理过程如下: ”mon”进程运行在负载均衡器上, 负责监测整个集群的服务器节点和服务进程。在配置文件”fping.monitor”中写入要检测服务器节点, 然后”mon”进程将会隔t秒检查一下相应的服务器节点是否还活着。

　　另外相关的服务监视器也要做相应的配置, 这样”mon”进程将每m秒检测一下所有节点的相应服务进程。例如: http.monitor: 用于配置监控http服务; ftp.monitor: 用于配置监控ftp服务; 以此类推。当配置完成后, 某个服务器节点失效或重新生效、 服务进程失效或重新生效时都会发送一个通告信息, 因此, 负载均衡器能够知道服务器节点是否能接受服务。

　　现在, 负载均衡器成为了整个系统的单点失效。为了防止这一现象, 我们必须安装一个负载均衡器的备份服务器。”fake”软件实现当负载均衡器失效时, 备份服务器自动接管IP地址, 并继续服务。而”heartbeat”则随时根据负载均衡器的状态自动激活/关闭备份服务器上的”fake”进程。在负载均衡器和备份服务器上都运行着一个”heartbeat”进程, 它们经过串行线周期性地发送”I'm alive ”消息。如果备份服务器在一个预定时间内接收不到来自负载均衡器的”I'm alive”信息时, 将自动激活”fake”进程接管负载均衡器的IP地址, 并开始提供负载均衡服务; 而当再次收到来自负载均衡器的”I'm alive ”消息时, 备份服务器将自动将”fake”进程关闭, 释放出它接管的服务器, 负载均衡器重新开始工作。

　　可是, 如果负载均衡器在客户正在请求时失效, 这时会引起客户请求失败, 客户必须重新发出请求信息。 　　”coda”是一个容错的分布式文件系统, 源于Andrew文件系统。服务器上的目录能够存储在”coda”上, 因此文件能够实现高可用性, 而且易于管理。

［方案二］ldirectord+heartbeat

　　”ldirectord”(Linux Director Daemon)是Jacob Rief编程实现的一个独立进程, 以实现对服务和物理服务器的监测, 广泛地用于http和https服务。

　　”ldirectord”安装简单, 能很好地与”heartbeat”配合工作。”ldirectord”程序包含在”ipvs”包中的”contrib”目录中。

　　以下是”ldirectord”的一些优点:

　　”ldirectord”是专门撰写的LVS监测程序。

　　它从/etc/ha.d/xxx.cf文件中读取所有关于IPVS路由表的配置信息。当”ldirectord”运行起来后, IPVS路由表将会被适当地配置。

　　能够将Virtual service配置放在多个配置文件中, 因此能够单独修改某一种服务的参数, 而不影响其它的服务。”ldirectord”能被”heartbeat”轻松地管理----启动、 关闭。

　　将”ldirectord”放到/etc/ha.d/resource.d/目录下, 然后在/etc/ha.d/haresources中增加一行: 　　node1 IPaddr::10.0.0.3ldirectord::www ldirectord::mail

　　”ldirectord”能够手动开启、 关闭。能够在无备份负载均衡器的LVS集群中使用它。

　　Xlinux的LATCH HA方案 正如前面所述, 高可用性解决方案(HA)是极为重要的, 许多厂商为此投入了大量的研究。其中, Xlinux发行版就提供LATCH HA解决方案。下面我们就一起看看LATCH HA方案。

　　LATCH HA解决方案的最典型的系统结构: 两台主机A、 B共享一个磁盘阵列, A为工作机, B为备份机。它们之间用一根心跳线来连接, 这称为”心跳检测”, 主要经过一条RS232检测链路来完成。LATCH HA也采用了用Ping来验证系统宕机的方法。安装在主机上的HA软件经过心跳线来实时监测对方的运行状态, 一旦正在工作的主机A因为各种硬件故障导致系统发生故障, 主机B立即投入工作。怎么样, 与IBM的HACMP有点像吧!

　　LATCH HA实现了”高可靠性共享存储”架构。该架构由两个或三个冗余服务器、 一个共享冗余磁盘阵列、 一个可选DBMS及LATCH HA系统软件构成。在LATCH HA的保护下, 企业的计算机系统能够提供不间断的信息服务, 避免由于硬件故障或日常维护所带来的宕机, 因而能够保障最佳的可靠性及最大程度地减少宕机时间。

　　方案应用

　　LATCH HA能够应用在各种集中式、 客户机/服务器模式或OLTP系统中。同时其与市场上各种主流的数据库系统与OLTP软件(如: Oracle、 SYBASE、 Informix、 Tuxedo)也都保持兼容。LATCH HA同时提供了各种应用程序接口。因此, 客户能够在其私有软件中集成各种功能来保证系统的高可靠性。

　　LATCH HA /HS 在线待机模式

　　在这种模式下, 一个服务器作为主服务器。正常情况下其承当所有的服务。另外一台服务器作为待机服务器(正常情况下除了监控主服务器的状态, 不进行其它的操作)。一旦主服务器宕机, 待机服务器就接手工作, 成为新的主服务器。客户依然能够拥有同样的服务器IP地址、 NFS、 数据、 数据库及其它……这种应用模式近似于上面介绍的典型应用模式(两台服务器实际上是在完成同一个功能应用), 安装在主机上的HA软件经过心跳线来实时监测对方的运行状态, 一旦正在工作的主机A因为各种硬件故障, 如电源失效、 主要部件失效或者启动盘失效等导致系统发生故障,主机B立即投入工作。

　　LATCH HA /DA 双机就绪模式

　　在这种模式下, 两个主机都作为主服务器, 共享自己的磁盘阵列, 各自承当一部分服务。例如: 服务器A在执行应用A, 服务器B在执行应用B, 两个主机在正常情况下各自独立运行自己的应用逻辑, 两个主机同时又都作为对方的待机服务器, 经过心跳线监控对方的状态。一旦某一服务器宕机, 另一台服务器就承担所有的服务, 为所有的客户服务。一旦服务器A发生故障, 服务器B马上接管服务器A上原来的应用; 或者服务器B发生故障, 服务器A马上接管服务器B上原来的应用, 这是一种互为冗余的模式。

　　很明显, 一旦某一服务器宕机, 另一台服务器的工作负担就比较重, 于是就有了三主机模式。

　　LATCH HA /HC 三主机模式

　　这种应用模式是最高端的HA应用模式, 它既保证了系统的设备冗余, 避免系统宕机, 而且又能保证在一旦宕机的情况下有足够的系统资源可供使用。

　　在这种模式中, 待机服务器C同时监控主服务器A与B的状态。一旦服务器A或B宕机, 服务器C将承担其服务, 为客户服务。这种系统结构既保证了系统的安全运行, 又保证了系统资源。

　　Linux HA的解决方案当然不限于上述两种, 但其核心思想是一致的, 即提供不间断的服务。近年来随着Linux操作系统不断走向成熟, 功能不断增强, 特别是其遵循GPL和标准化的PVM、 MPI消息传递机制的特性和在普通PC机上越来越好的高性能网络的支持, 所有这些为基于Linux的集群系统的发展提供了坚实的技术基础, 在把技术转化为具体的应用过程中, 高端的HA应用以其稳定可靠的性能和与Unix相比价格上的优势而脱颖而出。随着基于Intel平台的服务器业已成为关键性业务和应用的主流服务器, Linux HA集群技术的应用亦将日益广泛。

HA集群结构图

　　HA实际上是两台(或更多)计算机经过一定方式互相监听, 实现热备份。当其中Primary server出现问题时, Standby server能够自动立即接替工作, 使用户感觉不到停机。在Primary server恢复正常之后, Standby server又会把工作还给Primary server。