VMware vSphere Distributed Switch (vDS) – Part 2

 Configuring vSS and vDS Policies
Plicy’ler hem vSwitch hem de dvSwitch’te port group seviyesinde uygulanabilir. Bu policy’ler vSwitch üzerindeki tüm port group’lara veya dvSwitch’te portlara uygulanır fakat aynı zamanda üzerine yazılabilirlerdir.
Identifying Common vSwitch and dvSwitch Policies
vSwitch ve dvSwtch 4 ortak policy’ye sahiptir.
  • Failover and Load Balancing Policy: network kartları arasında outbound network trafiğinin nasıl dağıtılacağına ve hata veren network kartlarının nasıl işleneceğine karar vermek içi kullanılır.
  • Security Policy: Layer 2 fram filtering policy’leri kurmak için kullanılır.
  • Traffic Shapping Policy: İzin verilen bandwith miktarının kontrol edilmesi için kullanılır.
  • VLAN Policy: Bir network bağlantısı için VLAN ID oluşturmak amacıyla kullanılır. Fakat vSwitch’te Private VLAN yoktur.
vSwitch load balancing policy ile outbound traffic kontrol edilebilirken, inbound traffic fiziksel switch tarafından kontrol edilebilir.
Configuring Load Balancing and Failover Policies
Failover and Load Balancing Policy network kartları arasında outbound network trafiğinin nasıl dağıtılacağına ve hata veren network kartlarının nasıl işleneceğine karar vermek içi kullanılır. Aşağıdaki özellikler konfigüre edilebilir:
  • Load Balancing
Load balancing policy ESXi host’un uplink adapter’lerini nasıl kullanacağına karar verebilmesi için kullanılır. 5 seçenek vardır:
  • Route Based On Originating Virtual Port: Trafiğin switch’e girdiği port bazında bir uplink seçilecektir. Bu varsayılan seçenektir.
  • Route Based On IP Hash: vSwictch, her paketin kaynak ve hedef IP adresine istinaden VM’ler için uplinkleri seçer. Fiziksel switch konfigürasyonu gerektirir.
  • Route Based On Source MAC Hash: vSwitch, VM’in MAC adresine binaen VM için bir uplink seçer.
  • Route Based On Physical NIC Load: Fiziksel NIC üzerindeki mevcut yük baz alınarak bir uplink seçilir. Bu seçenek sadece dvSwitch ile kullanılabilir.
  • Use Explicit Failover Order: Bu policy ile gerçek bir failover sağlanmaz. VM daima Active adapters listesindeki ilk uplink’i kullanır ve failover algılama kriterini geçer. Active adapters listesinde bir uplink yoksa standby adapters listesinden uplink seçilir.
  • Network Failover Detection
Network Failover Detection uplink hatalarını tespit etmek için kullanılan bir mekanizmadır. İki seçenek vardır.
  • Link Status Only: Sadece network kartlarının sağladığı link durum bilgisine dayanır. Bu seçenek switch hatalarını ve kablo çıkmışsa hatayı tespit edebilir, fakat konfigürasyon hatalarını ve diğer uçtaki fiziksel switch’te kablo çıkmışsa bunu tespit edemez.
  • Beacon Probing: Team içindeki tüm NIC’ler için Beacon Prob’lar gönderilir ve dinlenir. Bu bilgi, link durumu ve daha fazlasını belirlemek için kullanılır. Konfigürasyon hatalarını ve diğer taraftaki kablo çıkma durumlarını tespit edebilir. Beacon probing Route Based On IP Hash load balancing policy ile birlikte kullanılmamalı. Terming içinde üç veya daha fazla adapter kullanıldığında faydalıdır.
Beacon probing kullanmak için özel bir sebep yoksa Link status only varsayılan seçeneği kullanılmalıdır.
  • Notify Switches
ESXi host üzerinde Uplink adapter’lardan birinde sorun oluştuğunda switch’e bildirimde bulunmak için kullanılır. İki seçenek vardır:
  • Yes Bu seçenek kullanıldığında virtual NIC’in lokasyonu değiştiğinde fiziksel switch’e bildirimde bulunulur. En düşük latency sağlandıktan sonra çoğu zaman istenen durum budur.
  • No Bu seçenek bağlanmış olan VM’ler unicast modda Microsoft Network Load Balancing (NLB) kullandığı zaman kullanılır.
  • Failback
Failback, bir uplik adapter hata durumundan sağlıklı çalışır duruma geri geldiğinde ne yapılacağına karar vermek için kullanılır. İki seçenek vardır:
  • Yes Adapter recovery’den hemen sonra eski yerine konulur ve standby adapter standby konumuna geri döner.
  • No Adapter tekrar ihtiyaç duyulana kadar servis dışı bırakılır.
  • Failover Order
İsimlendirme vSwitch’te kullanılan adapters teriminden ve dvSwitch’te kullanılan uplinks teriminden farklıdır. Üç seçenek vardır:
  • Actve Adapters/Uplinks: Network bağlntısı mevcut olduğu sürece kullanılır.
  • Standby Adapters/Uplinks: Active adapter’lardan biri bağlantıyı kaybederse kullanılır.
  • Unused Adapters/Uplinks: Bu adapter’lar asla kullanılmaz.
Active, Standby ve Unused adapters/uplinks virtual switch özelliklerinden organize dilebilir ve port group özelliklerinden üzerine yazılabilirler.
Route Based On IP Hash load-balancing policy kullanıldığında standby adapters/uplinks kullanılmaz.
Configuring Network Security Policies
Virtual switch’ler kendilerine başlı olan VM’leri taklit etme ve dinleme ataklarına karşı koruyabilir. Bu policy’ler vSwitch veya port group seviyesinde uygulanabilir.
Promiscuous Mode policy’ler, promiscuous mode’daki bir NIC’e sahip olan VM’lere aynı vSwitch veya port group’taki tüm trafiği gözlemesine izin verir. Genellikle bu policy VM üzerinde packet sniffer veya intrusion detection sistemleri çalışıyorsa kullanılmalıdır. Promiscuous Mode Accept olarak ayarlandığında, promiscuous mode’da bir NIC’e sahip olan herhangi bir VM, aynı network’te olan diğer tüm VM ve host’lar için gönderilen trafiği görebilir. Bu güvenli olmayan bir operasyondur ve varsayılan seçenek Reject’tir.
MAC Address Changes policy’ler bir VM tarafından alınan trafiği etkiler. Bu policy, intial MAC address ve effective MAC address arasındaki farkın vSwitch veya port group tarafından nasıl işleneceğini kontrol etmek için kullanılır. MAC Address Changes policy Accept olarak ayarlanırsa initial ve effective MAC address’ler farklı olabilir. Başka bir deyişle, vSwitch MAC address değişikliği talebini kabul eder. MAC Address Changes policy Reject olarak ayarlanırsa initial ve effective MAC address’leri eşleşmek zorundadır, aksi taktirde vSwitch VM NIC’inin bağlı olduğu portu disable eder. Bu VM, initial ve effective MAC adresleri tekrar eşleşene kadar herhangi bir trafik alamaz. ESXi Software iSCSI initiator kullanılıyorsa MAC address Changes policy’yi Accept olarak ayarlamak gerekiyor.
Forged Transmits policy’ler bir VM’den iletilen trafiği etkiler. Bu policy, intial MAC address ve effective MAC address arasındaki farkın vSwitch veya port group tarafından nasıl işleneceğini kontrol etmek için kullanılır. Forged Transmit policy Accept olarak ayarlandığı zaman initial ve effectve MAC address’ler farklı olabilir. Forged Transmit policy Reject olarak ayarlandığı zaman initial ve effective MAC address’leri eşleşmek zorunda. Aksi taktirde vSwitch VM’den alınan her paketi drop eder.
Configuring Traffic Shaping Policies
Traffic shaping policy’ler network bandwith’i kontrol etmek için kullanılır ve hem vSwitch hem de dvSwitch’te kullanılabilir. vSwitch’te sadece outbound trafiği kontrol edebilir, dvSwitch’te ise hem inbound hem de outbound trafiği kontrol edebilir.
Average Bandwidth: Bir portta izin verilen saniyedeki bit sayısı (kbit/s). Bu sayı zaman içinde ölçülür ve izin verilen ortalama yükü temsile eder.
Peak Bandwidth: Bir portta izin verilen maksimum saniyedeki bit sayısı (kbit/s). Bu sayı bir burst sırasında bandwitdth’i limitlemek için kullanılır ve average bandwitdth’ten küçük olamaz.
Burst Size: Bir burst içindeki izin verilen maksimum KB. Bir port average bandwidth’te belirtilen değerden daha fazla bandwitdth’e ihtiyaç duyarsa ve bandwidth uygun durumdaysa daha fazla trafik verilmesine olanak sağlar.
Determining Appropriate VLAN Configuration for a vSphere Implementation
VLAN, tek bir fiziksel network’ü birden fazla mantıksal network’e ayırmak için kullanılır. vSphere’de VLAN aşağıdaki sebeplerle kullanılır:
  • ESXi hots entegrasyonunu basitleştirmek için
  • Network güvenliğini artırmak için
  • Network’teki yoğunluğu azaltmak için
  • Network trafiğini izole etmek için
