Linux Advance Linux Advance Linux Advance

Linux Advance - Để đáp ứng nhu cầu tìm hiểu của những ai thật sự muốn tìm hiểu, bắt đầu từ hôm nay mình sẽ post lần lượt từng bài lab của chương trình Linux Advance. Mỗi tuần post một bài nhé . (Xem nội dung chương trình Linux Advance trên trang Nhất Nghệ) - Mục tiêu đề ra là: Xây dựng một hệ thống DataBase Server, Web Server và Firewall chạy ở chế độ Load Balancing trên nền Linux với mức độ "available" đến 99%. - Sẽ post tuần tự từng bài lab theo thứ tự sau: Bài Lab 1: Building MySQL Database Replication Bài Lab 2: Building Linux Cluster Bài Lab 3: Building MySQL Database Replication và Failover Bài Lab 4: Building Web Servers kết nối đến Database Servers Bài Lab 5: Building Web Servers Load Balacing & Failover Bài Lab 6: Building Firewall server Bài Lab 7: Building Firewall Load Balancing & Failover.

1. Replication là gì?

• •

•

•

Replication có ý nghĩa là “nhân bản”, là có một phiên bản giống hệt phiên bản đang tồn tại, đang sử dụng. Với cơ sở dữ liệu, nhu cầu lưu trữ lớn, đòi hỏi cơ sở dữ liệu toàn vẹn, không bị mất mát trước những sự cố ngoài dự đoán là rất cao. Vì vậy, người ta nghĩ ra khái niệm “nhân bản”, tạo một phiên bản cơ sở dữ liệu giống hệt cơ sở dữ liệu đang tồn tại, và lưu trữ ở một nơi khác, đề phòng có sự cố. Phiên bản cơ sở dữ liệu phục vụ ứng dụng được lưu trữ trên server master. Phiên bản cơ sở dữ liệu “nhân bản” được lưu trữ trên server slave. Quá trình nhân bản từ master sang slave gọi là replication. Khi có một thay đổi trên cơ sở dữ liệu master, master sẽ ghi xuống log file (log ở dạng binary). Slave đọc log file, thực hiện những thao tác trong log file. Việc ghi, đọc log theo dạng binary được thực hiện rất nhanh.

2. Mô hình MySQL replication gồm có 2 thành phần: a. MySQL master b. MySQL slave 3. Cách thức hoạt động: • Tại thời điểm hoạt động bình thường mọi request sẽ được đưa đến vào MySQL master. Khi MySQL master gặp sự cố, request sẽ được đẩy qua cho MySQL slave xử lí. Khi MySQL master up lại bình thường, request sẽ được trả về cho MySQL master. • Quá trình chuyển đổi vai trò giữa MySQL master và MySQL slave sẽ được giới thiệu ở bài hướng dẫn sau. • Bài hướng dẫn đầu tiên chỉ nêu các bước để cấu hình MySQL master và MySQL slave replicate cho nhau. 4. Mục đích của bài hướng dẫn này: a. Cấu hình MySQL master. b. Cấu hình MySQL slave. c. Mọi thay đổi trên MySQL master đều được thực hiện trên MySQL slave, luôn luôn đảm bảo dữ liệu trên MySQL master và MySQL slave là giống nhau. 5. Các bước cấu hình: a. Giả sử máy tính MySQL master có hostname là master.mydomain.com. Máy tính MySQL slave có hostname là slave.mydomain.com. b. Cài đặt mysql bằng các gói rpm trên MySQL master và MySQL slave. c. Start mysql trên MySQL master và MySQL slave. d. Cấu hình master: - Tạo user cho phép MySQL slave được quyền REPLICATE mysql> GRANT REPLICATION SLAVE ON *.* -> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass'; - Sửa trong file /etc/my.cnf những option sau:

[mysqld] log-bin=mysql-bin server-id=1 innodb_flush_log_at_trx_commit=1 sync_binlog=1 - Start mysql trên MySQL master e. Cấu hình slave: - Sửa trong file /etc/my.cnf option sau: server-id=2 - Start mysql trên MySQL slave. - Để replication, cần xem tình trạng ghi log hiện tại của MySQL master, để điều khiển slave bắt đầu replicate như thế nào. - Ngưng mọi tác động trên cơ sở dữ liệu MySQL master sql> FLUSH TABLES WITH READ LOCK; - Xem tình trạng của MySQL master mysql > SHOW MASTER STATUS; +---------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------+----------+--------------+------------------+ | mysql-bin.003 | 73 | test | manual,mysql | +---------------+----------+--------------+------------------+ - Cấu hình những thông tin cần thiết, để slave giao tiếp được với master: mysql> CHANGE MASTER TO -> MASTER_HOST='master.mydomain.com', -> MASTER_USER='repl', -> MASTER_PASSWORD='slavepass', -> MASTER_LOG_FILE='recorded_log_file_name', -> MASTER_LOG_POS=recorded_log_position; - Ghi chú: giá trị MASTER_LOG_FILE ở đây là file name [mysql-bin.003] và MASTER_LOG_POS là giá trị [Position] của câu lệnh SHOW MASTER STATUS; - Nếu trước khi thực hiện replication, master không ghi thành log file, thì giá trị tương ứng ở đây là: chuỗi rỗng (“”) và 4. - Giải phóng các table trên master: mysql> UNLOCK TABLES;

- Hoàn tất quá trình cấu hình, test thử. f. Master đã có dữ liệu: - Giả sử trước khi thực hiện mô hình replication, master đã có dữ liệu. Vậy ta cần migrate dữ liệu qua slave trước, trước khi thực hiện các bước replication như ở trên. - Trên master, ngưng những tác động làm thay đổi cơ sở dữ liệu, dump database: sql> FLUSH TABLES WITH READ LOCK; shell> mysqldump --all-databases --master-data > dbdump.db - Import cơ sở dữ liệu này vào MySQL slave. - Tương tự phần trên, nếu trước khi thực hiện replication, MySQL master có ghi log, cần xem tình trạng log tại thời điểm đó, để cấu hình cho MySQL slave bắt đầu replication tại điểm nào mysql > SHOW MASTER STATUS; +---------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------+----------+--------------+------------------+ | mysql-bin.003 | 73 | test | manual,mysql | +---------------+----------+--------------+------------------+ - Cấu hình những thông tin cần thiết, để slave giao tiếp được với master: mysql> CHANGE MASTER TO -> MASTER_HOST='master.mydomain.com', -> MASTER_USER='repl', -> MASTER_PASSWORD='slavepass', -> MASTER_LOG_FILE='recorded_log_file_name', -> MASTER_LOG_POS=recorded_log_position; - Giải phóng các table trên master, start mysql trên MySQL slave mysql> UNLOCK TABLES; - Hoàn tất quá trình cấu hình, test thử. 1/ Mô hình master-master replication: • Theo mô hình MySQL master-slave replication mình đã trình bày, dữ liệu sẽ được replicate như sau:

•

• •

•

Khi dữ liệu thay đổi trên master, dữ liệu sẽ được tự động replicate sang slave server. Tuy nhiên, nếu dữ liệu thay đổi trên slave, thì sẽ không được replicate sang master. Điều này có nghĩa là, mô hình master-slave replication chỉ có tính dự phòng, không có khả năng load balacing (share tải giữa 2 máy master và slave). Theo câu hỏi của miss_Van, mình trình bày thêm mô hình master-master replication. Khi dữ liệu thay đổi trên master, dữ liệu sẽ được tự động replicate sang slave, đồng thời khi dữ liệu thay đổi trên slave, thì cũng sẽ được tự động replicate sang master.

2/ Cơ sở cấu hình: Để cấu hình replication hai chiều, ta tiến hành cấu hình 2 mô hình master-slave replication lồng vào nhau. Bước 1: ServerA là master, ServerB là slave. Bước 2: ServerB là master, ServerA là slave. Như vậy, kết hợp 2 lần cấu hình, ta sẽ được: + Khi dữ liệu thay đổi trên ServerA, dữ liệu sẽ replicate qua ServerB (theo cấu hình replication của bước 1) + Đồng thời, khi dữ liệu thay đổi trên ServerB, dữ liệu sẽ replicate qua ServerA (theo cấu hình replication của bước 2). 3/ Chi tiết cấu hình: Bước 1: ServerA là master, ServerB là slave: cấu hình như bài lab 1 đã hướng dẫn. Bước 2: Chia làm các bước nhỏ như sau: a. ServerB là master, sửa những nội dung sau trong file /etc/my.cnf master-host = [IP ServerA] master-user = repl master-password = slavepass

master-port = 3306 log-bin binlog-do-db=adam b. Tạo quyền replication trên ServeB cho ServerA: grant replication slave on *.* to 'repl'@[IP ServerA] identified by 'slavepass2'; c. Để đưa ServerA thành slave của ServerB, sửa nội dung file /etc/my.cnf log-bin binlog-do-db=adam binlog-ignore-db=mysql binlog-ignore-db=test server-id=1 #information for becoming slave. master-host = [IP ServerB] master-user = repl master-password = slavepass2 master-port = 3306 d. Tiếp tục, làm lại các bước SHOW MASTER STATUS trên ServerB và START SLAVE trên ServerA như đã làm ở bước 1. Vậy là bạn đã có mô hình master-master replication hai chiều. Hoàn tất, test thử. 1.Mở đầu: Nếu các bạn search trên google, cụm từ “LVS Linux Virtual Server” có lẽ sẽ được một số lượng bài đáng kể, cả tiếng Anh và tiếng Việt. Với các bài hướng dẫn tiếng Anh thì rất đầy đủ, cả về lý thuyết lẫn chi tiết cấu hình, tuy nhiên số người chịu khó đọc các tài liệu này lại không nhiều, và phần lớn cho rằng đó là những điều “cao siêu, khó hiểu”. Với các bài viết tiếng Việt, thì theo mình đa số là hướng dẫn cấu hình, mà bỏ qua bước trình bày lý thuyết, thậm chí cũng ít bài viết chịu khó trình bày cấu hình như thế để được mục đích gì. (Chỉ biết cấu hình như thế thì sẽ chạy). Đó là nhận xét chủ quan của mình khi mình tìm kiếm tài liệu để đọc, cũng có thể các bạn tìm được bài viết hay hơn nhiều bài viết của mình, nếu như thế thì các bạn không cần đọc tiếp. Mình viết bài viết này mong muốn giúp những ai “thật sự muốn tìm hiểu” hiểu được lý thuyết, hoạt động của mô hình LVS. Song song với lý thuyết, mình sẽ đưa ra cách cấu hình cụ thể để giúp các bạn dễ hình dung. Hi vọng giúp ích được cho các bạn qua bài viết này. Bài viết tham khảo hình ảnh, nội dung từ trang chủ của LVS www.linuxvirtualserver.org. Ngoài ra, không copy từ mọi tài liệu khác. 2.Khái niệm LVS: LVS (Linux Virtual Server) là một server ảo được xây dựng dựa trên một cluster của các

server thật. Với người sử dụng thì họ chỉ nhìn thấy một server ảo đầy quyền năng, không hề biết đến kiến trúc bên trong.

Như mô tả của hình trên, khi sử dụng Virtual Server, người sử dụng bên ngoài Internet chỉ nhìn thấy một địa chỉ IP, đó là địa chỉ IP của Load balancer. Load balancer là máy tính duy nhất liên lạc, nhận request từ các máy ngoài Internet. Sau đó, load balancer sẽ có cơ chế tự động phân chia request đến các real server bên trong. Load balancer và các real server có thể liên lạc qua một đường truyền mạng LAN tốc độ cao, hoặc cũng có thể liên lạc qua mạng WAN. Để đảm bảo hệ thống hoạt động trong suốt với người sử dụng cần đảm bảo các vấn đề sau: • Khi load balancer bị lỗi, phải có cơ chế back up tốt để hoạt động của hệ thống vẫn tiếp diễn. • LVS phải có cơ chế để tự động cập nhật khi có một real server tham gia hoặc tách khỏi hệ thống. • Khi một real server bị lỗi, hệ thống phải phát hiện được để đảm bảo hoạt động không bị gián đoạn. • Mặt khác để hệ thống có thể hoạt động hiệu quả cần giải quyết vấn đề phân chia request hợp lí, tránh tình trạng một real server xử lí quá tải, trong khi các real server khác lại ở tình trạng “idle”. 3.Các mô hình LVS: Để triển khai ý tưởng của LVS, người ta có 3 mô hình chính: • Virtual server via NAT. • Virtual server via IP Tunneling. • Virtual server via Direct Routing.

Mỗi mô hình có một số ưu, khuyết điểm khác nhau. Tùy theo cách triển khai, tùy theo thực trạng và yêu cầu của hệ thống mà ta có thể lựa chọn một mô hình thích hợp. 4.Mô hình Virtual Server via NAT: Với mô hình NAT, dòng chuyển dữ liệu được thực hiện như sau: • Client gởi request cho load balancer. • Load balancer phân chia request đến cho những real server. • Real server gởi reponse cho load balancer. • Load balancer chuyển reponse cho client. Load balancer có 2 địa chỉ: một để liên lạc với client, một để liên lạc với các real server bên trong. Địa chỉ để liên lạc với real server cũng như địa chỉ của các real server có thể là địa chỉ private. Địa chỉ mà load balancer sử dụng để liên lạc với client là địa chỉ public (địa chỉ thật).

Điểm bất lợi lớn nhất của mô hình NAT là Load balancer có thể sẽ trở thành một “bottle neck” bởi vì tất cả request và reponse đều sẽ phải đi qua điểm này. Mô hình NAT chỉ có thể phục vụ khoảng 10-20 real server. Để khắc phục nhược điểm của mô hình NAT, ta có thể sử dụng mô hình Tunnel hoặc mô hình Direct Routing tùy theo yêu cầu triển khai cụ thể. 5.Mô hình Virtual Server via Tunneling: Với mô hình Tunneling, dòng dữ liệu lưu chuyển như sau:

• • •

Client gởi request cho Load balancer. Load balancer phân chia request cho các real server. Các real server sau khi được phân chia sẽ tự động liên lạc với các client bằng con đường riêng, không thông qua Load balancer.

Mô hình Tunneling sẽ giảm được tình trạng “bottle neck” cho load balancer. Load balancer chỉ đảm nhận nhiệm vụ lập lịch, phân chia request đến các real server. Với mô hình này, một load balancer có thể phục vụ cho khoảng 100 real server.

Tuy nhiên để triển khai mô hình Tunneling, bắt buộc tất cả real server phải cài hệ điều hành có cơ chế “IP Tunneling”. Muốn hiểu rõ hơn vấn đề này, các bạn tìm hiểu trên trang www.linuxvirtualserver.org. 6.Mô hình Virtual Server via Direct Routing: Giống mô hình Tunneling, mô hình Direct Routing chỉ nhận request và lập lịch xử lí. Các real server sẽ gởi reponse cho client theo một con đường riêng, không thông qua load balancer. Mô hình Direct Routing đòi hỏi load balancer và real server phải thuộc cùng một segment vật lí.

7.Cách triển khai các mô hình: Trước hết để Linux hỗ trợ LVS, cần thực hiện những việc sau: • Cài đặt gói các gói heartbeat. • Thực hiện các thao tác chặn ARP. (tìm hiểu kỹ hơn vấn đề này trên trang www.linuxvirtualserver.org). • Tùy theo mô hình chọn sử dụng (NAT, Tunneling, Direct Routing), ta sẽ chọn các cấu hình thích hợp. • Các bạn có thể tìm hiểu cách cấu hình cụ thể của từng mô hình trên trang www.linuxvirtualserver.org. Ở đây chỉ trình bày cách cấu hình cụ thể với mô hình LVS via Direct Routing 8.Các bước triển khai LVS via Direct Routing: a.Mô hình: Ở đây, giới thiệu một mô hình chuẩn gồm 4 server: Load balancer Master (Master), Load balancer (Backup), Real1, Real2. Ta test thử với dịch vụ HTTP. Khi client ở ngoài, gởi request http vào, request sẽ được tiếp nhận bởi Master, sau đó, Master sẽ tiến hành phân chia request cho Real1, và Real2. Master và Backup sẽ dùng tín hiệu heartbeat để trao đổi với nhau, nếu Master có sự cố, thì Backup sẽ thay thế vai trò của Master, và Master trở thành Backup. Khi Master khắc phục xong sự cố, Backup sẽ nhường lại vai trò cho Master. Master sẽ dùng ldirectord để monitor Real1 và Real2. Nếu Real1 có sự cố, Master sẽ chỉ chia request cho Real2 và ngược lại. Khi Real1 khắc phục xong sự cố, Master lại tiếp tục

chia request cho Real1. Giả sử hostname của các máy lần lượt là: Master, Backup, Real1, Real2. (Cần dùng lệnh uname –n để xác định chính xác hostname của các máy). • Master: eth0: 192.168.1.2, eth1: 172.16.1.2 • Backup: eth0: 192.168.1.3, eth1: 172.16.1.3 • Real1: 192.168.1.4 • Real2: 192.168.1.5 • VIP: 192.168.1.1 (IP ảo, Client gởi request đến IP này). • Master & Backup bắt buộc phải có 2 card mạng: eth0 để lắng nghe request từ bên ngoài, và eth1 để nhận tín hiệu heartbeat với nhau.

Đầu tiên, các bạn làm quen với mô hình chuẩn, gồm đủ các thành phần: Master, Backup, Real1, Real2. Khi đã hiểu nguyên tắc hoạt động, với các bài lab sau, mình sẽ hướng dẫn các bạn cách tinh chỉnh để giảm số server, mà vẫn đảm bảo được ý nghĩ logic của mô hình. a.Cài đặt: Cài đặt các gói heartbeat trên Master và Backup bằng lệnh: # yum install heartbeat* Hoặc cụ thể hơn, có thể cài đặt tất cả các gói rpm cho Master và Backup theo trình tự sau: # rpm –ivh heartbeat-pils-1.2.3.cvs.20050927-1.rh.el.um.1.i386.rpm # rpm –ivh libnet-1.1.2.1-1.rh.el.um.1.i386.rpm # rpm –ivh perl-Authen-SASL-2.08-1.rh.el.um.1.noarch.rpm # rpm –ivh perl-Convert-ASN1-0.18-1.rh.el.um.1.noarch.rpm # rpm –ivh perl-Net-SSLeay-1.25-1.rh.el.um.1.i386.rpm # rpm –ivh perl-IO-Socket-SSL-0.96-1.rh.el.um.1.noarch.rpm # rpm –ivh perl-Parse-RecDescent-1.94-1.rh.el.um.1.noarch.rpm

# rpm –ivh perl-Mail-IMAPClient-2.2.9-1.rh.el.um.1.noarch.rpm # rpm -ivh heartbeat-stonith-1.2.3.cvs.20050927-1.rh.el.um.1.i386.rpm # rpm –ivh perl-XML-NamespaceSupport-1.08-1.rh.el.um.1.noarch.rpm # rpm –ivh perl-XML-SAX-0.12-1.rh.el.um.1.noarch.rpm # rpm –ivh perl-ldap-0.3202-1.rh.el.um.1.noarch.rpm # rpm –ivh heartbeat-1.2.3.cvs.20050927-1.rh.el.um.1.i386.rpm # rpm –ivh heartbeat-ldirectord-1.2.3.cvs.20050927-1.rh.el.um.1.i386.rpm # rpm –ivh ipvsadm-1.21-1.rh.el.1.um.1.i386.rpm Cài đặt các gói sau trên Real1 và Real2: # rpm –ivh arptables-noarp-addr-0.99.2-1.rh.el.um.1.noarch.rpm # rpm –ivh arptables_jf-0.0.7-0.3E.i386.rpm Ghi chú: tùy theo cách cài đặt perl kèm theo hệ điều hành ban đầu, các gói perl trên đây có thể thiếu, hoặc có thể thừa. Có thể bổ sung cho đúng với cách cài đặt hệ điều hành. RPM download tại: http://www.ultramonkey.org b.Các bước cấu hình: Như đã trình bày, phần cấu hình cho Master sẽ gồm các bước sau: • Cấu hình hearbeat để Master và Backup lắng nghe nhau. • Cấu hình ldirectord để Master monitor Real1 và Real2 c.Cấu hình heartbeat: Phần này cấu hình cho cả Master và Backup. Các file cần cấu hình cho dịch vụ heartbeat là: file ha.cf, haresources, authkeys. Chép các file này vào thư mục /etc/ha.d cp /usr/share/doc/heartbeat-1.2.3.cvs.20050927/ha.cf /etc/ha.d/ cp /usr/share/doc/heartbeat-1.2.3.cvs.20050927/authkeys /etc/ha.d/ cp /usr/share/doc/heartbeat-1.2.3.cvs.20050927/haresources /etc/ha.d Sửa các tham số sau trong file ha.cf: udpport 694 # Port để gởi tín hiệu heartbeat bcast eth1 # Card mạng để gởi tín hiệu heartbeat keepalive 2 deadtime 30 initdead 120 node Real1 Real2 ( Sử dụng lệnh uname –n để xác định chính xác tên server real). Sửa các tham số sau trong file authkeys: auth 1 1 sha1 lvsvtdns11 Chuẩn bị các script để đặt vào file haresources: ldirectord.cf. Thêm dòng sau vào file haresources.

