Thiết kế bộ phân tải cho các dịch vụ mạng lớn đảm bảo khả năng nhanh chóng mở rộng quy mô hệ thống

Một website toàn cầu sẽ có rất nhiều web-server đặt ở nhiều nơi trên thế giới, cân bằng tải cho hệ thống web-server này nghĩa là làm cách nào để các web-server không bị quá tải, luôn đáp

LỜI CẢM ƠN

Lời đầu tiên tôi xin gửi lời cảm ơn chân thành và sâu sắc nhất tới thầy giáo - TS.Nguyễn Khanh Văn, người thầy tận tâm nhiệt tình đã chỉ dạy và hướng dẫn tôi hoàn thành luận văn này

Tôi cũng xin bày tỏ lòng biết ơn sâu sắc đến tất cả các thầy, các cô Viện Công nghệ Thông tin và Truyền thông đã giảng dạy và truyền thụ kiến thức cho tôi cũng như các bạn đồng học trong suốt quá trình học tập vừa qua

Cuối cùng tôi xin gửi lời cảm ơn chân thành sâu sắc tới gia đình, các bạn bè của tôi, những người đã luôn ở bên cạnh giúp đỡ, động viên khuyến khích tôi

Hà Nội, ngày 10 tháng 8 năm 2013

Học viên

Trần Văn Tâm

MỤC LỤC

PHẦN MỞ ĐẦU 8

CHƯƠNG I : KIẾN TRÚC WEB VỚI KHẢ NĂNG NHANH CHÓNG MỞ RỘNG QUY MÔ HỆ THỐNG 11

1 Khái niệm chung về kiến trúc web với khả năng mở rộng: 11

1.1.Khả năng mở rộng (Scalability): 11

1.2.Hiệu năng (Performance): 11

1.3.Khả năng sẵn có (High Availability): 12

1.4.Tính đáp ứng (Responsiveness): 12

1.5.Thời gian chết của hệ thống (Downtime impact): 12

2 Các vấn đề cần giải quyết trong quá trình xây dựng website theo kiến trúc với khả năng mở rộng: 13

2.1.Cân bằng tải cho Application servers: 13

2.2.Cân bằng tải cho Cơ sở dữ liệu (database) trên servers: 16

2.2.1 Share nothing Cluster 17

2.2.2 Real Application Cluster (Shared storage Cluster) 19

2.3.Tổ chức lưu trữ dữ liệu 20

CHƯƠNG II : PHƯƠNG PHÁP XÂY DỰNG BỘ CÂN BẰNG TẢI CHO WEB-SERVER 23

1 Lý thuyết xây dựng bộ cân bằng tải cho web-servers 23

1.1.Kỹ thuật cân bằng tải server (Server Load Balancing – SLB) 24

1.1.1 Kiểm tra trạng thái server 24

1.1.2 Lựa chọn server tốt nhất: 25

1.1.3 Kỹ thuật Session Persistence: 25

1.1.4 Cookie: 26

1.2.Cân bằng tải cho server toàn cầu (GSLB): 30

1.2.1 Domain Name System: 30

1.2.2 Cài đặt bộ cân bằng tải vào hệ thống mạng DNS: 32

1.2.3 Lựa chọn site tốt nhất: 35

1.3.Chuyển mạch cache trong suốt: 37

1.3.1 Các phương pháp cài đặt cache: 37

1.3.2 Các phương pháp cân bằng tải cho Cache: 44

1.3.3 Nhận biết các ngữ cảnh trong cache (Content-aware cache switching): 47

1.4.Cân bằng tải sử dụng phần cứng và cân bằng tải phần mềm: 49

1.4.1 Cân bằng tải sử dụng phần cứng: 49

1.4.2 Cân bằng tải sử dụng phần mềm: 51

2 Các thuật toán cân bằng tải: 52

2.1.Thuật toán ngẫu nhiên (random): 52

2.2.Thuật toán Round Robin (RR): 52

2.3.Thuật toán Weighted Round Robin (Ratio) 53

2.4.Thuật toán Dynamic Round Robin - DRR (Dynamic Ratio) 54

2.5.Thuật toán Fastest 54

2.6.Thuật toán Least Connections (LC) 55

2.7.Thuật toán Observed 56

2.8.Thuật toán Predictive 56

CHƯƠNG III : CÀI ĐẶT BỘ CÂN BẰNG TẢI HAPROXY 57

1 Bộ cân bằng tải sử dụng mã nguồn mở Haproxy: 57

1.1.Giới thiệu về bộ cân bằng tải mã nguồn mở Haproxy: 57

1.2.Cài đặt bằng phương pháp Cookie-insert: 59

1.3 Cài đặt với khả năng mở rộng cao: 62

2 Cài đặt các thuật toán cân bằng tải trên HAproxy: 66

2.1.Thuật toán Weighted Round Robin (WRR) 70

2.2.Thuật toán Lest Connection (LC) 72

2.3.Nâng cao khả năng chịu tải của bộ cân bằng tải: 73

3 Cài đặt và cấu hình Haproxy trên server Centos: 75

3.2 Cài đặt Haproxy: 79

4 Cấu hình và cài đặt bộ công cụ theo dõi server trong hệ thống cân bằng tải: 82

KẾT LUẬN VÀ ĐỊNH HƯỚNG PHÁT TRIỂN 86

TÀI LIỆU THAM KHẢO 89

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn này là kết quả quá trình nghiên cứu của tôi dưới sự hướng dẫn của thầy giáo – TS Nguyễn Khanh Văn

Toàn bộ nội dung của luận văn là các kiến thức của tôi đúc rút được sau quá trình học tập cũng như các kiến thức thu được từ các tài liệu tham khảo do thầy giáo cung cấp, luận văn không hề sao chép lại bất kỳ luận văn cũng như công trình khoa học nào khác

Học viên

Trần Văn Tâm

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

Ký hiệu Từ đầy đủ Nghĩa Tiếng Việt

DNS Domain Name System

Hệ thống phân giải tên trong internet, thiết lập tương ứng giữa địa chỉ IP của một website và tên miền của nó

Proxy – Proxy Server

Server đứng giữa người dùng và webserver, có nhiệm

vụ trao đổi thông tin

Reverse-proxy Proxy bên phía server, tăng tốc server

RR Round Robin

Thuật toán phân tải cho các server theo thứ tự xoay vòng

SAN Storage Area Networks

Kiến trúc kết nối những thiết bị lưu trữ từ xa để xem chúng như là cục bộ với nhau

Scalable - Scalability

Khả năng mở rộng: khả năng một website có thể đáp ứng được số lượng người dùng ngày một tăng Scale - Scaling Mở rộng, tăng khả năng hoạt động

Ký hiệu Từ đầy đủ Nghĩa Tiếng Việt

SPOF Single point of failure

Một node trong hệ thống mà nếu nó bị “chết” thì toàn bộ

DANH MỤC CÁC BẢNG

H 1.2-1 So sánh scale out và scale up 14

H 1.2-2 Bảng so sánh giá thành 2 phương pháp 15

H 1.2-3 Mô hình cân bằng tải web server 16

H 1.2-4 Mở rộng database server sử dụng kiến trúc SAN 17

H.1.2-5 Mở rộng database server theo chiều ngang 17

H.1.2-6 Real Application Cluster 19

H.1.2-7 Mô hình mở rộng database nên dùng 20

H.1.2-8 Mô hình CDN 21

H.2.1-1 Cách làm việc của cookie user=1 26

H.2.1-2 Cookie read 27

H.2.1-3 Cookie-insert 28

H.2.1-4 Bộ cân bằng tải chèn một cookie 29

H.2.1-5 Bộ cân bằng tải ghi đè một cookie 29

H.2.1-6 Mô hình Global Server Load Balancing 31

H.2.1-7 Bộ cân bằng tải hoạt động như một authoritative DNS 33

H.2.1-8 Bộ cân bằng tải hoạt động như một forward DNS proxy 34

H.2.1-9 Sự kết hợp GSLB và SLB trong bộ cân bằng tải 35

H.2.1-10 Cài đặt cache ở trình duyêt của người dùng 39

H.2.1-11 Cài đặt cache như một transparent proxy 40

H.2.1-12 Cân bằng tải cho transparent-proxy cache 41

H.2.1-13 Cài đặt cache như mọt reverse-proxy 42

H.2.1-14 Bộ cân bằng tải cho Reverse proxy caches 42

H.2.1-15 Transparent-reverse proxy caches 44

H.2.1-16 Phương pháp hash buckets dùng trong caching 46

H.2.1-17 Ví dụ về luật giúp bỏ qua các ngữ cảnh động 48

H.2.1-18 Cân bằng tải sử dụng phần cứng 50

H.3.1-1 Mô hình cân bằng tải đơn giản với một bộ cân bằng tải 60

H.3.1-2 Mô tả Luồng dữ liệu trong mô hình đơn giản 61

H.3.1-3 Mô hình phức tạp với 2 bộ cân bằng tải chia sẻ 1 địa chỉ IP ảo 63

H.3.1-4 Luồng dữ liệu trong mô hình 2 bộ cân bằng tải với keepalived 65

H.3.3-1 Cấu hình firewall cho CentOS 76

H.3.3-2Cấu hình firewall cho CentOS (tiếp) 76

H.3.3-3 Kiểm tra thông số server trong HAProxy 81

H.3.4-1 Kiến trúc hệ thống cài đặt Ganglia 82

PHẦN MỞ ĐẦU

