CFSDN nhấn mạnh vào giá trị tạo ra nguồn mở và chúng tôi cam kết xây dựng nền tảng chia sẻ tài nguyên để mọi nhân viên CNTT có thể tìm thấy thế giới tuyệt vời của bạn tại đây.

Bài viết trên blog CFSDN Keepaliving+Lvs+Nginx để xây dựng cụm Nginx có tính sẵn sàng cao này được tác giả sưu tầm và biên soạn. Nếu bạn quan tâm đến bài viết này thì nhớ like nhé.

nginx là một công cụ proxy ngược rất tuyệt vời hỗ trợ phân phối yêu cầu, cân bằng tải, bộ nhớ đệm và các chức năng rất thiết thực khác. Về xử lý yêu cầu, nginx sử dụng mô hình epoll, là mô hình dựa trên giám sát sự kiện nên có hiệu quả xử lý yêu cầu rất hiệu quả và khả năng xử lý đồng thời của một máy có thể lên tới hàng triệu. Các yêu cầu mà nginx nhận được có thể được phân phối đến các máy chủ ứng dụng cấp thấp hơn thông qua các chính sách cân bằng tải. Do đó, nếu hiệu suất không đủ, máy chủ ứng dụng có thể mở rộng lưu lượng bằng cách thêm máy. Tại thời điểm này, đối với một số trang web rất lớn, tắc nghẽn hiệu suất đến từ nginx, vì khả năng chạy đồng thời của một máy nginx có giới hạn trên và bản thân nginx không hỗ trợ chế độ cụm, do đó việc mở rộng theo chiều ngang của nginx tại thời điểm này là có vẻ đặc biệt quan trọng.

keepaliving là một công cụ phát hiện trạng thái máy chủ và chuyển đổi dự phòng. Trong tệp cấu hình của nó, bạn có thể định cấu hình máy chủ đang hoạt động và dự phòng cũng như yêu cầu phát hiện trạng thái của máy chủ. Điều đó có nghĩa là, keepaliving có thể liên tục gửi yêu cầu đến máy chủ được chỉ định theo yêu cầu đã định cấu hình trong thời gian dịch vụ. Nếu mã trạng thái được yêu cầu trả về là 200, điều đó có nghĩa là trạng thái máy chủ là bình thường. sau đó keepaliving sẽ gửi yêu cầu đến máy chủ được chỉ định. Máy chủ sẽ được chuyển sang chế độ ngoại tuyến và sau đó máy chủ dự phòng được đặt ở trạng thái trực tuyến.

lvs là một công cụ để cân bằng tải bốn lớp. Cái gọi là cân bằng tải bốn lớp tương ứng với giao thức mạng bảy lớp. Các giao thức phổ biến như HTTP dựa trên giao thức bảy lớp, trong khi lvs hoạt động trên giao thức bốn lớp, tức là: lớp vận chuyển, lớp mạng. và lớp liên kết dữ liệu và lớp vật lý. Các giao thức lớp vận chuyển chính ở đây là các giao thức TCP và UDP, có nghĩa là các phương thức chính được hỗ trợ bởi lvs là TCP và UDP. Chính vì lvs nằm ở lớp cân bằng tải thứ tư nên khả năng xử lý yêu cầu của nó cao hơn nhiều so với các máy chủ thông thường. Ví dụ: việc xử lý yêu cầu của nginx dựa trên lớp thứ bảy của mạng và khả năng cân bằng tải. của lvs là nginx hơn mười lần.

