㈠ nginx負載均衡原理
負載均衡（Load Balance），它在網路現有結構之上可以提供一種廉價、有效、透明的方法來擴展 網路設備 和 伺服器的帶寬 ，並可以在一定程度上 增加吞吐量 、 加強網路數據處理能力 、提高 網路的靈活性 和 可用性 等。用官網的話說，它充當著網路流中「交通指揮官」的角色，「站在」伺服器前 處理所有伺服器端和客戶端之間的請求 ，從而最大程度地 提高響應速率和容量利用率 ，同時 確保任何伺服器都沒有超負荷工作 。如果單個伺服器出現故障， 負載均衡的方法會將流量重定向到其餘的集群伺服器，以保證服務的穩定性 。當新的伺服器添加到伺服器組後，也可通過負載均衡的方法使其開始自動處理客戶端發來的請求。
負載均衡涉及到以下的基礎知識。
a. Round Robin: 對所有的backend輪訓發送請求，算是最簡單的方式了，也是默認的分配方式；
b. Least Connections(least_conn): 跟蹤和backend當前的活躍連接數目，最少的連接數目說明這個backend負載最輕，將請求分配給他，這種方式會考慮到配置中給每個upstream分配的weight權重信息；
c. Least Time(least_time): 請求會分配給響應最快和活躍連接數最少的backend；
d. IP Hash(ip_hash): 對請求來源IP地址計算hash值，IPv4會考慮前3個octet，IPv6會考慮所有的地址位，然後根據得到的hash值通過某種映射分配到backend；
e. Generic Hash(hash): 以用戶自定義資源(比如URL)的方式計算hash值完成分配，其可選consistent關鍵字支持一致性hash特性；
用戶(瀏覽器)在和服務端交互的時候，通常會在本地保存一些信息，而整個過程叫做一個會話(Session)並用唯一的Session ID進行標識。會話的概念不僅用於購物車這種常見情況，因為HTTP協議是無狀態的，所以任何需要邏輯上下文的情形都必須使用會話機制，此外HTTP客戶端也會額外緩存一些數據在本地，這樣就可以減少請求提高性能了。如果負載均衡可能將這個會話的請求分配到不同的後台服務端上，這肯定是不合適的，必須通過多個backend共享這些數據，效率肯定會很低下，最簡單的情況是保證會話一致性——相同的會話每次請求都會被分配到同一個backend上去。
出問題的backend要能被及時探測並剔除出分配群，而當業務增長的時候可以靈活的添加backend數目。此外當前風靡的Elastic Compute雲計算服務，服務商也應當根據當前負載自動添加和減少backend主機。
通常現代的網路服務者一個域名會關連到多個主機，在進行DNS查詢的時候，默認情況下DNS伺服器會以round-robin形式以不同的順序返回IP地址列表，因此天然將客戶請求分配到不同的主機上去。不過這種方式含有固有的缺陷：DNS不會檢查主機和IP地址的可訪問性，所以分配給客戶端的IP不確保是可用的(Google 404)；DNS的解析結果會在客戶端、多個中間DNS伺服器不斷的緩存，所以backend的分配不會那麼的理想。
轉自 https://blog.csdn.net/weixin_43694144/java/article/details/84098906
㈡ nginx配置負載均衡，訪問頁面不載入JS、CSS等靜態文件，F12查看源代碼發現，jsp獲取basePath錯誤
在NGINX.CONF文件中配置地址和IP：
proxy_set_header Host $host; #從header頭中獲取的主機名
proxy_set_header X-Real-IP $remote_addr;
#獲取header頭中獲取的主機的真實IP
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#獲取header頭中獲取代理者的真實ip
㈢ istio-ingress-gateway
本任務描述了如何配置 Istio，以使用 Istio Gateway 來將服務暴露至服務網格之外。
如果 EXTERNAL-IP 值已設置，說明環境正在使用外部負載均衡，可以用其為 ingress gateway 提供服務。 如果 EXTERNAL-IP 值為 <none> （或持續顯示 <pending> ），說明環境沒有提供外部負載均衡，無法使用 ingress gateway。 在這種情況下，你可以使用服務的 node port 訪問網關。
4.2 為通過 Gateway 的入口流量配置路由:
已為 httpbin 服務創建了 虛擬服務 配置，包含兩個路由規則，允許流量流向路徑 /status 和 /delay 。
gateways 列表規約了哪些請求允許通過 httpbin-gateway 網關。 所有其他外部請求均被拒絕並返回 404 響應。
注意上文命令使用 -H 標識將 HTTP 頭部參數 Host 設置為 「httpbin.example.com」。 該操作為必須操作，因為 ingress Gateway 已被配置用來處理 「httpbin.example.com」 的服務請求，而在測試環境中並沒有為該主機綁定 DNS 而是簡單直接地向 ingress IP 發送請求
事先，在服務網格中創建一個服務並向外部流量暴露該服務的 HTTP 端點
㈣ Nginx 負載均衡如何配置，高並發報502如何返回正常信息
負載均衡入口伺服器配置
入口
upstream mServer{
server 149.129.114.100:8080 weight=2 fail_timeout=30s max_fails=0;
server 149.129.75.101:8080 weight=4 fail_timeout=30s max_fails=0;
server 149.129.76.102:8080 weight=4 fail_timeout=30s max_fails=0;
}
server {
listen 80;
server_name www.xxx.com;
#charset koi8-r;
#access_log logs/host.access.log main;
#遇到502、503、504等狀態碼時，我們可以改變將之成200，這樣在調用介面時，就可以正常的返回信息，給用戶提供良好的交互環境。
error_page 502 503 504 =200 /dealwith_502?callback=$arg_callback;
location /dealwith_502{
#下面這些header，是為了防止跨域問題
add_header 'Content-Type' 'application/json; charset=utf-8';
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT';
set $ret_body '{ "status": 0, "info": "系統繁忙，請稍後訪問", "data": [] }';
if ( $arg_callback != "" )
{
return 200 'try{$arg_callback($ret_body)}catch(e){}';
}
return 200 $ret_body;
}
location / {
root html;
proxy_pass http://mServer;
proxy_set_header Host $host;
index index.php index.html index.htm;
}
}
伺服器1
server
{
listen 8080;
#listen [::]:80;
server_name 149.129.114.100;
index home.html index.htm index.php default.html default.htm default.php;
root /home/wwwroot/xxx;
#error_page 404 /404.html;
error_page 502 503 504 =200 /dealwith_502?callback=$arg_callback;
location /dealwith_502{
add_header 'Content-Type' 'application/json; charset=utf-8';
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT';
set $ret_body '{ "status": 0, "info": "系統繁忙，請稍後訪問", "data": [] }';
if ( $arg_callback != "" )
{
return 200 'try{$arg_callback($ret_body)}catch(e){}';
}
return 200 $ret_body;
}
location / {
if (!-e $request_filename) {
rewrite ^(.*)$ /index.php/$1 last;
break;
}
}
location ~ [^/]\.php(/|$)
{
# comment try_files $uri =404; to enable pathinfo
#try_files $uri =404;
fastcgi_pass unix:/tmp/php-cgi.sock;
fastcgi_index index.php;
include fastcgi.conf;
include pathinfo.conf;
fastcgi_param PHP_ADMIN_VALUE "open_basedir=/home/wwwroot/:/tmp/:/proc/";
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 30d;
}
location ~ .*\.(js|css)?$
{
expires 12h;
}
}
其他伺服器配置和伺服器1的配置是相同的，這樣就可以避免高並發的出現。我做的 項目 就是這樣處理的。
㈤ LVS負載均衡到後端apache的虛擬主機報404錯誤 檢查日誌發現：File does not exist: /etc/httpd/htdocs
錯誤日誌和訪問日誌一樣也是Apache的標准日誌。本文分析錯誤日誌的內容，介紹如何設置和錯誤日誌相關的選項，文檔錯誤和CGI錯誤的分類，以及如何方便地查看日誌內容，等等。
一、位置和內容
錯誤日誌無論在格式上還是在內容上都和訪問日誌不同。然而，錯誤日誌和訪問日誌一樣也提供豐富的信息，我們可以利用這些信息分析伺服器的運行情況、哪裡出現了問題。
錯誤日誌的文件名字是error_log，但如果是Windows平台，則錯誤日誌的文件名字是error.log。錯誤日誌的位置可以通過ErrorLog指令設置：
ErrorLog logs/error.log
除非文件位置用「/」開頭，否則這個文件位置是相對於ServerRoot目錄的相對路徑。如果Apache採用默認安裝方式安裝，那麼錯誤日誌的位置應該在/usr/local/apache/logs下。但是，如果Apache用某種包管理器安裝，錯誤日誌很可能在其他位置。
正如其名字所示，錯誤日誌記錄了伺服器運行期間遇到的各種錯誤，以及一些普通的診斷信息，比如伺服器何時啟動、何時關閉等。
我們可以設置日誌文件記錄信息級別的高低，控制日誌文件記錄信息的數量和類型。這是通過LogLevel指令設置的，該指令默認設置的級別是error，即記錄稱得上錯誤的事件。有關該指令中允許設置的各種選項的完整清單，請參見http://www.apache.org/docs/mod/core.html#loglevel的Apache文檔。
大多數情況下，我們在日誌文件中見到的內容分屬兩類：文檔錯誤和CGI錯誤。但是，錯誤日誌中偶爾也會出現配置錯誤，另外還有前面提到的伺服器啟動和關閉信息。
二、文檔錯誤
文檔錯誤和伺服器應答中的400系列代碼相對應，最常見的就是404錯誤——Document Not Found（文檔沒有找到）。除了404錯誤以外，用戶身份驗證錯誤也是一種常見的錯誤。
404錯誤在用戶請求的資源（即URL）不存在時出現，它可能是由於用戶輸入的URL錯誤，或者由於伺服器上原來存在的文檔因故被刪除或移動。
順便說一下，按照Jakob Nielson的意見，在不提供重定向或者其他補救措施的情況下，我們永遠不應該移動或者刪除Web網站的任何資源。Nielson的更多文章，請參見http://www.zdnet.com/devhead/alertbox/。
當用戶不能打開伺服器上的文檔時，錯誤日誌中出現的記錄如下所示：
[Fri Aug 18 22:36:26 2000] [error]
[client 192.168.1.6] File does not exist:
/usr/local/apache/bugletdocs/Img/south-korea.gif
可以看到，正如訪問日誌access_log文件一樣，錯誤日誌記錄也分成多個項。
錯誤記錄的開頭是日期/時間標記，注意它們的格式和access_log中日期/時間的格式不同。access_log中的格式被稱為「標准英文格式」，這或許是歷史跟我們開的一個玩笑，但現在要改變它已經太遲了。
錯誤記錄的第二項是當前記錄的級別，它表明了問題的嚴重程度。這個級別信息可能是LogLevel指令的文檔中所列出的任一級別（參見前面LogLevel的鏈接），error級別處於warn級別和crit級別之間。404屬於error錯誤級別，這個級別表示確實遇到了問題，但伺服器還可以運行。
錯誤記錄的第三項表示用戶發出請求時所用的IP地址。
記錄的最後一項才是真正的錯誤信息。對於404錯誤，它還給出了完整路徑指示伺服器試圖訪問的文件。當我們料想某個文件應該在目標位置卻出現了404錯誤時，這個信息是非常有用的。此時產生這種錯誤的原因往往是由於伺服器配置錯誤、文件實際所處的虛擬主機和我們料想的不同，或者其他一些意料不到的情況。
由於用戶身份驗證問題而出現的錯誤記錄如下所示：
[Tue Apr 11 22:13:21 2000]
[error] [client 192.168.1.3] user rbowen@rcbowen.
com: authentication failure for "/cgi-bin/hirecareers/company.cgi":
password mismatch
注意，由於文檔錯誤是用戶請求的直接結果，因此它們在訪問日誌中也會有相應的記錄。
三、CGI錯誤
錯誤日誌最主要的用途或許是診斷行為異常的CGI程序。為了進一步分析和處理方便，CGI程序輸出到STDERR（Standard Error，標准錯誤設備）的所有內容都將直接進入錯誤日誌。這意味著，任何編寫良好的CGI程序，如果出現了問題，錯誤日誌就會告訴我們有關問題的詳細信息。
然而，把CGI程序錯誤輸出到錯誤日誌也有它的缺點，錯誤日誌中將出現許多沒有標准格式的內容，這使得用錯誤日誌自動分析程序從中分析出有用的信息變得相當困難。
下面是一個例子，它是調試Perl CGI代碼時，錯誤日誌中出現的一個錯誤記錄：
[Wed Jun 14 16:16:37 2000] [error] [client 192.168.1.3] Premature
end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
Global symbol "$rv" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.
Global symbol "%details" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.
Global symbol "$Config" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.
Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
aborted e to compilation errors.
可以看到，CGI錯誤和前面的404錯誤格式相同，包含日期/時間、錯誤級別以及客戶地址、錯誤信息。但這個CGI錯誤的錯誤信息有好幾行，這往往會干擾一些錯誤日誌分析軟體的工作。
有了這個錯誤信息，即使是對Perl不太熟悉的人也能夠找出許多有關錯誤的信息，例如至少可以方便地得知是哪幾行代碼出現了問題。Perl在報告程序錯誤方面的機制是相當完善的。當然，不同的編程語言輸出到錯誤日誌的信息會有所不同。
由於CGI程序運行環境的特殊性，如果沒有錯誤日誌的幫助，大多數CGI程序的錯誤都將很難解決。
有不少人在郵件列表或者新聞組中抱怨說自己有一個CGI程序，當打開網頁時伺服器卻返回錯誤，比如「Internal Server Error」。我們可以肯定，這些人還沒有看過伺服器的錯誤日誌，或者根本不知道錯誤日誌的存在。決多大多數情況下，錯誤日誌能夠精確地指出CGI錯誤的所在以及如何修正這個錯誤。
四、查看日誌文件
我常常告訴別人說，在進行開發的同時我會不斷地檢查伺服器的日誌，以便能夠立即知道哪兒出了問題。但我得到的回答卻往往是沉默。起先我以為這種沉默意味著「你當然得這樣做」，後來我才發現這種沉默的真正含義是「我不知道別人的做法，但我自己是不幹的。」
雖然如此，下面我們還是要看看如何方便地查看伺服器日誌文件。用telnet連接到伺服器，然後輸入下面的命令：
tail -f /usr/local/apache/logs/error_log
該命令將顯示出日誌文件的最後幾行內容，如果有新的內容加入到日誌文件，它還會立即顯示出新加入的內容。
Windows用戶也同樣可以使用這種方法，比如可以使用各種為Windows提供的Unix工具軟體包。我個人愛好一個稱為AINTX的工具，它可以在http://maxx.mc.net/~jlh/nttools/index.htm找到。
還有一種替代方法是使用下面的Perl代碼，它利用了一個稱為File::Tail的模塊：
use File::Tail;
$file=File::Tail->new("/some/log/file");
while (defined($line=$file->read)) {
print "$line";
}
無論具體採用的是哪一種方法，同時打開多個終端窗口都是一種好習慣：比如在一個窗口中顯示錯誤日誌，在另一個窗口中顯示訪問日誌。這樣，我們就能夠隨時獲知網站上發生的事情並立即予以解決。轉載
㈥ Not Found HTTP Error 404. The requested resource is not found.網站突然打開這樣
The requested resource is not found意思就是無效的資源引用和不被允許訪問的頁面。請求的資源不否，表示你所打開的位於對方伺服器上的文件已經刪除或暫時不可用。 需要伺服器端來處理此問題。可嘗試下列方法解決問題：
1、在開發新頁面時取的頁面文件名當時也非常注意。包括頁面裡面的每一個action名，超鏈接的名稱，菜單項，struts-config.xml，DAO類，java類裡面的每個相應的名字都仔細檢查過沒有什麼錯誤。
2、啟動tomcat6運行系統後，在myeclipse8.5窗口瀏覽器中打開系統瀏覽頁面進入系統，其他頁面正常訪問，只有新加的頁面出現不能訪問的情況。
3、後來查到一個英文頁面裡面提到的解決方法就是反復強調檢查拼寫。
4、這只是個思路，問題還是要靠自己解決。進入tomcat程序目錄，檢查了頁面發現新加頁面的文件名排列與其他頁面不一樣齊。原來字母前面有一個空格符。試著去掉空格，然後運行，正常了。
㈦ linuxcentos6.8 負載均衡解析apache 出現 400狀態碼錯誤信息怎麼解決
當試圖用錯誤文件處理請求時 遇到404錯誤-沒有找到每一個互聯網用戶都會在某個地方碰到「404——無法找到文件」的錯誤頁面。或許在非正式微軟版本上會顯示：「該頁無法顯示。」或者瀏覽器顯示錯誤為：「頁面錯誤。」並非每個網站都以相同的方式公布錯誤。錯誤404是最為常見的一組標准化可配置HTTP協議錯誤，定位在400到505之間。當這些錯誤得到標准化時，Web伺服器處理404錯誤的方法最終就取決於網路管理員。這就是為什麼將其稱之為「可配置」。最為通用的Web伺服器軟體，Apache，通過位於public_html目錄下的小文本文件.htaccess來控制HTTP錯誤的處理方法。重定向語法非常簡單：「ErrorDocument [error code] [url]」。允許錯誤代碼的URL能夠指向任意一個具有有效地址的網站。通常，它指向一個工作目錄中的自定義頁面，如「404error.html」。Internet Explorer顯示的預設404錯誤頁面依賴於Web用戶控制的兩個變數。第一個變數，可以通過進入Internet選項並選擇高級標簽，向下拖動滾動條到「顯示友好HTTP錯誤消息」，取消復選框的選中狀態，可以禁用此項功能。未被選中的復選框將釋放原始的HTTP消息。但是，作為一個網頁設計者，你不能假設用戶已經取消了這個選項；同時，作為一個Internet Explorer用戶，你也不能就認為網頁設計者已經設計了友好的用戶信息。第二個變數是錯誤頁面自身的大小，以位元組為單位。Windows注冊表中的鍵值就是，HKEY_LOCAL_ ExplorerMainErrorThresholds，將404錯誤頁面大小的極限值設置為512位元組。如果該網站的404錯誤頁面超出512位元組，那麼Internet Explorer將顯示此錯誤頁面；如果未超出范圍，那麼就使用自身的錯誤頁面。(CE問答)
㈧ Linux 系統 NGINX 負載均衡404 錯誤怎麼處理
使用NGINX 實現負載均衡，但一組伺服器的數據不是實施同步，主伺服器有了數據要過段時間才同步到其他伺服器 upstream image.stream.com { server 192.168.1.25:8088; server 192.168.1.24:8088; server 192.168.1.23:8088; } 用戶訪問圖片的時候，就有60% 的
㈨ F5負載均衡虛擬伺服器配置FTP埠訪問不了
正常情況下主動模式FTP是使用21埠進行通訊，20埠傳輸數據。
81埠是對外，真實伺服器的埠是21么，還是也改掉了？
你需要看一下是否20埠也做了更改，如果更改了，需要新創建一個ftp profile，然後把數據傳輸的埠修改為你設置的傳輸埠。
另外，1024以下的埠都已經是被分配出去的，建議使用高一點的埠。
訪問方式應該為ftp://vip:port或直接在命令行下訪問