Monthly Archives: October 2015
Network Sanallastirma ve VMware NSX
SDDC , SDN , NFV ve Overlay Network Kavramlari
Software Defined Data Center (SDDC) : Kisa ve oz olarak bir veri merkezindeki tum altyapinin sanallastirilmasi ve servis olarak satilabilmesidir. Altyapi olarak kasdettigimiz bilesenler , CPU/RAM (Compute/Islem Gucu) , Storage , Networking , Security -Guvenlik- (Firewall,IDS/IPS,DDOS)
Software Defined Networking (SDN) : Gunumuzun ihtiyaci artik herseyi sanallastirmak, merkezi bir noktadan yonetmek , programlayabilmek, gerektiginde ihtiyaca gore buyutebilmek veya azaltabilmek ve bunlari otomize etmek , bunlari yaparkende acik standartlar kullanmak ( OpenFlow keza bu acik standartlardan biridir ) , Multi-Tenancy saglamak , farkli servisleri birbiriyle entegre etmek (Firewall,IDS/IPS,DDOS,LoadBalancer) . Iste bu saydigimiz gereksinimleri “Network” bazina indirgedigimizde SDN bir deyim/yaklasim/framework oluyor.
Network Function Visualization (NFV) : Eger birsey resim ile anlatilabiliyor ise bu kesinlikle asagidaki resim olacaktir. Daha cok telekom alt yapilarinda gorulen ozel hardware ler uzerinde kosan sistem ve uygulamalarin bilindik x86 tabanli donanimlar uzerinde kosan , uygulamalarin sanal ortama aktarilmis halleri denebilir, sadece telekom alt yapisinin degil veri merkezlerinde kosan Firewall , IPS/IDS , DDOS , NAT , LB ve VPN servisleride ayni kapsamda sanallasmakta ve x86 tabanli donanimlar uzerinde kosmaktadir.
Overlay Networkler
Iki tip “Overlay Network” mevcut biri network tabanli digeri ise host/sunucu tabanli. Direkt networkle ilgilenen arkadaslar bilirler mesela Q-in-Q , MAC-in-MAC , TRILL , Cisco FabricPath , OTV network tabanli , VXLAN , NVGRE , GRE (Xen Server Citrix kullaniyor) ise host tabanli olanlari.
Yukarida gordugumuz tum “Overlay Network” tipleri encapsulation yaparak calisiyorlar. Bizim konumuz host tabanli overlay networkler oldugundan VXLAN dan bahsediyor olacagiz.
VXLAN bizim icin iki onemli problemi cozuyor olacak biri halihazirda veri merkezlerindeki 4096 olan VLAN limitini asmak digeride L2 domain ini L3 uzerinden tasiyaraktan verimerkezinde hem performans kazandirmak hemde farkli lokasyonlarda ayni L2 domain i kullanmak.
Overlay Network lerde bahsettigimiz encapsulation i yapmak icin mutlaka farkli bir interface olacaktir, ornegin ESXi nodelar uzerinde management,vMotion,vSAN interface lerine ek olaraktan VTEP adi verilen ek bir interface daha olacak, bu interface in farkli bir ip adresi olacak ve tum VTEP interface i olan ESXi node lar mutlaka birbirleriyle konusabilir birbirleriyle VTEP interface ler uzerinden erisilebilir olmalilar. Overlay networkler uzerinden konusamak isteyen sanal makineler eskisi gibi vSS/vDS uzerinden veriyi aktarmak istediklerinde VTEP interface araya girecek ve sanal makineden gelen orjinal L2 frame i encapsule edip bu paketi kendi VTEP portunden karisdaki VTEP portuna atacak, hedefdeki VTEP portu gelen bu paketi encapsule edip orjinal L2 frame i ilgili sanal makineye yine vSS/vDS uzerinden gonderiyor olacak.
Asagida ornek bir cizim var, sag taraftaki MAC2 mac adresli sanal makine MAC1 mac adresli sanal makineye ayni L2 domain inde ve IP networkunde olduklarindan direkt L2 frame i yollamak istiyor , Host 2 uzerindeki VTEP interface yesil olarak isaretlenmis orjinal paketin onune VXLAN header bilgilerini ekleyip Host1 in VTEP portuna gonderiyor, Host 1 decapsule edip paketi sanal makineye ulastiriyor.
Ornek VXLAN Paketi
Overlay networkler kendi dunyalarindan gercek dunyaya cikmak icin mutlaka bir GW e ihtiyac duyacaklardir , VMware ve NSX kapsaminda bu Edge Service Gateway olacaktir , Openstack bazinda bakarsaniz Neutron , Microsoft bazinda bakarsaniz NVGRE GW. Bu cihazlar sayesinde VPN , SSL VPN , LB , NAT , DHCP gibi NFV servislerini ilgili overlay network icersinde kosan sanal makinelere saglayacaklardir.
VMware NSX Nedir ?
VMware NSX in ne oldugunu anlatmak icin asagidaki resim ve yukarda ne oldugunu kisaca anlattigim SDN in mimarisinden alinti yapacagim.
NSX VMware in 23 Temmuz 2012 de satinalmis oldugu Nicira adli SDN odakli bir firmanin urunu ile VMware in kendi vNetwork Distributed Switch , VXLAN ve vShield Edge denilen NFV yaziliminin birlesiminin/uyarlamasinin son halidir. NSX kisaca bir “Ag Sanallastirma” yazilimidir amaci ESXi ile nasil sunucu sanallastirma ve storage sanallastirma saglaniyor ise artik sanallastirma yoneticisinin network bazinda ozgur, hizli , kolay , donanim bagimsiz , genisleyebilir/limitler daha yukarida ve esnek olmasina olanak saglar. Kullanilan kelimeler klise olarak gelebilir fakat bunlari biraz daha aciklar isek gelisi guzel soylenmedigini anlayacaksiniz.
Ben konuya bir servis saglayicisi gozunden bakacagim, siz sirket bazinda uyarlama yapabilirsiniz ;
Izolasyon dan basliyor hikayemiz ; Bir servis saglayici icin en onemli olan nokta, izolasyon diyince aklimiza once farkli ip adres bloklari (192.168.0.0/24 veya 10.5.5.0/24 gibi bu ip adresleri public veya private olabilir) bunlarin bir firewall ile erisimlerinin giris ve cikislarin kontrolu gelecektir. Bunu oncelikle network bazinda uyarlayacak olur isek bunun karsiligi VLAN olacaktir. Bir sistem muhendisi ve/veya sanallastirma uzmani veri merkezindeki switch leri yonetmediginden bu istegi network departmanina iletecektir , ilgili VLAN ilgili TOR/Aggregate/Core ve ESXi node larin portlarinda tanimlanacaktir daha sonrasinda ESXi node larin ilgill network interface in uyesi oldugu vDS e ilgili port profile tanimlanip , servis saglayicinin kullanmakta oldugu vmware in “Consumption” diyerek belirttigi portal in ornegin vCloud Director uzerinde tanimlanip (farkli yazilimlar kullanilabilir ozellesmis kendi portal leriniz olabilir ) musterinin vDC a network kaynagi olarak eklenmesi gerekecektir. Tabi bu surecler sirketlerin is akislarina gore degisiklik ve departmanlarin SLA surelerine gorede zaman acisindan tamamlanmasi farkli sureler alacaktir.
Yukardaki tanima gore “ozgurluk” kendi VLAN imi kendim yaratmam olacaktir, “kolaylik ve hiz” ise bunu efektif sekilde otomize etmem ve ilgili yerlere gerekli kayitlari otomatik olarak girebilmemdir. Yani ilgili islemleri otomize edebilmem. Burada NSX bazinda artik VLAN lardan cok az bahsedecegiz onun yerine VXLAN dan bahsediyor olacagiz.
Hikaye buradan devam ediyor ; Limitasyonlar, su anda bana hem zor hemde kolayca erisebilecegim iki limitasyon var, ilki kolay olsun su anda tum switch lerin sahip oldugu 4096 VLAN limiti ki bu sectiginiz switch e gorede farklilik yaratir genelde 1000 VLAN destekleyen switch ler mevcut 4096 icin daha iyi bir switch almalisiniz, bir servis saglayici icin kolay erisilebilir bir deger, 4096 VLAN izole edilmis 4096 musteri anlamina geldigi gibi eger bir musterinin 3 katmanli bir yapi kullaniyor ise -Web , Uygulama ve DB- bu durumda yuvarlak 1365 musteri anlaminada gelebilir.
Diger zor erisilebilir diye dusundugum sey ise switch lerin sahip oldugu MAC adres limiti. Bir sanal makineye eklenmis olan tum network kartlarinin bir MAC adresi olacagindan, eger switch MAC limitini asarsaniz bu durumda erisim olarak sikintilar yasamaya baslayacaksiniz ve kullandiginiz switch ve/veya switchleri daha buyuk MAC adresleri destekleyen cihazlarla degistirmeniz gerekecek. Ornegin Nexus 5000 ve 5500, sirasiyla max MAC address limiti 15000 ve 32000
Yukardaki tanima gore “genisleyebilir/limitler daha yukarida” 16 Milyon VLAN sayisina kadar genisleyebilme (artik adi VXLAN oluyor) ve MAC veri merkezinde NSX ile beraber hicbir MAC adresinin switchlerde gozukmeyecek olmasi bizim icin sadece genisleyebilirlik degil ayni zamanda TOR olarak ve/veya aggregate olarak kullanilacak switch lerinde seciminde bizi daha ozgur kilacagindan ayni zamanda “donanim bagimsiz” olmamizi saglayacaktir.
Vallaha bundan daha “esnek” olunabilir mi bilmiyorum, NSX ayni zamanda kendi sahip oldugu NFV ozelliklerine ek olarak diger ucuncu parti ureticilerle entegrasyon yaparak fonksiyonel olarak ekstra ozellikler kullanabilmenize yardimci olacaktir.
NSX e gecmeden once hazirlik olmasi acisindan once SDN mimarisine kisaca bir deginelim arkasindan bilesenleri yerine koymaya baslayacagiz ;
SDN Application : Network gereksiminlerini SDN Controller a ileten yazilimlar ; vCenter Server , vCloud Director, Openstack ve bir sirketin ic musterilerine veya servis saglayicinin kendi musterilerine sagladigi diger ozel web tabanli portaller olabilir.
Ornegin cok katmanli bir yazilima ihtiyac duyan biri yazilim firmasi web uygulamalari icin bir network , app icin farkli bir network ve veri tabani icin farkli bir network ihityaci olabilir ve bunu saglanan SDN Application uzerinde SDN Controller a istekte bulunabilir. (Bir yanlis anlasilma olmasin yazilim firmasi ona saglanan portal uzerinden istekte bulunuyor , portal kendi is akisi sayesinde SDN Controller a baglaniyor)
SDN Application bir API uzerinden konusur SDN Controller ile VMware SDN uygulamasinin kendisi ile REST API uzerinden konusmasini saglar.
SDN Controller (Control Plane) : SDN Controller SDN Application dan istekleri alir ve bunu kendisinin ve Data Plane in anlayacagi sekile cevirip gerekli islemleri yapar.
Ornegin VMware ortaminda vCloud Director portalini kullanan sirket/kisi (Bu arada vCloud Director portalini bilen yok ise bunu Amazon Web Services portali veya Microsoft Azure portali olarak dusunebilirsiniz) sag tus -> yeni network yarat der gibi veya “+” tusuna basip yeni network yarat diyerekten SDN Controller a istekte bulunabilir , SDN Controller da sanki network adminler switch ler uzerinde VLAN yaratiyormus gibi sanal izole networkler yaratabilir (VXLAN)
Controller, VMware in NSX Manager adi verilen ve bir sanal makine uzerinde kurulmus bir uygulama sayesinde yonetilir. Gorevi sadece VXLAN (izole networkleri yaratmak degil) ayni zamanda routing icin gerekli ve firewall islemlerinin icin gerekli surecleride yonetir , SDN Controller tum yapiyi bilir ve bu yapiyida bilmesi gereken tum alt bilesenlere iletir. Bunlari daha ayrintili olarak aciklayacagim.
SDN Data Plane : Cok ozet bir sekilde anlatmak gerekir ise sadece verinin gectigi katmandir , yani ESXi uzerine kurulan kernel modulu ve NSX Switch uzerinden gecen sanal makinelerinize ait olan trafik.
SDN den once birbiriyle tumlesik calisan Control ve Data Plane
SDN den sonra birbirinden ayrilan Control ve Data Plane ; Burada “Flow Table” diyerek anlatilan sey aslinda SDN sayesinde Data Plane artik sadece neyi nereye gonderecegini biliyor ve geri kalan hicbirseye karismiyor. Ornegin neye calismiyor kendi portlarina baglanmis olan sanal veya fiziksel makinelerin MAC adreslerini ogrenmeye , eger kullanilan switch L3 destekleyen switch ise routing bilgisini ogrenmeye calismiyor bunlarin hepsi SDN Controller uzerinden SDN Data Path e iletiliyor.
NSX Bilesenlerini Gosteren bir diaygram var asagida ;
Simdi bu diaygrami SDN Mimarisi uzerinden tanimlarsak
Ayni seyleri herkesin cok iyi bildigini tahmin ettigim Cisco switch ler uzerinden aciklamak gerekir ise ;
VMware uzerinde NSX Bilesenlerinin uzerinden gecmek gerekir ise ;
NSX Data Plane : NSX Data Plane var olan vDS uzerine kurulan 3 ayri kernel modulu ile olusur, bunlar esx-vxlan ki “VXLAN” destegini getirir , esx-vsip “distributed router” ve esx-dvfilter-switch-security “distributed logical firewall” modulleridir. NSX vSwitch fiziksel yapiyla sanal yapiyi ayirir ve hypervisor katmani artik access-layer switching servisini vermeye baslar yani bir Cisco line card gibi.
Kisaca tum verinin aktigi , akilli degil (herhangi switching ve routing karari vermez) ama bilgili ( neyi nereye yonlendirecegini bilir) olan katmandir.
NSX Controller : Control Plane NSX Controller Cluster uzerinde kosar, NSX Controller bu sistemin kalbidir diyebiliriz , tum logical switch yapisini bir noktadan yonetir ve tum altayapiyi ESXi hostlari, VXLAN ve distributed logical router bilgilerini tutar. Dagitik tasarlanmis bir yonetim sistemdir, arkada bildigim kadariyla Apache ZooKeeper kosmaktadir.
NSX Controller hypervisor uzerindeki switching ve routing modullerini yonetir, uzerinden veri trafigi gecmez , devamlilik ve erisilebilirlik icin uc node cluster dan olusur (daha fazla olabilir ama vmware tarafindan optimum sayisi uc olarak belirtilmistir), herhangi bir controller node unun veya tamaminin erisilemez olmasi veri trafigini etkilemez (sadece yeni logical switch ve routing bilgilerinin degismesi veya eklenme durumlarinda controllerlarin ayakta ve erisilebilir olmasi gerekir)
NSX Controller node lari NSX Manager tarafindan kurulur, gorevi sahip oldugu network bilgisini tum ESXi host larla paylasmaktir.
NSX Control Cluster uzerinde cesitli roller mevcut olup her biri icin bir master controller node ve slave node lar sistem tarafindan otomatik olarak atanmistir, olasi bir problemde master role farkli bir slave uzerinde master olarak aktive edilir ;
- API Provider : NSX Manager in NSX Controller a ulasabilmesi icin calisan web servisi, HTTP API
- Persistence Server : Cluster node lari arasinda “network state” verisinin ayni oldugunu garanti eder
- Switch Manager : Hypervisor lari yonetir, ilgili configrasyonlari hypervisor lara iletir
- Logical Manager : Network Topology sini ve policy leri hesaplar
- Directory Server : VXLAN ve DLR veritabani yonetir
Multicast , unicast ve hybrid adinda uc adet logical switch control plane mode diye bir kavramla karsilasagiz, bu mode lar BUM adi verilen Overlay network lerde Broadcast , Unknown Unicast ve multicast trafiginin logical switch icersinde nasil yorumlanacagi ve aksiyon alacagini belirtir.
Unicast Mode yeni eklenmis mode lardan biri , eger olasi bir BUM trafigi oldugunda ilgili VXLAN in uzerinde oldugu ESXi node un VTEP interface ine bu BUM istegi NSX Controller tarafindan yollanir. Herseyde oldugu gibi controller yerine bu isin switch hardware i tarafindan yapimasini istiyor ise o zaman switch lerimizin IGMP Snooping ve PIM Routing aktive edilmesi gerekir ki bu ekstra zorluk anlamina geliyor. Hybrid tahmin edebileceginiz gibi ikisinin karisimi , eger BUM trafigi VTEP lere iletilecek ise local de Unicast , local disinda Multicast yapilacaktir.
NSX Manager : Yonetim katmanini olusturu, tek bir noktadan merkezi yonetim saglar, vCenter ile birebir iletisimi vardir, NSX Manager kurulduktan sonra vCenter a tanitilmasi gerekir, ayni NSX Manager farkli bir vCenter a tanitilamaz, NSX 6.2 ile beraber cross-vCenter destegi gelmistir artik Primary NSX Manager ve Slave NSX Manager kavramlari yaratilmis olup ek olarak universal logical switch ve logocal distributed router tanitilmistir. Su andaki limitasyon bir NSX Manager a yedi secondary NSX Manager tanitilabilir.
NSX Edge : Eskiden NSX oncesi sadece vShield Edge olara bildigimiz GW servisi veren sanal makineler artik sadece GW servisleri degil routing servisleride vermektedir. Bunu icin NSX Edge derken artik Edge Service Gateway (ESG) ve Distributed Logical Router (DLR) olarak bahsedecegiz.
ESG overlay networklerdeki GW gereksinimini karsilar , bir ESXi host uzerinde maksimum 250 adet olabilir. Her ESG 10 interface e kadar uplink ve internet network bacagi olabilir eger trunk mode interface kullaniliyor ise 200 sub interface destekleyebilir. NAT , VPN ve load balancer icin birden fazla enternal ip adresi destekleyebilir.
DLR degisen uygulamalar hadoop,casandra,redis,MongoDB gibi artik trafikleri dikeyde degil , yatayda daha az hop gecerek veriyi daha hizli iletmemizi istiyorlar bunun icinde East-West denilen trafigin farkli bir sekilde yonetilmesi gerekiyordu bu da artik Hypervisor larin kernel ina yerlestirilen logical routing modulu sayesinde oluyor. Artik farkli ip subnet ler arasindaki trafigide DLR lar yonetiyor olacak.
DLR, ESG ye gore daha farkli dizayn edilmis bir yapi , sekiz uplink ve bin adet internal interface i olabilir , genelde bir ustde ESG ile konusur. Iki bilesenden olusur switching de oldugu gibi DLR Control Plane ve DLR Data Plane.
DLR Control Plane
- Sanal bir makine
- BGP ve OSPF destekler
- ESG ile routing bilgilerini degis tokus eder
- NSX Manager ve Controller ile iletisim halindedir
- HA destekler (Aktif/Pasif)
DLR Data Plane
- ESXi kernel modulu
- Line card gibi veri trafigi kernel dan gecer
- Layer 3 routing destekler
- Routing Table i tutar (NSX Controller tarafindan iletilmistir)
- Internel interface lere LIF (logical intereface) denir logical switch ve VLAN based port group baglanabilir
- Her LIF bir ip adresi atanir bu ip adresi defailt gw olarak kullanilir ilgili L2 Domain icin
- Tum LIF ler ayni vMAC e adresine sahiptirler
Asagida ornek bir yapi mevcut, sirasiyla ;
- NSX Manager DLR Control VM instance yaratilmasi icin tetikler
- NSX Controller ESXi host lara DLR configrasyonunu iletir LIF sayisi , IP bilgisi vMAC adresleri gibi
- DLR ESG ile OSPF veya BGP kullanara peering kurar . DLR ile ESG routing bilgilerini degis tokus eder. Networkculer bilir DLR directly connected olan yani LIF interface lerindeki networkleri bir uste anons ederler , ESG de dis networklere ulasmak icin gerekli IP Route bilgilerini DLR a gonderir
- DLR ogrendigi IP Route bilgisini NSX Controller ile paylasir
- NSX Controller bu bilgileri ESXi hypervisor iletir , kernel bazinda tum ESXi node lar neyi nereye route etmeleri gerektigini ogrenirler ve bu bilgiyi tutarlar
- DLR kernel module ayni zamanda ESG kullanaraktan dis veri trafigini isler.
NSX Servisleri
Logical Switch : NSX bize birden fazla Logical Switch yaratmamiza olanak saglar her bir Logical Switch esittir VLAN baska bir deyisle broadcast domain veya izolasyon demek. Ornegin cok katmanli bir projeniz var , Web , App ve DB katmanini birbirinden ayirmak istiyorunuz bu durumda eger ortaminizda NSX var ise bu demek oluyorki uc adet logical switch yaratacaksiniz.
Yeni gelen cross-vCenter ozelligi sayesinde farkli cografi lokasyonda ayni broadcast domain i devam ettirebilirsiniz.
Logical Router : VMware logical router i farkli L2 Broadcast domain ler arasinda forwarding yapmak seklinde yorumluyor , biz genelde buna iki farkli IP networkunu veya subnet i biribir ile konusturma olarak adlandiriyoruz. Logical router sayesinde artik Bati-Dogu duzleminde yani yatayda nokta atisi yaparak veri trafigini akitabiliyoruz. Bu bize daha fazla hop gecemeden, daha efektif VM to VM iletisim anlamina geliyor. Tabi logical router sadece yatayda degil eger ESG ile veya bir ust katmanla arasinda bir iliski var ise Kuzey-Guney duzleminde veya dikey olarakda iletisime gecebilir.
Logical Firewall : NSX yine hypervisor kernel bazinda calisan , dagitik, vCenter uzerindeki tum obje lere gore (datacenter, resource pool, VM Name) kural yazabilieceginiz , vNIC bazinda uygulanan , vMotion destekleyen bir guvenlik mekanizmasidir.
Flow Monitoring ozelligi sayesinde sanal makinenin hangi uygulamalarla iletisime gectigini izleyebilir ve bu bilgileri kullanarakdan firewall policy leri tekrardan duzenleyebilir , yenilerini ekleyebilir , auditing yapabilir , tehlikeleri tanimlayabilirsiniz.
Service Composer : NSX ile beraber bir kisim servisi bir kisim sanal makineye direkt uygulayabilirsiniz. Security Group icersine VM leri , Servisler icersine firewall kurallari , AV ve PCI Compliance end-point veya IPS gibi servisleri grouplayarakdan bir VMware in Service Composer dedigi seyi yaratiyoruz boylece ilgili servisler ilgili vNIC ve VM lere uygulaniyor.
Ucuncu Parti Yazilimlarlar NSX Genisleme : NSX tum sorunlariniza cevap verecek durumda degil , firewall bazinda L4 kadar yardimci olabiliyor , NSX kendi basina size IPS/IDS servisi veremez veya bir F5 veya Netscaller capinda LB servisi saglayamayabilir fakat bunlari yapabilmeniz icin size bir yontem sunar , ilgili servisler icin ilgili ucuncu parti donanim veya yazilimlara yonlendirme yapabilir.
En cok bilinen ve uyarlanmis urunler PaloAlto , F5 , Rapid 7 gibi firewall , load balance ve PCI servisleri mevcut. Daha fazla bilgi icin https://featurewalkthrough.vmware.com/#!/nsx/nsx-partner-integration-1 adresini kullanabilirsiniz.
Guzel Linkler
Click to access SDN-architecture-overview-1.0.pdf
https://www.opennetworking.org/sdn-resources/technical-library
Auto Deploy
Auto Deploy Nedir ?
Yuzlerce ESXi node u hizli ve problemsiz standart bir sekilde kurmaniza olana saglar. Stateless veya Stateful destekler ister iseniz ESXi direkt memory e veya node un diskine imaji koyabilirsiniz. Herhangi configrasyon host uzerinde tutulmaz tum konfigrasyon gereksinimleri “Host Profile” sayesinde gerceklestirilir.
Ozel bir HA opsiyonu yok , Auto Deploy ile kurulmamis yonetim/management cluster inda Cluster level HA aktive edilmis durumda olmasi yeterli.
Guvenlik olarak Auto Deploy dosyalari SSL uzerinden yollar fakat PXE boot icin ayri bir network ve verimerkezinizdeki ve/veya isyerinizdeki farkli bir PXE boot sistemi ile karistirmamaniz onerilir.
Auto Deploy Server
Imaj ve Host Profilleri saglar
PXE
Network boot
Image Builder CLI
vSphere kurulumlari icin gerekli olan zip ve iso dosyalarini yaratmanizi , gerekli oldugu durumlarda 3. parti VIB lerin kullanarak ozellestirilmis kurulum dosyalarini yaratir.
Auto Deploy Rule Engine
Hangi imaj profilin hangi host profile ile iliskilendirilecegini ve bunun icin gerekli kosullari belirtir. PowerCLI uzerinden konfigre edilir
PowerCLI
Powershell uzeriden vCenter i yonetmek icin kullanacagiz
Cesitli blog yazilarinda “First Boot” ve “Subsequent Boot” diye tanimlar ve isimlendirmeler goreceksiniz, Auto Deploy ile henuz provision edilmeyen hostlar “First Boot” daha sonra Auto Deploy yapilmis ve vCenter a eklenmis olanlar “Subsequent Boot” olacak.
Auto Deploy Servisini dort farkli sekilde kullanabilirsiniz ;
- vCenter Server VCSA uzerinde Auto Deploy Server
- vCenter Server VCSA ile Auto Deploy Server Windows uzerinde
- Auto Deploy server VCSA uzerinde fakat vCenter Server farkli bir VCSA uzerinde
- Auto Deploy server VCSA uzerinde fakat vCenter Server Windows uzerinde
Once TFTP server kuralim (Asagidaki kurulum Ubuntu icindir)
noroot@ubudhcpdns:/etc/xinetd.d$ sudo apt-get install xinetd tftpd tftp
TFTP icin xinetd config dosyasini guncelleyelim
noroot@ubudhcpdns:/etc/xinetd.d$ sudo vi /etc/xinetd.d/tftp
Simdi gerekli config bilgilerini olusuturalim
service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}
Ilgili dizine gerekli haklari verelim
noroot@ubudhcpdns:/etc/xinetd.d$ sudo mkdir /tftpboot
noroot@ubudhcpdns:/etc/xinetd.d$ sudo chmod -R 777 /tftpboot
noroot@ubudhcpdns:/etc/xinetd.d$ sudo chown -R nobody /tftpboot
Service Restart edelim
noroot@ubudhcpdns:/etc/xinetd.d$ sudo service xinetd restart
xinetd stop/waiting
xinetd start/running, process 3137
Auto Deploy u vCenter a kaydettirelim ve servisi calistiralim
Command> shell.set –enabled True
Command> shell
———- !!!! WARNING WARNING WARNING !!!! ———-Your use of “pi shell” has been logged!
The “pi shell” is intended for advanced troubleshooting operations and while
supported in this release, is a deprecated interface, and may be removed in a
future version of the product. For alternative commands, exit the “pi shell”
and run the “help” command.The “pi shell” command launches a root bash shell. Commands within the shell
are not audited, and improper use of this command can severely harm the
system.Help us improve the product! If your scenario requires “pi shell,” please
submit a Service Request, or post your scenario to the
https://communities.vmware.com/community/vmtn/vcenter/vc forum and add
“appliance” tag.localhost:~ #
->
localhost:~ # autodeploy-register –register -a 10.111.31.15 -u administrator@sso.domain -w **********
Successfully registered autodeploy with vCenter 10.111.31.15
localhost:~ # service vmware-rbd-watchdog restart
Stopping /usr/bin/rbd-watchdog-linux: done
Starting /usr/bin/rbd-watchdog-linux: done
vCenter Web Client dan kontrol edelim
“Download” dugmesine basip ilgili “zip” dosyasini indirin ve acin, daha sonra yukarida kurdugumuz TFTP server in ilgili dizinine yerlesitirin.
noroot@ubudhcpdns:/tftpboot$ ls -al
total 780
drwxrwxrwx 2 nobody root 4096 Oct 6 14:25 .
drwxr-xr-x 26 root root 4096 Oct 5 16:25 ..
-rw-r–r– 1 noroot noroot 11 Oct 6 14:25 snponly64.efi
-rw-r–r– 1 noroot noroot 11 Oct 6 14:25 snponly64.efi.vmw-hardwired
-rw-rw-r– 1 noroot noroot 4 Oct 5 18:57 test
-rw-r–r– 1 noroot noroot 106 Oct 6 14:25 tramp
-rw-r–r– 1 noroot noroot 118690 Oct 6 14:25 undionly.0
-rw-r–r– 1 noroot noroot 118690 Oct 6 14:25 undionly.kpxe
-rw-r–r– 1 noroot noroot 83788 Oct 6 14:25 undionly.kpxe.debug
-rw-r–r– 1 noroot noroot 90186 Oct 6 14:25 undionly.kpxe.debugmore
-rw-r–r– 1 noroot noroot 118693 Oct 6 14:25 undionly.kpxe.nomcast
-rw-r–r– 1 noroot noroot 118696 Oct 6 14:25 undionly.kpxe.vmw-hardwired
-rw-r–r– 1 noroot noroot 118714 Oct 6 14:25 undionly.kpxe.vmw-hardwired-nomcast
DHCP tarafinda ek konfograsyona ihtiyacimiz olacak bunla berbare sunuclarda PXE boot ethernet icin aktif olup olmadigini kontrol edin
# vCenter Site A Mng Block
subnet 10.111.31.0 netmask 255.255.255.0 {
range 10.111.31.100 10.111.31.150;
option routers 10.111.31.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.111.31.255;
option domain-name-servers 8.8.8.8;
next-server 10.111.31.3;
option bootfile-name “undionly.kpxe.vmw-hardwired”;
}
Ek olarak asagidaki linkden https://10.111.31.15:6501/vmw/rbd/ (siz kendi ip adresinizle guncelleyin) “Debugging” ekranina erisebilirsiniz
Not : Burada onemli olan konulardan biri Auto Deploy server tek bir vCenter a register olmali ayni Deploy Server birden fazla vCenter icin kullanilamaz.
Simdi PowerCLI dan vCenter Server a baglanip var olan Imaj ve AutoDeploy kurallarina bakalim (Herhangi bir Windows makineye .Net ve Vmware PowerCLI kurululmus olmali)
Komutlar
Get-EsxImageProfile
Get-DeployRule
Gordugunuz gibi herahangi bir ESXi node un boot edecegi imaj ve imaj/host profile iliskisini kuracak bir kural henuz mevcut degil
Elimizdeki sunucularin ozelliklerini bulalim , buna gore Imaj lar yaratacagiz. Burada ayni vendor , hardware ve ip blogu ile ayrim yapilacak tabi sadece bunlar degil MAC adresine gore, BOIS UUID gibi bir suru opsiyon var “bakiniz sayfa 75”
Get-VMHost 10.111.31.100 | Get-VMHostAttributes
Simdi Auto Deploy ile kullanmak icin “ESXi Offline Bundle” indirelim , icersinde gerekli VIB, ESXi icin Imaj Profili ve VMware Tools mevcut.
Buradan bir cikarima gitmek gerekir ise ayni “ESXi Offline Bundle” HP, Dell gibi vendor lar alip kendi driverlari icin gerekli VIB leri ekleyip ESXi Image Builder ile iso export lar yaratip kendileri bu ozellestirilmis imajlari dagitiyorlar
Download ettigimiz dosyayi “C:\imagefolder” altina koydum “Add-EsxSoftwareDepot” ile imaj deposunu olusturuyorum
Add-EsxSoftwareDepot C:\imagefolder\update-from-esxi6.0-6.0_update01.zip
Yukarida gordugunuz gibi ESXi imajlari geldi ;
- Standard olan –VMware Tools– iceren version
- -no-tools –VMware Tools– icermeyen version
- ESXi-6.0.0-20150901001s , buradaki “s” security update olarak geciyor yani 6 dan 6 update 1 gibi
Burdan sonra eger bir ozellestirme yapicaksaniz “New-EsxImageProfile -CloneProfile” kullanabilir veya bos bir profil bile yaratabilirsiniz
Asagida tanimaldigimiz depo ve bu depolardaki tum paketler version ve tarihleri ile mevcut
“Get-EsxSoftwareDepot”
“Get-EsxSoftwarePackage”
Eger imaj bazli paketleri gormek isterseniz asagidaki komutu kullanabilirsiniz.
“Get-ESXImageProfile Profil_Adi | select -ExpandProperty viblist”
Eger ozellestirme yapacaksaniz depo a ya “Add-EsxSoftwarePackage” ile paket ekleyebilir , “Remove-EsxSoftwarePackage” ilede cikartabilirsiniz.
a
Simdi Sunucuyu Boot Edelim ;
Oncesinde aklinizda olsun -Set-DeployOption “vlan-id” 860- diyerekten default management vlan set edebilirsiniz
Bu opsiyon sadece “host profile” olmadiginde kullanacaktir, eger host profile i iliskilendirirseniz bu opsiyon zaten kullanilmayacaktir.
Bilerek bir hata yaptim acaba hata nasil goruluyor diye buna bir ornek asagida , goruldugu gibi ilgili host a match eden bir profile yok.
Simdi o zaman asil konfigrasyona gecelim en azindan VMware in bir boot ettigini gorelim. Asagidaki ornekte ortamda baska tip makine olmadigindan sadece vendor=HP olmasini ariyorum
New-DeployRule -Name “FirstTimeBoot” -Item “ESXi-6.0.0-20150902001-standard” -Pattern “vendor=HP”
Not: Burada ek soylenecek birsey var ise “-Item” kismi isterseniz “,” yardimiyla cluster , Host Profile tanimlarinida bir satirda yapabilirsiniz. Host Profile i “” arasina almaya gerek yok
Simdi aktive edelim, bakalim vSphere 6 yeni node uzerinde boot edecek mi ?
Evet guzellll …..
Yukardaki ekranda ilgili hyper-link e bastigimizda daha fazla bilgiye erisebilisiniz, ornegin henuz bu vmware node a “Host Profile” eklemis degiliz
Esxi boot etmeye devam ediyor …
Boot tamamladi , vCenter a da bir goz atalim
Burada deployment rule lar ile ilgili onemli birkac nokta var ;
- Birden fazla deployment rule ilgili tek bir host a match edebilir bu tip durumlarda siralam onem kazanir, baska bir deyisle altta kalanin cani ciksin hesabi 🙂 Ornegin iki deployment rule var ve her birinde farkli “Host Profile” mevcut bu durumda yukarda olanin “Host Profile” i gecerli olur
- Diger bir kullanim seklinde yine birden fazla deployment rule olabilir fakat biri “Image Profile” digeride “Host Profile” olabilir bu durumdan her ikisi birden uygulanir
- Deployment rule larda degisiklik yapmis olabilirsiniz bunlari hemen uygulamak isteyebilirsiniz (veya ilgili ESXi node degisiklik yapmaniza ragmen dogru host profile dan acmiyor olabilir) bu durumda asagidaki komutu kullanabilirsiniz (Degisiklikler node reboot sonrasi devreye girecektir)
C:\PS> Get-VMHost h1 | Test-DeployRuleSetCompliance | Repair-DeployRuleSetCompliance
Simdi asagida iki farkli kural giriyorum
New-DeployRule -Name “Cluster” -Item “Compute_Cluster” -Pattern “vendor=HP”
New-DeployRule -Name “HostProfile” -Item “Compute-Base100” -Pattern “vendor=HP”
Add-DeployRule Cluster
Add-DeployRule HostProfile
Bu arada Test-DeployRuleSetCpmliance kullanalim
Test-DeployRuleSetCompliance 10.111.31.106
Uygulayalim da onuda kullanmis olalim
Test-DeployRuleSetCompliance 10.111.31.106 | Repair-DeployRuleSetCompliance
Simdi birde webden sunucunun durumuna bakalim https://10.111.31.15:6501/vmw/rbd/host/a02cc14f4b57f9e67c1839c0a54002dd/
Simdi reboot ! Gordugunuz gibi “Host Profile” uygulaniyor
Kullandigim HP Gen8 de PXE boot vlan destegini bulamadigmdan , sunucu portlari trunked oldugundan ne yazikki management tarafina profile daki vDS ayarlarindan dolayi dogru ip i alip %100 islemi bitiremedi fakat yinede bulundugu cluster ve sekil acisindan herseyi gostermis oldu.
Herkese kolay gelsin
VM
Guzel Linkler ;
VIB Nedir ? https://blogs.vmware.com/vsphere/2011/09/whats-in-a-vib.html
Image Builder CLI Kullanmak ? https://www.youtube.com/watch?v=MgGMMZxfyUQ
Scripted ESXi Installation ? https://www.youtube.com/watch?v=5UlSqweiIqI
Understanding Auto Deploy ? http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2005131
TroubleShoot ? http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2000988
vSphere Auto Deploy Demo (vSOM) ? https://www.youtube.com/watch?v=G2qZl-760yU
Using the vSphere ESXi Image Builder Profile ? https://blogs.vmware.com/vsphere/2012/04/using-the-vsphere-esxi-image-builder-cli.html
vSphere Installation and Setup ? https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-installation-setup-guide.pdf
http://www.vclouds.nl/auto-deploy-how-to-pxe-boot-without-the-use-of-native-vlan/
DHCP ? http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2005071
http://www.vladan.fr/vmware-vsphere-autodeploy-run-powerclis-youre-boss/
VXLAN Auto Deploy ? http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2092871
Host Profile vSphere 6 ESXi
Merhaba ,
Bu gune kadar host profile hic kullanmadim , aslinda cok da faydali fakat elle isledi hersey. Asagida test icin kurdugum sistemde nasil faydali olabilir diye iki adimda test ettim.
Birinci adim NTP , Syslog , NFS mount , servis gibi ayarlari host profile ile diger node a nasil aktariyoruz bakalim ;
Asagida gordugunuz gibi iki node var , 10.111.34.100 ve 10.111.34.101 .
10.111.34.100 node unu baz aliyoruz. Bu node uzerinde NTP , Syslog (Log Insight), NFS mount ( 3 adet ISO ve diger iki datastore) ve SSH servis calisir durumda.
Cluster icin Datastore HA ayarli , 10.111.34.100 makinesine iki adet NFS Store mount edilmis durumda
Once baz aldigimiz makineden Host Profile i export edelim
Bir isim ve aciklama girelim, daha sonra Next ve Finish
Export u bekleyelim
Ana ekrandan Policies and Profiles i bulalim
Export edilen profili edit ledigimiz de ilgili ayarlari goruyor olacaksiniz mesela NFS, Syslog ayarlari
Simdi bu profili var olan diger node a atayalim
Profile uyuyor mu uymuyor mu kontrol ettirelim
Ve uygulayalim
Next
Kisa bir gozden gecirme ve Finish (Bu arada match etmeyen local disk bilgileri var bunlari profilden oncesinde cikartabilirsiniz. Cok problem degil sadece “compliance” gozukmeyecek ama yinede duzeltmekte fayda var)
Ornegin Export a baktigimizda local disk bilgileri Storage configuration” altinda “PSA Configuration” ve “NMP” altinda olacak. Burada vmware in guzel bir makalesi var eger ihtiyaciniz olur ise http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2002488
Bir dizi task calistigini goreceksiniz
Daha onceden belirttigim gibi profile atanmis node larin uyumlulugunu kontrol edebilirsiniz
Simdi 10.111.34.101 i kontrol edelim
Ikinci Adim Network Ayarlari
Asagidaki export ciktisida uygulanacak makineye ilgili vDS ayarlarini yapiyor olacak
VM
Cross vCenter Server vMotion in Action
Merhaba ,
Cross vCenter Server vMotion destegi sayesinde sanal sunuclarimizi farkli lokasyonsaki veya ayni lokasyondaki vCenter Server lar arasinda hem compute hemde storge bazinda tasiyabilecegiz.
Asagidaki ornekte oldugu gibi iki lokasyonumuz mevcut biri Istanbul diger ise Antalya. Istanbulda iki adet cluster var biri compute (sanal sunucularimizin kosacagi havuz) diger ise vDC ve NSX ortami icin hazirladigim edge cluster . Su anda “edge cluster” in bizim icin bir onemi yok. Onemli olan Istanbulda compute cluster inda olan bir VM in “CrossvCenterExampleUbuntu” Antalya daki “compute cluster” a vMotion yapilmasi.
Bu ornekte vMotion icin kullanilan network kartlari farkli VLAN larda ve TCP/IP Stack olarak vSphere 6 ile gelen “vMotion” kullaniliyor. Bu ozellik sayesinde artik sadece L2 seviyesinde degil L3 seviyesinde yani route edilebilen networkler arasinda vMotion yapilacak. Benim yaptigim test de ilgili cografi alanlar sadece mantiksal ve ip blok lari farkli olacak sekilde ayarlanmistir. vMotion TCP/IP Stack aktive ettiginizde artik “Default” TCP/IP Stack kullanan VMKernel port vMotion icin kullanilmaz olacak tum vMotion islemleri yeni set edilen VMKernel arabirimi uzerinden isleyecek.
vSphere6 ile beraber gelen yeni ozelliklerden biride “Long Distance vMotion” ki bunu icin yeni bir TCP/IP Stack olarak “Provisioning ” geliyor. Ilgili TCP/IP Stack “Cold Migration/Snapshot/cloning” kullaniliyor, bu katman NFC (Network File Copy) icin kullaniliyor baska bir deyisle dosyadan haberdar olan FTP 🙂 . Burada ek olarak birkac onemli nokta var ;
RTT (round-trip time) surest ki 150 ms gecmemeli
vSphere 6 Enterprise Plus Lisa’s
ve yukarda belirttigimiz gibi vmkernel port un Provisioning TCP/IP stack olarak tanimlanmasi.
Simdi bildigimiz “Migrate” islemini yapiyoruz.
Onemli olan konu ; eger sadece “compute” tasinmak isteniyor ise hem hedef hemde kaynagin ayni datastore u gormesi sart , eger farkli datastore lara sahip iseler hem storage hemde compute tasinmasinin beraber yapilmasi gerekiyor. Asagida sadece compute sectim fakat hedef noktasi farkli bir datastore kullandigi icin oncesinde data tasimasi yapicak bunu size birazdan gosterecegim.
Klasik nereye tasiyacagimizi belirtiyoruz
Hedefte hangi datastore a tasiyacagimizi belirtiyoruz
Tati network, istanbuldaki COSMOS network uni yine ayni ip blogunda calisan COSMOS Antalya network une tasiyacagim.
Burayi NSX kullanarak gostermek istiyordum fakat simdilik her iki noktadan ayni network u anons ederek tasima yapacagiz ve gecis sonrasi erisimler kaldigi yerden devam edecek.
Baslayalim
Evet, tasima islemi basladi
Istanbul ve Antalya cluster larina ayni NFS Sunucudan farkli partitionlari mount etmistim vSphere hostler, onlarin durumuna bir goz atalim . Gordugunuz gibi sdb partition inindaki Datastore dan sdc e super bir akis var.
Ping lerdeki durum , iki ufak kayip var
Ve yeni gorunum, hersey tamam !
Guzel !
Cross vCenter Server vMotion Gereksinimleri
Cross vCenter Server vMotion icin gereksinimler ;
- Iki lokasyondada vSphere 6 ve ustu olmasi lazim
- Long Distance ve vCenter lar arasinda gecis yapabilmek icin Enterprise Plus lisansiniz olmali
- Her iki vCenter ayni SSO etki alaninda ve Enchanced Linked Mode sekilde konfigre edilmis olmali
- Fakat fakli bir durum daha var API ve SDK kullanilarak bu is yapilacak ise farkli SSO etki alanlarinda olunabilir 🙂 Ilginc, allah tum proje yoneticileri ve yazilimcilardan korusun bizleri 🙂
- Saat ler sync olmali , ntp ntp ntp
- Sadece compute kaynaklarini tasimak istiyorsaniz her iki vCenter ayni storage kaynagina erisebiliyor olmasi lazim.
Ornek Yapi :
Bu yapi hem Cross vCenter Server vMotion hemde Multi Site NSX Cross vCenter kurulumlari icin kullanilacaktir. Grafik zaman icersinde guncellenebilir veya baz alinip farkli makalelerde kullanilabilir.
Su anda dikkat edilmesi gereken konu artik vMotion network u hem istanbuldaki clusterlar, hemde Antalyadaki cluster arasinda ayni L2 Domain de (ayni vlan da) degil. vSphere 6 ile beraber L3 bazinda routed bir network uzerinden (bir router veya firewall sayesinde OSPF/BGP ve/veya firewall vlan interface leri arasinda ) vMotion yapabilme ozelligi geldi hatta VMware artik vMotion icin farkli bir TCP/IP yigini kullanmaniza olanak sagliyor bu ozelligi kullanabilmek icin. Tek dikkat etmemiz gereken konu vMotion networklerinin birbirine ulasabiliyor olmasi.
Yeni vMotion network stack
Enchanced Linked Mode Konfigrasyonu (Fedaration/Federasyon) ;
Bir onceki makalelerde bir adet PSC ve VCSA 6 kurulumunu gostermistim , simdi buna eklenti yapacagiz. Bu daha hizli olacak.
Tekrardan PSC/VCSA kuracakmis gibi “vcsa-setup.html” dosyasini cift tiklayin ve yeni yaratacagimiz PSC icin isim ve kullanici bilgilerini tanimlayin
Antalaya tarafi icinde bir PSC kurmaya calisacagiz
Microsoft AD yapisinda birden fazla domain controller yaratiyormus gibi SSO etki alanina ikinci bir PSC ekliyoruz
istanbul site imiz var idi birde antalya site ini yaratacagiz
Static IP set ettik , NTP tekrardan dikkat kurulumda erisilemez veya ilgili network e bir restriction uygulanmis ise NTP ayari yapilamayacagindan kurulum hata verecektir
Kurulumu tamamlayin ve “vcsa-setup.html” dosyasini cift tiklayip VCSA yi kurmaya baslayalim
VCSA VM adini ve vCenter Server kuracagimizi belirttikten sonra
Antalya bolgesinde calisacak PSC e ve ilgili SSO etki alanina kayit olalim ve kurulumu bitirelim.
Bu islemler bittikten sonra “Web Client” i kapatip acalim , goredugunuz gibi iki adet vCenter tek bir ekranda erisilebilir durumda. Henuz antalya tarafinda bir kaynak yok , onuda vMotion sirasinda gorecegiz. Dikkat ederseniz herhangi bir vCenter uzerinde “Related Objects” kisminda “Linked vCenter Server Systems” altinda baglantili oldugu diger vCenter mevcut artik vMotion icin asagi yukari haziriz , yeni bir cluster yaratip antalya tarafina ekledikten ilk denemeyi yapacagiz.
vCenter 6 PSC ve VCSA Kurulumu – Artik MSSQL ve Windows a Gerek Yok
Merhaba ,
Artik sadece ve sadece VCSA (vCenter Server appliance) kurulumu icin bir windows makineye ihtiyac var, umarim yakin zamanda MAC uzerindende kurulum islemlerini yapabiliyor olacagiz benim gibi MAC kullanan arkadaslar icin daha da iyi olacak 🙂 VCSA ve PSC hakkinda bilgi icin bakiniz ->
VCSA artik bir iso dosyasi olarak ve direkt ESXi node a veya cluster a direkt kurulumu yapilabilecek bir installer ile beraber geliyor. MyVMware hesabinizdan direkt indirip bir Windows isletims sistemli makinede iso you mount edin.
Oncelikle mount ettiginiz iso dosyasinin icersondeki “vcsa” kalsorune girerkten “VMware-ClientIntegrationPlugin-6.0.0.exe” calistirip kurun.
Ardindan “vcsa-setup.html” dosyasini cift tiklayin PSC/VCSA kurulumuna baslayalim.
Karsiniza kurulum programi cikacak , su anda sifir bir kurulum yapacagimizdan “Install” dugmesine basip gecelim.
Klasik “agreement” devam ….
10.111.31.2 benim VCSA yi uzerine kuracagim ESXi node, gerekli kullanici bilgilerini girip devam edin
YES !!!
Once PSC kosacagi sanal makineyi kuracagiz, ayrintilar asagida ve ilgili link de VCSA ve PSC hakkinda bilgi icin bakiniz ->
Guzel bir kisim burasi, kucuk kurulumler ve birden fazla vCenter in ayni ekrandan yonetilmeyecegi, Enhanced Linked Mode kullanilmayacagi durumlarda “Install vCenter Server with an Embedded” secenegini secmek yeterli fakat benim yapacagim kurulum “Multi Datacenter NSX” ve “Cross vCenter vMotion” gereksinimlerinden dolayi “External Platform Service Controller” -> “Install Platform Services Controller” secenegini secip oncelikle PSC i kuruyor olacagim.
VCSA ve PSC hakkinda bilgi icin bakiniz ->
SSO (Single Sign On) Microsoft AD yapisini bilenler hemen uyanacaktir, AD nin VMware cesini kuruyoruz PSC ile 🙂
Site olarak ilk kurulumda “istanbul” set ettim domain name olarakda “sso.domain” haliyle bundan sonra loginler administrator@sso.domain seklinde olacak
Oldukca az kaynak harciyor gibi duruyor 🙂 Bu arda bir tanidigimizin lafi aklimdan hic cikmiyor “Ama bu LDAP dedim ! ” :)))
Bir sonraki ekranda “Datastore” u secip devam edin , isterseniz “Thin” seceneginide secip devam edebilirsiniz
VCSA nin bagli olacagi management networkunu ve ip adresini set edin , benim ortamimda bir DHCP server ve time server var.
Statik ip verebilirsiniz , time server aman olsun ve tum yapi ayni NTP server i kullansin, VMware bunun uzerine cok dusuyor, hakli oldugu case lerde var bastan ayarlamakta fayda var. SSH enable ettim , login olup bakmamiz gereken seyler olacaktir ama simdi degil bu sadece kurulum dokumani.
Ilgili ESXi node uzerinde hazirladigim , DHCP , NTP ve NFS server olan bir makine var kurulum adimlari icin bu dokumani kullanabilirsiniz.
Asagidaki ekranda statik olarak tanimlanmis hali , ortamda DHCP yok ise ve farkli bir NTP sunucu kullanacaksaniz proxy lik yapmak istemiyorsaniz elle tanimlayabilirsiniz herseyi
FQDN kullanmak icin dns ayarlamalarinizi onceden yapmalisiniz, NTP verdigi uyariyi gecebilirsiniz eger tum network erisimleriniz tamam ise.
Simdi bastan asagi bir kontrol ve ileri
Asagidaki gibi birkac kurulum ekrani ornegi mevcut, bittiginde “Close” dugmesine basip cikabilirsiniz.
Simdi sira geldi vCenter Server i kurmaya , “vcsa-setup.html” dosyasini tekrardan cift tiklayin simdi VCSA yi kuracagiz.
Direk 3. adimdan basliyorum gerekli isim ve kullanici adi/sifresini atayip ilerleyin
Artik bir PSC mevcut ve vCenter i buna baglayacagiz
SSO ayarlari , domain a join ediyoruz vCenter Server i 😀
Test yapacagiz en dusuk kaynakli sunucu bilgilerini secsek yeter
Tekrar VM in kurulacagi “Datastore” u secin
Networking ve NTP ayarlari
Kisa bir ozet
Kurulum devam ediyor , bittiginde ekrani “close” diyerek kapatin
Simdi bir login olalim
Tamamdir
Hazirlamakta oldugum “Cross vCenter vMotion” makalesine bu makalede kaldigim yerden baslayacagim , burada sonuc olarak PSC , SSO ve ilk vCenter kurulumlarini tamamlamis oldum.
VM
Platform Service Controller ve VCSA Hakkinda Genel
Merhaba ,
VMware vCenter 6 versionu ile beraber artik iki farkli bilesende olsuyor ; vCenter Server ve Platform Service Controller(PSC)
Tum bildigimiz standard servisler vCenter Server da ve diger servisler ise PSC de toparlanmis durumda.
PSC Bilesenleri ;
- VMware Appliance Management Service (only in Appliance-based PSC)
- VMware License Service
- VMware Component Manager
- VMware Identity Management Service
- VMware HTTP Reverse Proxy
- VMware Service Control Agent
- VMware Security Token Service
- VMware Common Logging Service
- VMware Syslog Health Service
- VMware Authentication Framework
- VMware Certificate Service
- VMware Directory Service
PSC iki sekilde kurulabiliyor embeded ve external olarak. External kurulumlar sayesinde birden fazla vCenter Server yukardaki servislere ortak erisebiliyor. Haliyle vCenter larin kurulum asamasinda ilgili PSC lere katilmasi gerekiyor. Site kavramlari ve domain kavramlari mevcut.
Artik sadece vCenter degil ayni zamanda PSC nin de devamliliginin dusunulmesi gerekiyor. Yukarida ornek bir yapi mevcut ki bu yapi Cross vCenter vMotion ve NSX Multi Site yapisi icin kullanilacak.
PSC de yedeklilik aslinda otomatik , site lar arasinda replikasyon otomatik olarak tanimlaniyor , eger bir site icersinde birden fazla PSC kurmak istiyorsaniz mutlaka VMware in sagladigi bir script ve load balancer a ihtiyaciniz olacak. Load balancer olarak F5 kullaniyorsaniz PSC F5 , Netscaller kullaniyorsaniz PSC Netscaller linklerini takip edin. Benim F5 hakkinda bir bilgim yok fakat Netscaller konfigrasyonunu kontrol ettigimde NGINX veya HA Proxy ile de cok rahat kullanilabilir , VMware in ESG (Edge Security Gateway – eski adiyla vShield Edge) lerde kullandigi bildigim kadariyla kendisinin de gelistirilmesinde yardimci oldugu HA Proxy neden desteklenmiyor veya link lerde paylasilmamis bilmiyorum.
Eger bulundugu site icersinde PSC leride HA seklinde kurmak isteyen var ise lutfen bu PSC HA kullanin. Neden bir site icinde yedekli kurmalisinizin cevabi eger PSC olmaz ise vCenter a login olamazsiniz. Eger “Enhanced Linked Mode” kullaniyorsaniz vCenter i farkli bir PSC e register etmeden login olamazsiniz.
PSC herhangi bir ekstra lisans’a tabi degil, ayri bir sanal makine olarak kuruldugunda fazla kaynak yemiyor (2vCPU,2GB Ram,4GB Disk,1 Gbit Eth)
PSC i yedeklemekte standart imaj bazli yedekleme kullanilabilir, Veeam , VDP , Acronis BAAS artik neyi kullaniyorsaniz. Restore islemi ise en basiti Multiple PSC ortamlari, vCenter i x farkli bir PSC e linkleyin , yeni PSC kurup var olan domain e ekleyin sonra ilgili vCenter i yine eski site daki PSC e geri linkelyin, hepsi bu. Daha fazla PSC backup icin bakiniz.
PSC kurulumunda goreceksinizki size domain ve site isimleri sorulacaktir, bunlar Microsoft AD ve Sites lardan mantiksal olarak cok farkli degiller ayni islevi goruyorlar.
Eger eski version vCenter Server 5.1 kullaniyorsaniz zaten SSO kullaniyorsunuzdur, bu versiondan 6.0 a upgrade mumkun.
Bu arada artik kullanmayaniniz var ise (vCenter Virtual Appliance) VCSA kullanmanin artik tam zamani , eksik olarak sadece Update Manager kaldi o da roadmap de .
Onemli PDF , Linkler ve Video lar ;
Click to access VMware-vCenter-Server-6-0-Availability-Guide.pdf
VMworld 2015 Session – INF4528
vmknowledge 