Qua phần giới thiệu ở trên, chúng ta có thể thấy rằng trong các trang web cực lớn, máy chủ ứng dụng có thể được mở rộng theo chiều ngang, nhưng nginx không hỗ trợ mở rộng theo chiều ngang. Lúc này, nginx sẽ trở thành nút thắt cổ chai về hiệu suất. Và lvs là một công cụ cân bằng tải nên nếu kết hợp lvs và nginx, chúng ta có thể triển khai nhiều máy chủ nginx và sử dụng khả năng cân bằng tải của lvs để phân bổ đều các yêu cầu đến từng máy chủ nginx, sau đó được máy chủ nginx phân phối đến từng ứng dụng server, bằng cách này, chúng tôi đã đạt được sự mở rộng theo chiều ngang của nginx. Vì nginx về cơ bản là một máy chủ ứng dụng nên nó cũng có thể ngừng hoạt động. Do đó, việc phát hiện lỗi nginx và chuyển đổi dịch vụ có thể đạt được bằng cách kết hợp giữ lại ở đây. Nói cách khác, thông qua keepaliving+lvs+nginx, chúng tôi nhận ra chế độ cụm có tính sẵn sàng cao của nginx.

Trong phần giới thiệu ở trên, chúng ta sẽ nhận thấy rằng mặc dù keepaliving+lvs+nginx thực hiện chế độ cụm của nginx, nhưng khi chúng ta sử dụng nginx, bản thân nó có IP và cổng nghe mặc định là 80 và 443. , vậy thì lvs phân phối như thế nào. yêu cầu tới các máy khách có địa chỉ IP và cổng khác nhau? Còn máy chủ nginx thì sao? Điều này được thực hiện thông qua ip ảo. Cái gọi là ip ảo là để cung cấp một ip công cộng cho thế giới bên ngoài yêu cầu ip này. chiến lược lập lịch và cân bằng tải, chọn máy chủ nginx mục tiêu, sau đó chuyển tiếp yêu cầu đến máy chủ đó. Có hai khái niệm trong LVS ở đây, đó là chiến lược lập lịch và cân bằng tải. Cái gọi là bộ lập lịch đề cập đến cách LVS sẽ xử lý dữ liệu yêu cầu và phản hồi. Có ba loại bộ lập lịch chính:

Máy chủ ảo thông qua dịch địa chỉ mạng (VS/NAT): Nguyên tắc chính của phương pháp này là sau khi người dùng gửi yêu cầu tới IP ảo, LVS sẽ chọn dịch vụ xử lý mục tiêu dựa trên thuật toán cân bằng tải, sau đó chuyển mục tiêu IP trong thông báo yêu cầu Địa chỉ được sửa đổi thành máy chủ mục tiêu được tính toán và gửi đến máy chủ đó. Đối với các gói phản hồi, bộ lập lịch sẽ sửa đổi địa chỉ nguồn trong dữ liệu phản hồi được máy chủ đích trả về địa chỉ IP ảo. Bằng cách này, máy khách dường như đang đối mặt với một máy chủ. Tuy nhiên, nhược điểm của phương pháp này là tất cả dữ liệu phản hồi cần phải đi qua bộ lập lịch. Nếu khối lượng yêu cầu tương đối lớn, bộ lập lịch sẽ trở thành nút thắt cổ chai của toàn bộ hệ thống.

Máy chủ ảo thông qua đường hầm IP (VS/TUN): Phương pháp này chủ yếu giải quyết vấn đề dữ liệu phản hồi truyền qua bộ lập lịch trong VS/NAT. Giống như VS/NAT, bộ lập lịch sẽ vẫn nhận dữ liệu được yêu cầu và thay đổi IP mục tiêu trong tin nhắn thành IP của dịch vụ đích. Tuy nhiên, sau khi dịch vụ đích xử lý dữ liệu, nó sẽ trực tiếp thay đổi IP nguồn trong tin nhắn phản hồi. . Sửa đổi nó thành IP ảo và sau đó gửi yêu cầu cho khách hàng. Bằng cách này, dữ liệu phản hồi được xử lý bởi từng dịch vụ đích mà không trả lại thông qua bộ lập lịch. Phương pháp này sẽ cải thiện đáng kể thông lượng của hệ thống và do thông báo yêu cầu chung nhỏ hơn nhiều so với thông báo phản hồi nên bộ lập lịch chỉ yêu cầu các thông báo. cần được xử lý và tải tổng thể của hệ thống sẽ được phân bổ đều cho từng máy chủ.

