VMware vSphere 7.0’a geçiş :) Birçok yönetici, her yükseltmeyle birlikte doğru planlama, toplama gereksinimleri ve uyumluluk önkoşullarının ne anlama geldiğini unutma eğilimindedir. Bu nedenle, diğer VMware ürünlerinin yeni vSphere sürümüyle nasıl uyumlu olduğunu gözden geçirme veya hangi Yükseltme Yollarının desteklendiğini belirleme bölümünü kaçırmaktadırlar.
İşte bu makalenin amacı,VMware vSphere’inizi yükseltmeden önce dikkat etmeniz gereken temel konulardır.
Her yöneticinin sistemini yükseltmeden önce bilmek istediği ilk şey, diğer ürünlerin eskiden olduğu gibi çalışmaya devam edip etmeyeceği olduğunu varsayacağım ve bu gerçekten iyi bir soru. Ya farklı çalışırlarsa veya daha kötüsü hiç desteklenmezlerse? Bu nedenle, tüm sıkıntılardan kaçınmak için , VMware Ürün Birlikte Çalışabilirlik Matrisleri ile Birlikte Çalışabilirliği kontrol etmeniz gerekir . Böylelikle ürünün bu versiyonunun sanal veri merkezinizdeki diğer çözümlerle nasıl uyumlu olduğunu görebilirsiniz.
Örneğin, VMware vCenter 6.7 Güncelleme 2’yi seçerseniz, VMware ESXi 6.5 Güncelleme 2 ve 6.0 Güncelleme 3 ile uyumlu olduğunu ancak ESXi 5.5 Güncelleme 3 ile uyumlu olmadığını açıkça görebilirsiniz.
Resim 1
Özellikle VMware ürünlerinin yanı sıra, üçüncü taraf yazılımları, yedekleme araçlarını, aktif komut dosyalarını, çeşitli çerçeveleri, API’yi vb. Kontrol etmenizden zarar gelmez. Yükseltmeden sonra da çalışmaya devam edeceğinden emin olmalısınız, bu yüzden üreticinin belgelerini gözden geçirmelisiniz.
Açık Aynı kaynak, ürünlerinizin anda yüklü versiyonları vSphere yeni sürümüne doğrudan yükseltme yolu olup olmadığını doğrulamak için bir sekme Yükseltme Yolu vardır.
Burada, örneğin, VMware vCenter Server için olası yükseltme yollarına buradan göz atabilirsiniz.
Resim 2
vCenter 5.5 Güncelleme 2’nin vCenter 6.7 ve sonraki sürümler için doğrudan bir yükseltme yoluna sahip olmadığını kendiniz görebilirsiniz. Bunun neden böyle olduğuna şaşmamalı: Ürünün kodu o kadar eski ki üreticinin bu ürünü sadece birkaç dinozoru hayatta tutmak için uyarlaması için hiçbir neden yoktur :)
Bununla birlikte, yakından bakarsanız, güncelliğini yitirmiş bir ürünü çalıştırmanın doğrudan bir yükseltme yolunun olmamasının tek nedeni olmadığını göreceksiniz. En azından vCenter 6.5 Güncelleme 2 ve vCenter 6.7’de durum böyle değildir.
Aslında göründüğünden daha basit. Bu bir Geriye Dönük Yükseltme senaryosudur: vCenter 6.5 Güncellemesi 2, vCenter 6.7’den daha sonra piyasaya sürüldü ve bu da kod farklılıklarına neden oldu.
Birçok yöneticinin, büyük yazılım yükseltmeleriyle uğraşırken temiz bir sayfa açmayı tercih ettiğini biliyorsunuz. Yine de, bu yolun, tarihsel verilerin korunması, karmaşık yapılandırmalar vardır. Yine de, ürünün temiz bir sürümünü büyük zorluklar olmadan kurmanın kolay bir yoluna sahipseniz, kesinlikle onunla gitmelisiniz.
Back-in-time;
Back-in-Time Upgrade ile anlaşmanın ne olduğunu açıklayalım. Böyle bir senaryo, bir yükseltme yolu sonunda kodun ve güvenlik düzeltmelerinin kasıtlı olarak gerilemesiyle sonuçlandığında ortaya çıkar. En küçük detaylar bile bu tatsız sonucu tetikleyebilir. Örneğin, eski bir alan silinmişse veya vCenter 6.5 Güncelleme 2’nin veritabanına yeni bir alan eklenmişse, vCenter 6.7 sonraki sürüme sahip olmasına rağmen bunu bilemez.
Bazen VMware bunların geçmesine izin verir, ancak gerileme riskleri hakkında her zaman bir uyarı vardır. Örneğin, VMware vSphere 6.5 Güncelleme 2d’yi (yayın tarihi 11.29.2018) vSphere 6.7 Güncelleme 1’e (10.16.2018) yükseltebilirsiniz.
Gerçekten bütün yapı numaraları ile karıştırılmamalıdır olsun istemiyorum yana, kontrol etmek son derece yararlı olduğunu bu . Burada, Back-in-Time Upgrade’in sizin durumunuzda bir tehdit olup olmadığını öğrenmenize yardımcı olabilecek yükseltme yolu matrislerine bakabilirsiniz.
ESXi ve vCenter matrisleridir:
vCenter Server 6.5’ten 7.0’a yükseltme matrisi
vCenter Server 6.7’den 7.0’a yükseltme matrisi
vCenter Server 6.5 ila 6.7 yükseltme matrisi
ESXi 6.x’ten 7.0’a yükseltme matrisi
ESXi 6.5’ten 6.7’ye yükseltme matrisi
Artık 6.7.0 U3b gibi vCenter ve ESXi yükseltmeleri için küçük güncellemeler dahil olmak üzere gerçek sayıları ve yayın tarihlerini görebiliriz.
Resim 3
Planning the Upgrade
Sizin için uygun bir upgrade yolu oluşturduğunuzda, upgrade iç düzenini geliştirme zamanı gelmiştir. Bizler yükseltme adımları ile ilgilenir, ama bir şeyler ters giderse, Yükseltmeden önce yapılandırmanızın yedek bir kopyasını elinizde bulundurmanızın da zararı olmaz.
Sadece, VMware vSphere’i yükseltirken, vCenter yönetim sunucularıyla başlamanız daha iyi olur: ESXi host ancak bundan sonra gelir.
Resim 4
Windows’ta vCenter Sunucunuz varsa, Geçiş Yardımcısı ve Geçiş Aracı yardımcı programlarını kullanmalısınız,vCenter Sunucu Uygulaması (vCSA) yolunda size adım adım yol göstereceklerdir.
VMware’e göre, vCenter’dan vCSA’ya geçmek için yalnızca iki ana kaleme ihtiyacınız vardır;
Migration Assistant – vCenter geçiş yöneticisinden önce etkinleştirdiğiniz konsol yardımcı programı. Taşıma gereksinimlerini belirler ve genellikle bir yöneticiyi doğru yöne yönlendirir.
Migration Tool – vCenter’ın ana dağıtımında bulunan geçiş yöneticisi.
Resim 5
Sonuç olarak, vCenter upgrade algoritması şuna benzer.
Resim 6
Geçiş tamamlandığında Virtual Hardware upgrade yükseltmesini unutmayın.
VMware ESXi yükseltmesini gerçekleştirmenin üç yolu vardır:
Manuel (CLI veya komut dosyalı kurulum kullanımıyla GUI aracılığıyla)
Auto Deploy (Host Upgrade)
vSphere Lifecycle Manager
Resim 7
Bu yazıda VMware vSphere 7.0 Transition konusuna kısaca göz atmaya çalıştık. Umarım faydalı olmuştur.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
TAGs: VMware vSphere 7.0 Transition,vsphere7, vmware vsphere7 geçiş,vsphere 7.0
