[TR] VMware vSphere 7.0 ve Sonrasında Ağ Geri Alma (Rollback) ve Kurtarma Mekanizmaları

Bir vSphere ortamında ESXi sunucularının merkezi olarak yönetilebilmesinin tek koşulu vardır yönetim ağının (management network) sağlıklı çalışması.

VMware vCenter Server envanterindeki her host ile bu ağ üzerinden konuşur yapılandırma değişikliklerini bu kanal üzerinden gönderir durum bilgilerini bu kanaldan toplar. Dahası vSphere HA (High Availability) mimarisi de host’lar arası “heartbeat” trafiği için aynı ağa dayanır.

Bu tek noktaya bağımlılık yönetim ağını sanallaştırma altyapısının en hassas bileşenlerinden biri hâline getirir. Yanlış girilmiş bir VLAN numarası, sehven değiştirilmiş bir MTU değeri veya bir uplink’in kaldırılması gibi ilk bakışta önemsiz görünen bir işlem, host’un vCenter Server ile bağlantısını anında koparabilir.

İşin can sıkıcı tarafı da şudur bağlantı koptuğu anda hatayı düzeltmek için kullanacağınız aracın (vCenter Server) kendisi de erişilemez hâle gelir. Klasik bir “oturduğunuz dalı kesme” senaryosudur.

İşte vSphere’in otomatik geri alma (rollback) ve DCUI üzerinden kurtarma (recovery) özellikleri tam olarak bu kısır döngüyü kırmak için tasarlanmıştır.

Bu makalemde söz konusu mekanizmaların nasıl çalıştığını hangi olaylarda devreye girdiğini ve bir yöneticinin bunlardan pratikte nasıl yararlanacağını ayrıntılı biçimde ele alıyor.

Not: Bu konudaki nihai ve bağlayıcı kaynak vSphere Networking Guide dokümanıdır. Kılavuz ile burada anlatılanlar arasında bir farklılık görürseniz kılavuzu esas alınız.

Problemin Kökeni: VSS ile VDS Arasındaki Fark

Geri alma mekanizmasının neden var olduğunu anlamak için standart sanal switch (VSS) ile dağıtık sanal switch (VDS) arasındaki yönetimsel farkı görmek gerekir.

Standart Sanal Switch (VSS) Senaryosu

VSS tanımı gereği host’a özeldir yapılandırması ilgili ESXi sunucusunun üzerinde yaşar. Dolayısıyla yönetim ağı bir VSS üzerinde koşuyorsa ve bir hata yapılırsa çözüm nispeten basittir sunucunun fiziksel konsoluna (ya da IPMI/iLO/iDRAC gibi bir out-of-band arayüze) bağlanır DCUI (Direct Console User Interface) üzerinden yönetim ağı yeniden yapılandırılır ve iş biter. Etki alanı tek host ile sınırlı kalır.

Dağıtık Sanal Switch (VDS) Senaryosu

VDS’te ise yapılandırma merkezîdir ve VMware vCenter Server tarafından yönetilir birden fazla host aynı dağıtık switch’e bağlanır. Bu operasyonel tutarlılık açısından büyük bir avantajdır ancak hata durumunda avantaj hızla dezavantaja dönüşür.

Yönetim VMkernel adaptörünün bağlı olduğu dağıtık port grubunda hatalı bir değişiklik yapıldığını düşünün. Bu değişiklik switch’e bağlı tüm host’lara aynı anda dağıtılır ve hepsinin VMware vCenter Server bağlantısını birden koparabilir.

Sonuç VMware vCenter Server artık VDS port grubu yapılandırmasında hiçbir düzeltme yapamaz çünkü düzeltmeyi iletebileceği bir kanal kalmamıştır.

Bu noktada geriye kalan tek klasik çözüm oldukça zahmetlidir;