Máy chủ ảo thông qua định tuyến trực tiếp (VS/DR): Sự khác biệt chính giữa phương pháp này và VS/TUN là VS/NAT sửa đổi địa chỉ IP trong thông báo yêu cầu thành địa chỉ IP của dịch vụ đích, trong khi VS/DR là để trực tiếp sửa đổi địa chỉ MAC trong thông báo yêu cầu thành địa chỉ đích Phương pháp này sẽ hiệu quả hơn vì địa chỉ IP trong VS/TUN vẫn cần được chuyển đổi thành địa chỉ MAC để gửi dữ liệu.

1. Chuẩn bị môi trường.

Máy chủ ảo,

4 máy chủ ảo CentOs7: 172.16.28.130, 172.16.28.131, 172.16.28.132, 172.16.28.133.

Dịch vụ hệ thống: LVS, Keepaliving.

Máy chủ web: nginx.

Thiết lập cụm: chế độ LVSDR.

2. Cài đặt phần mềm.

Trên bốn máy ảo, chúng tôi thiết lập một cụm như sau:

172.16.28.130lvs+keepalived 。

172.16.28.131lvs+keepalived 。

172.16.28.132nginx 。

172.16.28.133nginx 。

Ở đây chúng tôi sử dụng hai máy 172.16.28.130 và 172.16.28.131 làm máy hoạt động của lvs+keepaliving, nghĩa là chức năng của hai máy này chủ yếu là cân bằng tải, phát hiện lỗi và ngoại tuyến; Hai máy đóng vai trò là máy chủ ứng dụng, chủ yếu cung cấp dịch vụ cho thế giới bên ngoài. Bốn máy chủ này đóng vai trò là toàn bộ dịch vụ cụm back-end và IP ảo được cung cấp bên ngoài là 172.16.28.120. Cần lưu ý rằng các dịch vụ được keepaliving phát hiện ở đây là hai máy chủ lvs, một là máy chủ chính và một là máy chủ dự phòng. Cấu hình cân bằng tải của cả hai là hoàn toàn giống nhau. Trong trường hợp thông thường, khi máy khách yêu cầu IP ảo, LVS sẽ chuyển tiếp yêu cầu đến máy chủ chính, sau đó máy chủ chính chọn máy chủ ứng dụng dựa trên chính sách cân bằng tải đã định cấu hình và gửi yêu cầu đến máy chủ ứng dụng để xử lý. Nếu tại một thời điểm nào đó, máy chủ chính của LVS ngừng hoạt động do lỗi, keepaliving sẽ phát hiện lỗi, đưa lỗi ngoại tuyến, sau đó đưa máy dự phòng trực tuyến để cung cấp dịch vụ, từ đó thực hiện chức năng chuyển đổi dự phòng.

2.1 lvs+keepalived được bảo vệ.

Cài đặt ipv và giữ nguyên trên 172.16.28.130 và 172.16.28.131:

#Cài đặt ipv.

sudoyuminstallipvsadm。

#Cài đặt được giữ nguyên.

sudoyuminstallkeepalived 。

Cài đặt nginx trên 172.16.28.132 và 172.16.28.133:

#Cài đặt nginx.

sudoyuminstallnginx .

Cần lưu ý rằng tường lửa cần phải được tắt trên hai máy chủ nginx, nếu không, hai máy lvs+keepaliving sẽ không thể gửi yêu cầu đến hai máy chủ nginx:

#Tắt tường lửa.

systemctldisablefirewalld.service 。

Kiểm tra xem 2 máy cân bằng tải có hỗ trợ lvs hay không:

sudolsmod|grepip_vs 。

#Nếu bạn thấy kết quả sau, điều đó có nghĩa là nó được hỗ trợ.

[zhangxufeng@localhost~]$sudolsmod|grepip_vs 。

ip_vs1454970 。

nf_conntrack1372391ip_vs 。

libcrc32c126443xfs,ip_vs,nf_conntrack .

Nếu lệnh trên không tạo ra bất kỳ kết quả nào, hãy thực thi lệnh sudo ipvsadm để khởi động ipvs, sau đó kiểm tra nó thông qua lệnh trên. Sau khi khởi động ipv, chúng ta có thể chỉnh sửa tệp keepaliving.conf trong thư mục /etc/keepaliving/. Chúng ta sử dụng máy 172.16.28.130 làm máy chủ. Cấu hình nút chính như sau:

#Cấu hình toàn cầu 。

định nghĩa toàn cục { 。

lvs_iddirector1#Chỉ định id của lvs.

} 。

#Cấu hìnhVRRP.

vrrp_instanceLVS{ 。

stateMASTER#Chỉ định nút hiện tại là nút chính.

giao diệnens33#ens33 ở đây là tên của card mạng, có thể xem được thông qua ifconfig hoặc ipaddr.

virtual_router_id51#Những gì được chỉ định ở đây là id tuyến đường ảo. Nút chính và nút dự phòng cần chỉ định cùng một nút.

mức độ ưu tiên151# chỉ định mức độ ưu tiên của nút hiện tại. Giá trị càng lớn thì mức độ ưu tiên của nút chính càng cao.

advert_int1#Chỉ định khoảng thời gian gửi quảng cáo VRRP, đơn vị là giây.

xác thực{ 。

auth_typePASS#Authentication, được chuyển theo mặc định.

auth_pass123456#Mật khẩu truy cập xác thực.

} 。

địa chỉ IP ảo { 。

172.16.28.120#Chỉ định IP ảo.

} 。

} 。

#VirtualServerConfiguration-chowwwserver 。

#Cấu hình của máy chủ thực nền.

máy chủ ảo172.16.28.12080{ 。

delay_loop1#Khoảng thời gian kiểm tra tình trạng.

lb_algorr#Chiến lược cân bằng tải, đây là bỏ phiếu.

lb_kindDR#Loại trình lập lịch, đây là DR.

Persence_time1# chỉ định khoảng thời gian để tiếp tục gửi yêu cầu đến cùng một máy chủ thực.

giao thứcTCP# chỉ định loại giao thức để truy cập máy chủ thực ở chế độ nền.

#RealServer1cấu hình 。

#Chỉ định IP và cổng của máy chủ thực 1.

máy chủ thực172.16.28.13280{ 。

Weight1# chỉ định trọng lượng của máy chủ hiện tại.

Kiểm tra TCP

Connection_timeout10#Chỉ định thời gian chờ để kiểm tra nhịp tim.

nb_get_retry3#Chỉ định số lần lặp lại sau khi hết thời gian chờ nhịp tim.

delay_Before_retry3#Chỉ định khoảng thời gian trì hoãn trước khi thử.

} 。

} 。

#RealServer2Configuration 。

máy chủ thực172.16.28.13380{ 。

Weight1# chỉ định trọng lượng của máy chủ hiện tại.

Kiểm tra TCP

Connection_timeout10#Chỉ định thời gian chờ để kiểm tra nhịp tim.

nb_get_retry3#Chỉ định số lần lặp lại sau khi hết thời gian chờ nhịp tim.

delay_Before_retry3#Chỉ định khoảng thời gian trì hoãn trước khi thử.

} 。

} 。

} 。

Trên đây là cấu hình được giữ nguyên trên nút chính. Đối với nút dự phòng, cấu hình của nó gần giống như của nút chính, ngoại trừ các tham số trạng thái và mức độ ưu tiên của nó là khác nhau. Sau đây là cấu hình đầy đủ của nút dự phòng:

#Cấu hình toàn cầu 。

định nghĩa toàn cục { 。

lvs_iddirector2#Chỉ định id của lvs.

} 。

#Cấu hìnhVRRP.

