Disaster Recovery bir felaket anında sistemin sürekliliğini sağlamak için geliştirilmiş olan teknolojilerdir.Disaster Recovery çözümleri için sektörde bir çok donanımsal ve yazılımsal ürünler bulunmaktadır. Bu ürün seçimlerini , hızlı ve problemsiz geri dönüş yapmak için ihtiyaçlarımıza ve operasyonlarımızın yoğunluğuna göre iyi seçmemiz gerekmektedir.İyi bir ürün seçimi ve daha önceden hazırlanmış bir geri dönüş senaryosu zorunludur !
Nedeni, felaket anları – sistemin downtime (kapalı,ulaşılamaz olduğu zaman dilimleri) süreleri , zor olmanın yanı sıra sitreslidir ve baskı altında çalışmaya zorunlu kılınan sürelerdir.Bir bilgi işlem çalışanının, bir bilgi işlem yöneticisinin gerçek bilgi ve becerisi, baskı – sitres altında çalışma yeteneği bu zamanalarda ortaya çıkmaktadır.
Daha önceden hazırlanmış bir senaryo yoksa, daha önceden hazırlanmış bir geri dönüş planı yoksa ve olası bir felaket anı için seçilmiş doğru ürün yoksa bu sure uzamakta, baskı – sitres çoğalmakta, mantıklı – akıllı düşünme kabiliyeti azalmakta ve bu sebepler yüzüne downtime süreleri uzamaktadır. Downtime süreleri uzadıkça, şirketimizin maali açıdan kaybı her geçen dakika, saat büyümektedir.
Disaster Recovey çözümleri pahalı çözümlerdir.Disaster Recovey çözümlerini iki başlık altında inceleyebiliriz.
1. Business Continuity Plan (BCP)
Bu konu hakkında daha önceden yazmış olduğumFault Tolerance(Yuksek Erişilebilirlik Senaryoları) makalesini okumanızı önereceğim. İş sürekliliğini sağlamak adına server, server aksamları,Networkürünleri - bağlantıları, sistem odaları vb.. merkezi sistem odalarımız içinde yer alan ürünler üzerine yapmamız gereken dizaynlardan bahsetmiştik. Güncel serverlarımızın mimarisinden ve kullanmamız gereken zorunlu teknolojilerden örnekler vermiştik.
Business Continuity Plan içinde yeralan uygulamalar üzerine makale dizileri hazırlamış ve Hyper-V FailOver Clsuter olmak üzere senaryolarımızdan bahsetmiştik. Portalımız üzerinde yayınlanmakta olan Hyper-V FailOver cluster ve Microsoft FailOver Cluster makalelerine aşağıda ki adresten ulaşabilir ve Business Continuity Plan hakkında detaylı bilgiye sahip olabilirsiniz.
http://www.cozumpark.com/search/SearchResults.aspx?q=FailOver+cluster&a=1
2. Disaster Recovery Plan (DRP)
Business Continuity Plan isteklerini tam anlamıyla yapmadıktan sonra Disaster Recovery Planbölümüne geçmenin hiç bir anlamı yoktur !
DRP uygulamaları, BCP uygulamalarına göre daha pahalı çözümlerdir. BCP daoğru planlanmadığı sürece Sağlılı bir DRP planımız hiç bir zaman için olamaz!
Sebebi, Disaster Recovery Plan uygulamalarının ağırlıklı tercih sebebi, çok subeli yapılar için tercih edilmektedir.BCP teknolojilerini ağırlıklı olarak LAN ortamı için uygulamaktayız. DRP teknolojilerini ise WAN yapılarında uygulamaktayız.
Sağlıklı bir Disaster Recovery Plan için çok geniş senaryolar üretmemiz mümkündür ve gerekmektedir.Çünkü Disaster Recovery plana ihtiyaç duyacak olduğumuz nedenlerin başında Doğal Afetlerler gelmektedir.Doğal afetlerin ne zaman hangi şekilde hangi zararda geleceğini hiç bir zaman için bilememekteyiz.
Gerçek hayatda yaşanılan olaylara baktığımız zaman 17Agustos tarihinde doğru DRP yapılmamış firmaların hizmet kesintisi ve deprem haricinde yaşamış oldukları maali zararları araştırabilirsiniz.2009 senesi içinde yaşamış olduğumuz, Dünyanın en büyük metropolleri arasında yer alan Istanbul’ da yaşanılan SEL baskını sonrası, şirketlerin yaşamış olduğu kapalı olma sürelerini ve zararlarını araştırmanızı konunun öneminimerak eden okuyucularımız için isteyeceğim.
Sistem Center Data Protection Manager 2007 ile gerçekleştire bileceğimiz Disaster Recovery uygulamamıza geçmeden önce BCP ve DRP’ ın kullanım amaçlarının neler olduğunun anlaşıldığını varsayıyorum.
Yukarıda ki topolojiyi dikkatli bir şekilde inceleyelim.
Not :Topoloji gerçek hayatta uygulanmıştır. Makale içinde yer alan ekran görüntüleri operasyon sırasında alınmıştır.2009 Senesi 2nci çeyregi içinde başarılı bir şekilde gerçekleştirmiş olduğum, Microsoft tarafından başarı hikayesi yapılan bir projedir.Ekran görüntüleri ve Müşteri bilgilerini çekinmeden verebiliyorum ki bu makale ve başarı öyküsü için müşterimden izin alınmıştır.
Projenin oluşum aşaması; DRP bölümünde anlatmaya çalışmış olduğum bir takım felaketler müşterimizin başına gelmiş ve firma için istenmeyen olaylara sebep olmuştur.Merkez sistem odası için artık bir kaygı oluşmuş ve bu kaygı sonucunda Disaster Recovery Plan hazırlanması istenilmiştir.
Hazırlamış olduğum proje ismi dpm2dpm4ds dir. Proje ismi Microsoft technet üzerinde yayınlanan ve uygulamanın teknik döküman ismidir.dpm2dpm4ds ‘ açılımı, Primary DPM2007 Server üzerinde bulunan backupların (korunan server datalarının), Secondery DPM2007 Server üzerine kopyalanmasıdır. Secondery DPM 2007 Serverimiz farklı bir lokasyonda bulunmaktadır.İki nokta arasında IPSEC VPN Teknolojisi gerçekleştirilerek DPM Serverlar arasında ki iletişim gerçekleştirilmiştir.
Merkez Sistem Odası içinde bulunan Primary DPM 2007 Serverin görevi, Merkezde bulunan SQL Datalarının her saat yedeğini almaktır.
Depo noktasında bulunan Secondary DPM 2007 Serverin görevi ise, Primary DPM2007 Serverin her saat başı almış olduğu yedekleri her 6 saatte kendi üzerine kopyalamasıdır.
Primary DPM Server üzerinde genel kontrollerimizi gerçekleştiriyoruz.Merkezde bulunan ve SQL Serverin yedeklerini alan DPM Server üzerinde Management bölümü içinde Agents bölümüne giriyoruz.
Agents bölümü altında Protected (korunan)computersbölümünde DC-SRV bilgisayarını görebilmekteyiz.
NOT : isim bizleri aldatmasın. Dc-Srv ismine sahip serverimizin görevi aslında bir SQL serverdir.SQL serverin bağlı olmuş olduğu özel uygulamada isim değişikliğine izin verilmediği için ve eskiSQL serverin ismi geçmişten kalan dizayn nedeniyle değiştirilmemiştir.Kısacası Bu server bir SQL serverdir.
Yukarıda ki resimde görüldüğü gibi Primary DPM serverimiz aynı lokasyon içinde bulunan SQL server datalarını korumaktadır.
Primary DPM2007 Serverimizin Protection bölümüne baktığımız zaman SQL Server databaselerini yedeklediğini görebilmekteyiz.
Primary DPM2007 Serverimiz üzerinde Recovery bölümüne geldiğimiz zaman, Primary DPM serverin SQL Server üzerinde almış olduğu yedekleri ve geri yükleme noktalarını görebilmekteyiz.
Primary DPM2007 Serverimiz ile Secondery DPM2007 Serverimiz arasında ki iletişimi kontrol ediyoruz.Her iki DPM2007 Serverimiz aynı Active Directory’nin üyesi durumundadır.
Primary DPM2007 Serverimizin ismi w2k8DPM2007PDK (Pendik Merkez içinde barınmaktadır)
IP adresi ve secondery DPM 2007Server’a erişim gerçekleştirmek için izlemiş olduğu (tracert)yolları görebilmekteyiz.
Secondary DPM2007 Serverimizin ismi w2k8DPM2007DP (Depo Noktası içinde barınmaktadır)
IP adresi ve Primary DPM 2007Server’a erişim gerçekleştirmek için izlemiş olduğu (tracert)yolları görebilmekteyiz.
Her iki DPM serverimiz bir birleri ile başarılı bir şekilde iletişim kurabilmektedir.
Depo Noktası içinde bulunan Secondery DPM2007 Serverimiz üzerinde Management bölümü içine girip, Agent sekmesine baktığımız zaman yüklü agentların olmadığını görebilmekteyiz.
Sağ bölümde bulunan Actions bölümünde Install bölümünü tıklayarak agentimizi yukluyoruz.
Protection Agent Install bölümünde açılan sihirbazda, sol tarafta agent yüklemek üzere hazır bulunan Active Drictory bilgisayarlarını görebilmekteyiz.Bu bölümde Primary DPM serverimizi seçip devam ediyoruz.
Agent yüklenebilmesi için gerekli olan yönetici adımızı ve parolamızı giriyoruz.Ileri butonuna bastığımız zaman w2k8DPM2007PDKisminde ki Primary DPM serverimiza agent yükleme işleminin başarılı bir şekilde gerçekleştirildiğini görebilmekteyiz.
Not : DPM server, koruyacak olduğu bilgisayarlara agent yükleme işlemini bitirdikten sonra Agent yüklenen bilgisayarın yeniden başlatılmasını şart koşmaktadır.Fakat Secondery DPM server üzerinden Primary DPM server üzerine bir agent yüklendiği zaman böyle bir şartı yoktur.Sebebi ise bu işlemlerde herhangi bir agent YUKLEMEMEKTEDIR. Sadece Secondery DPM server üzerine Primary DPM server tanıtılması gerçekleştiriliyor ve bu işlem saniyeler kadar sürüyor.
Secondery DPM Serverimizin Management bölümü altında agent bölümüne girdiğimiz zamanUnprotected computers altında Primary DPM serverimizi görebilmekteyiz.Herhangi bir koruma bulunmamaktadır.
Secondery DPM serverimiz, Primary DPM serverimizin yedeklemiş olduğu dataları koruyacağı için Modify bölümünü tıklıyoruz.
Not : Modify bölümü disaster Kuralı haricinde hiç bir Protected Computers bölümünde çıkmaz. Bu özellik sadece Secondary DPM Serverin özelliği olup sadece Disaster kurallarında çıkmaktadır.
Korunan bilgisayarın (DC-Srv) detaylı özelliklerini görebilmekteyiz. Detayları incelediğimiz zaman,
1. Primary DPM serverinname( ismini ) görebilmekteyiz.
2. Computers Protected by Primary DPM server bölümünde primary serverin korumuş olduğu server sayısını görebiliyoruz. Sadece Dc-Srv bilgisayarını korumaktadır.
3. Computers enabled for secondary protection bölümünde, primary dpm serverin korumuş olduğu dataların secondary dpm server tarafından korunmadığını görebilmekteyiz.
Primary DPM serverin korumuş olduğu dataları yani DC-srv’ nin SQL datalarını, secondary DPM server tarafından korunabilmesi için Enable Secondary Protection bölümüne giriyoruz.
Secondary Protection’ un aktif duruma gelebilmesi için yönetici kullanıcı adımızı ve şifremizi bizlerden istemektedir.Bilgilerimizi doğruluyoruz.
Yapmış olduğumuz bu uygulamadan sonraki değişiklikler yukarıdadır.
Primary DPM Servera Secondary DPM serverin tanıtıldığını görebilmekteyiz.
Primary DPM Server üzerinde korunan DC-SRV bilgisayarının, artık Secondery DPM Server tarafındanda korunabildiğini görebilmekteyiz.
Not : Primary DPM Server üzerinde farklı korunan bilgisayar,server varsa eğer, her birisi için bu özellik ayrı ayrı yapılmalıdır. Primary DPM serverimiz Exchange Server datalarını koruyorsa, MOSS databasesini koruyorsa vb..korunan her bir database ve server için ayrı ayrı Enable Secondary Protection bölümü aktif duruma getirilmelidir.
Secondary DPM server üzerinde Protection bölümüne girdiğimiz zaman Secondary DPM Serverimiz üzerinde korunan hiç bir data olmadığını görebiliyoruz.Koruma oluşturmak için Actions bölümünde bulunan Create Protection bölümünü seçiyoruz.
Yeni bir koruma oluşturmak üzere sihirbazımız açılıyor.Bu bölümde yapabilecek olduğumuz korumalar agent yüklediğimiz bilgisayar ve serverlar olduğu gibi, Primary DPM serverin korumuş olduğu datalarda görünmektedir. W2k8DPM2007PDK bölümünü genişlettiğimiz zaman PrimaryDPM Server olan w2k8DPMPDK’ nin korumuş olduğu DC-SRV datalarını görebilmekteyiz.Seçimi DC-SRV için koruma altında olan dataları seçip devam ediyoruz.
Bizleri bir uyarı karşılamakta!Bu uyarıyı özellikle dikkate almanızı önereceğim. Sadece dpm2dpm4ds kuralı için gerekli olan bir uyarı değil genel anlamda DPM server kullanıyorsak eğer dikkate almamız gereken önemli bir uyarıdır.
Bu uyarıda bizlere söylenen Secondary DPM serverin, Primary DPM Serverin korumuş olduğu datalar için ikinci bir kural oluşturduğumuz söylemektedir.Eğer Secondary DPM Servera sahipsek, Primary DPM Serverin sahip olmuş olduğu SQL databasesinin de özellikle yedeklenmesi gerektiğini bizlere söylemektedir.
DPM 2007 bilindiği gibi arka tarafta SQL Server kullanmaktadır. Ve DPM server üzerinde korunan bütün bilgisayarların dataları, yüklü bulunan agentlar, disk bilgileri vb..DPM servera özel bütün bilgiler bu SQL database içinde saklanmaktadır. Eğer bizler DPM Serverimizin databasesini yedeklemezsek ve sahip olduğumuz DPM server zarar görürse sahip olduğumuz backuplara erişim sansımız bulunmamaktadır !
Çünkü DPM serverin korumuş olduğu dataları, yedeklemiş olduğu datalara sadece ama sadece yedekleri alanDPM server erişmekte ve görmektedir. DPM Serverimizin SQL Databasesinin yedeği yoksa eğer, zarar gören DPM serverin almış olduğu disk tabanlı ve tape tabanlı hiç bir datayı geri dönemeyeceğiz.Yeni baştan bir DPM Server kurup, Eski DPM serverin yedeklerini disk üzerinden veya tape backup üzerinden okuyamayacağız.Çünkü bu bilgilerin hepsi zarar gören DPM serverin SQL Databasesi içinde barınmaktadır. Bu uyarıyı dikkate alıyoruz ki backuplarımız en az canlı datalarımız kadar bizler için önemlidir.
Bu özelliği farklı bir makalede detaylı olarak anlatmaya çalışacağım.Ama kısa bir bilgi olarak DPM System Recovery Toolyazılımını incelemenizi öneriyorum.
Kuralımız içine Primary DPM Serverimizin databasesinide ekliyorum.DC-SRV için korunan yedeklerin haricinde bu kural içine primary DPM serverin sahip olmuş olduğu SQL datalarının da yedeklenmesi gerektiğini belirttim.
Oluşturmuş olduğumuz kurala isim veriyorum ve disk tabanlı koruma yapması gerektiğini belirtiyorum.
Oluşturmuş olduğumuz dpm2dpm4ds kuralı için yaşam süresi ve sekronizasyon aralığını Specify Short-Term Goals bölümünde belirliyoruz.
Oluşturmuş olduğumuz kuralın 60 gün boyunca yaşamasını belirtiyorum.
Sekronizasyon aralığınınsa her 24 saatte bir yapılması gerektiğini belirtiyorum.
Not : DPM Serverin her 15 dakikada bir backuplama görevini almak üzere dizayn edilmiştir. Fakat secondery DPM server, Primary DPM Serverin yedeklerini sadece 6 saat, 12 saat ve 24 saatte bir almak üzere geliştirilmiştir. Eğer bizler bu süreyi daha kısa bir zaman dilimine çekmek istersek ancak manuel olarak görevi başlatarak gerçekleştirebiliyoruz.Bu zaman süresi DPM2010 ile birlikte giderileceği bilgisi DPM Team tarafından duyurulmuştur.
Modify bölümüne tıkladığımıza zaman Express Full Backup’ ın ne zaman alınması gerektiğini belirtiyorum. Replicasyon WAN hattı üzerinden olacağı için çalışma saatlerinin olmadığı zaman dilimi benim için en uygun zaman dilimidir. Çünkü her 6, 12, ve 24 saat dilimlerinde data değişkenliğini alırken, Express Full Backup zamanında datanın bire bir kopyasını alıp datanın bütünlüğünü doğrulayacaktır.Bu sure uzun süreceği için çalışma saatleri harici benim için uygun olup Saturday (cumartesi) gününü belirtiyorum.
Kuralımızı oluşturduktan sonra otomatik olarak kuralın başlaması gerektiğini belirtiyoruz.Veya başlayacak olduğu zaman dilimini seçiyoruz.
Oluşturmuş olduğumuz Protected Grup hakkında özet bilgi verilmektedir. Sahip olduğumuz WAN hattı yavaşsa eğerOptimize Performance bölümünde replicasyon için değişiklikler yapabileceğiz.
Optimize Performance bölümünde, sahip olduğumuz WAN hattının hızına bağlı olarak Enable on-the-compression seçeneğini aktif duruma getirebiliriz. Bu seçenek bizlere replicasyonun daha hızlı olmasını sağlayacaktır. Replice edilecek datalar primary DPM 2007 server tarafından sıkıştırılacak ve Secondary DPM 2007 server tarafından açılacaktır.
Yukarıda ki tabloda Primary DPM Serverdan Secondary DPM server dataların başarılı bir şekilde gidebilmesi için tavsiye edilen hat hızları ve zaman dilimleri bulunmaktadır.
Diğer bölümdeyse secronizasyonun yapılacak olduğu zaman dilimlerini belirliyoruz.
Performance bölümünde ki değişiklikleri yaptıktan sonra Create Group butonu ile kuralımızı aktif duruma alıyoruz.
Kuralımız başarılı bir şekilde oluşturuldu.
Secondary DPM2007 Serverimiz üzerinde Monitoring bölümüne girdiğimiz zaman Jobs bölümü altında all jobs in progress seçimini yaparak aktif çalışan görevleri göreviliriz.
Kurulı oluşturduktan sonra görevin otomatik olarak çalışmasını istediğimiz için replicasyon kural oluşumu sonrasında başlamıştır.
Görevlerimiz WAN hattımıza ve data boyutuna bağlı olarak değişkenli gösterecektir.
Replicasyon tamamlandıktan sonra, relice edilen SQL datalarını 3 farklı noktaya geri dönebilmekteyiz. Bu noktalar ;
1. Primary DPM Server üzerine
2. Primary DPM Serverin korumuş olduğu DC-SRV üzerine
3. Secondery DPM Server üzerine tanımlı bulunan, agent yüklü bir bilgisayarın sabit diskine.
4. Secondery DPM Server üzerine tanımlı bulunan, agent yüklü bir SQL Server üzerine.
Fatih KARAALIOGLU