VMM Network Serisi – Logical Networks

SCVMM icerisindeki Software Defined Networking detaylarini inceleyen serinin bu bolumunde en onemli bilesenlerden birisi olan Logical Network leri inceleyecegiz. Logical Networklerden baslamamizin sebebi aslinda bir cok yapilandirmayi gerceklestirmeden once oncelikle Logical Network dizayninizi gerceklestirmenizin gerekiyor olmasidir.

Alt basliklar ile Logical Network’u inceleyemeye baslayalim.

Logical Network Nedir?

Logical Network en basit tanimi ile “Fiziksel Hyper-V hostlariniz, bu hostlar uzerinde bulunan sanal makineleriniz ve hizmetleriniz icin network bilesenlerini tanimlama ve organize etmenizi kolaylastiran bir kavramdir. SCVMM ile temelde yapmaya calistigimiz sey fiziksel network altyapisinin bir sanal kopyasini olusturmaktir, Logical Network bu noktada en buyuk rolu oynar ve fiziksel network uzerindeki bilesenlerin bircogunu tanimlamamiza olanak saglar.

Iste bu sebeple VMM icerisinde network yapilandirmasina Logical Network tanimi ile baslamamiz ve de ayni zamanda fiziksel network yapisini goz onune alarak Logical Network dizaynini gerceklestirmemiz gerekmektedir.

Logical Network tasarimi nasil gerceklestirilir?

Yukaridak bahsettigimiz gibi logical network tasarimi, VMM icerisinde tum networking bilesenlerini etkileyecegi icin tasarimi oldukca onemlidir. Logical Network tasarimi yaparken asagidaki hususlara dikkat edilmesi gerekiyor:

  • Oncelikle fiziksel network detaylari incelenir. Mumkun oldugunda fiziksel networkler Logical Network seklinde olusturulur.

Logical Network fiziksel networkun VMM icerisindeki sanal bir yansimasidir diyebiliriz. Bu sebeple fiziksel network detaylari detaylica incelenmelidir. Ornegin 3 ana lokasyona dagitilmis network altyapiniz varsa, bu 3 network icerisinde fiziksel Hyper-V sunuculariniz, farkli subnetleriniz ve IP araliklariniz varsa bu detaylar Logical Network tasarimi icin oldukca onemlidir.

Ancak bu her fiziksel network icin birer Logical Network olusturulacak anlamina gelmiyor. Ayni zamanda sadece 3 adet Logical Network olusturulmasi yeterlidir anlamina da gelmiyor.

Tek bir logical network icerisinde birden fazla network site, vlan ve IP subnet belirlenebilmektedir. Bu sebeple aslinda tek bir Logical Network olusturmak 3 farkli fiziksel network ihtiyaclarini karsilayabilir.

Ayrica herhangi bir lokasyonda farkli ihtiyaclar icin kullanilan networkler olabilir. Ornegin production sunuculari, test sunuculari ve development sunuculari birinci lokasyonda bulunuyor olabilir. Bu noktada bu birinci lokasyon icin ek 3 adet Logical Network daha olusturulabilir.

Goruldugu gibi fiziksel network yapisinin birebir kopyasi olarak Logical Network olusturmak her zaman dogru sonucu vermeyebilir.

Bu noktada yalnizca asagidaki senaryo icin kesin konusabiliriz.

Eger tek bir lokasyonunuz varsa ve herhangi bir izolasyon dusunmuyorsaniz tek bir Logical Network olusturabilir ve tum sanal makinelerinizi bu Logical Network uzerinden gecirebilirsiniz.

Bunun disindaki senaryolar icin detayli bir tasarim yapilmasi sarttir. Ancak her zaman basit sekilde baslamak ve ardindan eklemeler yapmak mantikli bir secim olur. Bu yuzden VMM icerisinde tek bir Logical Network ile baslayip ardindan ek Logical Network eklemelerini gerceklestirebilirsiniz.

