Daha önceki makalelerimde Azure üzerinde mimari tasarım yapılırken region ve network ile ilgili göz önünde bulundurulması gereken özellikleri ele almıştım. Bu bölümde ise storage account’lardan, mimarisinden ve önerilen konfigürasyonlarından bahsedeceğim.
Eminim storage account ile ilgili bir çok makale yazılmıştır. Bu makale teknik özelliklerden çok arka plandaki çalışma mantığı ve dizayn yapılırken göz önünde bulundurulması gereken durumları içermektedir. Bu yüzden daha öncesinde storage account’lar ile ilgili teknik bilgi edinmek isterseniz aşağıdaki kaynaklardan faydalanmanızı öneririm.
https://docs.microsoft.com/en-us/azure/storage/common/storage-account-overview
Resim-1
Storage accountlar onları kullanan uygulama bileşenleri ile aynı region’a deploy edilmeleri gerekir. Bunun iki önemli sebebi var. Birincisi performans ikincisi ise maliyettir.
Aynı datacenterdaki servisler Azure omurgasını kullanacakları için iletişimleri daha hızlı olacaktır. Buna ek olarak aynı datacenter’daki servisler iletişimleri sırasında aynı omurgayı kullanacakları için herhangi bir network maliyeti oluşmayacaktır.
Azure üzerindeki her bir storage account’un belli bir kapasitesi ve transaction rate’i vardır.
Normal bir storage account maksimum 500TB data saklayabilir. Eğer daha fazla alana ihtiyaç duyulursa birden çok storage account oluşturulabilir yada premium storage kullanılabilir.
Bir storage’a yapılacak olan IOPs değeri de 20000 ile sınırlıdır. Buda yönetilen datanın saniyede 60MB olduğu anlamına gelir. Bunun üzerinde yapılacak IOPS yada saniyede işlenecek data, işlemlerde dar boğaza sebep olacaktır.
Uygulamalar için bu miktarlar yeterli değilse storage account sayısı arttırılabilir yada premium storage account kullanılabilir.
Virtual machine’lerde kullanılacak data disk sayısı ve size’ı virtual machine’in size’ına bağlı olarak değişir. Yüksek size’daki Vm’ler daha yüksek IOPS değerlerine sahiptir ancak bu değerler storage account’un limiti olan 20000 IOPS ve saniyede 60MB ile sınırlıdır.
(Yeni çıkan ultra SSD diskler ile bu değerler 160K’lara ulaşmıştır)
VM’lerin diskleri aynı storage account içerisine koyulduğunda 20000 IOPS ulaşılabilir bir değer olabilir. Bu değere ulaşıldığında ise VM performansları ciddi anlamda etkilenir. VM’leri yöneten sistem adminlerin bu durumu göz önünde bulundurmaları ve dizaynlarını buna göre yapmaları gerekir. Bu iş yükünü ortadan kaldırmak için VM’lerde Managed disk’ler kullanılmalıdır. Managed Disk’ler kullanıldığında Microsoft bizim adımıza IOPS hesaplamalarını yapıp makine performanslarının IOPS’a bağlı olarak düşmesini engeller. Bunu da gerektiği koşullarda arkaplanda yeni storage account’lar oluşturarak yapar.
Genelde anonymous erişimleri engellemek için Azure storage accountlara erişirken SAS token‘lar kullanılması önerilir.
Burada dikkat edilecek nokta blob storage içerisinde farklı tip ve kategorilerde container’lar oluşturup bunların her biri için farklı SAS token’lar kullanmaktır. Bu SAS token’larda çalınmalara karşı belli aralıklar ile değiştirilmelidir.
Uygulama geliştiriciler genellikle storage account içerisindeki blobları cache’lerler. Burada cache’lenen datanın güncel olması için önerilen last modified property‘sine göre tekrardan cache’deki data’yı güncellemektir.
Azure storage account aynı anda kullanım özelliği ile aynı dosya ve verinin eş zamanlı olarak birden çok kullanıcı tarafından modifiye edilip edilmediğinden emin olur. Bunu sağlarken de storage üzerinde kullanılan servise göre üç farklı modeli kullanır;
- Optimistic concurrency : Bu özellik bir dosya üzerinde birden fazla kullanıcının modify etmesine izin verir. Ancak eğer bir değişiklik olursa kullanıcıları dosyayı refresh etmeleri konusunda uyarır. Table service için varsayılan özelliktir.
- Pessimistic concurrency : File serviste kullanılan aynı anda kullanım özelliğidir. SMB kullanarak bir uygulama bir dosyayı update ediyorsa dosyayı aynı zamanda kilitler. Diğer uygulamalar o dosya üzerinde o anda işlem yapamazlar. File service ile SMB protokolü kullanılarak dosyaya erişildiğinde kullanılan varsayılan özelliktir.
- Last writer wins: Bu özellik ile dosyaya en son yazan kullanıcı dosyayı ilk aldığı andan itibaren geçen sürede üzerine yaptığı değişiklikler ile kaydeder. Bu queue,blob ve file servis(Eğer REST API ile erişiliyorsa) için varsayılan özelliktir.
Storage üzerinde kullanılan içeriklerin tiplerine göre tanımlanması da önerilen konfigürasyonlar arasındadır.
Storage account’a yapılan kopyalama işlemleri dosya büyüklüklerine bağlı olarak uzun sürebilir. Bu süreyi düşürmek için dosyaları paralel upload etmek önerilir. Storage account üzerine paralel kopyalama işlemlerini yapabilirsiniz.
Azure üzerindeki blob storage’lar iki tipte bulunurlar. Bunlar block blob ve page blob’tur. Tutulacak içeriğin tipine göre doğru blob türünün seçilmesi gerekir. Örneğin Vm’lere ait VHD formatındaki işletim sistemi diskleri için page blob’lar seçilmelidir.
Azure storage üzerindeki dosyalar için en iyi şekilde ulaşılabilirlik sağlanmak isteniyorsa CDN entegrasyonu yapılması önerilmektedir.
Ayrıca var olan static içeriklerin direkt olarak Azure storage üzerinden servis edilmesi önerilir. Böylece yayınlama için kullanılan maaliyetler azaltılmış olacaktır.
Azure Storage’ın en efektif şekilde nasıl kullanılması gerektiğini özetlemiş olduk.
Referanslar
https://docs.microsoft.com/en-us/azure/architecture/
https://docs.microsoft.com/en-us/azure/architecture/patterns/
Azure for Architects Ebook
TAGs: Azure Design Pattern, Azure for Architects, Azure Architect, Azure Region Design Pattern, Azure IAAS Planning, Azure SAAS Planning, Planning Azure Architecture, Azure Architecture Best Practises, Azure Regions and Zones, Azure Availability Zones,Microsoft Azure, Cloud Design Pattern, Azure storage design, Azure storage best practise