Master 192.168.1.1 \ ldirectord::ldirectord.cf \ LVSSyncDaemonSwap::master \ d.Cấu hình ldirectord: Phần này cấu hình cho cả Master và Backup. ldirectord cần có file ldirectord.cf. File này có nội dung như sau: checktimeout=3 checkinterval=5 autoreload=yes logfile="/var/log/ldirectord.log" virtual=192.168.1.1:80 real=192.168.1.4:53 gate 5 real=192.168.1.5:53 gate 5 request="/.testpage" receive="test page" scheduler=rr service=http checkcount=3 protocol=tcp e.Cầu hình cho Real1, Real2: • Trên Real1 và Real2 cần cấu hình dịch vụ http. • Tạo một trang web test cho dịch vụ http, đặt trong Document Root. echo "test page" > .testpage • Tạo IP ảo cho các Real1 và Real2: ifconfig eth0:0 192.168.1.1 netmask 255.255.255.0 • Chặn ARP trên IP ảo của các Real1 và Real2: /usr/sbin/arptables-noarp-addr 192.168.1.1 start /etc/init.d/arptables_jf save /etc/init.d/arptables_jf restart f.Test thử cấu hình: • Sau khi thực hiện xong các bước cấu hình trên, thực hiện test như sau: • Trên Master, thực hiện: # service heartbeat start • Trên Backup, thực hiện: # service heartbeat start • Trên Master, xem kết quả:

# ipvsadm Nếu hiển thị kết quả bảng phân chia request có IP của Real1, Real2 là đúng. • Trên Backup, xem kết quả: # ipvsadm Vì backup, lúc này chỉ đang đứng lắng nghe, trên không có bảng phân chia request. • Từ Client kết nối dịch vụ http, hoạt động bình thường, dùng lại lệnh ipvsadm trên Master, sẽ thấy request được phân chia cho Real1 hoặc Real2.

Khi các bạn đã nắm được mô hình cluster gồm 4 thành phần, hiểu được nguyên tắc cấu hình của từng thành phần master, slave, real, các bạn hoàn toàn có thể tùy biến và kết hợp cluster với các mô hình khác, để đáp ứng nhu cầu của các bạn. Mình trình bày sự kết hợp giữa MySQL replication và cluster để đạt được mô hình MySQL replication fail over. 1. Mô hình MySQL replication và failover:

2. Mô tả hoạt động: • Hai server MySQL-1 và MySQL-2 được cấu hình theo mô hình master-master replication hoặc master-slave replication để đảm bảo dữ liệu luôn giống nhau. • Đưa MySQL-1 và MySQL-2 vào một cluster gồm có 2 thành phần. Cluster này không share tải, chỉ đảm bảo cho client luôn truy cập được MySQL không bị gián đoạn. • MySQL-1 và MySQL-2 được cài đặt heartbeat. MySQL-1 đóng vai trò master, MySQL-2 đóng vai trò slave. (Vì không share tải, nên không có real server). • Master và Slave được cấu hình dùng chung một VIP. Khi master sống, VIP này chính là master. Master và slave lắng nghe heartbeat với nhau, khi heartbeat detect master chết, nó sẽ chuyển VIP cho slave. • Client chỉ kết nối với VIP, không quan tâm đó thực sự là master hay slave. Dữ liệu luôn được đồng bộ vì đã được cấu hình master-master replication. 3. Các bước cài đặt: • Cài đặt, cấu hình mô hình master-slave replication hoặc master-master replication như hướng dẫn ở bài Lab1. • Cài đặt, cấu hình mô hình cluster cho MySQL-1 đóng vai trò master, MySQL-2 đóng vai trò slave như hướng dẫn ở bài Lab2. (Lưu ý cluster này chỉ gồm 2 thành phần master & slave, không có các real server). • Sau khi hoàn tất mô hình, từ client truy cập vào VIP, gởi request.

•

Test khả năng fail over của mô hình, bằng cách stop heartbeat trên master, khi đó VIP được chuyển sang slave, client vẫn kết nối bình thường.