Cân bằng tải trong các ứng dụng Web

Nội dung bài này nhằm mục đích cung cấp một số phương pháp để cân bằng tải trên các nhóm máy chủ (cluster) ứng dụng Web của bạn. Cluster là một nhóm các máy chủ chạy đồng thời một ứng dụng Web, quá trình thực hiện liên kết nhóm này làm cho các máy chủ hoạt động như một máy chủ riêng lẻ khi quan sát  từ khía cạnh bên ngoài. Để cân bằng tải máy chủ, hệ thống cần phải phân phối các yêu cầu (request) đến nhiều nút khác nhau bên trong cluster máy chủ, với mục đích tối ưu hóa hiệu suất hệ thống. Điều này sẽ mang đến cho mạng của bạn hiệu suất cao hơn, khả năng mở rộng (scalability) – tránh rơi vào tình trạng túng thiếu tài nguyên mạng trong một doanh nghiệp hay một ứng dụng Web nào đó.

Khả năng có sẵn cao có thể được hiểu là tình trạng dư thừa. Nếu một máy chủ không thể quản lý một yêu cầu thì các máy chủ khác trong cluster đó có quản lý được nó không? Trong một hệ thống có khả năng cung cấp cao, nếu một Web Server bị lỗi thì máy chủ khác sẽ tiếp quản ngay để xử lý yêu cầu.

Khả năng mở rộng (Scalability) là khả năng của một ứng dụng có thể hỗ trợ được số lượng người ngày một tăng. Nếu nó cần 10ms để một ứng dụng có thể đáp trả cho một yêu cầu thì khoảng thời gian sẽ là bao lâu để nó đáp trả đến 10.000 yêu cầu cùng một lúc? Khả năng mở rộng vô hạn sẽ cho phép nó đáp trả các yêu cầu này chỉ trong khoảng 10ms. Khả năng mở rộng là đơn vị đo cho một loạt các hệ số như số lượng người dùng đồng thời mà một cluster có thể hỗ trợ và thời gian nó cần để xử lý một yêu cầu.

Có hai phương pháp chính để cân bằng tải đó là:

  • Luân chuyển vòng DNS
  • Sử dụng các bộ cân bằng tải bằng phần cứng

Luân chuyển vòng DNS

Hầu hết trong số các bạn có lẽ đều đã biết rằng, cơ sở dữ liệu DNS (Domain Name Server) bản đồ hóa tên host thành các địa chỉ IP.