vSphere’de VLAN’in desteklenebilmesi için fiziksel veya sanal switch 801.1Q tag’i ile tag’lenmek zorundadır. Bu tag aynı zamanda VLAN ID olarak bilinir.
External Switch Tagging (EST): Tüm VLAN tag’leme işlemlerini fiziksel switch yapar. ESXi host network kartları fiziksel switch’te access/untagged portlara bağlanır.
Virtual Switch Tagging (VST): vSwitch veya dvSwitch tüm VLAN tag’leme işlemlerini yapar.ESXi host network kartları fiziksel switch’te trunk/tagged portlara bağlanmak zorundadır. Genelde kullanılan kurulum yöntemi budur.
Virtual Guest Tagging (VGT): 802.1Q VLAN trunking driver’i yüklenmiş olan VM tüm VLAN tag’leme işlemlerini yapar. ESXi host network kartları fiziksel switch’te trunk/tagged portlara bağlanmak zorundadır.
VST en çok kullanılan kurulum yöntemidir. Bunun nedeni VST trunked VLAN’ları kullanabilir ve VM tarafında herhangi bir konfigürasyon yapılmasına gerek yoktur. Trunked VLAN kullanmak ESXi host üzerinde fiziksel NIC gereksinimini ve karmaşıklığı azaltır.
Configuring dvPort Group Blocking Policies
Port blocking policy’ler gönderilen ve alınan verilerden bir port group üzerindeki tüm portları bloklamak için kullanılır ve sadece dvSwitch üzerinde bulunur.
Enabling Jumbo Frames Suport on Apporpriate Components
Jumbo Frame, 1.500 byte’tan büyük, 9.000 byte veya 9.000 byte’tan daha az yük boyutuyla bir Ethernet Frame’dir. Bu boyut aynı zamanda maximum transmission unit (MTU) olarak da bilinir. Jumbo frame, network I/O performansını artırmak için aktif edilebilir ve daha az CPU kaynağı kullanır. Jumbo frame, network üzerinde uçtan uca desteklenmelidir. Yani ESXi host, hedef, ve tüm fiziksel switch’ler jumbo frame desteklemelidir.
Jumbo frame otomatik olarak performans artışını garanti etmez. Jumbo frame kullanırken daima en iyi yöntem jumbo frame’li ve jumbo frame’siz performansı test etmektir.
Bir sanal makinanın jumbo frame kullanabilmesi için aşağıdaki gereksinimlerin karşılanması gereklidir:
  • Jumbo frame’in aktif edildiği bir virtual switch’te virtual machine port group’a VMXNET 2 veya VMXNET 3 network kartı bağlanmalıdır.
  • Sanal makinaya bağlanan tüm fiziksel switch’ler ve diğer cihazlar jumbo frame desteklemelidir.
  • VM jumbo frame desteklemesi için konfigüre edilmelidir. Windows makinalarda network adapter özelliklerinde MTU ayarlarını değiştirerek bu işlem yapılabilir.

VMware vSphere Distributed Switch (vDS) – Part 1

Bu yazıda vSphere Distributed Switch ile ilgili pratik, daha çok ansiklopedik bilgiler vermeye çalışacağım. Umarım faydalı olur.
vNetwork Distributed Swtich, dvSwitch veya vDS olarak da adlandırılabilir.
dvSwitch, tek bir virtual switch yeteneklerini diğer ESXi hostlara genişletmesiyle vSwitch’ten farklıdır.
dvSwitch kullanabilmek için vCenter Server ve Enterprise Plus lisansa ihtiyaç vardır.
dvSwitch, vSwitch’in tüm özellikerini desteklemekle beraber aşağıdaki özelliklere de sahiptir:
  • Bidirectional Virtual Machie Rate Limiting (Traffic Shaping): vSwitch sadece outbound (egress veya TX olarak da bilinir) traffic shapping yapabilirken, dvSwitch inbound (ingress veya RX olarak da bilinir) traffic shappin de yapabilir. Traffic Shapping, VM’ler üzerinde bandwith sınırlaması gereken durumlarda kullanılır.
  • Centralized vCenter Administration and Provisioning: dvSwitch’ler vCenter içerisinden yönetilir ve provision edilir. Bunun anlamı, yönetim için tek konfigürasyon yapılmasıdır. Özellikle büyük yapılar için ciddi avantajlar sağlar.
  • Cisco Nexus 1000V Virtual Switches: dcSwitch’lerin özelliklerine ek olarak third party dvSwitch kullanmak da mümkündür. Örneğin Cisco Nexus 1000V sanal ortama implemente edilebilir. Cisco Nexus 1000V ACLs kullanımı, port security gibi geliştirmeler sağlar.
  • Dynamic Adjustment for Load-Based NIC Teaming: Load-nased NIC teaming, team yapılmış NIC’lerin üzerindeki yükü düzenli olarak kontrol etmek için bir algoritma kullanır. Bir NIC’in yükü artarsa, yükü dengelemek için bir port-NIC mapping assignment meydana gelir. Bu işlem teamed NIC’lerin yükünü dengede tutar.
  • Enhanced Security and Monitoring for vMotion Traffic: Port istatistiklerini de içeren VM network durumu, VM’ler dvSwitch içinde vMotion ile host-to-host taşınıyormuş gibi izlenir. Bu, VM’lerin lokasyonlarına veya migration history’sine bakmaksızın, VM network interface’leri için daha tutarlı bir görünüm sağlar. Sorun çözümünü, VM’ler için network monitoring’i kolaylaştırır.
  • IEEE 802.1p Tagging: IEEE 802.1p Tagging MAC address seviyesinde kullanılan standart bir QoS servisidir. Bu yetenek, I/O kaynaklarını garanti eder ve outbound network trafiğine uygulanır.
  • LLDP: dvSwitch’ler Link Layer Discovery Protocol (LLDP) ‘ü destekler. LLDP network cihazları hakkında bilgi toplar.
  • NetFlow: Uygulama akışlarını (veya IP trafiğini) monitor etmeye izin verir. Bu Netflow verisi kapasite planlama ve I/O kaynaklarının sanal ortamda uygun kullanıldığından emin olmak için kullanılır.
  • Network I/O Control: Network I/O control, network bandwith’i de içeren resource pool’ların oluşturulmasına izin verir. Administrator’lar, port group’larla ilişkilendirmek ve 802.1p tag tanımlamak için yeni resource pool’lar oluşturabilir, farklı VM’lere farklı resource pool’lar içinde olabilmelerine imkan verir.
  • Port Mirror: Başka bir swtich portuna network monitoring cihazı bağlandığında, bir network switch, ilgili switch portlarına veya tüm VLAN’a network paketleri gönderir. Port mirroring izeleme ve problem çözümü için kullanılır.
  • Private VLAN Support: dvSwitch’ler aynı IP subnetteki bilgisayarların arasında izolasyon sağlayan Private VLAN (PVLAN) desteğini içerir. PVLAN, nested VLAN veya VLAN içinde VLAN olarak açıklanabilir. İlk VLAN primary olarak bilinir, nested VLAN’lar secondary olarak adlandırılır. Üç tür PVLAN vardır:
    • Promiscuous: Isolated ve Community dahil tüm portlarla iletişi kurabilir.
    • Isolated: Sadece Promiscuous port ile iletişim kurabilir.
    • Community: Aynı secondary PVLAN içindeki tüm portlarla ve Promiscuous PVLAN ile iletişim kurabilir.
  • Management Network Rollback and Recovery: Bu özellik management network kullanımını kolaylaştırmak için kullanılır. Management network üzerindeki konfigürasyon değişikliklerini algılayarak çalışır. Bir ESXi ilgili vCenter ile iletişim kuramazsa, network otomatik olarak bir önceki konfigürasyona geri döner.
  • Network Health Check: Bu özellik vSphere yöneticilerine network hatalarını hızlı bir şekilde tanımlayabilmeleri için yardımcı olur. VLAN, MTU ve network kart teaming’i düzenli olarak kontrol eder. Eğer bir hata durumu oluşursa vSphere Web Client’ta uyarı mesajı görüntülenir.
  • Link Aggregation Control Protocol (LACP): LACP, fiziksel network kartlarını tek bir mantıksal linke gruplamak için kullanılan standart bir protokoldür.
  • Traffic Filtering and Marking: Bu özellik VM’ler, Vmkernel adapter ve fiziksel kartlara olan network trafiğini filtrelemek ve öncelik etiketi eklemek için kullanılır. Bu bağlantıları güvenlik ataklarından veya istenmeyen outbound trafiğinden korumak için kullanılır.
Creating and Deleting a vNetwork Distributed Switch
dvSwitch, vCenter Server datacenter seviyesinde oluşturulabilir. vCenter Server 5.5 ‘te beş farklı dvSwitch versiyonu oluşturulabilir:
  • Distributed Switch 5.5.0: Bu versiyon vSphere 5.5 ve daha yeni sürümlerle uyumludur. Gelişmiş LACP desteğinin yanı sıra Traffic Filtering and Marking özelliği geldi.
  • Distributed Switch 5.1.0: Bu versiyon vSphere 5.1 ve daha yeni sürümlerle uyumludur. Management Network Rollback and Recovery, Health Check, Enhanced Port Mirroring ve LACP özellikleri geldi.
  • Distributed Switch 5.0.0: Bu versiyon vSphere 5.0 ve daha yeni sürümlerle uyumludur. Network I/O Control içinde user-defined network resource pool, NetFlow ve Port Mirroring özellikleri geldi.
  • Distributed Switch 4.1.0: Bu versiyon vSphere 4.1 ve daha yeni sürümlerle uyumludur. Load-based teaming ve Network I/O Control özellikleri geldi.
  • Distributed Switch 4.0: Bu versiyon vSphere 4.0 ve daha yeni sürümlerle uyumludur. dvSwitch’in daha yeni versiyonlardaki özellikleri bu versiyonda yok.
Daha yeni versiyonlardaki özellikler, önceki dvSwitch versiyonlarında yoktur. Örneğin NetFlow dvSwitch versiyon 5.0.0’da geldi ve 5.0.0, 5.1.0 ve 5.5.0 ile çalışır.
Uplink port, dvSwitch’in ESXi host üzerindeki fiziksel NIC’lere bağlanabilmesi için kullanılır ve host başına dvSwitch’e bağlanabilecek maksimum sayıyı belirtir.
dvSwitch’i silindiğinde aynı zamanda port group, alarm ve task’lar da silinir.
Adding and Removing ESXi Hosts to/from a vNetwork Distributed Switch
dvSwitch ile çalışabilmek için öncesinde ESXi hostları dvSwitch’e eklememiz gerekiyor.
Adding and Removing Uplink Adapters to/from dvUplinks Groups
Distributed Virtual Uplink (dvUplink) ESXi host üzerindeki fiziksel network kartı (vmnic) ve dvSwitch arasında bir soyutlama sağlamak için kullanılır. Bu, aynı dvSwitch’i kullanan ESXi hostlara ayrı vmnic konfigürasyonlarına sahip olmalarına rağmen halen aynı teaming, load balancing ve failover policy’lerini kullanmalarına olanak verir.
Bir uplink adapter dvSwitch’in external network’e bağlanabilmesini sağlayan fiziksel bir network karıdır.
Port Group eklerken aşağıdaki VLAN seçenekleri ile karşılaşırız:
  • None: VLAN kullanılmayacak. Bu seçenek, vSwitch’te opsiyonel olarak verilen VLAN ID alanının boş bırakılması ile aynıdır.
  • VLAN: 1-4094 arasında bir VLN ID girilerek kullanılır. Bu seçenek vSwitch’te port group oluştururken opsiyonel VLAN ID alanına bir değer girmekle aynıdır.
  • VLAN Trunking: Bu seçenek VLAN trunk aralığı girmek için kullanılır. Tek bir dvSwitch tüm trunk yapılmış VLAN’ları yönetebildiği için vSwitch’ten farklıdır. vSwitch aynı sonucu elde edebilmek için her VLAN için port group’a ihtiyaç duyar.
  • Private VLAN: Private VLAN seçmek için kullanılır. Private VLAN ayarlamalsı yapıllmadıysa kullanılamaz. vSwitch’te bir karşılığı yoktur.
Port group eklerken aşağıdaki Port binding seçenekleri karşılaşırız:
Port binding, dvPort group içindeki dvPort’ların bir VM’e ne zaman assign edilip edilmeyeceğine karar verir.
  • Static binding: Vmware tarafından genel kullanım için önerilen varsayılan port binding’dir. VM bir dvPort’a bağlandığında dvPort hemen assign edilir ve rezerve edilir. Bu yöntem VM için bağlantıyı garanti eder ve sadece VM dvPort group’tan kaldırıldığında serbest bırakılır. Static binding ile vMotion kullanılırken veya VM güç yönetim işlemleri sırasında network istatistikler tutulur.
  • Dynamic binding: vSphere 5’te artık kullanılmayan ve mevcut dvPort ‘lardan daha fazla VM’in olduğu fakat mevcut port sayısının beklendiği şekilde aşılamadığı durumlarda kullannılırdı. Örneğin; 128 portlu bir dvPort group’a 150 VM’in bağlandığı, fakat aynı anda 75 VM eş zamanlı olarak power on durumda olduğu bir ortam düşünelim. Dynamic binding ile bir dvPort sadece VM power on olduğu ve NIC’in bağlı olduğu durumda assing edilir. NIC bağlantısı koptuğunda veya VM power off olduğunda dvPort serbest bırakılır. Vmotion kullanılırken network istatistikleri tutulur fakat VM power off olduğunda kaybedilir.
  • Ephemeral binding: vSwitch’in davranışlarıyla benzerlik gösterir ve vCenter Server veya direkt olarak ESXi host üzerinden yönetilebilir. VMware, Ephemeral binding’i sadece recovery nedeniyle veya vCenter Server ulaşılamaz durumda olduğunda kullanılmasını öneriyor. Ephemeral binding ile VM power on olduğunda ve NIC bağlandığında dvPort oluşturulur. VM power off olduğunda veya NIC bağlantısı kesildiğinde dvPort silinir. vMotion kullanıldığında veya güç yönetim işlemleri sırasında network istatistikleri tutulmaz.
Creating, Configuring and Removing Virtual Adapters
dvSwitch’te virtual adatper’lar ESXi management traffic, votion, FT, iSCSI ve NFS gibi Vmkernel bağlantıları için kullanılır.
dvSwitch’te dvPort group’un aksine, virtual adapter’ların konfigürasyonu ve silinmesi ESXi host seviyesinde olur.
Virtual adapter’lar sadece Vmkernel bağlantıları için kullanılabilir.

Citrix Provisioning Service ile XenDesktop 7.6 İmaj Güncelleme

Citrix XenDesktop ile sanal masaüstü oluşturmak için iki yöntem vardır. Provisioning Services (PVS) ve Machine Creation Services (MCS). PVS ve MCS ile ilgili daha önce bir yazı yazmıştım. Buradan ulaşabilirsiniz.
PVS ve MCS ile golden imaj oluşturmak ve bu imajları güncelleştirmek için farklı yöntemler mevcut. Bu yazıda PVS ile oluşturulmuş olan bir imajı güncelleştirme yöntemlerinden birini anlatmaya çalışacağım.
Öncelikle ortamdan bahsedeyim.
  • Tüm sunucu işletim sistemleri (Provisioning Server, Delivery Controller vs.) Windows Server 2012 R2.
  • Sanal masaüstü olarak kullanılan işletim sistemi Windows 7.
  • XenDesktop 7.6
PVS ile imaj güncellemek aslında PVS Server üzerinde bulunan vDisk’in güncellenmesi demektir. Sanal masaüstleri çalışırken vDisk’in güncellenmesi mümkün değildir. vDisk güncellemesi yapılabilmesi için, vDisk’in Private Mode’da olması gerekir. vDisk’i Private Mode’a alabilmek için de ilgili vDisk’i kullanan tüm sanal VM’lerin kapatılması gerekir. (ki mesai saatleri içinde bu işlemi yapmak uygun olmaz). Bu seçenekte mevcutta kullanılmakta olan vDisk güncelleneceği için golden imajın güncellenmesi sırasında yapılabilecek bir hatada imaj kullanılamaz duruma gelebilir ve geri dönüşü olmayabilir.
İkinci seçenek, ilgili vDisk’in bir kopyasını alıp onun üzerinde güncelleme yapmak ve sonrasında yaygınlaştırmak. Bu seçenek ile mevcutta kullanılmakta olan vDisk’in bir kopyası alınıp bunun üzerinde değişiklikler yapıldığı için, hata yapılsa bile geri dönüşü mümkün olacaktır. Bu yazıda ikinci seçenek üzerinden ilerleyeceğiz.
Diğer bir seçenek de versiyonlama dediğimiz bir yöntemdir. Versiyonlama ile mevcut imajın farklı bir versiyonu alınarak uygulanan bir yöntemdir. Bu yazıda bu seçenekten bahsetmeyeceğiz.
İmaj güncelleme için kullanacağımız yöntemde vDisk’in bir kopyasını alıp, bu kopyanın üzerinde değişiklikleri yapacağımızı söylemiştim. Provisioning Services ile sanal masaüstü kullanımında tüm vDisk’ler PVS Server üzerinde durur. Her imaj için PVS Server’da 3 dosya türü bulunur:

 

Citrix PVS ve MCS Karşılaştırması (PVS vs. MCS)

Citrix, masaüstü sanallaştırma çözümü olan XenDesktop için yaygınlaştırma çözümü olarak iki seçenek sunar. Bunlar, MCS (Machine Creation Service) ve PVS (Provisioning Services).
Provisioning Services büyük ölçekli XenDesktop kurulumları için en iyi seçenektir. Küçük ölçekli kurulumlar için ise Machine Creation Services daha basit bir kurulum gerektirdiği için kolay olabilir.
Citrix, PVS teknolojisini 2006 yılından beri kullanıyor. MCS ise 2010 yılında XenDesktop 5 ile birlikte kullanılmaya başlandı.

