How to install AzureStack on Windows 10 Client – Tips and Tricks

I had a long Saturday this weekend. If you are not living in a cave you probably heard about Microsoft’s new Hybrid cloud approach AzureStack.

I’m not going to discuss the architecture or the benefits that AzureStack brings because there are bunch of good resources available:

https://azure.microsoft.com/en-us/documentation/articles/azure-stack-architecture/

http://blogs.technet.com/b/server-cloud/archive/2015/05/04/announcing-microsoft-azure-stack.aspx?linkId=13950132

https://www.petri.com/microsoft-azure-stack

Last week Microsoft announced that AzureStack first technical preview (TP1) will be available on 29th of Jan.

Also couple of weeks ago, hardware requirements are announced to deploy TP1. TP1 just focuses for POC deployments and available to install all components on a single server if you meet below requirements:

https://azure.microsoft.com/en-us/documentation/articles/azure-stack-deploy/

I’m sure most of you were expecting to install AzureStack on your laptop or home desktop PC to test basic functionalities but if you look at the requirements, that’s a bit challenging for a giant like Azure Stack.

Here are the couple req:

  • Windows Server 2016 Datacenter (TP4)

That one easy and can be installed on your lab server/desktop easily.

  • One available port on a switch for the POC machine

Shouldn’t be a problem

  • Microsoft Active Directory accounts

To deploy Azure Stack POC, you must have a valid Microsoft Azure AD account that is the directory administrator for at least one Azure Active Directory.

You can use your existing Azure subscription or create one for free.

  • Memory – 96 GB RAM

To be honest I don’t have a home lab that meets that requirement so we need to find a way for that one. Because deployment script will create bunch of virtual machines probably require around 96GM of RAM.

  • Hyper-V Enabled

If you were planning to use a virtual machine to test AzureStack, that’s another challenge as well because POC machine should have Hyper-V role installed.

  • Data Disks

Minimum configuration requires 4 disks; each disk provides a minimum of 140 GB of capacity. Also these disks should be visible in disk management as online – RAW – not in use

So like me, if you were planning to use your home lab to test AzureStack, there are couple of challenges we need to deal with.

Actually I was planning to use my home Windows 10 desktop machine which has following configurations:

  • 32 GB RAM
  • I7-6700K CPU
  • SSD System Drive
  • 1TB HDD

I know it’s not a good idea to use this system to run a giant like AzureStack but that was all I had this weekend J

So first thing first, we need to deal with Hyper-V requirement. You can always install Windows Server 2016 Datacenter edition on a dedicated partition and boot but also you can use Windows 10 latest insider version to have nested Hyper-Vs.

Currently I’m running:

So I simply enabled Hyper-V on it and then followed below instructions/scripts to install a nested Windows Server 2016 TP4 Hyper-V server as a virtual machine.

http://blogs.technet.com/b/virtualization/archive/2015/10/13/windows-insider-preview-nested-virtualization.aspx

Enable-NestedVM.ps1 script does all required checks for you and at the end of the steps you will have a fully working Nested 2016TP4 Hyper-V server.

So our Hyper-V server is ready – I hope.

Next thing we need to find a way to deal with hardware requirements.

For the data disk requirements, I simply created 4 VHD on my physical Windows 10 HDD with required sizes:

$i = 1..4
foreach ($a in $i)
{
New-VHD -Path G:\DATA_DISKS\VHD0$a.vhdx -Fixed -SizeBytes 140GB
}

Then simply added these disks to my nested Hyper-V server.

If you follow official AzureStack deployment guide, you will realize that we are booting nested Hyper-V server with WindowsServer2016Datacenter.vhdx disk using following command:

bcdboot <mounted drive letter>:\windows

and then we need to run

.\DeployAzureStack.ps1 –verbose

command to start the deployment. Before changing anything I just wanted to see what this command is actually doing so just run it once and realized all prerequisites are checked before deployment.

We don’t have a problem with data disks but I got error messages for the RAM as I only have 32 GB of RAM and set my nested Hyper-V to use around 24 GB out of it.

So I just opened DeployAzureStack.ps1 script to see what’s going on. First thing I realized that script is mounting $PoCVHD
=
‘MicrosoftAzureStackPOC.vhdx’
using below command.

