Fiziksel, Sanal ve Bulut Ortamlarında Sayım

Ön koşul: Lisans hakkı, metrik, entitlement, destek ve kaynak hiyerarşisini ayırabiliyor olmalısın. Bu derste fiziksel, sanal ve bulut topolojisinin sayımı nasıl değiştirebileceğini; normal, bakım, arıza ve DR durumlarını aynı hesap defterinde göstermeyi öğreneceksin. Yaklaşık 28 dakika anlatı, 28 dakika Arven çalışması ve 14 dakika kontrol önerilir. İlk adım her yazılım bileşeni için ürün, sürüm, edisyon, sözleşme, etkin tarih ve ölçüm birimini yazmaktır. Sonra gerçekten hangi fiziksel düğümlerin kullanılabildiğini göster: soket sayısı, etkin fiziksel çekirdek, işlemci modeli, cluster üyeliği, yazılımın çalıştığı hostlar ve failover hedefi. Soket, core ve vCPU eşanlamlı değildir. Hyperthreading ile görünen mantıksal işlemciyi fiziksel çekirdek gibi saymak veya soket paketini iki ayrı sunucuya keyfi bölmek yanlış olabilir. Ancak kesin hesap ürün koşulundan gelir. Microsoft'un Windows Server 2025 rehberinde fiziksel çekirdek lisanslaması için belirli işlemci ve sunucu minimumları anlatılır; bu sayı yalnız o ürün ve model bağlamında örnektir. Red Hat Enterprise Linux rehberi, belirli RHEL abonelikleri için fiziksel socket-pair ile sanal node seçeneklerini ayrı açıklar. İkisinden evrensel 'bir sunucu şu kadar lisans' sonucu çıkarılmaz. Arven'in sanallaştırma hostu portal, ERP gateway ve başka VM'ler taşıyorsa donanım envanterindeki tüm çekirdeklerin otomatik aynı yazılımın lisans tabanına girdiği veya yalnız çalışan VM'nin sayıldığı varsayılamaz. Ürün şartında yerleşim sınırı, minimum, etkin çekirdek ve yeniden atama tanımı aranır. BoM'da CPU artırımı veya host eklenmesi teknik kapasiteyi büyütürken lisans hesabını da değiştirebilir. Fiziksel topolojiyi 'bugün' ve hedef tasarım için ayrı kaydet; mevcut entitlement'ın kapsamı hedef mimariyle eşleşmeyebilir.

Sanal ortamda görünen vCPU tahsisi, fiziksel çekirdek kapasitesi, aktif çalışan VM ve lisanslı instance farklı nesnelerdir. Overcommit, CPU scheduler'ın teknik paylaşım davranışıdır; 'daha az fiziksel core olduğu için hak da otomatik daha azdır' demek değildir. Lisans modeli sanal işletim ortamını, fiziksel hostu veya tüm clusterı esas alabilir. VM'lerin hangi hostlarda çalışabileceklerini, anti-affinity kuralını, live migration hedeflerini ve yüksek erişilebilirlikte otomatik yeniden başlatma havuzunu haritalandır. Düğüm bakımında VM'nin taşınacağı host, arıza sonrası çalışacağı host ve test için açılan geçici kopya sözleşme açısından aynı olmayabilir. VM template ve snapshot da kurulu/çalışan yazılım tanımına göre soru yaratabilir; ürün koşulu görülmeden bunlara kesin lisans sonucu atama. Microsoft Product Terms, bazı hakların sürüm, lisans modeli, ek güvence ve yeniden atama şartlarına bağlı olduğunu gösterir. Buradan tüm Microsoft ürünlerinde sınırsız mobility sonucu çıkarılamaz. IBM'in sub-capacity kuralları, yalnız uygun ürün ve uygun sanallaştırma teknolojisinde, gerekli ölçüm/raporlama yükümlülükleriyle daha dar kapasitenin lisanslanabildiğine bir başka üretici örneğidir. IBM'e özgü koşul, Red Hat ya da Microsoft için kural değildir. Arven portal VM'sini gece bakımında ikinci hosta almak teknik olarak kolay olabilir; lisans hakkının bunu nasıl değerlendirdiği ayrı incelenir. Sanal kaynak planı yalnız normal durum ekran görüntüsünden çıkarılmaz. Geçmiş kullanım ölçümü, hedef dağıtım, maksimum eşzamanlı kopya, bakım/arıza takvimi ve otomatik ölçekleme sınırı aynı zaman çizelgesinde gösterilir. İki sitede eşzamanlı çalışan kopya varsa bunu 'pasif DR' etiketiyle gizleme. Lisans uzmanı ürün bazında hangi çalışır/erişilebilir durumun sayıldığını teyit eder. Sonuç Arven BoM, HLD/LLD ve lisans defterine aynı mimari sürümle yansır.

