Azure Storage Services – Part 6:Redundancy

Makale serimizin önceki bölümlerinde farklı Azure storage opsiyonlarını ve ölçeklenebilirlik limitlerini inceledik. Yazıların bir kısmında ise storage hizmetinin ve dolayısı ile içerisindeki farklı veri tiplerinin (blob, entity, mesaj) yedeklilikleri için bu makalemizi referans gösterdik.

Azure tarafındaki redundancy opsiyonlarını incelemeden önce bir önceki makalede yaptığımız gibi Redundancy terimini inceleyelim.

http://en.wikipedia.org/wiki/Redundancy

Mühendislikte de sıklıkla kullanılan Redundancy aslında kritik bir sistem içerisindeki kritik bileşenlerin birden fazla şekilde yapılandırılması ile bir yedeklilik yada koruma yöntemi oluşturulmasıdır. Sistemin kritiklik seviyesi yükseldikçe tutulan koruma/yedek sayısı da artacaktır. Örneğin uçaklarda bulunan bazı kritik bileşenlerin herhangi bir sorun oluştuğunda devreye girmesi için 2 farklı ek kopyası daha bulunur.

Bilişim teknolojilerinde de redundancy terimini sıklıkla kullanırız. Özellikle veri tabanı sistemlerinde kritik verinin iki yada daha fazla tabloda daha tutulması ile bu verinin yedekliliği sağlanmış olur.

Makale serisinin başından beri sürekli savunduğumuz arguman Azure’un en kritik uygulamalarınızı bile barındırabilecek teknolojiye sahip olduğu ve ihtiyaçlarınızı karşılayabildiğidir. Uygulama içerisinde en önemli bileşen olan verinin Azure içerisindeki güvenliği aslında bu argumanın en önemli noktası. Bu sebeple Microsoft Azure storage hizmetleri içerisinde hizmet bağımsız barındırılan verilerin tamamı yüksek erişilebilirlik ve yedeklilik sağlanması amacı ile koruma altına alınmıştır.

Bu makale bu korumanın detaylarını inceliyor olacağız.

Öncesinde Azure tarafından sunulan SLA taahhütlerini incelemekte fayda var.

http://azure.microsoft.com/en-us/support/legal/sla/

Görüldüğü gibi Storage bölümünde aşağıdaki ibareler mevcut.

  • We guarantee that at least 99.99% of the time, we will successfully process requests to read data from Read Access-Geo Redundant Storage (RA-GRS) Accounts, provided that failed attempts to read data from the primary region are retried on the secondary region.
  • We guarantee that at least 99.9% of the time, we will successfully process requests to read data from Locally Redundant Storage (LRS), Zone Redundant Storage (ZRS), and Geo Redundant Storage (GRS) Accounts.
  • We guarantee that at least 99.9% of the time, we will successfully process requests to write data to Locally Redundant Storage (LRS), Zone Redundant Storage (ZRS), and Geo Redundant Storage (GRS) Accounts and Read Access-Geo Redundant Storage (RA-GRS) Accounts.

Azure Storage hizmetlerinde redundancy sağlanabilmesi için farklı replikasyon yöntemleri kullanıma sunulmuştur. Bu makalemizde sunulan replikasyon çeşitlerini detaylı şekilde inceliyor olacağız.

Locally Redundant Storage (LRS)

LRS replikasyon yönteminin size sağladığı temel fayda storage hesabınız içerisinde tutulan verinin 3 farklı kopyasının aynı bölgedeki veri merkezinde tutulmasıdır. Yani hesabınızı oluşturduğunuz bölgeye göre oluşturulan tüm verilerin 3 farklı kopyası yine aynı meri merkezi içerisinde tutulacaktır.

Diğer replikasyon yöntemleri ile karşılaştırıldığında daha ekonomik bir çözüm olan LRS’sin en büyük handikapı bölgesel yada veri merkezi seviyesinde oluşabilecek problemlere karşı dayanıklı olmamasıdır. Verilerinizin bulunduğu donanım üzerinde gerçekleşen bir problemde diğer kopyalardan uygulamanız çalışmaya devam edebilir ancak veri merkezinin tamamını etkileyen bir kesinti durumunda sizin de verilerinize erişiminiz kesintiye uğrayacaktır.

LRS tanımı depolama hesabı oluşturma aşamasında belirlenir.

image

Geo-Redundant Storage (GRS)

GRS’in LRS’den en büyük farklı tutulan ek kopyaların aynı veri merkezinde değil farklı bir veri merkezinde barındırılmasıdır. Bu da otomatik olarak size bölgesel yada kıtasal oluşacak problemlerde dahi koruma sağlayacaktır.

Bu sebeple kritik uygulamaların verilerinin GRS ile korunması şiddetle önerilir. GRS ile korunan bir depolama hesabında yazılan veriler öncelikle Primary olarak seçilen veri merkezine gönderilir ve 3 farklı kopyası yine bu veri merkezinde farklı donanımlarda tutulur. Ardından ise bu veri ikinci bir veri merkezine gönderilir ve burada da 3 farklı kopyası ayrı donanımlarda tutulur. Böylece GRS ile verinizin 6 farklı kopyasını dünya üzerindeki farklı veri merkezlerinde tutmuş olursunuz.

GRS replikasyonunun seçilmesi aynı şekilde depolama hesabı oluşturulması esnasında gerçekleştirilir.

image

Yukarıdaki ekranda seçilen bölge (West Europa) birincil veri merkezi olarak yapılandırılır ve gönderilen tüm veriler ilk önce bu veri merkezindeki 3 kopyada saklanır. Ardından ise aşağıdaki tabloya göre otomatik olarak ikinci veri merkezi belirlenir ve asenkron kopyalama başlatılır.

image

Herhangi bir failover durumunda failover seviyesinin Stamp olduğunu unutmamak gerekiyor. Yani disaster durumunda tek bir storage hesabının taşınması yerine Stamp içerisinde tüm storage hesapları ikincil veri merkezlerine taşınacaktır. Herhangi bir failover durumunda ilgili tüm Azure Storage müşterilerine bir notifikasyon iletilir. Ardından müşterilerin account.-servisismi-.core.windows.net ismindeki DNS girdileri primary veri merkezindeki secondary veri merkezine yönlendirilmesi gerekmektedir.

Bu yönlendirme ile birlikte var olan Blob, Table ve Queue URI’leri tekrardan aktif olarak çalışmaya başlayacaktır. Böylece URI değişikliğini uygulama seviyesinde yapmanıza gerek kalmadan aynı URI ler ile ikincil veri merkezinden hizmet vermeye devam edeceksiniz.

Dikkat edilmesi gereken bir diğer nokta da aradaki replikasyonun asenkron olmasıdır. Bu da verilerin öncelikle primary veri merkezinde sonrasında ise ikinci veri merkezine bir süre sonra  yazılması manasına gelmesidir. Bu sebeple bir disaster anında ikincil veri merkezindeki verilerin son güncellemeleri alamamış olması beklenebilir. Bu tarz disaster senaryolarında RTO (Recovery Time Objective) değerleri önemlidir. Azure RTO ile ilgili bize herhangi bir SLA sunmamasına rağmen 15 dakikadan daha az şeklinde bir değer belirtir. Yani en fazla 15 dakikalık yazılan verilerinizi kaybedebilirsiniz şeklinde anlayabiliriz.

Diğer kritik değer de RTO (Recovery Time Objective) ‘dir. Bu da ne kadar sürede failover işleminin gerçekleştirileceğini belirtir. Azure bu noktada bize bir süre vermez çünkü bu sürenin var olan problemin keşfedilmesi, recover yapılmasına karar verilmesi ve DNS kayıtlarının değiştirilmesi gibi değişkenlere bağlı olduğunu savunur. Microsoft tarafındaki ilk aksiyon primary veri merkezinde tekrardan erişimin açılmasıdır. Ancak problemin devam edeceği ön görüldüğünde ikinci veri merkezi devreye alınır.

Read-Access Geo-Redundant Storage (RA-GRS)

RA-GRS ise GRS ile gerçekleştirilen ikinci veri merkezi replikasyonuna ek olarak ayrıca ikinci veri merkezindeki veriye read-only erişim izni verir. Böylece uygulamalar birincil veri merkezinde çıkan bir sorun sonrasında ikinci veri merkezinden veri okuma işlemini hızlıca gerçekleştirebilir.

Bu replikasyon modelini seçtiğinizde GRS’e ek olarak size ikinci bir erişim URI’si sunulur. Primary veri merkezi erişimi için hesap.blob.core.windows.net adresinden erişim sağlanırken, RA-GRS aktif edildiğinde ayrıca hesap-secondary.blob.core.windows.net URI’sine sahip olursunuz.

Azure tarafındaki failover aksiyonunu beklemeden primary URI üzerinde erişim sağlanamadığı anda uygulamalarınızın ikinci URI’den verileri okumasını sağlayabilirsiniz.

Bu replikasyon modeli aynı şekilde hesap oluşturulurken seçilebilir.

image

Zone-Redundant Storage (ZRS)

Son replikasyon/redundancy modeli ise ZRS’dir. Yalnızca block bloblar için kullanılabilir olan bu replikasyon modelinde LRS ile GRS arası bir opsiyon sunulur.

LRS’den farkı iki yada üç farklı kopyayı aynı bölge içerisindeki farklı veri merkezlerinde tutabilmesidir. Bölge aynı kalmak şartı ile birbirinden farklı lokasyonlardaki veri merkezlerinde bu kopyalar tutulabilir. Özetle tam olarak veri merkezi seviyesinde gerçekleşecek problemlerin önüne geçmek için hizmete sunulan bir özelliktir.

Yapılandırma için benzer adımlar izlenebilir.

image

Görüldüğü gibi Azure Storage hizmetleri ile birlikte farklı replikasyon/redundancy çözümleri sunulmaktadır. Fiyat detayları ile birlikte uygulamalarınızın kullandığı verilerin kritikliğini göz önüne alarak seçimi gerçekleştirmelisiniz.

Yukarıda gördüğümüz gibi temel sıralama

RA-GRS > GRS > ZRS > LRS şeklindedir.

Oluşturulan depolama hesaplarını replikasyon modelleri panel üzerinden değiştirilebilir.

image

Şimdilik ZRS replikasyon modeli ile oluşturulan storage hesaplarının farklı replikasyon modellerine değiştirilmesi desteklenmemektedir.

One thought on “Azure Storage Services – Part 6:Redundancy

Leave a Reply

Your email address will not be published. Required fields are marked *

42 − = 40