Đồ án Cân bằng tải cho các hệ webserver lớn và đảm bảo scalability

thường được chọn để dùng trong các bộ cân bằng tải Cân bằng tải cho server toàn cầu (GSLB) Có 2 nhân tố chính thể hiện sự cần thiết của GSLB, đó là khả năng có sẵn cao và thời gian đáp ứng. Để đảm bảo tính có sẵn của cụm server, chúng ta sử dụng 1 bộ cân bằng tải để thực hiện kiểm tra “health checks” đối với các server. Để đảm bảo bộ cân bằng tải không bị quá tải, chúng ta có thể cài đặt nhiều bộ cân bằng tải hoạt động theo chế độ active-active hoặc active-backup. Nhưng chuyện gì sẽ xảy ra nếu như toàn bộ trung tâm dữ liệu chứa các server và các bộ cân bằng tải không thể hoạt động vì mất điện, động đất, hoặc lũ lụt? Tất nhiên người dùng sẽ không thể truy cập vào websiste. Để tránh trường hợp này xảy ra, chúng ta có thể cài đặt website ở nhiều trung tâm dữ liệu khác nhau và sử dụng GSLB để đồng bộ giữa các trung tâm này. Phương án này đảm bảo rằng, nếu như có một trung tâm nào đó bị hỏng, thì vẫn còn các trung tâm khác hoạt động. Trong mạng internet, có những yếu tố bất lợi mà chúng ta không thể giải quyết một cách triệt để, một trong những yếu tố đó là “thời gian trễ của đường truyền internet” (internet delay), đây cũng chính là yếu tố quyết định đến thời gian đáp ứng của website đối với người dùng. Thời gian đáp ứng người dùng phụ thuộc vào thời gian trễ của người dùng (client-side delay), thời gian trễ của server (server-side delay), và thời gian trễ của đường truyền internet. Các phương án giảm thiểu tối đa thời gian trễ của server đã được bàn ở phần cân bằng tải cho server. Do chúng ta không thể kiểm soát được thời gian trễ của người dùng, nên phần này sẽ đi sâu vào các phương pháp cài đặt hệ thống server để hạn chế được thời gian trễ của đường truyền mạng. Domain Name System GSLB có thể đạt được bằng nhiều cách khác nhau, nhưng cách được dùng nhiều nhất là sử dụng Domain Name System (DNS). Khi người dùng truy cập vào website www.facebook.com, thì “facebook.com” chính là tên miền (domain), có nhiều loại tên miền khác nhau, chỉ định bằng đuôi của chúng. Chẳng hạn như tên miền .com là commercial (các trang web thương mại), tên miền .org thay cho organization (tổ chức), hoặc tên miền .edu thay cho education (giáo dục). Trong mỗi tên miền lại có những tên miền con, chẳng hạn như “pics.facebook.com” hay “video.facebook.com”, chúng còn được gọi là các vùng (zones) của tên miền chính. Một name server lưu trữ thông tin về các tên miền, và có trách nhiệm trả về tất cả các chất vấn về không gian tên của các tên miền này. Một tên miền có thể được lưu trữ ở nhiều DNS khác nhau, nhưng sẽ có một DNS có thẩm quyền cao nhất (authoritative DNS), DNS này có trách nhiệm cập nhập tất cả các thay đổi cho các DNS có thẩm quyền thấp hơn. Server tên miền cục bộ (local DNS) là name server được lưu trữ ở trong mạng LAN của người dùng. Khi người dùng truy cập một tên miền như www.facebook.com, local DNS sẽ chuyển tên miền này thành 1 địa chỉ IP, như mô tả trong hình 2.1-6. Vậy thì nó sẽ thực hiện điều này như thế nào? Đầu tiên nó sẽ đi đến “Root name server” (2), dữ liệu trả về sẽ là danh sách các tên miền có đuôi là .com (3). Sau đó, Local DNS sẽ chuyển đến yêu cầu đến “.com name server” (4), và name server này sẽ trả về IP của authoritative DNS của website facebook.com (5). Local DNS gửi yêu cầu đến địa chỉ IP này (6), và nhận dữ liệu trả về là IP của một trong các web-server của trang facebook.com (7). IP này được trả về cho trình duyệt và được dùng để truy xuất dữ liệu (8,9). H 2.1-6 Mô hình Global Server Load Balancing Trong bước (7), đôi khi dữ liệu trả về sẽ là một danh sách các địa chỉ IP của website cần truy cập, hoặc có khi DNS sẽ dùng round-robin để trả về danh sách này theo thứ tự quay vòng, như vậy mỗi lần sẽ trả về một địa chỉ IP khác nhau. Nếu local DNS nhận được một list các IP trả về, nó sẽ chuyển về trình duyệt các IP này theo thuật toán Round-Robin. Khi Local DNS nhận dữ liệu trả về, nó sẽ lưu trữ thông tin của các dữ liệu này trong một khoảng thời gian (gọi là Time-To-Live –TTL). Trong khoảng thời gian này, bất cứ yêu cầu nào với tên miền là con của tên miền gốc sẽ được trả về địa chỉ IP giống như yêu cầu gốc. Nếu hết thời gian TTL mà vẫn không có yêu cầu, dữ liệu này sẽ tự động bị xóa đi. Giá trị TTL giảm sẽ khiến local DNS truy cập vào authoritative DNS nhiều hơn, tăng giá trị TTL sẽ khiến local DNS có nguy cơ thừa quá nhiều dữ liệu không dùng đến. Vì vậy chọn giá trị TTL phải tùy thuộc vào từng website và thời điểm cụ thể. Để thực hiện GSLB dựa trên DNS, chúng ta cần phải đặt bộ cân bằng tải của website vào trong một node nào đó của hệ thống DNS, từ đó chọn địa chỉ IP của web-server phù hợp nhất để phục vụ cho từng nhóm người dùng cụ thể. Như vậy, ở đây cần phải giải quyết 2 vấn đề. Thứ nhất là làm sao để đặt bộ cân bằng tải vào trong hệ thống DNS, thứ hai là làm sao để chọn được site phù hợp nhất. Cài đặt bộ cân bằng tải vào hệ thống mạng DNS Có hai cách để cài đặt bộ cân bằng tải, đó là sử dụng bộ cân bằng tải để thay thế authoritative DNS và cài đặt bộ cân bằng tải như một forward DNS Proxy. + Bộ cân bằng tải thay thế authoritative DNS Như đã đề cập ở trên, authoritative DNS là DNS có quyền trả về địa chỉ IP hoặc một danh sách các địa chỉ IP của một cluster. Như vậy, nếu như thay vị trí của nó bằng bộ cân bằng tải, toàn bộ các yêu cầu dữ liệu DNS sẽ được chuyển vào bộ cân bằng tải, do bộ cân bằng tải có nhiều thuật toán phân tải và thuật toán lựa chọn tối ưu nên sẽ có khả năng trả về dữ liệu một cách tốt hơn. Hình 2.1-7 là một ví dụ minh họa cho phương pháp thay thế authoritative DNS bằng bộ cân bằng tải. Local DNS lúc này sẽ làm việc với bộ cân bằng tải có chức năng cân bằng tải cho server toàn cầu và nhận địa chỉ IP của web-server từ đây H 2.1-7 Bộ cân bằng tải hoạt động như một authoritative DNS Trong phương pháp này, bộ cân bằng tải sẽ thay thế cho authoritative DNS, do đó việc chọn IP trả về cho local DNS sẽ phụ thuộc vào chức năng DNS được cài đặt trong bộ cân bằng tải. Trên thực tế, một số sản phẩm của các công ty hàng đầu về cân bằng tải như F5 Networks, Foundry, Nortel, Cissco cung cấp rất nhiều chức năng DNS đa dạng. Nếu như một sản phẩm không thể điều khiển được một yêu cầu DNS nào đó, nó có thể loại bỏ chúng, trả về một lỗi hoặc chuyển chúng đến DNS server thực sự +Cài đặt bộ cân bằng tải như một forward DNS proxy Phương pháp này được mô tả trong hình 2.1-8. Lúc này bộ cân bằng tải trở thành một forward-proxy, nó đứng ở vị trí của một authoritative DNS, nhận yêu cầu từ phía local DNS, sau đó nó sẽ chuyển yêu cầu đến authoritative DNS thực sự được cài đặt ở phía sau nó. Khi nhận dữ liệu trả về từ authoritative DNS thực sự, bộ cân bằng tải sẽ chỉnh sửa cho phù hợp và trả về cho Local DNS, sự trả về này phải được thực hiện một cách “trong suốt” và chỉ những dữ liệu có liên quan đến GSLB mới cần phải thay đổi. Ở đây nếu như có nhiều DNS server thực sự, bộ cân bằng tải sẽ làm nhiệm vụ cân bằng tải cho nhóm DNS server này. H2.1-8 Bộ cân bằng tải hoạt động như một forward DNS proxy Ưu điểm của phương pháp cài đặt bộ cân bằng tải như một forward proxy là chúng ta có thể cài đặt nhiều DNS server và cân bằng tải cho chúng, do đó tăng khả năng mở rộng và khả năng có sẵn. Hơn nữa, IP của các DNS server thực sự có thể được giữ kín, và do đó có thể ngăn chặn việc truy cập trái phép và tăng tính bảo mật. Bộ cân bằng tải không cần phải cài đặt đầy đủ các chức năng GSLB mà chỉ cần các chức năng cần thiết để giúp DNS trả về địa chỉ IP cho local DNS một cách thông minh hơn. Hơn nữa, chúng ta có thể kết hợp cả GSLB và SLB vào trong một mô hình, như trong hình vẽ 2.1-9. Bộ cân bằng tải ở đây có 2 địa chỉ IP ảo: VIPD dùng để đóng vai trò một authoritative DNS; VIP1 dùng để cân bằng tải cho cụm server. H 2.1-9 Sự kết hợp GSLB và SLB trong bộ cân bằng tải Lựa chọn site tốt nhất Không kém phần quan trọng so với việc cài đặt bộ cân bằng tải vào hệ thống DNS, việc lựa chọn trang tốt nhất, hay đúng hơn là chọn cụm web-server nào tốt nhất và trả về địa chỉ IP của cụm đó cho người dùng. Cụm server tốt nhất ở đây bao hàm cả trạng thái server và vị trí của nó đối với người dùng. Các công việc phải thực hiện để kiểm tra trạng thái của server bao gồm kiểm tra “server health” (Site health conditions), thời gian đáp ứng (Site Response Time) và tải hiện tại của server (Site Load Conditions). Ở đây site chỉ cho một cụm máy chủ ở một vùng nào đó, có thể hiểu là một cluster. Kiểm tra trạng thái “health” là một nhân tố quan trọng của GSLB, nhằm nhận biết các site đang hoạt động và các site không hoạt động, từ đó chuyển hướng người dùng đến site phù hợp. Tuy vậy, việc này là khá dễ đối với bộ cân bằng tải vì nó có thể sử dụng cùng một phương pháp như phương pháp “health checks” đối với các server trong cùng một cluster. Có nhiều kiểu “health checks” khác nhau, từ tầng 2/3 đến tầng 4 của mô hình OSI, hay thậm chí ở tầng 7. Bộ bộ cân bằng tải toàn cầu sẽ gửi một yêu cầu HTTP đối với mỗi URL từ phía người dùng và kiểm tra một mã trả về, sau đó kiểm tra ngữ cảnh trên các từ khóa hoặc tính toán một mã kiểm tra (checksum) trên trang trả về để khớp với giá trị mà người dùng đã chỉ định. Nhân tố thứ 2 quyết định việc chọn site trong GSLB là thời gian đáp ứng của site đó (thời gian đáp ứng của web-server). Bộ cân bằng tải kiểm tra thời gian đáp ứng bằng cách đo thời gian trễ giữa quá trình gửi yêu cầu và nhận hồi đáp trong một giao tác. Như vậy, có thể kết hợp cả health check và kiểm tra thời gian đáp ứng bằng cách đo thời gian trễ của quá trình health check. Cần phải chú ý rằng thời gian đáp ứng của site là khác so với thời gian đáp ứng người dùng. Ở đây sẽ không có thời gian trễ của người dùng và thời gian trễ của internet, nó chỉ đơn giản là thời gian đáp ứng của cluster. Khi bộ cân bằng tải gửi một tín hiệu “health check”, tín hiệu này sẽ chuyển được đến một server nào đó trong cluster. Khi nó gửi thêm một tín hiêu khác, có thể sẽ được chuyển đến một server khác trong cluseter này. Thời gian đáp ứng đo được ở các giao tác này là khác nhau, vì vậy để đánh giá một cách chính xác thời gian đáp ứng của cluster, cần phải lấy thời gian trung bình trong các lần đo này. Nhân tố thứ 3 quyết định việc chọn site chính là trạng thái tải của site. Trong phần này, chúng ta cần biết đến không chỉ tải hiện tại của server mà còn phải quan tâm đến khả năng của server này, 2 nhân tố này làm nên tính sẵn có của site. Một bộ cân bằng tải hoạt động tốt nghĩa là nó nên chọn được site có tính sẵn có cao nhất. Một trong các thông số để đo trạng thái tải của server chính là số kết nối hiện tại đến server đó. Thêm nữa, một số ý kiến cho rằng, thời gian đáp ứng của server chính là nhân tố cho thấy tải hiện thời của server, một server nhẹ tải sẽ đáp ứng nhanh hơn một server nặng tải hơn. Song song với việc chọn site theo thông số của server là chọn site theo vị trí địa lý của site này. Nghĩa là, bộ cân bằng tải toàn cầu sẽ nhận biết IP của người dùng, sau đó xác định vùng mà người đó truy cập vào website. Việc xác định này sẽ dựa trên block của địa chỉ IP, được cấp phát bởi các công ty quản lý địa chỉ IP, chẳng hạn như Asia Pacific Network Information Center (APNIC) sẽ quản lý cấp phát địa chỉ IP ở Châu Á Thái Bình Dương. Sau khi xác định vùng truy cập, GSLB sẽ hướng người dùng đến server gần nhất. Điều này sẽ giúp giảm thiểu tối đa thời gian trễ của internet, vì hướng người dùng đến site gần họ nhất, nên hầu hết sẽ không phải tốn băng thông đi quốc tế. Cần phải nhắc lại rằng, DNS được tạo ra không phải để dành riêng cho GSLB. GSLB sử dụng DNS để phục vụ cho mục đích của mình và kết quả mang lại là rất tốt như chúng ta đã thảo luận ở trên. Tuy vậy vẫn có những hạn chế mà GSLB dựa trên DNS không giải quyết được, chẳng hạn như khi người dùng quá xa local DNS của họ, hoặc có một số local DNS bỏ qua giá trị TTL được chỉ định bởi authoritative DNS Chuyển mạch cache trong suốt Bộ nhớ cache đóng vai trò cực kỳ quan trọng trong việc tăng tốc độ hoạt động của hệ thống. Một hệ thống caching hiệu quả sẽ tăng tốc độ đáp ứng cho người dùng cao và tiết kiệm được băng thông của hệ thống. Để bộ cân bằng tải hoạt động hiệu quả thì thiết kế cache là một phần không thể thiếu. Ngoài yêu cầu về tính hiệu quả, thiết kế cache trong bộ cân bằng tải còn phải trong suốt đối với người dùng, vì vậy nó luôn đòi hỏi sự đầu tư về thời gian cũng như công sức cao. Trong khuôn khổ đồ án này, NVLV chỉ xin đưa ra những nghiên cứu mang tính lý thuyết về các phương pháp cài đặt cache và một số thuật toán cụ thể. Về cài đặt chi tiết ứng dụng và tích hợp vào trong một sản phẩm cân bằng tải xin dành cho một báo cáo sau, khi có đủ thời gian và nguồn lưc cần thiết. Sau đây xin giới thiệu các phương pháp cài đặt cache Các phương pháp cài đặt cache Như đã trình bày ở chương 1, có 4 phương án triển khai cache, đó là cài đặt cache như một forward proxy, transparent proxy, reverse proxy hoặc transparent-reverse proxy. Forward proxy và transparent proxy được dùng để tăng tốc bên phía người dùng (thường được cài đặt bên phía trình duyệt người dùng), trong khi đó reverse proxy và transparent-reverse proxy được dùng để tăng tốc server, và được cài đặt tích hợp trong bộ cân bằng tải. + Forward Proxy Trong phương pháp này, cache server được cài đặt giống như một proxy server cho một nhóm những người dùng đầu cuối. Trình duyệt của mỗi người dùng phải được cấu hình để chỉ đến proxy server này, nó dùng một cổng riêng biệt (special protocal) để hướng tất cả các requests của người dùng đến proxy cache này, nơi mà các ngữ cảnh sẽ được trả về cho người dùng. Rất nhiều doanh nghiệp sử dụng phương pháp này nhằm tăng tốc độ sử dụng hệ thống cho khách hàng. Một vấn đề nảy sinh trong khi triển khai phương pháp này là mỗi trình duyệt đều phải được cấu hình để chỉ đến proxy server, tuy nhiên, nó có thể được cài đặt tự động bằng cách chạy một script khi người dùng đăng nhập vào mạng của doanh nghiệp. Phương pháp cài đặt này cũng làm tăng khả năng bảo mật của hệ thống do người quản trị chỉ cho phép duy nhất proxy cache servers truy cập vào internet và khóa tất cả các truy cập khác. Như vậy tất cả người dùng sẽ phải thông qua proxy cache server nào đó, và do đó IP thực sự của người dùng sẽ được che giấu vì server gốc chỉ nhìn thấy proxy server giống như một người dùng cuối. Một vấn đề khác khi cài đặt forward proxy là cần phải đảm bảo khả năng mở rộng của cache server. Giả sử chúng ta có một cache server có khả năng phục vụ 500 người dùng, nhưng hệ thống của chúng ta cần đáp ứng cho 4000 người dùng một cách ổn định, khi đó chúng ta cần phải cài đặt 8 bộ cache như vậy và cần phải phân vùng tải giữa chúng. Thêm nữa, vì yêu cầu của người dùng được forward đến proxy cache server, nên khi cache server bị down, người dùng này sẽ bị mất kết nối đến internet, và như vậy ở đây xuất hiện hiện tượng thắt cổ chai (bottleneck). Bằng cách cài đặt một bộ cân bằng tải, chúng ta có thể có thể giải quyết được vấn đề mở rộng cũng như tính có sẵn của phương pháp cài đặt forward-proxy cache. Như mô tả ở hình 2.1-10, một bộ cân bằng tải được cài đặt ở phía trước forward-proxy caches. Chúng ta định nghĩa một địa chỉ IP ảo (VIP) trên bộ cân bằng tải và hướng VIP tới địa chỉ IP của từng cache server ở trên cổng 8080 (cổng 8080 thường được dùng cho kết nối proxy). Điều này nghĩa là lúc này trình duyệt sẽ được cấu hình để chỉ đến cổng này và nó sẽ gửi toàn bộ yêu cầu của người dùng đến cổng 8080 này. Với việc sử dụng bộ cân bằng tải này, chúng ta đã giải quyết được vấn đề về khả năng mở rộng cũng như tính đáp ứng của caches. Chúng ta có thể đưa thêm caches vào khi cần thiết, và chỉ cần kết nối nó với bộ cân bằng tải, thêm nữa, khi một cache không hoạt động, requests sẽ được gửi đến cache khác ngay lập tức. Một thuận lợi nữa là khi người quản trị cần bảo trì một cache nào đó, chẳng hạn update phần mềm cho nó, anh ta có thể làm việc này mà không làm gián đoạn hoạt động của hệ thống. H2.1-10. Cài đặt cache ở trình duyêt của người dùng Cân bằng tải cho caches ở đây cũng tương tự như cân bằng tải cho cụm server ứng dụng. Vấn đề lớn nhất khi sử dụng phương pháp này là phải cấu hình cho trình duyệt của người dùng chỉ đến cache. Nếu như chúng ta phải sử dụng một vài script tự động để làm việc này khi người dùng đăng nhập và hệ thống, thì sử dụng transparent proxy sẽ loại bỏ hoàn toàn được quá trình cấu hình này. + Transparent Proxy Như đã nói ở trên, phương pháp cài đặt này sẽ giúp chúng ta tránh phải cấu hình trình duyệt người dùng, cache được cài đặt như một transparent proxy bằng cách đặt nó trên đường kết nối internet, như mô tả trên hình 2.1-11 H2.1-11. Cài đặt cache như một transparent proxy Qua hình vẽ, chúng ta thấy rằng cache được cài đặt ở giữa đường truyền internet, do đó nó có khả năng ngắt kết nối tới server và phục vụ người dùng bằng dữ liệu mà nó có, trong trường hợp dữ liệu người dùng truy xuất không có trong cache, nó sẽ chuyển đến origin server để tìm và trả về cho người dùng. Người dùng sẽ không biết rằng có một bộ nhớ cache được cài đặt giữa họ và servers, tuy vậy phương án này sẽ gặp phải vấn đề về khả năng mở rộng và khả năng có sẵn. Với cách cài đặt như vậy, không thể lắp quá 1 bộ nhớ cache trên một đường truyền internet, và cache này trở thành SPOF[[] SPOF (Single point of failure): Một điểm trong hệ thống mà nếu nó ngừng hoạt động, toàn bộ hệ thống sẽ bị tê liệt ], nếu nó bị down, kết nối sẽ bị down hoàn toàn, hơn nữa, cách cài đặt này sẽ khiến cho người quản trị không thể bảo trì và nâng cấp cache mà không ngừng hoạt động của hệ thống. Bằng cách sử dụng một bộ cân bằng tải để thực thi chuyển hướng transparent cache (transparent-cache switching), như mô tả trong hình 2.1-12, chúng ta có thể đơn giản hóa cách cài đặt transparent-proxy cache. Bộ cân bằng tải phải được cấu hình bằng các biện pháp đổi hướng luồng dữ liệu (traffic-redirection policy) nhằm đổi hướng tất cả các luồng dữ liệu TCP với cổng đích là 80 đến cache. Các biện pháp này chỉ được dùng cho các luồng dữ liệu đến trên các cổng vật lý (physical port) mà được kết nối với mạng nội bộ. Điều này rất quan trọng, vì nếu như một cache không có đối tượng, nó sẽ tiếp tục gửi request đến server gốc, và lệnh này sẽ lại chạy qua bộ cân bằng tải một lần nữa, và lúc này, bộ cân bằng tải không được chuyển hướng request này ngược lại cache mà phải forward đến server gốc. H2.1-12. Cân bằng tải cho transparent-proxy cache Với việc sử dụng transparent-cache switching, bộ cân bằng tải có thể dễ dàng thực hiện “helth check” nhằm kiểm tra ngay lập tức bất cứ hỏng hóc nào. Nếu như cache bị hỏng, bộ cân bằng tải chỉ cần hoạt động đơn giản như một switch, chuyển hướng luồng dữ liệu theo đường đi của nó, người dùng sẽ vẫn kết nối internet bình thường, tuy nhiên tốc độ sẽ giảm vì không có cache. Nhưng điều quan trọng là người dùng sẽ không bị ngắt kết nối internet nữa, vì cache không còn nằm trên đường truyền, kết nối sẽ chỉ bị ngắt khi bộ cân bằng tải bị hỏng, nhưng do bộ cân bằng tải hoạt động chỉ như một switch, nên khả năng hỏng của nó là thấp hơn cache rất nhiều. + Reverse Proxy Khác với forward proxy hoạt động như một proxy cho người dùng gửi yêu cầu đến server, Reverse Proxy ngụ ý rằng nó hoạt động như một proxy cho server, như thể hiện trong hình 2.1-13. Chúng ta cài đặt reverse proxy ở phía trước của Web servers, và như vậy, chúng ta phải cấu hình lại DNS để tên của website chỉ vào IP của proxy cache chứ không phải web servers, như vậy khi kết nối, nếu đối tượng có trong cache, nó sẽ trả về cho người dùng, ngược lại nó sẽ yêu cầu vào web servers và trả kết quả về sau đó. Như vậy lúc này reverse-proxy cache đứng ở vị trí giống như một bộ cân bằng tải, dùng để tăng tốc độ phía server, hay giảm thời gian đáp ứng của server đến với người dùng. H2.1-13. Cài đặt cache như mọt reverse-proxy Hình 2.1-14 mô tả phương pháp cài đặt bộ cân bằng tải kết hợp với nhiều reverse-proxy cache. Một bộ cân bằng tải được đặt trước các caches, chúng ta sẽ định nghĩa một địa chỉ IP ảo VIP cho bộ cân bằng tải. Sau đó hướng nó đến từng reverse-proxy cache trên những cổng ứng dụng riêng biệt đang được cache, chẳng hạn như HTTP, FTP. Bộ cân bằng tải lúc này sẽ cân bằng tải cho các cache phía sau nó giống như nó cân bằng tải cho các web server và phân bố yêu cầu từ phía người dùng đến các cache này theo một thuật toán phân tải nào đó, chẳng hạn như round-robin hoặc băm theo một số giá trị. H2.1-14 Bộ cân bằng tải cho Reverse proxy caches Với các website toàn cầu, máy server được đặt ở khắp nơi trên thế giới, các bộ cache cũng như vậy, chúng không nhất thiết phải được cài đặt ngay trước Web servers mà có thể được cài đặt bất cứ đâu trên thế giới. Chẳng hạn như Web server có thể ở NewYork, nhưng cache lại được cài đặt ở Singapore, London. + Transparent Reverse Proxy Trong trường hợp sử dụng forward proxy, chúng ta phải cấu hình trình duyệt của người dùng để chỉ đến forward proxy cache. Cũng giống như vậy, trong trường hợp của reverse proxy, chúng ta phải cấu hình cho DNS chỉ đến reverse proxy. Chuyện gì sẽ xảy ra nếu như chúng ta không muốn thay đổi DNS entry? Và sau reverse proxy là rất nhiều web server? Cache sẽ phải phân phối yêu cầu vào trong các server này và sẽ gặp phải trường hợp cân bằng tải. Thêm nữa, nếu một công ty cung cấp hosting chỉ muốn cung cấp tính năng tăng tốc server như một tính răng cao cấp dành riêng cho những khách hàng đặc biệt của họ? Sử dụng transparent-reverse proxy chính là câu trả lời cho những câu hỏi này. Transparent-reverse proxy được mô tả như trong hình 2.1-15 . Một bộ cân bằng tải được đặt ở phía trước các web server, một tập các cache được cài đặt theo reverse-proxy cache. Nhiệm vụ cân bằng tải được đẩy cho bộ cân bằng tải, và như vậy cache sẽ không phải chịu trách nhiệm phân phối requests nữa, khi khách hàng đặc biệt kết nối và sử dụng dịch vụ đặc biệt, nhà cung cấp dịch vụ có thể cấu hình riêng cho địa chỉ IP ảo của khách hàng này trên bộ cân bằng tải sao cho tất cả các luồng dữ liệu được gửi đến trên cổng 80 sẽ được chuyển tiếp đến cache. Nếu cache hỏng, bộ cân bằng tải chỉ việc chuyển thẳng yêu cầu vào các web server. Luồng dữ liệu được mô tả như trên hình. Nếu bộ cân bằng tải nhận ra đây là IP của khách hàng đặc biệt, nó sẽ chuyển yêu cầu vào cache Nếu cache miss, hoặc yêu cầu cho các ngữ cảnh động, cache sẽ gửi yêu cầu ngược lại cho bộ cân bằng tải. Bộ cân bằng tải sẽ gửi yêu cầu đến server. Server gửi dữ liệu trả về cho cache Cache trả lại dữ liệu cho người dùng H2.1-15 Transparent-reverse proxy caches Các phương pháp cân bằng tải cho caches Cân bằng tải cho cache và cân bằng tải cho server là rất khác nhau. Đối với cân bằng tải cho server, bộ cân bằng tải tìm cách để tìm ra server đang có tải nhẹ nhất, và đẩy request về đó. Trong cân bằng tải cache, điều này phụ thuộc vào content đang có trong cache, nhằm đạt được tỉ lệ cache-hit cao nhất. Khi yêu cầu đầu tiên được gửi đến chưa có trong cache, dữ liệu từ server sẽ được đẩy xuống cache 1, nếu như cùng một yêu cầu đó từ phía người dùng đến lần thứ hai, sẽ là không cần thiết nếu như dữ liệu từ server lại được đẩy xuống cache 2, vì dữ liệu đã có sẵn ở cache 1. Do đó cần phải có cơ chế để nhận biết rằng, dữ liệu đã tồn tại trong cache nào đó, chỉ cần lấy ở đó trả về cho người dùng. Như vậy sẽ tăng tỉ lệ cache-hit và tốc độ trả về cho người dùng. Tuy khác nhau về nguyên lý, nhưng cũng có nhiều phương pháp để cân bằng tải cho cache khá giống với cân bằng tải server. Sau đây là một số phương pháp cân bằng tải cache thường được dùng: + Sử dụng hàm băm đơn giản (Simple Hashing) Bộ cân bằng tải sẽ tính toán một giá trị bằng cách sử dụng một hàm băm dựa trên một tập các nhân tố như giá trị địa chỉ IP nguồn, giá trị địa chỉ IP đích, giá trị cổng TCP/UDP nguồn và giá trị cổng TCP/UDP đích. Sau đó sử dụng giá trị này để tính toán xem cache nào là cache sẽ nhận được yêu cầu. Một phương pháp để thực hiện việc này đó là sử dụng hàm băm đơn giản. Một phép toán số học giống như phép cộng bytes trên các nhân tố được chọn sẽ cho ra kết quả là giá trị 1 byte X nằm trong khoảng (0 – 255). Lấy X chia cho N (với N là số cache hiện có) sẽ được số dư nằm trong khoảng (0 – N-1), và số dư này sẽ chỉ định là cache nào sẽ được chọn để gửi yêu cầu. Một số điểm cần lưu ý trong phương pháp này là: Nếu sử dụng địa chỉ IP đích làm giá trị băm, tất cả các yêu cầu tới cùng một web server sẽ được cho vào 1 cache duy nhất, vì địa chỉ IP đích không thay đổi nên giá trị băm luôn không đổi. Cần phải cân bằng trong việc chọn nhân tố cho hàm băm, nếu như chỉ chọn địa chỉ IP đích làm giá trị băm sẽ dẫn đến mất cân bằng. Thực vậy, giả sử 80% yêu cầu đều vào cùng 1 server, 20% vào các server khác, trong khi đó chúng ta có 3 cache, như vậy 80% số yêu cầu sẽ vào cùng một cache do cùng IP đích. Như vậy sẽ cân bằng cache sẽ không hiệu quả. Khi một cache bị hỏng, sẽ có một phép tính toán lại với N-1 cache còn lại, nhằm đảo bảo cho yêu cầu không bị đẩy vào một cache không tồn tại. Trong phương pháp simple hasing, chúng ta không quan tâm đến trạng thái cache, do đó nó còn được gọi là stateless load balancing, và chắc chắn sẽ có phương pháp stateful load balancing hoạt động hiệu quả hơn nhiều. Ph