Tài liệu Kế hoạch khôi phục thảm họa Active Directory docx

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

Directory ra khỏi mạng.
2. Lấy lưu trữ backup trạng thái hệ thống thích hợp mà bạn đã thực hiện
trước khi xóa.
3. Bảo đảm rằng lưu trữ này là hợp lệ và nó không bị “cũ” so với giới
hạn (mặc định là 60 ngày).
4. Khởi động restore domain controller trong chế độ Directory Service
Restore Mode (DSRM).
5. Thực hiện khôi phục trạng thái hệ thống cho domain controller này.
Lưu ý rằng bạn cần phải thực hiện hai lần để khôi phục nhóm và
người dùng đúng cách. Điều này không tầm thường chút nào.
6. Sát nhập domain controller vào mạng.
7. Bản sao sẽ thực thi các đối tượng Active Directory từ domain
controller được khôi phục vào các domain controller khác trong mạng.
Mặc dù vậy với lag site, bạn có một domain controller có chứa bản copy
Active Directory trước khi hành động xóa vô tình xảy ra (giả định rằng bạn
đã phát hiện thấy điều đó trong khoảng thời gian 4 ngày xuất hiện). Giả định
rằng bạn đã phát hiện rằng một quản trị viên đã vô tình xóa mất 10.000 tài
khoản ngày hôm qua. Khi đó bạn có thể vào domain controller trong lag site,
nơi có một copy Active Directory trước khi xóa và thực hiện một hành động
khôi phục thẩm định bằng copy domain controller của Active Directory.
Copy này phụ thuộc vào thời điểm lag site sao chép và thời điểm hành động
xóa xảy ra. Nếu quá trình sao chép xảy ra vào hôm thứ Hai và thứ Sáu còn
hành động xóa xảy ra vào tối thứ Ba thì bạn có chỉ có một cơ hội rất nhỏ.
Kiểm soát những vấn đề phát sinh (gotchas)
Điều quan trọng ở đây là bạn cần thực hiện các bước để ngăn chặn sự thẩm
định từ các domain controller của lag site từ khi nó có dữ liệu bảo mật (tài
khoản, mật khẩu, tài khoản bị khóa, thành viên nhóm,…) một tuần tuổi. Bạn
có thể thực hiện điều này bằng cách định nghĩa một chính sách site cho lag
site và định nghĩa thiết lập "DCLocator DNS Records Not Registered by the
DCs". Trường Mnemonics được mô tả trong tab Explain. Bạn cần gộp tất cả

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

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 3: Site ATL tạo bản sao cho site LA thông qua các bộ điều khiển miền
CHI site

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:

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ừ

xa.

Không tự tạo các đối tượng kết nối đến site khôi phục thảm họa.

Windows 2000 có nhiều nhược điểm trong việc dọn dẹp các đối tượng
kết nối cũ khi site lỗi hoạt động trở lại, yêu cầu các quản trị viên phải
tự thực hiện hành động này. Tuy nhiên Windows 2003 đã khắc phục
được yếu điểm này.

Tất cả đều dựa vào việc có kết nối mạng vật lý giữa site khôi phục
thảm họa và các site từ xa.

Cần test cẩn thận trong phòng lab trước khi đưa vào môi trường ứng
dụng.

Trong trường hợp có nhiều hub site lõi, khi một hub site bị lỗi (và Site
Link Bridge được kích hoạt), KCC sẽ định tuyến các kết nối đến các
nút khác. Tất cả chúng trở thành các site khôi phục thảm họa cho
nhau.
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.