Các máy chủ Hyper-V đã kết nối với một miền

Tất cả khách hàng của tôi đều bé nhỏ các doanh nghiệp chỉ cố gắng để có được bằng. Không có ngân sách của công ty để thực hiện mọi thứ theo cách hoàn toàn đúng đắn mà không cần phải động tay động chân và dành thời gian để tạo dựng lòng tin.

Một tình huống phổ biến là kế thừa một trang web với một máy chủ vật lý chạy một vài máy chủ ảo. Máy chủ Hyper-V này thường nằm trong một nhóm làm việc. Những lần khác, nó được nối với miền, với DC chạy như một trong các máy ảo của nó.

Kịch bản miền làm cho việc quản lý trở nên dễ dàng hơn, nhưng ý tưởng về bộ điều khiển miền bị hỏng có vẻ có vấn đề. Tôi đã thấy một trường hợp DC VM không được đặt ở chế độ luôn tự động khởi động. Tôi đã phát hiện ra điều này trước khi tắt máy chủ để bảo trì kéo dài. Tôi cũng nhận ra rằng mật khẩu quản trị viên miền đã bị thay đổi gần đây, vì vậy có thể xảy ra sự cố khi đăng nhập vào máy chủ nếu DC không chạy và không có thông tin xác thực được lưu trong bộ nhớ cache.

Hầu hết các trang web nhỏ không có ngân sách để mua máy chủ vật lý thứ hai và nhờ tôi thiết lập DC trên cả hai, mặc dù tôi khuyên bạn nên làm như vậy. Tôi có thể từ chối công việc kinh doanh của họ hoặc thực hiện một số thỏa hiệp để làm tốt nhất có thể với những gì họ có thể chi trả.Nhưng tôi thực sự không thích trạng thái tên miền/nhóm làm việc ngẫu nhiên của các máy chủ vật lý từ trang này sang trang khác.

Tình huống trên với DC với tư cách là VM có phải là vấn đề nghiêm trọng không? Thời gian ngừng hoạt động của DC kéo dài có thể tạo ra tình huống như tôi đã đề cập khi bạn thậm chí không thể đăng nhập vào máy chủ để khởi động hoặc sửa chữa DC không?

Bộ điều khiển miền duy nhất có thể là khách trên máy ảo Hyper-V và máy chủ lưu trữ có thể là thành viên miền.

Một câu hỏi cơ bản hơn: liệu tổ chức có thể chấp nhận mức độ sẵn sàng này trong trường hợp xấu nhất không. Thực hiện bài tập kinh doanh liên tục chứng minh AD DS có thể được khôi phục và tác động của sự cố ngừng hoạt động đó.

• Xác nhận thông tin đăng nhập của quản trị viên cục bộ trên máy chủ.
• Tắt DC và giả vờ nó bị hỏng.
• Tạo một máy khách DC thử nghiệm, từ bất kỳ phần cứng bổ sung nào tiện dụng, một máy tính để bàn nếu cần. Cô lập nó hoàn toàn khỏi mạng, theo phương pháp hay nhất của AD DS cho phòng thử nghiệm.
• Khôi phục DC, từ bất kỳ bản sao lưu nào có sẵn, về DC thử nghiệm.
• Ứng dụng chạy thử trên DC thật, kiểm kê cái gì hỏng. Mật khẩu được lưu trong bộ nhớ cache sẽ hoạt động, nhưng không hoạt động khi thay đổi người dùng hoặc tra cứu thư mục. Nếu DNS bị hỏng, nhiều thứ sẽ không hoạt động.
• Ngắt nguồn DC kiểm tra, bật nguồn DC sản xuất.

Một khách DC có thể ổn. Dễ quản lý. Tiết kiệm chi phí. Mất vài giờ nếu điều tồi tệ nhất xảy ra và miền bị chuyển vào thùng rác, giả sử rằng các bản sao lưu vẫn tốt.

Nếu tác động không được chấp nhận, giá cho tính khả dụng cao là một DC khác.Tất nhiên, điều đó làm tăng chi phí cho phần cứng, phần mềm và độ phức tạp.

Hyper-V không cần miền có thể truy cập được để khởi động và khởi động các máy ảo. Đảm bảo rằng bạn có tài khoản người dùng quản trị viên cục bộ trên máy chủ mà bạn có thể đăng nhập vào máy chủ nếu cần.

Cá nhân tôi đã chứng kiến ​​rất nhiều tình huống và cá nhân tôi không thấy đó là vấn đề lớn.

Không có nhiều hơn một Bộ điều khiển miền là một vấn đề lớn hơn đối với tôi sau đó liệu máy chủ Hyper-V có được kết nối với miền hay không.

Kịch bản miền làm cho việc quản lý dễ dàng hơn, nhưng ý tưởng về miền bộ điều khiển đi xuống có vẻ có vấn đề.

Không, hoàn toàn không. Nó thực sự là một kịch bản được hỗ trợ đã được giới thiệu ở một trong các phiên bản trước đó, ngay cả đối với phân cụm (và ĐÓ có vấn đề vì cụm không thể bắt đầu nếu không có bộ điều khiển AD - bây giờ họ có thể).

Hoàn toàn không có gì không được hỗ trợ dưới dạng cấu hình tiêu chuẩn trong nhiều năm nay.

Tôi đã thấy một trường hợp DC VM không được đặt ở chế độ luôn tự động khởi động.

Một số người là những kẻ ngốc. Và việc không thiết lập DC làm tự khởi động mà không có lý do chính đáng nằm trong danh mục đó. Đó không phải là một cuộc tranh luận. Tôi đã từng chứng kiến ​​một chiếc ô tô bị cháy - điều đó không có nghĩa là đó không phải là vấn đề kỹ thuật.

Hầu hết các trang web nhỏ không có ngân sách để mua máy chủ vật lý thứ hai

Xin lỗi, đó là một cuộc tranh luận tồi tệ như nó diễn ra. Đó cũng chính là những trang web rên rỉ như điên - thời điểm máy chủ đầu tiên bị lỗi và phần cứng KHÔNG bị lỗi. Nếu doanh nghiệp của bạn phụ thuộc vào một máy chủ, thì tốc độ của máy chủ thứ hai đắt hơn bao nhiêu so với việc trả tiền cho mọi người hoặc thuê cho một tổ chức phi kinh doanh? Cùng một mức độ lập luận như "chúng tôi không thực hiện sao lưu" - không liên quan gì đến công ty (ĐÓ có nhiều dự phòng) nhưng với lẽ thường.

Tôi có thể từ chối công việc kinh doanh của họ hoặc thực hiện một số thỏa hiệp để làm tốt nhất Tôi có thể với những gì họ có thể mua được.

Tắt kinh doanh của họ. Trừ khi công việc kinh doanh của BẠN phụ thuộc vào nó, còn không thì việc từ chối làm những công việc liều lĩnh không có ý nghĩa gì đối với tình hình tài chính của bạn.

Tình huống trên với DC với tư cách là VM có phải là vấn đề nghiêm trọng không?

Tôi xin lỗi, nhưng vì đó là một kịch bản tiêu chuẩn được ghi lại thành tài liệu.... nên ghi rõ "bạn biết bao nhiêu về những chiếc máy mà bạn làm việc cùng". Nó đã từng là một hack, kể từ đó nó đã được tiêu chuẩn hóa.,

Thời gian ngừng hoạt động của DC kéo dài có thể tạo ra tình huống như tôi đã đề cập khi bạn thậm chí không thể đăng nhập vào máy chủ để bắt đầu hoặc sửa chữa DC?

Nếu bạn không đủ cẩn thận và vô hiệu hóa mật khẩu quản trị viên cục bộ có thể đóng vai trò là điểm truy cập khẩn cấp (và không nên vô hiệu hóa mật khẩu này trong trường hợp không có nhiều bản sao lưu) và điều đó KHÔNG tồn tại vào thời điểm bạn không chạy AD trên máy .... không có rủi ro.