Ana içeriğe geç

SecuraWall.com

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

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

UPS Boyutlandırma Rehberi: Sunucu Odası İçin VA ve Watt

UPS seçimi yalnız toplam watt değerine bakılarak yapılmamalıdır; gerçek yük, güç faktörü, büyüme payı, istenen çalışma süresi ve cihazın giriş gereksinimleri birlikte değerlendirilmelidir.

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

Bu Konu Neden Önemli?

UPS seçimi yalnız toplam watt değerine bakılarak yapılmamalıdır; gerçek yük, güç faktörü, büyüme payı, istenen çalışma süresi ve cihazın giriş gereksinimleri birlikte değerlendirilmelidir.

Karar Verirken Kontrol Edilecek Noktalar

Gerçek watt tüketimini ölçün veya üretici verisinden hesaplayın.

VA ve watt limitlerinin ikisini de kontrol edin.

İstenen akü çalışma süresini iş ihtiyacına göre belirleyin.

Gelecek büyüme için güvenli kapasite payı bırakın.

Mimari ve çalışma modeli

UPS seçimi watt ve VA sınırlarını aynı anda karşılamalıdır. Güç faktörü yükün W/VA oranıdır; çalışma süresi akü, gerçek yük ve koşullara bağlıdır. Yalnız VA etiketiyle seçim yapılmaz. Jeneratör geçişi, kontrollü kapanma, bypass ve bakım erişimi ayrı işletim gereksinimleridir.

  1. 1Ölçülen W ve VA
  2. 2UPS sınırları
  3. 3Akü/runtime seçimi
  4. 4Kapanma ve geçiş testi
Watt, VA, gerçek yükte runtime ve kalan güç yolunu ayrı doğrulayın.

Tasarım parametreleri

Watt ve VA
Gerçek yükün hem W hem VA değerini UPS sınırlarıyla karşılaştırın; güç faktörü W/VA ilişkisidir.
Runtime ve yaşlanma
Batarya süresini modelin gerçek yük eğrisinden çıkarın; sıcaklık, yaş ve büyüme payını ayrıca değerlendirin.

Hesap ve uygulama örneği

Örnek 2.000 W yük ve 0,9 güç faktörü yaklaşık 2.222 VA görünür güç gerektirir. Yüzde 25 büyüme payıyla yaklaşık 2.500 W ve 2.778 VA hesabı oluşur. Bu sayılar çalışma süresini vermez; seçilen modelin yük-akü eğrisi ve kontrollü kapanma süresi ayrıca doğrulanır.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
UPS kapasitesi yeterli ama süre kısaBatarya yaşı, yük değişimi veya yanlış runtime varsayımı olabilir.Ölçülen yükü üretici eğrisi ve batarya sağlık kaydıyla karşılaştırın.

Kabul ve doğrulama kontrolleri

  1. Watt, VA, gerçek yükte runtime ve kalan güç yolunu ayrı doğrulayın.
  2. Gerçek yükü W ve VA olarak ölçüp iki UPS sınırını da doğrulayın.
  3. İstenen süreyi üreticinin yük-runtime eğrisiyle karşılaştırın.
  4. Onaylı bakımda şebeke kaybı ve kontrollü kapanış akışını test edin.
  5. UPS, PDU ve PSU besleme yollarını fiziksel etiketleriyle kaydedin.
  6. Batarya alarmının doğru kişiye ulaştığını doğrulayın.

İlgili kavramlar

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.

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.

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.

Failover ve failback

Failover, hizmetin başka bir bileşene geçmesidir; failback, tercih edilen konuma geri alınmasıdır. İkisi aynı risk ve işlem sırasına sahip olmayabilir. DNS güncellemesi, yönlendirme, oturumlar, veri geriliği ve uygulama bağımlılıkları kullanıcı kesintisini belirler. Otomatik geçişin hangi koşulda tetiklendiğini, yanlış alarmda ne olacağını ve geri dönüş onayını tanımlayın. Arızayı yalnız sanal makineyi kapatarak test etmek tüm hata türlerini kapsamaz. Ağ, depolama ve yönetim katmanı arızalarının ayrı etkilerini ölçün.

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

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

BİRİNCİL / RESMİ KAYNAKLAR

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ı!