Azure Storage – Blob-Level Tiering – Part 2

Azure Storage içerisinde bulunan Hot, Cool ve Archive detayına bir önceki yazımızda değindik. Şimdi ise Archive Blob hizmetinin işleyişine bakalım. Eğer bir blob Archive Tier seviyesine olduğu zaman okunamaz, kopyalanamaz, üzerine yazılamaz veya değiştirilemez. Ayrıca Archive Storage bulunan bir blob’un snapshot özelliğinden faydalanamazsınız. Bu operasyonlar dışında, varolan bloblarınız için silmek, listelemek, blob özelliklerini / meta verileri elde etmek veya blob’unuzun katmanını değiştirmek için ilgili özellikleri kullanabilirsiniz. Archive Blob Storage içerisindeki verileri okumak için, Blob’un Tier (katmanını hot veya cool olarak) değiştirmeniz gerekir. Bu işlem, rehydration(rehidrasyon) olarak bilinir ve 50 GB’dan daha küçük blob’lar için 15 saate kadar sürebilir. Daha büyük bloblar için ise ek süre gerekebilir.

Rehidrasyon türkçe de yeniden yapılandırma anlamına gelmektedir. Mevcut Blob için rehidrasyon işlemi sırasında katmanın değişip değişmediğini teyit etmek için “Access Tier” özelliğini kontrol edebilirsiniz. İşlem tamamlandığında “Arşiv Durumu” özelliğinden görüntüleyebilirsiniz. Access Tier özeliiğine göre aslında data erişim sıklığı için tutulan bloblar için Storage hizmetinin bedeli değişmektedir.

Yukarıda bulunan örnekte Azure Storage Account içerisinde bulunan Blob seviyesinde katmanlamayı Azure Portal üzerinden yapmış bulunuyoruz. Rehidrasyon işlemini manuel yapmak pek hoş gözükmesede programatic olarak “.NET, Phyton, Java Client Library, Node.Js Client Library ve Azure API” ile süreci yönetme şansınız var.

Yukarıdaki örnekte “.NET” ile mevcut bir blob’un Access Tier seviyesini değiştirilmesini görüyoruz. Dilerseniz yukarıdaki yazılım dilleri ile aynı süreci gerçekleştirebilirsiniz. Şimdi ise ben biraz daha işin programatic tarafı için yapılan çözümleri aktarmaya çalışacağım. Bunların başında ilk aklıma gelen Logic Apps oluyor.

Hemen Logic Apps örneğini açmaya çalışalım. Storage Account içerisinde çok fazla blob’unuz olduğunu varsayalım. Son 30 gün içerisinde erişmeyen var ise (Modified Time gibi değerlere bakarak ) “Access Tier” kısmında gerekli değişimi Logic Apps içerisindeki bir flow ile değiştiğini düşünün. Gerçekten kulağa çok hoş geliyor. Hatta biraz daha ileri gidip firma çalışanları Office 365 Forms üzerinden talep edip “Access Tier” değişimleri yönetebilsek kestirmeden nirvanaya ulaşabiliriz.

Yukarıda bulunan örnekte “Logic Apps” içerisinde Data Lifecyle Management örneği gerçekleştirilmiş. Hergün düzenli olarak çalışan bir flow sayesinde “LastModified” 30 gün önce olan tüm blob’ların “Access Tier” özelliği Archive olarak değiştirililiyor.Logic Apps bir kenara bırakıp bunu analizin yapacak ve tarafınıza “Cost Saving” gibi bir çıktı veren bir araçtan bahsetmek istiyorum. Ignite içerisinde gösterilen “Azure Storage – Blob Tier Analysis Tool” sayesinde mevcut Storage Account içerisinde bulunan Blob’lar için analiz yapıp ilgili katmanlar arasında geçişi yönetmenize destek olacaktır.

Blob Tier Analysis Tool sayesinde yukarıdaki resim içerisinde desteklenen özelliklerden yararlanabilirsiniz. Yine kısa bir görüntü ile nasıl bir çıktı verdiğini görelim.

Yukarıdaki resim içerisinde Azure Storage Account içerisinde 779 GB veri olduğu gözlenmektedir. Blob Storage Analysis Tool, Storage Account içerisinde bulunan blobları inceleyerek gerekli senaryoları bizlere çıkarttı. Bir console uygulaması olarak gözüksede güzel bir analiz yapmış gözüküyor. Dilerseniz şu sayfa üzerinden ilgili uygulamaya erişip kendiniz build ederek analiz parametrelerini belirtebilirsiniz.

Blob Storage Analysis Tool yaptığı analizler sonra aldığı aksiyonlara dahil görüntüyü yukarıdaki resim içerisinde görebilirsiniz.