集群和负载均衡的区别 nginx

集群和负载均衡的区别如下：

1、集群(Cluster)

所谓集群是指一组独立的计算机系统构成的一个松耦合的多处理器系统,它们之间通过网络实现进程间的通信｡应用程序可以通过网络共享内存进行消息传送,实现分布式计算机｡

2、负载均衡(Load Balance)

网络的负载均衡是一种动态均衡技术,通过一些工具实时地分析数据包,掌握网络中的数据流量状况,把任务合理均衡地分配出去｡这种技术基于现有网络结构,提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法,加强了网络数据处理能力,提高了网络的灵活性和可用性｡

3、特点

(1)高可靠性(HA)｡利用集群管理软件,当主服务器故障时,备份服务器能够自动接管主服务器的工作,并及时切换过去,以实现对用户的不间断服务｡

(2)高性能计算(HP)｡即充分利用集群中的每一台计算机的资源,实现复杂运算的并行处理,通常用于科学计算领域,比如基因分析､化学分析等｡

(3)负载平衡｡即把负载压力根据某种算法合理分配到集群中的每一台计算机上,以减轻主服务器的压力,降低对主服务器的硬件和软件要求｡

LVS系统结构与特点

1 Linux Virtual Server:简称LVS｡是由中国一个Linux程序员章文嵩博士发起和领导的,基于Linux系统的服务器集群解决方案,其实现目标是创建一个具有良好的扩展性､高可靠性､高性能和高可用性的体系｡许多商业的集群产品,比如RedHat的Piranha､ Turbo Linux公司的Turbo Cluster等,都是基于LVS的核心代码的｡

2 体系结构:使用LVS架设的服务器集群系统从体系结构上看是透明的,最终用户只感觉到一个虚拟服务器｡物理服务器之间可以通过高速的 LAN或分布在各地的WAN相连｡最前端是负载均衡器,它负责将各种服务请求分发给后面的物理服务器,让整个集群表现得像一个服务于同一IP地址的虚拟服务器｡

3 LVS的三种模式工作原理和优缺点: Linux Virtual Server主要是在负载均衡器上实现的,负载均衡器是一台加了 LVS Patch的22x版内核的Linux系统｡LVS Patch可以通过重新编译内核的方法加入内核,也可以当作一个动态的模块插入现在的内核中｡

           高可用集群是指以减少服务中断时间为目的的 服务器集群 技术。它通过保护用户的业务程序对外不间断提供的服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度。高可用集群的应用系统有多样化发展趋势，用途也越来越多样化，同时带来了配置及可操作性方面的复杂性，因此选择好的高可用软件至关重要。

           简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。高可用性集群（HA cluster）是指如单系统一样地运行并支持（计算机）持续正常运行的一个主机群。

             分为前端负载调度和后端服务两个部分。负载调度部分负责把客户端的请求按照不同的策略分配给后端服务节点，而后端节点是真正提供应用程序服务的部分。与高可用集群不同的是，负载均衡集群中，所有的后端节点都处于活动动态，它们都对外提供服务，分摊系统的工作负载。

             负载均衡建立在现有网络结构之上，它提供了一种廉价、有效、透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

集群架设服务器数量：2台

集群架设方法：（设定：主服务器IP：192168011 从服务器 192168012）

第一步：架设主服务器

1、 利用启动器配置好完整的服务端程序 （举例：比如服务器名：测试 服务器IP：192168011 登陆网关端口 7000 角色网关端口 7100 游戏RUN端口 7200 7300 7400），利用启动器配置好后，那么你的主服务器是一个完整的服务端了

2、 修改配置文件：（修改配置文件的目的是为了让你的从服务器能够跟这台主服务器进行通讯，具备负担的条件）

1> DBServer !addrtabletxt 此文档含义：允许连接DBS管理器的IP列表，一般写上 127001 主IP 192168011 从IP 192168012 三个IP独立成行

2> DBServer ！serverinfotxt 此文档含义：主服务器 从服务器 的网关IP以及端口，可以设置如下

192168011 192168011 7200 192168011 7300 192168011 7400

192168012 192168012 7200 192168012 7300 192168012 7400

3> LogunSrv !addrtabletxt 此文档 实际上是一个角色网关跟登陆网关直接通讯路由标识表 在最后加一个 从服务器的IP跟端口即可

比如：127001 127001 192168011:7100 192168012:7100

4> LogunSrv !serveraddrtxt 允许连接IDDBS 同DBServer !addrtabletxt

主服务器架设完毕 架设完毕后切忌不要再用启动器配置了 否则要从来再配置一遍，就麻烦啦。

第二步：架设从服务器

1、 从服务器只需要开 SELATE RUNGATE

1> SELATE 开启的目的是 登陆7000之后 可以选择到这台从服务器的网关 记得配置文件网关地址写本服务器IP地址 192168012 服务器地址写 192168011

