Sunucuların raflar arasındaki dağılımını optimize etme

Sohbetlerden birinde bana bir soru soruldu:

— Sunucuların raflara düzgün şekilde nasıl paketleneceği hakkında okuyabileceğim bir şey var mı?

Böyle bir metni bilmediğimi fark ettim ve kendi metnimi yazdım.

Öncelikle bu metin fiziksel veri merkezlerindeki (DC) fiziksel sunucularla ilgilidir. İkinci olarak, oldukça fazla sayıda sunucu olduğuna inanıyoruz: yüzbinlerce; daha küçük bir sayı için bu metnin bir anlamı yok. Üçüncüsü, üç kısıtlamamız olduğunu düşünüyoruz: raflardaki fiziksel alan, raf başına güç kaynağı ve bitişik raflardaki sunucuları bağlamak için bir ToR anahtarı kullanabilmemiz için rafların sıralar halinde durmasına izin vermek.

Sorunun cevabı büyük ölçüde hangi parametreyi optimize ettiğimize ve en iyi sonucu elde etmek için neyi değiştirebileceğimize bağlıdır. Örneğin, daha fazla büyümeye daha fazla yer bırakmak için minimum yer kaplamamız gerekiyor. Ya da belki rafların yüksekliğini, raf başına gücü, PDU'daki soketleri, bir anahtar grubundaki raf sayısını (1, 2 veya 3 raf için bir anahtar), kabloların uzunluğunu ve çekme işini seçme özgürlüğüne sahibiz ( bu, sıraların sonlarında kritik öneme sahiptir: sıradaki 10 raf ve anahtar başına 3 raf ile, kabloları başka bir sıraya çekmeniz veya anahtardaki bağlantı noktalarını yetersiz kullanmanız gerekecektir), vb., vb. Ayrı hikayeler: sunucuların seçimi ve DC'lerin seçimi, bunların seçildiğini varsayacağız.

Bazı nüansları ve ayrıntıları, özellikle de sunucuların ortalama/maksimum tüketimini ve elektriğin bize nasıl sağlandığını anlamak iyi olacaktır. Yani, 230V'luk bir Rus güç kaynağımız ve raf başına bir fazımız varsa, o zaman 32A'lık bir makine ~7kW'ı kaldırabilir. Diyelim ki nominal olarak raf başına 6kW ödedik. Sağlayıcı tüketimimizi her raf için değil, yalnızca 10 raflık bir sıra için ölçerse ve makine koşullu olarak 7 kW'lık bir kesmeye ayarlanmışsa, o zaman teknik olarak tek bir rafta 6.9 kW, diğerinde 5.1 kW tüketebiliriz ve her şey yoluna girecek; cezalandırılmayacak.

Genellikle asıl amacımız maliyetleri en aza indirmektir. Ölçülecek en iyi kriter TCO'daki (toplam sahip olma maliyeti) azalmadır. Aşağıdaki parçalardan oluşur:

  • CAPEX: DC altyapısı, sunucular, ağ donanımı ve kablolamanın satın alınması
  • OPEX: DC kiralama, elektrik tüketimi, bakım. OPEX hizmet ömrüne bağlıdır. 3 yıl olarak kabul etmek mantıklıdır.

Sunucuların raflar arasındaki dağılımını optimize etme

Genel pastadaki bireysel parçaların ne kadar büyük olduğuna bağlı olarak, en pahalı olanı optimize etmemiz ve geri kalanların kalan tüm kaynakları mümkün olduğunca verimli bir şekilde kullanmasına izin vermemiz gerekiyor.

Diyelim ki mevcut bir DC'miz var, H birimlik raf yüksekliği (örneğin, H=47), raf başına elektrik Prack (Prack=6kW) var ve h=2U iki birimli sunucu kullanmaya karar verdik. Anahtarlar, bağlantı panelleri ve düzenleyiciler için raftan 2..4 üniteyi çıkaracağız. Onlar. fiziksel olarak rafımızda Sh=rounddown((H-2..4)/h) sunucularımız var (yani raf başına Sh = rounddown((47-4)/2)=21 sunucu). Şunu hatırlayalım Ş.

Basit durumda, bir raftaki tüm sunucular aynıdır. Toplamda, bir rafı sunucularla doldurursak, her sunucuda ortalama olarak Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) güç harcayabiliriz. Basitlik açısından burada anahtar tüketimini göz ardı ediyoruz.

