ĐỒ án tốt NGHIỆP đại học NGHIÊN cứu, TRIỂN KHAI THỬ NGHIỆM hệ THỐNG CHỊU lỗi với mô HÌNH CLUSTER

MỤC LỤC
Đề mục Trang
LỜI MỞ ĐẦU 1
CHƯƠNG I. CƠ BẢN VỀ CLUSTER 3
CHƯƠNG II. CLUSTERING MỨC HỆ ĐIỀU HÀNH 24
LỜI MỞ ĐẦU
Trong thời đại bùng nổ của công nghệ thông tin hiện nay, mạng máy tính
đóng vai trò ngày càng quan trọng hơn trong hoạt động của các doanh
1
nghiệp, tổ chức cũng như các cơ quan nhà nước. Thậm chí ở một số đơn vị,
chẳng hạn như các công ty hàng không hoặc các ngân hàng lớn, mạng máy
tính có thể ví như hệ thần kinh điều khiển hoạt động của toàn doanh nghiệp.
Sự ngừng hoạt động của mạng máy tính trong những cơ quan này có thể làm
tê liệt các hoạt động chính của đơn vị, và thiệt hại khó có thể lường trước
được.
Chúng ta đều biết các máy chủ là trái tim của của mạng máy tính, nếu máy
chủ mạng hỏng, hoạt động của hệ thống sẽ bị ngưng trệ. Điều đáng tiếc là dù
các hãng sản xuất đã cố gắng làm mọi cách để nâng cao chất lượng của thiết
bị, nhưng những hỏng hóc đối với các thiết bị mạng nói chung và các máy
chủ nói riêng là điều không thể tránh khỏi. Do vậy, vấn đề đặt ra là cần có
một giải pháp để đảm bảo cho hệ thống vẫn hoạt động tốt ngay cả khi có sự
cố xảy ra đối với máy chủ mạng, và công nghệ clustering (bó) là câu trả lời
cho vấn đề này. Ngày nay, trong môi trường công nghệ thông tin hiện đại,
chúng ta đã khá quen thuộc khái niệm Clustering. Vậy bản chất cốt lõi của
Clustering là gì? Và nó đem lại lợi ích gì khi ứng dụng công nghệ này?
2
CHƯƠNG I. CƠ BẢN VỀ CLUSTER
1.1 Khái niệm Clustering
Clustering là một kiến trúc nhằm đảm bảo nâng cao khả năng sẵn sàng
cho các hệ thống mạng máy tính. Clustering cho phép sử dụng nhiều máy
chủ kết hợp với nhau tạo thành một cụm (cluster) có khả năng chịu đựng hay

chấp nhận sai sót (fault-tolerant) nhằm nâng cao độ sẵn sàng của hệ thống
mạng. Cluster là một hệ thống bao gồm nhiều máy chủ được kết nối với
nhau theo dạng song song hay phân tán và được sử dụng như một tài nguyên
thống nhất. Nếu một máy chủ ngừng hoạt động do bị sự cố hoặc để nâng
cấp, bảo trì, thì toàn bộ công việc mà máy chủ này đảm nhận sẽ được tự
động chuyển sang cho một máy chủ khác (trong cùng một cluster) mà không
làm cho hoạt động của hệ thống bị ngắt hay gián đoạn. Quá trình này gọi là
khả năng chống chịu lỗi (fail-over); và việc phục hồi tài nguyên của một
máy chủ trong hệ thống (cluster) được gọi là “fail-back”.
Nếu giả sử chúng ta sử dụng MSCS (Microsoft Cluster Server), trong hệ
thống Cluster này có N máy tính kết nối. Các máy tính khác trong mạng có
thể truy xuất tài nguyên từ N máy tính trên. Để làm được việc này, người sử
dụng chỉ cần gọi tên cluster mà không cần biết tên riêng của các máy tính
trong nhóm. Như vậy hệ thống cluster luôn đảm bảo khả năng cung cấp tài
nguyên cho người sử dụng mà client sẽ không biết là tài nguyên này đang
được điều khiển bởi máy tính nào (đây là tính năng trong suốt đối với người
sử dụng). Điều này có nghĩa là các Client sẽ được tách biệt và được bảo vệ
bởi những thay đổi về mặt vật lý của hệ thống Cluster. Hầu hết thì lợi ích
quan trọng nhất của Cluster đó là tính sẵn sàng cao “High Availibility”. Tài
nguyên trên các máy chủ Cluster cũng có khả năng sẵn sàng cao như là tài
nguyên của Cluster. Nếu môt node (tức là một máy tính, một máy chủ) trong
hệ thống Cluster không sẵn sàng (ví dụ như là chưa được khởi động) hoặc là
3
có quá trình tiến trình đang chạy trên đó khiến máy chủ này không thể đáp
ứng được các yêu cầu khác thì ngay lập tức các yêu cầu này được chuyển
sang node còn lại có khả năng đáp ứng được, một cách trong suốt đối với
Client. Chính vì vậy mà các Client không cần biết được chính xác vị trí của
tài nguyên đang sử dụng này là ở đâu. Ví dụ, khi một Client có yêu cầu sử
dụng một ứng dụng trên Cluster, thì Client này sẽ không cần biết tài nguyên
vật lý đang nằm ở đâu (tức là trên máy chủ nào quản lý) và cũng không biết

được máy chủ nào đang thực sự xử lý yêu cầu này. Một cách đơn giản,
người sử dụng chỉ việc truy nhập vào các ứng dụng một cách trong suốt và
luôn sẵn sàng, tin cậy cao.
Hình 1.1: Cấu trúc của hệ thống Cluster.
Một lợi ích khác là dễ dàng mở rộng về quy mô trong mô hình Cluster, ví
dụ khi xây dựng hệ thống Cluster ban đầu có thể về mặt kinh phí hoặc chưa
rõ lợi ích của Clustering đem lại, hệ thống chỉ được xây dựng dựa trên 2
Node. Nhưng nếu muốn hệ thống vẫn có thể được mở rộng thành 4 node, 8
node, tùy thuộc vào nhu cầu mà vẫn không gây ra ảnh hưởng gì đến hệ
thống đang vận hành, không có thời gian chết “downtime” của hệ thống. Để
tăng hiệu năng của hệ thống cũng có thể lắp thêm các CPU (Central
Processing Unit) (tạo thành máy SMP Symmetric Multiprocessing ), tăng
bộ nhớ truy cập ngẫu nhiên RAM, cho hệ thống Cluster. Tuy việc này
4
cũng làm cho hiệu năng của hệ thống nhưng nó không phải là giải pháp có
tính lâu dài đối với việc mở rộng quy mô, chia sẻ các ứng dụng trên hệ
thống. Hình vẽ sau mô tả việc mở rộng hệ thống Cluster và việc sử dụng
SMP
Hình 1.2: mô tả việc mở rộng hệ thống Cluster và việc sử dụng SMP
Khi muốn mở rộng quy mô của hệ thống Cluster chỉ đơn giản là việc mở
rộng CPU, RAM thì sẽ gây ra các vấn đề về “bottleneck” (nghẽn cổ chai)
khi mà tất cả các yêu cầu được gửi đến Cluster, làm cho CPU phải tính toán
nhiều hơn, bộ nhớ RAM được truy cập nhiều hơn làm lưu lượng trên BUS
bộ nhớ tăng lên đáng kế làm giới hạn thông lượng, và giảm hiệu năng của hệ
thống.
1.1.1 Lợi ích của hệ thống Cluster
Có rất nhiều lý do khác nhau để đưa ra mô hình xây dựng hệ thống
Cluster. Chúng ta luôn muốn đạt được, xây dựng một hệ thống có tính sẵn
sàng cao “High Availability” và tính dễ dàng mở rộng “Scalability” và
những đặc điểm này được nói rất nhiều bởi nó là đặc điểm nổi trội của

Cluster.
• Tính sẵn sàng cao (High Availability)
5
Nếu một Node trong Cluster có lỗi, thì toàn bộ tác vụ sẽ ngay lập tức
được chuyển sang xử lý bởi một Node (hoặc các Node còn lại) trong hệ
thống Cluster (nếu trong hệ thống không có máy chủ Cluster thì nếu một
máy chủ nào đó có lỗi thì toàn bộ ứng dụng hoạt động trên máy chủ này sẽ
tạm thời ngừng phục vụ).
• Dễ dàng mở rộng (Scalability)
Cùng với sự phát triển của hệ thống cả về sự đòi hỏi về tài nguyên, sự
tăng trưởng của ứng dụng thì hệ thống Cluster sẽ ngày càng trở nên quả tải
nếu không được mở rộng. Với hệ thống Clustering, nếu muốn giải quyết khó
khăn này thì hoàn toàn không khó khăn, một Node sẽ dễ dàng được thêm
vào Cluster với thời gian “no-downtime” hoặc “downtime” là tối thiếu.
• Hiệu suất (Performance)
Việc sử dụng Cluster để “Load Balancing” (cân bằng tải) sẽ đáp ứng
được số lượng tối đa người sử dụng đồng thời và tận dụng được tối đa tài
nguyên của hệ thống Cluster.
• Chi phí/Hiệu năng (Price/Performance)
Việc sử dụng hệ thống Cluster đem lại hiệu quả cao tính trên chi phí đầu
tư.
• Dễ dàng quản lý (Managebility)
Với hệ thống Cluster, người quản trị cũng rất dễ dàng quản lý chỉ thông
qua một giao diện duy nhất, có thể chuyển tài nguyên ứng dụng giữa các
Node (được dụng để điều khiển cân bằng tải)
1.1.2 Khái niệm tính sẵn sàng cao
Hầu hết các ứng dụng trong các hệ thống thông tin đều đòi hỏi tính sẵn
sàng cao hoặc thời gian “uptime” của hệ thống được liên tục. Những ứng
dụng nhậy cảm với lỗi (đòi hỏi tính sẵn sàng cao, không cho phép ngừng hệ
thống) như là các máy chủ e-business, không thể ngừng hệ thống vì bất cứ lý

6
do nào. Tuy nhiên, bởi vì các hệ thống máy tính được xây dựng sử dụng các
linh kiện điện tử nên cũng rất có thể có lỗi, cả về phần cứng và phần mềm.
Các nhà thiết kế hệ thống phải làm sao phải loại bỏ các lỗi như này và giảm
thiểu các ảnh hưởng.
Một cách truyền thống trước đây, các ứng dụng này sử dụng một hệ
thống máy tính lớn (mainframe) rất tin cậy đối với các ứng dụng nhậy cảm
với lỗi này. Các hệ thống này có nhược điểm rất lớn đó là chi phí trên hiệu
năng “price/performance” thường rất cao. Ngày nay, các ứng dụng này hầu
hết được chạy trên các máy chủ hệ thống trên nền Intel, có tính cạnh tranh
hơn về price/performance.
Trước khi xem xét vấn đề làm thể nào để tăng cường khả năng sẵn sàng
của hệ thống, chúng ta sẽ định nghĩa nó gần gũi hơn. Đơn giản có thể hiểu,
tính sẵn sàng là phần trăm thời gian mà hệ thống vận hành và sẵn sàng với
các ứng dụng của người sử dụng. Tính sẵn sàng được tính bằng thời gian
trong suốt khoảng thời gian mà hệ thống sẵn sàng, ví dụ nếu ứng dụng yêu
cầu hệ thống luôn sẵn sàng từ 6 AM đến 11 PM hàng ngày, thì thời gian
downtime để bảo dưỡng hệ thống được tính từ 11:01 PM đến 5:59 AM của
ngày hôm sau sẽ không được tính vào thời gian sẵn sàng. Tuy nhiên, nếu hệ
thống đòi hỏi liên tục 24x7 thì bất cứ thời điểm nào hệ thống ngừng hoạt
động cũng được xem là thời gian downtime của hệ thống. Khả năng sẵn sàng
của hệ thống mainframe là khoảng 99.5% nhưng đối với hệ thống sẵn sàng
cao ngày nay, có thể đạt tới 99.99% và có thể còn tốt hơn nữa. Có thể đạt
được con số này, các người thiết kế hệ thống phải thiết kế rất chi tiết và phải
có kế hoạch dài hạn. Việc thiết kế này thường phải kết hợp với đặc tính chịu
đựng lỗi của hệ thống fault-tolerance.
Các nhà thiết kế hệ thống có kinh nghiệm luôn đưa ra các kiến trúc hệ
thống tối ưu với khả năng sẵn sàng cao, tính chịu đựng lỗi tốt, cho phép hệ
thống vẫn có thể tiếp tục hoạt động ngay cả khi có lỗi trong bất kỳ một thành
7

