Moje wyzwanie
Mamy serwery Exchange w różnych miejscach, ale także na pokładzie statków. Statki są podłączone do naszej sieci za pośrednictwem łączy satelitarnych na morzu, ale przełączają się na mosty WiFi, gdy są w porcie.
Ze względu na duże opóźnienia (500+ ms) i nierzadkie wypadanie (np. Podczas zawracania statków), próba wysłania wiadomości e-mail o rozmiarze przekraczającym kilka megabajtów na morzu prawdopodobnie zakończy się niepowodzeniem i zostanie podjęta ponowna próba do limitu zostało osiągnięte. Wynik: wiadomość e-mail nie zostanie dostarczona, a każda próba zużywa cenną przepustowość łącza sat.
Jednym z „rozwiązań” jest ograniczenie maksymalnego rozmiaru wiadomości e-mail do 5 MB, ale jest to mało przyjazne dla użytkownika i niepotrzebne ograniczenie, gdy jest się w porcie.
Szorstki pomysł
Wolę raczej ustawiać w kolejce wszystkie wiadomości e-mail większe niż ustalony limit, aby móc je później dostarczyć na morzu, a jednocześnie natychmiast wysyłać wszystkie małe wiadomości e-mail. Pomyślałem wtedy, że będę regularnie pingować serwer transportu koncentrującego w naszym centrum danych, gdy opóźnienie spadnie poniżej ~ 400 ms, zacznę przetwarzać dużą kolejkę wiadomości e-mail. Gdy opóźnienie wzrasta o ponad 400 ms, zatkam dziurę i pozwolę, aby e-maile znów stały w kolejce.
Teraz nie zabrudziłem sobie rąk Exchange bardzo od wersji 2003. Wtedy można było zaplanować wysyłanie dużych e-maili do późniejszego dostarczenia, więc moim pomysłem było zrobienie czegoś podobnego w Exchange 2010, a następnie napisanie skryptu na sposób zmiany dostawy harmonogram dużych e-maili pomiędzy „zawsze” i „nigdy”.
Przeszkoda
Stworzenie takiego skryptu nie powinno być zbyt skomplikowane, ale potem przeczytałem, że funkcja, na której polegam, została usunięta z Exchange 2007:
Ta funkcja była obecna w programie Exchange 2003, ale została usunięta dla programu Exchange 2007. Została ustawiona na łączniku SMTP z opcją „używaj różnych czasów dostarczania wiadomości o dużych rozmiarach”.
pytania
Czy to prawda? - Czy ta funkcja nie jest już dostępna w programie Exchange 2010, czy po prostu przekształciła się w coś podobnego, którego mogę użyć do osiągnięcia celu? Jeśli tak to co?
Czy istnieje inny sposób odroczenia dostarczania dużych wiadomości e-mail na niektórych serwerach Exchange? Może być oparty na harmonogramie, a może nawet wymagać określonego działania - jestem całkiem pewien, że będzie jakiś sposób na uruchomienie dostawy za pomocą skryptu, po prostu potrzebuję dużych wiadomości e-mail w osobnej kolejce na statkach.
Twoje przemyślenia na ten temat będą bardzo mile widziane! :-)
Edycja nr 1: Udoskonalony szorstki pomysł
Natknąłem się na dwa polecenia cmdlet programu PowerShell, które moim zdaniem mogą przybliżyć mnie do celu:
Przez jakiś czas bawiłem się Get-Message, aby zobaczyć, z jakimi wiadomościami radzą sobie powyższe polecenia.
Co najważniejsze, te polecenia akceptują filtr rozmiaru wiadomości. To polecenie wyświetli komunikaty w kolejce, na bieżącym serwerze, większe niż 5 MB (5 242 880 bajtów):
get-message -Filter {Size -gt 5242880}
Wygląda na to, że Get-Messagezwraca tylko wiadomości z różnych kolejek dostarczania zdalnego. Ale czy wiadomości płynące w obrębie serwera, choć krótko, pojawiają się w kolejce, z którą będą się bał się Get / Suspend / Resume-Message?
Jeśli nie, rozwiązanie może być tak proste jak zaplanowany skrypt co kilka minut, zgodnie z linijką (w pseudo kodzie):
if ping_rtt > 400 Then
Suspend-Message -Filter {Size -gt 5242880}
Else
Resume-Message
EndIf
Obawy / pytania uzupełniające:
Przeważnie nieistotne teraz - patrz edycja # 2.
Czy będą Get-Messagezwracać tylko wiadomości z kolejek dostarczania zdalnego - nigdy wiadomości do dostarczenia wewnątrz serwera? Jeśli nie, to czy nazwa tożsamości kolejek dostarczania zdalnego jest zgodna z określonym wzorcem, którego można użyć do filtrowania?
Czy można to zrobić za pomocą niestandardowego agenta transportowego (zgodnie z sugestią @longneck) lub zlewu zdarzeń (jeśli ta koncepcja nadal istnieje w programie Exchange 2010)?
Załóżmy, że uruchamiam skrypt co 5 minut, co nadal oznacza, że wysyłane są duże wiadomości, może potencjalnie powodować problemy do 5 minut, zanim zostanie zawieszony. Nadal byłoby nam lepiej niż obecnie, ale nie jest to optymalne. Mógłbym zwiększać częstotliwość do każdej minuty, ale nie byłoby to najbardziej eleganckie rozwiązanie.
Nawet jeśli sprawdzam tylko czas podróży w obie strony co 5 minut (aby zaoszczędzić ruch satelitarny), jaki mechanizm wymiany musiałbym skonfigurować, aby sprawdzić względem ostatniego zarejestrowanego RTT, za każdym razem, gdy przesyłany jest komunikat, który trafia do zdalnej dostawy stać w kolejce, a następnie podjąć odpowiednie działania?
Edycja nr 2: Proponowane rozwiązania
Pozwólcie, że podsumuję zaproponowane rozwiązania oraz ich zalety i wady, jakie widzę:
Niestandardowy agent transportowy
Pojęcie
- Okresowo monitoruj opóźnienia, klasyfikuj jako wysokie lub niskie (próg: 400 ms?)
- Za pomocą niestandardowego agenta transportowego zawieszaj / wznawiaj wszystkie wiadomości e-mail większe niż ustawiony próg, gdy zmienia się klasyfikacja opóźnień
- Za pomocą niestandardowej usługi TA natychmiast przełączaj duże przesłane wiadomości w tryb „zawieszenia”, jeśli opóźnienie jest duże
Silne strony
- Duże wiadomości e-mail nigdy nie są dostarczane, gdy opóźnienie jest duże
Słabości
- Brak umiejętności programistycznych do wykonania tego we własnym zakresie (uwaga dla siebie: kod źródłowy powinien należeć do mojej firmy w ramach umowy z zewnętrznym programistą)
- Oprogramowanie innych firm, które łączy się z Exchange, może powodować problemy podczas łatania lub aktualizacji
- Konieczna jest jakaś umowa wsparcia, na wypadek, gdyby coś poszło nie tak (patrz wyżej)
Umiarkowane duże wiadomości
Pojęcie
- Okresowo monitoruj opóźnienia, klasyfikuj jako wysokie lub niskie (próg: 400 ms?)
- W oparciu o klasyfikację opóźnień skonfiguruj Reguły transportu Exchange za pomocą skryptów, aby pozwolić wszystkim wiadomościom na przepływ lub przekazywać duże wiadomości moderatorowi
- Zatwierdzaj wiadomości w kolejce moderatora, gdy statek jest w porcie, być może przez człowieka
Silne strony
- Duże wiadomości e-mail nigdy nie są dostarczane, gdy opóźnienie jest duże
- Wiadomości są zawieszane przy użyciu macierzystych rodzimych reguł transportu Exchange
Słabości
- Wygląda na to, że wiadomości nie można zatwierdzać programowo, gdy opóźnienia są niskie, dlatego wymagana jest interwencja człowieka za każdym razem, gdy statek jest w porcie
- Możliwe problemy z prywatnością, jeśli moderacja nie jest obsługiwana programowo
pytania
- Czy wiadomości można zatwierdzać programowo ze skrzynki moderatora? W jaki sposób?
Zaplanowane polecenia PowerShell
Pojęcie
- Okresowo monitoruj opóźnienia, klasyfikuj jako wysokie lub niskie (próg: 400 ms?)
- Dopóki opóźnienie jest duże, często (co minutę?) Zawieszaj duże wiadomości (
Suspend-Message -Filter {Size -gt 5242880}) - Gdy opóźnienie spadnie do niskiego poziomu, wznów wszystkie wiadomości (
Resume-Message)
Silne strony
- Bardzo prosty do wdrożenia
Słabości
- Nie najbardziej eleganckie rozwiązanie
- Można próbować dostarczyć każdą nową dużą wiadomość tak długo, jak długo trwa przerwa między
Suspend-Messagepoleceniami, prawdopodobnie nadal marnując część przepustowości i powodując przeciążenia (choć bardzo krótko w porównaniu z brakiem działania)
pytania
- Jakieś pomysły na to, jak zapobiegać próbom dostarczania dużych wiadomości pomiędzy
Suspend-Messagepoleceniami? - Czy będą
Get-Messagezwracać tylko wiadomości z kolejek dostarczania zdalnego - nigdy wiadomości do dostarczenia wewnątrz serwera? Jeśli nie, to czy nazwa tożsamości kolejek dostarczania zdalnego jest zgodna z określonym wzorcem, którego można użyć do filtrowania?
Edycja nr 3: Droga naprzód
Po przedstawieniu proponowanych rozwiązań w moim zespole (w tym proxy SMTP, którego nie uwzględniłem w edycji nr 2) i na podstawie własnych odczuć zdecydowaliśmy się na niestandardowego agenta transportu.
Jestem w kontakcie z kilkoma firmami konsultingowymi, które skontaktują się ze mną, w jaki sposób zaatakują problem i jakie będą jego koszty.
Jeśli masz jakieś doświadczenie w programowaniu zadań outsourcingowych, nie wahaj się napisać opinii na moje powiązane pytanie dotyczące przepełnienia stosu , ponieważ ja nie.