Cluster tek bir sunucu kaydı değildir
Proxmox VE ortamını envantere tek bir cluster adıyla eklemek işletim ayrıntılarını gizler. Yönetim kümesi, node’lar, QEMU sanal makineleri, LXC konteynerleri, depolama tanımları ve ağ bağlantıları ayrı kayıtlar olarak düşünülmelidir. Ardından bunların üzerinde çalışan uygulamalar ve kurumsal hizmetler ilişkilendirilir. Buradaki amaç her teknik ayrıntıyı gereksiz yere çoğaltmak değil, bir bakım veya arıza sırasında hangi ortak kaynağın hangi hizmetleri etkileyebileceğini açıklayacak kadar doğru bilgi tutmaktır.
VMID hangi kapsamda anlamlıdır?
VMID’yi tek başına kurum genelinde benzersiz kimlik kabul etmeyin. Farklı Proxmox ortamlarında aynı numara kullanılabilir; silinen bir misafirin numarası daha sonra başka bir kayıt için yeniden kullanılabilir. Envanter tasarımında kaynak cluster kimliği, misafir türü, VMID ve yaşam döngüsü birlikte değerlendirilmelidir. Ad değişikliği veya node taşıması yeni bir varlık gibi yorumlanmamalıdır. Kaynak yeniden kurulduğunda ya da yedekten farklı bir sistem oluşturulduğunda uygulanacak kimlik kuralı ayrıca belgelenmelidir.
QEMU VM ve LXC aynı işletim sınırına sahip değildir
QEMU sanal makinesi ile LXC konteynerini yalnızca çalışan misafir başlığı altında birleştirmek önemli farkları siler. VM kendi misafir işletim sistemi katmanıyla değerlendirilirken LXC host çekirdeğini paylaşır. Envanterde tür, node, kaynak tahsisi, disk veya rootfs bağlantıları ve ağ arayüzleri ayrı görünmelidir. Uygulama ilişkisi ise bu teknik türden bağımsız olarak tanımlanır. Örneğin bir web uygulamasının konteynerde, veritabanının VM’de bulunması ortak hizmet kaydı kurmaya engel değildir.
Storage adı aynıysa veri de aynı yerde midir?
Hayır. Aynı storage tanımının birden fazla node üzerinde görünmesi, alttaki verinin ortak olduğunu tek başına göstermez. Yerel depolama ile paylaşımlı depolama ayrımını açık tutun. Disk veya rootfs volume kaydı, storage kimliği, depolama türü, node kapsamı ve erişilebilirlik birlikte değerlendirilmelidir. Directory, LVM-thin, ZFS, NFS veya Ceph gibi düzenlerde alt bağımlılıklar farklılaşır. Bir storage tanımını shared olarak işaretlemek, yerel veriyi kendiliğinden paylaştırmaz. Fiziksel disk eşlemesi için node veya storage tarafındaki kanıt gerekir.
Bridge ve VLAN kaydı fiziksel topolojiyi tamamlamaz
Bir misafirin vmbr0 köprüsüne bağlı olduğunu bilmek, trafiğin hangi fiziksel porttan çıktığını her zaman açıklamaz. Bridge’in fiziksel portu, varsa bond üyeleri, VLAN yapılandırması ve switch tarafındaki bağlantı birlikte incelenmelidir. Aynı bridge adı farklı node’larda farklı bağlantılara karşılık gelebilir. Bu yüzden kimlik kapsamına node’u ekleyin. SDN kullanılan yapılarda mantıksal ağ katmanını da ayrıca kaydedin. Kablo bağlantısı ile uygulamanın erişebilirliği farklı olgulardır; yönlendirme ve güvenlik politikaları da sonucu etkiler.
Quorum, HA ve yedekleme farklı soruları yanıtlar
Cluster yönetimindeki quorum durumu, bir VM’nin uygulama seviyesinde sağlıklı olduğu anlamına gelmez. Corosync iletişimi gecikme ve ağ kararlılığı bakımından ayrıca değerlendirilmelidir. HA yapılandırması, ilgili kaynakların yeniden çalıştırılmasıyla bağlantılı işletim davranışını belirler; yedekleme ise veri geri dönüşü için ayrı bir konudur. Envanterde cluster iletişim ağı, HA kapsamı ve yedekleme bağımlılıklarını aynı ilişki türüne sıkıştırmayın. Bakım kararında yönetim iletişiminin, depolama erişiminin ve uygulama sürekliliğinin her biri ayrı kontrol gerektirir.
Örnek: node bakımı neden yalnızca VM listesinden planlanamaz?
Üç node’lu örnek bir ortamda bakım yapılacak node üzerindeki misafirleri listelediğinizi düşünün. Bu liste başlangıçtır. Hangi disklerin yerel olduğu, hedef node’un aynı ağa ve depolamaya erişip erişmediği, kapasite ve uygulama kısıtları da önemlidir. Ortak storage varsa onun bağımlılıkları da bakım alanına girebilir. Envanter, bu soruları doğru kayıtlara yönlendirmelidir; taşımanın her durumda mümkün veya kesintisiz olduğunu varsaymamalıdır. Burada anlatılan çalışma bir değerlendirme senaryosudur, otomatik taşıma talimatı değildir.
Salt okunur kapsamı nasıl doğrularsınız?
Entegrasyon değerlendirmesinde API sürümü, token veya hesabın yetkileri, erişilebilir node’lar ve okunabilen misafir alanları belirlenmelidir. Test kapsamına farklı misafir türlerini, yerel ve paylaşımlı storage’ı, taşınmış bir VM’yi ve geçici erişim kaybını alın. Bir kaynağın görünmemesiyle silinmesi aynı sonuç olmamalıdır. Yedekleme konumu gibi hassas ayrıntıları yalnızca gerekli kapsamda tutun. Başarı ölçütünü ekranın dolması yerine, seçilen örneklerin kimlik ve bağlantılarının kaynakla tutarlı olması üzerinden tanımlayın.
Argamos değerlendirmesinde Proxmox’u nereye yerleştirmelisiniz?
Argamos’un kaynak gözlemi, yönetilen envanter ve hizmet ilişkisi yaklaşımı bu değerlendirme için ortak çerçeve sağlar. Proxmox’u kurumunuzdaki sürüm, API ve veri kapsamıyla ele alın; bu rehber hazır Proxmox bağlayıcısı veya bütün alanlarda otomatik keşif taahhüdü değildir. Kaynak veri toplama tasarımı atanmış Edge Runtime üzerinden değerlendirilir. Önce bir hizmetin VM veya LXC kaydını, node’unu, storage ve ağ sınırlarını doğrulayın; sonra Argamos üzerinde kurmak istediğiniz sahiplik, incident ve değişiklik bağlamını netleştirin.
Envanter modeli: hızlı başvuru
| Katman / kayıt | Tutulacak bilgi | Operasyonel anlam |
|---|---|---|
| Misafir kimliği | Kaynak cluster, VMID, tür, yaşam döngüsü | Farklı cluster ve yeniden kullanım çakışmalarını ayırır |
| Yerleşim | Misafir → node; son görülme zamanı | Taşıma ile varlık kimliğini birbirinden ayırır |
| Depolama | Disk/rootfs → storage; tür ve node kapsamı | Aynı adı taşıyan yerel kaynakları karıştırmaz |
| Ağ ve cluster | Node kapsamlı bridge, bond, VLAN; Corosync ağı | Misafir trafiği ile yönetim iletişimini ayırır |
Teknik kaynaklar
Platform kavramları için resmî dokümantasyon. Kurulumunuzun sürümü ve erişim kapsamıyla birlikte değerlendirin.