Ưu điểm:
Session replication là tăng khả năng failover của hệ thống , làm cho hệ thống của ta cĩ khả năng đáp ứng liên tục , đặc biệt là các ứng dụng địi hỏi độ tin cậy cao như ứng dụng thương mại (shopping cart..).
Khuyết điểm:
Session replication làm cho IO network tăng lên , do multicast các thơng điệp trao đổi session giữa các serrvers , làm tăng traffic lên , ảnh hưởng đến bandwidth của mạng. Do đĩ để làm giảm IO này ta phải giới hạn lại số lượng servers (nodes) trong một cluster . Bởi vì nhiều nodes trên một cluster sẽ làm cho nhiều data sẽ chạy trên đường mạng . Cĩ quá nhiều nodes trong một cluster và sử dụng session replication sẽ làm cho ứng dụng bị thắt cổ chay.
Clustering cĩ nghĩa là sẽ ít lỗi xảy ra hơn do quá tãi khả năng đáp ứng của phần cứng cũng như perfomance của mạng. Nhưng khi sử dụng session replication , như khi ta thêm một server thứ ba vào hệ thống cluster 2 servers thì khả năng mỗi server phải lưu trữ thêm session tăng lên (bằng lượng session phải lưu trên ba máy nếu khơng sử dụng session replication , tức lần gấp 3 lần , cho rằng các instance lưu trữ session như nhau). Điều này cịn tuỳ thuộc vào loại ứng dụng (do lập trình) của ta lưu trữ session nhiều hay ít. Do đo , khi lựa chọn clustering cho giải pháp session ta phải cân nhắc giữa lựa chọn session replication và session affinity .
3.5.2 Content-based load balancing kết hợp LVS với Reverse proxy A. Tại sao phải chia tải theo nội dung yêu cầu ( content-based)?
Trong các mơ hình cluster server tham khảo, nhận thấy rằng khi thực hiện cluster thì các server của chúng ta phải chạy cùng một dịch vụ và cung cấp cùng một nội dung giống nhau. Tức là khi đĩ nội dung cung cấp được lưu trữ ở cùng một hệ thống share file hoặc cơ sở dữ liệu dùng chung. Hệ thống load balancer sẽ hoạt động mà khơng cần biết đến nội dung cung cấp, yêu cầu của client sẽ được đáp ứng bởi bất kỳ server nào trong hệ thống cluster.
Một nhu cầu mới phát sinh khi mà ta muốn đa dạng hố các dịch vụ cung cấp, giả sử cũng cùng một hệ thống mà ta muốn vừa cung cấp dịch vụ hosting, vừa cung cấp dịch vụ e- comerce,… Và khi đĩ trong danh sách các server của chúng ta sẽ cĩ mức đầu tư khác nhau. E- comerce server do tính quan trọng của nĩ nên được đầu tư những máy tính đắt tiền cĩ khả năng xử lý cao. Hosting server cĩ thể nĩi là kém quan trọng hơn nên được đầu tư là những server “cheap” hơn. Hay khi hệ thống của ta gồm nhiều servers nhưng khả năng xử lý ( độ power) của nĩ khơng giống nhau, ta chỉ muốn các server “yếu hơn” sẽ xử lý các trang web tĩnh (html,…) cịn các servers “mạnh hơn” sẽ đảm nhiệm cơng việc xử lý các web động ( jsp/servlet,…) .Với hệ thống đa dạng như vậy nhưng ta vẫn muốn đạt được sự cân bằng tãi hệ thống. Để thực hiện được điều này thì load balancer ngồi việc nhận biết được sự chênh lệch về sức mạnh của các server (weight) mà cịn phải cĩ khả năng nhận biết được nội dung của yêu cầu cần xử lý nhiều hay ít để mà điều phối hợp lý.
B. Hướng giải quyết – cluster of cluster
Như các mơ hình đã tham khảo trên, ta thấy load balancer ở mức application cĩ khả năng điều phối các yêu cầu dựa vào nội dung (content-based) nhưng khơng nhanh và tốt như load balancing ở mức IP ( LVS). Do đĩ, để giải quyết được vấn đề nêu trên thì ta cần phải cĩ
một load balancer kết hợp. Ta xây dựng một load balancer ở nhiều cấp, level1 là LVS load balancer sẽ điều phối các requests đến load balancers ở level2 cĩ thể là các application load balancers (vì nĩ cĩ khả năng nhận biết được nội dung cần xử lý) , và mơ hình này tạm gọi tên là “cluster of cluster”.
“Cluster of Cluster” - thực hiện load balancing ở nhiều mức và trong kiến trúc này các webservers thực sự được chia ra theo từng nhĩm, mỗi nhĩm servers này sẽ cung cấp nội dung các dịch vụ khác nhau cĩ nhĩm servers phục hosting, nhĩm phục vụ thương mại, ...
Apache Load balancer sử dụng AJP13 Connector để truyền thơng với các servers , do đĩ gặp khĩ khăn khi kết hợp giữa LVS load balancer với Apache load balancer (mod_jk) vì LVS load balancer khơng hỗ trợ AJP13 Connector. Hướng giải quyết là ta tìm một load balancer mức application khác hỗ trợ cho việc kết hợp này.
Giới thiệu Revese Proxy: cĩ khi gọi là reverse proxy cache hay web server acceleration, là một phương pháp dùng để làm giảm lưu lượng tãi cho web server bằng cách sử dụng web cache giữa web server và internet. Một ưu điểm nữa là ta cĩ thể xây dựng được các chính sách bảo mật trên proxy. Đây cịn là một trong những cách mở rộng hệ thống servers mà khơng địi hỏi độ phức tạp cao. Người ta thường sử dụng reverse proxy để làm giảm gánh nặng cho web server cả về các trang tĩnh và trang động. Hoạt động của reverse proxy được mơ tả như hình sau:
Hình 3-41 Hoạt động Reverse proxy
Khi browser client tạo http request, sẽ được chuyển đến reverse proxy mà khơng chuyển trực tiếp đến web server. Reverse proxy sẽ kiểm tra nếu nội dung yêu cầu cĩ nằm trong cache khơng, nếu khơng cĩ sẽ connect trực tiếp đến web server để download nội dung này về cache của nĩ và đồng thời trả kết quả về cho client. Reverse proxy cache các nội dung tĩnh (như html, images). Các nội dung động như các cgi-script ngày nay cĩ thể được cache bằng các chính sách intelligent cache.
Dựa vào những điểm nổi bật của proxy, ta xây dựng mơ hình kết hợp “cluster of cluster” giữa LVS load balancer với các reverse proxy.
Hình 3-42 LVS Load balancer kết hợp với Reverse proxy
Lợi ích khi sử dụng reverse proxy:
Khi sử dụng reverse proxy như là một load balancer ở cấp thứ 2, ngồi lợi ích về chia tải theo nội dung yêu cầu ra ( load balancing) ta cịn cĩ các lợi ích khác như:
* Phục vụ được nhiều yêu cầu cho các trang tĩnh (static content) hơn nhờ vào tính năng cache của proxy.Phục vụ được nhiều yêu cầu cho các trang động (dynamic content) từ web servers kết hợp với các chính sách cache thơng minh.
* Bảo mật hơn nhờ vào tính năng security vốn cĩ của proxy. * Response time nhanh hơn đối với các request tĩnh.
* Tiết kiệm được băng thơng và các xử lý.
Tuy nhiên mơ hình này cĩ các khuyết điểm : Làm giảm thời gian response với các web động do phải xử lý ở hai mức load balancer.
Hoạt động:
Các yêu cầu từ client sẽ được chuyển đến LVS director (load balancer level1), tại đây các request sẽ được LVS director điều phối đến các proxy (load balancer level2) dưới dạng các http requests thơng thường (LVS xem proxy như các real servers) , reverse proxy nhận biết được http protocol và điều phối đến các web server theo nội dung yêu cầu (nếu nội dung đĩ cĩ trong cache của proxy nĩ sẽ trả về cho LVS director ngay lập tức).
Với mơ hình kết hợp này ta khơng cần bổ xung Connector hay protocol nào giữa LVS director và các reverse proxy, vì sau khi nhận được yêu cầu LVS director sẽ forward các yêu cầu dưới dạng http requests thơng thường. Như vậy reverse proxy cĩ thể được coi như là “trong suốt” đối với LVS director và các WebServer.