Di salah satu obrolan saya ditanyai pertanyaan:
β Apakah ada yang bisa saya baca tentang cara mengemas server dengan benar ke dalam rak?
Saya menyadari bahwa saya tidak mengetahui teks seperti itu, jadi saya menulis teks saya sendiri.
Pertama, teks ini membahas tentang server fisik di pusat data fisik (DC). Kedua, kami yakin servernya cukup banyak: ratusan-ribuan; untuk jumlah yang lebih kecil, teks ini tidak masuk akal. Ketiga, kami menganggap bahwa kami memiliki tiga kendala: ruang fisik di rak, catu daya per rak, dan membiarkan rak berdiri dalam barisan sehingga kami dapat menggunakan satu saklar ToR untuk menghubungkan server di rak yang berdekatan.
Jawaban atas pertanyaan ini sangat bergantung pada parameter apa yang kita optimalkan dan apa yang dapat kita variasikan untuk mencapai hasil terbaik. Misalnya, kita hanya perlu mengambil ruang minimum agar dapat menyisakan lebih banyak ruang untuk pertumbuhan lebih lanjut. Atau mungkin kita mempunyai kebebasan dalam memilih ketinggian rak, daya per rak, soket di PDU, jumlah rak dalam kelompok sakelar (satu sakelar untuk 1, 2 atau 3 rak), panjang kabel dan pekerjaan penarikan ( ini sangat penting di ujung baris: dengan 10 rak berturut-turut dan 3 rak per sakelar, Anda harus menarik kabel ke baris lain atau kurang menggunakan port di sakelar), dll., dll. Cerita terpisah: pemilihan server dan pemilihan DC, kami berasumsi bahwa mereka terpilih.
Sebaiknya kita memahami beberapa nuansa dan detailnya, khususnya, konsumsi rata-rata/maksimum server, dan bagaimana listrik disuplai ke kami. Jadi, jika kita memiliki catu daya Rusia sebesar 230V dan satu fase per rak, maka mesin 32A dapat menangani ~7kW. Katakanlah kita membayar nominal 6kW per rak. Jika penyedia mengukur konsumsi kita hanya untuk deretan 10 rak, dan bukan untuk setiap rak, dan jika mesin disetel pada batas kondisional 7 kW, maka secara teknis kita dapat mengonsumsi 6.9 kW di satu rak, 5.1 kW di rak lain, dan semuanya akan baik-baik saja - tidak dapat dihukum.
Biasanya tujuan utama kami adalah meminimalkan biaya. Kriteria terbaik untuk mengukurnya adalah pengurangan TCO (total biaya kepemilikan). Ini terdiri dari bagian-bagian berikut:
- CAPEX: pembelian infrastruktur DC, server, perangkat keras jaringan, dan kabel
- OPEX: Sewa DC, konsumsi listrik, pemeliharaan. OPEX bergantung pada masa pakai. Masuk akal untuk berasumsi bahwa itu adalah 3 tahun.
Bergantung pada seberapa besar masing-masing bagian dalam keseluruhan kue, kita perlu mengoptimalkan yang paling mahal, dan membiarkan sisanya menggunakan semua sumber daya yang tersisa seefisien mungkin.
Katakanlah kita memiliki DC yang sudah ada, ada tinggi rak H unit (misalnya, H=47), listrik per rak Prack (Prack=6kW), dan kami memutuskan untuk menggunakan server dua unit h=2U. Kami akan menghapus 2..4 unit dari rak untuk sakelar, panel tempel, dan pengatur. Itu. secara fisik, kami memiliki server Sh=rounddown((H-2..4)/h) di rak kami (yaitu Sh = rounddown((47-4)/2)=21 server per rak). Mari kita ingat Sh ini.
Dalam kasus sederhana, semua server di rak adalah identik. Secara total, jika kita mengisi rak dengan server, maka pada setiap server kita dapat menghabiskan rata-rata daya Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Untuk mempermudah, kami mengabaikan konsumsi saklar di sini.
Mari kita minggir dan tentukan berapa Pmax konsumsi server maksimum. Jika ini sangat sederhana, sangat tidak efektif dan sepenuhnya aman, maka kita membaca apa yang tertulis di catu daya server - ini dia.
Jika lebih kompleks dan efisien, maka kami mengambil TDP (paket desain termal) semua komponen dan menjumlahkannya (ini tidak sepenuhnya benar, tetapi mungkin saja).
Biasanya kami tidak mengetahui TDP komponen (kecuali CPU), jadi kami mengambil pendekatan yang paling benar, tetapi juga pendekatan yang paling rumit (kami memerlukan laboratorium) - kami mengambil server eksperimental dengan konfigurasi yang diperlukan dan memuatnya, misalnya, dengan Linpack (CPU dan memori) dan fio (disk), kami mengukur konsumsi. Jika kita menganggapnya serius, kita juga perlu menciptakan lingkungan terhangat di koridor dingin selama pengujian, karena hal ini akan mempengaruhi konsumsi kipas dan konsumsi CPU. Kami mendapatkan konsumsi maksimum server tertentu dengan konfigurasi spesifik dalam kondisi spesifik di bawah beban spesifik ini. Yang kami maksudkan adalah firmware sistem baru, versi perangkat lunak yang berbeda, dan kondisi lain dapat memengaruhi hasil.
Jadi, kembali ke Pserv dan bagaimana kita membandingkannya dengan Pmax. Ini masalah memahami cara kerja layanan dan seberapa kuat keberanian direktur teknis Anda.
Jika kami tidak mengambil risiko sama sekali, kami yakin semua server secara bersamaan dapat mulai mengonsumsi secara maksimal. Pada saat yang sama, satu masukan ke DC mungkin terjadi. Bahkan dalam kondisi seperti ini, infra harus memberikan layanan, sehingga Pserv β‘ Pmax. Ini adalah pendekatan yang mengutamakan keandalan.
Jika direktur teknologi tidak hanya memikirkan tentang keamanan yang ideal, tetapi juga tentang keuangan perusahaan dan cukup berani, maka Anda 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, namun layanan tetap berfungsi;
- dan/atau kami menyebarkan beban dengan baik secara horizontal di seluruh rak, sehingga layanan kami tidak akan pernah mencapai konsumsi maksimum dalam satu rak secara bersamaan.
Di sini sangat berguna untuk tidak sekedar menebak, tetapi untuk memantau konsumsi dan mengetahui bagaimana sebenarnya server mengkonsumsi listrik dalam kondisi normal dan puncak. Oleh karena itu, setelah beberapa analisis, direktur teknologi memeras semua yang dia miliki dan berkata: "kami membuat keputusan dengan kemauan keras bahwa rata-rata maksimum yang dapat dicapai dari konsumsi server maksimum per rak adalah **jauh** di bawah konsumsi maksimum," dengan syarat Pserv = 0.8* Pmaks.
Dan kemudian rak 6kW tidak lagi dapat menampung 16 server dengan Pmax = 375W, tetapi 20 server dengan Pserv = 375W * 0.8 = 300W. Itu. 25% lebih banyak server. Ini adalah penghematan yang sangat besar - lagipula, kita akan segera membutuhkan rak yang 25% lebih sedikit (dan kita juga akan menghemat PDU, sakelar, dan kabel). Kerugian serius dari solusi semacam ini adalah kita harus terus memantau apakah asumsi kita masih benar. Bahwa versi firmware baru tidak secara signifikan mengubah pengoperasian kipas dan konsumsi, bahwa pengembangan tiba-tiba dengan rilis baru tidak mulai menggunakan server jauh lebih efisien (baca: mereka mencapai beban lebih besar dan konsumsi lebih besar di server). Lagi pula, baik asumsi awal maupun kesimpulan kita langsung menjadi salah. Ini adalah risiko yang harus diambil secara bertanggung jawab (atau dihindari dan kemudian dibayar untuk rak yang jelas-jelas kurang dimanfaatkan).
Catatan penting - Anda harus mencoba mendistribusikan server dari berbagai layanan secara horizontal di seluruh rak, jika memungkinkan. Hal ini diperlukan agar tidak terjadi situasi ketika satu kumpulan server tiba untuk satu layanan, rak-raknya dikemas secara vertikal untuk meningkatkan "kepadatan" (karena lebih mudah). Pada kenyataannya, ternyata satu rak diisi dengan server identik dengan beban rendah dari layanan yang sama, dan rak lainnya diisi dengan server dengan beban yang sama tinggi. Kemungkinan jatuhnya yang kedua jauh lebih tinggi, karena profil bebannya sama, dan semua server yang bersama-sama di rak ini mulai mengonsumsi jumlah yang sama sebagai akibat dari peningkatan beban.
Mari kembali ke distribusi server di rak. Kita telah melihat ruang rak fisik dan keterbatasan daya, sekarang mari kita lihat jaringannya. Anda dapat menggunakan sakelar dengan port 24/32/48 N (misalnya, kami memiliki sakelar ToR 48 port). Untungnya, tidak banyak pilihan jika Anda tidak memikirkan kabel yang putus. Kami sedang mempertimbangkan skenario ketika kami memiliki satu saklar per rak, satu saklar untuk dua atau tiga rak di grup Rnet. Menurut saya lebih dari tiga rak dalam satu grup sudah terlalu banyak, karena... masalah pemasangan kabel antar rak menjadi jauh lebih besar.
Jadi, untuk setiap skenario jaringan (1, 2 atau 3 rak dalam satu grup), kami mendistribusikan server di antara rak:
Srack = min(Sh, pembulatan(Prack/Pserv), pembulatan(N/Rnet))
Jadi, untuk opsi dengan 2 rak dalam satu grup:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 server per rak.
Kami mempertimbangkan opsi lainnya dengan cara yang sama:
Srack1 = 20
Srack3 = 16
Dan kita hampir sampai. Kami menghitung jumlah rak untuk mendistribusikan semua server kami S (biarkan 1000):
R = pembulatan(S / (Srack * Rnet)) * Rnet
R1 = pembulatan(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rak
R2 = pembulatan(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rak
R3 = pembulatan(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rak
Selanjutnya, kami menghitung TCO untuk setiap opsi berdasarkan jumlah rak, jumlah sakelar yang diperlukan, pemasangan kabel, dll. Kami memilih opsi dimana TCO lebih rendah. Laba!
Perhatikan bahwa meskipun jumlah rak yang dibutuhkan untuk opsi 1 dan 2 sama, harganya akan berbeda karena jumlah sakelar untuk opsi kedua adalah setengahnya, dan panjang kabel yang dibutuhkan lebih panjang.
PS Jika Anda memiliki kesempatan untuk bermain dengan kekuatan per rak dan tinggi rak, variabilitasnya meningkat. Namun prosesnya dapat direduksi menjadi seperti yang dijelaskan di atas hanya dengan melalui opsi. Ya, akan ada lebih banyak kombinasi, tetapi jumlahnya masih sangat terbatas - catu daya ke rak untuk perhitungan dapat ditingkatkan dalam langkah 1 kW, rak tipikal tersedia dalam jumlah terbatas dengan ukuran standar: 42U, 45U, 47U, 48U , 52U. Dan di sini analisis Bagaimana-Jika Excel dalam mode Tabel Data dapat membantu penghitungan. Kami melihat pelat yang diterima dan memilih minimum.
Sumber: www.habr.com