VCF 9.1 Automation: Namespace Self-Service, Namespace Capture ve Infrastructure Policies (Modül 2)

Önceki modülde HOL-2701-01 serisine VCF 9.1'in yeni menüleri ve VCF Operations tarafıyla başlamıştım. Operations modülünde çoğunlukla ekran gezdik, burada gerçekten bir şeyler oluşturuyoruz: namespace açıyoruz, bir namespace'i blueprint'e çeviriyoruz, tag ve policy zinciri kurup VM'in başka bir host'a kendiliğinden taşınmasını izliyoruz.

Her zamanki not: bunları sahadan değil, HOL ortamından yazıyorum. Production'da VCF Automation işletmedim. Lab'da gördüklerimi, "bunu gerçek bir ortamda kullanacak olsam ne sorardım" gözüyle okumaya çalıştım. Yanlış yorumladığım yer olursa yorumlarda düzeltirseniz sevinirim.

Kılavuz dört bölümden oluşuyor: Namespace Self-Service, Namespace Capture, Infrastructure Policies ve Service Framework. Sırayla gidiyorum.

Önce roller: bu modülde üç farklı kişi var

Bu modülü takip ederken en çok işime yarayan şey, kimin hangi portalda ne yaptığını baştan netleştirmek oldu. Çünkü lab sürekli portal değiştiriyor ve ne zaman hangi hesapla girdiğinizi karıştırmak kolay.

• Provider admin: VCF Automation Provider portalında çalışıyor. Infrastructure Policy'leri burada tanımlıyor, Organization'lara Region Quota üzerinden atıyor, servisleri (Service Management) yönetiyor.
• Organization admin: Organization portalında (lab'da ACME). Ağları, namespace class'larını, namespace servislerini sahipleniyor ve project'lere self-service'i açıyor.
• Project admin: Kendi project'i sınırları içinde, org admin'in izin verdiği kaynaklarla namespace oluşturuyor, blueprint yayınlıyor.

Bu ayrım bana vCenter'daki "herkes admin" alışkanlığından farklı geldi. Self-service'in mantığı bu: org admin çerçeveyi çiziyor, project admin o çerçevenin içinde istediği gibi hareket ediyor.

Namespace Self-Service

Kılavuzdaki girişte iş akışı şöyle anlatılıyor: ağlar, namespace class'ları ve namespace servisleri org admin tarafından sağlanıyor. Project admin'ler bunları kendi project'leri sınırları içinde kullanıyor. Namespace oluşturabilmeleri için önce org admin'in o project için self-service'i yapılandırması gerekiyor. Bu ayarlar, hangi paylaşılan kaynakların ve hangi şablonların kullanılabileceğini belirliyor.

Lab'da bu kurulum zaten yapılmış halde geliyor. Yani org admin'in self-service'i nasıl açtığını görmüyoruz, sadece yapılmış ayarlara bakıyoruz. Bunu not düşmek istiyorum, çünkü gerçek ortamda en çok emek harcanacak yer bence orası.

Ayarlara şuradan ulaşıyorsunuz: Manage & Govern > default-project > Namespace Self-Service sekmesi.

Sekmede şu bölümler var:

• Associated Regions: Namespace'lerin hangi region'larda oluşturulabileceği.
• Associated Namespace Classes: Önceden tanımlanmış boyutlar. Project admin bunları değiştiremiyor.
• Associated VPCs: Namespace oluştururken seçilebilecek paylaşılan VPC'ler.
• Associated Connectivity Profiles: Bu profil seçilirse namespace için ayrı (dedicated) bir VPC oluşturuluyor.
• Associated Subnets: Namespace oluştururken seçilebilecek önceden tanımlı subnet'ler.
• Infrastructure Policies: Varsa project'e buradan bağlanıyor. Bu konuya modülün ortasında geri döneceğiz.
• Associated Service Engine Groups: Avi Load Balancer'dan Service Engine Group tüketmek için.

Yeni namespace oluşturmak

Sonra kılavuz bir namespace açtırıyor: Namespaces > New Namespace. Sihirbazdaki alanlar şöyle:

1. İsim: sales (isim kurallarına dikkat edin diyor).
2. Namespace class: small. Sağ tarafta seçilen class'a göre kaynak sınırları değişiyor.
3. Region: us-west.
4. Zone: z-wld-a. Namespace'e ayrılan kaynaklar seçilen region'daki bir ya da birden fazla zone'dan geliyor.
5. Networking: Shared VPC (diğer seçenek Dedicated VPC) ve VPC olarak default-us-west.
6. Shared subnet: lab'daki hazır subnet.

Namespace hazır olunca sağ taraftaki detay panelini açıyorsunuz. Burada VM class'larını (ekleyip çıkarabiliyorsunuz), storage class'ı ve storage limitini (EDIT ile), infrastructure policy ayarını ve kullanılabilir servisleri görüyorsunuz.

Burada aklıma gelen sorular şunlar: Namespace class'larının sınırları ne kadar katı? Bir project admin kaç namespace açabilir, toplam limit nerede uygulanıyor? Lab bunları göstermiyor, sadece "oluşturdum, hazır" noktasına kadar götürüyor. Bir de dedicated VPC seçeneğini denemedik, sadece shared VPC kullandık.

Kılavuzun bu bölümün sonunda söylediği şey şu: bu özellik, namespace'i VM ya da ağ gibi bir kaynak olarak istemeyi mümkün kılıyor ve bir sonraki özelliğin (Namespace Capture) temeli.

Namespace Capture

Bence modülün en ilginç kısmı bu. Kılavuzun tanımı şöyle: çalışan bir namespace'i (VPC, VM'ler, diskler, subnet'ler, load balancer'lar ve ayarları dahil) alıp standart bir VCF Automation blueprint'ine, yani YAML'a çeviriyor. Bu blueprint versiyonlanıp catalog item olarak yayınlanabiliyor ve yetkili project kullanıcıları orijinalin birebir, bağımsız bir kopyasını isteyebiliyor.

Kılavuz bir de şunu söylüyor: 9.1 öncesinde blueprint'leri elle YAML olarak yazmanız gerekiyordu, bilinen bir namespace'i "kaydedip" dağıtılabilir bir şeye çevirmenin yolu yoktu. Şimdi project admin iş yükünü gerçek bir namespace'te kuruyor, doğruluyor ve blueprint'i VCF Automation üretiyor. Test/dev/lab ortamlarını "golden" bir şablondan tekrar tekrar basmak için düşünülmüş.

Proxmox otomasyon serisinde Terraform ve Ansible ile zero-touch VM provisioning yazmıştım. Orada her şeyi elle tanımlamanız gerekiyor ve bu işin asıl emeği. Burada ise tersini yapıyor: önce çalışan bir ortam kuruyorsunuz, sonra ondan tanım çıkarıyorsunuz. Hangi yaklaşımın daha iyi olduğunu söylemek için erken. Ama bu üretilen YAML'ın Git gibi bir akışa nasıl oturduğunu merak ediyorum, lab bunu göstermiyor. Blueprint ve versiyonlar VCF Automation'ın içinde tutuluyor.

Capture öncesi gerekenler

Kılavuz ön koşulları açıkça sayıyor, ben de aynen aktarayım çünkü gerçek hayatta bunlar işi belirler:

• Org admin'in o project için Namespace self-service'i açmış olması.
• Namespace ile ilişkili en az bir project content library olması. Yakalanan VM image'ları buraya kaydediliyor. Project content library OVA/OVF destekliyor, ISO ve çoklu VM içeren OVA desteklenmiyor.
• Namespace içinde tam olarak bir VM Group olması ve namespace'teki her VM'in bu gruba ait olması.
• Tüm VM'lerin başlatılmış (initialized) ve capture anında kapalı olması, veri tutarlılığı için.

İki kısıt da var: VKS cluster içeren namespace'ler capture edilemiyor. vSphere pod içeren namespace'ler capture edilebiliyor ama pod'lar blueprint'e dahil olmuyor.

Bu kısıtlar bana şunu düşündürdü: çalışan bir uygulama ortamını "yakalamak" için VM'leri kapatmanız gerekiyor. Golden bir lab ortamı için sorun değil, ama canlı bir ortamı kopyalamak için değil. VKS'in capture dışında kalması da, Kubernetes ağırlıklı bir kurulumda bu özelliğin kapsamını ciddi biçimde daraltabilir.

İki capture türü

