Overview Azure Migrate – Part 2

Bir önceki yazımızda Azure Migrate hizmetini genel hatlarıyla aktarmaya çalıştım. Şimdi ise Azure Migrate hizmetinin nasıl çalıştığına biraz göz gezirelim. Öncelike preview olan bu hizmeti aktif hale getirmek için şu sayfa üzerinden gerekli formu doldurup tarafınıza onay gelmesini bekleyiniz.

Azure Migrate nasıl çalışır?

  • Portal içerisinde Azure Migrate bölümüne gelerek yeni bir projesi oluşturursunuz.
  • Azure Migrate, organizasyon içerisinde çalışan makineleriniz hakkında bilgi bulmak için Collector Appliance adı verilen On-Premises içerisine kurulan bir Virtual Appliance kullanır. Cihazı oluşturmak için kurulum dosyası olan Open Virtualization Appliance (.ova) formatında indirin ve kurum içinde bulunan vCenter sunucunuzda bir VM olarak içe aktarın.
  • vCenter sunucusunda en az Read-Only yetkilerine sahip bir hesap kullanarak VM’e bağlanın ve collector uygulamasını çalıştırın.
  • Collector Appliance, sanal sunucuların verilerini VMware PowerCLI cmdlet’lerini kullanarak toplar. Bu yapılan keşif agent ihtiyacı duymaz ve VMware Host makinelerine veya VM’lere hiçbir şey yüklememektedir. Toplanan veriler Core, RAM, diskler, disk boyutları ve network adapter gibi bilgilerini içerir. Ayrıca CPU’lar ve bellek kullanımı, disk IOPS ve ağ çıktısı (MBps) de dahil olmak üzere VM’ler için performans verileri toplar.
  • Toplanan bu veriler Azure Migrate projesine gönderilir. Azure portalında görüntüleyebilirsiniz.
  • Değerlendirme noktasında, VM’leri gruplar halinde topluyorsunuz. Örneğin, aynı uygulamayı çalıştıran VM’leri gruplayabilirsiniz. VM’leri vCenter’da etiketleme veya Azure portalı kullanarak gruplandırabilirsiniz.
  • Bir grup için bir değerlendirme yapınız. Değerlendirme tamamlandıktan sonra, portalda görüntüleyebilir veya Excel formatında indirebilirsiniz

Değerlendirmeler nasıl hesaplanır?

Bir değerlendirme yapılırken, Azure Migrate bir makinenin IaaS platformuna uygunluk analiziyle başlar devamında bunu performansa dayalı boyutlandırma ve son olarak aylık tahmini maliyetini izler. Yapılan analizde bir workload, bir önceki aşamayı geçerse yalnızca daha sonraki bir aşamaya geçer. Örneğin, bir makine Azure uygunluk kontrolünü geçemezse, Azure Migrate için uygunsuz olarak işaretlenir ve boyutlandırma / maliyet tahmini yapılmaz.

Azure uygunluk analizi

Taşıma yapmak istediğiniz VM’ler Azure gereksinimlerini ve sınırlamalarını karşılamalıdır. Örneğin, kurum içi bir VM disk 4 TB’dan fazla ise, Azure’de barındırılamaz. Uygunluk için gerekli olan kontroller tabloda özetlenmiştir.

Setting

Description

Compute: Boot type Taşınacak olan işletim sisteminin boot tipi UEFI değil, BIOS olmalıdır.
Compute: Cores Sunucuların core sayısı, bir Azure VM için desteklenen maksimum core sayısına (32) eşit olmalıdır (veya daha azdır). Performans geçmişi mevcutsa, Azure Migrate, karşılaştırma için kullanılan core tüketimini değerlendirir. Değerlendirme özelliklerinde bir konfor faktörü spesifikse, kullanılan çekirdek sayısı konfor faktörü ile çarpılır.
Compute: Memory Sunucuların bellek boyutu Azure tarafında desteklenen (448 GB ) için verilen maksimum bellek miktarına eşit olmalıdır (veya daha az olmalıdır).Performans geçmişi mevcutsa, Azure Migrate, karşılaştırma için kullanılan belleği değerlendirir.
Compute – OS

Desteklenen işletim sistemleri aşağıdaki gibidir.

Storage disk size Azure VM’lerin tek disk boyutumaksimum 4 TB (4096 GB) olmalıdır. Sunucuya bağlı disk sayısı OS diski de dahil olmak üzere 65 veya daha az olmalıdır.
Storage disk IOPS/throughput Sunucu tiplerine göre disk başı için belirli sınırlamalar getirir ( IOPS gibi. ) Azure Migrate, sadece Managed Disk yapısını desteklemektedir.
Networking Taşınacak sunucuya bağlı en fazla 32 veya daha az NIC’ye sahip olmalıdır.

Overview Azure Migrate – Part 1

Microsoft’un Ignite 2017 de duyurduğu hizmet ile yine karşınızdayım. Bu sefer hizmeti ele almamım temel sebebi, yapmış olduğum birçok geçiş sonrası karşılaştığım sorunlara nasıl çözüm bulduklarını anlamak adına aradaki farkları aktarmak olacak. Azure Migrate hizmeti, kaynaklarınızın Azure’a taşınması için kurum içi ve iş yüklerini değerlendirmeyi kolaylaştıran bir hizmettir. Azure Migrate, taşınabilme uygunluğunu, performansa dayalı boyutlandırmayı, kurum içi iş yüklerini Azure da çalıştırmak için yapılan maliyet tahminlerini değerlendirir. Meşhur Scale Up, Scale Down ve Scalue Out gibi kavramlara yakın olup geçişi düşünüyorsanız ve geçişin erken değerlendirme aşamasındaysanız, bu hizmet tam sizin için.

Teknik açıdan bakıldığı zaman herhangi bir cloud provider’a geçişin zor olması gerekmiyor. Birçok kurum geçiş aşamalarına başlamak için iş yükleri, uygulamalar ve veriler arasındaki sıkı bağımlılıklara karşı derin bir direnç sağlamaktadırlar. Bulutun maliyet avantajlarını sergilemeden birçoğu bu konuya odaklanmadan erteleyebiliyor. Kuruluşlar için tasarlanan, Azure’a geçişlerine hızlı şekilde cevap vermelerine yardımcı olmak için Azure Migrate adında yeni bir hizmet var. Şirketlere buluta geçiş yapmak için gereken rehberliği, bilgileri ve mekanizmaları sağlayacak. (Bence bu hizmeti çıkarmak için çok geç kaldığını altını çizerek söylemekten çekinmiyorum.) Bu yazı serisinde iş yüklerinin taşınması sürecinde çok fazla bulunduğumdan dolayı geçiş aşamalarında yine Azure’un servislerinden olan Site Recovery ile yön verebiliyorum. Fakat Azure Migrate olaya yen bir boyut getirmiş. Gelin bunlar neler, biraz göz gezdirelim.

Neden Azure Migrate’ı kullanırız ?

  • Azure alt yapı hazırlığı : Azure’da çalıştırmak için kurum içi sunucuların uygunluğu.
  • Boyut önerileri : Kurum içi sunucuların performans geçmişine dayanan Azure VM boyutlandırma
  • Aylık maliyet tahmini : Taşınacak olan sunucuların, Azure için tahmini maliyetleri

Sınırlamalar ( Şimdilik )

  • Sınırlı Ön İzleme için, Azure’de IaaS VM’lere geçiş için kurum içi VMware sanal makinelerini (VM’ler) değerlendirebilirsiniz.
  • Azure Migrate portalı şu anda sadece İngilizce olarak mevcuttur.
  • West Central US – Azure Region’da bir proje oluşturabilirsiniz. Bununla birlikte, VM’leri farklı bir Azure Region’ı için değerlendirebilirsiniz.

Değerlendirmeye ne dahil ?

Setting

Description

Target location

Taşımak istediğiniz firmanın konumu. Varsayılan olarak oluşturduğunuz taşıma projesinin konumu gibide düşünebiliriz. Bu ayarı değiştirebilirsiniz

Storage redundancy

Taşıma sonrasında Azure VM’lerin kullanacağı depolama seçeneği. Şu anda Azure Migrate, yalnızca Yerel olarak yedekli depolama alanını (LRS) desteklemektedir

Pricing plans

Fiyatlandırma çok önemlidir. Yazılım Güvencesi (Software Assurance) kapsamında olup olmadığınızı, eğer sahip iseniz Azure Hybrid Use Benefit’i kullanıp kullanamayacağınızı ve seçmeniz gereken Azure tekliflerini değerlendirir. Ayrıca, teklifin üstünde olabileceğiniz herhangi bir aboneliğe özel indirim (yüzdelik) belirtmenizi sağlar.

Pricing tier

Azure Migrate, Azure VM’lerin fiyatlandırma katmanını ( basic / standart) belirtmenizi sağlar. Bu, kurum içi ortamınızında belrrli SLA seviyelerine girip girmediğinize bağlı olarak doğru Azure VM ailesine geçiş yapmanıza yardımcı olur. Varsayılan olarak, Standart katman kullanılır.

Performance history

Varsayılan olarak Azure Migrate bir aylık geçmişi kullanarak kurum içi makine performansını değerlendirir. İsteğe bağlı olarak bu değiştirilebilir.

Comfort factor

Azure Migrate, değerlendirme sırasında konfor faktörünü göz önüne alır. VM’lerin (CPU, bellek, disk ve ağ için) kullanım verilerinin üstünde uygulanır. Trende göre kullanım, kısa performans geçmişi ve gelecekteki olası artışlar gibi konularda konfor faktörü ekler.

Powershell ile WMI ve CIM Kullanımı – Part 3

CIM ve WMI tarafından kullanılan repository, farklı namepsace yapısı içerisinde düzenlenmiştir. Bir namespace alanı temelde bir klasör gibi düşünülebilir ve farklı yönetim amaçlarıyla ilgili öğeleri gruplamak için kullanılır. Namespace alanları kendine içinde class(sınıflar) içerir. Bir class, yönetilebilir bir yazılım veya donanım bileşenini temsil edebilir. Örneğin, Windows işletim sistemi, işlemciler, disk sürücüleri, hizmetler, kullanıcı hesapları vb. Için class yapısı bizlere sağlar. Network ortamında bulunan her bilgisayar, farklı işletim sistemlerine sahip olacağından dolayı farklı namespace alanları ve class yapısına sahip olabilir.

Farklı namespace ve class yapısına hızlı bir örnek verecek olursak, Örneğin Active Directory rolüne sahip bir bilgisayar ile Windows Client arasında namespace ve class yapısı doğal olarak farklılık gösterecektir. Gelelim bu repository içerisinde nasıl aramalar yapılır bu namespace ve class nasıl erişeceğim dediğiniz duyar gibiyim. İşte bu kısımda yardımımıza önereceğim araçlar yetişiyor olacak ve işimiz çokta kolaylaştıracak.

Ama bunun öncesinde bir WMI ve CIM class çağırıldığı zaman bunların bir takım özellikleri bulunuyor ve bunları aşağıda inceleyelim.

  • Methods: Method yapısı kullanılarak aksiyonlar aldırabiliriz. ( Uzak bilgisayara Re-start, servis-start-stop)
  • Properties: Çağırdınız class içerisinden alınabilecek bilgilerdir. Nitelik.
  • Events: WMI veya CIM class’ını izleyip gerçekleştiklerinde harekete geçebilecekleri eylemlerdir.( Trigger)

Şu anda WMI için namespace ve class yapısını keşfedebileceğiniz birkaç GUI aracı var, bu yüzden bir kez Namespace, Class, Properties veya event yapısı ile çalışmak istediğiniz zaman karar verebilirsiniz. Birçok sistem yöneticisi tarafından WMI’yi keşfetmek için en sevdiğim araçlardan biri, SAPHIEN firmasının WMIExplorer diyebilirim. Bu araçlar oldukça kolaylık sağlıyor. Powershell ile Namespace, class, properties ve method aramaları gerçekleştirebilirsiniz ama oldukça zor olabiliyor siz isterseniz bunun için aşağıdaki örneklere dikkat edin.

Bilgisayarınızdaki veya remote bir bilgisayardaki tüm namespace alanlarını listelemek için Windows PowerShell’i kullanabilirsiniz.

Yukarıdaki örnekte Powershell ile bilgisayarınız üzerinde bulunan tüm “Namespace” isimlerini listemiş bulunuyoruz. Namespace içerisinde “Class” detaylarını nasıl incelendiğine bakalım. Windows PowerShell, belirli bir namespace alanındaki tüm class’ları listeleyebilir. Örneğin, “root CIMv2” namespace alanındaki tüm sınıfları listelemek için aşağıdaki komutlardan birini çalıştırabilirsiniz.

Yukarıdaki görüldüğü gibi Powershell içerisinden ilgili NameSpace adını yazıp, tüm WMI ve CIM Classlarini listelenmesini sağladık. Class isimlerine dikkatinizi çekmek istiyorum. “Win32_*” ile başlayanlar WMI temsil ediyorlar, bu classları kullandığınız zaman isimlerinden göründüğü gibi bilgileri elde edebiliyoruz. Mesela, “Win32_Volume” Class’ını Powershell içerisinden çağırıp sorgulama yaptığım zaman, sorgulama yaptığım işletim sistemleri üzerinde Volume bilgilerini alabileceğimiz detaylar gözüküyor olacak. Burası gerçekten çok fazla detay gerektiren ve zamanla kavranabilecek bir yer. SCCM, SpiceWorks, diğer Inventory Management yapan tüm yazılımlar aslında OS üzerindeki bu class yapısına sorgular yaparak bilgileri topluyor. Bir sonraki yazımızda bu class yapısının özelliklerini inceleyelim.

Powershell ile WMI ve CIM Kullanımı – Bölüm 2

CIM komutlarını iki şekilde kullanabilirsiniz. İlk yöntem olan bağlanmak istediğiniz uzaktaki bilgisayarın WinRM’yi yüklenmesi ( işletim sistemi versiyonu detayını unutmayalım) ve aktifleştirmenizi gerektirir. Bu süreç genellikle, Windows Management Framework 3.0’ın yüklenmesini ve Windows PowerShell Remote Session özelliğinin aktif hale getirilmesi durumudur. CIM komutlarını kullanmanın ikinci yöntemi ise, komutu eski hali olan WMI teknolojisini kullanması durumudur. Bu sayede, WMI komutlarıyla aynı sorgulara cevaplar alabilir ve Windows Management Framework uzak bilgisayarda kurulmasını ve aktifleştirilmesi gibi süreçler ile uğraşılmaz.

