所谓集群，指一组(多台)相互独立的计算机利用高速通信网络组成的一个规模较大的计算机服务系统，每个集群节点(即集群中的一台服务器)都是运行各自服务的独立服务器。这些服务器之间相互连接，协同为用户提供应用程序、数据资源，并以单一系统的模型进行管理。当用户请求集群系统时，集群给用户的感觉就像是一台独立的服务器在为客户提供服务，而实际上处理客户请求的这个步骤是由很多台服务器共同实现的。
1.2.集群的优点
一些国家重要的计算密集型应用（如天气预报、核试验模拟等）需要计算机有很强的运算处理能力。以全世界现有的技术，即使是大型机，其计算能力也是有限的，很难单独完成此任务。因为计算时间可能会相当长，也许几天，甚至几年或更久。因此，对于这类复杂的计算业务使用了计算机集群技术，集群中有几十台、上百台，甚至成千上万台计算机协同计算。
通常一套系统集群架构，只需要几台或数十台服务器主机即可。与动辄价值上百万的专用超级计算机相比便宜了很多。在达到同样性能需求的条件下，采用计算机集群架构比采用同等运算能力的大型计算机具有更高的性价比。
当服务负载、压力增长时，针对集群系统进行较简单的扩展即可满足需求，且不会降低服务质量。
单一的计算机系统总会面临设备损毁的问题，如CPU、内存、主板、电源、硬盘等，只要一个部件坏掉，这个计算机系统就可能会宕机，无法正常提供服务。在集群系统中，尽管部分硬件和软件也会发生故障，但整个系统的服务可以是7×24小时可用的。目前几乎100%的互联网网站都要求7×24小时提供服务的。
多个独立计算机组成的松耦合集群系统构成一个虚拟服务器；用户或客户端程序访问集群系统时，就像访问一台高性能、高可用的服务器一样，集群中一部分服务器的上线下线不会中断整个系统服务，这对用户也是透明的。
1.3.集群的类型
HPC/高性能运算（High Performance Computer）集群
无论哪种集群、都至少包括两台节点服务器，而且对外表现为一个整体，只提供一个访问入口(域名或IP)。
以提高应用系统的响应能力、尽可能处理更多的访问请求，减少延迟为目标获得高并发、高负载的整体性能。例如，“DNS轮询”、“应用层交换”、“反向代理”等都可以用作负载均衡集群。LB的负载分配主要依赖于主节点的分流算法，将来自客户机的访问请求分担给多个服务器节点，从而缓解整个集群系统的压力。
❑ 分担用户访问请求及数据流量（负载均衡）。
负载均衡集群典型的开源软件包括LVS、Nginx、Haproxy等。
HA/高可用集群
以提高应用系统的可靠性，尽可能地减少中断时间为目标，确保服务的连续性，达到高可用的容错效果。例如“故障切换”、“双机热备”、“多机热备”等都属于高可用集群技术。HA的工作方式包括双工和主从两种模式，双工即所有节点同时上线，而主从只有主节点在线提供服务，当主节点出现问题后备接替出故障的主节点为用户提供服务。
HPC/高性能运算集群
以提高应用系统的CPU运算速度、扩展硬件资源和分析能力为目标，获得相当于大型、超级计算机的高性能运算(HPC)能力。例如“云计算”、“网格计算”也可视为高性能运算的一种。高性能运算集群的高性能依赖于“分布式运算”、“并行运算”，通过专用硬件和软件将多台服务器的CPU、内存等硬件资源整合到一起，实现只有大型、超级计算机才具备的计算能力。
在互联网网站架构中，比较常用的是负载均衡集群和高可用性集群。
1.3.集群实现的方式
企业中常用的开源集群软件有：Nginx、LVS、Haproxy、Keepalived、Heartbeat等
企业中常用的商业集群硬件有：F5、Netscaler、Radware、A10等
相比较而言，商业的负载均衡产品成本高、性能好，更稳定，缺点是不能二次开发，开源的负载均衡软件对运维人员的能力要求较高，如果运维及开发能力强，那么开源软件的负载均衡是不错的选择，目前的互联网行业更偏向使用开源的负载均衡软件。
在典型的负载均衡集群中，主要包括三个层次的组件。如下图所示，前端至少有一个负载调度器(Director) 负责响应并分发来自客户机的访问请求；后端有大量独立节点服务器(Real Server)构成服务器池(Server Pool)提供实际的应用服务，整个集群的伸缩性通过增加、删除节点服务器来完成，而这些过程对客户机都是透明的；为了保持服务、数据的一致性，所有节点使用共享存储设备。
第一层，负载均衡调度器
这是访问整个集群系统的唯一入口，对外使用所有服务器的共有VIP（Virtual IP）地址，也称为集群IP地址。通常会配置主、备两台调度器实现双机热备效果，当主调度器失效后，可以平滑替换至备用调度器，从而确保高可用性。
第二层，服务器池
集群所提供的应用服务(如web、ftp等)由服务器池承担，其中每个节点具有独立的RIP(Real IP,真实IP)地址，只处理调度器分发过来的客户机请求，当某个节点暂时失效时，负载调度器的容错机制将会将其隔离，等待错误排除后再重新加入服务器池。
为服务器池中的所有节点提供稳定、一致的文件存储服务，确保整个集群的统一性。在Linux/UNIX环境中，共享存储可以使用NAS设备，或者提供NFS(网络文件系统)共享服务的专用服务器。
严格来说，Nginx仅仅是作为Nginx Proxy反向代理使用的，因为这个反向代理功能表现的效果是负载均衡集群的效果，所以称之为Nginx负载均衡。那么，反向代理和负载均衡有什么区别呢？
普通负载均衡软件，如大名鼎鼎的LVS，其实现的功能只是对请求数据包的转发（也可能会改写数据包）、传递，其中DR模式明显的特征是：从负载均衡下面的节点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户，而反向代理就不一样了，反向代理接收访问用户的请求后，会代理用户重新向代理下的节点服务器发起请求，最后把数据返回给客户端用户，在节点服务器看来，访问节点服务器的客户端用户就是反向代理服务器了，而非真实的网站访问用户。
nginx工作在七层能够针对域名、目录做特定转发，功能更全面
一句话概括：LVS等的负载均衡是转发用户请求的数据包，而Nginx反向代理是接收用户的请求然后重新发起请求去请求其后面的节点。
如右图，所有用户的请求统一发到Nginx负载均衡器，然后由负载均衡器根据调度算法来请求Web01和Web02。
|
Nginx HTTP功能模块 |
|
Nginx的负载均衡功能依赖于ngx_http_upstream_module模块，所支持的代理方式包括proxy_pass、fastcgi_pass、memcached_pass等，本文主要针对proxy_pass代理方式进行讲解。ngx_http_upstream_module模块允许Nginx定义一组或多组节点服务器，使用时可以通过proxy_pass代理方式把网站的请求发送到事先定义好的对应upstream组上，具体写法为“proxy_pass http://www_pools”，其中www_pools就是一个upstream节点服务器组名字。
http {
upstream www_pools { //www_pools为集群组名称
server 192.168.1.12:80 weight=10;
server 192.168.1.13:80 weight=20;
server 192.168.1.14:80 backup; //其他服务器不可以时启用该服务器
}
}
调度算法一般分为以下两类：
静态调度算法：即负载均衡器根据自身设定的规则进行分配，不需要考虑后端节点服务器情况。例如：rr、wrr、ip_hash都属于静态调度算法。
动态调度算法：即负载均衡器会根据后端节点的当前状态来决定是否分发请求。例如：连接数少的优先获得请求，响应时间短的优先获得请求，least_conn、fair等都属于动态调度算法。
常用的调度算法：
按客户端请求顺序把客户端的请求逐一分配到不同的后端节点服务器，这相当于LVS中的rr算法，如果后端节点服务器宕机（默认情况下Nginx只检测80端口），宕机的服务器会被自动从节点服务器池中剔除，以使客户端的用户访问不受影响。新的请求会分配给正常的服务器。
（2）wrr（权重轮询，静态调度算法）
在rr轮询算法的基础上加上权重，即为权重轮询算法，当使用该算法时，权重和用户访问成正比，权重值越大，被转发的请求也就越多。可以根据服务器的配置和性能指定权重值大小，从而有效解决新旧服务器性能不均带来的请求分配问题。
（3）fair（动态调度算法）
此算法会根据后端节点服务器的响应时间来分配请求，响应时间短的优先分配。这是更加智能的调度算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身是不支持fair调度算法的，如果需要使用这种调度算法，必须下载Nginx的相关模块upstream_fair。
least_conn算法会根据后端节点的连接数来决定分配情况，哪个机器连接数少就分发给哪个节点。
proxy_pass指令属于ngx_http_proxy_module模块，此模块可以将请求转发到另一台服务器，在实际的反向代理工作中，会通过location功能匹配指定的URI，然后把接收到的符合匹配URI的请求通过proxy_pass抛给定义好的upstream节点池。
- 将匹配URI为name的请求抛给http://127.0.0.1/remote/:
server {
proxy_pass http://127.0.0.1/remote/;
}
}
- 将匹配URI为some/path的请求抛给http://127.0.0.1:
server {
proxy_pass http://127.0.0.1;
}
}
server {
location / {
}
}
原文地址:https://blog.csdn.net/m0_50818626/article/details/130340161
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_16103.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
