fragen stichworte

Planen Sie große E-Mails in der Warteschlange, und warten Sie in die Warteschlange, um die Wartezeit zu verringern

Meine Herausforderung

Wir haben Exchange-Server an verschiedenen Standorten, aber auch an Bord von Schiffen. Die Schiffe sind auf See über Satellitenverbindungen mit dem Netzwerk verbunden, wechseln jedoch im Hafen zu WLAN-Brücken.

Aufgrund der hohen Latenz (mehr als 500 ms) und ungewöhnlicher Ausfälle (z. B. wenn sich die Schiffe wenden) kann der Versuch, E-Mails über einige Megabytes auf See zu versenden, wahrscheinlich fehlschlagen und erneut versucht werden bis das Limit erreicht ist. Das Ergebnis: Die E-Mail wird nicht zugestellt und jeder Versuch verbraucht wertvolle Bandbreite für den Sat-Link.

Eine "Lösung" besteht darin, die maximale E-Mail-Größe auf 5 MB zu beschränken. Dies ist jedoch wenig benutzerfreundlich und eine unnötige Einschränkung im Port.

Grobe Idee

Was ich lieber tun möchte, ist, alle E-Mails in die Warteschlange zu setzen, die größer als ein festgelegter Grenzwert für die spätere Zustellung auf See sind, während alle kleinen E-Mails sofort verschickt werden. Ich dachte dann, ich würde regelmäßig an den Hub-Transport-Server in unserem Rechenzentrum pingen. Wenn die Latenz unter 400 ms sinkt, würde ich die Verarbeitung der großen E-Mail-Warteschlange beginnen. Wenn die Latenzzeit mehr als 400 ms beträgt, würde ich die Lücke verstopfen und die E-Mails erneut in die Warteschlange stellen.

Nun habe ich mich mit Exchange seit Version 2003 nicht wirklich schmutzig gemacht. Damals konnten Sie große E-Mails für die spätere Zustellung einplanen. Daher hatte ich die Idee, etwas Ähnliches in Exchange 2010 zu tun, und dann ein Skript Wechseln Sie den Zustellungsplan für große E-Mails zwischen "immer" und "nie".

Hindernis

Es sollte nicht zu kompliziert sein, ein solches Skript zu erstellen, aber dann habe ich gelesen, dass die Funktion, auf die ich mich verlasse, mit Exchange 2007 entfernt wurde:

This was a feature present in Exchange 2003 but has been removed for Exchange 2007. It was set on an SMTP Connector with the 'use different delivery times for oversize messages'.

TechCenter: Kann die E-Mail-Zustellung nach Größe in Exchange geplant werden?

Fragen

Stimmt es? - Ist diese Funktion in Exchange 2010 nicht mehr vorhanden, oder hat sie sich lediglich in etwas ähnliches verwandelt, das ich verwenden kann, um mein Ziel zu erreichen? Wenn ja, was?

Gibt es eine andere Möglichkeit, die Zustellung großer E-Mails auf bestimmten Exchange-Servern zu verschieben? Es könnte sich um einen Zeitplan handeln oder vielleicht sogar eine bestimmte Aktion erfordern. Ich bin ziemlich sicher, dass es eine Möglichkeit gibt, die Übermittlung durch ein Skript auszulösen. Ich brauche nur große E-Mails in einer separaten Warteschlange auf Schiffen.

Ihre Gedanken dazu werden sehr geschätzt! :-)

Bearbeiten Sie # 1: Verfeinerte grobe Idee

Ich bin über zwei PowerShell-CmdLets gestolpert, von denen ich denke, dass sie mich meinem Ziel ziemlich nahe bringen können:

Ich habe eine Weile mit Get-Message gespielt, um zu sehen, mit welchen Nachrichten sich die obigen Befehle befassen würden.

Diese Befehle akzeptieren vor allem einen Filter für die Nachrichtengröße. Dieser Befehl listet Nachrichten auf dem aktuellen Server in der Warteschlange auf, die größer als 5 MB (5.242.880 Byte) sind:

get-message -Filter {Size -gt 5242880}

Es scheint, dass Get-Message nur Nachrichten aus verschiedenen Remote Delivery-Warteschlangen zurückgibt. Aber erscheinen Nachrichten, die innerhalb des Servers fließen, jedoch nur kurz in einer Warteschlange, mit der sich Get/Suspend/Resume-Message verwirrt?

Wenn dies nicht der Fall ist, könnte die Lösung alle paar Minuten so simpel wie ein geplantes Skript sein, etwa wie folgt (im Pseudocode):

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

Anliegen/Folgefragen:

Jetzt weitgehend irrelevant - siehe Bearbeiten # 2.

Gibt Get-Message nur Nachrichten aus Remote Delivery-Warteschlangen zurück - niemals Nachrichten für die Intra-Server-Zustellung? Wenn nicht, folgt der Identitätsname von Remote Delivery-Warteschlangen einem bestimmten Muster, das ich zum Filtern verwenden kann?

Könnte/sollte dies über einen benutzerdefinierten Transport Agent (wie von @longneck vorgeschlagen) oder über eine Ereignissenke (falls dieses Konzept in Exchange 2010 noch vorhanden ist) erfolgen?

Angenommen, ich führe das Skript alle 5 Minuten aus. Das bedeutet, dass immer noch große Nachrichten gesendet werden. Dies kann bis zu 5 Minuten lang Probleme verursachen, bevor es ausgesetzt wird. Es geht uns immer noch besser als heute, aber es ist nicht optimal. Ich könnte die Frequenz auf jede Minute erhöhen, aber es wäre nicht die eleganteste Lösung.

Selbst wenn ich nur alle 5 Minuten die Roundtrip-Zeit prüfe (um den Datenverkehr zu sparen), welchen Exchange-Mechanismus müsste ich einrichten, um die letzte aufgezeichnete RTT zu überprüfen, und zwar immer dann, wenn eine Nachricht gesendet wird, an die gesendet wird eine Remote-Zustellungswarteschlange und dann entsprechende Maßnahmen ergreifen?

Bearbeiten Sie # 2: Lösungsvorschläge

Lassen Sie mich die vorgeschlagenen Lösungen und ihre Vor- und Nachteile so zusammenfassen, wie ich es sehe:

Benutzerdefinierter Transport-Agent

Konzept

  • Periodische Überwachung der Latenz, Klassifizierung als hoch oder niedrig (Schwellenwert: 400 ms?)
  • Mit einem benutzerdefinierten Transport-Agent können Sie alle E-Mails, die einen festgelegten Schwellenwert überschreiten, unterbrechen/fortsetzen, wenn sich die Latenzklassifizierung ändert.
  • Setzen Sie anschließend die übergebenen großen Nachrichten sofort in den "Suspend" -Modus, wenn die Latenz hoch ist.

Stärken

  • Es wird niemals versucht, große E-Mails zuzustellen, wenn die Latenz hoch ist.

Schwächen

  • Keine internen Entwicklungsfähigkeiten (interner Hinweis: Eigener Quellcode sollte im Rahmen des Vertrags mit dem externen Entwickler zu meinem Unternehmen gehören).
  • Drittanbieter-Software, die an Exchange gebunden ist, kann Probleme beim Patchen oder Aktualisieren verursachen.
  • Es ist eine Art Support-Vereinbarung erforderlich, falls etwas schief geht (siehe oben).

Moderate Large Messages

Konzept

  • Periodische Überwachung der Latenz, Klassifizierung als hoch oder niedrig (Schwellenwert: 400 ms?)
  • Konfigurieren Sie die Exchange-Transportregeln auf der Grundlage der Latenzklassifizierung durch Skripting, um entweder alle Nachrichten fließen zu lassen oder umfangreiche Nachrichten an den Moderator weiterzuleiten.
  • Genehmigen Sie Nachrichten in der Moderatorwarteschlange, wenn sich das Schiff im Hafen befindet, möglicherweise von einem Menschen

Stärken

  • Es wird niemals versucht, große E-Mails zuzustellen, wenn die Latenz hoch ist.
  • Nachrichten werden mithilfe systemeigener Exchange-Transportregeln ausgesetzt

Schwächen

  • Wie es aussieht, können Nachrichten nicht programmgesteuert genehmigt werden, wenn die Latenz niedrig ist. Daher ist jedes Mal, wenn sich ein Schiff im Hafen befindet, ein menschlicher Eingriff erforderlich
  • Möglicherweise Probleme mit dem Datenschutz, wenn die Moderation nicht programmgesteuert erfolgt

Fragen

  • Können Nachrichten vom Moderatorpostfach aus programmgesteuert genehmigt werden? Wie?

Geplante PowerShell-Befehle

Konzept

  • Periodische Überwachung der Latenz, Klassifizierung als hoch oder niedrig (Schwellenwert: 400 ms?)
  • Solange die Latenz hoch ist, setzen große (jede Minute?) große Nachrichten (Suspend-Message -Filter {Size -gt 5242880})
  • aus
  • Wenn die Latenzzeit zu niedrig ist, setzen Sie alle Nachrichten fort (Resume-Message)

Stärken

  • Sehr einfach zu implementieren

Schwächen

  • Nicht die eleganteste Lösung
  • Die Zustellung jeder neuen großen Nachricht kann so lange versucht werden, wie das Intervall zwischen den Suspend-Message -Befehlen erforderlich ist, wobei möglicherweise noch etwas Bandbreite verschwendet wird und es zu Überlastungen kommt (wenn auch sehr kurz im Vergleich zu nichts unternommen wird)

Fragen

  • Ideen zur Verhinderung von Versuchen, große Nachrichten zu übermitteln, zwischen Suspend-Message -Befehlen?
  • Gibt Get-Message nur Nachrichten aus Remote Delivery-Warteschlangen zurück - niemals Nachrichten für die Intra-Server-Zustellung? Wenn nicht, folgt der Identitätsname von Remote Delivery-Warteschlangen einem bestimmten Muster, das ich zum Filtern verwenden kann?

Bearbeiten Sie # 3: Der Weg nach vorne

Nachdem wir die vorgeschlagenen Lösungen in meinem Team (einschließlich des SMTP-Proxys, den ich nicht in die Bearbeitung Nr. 2 aufgenommen hatte) zusammengestellt haben, und aufgrund meines eigenen Bauchgefühls entschieden wir uns für einen benutzerdefinierten Exchange-Transport-Agenten.

Ich stehe in Kontakt mit einigen Beratungsunternehmen, die sich mit mir in Verbindung setzen werden, wie das Problem angegangen wird und was es kosten würde.

Wenn Sie Erfahrung mit dem Outsourcing von Programmieraufgaben haben, können Sie mir gerne meine auf verwandte Frage zum Stack Overflow mitteilen, da ich dies nicht tun kann.

antworten

Nachrichtenmoderation

Eine wahrscheinlich nicht ideale Lösung ist die Verwendung einer Transportregel, um Nachrichten mit einer bestimmten Größe an den Manager des Absenders oder ein angegebenes Postfach (auf dem Exchange-Server des Schiffs) zur Moderation weiterzuleiten. Auf diese Weise können große Nachrichten im Wesentlichen in einer anderen Mailbox in die Warteschlange gestellt werden, wenn sie sich auf See befinden. Wenn das Schiff im Hafen ankommt, kann der Manager oder der designierte Moderator sie für die Lieferung genehmigen.

Die Nachteile sind:

  • Diese Regel ist immer aktiviert, sofern Sie sie nicht manuell deaktivieren (dies könnte jedoch über ein Skript geschehen), sodass auch große Nachrichten an einem Port an das Moderatorpostfach weitergeleitet werden
  • Für alle großen Nachrichten ist vor dem Senden eine manuelle Überprüfung durch eine Person erforderlich. Sie können jedoch Ausnahmen für bestimmte Dinge in der Regel hinzufügen.
  • Eine andere Person liest ausgehende E-Mails, was aus Datenschutzgründen möglicherweise nicht ideal ist. Dies hängt jedoch von Ihrer Organisation ab.

Ein Vorteil ist, dass Sie einen Menschen entscheiden müssen, ob eine Nachricht überhaupt gesendet werden soll oder nicht, beispielsweise ob ein Benutzer versucht hat, eine Menge nicht-arbeitsbezogenem Mist zu senden, der die Verbindung ohne Grund blockiert . Sie können durch administrative Kontrollen korrigiert werden, z. B. auf eine Richtlinie zeigen und diese auf das Handgelenk schlagen, damit sie dies nicht noch einmal tun.

Exchange 2010-Transportregeln

Benutzerdefiniertes Skript

RE: Ein benutzerdefiniertes Skript zum Verwalten großer E-Mails. Ich könnte etwas wie das Folgende sehen, das Ihren Sendeconnector auf dem Exchange-Server aktivieren/deaktivieren würde. Ein Nachteil ist, dass alle E-Mails in der Warteschlange gespeichert werden, anstatt nur große Nachrichten. Einige Logik in dieser Zeile sollte jedoch funktionieren:

  1. Auf Latenz prüfen. Ist dies der Fall, aktivieren Sie den Sendeconnector, entfernen Sie keine großen Nachrichten und warten Sie 5 Minuten (oder eine andere beliebige Zeitspanne). Wenn es hoch ist, deaktivieren Sie den Sendeconnector.
  2. Warten Sie 5 Minuten.
  3. Prüfen Sie nach 5 Minuten, ob große Nachrichten vorhanden sind, und setzen Sie sie aus. Aktivieren Sie den Sendeconnector erneut, damit kleine, in der Warteschlange befindliche Nachrichten freigegeben werden, bis die Warteschlange leer ist (Sie können sogar 1 Nachricht gleichzeitig durchlaufen, um die Warteschlangen-/WAN-Verbindung nach dem erneuten Aktivieren des Sendeconnectors nicht zu blockieren)
  4. Deaktivieren Sie den Sendeconnector und gehen Sie zu # 1

Diese Logik ist nicht 100% sinnvoll, aber Sie haben die Idee, alle E-Mails in die Warteschlange zu stellen, auf Latenz zu prüfen, große Nachrichten auszusetzen, wenn sie zu hoch sind, E-Mails in die Warteschlange zu stellen, alle E-Mails in die Warteschlange zu stellen usw. Der Nachteil eines solchen Skripts ist, wenn es jemals abstürzt oder abbricht. Woher wissen Sie, dass Sie es ohne IT-Personal an Bord der Schiffe neu initialisieren sollten? Es könnte entweder alle ausgehenden Nachrichten auf unbestimmte Zeit stoppen (wenn sie nach dem Deaktivieren des Sendeconnectors angehalten wird), oder Sie könnten die Kontrolle über umfangreiche Nachrichten verlieren, wenn der Sendeconnector nur aktiviert bleibt und das Skript nicht mehr ausgeführt wird.

SMTP-Proxy

Auch wenn Sie angegeben haben, dass Sie sich gegen die Bearbeitung von Nachrichten außerhalb von Exchange aussprechen, habe ich mich entschlossen, bei @longneck einige Arten von SMTP-Proxy-Lösungen zu verwenden. Sogar IIS SMTP verfügt über einen verzögerten Übermittlungsmechanismus, den es bei Exchange 2010 nicht zu geben scheint. Sie können große Nachrichten an den IIS-SMTP-Server umleiten, der sie auf der Festplatte speichern könnte. Wenn Sie zuerst die Latenz überprüfen, wird der IIS-SMTP-Server sie über ein Skript senden, wenn die Latenzzeit niedrig ist. Der schlimmste Fall, wenn Ihr Planungsmechanismus stecken geblieben oder gestoppt wurde, wäre, dass die großen Nachrichten auf der Festplatte hängen bleiben, aber kleine Nachrichten weiterhin gesendet werden. Es gibt wahrscheinlich bessere Lösungen als IIS SMTP, und ich habe es selbst nie verwendet, aber es ist nur ein Beispiel.

Konfigurieren Sie SMTP-E-Mail in IIS 7

Sehen Sie sich die neuen Funktionen von "Message Throttling" an, die mit Exchange 2010 SP1 eingeführt wurden. Es könnte sehr hilfreich für Ihren Anwendungsfall sein.

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

Um das Problem so zu lösen, wie Sie es angefordert haben, könnten Sie Ihren eigenen Transport-Agent mit dem Microsoft Exchange-Transport-Agent-SDK schreiben. Transport Agents sind ereignisbasiert, sodass Exchange eine Funktion in Ihrer Bibliothek aufruft, wenn eine Nachricht empfangen wird. Ihre Bibliothek kann dann etwas tun, wie die Nachricht zu halten. Wenn Sie nicht die Fähigkeiten dazu haben, können Sie einen Entwickler beauftragen, es für Sie zu schreiben.

Aber ich denke nicht, dass dies eine großartige Lösung ist. Als eine Alternative, die Sie untersuchen sollten, möchten Sie vielleicht nach einem SMTP-Proxy für Links mit niedriger Qualität suchen. Wie Sie festgestellt haben, ist SMTP ein schreckliches Protokoll für Links mit niedriger Qualität, da eine unterbrochene Verbindung dazu führt, dass die Nachrichtenübertragung von Anfang an neu gestartet wird, anstatt von dort weiterzumachen, wo sie unterbrochen wurde. Wenn Sie einen Entwickler für etwas beauftragen, würde ich in Betracht ziehen, ein Serverprogramm zu schreiben, das eingehende SMTP-Verbindungen akzeptiert und die Nachricht auf fortlaufende Weise an eine entfernte Instanz dieses Programms am anderen Ende der Satellitenverbindung sendet ( Möglicherweise trennen Sie die großen Nachrichten von den kleinen Nachrichten über den TCP-Port, um eine QoS-Behandlung durch Ihren WAN-Beschleuniger zu ermöglichen. Die entfernte Instanz könnte dann nach dem Empfang der vollständigen Nachricht die Zustellung der Nachricht über SMTP abschließen.