cara membuat datacenter paling tidak efisien

Apa yang Anda bangun

Setiap panduan di situs ini mengajarkan Anda untuk melakukan sesuatu dengan benar: perintah yang berurutan, tampilan hasil yang benar, dan kegagalan yang disebutkan. Panduan ini berbeda. Hari ini, secara hipotetis, kita akan merancang datacenter paling tidak efisien yang dapat dihasilkan oleh uang, listrik, dan kesombongan.

Kita membutuhkan metrik, jadi kita akan meminjam metrik industri: PUE, Power Usage Effectiveness — total daya fasilitas dibagi dengan daya yang benar-benar mencapai peralatan komputasi. Datacenter hyperscale berjalan di sekitar 1.1: hampir setiap watt melakukan pekerjaan yang berguna. Ruang server perusahaan yang layak mengelola 1.5. Target kita adalah 4.0 atau lebih tinggi, yang berarti untuk setiap watt komputasi, tiga watt tambahan terbuang percuma. Kita akan sering merujuk pada angka ini, sebagaimana panduan serius merujuk pada cadangan (backup).

Pemilihan lokasi: panas adalah intinya

Pendinginan adalah overhead terbesar dalam datacenter nyata, itulah sebabnya milik kita akan melawan termodinamika di wilayahnya sendiri. Lokasi ideal adalah loteng. Menghadap ke selatan. Idealnya dengan jendela skylight yang diposisikan untuk menyinari server secara langsung, sehingga mesin menerima panas limbahnya sendiri dan panas matahari, sebuah kolaborasi antara tagihan listrik Anda dan sebuah bintang.

Di musim dingin, pendinginan ditangani dengan membuka jendela. Datacenter nyata memang menggunakan udara luar — teknik ini disebut free cooling, dan teknik ini dirancang, difilter, dan dikontrol kelembapannya. Kita akan menggunakannya secara tidak sengaja, melalui jendela yang juga memasukkan hujan, serbuk sari, dan setidaknya satu burung yang bingung setiap kuartal.

Untuk seni yang sesungguhnya, pasanglah pendingin ruangan (AC), lalu letakkan pemanas ruangan dua kaki dari termostatnya, dengan pengaturan dua derajat lebih hangat dari target AC. Kedua mesin tersebut sekarang akan berjalan terus-menerus, selamanya, dalam ketidaksetujuan yang sempurna. Perusahaan listrik akan mengirimkan Anda kartu ucapan saat Natal.

Satu server, besar, dicintai

Redundansi mengencerkan komitmen. Datacenter kita berisi tepat satu server, dan ukurannya sangat besar, karena satu mesin dengan 512 GB RAM terasa seperti infrastruktur, sedangkan empat mesin kecil terasa seperti daftar tugas.

Server tersebut memiliki nama. Bukan hostname — sebuah nama. Biasanya Gandalf, atau Odin. Anda tidak bisa menonaktifkan Odin. Odin telah menyala selama lima tahun:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

Angka tersebut adalah sebuah kebanggaan, itulah sebabnya Anda mengambil tangkapan layar dan mengunggahnya, dan mengapa setiap penyerang yang melihat tangkapan layar tersebut juga menganggapnya mengesankan: 1.847 hari uptime berarti 1.847 hari kerentanan kernel, yang tidak ditambal oleh siapa pun. Melakukan reboot sama sekali tidak mungkin — reboot adalah cara Anda menemukan layanan mana yang dijalankan secara manual pada tahun 2021 dan tidak pernah ditulis ke dalam unit systemd. Tidak ada yang ingat layanan yang mana. Server tersebut kini menjadi penopang utama dalam struktur organisasi.

Penyimpanan: kecepatan, dan cara lain untuk kehilangan data

Disk dikonfigurasi dalam RAID 0, untuk performa. Angka nol merujuk pada jumlah disk yang boleh gagal. Untuk efek maksimal, buatlah stripe array pada penyimpanan dengan asal-usul campuran: dua SSD asli, satu hard disk lama, dan sebuah USB stick dari sebuah konferensi. Array tersebut akan memiliki keandalan yang sama persis dengan stick konferensi tersebut, itulah desainnya.

Cadangan ditangani oleh direktori pada array yang sama bernama backup_final_v2_REAL, yang berisi tarball dari skema penamaan sebelumnya. Cadangan off-site diwakili oleh catatan tempel bertuliskan "set up off-site backups," yang secara teknis tersimpan secara off-site saat Anda membawanya pulang di penutup laptop Anda.

Hasil yang benar terlihat seperti: df melaporkan penggunaan 97%, dan sebuah rencana untuk menanganinya pada sprint berikutnya.

Jaringan: satu untaian untuk segalanya

Server DNS berjalan pada mesin itu sendiri, sehingga saat server mati, ia juga membawa serta catatan DNS yang akan Anda gunakan untuk mencari tahu penyebabnya. Ini disebut konsolidasi.

Firewall telah dinonaktifkan pada tahun 2021 — untuk sementara, guna melakukan debugging sesuatu. Debugging selesai; firewall tidak kembali. Setiap port pada router diteruskan ke server "untuk menghemat waktu nanti," dan panel admin router dapat dijangkau dari sisi WAN dengan kata sandi pabriknya, untuk manajemen jarak jauh yang nyaman. Milik Anda, dan milik orang lain.

Server telah berjalan sangat panas akhir-akhir ini, bahkan menurut standar loteng, dan top menunjukkan proses tersibuk adalah sesuatu yang disebut xmrig. Kami berasumsi ini adalah alat pemantauan yang kami gunakan. Kami tidak menginstalnya — ia muncul dengan sendirinya tak lama setelah port diteruskan, yang kami anggap sebagai tanda bahwa ekosistem ini berkembang pesat. Ia memantau sepanjang waktu.

Daya masuk melalui rangkaian kabel terminal (power strip) konsumen yang panjang gabungannya melebihi jarak berjalan ke panel pemutus arus (breaker panel) — yang mana efisien, dalam arti tertentu, karena Anda akan sering mengunjungi panel pemutus arus tersebut.

Redundansi melalui kompleksitas

Setelah menolak redundansi di tempat yang penting, sekarang kita menambahkannya di tempat yang tidak penting. Beranda perusahaan — satu file HTML statis — dilayani oleh klaster Kubernetes dua belas node. Ini mencapai apa yang disebut insinyur sebagai arsitektur berbasis resume: halaman dimuat dalam waktu empat puluh milidetik yang sama dengan yang akan diberikan nginx, tetapi sekarang ia dapat gagal dengan cara yang memerlukan konsultan.

Untuk isolasi, klaster itu sendiri berjalan di dalam sebuah mesin virtual di dalam mesin virtual di dalam mesin virtual, setiap lapisan menambah keamanan sebagaimana setiap lapisan turducken menambah daging unggas. Formulir kontak terdiri dari sembilan microservices. Dua di antaranya belum pernah dipanggil. Satu di antaranya adalah penopang utama dan tidak ada yang tahu yang mana.

Pemanas sebagai layanan

Server modern mengubah listrik menjadi komputasi dan panas, dan kita berniat memaksimalkan output kedua. media server tanpa GPU adalah taktik klasik: CPU-transcoding satu aliran 4K tunggal akan membebani enam belas core dan menghangatkan kamar tidur kecil, sebuah pemanas ruangan yang juga memutar film. Operator yang ambisius naik kelas ke menjalankan large language model pada CPU — sebuah pemanas ruangan dengan 70 miliar parameter yang memiliki API, menghasilkan token dengan kecepatan yang paling tepat diukur secara musiman.

Monitor mengawasi dirinya sendiri

Observabilitas itu penting, jadi kami menerapkan self-hosted uptime monitor — pada server yang sama yang ia pantau. Saat Odin mati, monitor mati bersamanya, dan inilah bagian yang elegan: tidak ada peringatan (alert) yang muncul. Tidak ada peringatan berarti tidak ada insiden. Tidak ada insiden berarti uptime sempurna, sebagaimana yang diukur. Laporan bulanan tidak pernah terlihat sebagus ini.

Email peringatan, untuk kelengkapan, diteruskan melalui server email yang juga berjalan di Odin. Jalur peringatan dengan demikian sepenuhnya mandiri, seperti seekor ular yang memakan ekornya sendiri secara penuh.

Bagian yang tidak nyaman

Inilah bagian yang selama ini saya tunda. Semua ini bukan fiksi. Server yang dicintai dan tak tergantikan, RAID 0 dengan cadangan pada volume yang sama, firewall yang dinonaktifkan "untuk sementara," klaster Kubernetes yang melayani satu halaman, monitor yang mengawasi dirinya sendiri — saya telah melihat semua ini di lingkungan produksi. Beberapa di antaranya saya lihat tahun ini. Satu atau dua di antaranya, di masa awal saya, saya bangun sendiri.

Seperti apa efisiensi yang sebenarnya adalah hal yang membosankan, itulah sebabnya ia kalah dalam argumen sesaat namun menang dalam satu dekade: PUE yang tidak pernah Anda pikirkan karena orang lain yang merancangnya. Mesin yang ukurannya disesuaikan dengan beban kerja, bukan dengan citra diri pemiliknya. Radius ledakan (blast radius), yang dipertimbangkan sebelum ledakan terjadi. Cadangan yang diuji dengan cara memulihkannya, sesuai jadwal, dengan pengingat kalender dan tanpa kepahlawanan. Redundansi yang membosankan — dua perangkat murah mengalahkan satu perangkat megah, setiap saat, dalam setiap kegagalan yang pernah memanggil saya.

Dan datacenter paling efisien yang dapat Anda jalankan adalah yang tidak Anda jalankan. VPS menyerahkan daya, pendinginan, redundansi, dan kegagalan perangkat keras jam 3 pagi kepada orang-orang yang melakukannya dalam skala besar, secara membosankan, yang merupakan pujian tertinggi yang dapat diperoleh infrastruktur — dan itu menyisakan bagian yang benar-benar menyenangkan bagi Anda, yaitu menjalankan layanan Anda sendiri di atasnya, pada mesin yang sanggup Anda relakan jika hilang, yang merupakan satu-satunya jenis mesin yang seharusnya Anda gunakan untuk bereksperimen.

FAQ

Haruskah saya benar-benar melakukan semua ini?

Tidak. Setiap bagian dari panduan ini adalah anti-pola yang terdokumentasi dengan korban akhir pekan. Jika pengaturan Anda saat ini menyerupai lebih dari dua bagian, lewati ke pertanyaan terakhir di FAQ ini — sesuai urutan yang diberikan, karena urutan tersebut adalah triase.

Berapa PUE yang baik, sebenarnya?

Datacenter hyperscale berjalan di sekitar 1.1, ruang perusahaan yang dikelola dengan baik mengelola 1.4 hingga 1.6, dan lemari tanpa pendingin dengan perselisihan pemanas ruangan dapat benar-benar melebihi 3. Anda tidak dapat bersaing secara berarti dengan 1.1 di rumah, yang merupakan argumen ekonomi yang tenang untuk menyewa komputasi dari mereka yang mampu.

Apakah memanaskan gedung dengan server adalah hal yang nyata?

Ya — jika dilakukan dengan benar. Proyek pemanas distrik di beberapa negara menangkap panas limbah datacenter melalui penukar panas dan menyalurkannya ke rumah-rumah, secara desain, dengan rekayasa dan kontrak. Satir di atas bukan tentang panas server dapat menghangatkan ruangan; melainkan melakukannya secara tidak sengaja dan menyebut ketidaksengajaan itu sebagai strategi.

Server saya sudah terlihat seperti ini. Apa yang harus saya lakukan pertama kali?

Cadangan, malam ini, ke tempat yang bukan server tersebut, dan kemudian uji pemulihan — cadangan yang tidak diuji hanyalah rumor. Kedua, tambal (patch) dan reboot yang selama ini Anda hindari, dalam jendela waktu yang direncanakan, sehingga Anda mempelajari apa yang rusak saat Anda sedang mengawasinya. Ketiga, pisahkan titik kegagalan tunggal (single point of failure): pindahkan DNS dan pemantauan keluar dari mesin tersebut. Segala hal lainnya bisa menunggu minggu yang lebih tenang; tiga hal tersebut tidak bisa.