Kisah Railway Membangun Data Centernya Sendiri
(blog.railway.com)- Railway menilai komputasi berbasis GCP membatasi harga, dukungan, dan pengembangan fitur, lalu memulai Railway Metal, infrastruktur fisik yang bisa dikendalikan lebih langsung
- Setelah dimulai pada Januari 2024, butuh 5 bulan hingga server pertama terhubung, lalu tambahan 3 bulan hingga workload pengguna dimasukkan; 9 bulan kemudian site pertama di California mulai beroperasi
- Batasan yang lebih besar daripada menyewa ruang adalah listrik dan pendinginan, dan Railway memilih Cage Colocation alih-alih Greenfield atau sewa per rak
- Jaringannya bersiap menghadapi kegagalan satu data center dengan minimal 2 ISP per wilayah, tabel routing internet penuh, pemilihan rute per IP prefix, dan desain beberapa zone
- Mereka harus menangani sendiri penempatan rak, dokumentasi kabel, PDU, switch reverse airflow, Redfish API, PXE, FRR, hingga SONiC; membangun cloud sendiri lebih mirip membangun rumah daripada deploy Terraform
Alasan Berpindah dari GCP ke Railway Metal
- Sejak awal, komputasi Railway dibangun di atas Google Cloud Platform
- GCP membantu pertumbuhan awal, tetapi seiring operasi membesar, muncul keterbatasan dalam menyediakan platform yang diinginkan bagi pelanggan
- Operasi berbasis hyperscaler secara langsung membatasi harga, tingkat layanan, dan cakupan pengembangan fitur yang bisa ditawarkan Railway
- egress fee memengaruhi harga
- ketika terjadi masalah di infrastruktur lapisan atas, penyebabnya jarang bisa dipahami
- Railway menilai bahwa meski menghabiskan jutaan dolar per tahun, tingkat dukungannya tidak jauh berbeda dari menghabiskan 100 dolar
- Sebagai respons, Railway memulai proyek Railway Metal pada 2024
- 9 bulan kemudian, site pertama di California mulai beroperasi
- Mereka merancang, menentukan spesifikasi, dan memasang sendiri semuanya, mulai dari kabel fiber optik di dalam cage hingga kontrak ISP
- Mereka juga sedang menyalakan 3 region data center tambahan
Pilihan Ruang Pertama: Cage Data Center
- Proyek Railway Metal dimulai pada Januari 2024, dan butuh 5 bulan hingga server pertama terhubung
- Diperlukan 3 bulan tambahan sampai mereka menilai workload pengguna boleh dijalankan di hardware tersebut
- Infrastruktur sendiri membutuhkan ruang untuk menaruh server, listrik yang stabil, dan pendinginan yang memadai
- Secara garis besar ada tiga pilihan
- Greenfield buildout: membeli atau menyewa data center
- Cage Colocation: mendapatkan ruang khusus yang dikelilingi dinding mesh di dalam data center milik operator
- Rack colocation: menyewa rak individual atau sebagian rak di data center colocation
- Railway memilih Cage Colocation untuk mendapatkan ruang kosong dengan empat dinding, pintu keamanan, dan kebebasan merancang sisanya sendiri
- Biaya ruang itu sendiri tidak besar, tetapi biaya listrik dan pendinginan yang menyertainya adalah yang paling besar
- Biaya per kW sangat berbeda tergantung wilayah
- Di Amerika Serikat bagian barat, biayanya bisa kurang dari setengah biaya di Singapura
- Listrik dibayar sebagai komitmen bulanan untuk menjamin ketersediaan on-demand, terlepas dari pemakaian aktual
Desain Listrik dan PDU
- Railway lebih dulu menentukan target jumlah vCPU, GB RAM, dan TB NVMe agar sesuai dengan kapasitas yang digunakan di GCP
- Berdasarkan angka ini, mereka memilih server dan CPU
- Variabel kuncinya adalah kepadatan daya, yaitu memasukkan kepadatan komputasi yang diinginkan dalam konsumsi daya tertentu
- Perhitungan listrik tidak selesai hanya dengan menjumlahkan watt, dan menjadi lebih rumit terutama pada listrik 3 fase
- Pengantar listrik 3 fase dan PDU dari Cloudflare membahas topik terkait
- Di data center, listrik adalah sumber daya terpenting, dan pemulihan dari pemadaman bisa memakan waktu sangat lama
- Setiap rak membutuhkan 2 feed listrik yang sepenuhnya independen
- Dalam kondisi normal, kedua feed membagi beban
- Sistem harus mampu bertahan meski salah satu feed mati
- Untuk menyalurkan listrik ke server, diperlukan Power Distribution Unit
- PDU dasar pada dasarnya mirip stop kontak ekstensi
- PDU yang dipasang Railway memungkinkan kontrol dan pengukuran per soket
- Setiap PDU dapat diakses melalui jaringan, dan tiap soket dapat diukur serta dikontrol dari jarak jauh
Jaringan: ISP, Routing, Rute per Wilayah
- Mesin cloud tidak berdiri sendiri, sehingga jaringan berperan penting
- Railway mencari fasilitas data center yang terhubung kuat ke dunia luar demi latensi rendah
- Kriteria yang disukai adalah sebagai berikut
- Berstatus on-network dengan ISP Tier 1
- Termasuk dalam Internet Exchange
- Memiliki fiber optik yang dapat terhubung ke data center lain di sekitar
- Aplikasi yang di-deploy di Railway berkomunikasi dengan berbagai endpoint
- Pengguna internet rumahan di Sydney
- API yang di-host di server AWS Amerika Serikat
- Demi latensi rendah dan biaya bandwidth rendah, Railway mengontrak beberapa penyedia internet yang dioptimalkan untuk tiap use case
- ISP dipilih berdasarkan kematangan jaringan di wilayah target
- Bekerja sama dengan ISP yang salah bisa menambah hop jaringan menuju pasar target tertentu dan meningkatkan latensi
- Dalam skenario terburuk, jalur jaringan yang rumit dan berbelit bisa muncul
- Di setiap wilayah, mereka memilih minimal 2 jaringan terpisah berdasarkan footprint lokal
- Setelah terhubung, mereka menerima tabel routing internet penuh dari tiap ISP, lalu menggabungkannya di network switch untuk menentukan rute terbaik per IP prefix
- Jika pengguna Australia mengakses aplikasi yang di-deploy di Singapura, paket kemungkinan besar akan diteruskan ke Telstra
- Jika aplikasi yang sama mengirim paket ke pengguna atau server di Jepang, paket kemungkinan besar akan diteruskan ke PCCW
- Informasi peering tersedia untuk publik, dan interkoneksi jaringan dapat dilihat di bgp.tools
- Untuk redundansi, mereka membangun beberapa zone di dalam tiap region, dan interkoneksi antar-site juga penting untuk ekspansi
- Mereka meninjau alat seperti dark fiber atau wavelength service
- Tujuannya agar aplikasi tidak merasakan perbedaan apakah database berada di ruangan yang sama atau di gedung tetangga yang berjarak 4 blok
- Ini adalah desain untuk meningkatkan ketahanan terhadap kegagalan data center individual
Rak, Lorong, Pendinginan, dan Jalur Kabel
- Di data center, rak disusun berjajar dan lorong di antara rak digunakan untuk aliran udara
- Di Cold Aisle, udara dingin dari fasilitas masuk, lalu server mengisap udara ini dan membuangnya ke Hot Aisle di belakang
- Untuk meningkatkan efisiensi, udara antara Cold Aisle dan Hot Aisle tidak boleh bercampur
- Meski menggunakan perangkat selebar 19 inci, tinggi, lebar, dan kedalaman rak dapat dipilih sesuai kebutuhan perangkat dan kabel
- Sebagian besar perangkat server dapat ditarik ke depan di atas rel untuk pemeliharaan, sehingga dimensi cage harus memungkinkan hal ini
- Kabel dan manajemen kabel juga membutuhkan ruang, sehingga ada trade-off antara seberapa padat rak diisi dan berapa rak yang dapat dimasukkan ke dalam cage
- Dalam pengalaman Railway, listrik dan pendinginan lebih sering menjadi batasan daripada ruang fisik
- Di site baru, mereka memilih rak yang lebih lebar, 800 mm, untuk menyingkirkan kabel dari jalur pembuangan dan memperbaiki airflow
- Selain rak, dibutuhkan infrastruktur atas dan tray untuk menyalurkan listrik dan data
- Fiber optik dirutekan dari tepi cage ke tiap rak
- Kabel antar-rak juga dirutekan
- Item seperti ini terkadang dimasukkan operator data center dalam penawaran cage
- Karena Railway memiliki kepadatan kabel fiber optik switch-to-server yang tinggi di setiap rak, mereka membeli reverse airflow switch dengan port menghadap bagian belakang rak
- Ini adalah switch yang membuang udara ke sisi tempat port jaringan berada
- Tray kabel disesuaikan agar semua cabling dilakukan dari satu sisi rak
- Mereka menghindari situasi kabel bolak-balik zig-zag antara depan dan belakang rak
Dokumen Instalasi dan Rack-and-Stack
- Railway awalnya mencoba melakukan cabling sendiri, tetapi hasilnya tidak konsisten, lalu mereka melibatkan ahli agar instalasi dilakukan dengan benar
- Paket dokumentasi yang komprehensif diperlukan agar ahli instalasi tahu apa yang harus dipasang dan di mana
- Dokumen umum ada dua jenis
- Cabling matrix: mendefinisikan lokasi perangkat di kedua ujung tiap kabel, port, spesifikasi kabel, jenis fiber optik, panjang, dan sebagainya
- Rack elevation: menampilkan secara visual posisi dan orientasi tiap perangkat di dalam rak
- Setiap tahap instalasi Railway mencakup lebih dari 60 perangkat, lebih dari 300 kabel individual, dan puluhan detail
- Spesifikasi tertulis dan spreadsheet yang menjadi dasar instalasi serta commissioning dibuat secara manual
- Setelah material tiba di lokasi, semua instalasi memakan waktu sekitar 6–14 hari
- Setelah itu, Railway membuat alat internal untuk mengotomatiskan pembuatan build specification
- Membangun cage data center sangat jauh dari software biasa, DevOps, atau deployment Terraform stack; ini lebih mirip membangun rumah
- Tiap fasilitas data center, kontraktor, dan vendor memiliki cara yang sedikit berbeda, bahkan dalam organisasi yang sama, sehingga operasi membutuhkan perhatian yang sangat rinci
Pengecualian dan Masalah Fisik yang Ditemui di Lapangan
- Di satu site, PDU terpasang terbalik, dan karena listrik masuk dari lantai, nomor soket yang direncanakan menjadi terbalik
- Di lokasi Amsterdam, terdapat pola fasilitas di mana link fiber optik eksternal masuk langsung ke sebuah box di dalam rak, bukan ke demarcation point khusus
- Sebuah fasilitas memasang soket listrik dengan wiring phase-to-neutral, berbeda dari site lain, sementara fasilitas lain menggunakan phase-to-phase
- Ada kasus kontraktor tidak tahu bahwa perangkat jaringan adalah reverse airflow dan mencoba memasangnya ke arah berlawanan, lalu menyimpulkan kabel data terlalu pendek
- Penyebab link yang tidak naik pada kabel tertentu adalah kesalahan polarity fiber optik, dan saat itu Railway mempelajari “rolling fibre cables”
- Caranya adalah mencabut plug LC connector lalu menukarnya satu sama lain
- Sekitar 24 PDU dari satu vendor memiliki cacat soket sehingga colokan listrik tidak terpasang dengan benar, dan masalah itu tidak terselesaikan meski diberi tenaga fisik yang kuat
Pekerjaan Software Setelah Instalasi Fisik
- Setelah hardware berada di tempatnya, pekerjaan berpindah ke ranah software yang lebih familier
- Pekerjaan yang dibutuhkan adalah sebagai berikut
- Konfigurasi BGP
- Instalasi OS
- Konfigurasi monitoring
- Konfigurasi perangkat jaringan
- Penulisan konfigurasi router
- Pembaruan catatan RIR, yaitu Regional Internet Registry
- Mereka menggunakan Redfish APIs untuk mengakses controller khusus pada server dan PDU
- Mereka menggunakan PXE untuk mem-boot server melalui jaringan
- Desain jaringan Railway menggunakan whitebox network switch yang menjalankan FRR dan SONiC
- Dengan desain ini, Railway membangun jaringan berbasis software L3-only yang terintegrasi mendalam dengan control plane Railway
- Dalam beberapa bulan terakhir, Railway membuat alat software baru, Railyard dan MetalCP
- Mendesain cage baru
- Melacak dan memvisualisasikan kabel
- Menginstal OS server
- Alat untuk memungkinkan pengalaman klik tombol hingga proses menghubungkan server ke internet
- Tulisan berikutnya akan membahas proses mengubah kumpulan server di dalam sebuah ruangan menjadi Railway zone yang berfungsi
1 komentar
Komentar Hacker News
Dari pengalaman saya dan tulisan-tulisan seperti ini, rasanya Google tidak suka punya pelanggan
Sepertinya seseorang memutuskan “kita harus punya public cloud” lalu mereka membuatnya, tetapi kesannya mereka ingin mendorong pelanggan menjauh dengan galah sepanjang 3 meter
Saya 100% yakin account manager AWS adalah orang yang, kalau perlu, akan ikut berguling di lumpur bersama Anda. Kalau diminta dalam situasi krisis, dia akan tidur di lantai bersama Anda
Sebaliknya, melihat orang-orang Google Cloud membuat saya sedih. Karena terlihat bahwa bahkan di dalam Google pun mereka kurang dicintai dan kurang didukung dibanding kita. Sedih melihat orang yang berusaha meyakinkan perusahaannya sendiri agar menjual dan melayani dengan benar, dan rasanya mereka memang disiapkan untuk gagal
Orang-orang Microsoft itu seperti antipeluru: tangguh, jago menjual, jago memberikan layanan, menguras habis uang dari kantong saya, sambil membuat saya benar-benar percaya bahwa itu baik untuk saya. Hanya saja cloud mereka adalah sesuatu yang sangat aneh… entah apa
Soal Railway pindah ke bare metal, dari pengalaman sekitar 15 tahun, saya sama sekali, sama sekali, sama sekali tidak ingin kembali. Tidak sepadan. Tapi sepertinya mereka harus mengalaminya sendiri untuk tahu, dan memang begitulah jalannya
Mereka akan segera tahu kenapa Google sampai begitu kerepotan. Namun, jika keinginan untuk menjual layanan kepada orang benar-benar kuat, alih-alih membuat Borg atau otak buatan, mereka bisa melakukannya 100 kali lebih baik daripada Google
Tetap saja saya tidak merasa dia akan ikut berguling di lumpur, jadi itu agak mengejutkan. Saya penasaran harus menghabiskan berapa banyak uang agar masuk ke tahap ditemani berguling di lumpur
Seluruh layanan cloud-nya terasa seperti dirancang oleh orang yang sama sekali tidak memahami cloud computing dan hanya tahu “sewa server bare metal”. Memang cloud computing, tetapi dengan cara yang meruntuhkan konsep cloud computing itu sendiri
Tool command-line GCP,
gcloud, juga terasa dirancang dengan lebih baikDengan begitu kami bisa menghemat beberapa bulan pekerjaan awal
Dari pengalaman pribadi, dukungan Google Cloud memperlakukan kami cukup baik bahkan saat kami hanya tim kecil beranggotakan 3 orang dengan pengeluaran sangat kecil, dan di perusahaan lain Microsoft juga memperlakukan kami dengan sangat baik. Namun saat itu skala pengeluarannya mungkin sampai bisa dilacak dari pemantauan jaringan listrik data center
Sebaliknya, AWS berbohong tentang fitur, dan pada akhirnya bahkan tidak pernah memberi jawaban
Account manager yang membicarakan kontrak AWS wajib bernilai jutaan dolar dengan manajemen senior tampaknya tahu betul bagaimana berbicara kepada para eksekutif itu
Namun ketika sampai pada tahap benar-benar mengembangkan dan menyediakan produk untuk orang lain, hanya kami yang ditinggalkan di tengah debu
Yang lebih lucu lagi, fitur yang mereka bohongi itu adalah fitur yang dijual sebagai kunci untuk membuat pengalaman pengguna akhir menjadi sangat luar biasa
Saya membalas tiket dukungan itu tetapi tidak ada respons, lalu mengirim email ke dua perwakilan AWS, tetapi tetap tidak ada jawaban
Teringat masa-masa Rackspace dulu. Benar-benar banyak kejadian seperti perang.
Orang-orang EMC datang untuk memasang perangkat storage untuk pengujian, lalu kaki mereka saling tersandung dan, seperti adegan komedi, menjatuhkan satu rak server utuh. Tentu saja kontraknya tidak berhasil didapat.
Seorang sopir truk mengalami serangan jantung, dan akibat kecelakaan itu data center DFW jadi offline. Sebenarnya ada bollard untuk mencegah situasi seperti ini, tetapi saat itu belum diisi semen.
Pernah juga kami membuat koneksi sementara dengan menembakkan bandwidth menggunakan laser ke gedung lain di seberang jalan.
Suatu hari, sebuah server secara harfiah mulai terbakar, jadi kami memecahkan jendela dan membeli box fan.
Rekayasa data center sudah cukup maju dibanding masa-masa awal. Saat itu kami mengerjakan OpenCompute Project bersama Facebook, dan untuk standar waktu itu ada konsep-konsep infrastruktur yang sangat maju.
Link microwave utama terus putus dengan error paket yang sesekali muncul jauh di lapisan data link. Setelah diselidiki, ternyata pohon di seberang jalan mulai berdaun, dan cabang-cabangnya bergoyang masuk ke garis pandang perangkat di gedung kami. Dengan tangga, gergaji, dan 10 menit, koneksi berhasil dipulihkan.
Router BGP utama yang keluar dari data center terus reboot. Tidak ada perangkat redundan. Setelah dicek, suhu data center terlalu tinggi dan pendinginannya sangat buruk sehingga suhu udara di sisi kipas intake melampaui 60°C. Untuk sementara kami memasang kipas yang diarahkan ke sana.
Beberapa minggu kemudian AC di ruangan lain juga rusak dan mulai menyemburkan air ke atas Nortel DMS-100. Itu adalah ISP dial-up yang punya switch sendiri. Saya tidak ingin membantu mengelapnya karena berpikir air itu mungkin saja dialiri listrik, tetapi tidak ada pilihan lain.
Setelah itu saya juga bekerja di sebuah pulau kecil terpencil; link internet utamanya adalah link 1MB/s melalui satelit GS, dengan ping di atas 500ms. Warga lokal dial-up lewat jaringan telepon microwave yang dinilai 9600 baud, tetapi entah bagaimana modem 56k bisa berfungsi.
Suatu hari saya tahu bahwa sebuah box Solaris kehilangan
.sopenting, sementara tidak ada backup lokal maupun media instalasi. Saya menelepon teman di Inggris dan memintanya mengunggah salinannya ke server FTP, lalu box itu bisa kembali online.Beberapa tahun kemudian, saya juga memasang link laser di atas Oxford Road di Manchester, yang saat itu merupakan rute bus tersibuk di Eropa, untuk menghubungkan kantor dengan kampus universitas. Masa-masa yang menyenangkan.
Semuanya sangat seru, tetapi sekarang saya benar-benar bersyukur hampir hanya mengerjakan software.
Meski server tidak benar-benar terbakar, kejadian membuka jendela dan memakai kipas juga terjadi pada Januari 2024 di data center Equinix CH1 di Chicago. Azure ExpressRoute turun.
Saya dengar suhunya menjadi terlalu dingin sehingga CRAC tampaknya tidak sanggup bertahan. Konon semua pintu dan jendela dibuka agar tetap cukup dingin, tetapi akhirnya gagal. Kalau CRAC tumbang, server juga ikut tumbang.
Switch itu pasti terkutuk. Belakangan minggu itu, pada perangkat yang sama terjadi kesalahan konfigurasi spanning tree, membuat LINX berhenti selama beberapa jam, dan separuh peering ISP Inggris sempat kacau sementara. Orang-orang lain yang terlibat dalam proyek itu juga semuanya meninggal dalam 2 tahun.
Beberapa tahun kemudian saya meninjau fasilitas itu, dan bangkai yang terpanggang masih ada di lantai di bawahnya.
Bagian di tulisan yang mengatakan “meski menghabiskan jutaan dolar per tahun, dukungan yang didapat hanya setara orang yang membelanjakan 100 dolar” itu menyakitkan. Ini masalah yang cukup besar bagi Google.
Tulisan ini terasa sangat menarik karena kami mengalami petualangan serupa saat membangun infrastruktur Blekko.
Untuk perusahaan seperti Blekko, yang trafik antarraknya—yaitu trafik timur-barat—lebih besar daripada trafik ke dan dari internet, sangat penting agar layanan yang ditempatkan bersama secara fisik tidak bersaing bandwidth dengan server lain. Itu jauh lebih ekonomis dibanding membayar biaya kasus khusus seperti ini di SoftLayer, yakni cloud turunan IBM.
Ada juga perusahaan-perusahaan yang cukup keren yang membuat enclosure untuk membungkus cold aisle. Pada dasarnya, semua udara dingin yang keluar dari lantai masuk ke bagian belakang server dan tidak bocor ke tempat lain. Ini juga mencegah udara yang kurang dingin dari sisi samping tersedot masuk ke server.
Perhitungan kapasitas HVAC CRAC di data center juga menarik. Di fasilitas colocation pertama, kami punya hak penolakan pertama untuk memperluas ke area lantai di sebelah cage kami, tetapi ketika tiba waktunya benar-benar ekspansi, kapasitas pendinginan fasilitas sudah tidak tersisa, jadi hak itu sama sekali tidak berarti.
Setelah mengalami proses seperti ini, solusi 0xide akan jauh lebih mudah dipahami.
Beginilah cara membangun perusahaan yang dominan. Bagus sekali mereka mengabaikan kebijaksanaan umum yang cengeng yang membuat orang terkurung di hyperscaler.
Kalau perusahaan infrastruktur, bare metal yang dijualnya harus dimiliki sendiri. Kalau tidak, mereka hanya perantara cloud, dan kapan saja bisa kalah harga dari pesaing bare metal dengan biaya egress 0 dolar.
Karena colocation dan peering bisa membuat biaya egress menjadi 0 dolar, Cloudflare bisa menawarkan paket gratis, dan pendatang baru yang sekadar menjual ulang layanan cloud tidak bisa bersaing dengan Cloudflare.
Sebenarnya, bagi hyperscaler, mark-up bandwidth bukan sekadar sumber pendapatan, melainkan moat. Itu mencegah orang membangun AWS berikutnya di atas AWS, dan menciptakan segmen pasar yang benar-benar baru dan secara strategis lebih lemah bernama “PaaS” di atas IaaS.
Dengan ini kami bisa memangkas biaya itu menjadi setengahnya, menurunkan biaya storage, dan menghapus penetapan harga “per seat”.
Saya benar-benar menantikannya.
Ini tulisan yang cukup bagus. Satu hal yang terpikir: mengapa mereka membuat sendiri tool internal untuk manajemen rack? NetBox sudah ada
NetBox itu bagus, dan saya berharap tool ini sudah ada saat saya mengelola lebih dari 50 rack pada pertengahan 2000-an
https://github.com/netbox-community/netbox
Namun tool yang kami buat, Railyard, cocok karena terintegrasi sangat dalam dengan seluruh stack software, hardware, dan orkestrasi kami
Masalah dengan tool open source adalah sifatnya terlalu generik. Alih-alih memecahkan masalah, kita malah membengkokkan masalah agar sesuai dengan model data tool tersebut
Pada akhirnya, besar kemungkinan tool ini akan kami integrasikan ke Railway sendiri. Jika ingin menjalankan on-premise, cukup klik tombol untuk mendapatkan desain hardware, commissioning, deployment, hingga pengalaman developer. Mirip dengan yang dilakukan Oxide, tetapi didekati dari arah sebaliknya
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBox ingin menjadi “sumber kebenaran (source of truth) untuk infrastruktur jaringan”
Hal yang penting berbeda-beda tergantung situasi, tetapi ceritanya mungkin akan berbeda jika NetBox tidak bersikeras bahwa item tertentu tidak boleh memiliki sistem lain sebagai sumber kebenaran, dan hanya menargetkan diri sebagai repositori pusat
Saya belajar bahwa upaya untuk memusatkan kompleksitas dan kontrol tidak berhasil. Kami hampir langsung mengetahuinya tak lama setelah Clinger-Cohen Act disahkan, dan kini ITIL serta TOGAF juga membahas ini dengan jelas. Saya rasa para konsultan akan banyak membidik titik ini dalam beberapa tahun ke depan
Kita memang perlu cara pusat yang konsisten untuk menemukan status. Tujuannya agar tidak ada keraguan tentang di mana informasi yang otoritatif harus dicari
Namun untuk berekspansi, tumbuh, atau beradaptasi dengan perubahan baru, sistem preskriptif semacam kotak dewa tersentralisasi seperti ini harus dihindari
Bukan software yang terlalu menyenangkan untuk dipakai
Ini contoh umum dari “kami butuh X dan Y melakukan X”, tetapi mengabaikan fakta bahwa Y juga melakukan Z, M, Q, bahkan mencuci piring, padahal semua itu tidak diperlukan
Kadang solusi paling mudah adalah membuat hanya yang dibutuhkan. Apalagi kalau yang dibutuhkan hanyalah CRUD di depan database
Pada praktiknya itu hanya memperluas cakupan. NetBox adalah titik awal yang baik jika Anda memulai dari sana dan bersedia menyesuaikan sistem di sekelilingnya
Namun jika sudah punya sistem, atau harus melakukan hal-hal yang tidak cocok dengan logika NetBox, kemungkinan besar lebih baik memperluas sistem yang sudah ada
Dalam kasus ini, Railway harus memperhatikan jauh lebih banyak informasi tambahan selain rack, alamat IP, dan server fisik
Saya pernah mengerjakan otomatisasi perbaikan perangkat di perusahaan teknologi besar. Menurut saya perbaikan adalah salah satu pekerjaan yang diremehkan, tetapi termasuk yang lebih sulit ditangani
Saat berjalan di AWS, kita hampir tidak memikirkan hardware yang rusak. Karena umumnya akan diperbaiki dengan sendirinya
Jika mengoperasikannya sendiri, kemewahan itu tidak ada. Dibutuhkan suku cadang cadangan, teknisi untuk memperbaiki, prosedur untuk mengeluarkan pekerjaan dari host lalu memasukkannya kembali, test suite, tool monitoring hardware, dan 1001 hal lainnya
Pada skala kecil, sebagian bisa dilewati seadanya, tetapi pada akhirnya akan menyusul. Itu baru soal server
Perangkat jaringan punya kumpulan masalah menarik lainnya, dan jika gagal bisa menjatuhkan seluruh rack. Seberapa yakin Anda bahwa penyedia colocation tidak akan kehilangan daya saat beban puncak? Saya harap mereka melakukan latihan pemulihan bencana untuk situasi seperti ini
Semoga tim ini beruntung. Kelihatannya menarik
Ini mengingatkan saya pada beberapa hari dalam karier saya. Antara 2003–2010, saya harus men-deploy puluhan ribu server dan belajar cukup banyak hal menarik tentang data center
Manajemen kabel dan standardisasi sangat penting. Praktik yang berantakan tidak bisa bertahan
Di tempat kami men-deploy ratusan server setiap minggu, jika server berbeda dari salah satu cluster utama, operator punya menu pilihan. Pada dasarnya ada 2 jenis chassis: server disk berkapasitas besar 2U atau pizza box 1U. Disk bisa dipilih antara SCSI 9/36/146GB
Semuanya dual-processor dengan prosesor yang sama, dan bagian bawah rack diisi sekitar 10 unit box 2U, sisanya lebih dari 20 unit box 1U
Kalau ingatan saya benar, kami mendapat harga listrik dengan ketentuan yang sangat bagus, mungkin karena menggunakan rack fasilitas di dalam cage. Saya rasa jika memakai rack itu, dua circuit 30A 240V pertama diberikan gratis
Kontraknya 10 tahun dan tidak ada metering, jadi kami mengisi setiap rack sepadat mungkin. Di satu sisi kami memasang dua 30A, dan di sisi lain dua 20A
Melihat panas dan konsumsi daya yang kami keluarkan, rasanya data center itu hampir impas saja. Mungkin mereka menutupinya dari biaya koneksi atau peering
Saya tidak terlalu ingat detailnya, jadi perlu mengecek dengan teman yang bekerja di sana pada masa itu
Ada tempat yang memang tepat berada di cloud, dan ada yang tidak. Contoh terbaik adalah aplikasi dengan bandwidth tinggi atau banyak memakai disk
Lihat Netflix: hampir semuanya ada di cloud, tetapi pengiriman video sebenarnya dilakukan dengan hardware mereka sendiri. Bahkan pada skala Netflix, saya ragu apakah secara ekonomi itu memungkinkan jika mereka membayar pihak lain untuk melakukannya
Jika sedikit mengubah angka yang sering saya lihat, egress 20PB dengan tarif 0,02 dolar per GB berarti 400 ribu dolar per bulan
20PB kira-kira setara dengan 67Gbps pada persentil ke-95
Tidak sulit menemukan koneksi flat-rate 100Gbps seharga 5 ribu dolar per bulan
Tentu ini perhitungan yang terlalu disederhanakan, dan dalam praktiknya ada jauh lebih banyak faktor. Meski begitu, selisihnya besar
Bagi sebagian perusahaan, 4,68 juta dolar per tahun mungkin bukan masalah besar, tetapi bagi perusahaan lain itu bisa menjadi jumlah yang menentukan hidup-mati
Akan jauh lebih baik kalau ada detail yang jauh lebih banyak. Bagian WTF paling menarik
Peralatannya tampaknya perlu label seperti “arahkan sisi ini ke musuh”, atau affordance yang tepat agar hanya bisa masuk dari satu arah
Apakah tata letaknya distandardisasi di tingkat rak? Prosedur poka-yoke apa yang diterapkan untuk mencegah kesalahan?
Seperti apa stack dari bare metal sampai booting?
Dari sudut pandang seseorang yang pernah bekerja di dua penyedia cloud berbeda dan membangun cloud internal sendiri dengan host PXE boot, hal-hal seperti ini benar-benar menarik
Saat memulai data center baru, sebaiknya manfaatkan semaksimal mungkin untuk menguji semua skenario kegagalan yang terpikirkan, serta skenario yang tidak terpikirkan melalui injeksi kegagalan acak
Standardisasi tata letak tingkat rak sekarang sudah kami lakukan. Kami baru menyadarinya setelah site kedua. Berkat itu, validasi jadi jauh lebih mudah
Validasi itu sulit dan sejauh ini masih kami lakukan secara manual. Saya ingin mencoba mengambil data LLDP, tetapi ada bug di stack perangkat lunak switch
Ini proses yang terus berevolusi. Semakin banyak kami bekerja dengan kontraktor yang berbeda, semakin banyak kasus pengecualian yang kami temukan dan masukkan
Peningkatan terbesar adalah membuat DCIM internal untuk menjadikan desain rak berbasis template, lalu mengekspor “penjelajah cabling” interaktif untuk teknisi lapangan. Di dalamnya juga ada diagram beranotasi detail untuk perangkat, termasuk nama port dan sebagainya. Tangkapan layar elevasi rak di tulisan itu adalah bagian dari tool tersebut
Untuk bare metal sampai booting, kami punya sesuatu yang di-hack di atas https://github.com/danderson/netboot/tree/main/pixiecore. Ini menyediakan Debian netboot dan file preseed
Kami juga punya worker Temporal kustom yang terhubung ke Redfish API milik BMC untuk mengendalikan perangkat ini. Setelah itu, host agent kustom mem-provision QEMU VM, dan di host menggunakan FRR untuk mengiklankan IP yang dialokasikan lewat BGP
Terkait skenario kegagalan data center baru, kami sudah mengujinya dengan menjatuhkan circuit breaker, dan dari sana kami menemukan bahwa penyeimbangan fase tidak beres. Di site lain, kami masuk membawa kamera termal
Site AMS akan naik minggu depan, dan targetnya adalah melihat sejauh mana kami bisa mendorong switch fabric yang terisi penuh
Tulisan yang bagus. Saat butuh kecepatan 100G, Google benar-benar mengenakan harga yang sangat tinggi. Hampir terasa menghina
Misalnya, Dedicated Interconnect 100G yang redundan biayanya sekitar 35 ribu dolar per bulan, belum termasuk VLAN attachment, biaya cross-connect colocation, transit, dan sebagainya. Selain itu, VLAN attachment maksimal hanya 50G
Kalau biaya ini dibandingkan, dengan uang yang sama Anda bisa membeli 2 switch Arista 100G baru dengan 32 port
Di Amerika Utara, koneksi WAN 100G, yaitu managed Wavelength, bisa didapat dengan harga di bawah 5 ribu dolar per bulan. Untuk metro lokal, dark fiber bisa didapat lebih murah dan dijalankan pada kecepatan yang Anda inginkan