本章介紹如何使用NGINX Plus和NGINX開放源代理和負載平衡TCP和UDP流量。
目錄
介紹
負載平衡是指跨多個后端服務器有效分布網絡流量。
在版本5和更高版本中，NGINX可以代理和負載平衡TCP流量。TCP（傳輸控制協議）是用於許多流行的應用和服務的協議，例如LDAP，MySQL和RTMP。
在版本9和更高版本中，NGINX可以代理和負載平衡UDP流量。UDP（用戶數據報協議）是許多流行的非事務性應用程序的協議，例如DNS，syslog和RADIUS。
要加載平衡HTTP流量，請參閱HTTP負載平衡一文。
先決條件
- 最新的
--with-streamNGINX 開源采用配置標志或最新的NGINX Plus構建（無需額外的構建步驟） - 通過TCP或UDP進行通信的應用程序，數據庫或服務
- 上游服務器，每個服務器運行應用程序，數據庫或服務的同一實例
配置反向代理
首先，您需要配置反向代理，以便NGINX 可以將客戶端的TCP連接或UDP數據報轉發到上游組或代理服務器。
打開NGINX配置文件並執行以下步驟：
1、創建頂級stream {}塊：
stream {
...
}
2、server {}在頂層stream {}上下文中為每個虛擬服務器 定義一個或多個配置塊。
3、在server {}每個服務器的配置塊中，包括listen用於定義服務器偵聽的IP地址和/或端口的指令。對於UDP流量，還包括udp參數。TCP是stream上下文的默認協議，因此沒有tcp
參數listen指令：
stream { server { listen 12345; ... } server { listen 53 udp; ... } ... }
4、包括proxy_pass用於定義代理服務器的指令或服務器轉發流量的上游組：
stream { server { listen 12345; #TCP traffic will be proxied to the "stream_backend" upstream group proxy_pass stream_backend; } server { listen 12346; #TCP traffic will be proxied a proxied server proxy_pass backend.example.com:12346; } server { listen 53 udp; #UDP traffic will be proxied to the "dns_servers" upstream group proxy_pass dns_servers; } ... }
5、或者，如果您的代理服務器有多個網絡接口，您可以配置NGINX選擇一個源IP地址連接到上游服務器。如果NGINX后面的代理服務器配置為接受來自特定IP網絡或IP地址范圍的連接，這可能很有用。
指定proxy_bind必需的網絡接口的偽指令和IP地址：
stream { ... server { listen 127.0.0.1:12345; proxy_pass backend.example.com:12345; proxy_bind 127.0.0.1:12345; } }
6、或者，您可以調整兩個內存緩沖區的大小，其中NGINX可以從客戶端和上游連接中輸入數據。如果存在小量的數據，則可以減少緩沖器，這可以節省存儲器資源。如果存在大量數據，則可以增加緩沖區大小以減少套接字讀/寫操作的數量。一旦在一個連接上接收到數據，NGINX讀取它並通過另一個連接轉發它。緩沖區由指令proxy_buffer_size控制：
stream { ... server { listen 127.0.0.1:12345; proxy_pass backend.example.com:12345; proxy_buffer_size 16k; } }
配置TCP或UDP負載平衡
1、創建一組服務器，或流量將負載平衡的上游組。upstream {}在頂層stream {}上下文中定義一個或多個配置塊，並為上游組設置名稱，例如，stream_backend對於TCP服務器和dns_serversUDP服務器：
stream {
upstream stream_backend {
...
}
upstream dns_servers {
...
}
...
}
注意:確保上一個配置中proxy_pass引用了上游組的名稱。
2、使用上游服務器填充上游組。在upstream {} 塊中，server為每個上游服務器添加一個偽指令，指定其IP地址或主機名（可解析為多個IP地址）和必需的端口號。請注意，您不為每個服務器定義協議，因為它是由您在前面創建listen的server塊中的偽指令中包含的參數為整個上游組定義的。
stream { upstream stream_backend { server backend1.example.com:12345; server backend2.example.com:12345; server backend3.example.com:12346; ... } upstream dns_servers { server 192.168.136.130:53; server 192.168.136.131:53; ... } ... }
配置上游組使用的負載分擔方法。您可以指定以下方法之一：
round-robin- 默認情況下，NGINX使用循環算法對流量進行負載均衡，將其順序定向到配置的上游組中的服務器。因為它是默認方法，沒有round-robin指令; 只需upstream在頂層stream上下文中創建一個配置塊並添加上server一步中描述的指令。least_conn- NGINX選擇當前活動連接數較少的服務器。least_time- NGINX選擇平均延遲最小，活動連接數最少的服務器。最低平均延遲是基於以下參數中的哪一個包括在least_time指令上計算的：connect- 連接到上游服務器的時間first_byte- 接收數據的第一個字節的時間last_byte- 從服務器接收完整響應的時間-
upstream stream_backend { least_time first_byte; server backend1.example.com:12345; server backend2.example.com:12345; server backend3.example.com:12346; } hash- NGINX基於用戶定義的密鑰選擇服務器，例如源IP地址（$remote_addr）：
upstream stream_backend { hash $remote_addr; server backend1.example.com:12345; server backend2.example.com:12345; server backend3.example.com:12346; }
所述散列負載平衡方法還用於配置會話持久性。由於散列函數基於客戶端IP地址，來自給定客戶端的連接始終傳遞到同一服務器，除非服務器關閉或以其他方式不可用。指定一個可選consistent參數以應用ketama一致性散列方法：
hash $remote_addr consistent;
或者，對於每個上游服務器，指定服務器特定的參數，包括最大連接數，服務器權重等：
upstream stream_backend { hash $remote_addr consistent; server backend1.example.com:12345 weight=5; server backend2.example.com:12345; server backend3.example.com:12346 max_conns=3; } upstream dns_servers { least_conn; server 192.168.136.130:53; server 192.168.136.131:53; ... }
另一種方法是將流量代理到單個服務器而不是上游組。如果您通過主機名標識服務器，並將主機名配置為解析為多個IP地址，則NGINX使用循環算法在IP地址之間對流量進行負載平衡。在這種情況下，必須在配置參數中指定服務器的端口號，proxy_pass並且不能在IP地址或主機名之前指定協議：
stream { ... server { listen 12345; proxy_pass backend.example.com:12345; } }
被動健康監控
如果嘗試連接到上游服務器超時或導致錯誤，NGINX開源或NGINX Plus可以將服務器標記為不可用，並停止向其發送請求一段確定的時間。要定義NGINX認為上游服務器不可用的條件，請在指令中包含以下server參數
fail_timeout- 指定數量的連接嘗試必須失敗，服務器被認為不可用的時間量。此外，在標記它之后，NGINX認為服務器不可用的時間量。max_fails- 在指定時間內發生的NGINX認為服務器不可用的失敗嘗試次數。
默認值為10秒和1嘗試。因此，如果連接嘗試在10秒內超時或至少出現一次失敗，則NGINX將服務器標記為不可用10秒。該示例顯示如何在30秒內將這些參數設置為2個故障：
upstream stream_backend { server backend1.example.com:12345 weight=5; server backend2.example.com:12345 max_fails=2 fail_timeout=30s; server backend3.example.com:12346 max_conns=3; }
主動健康監控
可以配置運行狀況檢查以測試各種故障類型。例如，NGINX Plus可以連續測試上游服務器的響應能力，避免出現故障的服務器。
怎么運行的
NGINX Plus向每個上游服務器發送特殊的健康檢查請求，並檢查滿足特定條件的響應。如果無法建立與服務器的連接，則健康檢查將失敗，並認為服務器不正常。NGINX Plus不會將客戶端連接代理到不正常的服務器。如果為一組服務器定義了幾個運行狀況檢查，則任何一個檢查的失敗都足以使相應的服務器被視為不正常運行。
先決條件
- 您已在
stream上下文中配置了上游服務器組，例如：
stream { upstream stream_backend { server backend1.example.com:12345; server backend2.example.com:12345; server backend3.example.com:12345; } }
- 您已配置將流量（在這種情況下為TCP連接）傳遞到服務器組的服務器：
server { listen 12345; proxy_pass stream_backend; }
基本配置
- 指定共享內存區域 - 一個特殊區域，NGINX Plus工作進程共享關於計數器和連接的狀態信息。將
zone指令添加到上游服務器組，並指定區域名稱和內存量：
stream { upstream stream_backend { zone stream_backend 64k; server backend1.example.com:12345; server backend2.example.com:12345; server backend3.example.com:12345; } }
對上游組中的服務器啟用運行狀況檢查。將health_check和health_check_timeout指令添加到代理到上游組的連接的服務器：
server { listen 12345; proxy_pass stream_backend; health_check; health_check_timeout 5s; }
該health_check指令啟用運行狀況檢查功能，同時health_check_timeout覆蓋proxy_timeout運行狀況檢查的值，對於運行狀況檢查，此超時需要顯着縮短。
要對UDP流量啟用運行狀況檢查，在health_check指令中指定udp啟用UDP的運行狀況檢查的參數，以及包含用於驗證服務器響應的測試match=的相應match塊的名稱的參數（請參閱微調UDP運行狀況檢查）：
server { listen 5053; proxy_pass dns_servers; health_check udp match=dns; health_check_timeout 5s; }
微調健康檢查
默認情況下，NGINX Plus每5秒嘗試連接一個上游服務器組中的每個服務器。如果無法建立連接，NGINX Plus認為健康檢查失敗，將服務器標記為不正常，並停止將客戶端連接轉發到服務器。
要更改默認行為，請在參數中包含health_check參數：
interval- NGINX Plus發送健康檢查請求的頻率（以秒為單位）（默認為5秒）passes- 服務器必須響應以認為健康的連續運行狀況檢查的數量（默認值為1）fails- 服務器必須無法響應以認為不正常的連續運行狀況檢查數（默認值為1）-
server { listen 12345; proxy_pass stream_backend; health_check interval=10 passes=2 fails=3; }
在該示例中，TCP運行狀況檢查之間的時間增加到10秒，服務器在3連續失敗的運行狀況檢查后被認為不健康，並且服務器需要通過2連續檢查以再次被視為健康。
默認情況下，NGINX Plus會向塊中server指令指定的端口發送運行狀況檢查消息upstream。您可以指定另一個端口進行運行狀況檢查，這在監視同一主機上許多服務的運行狀況時尤其有用。要覆蓋端口，請指定port指令的health_check參數：
server { listen 12345; proxy_pass stream_backend; health_check port=8080; }
uptream name { server 192.168.0.21:80; server 192.168.0.22:80; check interval=3000 rise=2 fall=5 timeout=1000 type=http; } #上面配置的意思是，對name這個負載均衡條目中的所有節點，每個3秒檢測一資，請求2資下正常則標記realserver狀態為up,如果檢測5次都失敗，則標記realserver的狀態為down，超時間為1秒。