Machine Creation Services

  • MCS, Studio yönetim konsolundan yönetilebilen, XenDesktop’un bir bileşenidir. MCS’in avantajlarından biri hemen kullanılmaya başlanabilir olmasıdır. PVS ile sanal masaüstü oluşturup kullanmaya başlamadan önce Provisioning Server’ların kurulması gerekmektedir.
  • MCS, XenServer, Hyper-V ve VMware ESXi hipervizörler ile uyumludur. Sanal makinaları oluşturmak, konfigüre etmek ve yönetmek için API’leri kullanır.
  • MCS ile Pooled-Random, Pooled-Static ve Dedicated olmak üzere üç tip sanal makina oluşturulabilir
  •  Dedicated, Citrix personal vDisk içeren kalıcı bir sanal masaüstü olarak gelir. Differencing disk, kullanıcıların verilerini kaydetmek için kullanılır ve write cache gibi davranır. Kullanıcı verileri bir login’den diğer login’e taşınır.
  •  Pooled-random, nonpersistent (kalıcı olmayan) sanal masaüstüdür. VDI oturumları arasında verileri kaydetmez.
  • Pooled-static, kalıcı olmayan masaüstüdür fakat belirli kullanıcılara dedike edilirler. MCS kalıcı olmayan masaüstleri differencing disk içerir, fakat VDI oturumları arasında kullanıcı bazlı verileri silerler.
MCS kullanmak için ilk adım, kendisinden clone’lar oluşturmak amacıyla şablon olarak hizmet verecek bir master VM oluşturmaktır. CPU, RAM miktarı ve disk alanı belirlenebilir, işletim sistemi ve uygulamalar kurulur. Studio console kullanarak base image’lar baz alınarak oluşturulan clone VM’lerden bir catalog oluşturulur. PVS’ten farklı olarak bu VM’ler datastore içinde yer kaplarlar. Bundan dolayı Thin Provisioning kullanmak faydalı olabilir.
Sanal masaüstü imajlarına bir catalog oluşturmak için, bir VM oluşturulur ve bu master VM olarak seçilir. MCS, master VM’in bir snapshot’ını ve bu snapshot’un full kopyasını oluşturur. Daha sonra MCS bu masaüstlerini Active Directory’ye ekler.
Kullanıcıların sanal masaüstlerini güncellemek için master VM’de değişiklikler yapılmalı Studio içinde update seçeneği seçilmeli. Pooled-random ve pooled-static masaüstleri için MCS tamamen yeni clone’lar oluşturur ve bunları kullanıcıların bir sonraki boot işleminde eskileriyle değiştirir. MCS, kullanıcıların yaptığı değişiklikleri silmeden dedicated masaüstlerini güncelleyemez.
Master Image’i güncellemek veya çıkan yamaları yapmak ve ardından yeni VM clone’ları deploy etmek için de MCS kullanılır. Bu özellik nonpersistent masaüstleri için kullanışlıdır, çünkü eski nonpersistent masaüstlerini silmek önemli değildir. Storage üzerinde yeterli alan yoksa persistent masaüstleri sorun çıkarabilir, bununla birlikte eski versiyonlar genelde tutulur. Aksi taktirde kullanıcılar verilerini kaybedebilir.
MCS genelde PVS’ten daha fazla IOPS kullanır. Firmalar bu endişeyi SSD gibi teknolojiler ile gidermeye çalışır. Ayrıca hyperconverged altyapılar IOPS verimiliğini artırarak iş yükü ile ilgili endişeleri gidermeye çalışırlar.
Aşağıdaki durumlarda MCS kullanmak doğru bir seçim olabilir:
  • Sade bir VDI ortamı kurmak istiyorsunuz
  • NFS storage (XenServer ve ESXi) veya Clustered Shared Volumes (Hyper-V) eklemek niyetindesiniz
  • Bir site’da 2500’e kadar masaüstü deploy etmek istiyorsunuz
  • Paylaşımlı depolama ünitesi üzerinde yeterli IOPS’a sahipsiniz

Provisioning Services

