Queue – kuyruk, genel olarak pek çok teknoloji ürününde kullanilan bir kavramdir. Exchange Server mimarisinde de pek çok sistem yöneticisinin yakindan bildigi ve zaman zaman sorun yasadigi basliklardan birisidir. Temel olarak bir mesajin hedefine ulasmak için geçici olarak bekledigi alan olarak ifade edebiliriz. Mesaj iletilmeden önce, iletilme sirasinda ve iletildikten sonra kuyrukta saklanir ( detayli olarak makalenin ilerleyen bölümlerinde açiklanacaktir). Her mailbox ve Edge rolünde ( Exchange 2010 için Hub transport ve Edge ) yer alan bir veri tabanidir. Özetle transport sunucularinda yer alan bir veri tabanidir. Ayni maillerin saklandigi Exchange Server Mailbox Database gibi Queue Database de yer almaktadir. ( Her ikisi de Extensible Storage Engine (ESE) mimarisini kullanir)
Exchange Server 2013 için kuyruk tipleri asagidaki gibidir;
1. Persistent queues
· Submission queue
· Unreachable queue
· Poison message queue
2. Delivery queues
3. Shadow queues
4. Safety Net
Kalici kuyruk olarak geçen kuyruk tipleri asagidakilerdir
Submission Queue
Transport server üzerinde çalisan transport agentlar tarafindan islenen tüm maillerin kategorize edilmesi için kullanilan kuyruk tipidir. Transport sunucusuna gelen tüm mesajlar submission kuyrugunda islenir. 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 alinabilir.
Kategorize etmek temel anlamda kuyruktaki mesajlarin alicisini ve bu alicinin nerede oldugunu bularak mesaji oraya iletmek olarak ifade edilebilir. Eger alicinin yeri bulunmus ise bu mesaj Delivery kuyruguna, bulunamamis ise Unreachable kuyruguna iletilir. Her transport servisi sadece bir tane submission kuyruguna sahiptir. Bir mail submission kuyrugunda ise ayni anda diger kuyruklarda islenemez.
Unreachable Queue
Yönlendirilemeyen yani alicisi bulunamayan mesajlarin saklandigi kuyruktur. Bu tür kuyruklar genellikle mail iletimindeki yapilandirma degisiklikleri nedeni ile görülür. Her transport servis bir adet unreachable kuyruguna sahiptir. Bu kuyruk içerisindeki mesajlar iletim yapilandirilmasinda bir degisiklik sezildiginde tekrar delivery kuyruguna gönderilir. Bu kuyruk genellikle bos olur ve bu durumlarda get-queue powershell komut çiktisinda göremeyebilirsiniz.
Poison Message Queue
Transport sunucusu veya servisine zarar verdigi tespit edilen maillerin ortamdan izole edilmesi için kullanilan özel bir kuyruktur. Genellikle kötü içerikli kod içeren maillerin burada saklandigini görebiliriz. Bunun tespiti ise daha çok transport server üzerindeki transport agent’ larin bu maili islerken hata almasi veya isleyememesi durumlarinda görülür.
Delivery Queue
SMTP protokolü tarafindan yerel veya uzak bir hedefe iletilmek üzere olan maillerin saklandigi kuyruktur. Birden çok iletim kuyrugu görebilirsiniz ve ayni hedefe giden mailler genelde bir kuyruk altina toplanabilir. Örnegin sirket içerisinde 1000 çalisan ve x bir zamanda 13 kisi hotmail.com a 7 kisi gmail.com 5 kisi IT Stack.com.tr ye ve 50 kisi cozumpark.com a mail atar ise bu 4 domain için 4 iletim kuyrugu görebilirsiniz ve bu mailler bu kuyruk altinda toplanir. Kuyruk otomatik olusur ve yine otomatik olarak silinir. Silinme süresi varsayilan olarak 3 dakika olup Set-TransportService komut seti ile QueueMaxIdleTime parametresini kullanarak degistirebilirsiniz.
Shadow Queue
Exchange Server’ in mail iletiminde de yani transport seviyesinde de yüksek erisilebilirlik destegi sunabilmesi amaci ile kullanilan bir kuyruktur. Bir mail iletilirken bir kopyasinin saklandigi bir kuyruk tipidir. Eger mesaji alan bir sonraki nokta saglikli bir sekilde aldigini söyler ise bu kopya silinir, eger sorun oldugu bildirilir ise bu kopya sayesinde mail tekrar iletilir. Maili alan bir sonraki sunucu ile bu bilgiyi XSHADOW sayesinde ögrenir. Ancak mail bir Exchange sunucusundan diger bir Exchange sunucusuna yani XSHADOW destekleyen bir sunucuya degil de bu komuttan anlamayan ve dogal olarak Exchange Server’ in bekledigi cevabi veremeyen bir sunucuya gönderilmesi durumu içinde mevcut mail’ i silmek için bir delay yani bekleme ayari vardir.
Safety NET
Transport sunucusu tarafindan basarili bir sekilde teslim edilmis bir mailin kopyasinin tutuldugu kuyruk tipidir. Temel amaci DAG mimarisinde bir transport sunucusu tarafindan gönderilmis ama henüz DAG ile replike edilmemis olan mailleri bu transport sunucusuna bir sey olmasi durumunda kaybolmamasi için saklandigi yerdir. Örnegin DAG nodelarindan biri down oldu ve diger MBX sunucusu ayaga kalkacak, ancak eski sunucunun kuyrugundaki mailler henüz DB seviyesinde kopyalanmadigi için Safety NET sayesinde bu yeni sunucu eksik olan mailleri otomatik olarak alir.
Kuyruk veri tabani varsayilan olarak asagidaki dizinde yer alir
%ExchangeInstallPath%TransportRoles\data\Queue
Mail.que
Kuyruktaki mesajlarin saklandigi veri tabani dosyasidir.
Tmp.edb
Kuyruk veri tabaninin ilk yüklenmesinde veri tabani semasinin kontrol edilmesinde kullanilir
Trn*.log
Aktif olay günlügüdür, yani veri tabanina yazilmadan önce gerçeklesen aktiviteler ram ve log dosyasinda tutulur, daha sonra veri tabanina yazilir. Mevcut bir log dosyasi maksimum boyutuna ulasmasi durumunda Trn.log, Trnnnn.log seklinde isim degistirerek artar.
Trn.chk
Kontrol dosyasi transaction log dosyalarinin veri tabanina islenmesini takip eder. Yani hangi log dosyasi veri tabanina islenmis kontrol eder.
Trnres00001.jrs – Trnres00002.jrs
Bunlar placeholder olarak tanimlanir, yani yer kaplamak için kullanilir, diskte yer kalmadiginda mevcut log dosyalarinin kullanilabilmesi için sirasi ile silinir.
Klasik ESE mimarisi kullanilir. Yani hizli çalismasi için gelen istekler önce RAM ve loglara sonra veri tabanina yazilir.
Checkpoint dosyasi hangi log dosyasinin içeriginin veri tabanina düzgün bir sekilde yazilip yazilmadigini kontrol eder. Log dosyalari için bir bakima gerek yoktur çünkü bu veri tabani için circular log açiktir.
Kuyruk veri tabaninda saklama ve temizleme islemi için “generation tables” ismini verdigimiz tablolar kullanilir. Yani tek tek mail bazli bir temizlik yerine saat bazli bir tablonunun içeriginin komple silinmesi gerçeklestirilir.
Temel çalisma mantigi, örnegin saat 1PM – 2PM arasinda gelen mesajlarin hepsi 1p-2p_msgs tablosunda tutulur, 2PM olduktan sonra gelen mesajlar ise 2p-3p_msgs tablosun da. Bu sekilde 3p_4p_msgs tablosu seklinde veri tabaninda sürekli yeni tablolar olusur. Mesaj silme islemi ise örnegin 1p-2p_msgs tablosu için bu tablo içerisindeki tüm mailler basarili bir sekilde islenmis ise bu tablo silinir, bu sekilde saat bazli olarak islenmis ve artik kuyruk veri tabaninda olmasina gerek olmayan mesajlar silinir.
Bu sekilde bireysel veya tüm mesajlarin silinmesinden dogacak disk I/O yükünü de düsürmektedir.
Peki, böyle bir mimari için kuyruk veri tabani boyutlari ne olmali? Aslinda bu konu çok net ifade edilebilecek bir konu degil çünkü mail sisteminizdeki en küçük anormallik kuyruk veri tabaninin hizlica büyümesine neden olabilir, ama ben yine de kagit üzerinde olmasi gerekeni paylasabilirim.
Örnek senaryoda saniyede 50KB olan 5 mail alan bir sistem için maksimum 24 saat ve 500.000 mail barindirmasi + %20 disk alani için toplam gereksinim 58GB olmaktadir. Kuyruk boyutu ise 25GB olmaktadir.
Buraya kadar temel olarak Exchange Server kuyruk mimarisinden bahsettim, simdi ise bu mimarinin en önemli oyuncusu olan kuyruk veri tabanindan bahsedecegim.
Genel olarak bu DB boyutu kontrolsüz bir sekilde büyüyebilir, bunun birkaç nedeni vardir. Ilk olarak mevcut sunucularinizdaki kuyruk durumunu asagidaki powershell ile kontrol edebilirsiniz
Get-TransportService | Get-Queue | Measure-Object MessageCount
Eger kuyrukta çok fazla mail var ise hali hazirda kuyruk veri tabaninin büyük olmasi gayet normaldir. Yukaridaki resimde 13 tane mail oldugunu görüyoruz ki bu çok küçük bir degerdir. Kuyrukta yapinin büyüklügüne göre mutlaka degismek ile beraber 50, 100 tane mail olmasi olasidir. Malum büyük sirketlerde örnegin 1000 kisi çalisan bir yerde hotmail yerine homail yazan, gmail yerine gail yazan 3 5 kisi çiksa bile onlardan 10 20 bilemediniz 30 40 tan yanlis yazilmis mail domain nedeni ile DNS çözümlemesi yapilamayan ve bu nedenle kuyrukta bekleyen mailler olur. Ama bu rakam 500, 1000 ve daha fazla ise bu durumda bir terslik var demektir.
Varsayilan olarak kuyrugunda çok mail olmamasina karsin kuyruk veri tabani büyük olan yapilar için kontrol noktalari asagidaki gibidir.
Öncelikle kuyruk veri tabaninin ayarlarini kontrol etmemiz gereklidir. Kuyruk veri tabani ayarlari için asagidaki dosyayi inceleyebiliriz
%ExchangeInstallPath%Bin\EdgeTransport.exe.config
Not: bu dosya üzerindeki degisikliklerin geçerli olmasi için lütfen Microsoft Exchange Transport service yeniden baslatin.
Burada kuyruk veri tabani ile baslayan tüm ayarlar kuyruk veri tabanini ilgilendiren ayarladir.
Daha fazla ayar ve açiklama 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 tabani boyutunun etkileyecek olan ayarlari detaylandiracagim.
QueueDatabaseMaxBackgroundCleanupTasks
Eger kuyruk veri tabani boyutu hizli olarak büyüyor ise, ama bu nokta önemli hali hazirda zaten boyutu yüksek ise degil hizli olarak büyüyor ise bu temizleme isleminin kuyruklama isleminden yavas kaldigini gösterir ki o zaman bu degeri 32 den 64 e çikarip bir gün bekleyebilirsiniz, bunun sonucunda veri tabanindaki büyüme hizinin düsmesi beklenir, ama küçülmez.
QueueDatabaseOnlineDefragSchedule
Varsayilan olarak açik gelen online birlestirme islemi için gece 1:00:00 da baslamasi için bir ayar vardir. Bu ayari eger veri tabani boyutununz büyük ise 18:00:00 seklinde degistirebilirsiniz. Bu sayede mesai sonrasinda defrag islemi baslar.
QueueDatabaseOnlineDefragTimeToRun
Bu deger ise varsayilan olarak 3 olup online defrag isleminin baslamasindan sonra kaç saat çalisacagini gösterir. Bunu da 12 yaparak sabah 06 ya kadar online defrag islemi yaptirabilirsiniz.
Diger kontrol noktalari ise asagidaki gibidir
Get-TransportServer “Postaci” |fl *pipe*
Eger true ise bunu asagidaki komut ile kapatiyoruz
Set-TransportServer Postaci -PipelineTracingEnabled $False
Bu veri tabaninin büyümesini tetikleyen bir izleme özelligidir.
Sonra ise asagidaki komut ile Config dosyasi incelenir
Get-TransportConfig
MaxDumpsterSizePerStorageGroup degerki MB olmali, GB degil. Ek olarak
MaxDumpsterTime : 7.00:00:00
Degeri 7 degil ise bunu 7 gün yapmali,
Get-TransportConfig | fl *dump*
Eger farkli ise yukaridaki varsayilan degerlere çekiniz
Set-TransportConfig -MaxDumpsterSizePerStorageGroup <size> -MaxDumpsterTime <timespan>
Not: bu degerler sirket ihtiyaçlarina göre degisir. Yani 7 gün pek çok kurum için yeterli bir süredir, ancak 18MB günümüz ihtiyaçlarinda 50MB olabilir. Bunu belirlerken o kurumun mail almak veya göndermek için belirledigi en üst siniri sizde referans alabilirsiniz. Yani bir seferde 50bm lik bir mail alabiliyor ve gönderebiliyor ise sistem lütfen bu degeri minimum 50MB + %30 yapin.
Kuyruk veri tabaninin boyutlarinin büyük olmasinin bir nedeni de Transport Agent olabilir. Özellikle Exchange server üzerinde kurulu olan bir Anti Virus, Anti Spam ürünü var ise bunu transport seviyesinde kapatip birkaç gün büyüme trendini izleyerek çözebilirsiniz.
Bir diger önerim ise internal spam mailler olacaktir, muhtemel disaridan gelen spam maillere karsi önleminiz vardir, ama yok ise zaten sürekli olarak spam yiyen bir Exchange server kuyruk veri tabani hizli siser 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 kullanicilar oldugu için içerideki spam konularina da dikkat etmeniz gereklidir. Bu nedenle önerim Promodag ve benzeri bir Reporter ürünü alip haftalik olarak rapor çekmeniz ve internal spamcilari bulmanizdir.
Mail alma ve gönderme limitleriniz yine 50mb ve benzeri ise db boyutunun hizli büyümesi normaldir. Tabiki bunlari takip etmenin en iyi yolu öncelikle mevcut db yi bir sifirlamak ve yukaridaki adimlari saglikli olarak takip etmek.
Kuyruk veri tabaninin boyutunun büyümesindeki bir diger faktör ise Safety NET özelligidir. Bunu makalemin basinda açiklamistim. Mail kaybi olmamasi için kullanilan bu özellikle gerek Primary Safety NET gerekse bunu yedegi olan sunucu da mailler 2 + 2 toplam 4 gün saklanir. Bunun en temel nedeni ise ulastirilamayan bir mail zaten 2 günün sonunda kullaniciya NDR mesaji olarak geri gönderilir. Ama bu gönderilen maillerin bir kopyasinin iki gün sunucularda tutulmasi büyük yapilar için ciddi bir yük olusturur, bu nedenle buradaki tavsiyem asagidaki iki komut ile bu süreyi bir güne düsürmeniz olacaktir.
Set-TransportConfig -SafetyNetHoldTime 1.00:00:00
Get-TransportService | Set-TransportService -MessageExpirationTimeout 1.00:00:00″
Not: SafetyNetHoldtime degeri, organizasyondaki ReplayLagTime degerine esit veya büyük olmalidir.
Exchange Server 2016 için komutlar asagidaki gibidir;
Exchange 2016
Set-TransportConfig -SafetyNetHoldTime 1.00:00:00
Get-TransportConfig | Set-TransportConfig -ShadowMessageAutoDiscardInterval 1.00:00:00
Eger transport queue db boyutu tüm bunlara ragmen düsmüyor ise mevcut kuyruk veri tabanini sifirlamaniz en iyi yöntemlerden biri olacaktir. Tek sunuculu bir ortamda iseniz Microsoft Exchange Transport service önce pause yapin, sonra maillerin sifir olmasini bekleyin ve servisini durdurun. Daha sonra eski veri tabaninin ismini veya lokasyonunu degistirin ve servisi tekrar baslatin, bu sayede yeni bir veri tabani ile devam etmis olursunuz. Birden çok sunucu ve DAG olan ortamlarda bu islemi yapabilirsiniz ancak burada son bir günlük veya ayari degistirmediyseniz varsayilan olarak iki günlük safety NET içerigini kaybetmis olacaksiniz. Bunu kaybetmeden bu islemi yapmak için DAG node larini teker teker bosa çikarin, yani bir node üzerindeki tüm kullanicilari diger node’ a tasiyin, daha sonra kuyrugu izleyin ve hiç mail alinmadigini kontrol edin ( HealthMailbox gönderimlerini önemsemeyin ). Ardindan 1 gün bekledikten sonra bu islemi gerçeklestirin. Daha sonra tüm posta kutularini bu sunucu üzerine alip sirasi ile diger sunucularinda kuyruk veri tabanlarini 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
http://msexchangeguru.com/2011/06/02/mail-que/
http://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