Queue – kuyruk, genel olarak pek çok teknoloji ürününde kullanılan bir kavramdır. Exchange Server mimarisinde de pek çok sistem yöneticisinin yakından bildiği ve zaman zaman sorun yaşadığı başlıklardan birisidir. Temel olarak bir mesajın hedefine ulaşmak için geçici olarak beklediği alan olarak ifade edebiliriz. Mesaj iletilmeden önce, iletilme sırasında ve iletildikten sonra kuyrukta saklanır ( detaylı olarak makalenin ilerleyen bölümlerinde açıklanacaktır). Her mailbox ve Edge rolünde ( Exchange 2010 için Hub transport ve Edge ) yer alan bir veri tabanıdır. Özetle transport sunucularında yer alan bir veri tabanıdır. Aynı maillerin saklandığı Exchange Server Mailbox Database gibi Queue Database de yer almaktadır. ( Her ikisi de Extensible Storage Engine (ESE) mimarisini kullanır)
Exchange Server 2013 için kuyruk tipleri aşağıdaki gibidir;
- Persistent queues
- Submission queue
- Unreachable queue
- Poison message queue
- Delivery queues
- Shadow queues
- Safety Net
Kalıcı kuyruk olarak geçen kuyruk tipleri aşağıdakilerdir
Submission Queue
Transport server üzerinde çalışan transport agentlar tarafından işlenen tüm maillerin kategorize edilmesi için kullanılan kuyruk tipidir. Transport sunucusuna gelen tüm mesajlar submission kuyruğunda işlenir. Mailbox server üzerinde mesaj receive connector üzerinden, pickup veya replay dizinlerinden veya Mailbox Transport Submission servisinden. Edge rolünde de mesajlar klasik olarak receive connector üzerinden ve yine pickup – replay dizinlerinden alınabilir.
Kategorize etmek temel anlamda kuyruktaki mesajların alıcısını ve bu alıcının nerede olduğunu bularak mesajı oraya iletmek olarak ifade edilebilir. Eğer alıcının yeri bulunmuş ise bu mesaj Delivery kuyruğuna, bulunamamış ise Unreachable kuyruğuna iletilir. Her transport servisi sadece bir tane submission kuyruğuna sahiptir. Bir mail submission kuyruğunda ise aynı anda diğer kuyruklarda işlenemez.
Unreachable Queue
Yönlendirilemeyen yani alıcısı bulunamayan mesajların saklandığı kuyruktur. Bu tür kuyruklar genellikle mail iletimindeki yapılandırma değişiklikleri nedeni ile görülür. Her transport servis bir adet unreachable kuyruğuna sahiptir. Bu kuyruk içerisindeki mesajlar iletim yapılandırılmasında bir değişiklik sezildiğinde tekrar delivery kuyruğuna gönderilir. Bu kuyruk genellikle boş olur ve bu durumlarda get-queue powershell komut çıktısında göremeyebilirsiniz.
Poison Message Queue
Transport sunucusu veya servisine zarar verdiği tespit edilen maillerin ortamdan izole edilmesi için kullanılan özel bir kuyruktur. Genellikle kötü içerikli kod içeren maillerin burada saklandığını görebiliriz. Bunun tespiti ise daha çok transport server üzerindeki transport agent’ ların bu maili işlerken hata alması veya işleyememesi durumlarında görülür.
Delivery Queue
SMTP protokolü tarafından yerel veya uzak bir hedefe iletilmek üzere olan maillerin saklandığı kuyruktur. Birden çok iletim kuyruğu görebilirsiniz ve aynı hedefe giden mailler genelde bir kuyruk altına toplanabilir. Örneğin şirket içerisinde 1000 çalışan ve x bir zamanda 13 kişi hotmail.com a 7 kişi gmail.com 5 kişi itstack.com.tr ye ve 50 kişi cozumpark.com a mail atar ise bu 4 domain için 4 iletim kuyruğu görebilirsiniz ve bu mailler bu kuyruk altında toplanır. Kuyruk otomatik oluşur ve yine otomatik olarak silinir. Silinme süresi varsayılan olarak 3 dakika olup Set-TransportService komut seti ile QueueMaxIdleTime parametresini kullanarak değiştirebilirsiniz.
Shadow Queue
Exchange Server’ ın mail iletiminde de yani transport seviyesinde de yüksek erişilebilirlik desteği sunabilmesi amacı ile kullanılan bir kuyruktur. Bir mail iletilirken bir kopyasının saklandığı bir kuyruk tipidir. Eğer mesajı alan bir sonraki nokta sağlıklı bir şekilde aldığını söyler ise bu kopya silinir, eğer sorun olduğu bildirilir ise bu kopya sayesinde mail tekrar iletilir. Maili alan bir sonraki sunucu ile bu bilgiyi XSHADOW sayesinde öğrenir. Ancak mail bir Exchange sunucusundan diğer bir Exchange sunucusuna yani XSHADOW destekleyen bir sunucuya değil de bu komuttan anlamayan ve doğal olarak Exchange Server’ ın beklediği cevabı veremeyen bir sunucuya gönderilmesi durumu içinde mevcut mail’ i silmek için bir delay yani bekleme ayarı vardır.
Safety NET
Transport sunucusu tarafından başarılı bir şekilde teslim edilmiş bir mailin kopyasının tutulduğu kuyruk tipidir. Temel amacı DAG mimarisinde bir transport sunucusu tarafından gönderilmiş ama henüz DAG ile replike edilmemiş olan mailleri bu transport sunucusuna bir şey olması durumunda kaybolmaması için saklandığı yerdir. Örneğin DAG nodelarından biri down oldu ve diğer MBX sunucusu ayağa kalkacak, ancak eski sunucunun kuyruğundaki mailler henüz DB seviyesinde kopyalanmadığı için Safety NET sayesinde bu yeni sunucu eksik olan mailleri otomatik olarak alır.
Kuyruk veri tabanı varsayılan olarak aşağıdaki dizinde yer alır
%ExchangeInstallPath%TransportRoles\data\Queue
Mail.que
Kuyruktaki mesajların saklandığı veri tabanı dosyasıdır.
Tmp.edb
Kuyruk veri tabanının ilk yüklenmesinde veri tabanı şemasının kontrol edilmesinde kullanılır
Trn*.log
Aktif olay günlüğüdür, yani veri tabanına yazılmadan önce gerçekleşen aktiviteler ram ve log dosyasında tutulur, daha sonra veri tabanına yazılır. Mevcut bir log dosyası maksimum boyutuna ulaşması durumunda Trn.log, Trnnnn.log şeklinde isim değiştirerek artar.
Trn.chk
Kontrol dosyası transaction log dosyalarının veri tabanına işlenmesini takip eder. Yani hangi log dosyası veri tabanına işlenmiş kontrol eder.
Trnres00001.jrs – Trnres00002.jrs
Bunlar placeholder olarak tanımlanır, yani yer kaplamak için kullanılır, diskte yer kalmadığında mevcut log dosyalarının kullanılabilmesi için sırası ile silinir.
Klasik ESE mimarisi kullanılır. Yani hızlı çalışması için gelen istekler önce RAM ve loglara sonra veri tabanına yazılır.
Checkpoint dosyası hangi log dosyasının içeriğinin veri tabanına düzgün bir şekilde yazılıp yazılmadığını kontrol eder. Log dosyaları için bir bakıma gerek yoktur çünkü bu veri tabanı için circular log açıktır.
Kuyruk veri tabanında saklama ve temizleme işlemi için “generation tables” ismini verdiğimiz tablolar kullanılır. Yani tek tek mail bazlı bir temizlik yerine saat bazlı bir tablonunun içeriğinin komple silinmesi gerçekleştirilir.
Temel çalışma mantığı, örneğin saat 1PM – 2PM arasında gelen mesajların hepsi 1p-2p_msgs tablosunda tutulur, 2PM olduktan sonra gelen mesajlar ise 2p-3p_msgs tablosun da. Bu şekilde 3p_4p_msgs tablosu şeklinde veri tabanında sürekli yeni tablolar oluşur. Mesaj silme işlemi ise örneğin 1p-2p_msgs tablosu için bu tablo içerisindeki tüm mailler başarılı bir şekilde işlenmiş ise bu tablo silinir, bu şekilde saat bazlı olarak işlenmiş ve artık kuyruk veri tabanında olmasına gerek olmayan mesajlar silinir.
Bu şekilde bireysel veya tüm mesajların silinmesinden doğacak disk I/O yükünü de düşürmektedir.
Peki, böyle bir mimari için kuyruk veri tabanı boyutları ne olmalı? Aslında bu konu çok net ifade edilebilecek bir konu değil çünkü mail sisteminizdeki en küçük anormallik kuyruk veri tabanının hızlıca büyümesine neden olabilir, ama ben yine de kağıt üzerinde olması gerekeni paylaşabilirim.
Örnek senaryoda saniyede 50KB olan 5 mail alan bir sistem için maksimum 24 saat ve 500.000 mail barındırması + %20 disk alanı için toplam gereksinim 58GB olmaktadır. Kuyruk boyutu ise 25GB olmaktadır.
Buraya kadar temel olarak Exchange Server kuyruk mimarisinden bahsettim, şimdi ise bu mimarinin en önemli oyuncusu olan kuyruk veri tabanından bahsedeceğim.
Genel olarak bu DB boyutu kontrolsüz bir şekilde büyüyebilir, bunun birkaç nedeni vardır. İlk olarak mevcut sunucularınızdaki kuyruk durumunu aşağıdaki powershell ile kontrol edebilirsiniz
Get-TransportService | Get-Queue | Measure-Object MessageCount
Eğer kuyrukta çok fazla mail var ise hali hazırda kuyruk veri tabanının büyük olması gayet normaldir. Yukarıdaki resimde 13 tane mail olduğunu görüyoruz ki bu çok küçük bir değerdir. Kuyrukta yapının büyüklüğüne göre mutlaka değişmek ile beraber 50, 100 tane mail olması olasıdır. Malum büyük şirketlerde örneğin 1000 kişi çalışan bir yerde hotmail yerine homail yazan, gmail yerine gail yazan 3 5 kişi çıksa bile onlardan 10 20 bilemediniz 30 40 tan yanlış yazılmış mail domain nedeni ile DNS çözümlemesi yapılamayan ve bu nedenle kuyrukta bekleyen mailler olur. Ama bu rakam 500, 1000 ve daha fazla ise bu durumda bir terslik var demektir.
Varsayılan olarak kuyruğunda çok mail olmamasına karşın kuyruk veri tabanı büyük olan yapılar için kontrol noktaları aşağıdaki gibidir.
Öncelikle kuyruk veri tabanının ayarlarını kontrol etmemiz gereklidir. Kuyruk veri tabanı ayarları için aşağıdaki dosyayı inceleyebiliriz
%ExchangeInstallPath%Bin\EdgeTransport.exe.config
Not: bu dosya üzerindeki değişikliklerin geçerli olması için lütfen Microsoft Exchange Transport service yeniden başlatın.
Burada kuyruk veri tabanı ile başlayan tüm ayarlar kuyruk veri tabanını ilgilendiren ayarladır.
Daha fazla ayar ve açıklama için Technet referans linkini kullanabilirsiniz
https://technet.microsoft.com/en-us/library/bb125022(v=exchg.150).aspx
Ben daha çok günlük hayatta özellikle kuyruk veri tabanı boyutunun etkileyecek olan ayarları detaylandıracağım.
QueueDatabaseMaxBackgroundCleanupTasks
Eğer kuyruk veri tabanı boyutu hızlı olarak büyüyor ise, ama bu nokta önemli hali hazırda zaten boyutu yüksek ise değil hızlı olarak büyüyor ise bu temizleme işleminin kuyruklama işleminden yavaş kaldığını gösterir ki o zaman bu değeri 32 den 64 e çıkarıp bir gün bekleyebilirsiniz, bunun sonucunda veri tabanındaki büyüme hızının düşmesi beklenir, ama küçülmez.
QueueDatabaseOnlineDefragSchedule
Varsayılan olarak açık gelen online birleştirme işlemi için gece 1:00:00 da başlaması için bir ayar vardır. Bu ayarı eğer veri tabanı boyutununz büyük ise 18:00:00 şeklinde değiştirebilirsiniz. Bu sayede mesai sonrasında defrag işlemi başlar.
QueueDatabaseOnlineDefragTimeToRun
Bu değer ise varsayılan olarak 3 olup online defrag işleminin başlamasından sonra kaç saat çalışacağını gösterir. Bunu da 12 yaparak sabah 06 ya kadar online defrag işlemi yaptırabilirsiniz.
Diğer kontrol noktaları ise aşağıdaki gibidir
Get-TransportServer “Postaci” |fl *pipe*
Eğer true ise bunu aşağıdaki komut ile kapatıyoruz
Set-TransportServer Postaci -PipelineTracingEnabled $False
Bu veri tabanının büyümesini tetikleyen bir izleme özelliğidir.
Sonra ise aşağıdaki komut ile Config dosyası incelenir
Get-TransportConfig
MaxDumpsterSizePerStorageGroup değerki MB olmalı, GB değil. Ek olarak
MaxDumpsterTime : 7.00:00:00
Değeri 7 değil ise bunu 7 gün yapmalı,
Get-TransportConfig | fl *dump*
Eğer farklı ise yukarıdaki varsayılan değerlere çekiniz
Set-TransportConfig -MaxDumpsterSizePerStorageGroup <size> -MaxDumpsterTime <timespan>
Not: bu değerler şirket ihtiyaçlarına göre değişir. Yani 7 gün pek çok kurum için yeterli bir süredir, ancak 18MB günümüz ihtiyaçlarında 50MB olabilir. Bunu belirlerken o kurumun mail almak veya göndermek için belirlediği en üst sınırı sizde referans alabilirsiniz. Yani bir seferde 50bm lık bir mail alabiliyor ve gönderebiliyor ise sistem lütfen bu değeri minimum 50MB + %30 yapın.
Kuyruk veri tabanının boyutlarının büyük olmasının bir nedeni de Transport Agent olabilir. Özellikle Exchange server üzerinde kurulu olan bir Anti Virus, Anti Spam ürünü var ise bunu transport seviyesinde kapatıp birkaç gün büyüme trendini izleyerek çözebilirsiniz.
Bir diğer önerim ise internal spam mailler olacaktır, muhtemel dışarıdan gelen spam maillere karşı önleminiz vardır, ama yok ise zaten sürekli olarak spam yiyen bir Exchange server kuyruk veri tabanı hızlı şişer bu normal bir durum, ancak büyük kurumlardaki anti spam çözümleri buna izin vermez. Ama yine bu büyük kurumlarda 500, 1000 ve üzeri kullanıcılar olduğu için içerideki spam konularına da dikkat etmeniz gereklidir. Bu nedenle önerim Promodag ve benzeri bir Reporter ürünü alıp haftalık olarak rapor çekmeniz ve internal spamcıları bulmanızdır.
Mail alma ve gönderme limitleriniz yine 50mb ve benzeri ise db boyutunun hızlı büyümesi normaldir. Tabiki bunları takip etmenin en iyi yolu öncelikle mevcut db yi bir sıfırlamak ve yukarıdaki adımları sağlıklı olarak takip etmek.
Kuyruk veri tabanının boyutunun büyümesindeki bir diğer faktör ise Safety NET özelliğidir. Bunu makalemin başında açıklamıştım. Mail kaybı olmaması için kullanılan bu özellikle gerek Primary Safety NET gerekse bunu yedeği olan sunucu da mailler 2 + 2 toplam 4 gün saklanır. Bunun en temel nedeni ise ulaştırılamayan bir mail zaten 2 günün sonunda kullanıcıya NDR mesajı olarak geri gönderilir. Ama bu gönderilen maillerin bir kopyasının iki gün sunucularda tutulması büyük yapılar için ciddi bir yük oluşturur, bu nedenle buradaki tavsiyem aşağıdaki iki komut ile bu süreyi bir güne düşürmeniz olacaktır.
Set-TransportConfig -SafetyNetHoldTime 1.00:00:00
Get-TransportService | Set-TransportService -MessageExpirationTimeout 1.00:00:00″
Not: SafetyNetHoldtime değeri, organizasyondaki ReplayLagTime değerine eşit veya büyük olmalıdır.
Eğer transport queue db boyutu tüm bunlara rağmen düşmüyor ise mevcut kuyruk veri tabanını sıfırlamanız en iyi yöntemlerden biri olacaktır. Tek sunuculu bir ortamda iseniz Microsoft Exchange Transport service önce pause yapın, sonra maillerin sıfır olmasını bekleyin ve servisini durdurun. Daha sonra eski veri tabanının ismini veya lokasyonunu değiştirin ve servisi tekrar başlatın, bu sayede yeni bir veri tabanı ile devam etmiş olursunuz. Birden çok sunucu ve DAG olan ortamlarda bu işlemi yapabilirsiniz ancak burada son bir günlük veya ayarı değiştirmediyseniz varsayılan olarak iki günlük safety NET içeriğini kaybetmiş olacaksınız. Bunu kaybetmeden bu işlemi yapmak için DAG node larını teker teker boşa çıkarın, yani bir node üzerindeki tüm kullanıcıları diğer node’ a taşıyın, daha sonra kuyruğu izleyin ve hiç mail alınmadığını kontrol edin ( HealthMailbox gönderimlerini önemsemeyin ). Ardından 1 gün bekledikten sonra bu işlemi gerçekleştirin. Daha sonra tüm posta kutularını bu sunucu üzerine alıp sırası ile diğer sunucularında kuyruk veri tabanlarını temizleyebilirsiniz.
Kaynaklar
https://technet.microsoft.com/en-us/library/bb125022%28v=exchg.150%29.aspx#QueueDBFiles
https://technet.microsoft.com/en-us/library/aa997263%28v=exchg.150%29.aspx
https://msexchangeguru.com/2011/06/02/mail-que/
https://jaapwesselius.com/2014/03/05/move-transport-database-in-exchange-2013/
https://technet.microsoft.com/en-us/library/bb738141(v=exchg.80).aspx
https://technet.microsoft.com/en-us/library/aa998047(v=exchg.150).aspx