1 Lý do chọn đề tài

Sự bùng nổ của ngành dịch vụ web trong những năm gần đây khiến số lượng người truy cập vào mạng internet ngày càng tăng mạnh, đặc biệt là các website mạng xã hội và các website chia sẻ video trực tuyến Với hàng trăm triệu lượt truy cập mỗi ngày, các website này đòi hỏi phải có một hệ thống server cực kỳ mạnh mẽ Một hệ thống hoạt động tốt sẽ khiến người dùng hài lòng, sau một thời gian hoạt động số lượng người dùng sẽ tăng lên, máy chủ của hệ thống sẽ bị quá tải, dẫn đến yêu cầu nâng cấp Sau khi nâng cấp lại tiếp tục như cũ Vòng tuần hoàn này dẫn đến nhu cầu cần phải xây dựng một hệ thống website với khả năng đáp ứng người dùng trong một thời gian đủ dài và dễ dàng nâng cấp mở rộng khi cần Đó chính là kiến trúc web với khả năng mở rộng quy mô hệ thống

Vấn đề quan trọng nhất trong kiến trúc web với khả năng mở rộng chính là cân bằng tải cho hệ thống web-server Một website toàn cầu sẽ có rất nhiều web-server đặt ở nhiều nơi trên thế giới, cân bằng tải cho hệ thống web-server này nghĩa là làm cách nào để các web-server không bị quá tải, luôn đáp ứng được nhu cầu của người dùng trong thời gian nhanh nhất Trong sự cạnh tranh khốc liệt giữa các website dịch vụ, nhà quản trị nào có thể đáp ứng được nhu cầu của người dùng một cách tốt nhất, người đó sẽ thắng, vì vậy nhu cầu cân bằng tải là vô cùng cần thiết và là vấn

đề sống còn đối với các nhà cung cấp dịch vụ web

Có nhiều phương pháp để cân bằng tải, tuy nhiên lý thuyết chung là cần phải

có một bộ cân bằng tải đứng giữa người dùng và hệ thống web-server Bộ cân bằng tải này sẽ nhận yêu cầu từ phía người dùng, sau đó chuyển hướng các yêu cầu này đến các server phù hợp dựa trên các thuật toán phân tải, sau đó nhận dữ liệu từ server và trả về cho người dùng

Luận văn trình bày tổng quan về các vấn đề cần phải giải quyết trong quá trình thiết kế hệ thống web với khả năng mở rộng Sau đó sẽ đi sâu vào lý thuyết cân bằng tải cho các hệ thống web-server lớn, các kỹ thuật và phương pháp cân bằng tải hiện đang được sử dụng

Tiếp theo sẽ là kiến trúc và các thành phần cần xây dựng của một bộ cân bằng tải, các thuật toán phân tải đã và đang được dùng trên thế giới, các phương pháp cài đặt bộ cân bằng tải vào hệ thống để đạt được hiệu quả về khả đáp ứng người dùng cũng như khả năng mở rộng Tiếp theo em xin đưa ra cài đặt một số thuật toán cân bằng tải cụ thể dựa trên một số phần mềm cân bằng tải mã nguồn mở và một số cải tiến cho các thuật toán này Cuối cùng là định hướng xây dựng một bộ cân bằng tải hoàn toàn độc lập thực thi các thuật toán phân tải cải tiến nhằm áp dụng cho các website đang hoạt động.

Nội dung luận văn được chia thành 3 chương:

Chương 1: Khái niệm chung về kiến trúc web với khả năng nhanh chóng

mở rộng quy mô hệ thống, các vấn đề cần giải quyết khi xây dựng website theo kiến trúc với khả năng mở rộng

Chương 2: Lý thuyết để xây dựng bộ cân bằng tải web-server, chức năng, nhiệm vụ của một bộ cân bằng tải Các thuật toán, kỹ thuật phân tải đã và đang được sử dụng trên các bộ cân bằng tải web-server

Chương 3: Ứng dụng một số thuật toán cân bằng tải dựa trên phần mềm cân bằng tải mã nguồn mở HAProxy

Phần kết luận

4 Phương pháp nghiên cứu

Phương pháp thu thập tư liệu sẵn có: Sử dụng công cụ tìm kiếm trên mạng Internet để tìm kiếm các tài liệu liên quan, thu thập các tài liệu ebook, các nghiên cứu được đăng trên các tạp chí chuyên ngành, hỗ trợ cho việc thực hiện luận văn Phương pháp kế thừa: Kế thừa lại các kết quả nghiên cứu của các tài liệu có cùng lĩnh vực nghiên cứu để tiếp tục nghiên cứu mở rộng các nội dung này

Phương pháp lấy ý kiến chuyên gia: Tiếp thu ý kiến của thầy giáo hướng dẫn trực tiếp, các thầy trong Viện để hoàn thiện luận văn

