Bu Konu Neden Önemli?
ECC bellek, belirli bellek hatalarını algılayıp düzeltebilmek için hata düzeltme kodları kullanan sunucu sınıfı bellek yaklaşımıdır.
Karar Verirken Kontrol Edilecek Noktalar
Sunucu platformunun desteklediği DIMM tipini doğrulayın.
Bellek kanallarını üretici kurallarına göre doldurun.
Kapasite kadar frekans ve kanal dengesini de değerlendirin.
Kritik iş yüklerinde bellek hatası telemetrisini izleyin.
Mimari ve çalışma modeli
ECC desteği CPU, bellek denetleyicisi, anakart ve DIMM türünün birlikte uyumuna bağlıdır. Registered/unbuffered, kanal yerleşimi ve hız kuralları birbirinden farklıdır. Düzeltilen hata ile düzeltilmeyen hata ayrı izlenmelidir. Tek bir geçmiş hata modülün hemen bozuk olduğunu kanıtlamaz; tekrar, yuva ve zaman ilişkisi değerlendirilir.
- 1Platform uyumluluğu
- 2DIMM ve kanal yerleşimi
- 3ECC olayları
- 4Bakım ve doğrulama
Tasarım parametreleri
- ECC ve platform desteği
- CPU, anakart, BIOS ve DIMM desteğini birlikte doğrulayın; yalnız ECC modül takmak aktif korumayı kanıtlamaz.
- Hata sınıfı ve kayıt
- Düzeltilebilir ve düzeltilemez hata sayaçlarını, slot bilgisini ve üretici değiştirme kriterini izleyin.
- Yoğun saat iş yükü
- CPU, bellek, disk ve ağ ölçümlerini aynı zaman aralığında toplayın. Bir kaynak yüzdesi tek başına sizing kararı verdirmez.
- N-1 kapasitesi
- Bir bileşen kaybedildiğinde kalan kapasiteyi hesaplayın. Normal durumda boş pay görünmesi arızada yeterli kapasite bulunduğunu kanıtlamaz.
- Uyumluluk zinciri
- CPU, firmware, sürücü, hypervisor ve konuk uygulamaların destek koşullarını birlikte inceleyin.
- İşletim rezervi
- Backup, migration, bakım ve büyüme aynı kaynaklarla yarışır. Rezervi yalnız ortalama yük üzerinden belirlemeyin.
Hesap ve uygulama örneği
Örnek bakımda iki DIMM eklemeden önce platformun kanal doldurma kuralını kontrol edin. Sonrasında görünen kapasite, bellek hızı ve donanım hata logunu doğrulayın. Aynı yuvada tekrarlayan hata modül, yuva veya denetleyici ayrımı gerektirir; bellek değişimini veri kurtarma stratejisinin yerine koymayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Tek slotta hatalar artıyor | DIMM, slot veya bellek kanalı problemi olabilir. | BMC/OS kayıtlarını aynı zaman aralığında eşleştirip üretici tanı prosedürünü uygulayın. |
| Düşük CPU kullanımına rağmen uygulama yavaş | Depolama, kilit, tek çekirdek veya zamanlama beklemesi toplam CPU değerinde görünmeyebilir. | Uygulama gecikmesini çekirdek, disk ve hypervisor beklemeleriyle eşleştirin. |
| Arıza sonrası host aşırı yükleniyor | Kapasite planı normal dağılım için yapılmış, N-1 durumu dışarıda kalmış olabilir. | Kontrollü arıza testinde kalan RAM, CPU ve depolama gecikmesini ölçün. |
| Değişiklikten sonra performans kötüleşti | Sürücü, firmware, NUMA yerleşimi veya kaynak ataması değişmiş olabilir. | Aynı iş yükünde önce/sonra karşılaştırma yapın; bir değişkeni bir seferde değiştirin. |
Kabul ve doğrulama kontrolleri
- DIMM kapasitesi, türü, hız ve hata kaydını aynı envanterde tutun.
- Yoğun saat yükünü ve bakım işlerini birlikte temsil eden test çalıştırın.
- Bir host veya bağlantı kaybında hizmet ve veri yazmasını doğrulayın.
- Konuk işletim sistemi ve uygulama desteğini resmî matriste kontrol edin.
- Yeniden başlatma sonrasında aygıt, servis ve depolama sağlığını doğrulayın.
- Kapasite hesabının ham ve kullanılabilir değerlerini ayrı saklayın.
İlgili kavramlar
Bellek hatası ve ECC
ECC belirli bellek hatalarının algılanmasına ve düzeltilmesine yardımcı olur; bütün hata türlerini veya bütün donanım arızalarını gidermez. Destek, bellek modülü kadar CPU, anakart ve firmware ile ilişkilidir. Düzeltilebilir hata sayısının artması bakım gereksinimine işaret edebilir; düzeltilemeyen hata ise hizmeti durdurabilir. DIMM yuvası ve zaman bilgisini içeren donanım kayıtlarını inceleyin. Modül karıştırma ve yerleştirme kuralları üretici platformuna göre doğrulanmalıdır. Bellek kapasitesi planı ile güvenilirlik planını ayırın; ECC backup veya HA yerine geçmez.
NUMA yerelliği
NUMA sistemlerde işlemci, kendisine yakın bellekle uzak düğüm belleğine farklı maliyetle erişebilir. Bir sanal makinenin vCPU ve bellek boyutu, fiziksel düğüm kapasitesi ve hypervisor yerleştirmesiyle birlikte değerlendirilir. Daha fazla vCPU vermek her zaman hız kazandırmaz; yerellik kaybı ve zamanlama beklemesi performansı düşürebilir. Fiziksel topolojiyi, VM içindeki görünen topolojiyi ve gerçek iş yükünün bellek davranışını birlikte kaydedin. Değişikliği aynı yük altında önce/sonra karşılaştırın; yalnız CPU yüzdesi yerine uygulama gecikmesini ve uzak bellek etkisini inceleyin.
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun