Kế hoạch khôi phục thảm họa Active Directory – Phần 2: Tạo dự phòng trong bản sao Active Directory

Kế hoạch khôi phục thảm họa Active Directory - Phần 1: Tạo một Active Directory replication lag site
Quản trị mạng – Một trong những khía cạnh quan trọng đối với công việc của các quản trị viên là khả năng khôi phục hệ thống từ một lỗi không mong muốn nào đó – có thể do chủ tâm hoặc do vô tình. Khôi phục thảm họa Active Directory có nhiều khía cạnh cần phải bảo đảm và chắc chắn nó phải phức tạp hơn việc giữ một backup trong tay bạn.

Cách tốt nhất để bảo đảm rằng bạn có thể khôi phục thành công từ bất kỳ một tình huống lỗi nào – phần cứng hay phần mềm – là phải đi tiên phong (proactive). Thực hiện những bước đi để bảo đảm rằng doang nghiệp sẽ chỉ phải chịu một khoảng thời gian ngừng hoạt động máy móc ở mức tối thiểu. Trong bài này, chúng tôi sẽ giới thiệu cho các bạn cách bảo đảm rằng một bản sao Active Directory sẽ vẫn được duy trì mặc dù có xảy ra lỗi các domain controller nghiêm trọng.

Thay đổi mật khẩu, thay đổi bảo mật, chính sách bảo mật và một loạt các thiết lập cấu hình quan trọng đều được thực thi thông qua Group Policy, bản sao FRS Replication và bản sao Active Directory và chịu trách nhiệm cho việc bảo đảm tất cả các bộ điều khiển miền đều có các thiết lập chính sách giống nhau. Vì vậy, vấn đề quan trọng nhất của doanh nghiệp là bảo đảm rằng bảo sao Active Directory thành công và được duy trì một cách không ngắt quãng. Các công ty vẫn tạo một site khôi phục thảm họa là cách thường được thực hiện. Nhiều mạng công ty được cấu hình theo một vài topo mạng giống như những gì thể hiện trong hình 1 bên dưới. Lưu ý rằng trong một số cấu hình, có nhiều hub tạo thành một lõi cho bản sao Active Directory. Có nhiều hub site lõi chứa cấu hình khôi phục thảm họa cố hữu. Do đó khi một site lõi gặp vấn đề sẽ có các site khác chia sẻ tải.

Hình 1: Topo mạng đa hub và đơn hub

Với các cấu hình hub đơn, khó khăn cho việc khôi phục thảm họa là tạo một Active Directory site trong một location được kết nối tốt trong mạng, ghép cặp với ít nhất một domain controller từ mỗi miền trong mỗi forest trong doanh nghiệp. Điều này gồm có ít nhất một máy chủ global catalog (GC), các máy chủ Exchange và cá máy chủ ứng dụng cũng như file/print khác, phụ thuộc vào cơ sở hạ tầng được yêu cầu để hỗ trợ cộng đồng người dùng.

Giả dụ rằng chúng ta đã chọn một site như vậy và có cơ sở hạ tầng máy chủ cần thiết, một trong những thứ mà chúng ta cần phải định rõ là những gì xảy ra trong việc tạo bản sao Active Directory khi hub site chính gặp sự cố. Nhớ rằng chúng ta sẽ không phải đợi cho đến khi gặp một tấn công khủng bố để thấy hiện tượng xảy ra – một lỗi mạng đơn giản hoặc hiện tượng mất điện cũng có thể dẫn đến lỗi này.

Xem xét trường hợp nơi mạng có topo hub-and-spoke (trục bánh xe và nan hoa) có một hub đơn. Site khôi phục thảm họa được thiết kế tốt sẽ gánh tải trọng nếu hub site chính bị lỗi. Trong việc tạo dự phòng bản sao Active Directory phòng khi lỗi ở tất cả các domain controller tại hub site bị lỗi, mô hình được đưa ra là tạo các liên kết cho cả hub site chính và site khôi phục thảm họa (DR site) như thể hiện trong hình 2. Ở đây chúng ta thấy rằng các liên kết site đang kết nối các site từ xa với hub site chính có cost bằng 100, các liên kết kết nối các site từ xa đến site khôi phục thảm họa có cost bằng 200. Các liên kết dự trữ sẽ không được sử dụng khi các domain controller trong site chính hoạt động, điều này là vì đường dẫn có cost bé nhất sẽ ưu tiên các liên kết site chính hơn các các liên kết site từ xa. Mặc dù vậy, trong quá trình test, các domain controller của site chính bị vô hiệu hóa, chúng tôi vẫn phát hiện thấy rằng KCC đã ước tính một topo khác so với kiến trúc dự định, tạo ra các kết nối qua lại giữa các site từ xa thay cho trực tiếp đến site khôi phục thảm họa. Các cố gắng để sửa hầu như đều trở nên vô nghĩa. Khi nghiên cứu nhằm chỉ ra chính xác tại sao topo này lại được tính toán theo cách đó thì một đánh giá về các rule bản sao Active Directory đơn giản đã cho thấy rằng, vấn đề thực sự nằm ở thiết kế.

Hình 2: Cấu hình hub site đơn với site khôi phục thảm họa

Bản sao Active Directory có tính năng dự trữ kèm theo (built-in) mang tên Site Link Bridge. Site Link Bridge cho phép KCC có thể xây dựng các liên kết ngoại động (transitive) trong sự kiện lỗi của một domain controller trong site đã cho nào đó, cho phép bản sao định tuyến xung quanh các domain controller bị lỗi mà không cần bất cứ sự can thiệp nào của con người. Điều này tỏ ra đặc biệt quan trọng trong trường hợp domain controller lỗi là domain controller duy nhất trong site (hay tất cả các domain controller trong site lỗi như kịch bản trong ví dụ của chúng ta). Xem xét trường hợp trong hình 3. Ở đây có 3 site - ATL, CHI, và NYC. Giả định rằng mạng vật lý kết nối tất cả ba site, liên kết site kết nối ATL và CHI, liên kết site kết nối CHI và NYC. Tuy nhiên không có liên kết site kết nối ATL và NYC. Chỉ cần domain controller nằm trong CHI còn sống thì bản sao là hoàn toàn không có gì phải lo ngại. Tuy nhiên điều gì sẽ xảy ra nếu domain controller của CHI bị lỗi? Có vẻ rằng bản sao giữa ATL và NYC sẽ lỗi – chắc chắn là như vậy – mà không có Site Link Bridge. Nếu Site Link Bridge được kích hoạt, khi đó ATL có thể tạo bản sao cho CHI và CHI có thể tạo bản sao cho NYC nên ATL có thể tạo bản sao với NYC. Sau đó một liên kết từ ATL đến NYC với một cost bằng cost được kết hợp giữa các liên kết CHI-NYC và ATL-CHI sẽ được tạo (xem trong hình 4).

Hình 4: Trong trường hợp CHI site bị lỗi, Site Link Bridge sẽ được kích hoạt, khi đó KCC sẽ tạo một liên kết transitive giữa ATL site và LA site để cho phép thực hiện sao chép.

Cần lưu ý rằng KCC không thể thấy mạng vật lý và dựa vào quản trị viên để cấu hình các liên kết site sẽ kết nối các domain controller trong mạng vật lý. Trong trường hợp site CHI lỗi, KCC biết rằng có kết nối từ CHI-NYC và ATL-CHI, mạng vật lý kết nối ATL và NYC – tuy nhiên quản trị viên lại không tạo một liên kết site rõ ràng từ ATL-NYC. Do đó KCC sẽ giám sát và chăm sóc bản sao này một cách liên tục giữa ATL và NYC, cho tới khi CHI hoạt động trở lại, trong trường hợp đó KCC bỏ rơi các kết nối ATL-NYC và thiết lập các kết nối gốc thông qua CHI. Chúng ta có thể quyết định vô hiệu hóa Site Link Bridge (mặc định nó vẫn được kích hoạt) và tạo liên kết ATL-NYC một cách đơn giản, tuy nhiên trong môi trường lớn, điều này có thể khó cho việc quản lý.

Cần lưu ý rằng, Windows 2000 có một số hạn chế nhất định, ví dụ như trong một doanh nghiệp không được có quá 200 site có các domain controller được kích hoạt, không có quá 120 site bản sao cho một hub site. Hạn chế này dẫn đến tình trạng các quản trị viên thường phải vô hiệu hóa tính năng Sitel Link Bridge để giảm tải trên KCC và loại trừ một số vấn đề khác. Tuy nhiên Windows 2003 sử dụng một thuật toán hoàn toàn khác cho việc mở rộng cây, cho phép KCC có thể khắc phục các hạn chế và cho phép chúng ta có thể sử dụng Site Link Bridge.

Vậy, tất cả những thứ mà Site Link Bridge phải thực hiện cho việc loại trừ các liên kết sao chép được tạo từ site khôi phục thảm họa cho các site từ xa trong trường hợp của ví dụ là gì? Nếu chúng ta sử dụng ví dụ trước với các site ATL, NYC và CHI thì chúng ta có thể thấy cách nó làm việc như thế nào. Trong ví dụ đó, hãy giả sử rằng CHI là một hub site và ATL là site khôi phục thảm họa. Tuy nhiên thay vì chỉ có NYC là site từ xa, chúng ta có nhiều site từ xa khác, và rõ ràng SLB được kích hoạt. Chúng ta đã thấy trong ví dụ, cách site từ xa NYC được tạo bản sao cho ATL khi các domain controller của CHI site bị lỗi như thế nào. Kich bản này có thể được áp dụng cho tất cả các site từ xa khác. Chính vì vậy nếu các domain controller trong CHI gặp lỗi, KCC sẽ chọn CHI không có domain controller để tạo bản sao và sẽ tạo các liên kết đến ATL, cho phép các đối tượng kết nối được tạo giữa các site từ xa và ATL, hoàn tất quá trình chuyển đổi dự phòng.

Một số điểm quan trọng khác:

Lưu ý cuối cùng là thiết kế một topo tạo bản sao đơn giản nếu có thể (topo hub-and-spoke cung cấp một đường dẫn đơn giản đến các site từ xa), sau đó cho phép Site Link Bridge cung cấp dự phòng trong trường hợp hub site chính bị lỗi.