Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Teknik Rehber · Server & Sanallaştırma

Sunucu Odası Sıcaklık ve Nem Değerleri Nasıl Planlanır?

Sunucu odası çevresel kontrolü yalnız klima set değerinden ibaret değildir; rack giriş sıcaklığı, hava akışı, sıcak/soğuk koridor, nem ve alarm eşikleri birlikte izlenmelidir.

SON TEKNİK GÖZDEN GEÇİRME:
Server & Sanallaştırma

Bu Konu Neden Önemli?

Sunucu odası çevresel kontrolü yalnız klima set değerinden ibaret değildir; rack giriş sıcaklığı, hava akışı, sıcak/soğuk koridor, nem ve alarm eşikleri birlikte izlenmelidir.

Karar Verirken Kontrol Edilecek Noktalar

Ölçümü oda ortasından değil kritik rack girişlerinden alın.

Hava kısa devresini ve sıcak hava geri dönüşünü azaltın.

Sıcaklık ve nem alarmlarını izleme sistemine bağlayın.

Üretici çevresel limitlerini ekipman bazında kontrol edin.

Mimari ve çalışma modeli

Çevresel tasarım cihaz hava girişindeki koşula göre yapılmalıdır; duvar termostatı bütün rackleri temsil etmez. Sıcak hava geri dolaşımı, yük değişimi ve sensör yeri sonucu etkiler. Bağıl nem, sıcaklık ve çiy noktası birlikte değerlendirilir. Üreticinin cihaz sınıfı ve geçerli çevresel sınırları tercih edilen işletim aralığından ayrılmalıdır.

  1. 1Rack giriş ölçümü
  2. 2Hava akışı ve yük
  3. 3Soğutma arızası
  4. 4Alarm ve müdahale
Sensör konumu, zaman serisi ve soğutma arızasındaki yükselme hızını birlikte saklayın.

Tasarım parametreleri

Hava giriş ölçümü
Rack üst, orta ve alt girişlerini ölçün; oda ortalaması lokal sıcak noktayı gizleyebilir.
Çiy noktası ve değişim hızı
Sıcaklık, bağıl nem ve çiy noktasını cihaz çevresel sınıfıyla değerlendirin; alarm müdahale süresini kapsamalıdır.

Hesap ve uygulama örneği

Örnek ölçümde rack üst, orta ve alt girişlerine sensör yerleştirin. Yoğun yükte ve bir soğutma ünitesi kaybında değerleri kaydedin. Alarm eşiğini tek bir evrensel sıcaklık sayısından değil cihaz şartları, artış hızı ve müdahale süresinden çıkarın.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Termostat normal ama cihaz sıcakSıcak hava geri dolaşımı, tıkalı giriş veya hatalı sensör konumu olabilir.Rack giriş zaman serisini yük ve hava akışıyla karşılaştırın.

Kabul ve doğrulama kontrolleri

  1. Sensör konumu, zaman serisi ve soğutma arızasındaki yükselme hızını birlikte saklayın.
  2. Rack girişindeki sensörleri cihaz şartlarıyla karşılaştırın.
  3. Yoğun yükte üst, orta ve alt noktaların zaman serisini kaydedin.
  4. Onaylı soğutma arızası senaryosunda müdahale süresini ölçün.
  5. Nem ve çiy noktasını sıcaklıkla aynı zaman aralığında izleyin.
  6. Alarmların enerji veya ağ kesintisinde de iletilebildiğini sınayın.

İlgili kavramlar

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.

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.

Bağımlılık ve yeniden başlatma sırası

Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Hizmetlerin yeniden başlatılma sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.

Kapasite ve kullanılabilir pay

Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalı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.

Güven sınırı ve hata alanı

Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.

Birincil teknik dokümantasyon

Who · How · Why

Bu İçerik Nasıl Hazırlandı?

Kim?

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.

Nasıl?

Teknik kriterler + birincil kaynaklar

Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.

Neden?

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.

SON TEKNİK GÖZDEN GEÇİRME

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
Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!