Windows Server 2012 sunduğu tüm yeniliklerin yanında tamamıyla bulut-entegre bir işletim sistemi olarak geliştirildi. Gerek küçük ölçekli sanallaştırma çözümleri kullanan organizasyonlar gerek ise çok büyük veri merkezleri için uçtan uca sanallaştırma ve bulut altyapısı sunabilmektedir. Bu kadar geniş bir yelpazeye hizmet verebilmek için bugüne kadar olan tüm kullanıcı geri bildirimleri dinlenmiş ve günümüz BT çalışanlarının gelecekteki kritik iş uygulamalarını güvenli, esnek ve yüksek erişilebilir bir ortamda barındırabilme ihtiyaçları göz önünde tutulmuştur.
Resim-1
Günümüzde bulut teknolojisi ile ilgilenen, var olan altyapı, uygulama ve servislerini bir hizmet sağlayıcının veri merkezine taşımayı düşünen organizasyonlarda hep belli başlı çekinceler olmuştur.
Örneğin Public Cloud senaryosunu ile altyapısını hizmet sağlayıcı firmanın veri merkezine taşıyacak olan müşterinin ilk aklına takılan soru güvenliktir. Acaba kritik iş verileri hizmet sağlayıcının networkü içerisinde ne kadar güvenli kalacaktır? Bu network içerisindeki verilerin diğer networklerden yalıtımı nasıl sağlanacaktır?
Ya da hali hazırda var olan network altyapısı, IP adresleri ve bu IP adreslerine bağlı poliçeler değiştirilmeden altyapı nasıl veri merkezine taşınabilir? Kendi altyapısını Bulut hizmet sağlayıcılara taşımak isteyen müşterilerin en büyük çekinceleri, IP yapılandırmalarını hizmet sağlayıcının network altyapısına göre tekrardan düzenleme gereksinimidir. Birçok organizasyon içerisinde halen IP bazlı çalışan kritik uygulamalar bulunmakta ve bu IP’lerin değişimi farklı sorunların ortaya çıkmasına neden olabilmektedir.
Private Cloud senaryosu için de aynı sorular sorulabilir. Organizasyon içerisinde bulunan ve birbirinden izole durumda barındırılması gereken hizmetler için network katmanında nasıl bir yol izlenmelidir?
Bu noktada bugüne kadar kullanılan yöntem genellikle VLAN olmuştur. Virtual LAN teknolojisi ile networkler birbirinden izole edilebilmekte, her bir network kendi iç broadcast networkünü oluşturabilmektedir. Böylece VLAN içerisindeki trafik, sınırlar dışına çıkmamaktadır.
Resim-2
Windows Server 2008 Hyper-V ile sanallaştırma yönetimi gerçekleştiren kurumlar yukarıdaki gereksinimleri karşılayabilmek için, sunulan VLAN desteği ile birlikte sanal makineleri fiziksel VLAN ID leri ile iletişime sokmuşlardır.
Resim-3
Ancak günümüz dinamik BT altyapısında VLAN kullanımı ile ilgili çok temel iki problem bulunmaktadır:
- Dinamik veri merkezlerinde sanal makinelerin barındırıldığı veri merkezi ya da VLAN sınırları değiştirilmek istendiğinde VLAN kullanımı ve bakımı yüksek konsolidasyon oranlarında oldukça zaman alıcı ve hataya yatkın bir işleme dönüşmektedir.
- Genişletilebilme noktasında VLAN ların belli sınırlarının olması yüksek sayıda sanal sunucuya hizmet veren hizmet sağlayıcılarda kimi zaman bariyer oluşturmaktadır. Birçok güncel Switch maksimum 1000 VLAN ID desteklemektedir. Bu da özellikle hizmet sağlayıcıların farklı organizasyonları birbirinden izole etmek istediğinde takıldıkları bir limit olarak karşılarına çıkmaktadır.
Bu problemlere çözüm olarak Windows Server 2012 içerisinde Network Virtualization teknolojisi sunulmuştur.
Sunucu sanallaştırması ile benzer mimariyi kullanan bu teknoloji ile fiziksel network segmentleri sanal makinelere emule edilebilir ve bu networkler sanal makineler üzerinde sanki fiziksel networklermiş gibi çalışabilirler.
Network sanallaştırma sayesinde:
- Tüm yapılandırma merkezi olarak gerçekleştirilir. Her taşıma ya da değişiklik ihtiyacında VLAN benzeri karmaşık yapılandırmaların tamamlanması ihtiyacı yoktur.
- Her organizasyon birbirleri ile benzer IP adres yapısına sahip olsalar dahi izole şekilde farklı networklerdeymiş gibi çalışabilirler. Böylece müşteriler kendi IP adres şemalarını kullanmaya devam edebilirler.
- Farklı subnetler arasında Hyper-V Live Migration kullanılabilir.
- Sanal kaynakları farklı veri merkezlerine taşırken IP adresi değişikliklerine gidilmediği için IP bazlı çalışan tüm poliçe ve güvenlik kurallarının yeniden tasarlanmasına gerek kalmamaktadır.
Özellikle IP adreslerinin farklı organizasyonlarda kullanılıyor olmasına rağmen çakışma sağlanmadan devam edebilmesi Hyper-V içerisinde aşağıdaki iki teknoloji kullanılarak gerçekleştirilir:
- Generic Routing Encapsulation (NVGRE): Bu adres sanallaştırma yöntemi ile sanal networkler ile Hyper-V sunucular arasında tüneller oluşturulur. Tünel içerisinde sanal makine tarafından gönderilen paketler farklı bir paket içerisinde kapsüllenir ve ilgili bilgiler eklenir. Paket içeriği daha detaylı incelendiğinde CA IP adresinin kapsüllendiği ve PA adresinin bu paketin başlığına eklendiği görülür. CA ve PA ilerleyen bölümlerde incelenecektir.
- IP Address Rewrite: Bu özellik ile birlikte sanal makinelerin IP adresleri fiziksel networke ulaşırken fiziksel bir IP adresi ile değiştirilir. NAT benzeri bu özellik genellikle yüksek bant genişliği gerektiren (örn. 10Gbps) senaryolarda kullanılmaktadır. Çünkü fiziksel network kartları üzerindeki offload mekanizmaları sayesinde geniş bant genişlikleri kullanılabilir.
Network sanallaştırmasında Hyper-V içerisindeki her bir sanal network kartı iki farklı IP adresi ile ilişkilendirilir:
Customer Address (CA): Networkünü sanallaştırmak isteyen müşteri tarafından kendi altyapısı göz önüne alınarak atanan IP adresidir. Bu adres yalnızca sanal makine üzerinde aktiftir ve müşteri tarafından ulaşılabilir. Böylece müşterinin sanal makine ile veri alışverişi bu IP adresi üzerinden sağlanır.
Provider Address (PA): Hizmet sağlayıcı tarafından veri merkezi altyapısı göz önüne alınarak atanan IP adresidir. Bu IP adresi fiziksel network üzerinde hizmet sağlayıcı tarafından ulaşılabilir ve Hyper-V sunucunun gerçekleştirdiği veri alışverişinde kullanılır.
Özetle CA adres aralığı sanal makine networkleri tarafından kullanılırken PA adres aralığı fiziksel network tarafından kullanılır. Unutulmaması gereken fiziksel network üzerinde Hyper-V sunucular arasında NVGRE tünelleri oluşturulur ve bu tüneller farklı PA alanlarını kullanırlar.
Sanal makinelerden birisi bir paketi dış dünyaya göndermek istediğinde bu paket PA başlığı ile birlikte kapsüllenir ve fiziksel network üzerindeki tünellerden gönderilir. Yani her bir sanal makine CA’i, fiziksel bir sunucu PA’i ile eşleşmiştir ve bu sayede sanal makinelerin farklı fiziksel sunucularda ürettikleri paketler diğer fiziksel sunuculara gönderilebilir.
Microsoft tarafından hazırlanan aşağıdaki diyagram yukarıda bahsedilen aksiyonları özetlemektedir:
Resim-4
Benzer durum farklı müşterilerin var olduğu bir veri merkezinde de geçerlidir. Her bir müşteri networkü için manuel olarak ya da System Center Virtual Machine Manager tarafından bir Routing Domain ID (RDID) numarası atanır. Bu numara sayesinde müşterinin networkü tespit edilebilir.
Aynı zamanda bir müşteri tarafından kullanılan sanal makinelerin aynı IP subneti kullananları bir Virtual Subnet içerisinde yer alır. Bir müşteri birden fazla IP subnetine dolayısıyla da birden fazla Virtual Subnet‘e sahip olabilir.
Bir müşteri için oluşturulan tüm Virtual subnetlere Virtual Subnet ID (VSID) ataması gerçekleştirilir ve bu subnetlerin her biri bir RDID‘e bağlıdır.
Beklenildiği gibi farklı VSIDler birbirleri ile haberleşebilirler. Çünkü bu VSIDler aslında müşterinin sahip olduğu farklı subnetlerdir. (VLAN ile oluşturulan Broadcast domainine benzerler). Aynı RDID altındaki VSID ler arasında bir iletişim gerçekleşeceği zaman ilgili paketin VSID numarası hedef VSID numarası şeklinde güncellenir. Bu önemli bir adımdır çünkü aksi halde paket teslim edilmeyecektir. Bu da farklı RDIDler arasında (farklı müşteriler) paketlerin iletilemeyeceği anlamına gelmektedir.
Resim-5
Network Virtualization yapılandırması için görsel bir ara yüz bulunmamaktadır. Tüm yapılandırmalar PowerShell komutları ile gerçekleştirilir. Fiziksel network kartı üzerinde Network Virtualization aktif edilmesi için aşağıdaki komut kullanılır:
Enable-NetAdapterBinding Ethernet -ComponentID ms_netwnv
Provider adresini belirlemek için aşağıdaki iki komut kullanılır. İlk komut ile NIC detayları alınarak index numarası ikinci komut içerisinde kullanılır.
Get-NetAdapter –InterfaceDescription “Intel(R) Gigabit Network”
New-NetVirtualizationProviderAddress -InterfaceIndex 6 –ProviderAddress 192.168.1.77 -PrefixLength 24
Yukarıdaki komutlar tüm Hyper-V sunucular üzerinde çalıştırılmalıdır.
Subnet ve Route kayıtları her bir Hyper-V sunucu için girilir. Bu sayede RDID numaraları da tanımlanmış olur.
New-NetVirtualizationLookupRecord -CustomerAddress “172.1.1.1” -ProviderAddress “192.168.1.1” -VirtualSubnetID “4002” -MACAddress “101010101010” -Rule “TranslationMethodEncap”
New-NetVirtualizationCustomerRoute -RoutingDomainID “{11111111-2222-3333-4444-000000000000}” -VirtualSubnetID “4002” -DestinationPrefix “10.1.0.0/16” -NextHop “0.0.0.0” -Metric 255
Ardından sanal makine bazlı Hyper-V Network Switch portları için Virtual Subnet ID ler yapılandırılır.
Get-VMNetworkAdapter -VMName VM1 | where {$_.MacAddress -eq “101010101010”} | Set-VMNetworkAdapter -VirtualSubnetID 4002
Yukarıdaki komut ile yapılandırılan tüm sanal makineler 10.1.0.0/16 subnetini kullanarak birbirleri ile haberleşebilir duruma gelirler.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
anıl süper yazı olmuş. ellerine sağlık.