phần nào trong mạng. Phương pháp phổ biến để tăng khả năng chịu đựng lỗi
của hệ thống là thiết kế các thành phần có tính dự phòng hoặc trên cùng một
máy tính hoặc bất cứ các thành phần nào trên mạng. Điều này làm cho việc
backup có thể thực hiện dễ dàng khi có lỗi.
Có một số thành phần có khả năng dự đoán được lỗi và đưa ra các cách
thức để chống lại các lỗi này hoặc ít ra thì cũng làm giảm thiểu ảnh hưởng
do lỗi này gây ra làm ảnh hưởng đến khả năng vận hành của toàn hệ thống.
Ví dụ, ngay trong các hệ thống không sử dụng công nghệ Cluster, các ổ
cứng sử dụng PFA (Predictive Failure Analysis) có thể cảnh báo hệ thống
sắp có lỗi trên ổ cứng (đĩa cứng sắp hỏng), cho phép Disk Controller chuyển
ổ cứng này sang trạng thái offline và thay thế ổ này bằng ổ cứng dự phòng
nóng Hot Spare mà không can thiệp gì đến hệ thống và không có thời gian
downtime của hệ thống.
Trong giải pháp hệ thống Cluster, tất cả các thành phần chính hoặc các
thành phần phụ của một Node có thể có lỗi nhưng đều không làm ảnh hưởng
đến người dùng. Dịch vụ Clustering sẽ phát hiện ra lỗi và sẽ tự động chuyển
các tác vụ này sang máy chủ khác xử lý và trong suốt đối với người dùng.
Khi xây dựng hệ thống Cluster có tính sẵn sàng cao, có các phân loại như
sau:
Tính sẵn sàng cao là rất quan trọng đối với hầu hết các hệ thống, lỗi trong
hệ thống làm ngừng hoạt động của doanh nghiệp sẽ gây ra các ảnh hưởng rất
lớn đối với người dùng (đặc biệt là đối với các doanh nghiệp như là Ngân
hàng, Hàng không, ), khách hàng.
8
Đòi hỏi về tính sẵn sàng của hệ thống cũng ngày càng tăng, và thời gian
ngừng hệ thống cũng được phân loại như sau:
 Sự vững chắc của server (Server Consolidation)
Server Consolidation có thể đạt được một trong 3 cách sau: Logical
Consolidation, Physical Consolidation, và Re-Centralization.
• Sự vững chắc về logic (Logical Consolidation)

Logical Server Consolidation làm cho môi trường vận hành máy chủ trở
lại làm việc bình thường với các tác vụ như backup và các kết nối người
dùng. Lợi ích là của vấn đề này là làm giảm các thao tác của người quản trị
và giảm tải công việc việc quản lý. Đặc điểm này được gọi là ROI (Return
On Investment) (bảo vệ chi phí đầu tư).
• Sự vững chắc về vật lý (Physical Consolidation)
Các máy chủ đều nằm trong một phạm vi vật lý (phòng server) cho phép
cải thiện tính an ninh ở mức vật lý và tăng dung lượng, khả năng lưu trữ của
máy chủ, môi trường chia sẻ các thiết bị ngoại vi tốt hơn. Điều này có nghĩa
là làm giảm chi phí kết nối cable, đóng gói, phần cứng.
• Re-Centralization
Các máy chủ trong hệ thống Cluster được nhóm lại thành một máy chủ
Logic, có tính năng rất mạnh. Bộ xử lý của máy chủ này có thể luân phiên
được sử dụng để tận dụng tối đa nguồn tài nguyên xử lý, tận dụng tối đa
9
khoảng không gian đĩa cứng của hệ thống. Ngoài ra còn có những lợi thế
sau:
 Chỉ cần duy nhất một hệ điều hành (tất cả các máy trong
hệ thống Cluster đều sử dụng cùng một hệ điều hành).
 Giảm thiểu chi phí về License cho phần mềm hệ điều hành
 Giảm thiểu chi phí về phần mềm các ứng dụng.
 Giảm thiểu số lượng các version phần mềm hệ thống, ứng
dụng hỗ trợ (khi phần mềm đã hỗ trợ 1 Node thì cũng sẽ hỗ trợ các Node
còn lại)
1.2 Các thành phần của dịch vụ Cluster
Dịch vụ Cluster chạy trên mỗi node trong server cluster và điều khiển
mọi hoạt động của server cluster. Cluster service bao gồm nhiều thành phần
software làm việc cùng với nhau. Các thành phần này thực hiện việc theo
dõi, duy trì tính ổn định và vận chuyển các resource từ một node qua một
node khác

• Resource DLLs: cho mỗi ứng dụng chịu trách nhiệm theo dõi và điều
khiển ứng dụng đó. Ví dụ : Resource DLL sao lưu và phục hồi các thuộc
tính của ứng dụng trong Cluster database, mang resource online và offline và
kiểm tra trạng thái của resource đó. Khi cần thiết phải thực hiện failover,
Resource DLL làm việc cùng với Resource Monitor và Failover Manager
để đảm bảo quá trình failover được thực hiện dễ dàng.
• Checkpoint Manager: Để đảm bảo cho việc Cluster service có thể
phục hồi từ một tài nguyên bị lỗi, Checkpoint Manager kiểm tra các khóa
registry khi một tài nguyên được mang online và ghi dữ liệu checkpoint lên
quorum resource khi resource này offline. Một vài ứng dụng chứa thông tin
cấu hình tại cục bộ thay cho việc chứa thông tin trong cơ sở dữ liệu cấu hình
Cluster. Nếu một ứng dụng yêu cầu chứa đựng cục bộ thông tin có thể
failover, Checkpoint Manager cung cấp cho yêu cầu này bằng cách duy trì
10
một bản sao của thông tin cục bộ hiện hành này trên tài nguyên Quorum.
Đối với các ứng dụng chứa thông tin cấu hình trong registry trên server,
Checkpoint Manager theo dõi dữ liệu này khi ứng dụng đang online. Khi
có sự thay đổi xảy ra, Checkpoint Manager cập nhật tài nguyên quorum
với dữ liệu cấu hình hiện hành.
• Database Manager: Chạy trên mỗi node và duy trì một bản sao lưu
cục bộ của cơ sở dữ liệu cấu hình Cluster - chứa những thông tin về những
thực thể vật lý và logic trong một Cluster. Những thực thể này bao gồm bản
thân Cluster, các node thành viên, các nhóm tài nguyên (resource group), các
loại tài nguyên và những mô tả của các loại tài nguyên đặc biệt như là các ổ
đĩa và địa chỉ IP. Database Manager dùng Global Update Manager cho
việc cập nhật lẫn nhau (replicate) tất cả những thay đổi tới các node khác
trong cluster. Theo cách này, những thông tin cấu hình được duy trì qua
Cluster nay cả khi một node bị hỏng và khi Administrator thay đổi cấu hình
Cluster trước khi node đó quay trở lại phục vụ. Database Manager cũng
cung cấp một interface chứa những thay đổi trong cơ sở dữ liệu cấu hình

Cluster thông qua các thành phần dịch vụ Cluster khác như là Failover
Manager và Node Manager. Interface này dùng để tạo ra những thay đổi
tương tự như interface dùng để tạo ra những thay đổi tới registry qua
Windows Programming Interface (API). Những thay đổi khác này được
Database Manager tiếp nhận để cập nhật cho các node khác trong cluster
qua Global Update Manager.
• Event Log Replication Manager: Là một phần của dịch vụ Cluster
làm việc cùng với Event Log Service để sao chép các event log tới tất cả các
node trong Cluster. Các sự kiện này được đánh dấu để cho thấy node nào mà
sự kiện xảy ra trên đó. Các sự kiện được ghi lại trên một node được sắp xếp,
củng cố và gửi qua Event Log Replication Manager để broadcast tới các
node đang hoạt động khác. Nếu một vài sự kiện được ghi lại trong một
11
khoảng thời gian, mỗi sự kiện có thể broadcast một cách riêng lẻ, nhưng nếu
nhiều sự kiện được ghi lại trong một khoảng thời gian ngắn, chúng được kết
hợp với nhau trước khi broadcast. Các sự kiện được dán nhãn để cho biết
node nào chúng được xảy ra. Các node khác tiếp nhận các sự kiện và ghi
chúng lên local log.
• Failover Manager: Quản lý các tài nguyên và các nhóm tài nguyên.
Nó chịu trách nhiệm tắt hay khởi động các tài nguyên, quản lý các tài
nguyên liên quan và chuẩn bị cho một quá trình failover các nhóm tài
nguyên. Để thực hiện các hoạt động này, nó tiếp nhận tài nguyên và thông
tin trạng thái hệ thống từ các thành phần Cluster trên một node và từ
Resource Monitors. Resource Monitors cung cấp môi trường thực hiện cho
các tài nguyên DLL và cung cấp sự giao tiếp giữa các tài nguyên DLL và
FailoverManager. Failover Manager xác định node nào trong Cluster nên
sở hữu nhóm tài nguyên. Khi cần thiết phải failover một nhóm tài nguyên,
Failover Manager trên mỗi node trong Cluster làm việc cùng nhau để tái
chỉ định quyền sở hữu cho nhóm tài nguyên đó. Dựa trên cách mà nhóm tài
nguyên được cấu hình, Failover Manager có thể cục bộ khởi động lại tài

nguyên bị hỏng hay có thể làm cho tài nguyên đó offline đối với các tài
nguyên liên quan với nó và sau đó chuẩn bị cho một quá trình failover.
• Global Update Manager: được dùng bởi các thành phần bên trong
cluster như là Failover Manager hay Database Manager để mang những cập
nhật thay đổi tới mỗi node trong Cluster. Khi quá trình cập nhật xảy ra, nó
bắt đầu tại một node client và một node khác được bổ nhiệm theo dõi việc
cập nhật để đảm bảo việc cập nhật được xảy ra trên tất cả các node. Node
client yêu cầu node này gửi tới một global lock để thực hiện cập nhật. Nếu
lock này chưa sẵn sàng, nó sẽ chờ. Khi lock này sẵn sàng node giám sát sẽ
gán cho node client và chỉ định cập nhật tại cục bộ. Nếu node này cập nhật
thành công mà quá trình update bị lỗi trên một node khác thì node này sẽ bị
12
loại bỏ khỏi danh sách các node đang hoạt động và sự cập nhật tiến hành
trên các node còn hoạt động khác. Nếu việc này xảy ra, quorum log sẽ được
ghi lại để đảm bảo rằng node bị lỗi có thể nhận được tất cả các thông tin cấu
hình cần thiết khi nó quay trở lại hoạt động.
• Log Manager: Cùng với Checkpoint Manager tương tác với nhau
đảm bảo rằng recover log trên tài nguyên quorum chứa đựng dữ liệu cấu
hình mới nhất và các checkpoint thay đổi. Nếu một hay nhiều node trong
Cluster bị hỏng, các node còn hoạt động khác vẫn có thể thực hiện thay đổi
cấu hình. Khi những node này bị hỏng, Database Manager sử dụng Log
Manager để ghi lại sự thay đổi cấu hình lên tài nguyên Quorum. Khi các
node bị lỗi quay trở lại phục vụ, chúng đọc vị trí của tài nguyên quorum
trong local cluster. Các cơ chế được xây dựng bên trong sẽ dò tìm trong cơ
sở dữ liệu cũ những tài nguyên quorum nào không đúng. Sau đó Database
Manager sẽ yêu cầu Log Manager cập nhật bản sao cục bộ của Cluster sử
dụng file checkpoint trong tài nguyên Quorum và sau đó đối chiếu với file
log trong Quorum disk. Kết quả là hoàn thành việc cập nhật Cluster.
• Membership Manager: Chịu trách nhiệm duy trì một một cái nhìn
nhất quán về các node trong Cluster hiện đang hoạt động hay bị hỏng tại một

thời điểm nhất định. Trọng tâm của thành phần này là thuật toán regroup
được yêu cầu thực hiện bất cứ khi nào có dấu hiệu của một hay nhiều node
bị lỗi.
• Node Manager: Chạy trên mỗi node và duy trì một danh sách cục bộ
các node, các network, các network interface trong cluster. Qua sự giao tiếp
giữa các node, Node Manager đảm bảo cho tất cả các node có cùng một
danh sách các node đang hoạt động. Node Manager dùng những thông tin
trong cơ sở dữ liệu cấu hình Cluster để xác định các node nào được thêm
vào hay bị loại bỏ khỏi Cluster. Node Manager trên mỗi node cũng theo dõi
các node khác để tìm ra node bị lỗi. Để thực hiện việc theo dõi, nó gửi và
13
nhận những tin nhắn gọi là các heartbeat tới mỗi node trong Cluster. Nếu
một node có một sự giao tiếp bị lỗi với một node khác, nó gửi broadcast một
tin nhắn tới các node khác sao cho tất cả các node nhận tin nhắn này để xác
nhận lại danh sách các node đang hoạt động trong cluster. Quá trình này gọi
là một regroup event. Node Manager cũng tham gia vào quá trình một node
tham gia vào Cluster. Tại thời điểm một node được thêm vào Cluster, Node
Manager trên node đó thành lập một quá trình giao tiếp với các Node
Manager trên các node khác để thực hiện quá trình chứng thực.
• Resource Monitor: Cung cấp một interface giao tiếp giữa các tài
nguyên DLL và dịch vụ Cluster. Khi Cluster cần lấy dữ liệu từ một tài
nguyên, Resource Monitor tiếp nhận yêu cầu và đẩy yêu cầu đó tới tài
nguyên DLL thích hợp. Ngược lại, khi một tài nguyên DLL cần báo cáo
trạng thái của nó hoặc thông báo cho dịch vụ Cluster một sự kiện, tài nguyên
đẩy thông tin này từ tài nguyên tới dịch vụ Cluster.
• Backup/RestoreManager: Dịch vụ Cluster đưa ra một API dùng để
backup cơ sở dữ liệu cluster, Backup Cluster Database. Backup Cluster
Database trước tiên tương tác với Failover Manager, sau đó đẩy yêu cầu
tới node sở hữu tài nguyên quorum. Database Manager trên node đó sẽ được
yêu cầu và sau đó tạo một bản backup cho quorum log file và các file

checkpoint.
Dịch vụ Cluster cũng đưa ra một API khác, Restore Cluster Database
để restore cơ sở dữ liệu Cluster từ một backup path. API này có thể chỉ được
yêu cầu tại cục bộ từ một trong các node của Cluster. Khi API được yêu cầu,
trước tiên nó tắt dịch vụ Cluster, restore cơ sở dử liệu Cluster từ bản backup,
tạo một giá trị registry chứa backup path và sau đó khởi động lại dịch vụ
Cluster. Dịch vụ Cluster khi khởi động sẽ dò tìm yêu cầu restore và tiến
hành restore cơ sở dữ liệu Cluster từ backup path tới tài nguyên Quorum.
14
1.3 Nguyên tắc hoạt động của dịch vụ Cluster
Khi một node hay một ứng dụng trong Cluster bị lỗi, Server Cluster có
thể phản ứng bằng cách khởi động lại application bị lỗi hay phân tán công
việc từ node bị fail tới các node khác còn hoạt động trong Cluster đó. Dịch
vụ
Cluster kiểm tra tình trạng không hoạt động của các tài nguyên riêng biệt
hay một node, và tự động di chuyển hay khởi động lại các ứng dụng, dữ liệu
và file tài nguyên tới một node còn hoạt động trong Cluster. Quá trình này
cho phép các tài nguyên như là cơ sở dữ liệu, file chia sẻ (file share) và ứng
dụng duy trì tính sẵn sàng cao cho các ứng dụng củau ser và client. Server
Cluster đưa ra 2 cơ chế kiểm tra tình trạng không hoạt động khác nhau:
• Detect Node Failure: Một cách định kỳ, mỗi node trao đổi các gói tin
nhắn với những node khác trong Cluster sử dụng private cluster network.
Những tin nhắn này được gọi là Heartbeat. Sự trao đổi Heartbeat cho phép
mỗi node kiểm tra tính sẵng sàng của các node khác và các ứng dụng của
chúng. Nếu một server bị fail trong việc phản hồi 1 Heartbeat, các server
còn hoạt động bắt đầu một quá trình Failover để đàm phán quyền sở hữu đối
với các tài nguyên và ứng dụng của node bị fail. Việc đàm phán này sử dụng
Challenge và Defense protocol. Việc bị fail trong quá trình phản hồi
Heartbeat có thể xảy ra trong nhiều sự kiện như là computer failure,
network interface failure, network failure, hay trong lúc hoạt động cao bất

thường nào đó. Thông thường, khi tất cả các node giao tiếp với nhau,
Configuration Database Manager gửi Global Configuration Database
update tới mỗi node. Tuy nhiên, khi fail trong quá trình trao đổi heartbeat
xảy ra, Log Manager cũng lưu lại cấu hình database thay đổi tới tài nguyên
Quorum. Nó đảm bảo các node còn hoạt động có thể truy cập thông tin cấu
hình Cluster mới nhất và dữ liệu registry cục bộ trên node trong quá trình
phục hồi
15
• Detect Resource Failure: Failover Managervà Resource Monitors
làm việc cùng với nhau để dò tìm và khôi phục resource bị fail. Resource
Monitors theo dõi trạng thái của tài nguyên bằng cách kiểm tra định kỳ các
tài nguyên sử dụng Resource DLLs. Việc kiểm tra vòng gồm hai bước, một
query LookAlive lướt qua và một query lâu hơn, cuối cùng - IsAlive. Khi
Resource Monitor dò tìm một tài nguyên bị lỗi, nó thông báo cho Failover
Manager và tiếp tục giám sát tài nguyên này. Failover Manager duy trì
trạng thái của các tài nguyên và nhóm tài nguyên. Nó cũng chịu trách nhiệm
thực hiện việc phục hồi khi một tài nguyên bị lỗi và sẽ yêu cầu Resource
Monitor phản hồi tới người tình trạng hoạt động hay không hoạt động của
tài nguyên. Sau khi tài nguyên bị fail được tìm thấy, Failover Manager có
thể thực hiện việc phục hồi bằng cách khởi động lại một tài nguyên và các
tài nguyên hay di chuyển toàn bộ nhóm tài nguyên tới một node khác. Công
việc phục hồi xác định đã được thực hiện bởi resource và resource group
properties và node availability .Trong quá trình failover, một resource
group được coi như là một failover unit, để đảm bảo resource được phục hồi
đúng. Khi một tài nguyênđược phục hồi từ trạng thái fail, Resource
Monitor thông báo tới Failover Manager để tự động thực hiện quá trình
“failback” các resource group dựa trên cấu hình của resource group
failback properties.
Ghi chú:
 Đối với những Cluster có 2 node, dùng thông điệp unicast cho

traffic trong nội bộ Cluster. Không dùng multicast.
 Đối với những cluster có từ 3 node trở lên mà ở dạng mixed
version (một số node chạy Windows Server 2003 Enterprise Edition hay
Datacenter Edition và một số node khác chạy windows 2000) các Cluster
gửi những thông điệp unicast, không dùng multicast.
16
• Heartbeat: Là một UDP packet chuyển đổi giữa các node mỗi 1.2
giây một lần để xác định mỗi node trong Cluster vẫn hoạt động. Nếu một
node thiếu hụt liên tiếp 5 heartbeat, node đó sẽ chuẩn bị một quá trình
regroup event để đảm bảo rằng tất cả các node đi tới một sự nhất quán danh
sách các node còn đang hoạt động. Server Cluster network có thể là private
( chỉ có sự giao tiếp giữa các node với nhau), public ( giao tiếp giữa client
với node), hay mixed (cả sự giao tiếp giữa các node và sự giao tiếp giữa
client với node). Heartbeat được giao tiếp qua tất cả các loại network, tuy
nhiên việc theo dõi heartbeat và cách mà Cluster thể hiện các heartbeat bị lỗi
dựa trên các kiểu network sau:
- Trên private hay mixed network, cả hai đều có sự giao tiếp giữa các
node, heartbeat được theo dõi để xác định node có hoạt động trong
Cluster hay không.
- Trên public network, chỉ có sự giao tiếp giữa client với node, heartbeat
được theo dõi chỉ để xác định network adapter của node có hoạt động hay
không.
• Regroup event: Nếu một node thiếu hụt liên tiếp 5 heartbeat, một quá
trình regroup event được xảy ra. Nếu node vẫn duy trì tính trạng không thể
phản hồi, node đó sẽ được loại bỏ khỏi danh sách các node hoạt động. Nếu
node không phản hổi này đang sở hữu một tài nguyên quorum, các node còn
lại cũng bắt đầu một quá trình đàm phán quorum. Sau đó, quá trình failover
được bắt đầu.
• Quá trình đàm phán quorum: Quá trình đàm phán quorum xảy ra khi
một node đang sở hữu một tài nguyên quorum bị lỗi hay không hoạt động,

và các node còn lại sẽ xác định node nào sẽ giữ quyền sở hữu tài nguyên
quorum. Mục đích của quá trình đàm phán quorum là tại một thời điểm đảm
bảo rằng chỉ một node duy nhấ tđược sở hữu quorum resource. Việc chỉ cho
một node sở hữu tài nguyên quorum là rất quan trọng bởi vì nếu tất cả các
17
giao tiếp giữa 2 hay nhiều node bị lỗi, nó có khả năng chia Cluster thành 2
hay nhiều phần riêng biệt để giữ cho nó vần tiếp tục hoạt động (split brain).
Server Cluster ngăn ngừa nó bằng cách chỉ cho phép duy nhất một Cluster
tách ra này có chứa node đang sở hữu tài nguyên quorum tiếp tục hoạt động
như một Cluster. Bất kỳ node nào không thể giao tiếp với node đang sở hữu
tài nguyên quorum, thì node đó sẽ không còn là node thành viên trong
Cluster.
• Cách cluster giữ cho các nhóm tài nguyên luôn sẵn sàng: Cluster
giữ cho các nhóm tài nguyên luôn sẵn sàng bằng cách theo dõi trạng thái của
các tài nguyên, mang các tài nguyên online, và tiến hành failover.
• Theo dõi trạng thái các tài nguyên: Resource Monitor đưa ra 2 cách
theo dõi trạng thái các tài nguyên trên node mà nó giám sát : Look Alive (tài
nguyên xuất hiện là online) và IsAlive (kiểm tra chi tiết trạng thái online và
hoạt động của tài nguyên là đúng chức năng).
• Cách Failover xảy ra: Quá trình failover xảy ra khi một nhóm hay
một node đang sở hữu tài nguyên bị lỗi. Một tài nguyên bị lỗi có thể là lý do
cho một nhóm lỗi nếu ta cấu hình Affect the group cho tài nguyên đó.
Failover có hai dạng: Resource failure hay Group failure và Node failure
hay mất sự giao tiếp giữa các node.
o Resource failure và Group failure: Khi một tài nguyên bị hỏng quá
trình sau sẽ xảy ra :
 Resource Monitor dò tìm lỗi qua Looks Alive hay Is Alive hoặc qua
một sự kiện được ghi bởi tài nguyên đó. Resource Monitor gọi điểm vào Is
Alive của resource DLL để xác định tài nguyên đó bị hỏng
 Nếu Is Alive bị lỗi, trạng thái tài nguyên chuyển thành lỗi

 Nếu ta cấu hình cho tài nguyên khởi động lại khi bị lỗi, Failover
Manager cố gắn khởi động lại tài nguyên để mang nó online trở lại. Nếu sự
18
cố gắng mang tài nguyên online không đạt được hay vượt qua ngưỡng hay
thời gian cho phép khởi động lại, Resource Monitor dừng tài nguyên này.
 Thông qua Resource Monitor, Failover Manager gọi Terminal entry
point của tài nguyên DLL
 Nếu tài nguyên này được cấu hình là Affect the group, quá trình làm
việc được tiếp tục, ngược lại, nó sẽ kết thúc mà không có hoạt động nào
khác. Khi cấu hình là Affect the group, Failover Manager trên các node trong
cluster làm việc cùng với nhau để tái chỉ định quyền sở hữu cho nhóm đó.
 Trên node mà tài nguyên bị hỏng, Failover Manager kết thúc tài