vrrp_instanceLVS{ 。

stateBACKUP#Chỉ định nút hiện tại làm nút chính.

giao diệnens33#ens33 ở đây là tên của card mạng, có thể xem được thông qua ifconfig hoặc ipaddr.

virtual_router_id51#Những gì được chỉ định ở đây là id tuyến đường ảo. Nút chính và nút dự phòng cần chỉ định cùng một nút.

mức độ ưu tiên150# chỉ định mức độ ưu tiên của nút hiện tại. Giá trị càng lớn thì mức độ ưu tiên của nút chính càng cao.

advert_int1#Chỉ định khoảng thời gian gửi quảng cáo VRRP, đơn vị là giây.

xác thực{ 。

auth_typePASS#Authentication, được chuyển theo mặc định.

auth_pass123456#Mật khẩu truy cập xác thực.

} 。

địa chỉ IP ảo { 。

172.16.28.120#Chỉ định IP ảo.

} 。

} 。

#VirtualServerConfiguration-chowwwserver 。

#Cấu hình của máy chủ thực nền.

máy chủ ảo172.16.28.12080{ 。

delay_loop1#Khoảng thời gian kiểm tra tình trạng.

lb_algorr#Chiến lược cân bằng tải, đây là bỏ phiếu.

lb_kindDR#Loại trình lập lịch, đây là DR.

Persence_time1# chỉ định khoảng thời gian để tiếp tục gửi yêu cầu đến cùng một máy chủ thực.

giao thứcTCP# chỉ định loại giao thức để truy cập máy chủ thực ở chế độ nền.

#RealServer1cấu hình 。

#Chỉ định IP và cổng của máy chủ thực 1.

máy chủ thực172.16.28.13280{ 。

Weight1# chỉ định trọng lượng của máy chủ hiện tại.

Kiểm tra TCP

Connection_timeout10#Chỉ định thời gian chờ để kiểm tra nhịp tim.

nb_get_retry3#Chỉ định số lần lặp lại sau khi hết thời gian chờ nhịp tim.

delay_Before_retry3#Chỉ định khoảng thời gian trì hoãn trước khi thử.

} 。

} 。

#RealServer2Configuration 。

máy chủ thực172.16.28.13380{ 。

Weight1# chỉ định trọng lượng của máy chủ hiện tại.

Kiểm tra TCP

Connection_timeout10#Chỉ định thời gian chờ để kiểm tra nhịp tim.

nb_get_retry3#Chỉ định số lần lặp lại sau khi hết thời gian chờ nhịp tim.

delay_Before_retry3#Chỉ định khoảng thời gian trì hoãn trước khi thử.

} 。

} 。

} 。

Lý do tại sao bản chính và bản sao lưu được cấu hình giống hệt nhau là khi bản chính ngừng hoạt động, dịch vụ có thể được chuyển đổi liền mạch dựa trên cấu hình bản sao lưu.

Sau khi hoàn tất cấu hình máy lvs+keepaliving, chúng tôi định cấu hình cấu hình nginx của hai máy chủ ứng dụng. Ở đây chúng tôi sử dụng nginx làm máy chủ ứng dụng, định cấu hình mã trạng thái trả về 200 trong tệp cấu hình của nó và trả về IP của máy chủ hiện tại. Sau đây là cấu hình của nó:

worker_processesauto,

#pid/chạy/nginx.pid,

sự kiện{ 。

công nhân_kết nối786,

} 。

http{ 。

máy chủ{ .

lắng nghe80,

#Ở đây, mã trạng thái 200 và một đoạn văn bản được trả về trực tiếp.

vị trí/{ .

mặc định_kiểu_văn_bản/html,

return200"Xin chào, Nginx!Serverzhangxufeng@172.16.28.132 ",

} 。

} 。

} 。

worker_processesauto,

#pid/chạy/nginx.pid,

sự kiện{ 。

công nhân_kết nối786,

} 。

http{ 。

máy chủ{ .

lắng nghe80,

#Ở đây, mã trạng thái 200 và một đoạn văn bản được trả về trực tiếp.

vị trí/{ .

mặc định_kiểu_văn_bản/html,

return200"Xin chào, Nginx!Serverzhangxufeng@172.16.28.133 ",

} 。

} 。

} 。

Có thể thấy IP máy chủ trong văn bản được hai máy trả về là khác nhau. Sau khi nginx được cấu hình, bạn có thể khởi động nó bằng lệnh sau:

sudonginx 。

Sau khi khởi động nginx, chúng ta cần định cấu hình IP ảo. Điều này là do bộ lập lịch lvs mà chúng ta sử dụng ở chế độ DR, như chúng tôi đã đề cập trước đó, ở chế độ này, phản hồi cho máy khách được máy chủ thực trả về trực tiếp cho máy khách. và máy chủ thực sự cần thay đổi IP nguồn trong thông báo phản hồi thành IP ảo. IP ảo được định cấu hình ở đây phục vụ mục đích này. Chúng ta chỉnh sửa file /etc/init.d/lvsrs và viết nội dung sau:

#!/bin/bash。

ifconfiglo:0172.16.28.120netmask255.255.255.255broadcast172.16.28.120up 。

routeadd-host172.16.28.120devlo:0 。

echo"0">/proc/sys/net/ipv4/ip_forward 。

echo"1">/proc/sys/net/ipv4/conf/lo/arp_ignore 。

echo"2">/proc/sys/net/ipv4/conf/lo/arp_announce 。

echo"1">/proc/sys/net/ipv4/conf/all/arp_ignore 。

echo"2">/proc/sys/net/ipv4/conf/all/arp_announce 。

thoát0.

lo: Cho biết tên card mạng thực của máy chủ hiện tại.

172.16.28.120: đại diện cho ip ảo,

Chỉ cần chạy tập lệnh sau khi viết nó. Sau đó bắt đầu dịch vụ được lưu giữ trên hai máy lvs+được lưu giữ:

sudoservicekeepalivestart。

Cuối cùng, bạn có thể xem chính sách lvs+keepaliving đã định cấu hình thông qua lệnh sau:

[zhangxufeng@localhostkeepalived]$sudoipvsadm-ln 。

IPVirtualServerversion1.2.1(kích thước=4096) 。

ProtLocalAddress:PortSchedulerFlags 。

->RemoteAddress:PortForwardWeightActiveConnInActConn 。

TCP172.16.28.120:80rr 。

->172.16.28.132:80Tuyến đường 100 。

2.2 Kiểm tra cụm.

Theo các bước trên, chúng tôi đã định cấu hình cụm lvs+keepaliving+nginx. Trong trình duyệt, chúng ta có thể truy cập http://172.16.28.120 và xem phản hồi sau:

Xin chào, Nginx!Serverzhangxufeng@172.16.28.132 。

Sau khi làm mới trình duyệt nhiều lần, bạn có thể thấy văn bản hiển thị trong trình duyệt chuyển đổi như sau. Điều này là do chính sách cân bằng tải của lvs:

Xin chào, Nginx!Serverzhangxufeng@172.16.28.133 。

3. Tóm tắt.

Bài viết này trước tiên giải thích nguyên tắc hoạt động của lvs và keepaliving, giới thiệu một số chế độ làm việc, sau đó giải thích chi tiết cách xây dựng cụm nginx với lvs+keepaliving+nginx và giải thích các vấn đề cần chú ý.

Cuối cùng, bài viết này về Keepaliving+Lvs+Nginx để xây dựng cụm khả dụng cao Nginx kết thúc tại đây. Nếu bạn muốn biết thêm về Keepaliving+Lvs+Nginx để xây dựng cụm khả dụng cao Nginx, vui lòng tìm kiếm các bài viết CFSDN hoặc tiếp tục duyệt. Bài viết liên quan, hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .