Mon défi
Nous avons des serveurs Exchange sur divers sites, mais aussi à bord de navires. Les navires sont connectés à notre réseau via des liaisons par satellite lorsqu'ils sont en mer, mais passent aux ponts WiFi lorsqu'ils sont au port.
En raison de la latence élevée (500+ ms) et des abandons non rares (par exemple lorsque les navires tournent), tenter d'envoyer des e-mails au-dessus de quelques mégaoctets en mer est susceptible d'échouer et d'être réessayé jusqu'à la limite a été atteint. Le résultat: l'e-mail n'est pas livré et chaque essai consomme une bande passante précieuse sur le lien satellite.
Une «solution» consiste à limiter la taille maximale des e-mails à 5 Mo, mais ce n'est guère convivial et une restriction inutile pendant le port.
Idée approximative
Ce que je préférerais faire, c'est mettre en file d'attente tous les e-mails supérieurs à une limite définie pour une livraison ultérieure en mer, tout en envoyant tous les petits e-mails immédiatement. Je pensais alors que je ferais régulièrement une requête ping au serveur de transport concentrateur dans notre centre de données, lorsque la latence tombe en dessous de ~ 400 ms, je commençais à traiter la grande file d'attente des e-mails. Lorsque la latence augmente de plus de 400 ms, je boucherais le trou et laisserais les e-mails faire la queue à nouveau.
Maintenant, je n'ai pas vraiment mis la main sur Exchange depuis la version 2003. À l'époque, vous pouviez planifier de gros e-mails pour une livraison ultérieure, alors mon idée était de faire quelque chose de similaire dans Exchange 2010, puis de créer un script pour changer la livraison. programmez des e-mails volumineux entre «toujours» et «jamais».
Obstacle
Cela ne devrait pas être trop compliqué de créer un script comme ça, mais j'ai lu ensuite que la fonctionnalité sur laquelle je comptais a été supprimée avec Exchange 2007:
Cette fonctionnalité était présente dans Exchange 2003 mais a été supprimée pour Exchange 2007. Elle a été définie sur un connecteur SMTP avec «utiliser des délais de livraison différents pour les messages surdimensionnés».
Des questions
Est-ce vrai? - Cette fonctionnalité n'est-elle plus présente dans Exchange 2010, ou s'est-elle simplement transformée en quelque chose de similaire, que je peux utiliser pour atteindre mon objectif? Si oui, quoi?
Existe-t-il un autre moyen de différer la livraison de gros e-mails sur certains serveurs Exchange? Cela pourrait être basé sur un calendrier ou peut-être même nécessiter une action spécifique - je suis assez certain qu'il y aura un moyen de déclencher la livraison via un script, j'ai juste besoin de gros e-mails dans une file d'attente séparée sur les navires.
Votre opinion à ce sujet sera très appréciée! :-)
Edit # 1: Idée approximative raffinée
Je suis tombé sur deux CmdLets PowerShell qui, je pense, peuvent me rapprocher assez de mon objectif:
J'ai joué avec Get-Message pendant un certain temps, pour voir quel type de messages les commandes ci-dessus traiteraient.
Plus important encore, ces commandes acceptent un filtre de taille de message. Cette commande répertorie les messages en file d'attente, sur le serveur actuel, d'une taille supérieure à 5 Mo (5 242 880 octets):
get-message -Filter {Size -gt 5242880}
Il semble Get-Messageque ne renvoie que les messages de diverses files d'attente de remise à distance. Mais les messages circulant dans le serveur, même brièvement, apparaissent-ils dans une file d'attente avec laquelle Get / Suspend / Resume-Message va jouer?
Sinon, la solution pourrait être aussi simple qu'un script planifié toutes les quelques minutes, dans le sens de (en pseudo code):
if ping_rtt > 400 Then
Suspend-Message -Filter {Size -gt 5242880}
Else
Resume-Message
EndIf
Préoccupations / questions de suivi:
Actuellement peu pertinent - voir la modification n ° 2.
Renvoie Get-Messageuniquement les messages des files d'attente de remise distantes - jamais les messages pour la remise intra-serveur? Sinon, le nom d'identité des files d'attente de remise à distance suit-il un certain schéma que je peux utiliser pour le filtrage?
Cela pourrait-il / devrait-il être fait via un agent de transport personnalisé (comme suggéré par @longneck) ou un récepteur d'événements (si ce concept existe toujours dans Exchange 2010)?
Supposons que j'exécute le script toutes les 5 minutes, ce qui signifie toujours que des messages volumineux sont envoyés, peut potentiellement causer des problèmes jusqu'à 5 minutes avant d'être suspendu. Nous serions encore mieux lotis qu'aujourd'hui, mais ce n'est pas optimal. Je pourrais augmenter la fréquence à chaque minute, mais ce ne serait pas la solution la plus élégante.
Même si je ne vérifie que le temps d'aller-retour toutes les 5 minutes (pour économiser le trafic sat), quel mécanisme d'échange aurais-je besoin de configurer, afin de comparer avec le dernier RTT enregistré, chaque fois qu'un message est envoyé qui va à une livraison à distance file d'attente, puis prendre des mesures appropriées?
Édition n ° 2: Solutions proposées
Permettez-moi de résumer les solutions proposées, ainsi que leurs avantages et inconvénients tels que je les vois:
Agent de transport personnalisé
Concept
- Surveillez périodiquement la latence, classifiez-la comme élevée ou faible (seuil: 400 ms?)
- Grâce à un agent de transport personnalisé, suspendez / reprenez tous les e-mails supérieurs à un seuil défini, lorsque la classification de latence change
- Grâce à l'assistance technique personnalisée, mettez immédiatement les messages volumineux soumis ultérieurement en mode "suspension", si la latence est élevée
Forces
- Les e-mails volumineux ne sont jamais tentés lorsque la latence est élevée
Faiblesses
- Aucune compétence de développement pour faire cela en interne (note à soi-même: le code source doit appartenir à mon entreprise dans le cadre du contrat avec le développeur externe)
- Les logiciels tiers liés à Exchange peuvent provoquer des problèmes lors de l'application de correctifs ou de mises à jour
- Une sorte d'accord de support nécessaire en cas de problème (voir ci-dessus)
Messages modérés volumineux
Concept
- Surveillez périodiquement la latence, classifiez-la comme élevée ou faible (seuil: 400 ms?)
- En fonction de la classification de latence, configurez les règles de transport Exchange via des scripts, pour laisser tous les messages circuler ou transférer des messages volumineux au modérateur
- Approuver les messages dans la file d'attente du modérateur lorsque le navire est dans le port, éventuellement par un humain
Forces
- Les e-mails volumineux ne sont jamais tentés lorsque la latence est élevée
- Les messages sont suspendus à l'aide des règles de transport Exchange natives natives
Faiblesses
- De par son apparence, les messages ne peuvent pas être approuvés par programme lorsque la latence est faible, donc une intervention humaine est requise chaque fois que le navire est dans le port
- Peut-être des problèmes de confidentialité, si la modération n'est pas gérée par programme
Des questions
- Les messages peuvent-ils être approuvés par programme à partir de la boîte aux lettres du modérateur? Comment?
Commandes PowerShell planifiées
Concept
- Surveillez périodiquement la latence, classifiez-la comme élevée ou faible (seuil: 400 ms?)
- Tant que la latence est élevée, suspendez fréquemment (toutes les minutes?) Les gros messages (
Suspend-Message -Filter {Size -gt 5242880}) - Lorsque la latence devient faible, reprenez tous les messages (
Resume-Message)
Forces
- Très simple à mettre en œuvre
Faiblesses
- Pas la solution la plus élégante
- La livraison de chaque nouveau gros message peut être tentée aussi longtemps que l'intervalle entre les
Suspend-Messagecommandes, peut-être encore gaspiller de la bande passante et créer des congestions (bien que très brièvement par rapport à ne rien faire)
Des questions
- Avez-vous des idées sur la façon d'empêcher les tentatives de livraison de gros messages, entre les
Suspend-Messagecommandes? - Renvoie
Get-Messageuniquement les messages des files d'attente de remise distantes - jamais les messages pour la remise intra-serveur? Sinon, le nom d'identité des files d'attente de remise à distance suit-il un certain schéma que je peux utiliser pour le filtrage?
Edit # 3: La voie à suivre
Après avoir apporté les solutions proposées dans mon équipe (y compris le proxy SMTP, que je n'ai pas réussi à inclure dans l'édition n ° 2), et en fonction de mon intuition, nous avons décidé d'opter pour un agent de transport Exchange personnalisé.
Je suis en contact avec quelques sociétés de conseil, qui me répondront comment ils s'attaqueront au problème et ce qu'il en coûterait.
Si vous avez une expérience avec l'externalisation des tâches de programmation, n'hésitez pas à laisser des commentaires sur ma question connexe sur Stack Overflow , car je n'en ai pas.