商业源码 简述负载均衡集群中常见的调度算法及原理？（5种以上）
2 LVS介绍
3 IPVS发展史
4LVS体系结构与工作原理简单描述
5LVS的基本工作过程
6LVS的三种工作模式：
61NAT模式-网络地址转换
62TUN模式
63DR模式（直接路由模式）
很多组织机构慢慢的在不同的服务器和地点部署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的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。
在本实验环境中我们没有办法为大家提供多台服务器来模拟集群环境，由此我们 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 模式，实现集群系统的负载均衡。
随着用户访问的增多，一个应用服务器不能满足需求了，就需要部署多台应用服务器，通过负载均衡，将数据分发到不同的应用服务器。
从作用来看，和缓存集群的分发很相似，但是有不同。缓存需要发送到特定的服务器。但是，由于应用服务器是无状态的，因此，负载均衡不用根据请求分发到特定服务器，发送到哪个应用服务器都可以。
因此，负载均衡关注的技术焦点有两个，分别是：网络通信、路由选择
网络通信分为以下几种方法。
负载均衡服务器什么都不做，重定向响应
这种方法优点是简单，但是缺点也很明显：
由于这些问题，这种方法，在现实中几乎没有人使用。
每次请求DNS解析到IP地址不同，从而访问到不同到应用服务器。
这种方法，性能方面没有问题，虽然，还是2次http请求，但是不是每一次请求都需要域名解析，一次解析，ip就会记录到本地。下次，直接访问记录的ip。因此，性能无问题。
但是，由于域名解析服务器解析出的ip，如果出错，不会很快更新，且用户已经本地存储了ip也不会很快改变。因此，采用这种方案时，需要两级负载均衡。若应用服务器出错，在第二层负载均衡去掉。
对于安全性，现实使用时，该方法主要适用于两层负载均衡的情况，DNS负载均衡用于第一层负载均衡，解析出来的是第二层负载均衡服务器，因此，脆弱的服务器还是可以在内网中。淘宝、百度，不同时间ping，返回地址不同，意味着都是用了DNS负载均衡。
在应用层进行负载均衡，收到请求时，将请求转发到内网，再将收到的内网响应，返回给用户。
nagix本身的反向代理服务器，就有该功能。一般应用服务器是几十台，这种模式够用，再多一些，会不够用。因此，大一些的网站不会使用。
因为用的http请求协议，http比较重（比tcp的包重）。对反向代理服务器压力很大，其通过应用程序级别的线/进程才能完成分发，还要等应用服务器返回，因此，会有性能瓶颈。即使负载均衡做集群效率也低，因为后面的应用服务器有限。
因此，可以应用的规模很有限。
负载均衡服务器，和反向代理负载均衡原理相同，但是是在tcp层，修改包中源地址和目标地址，并发送到内网，收到响应后，再修改目标地址和原地址，返回给用户。
因为，负载均衡服务器处理的是ip那一层包，因此，处理能力可以提高。
但是，这种方法，请求和响应都通过了负载均衡，尤其是响应一般比较大。响应出口网络带宽会成为瓶颈。
数据链路层负载均衡，IP地址不变，只修改网卡MAC地址。应用服务器和负载均衡服务器共享一个虚拟ip。因为ip没有被修改过，tcp/ip协议还是通的，可以通过校验。又由于目的地址的mac地址改变了，因此，处理响应不用再经过负载均衡服务器。
大型互联网应用主要使用的负载均衡方案，也称为负载均衡的三角模式。
轮询
该方案已经被淘汰的。
通过session复制的方式，集群规模会受限制，复制不过来。做集群就是因为用户请求多，请求多，session也多，如果每个都有所有的session，对服务器压力很大。
来自相同的ip，总是到同一个应用服务器。这种方法也很快就淘汰了。
因为，会话需要会话关闭，如果因为发布程序，kill进程，session丢失。系统的可用性会下降。
发请求时，带cookie发送服务器，session记录的cookie中，返回给浏览器。任何一台服务器可以重cookie里得到session。
缺点：cookie变大，网络开销有影响。且有些浏览器禁用cookie，不好用。
早期使用的这个方案。缺点明显，但是生命力强。
对服务器架构要求很低。
0条评论