Aslinda neden tek bir Logical Network olusturup farkli subnetleri destekleyebileceksen neden birden fazla Logical Network olusturmam lazim sorusunun iki cevabi var:

  • Ileriki serilerde gorecegimiz Port Profile lar yalnizca Logical Network uzerinde uygulanabilir. Port Profile ile bir network uzerindeki bandwidth yada ek guvenlik aksiyonlari alinabilir. Bu sebeple bu tarz gereksinimler var ise tek bir Logical Network ile ilerleyemezsiniz.
  • Ikincisi de tabi ki yonetim anlaminda kolaylik. Tek bir Logical Network icerisinde onlarca subnet, vlan olusturmak VMM icerisinde yonetimi oldukca zorlastiracaktir. Bunun yerine ayrilmis sekilde farkli networkleri ayri logical Networkler icerisinde yonetmek daha kolay olacaktir.

Ancak bu konustugumuz senaryolar gercekten dagitilmis ve farkli izolasyon gereksinimleri olan networkler icin gecerlidir. Eger tek bir lokasyona sahip yada ek izolasyon talepleriniz yok ise basit sekilde tek bir Logical Network ile baslamak sizin icin daha mantikli bir secim olacaktir.

Logical Network icerisinde hangi bilesenler tanimlanabilir?

Bir Logical Network icinde asagida goruldugu gibi farkli Network Site lar (ilerleyen bolumlerde inceleyecegiz) ve her bir network site icerisinde de VLAN ve subnet tanimlari girilebilir.


Diger bolumlerde Logical Switch, Port Profile, IP Pool, VNic, Network Site gibi ek bilesenleri inceleyecegiz.



I have a dream..Consolidated Multi-Hypervisor Management Solution




I have a dream that one day we will be able to manage cross virtualization platforms/cloud types/datacenters through a single pane of glass.


I recently blogged about System Center 2012 R2 Virtual Machine Manager UR6 details. One of the features shipped with UR6 was the ability to manage Microsoft Azure VMs from same VMM console. That`s really great if we are talking about a real hybrid cloud solution. I will not start to compare hypervisors or cloud vendors here. I believe diversity makes us better, stronger. No matter which Hypervisor or Cloud solution you have, upper management requires an ROI and you need to leverage your investment. I do not have luxury to tell you “Hyper-V is better, at least we have same feature set with VMware, let`s drop all your infrastructure and build from scratch with Hyper-V” ….No way..

But even you have some investment on VMWare, you may have some workloads on Microsoft Azure as well. Virtual Machines, Azure Site Recovery, Azure Backup or on-premise Hyper-V VMs for test&development purposes.

People are usually maintaining their current investment in its main hypervisor platform and then starting to onboard additional hypervisors for different purposes (cost, DR flexibility, Public cloud integration etc)

See also below blog post from Chris Wolf:


In this poll, %29 indicated that they are planning to have multi-Hypervisor for production server applications that require DR.

Poll also shows that primary driver for choosing single Hypervisor is DR simplicity. I strongly agree with that. Today we are just talking about management side of having multi-hypervisors. But another challenge is to store applications across different Hypervisors that requires Disaster Recovery.

At MSIgnite2015, VMM team announced additional features come with UR6. For me, one of the most exciting was initial management of VMWare 5.5. Below some management operations that you can achieve with UR6:

  • Add VCenter and ESX Hosts
  • Create VMWare VM Template with basic networking
  • Create VMs from templates
  • Perform VM lifecycle operations on VM
  • Start, stop, shutdown, repair, refresh, checkpoint
  • Connect to VM using console
  • Delete VMs
  • Create Resource Pool and bring under management.

I know these are really initial capabilities when you compare with VMware. There are still vast majority of features need to be added.

But if you see the big picture and read following blogs, you also may dream about to have a unified single management solution across different clouds, datacenters, hypervisors.

Hitachi LPAR – Intel Nested Virtualization Support:


Hyper-V Nested Virtualization Support Announced:


VMM UR6 Azure VM Management:


Who knows, If you are good enough you can see “The Smurfs” as well.

One more step to Hybrid Cloud – SCVMM 2012R2 UR6

Microsoft team just announced Update Rollup 6 for System Center 2012 R2 Virtual Machine Manager. This time Microsoft has incorporated requests from customer feedbacks and brought two great features. Gen 2 Support for VMM Service Templates and ability to manage Microsoft Azure VMSs directly from VMM console.

Let`s talk about why these 2 updates are so important.

Generation 2 VMs were announced as a new type of virtual machines in Windows Server 2012 R2. Using Gen2 VMS, you have great benefits such as booting from SCSI attached storage, eliminating legacy networking, larger volume sizes, secure boot features so on. Gen 2 VMs also use UEFI firmware. As you may notice many of these advantages are patently exciting.

However, after you dig far into Generation 2 VMs, you will notice that there is lack of compatibility issue with VMM service templates.  Therefore if you want to deploy “IT services” using VMM Service template which is suggested method, you will get an error regarding compatibility.

This is why, UR6 VMM Service Template support for Gen 2 VMs is important.

Secondly, I like the idea of Microsoft`s Hybrid Cloud approach. Enterprises are looking ways to get full potential of all different cloud types they require to be competitive in market. Microsoft plays a significant role when it comes to a consistent platform for different customers and different needs. Microsoft is single cloud player that offers same consistent platform for customers, consumers and service providers.

Microsoft also invested the idea of Hybrid Cloud in past years. As a virtualization manager, you may have investments in your local datacenter and you may be using  a virtualization fabric management solution like Virtual Machine Manager to manage Hyper-V or different hypervisors. You may also have some workloads on public cloud as well (Azure). Before UR6, to manage local VMs and fabric you had to use Virtual Machine Manager console. To manage your Azure virtual machines, options were browser, PowerShell, Rest Api etc

VMM UR6 brings a new capability into VMM to manage all Virtual Machines from your local datacenter or Azure Infrastructure Services. In one single cloud management portal, you will have a great control of your infrastructure services from Private or Public cloud services.

If you want to know more about these features, checkout below video, Matt McSpirit and Jonobie Ford are discussing some of what`s coming up with UR6.

Microsoft Özel Bulut (Private Cloud) Bileşenleri

Sanallaştırma teknolojileri ile birlikte, IT servislerinin konumlandırılması ve yönetiminde kullanılan ve IT harcamalarının büyük bir kısmını oluşturan fiziksel kaynaklar önemli ölçüde konsolide olmuştu. Sanallaştırma teknolojisinin bizi getirdiği son nokta ise Bulut teknolojileri.

Bulut teknolojisi adaptasyonu ile birlikte var olan veri merkezinizi uçtan uca yönetebilir, kaynak tüketen altyapı ve servisleri bulut ortamına taşıyabilir yada siz, veri merkezinizi kullanarak bulut üzerinden hosting hizmeti verebilirsiniz.

Bu noktada karşımıza Hybrid, Private ve Public Cloud kavramları çıkıyor.

Public Cloud servislerine aylık/yıllık üyelik gerçekleştirerek kaynaklarınızı bulut hizmet sağlayıcı üzerinden kullanabilir, ek kaynak ihtiyacı durumunda satın aldığınız pricing-model’e göre ek ücretler ödeyerek yapınıza kaynak ekleyebilirsiniz.

Private Cloud ise hali hazırda var olan altyapınızı, sanallaştırma teknolojileri ile donatmak ve tüm bu sanal altyapıyı uçtan uca yönetebilmek anlamına geliyor. Yönetmek kavramını biraz daha açmak gerekirse, tüm altyapıyı ve servisleri proaktif ve canlı olarak izlemeli, izlenen verileri analiz ederek gerekli aksiyonları alabilmeli, belirli aksiyonları kriterlere bağlayarak otomatize hale getirebilmelisiniz.

Bu iki teknolojinin bir arada kullanılmasını gerektiren yapılarda ise Hybrid Cloud tasarımı kullanılabilir.

Microsoft Private Cloud çözümü için güncel 2012 ürün ailesi ile birlikte çok önemli geliştirmeleri duyurdu. Private Cloud ile önceden manuel işlem gerçekleştirilmesini zorunlu kılan aksiyonlar otomatize edilmeli ve böylece operasyonel maliyetlerin azaltılması sağlanmalıdır. Tüm bu automation ise önceden oluşturulan servis katalogları ile birlikte self-service yani kendi kendine hizmet verebilecek şekilde tasarlanmalıdır. Kendi kendini yöneten IT altyapısı aynı zamanda organizasyon içerisinde bulunan diğer farklı departmanlara da SLA’ lere bağımlı kalarak hizmet verebilir olmalıdır.

Bu yazımızda yukarıdaki gereksinimleri karşılamak için Microsoft’un sunduğu bileşenleri inceleyelim.

Windows Server / Hyper-V

Windows Server 2012 Microsoft tarafından sunulan en güncel ve güvenli işletim sistemi olarak karşımıza çıkıyor. Sahip olduğu yenilenmiş ve geliştirilmiş Hyper-V rolü ile birlikte tüm Private Cloud altyapısı için Hypervisor yani sanallaştırma katmanı görevi görmektedir. 2012 versiyonu ile birlikte sunulan basitleştirilmiş merkezi yönetim ile birlikte tek bir konsol içerisinden ortamda bulunan tüm Windows Server 2012 sunucular kolaylıkla yönetilebilir. Bu aynı zamanda sanallaştırma altyapısı için de esnek, güvenli ve basit bir arayüz deneyimi sunmaktadır.

Microsoft System Center Virtual Machine Manager

System Center 2012 içerisinde yer alan Virtual Machine Manager ile varolan sanallaştırma sunucuları, sanal makineler yönetilebilir ve bulut mimarisi için hizmet dağıtımı yapılabilir. Sağladığı çoklu sanallaştırma ortam desteği ile kompleks ve karmaşık sanallaştırma ortamlarını dahi kolaylıkla yönetebilen SCVMM aynı zamanda oluşturulan servis şablonları ile sanal makine provision işlemlerini de rahatlıkla sağlayabilir.

Microsoft System Center App Controller

App Controller sayesinde, sunulan web konsolu kullanılarak hizmetler oluşturulabilir ve Private/Public Cloud ortamlarına dağıtılabilir. App Controller sayesinde farklı cloud ortamlarında bulunan Hybrid uygulamalar merkezi bir konsol içerisinden yönetilebilir.

Microsoft System Center Operations Manager

SCOM 2012 versiyonu veri merkezlerini uçtan uca izleyebilecek şekilde tasarlandı. Geliştirilen network monitoring özelliği ve hizmet seviyesi izleme yapabilmesi sayesinde Private Cloud ortamlarının performans ve availability durumlarını uçtan uca izleyebilirsiniz.

Microsoft System Center Orchestrator

Private Cloud ortamların iskeletini oluşturan, manuel işlemlerin otomatize edilmesi görevini gerçekleştiren ürün System Center Orchestrator’dır. Oluşturulan workflow/runbook lar ile private cloud ortamlarındaki kaynaklar talep edilen ihtiyaçlara, açılan çağrılara, monitoring tool’dan gelen alertlere göre oluşturulabilir. Orchestrator aynı zamanda Private Cloud ortamlarında bulunan Microsoft olmayan sistemlere de Integration Packler sayesinde erişebilir, bu sistemleri akışlar içerisine yerleştirebilir.

Microsoft System Center Service Manager

Service Manager, ITIL içerisinde yer alan IT Hizmet yönetimi yöntemlerini organizasyonunuzda uygulamanızı sağlar. Service Manager sayesinde cloud mimarisi içerisinde self-service yönetim tam anlamıyla sağlanmış olur. Varolan Private Cloud ortamınızda değişiklik kontrolü, olay yönetimi ve problem çözümünü tümleşik gelen processler ile sağlayabilirsiniz.

Microsoft System Center Data Protection Manager

Data Protection Manager ile birlikte disk bazlı yada tape bazlı veri koruması sağlayabilirsiniz. Private Cloud ortamınızda bulunan kritik sunuucların ve sanal makinelerin canlı yedeklerini alabilir, Bare Metal Recovery yapabilirsiniz.

Diğer yazılarımızda Cloud mimarisi fiyatlandırma modellerine ve değişen IT rollerine göz gezdireceğiz.


SQL Server 2012 AlwaysOn–System Center 2012 SP1

SQL Server 2012 ile birlikte sunulan en önemli yeniliklerden birisi AlwaysOn teknolojisi. Bu yazımız daha çok System Center ağırlıklı olsa da öncelikle AlwaysOn ile birlikte veritabanı seviyesinde ne gibi avantajlarımız var inceleyelim.

2012 versiyonu öncesi SQL Sunucularda yüksek erişebilirlik sağlamak için sıklıkla Database Mirroring ve Log Shipping yöntemleri kullanılıyordu. Ancak bu yöntemlerin bağımlı olduğu bazı bileşenler vardı. Daha da büyük sıkıntı son dönemlerin popüler konusu olan Cloud yapısına geçilmek istenirse mevcut HA yöntemleri farklı sitelar arasındaki erişilebilirliği istenildiği kadar yeterli şekilde sağlayamıyordu.

Önceki versiyonların sunduğu HA çözümlerindeki sıkıntıları hızlıca inceleyelim.

Database Mirroring çok sık kullanılan bir yöntem. Bir instance içerisinde bulunan SQL veritabanlarını farklı bir instance’a senkronize işlemini database mirroring ile gerçekleştirebiliyorduk. Ancak yaşanan en büyük sıkıntı aynı instance içerisinde bulunan ve birbirine bağımlı olarak çalışan farklı veritabanlarının bir failover durumunda grup halinde taşınamamasıydı. Aynı zamanda mirror edilen veritabanına da erişim mümkün değildi.

Database Mirroring ile her bir veritabanının ancak bir mirror kopyası oluşturulabiliyordu.

Log Shipping yöntemi ise konfigure edilmesi oldukça kompleks olmakla birlikte receiving veritabanının recovery state durumda olduğu için kullanılamamasıydı.

SQL Server 2012 AlwaysOn teknolojisi ile bu noktalarda önemli gelişmeler var.

Bana göre sunulan en önemli yenilik artık sahip olunan AlwaysOn Availability Group mimarisi sayesinde shared storage ihtiyacının ortadan kalkması. Özellikle bulut mimarisinde, private ve public cloud yapılarında SQL cluster mimarisi için costu arttıran en önemli bileşenlerden birisi shared storage ihtiyacı idi. AlwaysOn ile birlikte nodelar üzerindeki DAS ları storage olarak kullanmak mümkün kılındı.

AlwaysOn ile birlikte artık Primary olarak set edilen veritabanının secondary kopyalarını oluşturabiliyoruz. Bu noktada mimari Exchange 2010 ile birlikte sunulan DAG yapısına benzer. Tek bir primary kopyasının 4 farklı secondary kopyası farklı instanceler üzerinde oluşturulabilir.

Primary replica okuma ve yazma için uygun durumdayken aynı zamanda secondary kopyalar da read-only mode için konfigure edilebilir. Bu şu demek, secondary kopyalar üzerinde Database Backup, reporting ve snapshot işlemlerinin gerçekleştirilmesi mümkün.

Güvenlik anlamında da SQL Server 2008 ile birlikte sunulan Transparent Database Encryption (TDE) Enterprise sürüm ile birlikte sunuluyor. TDE’den kısaca bahsetmek gerekirse:

Oracle ve Microsoft tarafından sunulan veritabanı Encrypt yöntemi. Microsoft SQL 2008 ve 2012 sürümü ile TDE desteğini açıkladı. SQL tarafında sağladığı fayda ise bağımlı aplikasyonları etkilemeden var olan herşeyi encrypt etmesi.

Aktif etmek için bir master key oluşturulması, gerekli sertifikanın oluşturulması ve yedeklenmesi yeterli olacaktır. TDE için en kritik nokta master ley için oluşturulan sertifikanın asla ve asla kaybedilmemesi.

AlwaysOn arka tarafta Windows Cluster servisine bağımlı çalışıyor. Aktif etmek için yapılması gereken iki farklı standalone SQL kurulumunun yapılması ve ardından AlwaysOn enable edilerek Availability grupların oluşturulması.

Bu yazının asıl amacına gelirsek:

Bildiğimiz gibi System Center 2012 ile birlikte cloud mimarinizi uçtan uca yönetmeniz mümkün. AlwaysOn ile birlikte veritabanı bazında da datacenterlar arasındaki HA konfigurasyonu artık oldukça kolay ve başarılı.

En önemli nokta ise System Center 2012 SP1 ile birlikte SQL Server 2012 AlwaysOn’un desteklenmesi.

Özellikle Cloud Management için kullanılan System Center ürünleri olan:

  • System Center 2012 SP1 Operations Manager
  • System Center 2012 SP1 Orchestrator
  • System Center 2012 SP1 Virtual Machine Manager
  • System Center 2012 SP1 Data Protection Manager
  • System Center 2012 SP1 Service Manager
  • System Center 2012 SP1 App Controller

Tek eksik Configuration Manager 2012. Bunun sebebi olarak kişisel görüşüm ise ConfigMgr’nin Cloud Management vizyonu içerisinde kendisine çok fazla yer bulamaması.

Yukarıdaki ürünler için ise veritabanlarını SQL Server 2012 içerisinde barındırmak istersek AlwaysOn özelliğinden yararlanabilmeniz mümkündür.

System Center 2012 SP1 Upgrade Sıralaması

Eğer ortamınızda Microsoft System Center 2012 bileşenlerinden iki ya da daha fazlasını barındırıyorsanız System Center 2012 Service Pack 1 Upgrade işleminde izleyeceğiniz sıralamanın önemi, upgrade sonrası bileşenlerin beklendiği gibi çalışması adına oldukça önemli.

Bu sebeple aşağıdaki sıranın izlenmesi MS tarafından test edilmiştir:

1.   Orchestrator

2.   Service Manager

3.   Data Protection Manager (DPM)

4.   Operations Manager

5.   Configuration Manager

6.   Virtual Machine Manager

7.   App Controller


Windows Server 2003 zamanında Cluster.exe ile konfigure edilebilen bir attribute olan AntiAffinityClassNames VM kullanımının artması ile birlikte daha kritik öneme sahip olmaya başladı.

Birden fazla node’unuzun olduğu bir Hyper-V cluster ortamını düşünün. Bu noktada bazı kritik servislerinizde sanal makine olarak bu ortamın içerisinde barınıyor olabilir. Fakat bazı kritik servislerin ihtiyaç gereği failover durumlarında asla aynı host sunucuda barınmamasını isteyebilirsiniz. Örneğin Exchange sunucularının ya da Active Directory sunucularının mümkün oldukça aynı host üzerinde barınmamasını talep edebilirsiniz.

Bu noktada devreye cluster.exe’nin bir parametresi olan AntiAffinityClassNames giriyor. Normalde herhangi bir host fail olduğunda VM ilk olarak preferred owner sunucusuna gitmek isteyecektir. Eğer buraya da geçemez ise sıradaki diğer host sunuculara geçer.

Fakat aynı zamanda her geçiş sırasında ilgili host üzerindeki cluster group için AntiAffinityClassNames parametresi kontrol edilir. Eğer kendisinin sahip olduğu bu parametre geçiş yapmaya çalıştığı cluster group’da da aynı  ise bu geçişi ignore ederek bir sonraki host sunucuya geçiş yapmaya çalışacaktır.

Bu durum mümkün oldukça geçerlidir. Eğer VM’in geçebileceği farklı başka grup yok ise o takdirde AntiAffinityClassNames aynı olsa dahi aynı cluster group içerisine VM taşınabilir.

Bu attribute’ı konfigure edebilmek için aşağıdaki komut satırı kullanılabilir:

cluster group “GROUP1″ /Prop AntiAffinityClassNames=”CustomName”

PowerShell ile de benzer atamayı gerçekleştirebilirsiniz: