Tantangan saya
Kami memiliki server Exchange di berbagai situs, tetapi juga di atas kapal. Kapal-kapal terhubung ke jaringan kami melalui tautan satelit ketika di laut, tetapi beralih ke jembatan WiFi saat di pelabuhan.
Karena latensi tinggi (500+ ms) dan drop-out yang tidak biasa (misalnya ketika kapal berputar), mencoba mengirim email apa pun di atas beberapa megabyte saat berada di laut, kemungkinan akan gagal dan dicoba lagi hingga batasnya telah tercapai. Hasilnya: Email tidak terkirim dan masing-masing mencoba mengkonsumsi bandwidth berharga pada tautan sat.
Salah satu "solusi" adalah membatasi ukuran email maksimum hingga 5 MB, tapi itu tidak mudah digunakan dan tidak perlu pembatasan saat berada di port.
Ide yang kasar
Apa yang saya lebih suka lakukan, adalah mengantri semua email lebih besar dari batas yang ditentukan untuk pengiriman nanti ketika di laut, saat mengirim semua email kecil segera. Saya kemudian berpikir saya akan melakukan ping ke server transport hub di pusat data kami secara teratur, ketika latensi turun di bawah ~ 400 ms, saya akan mulai memproses antrian email yang besar. Ketika latensi naik lebih dari 400 ms, saya akan pasang lubang dan membiarkan e-mail masuk lagi.
Sekarang, saya belum benar-benar kotor dengan Exchange sejak versi 2003. Saat itu, Anda dapat menjadwalkan e-mail besar untuk pengiriman nanti, jadi ide saya melakukan sesuatu yang serupa di Exchange 2010, lalu skrip cara untuk mengalihkan pengiriman. jadwal untuk email besar antara 'selalu' dan 'tidak pernah'.
Kendala
Seharusnya tidak terlalu rumit untuk membuat skrip seperti itu, tetapi kemudian saya membaca bahwa fitur yang saya andalkan telah dihapus dengan Exchange 2007:
Ini adalah fitur yang ada di Exchange 2003 tetapi telah dihapus untuk Exchange 2007. Ini ditetapkan pada Konektor SMTP dengan 'menggunakan waktu pengiriman yang berbeda untuk pesan yang terlalu besar'.
TechCenter: Apakah mungkin untuk menjadwalkan pengiriman email berdasarkan ukuran di Exchange?
Pertanyaan
Apakah itu benar - Apakah fitur ini tidak lagi hadir di Exchange 2010, atau hanya diubah menjadi sesuatu yang serupa, yang dapat saya gunakan untuk mencapai tujuan saya? Jika ya, apa?
Apakah ada cara lain untuk menunda pengiriman email besar di server Exchange tertentu? Itu bisa didasarkan pada jadwal atau bahkan mungkin memerlukan tindakan khusus - saya cukup yakin akan ada beberapa cara untuk memicu pengiriman melalui skrip, saya hanya perlu email besar dalam antrian terpisah di kapal.
Pikiran Anda tentang ini akan sangat dihargai! :-)
Sunting # 1: Gagasan Kasar yang Disempurnakan
Saya mencoba dua PowerMell CmdLets saya pikir saya bisa membawa saya cukup dekat dengan tujuan saya:
Saya bermain-main dengan Get-Message untuk sementara waktu, untuk melihat pesan seperti apa yang akan ditangani oleh perintah di atas.
Yang terpenting, perintah ini menerima filter ukuran pesan. Perintah ini akan mencantumkan pesan yang antri, pada server saat ini, lebih besar dari 5 MB (5.242.880 byte):
get-message -Filter {Size -gt 5242880}
Tampaknya Get-Messagehanya mengembalikan pesan dari berbagai antrian pengiriman jarak jauh. Tetapi apakah pesan mengalir dalam server, namun secara singkat, muncul dalam antrian yang Get / Suspend / Resume-Message akan berantakan?
Jika tidak, solusinya bisa sesederhana skrip terjadwal setiap beberapa menit, di sepanjang baris (dalam kode pseudo):
if ping_rtt > 400 Then
Suspend-Message -Filter {Size -gt 5242880}
Else
Resume-Message
EndIf
Masalah / pertanyaan lanjutan:
Sebagian besar tidak relevan sekarang - lihat edit # 2.
Apakah Get-Messagehanya akan mengembalikan pesan dari antrian pengiriman jarak jauh - tidak pernah pesan untuk pengiriman intra-server? Jika tidak, apakah nama identitas antrian pengiriman jauh mengikuti pola tertentu, yang dapat saya gunakan untuk memfilter?
Bisakah / haruskah ini dilakukan melalui Agen Transport khusus (seperti yang disarankan oleh @longneck) atau Event Sink (jika konsep ini masih ada di Exchange 2010)?
Katakanlah saya menjalankan skrip setiap 5 menit, itu masih berarti pesan besar sedang dikirim, berpotensi menyebabkan masalah hingga 5 menit, sebelum ditangguhkan. Kita masih lebih baik dari kita sekarang, tetapi itu tidak optimal. Saya dapat meningkatkan frekuensinya setiap menit, tetapi itu bukan solusi yang paling elegan.
Bahkan jika saya hanya memeriksa waktu bolak-balik setiap 5 menit (untuk menghemat lalu lintas sat), mekanisme Exchange apa yang harus saya siapkan, untuk mengecek terhadap RTT yang terakhir direkam, setiap kali sebuah pesan dikirimkan yang dikirim ke pengiriman jarak jauh mengantri, dan kemudian mengambil tindakan yang sesuai?
Sunting # 2: Solusi yang Diusulkan
Izinkan saya untuk merangkum solusi yang diusulkan, dan pro dan kontra mereka seperti yang saya lihat:
Agen Transportasi Khusus
Konsep
- Monitor latensi secara berkala, klasifikasikan sebagai tinggi atau rendah (ambang batas: 400 ms?)
- Melalui Agen Transportasi khusus, menangguhkan / melanjutkan semua email yang lebih besar dari ambang batas yang ditetapkan, ketika klasifikasi latensi berubah
- Melalui TA kustom, segera masukkan pesan besar selanjutnya dalam mode "tangguhkan", jika latensi tinggi
Kekuatan
- Email besar tidak pernah dicoba dikirim ketika latensi tinggi
Kelemahan
- Tidak ada keterampilan pengembangan untuk membuat in-house ini (catatan untuk diri sendiri: kode sumber harus menjadi milik perusahaan saya sebagai bagian dari kontrak dengan pengembang eksternal)
- Perangkat lunak pihak ketiga yang terkait dengan Exchange dapat menyebabkan masalah saat menambal atau memperbarui
- Diperlukan semacam perjanjian dukungan, jika terjadi kesalahan (lihat di atas)
Pesan Besar Sedang
Konsep
- Monitor latensi secara berkala, klasifikasikan sebagai tinggi atau rendah (ambang batas: 400 ms?)
- Berdasarkan klasifikasi latensi, konfigurasikan Exchange Transport Rules melalui scripting, untuk membiarkan semua pesan mengalir atau meneruskan pesan besar ke moderator
- Menyetujui pesan dalam antrean moderator saat mengirim di pelabuhan, mungkin oleh manusia
Kekuatan
- Email besar tidak pernah dicoba dikirim ketika latensi tinggi
- Pesan ditangguhkan menggunakan Aturan Transport Exchange asli setempat
Kelemahan
- Dengan kelihatannya, pesan tidak dapat disetujui secara program ketika latensi rendah, maka intervensi manusia diperlukan setiap kali kapal berada di pelabuhan
- Mungkin masalah privasi, jika tidak dikelola secara terprogram
Pertanyaan
- Bisakah pesan disetujui secara terprogram dari kotak surat moderator? Bagaimana?
Perintah PowerShell terjadwal
Konsep
- Monitor latensi secara berkala, klasifikasikan sebagai tinggi atau rendah (ambang batas: 400 ms?)
- Selama latensi tinggi, sering (setiap menit?) Menangguhkan pesan besar (
Suspend-Message -Filter {Size -gt 5242880}) - Ketika latensi turun ke rendah, lanjutkan semua pesan (
Resume-Message)
Kekuatan
- Sangat sederhana untuk diimplementasikan
Kelemahan
- Bukan solusi yang paling elegan
- Pengiriman setiap pesan besar baru dapat dicoba selama interval antar
Suspend-Messageperintah, mungkin masih menyia-nyiakan beberapa bandwidth dan membuat kemacetan (meskipun sangat singkat dibandingkan dengan tidak melakukan apa-apa)
Pertanyaan
- Adakah ide tentang cara mencegah upaya untuk mengirim pesan besar, di antara
Suspend-Messageperintah? - Apakah
Get-Messagehanya akan mengembalikan pesan dari antrian pengiriman jarak jauh - tidak pernah pesan untuk pengiriman intra-server? Jika tidak, apakah nama identitas antrian pengiriman jauh mengikuti pola tertentu, yang dapat saya gunakan untuk memfilter?
Sunting # 3: Langkah Maju
Setelah membawa solusi yang diusulkan di tim saya (termasuk proksi SMTP, yang gagal saya sertakan dalam edit # 2), dan berdasarkan perasaan saya sendiri, kami memutuskan untuk mencari Agen Transport Exchange kustom.
Saya berhubungan dengan beberapa perusahaan konsultan, yang akan kembali kepada saya dengan bagaimana kehendak menyerang masalah dan berapa biayanya.
Jika Anda memiliki pengalaman dengan outsourcing tugas pemrograman, jangan ragu untuk meninggalkan umpan balik ke pertanyaan terkait saya di Stack Overflow , karena saya tidak.