Bulut için önce yazılımın hizmete dahil lisansla mı, müşterinin getirdiği lisansla mı, yoksa ayrı pazar yeri aboneliğiyle mi çalıştığını belirle. Altyapı faturasında bir VM satırı görmek yazılım kullanım hakkının dahil olduğu anlamına gelmez. BYOL seçeneği de 'elimizde anahtar var' demek değildir; ürünün bulut sağlayıcısı, dedicated/shared host modeli, bölge, tenant ve müşterinin anlaşması açısından izin verdiği kullanımı kontrol eder. AWS License Manager, müşteri tarafından tanımlanan metrik ve kuralları kaynaklarla eşleyip izlemeye yardımcı olabilir; AWS dokümanı da kuralların müşterinin anlaşmasına göre dikkatle kurulması gerektiğini söyler. Araç yanlış kuralın hukuki sorumluluğunu ortadan kaldırmaz. AWS Dedicated Hosts BYOL rehberi belirli fiziksel host görünürlüğü ve raporlama seçeneklerini açıklar; her yazılımın orada kullanılabildiği sonucu çıkmaz. Buluta taşınan Arven portalı için geçiş süresince on-prem ve cloud kopyalarının aynı anda çalışması, test ortamı ve geri dönüş penceresi sayımda ayrı senaryolardır. Autoscailing tavanı veya mümkün eşzamanlı kopya sayısı bilinmiyorsa maliyet ve hak miktarı güvenilir hesaplanamaz. DR kopyası soğuk, sıcak veya aktif olabilir; isim değil gerçekten kurulu ve çalışır durum, hak şartı ve kullanım süresi önemlidir. Restore ve failover tatbikatı sırasında kopya açılıyor, veri eşitleniyor ve iş kullanıcıları bağlanıyorsa bu senaryoyu ürün özel şartında sor. RTO hedefi ile lisans sınırlaması çelişiyorsa çözüm teknik olarak toparlansa da ticari olarak sürdürülemeyebilir. Felaket anında hak sonradan satın alınır varsayımıyla kesin DR vaadi verme. Lisans dahil ve BYOL seçeneklerini aynı hesap döneminde karşılaştır: altyapı, yazılım, destek, transfer, operasyon ve çıkış maliyeti birlikte görülmeli. Nihai teklif, geçerli sözleşme ve yetkili ticari teyit olmadan kesinleşmez.

Bir lisans hesabı tek anlık ekran görüntüsüyle yönetilemez. Arven için senaryo defterinde normal, kampanya tepe, planlı bakım, tek host kaybı, DR tatbikatı, gerçek failover, failback ve buluta geçiş dönemlerini yan yana koy. Her satırda yazılım bileşeni, fiziksel/sanal/bulut yerleşim, kullanıcı erişimi, eşzamanlı kopya, metrik, ölçüm aracı, entitlement kaynağı, geçerli dönem, destek ve açık şart bulunur. Hiçbir satır diğerinden otomatik türetilmez: örneğin bakımda iki host erişilebilirken tepe kampanyasında autoscale instance sayısı artabilir. Maksimum teknik kapasiteyi maksimum fiili kullanımdan, sözleşmede kapsanan kullanım sınırından ve maliyet tahmininden ayır. Değişik metrikli iki ürünün adetleri toplanmaz; maliyet ancak kendi fiyat ve kapsamıyla karşılaştırılır. Miktar belirsizse yalnız tek sayı yazıp dipnota TBD koyma; hesap girdisi, alt/üst kullanım zarfı, hangi olayda üst sınıra çıkıldığı ve ticari karar etkisini anlat. Yetkili lisans uzmanından gelen teyit, ürün ve sözleşme revizyonuna bağlı kaydedilir; değişiklikte yeniden açılır. IBM sub-capacity örneğinde uygun ürün/sanallaştırma ve raporlama araçları koşulunun sonucu değiştirebilmesi, kanıt operasyonunun maliyete dahil edilmesi gerektiğini gösterir. Ancak bu IBM modeli Arven'in varsayılan sözleşmesi değildir. Lisans yönetimi bir kerelik satın alma değil yaşam döngüsü faaliyetidir: yeni host, değişen çekirdek, VM taşınma politikası, DR topolojisi, ürün sürümü, destek yenilemesi ve cloud bölgesi değiştiğinde hem teknik hem ticari karar yeniden değerlendirilir. Üç yıllık TCO'da normal kullanım, büyüme, destek ve yenileme, geçişte olası çift kullanım ve izleme/raporlama emeği aynı kapsamda gösterilir. Kesin fiyat veya indirim, geçerli teklif olmadan uydurulmaz. Müşteriye sunulan karar paketi şunu açık söyler: ne biliniyor, hangi belgeyle, hangi senaryo için, hangi hak belirsiz, kim ne zaman doğrulayacak ve olumsuz yanıt gelirse mimari fallback nedir.