Bài toán Domain trong triển khai Hyper-V – Phần 2

Trong phần hai của loạt bài này, chúng tôi sẽ tiếp tục giới thiệu cho các bạn một số tùy chọn cho việc ảo hóa domain controller.

Ở phần cuối của phần một chúng tôi đã đề cập đến khả năng tạo một Active Directory forest hoàn toàn độc lập để quản lý các host ảo của bạn. Ưu điểm của phương pháp này là cho phép bạn ảo hóa tất cả các domain controller sản xuất của mình trong khi đó vẫn có thể sử dụng các công cụ quản lý phụ thuộc Active Directory.

Mặc dù có một số nhược điểm trong việc đặt các host ảo của bạn vào một forest chuyên dùng. Như chúng tôi đã ám chỉ trong phần trước, một trong những bất thuận lợi lớn là yêu cầu của cơ sở hạ tầng. Nói theo cách khác, một forest chuyên dụng sẽ yêu cầu các domain controller riêng, DNS server riêng và nó cũng thể yêu cầu các kiểu máy chủ cơ sở hạ tầng khác chẳng hạn như các máy chủ quản lý bản vá, quản lý antivirus hoặc backup.

Một bất thuận lợi nữa trong việc tạo một forest chuyên dụng cho các host ảo là sự mất kết nối giữa forest ảo và forest sản xuất. Phụ thuộc vào cấu hình mạng của bạn, sự mất kết nối này có thể ngăn chặn việc chia sẻ các thông tin Active Directory giữa hai forest. Điều này có thể khó giải quyết nếu bạn đang sử dụng giải pháp backup phụ thuộc vào Active Directory và muốn backup các máy chủ từ cả hai forest.

Thậm chí ngay cả khi bạn không quan tâm đến sự cách ly Active Directory gây ra bởi việc sử dụng nhiều forest thì yêu cầu về cơ sở hạ tầng liên quan trong việc tạo một forest hoàn toàn độc lập cho các host ảo hóa có thể sẽ làm bạn phân vân rằng liệu sử dụng phương pháp này có đáng với nỗ lực của mình. Quả thực không có chiến lược nào cho việc ảo hóa và tổ chức các domain controller là hoàn hảo. Tuy nhiên vẫn có một số thứ để bạn có thể làm cho phương pháp này trở nên lôi cuốn hơn đôi chút.

Một phương pháp mà bạn có thể sử dụng ở đây là cấu hình hai máy chủ vật lý làm việc như các domain controller cho miền sản xuất. Sau đó có thể cấu hình một trong hai domain controller vật lý làm việc như một DNS server tích hợp Active Directory.

Khi hoàn tất cấu hình này, bạn có thể join các máy chủ host của mình vào miền sản xuất mà không cần phải lo lắng về nghịch biện “trứng có trước hay gà có trước”. Bạn có thể thực hiện ảo hóa một cách an toàn tất cả các domain controller của mình, ngoại trừ hai domain controller mà vừa thiết lập. Rõ ràng trong cách thực hiện này, chúng ta đã thừa nhận rằng forest đang được đề cập đến chỉ gồm có một miền. Trong các phần sau của loạt bài này, chúng tôi sẽ đề cập đến các chế độ ảo hóa đa miền, còn lúc này đây chúng tôi chỉ muốn đơn giản hóa mọi thứ bằng cách sử dụng một domain forest.

Nhân tố cơ bản nằm bên dưới việc sử dụng phương pháp này là nó bảo vệ bạn tránh được các lỗi máy chủ host (tối thiểu cũng được vài mức). Chúng ta giả sử rằng hai domain controller vật lý không tồn tại và rằng bạn đã ảo hóa tất cả các domain controller khác của mình. Phụ thuộc vào cách cấu hình các domain controller này, bạn có thể gặp tình huống mà ở đó lỗi của máy chủ host sẽ làm cho các domain controller ảo hóa của bạn trở thành không thể truy cập, do đó nó sẽ ngăn chặn việc đăng nhập vào mạng. Có hai domain controller vật lý riêng sẽ bảo đảm việc người dùng có thể đăng nhập vào mạng thậm chí khi toàn bộ cơ sở hạ tầng ảo hóa thất bại.

Rõ ràng việc đơn giản hóa ở con số hai domain controller vật lý là không đủ. Như những gì bạn có thể xem lại, chúng tôi đã đề cập rằng, một trong số hai máy chủ này cần được cấu hình làm DNS server. Cho đến đây chúng ta vẫn chưa cấu hình bất cứ máy nào trên mạng của mình để sử dụng nó như vậy. Lời khuyên ở đây là thiết lập máy chủ này làm DNS server thứ hai. Theo cách đó, các host trên mạng của bạn sẽ vẫn có thể sử dụng DNS server chính. Trong trường hợp DNS server chính của bạn hoặc các host mà nó cư trú trên bị lỗi thì DNS server vật lý vẫn có thể xử lý các truy vấn DNS trong mạng cho tới khi tình huống được khắc phục.

Một vấn đề khác mà bạn cần phải xét xem liệu có nên đi theo phương pháp này hay không nằm ở các role Flexible Single Master Operation. Windows 2000 Server và các phiên bản gần đây sử dụng chế độ tạo bản sao multi master, trong đó các nâng cấp cho cơ sở dữ liệu Active Directory có thể được ghi đè vào bất cứ domain controller có sẵn nào. Mặc dù vậy, một số domain controller được xem như quan trọng hơn một số domain controller khác. Các domain controller được gán cho các role Flexible Single Master Operation sẽ chịu trách nhiệm duy trì tính niêm trực của Active Directory. Cho ví dụ, domain controller đang nắm giữ Schema Master sẽ có trách nhiệm duy trì giản đồ Active Directory. Tất cả những sự thay đổi của giản đồ sẽ được ghi đè vào domain controller này.

Chúng tôi sẽ không biến bài viết này thành một thảo luận chuyên sâu về các Flexible Single Master Operations role và các chức năng của chúng mà chỉ đề cập đến sự thay thế role Flexible Single Master Operation bên trong môi trường ảo hóa.

Như những gì bạn biết, có hai kiểu role Flexible Single Master Operation; domain level role và forest level role. Khi bạn tạo một Active Directory forest, domain controller đầu tiên mà bạn thiết lập sẽ tự động được gán tất cả các role ở mức forest (forest level role) và tất cả các role mức miền (domain level role) cho miền mà bạn đã tạo. Nếu bạn tạo các miền bổ sung bên trong forest thì domain controller đầu tiên trong mỗi miền sẽ được gán các role mức miền cho miền đó.

Với lưu ý đó chúng ta hãy quay lại chế độ ảo hóa của mình với hai domain controller vật lý và tất cả các domain controller đã được ảo hóa. Chúng ta hãy tiếp tục giả định rằng chế độ này được áp dụng cho một forest chỉ gồm có một miền đơn.

Vì tất cả các domain controller đang tồn tại đều đã được ảo hóa, điều đó cũng có nghĩa rằng tất cả các flexible single master operation role đều đang được cấu hình trên domain controller ảo. Do Active Directory không thể thực hiện lâu mà không cần truy cập vào domain controller, nơi các role được gán nên chúng ta cần phải quan tâm đến có nên hay không ảo hóa domain controller này.

Theo quan điểm của chúng tôi, sẽ không có gì bất lợi trong việc ảo hóa domain controller đang giữ các flexible single master operations role. Tuy các máy chủ host có thể lỗi, làm cho domain controller lỗi theo với nó, nhưng các máy chủ vật lý cũng có thể bị lỗi như vậy.

Lý do tại sao chúng ta tin ảo hóa domain controller gồm các Flexible Single Master Operations role an toàn là vì lỗi xảy ra với domain controller này sẽ không thê thảm (giả định rằng có một số domain controller khác trên mạng). Miễn là một số domain controller và một DNS server còn trên mạng của bạn thì Active Directory sẽ tiếp tục hoạt động bình thường trong một thời gian.

Nếu lỗi xuất hiện cho thấy rằng dường như việc khôi phục là không thể thì bạn có thể bỏ các role flexible single master operations ra khỏi domain controller bị lỗi và bổ nhiệm các role vào domain controller đang làm việc. Khả năng này sẽ an toàn hơn nếu ảo hóa các domain controller thậm chí nếu chúng có các flexible single master operations role.

Kết luận

Trong phần này, chúng tôi đã giới thiệu được cho các bạn một số ưu điểm trong việc sử dụng máy chủ vật lý để thực hiện nhiệm vụ như các domain controller, trong bài cũng đề cập đến sự an toàn trong việc sử dụng các domain controller đã được gán flexible single master operations role. Trong phần ba của loạt bài này, chúng tôi sẽ tiếp tục giới thiệu thêm về chế độ thay thế domain controller và sự thay thế máy chủ global catalog.

Quantrimang

Posted on 29/12/2010, in Hyper-V, Microsoft and tagged , , . Bookmark the permalink. Để lại bình luận.

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s

%d bloggers like this: