CHƯƠNG II CLUSTERING MỨC HỆ ĐIỀU HÀNH
2.1.5 Tài nguyên Quorum
Một vùng đĩa vật lý mà cả 2 Node có thể truy nhập vào được sử dụng để lưu thông tin trạng thái Cluster được gọi là ổ đĩa Quorum. Vùng đĩa này dùng để lưu trữ các dữ liệu Log thiết yếu để duy trì trạng thái của Cluster và duy trì hoạt động đồng bộ thông tin trạng thái giữa 2 Node, đặc biệt khi 1 Node lỗi. Tại 1 thời điểm chỉ có 1 Node quản lý các tài nguyên của Cluster. Ví dụ, nết 1 Node mất kết nối với Node còn lại thì Node mất kết nối này sẽ không thể trao đổi trạng thái với ổ đĩa Quorum được nên nó sẽ bị loại ra khỏi hệ thống Cluster. Khi khởi tạo MSCS sẽ yêu cầu phải chỉ ra tài nguyên ổ đĩa Quorum, và ổ đĩa này phải nằm trên Share Disk. Mặc dù ổ đĩa Quorum có thể lưu trữ các dữ liệu ứng dụng khác nhưng điều này là không nên, và chỉ
để ổ đĩa này lưu trữ, cập nhật trạng thái thông tin của các Node trong Cluster.
2.1.6 TCP/IP
MSCS sử dụng giao thức TCP/IP để kết nối các tài nguyên và ứng dụng mạng. Địa chỉ IP cho Cluster không thể là địa chỉ được cấp từ máy chủ DHCP. TCP/IP bao gồm các tài nguyên về IP Address, địa chỉ IP được chính các Node sử dụng kết nối mạng vật lý. Mỗi Node sẽ sử dụng tối thiểu là 2 kết nối mạng, do đó cần tối thiểu 2 Network Interface Card. Trong đó, 1 kết nối mạng dùng để trao đổi trạng thái giữa các Node với nhau (trong trường hợp kết nối mạng kia bị lỗi). Mặc dù các địa chỉ IP vật lý của các NIC này có thể lấy từ máy chủ DHCP nhưng theo khuyến nghị thì không nên dùng địa chỉ IP động này mà nên dùng địa chỉ IP tĩnh. Vì trong trường hợp máy chủ DHCP có sự cố, hoặc thời gian dùng địa chỉ IP hết thì các Node sẽ không nhận được địa chỉ IP này nữa, do đó khả năng mà hệ thống Cluster gặp phải lỗi là rất cao. Địa chỉ IP dùng để trao đổi trạng thái các Node Cluster là địa chỉ private, các dải địa chỉ private được dùng là:
2.1.7 Domain
Phần này sẽ chỉ ra liên hệ của hệ thống Cluster với Domain - Cả 2 máy chủ phải đều là member của cùng 1 Domain - Mỗi máy chủ chỉ có thể là member của 1 hệ thống Cluster
Mặc dù, cả 2 Node đều có thể là máy chủ Domain Controller hoặc mãy chủ Stand-alone nhưng Microsoft khuyến nghị nên để cả 2 Node này ở dạng Stand-alone để giảm tải cho 2 Node. Chỉ trong trường hợp quy mô của mạng nhỏ, số lượng máy chủ hạn chế thì có thể dùng luôn máy chủ Domain
Controller làm máy chủ Cluster. Nếu máy chủ này chuyển trạng thái là member server sang là domain controller hoặc ngược lại khi khởi tạo dịch vụ Cluster có thể làm cho hệ thống Cluster này lỗi như sau:
Event ID: 7013
Source: Service Control Manager
Description: Logon attempt with current password failed with the following error: Logon failure: the user has not been granted the requested logon type at this computer.
Event ID: 7000
Source: Service Control Manager
Description: The Cluster service failed to start due to the following ErrorID: The service did not start due to a logon failure.
2.1.8 Failover
Failover là quá trình chuyển quyền xử lý, điều khiển tài nguyên từ Node lỗi sang Node còn hoạt động. Việc phát hiện ra lỗi này là nhiệm vụ của
Resource Monitor, khi xảy ra lỗi của các tài nguyên thì Resource Monitor sẽ thông báo cho Cluster Service và sau đó sẽ chuyển đổi trạng thái của Cluster bằng quá trình failover đối với tài nguyên đó. Mặc dù có thể lỗi chỉ xảy ra bởi các tài nguyên đơn lẻ nhưng quá trình failover sẽ thực hiện failover toàn bộ tài nguyên trong Group đó. Mặc định, MSCS cấu hình tất cả các tài nguyên trong Cluster cùng chia sẻ 1 Resource Monitor. Điều này có nghĩa là, bất cứ thời điểm nào, bất cứ tài nguyên nào fail thì Resource Monitor này sẽ kiểm tra lại tất cả các tài nguyên để đưa ra quyết định chính xác. Tất nhiên, trong trường hợp này, các tài nguyên sẽ mất nhiều thời gian hơn để chuyển sang trạng thái online bởi vì nó phải làm việc chỉ dựa trên cơ sở 1 Resource Monitor duy nhất phục vụ. Để tránh khỏi hạn chế này, Microsoft khuyến nghị tất cả các tài nguyên IP Address và tài nguyên Physical Disk
này. Sử dụng như vậy để tối đa khả năng sẵn sàng của các tài nguyên MSCS.
Failover xảy ra trong 3 trường hợp sau: manually (thường là do thao tác của người quản trị), automatically (tự động) hoặc vào một thời điểm định trước được thực hiện Cluster Manager.
Việc tự động failover xảy ra tuần tự theo 3 bước:
Phát hiện lỗi
Chuyển quyền điều khiển tài nguyên
Khởi động lại các ứng dụng dịch vụ (thường mất nhiều thời gian nhất trong quá trình failover)
• Thiết lập failover tài nguyên
Mức ngưỡng để xảy ra failover là số lần trong một khoảng thời gian nhất định mà MSCS cho phép tài nguyên được khởi tạo lại trên cùng 1 Node. Nếu số lần này vượt quá mức ngưỡng thì tài nguyên này và tất cả các tài nguyên khác trong Group sẽ được failover cho Node khác trong Cluster. Khoảng thời gian failover là thời gian (được tính băng giây) trong suốt quá trình mà 1 Node khởi tạo dịch vụ trước khi nhóm dịch vụ đó được failover. Sau khi vượt quá mức ngưỡng này, MSCS sẽ failover Group mà chứa tài nguyên bị lỗi đó và tất cả các tài nguyên còn lại trong Group sang Node tiếp theo và lại cố gắng để chuyển các tài nguyên này sang trạng thái online.
• Thiết lập failover nhóm
Mức ngưỡng là số lần tối đa mà Group cho phép failover trong một khoảng thời gian nhất định. Nếu Group vượt quá số lần failover này trong khoảng thời gian đó, MSCS sẽ chuyển trạng thái của tài nguyên này ở trạng thái offline và chuyển sang trạng thái partially online đối với Group đó, tùy thuộc vào trạng thái của các tài nguyên còn lại trong nhóm. Khoảng thời gian failover là khoảng thời gian (tính bằng giờ) được chỉ ra trong mức
Domino, các tài nguyên khác trong nhóm bao gồm tài nguyên File Share và tài nguyên Physical Disk.
H ình 2.3: Thiết lập failover nhóm
Với hình vẽ minh họa trên, người quản trị thiết lập hệ thống Cluster với mức failover threshold là 3, khoảng thời gian failover là 60s đối với tài nguyên Domino và failover threshold là 5 và khoảng thời gian failover là 1h đối với Lotus Domino Group. Chúng ta sẽ lần lượt xem xét các tình huống xảy ra, khi Domino từ từ lỗi, tài nguyên Generic Application sẽ khởi động lại trên Node này 3 lần. Nếu đến lần thứ 4 vẫn không khởi tạo lại được trong vòng 1 phút thì chính tài nguyên này và nhóm tài nguyên chứa chúng, Lotus Domino Group sẽ failover sang Node B, lúc này được tính là nhóm Lotus Domino Group failover 1 lần. Khi Domino lỗi 4 lần (vượt quá mức ngưỡng) trên Node B, nó sẽ lại được failover trở lại Node A, lúc này được tính là failover 2 lần đối với Lotus Domino Group. Nếu như tài nguyên Domino vẫn không khởi tạo được thì quá trình sẽ tiếp tục diễn ra như trên. Sau lần thứ 5 failover của Lotus Domino Group trong vòng 1 giờ (Node A->B->A- >B->A....), MSCS không thể khởi động lại được Domino thì Domino sẽ chuyển sang trạng thái lỗi, và Lotus Domino Group sẽ chuyển sang trạng
thái partially online. Tất cả các tài nguyên khác sẽ bị chuyển sang trạng thái lỗi nếu các tài nguyên này là các phụ thuộc của tài nguyên Domino.
2.1.9 Failback
Failback là trường hợp đặc biệt của failover và là quá trình chuyển trả lại một vài hoặc tất cả Group sang Node trước failover (Orginal Node), được gọi là preferred owner. Preferred owner của 1 Group là Node trong Cluster mà được định nghĩa trong cấu hình MSCS.
Nếu preferred owner lỗi, tất cả các tài nguyên của Cluster sẽ được chuyển sang Node còn lại. Khi Node lỗi này hoạt động trở lại, các nhóm mà được chỉ ra preferred owner sẽ tự động được chuyển trở lại Node nay. Các nhóm mà không được định nghĩa preferred owner thì sẽ không có quá trình chuyển ngược trở lại này (failback). Với failback, có thể cấu hình cân bằng tải Load-Balancing đơn giản. Khi cả 2 máy chủ cùng chạy, được cấu hình failback, các tài nguyên và ứng dụng sẽ chuyển tới preferred owner, do đó có thể cấu hình cân bằng tải trên Cluster nhưng chỉ có tính chất tương đối. Khi 1 Group được tạo, thì failback mặc định chưa được khởi tạo, ở trạng thái disable. Nói cách khác, nếu failover xảy ra, các tài nguyên sẽ được chuyển sang Node kia và sẽ duy trì ở Node đó mà không chuyển trở lại ngay cả khi preferred node ở trạng thái online ngay cả khi các Node này trở lại hoạt động bình thường. Nếu muốn quá trình failback thực hiện một cách tự động, MSCS phải được cấu hình Group để failback trở lại ngay khi
preferred node trở lại trạng thái bình thường hoặc có thể thiết lập giới hạn failback với khoảng thời gian nhất định. Với nhiều ứng dụng lớn thì không nên cấu hình failback, bởi việc khởi tạo lại ứng dụng trên preferred node có
thể mất nhiều thời gian, làm ngắt các kết nối đang được phục vụ
2.1.10 LooksAlive và IsAlive
Để xác định xem liệu tài nguyên có sẵn sàng hay không, Resource Monitor sẽ lấy các thông tin này từ các tài nguyên DLL. Có 2 mức để lấy
được các thông tin này mà Resource Monitor hỗ trợ và có thể điều chỉnh được đối với mỗi tài nguyên. 2 mức này được gọi là LooksAlive và IsAlive, chúng được định nghĩa như sau:
• LooksAlive
Resource Monitor thực hiện kiểm tra lướt qua để quyết định liệu tài nguyên này có đang trong tình trạng sẵn sàng hay không. Nếu tài nguyên này không có tín hiệu gì đáp lại thì Resource Monitor sẽ thông báo cho Cluster Service. Khi một tài nguyên mới được tạo ra, khoảng thời gian giữa các lần kiểm tra LooksAlive (Bằng giây) phải đựơc định nghĩa, giá trị mặc định là 5000ms (5s).
• IsAlive
Resource Monitor thực hiện kiểm tra kỹ lưỡng tài nguyên để kiểm tra xem chắc chắn tài nguyên này có đang trong tình trạng hoạt động hay không. Nếu kết quả kiểm tra cho biết lỗi, Cluster Service được thông báo ngay lập tức và tuỳ thuộc vào cấu hình được định nghĩa của tài nguyên đó. Resource Manager sẽ hoặc là kết thúc tài nguyên đó hoặc là cố gắng làm sao đưa tài nguyên này về trạng thái Online trên cùng Node đó hoặc Node khác, giá trị mặc định là 60,000ms (1phút)
Hình 2.4: Giao diện điều khiển IsAlive
Xem xét hình vẽ trên với Domino, với giá trị tài nguyên Geneic Application được tạo ra với các giá trị mặc định, Resource Monitor gọi chức năng LooksAlive trong tài nguyên DLL 5s một lần để kiểm tra trạng thái Domino. Mỗi lần 60s, chức năng IsAlive được xem là sự kiểm tra rất kỹ lưỡng để biết được tình trạng Domino hoạt động.