Exchange Server Mailbox Database Mimarisi

Exchange Server Mailbox Database Mimarisi, Microsoft Exchange Server ortamlarında veri bütünlüğü, performans ve ölçeklenebilirlik açısından kritik bir rol oynamaktadır ve Sistem yöneticileri için sağlıklı bir mesajlaşma altyapısının temel yapı taşlarından biridir.

Bu mimari, ESE (Extensible Storage Engine – Genişletilebilir Depolama Birimi) altyapısı ile tasarlanmıştır. Daha önce Exchange’in kullandığı log mimarileri kapsamında ESE yapısını sizlere paylaşmıştık.

Bu yazımızda, Exchange Server Mailbox Database Mimarisi başlığı altında aşağıdaki başlıkları detaylarıyla inceleyeceğiz.

1. Extensible Storage Engine Nedir?

Extensible Storage Engine (ESE), verileri mantıksal bir sırayla depolayan gelişmiş bir veritabanı motorudur. Verilere, sıralı olarak ya da tanımlanmış dizinler aracılığıyla erişilebilir. Veritabanı üzerindeki her güncelleme, güvenli işlem yönetimi sağlamak amacıyla bir işlem (transaction) kapsamında gerçekleştirilir.

ESE, işlem günlüğü (log) dosyaları da dâhil olmak üzere birden fazla veritabanına eşzamanlı erişim imkânı sunar ve bu sayede sistem kurtarma süreçlerinde de aktif rol oynar.

Hem küçük hem de büyük ölçekli uygulamalar için kullanılabilen ESE, zengin özelliklere sahip bir uygulama programlama arayüzü (API) ile birlikte çalışmaktadır. Bu yapı; yedekleme, çevrim içi veri koruma ve veri tutarlılığı sağlanarak yedekten geri yükleme gibi işlemler sırasında sistemin kararlı kalmasına olanak tanır.

#exchange server logging etiketi ile paylaşmış olduğumuz makaleler için de anlattığımız gibi Exchange Server ‘in kullanmış olduğu bir çok veri tabanı ESE (Extensible Storage Engine) üzerine tasarlanmıştır ve Exchange Server Mailbox Database Mimarisi ‘de bu mimari üzerinde çalışmaktadır.

2. Exchange Server Database

Microsoft Exchange Server Mailbox Database mimarisi, e-posta, takvim, kişiler ve diğer iş birliği verilerini yönetmek için kullanılan bir yapıdır. Microsoft Exchange Server Role Konsalidasyon süreci ile birlikte artık her bir Exchange Server aynı zaman da Exchange Mailbox Server durumundadır ve sahip oldukları bir database bulunmaktadır.

Bizler yeni bir Exchange Server kurulum işlemini yaptığımız zaman bu kurulum ile birlikte Exchange Mailbox Server üzerinde Exchange Server default database ‘de oluşur. Eğer bir organizasyona ilk defa bir Exchange Server kurulumu yapıyorsak ilk default database içinde de Exchange Server Arbitration Mailbox ‘ları oluşur ve bu mailboxlar da Exchange Server ‘in system mailboxlarıdır ve Microsoft Exchange Server Mailbox Database mimarisi içinde e-posta, takvim, kişiler ve diğer iş birliği verilerini yönetmek için kullanılan toplusal bir yapıdır

Temelde Extensible Storage Engine (ESE) olarak adlandırılan veritabanı yönetim sistemi üzerine kuruludur ve Jet Blue olarak da bilinir. Exchange Server’ın veri depolama yapısı, Mailbox Database ve Transactional Log Files olmak üzere iki temel bileşene ayrılır.

2.1 Mailbox Database (EDB Dosyaları)

• Veri Depolama: Tüm e-postalar, takvimler, görevler ve kişiler burada saklanır.
• ESE (Extensible Storage Engine): Exchange’in veritabanı motorudur. Esnek ve yüksek performanslı bir yapı sunar.
• Single Instance Storage (SIS) Kaldırıldı: Exchange 2010 öncesinde aynı e-posta birden fazla kullanıcıya gönderildiğinde tek kopyası tutulurdu. Ancak modern Exchange sürümlerinde bu kaldırıldı.
• Mailbox Database Partitioning: Exchange, veritabanlarını mantıksal bölümlere ayırarak büyük ölçekli kullanımda performans artırır.

Örnek Mailbox Database Dosyaları aşağıdaki gibidir.

• .edb – Asıl veritabanı dosyasıdır.
• .stm – (Eski sürümlerde) akış verilerini içerirdi.
• .chk – Checkpoint dosyasıdır, loglardan hangi verilerin veritabanına işlendiğini takip eder.

2.2 Transaction Log Files (Log Dosyaları)

