Bu yazı Microsoft Azure laaS hizmeti olan ( Sanal Makineler Servisi ) ile başlangıçtan beri dahil olmamış kesime tanıtmak, bunun nasıl çalıştığını hızlıca anlamak isteyenlere ve ikna edilebilirse başlatmaya hatta kullanmayı düşündürmek üzere yazılmıştır. Bu yazıda, Microsoft Azure’ın içerisindeki laaS (Infrastructure as a Service) özellikleriyle ilgili çok şey detaylandırmayacağım, çünkü onlardan yüzlercesine sahip olunan kısımlar var ve Azure temellerini konu alan, tarif eden pek çok kitap ve uzun makaleler var.

Bu Makale serisi aşağıdaki gibi başlıklara ayrılmıştır.

1. Tanıtım (Introduction) : Azure Sanal Makineleri (laaS) nedir?
2. Bileşenler (Components) : Makalemizin ana kısmıdır. Burada sizlere Azure Sanal Makineleri Servisi'nin bileşenlerini ve yapı taşlarını tarif edeceğim. Sizlere Azure laaS'in nasıl çalıştığını ve Azure Sanal Makineleri Servisi ile yola çıkmadan önce neyin dikkate alınması gerektiğini konusunda yardımcı olacaktır.
3. Sanal Ağ (Virtual Network) : Azure içerisinde Virtual Network konseptinin detaylarını içerir.
4. Depolama (Storage Account): Azure içerisinde Storage konseptinin detayları barındırır.
5. Fiyatlandırma (Pricing) : Azure fiyatlandırma konusundaki işleyişinin anlatıldığı kısımdır.
6. Dizayn Hususları (Design Model): Bazı dizayn hususlarına ve hatırlanması gereken noktalara değinir.
7. Okumanın Ötesinde : Azure'a dalış yapabilmek hatta daha derine gidebilmek için bazı tavsiyelere değineceğim.

Tanıtım (Introduction)​

Azure Sanal Makineleri Azure'un laaS (Infrastructure as a Service) kapasitelerinin merkez özelliklerinden biridir. Azure Sanal Makineleri, bir Microsoft Azure datacenter içerisindeki Windows Server veya Linux Sanal Makineleri'nin açılımını destekler. Sanal Makineleri'nin yapılandırılmasındaki toplam kontrol sizdedir. Tüm sunuculardaki yazılım yüklemesinden, yapılandırılmadan, bakımdan ve işletim sistemi yamalarından sorumlu olan sizsinizdir. Tüm kaynaklar Microsoft veri merkezleri içinde çalışır, onlara tek bağlantı da şüphesiz ki ağ olacaktır. Bunu şöyle düşünün, şirketinizden başka bir lokasyonda veya bölgede bir veri merkezine sahipsiniz. Tüm workloadları orada yaratıyorsunuz ve onlara uzaktan ulaşabiliyorsunuz.

Tek farkı ise şu:

• Veri merkezi Microsoft'a ait oluyor.
• Bütün altında yatan yönetim, güncellemeler, bakımlar Microsoft'un sorumluluğu oluyor.( Donanım,Ağ,Soğutma,Güç...)
• Fiziksel güvenlik Microsoft'un sorumluluğunun altında oluyor.

Sonuç ise, Microsoft sizlere bir özellik sunuyor. ( Bir servis ) Bu sizi sanal makine yaratma ve onları özgürce kullanma konusunda yetkinleştiriyor, tıpkı sizinmiş gibi ve zaten sizin. Azure Sanal Makineleri özelliği hakkında tanıtıma devam etmeyi çok isterdim, çünkü bu harika ve oldukça enteresan. Size Bulut Platformları (laaS) hakkında " Ne ve Neden " konusunu tartışmak ve yeni konsepte karşı ilerlemenin makul olup olmadığını konuşmak üzere detaylı bir yazı yazıyor olacağım.

Sizde Azure Datacenter içerisinde gezinmek istiyorsanız, neredeyse kusursuz olan bu işleyişini merak ediyorsanız bu link tam da size göre ; https://www.microsoft.com/en-us/server-cloud/ms.datacenter.tour/datacenter/

Dünya üzerinde bir çok bölgede Azure Datacenter'lar bulunmaktadır. Bulunduğunuz ülkeye hangi Azure Datacenter yakın olduğunuz anlamak çok da zor değil. Azure Speed Test adlı sayfa sizlere hangi Datacenter içerisine ne kadar gecikme(latency) ile gideceğinizin sonuçlarını belirtiyor. Bu link speed test konusunda sizlere yardımcı olacaktır. Dilerseniz Datacenter bulunduğu lokasyonları da bu adresten görebilirsiniz.

Bileşenler (Components)​

Bileşenleri hesaplamak Azure Sanal Makineleri'nin kalbidir. Sanal makine kaynaklarında hesaplamak demek, CPU, RAM ve İşletim Sistemi (OS) anlamına gelir. Azure içerisinde bir sanal makine yarattığınızda, önce Sanal Makine yapılandırmasını seçersiniz. Donanım ve Yazılım ( Örnek olarak, ben 4 GB Ram ve 2 CPU ile çalışan Windows Server 2012 R2 Datacenter Sanal Makinesini kullanmak istiyorum.) Buna bakıldığında, bir depolama yapılandırılmasından bahsetmiyorum.( İşletim Sistemi (OS) disk boyutu, sayısı ya da veri disklerinin büyüklüğü ) Azure size özgürce donanım yapılandırılmasını seçme olasılığını vermez. Bu konu hakkında yanlış değinmeden şunu düzeltelim. Aslında, Azure önceden tanımlanmış şablonların arasından seçimisizlere sunar. Bu şablonlar Sanal Makine serileri ve boyutları içerisine sınıflandırılmıştır. Sanal Makine büyüklüklerinin listesinin tamamı burada bulunabilir ve Microsoft tarafından değişim ihtimali olabilir diye düzenli olarak güncellenmektedir.

Azure'daki Sanal Makineler şöyle sınıflandırılabilir.

TIER​

Tier sanal makinelerin tip kategorizasyonudur. Azure'da iki adet Tier tipi bulunmaktadır. Basic Tier ve Standart Tier. Basic Tier sanal makineleri genellikle test etmek için kullanılır ya da daha önemsiz sanal makinelerdir. Basic Tier sanal makineleri daha çok ürün test süreçleri için kullanılır. Basic ve Standart arasında farklı olduğu kısımlar ise aşağıdaki gibidir.

• Basic Tier sanal makineleri Azure yük dengeleme kapasitelerini desteklemez.( Azure yük dengeleme özelliği kullanan iki basit sanal makine arasında yük dengeleme trafiği yapamazsınız.)
• Basic Tier Sanal Makineleri ile Azure içerisindeki tüm donanım serileri verilmemiştir, ileri donanım yapılandırılmaları ( Daha fazla CPU, RAM, Disk, Performans) sadece Standart Tier sanal makineleri ile sağlanabilir.
• Basic Tier sanal makineler veri disklerinin her birine 300 IOPS(Input/output operations per second) düşerken, Standart Tier disklerinin başına 500 veya daha azı kadar IOPS düşüyor. (Storage Account bölümünde detaylar anlatılacaktır.)
• Basic Tier sanal makineleri Standart Tier seviyesine göre %27 daha ucuzudur. Aslında bunun altında yatan bir çok sebep bulunmakta bunların başında, CPU ve Load-Balance özelliği gelmektedir. Bu fiyat ortalama Standart Tier seviyesinde sanal makineye göre %27 olarak gözlenmektedir.
• Basic Tier sanal makinesi için örnek verelim. Azure üzerinde hizmet verecek bir Domain Controller sanal makinesine ihtiyacınız var. Basic Tier ile ufak bir boyutta sanal makine oluşturarak hizmet verebiliriz. Domain Controller sunucuları ile yük dengeleme(Load Balance) veya otomatik ölçeklendirme(Auto – Scale) kullanamazsınız çünkü, Domain Controller yapısından dolayı (SYSVOL, NETLOGON vb saklanır) ve DC'nin nispeten hafif iş yükü ve veri disk için çok fazla IOPS gerektirmez.

SERIES ( SERILER )​

Seriler sınıflandırılırken temel amaç müşteriye hızlıca yardım etmek, onlarca sanal makinelerin arasından türünü hızlıca bulmak ve seçmektir. Araba satıcılarının sağladığı sınıflandırılıma örnek verebiliriz. Mercedes Sınıf A,B,C,E ve S ya da BMW Serileri 1,3,5 ve 7

Günümüze kadar, 6 adet Azure Sanal Makine serisi süregelmiştir:A-Serisi,D-Serisi,DS-serisi, G-Serisi ve N-Serisi

• A-Serisi : A serisi basic ve standart sanal makineleri sınıflarını sunar. Workloadlarınızın çoğunluğu için planlanmıştır. Sadece A serisi Basic Tier kategorizasyonu sağlar.
• D-Serisi : D serisi geliştirilmiş sanal makinelerin altında yatan donanımı sunar.Sanal makineler daha iyi fiziksel sunucuların üstünde daha hızlı işlemciler, daha hızlı disk önbelleği ve daha fazla depo desteği sağlar. D Serisi Sanal Makinelerin Boyutları bu adresten kontrol edebilirsiniz. https://azure.microsoft.com/tr-tr/blog/new-d-series-virtual-machine-sizes/
• DS-Serisi : DS serisi Azure Premium Depo ile çalışan tek Azure Sanal Makine serisidir.(Storage konusu tartışılacaktır.)Bu başlıca yüksek performansa ve düşük gecikme süresine ihtiyaç duyan workloadlar için sağlanmıştır.
• Dv2-Serisi : Dv2 Serisi sanal makineler D serisi sanal makine örneklerinden ortalama %35 daha hızlı ve daha güçlü CPU'lara ve D serisi ile aynı memory ve aynı disk yapılandırmalarına sahiptir. Kurumsal düzeyde birçok uygulama için güçlü bir alt yapı sunmaktadır.
• G-Serisi : Bu en son duyurulan Azure Sanal Makine serisidir. Güçlü sanal makine donanım yapılandırılması sağlar. ( Yüksek Özellikler ) Altında yatan donanım daha iyi CPU ve RAM markaları kullanır. Bu başlıca devasa workloadlar için sağlanmıştır. ( Ram'i yüzlerce gb olarak sağlayabilenler ) G serisi Sanal Makinelerin Boyutlarını bu adresten kontrol edebilirsiniz https://azure.microsoft.com/tr-tr/blog/largest-vm-in-the-cloud/
• N-Serisi : Son serisi olan bu sanal makineler GPU destekli altyapı sağlamaktadır. Azure üzerinde kurumsal müşterilerin iş akışlarında sanallaştırılmış grafik uygulamaları için NVIDIA GRID 2.0 teknolojisi NVIDIA Tesla K80 GPU hızlandırıcı erişimi sağlamaktadır.

SIZES ( BOYUTLAR )​

Sanal makinelerin büyüklüğü demek onun donanım yapılandırılmasına işaret eder. Azure'da, donanım yapılandırılması 4 element ile anılır.

• CPU: Sanal işlemci
• RAM : Sanal makineye atanan Ram miktarı
• Geçici ya da Yerel Depo : Sanal makineye atanan geçici deponun büyüklüğüdür. Sanal makinenin çalıştığı zamanda geçici depo olarak kullanılabilen tümleşik bir disktir. Sanal makine durduğunda ( planlanmış veya planlanmamış bir şekilde ) içerik yok olur. Bu disk içerisinde veri tutmamanız gerekiyor.
• Disk sayısı: Her bir sanal makine boyutuna maksimum sayıda eklenecek veri diski sayısı vardır(Attach Disk). Bu durumu biraz açar isek, Örneğin; Sanal Makine serilerinden bahsettik. A4 bir sanal makinenin içerisine ekleneceği disk sayısının ve boyutunun bir limiti bulunmaktadır. Bu detaylara ise linkten erişebiliriz.

Operating System (İşletim Sistemleri)​

Azure Sanal Makine hizmetini kullanarak farklı işletim sistemlerinden faydalanabilirsiniz. Microsoft Azure bizlere hazır işletim sistemi şablonları sunmaktadır. İsteğe bağlı olarak kendi sunucularınızın imajlarınızı hazırlayıp dağıtılabilir veya kendi lokasyonunuzda hizmet veren işletim sistemlerinin VHD dosyalarını upload ederek sunucularınızı Azure Platformu üzerinden çalıştırabiliriz. Linux makine desteklerinin detayları için sizlere şu link yol gösterecektir. Desteklenen tüm Template listesini görmek için lütfen bu adresten kontrol ediniz. https://azure.microsoft.com/en-in/marketplace/virtual-machines/all/

Cloud Service (Bulut Hizmeti)​

Sanal Makine oluşturduğunuz zaman, hizmetin yaratılma sırasında arka tarafta birçok bileşen onunla beraber ön gereksinimlerinden dolayı yaratılıyor. Bunların en başında "Cloud Service" gelmektedir. Cloud Service yaratılmasındaki temel sebep, sanal makine(ler) ev sahipliği yapması ve onlara aynı container içerisinde tutmasıdır. Oluşturulan sanal makine(ler) otomatik olarak network kartı (NIC) ve Azure tarafından atanan bir Public IP adresi sağlanmaktadır. Ayrıca Windows tabanlı sanal makineler için uzak masaüstü (RDP) ve Remote PowerShell trafiğine izin verir. Linux tabanlı sanal makineler için ise Shell (SSH) endpoint noktalarını içermektedir. Bununla beraber Cloud Service azure içerisindeki sanal makinelerin Public IP, yük dengeleme gibi hizmetleri yönetirken kullanmaktayız.

Önemli Not : Azure içerisinde farklı deployment modelleri bulunmaktadır. General Availability bu yazıda duyurulan (ARM GA Announcement) "Resource Manager" yeni dağıtım modeli olarak bir takım esneklikler ve değişiklikler içermektedir.Yeni Azure Portal ( Ibıza ) üzerinden bir sanal makine oluştururken Cloud Service oluşturmuyor. Arka tarafta daha farklı mimariye sahiptir. Bu senaryoyu daha detaylı anlamak isteyenler için daha önce blog üzerinde paylaştığım yazıyı okumasını tavsiye ediyorum.

Load Balance (Yük Dengeleme)​

Azure Sanal makineler arasında kullanabileceğimiz bir özellik olan Load-Balance ( yük dengeleme) isteğe bağlı olarak ilgili sunucular arasında yapılabilir. Bu özelliğin kullanılabilmesi için Azure Sanal Makinelerinin Tier seviyesinin "Standart" olmasına dikkat edilmesi gerekiyor. Load Balance özelliği level 4 seviyede tcp ve udp trafiğini paylaştırmamız için bizlere yol gösterir. Bu trafik istenirse public veya internal olarakda belirlenebilir. Bu kavramları hızlıca açalım.

• Public olarak adlandırdığımız istekler; örneğin bir web siteniz var ve dışardan gelen istekleri iki sunucu arasında paylaştırma yapılan yöntemdir.
• Internal olarak adlandırdığımız istekler; sunucular aynı hizmeti veriyor olabilir ve bu hizmet sadece kendi network ortamlarınız içerisinde paylaştırabilirsiniz.

Affinity Group​

Affinity grupları Azure sanal sunucularıınn birbirinin bulundukları aynı yerlere konumlanmasını sağlayacak bir yoldur. Geçmişte, affinity grupları sanal makine yaratmak için zorunlu bir gereksinimdi. Son mimari gelişmelerinde Virtual Network ( Sanal Ağlar) kapsamını artırmış. Çok katmanlı bir uygulamamız varsa veri tabanı ve uygulama sunucularının maksimum performans ile çalışabilmeleri için birbirlerine mümkün olduğu kadar yakın çalışmaları gerekmektedir. Bunun için VM'lerin aynı affinity group içerisinde olması aralarında ki mesafeyi kısaltacağı için latency'i (ms) düşürmektedir. Fakat artık mimari gelişimlerinin sonucu olarak,affinity grupları artık sanal makineler için önerilen veya gereksinim duyulan bir şey değildir.

Önemli Not : Daha öncede bahsetmiş olduğumuz Resource Manager deployment modeli ile "Affinity Group" kavramı tamamen hayatımızdan çıkmıştır.

Availability Set​

Sanal makinelerin uygunluğunu/sürekliliğini etkileyen Azure platformunda iki adet olaylar türü vardır : Planlanmış bakım ve Planlanmamış bakım. Planlanmış bakım genelde Azure sanal makinelerinin uygunluğunu etkilemez, ama bazen sanal makinelerin yeniden başlatmasını gerektirebilir. Planlanmamış bakım, servislerin bozulması veya genelde altında yatan donanım başarısızlığı yüzünden karşımıza çıkmaktadır. Azure SLA garanti etmek (99,95%) için bunun önüne geçebilmek ve istediğimiz SLA seviyesini tutturabilmemiz için availability set olarak adlandırdığı bir özellik sunmaktadır. Bazı uygulamalarımızda servislerimizi birden fazla VM üzerine kurup hem yük dağıtımında (Load-Balance) bulunur hem de iş sürekliğini yükseltmek isteriz, bunun en iyi örneği bir web uygulamasının front-end sunucularıdır. Bu sunucular yükü alıp arka tarafta ki Database veya uygulama sunucusuna aktarırlar ve en yüksek availability'i oluşturabilmek için birden fazla front-end sunucusu kurarak yükü dağıtmak isteyebiliriz. Peki, bu sunucuların hepsi aynı fiziksel sunucu üzerinde olursa ve bir güncelleme veya kesinti durumunda tüm servisimiz kesintiye uğrayabilir. Aynı availability set içerisinde ki VM'ler (minimum 2 adet olması gerekmekte) farklı fiziksel alanlarda tutularak donanım, güncelleme ve network sıkıntılarından minimum seviyede etkilenmesini hedeflenmektedir. "Availability Set" sanal makine oluşturulurken yaratılır. Yukarda bahsettiğimiz "Load-Balance" bileşineni kullanabilmek için aynı "Availbility Set" içerisinde olan sanal makineler faydalanabilmektedir.

Özgeçmişe Doğru​

Azure içerisinde bir sanal makine yaratmayı planladığınız zaman, hedef sanal makinenin özelliklerini bilmeniz ve sonrasında Tier/Seriler/Boyutlar arasında seçim yapmanız gerekmektedir. Zihinde kalması gereken noktalar :

• Sanal makinenin tipini her an değiştirebilirsiniz. Donanım kaynağını azaltabilir veya arttırabilir olarak değiştirebilmeniz mümkün. (Bir donanım yapılandırması perspektifinden) Fakat, Azure içerisinde bulunan Sanal Makine(VMs) tip gereksinimlerine saygı göstermeniz gerekmekte. Örneğin, eğer Premium Depo kullanıyorsanız DS-Serisinden başka bir seriye değiştiremezsiniz ya da A4 VM ile 16 diskten A3 Vm'e geçiş yapamazsınız, çünkü A3 maksimum 8 data diski destekler. Sanal makine yapılandırma değişikliklerinde nadiren sorunlarla karşılaşırsınız.
• Sisteminizde bulunan bazı Workload sunucularınız gereksinimlerden dolayı birden fazla Network Interface Card( NIC) ihtiyaç duyacaktır. Azure Sanal makineleri birden fazla ağ adaptörü destekler: ( 4 NICs: A4,A7,A9,D4,D13,G4), ( 2 NICS: A3,A6,A8,D3,D12,G3)
• Sanal makine fiyatlandırması 3 sınıflandıramaya dayanır :Tier,Seriler ve Büyüklük.Daha fazla yapılandırma ve daha iyi seçenekler, daha pahalı sanal makine anlamına gelir. (Fiyatlandırma konusu yazımın ileri kesimlerinde tartışma konusu olacaktır.)
• Farkına varılacak en önemli nokta, Storage (depolama) kullanımı ve Virtual Network( Sanal Ağ) sanal makine sınıflandırmasının bir parçası değildir.
• Eğer "Normal" sanal makineleriniz için yük dengelemesi ve özel performans istemiyorsanız , Basic Tier Vms kullanın : Fiyatlama açısından bu daha makul.

Sanal Ağ (Virtual Network)​

Virtual Networks (Sanal Ağlar)​

Servislerinizin güvenliğin ve izolasyonun katmanını sağlamak için Azure içerisinde sanal ağlar (VNet) kullanılabilir. Herhangi bir Virtual Network (VNet) yapılandırılması olmadığı zaman Service Management(Eski Portal) Deployment modelinde yaratılan sanal makinelere Azure üzerinden bir ip adresi atamasını Cloud Service gerçekleşecektir. Ancak siz Virtual Network ( Sanal Ağ) yapılandırarak dışarıdan gelen servislerin ulaşmasına izin verebilirsiniz. Varsayılan olarak, Azure Datacenter dışındaki hizmetler Virtual Network içerisinde bulunan hizmetlere bağlanmak isterse Site to Site VPN veya Point to Site VPN gibi yöntemler tercih edilir. Herhangi bir Virtual Network(Sanal Ağ) yapınız olmadan VPN yöntemlerini kullanamazsınız. (Şirketiniz ile Azure Datacenter aynı network içerisindeymiş gibi)

• Aynı sanal ağın içindeki tüm trafik varsayılan olarak izin verilmiştir ancak Azure sanal makineler veya subnet arasında ACLs'in (Erişim Listeleri) yapılandırılmasına izin verecek bir güvenlik katmanı sağlar.
• Aynı Azure Datacenter içinde olsalar bile iki sanal ağ doğrudan iletişim içerisinde olamaz. Bir sanal ağdan sanal ağa ileti gönderilebilmesi için bağlantının yapılandırılması gereklidir.(VNet to VNet VPN Kullanmak )
• VLAN sanal ağlar tarafından ne desteklenmiştir ne de anlaşılmıştır, aslında Azure sanal ağlar 3 ağa kiracı perspektifi için katman görevi görüyor.
• Sadece tcp,udp, ve icmp protokolleri Azure sanal ağları içinde desteklenir.
• Sanal ağlar diğer ofisleriniz ile aynı network içerisindeymişsiniz gibi bağlantı yapmanızı destekler. ( Site to Site VPN ) Bir sanal makineye ulaşmak için on-premises ağına bağlanmak için uygun durumda olacaksınız.

Subnets (Alt Ağlar)​

Bir sanal ağ oluştururken aşağıdaki bilgiler verilmelidir.

• Location [Zorunlu] : Azure Datacenter bölgesinde Virtual Network(sanal ağ) oluşturulacak.
• DNS Server [Opsiyonel]: Azure sizin Sanal Makinelerinize IP adreslerini atamaktan sorumlu olacak. (Tabi ki sizin vermiş olduğunuz bir IP adresi havuzundan). Dolayısıyla bunu Virtual Network(sanal ağ) detayları için yapılandırılacaktı. Eğer herhangi bir DNS sunucusu belirtmez iseniz Azure kendi DNS Sunucu adreslerini dağıtacaktır.
• Address Space [Zorunlu]: Her oluşturulan sanal ağ, en az bir ağ adres alanı ile yapılandırılması gerekir.
• Subnets [Zorunlu]: Adres alanı aralığı Azure tarafından doğrudan kullanılamaz. En az bir alt ağ adres alanı tanımlanmalıdır. Birkaç alt ağa adres alanına bölmek tercih edilebilir. Bunu tercih etmenizin diğer bir sebebi ise firmaların Azure üzerinde DMZ network yapısına ihtiyaç duymalarıdır.Bu yöntem ile alt ağlar arasında Access List ( Erişim Listeleri yazarak) DMZ Network oluşturabilirsiniz.

Notlar : Azure Virtual Network ( Sanal Ağlar) public ve private olarak IP aralıkları (CIDR gösterim) destekler. CIDR nedir dediğiniz duyar gibiyim, hemen açıklayalım. CIDR (Classless Inter-Domain Routing), IP adreslerinin daha etkin kullanımını sağlayarak IPv4 adreslerinin tükenmesini yavaşlatmayı ve İnternet üzerindeki yönlendiricilerin kullandığı yönlendirme tablolarının aşırı kalabalıklaşmasını önlemeyi amaçlamaktadır.

Depolama (Azure Storage)​

Azure Storage IaaS hizmetleri içerisinde önem verdiğimiz diğer noktalardan biridir. Müşterilerimize giderken en çok önem verdiğimiz konuların başında yerel veri merkezlerimizdeki en büyük maliyet kalemi depolama çözümleri iken Microsoft Azure bulut çözümü içerisindeki en ucuz kalemlerin başında depolama gelmektedir. Aynı zamanda bulut teknolojisinin en önemli avantajlarından birisi olan Pay As You Go ( "Kullandıkça Öde" ) yöntemi depolama çözümleri için de geçerlidir. Eğer dilenirse şirketler "CAPEX VE OPEX" yöntemleriyle inceleme yaparak maliyet/bütçe hesaplamaları sonucunda genel bir ilk yatırım yapmak yerine yalnızca ilgili depolama alanının kullanıldığı kadarı ödenir ve esnek bir biçimde aşağı veya yukarı bu değerler değiştirilebilir. Azurere Storage içerisinde barındırılabilinirken aynı zamanda big data senaryolarını destekleyecek bilimsel, finansal analiz, medya uygulamaları gibi gereksinimleri de rahatlıkla karşılayabilir. İçerisinde terabyte'larca veri rahatlıkla barındırılabilir ve işlenebilir. Azure Storage kendi içerisinde servislere ayrılmaktadır. Bunların Virtual Machine (Sanal Makine) ile ilgili olan kısımlarını tanıyalım.

Blob Storage​

Azure Blob Storage genellikle yapılandırılmamış verileri barındıran ve HTTP/HTTPS protokolü üzerinden erişim imkanı veren bir hizmettir. Büyük miktarda yapısal olmayan verileri tutmak için tasarlanmış bir hizmettir.

• Streaming için kullanılan Video ve Ses dosyalarını
• Text Dosyaları, Resim, text, binary, veritabanı yedekleri, loglar vs.
• Güvenli yedekleme ve felaket kurtarma gerçekleştirme için ( Azure Recovery Services & Backup Vault )

Yukarıda listelenen dosya türleri için gibi birçok dosya türü birçok amaç için 'Blob Storage'de depolanabilmektedir. Ancak bir Storage Account toplamda en fazla 500 TB olabilir. Blob Storage kendi için iki farklı bölüme ayrılmaktadır.

• Block blob Storage : Belgeler, videolar, resimler, yedekleme ve diğer yapılandırılmamış metin veya binary veri depolamak için kullanılır.
• Page Blob Storage: Random olarak Read(okuma) ve write(yazma) işlemleri için optimize edilmiş, sanal makinelerinizin VHD formatları için idealdir. Page Blog Storage sanal makine depolama için kullanılır.

Page Blob Storage yaygın olarak işletim sistemi diskleri ve veri diskleri dahil olmak üzere Azure sanal makine dosyalarını depolamak için kullanılır. Bir sanal makine provisioning edilmeye başlandığı zaman karşımıza iki tür Storage modeli çıkmaktadır. Bunlar Standart Storage ve Premium Storage olarak gözükmektedir. Bu iki modelin birbirlerinden farkı performans üzerinedir.

• Bir Azure Subscription içerisinde oluşturulacak Storage Account ( Depolama Hesabı ) default limit 100 olarak belirlenmiştir. Dilenirse, Microsoft tarafına case açarak bu limit aşılabilir.
• Storage Account kendi içerisinde Redundancy sağlayabilmesi için farklı replikasyon model olarak ayrılmaktadır. 4 yöntem olarak bizlere bu seçenekleri sunan Azure'ın en temel modeli olan LRS'i hızlıca açalım. Locally Redundant Storage (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. Bu repikasyon modelleri dışındakileri anlamak için Geo-Redundant Storage (GRS), Read-Access Geo-Redundant Storage (RA-GRS), Zone-Redundant Storage (ZRS) bu link sizlere yol gösterecektir.
• Standart Storage : Depolama performansı IOPS değeri ile sınırlıdır. Disk (VHD) başına maksimum IOPS standart tier için 500 IOPS disk başına, Basic Tier sanal makineler için ise 300 IOPS disk başına ve el edilecek maksimum verimlilik saniyede 60 MB olarak gösterilir. Tabii ki daha yüksek IOPS ve verimlilik diski toplanmasıyla yani (stripping) kullanılarak elde edilebilir. Bu şekilde seçilen yöntem IOPS ve Azure depolama için verimi bizlere açıklar. Sanal makinelere göre ulaşabilecek IOPS değerlerine bu link sizlere yol gösterecektir.
• Premium Storage : Premium gibi bir hizmetle depolama hizmetinde üst seviye bir hizmet vermek isteyen Microsoft, son teknoloji SSD (Solid State Drives) sunmaktadır. Sanal makineler için varsayılanda kullanılan HDD (Hard Disk Drives) performansının yetersiz olduğu durumlarda Premium hesap ile birlikte gelen SSD disklere sahip sanal makineler kullanılabilir. Yüksek performanslı diskler ile beraber Azure Sanal makineleri kullanabilirsiniz. DS ve GS Serisi Sanal Makineler Premium Storage desteklemektedir. Premium Storage ile uygulamalar VM başına 64 TB kapasite ve 80000 IOPS, VM başına okuma işlemleri 2000 Mb Seviyesindedir. Premium Storage Exchange Server ,SQL Server ,SAP vb veritabanı üzerinde çalışan uygulamalarda kullanılması önerilmektedir.

File Storage​

 Azure File Storage, On-Premises veya Cloud üzerinde çalışan uygulamalar arasında paylaşılan bir depolama alanı sunulabilmesi için tasarlanmıştır. Örneğin konfigürasyon dosyalarını, logları depolamak için bu hizmeti tercih etmek isteyebilirsiniz. İletişim için standart "Server Message Block (SMB 2.1)" protokolü kullanılmaktadır. Azure üzerindeki uygulamalar File I/O API'lar yardımıyla bu paylaşıma erişebilirler. Dolayısıyla lokalde dosya paylaşımı gerektiren bir uygulamanız ve bu paylaşımın yüksek erişebilir olmasını gerektiren bir durum varsa kodlarda çok fazla değişiklik yapmadan bu uygulamayı buluta taşıyabilirsiniz. Buna en temel örnek Cluster yapısında "Witness Server / quorum " olarak belirtmiş olduğumuz paylaşımları gösterebiliriz. Artık Cluster organizasyonunda Azure File Storage servisini gösterebilir durumdayız. Aklınıza bu hizmet On-Premises kullanılan geleneksel file server paylaşımları \\serveradı\paylasimadi" olarak gelebilir.

Fiyatlandırma (Pricing)​

Bu bölüm Azure içerisindeki laaS (Infrastructure as a Service) bileşenlerinin basit olarak fiyatlandırmasını tarif eder. Azure platformu dizayn ederken fiyatlandırma çok fazla önem taşır. Dizaynınız içerisinde dahil edilen tüm bileşenlerin farkında olmalısınız,böylece oldukça yakın bir şekilde platformun ücretini kestirebilirsiniz. Fiyat hesaplanması için Azure Pricing sayfasını veya Microsoft resmi olarak yayınladığı ve devamlı güncel tutmuş olduğu "Azure Cost Estimator Tool" adında başarılı bulduğum bir araç var. Bu aracın yetenekleri oldukça fazla. Sanallaştırma platformuzu belirtip anlık bir şekilde çalışan workload yapınıza fiyat hesaplamasını gerçekleştirebiliyor. Tabi şunu söylemekte fayda var, hesaplanan fiyatın tutarlılığı yok. Çünkü Azure tarafında, esnek davranmak tamamen sizin elinizdedir.

Fiyatı Hesaplamak​

• Her sanal makine tipine göre bir fiyat biçilir. Fiyat kaynakları hesaplamak içindir. (Depolama ve sanal ağ dahil değil.) ve 3 maddeye göre hesaplanır.(Tier,Seriler,Büyüklük)

• Azure, Virtual Machine hizmetini sunarken maliyet hesaplaması gizli bir sır barındırıyor. Maliyet kullanıcılara stabil olarak değil, kullandıkları kadar yansıyor. Tüketim dakika başına hesaplanır. Eğer Sanal makineyi 1 saatliğine kullanırsanız, 60 dakika için ücretlendirileceksiniz. Ancak 30 saniye kullanırsanız, 1 dakikadan ücretlendirileceksiniz. Eğer sanal makinelerinizin iş saatleri dışında çalışmamasını ve kestirmeden nirvana erişmek istiyorsanız, Azure Automation hizmetini incelemenizi tavsiye ederim. Blog üzerinde bu sır ile ilgili güzel bir maliyet avantajı hesaplaması yapmıştım. Azure Automation Serisi : http://hasangural.com/azure-automation-part-0giris/

• Fiyatlandırma Azure Datacenter (bölgeden bölgeye) değişiklik gösterebilmektedir. Genelde, en yüksek fiyatlandırma Avusturalya ve Brezilya'da olmaktadır .

• Bir sanal makine her zaman faturalandırılır, aksi taktirde silinir veya serbest bırakılır. (Durdurulur ve boş bırakılır.)

• Fatura detaylarına baktığınızda Depolama (Storage) ve Ağ (Virtual Network) kaynakları ayrı bir şekilde faturalandırılır. Geçici depolama (Temporary Disk) alanı sanal makineye yüklenmiş ancak ücretlendirilmez.

• Sanal makine kullanımında uygulanan vergiler vardır. Bu vergiler Azure sanal makinelerinin fiyatlarına dahil değilir, ve faturaya ayrı bir şekilde eklenir. Bu vergilerin nasıl hesaplandığı hakkında bir fikrim yok.

• Azure sanal makine fiyatlandırma detayı için şu linki tıklayın : https://azure.microsoft.com/en-gb/pricing/details/virtual-machines/

Depolama ( Storage ) Fiyatlandırması​

• Sanal makine deposu ( geçici disk hariç ) GB/Ay başına faturalandırılır.Örneğin, eğer ilk 15 gün içerisinde 100 gb kullanırsanız, ve geriye kalan 15 gün için 0 Gb kaldığında, GB/Ay başına 50 GB için faturalandırılacaksınız.Her gün, Azure tüketilmiş deponun değerini o gün için birleştirecektir.Ayın sonunda, bu değer aylık kullanım değerini hesaplamak için kullanılır.(Gün1+Gün2+......+Gün30)/30
• Azure içerisinde bir Storage Account ( Depolama hesabı ) oluşturduğunuzda dilenirse verinin replike edilmesi için depolama hesabı içerisinde replikasyon yöntemleri bulunmaktadır. Bir storage account içerisindeki veriyi dünya üzerinde bulunan farklı Datacenter içerisine replike olabilecek teknolojiye sahiptir. Bu seçim maliyeti etkileyen unsurlardan biridir. Seçim yaparken maliyet önemli ise şu yöntem pahalı doğru gidilirken şu yöntem izlenmelidir. (LRS> ZRS> GRS <RA-GRS)
• En büyük maliyet avantaj kalemi olan depolama tüketimi ile depolama maliyeti azalır. devamını depolama kullanın, ucuz GB / ay fiyatlandırma birimi olacak.
• Storage içerisinde veri transferi ile ilgili bazı kavramlar mevcut ve hemen bunları açıklayalım. Bunlarda biri olan "ingress", Azure veri merkezine yani Storage Account içerisindeki depolama çözümüne aktarılan veriyi temsil eder. Egress ise Azure veri merkezinden, yani Storage Account'dan dışarıya aktarılan veriyi temsil eder. Datacenter içerisinden bir veri çıkışı olduğu zaman hesaplamamız gerekiyor. Detayları bu adresten bulabilirsiniz. Link : https://azure.microsoft.com/en-us/pricing/details/data-transfers/
• Sadece gerçekten tüketilen depolama fatura edilir. Örneğin, sadece 50 GB içeriğiniz var, elinizde bir 200 GB boyutunda VHD oluşturursanız, sadece 50 GB ay sonuna kadar fatura edilecektir. Depolama işlemleri fatura edilir. Her yazma / okuma işlemi tahsil edilir.
• Kullandığınız kadar öde tarifesi Premium Depolama için geçerli değildir. Premium Depolama modelinde boş diskler de faturalandırılır
• Premium Depolama için her yazma / okuma işlemi için işlem ücreti alınmaz.

Virtual Network ( Sanal Ağ ) Fiyatlandırması​

• Aynı Azure Datacenter içerisine bulunan Virtual Network ( Sanal Ağ) arasında yapılan transferlere herhangi bir faturalandırma yapılmaz. (Intra-VNET, Inter-VNET aynı Region içerisinde olmak şartı ile)
• Gelen veriler ücretsizdir. Datacenter içerisinden giden ilk 5 GB veri ücretsizdir. Fiyat modellerinde dikkat edilmesi gereken nokta, kullanım oranı arttırkça fiyat azalıyor.
• Veri aktarıma ücretine ek olarak, Azure (saat esasına Başına) hizmetlerini sanal makinelere tahsis ve ilişkili olan IP adreslerine uygulanan masraf vardır. Bu masrafralar saat başı esasına tabi tutulur. Detaylar aşağıdaki gibidir.
• VIP – (virtual IP address) tüm Azure sanal makinelerinin bir VIP adresleri vardır. Eğer aynı Cloud Service içerisinde yaratıldılar ise aynı VIP adresini kullanacaklardır. Maliyet kısmına bakacak olur isek, VIP ücretsizdir. Eğer (5 VIP kadar) dilenirse aynı Cloud Service (bulut hizmeti) için çoklu VIP sahip olmak istiyorsanız, aynı maliyetle nominal bir ücret karşılığında onlara sahip olunabilir.
• PIP – (instance-level public IP address) PIP adresleri doğrudan erişim için bir Virtual Machine atanan dinamik bir Public IP Adresi (PIP). Bunlar özgür değildir ve saat bazında ücret alınır. (ancak, bir PIP maliyetleri VM başına ayda yaklaşık 3$ olarak seyretmektedir.) Direk sunucuya erişen hizmetlere örnek verecek olur isek FTP Serverın gereksinimden olayı Passive FTP port aralığını gösterebiliriz. PIP kullanıldığı zaman Azure Load Balancer gibi hizmetlerin araya girmeden sunucuya direk erişim sağlanacaktır. Çok teknik olmasada bir kavramdan bahsedelim. Public IP adreslerini istenilirse Address-Remap özelliği ile farklı Cloud Service ( Bulut Hizmetleri ) arasında geçişisini sağlayabilirsiniz. Bu özellik Azure Subscription içerisinde tanımlanan limit ile sınırı belirlenmektedir. 100 Adet adresi bir ay içerisinde değiştirebilmeniz mümkündür. Herhangi bir ücrete tabi tutulmaz.
• Eğer Site to Site VPN veya bir VNet-to-VNet bağlantısı kullanarak bir farklı lokasyonlarınızı Azure Datacenter ile aynı network içerisindeymiş gibi hizmet vermesini istediğiniz anda bir Azure VPN Gateway kullanılır. Farklı performanslar ve ölçeklenebilirlik değerlerini ve farklı maliyetler ile sunan birçok Azure VPN Gateway türü vardır. Aşağıdaki bağlantı Azure VPN Gateway türlerini göstermektedir. Fiyatlandırma bu bağlantıyı bulabilirsiniz. Üç adet farklı Azure VPN gateway türleri bulunmaktadır ve bunları kendi aralarında oluşacabilecek VPN Tüneli, Bandwith ve Express Route gibi özellikleri desteklemeleri konusunda ayrılıyorlar. Gateway türleri; Basic, Standard, High Performance.Detaylar bu link bulunmaktadır..
• Express Route : Azure ExpressRoute, Azure veri merkezleri ile şirketinizin içindeki veya ortak yerleşim ortamındaki altyapı arasında özel bağlantılar oluşturmanızı sağlar. ExpressRoute bağlantıları, genel İnternet üzerinden yapılmaz. Bu bağlantılar, tipik İnternet bağlantılarına göre daha fazla güvenilirlik, daha yüksek hız, daha düşük gecikme süreleri ve daha fazla güvenlik sağlar. Bazı durumlarda, ExpressRoute bağlantılarının şirket içi sistemler ile Azure arasında veri aktarmak için kullanılması önemli maliyet avantajları sağlayabilir. ExpressRoute'u kullanarak bir ExpressRoute konumundan (Exchange sağlayıcısı tesisi gibi) Azure bağlantıları oluşturabilir veya bir hizmet sağlayıcısı tarafından sağlanan (MPLS) hizmetli ile Azure'a doğrudan bağlanabilirsiniz. ExpressRoute'un sunduğu öngörülebilir, güvenilir ve yüksek performanslı bağlantılarla, güvenliği veya performansı riske atmadan şirket içi altyapıyı ve Azure'u kapsayan uygulamalar oluşturulabilir. Express Route'un fiyatlarını bu link üzerinden bulabilirsiniz. Bu hizmetin Office 365 tarafınında olduğunu hatırlatıp, Türkiye de bu hizmeti British Telecom hizmet vermektedir.

Dizayn Husuları (Design Model)​

Azure laaS VM (Infrastructure as a Service ) ve organizasyonların kendi alt yapıları için özel sanal makineler kullanmayı planlarken bu bölümde, bazı tasarım konuları ve öneriler anlatacağız. Tasarım çok önemlidir. Hatalı tasarım performans, olumsuz bir bakış ve hatta hatalı maliyet dezavantajları ortaya çıkaracaktır. Azure içerisinde yaratılan sanal makinelerin üç durumu vardır. Bunlar sırasıyla aşağıdaki gibidir.

Virtual Machines ( Sanal Makineler)​

• Running ( Çalışır Durumda ) bu durumda olduğunda Microsoft bizlere Tüm sanal makine kaynakları fatura edilir -> Virtual Machine, Virtual Network ve Storage Account
• Stopped (Tahsis Edilmiş): Sanal makine işletim sistemi (makine işletim sistemi içinden durdurulur ise) ile durdurulduğunda Bu -> Tüm sanal makine kaynaklar fatura edilir: Virtual Machine, Virtual Network ve Storage Account
• Stopped (Ayrılmamış) : Sanal makine Azure portal üzerinden kapatma düğmesine veya Azure PowerShell / API kullanarak durdurulduğunda bu -> Virtual Machine ( Sanal Makine) tarafından kullanılan sadece (Storage Account)depolama faturalandırılmış olacaktır.

Her zaman bizlerin ihtiyaçlarına en uygun en az sanal makine boyutu ile başlayın. Daha sonra gerekli sanal makine yapılandırması yükseltebilirsiniz. Yazımızın Bileşenler bölümünde bahsetiğimiz Availbility Set sayesinde SLA süremisini arttırmak için Standart Tier sanal makineleri kullanıyorduk. Eğer böyle bir gereksinime ihtiyacınız yok ise, Basic Tier ile başlayabilirsiniz. ( SLA %99.5 olarak belirtiliyor.) Unutmayalım ki Basic Tier'da her boyutta sanal makine yok.

Virtual Networks ( Sanal Ağlar)​

Varsayılan olarak, dinamik bir IP adresi havuzu tarafından oluşturulan sanal makineye IP Adresi ataması gerçekleşir. Bu IP adresi dinamik olarak ataması gerçekleştirilmiştir. Kullanmakta olduğunuz veya hizmet veren sunucularınızın mümkün oldukça Azure tarafında IP Adreslerini statik olarak ayarlamalısınız. Sanal makine sağlama/oluşturma sırasında bu IP adresini statik olarak sağlamanın iki yöntemi bulunuyor.

• Bunların başında ellerimizi biraz kirleterek, Azure Powershell Module ile sanal makine oluşturarak statik bir IP atamasını gerçekleştirebilirsiniz.
• İsteğe bağlı olarak Azure Yeni Portal ( Ibıza Portal) üzerinden sanal makineyi oluştururken statik IP atamasını gerçekleştirebilirsiniz.
• Çalışan bir sanal makinenin IP adres atamasını dinamikten statik doğru değiştirdiğinizde herhangi bir kesinti olmadan IP adresini değiştiremezsiniz (VM yeniden başlatma)

Azure ile kendi Datacenter yapınızın aynı network içerisindeymiş gibi bağlantı kurmasını planlıyorsanız ( Site to Site VPN – Multi Site VPN) RC1918 IP aralıkları adresleri aralıklarını kullanmak zorundasınız. Farklı Azure Virtual Network yapıları içerisinde geçiş yapabilmek için aşağıdaki kurallara dikkat edilmelidir.

• Bir sanal makine Virtual Network içerisindeki Subnets( Alt Ağlar) arasında geçiş işlemini Powershell ile yazılan bir cmdlet sayesinde gerçekleştirir. Çalıştırılan cmdlet sanal sunucunun re-start işlemi ile ilgili Virtual Network(Vnet) içerisinde Subnets değişimini gerçekleştirir.
• Azure üzerinde birden fazla Virtual Network olduğunu düşünürsek ve sanal sunucularınızın bağlı olduğu Virtual Network(Vnet) değiştirmek isterseniz işte burası biraz can sıkıcı olabilir. Bu kısımda yapmamız gereken sanal makineyi siliniyor ( Sanal Sunucunun dosyaları değil ) ve daha sonra aynı dosyalar kullanılarak (VHD) yeniden provisioning edilmesi gerekiyor. ( Ortalama 20-30 dakika gibi bir süre alabilir. Kestirmeden nirvana için Powershell Scriptler kullanın. )

Azure sanal makineleri layer 3 (IP) gateway veya routers gibi davranmayı desteklemez. Windows üzerinde bunu yazılımsal olarak gerçekleştirmek için iki adet eklenen NIC ile gerçekleştirme şansınız yok. Site to Site VPN ve Point to Site VPN bağlantı şekillerini kullanabilmeniz için oluşturulan Virtual Network Gateway kesinlikle Dynamic Routing olarak yapılandırılması gerekiyor. VPN Yöntemlerinin detayları için bu adres size yardımcı olacaktır.

Azure tarafında farklı IP adresler türleri bulunmakta, sen bunların farkında olmalısın.

• Internal IP address : Ayrıca DIP olarak da bilinen, sanal makinenin özel iç IP adresidir. Vnet ( Virtual Network) adres alanı havuzundan bir sanal makineye atanan yerel IP adresidir. Bu IP adresi dış ağdan ulaşılamaz. Eğer statik olarak ayarlanır ise sunucu hizmet verdiği sürece bu IP adresini kullanacaktır. (Statik IP Adresi atama şekillerinden yukarıda bahsetmiştik.)
• Internal virtual IP address : Ayrıca LIB olarak anılır. ( Internal Load Balancer ) Virtual kelimesi bize, sanal bir yük dengeleyicden bahsediyor. Internal(iç) sanal IP adresi yükü dengelenmek(paylaştırmak) istenen iş yüklerini erişmek için dahili servislerde tarafından kullanılmak üzere Azure'un İç yük dengeleyici servisi tarafından atanan bir IP adresidir. Bu yazı daha önce Load Balance bölümde açıklanmıştır.

Yukarıdaki IP adres modellerine ek olarak, fiyatlandırma bölümünde VIP ve PIP kavramlarınıda unutmayalım.

Storage (Depolama)​

• Veri disklerde istenen IOPS / Throughput değerlerini elde etmek için, striping yöntemini kullanabilirsiniz. Bugün Microsoft, disk striping yöntemi için Azure sanal makine içinde Storage Spaces(Windows Server içerisinde bir roldür.) özelliğinin kullanılmasını önerir.
• Premium depolama yönetimi Azure Yeni portalı üzerinden mümkündür. DS-Serisi dağıtmak istiyorsanız, Azure yeni portal kullanmalıdır.
• İstenen IOPS değerini elde etmek için, (Depolama bölümünde) yukarıda tartışıldığı gibi / verim tamamen Premium depolamada gözükmekte, istenilen performansı elde etmek için, yeterli Sanal Makine Boyutunu / Premium Disk seçmelisiniz. Her sanal makine boyutu (DS-Serisi) maksimum IOPS / Verim sınırı vardır unutmayın. Buna ek olarak, her bir Premium disk ( P10,P20,30) türü ve maksimum IOPS hacmine sahiptir.

Management (Yönetim)​

• Azure Yönetim portalı (https://manage.windowsazure.com/): Bu adresten hemen hemen tüm yönetim görevlerini yapabilir ve klasik portal olarak anılmaktadır. Bu portal üzerinden birçok eylem ve özellikleri artık yapamaz duruma geldik. Yeni Azure Portal kullanmak zorunda olacaksınız. ( Premium Storage , DS Serisi Makineler)
• Azure portalı (https://portal.azure.com/): Bu adtesten Azure Yeni Portalına ( metro arayüzü tarzı portal) erişim sağlayabilirisiniz. Public olarak kullanabilir durumdadır. Bu portal sayesinde Resource Manager modeli yapabilecekleriniz oldukça fazladır. Resource Manager detayları için bu yazıya göz gezdirmenizi tavsiye ederim.
• Klasik yönetim portalı (https://manage.windowsazure.com/) zamanla kaldırılmış olacaktır. Bu yüzden başlangıç ve alışkanlığın arttırmak adına müşterilerimizi Azure Yeni Portal üzerine alıştırmak en mantıklısı gözüküyor. ( Recovery Services, Azure Backup Vault, Machine Learning gibi hizmetleri kullanabilmek ve yönetebilmek için klasik yönetim portalını kullanmak şart.)
• Azure Yeni Portal, kullanıcıya daha yakın, alışkın olduğu arayüzler (Metro tasarım), esnek olarak tablet ve dokunmatik telefonlar ile yönetim gerçekleştirebilirsiniz.
• Bitmek bilmeyen avantajlarından bir tanesi Azure Yeni Portalın eski yönetimde klasik portal ile bir çok özel durumlar için Azure Powershell modülüne ihtiyaç duyuyorduk fakat artık bunların hepsini Azure Yeni Portal arayüzünden gerçekleştirebiliyoruz. Sanal Makine ( VM) şifreleri sıfırlama, DS Serisi sanal makineleri, Role Based Access Control ( Spesifik kaynaklara spesifik kullanıcılara yetkiler vermek.)

Okumanın ötesinde​

Bildiğiniz gibi İnternetin Çağında yaşayan Google ve Bing gibi arama motorları sayesinde, hiçbir şey yok/bulunamadı dememeliyiz. Eğer Azure hakkında daha fazla bilgi edinmek istiyorsanız birkaç noktara dikkat çekmek istiyorum.

• Burada Azure giriş seviyesi ücretsiz e-kitaplar bulunmaktadır. http://www.microsoftvirtualacademy.com/ebooks
• Yukarıdaki e-kitap tavsiyesi dışında Microsoft kendi eğitim platformu olan "Microsoft Virtıal Academy" ile bir çok teknolojiyi geliştiren kişilerden dinleyebilirsiniz. http://www.microsoftvirtualacademy.com/
• Microsoft Azure resmi Blog sayfasını şiddetle öneriyorum. Bu sayfada tüm servislerin güncellemeleri ilk önce bu sayafada yayınlanıyor. https://azure.microsoft.com/en-us/blog/
• Son olarak kutsal bilgi kaynağı olarak gördüğüm yöntemi açıklıyorum. Formül ise oldukça basit, "favori arama motoru + Anahtar kelime" benim tercih ettiğim ve en çok kullanılan öğrenme yöntemidir.

Bu yazının amacı, Azure sanal makineleri hizmetinideki sır perdesini aralamak ve farklı özellikleri ve bileşenleri açıklamaktır. Sağlanan bilgilerin sadece bir başlangıç noktası var ve birkaç ay üzerinden geçtikten sonra kaldırılmış ve değişmiş olabilir. ( Değişime hazır olun!) Azure sürekli geliştirmeleri, hızlı çıkan yeni özellikleri ve büyüme aşaması ile meşhur.(Bu ne zaman çıkmış diyeceğinizi duyar gibiyim.) Her zaman son güncellemeler ve haberler için Microsoft adreslerini kontrol etmenizi öneririm

Microsoft Azure Platformu üzerinde çalışıyorsanız ve Azure Ibıza (Yeni) Portal üzerinden bir hizmeti kullanmak istediğiniz zaman deployment süreçlerine başladığınızda karşınıza "Service Management" ve "Resource Management" şeklinde iki farklı model çıkıyor olacaktır. Bu terimlerin, Microsoft Azure bulut hizmetlerine erişimi sağlayan iki farklı REST API olduğunu söylemekte fayda var. "Resource Manager" bizlere Microsoft Azure üzerinde yeni bir deployment modeli sunar. Bu yeni model, Classic ( Service Management) dağıtım modelinden çok önemli farklılıklar içermektedir ve iki model tamamen birbiriyle uyumlu değildir. Kaynakların dağıtımını ve yönetimini basitleştirmek için Microsoft eğer mümkünse "Resource Manager" deployment modelini kullanmanızı tavsiye eder. Resource Manager ile ilgili daha önce blog içerisinde yazı serisine erişebilirsiniz.

Bu dağıtım modellerinden hangi API tercih edilmelidir sorusuna cevap verelim.

• Azure Service Management (ASM) - "eski" API
• Azure Resource Manager (ARM) - "yeni" API

Azure Service Management ( ASM )​

Daha önce de belirtildiği gibi, Azure Service Management "eski" API ve http://manage.windows azure.com de web portalı ilişkilidir. Bu API nevi şahsına münhasır iletişim için ayrı bir PowerShell modülü de var. Azure Classic Portal içerisinde bir hizmet oluşturduğunuz zaman karşımıza "Cloud Service" kavramı çıkmaktadır. Service Management (Classic) API programmatic olarak XML kullanarak Azure kaynaklarınızı yönetmenizi sağlıyor.

Classic Deployment (Service Management) modelinin hizmetler ile ilişkisini aşağıdaki şekilde görebilirsiniz. Aşağıdaki örnekte, bir Virtual Machine genelinde detaylandırılmıştır.

• Cloud Service sanal makine(ler) ev sahipliği yapar ve onlara aynı container içerisinde gibi davranır.
• Cloud Service sanal makine(ler) otomatik olarak network kartı (NIC) ve Azure tarafından atanan bir IP adresiyle sağlanmaktadır. Ayrıca, Cloud Service Windows tabanlı sanal makineler için uzak masaüstü(RDP) ve Remote PowerShell trafiğine izin verir. Linux tabanlı sanal makineler için ise Shell (SSH) endpoint noktalarını içermektedir.
• İşletim sistemi (OS Disk), temporary ve eklenen diskler dahil olmak üzere bir Storage Account ihtiyacı vardır.
• Aynı Cloud Service içerisine alınan sanal makineler Availability Group olarak yapılandırılabilir ve endpoint tanımlamaları için Load-Balancer özelliğini destekler.

Azure Resource Manager ( ARM )​

Azure Resource Manager (ARM) API Azure bulut kaynakları ile etkileşim için bir JSON odaklı API sunar. Bu API ailesinin kendi aralarında artıları ve eksileri var, ama aralarında uyumluluk olmadığını anlamak önemlidir. Resource Manager sayesinde artık kaynaklarınızı mantıksal gruplara yani Resource Group içerisine alarak yönetimde esneklik kazanabiliyoruz. Bunları temel olarak sıralayacak olur isek,

• Role Based Access Control
• Tags
• Audit Logs
• Resource Locks
• Template Deployment

Yukarıdaki kavramları daha iyi anlamak adına Blog içerisinde "Resource Manager Nedir" makale serisini okumanızı tavsiye ederim. Resource Manager ve Service Manager kavramlarının farklarını aşağıdaki şekilde bulabilirsiniz.

Microsoft Azure yeni deployment modeli olan Resource Manager kendine özel yeni bir API bizlere sunmaktadır. Azure Resource Explorer developer olan kişiler tarafından bu yeni modeli keşfetmeleri için çok faydalı bir araç. Resource Explorer erişmemizin birden fazla yöntemi bulunmaktadır. Bunların en temeli olan Azure New (Ibıza) Portal üzerinden erişebiliyorsunuz. Mevcut Azure hesabınız ile oturum açtıktan sonra, Resouce Explorer tıkladığınız zaman Resource Manager API bizlere verdiğini Provider kullanarak "GET","PUT","DELETE","POST" methodlarını API içerisine gönderip aksiyonlar alabilir veya veriler çağırabiliriz. Aşağıdaki örnekte Azure New (Ibıza) Portal içerisinde Resouce Explorer sayfasına erişebiliriz.

Resource Explorer bölümüne Azure Portal içerisinde eriştiğiniz zaman JSON formatında olarak kaynaklarımızın detaylarınızı keşfedebilirsiniz.

Bununla beraber dilerseniz, https://resources.azure.com sayfası üzerinden Azure Credentials ile oturum açtığımız zaman karşınıza yukarıdaki gibi bir sayfa gelecektir. Fakat bu sayfa şuan Preview olup bahsetmiş olduğumuz Resource Manager API ile "GET","PUT","DELETE","POST" methodlarını Web sayfası üzerinden gönderme şansımız bulunmaktadır. Biraz daha detaylandırırsak dilerseniz, oluşturulan Resource Group kaynaklarınızı silebilir veya Resource Grouplar arasında geçişler sağlayabiliriz. Resource Manager modelini ile ve sizde danışmanlık süreçlerinizde herhangi bir hizmeti deployment ederken zaman kazanmak istiyorsanız Resource Manager Template yapısını kullanarak çok hızlı bir şekilde provisioning işlemlerinizi gerçekleştirebilirsiniz. Resource Manager ile deployment yaparken arka tarafta bir JSON formatında kullanmak istediğiniz kaynaklarınızı detaylandırmanız gerekiyor. JSON formatının belirli bir syntax ile yazılmış olması ve bu JSON dosyasını Azure Powershell ( Resouce Manager) Modeli ile deployment sürecini başlatma şansınız var.

Bu tarz deployment süreçlerini diğer yazılarımda detaylarına iniyor olacağım. Fakat bu yapının nasıl çalıştığını anlamak için dilerseniz, GitHub üzerinden merakınızı gidebilirsiniz. Eğer biraz daha kestirmeden nirvanaya ulaşmak istiyorsanız aşağıdaki sayfa üzerinden tüm Deployment Template erişebilirsiniz. Hemen bu süreci anlamak adına https://azure.microsoft.com/en-us/ sayfasına girdiğiniz zaman, "Resources" sekmesiden "Templates" kısmına tıklayalım ve karşımıza tüm publish edilen Resource Manager için geliştirilmiş template örneklerini bakalım.

"Templates" sekmesini tıkladıktan sonra karşımıza geliştirilen ve paylaşılan bütün Resource Manager Template örnekleri gelecektir. Aşağıdaki örnek üzerinde herhangi bir template tıklayıp deployment sürecinin nasıl işlediğini anlayalım.

Örnek olarak "Join a VM to an existing domain" yazısının üzerine tıklayarak Developer tarafından geliştirip ve publish konumda olan Resource Manager modeli ile hazırlanmış Deployment Template kullanmaya başlayalım.

Yukarıda görüldüğü gibi, "Deploy to Azure" butonu ile sizi Azure New Portal içerisine yönlendirecek ve geliştirilen Deployment Template içerisine tanımlanan JSON dosyasının içerisindeki parametreleri göndererek provisioning sürecine başlıyor olacaksınız. Resource Manager deployment modelini kullanarak sizde basit bir JSON dosyasına oluşturmak istediğiniz kaynaklarınızın detaylarını belirtip zaman kazanabilirsiniz.

Azure Automation, Infrastructure as a service (IaaS) ve Platform as a service (PaaS) gibi aldığınız hizmetlerin Azure içerisinde uzun çalışan, hata eğilimi olan ve sık sık tekrarlanan görevleri düzenli olarak gerçekleştiren bir servistir. Bu makale serisi içerisinde Azure Automation hakkında sık sorulan sorulara cevap vermeye ve genel alt yapısını incelemeye çalışacağız. Makale serisine başlamadan önce size Anıl Erduran'ın "Microsoft Automation Dün Bugün ve Yarın" adlı yazısını okumanızı şiddetle tavsiye ederim. Şimdi ise yarını detaylandırmaya başlayabiliriz.

Bu servisi kullananlar zaman, maliyet avantajı ve iş güçü kazanır. Bulut ortamlarında düzenli olarak gerçekleştirdiğiniz görevler için, (Provisioning ve Scale VM, Web Sites, Test Environment vb.) hiçbir insan müdahalesi olmadan hatasız, istenilen veya belirli aralıklarla gerçekleşmesini sağlar.

Azure Automation Windows Powershell Workflow söz dizimine uygun olarak yazılmış Runbook aktiviteleri kullanır. İhtiyacımızdan dolayı Workflow yazıldığı zaman bunu arka tarafta Windows Workflow Foundation (WWF) tarafından yürütüldüğünü söylemekte fayda var. Service Management Automation (SMA) ile Azure Automation benzerlik göstermektedir. İkisi de Windows Powershell Workflow ile geliştirilen Runbook aktivite biçimini kullanırlar. Azure Automation içerisindeki Runbook aktiviteleri Public Cloud Resource ve Azure ile ilgili powershell cmdlets ailesine erişim sağlarken, Service Management Automation (SMA) üzerinde bulunan Runbook'lar Windows Azure Pack'in parçalarına ve Azure Pack cmdlet'lere ihtiyaç duyar. Makalemiz içerisin de geliştireceğimiz Runbook aktiviteleri sayesinde, Azure Automation ihtiyaç duyulan zamanlar içerisinde ilgili sunucuların hizmet vermesini sağlayarak aldığımız hizmetin maliyetlerini azaltacak. Kaba bir matematik ile bunlara çok basit örnekler verelim.

Azure, Virtual Machine hizmetini aylık olarak kullanıcılarına sunmakta. Ancak bu hizmetin maliyet hesaplaması gizli bir sır barındırıyor. Maliyet kullanıcılara stabil olarak değil, kullandıkları kadar yansıyor. Geliştirdiğimiz Runbook sayesinde bu sırrı ortaya çıkartacağız. Örnek olarak A3 tipinde bir Virtual Machine alındığında, aylık maliyeti yaklaşık olarak 270($) dolardır. Bir ayda 720 saat olduğunu düşünürsek, bu hizmetin saatlik masrafı kabaca 0,375($) dolara denk gelmektedir. Saatlik masrafı gözünüzde küçük gözükebilir ancak birazdan geçeceğimiz derin hesaplar sonucu maliyetin küçük olmadığını göreceksiniz.(Yaptığımız veya bir sonraki yapacağım hesaplamalarda ay 30 gün olarak alınmıştır.) Örnek aldığımız sanal makinenin şirket içerisinde hizmet verdiği saatlerinin 09:00 – 18:00 arasında olduğunu varsayalım. Kullanılan sanal makinenin günün sadece 9 saati çalışmasına karşın, şirket sanal makineyi Azure üzerinde tüm gün hizmet olarak alıyor, saat ayrımı yapmıyor. Bu sebepten dolayı ödeyeceği 3,375 ($) dolar miktarı, 9 ($) dolara yükseliyor ve bu hesap ise sadece günlük kısmı. Aylık olarak hesaplamada ise, normal ödenmesi gereken miktar 101($) dolardır. Arada oluşan 169($) dolar farkı, yıllık olarak bakıldığında 2.028($) dolara yükseliyor. Geliştireceğimiz Runbook sayesinde, sanal makinenin sadece çalışması gerektiği saatler içerisinde çalışarak, maliyetten tasarruf etmemizi sağlayacaktır.

Azure Automation içerisinde oluşturduğumuz Runbook'lar ile On-Premises Datacenter yönetmeniz mümkün değil. Şimdiler de ismini çok sıklıkla duyduğumuz Operation Management Suite ile beraber artık Hybrid Runbook Server kavramı hayatımıza girmiş durumdadır. Azure Automation içerisin de buluanan Runbook'lar ile artık On-premises içerisin de Hybrid Runbook Worker olarak belirlenen sunucu tarafından uygulanabilir durumdadır. Operation Management Suite olması şartıyla, yüklenen bir Agent sayesinde gösterdiğiniz sunucuyu Hybrid Runbook Worker olarak belirtebilirsiniz. Aşağıdaki resim ile bu senaryonun kafamızda kısa süreliğine de olsa gerçekleşmesini istiyorum.

Azure Atuomation serisine aşağıdaki linklerden ulaşabilirsiniz.

• Azure Automation - Part 1 - Automation Account Oluşturulması
• Azure Automation - Part 2 - Assets Kullanımı
• Azure Automation - Part 3 - Runbook Kullanımı
• Azure Automation - Part 3.1 - Runbook Kullanımı
• Azure Automation - Part 3.2 - Runbook Kullanımı

Azure Automation kullanabilmeniz için Azure Subscription sahip olmanız gerekiyor. Mevcut bir Azure hesabı sizlere Azure üzerindeki kaynaklara erişmenizi sağlar. (Cloud Services, Service Bus, Storage Account, Mobile Services, vd) Azure Automation Account hesabı ise, mevcut hesabınız için tüm otomasyon kaynaklarını tutar. ( Runbook, assets)

Yeni bir Automation Account oluşturmak için birçok yöntemimiz bulunur. Bunlardan en basit ve en kolayı mevcut Azure Portal içerisinden veya Preview Portal üzerinden yeni bir Azure Automation Account yaratabilmektir. Azure üzerinde ihtiyaçtan dolayı birçok Automation Account yaratılabilir. Farklı Azure Region üzerindeki IT Operasyonel işleri yöneten kişilere ait farklı Automation hesapları oluşturulabilir. Bir subscription içerisinde 30 adet farklı Automation Account yaratılabilir.

Automation Account oluşturulması​

Azure Management Portal üzerinde oturum açılır. Portal içerisinden sol tarafta Automation kısmına gelip "Create an Automation Account" seçilir.

Karşımıza gelen ekran içerisinde Automation Account hangi Region üzerinde yaratılacağını ve geçerli bir isim verilerek "Complete" butonu tıklanır.

Hesabımızın başarıyla oluştuğunu gördükten sonra, artık Automation Account içerisindeki kavramları incelemeye başlayabiliriz. Automation Account içerisine girdiğim zaman karşımıza bizi "Get Started" sayfası karşılıyor olacak.

Karşımıza gelen "Get Started" dışında yan taraflarında birçok sekme var. "Get Started" sayfası içerisinde yeni bir runbook oluşturmak, Technet Gallery üzerinden geliştirip paylaşılan hazır runbook'lara erişmeniz mümkün. Automation Account içerisindeki sekmeleri sırasıyla inceleyelim ve neler yaptığını anlayalım.

• Dashboard : Otomasyon süreçleri için diagnostic, job state ve usage information gibi bilgileri gösterir. Bununla beraber, 30 gün veya istenilirse bir saatlik detaya kadar Account içinde gerçekleşen farklı işlerin durumunu ( başarısız, durdu, tamamlanmış ve çalışan) gibi bilgileri gösterir. Son olarak da mevcut Automation Account içerisinde runbook sayısını ve değişkenlerinin toplam sağ alt kısımdan rakamlarını görebilirsiniz.
• Runbooks : Mevcut yazdığınız veya Gallery üzerinden indirdiğiniz tüm Runbook bu ekran içerisinde gözükmektedir. Belirli tarihler ve saatler ile runbook durumunu için filtreleme yapabilirsiniz. Dilerseniz kendiniz geliştirdiğiniz Runbook Import edebilir yada başkasına göndermek amacıyla export edebilirsiniz.

• Assets : Runbook içerisinde kullanılan değişkenlerin yönetimi bu bölümden sağlanır. Variables, Connection, Schedule isteğe bağlı olarak bu değişkenler eklenir. Eklenen bu değişkenler, Automation Account içerisindeki tüm runbooklar tarafından erişilebilir. Integration Module sayesinde ilgili cmdlet ailesini Azure Automation içerisine yükleme şansına sahipsiniz. Bildiğimiz gibi Powershell içerisin de Module mantığı vardır. Azure Automation tarafında bir workflow geliştirdiğinizi hayal edelim. Bu Workflow içerisin de örnek olarak Active Directory veya Office 365 ile ilgili cmdlet bulunduğu varsayalım. İşte bu cmdletlerin Azure Automation tarafından bilinmesi için ilgili modülleri Azure Automation hesabının içine atılması gerekiyor. İstediğiniz Powershell Modulünü buradan "Import Module" tıklayarak ekleyebilirsiniz.

• Scale : Free veya Basic olarak Automation planınızı seçmenize olanak verir. Bu kısımda önemli ve atlanmaması gereken bir nokta var, seçtiğiniz plan Azure Subscription içerisindeki tüm Automation hesapları için geçerlidir. Ücretsiz plan ayda 500 dakikaya izin verir ve fatura edilmez. Eğer kullanımı sınırsız dakika gerekiyorsa, Basic planını seçin.

Bir önceki yazımızda, Automation Account oluşturma adımlarından bahsettik ve Assets kavramını kısa bir açıklamasını önceki yazımızda yapmıştık. Bu yazımızda Assets kavramını detaylandırmaya çalışacağız. Assets bölümü Azure Automation hesabı içerisin de en önemli kısımlardan biridir. Assets bölümünde Azure Automation Account hesabı için Integration Module ve Settings kısmı bulunmaktadır. Açıkcası bu kısma Settings demek pek hoşuma gitmiyor. Portal içerisinde bu şekilde ekleyeceğiz ama değişkenler demek bundan sonra daha doğru gibi gözüküyor.

Runbook aktivitelerinizin içerisin de kullandığınız cmdlet eğer ilgili Automation Account içerisinde yok ise Assets içerisinde Integration Module ile yükleme şansına sahipsiniz. Bu işlem bizim için oldukça basit. Assets bölümünü kullanmamızdaki diğer temel amaç eklediğimiz Settings ( Değişkenlerden) oluşmaktadır. Tüm script dillerinde olduğu gibi PowerShell içerisinde de string ya da integer tabanlı nesneler istenilen değişkenlere atanarak, scriptin devam eden bölümünde ihtiyaç olduğunda rahatlıkla kullanılabilir. Biz portal içerisinden "Add Settings" tıklayarak değişkenler oluşturarak Runbook içerisinden bu değişkenlere erişim sağlayarak Workflow'un devam eden bölümünde ihtiyaç olduğunda kullanabileceğiz.

Assets kısmında bulunan değişkenlere ve Integration Modüllere erişim noktasında önemli bir bölüm var. Tanımlamış olduğunuz değişkenleriniz veya eklediğiniz Integration Modülleriniz geliştirdiğiniz farklı Runbook aktiviteleri içerisinden tekrar erişilebilir durumdadır. Bu kısma örnek verecek olursak aşağıdaki resimden ilerleyelim.

Yukurdaki resimde üç adet "Asset 1", "Asset 2", "Asset 3" adında değişkenlerim bulunuyor. Bu değişkenler, sırasıyla "Integer", "String" ve "Credential" olduğunu varsayalım. "AA" adında bir Azure Automation Account içerisinde tanımlı olarak gözükmektedir. Bununla beraber bu Automation Account içerisinde iki adet Runbook aktivitem var. Bunlar "A" ve "B" adında gözükmektedir. Bu Runbook aktivitelerinde yazılan Powershell Workflow içerisinde tanımlamış olduğumuz Settings(Değişkenler) "Get-AutomationVariable –Name değişkenadı" şeklinde çağrılır ve geliştireceğiniz Runbook içerisinden erişebilirsiniz.

Azure Portal içerisinden, "Add Settings" tıklanarak herhangi yeni bir değişken oluşturmak istediğiniz zaman, karşımıza gelen değişken tiplerini tanıyalım.

• Credential Asset : Bu değişkeni eklemek istediğiniz zaman karşınıza iki farklı tip ile geliyor olacak. Bunlar "Certificate ve Powershell Credential" şeklinde gözükecektir. Oluşturulacak olan Credential değikenine isim verdikten sonra, Assets bölümünde gözükecetir. Bu değikenler şifrelenir ve her otomasyon hesabı için oluşturulan benzersiz bir anahtar kullanarak Azure Automation hesabı içinde saklanır. Bu anahtar bir ana sertifika tarafından şifrelenir.
• Connection Asset : Automation hesabınızda oluşturduğunuz Runbook aktiviteleriniz üzerinden herhangi bir harici hizmete veya uygulamaya bağlanmak için gereken bağlantı bilgileri için tanımlanır.
• Variable Asset : Runbook aktivitelerini geliştirirken en çok işimiz olacağı yer. Powershell içerisinde tanımladığımız "String","Integer","Boolen","DateTime" tipinde nesneler tanımlanarak değişken haline gelir ve Runbook aktiviteleri içerisinden çağırılır.
• Schedule : Geliştirdiğimiz Runbook aktivitelerini Schedule bir şekilde çalışmasını sağlamak için oluşturduğumuz değişken yöntemidir.

Assets oluşturmanın birçok yöntemi var. İsterseniz, Azure Portal, Preview Portal ve Azure Powershell ile yaratma şansına sahipsiniz.

Azure Portal içerisinden bir "String" tipinde Variable Asset oluşturalım. Automation Account içerisine girdikten sonra, "Add Settings" tıklanır ve karşınıza yukarıda bahsetmiş olduğumuz Asset tipleri gelmektedir. Bu kısımda "Add Variable" seçilir.

Add Variable seçip ilerledikten sonra, karşımıza değişken tipleri gelecektir. Bu ekranda ben "String" tipinde oluşturacağımı söyleyeceğim ve içerisine bir değer gireceğim.

Variable Type olarak String seçildi ve değişkenimizin adı "MyNewVariable" olarak belirledik bir sonraki ekrana geçerek değişkenimize değer ataması gerçekleştireceğiz.

Yeni bir String tipinde Varriable Asset tanımlamış durumdayız. Artık Automation Account içerisindeki tüm Runbook aktiviteleri üzerinden erişilebilir durumdadır. Tanımladığımız değişkeni Runbook içerisinde yazdığımız Powershell Workflow içerisinden çağırmak için aşağıdaki örnek bizlere yol gösterecektir. Yukarıdaki ekran içerisinde bir yere daha dikkatinizi çekmek istiyorum, "Encrypted" kapalı olarak gelmiş durumdadır. Eğer bu özelliği aktif ederseniz, tanımladığınız değişkenleriniz Automation hesabınız içerisinde Encrypted bir şekilde saklanacaktır.

Get-AutomationVariable cmdlet'ini Runbook içerisinde kullanarak tanımladığım Asset adını gönderek değişkenin içerisindeki değere Runbook içerisinden artık erişebilir durumdayım. İsterseniz, Azure Powershell Module ile yeni bir değişken yaratabilirsiniz.