Şimdi bir adım atalım ve maksimum sunucu tüketimi Pmax'ın ne olduğunu belirleyelim. Çok basit, çok etkisiz ve tamamen güvenliyse, sunucunun güç kaynağında yazılanları okuruz - işte bu.

Daha karmaşık ve daha verimliyse, tüm bileşenlerin TDP'sini (termal tasarım paketi) alıp özetliyoruz (bu çok doğru değil ama mümkün).

Genellikle bileşenlerin TDP'sini bilmiyoruz (CPU hariç), bu nedenle en doğru ama aynı zamanda en karmaşık yaklaşımı kullanıyoruz (bir laboratuvara ihtiyacımız var) - gerekli konfigürasyona sahip deneysel bir sunucuyu alıyoruz ve yüklüyoruz, örneğin Linpack (CPU ve bellek) ve fio (diskler) ile tüketimi ölçüyoruz. Ciddiye alırsak testler sırasında soğuk koridorda en sıcak ortamı da oluşturmamız gerekiyor çünkü bu hem fan tüketimini hem de CPU tüketimini etkileyecektir. Bu spesifik yük altında, bu spesifik koşullarda, spesifik bir konfigürasyona sahip belirli bir sunucunun maksimum tüketimini elde ederiz. Sadece yeni sistem donanım yazılımının, farklı bir yazılım sürümünün ve diğer koşulların sonucu etkileyebileceğini kastediyoruz.

Pserv'e ve bunu Pmax ile nasıl karşılaştırdığımıza dönelim. Hizmetlerin nasıl çalıştığını ve teknik direktörünüzün sinirlerinin ne kadar güçlü olduğunu anlamak önemli.

Hiçbir risk almazsak, tüm sunucuların aynı anda maksimum kapasiteyi tüketmeye başlayabileceğine inanıyoruz. Aynı anda DC'ye bir giriş meydana gelebilir. Bu koşullar altında bile altyapının hizmet vermesi gerekir, dolayısıyla Pserv ≡ Pmax. Bu, güvenilirliğin kesinlikle önemli olduğu bir yaklaşımdır.

Eğer teknoloji direktörü sadece ideal güvenliği değil aynı zamanda şirketin parasını da düşünüyorsa ve yeterince cesursa, o zaman buna karar verebilirsiniz.

  • Tedarikçilerimizi yönetmeye başlıyoruz, özellikle bir girdideki düşüşü en aza indirmek için planlı pik yük zamanlarında planlı bakımı yasaklıyoruz;
  • ve/veya mimarimiz raf/sıra/DC kaybetmenize izin verir ancak hizmetler çalışmaya devam eder;
  • ve/veya yükü raflar arasında yatay olarak iyi bir şekilde dağıtırız, böylece hizmetlerimiz hiçbir zaman tek bir rafta maksimum tüketime ulaşmayacaktır.

Burada sadece tahmin etmek değil, tüketimi izlemek ve sunucuların normal ve yoğun koşullar altında elektriği gerçekte nasıl tükettiğini bilmek de çok faydalıdır. Bu nedenle, biraz analizden sonra teknoloji direktörü sahip olduğu her şeyi sıkıştırıyor ve şöyle diyor: "Raf başına maksimum sunucu tüketiminin ulaşılabilir maksimum ortalamasının, maksimum tüketimin **çok** altında olduğuna dair isteğe bağlı bir karar veriyoruz", koşullu olarak Pserv = 0.8* Pmaks.

Ve 6kW'lık bir raf artık Pmax = 16W olan 375 sunucuyu değil, Pserv = 20W * 375 = 0.8W olan 300 sunucuyu barındırabilir. Onlar. %25 daha fazla sunucu. Bu çok büyük bir tasarruf; sonuçta hemen %25 daha az rafa ihtiyacımız var (ve aynı zamanda PDU'lardan, anahtarlardan ve kablolardan da tasarruf edeceğiz). Böyle bir çözümün ciddi bir dezavantajı, varsayımlarımızın hâlâ doğru olup olmadığını sürekli izlememiz gerekmesidir. Yeni aygıt yazılımı sürümünün fanların çalışmasını ve tüketimini önemli ölçüde değiştirmediğini, yeni sürümle birlikte aniden gelişen gelişimin sunucuları çok daha verimli kullanmaya başlamadığını (okuyun: sunucuda daha fazla yük ve daha fazla tüketim elde ettiler). Sonuçta, hem ilk varsayımlarımız hem de sonuçlarımız anında yanlış olur. Bu, sorumlu bir şekilde ele alınması gereken bir risktir (veya kaçınılması ve daha sonra açıkça az kullanılan raflar için ödeme yapılması).

Önemli bir not; mümkünse, farklı hizmetlere ait sunucuları raflar arasında yatay olarak dağıtmaya çalışmalısınız. Bu, bir hizmet için bir grup sunucunun geldiğinde, "yoğunluğu" artırmak için rafların dikey olarak paketlendiği durumların meydana gelmemesi için gereklidir (çünkü bu şekilde daha kolaydır). Gerçekte, bir rafın aynı hizmetin aynı düşük yüklü sunucularıyla, diğerinin ise eşit derecede yüksek yüklü sunucularla dolu olduğu ortaya çıktı. İkinci düşme olasılığı önemli ölçüde daha yüksektir, çünkü yük profili aynı olup, yükün artması sonucunda bu raftaki tüm sunucular aynı miktarda tüketim yapmaya başlar.

Sunucuların raflardaki dağıtımına dönelim. Fiziksel raf alanına ve güç sınırlamalarına baktık, şimdi ağa bakalım. 24/32/48 N bağlantı noktasına sahip anahtarları kullanabilirsiniz (örneğin, 48 bağlantı noktalı ToR anahtarlarımız var). Neyse ki, çıkış kablolarını düşünmüyorsanız çok fazla seçenek yok. Rnet grubunda raf başına bir anahtarımız, iki veya üç raf için bir anahtarımız olduğu senaryoları değerlendiriyoruz. Bana öyle geliyor ki bir grupta üçten fazla raf zaten çok fazla, çünkü... raflar arasındaki kablolama sorunu çok daha büyük hale gelir.

Böylece, her ağ senaryosu için (bir grupta 1, 2 veya 3 raf), sunucuları raflara dağıtırız:

Srack = min(Sh, yuvarlama(Prack/Pserv), yuvarlama(N/Rnet))

Böylece, grup halinde 2 raflı seçenek için:

Srack2 = min(21, yuvarlama(6000/300), yuvarlama(48/2)) = min(21, 20, 24) = raf başına 20 sunucu.

Kalan seçenekleri aynı şekilde değerlendiriyoruz:

Srak1 = 20
Srak3 = 16

Ve neredeyse oradayız. Tüm sunucularımızı S dağıtmak için raf sayısını sayıyoruz (1000 olsun):

R = yuvarlama(S / (Srack * Rnet)) * Rnet

R1 = yuvarlama(1000 / (20 * 1)) * 1 = 50 * 1 = 50 raf

R2 = yuvarlama(1000 / (20 * 2)) * 2 = 25 * 2 = 50 raf

R3 = yuvarlama(1000 / (16 * 3)) * 3 = 25 * 2 = 63 raf

Daha sonra, raf sayısına, gereken anahtar sayısına, kablolara vb. göre her seçeneğin TCO'sunu hesaplıyoruz. TCO'nun daha düşük olduğu seçeneği seçiyoruz. Kâr!

Seçenek 1 ve 2 için gereken raf sayısı aynı olmasına rağmen fiyatlarının farklı olacağını unutmayın; ikinci seçenek için anahtar sayısı yarısı kadardır ve gerekli kabloların uzunluğu daha uzundur.

Not: Raf başına güç ve raf yüksekliği ile oynama imkanınız varsa değişkenlik artar. Ancak süreç, sadece seçenekler üzerinden gidilerek yukarıda açıklanana indirgenebilir. Evet, daha fazla kombinasyon olacak, ancak yine de çok sınırlı sayıda olacak - hesaplama için rafa giden güç kaynağı 1 kW'lık adımlarla artırılabilir, tipik raflar sınırlı sayıda standart boyutta gelir: 42U, 45U, 47U, 48U , 52U. Ve burada Excel'in Veri Tablosu modundaki Durum Analizi hesaplamalara yardımcı olabilir. Alınan plakalara bakıyoruz ve minimumu seçiyoruz.

Kaynak: habr.com

Yorum ekle