Citrix’in diğer konfigürasyon aracı olan PVS, XenDesktop ve XenApp’in tüm versiyonları ile kullanılabilir. Citrix PVS bu iki ürünle entegre edilmiştir. Fakat, kurulumları yapmak daha fazla zaman alır. Buna rağmen, kurulumu ve konfigürasyonu yaptıktan sonra PVS streaming teknolojisi tek bir master imajdan çok fazla sanal masaüstünü yönetmek daha kolay bir hale gelir.
Öncelikle PVS yazılımı sunuculara kurulmalı ve bu sunucular merkezi yönetim için bir server farm olarak yapılandırılmalıdır. Citrix PVS, tek PVS sever üzerinden yüzlerce hatta binlerce masaüstünü stream edebilir. Sadece biri primary, diğeri fallback olmak üzere en az 2 adet PVS sunucu yapılandırmak gereklidir. Ek olarak PVS console’un kurulması ve master image’in yapılandırılması gerekiyor.
Provisioning Services, read only XenDesktop oturumları sırasında, host server’lar üzerindeki local storage’leri kullanarak, bir write cache gibi davranmasını sağlamak amacıyla tek seferde çok sayıda hedefe paylaşılan base imajları stream edebilir. Sanal masaüstlerini son kullanıcılara ulaştırmak için ihtiyaç duyuldukça hedef VM’ler vDisk imajları stream ederler. Bu kurulum şekli, bir VDI oturumunu başlatmak için gerekli olan bandwith miktarını azaltır. PVS’in streaming teknolojisi ile sadece tek bir master imajın güncellenmesi sayesinde, VM’ler reboot edildiğinde yeni versiyon ile başlayacaklardır.
Aşağıdaki durumlarda PVS kullanmak doğru bir seçim olabilir:
  • Hosted Shared veya Streamed fiziksel masaüstleri deploy etmek istiyorsunuz
  • 2500’den fazla masaüstüne ihtiyacınız var
  • Ortamınızın IOPS ile ilgili sıkıntıları var
  • NFS kullanmanız söz konusu değil

Nutanix NOS Upgrade

Normal şartlar altında bir bilgi işlem altyapısı kurmak istediğinizde server, storage gibi yatırımları ayrı ayrı yapmak durumundasınızdır. Bu cihazların kurulumlarını da ayrıca yapmak zorunda kalırsınız. Nutanix, bize Hyperconverged bir yapı sunuyor. Hyperconverged yapılar compute ve storage katmanını bir araya getirerek birleşik altyapı çözümleri sunar. Nutanix de bu yapıların öncülerindendir. Bu yazının amacı Nutanix NOS Upgrade olduğu için Nutanix ile ilgili daha fazla bilgi vermeyeceğim.
Nutanix’in her node’u üzerinde bir Controller VM (CVM) çalışır ve bu CVM’lerin kendi işletim sistemleri vardır. Bu işletim sistemine Acropolis Operating System (AOS) veya NOS denir. Nutanix belirli zamanlarda bu işletim sisteminin güncellemelerini yayınlar. Güncellemeleri yüklemek oldukça kolaydır. Güncellemeleri Nutanix’in Prism web arayüzünden yapıyoruz. Güncelleme işlemi sırasında vMotion yapılmaz, I/O kesintisi yaşanmaz, host’lar maintenance mode’a geçmez. Dolayısıyla Nutanix cluster içerisinde işler normal bir şekilde yürümeye devam eder. Güncelleme işlemini mesai saatleri içinde yapabiliriz. Ben de bu işlemi mesai saatleri içinde yaptım. Ancak her ihtimale karşı mesai saatleri dışında yapmak isteyebilirsiniz.
Benim çalıştığı ortam 6 adet Dell XC630 node’dan oluşuyor. Citrix XenDesktop ve XenApp çalışıyor. 400’ün üzerinde sanal masaüstü çalışıyor.
Upgrade işlemi oldukça kolaydır. Nutanix, internet bağlantısının olduğu durumda yeni versiyonları sürekli kontrol eder. Download butonuna tıklayarak yüklemek istediğimiz versiyonu indirip yüklemesini sağlayabiliriz. Ancak internet bağlantısının olmadığı durumlarda AOS’u başka bir yerden indirip Nutanix’e upload etmek gerekir.

Nos_Download

vSphere 6.0 What’s New – vMotion Enhancements

vSphere 6.0 ile birlikte vMotion tarafında da bir takım yeni özellikler geldi. vSphere 5.5 sürümü de dahil olmak üzere vMotion sadece aynı datacenter ve vCenter içerisinde mümkündü. vSphere 6.0 ile birlite artık vMotion sınırları aşarak farklı vCenter’alr ve hatta faklı datacenter’lar arasında sanal makineler taşınabilmektedir. vCenter Server’ın windows versiyonundan vCenter Appliance ‘a vMotion yapılabilmektedir. Bu işlemin tam tersi de geçerlidir. Bu yeniliklere bir bakalım: