Exchange Server DAG Yapısında Manual DB Seeding

Kısa süre önce bir müşterimiz için uyguladığımız çözüm eminim aynı veya benzer durum ile karşılaşan birçok kişinin işine yarayacaktır.

Aynı subnet/lokasyon içinde Mailbox Database’lerinin yüksek erişilebilirliğini (high availability) arttırmak, farklı subnet/lokasyonlar arasında ise site esnekliği/dayanıklılığı (site resilience) sağlamak için kullanılan DAG (Database Availability Group) yapısı, Exchange Server organizasyonlarının vaz geçilmez bir parçasıdır. Mailbox rolünü tutan sunucular üzerinde yer alan ve kullanıcı mailbox’larını barındıran database’lerin, aynı lokasyon veya farklı lokasyonlar içerisinde konumlanmış diğer Mailbox Server’lara replikasyonunu amaçlayan DAG, mailbox erişimi ve yedeklemesi notasında kritik rol oynar ve database seviyesinde recovery şansı sunar.

Exchange Server organizasyonu içerisinde bir DAG yapısı devreye aldıktan sonra yüksek erişilebilirlik hedeflediğiniz mailbox database’lerini DAG yapısına dahil etmelisiniz. Bir mailbox database’i DAG yapısına ilk kez eklediğinizde seeding (tohumlama) dediğimiz bir olayın gerçekleşmesi gerekir. Bu olay, ilgili mailbox database için diğer Mailbox Server üzerinde bir kopya oluşması amacıyla gerçekleşir çünkü olayın başında diğer Mailbox Server üzerinde söz konusu database için herhangi bir data yoktur.

Exchange Server DAG Topolojisi

Seeding işlemi sonrasında mailbox database’in tüm içeriği bir kereye mahsus diğer Mailbox Server’a taşınmış olur ve artık sadece oluşan log dosyalarının transferi ile değişiklikler aktarılarak pasif mailbox database üzerine işlenir.

Normal şartlarda seeding işlemi Add-MailboxDatabaseCopy işleminin, yani söz konusu mailbox database’i DAG yapısına dahil ettiğiniz anın bir parçası olarak, ekleme anından hemen sonra otomatik bir şekilde başlar ve ana veri kopyalanana kadar devam eder. Eğer DAG yapınız yerel ağ ortamında veya arada yüksek hızlı bağlantı olan lokasyonlar arasında kurulmuş ise, seeding işlemi mailbox database boyutları ile de paralel olarak mümkün olan en kısa sürede tamamlanacaktır. Ama şayet DAG yapısının arada yüksek hızlı bir bağlantı olmayan WAN ortamında çalışması gerekiyor ve mailbox database boyutlarınız da biraz yüksek ise, işte tam bu noktada seeding işleminin tamamlanması çok ciddi zaman alabilir ve hatta bazen mümkün olmayabilir.

Bir diğer husus ise seeding sonunda source mailbox database tarafında oluşan log dosyalarının da target mailbox database’e gönderilip işlenmesi gerekliliğidir. Bu işlem, seeding başlangıcı ile sonu arasında source mailbox database tarafında oluşan ve log dosyaları içerisinde saklanan değişikliklerin de target mailbox database’e işlenmesini sağlar ve zaten bunda sonraki replikasyon da bu şekilde log taşıma yöntemi ile devam eder. Özellikle düşük bağlantı hızları nedeniyle günlerce sürebilecek bir seeding işlemi söz konusu ise, bu süre içerisinde source mailbox database için oluşan log’ların bir şekilde temizlenme (backup yazılımı veya benzer bir faktör nedeniyle silinmesi) ihtimali vardır ve bu da seeding tamamlandığında gerekli olan log dosyalarının target mailbox database’e gönderilememsi demektir. Sonuç olarak seeding başarısız olur ve tekrar en baştan başlatılması veya gerekli olan log dosyalarının bir şekilde bulunup replay edilmesi gerekir.

Site Arası Exchange Server DAG Topolojisi

