I. Giới thiệu cơ bản

1.1 LVS

LVS là viết tắt của Linux Virtual Server, có nghĩa là máy chủ ảo Linux. LVS bao gồm ipvsadm ở không gian người dùng và ipvs ở không gian kernel. ipvsadm được dùng để định nghĩa quy tắc, ipvs sử dụng các quy tắc được định nghĩa bởi ipvsadm để hoạt động.

1.2 Nginx

Nginx là một máy chủ web nhẹ/đảo ngược proxy và máy chủ proxy email (IMAP/POP3), được phát hành dưới giấy phép BSD-like.

1.3 HAProxy

HAProxy là một phần mềm miễn phí và mã nguồn mở được viết bằng ngôn ngữ C, cung cấp tính sẵn sàng cao, cân bằng tải và proxy ứng dụng dựa trên TCP và HTTP.

II. Giải thích nguyên lý hoạt động

2.1 LVS

2.1.1 Đặc điểm của LVS

LVS sử dụng công nghệ cân bằng tải và hệ điều hành Linux để xây dựng một cụm máy chủ có hiệu năng cao và sẵn sàng cao. Nó có độ tin cậy, khả năng mở rộng và khả năng vận hành tốt. Từ đó đạt được hiệu suất dịch vụ tối ưu với chi phí thấp. Các đặc điểm chính của LVS bao gồm:

Ưu điểm:

• Các kết nối đồng thời cao: LVS hoạt động ở tầng mạng kernel, có khả năng chịu tải và xử lý đồng thời vượt trội. Một máy chủ cân bằng tải LVS duy nhất có thể hỗ trợ hàng chục nghìn kết nối đồng thời. Độ ổn định cao: Hoạt động ở tầng 4 trở lên chỉ để phân phối, đặc điểm này quyết định nó có hiệu suất tốt nhất, ổn định nhất trong các phần mềm cân bằng tải, tiêu thụ tài nguyên CPU và bộ nhớ cực thấp.
• Chi phí thấp: Các thiết bị cân bằng tải phần cứng ít nhất vài chục nghìn, nhiều thì hàng trăm triệu. LVS chỉ cần một máy chủ để triển khai miễn phí, có tỷ lệ hiệu suất trên chi phí rất cao.
• Cấu hình đơn giản: Cấu hình LVS rất đơn giản, chỉ cần vài dòng lệnh để hoàn thành cấu hình, có thể viết thành script để quản lý.
• Hỗ trợ nhiều thuật toán: Hỗ trợ nhiều thuật toán xoay vòng, có thể linh hoạt điều chỉnh theo kịch bản kinh doanh, hỗ trợ nhiều mô hình làm việc: Có thể sử dụng các mô hình khác nhau để giải quyết vấn đề xử lý yêu cầu trong môi trường sản xuất.
• Phạm vi ứng dụng rộng: Vì LVS hoạt động ở tầng 4, nên nó có thể cân bằng tải cho hầu hết các ứng dụng, bao gồm http, cơ sở dữ liệu, DNS, ftp, v.v.

Nhược điểm: Hoạt động ở tầng 4, không hỗ trợ sửa đổi quy tắc tầng 7, cơ chế quá cồng kềnh, không phù hợp với ứng dụng quy mô nhỏ.

2.1.2 Các thuật ngữ phổ biến của LVS

2.1.3 Các mô hình làm việc phổ biến của LVS

LVS thường sử dụng các mô hình làm việc sau: DR (Direct Routing), TUN và NAT.

2.1.4 Nguyên lý hoạt động

LVS hoạt động theo nguyên lý:

• Khi yêu cầu của client đến không gian kernel của máy chủ cân bằng tải, nó sẽ đến chuỗi PREROUTING đầu tiên.
• Khi kernel phát hiện địa chỉ đích của gói dữ liệu yêu cầu là máy chủ này, nó sẽ gửi gói dữ liệu đến chuỗi INPUT.
• LVS bao gồm ipvsadm ở không gian người dùng và IPVS ở không gian kernel. ipvsadm dùng để định nghĩa quy tắc, IPVS sử dụng các quy tắc được định nghĩa bởi ipvsadm để hoạt động. IPVS hoạt động trên chuỗi INPUT, khi gói dữ liệu đến chuỗi INPUT, nó sẽ được IPVS kiểm tra đầu tiên. Nếu địa chỉ đích và cổng trong gói dữ liệu không có trong quy tắc, gói dữ liệu này sẽ được gửi đến không gian người dùng qua chuỗi INPUT để xử lý bởi tiến trình không gian người dùng.
• Nếu địa chỉ đích và cổng trong gói dữ liệu có trong quy tắc, gói dữ liệu này sẽ được sửa đổi địa chỉ đích thành máy chủ phía sau đã được định nghĩa trước và gửi đến chuỗi POSTROUTING.
• Cuối cùng, nó được gửi đến máy chủ phía sau qua chuỗi POSTROUTING.

2.2 Nginx

2.2.1 Đặc điểm của Nginx

Ưu điểm:

• Hoạt động ở tầng 7 trở lên, có thể thực hiện các chiến lược phân luồng cho ứng dụng http, chẳng hạn như theo tên miền, cấu trúc thư mục. Quy tắc regex của nó mạnh mẽ và linh hoạt hơn HAProxy, đây cũng là một trong những lý do chính cho sự phổ biến của nó hiện nay. Nginx chỉ với đặc điểm này đã có thể sử dụng trong nhiều trường hợp hơn LVS. location sử dụng linh hoạt, phạm vi ứng dụng rộng, hoạt động ở tầng ứng dụng.
• Nginx phụ thuộc ít vào sự ổn định của mạng, về lý thuyết, chỉ cần ping được là có thể thực hiện cân bằng tải. Đây cũng là ưu điểm của nó. Ngược lại, LVS phụ thuộc nhiều vào mạng.
• Nginx cài đặt và cấu hình đơn giản, dễ dàng kiểm tra, nó cơ bản có thể in ra lỗi bằng log. Cấu hình và kiểm tra LVS sẽ mất nhiều thời gian hơn. LVS phụ thuộc nhiều vào mạng.
• Nginx có thể phát hiện lỗi của máy chủ nội bộ thông qua cổng, chẳng hạn như theo trạng thái mã trả về của trang web, thời gian chờ, v.v., và sẽ gửi lại yêu cầu bị lỗi đến một nút khác. Tuy nhiên, nhược điểm là nó không hỗ trợ kiểm tra bằng url. Ví dụ, nếu người dùng đang tải lên một tệp và nút xử lý tải lên gặp sự cố trong quá trình tải lên, Nginx sẽ chuyển tải lên sang một máy chủ khác để xử lý lại, trong khi LVS sẽ ngắt kết nối trực tiếp. Nếu là tải lên một tệp lớn hoặc tệp quan trọng, người dùng có thể không hài lòng vì điều này.
• Nginx không chỉ là một phần mềm cân bằng tải/reverse proxy xuất sắc, mà còn là máy chủ ứng dụng web mạnh mẽ. Kiến trúc LNMP cũng rất phổ biến trong những năm gần đây, ổn định tốt trong môi trường lưu lượng cao.
• Nginx hiện đang trở nên ngày càng trưởng thành như một bộ đệm tăng tốc đảo ngược web, tốc độ nhanh hơn máy chủ Squid truyền thống, có thể xem xét sử dụng nó làm bộ tăng tốc đảo ngược.
• Nginx có thể được sử dụng làm proxy đảo ngược ở tầng trung gian, ở tầng này, Nginx cơ bản không có đối thủ, chỉ có lighttpd có thể so sánh với Nginx, nhưng lighttpd hiện chưa đạt được đầy đủ chức năng của Nginx, cấu hình cũng không rõ ràng và dễ đọc, tài liệu cộng đồng cũng không hoạt động bằng Nginx.
• Nginx cũng có thể được sử dụng làm máy chủ web tĩnh và máy chủ hình ảnh, hiệu suất ở lĩnh vực này cũng không có đối thủ. Ngoài ra, cộng đồng Nginx rất sôi động, có nhiều module của bên thứ ba.

Nhược điểm:

• Nginx chỉ hỗ trợ các giao thức http, https và Email, do đó phạm vi ứng dụng bị hạn chế, đây là nhược điểm của nó.
• Đối với kiểm tra sức khỏe của máy chủ phía sau, chỉ hỗ trợ kiểm tra qua cổng, không hỗ trợ kiểm tra bằng url. Không hỗ trợ giữ session trực tiếp, nhưng có thể giải quyết bằng ip_hash.

2.2.2 Nguyên lý hoạt động của Nginx

Nginx bao gồm kernel và module. Công việc thực tế mà Nginx làm rất ít. Khi nó nhận được một yêu cầu HTTP, nó chỉ tìm kiếm tệp cấu hình để ánh xạ yêu cầu này đến một khối location, và các chỉ thị được cấu hình trong location này sẽ khởi động các module khác nhau để hoàn thành công việc. Do đó, module có thể được coi là người lao động thực sự của Nginx. Thông thường, các chỉ thị trong một location sẽ liên quan đến một module handler và nhiều module filter (tất nhiên, nhiều location có thể sử dụng lại cùng một module). Module handler chịu trách nhiệm xử lý yêu cầu, tạo nội dung phản hồi, trong khi module filter xử lý nội dung phản hồi. Các module do người dùng phát triển theo nhu cầu của mình đều thuộc về module của bên thứ ba. Chính nhờ sự hỗ trợ của nhiều module như vậy, Nginx mới có chức năng mạnh mẽ như vậy. Quy trình xử lý cụ thể của Nginx:

1. Client gửi yêu cầu HTTP
2. Nginx chọn một module xử lý phù hợp dựa trên vị trí trong tệp cấu hình
3. Module cân bằng tải chọn một máy chủ phía sau (nếu có)
4. Module xử lý xử lý và đặt bộ đệm đầu ra vào module filter đầu tiên
5. Module filter đầu tiên xử lý và xuất ra module filter thứ hai
6. Sau đó module filter thứ hai đến module thứ ba
7. Tiếp tục như vậy, cuối cùng gửi phản hồi về client.

2.2.3 Chiến lược cân bằng tải của Nginx

Nginx hiện hỗ trợ 3 chiến lược cân bằng tải:

• Round Robin (rr): Phân phối theo thứ tự vòng lặp (mặc định), mỗi yêu cầu được phân phối lần lượt đến các máy chủ phía sau khác nhau theo thứ tự thời gian. Nếu máy chủ phía sau down, có thể tự động loại bỏ. Mặc dù phương pháp này đơn giản và chi phí thấp, nhưng nhược điểm là độ tin cậy thấp và phân phối tải không cân bằng.
• Weight: Chỉ định xác suất vòng lặp, weight tỷ lệ thuận với tỷ lệ truy cập, sử dụng cho trường hợp máy chủ phía sau có hiệu năng không đồng đều.

upstream tech_cluster {
     server 192.168.1.10:80 weight=8;
     server 192.168.1.11:80 weight=2;
}

• ip_hash: Hai phương pháp trên đều có một vấn đề, đó là yêu cầu tiếp theo có thể được phân phối đến một máy chủ khác. Khi chương trình của chúng ta không không trạng thái (sử dụng session để lưu trữ dữ liệu), sẽ có một vấn đề lớn. Ví dụ, nếu thông tin đăng nhập được lưu trong session, thì khi chuyển sang một máy chủ khác, cần đăng nhập lại. Do đó, trong nhiều trường hợp, chúng ta cần một client chỉ truy cập một máy chủ, lúc này cần sử dụng ip_hash. Mỗi yêu cầu được phân phối theo kết quả hash của địa chỉ ip truy cập, do đó mỗi khách truy cập cố định truy cập một máy chủ phía sau, có thể giải quyết vấn đề session.

# ip_hash: Yêu cầu từ cùng một IP sẽ được phân phối đến cùng một máy chủ phía sau
upstream tech_cluster {
     ip_hash;
     server 192.168.1.10:80;
     server 192.168.1.11:80;
}

• Fair: Đây là chiến lược của bên thứ ba, phân phối yêu cầu theo thời gian phản hồi của máy chủ phía sau, máy chủ có thời gian phản hồi ngắn sẽ được ưu tiên.

upstream backend {
	 fair;
     server 192.168.1.10:80;
     server 192.168.1.11:80;
}

• url_hash: Phân phối yêu cầu theo kết quả hash của url truy cập, làm cho mỗi url được định hướng đến cùng một máy chủ phía sau, hiệu quả khi máy chủ phía sau là bộ đệm.

upstream backend {
     hash $request_uri; 
     hash_method crc32; 
     server 192.168.1.10:80;
     server 192.168.1.11:80;
}

2.3 HAProxy

2.3.1 Đặc điểm của HAProxy

Ưu điểm:

• Hỗ trợ hai chế độ proxy: TCP (tầng 4) và HTTP (tầng 7), hỗ trợ máy chủ ảo;
• Hỗ trợ giữ session, dẫn đường cookie; đồng thời hỗ trợ lấy url cụ thể để kiểm tra trạng thái máy chủ phía sau. Có thể bù đắp một số nhược điểm của Nginx.
• HAProxy tương tự như LVS, bản thân nó chỉ là một phần mềm cân bằng tải; về mặt hiệu suất, HAProxy có tốc độ cân bằng tải tốt hơn Nginx, cũng vượt trội hơn Nginx trong xử lý đồng thời.
• HAProxy có thể cân bằng tải cho Mysql, kiểm tra và cân bằng tải cho các nút DB phía sau.
• HAProxy có nhiều chiến lược cân bằng tải, chẳng hạn như: Dynamic Round Robin, Weighted Source Hash, Weighted URL Hash và Weighted Parameter Hash
• Miễn phí và mã nguồn mở, độ ổn định cũng rất tốt, có thể so sánh với LVS;
• Có trang giám sát trạng thái máy chủ mạnh mẽ, trong môi trường thực tế, chúng ta kết hợp với Nagios để gửi cảnh báo qua email hoặc SMS;

2.3.2 Nguyên lý

HAProxy triển khai mô hình một tiến trình, dựa trên sự kiện, mô hình này hỗ trợ số lượng kết nối đồng thời rất lớn. Mô hình nhiều tiến trình hoặc nhiều luồng bị giới hạn bởi bộ nhớ, bộ lập lịch hệ thống và các khóa everywhere, hiếm khi có thể xử lý hàng nghìn kết nối đồng thời. Mô hình dựa trên sự kiện vì tất cả các tác vụ này được thực hiện trong không gian người dùng (User-Space) với quản lý tài nguyên và thời gian tốt hơn, nên không có vấn đề này. Nhược điểm của mô hình này là, trên hệ thống nhiều nhân, các chương trình này thường có khả năng mở rộng kém. Đó là lý do tại sao chúng phải được tối ưu hóa để làm nhiều việc hơn trong mỗi chu kỳ CPU.

2.3.3 Thuật toán cân bằng tải của HAProxy

• roundrobin: Xoay vòng đơn giản
• static-rr: Xoay vòng có trọng số
• leastconn: Ưu tiên máy chủ có ít kết nối nhất
• source: Theo địa chỉ IP nguồn của yêu cầu, tương tự như cơ chế ip_hash của Nginx
• ri: Theo URI của yêu cầu
• rl_param: Theo tham số URI của yêu cầu
• hdr(name): Khóa mỗi yêu cầu HTTP theo tiêu đề HTTP
• rdp-cookie(name): Khóa và hash mỗi yêu cầu TCP theo cookie