服务器负载均衡问题,需要的设备和软件
WEB服务器
数据库服务器
存储
支持来CMS集群管理方式;支持WEB管理,支持网络流量分析的路由器或交换机。用来实现NBL。
1首先你要有这面的这些设备,自服务器最好同一型号。要做成集群(NLB),共享存储,具体怎么做集群,网上有很多资料的。我就不细说了。
2流媒体服务器。流媒体服务器可以通过已有的硬百件设备来连接。客户端访问流媒体服务器,流媒体服务器再通过客户的请求来访问数据库。
3访问数据库时,就可根据自己度定义的NLB来实现负载均衡。
1、集群是什么?
① 集群(cluster)技术是一种较新的技术,通过集群技术,可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益,其任务调度则是集群系统中的核心技术。
② 集群是一组相互独立的、通过高速网络互联的计算机,它们构成了一个组,并以单一系统的模式加以管理。一个客户与集群相互作用时,集群像是一个独立的服务器。
③ 集群组成后,可以利用多个计算机和组合进行海量请求处理( 负载均衡 ),从而获得很高的处理效率,也可以用多个计算机做备份(高可用),使得任何一个机器坏了整个系统还是能正常运行。集群在目前互联网公司是必备的技术,极大提高互联网业务的可用性和可缩放性。
2、负载均衡集群技术
① 负载均衡(Load Balance):负载均衡集群为企业需求提供了可解决容量问题的有效方案。负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理。
② 负载通常包括应用程序处理负载和网络流量负载。这样的系统非常适合向使用同一组应用程序的大量用户提供服务。每个节点都可以承担一定的处理负载,并且可以实现处理负载在节点之间的动态分配,以实现负载均衡。对于网络流量负载,当网络服务程序接受了高入网流量,以致无法迅速处理,这时,网络流量就会发送给在其它节点上运行的网络服务程序。也可根据服务器的承载能力,进行服务请求的分发,从而使用户的请求得到更快速的处理。
3、负载均衡集群技术的实现
负载均衡(Load Balance)
负载均衡技术类型:基于 4 层负载均衡技术和基于 7 层负载均衡技术
负载均衡实现方式:硬件负载均衡设备或者软件负载均衡
硬件负载均衡产品: F5 BIG-IP 、Citrix Netscaler 、深信服 、Array 、Radware
软件负载均衡产品: LVS (Linux Virtual Server)、 Haproxy、Nginx、Ats(apache traffic server)
4、实现效果如图
5、负载均衡分类
负载均衡根据所采用的设备对象( 软/硬件负载均衡 ),应用的OSI网络层次( 网络层次上的负载均衡 ),及应用的地理结构( 本地/全局负载均衡 )等来分类。本文着重介绍的是根据应用的 OSI 网络层次来分类的两个负载均衡类型。
我们先来看一张图,相信很多同学对这张图都不陌生,这是一张网络模型图,包含了 OSI 模型及 TCP/IP 模型,两个模型虽然有一点点区别,但主要的目的是一样的,模型图描述了通信是怎么进行的。它解决了实现有效通信所需要的所有过程,并将这些过程划分为逻辑上的层。层可以简单地理解成数据通信需要的步骤。
根据负载均衡所作用在 OSI 模型的位置不同,负载均衡可以大概分为以下几类:
二层负载均衡(mac)
根据OSI模型分的二层负载,一般是用虚拟mac地址方式,外部对虚拟MAC地址请求,负载均衡接收后分配后端实际的MAC地址响应。
三层负载均衡(ip)
一般采用虚拟IP地址方式,外部对虚拟的ip地址请求,负载均衡接收后分配后端实际的IP地址响应。
四层负载均衡(tcp)
在三层负载均衡的基础上,用ip+port接收请求,再转发到对应的机器。
七层负载均衡(http)
根据虚拟的url或IP,主机名接收请求,再转向相应的处理服务器。
在实际应用中,比较常见的就是四层负载及七层负载。这里也重点说下这两种负载。
6、四层负载均衡(基于IP+端口的负载均衡)
所谓四层负载均衡,也就是主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
layer4
1在三层负载均衡的基础上,通过发布三层的IP地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。
2以常见的TCP为例,负载均衡设备在接收到第一个来自客户端的SYN 请求时,即通过上述方式选择一个最佳的服务器,并对报文中目标IP地址进行修改(改为后端服务器IP),直接转发给该服务器。TCP的连接建立,即三次握手是客户端和服务器直接建立的,负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下,为保证服务器回包可以正确返回给负载均衡设备,在转发报文的同时可能还会对报文原来的源地址进行修改。
3对应的负载均衡器称为四层交换机(L4 switch),主要分析IP层及TCP/UDP层,实现四层负载均衡。此种负载均衡器不理解应用协议(如HTTP/FTP/MySQL等等)要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。
4实现四层负载均衡的软件有:
F5:硬件负载均衡器,功能很好,但是成本很高。
lvs:重量级的四层负载软件
nginx:轻量级的四层负载软件,带缓存功能,正则表达式较灵活
haproxy:模拟四层转发,较灵活
7、七层的负载均衡(基于虚拟的URL或主机IP的负载均衡)
所谓七层负载均衡,也称为“内容交换”,也就是主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
layer7
1在四层负载均衡的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,比如同一个Web服务器的负载均衡,除了根据VIP加80端口辨别是否需要处理的流量,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,如果你的Web服务器分成两组,一组是中文语言的,一组是英文语言的,那么七层负载均衡就可以当用户来访问你的域名时,自动辨别用户语言,然后选择对应的语言服务器组进行负载均衡处理。
2以常见的TCP为例,负载均衡设备如果要根据真正的应用层内容再选择服务器,只能先代理最终的服务器和客户端建立连接(三次握手)后,才可能接受到客户端发送的真正应用层内容的报文,然后再根据该报文中的特定字段,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。负载均衡设备在这种情况下,更类似于一个 代理服务器 。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看,七层负载均衡明显的对负载均衡设备的要求更高,处理七层的能力也必然会低于四层模式的部署方式。
3对应的负载均衡器称为七层交换机(L7 switch),除了支持四层负载均衡以外,还有分析应用层的信息,如HTTP协议URI或Cookie信息,实现七层负载均衡。此种负载均衡器能理解应用协议。
4实现七层负载均衡的软件有:
haproxy:天生负载均衡技能,全面支持七层代理,会话保持,标记,路径转移;
nginx:只在http协议和mail协议上功能比较好,性能与haproxy差不多;
apache:功能较差
Mysql proxy:功能尚可。
8、四层负载与七层负载的区别
举个例子形象的说明:四层负载均衡就像银行的自助排号机,每一个达到银行的客户根据排号机的顺序,选择对应的窗口接受服务;而七层负载均衡像银行大堂经理,先确认客户需要办理的业务,再安排排号。这样办理理财、存取款等业务的客户,会根据银行内部资源得到统一协调处理,加快客户业务办理流程。
总结:从上面的对比看来四层负载与七层负载最大的区别就是效率与功能的区别。四层负载架构设计比较简单,无需解析具体的消息内容,在网络吞吐量及处理能力上会相对比较高,而七层负载均衡的优势则体现在功能多,控制灵活强大。在具体业务架构设计时,使用七层负载或者四层负载还得根据具体的情况综合考虑。
2、Haproxy 实现四层负载
1921681100 (电信)
1921681101 (电信)
1921681102 (电信)
101010100 (网通)
101010101 (网通)
并且5台服务器都在为www提供服务。
本例子再假设域名为qicaispacecom
为电信用户实现负载均衡
根据前面的资料,电信一共有3台www服务器,分别是
1921681100
1921681101
1921681102
首先登陆DNSPod的後台,添加一个qicaispacecom的域名。
然後在 管理域名记录 中添加一条记录
主机记录 www记录类型 A线路类型 电信
记录值 1921681100点击增加接着,再分别添加两条记录
主机记录 www记录类型 A线路类型 电信
记录值 1921681101
主机记录 www记录类型 A线路类型 电信
记录值 1921681102
为网通用户实现负载均衡
电信用户的记录添加完毕後,接着添加网通的。
网通的添加方法跟电信的没太大分别
主机记录 www记录类型 A线路类型 网通
记录值 101010100
主机记录 www记录类型 A线路类型 网通至此,所有记录添加完毕
很多组织机构慢慢的在不同的服务器和地点部署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台服务器呢。
2 应该是每台都会有一个IP地址 外网 访问连接到的那个IP地址 是你的负载均衡交换机的IP地址 他随机把你的访问请求分配到你的3台服务器上
3 无主从关系,负载均衡交换机它会没2秒左右向你的服务器发送一个健康检查,如果发现你的服务器出现问题,它会自动屏蔽你这台服务器
4 你问的重复问题。
随着企业用户量的增大,单台服务器已难以承受高并发流量的冲击,此时部署负载均衡是必须的,它帮助企业达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。可以说,现在负载均衡已经成为了平台级的服务,几乎所有的云服务提供商都提供负载均衡服务。那么,流媒体服务器如何实现负载均衡?
图源:
算法
提供多个WAN ports可作多种负载平衡算法则,企业可依需求自行设定负载平衡规则,而网络存取可参照所设定的规则,执行网络流量负载平衡导引。算法则有:
◎ 依序Round Robin
◎ 比重Weighted Round Robin
◎ 流量比例Traffic
◎ 使用者端User
◎ 应用类别Application
◎ 联机数量Session
◎ 服务类别Service
◎ 自动分配Auto Mode
Inbound Load Balancing
内建Inbound Load Balance 功能,可让企业透过多条ISP线路,提供给浏览者更实时、快速与稳定不断线的因特网在线服务;
Inbound负载平衡算法包括:Round Robin/ Weighted Round Robin/Auto Back Up;
功能
内建DNS服务器,可维护多个网域(domain),每个网域又可以新增多笔纪(A/CNAME/MX),达到Inbound Load Sharing的功能。
■Server Load Balancing
AboCom服务器负载均衡提供了服务级(端口)负载均衡及备援机制。主要用于合理分配企业对外服务器的访问请求,使得各服务器之间相互进行负载和备援。
AboCom服务器负载与服务器群集差异:
一旦有服务器故障,群集技术只对服务器的硬件是否正常工作进行检查;AboCom服务器负载则对应用服务端口进行检查,一旦服务器的该应用服务端口异常则自动将访问请求转移到正常的服务器进行响应。
■*** Trunk 负载均衡
支持同时在多条线路上建立***连接,并对其多条***线路进行负载。不仅提高了企业总部与分支机构的***访问速度,也解决了因某条ISP线路断线造成无法访问的问题。进行***负载均衡时***访问数据将同时在多条***线路上进传输。当一条***线路故障时,所有流量将自动切换到正常的***线路上进行传输。
QoS(带宽管理)
个人带宽管理:可实现每个人的网络带宽分配、管理,可以设置保证带宽用以保障个人应用不受整体环境影响。每日带宽配额:可以针对个人、群组或部门等分别设置带宽配额,这样可以合理利用带宽资源,杜绝资源的浪费,也杜绝员工干与工作无关的事,如看在线**,下载大容量文件资料等等。
内容过滤
网络信息过滤:采用关键字进行内容过滤,可保护内网不受色情、暴力、反动、迷信等信息的入侵和干扰。
聊天软件、P2P软件控制:可针对QQ、MSN、YAHOO、SKYPE、GOOGLE TALK等聊天通讯软件进行管控和限制,还可限制或禁止如BT、电驴、迅雷等P2P软件的使用。
SSL ***
提供最佳远程安全存取解决方案,企业仅需透过最熟悉的网络浏览器接口(Web Browser),即可轻松连接到企业内部网络;即使未携带企业管控的笔记型计算机,利用家用计算机、公用计算机、PDA等,甚至是通过无线局域网络,都不影响安全联机的建立。
其他功能
实时图形化统计分析:记录所有网络封包的进出流量信息,可用做网络使用监控及统计记录;提供事件警报 (Event Alert)及日志记录管理功能;
支持3A认证:Authentication、Authorization、Accounting,即认证、授权、审计;
交换机联合防御:利用指定交换机进行联合防护,提升整个网络的安全系数和安全强度;
HA双机热备:支持双机备援,防止设备故障造成网络瘫痪,提升整个网络的可靠性;
远程唤醒(Wake on Lan):远程启动计算机。 软/硬件
软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡,如DNS Load Balance,CheckPoint Firewall-1 ConnectControl等,它的优点是基于特定环境,配置简单,使用灵活,成本低廉,可以满足一般的负载均衡需求。
软件解决方案缺点也较多,因为每台服务器上安装额外的软件运行会消耗系统不定量的资源,越是功能强大的模块,消耗得越多,所以当连接请求特别大的时候,软件本身会成为服务器工作成败的一个关键;软件可扩展性并不是很好,受到操作系统的限制;由于操作系统本身的Bug,往往会引起安全问题。
硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备,这种设备通常称之为负载均衡器,由于专门的设备完成专门的任务,独立于操作系统,整体性能得到大量提高,加上多样化的负载均衡策略,智能化的流量管理,可达到最佳的负载均衡需求。
负载均衡器有多种多样的形式,除了作为独立意义上的负载均衡器外,有些负载均衡器集成在交换设备中,置于服务器与Internet链接之间,有些则以两块网络适配器将这一功能集成到PC中,一块连接到Internet上,一块连接到后端服务器群的内部网络上。
一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵。
本地/全局
负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance,也叫地域负载均衡),本地负载均衡是指对本地的服务器群做负载均衡,全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。
本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题,并且不需花费昂贵开支购置性能卓越的服务器,充分利用现有设备,避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充升级,也只是简单地增加一个新的服务器到服务群中,而不需改变现有网络结构、停止现有的服务。
全局负载均衡主要用于在一个多区域拥有自己服务器的站点,为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器,从而获得最快的访问速度,也可用于子公司分散站点分布广的大公司通过Intranet(企业内部互联网)来达到资源统一合理分配的目的。
全局负载均衡有以下的特点:
实现地理位置无关性,能够远距离为用户提供完全的透明服务。
除了能避免服务器、数据中心等的单点失效,也能避免由于ISP专线故障引起的单点失效。
解决网络拥塞问题,提高服务器响应速度,服务就近提供,达到更好的访问质量。 负载均衡有三种部署方式:路由模式、桥接模式、服务直接返回模式。路由模式部署灵活,约60%的用户采用这种方式部署;桥接模式不改变现有的网络架构;服务直接返回(DSR)比较适合吞吐量大特别是内容分发的网络应用。约30%的用户采用这种模式。
路由模式(推荐)
路由模式的部署方式如上图。服务器的网关必须设置成负载均衡机的LAN口地址,且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小,能均衡任何下行流量。
桥接模式桥接模式配置简单,不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP(WAN口与LAN口是桥连接),所有的服务器与负载均衡均在同一逻辑网络中。参见下图:
由于这种安装方式容错性差,网络架构缺乏弹性,对广播风暴及其他生成树协议循环相关联的错误敏感,因此一般不推荐这种安装架构。
服务直接返回模式
如上图,这种安装方式负载均衡的LAN口不使用,WAN口与服务器在同一个网络中,互联网的客户端访问负载均衡的虚IP(VIP),虚IP对应负载均衡机的WAN口,负载均衡根据策略将流量分发到服务器上,服务器直接响应客户端的请求。因此对于客户端而言,响应他的IP不是负载均衡机的虚IP(VIP),而是服务器自身的IP地址。也就是说返回的流量是不经过负载均衡的。因此这种方式适用大流量高带宽要求的服务。 基础网络配置:
AX1000(config)#clock timezone Asia/Shanghai//设置时区
AX1000(config)#vlan 10//创建VLAN10
AX1000(config-vlan:10)# untagged ethernet 1 to 2//划分接口到VLAN10中
AX1000(config-vlan:10)# router-interface ve 10 //设置路由接口为Ve10,后面会给Ve10 配置地址的,这点和传统的二、三层交换不一样。
AX1000(config-vlan:10)# name “Web-Server-Outside”//也可以设置的备注
AX1000(config-vlan:10)#end//完成VLAN10的内容,和Cisco的命令一样。
AX1000(config)#vlan 20
AX1000(config-vlan:20)# untagged ethernet 3 to 4
AX1000(config-vlan:20)# router-interface ve 20
AX1000(config-vlan:20)# name “Web-Server-Inside”
AX1000(config-vlan:10)#end
AX1000(config)#interface ethernet 1//进入eth1口
AX1000(config-if:ethernet1)# enable //激活该接口
AX1000(config-if:ethernet1)# interface ethernet 2
AX1000(config-if:ethernet2)# enable
AX1000(config-if:ethernet2)#interface ethernet 3
AX1000(config-if:ethernet3)# enable
AX1000(config-if:ethernet3)#interface ethernet 4
AX1000(config-if:ethernet4)# enable
AX1000(config-if:ethernet4)#end
AX1000(config)#interface ve 10//进入Ve10接口并为其配置地址
AX1000(config-if:ve10)# ip address 1162551882 2552552550
AX1000(config-if:ve10)# ip nat outside//这和传统的路由交换设置一直,是需要做NAT处理的。
AX1000(config-if:ve10)#end
AX1000(config)#interface ve 20
AX1000(config-if:ve20)# ip address 19216811 2552552550
AX1000(config-if:ve20)# ip nat inside
AX1000(config-if:ve20)#end
首先添加服务器:
AX1000(config)#slbserver Web1192168111//添加服务器Web1,其IP地址为192168111
AX1000(config-real server)#port 80tcp//指定服务器开放的端口及端口类型
AX1000(config-real server-node port)#exit
AX1000(config-real server)#exit
AX1000(config)#slb server Web2192168112
AX1000(config-real server)#port 80tcp
AX1000(config-real server-node port)#end
检查添加的服务器状态是否正常:
AX1000#showslbserver //查看SLB信息
Total Number of Services configured: 2
Current = Current Connections, Total = Total Connections
Fwd-pkt = Forward packets, Rev-pkt = Reverse packets
Service Current Total Fwd-pkt Rev-pkt Peak-conn State
—————————————————————————————
Web1:80/tcp 0 0 0 0 0 Up
Web1: Total 0 0 0 0 0 Up
Web2:80/tcp 0 0 0 0 0 Up
Web2: Total 0 0 0 0 0 Up
发现全Up以后,则表示服务器的健康检查通过。
默认的健康检查方式是Ping检查服务器的存活状态。只有服务器状态为Up时,负载均衡器才会把会话分发给该服务器处理,从而最大可能性的保障用户的请求得到服务器的正常应答,这也是负载均衡器的基本功能之一。
在很多时候服务器作了安全策略,比如说防止Icmp的报文等等,就需要调整服务器的健康检查方式,具体内容后期提供。
创建服务组
AX1000(config)#slb service-group Webtcp
AX1000(config-slbsvc group)#member Web1:80
AX1000(config-slbsvc group)#member Web2:80
AX1000(config-slbsvc group)#end验证服务组工作正常
AX1000#show slb service-group
Total Number of Service Groups configured: 2
Current = Current Connections, Total = Total Connections
Fwd-p = Forward packets, Rev-p = Reverse packets
Peak-c = Peak connections
Service Group Name
Service Current Total Fwd-p Rev-p Peak-c
——————————————————————————-
Web State:All Up
Web1:80 0 0 0 0 0
Web2:80 0 0 0 0 0创建虚拟服务器:
其地址为:116255188235,即对外公布的真实的服务地址
AX1000(config)#slbvirtual-server VIP-WEB 116255188235//创建VIP
AX1000(config-slbvserver)#port 80http//指定VIP对公共用户开放的端口及端口类型,Web页面选择http
AX1000(config-slbvserver-vport)#service-group Web//该端口对应的服务组为Web
AX1000(config-slbvserver-vport)#end查看虚拟服务器状态
AX1000#showslbvirtual-server
Total Number of Virtual Services configured: 1
Virtual Server Name IP Current Total Request Response Peak
Service-Group Service connection connection packets packets connection
—————————————————————————————-
VIP-WEB(A) 116255188235 Up
port 80 http 0 0 0 0 0
Web 80/http 0 0 0 0 0
Total received conn attempts on this port: 0
域名的解析记录已设置为116255188235,所以只要直接访问即可看到效果。
验证:
AX1000#show session | in 116255188235//查看当前设备上访问116255188235的详细会话
Traffic Type Total
——————————————–
TCP Established 17
TCP Half Open 8
UDP 0
Non TCP/UDP IP sessions 0
Other 681295
Reverse NAT TCP 0
Reverse NAT UDP 0
Free Buff Count 0
Curr Free Conn 2031387
Conn Count 6926940
Conn Freed 6926870
TCP SYN Half Open 0
Conn SMP Alloc 103137
Conn SMP Free 102986
Conn SMP Aged 0
Conn Type 0 Available 6225920
Conn Type 1 Available 3112960
Conn Type 2 Available 2015155
Conn Type 3 Available 778240
Conn SMP Type 0 Available 6225920
Conn SMP Type 1 Available 3112960
Conn SMP Type 2 Available 1572712
Conn SMP Type 3 Available 778240
Prot Forward Source Forward Dest Reverse Source Reverse Dest Age Hash Flags
—————————————————————————————————————-
Tcp 110152232139:1927 116255188235:80 192168111:80 110152232139:80 0 1 OS
Tcp 110152232139:1927 116255188235:80 192168112:80 110152232139:80 0 1 OS
类型 源地址 目的地址服务器地址 服务器回报地址
关于 LVS 和 kube-proxy、F5 我们这里之后在和小伙伴分享, F5 没有接触过, LVS 的demo容器的方式一直没有成功, kube-proxy 这一块我还没学到,只是简单的了解
如果能深刻理解苦难,苦难就会给人带来崇高感 。 ——路遥
处理传输层到应用层的数据,为了能通一个URL或者IP+PORT将前端的访问分发到后台的多个服务器上
Dev 即开发角度的负载均衡。开发中的负载均衡一般是在 微服务 中涉及。服务提供方一般以多实例的形式提供服务, 负载均衡功能能够让服务调用方连接到合适的服务节点 。 并且, 服务节点选择的过程对服务调用方来说是透明的 。
所以这里理解为是客户端的负载均衡,是相对服务端负载均衡而言。
客户端负载均衡来讲,就是调用的客户端本身是知道所有服务信息,当需要调用服务上的接口的时候,客户端从自身所维护的服务列表中,根据提前配置好的负载均衡策略,自己挑选一个服务来调用,此时,客户端知道它所调用的是哪一个服务
在 Spring Cloud 中使用在 RestTemplate 进行服务调用,要想使用负载均衡功能,需要使用 Spring Cloud Ribbon 。
Spring Cloud Ribbon 是一个基于HTTP和TCP的客户端负载均衡工具,它基于 Nettlix Ribbon 实现。通过 Spring Cloud 的封装,可以让我们轻松地将面向服务的 REST 模板请求自动转换成客户端负载均衡的服务调用。
使用时需要给 RestTemplate 实例上添加一个 @LoadBalanced 注解即可,此时, RestTemplate 就会自动具备负载均衡功能,这个 负载均衡 就是 客户端负载均衡 。
Ops 即运维角度的负载均衡,这里的负载我们也称为服务端负载
所谓服务端负载均衡,比如传统的Nginx的方式,调用的客户端并不知道具体是哪个服务提供的服务,它也不关心,反正请求发送给Nginx, 或者hyproxy作为代理的服务器,然后 Ngixn 在请求负载任意服务,客户端只需要记着Nginx的地址即可。
Nginx 7层负载是最常见的一种负载,所谓7层负载,即应用层负载,即基于应用层协议(TELNET,SSH,HTTP,SMTP,POP…)做的代理,7层负载需要解析数据包的具体内容,需要消耗额外的cpu,然后根据具体内容(url, 参数, cookie, 请求头)匹配相应的路径,然后转发到相应的服务器。转发的过程是:建立和目标机器的连接,然后转发请求,收到响应数据再转发给请求客户端。
使用docker构建一个内部网络
内网里运行两个httpd服务
101122
101133
Ngixn实现到上面两个httpd服务的负载
运行Nginx容器
测试一下
所谓四层负载,即在传输层协议的基础上来做负载,基于TCP,UDP等协议,传输层的作用是确保数据被可靠的传输送到目标地址,能够让应用程序之间实现通信,所以彼此传递的是数据包,标识的只有IP+端口。不涉及具体的url其他结构解析。路径匹配等,不会涉及具体的应用层协议,所以理论上四层负载要比七成负载快。
nginx 四层代理是nginx190开始新增的功能,需要开启 --with-stream 模块,可以实现四层协议的转发、代理、负载等功能 。
这里的话,我们还是用容器的方式。配置方式和七层主要是配置文件的区别
启动4层负载的Nginx
测试一下
HAProxy 是一款提供高可用性、负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理软件,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。
HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要 会话保持 或 七层处理 。HAProxy完全可以支持数以万计的并发连接。
这里我们还用之前的连个httpd服务演示
haproxycfg配置文件
测试下
四层负载和七层负载也是配置文件的区别
运行容器并测试
0条评论