Bu makalemde artık herkesin aşina olduğunu tahmin ettiğim Veeam Backup&Replication programının replikasyon tarafındaki özelliklerini ve mantığını anlatıyor olacağım. Kurumlar için disaster site’lar artık bir gereklilik haline geldi ve bu ihtiyacı karşılamak için de piyasada çok farklı çözümler mevcut. Fakat bu çözümleri uygulayıp yönetirken sistem yöneticilerine sağlayabildiği kullanım kolaylığı da bence atlanmaması gereken önemli bir nokta Veeam bu konuda oldukça başarılı, daha önce hiç Veeam kullanmayan biri backup ve replikasyon mantığını kavrayıp kolayca uygulayabilir hale gelebilir. Konuyu fazla uzatmadan replikasyon uygulamamda kullanacağımız yapıdan bahsedeyim. Mevcut yapıda storage’ıma bağlı Vmware Esxi hostlarım üzerinde çalışan sanal makinelerim ve bunları yöneten bir vCenter’ım var.Disaster site ile aramda bir wan hattı mevcut ve burada da merkezdeki gibi bir Vmware ortamı var.Ben production ortamımda çalışan sanal makinelerimi benim istediğim sıklıkta ve ayarlarda disaster tarafa replike ettireceğim. Uygulamaya geçmeden önce Veeam’deki replikasyon mantığından bahsedelim ki kafamızda daha iyi şekillensin. Bu ve buna benzer yapıya sahip işletmeler Veeam ile replikasyon yapmaya karar verdiğinde başlangıç olarak karşılarına iki seçenek geliyor.
Onsite Replication: Bu replikasyon mantığı aynı site üzerinde başka lokasyona sanal makinelerinizi replike ettirmek. Örneğin belli bir arazi üzerinde birden fazla binası olan bir işletme var ve bu binalarda birbirlerine fiber ile bağlı olsun. Sistemlerin çalıştığı bir binadaki olası bir felaket anında sistemin replike edilen diğer system odasından hemen ayağa kalkması istenebilir. Böyle bir senaryoda 1 adet Veeam sunucusu yeterli olacaktır. Bu sunucu aynı zamanda Veeam proxy sunucusu olacağından ve aradaki bağlantının da en az 1Gbit olacağını varsayarsak ekstra bir proxy sunucusu tanımlamaya gerek kalmıyor. Âmâ atlanmaması gereken önemli bir nokta da bu sunucuyu da disaster tarafta kurup çalıştırmak daha mantıklı olur ki disaster anında veaam sunucusu çalışan tarafta erişebilir bir halde olsun. Anlatmak istediğim senaryonun şeması aşağıdaki gibidir. Aslında basitçe şöyle düşünebilirsiniz, eğer disaster site ile aranızdaki bağlantı hızı 1Gbit ve üzeri ise bu senaryoyu kullanmalısınız.
Offsite Replication: Bu replikasyon seçeneğinde ise replike ettirilecek hat hızı ve veri miktarı büyükse bize kolaylık getiren iki seçeneği var. Örneğin disaster site ile aranızdaki bağlantı 10Mbit olsun. Production taraftaki replike ettireceğiniz sanal makinelerin boyutu da 2TB olsun. Bunu sıfırdan direkt olarak disaster site’a basmak onlarca gün alacaktır ki, bağlantısının bu süre içinde stabil kalabilmesi de gerekecek tabi.Bu yüzden Veeam burada iki tane basit ama etkili çözüm sunuyor.Bunlardan ilki replica seeding. Replica seeding demek şu; Veaam diyor ki disaster site’daki sunucu ve storage’ın eğer yanındaysa veya yanına alabiliyorsan ilk önce localde on-site şeklinde replike ettir. Disaster site’a götürdüğün zaman replike ettirdiğin bu sunucuyu job üzerinden map et.Yani bu durumda verinin çok büyük bir kısmını local network’te hızlı bir şekilde atmış olacağız, disaster site götürüp map ettiğimizde ise o sadece arada geçen zamanki farkları atmış olacağız. Diğer bir seçenekte disaster taraftaki makineleri yanına alamayanlar için J Bunun çözümü de oldukça etkili. İlk önce iç tarafta Veeam ile replike ettireceğiniz sunucuların full yedeğini alıyorsunuz. Sonra yedeği aldığınız diski, nas cihazını vs götürüp disaster taraftaki ortamınıza bağlayıp orada çalışan Veeam sunucusuna backup repository olarak ekliyorsunuz. Replikasyon job’u oluşturduğunuzda seçeneklerden initial seeding’i seçtikten sonra bu backup repository’i gösteriyorsunuz. Replikasyon başladığında Veeam ilk önce aldığınız backup’ı disaster ortama restore ediyor sonrada production ortam ile arasındaki farkları almaya başlıyor. Offsite replikasyonun diğer bir farkı da 2 adet proxy sunucu kullanılmasıdır. Disaster tarafta kurulu Veeam sunucusunun kendisi bir proxy olup, ek olarak production tarafa da bir proxy sunucu performans için gereklidir. Proxy sunucu görevini sanal ya da fiziksel herhangi bir makineye verebilirsiniz. Bunun için veeam’i o makineye kurmanıza gerek yok. Sadece disaster taraftaki Veeam üzerinde proxy ekle deyip production site’daki makinenin ip ve kullanı bilgilerini gireceksiniz oda buraya bir agent kuracak. Yani basitçe offsite replication yavaş wan hattına sahip kullanıcıların büyük verileri ilk etapta daha hızlı bir şekilde karşı tarafa replike ettirmenin kolay yoludur.
Şimdi offsite replikasyona örneğimize başlayalım;
Mevcut yapımdaki Veaam sunucum disaster tarafta kurulu ve hem buradaki hem de production ortamımdaki vCenter sunucum konsola ekli durumdadır. Replication job’a tıkladığımda karşımıza ilk ekranımız geliyor.
Low connection bandwith offsite replikasyon için işaretlememiz gereken bir seçenek. Diğer opsiyonel seçeneklere de değinebilmek için ben hepsini seçiyorum, next diyoruz.
Bu ekranda add deyip production ortamımızdaki replike edilecek sanal sunucuları seçip next diyoruz.
Bu ekranda replike edilecek sunucuyu ve buna bağlı bir datastore seçip next diyoruz.
Bu ekran başta seçtiğim separate virtual network seçeneği ile geldi. Bu seçeneğe şu şekilde ihtiyaç duyabilirsiniz, örneğin disaster tarafınızı datacenter firmasında barındırıyorsunuz. Olası bir disaster durumunda sanal makinelerin ayağa kalkıp hizmet verebilmesi için network yapısının da ona göre tekrar düzenlenmesi gerekebilir. Mesela disaster tarafta size ayrı bir vlan tanımlı ve makinelerin bu vlan dan ayağa kalkması gerekiyor (tabi bu vlan networkünün önce vmware tarafında tanımlanması gerek).Burada kaynak ve hedef networkleri seçiyorsunuz. Hedef network’ü seçmeniz makinelerin açıldığı zaman direkt olarak bu network üzerinden çalışmasını sağlıyor.
Bu ekranda başta seçtiğim different ip address schema ile geldi.Disaster tarafımızdaki ip network’ü farklı ise işimizi kolaylaştıracak bir özellik. Burada kaynak sanal makinenin ip ve subnet bilgelerinden sonra ayağa kalkmasınız istediğiniz ip ayarlarını yapıyorsunuz.
Bu ekranda ise yukarıda bahsettiğim proxy sunucuları belirtiyoruz.Source proxy kısmına production taraftaki görevlendirdiğim sunucuyu, target ise disaster taraftaki (yani bu makine) makinemi belirtiyorum. Ayrıca kaç adet restore point tutsun ve replike edilen sunucu ismine ne eklensin gibi seçeneklerinde burada ayarlıyoruz. Advanced kısmına da bir göz atalım.
Traffic bölümünde replike ettirilecek verinin sıkıştırma oranı ve aradaki bağlantı tipini seçiyorsunuz. Sıkıştırma oranını arttırmak proxy sunucu üzerinde daha fazla işlemci kullanımı anlamına geliyor. Benim yapıma uygun olan seçenekleri seçiyorum. Notificaitons bölümüne Veeam’e tanımladığınız bir mail adresi dışında bir mail eklemek istiyorsanız kullanabilirsiniz. Diğer seçeneklerde de ihtiyacınıza göre job çalışmasını bitirdiği zaman bir script çalıştırabilme, uyumla olan storage’lar üzerinde snapshotları kullanabilme gibi seçenekleri belirleyebilirsiniz. Bu kısımlarla bir işim olmadığı için next ile devam ediyorum.
Ve geldik seeding menümüze. Burada yukarıda bahsettiğim iki offsite replikasyon seçeneğinden birini seçeceğiz .Eğer backup alıp disaster tarafa gönderip bağladıysak initial seeding, daha önceden replike ettirdiyseniz replica seeding seçip detect yada edit butonu yardımı ile o sunucunun replikesini göstermek. Next ile devam ediyoruz.
NOT : Bu seçenekleri job’u ilk çalıştırdığınızda kullanacaksınız. Dolayısıyla bittiği zaman jobu tekrar düzenleyip en başta seçtiğimiz Low connection bandwith offsite replikasyon tikini kaldırmanızda yarar va
Enable application-aware image processing seçeneği ile vss tabanlı uygulama sunucuları üzerinde tutarlılık sağlanabiliyor. Ayrıca mesela exchange sunucunuz için replikasyon sırasında transaction logları temizlemesini istiyorsanız bu seçeneği işaretleyip advanced bölümden yapabiliyorsunuz. Next ile devam ediyorum
Bu ekranda da job’un ne kadar sıklıkla saat kaçta çalışacağı gibi ayarları yapıp bitiriyoruz.
Eğer bağlantıda ve kullanıcı yetkilerinde bir problem yoksa replikasyon başarılı bir şekilde çalışacak demektir.
Şimdi failover kısmına değinelim;
Olası bir durumda sunucuları ayağa kaldırmak istediğimizde sol tarafta bulunan replicas bölümünde replike edilmiş sunucularınızı göreceksiniz. Bu listeden ayağa kaldırmak istediğiniz sunucuya sağ tıklayıp failover now diyoruz.
Karşımıza gelen ekranda daha önceki restore point leri seçme şansımız mavcut (örneğin 2 gün önceki hali gibi)
Ardından next diyerek failover çalışmaya başlar ve disaster taraftaki replike makine belirttiğiniz ayarlar ile power on olarak hizmet vermeye başlar.
Şu anda sunucumuz disaster tarafta ayağa kalktı ve çalışıyor ama bu şekilde askıda diyebiliriz (read only olarak düşünebilirsiniz).Bu sunucuyu belirleyeceğimiz stratejiye göre kullanacağız. Burada karşımıza 3 adet seçenek çıkıyor.
Permanent Failover: Bu seçeneği seçtiğinizde bu sunucu artık disaster tarafta çalışacak ve kalıcı olacak demiş oluyorsunuz. Failover olan makinenin o ana kadar olan değişikleri üzerine işlenip açılıyor (bu işlem bittiğinde Veeam konsolunda replicas bölümünde artık bu sunucuyu görmeyeceksiniz).
Undo Failover : Production taraftaki sunucunuzdaki problemi giderdiniz veya bu sırada failover olarak ayağa kaldırdığınız sunucu ile işiniz bitti diyelim.Bu seçeneği seçtiğinizde failover olarak çalışan sunucu çalışmaya başladığı andan o ana kadarki olan değişiklikleri silip otomatik olarak kapanır.
Failback to Production: Bu seçenek disaster tarafta çalışan sunucunun production tarafına alınmasını sağlıyor.
Şimdi Failback to Production seçeneği ile disaster tarafta çalışan sunucumuzu production ortamımıza alalım.
Sunucumuzu seçip next diyoruz.
Destination ekranında sunucumuzun nereye failback edileceğini seçebiliyoruz. Burada orjinal yerine, farklı bir sunucu ya da datastore’a ve farklı bir sanal sunucu ile değiştirme seçenekleriniz mevcut. Pick backup proxies for data center seçeneği ile arada kullanılacak proxy sunucuları seçebilirsiniz. Bu konu önemli. Yukarıda anlattığım offsite replikasyon için kullandığım proxy sunucu mantığının aynısı.
Failback işlemi başladığında adımları detaylıca görebiliyorsunuz.Kısaca açıklamak gerekirse replike sunucu production tarafa transfer ediliyor ardından da değişiklikler transfer edilerek üzerine yazılıyor (orjinal vm’i eziyor).Burada aklınıza disaster tarafta sunucunun farklı ip ile çalıştığı ve bu ip ile production ortama geleceği gelebilir ama failback yapıldığında sunucu production tarafta orjinal ip adresi ile ayağa kalkıyor. Yani replike ederken kullandığımız re-ip kuralı tersine çalışıyor. Tüm işlem sonlandığında disaster tarafta çalışan sunucu kapanıp production ortamındaki sunucu açılıyor.
Sunucumuz production ortama replike edildi ve çalışır halde ama hala askıda diyebiliriz (read only olarak düşünebilirsiniz).Eğer bu sunucuyla benim işim bitti gerek yok derseniz undo failback seçeneğini seçmelisiniz. Bu durumda yapılan değişiklikler silinir, production ortamdaki sunucu kapatılıp disaster taraftaki açılır. Yani failover moda geri dönülür.
Artık bunun da kalıcı olarak orjinal sunucumuzun yerini alması için commit failback seçeneği ile devam edelim.
İşlem sıkıntısız bittiğinde felaket anında ya da başka bir sebepten dolayı kaybettiğimiz sanal sunucumuzu disaster site’dan ayağa kaldırarak çalışmamıza devam edebilmiş ve sunucumuzu production ortamımıza geri kazandırmış oluyoruz.
Tabi ki umudumuz kimsenin bu sorunları yaşamayıp bu adımları yapmak zorunda kalmaması yönündedir.
Sizlere Veaam ile replikasyon ve failover senaryolarını anlatmaya çalıştım, umarım faydalı olmuştur. Başka bir makalede görüşmek ümidiyle.