• Öncelikli Veri Kaydı: Veritabanına işlenmeden önce tüm işlemler öncelikle log dosyalarına yazılır.
• Log Dosyalarının Dönüştürülmesi: Eğer bir çökme olursa, sistem loglardan verileri yeniden oluşturarak veri kaybını önler.
• Circular Logging: Log dosyalarının aşırı büyümesini önlemek için kullanılır. Ancak sağlıklı bir yedekleme alt yapısına sahipsek, kapatılması önerilmez

Örnek Log Dosyaları:

• E00.log – Mevcut işlem gören log dosyasıdır.
• E0000000001.log – Eski log dosyaları.
• E00.chk – Checkpoint dosyası.

2.3. Database Availability Group (DAG)

Database Availability Group mimarisi Exchange Server için High Availability (Yüksek Erişilebilirlik) alt yapısıdır. Birden fazla Exchange Server arasında otomatik eşitleme sağlayarak veri kaybını önler.

• Active-Passive Replica Modeli: Bir sunucu aktif çalışırken, diğerleri yedek olarak bekler.
• Automatic Failover: Sunucu çökmesi durumunda diğer sunucular devreye girer.
• Multiple Database Copies: Mailbox veritabanının birden fazla kopyası saklanabilir

2.4. Content Indexing & Search

Microsoft Exchange Server Mailbox Database mimarisi, büyük ölçekli kurumsal e-posta sistemlerini desteklemek için optimize edilmiştir. ESE veritabanı, transaction log sistemi, DAG mimarisi ve indexleme gibi bileşenler sayesinde yüksek erişilebilirlik ve veri güvenliği sağlar.

3. Exchange Server Database Bakım Önerileri

Exchange Server Database bakım işlemleri, sistemin stabil çalışmasını sağlamak, performansı artırmak ve veri kaybını önlemek için düzenli olarak yapılmalıdır. Bakım işlemleri genel olarak önleyici bakım (proaktif bakım) ve onarım odaklı bakım (reaktif bakım) olmak üzere ikiye ayrılır.

Exchange Server Database Bakım İşlemleri Exchange veritabanının sağlıklı çalışması için düzenli olarak aşağıdaki işlemler yapılmalıdır:

3.1 Online Maintenance (Çevrimiçi Bakım)

Exchange Server, veritabanı üzerindeki bazı bakım işlemlerini otomatik olarak arka planda gerçekleştirir:

Exchange Server Database Bakım işlemleri varsayılan değerde her bir database için gece yarısı yapmaktadır ve bu zaman dilimini her bir Exchange Database üzerinde Maintenance sekmesinden Maintenance Schedule bölümünden değiştirebilirsiniz.

• Veri temizleme: Boş alanları optimize eder.
• Index Güncellemeleri: Arama performansını artırır.
• Log Temizleme: Artık kullanılmayan transaction log dosyalarını yönetir.
• Veri bütünlüğü kontrolü: Bozulmuş sayfaları belirleyerek sistemin sağlıklı çalışmasını sağlar.

Online bakım, varsayılan olarak her gece belirlenen zaman diliminde çalışır. Exchange Management Shell (EMS) üzerinden şu komutla kontrol edebilirsin:

3.2 Offline Maintenance (Çevrimdışı Bakım)

Offline bakım işlemleri, büyük sorunlar yaşanmadan önce veya büyük bir güncelleme öncesinde yapılmalıdır.

Exchange Server Mailbox Database üzerinde yapılan Offline Defragmentation (Çevrimdışı Boşluk Sıkıştırma), veri tabanında gereksiz yere kullanılan boş alanları temizlemek ve fiziksel boyutunu küçültmek için yapılan bir işlemdir.

Exchange Server,otomatik olarak veritabanı boyutunu küçültmez! Mailbox veya e-postalar silindiğinde, bu alan boş (white space) olarak işaretlenir ama veritabanı fiziksel olarak küçülmez.

Yukarıda paylaşmış olduğum Eseutil /D komutu kullanılarak boş alanlar kaldırılır ve veritabanı sıkıştırılır. Fakat bu işlem için Exchange Mailbox Database ‘nin dismount olması gerekmektedir ve hizmet kesintisi sonrasında oluşur. Bu işlemin süresi de Exchange Mailbox Database boyutuna bağlı olarak değişeceği için çok fazla önerilen bir çalışma değildir.

Exchange Mailbox Database Offline Defragmentation makalesi içinde daha detaylı bilgilere sahip olabilirsiniz.

3.2.1 Veritabanı Tutarlılık Kontrolü (Integrity Check)

Exchange Server üzerinde Eseutil aracı ile Exchange Server Database ‘leri için bütünlük kontrolü yapabilirsiniz.

