Một bộ cõn bằng tải cần phải thực hiện được 4 chức năng cốt lừi sau:
+ Cân bằng tải cho server (server load balancing): có nhiệm vụ phân phối tải giữa các server, tăng khả năng mở rộng của hệ thống, giúp cho hệ thống vẫn hoạt động khi có server bị “chết”.
+ Cân bằng tải cho server toàn cầu (global server load balancing): có nhiệm vụ chuyển hướng yêu cầu của người dùng đến các data center khác nhau trong trường hợp website có nhiều trung tâm dữ liệu trên thế giới. Góp phần tăng tốc độ phản hồi cho người dùng và giúp cho hệ thống vẫn có khả năng hoạt động khi có trung tâm dữ liệu bị “chết”.
+ Cân bằng tải cho firewall (firewall load balancing): có nhiệm vụ phân phối tải giữa các firewall, giúp cho hệ thống vẫn hoạt động được khi có firewall bị “chết”
+ Chuyển mạch cache trong suốt (transparent cache switching): Giúp chuyển hướng lưu lượng một cách “trong suốt” đến các caches, góp phần tăng thời gian đáp ứng và hiệu năng của hệ thống.
1.1 Kỹ thuật cân bằng tải server (Server Load Balancing – SLB)
Như chúng ta đã biết, bộ cân bằng tải có nhiệm vụ kết nối giữa người dùng và server, do đó nó có thể hoạt động như một proxy hoặc gateway. Một proxy có nhiệm vụ luân chuyển yêu cầu và dữ liệu đáp trả giữa người dùng và server, trong khi đó một gateway chỉ có nhiệm vụ tạo ra một kết nối hai đối tượng này và không làm gì thêm. Có thể sử dụng phần cứng hoặc phần mềm được cài đặt trên một front server, hoặc trên chính web server. Thêm nữa, khi số lượng người dùng tăng lên, để tránh SPOF[4], cần thiết phải cài đặt 2 bộ cân bằng tải song song, hoạt động theo cơ chế active-active hoặc active-backup.
Các phần mềm cân bằng tải thường được cài đặt như một proxy. Để xây dựng một bộ cân bằng tải phần mềm, các kỹ thuật cần phải chú trọng, đó là: kiểm tra trạng thái server, lựa chọn server tốt nhất để gửi yêu cầu và kỹ thuật duy trì kết nối của người dùng.
1.1.1 Kiểm tra trạng thái server
Để chọn được server phù hợp để gửi request, bộ cân bằng tải cần phải biết được server nào đang có sẵn. Vì vậy, nó cần phải dùng biện pháp nào đó để kiểm tra trạng thái của server, chằng hạn như gửi lệnh ping, các yêu cầu, thử kết nối hay bất cứ phương pháp nào mà người quản trị nghĩ là dùng được. Kỹ thuật kiểm tra này thường được gọi là “health checks”
Một server bị down có thể trả lời lệnh ping nhưng không thể trả lời các kết nối TCP[5], một server bị treo có khả năng trả lời kết nối TCP nhưng không thể trả lời các yêu cầu HTTP. Khi một ứng dụng web nhiều lớp được kích hoạt, một số yêu cầu HTTP có thể trả lời ngay lập tức trong khi số khác sẽ thất bại.
Chính vì thế, việc chọn một phương pháp test phù hợp được chấp nhận bởi ứng dụng web và bộ cân bằng tải là rất thú vị. Một số test đôi khi phải cần truy xuất dữ liệu database nhằm đảm bảo rằng toàn bộ quá trình của nó là đúng. Hạn chế lớn nhất là những phương pháp kiểm tra này sẽ chiếm tài nguyên của hệ thống như là CPU, threads…
Do đó, cân bằng thời gian kiểm tra chính là vấn đề khó nhất trong kỹ thuật lựa chọn server. Khoảng thời gian giữa 2 lần test liên tiếp phải đủ dài để không tốn quá nhiều tài nguyên của hệ thống và cũng cần đủ ngắn để nhanh chóng phát hiện ra những server “chết”. Vì “health checks” là một trong những khía cạnh phức tạp nhất của kỹ thuật cân bằng tải, nên thường sau một vài kiểm tra, các nhà phát triển ứng dụng sẽ thực thi một yêu cầu đặc biệt dành riêng cho bộ cân bằng tải, giúp cho nó thực hiện một số kiểm tra nội bộ.
4[] 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
5[] TCP: Transmission Control Protocol: Giao thức điều khiển truyền vận, sử dụng tạo kết nối để trao đổi các gói tin
Phần mềm cân bằng tải có khả năng cung cấp scripting, do đó nó đạt được độ linh hoạt rất cao. Thêm nữa, nếu như một bài kiểm tra nào đó đòi hỏi phải chỉnh sửa code, nó có thể thực hiện trong một khoảng thời gian ngắn.
1.1.2 Lựa chọn server tốt nhất
Việc lựa chọn server tốt nhất chính là phần chính của thuật toán cân bằng tải được đề cập trong phần 2. Phương pháp dễ nhất và thường được sử dụng nhất trong các hệ thống nhỏ là Round Robin, các server được lựa chọn quay vòng, tuy nhiên phương pháp này có nhược điểm là 2 requests liên tục từ một người dùng sẽ vào 2 servers khác nhau, thông tin giữa 2 yêu cầu liên tiếp sẽ bị mất, như vậy sẽ không thể tối ưu hóa được sử dụng tài nguyên. Đặc biệt là khi cần phải cài đặt kết nối cho các phiên chạy - ví dụ như SSL key negociation - sẽ rất tốn thời gian.
Một cách khắc phục nhược điểm này là sử dụng một hàm băm theo địa chỉ IP, như vậy requests từ cùng một địa chỉ IP sẽ chỉ vào một server duy nhất. Tuy vậy phương pháp này đòi hỏi người dùng phải có IP tĩnh. Vậy thì cách khắc phục cho những hạn chế trên là gì? Đó chính là các kỹ Persistence
1.1.3 Kỹ thuật Session Persistence
Như đã đề cập ở trên, vấn đề cần giải quyết chính là làm sao để giữ cho các yêu cầu của một người dùng được gửi vào một máy duy nhất trong suốt phiên làm việc của người đó. Tất cả các yêu cầu của người dùng này cần phải được chuyển vào cùng một server. Nếu server bị chết, hoặc ngừng để bảo trì, cần phải có cơ chế để chuyển session của người dùng này sang máy server khác. Đó chính là kỹ thuật Session Persistence.
Có một số giải pháp được đưa ra để tiếp cận kỹ thuật này, chẳng hạn như sử dụng một respone HTTP 302 hay tạo ra liên kết giữa người dùng – server. Tuy vậy 2 phương pháp này đều có những hạn chế, sử dụng HTTP 302 sẽ khiến người dùng luôn luôn tìm cách kết nối với một server duy nhất, kể cả khi server này đã “chết”.
Dùng cách tạo liên kết đòi hỏi user phải có IP tĩnh trong suốt phiên làm việc.
Vậy thì câu trả lời cuối cùng là gì? Đó chính là sử dụng cookie. Cookie là một đối tượng được điều khiển bởi Web Servers. Trong kết quả trả về cho người dùng web servers sẽ chèn thêm một số thông tin. Những yêu cầu tiếp theo của người dùng gửi đến server sẽ chứa thêm thông tin của cookie này, server sẽ đọc các cookie và biết phải làm gì với các yêu cầu này.
1.1.4 Cookie
Một cookie được định nghĩa bằng cặp tên=giá trị (name=value). Hình 2.1-1 miêu tả hoạt động của cookie với cặp user=1, cho biết tên cookie là user và giá trị của nó là 1. Bên phía người dùng, cookie được điều khiển bởi trình duyệt và “trong suốt” đối với người dùng.
H 2.1-1. Cách làm việc của cookie user=1
Trong thiết kế của bộ cân bằng tải, có 3 cách để sử dụng cookie: Cookie chỉ đọc (Cookie-Read), bộ cân bằng tải chèn cookie nhằm chứng thực server (Cookie- Insert) và ghi đè cookie (Cookie-Rewrite).
+ Cookie-Read
Cách thức hoạt động của cookie-read được mô tả trong hình 2.1-2 dưới đây. Khi người dùng lần đầu tiên gửi yêu cầu đến server, do không có cookie trong yêu cầu, nên nó sẽ được phân tải đến server RS1 (1). Server RS1 sẽ tạo và đặt cookie server=1 vào trong dữ liệu trả về cho người dùng (2). Trình duyệt của người dùng sẽ nhận trả về này, đọc thấy cookies và lưu trữ nó vào trong đĩa cứng (3). Sau đó người dùng có thể đóng trình duyệt hoặc ngắt kết nối (giả sử rằng trình duyệt của người dùng không tự động xóa cookie sau khi đóng). Một thời gian sau người dùng kết nối lại và gửi yêu cầu đến bộ cân bằng tải . Sau khi kết nối được thiết lập, trình duyệt người dùng sẽ gửi cookie server=1 như là một phần của yêu cầu HTTP (4).
Bộ cân bằng tải sẽ đọc được cookie này, và do đó sẽ chuyển yêu cầu của người dùng vào server RS1. Như vậy người dùng sẽ luôn được kết nối vào server 1 cho đến khi nào cookie còn tồn tại, cho dù người dùng có thể vào website từ các địa chỉ IP khác nhau.
H 2.1-2 Cookie read
Ưu điểm của phương pháp cookie-read là nó không đòi hỏi bộ cân bằng tải phải làm việc nhiều, chỉ cần đọc cookie được tạo ra từ phía web-server và từ yêu cầu của người dùng. Nhược điểm của phương pháp này là ứng dụng ở server phải tạo ra một cookie, điều này không khó khăn lắm, nhưng nó sẽ khiến nhà phát triển ứng dụng phải thay đổi mã nguồn chương trình. Khi một server mới được lắp đặt, người quản trị hệ thống phải sửa đổi hoặc đặt thêm thông số server vào file cấu hình của bộ cân bằng tải.
+ Cookie-Insert
Phương pháp này được mô tả trong hình 2.1-3. Trong phương pháp này, ứng dụng ở server sẽ không làm gì cả. Kịch bản diễn ra tương tự như cookie-read, nhưng ở đây, khi server trả về dữ liệu cho người dùng (2), bộ cân bằng tải sẽ xem là server nào trả về dữ liệu, và chèn vào đó một cookie chứa thông tin về server này, chẳng hạn như cookie server=1 trong hình vẽ. Khi người dùng kết nối lần tiếp theo, bộ cân bằng tải sẽ đọc thông tin về cookie này, và chuyển hướng yêu cầu của người dùng vào đúng server RS1.
H2.1-3 Cookie-insert
Ưu điểm của phương pháp này là nó “trong suốt” đối với ứng dụng được cài đặt trên server, hay nói cách khác ứng dụng server sẽ không cần phải tạo ra một cookie hay không cần quan tâm xem cookie là gì. Khi 1 server được thêm mới hoặc xóa bỏ, hoặc khi file cấu hình của bộ cân bằng tải bị thay đổi, người quản trị hệ thống sẽ không cần phải lo lắng về việc cập nhập file cấu hình cho server. Nhược điểm của phương pháp này là có thể gây ra quá tải ở bộ cân bằng tải. Chúng ta có thể thấy rừ số lượng cụng việc mà bộ cõn bằng tải phải làm khi chốn 1 cookie trong
hình 2.1-4. Vì cần phải chèn dữ liệu nên gói dữ liệu trả về phải được sao lại 1 phần, vì vậy tăng dung lượng bộ nhớ cần thiết ở phía bộ cân bằng tải, thêm vào đó còn tăng dung lượng gói tin trả về cho người dùng, có thể khiến gói tin bị chia đôi, dẫn đến mất dữ liệu.
.
H2.1-4 Bộ cân bằng tải chèn một cookie + Cookie-Rewrite
Phương pháp cookie-read không đòi hỏi bộ cân bằng tải phải làm quá nhiều việc như cookie-insert, trong khi đó cookie-insert lại không yêu cầu ứng dụng phía server phải tạo cookie còn cookie-read lại cần. Cần phải có một phương pháp dung hòa ưu và nhược điểm của 2 phương pháp trên. Đó chính là phương pháp ghi đè cookie.
Nhược điểm lớn nhất trong cookie-insert là cần phải có một bộ nhớ phức tạp, và thêm nữa có thể khiến gói tin bị chia thành 2 (do dung lượng vượt quá giá trị lớn nhất của gói tin được chấp nhận ở Ethernet) và dẫn đến mất dữ liệu. Chuyện gì sẽ xảy ra nếu như chúng ta tạo một chỗ trống ở gói tin để lưu giá trị cookie, và bộ cân bằng tải chỉ cần đặt vào đó giá trị cần thiết. Trong phương pháp ghi đè cookie, được mô tả như hình 2.1-5 ở dưới, ứng dụng sẽ chèn vào gói tin trả về một cookie server=XXX. Tất cả những gì bộ cân bằng tải phải làm là tìm kiếm đoạn server=XXX này và thay “XXX” bằng giá trị ID của server, chẳng hạn như server=001.
H2.1-5 Bộ cân bằng tải ghi đè một cookie
Ưu điểm của phương pháp này là tránh cho bộ cân bằng tải làm việc quá mức và tránh cho gói tin bị chia nhỏ. Bên cạnh đó nó cũng khắc phục được nhược điểm của phương pháp cookie-read. Nó là phương pháp tốt nhất trong 3 phương pháp đã được đề cập ở trên và thường được chọn để dùng trong các bộ cân bằng tải
1.2 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.
1.2.1 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