Bu bölümünde özellikle felaket senaryoları için vazgeçilmez olan Replication'ı anlatmaya çalışacağım. Tabi makaleye başlamadan önce birkaç felaket durumu ve yanlışlıkları ile ilgili birkaç bilgi vermek istiyorum. Felaket durumu deyince aklımıza ilk deprem, sel, yangın gibi olaylar geliyor. Bu gibi durumlarda yakında bulunan her şeyi kapsayacağından felaket senaryolarında mutlaka farklı bir bölge de sistemlerimizin yedeklerinin tutulması gerekiyor. Bizlerde yapılan yanlışlıklar ise bunları maliyetini düşürmek için yakın lokasyonlar seçerek yapınca ortaya çıkıyor. Sanki yangın çıkınca veya deprem olunca yakın lokasyonada da olmayacakmış gibi düşünüyoruz. Bazılarınızı duyar gibiyim deprem olmuş ben ölmüşün ne sistemi, ne yedeği der gibi. İşin acı gerçeği bizler ölsek de o sistemler yaşamalı.

Replication

Storage tarafında replication; var olan storage üzerindeki önemli volumelerimizin bir başka bölgede bulunan diğer storage üzerine o volumelerin birebir eşlenme işlemine denir. Replication'da önemli olan konulardan biri zamandır. Çünkü sizin için verilerin ne kadar kritik olmasına göre seçeceğiniz replication türü de değişecektir. Zaman kavramları için Recovery Point Objective/ Recovery Time Objective diye adlandırdığımız iki faktör devreye girecektir. Bu iki kavramı backuplarda da duymuş olabilirsiniz mantık olarak aynı sadece işlev olarak biraz farklılık gösteriyorlar.

 

RPO/RTO

Var olan yapının diğer bölgedeki yapıyla arasında geçen eşleşme süresine yani potansiyel bir felaket sırasında kaybolabilir veri miktarını yansıtan süreye RPO deriz. Şöyle bir örnekle açıklamaya çalışayım; diyelim ki saat 16:00'da storage'ınız arızalandı ve sizin replica sitenız ise 4 Saat'te bir güncelleme yapıyor. En son güncelleme ise saat 13:00'de yapılmış olsun. Arada 3 saatlik bir kayıp var demektir. Fakat siz 4 saat günceleme zamanı koyduğunuzdan ötürü 4 saatinizi riske edebilmişsiniz demektir. İşte bu 4 saatlik süre sizin maximum RPO sürecinizdir. Eğer RPO'nuz sıfır olsun istiyorsanız Synchronous Replication tek çözümdür.

RTO ise sizin olası bir felaket durumunda sistemi ne kadar sürede tekrar devreye aldığınız zamandır. Tabi bu da sizin diğer lokasyonda birincil lokasyonuzda ki server'a eşdeğer bir sunucu bulundurma ve bağlanma süreniz ve kullanmış olduğunuz storage marka ve modeline göre eleman bulundurup bulundurmadığınıza göre değişkenlik gösterebilmektedir.

 

Synchronous Replication
 

Synchronous Replication'da ilk olarak sunucudan gelen veri kaynak volume'e yazılır fakat acknowledge paketi sunucuya geri iletilmez. İkinci adımda veri hedefteki volume'e yazılır ve hedef volume acknowledge paketini kaynağa gönderir. Son adımda kaynak volume server'a acknowledge paketini gönderir ve veri yazılmış olur. Bu süreç bitene kadar veri sunucuya yazılmaz. Burada RPO süresi 0 olarak RTO süreside kullandığınız teknolojiye göre değişkenlik gösterebilir. O yüzdendir ki aradaki bağlantı çok önemlidir. Çünkü diğer lokasyona erişim sırasında bir sorun olursa sizin tarafınızda da verinin bozulmasına sebep verebilir. Düzgün bir alt yapınız yoksa bu yöntemi seçmeniz tavsiye edilmez. Hatta ve hatta yedekli hatlar ile gitmeniz tavsiye edilir. O yüzdendir ki bu Synchronous Replication'da Fiber altyapılı hatlar kullanılması tavsiye edilir. Eğer hat fiber ise fiberde Km başına 0,005 ms kayıp vardır. Storagelar arası Synchronous Replication'da tavsiye edilen  ms değeri (verinin yazılması ve bilgi paketinin geri gelme süreside hesaplandığında) 1ms'yi geçmemelidir. O yüzden iki storage arası en fazla 100 km uzaklıkta olması tavsiye edilir. Maximum destek ise 5ms'dir bu da 500 km'ye ulaşan bir destek var diyebiliriz ama o kadar uzak lokasyon seçilmemesi daha çok tavsiye edilir. Lakin böyle bir altyapı hem çok pahalı hem de her yerde fiber bir altyapı bulmak mümkün olmayacağından daha ucuz ve alternatif çözümler bulmak gerekebilir. Bu alternatiflerden biride Asynchronous Replication'dır.

 

 

 

Asynchronous Replication

Bu yöntem Synchronous Replication'a göre daha az maliyetli ve daha az bandwitdh ihtiyacı bulunmaktadır. Asynchronous Replication'da ilk olarak sunucudan gelen veri kaynak volume'e yazılır ve acknowledge paketi sunucuya geri iletilir ve veri yazılmış olur. Üçüncü adımda sizin belirtmiş olduğunuz synchronize süresinde veri hedefteki volume'e yazılır ve hedef volume acknowledge paketini kaynağa göndererek işlem tamamlanmış olur. Burada RPO süresini siz belirliyorsunuz ve buna göre synchronize süresini storage'ta ayarlıyorsunuz. Peki, bunu neye göre belirlemeliyiz bir örnekle açıklamaya çalışayım.

Diyelim ki 5 TB'lık bir volume'ünüz var ve her gün değişen 40GB'lık veriniz var. En fazla da 4 saatlik bir kayıp göz ardı edilebiliyor olalım. O zaman bizim RPO süremiz 4 saat demektir ve 4 saatte bir veri diğer lokasyonda bulunan storage'a veriler synchronize edilmelidir. Ama ilk önce 5TB'lık ilk volume verisi diğer lokasyonda bulunan storage'a geçmeli ve bunun için diğer storage'ı aynı lokasyona getirip ilk synchronize işlemini aynı yerde yapmanız tavsiye edilir. Ondan sonra sadece değişen verileri göndererek çok yüksek bandwitdh ihtiyacımız olmasına gerek kalmaz. Burada altyapımız değişen verinin 4 saatte bir gidecek kadar bandwitdh'e sahip olması gerekir. Değişen verimiz 4 saatte 40GB'tı. O zaman bunu şu şekilde hesaplayabiliriz; Bandwitdh = bit/sn ise byte'ı bit'e çeviremek için 8 ile çarpmamız gerekir.

40GB/4Saat *8= 40960MB/14400Saniye *8= 2,8777MB/Sn*8= 22,8Mbit/sn'lik bir bandwitdh olmalıdır.

Kısacası elinizde ki bandwitdh değerine göre bunu kendinizde hesaplayabilirsiniz. Değişen verilerin boyutunu değiştirmek sizin elinizde olmayacağından10Mb/sn'lik bir bandwitdh'niz varsa süreyi uzatarak bu problemi çözebilirsiniz ya da bandwitdh değerinizi arttırmaya çalışabilirsiniz.

 

 

 

Umarım Replication konusunda fikri olmayanlar veya süre hesaplamayı bilmeyenler için yaralı olmuştur. Biz sonraki makalemde görüşmek üzere.

 

SELÇUK SAVAŞAL

DANIŞMAN / KURUMSAL VERİ MERKEZİ VE SANALLAŞTIRMA BİRİMİ, KURUMSAL VERİ MERKEZİ VE SANALLAŞTIRMA BİRİMİ