Nghiên cứu đánh giá và phát triển các mô hình Cluster Server

Nghiên cứu đánh giá và phát triển các mô hình Cluster Server

Trường Đại Học Khoa Học Tự Nhiên Tp HCM

Khoa Công nghệ Thông tin Bộ môn Mạng máy tính & Viễn thông

Báo cáo Đề tài :

x y

Với nhiều sự giúp đỡ vô cùng quý báu của Quý Thầy, Cô khoa Công Nghệ Thông Tin,sự chỉ bảo nhiệt tình của các Anh, chị khóa trước cùng với sự hỗ trợ từ bạn bè, chúng em đãhoàn thành Luận Văn Tốt Nghiệp này

Để bày tỏ lòng biết ơn to lớn ấy, chúng em xin chân thành cảm ơn:

• Quý Thầy, Cô khoa Công Nghệ Thông Tin đã tận tình dìu dắt, chỉ dạy cho emnhững kiến thức quan trọng để chúng em hoàn thành Luận Văn này

• Đặc biệt, chúng em xin kính gửi đến Giáo viên Hướng dẫn - Thầy Phạm NguyễnAnh Huy - Người đã tận tâm chỉ dẫn, truyền đạt kiến thức cho chúng em trongsuốt thời gian làm Luận Văn Tốt Nghiệp lòng biết ơn sâu sắc nhất

• Xin chân thành cảm ơn các Anh chị khóa trước, các bạn học cùng khóa đã nhiệt tìnhgóp ý giúp đỡ chúng em hoàn chỉnh luận văn này

Cuối cùng, chúng em xin kính chúc sức khỏe Quý Thầy, Cô, các anh chị và các bạn.Xin chân thành cảm ơn !

Trân trọng kính chào

Nhóm thực hiện đề tài

Nguyễn Trường An & Phạm Thanh Phong

MỤC LỤC

1 Đặt vấn đề ( bài toán) 1

2 Giới thiệu 1

2.1 Single Server Solution 1

2.2 Cluster Server Solution 2

3 Các giải pháp chia tải Server 3

3.1 DNS Load balancing (DNS Round Robin) 4

3.1.1 Giới thiệu 4

3.1.2 Cấu hình 6

3.1.3 Đánh giá ưu khuyết điểm 8

3.2 Hardware-based Load balancing 9

3.2.1 Giới thiệu 9

3.2.2 Mô hình hoạt động 10

3.2.3 Cisco LocalDirector 4000 series 11

3.2.4 Đặc điểm của thiết bị 11

3.2.5 Cấu hình thiết bị 13

3.2.6 Bảng giá tham khảo 13

3.3 Software-based Load balancing 14

3.3.1 Application level load balancing với Apache/mod_jk/Tomcat 14

A Giới thiệu 14

B Cài đặt 15

3.3.2 Kỹ thuật IP load balancing với LVS (Linux Virtual Server) 19

A.Giới thiệu 19

B Kiến trúc hệ thống 20

C Kỹ thuật IP load balancing 25

D Các thuật toán load balancing trong LVS 31

E Các công cụ dùng để quản trị LVS 34

F Cài đặt và cấu hình LVS cluster 35

G Đánh giá ưu khuyết điểm 42

H Kết luận 43

3.4 Oracle 9iAS clustering 43

3.4.1 Kiến trúc n-tier clustering 43

A Single tier-clustering ( basic clustering) 44

B Two tier-clustering 45

C Multi tier-clustering 47

3.4.2 n-tier clustering với Oracle 9iAS 48

A Kiến trúc của một Oracle 9i cluster 49

B Cấu trúc cây phân cấp của Enterprise Manager trên Oracle 9iAS 57

C Instance- specific 58

D Software & Hardware failure trên Oracle9iAS 59

E Cấu hình clustering và load balancing 60

F Cấu hình OC4J Instance trên Oracle9i AS 63

3.5 Mô hình cải tiến ( phát triển) 64

3.5.1 Apache/mod_jk/Tomcat với session replication 64

A Giới thiệu session replication 64

B Cơ chế hoạt động 65

C Nâng cấp mô hình Apache/mod_jk/Tomcat với Session Replication 66

D Nhận xét ưu khuyết điểm 68

3.5.2 Content-based load balancing kết hợp LVS với Reverse proxy 68

A Tại sao phải chia tải theo nội dung yêu cầu ( content-based)? 68

B Hướng giải quyết - cluster of cluster 68

C Cài đặt cluster of cluster 71

3.5.3 Giải quyết single point of failure 74

4 Cluster testing và Results 75

4.1 Testing plan 75

4.2 Results 78

5 Hướng phát triển 80

6 Kết luận 80

7 Tài liệu Tham khảo 82

8 Phụ lục 85

8.1 Phụ lục Các internet site xử dụng Cluster server với LVS 85

8.2 Phụ lục Một số Thuật ngữ chuyên ngành sử dụng trong báo cáo 86

8.3 Phụ lục Cấu trúc CD báo cáo 88

3 DAN H MỤC HÌNH ẢNH Hình 2-1 Tổng quan về cluster server 2

Hình 3-1 DNS lookup một yêu cầu 5

Hình 3-2 DNS load balancing 5

Hình 3-3 Cấu hình DNS Load balancing 6

Hình 3-4 Server bị lỗi trong DNS Round Robin 8

Hình 3-5 sơ đồ phân tải luồng TCP/IP sử dụng LocalDirector(không có failover ở mức load balancer) 10

Hình 3-6 sơ đồ phân tải luồng TCP/IP sử dụng LocalDirector(có failover ở mức load balancer) 11

Hình 3-7 Front view LocalDirector 430 / 416 11

Hình 3-8 Front view LocalDirector 417 12

Hình 3-9 Rear view (với kết nối cáp failover giữa primary và backup load balancer) LocalDirector 430 / 416 12

Hình 3-10 Kiến trúc Apache/Tomcat load balancing 14

Hình 3-11 n-tier clustering với Apache load balancer 15

Hình 3-12 Tổng quan về LVS 21

Hình 3 -13 Failover mức load balancer trong LVS 23

Hình 3-14 Các thành phần trong LVS 24

Hình 3-15 LVS-NAT 25

Hình 3-16 Một ví dụ LVS-NAT 26

Hình 3-17 LVS-TUN 28

Hình 3-18 Hoạt động của LVS-TUN 29

Hình 3-19 LVS-DR 30

Hình 3- 20 Hoạt động của LVS-DR 31

Hình 3-21 Basic clustering 45

Hình 3-22 Two tier clustering (webtier và presentation tier chung một host) 46

Hình 3-23 Two tier clustering ( presentation tier và object tier chung host) 47

Hình 3-24 Multi tier clustering 48

Hình 3-25 Kiến trúc n-tier clustering trên Oracle 9iAS 49

Hình 3-26 Kiến trúc cluster Oracle9iAS 50

Hình 3-27 kiến trúc của farm và cluster trên Oracle9iAS 51

Hình 3-28 Minh họa OHS 55

Hình 3-29 Minh họa OC4J Instance 56

Hình 3-30 Minh họa Islands 57

Hình 3-31 Minh họa cấu trúc cây của Cluster 58

Hình 3-32 Minh họa Software failure 59

Hình 3-33 Minh họa hardware failure 60

Hình 3-34 Minh họa load balancing trên Application Server Instance 61

Hình 3-35 Demo tạo cluster bằng Giao diện web-based 61

Hình 3-36 Demo thêm một instance vào cluster bằng giao diện web-based 62

Hình 3-37 Demo việc quản lý cluster farm bằng giao diện web-based 62

Hình 3-38 Giao diện Web-based cấu hình web session replicate 63

Hình 3- 39 Cấu hình Apache/Tomcat với session replication 64

Hình 3- 40 Session replication over IP multicast 66

Hình 3-41 Hoạt động Reverse proxy 69

Hình 3-42 LVS Load balancer kết hợp với Reverse proxy 70

Hình 3-43 Cài đặt Reverse proxy trong cùng một mạng 71

Hình 3-44 cài đặt reverse proxy thuộc hai mạng khác nhau 72

Hình 3-45 Mô hình giải pháp “single point of failure” 75

Hình 4-1 Sơ đồ mạng testing mô hình Apache/mod_jk/Tomcat 76

Hình 4-2 Sơ đồ mạng testing mô hình LVS 77

Hình 4-3 Kết quả testing mô hình Apache/mod_jk/Tomcat 78

Hình 4-4 Kết quả testing mô hình LVS 79

