Cân bằng tải xác thực Active Directory và chuyển đổi dự phòng

8

Đối với các ứng dụng xác thực với Active Directory DC, rõ ràng tốt nhất là chỉ trỏ chúng vào bản ghi DNS miền chính thay vì DC cụ thể để chuyển đổi dự phòng, cân bằng tải, v.v.

Thực tiễn tốt nhất cho những ứng dụng buộc bạn phải mã hóa IP của DC là gì? Thay vào đó, chúng tôi có thể mã hóa địa chỉ IP của bộ cân bằng tải để nếu một DC đi xuống, ứng dụng đó vẫn có thể xác thực. Có sự thay thế nào tốt hơn không?

— Derrick
nguồn

2

Bất cứ ai đã viết một ứng dụng buộc bạn phải mã hóa địa chỉ IP của bộ điều khiển miền vào đó sẽ không biết người đó đang làm gì.

— Ryan Ries

1

Tìm nhà phát triển ứng dụng và yêu cầu họ sửa nó.

— Michael Hampton

Nó chủ yếu dành cho một số ứng dụng cũ và các hộp NAS cũ mà chúng tôi chưa sẵn sàng để thay thế.

— Derrick

8

Active Directory đã có các kỹ thuật cân bằng tải được tích hợp trong nó. Máy khách Windows của bạn biết cách định vị bộ điều khiển miền dự phòng trong trang web của chính nó và cách sử dụng bộ điều khiển khác nếu không có bộ điều khiển đầu tiên. Không cần thực hiện cân bằng tải bổ sung, như các DC "phân cụm", v.v ... miễn là bạn có các DC dự phòng.

Theo một cách nào đó, bạn có thể nghĩ về Trang web Active Directory như một "bộ cân bằng tải", bởi vì các máy khách trong trang web đó sẽ chọn ngẫu nhiên một trong các DC trong cùng một trang. Nếu tất cả các DC trong một trang bị lỗi hoặc nếu trang đó không có DC, thì các máy khách sẽ chọn một trang khác (trang web gần nhất tiếp theo hoặc ngẫu nhiên.)

Bạn có thể tải cân bằng Dịch vụ DNS do Active Directory cung cấp cho các máy khách tham gia miền bằng cách đặt VIP trên bộ cân bằng tải phần cứng và có cân bằng tải VIP giữa một số bộ điều khiển miền. Sau đó, trên máy khách của bạn, đặt VIP đó làm máy chủ DNS ưa thích trong cấu hình TCP / IP.

Tôi đang làm điều đó ngay bây giờ cho một cơ sở hạ tầng toàn cầu và nó hoạt động rất tốt.

Nhưng điều đó chỉ áp dụng cho dịch vụ DNS.

Đừng cố tải cân bằng bộ điều khiển miền của bạn để xác thực. Đó là yêu cầu rắc rối. Ít nhất bạn sẽ phải thực hiện rất nhiều công việc SPN tùy chỉnh phức tạp và bạn sẽ tự mình thoát ra khỏi ranh giới hỗ trợ của Microsoft. Từ blog này, mà bạn nên đọc , tôi sẽ trích dẫn anh ấy:

Quay trở lại các nhà cung cấp và nói với họ rằng bạn không coi họ là AD Tích hợp và bạn sẽ tìm thấy một giải pháp khác.

Bây giờ đối với các ứng dụng yêu cầu bạn nhập địa chỉ IP của bộ điều khiển miền? Vâng, tôi sẽ chỉ nhắc lại nhận xét của tôi:

Bất cứ ai đã viết một ứng dụng buộc bạn phải mã hóa địa chỉ IP của bộ điều khiển miền vào đó sẽ không biết người đó đang làm gì.

— Ryan Ries
nguồn

Câu hỏi ban đầu là "Những thực tiễn tốt nhất cho những ứng dụng buộc bạn phải mã hóa IP của DC là gì?". Giả sử không có ứng dụng hợp pháp nào ngoài đó không hỗ trợ khám phá động là một giả định tồi. Có rất nhiều ứng dụng không phải Windows tồn tại muốn tự động chống lại Active Directory. Vì vậy, cách tốt nhất để làm cho các ứng dụng này hoạt động trong đó phát hiện DC động không phải là một tùy chọn?

— Dscoduc

@Dscoduc Nhận ứng dụng tốt hơn.

— Ryan Ries

3

chưa bao giờ có một lý do chính đáng để mã hóa IP hoặc sử dụng IP để giải quyết các truy vấn AD. Không có thực hành tốt nhất cho thực hành xấu.

— Jim B
nguồn

1

"Không có thực hành tốt nhất cho thực hành xấu." Trích dẫn trong ngày, thưa ông.

— mfinni

1

Một số câu trả lời khác cho câu hỏi này dường như cho rằng không có thế giới nào khác ngoài các ứng dụng nhận biết của Microsoft. Thật không may, đây không phải là trường hợp, như bằng chứng của câu hỏi ban đầu:

Thực tiễn tốt nhất cho những ứng dụng buộc bạn phải mã hóa IP của DC là gì?

Mặc dù Microsoft không hỗ trợ hoặc khuyên bạn nên sử dụng giải pháp NLB trước Active Directory, nhưng thực sự có một số tùy chọn để xác thực các ứng dụng nhận biết không phải của Microsoft AD.

— Dscoduc
nguồn

Để theo dõi qyestion này và câu trả lời đã đăng của tôi - công ty của tôi đã triển khai giải pháp F5 LDAP Local Traffic Manager mạnh mẽ hỗ trợ thành công Active Directory cho các hệ thống không phải Windows không có khả năng tận dụng dịch vụ DCLocator. Chúng tôi có sáu lưu lượng xử lý của LTM trên toàn thế giới mà không gặp vấn đề gì.

— Dscoduc

0

Một nhu cầu thực tế cho AD "Cân bằng tải" bên ngoài là rất hiếm, và rất khó để thực hiện đúng. Nhu cầu về các truy vấn thông thường có thể hoạt động tốt, tuy nhiên, ứng dụng khách và ứng dụng Windows thông thường cần thực hiện cập nhật. Một máy khách Windows cố gắng thiết lập mối quan hệ với một dc cụ thể, để nếu nó cập nhật một cái gì đó và ngay lập tức thử một thao tác tiếp theo, nó sẽ đạt cùng một dc. Các nhà phát triển ứng dụng làm điều tương tự. Nếu bạn viết mã tạo tài khoản người dùng, sau đó thử thay đổi mật khẩu trên tài khoản đó 1 ms sau đó, bạn cần phải nhấn cùng một dc.

Nếu bạn đã đến AD mặt trước với một số giải pháp cân bằng tải, bạn có quyền đảm bảo các phương pháp và mối quan hệ đó không bị phá vỡ.

Nếu nhu cầu là có sẵn, trái ngược với cân bằng tải, phân cụm có thể phù hợp hơn (cụm giun có thể sang một bên).

Trong các triển khai quảng cáo lớn, cách tiếp cận truyền thống hơn là xác định phần lớn người tiêu dùng và đưa họ vào một trang web có dc của chính họ. Ví dụ: nếu bạn có năm máy chủ Exchange, hãy tạo một trang web cho các mạng con cho các máy chủ đó và đặt các GC chuyên dụng vào trang web đó. Tương tự sẽ áp dụng cho các máy chủ khác như SharePoint.

— Greg Askew
nguồn