• Eğer “Clean Shutdown” görüyorsan, veritabanı sağlıklı.
• Eğer “Dirty Shutdown” varsa, tamir işlemi gerekmektedir.

Exchange Server Database üzerinde Eseutil aracı ile çalıştırmış olduğunuz Integrity Check işleminde Database üzerinde Dirty Shutdown mührünü görüyorsanız yapmanız Exchange Database Repair yani veri tabanı onarım işlemini yapmanız gerekmektedir.

Exchange Database Repair işlemi içinde Eseutil aracı kullanılmakta ve soft repair ve hard repair olmak üzere iki farklı onarım işlemini kapsamaktadır.

3.2.1.1 Exchange Database Eseutil Soft Recovery

Bozuk bir Exchange Database onarmak için ilk olarak Yumuşak Onarım (Soft Recovery – Loglardan Geri Yükleme) yapmanız önerilmektedir.

3.2.1.2 Exchange Database Eseutil Hard Recovery

Bozuk bir Exchange Database onarmak için ilk olarak Yumuşak Onarım (Soft Recovery – Loglardan Geri Yükleme) yaptınız fakat bu işlem başarısız sonuçlandı. Bu durumda hard recovery işlemini tercih etmeniz gerekmektedir.

Hard recovery işlemi veri kaybına neden olabilir. Öncesinde mutlaka yedek alınmalı!

3.3 Transaction Log Yönetimi

Exchange Server, veritabanındaki tüm işlemleri önce transaction loglarına kaydeder. Gereksiz log dosyalarının birikmesi disk doluluğuna neden olabilir. Log temizliği için en iyi yöntem:

• Tam bir yedekleme almak (Bu, eski logları otomatik olarak temizler ve önerilen çözümdür)
• Circular Logging’i etkinleştirmek (Ancak bu yöntem felaket kurtarma işlemlerini zorlaştırabilir!)

Circular Logging’i etkinleştirmek için aşağıda ki komutu her bir Exchange Database özelinde çalıştırmalısınız.

Exchange Database ‘i Exchange DAG Cluster kümesinde eşitleme yapacaksanız Circular Logging özelliği aktif durumdaysa bunu yapamazsınız.  Circular Logging özelliğini kapatıp kullanacaksanız tekrardan açmanız gerekmektedir.

Exchange Server Mailbox Database Circular Logging makalesi hakkında detaylı bilgi için paylaşılan makaleye erişebilirsiniz.

3.4. Mailbox Boyut Yönetimi

Exchange Server üzerinde barınan Çok büyük mailbox’lar performansı olumsuz etkileyecektir. Kullanıcı başına kota ayarlamak sistem performansını artıracaktır. Unlimited Mailbox ‘lar kullanmalısınız.

Exchange Mailbox Database boyutu kullanıcı mailbox boyutu ile ilgili olduğu gibi aynı zaman da Exchange Mailbox Database içinde bulunan Mailbox Sayısı ile de orantılıdır.

Exchange Server organizasyonu içinde bulunan mailbox boyutlarını belirlerken, sınırlar koyarken aslında arka tarafta Exchange Mailbox Database veri tabanının EDB dosya boyutunun da büyüyeceği limiti belirlemiş olmaktayız.

User Mailbox boyutlarını sınırlarken aynı zaman da Exchange Mailbox Database içinde bulunan Mailbox sayısını da bilmemiz bu sınırlamayı yaparken bizlere yardımcı olacaktır.

Yukarıda paylaşmış olduğum Exchange Management Shell ile bir Exchange Mailbox Database içinde kaç adet mailbox olduğunu görebilmekte ve böylece boyut sınırlamaları yaparken bu sayıları referans alabiliriz.

Bu komut ise Exchange Server Organizasyonu içinde bulunan her bir kullanıcının sahip olduğu posta kutu boyutunu bizlere söylemektedir.

3.5 Exchange Database Bakımı İçin Önerileri Özet

• Düzenli yedekleme al! – Tam yedek almak logları temizler ve sistemin güvenliğini artırır.
• DAG (Database Availability Group) kullan! – Sunucu çökmelerinde veri kaybını önler.
• Disk kullanımını izle! – Log dosyaları çok büyüyorsa, yedeklemeleri kontrol et.
• Mailbox boyutlarını sınırla! – Kullanıcıların büyük mail kutuları oluşturmasına izin verme.
• Veritabanı bütünlüğünü kontrol et! – Eseutil ile periyodik olarak durum kontrolü yap.

Exchange Server Database’in sağlıklı çalışması için otomatik bakım işlemleri yeterli olsa da, düzenli offline bakım ve izleme yapmak olası sorunları önler. Özellikle yedekleme stratejisi en kritik konudur.