3

DANH MỤC CÁC BẢNG

Bảng 3-1 Cấu hình Local Director 416/430 13

Bảng 3-2 Cấu hình Local Director 417 13

Bảng 3-3 Bảng giátham khảo tại http://www.alliancedatacom.com/manufacturers/cisco-systems/prices/index_full.asp 13

Bảng 3-4 Bảng giá tham khảo tại http://www.vimcom.ru/prices/newpricewww/enduser/pr_cisco19_v.htm 14

Bảng 4-1 Cấu hình Client 76

Bảng 4-2 Cấu hình Server 76

Bảng 4-3 Cấu hình Apache load balancer 77

Bảng 4-4 Cấu hình LVS Director 77

3

1 Đặt vấn đề ( bài toán)

Ngày nay, với sự bùng nổ số lượng người sử dụng Internet đặc biệt là các ứng dụngWeb, thương mại điện tử …cùng với sự phát triển của các trang web có nội dung động (dynamiccontent) đã làm gia tăng đáng kể khả năng xử lý của server Đến một thời điểm nào đó serversẽ không thể đáp ứng với số lượng lớn các yêu cầu đồng thời, và giải pháp được đưa ra là thaythế hoặc nâng cấp server hiện tại bằng server khác có cấu hình mạnh, khả năng xử lý caonhưng giải pháp này không được khả thi bởi vì các lý do sau:

• Với server mới được thay thế này thì trong tương lai gần lại không thể đáp ứngđược số lượng các yêu cầu lớn hơn và chúng ta lại phải thay thế hoặc nâng cấpserver này bằng server khác có cấu hình mạnh mẽ hơn và điều này sẽ còn tiếptục cho đến khi nào ???

• Với mỗi công đoạn thay thế hay nâng cấp server thì chi phí phải trả cho thiết bịphần cứng khá cao, và giải pháp này xem ra không mang lại hiệu quả kinh tếcho lắm

Từ các vấn đề trên , người ta đưa ra khái niệm “cluster server”?

2 Giới thiệu

Tim Berners-Lee đã phát triển World Wide Web (WWW) năm 1990 khi ông đang làmviệc tại CERN ( the European Laboratory for Particle Physics -Boutell) Kể từ đó, web đã trởthành nguồn chủ lực trong tất cả các loại thông tin Web đã trở nên không còn hạn chế nữa khiMarc Andreessen thuộc The National Center for Supercomputing Applications cho ra đờiMosaic, một trình WWW client rất phổ biến

Trong vài năm gần đây, các ứng dụng web đã gia tăng rất đáng kể từ vài trăm pages đãlên đến hàng triệu web sites như hiện nay Số lượng người dùng online ngày càng cao điểnhình như : Yahoo, Amazon.com, Microsoft, …Một webserver thông thường sẽ không thể nàođáp ứng được hàng ngàn các requests cùng lúc được Đối mặt với vấn đề này, các sites cólượng traffic cao thường có hai giải pháp lựa chọn : thay thế webserver cũ bằng webserver mớinhanh hơn hoặc thêm vào các server khác để làm tăng khả năng đáp ứng ( giải pháp thêmnhiều server hoạt động đồng thời này gọi là cluster server)

2.1 Single Server Solution

Để giải quyết vấn đề gia tăng đáng kể các yêu cầu từ client, nhà quản trị thay thếserver cũ (hardware) bằng server mới, mạnh hơn và nhanh hơn để có thể đáp ứng được tốt cácyêu cầu

Với hướng tiếp cận này, có thể giải quyết được vấn đề khi mà nội dung cung cấp hầuhết là những trang web tĩnh ( HTML, ) Mặc dù server hiện tại có thể mạnh nhưng cũng khôngthể nào đáp ứng được lượng lớn yêu cầu web động (dynamic content) trên internet Hơn nữa,giải pháp single server này lại mang nhiều khuyết điểm:

X Giá thành cao ( do đầu tư hardware mạnh)

X Không có khả năng mở rộng hệ thống ( scalability)

X Không có tính chịu lỗi cao ( fault tolerance)

2.2 Cluster Server Solution

Khái niệm “cluster” thật sự là một định nghĩa không được chuẩn xác lắm và đôi khi nó

làm cho người ta hiểu theo nhiều nghĩa khác nhau Trước kia, khi học nhập môn hệ điều hànhkhái niệm “cluster” là nhóm các disk sectors, một đơn vị trong đĩa cứng Còn hầu hết những

người dùng Windows chắc cũng quen thuộc với thông báo lỗi “lost clusters- something that can

be rectified by running the defrag utility” Một số người dùng Unix cao cấp có lẽ sẽ gắn liền

khái niệm “cluster” với cluster computing, một giải pháp máy tính bó xử lý song song nhằm

giải quyết một bài toán lớn (nổi bật là đề án Beowulf- super computer xử lý hàng tỉ chỉ thị

giây) Nhưng bây giờ, khi nghiên cứu cluster server solution, chúng ta sẽ hiểu “cluster” theo

một nghĩa khác

“Cluster Server” là một nhóm các server hoạt động cùng nhau để chia tải công việc, cung cấp độ tin cậy và khả năng xử lý cao cho hệ thống Đối với client, cluster server hoạt độnggiống như một server đơn lẻ nhưng thực chất nó là một nhóm nhiều servers

Trong đề tài này, chúng ta bàn vào một vài giải pháp clustering ở phía server hay còn

gọi là “business side of clustering” Giải pháp này đặc biệt thích hợp cho việc xây dựng hệ

thống virtual server- high availability Với giải pháp cluster server, font-end server được coinhư là load balancer nó cho phép hệ thống servers của ta đáp ứng được một số lượng rất lớn

các yêu cầu đồng thời hơn single server Hơn nữa, với cách nâng cấp “piece by piece”, khi

server hỏng ta remove chúng khỏi hệ thống để bảo trì, sau đó ta add thêm server vào hệ thốngmà không đòi hỏi thời gian downtime hoặc ảnh hưởng đến yêu cầu dịch vụ của client Một ưuđiểm của hệ thống cluster là giá thành thấp bởi vì hệ thống cluster server bao gồm một nhómcác servers hoạt động cùng nhau nên một server sẽ không phải xử lý tất cả yêu cầu; do đó đầu

tư các server này có thể là những máy tính rẽ, giá thành kinh tế thấp

Hình 2-1 Tổng quan về cluster server

Các mô hình nghiên cứu trong đề tài là: LVS ( Linux Virtual Server), CiscoLocalDirector, mô hình server Apache front ends to Java applications servers (như: mod_jk vàTomcat) Tất cả các mô hình đều gồm : một font-end server sẽ điều phối cho nhiều back-endservers

Các đánh giá ưu khuyết điểm cho từng mô hình nghiên cứu , song song đó có cải tiến (hoặc đề nghị cải tiến) cho từng mô hình như : duy trì session trên các server (session

replication) , cân bằng tải hệ thống dựa trên nội dung cung cấp ( load balancing based oncontents)

3 Các giải pháp chia tải Server

Trên mô hình client/server, một phía là client phía còn lại là server và có thể tồn tạiproxy ở giữa như proxy server cho các dịch vụ web Dựa vào đặc điểm này, chúng ta thấy cónhiều cách để điều phối yêu cầu đến cluster server ở nhiều cấp độ khác nhau Thông thườngcác server cluster sẽ chạy cùng dịch vụ và cùng một nội dung cung cấp Nội dung này có thểđược “nhân bản” trên đĩa local các servers, hệ thống share file chung hoặc có thể là một hệthống file phân tán chung Các giải pháp đề nghị cho việc phân tán các yêu cầu phục vụ có thểkể ra như sau:

Berkeley’s Smart Client 1đề nghị cung cấp một applet chạy phía client, khi đó applet tạo cácyêu cầu đến cluster và lấy thông tin trạng thái của tất cả servers, sau đó lựa chọn server phụcvụ cho yêu cầu của mình dựa vào thông tin trạng thái đó và forward yêu cầu đó đến server.Applet sẽ thực hiện gửi yêu cầu cho server khác nếu server đang phục vụ nó “down” Mộthướng khác2, tác giả phát triển một công nghệ lựa chọn server phục vụ dựa vào băng thông,khi đó client sẽ thăm dò băng thông giữa client và server cộng với khả năng ước lượng sự tắcnghẽn trên mỗi đường đi mà ra quyết định lựa chọn đường đi đến server phục vụ tối ưu nhất.Với hướng tiếp cận này thì không “trông suốt” với client (client-transparent), nó đòi hỏi phíaclient phải bổ sung code cho ứng dụng, vì vậy nó không thể triển khai cho tất cả các dịch vụTCP/IP Hơn nữa, nó sẽ làm tăng network traffic do phải sử dụng thêm nhiều query hoặc cácthao tác thăm dò

