Dell-EMC vXRail’de “The provided vCenter credentials are not valid hatasının giderilmesi

Sanal altyapı yöneticiliği yapan herkesin günlük rutininde bazen küçük bir hata mesajının saatlerini çalabileceği anlar vardır. Dell EMC VxRail ortamlarında çalışıyorsanız vSphere Client üzerinden VxRail eklentisine geçiş yaptığınızda karşınıza çıkan şu mesaj muhtemelen tanıdık gelecektir “The provided vCenter credentials are not valid” yani “Sağlanan vCenter kimlik bilgileri geçerli değil.” Bu hatayla ilk karşılaştığınızda yapacağınız şey bellidir. Parolayı yanlış mı girdim diye düşünür kullanıcıyı kontrol eder belki başka bir hesapla denersiniz. Kimi zaman VMware vCenter arayüzüne aynı kullanıcıyla giriş yapıp her şeyin yolunda olduğunu da doğrularsınız. Ama hata mesajı inatla aynı yerde durur. İşte tam burada mesele ilginçleşiyor.

Bu hatanın söylediğiyle gerçekte yaşanan şey çoğu zaman birbirinden farklıdır. Ekrandaki ifade kimlik doğrulamayı işaret etse de arka planda olan bambaşka bir hikâyedir bir DNS sorgusu cevap dönmüyor olabilir bir sertifika dosyası boş indirilmiş olabilir ya da sizin bir hafta önce çalıştırdığınız zararsız görünen bir güvenlik duvarı komutu bugün karşınıza bambaşka bir yüzle çıkıyor olabilir. Kısacası hata mesajı bir tür sis perdesi görevi görüyor; gerçek sorun bu perdenin arkasında saklanıyor.

Aşağıda Dell EMC’nin resmi bilgi tabanında yer alan bu sorunu kendi deneyimlerimden ve sahada karşılaştığım örneklerden de yararlanarak adım adım açacağım. Hangi log dosyasına nereden bakacağınızı hangi belirtiyi nasıl yorumlayacağınızı ve her bir senaryoda neyi neden yaptığınızı anlayarak çözeceksiniz. Çünkü “şu komutu çalıştırın” demek ile “bu komut neden işe yarıyor” demek arasındaki fark, sistem yöneticiliğinde iyiyle çok iyi arasındaki farktır.

Sorunun Görüldüğü Sürümler ve İlk Kontroller

Bu hata özellikle VxRail 7.0.x ve VxRail 8.0.x sürümlerinde gözlemleniyor. Belirti her zaman aynı değil; bazen eklenti hiç yüklenmiyor, bazen küme bilgileri boş geliyor, bazen yapılandırma değişikliği yapmaya çalıştığınızda işlem ortada kesiliyor. Ancak son tahlilde hepsi aynı mesaja çıkıyor: kimlik bilgileri geçersiz.

Derin sorun gidermeye girişmeden önce gerçekten basit olanı eleyelim — çünkü saatler harcayıp sonunda “meğer gerçekten parola yanlışmış” demek kadar can sıkıcı bir şey yoktur. Şu kontrolleri sırayla yapın:

vCenter yönetim hesabınızla doğrudan vSphere Client’a giriş yapabildiğinizden emin olun. Hesabın kilitli olmadığını, parolanın süresinin dolmadığını ve gerekli yetkilere (en azından Administrator rolüne) sahip olduğunu doğrulayın. Eğer kısa süre önce hesap parolası değiştirildiyse, VxRail Manager’ın bu yeni parolayı henüz almamış olma ihtimalini de aklınızın bir köşesinde tutun.

Bu temel kontrollerden geçtikten sonra hata hâlâ devam ediyorsa, artık asıl meseleye geçebiliriz. Karşımızda beş farklı senaryo var ve her biri farklı bir teknik katmanda yaşanan bir aksaklığa karşılık geliyor.

Senaryo 1: Mikroservislerde DNS Çözümleme Sorunu

VxRail Manager modern bir mimariye sahip; içeride monolitik bir uygulama yerine, her biri kendi sorumluluğu olan konteyner tabanlı mikroservisler çalışıyor. Bunlardan biri olan do-cluster servisi, vCenter ile iletişimi yöneten kritik bileşendir. Bu servis vCenter’a bağlanmak için elindeki FQDN bilgisini DNS üzerinden çözmek zorundadır — yani “vcenter.sirket.local” gibi bir adı, “192.168.10.20” gibi bir IP adresine dönüştürmesi gerekir.

