Exchange 2010'da büyük e-postaları zamanlayın / sıralayın, gecikme süresi düşene kadar erteleyin

Zorluğum

Çeşitli sitelerde Exchange sunucularımız var, aynı zamanda gemilerde. Gemiler denizdeyken uydu bağlantıları üzerinden ağımıza bağlı, ancak limandayken WiFi köprülerine geçiyorlar.

Yüksek gecikme süresi (500+ ms) ve nadir olmayan bırakmalar (örn. Gemiler dönerken) nedeniyle, denizdeyken birkaç megabaytın üzerindeki e-postaları göndermeye çalışmak muhtemelen başarısız olur ve sınıra kadar yeniden denenir ulaşıldı. Sonuç: E-posta teslim edilmez ve her deneme sat bağlantısında değerli bant genişliği tüketir.

Bir "çözüm", maksimum e-posta boyutunu 5 MB ile sınırlamaktır, ancak bu kullanıcı dostu değildir ve bağlantı noktasındayken gereksiz bir kısıtlamadır.

Kaba fikir

Yapmayı tercih ettiğim, tüm e-postaları derhal gönderirken, denizde daha sonra teslim edilmek üzere belirlenmiş bir sınırdan daha büyük olan tüm e-postaları sıraya koymaktır. Daha sonra veri merkezimizde hub aktarım sunucusuna düzenli olarak ping yapacağımı düşünüyordum, gecikme ~ 400 ms'nin altına düştüğünde, büyük e-posta sırasını işlemeye başlayacağım. Gecikme süresi 400 ms'nin üzerine çıktığında, deliği tıkar ve e-postaların tekrar sıraya girmesine izin veririm.

Şimdi, 2003 sürümünden beri ellerimi Exchange ile gerçekten kirletmedim. O zaman, daha sonra teslim edilmek üzere büyük e-postalar planlayabilirsiniz, bu yüzden fikrim Exchange 2010'da benzer bir şey yapmaktı, sonra teslimatı değiştirmenin bir yolunu yazıyordum 'her zaman' ve 'asla' arasındaki büyük e-postalar için zamanlama.

Engel

Böyle bir komut dosyası oluşturmak çok karmaşık olmamalı, ancak sonra güveneceğim özelliğin Exchange 2007 ile kaldırıldığını okudum:

Bu, Exchange 2003'te bulunan bir özellikti ancak Exchange 2007 için kaldırıldı. SMTP Bağlayıcısı üzerinde 'büyük boyutlu iletiler için farklı teslim süreleri kullan' ile ayarlandı.

TechCenter: E-posta dağıtımını Exchange'deki boyuta göre planlamak mümkün mü?

Sorular

Bu doğru mu? - Bu özellik artık Exchange 2010'da mevcut değil mi veya yalnızca benzer bir şeye dönüştü, hedefime ulaşmak için kullanabilir miyim? Öyleyse ne olmuş?

Belirli Exchange sunucularında büyük e-postaların teslimini ertelemenin başka bir yolu var mı? Bir programa dayanabilir veya belki de belirli bir eylem gerektirebilir - Komut dosyası aracılığıyla teslimatı tetiklemenin bir yolu olacağından oldukça eminim, sadece gemilerde ayrı bir kuyrukta büyük e-postalara ihtiyacım var.

Bu konudaki düşünceleriniz çok takdir edilecektir! :-)

Düzenleme # 1: Rafine Kaba Fikir

İki adet PowerShell CmdLets'e rastladım, sanırım beni hedefime oldukça yaklaştırabilir:

• Suspend-Message
• Resume-Message

Yukarıdaki komutların ne tür mesajlarla ilgileneceğini görmek için bir süre Get-Message ile oynadım.

En önemlisi, bu komutlar bir mesaj boyutu filtresini kabul eder. Bu komut, geçerli sunucuda sıralı iletileri 5 MB'tan (5.242.880 bayt) büyük olarak listeler:

get-message -Filter {Size -gt 5242880}

Görünüşe göre Get-Messageyalnızca çeşitli uzak dağıtım kuyruklarından gelen iletileri döndürüyor. Ancak sunucu içinde akan iletiler, kısaca, Al / Askıya Al / Sürdür-İletisi'nin bozulacağı bir kuyrukta görünüyor mu?

Değilse, çözüm (pseudo code'da) satırları boyunca birkaç dakikada bir planlanmış bir komut dosyası kadar basit olabilir:

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

Endişeler / takip soruları:

Şimdi çoğunlukla ilgisiz - bkz. Düzenleme # 2.

Will Get-Messagesunucu içi teslimat için asla mesajlar - sadece uzaktan dağıtım sıradan ileti dönmek? Değilse, uzak dağıtım kuyruklarının kimlik adı, filtreleme için kullanabileceğim belirli bir modeli izliyor mu?

Bu, özel bir Aktarım Aracısı (@longneck tarafından önerildiği gibi) veya bir Etkinlik Lavabosu (bu kavram Exchange 2010'da hala mevcutsa) yoluyla yapılabilir mi?

Komut dosyasını her 5 dakikada bir çalıştırdığımı varsayalım, yine de büyük iletilerin gönderilmesi, askıya alınmadan önce 5 dakikaya kadar sorunlara neden olabilir. Şu ankinden daha iyi olacağız, ama bu optimal değil. Frekansı her dakikaya kadar artırabilirdim, ancak en zarif çözüm olmazdı.

Her 5 dakikada bir (oturmuş trafiği kaydetmek için) gidiş-dönüş süresini kontrol etsem bile, en son kaydedilen RTT'ye karşı kontrol etmek için hangi Exchange mekanizmasını ayarlamam gerekir, uzaktan teslim edilen her mesaj gönderildiğinde ve ardından uygun eylemi gerçekleştirmeli misiniz?

Düzenleme # 2: Önerilen Çözümler

Önerilen çözümleri, bunların artılarını ve eksilerini gördüğüm gibi özetlememe izin verin:

Özel Taşıma Acentesi

kavram

• Gecikmeyi periyodik olarak izleyin, yüksek veya düşük olarak sınıflandırın (eşik: 400 ms?)
• Özel bir Aktarım Aracısı aracılığıyla, gecikme sınıflandırması değiştiğinde, belirlenen bir eşikten daha büyük olan tüm e-postaları askıya alın / devam ettirin
• Özel TA aracılığıyla, gecikme yüksekse, derhal daha sonra gönderilen büyük iletileri "askıya alma" moduna getirin

Güçlü

• Gecikme yüksek olduğunda büyük e-postalar hiçbir zaman teslim edilmeye çalışılmaz

Zayıf Yönler

• Bu in-house yapmak için hiçbir geliştirme becerisi (kendi kendine not: kaynak kodu harici geliştirici ile yapılan sözleşmenin bir parçası olarak şirketime ait olmalıdır)
• Exchange ile bağlanan 3. taraf yazılımlar yamalama veya güncelleme sırasında sorunlara neden olabilir
• Bir şeyler ters gittiğinde bir tür destek anlaşması gereklidir (yukarıya bakın)

Büyük İletileri Denetle

kavram

• Gecikmeyi periyodik olarak izleyin, yüksek veya düşük olarak sınıflandırın (eşik: 400 ms?)
• Gecikme sınıflandırmasına bağlı olarak, tüm iletilerin akmasına izin vermek veya büyük iletileri denetleyiciye iletmek için Exchange Aktarım Kuralları'nı komut dosyası aracılığıyla yapılandırın
• Muhtemelen bir insan tarafından gemi limandayken moderatör kuyruğundaki mesajları onaylayın

Güçlü

• Gecikme yüksek olduğunda büyük e-postalar hiçbir zaman teslim edilmeye çalışılmaz
• İletiler yerel yerel Exchange Aktarım Kuralları kullanılarak askıya alınır

Zayıf Yönler

• Görünüşe göre, gecikme süresi düşük olduğunda mesajlar programlı olarak onaylanamaz, bu nedenle gemi limanda her seferde insan müdahalesi gerekir
• Denetleme programlı olarak ele alınmazsa olası gizlilik sorunları

Sorular

• Can mesajlar moderatör posta kutusundan programlı onaylanır? Nasıl?

Zamanlanmış PowerShell komutları

kavram

• Gecikmeyi periyodik olarak izleyin, yüksek veya düşük olarak sınıflandırın (eşik: 400 ms?)
• Gecikme yüksek olduğu sürece, sık sık (her dakika?) Büyük iletileri askıya alır ( Suspend-Message -Filter {Size -gt 5242880})
• Gecikme süresi düştüğünde, tüm iletileri devam ettirin ( Resume-Message)

Güçlü

• Uygulaması çok basit

Zayıf Yönler

• En zarif çözüm değil
• Her yeni büyük mesajın Suspend-Messageiletimi, komutlar arasındaki aralık boyunca , muhtemelen yine de bazı bant genişliğini boşa harcayan ve tıkanıklıklar yaratan (herhangi bir şey yapmamaya kıyasla çok kısa olsa da) denenebilir.

Sorular

• Suspend-MessageKomutlar arasında büyük mesajlar verme girişimlerinin nasıl önleneceğine dair bir fikrin var mı?
• Will Get-Messagesunucu içi teslimat için asla mesajlar - sadece uzaktan dağıtım sıradan ileti dönmek? Değilse, uzak dağıtım kuyruklarının kimlik adı, filtreleme için kullanabileceğim belirli bir modeli izliyor mu?

Düzenleme 3: İlerleme Yolu

Önerilen çözümleri ekibime getirdikten sonra (düzenleme 2'ye dahil edemediğim SMTP proxy'si dahil) ve kendi bağırsak hislerime dayanarak, özel bir Exchange Taşıma Aracısı'na gitmeye karar verdik.

Soruna nasıl saldıracağı ve ne kadara mal olacağı konusunda bana geri dönecek olan birkaç danışmanlık şirketi ile temasa geçiyorum.

Dış kaynak programlama görevleriyle ilgili herhangi bir deneyiminiz varsa , Stack Overflow ile ilgili soruma geri bildirim bırakmaktan çekinmeyin , çünkü bilmiyorum.

Sorunu istediğiniz gibi çözmek için, Microsoft Exchange Aktarım Aracısı SDK'sını kullanarak kendi Aktarım Aracısını yazabilirsiniz . Aktarım Aracıları olay tabanlıdır, bu nedenle Exchange bir ileti alındığında kitaplığınızdaki bir işlevi çağırır. Böylece kitaplığınız mesajı bekletmek gibi bir şey yapabilir. Bunu yapmak için şirket içi becerileriniz yoksa, sizin için yazmak için bir geliştirici kiralayabileceğinizden eminim.

Ama bunun harika bir çözüm olduğunu düşünmüyorum. Araştırmanız için bir alternatif olarak, düşük kaliteli bağlantılar için SMTP proxy'si gibi bir şeye bakmak isteyebilirsiniz. Bulduğunuz gibi, SMTP düşük kaliteli bağlantılar için korkunç bir protokoldür, çünkü kesik bir bağlantı, mesaj iletiminin kaldığı yerden devam etmek yerine baştan başlatılmasına neden olur. Bir şey için bir geliştirici kiralayacaksanız, gelen SMTP bağlantılarını kabul eden ve mesajı uydu bağlantısının diğer ucundaki aynı programın uzak bir örneğine devam ettirilebilir bir şekilde gönderen bir sunucu programı yazmayı düşünürüm ( WAN hızlandırıcı tarafından QoS tedavisine izin vermek için büyük iletileri TCP bağlantı noktası üzerinden küçük iletilerden ayırmak). Uzak örnek, iletinin tamamını aldıktan sonra,

Mesaj Denetimi

Muhtemelen ideal olmayan bir çözüm, belirli bir boyuttaki mesajları denetlemek için gönderenin yöneticisine veya belirlenmiş bir posta kutusuna (geminin Exchange sunucusunda) iletmek için bir taşıma kuralı kullanmaktır. Bu şekilde denizdeyse büyük mesajlar başka bir posta kutusunda sıraya alınabilir. Gemi limana geldiğinde, yönetici veya atanan moderatör bunları teslimat için onaylayabilir.

Dezavantajları:

• bu kural, manuel olarak devre dışı bırakmadığınız sürece (ancak bir komut dosyası aracılığıyla gerçekleştirilebildiği sürece) her zaman açıktır, bu nedenle bağlantı noktasında büyük iletiler bile moderatör posta kutusuna yönlendirilir
• tüm büyük iletilerin göndermeden önce biri tarafından manuel olarak incelenmesi gerekir, ancak belirli şeyler için kuralda istisnalar ekleyebilirsiniz
• başka bir kişi, gizlilik endişeleri nedeniyle ideal olmayabilecek giden postaları okuyor olabilir, ancak bu, kuruluşunuza bağlıdır

Bir ters tarafı, bir kullanıcının bir sebeple bağlantıyı kesecek bir grup işle ilgili olmayan bok göndermeye çalıştığı gibi bir mesajın gönderilip gönderilmeyeceği konusunda bir insan kararları vermenizdir. Bir politikaya işaret etmek ve bileğe vurmak gibi idari kontrollerle düzeltilebilirler, böylece tekrar yapmazlar.

Exchange 2010 Taşıma Kuralları

Özel Komut Dosyası

RE: Büyük e-postaları yönetmek için özel bir komut dosyası. Exchange sunucusunda Gönderme Bağlayıcınızı etkinleştiren / devre dışı bırakan aşağıdaki gibi bir şey görebiliyordum. Bir dezavantajı, tüm postaların yalnızca büyük iletiler yerine kuyrukta tutulmasıdır, ancak bu satırlardaki bazı mantıkların çalışması gerekir:

1. Gecikmeyi kontrol edin. Düşükse, Gönderme Bağlayıcısını etkinleştirin, büyük iletilerin askıya alınmasını bekleyin ve 5 dakika (veya rasgele başka bir süre) bekleyin. Yüksekse, Gönderme Bağlayıcısını devre dışı bırakın.
2. 5 dakika bekle.
3. 5 dakika sonra büyük mesajları kontrol edin ve askıya alın. Gönderme Bağlayıcısı'nı, kuyruk boşalana kadar küçük, sıraya alınmış iletiler serbest bırakılacak şekilde yeniden etkinleştirin (Gönderme bağlayıcısını yeniden etkinleştirdikten sonra kuyruk / WAN bağlantısını tıkamamak için bir seferde 1 ileti arasında geçiş yapabilirsiniz)
4. Gönderme Bağlayıcısını devre dışı bırakın ve # 1'e gidin

Bu mantık% 100 anlamlı olmak için tamamen parlatılmamıştır, ancak fikri alırsınız - tüm postaları kuyruğa alın, gecikmeyi kontrol edin, yüksekse büyük iletileri askıya alın, kuyruk dışı posta, tüm postaları kuyruğa alın, vb. böyle bir senaryo, herhangi bir çökme veya durma durumundaysa, gemide hiçbir BT personeli olmadan yeniden başlatmayı nasıl bilebilirsiniz? Tüm giden postaları süresiz olarak durdurabilir (Gönderme Bağlayıcısını devre dışı bıraktıktan sonra durursa) veya yalnızca Gönderme Bağlayıcısını etkin bırakırsa ve komut dosyası artık çalışmıyorsa büyük ileti denetiminizi kaybedebilirsiniz.

SMTP Proxy'si

Exchange dışında herhangi bir ileti işleme karşı olduğunuzu belirtmiş olsanız bile, Bunu biraz düşündükten sonra, bir tür SMTP proxy çözümü kullanma @longneck ile karar verdim. IIS SMTP'nin bile Exchange 2010'un görmediği ertelenmiş bir dağıtım mekanizması vardır. Büyük iletileri diskte depolayabilen IIS SMTP sunucusuna yeniden yönlendirebilir ve önce gecikme süresini denetleyerek IIS SMTP sunucusunun gecikme süresi düşük olduğunda bunları komut dosyası aracılığıyla göndermesini sağlayabilirsiniz. Zamanlama mekanizmanız sıkışırsa veya durursa en kötü durum büyük mesajların diskte takılı kalmasıdır, ancak küçük mesajlar gönderilmeye devam eder. Muhtemelen IIS SMTP'den daha iyi çözümler var ve ben hiç kullanmadım, ama bu sadece bir örnek.

IIS 7'de SMTP E-postasını Yapılandırma

Exchange 2010 SP1 ile sunulan "İleti Azaltma" nın yeni özelliklerine bir göz atmaya çalışın. Kullanım durumunuz için çok yararlı olabilir.

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