VM listesi ile hizmet envanteri arasındaki fark
Bir vCenter ekranında sanal makinelerin açık olduğunu görmek, bu makinelerin sunduğu hizmetlerin sağlıklı olduğunu göstermez. Bir VM içinde işletim sistemi, uygulama, veritabanı ve zamanlanmış işler bulunabilir. Bunların her birinin farklı sahipleri ve bağımlılıkları olabilir. Yararlı bir envanter; yönetim nesnelerini, çalışma konumunu, misafir sistem bilgisini ve kurumsal hizmet ilişkisini ayrı katmanlarda ele alır. Böylece planlı bakım sırasında yalnızca kaç VM bulunduğunu değil, hangi iş hizmetinin incelenmesi gerektiğini sorabilirsiniz.
vCenter hiyerarşisi çalışma bağımlılığı değildir
Datacenter, cluster, resource pool ve folder aynı anlamı taşımaz. Folder düzenleme ve yetkilendirme bağlamı sağlar; fiziksel arıza alanı değildir. Cluster birden fazla host’un hesaplama kaynaklarını birlikte temsil eder. VM’nin resource pool üyeliği de o anda hangi host üzerinde çalıştığıyla aynı ilişki değildir. Envanter modelinde içerir, kaynak ayırır ve üzerinde çalışır ilişkilerini ayrı adlandırın. Aksi hâlde idari bir klasör değişikliği, uygulamanın fiziksel konumu değişmiş gibi yorumlanabilir.
VM kimliği ve vMotion sonrası güncellik
VM adları değişebilir; aynı ad farklı yönetim ortamlarında tekrar kullanılabilir. Kaynak vCenter kimliğiyle birlikte managed object referansını ve uygun UUID alanlarını koruyun. Kopyalama veya yeniden kayıt gibi olaylarda eşleştirme kurallarını ayrıca doğrulayın. VM’nin runtime.host ilişkisi zamanla değişebilir. Taşıma sonrasında eski host bağımlılığını güncelmiş gibi tutmak, bakım etki listesini bozar. Bu nedenle ilişki kaydında kaynak ve gözlem zamanı bulunmalı; geçmiş yerleşim ile son bilinen yerleşim açıkça ayrılmalıdır.
Datastore bir fiziksel disk değildir
Bir VM’nin dosyaları birden fazla datastore ile ilişkili olabilir. Datastore nesnesinden doğrudan tek bir fiziksel diske atlamak doğru değildir. VMFS, NFS ve dağıtık depolama düzenlerinde alttaki bağımlılık modeli değişir. Sanal disk, datastore, depolama servisi ve erişim yolu arasındaki bağlantıları ayrı doğrulayın. Yönetim API’sinde görülebilen ilişki burada başlangıç noktasıdır. Storage sisteminin kendi envanteri olmadan controller, disk grubu veya fiziksel disk seviyesindeki etkiyi kesin olarak açıklayamazsınız.
Sanal ağdan fiziksel switch portuna kadar
VM’nin sanal ağ kartı, bağlı port group ve sanal switch bilgisi ağ yolunun yalnızca bir bölümünü gösterir. Host uplink’i, fiziksel NIC, switch portu, VLAN ve yönlendirme bağlamı da önemlidir. Distributed switch ile standard switch aynı yönetim modeline sahip değildir. Fiziksel eşleştirmede cihaz envanteri, izin verilen komşuluk verisi ve onaylı kablolama bilgisi birlikte kullanılabilir. Aynı VLAN numarasını farklı lokasyonlarda görmek, iki ağın aynı yayın alanı olduğunu tek başına kanıtlamaz.
Misafir işletim sistemi uygulamayı tamamen açıklamaz
Guest bilgileri kullanılan araçların ve erişimin kapsamına bağlıdır. IP adresi, hostname veya işletim sistemi adı eksik ya da eski olabilir. VM içinde çalışan veritabanının hangi uygulamalar tarafından kullanıldığı, sanallaştırma envanterinden kendiliğinden çıkmaz. Uygulama sahipliği ve servis bağımlılıkları için uygulama envanteri, yapılandırma bilgisi veya onaylanmış diğer kaynaklar gerekir. Kurumsal kayıtta misafir sistem gözlemini, uygulama sorumlusunun onayladığı hizmet ilişkisinden ayırın. İki bilgi çeliştiğinde teknik kaynak idari sahipliği otomatik olarak değiştirmemelidir.
Örnek: iki host aynı storage bağımlılığını paylaşabilir
Bir uygulamanın ön yüzü ve veritabanı farklı ESXi host’larında çalışıyor olsun. Bu dağılım host arızasına karşı belirli bir ayrışma sağlar; fakat iki VM aynı depolama hizmetine veya aynı ağ geçidine bağlı olabilir. Storage bakımı öncesinde yalnızca VM–host dağılımını kontrol etmek bu ortak bağımlılığı kaçırır. Önce ilgili datastore’ları kullanan VM’leri, ardından bu VM’lerle ilişkilendirilmiş hizmetleri inceleyin. HA yapılandırmasının varlığını da kesintisizlik garantisi olarak yorumlamayın; kapasite, erişim ve uygulama davranışı ayrı sorulardır.
Envanter kabul testinde hangi durumlar denenmeli?
Seçilen bir VM’nin yeniden adlandırılması, host değiştirmesi ve ağ bağlantısının güncellenmesi kayıtta doğru görünmelidir. Salt okunur hesabın yetki kapsamı daraldığında görünmeyen nesneler otomatik olarak silinmiş sayılmamalıdır. Datastore veya host erişim sorunu, veri toplama sorunu ve gerçek nesne silinmesi ayrı durumlar olarak ele alınmalıdır. Örnek hizmet için VM, ESXi, storage ve ağ ilişkilerini kaynak ekranlarıyla karşılaştırın. Testin çıktısı, doğrulanan ilişkiler ve henüz kanıtlanamayan sınırlar olmalıdır.
Argamos ile VMware bilgisini iş etkisine bağlayın
Argamos VMware kaynak bilgisini, envanter ve hizmet yönetiminin ortak bağlamında değerlendirmeyi sağlar. Atanmış Edge Runtime kaynak erişimini yürütür; teknik gözlem, sahiplik ve ilgili operasyon kayıtları birlikte ele alınır. İlk değerlendirmede bir cluster ve kritik bir uygulama seçerek veri kapsamını sınırlandırın. vSphere sürümünü, API erişimini ve okunabilen alanları netleştirin. VM kontrolü, otomatik taşıma veya bütün fiziksel ağın kendiliğinden keşfi yerine, doğrulanmış ilişkiler üzerinden bakım ve incident değerlendirmesine odaklanın.
Envanter modeli: hızlı başvuru
| Katman / kayıt | Tutulacak bilgi | Operasyonel anlam |
|---|---|---|
| VM kimliği | vCenter kaynak kimliği, nesne referansı, UUID alanları | Ad değişikliği ile yeni VM’yi ayırır |
| Çalışma konumu | VM → güncel ESXi host; gözlem zamanı | Taşıma sonrası bakım kapsamını günceller |
| Depolama | Sanal disk → datastore → doğrulanmış storage kaydı | Mantıksal depolama ile fiziksel kaynağı ayırır |
| Ağ | vNIC → port group → switch/uplink → fiziksel port | Eksik veya doğrulanmış bağlantı sınırını gösterir |
Teknik kaynaklar
Platform kavramları için resmî dokümantasyon. Kurulumunuzun sürümü ve erişim kapsamıyla birlikte değerlendirin.