Xây dựng hệ thống Linux cluster

[emailhoc]

1.Mở đầu:
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.