Cân bằng tải các máy chủ Exchange 2007 SP1 Hub Transport bằng kỹ thuật Windows Network Load Balancing (Phần 2)

Cân bằng tải các máy chủ Exchange 07 SP1 Hub Transport bằng kỹ thuật Windows Network Load Balancing (Phần 1)

Henrik Walther

Trong phần hai và cũng là phần cuối của loạt bài hai phần này, chúng tôi giới thiệu cho các bạn cách cung cấp dung sai lỗi cũng như việc cân bằng tải cho các máy chủ Exchange 07 SP1 Hub Transport bằng công nghệ Windows Network Load Balancing.

Tạo và bổ sung bộ kết nối nhận trên các máy chủ Hub Transport

Như chúng tôi đã đề cập ở phần 1 của loạt bài này, Hub Transport chỉ hỗ trợ để cân bằng tải các kết nối SMTP đi về (inbound) đến từ các ứng dụng (như LOB application, MOSS 07, SCOM 07,…) và các nguồn non-Exchange khác sử dụng công nghệ WNLB. Để không ảnh hưởng tới truyền thông bên trong tổ chức (intra-org) (Hub Transport server đến Hub Transport server), chính vì vậy chúng ta phải tạo một bộ nhận mới để lắng nghe trên cổng /SMTP bằng cách sử dụng địa chỉ IP ảo đã chỉ định khi tạo NLB cluster. Để thực hiện điều đó, bạn khởi chạy Exchange Management Console và kích vào Server Configuration, sau đó là Hub Transport. Lúc này bạn hãy chọn Hub Transport server đầu tiên trong panel kết quả, sau đó mở trang thuộc tính cho bộ nhận mặc định trong panel làm việc như thể hiện trong hình 1 bên dưới.

Hình 1: Mở trang thuộc tính cho bộ nhận mặc định

Kích vào tab Network và cấu hình địa chỉ IP thành địa chỉ non-cluster bên trong (hình 2).

Hình 2: Chỉ định địa chỉ IP non-clustered cho bộ nhận máy chủ mặc định

Bây giờ bạn hãy tạo một bộ nhận mới (kiểu tùy chọn) và tên Inbound SMTP relay (WNLB), sau đó kích Next (hình 3).

Hình 3: Đặt tên cho bộ nhận Receive WNLB mới

Trên cửa sổ Local Network Settings (hình 4), bạn cấu hình bộ nhận để nó chỉ lắng nghe cổng trên địa chỉ NLB cluster, địa chỉ trong ví dụ là 10.10.1.194. Bạn cũng có thể nhập vào một FQDN cho bộ kết nối (connector). Kích Next để tiếp tục.

Hình 4: Cấu hình bộ nhận để lắng nghe trên địa chỉ IP NLB cluster ảo

Lúc này bạn hãy nhập vào địa chỉ IP được cho phép để chuyển tiếp (relay) thông qua bộ nhận. Không được chỉ định một dải ở đây mà chỉ có địa chỉ IP chỉ định đã được cấu hình trên máy chủ đang chạy các ứng dụng đệ trình thông báo đến Exchange 07 thông qua bộ nhận này (hình 5). Sau đó kích Next.

Hình 5: Địa chỉ IP cần được cho phép để đệ trình các thông báo đến bộ nhận này

Cuối cùng bạn kích New và sau đó là Finish để tạo một bộ nhận mới (hình 6).

Hình 6: Trang hoàn tất

Bây giờ bạn hãy mở trang thuộc tính cho bộ nhận mới, sau đó kích tab Permission Groups. Dưới tab này, bạn hãy tích vào tùy chọn “Anonymous users” như trong hình 7.

Hình 7: Cho phép người dùng nặc danh đệ trình các thông báo đến bộ nhận

Tiếp đến chúng ta phải công nhận các điều khoản cần thiết theo thứ tự cho các địa chỉ IP điều khiển xa nào đó nhằm có thể relay thông qua bộ nhận này. Để thực hiện điều đó, bạn phải mở Exchange Management Shell và đánh vào đó lệnh dưới đây:

Get-ReceiveConnector "Inbound SMTP relay (WNLB)" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Hình 8: Cho phép các điều khoản cần thiết đối với một bộ nhận mới

Bây giờ bạn hãy thực hiện các bước tương tự trên máy chủ Hub Transport thứ hai.

Kiểm tra kết nối Hub Transport Server thông qua NLB Cluster FQDN

Lúc này hai Hub Transport Server đã được bổ sung như các nút trong WNLB cluster cũng như các bộ nhận mới đã được tạo cho địa chỉ IP ảo WNLB, chúng ta lúc này có thể telnet đến các cổng và 587 bằng cách sử dụng NLB cluster FQDN, yếu tố cho mục đích trong bài này là mail.ehlo.dk. Để thực hiện như vậy, bạn hãy mở cửa sổ lệnh trên máy chủ điều khiển xa (máy chủ có thể đệ trình các thông báo đến Exchange 07 bằng NLB FQDN) và đánh vào đó:
Telnet mail.ehlo.dk

Khi đó bạn sẽ thấy được ESMTP banner từ một trong các máy chủ Hub Transport (xem trong hình 9 bên dưới).

Hình 9: ESMTP Banner từ bộ nhận chuyên dụng WNLB của HT01

Telnet đến cổng 587 cũng cần phải có kết quả ESMTP banner tương tự (cổng 587 là cổng được sử dụng bởi bộ nhận Client trong máy chủ Hub Transport của Exchange 07 mặc định).

Chúng ta hãy thử telnet các máy chủ Hub Transport đang sử dụng bộ nhận mặc định bằng FQDN cho bản thân các máy chủ (trong trường hợp này là ht01.ehlo.dk và ht02.ehlo.dk). Cách làm này cho kết quả hơi khác so như những thể hiện trong hình 10.

Hình 10: Telenet đến bộ nhận máy mặc định

Cho đến lúc này mọi thứ đều tốt, chúng ta đã xác minh là có thể đệ trình các thông báo bằng cách sử dụng một bộ nhận mới sử dụng NLB cluster FQDN (mail.ehlo.dk).

Kiểm tra tính đàn hồi cho Hub Transport Server

Chúng ta hãy xem xem máy chủ điều khiển xa (nguồn non-Exchange như ứng dụng LOB, MOSS 07, hoặc SCOM 07) cần để đệ trình các thông báo đến Exchange 07 trong thực tế có thể thực hiện như vậy không khi một trong các nút NLB cluster có vấn đề. Để kiểm tra tình trạng làm việc này, chúng ta hãy drainstop nút đầu tiên, trong bài của chúng tôi là HT01. Chúng ta thực hiện điều này bằng cách mở NLB Manager và kích chuột phải vào nút đầu tiên, sau đó chọn Drainstop như trong hình 11.

Hình 11: Drainstop nút đầu tiên trong NLB Cluster

Khi nút thứ nhất này đã được Drainstop, biểu tượng của nó sẽ chuyển thành màu đỏ (hình 12) và chúng ta có thể thực hiện bài test của mình ở đây.

Hình 12: HT01 bị drainstop

Chúng ta hãy thử telnet đến cổng bằng NLB cluster FQDN lai một lần nữa. Như những gì bạn thấy trong hình 13 thì chúng ta đã kết nối với HT02, đây chính là nút thứ hai trong NLB cluster.

Hình 13: Các kết quả thu được trong kết nối ESMTP đến mail.ehlo.dk

Rõ ràng chúng ta hiện đã xác định được có cài đặt một độ co dãn trong làm việc Hub Transport server bằng công nghệ WNLB cho cả hai khi nói về truyền thông intra.org cũng như truyền thông từ các nguồn non-Exchange đến các máy chủ Hub Transport. Mặc dù nó nằm bên ngoài phạm vi của bài này nhưng bạn hoàn toàn vẫn có thể sử dụng một phần cứng dựa trên giải pháp cân bằng tải hoặc nếu có nhiều máy chủ ISA đã được cấu hình trong một mảng máy chủ này thì hãy thực hiện cân bằng tải trên máy chủ ISA trong các tổ chức mạng của bạn.

Cung cấp khả năng khắc phục lỗi và cân bằng tải cho các thư gửi đi

Cho đến lúc này, chúng tôi đã giới thiệu được cho các bạn cách dàn tải các thư đã được đệ trình từ một ứng dụng LOB bằng WNLB, chúng tôi sẽ tiếp tục giải thích cho các bạn cách cân bằng tải cũng như cung cấp khả năng khắc phục sự cố cho luồng mail gửi đi. Quả thực đây là một nhiệm vụ rất đơn giản trong thao tác. Bạn chỉ cần thêm vào một số máy chủ Hub Transport trong tab Source Server của Send Connector, đây chính là nơi định tuyến các thư (hoặc có lẽ là định tuyến đến một tập các cổng SMTP trong mạng ). Tuy vậy, bạn cần lưu ý rằng việc cân bằng tải sẽ không làm việc cho Send connector riêng lẻ nào trừ khi máy chủ Hub Transport nằm trong tab Source Server là từ cùng một vị trí Active Directory.

Vì vậy để bổ sung thêm các máy chủ nguồn Hub Transport vào Send Connector, bạn cần phải mở Exchange Management Console (EMC), vào Organization Configuration và tìm đến cây thư mục bên phần bên trái của giao diện điều khiển. Ở đây bạn cần phải chọn Hub Transport và kích vào tab Send Connector. Lúc này hãy mở trang thuộc tính của Send Connector tương ứng và kích tab Source Server như trong hình 14 bên dưới. Tiếp đến, bạn bổ sung thêm các máy chủ Hub Transport được yêu cầu bằng cách kích vào nút Add và áp dụng các thiết lập.

Hình 14: Nhiều máy chủ nguồn (Source Servers) trong Internet Send Connector

Tất cả các thư gửi đi lúc này sẽ được cân bằng tải giữa các máy chủ nguồn và nếu một trong số các máy chủ này gặp sự cố (có thể là để bảo trì) thì máy chủ Hub Transport cần cung cấp thư đến người nhận bên ngoài tổ chức của bạn sẽ chọn máy chủ nguồn kế tiếp để thực hiện nhiệm vụ. Có một thứ cần lưu ý ở đây là nếu một máy chủ Hub Transport nào đó đang chuyển tiếp thư tín vào mạng Internet, máy chủ này cũng được liệt kê trong tab Source Server của Send Connector, thì vấn đề cân bằng tải sẽ không xuất hiện vì các máy chủ nội bộ ở gần luôn có thứ bậc ưu tiên nhiều hơn.

Nếu Send Connector định tuyến các thư tín bên ngoài tổ chức được cấu hình phân phối thư đến một host thông minh nào đó thì bạn cần phải thêm các host thông minh đó vào để loại trừ tất cả các điểm lỗi trong topo định tuyến thư gửi đi.

Nếu bạn sử dụng các máy chủ Edge Transport đã được đăng ký như một giải pháp lọc virus và spam trong mạng vành đai của mình thì nên thay vì các máy chủ Hub Transport mà bổ sung các máy chủ Edge Transport đã được đăng ký trong tab Source Server (như trong hình 15). Điều này sẽ bảo đảm cho tất cả các thư gửi đi được cân bằng tải giữa các máy chủ Edge Transport trong mạng vành đai.

Hình 15: Edge Transport Server đã đăng ký được liệt kê trong tab Source Server

Lưu ý rằng chỉ có một máy chủ Edge Transport được liệt kê trong hình , điều này là vì chúng tôi chỉ có một máy chủ này được đăng ký với Exchange trong môi trường lab sử dụng cho mục đích của bài này. Khi sử dụng các máy chủ Edge Transport được đăng ký trong tổ chức Exchange của bạn, các thiết lập Send connector sẽ tự động được nhân lên đối với các máy chủ Edge Transport được liệt kê trong tab Source Server.

Kiểm tra khả năng khắc phục lỗi và cân bằng tải cho các thư gửi đi

OK, chúng ta hãy thẩm định khả năng khắc phục lỗi và cơ chế cân bằng tải làm việc như thế nào. Để thực hiện điều đó, bạn hãy gửi thư test từ một máy chủ Exchange 07 của nhóm thứ ba nào đó trong môi trường lab của bạn. Máy chủ này có cài đặt các role Mailbox, Client Access và Hub Transport, và mặc dù máy chủ này là Hub Transport server nhưng nó không được bổ sung như một máy chủ nguồn trong end Connector, điều đó có nghĩa rằng nó sẽ cung cấp thư test gửi đi đến HT01 hoặc HT02. Hình 16 thể hiện Internet Mail header của thư test này trong Mail client của người nhận bên ngoài.

Hình 16: HT01.ehlo.dk là máy chủ nguồn trong Internet Mail Header

Giờ chính là thời điểm chúng ta tắt Hub Transport server (HT01) đầu tiên và sau đó gửi thêm một thư test nữa để có thể xem HT02 giải quyết tình trạng này như thế nào. Như các bạn có thể thấy trong hình 17, thư test của chúng ta đã được thực hiện thành công tốt đẹp.

Hình 17: HT02.ehlo.dk là máy chủ nguồn trong Internet Mail Header