2> RUNGATE 手动配置3个 7200 7300 7400 服务器地址写上 主服务器地址 192168011

架设完毕主服务器利用启动所有程序 从服务器手动开 角色网关 和三个游戏网关

在主服务器的M2上面能看到 从服务器的IP过来就说明通讯成功，如果看不到，说明自己哪里设置错了，仔细检查下！原理很简单的，自己实践吧！

在本实验环境中我们没有办法为大家提供多台服务器来模拟集群环境，由此我们 docker 工具来创建多个 container 来模拟集群所需要的多台服务器。

docker 可以简单的理解为非常轻量级的虚拟机工具，而 container 则理解为创建的虚拟机。

集群系统中，服务器资源可以简单分为两种角色：

一种是 Load Balancer，即负载均衡调度器，位于集群系统的前端，对后端服务器实现负载均衡作用，对外 IP 地址也称为 VIP（虚拟 IP 地址）。

另一种就是后端服务器群，处理由 Load Balancer 发来的请求。

整个集群系统结构：

宿主机环境（默认桌面环境）：装有 ipvsadm（LVS 的 IP 负载由 IPVS 内核模块完成，ipvsadm 是为 IPVS 编制规则的工具），充当负载均衡调度器

宿主机浏览器：通过宿主机中的浏览器来充当客户端

RealServer1 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

RealServer2 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

我们将通过这样的一些步骤来完成此次的实验：

本地安装 ipvsadm 工具，加载 IPVS 模块

通过 docker 创建两个 container 来模拟服务器池中的成员

配置两台 RealServer 的环境：

安装 vim 与 nginx 工具

修改默认的 nginx 展示页面

配置负载均衡调度机器：

修改内核转发参数

配置 ipvsadm 规则

测试实验效果

LVS 成功测试：我们能够通过 VIP 访问我们的 Nginx 站点，经过多次的刷新我们能够访问另一个站点的内容（以显示的内容以作区分，因为负载并不高，所以需要很多次刷新，点击地址栏，按住 F5 不放）

安装 ipvsadm 工具

首先为了能够使用 IPVS 内核模块，我们将在宿主机中安装 ipvsadm，并尝试能否使用：

命令讲解：

docker run：创建 docker 容器

name 参数：给容器命名，方便区分

tid 参数：分配 tty，能够与之交互

ubuntu：指定容器镜像，这里使用 ubuntu 镜像

安装相关工具

为了区分 RealServer1 和 RealServer2 的 Nginx 响应页面，需要修改默认 nginx 的展示 html 页面。

按 i 键插入，按 esc 再输入 :wq 保存退出。

注意若完成了 RealServer1 的配置之后，如果我们不想打开新的终端，可以通过 ctrl+p+q 的组合快捷键脱离当前机器的登录，切勿使用 exit 的方式退出 container，这样的方式关闭服务器的。 脱离之后便会返回到 shiyanlou 的 zsh 交互，可以通过 docker attach RealServer2 的命令来登录另一台机器，然后做类似的操作（同上的软件安装操作以及 nginx 启动操作）

接下来就修改 nginx 页面，如下所示：

LoadBalancer 的对外 IP 地址为 VIP，即 VIP 地址为 12026159 （注意，你的 VIP 地址可能和我的不一样，根据自己实际情况来）。对内 IP 称为 RIP，此时 RIP 为 19216801。

2开启 LoadBalancer 的内核路由转发：

3查看当前机器内核路由转发开启情况：

得到的值为 1，说明此机器已开启内核路由转发。进行下一步。

4使用 ipvsadm 添加 ipvs 规则。定义集群服务：

上面命中 ipvsadm 参数讲解：

以上便实现了 LVS 的 NAT 负载均衡系统。

与 NAT 方式相同，我们将通过 docker 来模拟我们的集群环境。

集群系统中，服务器资源可以简单分为两种角色：

一种是 Load Balancer，即负载均衡调度器，位于集群系统的前端，对后端服务器实现负载均衡作用，对外 IP 地址也称为 VIP（虚拟 IP 地址）。

另一种就是后端服务器群，处理由 Load Balancer 发来的请求。

整个集群系统结构：

宿主机环境（默认桌面环境）：充当客户端访问 web 服务

LoadBalancer1 的 container：装有 ipvsadm，充当负载均衡调度器

RealServer1 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

RealServer2 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

我们将通过这样的一些步骤来完成此次的实验：

本地安装 ipvsadm 工具，加载 IPVS 模块

通过 docker 创建三个 container 来模拟服务器池中的成员

配置两台 RealServer 的环境：

安装 vim 与 nginx 工具

修改默认的 nginx 展示页面

修改内核参数，抑制 arp

创建网卡别名与添加路由

配置一台 LoadBalancer 环境：

安装 ipvsadm

配置网卡别名

配置 ipvsadm 规则