Müşterimizin DAG yapısı iki lokasyon ile çalışıyor ve bazı özel nedenlerden ötürü lokasyonlar arasındaki bağlantı hızı 2mbit ile sınırlı. DAG yapısına eklenecek mailbox database’lerin boyutları oldukça küçük olmasına rağmen (SiteA:40GB-SiteB:35GB) aradaki hat çok düşük hızlı olduğu ve çift yönlü bir replikasyon gerektiği için seeding işlemi en iyi ihtimalle yaklaşık 4,5 gün sürecekti.

Buraya bir not: Bu tip senaryolarda seeding ardından replikasyonun devam edebilmesi için oluşacak log dosyalarının da taşınması gerektiğini ve bundan sonraki sürecin bu şekilde devam edeceğini unutmayın. Her ne kadar DAG yapısında log gönderimi için kuyruklama özelliği olsa da aradaki hat hızının anlık olarak oluşan log dosyalarını taşıyabilecek kapasitede olması tavsiye edilir. Örneğin 2mbit ile saniyede teorik olarak yaklaşık 250kb data transfer edilebilir. Bu rakam pratikte daha düşük olacaktır. 200kb olduğunu varsayarsak ve Exchange Server 2010 birim log dosya boyutunun 1mb olduğunu düşünürsek, bu hat 24 saat içerisinde en fazla (ve tabi yine yaklaşık olarak) 17280 adet log dosyası taşıyabilir. Eğer mailbox database’ler üzerinde daha fazla log oluşuyor ise veya zaten kısıtlı olan bant genişliği başka uygulamalar tarafından da kullanılıyor ise kuyruk sürekli dolu olacaktır ve bu da yapının sağlıksız olması anlamına gelir.

Çözüm olarak ise manual seeding yöntemini kullanabilirsiniz. Bu yöntem, bir mailbox database’i DAG yapısına dahil ederken otomatik başlayan seeding işlemin ertelenmesini ve gerekli dosyaların (.edb ve .log) örneğin bir taşınabilir aygıt veya medya ile transfer edildikten sonra işlemin manual olarak gerçekleştirilebilmesini mümkün kılar.

Online ve Offline olmak üzere iki şekilde kullanabilirisiniz. Offline mailbox database seeding işlemi sırasında ilgili mailbox database’in dismount durumda olması gerektiği için pek tercih edilmez ve online seçeneği varken bahsetme gereği duymuyorum. Online mailbox database seeding için ise VSS destekli bir yedekleme yazılımı gerekecek. (örneğin Windows Server Backup)

Konu DAG kurulumu olmadığı için o bölüme hiç girmiyorum. DAG kurulumu tamamlanmış yani şöyle bir yapı üzerinde konuşuyoruz:

Site Arası Exchange Server DAG Topolojisi Site-A Exch1 üzerindeki TestDB’yi Site-B Exch2 ile DAG üyesi yapacağız ve bu sırada manual seeding kullanacağız.

Online Mailbox Database Seeding uygulamak için aşağıdaki adımları takip edin.

1) Seeding erteleme seçeneğini sadece mailbox database’i DAG yapısına ilk kez eklerken kullanabilirsiniz, bu nedenle Add-MailboxDatabaseCopy komutunu –seedingPostponed parametresi ile çalıştırın. Add-MailboxDatabaseCopy cmdlet’i söz konusu DB’yi DAG üyesi yapmak için, –seedingPostponed parametresi ise bu sırada seeding’i ertelemek için kullanılır.

Add-MailboxDatabaseCopy –identity TestDB –MailboxServer exch2.serhatakinci.lab -ReplayLagTime 01:00:00 -TruncationLagTime 00:15:00 –seedingPostponed

Add-MailboxDatabaseCopy

WARNING: Replication is suspended for database copy ‘TestDB’ because the database copy needs to be seeded.

Yukarıdaki uyarıyı alıyor olmanız normal ve hatta almanız gerekir. Bu, seeding işleminin ertelendiğinin göstergesidir.

ReplayLagTime ve TruncationLagTime parametreleri ise opsiyoneldir. Ben gönderilen log dosyalarının hemen taşınması ancak 1saat gecikme ile target mailbox database’e işlenmesi ve işlendikten 15dk. sonra da silinmesi için kullanıyorum.

Ayrıca doğrulama için Exch1 ve Exch2 sunucular üzerinde C:\TestDB\ içeriğine bakabilirsiniz:

Exchange Server Mailbox DB Dosyaları

Exch2 tarafında herhangi bir EDB dosyası yok, bir adet ve sadece en yaşlı log dosyası kopyalanmış.

Get-MailboxDatabaseCopyStatus cmdlet’i ile veya EMC’den baktığınızda Copy Status için Failed and Suspended olduğunu ve DB üzerine replay edilmesi gereken 31 adet log dosyası beklediği görülüyor.

Copy Status - Failed and Suspended

2) Eğer Suspended durumda değil ise söz konusu Mailbox Database için Copy Status’u Suspended’a çekin.

Suspend-MailboxDatabaseCopy –identity TestDB\Exch2

Suspend-MailboxDatabaseCopy

3) VSS destekli yedekleme yazılımı ile az sonra file seviyesinde kopyalama (yani yedekleme) yapacağınız TestDB için database file ve log file’ların nerede durduğunu kontrol edin. Database file (edb) ve log file’ları (log) hatalı veya eksik almanız işlemi en baştan yapmanıza neden olabilir.

Data file ve log file’ların bulunduğu dizinleri şu şekilde kolayca tespit edebilirsiniz:

Get-MailboxDatabase –identity TestDB | fl name,logFilePrefix,logFolderPath,edbFilePath

Get-MailboxDatabase

TestDB.edb dosyası ve E03 prefix’li log dosyaları C:\TestDB altında duruyor. VSS ile yedek alınması gereken yer burası. Backup öncesi log dosyaları arasında herhangi bir eksik olmamalı. Eğer emin değilseniz eseutil /ml E03 ile doğrulayabilirsiniz.

eseutil /ml

E03.log için dönen hata normaldir, problem yok.

4) Exch1 üzerindeki ilgili dizin ve dosyaları VSS destekli bir yedekleme yazılımı ile yedekleyin. VSS destekli olması gerekiyor çünkü bu yazılım TestDB online durumdayken iş yapabilmeli, yani mailbox database erişiminde herhangi bir kesinti oluşmamalı.

Bu iş için elinizdeki VSS destekli herhangi bir yedekleme yazılımını kullanabileceğiniz gibi Windows Server içerisinde yerleşik olarak gelen Windows Server Backup aracını da kullanabilirsiniz. (Varsayılan olarak ekli değildir, Features bölümünden eklenmesi gerekir)

İkinci önemli husus ise yedekleme işleminin file seviyesinde gerçekleşmesi gerektiği. Bazı yedekleme yazılımları Exchange Server ile entegre olarak DB seviyesinde çok daha farklı yedekleme işleri yapabiliyorlar. Bu yöntemler genelde manual seeding işlemi için uygun değildir. Yedekler mutlaka file seviyesinde alınmış ve dönülmüş olmalıdır.

Windows Server Backup

Windows Server Backup için yukarıdaki pencerede Advanced Settings bölümünden ulaşabileceğiniz VSS ayarları ise ayrıca önemli. Hangi yedekleme yazılımını kullanıyorsanız kullanın kesinlikle VSS FULL yedek almayın. FULL yedek ardından bekleyen log dosyaları silineceği için seeding işlemi başarısızlığa uğrar. VSS Copy Backup (veya kullanmış olduğunuz yazılıma göre uygun seçenek ile) log dosyalarının yerinde kalmasını sağlayarak dizini yedekleyin.

VSS Copy Backup

Örneğin yedekleri direkt bir External disk üzerine alabilirsiniz. Exch2 sunucusu üzerinde, aldığınız yedekleri açabilecek bir araç olması gerektiğini, eğer yok ise yedekleri açık bir şekilde götürmeyi unutmayın :)

5) Aldığınız yedekleri diğer lokasyondaki Mailbox Server’a ulaştırdıktan sonra disk üzerinde geçici bir dizine açın. Eğer zaten açık şekilde taşıdıysanız bu adımı atlayabilirsiniz.

C:\temp’e yaptığım file seviyesinde restore içeriği şöyle görünüyor:

Backup Restore

6)  Yedek ile taşınan içeriği ilgili dizin altına (ben de C:\TestDB) kopyalayın.

Bu iş için geleneksel copy/paste kullanabileceğiniz gibi en azında EDB dosyasını kopyalamak için eseutil aracını /y parametresi ile de kullanabilirsiniz. Eseutil /y , yüksek boyutlu dosyaları kopyalamak için optimize edilmiş bir yol sunar ancak bu yöntemi genel amaçlı kopyalamalar için kullanmayın, sadece edb dosyaları :)

Eseutil /y c:\temp\testdb.edb /d c:\testdb\testdb.edb

Eseutil

Eğer yedekleri DB ve Log dosyaların taşınacağı partition içerisine açtıysanız, cut/paste şeklinde çok daha hızlı taşıyabilirsiniz.

Eğer yedekleme, taşıma veya kopyalama işlemi sırasında bir problem veya corruption durumu olmasından şüpheleniyorsanız şayet, Resume işlemi öncesinde EDB dosyasının sağlığını eseutil /k c:\testdb\testdb.edb ile kontrol edebilirsiniz. Data file boyutuna göre zaman alabilir.

Database file kopyalama işi tamamlandıktan sonra ikinci kopyalama işi olarak uygun prefix’li log dosyalarını copy/paste ile yeni yerine yerleştirin.

copy-paste

Eğer bu log dosyalarını kopyalamazsanız seeding işlemi hata vermeyecektir ancak Resume işleminden sonra sistem bu logların tamamını Exch1 üzerinden kopyalamaya başlar. Bu logları sizin taşımanız işlemin çok daha hızlı tamamlanmasına yardımcı olur.

7) Eğer bu adıma kadar problemsiz geldiyseniz mailbox database copy özelliğini Resume etmek için hazırsınız demektir.

Aşağıdaki gibi Resume edebilirsiniz:

Resume-MailboxDatabaseCopy –identity TestDB\Exch2

Resume-MailboxDatabaseCopy

Bu aşamadan sonra önce arka planda otomatik olarak bir Resynchronizing işlemi başlar ve bu sayede VSS backup içinde yer almayan, çünkü VSS backup aldığınız andan sonra oluşan ve taşınması gereken log dosyaları da aktarılır. Bu işlem bittiğinde ise artık Copy Status Heatly durumdadır.

Copy Status Heatly

Copy Status Heatly

Son olarak online mailbox database seeding yönteminde content index files geride (source server) kaldığı için target server üzerinde yeniden oluşması gerekir. Bu işlem de kendi kendine arka planda yürür ve mailbox database boyutuna göre biraz zaman alabilir. Bu sırada Content Index State için CRAWLING gibi bir status bilgisi görebilirsiniz. İşlem tamamlandığında ortadan kalkmış ve manual database seeding süreci tamamlanmış olur.

Sonuç olarak düşük hat hızları nedeniyle günlerce sürebilecek ve başarısız olma ihtimali yüksek seeding işlemini manual gerçekleştirerek çok daha kısa sürede tamamlayabilirsiniz. Üstelik online bir çalışma olacağı için işin hiçbir noktasında kullanıcı mailbox erişimlerinde kesinti yaşanmaz.

Yazı Etiketleri: , , , ,

Sayfa Başı ▲

Yorumlar (2)

  1. Anıl Alan

    Bu değerli bilgi için teşekkürler abi.

  2. salih kaya

    Merhabalar Serhat Bey , exchange dag makalelerini okuyorum fakat bence genel olarak eksik anlatım mevcut (benim için) sormak istediğim konu şu , bir adet exchange 2010 sunucumuz var ve dag sistemini hayata geçirmek istiyoruz ve ikinci bir sunucu satın alıp , en baştan ikinci sunucuyu nasıl yapılandıracağız ?

    bu cevap benim için önemli , ikinci sunucuya active directory kuracağız (mecburen exchange 2010 kurlumu için) peki AD de ileriye doğru etki alanı adı ne olmalı ? dns ileriye doğru arama bölgesi site adı ne olmalı ? domain adını (exchange domain adı örnek : mail.xxx.com) ikinci sunucuya da yönlendirmemiz gerekli mi ? kısacası ikinci sunucuyu dag için en baştan nasıl kuracağız ve hazırlayacağız ,

    cevaplarsınız memnun olurum , şimdiden teşekkürler.

Yorum Ekle