Kế hoạch khôi phục thảm họa Active Directory

Ngăn chặn lỗi Active Directory chính là thành phần chủ yếu trong bất
cứ kế hoạch khôi phục thảm họa nào. Tuy có nhiều cách có thể giảm
được thảm họa cho Active Directory nhưng cách tốt nhất để tối thiểu
thời gian chết của máy móc chính là cần phải có một kế hoạch phù hợp.
Bạn cần khôi phục một domain controller? Muốn ngăn chặn việc xóa một số
lượng lớn các đối tượng quan trọng do vô tình? Trong bài này chúng tôi sẽ
giới thiệu cho các bạn cách lập kế hoạch cho những điều tồi tệ nhất và
những gì bạn cần thực hiện để khôi phục Active Directory của mình và giúp
nó chạy trở lại.
Điều quan trọng là phải có một kế hoạch khôi phục thảm họa cho các thảm
họa lớn, tuy nhiên có rất nhiều hành động bạn có thể thực hiện để ngăn chặn
các thảm họa này – hoặc ít nhất cũng là tối thiểu cơ hội gây ra thảm họa
Active Directory, chẳng bạn như việc xóa nhầm một số lượng lớn các đối
tượng do vô tình.
Một trong những hành động đó là tạo một lag site bản sao. Rất đơn giản,
một lag site là một Active Directory site được dự trữ trong khoảng vài ngày
trong một tuần ở sau phần còn lại của miền. Rõ ràng, có một số vấn đề phát
sinh (gotchas) khi thực hiện điều này, tuy nhiên về cơ bản một lag site sẽ dự
trữ được một backup “sống” cho Active Directory.
Bạn tạo một lag site bằng cách đặt một domain controller từ một hub site
vào một site riêng (chúng tôi gọi nó là site khôi phục thảm họa) với một liên
kết site đến hub site. Cấu hình liên kết hub site khôi phục thảm họa để có tần
xuất tái tạo là 96 giờ. Điều đó có nghĩa rằng một copy sẽ được thực hiện sau
96 giờ phía sau phần còn lại của forest.
Lúc này, cần nhớ rằng, nếu một quản trị viên nào đó do vô tình xóa một OU
có 10.000 người dùng thì những gì bạn chỉ có thể làm lúc này là thực hiện
một khôi phục thẩm định (và hy vọng thiết bị backup của mình hợp lệ). Điều
đó có nghĩa rằng bạn phải thực hiện quá trình khôi phục thẩm định sau:
1. Cách ly một domain controller có copy thẩm định của Active

Mnemonics ngoài trừ bản ghi CNAME (cần thiết cho bản sao). Tab Explain
có đôi chút lộn xộn, tuy nhiên nó là một danh sách được phân định theo
khoảng trống như thể hiện trong hình 1 bên dưới. Bản thân Mnemonics được
liệt kê trong cột bên trái trên tab Explain.

Hình 1: Danh sách phân định theo khoảng trống trong một lag site
Cấu hình tối thiểu để thực thi một Active Directory lag site là phải có một
site có ít nhất một domain controller từ mỗi miền trong site. Cấu hình được
ưa thích là phải có hai domain controller từ mỗi miền trong site. Thiết lập
tần suất tạo bản sao là 168 giờ mỗi tuần và dao động lịch trình để chúng tạo
bản sao cứ 3,5 ngày một lần. Như vậy bạn sẽ có hai copy cũ để có thể lựa
chọn, vấn đề sẽ được giảm một cách rõ rệt.
Bạn cũng có thể sử dụng Virtual Server như các domain controller của lag
site để tiết kiệm chi phí phần cứng.
Nếu có một cấu trúc phức tạp (cha/con), thì bạn có rất nhiều vấn đề không
thấy rõ. Khi thử một khôi phục trên một miền, bạn sẽ thất bại trong việc khôi
phục các thành viên nhóm trong toàn miền. Hewlett-Packard Co. là công ty
lần đầu tiên phát hiện ra vấn đề này và công ty này đã phát triển một công cụ
mang tên Active Directory Link Replication Manager (ADLRM) để lưu các
liên kết này trong một cơ sở dữ liệu SQL và khôi phục chúng khá tiện lợi.
Công cụ này cũng có thể lưu và khôi phục các thuộc tính riêng lẻ. Cho ví dụ,
nếu bạn có một ứng dụng quản trị nhân sự (HR) đã thay đổi thuộc tính của
một người dùng nào đó, trong khi đó bạn cần khôi phục lại thuộc tính này về
giá trị được thay đổi trước đó, ADLRM sẽ cho phép bạn thực hiện điều đó
mà không yêu cầu một quá trình khôi phục thẩm định toàn bộ.

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

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à

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:

Cần có liên kết site có cost thấp giữa hub site chính và site khôi phục
thảm họa để bảo đảm sự cập kịp thời site khôi phục thảm họa với site
chính. Điều này cũng ngụ ý rằng, mạng vật lý cần phải có liên kết tin
cậy và tốc độ cao giữa hai site này.

Không tạo các liên kết site giữa site khôi phục thảm họa và các site từ