Pianificare / mettere in coda e-mail di grandi dimensioni in Exchange 2010, rimandare fino alla caduta della latenza


14

La mia sfida

Abbiamo server Exchange in vari siti, ma anche a bordo di navi. Le navi sono collegate alla nostra rete tramite collegamenti satellitari quando sono in mare, ma passano ai ponti WiFi quando sono in porto.

A causa dell'elevata latenza (500+ ms) e di abbandoni non insoliti (ad esempio quando le navi stanno girando), il tentativo di inviare e-mail al di sopra di qualche megabyte in mare, è probabile che fallisca e venga ripetuto fino al limite è stato raggiunto. Il risultato: l'e-mail non viene recapitata e ogni tentativo consuma preziosa larghezza di banda sul collegamento satellitare.

Una "soluzione" è limitare la dimensione massima dell'e-mail a 5 MB, ma è difficile da usare e una restrizione non necessaria mentre si è in porto.

Vaga idea

Quello che preferirei fare è mettere in coda tutte le e-mail più grandi di un limite prestabilito per la successiva consegna in mare, mentre si inviano immediatamente tutte le piccole e-mail. Pensavo quindi di eseguire regolarmente il ping del server di trasporto hub nel nostro datacenter, quando la latenza scende sotto ~ 400 ms, inizierei a elaborare la grande coda di e-mail. Quando la latenza sale oltre i 400 ms, tapperei il buco e avrei lasciato le e-mail in coda di nuovo.

Ora, non mi sono sporcato le mani con Exchange dalla versione 2003. All'epoca, potevi pianificare grandi e-mail per la consegna successiva, quindi la mia idea era fare qualcosa di simile in Exchange 2010, quindi scrivere un modo per cambiare la consegna programma per e-mail di grandi dimensioni tra 'sempre' e 'mai'.

Ostacolo

Non dovrebbe essere troppo complicato creare uno script del genere, ma poi ho letto che la funzionalità su cui fare affidamento è stata rimossa con Exchange 2007:

Questa era una funzionalità presente in Exchange 2003 ma è stata rimossa per Exchange 2007. È stata impostata su un connettore SMTP con "utilizzare tempi di consegna diversi per i messaggi di grandi dimensioni".

TechCenter: è possibile pianificare il recapito della posta elettronica in base alle dimensioni in Exchange?

Domande

È vero? - Questa funzionalità non è più presente in Exchange 2010 o si è semplicemente trasformata in qualcosa di simile che posso usare per raggiungere il mio obiettivo? E quindi?

Esiste un altro modo per rinviare la consegna di e-mail di grandi dimensioni su determinati server Exchange? Potrebbe essere basato su un programma o forse anche richiedere un'azione specifica - Sono abbastanza certo che ci sarà un modo per innescare la consegna tramite script, ho solo bisogno di grandi e-mail in una coda separata sulle navi.

I tuoi pensieri su questo saranno molto apprezzati! :-)

Modifica n. 1: raffinata idea approssimativa

Mi sono imbattuto in due CmdLets di PowerShell che penso mi possano avvicinare abbastanza al mio obiettivo:

Ho giocato con Get-Message per un po ', per vedere che tipo di messaggi avrebbero gestito i comandi sopra.

Ancora più importante, questi comandi accettano un filtro dimensioni messaggio. Questo comando elencherà i messaggi in coda, sul server corrente, maggiori di 5 MB (5.242.880 byte):

get-message -Filter {Size -gt 5242880}

Sembra Get-Messageche restituisca solo messaggi da varie code di recapito remoto. Ma i messaggi che scorrono all'interno del server, per quanto brevemente, vengono visualizzati in una coda con cui Get / Suspend / Resume-Message avrà problemi?

In caso contrario, la soluzione potrebbe essere semplice come uno script programmato ogni pochi minuti, sulla falsariga di (in pseudo codice):

if ping_rtt > 400 Then
    Suspend-Message -Filter {Size -gt 5242880}
Else
    Resume-Message
EndIf

Preoccupazioni / domande di follow-up:

Per lo più irrelvant ora - vedi modifica # 2.

Sarà Get-Messagerestituire solo i messaggi da code di recapito remote - mai messaggi per il recapito intra-server? In caso contrario, il nome dell'identità delle code di recapito remoto segue un determinato modello, che posso utilizzare per il filtro?

Potrebbe / dovrebbe essere fatto tramite un agente di trasporto personalizzato (come suggerito da @longneck) o un sink di evento (se questo concetto esiste ancora in Exchange 2010)?

Supponiamo che eseguo lo script ogni 5 minuti, il che significa che vengono inviati messaggi di grandi dimensioni, possono potenzialmente causare problemi fino a 5 minuti, prima di essere sospesi. Staremmo ancora meglio di adesso, ma non è ottimale. Potrei aumentare la frequenza ad ogni minuto, ma non sarebbe la soluzione più elegante.

Anche se controllo solo il tempo di andata e ritorno ogni 5 minuti (per salvare il traffico satellitare), quale meccanismo di Exchange dovrei impostare, per verificare con l'ultimo RTT registrato, ogni volta che viene inviato un messaggio che arriva a una consegna remota fare la coda, e quindi intraprendere azioni appropriate?

Modifica n. 2: soluzioni proposte

Consentitemi di riassumere le soluzioni proposte e i loro pro e contro a mio avviso:

Agente di trasporto personalizzato

Concetto

  • Monitorare periodicamente la latenza, classificarla come alta o bassa (soglia: 400 ms?)
  • Tramite un agente di trasporto personalizzato, sospendere / riprendere tutte le e-mail superiori a una soglia impostata, quando cambia la classificazione della latenza
  • Tramite l'AT personalizzato, metti immediatamente i messaggi di grandi dimensioni inviati successivamente in modalità "sospendi", se la latenza è elevata

Punti di forza

  • Le e-mail di grandi dimensioni non vengono mai tentate di recapitare quando la latenza è elevata

Punti di debolezza

  • Nessuna capacità di sviluppo per renderlo interno (nota per sé: il codice sorgente dovrebbe appartenere alla mia azienda come parte del contratto con lo sviluppatore esterno)
  • Il software di terze parti collegato a Exchange può causare problemi durante l'applicazione di patch o l'aggiornamento
  • È necessaria una sorta di accordo di supporto, nel caso in cui qualcosa vada storto (vedi sopra)

Moderati messaggi di grandi dimensioni

Concetto

  • Monitorare periodicamente la latenza, classificarla come alta o bassa (soglia: 400 ms?)
  • In base alla classificazione della latenza, configura le regole di trasporto di Exchange tramite script, per consentire a tutti i messaggi di fluire o inoltrare messaggi di grandi dimensioni al moderatore
  • Approvare i messaggi nella coda del moderatore quando la nave è in porto, possibilmente da un essere umano

Punti di forza

  • Le e-mail di grandi dimensioni non vengono mai tentate di recapitare quando la latenza è elevata
  • I messaggi vengono sospesi utilizzando le regole di trasporto native di Exchange

Punti di debolezza

  • A quanto pare, i messaggi non possono essere approvati a livello di codice quando la latenza è bassa, quindi è necessario l'intervento umano ogni volta che la nave è in porto
  • Eventuali problemi di privacy, se la moderazione non viene gestita a livello di codice

Domande

  • I messaggi possono essere approvati a livello di codice dalla cassetta postale del moderatore? Come?

Comandi PowerShell pianificati

Concetto

  • Monitorare periodicamente la latenza, classificarla come alta o bassa (soglia: 400 ms?)
  • Finché la latenza è alta, frequentemente (ogni minuto?) Sospende i messaggi di grandi dimensioni ( Suspend-Message -Filter {Size -gt 5242880})
  • Quando la latenza scende al minimo, riprendi tutti i messaggi ( Resume-Message)

Punti di forza

  • Molto semplice da implementare

Punti di debolezza

  • Non è la soluzione più elegante
  • La consegna di ogni nuovo messaggio di grandi dimensioni può essere tentata fino a quando l'intervallo tra i Suspend-Messagecomandi, probabilmente sprecando ancora un po 'di larghezza di banda e creando congestioni (anche se molto brevemente rispetto al non fare nulla)

Domande

  • Qualche idea su come prevenire i tentativi di recapitare messaggi di grandi dimensioni, tra Suspend-Messagecomandi?
  • Sarà Get-Messagerestituire solo i messaggi da code di recapito remote - mai messaggi per il recapito intra-server? In caso contrario, il nome dell'identità delle code di recapito remoto segue un determinato modello, che posso utilizzare per il filtro?

Modifica n. 3: The Way Forward

Dopo aver introdotto le soluzioni proposte nel mio team (incluso il proxy SMTP, che non sono riuscito a includere nella modifica n. 2) e in base al mio intuito, abbiamo deciso di optare per un agente di trasporto di Exchange personalizzato.

Sono in contatto con un paio di società di consulenza, che mi risponderanno su come la volontà attaccherà il problema e quanto costerebbe.

Se hai esperienza con le attività di programmazione in outsourcing, sentiti libero di lasciare un feedback alla mia domanda correlata su Stack Overflow , perché io no.


3
+1 per una delle domande migliori che ho visto di recente.
John Gardeniers,

quali ruoli ricoprono i server Exchange sulle navi?
Agosto

I server Exchange sulle navi detengono i ruoli Trasporto Hub, Cassette postali e Accesso client.
abstrask

1
stai eseguendo qualsiasi tipo di ottimizzatore QoS o WAN sui collegamenti satellitari?
collo lungo

Hmm con il ruolo Mailbox, potresti anche avere il link saturato quando la posta esterna viene inviata a una mailbox di qualcuno sul server Exchange della nave ...
mese di agosto

Risposte:


2

Per risolvere il problema nel modo richiesto, è possibile scrivere il proprio agente di trasporto utilizzando l' SDK dell'agente di trasporto di Microsoft Exchange . Gli agenti di trasporto sono basati sugli eventi, quindi Exchange chiamerà una funzione nella libreria quando viene ricevuto un messaggio. La tua libreria può quindi fare qualcosa come tenere il messaggio. Se non hai le competenze interne per farlo, sono sicuro che potresti assumere uno sviluppatore per scriverlo per te.

