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.
źródło
Odpowiedzi:
Aby rozwiązać problem zgodnie z żądaniem, możesz napisać własnego agenta transportowego za pomocą zestawu SDK programu transportowego Microsoft Exchange . Agenty transportu są oparte na zdarzeniach, więc Exchange odbierze funkcję w bibliotece po otrzymaniu wiadomości. Twoja biblioteka może wtedy zrobić coś takiego, jak wstrzymanie wiadomości. Jeśli nie masz umiejętności, aby to zrobić, jestem pewien, że możesz zatrudnić programistę, który napisze to dla Ciebie.
Ale nie sądzę, że to świetne rozwiązanie. Jako alternatywę do zbadania, możesz zajrzeć do czegoś w rodzaju proxy SMTP dla łączy niskiej jakości. Jak odkryłeś, SMTP jest okropnym protokołem dla łączy niskiej jakości, ponieważ przerwane połączenie powoduje, że transmisja wiadomości rozpoczyna się od początku, zamiast wznawiać od miejsca, w którym została przerwana. Jeśli zamierzasz wynająć programistę na coś, rozważę napisanie programu serwera, który akceptuje przychodzące połączenia SMTP i wysyła wiadomość do zdalnej instancji tego samego programu na drugim końcu połączenia satelitarnego w sposób umożliwiający wznowienie ( możliwe oddzielenie dużych wiadomości od małych wiadomości przez port TCP, aby umożliwić obsługę QoS przez twój akcelerator WAN). Zdalna instancja może wtedy, po otrzymaniu pełnej wiadomości,
źródło
Moderacja wiadomości
Jednym prawdopodobnie prawdopodobnie nie idealnym rozwiązaniem jest użycie reguły transportu do przekazywania wiadomości o określonym rozmiarze do menedżera nadawcy lub do wyznaczonej skrzynki pocztowej (na serwerze Exchange statku) w celu moderacji. W ten sposób, jeśli są na morzu, duże wiadomości mogą być zasadniczo umieszczone w kolejce w innej skrzynce pocztowej. Kiedy statek przybywa do portu, kierownik lub wyznaczony moderator może zatwierdzić go do dostawy.
Minusy to:
Jedną zaletą jest to, że człowiek decyduje o tym, czy wiadomość powinna zostać nawet wysłana, na przykład, jeśli użytkownik próbował wysłać kilka bzdur niezwiązanych z pracą, które po prostu zawiodłyby połączenie bez powodu. Można je poprawić za pomocą kontroli administracyjnych, takich jak wskazywanie polityki i klepanie ich w nadgarstek, aby nie robili tego ponownie.
Zasady transportu Exchange 2010
Skrypt niestandardowy
RE: Niestandardowy skrypt do zarządzania dużymi wiadomościami e-mail. Widziałem coś takiego poniżej, które włącza / wyłącza twój Send Connector na serwerze Exchange. Minusem jest to, że cała poczta jest przechowywana w kolejce zamiast tylko dużych wiadomości, ale pewna logika wzdłuż tych linii powinna działać:
Ta logika nie jest w pełni dopracowana, aby mieć 100% sensu, ale masz pomysł - ustaw kolejkę całej poczty, sprawdź opóźnienie, zawieszaj duże wiadomości, jeśli jest wysoka, cofnij kolejkę, ustaw kolejkę całej poczty itp. Kolejny minus działania taki skrypt jest taki, że jeśli się zawiesi lub przestanie działać, skąd miałbyś go zainicjować bez personelu IT na pokładzie? Może to potencjalnie zatrzymać całą pocztę wychodzącą na czas nieokreślony (jeśli zatrzyma się po wyłączeniu Send Connector) lub możesz stracić kontrolę nad dużymi wiadomościami, jeśli tylko pozostawi Send Send włączony i skrypt nie będzie już działał.
Serwer proxy SMTP
Mimo że zasugerowałeś, że jesteś przeciwny obsłudze wiadomości poza Exchange, zastanowiłem się nad tym trochę, zdecydowałem, że jestem przy @longneck w sprawie korzystania z pewnego rodzaju rozwiązania proxy SMTP. Nawet IIS SMTP ma odroczony mechanizm dostarczania, który wydaje się, że nie ma Exchange 2010. Można przekierowywać duże wiadomości do serwera SMTP usług IIS, który może przechowywać je na dysku, a najpierw sprawdzając opóźnienie, serwer SMTP usług IIS wysyła je za pomocą skryptu, gdy opóźnienie jest niskie. Najgorszym przypadkiem, jeśli twój mechanizm planowania utknąłby lub został zatrzymany, duże wiadomości utknęłyby na dysku, ale małe wiadomości są nadal wysyłane. Prawdopodobnie istnieją lepsze rozwiązania niż IIS SMTP i sam nigdy z nich nie korzystałem, ale to tylko przykład.
Skonfiguruj wiadomość e-mail SMTP w IIS 7
źródło
Spróbuj zapoznać się z nowymi funkcjami „Ograniczania wiadomości” wprowadzonymi wraz z Exchange 2010 SP1. Może to być bardzo pomocne w twoim przypadku użycia.
http://technet.microsoft.com/en-us/library/bb232205(v=exchg.141).aspx
źródło