5 Kết luận

Luận văn đã đưa ra các thành phần cần phải xây dựng của một bộ cân bằng tải

và đã cài đặt một giải pháp phân tải động thông minh hoạt động hiệu quả hơn so với giải pháp đang chạy trên một bộ cân bằng tải mã nguồn mở

Trong đó luận văn đã trình bày các bước cài đặt một thuật toán tĩnh và một thuật toán động dựa trên một sản phẩm cân bằng tải mã nguồn mở chạy trên server linux là HAProxy

CHƯƠNG I KIẾN TRÚC WEB VỚI KHẢ NĂNG NHANH CHÓNG MỞ RỘNG QUY MÔ

HỆ THỐNG

1 Khái niệm chung về kiến trúc web với khả năng mở rộng:

Một website với khả năng mở rộng nghĩa là, khi số lượng người dùng tăng lên trong một khoảng nhất định, website vẫn đáp ứng được nhu cầu, thêm nữa, website

có khả năng dễ dàng nâng cấp lên để phù hợp với tình hình mới Tại thời điểm ban đầu, các website với khả năng mở rộng lớn thường được thiết kế để phục vụ hàng chục triệu yêu cầu mỗi ngày, sau đó nó sẽ được nâng cấp để phục vụ thêm, nếu như

có nhu cầu Để phục vụ được hàng chục triệu lượt truy cập mỗi ngày, website cần phải đáp ứng được yêu cầu về khả năng mở rộng (Scalability), về hiệu năng (Performance), tính đáp ứng (Responsiveness), tính sẵn có cao (High Availability), tránh được thời gian chết của hệ thống (downtime impact), khả năng bảo trì tốt và được xây dựng với giá thành tốt nhất Sau đây em xin trình về các khái niệm này

1.1 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 Như vậy, khả năng mở rộng là đơn vị đo sự kết hợp của các hệ số, đó là số lượng người dùng đồng thời mà một cụm server có thể hỗ trợ và thời gian cụm server cần

để xử lý một yêu cầu Thiết kế website với khả năng mở rộng cao là yêu cầu sống còn đối với hầu hết các công ty dịch vụ web hiện nay, để tồn tại và phát triển, một website cần phải đáp ứng được yêu cầu của người dùng trong thời gian mà họ mong muốn

1.2 Hiệu năng (Performance):

Là khả năng mà hệ thống sử dụng tài nguyên của nó một cách tốt nhất Tính thực hiện được đo bằng lượng công việc có ích mà hệ thống thực hiện được với một nguồn tài nguyên nhất định, chẳng hạn như nếu 2 server có cấu hình giống nhau, server nào có thể phục vụ được nhiều người dùng hơn (người dùng chạy các ứng dụng tương đương) thì máy đó có tính thực hiện cao hơn

1.3 Khả năng sẵn có (High Availability):

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ó hay không? Trong một hệ thống có khả năng có sẵn cao, nếu một web server bị lỗi thì một web server khác sẽ tiếp quản ngay để xử lý yêu cầu Nghĩa là nếu người dùng đang làm việc với một server mà server đó bị lỗi, toàn bộ thông tin trong phiên làm việc của người đó sẽ được chuyển qua cho một server khác đảm nhiệm Như vậy trong bất cứ trường hợp nào, người dùng truy cập vào các dịch vụ của hệ thống đều được đáp ứng, chính vì vậy mà người dùng luôn cảm thấy được phục vụ tốt nhất

1.4 Tính đáp ứng (Responsiveness):

Tính đáp ứng ở đây có thể hiểu là khả năng phục vụ người dùng của hệ thống, làm sao để hệ thống có thể phục vụ người dùng tại mọi thời điểm, và thời gian cho đáp ứng đó là bao nhiêu Hệ thống gửi response về càng nhanh thì tính đáp ứng của

nó càng cao, ngược lại, nếu thời gian trì hoãn (delay) càng lớn, sẽ khiến người dùng thất vọng, và dẫn tới việc họ tin là trang web đang bị hỏng, điều này rất có hại, vì nếu người dùng mất niềm tin, họ sẽ không quay trở lại trang web đó nữa Chẳng hạn như khi người dùng truy cập vào một trang web, nếu họ phải chờ quá lâu, họ sẽ chuyển qua làm công việc khác, đôi khi họ quên mất là mình đang truy cập và một dịch vụ web và đóng luôn trình duyệt, hoặc họ quay trở lại sau một thời gian khá lâu, điều này rất không tốt vì hệ thống mà họ truy cập vẫn hoạt động và lưu giữ session mà không phục vụ cho ai cả, đó là một sự lãng phí lớn Ở đây cần phải hiểu rằng tính đáp ứng và tính thực hiện là độc lập với nhau, một hệ thống có hiệu năng tốt vẫn có thể đáp ứng rất tệ

1.5 Thời gian chết của hệ thống (Downtime impact):

Downtime impact là một vấn đề mà tất cả các hệ thống đều gặp phải, đó là thời gian mà hệ thống bị “chết”, khi mà một số các chắc năng chính bị down, đây là vấn đề có tính tuần hoàn đối với các nhà phát triển hệ thống Một hệ thống tốt sẽ giúp người dùng truy cập nhanh, làm họ cảm thấy hài lòng, dẫn đến số lượng người dùng tăng lên, và khi số lượng người dùng tăng lên hệ thống sẽ lại bị tắc nghẽn, và nhà quản trị sẽ phải đối phó với vấn đề nó, giải quyết nó nhằm tạo ra hệ thống hoạt

động tốt hơn, cứ như vậy vòng quay lại tiếp tục Điều quan trọng là một hệ thống tốt cần phải kéo thời gian chu kỳ này lên, nghĩa là làm sao cho hệ thống hoạt động được tốt nhất trong một thời gian đủ dài trước khi cần phải nâng cấp, cũng như làm sao để xây dựng được một hệ thống có khả năng mở rộng lớn

Cùng với các đòi hỏi này, hệ thống cũng cần phải có thể dễ dàng bảo trì và giá thành vừa phải Xây dựng một hệ thống web như vậy sẽ gặp rất nhiều vấn đề khó, sau đây em xin trình bày ra những vấn đề quan trọng nhất trong việc thiết kế một trang web có khả năng mở rộng mà bất cứ nhà phát triển hệ thống web nào cũng phải giải quyết, đó là: cân bằng tải cho application servers, cân bằng tải cho database-server, tổ chức lưu trữ dữ liệu trên đĩa cứng và cân bằng tải cho cache

2 Các vấn đề cần giải quyết trong quá trình xây dựng website theo kiến trúc với khả năng mở rộng:

2.1 Cân bằng tải cho Application servers:

Một trang web phục vụ hàng triệu lượt người truy cập mỗi ngày thì điều quan trọng đầu tiên là phải có một hệ thống servers đủ mạnh, khi người dùng tăng lên theo thời gian, hệ thống máy chủ cũng phải được nâng cấp, mở rộng Có 2 sự lựa chọn ở đây: mở rộng theo chiều ngang (scale out) và mở rộng theo chiều dọc (scale up)

Mở rộng theo chiều dọc nghĩa là, khi số lượng người dùng tăng lên, nhà phát triển sẽ nâng cấp server của mình bằng cách tăng cấu hình của máy server, hệ thống vẫn chỉ có 1 server với cấu hình ngày mạnh hơn (tăng số lượng chip, tăng dung lượng RAM…) Sử dụng phương pháp này, người quản trị hệ thống sẽ không phải quan tâm đến vấn đề cân bằng tải cho cụm server, hệ thống hoạt động rất tốt khi số lượng người dùng vừa phải Tuy vậy, phương pháp này sẽ dẫn đến nhiều vấn đề, đầu tiên là giá thành, nhìn vào bảng so sánh giá ở trang dưới, sử dụng một server sẽ tốn kém hơn rất nhiều so với nhiều servers, một vấn đề nữa cũng quan trọng không kém là vấn đề downtime impact, vì chỉ có 1 server nên nó trở thành SPOF (single point of failure), nếu như server này bị chết, ngay lập tức toàn bộ hệ thống sẽ chết Phương pháp này còn dẫn đến giới hạn cho hệ thống, vì đến môt mức nào đó hệ thống sẽ không thể phục vụ được nhiều yêu cầu hơn nữa, vì một hệ thống tổng thể

còn phụ thuộc vào nhiều yếu tố như băng thônghay khả năng vào ra của file trên đĩa cứng

Ví dụ sau đây sẽ cho thấy rõ điều đó, giả sử với 1 site video, băng thông để xem được 1 clip ở dạng chất lượng trung bình sẽ vào khoảng 512kb/s -> 0.5mb/s Vậy đường truyền 100mb sẽ cho phép tối đa 200 người dùng xem đồng thời Điều

gì sẽ xảy ra nếu muốn có hơn số người dùng đó? Người ta có thể tăng băng thông cho đường truyền lên 1 gigabit nhưng đây sẽ rơi vào tình trạng của scale up và gặp giới hạn Ngoài ta, tốc độ đọc đĩa cứng chỉ vào khoảng 400mb/s nên dù cho có tăng tốc đường truyền lền thì server vẫn không thể phục vụ được nhiều hơn nữa Như vậy sử dụng scale up không thể giải quyết được vấn đề này

Giải pháp thứ hai là lắp nhiều servers song song, và chúng hoạt động thành một cụm (Cluster) Theo ví dụ ở trên, cứ lắp thêm 1 server lại có khả năng đáp ứng cho 200 người dùng nữa, và càng nhiều server thì khả năng mở rộng lại càng lớn Thêm nữa, sử dụng phương pháp này còn giảm thiểu được chi phí Vậy thì điểm yếu giải pháp này là gì? Đó chính là vấn đề cân bằng tải, để cứ mỗi server sẽ thêm được 200 người dùng, hệ thống phải được cân bằng tải một cách tốt nhất, làm sao

để tải được phân bố đều đặn vào trong các máy server? Các server được kết nối với nhau như thế nào?

H 1.2-1 So sánh scale out và scale up

Giá thành của 2 phương pháp:

hệ thống phải làm sao để các server hoạt động cân bằng, nghĩa là các server được phục vụ một lượng yêu cầu phù hợp, tránh không để bất cứ server nào bị quá tải (overload), đồng thời tận dụng được hết tài nguyên hệ thống để phục vụ được lượng truy cập lớn nhất

Như đã đề cập ở phần mở đầu, để cân bằng tải cho hệ thống web-servers cần phải xây dựng một gọi là bộ cân bằng tải (load balancer) Bộ cân bằng tải này này được đặt trước cluster, nhận yêu cầu từ phía người dùng, xử lý các yêu cầu này và chuyển hướng chúng đến máy server phù hợp

Mô hình tổng quát được miêu tả dưới đây:

H 1.2-3 Mô hình cân bằng tải web server

2.2 Cân bằng tải cho Cơ sở dữ liệu (database) trên servers:

Bên cạnh các web server, các database server cũng đóng vai trò vô cùng quan trọng trong hệ thống web Sự phát triển của website sẽ dẫn đến yêu cầu phải mở rộng database server, chẳng hạn như lắp thêm server để phục vụ nhu cầu tại một địa điểm đã có server từ trước hoặc lắp mới server ở các vùng khác nhau trên thế giới Cũng như cân bằng tải ở Application Server, mở rộng Database Server cũng có 2 phương pháp: mở rộng theo chiều ngang và mở rộng theo chiều dọc

Mở rộng theo chiều dọc, hiện nay các nhà phát triển hệ thống sử dụng kiến trúc SAN (Storage area networks), DB sẽ được phân chia (partitioning out) theo kiến trúc này SAN là một kiểu kiến trúc kết nối những thiết bị lưu trữ máy tính từ

xa (như disk arrays, tape libararies, and optical jukeboxes) để phục vụ theo cách mà những thiết bị ấy được xem như là cục bộ (local) đối với hệ điều hành Như vậy, hệ thống lưu trữ bây giờ chỉ được xem như một Database Server duy nhất, vì vậy mà

nó hoạt động rất hiệu quả

Kiến trúc này sẽ tăng đáng kể khả năng của Database Server, tuy vậy vì giá thành của nó rất đắt (như đã đề cập ở trên) nên nó không được sử dụng rộng rãi mà chỉ được dùng trong các hệ thống lớn và quan trọng

H 1.2-4 Mở rộng database server sử dụng kiến trúc SAN

Mở rộng DB theo chiều ngang (scaling out), nghĩa là tăng số lượng các node Database Server, như minh họa dưới đây:

H.1.2-5 Mở rộng database server theo chiều ngang

Sẽ có 2 lựa chọn để cài đặt theo phương pháp này:

- Shared nothing Cluster

- Real Application Cluster (Shared storage Cluster)

Mô tả 2 phương pháp trên:

2.2.1 Share nothing Cluster

Trong phương pháp Shared nothing cluster, mỗi database server sẽ chứa một bản copy hoàn toàn của database, tức là tất cả các DBServer sẽ giống nhau Không

có dữ liệu được chia sẻ giữa các DB Server Nodes, ở đây các file DB thực sự sẽ được chứa trong SAN Kiến trúc này được hỗ trợ một cách tự nhiên bởi hầu hết các RDBMs hoặc các phần mềm của hang thứ 3

Một vấn đề nữa ở đây là phải chọn cơ chế sao bản (replication) phù hợp, vì các DB sẽ chứa cùng 1 bản sao hoàn chỉnh của cơ sở dữ liệu Có rất nhiều lựa chọn

để tạo sao bản đó là lựa chọn giữa phương pháp Master – Slave và Multi – Master, đồng bộ hay không đồng bộ và tạo sao bản ở mức nào của dữ liệu

Trong phương pháp master – slave, các yêu cầu đọc sẽ được gửi tới một master, và sau đó sẽ được sao ra ở các slave DB, thêm nữa, việc tạo sao bản có thể

sẽ bị lặp (cascaded) Tuy vậy phương pháp này dễ cài đặt và không đòi hỏi phải quản lý xung đột Với trường hợp Multi – Master, các lệnh đọc sẽ được gửi đến cho nhiều master, sau đó nó sẽ được sao ra ở các master khác cũng như các slave Phương pháp này sẽ đòi hỏi nhà quản trị phải quản lý xung đột, và rất dễ xảy ra hiện tượng deadlock (khi mà dữ liệu được sửa ở nhiều nơi cùng một lúc)

Giữa phương pháp đồng bộ và không đồng bộ Phương pháp không đồng bộ được đảm bảo nhưng bản sao không được đồng nhất (out-of-band replication) từ Master đến Slave Master cập nhât DB riêng của nó và hồi đáp trở lại client Việc sao lưu từ Master đến slave xảy ra không đồng bộ, tuy vậy ưu điểm của phương pháp này là khả năng trả về client nhanh Nhưng nhược điểm của nó là dữ liệu slave

bị giới hạn sau Master, nó cũng yêu cầu App phải thay đổi để các critical reads được gửi đến master và cân bằng tải cho các lệnh đọc khác

Phương pháp đồng bộ được đảm bảo, bản sao được đồng nhất từ Master đến Slave Master cập nhập cơ sở dữ liệu riêng của nó và xác nhận tất cả các slave phải cập nhật những dữ liệu riêng của chúng trước khi hối đáp trở lại client, sự hồi đáp này sẽ chậm hơn Slaves sẽ có cũng dữ liệu như của Master trong suốt quá trình Yêu cầu những thay đổi về ứng dụng phải gửi lệnh ghi đến master và cân bằng tải với tất cả lệnh đọc

Cuối cùng là chọn mức dữ liệu để tạo sao bản: tại mức RDBMS hoặc tại mức Driver/DAO Phương án thứ nhất có thể có sẵn trong RDBMS hoặc được hỗ trợ bởi một 3rd party tool, nó có ưu điểm là nhanh và đáng tin cậy Trong trường hợp này, application phải gửi lệnh ghi hoặc các critical reads tới Master, và các lệnh đọc khác

đến bất cứ DB nào khác Phương án thứ hai thường chậm hơn và không đáng tin cậy, trong phương án này, lệnh ghi được thực thi ở tất cả các DB, lệnh đọc được cân bằng tải và các critical reads sẽ được gửi tới Master

2.2.2 Real Application Cluster (Shared storage Cluster)

Lựa chọn thứ hai để cài đặt DBServer theo chiều ngang là Real Application Cluster

Mô hình tổng quát:

H.1.2-6 Real Application Cluster

Trong phương pháp này, các nodes ở DB cùng chia sẻ một phần chung ở SAN, ràng buộc của phương pháp này là file system phải được định dạng là clustered file system (GFS/OFS) Phương pháp này chỉ được cung cấp bởi công ty Oracle do giá thành của nó rất cao Hiện nay chỉ có các doanh nghiệp lớn hoặc các tập đoàn mới triển khai phương pháp này

Tổng hợp lại, dựa theo ưu nhược điểm và kinh nghiệm của các nhà phát triển,

mô hình Database mở rộng nên dùng là:

- Master-Slave replication

- Sao chép không đồng bộ

- Ghi dữ liệu tại DAO layer

H.1.2-7 Mô hình mở rộng database nên dùng

Ưu điểm của phương pháp này là dễ triển khai, chi phí thấp, tuy nhiên tốc độ đọc/ghi dữ liệu không nhanh

2.3 Tổ chức lưu trữ dữ liệu

Một website có hệ thống web-server và database server mạnh mẽ vẫn sẽ bị giới hạn tốc độ truy cập nếu như khả năng lưu trữ và phân bổ dữ liệu của website đó không tốt Một trang web sẽ được cấu thành từ nhiều thành phần khác nhau, bao gồm các thành phần tĩnh và động Để hiện thị được một trang web hoàn chỉnh, cần phải tải hết tất cả các thành phần này về trình duyệt của người dùng Nếu như dữ liệu cần tải về lưu trữ quá xa người dùng, quá trình này sẽ chiếm nhiều thời gian, có thể khiến cho người dùng bỏ luôn việc xem trang web Chẳng hạn khi một người dùng ở Việt Nam muốn xem một video trên youtube.com, nhưng video này lại không có trong máy chủ server của youtube đặt tại Việt Nam, nếu phải tải nó từ server của Mỹ, chắc chắn sẽ mất thời gian và khiến cho quá trình xem video bị giật, gây khó chịu ít nhiều cho người dùng

Để giải quyết vấn đề này, một kỹ thuật thường dùng là CDN (Content delivery network) hay content switching, tư tưởng chính của kỹ thuật này là hướng request thẳng đến server phục vụ nó CDN thực ra có ý nghĩa khá rộng mà các định nghĩa

chuẩn thiên về hướng request đến server gần người dùng nhất, nghĩa là người dùng Việt Nam sẽ được forward đến server Việt Nam Điều này rất có giá trị khi giảm các yêu cầu chạy qua trục backbone chính, đồng thời giảm băng thông đi quốc tế Vậy thì thực hiện điều này như thế nào? Một cách đơn giản nhất là bộ cân bằng tải

sẽ xác định IP của người dùng rồi xác định khu vực và hướng yêu cầu đến server nằm tại data center gần đó nhất

H.1.2-8 Mô hình CDN

Khi một website đã trở nên toàn cầu và có trung tâm dữ liệu (data center) tại nhiêu nơi khác nhau trên thế giới, sẽ xảy ra vấn đề đồng bộ dữ liệu giữa các trung tâm dữ liệu này Cần phải đảm bảo được dữ liệu mà người dùng muốn truy cập đến luôn có trên server, người ta xử lý điều này bằng cách, nếu dữ liệu đó là dữ liệu quan trọng, đơn giản là một video clip có số lượt xem rất cao, nó sẽ được sao lưu đến tất cả các data center trong hệ thống, còn nếu đó là 1 video không được quan tâm lắm, thì nó có thể chỉ được lưu trên server khi mà nó được upload lên Điều này

có nghĩa là nếu một người dùng Việt Nam truy cập vào một video "hot", đầu tiên video này sẽ được chuyển về data center ở VN, và người dùng sẽ đọc ở đây, trong trường hợp ngược lại, yêu cầu của người dùng sẽ có thể được gửi thẳng đến server đang chứa video đó, và dữ liệu sẽ được tải về từ đây cho người dùng

Một vấn đề nữa là khi số lượng truy cập vào website là rất nhiều và đa dạng,

dữ liệu phải liên tục vào ra tại ổ đĩa lưu trữ của website Khác với web application khi băng thông không quá cao, có thể dùng một proxy server đứng trước phân tải, trong trường hợp file sharing hay video sharing, làm như thế sẽ khiến bộ cân bằng tải sẽ trở thành thắt cổ chai (bottle neck) Điều này hoàn toàn dễ hiểu, vì ra vào dữ liệu ra vào tại bộ cân bằng chỉ có giới hạn nhất định, nếu vượt qua giới hạn đó nó sẽ rơi vào tình trạng quá tải

CHƯƠNG II PHƯƠNG PHÁP XÂY DỰNG BỘ CÂN BẰNG TẢI CHO WEB-SERVER

Cân bằng tải web-server là phần quan trọng nhất trong quy trình xây dựng website theo kiến trúc mở rộng Một trang web được cân bằng tải tốt sẽ tránh được tình trạng tắc nghẽn server, luôn trả về yêu cầu của người dùng trong khoảng thời gian ngắn nhất, do đó sẽ khiến cho người dùng hài lòng Có nhiều kỹ thuật để thực hiện cân bằng tải cho server, một trong những kĩ thuật thường được đề cập rộng rãi trên internet là sử dụng DNS (Domain Name System) Là một phần của cân bằng tải toàn cầu, DNS server sẽ chứa thông tin về địa chỉ của rất nhiều host dưới một cái tên host duy nhất Khi người dùng truy cập vào host bằng tên này, DNS sẽ trả về các host theo thứ tự quay vòng, như vậy người dùng khác nhau sẽ truy cập vào các địa chỉ khác nhau dưới cùng một tên Kỹ thuật này được gọi là DNS Round Robin

Tuy nhiên kỹ thuật này chưa cho thấy được tầm quan trọng của bộ cân bằng tải Sẽ

còn rất nhiều vấn đề về năng mở rộng, chống failure, bảo mật…mà sử dụng DNS round robin sẽ không giải quyết được Điều quan trọng nhất trong cân bằng tải server chính là thiết kế và xây dựng bộ cân bằng tải Bộ cân bằng tải này sẽ đứng trước cụm server, nhận yêu cầu từ người dùng, sau đó phân tải vào các server một cách phù hợp Vậy làm cách nào để thiết kế được bộ cân bằng tải này? Các thành phần cần có của một bộ cân bằng tải là gì? Các kỹ thuật cân bằng tải được thể hiện như thế nào? Chúng sẽ được mô tả chi tiết trong chương 2 dưới đây

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 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, 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ộ

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 Cách khắc phục hạn chế trên

là sử dụng kỹ thuật 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 ảnh dưới đây 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 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 dưới đây 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

H.2.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 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

H.2.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 ở 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

H.2.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 dưới đây 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

1.2.2 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 dưới 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 dưới đây 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

H.2.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ẽ dưới đây 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

1.2.3 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ộ 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 cluster 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

1.3 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 Các phương pháp cài đặt cache:

1.3.1 Các phương pháp cài đặt cache:

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

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 dưới, 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

H.2.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

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 dưới đây

H.2.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(Single point of failure), 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 dưới đây, 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