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.
la source
Réponses:
Pour résoudre le problème comme vous l'avez demandé, vous pouvez écrire votre propre agent de transport à l'aide du SDK de l'agent de transport Microsoft Exchange . Les agents de transport sont basés sur des événements, donc Exchange appellera une fonction dans votre bibliothèque lorsqu'un message est reçu. Votre bibliothèque peut alors faire quelque chose comme retenir le message. Si vous n'avez pas les compétences en interne pour le faire, je suis sûr que vous pourriez embaucher un développeur pour l'écrire pour vous.
Mais je ne pense pas que ce soit une excellente solution. Comme alternative pour vous d'enquêter, vous voudrez peut-être chercher quelque chose comme un proxy SMTP pour les liens de faible qualité. Comme vous l'avez découvert, SMTP est un protocole horrible pour les liaisons de faible qualité car une connexion interrompue fait redémarrer la transmission des messages depuis le début au lieu de reprendre là où elle s'était interrompue. Si vous allez embaucher un développeur pour quelque chose, j'envisagerais d'écrire un programme serveur qui accepte les connexions SMTP entrantes et envoie le message à une instance distante de ce même programme à l'autre extrémité de la connexion satellite de manière résumable ( éventuellement séparer les gros messages des petits messages via le port TCP pour permettre le traitement QoS par votre accélérateur WAN). L'instance distante pourrait alors, à réception du message complet,
la source
Modération des messages
Une solution probablement non idéale consiste à utiliser une règle de transport pour transférer les messages d'une certaine taille au gestionnaire de l'expéditeur ou à une boîte aux lettres désignée (sur le serveur Exchange du navire) pour modération. De cette façon, s'ils sont en mer, les gros messages peuvent être mis en file d'attente dans une autre boîte aux lettres. Lorsque le navire arrive au port, le gestionnaire ou le modérateur désigné peut les approuver pour la livraison.
Les inconvénients sont:
Un avantage est que vous auriez un humain à prendre des décisions sur l'envoi ou non d'un message, par exemple si un utilisateur essayait d'envoyer un tas de conneries non liées au travail qui ne feraient qu'embourber la connexion sans raison. Ils pourraient être corrigés par des contrôles administratifs comme le fait de pointer vers une politique et de les frapper au poignet pour qu'ils ne recommencent pas.
Règles de transport Exchange 2010
Script personnalisé
RE: Un script personnalisé pour gérer les gros e-mails. Je pouvais voir quelque chose comme ci-dessous qui activerait / désactiverait votre connecteur d'envoi sur le serveur Exchange. Un inconvénient est que tout le courrier est conservé dans la file d'attente au lieu de simplement les gros messages, mais une logique dans ce sens devrait fonctionner:
Cette logique n'est pas complètement peaufinée pour avoir un sens à 100%, mais vous avez l'idée - mettre en file d'attente tous les messages, vérifier la latence, suspendre les gros messages s'ils sont élevés, annuler la mise en file d'attente des messages, mettre tous les messages en file d'attente, etc. un script comme celui-ci est si jamais il tombe en panne ou s'arrête, comment sauriez-vous le réinitialiser sans personnel informatique à bord des navires? Il peut potentiellement arrêter tous les messages sortants indéfiniment (s'il s'arrête après avoir désactivé le connecteur d'envoi) ou vous pouvez perdre votre contrôle de message volumineux s'il laisse simplement le connecteur d'envoi activé et que le script n'est plus en cours d'exécution.
Proxy SMTP
Même si vous avez indiqué que vous êtes contre toute gestion de messages en dehors d'Exchange, après y avoir réfléchi un peu plus, j'ai décidé que je suis avec @longneck sur l'utilisation d'un certain type de solution proxy SMTP. Même IIS SMTP dispose d'un mécanisme de remise différée qui ne semble pas être le cas pour Exchange 2010. Vous pouvez rediriger des messages volumineux vers le serveur SMTP IIS qui pourrait les stocker sur le disque et, en vérifiant d'abord la latence, demander au serveur SMTP IIS de les envoyer via un script lorsque la latence est faible. Le pire des cas si votre mécanisme de planification est bloqué ou arrêté serait que les gros messages restent bloqués sur le disque, mais les petits messages continuent d'être envoyés. Il existe probablement de meilleures solutions que IIS SMTP, et je ne l'ai jamais utilisé moi-même, mais ce n'est qu'un exemple.
Configurer le courrier électronique SMTP dans IIS 7
la source
Essayez de jeter un coup d'œil aux nouvelles fonctionnalités de "Message Throttling" introduites avec Exchange 2010 SP1. Cela pourrait être très utile pour votre cas d'utilisation.
http://technet.microsoft.com/en-us/library/bb232205(v=exchg.141).aspx
la source