Compute Tasarımı, Dayanıklılık ve Yaşam Döngüsü

Ön koşul: iş yükü baseline’ı, CPU topolojisi, bellek/NUMA ve I/O yerelliğini kanıtla inceleyebilmelisin. Bu dersin sonunda host sayısını toplam kaynak bölme işleminden çıkaramayacak; normal, tepe, bakım, arıza ve büyüme senaryolarını ayrı kapasite kapıları olarak hesaplayabilecek; yönetim düzlemi, firmware, güvenlik, enerji ve destek yaşam döngüsünü teknik tasarıma katabilecek; Arven için karşılaştırılabilir compute karar paketi hazırlayabileceksin. Yaklaşık 29 dakika anlatı ve örnek, 16 dakika vaka, 10 dakika kontrollerdir. Belirli marka/model kazananı veya güncel lisans kuralı seçilmez.

Compute tasarımının birimi tek sunucu değildir; kabul edilen hizmet sonucunu hedef koşullarda taşıyan platformdur. Toplam vCPU ve RAM’i bir host kapasitesine bölmek başlangıç aritmetiği olabilir, tasarım değildir. İş yükü yerleşimi, socket/NUMA sınırı, lisans, anti-affinity, hata alanı, bakım boşluğu, boot storm, yedekleme, güvenlik ve operasyon ortak kapasiteyi değiştirir. Beş senaryo ayrı yazılır. Normal koşul olağan iş karışımını; tepe koşulu ay sonu veya kampanyayı; bakım koşulu planlı çıkarılan host ve yolları; arıza koşulu beklenmedik kaybı ve yeniden başlatma dalgasını; büyüme koşulu tarihli iş sürücülerini gösterir. En yüksek yüzdeyi bütün kaynaklara uygulamak yerine her iş yükünün CPU, working set, I/O ve eşzamanlılık davranışı modellenir. Kabul eşiği her senaryoda latency, throughput, batch bitişi ve hata oranıyla doğrulanır. Yerleşim kuralı kapasite kadar önemlidir. Aynı failure domain’deki iki uygulama örneği sayısal olarak yedekli görünse de tek olayda kaybolabilir. Çok büyük VM, host üzerinde çalışsa bile bakım sırasında diğer hosta sığmayabilir. Affinity/anti-affinity, reserved capacity ve admission control gibi politikalar tasarım hipotezidir; platformun gerçekten uyguladığı ve operasyonun izlediği kanıtlanır. Tasarım girdilerinin her biri kaynak ve tarih taşır. Toplam envanter, son üç aylık tepe, planlanan proje ve ürün datasheet’i farklı güven düzeyindedir. Ölçülmeyen büyüme ve sıkıştırma gibi oranlar senaryo olarak tutulur. Kesin BoM, tüm TBD’ler kapanmasa bile üretilebilir; ancak hangi varsayıma, risk kabulüne ve yeniden boyutlandırma koşuluna bağlı olduğu açık yazılır.

Dayanıklılık, bileşen sayısından önce korunulan olayla tanımlanır. Tek PSU arızası, fan, DIMM, CPU socket, host, rack PDU, top-of-rack switch, yönetim ağı, firmware hatası veya ortak yazılım sürümü farklı failure domain’lerdir. İki güç kaynağı aynı PDU’ya bağlıysa enerji yolu tekildir. Çok sayıda host aynı hatalı firmware veya otomasyonla aynı anda etkilenebilir. Fiziksel ve mantıksal ortak nedenler diyagramda gösterilir. RAS özellikleri hata düzeltme, algılama, izolasyon veya kurtarma sağlayabilir; isimleri platforma göre değişir. ECC belleğin her hatayı kesintisiz düzelttiği, hot-plug özelliğinin bütün bileşenlerde kullanılabildiği veya yedek parçanın otomatik hizmeti geri getirdiği varsayılmaz. Desteklenen davranış, telemetry, alarm, failover ve operasyon prosedürü OEM belgesi ile test kanıtına bağlanır. Bakım yapılabilirlik arıza dayanıklılığından ayrıdır. Firmware, BIOS, hypervisor ve sürücü güncellemesinde host boşaltma süresi, kalan kapasite, iş yükü lisans/affinity sınırı ve geri dönüş yöntemi yazılır. Rolling update planı tüm hostların aynı anda güncellenmemesini sağlayabilir; fakat yeni ve eski sürümlerin birlikte desteklenme penceresi doğrulanır. Firmware bağımlılık sırası ve kesintisiz güncelleme iddiası test edilmeden taahhüt edilmez. Kurtarma yolu uygulama katmanına kadar izlenir. Host yeniden başlatma başarısı veri tabanı bütünlüğü, bağımlı servis, oturum ve kullanıcı kabulünü otomatik kanıtlamaz. Testte olay enjeksiyonu, gözlenen algılama zamanı, otomatik/manuel eylem, hizmetin geri dönme süresi, veri etkisi ve beklenmeyen davranış kaydedilir. Başarısız test tasarım girdisidir; saklanmaz.

Sunucunun veri düzlemi kadar yönetim düzlemi de tasarlanır. Out-of-band yönetim; envanter, telemetry, power control, console, firmware ve olay yönetimi sağlar. Yönetim ağı segmentasyonu, kimlik, rol, MFA desteği, sertifika, log, saat, yedekli erişim ve break-glass prosedürü açıklanır. Redfish gibi standart arayüzler otomasyonu kolaylaştırabilir; yine de OEM implementasyonu, desteklenen schema/action ve güvenlik ayarı doğrulanır. Firmware platformun boot ve işletimi için temel bileşendir. NIST SP 800-193 dayanıklılığı protect, detect ve recover amaçlarıyla ele alır. Satın alma kararı yalnız secure boot özelliğini işaretlemek değildir: yetkisiz değişiklikten koruma, bütünlük ihlalini algılama, bilinen iyi duruma güvenli kurtarma ve bu süreçlerin operasyon sahipliği sorgulanır. BMC, BIOS/UEFI, NIC/HBA, drive ve accelerator firmware envanteri ile bağımlılık sırası tutulur. Yaşam döngüsü teklif tarihinde bitmez. Satış, destek, güvenlik güncellemesi ve parça bulunabilirliği tarihleri; OS/hypervisor/driver uyumluluk matrisi; firmware baseline; kapasite büyüme slotları; bakım becerisi ve decommission yöntemi kaydedilir. “Beş yıl destek” kapsam, başlangıç, hizmet seviyesi ve istisna bilinmeden requirement değildir. Güncel üretici kaynakları teklif öncesi ve değişiklik öncesi yeniden doğrulanır. Enerji kararı nameplate watt toplamı değildir. Idle, tipik ve tepe güç; farklı yük düzeylerindeki throughput/latency; güç kaynağı verimi; termal/rack sınırı ve iş tamamlanma süresi birlikte ölçülür. SPEC güç-performans metodolojisi karşılaştırmanın aynı iş modeli, sistem sınırı, ölçüm cihazı ve koşullarla yapılmasını ister. En düşük anlık güç, işi daha uzun çalıştırıp toplam enerjiyi artırabilir. TuneD profilleri de throughput, latency ve power arasında seçim yapar; ölçülmeden evrensel profil önerilmez.

Arven dört hostluk mevcut cluster’ı üç büyük veya beş orta hostla yenilemeyi değerlendirir. Üç büyük host daha az yönetim nesnesi ve olası lisans avantajı sunabilir; tek host kaybında daha büyük kapasite ve failure impact yaratır. Beş orta host daha küçük arıza adımı sağlayabilir; rack portu, enerji, destek ve yönetim sayısını artırır. İki seçenek iş yükü, yerleşim, bakım, arıza, büyüme ve yaşam döngüsü ölçülerinde karşılaştırılmadan seçilmez. Arven paketinde ERP büyük VM’in NUMA sınırı, portal throughput’u, ay sonu batch’i ve yönetim servisleri yerleşir. Bir host bakımdayken tepe yük ve restart dalgası modellenir. Güç yolları, NIC/HBA bağlantıları, yönetim ağı ve ortak firmware domain’leri çizilir. Beş yıllık büyüme tek yüzde değil, tarihli yeni proje ve hacim sürücüleriyle senaryolanır. Enerji karşılaştırması aynı iş hacminde idle, tipik ve tepeyi; toplam iş süresini ve rack termal sınırını taşır. Karar matrisi her ölçüte ağırlık vermeden önce kapı ölçütlerini ayırır: hizmet eşiğini veya destek/uyumluluğu geçemeyen seçenek puan toplamıyla kurtarılamaz. Geçen seçenekler maliyet, operasyon karmaşıklığı, enerji, büyüme ve riskte karşılaştırılır. Sonuç hangi kaynaklara, testlere ve varsayımlara dayandığını; hangi değişiklikte yeniden açılacağını gösterir. Teknik doğruluk “A daha iyi” cümlesi değil, kararın sınırlarını dürüstçe açıklamaktır.