İşte işin püf noktası tam burada. Eğer bu çözümleme süreci herhangi bir nedenle başarısız olursa, mikroservis vCenter’a hiç ulaşamaz. Ulaşamadığı için kimlik doğrulama da yapamaz. Ve VxRail Manager bu durumu kullanıcıya en yanıltıcı şekilde bildirir: “kimlik bilgileriniz geçersiz.”

Belirtileri Nasıl Tespit Ederiz?

Bu senaryoyu doğrulamak için VxRail Manager’a SSH ile bağlanmanız ve /var/log/microservice_log/short.term.log dosyasını incelemeniz gerekir. Dosyada do-cluster mikroservisine ait satırlarda DNS çözümleme hatalarının izlerini ararsınız. Tipik olarak şu üç ifadeden biri (ya da hepsi) karşınıza çıkar:

• Temporary failure in name resolution
• No address associated with hostname
• socket.gaierror: [Errno -3] Temporary failure in name resolution

Logları biraz daha dikkatli incelediğinizde, hatanın Python traceback’leri içinde ClusterResolver.py dosyasındaki get_cluster fonksiyonundan başladığını ve aşağıya doğru socks_proxy.py, _socketcommon.py ve nihayetinde sistem çağrısı seviyesindeki getaddrinfo fonksiyonuna kadar uzandığını görürsünüz. Bu zincir size çok şey anlatır: uygulama vCenter’a SOAP üzerinden bağlanmak istemiş, bağlantı için socket açmaya çalışmış, ama daha socket’i açamadan adı IP’ye çeviremediği için işlem ortada kalmış.

Çözüm: Üç Adımlı Yaklaşım

İlk müdahale olarak VxRail Manager üzerinde çalışan dnsmasq servisini yeniden başlatın. Bu servis, sistemde yerel bir DNS önbelleği görevi görür ve zaman zaman takılma sorunları yaşayabilir. Yeniden başlatma çoğu hafif sorunu çözer:

service dnsmasq stop
service dnsmasq start

Servis yeniden başlatıldığı halde sorun devam ediyorsa, ikinci adım olarak DNS yapılandırmasının kendisini sorgulayın. Burada sıkça karşılaşılan ve atlanan bir hata var: VxRail Manager’ın DNS sunucusu olarak Google’ın 8.8.8.8 veya Cloudflare’in 1.1.1.1 gibi harici bir genel DNS tanımlanmış olabilir. Görünüşte mantıklıdır — internet bağlantısı varsa çalışacaktır. Ama burada büyük bir mantık hatası gizlidir: iç ağınızdaki vCenter veya ESXi sunucularının kayıtları bu harici DNS’lerde yoktur. Olamaz da. Çünkü vcenter.firma.local gibi bir kayıt yalnızca sizin kurumsal DNS sunucunuzda bulunur. Dolayısıyla VxRail Manager harici bir DNS’e “bana vcenter.firma.local’in IP’sini ver” diye sorduğunda, cevap her zaman olumsuz dönecektir. Bu yapılandırmayı kurumsal/dahili DNS sunucularınızla değiştirmeniz gerekir.

Üçüncü adım, eğer önceki ikisi de işe yaramadıysa, Dell Destek hattını aramaktır. Görüşme sırasında 000214621 numaralı bilgi tabanı makalesini referans gösterirseniz, destek mühendisi DNS kontrol aracını çalıştırarak daha derin bir analiz yapacaktır. Bu noktaya gelmişseniz, muhtemelen ortama özgü bir routing veya isim çözümleme sorunu vardır ve uzaktan tanı koymak gerekir.

Senaryo 2: Bozuk veya Boş CRL Dosyaları

Şimdi sertifika dünyasının daha az gezilen koridorlarına giriyoruz. SSL/TLS dünyasında Sertifika İptal Listesi (Certificate Revocation List — CRL) adı verilen bir mekanizma vardır. Bu listeler, bir CA tarafından imzalanmış olmasına rağmen artık geçerliliğini yitirmiş sertifikaları belirtir. VxRail Manager, vCenter ile güvenli iletişim kurabilmek için vCenter’ın güvenilen kök CA sertifikalarını içe aktarırken bu CRL dosyalarını da indirir.

Sorun şu ki, bu indirme işlemi her zaman düzgün gitmez. Bazen ağ kesintisi, bazen vCenter tarafındaki bir yapılandırma hatası, bazen de basitçe bir zamanlama sorunu nedeniyle CRL dosyaları diske boş ya da bozuk şekilde yazılır. Sıfır byte boyutunda bir dosya, dosya sisteminde yer kaplar ama hiçbir bilgi taşımaz. VxRail Manager bir sonraki başlatmada bu dosyayı okumaya çalıştığında, beklediği yapıyı bulamaz ve uygulama başlangıcının erken aşamasında çöker. SSL güven yöneticisi yüklenemez, vCenter bağlantı servisi başlatılamaz ve sonuç olarak — yine — kimlik bilgileri geçersiz hatasıyla karşılaşırsınız.

Belirtileri Nasıl Tespit Ederiz?

Bu senaryonun parmak izi /var/log/mystic/web.log dosyasındadır. Logu açtığınızda göreceğiniz şey, oldukça uzun ve göz korkutan bir Java istisna zinciridir. Spring Framework’ün bean oluşturma hataları üst üste sıralanır: önce backupEVCSettingAction, ardından VCConnectionServiceImpl, sonra connectionHelper, ardından connectionFactory, en sonunda da marvinTrustManager. Bu zincir başta korkutucu görünebilir, ama aslında size çok net bir şey söyler: uygulama, bağımlılıkları yukarıdan aşağıya doğru kurmaya çalışmış ama en derindeki marvinTrustManager bileşeni başlatılamadığı için yukarıdaki her şey domino taşı gibi devrilmiş.

Tüm bu zincirin en altında, asıl suçluyu açığa çıkaran tek satır vardır: java.security.cert.CRLException: Empty input. Bu satır size der ki: “Senin verdiğin CRL dosyası tamamen boş, ben boş bir CRL dosyasını parse edemem.”

Doğrulamak çok kolay. Şu komutla ilgili dizini listeleyin:

ls -l /var/lib/vmware-marvin/trust/lin/

Çıktıda iki tür dosya görürsünüz: .0 uzantılı dosyalar sertifikaların kendisidir ve normal boyutta (genellikle 1-2 KB) olmalıdır. .r0 uzantılı dosyalar ise CRL’lerdir. Eğer bir .r0 dosyasının boyutu 0 byte ise, suçluyu bulmuşsunuz demektir:

Çıktıda iki tür dosya görürsünüz: .0 uzantılı dosyalar sertifikaların kendisidir ve normal boyutta (genellikle 1-2 KB) olmalıdır. .r0 uzantılı dosyalar ise CRL'lerdir. Eğer bir .r0 dosyasının boyutu 0 byte ise, suçluyu bulmuşsunuz demektir:

İkinci satırdaki o sıfır, sorununuzun kaynağıdır.

Çözüm Yaklaşımı

Bu sorunun çözümü iki aşamalıdır: önce kaynaktaki bozukluğu temizlemek, sonra da VxRail Manager’a sertifikaları yeniden tanıtmak. Yani sadece dosyayı silmek yetmez — vCenter tarafındaki kök neden de adreslenmelidir, aksi halde aynı bozuk dosya bir sonraki içe aktarma işleminde tekrar oluşur.

Dell, bu işlemi adım adım anlattığı ayrı bir bilgi tabanı makalesi yayımlamış: 000194669 numaralı “VxRail: Unable to Import vCenter Root Certificates Due to Empty or Corrupted CRL Files” makalesi. Burada hem vCenter üzerindeki bozuk CRL’lerin nasıl tespit edilip silineceği, hem de VxRail Manager’a sertifikaların nasıl yeniden içe aktarılacağı detaylı şekilde anlatılıyor. Bu prosedürü adım adım izlemenizi öneririm — sertifika işlemlerinde “yaklaşık doğru” diye bir şey yoktur, ya tam doğru yaparsınız ya da daha büyük sorunlar yaratırsınız.

Senaryo 3: Sertifika Doğrulama Hatası

Bazen sorun CRL gibi çevresel bir bileşende değil, doğrudan SSL sertifikasının kendisinde olur. VxRail Manager vCenter’a TLS bağlantısı kurmaya çalışır, TCP el sıkışması başarılı olur, ama TLS el sıkışması sırasında sunucudan gelen sertifika doğrulanamaz. Bağlantı orada kesilir.

Bu doğrulama başarısızlığının arkasında birden fazla neden olabilir: sertifika zinciri eksik olabilir (yani aradaki bir CA’nın sertifikası VxRail Manager’da bulunmuyordur), sertifikanın süresi dolmuş olabilir, sertifikayı imzalayan CA VxRail Manager’ın güven deposuna eklenmemiş olabilir, ya da sertifika değiştirilmiş ama VxRail Manager hâlâ eski sertifikanın parmak izini hatırlıyor olabilir.

Belirtileri Nasıl Tespit Ederiz?

Yine /var/log/microservice_log/short.term.log dosyasına bakıyoruz. Bu kez göze çarpan satırlar şunlardır:

ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
graphql.error.base.GraphQLError: Failed to connect to vCenter None

Stack trace’i takip ettiğinizde hatanın cluster_do_query.py içindeki resolve_cluster fonksiyonundan başladığını, oradan ClusterResolver.py‘a geçtiğini ve sonunda Python’un standart ssl kütüphanesinde patladığını görürsünüz. GraphQL katmanında ortaya çıkan “Failed to connect to vCenter None” mesajı da ayrıca dikkat çekici — None ifadesi, uygulamanın aslında host bilgisini bile düzgün alamadan bağlantı kurmayı denediğini gösterir, yani bağlantı kurulurken erken bir aşamada her şey çökmüş demektir.

Çözüm Yaklaşımı

Bu senaryoda Dell’in tutumu net: doğrudan müdahale yerine destek ekibinin sürece dahil edilmesini öneriyor. Bunun mantıklı bir gerekçesi var. Sertifika yönetimi son derece hassas bir alandır; yanlış müdahale sadece mevcut sorunu çözmemekle kalmaz, üretim ortamınızdaki tüm güven ilişkilerini bozarak çok daha büyük bir krize yol açabilir. Özellikle vSphere ortamlarında sertifikaların kendi içinde karmaşık bir hiyerarşisi vardır — VECS, STS, machine SSL, solution user sertifikaları ve daha fazlası. Bu hiyerarşinin tamamını bilmeden müdahale etmek, doğru aletle yanlış vidayı sökmeye benzer.

Dell Destek ile iletişime geçerken 000157888 numaralı bilgi tabanı makalesini referans göstermeniz, sürecin doğru noktadan başlamasını sağlayacaktır. Görüşme öncesinde elinizde bulunması gereken bilgiler: VxRail sürümü, vCenter sürümü, en son ne zaman sertifika değişikliği yapıldığı (eğer biliyorsanız) ve elbette ilgili log dosyalarının kopyaları.

Senaryo 4: vCenter SSL Sertifikasında FQDN Eksikliği

Bu senaryo, sertifika konfigürasyonunda yapılmış bir tasarım hatasından kaynaklanır ve aslında oldukça yaygındır. Hikâye şöyle başlıyor: birisi vCenter kurarken veya sonradan sertifika değiştirirken, sertifikanın Subject Alternative Name (SAN) alanına yalnızca IP adresini ekliyor, FQDN’i atlıyor. Belki bilerek yapıyor, belki bilmeden — sonuç değişmiyor.

VxRail mikroservisleri ise vCenter’a bağlanırken adres olarak FQDN kullanır, IP değil. Bu mimari bir tercihtir ve mantıklıdır — IP adresleri değişebilir, FQDN’ler sabit kalır. Ama bu durumda bir uyumsuzluk doğar: mikroservis “vcenter.firma.local’a bağlanıyorum” der, sertifika ise “ben sadece 192.168.10.20’yi tanırım” der. TLS protokolü bu uyumsuzluğu hata olarak işaretler ve bağlantıyı keser.

Belirtileri Nasıl Tespit Ederiz?

Bu senaryonun log imzası diğerlerinden çok daha okunaklıdır:

ssl.CertificateError: hostname 'VC_FQDN' does not match 'VC_IP'

Mesaj nereye baksanız aynı şeyi söyler: “Sen FQDN ile geldin, ben sadece IP biliyorum, ikimiz anlaşamayız.”

Sertifikanın gerçekten bu sorundan muzdarip olup olmadığını bağımsız bir şekilde doğrulamak için dilediğiniz bir Linux makineden — illa VxRail Manager olması gerekmez — şu komutu çalıştırabilirsiniz:

echo | openssl s_client -connect <vc_fqdn>:443 2>/dev/null | openssl x509 -noout -text

Çıktıda X509v3 Subject Alternative Name bölümüne odaklanın. Sorunlu bir sertifikada şöyle bir tablo görürsünüz:

X509v3 Subject Alternative Name:
                IP Address:xx.xx.xx.xx

Sadece IP var, başka bir şey yok. Doğru yapılandırılmış bir sertifikada ise hem DNS adı hem de IP adresi yan yana durmalıdır:

X509v3 Subject Alternative Name:
                DNS:xxxxxxx, IP Address:xx.xx.xx.xx

Bu fark, küçük gibi görünse de modern TLS protokollerinin kabul ettiği ile reddettiği arasındaki tüm farktır.

Çözüm Yaklaşımı

Çözüm, vCenter Server’ın makine SSL sertifikasını yeniden oluşturmaktır. Yeni sertifika oluşturulurken SubjectAltName alanına mutlaka DNS Name=machine_FQDN girişinin eklendiğinden emin olun. VMware bu işlem için certificate-manager adında özel bir araç sunar; vCenter Server Appliance üzerinde shell’e geçtiğinizde /usr/lib/vmware-vmca/bin/certificate-manager yolundan erişebilirsiniz.

Sertifikayı yeniden oluşturduktan sonra iş bitmiş sayılmaz — VxRail Manager’ın bu yeni sertifikayı tanıması ve eski güven ilişkisini güncellemesi gerekir. Bu da genellikle vCenter güvenilen kök sertifikalarının VxRail Manager’a yeniden içe aktarılmasını gerektirir. Eğer Senaryo 2’de bahsi geçen CRL sorunu da paralel olarak yaşanıyorsa, iki sorunu birlikte ele almak gerekebilir.

Senaryo 5: “No Route to Host” — Güvenlik Duvarı Tuzağı

Şimdi geldiğimiz beşinci senaryo, beni en çok üzen olanı. Çünkü bu senaryo neredeyse her zaman, iyi niyetli bir sistem yöneticisinin kendi elleriyle tetiklediği bir kazadır. Hikâye şu şekilde gelişir: bir gün VxRail Manager üzerinde firewalld kurallarında bir değişiklik yapmanız gerekir. Belki bir port açacaksınız, belki bir kuralı kaldıracaksınız. Linux dünyasında bu tür değişikliklerden sonra alışkanlıkla yapılan şey nedir? firewall-cmd --reload komutunu çalıştırmak. Komut çalışır, geri dönüş “success” der, siz de görevinizi tamamladığınızı düşünüp başka bir şeyle ilgilenmeye başlarsınız.

Birkaç saat sonra ya da ertesi gün, VxRail eklentisi çalışmamaya başlar. Hata mesajı yine aynıdır: kimlik bilgileri geçersiz. Ve siz bu iki olay arasındaki bağlantıyı asla kuramazsınız — ta ki birisi size logları göstermeden.

Peki neden? Çünkü VxRail Manager, modern bir mimariyle tasarlanmıştır ve içeride rke2 (Rancher Kubernetes Engine 2) çalıştırır. Bu Kubernetes dağıtımı, konteyner ağlarını ve servisler arası iletişimi yönetmek için runtime’da iptables zincirlerine kurallar enjekte eder. Bu kurallar firewall-cmd tarafından yönetilen kalıcı yapılandırmada bulunmaz — tamamen runtime’da yaşarlar.

firewall-cmd --reload komutunu çalıştırdığınızda firewalld, mevcut tüm runtime kurallarını siler ve diskten kalıcı yapılandırmayı yeniden yükler. Yapılan iş kısmen “temiz bir başlangıç” gibidir. Ama bu temizlik sırasında rke2’nin enjekte ettiği tüm konteyner ağ kuralları yok olur. Konteynerler birden bire dış dünyayla — bu durumda vCenter ile — iletişim kuramaz hale gelir. Ağ topolojisi açısından konteynerler “hâlâ orada” görünür ama gerçekte trafik akışı tamamen kopmuştur.

Belirtileri Nasıl Tespit Ederiz?

Bu senaryonun log imzası, ağ yöneticisi gözüyle bakanlar için klasiktir:

OSError: [Errno 113] No route to host

Errno 113 Linux çekirdeğinde “No route to host” anlamına gelir ve şunu söyler: “Bu hedef IP’ye nasıl ulaşacağımı bilmiyorum, routing tablomda bir cevap yok.” Stack trace’in derinliklerine baktığınızda pyVmomi/SoapAdapter.py dosyasındaki connect çağrısının başarısız olduğunu, socks_proxy.py üzerinden yapılan bağlantı denemesinin de aynı şekilde patladığını görürsünüz. Hata zinciri sonunda Python’un kendi http/client.py modülüne kadar iner — yani uygulama HTTP isteğini bile gönderemeden ağ katmanında çıkmaza girmiştir.

Çözüm: İki Seçenek, Bir Önlem

İlk ve daha hafif seçenek, rke2 sunucusunu yeniden başlatmaktır. Bu, rke2’nin tüm ağ kurallarını yeniden enjekte etmesini sağlar:

bash /usr/local/bin/rke2-killall.sh
systemctl start rke2-server

Birinci komut tüm rke2 süreçlerini sonlandırır, ikincisi servisi yeniden başlatır. Süreç birkaç dakika sürebilir ve bu süre boyunca VxRail Manager arayüzü erişilemez olabilir, dolayısıyla planlı bir bakım penceresinde yapmanız iyi olur.

İkinci seçenek daha radikaldir: VxRail Manager’ı tamamen yeniden başlatmak. Bu yöntem ortamı bozmaz çünkü VxRail Manager bir yönetim sanal makinesidir; ESXi ana bilgisayarları veya iş yükü sanal makineleri etkilenmez. Ama yine de kısa süreli bir yönetim katmanı kesintisi yaratacağı için planlı bir saatte yapılması doğru olur.

Şimdi geldik en kritik kısma — gelecekte aynı sorunu yaşamamak için.

Bu Yazıdan Çıkarılacak En Önemli Pratik Bilgi: VxRail Manager üzerinde firewall-cmd --reload komutunu kesinlikle çalıştırmayın. Eğer firewalld kurallarını kalıcı hale getirmeniz gerekiyorsa, bunun yerine firewall-cmd --runtime-to-permanent komutunu kullanın.

Bu iki komut arasındaki fark, kâğıt üzerinde küçük görünse de operasyonel açıdan dünya kadar farklıdır. --reload sıfırdan başlar; runtime’daki her şeyi siler ve diskten yükler. --runtime-to-permanent ise mevcut runtime kurallarını alır ve onları diske yazar. İkincisi rke2’nin enjekte ettiği kuralları bozmaz, sadece onları kalıcı yapılandırmaya da kaydeder. Bu küçük dilbilgisi farkı, sizi gece yarısı çağrılarından kurtaracak farktır.

Sahada Sistematik Sorun Giderme Yaklaşımı

Şimdiye kadar beş senaryoyu tek tek inceledik. Peki gerçek hayatta hata mesajıyla karşılaştığınızda hangi senaryoda olduğunuzu nasıl tespit edeceksiniz? İşte size sahada işe yarayan bir akış öneriyorum.

İlk önce gerçekten basit olanı eleyin. vSphere Client’a aynı vCenter kullanıcı adı ve parola ile manuel giriş yapın. Eğer giriş yapamıyorsanız, tebrikler — sorununuz bir VxRail sorunu değil, gerçekten bir kimlik doğrulama sorunu. AD bağlantısı, hesap kilitleme, parola süresi gibi standart Active Directory kontrollerine yönelin.

Eğer manuel giriş çalışıyorsa, VxRail Manager’a SSH ile bağlanın. Bağlanırken kullanıcı adı genellikle mystic‘tir; bu kullanıcının parolası VxRail kurulumu sırasında belirlenmiştir ve bilgi sizde olmalıdır. Eğer yoksa Dell Destek’e başvurmanız gerekir.

SSH oturumunda iki ana log dosyasını incelemek yeterlidir: /var/log/microservice_log/short.term.log ve /var/log/mystic/web.log. Bu dosyaları tail ile son 200-300 satır olarak görüntüleyebilir veya grep ile spesifik anahtar kelimeler arayabilirsiniz. Aradığınız kelimeler senaryoya göre değişir:

name resolution veya gaierror görüyorsanız → Senaryo 1 (DNS).

CRLException veya Empty input görüyorsanız → Senaryo 2 (CRL).

CERTIFICATE_VERIFY_FAILED görüyorsanız → Senaryo 3 (Sertifika Doğrulama).

hostname ve does not match ifadeleri yan yana görünüyorsa → Senaryo 4 (FQDN Eksikliği).

No route to host veya Errno 113 görüyorsanız → Senaryo 5 (Güvenlik Duvarı).

Senaryoyu tespit ettikten sonra ilgili çözüm adımlarını uygulayın. Sertifika tabanlı senaryolarda (özellikle Senaryo 2 ve 3) eğer kendi başınıza ilerlemekten emin değilseniz, doğrudan Dell Destek’e başvurmak en güvenli yoldur. Üretim ortamlarında “deneyelim, olmazsa geri alırız” yaklaşımı, sertifika söz konusu olduğunda nadiren işe yarar.

Bu Hatadan Çıkarılacak Daha Geniş Bir Ders

VxRail eklentisindeki “credentials are not valid” hatası aslında modern altyapıların doğası hakkında oldukça öğretici bir vakadır. Konteyner tabanlı, mikroservis mimarili sistemler hayatımıza esneklik ve ölçeklenebilirlik getirdi, ama beraberinde yeni türden hata senaryolarını da getirdi. Eskiden monolitik bir uygulamada “vCenter’a bağlanamıyorum” hatası genellikle çok dar bir kümeyi ifade ederdi. Bugün ise bu hatanın arkasında DNS, sertifika, ağ, konteyner orkestrasyon ve hatta firewalld davranışı gibi pek çok katman gizli olabilir.

Bu durum sistem yöneticisinden iki şey ister: birincisi, hata mesajını olduğu gibi kabul etmemek. Mesaj “kimlik bilgileri geçersiz” diyor olabilir ama gerçek hiç de öyle olmayabilir. İkincisi, log okumayı bir alışkanlık haline getirmek. Modern sistemler mesajlarla değil, log akışlarıyla konuşur. Logları okumayı öğrenmek, bu sistemleri yönetmenin ön koşuludur.

Üçüncü ve belki de en önemli çıkarım, “zararsız” görünen komutların izini sürmektir. firewall-cmd --reload örneği bunun altın değerinde bir göstergesidir. Klasik Linux dünyasında onlarca yıldır kullanılan bu komut, modern konteyner tabanlı bir sistemde bambaşka sonuçlar doğurabilir. Eski bilgi her zaman yeni sistemde geçerli olmayabilir — bunu içselleştirmek, üretim ortamında küçük büyük pek çok krizi önler.

Son Sözler ve Pratik Notlar

Üretim ortamlarında değişiklik yapmadan önce her zaman bir yedek planınız olsun. VxRail Manager’ın anlık görüntüsünü almak veya sanal makinenin yedeğini doğrulamak, beklenmedik bir durumda size hayat kurtaran bir geri dönüş yolu sağlar. Mümkünse müdahalelerinizi planlı bakım pencerelerinde yapın — gece 03:00’te baskı altında çözüm üretmek hiç kimsenin istediği bir senaryo değildir.

Dell’in resmi bilgi tabanı makaleleri çok değerli kaynaklardır, ama her ortamın kendine özgü koşulları olduğunu unutmayın. Makaledeki adımlar genellikle “saf” bir VxRail kurulumunu varsayar; sizin ortamınızda özel ağ topolojileri, üçüncü parti sertifika otoriteleri, özelleştirilmiş güvenlik duvarı kuralları gibi farklılıklar olabilir. Bu nedenle adımları körü körüne uygulamak yerine her birinin neden yapıldığını anlayarak ilerlemek, hem sorunu çözmenizi hem de gelecekte benzer durumları daha hızlı tanımanızı sağlar.

Son olarak — ve bunu defalarca tekrar etmekten çekinmeyeceğim — kararsız kaldığınız her noktada Dell Destek’e başvurmaktan utanç duymayın. VxRail gibi entegre çözümlerde destek ekibi, sahaya geniş bir bilgi havuzuyla çıkar. Bir destek talebi açmak, kendi başınıza saatlerce uğraşıp daha derin bir soruna yol açmaktan her zaman daha akıllıcadır.