Sự mở rộng web server đầu tiên sử dụng Round Robin DNS ( RFC 1794) DNS server sẽ ánh

xạ một tên thành nhiều địa chỉ IP khác nhau một cách round–robin và mỗi lượt truy cập khácnhau của client sẽ được chuyển đến các server khác nhau trong cluster, phân tán yêu cầu chocác server Tuy nhiên, do cơ chế caching IP của client và hệ thống phân cấp DNS server nênphương pháp này không năng động trong việc load balancing cho cluster server và nó có nhiều

khuyết điểm (xem chi tiết mục 3.1).

X Hướng tiếp cận phía server, xây dựng kỹ thuật load balancing mức application

EDDIE3, Reverse-proxy4, SWEB5sử dụng các thuật toán load balancing ở mức applicationđể xây dựng hệ thống web cluster Bằng cách forward các HTTP requests đến các webserverssau đó lấy kết quả trả về và cuối cùng trả về cho clients Tuy nhiên, cách này đòi hỏi phảithiết lập 2 kết nối TCP cho mỗi yêu cầu, 1 giữa client và load balancer, 1 là giữa load balancervà servers , có độ trễ cao Khả năng xảy ra overhead trên load balancer do phải phân phối cácrequest và nhận kết quả trả về

Trong hướng tiếp cận này chúng ta sẽ nghiên cứu một mô hình : sử dụng một ServerApache + module mod_jk như một load balancer và phân phối yêu cầu đến các Server chạy

1

http://now.cs.berkeley.edu/ “Using Smart Clients to Build Scalable Services”

2http://www.ncstrl.ogr/ “Dynamic Server selection using Bandwidth probing in WAN”

ứng dụng java (Tomcat Server) (Trình bày chi tiết mục 3.3.1) Đây được coi là một giải pháp

điển hình cho hướng tiếp cận trên

X Hướng tiếp cận phía server, xây dựng kỹ thuật IP load balancing

Translation) để xây dựng load balancing ở mức IP cho server cluster Tuy nhiên, Magic Routerhiện nay không còn hiệu dụng nữa, còn Cisco’s Local Director thì giá quá đắt ( trình bày ở

mục 3.2 )

IBM’s TCP router 8sử dụng cải tiến NAT để xây dựng scalable web server trên hệthống Parallel SP-2 TCP router thay đổi địa chỉ đích của các request packets và forward đếnserver được chọn Server sau khi xử lý sẽ cập nhật lại source address trong reply packets chophù hợp với địa chỉ router và reply trực tiếp về cho clients Ưu điểm của cách này là routerkhông cần phải rewrite lại các reply packets Khuyết điểm là ta cần phải compile lại kernelcode ở phía các server

NetDispatcher 9, là một TCP router, forward trực tiếp các packets đến các servers đãđược cấu hình cùng IP với router trên interface non-arp Giống như là LVS/DR trong kiến trúc

Linux Virtual Server ( trình bày ở mục 3.3.2), nhưng NetDispatcher là một sản phẩm thương

mại rất đắt tiền

Trong hướng tiếp cận kỹ thuật IP load balancing sẽ trình bày giải pháp với kiến trúc

Linux Virtual Server ( mục 3.3.2 ).

3.1 DNS Load balancing (DNS Round Robin)

3.1.1 Giới thiệu

Mỗi client và server trên internet đều có 32 bits duy nhất gọi là địa chỉ IP (ipv4) Để

client truyền thông được với server thì nó phải biết được địa chỉ IP của server bằng cách gửiyêu cầu đến DNS (Domain Name System) DNS server chịu trách nhiệm ánh xạ tên máy tínhsang địa chỉ IP Khi ta nhập một URL vào address box trên browser (ví dụ :www.mysite.com),browser sẽ gửi yêu cầu đến DNS để được địa chỉ IP của site này như 172.29.0.1 chẳng hạn,thao tác này gọi là DNS lookup Sau khi browser nhận được IP nó sẽ gửi yêu cầu trực tiếp

server (xem hình 3-1)

6http://www.cs.berkeley.edu/eanders/magicrouter/ “an application of fast packet interposing”

7http://www.cisco.com/warp/public/715/lodir/index.html

8

keyword :” A scalable and highly available server”

9http://www.ics.raleight.ibm.com/netdispatch/ “NetDispatcher : A tcp connection router”

Hình 3-1 DNS lookup một yêu cầu

Thông thường thì mỗi website ( domain name) sẽ tồn tại một địa chỉ IP duy nhất trênDNS Với phương pháp DNS Round Robin thì DNS Server duy trì nhiều hơn một địa chỉ IP chomột website name , và khi đó mỗi lượt yêu cầu về địa chỉ IP của www.mysite.com sẽ đượcDNS trã về luân phiên các địa chỉ IP này Điều này cho phép ta load balancing trên hệ thống

cluster gồm nhiều server Cách hoạt động được mô tả đơn giản như hình 3-2

Hình 3-2 DNS load balancing

Ta có 2 webserver là webserver1 và webserver2 , khi client1 yêu cầu IP củawww.mysite.com sẽ được DNS trả về IP của webserver1 và yêu cầu client sẽ được gửi đếnwebserver1 (hình 3-2a), client3 thực hiện yêu cầu và được chỉ đến webserver2 (hình 3-2b).Tiếp theo client2 thực hiện tương tự và được đáp ứng bởi bởi webserver1 Cách dùng thuậttoán DNS Round Robin như trên thì tất cả các yêu cầu gửi đến sẽ được đáp ứng luân phiên bởicác server cluster Vì vậy các các nodes trên mô hình cluster đều phục vụ mạng

Đây là một giải pháp đơn giản và việc cấu hình cho nó cũng đơn giản.

3.1.2 Cấu hình

Sau đây là một cách cấu hình DNS Round Robin trên BIND (Berkeley Internet NameDaemon) – được phát triển và duy trì bởi Internet Software Consortium (ISC), đây là mộtDomain Name Server rất phổ biến trên flatform unix

Trong cấu hình này ta tạo alias cho www.mysite.com sẽ được ánh xạ đếnwwwX.mysite.com (X : là số thứ tự các realserver 1, 2, ) bằng cách sử dụng nhiều CNAME (

Canonical Name) record Ví dụ ta có 3 webserver : www1, www2, www3 (hình 3-3)

www.mysite.com.

Hình 3-3 Cấu hình DNS Load balancing

Ta tiến hành edit 3 files sau:

File named.boot – BIND daemon boot configuration

;type domain source-file

primary mysite.dom db.mysite

primary rr.mysite.dom db.mysite.rr

File db.mysite - BIND DNS zonefile for the mysite.com domain