So you have two options:

You can fire the deploy script and wait for vhdx to be mounted and then find the requirement definitions and change it. I tried this method but faced another problem.

As you may see on the above script, VHD is mounted as read-only which makes impossible to change any content in VHD.

I actually found the precheck script to change the required RAM settings but once I tried to save it gave below error:

So you can simply edit the first script and remove (-access ReadOnly) parameter. That will mount the disk in a normal state and you can hijack any file you found.

But I believe second option is much easier. Before running DeployAzureStack script you can simply mount the disk (MicrosoftAzureStackPOC.vhdx) manually, edit the files you need and then eject it. Then you can simply start the deployment with an updated VHDX.

Here is the file I found when I mounted VHDX.

That script includes all functions which actually checks your infrastructure. I changed CheckRAM function to lower the memory requirements for my host machine:

And then I started the deployment and forgot an important thing…

Yes my host now meets requirements for the installation but once the installation starts, it will create 10 different virtual machines with different Vcpu and memory settings. And first 3 or 4 VMs already filled my memory. You can try the ugly way and change the VM settings after the deployment of each machine. But probably you need to spend couple of hours to check each and every VM and that could also break the installation.

So we also need to find VM memory and CPU definition files.

That file is POCFabricSettings.XML

You can simply edit processor count and RAM settings according to your current infrastructure:

I simple used “1” for Processor count and “2” for the RAM. These are quite low settings to run these machines but helps you to finish installation without any problem.

You need to save changes and then eject VHD before starting deployment.

And you are ready to go!

I had two issues during the deployment.

One is the JavaScript to connect Azure subscription during the installation;

Turning of IE enhanced mode on Nested 2016TP4 resolved the problem.

Second issue is whole installation took around 9 hours to complete. I know this is not a recommended way of installing AzureStack and probably I may face serious performance issues but will help you to test some basic functionalities before you find a real gear.

Hope that helps you.

Read More

Operations Management Suite Part 8 – Alert Management

 

Bu yazımızda OMS Solution Gallery üzerinde bulunan Alert Management çözümünü inceleyeceğiz.

Solution Gallery içerisinde farklı hizmetler için ek çözümleri OMS’e ekleme sansınız bulunuyor. Bu çözümlerden birisi olan Alert Management özellikle SCOM altyapısı olan ve OMS’i SCOM ile entegre şekilde kullanmak isteyenler için önemli bir eklenti.

Bu eklenti aktif edildiğinde SCOM tarafından oluşturulan alertler OMS workspace içerisinde rahatlıkla görüntülenebilir ve filtrelenebilir. Ayni zamanda birden fazla Management Group bulunan SCOM altyapılarında OMS Alert Management tek bir merkezi alert çözümü olarak kullanılabilir.

Alert Management ‘in aktif edilmesi için Solution Gallery içerisine girilerek Alert Management – Add tıklanması yeterlidir.

Alert Management ile verileri toplayabilmek için SCOM Management sunucularınızı OMS ile entegre etmeniz gerekmektedir. Önceki makale bölümlerimizde bu entegrasyonu başarılı şekilde gerçekleştirmiştik.

Solution Gallery içerisinde ekleme yapıldıktan sonra ana ekranda Alert Management isimli yeni bir bölme göreceksiniz.

 

İlk yapılandırma sonrası yaklaşık bir saat içerisinde SCOM üzerinden toplanan alertler OMS konsolu içerisinde gösterilmeye başlanacaktır.

Bu entegrasyon gerçekleştirildikten sonra SCOM Management Group üzerinde oluşturulan alertler OMS’e gönderilecektir.

Yeni oluşturulan Alert Management bölümüne tıkladığınızda gönderilen alertlerin detaylarını görebilirsiniz.

OMS ekranında gösterilen alertler yalnızca son 7 günü kapsamaktadır. İsterseniz zaman aralığını daha fazla genişletebilirsiniz.

Ayni şekilde yalnızca belirli bir Management Group üzerinde oluşturulan alertleri görmek isterseniz var olan kapsamı globalden MS’e değiştirmeniz gerekmektedir.

Bu ekranda da benzer filtreleme yöntemlerini kullanarak arama işlemi gerçekleştirebilirsiniz. Daha önceki filtrelerimizde Type kullanarak yalnızca eventleri listelemiştik. Ayni şekilde aşağıdaki gibi bir filtre ile spesifik alertleri görüntüleyebilirsiniz. Bunun için Log Search ekranını kullanmanız gerekmektedir.

Kompleks sorgular için birkaç örnek:

SCOM üzerinde oluşturulan alertlerin OMS’e gönderilmesinden sorumlu bir SCOM kuralı bulunmaktadır.

Collect Alert Changes isimli bu kural ve Management Pack’i export ederek ek detaylarını görüntüleme sansınız bulunuyor.

 

Read More

Operations Management Suite Part 7 – Solution Gallery

Bu yazımızda OMS ile birlikte Dashboard ekranına tümleşik gelen Solution Gallery’i inceleyeceğiz.

OMS’in daha önceki yazılarımızda tamimiyle bir bulut hizmeti olduğundan bahsetmiştik. Her ne kadar Hibrit mimari desteği ve farklı veri merkezlerindeki uç noktaları yönetme kabiliyeti olsa da OMS’in kendisi Microsoft bulut Hizmetleri üzerinde barınmaktadır.

Yeni özellikler yada eklentiler acısından düşündüğümüzde bunun artıları tartışılamaz. Ayni Office 365’de olduğu gibi Microsoft, OMS üzerinde yeni bir güncelleme aktif ettiğinde yada bir eklentiyi yayına aldığında sizin bu konuda bir on hazinlik yada yapılandırma zorunluluğunuz bulunmuyor. Tek yapmanız gereken ertesi gün OMS konsoluna login olmak ve gerçekleştirilen güncellemeleri kullanmaya başlamak.

OMS daha önce defalarca söylediğimiz gibi direkt olarak istemcilerden yada SCOM sunucusundan verileri toplar, analiz imkânı verir ve size sunar. Ancak yapabildiklerinin siniri yalnızca bu değildir. Log Search OMS ile birlikte sunulan bileşenlerden yalnızca birisidir.

Solution Gallery içerisinde OMS ile entegre şekilde kullanabileceğiniz farklı çözümleri bulabilirsiniz. Bunları bir nevi Management Pack olarak düşünebilirsiniz. Su an için yalnızca Microsoft tarafından sunulan bu ek bileneler/çözümler ileride 3. Parti üreticiler tarafından da sunulmaya başlanacak.

OMS konsolunuzda Solution Gallery’e geldiğinizde su an için sunulan oldukça başarılı bazı çözümler göreceksiniz. Bunlardan birkaçı:

AD Assessment: Var olan Active Directory ortamınızın risk ve sağlık durumunu inceleyen ve bununla ilgili size öneriler ve raporlar sunan bir servis.

Malware Assessment: OMS ile birlikte yönettiğiniz sunucuların malware risk detaylarını size sunan çözüm.

Alert Management: Var olan SCOM yapınızdaki alert leri yönetmenizi sağlayan çözüm.

Automation: Azure Automation ile birlikte sunulan Hibrit Runbook Workerlarin analiz edilmesini sağlar. Böylece kendi veri merkezinizde yada Azure üzerinde çalışan runbooklarda oluşan herhangi bir soruna hızlıca müdahale edebilirsiniz.

Change Tracking: OMS ile yönettiğiniz sunucular üzerindeki Change Tracking’in aktif edilmesini sağlar. Bu sayede bu sunucular üzerinde herhangi bir uygulama yada serviste değişiklik olduğunda bunu OMS konsolu üzerinden takip edebilirsiniz.

Security Audit: Bu çözüm ise sunuculardan toplanan audit verileri üzerinde forensic analiz gerçekleştirmenizi sağlar. Unified bir dashboard üzerinden tüm aktiviteleri, ortamınızda gerçeklesen problemleri görüntüleme şansı verir.

Azure Site Recovery: ASR ile entegre olan bu çözüm sayesinde ASR üzerindeki DR planlarınızı, görevlerinizi ve görev sonuçlarınızı gözlemleyebilirsiniz.

Yukarıda yalnızca birkaç çözüm ile ilgili hızlıca bilgi verdik. OMS konsoluna girerseniz ek sunulan çözümleri ve detaylarını görebilirsiniz.

Simdi hızlıca AD Assessment çözümünü OMS ile entegre edelim.

Bunun için Solution Gallery’de ilgili çözümü seçip eklememiz yeterli olacaktır.

Bu işlem sonrasında ilgili çözüm ana ekrana düşecek ve verileri toplamaya başlayacaktır.

Eğer seçmiş olduğunuz çözüm ile ilgili ek bir yapılandırma yapılması gerekiyorsa ana ekranda bu uy ariyi görebilirsiniz.

İlgili uyarıya tıklayarak yapılandırmayı gerçekleştirebilirsiniz.

Su an için yalnızca Microsoft tarafından sunulan ek çözümleri içerse de ileride bu bolumun farklı vendorlar tarafından sunulan çözümler ile oldukça zenginleşeceği aşikâr. SCOM mimarisindeki Management Pack kavramının yerine OMS ile bulut üzerinden Solution Gallery’i kullanmaya yakın zamanda başlayacağız gibi görünüyor.

Read More

Operations Management Suite Part 6 – Log Filtreleme

Bu yazımızda yapılandırılmış sunucularımızdan toplanan verileri log analizi ile görüntüleme ve basit sorgular oluşturma görevlerini inceleyeceğiz.

OMS ile birlikte veri merkezinizden yada bulut ortamınızda çok değerli verileri toplayabilirsiniz. Ancak toplanan bu verileri doğru şekilde analiz etmeden, anlamlandırmadan ne yazık ki OMS’in sunduğu faydalardan yararlanamazsınız.

Bu sebeple toplanan verilere nereden lastiğiniz ve bu veri havuzu içerisinden istediniz verileri nasıl çektiğiniz oldukça önem kazanıyor.

OMS içerisindeki Log Search kısmi toplanan verilerin genel bir özetini sunan ekrandır. En basit filtreleme olarak yukarıda bulunan search bolumu kullanılabilir.

Örneğin “error” yazarak basit bir filtreleme gerçekleştirdim.

OMS konsolunun en altında görüldüğü gibi filtrelenen verileri liste yada tablo halinde görüntüleyebilir, direkt olarak Excel’e export edilebilir yada daha sonrası için bu filtre kaydedilebilir.

Sol taraftaki add butonuna basarak çok daha detaylı filtreleme opsiyonlarını görebilirsiniz. Bu ekran size ek filtre yazma zahmetinde bulunmadan hızlıca istenilen verileri görüntüleme imkânı sağlar.

Aranacak veri için özelleştirilmiş tarih bilgileri verilebilir.

Ayni zamanda OMS search fonksiyonu size anlık custom queryler yazma imkânı da verir.

Örneğin yalnızca belirli bir bilgisayar için log detaylarını görmek istediğimde aşağıdaki sorguyu kullanabilirim.

Bir adim daha ileri giderek yalnızca belirli EventLog ve IDleri sorgulama şansım da bulunuyor.

Yada Measure metodu ile eventloglari üzerinde count bazlı bir değerlendirme yapma imkânı bulabilirim.

Varsayılanda filtre kısmını yazdığınız her filtre otomatik olarak AND ile kullanılır. Fakat isterseniz OR ile de filtre oluşturabilirsiniz.

Görüldüğü gibi log analizi kısmında basit filtreler dışında oldukça kompleks filtreler de oluşturmanız mümkün. Daha fazla filtre örneği için aşağıdaki TechNet makalesini inceleyebilirsiniz.

https://technet.microsoft.com/en-us/library/mt450427.aspx

 

Read More

Operations Management Suite Part 5 – Azure Diagnostic

Daha önce bahsettiğimiz gibi OMS hem veri merkezinizdeki sunucular için hem de bulut ortamınızdaki sunucular için, Windows yada Lınux fark etmeksizin merkezi bir yönetim imkân sunar.

Bunun için bir önceki makalemizde nasıl ajan kurulumlarının yapılacağını yada SCOM Management Server ile entegrasyon sağlanacağını incelemiştik.

OMS’in çok göz onunda bulunmayan bir diğer yeteneği de var olan Azure üyeliğinize bağlanarak bu üyelik kapsamında bulunan Azure sanal makinelerinin bulunduğu Azure Storage üzerinde verileri çekebilmesidir. Azure Diasgnostic tarafından Azure Storage üzerinde oluşturulan Diasgnostic verileri OMS ile konsol üzerine alınabilir ve analiz gerçekleştirebilirsiniz. Hem sanal makineleriniz hem de bulut servisleriniz için IIS yada event loglarini toparlayıp analiz işlemlerine başlayabilirsiniz.

Tabii ki buna ek olarak her zaman Azure üzerindeki sanal makinelerinize OMS ajanını kurabilir ve ek bilgileri toplayabilirsiniz.

Azure Diagnostic ile oluşturulan verilerin toplanması için aşağıdaki adımların uygulanması gerekmektedir.

Öncelikle VM bazında Azure Diagnostic hizmetinin Azure portali içerisinde aktif edilmesi gerekmektedir. Bunun için yeni bir sanal makine oluştururken VM Agent özelliğinin seçili olması yeterlidir.

 

Eğer önceden oluşturulmuş sanal makinelerinizde VM Agent aktif değilse Custom Create seçeneği ile aktif edebilirsiniz.

Ardından VM bazında diagnostic verinin toplanmasının aktif edilmesi gerekmektedir. Bunun için aşağıdaki alan kullanılır.

Bu şekilde kurulmuş yada sonradan yapılandırılmış sanal makineler otomatik olarak diagnostic verileri toplamaya başlayacaktır.

OMS benim için IIS, System ve application loglarini toplayabildiği için bunları aktif ediyorum.

İlgili yapılandırmayı aktif etmek için ayni zamanda bir storage account secimi gerçekleştirmemiz gerekiyor.

OMS tarafında analizin aktif edilmesi için Azure portalinda Operational Insigths workspace’i seçip Storage tabında ilgili storage hesabınızı eklemeniz gerekmektedir.

Hem IIS hem de event loglari için gerekli yapılandırmayı gerçekleştirdim.

Ayni şekilde isterseniz Linux, ETW yada Service Fabric event leri de toplayabilirsiniz. Tek yapmanız gereken ilgili veri tipini bu alana eklemek.

Bu ekleme işlemlerini gerçekleştirdikten sonra yaklaşık bir saat içerisinde OMS içerisinde analiz için gerekli bilgileri görmeye başlayacaksınız.

Read More

Operations Management Suite Part 4 – SCOM – Ajan Dagitimi

Daha önce OMS veri iletişim yöntemlerinden bahsetmiştik. Uç noktaların OMS veri merkezine verileri iletebilmesi için öncelikle uç nokta üzerinde ajan kurulumlarının gerçekleştirilmesi gerekiyor. Bu ajan SCOM mimarisinden alışık olduğumuz Microsoft Monitoring Agent’in ta kendisidir.

Ajan kurulan istemci direk OMS ile iletişime geçebileceği gibi ayrıca SCOM sunucusuna rapor göndermeye devam edebilir. Bu noktada yapılması gereken SCOM ile OMS arasında entegrasyonun gerçekleştirilmesidir.

Bu bolümde yerel SCOM sunucumuz ile OMS arasındaki entegrasyonu gerçekleştiriyor olacağız.

Entegrasyonu gerçekleştirmek için ilk işlemin SCOM sunucusu üzerinde yapılması gerekmektedir. Bunun için SCOM konsolu Administrator tabında “Register to Operations Management Suite” linki tıklanır.

Bu asamadan sonra SCOM sihirbazı var olan Microsoft yada organizasyon hesabınız ile bağlantı gerçekleştirmenizi isteyecek. Bu noktada aşağıdaki gibi bir uyarı alabilirsiniz.

Bunun için yapmanız gereken Server Manager konsolu içerisinden Internet Explorer Enhanced Mode’u disable etmektir.

Ardından oturum açma işlemini gerçekleştirebilirsiniz.

Daha önce oluşturdunuz Workspace seçimini yapabilirsiniz.

Gerekli entegrasyonu sağladıktan sonra OMS konsolunuz içerisinde bağlantıya dair uyarıyı göreceksiniz.

Bu asamadan sonra OMS ile de yönetmek istediğiniz SCOM bilgisayarlarını eklemeniz yeterli olacaktır.

Microsoft var olan SCOM yapılandırmaları için OMS desteğini UR2 ile birlikte vermeye başladı. Yani yapınızda SCOM 2012 R2 UR2 güncelleştirmesi gerçekleştirdiyseniz OMS entegrasyonunu sağlayabilirsiniz. Ayni şekilde eğer UR3 güncelleştirmesini gerçekleştirdiyseniz Proxy desteğine de sahip olacaksınız.

Proxy desteği özellikle Internet Proxy yapılandırılması gerçekleştirilmiş bir ortamdan OMS bağlantısı sağlamak istediğinizde size yardımcı oluyor. Bunun için öncelikle SCOM içerisinde ilgili Run As Profile hesabını güncelleştirmeniz gerekmektedir.

Bu noktada yapılması gereken Proxy için kullanılacak kullanıcı adi ve parola ile bir Run As Account oluşturmak ve bu Run As Profile içerisine dahil etmektedir.

Bir diğer önemli nokta oluşturduğunuz Run As Account için target olarak Microsoft System Center Advisor Monitoring Server Group objesini seçmeniz. Aksi takdirde bu Run As Account tüm sunucular üzerinde oturum açmaya çalışacak ve size gereksiz tonlarca SCOM alert/warning olarak geri dönecektir.

SCOM bağlantısı dışında bir diğer alternatif de sunucuları direkt olarak OMS hizmetine bağlamaktır. Bunun için yapılması gereken OMS ajanını ilgili sunucular üzerine farklı dağıtım yöntemleri ile göndermektedir. Bu dağıtım yöntemleri

  • Manual kurulum
  • Komut satiri ile kurulum
  • Script ile kurulum
  • Azure Resource Manager Template ile kurulum (Azure sunucuları için)

Seklinde olabilir. Öncelikle OMS portal üzerinden istenilen mimari için gerekli ajan paketi indirilir.

Ayrıca WorkspaceID ve PrimaryKey değerlerinin de kurulum sırasında kullanılmak üzere kopyalanması gerekmektedir.

Bir sonraki adımda istenilen sunucu üzerinde ajan paketi calistirilir.

Kurulum tamamlandıktan sonra Control Panel içerisinde Microsoft Management Agent’i görüntüleyebilirsiniz.

OMS konsolunda görüldüğü gibi sunucum bağlantısını gerçekleştirdi.

Ayni şekilde ARM template, komut satiri yada PowerShell ile de kurulum tek ve birden fazla sunucu için gerçekleştirilebilir.

 

 

Read More

Operations Management Suite Part 3 – Workspace Olusturulmasi

Bu bolümde yeni bir OMS hizmeti oluşturup ilk workspace üzerinde çalışmaya başlayacağız. Makalenin ilerleyen kısımlarında da oluşturduğumuz bu workspace üzerinde çalışıyor olacağız.

https://www.mms.microsoft.com/ adresinden var olan Azure hesabınızı OMS ile ilişkilendirebilir yada ücretsiz deneme sürümünü başlatabilirsiniz.

Ardından aşağıdaki formu doldurarak yeni bir OMS workspace oluşturabilirsiniz.

Bir sonraki adımda var olan bir Azure üyeliğinizi OMS ile entegre edebilirsiniz. Her ne kadar bu zorunlu bir adim olmasa da Azure üzerinde bulunan organizasyon kullanıcılarınız ile yetkilendirme ve delegasyon yapılması için önerilmektedir.

Ve ilk workspace’iniz karşınızda.

Veri toplama, analiz, SCOM entegrasyonu gibi işlemleri gerçekleştirmeden önce workspace üzerinde ilk yapılması gereken işlem OMS yönetimi için kullanıcıların delege edilmesi, gerekirse organizasyon active directory’si ile OMS’in ilişkilendirilmesidir. Bunun için yapılması gereken OMS workspace ekranında settings bölümüne girerek add organization seçilmesidir.

Ayni konsol içerisinde ayni zamanda sağ tarafta bulunan kullanıcı bölümünden delegasyon işlemleri de gerçekleştirilebilir.

Read More

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.

Read More

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.

 

Read More

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

Read More