在前一篇博客中我們聊了下用Nginx和httpd對后端tomcat服務(wù)做反代相關(guān)配置,回顧請參考https://www.jb51.net/article/191277.htm;今天我們來聊一聊用Nginx和httpd對tomcat集群做負(fù)載均衡的配置以及需要注意的點;在前邊的演示和配置都是以單臺tomcat來配置使用;但是在生產(chǎn)中單臺tomcat實在支撐不了大規(guī)模的訪問,這個時候我們就需要考慮把多臺tomcat做成集群對外提供服務(wù);多臺tomcat做成集群對外提供服務(wù)就必然要有一個調(diào)度器來對客戶端的請求做調(diào)度,常用的調(diào)度器有nginx httpd haproxy lvs等等;用這些調(diào)度器來對tomcat做負(fù)載均衡的配置和對其他web服務(wù)器做負(fù)載均衡的配置沒有本質(zhì)的不同;我們都可以把tomcat當(dāng)作web服務(wù)器來配置就好;
1、環(huán)境準(zhǔn)備
運行docker 啟動兩個tomcat容器當(dāng)作后端tomcat server 并且把兩臺tomcat容器的網(wǎng)頁目錄分別用存儲卷的方式映射到/tomcat/doc/tomcat1和tomcat1目錄
提示:以上就運行了兩個tomcat容器,分別是tct1和tc2,并且我們把/usr/local/tomcat/webapps/myapp映射到宿主機(jī)的/tomcat/doc/tomcat1和tomcat2,這樣做我們就可以直接把網(wǎng)頁腳本放到宿主機(jī)上的這個目錄從而實現(xiàn)把網(wǎng)頁部署到tomcat的默認(rèn)虛擬主機(jī)上;
編輯兩個容器的主頁文件內(nèi)容
提示:以上分別給tomcat1和tomcat2提供了一個測試主頁;
現(xiàn)在分別放tomcat1和tomcat2看看對應(yīng)主頁是否能夠訪問到
提示:可以看到tomcat1和tomcat2都能夠訪問到,到此后端tomcat的環(huán)境就準(zhǔn)備好了;接下來我們來配置nginx來對他們做負(fù)載均衡;
2、配置nginx對tomcat做負(fù)載均衡
提示:以上配置就是把兩臺tomcat容器歸并為tcsevs組,然后反代/的訪問到這個組上即可。這樣配置默認(rèn)是輪詢的;
驗證:訪問宿主機(jī)上的80端口看看是否分別能夠訪問到后端兩臺tomcat容器提供的主頁?
檢查nginx配置文件語法格式并啟動nginx
訪問宿主機(jī)的80端口,看看是否能夠訪問到后端tomcat提供的頁面?
提示:可以看到訪問宿主機(jī)的80端口是能夠正常訪問到后端tomcat服務(wù)器上的,并且也看出了默認(rèn)輪詢調(diào)度的效果;但是這里存在一個問題,同一用戶訪問宿主機(jī)的80端口,給我們響應(yīng)的結(jié)果session id都不同,這意味著nginx并沒有追蹤到用戶的狀態(tài)信息,原因是因為http請求本來就是無狀態(tài)的,為了讓服務(wù)記錄用戶的狀態(tài)信息,在nginx上我們可以基于源ip做調(diào)度,什么意思呢,就是同一源ip地址,nginx都把該請求調(diào)度到同一臺后端server上,使得同一用戶訪問的狀態(tài)信息始終調(diào)度到同一后端server上;
nginx基于源ip做會話保持
提示:ip_hash和hash $remote_addr都表示對源ip進(jìn)行哈希計算,然后把取得到結(jié)果和總權(quán)重做模運算,結(jié)果落到那個節(jié)點,就調(diào)度到那個節(jié)點;什么意思呢,如上所示,后端server有兩個,且權(quán)重都為1,那么他們的權(quán)重和就是2,ip_hash和hash $remote_addr就是把客戶端的ip地址的前三段進(jìn)行hash計算,然后把得到的值再和權(quán)重和做取模運算,很顯然取模后端結(jié)果要么是0要么是1,如果取模后的結(jié)果是1,那么nginx基于它內(nèi)部的對應(yīng)關(guān)系,把該請求就調(diào)度到tomcatB或者tomcatA;
測試:重啟niginx ,訪問宿主機(jī)的80端口看看是否都把請求調(diào)度到同一后端server上?
提示:可以看到現(xiàn)在訪問宿主機(jī)的80端口就沒有在輪詢了,而是始終調(diào)度到tomcatA這臺server上進(jìn)行響應(yīng);但是我們訪問127.0.0.1的80端口它又調(diào)度到tomcatB上去了,這是因為nginx的調(diào)度算法中hash $remote_addr 和ip_hash是把IP地址的前24位做hash,所以如果你的IP前三段相同時,nginx它會認(rèn)為是和nginxserver是同一局域網(wǎng),所以它會把請求調(diào)度到同一局域網(wǎng)之前來請求過的后端server上進(jìn)行響應(yīng);當(dāng)然除了我們可以對源地址做hash,我們也可以對其他首部做hash計算,原理都是類似的,都是把對應(yīng)首部的值做hash計算,然后同權(quán)重和做取模運算;然后根據(jù)nginx內(nèi)部的對應(yīng)關(guān)系,把取模后端結(jié)果相同的請求調(diào)度到同一后端server,就是基于這樣的原理,把客戶端和后端server綁定到一起實現(xiàn)了會話綁定;
httpd對tomcat做負(fù)載均衡
httpd做負(fù)載均衡器,需要確認(rèn)httpd是否開啟了proxy_http_module、proxy_module 、proxy_balancer_module如果需要用到ajp還需要確定proxy_ajp_module模塊是否啟用,以及調(diào)度算法的三個模塊lbmethod_bybusyness_module 、lbmethod_byrequests_module、lbmethod_bytraffic_module;以上模塊對于調(diào)度算法來說用到那個啟用那個也行,對于http或者ajp也是一樣的;用得到就啟用,用不上不啟用也沒關(guān)系;
提示:可以看到我們需要用的模塊都是啟用了的;
配置httpd對后端tomcat 做負(fù)載均衡
提示:從上面的配置,其實感覺和nginx的配置邏輯很相似,首先把后端server歸并成一個組,然后反代時把請求代理到定義的組上即可;這里說一下調(diào)度算法吧,proxyset lbmethod 用來指定調(diào)度算法的,默認(rèn)不寫是使用byrequests,這個算法就是httpd里的輪詢調(diào)度算法,當(dāng)然在每個balancermember 后面加上權(quán)重,就成了加權(quán)輪詢了;除此調(diào)度算法,我們還可以使用bytraffic,這個調(diào)度算法是根據(jù)和后端server的傳輸流量來調(diào)度,如果某個服務(wù)器傳輸流量很大,那么他會把請求往傳輸流量相對小的服務(wù)器上調(diào)度;bybusyness這個調(diào)度算法是根據(jù)后端server的繁忙程度來調(diào)度;類似nginx里的least_conn最少連接算法;對balancermember 我們也可以向nginx 那樣設(shè)置單獨屬性,只需要在后面寫上對應(yīng)的屬性即可;常用的屬性有status 這個屬性表示表示對應(yīng)balancermember是處于什么狀態(tài),其中對status有6種取值;D表示禁用對應(yīng)server,不提供任何請求;S表示人工手動標(biāo)識為不可用;I表示強(qiáng)制上線模式(強(qiáng)制忽略錯誤模式);H表示熱備模式(相當(dāng)于nginx里的backup,只有組里的其他server都不可用時,它才會被激活,用于say sorry);E表示強(qiáng)制處于錯誤模式(即便沒有錯誤也要讓他處于有錯誤);N表示排干模式;除了status來指定balancermember的狀態(tài),還可以使用loadfactor來指定權(quán)重,類似于nginx里的weight;
停掉nginx,檢查httpd 的配置文件語法,如果沒有問題就啟動httpd
訪問httpd提供的服務(wù),看看是否訪問到后端tomcat的頁面
提示:可以看到和nginx的訪問一樣,都可以實現(xiàn)輪詢;
httpd基于cookie對后端tomcat做會話粘性
提示:以上配置表示給客戶端請求cookie首部添加一個標(biāo)識,ROUTEID=%{BALANCER_WORKER_ROUTE}e表示,我們指定的ROUTEID標(biāo)識的值為balancermember 后面的route屬性指定的值;env=BALANCER_ROUTE_CHANGED表示,如果我們指定的route的值發(fā)生變化時,它需要重新調(diào)度;簡單講就是給cookie信息打標(biāo)簽;proxyset stickysession=ROUTEID 表示給該組所有成員設(shè)置會話粘性KEY的名稱為ROUTEID,這個值通常要和上面的set-cookie后面的KEY對應(yīng);如果把它寫到每個balancermember后面表示單獨給某個server設(shè)置會話粘性KEY的名稱;如果寫在proxy配置段里需要用proxyset指令來設(shè)置,表示給該組的所有member設(shè)置 stickysession;簡單講就是聲明以那個key來當(dāng)做會話粘性的基準(zhǔn)來做調(diào)度;這個邏輯和haproxy里面的會話保持設(shè)定類似;有關(guān)haproxy配置會話保持可以參考https://www.jb51.net/article/33639.htm;
測試:檢查httpd的配置文件語法,如果沒有問題就重啟httpd,然后訪問httpd看看會有什么變化
用curl 來模擬第一次訪問httpd服務(wù)器,看看響應(yīng)首部有什么變化?
提示:可以看到訪問httpd服務(wù)器,在響應(yīng)首部會多一個set-cookie首部,并且該首部的的值就是我們之前在配置文件中配置的KEY和value;set-cookie首部主要是在瀏覽器下次請求時,它會把set-cookie首部的值用cookie首部攜帶去訪問服務(wù)器,這樣一來,服務(wù)器就可根據(jù)客戶端請求報文的cookie的值,來分析本次請求是那個客戶端發(fā)送過來,后續(xù)服務(wù)端該怎么調(diào)度;
用瀏覽器訪問,看看客戶端后續(xù)的請求,是不是把第一次訪問中的set-cookie的值拿上去請求服務(wù)端?
提示:可以看到瀏覽器第一次訪問,服務(wù)器會在響應(yīng)首部中添加一個set-cookie的首部;這個首部的值就是ROUTEID是目前響應(yīng)我們的后端server上的route的值;
提示:可以看到客戶端在請求首部cookie中,把之前set-cookie中的值都攜帶過去了;此時httpd收到客戶端請求就可以根據(jù)設(shè)置的stickysession 指定的KEY來判斷該把對應(yīng)請求發(fā)送到那個后端server上進(jìn)行響應(yīng)了;這樣一來,只要客戶端的cookie不變,那么它每次訪問服務(wù)端都會以cookie首部的值去告訴服務(wù)端該調(diào)度到那臺后端server上;
用curl模仿客戶端請求攜帶cookie訪問服務(wù)端
提示:可以看到當(dāng)我們使用curl模仿客戶端訪問攜帶cookie時,在響應(yīng)首部就不會在給我們發(fā)set-cookie首部(這里的set-cookie是指和我們在服務(wù)器設(shè)定相關(guān)的首部),并且我們攜帶不同ROUTEID的cookie,它會根據(jù)我們攜帶的ROUTEID的值把我們調(diào)度到不同的后端server上進(jìn)行響應(yīng);對于httpd負(fù)載均衡代理后端tomcat用ajp的配置方式和http的配置方式一樣的,不同的只是把后端server的http協(xié)議修改成ajp,后端tomcat的端口修改成ajp協(xié)議監(jiān)聽的端口即可,默認(rèn)tomcatajp協(xié)議監(jiān)聽在8009端口;
配置httpd后端管理界面頁
提示:以上配置表示啟動httpd管理頁面,并綁定到/manager-page這個uri上,對于/manager-page這個uri不做任何代理,并且該rui只能允許ip地址為192.168.0.232的主機(jī)訪問,其他主機(jī)都沒有權(quán)限,包括服務(wù)器本身;
驗證:用非192.168.0.232的主機(jī)訪問192.168.0.22/manager-page看看是否能夠訪問到?
提示:可以看到用192.168.0.22去訪問,提示403沒有權(quán)限;
用192.168.0.232去訪問,看看是否能夠訪問到管理頁面?
提示:用192.168.0.232上的瀏覽器上可以正常訪問到httpd的管理頁面的;
動態(tài)修改tomcat1的權(quán)重
提示:正因為這個頁面可以動態(tài)的更改后端服務(wù)器的屬性,所以通常需要做訪問限制;
到此這篇關(guān)于Nginx/Httpd負(fù)載均衡tomcat配置的文章就介紹到這了,更多相關(guān)Nginx/Httpd負(fù)載均衡tomcat配置內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!