Ma non penso che sia un'ottima soluzione. In alternativa, per indagare, potresti voler esaminare qualcosa come un proxy SMTP per collegamenti di bassa qualità. Come hai scoperto, SMTP è un protocollo orribile per collegamenti di bassa qualità perché una connessione interrotta fa ricominciare la trasmissione del messaggio dall'inizio invece di riprendere da dove era stata interrotta. Se hai intenzione di assumere uno sviluppatore per qualcosa, prenderei in considerazione la possibilità di scrivere un programma server che accetti connessioni SMTP in entrata e invii il messaggio a un'istanza remota di questo stesso programma all'altra estremità della connessione satellitare in modo riprendibile ( eventualmente separando i messaggi di grandi dimensioni dai piccoli messaggi tramite la porta TCP per consentire il trattamento QoS dall'acceleratore WAN). L'istanza remota potrebbe quindi, al ricevimento del messaggio completo,


Grazie per il tuo contributo! Devo dire che è molto meno immediato di quanto sperassi. Sono un grande fan del principio KISS. Anche se non so molto sulla scrittura di agenti di trasporto, è in qualche modo convincente per me mantenere la gestione all'interno di Exchange. In Exchange 2010, sembra che le code vengano create e distrutte su richiesta. Forse l'agente potrebbe forzare i messaggi di grandi dimensioni in una coda separata e uno script può passare tra "sospendi" e "riprendi". Qualche idea è che è il tipo di cosa che puoi fare con le TA in Exchange 2010?
abstrask

Per quanto riguarda il suggerimento proxy SMTP / smarthost, suona anche come una soluzione OK, se riesco a trovare una soluzione standard, preferibilmente mantenuta attivamente. Sembra essere un'attività di programmazione più grande e complessa di un agente di trasporto di Exchange, che modifica il flusso all'interno di Exchange (potrei sbagliarmi?). È la mia esperienza che soluzioni complesse e personalizzate, come immagino sarebbe un proxy SMTP, tende a essere costosa da supportare a lungo termine.
abstrask

ri: code separate, non ho abbastanza familiarità con gli interni di Exchange per sapere se le code funzionano in questo modo o se è il modo migliore. so che i singoli messaggi possono essere trattenuti da un TA per l'elaborazione in base alla mia esperienza con Litera Metadact-e, che fa esattamente questo: tenere un messaggio fino al termine dell'elaborazione (che può richiedere molti minuti). non so se è possibile tenerli indefinitamente.
collo lungo

il mio punto generale della mia risposta è che dovresti probabilmente consultare uno sviluppatore in quanto non esiste una soluzione pronta all'uso per te. tuttavia, questo è un problema piuttosto semplice e assumere uno sviluppatore per risolvere questo problema per te probabilmente non è un costo proibitivo.
collo lungo

L'esistenza del CmdLet PowerShell Suspend-Message è stata convinta che anche lo stato di consegna dei messaggi può essere modificato a livello di codice. Mi piace l'idea di un agente di trasporto personalizzato, che modifichi semplicemente lo stato di consegna del messaggio, su un proxy SMTP separato, poiché saremo ancora in grado di mantenere tutto il monitoraggio dei messaggi, la delega dei diritti di amministratore ecc. In Exchange. Grazie per il tuo contributo!
abstrask

3

Moderazione del messaggio

Una soluzione probabilmente non ideale è quella di utilizzare una regola di trasporto per inoltrare messaggi di una certa dimensione al gestore del mittente o a una cassetta postale designata (sul server Exchange della nave) per la moderazione. In questo modo, se sono in mare, i messaggi di grandi dimensioni possono essere essenzialmente messi in coda in un'altra cassetta postale. Quando la nave arriva in porto, il manager o il moderatore designato può approvarli per la consegna.

Gli svantaggi sono:

  • questa regola è sempre attiva a meno che non venga disabilitata manualmente (ma potrebbe essere eseguita tramite uno script), quindi anche in porta i messaggi di grandi dimensioni reindirizzerebbero alla cassetta postale del moderatore
  • tutti i messaggi di grandi dimensioni dovrebbero essere esaminati manualmente da qualcuno prima di inviarli, ma è possibile aggiungere eccezioni alla regola per cose specifiche
  • un'altra persona leggerebbe la posta in uscita, che potrebbe non essere l'ideale a causa di problemi di privacy, ma questo dipende dalla tua organizzazione

Un aspetto positivo è che si dovrebbe prendere una decisione umana sull'opportunità o meno di inviare un messaggio, come se un utente stesse cercando di inviare un mucchio di merda non legate al lavoro che impantanerebbe la connessione senza motivo. Potrebbero essere corretti da controlli amministrativi come indicare una politica e schiaffeggiarli al polso in modo da non farlo più.

Exchange 2010 Regole di trasporto

Script personalizzato

RE: uno script personalizzato per la gestione di e-mail di grandi dimensioni. Potrei vedere qualcosa di simile al seguente che abiliterebbe / disabiliterebbe il tuo connettore di invio sul server Exchange. Un aspetto negativo è che tutta la posta è tenuta in coda anziché solo messaggi di grandi dimensioni, ma un po 'di logica lungo queste linee dovrebbe funzionare:

  1. Controlla la latenza. Se è basso, abilitare il connettore di invio, non sospendere eventuali messaggi di grandi dimensioni e attendere 5 minuti (o altri periodi di tempo arbitrari). Se è elevato, disabilitare il connettore di invio.
  2. Aspetta 5 minuti.
  3. Dopo 5 minuti, verifica la presenza di messaggi di grandi dimensioni e sospenderli. Riattiva il connettore di invio in modo che i messaggi in coda di piccole dimensioni vengano rilasciati fino a quando la coda non è vuota (potresti persino scorrere 1 messaggio alla volta in modo da non ostruire il collegamento coda / WAN dopo aver riattivato il connettore di invio)
  4. Disabilita il connettore di invio e vai a # 1

Questa logica non è completamente perfezionata per dare un senso al 100%, ma ottieni l'idea: accoda tutta la posta, controlla la latenza, sospendi i messaggi di grandi dimensioni se è alta, posta in coda, metti in coda tutta la posta, ecc. Un altro aspetto negativo dell'esecuzione una sceneggiatura del genere è se si blocca o si interrompe mai, come faresti a reinizializzarla senza personale IT a bordo delle navi? Potrebbe potenzialmente arrestare indefinitamente tutta la posta in uscita (se si interrompe dopo aver disabilitato il connettore di invio) o perdere il controllo dei messaggi di grandi dimensioni se lascia il connettore di invio abilitato e lo script non è più in esecuzione.

Proxy SMTP

Anche se hai indicato di essere contrario a qualsiasi gestione dei messaggi al di fuori di Exchange, dopo averci pensato un po 'di più, ho deciso di utilizzare @longneck sull'utilizzo di un tipo di soluzione proxy SMTP. Anche IIS SMTP ha un meccanismo di consegna differito che sembrerebbe che Exchange 2010 non abbia. È possibile reindirizzare i messaggi di grandi dimensioni al server SMTP IIS che potrebbe archiviarli sul disco e, verificando prima la latenza, fare in modo che il server SMTP IIS li invii tramite uno script quando la latenza è bassa. Il caso peggiore se il meccanismo di pianificazione si è bloccato o arrestato sarebbe che i messaggi di grandi dimensioni si bloccano sul disco, ma i messaggi piccoli continuano a essere inviati. Probabilmente ci sono soluzioni migliori di IIS SMTP e non l'ho mai usato da solo, ma è solo un esempio.

Configurare la posta elettronica SMTP in IIS 7


Grazie per il tuo contributo! Sebbene non sia specificato direttamente, è un requisito per me che le e-mail differite alla fine raggiungano la loro destinazione inalterate. È questo il caso, quando li inoltri per la prima volta a una cassetta postale del moderatore, o lascerà segni nascosti o visibili? Per quanto riguarda il processo manuale di approvazione, penso che questo possa essere scritto in qualche modo?
abstrask

Buona domanda, e poiché non l'ho mai implementato, ho creato una regola di test rapida nella nostra organizzazione di Exchange e ho inviato un'e-mail di prova. Il moderatore ha ricevuto il messaggio con un'opzione 'Approva' o 'Rifiuta'. Una volta approvato il messaggio, è stato rilasciato e inviato alla destinazione inalterato senza alcun segno della cassetta postale del moderatore in nessun punto dell'intestazione del messaggio o del corpo dell'e-mail. Tuttavia, non riesco a trovare nulla sullo scripting del processo di approvazione, quindi potrebbe essere necessario designare un essere umano per questo compito.
Agosto

Grazie mille per l'idea. Penso che la regola possa essere facilmente modificata tramite lo scripting, ma la parte dell'intervento umano è un grosso svantaggio per noi, poiché non abbiamo personale IT dedicato a bordo. Qualcuno sa se i messaggi possono essere approvati a livello di codice e come?
abstrask

2

Prova a dare un'occhiata alle nuove funzionalità di "Message Throttling" introdotte con Exchange 2010 SP1. Potrebbe essere molto utile per il tuo caso d'uso.

http://technet.microsoft.com/en-us/library/bb232205(v=exchg.141).aspx


1
Non sono così sicuro che la limitazione dei messaggi sarebbe di aiuto in questo particolare scenario. Leggendo l'articolo sembra più orientato a impedire che un server di trasporto o Edge venga sopraffatto da una tonnellata di messaggi, quindi applica i costi per fornire un livello di consegna dei messaggi di tipo QoS. In questo caso, tuttavia, un singolo utente che invia un messaggio da 10 MB potrebbe saturare l'intero collegamento WAN, rendendo non disponibili altri servizi. Penso che un meccanismo di consegna differita sarebbe più appropriato.
Agosto

1
Ci dispiace, ma come ho letto, "Messaggio Throttling" sarà solo favorire l'invio di messaggi più piccoli ( per impostazione predefinita, il rapporto normale al più basso messaggio è di 20: 1 ), non impediscono l'invio di messaggi di grandi dimensioni. Hai un suggerimento più specifico su come raggiungere il mio obiettivo? Grazie.
abstrask
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.