1:找分区或目录同步软件,某台服务器改动了自动把修改应用到别的服务器,比如红旗的HA。
2:换种建服务器的思路,后台用一台独立的服务器做数据库和文件服务器,用来存放数据库和上传的文件,另外的做负载均衡运行服务器,把不需要变动的网页程序放上面。
你可以试试在一台服务器做WEB和数据库,另外一台做WEB,两个WEB都连接那一个数据库,这样两个WEB内容就是同步的了,然后两台WEB间做负载,下边是我COPY的
网络负载均衡可以让客户端用一个逻辑Internet名称和虚拟IP地址(又称群集IP地址)访问群集,同时保留每台计算机各自的名称。下面,我们将在两台安装Windows Server 2003的普通计算机上,介绍网络负载均衡的实现及应用。
这两台计算机中,一台计算机名称为A,IP地址为19216807;另一台名为B,IP地址为19216808。规划网络负载均衡专用虚拟IP地址为19216809。当正式应用时,客户机只需要使用IP地址19216809来访问服务器,网络服务均衡会根据每台服务器的负载情况自动选择19216807或者19216808对外提供服务。具体实现过程如下:
在实现网络负载均衡的每一台计算机上,只能安装TCP/IP协议,不要安装任何其他的协议(如IPX协议或者NetBEUI协议),这可以从“网络连接属性”中查看。
第一步,分别以管理员身份登录A机和B机,打开两台机的“本地连接”属性界面,勾选“此连接使用下列项目”中的“负载均衡”项并进入“属性”对话框,将IP地址都设为19216809(即负载均衡专用IP),将子网掩码设置为2552552550;
第二步,分别进入A机和B机的“Internet协议(TCP/IP)”属性设置界面,点击“高级”按钮后,在d出的“高级TCP/IP设置”界面中添加IP地址19216809和子网掩码设置为2552552550。
第三步,退出两台计算机的“本地连接属性”窗口,耐心等一会儿让系统完成设置。
以后,如果这两台服务器不能满足需求,可以按以上步骤添加第三台、第四台计算机到网络负载均衡系统中以满足要求。
用IIS服务验证网络负载均衡
网络负载均衡配置好后,为了实现某项具体的服务,需要在网络负载均衡的计算机上安装相应的服务。例如,为了实现IIS网站的负载均衡,需要在相应的网络负载均衡服务器上安装IIS服务。为了让每个用户在通过网络负载均衡访问到不同的计算机时,能够访问到一致的数据,需要在网络负载均衡的每台计算机上保持数据的一致性。举例来说,实现了两个节点的IIS的网络负载均衡,为了保证两个网站内容的一致性,除了这两个IIS服务器的配置相同外,相应的网站数据必须一致。
为了检验网络负载均衡,我们可以通过IIS来进行验证,其他的一些应用如终端服务、Windows Media服务与IIS的应用与之相类似。在其他计算机上的IE浏览器中键入19216809,根据网络的负载,网络负载均衡会自动转发到A机或B 机。为了验证效果,你可以在浏览的时候,拔掉第一台计算机的网线或拔掉第二台机器的网线,将会发现浏览到的将是不同内容。当然,我们在测试的时候,为了验证网络负载均衡的效果,把两个网站设置成不一致的内容,而在正式应用的时候,网络负载均衡群集的每个节点计算机的内容将是一致的,这样不管使用哪一个节点响应,都能保证访问的内容是一致的。
如果负载均衡的主控节点挂了,会对负载均衡系统的正常运行产生一定的影响,但不一定会导致所有节点都瘫痪。在负载均衡系统中,通常有多个节点(包括主控节点和备份节点),它们之间通过协议进行通信和数据同步。如果主控节点挂了,备份节点通常会接管主控节点的工作,继续提供负载均衡服务。因此,只有在备份节点也无法正常工作时,整个负载均衡系统才会瘫痪。
当然,在实际的负载均衡系统中,还可能存在其他问题导致整个系统崩溃,如节点之间的通信故障、负载不均衡、服务故障等。因此,在设计和部署负载均衡系统时,需要考虑各种情况,采取相应的措施进行容错和备份,以确保整个系统的高可用性和可靠性。三种机制的优点,及这些机制的四种配置方法和架构方式。
三种转发机制的优缺点
◆Virtual Server via NAT
VS/NAT 的优点是服务器可以运行任何支持TCP/IP的 *** 作系统,它只需要一个IP地址配置在LVS主机上,服务器组可以用私有的IP地址。缺点是它的扩充能力有限,当服务器结点数目升到20时,LVS主机本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应封包都需要通过负载平衡LVS主机。在 Pentium 166主机上测得重写封包的平均延时为60us,假设TCP封包的平均长度为536 Bytes,则LVS主机的最大吞吐量为893 MBytes/s。再假设每台服务器的吞吐量为600KBytes/s,这样一个LVS主机可以带动16台服务器。
◆Virtual Server via IP Tunneling
在VS/TUN 的集群系统中,负载平衡LVS主机只将请求分配到不同的实际服务器,实际服务器将应答的资料直接返回给用户。这样,负载平衡LVS主机就可以处理巨量的请求,而不会成为系统的瓶颈。即使负载平衡LVS主机只有100Mbps的全双工网卡,虚拟服务器的最大吞吐量可以达到几Gbps。所以,VS/TUN可以极大地增加负载平衡LVS主机分配的服务器数量,它可以用来构建高性能超级服务器。VS/TUN技术对服务器的要求是所有的服务器必须支持"IP Tunneling"或者"IP Encapsulation"协议。目前,VS/TUN 的后端服务器主要运行Linux *** 作系统。因为"IP Tunneling"正成为各个 *** 作系统的标准协议,所以VS/TUN也会适用运行其它 *** 作系统的后端服务器。
◆Virtual Server via Direct Routing
同VS/TUN 一样,VS/DRLVS主机只处理客户到服务器端的连接,响应资料可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。同 VS/TUN相比,这种方法没有IP隧道的开销,但是要求负载平衡LVS主机与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备或者设备别名不作 ARP 响应。
四种分配方法(Load-balancing Methods)
不同的分配方法建构LVS主机成四种不同的排程
负载平衡排程是以连接为单位的。在>
市面上存在两种数据库负载均衡的思路:1
基于数据库连接的负载均衡:例如总共有100个数据库连接,50个连接登录到数据库机器A,另外50个连接登录到数据库机器B,这样每个连接中接下来的所有请求全都是发往同一台数据库机器的
这种数据库负载均衡的思路模拟了WEB上的负载均衡方法,但是由于WEB连接是短时间连接(连接建立后,获取需要的HTML等资源后,连接马上被关闭),而数据库连接是长时间连接(连接建立后,可长时间保持,客户可不停向数据库发送SQL请求,数据库做出回答,如此不断循环直到连接被人为或因错而断开为止),因此这种数据库负载均衡思路存在着明显的缺点:有可能会发生绝大部分的请求压力都集中到某台数据库机器上去,从而使得负载均衡效果失效
2
基于批处理请求的负载均衡:在建立数据库连接的时候,会同时与每台数据库服务器建立连接,之后针对客户端的每次请求,都会根据负载均衡算法,独立地选出某个数据库节点来执行这个请求
此种思路符合数据库长时间连接的特征,不存在上面所述的基于连接的负载均衡方法的缺点
市面上的负载均衡厂商,既有基于连接的,也有基于批处理请求的,用户需仔细辨别才能找到自己想要的合适产品
在软件系统的架构设计中,对集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。负载均衡本质上是用于将用户流量进行均衡减压的,因此在互联网的大流量项目中,其重要性不言而喻。早期的互联网应用,由于用户流量比较小,业务逻辑也比较简单,往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大,稍微好一点的系统,访问量就非常大了,并且系统功能也越来越复杂,那么单台服务器就算将性能优化得再好,也不能支撑这么大用户量的访问压力了,这个时候就需要使用多台机器,设计高性能的集群来应对。
那么,多台服务器是如何去均衡流量、如何组成高性能的集群的呢?
此时就需要请出 「负载均衡器」 入场了。
负载均衡(Load Balancer)是指把用户访问的流量,通过「负载均衡器」,根据某种转发的策略,均匀的分发到后端多台服务器上,后端的服务器可以独立的响应和处理请求,从而实现分散负载的效果。负载均衡技术提高了系统的服务能力,增强了应用的可用性。
目前市面上最常见的负载均衡技术方案主要有三种:
基于DNS负载均衡
基于硬件负载均衡
基于软件负载均衡
三种方案各有优劣,DNS负载均衡可以实现在地域上的流量均衡,硬件负载均衡主要用于大型服务器集群中的负载需求,而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中,这三种是可以组合在一起使用。下面来详细讲讲:
基于DNS负载均衡
基于DNS来做负载均衡其实是一种最简单的实现方案,通过在DNS服务器上做一个简单配置即可。
其原理就是当用户访问域名的时候,会先向DNS服务器去解析域名对应的IP地址,这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP,北方的用户来访问的话,我就返回北京业务服务器所在的IP。
在这个模式下,用户就相当于实现了按照「就近原则」将请求分流了,既减轻了单个集群的负载压力,也提升了用户的访问速度。
使用DNS做负载均衡的方案,天然的优势就是配置简单,实现成本非常低,无需额外的开发和维护工作。
但是也有一个明显的缺点是:当配置修改后,生效不及时。这个是由于DNS的特性导致的,DNS一般会有多级缓存,所以当我们修改了DNS配置之后,由于缓存的原因,会导致IP变更不及时,从而影响负载均衡的效果。
另外,使用DNS做负载均衡的话,大多是基于地域或者干脆直接做IP轮询,没有更高级的路由策略,所以这也是DNS方案的局限所在。
基于硬件负载均衡
硬件的负载均衡那就比较牛逼了,比如大名鼎鼎的 F5 Network Big-IP,也就是我们常说的 F5,它是一个网络设备,你可以简单的理解成类似于网络交换机的东西,完全通过硬件来抗压力,性能是非常的好,每秒能处理的请求数达到百万级,即 几百万/秒 的负载,当然价格也就非常非常贵了,十几万到上百万人民币都有。
因为这类设备一般用在大型互联网公司的流量入口最前端,以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。
采用 F5 这类硬件做负载均衡的话,主要就是省心省事,买一台就搞定,性能强大,一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略,同时还具有一些防火墙等安全功能。但是缺点也很明显,一个字:贵。
基于软件负载均衡
软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡,分为7层协议 和 4层协议。
网络协议有七层,基于第四层传输层来做流量分发的方案称为4层负载均衡,例如 LVS,而基于第七层应用层来做流量分发的称为7层负载均衡,例如 Nginx。这两种在性能和灵活性上是有些区别的。
基于4层的负载均衡性能要高一些,一般能达到 几十万/秒 的处理量,而基于7层的负载均衡处理量一般只在 几万/秒 。
基于软件的负载均衡的特点也很明显,便宜。在正常的服务器上部署即可,无需额外采购,就是投入一点技术去优化优化即可,因此这种方式是互联网公司中用得最多的一种方式。
上面讲完了常见的负载均衡技术方案,那么接下来咱们看一下,在实际方案应用中,一般可以使用哪些均衡算法?
轮询策略
负载度策略
响应策略
哈希策略
下面来分别介绍一下这几种均衡算法/策略的特点:
NO1—— Random 随机
这是最简单的一种,使用随机数来决定转发到哪台机器上。
优点:简单使用,不需要额外的配置和算法。
缺点:随机数的特点是在数据量大到一定量时才能保证均衡,所以如果请求量有限的话,可能会达不到均衡负载的要求。
NO2—— Round Robin 轮询
这个也很简单,请求到达后,依次转发,不偏不向。每个服务器的请求数量很平均。
缺点:当集群中服务器硬件配置不同、性能差别大时,无法区别对待。引出下面的算法。
NO3—— Weighted Round Robin 加权轮询
这种算法的出现就是为了解决简单轮询策略中的不足。在实际项目中,经常会遇到这样的情况。
比如有5台机器,两台新买入的性能等各方面都特别好,剩下三台老古董。这时候我们设置一个权重,让新机器接收更多的请求。物尽其用、能者多劳嘛!
这种情况下,“均衡“就比较相对了,也没必要做到百分百的平均。
NO4—— Least Connections 最少连接
这是最符合负载均衡算法的一个。需要记录每个应用服务器正在处理的连接数,然后将新来的请求转发到最少的那台上。
NO5—— Source Hashing 源地址散列
根据请求的来源ip进行hash计算,然后对应到一个服务器上。之后所有来自这个ip的请求都由同一台服务器处理。
>
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)