Dalam salah satu obrolan saya ditanya pertanyaan:
- Dan ada sesuatu untuk dibaca, bagaimana mengemas server di rak dengan benar?
Saya menyadari bahwa saya tidak tahu teks seperti itu, jadi saya menulis sendiri.
Pertama, teks ini adalah tentang server fisik di pusat data fisik (DC). Kedua, kami percaya bahwa ada banyak server: ratusan atau ribuan, untuk jumlah yang lebih kecil, teks ini tidak masuk akal. Ketiga, kami percaya bahwa kami memiliki tiga pembatas: ruang fisik di rak, daya ke rak, dan membiarkan rak berdiri di barisan, sehingga kami dapat menggunakan satu sakelar ToR untuk menghubungkan server di rak tetangga.
Jawaban atas pertanyaan sangat tergantung pada parameter mana yang kami optimalkan dan apa yang dapat kami variasikan untuk mencapai hasil terbaik. Sebagai contoh, kita hanya perlu mengambil ruang minimum untuk meninggalkan lebih banyak untuk pertumbuhan lebih lanjut. Atau mungkin kita memiliki kebebasan dalam memilih ketinggian rak, daya per rak, soket di PDU, jumlah rak dalam kelompok sakelar (satu sakelar per 1, 2 atau 3 rak), panjang kabel dan pekerjaan penarik (ini sangat penting di ujung baris: dengan 10 rak berturut-turut dan 3 rak di sakelar, Anda harus menarik kabel di baris lain atau menggunakan port di sakelar secara bergantian), dll., dll. Cerita terpisah: pemilihan server dan pemilihan DC, kami mengasumsikan bahwa mereka dipilih.
Akan menyenangkan untuk memahami beberapa nuansa dan detail, khususnya, konsumsi rata-rata / maksimum server, dan bagaimana kami disuplai dengan listrik. Jadi, jika kita memiliki catu daya Rusia 230V dan satu fase per rak, maka mesin 32A dapat menampung ~ 7kW. Misalkan kita secara nominal membayar 6kW per rak. Jika penyedia mengukur konsumsi kita hanya untuk serangkaian 10 rak, dan tidak untuk setiap rak, dan jika mesin berada pada batas konvensional 7 kW, maka secara teknis kita bisa melahap 6,9 kW di rak terpisah, di 5,1 kW lain dan semuanya akan baik-baik saja - tidak dapat dihukum.
Biasanya tujuan utama kami adalah untuk meminimalkan biaya. Kriteria pengukuran terbaik adalah pengurangan TCO (total biaya kepemilikan). Ini terdiri dari potongan-potongan berikut:
- CAPEX: pengadaan infrastruktur DC, server, perangkat keras jaringan dan pemasangan kabel
- OPEX: Sewa DC, listrik yang dikonsumsi, perawatan. OPEX tergantung pada umur layanan. Masuk akal untuk menganggap itu sama dengan 3 tahun.
Tergantung pada seberapa besar masing-masing potongan dalam seluruh pie, kita perlu mengoptimalkan yang paling mahal, dan membiarkan sisanya menggunakan semua sumber daya yang tersisa seefisien mungkin.
Misalkan kita memiliki DC yang ada, ada ketinggian rak unit H (misalnya, H = 47), listrik ke rak P
rak (
rak P = 6 kW), dan kami memutuskan untuk menggunakan h = 2U server dua unit. Kami melepas 2..4 unit dari rak ke sakelar, panel tambalan, dan penyelenggara. Yaitu secara fisik, kami memiliki server S
h = rounddown ((H-2..4) / h) di rak kami (mis., S
h = rounddown ((47-4) / 2) = 21 server per rak). Ingat ini S
h .
Dalam kasus sederhana, semua server di rak adalah sama. Total, jika kita memalu rak dengan server, maka pada setiap server kita dapat menghabiskan rata-rata daya P
serv = P
rack / S
h (P
serv = 6000 W / 21 = 287 W). Untuk kesederhanaan, kami mengabaikan beralih konsumsi di sini.
Kami mengambil langkah ke samping dan menentukan berapa konsumsi server maksimum adalah P
maks . Jika itu sangat sederhana, sangat tidak efisien dan sepenuhnya aman, maka kita membaca apa yang tertulis pada catu daya server - itu saja.
Jika lebih rumit, lebih efisien, maka kami mengambil TDP (paket desain termal) dari semua komponen dan merangkum (ini tidak terlalu benar, tetapi bisa jadi begitu).
Biasanya kami tidak tahu komponen TDP (kecuali untuk CPU), jadi kami mengambil yang paling benar, tetapi juga pendekatan yang paling sulit (kami membutuhkan laboratorium) - kami mengambil server eksperimental dari konfigurasi yang diperlukan dan memuatnya, misalnya, dengan Linpack (CPU dan memori) dan fio (disk) mengukur konsumsi. Jika Anda menganggapnya serius, Anda juga perlu menciptakan lingkungan terhangat di koridor dingin selama pengujian, karena ini akan memengaruhi konsumsi kipas dan konsumsi CPU. Kami mendapatkan konsumsi maksimum dari server tertentu dengan konfigurasi spesifik dalam kondisi spesifik ini di bawah beban spesifik ini. Kami hanya berarti bahwa firmware baru dari sistem, versi lain dari perangkat lunak, kondisi lain dapat mempengaruhi hasilnya.
Secara total, kita kembali ke P
serv dan bagaimana kita membandingkannya dengan P
maks . Ini adalah pertanyaan untuk memahami bagaimana layanan bekerja dan seberapa kuat saraf Anda di teknisi Anda.
Jika Anda tidak mengambil risiko sama sekali, maka kami percaya bahwa semua server dapat segera mulai mengkonsumsi secara maksimal. Pada saat yang sama, satu input ke DC dapat dibentuk. Infra dalam kondisi ini harus menyediakan layanan, oleh karena itu P
serv ≡ P
maks . Ini adalah pendekatan di mana keandalan sangat penting.
Jika teknisi tidak hanya berpikir tentang keamanan yang sempurna, tetapi juga tentang uang perusahaan dan cukup berani, maka kita dapat memutuskan bahwa
- kami mulai mengelola vendor kami, khususnya, kami melarang pemeliharaan terjadwal pada saat beban puncak yang direncanakan untuk meminimalkan penurunan satu input;
- dan / atau arsitektur kami memungkinkan Anda kehilangan rak / baris / DC, dan layanan terus bekerja;
- dan / atau kami dengan baik menyebarkan beban secara horizontal di rak, sehingga layanan kami tidak akan pernah melompat ke konsumsi maksimum dalam satu rak bersama-sama.
Sangat berguna di sini bukan hanya untuk menebak, tetapi untuk memantau konsumsi dan mengetahui bagaimana sebenarnya dalam kondisi normal dan puncak server mengkonsumsi listrik. Oleh karena itu, setelah beberapa analisis, techdir memampatkan semua yang dimilikinya dan mengatakan: "kami dengan sengaja memutuskan bahwa rata-rata maksimum yang dapat dicapai dari konsumsi server maksimum per rak adalah ** jauh lebih rendah ** lebih rendah dari konsumsi maksimum", dengan syarat P
serv = 0,8 *
Maks .
Dan kemudian di rak 6kW, tidak lagi 16 server dengan P
max = 375W, tetapi 20 server dengan P
serv = 375W \ * 0.8 = 300W. Yaitu 25% lebih banyak server. Ini adalah penghematan yang sangat besar - setelah semua, kami segera membutuhkan rak 25% lebih sedikit (kami juga menghemat PDU, sakelar dan kabel). Kekurangan serius dari keputusan semacam itu - perlu untuk terus memantau bahwa asumsi kita masih benar. Bahwa versi baru dari firmware tidak secara signifikan mengubah operasi penggemar dan konsumsi, bahwa pengembangan rilis baru tiba-tiba tidak mulai menggunakan server jauh lebih efisien (baca, kami mendapat lebih banyak beban dan lebih banyak konsumsi di server). Setelah semua, maka kedua asumsi dan kesimpulan awal kami segera menjadi salah. Ini adalah risiko yang harus diambil secara bertanggung jawab (atau dihindari dan kemudian dibayar untuk rak yang jelas-jelas kurang muatan).
Catatan penting - Anda harus mencoba mendistribusikan server dari berbagai layanan di rak secara horizontal, jika memungkinkan. Ini diperlukan agar cerita tidak terjadi ketika satu batch server untuk satu layanan tiba, rak tersumbat secara vertikal untuk meningkatkan "kepadatan" (karena lebih mudah). Pada kenyataannya, ternyata satu rak dijejali dengan server-server dengan satu layanan yang sama, dan lainnya sama-sama bermuatan tinggi. Probabilitas jatuh yang kedua jauh lebih tinggi, profil pemuatan adalah sama, dan semua server bersama-sama di rak ini mulai mengkonsumsi jumlah yang sama sebagai hasil dari peningkatan beban.
Kembali ke distribusi server di rak. Kami memeriksa keterbatasan fisik ruang rak dan keterbatasan daya, dan sekarang lihat jaringannya. Anda dapat menggunakan sakelar pada port 24/32/48 N (misalnya, kami memiliki sakelar ToR 48-port). Untungnya, tidak banyak pilihan jika Anda tidak berpikir tentang kabel break-out. Kami mempertimbangkan skenario ketika kami memiliki satu sakelar per rak, satu sakelar ke dua atau tiga rak di grup R
net . Tampak bagi saya bahwa lebih dari tiga rak dalam grup sudah terlalu banyak, karena masalah pemasangan kabel di antara rak menjadi jauh lebih besar.
Jadi, untuk setiap skenario jaringan (rak 1, 2 atau 3 dalam grup) kami mendistribusikan server ke rak:
S
rack = min (S
h , rounddown (
rak P / P
serv ), rounddown (N / R
net ))
Jadi, untuk opsi dengan 2 rak dalam grup:
S
rack 2 = min (21, rounddown (6000/300), rounddown (48/2)) = min (21, 20, 24) = 20 server per rak.
Demikian pula, kami mempertimbangkan opsi yang tersisa:
S
rak 1 = 20
Rak 3 = 16
Dan kita hampir sampai. Kami menghitung jumlah rak untuk distribusi semua server S kami (biarlah 1000):
R = roundup (S / (S
rack * R
net )) * R
netR
1 = pengumpulan (1000 / (20 * 1)) * 1 = 50 * 1 = 50 rak
R
2 = pembulatan (1000 / (20 * 2)) * 2 = 25 * 2 = 50 rak
R
3 = pembulatan (1000 / (16 * 3)) * 3 = 21 * 3 = 63 rak
Selanjutnya, kami mempertimbangkan TCO untuk setiap opsi berdasarkan jumlah rak, jumlah sakelar yang diperlukan, kabel, dll. Kami memilih opsi di mana TCO kurang. Untung!
Perhatikan bahwa meskipun jumlah rak yang diperlukan untuk opsi 1 dan 2 adalah sama, harganya akan berbeda, karena jumlah sakelar untuk opsi kedua adalah setengahnya, dan panjang kabel yang dibutuhkan lebih panjang.
PS Jika ada peluang untuk memainkan kekuatan di rak dan ketinggian rak, variabilitas meningkat. Tetapi prosesnya dapat dikurangi menjadi di atas, cukup memilah-milah pilihan. Ya, akan ada lebih banyak kombinasi, tetapi masih dalam jumlah yang sangat terbatas - kekuatan untuk rak untuk penghitungan dapat ditingkatkan dengan peningkatan 1 kW, rak tipikal memiliki jumlah ukuran terbatas: 42U, 45U, 47U, 48U, 48U, 52U. Dan di sini, analisis What-If Excel dalam mode Tabel Data dapat membantu menghitung. Kami melihat pelat yang diterima dan memilih minimum.