Merhaba;

Bu yazımda “Veritas Volume Replicator” ve sunduğu “Snapshot” teknikleri üzerinde duracağım.

“Veritas Volume Replicator” ürününe geçmeden önce “Disaster Recovery” kavramından bahsetmemiz gerekir. “Disaster Recovery” kavramını “Felaket kurtarma” olarak çevirebiliriz ama bu kavramı bu yazımda kısaca DR olarak ifade edeceğim.

“DR”ı, eğer üretim ortamının çalıştığı lokasyonda iş ihtiyacının izin verdiği süreler içerisinde çözülemeyen bir sorun varsa, operasyonu alternatif bir lokasyonda tekrar başlatabilme yetkinliği olarak düşünebiliriz. “DR” yapılarında birincil öncelik kritik veriye son kullanıcı bazında herhangi bir değişikliğe gerek kalmadan ulaşabilmeyi sağlamaktır. Veritas, veri koruma teknolojilerinde endüstri liderlerinden birisidir. “VVR” da tüm kritik veriler için tam bir “DR” planı oluşturmak için anahtar bileşenlerden birisidir.

“DR” ve “Local High Availability” kavramlarının farkını belirtmemiz oldukça önemlidir. “DR”, üretim ortamının çalıştığı lokasyonda iş ihtiyaçları içerisinde oluşan arızayı aşamadığımızda farklı bir lokasyonda üretim verisine ulaşabilmeyi belirtirken; “local high availability” ise lokal bir kesintide, servisleri lokalde (aynı lokasyonda) bulunan “standby” sunucuda çalıştırabilir hale getirmeyi işaret eder.

İş sürekliliğinde (“business continuity”) de karşımıza çıkan terimleri tekrar gözden geçirelim. “Disaster Recovery”: kritik uygulamalara ve veriye alternatif bir lokasyonda tekrar ulaşabilmeyi işaret eder. “DR”, genel olarak Bilgi Teknolojileri (“Information Technology”) üzerine odaklanır. “DR” aslında iş bilgisine, iş bilgisini işleyen sistemlere uzak bir lokasyonda ulaşabilmeyi tanımlar. Uzak bir lokasyonda bu bilgilere erişim genellikle tape yedeklerinin, offsite tape vaulting özelliğinin ve veri replikasyonlarının kullanımıyla olur. “Business Recovery”: çalışanların işlerini tekrar icra edebilmeleri için gerekenlerin sağlanması üzerine odaklanır. Bu durumda lojistik ile ilgili bileşenlerde devreye girer. Örneğin telefon, ofis alanı, yaşam koşulları gibi.   “Business continuity”: iş süreçlerine alternatif bir lokasyonda tekrar ulaşabilmeyi tanımlar. “BC” nin daha geniş bir kapsamı vardır. “BC”, iş operasyonlarını yeniden başlatabilmek için ihtiyaç duyulan tüm süreci kapsar. Bilgi teknolojisi bileşenleri, insanlar, çalışma alanları, lojistik gibi kavramlar bu sürecin içerisinde yer alır. “Contingency planning”: herhangi bir felaket durumunda alınması gereken aksiyonları içeren planı tanımlar. Veritas, “DR” üzerinde odaklanmaktadır.

Verimiz ve sistemlerimiz için net tür tehlikeler mevcut? Bu tehditleri üç genel başlık altında inceleyebiliriz: lokal tehditler, lokasyon ile ilgili tehditler ve mantıksal tehditler. Lokal tehditler, lokal bileşenlerle ilgili hataları içerir. Örneğin, CPU hataları, disk hataları, HBA, NIC hataları, disk uniteleri hataları gibi. Lokal hatalar genellikle kesintiye neden olur. Lokal hataları “high-availability” ve “logical volume management” gibi çözümlerle adresleyebilirsiniz. Örneğin “high-availability” için Veritas Cluster Server, “logical volume management” için Veritas Volume Manager kullanılabilir. Lokal tehditlere karşı nasıl bir koruma sağlanabileceğini aşağıdaki şekil net anlatmaktadır.

Şekil: Lokal Tehditler

