Sistem · Rehber

VMware Executive Summit 2026 Sonrası Notlarım: VMware 9.0 ve 9.1

VMware 9.0 ve 9.1’de bellek, host bakımı ve depolama tarafında neler değişti? Memory Tiering, Quick Patch, vSAN ve yükseltme öncesi kontrol listesi.

HEHidayet Eriş5 dk okuma
VMware Executive Summit 2026 etkinlik salonu
VMware Executive Summit 2026 etkinlik salonu

17 Eylül’de İstanbul’daki VMware Executive Summit 2026’ya katıldım.

9.0 ve 9.1 hangi ürünleri kapsıyor?

VMware 9.0 ve 9.1 derken tek bir üründen söz etmiyoruz. vSphere ve ESX’in yanında VMware Cloud Foundation (VCF) ve VMware vSphere Foundation (VVF) paketleri var. Özellikle ağ ve otomasyon özelliklerinde, kullanılan paketin kapsamına bakmak gerekiyor. VCF’de bulunan her özellik VVF’de de varmış gibi düşünmemek lazım.

Kaynak: VCF 9.1 özellik karşılaştırması ve yükseltme yolları

Sürüm tarihleri de şöyle: VCF 9.0, 17 Haziran 2025’te; 9.1.0, 12 Mayıs 2026’da; 9.1.1 ise 3 Eylül 2026’da çıktı. Yani etkinliğin yapıldığı 17 Eylül’de 9.1 ailesi zaten genel kullanımdaydı.

Kaynak: VCF sürüm ve yayımlanma tarihleri

VMware Cloud Foundation 9.1 sunum slaydı

VCF 9.1’e geçiş başlıkları · VMware Executive Summit 2026

1. NVMe Memory Tiering

NVMe Memory Tiering, sunucuya bağlı NVMe diskleri ikinci bir bellek katmanı olarak kullanıyor. vSphere 8.0 Update 3’te teknik önizleme aşamasındaydı; 9.0’da genel kullanıma geçti.

Kaynak: VCF 9.0 kapsamındaki vSphere yenilikleri

Sık erişilen bellek sayfaları DRAM’de kalıyor, daha az kullanılan sayfalar NVMe katmanına taşınıyor. Böylece sanal makineler için daha fazla mantıksal bellek kapasitesi elde edebiliyoruz. NVMe’nin gecikmesi DRAM ile aynı olmadığı için, kapasite artışını uygulamanın performansından ayrı düşünmemek gerekiyor.

9.1’de yapılandırma ve takip tarafında birkaç iş kolaylaşıyor:

  • NVMe bellek katmanında yerleşik yazılımsal aynalama kullanabiliyoruz.
  • Ayarları vSphere Configuration Profiles üzerinden yönetebiliyoruz.
  • Sistem, gerekli disk bölümlerini otomatik oluşturuyor.
  • Memory Tiering yapılandırması için hostu yeniden başlatmak gerekmiyor. Hostu yine bakım moduna almak gerekiyor.
  • Bellek katmanlarının kullanımını, gecikmeleri ve NVMe aygıtlarının sağlık durumunu daha ayrıntılı görebiliyoruz.

Burada karar vermek için yalnızca toplam bellek kapasitesine bakmak yeterli olmaz. İş yükünün aktif bellek kullanımı, sayfalara ne sıklıkla eriştiği ve seçilen NVMe diskler sonucu değiştiriyor. Üretim ortamına geçmeden önce uygulama gecikmelerini ölçmek önemli.

Kaynak: 9.1 Memory Tiering geliştirmeleri

2. Host güncellemeleri ve Live Patch

ESX 9’a geçişte eski baseline tabanlı güncelleme yönetimiyle devam edemiyoruz. Host ve cluster’ları image tabanlı yönetime geçirmek gerekiyor.

Aynı cluster’da farklı üreticilerin sunucuları varsa, temel ESX sürümünü ortak tutup vendor add-on, firmware ve diğer bileşenleri donanıma göre tanımlayabiliyoruz. Farklı dönemlerde alınmış sunucuları yöneten ekipler için kullanışlı bir seçenek. Yine de donanımların aynı cluster’da desteklenen bir yapı oluşturduğunu uyumluluk listelerinden kontrol etmek şart.

Kaynak: VCF 9.0 kapsamındaki vSphere yenilikleri

9.1’de ESX Live Patch, TPM etkin sunucularda da çalışıyor. Uyumlu yamaları hostu yeniden başlatmadan uygulayabiliyoruz. Ancak bu, bütün güncellemeler için geçerli değil. Live Patch’e uygun olmayan bir yama, standart bakım modu ve yeniden başlatma sürecini gerektirebilir. Bakım penceresini planlarken yamanın uyumluluğunu kontrol etmek gerekiyor.

Kaynak: vSphere 9.1 yenilikleri

3. vCenter Quick Patch

vCenter Quick Patch, 9.1’de desteklenen güvenlik yamaları için kullanılabiliyor. Yamanın etkilediği paket ve dosyaları güncelliyor; böylece daha geniş kapsamlı bir güncellemenin bakım yükünü azaltıyor.

Broadcom’a göre uygun yamalarda vCenter kesintisi bir dakikanın altına inebiliyor, bazı yamalar ise kesinti gerektirmiyor. Bu süre, tüm yama işleminin ne kadar sürdüğünü göstermiyor. Hangi servislerin etkilendiğine ve yamanın içeriğine bağlı olan vCenter kesinti süresinden söz ediyoruz.

Yama ekranında Quick Patch desteğine, etkilenen servislere ve tahmini kesintiye bakmak gerekiyor. 9.0’dan 9.1’e geçiş gibi sürüm güncellemelerinde Reduced Downtime Update (RDU) yöntemini de planın içinde tutmak lazım. vCenter’ın yönetim servislerindeki kesintiyle çalışan sanal makinelerin durumunu ayrı değerlendirmek önemli.

Kaynak: vCenter Quick Patch

4. Depolama ve vSAN

VCF 9.0’da yeni bir management domain kurarken Fibre Channel üzerinden VMFS veya NFSv3’ü ana depolama olarak seçebiliyoruz. NFSv3’te uygun VAAI eklentisiyle kullanılmayan alanı geri kazanmak mümkün. NFS 4.1’de ise Kerberos üzerinden aktarım sırasında şifreleme desteği var.

Kaynak: vSphere ve VCF 9 depolama yenilikleri

9.1’de vSAN Express Storage Architecture (ESA), ZSTD tabanlı sıkıştırma kullanıyor. Global deduplication da bu sürümde genel kullanımda. Cluster genelindeki tekrar eden verilerin kapladığı fiziksel alanı azaltan bu özelliği, disk üzerindeki veri şifrelemesiyle birlikte kullanabiliyoruz. Global deduplication için iki düğümlü ve stretched cluster desteği ise yok.

Yükseltmeden hemen sonra bütün verilerin yeni sıkıştırma yöntemiyle küçülmesini beklememek gerekiyor. Gerekli disk formatı güncellemesinden sonra, mevcut veriler okunup yeniden yazıldıkça yeni yöntem devreye giriyor. Bu yüzden kapasitedeki değişimi zaman içinde takip etmek daha doğru.

Kaynak: vSAN 9.1 sıkıştırma ve global deduplication

5. DRS, vMotion ve ağ yönetimi

VCF 9.0’da Virtual Private Cloud (VPC) işlemlerini vCenter ve VCF Automation üzerinden yönetebiliyoruz. Ekipler veya projeler için ayrı sanal ağlar oluşturup kaynakları belirlenen yetki ve politikalarla kullanıma açmak mümkün. Bu özellikleri değerlendirirken NSX ve VCF gereksinimlerini de hesaba katmak gerekiyor.

Kaynak: VCF 9.0 ağ yenilikleri

9.1’de DRS destekli yeni tahliye seçeneği, bakım için boşaltılan hosttaki VM’lerin kaynak talebine bakıyor. VM’leri taşıyacağı hostların bu talebi karşılayabilmesini dikkate alıyor. Bakım sırasında kalan hostlarda kaynak sıkışıklığını azaltmak açısından önemli bir değişiklik.

vMotion kuyruğunda da bir taşıma bittiğinde boşalan kapasiteyi yeni bir taşıma kullanabiliyor. Aynı gruptaki bütün taşımaların tamamlanmasını beklemek gerekmiyor.

Kaynak: vSphere 9.1 yenilikleri

6. 9.x’e geçmeden önce

Geçiş planı, mevcut sürüme ve ortamda çalışan bileşenlere göre değişiyor. Örneğin vSphere 7’den 9.0’a doğrudan yükseltme desteği yok. Önce gerekli ara sürümleri ve bileşenlerin güncelleme sırasını belirlemek gerekiyor.

Kaynak: VCF 9.0 kapsamındaki vSphere yenilikleri

Yükseltme öncesi kontrol listesinde şunlar olmalı:

  • Sunucu, işlemci, ağ kartı ve depolama denetleyicisinin hedef sürüm desteği
  • Sürücü ve firmware uyumluluğu
  • Yedekleme yazılımının, eklentilerin ve diğer entegrasyonların sürüm desteği
  • Bileşenlerin hangi sırayla güncelleneceği
  • Yönetim bileşenleri için kapasite, DNS ve IP planı
  • Doğrulanmış yedekler, geri dönüş adımları ve pilot çalışma

Lisanslama tarafında da eski yöntemle devam etmiyoruz. 9.x ailesi, 25 karakterli lisans anahtarları yerine abonelik tabanlı lisans dosyaları kullanıyor.

Kaynak: VCF yükseltme ve lisanslama değişiklikleri

9.1’de merkezi License Server hem VCF hem VVF için zorunlu. VCF Management Services ise VCF’de zorunlu, VVF’de isteğe bağlı. Kurulum için kaynak ayırırken bu bileşenleri ve desteklenen yükseltme sırasını da plana dahil etmek gerekiyor.

Kaynak: 9.1 yükseltme sırası ve yönetim bileşenleri

Yorumlar (0)

Henüz onaylanmış yorum yok.

Deneyimini paylaş

Yorumlar yönetici onayından sonra yayımlanır. E-posta adresin herkese açık gösterilmez.