nguyên đó và các tài nguyên liên quan với nó
 Failover Manager trên node mà tài nguyên bị hỏng thông báo cho
Failover Manager trên node sẽ sở hữu tài nguyên đó và cũng thông báo với
Failover Manager trên tất cả các node khác cho sự thay đổi này
 Nếu bất kỳ tài nguyên nào được cấu hình lưu thông tin cấu hình trên
cục bộ registry, Checkpoint Manager sẽ restore bản sao registry cho tài
nguyên đó từ tài nguyên quorum
 Node mà Failover Manager sẽ chuyển tài nguyên tới là duy nhất, sử
dụng danh sách phụ thuộc để xác định thứ tự đúng
 Node mới sở hữu group sẽ điều khiển các tài nguyên của nhóm đó
thông qua Resource Monitor tương ứng
o Node failure và mất sự giao tiếp giữa các node: Failover xảy ra khi
một node bị hỏng khác với Failover xảy ra khi một tài nguyên bị hỏng.
Trong Clustering, một node được coi là bị hỏng nếu nó mất sự giao tiếp với
các node khác. Nếu một node mất liên tiếp 5 heartbeat, nó được coi là bị
hỏng và một quá trình regroup event được xảy ra. Sau khi một node bị hỏng,
các node còn lại tiến hành đàm phán cho việc sở hữu các nhóm tài nguyên.
Failover Manager trên các node còn sử dụng được xác định quyền sở hữu

các nhóm tài nguyên dựa trên :
19
 Các node mà ta chỉ định có khả năng sở hữu các nhóm tài nguyên đó.
 Thứ tự được chỉ định trong danh sách các node ưu tiên
• Cách Failback xảy ra: Failback là quá trình dịch vụ Cluster chuyển
các nhóm tài nguyên trả về node thích hợp hơn sau khi node này online trở
lại.
Node mà một group được trả về chuẩn bị một quá trình failback. Failover
Manager trên node đó tương tác với Failover Manager trên node đang sở
hữu group và tiến hành đàm phán sau đó chuyển quyền sở hữu nhóm tài
nguyên trở về node thích hợp hơn.
1.4 Phân loại Cluster
Có nhiều cách để phân lọai Cluster như:
 Clustering dựa trên nền tảng của phần mềm hay phần
cứng.
 Clustering chạy như một dịch vụ của Hệ điều hành hay là
một dịch vụ độc lập.
 Kiểu phần cứng được dùng để dữ liệu có tính Clustering
Ngày nay, các hệ thống Cluster trên nền Intel có các phương pháp khác
nhau và sẽ được tìm hiểu trong các phần tiếp theo.
1.4.1 Cluster dựa trên nền tảng phần mềm
Tùy thuộc vào nhu cầu mong muốn Clustering về khả năng sẵn sàng, có
nhiều mức để thiết lập Clustering:
 Mức hệ điều hành như là MSCS, Linux Clustering,
 Mức ứng dụng như Exchange Clustering, SQL Clustering,
Oracle Clustering, Lotus Clustering.
 Cả mức hệ điều hành và mức ứng dụng.
1.4.2 Cluster dựa trên nền tảng phần cứng
Phương pháp dùng phần cứng Clustering thường được áp dụng đối với hệ
thống lưu trữ, có 2 loại Cluster được xem xét đó là Cluster trên đĩa lưu trữ

20
dùng chung (share disk), Cluster không sử dụng đĩa dùng chung (sử dụng
local disk).
• Share disk
Sử dụng lưu trữ dùng chung được thiết kế bởi một tủ đĩa dùng chung
giữa các Node trong Cluster để tất cả các Node này đều có thể truy nhập vào
tủ đĩa này. Những phần mềm dịch vụ Clustering quản lý các đĩa này không
cho các hệ thống cùng tạo ra sự thay đổi trên tủ đĩa vào cùng một vùng dữ
liệu đồng thời.
• Share local disk
Mỗi Node trong Cluster có một vùng đĩa riêng (local disk), khi một Node
trong Cluster cần thiết truy nhập vào dữ liệu được quản lý bởi Node khác
trong Cluster, nó sẽ phải được sự cho phép của Node sở hữu tài nguyên này.
Nếu một Node fail, dữ liệu nó quản lý được chuyển sang cho Node khác
quản lý trong Cluster.
1.4.3 Máy chủ chủ động (active) và thụ động ( passive)
Các Node trong Cluster có thể hoạt động theo nhiều cách, tùy thuộc vào
việc chúng được cấu hình như thế nào. Trong một hệ thống Cluster lý tưởng
gồm 2 Node, cả 2 máy chủ cùng chủ động đồng thời. Điều đó có nghĩa là
các ứng dụng có thể đồng thời được chạy trên cả 2 Node. Trong trường hợp
có 1 Node fail, các ứng dụng đang chạy trên Node fail này sẽ được chuyển
sang Node còn chủ động. Khi đó, hiệu năng của hệ thống sẽ bị giảm xuống,
bởi vì tất cả các tác vụ đều được chạy trên Node còn chủ động này.
Một giải pháp khác là luôn có 1 Node trong trạng thái thụ động khi hệ
thống Cluster hoạt động bình thường, và Node này sẽ chủ động khi 1 Node
đang ở trạng thái chủ động lỗi. Tuy nhiên, giải pháp này không phải là giải
pháp có hiệu quả tính về mặt chi phí, bởi vì khi đó phải cần 2 máy chủ
nhưng chỉ có 1 máy chủ làm việc trong một thời điểm. Mặc dù, với mô hình
này thì hiệu năng hoạt động của hệ thống trước và sau khi có 1 Node fail là
21