Khi bạn nhập một URL vào trong trình duyệt (ví dụ như http://www.loadbalancedsite.com) thì trình duyệt sẽ gửi một yêu cầu đến DNS yêu cầu nó trả về địa chỉ IP của site. Đây được gọi là việc tra cứu DNS. Sau khi trình duyệt Web có được địa chỉ IP cho site thì nó sẽ liên hệ với site bằng địa chỉ IP, và hiển thị trang mà bạn vừa yêu cầu. Máy chủ DNS thường có một địa chỉ IP được bản đồ hóa với một tên site nào đó. Trong ví dụ riêng của chúng tôi thì site là http://www.loadbalancedsite.com bản đồ hóa thành địa chỉ IP là 203.24.23.3.

Để cân bằng tải bằng DNS, máy chủ DNS phải duy trình một số địa chỉ IP khác nhau cho cùng một tên site. Nhiều địa chỉ IP thể hiện nhiều máy trong một cluster, tất cả trong số chúng đều bản đồ hóa đến một tên site logic. Trong ví dụ của chúng ta, http://www.loadbalancedsite.com có thể được cấu hình trên ba máy chủ trong một cluster với các địa chỉ IP dưới đây:

203.34.23.3
203.34.23.4
203.34.23.5

Trong trường hợp này, máy chủ DNS được bản đồ hóa như sau:


www.loadbalancedsite.com  203.34.23.3
www.loadbalancedsite.com 203.34.23.4
www.loadbalancedsite.com 203.34.23.5

Diagram.

Khi yêu cầu đầu tiên đến được máy chủ DNS, nó sẽ trả về địa chỉ IP 203.34.23.3, máy đầu tiên. Khi có yêu cầu thứ hau, nó sẽ trả về địa chỉ IP thứ hai: 203.34.23.4. Tiếp tục như vậy, với yêu cầu thứ tư, địa chỉ IP đầu tiên lại được lặp lại.

Bằng cách sử dụng luân chuyển vòng DNS như ở trên, tất cả các yêu cầu đối với một site nào đó đều được phân phối đều đến tất cả các máy trong cluster. Chính vì vậy, với phương pháp cân bằng tải này, tất cả các nút trong cluster đều được sử dụng.

Ưu điểm của phương pháp luân chuyển vòng DNS

Các ưu điểm chính của phương pháp này nằm ở chỗ rẻ và dễ dàng:

Không đắt và dễ dàng thiết lập: Các quản trị viên hệ thống chỉ cần tạo một số thay đổi trong máy chủ DNS để hỗ trợ được việc luân chuyển vòng, và nhiều máy chủ DNS đã có sự hỗ trợ này. Nó không yêu cầu đến sự thay đổi mã của ứng dụng Web; trong thực tế, các ứng dụng Web không hề biết về cơ chế cân bằng tải mà nó bị thực hiện.

Đơn giản: Phương pháp này không yêu cầu đến các chuyên gia về mạng trong việc thiết lập hoặc giỡ rối hệ thống trong trường hợp có vấn đề nào đó xay ra.

Nhược điểm của phương pháp này

Có hai nhược điểm chính của phương pháp dựa trên phần mềm này là nó không cung cấp sự hỗ trợ mối quan hệ thời gian thực giữa các máy chủ với nhau và không hỗ trợ khả năng có sẵn cao. 

Không hỗ trợ mối quan hệ thời gian thực giữa các máy chủ. Mối quan hệ thời gian thực giữa các máy chủ là khả năng của hệ thống trong việc quản lý các yêu cầu của người dùng, máy chủ này hoặc bất kỳ máy chủ nào, phụ thuộc vào thông tin session được duy trì trên máy chủ hoặc tại mức cơ sở bản, mức cơ sở dữ liệu.

Không có được khả năng hỗ trợ mối quan hệ giữa các máy chủ, phương pháp luân chuyển vòng DNS dựa vào một trong ba phương pháp đã được đưa ra để duy trì sự kiểm soát session hoặc sự nhận dạng người dùng đối với các yêu cầu đang đến trên HTTP.

  • Các cookie
  • Các trường ẩn
  • Viết lại URL

Khi một người dùng thực hiện một yêu cầu đầu tiên, máy chủ Web sẽ trả một thẻ bằng văn bản duy nhất để phân biệt người dùng đó. Các yêu cầu tiếp theo có thẻ này để sử dụng cookie, viết lại URL hoặc các trường ẩn, cho phép máy chủ xuất hiện để duy trì một session giữa máy khách và máy chủ. Khi người dùng thiết lập một session với một máy chủ, thì tất cả các yêu cầu đến sau thường đều đi đến cùng một máy chủ.

Vấn đề ở đây là trình duyệt lưu địa chỉ IP của máy chủ đó. Khi Cache hết hạn, trình duyệt sẽ thực hiện một yêu cầu khác đối với máy chủ DNS để có được địa chỉ IP có liên kết với tên miền. Nếu máy chủ DNS trả về một địa chỉ IP khác, một máy chủ khác trong cluster, thì các thông tin về session sẽ bị mất.

Không hỗ trợ cho khả năng có sẵn cao. Xem xét một cluster có n nút. Nếu một nút nào đó gặp vấn đề thì cứ yêu cầu thứ n đến máy chủ DNS đều hướng bạn đến một nút hỏng này. Một router thông minh có thể giải quyết được vấn đề này bằng cách kiểm tra các nút ở các khoảng thời gian nào đó, phát hiện ra các nút bị hỏng và gỡ bỏ chúng ra khỏi danh sách, chính vì vậy sẽ không có yêu cầu nào được gửi đến chúng nữa. Tuy vậy, vấn đề ở đây vẫn tồn tại nếu nút vẫn có nhưng ứng dụng Web đang chạy trên nút đã bị hỏng.

Thay đổi cluster sẽ mất nhiều thời gian để truyền bá đến toàn bộ phần còn lại của Internet. Một lý do ở đây là trong nhiều tổ chức lớn – các ISP, các công ty, hay đại lý – lưu các yêu cầu DNS của họ để giảm lưu lượng mạng và thời gian request. Khi người dùng bên trong các tổ chức như vậy thực hiện một request thì hệ thống sẽ được kiểm tra danh sách các tên DNS của Cache đã được bản đồ hóa địa chỉ IP. Nếu hệ thống phát hiện thấy một entry nào thì nó sẽ trả địa chỉ IP về cho người dùng. Nếu nó không phát hiện thấy entry nào trong Cache nội bộ thì ISP sẽ gửi request DNS này đến máy chủ DNS và lưu sự đáp trả.

Khi một entry đã được lưu hết hạn, ISP sẽ nâng cấp cơ sở dữ liệu nội bộ của nó bằng cách liên hệ với các máy chủ DNS khác. Khi danh sách các máy chủ của bạn thay đổi, nó có thể cần đến một khoảng thời gian ngắn cho các entry đã được lưu trên mạng của các tổ chức khác hết hạn và tìm kiếm danh sách các máy chủ đã được cập nhật. Trong suốt chu trình này, máy khách vẫn có thể thực hiện hành động “hit” nút máy chủ bị hỏng, nếu ISP của máy khách đó vẫn có một entry trỏ đến nó. Trong trường hợp như vậy, một số người dùng của ISP đó không thể truy cập vào site của bạn từ những lần truy cập ban đầu, thậm trí nếu cluster của bạn có các máy chủ dư thừa vẫn đang hoạt động.

Một vấn đề còn lớn hơn xuất hiên khi gỡ bỏ (removing) một nút so với việc bổ sung. Khi bạn bớt đi một nút, người dùng có thể đang thực hiện “hit” một máy chủ không tồn tại. Còn khi bạn thêm một nút thì máy chủ đó vẫn chưa được sử dụng cho tới khi địa chỉ IP của nó đến được tất cả các máy chủ DNS.

Mặc dù phương pháp này có thể cân bằng được một số lượng người dùng trên mỗi máy chủ, nhưng nó không hoàn toàn cân bằng tải máy chủ. Một số người dùng có thể yêu cầu mức tải cao hơn trong suốt một session của họ so với những người dùng khác ở trên máy chủ khác, và phương pháp này không thể bảo đảm chống lại được sự bất công bằng đó.

Cân bằng tải dựa trên phần cứng

Các bộ cân bằng tải phần cứng giải quyết được nhiều vấn đề mà chúng ta vừa phải đối mặt trong phương pháp phần mềm luân chuyển vòng DNS ở trên thông qua các địa chỉ IP ảo. Bộ cân bằng tải sẽ thể hiện một địa chỉ IP ảo đối với mạng bên ngoài, địa chỉ này bản đồ hóa đến các địa chỉ của mỗi máy trong một cluster. Chính vì vậy bộ cân băng tải này cần phải đưa ra một địa chỉ IP của toàn bộ các máy tính trong cluster đối với thế giới bên ngoài.

Khi một request đến bộ cân bằng tải, nó sẽ ghi lại header của request để trỏ đến các máy khác trong cluster. Nếu một máy nào đó bị gỡ bỏ từ cluster thì request sẽ không chạy một cách rủi ro việc “hit” vào máy chủ đã chết này, vì tất cả các máy chủ khác trong cluster xuất hiện đều có cùng địa chỉ IP. Địa chỉ này duy trì giống nhau thậm chí nếu một nút nào đó trong cluster bị hỏng. Khi một đáp trả được trả về, máy khách sẽ xem đáp trả đang đến từ bộ cân bằng tải phần cứng. Hay nói theo cách khác thì máy khách sẽ xử lý với một máy tính đó là bộ cân bằng phần cứng.

Ưu điểm

Mối quan hệ giữa các máy chủ. Bộ cân bằng tải phần cứng đọc cookie hoặc các URL đang được đọc trên mỗi một request bởi máy khách. Dựa trên các thông tin này, nó có thể ghi lại các thông tin header và gửi request đến nút thích hợp trong cluster, nơi session của nó được duy trì.

Các bộ cân bằng tải này có thể cung cấp mối quan hệ giữa các máy chủ trong truyền thông HTTP, nhưng không thông qua kênh an toàn như HTTPS. Trong kênh an toàn, các thông báo được mã hóa SSL và có thể tránh được bộ cân bằng tải từ việc đọc các thông tin session.

Khả năng có sẵn cao thông qua hệ thống tự động chuyển đổi dự phòng. Việc chuyển đổi dự phòng xảy ra khi một nút trong cluster không thể xử lý một request và chuyển hướng nó đến một nút khác. Có hai kiểu tự động chuyển đổi dự phòng:

  • Yêu cầu mức chuyển đổi dự phòng. Khi một nút trong cluster không thể xử lý một request (thường là vì bị hỏng) thì nó sẽ chuyển request này sang một nút khác.
  • Chuyển đổi dự phòng session một cách trong suốt. Khi một lời triệu gọi thất bại, nó sẽ được định tuyến một cách trong suốt đến một nút khác trong cluster để hoàn tất sự thực thi.

Bộ cân bằng kiểu này cung cấp chuyển đổi dự phòng mức request; tức là khi nó phát hiện có một nút nào đó bị sự cố thì bộ cân bằng này sẽ chuyển hướng tất cả các request theo sau được gửi đến nút này sang một nút tích cực khác trong cluster. Mặc dù vậy, bất kỳ một thông tin session nào trên nút chết sẽ bị mất khi các request được chuyển hướng đến một nút mới.

Chuyển đổi dự phòng session trong suốt yêu cầu một số kiến thức về sự thực thi cho một quá trình trong một nút, vì bộ cân bằng tải phần cứng chỉ có thể phát hiện các vấn đề mức mạng, không có lỗi. Để thực thi một cách trong suốt về vấn đề chuyển đổi dự phòng, các nút trong cluster phải kết hợp với các nút khác và có vùng bộ nhớ chia sẻ hoặc cơ sở dữ liệu chung để lưu tất cả các dữ liệu session. Cũng chính vì vậy nếu một nút trong cluster có vấn đề thì một session có thể tiếp tục trong một nút khác.

Metrics. Vì tất cả các yêu cầu tới một ứng dụng web đều phải qua hệ thống cân bằng tải, hệ thống có thể quyết định số lượng session hoạt động, số lượng session hoạt động được kết nối trong các trường hợp khác nhau, các khoảng thời gian đáp ứng, thời gian tối đa điện áp, số lượng session trong suốt khoảng tối đa điện áp, số lượng session trong suốt khoảng tối thiểu điện áp… Tất cả các thông tin kiểm định này được sử dụng để tinh chỉnh toàn bộ hệ thống nhằm tối ưu hiệu suất.

Nhược điểm

Nhược điểm đối với định tuyến phần cứng là giá thành của nó, sự phức tạp trong vấn đề thiết lập và khả năng hổng ở một vấn đề nào đó trong tương lai. Vì tất cả request đều được chuyển qua một bộ cân bằng tải phần cứng nên lỗi yêu cầu của phần cứng đó ảnh hưởng đến toàn bộ site.

Việc cân bằng các request HTTPS

Như đã đề cập ở trên, rất khó khăn trong vấn đề cân bằng tải và duy trì các thông tin session của request sử dụng giao thức HTTPS, vì chúng đã được mã hóa. Bộ cân bằng tải phần cứng không thể chuyển tiếp các request dựa trên thông tin trong header, cookie hay URL. Có hai cách để giải quyết vấn đề này:

  • Proxy của Web Server
  • Bộ giải mã SSL phần cứng

Bổ sung các proxy của Web Server

Một Web server proxy nằm trước một cluster của các máy chủ Web lấy tất cả các request và mã hóa chúng. Sau đó nó chuyển hướng chúng đến một nút thích hợp, dựa trên các thông tin header trong phần header, cookie và URL.

Ưu điểm của Web server proxy là chúng cung cấp cách để có được mối liên hệ giữa các máy chủ cho các thông báo được mã hóa SSL, không cần bất cứ một phần cứng mở rộng. Nhưng quá trình SSL mở rộng cần đến một tải mở rộng trên proxy.

Apache và Tomcat. Trong nhiều hệ thống phục vụ, các máy chủ Apache và Tomcat làm việc cùng với nhau để quản lý tất cả request HTTP cho các trang động (JSSP hoặc servlets). Các máy chủ Tomcat cũng quản lý các trang tĩnh, nhưng trong các hệ thống phối hợp, chúng thường được thiết lập để quản lý các request động.

Bạn cũng có thể cấu hình Apache và Tomcat để điều khiển các yêu cầu HTTPS và trong các tải cân bằng. Để thực hiện điều này, bạn chạy trường hợp đa máy chủ Tomcat trên một hoặc nhiều máy. Nếu tất cả máy chủ Tomcat đều chạy trên một máy, chúng nên được cấu hình để nghe trên các cổng khác nhau. Để thực thi cân bằng tải, bạn tạo một mẫu Tomcat đặc biệt gọi là Tomcat Worker.

 

Như những gì bạn có thể thấy trên hình trên, Web server Apache nhận request HTTP và HTTPS từ các máy khách. Nếu request là HTTPS, thì Web server Apache sẽ mã hóa request và gửi nó đến adapter máy chủ Web, máy chủ sẽ gửi request đến Tomcat Worker, gồm có cả thuật toán cân bằng tải. Tương tự với Web server proxy, thuật toán này cũng cân bằng tải giữa các máy như Tomcat.

Bộ giải mã SSL bằng phần cứng

Cuối cùng, chúng ta nên đề cập đến ở đây rằng có một số thiết bị phần cứng có khả năng giải mã các request SSL. Hướng dẫn chi tiết về chúng không nằm trong phạm vi bài này, nhưng có thể nói một cách vắn tắt, chúng được đặt trước bộ cân bằng tải phần cứng và cho phép giải mã thông tin trong các cookie, header và URL.

 

Các bộ giải mã SSL phần cứng này thường hoạt động nhanh hơn các proxy máy chủ Web và có khả năng mở rộng cao. Tuy nhiên như hầu hết các giải pháp phần cứng, chúng vẫn gây ra nhiều vấn đề phức tạp trong việc thiết lập và cấu hình.

Anh Ngọc (Nguồn QTM)

 

About Tony Nguyễn
Tôi tên Tony tự Tèo trú tại thôn Tám, Trảng Thanh tỉnh Thừa Thiên. Thưở thiếu thời trí tuệ tôi thường thường, tuy thế tính tình thật thà thẳng thắng, thích thi thơ ...

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: