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 Stack POC – Donanim Gereksinimleri

Gectigimiz gunlerde Microsoft tarafindan Azure Stack Technical Previwe icin donanim gereksinimleri sunuldu.

Bildiginiz gibi Azure Stack, Microsoft’un hibrit bulut vizyonunda onemli bir yer tutuyor. Windows Azure Pack ile birlikte public Azure’un en azindan portal bilesenini kendi veri merkezlerimizde kullanmaya baslamistik. Ancak konu yazilim gelistirme sureclerine, uygulamalarin yerel ve public Azure uzerinde mimari degisliklige ugramadan calisabilmesi gibi noktalara geldiginde gercek bir hibrit bulut mimarisinden bahsedemiyorduk. Portal bize yalnizca Windows Azure on yuzunu kullanmamiza izin veriyordu.

Azure Stack ise bu noktada bir adim one gidiyor. Microsoft’un yillardir Azure ile edindigi tecrubeler tamamiyle ayni mimari, API ve kod ile birlikte yerel veri merkezi icin kullanima sunuluyor. Bu bircok senaryoyu da beraberinde getiriyor olacak.

Henuz elimizde test yapabilecegimiz bir surum olmadigi icin bilgiler kisitli. Ancak kisa zaman once Microsoft, TP surumu icin donanim gereksinimlerini bizlerle paylasti. Detaylar asagida:

http://blogs.technet.com/b/server-cloud/archive/2015/12/21/microsoft-azure-stack-hardware-requirements.aspx

Component

Minimum

Recommended

Compute: CPU Dual-Socket: 12 Physical Cores Dual-Socket: 16 Physical Cores
Compute: Memory 96 GB RAM 128 GB RAM
Compute: BIOS Hyper-V Enabled (with SLAT support) Hyper-V Enabled (with SLAT support)
Network: NIC Windows Server 2012 R2 Certification required for NIC; no specialized features required Windows Server 2012 R2 Certification required for NIC; no specialized features required
Disk drives: Operating System 1 OS disk with minimum of 200 GB available for system partition (SSD or HDD) 1 OS disk with minimum of 200 GB available for system partition (SSD or HDD)
Disk drives: General Azure Stack POC Data 4 disks. Each disk provides a minimum of 140 GB of capacity (SSD or HDD). 4 disks. Each disk provides a minimum of 250 GB of capacity.
HW logo certification Certified for Windows Server 2012 R2

Storage considerations

Data disk drive configuration: All data drives must be of the same type (SAS or SATA) and capacity.  If SAS disk drives are used, the disk drives must be attached via a single path (no MPIO, multi-path support is provided)
HBA configuration options:
     1. (Preferred) Simple HBA
2. RAID HBA – Adapter must be configured in “pass through” mode
3. RAID HBA – Disks should be configured as Single-Disk, RAID-0
Supported bus and media type combinations

  •          SATA HDD
  •          SAS HDD
  •          RAID HDD
  •          RAID SSD (If the media type is unspecified/unknown*)
  •          SATA SSD + SATA HDD**
  •          SAS SSD + SAS HDD**

* RAID controllers without pass-through capability can’t recognize the media type. Such controllers will mark both HDD and SSD as Unspecified. In that case, the SSD will be used as persistent storage instead of caching devices. Therefore, you can deploy the Microsoft Azure Stack POC on those SSDs.

** For tiered storage, you must have at least 3 HDDs.

Example HBAs: LSI 9207-8i, LSI-9300-8i, or LSI-9265-8i in pass-through mode

 

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 RBAC – GA – Kullanilabilir Durumda

RBAC (Role Based Access Control) yani rol tabanli erisim denetimi bilindigi gibi Microsoft’un son donemde cikardigi neredeyse tum hizmet ve cozumlerde destekleniyordu. Bu sayede rahatlikla kullanici bazli yetkilendirmeler tek bir konsol uzerinden hizlica gerceklestirilebiliyordu.

Birkac gun once duyurulan bir guncelleme ile artik Azure icin de RBAC destegi genel kullanima sunuldu.

Ozellikle Azure gibi icerisinde tonlarca servisin bulundugu ve cok fazla kullanici/yoneticinin erisiminin gerektigi yapilar icin RBAC hayatimizi onemli olcude kolaylastiracak gibi duruyor.

RBAC oncesinde yetkilendirme icin en cok kullanilan yontemlerden birisi Azure Active Directory idi. Var olan local Active Directory yapinizi Azure uzerine extend ederek single sign-on senaryolarini aktif edebilirdiniz. Ayni zamanda yerel AD uzerindeki kullanicilariniz otomatik olarak Azure hizmetleri icin kullanilabilir durumda oluyordu.

Azure RBAC ile birlikte ayni zamanda self-service yonetimini de aktif edebileceksiniz.