Windows Management Instrumentation (WMI) komutları ve teknolojisinin detayları

WMI komutları ile CIM komutları aynı havuzu kullanırlar. Aralarındaki tek fark, WMI komutlarının uzak bir bilgisayara nasıl bağlandığının detayıdır. WMI komutları session tabanlı bağlantıları desteklemez. Komutlar, yalnızca geçici bağlantıları DCOM üzerinden destekler. WMI veya CIM komutlarıyla kullanıldığında, DCOM bazı durumlarda kullanımı zor olabilir. DCOM, Remote Procedure Call (RPC) protokolünü kullanır. Bu protokol doğru çalışması için güvenlik duvarı istisnaları gerektirir.

WMI komutları, WMI servisiyle iletişim kurar. Uzak bilgisayarda herhangi bir WMI sorgusu yaptığınız zaman Windows Management Framework herhangi bir sürümünün detayı aranmaz ve Windows PowerShell Remote Session özelliğinin etkinleştirilmesi ile uğraşılmaz. Bağlanılacak uzak bilgisayarda Windows Güvenlik Duvarı özelliği etkinleştirilmişse ve third-party bir hizmet aktif ise, WMI sorguları için uzak bilgisayarda güvenlik duvarı tarafında kuralları WMI servisi için kurallar yazılması gereklidir. CIM komutları DCOM’u da kullanabileceğinden, WMI komutları session olarak sorgulama yapmadığı için (ad-hoc connection model) WinRM’in uzak bilgisayarda aktif edilmesi aranmaz. CIM ve WMI özetine baktığımız zaman, WMI ile sorgular yaparken herhangi bir servisin aktif edilmesi ile uğraşılmasına gerek kalmaz sadece Firewall tarafında bir takım kurallar yazılması gereklidir.

WMI işletim sisteminin farklı bölümlerine erişim sağlayan nesne topluluğu olarak bakabiliriz. PowerShell’de nesnelerinde sahip olduğumuz gibi her biri için properties, method ve event’lar var. Bu nesnelerin her biri “System32wbem” dosyasında “.mof” uzantısıyla kaydedilen MOF (Management Object Framework) adlı dosyalar tarafından tanımlanır.

WMI veya CIM hangisi tercih edilmeli?

Öncelikle çoğu zaman, WMI cmdlet’lerinin yerine CIM cmdlet’lerini kullanmanız gerekir. Bunun birden fazla sebebi var aslında.

  • CIM cmdlet’leri uzak bilgisayarlara yapılan bağlantılar için WS-MAN’ı kullanır.
  • CIM cmdlet’leri, uzak bilgisayara oturum temelli bağlantılar için DCOM veya WS-MAN kullanabilir.

WMI cmdlet’leri ile sorgulamalar yaparken, Windows Management Framework 2.0 veya daha yeni bir sürümü yüklü olmayan bir bilgisayara veya Windows Management Framework 2.0 yüklü ancak Windows PowerShell Remote Session sistemine sahip olmayan bir bilgisayara geçici bir bağlantı oluşturmanız gerektiğinde bu gereksinimlere ihtiyacınız yoktur.

CIM tarafında ise oldukça farklı durumlar mevcut yazımızın başında dediğim gibi cross platform desteği olması, ortamda bulunan bir switch cihazına CIM session üzerinden komutlar gönderme şansınız var. CIM cross platform ve cross versiyon olayında oldukça önde olduğunu tekrar hatırlatalım.

WMI ve CIM teknolojilerinin detaylarını anlattıktan sonra artık cmdlet mimarisine geçelim. Kendine ait ama çok benzer bir yapıya sahipler. “Get-Command” cmdlet yardımı ile “WMI” cmdlet hepsini listeleyelim.

Yukarıdaki bulunan resimde WMI ailesine ait tüm cmdlet listesi bulunmaktadır. Şimdi ise CIM cmdlet ailesine göz gezdirelim.

CIM cmdlet ailesi WMI’dan fazla görünüyor. Yeni teknoloji olan CIM modeli oldukça işimizi kolaylaştıran cmdletere sahip. Çok kısa bir örnek ile bunun detayına değinmek istiyorum. WMI ve CIM işletim sisteminin repository olarak düşünmeyi asla unutmuyoruz. Ortamınızda bulunan bilgisayarlarda SCCM, Intune, SpiceWorks ve diğer Varlık yönetimi yapan tüm uygulamalar arka tarafta WMI veya CIM kullanarak bizlere raporlar sunmaktadır. Bir sonraki yazımızda Repository kullanımının detayına bakalım.

Powershell ile WMI ve CIM Kullanımı – Bölüm 1

