Thử thách của tôi
Chúng tôi có máy chủ Exchange tại các trang web khác nhau, nhưng cũng có trên tàu. Các tàu được kết nối với mạng của chúng tôi thông qua các liên kết vệ tinh khi ở trên biển, nhưng chuyển sang cầu WiFi khi ở cảng.
Do độ trễ cao (500+ ms) và thả ra không phổ biến (ví dụ: khi tàu đang quay đầu), cố gắng gửi bất kỳ e-mail nào trên một vài megabyte khi ở trên biển, có khả năng bị lỗi và được thử lại cho đến giới hạn đã đạt được. Kết quả: Email không được gửi và mỗi lần thử sẽ tiêu tốn băng thông có giá trị trên liên kết sat.
Một "giải pháp" là giới hạn kích thước e-mail tối đa là 5 MB, nhưng điều đó hầu như không thân thiện với người dùng và hạn chế không cần thiết khi ở trong cổng.
Ý tưởng thô
Điều tôi muốn làm là xếp hàng tất cả các e-mail lớn hơn giới hạn đã đặt để gửi sau này khi ở trên biển, trong khi gửi tất cả các e-mail nhỏ ngay lập tức. Sau đó tôi đã nghĩ rằng tôi sẽ ping máy chủ vận chuyển trung tâm trong trung tâm dữ liệu của chúng tôi thường xuyên, khi độ trễ giảm xuống dưới 400 ms, tôi sẽ bắt đầu xử lý hàng đợi email lớn. Khi độ trễ tăng hơn 400 ms, tôi sẽ cắm lỗ và để e-mail xếp hàng lại.
Bây giờ, tôi đã không thực sự bẩn với Exchange kể từ phiên bản 2003. Trước đó, bạn có thể lên lịch các e-mail lớn để gửi sau, vì vậy ý tưởng của tôi là làm một cái gì đó tương tự trong Exchange 2010, sau đó viết kịch bản một cách để chuyển giao lên lịch cho các e-mail lớn giữa 'luôn luôn' và 'không bao giờ'.
Trở ngại
Không nên quá phức tạp để tạo một tập lệnh như vậy, nhưng sau đó tôi đọc rằng tính năng mà tôi dựa vào đã bị xóa với Exchange 2007:
Đây là một tính năng có trong Exchange 2003 nhưng đã bị xóa trong Exchange 2007. Nó được đặt trên Trình kết nối SMTP với 'sử dụng thời gian gửi khác nhau cho các tin nhắn quá khổ'.
TechCenter: Có thể lên lịch gửi email dựa trên kích thước trong Exchange không?
Câu hỏi
Có đúng không - Tính năng này không còn xuất hiện trong Exchange 2010 hay chỉ đơn thuần là nó được chuyển đổi thành thứ tương tự, tôi có thể sử dụng để thực hiện mục tiêu của mình không? Nếu vậy thì sao?
Có cách nào khác để trì hoãn việc gửi e-mail lớn trên các máy chủ Exchange nhất định không? Nó có thể dựa trên lịch trình hoặc thậm chí có thể yêu cầu hành động cụ thể - Tôi khá chắc chắn sẽ có một số cách để kích hoạt phân phối thông qua tập lệnh, tôi chỉ cần e-mail lớn trong một hàng đợi riêng trên tàu.
Suy nghĩ của bạn về điều này sẽ được đánh giá cao! :-)
Chỉnh sửa # 1: Ý tưởng thô tinh tế
Tôi tình cờ thấy hai CmdLets PowerShell mà tôi nghĩ có thể mang lại cho tôi khá gần với mục tiêu của mình:
Tôi đã chơi đùa với Get-Message một lúc, để xem những loại tin nhắn mà các lệnh trên sẽ xử lý.
Quan trọng nhất, các lệnh này chấp nhận một bộ lọc kích thước tin nhắn. Lệnh này sẽ liệt kê các tin nhắn được xếp hàng, trên máy chủ hiện tại, lớn hơn 5 MB (5.242.880 byte):
get-message -Filter {Size -gt 5242880}
Dường như Get-Messagechỉ trả về tin nhắn từ các hàng đợi giao hàng từ xa khác nhau. Tuy nhiên, các tin nhắn chảy trong máy chủ, tuy nhiên, có hiển thị trong một hàng đợi mà Nhận / Tạm dừng / Tiếp tục-Tin nhắn sẽ gây rối không?
Nếu không, giải pháp có thể đơn giản như một tập lệnh được lên lịch cứ sau vài phút, dọc theo dòng (trong mã giả):
if ping_rtt > 400 Then
Suspend-Message -Filter {Size -gt 5242880}
Else
Resume-Message
EndIf
Mối quan tâm / câu hỏi tiếp theo:
Chủ yếu là không liên quan bây giờ - xem chỉnh sửa # 2.
Sẽ Get-Messagechỉ trả lại tin nhắn từ hàng đợi giao hàng từ xa - không bao giờ tin nhắn cho phân phối nội bộ máy chủ? Nếu không, tên nhận dạng của hàng đợi phân phối từ xa có tuân theo một mẫu nhất định mà tôi có thể sử dụng để lọc không?
Điều này có thể / nên được thực hiện thông qua Đại lý vận tải tùy chỉnh (như được đề xuất bởi @longneck) hoặc Sự kiện chìm (nếu khái niệm này vẫn tồn tại trong Exchange 2010)?
Giả sử tôi chạy tập lệnh cứ sau 5 phút, điều đó vẫn có nghĩa là các tin nhắn lớn được gửi, có khả năng gây ra sự cố trong tối đa 5 phút, trước khi bị treo. Chúng tôi vẫn tốt hơn so với hiện tại, nhưng nó không tối ưu. Tôi có thể tăng tần suất lên mỗi phút, nhưng nó sẽ không phải là giải pháp tao nhã nhất.
Ngay cả khi tôi chỉ kiểm tra thời gian khứ hồi cứ sau 5 phút (để lưu lượng truy cập sat), tôi cần cài đặt cơ chế Exchange nào, để kiểm tra RTT được ghi lại gần đây, mỗi lần gửi tin nhắn đi đến gửi từ xa xếp hàng, và sau đó có hành động khủng bố?
Chỉnh sửa # 2: Giải pháp đề xuất
Cho phép tôi tóm tắt các giải pháp được đề xuất, ưu và nhược điểm của chúng khi tôi thấy:
Đại lý vận tải tùy chỉnh
Ý tưởng
- Định kỳ theo dõi độ trễ, phân loại là cao hay thấp (ngưỡng: 400 ms?)
- Thông qua Đại lý vận tải tùy chỉnh, tạm dừng / tiếp tục tất cả các email lớn hơn ngưỡng đã đặt, khi phân loại độ trễ thay đổi
- Thông qua TA tùy chỉnh, ngay lập tức đặt các tin nhắn lớn sau đó được gửi ở chế độ "tạm dừng", nếu độ trễ cao
Điểm mạnh
- Email lớn không bao giờ được gửi đi khi độ trễ cao
Những điểm yếu
- Không có kỹ năng phát triển để thực hiện điều này trong nhà (lưu ý đến bản thân: mã nguồn nên thuộc về công ty của tôi như một phần của hợp đồng với nhà phát triển bên ngoài)
- Phần mềm bên thứ 3 liên kết với Exchange có thể gây ra sự cố khi vá hoặc cập nhật
- Một số loại thỏa thuận hỗ trợ cần thiết, trong trường hợp có sự cố xảy ra (xem bên trên)
Tin nhắn lớn vừa phải
Ý tưởng
- Định kỳ theo dõi độ trễ, phân loại là cao hay thấp (ngưỡng: 400 ms?)
- Dựa trên phân loại độ trễ, định cấu hình Quy tắc vận chuyển trao đổi thông qua tập lệnh, để cho phép tất cả các thông báo truyền hoặc chuyển tiếp thư lớn đến người điều hành
- Phê duyệt tin nhắn trong hàng đợi của người điều hành khi tàu cập cảng, có thể là do con người
Điểm mạnh
- Email lớn không bao giờ được gửi đi khi độ trễ cao
- Tin nhắn bị treo bằng cách sử dụng Quy tắc giao thông gốc
Những điểm yếu
- Nhìn bề ngoài, tin nhắn không thể được phê duyệt theo chương trình khi độ trễ thấp, do đó cần có sự can thiệp của con người mỗi khi tàu cập cảng
- Có thể các vấn đề riêng tư, nếu kiểm duyệt không được xử lý theo chương trình
Câu hỏi
- Có thể thông điệp được phê duyệt theo chương trình từ hộp thư người điều hành? Làm sao?
Các lệnh PowerShell được lên lịch
Ý tưởng
- Định kỳ theo dõi độ trễ, phân loại là cao hay thấp (ngưỡng: 400 ms?)
- Miễn là độ trễ cao, thường xuyên (mỗi phút?) Đình chỉ bất kỳ tin nhắn lớn nào (
Suspend-Message -Filter {Size -gt 5242880}) - Khi độ trễ giảm xuống mức thấp, hãy tiếp tục tất cả các tin nhắn (
Resume-Message)
Điểm mạnh
- Rất đơn giản để thực hiện
Những điểm yếu
- Không phải là giải pháp thanh lịch nhất
- Việc gửi từng tin nhắn lớn mới có thể được cố gắng miễn là khoảng thời gian giữa
Suspend-Messagecác lệnh, có thể vẫn lãng phí một số băng thông và tạo ra các tắc nghẽn (mặc dù rất ngắn so với không làm gì cả)
Câu hỏi
- Bất kỳ ý tưởng nào về cách ngăn chặn các nỗ lực gửi tin nhắn lớn,
Suspend-Messagecác lệnh ở giữa ? - Sẽ
Get-Messagechỉ trả lại tin nhắn từ hàng đợi giao hàng từ xa - không bao giờ tin nhắn cho phân phối nội bộ máy chủ? Nếu không, tên nhận dạng của hàng đợi phân phối từ xa có tuân theo một mẫu nhất định mà tôi có thể sử dụng để lọc không?
Chỉnh sửa # 3: Con đường phía trước
Sau khi đưa các giải pháp được đề xuất lên trong nhóm của tôi (bao gồm cả proxy proxy mà tôi không thể đưa vào chỉnh sửa # 2) và dựa trên cảm giác ruột của mình, chúng tôi đã quyết định chọn một Đại lý vận tải trao đổi tùy chỉnh.
Tôi đang liên lạc với một vài công ty tư vấn, họ sẽ liên hệ lại với tôi về cách thức tấn công vấn đề và chi phí sẽ là bao nhiêu.
Nếu bạn có bất kỳ kinh nghiệm nào về việc thuê ngoài các nhiệm vụ lập trình, vui lòng để lại phản hồi cho câu hỏi liên quan của tôi về Stack Overflow , vì tôi không biết.