web-dev-qa-db-ja.com

Exchange 2010で大規模な電子メールをスケジュール/キューに入れ、待機時間が減少するまで延期する

私の挑戦

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

レイテンシが長い（500+ ms）とドロップアウトが珍しくなく（船が方向転換している場合など）、海上で数メガバイトを超えるメールを送信しようとすると、失敗して制限まで再試行される可能性があります。に達した。結果：電子メールは配信されず、試行するたびにsatリンク上の貴重な帯域幅が消費されます。

"解決策"の1つは、電子メールの最大サイズを5 MBに制限することですが、これはユーザーフレンドリーではなく、移植時の不要な制限です。

大まかなアイデア

私がやりたいのは、すべての小さな電子メールをすぐに送信しながら、すべての電子メールを、設定された制限よりも大きいキューに入れて、後で海に送られるようにすることです。次に、データセンターのハブトランスポートサーバーに定期的にpingを実行し、レイテンシが400ミリ秒未満になると、大きな電子メールキューの処理を開始すると考えていました。レイテンシが400ミリ秒を超えると、穴をふさぎ、電子メールを再びキューに入れます。

現在、バージョン2003以降、Exchangeにそれほど手を染めていません。当時は、後で配信するように大規模な電子メールをスケジュールすることができたので、Exchange 2010で同様のことを行い、配信を切り替える方法をスクリプト化しました。 「常に」と「決して」の間の大規模な電子メールのスケジュール。

障害

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

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

TechCenter：Exchangeのサイズに基づいてメール配信をスケジュールすることは可能ですか？

ご質問

本当ですか？ -この機能はExchange 2010には存在しませんか、それとも単に類似したものに変換されただけで、目的を達成するために使用できますか？もしそうなら、何ですか？

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

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

編集＃1：洗練されたラフなアイデア

私は2つのPowerShell CmdLetを試してみました。目標にかなり近づけると思います。

上記のコマンドがどのようなメッセージを処理するかを確認するために、しばらく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トランスポートルールを使用してメッセージが中断されている

弱点

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

質問

  • Canメッセージは、モデレーターのメールボックスからプログラムで承認されますか？どうやって？

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

コンセプト

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

強さ

  • 実装が非常に簡単

弱点

  • 最もエレガントなソリューションではありません
  • 新しい大きな各メッセージの配信は、Suspend-Messageコマンドの間隔が空いている限り試行できますが、帯域幅が無駄になり、輻輳が発生する可能性があります（何もしない場合に比べると非常に短時間ですが）。

質問

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

編集＃3：前進

私のチームで提案されたソリューション（編集＃2に含めなかったSMTPプロキシを含む）を取り上げた後、自分の直感に基づいて、カスタムExchangeトランスポートエージェントを使用することにしました。

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

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

exchangeexchange-2010smtpsatellite
14
abstrask

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

しかし、これは素晴らしい解決策だとは思いません。調査する代替手段として、低品質のリンクのためにSMTPプロキシのようなものを調べたい場合があります。ご存じのように、SMTPは接続の中断によりメッセージの送信が中断したところから再開するのではなく、最初から再開されるため、低品質のリンクにとって恐ろしいプロトコルです。開発者を雇うつもりなら、着信SMTP接続を受け入れ、サテライト接続のもう一方の端にある同じプログラムのリモートインスタンスにメッセージを再開可能な方法で送信するサーバープログラムを書くことを検討します（ TCPポートを介して大きなメッセージを小さなメッセージから分離することにより、WANアクセラレータによるQoS処理を可能にします）。リモートインスタンスは、メッセージ全体、SMTPを介したメッセージの配信を完了します。

2
longneck

メッセージ管理

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

欠点は次のとおりです。

  • このルールは、手動で無効にしない限り（ただし、スクリプトを使用して実行できます）常にオンになっているため、ポートが大きい場合でも、メッセージはモデレーターのメールボックスにリダイレクトされます。
  • 大きなメッセージはすべて、送信する前に誰かが手動で確認する必要がありますが、特定の事柄についてルールに例外を追加できます
  • 別の人が送信メールを読んでいますが、プライバシーの問題から理想的ではないかもしれませんが、これは組織によって異なります

利点の1つは、ユーザーが理由のない接続を停止するような仕事に関連しないがらくたの束を送信しようとした場合など、メッセージを送信するかどうかを人間が決定することです。それらは、ポリシーを指して手首で叩くなどの管理コントロールによって修正され、再度実行しないようにすることができます。

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

カスタムスクリプト

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

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

このロジックは100％の意味で完全に洗練されているわけではありませんが、すべてのメールをキューに入れ、待ち時間を確認し、大きい場合は大きなメッセージを一時停止し、メールのキューを解除し、すべてのメールをキューに入れるなどのアイデアを得ます。このようなスクリプトは、クラッシュまたは停止した場合に、船にITスタッフがいない状態でスクリプトを再初期化する方法を教えてください。すべての送信メールが無期限に停止する可能性があります（送信コネクタを無効にした後に停止した場合）、または送信コネクタが有効なままでスクリプトが実行されていない場合、大きなメッセージコントロールを失う可能性があります。

SMTPプロキシ

Exchangeの外部でのメッセージ処理に反対しているとおっしゃいましたが、これについてもう少し考えた後、ある種のSMTPプロキシソリューションを使用することに@longneckを使うことにしました。 IIS SMTPには遅延配信メカニズムがあり、Exchange 2010にはないようです。大きなメッセージをIIS SMTPサーバーにリダイレクトすることができます。ディスク、および最初にレイテンシをチェックする場合、IIS SMTPサーバーがレイテンシが低いときにスクリプトを介して送信するようにします。スケジューリングメカニズムが停止または停止した場合の最悪のケースは、大きなメッセージです。ディスクに行き詰まりますが、小さなメッセージが送信され続けますIIS SMTPより良い解決策があり、私自身はこれを使用したことがありませんが、これは単なる例です。

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

3
August

Exchange 2010 SP1で導入された「メッセージスロットリング」の新機能を見てみましょう。これは、ユースケースに非常に役立ちます。

http://technet.Microsoft.com/en-us/library/bb232205（v = exchg.141）.aspx

2
Emyl