Exchange 2010で大きな電子メールをスケジュール/キューに入れ、遅延が減少するまで延期します


14

私の挑戦

さまざまなサイトにExchangeサーバーがありますが、船内にもあります。船は、海上では衛星リンクを介してネットワークに接続されますが、港ではWiFiブリッジに切り替えます。

待ち時間が長く(500ミリ秒以上)、珍しいドロップアウトがないため(例:船が回転しているとき)、海上で数メガバイトを超える電子メールを送信しようとすると、失敗し、制限まで再試行される可能性がありますに達した。結果:電子メールは配信されず、各試行はsatリンクの貴重な帯域幅を消費します。

1つの「解決策」は、電子メールの最大サイズを5 MBに制限することですが、それはユーザーフレンドリーではなく、ポート内での不必要な制限です。

大まかなアイデア

私がしたいのは、設定された制限を超えるすべての電子メールをキューに入れて、後で海にいるときに配信し、すべての小さな電子メールをすぐに送信することです。その後、データセンターのハブトランスポートサーバーに定期的にpingを実行し、待ち時間が400ミリ秒未満になると、大きな電子メールキューの処理を開始すると考えていました。遅延が400ミリ秒を超えると、この穴をふさいで、電子メールを再びキューに入れます。

今、バージョン2003以降、Exchangeに手を汚していません。当時は、後で配信するために大きな電子メールをスケジュールできました。そのため、私の考えはExchange 2010で同様のことを行い、配信を切り替える方法をスクリプト化することでした'always'と 'never'の間の大きな電子メールのスケジュール。

障害

そのようなスクリプトを作成するのはそれほど複雑ではないはずですが、次に頼っていた機能がExchange 2007で削除されたことを読みました。

これはExchange 2003に存在する機能でしたが、Exchange 2007では削除されました。「特大のメッセージに異なる配信時間を使用する」SMTPコネクタで設定されました。

TechCenter:Exchangeのサイズに基づいてメール配信をスケジュールすることはできますか?

ご質問

本当ですか?-この機能はExchange 2010に存在しなくなりましたか、それとも同様の機能に変換されただけで、目標を達成するために使用できますか?もしそうなら、何?

特定のExchangeサーバーで大きな電子メールの配信を延期する別の方法はありますか?スケジュールに基づいている場合もあれば、特定のアクションを必要とする場合もあります。スクリプトを介して配信をトリガーする方法があることはかなり確信しています。

これについてのあなたの考えは高く評価されます!:-)

編集#1:洗練された大まかなアイデア

私は2つのPowerShell CmdLetsを手に入れたので、目標にかなり近づけることができました。

上記のコマンドがどのようなメッセージを処理するかを確認するために、しばらくGet-Messageをいじりました。

最も重要なのは、これらのコマンドがメッセージサイズフィルターを受け入れることです。このコマンドは、現在のサーバーで、5 MB(5,242,880バイト)を超えるキューに入れられたメッセージをリストします。

get-message -Filter {Size -gt 5242880}

Get-Messageさまざまなリモート配信キューからのメッセージのみを返すようです。しかし、サーバー内を流れるメッセージは、たとえ短時間であっても、Get / Suspend / Resume-Messageが混乱するキューに表示されますか?

そうでない場合、ソリューションは、次の行に沿って、数分ごとにスケジュールされたスクリプトのように単純になる可能性があります(擬似コードで):

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

懸念/フォローアップの質問:

今はほとんど関係ない-編集#2を参照。

ウィルGet-Messageサーバ内の配信のために決してメッセージ-唯一のリモート配信キューからメッセージを返しますか?そうでない場合、リモート配信キューのID名は特定のパターンに従っていますか?フィルタリングに使用できますか?

これは、カスタムトランスポートエージェント(@longneckが提案)またはイベントシンク(この概念がExchange 2010にまだ存在する場合)を介して実行できますか、または実行する必要がありますか?

スクリプトを5分ごとに実行すると、大きなメッセージが送信されることを意味し、中断される前に最大5分間問題を引き起こす可能性があります。私たちは今よりもまだましですが、それは最適ではありません。頻度を1分ごとに増やすことはできますが、それは最もエレガントなソリューションではありません。

(飽和トラフィックを節約するために)5分ごとに往復時間のみをチェックする場合でも、リモート配信に送信されるメッセージが送信されるたびに、最後に記録されたRTTをチェックするために、どのExchangeメカニズムをセットアップする必要がありますかキューに入れて、適切なアクションを実行しますか?

編集#2:提案されたソリューション

提案されたソリューションと、その長所と短所を要約してみましょう。

カスタムトランスポートエージェント

概念

  • 定期的に遅延を監視し、高または低に分類します(しきい値:400ミリ秒?)
  • カスタムトランスポートエージェントを使用して、遅延分類が変更されたときに、設定されたしきい値を超えるすべての電子メールを一時停止/再開する
  • 遅延が大きい場合、カスタムTAを使用して、その後送信された大きなメッセージをすぐに「中断」モードにします

強み

  • 遅延が大きい場合、大きな電子メールが配信されることはありません

弱点

  • これを社内で行うための開発スキルはありません(自己注意:外部開発者との契約の一部として、ソースコードは私の会社に属している必要があります)
  • Exchangeに接続するサードパーティソフトウェアは、パッチの適用または更新時に問題を引き起こす可能性があります
  • 問題が発生した場合に備えて、何らかのサポート契約が必要です(上記を参照)

中規模の大きなメッセージ

概念

  • 定期的に遅延を監視し、高または低に分類します(しきい値:400ミリ秒?)
  • 遅延分類に基づいて、スクリプトを介してExchangeトランスポートルールを構成し、すべてのメッセージをフローさせるか、大きなメッセージをモデレーターに転送します。
  • 船が港にいる場合、おそらくは人間によって、モデレーターキューのメッセージを承認します

強み

  • 遅延が大きい場合、大きな電子メールが配信されることはありません
  • ネイティブのネイティブExchangeトランスポートルールを使用してメッセージが中断されます

弱点

  • 見た目では、待ち時間が短い場合、プログラムでメッセージを承認することはできません。そのため、船舶が入港するたびに人間の介入が必要です。
  • モデレートがプログラムで処理されない場合、おそらくプライバシーの問題

ご質問

  • モデレーターのメールボックスからプログラムでメッセージを承認できますか?どうやって?

スケジュールされたPowerShellコマンド

概念

  • 定期的に遅延を監視し、高または低に分類します(しきい値:400ミリ秒?)
  • 待ち時間が長い限り、頻繁に(1分ごとに)大きなメッセージを一時停止します(Suspend-Message -Filter {Size -gt 5242880}
  • レイテンシーが低くなったら、すべてのメッセージを再開します(Resume-Message

強み

  • 実装が非常に簡単

弱点

  • 最もエレガントなソリューションではない
  • 各新しい大きなメッセージの配信は、Suspend-Messageコマンド間の間隔で試行できますが、帯域幅を浪費し、輻輳を引き起こす可能性があります(ただし、何もしないことと比較すると非常に簡単です)

ご質問

  • Suspend-Messageコマンド間で大きなメッセージを配信しようとするのを防ぐ方法についてのアイデアはありますか?
  • ウィルGet-Messageサーバ内の配信のために決してメッセージ-唯一のリモート配信キューからメッセージを返しますか?そうでない場合、リモート配信キューのID名は特定のパターンに従っていますか?フィルタリングに使用できますか?

編集#3:今後の道

提案されたソリューションをチームに持ち込んだ後(編集#2に含めなかったSMTPプロキシを含む)、私自身の直感に基づいて、カスタムExchangeトランスポートエージェントを採用することにしました。

私は、いくつかのコンサルタント会社と連絡を取り合っています。コンサルタント会社は、問題がどのように攻撃し、費用がかかるかについて私に連絡します。

プログラミングタスクのアウトソーシングの経験がある場合は、Stack Overflowに関する関連する質問にフィードバックをお寄せください。


3
私が最近見たより良い質問の1つに対して+1。
ジョンガーデニアーズ

船上のExchangeサーバーはどの役割を担っていますか?

出荷時のExchangeサーバーは、ハブトランスポート、メールボックス、およびクライアントアクセスの役割を保持しています。
抽象化

1
衛星リンクでQoSまたはWANオプティマイザーのいずれかのタイプを実行していますか?
ロングネック

うーん、メールボックスの役割で、あなたも...外部のメールが船のExchangeサーバー上で誰かのメールボックスに送信されますときに、リンクが飽和し持つことができる
8月

回答:


2

要求した方法で問題を解決するには、Microsoft Exchange Transport Agent SDKを使用して独自のトランスポートエージェントを作成できます。トランスポートエージェントはイベントベースであるため、メッセージを受信すると、Exchangeはライブラリ内の関数を呼び出します。ライブラリはメッセージを保留するなどの操作を実行できます。社内でこれを行うスキルがない場合は、開発者を雇って作成してもらうことができます。

しかし、これは素晴らしい解決策ではないと思います。調査するための代替手段として、低品質リンクのSMTPプロキシのようなものに注目することができます。発見したように、SMTPは低品質リンクの恐ろしいプロトコルです。接続が中断されると、メッセージ送信が中断したところから再開するのではなく、最初から再開するためです。何かのために開発者を雇うつもりなら、受信SMTP接続を受け入れ、再開可能な方法でサテライト接続の反対側にある同じプログラムのリモートインスタンスにメッセージを送信するサーバープログラムを書くことを検討します( WANポートアクセラレータによるQoS処理を可能にするために、TCPポート経由で小さなメッセージから大きなメッセージを分離する可能性があります)。リモートインスタンスは、完全なメッセージを受信すると、


ご意見ありがとうございます!私はそれが私が望んでいたよりもはるかに少ない箱のようなものだと言わなければなりません。私はKISSの原則の大ファンです。トランスポートエージェントの記述についてはあまり知りませんが、Exchange内で処理を維持することは、ややややややこしくなります。Exchange 2010では、キューは必要に応じて作成および破棄されるようです。エージェントが大きなメールを強制的に別のキューに入れ、スクリプトが「一時停止」と「再開」を切り替えることができる場合があります。Exchange 2010でTAを使用してできることは何ですか?
抽象化

SMTPプロキシ/スマートホストの提案に関しては、できれば積極的に保守されている既成のソリューションを見つけることができれば、それはOKソリューションとして聞こえます。Exchange内のフローを変更するのは、Exchangeトランスポートエージェントよりも大きく複雑なプログラミングタスクのようです(間違っているかもしれません)。私の経験では、SMTPプロキシのように複雑でカスタムメイドのソリューションは、長期的にサポートするのに費用がかかる傾向があります。
抽象化

re:別のキュー。キューがそのように機能するかどうか、またはそれが最良の方法であるかどうかを知るために、Exchangeの内部に十分な知識がありません。Litera Metadact-eでの経験に基づいて、処理のためにTAが個々のメッセージを保持できることを知っています。これはまさにその処理を行います。それらを無期限に保持できるかどうかはわかりません。
ロングネック

私の答えの全体的なポイントは、すぐに使えるソリューションはないので、おそらく開発者に相談すべきだということです。ただし、これは非常に単純な問題であり、この問題を解決するために開発者を雇うことはおそらく法外な費用ではありません。
ロングネック

Suspend-Message PowerShell CmdLetの存在は、メッセージの配信状態もプログラムで変更できることを確信しています。Exchangeですべてのメッセージ追跡、管理者権限の委任などを維持できるため、個別のSMTPプロキシを介してメッセージの配信状態を変更するだけのカスタムトランスポートエージェントのアイデアが好きです。ご意見ありがとうございます!
-abstrask

3

メッセージの管理

おそらく理想的ではない解決策の1つは、トランスポートルールを使用して、一定のサイズでメッセージを送信者の上司または指定されたメールボックス(船のExchangeサーバー上)に転送してモデレートすることです。このように、海上にいる場合、大きなメッセージは本質的に別のメールボックスにキューイングできます。船舶が港に到着すると、管理者または指定されたモデレーターが配送を承認できます。

欠点は次のとおりです。

  • このルールは手動で無効にしない限り常にオンになります(ただし、スクリプトを使用して実行できます)
  • すべての大きなメッセージは、送信する前に誰かが手動で確認する必要がありますが、特定の事柄のルールに例外を追加できます
  • 別の人が送信メールを読んでいる可能性がありますが、これはプライバシーの懸念から理想的ではない場合がありますが、これは組織によって異なります

利点の1つは、ユーザーが理由なしに接続を完全に停止させてしまうような、業務に関係しない大量のメッセージを送信しようとしているかどうかなど、メッセージを送信するかどうかを人間が決定することです。それらは、ポリシーを指し示し、手首を叩くなどの管理コントロールによって修正される可能性があります。

Exchange 2010トランスポートルール

カスタムスクリプト

RE:大量の電子メールを管理するためのカスタムスクリプト。Exchangeサーバーで送信コネクタを有効または無効にする次のようなものが表示されます。欠点は、すべてのメールが大きなメッセージだけでなくキューに保持されることですが、これらの行に沿ったいくつかのロジックが機能するはずです:

  1. 待ち時間を確認してください。低い場合は、送信コネクタを有効にし、大きなメッセージの一時停止を解除して、5分(またはその他の任意の時間)待機します。高い場合は、送信コネクタを無効にします。
  2. 5分お待ち下さい。
  3. 5分後、大きなメッセージを確認して中断します。キューが空になるまで、送信コネクタを非常に小さく再有効化します(送信コネクタを再度有効にした後にキュー/ WANリンクを詰まらせないように、一度に1つのメッセージを循環させることもできます)
  4. 送信コネクタを無効にして、#1に移動します

このロジックは完全に洗練されているわけではありませんが、すべてのメールをキューに入れ、待ち時間を確認し、大きい場合は大きなメッセージを中断し、メールをキューから外し、すべてのメールをキューに入れます。このようなスクリプトは、クラッシュまたは停止した場合、船内のITスタッフがいない状態でスクリプトを再初期化する方法を知っていますか?すべての送信メールを無期限に停止する可能性があります(送信コネクタを無効にした後に停止する場合)、または送信コネクタを有効のままにしてスクリプトが実行されなくなった場合、大きなメッセージコントロールが失われる可能性があります。

SMTPプロキシ

Exchange以外でのメッセージ処理に反対していることを示したとしても、これについてさらに考えた後、何らかの種類のSMTPプロキシソリューションを使用することに@longneckを使うことにしました。IIS SMTPにも、Exchange 2010にはないように見える遅延配信メカニズムがあります。大きなメッセージをディスクに保存できるIIS SMTPサーバーにリダイレクトし、最初に待機時間を確認して、待機時間が短いときにIIS SMTPサーバーにスクリプトを介して送信させることができます。スケジューリングメカニズムがスタックまたは停止した場合の最悪のケースは、大きなメッセージがディスクにスタックすることですが、小さなメッセージは引き続き送信されます。おそらくIIS SMTPよりも優れたソリューションがあり、自分で使用したことはありませんが、これは単なる例です。

IIS 7でSMTP電子メールを構成する


ご意見ありがとうございます!直接指定されていませんが、延期された電子メールが最終的に変更されずに宛先に到達することが私にとっての要件です。それは、最初にモデレーターのメールボックスに転送する場合ですか、それとも非表示または表示の標識を残しますか?それらを手動で承認するプロセスについては、これは何らかの形でスクリプト化できると思いますか?
抽象化

いい質問です。これを実装したことがないので、Exchange組織で簡単なテストルールを作成し、テストメールを送信しました。モデレーターは、「承認」または「拒否」オプション付きのメッセージを受け取りました。メッセージを承認すると、メッセージはリリースされ、メッセージヘッダーまたは電子メール本文のどこにもモデレーターメールボックスの兆候なしに変更されずに宛先に送信されました。ただし、承認プロセスのスクリプトについては何も見つからないようですので、このタスクに実際に人間を指定する必要があるかもしれません。
8月

アイデアをありがとうございます。スクリプトを使用してルールを簡単に変更できると思いますが、専任のITスタッフがいないため、人間の介入の部分は大きな欠点です。メッセージをプログラムで承認できるかどうか、どのように知っていますか?
-abstrask

2

Exchange 2010 SP1で導入された「メッセージ調整」の新機能を見てみてください。ユースケースに非常に役立つ可能性があります。

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


1
この特定のシナリオでメッセージ調整が役立つかどうかはわかりません。この記事を読むと、トランスポートサーバーまたはエッジサーバーが大量のメッセージに圧倒されるのを防ぐことを目的としているため、QoSタイプのレベルのメッセージ配信を提供するためにコストがかかります。この場合、1人のユーザーが10 MBのメッセージを送信すると、WANリンク全体が飽和状態になり、他のサービスが利用できなくなります。遅延配信メカニズムの方が適切だと思います。

1
申し訳ありませんが、私はそれを読むと、「メッセージ調整は」ちょうどます好む小さいメッセージを送信する(デフォルトでは、通常の低へのメッセージ比は20:1)、ない妨げる大きなメッセージを送信します。私の目標を達成する方法について、より具体的な提案はありますか?ありがとう。
抽象化
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.