Bu yazı serisinde Powershell ile WMI ve CIM teknolojilerinin nasıl çalıştığını, kullanım methodlarını genel hatlarıyla detaylandırmaya çalışıcam. Artık Blog üzerinde genelde seriler yazmaya çalışıyorum ve bu yazı serisine başlamak için çok sabırsızdım. Bir şekilde herkes Powershell ile haşır neşir oluyor fakat bu tarz derinlemesine konulara bakmaya fırsatı olmuyor veya dokunamıyor. İşte bu yazı serisinde bu teknolojilerin öneminden bahsedeceğim.

Windows Management Instrumentation (WMI) ve Common Information Model (CIM) birbirleriyle ilgili teknolojilerdir. Her ikisi de, farklı platformlarda uygulanabilen bağımsız yönetim standartlarını tanımlayan Distributed Management Task Force (DMTF), tarafından tanımlanan endüstri standartlarını temel alır. WMI, Microsoft’un Web-Based Enterprise Management (WBEM) standardının bir uygulamasıdır. Ön standartlara ve tescilli teknolojiye dayanan eski bir teknolojidir. CIM daha yeni bir teknolojidir ve açık, Cross-platform standartlarına dayanmaktadır. WMI, Windows NT 4.0’dan bu yana Windows işletim sisteminde kullanılabilir durumdadır.

DMTF nedir diyenler bu sayfaya göz gezdirebilirler. Distributed Management Task Force (DMTF) – www.dmtf.org

Her iki teknoloji de ortak bilgi deposu olarak (WMI deposu olarak da bilinir) bağlanmanın bir yolunu sağlar. Bu depo içerisine sorgular gönderebilir ve yönlendirebileceğiniz yönetim bilgilerini içerir. Windows PowerShell 3.0 ve sonraki tüm sürümler her iki teknolojiyi de desteklemektedir. Windows PowerShell’in önceki sürümleri yalnızca WMI’yı desteklemektedir. Windows PowerShell 3.0 ve sonraki sürümlerinde, paralel olarak iki komut grubu, WMI veya CIM’i kullanarak görevleri gerçekleştirmenize izin verir.

Yukarıdaki resim bir bilgisayarın Repository yapısı ile iletişim kurabileceği iki yolu gösterir. Yeni yol olan Common Information Model (CIM) komutlarını kullanmaktır(Get-CIMOBject). Bu komutlar Web Services for Management (WS-MAN) protokolünü kullanarak iletişim kurar ve Windows Remote Management (WinRM) hizmetine bağlanır. Eski yol olan Windows Management Instrumentation (WMI) komutlarını kullanmaktan geçiyordu ve bu komutlar, DCOM protokolünü kullanarak iletişim kurar ve WMI hizmetine bağlanırlar. (Get-WMIObject) Distributed Component Object Model (DCOM) protokolünü merak edenler bu sayfadan detaylara erişebilirler.

CIM komutları, çok sayıda Cross-Platform ve Cross version yetenekleri sunar. Çeşitli bağlantıları desteklerler bunlar sırasıyla,

  • DCOM kullanan yerel bilgisayara bağlantı sağlarlar.
  • Web Hizmetleri Yönetimi olan (WS-MAN) protokolünü kullanan uzak bilgisayara bağlantılar sağlayabilirler. Bu protokol defaul olarak HTTP tabanlıdır.
  • DCOM veya WS-MAN kullanabilen uzaktaki bir bilgisayara oturum temelli bağlantılar sağlar.

DCOM bağlantıları, genellikle Windows işletim sisteminin bir parçası olan Windows Management Instrumentation (WMI) hizmetine yapılır. WS-MAN bağlantıları, Windows PowerShell Remote Session ayarını etkinleştiren, Windows Remote Management (WinRM) hizmetine yapılmaktadır. WinRM hizmetini aktif ederken dikkat edilmesi gereken nokta, Windows Management Framework bir parçası olduğunu ve Windows Management Framework 2.0 ( Powershell version 2.0 üstü) ve daha yeni sürümlerinde bulunmaktadır. WinRM, varsayılan olarak Windows 7, Windows 8, Windows Server® 2008 R2, Windows Server 2012R2 ve Windows Server 2016 çalıştıran bilgisayarlara kurulu olarak gelmektedir. Varsayılan olarak tüm bu işletim sistemlerine yüklenmesine rağmen, WinRM yalnızca Windows Server 2012 ve üstü işletim sistemlerinde otomatik olarak etkinleştirilmiştir.

Azure Storage – Blob-Level Tiering – Part 1

Yeni kurulumlardan büyük organizasyonlara kadar, her endüstrideki müşteriler verilerinde üstsel büyüme yaşıyorlar. Bu verinin önemli bir bölümüne nadiren erişilebilir ancak iş sürekliliği ve uyumluluk gereksinimlerini karşılamak için uzun bir süre saklanmalıdır. Örnekler arasında çalışan verileri, tıbbi kayıtlar, müşteri bilgileri, mali kayıtlar, yedekler vb. yer almaktadır. Ayrıca, yapay zeka ve veri analizinde yeni olan gelişmeler, daha önce atıl olan veya saklanması gereken verilere ihtiyaç duyuyor. Bu yüzden firmaların çoğu, bu veri setlerinden daha fazla zaman saklamak istiyor ancak bunun için ölçeklenebilir ve düşük maliyetli bir çözüme ihtiyaç duyuyorlar.

Geçen yıl içerisinde Microsoft “Azure – Cool Blob Storage” hizmetini duyurmuştu. Müşterilerin erişilen verilerini “Cool Tier” adında bir katmanda saklayarak depolama maliyetlerini azaltmalarına yardımcı oldu. Bunu malasef Azure Storage Account oluştururken tipine göre belirleyebiliyorduk. Ignite 2017 duyurulan “Archive Storage” sayesinde nadiren erişilen verileri en düşük fiyatlı katmanda saklayarak, kuruluşların depolama maliyetlerini daha da azaltmalarına yardımcı olmak için tasarlanan Archive Blob Storage hizmetini genel önizlemesini duyurdu. Ayrıca, bu katmanlardaki blob düzeyindeki verilerinizin yaşam döngüsü düzeyini kolayca yöneterek depolama maliyetlerini optimize etmenize olanak tanıyan Blob Level Tiering’in özelliğini herkese açık önizlemesini sundu.

Archive Blob Storage Nedir ?

Azure Archive Blob Storage, esnek gecikme gereksinimleri olan nadiren erişilen veriler için (belirli bir saat içinde erişemde olur dediğiniz), yüksek kullanılabilirliğe sahip ve güvenli bulut depolama alanı olanağı sağlayan düşük maliyetli bir hizmet ile kuruluşları sağlamak üzere tasarlanmıştır. Yukarıdaki resimde görüldüğü gibi artık Azure Blob Storage içerisinde : Hot,Cool ve Archive isimlerinde üç farklı seviye bulunmaktadır. Bu farklı seviyeler arasında doğal olarak fiyat farklılıkları ve erişim methodlar var. Aşağıdaki resimde Archive Blob Storage kullanıldığı senaryoları görebilirsiniz. Fiyat konusunu merak edenleriniz var biliyorum fakat henüz bir resmi bir duyuru yapılmadı.

Archive Blob Storage Nasıl Kullanılır ?

Archive Blob Storage hizmetini kullanabilmeniz için aşağıdaki adımları gerçekleştirmeniz gerekmektedir. Şimdilik hizmet, Public Preview olduğu için bu işlemleri yapmaktayız. General Available olduğu gün bu dertlerimiz olmayacak. Powershell ve Azure CLI aracılığı ile birkaç istek gönderme sürecimiz var. Talebiniz onaylandıktan (1-2 gün içinde) East US 2’de kaynaklarınız için geçerli olacaktır. Önizleme sırasında yalnızca Storage Replication tipi Locally-redundant storage (LRS) olanlar desteklenecektir, ancak General Available’ da GRS ve RA-GRS hesaplarına (yeni ve mevcut) da destek vermeyi planlıyorlar. Bu talebimiz onaylandıktan sonra artık Blob düzeyinde Archive Storage ve Access Tier özelliğine sahip olabileceğiz. Makalemizin ana konusunu barından “Blob Level Tiering” olayı sayesinde mevcut blob’larınız için katmanlama durumunu sizin belirlediğiniz aralıklara göre ( 30 gün boyunca erişmediklerim – Archive Tier seviyesine geçsin.) gibi aksiyonlar alabileceksiniz.

Yukarıda bulunan Powershell satıları içerisinde Archive Blob Storage özelliğini aktif etmek için istek gönderdik. Son satırda ise gerekli talebi yaptıktan sonra “Registered” yazısını görmeyi beklemeniz gerekmektedir.

Archive Blob Storage özelliğini açıldı. Bu sayede hem Archive Blob Storage hemde Blob Level Tiering özelliğine sahip olduk. Archive Blob ve Blob Level Tiering konusundaki erişim methodlarına yoğunlaşabiliriz.

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.

Azure Functions in Practice

Evrim her yerdedir, doğanın sahip olduğu gibi Bilgi Teknoloji departmanları da buna sahiptir. Her başka bir gün nereden geldiği belli olmayan bir yenilik çıkıyor ve insanlar bunu gördüklerinde tepkileri “Wow! işte bu herşeyi değiştirir.” oluyor.
Bilgi Teknolojileri birbirleriyle ilişkisi olmayan makinelerden küçük yerel ağlara ve sonra internete evrildi. Ayrıca veri merkezlerine sahipken ardından da buluta kavuştuk. Cloud Computing, IaaS olarak başladı, sonra hayatımıza PaaS ve SaaS’a girdi.

Azure Functions ( Serverless Architecture ) nedir?

Bir hayal kuralım ve yapmak istediğiniz bir işiniz var. Örneğin dosya işlemek, resim işlemek, bildirim yapmak vs. Bu işleri yapmak için sunucu, ortam ve diğer etkenleri düşünmeden sadece görevinizi tanımlayıp çalıştırabileceğiniz sistemler olduğunu düşünün. İlk olarak şunu kesinlikle anlamamız gerekiyor. Serverless demek kesinlikle programınızın çalışması için sunuculara ihtiyacınız olmadığı anlamına gelmiyor. Serverless mimarilerde kesinlikle sunucular kullanılıyor. Fakat burada önemli olan nokta bu sunucuların yönetiminin, dolayısı ile oluşan birçok operasyonel işlerin artık bizim değil servis sağlayıcının sorunu olması.( Function as a Services ). Yani production’da bir uygulama / kodu çalıştırmanın en önemli zorluklarından olan operasyonel işleri servis sağlayıcısına tamamen teslim etmiş oluyoruz. ( Bırakınız yapsınlar, yönetsinler ! ) Kısacası siz kodunuzu upload edin gerisine karışmayın. Cloud ortamı olduğu için ise kodunuz çalıştığı zaman aralığı için ücret ödeyin.

Azure Functions desteklediği yazılım dilleri, C#, F#, Node.js, Java, Python, PHP, batch, bash, or any executable. olarak söyleyebiliriz.

Azure Functions (veya AWS Lambda) ile ilgili müthiş şey, geleneksel olarak kodu yürütmek zorunda kalacağınız altyapıyı yönetmek / korumak zorunda değilsiniz. Benim aklıma ilk takılan soru ise Azure Automation’dan farkı ne acaba diye düşündüm. Azure Automation’ı biliyorsanız, Powershell ile otomasyon sağlayabilen bir servis. Ancak, Azure Function, Automation’ın sağladığının da ötesine geçmektedir. Automation PowerShell ile sınırlıdır ve gerçekten yalnızca bir web hook veya Azure SDK (API veya CLI) tarafından tetiklenebilir.

Azure Functions içerisinde Powershell’i kullanarak basit bir kod bloğumun çalıştırılması sağlayacağım.Yazdığım kod bloğunu Azure Function içerisine upload ettim ve sadece http trigger üzerinden istediğim zaman tetikleyerek ilgili code satırlarının çalışmasını gerçekleştireceğiz. Kod bloğumuz aşağıdaki gibidir.

Kod bloğumuz upload ettikten sonra, “Get function URL” butonuna basıp http üzerinden gerekli trigger url sahip olduk. Artık Azure Functions ile http üzerinden trigger ederek Powershell script’in çalışmasını sağlayabiliriz.

Trigger işlemini görüldüğü gibi “1.adım” içerisinde yaptım. Gelen istek çok hızlı bir şekilde Powershell Script çalışmasını sağladı. Functions hizmetini Powershell ile göstermeye çalıştım. Fakat diğer diller ile yapılabilecekleri hayal edin.Kazanımlarımızı kısaca özetlemek gerekirse; Şüphesiz ilk akla geleni maliyet adına bize kazandırdıkları, Pay-as-you-go– Kullanım başına ödeme diyebiliriz. Yukarıda kısaca bahsetmeye çalıştım tekrar edecek olursak, sunucunun RAM ve İşlemci kullanımına göre ödeme yaptığımız modelden, sadece foksiyonlarınız çalıştığı zaman ücret ödeme modeline geçmiş olacağız. Yaz ve çalıştır kolaylığına eriştiniz. Ayrıca Yönetecek, server vb. bir alt yapı da olmadığı için çok daha hızlı bir geliştirme süreci sunulmaktadır. Server kurma, yönetme, ölçeklendirme, güvenlik maliyetlerinden sizi kurtarıp sadece uygulamanızı, iş mantıklarınızı kurmanıza odaklamanızı sağlar.

Azure Building Blocks – Part 2

Yazımızın ilk serisinde genel hatlarıyla Azure Resource Manager ile Building Blocks yapısını anlamamız için açıklamalarda bulunduk. Building Blocks açık kaynaklı bir yazılım olduğunu ve Resource Manager dağıtım modelinde bize daha seri bir şekilde deployment yapmamıza yardımcı olacağından bahsettik. Şimdi ise genel yapısını ve nasıl kullanabileceğimize bakalım. Öncelikle Building Blocks aracını kurmanız için bir çok yöntem karşımıza çıkıyor. Eğer mevcut bilgisayarınız içerisinden bu tool erişip gerekli dağıtımı yapmak istiyorsanız, Azure Command Line Interface ( Azure CLI ) Yönetim aracını kurmanız gerekmektedir. Burası tamamen sizin seçiminize kalmakla beraber, dilerseniz Linux Bash üzerinden Building Blocks aracını yükleme şansına sahipsiniz. Ben bu yazı serisi içerisinde Azure CLI üzerinden devam edeceğim. Alternatif olarak tool kurulum süreçleri ile uğraşmak istemiyorum diyenler Azure Cloud Shell tercih edebilir ve Web Based olarak devam edebilirler.

Bir önceki yazımızda bahsettiğimiz gibi Azure Building Blocks 2.0 versiyonu ile indirilebilir durumdadır. Open Source bir araç olduğu için ve Azure CLI üzerinden kullanabilme durumunu hesaba katıp geniş bir şekilde bir çok platformda bu aracı tercih etmenizi sağlayacağını söyleyebiliriz. Bunların başını çeken, macOS, Ubuntu, Red Hat Enterprise Linux (RHEL), Fedora, or CentOS gibi İşletim sistemleri bulunmaktadır. Windows ise zaten söylememe gerek olduğunu düşünmüyorum. Şimdi sırasıyla Azure Building Blocks için neler gerektiğine bir göz gezdirelim.

  • Azure CLI 2.0 – İşletim sisteminize şu adresten kurulum gerçekleştiriniz.
  • Node.JS – İşletim sisteminize şu adresten kurulum gerçekleştiriniz.
  • Windows için – Command Prompt – Linux için ise Bash açılması gerekmektedir.

Windows üzerinde çalışan Azure CLI üzerinden gideceğim için Command Prompt üzerine gelip, aşağıdaki Package Manager (npm) çağırıp kurulumu gerçekleştireceğim.

Yukarıda görüldüğü gibi Azure Building Blocks kurulumunu başarıyla yaptık. Şimdi, Azure Building Blocks aracına nasıl eriştiğimizi anlamaya çalışalım. Aşağıdaki resimde görülen örnekte, Powershell üzerinden “azbb” yazdığım zaman ilgili aracı çağırmış bulunmaktayım. Bu araç ile gönderebileceğimiz parametleri görmekteyim. Yazımızın ilerleyen kısımlarında bu parametleri kullanıp deployment yapmaya çalışacağız.

Azure Building Blocks kurulumunu yaptık. Yukarıda bulunan resim size şaşırtmasın, Azure Building Blocks kurduğum zaman artık “Powershell” içerisinden çağırdım. Versiyon kontrolü yapmak istersek “AZBB” aracını çağırarak parametre göndermesi gerçekleştirelim ve versiyonumuzu öğrenelim.

“azbb –version” parametresini göndererek hangi versiyonda olduğumu öğrenmiş oldum. Bir sonraki yazı içerisinde artık Azure Building Blocks için deployment ve template geliştirme sürecine başlıyor olacağız.

Azure Building Blocks – Part 3

Azure Building Blocks temelde bir adet “Settings File” ihtiyaç duyar. Bu “Settings File” içerisine, Deploy etmek istediğiniz kaynağın detayları belirtirsiniz. Bu size tanıdık gelen bir format olacak fakat Azure Resource Manager Deployment modelinde geliştirdiğinizden oldukça basit bir şekilde karşınıza çıkmaktadır. Bu kısımdaki esneklikleri anlamak için hemen boş bir “Settings File” oluşturalım ve ardından ilk örneğimizle yola çıkalım.

Yıukarıda bulunan JSON şemasını izleyen bir “Building Blocks” tanımlaması ve ardından buildingBlocks dizisini istediğiniz şekilde dolduracak bir yapı izlemektedir. Şimdi basit bir örnek ile başlayalım.

Yapmak istediğimiz ilk kısım, Azure Subscription içerisinde basit bir Virtual Network ve subnet yaratılması gerekmektedir. Sırasıyla mimari aşağıdaki yapıyı içerir.

  • 10.0.0.0/16 adres alanına sahip “msft-hub-vnet” isimli bir VNet.
  • 10.0.1.0/24 adres alanına sahip “firewall” olarak adlandırılan “msft-hub-vnet” içindeki bir alt ağ.

Her blok bir JSON içerisinde nesne olarak temsil edilebilir. Örneğimiz içerisinde, basit bir Virtual Network’ü temsil etmek için aşağıdaki JSON nesnesini kullanalım.

Yukarıdaki JSON dosyasında buildingBlocks nesnesinin içerisine gerekli tanımlamaları yaptık. Dikkat ederseniz, “Type” adında bir nesnemiz var ve onun karşınıza gerekli kaynağın modelini tanıtıyoruz. Azure Resource Manager Template gibi uzun gözüküyor. “Bunun hangi aşaması kolay ? ” dediğinizi duyar gibiyim. Bu yüzden bu aradaki farklı anlamanız için aynı mimarinin Azure Resource Manager Template ile yazmaya çalışsaydınız örneğini aşağıdaki resimde görebilirsiniz.

Resim içerisine hepsini sığdıramadım fakat, yukarıdaki sadece basit bir Virtual Network oluşturulması için yapılan adımlardı. Azure Resource Manager Template kullanarak deployment yapmak oldukça zamanımızı alabiliyor. Hızlı ve basit bir şekilde yapmak için Azure Building Blocks sizleri bekliyor. Bir sonraki yazımızda geliştirmiş olduğumuz “Virtual Network Settings File” nasıl deploy edebileceğimizi inceleyelim.