@ IN SOA world.mysite.com root.world.mysite.com (

1998021502 ; SERIAL

604800 ; REFRESH: Secondaries refresh after 1 week

3600 ; RETRY: Secondaries retry after 1 hour

604800 ; EXPIRE: Maximum TTL of Data is 1 week

86400 ; MINTTL: Minimum TTL of Data is 1 day

IN NS world.mysite.com.

;;

;; the resource record for www.mysite.com which

;; maps to the Round-Robin domain

;;

www IN CNAME www.rr.mysite.com.

Lựa chọn giá trị TTL (Time To Live) trong phương pháp này là một vấn đề khó khăn.Việc caching các địa chỉ IP được điều khiển bởi giá trị này và nó được bổ sung bởi DNS server( TTL được đặt trong SOA (start of authority) record trong BIND zonefile) Bởi lẽ, nếu ta đặtTTL quá cao, ta sẽ giảm được DNS traffic nhưng DNS server caching thông tin quá lâu và nhưvậy việc phân tán HTTP traffic đến các webservers sẽ không hiệu quả Nếu ta set TTL quáthấp sẽ làm tăng DNS traffic và các query đến DNS sẽ liên tục (do thông tin DNS hết hạnnhanh vì vậy nó phải phân giải địa chỉ liên tục => có thể dẫn đến “thắt cổ chai” DNS server)nhưng nó sẽ load balance hiệu quả hơn Việc quyết định giá trị TTL tuỳ thuộc vào chúng tamuốn load balancing hệ thống như thế nào Trong cách cài đặt dưới đây với giá trị TTL bằng 1giờ thì hệ thống hoạt động tương đối hiệu quả

File db.mysite.rr BIND DNS zonefile for the rr.mysite.com domain

;; db.mysite.rr BIND DNS zonefile for the rr.mysite.com domain

;;

;;

;; the start of authority (SOA) resource record which

;; forces a minimal time-to-live (TTL) for this zonefile

;;

@ IN SOA world.mysite.com root.world.mysite.com (

1998021501 ; SERIAL

3600 ; REFRESH: Secondaries refresh after 1 hour

600 ; RETRY: Secondaries retry after 10 minutes

3600 ; EXPIRE: Maximum TTL of Data is 1 hour

1800 ; MINTTL: Minimum TTL of Data is 30 minutes )

IN NS world.mysite.com.

;;

;; the multiple canonical name (CNAME) resource record

;; which implies BIND's Round-Robin (RR) feature

;; the address (A) resource records for the

;; final NAME -> IP mapping

;;

www1 IN A 172.29.0.1

www2 IN A 172.29.0.2

www3 IN A 172.29.0.3

3.1.3 Đánh giá ưu khuyết điểm

Ü Ưu điểm

- Chi phí thấp và dễ cài đặt : Tất cả các DNS Server hiện nay điều hỗ trợ phương phápnày, do đó người quản trị hệ thống chỉ làm một ít thay đổi trên DNS server Phương pháp nàykhông đòi phải thay đổi hay thêm code vào các Web Application vì các ứng dụng này sẽkhông nhận ra việc sử dụng phương pháp DNS load balancing

- Đơn giản : Phương pháp này không cần một chuyên gia mạng để cài đặt hay bảo trì.Tuy nhiên phương pháp DNS Round Robin có một số khuyết điểm

Ü Khuyết điểm

Đây là phương pháp software-based và nó không thực sự hỗ trợ high – availability vàsession affinity

* Không hổ trợ hight – availability: Một mô hình cluster gồm có n nodes Nếu 1 node “down”

thì n yêu cầu đến sẽ chắc chắn nhận được IP của node down vì DNS Server không nhận ra

điều này và do đó người dùng sẽ nhận ra hệ thống bị lỗi (Hình 3-4)

Hình 3-4 Server bị lỗi trong DNS Round Robin

Trong trường hợp trên, WebServer1 bị lỗi và DNS không nhận biết điều này do đó yêu

cầu của client2 sẽ bị lỗi (hình 3-4a) Trong khi đó yêu cầu client3 vẫn được đáp ứng tốt bởi Webserver3(hình 3-4b) Và vẫn luân phiên khi client2 thực hiện yêu cầu tiếp sẽ được chuyển đến Webserver1 bị lỗi (hình 3-4c).

Trên thực tế để làm tăng hiệu quả cho network traffic và request time, người ta có cơchế cache danh sách các IP đã mapped trước đó cả trên máy local và trên DNS Server Do đókhi có yêu cầu mapping IP address nó sẽ tìm trên cache máy local trước nếu không có thì gửiyêu cầu lên DNS server và đương nhiên DNS server cũng lấy từ cache ra nếu cache đó chưahết hạn Nếu trong trường hợp thời gian cache danh sách các IP address chưa hết hạn nhưngnode có IP đó đã “down” thì client vẫn được route đến node lỗi này Trong trường hợp đó thìclient không thể access vào site đó mặc dù trên hệ thống server cluster vẫn còn nhiềuWebServer đang chạy tốt

Vấn đề khó khăn phát sinh là khi remove một node ra khỏi hệ thống cluster (để bao trìhay nâng cấp) thì sự việc vẫn diễn ra như trên khi client cố gắng access vào một node đãremoved Khi thêm mới node thì node này chỉ phát huy hiệu quả sau khi đã cập nhật vào DNS

*Không hỗ trợ session affinity:

Session affinity là khả năng duy trì các yêu cầu thuộc cùng một kết nối sẽ do mộtserver đáp ứng Điều này đặc biệt quan trọng trong các ứng dụng web động mà khi đó sessioncủa mỗi phiên làm việc sẽ được lưu trữ trên server DNS load balancing với tính luân phiêncủa nó thì các yêu cầu lần lượt được chuyển đến các servers trong danh sách server cluster đápứng Khi đó sẽ xảy ra lỗi do session được lưu trữ trên server này mà yêu cầu tiếp theo lại doserver khác đáp ứng Một ví dụ, là khi người dùng login vào một hệ thống e-commerce, saukhi đăng nhập thành công, session login thành công được lưu trên server1 và khi họ thao tácchọn hàng vào giỏ hàng lại được server2 đáp ứng, do server2 không biết được thông tin đăngnhập của user nên nó báo lỗi “access denied” và bắt người dùng phải đăng nhâp lại

3.2 Hardware-based Load balancing

Có nhiều lựa chọn cho giải pháp load balancing sử dụng phần cứng Các hãng nổi tiếngnhư Cisco, Alteon, Foundry network cung cấp nhiều Switchs mà có kèm sẵn chức năng loadbalancing trong đó Với vài thao tác cấu hình, ta có thể gắn nhiều máy tính chạy webservervào switchs, và lưu lượng mạng sẽ được cân bằng giữa các server

Các thiết bị Switchs (có chức năng load balancing) này họat động ở tầng 3 hoặc 4 (switch layer 3 hay switch layer 4 ) Đối với Switch Layer 3 nó dựa vào địa chỉ IP của các yêucầu gửi đến và điều phối yêu cầu cho webserver trên những thông tin này Còn Switch layer4(TCP layer) thì dựa vào port number (ví dụ như 80 cho HTTP)

Các thiết bị load balancing đặc biệt này hoạt động tốt mà không phụ thuộc vào sốlượng máy tính gắn vào nó ít hay nhiều Giải pháp load balancing sử dụng phần cứng thôngminh hơn cách sử dụng thuật toán round robin , không cần sử dụng các “mẹo” nào trên DNS.Các Switchs nhận tất cả các yêu cầu và phân tán các yêu cầu cho các available machines, tứclà khi server nào còn họat động thì nó mới chuyển yêu cầu đến và khi server bị down thì sẽkhông nhận được yêu cầu nào cho đến khi server đó họat động trở lại

Giải pháp dựa vào phần cứng cũng có một số khuyết điểm Nó không nhận biết đượcnăng lực xử lý của các máy tính, ví dụ như nó không chuyển nhiều yêu cầu hơn cho máy tínhcó năng lực xử lý mạnh hơn trên server farm Giá thành của giải pháp phần cứng đắt hơn nhiều

so với giải pháp phần mềm

Ngày nay, người ta đang có xu hướng kết hợp các ưu điểm của giải pháp phần mềmtrên các thiết bị phần cứng đặc biệt nhằm đưa ra một giải pháp tối ưu

Sau đây là giải pháp load balancing sử dụng Cisco Local Director của Cisco

Với LocalDirector ta có thể xây dựng một hệ thống server farm với đầy đủ các tínhnăng cao cấp như highly redundant và fault tolerant

LocalDirector cho phép chuyển hướng các luồng kết nối tới nhiều servers tuỳ theo loạidịch vụ Ví dụ tất cả các FTP requests được chuyển đến hệ thống cluster gồm nhiều servers chỉphục vụ FTP request và HTTP requests được chuyển đến cluster chỉ phục vụ HTTP request.Các thuật toán load balancing dựa trên weight (một trọng số mô tả performance của server) vàsố lượng kết nối hiện tại của server để nhằm đảm bảo cho servers trong cluster không bị quátải Nó xác định trạng thái sẵn sàng đáp ứng hay không của server (real time)

LocalDirector hỗ trợ các ứng dụng secure e-commerce và network có topology phứctạp Nó có thể duy trì được trạng thái kết nối của các browsers với các servers phân biệt trongtransaction cho dù client browsers có nằm sau một proxy

Hỗ trợ QoS, trong suốt với người dùng khi online/offline, add/remove server Có thểcấu hình redundancy bằng cách thêm một LocalDirector khác chạy standby – giải quyết đượcfailover ở mức load balancer khi một director down

LocalDirector có thể phân phối requests với hơn 200Mbps throughput Đây là giải phápphù hợp cho các sites internet có mật độ tải cao Việc cấu hình và quản trị với giải pháp nàytương đối đơn giản, không phải thay đổi lại địa chỉ mạng, giải quyết được vấn đề thiếu IP thực

3.2.2 Mô hình hoạt động

Hình 3-5 sơ đồ phân tải luồng TCP/IP sử dụng LocalDirector(không có failover ở mức

load balancer)

Hình 3-6 sơ đồ phân tải luồng TCP/IP sử dụng LocalDirector(có failover ở mức load

balancer)

3.2.3 Cisco LocalDirector 4000 series

Tiêu biểu cho dòng sản phẩn này là Cisco LocalDirector416 và 430

*LocalDirector 430 : Phù hợp cho các sites internet có mật độ tải cao nó đáp ứng đến

200 Mbps cho throughput của hệ thống, tốt cho các hệ thống websites có tốc độ phát triển vàmở rộng nhanh, giải quyết đến 100 triệu lượt truy cập một ngày

*LocalDirector 416 : Có giá thành tương đối, là giải pháp high-availability cho tất cả

các ứng dụng TCP/IP gồm:

*Sản phẩm cuối cùng trong dòng này là Cisco LocalDirector 417

Tuỳ theo nhu cầu và ứng dụng cung cấp mà chọn giải pháp với thiết bị thích hợp

3.2.4 Đặc điểm của thiết bị

Hình 3-7 Front view LocalDirector 430 / 416

Hình 3-8 Front view LocalDirector 417

Hình 3-9 Rear view (với kết nối cáp failover giữa primary và backup load balancer)

LocalDirector 430 / 416

* Chi tiết

LocalDirector cung cấp các tính năng chi tiết sau:

- Hot standby và stateful failover, loại trừ các khả năng xảy ra lỗi và cho phép cấu hìnhfailover ở mức load balancer

- Hỗ trợ transparent cho hầu hết các ứng dụng thông dụng như Web, FTP, telnet,Gopher và SMTP mà không cần dùng đến phần mềm hay các cấu hình đặc biệt khác

- Cung cấp khả năng throughput hệ thống lên 80Mbps đến 200Mbps (công nghệFastEthernet) đáp ứng được các giải pháp mạng đòi hỏi performance cao

- Hỗ trợ 16 Fast EtherChannel 10/100 interfaces với LocalDirector 430, thích hợp chocác hệ thống mạng phức tạp

- Các thuật toán phân tán sessions hỗ trợ đến 1 triệu session TCP đồng thời (LocalDirector 430) đáp ứng cho số lượng users tăng nhanh

- Cho phép đến 64.000 virtual và real servers, cho phép cấu hình nhiều domain và cấuhình mạng khác nhau.

- Tương thích với bất kỳ hệ điều hình nào chạy trên servers

- NAT, giải quyết được vấn đề khan hiếm IP đi internet trực tiếp cho servers

- Tích hợp khả năng security, chống truy cập bất hợp pháp từ bên ngoài

- Cấu hình đơn giản với tập lệnh chỉ gồm 10 commands và không cần thay đổi cấu hìnhmạng hiện tại hoặc cấu hình lại IP cho mạng

- Có hỗ trợ giao diện GUI với hầu hết các lệnh cấu hình

3.2.5 Cấu hình thiết bị

card

4 10/100 BaseT ports(upgradeable to 16 ormaximum 4 FDDI ports)

consolse interface port

DB-9 EIA/TIA -323consolse interface port

Bảng 3-1 Cấu hình Local Director 416/430

Bảng 3-2 Cấu hình Local Director 417

3.2.6 Bảng giá tham khảo

Cisco LocalDirector

Bảng 3-3 Tham khảo tại

http://www.alliancedatacom.com/manufacturers/cisco-systems/prices/index_full.asp

Cisco LocalDirector

Bảng 3-4 Tham khảo tại http://www.vimcom.ru/prices/newpricewww/enduser/pr_cisco19_v.htm

3.3 Software-based Load balancing

3.3.1 Application level load balancing với Apache/mod_jk/Tomcat

A Giới thiệu

Hình 3-10 Kiến trúc Apache/Tomcat load balancing

Trong kiến trúc này, một Apache server như là một font-end HTTP server kết hợp vớimodule mod_jk để nó hoạt động như một load balancing, thực hiện phân tải các yêu cầu đếncác Servlet/JSP Server (Tomcat), các Server Tomcat sử dụng một hệ thống database chung.Mỗi tomcat server chạy JVM (Java Virtual Machine) khác nhau Ta có thể sử dụng mô hình

này trong n-tier clustering ( trình bày ở mục 3.4.1) Khi đó sau các Servlet/JSP server (

presentation tier) ta kết hợp thêm các Object Container ( như JonAS Server, JBoss Server) vàđến database chung.

Hình 3-11 n-tier clustering với Apache load balancer

Đây là một cách triển khai điển hình về load balancing ở mức application, tên thườnggọi là mô hình kết hợp giữa Apache với các Java Application Server, là một mô hình clusterserver

Với kiến trúc này cung cấp cho hệ thống cluster:

• Load balancing : Các requests được phân phối cho nhiều Servers đáp ứng Cungcấp được tính năng “scalability”, cho phép nhiều hơn các kết nối đồng thời

• High Availability (HA) : Các requests đảm bảo sẽ được chuyển đến những serverscó khả năng đáp ứng tốt (available server), tránh lỗi xảy ra do chuyển request đếnserver bị “down”

• Failover mức Servlet / JSP level : Nếu một Server JSP /Servlet bị “down”, thì mộtJSP/ Servlet Server sẽ đáp ứng các yêu cầu ngay tức thì mà vẫn đảm bảotransparently với người dùng

Nếu ta sử dụng n-tier clustering, thì failover ở mức Object tier sẽ tích hợp sẵn trong các Objectserver ( như JBoss chẳng hạn)

B Cài đặt

Cấu hình: 1 Server Apache+mod_jk load balance cho 2 Server Tomcat (Hình 3-10)

- Apache HTTP Server, Tomcat, mod_jk là những sản phẩm mã nguồn mở, chạy tốt cả trênWindows là Unix Linux Trong phần trình bày sau đây sử dụng Apache version 1.3.3, Tomcat4.1x, mod_jk.dll (cho Apache1.3.x chạy trên windows) Nếu cấu hình trên nền linux thì ta sử

dụng thư viện mod_jk.so ( chép vào thư mục<apache_home>/libexec/) (Tất cả các software và package trên có kèm theo CD báo cáo).

Trên mỗi node ta cài đặt các Server tương ứng

* Load balancer (ta cài đặt Apache HTTP server Cài đặt đơn giản qua giao diện GUI vàWizard trên windows)

- copy mod_jk.dll vào thư mục windows/system32 hay bất cứ thư mục nào trên máy

- Edit file cấu hình http.conf trong <apache_home>/conf/http.conf (thêm vào cuối file cấu hình

JkMount /servlet loadbalancer

JkMount /servlet/* loadbalancer

- Tạo file tên là workers.properties và đặt nó vào <apache_home>/conf/ File này khai báo

thông tin về các server apache đang chạy sau nó, port giao tiếp Để cho dễ nhớ ta đặt 2 Server

Tomcat là Tomcat1 và Tomcat2 Nội dung workers.properties như sau:

ps=/

#danh sách các worker

worker.list=tomcat1, tomcat2, loadbalancer

# > lbfactornhỏ có nghĩa worker này sẽlàm ít hơn worker kia

# chênh lệch giữa 2 worker khi cấu hình 2 server này khác nhau.

# loadbalancer (type lb) worker sd thuật toán weighted round-robin

# > nếu worker die, load balancer sẽ check trạng thái nó

# trong một lúc Và sau đó request sẽ được chuyển cho other

- Đến đây phần cấu hình load balancer đã xong

* Cấu hình cho Tomcat server

- Edit file cấu hình <tomcat_home>/conf/server.xml

Tomcat cung cấp cho phép nhiều kiểu kết nối đến nó, trong đó có http và https Các

kiểu kết nối này được định nghĩa là “Connector” trong file server.xml

Để cấu hình cho Tomcat sử dụng AJP “nói chuyện” với Apache, phải chắc chắn rằng AJP13connector phải được enable ( mặc định)

<! Define a Coyote/JK2 AJP 1.3 Connector on port 8009 >

Để ngăn ngừa user truy cập trực tiếp vào server Tomcat, ta comment dòng “connector”non-SSL HTTP/1.1 lắng nghe trên port 8080 ( ta chỉ cho người dùng truy cập vào serverTomcat qua Apache)

Disalbe Warp connector ( vì ta sử dụng AJP connector tốt hơn)

Comment tag <Connector…WarpConnector…> (khoảng dòng 314)

- Cấu hình tương tự cho server Tomcat2

* Tạo trang testlb.jsp để test load balancing

Nội dung đơn giản chỉ in ra màu sắc để dễ dàng cho việc testing

<h1>Serving by Tomcat 1</h1>

</body>

</html>

* Kiểm tra cấu hình cài đặt

-Starting Tomcat1, Tomcat2 server <tomcat_home>/bin/startup.bat (on windows)

Phải startup 2 tomcat server trước, sau đó startup Apache Web server

<apache_home>/apache.exe

Mở Browser :http://localhost/(địa chỉ của Apache Webserver) Ta sẽ thấy trang index.htmlTest tomcat :http://localhost/index.jspnếu thấy tomcat index page là thành công

Testing loadbalancing:http://localhost/testlb.jsp

Nếu thấy trang màu đỏ (Yêu cầu được server Tomcat1 phục vụ)

Màu xanh (Tomcat2)

Luân phiên mở 2 browser ta sẽ thấy load balancing Round Robin

* Session Affinity(có được hiểu là sticky session)

Session Affinity: Khi một yêu cầu của client được load balancer chuyển cho một Tomcatserver phục vụ, thì các queries tiếp theo (cùng browser session client đó) sẽ vẫn do Tomcatserver đó phục vụ mà không đổi server theo thuật toán RR ( đây là thuật toán cải tiến của RR).Điều này đặc biệt quan trọng do session ban đầu được lưu trữ trên server (giả sử Tomcat1) nếucác queries tiếp theo chuyển qua cho server khác (Tomcat2) thì session ban đầu sẽ bị mất

* Cấu hình Session Affinity

Theo file cấu hình mặt định khoảng line thứ 100 thay thế:

<Engine name="Standalone" defaultHost="localhost" debug="0">

Bằng:

<Engine jvmRoute=”tomcat1” name="Standalone" defaultHost="localhost" debug="0">

Tương tự cho Tomcat2, đặtjvmRoute=”tomcat2”

Giá trị jvmRoute là duy nhất để xác định Tomcat instance.

Bây giờ nếu nhấn refresh button (F5) trên browser nhiều lần mà vẫn nhận được đápứng cùng một tomcat server (một màu) thì đã đạt được session affinity

3.3.2 Kỹ thuật IP load balancing với LVS (Linux Virtual Server)

A.Giới thiệu

LVS (Linux Virtual Server) là một hệ thống load balancing sử dụng Linux KernelModules Điều khác là load balancing trong trường hợp này được thực hiện ở mức hệ điềuhành và liên quan đến các tác vụ ở tầng network (IP) và transport (TCP), nó khác với mô hìnhload balancing Tomcat/Apache/mod_jk thực hiện load balancing ở tầng ứng dụng (application).LVS có ba mode hoạt động là NAT, TUN và DR, hỗ trợ để xây dựng cluster trên nhiềunetwork topologies khác nhau giữa load balancer, back-end servers và clients

LVS cung cấp một nền tảng cơ bản để xây dựng một hệ thống internet server với đầyđủ tính năng cao cấp:

* Scalability, khi nhu cầu cho các services mà ta cung cấp tăng lên , hệ thống của ta sẽ

dễ dàng mở rộng để đáp ứng yêu cầu người dùng ( đơn giản chỉ là việc thêm server phục vụvào hệ thống đang hoạt động)

* 24x7 availability, các dịch vụ ta cung cấp phải đáp ứng sẵn sàng 24/7 bất chấp có xảy

ra lỗi ở do phần cứng hoặc phần mềm

* Manageability, mặc dù ta có thể xây dựng hệ thống cluster trong một khoảng cách

vật lý lớn, nhưng công việc quản trị cũng đơn giản và dễ dàng nhờ vào các công cụ cung cấpđể quản lý cluster

* Cost-effectiveness, đây là tính năng cạnh tranh về mặc giá cả của hệ thống LVS so

với các hệ thống cung cấp cluster khác ( ví dụ như giải pháp cluster bằng thiết bị phần cứngLocalDirector của Cisco)

Hệ thống cluster server với kiến trúc Linux Virtual Server được sử dụng ở các sites phổbiến trên internet có mật độ tải cao như Linux portal www.linux.com, sourceforge.net, UKNational JANET Web Cache Services…( chi tiết ở phần phụ lục)

B Kiến trúc hệ thống

B.1 Tổng quát

Đây là một kiến trúc dùng để xây dựng hệ thống network cung cấp các dịch vụ với cáctính năng highly scalable và highly available Kiến trúc 3 tier LVS được mô tả như hình:

Hình 3-12 Tổng quan về LVS

Load balancer:

Các connections từ clients bên ngoài đến hệ thống servers thông qua load balancer, nóđảm nhiệm công việc chuyển hướng các yêu cầu này đến các real servers trong cluster farm(xử lý yêu cầu này ) Yêu cầu từ clients gửi đến hệ thống cluster thông qua một IP duy nhất là

IP của load balancer

Server pool (server farm):

Gồm nhiều server cung cấp các dịch vụ thực sự như web, ftp, mail, …

Backend storage:

Cung cấp hệ thống lưu trữ share-file cho các servers để đồng bộ hoá dữ liệu Đảm bảocung cấp nội dung giống nhau trên cùng một dịch vụ

Load balancer sử dụng các kỹthuật IP load balancing để điều phối các incomingconnections, nó chọn một server trong server pool để xử lý yêu cầu, duy trì trạng thái kết nốihiện tại và forward packets đến server đó Tất cả các công việc này được thực hiện bên trongkernel vì vậy khả năng overhead trên load balancer là rất thấp Do đó Load balancer có khảnăng tiếp nhận số lượng kết nối đến hệ thống nhiều hơn server thông thường.

Các servers trong kiến trúc này có thể được thêm vào để tăng khả năng scalability và

high availability Scalability là khả năng thêm vào hoặc bớt ra (adding or removing) một node trong hệ thống cluster mà trong suốt (transparent) với user Khi một server được thêm vào thì

performance của hệ thống tăng

Một ưu điểm của clustering là tính dư thừa về phần cứng và phần mềm Highavailability được cung cấp bằng cách kiểm tra các node (daemon hoặc service) bị lỗi, Loadbalancer cấu hình lại hệ thống để các yêu cầu tiếp theo sẽ không được chuyển đến node bị lỗinày Chúng ta thường sử dụng monitor daemon chạy trên Load balancer để kiểm tra trạng tháicủa một node, nếu 1 server không hồi đáp ICMP Ping hoặc không hồi đáp service trong 1khoảng thời gian nào đó thì Load balancer sẽ remove hoặc disable server bị lỗi này ra khỏidanh sách các server phục vụ, vì vậy Load balancer sẽ không điều phối một connection đếnserver bị lỗi( user sẽ không thấy hệ thống bị lỗi )

Vấn đề được đặt ra là Load balancer là điểm mấu chốt (single point) có thể gây ra lỗicho toàn bộ hệ thống, một khi Load balancer bị lỗi thì hệ thống sẽ ngưng hoạt động do các yêucầu không được điều phối đến các servers Để ngăn ngừa lỗi xảy ra trên Load balancer chúng

ta cần set up một backup Load balancer

Hình 3 -13 Failover mức load balancer trong LVS

Hai heartbeat daemon chạy trên primary và backup chúng truyền thông điệp heartbeat(health message) qua một kênh truyền heartbeat như đường serial line (sử dụng cable riêng).Khi mà heartbeat daemon trên backup không nghe được health message từ primary trong 1khoảng thời gian xác định, nó sẽ sử dụng kỹ thuật ARP snoofing để sử dụng virtual IP address(của primary) và đảm nhiệm chức năng Load balancing thay cho primary Khi mà primaryLoad balancer được phục hồi, một là nó sẽ trở thành backup loadbalancer luôn; hai là nó sẽnhận lại IP ban đầu (bằng các thông điệp heartbeat từ primary thay thế) và nó trở lại vai tròprimary load balancer như ban đầu, và load balancer thay thế sẽ trở về vị trí backup như banđầu Đây là quá trình failover(take failover ) ở mức Load balancer.Tuy nhiên, khi quá trìnhnày xảy ra thì bảng lưu trữ trạng thái các nối kết hiện tại sẽ bị mất và client phải thiết lập nốikết lại

B.3 Các thành phần

Các thành phần chính của Linux virtual server được thể hiện trong hình sau:

Hình 3-14 Các thành phần trong LVS

“ VS Schedule & Control Module” đây là module chính của LVS, nó được “hook” ở hainơi như hình, đặt ngay hướng các packets đi ngang qua bên trong kernel giữ lấy và rewrittenlại packets để thực hiện IP load balancing Nó được lookup trong “VS Rules Table” kiểm traxem packet của một connection mới có thuộc dịch vụ cung cấp load balancing không, và kiểmtra “Connection Hash Table” để nhận thấy gói tin này có thuộc kết nối được thực hiện trước đókhông IPVSADM là giao diện người dùng cho phép quản trị virtual servers, nó sử dụng hàmsetsockopt() để bổ sung các virtual server rules vào trong kernel (như loại dịch vụ đáp

ứng,port, IP address,…), và đọc các rules này thông qua /proc files.

“Connection Hash Table” được thiết kế để có thể lưu trữ thông tin hàng triệu kết nốiđồng thời, và mỗi entry lưu trữ chiếm 128 bytes bộ nhớ của loadbalancer Ví dụ, một Loadbalancer 256Mbytes RAM free có thể lưu trữ khoảng hai triệu kết nối cùng lúc Kích thước củahash table có thể được hiệu chỉnh bởi user cho phù hợp với ứng dụng của họ cung cấp, và

client < protocol, address, port > được sử dụng như một hash key vì vậy xung đột hash rất

thấp Một đồng hồ nhảy chậm sẽ kiểm tra mỗi giây để thu gom (giải phóng) các kết nối hếthạn

LVS thực hiện lưu giữ các gói ICMP cho virtual services Các gói imcoming ICMPpacket sẽ được forward đến đúng realserver đáp ứng, và các outgoing ICMP packets nhậnđược từ realserver cũng sẽ được hiệu chỉnh cho phù hợp và gửi chúng ra ngoài đúng cho client.Điều này đặc biệt quan trọng để phát hiện lỗi và điều khiển cảnh báo giữa client và cácservers như thông tin về MTU

LVS xây dựng 3 kỹ thuật IP load balancing, chúng có thể được sử dụng cho nhiều loạihệ thống cluster, hoặc có thể kết hợp chúng với nhau trong một cluster, ví dụ : các packets

được forward cho một vài server qua phương pháp LVS/NAT, một vài servers khác thì quaLVS/DR, và với các servers ở khoảng cách vật lý xa (kết nối WAN) sử dụng LVS/TUN.

C Kỹ thuật IP load balancing

Kỹ thuật IP Load balancing mang lại tính sẵn sàng cao (high scalability), chúng ta phảipatch lại Kernel Linux để nó hỗ trợ tính năng này Gồm có 3 loại: LVS/NAT, LVS/TUN(tunnelling), LVS/DR (direct routing) Một máy chạy Linux Virtual Server hoạt động như Load balancer cho các nối kết từ client Thông thường, các real server cung cấp các dịch vụvới cùng một nội dung Các nội dung này được nhân bản (replicate) trên đĩa local của serverhoặc hệ thống share-file

C.1 Linux Virtual Server – NAT

Do sự giới hạn không gian địa chỉ của IPv4 và một vài lý do về bảo mật, nhiều networksử dụng địa chỉ IP riêng cho các máy trong mạng mình và nó không nối kết được Internet.NAT (Network Address Translation) được phát triển khi các host trong mạng cục bộ muốn truycập đến hoặc được truy cập từ Internet Cơ chế NAT dựa vào đặc điểm header của các packetcó thể điều chỉnh được và các client nối kết tới hệ thống server bằng một IP duy nhất-IP củaNAT, các real server sử dụng các IP khác nhau kết nối với NAT server, trên NAT server sửdụng 2 network interfaces với một IP mạng riêng (cùng mạng với các server ) và một IPInternet (nối ra mạng ngoài) Đặc điểm này được sử dụng để xây dựng một virtual server.Kiến trúc LVS-NAT được mô tả như hình sau:

Trong kiến trúc này Load balancer và các real server nối kết với nhau bằng switch hoặchub Hoạt động của LVS-NAT như sau: khi 1 user truy cập vào virtual service được cung cấpbởi cluster server, một request packet được gửi đến virtual IP address (IP chấp nhận yêu cầucho virtual service ) đến Load balancer Load balancer xác định địa chỉ đích và port numbercủa packet nếu nó hợp lệ với virtual service được cung cấp bởi các virtual server dựa vào bảngrule table Một real server sẽ được chọn để phục vụ bằng các thuật toán Load balancing, thôngtin về kết nối này được lưu vào bảng hash table để ghi nhận kết nối Tiếp theo, địa chỉ đích vàport number của packet được re-written cho phù hợp với server được chọn và packet đượcforward đến server Khi mà các packet tiếp theo của kết nối đã được thiết lập trước đó ( kếtnối này được tìm thấy trong bảng hash table) và các packet này sẽ được re-written và forwardđến cùng server đã phục vụ nó trước đó Khi Load balancer nhận được response packet, nó re-

write lại <source address, port number> cho phù hợp với virtual service và trả về cho client.

Khi một kết nối bị đứt hoặc timeout, record ghi nhận thông tin kết nối sẽ được xoá bỏ khỏibảng hash table

Một ví dụ về LVS/NAT mô tả như hình sau:

Hình 3-16 Một ví dụ LVS-NAT

Ta có 3 server như hình trên, một máy có 2 network interfaces làm Loadbalancer(external IP Address :202.103.106.5 và internal IP Address: 172.16.0.1), 2 máy còn lại làm realserver với IP lần lượt là : 172.16.0.2 và 172.16.0.3

Bảng sau mô tả việc cấu hình phân tải cho các real server với 2 dịch vụ web và ftp:

Tất cả các kết nối đến IP address : 202.103.106.5 (địa chỉ Load balancer) ở port 80 sẽđược load balancer chuyển đến realserver IP address 172.16.0.2 port 80 và 172.16.0.3 port

8000 Như vậy đối với dịch vụ web sẽ được chia tải cho 2 real server này Tương tự với dịchvụ ftp , các kết nối đến địa chỉ 202.103.106.5 ở port 21 sẽ được chuyển đến server IP address172.160.0.3 port 21, trong trường hợp này thì ta chỉ có một máy phục vụ ftp service (Ghi chú:giá trị Weight trong bảng trên chỉ là một con số “integer” cho thấy khả năng xử lý của 2 máycó sự khác nhau, giá trị mặc định bằng 1)

Hai real server trên có thể chạy dưới bất kỳ hệ điều hành nào miễn là có hỗ trợ TCP/IPvà cấu hình default route của realservers phải là Virtual IP Address (172.16.0.1 trong trườnghợp này)

Với trường hợp LVS/NAT thì việc rewrite lại các packets được thực hiện như sau:Các packets yêu cầu dịch vụ Web có địa chỉ nguồn và địa chỉ đích:

C.3 Linux Virtual Server – TUN (Tunnelling)

IP Tunneling(IP encapsulation) là công nghệ đóng gói IP datagram vào một IPdatagram, định hướng datagram từ một IP address đến một IP address khác Công nghệ nàycho phép xây dựng một virtual server mà Load balancer chuyển các request packet theo tunnelđến các server khác nhau, server xử lý các yêu cầu và trả kết quả trực tiếp về cho client.Vìvậy, dịch vụ cung cấp được xem như virtual service trên một IP address Kiến trúc LVS-IPTunneling được mô tả như hình sau:

Hình 3-17 LVS-TUN

Với kiến trúc này real server có thể có real IP address của bất cứ mạng nào, trên cảmạng có khoảng cách xa(WAN) nhưng phải hỗ trợ IP Tunneling protocol và tất cả phải cótunnel device được cấu hình với VIP (virtual IP address-IP của Load balancer ) giống như cấu

hình “ifconfig tunl0 VIP” trên Linux.

Hoạt động của LVS/TUN giống như LVS/NAT:

Hình 3-18 Hoạt động của LVS-TUN

Trong LVS/TUN Load balancer đóng gói (encapsulation) packet với một IP datagramvà forward nó đến server được chọn phục vụ Khi server nhận packet đóng gói này, nó mở gói(de-capsulation) và tìm trong packet địa chỉ VIP, sau đó xử lý yêu cầu và trả về kết quả trựctiếp cho user

C.3 Linux Virtual Server – DR (Direct Routing)

Hình 3-19 LVS-DR

Trong kiến trúc này Load balancer và real servers phải thuộc cùng một segment củaLAN như Hub/Switch Virtual IP address được dùng chung cho Load balancer và Real servers

Tất cả các Real servers phải hỗ trợ loopback alias interface (lo trên Linux) cấu hình với VIP,

và Load balancer phải có một network interface khác cấu hình với địa chỉ IP có thể nhận đượccác packets từ bên ngoài

Hoạt động của LVS/DR giống như LVS/NAT và LVS/TUN:

Hình 3- 20 Hoạt động của LVS-DR

Load balancer chuyển hướng các request packets đến server được chọn để phục vụbằng cách đơn giản thay đổi MAC address của frame dữ liệu sau đó chuyển chúng vào LAN.Khi server trong LAN nhận được packet, nó tìm trong packet địa chỉ phù hợp với IP trênloopback interface của nó, xử lý và trả kết quả trực tiếp về cho user Điều chú ý là realserverphải được cấu hình cùng virtual IP address và không thực hiện hồi đáp arp

Bảng so sánh giữa LVS/NAT, LVS/TUN, LVS/DR

D Các thuật toán load balancing trong LVS

Sau đây là một vài thuật toán điều phối hay còn gọi là thuật toán load balancing đượccài đặt trong kiến trúc Linux Virtual Server

D.1 Round Robin

Thuật toán Round-Robin điều phối các yêu cầu theo kiểu “luân phiên” lần lượt đến cácserver phục vụ trong danh sách các realserver Ví dụ như ta có 3 real server trong danh sáchcác server ( Server A, B và C) Request thứ 1 sẽ được chuyển đến server A, request thứ 2được chuyển đến server B, request thứ 3 được chuyển đến server C và request thứ 4 sẽ đượcchuyển trở lại cho server A Với thuật toán này thì nó xem tất cả các realserver có khả năng

xử lý như nhau mà không xem xét đến số lượng kết nối hiện tại đến server hoặc thời gian màserver đáp ứng yêu cầu của từng server.

Linux Virtual Server Robin có một số cải tiến so với truyền thống DNS Robin, nó không lưu cache mà luôn kiểm tra một cách năng động khả năng tồn tại ( chưa bịlỗi) của server Điều này tạo hiệu quả hơn cho thuật toán

Round-D.2 Weighted Round Robin

Thuật toán này điều phối các real server cũng luân phiên giống Round-Robin nhưng nócòn kết hợp vào khả năng xử lý của từng máy server (Round-Robin xem như khả năng xử lýtất cả server bằng nhau) Mỗi server được đánh giá bằng một số integer (giá trị Weight) chỉ rakhả năng xử lý của nó Mặc định giá trị Weight bằng 1 Ví dụ, các realserver A, B, C cóweight lần lượt là 4, 3, 2 và thứ tự điều phối các yêu cầu AABABCABC, nó luân phiên trong

chu kỳ (mod sum(Wi) ) Thứ tự chọn real server phục vụ dựa vào số Weight của server.

Ta có một danh sách các real servers S={S0, S1, …, Sn}, một giá trị i (index) chỉ servervừa mới được chọn trong danh sách S, cw chỉ giá trị weight hiện tại của server Cả i và cw banđầu được gán bằng zero Nếu tất cả W(Si)=0 ,thì lúc này coi như là hệ thống không có serverđáp ứng nào, tất cả các kết nối đến hệ thống sẽ bị từ chối

Thuật giải được mô tả như sau:

while (1) {

if (i==0) { cw=cw-1;

if (cw<=0) { set cw the maximun weight of s;

if (cw==0) return null;

} } else i= (i+1) mod n;

if (w(si)>=cw) return si;

}

Trong WRR , các realserver có giá trị weight cao sẽ nhận được kết nối mới đầu tiên vànhận nhiều kết nối hơn server có weight thấp, servers có giá trị weight bằng nhau sẽ nhận sựphân tải các kết nối mới bằng nhau

Thuật toán điều phối Weighted Round-Robin hoạt động tốt hơn Round-Robin nếu khảnăng xử lý của các servers có khác nhau, tuy nhiên hệ thống cũng có khả năng xảy ra mất cânbằng nếu yêu cầu xử lý đòi hỏi quá cao, chẳng hạn như với một yêu cầu màsố lượng đáp ứngnhiều thì có thể nó sẽ dẫn đến chỉ một server đáp ứng

Thật ra Round-Robin là một trường hợp đặc biệt của Weighted Round-Robin mà khi đócác giá trị Weight đều bằng 1

D.3 Least Connection

Thuật toán Least-Connection (LC) lựa chọn server phục vụ dựa vào số lượng kết nối

hiện tại đến server là ít nhất, đây là một thuật toán “dynamic”, bởi vì nó đếm số lượng kết nối

đến server một cách thường xuyên Giống như RR, LC xem các performance của các server lànhư nhau, điều này thích hợp cho các yêu cầu cần đáp ứng ít Tuy nhiên nó có thể không cânbằng được tải của hệ thống khi có nhiều loại server khác nhau và khả năng xử lý của chúngcũng khác nhau

D.4 Weighted Least Connection

Cũng giống như giữa RR và WRR, Weighted Least-Connection (WLC) khác với LC ởchỗ nó gán một giá trị biểu hiện performance cho mỗi server Server có performance cao hơnsẽ nhận được lượng phần trăm yêu cầu nhiều hơn (trong mỗi thời điểm) Người quản trị có thểgán cho mỗi server một giá trị weight, số kết nối được chuyển cho server dựa vào tỉ lệ phầntrăm các kết nối hiện tại và chỉ số weight này

WLC hoạt động như sau: Ta có n realserver mỗi server i có một giá trị Wi(i=1,2, ,n)vàcác kết nối hiện hành đến hệ thống là Ci(i=1,2, ,n), ta gọi tổng số các kết nối này là S=sum

Ci(i=1,2, ,n) Giả sử lúc này server j sẽ được chọn với điều kiện sau được thỏa:

(Cj/S)/Wj= min {(Ci/S)/Wi} (vớii=1,2, ,n)

Bởi vì S là một hằng số nên ta có thể biểu diễn biểu thức trên như sau:

Cj/Wj= min {Ci/Wi} (vớii=1,2, ,n)

Có thể so sánh tương đương ( do không có số thực trong kernel linux)

Cj/Wj> Ci/Withay bằng Cj*Wi> Ci*Wj ( vì số Weight luôn > 0)

D.5 Connection Affinity

Chúng ta có thể xem mỗi connection đến hệ thống cluster server sẽ độc lập với cácconnections khác, vì vậy các connections có thể được phục vụ bởi các servers khác nhau Tuynhiên, khi 2 connections được thực hiện bởi cùng một client thì 2 kết nối này phải được phụcvụ bởi cùng một server vì nhiều nguyên nhân

FTP là một ví dụ cho thấy sự cần thiết connection affinity Để truy cập đến dịch vụ ftp,client phải tạo ra 2 connections đến server, một là control connection (port 21) để trao đổi cáccommand, một data connection (thường là port 20) để truyền dữ liệu Đối với active FTP,client cung cấp thông tin cho server biết port mà nó đang listen, data connection được khởi tạobởi server từ server’s port 20 đến client’s port Linux Virtual Server có thể kiểm tra được cácpackets đến từ client và port mà client đang lắng nghe, tạo entry và lưu vào bảng hash tablecho kết nối data này Nhưng đối với passive FTP, server báo cho client port nó đang listen, sauđó client sẽ khởi tạo data connection đến port của server LVS/TUN và LVS/DR chỉ tham giavào một nữa kết nối giữa client-server vì real server trả kết quả trực tiếp về cho client màkhông qua load balancer, vì vậy Linux Virtual Server không thể lấy được thông tin về porttrong các packets mà realserver chuyển trực tiếp cho client

Một cách giải quyết vấn đề này là lưu trữ thông tin kết nối của người dùng Khi clienttruy cập lần đầu, load balancer sẽ tạo ra một template giữa client và server được chọn phục vụvà lưu trữ thông tin này vào bảng hash table Thông tin template này được cấu hình thời hạntrong khoảng thời gian, và nó sẽ không bị hết hạn nếu nó vẫn còn điều khiển kết nối Nhờ vàothông tin trên template này mà load balancer sẽ chuyển tất cả các kết nối từ cùng một clientđến cùng một server phục vụ Cách giải quyết này ổn thoả cho các dịch vụ đòi hỏi connectionaffinity (như các ứng dụng multi port) nhưng có thể nó sẽ gây mất cân bằng cho hệ thống trongmột số trường hợp, tuy nhiên đây là giải pháp tốt cho connection affinity