测试实验效果

LVS 成功测试：我们能够通过 VIP 访问我们的 Nginx 站点，经过多次的刷新我们能够访问另一个站点的内容（以显示的内容以作区分，因为负载并不高，所以需要很多次刷新，点击地址栏，按住 F5 不放）

查看 ipvsadm 中的统计数据。

若是我们沿用 NAT 的实验环境，我们需要做环境的清理：

1首先清除 ipvsadm 的规则：

2删除之前所创建的 container，虽然都是提供 Web 服务，但是在 DR 模式中需要修改内核参数与创建网卡别名，需要超级权限，所以不能沿用之前的 container：

安装 ipvsadm 工具

因为在 NAT 实验中我们已安装所以可跳过该步骤，若是新启动的环境请参考 NAT 中的步骤，此处提示务必在宿主机环境中执行 ipvsadm -L 的验证步骤，若是不执行该步骤，在 LoadBalancer 的 container 中我们将无法加载 IPVS 的内核模块。

创建与配置服务器池成员

同样我们使用 docker 来模拟我们的集群环境，创建三台 container：

其中 --privileged 参数用于给予容器超级权限。

完成我们服务器池成员的创建之后，我们参照 NAT 中配置步骤完成 RealServer 中的：

nginx 与 vim 的安装

默认展示页面的修改

nginx 服务的启动

在完成这样的配置之后我们需要一些额外的操作：

1修改内核参数

以 RealServer1 为例，登录 container：

执行下列命令：

ARP 的内核参数： arp_ignore 部分参数：定义了本机响应 ARP 请求的级别

0 表示目标 IP 是本机的，则响应 ARP 请求。默认为 0

1 如果接收 ARP 请求的网卡 IP 和目标 IP 相同，则响应 ARP 请求

arp_announce 参数：定义了发送 ARP 请求时，源 IP 应该填什么。

0 表示使用任一网络接口上配置的本地 IP 地址，通常就是待发送的 IP 数据包的源 IP 地址 。默认为 0

1 尽量避免使用不属于该网络接口(即发送数据包的网络接口)子网的本地地址作为 ARP 请求的源 IP 地址。大致的意思是如果主机包含多个子网，而 IP 数据包的源 IP 地址属于其中一个子网，虽然该 IP 地址不属于本网口的子网，但是也可以作为ARP 请求数据包的发送方 IP。

2 表示忽略 IP 数据包的源 IP 地址，总是选择网络接口所配置的最合适的 IP 地址作为 ARP 请求数据包的源 IP 地址(一般适用于一个网口配置了多个 IP 地址)

2配置网卡别名

只有目的 IP 是本机器中的一员时才会做相应的处理，所以需要添加网卡别名：

同两台 Web 服务器中都做该配置，即完成了所有 Web 服务器所需的配置工作。

配置调度器规则

紧接着我们登录 LoadBalancer 机器：

安装 ipvsadm 软件：

创建 eth0 的别名并绑定 VIP 地址，作为集群同时使用：

查看网卡信息：ifconfig

在 LoadBalancer 中添加 IPVS 规则：

ipvsadm 命令参数讲解：

以上操作就实现了 LVS/DR 模式，实现集群系统的负载均衡。

轮转(Round-Robin)算法

加权轮转(Weighted Round Robin)算法

最小连接数（Least Connections）算法

加权最小连接数（Weighted Least Connections）算法

目的地址哈希散列（Destination Hashing Scheduling）算法

源地址哈希散列（Source Hashing Scheduling）算法

随机（Random）算法

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQL Server

SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

单个的大的SQL Server集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

市面上存在两种数据库负载均衡的思路：1

基于数据库连接的负载均衡：例如总共有100个数据库连接，50个连接登录到数据库机器A，另外50个连接登录到数据库机器B，这样每个连接中接下来的所有请求全都是发往同一台数据库机器的

这种数据库负载均衡的思路模拟了WEB上的负载均衡方法，但是由于WEB连接是短时间连接(连接建立后，获取需要的HTML等资源后，连接马上被关闭)，而数据库连接是长时间连接(连接建立后，可长时间保持，客户可不停向数据库发送SQL请求，数据库做出回答，如此不断循环直到连接被人为或因错而断开为止)，因此这种数据库负载均衡思路存在着明显的缺点：有可能会发生绝大部分的请求压力都集中到某台数据库机器上去，从而使得负载均衡效果失效

2

基于批处理请求的负载均衡：在建立数据库连接的时候，会同时与每台数据库服务器建立连接，之后针对客户端的每次请求，都会根据负载均衡算法，独立地选出某个数据库节点来执行这个请求

此种思路符合数据库长时间连接的特征，不存在上面所述的基于连接的负载均衡方法的缺点

市面上的负载均衡厂商，既有基于连接的，也有基于批处理请求的，用户需仔细辨别才能找到自己想要的合适产品