Khóa luận Nghiên cứu, đánh giá và phát triển các mô hình Cluster Server

Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & 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 : Giáo viên hướng dẫn Phạm Nguyễn Anh Huy Sinh viên thực hiện Nguyễn Trường An MSSV: 9912501 Phạm Thanh Phong MSSV: 9912645 Tp HCM Tháng 07/2003 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Y×Z 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 em nhữ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ễn Anh Huy - Người đã tận tâm chỉ dẫn, truyền đạt kiến thức cho chúng em trong suố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ình gó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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server 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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server 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  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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server 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  Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server 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 systems/prices/index_full.asp................................................................................................. 13 Bảng 3-4 Bảng giá tham khảo tại 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  Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 1 / 98 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ụng Web, 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 (dynamic content) đã làm gia tăng đáng kể khả năng xử lý của server. Đến một thời điểm nào đó server sẽ 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à thay thế 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ý cao như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ấp server 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ếp tụ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àm việ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 khi Marc Andreessen thuộc The National Center for Supercomputing Applications cho ra đời Mosaic, 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ển hì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ới nhanh 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êm nhiề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ác yê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ầu hế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ông thể 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: 9 Giá thành cao ( do đầu tư hardware mạnh) 9 Không có khả năng mở rộng hệ thống ( scalability) 9 Không có tính chịu lỗi cao ( fault tolerance) Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 2 / 98 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ành khá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 động giố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 coi như 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ống mà 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óm cá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), Cisco LocalDirector, 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-end servers. 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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 3 / 98 replication) , cân bằng tải hệ thống dựa trên nội dung cung cấp ( load balancing based on contents).. 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ại proxy ở 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ường cá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: 9 Hướng xây dựng phía Client Berkeley’s Smart Client 1 đề nghị cung cấp một applet chạy phía client, khi đó applet tạo các yê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ục vụ 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ột hướng khác 2 , 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ắc nghẽ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ía client 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ác thao tác thăm dò. 9 Hướng xây dựng phía server – Round Robin DNS 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ác nhau của client sẽ được chuyển đến các server khác nhau trong cluster, phân tán yêu cầu cho các server. Tuy nhiên, do cơ chế caching IP của client và hệ thống phân cấp DNS server nên phươ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). 9 Hướng tiếp cận phía server, xây dựng kỹ thuật load balancing mức application EDDIE 3 , Reverse-proxy 4 , SWEB 5 sử 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 webservers sau đó 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ải thiế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 balancer và servers , có độ trễ cao. Khả năng xảy ra overhead trên load balancer do phải phân phối các request 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 Server Apache + module mod_jk như một load balancer và phân phối yêu cầu đến các Server chạy 1 “Using Smart Clients to Build Scalable Services” 2 “Dynamic Server selection using Bandwidth probing in WAN” 3 “A robust and scalable internet server” 4 “practical approaches for distributing http traffic ” 5 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 4 / 98 ứ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. 9 Hướng tiếp cận phía server, xây dựng kỹ thuật IP load balancing Berkeley’s MagicRouter 6 và Cisco’s Local Director 7 sử dụng NAT (Network Address Translation) để xây dựng load balancing ở mức IP cho server cluster. Tuy nhiên, Magic Router hiệ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 8 sử 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 đến server được chọn. Server sau khi xử lý sẽ cập nhật lại source address trong reply packets cho phù 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à router khô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 kernel code ở 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ửi yêu cầu đến DNS (Domain Name System). DNS server chịu trách nhiệm ánh xạ tên máy tính sang đị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) . 6 “an application of fast packet interposing” 7 8 keyword :” A scalable and highly available server” 9 “NetDispatcher : A tcp connection router” Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 5 / 98 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ên DNS. Với phương pháp DNS Round Robin thì DNS Server duy trì nhiều hơn một địa chỉ IP cho một website name , và khi đó mỗi lượt yêu cầu về địa chỉ IP của www.mysite.com sẽ được DNS 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 3-2a) 3-2b) 3-2c) Hình 3-2 DNS load balancing Ta có 2 webserver là webserver1 và webserver2 , khi client1 yêu cầu IP của www.mysite.com sẽ được DNS trả về IP của webserver1 và yêu cầu client sẽ được gửi đến webserver1 (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ật toá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ởi các server cluster . Vì vậy các các nodes trên mô hình cluster đều phục vụ mạng . Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 6 / 98 Đâ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 Name Daemon) – được phát triển và duy trì bởi Internet Software Consortium (ISC), đây là một Domain 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ạ đến wwwX.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) IN CNAME www1.mysite.com IN CNAME www2.mysite.com www.mysite.com. IN CNAME www3.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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 7 / 98 ) 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 đặt TTL 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ạn nhanh 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 ta muố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 1 giờ 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 ;; www IN CNAME www1.rr.mysite.com. IN CNAME www2.rr.mysite.com. IN CNAME www3.rr.mysite.com. ;; ;; 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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 8 / 98 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áp nà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ày khô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) 3-4a) 3-4b) 3-4c) 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ửi yêu cầu lên DNS server và đương nhiên DNS server cũng lấy từ cache ra nếu cache đó chưa hế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ưng node 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ều WebServer đ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. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 9 / 98 *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ột server đáp ứng. Điều này đặc biệt quan trọng trong các ứng dụng web động mà khi đó session củ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ên củ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 do server khác đáp ứng. Một ví dụ, là khi người dùng login vào một hệ thống e-commerce, sau khi đăng nhập thành công, session login thành công được lưu trên server1 và khi họ thao tác chọn hàng vào giỏ hàng lại được server2 đáp ứng, do server2 không biết được thông tin đăng nhậ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ếng như Cisco, Alteon, Foundry network cung cấp nhiều Switchs mà có kèm sẵn chức năng load balancing 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 webserver và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êu cầ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ông minh 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ức là 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 được nă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ính có 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ềm trê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. 3.2.1 Giới thiệu Đây là giải pháp sử dụng thiết bị mạng (phần cứng) để thực hiện công việc load balancing trong mô hình clustering. Giải pháp với thiết bị Cisco LocalDirector. Cisco LocalDirector là một thiết bị mạng dùng để thực hiện chức năng loadbalancing TCP/IP cho nhiều servers. Nó đảm nhiệm chức năng phân tán các requests từ người dùng cho hệ thống gồm nhiều servers (low-cost servers) –gọi là server farm. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 10 / 98 Với LocalDirector ta có thể xây dựng một hệ thống server farm với đầy đủ các tính nă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ại dị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ức tạ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 trong transaction 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 được failover ở 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áp phù 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ày tươ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) Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 11 / 98 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: ƒ Intranets ƒ Database access ƒ TN3270 sessions *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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 12 / 98 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ình failover ở 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 cho cá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. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 13 / 98 - Cho phép đến 64.000 virtual và real servers, cho phép cấu hình nhiều domain và cấu hì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ình mạ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ị Description LocalDirector 416 LocalDirector 430 Interfaces 3 10/100 BaseT interfaces card 4 10/100 BaseT ports (upgradeable to 16 or maximum 4 FDDI ports) Ports DB-9 EIA/TIA -323 consolse interface port DB-9 EIA/TIA -323 consolse interface port DRAM 32MB 384MB Flash Memory 2MB 4MB Bảng 3-1 Cấu hình Local Director 416/430 Description LocalDirector 417 CPU 600 MHz Pentium III Ethernet Controller Intel 82559 Memory 512 MB SDRAM 16 MB Flash Memory Ports 1 consolse 2 RJ45 (eth0-eth1 Intergrated 10/100 BaseT port ) 4 port-10/100 BaseT interfaces card (eth2- eth5) 1 failover port (DB-15) Bảng 3-2 Cấu hình Local Director 417 3.2.6 Bảng giá tham khảo Cisco LocalDirector LD-417 LocalDirector 417 $10,000 LD-FO= Local Director Fail Over Cable $200 Bảng 3-3 Tham khảo tại systems/prices/index_full.asp Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 14 / 98 Cisco LocalDirector LDIR-416 LocalDirector 416 $9 708,53 LDIR-430 LocalDirector 430 $24 293,75 LD-QUADFE= Four Port 10/100 Ethernet Card $777,40 LD-FDDI= FDDI Card for LocalDirector $2 915,25 LD-FO= Local Director Fail Over Cable $194,35 Bảng 3-4 Tham khảo tại 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ới module 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 đến cá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 ( Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 15 / 98 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ường gọ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 cluster server. 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. Cung cấ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 servers có khả năng đáp ứng tốt (available server), tránh lỗi xảy ra do chuyển request đến server bị “down”. • Failover mức Servlet / JSP level : Nếu một Server JSP /Servlet bị “down”, thì một JSP/ Servlet Server sẽ đáp ứng các yêu cầu ngay tức thì mà vẫn đảm bảo transparently 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 Object server ( 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ên Windows là Unix Linux. Trong phần trình bày sau đây sử dụng Apache version 1.3.3, Tomcat 4.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ử Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 16 / 98 dụng thư viện mod_jk.so ( chép vào thư mục/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 /conf/http.conf (thêm vào cuối file cấu hình sau: LoadModule jk_module /system32/mod_jk.dll JkWorkersFile "conf/workers.properties" JkLogFile "logs/mod_jk.log" JkLogLevel info JkMount /*.jsp loadbalancer JkMount /servlet loadbalancer JkMount /servlet/* loadbalancer - Tạo file tên là workers.properties và đặt nó vào /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 # ------------------------ # tomcat1 # ------------------------ worker.tomcat1.port=8009 //port listen mặt định cho AJP13 connector trên Tomcat worker.tomcat1.host= worker.tomcat1.type=ajp13 #kích thước cache cho một connect #worker.tomcat1.cachesize #chỉ ra cho worker load balancing khả năng đáp ứng của nó # ----> lbfactorphải > 0 # ----> 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. worker.tomcat1.lbfactor=100 # ------------------------ #tomcat2 # ------------------------ worker.tomcat2.port=8009 worker.tomcat2.host= worker.tomcat2.type=ajp13 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 17 / 98 #worker.tomcat2.cachesize # worker.tomcat2.lbfactor=100 # ------------------------ # Load Balancer worker # ------------------------ # # 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 # worker. worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=tomcat1, tomcat2 #cho phép session affinity ( session sticky) worker.loadbalancer.sticky_session=1 # # END workers.properties - Đến đây phần cấu hình load balancer đã xong * Cấu hình cho Tomcat server - Edit file cấu hình /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 Non-SSL HTTP/1.1 @ 8080 (*) SSL HTTP/1.1 @ 8443 AJP 1.3 @ 8009 // AJP13 Connector để kết nối với Server Apache (*) Proxy HTTP/1.1 @ 8081 (*) non-SSL HTTP/1.0 @ 8082 WARP @ 8008 ( ghi chú “* ” mặc định là disable; con số sau @ là port mặc định cho connector; Tomcat sử dụng port TCP/8005 cho control connections). HTTP và HTTPS là 2 protocol thông dụng cho các clients thông thường ( browsers) kết nối đến Tomcat. AJP13 (Apache JServ Protocol) và WARP là những protocol dùng để liên lạc giữa các server với nhau ( Giữa ApacheHTTP server và Tomcat Server) cho phép ta cấu hình hệ thống server phân tán. Để 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 AJP13 connector phải được enable ( mặc định). <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8009" minProcessors="5" maxProcessors="75" enableLookups="true" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="20000" useURIValidationHack="false" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/> Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 18 / 98 Để 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 server Tomcat qua Apache) Ví dụ: <!-- <Connector className="org.apache.catalina.connector.http.HttpConnector" port="8080" minProcessors="5" maxProcessors="75" enableLookups="true" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="60000"/> --> Disalbe Warp connector ( vì ta sử dụng AJP connector tốt hơn) Comment tag (khoảng dòng 314) Ví dụ: <!-- <Connector className="org.apache.catalina.connector.warp.WarpConnector" port="8008" minProcessors="5" maxProcessors="75" enableLookups="true" appBase="webapps" acceptCount="10" debug="0"/> --> Nếu chạy tomcat instance trên cùng một máy thì phải thay đổi port của server và port của AJP để tránh đụng độ. - 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. Serving by Tomcat 1 - Đặt file testlb.jsp này vào thư mục /webapps/root/testlb.jsp trên server Tomcat1 - Tương tự tạo file testlb.jsp cho server Tomcat2 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 19 / 98 Serving by Tomcat 1 * Kiểm tra cấu hình cài đặt -Starting Tomcat1, Tomcat2 server /bin/startup.bat (on windows) Phải startup 2 tomcat server trước, sau đó startup Apache Web server /apache.exe Mở Browser : (địa chỉ của Apache Webserver) . Ta sẽ thấy trang index.html Test tomcat : nếu thấy tomcat index page là thành công Testing loadbalancing : 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 Tomcat server phục vụ, thì các queries tiếp theo (cùng browser session client đó) sẽ vẫn do Tomcat server đó 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ếu cá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ế: Bằng: Tương tự cho Tomcat2, đặt jvmRoute=”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 Kernel Modules. Điều khác là load balancing trong trường hợp này được thực hiện ở mức hệ điều hà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ình load 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ều network topologies khác nhau giữa load balancer, back-end servers và clients . Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 20 / 98 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ứng LocalDirector 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, UK National 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ác tính năng highly scalable và highly available. Kiến trúc 3 tier LVS được mô tả như hình: Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 21 / 98 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ảo cung cấp nội dung giống nhau trên cùng một dịch vụ. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 22 / 98 Load balancer sử dụng các kỹthuật IP load balancing để điều phối các incoming connections, nó chọn một server trong server pool để xử lý yêu cầu, duy trì trạng thái kết nối hiệ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 trong kernel 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. High availability được cung cấp bằng cách kiểm tra các node (daemon hoặc service) bị lỗi, Load balancer 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ỗi này. Chúng ta thường sử dụng monitor daemon chạy trên Load balancer để kiểm tra trạng thái của một node, nếu 1 server không hồi đáp ICMP Ping hoặc không hồi đáp service trong 1 khoảng thời gian nào đó thì Load balancer sẽ remove hoặc disable server bị lỗi này ra khỏi danh sách các server phục vụ, vì vậy Load balancer sẽ không điều phối một connection đến server 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ỗi cho 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êu cầ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. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 23 / 98 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 1 khoả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à primary Load 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ình nà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ối kết lại. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 24 / 98 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” ở hai nơi như hình, đặt ngay hướng các packets đi ngang qua bên trong kernel giữ lấy và rewritten lại packets để thực hiện IP load balancing. Nó được lookup trong “VS Rules Table” kiểm tra xem packet của một connection mới có thuộc dịch vụ cung cấp load balancing không, và kiểm tra “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àm setsockopt() để 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 Load balancer 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ủa hash 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 đượ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ết hạn. LVS thực hiện lưu giữ các gói ICMP cho virtual services. Các gói imcoming ICMP packet 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ác servers 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ại hệ 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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 25 / 98 được forward cho một vài server qua phương pháp LVS/NAT, một vài servers khác thì qua LVS/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ải patch 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 server hoặ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 network sử 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 truy cậ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 packet có 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ủa NAT, 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 IP Internet (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: Hình 3-15 LVS-NAT Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 26 / 98 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ặc hub. Hoạt động của LVS-NAT như sau: khi 1 user truy cập vào virtual service được cung cấp bởi cluster server, một request packet được gửi đến virtual IP address (IP chấp nhận yêu cầu cho virtual service ) đến Load balancer. Load balancer xác định địa chỉ đích và port number củ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ảng rule table. Một real server sẽ được chọn để phục vụ bằng các thuật toán Load balancing, thông tin 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 được forward đến server. Khi mà các packet tiếp theo của kết nối đã được thiết lập trước đó ( kết nố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 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ỏi bả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 real server 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: Protocol Virtual IP Address Port Real IP address Port Weight 172.16.0.2 80 1TCP 202.103.106.5 80 172.16.03 8000 2 TCP 202.103.106.5 23 172.160.0.3 21 1 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 27 / 98 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ịch vụ ftp , các kết nối đến địa chỉ 202.103.106.5 ở port 21 sẽ được chuyển đến server IP address 172.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áy có 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/IP và cấu hình default route của realservers phải là Virtual IP Address (172.16.0.1 trong trường hợ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: SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80 Load balancer sẽ chọn một real server phục vụ chẳn hạn 172.16.0.3:8000. Packet được rewriten và forward đến server : SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000 Packet hồi đáp từ real server sau khi xử lý: SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456 Và cuối cùng packet được rewriten lại tại load balancer để gửi trả kết quả về cho client: SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456 C.3 Linux Virtual Server – TUN (Tunnelling) IP Tunneling(IP encapsulation) là công nghệ đóng gói IP datagram vào một IP datagram, định hướng datagram từ một IP address đến một IP address khác. Công nghệ này cho 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-IP Tunneling được mô tả như hình sau: Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 28 / 98 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: Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 29 / 98 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 datagram và 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ực tiếp cho user. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 30 / 98 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ủa LAN 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 được các packets từ bên ngoài. Hoạt động của LVS/DR giống như LVS/NAT và LVS/TUN: Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 31 / 98 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ên loopback interface của nó, xử lý và trả kết quả trực tiếp về cho user. Điều chú ý là realserver phả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 LVS/NAT LVS/TUN LVS/DR Server Any Tunneling Non-arp dev Server network private LAN/WAN LAN Server number Low (10~20) High (100) High(100) Server gateway Load balancer Own router Own router 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 được cà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ác server phục vụ trong danh sách các realserver. Ví dụ như ta có 3 real server trong danh sách cá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ẽ được chuyể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 Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 32 / 98 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 Round-Robin có một số cải tiến so với truyền thống DNS Round- 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. 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ỉ ra khả 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ỉ server vừ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ân bằ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 ứng nhiề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ân bằ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úng cũng khác nhau. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 33 / 98 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ơn sẽ 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ần tră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ới i=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ới i=1,2,..,n) Có thể so sánh tương đương ( do không có số thực trong kernel linux) Cj/Wj > Ci/Wi thay 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ác connections khác, vì vậy các connections có thể được phục vụ bởi các servers khác nhau. Tuy nhiê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ục vụ 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ác command, 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ạo bởi server từ server’s port 20 đến client’s port. Linux Virtual Server có thể kiểm tra được các packets đến từ client và port mà client đang lắng nghe, tạo entry và lưu vào bảng hash table cho 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 gia và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ề port trong 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 client truy 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ạn trong 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ào thô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 connection affinity (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 trong một số trường hợp, tuy nhiên đây là giải pháp tốt cho connection affinity. Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 34 / 98 E. Các công cụ dùng để quản trị LVS Việc quản trị một hệ thống cluster là vấn đề quan tâm hàng đầu khi người ta muốn xây dựng hệ thống này. Đầu tiên là hệ thống cluster phải dễ cài đặt và quản trị, như việc thêm vào một server để tăng throughput, hoặc bớt ra một server để bảo trì nó khi nó bị fail. Thứ hai, là các phần mềm phục vụ công việc quản trị phải có khả năng tự cấu hình (self-configuration), khả năng tự recovery khi xảy ra lỗi. Sau đây là 3 giải pháp với các gói phần mềm phục vụ cho cài đặt và quản trị LVS cluster. E.1 LVS Gui + heartbeat + ldirectord - lvs-gui ( ) cho phép cấu hình các servers chạy LVS kernel pachtes, ở thời điểm hiện tại thì lvs-gui chỉ hỗ trợ cấu hình LVS/DR. - heartbeat ( ) là một công cụ truyền thông giữa các servers định kỳ trong một khoảng thời gian cho trước để kiểm tra “health” của các server. - ldirectord” được viết bởi Jacob Rief là một daemon (process) dùng để monitor và quản trị các realserver trong cluster. Với gói phần mềm này ta xây dựng failover mức realservers như sau: ldirectord daemon chạy trên load balancer, nó monitor tất cả các realservers một cách thường xuyên. Nếu một real server bị lỗi, nó sẽ đưa server này ra khỏi danh sách các server phục vụ, và nó sẽ add trở lại danh sách khi server được recovery. Failover ở mức load balancer: heartbeat daemons chạy trên cả primary và backup loadbalancer, chúng truyền cho nhau thông điệp heartbeat (định kỳ) qua UDP/hoặc đường serial line (cáp nối đặt biệt qua cổng com giữa 2 máy) được nối giữa 2 load balancer. Khi heartbeat daemon trên backup loadbalancer không nhận được thông điệp heartbeat từ daemon/primary trong khoảng thời gian định trước, nó sẽ kích hoạt fake daemon ( để cấu hình cho backup sử dụng Virtual IP address cung cấp cho load balancer; Và khi nó nhận được thông điệp heartbeat trở lại từ primary, nó sẽ ngưng kích hoạt fake daemon để trả lại IP address cho primary. E.2 Piranha piranha là một sản phẩm clustering từ Red Hat Inc., nó bao gồm kernel patch, các daemons cluster và công cụ quản trị cluster với giao diện GUI. nanny daemon quản trị các server nodes và trao đổi thông tin dịch vụ trong cluster. pulse daemon điều khiển nanny deamon và đảm nhiệm công việc failover giữa 2 load balancers. pulse daemon phân công cho mỗi nanny phụ trách một realserver phân biệt, và khi nanny không nhận được hồi đáp từ server node trong khoảng thời gian qui định thì nó sẽ remove server đó ra khỏi danh sách các server được điều phối. nanny daemon có thể điều chỉnh giá trị weight của mỗi server node để tránh cho server bị quá tải. Khi nanny thấy server load cao hơn giá trị bình thường nó sẽ giảm giá trị weight trong bảng điều phối bên trong kernel để server sẽ nhận ít connection hơn. E.3 mon + heartbeat mon ( là gói phần mềm rất thông dụng dùng để monitor hệ thống, ngày nay nó đã được mở rộng để monitor tính sẵn sàng của các dịch vụ mạng trong các server nodes. Các mon service modules như fping.monitor, http.monitor, Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 35 / 98 ldap.monitor …được sử dụng để monitor các dịch vụ tương ứng trên realservers. Một alert sẽ được phát ra để add/remove một entry trong bảng điều phối các servers khi phát hiện ra một server node up/down. Vì vậy load balancer sẽ che dấu được các server bị lỗi với người dùng và cho nó tiếp tục cung cấp dịch vụ khi được recovery. heartbeat daemon được sử dụng để đảm nhiệm failover ở mức load balancers. * Tất cả các gói phần mềm trên đây điều được sử dụng miễn phí theo GNU. F. Cài đặt và cấu hình LVS cluster F.1 Requirement cho client, Director, RealServers * Clients : Bất cứ máy tính nào chạy bất kỳ hệ điều hành nào hỗ trợ telnel client và http client (như browsers : netscape, lynx, IE) sử dụng cho công việc testing. * Director : Máy tính chạy linux kernel 2.2.x (x>=14) hoặc 2.4.x patch với ipvs. Hiện tại nên sử dụng kernel 2.4.x.Với mục đích testing, director không đòi hỏi phải có cấu hình cao – các máy 486 với 10 bps ethernet card là đủ. * Các RealServers : Đây là các máy tính cung cấp dịch vụ chính cho hệ thống (telnet hay http service). Director forward các packets bằng 3 mode, tuỳ theo mỗi mode mà ta chọn OS cho realservers: - LVS-NAT: any machine, any OS , real server phải có tcp/ip stack. - LVS-DR : OS hỗ trợ loopback aliasing ( không tốt với windows). - LVS-TUN: real server cần phải chạy OS hỗ trợ tunnel (linux). Lưu ý: - Real servers và Client thường khác network ( thực tế khi triển khai thực hiện nếu client và LVS cùng một network – sẽ không chạy), cho nên chúng ta sẽ sử dụng 2 network ( các realserver private network vd : 192.168.1.0/24 ) , và client để test các dịch vụ nằm trên một network khác. RealServers kết nối Director-Router-…Clients . - Director thường sử dụng 2 NICs để có thể bổ sung thêm các tính năng filter và security. Tuy nhiên ta cũng có thể đặt 1 NIC trên director với 2 IP address thuộc 2 network khác nhau ( vd : eth0:1 , eth0:2). - Ta không thể truy cập các dịch vụ cung cấp bởi LVS trên các máy tính trong hệ thống LVS, tức là ta cần 1 client không thuộc realservers hoặc director. Nếu truy cập từ director thì kết nối sẽ bị treo, kết nối từ realserver thì sẽ truy cập dịch vụ trên máy local mà không qua LVS. Do đó minimum cho hệ thống là 3 machines : client, director, realserver(s). F.2 Software ( các packages) Để sử dụng được LVS ta phải patch và dịch lại kernel cho nó hỗ trợ IPVS. Kernel hiện tại là bản 2.4, và công việc này thực hiện như sau: Download bản standard kernel tại ftp://ftp.kernel.org/pub/linux/kernel/v2.4/ chọn bản thích hợp như linux-2.4.17.tar.gz ( hoặc có thể cài đặt gói rpm kernel có kèm trong bộ đĩa CD cài đặt RedHat Linux – sau khi cài đặt source kernel nằm ở : /usr/src/linux-2.4 ) Download hidden patch tại Download IPVS patch tại 2.4.20-ipvs-1.0.8.patch.gz (April 11, 2003) Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 36 / 98 Công cụ quản trị và cấu hình LVS đơn giản ipvs admin : hoặc đều được. F.3 Các bước thực hiện Các bước re-compile lại kernel như sau: #unpack new kernel tar zxvf linux-2.4.17.tar.gz #unpack ipvs patch gunzip linux-2.4.20-ipvs-1.0.8.patch.gz #unpack kernel mv linux /usr/src/linux-2.4.17 cd /usr/src # tạo symlink rm –f linux-2.4 ln -s linux-2.4.17 linux-2.4 ln –s linux-2.4.17 linux # Apply “hidden” patch cd linux-2.4.17 patch –p1 < hidden-2.4.5-1.diff output dạng như sau: patching file include/linux/inetdevice.h patching file include/linux/sysctl.h Hunk #1 succeeded at 334 (offset 9 lines). patching file net/ipv4/arp.c Hunk #3 succeeded at 754 (offset -1 lines). patching file net/ipv4/devinet.c Hunk #1 succeeded at 756 (offset 20 lines). Hunk #2 succeeded at 1013 (offset -4 lines). Hunk #3 succeeded at 1079 (offset 20 lines). patching file Documentation/filesystems/proc.txt Hunk #1 succeeded at 1583 (offset 5 lines). patching file Documentation/networking/ip-sysctl.txt #apply ipvs patch patch –p1 < linux-2.4.20-ipvs-1.0.8.patch #Bắt đầu biên dịch make clean make mrproper make menuconfig make bzImage make modules make modules_install #lưu ý là các bước trên diễn ra rất lâu – phải kiên nhẫn #sau khi biên dịch, tập tin nhân kết quả lưu trong /usr/src/linux-2.4/arch/i386/boot/bzImage #tiếp theo copy tập tin nhân kết quả vào thư mục /boot cp /usr/src/linux/System.map-2.4.17 /boot/System.map-2.4.17 cd /boot rm System.map ln –s System.map-2.4.17 System.map Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 37 / 98 #Bây giờ cấu hình lại bootloader để nó nhận ra kernel mới (edit file /etc/lilo.conf nếu chọn bootloader là lilo lúc cài đặt) , hoặc /boot/grub/grub.conf nếu chọn GRUB bootloader lúc cài đặt vi /etc/lilo.conf image=/usr/src/linux-2.4/arch/i386/boot/bzImage label=linuxipvs root=/dev/hda1 #reboot lại hệ thống ------------------------------------------------------------------------------------------------- #Bước tiếp theo là cài đặt ipvsadm #Nếu download gói rpm ta chỉ thực hiện rpm –ivh ipvsadm-1.20-5.src.rpm #Nếu download gói .tar.gz ta thực hiện unpack, make, makeinstall Mọi việc cài đặt cho hệ thống xem như xong, sau đây là bước cấu hình hệ thống LVS, nếu sử dụng các công cụ hỗ trợ cấu hình giao diện GUI, hoặc các script cấu hình có sẵn như ( thì có thể download và cài đặt theo help của nhà cung cấp . Để đơn giản trong việc cấu hình LVS phục vụ cho testing, sau đây 3 cách cấu hình đơn giản LVS/NAT, LVS/TUN, LVS/DR “by hand” sử dụng ipvsadm . F.3.1 LVS/NAT Cấu hình LVS-NAT với các real server thuộc cùng một LAN, client dùng test thuộc một network khác và director có 2 card mạng với 2 IP thuộc 2 mạng server và client. Chi tiết như sơ đồ sau: ________ | | | client | |________| CIP=172.29.0.2 /16(eth0) | | __________ | | | | (VIP=172.29.0.1/16, eth0) | director |---| |__________| | DIP=192.168.0.9/25 (eth1) | | ----------------------------------- | | | | RIP1=192.168.0.1/25(eth0) RIP2=192.168.0.2/25(eth0) ____________ ____________ | | | | |realserver1 | |realserver2 | |____________| |____________| Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 38 / 98 * Cấu hình với dịch vụ telnet port 23: Để đơn giản cho việc testing cấu hình ta setup trước tiên làdịch vụ telnet, các dịch vụ khác tương tự ta chỉ cần thay đổi port (ví dụ http, ftp,..) Các công việc sau đây sẽ được thực hiện trên director (load balancer). - Ta có thể thực hiện bằng command line trên console director hoặc gom chúng lại thành một shell script tên tự đặt lvs_nat_telnet.sh và thực thi $sh lvs_nat_telnet.sh để thực hiện cấu hình - Shell script lvs_nat_telnet như sau: #!/bin/sh #------lvs_nat_telnet-director---------- #set ip_forward ON for vs-nat director (1 on, 0 off). cat /proc/sys/net/ipv4/ip_forward echo "1" >/proc/sys/net/ipv4/ip_forward #director is gw for realservers #turn OFF icmp redirects (1 on, 0 off) echo "0" >/proc/sys/net/ipv4/conf/all/send_redirects cat /proc/sys/net/ipv4/conf/all/send_redirects echo "0" >/proc/sys/net/ipv4/conf/default/send_redirects cat /proc/sys/net/ipv4/conf/default/send_redirects echo "0" >/proc/sys/net/ipv4/conf/eth0/send_redirects cat /proc/sys/net/ipv4/conf/eth0/send_redirects #cấu hình VIP /sbin/ifconfig eth0 172.29.0.1 broadcast 172.29.0.255 netmask 255.255.0.0 up #Cấu hình DIP /sbin/ifconfig eth1 192.168.0.9 netmask 255.255.255.0 up #set default gateway #nếu director đứng sau một router thì đây là địa chỉ router đó #trong trường hợp này là địa chỉ của client /sbin/route add default gw 172.29.0.2 netmask 255.255.0.0 metric 1 #clear ipvsadm tables /sbin/ipvsadm -C #install LVS services with ipvsadm #add telnet to VIP with rr sheduling (dùng thuật toán điều phối round robin: rr) /sbin/ipvsadm -A -t 172.29.0.1:telnet -s rr #Ghi chú #(-A): virtual service; (-t): TCP sau đó là host:port ; rr: round-robin (các thuật toán #khác thay thế lc: least- connection, wlc: weighted least-connection,..) #first realserver #forward telnet to realserver 192.168.0.1 using LVS-NAT (-m), with weight w=1 /sbin/ipvsadm -a -t 172.29.0.1:telnet -r 192.168.0.1:telnet -m -w 1 # (-r hostname:port) chỉ realserver và cổng dịch vụ #check that realserver is reachable from director ping -c 1 192.168.0.1 #Tương tự cho ealserver2 #forward telnet to realserver 192.168.0.2 using LVS-NAT (-m), with weight=1 /sbin/ipvsadm -a -t 172.29.0.1:telnet -r 192.168.0.2:telnet -m -w 1 #checking if realserver is reachable from director Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 39 / 98 ping -c 1 192.168.0.2 #list ipvsadm table /sbin/ipvsadm #------end lvs_nat_telnet -director---------- Thi hành shell trên $sh lvs_nat_telnet.sh sẽ thấy các output tương ứng lên màn hình console. Trên các realserver ta cần khai báo default gateway là DIP ngoài ra không cần phải cấu hình nào khác ( đương nhiên là phải start server cung cấp dịch vụ như Webserver, ftp server, hay telnet server tương ứng). *Testing LVS-NAT: Công cụ kiểm tra cũng là ipvsadm với các option như sau: $ipvsadm : hiển thị cấu trúc của cấu hình LVS $ipvsadm –S : hiển thị các rules cấu hình $ipvsadm –L –stats : hiển thị trạng thái $ipvsadm –L –rate : hiển thị chi tiết các connection hiện tại, các packets transfer, và tỉ lệ packets transfer. Chi tiết có thể manpage ipvsadm $man ipvsadm Khi thực hiện $ipvsadm output dạng như sau: IP Virtual Server version 0.9.14 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.29.0.1:telnet rr -> 192.168.0.1:telnet Masq 1 0 0 -> 192.168.0.2:telnet Masq 1 0 0 Ngồi trên máy client thực hiện telnet 172.29.0.1 và trở lại director thực hiện $ipvsadm , lúc này có dạng như sau IP Virtual Server version 0.9.14 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.29.0.1:telnet rr -> 192.168.0.1:telnet Masq 1 1 0 -> 192.168.0.2:telnet Masq 1 0 0 Bây giờ thì số lượng kết nối ActiveConn đã tăng lên, mở một telnet 172.29.0.1 khác và output sẽ thấy ActiveConn tăng lên ở server thứ 2 IP Virtual Server version 0.9.14 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.29.0.1:telnet rr Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 40 / 98 -> 192.168.0.1:telnet Masq 1 1 0 -> 192.168.0.2:telnet Masq 1 1 0 Đến đây đã cấu hình LVS-NAT thành công. Lưu ý quan trọng: Nếu lỗi treo kết nối , dòng ActiveConn không tăng mà InActConn tăng dạng như sau: IP Virtual Server version 0.9.14 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.29.0.1:telnet rr -> 192.168.0.1:telnet Masq 1 0 1 -> 192.168.0.2:telnet Masq 1 0 0 Lỗi set default gateway trên realserver phải là director (DIP) và ngoài ra không được route đến đích khác. Nếu tồn tại các route entries khác trong bảng route table của realserver thì phải remove nó đi ví dụ: route del –net 192.168.0.0 netmask 255.255.255.0 dev eth0 trên linux redhat. F.3.2 LVS/DR * Cấu hình LVS/DR trên một mạng đơn (192.168.1.254/24) trên các máy có 1 network card. Cấu hình ip trên các alias (eth0:110, lo:0), các máy phải không được route với nhau để tránh trường hợp chúng ping lẫn nhau. ________ | | | client | |________| CIP=SGW=192.168.1.254 (eth0) | | __________ | | | | (VIP=192.168.1.110, eth0:110) | director |---| |__________| | DIP=192.168.1.9 (eth0) | | ----------------------------------- | | | | RIP=192.168.1.11(eth0) RIP=192.168.1.12(eth0) (VIP=192.168.1.110, lo:0) (VIP=192.168.1.110, lo:0) ____________ ____________ | | | | | realserver | | realserver | |____________| |____________| Giống như NAT, ta có script cấu hình dịch vụ telnet (http tương tự) cho Director: #!/bin/bash #---------------lvs_dr_telnet-director------------------------ #set ip_forward OFF for vs-dr director (1 on, 0 off) Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 41 / 98 cat /proc/sys/net/ipv4/ip_forward echo "0" >/proc/sys/net/ipv4/ip_forward #director is not gw for realservers: leave icmp redirects on echo 'setting icmp redirects (1 on, 0 off) ' echo "1" >/proc/sys/net/ipv4/conf/all/send_redirects cat /proc/sys/net/ipv4/conf/all/send_redirects echo "1" >/proc/sys/net/ipv4/conf/default/send_redirects cat /proc/sys/net/ipv4/conf/default/send_redirects echo "1" >/proc/sys/net/ipv4/conf/eth0/send_redirects cat /proc/sys/net/ipv4/conf/eth0/send_redirects #add ethernet device and routing for VIP 192.168.1.110 /sbin/ifconfig eth0:110 192.168.1.110 broadcast 192.168.1.110 netmask 255.255.255.255 /sbin/route add -host 192.168.1.110 dev eth0:110 #listing ifconfig info for VIP 192.168.1.110 /sbin/ifconfig eth0:110 #check VIP 192.168.1.110 is reachable from self (director) /bin/ping -c 1 192.168.1.110 #listing routing info for VIP 192.168.1.110 /bin/netstat -rn #setup_ipvsadm_table #clear ipvsadm table /sbin/ipvsadm -C #installing LVS services with ipvsadm #add telnet to VIP with round robin scheduling /sbin/ipvsadm -A -t 192.168.1.110:telnet -s rr #forward telnet to realserver using direct routing with weight 1 /sbin/ipvsadm -a -t 192.168.1.110:telnet -r 192.168.1.11 -g -w 1 #check realserver reachable from director ping -c 1 192.168.1.12 #forward telnet to realserver using direct routing with weight 1 /sbin/ipvsadm -a -t 192.168.1.110:telnet -r 192.168.1.12 -g -w 1 #check realserver reachable from director ping -c 1 192.168.1.12 #displaying ipvsadm settings /sbin/ipvsadm #not installing a default gw for LVS_TYPE vs-dr #---------------end lvs_dr_telnet-director------------------------ ShellScript cấu hình cho các realserver #!/bin/bash #----------lvs_dr_telnet-realserver------------------ #installing default gw 192.168.1.254 for vs-dr /sbin/route add default gw 192.168.1.254 #showing routing table /bin/netstat -rn #checking if DEFAULT_GW 192.168.1.254 is reachable ping -c 1 192.168.1.254 #set_realserver_ip_forwarding to OFF (1 on, 0 off). echo "0" >/proc/sys/net/ipv4/ip_forward cat /proc/sys/net/ipv4/ip_forward Khoa CNTT Báo cáo Luận văn Tốt nghiệp Nghiên cứu, Đánh giá & Phát triển các mô hình Cluster Server Trang 42 / 98 #looking for DIP 192.168.1.9 ping -c 1 192.168.1.9 #looking for VIP (will be on director) ping -c 1 192.168.1.110 #install_realserver_vip /sbin/ifconfig lo:110 192.168.1.110 broadcast 192.168.1.110 netmask 0xffffffff up #ifconfig output /sbin/ifconfig lo:110 #installing route for VIP 192.168.1.110 on device lo:110 /sbin/route add -host 192.168.1.110 dev lo:110 #listing routing info for VIP 192.168.1.110 /bin/netstat -rn #hiding interface l