Exchange Server DAG Yapısında Manual DB Seeding

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 Database Availability Group (DAG) 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 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 öncesinde diğer Mailbox Server üzerinde söz konusu database için herhangi bir veri yoktur. Seeding işlemi sonrasında mailbox database’in tüm içeriği bir kereye mahsus diğer Mailbox Server’a gönderilir ve takip eden zamanlarda artık sadece oluşan transaction 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 ilk değişikliklerin de target mailbox database’e işlenmesini sağlar ve zaten bunda sonraki replikasyon bu şekilde log taşıma yönteminin tekrarı ile devam eder.

Kısa süre önce bir müşterimiz için uyguladığımız çözüm eminim aynı veya benzer durum ile karşılaşan kişilerin işine yarayacaktır. 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ı küçük olmasına rağmen aradaki hat hızı düşük olduğu ve çift yönlü bir replikasyon gerektiği için seeding işlemi en iyi ihtimalle yaklaşık 5 gün kadar sürecekti.

Buraya bir not düşelim. 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ı gerekir. Örneğin 2mbit ile saniyede teorik olarak yaklaşık 250kb data transfer edilebilir. Bu rakam pratikte daha düşük olacaktır. Kabaca 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 düzgün işleyemeyeceği 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 ile transfer edildikten sonra işlemin manual olarak gerçekleştirilebilmesini mümkün kılar. Online ve Offline olmak üzere iki şekilde kullanabilirsiniz. Offline mailbox database seeding işlemi sırasında ilgili mailbox database’in dismount durumda olmasını gerektirdiği için pek tercih edilmez. Online mailbox database seeding için ise örneğin Windows Server Backup gibi VSS destekli bir yedekleme yazılımı gerekir. Senaryoda konuştuğumuz DAG yapısı kabaca şu şekilde:

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. Bu cmdlet 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

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

Yukarıdaki uyarıyı alıyor olmanız normaldir. Bu, seeding işleminin ertelendiğini gösterir. -ReplayLagTime ve -TruncationLagTime parametreleri ise opsiyoneldir. Ben gönderilen log dosyalarının hemen taşınması ancak 1 saat gecikme ile target mailbox database’e işlenmesi ve işlendikten 15 dk. sonra da silinmesi için kullandım. Ayrıca transferin başlayıp başlamadığını doğrulama için Exch1 ve Exch2 sunucular üzerinde C:\TestDB\ içeriğine bakabilirsiniz:

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.

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

3) VSS destekli yedekleme yazılımı ile az sonra file seviyesinde kopyalama (yani bir nevi 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

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. 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 dosya 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 manual seeding işlemi için uygun değildir. Yedekler mutlaka dosya seviyesinde alınmış ve dönülmüş olmalıdır.

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 ve kesinlikle VSS FULL yedek almayın. FULL yedek ardından bekleyen log dosyaları silineceği için seeding işlemi sonrasındaki süreç 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.

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özüküyor:

6)  Yedek ile taşınan içeriği ilgili dizin altına (bende 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 ve bu yöntemi sadece edb dosyalarını kopyalarken kullanın: Eseutil /y c:\temp\testdb.edb /d c:\testdb\testdb.edb

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 olduğundan endişeleniyorsanı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. 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. Şu şekilde Resume edebilirsiniz: Resume-MailboxDatabaseCopy –identity TestDB\Exch2

Bu aşamadan sonra, önce arka planda otomatik olarak bir Resynchronizing işlemi başlar ve bu sayede VSS backup içinde yer almayan yani 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.

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 bitmiş 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 daha kısa sürede tamamlayabilirsiniz.