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 (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.
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.
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-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
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:
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 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 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 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.
Ö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:
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
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.
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
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.
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.
Serhat AKINCI
http://twitter.com/serhatakinci