như nhau nhưng hiệu quả tính theo price/performance trong khi hoạt động
bình thường là không kinh tế.
Do đó, dựa vào đây, chúng ta có một cách khác nữa để phân loại Cluster
dựa trên 2 Node:
• Chủ động/Chủ động (Active/Active)
Đây là mô hình Cluster phổ biển, nó cung cấp khả năng sẵn sàng cao,
hiệu năng lớn. Mô hình này cũng tận dụng tối đa tài nguyên phần cứng của
hệ thống Cluster.
Mỗi Node đều có nhiệm vụ cung cấp các tài nguyên cho tất cả các Client
trong mạng. Khả năng hoạt động của mỗi Node cũng được điều khiển để tối
ưu hóa hiệu năng và có thể linh hoạt chia tải giữa các Node, và chuyển tải
khi 1 Node lỗi.
Tất cả các dịch vụ của máy Client vẫn luôn trong suốt khi failover giữa
các Node nhưng hiệu năng có giảm xuống.
• Chủ động/Thụ động (Active/Passive)
Mặc dù luôn cung cấp tính sẵn sang cao cho hệ thống và tối thiểu ảnh
hưởng đến hiệu năng của tài nguyên, nhưng mô hình Chủ động/Thụ động
cũng yêu cầu các Node có phần cứng như trong mô hình Chủ động/Chủ
động , trong khi đó hiệu năng chỉ đạt được bằng 1/2 trong trạng thái hoạt
động bình thường so với mô hình Chủ động/Chủ động. Node chủ động
(Primary) xử lý tất cả các yêu cầu từ phía Client trong khi Node thụ động
(Secondary) thì xử lý rất ít hoặc hầu như không xử lý (idle). Khi Node
Primary lỗi, thì Node Secondary sẽ khởi tạo tất cả các tài nguyên và tiếp tục
phục vụ các yêu cầu của Client mà không gây ảnh hưởng gì về phía Client
về hiệu năng.
• Hybrid
22
Mô hình Hybrid là sự kết hợp của cả 2 mô hình trên, bằng cách cho phép
chỉ failover các ứng dụng nhậy cảm. Hệ thống vẫn đảm bảo tính sẵn sàng
cao như trong mô hình Chủ động/Chủ động , trong khi các ứng dụng ít nhậy

cảm vẫn có thể chỉ chạy trên máy chủ riêng lẻ, không cần Cluster. Khi có
failover, các ứng dụng ít nhậy cảm đang hoạt động trên máy chủ fail sẽ
chuyển sang trạng thái không sẵn sàng (downtime) mà không làm giảm hiệu
năng của các ứng dụng đang chạy.
23
CHƯƠNG II. CLUSTERING MỨC HỆ ĐIỀU HÀNH
Trong phần này, chúng ta sẽ xem xét công nghệ Clustering ở mức hệ điều
hành. Phần mềm Clustering được tích hợp sẵn vào trong hệ điều hành (chủ
yếu xem xét Clustering trên nền tảng Microsoft và trên UNIX như Linux
Clustering)
2.1 Microsofte Cluster Server (MSCS)
MSCS là một phần của các dòng hệ điều hành Enterprise của Microsoft:
 Windows NT 4.0 Enterprise Edition
 Windows 2000 Advanced Server
 Windows 2000 Datacenter Server
 Windows 2003 Enterprise Server
Phiên bản đầu tiên có hỗ trợ Clustering của Microsoft là Windows NT
4.0 Enterprise Edition. Với phiên bản này, 2 máy chủ được liên kết với nhau
cho phép khả năng chịu đựng lỗi fault-tolerance qua failover. Thậm chí,
trước khi phiên bản MSCS này, các nhà sản xuất phần cứng như IBM, HP,
Fujitsu, Dell, đã cung cấp khả năng dự phòng (redundancy) đối với các
linh kiện của máy chủ bao gồm như là nguồn, đĩa cứng và bộ nhớ. Tuy nhiên
đây chỉ là mức bảo vệ cho từng linh kiện phần cứng, tức là ở mức phần
cứng, chứ không phải ở mức ứng dụng. Phiên bản tiếp theo của MSCS là
Windows 2000 Advanced Server, cung cấp thêm các tính năng mới tích hợp
trong Clustering Service như DHCP, WINS, SMTP, NNTP. Phiên bản hiện
nay hỗ trợ MSCS là Windows 2003 Enterprise Server, có đầy đủ các tính
năng như phiên bản trước và có thềm các tính năng về bảo mật.
Cung cấp khả năng dự phòng tức là bất kỳ một máy chủ nào bị lỗi nhưng
vẫn không tác động đến truy nhập của máy Client vào tài nguyên. MSCS mở

rộng tính năng bằng cách cho phép phần mềm lỗi, cả phần mềm hệ thống và
phần mềm ứng dụng. Nếu hệ điều hành của 1 Node lỗi, tất cả các ứng dụng
24
và dịch vụ có thể được khởi tạo lại trên Node còn lại. MSCS thực hiện việc
này bằng cách liên tục cập nhật trạng thái của dịch vụ và ứng dụng, đảm bảo
bất cứ sự cố nào làm ngừng ứng dụng hoặc treo ứng dụng đều được khởi tạo
lại trên chính máy chủ đó hoặc trên máy chủ khác. Khi 1 Node lỗi, quá trình
khởi tạo lại các ứng dụng đang chạy trên Node khác được gọi là quá trình
failover. Failover có thể hoặc xảy ra tự động (khi các ứng dụng hoặc máy
chủ có sự cố) hoặc xảy ra một cách thủ công (manually) . Bằng việc failover
thủ công, người quản trị có thể chuyển tất cả các ứng dụng và tài nguyên
trên 1 Node sang Node còn lại (ví dụ như mục đích bảo dưỡng). Khi máy
chủ đó khởi động lại, trở lại trạng thái hoạt động bình thường thì các ứng
dụng cũng có thể được chuyển trở lại máy chủ này tự động hoặc thủ công.
Việc trả lại tài nguyên cho máy chủ này được gọi là quá trình failback.
Cách kết nối của hệ thống Cluster điển hình như sau:
Hình 2.1: Cách kết nối của hệ thống Cluster điển hình
 Mỗi Node có tối thiểu là 2 kết nối mạng, 1 cho Private
(hearbeat, chỉ trao đổi dữ liệu giữa 2 Node với nhau), 1 cho Public (trao đổi
dữ liệu với mạng bên ngoài và cho chính các Node với nhau).
 Tủ đĩa lưu trữ dùng chung cho hệ thống Cluster (Share
Disk), đây là tử đĩa ngoài, cho phép tất cả các Node có thể truy nhập tới,
25