Vmware’in her yıl düzenliği vmworld etkinliğinde bu yıl SRM’in yeni sürümüyle beraber gelmesi planlanan özelliklerini tanıttı bunlar arasında en çok dikkatimi çekmiş olan SRM: stretch storage and Active Active Datacenters sessionında tuttuğum notlar yardımıyla anlatmak istiyorum.

Konuya başlamadan önce belirtmek istiyorum ki bu özellikler hala geliştirme aşamasında olduğundan vmware tarafından değiştirilebilir veya kaldırılabilirler.

İlk önce vSphere 6 ile gelecek vCenter’lar arası vMotion özelliğinden bahsedip hemen ardından DR site modellerine ve stretch storage’ın ne olduğunu tekrardan hatırlatmak istiyorum.

Yeni gelecek vSphere 6.0 sürümüyle beraber vCenter’lar arasında vMotion yapabiliyor olacağız. Bunun için şartlar ise şu an için vCenter’ların aynı SSO domaini içerisinde olması ve VM network’ünün L2 üzerinden bir birlerine bağlı olmalarıdır.  Bu özellik aynı zaman da VM taşındıktan sonra eski vCenter’ında bulunan ve VM’e tanımlı DRS kurallarını ve HA kurallarını da beraberinde taşımaktadır. Artık bu sayede site’larımız arasında load balance yapabileceğimiz gibi Disaster Avoidance ve planlı bakım konularında da bize esneklik getirmektedir.

Stretch Storage veya daha çok bilinen terimiyle metro storage cluster temelde storage ünitelerinizi farklı sistem odalarında veya veri merkezlerinde tutarak lokasyondan bağımsız olarak yedekli çalıştırmamıza izin veren bir yöntemdir. Farklı lokasyonlara dağılmış bu storage controller’ları aslında tek bir cluster gibi hareket ederler ve R/W işlemlerini ortak olarak yaparlar. Bu sayede eğer bir noktada ki storage controller’ı devre dışı kalırsa veya başına bir felaket gelirse öteki lokasyondan sistemler tekrar ayağa kaldırabilir. Bu konu hakkında daha detaylı bilgi için aşağıda ki bağlantıyı kontrol etmenizi öneririm.

http://www.vmware.com/files/pdf/techpaper/vSPHR-CS-MTRO-STOR-CLSTR-USLET-102-HI-RES.pdf

Disaster Recovery Site yapılarına gelirsek genel 4 farklı mimari üzerinde durulur:

Bulk Site: Eski ve bence artık geçerliliğini yitirmiş bir yapıdır. Sadece disklerin veya tapelerin başka bir veri merkezine kopyalanması/gönderilmesi şeklinde olur. Bir sorun yanında sunucular bu yedeklerden veya kopyalardan kurtarılmaya çalışılır. Bu işlem genelde vakit alan ve elle yapılan bir işlemdir. RTO ve RPO’su günler ile ifade edilmektdir.

Production ve DR için ayrı veri merkezi bulundurmak: En çok kullanılan yapıdır.  DR için kullanacağımız veri merkezinde sanallaştırma katmanımız ve fiziksel sunucularımız hazırdır; vReplication, storage replication veya benzer 3. Parti bir yazılımla VM’ler sürekli öbür tarafa kopyalanır ve bir durum anında hızlıca VM’ler ayağa kaldırılabilir. RPO ve RTO genelde saatler cinsinden ifade edilmektedir. Bu yöntemin en büyük sorunu DR merkezinde ki kaynakların atıl olarak durmasıdır.

Bidirectional(Çift yönlü) Failover: Bu yöntem için iki farklı canlı veri merkezimizin olması gerekmektedir. Her iki veri merkezide aktif olarak kullanılma da ve bir birlerini yedeklemektedirler. Böylelikle hem kaynaklardan tasarruf edilir hem de DR çözümü sağlanabilir.

Active/Active veri merkezi: Biraz önce bahsetmiş olduğum Stretch Storage yardımıyla kurulur, disaster avoidance acısından en iyi çözümü vermektedir. Sıfıra yakında RPO’nun yanında iki veri merkezi arasında kesintisiz olarak vm’leri taşıyabilir ve ani bir kesinti esnasında SRM sayesinde hızlı bir şekilde sistemi açabiliriz. Tek sorunu metro yapısına bağımlı olduğundan dolayı onun mesafe limitine takılmasıdır.

Bu yapıları tekrardan gözden geçirdiğimize göre artık SRM’e yeni gelen özellikleri ve bunların active/active veri merkeziyle nasıl kullanabileceğimize geçelim.

SRM’de bulunan vReplication ve Storage Replication özelliklerine ek olarak Storage-Profile based Protection Groups(SPPG) isimli yeni bir seçenek gelmesi planlanıyor. Bu özellik sayesinde recovery plan’ı planned failover olarak çalıştırdığımızda active/active çalışan veri merkezlerinde iki farklı vCenter arasında sunucuları kapatıp failover yapmak yerine kesintisiz olarak vMotion ile taşımaktadır. Bunun için mevcut recovery planlarımızı kullanmaya devam edebiliriz bu sayede ani bir kesintide aynı planı failover yapmak içinde kullanmaya devam edebiliyoruz. Her şeyin SRM tarafından yönetiliyor olması ve taşıma esnasında DRS,HA gibi kurallarımızın da taşınıyor olması operasyon için ciddi bir iş yükünü ortadan kaldırmaktadır.  Bu sistemin sağlıklı çalışabilmesi içinse gerekli ön şartlar:

• vCenter’lar bir birine L3 ile bağlanmalıdır
• VM network’leri için her iki site arasında L2 bağlantı olmalıdır bu sayede IP değiştirmenize gerek kalmaz(eğer L2 sorun olursa SRM’in ip değiştirme özelliğini kullanabilirsiniz)
• vMotion için tüm şartların sağlanması gereklidir
• Vmware NFC(network file copy) protokolünün L2 veya management networkü üzerinden yayın yapacak şekilde(L3) ayarlanması
• Storage üreticileri bu yapıya uygun SRA’lerini yayınlamaya başlamışlar. Her iki vCenter’a bağlı SRM sunucusuna kurulmalıdır

SPPG’nin getirdiği bir başka ek bir özellikse artık bu storage politikasına sahip bir VM, otomatik olarak koruma altına almaktadır, yani tekrardan SRM üzerinden tekrardan ayarlama yapmamıza gerek kalmıyor. VM’in politikasını değiştirmemiz veya mevcut olarak bu politikaya sahip bir datastore’a taşımamız yeterlidir. Karma protection group ve recovery group oluşturabilmemiz de gündemdeymiş.

SRM’in en çok beğenilen özelliği olan recovery test kısmındaysa diğer yöntemlerin aksine VM’leri bir buble network içerisinde açmıyor veya izole bir network’e bağlamak yerine vMotion şartlarını sağlayıp sağlayamadıklarını kontrol ediyor.

Son bir özellik olarak ve benim duyduğuma en çok sevindiğim kısımsa planned failover esnasında eğer bir sorun çıkarsa tüm süreci tekrardan başlamamız gerekiyordu ve bazen süreç öyle noktalarda sorun çıkartıyordu ki o ana kadar yapılan işlemleri elle geri almak bazen tam bir işkence oluyordu. Tabii kesinti süresinin uzamasından hiç bahsetmiyorum. Yeni yapıda eğer planned failover bir sebepten dolayı yarım kalırsa hatayı düzeltip plan’ı tekrar başlattığınızda daha önceden tamamlamış olduğu kısımları atlayıp kaldığı son adımdan devam edecektir.

Bundan sonra tek beklememiz gereken sanırım vSphere 6.0 ve SRM’in son sürümü olacaktır.

Linkedin

Twitter

Facebook

Stumbleupon

Diggit