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

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI KHOA CÔNG NGHỆ THÔNG TIN ──────── * ─────── ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC NGÀNH CÔNG NGHỆ THÔNG TIN CÂN BẰNG TẢI CHO CÁC HỆ WEBSERVER LỚN VÀ ĐẢM BẢO SCALABILITY Sinh viên thực hiện : Võ Duy Pho Lớp CNPM - K49 Giáo viên hướng dẫn: TS. Nguyễn Khanh Văn HÀ NỘI 6-2009  PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP 1. Thông tin về sinh viên Họ và tên sinh viên: Võ Duy Pho Điện thoại liên lạc: 0944599926 Email: d.for.vo@gmail.com Lớp: CNPM-K49 Hệ đào tạo: Chính qui Đồ án tốt nghiệp được thực hiện tại: Trường đại học Bách Khoa Hà Nội Thời gian làm ĐATN: Từ ngày 22/02/2009 đến ngày 29/05/2009 2. Mục đích nội dung của ĐATN Tìm hiểu về lý thuyết cân bằng tải cho các hệ thống web server lớn bao gồm nhiều web server được cài đặt ở nhiều nơi khác nhau, tìm hiểu về lý thuyết xây dựng bộ cân bằng tải cho các web server, cài đặt các thuật toán cân bằng tải, khắc phục một số nhược điểm của các thuật toán này. Tìm hiểu các phương án cài đặt và cấu hình các bộ cân bằng tải vào hệ thống web server nhằm đảm bảo được tính mở rộng cao và khả năng chống lỗi. 3. Các nhiệm vụ cụ thể của ĐATN - Tìm hiểu về kiến trúc website với khả năng mở rộng - Tìm hiểu về cân bằng tải cho các hệ thống web-server lớn, các kỹ thuật cân bằng tải server - Tìm hiểu về lý thuyết xây dựng bộ cân bằng tải, cân bằng tải cho server, cân bằng tải cho server toàn cầu và cân bằng tải cho cache - Tìm hiểu và cài đặt một số thuật toán cân bằng tải bằng ngôn ngữ C dựa trên một sản phẩm cân bằng tải mã nguồn mở, đề xuất một số phương pháp cải tiến thuật toán. - Cấu hình và cài đặt các bộ cân bằng tải vào hệ thống theo các kiến trúc khác nhau, đảm bảo được khả năng mở rộng và khả năng chống lỗi của hệ thống. 4. Lời cam đoan của sinh viên: Tôi – Võ Duy Pho - cam kết ĐATN là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của TS Nguyễn Khanh Văn. Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ công trình nào khác. Hà Nội, ngày 25 tháng 5 năm 2009 Tác giả ĐATN Võ Duy Pho 5. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo vệ: Hà Nội, ngày tháng năm Giáo viên hướng dẫn TS. Nguyễn Khanh Văn LỜI CẢM ƠN Trong suốt 5 năm học tại trường đại học Bách Khoa Hà Nội vừa qua, em đã thu nhận được rất nhiều kiến thức bổ ích từ trong sách vở, và quý báu hơn là từ kinh nghiệm, tâm huyết của chính các thầy cô truyền lại. Em xin gửi lời cảm ơn chân thành tới các thầy cô đã tận tình chỉ bảo và giúp đỡ em trong thời gian qua. Đặc biệt, em xin gửi lời cảm ơn sâu sắc nhất tới thầy TS. Nguyễn Khanh Văn đã trực tiếp hướng dẫn và giúp đỡ em hoàn thành đồ án tốt nghiệp này. Em cũng xin gửi lời cảm ơn chân thành tới anh Nguyễn Vũ, các anh tại công ty ERAS Việt Nam và các bạn đã nhiệt tình chia sẻ kinh nghiệm cũng như cung cấp các tài liệu, công cụ giúp em hoàn thành đồ án tốt nghiệp này. Em xin chân thành cảm ơn! TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP 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. 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 webserver 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 webserver. 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. Trong đồ án tốt nghiệp này, người viết luận văn (NVLV) sẽ đưa 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 webserver 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. Phần tiếp 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. ABSTRACT OF THESIS The boost of website services, especially the social network and online video-sharing websites, in recent years causes the number of clients using Internet rapidly increase. These websites are required to have a very powerful server system to match the demand of over hundred millions of clients. An interesting website certainly attracts a lot of users, then the clients go up, that makes servers overload and need to be improved. This process is repeated when there are more and more clients access to server again. This problem raise the question of how to build an website system which have ability to meet the accessing demand of people within long enough time and easily improved if there is necessary. That is scalable web architecture. The most important factor in scalable web architecture is load balancing for web server system. A global website have web servers in many different places. Load balancing for the web server system is how to minimize clients response time without overloading. In the competition between web services, a manager who successfully match users’ demands will become winner. Therefore, load balancing demand is very crucial for the survival of web service industry. There many methods for load balancing but the general point is the necessity of load balancer between clients and web server system. This load balancer receives the requests from clients then directs them to suitable servers base on load distribution algorithms, next it gets the response and returns to clients.  We will present a general view on the problems which need to be solved in the process of webs ever designs with scalable ability. Then, we focus on the theory of load balancing for large server systems, techniques and methods of load balancer in use. We also mention the architecture and necessary factors for a load balancer, load distribution algorithms which have been used globally, methods of installing a load balancer into system for matching the demands as well as the scalable capability. The next part will introduce some specific load balancing algorithms base on an open source load balancer and improvements for these. The final part will provide a possible direction for building a completely independent load balancer which implements improved load distribution algorithms in order to apply in operating websites. MỤC LỤC DANH MỤC CÁC HÌNH STT Tên hình Trang H 1.2-1 So sánh scale out và scale up 15 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 19 H 1.2-8 Ví dụ về mô hình CDN 21 H 1.2-9 Simple Cache 22 H 2.1-1 Cách làm việc của cookie user=1 27 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 32 H 2.1-8 Bộ cân bằng tải hoạt động như một forward DNS proxy 33 H 2.1-9 Sự kết hợp GSLB và SLB trong bộ cân bằng tải 34 H 2.1-10 Cài đặt cache ở trình duyêt của người dùng 38 H 2.1-11 Cài đặt cache như một transparent proxy 38 H 2.1-12 Cân bằng tải cho transparent-proxy cache 40 H 2.1-13 Cài đặt cache như mọt reverse-proxy 40 H 2.1-14 Bộ cân bằng tải cho Reverse proxy caches 41 H 2.1-15 Transparent-reverse proxy caches 42 H 2.1-16 Phương pháp hash buckets dùng trong caching 44 H 2.1-17 Ví dụ về luật giúp bỏ qua các ngữ cảnh động 46 H 2.1-18 Cân bằng tải sử dụng phần cứng 47 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 57 H 3.1-2 Luồng dữ liệu trong mô hình đơn giản 58 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 59 H 3.1-4 Luồng dữ liệu trong mô hình 2 bộ cân bằng tải với keepalived 61 H 3.3-1 Cấu hình firewall cho CentOS 70 H 3.3-2 Cấu hình firewall cho CentOS (tiếp) 70 H 3.3-3 Kiểm tra thông số server trong HAProxy 74 H 3.3-4 Thông số các server của website www.tamtay.vn sử dụng HaProxy 75 Hình vẽ được đánh theo định dạng: H [Chương].[Mục lớn] [Số thứ tự] DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ Authorita-tive DNS Authoritative Domain Name Server Một website sẽ lưu thông tin về tên của nó trong nhiều server tên. Đây là server tên có thẩm quyền cao nhất Client Khách hàng, người truy cập vào website nói chung Cluster Dùng để chỉ một cụm máy chủ trong mạng LAN 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ó. Forward-proxy Proxy bên phía client, dùng để tăng tốc client, client phải chỉ đến proxy này để truy cập internet Gateway Khá giống proxy, tuy nhiên chỉ có nhiệm vụ tạo kết nối giữa người dùng và server. GSLB Global Server Load Balancing Cân bằng tải cho các máy server được cài đặt ở khắp nơi trên thế giới HTTP Hypertext Transfer Protocal Giao thức truyền tải siêu văn bản, được sử dụng trong WWW LB Load balancing Cân bằng tải: phân phối tải giữa các server nhằm đảm bảo sự cân bằng giữa chúng LBer Load Balancer Bộ cân bằng tải: thiết bị phần cứng hoặc phần mềm dùng để thực thi hoạt động cân bằng tải LC Least connections Thuật toán phân tải cho các server dựa trên số kết nối hiện tại của chúng Local DNS Local Domain Name Server Server tên nằm trong mạng LAN của client, trình duyệt của client sử dụng local DNS để liên lạc với Domain Name System 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 Server Máy phục vụ, chứa các thông tin, ứng dụng cho phép người dùng truy cập vào SLB Server Load Balancing Cân bằng tải cho các máy server Socket Sự kết hợp giữa địa chỉ IP và cổng nhằm xác định đích của một ứng dụng đang chạy trên server SPOF Single point of failure Một node trong hệ thống mà nếu nó bị “chết” thì toàn bộ hệ thống sẽ bị tê liệt 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 Transparent-proxy Proxy bên phía client, hoạt động “trong suốt” với người dùng WWW World Wide Web Mạng máy tính toàn cầu ĐẶT VẤN ĐỀ Tính cấp thiết của đề tài Sự phát triển của ngành dịch vụ web khiến cho số lượng người truy cập vào các website ngày càng tăng mạnh, đặc biệt là các mạng xã hội ảo hoặc website chia sẻ video trực tuyến. Các website này không chỉ cho phép người dùng trao đổi và chia sẻ thông tin, giao lưu và kết bạn mà còn cho phép người dùng lưu trữ tài liệu, tìm kiếm bạn bè, người thân, hay thậm chí cả đối tác kinh doanh. Mặc dù chỉ mới bắt đầu phát triển trong vòng 5 năm trở lại đây nhưng mạng xã hội và các trang chia sẻ video trực tuyến đã có cố lượng người dùng lên đến con số hàng trăm triệu và vẫn đang tăng với tốc độ chóng mặt. Với mạng xã hội, người dùng có thể chat, email, voice chat, chia sẻ file, viết nhật ký cá nhân (blog) và cùng nhau bàn luận về những vấn đề mà họ cùng quan tâm. Thêm nữa, người dùng có thể thông qua mạng tìm kiếm bạn bè hay đối tác theo tên (tên sử dụng hoặc email), sở thích cá nhân (như thể thao, phim ảnh, ca nhạc) hoặc lĩnh vực quan tâm (công nghệ, điện ảnh, kinh doanh…). Chính những tính năng đó làm cho người dùng tìm đến các mạng xã hội ngày càng nhiều hơn và thời gian hàng ngày họ dành cho nó cũng tăng lên. Có thể kể ra hàng loạt các mạng xã hội đang có số lượng người dùng lớn như MySpace, Facebook, Hi5, Friendster, LinkdeIn…Theo số liệu cập nhập tháng 1/2009, myspace có 255 triệu tài khoản đăng ký và đứng thứ 9 trong bảng xếp hạng các website hàng đầu thế giới theo Alexa, FaceBook có 177 triệu tài khoản và đứng thứ 4. Các website mạng xã hội khác như Hi5, Friendster…đều có số lượng tài khoản đã đăng ký trên 50 triệu. Với các website chia sẻ video trực tuyến cũng vậy, sự phát triển của công nghệ kỹ thuật số giúp cho mọi người có thể dễ dàng tạo ra các đoạn clip vui nhộn, hay các video gia đình, họ muốn lưu trữ, muốn gửi cho bạn bè khắp nơi, vì vậy họ tìm đến các website chia sẻ video trực tuyến. www.youtube.com, website chia sẻ video lớn nhất hiện nay, có trên 6 tỉ video và 100 triệu video được xem mỗi ngày. Youtube đứng thứ 3 trong bảng xếp hạng thông lượng website của Alexa. Sự cạnh tranh giữa các website mạng xã hội và các trang chia sẻ video trực tuyến là không thể tránh khỏi, bất cứ một nhà quản trị nào cũng muốn tăng số lượng người dùng cũng như muốn website của mình ngày càng nổi tiếng. Để làm được điều đó, ngoài nội dung hấp dẫn và phong phú, website cần phải đáp ứng được nhu cầu của người dùng một cách tốt nhất. Với 100 triệu video được xem mỗi ngày, tính trung bình mỗi giây có gần 1200 video được xem trên Youtube, con số này đòi hỏi Youtube phải có một hệ thống server mạnh mẽ và linh hoạt. Một website với số lượng truy cập ngày càng tăng sẽ khiến máy chủ của website đó không đáp ứng được hết nhu cầu của người dùng và bị quá tải. Yêu cầu đặt ra đối với người quản trị website là cần phải giải quyết vấn đề quá tải này, làm sao để bất cứ người dùng nào truy cập vào website đều được phục vụ một cách nhanh nhất. Để làm được điều đó, người quản trị phải nâng cấp hệ thống server. Nghĩa là, cần phải tăng cấu hình máy server hoặc tăng số lượng server, đó chính là một trong hai phương án mở rộng server: mở rộng theo chiều dọc (scaling up) và mở rộng theo chiều ngang (scaling out). Mở rộng theo chiều dọc nghĩa là nâng cấp một server có cấu hình ngày càng mạnh hơn tùy theo nhu cầu của người dùng, phương pháp này khá tốt trong trường hợp số lượng người dùng không nhiều tuy nhiên giá thành của nó đắt và khả năng mở rộng kém. Mở rộng theo chiều ngang nghĩa là sử dụng một hệ thống nhiều server nhỏ với chi phí thấp hơn và mỗi server phục vụ một lượng người dùng nhất định, phương pháp này có khả năng mở rộng tốt (lắp thêm server khi cần) và hoạt động khá hiệu quả. Với những trang có số lượng người truy cập nhiều và tỉ lệ truy cập cao, các nhà quản trị hệ thống thường lựa chọn phương án thứ hai – mở rộng theo chiều ngang. Nâng cấp server cũng giống như là một hoạt động có chu kì trong vòng đời của hệ thống. Khi hệ thống server không đáp ứng được nhu cầu của người dùng, nó sẽ được nâng cấp. Sau khi nâng cấp, tốc độ cải thiện sẽ kiến người tin tưởng vào khả năng phục vụ của website, số lượng người dùng lại tăng lên, hệ thống server lại không đáp ứng được nhu cầu của người dùng và lại cần nâng cấp…Vòng luẩn quẩn đó khiến các nhà quản trị mong muốn tìm kiếm một giải pháp nào đó, mà website của họ có thể hoạt động ổn định trong một thời gian dài, và dễ dàng nâng cấp khi cần thiết. Đó chính là phương án mà hầu hết các mạng xã hội và các trang chia sẻ video trực tuyến như myspace, google video…đã chọn - sử dụng kiến trúc web với khả năng mở rộng (scalable web architecture). Cách tiếp cận này cho phép nhà quản trị tăng hiệu năng của hệ thống, cho khả năng mở rộng và khả năng có sẵn cao, đáp ứng được yêu cầu trong suốt đối với người dùng (user-transparent), tuy nhiên có rất nhiều thách thức cần phải vượt qua để xây dựng được các chức năng của một hệ thống website trên nền trình duyệt web và HTTP. Để xây dựng được một website theo kiến trúc này, nhà quản trị website phải thiết kế một cách “nhịp nhàng” các thành phần của hệ thống, các thành phần chính bao gồm xây dựng hệ thống web-server, xây dựng hệ thống database-server, quản lý session, thiết kế bộ cache cho hầu hết các thành phần của hệ thống. Một website xây dựng theo kiến trúc này khi muốn nâng cấp mở rộng sẽ theo chiều hướng scaling out, nghĩa là hệ thống sẽ có nhiều web-server và nhiều database-server kết nối với nhau, khi cần mở rộng sẽ lắp đặt thêm các server mới. Khi hệ thống có nhiều server thì vấn đề đặt ra là khi một người dùng truy cập vào website, yêu cầu của người dùng đó sẽ được chuyển đến server nào xử lý, lấy dữ liệu ở database-sever nào? Làm thế nào để các server trong hệ thống nhận được lượng tải phù hợp với server đó, đảm bảo cho không server nào bị quá tải? Làm sao để hệ thống có thể đáp ứng được số lượng người dùng cao nhất? Đó chính là bài toán cân bằng tải (Load Balancing – LB) cho các server, cũng chính là phần quan trọng nhất trong việc giữ cho hệ thống hoạt động ổn định, là nhân tố quyết định đến khả năng đáp ứng người dùng của hệ thống. Thuật ngữ cân bằng tải không những chỉ dùng cho server, mà còn dùng trong hầu hết các thành phần còn lại của kiến trúc web với khả năng mở rộng, đó là cân bằng tải cho database, cân bằng tải cho cache, cân bằng tải cho firewall…Một website được cân bằng tải tốt sẽ tận dụng được cao nhất nguồn lực sẵn có. Chẳng hạn như website với 1 web-server có thể đáp ứng được cho 1000 người dùng cùng lúc, khi nâng cấp lên 4 servers, nếu cân bằng tải tốt sẽ có khả năng đáp ứng cho 4000 người cùng lúc, ngược lại sẽ chỉ có thể đáp ứng được 2000 người, thậm chí còn ít hơn số đó. Một trang web được xử lý tốt vấn đề cân bằng tải sẽ đáp ứng được người dùng một cách tốt nhất và có khả năng mở rộng cao. Để cân bằng tải cho cụm server, cần phải xây dựng các bộ cân bằng tải (Load Balancer). Các bộ cân bằng tải này được cài đặt ở giữa người dùng và hệ thống server, nhận yêu cầu từ phía người dùng, sau đó chuyển chúng đến web-server phù hợp. Bộ cân bằng tải lúc đó đóng vai trò là web-server duy nhất đối với tất cả mọi người dùng, chỉ cần truy cập đến địa chỉ chứa bộ cân bằng tải, người dùng sẽ nhận được thông tin mình cần, không cần biết phía sau đó hệ thống có bao nhiêu server, cũng không cần nhớ địa chỉ của các server này. Vậy làm cách nào để xây dựng được một bộ cân bằng tải hoạt động hiệu quả, nhằm đảm bảo tải được phân phối một cách cân đối giữa các web-server? Một bộ cân bằng tải cần đáp ứng được hai yêu cầu chính. Thứ nhất, cũng là quan trọng nhất, đó là khả năng xử lý và chuyển yêu cầu của người dùng đến server phù hợp, để giải quyết vấn đề này, cần phải xây dựng một thuật toán phân tải hoạt động “mềm dẻo” trên nhiều yếu tố khác nhau. Thứ hai, nó cần phải kiểm tra và cập nhập được các thông số kỹ thuật cũng như trạng thái của các server, kiểm tra xem server nào đang hoạt động, server nào đang tạm nghỉ, server nào vừa được thêm vào cụm server, hay vừa được đưa ra (để sửa chữa, bảo trì…) trong hệ thống, kiểm tra sự thay đổi trong khả năng phục vụ (chẳng hạn số kết nối lớn nhất) hay trọng số của các server. Giải quyết tốt hai bài toán trên sẽ cho ra một bộ cân bằng tải hoạt động hiệu quả và ổn định. Các bộ cân bằng tải thường được chia ra làm hai loại: loại hoạt động dựa trên phần cứng và hoạt động dựa trên phần mềm. Hoạt động dựa trên phần cứng nghĩa là nó sử dụng một thiết bị phần cứng hoạt động ở tầng mạng (network layer) và tầng giao vận (transport layer) của mô hình OSI, thiết bị này được thiết kế trên mô hình chuyển mạch và nó phân bố tải rất hiệu quả. Tuy nhiên giá của những thiết bị phân tải này thường rất đắt, vượt ngoài khả năng của những nhà phát triển hệ thống vừa và nhỏ. Bộ cân bằng tải phần mềm là một phần mềm được cài đặt trên một máy riêng biệt hoặc trên máy server, lưu giữ địa chỉ của các máy server trong hệ thống để phân tải. Bộ cân bằng tải phần mềm có khả năng phân tải kém hơn các thiết bị phần cứng, tuy nhiên giá thành của nó rẻ hơn và phù hợp với các nhà phát triển hệ thống vừa và nhỏ, thậm chí còn có rất nhiều phần mềm mã nguồn mở hoạt động rất tốt. Một phần mềm hoạt động hiệu quả cũng có khả năng phân tải tương đương với các phần cứng có giá thành trung bình. Hơn nữa, dù có sử dụng phần cứng, các website vẫn cần phần mềm để hỗ trợ phân tải. Điểm mẫu chốt trong hoạt động của các bộ cân bằng tải là thuật toán phân phối tải. Không có một thuật toán nào thực sự phù hợp cho mọi môi trường. Với những điều kiện hệ thống nhất định, yêu cầu đặt ra là phải chọn thuật toán nào cho phù hợp. Các thuật toán phân tải đang được sử dụng thường được chia ra làm hai loại chính, đó là thuật toán phân tải tĩnh và thuật toán phân tải động. Các thuật toán phân tải tĩnh dễ thiết kế, hoạt động đơn giản nhưng hiệu suất không cao. Chúng được gọi là thuật toán tĩnh vì phương pháp chọn server để gửi yêu cầu tiếp theo được dựa trên các yếu tố tĩnh, không thay đổi. Ngược lại, các thuật toán phân tải động dựa trên các nhân tố động, thay đổi liên tục, do đó các thuật toán động này hoạt động linh hoạt hơn và đáp ứng yêu cầu phân tải một cách tốt hơn. Tuy vậy không có một thuật toán nào có thể đáp ứng được trong mọi trường hợp. Cần phải có một sự kết hợp mềm dẻo dựa các thuật toán này mới có thể xây dựng được một bộ cân bằng tải hoạt động tốt. Việc nghiên cứu các thuật toán phân tải mềm dẻo sẽ giúp cho các bộ cân bằng tải hoạt động hiệu quả hơn và đáp ứng được nhu cầu phân tải cao hơn. Với sự bùng nổ của dịch vụ web, số lượng website ngày càng nhiều đem đến cho người dùng rất nhiều sự lựa chọn. Để tồn tại và phát triển, các website phải giữ được người dùng hiện tại của mình và lôi kéo thêm được nhiều người dùng mới. Để làm được điều này, các nhà quản trị hệ thống phải đảm bảo cho hệ thống của mình hoạt động tốt nhất, do đó yêu cầu lắp đặt thêm nhiều server mới cũng như yêu cầu cân bằng tải sẽ cho các server thực sự là nhu cầu cấp thiết. Đứng trước sự cạnh tranh về giá thành, việc phát triển và xây dựng các phần mềm cân bằng tải trở nên vô cùng hữu ích. Đứng trước yêu cầu đó, NVLV quyết định tìm hiểu về nguyên lý hoạt động cũng như các thuật toán cân bằng tải nhằm xây dựng nên một nền tảng vững chắc về chủ đề này, từ đó góp phần thúc đẩy quá trình xây dựng nên một bộ cân bằng tải hoạt động hiệu quả có khả năng đáp ứng nhu cầu cho các website đang hoạt động trong và ngoài nước. Mục đích nghiên cứu Nghiên cứu tổng quan về kiến trúc web với khả năng mở rộng, tìm hiểu lý thuyết chung về cân bằng tải server, cân bằng tải database, cân bằng tải cho cache và quản lý session. Tìm hiểu các kỹ thuật cân bằng tải cho web server, lý thuyết xây dựng bộ cân bằng tải cho web server và điểm mạnh yếu của các thuật toán phân tải cho bộ cân bằng tải. Xây dựng và cài đặt thử nghiệm một số thuật toán cân bằng tải cơ bản, thực thi một số thuật toán cân bằng tải tĩnh và cân bằng tải động. Tìm hiểu cách cấu hình các bộ cân bằng tải cùng với web server theo các điều kiện khác nhau, nhằm đáp ứng được nhu cầu từng hệ thống web riêng biệt. Kết cấu luận văn Trong khuôn khổ báo cáo này, NVLV xin trình bày kết quả tìm hiểu được cũng như cài đặt thử nghiệm một số thuật toán cân bằng tải nhất định. Do nguồn lực và thời gian có hạn, nên NVLV chưa thực sự xây dựng được một phần mềm cân bằng tải hoạt động thực sự mà chỉ có thể cài đặt thử nghiệm một số thuật toán cân bằng tải dựa trên một bộ cân bằng tải có sẵn. Để giúp tiếp cận vấn đề một cách nhanh nhất, báo cáo này được trình bày với nhiều hình ảnh sinh động. Nội dung của báo cáo chia làm 4 chương như sau: Chương 1: Tổng quan về kiến trúc web với khả năng mở rộng. Chương 2: Kỹ thuật cân bằng tải ở web-server, lý thuyết xây dựng bộ cân bằng tải cho webserver và các thuật toán phân tải cho bộ cân bằng tải. Chương 3: Trình bày về môi trường phát triển, các phương án cài đặt bộ cân bằng tải vào mạng, kết quả cài đặt thuật toán, một số cải tiến cho các thuật toán cân bằng tải. Cách cài đặt và cấu hình bộ cân bằng tải cho một hệ thống webserver cụ thể Chương 4: Kết luận và định hướng phát triển. CHƯƠNG 1 KIẾN TRÚC WEB VỚI KHẢ NĂNG MỞ RỘNG (SCALABLE WEB ARCHITECTURE) Các khái niệm về kiến trúc 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 NVLV[[] Người viết luận văn ] xin trình về các khái niệm này. Khả năng mở rộng 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. Hiệu năng 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. 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. 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ệ. 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 NVLV 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. 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 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 server đủ 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[[] 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 ] (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ư bandwidth[[] Băng thông: độ rộng của đường truyền internet ] hay 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 phải được nối với nhau như thế nào… đều là những bài toán khó. Bức tranh dưới đây sẽ cho chúng ta thấy ưu và nhược điểm của từng phương pháp: H 1.2-1 So sánh scale out và scale up Và giá thành của 2 phương pháp: H 1.2-2 Bảng so sánh giá thành 2 phương pháp Như vậy, rõ ràng rằng sự lựa chọn 1 server chỉ phù hợp cho các hệ thống đòi hỏi sự ổn định cao, với số lượng người dùng tăng lên hàng năm là không nhiều và có tiềm lực mạnh về kinh tế như các hệ thống chứng khoán, ngân hàng… còn đối với các mạng xã hội hay các trang chia sẻ video trực tuyến thì sự lựa chọn nhiều server họat động song song là hiệu quả. Khi sử dụng phương pháp scale out, yêu cầu từ phía người dùng sẽ được chuyển vào một trong các servers này xử lý, từ đó, xuất hiện bài toán cân bằng tải (load balancing – LB) cho cluster này. Nhà phát triển 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 request 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 Chi tiết về nguyên lý, kỹ thuật và các phương pháp cân bằng tải server cũng như thiết kế bộ cân bằng tải sẽ được làm rõ trong chương 2 của đồ án này. Mở rộng Database server 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) Shared 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 3rd party. 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. Real Application Cluster Lựa chọn thứ hai để cài đặt DBServer theo chiều ngang là Real Application Cluster 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 Mô hình khuyên dùng 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 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. Một ví dụ thấy rõ nhất điều này, trước khi www.youtube.com đặt server ở Việt Nam, người dùng ở Việt Nam xem các video ở Youtube.com rất chậm, thường phải chờ tải từng phần, sự ngắt quãng này khiến người dùng không hài lòng và không muốn quay trở lại với website. Nhưng sau khi youtube đặt server ở Việt Nam, tốc độ đường truyền đã được cải thiện đáng kể, người dùng Việt Nam không còn bị giật khi xem video, chính vì vậy mà youtube đã vượt hẳn lên so với trang web chi sẻ video trực tuyến của Việt Nam là www.clip.vn. Một ví dụ rõ hơn được mô tả trong hình 2.2-5. Khi người dùng truy cập vào website www.discovery.com (1), origin server đầu tiên sẽ trả về trang chỉ mục index.html (2). Sau đó nó sẽ chuyển hướng yêu cầu đến nhà cung cấp CDN (ở đây là Akamai) (3), nhà cung cấp CDN sẽ dùng thuật toán lựa chọn của họ để tìm kiếm server sao bản gần với người dùng nhất (4) và sau đó trả về dữ liệu cho người dùng từ server này (5). H 1.2-8 Ví dụ về 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 dtrê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 và bị “treo”. Để giải quyết vấn đề này, cần phải có các kỹ thuật partitioning các ổ đĩa lưu trữ một cách hiệu quả, các kỹ thuật này sẽ giúp cho việc vào ra tại các thiết bị lưu trữ được giảm một cách tối ưu. Trong khuôn khổ báo cáo này, NVLV xin không đề cập chi tiết đến cách thức thực hiện điều này, xin dành cho một nghiên cứu sau. Một phương pháp nữa là sử dụng bộ đệm cache một cách hiệu quả, sẽ nói đến trong phần sau của chương này. Cân bằng tải cho Cache Như chúng ta đã biết, khái niệm cache trong công nghệ thông tin nhằm để chỉ kỹ thuật lưu trữ dữ liệu được truy xuất thường xuyên và sử dụng lại liên tục. Khi người dùng thường xuyên truy cập vào một vùng dữ liệu nào đó, thay vì gọi lại phần dữ liệu đó từ database, chương trình ứng dụng sẽ đẩy dữ liệu đó vào một vùng nhớ tạm có khả năng truy xuất nhanh, và gọi ra từ đó. Phương pháp này sẽ giảm thiểu tối đã các luồng dữ liệu chạy trong hệ thống, chẳng hạn như giảm thiểu số lần truy xuất vào database (trong trường hợp caching database). Caching là một phần vô cùng quan trọng trong tất cả các hệ thống, nó là yếu tố quyết định trong việc tăng tốc độ hoạt động của hệ thống. Trong phần này, NVLV sẽ giới thiệu về các khái niệm cơ bản của caching, cache ở phía người dùng và cache ở phía web-server, các phương án cài đặt cache giữa người dùng và web-server và một số ưu nhược điểm của chúng. Chi tiết về cài đặt và các thuật toán cài đặt cache sẽ được trình bày trong chương 3 của đồ án này, trong thiết kế của bộ cân bằng tải. Định nghĩa Trong các hệ thống web, bộ nhớ cache lưu trữ các Web Content ( sự kết hợp giữa text, các hình động hoặc audio) nhằm giúp tiết kiệm băng thông cũng như tăng tốc độ truy xuất web. Chúng ta hãy xem ví dụ dưới đây. Khi người dùng A lần đầu tiên gõ vào trong trình duyệt web của họ bộ nhớ web cache sẽ nhận được yêu cầu này. Vì đây là lần đầu người dùng A truy nhập và hệ thống, nên sẽ chưa có trang này trong cache, bộ nhớ cache sẽ tìm kiếm trang này từ server gốc và lưu giữ trang này trong bộ nhớ local, chẳng hạn như RAM hoặc đĩa, sau đó nó sẽ trả về trang này cho người dùng. Sau đó, người dùng B truy xuất vào địa chỉ này, vì nó đã tồn tại trong cache, nên nó sẽ ngay lập tức trả về trang này cho người dùng B. Vì vậy, người dùng B sẽ nhận được trả lời nhanh hơn người dùng A và người phát triển web cũng sẽ tiết kiệm được băng thông khi không phải truy cập vào server gốc để lấy trang này. H 1.2-9 Simple Cache Vì một trang web được cấu thành từ rất nhiều đối tượng khác nhau, chẳng hạn như các đoạn text, các file hình ảnh, audio, các đoạn flash…do đó, khi có yêu cầu, Web Server sẽ trả về tất cả các URLs cho tất cả các đối tượng, sau đó trình duyệt sẽ nhúng chúng vào với nhau để hiển thị ra trang hoàn chỉnh. Do bộ nhớ cache trả về dữ liệu cho người dùng cuối thay vì web server, nên nó được gọi là proxy server hoặc proxy cache. Nếu như dữ liệu cần trả về cho một yêu cầu từ phía người dùng có trong cache, chúng ta gọi là cache hit, trong trường hợp ngược lại, chúng ta có khái nhiệm cache miss. Cache hit-ratio là giá trị được tính bằng phần trăm giữa cache hit và tổng số requests mà cache nhận được, và rõ ràng, nếu tỉ lệ này càng cao, thời gian đáp ứng càng ngắn và càng tiết kiệm được nhiều băng thông hơn. Các loại Caches và cách cài đặt Như đã đề cập ở trên, bộ nhớ cache có thể được dùng để tăng tốc độ đáp ứng yêu cầu của người dùng hoặc dùng để tăng hiệu năng của web servers. Dựa trên khả năng của nó, cache được phân thành hai loại: tăng tốc người dùng (client acceleration) và tăng tốc server (server acceleration). Triển vọng của client acceleration cache là khả năng đáp ứng người dùng nhanh hơn và tiết kiệm băng thông mạng. Triển vọng của server acceleration là khả năng luẩn chuyển web content nhanh hơn và giảm số lượng servers cần thiết, vì nguyên lý của server acceleration là dựa trên một tiền đề mà qua đó sử dụng cache là phù hợp hơn servers trong việc phục vụ các ngữ cảnh tĩnh (static content). Web servers sẽ giảm bớt được yêu cầu phục vụ các ngữ cảnh tĩnh (đã được chỉ định cho cache) và tập trung vào phục vụ các ngữ cảnh động (dynamic web content) Dựa trên lý thuyết cơ bản về caching, có 4 cách khác nhau để triển khai và sử dụng cache: Forward Proxy dùng cho tăng tốc client Transparent Proxy dùng cho tăng tốc client Reverse Proxy dùng cho tăng tốc server Transparent Reverse Proxy dùng cho tăng tốc server Nhìn vào tên của 4 loại cache này, chúng ta có thể thấy được chức năng của chúng. Cache được cài đặt như một forward proxy được dùng để tăng tốc truy nhập internet cho client, trong khi đó cache được cài đặt như reverse proxy được dùng để tăng tốc truyền tải dữ liệu của server. Transparent proxy cũng thực thi nhiệm vụ như forward proxy, nhưng nó được cài đặt để người dùng không biết nó tồn tại. Transparent reverse proxy được cài đặt như reverse proxy và hoàn toàn transparent đối với servers. Phương pháp cài đăt và chi tiết các loại cache này sẽ được nói rõ trong chương 3 của đồ án. CHƯƠNG 2 KỸ THUẬT CÂN BẰNG TẢI WEB-SERVER Như đã đề cập ở chương 1, 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. 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. Lý thuyết xây dựng bộ cân bằng tải cho web-servers 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. 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[[] 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 ], 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. 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[[] 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 ], 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. 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 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. 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 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ương pháp này quan tâm đến tải hiện thời đang có của cache, từ đó tính toán nhằm đưa ra cache phù hợp nhất để nhận yêu cầu, tuy nhiên nó sẽ không tránh được sẽ bị lặp dữ liệu trong các bộ cache. Có 2 phương pháp thực hiện cân bằng tải stateful, đó là Hash Buckets và URL Hashing. + Hash Buckets Phương pháp này sẽ giúp chúng ta loại bỏ được các điểm yếu của simple hashing. Hàm băm sẽ vẫn tính toán một giá trị băm dựa trên một số các nhân tố chẳng hạn như giá trị địa chỉ đích. Điểm khác ở đây là thuật toán băm sẽ được dùng để tính ra một giá trị băm giữa (0 – H), trong đó H là số xô băm (buckets). Nếu như như H = 255, như vậy sẽ cần một giá trị 1 bytes giữa (0 – 255), chúng ta sẽ có simple hashing. Nếu như giá trị H càng cao, thuật toán phân tải sẽ càng chính xác, H =1024 sẽ hoạt động tốt hơn H = 255. Khi khởi tạo, các buckets không được chỉ định cache, giống như trong hình 2.1-16. Tại thời điểm nhận được kết nối đầu tiên (TCP SYN packet), giá trị hash sẽ rơi vào một bucket chưa được chỉ định, bộ cân bằng tải sẽ sử dụng một trong các thuật toán cân bằng tải để chỉ định một cache cho server này, chẳng hạn như sử dụng thuật toán “least connections” chỉ định cache đang chịu tải nhẹ nhất trong cụm cache cho bucket (bucket 4 à cache c3). Tất cả các phiên và các gói dữ liệu sau này có giá trị hash 4 này sẽ đều được chuyển đến cache c3. Phương pháp này đòi hỏi bộ cân bằng tải phải theo dõi được tải của các cache để chuyển có thể chỉ định chúng cho bucket nào tại thời nhận đươc một giá trị băm mới. H 2.1-16 Phương pháp hash buckets dùng trong caching Nếu như một cache bị hỏng, hoặc được gỡ ra khỏi cụm để bảo trì, các hash bucket đã được chỉ định cho cache này sẽ được chỉ định lại, trong khi đó các cache khác sẽ không bị ảnh hưởng. Bộ cân bằng tải sẽ chỉ định cache mới cho các hash bucket này dựa trên tải của các cache tại thời điểm đó. Kết quả là tải của cache bị hỏng sẽ được chia ra cho các cache đang hoạt động mà không ảnh hưởng đến hoạt động của toàn bộ hệ thống. Vì hàm băm hoạt động dựa trên địa chỉ IP và các cổng nên phương pháp này chỉ có thể giảm thiểu được việc lặp lại dữ liệu ở một phần nào đó. Tuy nhiên phương pháp này sẽ giúp phân tải tốt hơn simple hashing. Trong simple hashing, nếu một cache không hoạt động, bộ cân bằng tải cần phải phân chia tải ở cache này vào trong các cache còn lại, nó sẽ làm ngắt quãng toàn bộ việc phân tải ở tất cả các cache. Trong khi đó sử dụng hash buckets, bộ cân bằng tải chỉ cần chỉ định lại cache cho những bucket đã được chỉ định cho cache không hoạt động, vì vậy không làm ngắt quãng hoạt động của các bucket khác. + URL Hashing Phương pháp này nhằm loại bỏ hoàn toàn việc lặp dữ liệu ở trong các cache, tất cả các hàm băm đều sẽ sử dụng URL của đối tượng được yêu cầu. Điều này sẽ đảm bảo là tất cả các yêu cầu “con” của một yêu cầu ban đầu sẽ được chuyển đến cùng một cache, do đó sẽ tăng tỉ lệ cache-hit và tăng hiệu năng hoạt động của cache. Tại thời điểm ban đầu, khi người dùng khởi tạo kết nối TCP với một gói TCP SYN (gói dữ liệu được gửi đi để cho biết kết nối đã được thiết lập), bộ cân bằng tải chưa có URL của yêu cầu để thực hiện hàm băm. Do đó bộ cân bằng tải gửi đi một tín hiệu SYN ACK (tín hiệu cập nhập người dùng với những thay đổi của kích thước cửa sổ khi có rất nhiều gói dữ liệu nhận được không được trả lời) và chờ tín hiệu ACK trả về từ phía người dùng. Khi người dùng đã thiết lập xong kết nối, trình duyệt của họ sẽ gửi lệnh HTTP GET có chứa thông tin về URL. Khi đó bộ cân bằng tải sẽ sử dụng URL này để thực hiện hàm băm và chọn cache thích hợp. Đôi khi URL rất dài và bao gồm rất nhiều gói, khi đó bộ cân bằng tải cần phải dùng bộ nhớ đệm chứa các gói cho đến khi đạt được đầy đủ số gói để lấy được URL hoàn chỉnh và thực hiện hàm băm. Tuy vậy, bộ cân bằng tải cũng có thể chỉ cần hạn chế ở một số packet đầu tiên và thực hiện hằm băm trên đó. URL hashing có thể được dùng với hash-buckets nhằm đạt được khả năng cân bằng tải cao. URL hashing sẽ khắc phục được nhược điểm của hash-buckets và ngược lại. Nhận biết ngữ cảnh trong cache (Content-aware cache switching) Cache được thiết kế để phục vụ cho các ngữ cảnh tĩnh. Trong một trang web, có các ngữ cảnh tĩnh và các ngữ cảnh động. Các đối ngữ cảnh tĩnh là các đối tượng không thay đổi như logo, màu nền, các đoạn text hay các liên kết xuất hiện trên trang web, trong khi đó các ngữ cảnh động bao gồm các đối tượng thường xuyên thay đổi, hoặc phải cập nhập liên tục trong một khoảng thời gian ngắn, chẳng hạn như đồng hồ hệ thống trên trang web, hoặc các tin tức mới nhất (lastest headlines) – cập nhập cứ mỗi 30 phút. Cache không thể sử dụng với các đối tượng cập nhập liên tục như đồng hồ hệ thống, tuy nhiên có thể sử dụng với các đối tượng như lastest headlines. Sẽ có một biến thời gian là Time To Live (TTL) dành riêng cho các biến này, nếu cache thấy biến TTL đã hết hạn, nó sẽ lấy dữ liệu mới từ server trả về cho người dùng. Như vậy, bộ cân bằng tải cần phải có một cơ chế để bỏ qua những ngữ cảnh động trong các yêu cầu. Nếu yêu cầu chứa các đối tượng động, nó cần phải cho yêu cầu này đi qua và vào thẳng server gốc, ngược lại nó sẽ cho vào cache để xử lý. Bộ cân bằng tải cần phải đặt ra các luật, ví dụ như trong hình 2.4-9, các URL có đuôi là .asp sẽ được xem như các ngữ cảnh động, bộ cân bằng tải sẽ chuyển các request này trực tiếp vào server. Phương pháp này thường được gọi là content-aware cache switching H 2.1-17: Ví dụ về luật giúp bỏ qua các ngữ cảnh động Phương pháp này còn được sử dụng cho các mục đích khác. Chẳng hạn như chúng ta có thể tạo ra những luật về địa chỉ IP, yêu cầu bộ cân bằng tải không sử dụng cache cho các host nào đó, từ đó có thể điều khiển được host nào được cache và host nào không. Chúng ta cũng có thể chia cache thành các nhóm, mỗi nhóm phục vụ cho một ngữ cảnh hoặc một trang khác nhau. Chẳng hạn như nhà cung cấp dịch vụ có thể dùng các cache có tốc độ cao chỉ để phục vụ cho các khách hàng doanh nghiệp có nhu cầu. Cân bằng tải sử dụng phần cứng và cân bằng tải phần mềm Cân bằng tải sử dụng phần cứng Bộ cân bằng tải bằng phần cứng 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 toàn bộ các máy tính trong cluster sẽ chỉ được xem như là một máy duy nhất đối với thế giới bên ngoài. Bộ cân bằng tải sử dụng phần cứng thường hoạt động ở tầng mạng và hoạt động dựa trên sự định tuyến, sử dụng một trong các phương pháp: Định tuyến trực tiếp (direct routing), tunnelling, IP address translation (NAT) 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 server đã chết này, vì tất cả các máy server 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ề, client 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ì người dùng sẽ xử lý với một máy tính đó là bộ cân bằng tải sử dụng phần cứng. H 2.1-18 Cân bằng tải sử dụng phần cứng Ưu điểm của phương pháp này là: • 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 server 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 bộ cân bằng tải đọ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 công việc. 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. Cân bằng tải sử dụng phần mềm Một bộ cân bằng tải bằng phần cứng giải quyết được vấn đề lost session, nhờ vào cơ chế chuyển đổi dự phòng của nó. Tuy nhiên, cái giá phải trả cho sự lựa chọn này là quá đắt. Một thiết bị Big-IP 6800 của F5 Networks có giá lên tới $49,995, hay thiết bị của Citrix với giá $49,999.00 (Netscaler 9010-ENT Load Balancer ). Điều này là không thể đối với các hệ thống vừa và nhỏ, chính vì vậy mà sự lựa chọn tối ưu hơn ở đây là sử dụng một phần mềm load balancing với giá vừa phải, hay sử dụng các phần mềm load balancing mã nguồn mở. Tuy nhiên, giá của các phần mềm được cung cấp bởi F5 hay Citrix vẫn còn là thách thức lớn đối với các nhà phát triển web, tất nhiên các phần mềm này hoạt động rất hiệu quả và tương thích với nhiều môi trường khác nhau. Với phần mềm do các công ty hay các nhóm nhỏ hơn thì chất lượng sẽ kém đi, chính vì vậy nếu không có $20k để sử dụng một giải pháp của F5 thì người ta thường sẽ chọn các phần mềm mã nguồn mở, sau đó tinh chỉnh cho phù hợp với hệ thống của mình. Có rất nhiều phần mềm như vậy trên thị trường, chằng hạn như HAProxy, Squid…. Giải pháp phần mềm thường sử dụng hai thuật toán chính đó là thuật toán cân bằng tải tĩnh (Static LB - DNS Round Robin) và thuật toán cân bằng tải động (Dynamic LB). Các thuật toán cân bằng tải Thuật toán ngẫu nhiên (random) Trong thuật toán random, tải sẽ được phân một cách ngẫu nhiên vào trong các web-server. Web server được chọn dựa trên một hàm chọn số ngẫu nhiên, sau đó yêu cầu hiện tại từ phía người dùng sẽ được chuyển vào server này. Thuật toán này có thể thực hiện như sau: arrayServer[] == list_of_server(); int n = number_of_active_server; int i = get_random_number(n); proxy ->server = arrayServe[i]; Thuật toán này hầu như không dùng đến trong các bộ cân bằng tải mặc dù nó thường được cài đặt sẵn, nó chỉ thường thấy trong các gói phần mềm lớn mà trong đó cân bằng tải chỉ được đưa ra như một chức năng. Thuật toán Round Robin (RR) RR là thuật toán được dùng thường xuyên nhất trong các hệ thống vừa và nhỏ, có ít đòi hỏi về khả năng mở rộng. Một kết nối mới sẽ được gửi đến server kế tiếp trong cụm server, và cứ quay vòng như vậy. RR làm việc tốt trong mọi cấu hình, nhưng sẽ tốt hơn nếu như các trang thiết bị đang được cân bằng tải khác nhau về tốc độ xử lý, tốt độ kết nối hoặc bộ nhớ. Một cách để thực thi thuật toán này là sử dụng một server_map. Bộ cân bằng tải sẽ được khai báo như một con trỏ proxy, nó sẽ có biến server_map là một mảng các server và biến srv_rr_idx để chỉ định server tiếp theo trong chu kỳ round robin. Sample code: /* Kiểm tra xem có server nào sẵn có không bằng cách kiểm tra kích thước server_map */ if(srv_map_size = 0) return NULL; if (srv_rr_idx > proxy->srv_map_size) /* Nếu đến cuối mảng srv_map, update lại giá trị srv_rr_idx */ srv_rr_idx = 0; int newidx = px->srv_rr_idx; do { srv = proxy ->srv_map[newidx++]; /* Trả về server và update lại giá trị srv_rr_idx */ return srv; proxy->srv_rr_idx = newidx; } while (newidx != px->srv_rr_idx) /* Thực hiện cho đến khi lấy được server tiếp theo */ RR hoạt động tốt khi các server có khả năng xử lý (cấu hình) tương tự nhau, tuy nhiên sẽ có hiện tượng mất cân bằng khi các server có cấu hình khác nhau, hoặc sau một thời gian, số kết nối đang hoạt động ở một server đang nhiều hơn hẳn một server khác, nhưng lượng kết nối tiếp theo mà các server này nhận được vẫn bằng nhau. Do đó một số server sẽ phải xử lý nhiều hơn hẳn các server khác. Tuy vậy, vì tính đơn giản của nó, nên nó hoạt động rất hiệu quả (không phải mất thêm thời gian tính toán các thông số khác nên việc phân tải diễn ra rất nhanh). Nếu các server hoạt động bình thường và không xảy ra sự cố thì sử dụng RR rất tốt. Điểm yếu của RR là 2 yêu cầu liên tục từ phía một người dùng có thể sẽ được gửi vào 2 server khác nhau. Điều này không tốt vì khi người dùng đang được kết nối vào một server, thông tin mà họ cần đang ở server đó, nếu kết nối tiếp theo vẫn được server đó xử lý thì sẽ góp phần tăng tốc độ đáp ứng cho người dùng. Do đó thuật toán RR thường được cài đặt cùng với các phương pháp duy trì session như sử dụng cookie. Thuật toán Weighted Round Robin (Ratio) Nguyên lý hoạt động của thuật toán WRR cũng giống như thuật toán RR, yêu cầu từ phía người dùng sẽ được bộ cân bằng tải chuyển đến các server theo thứ tự xoay vòng. Sự khác biệt duy nhất ở đây là thuật toán WRR còn quan tâm đến khả năng xử lý (cấu hình) của các server. Trong cùng một chu kỳ, 1 server có k