吸取他人经验，了解负载均衡功能(1)

本文主要内容：本文针对负载均衡功能进行了详细的介绍，包括一些网友的经验，在此特意为大家整理出来，希望能让广大的读者从他人的经验中吸取精华。

对于初学者，总是会对集群和负载均衡功能进行混淆。那么在这里我们从一些资料中，总结了一些网友的学习经验，在此分享给广大的读者。看看别人的理解和表述，对你的学习是否有所帮助呢？现在就来看看负载均衡功能的实现问题吧。

有两个问题一直没有很好的对自己能解释通，尤其是在没有弄明白这两个问题的相关术语的时候，又去研究相关的衍生问题，搞得自己差点口吐白沫。这两个问题是这样的：

1.集群软件能否实现负载均衡的功能，两者有何差别

2.如何实现数据库的均衡

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

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

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

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

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

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

这样一来，节点A和节点B都是身兼两职，而用户同时得到了一个具有高可用性的Oracle服务和一个具有负载均衡功能的HTTP服务。即使有一个节点发生故障，Oracle服务和HTTP服务都不会因此而中断。

这里涉及到一个关键问题：对于同一种服务，是不能同时获得高可用性与负载均衡功能的（有不同意见的么？）。对一种服务，要么是只有一份数据，放在共用存储设备上，一次被一个节点访问，获得高可用性；要么是把数据复制为多份，存储于每个节点的本地硬盘上，用户的请求同时发送到多个节点上，获得负载均衡功能。这也是F5设备没有提供数据库均衡的解决方案的难点所在。

引文:

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

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

编辑推荐

负载均衡技术基础专题

当前，无论在企业网、园区网还是在广域网上，即使按照当时最优配置建设的网络，业务量的发展都超出了过去..

本文主要内容：本文针对负载均衡功能进行了详细的介绍，包括一些网友的经验，在此特意为大家整理出来，希望能让广大的读者从他人的经验中吸取精华。

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

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

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

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

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

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

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

就如我开篇所说

引文:

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

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

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

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

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

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

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

佟媛微

编辑推荐

负载均衡技术基础专题

当前，无论在企业网、园区网还是在广域网上，即使按照当时最优配置建设的网络，业务量的发展都超出了过去..