1. Her bir host’a tek tek fiziksel/uzak konsol üzerinden bağlanmak,
2. Her birinde doğru yapılandırmaya sahip bir VSS oluşturmak,
3. Yönetim ağını bu geçici VSS’e taşımak,
4. Tüm host’lar tekrar iletişim kurabilir hâle geldikten sonra vCenter Server üzerinden VDS’i düzeltmek,
5. Son olarak yönetim ağını yeniden VDS’e geri taşımak.

Onlarca host’lu bir clusterda bunun ne anlama geldiğini tahmin etmek zor değil.

Önemli ayrıntı: Yönetim ağı VDS üzerindeyken DCUI’daki “Network Adapters” ve “VLAN” seçenekleri gri (devre dışı) görünür.

Bu seçenekler VMware ESXi yönetim ağı bir VSS’e taşınana kadar kullanılabilir hâle gelmez.

Bu davranış sorun anında pek çok yöneticiyi şaşırtan noktalardan biridir.

Klasik Kaçınma Yöntemi: Ayrık Tasarım

Host’larda fiziksel ağ kartı (pNIC) sayısı bir kısıt oluşturmuyorsa uzun yıllardır önerilen bir tasarım deseni vardır. yönetim ağını VSS üzerinde, geri kalan tüm trafiği (vMotion, vSAN, sanal makine trafiği vb.) VDS üzerinde tutmak.

Bu yaklaşım için host başına en az dört ağ adaptörü gerekir ikisi VSS’e, ikisi VDS’e bağlanacak şekilde.

Bu tasarım hâlâ geçerli ve güvenlidir ancak port yoğunluğu ve kablolama maliyeti getirir. VMware vSphere’in otomatik geri alma özelliği tam olarak bu ödünleşimi ortadan kaldırmak için geliştirilmiştir artık yönetim ağını rahatlıkla VDS üzerinde tutabilirsiniz.

Otomatik Geri Alma (Rollback) Nasıl Çalışır?

Mekanizmanın mantığı sade ama etkilidir. Bir ağ yapılandırma değişikliği uygulandığında host değişiklik sonrasında vCenter Server’a hâlâ ulaşıp ulaşamadığını doğrular. Eğer erişim kaybolmuşsa host değişikliği kalıcı hâle getirmez ve bilinen son geçerli yapılandırmaya geri döner. İlgili görev (task) vCenter Server tarafında başarısız olarak işaretlenir.

Yani sistem sizi kendi hatanızdan otomatik olarak korur yanlış komut çalışır, sonuç ölçülür, sonuç kötüyse işlem geri sarılır.

Geri alma varsayılan olarak etkindir. İstenirse VMware vCenter Server seviyesinde açılıp kapatılabilir. Özel bakım senaryoları dışında bu özelliğin kapatılması genellikle önerilmez.

Geri almayı tetikleyebilecek olaylar iki ana kategoride toplanır.

Kategori 1: Host Ağ Yapılandırması Geri Almaları

Bu tür geri almalar host’un kendi ağ yapılandırmasında (sanal switch’ler veya ağ sistemi düzeyinde) geçersiz bir değişiklik yapıldığında devreye girer.

Temel kural nettir = host’un bağlantısını koparan her ağ değişikliği geri alma tetikler.

Tipik tetikleyici örnekleri:

Değişiklik Türü	Açıklama
Fiziksel NIC hız/dupleks ayarı	Fiziksel switch port’u ile uyumsuz bir hız veya dupleks değeri verilmesi
DNS ve yönlendirme (routing) ayarları	Hatalı varsayılan ağ geçidi veya erişilemez DNS sunucusu tanımlanması
Teaming/failover veya trafik şekillendirme politikaları	Yönetim VMkernel adaptörünü barındıran standart port grubunda yapılan politika değişiklikleri
VLAN değişikliği	Yönetim VMkernel adaptörünü barındıran standart port grubunun VLAN ID’sinin değiştirilmesi
MTU artırımı	Yönetim VMkernel adaptörünün ve switch’inin MTU değerinin, fiziksel altyapının desteklemediği bir seviyeye çıkarılması (ör. jumbo frame uçtan uca yapılandırılmadan 9000’e çıkılması)
IP ayarları	Yönetim VMkernel adaptörünün IP adresi, alt ağ maskesi vb. ayarlarının değiştirilmesi
VMkernel adaptörünün kaldırılması	Yönetim VMkernel adaptörünün standart veya dağıtık switch’ten silinmesi
Fiziksel NIC’in kaldırılması	Yönetim VMkernel adaptörünü taşıyan standart veya dağıtık switch’ten bir pNIC’in (uplink) çıkarılması

