负载均衡器技术Nginx和F5的优缺点对比
2017年12月21日 10:51:29 手撕代码 阅读数:14553
nginx(一) nginx详解
nginx是一个被广泛使用的集群架构组件,我们有必要对它有足够的了解。下面将先认识nginx:包括应用场景、nginx基本架构、功能特性、并发模型以及配置说明,最后我们再总结下,为什么选择nginx的原因。
1、nginx应用
nginx (engine x)是一个可以作为HTTP WEB服务器、反向代理服务器、邮件代理服务器和一个通用的TCP / UDP代理服务器(1.9.0版本后)的多功能架构组件,同时也可以提供一定的缓存服务功能。
nginx应用比较多的场景是WEB服务器和反向代理服务器,这两个场景的相关配置后面的文章我们会分别操作配置,这里先来认识下:
**1、WEB服务器:**这是应用比较多的场景,配置虚拟主机提供HTTP WEB服务。可以先通过动态/静态内容分离,而后为静态内容(html/css/js/图片等)提供HTTP访问功能;而动态内容可以整合代理模块,代理给上游服务器,来支持对外部程序的直接调用或者解析,如FastCGI支持PHP。
**2、反向代理服务器:**这是应用非常多的场景,为后端服务器代理。接收客户端请求,根据负载均衡策略转发给后端多个上游服务器处理;然后再等待后端服务器返回请求响应,接收到后再返回给请求的客户端。
2、nginx基本架构
1、一个master进程生成多个worker子进程(每个进程只有一个线程),一个worker响应多个用户请求;
2、非阻塞、IO复用、事件驱动:select,poll, epoll, kqueue,/dev/poll;
3、支持sendfile,sendfile64;
4、支持文件AIO(异步I/O);
5、支持mmap;
6、灵活的文件配置;
7、占用内存小:10,000个非活动HTTP保持连接占用大约2.5M内存。
3、nginx功能特性
3-1、基本功能
实现与服务静态文件(静态资源的web服务器),能缓存打开的文件描述符;
反向代理服务器,缓存、负载均衡、健康状态检测;
支持FastCGI;
模块化机制,非DSO机制,支持多种过滤器gzip,SSI和图像的模块完成图形大小调整等;
支持SSL;
3-2、扩展功能
基于名称和IP做虚拟主机;
支持keeplive;
支持平滑配置更新或程序版本升级;
定制访问日志,支持使用日志缓存以提高性能;
支持URL rewrite;
支持路径别名;
支持基于IP及用户的认证;
支持速率限制,并发数限制等;
4、nginx并发模型
如前图,一个master进程生成多个worker子进程(每个进程只有一个线程),一个worker响应多个用户请求。如果单进程启动:仅有一个进程,既充当master进程的角色,也充当worker进程的角色。
4-1、master进程
充当整个进程组与用户的交互接口(接收来自外界的信号,向各worker进程发送信号),同时监控worker进程的运行状态。
它不需要处理网络事件,不负责业务的执行,只会通过管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。
4-2、worker进程
主要任务是处理基本的网络事件,完成具体的任务逻辑。多个worker进程之间是对等的,互相独立的。
worker进程主要关注点是与客户端或后端服务器(此时nginx作为中间代理)之间的数据可读/可写等I/O交互事件,所以工作进程的阻塞点是在像select()、epoll_wait()等这样的I/O多路复用函数调用处,以等待发生数据可读/写事件。当然也可能被新收到的进程信号中断。
** worker进程个数**:
** **如果负载以CPU密集型应用为主,一般会设置与机器cpu核数一致或少一个(用来处理用户等其他任务);
** **如果负载以IO密集型为主,如响应大量内容给客户端,则worker数应该为CPU个数的1.5或2倍。
** **因为更多的worker数,只会导致进程来竞争cpu资源了,从而带来不必要的上下文切换。而且,nginx为了更好的利用多核特性,具有cpu绑定选项,我们可以将某一个进程绑定在某一个核上,这样就不会因为进程的切换带来cache的失效。
** **更具体的可以根据公式:Nthread = Ncpu*Ucpu*(1+W/C),Ncpu是cpu的个数,Ucpu是cpu的使用率,W为等待时间,C为计算时间。这时需要通过监控工具来获取相应数据来计算。
** **最后,再以监控工具数据为准进行微调。
4-3、并发处理
A、在master进程里面,先创建socket,并bind、listen在80端口(所以master进程需要root权限);
B、然后再fork出多个worker进程,这样每个worker进程都可以去accept这个socket(会产生惊群问题), 或者使用锁机制,让抢到锁的一个worker进程去accept这个socket,注意这里一般使用select/poll/epoll机制来解决accept阻塞问题;
C、当一个新连接进来后,而只有抢到锁的一个进程可以accept这个连接进行处理(也是放入epoll中);
D、抢到锁的worker进程accept到新连接后,会立即释放锁;然后所有worker进程再次参与抢锁,这样就回到了第二步,进行循环处理并发连接;
4-4、惊群问题
A、生产原因:像上面第二步,多个worker进程等待同一个socket的连接事件,当这个事件发生时,这些进程被同时唤醒,就是惊群。
注意,在linux2.6内核上,accept系统调用已经不存在惊群,但用epoll机制来解决accept阻塞问题,epoll_wait会有惊群问题(新增 EPOLLEXCLUSIVE 选项解决了)。
B、导致后果:许多worker进程被内核重新调度唤醒,只有一个进程可以accept这个连接进行处理,其他余者皆失败,导致性能浪费。
C、nginx解决方案:使用锁机制,让抢到锁的一个worker进程去accept(epoll_wait)这个socket;如果操作系统支持原子整型,才会使用共享内存实现原子上锁,否则使用文件上锁。
5、Nginx配置说明
5-1、配置文件区域说明
nginx主要配置文件nginx.conf,里面主要包括以下几个配置区域,如下表:
配置区域 | 说明 |
main块 | 配置影响nginx全局的指令。一般有运行nginx服务器的用户组,nginx进程pid存放路径,日志存放路径,配置文件引入,允许生成worker process数等。 |
events块 | 配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数,选取哪种事件驱动模型处理连接请求,是否允许同时接受多个网路连接,开启多个网络连接序列化等。 |
http块 | 可以嵌套多个server,配置代理,缓存,日志定义等绝大多数功能和第三方模块的配置。如文件引入,mime-type定义,日志自定义,是否使用sendfile传输文件,连接超时时间,单连接请求数等。 |
upstream块 | 配置HTTP负载均衡器分配流量到几个应用程序服务器。 |
server块 | 配置虚拟主机的相关参数,一个http中可以有多个server。 |
location块 | 配置请求的路由,以及允许根据用户请求的URI来匹配指定的各location以进行访问配置;匹配到时,将被location块中的配置所处理。 |
1 | 1 |
** nginx文件结构**如下:
[plain] view plain copy
- … #main全局块
- events { #events块
- …
- }
- http #http块
- {
- … #http全局块
- upstream … # upstream负载均衡块
- {
- …
- }
- server #server块
- {
- … #server全局块
- location [PATTERN] #location块
- {
- …
- }
- location [PATTERN]
- {
- …
- }
- }
- server
- {
- …
- }
- … #http全局块
- }
5-2、Nginx核心功能配置
nginx核心功能配置主要是main和events的顶层全局配置,都是配置nginx核心模块(ngx_core_module),管理服务器级别的行为。下表包含是大部分常用的配置选项,更多配置请参考官方文档:http://nginx.org/en/docs/ngx_core_module.html
配置类别 | 配置选项 | 上下文 | 语法 | 默认值 | 功能描述 |
基本配置 | user | main | user username [groupname] | nobody | 以那个用户身份运行,以在configure指定的用户为准 |
pid | main | pid /path/to/pid_filename | nginx.pid | 指定nginx的pid文件 | |
worker_rlimit_nofile | main | 受linux内核文件描述符数量限制 | 指定一个worker进程所能够打开的句柄数。因为Linux对每个进程所能打开的文件描述数量是有限制的,默认一般是1024个,可通过ulimit -n FILECNT或/etc/securit/limits.conf配置修改linux默认能打开的文件句柄数限制。建议值为:系统最大数量/进程数。但进程间工作量并不是平均分配的,所以可以设置在大一些。推荐值为:655350。 | ||
优化性能相关配置 | worker_procrsses | main | worker_processes number | auto; | 1 | work进程的个数.如果负载以CPU密集型应用为主,一般会设置与机器cpu核数一致或少一个(用来处理用户等其他任务),如果负载以IO密集型为主,如响应大量内容给客户端,则worker数应该为CPU个数的1.5或2倍。因为更多的worker数,只会导致进程来竞争cpu资源了,从而带来不必要的上下文切换。而且,nginx为了更好的利用多核特性,具有cpu绑定选项,我们可以将某一个进程绑定在某一个核上,这样就不会因为进程的切换带来cache的失效。 |
worker_cpu_affinity | main | worker_cpu_affinity cpumask …; | 无,不绑定 | 将工作进程绑定到特定的CPU上,减少CPU在进程之间切换的开销。用二进制bit位表示进程绑定在哪个CPU内核。如4工作进程4内核:worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; 2工作进程4内核: worker_processes 2; worker_cpu_affinity 0101 1010; | |
worker_priority | main | worker_priority number; | 0 | 工作进程调度优先级,-20到19之间的值,值越小越优先调用。如果系统同时运行多个任务,你可能需要提高nginx的工作进程的优先级 | |
timer_resolution | main | timer_resolution interval; | 无 | 每次内核事件调用返回时,都会使用gettimeday()来更新nginx缓存时钟;timer_resolution用于定义每隔多久才会由gettimeday()更新一次缓存时钟;x86-64系统上,gettimeday()代价已经很小,可以忽略此配置 | |
ssl_engine | main | ssl_engine device; | 无 | 在存在ssl硬件加速器的服务器上,指定所使用的ssl硬件加速设备。由于https链接所消耗的资源比http大得多,可能要多消耗5、6倍,最好有专门处理ssl的硬件设备 | |
事件相关配置 | worker_commections | events | worker_connections number; | 512 | 每个worker能够并发响应的最大请求数。系统每处理一个请求就要消耗一个套接字文件,如果为代理服务器的话,worker_rlimit_nofile=worker_commections*2 |
use | events | use method; | 无,自动选择 | 指定使用哪种模型(select/poll/epoll),建议让nginx自动选择,linux内核2.6以上一般能使用epoll,提高性能。 | |
accept_mutex | events | accept_mutex on | off; | Off(1.11.3版本前默认on) | 是否打开nginx的accept锁;此锁能够让多个worker进行轮流地、序列化地与新的客户端建立连接;而通常当一个worker进程的负载达到其上限的7/8,master就尽可能不将请求调度至worker. 1.11.3版本epoll支持EPOLLEXCLUSIVE 标记,不再有惊群问题 。 | |
accept_mutex_delay | events | accept_mutex_delay time; | 500ms | 使用accept锁以后,只有一个worker能取得锁,一个worker进程为取得accept锁的等待时长,即用户建立等待的时间,如果某worker进程在某次试图取得锁时失败了,至少要等待#ms才能在一次请求锁 | |
multi_accept | events | multi_accept on | off; | off | 是否允许一次性地响应多个用户请求 | |
调试、定位问题配置 | daemon | main | daemon on | off; | on | nginx是否以守护进程运行,是否让nignx运行于后台;调试时应该为off,使得所有信息直接输出在控制台 |
master_process | main | master_process on | off; | on | 是否以master/worker模式运行nginx,默认为on,调试时可以设置为off以方便追踪 | |
error_log | main, http, mail, stream, server, location | error_log file [level]; | error_log logs/error.log error; | 配置错误日志文件的路径和日志级别。日志级别有debug, info, notice, warn, error, crit, alert和emerg几种。调试时可以使用debug级别,但要求在编译时必须使用–with-debug启用debug功能,默认通常为error级别. |
1 | 1 |
5-3、Nginx HTTP核心配置
http功能核心配置主要是http块、server块和location块的配置,包括HTTP核心模块(ngx_http_core_module)和一些扩展模块(如ngx_stream_ssl_module),提供管理WEB服务器级别的行为。
必须使用虚拟机来配置站点,每个虚拟主机使用一个server{}段来配置,非虚拟主机的配置和公共选项,需要定义在server之外,http之内。
下表包含是大部分常用的配置选项,更多配置请参考官方文档:http://nginx.org/en/docs/
配置类别 | 配置选项/模块 | 上下文 | 语法 | 默认值 | 功能描述 |
基本配置 | http | main | http { … } | 无 | 提供HTTP服务器配置上下文 |
server | http | server { … } | 无 | HTTP服务器的核心配置,定义一个虚拟主机:nginx支持使用基于主机名或IP的虚拟主机 | |
listen | server | listen address[:port] listen prot listen unix:socket | listen *:80 | *:8000 | 配置虚拟主机监听的IP地址和端口,默认监听本机IP地址和80或8000端口。如果只设置了IP没设端口,默认使用80端口。如果只设置了端口,没设置IP默认使用本机IP。 后面可以指定一些参数: default_server:定义此server为http中默认的server;如果所有的server中任何一个listen使用此参数,那么第一个server即为默认server; rcvbuf=SIZE:接收缓存大小; sndbuf=SIZE: 发送缓存大小; ssl:https server:必须以ssl连接; | |
server_name | server | server_name name …; | "" | 配置虚拟主机的域名,可以指定多个,用空格分隔。默认为空。 名称可以使用通配符和正则表达式(通常以~开头):当nginx收到一个请求时,会取出其首部的server的值,而后跟众server_name进行比较:比较方式 (1) 先做精确匹配,如www.tjiyu.com (2) 左侧通配符匹配,如tjiyu.com (3) 右侧通配符匹配,如www. (4) 正则表达式匹配 | |
server_name_hash_bucket_size | server | server_names_hash_bucket_size size; | 32|64|128 | 为了实现快速主机查找,nginx使用hash表来保存主机名。 默认值取决于处理器缓存线的大小。 | |
location | server, location | location [ = | ~ | |
无 | 允许根据用户请求的URI来匹配指定的各location以进行访问配置;匹配到时,将被location块中的配置所处理。 =:精确匹配; ~:正则表达式模式匹配,匹配时区分字符大小写; |
|
资源路径定义配置 | root | http, server, location, if in location | root path; | root html; | 设置web资源路径,用于指定请求的根文档目录,从根开始匹配。 如root /html/image/,请求"/tjiyu.gif"对应的文件为"/html/image/tjiyu.gif" |
alias | location | alias path; | 无 | 指定路径别名,只能用于location中,从最后一个/开始匹配。 如location /i/ { alias /data/w3/images/; } 请求"/i/top.gif", 实际文件"/data/w3/images/top.gif" | |
Index | http, server, location | index file …; | index index.html; | ngx_http_index_module. 定义默认页面,可以跟多个值。自左向右匹配。 | |
error_page | http, server, location, if in location | error_page code … [=[response]] uri; | 无 | ngx_http_core_module 当对于某个请求发回错误时,如果匹配上了error_page指令中设定的code,则从定向至新的URI中,错误重定向. 如 error_page 500 502 503 504 /50x.html; 也可以改变返回码。 如error_page 404 =200 /404.html; | |
try_files | server, location | try_files file … uri; try_files file … =code; | 无 | 自左向右尝试读取有path所指定路径,在第一找到即停止并返回,如果所有path均不存在,则返回最后一个uri或者code. 如try_files $uri $uri/index.html $uri.html =404; | |
网络连接相关设置 | keepalive_timeout | http, server, location | keepalive_timeout timeout [header_timeout]; | 75s | 保持连接的超时时长,默认为75s。 降低每个连接的alive时间可在一定程度上提高可响应连接数量,所以一般可适当降低此值 |
keepalive_requests | http, server, location | keepalive_requests number; | 100 | 在一次长连接上允许承载的最大请求数。 | |
keepalive_disable | http, server, location | keepalive_disable none | browser …; | msie6(ie6无法长连接) | 对指定的浏览器禁止使用长连接。 | |
tcp_nodelay | http, server, location | tcp_nodelay on | off; | on | 这里指ngx_http_core_module模块的选项。 对keepalive连接是否使用tcp_nodelay选项 启动配置,会在数据包达到一定大小后再发送数据。这样会减少网络通信次数,降低阻塞概率,但也会影响响应及时性。比较适合于文件下载这类的大数据通信场景。 | |
client_header_timeout | http, server | client_header_timeout time; | 60s | 读取http请求首部的超时时长。 如果客户端在此时间内未传输整个头,则会向客户端返回408(请求超时)错误。 | |
client_body_timeout | http, server, location | client_body_timeout time; | 60s | 读取http请求包体的超时时间。 | |
send_timeout | http, server, location | send_timeout time; | 60s | 发送响应的超时时长。 超时后连接将关闭。 | |
对客户端请求的限制配置 | limit_except | location | limit_except method … { … } | on | 指定范围之外的其他方法的访问控制。 方法有:GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK, or PATCH. 如只允许GET访问: limit_except GET { allow 192.168.1.0/32; deny all; } |
client_max_body_size | http, server, location | client_max_body_size size; | 1m | http请求包体的最大值,常用于限定客户端所能够请求的最大包体,根据请求首部中的Content-Length来检查,以避免无用的传输。 | |
limit_rate | http, server, location, if in location | limit_rate rate; | 0 | 限制客户端每秒传输的字节数,默认为0,表示没有限制。 | |
limit_rate_after | http, server, location, if in location | limit_rate_after size; | 0 | nginx向客户端发送响应报文时,如果时长超过了此处指定的时长,则后续的发送过程开始限速(下载站点常用)。 配置上面的limit_rate使用。 | |
对客户端请求的特殊处理 | ignore_invalid_headers | http, server | ignore_invalid_headers on | off; | on | 是否忽略不合法的http首部,默认为on,off意味着请求首部中出现不合规的首部将拒绝响应。 |
log_not_found | http, server, location | log_not_found on | off; | on | 用户访问的文件不存在时,是否将其记录到错误日志中。 | |
resolver | http, server, location | resolver address … [valid=time] [ipv6=on|off]; | 无 | 这里指ngx_http_core_module模块选项、 指定nginx使用的dns服务器地址。 valid = 30s,整缓存时间设置。在1.1.9版之前,不可能调整缓存时间,而nginx总是缓存答案5分钟的时间。 | |
resolver_timeout | http, server, location | resolver_timeout time; | 30s | 指定DNS解析超时时长。 | |
server_tokens | http, server, location | server_tokens on | off | string; | on | 是否在错误页面中显示和"响应头字段中发出nginx的版本号。 从版本1.9.13开始,可以使用带有变量的字符串显式设置。 空字符串禁用。 | |
文件操作的优化 | sendfile | http, server, location, if in location | sendfile on | off; | off | 是否启用sendfile内核复制模式功能。 作为静态服务器可以提高最大的IO访问速度。传统的文件读写采用read和write方式,流程为:硬盘 >> kernel buffer >> user buffer>> kernel socket buffer >>协议栈,采用sendfile文件读写的流程为:硬盘 >> kernel buffer (快速拷贝到kernelsocket buffer) >>协议栈,很明显sendfile这个系统调用减少了内核到用户模式之间的切换和数据拷贝次数,直接从内核缓存的数据拷贝到协议栈,提高了很大的效率。 |
aio | http, server, location | aio on | off | threads[=pool]; | off | 是否启用异步文件IO功能。 Linux从内核版本2.6.22开始支持,有必要启用directio,否则读取将阻塞。 directio只能用于读取在512字节边界(或XFS为4K)上对齐的块。文件结束未对齐将在阻塞模式下读取。 当在Linux上同时启用AIO和sendfile功能时,AIO用于大于或等于directio指令中指定大小的文件,而小于或禁用directio时则用sendfile。 location /video/ { sendfile on; aio on; directio 8m; } | |
open_file_cache | http, server, location | open_file_cache off; open_file_cache max=N [inactive=time]; | off | 是否打开文件缓存功能。 max:用于缓存条目的最大值,允许打开的缓存条目最大数,当满两类以后将根据LRU(最小最少连接数)算法进行置换 inactive:某缓存条目在指定时长内没有被访问过时,将自动被删除,即缓存有效期,通常默认为60s。 缓存的信息包括: 文件句柄、文件大小和上次修改时间; 已经打开的目录结构; 没有找到或没有访问权限的信息等。 建议值:max=655350(和worker_rlimit_nofile参数一致) inactive=20s; | |
open_file_cache_errors | http, server, location | open_file_cache_errors on | off; | off | 是否缓存文件找不到或没有权限访问等相关信息。 | |
open_file_cache_valid | http, server, location | open_file_cache_valid time; | 60s | 多长时间检查一次缓存中的条目是否超出非活动时长。 建议值:小于等于open_file_cache inactive | |
open_file_cache_min_use | http, server, location | open_file_cache_min_uses number; | 1 | 在open_file_cache inactive指定的时长内被访问超过此处指定的次数时,才不会被删除(删除低命中率的缓存)。 | |
Gzip压缩相关配置 | gzip | http, server, location, if in location | gzip on | off; | off | 开启内容压缩,可以有效降低客户端的访问流量和网络带宽 |
gzip_min_length | http, server, location | gzip_min_length length; | 20k | 内容超过最少长度后才开启压缩,因为太短的内容压缩效果不佳,且压缩过程还会浪费系统资源。这个压缩长度会作为http响应头Content-Length字段返回给客户端。 建议值:64 | |
gzip_comp_level | http, server, location | gzip_comp_level 1~9; | 1 | 压缩级别,默认值为1。范围为1~9级,压缩级别越高压缩率越高,但对系统性能要求越高。 建议值:4 | |
gzip_types | http, server, location | gzip_types mime-type …; | text/html | 压缩内容类型,默认为text/html;。只压缩html文本,一般我们都会压缩js、css、json之类的,可以把这些常见的文本数据都配上。如:text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; |
1 | 1 |
5-4、配置变量
Nginx配置文件支持使用变量,可以使用内置变量或自定义变量。用户自定义变量语法:set var_name value;**http核心模块的内置变量(http://nginx.org/en/docs/varindex.html),主要有如下**:
[plain] view plain copy
- $uri:当前请求的uri,不带参数
- $request_uri:请求的uri,带完整参数
- $host:http请求报文中host首部;如果请求中没有host首部,则以处理此请求的主机的主机名代替
- $hostname:nginx服务运行所在主机的主机名
- $remote_addr:客户端IP
- $remote_port: 客户端port
- $remote_user:使用用户认证时客户端用户输入的用户名
- $request_filename:用户请求中的URI经过本地root或alias转换后映射的本地的文件路径
- $request_method:请求方法
- $server_addr:服务器地址
- $server_name: 服务器名称
- $server_port:服务器端口
- $server_protocol:服务器向客户端发送响应时的协议,如http/1.1,http/1.0
- $scheme:在请求中使用的scheme 映射协议本身的协议
- $http_HEADER:匹配请求报文中指定的HEADER,$http_host匹配请求报文中的host首部
- $sent_http_HEADER:匹配响应报文中指定的HERDER,例如$http_content_type匹配相应报文中的content-type首部
- $document_root:当前请求映射到的root配置
5-5、if判断语句
if是URL地址重写ngx_http_rewrite_module模块中的选项。
在location中使用if语句可以实现条件判断,其通常有一个return语句,且一般与有着last或break标记的rewrite规则一同使用。但其也可以按需要使用在多种场景下,需要注意的是,不当的使用可能会导致不可预料的后果。if语句中的判断条件匹配用法如下:
[plain] view plain copy
- 正则表达式匹配:
- ==: 等值比较;
- ~:与指定正则表达式模式匹配时返回"真",判断匹配与否时区分字符大小写;
- ~*:与指定正则表达式模式匹配时返回"真",判断匹配与否时不区分字符大小写;
- !~:与指定正则表达式模式不匹配时返回"真",判断匹配与否时区分字符大小写;
- !~*:与指定正则表达式模式不匹配时返回"真",判断匹配与否时不区分字符大小写;
- 文件及目录匹配判断:
- -f, !-f:判断指定的路径是否为存在且为文件;
- -d, !-d:判断指定的路径是否为存在且为目录;
- -e, !-e:判断指定的路径是否存在,文件或目录均可;
- -x, !-x:判断指定路径的文件是否存在且可执行;
比如:
if ($request_method == "PUT") { #判断请求方法
}
if ($request_uri ~ ".(jpg|gif|jpeg|png)$"){#判断URL是否是以这些结尾的图片
}
6、nginx命令行参数
nginx 仅有数个命令行参数,完全通过配置文件来配置。通过"nginx –h"可以查看,如下:
常用选项:
[plain] view plain copy
- -c </path/to/config> 为 Nginx 指定一个配置文件,来代替缺省的。
- -t 不运行,而仅仅测试配置文件。nginx 将检查配置文件的语法的正确性,并尝试打开配置文件中所引用到的文件。
- -v 显示 nginx 的版本。
- -V 显示 nginx 的版本,编译器版本和配置参数。
** 注意,下面安装后我们为nginx提供了一个SysV init服务脚本,就是基于这些命令实现的。**
7、为什么选择使用nginx
前面讲了那么多,我们最后来总结下,选择nginx的理由:
7-1、高并发性能的并发模型:性能好、占用内存少、稳定
前面说过,nginx的并发模型中最好设置worker进程与CPU核心数量差不多,而一个worker进程可以处理多个请求,比apache一个进程/一个线程响应响应一个请求的并发模型,可以大大减少进程/线程数量,减少重复的数据,所以内存使用效率较高,占用内存资源少,同时减少CPU调度和上下文切换次数,所以nginx要比apache更**"轻量",且性能更好**;
一个worker进程绑定一个CPU核心,更是可以让nginx充分发挥CPU的计算能力来处理请求。
使用IO复用机制避免阻塞,可以处理更多的任务;
多个worker进程互不影响,不像多线程模型,一个线程出问题可能使整个进程内其他线程都崩溃,所以nginx稳定,健壮性好。
7-2、高扩展性
Nginx的模块化设计极具扩展性,它完全是由多个不同功能、不同层次、不同类型且耦合度极低的模块组成。因此,当对某一个模块修复Bug或进行升级时,可以专注于模块自身,无须在意其他。
这种低耦合度的优秀设计,造就了Nginx庞大的第三方模块,当然,公开的第三方模块也如官方发布的模块一样容易使用。
7-3、功能强大,应用前景广阔
Nginx提供大量的功能模块,支持诸多特性,应用场景多,且现今(2016)在WEB服务器应用中占有27.80%份额。
作为 Web 服务器:相比 Apache,Nginx 使用更少的资源,支持更多的并发连接,体现更高的效率,能够支持高达50000个并发连接数的响应。
作为负载均衡服务器:Nginx既可以在内部直接支持 Rails 和 PHP,也可以支持作为 HTTP代理服务器 对外进行服务。Nginx用C编写, 不论是系统资源开销还是 CPU 使用效率都比Perlbal要好的多。
还可作为邮件代理服务器、缓存服务器。
7-4、配置/操作简便
Nginx安装非常的简单,配置文件非常简洁(还能够支持perl语法),Bugs非常少的服务器: Nginx 启动特别容易,并且几乎可以做到7*24不间断运行,即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下进行软件版本的升级。
到这里,我们对nginx有了一个基本的认识,后面将分别进行nginx的WEB服务和代理服务相关的应用配置……
【参考资料】
1、nginx官网文档:http://nginx.org/en/docs/
2、nginx源码
3、Web服务器之Nginx详解:http://freeloda.blog.51cto.com/2033581/1285332
4、Nginx 多进程连接请求/事件分发流程分析:http://www.cnblogs.com/NerdWill/p/4992345.html
5、Nginx配置详解:http://www.cnblogs.com/knowledgesea/p/5175711.html
================
对比
对于数据流量过大的网络中,往往单一设备无法承担,需要多台设备进行数据分流,而负载均衡器就是用来将数据分流到多台设备的一个转发器。
目前有许多不同的负载均衡技术用以满足不同的应用需求,如软/硬件负载均衡、本地/全局负载均衡、更高网络层负载均衡,以及链路聚合技术。
我们使用的是软负载均衡器Nginx,而农行用的是F5硬负载均衡器,这里就简单介绍下这两种技术:
a.软件负载均衡解决方案
在一台服务器的操作系统上,安装一个附加软件来实现负载均衡,如Nginx负载均衡(我们管理系统平台使用的也是这款均衡器)。它的优点是基于特定环境、配置简单、使用灵活、成本低廉,可以满足大部分的负载均衡需求。
一、什么是Nginx
Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器,也是一个 IMAP/POP3/SMTP 代理服务器。 可以说Nginx 是目前使用最为广泛的HTTP软负载均衡器,其将源代码以类BSD许可证的形式发布(商业友好),同时因高效的性能、稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名于业界。像腾讯、淘宝、新浪等大型门户及商业网站都采用Nginx进行HTTP网站的数据分流。
二、Nginx的功能特点
1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构;
2、Nginx对网络的依赖比较小;
3、Nginx安装和配置比较简单,测试起来比较方便;
4、也可以承担高的负载压力且稳定,一般能支撑超过1万次的并发;
5、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,www.linuxidc.com 并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测;
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载;
7、Nginx能支持http和Email,这样就在适用范围上面小很多;
8、不支持Session的保持、对Big request header的支持不是很好,另外默认的只有Round-robin和IP-hash两种负载均衡算法。
三、Nginx的原理
Nginx采用的是反向代理技术,代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理,从而达到负载均衡的目的。
b.硬件负载均衡解决方案
直接在服务器和外部网络间安装负载均衡设备,这种设备我们通常称之为负载均衡器。由于专门的设备完成专门的任务,独立于操作系统,整体性能得到大量提高,加上多样化的负载均衡策略,智能化的流量管理,可达到最佳的负载均衡需求。 一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵,比如最常见的就是F5负载均衡器。
什么是F5 BIG-IP
F5负载均衡器是应用交付网络的全球领导者F5 Networks公司提供的一个负载均衡器专用设备,F5 BIG-IP LTM 的官方名称叫做本地流量管理器,可以做4-7层负载均衡,具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。
以下是F5 BIG-IP用作HTTP负载均衡器的主要功能:
①、F5 BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器,而面对用户,只是一台虚拟服务器。
②、F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障,F5会检查出来并将该服务器标识为宕机,从而不将用户的访问请求传送到该台发生故障的服务器上。这样,只要其它的服务器正常,用户的访问就不会受到影响。宕机一旦修复,F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。
③、F5 BIG-IP具有动态Session的会话保持功能。
④、F5 BIG-IP的iRules功能可以做HTTP内容过滤,根据不同的域名、URL,将访问请求传送到不同的服务器。
方案优缺点对比
基于硬件的方式(F5)
优点:能够直接通过智能交换机实现,处理能力更强,而且与系统无关,负载性能强更适用于一大堆设备、大访问量、简单应用
缺点:成本高,除设备价格高昂,而且配置冗余.很难想象后面服务器做一个集群,但最关键的负载均衡设备却是单点配置;无法有效掌握服务器及应用状态.
硬件负载均衡,一般都不管实际系统与应用的状态,而只是从网络层来判断,所以有时候系统处理能力已经不行了,但网络可能还来 得及反应(这种情况非常典型,比如应用服务器后面内存已经占用很多,但还没有彻底不行,如果网络传输量不大就未必在网络层能反映出来)
基于软件的方式(Nginx)
优点:基于系统与应用的负载均衡,能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的,性价比高,实际上如果几台服务器,用F5之类的硬件产品显得有些浪费,而用软件就要合算得多,因为服务器同时还可以跑应用做集群等。
缺点:负载能力受服务器本身性能的影响,性能越好,负载能力越大。
综述:对我们管理系统应用环境来说,由于负载均衡器本身不需要对数据进行处理,性能瓶颈更多的是在于后台服务器,通常采用软负载均衡器已非常够用且其商业友好的软件源码授权使得我们可以非常灵活的设计,无逢的和我们管理系统平台相结合。
https://blog.csdn.net/zxc456733/article/details/78861100
关于F5负载均衡你认识多少?
2018年06月09日 18:01:09 tvk872 阅读数:4353更多
个人分类: NetworkF5
F5负载均衡产品时我们常用的网络负载控制的产品之一,那么在此我们对它的功能和特点进行一个全面的介绍。通过对这个产品的认识,我们也能发现,在网络管理中我们需要注意哪些方面的问题。那么更多的内容,还是从下文中了解吧。
配置F5交换机的问题在于,与平时所学的交换机、路由器思路完全不同,拿到设备后,完全不知如何下手。
网络拓扑图如下:
两台web服务器对外提供服务,Ip地址为:192.168.192.10-20/24,外网地址192.168.27.100的80端口进行负载均衡的访问。
F5配置最简单负载均衡,需要配置的参数有Node(节点)、Pool(资源池)、和Virtual Server(虚拟服务器),它们的关系式,先配置Node,然后配置VS。Node是最基本的定义,如每个服务器就是一个Node,负载均衡Pool是一组Node接收和处理流量的一组设备,如web服务器集群。BIGIP系统将客户机流量请求发送到Pool成员中的任一服务器上(Node),然后将Pool与BIGIP系统中的Virtual server相关联,最后,BIGIP系统将进入Virtual Server中流量传输到Pool成员,Pool再传达给Node。
F5负载均衡功能1.多链路的负载均衡和冗余
与互联网络相关的关键业务都需要安排和配置多条ISP接入链路以保证网络服务的质量,消除单点故障,减少停机时间?多条ISP接入的方案并不是简单的多条不同的广域网络的路由问题,因为不同的ISP有不同自治域,所以必须考虑到两种情况下如何实现多条链路的负载均衡:内部的应用系统和网络工作站在访问互联网络的服务和网站时如何能够在多条不同的链路中动态分配和负载均衡,这也被称为OUTBOUND流量的负载均衡?互联网络的外部用户如何在外部访问内部的网站和应用系统时也能够动态的在多条链路上平衡分配,并在一条链路中断的时候能够智能地自动切换到另外一条链路到达服务器和应用系统,这也被称作为INBOUND流量的负载均衡?
F5 的BIG-IP LC可以智能的解决以上两个问题:对于OUTBOUND流量,BIG-IP LC接收到流量以后,可以智能的将OUTBOUND流量分配到不同的INTERNET接口,并做源地址的NAT,可以指定某一合法IP地址进行源地址的 NAT,也可以用BIG-IP LC的接口地址自动映射,保证数据包返回时能够正确接收?对于INBOUND流量,BIG-IP LC分别绑定两个ISP 服务商的公网地址,解析来自两个ISP服务商的DNS解析请求?BIG-IP LC不仅可以根据服务器的健康状况和响应速度回应LDNS相应的IP地址,还可以通过两条链路分别与LDNS建立连接,根据RTT时间判断链路的好坏,并且综合以上两个参数回应LDNS相应的IP地址?
F5负载均衡功能2.防火墙负载均衡
考虑到绝大多数的防火墙只能达到线速的30%吞吐能力,故要使系统达到设计要求的线速处理能力,必须添加多台防火墙,以满足系统要求?然而,防火墙必须要求数据同进同出,否则连接将被拒绝?如何解决防火墙的负载均衡问题,是关系到整个系统的稳定性的关键问题?F5的防火墙负载均衡方案,能够为用户提供异构防火墙的负载均衡与故障自动排除能力?典型的提高防火墙处理能力的方法是采用“防火墙三明治"的方法,以实现透明设备的持续性?这可满足某些要求客户为成功安全完成交易必须通过同一防火墙的应用程序的要求,也能够维护原来的网络安全隔离的要求?
F5负载均衡功能3.服务器负载均衡
对于所有的对外提供服务的服务器,均可以在BIG-IP上配置Virtual Server实现负载均衡,同时BIG-IP可持续检查服务器的健康状态,一旦发现故障服务器,则将其从负载均衡组中摘除?BIG-IP利用虚拟IP地址(VIP由IP地址和TCP/UDP应用的端口组成,它是一个地址)来为用户的一个或多个目标服务器(称为节点:目标服务器的IP地址和TCP/UDP应用的端口组成,它可以是internet的私网地址)提供服务?因此,它能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务?根据服务类型不同分别定义服务器群组,可以根据不同服务端口将流量导向到相应的服务器?BIG-IP连续地对目标服务器进行L4到L7合理性检查,当用户通过VIP请求目标服务器服务时,BIG-IP根椐目标服务器之间性能和网络健康情况,选择性能最佳的服务器响应用户的请求?如果能够充分利用所有的服务器资源,将所有流量均衡的分配到各个服务器,我们就可以有效地避免“不平衡"现象的发生?利用UIE+iRules可以将TCP/UDP数据包打开,并搜索其中的特征数据,之后根据搜索到的特征数据作相应的规则处理?因此可以根据用户访问内容的不同将流量导向到相应的服务器,例如:根据用户访问请求的URL将流量导向到相应的服务器?
F5负载均衡功能4.系统高可用性
系统高可用性主要可以从以下几个方面考虑:
4.1.设备自身的高可用性:F5 BIG-IP专门优化的体系结构和卓越的处理能力保证99.999%的正常运行时间,在双机冗余模式下工作时可以实现毫秒级切换,保证系统稳定运行,另外还有冗余电源模块可选?在采用双机备份方式时,备机切换时间最快会在200ms之内进行切换?BIG-IP 产品是业界唯一的可以达到毫秒级切换的产品, 而且设计极为合理,所有会话通过Active 的BIG-IP 的同时,会把会话信息通过同步数据线同步到Backup的BIG-IP,保证在Backup BIG-IP内也有所有的用户访问会话信息;另外每台设备中的watchdog芯片通过心跳线监控对方设备的电频,当Active BIG-IP故障时,watchdog会首先发现,并通知Backup BIG-IP接管Shared IP,VIP等,完成切换过程,因为Backup BIG-IP中有事先同步好的会话信息,所以可以保证访问的畅通无阻?
4.2.链路冗余:BIG-IP可以检测每条链路的运行状态和可用性,做到链路和ISP故障的实时检测?一旦出现故障,流量将被透明动态的引导至其它可用链路?通过监控和管理出入数据中心的双向流量,内部和外部用户均可保持网络的全时连接?
4.3.服务器冗余,多台服务器同时提供服务,当某一台服务器故障不能提供服务时,用户的访问不会中断?BIG-IP可以在OSI七层模型中的不同层面上对服务器进行健康检查,实时监测服务器健康状况,如果某台服务器出现故障,BIG-IP确定它无法提供服务后,就会将其在服务队列中清除,保证用户正常的访问应用,确保回应内容的正确性?
F5负载均衡功能5.高度的安全性
BIG-IP采用防火墙的设计原理,是缺省拒绝设备,它可以为任何站点增加额外的安全保护,防御普通网络攻击?可以通过支持命令行的SSH或支持浏览器管理的SSL方便?安全的进行远程管理,提高设备自身的安全性;能够拆除空闲连接防止拒绝服务攻击;能够执行源路由跟踪防止IP欺骗;拒绝没有ACK缓冲确认的SYN防止SYN攻击;拒绝teartop和land攻击;保护自己和服务器免受ICMP攻击;不运行SMTP?FTP?TELNET或其它易受攻击的后台程序?
BIG-IP的Dynamic Reaping特性可以高效删除各类网络DoS攻击中的空闲连接,这可以保护BIG-IP不会因流量过多而瘫痪?BIG-IP可以随着攻击量的增加而加快连接切断速率,从而提供一种具有极强适应能力?能够防御最大攻击量的解决方案?BIG-IP的Delay Binding技术可以为部署在BIG-IP后面的服务器提供全面地SYN Flood保护?此时,BIG-IP设备作为安全代理来有效保护整个网络?BIG-IP可以和其它安全设备配合,构建动态安全防御体系?BIG-IP可以根据用户单位时间内的连接数生成控制访问列表,将该列表加载到其它安全设备上,有效控制攻击流量?F5负载均衡功能6.SSL加速,在每台BIG-IP上,都具有SSL硬件加速芯片,并且自带100个TPS的License,用户可以不通过单独付费,就可以拥有100个TPS的SSL 加速功能,节约了用户的投资?在将来系统扩展时,可以简单的通过License升级的方式,获得更高的SSL加速性能?
F5负载均衡功能7.系统管理
BIG-IP提供HTTPS?SSH?Telnet?SNMP等多种管理方式,用户客户端只需操作系统自带的浏览器软件即可,不需安装其它软件?可以通过支持命令行的SSH或支持浏览器管理的SSL方便?安全的进行远程管理?直观易用的Web图形用户界面大服务降低了多归属基础设施的实施成本和日常维护费用?BIG-IP包含详尽的实时报告和历史纪录报告,可供评测站点流量?相关ISP性能和预计带宽计费周期?管理员可以通过全面地报告功能充分掌握带宽资源的利用状况?另外,通过F5 的i-Control 开发包,目前国内已有基于i-Control开发的网管软件x-control, 可以定制针对系统服务特点的监控系统,比如服务的流量情况?各种服务连接数?访问情况?节点的健康状况等等,进行可视化显示?告警方式可以提供syslog?snmp trap?mail等方式?
F5负载均衡功能8.其它
内存扩充能力:F5 BIG-IP 1000以上设备单机最大可扩充到2G内存,此时可支持400万并发回话?升级能力:F5 所有设备均可通过软件方式升级,在服务有效期内,升级软件包由F5公司提供?F5 NETWORKS已经发布其系统的最新版本BIG-IP V9.0,主要有以下特性:虚拟 IPV4 / IPV6 应用?加速Web应用高达3倍?减少66%甚至更多的基础架构成本?确保高优先级应用的性能?确保更高级别的可用性?大幅提高网络和应用安全性?强大的性能,简单的管理方式?无以匹敌的自适应能力和延展能力和突破的性能表现力?其强大的HTTP压缩功能可以将用户下载时间缩短50%,节省80%的带宽?IP地址过滤和带宽控制:BIG-IP可以根据访问控制列表对数据包进行过滤,并且针对某一关键应用进行带宽控制,确保关键应用的稳定运行?配置管理及系统报告:F5 BIG-IP提供WEB 界面配置方式和命令行方式进行配置管理,并在其中提供了丰富的系统报告,更可通过i-Control自行开发复杂的配置及报告生成
对我们管理系统应用环境来说,由于负载均衡器本身不需要对数据进行处理,性能瓶颈更多的是在于后台服务器,通常采用软负载均衡器已非常够用且其商业友好的软件源码授权使得我们可以非常灵活的设计,无逢的和我们管理系统平台相结合。
Virtual Server重要参数
F5的核心就是Virtual Server。
1、VS Type
在配置VS时,VS的Type有Performance L4、Standard VS、Forwarding IP 和 Fast Http。一般企业中常见的是前三种,考虑到尽量减少F5负载均衡引入对应用系统的影响,在可能的情况下,建议优先选用Performance L4类型的Virtual Server。在一些必须使用Standard的情况下,必然需要在F5设备上启用7层功能,包括Cookie会话保持、Session ID会话保持、Header会话保持、基于交易的长连接拆分等应用场景。另外,在应用系统需要使用F5实现Syn攻击防护时,可以采用 Standard Virtual Server。在明确后台应用基于HTTP协议时,建议在Standard的基础上关联BIGIP内置的标准HTTP Profile。对于非HTTP协议的应用,需要在VS上关联的其他Profile或者iRules根据实际的业务需求进行确定。
下面对每个VS的类型进行深入的说明:
第一种: Performance L4 模式(4层数据的转发)
Performance L4模式如图2所示,其中TMM只是负责客户端连接的分配和转发,不改变TCP连接中的任何参数,即客户端连接与服务器拦截是1:1的关系。一般企业中常是这种模式,因为转发速率快。但在一些7层数据包的情况下,如HTTP,建议使用Standard VS模式。
第二种 Standard VS模式
在这种模式下,客户端与服务器端的TCP连接完全独立,同时F5默认情况下以客户端源IP和后台建立连接,在打开SNAT的情况下用SNAT地址和后台建立连接。Standard VS的端口永远对外开放,无论后台是否有服务器在工作。也就是说,如果VS开放的端口是80,在Node A和Node B都down的情况下,虚IP的80端口还是可以telnet通的,只不过网页访问不了了。
第三种: Forwarding IP
一般用于内外网连接,没有Pool Member,转发完全取决于本地路由。默认情况下,F5没有路由功能,需要建立一个全0的VS去开启F5的路由功能,其中,如果想控制只有内网可以访问外网,而外网不能访问内网,可以通过调整“VLAN and Tunnel Traffic”参数来实现。
2. VS Profile
VS Profile 是依赖于VS的存在,是对于VS的流量进行格式化处理。如果VS上配置了TCP Profile,那么对于UDP的连接,F5是不会接受的。
tcp参数中Idel Timeout值(多长时间连接里面没有数据流量时就删除连接表)必须要与服务器相配合,否则会出现错误。如果F5上此值为150s,而IIs服务器为300s,就会产生大量错误。
3、 VS里面的Address Translation 和 Port Translation ,默认情况下都是 enabled。
Address Translation的含义是如果外面访问的主机和VS IP不一样,就需要开启此参数,比如VS IP地址是192.168.27.100,真实机器为192.168.27.10,那么需要开启Address Translation,而企业应用中,这参数一般是开启的,除非特殊的上面介绍的Fowarding IP模式不需要开启。
Port Translation 参数的意思是VS地址是192.168.27.100的8080端口对应真实地址的80端口,那么需要开启Port Translation
4、SNAT Pool ???
内网需要访问公网进行NAT转换。当配置SNAT AutoMap的时候,表示请求从哪个VLAN发出去,则SNAT的源地址为VLAN上的SelfIp,比如外网用户(192.168.27.1)访问内网服务器(192.168.192.10),在开启SNAT AutoMap的情况下,访问的源IP将转变为F5的内网SelfIP(192.168.192.2)去访问。当一个vlan上有多个SelfIP存在的时候,SNAT的源地址是在多个SelfIP之间轮询。
5、会话保持
在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中,一个客户与服务器经常经过多次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的,服务器在进行这些交互过程的某一个交互步骤时,往往需要了解上一次交互过程的处理结果,服务器进行下一步操作时需要,就要求所有这些相关的交互过程都由一台服务器完成,而不能被负载均衡器分散到不同的服务器上。
经验总结:
1、拿到F5首先就是要激活,通过向导可以很简单的进行激活,但是记住一定要能上网,最好在上架前完成激活工作。
2、打开浏览器使用https://192.168.1.245 设备管理ip可以登录到F5设备。默认用户名和密码均为admin。
3、创建相应的VLAN,并将接口加入相应的VLAN,Network -> VLANS 。
Name : 设置这个VLAN的名字;
Tag: 保留为空;
Interface:定义Avalilable 中显示的端口有选择性的划分到这个vlan中,指定端口后,单击<< 选人 Untagged 栏即可。
点击 Finished 完成。
4、在划分完VLAN后,即可对每个VLAN进行IP地址的定义,方法如下:点击左侧导航条中的 Networks -> Self IPS。
5、配置路由,点击左侧导航条中的 Networks -> Routes .
Type :定义配置的是默认网关还是静态路由。
Destination: 定义目标网段。
Netmask : 定义目标网段的掩码;
Resource : 定义网关地址。
点击 Finished 完成。
6、Pool 配置:点击左侧导航条中的Local Traffic -> Virtual Servers -> Pools;
Name 定义创建的Pool的名字。
Health Monitors 定义该Pool使用的健康检查机制,此处为TCP。
Load Balacing Method定义该Pool使用哪种负载均衡算法 –我们选用 observed-member(观察法)。
New Members 定义该pool下真实的服务器的IP和Port。
点击 Finished 完成。
7、Virtual Server 配置,Local Traffic -> Virtual Servers,这里面的参数可以参见之前介绍的进行填写,并将管理相应的Pool。并配置相应的F5轮询方式,常用的是轮询(RoundRobin)。
8、配置Monitor 的作用是检查服务器的健康状态,然后关联的相应的Pool,Local Traffic -> Monitors。
9、配置Redundant,这在前面已介绍。
近几年来,四到七层网络负载均衡首先在电信、移动、银行、大型网站等单位进行了应用,因为其网络流量瓶颈的现象最突出。目前在多家企业,随着企业关键网络应用业务的发展,负载均衡的应用需求也越来越大了。
https://blog.csdn.net/tvk872/article/details/80634898