VMware altyapılarında bazı bileşenler vardır ki çalışmadığında tüm ortamı etkiler. Bunların başında hiç şüphesiz VMware vCenter Server gelir. Özellikle bir VMware vSAN cluster’ını yöneten vCenter erişilemez hale gelirse, ortam bir anda yönetilemez bir yapıya dönüşebilir.

Bu makalemde yedeği olmayan ve tamamen kullanılamaz hale gelmiş bir vCenter senaryosunda mevcut vSAN cluster’ı veri kaybı yaşamadan yeni bir vCenter’a nasıl taşıdığımızı tüm teknik detaylarıyla sahada yaşanmış gerçek bir süreç üzerinden anlatıyorum.

Problem: vCenter Var, Ama Yok

Müşteri ortamında vSAN cluster’ı yöneten vCenter tamamen erişilemez durumdaydı. Appliance açılmıyor, servisler çalışmıyor ve en önemlisi:

• VAMI üzerinden alınmış bir backup yok
• Sanal makine seviyesinde bir yedek yok

Normal şartlarda yapılması gereken işlem vCenter’ı yedekten geri yüklemektir. Ancak yedek yoksa geri dönüş de yoktur.

Bu noktada tek uygulanabilir çözüm:

Yeni bir vCenter kurmak ve mevcut vSAN cluster’ı bu yeni vCenter’a taşımak.

VMware’in bu işlem için yayınladığı resmi makale: “Moving a vSAN cluster from one vCenter Server to another”

Ancak doküman teoride basit görünse de pratikte ciddi bir teknik dikkat gerektiriyor. Özellikle de ortamda vDS (Distributed Switch) kullanılıyorsa.

Asıl Risk: vDS Bağımlılığı

Mevcut ortamda vSAN trafiği bir vSphere Distributed Switch (vDS) üzerinden geçiyordu.

Buradaki kritik problem şuydu:

• vDS konfigürasyonu vCenter’a bağlıdır.
• vCenter erişilemezse vDS yönetimi de ortadan kalkar.
• Yeni vCenter’a geçerken vDS bağımlılığı süreci karmaşıklaştırır.

Bu nedenle ilk yapmamız gereken şey:

vSAN trafiğini vDS’ten çıkarıp geçici olarak vSphere Standard Switch (vSS) üzerine taşımaktı.

Bu adım cluster’ı vCenter bağımlılığından kurtaran en kritik hamle oldu.

Operasyon Planı

Bu işlemi aceleye getirmek mümkün değildir. Çünkü:

• vSAN dağıtık bir storage yapısıdır.
• vmkernel değişiklikleri sırasında obje yeniden yapılandırmaları (rebuild) tetiklenebilir.
• Aynı anda birden fazla host üzerinde işlem yapılırsa cluster risk altına girer.

Bu nedenle işlemler:

• Host host
• Sırayla
• Her adımda sağlık kontrolü yapılarak uygulanmalıdır.

Adım 1 – Mevcut Network Yapısını Analiz Etmek

İlk olarak ESXi üzerinde mevcut switch ve uplink yapısını kontrol etmektir.

esxcfg-vswitch -l

Bu komut sayesinde:

• Hangi vmnic hangi switch’e bağlı,
• vDS ve vSS yapıları,
• PortGroup konfigürasyonları,
• vmkernel interface’leri,

net şekilde görülebilir. Bu analiz aşamasını atlamayın. Yanlış vmnic’i taşımanız ortamı izole edebilir.

Adım 2 – vSAN vmnic’ini vDS’ten Çıkarma

Örneğin vSAN trafiği vmnic5 üzerinden gidiyorsa ve vDS adı DS1vSAN1 ise;

esxcfg-vswitch -Q vmnic5 -V 12 DS1vSAN1

Bu komut ile vmnic’i distributed switch’ten ayırıyoruz. Bu noktada henüz vSAN kesilmez çünkü vmkernel interface hala mevcut yapıdadır.

Adım 3 – Yeni Bir vSphere Standard Switch Oluşturmak

esxcli network vswitch standard add --vswitch-name=VSAN

Ardından fiziksel uplink’i bu yeni vSS’e bağlıyoruz;

esxcli network vswitch standard uplink add --uplink-name=vmnic5 --vswitch-name=VSAN

Adım 4 – PortGroup ve VLAN Tanımlamak

esxcli network vswitch standard portgroup add --portgroup-name=VMK_VSAN --vswitch-name=VSAN

VLAN kullanıyorsanız;

esxcli network vswitch standard portgroup set -p VMK_VSAN --vlan-id 100

Burada VLAN ID’nin doğru olduğundan emin olun. Yanlış VLAN host’lar arası iletişimi tamamen keser.

Kritik Aşama – vmkernel Interface Taşınması

İşte sürecin en hassas noktası burası.

vSAN trafiğini taşıyan vmkernel interface’i (örneğin vmk2) vDS’ten kaldırıp vSS’e taşıyoruz.

Önce cluster sağlığını kontrol ediniz.

esxcli vsan health cluster

Her şey sağlıklıysa devam edin.

vDS Üzerindeki vmkernel’i Silmek

esxcli network ip interface remove --interface-name=vmk2

Bu komut sonrası host’un vSAN bağlantısı geçici olarak kesilir.

Panik yapmayın diğer node’lar objeleri korumaya devam eder.

vSS Üzerinde Yeniden Oluşturmak

esxcli network ip interface add --interface-name=vmk2 --portgroup-name="VMK_VSAN"

IP adresini tekrar atayınız.

esxcli network ip interface ipv4 set --interface-name=vmk2 --ipv4=x.x.x.x --netmask=x.x.x.x --type=static

vSAN servisini tanımlayınız.

esxcli network ip interface tag add --interface-name=vmk2 --tagname=VSAN

Bağlantı Testi

Diğer ESXi node’ların vSAN vmkernel IP’lerine erişimi test ediniz.

vmkping -I vmk2 x.x.x.x

Ping başarılı değilse diğer host’a geçmeyin.

Sağlık Kontrolü

esxcli vsan health cluster

Cluster tekrar Healthy durumuna gelmeli.

Objeler rebuild ediliyorsa bekleyin. Sabırlı olun. vSAN zaman ister.

Tüm Node’lar İçin Tekrarlamak

Bu işlem her ESXi host üzerinde tek tek uygulanmalıdır.

Aynı anda birden fazla host üzerinde işlem yapmayın. Her geçiş sonrası sağlık kontrolü yapın.

Cluster tamamen stabil hale gelmeden sonraki adıma geçmeyiniz.

Son Aşama – Yeni vCenter’a Geçiş

Tüm host’lar:

• vDS bağımlılığından kurtulmuş
• vSS üzerinden vSAN iletişimi sağlanmış
• Cluster sağlıklı hale geldikten sonra yeni kurulan VMware vCenter Server üzerine host’lar eklenir ve vSAN cluster yeniden oluşturularak mevcut disk grupları import edilir.

Bu aşama artık kontrollü ve risksizdir çünkü network bağımlılığı ortadan kaldırılmıştır.

Bu Süreçten Çıkarılan Dersler

Bu olay birkaç önemli gerçeği tekrar hatırlattı:

• vCenter backup’ı opsiyonel değildir.
• VAMI backup mutlaka aktif olmalıdır.
• vDS kullanılan ortamlarda felaket senaryosu önceden planlanmalıdır.
• vSAN değişikliklerinde sağlık kontrolü ihmal edilmemelidir.
• Aynı anda birden fazla host üzerinde işlem yapılmamalıdır.

Yedeği olmayan, tamamen erişilemez bir vCenter ortamında bile doğru teknik yaklaşım ve dikkatli planlama ile vSAN cluster kayıpsız şekilde yeni bir vCenter’a taşınabilir.

Bu sürecin kalbi şudur:

vSAN vmkernel trafiğini kontrollü şekilde vDS’ten vSS’e taşımak ve her adımda cluster sağlığını doğrulamak.

Doğru sırayla sabırla ve kontrollü ilerlerseniz bu operasyon başarıyla tamamlanır.