Bu işlemlerden herhangi biri bağlantı kopmasına yol açarsa ilgili görev başarısız olur ve host son geçerli yapılandırmaya döner.

Kullanıcı açısından görünen sonuç “işlem başarısız oldu” hatasıdır — ama arka planda aslında ciddi bir kesinti önlenmiştir.

Kategori 2: Dağıtık Switch (VDS) Geri Almaları

İkinci kategori dağıtık switch’ler, dağıtık port grupları veya tekil dağıtık port’lar üzerinde yapılan geçersiz güncellemeleri kapsar.

Geri alma tetikleyebilecek başlıca VDS değişiklikleri:

• Dağıtık switch’in MTU değerinin değiştirilmesi
• Yönetim VMkernel adaptörünün bağlı olduğu dağıtık port grubunda aşağıdaki ayarların değiştirilmesi:
  • Teaming ve failover
  • VLAN
  • Trafik şekillendirme (traffic shaping)
• Yönetim VMkernel adaptörünü içeren dağıtık port grubundaki tüm port’ların bloklanması (blocking)
• Yukarıdaki politikaların yönetim VMkernel adaptörünün bağlı olduğu tekil dağıtık port düzeyinde geçersiz kılınması (override)

Bu değişikliklerden biri geçersiz bir yapılandırmaya yol açarsa bir veya birden fazla host dağıtık switch ile senkronizasyon dışı (out of sync) duruma düşebilir.

Senkronizasyon Dışı Kalan Host’ları Düzeltmek

Burada iki farklı yol izlenebilir ve hangisini seçeceğiniz, sorunun kaynağını bilip bilmediğinize bağlıdır.

1. Çakışmanın yerini biliyorsanız – ayarı manuel düzeltin.

Klasik bir örnek yönetim VMkernel adaptörünü yanlışlıkla yeni bir VLAN’a taşıdınız ancak bu VLAN fiziksel switch üzerinde ilgili port’lara trunk edilmemiş.

Bu durumda yapılacak şey fiziksel switch yapılandırmasını düzeltmektir.

Fiziksel taraf düzeldiği anda, bir sonraki dağıtık switch → host senkronizasyonu sorunu kendiliğinden çözecektir.

Bu senaryo sorunun her zaman VMware vSphere içinde olmadığını hatırlatması bakımından önemlidir. Sanal katmandaki “hata” çoğu zaman fiziksel katmandaki bir eksikliğin yansımasıdır.

2. Sorunun nerede olduğundan emin değilseniz – önceki yapılandırmaya geri dönün.

Dağıtık switch’i veya dağıtık port grubunu daha önceki bir yapılandırmasına geri alabilirsiniz.

Bu işlem otomatik değildir her iki adım da manuel olarak gerçekleştirilir. VMware vSphere, VDS yapılandırmalarının geçmiş sürümlerini sakladığı için bilinen çalışır bir noktaya dönmek mümkündür.

DCUI ile Ağ Yapılandırma Hatalarından Kurtarma

Otomatik geri alma güçlü bir güvenlik ağıdır ancak her senaryoyu kapsayamaz. Örneğin fiziksel altyapıdaki bir değişiklik sonradan gerçekleşirse ya da bağlantı kaybı gecikmeli olarak ortaya çıkarsa host yine de erişilemez hâle gelebilir.

Bu noktada VMware vSphere 7.0 ve sonrası ikinci bir kurtarma yolu sunar doğrudan host’a bağlanıp, DCUI üzerinden dağıtık switch özelliklerini veya diğer ağ yanlış yapılandırmalarını düzeltmek. Bu VDS ortamlarında geçmişte mümkün olmayan ve tam da yukarıda anlatılan “her host’a VSS kurma” angaryasını ortadan kaldıran bir yetenektir.

Ön Koşullar ve Kısıtlar

• Stateless (durumsuz) ESXi kurulumlarında bu kurtarma yöntemi desteklenmez. Auto Deploy ile stateless çalışan host’lar için farklı bir kurtarma stratejisi planlamanız gerekir.
• Yönetim ağının bir dağıtık switch üzerinde yapılandırılmış olması gerekir. DCUI üzerinden VDS yapılandırma hatalarını düzeltmenin tek yolu budur.

VDS’i DCUI Üzerinden Geri Yükleme Adımları

1. Host’un DCUI‘sine bağlanın (fiziksel konsol veya out-of-band yönetim arayüzü üzerinden).
2. Network Restore Options menüsünden Restore vDS seçeneğini seçin.
3. İlgili alanlara doğru değerleri girin VLAN, uplink ve gerektiğinde blocked özellikleri.
4. Enter tuşuna basarak işlemi onaylayınız.

Perde Arkasında Ne Oluyor?

Bu adımlar tamamlandığında zincirleme bir dizi işlem gerçekleşir:

1. DCUI, mevcut hatalı yapılandırmaya sahip port’tan bir host yerel port’u (host local port) klonlar.
2. Girdiğiniz VLAN ve Blocked değerlerini bu yeni port’a uygular.
3. Yönetim ağını yeni oluşturulan bu yerel port’u kullanacak şekilde değiştirir böylece vCenter Server ile bağlantı yeniden kurulur.
4. vCenter Server yeni host yerel port’unu algılar ve veritabanını bu bilgiyle günceller.
5. vCenter Server, yönetim ağına bağlı bir bağımsız port (standalone port) oluşturur.

Sonuç olarak host, vCenter Server envanterine tekrar sağlıklı biçimde katılır ve kalıcı düzeltmeleri artık merkezî arayüzden yapabilir hâle gelirsiniz.

Anlatılan mekanizmaların günlük operasyona nasıl yansıtılacağına dair birkaç somut öneri:

• Geri alma özelliğini kapatmayın. Varsayılan olarak etkin gelmesinin iyi bir nedeni vardır. Kapatmayı gerektiren çok özel bir senaryo yoksa olduğu gibi bırakın.
• Değişiklikleri kademeli uygulayın. Özellikle MTU ve VLAN gibi uçtan uca uyum gerektiren ayarları önce tek bir test host’unda deneyin, ardından kümeye yayın.
• Fiziksel katmanı önce hazırlayın. VLAN trunk’ları, jumbo frame desteği ve port kanalı ayarları sanal tarafta değişiklik yapmadan önce doğrulanmalıdır. Sanal katmandaki hataların önemli bir kısmı aslında fiziksel katmandan kaynaklanır.
• Out-of-band erişimi her zaman hazır tutun. DCUI kurtarması, ancak konsola ulaşabildiğiniz sürece işe yarar. iLO/iDRAC/IPMI erişiminizin çalıştığından ve kimlik bilgilerinin güncel olduğundan emin olun — bunu ihtiyaç anında değil, öncesinde test edin.
• Stateless host’lar için ayrı plan yapın. Auto Deploy kullanıyorsanız DCUI kurtarması seçenek değildir; host profili ve imaj profili düzeyinde bir geri dönüş stratejisi tanımlayın.
• Kritik VDS değişikliklerinden önce yapılandırmayı dışa aktarın. Manuel geri dönüş ihtiyacı doğduğunda elinizde temiz bir referans noktası olması işinizi ciddi biçimde kolaylaştırır.