Dalam salah satu obrolan saya ditanya sebuah pertanyaan:
—Apakah ada yang bisa saya baca tentang cara mengemas server ke dalam rak dengan benar?
Saya menyadari bahwa saya tidak mengetahui teks seperti itu, jadi saya menulis teks saya sendiri.
Pertama-tama, teks ini membahas tentang... server fisik di pusat data fisik (DC). Kedua, kami berasumsi ada cukup banyak server: ratusan atau ribuan; untuk jumlah yang lebih kecil, teks ini tidak relevan. Ketiga, kami berasumsi kami memiliki tiga batasan: ruang rak fisik, catu daya rak, dan, dengan asumsi rak disusun dalam baris, kami dapat menggunakan satu switch ToR untuk menghubungkan server di rak yang berdekatan.
Jawaban atas pertanyaan ini sangat bergantung pada parameter yang kita optimalkan dan apa yang dapat kita variasikan untuk mencapai hasil terbaik. Misalnya, kita mungkin hanya perlu menggunakan ruang minimum untuk menyisakan lebih banyak ruang bagi pertumbuhan di masa mendatang. Atau mungkin kita memiliki lebih banyak fleksibilitas dalam memilih tinggi rak, daya per rak, stopkontak unit catu daya (PDU), jumlah rak dalam satu grup switch (satu switch per 1, 2, atau 3 rak), panjang kabel, dan biaya pemasangan kabel (ini penting di ujung baris: dengan 10 rak per baris dan 3 rak per switch, kita harus memperpanjang kabel ke baris lain atau memanfaatkan port di switch secara kurang optimal), dll. Topik terpisah: pemilihan server dan pemilihan pusat data; mari kita asumsikan keduanya sudah dipilih.
Akan sangat membantu jika kita memahami beberapa nuansa dan detail, khususnya konsumsi rata-rata/maksimum server dan bagaimana kita mendapatkan pasokan listrik. Misalnya, jika kita memiliki catu daya 230V Rusia dan satu fasa per rak, pemutus sirkuit 32A dapat menangani sekitar 7 kW. Katakanlah kita membayar 6 kW per rak. Jika penyedia mengukur konsumsi kita hanya untuk deretan 10 rak, dan bukan untuk setiap rak, dan jika pemutus sirkuit diatur untuk memotong pada, katakanlah, 7 kW, maka secara teknis kita dapat mengonsumsi 6.9 kW di satu rak, 5.1 kW di rak lainnya, dan semuanya akan baik-baik saja—tanpa penalti.
Tujuan utama kami biasanya adalah meminimalkan biaya. Metrik terbaik untuk mengukurnya adalah mengurangi TCO (total biaya kepemilikan). Komponen-komponennya terdiri dari:
- CAPEX: pembelian infrastruktur pusat data, server, perangkat keras jaringan, dan kabel
- OPEX: sewa pusat data, konsumsi listrik, pemeliharaan. OPEX bergantung pada masa pakai. Perkiraan yang wajar adalah 3 tahun.
Bergantung pada seberapa besar potongan-potongan individual dalam keseluruhan kue, kita perlu mengoptimalkan potongan yang paling mahal, dan membiarkan sisanya menggunakan semua sumber daya yang tersisa seefisien mungkin.
Misalkan kita memiliki pusat data yang sudah ada, dengan tinggi rak H unit (misalnya, H = 47), dan konsumsi daya Prack (Prack = 6 kW). Kita memutuskan untuk menggunakan server dua unit h = 2U. Kita akan mengurangi 2,4 unit dari rak untuk switch, patch panel, dan organizer. Ini berarti secara fisik, rak kita dapat memuat Sh = rounddown((H - 2,4) / h) server (yaitu, Sh = rounddown((47 - 4) / 2) = 21 server per rak). Mari kita ingat Sh ini.
Dalam kasus sederhana, semua server di rak tersebut identik. Jadi, jika kita mengisi rak tersebut serverMaka, konsumsi daya rata-rata untuk setiap server adalah Pserv = Prack/Sh (Pserv = 6000W/21 = 287W). Untuk menyederhanakan, kita mengabaikan konsumsi switch di sini.
Mari kita mundur sejenak dan mendefinisikan konsumsi daya maksimum (Pmax) server. Jika sangat sederhana, sangat tidak efisien, dan sepenuhnya aman, maka baca saja apa yang tertulis di catu daya server—itu saja.
Kalau lebih kompleks dan lebih efisien, maka kita ambil TDP (thermal design package) semua komponen dan jumlahkan (ini tidak sepenuhnya benar, tapi mungkin saja).
Kami biasanya tidak mengetahui TDP komponen (kecuali CPU), jadi kami mengambil pendekatan yang paling akurat, tetapi juga paling kompleks (memerlukan lab): kami mengambil server eksperimental dengan konfigurasi yang diinginkan dan memuatnya dengan, misalnya, Linpack (CPU dan memori) dan fio (drive), untuk mengukur konsumsi daya. Jika kami serius, kami juga harus menciptakan lingkungan yang paling hangat di lorong dingin selama pengujian, karena ini memengaruhi konsumsi kipas dan konsumsi CPU. Ini menghasilkan konsumsi maksimum server tertentu dengan konfigurasi tertentu dalam kondisi tertentu dan beban tertentu. Perlu diingat bahwa firmware sistem baru, versi perangkat lunak yang berbeda, dan kondisi lain dapat memengaruhi hasil.
Jadi, kembali ke Pserv dan bagaimana kita membandingkannya dengan Pmax. Intinya adalah memahami cara kerja layanan dan ketegasan direktur teknis Anda.
Jika kita tidak mengambil risiko apa pun, kita berasumsi bahwa semua server bisa tiba-tiba mulai menghabiskan kapasitas maksimumnya. Pada saat yang sama, satu input ke pusat data bisa gagal. Bahkan dalam kondisi ini, infrastruktur harus menyediakan layanan, jadi Pserv ≡ Pmax. Ini adalah pendekatan yang sangat mengutamakan keandalan.
Jika direktur teknis tidak hanya memikirkan keamanan ideal, tetapi juga tentang uang perusahaan dan cukup berani, maka Anda dapat memutuskan bahwa
- Kami mulai mengelola vendor kami, khususnya, kami melarang pemeliharaan terjadwal selama periode beban puncak yang direncanakan untuk meminimalkan penurunan pada satu masukan;
- dan/atau arsitektur kami memungkinkan Anda kehilangan rak/baris/pusat data, tetapi layanan tetap berfungsi;
- dan/atau kami menyebarkan beban secara horizontal di seluruh rak dengan baik, sehingga layanan kami tidak pernah melonjak ke konsumsi maksimum di satu rak sekaligus.
Di sini, sangat berguna bukan hanya untuk menebak, tetapi juga untuk memantau konsumsi dan mengetahui berapa banyak daya yang sebenarnya dikonsumsi server dalam kondisi normal dan puncak. Oleh karena itu, setelah beberapa analisis, CTO merangkum semua yang mereka miliki dan berkata, "Kami secara sukarela menerima bahwa rata-rata maksimum yang dapat dicapai dari konsumsi server maksimum per rak **jauh** lebih rendah daripada konsumsi maksimum," dengan asumsi Pserv = 0.8 * Pmaks.
Maka rak 6 kW dapat menampung bukan 16 server dengan Pmax = 375 W, tetapi 20 server dengan Pserv = 375 W * 0.8 = 300 W. Itu berarti server 25% lebih banyak. Ini adalah penghematan yang signifikan—bagaimanapun juga, kita langsung membutuhkan rak 25% lebih sedikit (dan kemudian kita akan menghemat PDU, sakelar, dan kabel). Kelemahan serius dari solusi ini adalah kita perlu terus memantau asumsi kita untuk memastikannya masih valid. Bahwa versi firmware baru tidak secara signifikan mengubah operasi kipas dan konsumsi daya, dan bahwa tim pengembangan belum tiba-tiba mulai menggunakan server jauh lebih efisien dengan rilis baru (artinya mereka telah mencapai beban yang lebih tinggi dan konsumsi daya yang lebih tinggi per server). Lagipula, dengan begitu asumsi dan kesimpulan awal kita langsung menjadi tidak benar. Ini adalah risiko yang harus diterima secara bertanggung jawab (atau dihindari dan kemudian dibayar untuk rak yang jelas-jelas kurang dimanfaatkan).
Catatan penting: usahakan untuk mendistribusikan server dari berbagai layanan secara horizontal di seluruh rak, jika memungkinkan. Hal ini diperlukan untuk menghindari situasi di mana sekumpulan server untuk satu layanan tiba dan rak ditumpuk secara vertikal untuk meningkatkan kepadatan (karena lebih mudah). Namun, pada kenyataannya, satu rak diisi dengan server identik dengan beban rendah dari satu layanan, sementara rak lainnya diisi dengan server identik dengan beban tinggi. Kemungkinan kegagalan rak kedua jauh lebih tinggi, karena profil bebannya identik, dan semua server di rak tersebut mulai mengonsumsi daya dalam jumlah yang sama seiring dengan peningkatan beban.
Mari kita kembali ke distribusi server dalam rak. Kita telah mempertimbangkan keterbatasan ruang fisik dan daya rak, sekarang mari kita lihat jaringannya. Switch dengan port N 24/32/48 dapat digunakan (misalnya, kita menggunakan switch ToR 48-port). Untungnya, pilihannya tidak terlalu banyak, kecuali jika Anda mempertimbangkan kabel breakout. Kita sedang mempertimbangkan skenario di mana kita memiliki satu switch per rak, satu switch per dua rak, atau tiga rak dalam grup Rnet. Saya pikir lebih dari tiga rak dalam satu grup terlalu berlebihan, karena masalah kabel antar rak menjadi jauh lebih menantang.
Jadi, untuk setiap skenario jaringan (1, 2 atau 3 rak dalam satu grup), kami mendistribusikan server di antara rak:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(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 menghitung opsi yang tersisa dengan cara yang sama:
Srack1 = 20
Srack3 = 16
Dan kita hampir sampai. Mari kita hitung jumlah rak yang dibutuhkan untuk mendistribusikan semua server S kita (misalkan 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 dibutuhkan, kabel, dll. Pilih opsi dengan TCO terendah. Untung!
Perhatikan bahwa meskipun jumlah rak yang dibutuhkan untuk opsi 1 dan 2 sama, harganya akan berbeda, karena jumlah sakelar untuk opsi kedua setengahnya, dan panjang kabel yang dibutuhkan lebih besar.
P.S. Jika Anda bisa bereksperimen dengan daya dan tinggi rak, variabilitasnya akan meningkat. Namun, prosesnya dapat disederhanakan menjadi seperti di atas, cukup dengan mengulangi opsi-opsi yang tersedia. Ya, akan ada lebih banyak kombinasi, tetapi jumlahnya masih sangat terbatas—daya rak dapat ditingkatkan dengan kelipatan 1 kW untuk perhitungan, dan rak standar tersedia dalam beberapa ukuran terbatas: 42U, 45U, 47U, 48U, 52U. Analisis What-If Excel dalam mode Tabel Data dapat membantu. Lihat tabel yang dihasilkan dan pilih nilai minimum.
Sumber: www.habr.com
