F5配置.docx
- 文档编号:11297183
- 上传时间:2023-02-26
- 格式:DOCX
- 页数:26
- 大小:637.60KB
F5配置.docx
《F5配置.docx》由会员分享,可在线阅读,更多相关《F5配置.docx(26页珍藏版)》请在冰豆网上搜索。
F5配置
第1章F5基础
1.1集群
1.1.1背景介绍
Internet的飞速发展给网络带宽和服务器带来巨大的挑战。
从网络技术的发展来看,网络带宽的增长远高于处理器速度和内存访问速度的增长。
大部分网站都需要提供每天24小时、每星期7天的服务,对电子商务等网站尤为突出,任何服务中断和关键性的数据丢失都会造成直接的商业损失。
所以这对网络服务的可靠性提出了越来越高的要求。
现在Web服务中越来越多地使用CGI、动态主页等CPU密集型应用,这对服务器的性能有较高要求。
未来的网络服务会提供更丰富的内容、更好的交互性、更高的安全性等,需要服务器具有更强的CPU和I/O处理能力。
例如,通过HTTPS(SecureHTTP)取一个静态页面需要的处理性能比通过HTTP的高一个数量级,HTTPS正在被电子商务站点广为使用。
所以,网络流量并不能说明全部问题,要考虑到应用本身的发展也需要越来越强的处理性能。
因此,对用硬件和软件方法实现高可伸缩、高可用网络服务的需求不断增长,这种需求可以归结以下几点:
可伸缩性(Scalability):
当服务的负载增长时,系统能被扩展来满足需求,且不降低服务质量。
高可用性(Availability):
尽管部分硬件和软件会发生故障,整个系统的服务必须是每天24小时每星期7天可用的。
可管理性(Manageability):
整个系统可能在物理上很大,但应该容易管理。
价格有效性(Cost-effectiveness):
整个系统实现是经济的、易支付的。
1.1.2服务器集群系统
对称多处理(SymmetricMulti-Processor,简称SMP)是由多个对称的处理器、和通过总线共享的内存和I/O部件所组成的计算机系统。
SMP是一种低并行度的结构,是我们通常所说的"紧耦合多处理系统",它的可扩展能力有限,但SMP的优点是单一系统映像(SingleSystemImage),有共享的内存和I/O,易编程。
由于SMP的可扩展能力有限,SMP服务器显然不能满足高可伸缩、高可用网络服务中的负载处理能力不断增长需求。
随着负载不断增长,会导致服务器不断地升级。
这种服务器升级有下列不足:
一是升级过程繁琐,机器切换会使服务暂时中断,并造成原有计算资源的浪费;二是越往高端的服务器,所花费的代价越大;三是SMP服务器是单一故障点(SinglePointofFailure),一旦该服务器或应用软件失效,会导致整个服务的中断。
通过高性能网络或局域网互联的服务器集群正成为实现高可伸缩的、高可用网络服务的有效结构。
这种松耦合结构的服务器集群系统有下列优点:
性能:
网络服务的工作负载通常是大量相互独立的任务,通过一组服务器分而治之,可以获得很高的整体性能。
性能/价格比:
组成集群系统的PC服务器或RISC服务器和标准网络设备因为大规模生产降低成本,价格低,具有最高的性能/价格比。
若整体性能随着结点数的增长而接近线性增加,该系统的性能/价格比接近于PC服务器。
所以,这种松耦合结构比紧耦合的多处理器系统具有更好的性能/价格比。
可伸缩性:
集群系统中的结点数目可以增长到几千个,乃至上万个,其伸缩性远超过单台超级计算机。
高可用性:
在硬件和软件上都有冗余,通过检测软硬件的故障,将故障屏蔽,由存活结点提供服务,可实现高可用性。
当然,用服务器集群系统实现可伸缩网络服务也存在很多挑战性的工作:
透明性(Transparency):
如何高效地使得由多个独立计算机组成的松藕合的集群系统构成一个虚拟服务器;客户端应用程序与集群系统交互时,就像与一台高性能、高可用的服务器交互一样,客户端无须作任何修改。
部分服务器的切入和切出不会中断服务,这对用户也是透明的。
性能(Performance):
性能要接近线性加速,这需要设计很好的软硬件的体系结构,消除系统可能存在的瓶颈。
将负载较均衡地调度到各台服务器上。
高可用性(Availability):
需要设计和实现很好的系统资源和故障的监测和处理系统。
当发现一个模块失败时,要这模块上提供的服务迁移到其他模块上。
在理想状况下,这种迁移是即时的、自动的。
可管理性(Manageability):
要使集群系统变得易管理,就像管理一个单一映像系统一样。
在理想状况下,软硬件模块的插入能做到即插即用(Plug&Play)。
可编程性(Programmability):
在集群系统上,容易开发应用程序。
1.2Linux集群系统
针对高可伸缩、高可用网络服务的需求,我们给出了基于IP层和基于内容请求分发的负载平衡调度解决方法,并在Linux内核中实现了这些方法,将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。
虚拟服务器的体系结构如图1所示,一组服务器通过高速的局域网或者地理分布的广域网相互连接,在它们的前端有一个负载调度器(LoadBalancer)。
负载调度器能无缝地将网络请求调度到真实服务器上,从而使得服务器集群的结构对客户是透明的,客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。
客户程序不受服务器集群的影响不需作任何修改。
系统的伸缩性通过在服务集群中透明地加入和删除一个节点来达到,通过检测节点或服务进程故障和正确地重置系统达到高可用性。
由于我们的负载调度技术是在Linux内核中实现的,我们称之为Linux虚拟服务器(LinuxVirtualServer)。
图1:
虚拟服务器的结构
LinuxVirtualServer项目的目标:
使用集群技术和Linux操作系统实现一个高性能、高可用的服务器,它具有很好的可伸缩性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。
目前,LVS项目已提供了一个实现可伸缩网络服务的LinuxVirtualServer框架,如图2所示。
在LVS框架中提供了含有三种IP负载均衡技术的IP虚拟服务器软件IPVS、基于内容请求分发的内核Layer-7交换机KTCPVS和集群管理软件。
可以利用LVS框架实现高可伸缩的、高可用的Web、Cache、Mail和Media等网络服务;在此基础上,可以开发支持庞大用户数的、高可伸缩的、高可用的电子商务应用。
图2:
Linux虚拟服务器框架
1.2.1LinuxIPVS
在调度器的实现技术中,IP负载均衡技术是效率最高的。
在已有的IP负载均衡技术中有通过网络地址转换(NetworkAddressTranslation)将一组服务器构成一个高性能的、高可用的虚拟服务器,我们称之为VS/NAT技术(VirtualServerviaNetworkAddressTranslation),大多数商品化的IP负载均衡调度器产品都是使用此方法,如Cisco的LocalDirector、F5的Big/IP和Alteon的ACEDirector。
在分析VS/NAT的缺点和网络服务的非对称性的基础上,我们提出通过IP隧道实现虚拟服务器的方法VS/TUN(VirtualServerviaIPTunneling),和通过直接路由实现虚拟服务器的方法VS/DR(VirtualServerviaDirectRouting),它们可以极大地提高系统的伸缩性。
所以,IPVS软件实现了这三种IP负载均衡技术,它们的大致原理如下:
(1)VirtualServerviaNetworkAddressTranslation(VS/NAT):
通过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文通过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。
(2)VirtualServerviaIPTunneling(VS/TUN):
采用NAT技术时,由于请求和响应报文都必须经过调度器地址重写,当客户请求越来越多时,调度器的处理能力将成为瓶颈。
为了解决这个问题,调度器把请求报文通过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,所以调度器只处理请求报文。
由于一般网络服务应答比请求报文大许多,采用VS/TUN技术后,集群系统的最大吞吐量可以提高10倍。
(3)VirtualServerviaDirectRouting(VS/DR):
VS/DR通过改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。
同VS/TUN技术一样,VS/DR技术可极大地提高集群系统的伸缩性。
这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,但是要求调度器与真实服务器都有一块网卡连在同一物理网段上。
针对不同的网络服务需求和服务器配置,IPVS调度器实现了如下八种负载调度算法:
(1)轮叫(RoundRobin):
调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。
(2)加权轮叫(WeightedRoundRobin):
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。
这样可以保证处理能力强的服务器处理更多的访问流量。
调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
(3)最少链接(LeastConnections):
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。
如果集群系统的真实服务器具有相近的系统性能,采用"最小连接"调度算法可以较好地均衡负载。
(4)加权最少链接(WeightedLeastConnections):
在集群系统中的服务器性能差异较大的情况下,调度器采用“加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。
调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
(5)基于局部性的最少链接(Locality-BasedLeastConnections):
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。
该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。
(6)带复制的基于局部性最少链接(Locality-BasedLeastConnectionswithReplication):
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。
它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。
该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组,按"最小连接"原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按“最小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。
同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。
(7)目标地址散列(DestinationHashing):
“目标地址散列”调度算法根据请求的目标IP地址,作为散列键(HashKey)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
(8)源地址散列(SourceHashing):
“源地址散列”调度算法根据请求的源IP地址,作为散列键(HashKey)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
1.2.2虚拟服务器的实现方法
在网络服务中,一端是客户程序,另一端是服务程序,在中间可能有代理程序。
由此看来,可以在不同的层次上实现多台服务器的负载均衡。
用集群解决网络服务性能问题的现有方法主要分为以下四类。
1.2.2.1基于RR-DNS的解决方法
NCSA的可伸缩的WEB服务器系统就是最早基于RR-DNS(Round-RobinDomainNameSystem)的原型系统。
它的结构和工作流程如下图所示:
图3:
基于RR-DNS的可伸缩WEB服务器
有一组WEB服务器,他们通过分布式文件系统AFS(AndrewFileSystem)来共享所有的HTML文档。
这组服务器拥有相同的域名(如www.ncsa.uiuc.edu),当用户按照这个域名访问时,RR-DNS服务器会把域名轮流解析到这组服务器的不同IP地址,从而将访问负载分到各台服务器上。
这种方法带来几个问题。
第一,域名服务器是一个分布式系统,是按照一定的层次结构组织的。
当用户就域名解析请求提交给本地的域名服务器,它会因不能直接解析而向上一级域名服务器提交,上一级域名服务器再依次向上提交,直到RR-DNS域名服器把这个域名解析到其中一台服务器的IP地址。
可见,从用户到RR-DNS间存在多台域名服器,而它们都会缓冲已解析的名字到IP地址的映射,这会导致该域名服器组下所有用户都会访问同一WEB服务器,出现不同WEB服务器间严重的负载不平衡。
为了保证在域名服务器中域名到IP地址的映射不被长久缓冲,RR-DNS在域名到IP地址的映射上设置一个TTL(TimeToLive)值,过了这一段时间,域名服务器将这个映射从缓冲中淘汰。
当用户请求,它会再向上一级域名服器提交请求并进行重新影射。
这就涉及到如何设置这个TTL值,若这个值太大,在这个TTL期间,很多请求会被映射到同一台WEB服务器上,同样会导致严重的负载不平衡。
若这个值太小,例如是0,会导致本地域名服务器频繁地向RR-DNS提交请求,增加了域名解析的网络流量,同样会使RR-DNS服务器成为系统中一个新的瓶颈。
第二,用户机器会缓冲从名字到IP地址的映射,而不受TTL值的影响,用户的访问请求会被送到同一台WEB服务器上。
由于用户访问请求的突发性和访问方式不同,例如有的人访问一下就离开了,而有的人访问可长达几个小时,所以各台服务器间的负载仍存在倾斜(Skew)而不能控制。
假设用户在每个会话中平均请求数为20,负载最大的服务器获得的请求数额高于各服务器平均请求数的平均比率超过百分之三十。
也就是说,当TTL值为0时,因为用户访问的突发性也会存在着较严重的负载不平衡。
第三,系统的可靠性和可维护性差。
若一台服务器失效,会导致将域名解析到该服务器的用户看到服务中断,即使用户按“Reload”按钮,也无济于事。
系统管理员也不能随时地将一台服务器切出服务进行系统维护,如进行操作系统和应用软件升级,这需要修改RR-DNS服务器中的IP地址列表,把该服务器的IP地址从中划掉,然后等上几天或者更长的时间,等所有域名服器将该域名到这台服务器的映射淘汰,和所有映射到这台服务器的客户机不再使用该站点为止。
1.2.2.2基于客户端的解决方法
基于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识,进而把以负载均衡的方式将请求发到不同的服务器。
例如,NetscapeNavigator浏览器访问Netscape的主页时,它会随机地从一百多台服务器中挑选第N台,最后将请求送往。
然而,这不是很好的解决方法,Netscape只是利用它的Navigator避免了RR-DNS解析的麻烦,当使用IE等其他浏览器不可避免的要进行RR-DNS解析。
SmartClient是Berkeley做的另一种基于客户端的解决方法。
服务提供一个JavaApplet在客户方浏览器中运行,Applet向各个服务器发请求来收集服务器的负载等信息,再根据这些信息将客户的请求发到相应的服务器。
高可用性也在Applet中实现,当服务器没有响应时,Applet向另一个服务器转发请求。
这种方法的透明性不好,Applet向各服务器查询来收集信息会增加额外的网络流量,不具有普遍的适用性。
1.2.2.3基于应用层负载均衡调度的解决方法
多台服务器通过高速的互联网络连接成一个集群系统,在前端有一个基于应用层的负载调度器。
当用户访问请求到达调度器时,请求会提交给作负载均衡调度的应用程序,分析请求,根据各个服务器的负载情况,选出一台服务器,重写请求并向选出的服务器访问,取得结果后,再返回给用户。
应用层负载均衡调度的典型代表有Zeus负载调度器、pWeb、Reverse-Proxy和SWEB等。
Zeus负载调度器是Zeus公司的商业产品,它是在ZeusWeb服务器程序改写而成的,采用单进程事件驱动的服务器结构。
pWeb就是一个基于Apache1.1服务器程序改写而成的并行WEB调度程序,当一个HTTP请求到达时,pWeb会选出一个服务器,重写请求并向这个服务器发出改写后的请求,等结果返回后,再将结果转发给客户。
Reverse-Proxy利用Apache1.3.1中的Proxy模块和Rewrite模块实现一个可伸缩WEB服务器,它与pWeb的不同之处在于它要先从Proxy的cache中查找后,若没有这个副本,再选一台服务器,向服务器发送请求,再将服务器返回的结果转发给客户。
SWEB是利用HTTP中的redirect错误代码,将客户请求到达一台WEB服务器后,这个WEB服务器根据自己的负载情况,自己处理请求,或者通过redirect错误代码将客户引到另一台WEB服务器,以实现一个可伸缩的WEB服务器。
基于应用层负载均衡调度的多服务器解决方法也存在一些问题。
第一,系统处理开销特别大,致使系统的伸缩性有限。
当请求到达负载均衡调度器至处理结束时,调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制;需要进行二次TCP连接,一次是从用户到调度器,另一次是从调度器到真实服务器;需要对请求进行分析和重写。
这些处理都需要不小的CPU、内存和网络等资源开销,且处理时间长。
所构成系统的性能不能接近线性增加的,一般服务器组增至3或4台时,调度器本身可能会成为新的瓶颈。
所以,这种基于应用层负载均衡调度的方法的伸缩性极其有限。
第二,基于应用层的负载均衡调度器对于不同的应用,需要写不同的调度器。
以上几个系统都是基于HTTP协议,若对于FTP、Mail、POP3等应用,都需要重写调度器。
1.2.2.4基于IP层负载均衡调度的解决方法
用户通过虚拟IP地址(VirtualIPAddress)访问服务时,访问请求的报文会到达负载调度器,由它进行负载均衡调度,从一组真实服务器选出一个,将报文的目标地址VirtualIPAddress改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将报文发送给选定的服务器。
真实服务器的回应报文经过负载调度器时,将报文的源地址和源端口改为VirtualIPAddress和相应的端口,再把报文发给用户。
Berkeley的MagicRouter、Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP等都是使用网络地址转换方法。
MagicRouter是在Linux1.3版本上应用快速报文插入技术,使得进行负载均衡调度的用户进程访问网络设备接近核心空间的速度,降低了上下文切换的处理开销,但并不彻底,它只是研究的原型系统,没有成为有用的系统存活下来。
Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是非常昂贵的商品化系统,它们支持部分TCP/UDP协议,有些在ICMP处理上存在问题。
1.2.3VS/NAT
由于IPv4中IP地址空间的日益紧张和安全方面的原因,很多网络使用保留IP地址(10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0)。
这些地址不在Internet上使用,而是专门为内部网络预留的。
当内部网络中的主机要访问Internet或被Internet访问时,就需要采用网络地址转换(NetworkAddressTranslation,以下简称NAT),将内部地址转化为Internets上可用的外部地址。
NAT的工作原理是报文头(目标地址、源地址和端口等)被正确改写后,客户相信它们连接一个IP地址,而不同IP地址的服务器组也认为它们是与客户直接相连的。
由此,可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。
VS/NAT的体系结构如图4所示。
在一组服务器前有一个调度器,它们是通过Switch/HUB相连接的。
这些服务器提供相同的网络服务、相同的内容,即不管请求被发送到哪一台服务器,执行结果是一样的。
服务的内容可以复制到每台服务器的本地硬盘上,可以通过网络文件系统(如NFS)共享,也可以通过一个分布式文件系统来提供。
图4:
VS/NAT的体系结构
客户通过VirtualIPAddress(虚拟服务的IP地址)访问网络服务时,请求报文到达调度器,调度器根据连接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址VirtualIPAddress改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器。
同时,调度器在连接Hash表中记录这个连接,当这个连接的下一个报文到达时,从连接Hash表中可以得到原选定服务器的地址和端口,进行同样的改写操作,并将报文传给原选定的服务器。
当来自真实服务器的响应报文经过调度器时,调度器将报文的源地址和源端口改为VirtualIPAddress和相应的端口,再把报文发给用户。
当连接终止或超时,调度器将这个连接从连接Hash表中删除。
在一些网络服务中,它们将IP地址或者端口号在报文的数据中传送,若我们只对报文头的IP地址和端口号作转换,这样就会出现不一致性,服务会中断。
所以,针对这些服务,需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。
我们所知道有这个问题的网络服务有FTP、IRC、H.323、CUSeeMe、RealAudio、RealVideo、Vxtreme/Vosiac、VDOLive、VIVOActive、TrueSpeech、RSTP、PPTP、StreamWorks、NTTAudioLink、NTTSoftwareVision、YamahaMIDPlug、iChatPager、Quake和Diablo。
下面,举个例子来进一步说明VS/NAT,如图5所示:
图5:
VS/NAT的例子
VS/NAT的配置如下表所示,所有到IP地址为202.103.106.5和端口为80的流量都被负载均衡地调度的真实服务器172.16.0.2:
80和172.16.0.3:
8000上。
目标地址为202.103.106.5:
21的报文被转移到172.16.0.3:
21上。
而到其他端口的报文将被拒绝。
Protocol
VirtualIPAddress
Port
RealIPAddress
Port
Weight
TCP
202.103.106.5
80
172.16.0.2
80
1
172.16.0.3
8000
2
TCP
202.103.106.5
21
172.16.0.3
21
1
从以下的例子中,我们可以更详细地了解报文改写的流程。
访问Web服务的报文可能有以下的源地址和目标地址:
SOURCE
202.100.1.2:
3456
DES
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- F5 配置