Mantıksal tehditleri, yazılımsal buglar, virüsler, veri bozulmaları, yalnışlıkla verinin silinmesi olarak düşünebiliriz. Mantıksal tehditler, lokal sahayı, DR’ı veya her ikisini etkileyebilir. Bu durumda ancak düzenli olarak alınan veri yedekleri hayatımızı kurtarabilir. HA ve DR sistemler asla rutin alınan veri yedeklerinin yerine geçemez. Misyon kritik uygulamalar için hızlıca servisleri geri getirmeyi sağlayan “snapshot” mekanizmaları bu amaç ile kullanılabilir. Aşağıda olan şekil bu tehdit ile ilgili özet bir bilgi vermektedir.

Şekil: Mantıksal tehditler

Lokasyonla ilgili tehditler, doğal felaketleri, diğer dış etkenlerin neden olduğu olayları içerir. Bu durumlarda hayatımızı “DR” stratejilerimiz kurtarabilir. “DR” stratejileri oluşturulurken hangi lokasyonda hangi tehlikelerin daha olası olduğunun analizinin iyi yapılması gerekir. “DR” stratejilerinde verinin farklı lokasyona replikasyonunu ve tek bir konsol üzerinden yönetilen global “HA” yapısını kesinlikle öneriyoruz. Lokasyonla ilgili tehditleri ve olası koruma yöntemlerini aşağıda olan şekil net olarak anlatmaktadır.

Şekil: Lokasyonla ilgili tehditler

“DR” planları yapılırken iki önemli kavram karşımıza çıkmaktadır: RTO ve RPO. Firmalar, iş ihtiyaçlarına göre uygun teknolojileri seçmelidirler. Bu kavramları aşağıda olan şekil üzerinden anlatmaya çalışacağım.

Şekil: RTO ve RPO Tanımları

T0-T1 aralığı, en son alınan yedek ile gerçek kesintinin olduğu an arasındaki zamanı ifade eder. Bu zaman farkı, ne kadar yeni verinin “DR” lokasyonunda olacağını belirler. RPO (“Recovery Point Objective”), zaman içerisinde bir nokta olarak tanımlanır. Öyleki iş süreçlerinin tekrar çalışabilir hale getirilmesi için hangi veriden geri dönülmesi gerektiğini işaret eder. T0-T1 aralığını daraltmak istediğinizde farklı teknolojiler arasında seçim yapmanız gerekmektedir. Şekilde görülen “Synchornous replication” diğer çözümlere göre daha pahalı bir çözüm olacaktır. Firmanın bir felaket anında ne kadar veri kaybını tolere edebileceğini iyi saptaması gerekir.

T1-T2 arasındaki zaman, bir kesintiden ne kadar sonra tekrar servislerin çalışabilir olacağını ifade eder. RTO (“Recovery Time Objective”) bu zaman aralığını ifade eder. İş ihtiyaçlarına göre RTO ve RPO belirlenir. RTO ve RPO belirlendikten sonra da uygun bir teknoloji seçilir. Örneğin bazı firmalar herhangi bir veri kaybını tolere edemezken, güncel veri ile servislerin 8 saat içerisinde açılmasını tolere edebilir.

Veritas’ın Sunduğu DR Teknolojileri

Veritas Volume Replicator (VVR)

VVR yapısını anlamak için Veritas Volume Manager’dan (VxVM) bahsetmeden geçemeyiz elbette. Aşağıda olan şekil, yapıda VxVM varsa hangi katmanda konumlandığını göstermektedir.

Şekil: “Logical Volume Management” Yazılımı

Bir “volume”ü sanal bir disk “device” olarak düşünebiliriz. Veri tabanları, uygulamalar, dosya sistemleri bu sanal diski fiziksel bir disk gibi düşünür. Buna rağmen, sanal disk fiziksel diskin sahip olduğu limitasyonlara sahip değildir. VxVM ile oluşturulan sanal disk “device”, RAID yapılarını destekler. “Concatenation”, “striping”, “mirroring”, “mirror-stripe”, “stripe-mirror” desteklenen RAID yapılarıdır. Yukardaki şekilde görüldüğü gibi, ortamda eğer “logical volume management” yazılımı yoksa, işletim sistemi disklerle doğrudan iletişime geçer. Eğer ortamda “logical volume management” uygulaması varsa, işletim sistemi veriyi VxVM’e transfer eder. VxVM sanal disk “device” yapısına göre yazma işlemlerini uygun bir şekilde yerine getirir.

Uygulama bazında VxVM ve VVR katmanları devreye girdiğinde nasıl bir farklılık oluşuyoru netleştirmek adına aşağıda bir kaç şekil faydalı olacaktır.

İlk şekilde herhangi bir “logical volume management” yazılımı yoktur.

Şekil: Uygulama katmanı

Şimdi bu yapıya VxVM katmanını ekleyelim. Bu durumda yazma işlemleri fiziksel disklere değil VxVM tarafından oluşturulan sanal disk “device”lara yapılacaktır.

Şekil: VxVM katmanı

VVR, uygulama ve “logical volume management” yazılımı arasından konumlanır. Bu durumda tüm yazma işlemleri tutulur ve ikincil sisteme kopyalanır.

Şekil: VVR Katmanı

VVR, Veritas Volume Manager’ın bir opsiyonudur. Lisans ile aktif hale getirilebilir. VVR, kaynaktan bir veya daha fazla uzak alana replikasyon yapabilir. Replikasyon mantığını anlamak için VVR’ı bileşenlerinden bahsetmek gerekiyor. Aşağıda olan şekil VVR yapısında kullanılan bileşenleri özetlemektedir.

Şekil: VVR Bileşenleri

İlk önemli kavramımız RVG’dir (“Replicated Volume Group”). RVG’yi bir veya birden fazla ikincil sisteme replikasyonu yapılmak istenen tüm “volume” lerin gruplandığı yapı olarak düşünebiliriz. Replikasyonu yapılan ikincil alanlardaki verinin bütünlüğü çok önemlidir. Bu bütünlük RVG içinde yapılan “write order fidelity” ile sağlanır.

Şekil: RVG Yapısı

İkinci önemli kavramımız RDS’dir (“Replicated Data Set”). Kaynak sistem üzerinde bulunan RVG ve onun tüm hedef (ikincil sistemler) sistemler üzerindeki eşlenikleri bir bütün olarak RDS’i oluşturur. RDS, bir obje değil sadece bir kavramdır. Pek çok VVR komutu RDS üzerinde çalışır.

Şekil: RDS Yapısı

Üçüncü önemli kavramımız RLINK’dir (“Replication Links”). RLINK, ikincil RVG’ye olan VVR replikasyon linkidir. Primary (Kaynak/birincil sistem) RVG üzerinden bulunan her RLINK, Primary RVG’den kendisine karşı gelen ikincil (secondary) RVG’ye olan iletişim linkidir. Primary RVG, birden fazla RLINK’e sahiptir. Her primary RVG, maksimum 32 RLINK’e sahip olabilir.

Dördüncü önemli kavramımı SRL (“Storage Replicator Log”)dur. RVG’deki yazma işlemleri için dairesel buffer alanıdır. Her RVG, bir tane SRL içerir. Disk üzerine yapılan her yaz işlemi iki tane “write” işlemi üretir: bir tanesi SRL; diğeri ise data volume içindir. SRL, sayesinde “Write Order Fidelity” korunur.

Şekil: SRL Kavramı

Acaba VVR senkron replikasyon durumunda veri akışı ne şekilde olmaktadır?

Şekil: Senkron Replikasyon

VVR senkron modda kullanılıyorsa, VVR, “write” işleminin tamamlandığını belirten bilgilendirmeyi uygulamaya göndermeden önce ikincil lokasyondan bir doğrulama mesajı bekler. Sıralama şu şekilde gerçekleşmektedir.

  • 1. Uygulamadan bir “write” işlemi alınır.
  • 2. Bu “write” işlemi SRL’e yazılır.
  • 3. Bu “write” işlemi ikincil lokasyonlara tüm senkron RLINK’ler üzerinden gönderilir.
  • 4. “Write” işleminin ikincil sisteme ulaştığına dair bir network bilgilendirmesi birincil sisteme gider ve aynı anda bu “write” işlemi birincil sistemdeki “data volume”e yazılır.
  • 5. İkincil sistemde bu “write” işlemi data “volume” lere yazılır ve birincil lokasyonda uygulamaya “write” işleminin ikincil sistemde tamamlandığına dair bilgilendirme gider.
  • 6. İkincil sistemde bu “write” işlemi data “volume” lere yazıldıktan sonra, birincil sisteme veri bilgilendirmesi gider.
  • 7. SRL’e ilgili “write” işleminin yapıldığına dair işaret konur.

Senkron modda performansı, birincil sistemde SRL’e “write” işleminin yazılması ve ikincil sistemden network bilgilendirmesinin gelmesi süresi belirler.

Asenkron modda, veri akışı senkron moda göre daha basittir.

Şekil: Asenkron Replikasyon

Asenkron modda, uygulamadan alınan “write” işlemi birincil sistemde SRL’e yazıldıktan hemen sonra uygulamaya “write” işleminin yapıldığına dair bilgilendirme gider ve aynı anda bu “write” işlemi birincil sistemdeki “data volume” lere yazılır.

VVR işleyişinde önemli bir bileşen daha vardır: DCM (“Data Change map”). DCM, SRL dolduğunda, tekrardan “full” senkronizasyona gerek kalmaması için “write” işlemlerini takip eder. DCM’i bit haritası gibi düşünebiliriz. SRL, yazma işlemlerinin artık karşılayamayacak duruma geldiğinde (SRL overflow) DCM aktif hale gelir. DCM aktif olduğunda, set edilen her bit; primary ve secondary içeriklerinin farklı olduğu alanları ifade eder. DCM’in senkronizasyonu başladığında, ikincil sistemde olan veri bütünlüğü kaybolur çünkü bu aşamada “write order fidelity” korunmaz. DCM senkronizasyonu tamamlandıktan sonra veri tutarlı olur ve replikasyon olağan şekilde devam eder.

VVR’ın sunduğu senkron ve asenkron replikasyonların herbirinin avantajları ve dezavantajları vardır. Senkron replikasyonda uzak lokasyonda güncel veri tutulurken, uygulama performansından feragat edilir. Asenkron replikasyon uygulama performansını çok daha az etkilerken uzak lokasyondan güncel verinin bulunacağını garanti etmez. Her iki replikasyonun avantajlarından fayda sağlamak için; birincil lokasyona yakın bir lokasyona senkron replikasyon yapılırken uzak lokasyona asenkron replikasyon yapılabilir. Bu durumda da üç farklı veri merkezinde verinin üç tam kopyası gerekir. Eğer veri miktarınız çok fazlaysa bu çözüm pahalı olabilir. Bu durumda VVR 5.0 ile gelen senkron ve asenkron replikasyonun avantajlarını birleştirerek kullanan “bunker” replikasyondan bahsetmemiz uygun olacaktır.

“Bunker” replikasyonda birincil lokasyona yakın bir lokasyonda SRL’in kopyası tutulur. Bu lokasyon “bunker” lokasyon olarak isimlendirilir. Eğer birincil lokasyonda bir sorun olursa, “bunker” lokasyondaki SRL, ikincil lokasyondaki veriyi güncel hale getirmek için kullanılır. “Bunker” replikasyonda sadece SRL için ek depolama alanı ihtiyacı olur.

Şekil: Bunker Replikasyon

Snapshot Mekanizması

Nihayet Snapshot mekanizmalarından konuşmaya başlayacağız. VVR, “online” data “volume” lerin istenilen bir zaman için “snapshot” larının oluşturulmasına imkan sağlar. Orijinal data “volume” de veri değişebilir ama snapshot’lar kararlı ve bağımsız bir kopya olarak farklı amaçlarda kullanılabilir. VVR, snapshot oluşturmak için iki farklı yöntem sunar: anlık (“snapshot”) snaphot ve geleneksel (“traditional”) snapshot. Önemli bir not, eğer ikincil lokasyondaki RVG tutarlı değilse, bu RVG altındaki “volume” ler için snapshot oluşturmanıza VVR izin vermeyecektir.

“Instant snapshot” özelliği VVR’dan ayrı lisanslanmaktadır. Bu yöntemin geleneksel snapshot yöntemine göre avantajı snapshot’ların hemen kullanıma hazır olmasıdır ve bu snapshot’ların space-optimized olarak oluşturulabilmeleridir. Yani, geleneksel snapshot’lara göre daha az yer kaplarlar. Geleneksel snapshot’larda “volume” ün büyüklüğüne bağlı olarak plex’lerin başlangıç senkronizasyonu için gereken zaman çok büyük olabilir. Bir “volume” için aynı anda hem geleneksel hem de anlık snapshot kullanamazsınız.

“vxrvg snapshot” komutuyla anlık snapshot’lar oluşturulabilir. Bu komut RVG içindeki data “volume” lerin snapshot’larını alır. Bu alınan snapshot “volume” ler RVG’nin bir parçası olmayacaktır. RVG içindeki her data “volume” ün birden fazla snapshot “volume”ü olabilir. “full-instant” veya “space-optimized” snapshot’lar oluşturulurken, snapshot “volume” lerin öncesinde senkron olmasına gerek yoktur. Bu nedenle snapshot’lar hemen kullanılabilir durumdadır. Bu snapshot’lar daha sonra “background”da senkron olurlar.

“Instant full” snapshot “volume”, orijinal “volume” ile aynı büyüklükte olacaktır. “vxrvg -F snapshot” komutuyla oluşturulur. “Instant space-optimized” snapshot’lar “vxrvg -S snapshot” komutuyla oluşturulur. Bu snapsho’lar “cache” alanı kullanır. Sadede değişen verilerin orijinal şekli bu “cache” alanda tutulacağı için daha az yer kaplarlar. Geleneksel snapshot özelliğine benzer bir şekilde “instant plex-breakoff” snapshot’larda oluşturabilirsiniz. Geleneksel snapshot yönteminde bildiğimiz “mirror” plex’ler dışarı çıkarılır.

FastResync (FR) dediğimiz özellik sayesinde, “mirror” yapıdaki “volume” den “plex” dışarı alınabilir, üzerinde işlemler yapıldıktan sonra, tekrar orijinal “volume” e geri eklendiğinde tam bir senkronizasyona gerek kalmadan sadece değişen verilerin senkronizasyonu sağlanabilir.

VVR yapıda “off-host processing” de yapabilirsiniz. Bu yapıda VxVM’in FastResync özelliğini In-Band Control (IBC) mesajlaşma fonksiyonuyla kullanabilir ve böylece uygulama bazında tutarlı snapshot’lar oluşturabilirsiniz. Özellikle DSS (“Decision Support Systems”) ve backup yapılarında “off-host processing” çok kullanılan bir yöntemdir. Bu sayede üretim ortamındaki sistemi, bazı süreçleri farklı bir sistem üzerinde yaparak rahatlatmış olursunuz. İkincil sistemde veriye erişimin genel modeli, RVG’de bulunan her bir data “volume” için “mirror plex” i dışarı çıkarmak, üzerinde işlem yapmak ve bu “plex”i tekrar “volume”e eklemek şeklindedir.

İkincil sistem üzerinden alınan “snapshot”ın uygulama seviyesinde tutarlı olmasını garantilemek için IBC kullanabileceğimizden bahsettik. Çalışma mekanizmasını aşağıda olan şekil üzerinden açıklamak istiyorum.

Şekil: IBC Mesajlaşma

Şekilde, n. “write” işleminden sonra IBC mesajın ikincil sisteme gönderildiğini görüyoruz. IBC mesajı ikincil lokasyondaki sisteme ulaştığında ikincil sistemdeki data “volume” üzerine n. “write” işlemi yazılır ve sonra gelen “write” işlemleri ikincil lokasyondaki SRL’e yazılmaya başlanır. Yani ikincil sistemdeki data “volume” lere herhangi bir şey yazılmaz. Bu durumun veritas dökümanlarında “replication freeze” olarak ifade edildiğini göreceksiniz. Şuna dikkat etmeniz önemlidir. Bu noktada birincil sistemden veriler hala gönderilmeye devam edilir ama bu veriler ikincil sistemdeki SRL’e yönlendirilir. Bu durumda uygulama seviyesinde bütünlük sağlandığı için istenen aksiyonlar alınır (örneğin snapshot’ların alınması gibi) ve replikasyon tekrar “unfrozen” yapılır. Yani ikincil SRL’a alınan “write” işlemleri ikincil data “volume” e yazılmaya başlar. İkincil SRL’deki “write” işlemleri eridikten sonra birncil sistemden gelen “write” işlemleri artık doğrudan ikincil sistemdeki data “volume” lere yazılmaya başlanır. IBC mesajı ikincil lokasyona ulaştıktan sonra akışın nasıl olduğunu yine aşağıda olan şekilden görebiliriz.

Şekil: IBC Mesajlaşma

Veritas Volume Replicator, host bazlı güvenilir bir replikasyon yöntemi olarak kullanılabilir. VVR, uzak lokasyona blok bazlı bir replikasyon yapmaktadır. VxVM’in VVR ile birlikte kullanımıyla uzak lokasyonda IBC’i de sürece dahil ederek uygulama bazında tutarlı snapshot’lar alınabilmektedir. Konuyla ilgili daha fazla detay almak isterseniz support@gantek.com ile iletişime geçebilirsiniz.

22 Ekim 2016 Cumartesi – Asiye Yiğit

Kaynakça:

Veritas Admin Kılavuzları