NGINX基于Tomcat配置负载均衡
本部署指南说明了如何使用NGINX开源和NGINX Plus在Apache TomcatTM应用程序服务器池之间平衡HTTP和HTTPS流量。本指南中的详细说明适用于Tomcat的基于云的部署和本地部署。
关于NGINX和NGINX Plus关于Apache Tomcat先决条件和系统要求为客户端流量配置SSL / TLS证书创建和修改配置文件使用NGINX或NGINX Plus配置基本负载平衡 为HTTP和HTTPS流量配置虚拟服务器配置基本负载平衡配置基本会话持久性配置WebSocket流量的代理配置内容缓存配置HTTP / 2支持基本负载平衡的完整配置使用NGINX Plus配置增强的负载平衡 配置高级会话持久性配置应用程序运行状况检查启用实时活动监控启用上游组的动态重新配置完整配置以增强负载平衡资源资源
关于NGINX开源和NGINX Plus
NGINX开源是一种开源Web服务器和反向代理,由于其可伸缩性,出色的性能和较小的占用空间,近年来已越来越受欢迎。NGINX开源最初创建是为了解决C10K问题(在一台Web服务器上同时服务10,000个连接)。NGINX开放源代码的功能和性能使其成为高性能网站的重要组成部分-它是全球100,000个最繁忙的网站中排名第一的Web服务器。
NGINX Plus是NGINX开放源代码的商业支持版本。NGINX Plus是一个完整的应用程序交付平台,它通过一系列企业就绪功能扩展了NGINX Open Source的功能,这些功能可增强Tomcat部署并有助于大规模构建Web应用程序:
功能齐全的HTTP,TCP和UDP负载平衡智能会话持久性高性能反向代理缓存和卸载动态和静态内容自适应流传输,可将音频和视频传输到任何设备应用感知健康检查和高可用性可通过仪表板或API进行高级活动监控使用DevOps友好的工具进行管理和实时配置更改
关于Apache Tomcat
Apache Tomcat是Java Servlet,JavaServer Pages,Java Expression Language和Java WebSocket技术的开源软件实现。
我们针对Apache Tomcat 8.0测试了本指南中的过程。
先决条件和系统要求
在物理或虚拟系统上安装和配置的Tomcat应用程序服务器。托管NGINX开源或NGINX Plus的Linux系统。为避免与其他应用程序发生潜在冲突,建议您将软件安装在新的物理或虚拟系统上。有关NGINX Plus支持的操作系统列表,请参见NGINX Plus技术规范。NGINX Open Source 1.9.5和更高版本,以及NGINX Plus R7和更高版本。这些说明假定您具有基本的Linux系统管理技能,包括以下内容。没有为这些任务提供完整的说明。
配置和部署Tomcat应用程序从供应商提供的软件包安装Linux软件编辑配置文件在中央管理系统和Linux服务器之间复制文件运行基本命令以启动和停止服务读取日志文件
关于样本值和文本复制
用作示例域名(在键名和配置块中)。将其替换为您的组织名称。本指南中的许多NGINX开源和NGINX Plus配置块列出了两个IP地址为10.100.100.11和10.100.100.12的示例Tomcat应用程序服务器。将这些地址替换为Tomcat服务器的IP地址。如果您有两个以上,则在每个服务器的配置块中包含一行。出于可读性原因,某些命令显示在多行上。如果要将它们复制并粘贴到终端窗口中,建议您首先将它们复制到文本编辑器中,在其中可以替换适合于部署的对象名称,并删除浏览器可能插入的任何多余的格式字符。本指南中的某些示例是局部的,需要其他指令或参数才能完整。您可以按照创建和修改配置文件中的说明,从NGINX网站下载完整的配置文件,以实现基本和增强的负载平衡。有关特定指令或参数的详细信息,请参见NGINX参考文档。我们建议您不要将本指南中的配置片段中的文本复制到配置文件中。有关创建配置文件的推荐方法,请参阅《创建和修改配置文件》。为客户端流量配置SSL / TLS证书
如果计划启用NGINX Open Source或NGINX Plus与Tomcat应用程序的客户端之间的通信的SSL / TLS加密,则需要为NGINX Open Source或NGINX Plus配置服务器证书。
默认情况下,NGINX提供的所有NGINX Plus软件包和NGINX Open Source二进制文件均启用SSL / TLS支持。如果要从源代码编译NGINX开源程序,请包含--with-http_ssl_module
参数以启用对HTTP流量的SSL / TLS支持(TCP的对应参数为--with-stream_ssl_module
,电子邮件的对应参数为--with-mail_ssl_module
,但本指南不涵盖这两种协议类型)。如果使用来自其他提供程序的二进制文件,请查阅提供程序文档以确定它们是否支持SSL / TLS。
有几种获取服务器证书的方法,包括以下几种。为了您的方便,第二和第三选项提供了分步说明。
如果您已经在另一个UNIX或Linux系统(包括运行Apache HTTP Server的系统)上安装了NGINX Open Source或NGINX Plus的SSL / TLS证书,请将其复制到NGINX Open Source或NGINX的/ etc / nginx / ssl目录中加服务器。如下面的生成自签名证书中所述,生成自签名证书。这足以测试场景,但是生产部署的客户端通常需要由证书颁发机构(CA)签名的证书。向CA或您组织的安全组请求新证书,如下面的生成证书请求中所述。
有关SSL / TLS终止的更多详细信息,请参见《NGINX Plus管理指南》。
生成自签名证书
生成公私钥对和基于它们的PEM格式的自签名服务器证书。
以root用户身份登录到已openssl
安装软件的计算机上。
生成PEM格式的密钥对(默认)。要加密私钥,请包含-des3
参数。(其他可用的加密算法可用,在genrsa
命令的手册页上列出。)提示您输入用作加密基础的口令。
root#openssl genrsa -des3 -out〜/ private-key.pem 2048生成RSA私钥...输入private-key.pem的密码:
在安全位置创建密钥文件的备份。如果丢失密钥,则证书将无法使用。
根目录cp〜/ private-key.pem <SECURE-DIR> /private-key.pem.backup
生成证书。包括-new
和-x509
参数以创建新的自签名证书。(可选)包括-days
参数,以将密钥的有效期从默认的30天(10950天约为30年)更改为默认值。使用适合您的测试部署的值来响应提示。
root#openssl req -new -x509 -key〜/ private-key.pem -out〜/ self-cert.pem -days 10950
将证书文件和关联的密钥文件复制或移动到NGINX Open Source或NGINX Plus服务器上的/ etc / nginx / ssl目录。
生成证书申请
以root用户身份登录到已openssl
安装软件的计算机上。
创建要打包在证书中的私钥。
root#openssl genrsa -out〜/ .key 2048
在安全位置创建密钥文件的备份。如果丢失密钥,则证书将无法使用。
root#cp〜/ .key <安全目录> /.key.backup
创建一个证书签名请求(CSR)文件。
root#openssl req -new -sha256 -key〜/ .key -out〜/ .csr
向CA或您的内部安全组请求证书,并提供CSR文件(.csr)。提醒一下,切勿直接与第三方共享私钥(.key文件)。
证书必须是PEM格式,而不是Windows兼容的PFX格式。如果您是自己从CA网站请求证书的,请在系统提示您选择要为其生成证书的服务器平台时,选择NGINX或Apache(如果可用)。
将证书文件和关联的密钥文件复制或移动到NGINX Plus服务器上的/ etc / nginx / ssl目录。
创建和修改配置文件
为了减少错误,本指南让您将NGINX提供的文件中的指令复制到配置文件中,而不是使用文本编辑器自己键入指令。然后,您将遍历本指南中的各节(从配置虚拟服务器以进行HTTP和HTTPS流量入手)以了解如何根据部署要求修改指令。
如所提供的,有一个文件用于基本负载平衡(使用NGINX Open Source或NGINX Plus)和一个文件用于增强负载平衡(使用NGINX Plus)。如果要在新的Linux系统上安装和配置NGINX开源或NGINX Plus,并且仅使用它来负载平衡Tomcat流量,则可以将提供的文件用作主配置文件,按照惯例,该文件称为/ etc / nginx / nginx .conf。
但是,我们建议您使用一个在安装NGINX Plus软件包时自动设置的方案,而不是单个配置文件,尤其是如果您已经具有现有的NGINX Open Source或NGINX Plus部署或计划扩大对以下文件的使用时NGINX开源或NGINX Plus将来会用于其他目的。在传统方案中,主配置文件仍称为/etc/nginx/nginx.conf,但是您没有在其中包含所有指令,而是为不同的HTTP相关功能创建了单独的配置文件,并将文件存储在/ etc /中。 nginx / conf.d目录。然后,您可以include
在http
主文件的上下文,以读取功能特定文件的内容。
要下载完整的配置文件以进行基本的负载平衡:
根目录cd /etc/nginx/conf.droot#curl /resource/conf/tomcat-basic.conf> tomcat-basic.conf
要下载完整的配置文件以增强负载平衡:
根目录cd /etc/nginx/conf.droot#curl /resource/conf/tomcat-enhanced.conf> tomcat-enhanced.conf
(您也可以在浏览器中访问URL并以这种方式下载文件。)
要设置常规配置方案,请http
在主nginx.conf文件中添加一个配置块(如果尚不存在)。(标准放置在所有全局指令下方。)将此include
指令添加适当的文件名:
http{includeconf.d / tomcat-(basic | enhanced).conf ; }
您还可以使用通配符表示法在适当的上下文块中引用与某种功能或流量类型有关的所有文件。例如,如果您将所有HTTP配置文件的功能都命名为-http.conf,那么这是一个适当的include
指令:
http{包括conf.d / *-http.conf ; }
出于参考目的,完整的配置文件的文本包含在本文档中:
基本负载平衡的完整配置完整配置以增强负载平衡
但是,我们建议您不要直接从此文档中复制文本。它不一定使用与文本编辑器相同的机制来定位文本(例如,换行符和空白)。在复制到编辑器中的文本中,行可能会同时运行,并且配置块中的子语句缩进可能会丢失或不一致。对于NGINX开源或NGINX Plus而言,没有格式设置不会出现问题,因为(像许多编译器一样)它们在解析期间会忽略空格,仅依靠分号和花括号作为定界符。但是,缺少空格的确使人更难以解释和修改配置而不会犯错误。
关于重新加载更新的配置
我们建议您每次完成对配置的一组更新时,都运行命令以测试配置文件的语法有效性。nginx-t
根号nginx -tnginx:配置文件/etc/nginx/nginx.conf语法正常nginx:配置文件/etc/nginx/nginx.conf测试成功
要告诉NGINX Open Source或NGINX Plus开始使用新配置,请运行以下命令之一:
root#nginx -s重新加载
要么
root#服务nginx重新加载
使用NGINX开源或NGINX Plus配置基本负载平衡
本节说明如何在两个Tomcat服务器之前将NGINX开源或NGINX Plus设置为负载平衡器。前两节中的说明是强制性的:
为HTTP和HTTPS流量配置虚拟服务器配置基本负载平衡
其余部分中的说明是可选的,具体取决于应用程序的要求:
配置基本会话持久性配置WebSocket流量的代理配置内容缓存配置HTTP / 2支持
完整的配置文件显示在“基本负载平衡的完整配置”中。
如果您使用的是NGINX Plus,则可以在完成基本负载平衡的配置后配置其他增强功能。请参阅使用NGINX Plus配置增强的负载平衡。
为HTTP和HTTPS流量配置虚拟服务器
这些指令server
在顶级http
配置块中的单独块中定义用于HTTP和HTTPS通信的虚拟服务器。所有HTTP请求都重定向到HTTPS服务器。
配置一个server
块,侦听在端口443上收到的请求。
的ssl_certificate
和ssl_certificate_key
指令是必需的;替换在为客户端流量配置SSL / TLS证书中选择的证书和私钥的名称。
其他指令是可选的,但建议使用。
#在'http'块服务器中{监听443 ssl ;server_name;ssl_certificate/etc/nginx/ssl/.crt ;ssl_certificate_key/etc/nginx/ssl/.key ;ssl_session_cacheshared:SSL:1m ;ssl_prefer_server_ciphers上; }
指令文件:listen
,server
,server_name
,ssl_certificate
和ssl_certificate_key
,ssl_prefer_server_ciphers
,ssl_session_cache
配置一个server
块,该块将在端口80上收到的对的请求永久重定向到上一步中定义的HTTPS服务器。
如果您不使用SSL / TLS进行客户端连接,请忽略该return
指令。当在本指南的其余部分中指示server
为HTTPS通信量的块添加指令时,请将其添加到该块中。
#在'http'块服务器中{监听80 ;server_name;#将所有HTTP请求重定向到HTTPS位置/ {返回301 https:// $ server_name $ request_uri ; } }
指令文件:location
,return
有关配置SSL / TLS的更多信息,请参阅NGINX Plus管理指南和HTTPSSL / TLS模块的参考文档。
配置基本负载平衡
To configure load balancing, you first create a namedupstream group, which lists the backend servers among which client requests are distributed. You then set upNGINX Open Sourceor NGINXPlus as a reverse proxy and load balancer by referring to the upstream group in one or moreproxy_pass
directives.
Configure an upstream group calledtomcatwith two Tomcat application servers listening on port 8080, one on IP address 10.100.100.11 and the other on 10.100.100.12.
# In the 'http' blockupstreamtomcat {server10.100.100.11:8080;server10.100.100.12:8080;}
Directive documentation:server
,upstream
In theserver
block for HTTPS traffic that we created inConfiguring Virtual Servers for HTTP and HTTPS Traffic, include twolocation
blocks:
The first one matches HTTPS requests in which the path starts with/tomcat-app/, and proxies them to thetomcatupstream group we created in the previous step.The second one funnels all traffic to the firstlocation
block, by doing a temporary redirect of all requests for/.
# In the 'server' block for HTTPS trafficlocation/tomcat-app/ {proxy_passhttp://tomcat;}location= / {return302 /tomcat-app/;}
Directive documentation:location
,proxy_pass
,return
Note that these blocks handle only standard HTTPS traffic. If you want to load balance WebSocket traffic, you need to add anotherlocation
block as described inConfiguring Proxy of WebSocket Traffic.
默认情况下,NGINX Open Source和NGINX Plus使用Round Robin算法在服务器之间进行负载平衡。负载平衡器按顺序遍历上游组中的服务器列表,将每个新请求转发到下一台服务器。在我们的示例中,第一个请求转到10.100.100.11,第二个请求转到10.100.100.12,第三个请求到10.100.100.11,依此类推。有关其他可用负载平衡算法的信息,请参见《NGINX Plus管理指南》。
在NGINX Plus中,当后端服务器组发生更改时,您还可以使用DNS或API来对上游组进行动态重新配置。请参阅启用上游组的动态重新配置。
有关代理和负载平衡的更多信息,请参阅《 NGINX Plus管理指南》中的NGINX反向代理和HTTP负载平衡,以及HTTP代理和上游模块的参考文档。
配置基本会话持久性
如果您的应用程序需要基本的会话持久性(也称为粘性会话),则可以使用IP哈希负载平衡算法在NGINX开源中实现它。(如配置高级会话持久性中所述,NGINX Plus提供了一种更为复杂的会话持久性形式。)
使用IP哈希算法,对于每个请求,将基于客户端的IP地址计算哈希,并将其与上游服务器之一相关联。具有该哈希值的所有请求都将发送到该服务器,从而建立会话持久性。
如果客户端具有IPv6地址,则哈希基于整个地址。如果它具有IPv4地址,则哈希仅基于地址的前三个八位位组。旨在针对从子网(/ 24)范围动态分配IP地址的ISP客户端进行优化。但是,在以下情况下无效:
到您站点的大部分流量来自一个转发代理或来自同一/ 24网络上的客户端,因为在这种情况下,IP哈希将所有客户端映射到同一服务器。客户端的IP地址可以在会话期间更改,例如,当移动客户端从WiFi网络切换到蜂窝网络时。
要在NGINX中配置会话持久性,请将ip_hash
指令添加到upstream
在配置基本负载平衡中创建的块中:
#在tomcat {ip_hash;上游的'http'块中服务器10.100.100.11 :8080 ;服务器10.100.100.12 :8080 ; }
指令文档:ip_hash
您还可以使用哈希负载平衡方法来保持会话持久性,其中哈希基于指定的文本和NGINX变量的任意组合。例如,您可以使用以下配置在完整(四字节)的客户端IP地址上进行哈希处理。
#在tomcat上游的'http'块中{hash$ remote_addr ;服务器10.100.100.11 :8080 ;服务器10.100.100.12 :8080 ; }
指令文档:hash
配置WebSocket流量的代理
WebSocket协议(在RFC 6455中定义)允许在客户端和服务器之间的单个TCP连接上同时进行双向通信,双方可以独立发送数据。为了启动WebSocket连接,客户端向服务器发送一个握手请求,将请求从标准HTTP升级到WebSocket。如果握手请求通过验证,并且服务器接受请求,则建立连接。创建WebSocket连接后,浏览器客户端可以将数据发送到服务器,同时从该服务器接收数据。
Tomcat 8默认情况下不启用WebSocket,但是Tomcat文档中提供了启用WebSocket的说明。如果要使用NGINX开源或NGINX Plus将WebSocket通信代理到Tomcat应用程序服务器,请添加本节中讨论的指令。
默认情况下,NGINX Open Source和NGINX Plus使用HTTP / 1.0进行上游连接。为了正确地代理,WebSocket连接需要HTTP / 1.1以及一些其他设置HTTP标头的配置指令:
#在“ http”块图中$ http_upgrade $ connection_upgrade {默认升级;“”关闭; }#在HTTPS流量位置的“服务器”块中/ wstunnel / {proxy_passhttp:// tomcat ;proxy_http_version1 .1 ;proxy_set_header升级 $ http_upgrade ;proxy_set_header连接 $ connection_upgrade ; }
指令文件:location
,map
,proxy_http_version
,proxy_pass
,proxy_set_header
proxy_set_header
需要第一个指令,因为Upgrade
请求标头是逐跳的;也就是说,HTTP规范明确禁止代理转发它。该指令将覆盖禁止。
第二个proxy_set_header
指令将Connection
标头设置为取决于map
块中测试的值:如果请求具有Upgrade
标头,则Connection
标头设置为upgrade
;否则,将其设置为close
。
有关代理WebSocket通信的更多信息,请参见WebSocket代理和NGINX作为WebSocket代理。
配置内容缓存
从Tomcat应用程序服务器缓存响应既可以改善对客户端的响应时间,又可以减少服务器上的负载,因为合格的响应会立即从缓存中提供,而不是在服务器上再次生成。有许多有用的指令可用于微调缓存行为。有关详细讨论,请参见《 NGINX和NGINX Plus缓存指南》。
要在NGINX Open Source或NGINX Plus中启用基本缓存,请添加以下配置:
包括该proxy_cache_path
指令以创建本地磁盘目录/ tmp / NGINX_cache /用作缓存。该keys_zone
参数为称为backcache的区域分配10 MB的共享内存,该区域用于存储缓存密钥和元数据(例如使用计时器)。1 MB的区域可以存储大约8,000个密钥的数据。
#在'http'块中proxy_cache_path/ tmp / NGINX_cache / keys_zone = backcache:10m ;
指令文档:proxy_cache_path
在location
与HTTPS请求匹配的块中(路径以/ tomcat-app /开头)中,包含proxy_cache
用于引用上一步中创建的缓存的指令。
#在HTTPS流量位置的“服务器”块中/ tomcat-app / {proxy_passhttp:// tomcat ;proxy_cachebackcache ; }
指令文件:location
,proxy_cache
,proxy_pass
默认情况下,缓存键类似于NGINX变量的字符串:$scheme$proxy_host$request_uri
。要更改变量列表,请使用proxy_cache_key
指令指定它们。该指令的一种有效用法是根据JSESSIONID
Cookie为每个用户创建一个缓存密钥。当缓存是私有的(例如包含购物车数据或其他特定于用户的资源)时,此功能很有用。JSESSIONID
使用以下伪指令在缓存键中包含cookie:
proxy_cache_key$ proxy_host $ request_uri $ cookie_jessionid ;
指令文档:proxy_cache_key
有关缓存的更多信息,请参见NGINX Plus管理指南和HTTP代理模块的参考文档。
配置HTTP / 2支持
Nginx开源1.9.5和更高版本以及NGINX Plus R7和更高版本完全支持HTTP / 2。与往常一样,我们建议您运行最新版本的软件以利用改进和错误修复。
如果使用NGINX Open Source,请注意,在1.9.5版和更高版本中,SPDY模块已从代码库中完全删除,并被HTTP / 2模块取代。升级到1.9.5或更高版本后,您将无法再将NGINX开源配置为使用SPDY。如果要继续使用SPDY,则需要从NGINX 1.8.x分支中的源代码编译NGINX Open Source。
在NGINX Plus R8和更高版本中,NGINX Plus默认支持HTTP / 2。(从该版本开始,不再支持SPDY)。特别:
在NGINX Plus R11和更高版本中,nginx-plus软件包默认情况下继续支持HTTP / 2,但动态模块已弃用了先前发行版中的nginx-plus-extras软件包。
对于NGINX Plus R8到R10,nginx-plus和nginx-plus-extras软件包默认支持HTTP / 2。
如果使用NGINX Plus R7,则必须安装nginx-plus-http2软件包而不是nginx-plus或nginx-plus-extras软件包。
要启用HTTP / 2支持,请将http2
参数添加到我们在“为HTTP和HTTPS通信配置虚拟服务器”中创建的HTTPS通信块中的listen
伪指令中,如下所示:server
#在HTTPS流量的“服务器”块中,监听443 ssl http2 ;
指令文档:listen
要验证HTTP / 2转换是否正常,您可以使用适用于Google Chrome和Firefox的“ HTTP / 2和SPDY指示器”插件。
基本负载平衡的完整配置
The full configuration for basic load balancing appears here for your convenience. It goes in thehttp
context. The complete file is available fordownloadfrom the NGINX website.
We recommend that you do not copy text directly from this document, but instead use the method described inCreating and Modifying Configuration Filesto include these directives in your configuration– add aninclude
directive to thehttp
context of the mainnginx.conffile to read in the contents of/etc/nginx/conf.d/tomcat-basic.conf.
proxy_cache_path/tmp/NGINX_cache/ keys_zone=backcache:10m;map$http_upgrade $connection_upgrade {defaultupgrade;''close; }upstreamtomcat {# Use IP Hash for session persistenceip_hash;# List of Tomcat application serversserver10.100.100.11:8080;server10.100.100.12:8080; }服务器{听80 ;server_name;#将所有HTTP请求重定向到HTTPS位置/ {返回301 https:// $ server_name $ request_uri ; } }服务器{监听443 SSL http2 ;server_name;ssl_certificate/etc/nginx/ssl/.crt ;ssl_certificate_key/etc/nginx/ssl/.key ;ssl_session_cacheshared:SSL:1m ;ssl_prefer_server_ciphers上;#跨Tomcat应用程序对'/ tomcat-app /'的负载平衡请求#服务器位置/ tomcat-app / {proxy_passhttp:// tomcat ;proxy_cachebackcache ; }#当用户请求'/'location= / {返回302 / tomcat-app / ; 时,返回到/ tomcat-app /的临时重定向 。}#WebSocket配置位置/ wstunnel / {proxy_passhttps:// tomcat ;proxy_http_version1 .1 ;proxy_set_header升级 $ http_upgrade ;proxy_set_header连接 $ connection_upgrade ; } }
使用NGINX Plus配置增强的负载平衡
本节说明如何使用NGINX Plus中的某些扩展功能配置增强的负载平衡。
注意:在设置本节中描述的增强功能之前,必须完成以下两个部分中有关基本负载平衡的说明:
为HTTP和HTTPS流量配置虚拟服务器配置基本负载平衡。
除非另有说明,否则所有可选的基本功能(如在NGINX Open Source和NGINX Plus中配置基本负载平衡的其他小节中所述)都可以与此处描述的增强功能结合使用。
以下各节中描述的功能都是可选的。
配置高级会话持久性配置应用程序运行状况检查启用实时活动监控启用上游组的动态重新配置
完整的配置文件显示在“增强负载平衡的完整配置”中。
配置高级会话持久性
与NGINX Open Source相比,NGINX Plus提供了更复杂的会话持久性方法,该方法在sticky
指令的三个变体中实现。在以下示例中,我们将该指令添加到在“配置基本负载平衡”中创建的上游组中,以基于Tomcat应用程序设置的属性建立会话持久性。stickyroute
jvmRoute
配置基于粘性路由的会话持久性
在NGINX Plus配置中,删除或注释掉该ip_hash
指令,仅保留server
指令:
#在tomcat {#ip_hash;上游的'http'块中服务器10.100.100.11 :8080 ;服务器10.100.100.12 :8080 ; }
指令文件:server
,upstream
将以下行添加到后端Tomcat服务器的配置文件中,以将基于jvmRoute
属性的标识符(在此设置为a
或b
)附加到JSESSIONID
cookie值的末尾:
#在主机10.100.100.11上<Engine name =“ Catalina” defaultHoast =“ ” jvmRoute =“ a”>#在主机10.100.100.12上<Engine name =“ Catalina” defaultHoast =“ ” jvmRoute =“ b”>
通过检查JSESSIONID
每个请求中的cookie和URL并提取jvmRoute
值,将NGINX Plus配置为选择上游服务器。
#在'http'块图中$ cookie_jsessionid $ route_cookie {〜。+ \。(?Pw +)$$ route ; }映射$ request_uri $ route_uri { 〜jsessionid=。+ \。(?Pw +)$$ route_uri ; }上游的Tomcat {服务器10.100.100.11 :8080 路由=一个;服务器10.100.100.12 :8080 路由= B ;粘性路线 $ route_cookie $ route_uri ; }
指令文件:map
,server
,,stickyroute
upstream
第一个map
指令提取JSESSIONID
cookie的最后一个元素(在句点之后),并将其记录在$route_cookie
变量中。
第二个map
指令从jsessionid=
请求URL的结尾元素中提取最后一个元素(在句点之后),并将其记录在$route_uri
变量中。
该指令告诉nginx加上使用它找到的参数列表,在这里是两个变量被设置的第一个非空变量的值指示。换句话说,它使用cookie的final元素(如果存在),否则使用URL元素的final元素。stickyroute
map
JESSIONID
jessionid=
的route
所述参数server
指示意味着请求如果该值发送到10.100.100.11a
如果该值和10.100.100.12b
。
配置基于学习的粘性会话持久性
该指令是会话持久性的另一种选择。在这种情况下,会话标识符是由Tomcat应用程序创建的cookie。stickylearn
JSESSIONID
如上面的步骤1所示,删除或注释掉ip_hash
该upstream
块中的指令。
在块中包含指令:stickylearn
upstream
#在'HTTP'块上游的Tomcat {服务器10.100.100.11 :8080 ;服务器10.100.100.12 :8080 ;粘性学习 create = $ upstream_cookie_JSESSIONID lookup = $ cookie_JSESSIONID zone = client_sessions:1m ; }
指令文件:map
,server
,,stickylearn
upstream
在create
和lookup
参数指定如何进行新会话,创建和现有会话分别搜索。对于新会话,NGINX Plus将会话标识符设置为$upstream_cookie_JSESSIONID
变量的值,该变量捕获JSESSIONID
由Tomcat应用程序服务器发送的cookie。检查现有会话时,它将JSESSIONID
客户端发送的cookie($cookie_JSESSIONID
变量)用作会话标识符。
可以多次指定两个参数(每次都使用不同的变量),在这种情况下,NGINX Plus会为每个参数使用第一个非空变量。
该zone
参数创建一个共享内存区域,用于存储有关会话的信息。分配的内存量(此处为1 MB)决定了一次可以存储多少个会话(该数量因平台而异)。在client_sessions
每个sticky
指令中,分配给区域的名称(在这里)必须是唯一的。
有关会话持久性的更多信息,请参见《NGINX Plus管理指南》。
配置应用程序运行状况检查
健康检查是按固定间隔发送到服务器的带外HTTP请求。它们用于确定服务器是否响应正常且功能正常,而无需客户端的实际请求。
由于health_check
伪指令放置在location
块中,因此我们可以为每个应用程序启用不同的运行状况检查。
在location
与HTTPS请求匹配的块中,其路径以/ tomcat-app /开头(在配置基本负载平衡中创建),添加health_check
指令。
在这里,我们将NGINX Plus配置为每2秒向tomcat上游组中的每台服务器发送对顶级URI/(斜杠)的带外请求,这比默认的5秒间隔更具攻击性。如果服务器没有正确响应,它将被标记为Down并且NGINX Plus将停止向其发送请求,直到它连续通过五次后续运行状况检查为止。我们包括用于定义一组非默认的运行状况检查测试的参数。match
#在HTTPS流量位置的“服务器”块中/ tomcat-app / {proxy_passhttp:// tomcat ;proxy_cachebackcache ;health_checkinterval = 2s 失败= 1 pass = 5 uri = / match = tomcat_check ; }
指令文件:health_check
,location
,proxy_cache
,proxy_pass
在http
上下文中,请包含一个match
指令,以定义服务器必须通过的测试才能被视为正常运行。在此示例中,它必须返回状态码200
,Content-Type
响应标头必须为text/html
,并且响应正文必须与指示的正则表达式匹配。
#在'http'块中匹配health_check {status200 ;标头Content-Type = text / html ;正文〜 “ Apache Tomcat / 8” ; }
指令文档:match
在tomcat上游组中,包括zone
用于定义共享内存区域的指令,该区域用于存储组的配置和运行时状态,并在工作进程之间共享。
#在tomcat上游的'http'块中{zonetomcat 64k ;服务器10.100.100.11 :8080 ;服务器10.100.100.12 :8080 ;#...}
指令文件:server
,upstream
,zone
NGINX Plus还具有启动缓慢的功能,该功能对于健康检查非常有用。当故障服务器恢复正常或将新服务器添加到上游组时,NGINX Plus会在定义的时间内缓慢增加流量。这使服务器有时间进行“热身”,而不会被启动时无法处理的更多连接所淹没。有关更多信息,请参见《NGINX Plus管理指南》。
例如,要为Tomcat应用程序服务器设置30秒的缓慢启动时间,请将slow_start
参数包含在它们的server
指令中:
#在'上游'块#...服务器10.100.100.11 :8080 slow_start = 30秒;服务器10.100.100.12 :8080 slow_start = 30秒;
有关自定义健康检查的信息,请参见《NGINX Plus管理指南》。
启用实时活动监控
NGINX Plus包含一个实时活动监视界面,可实时提供关键的负载和性能指标,包括NGINX Plus R6及更高版本中的TCP指标。通过RESTful JSON接口报告统计信息,从而非常容易将数据提供给自定义或第三方监视工具。还有一个内置仪表板。请按照以下说明进行部署。
有关实时活动监控的更多信息,请参见《NGINX Plus管理指南》。
配置模块和内置仪表板的最快方法是从NGINX网站下载示例配置文件,并根据需要进行修改。有关更完整的说明,请参阅3个简单步骤中的NGINX Plus实时活动监视。
将status.conf文件下载到NGINX Plus服务器:
#cd /etc/nginx/conf.d#curl /resource/conf/status.conf> status.conf
在nginx.conf主文件的顶级配置块中读取status.conf:http
#在'http'块中包含conf.d / status.conf ;
指令文档:include
如果您使用的是常规的配置方案和现有的include
指令使用中讨论的通配符符号创建和修改配置文件,您可以添加一个单独的include
指令为status.conf如上图所示,或更改名称status.conf所以它是通配符捕获include
到http
块中现有指令中。例如,将其更改为status-http.conf意味着它被的include
指令捕获*-http.conf
。
status.conf中的注释说明了必须为部署自定义的指令。特别是,样本配置文件中的默认设置允许任何网络上的任何人访问仪表板。强烈建议您使用以下一种或多种方法限制对仪表板的访问:
基于IP地址的访问控制列表(ACL)。在样本配置文件中,取消对allow
和deny
指令的注释,并用10.0.0.0/8替换管理网络的地址。只有指定网络上的用户才能访问状态页面。
允许10 .0.0.0 / 8 ;否认全部;
指令文件:allow
,deny
RFC 7617中定义的HTTP基本身份验证。在样本配置文件中,取消注释auth_basic
和auth_basic_user_file
指令,然后将用户条目添加到/ etc / nginx / users文件中(例如,使用htpasswd生成器)。如果安装了Apache,则另一个选择是重用现有的htpasswd文件。
auth_basicon ;auth_basic_user_file/ etc / nginx / users ;
指令文件:auth_basic
,auth_basic_user_file
客户端证书,它是SSL / TLS完整配置的一部分。有关更多信息,请参见NGINX Plus管理指南和HTTPSSL / TLS模块的参考文档。
防火墙。将防火墙配置为禁止外部访问仪表板端口(样本配置文件中为8080)。
在要监视的每个上游组中,包括该zone
指令以定义一个共享内存区域,该区域存储该组的配置和运行时状态,并在工作进程之间共享。
例如,要监视Tomcat应用程序服务器,请将zone
指令添加到tomcat上游组(如果您已按照配置应用程序运行状况检查中的说明进行操作,则已经进行了此更改)。
#在tomcat上游的'http'块中{zonetomcat 64k ;服务器10.100.100.11 :8080 ;服务器10.100.100.12 :8080 ;#...}
指令文件:server
,upstream
,zone
在server
用于HTTPS流量的块(在为HTTP和HTTPS流量配置虚拟服务器中创建)中,添加status_zone
伪指令:
#在HTTPS流量的'server'块中status_zonetomcat ;
指令文档:status_zone
当您重新加载NGINX Plus配置文件时(例如通过运行命令),可以在http://nginx-plus-server-address:8080上立即使用NGINX Plus仪表板。nginx-sreload
启用上游组的动态重新配置
借助NGINX Plus,您可以使用NGINX Plus R13中引入的域名系统(DNS)或NGINX Plus API动态地重新配置负载均衡的服务器组(HTTP和TCP / UDP)。有关DNS和API方法的详细讨论,请参见NGINX Plus管理指南。
配置API方法
要使用NGINX Plus API对上游的Tomcat应用程序服务器组进行动态重新配置,您需要授予对其的安全访问权限。您可以使用API来添加或删除服务器,动态地改变它们的权重,并设置其地位primary
,backup
或down
。
将zone
指令包括在tomcat上游组中,以创建一个共享内存区域来存储组的配置和运行时状态,从而使信息可用于所有工作进程。(如果您配置了应用程序运行状况检查或实时活动监视,则已经进行了此更改。)
#在tomcat上游的'http'块中{zonetomcat 64k ;服务器192.168.33.11 :8080 ;服务器192.168.33.12 :8080 ;#...}
指令文件:server
,upstream
,zone
在server
用于HTTPS流量的块(在为HTTP和HTTPS流量配置虚拟服务器中创建)中,location
为NGINX Plus API添加一个新块,该块可实现其他功能的动态重新配置。它包含api
指令(api也是该位置的常规名称,如此处所用)。
(如果通过下载status.conf文件配置了实时活动监视,则它已经包含此块。)
强烈建议您限制对该位置的访问,以便只有授权的管理员才能访问NGINX Plus API。以下示例中的allow
和deny
指令仅允许从本地主机地址(127.0.0.1)访问。
#在HTTPS流量位置/ api {apiwrite = on ;允许127 .0.0.1 ;否认全部; }
指令文件:allow
和deny
,api
配置DNS方法
在该http
块中,添加resolver
指向您的DNS服务器的指令。在tomactupstream
块中,将resolve
参数添加到server
指令中,该指令指示NGINX Plus定期使用DNS重新解析域名(此处为)。
还应zone
在upstream
块中包含该指令,以创建一个共享内存区域来存储上游组的配置和运行时状态,从而使该信息可用于所有工作进程。(如果您配置了应用程序运行状况检查或实时活动监视,则已经进行了此更改。)
#在'http'块解析器中<DNS服务器的IP地址> ;上游雄猫 {区雄猫 64k ;服务器解决; }
指令和参数文档:resolve
,resolver
,zone
NGINX Plus版本9和更高版本也可以使用DNSSRV
记录中的其他信息,例如端口号。将service
参数server
与resolve
参数一起包括在指令中:
#在'http'块解析器中<DNS服务器的IP地址> ;上游雄猫 {区雄猫 64k ;服务器service = http resolve ; }
参数文档:service
完整配置以增强负载平衡
为方便起见,此处显示用于增强负载平衡的完整配置。它取决于http
上下文。完整文件可从NGINX网站下载。
我们建议您不要直接从本文档中复制文本,而应使用“创建和修改配置文件”中描述的方法在配置中包括这些指令–即,将include
指令添加到http
主nginx.conf文件的上下文中以进行读取在/etc/nginx/conf.d/tomcat-enhanced.conf的内容中。
proxy_cache_path/ tmp / NGINX_cache / keys_zone = backcache:10m ;#WebSocket配置图$ http_upgrade $ connection_upgrade {默认升级;“”关闭; }#在最后一个句号(。)之后提取 #JSESSIONID cookie中的数据,并将其存储在$ route_cookie变量中。映射$ cookie_jsessionid $ route_cookie {〜。+ \。(?P <route> w +)$$ route ; }#在URL中搜索结尾的jsessionid参数,提取最后一个句点(。)之后的 #数据,并将其存储在 #$ route_uri变量中。映射$ request_uri $ route_uri {jsessionid =。+ \。(?P <route> w +)$$ route ; }#应用程序运行状况检查与tomcat_check {状态200 ;标头Content-Type = text / html ;正文〜 “ Apache Tomcat / 8” ; }上游tomcat { #共享内存区域,用于应用程序运行状况检查,实时活动 #监视和动态重新配置区域,tomcat 64k ;#Tomcat应用服务器列表服务器10.100.100.11 :8080 slow_start = 30秒;服务器10.100.100.12 :8080 slow_start = 30秒;#基于JSESSION ID cookie粘性路由 $ route_cookie $ route_uri中的jvmRoute值的会话持久性 ;#根据JSESSIONID,取消以下指令的注释(并注释前面的 #'sticky route'和JSESSIONID'map'指令) #持久性 #sticky学习create = $ upstream_cookie_JSESSIONID #lookup = $ cookie_JSESSIONID #zone = client_sessions:1m; }服务器{听80 ;server_name;#将所有HTTP请求重定向到HTTPS位置/ {返回301 https:// $ server_name $ request_uri ; } }服务器{监听443 SSL http2 ;server_name;#对HTTPS流量status_zonetomcat的实时活动监视是必需的 ;ssl_certificate/etc/nginx/ssl/.crt ;ssl_certificate_key/etc/nginx/ssl/.key ;ssl_session_cacheshared:SSL:1m ;ssl_prefer_server_ciphers上;#跨Tomcat应用程序对'/ tomcat-app /'的负载平衡请求#服务器位置/ tomcat-app / {proxy_passhttp:// tomcat ;proxy_cachebackcache ;#主动运行状况检查health_checkinterval = 2s 失败= 1 pass = 5 uri = / match = tomcat_check ; }#当用户请求'/'location= / {返回302 / tomcat-app / ; 时,返回302重定向到'/ tomcat-app /' 。}#WebSocket配置位置/ wstunnel / {proxy_passhttp:// tomcat ;proxy_http_version1 .1 ;proxy_set_header升级 $ http_upgrade ;proxy_set_header连接 $ connection_upgrade ; }#安全访问NGINX Plus API位置/ api {apiwrite = on ;允许127 .0.0.1 ; #允许来自本地主机的访问拒绝所有; #拒绝其他任何地方的访问 } }
资源资源
NGINX Plus概述NGINX Plus管理指南NGINX维基修订记录
版本5(10月)–修复了配置代码段中注释的语法(添加缺少的内容#
)版本4(2月)– NGINX Plus API(NGINX Plus R14)更新版本3(4月)–关于HTTP / 2支持和动态模块的更新(NGINX Plus R11,NGINX开源1.11.5)版本2(1月)–关于HTTP / 2支持的更新(NGINX Plus R8,NGINX开源1.9.9)版本1(1月)–初始版本(NGINX Plus R7,NGINX开源1.9.5)
如果觉得《NGINX基于Tomcat配置负载均衡》对你有帮助,请点赞、收藏,并留下你的观点哦!