• Capture as an identical copy: Namespace'i birebir yeniden üretiyor: namespace class ve region, VPC connectivity profile ve private CIDR'lar, VM donanımı (VM class, sanal BIOS, NIC IP/MAC), ağ ve storage ayarları. Bootstrap alanları temizleniyor ki guest customization tekrar çalışmasın. Referans verilen secret'lar yeniden oluşturulmuyor. "Bana bundan bir tane daha ver, aynısı olsun" durumu için.
• Capture with customizations: Aynısını yapıyor ama catalog'dan isteyen kişiye VM başına guest OS ayarları açıyor: hostname, parola (kullanıcının girdiği ya da otomatik üretilen, isterseniz ilk girişte değiştirmeye zorlayan), pre/post script'ler (Windows'ta Sysprep GuiRunOnce ya da PowerShell, Linux'ta LinuxPrep shell script'leri) ve Windows Active Directory domain join. Her dağıtımın benzersiz olması ya da domain'e katılması gerektiğinde.

Domain join seçeneğini görünce bir sistemci olarak rahatladım. Çünkü "aynı VM'den on tane" fikrinin ilk takıldığı yer hep hostname, SID ve domain oluyor.

Lab'da yaptıklarım

1. VM Group oluşturmak. Build & Deploy > Virtual Machine > VM Groups > +NEW VM GROUP. Sihirbazda Power State'i Powered Off yapıyorsunuz, listeden VM'i seçiyorsunuz, start order adımını geçiyorsunuz ve bitiriyorsunuz. VM açıksa grup oluşturulurken kapatılıyor.

Ekran görüntüsündeki [object Object] ifadesi web arayüzündeki bir görüntüleme hatası: arayüz bir metin beklerken nesne almış. İşleyişi etkilemiyor, sihirbaz normal şekilde devam ediyor.

2. Capture'ı başlatmak. Namespace Overview > CAPTURE AS A BLUEPRINT. Önce bir dizi precheck çalışıyor. Başarısız olan olursa burada raporlanıyor, hepsi geçerse Capture Wizard'a devam ediyorsunuz.

3. Blueprint detayları. İsim olarak HOL Namespace Capture, content library olarak ACME Default Project Library seçiyorsunuz, türü Capture with customizations yapıyorsunuz ve guest customization'ı açıyorsunuz. Sonra VM kaynağını seçip CONFIGURE diyorsunuz. Lab'da parola seçeneği olarak User specified password seçiliyor. Sonra Next ve CAPTURE.

4. İzlemek. Recent Captures sekmesinde durumu görüyorsunuz.

Blueprint ile catalog item farkı

Kılavuzun burada anlattığı ayrım önemli: capture bir blueprint üretiyor, yani versiyonlanabilen ve düzenlenebilen bir YAML tasarım dosyası. Bunu yayınlamak ayrı bir adım. Blueprint'i açıp Version diyorsunuz, bir versiyon numarası ve açıklama giriyorsunuz, "Publish this version to the catalog" seçeneğini açıp Create diyorsunuz. Bir blueprint'in çok versiyonu olabilir ama catalog'da sadece yayınladıklarınız görünüyor.

Bunun mantığı şu: tasarımı (YAML'ı düzenleyip tekrar capture edip versiyonu artırarak) mevcut kullanıcıları bozmadan geliştirebiliyorsunuz, hangi versiyonun dağıtımda olduğunu kontrol ediyorsunuz, belirli versiyonları organization'ınızdaki başka project'lerle ya da başka VCF Automation organization'larıyla paylaşabiliyorsunuz. Catalog item olmadan blueprint'e sadece org admin'ler ve project admin'ler ulaşıyor, project kullanıcıları isteyemiyor.

Lab'da: Blueprint Design > HOL Namespace Capture diyerek blueprint'i açıyoruz. Topology diyagramını ve YAML'ı inceliyoruz. Kılavuzun vurguladığı şey, capture'ın standart VCF Automation YAML'ı üretmesi. Sonra VERSION > versiyon 1, açıklama Initial Capture Catalog Item, Publish this version to the catalog açık > CREATE.

Catalog'dan dağıtmak

Catalog sayfasında HOL Namespace Capture item'ında REQUEST diyorsunuz, dağıtım adı (HOL Deployment 1) ve VM parolası giriyorsunuz, SUBMIT. Dağıtım birkaç dakika sürüyor.

Bittiğinde dağıtımın özetini görüyorsunuz: Power State, IP adresi, VM Class. Kılavuzun bu noktada dikkat çektiği bir şey var: gördüğünüz IP, VM'in namespace'in özel ağındaki IP'si ve routable değil. VM'e ulaşmak için VM Load Balancer'a bakmanız gerekiyor. Topology sekmesinde vmService_vm_lb_... öğesine tıklayıp Load Balancer Ingress IP'yi alıyorsunuz, sonra terminalden SSH ile bağlanıyorsunuz.

Burada gözüme batan şey şu: yeni dağıtılan VM'e ulaşmak için ilk bakacağınız yer olan IP, erişilemeyen IP. Bunu bilmeyen biri bir süre uğraşabilir. Ayrıca ben bu bölümde sadece tek VM'li bir namespace capture ettim. Birden fazla VM, birden fazla disk ya da gerçek bir uygulama yığını yok. "Golden dev/test ortamını basma" iddiası kâğıt üzerinde güçlü, ama lab bunu tek VM ile gösteriyor.

Infrastructure Policies

Bu bölüm en uzun kısım (yaklaşık 50 sayfa) ve zincirleme çok adımı olduğu için ayrıca anlatmaya değer.

Kılavuzun tanımı: Infrastructure Policy'ler, cloud admin'in hizmet seçeneklerini ayırması (CPU yoğun ya da yüksek bellekli profiller gibi) ve lisans uyumluluğu için host yerleşimini yönetmesi için bir mekanizma. Bir Infrastructure Policy, bir VM'in hangi host'a ya da host grubuna yerleşeceğini tanımlıyor. VM-host affinity kurallarını uygulamak için. Policy'ler VCF Automation'da oluşturuluyor ve Region Quota üzerinden Organization'lara atanıyor.

İki uygulama biçimi var:

• Mandatory: Organization'a zorunlu atanırsa, o organization'da oluşturulan her namespace'e otomatik uygulanıyor.
• Optional: Org admin ya da project admin namespace oluştururken/güncellerken opsiyonel policy listesinden seçiyor, kullanıcılar da iş yükü dağıtırken bunlardan seçiyor.

Lab sadece optional policy'leri gösteriyor. Mandatory olanlar ve bunları otomatik uygulayan criteria builder için kılavuz "gelecekteki bir modül" diyor. Bunu açıkça yazıyorum, çünkü zorunlu uygulama production'da asıl merak edilen kısım ve burada görmüyoruz.

Policy'ler arkada vCenter Compute Policy'lerini kullanıyor. Kılavuzdaki dört adımlı akış şöyle:

1. Tag oluşturma: VCF Operations'ın tag özelliğiyle.
2. Compute Policy: Bu tag'leri vCenter'da bir Compute Policy'ye bağlamak.
3. Infrastructure Policy tanımı: VCF Automation Provider portalında.
4. Uygulama: Organization'ların Region Quota'sına eklemek.

Yani tek bir özellik için dört farklı yerde çalışıyorsunuz. Bu bana zincirin her halkasının sahibinin kim olduğu sorusunu getirdi: tag'ler platform ekibinde mi, vCenter policy'leri sanallaştırma ekibinde mi, Automation tarafı başka bir ekipte mi? Lab bunu tek kişinin yaptığı bir egzersiz olarak gösteriyor.

1. Tag'ler (VCF Operations)

Manage > Tags > Tag Definitions > + CREATE. Category adı infrastructure, altına üç tag: backup, disaster-recovery, production.

Sonra bu kategorileri vCenter'lara gönderiyorsunuz: PUSH CATEGORIES > ilgili vCenter'ı seç (lab'da wld01-a) > PUSH. Kılavuz, tag kategorilerini tek seferde birden fazla vCenter'a push edebildiğinizi özellikle vurguluyor. Çok vCenter'lı ortamlarda tek tek tag kategorisi oluşturmak zorunda kalmamak güzel.

Ardından Tag Assignments sekmesinde filtre uyguluyorsunuz: VCF Components altında wld01-a, Object Types altında Host. Atamalar şöyle:

• Listelenen tüm host'lara infrastructure:backup.
• esx-05a host'una infrastructure:disaster-recovery.
• esx-06a ve esx-07a host'larına infrastructure:production.

Her atamada Assign Tags penceresinde seçilen nesneleri kontrol edebiliyorsunuz. Bu tasarım bana mantıklı geldi: backup tag'i tüm host'larda olduğu için, backup ve disaster-recovery policy'lerini birlikte seçen bir VM'in esx-05a'ya düşmesi beklenir. Bunu kılavuz açıkça yazmıyor, benim yorumum.

2. Compute Policy'ler (vCenter)

vCenter'a (workload domain'in vc-wld01-a'sı) geçiyorsunuz. Önce bir lab ayarı: kümenin vSphere DRS Automation Level'ı lab'daki kaynak kısıtları yüzünden Partially Automated gelmiş. Policy'nin otomatik yerleşimi gösterebilmesi için Fully Automated yapıyorsunuz (Hosts and Clusters > cluster-wld01-01a > Configure > vSphere DRS > Edit).

Sonra Policies and Profiles > Compute Policies > ADD. Üç tane VM-Host affinity policy oluşturuyorsunuz:

• backup-vm-host-affinity: VM tag'i infrastructure:backup, host tag'i infrastructure:backup.
• disaster-recovery-vm-host-affinity: VM ve host tag'i infrastructure:disaster-recovery.
• production-vm-host-affinity: VM ve host tag'i infrastructure:production.

Mantık: bu tag'e sahip VM'ler, aynı tag'e sahip host'lara yerleşecek.

Kılavuz bu policy'lerin "must" mu "should" mu olduğunu belirtmiyor. Bu fark production'da önemli: host arızasında HA'nın bu kuralı çiğneyip çiğneyemeyeceği buna bağlı. Lab'da bunu görmedik.

3. Infrastructure Policy'ler (VCF Automation Provider portal)

Provider portalında Infrastructure Policies > vCenter Compute Policies sekmesinde üç compute policy'yi görüyorsunuz. Kılavuz bu policy'lerin VCF Automation'da görünmesinin birkaç dakika alabileceğini söylüyor. Sonra Infrastructure Policies sekmesinde CREATE INFRASTRUCTURE POLICY ile backup, disaster-recovery ve production adında üç policy tanımlıyorsunuz, her biri ilgili compute policy'ye bağlı.

4. Organization'a atamak

Organizations > Acme > Region Quota > us-west (>>) > Infrastructure Policies > EDIT, hepsini seçip SAVE. Sonra LAUNCH ORGANIZATION PORTAL ile org portalına geçiyorsunuz.

Test: namespace ve VM

Org portalında yeni bir namespace açıyorsunuz: production-all-apps, project default-project, class small, region us-west, zone z-wld-a, Infrastructure Policies alanında hepsini seçili, VPC default-us-west. Namespace Active olunca açıp Infrastructure Policies'in atandığını görüyorsunuz.

Sonra Services altında Virtual Machine servisinden + CREATE VM: Deploy from OVF, VM adı web-vm, Infrastructure Policy alanında backup ve disaster-recovery, image hol-ubuntu24, VM class best-effort-xsmall, DEPLOY VM.

VM Ready olunca nesne detayında iki policy'nin atandığını görüyorsunuz. vCenter'da web-vm'i aratıp açınca, Tags widget'ında vSphere tag'lerini ve Related Objects widget'ında dağıtım konumunu doğruluyorsunuz.

Policy değişince VM ne yapıyor?

Lab'ın en iyi gösterdiği şey bu. VM oluştuktan sonra Infrastructure Policy'yi düzenliyorsunuz: disaster-recovery'yi kaldırıp production'ı seçiyorsunuz, Save. vCenter'ı yenileyince disaster-recovery tag'inin yerini production tag'inin aldığını görüyorsunuz. Tag değiştiği için DRS, VM'i uygun bir host'a taşıyor. Monitor > Tasks altında Migrate virtual machine ve Reconfigure virtual machine görevlerini inceleyebiliyorsunuz.

Bunu görmek gerçekten iyiydi: policy değişikliği tag'e dönüşüyor, tag DRS'i tetikliyor, VM kendiliğinden taşınıyor. Ama aynı zamanda bir uyarı da: production'da bir policy düzenlemek, o policy'ye bağlı tüm VM'leri taşıyabilir. Kaç VM etkilenir, bunu düzenlemeden önce nasıl görürüm, taşıma sırasında ne olur, lab bunları cevaplamıyor. Üstelik lab'da DRS'i Fully Automated'a çekmemiz gerekti. Partially Automated olan bir ortamda bu akış aynı çalışmaz.

Service Framework

Son bölüm kısa. Provider portalındaki Service Management arayüzüyle, VCF Automation'ı Broadcom'un ve üçüncü tarafların sunduğu servislerle genişletebiliyorsunuz. Bir servis UI plugin'leri, service account'lar, Supervisor Service'ler, roller, rights bundle'lar, runtime defined entity'ler gibi birçok öğe içerebiliyor. İki tür servis var: VCF services (Broadcom'dan, örneğin VMware Data Services Manager ve Secret Store) ve partner services (dış üreticilerden).

Lab'da Service Management altında Secret Store Service'i buluyorsunuz ve Install diyorsunuz. Sertifikaları kabul ediyorsunuz, tüm region'lara ya da belirli region'lara dağıtmayı seçebiliyorsunuz (lab'da us-west), servis özelliklerini gözden geçiriyorsunuz (gerekirse elle değiştirilebiliyor) ve son adımda kurulumu tamamlamadan Cancel diyorsunuz.

Kılavuzun Secret Store tanımı: vSphere Supervisor ortamlarında secret yönetimi için merkezi bir servis. Supervisor ve VKS cluster'larla entegre, yöneticiler, DevOps mühendisleri ve uygulama kiracıları için rol tabanlı erişim sağlıyor, Kubernetes-native API'leri destekliyor.

Bu bölüm bir ekran turundan ibaret. Kurulumu tamamlamadığımız için servisin nasıl çalıştığını, yükseltmelerin nasıl yapıldığını, partner servislerin destek sınırlarını ve bir servis bozulduğunda ne olacağını göremiyoruz. Soru işaretlerim burada en fazla.

Genel olarak neler dikkatimi çekti

İlk olarak, bu modülün ana fikri self-service'i yönetilebilir hale getirmek. Namespace Self-Service, Capture ve Infrastructure Policies'in üçü de aynı yöne bakıyor: platform ekibi çerçeveyi çiziyor, kullanıcı o çerçevenin içinde kendi başına iş görüyor. Mantığını anlıyorum. Ama bu çerçevenin kurulumu lab'da hazır geliyor, yani asıl emeği göremiyoruz.

İkincisi, ön koşullar ve kısıtlar çok belirleyici. Capture için VM'lerin kapalı olması, tek VM Group, VKS'in dışarıda kalması, ISO ve çoklu VM OVA'nın desteklenmemesi. Bunları okumadan "ortamımı yakalayıp çoğaltırım" demek yanlış olur.

Üçüncüsü, Infrastructure Policy'lerde zincirin uzunluğu. Tag, compute policy, infrastructure policy, region quota. Her halka ayrı bir yerde ve muhtemelen ayrı bir ekibin elinde. Sorun çıktığında hangi halkada baktığınızı bilmek gerekecek.

Dördüncüsü, lab'ın göstermedikleri: mandatory policy'ler, DRS'in Fully Automated olmadığı durum, çoklu VM'li capture, Service Framework'ün işletme tarafı. Kılavuz bazılarını kendisi de "gelecek modül" diye erteliyor.

Son olarak, her zamanki gibi: bu yazıdaki her şey lab ortamında, küçük ve temiz bir kurulumda gördüklerime dayanıyor. Production'da ölçek ve alışkanlıklar işi değiştirir. Orada VCF Automation işletenler "şu aslında böyle olmuyor" derse öğrenmek isterim.

Gelecek hafta serinin son yazısı: kılavuzun 4. ve 5. modülleri. vSphere'de Memory Tiering, vSAN'da Global Deduplication, Effective Capacity Reporting ve Oracle RAC ile WSFC için Hot Extend.

---

Bu seri VMware HOL ortamı (HOL-2701-01-VCF-L) üzerinden yürütülmektedir. Buradaki gözlemler lab bağlamında değerlendirilmeli, production kararları için resmi VMware dokümantasyonu ve deneyimli mühendisler referans alınmalıdır.