现在看起来蛮easy的问题，可是当初俺是菜菜哦。不过说起来，要讲清楚这个问题也是蛮考察功力的哦。好了，俺把俺研究的东东分享一下。

集群一般有两种：高可用和高性能集群，一般的集群，包括现在的低端双机容错、IBM的HACMP、HP的MC ServiceGuard都是高可用性集群，不能做负载均衡；而高性能集群主要是科学计算、科研等一些特殊环境用，在现实应用中比较少。而ORACLE 的RAC是基于特殊环境下的应用系统，要求有操作系统层面的分布式锁（DLM)。具体使用起来要作相应的规划，而且不能随便使用，弄不好性能适得其反的差。

前面说过，负载均衡不能完全算高可用性集群的一种，是高性能性集群，普通的HA软件没办法支持象ORACLE RAC一样的环境，这不完全是集群软件的功能。

高可用性集群与负载均衡集群的工作原理不同，适用于不同类型的服务。通常，负载均衡集群适用于提供静态数据的服务，如HTTP服务；而高可用性集群既适用于提供静态数据的服务，如HTTP服务，又适用于提供动态数据的服务，如数据库等。高可用性集群之所以能适用于提供动态数据的服务，是由于节点共享同一存储介质，如SAN阵列。也就是说，在高可用性集群内，每种服务的用户数据只有一份，存储在共用存储设备上，在任一时刻只有一个节点能读写这份数据。

高可用性集群对一种服务而言不具有负载均衡功能，它可以提高整个系统的可靠性，但不能增加负载的能力。当然，高可用性集群可以运行多种服务，并适当分配在不同节点上，比如节点A提供Oracle服务，同时节点B提供Sybase服务，这也可以看成是某种意义上的负载均衡，不过这是对多种服务的分配而言。

负载均衡集群适用于提供相对静态的数据的服务，比如HTTP服务。因为通常负载均衡集群的各节点间通常没有共用的存储介质，用户数据被复制成多份，存放于每一个提供该项服务的节点上。

这个困扰我已久一直没有系统整理的问题到这里基本明了了，各位看官到这里旋即也会想到，如果用户有一个由两个节点组成的最小集群，是否可以同时获得高可用性集群和负载均衡集群的效益呢？答案是肯定的。由于高可用性集群适用于提供动态数据的服务，而负载均衡集群适用于提供静态数据的服务，所以我们不妨假设要同时提供Oracle和HTTP服务。用户要在节点A和B上安装HA和NLB软件。把节点A作为Oracle正常工作的节点，节点B作为Oracle服务的后备节点，这是对HA软件而言。对于NLB软件而言，要设置节点B为主ATM（Application Traffic Management）节点，节点A为后备ATM节点，而节点A和节点B同时又都是HTTP的服务节点。

这样一来，节点A和节点B都是身兼两职，而用户同时得到了一个具有高可用性的Oracle服务和一个具有负载均衡功能的HTTP服务。即使有一个节点发生故障，Oracle服务和HTTP服务都不会因此而中断。
这里涉及到一个关键问题：对于同一种服务，是不能同时获得高可用性与负载均衡能力的（有不同意见的么？）。对一种服务，要么是只有一份数据，放在共用存储设备上，一次被一个节点访问，获得高可用性；要么是把数据复制为多份，存储于每个节点的本地硬盘上，用户的请求同时发送到多个节点上，获得负载均衡能力。这也是F5设备没有提供数据库均衡的解决方案的难点所在。

引文:
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
首先申明，除了只读型数据库在某些特定条件下可能使用BIGIP实现负载均衡外。F5迄今未推广过读写型数据库的负载均衡方案。

数据库的Cluster和HA是两个概念。在HA方式下，两台数据库服务器只有一台在工作，并且是由Active设备控制盘阵。在发生HA切换时，Backup设备接管盘阵。在Cluster状态下，比如Oracle RAC，可以实现两台服务器对同一盘阵的同时控制，并且使用的是同一份数据库文件。在RAC存在的情况下，理论上有可能使用BIGIP实现负载均衡，但实际上很难发挥作用，只有在C/S结构下有可能实现，或者是多台应用服务器访问少量数据库服务器的状况下有可能。现在F5中国还未有进行此类测试，如果那位有此类环境可以做一个测试。F5会全力支持测试。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

对于高可用性集群，由于它在设计时的目的就是为了最大可能地减少服务中断时间，因此服务的切换受到很大的关注。当一个节点上的服务故障时，会被很快地检测到并被切换到其他节点上。但在切换时，不能忽略对数据完整性的保护。

再研究一下：在什么情况下数据完整性会被破坏呢？由于高可用性集群中至少有两个节点，连接在一个共用的存储设备上，对于非裸分区而言，如果被两个节点同时读写，就会造成文件系统被破坏。因此就需要利用I/O屏障来防止这一事件的发生。

I/O屏障的目的是为了保证故障节点不能再继续读写某一服务的共用分区，实现的方式有多种。Kimberlite使用硬件开关来实现，当一个节点发生故障时，另一节点如果能侦测到，就会通过串行口发出命令，控制连接在故障节点电源上的硬件开关，通过暂时断电，而后又上电的方式使得故障节点被重启动。

I/O屏障有多种形式。对于支持SCSI Reserve/Release命令的存储设备，也可以用SG命令实现I/O屏障。正常节点应使用SCSI Reserve命令“锁住”共用存储设备，保证其不被故障节点读写。如果故障节点上的集群软件仍在运行，如发现共用存储设备已被对方锁住，就应把自己重启动，以恢复正常工作状态。

实际上，使用F5设备有变通的方法：把两台服务器放入一个POOL中，设不同的优先级，让优先级高的服务器对磁盘有读写操作，当高优先级的服务器宕机时，切到低优先级的机器上，这也实现了HA， 这有点强词夺理，但也能解释，比HA软件切换的快，因为用HA软件做双机时，备机上的各个服务都是宕的，只能当备机探测到主机服务宕机时，才开始启动相应的服务，有时服务还启不了；而用F5做双机时，备机的各服务都是正常启动着的，只是F5设备不把客户请求发到备机上去而已，当主机宕机时，F5设备才把客户请求发到备机，而备机的各服务都是正常启动着的，所以…………

呵呵，想明白了为什么我说是强词夺理么？

如果按照上面的方法作数据库负载均衡，则必须解决一个重要的问题：数据库的同步，如果切换的速度很快，则要求两台数据库的同步也很快…………。其它可能还存在一些问题，所以迄今为止还是没有见过类似结构。

OOPS，扯远了。我来详细说说为什么高可用集群不能对数据库系统进行负债均衡。俺的理由是对负债均衡的定义。

就如我开篇所说

引文:
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
集群一般有两种高可用性和高性能集群，…………负载均衡不能完全算高可用性集群的一种，是高性能性集群

普通的HA软件没办法支持象ORACLE RAC一样的环境，这不完全是集群软件的功能。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

我们就拿OPS来说事儿吧，OPS的核心组件是分布式锁管理器(DLM)，它为OPS实例提供并行高速缓存管理。OPS群集的每个节点在加入群集时都启动DLM进程的一个实例，然后这些实例就可以通过网络互相通信。

因此我的结论一：没有DLM，不管你是HACMP还是ServiceGuard或者TurboCluste都不能并行跑数据库。（不了解mssql、sybase和DB2，欢迎举反例）

然后，OPS的工作机制和simon说的没错，但是最终，它对库文件的读写还是靠缓存排队的，最终仍然同一时刻只有一台主机在读写。可是，真正的负债均衡是N份文件的分布式读取哦。负债均衡是所有资源的均衡哦。

因此我的结论二：即使HA软件配合OPS，仍然不是真正的负债均衡。当然，我们和客户不能这么说。

不过，我有一个想法，在数据库只读的应用环境下，比如高考考分查询，是不是可以多台机器建多个库，库内容都一样，这样的话由于不涉及数据同步的问题，应该可以实现真正均衡的。

顺便分享一下我查到的OPS介绍。总会有人不了解的。

引文:
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
1、什么是OPS

OPS(Oracle Parallel Server)可以让位于不同系统的多个实例同时访问同一个数据库。并行服务器可以有效地提高系统的可用性和对多系统的访问性能，但是，如果你的数据没有做很好的分割，性能可能还会下降。

安装OPS时，多个实例mount同一数据库文件，实例间的通讯由分布式锁管理器（DLM）来管理。需要注意的是分布式锁管理器与你所使用的硬件和操作系统有着密切的关系。为了确定多个企图同时修改同一数据的实例，Oracle使用了十个后台进程：LCK0-LCK9，来锁定某一实例所使用的资源。

OPS主要用于UNIX/LINUX集群环境中。

3、所有的应用都是适合OPS吗？

可以根据功能或数据进行分割的应用最适合OPS。那些有”热数据”（经常被多实例同时访问的数据）的应用并不适合使用OPS。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

结束语：尽管HA软件的功能足够强大，但是我们在系统设计的时候尽量用专用硬件来代替软件能实现的功能比如F5实现http负债均衡。理由1:利润更丰厚2:服务器应该只做单一的服务器从而最大化利用服务资源3:出现问题便于排错4：降低用户的维护成本5：……很多啦，不一一说了

附件：simon写的HA情况下，数据库的操作
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
a、在一个多节点数据库系统的集群中，是将数据保存在一个公用的磁盘空间上的方式来保证数据的统一性的。 而在没有外来机制的情况下，一个磁盘空间上的逻辑空间也是只能被一个主机系统所控制的，即该主机取得了逻辑空间的读写控制权后，其他的主机系统是无法再去进行读写的（UNIX/Windoes平台均是如此），这是由阵列卡的工作机制所决定的。 而这个时候HACMP软件（或者其他的集群软件）出马了，它通过接管控制阵列卡，协调多个主机的操作系统，使他们可以同时去读写同一个逻辑空间（这里的同时只是指访问同一个逻辑空间，而不是同时一个数据记录），这使得多数据库节点共同处理访问请求成为可能，因为它们可以读写同一个后台数据库了。
b、从另一个方面来说，一个数据记录同时只能被一个I/O操作所控制，即一个节点上的数据库系统对数据记录进行读写时，其他的数据库系统是无法去读写该记录的；而在一个多节点的数据库集群中，这就需要对数据记录进行协作、控制，即保证该记录在被一个I/O读写时必须被缩定，禁止其他的数据库对它进行读写，而当该I/O操作完成时必须能释放掉该数据记录，使之能被其他的数据库系统读写。 这点显然是NLB所不能实现的，是需要数据库系统本身的功能支持（主流的数据库Oracle/SQL/Sybase均可实现该功能）。而这点实现了多节点数据库系统间的共同协作处理，也保证了多节点数据库系统的处理能力均衡分载的应用层基础。
在以上2点的保证下，通过HACMP集群软件对外提供同一个公用IP地址（ServiceIP）接受访问请求，由数据库系统的集群组件将请求分配给各个节点上的数据库系统，并协调他们进行后台数据的读写，真正的实现了数据库系统的处理能力上的负载分担、均衡。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

相关日志

• F5作NAT出现的两个问题及解决