Operations Management Suite Part 2 – Genel Mimari

Bir önceki makalemizde OMS’den kısaca bahsetmiş ve OMS’in temel aldığı Hibrit bulut mimarisini genel olarak açıklamıştık.

Operations Management Suite, Microsoft tarafından sunulan ve içerisinde log analizi, güvenlik, compliance, backup-recovery, otomasyon gibi bileşenleri barındıran bir bulut yönetim çözümüdür. OMS’in temel amacı farklı veri merkezlerinde yer alan uç noktalarınız üzerinde tam bir hakimiyet sağlamanız ve ayni zamanda System Center yatırımlarınızı buluta entegre edebilmenizdir.

Öncelikle Operations Management Suite içerisinde bulunan bileşenleri genel olarak inceleyelim.

Automation: Eğer ayni isi iki kez yapıyorsanız, onu otomatize edin. Daha önceki yazılarımızda bahsettiğimiz gibi Microsoft Automation alanında son yıllarda önemli atımlımlar gerçekleştirdi. PowerShell ile yıllar önce başlayan süreç su anda Hibrit, private ve public cloud mimarilerinin tamamını kapsayabilecek otomasyon çözümlerine evirilmiş durumda. Bu surecin son halkası olan Azure Automation sayesinde kendini tekrarlayan operasyonel görevlerin büyük bir kısmını otomatize etme şansına sahipsiniz. OMS ise Azure Automation ile entegre bir şekilde çalışarak tam olarak Hibrit bir otomasyon çözümünün yönetimini mümkün kılar. Hibrit otomasyon çözümünden kastimiz ilk bölümde bahsettiğimiz esnekliğin tam olarak sağlanabilmesi. Yani kendi veri merkezinizdeki bir istemci üzerinde bulunan PowerShell editörü ile hazırladığınız bir runbook artık bulut otomasyon çözümü içerisinde de kullanılabilir. İster komut satiri üzerinden isterse Azure Automation görsel ara yüz üzerinden rahatlıkla otomasyon runbooklari hazırlanabilir ve manuel süreçler otomatize edilebilir. Bu runbooklar istenirse manuel bir şekilde tetiklenebilir, farklı sistemler tarafından başlatılabilir yada zamanlanarak istenilen tarihlerde çalıştırılabilir. OMS ise bu Hibrit otomasyon yaklaşımının merkezi bir ara yüzden izlenebilmesi ve yönetilebilmesini sağlar.

Log
Analytics: Log analiz hizmeti size tümleşik arama ve custom ara yüzler üzerinden gerçek zamanlı log analizi yapma imkânı verir. Bu hizmet sayesinde farklı uç noktalardan loglar toplayabilir, ilişkilendirebilir, arama gerçekleştirebilir ve toplanan bu veri üzerinde farklı aksiyonlar alabilirsiniz.

Bu hizmet öncelikle farklı veri merkezlerindeki uç noktalardan veriyi toplar, ardından toplanan veriyi görselleştirerek analiz imkânı verir. En önemli nokta toplanan bu datanın hem geçmişe yönelik olması hem de gerçek zamanlı veriyi içermesidir.

Security – Compliance: OMS ayni zamanda kullanıcı, is yükleri ve sunucular için ek koruma çözümlerini devreye almanızı sağlar. Uç noktalarınız için eksik güncelleştirme ve virüs tanım detaylarını raporlayabilir, security eventlerini toplayabilir, forensic-audit-breach analiz görevlerini toplanan bu veriler üzerinde çalıştırabilirsiniz.

Backup and Disaster Recovery: Son olarak OMS ile birlikte backup-recovery çözümleri de aktif edilebilir. Azure Site Recovery ve Azure Backup ile birlikte sunulan backup-recovery çözümleri OMS entegre şekilde yönetimin içerisine dahil edilebilir.

Görüldüğü gibi OMS ile temel olarak hedeflenen var olan Azure veya yerel veri merkezi çözümlerinin Hibrit bulut mimarisi desteği ile merkezi olarak yönetilebilmesi. Ayrıca var olan servislerin dışında log analitik gibi ek servisler de OMS ile birlikte hizmete sunulmaktadır.

Genel olarak suite içerisinde var olan bileşenleri hızlıca inceledik. Simdi birazcık OMS mimarisinin nasıl çalıştığına bakalım.

Öncelikle, OMS’ in tamamı ile public cloud üzerinde çalışan bir servis olduğunu belirtelim. Her ne kadar Hibrit cloud destekli ve yerel veri merkezinizdeki istemcileri yönetse de OMS’in kendisi bir bulut hizmetidir. Bu sebeple OMS implementasyonu için herhangi bir altyapı yatırımı yapmanıza, fiziksel donanım maliyeti karşılamanıza gerek yoktur.

Tabii tamamen public cloud tabanlı bir ara yüze sahip olduğu ve organizasyon için kritik sayılabilecek veri tipleri üzerinde işlem gerçekleştirdiği için güvenlik ve bu güvenliği sağlayan bileşenler önem kazanıyor. Öncelikle OMS’in çalışma mimarisini ardından da verilerimizin nasıl güvenli şekilde saklandığını inceliyor olalım.

OMS, uç noktalardaki istemci ve sunuculardan verileri toplayabilmek için ajan ihtiyacı duyar. Microsoft Monitoring Agent ismi verilen bu ajan sayesinde uç noktalar verileri hem SCOM hem de OMS’e gönderebilir. Ajan dağıtımında istenirse ajanların yerel yapınızda bulunan SCOM’a raporlaması sağlanabilir. Ardından SCOM ile OMS arasında güvenli bir kanal kurularak veriler bu güvenli kanal üzerinden OMS’e analiz için gönderilebilir. Bunun dışında istenirse ajanların direkt olarak OMS’e raporlanması da sağlanabilir.

Bir ajan OMS hizmeti ile iletişime geçtiğinde aslında arka planda özel bir anahtar kayıt edilir ve tüm bağlantı 443 nolu port üzerinden gerçekleşir. Ayni mimari SCOM ve OMS iletişiminde de geçerlidir. OMS, verileri SCOM yada istemcinin kendisinden toplarken öncelikle veri gönderen kaynağın gerçekten güvenilir kaynak olup olmadığını kontrol eder. Bu kontrol işlemi sertifika tabanlıdır. Sertifika tabanlı eşleştirme sağlandıktan sonra ayni zamanda data integrity kontrol edilir. Böylece farklı kaynaklar üzerinden iletişimin bölünmesi ve güvensiz verinin gönderilmeye çalışılmasının önüne geçilir.

Toplanan veriler OMS içerisinde Azure blob storage üzerinde saklanır. Azure blob storage bilindiği gibi kullanıcı bazlıdır ve yalnızca o kullanıcının erişebilmesi için gerekli anahtarlar sağlanır. Her OMS kendi için oluşturulan blob alanına erişebilmesi için gerekli anahtara sahiptir. Ayni zamanda bu anahtar da her 90 günde bir değiştirilmektedir.

Bir sonraki bölümde ilk OMS alanımızı (workspace) açıp gerekli yapılandırmaları gerçekleştireceğiz.

Operations Management Suite Part 1 – Hibrit Bulut Nedir

Bu makale serisinde Microsoft’un yeni bulut tabanlı yönetim platformu olan Operations Management Suite’i inceleyeceğiz. OMS aslında Microsoft’un son yıllarda öne çıkardığı Hibrit bulut yaklaşımının en önemli bileşenlerinden birisi olmaya aday.

Ancak Operations Management Suite detaylarına girmeden önce ilk bölümümüzde Vendor bağımsız Hibrit bulutun ne olduğunu, altyapı ve uygulama geliştirme süreçlerine katkısı, getirdiği artıları ve ayni zamanda ortaya çıkardığı problemleri inceleyelim. Ardından OMS’in bu mimari içerisinde nerede durduğuna daha yakından bakıyor olacağız.

Sanırım sanallaştırma furyasından beri sektör bu denli yoğun bir dönüşüme maruz kalmamıştı. Bulut bilişim hayatımıza girdiğinden beri gerek işletmeler, gerek bilişim teknolojileri yöneticileri gerekse teknoloji üreticileri bu dönüşüme ayak uydurmaya, müşteri ihtiyaçlarına en uygun çözümleri sunmaya çalışıyor. Burada bahsettiğimiz müşteri kavramı herkes için geçerli. Bir banka için müşterileri banka hizmetlerini alan kişi ve kurumlar olabilirken teknoloji üreticileri için müşteri bankanın kendisi olabiliyor. Ayni şekilde müşterileri kendi iç departmanları olan tonlarca işletme de bulunuyor. Bu senaryoların hepsinde temel amaç değişen ve gelişen is ihtiyaçlarına teknolojik açıdan hızlı ve esnek çözümler üretebilmek, artan rekabetçi ortamda geride kalmamak ve hizmetleri geleneksel yöntemler yerine yenilikçi yöntemler ile daha hızlı, güvenli ve esnek şekilde sunabilmek. Bunun yanında benim bugüne kadar edindiğim gözlemlere göre bilişim yöneticilerinin bir diğer hedefi de farklı is kaynaklarının tamamı için öngörülebilirlik (predictability) ve tutarlılık (consistency) in öncelikli hale getirilmesi.

Aslında bulut teknolojileri bu hedeflerin gerçekleştirilmesinde en önemli araçlardan birisi oldu. Belki de bulut teknolojisi sayesinde organizasyonlar ve yöneticiler kendilerine bu denli zorlayıcı hedefleri rahatlıkla koyabilmeye başladılar. Su an dünya üzerindeki rekabetçi piyasalara bakıldığında işletmelerin bulut bilişimin faydalarını özümsediklerini ve bunun geleceğin platformu olduğunu anladıklarını görebiliyoruz. Birkaç yıl öncesine kadar şirketler geleneksel bir veri merkezinde is yüklerini barındırmaya devam etmek yada Public/Private Cloud mimarilerine geçmek arasında kalırken artık bu aşamanın geçildiğini ve farklı bulut teknolojilerinin harmanlanıp en uygun custom modellerin uygulanmaya çalışıldığını görebiliriz.

İşte bu noktada Hibrit bulut mimarisi bir çözüm olarak karşımıza çıkıyor.

Hibrit bulut mimarisi aslında geleneksel veri merkezi ve bilişim süreçlerini yukarıda bahsettiğimiz bulut bilişimin farklı yaklaşımları ile harmanlayarak en uygun çözümün ortaya çıkarılmasıdır. Peki, Hibrit bulut mimarisinde bulut bilişimin hangi farklı yaklaşımlarını kullanabiliriz? Bu noktada birçoğunuzun hakim olduğu aşağıdaki yaklaşım/türler kullanılıyor.

  • Private Cloud
  • Public Cloud
  • Managed Cloud

Bu üç turun detaylarına girmeyeceğim. Eminim farklarını ve detaylarını inceleyen birçok yazı okumuş, sunum incelemişsinizdir. Benim asil bahsetmek istediğim ise bu farklı bulut türlerinin, geleneksel bilişim teknolojileri ile nasıl harmanlanabileceği.

Bana göre bu harmanlamadan organizasyonunuz için başarılı sonuç çıkarabilmenizin en önemli kriteri günün sonunda yönetilen veya servis edilen tüm hizmetlerin sanki tek bir altyapı için tasarlanmış gibi davranabilmesidir. Eğer Hibrit bulut mimarisi ile birlikte uygulama geliştirme yada altyapı süreçlerinizde farklı ortamlar ve entegrasyon noktasında öngörülemeyen problemler nedeni ile ulaşılmak istenen sonucu elde edemiyorsanız Hibrit bulut mimarisi sizin için uygun olmayabilir yada Hibrit bulut mimarisi sizin için düzgün konumlandırılmamış olabilir.

Yukarıdaki sorun aslında Hibrit bulut mimarilerinde sıklıkla karşılaşılan problemlerin başında geliyor. Henüz uygulamaların gerçekten Hibrit bulut için uygun olup olmadığına dair bir assessment gerçekleştirilmeden, yüzlerce uygulama içerisinde hiçbir native cloud uygulamaya sahip olmadan ve entegrasyon noktasında yeterli planlama yapılmadığı için sonuç hüsran olabiliyor.

Hibrit bulut mimarisinde hem kendi veri merkezinizdeki kaynakları hem de farklı veri merkezlerindeki kaynakları es zamanlı olarak kullanabilmeniz ve uygulamalarınız da bu yapıya adapte olup sanki homojen bir ortamda çalışıyormuş gibi performans, geliştirme, test ve benzeri süreçlerde “en azından” eskisi kadar sorunsuz hizmet vermeye devam ediyor olmaları gerekiyor.

Tabii ki bu “en azından” isimli sureci tamamlayıp Hibrit bulut mimarisinden daha fazla faydalanma aşamasına da geçilmesi gerekiyor. Yine uygulama bazlı bakacak olursak uygulamalarınızın gerekli esnekliğe sahip olabilmesi ve uygulama kodunun bir ortamdan diğerine rahatlıkla taşınabilmesi gerekmektedir. Böylece örneğin bir public cloud servisinde PAAS kullanılarak uygulama geliştiricileriniz, kendileri için gerekli altyapıyı saniyeler içerisinde ayağa kaldırabilir, uygulamaları çok hızlı şekilde üretim ortamında kullanılacak duruma getirebilirler. Ancak günün sonunda bu uygulamanın sizin geleneksel veri merkeziniz içerisinde çalışması ve iç kullanıcılara hizmet verebilmesi gerekmektedir. Bu sebepten de test süreçlerini tamamlayan uygulama geliştiricilerin ayni kodu rahatlıkla private cloud yada geleneksek veri merkezine taşıyabilmeleri zorunluluğu doğuyor. Eğer bu işlem için yazılımcıların uygulama kodunun mimarisini tekrardan değiştirmeleri gerekiyor ise ne yazık ki bu göze alınmayacak bir efor olacaktır. Bulut mimarisinin getirdiği hız ve esneklik uygulama üretim ortamına taşınamadan kaybedilecektir.

Aslında bu esnekliği ve farklı mimariler arasında taşınma işlemini container teknolojileri ile rahatlıkla gerçekleştirebilirsiniz. Bu yüzden container teknolojisi özellikle Hibrit bulut mimarileri için halen yükselen eğilim olmaya devam ediyor.

Hibrit bulut ile ilgili ayrı bir makale serisi yazılabilir. Güvenlik, esneklik, gözlemlenebilme, DevOps, Automation vb farklı süreçlerin doğru şekilde uygulanması ve sonuç alınması gerekiyor.

Operations Management Suite ise Microsoft’un Hibrit bulut mimarisinin temel bileşenlerinden birisi olarak öne çıkıyor. Var olan System Center yatırımlarınızı public cloud servisleri ile entegre ederek tam bir Hibrit bulut yönetim çözümü sunuyor.

Bir sonraki yazımızda Operations Management Suite detaylarına giriyor olacağız.

 

Azure Disk Encryption – Workflow

Daha onceki yazimda bahsettigim gibi Azure uzerindeki Linux ve Windows sanal makineler icin Bitlocker ve Kye Vault ile birlikte disk sifreleme destegi gelmisti. Bu yazida genel olarak sifreleme surecinin uzerinden gecmek istiyorum.

Capture

  • Onceki yazimizda bahsettigimiz gibi oncelikle kullanici asagidaki 3 farkli sifreleme senaryosundan hangisini gerceklestirecegini secmelidir.
    • Azure uzerinde hali hazirda calisan sanal makineler icin sifreleme
    • Azure Gallery uzerinden olusturulan sanal makineler icin sifreleme
    • Kullanicilar tarafindan sifrelenmis VHDler ile olusturulmus sanal makinelerde sifreleme
  • Kullanici sifrelemeyi gerceklestirmek icin bir yontem seciyor. Bu yontem Azure Resource Manager Template, PowerShell komutlari yada Azure CLI komutlarindan birisi olabilir.
  • Eger kullanici tarafindan sifrelenmis bir VHD kullanilacak ise, ilk once bu VHD Azure uzerindeki storage hesabina upload edilir. AYni sekilde sifreleme anahtarlari Azure Key Vault’a gonderilir.
  • Azure Gallery uzerinde olusturulmus yada hali hazirda Azure uzerinde calistirilan sunucular icin ise musteriler sifreleme yapilandirmalarini gerceklestirirler.
  • Azure platformuna Vault icerisindeki anahtarlarin okunabilmesi icin yetki atanir.
  • Azure Service Management, VM Service modilini sifreleme ile birlikte gunceller.

Unutulmamasi gereken nokta su an icin yalnizca asagidaki isletim sistemleri icin destek bulunuyor:

  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2

Azure Disk Encryption – Linux / Windows

Kisa bir sure once Microsoft Azure altyapisinda calistirilan sanal makinelerde disk sifreleme isleminin detaylarini inceleyen bir whitepaper yayimladi. Whitepaper’a asagidaki linkten ulasabilirsiniz.

https://gallery.technet.microsoft.com/Azure-Disk-Encryption-for-a0018eb0

Kisa bir ozet gecmek gerekirse, bilindigi gibi uzun yillardir Microsoft kendi veri merkezimizde bulunan istemci ve sunucular icin bitlocker ile fiziksel guvenligi sagliyordu. Bunun icin farkli yapilandirma yontemleri bulunuyordu. TPM, USB, Group Policy vb yontemler ile disk uzerindeki verilerin herhangi bir fiziksel calinma durumunda okunamaz duruma gelmelerini saglayabiliyorduk.

Microsoft benzer yapilandirmayi artik Microsoft Azure uzerinde de sagliyor. Ayni sekilde temelde Bitlocker teknolojisini kullanan bu yapilandirma hem Windows hem de Linux sanal makineler icin kullanilabilir durumda. Bitlocker ile birlikte arka tarafta aslinda sureci yoneten bilesen ise Azure Key Vault.

Azure Key Vault aslinda size bulut mimarisini uzerinde kullanmis oldugunuz anahtarlari sifreleme sansi veriyor. Bu anahtarlara birkac ornek: authentication, storage account, sertifikalar yada standart sifreler verilebilir. BU sayede yazilim gelistiriciler cok hizli bir sekilde istenilen anahtarlari olusturabilir, sifreleyebilir ve istedikleri testleri gerceklestirebilirler. Uygulamalar icin olusturulan bu guvenlik anahtalari uygulama disinda ayri bir vault icerisinde saklanir ve URI ile tetiklenebilir. Ayri bir vault icerisinde tutulan bu anahtarlar ise varsayilanda uygulama ile ayni Azure veri merkezinde saklanir ve verimlilik/performans artisi saglanir.

Arka tarafta Azure Key Vault destegi ile birlikte artik Azure izerinde bulunan sanal makinelerinizi, galeri icerisinden olsuturdugunuz sanal makineleri ve hali hazirda calistirdiginiz sanal makineleri sifreleyebilirsiniz. SU anki Public Preview surumu ile birlikte:

  • Azure Key Vault destegi yukarida bahsettigimiz gibi bulunuyor
  • A,D ve G serisi sanal makine destegi bulunuyor
  • Azure Resource Manager ile sifreleme tetikleneniliyor
  • Bu surum ile birlikte ozellikle tum Azure bolgerinde kullanilabilir durumda

Ozellikle Azire Resource Manager destegi oldukca onemli. Bu sayede PowerShell yada Azure CLI kullanarak sifreleme gorevlerini gerceklestirebilirsiniz.

Azure Premium Storage

Azure gun geçtikçe daha yeni ozelliklerle karsimiza cikiyor ve bu sayede daha fazla organizasyon kritik kaynaklarini buluta taşıyabiliyor.

Uzun zamandir beklediğim ozelliklerden birisi de artik Azure üzerinde kullanılabilir. Premium Storage.

Bilindigi gibi daha önceden Azure üzerinde sanal makinelerimiz için kullandigimiz disklerde cok fazla yapilandirma gerçekleştiremiyorduk. Ancak gerçek dünyada bulunan uygulamalarimizin cok spesifik kaynak kullanim ihtiyaclari olabiliyor. Eger daha hizli veri transferi gereksinimi duyan uygulamalari buluta tasimayi dusunuyorsaniz artik Premium Storage içerisinde gelen Shared SSD diskleri kullanabilme sansiniz var. Premium Storage su an için yalnızca DS ve GS serisi sanal makineler içerisinde kullanılabilir.

Premium Storage ile ilgili önemli noktalar:

  • Premium Storage kullanmak için bir Premium Storage hesabi olusturmaniz gerekiyor.
  • Premium Storage Azure Portal disinda PowerShell ve SDK ile ulaşılabilir durumda.
  • Su an için yalnızca page blobs desteği bulunuyor. Page blob bildiğiniz gibi sanal makinelerin disklerinin barindirildigi storage hizmeti
  • Otomatik olarak Premium Storage LRS ile 3 kopya tutacaktır.
  • Yalnizca DS ve GS serilerinde kullanılabilir.
  • Isterseniz bu seri sunucularda normal diskleri de kullanabilirsiniz.
  • Premium Storage hesabi farkli bir custom domain name üzerinde maplenemez.
  • Storage Analytics su an için desteklenmiyor.

Kullanim öncesi asagidaki Scability ve Performance detaylarini goz onunde bulundurmaniz önemli.

5 6

EMS ile kolay Microsoft Destegi!

Microsoft cozumlerini kullanan organizasyonlarin onemli bir kismi daha once Microsoft Support ile iletisime gecmistir. Herhangi bir sorun aninda partner eger sorunu cozemiyor ise eskale edilebilecek son adim Microsoft Support oluyor.

On-premise yapilarda Microsoft Support muhendisinin gerceklesen sorun ile ilgili cozum uretebilmesi icin oncelikle var olan altyapinin detaylarini bilmesi ardindan sorun ile ilgili kapsamli bir log/trace dosyasini incelemesi gerekmektedir.

Ancak yavas yavas bulut hizmetlerini kullanmaya basliyoruz ve teknolojiyi hizmet olarak almaya basladigimiz icin bunun nimetlerinden faydalanmak da hakkimiz.

Yeni nesil Hibrit tabanli yonetim cozumu olan Microsoft Operations Management Suite ile Microsoft destegi almak oldukca kolay.

Oncelikle hizmet zaten tamami ile bir Microsoft hizmeti oldugu icin bircok on gereksinimden yada sorun cikarabilecek sizin veri merkezinizdeki bilesenlerden muaf durumda. Bu yuzden geleneksek on-premise cozumlere kiyasla cok daha az sorun cikaracagi asikar. Ancak herhangi bir sorun aninda da sizin mudahele sansiniz cok fazla bulunmuyor. Bu durumda Microsoft destek muhendisinin OMS icerisindeki veriyi ve hatayi gormesi gerekli.

OMS ekibi bu konuda cok efektif bir ozellik sundu. Artik OMS icerisindeki hesaplar bolumune Microsoft destek personelinin mail adresini ekleyebilir ve bu kisiye read-only OMS verisine erisim yetkisi verebilirsiniz. Bu sayede sorun cozumlenene kadar Microsoft personeli rahatlikla sorunu goruntuleyebilir ve aksiyon alabilir.

Bunun icin yapilmasi gereken asagidaki ekrani kullanarak ilgili mail adresinin eklenmesidir.

SupportWithOMS1.png-550x0

Azure Network Limits

Azure uzerinde network bilesenlerini yapilandirirken asagidaki limitlere dikkat edilmesi onemlidir.

Resource Default limit Maximum limit
Virtual networks per subscription 50 100
Local network sites per virtual network 20 contact support
DNS Servers per virtual network 20 100
Virtual machines and role instances per virtual network 2048 2048
Concurrent TCP connections for a virtual machine or role instance 500K 500K
Network Security Groups (NSG) 100 200
NSG rules per NSG 200 400
User defined route tables 100 200
User defined routes per route table 100 500
Public IP addresses (dynamic) 5 contact support
Reserved public IP addresses 20 contact support
Public VIP per deployment 5 contact support
Private VIP (ILB) per deployment 1 1
Endpoint Access Control Lists (ACLs) 50 50

Azure VNet Nedir?

Nasil ki yerel veri merkezimizde sunucular uzerinde hizmet verebilmek icin bir network agina, bilesenlerine, guvenlik ilkelerine, sanal aglara ihtiyacimiz var ise, bulut hizmetlerinde de benzer bir network altyapisina ihtiyac duyariz. Belirli sunucularin yada sunucu gruplarinin birbirleri ile yada dis dunya ile iletisime gecebilmeleri icin en azindan bulut uzerinde bir IP adresine sahip olmalari, bir network agina dahil olmalari ve bilindik protokolleri kullanmalari gerekmektedir.

Eger Azure uzerinde var olan sunucularimizin network uzerinden haberlesmesini istiyorsak bu konuda VNet kavrami ile tanismamiz gerekiyor. VNetler sizin bulut uzerindeki networkunuzun bir yansimasidir.

Aynen gercek bir networkte oldugu gibi VNet uzerinde de IP adres bloklarina sahip olabilirsiniz, isterseniz guvenlik kurallari uygulayabilirsiniz, isim cozumleme icin DNS sunuculari yapilandirabilirsiniz hatta ve hatta routing table kayitlari giyebilirsiniz.

En buyuk fark ise siz tum bu yapilandirmalari aslinda Software Defined Networking uzerinde gerceklestirmenizdir. Yani gerceklestirdiginiz bu ayarlar Microsoft veri merkezlerindeki fiziksel network cihazlarina aninda islenmiyor. Siz Microsoft tarafindan belirlenmis kurallar cevresinde, yine Microsoft’un dizayn ettigi sanal bir network uzerinde bu yapilandirmalari gerceklestiriyorsunuz. Eger Microsoft bu sekilde bir Software Defined yaklasimi kullanmiyor olsaydi, milyonlarca farkli network, IP adresi ve yapilandirmayi yonetebilme sansi imkansiz olurdu.

Asagidaki cizimde VNetin ne olduguna dair daha fazla fikir edinebilirsiniz.

Azure virtual network

Goruldugu gibi Azure altyapisi geneneksel bir network altyapisinda bulunan network cihazlarinin yerini almis ve erisim imkani vermistir. Vnet icerisindeki onemli bilesenleri hizlica inceleyelim:

Subnet: Subnet bildiginiz gibi belirli IP adreslerini iceren bir araliktir. VNet icerisinde de farkli IP bloklari icin subnetler olusturabilirsiniz. Geleneksel veri merkezinde oldugu gibi ayni subnet icerisindeki hizmetler birbirleri ile haberlesebilirler. Ayni zamanda cross subnet erisimleri de yapilandirma sansiniz bulunuyor.

IP Adresi: Azure icerisinde kullanabileceginiz iki IP adresi tipi bulunuyor. Public yada Private. Adindan da anlasilabilecegi uzere Public IP adresleri genelde dis dunya ile iletisime gecmesi gereken servisler icin kullanilir. Private IP adresleri ise bir VNet icerisindeki kaynaklarin birbirleri ile iletisime gecmeleri icin yapilandirilir.

Azure Load Balancer: Azure uzerinde bir uygulama yada sanal makine dis yada ic dunyaya hizmet verirken Azure tarafindan saglanan yazilimsal bir Load Balancer arkasinda konumlandirilabilir. Bu sayede bu kaynaklar uzerine gelen talepler Azure LB ile dengelendikten sonra arka tarafta bulunan sunucu yada uygulamalara dagitilirlar.

Network Security Group: NGS sayesinde belirli VM yada subnetlere erisimde iletilen trafige izin verebilir yada yasaklayabilirsiniz. Bu yasaklama kaynak yada hedef IP adresine gore yapilandirilabilecegi gibi port numarasina gore de ayarlanabilir.

 

 

 

Azure File Storage

Gectigimiz gunlerde sonunda Azure File Storage genel kullanima sunuldu. Azure File Storage sayesinde artik bulut üzerinde tam anlamiyla dosya paylasimini kullanmaya başlayabiliriz.

Azure File Storage arka planda SMB 3.0 protokolunu kullanarak uygulamalar için dosya paylasimi ile dosyalara erişimi mumkun kilar.

Ayni zamanda desteklediği REST API sayesinde modern uygulama geliştirme süreçlerinde de erişim desteği sunar.

Uzun zamandir beta surumunu test ediyorduk ancak GA surumu ile birlikte asagidaki ozellikler de eklenmiş durumda:

  • SMB 3.0 destegi
  • Encryption desteği
  • Browser tabanli dosya yöneticisi
  • Azure Storage Metrics destegi
  • Azure File Storage üzerinde bulunan dosya paylasimlarini on-premise mount edebilme
  • Gelistirilmis API destegi

Peki Azure File Storage ile ne tarz senaryolari hayata geçirebiliriz.

Bana gore en önemlisi artik kolaylıkla on-premise bulunan verilerimizi bulut ile paylaşabiliriz. Ornegin log dosyalari yada yedekler cok daha efektif barindirma imkani sunan Azure üzerinde kolaylıkla tutulabilir.

REST API destegi ve SMB 3.0 protokolu ile birlikte artik standard uygulamalar ile modern uygulamalari kolaylıkla entegre edebiliriz.

Bana gore bu destek cok fazla senaryoyu da beraberinde getirecek.

Istemci tarafında kullanilan SMB sürümlerini asagidaki tablodan kontrol etmeyi unutmayin.

4