私の挑戦
さまざまなサイトに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に関する関連する質問にフィードバックをお寄せください。