Ini adalah postingan ke dua puluh dua dalam seri Fastmail Advent 2024. Posting sebelumnya adalah 21 Desember: Fastmail In A Box. Periksa kembali besok untuk posting lainnya.
Mengapa kami menggunakan perangkat keras kami sendiri
Belakangan ini sedang ramai dibicarakan repatriasi awan ketika perusahaan beralih dari cloud ke on-premise, dan beberapa diantaranya contoh yang berisik.
Fastmail memiliki sejarah panjang dalam menggunakan perangkat keras kami sendiri. Kami memiliki pengalaman lebih dari dua dekade dalam menjalankan dan mengoptimalkan sistem kami agar dapat digunakan sendiri logam telanjang server secara efisien.
Kami mendapatkan pengoptimalan biaya yang jauh lebih baik dibandingkan memindahkan semuanya ke cloud karena:
- Kami memahami pola penggunaan, persyaratan, dan pertumbuhan jangka pendek, menengah dan panjang kami dengan sangat baik. Artinya, kami dapat merencanakan pembelian perangkat keras sebelumnya dan tidak memerlukan penskalaan dinamis cepat yang disediakan cloud.
- Kami memiliki pengalaman operasi internal dalam menginstal, mengonfigurasi, dan menjalankan perangkat keras dan jaringan kami sendiri. Ini adalah keterampilan yang harus kami pertahankan dan kembangkan di rumah sejak kami melakukan ini selama 25 tahun.
- Kami dapat menggunakan perangkat keras kami untuk jangka waktu lama. Kami mendapati bahwa perangkat keras kami dapat memberikan masa manfaat antara 5-10 tahun, bergantung pada jenis perangkat keras tersebut dan kapan perangkat tersebut dibeli dalam siklus teknologi global, yang berarti kami dapat mengamortisasi dan mendepresiasi biaya perangkat keras apa pun selama bertahun-tahun.
Ya, itu berarti kami harus melakukan lebih banyak hal sendiri, termasuk merencanakan, memilih, membeli, memasang, dll, namun pengorbanannya bagi kami sudah ada dan kami yakin akan tetap sangat bermanfaat.
Perangkat keras selama bertahun-tahun
Tentu saja selama 25 tahun kami menjalankan Fastmail, kami telah mengalami sejumlah perubahan perangkat keras. Selama bertahun-tahun, platform penyimpanan server IMAP kami merupakan kombinasi dari karat yang berputar drive dan Pengontrol RAID ARECA. Kami cenderung menggunakan drive SAS 15k RPM yang lebih cepat serangan1 untuk meta data panas kami, dan drive SATA 7,2k RPM masuk RAID6 untuk data gumpalan email utama kami.
Sebenarnya ini sedikit lebih rumit dari ini. Gumpalan email ditulis ke volume RAID1 SAS yang cepat pada saat pengiriman, namun kemudian proses pengarsipan terpisah akan memindahkannya ke volume SATA pada waktu aktivitas server rendah. Dukungan untuk semua ini telah ditambahkan Cyrus dan peralatan kami selama bertahun-tahun dalam bentuk “meta”, “data” dan “arsip” partisi.
Pindah ke SSD NVMe
Namun beberapa tahun yang lalu kami melakukan peningkatan perangkat keras terbesar yang pernah ada. Kami memindahkan semua server email kami ke yang baru Platform AMD 2U dengan murni SSD NVMe. Peningkatan kepadatan (drive NVMe 24 x 2,5″ vs drive SATA 12 x 3,5″ per 2U) dan peningkatan kinerja sangat besar. Kami menemukan bahwa kinerja server baru ini bahkan lebih baik daripada ekspektasi awal kami.
Pada saat kami meningkatkan versi, namun pengontrol RAID NVMe belum tersedia secara luas. Jadi kami harus memutuskan bagaimana menangani redundansi. Kami mempertimbangkan penyiapan tanpa RAID menggunakan drive SSD mentah di setiap mesin dengan replikasi tingkat aplikasi sinkron ke mesin lain, namun perubahan perangkat lunak yang diperlukan akan lebih kompleks dari yang diharapkan.
Kami sedang mempertimbangkan untuk menggunakan Linux klasik Nyonya RAIDtapi itu menulis lubang adalah kekhawatiran dan menulis cache tampaknya belum teruji dengan baik pada saat itu.
Kami memutuskan untuk melihatnya ZFS dan setidaknya mengujinya.
Meskipun beberapa cyrus pada struktur database disk cukup bermusuhan ZFS Salin-saat-tulis semantik, mereka masih sangat cepat pada semua IO yang kami berikan kepada mereka. Dan masih ada beberapa kemenangan lainnya juga.
Kompresi dan penyetelan ZFS
Saat kami meluncurkan ZFS untuk server email kami, kami juga mengaktifkannya kompresi standar Z transparan. Ini berhasil dengan baik bagi kami, menghemat sekitar 40% ruang di semua data email kami.
Kami juga baru-baru ini melakukan beberapa perhitungan tambahan untuk melihat apakah kami dapat menyesuaikan beberapa parameter dengan lebih baik. Kami mengambil sampel 1 juta email secara acak dan menghitung berapa banyak blok yang diperlukan untuk menyimpan email tersebut tanpa terkompresi, lalu dengan Ukuran catatan ZFS opsi kompresi 32k, 128k atau 512k dan zstd-3 atau zstd-9. Meskipun ZFS RAIDz2 tampaknya secara konseptual mirip dengan RAID6 klasik sebenarnya menyimpan blok data sangat berbeda sehingga Anda harus memperhitungkan ukuran volblock, bagaimana file dipecah menjadi blok ukuran rekaman logis, dan jumlah drive saat melakukan penghitungan.
Emails: 1,026,000
Raw blocks: 34,140,142
32k & zstd-3, blocks: 23,004,447 = 32.6% saving
32k & zstd-9, blocks: 22,721,178 = 33.4% saving
128k & zstd-3, blocks: 20,512,759 = 39.9% saving
128k & zstd-9, blocks: 20,261,445 = 40.7% saving
512k & zstd-3, blocks: 19,917,418 = 41.7% saving
512k & zstd-9, blocks: 19,666,970 = 42.4% saving
Ini menunjukkan bahwa ukuran rekaman default 128k dan zstd-3 sudah cukup bagus. Pindah ke ukuran rekor 512k meningkatkan kompresi di atas 128k sebanyak 4%. Mengingat semua meta data di-cache secara terpisah, hal ini tampaknya merupakan peningkatan yang bermanfaat tanpa adanya kerugian yang signifikan. Pindah ke zstd-9 meningkatkan kompresi dibandingkan zstd-3 sekitar 2%. Mengingat biaya kompresi CPU pada zstd-9 adalah sekitar 4x zstd-3, meskipun email tidak dapat diubah dan cenderung disimpan dalam waktu lama, kami memutuskan untuk tidak menerapkan perubahan ini.
Enkripsi ZFS
Kami selalu mengaktifkan enkripsi saat istirahat di semua drive kami. Ini biasanya dilakukan dengan kemewahan. Tetapi dengan ZFS hal ini terjadi dibangun di. Sekali lagi, hal ini mengurangi kompleksitas sistem secara keseluruhan.
Melakukan semuanya di ZFS
Jadi setelah keberhasilan pengujian awal kami, kami memutuskan untuk menggunakan ZFS secara menyeluruh untuk semua kebutuhan penyimpanan data kami yang besar. Kami sekarang telah menggunakan ZFS untuk semua server email kami selama lebih dari 3 tahun dan sangat senang dengannya. Kami juga telah memindahkan seluruh database, log, dan server cadangan kami untuk menggunakan ZFS pada SSD NVMe juga dengan hasil yang sama baiknya.
Masa pakai SSD
Memori flash di SSD memiliki masa pakai yang terbatas dan beberapa kali yang terbatas dapat ditulisi. Penggunaan SSD semakin kompleks perataan keausan algoritma untuk menyebarkan penulisan dan meningkatkan masa pakai drive. Anda akan sering melihat kutipan ketahanan SSD perusahaan sebagai angka absolut dari “Penulisan Seumur Hidup”/”Total byte yang ditulis” seperti 65 PBW (petabyte tertulis) atau angka relatif per hari dari “Penulisan Drive per hari” seperti 0,3, yang dapat Anda ubah menjadi angka masa pakai dengan mengalikannya dengan ukuran hard disk dan perkiraan masa pakai hard disk yang sering kali diasumsikan 5 tahun.
Meskipun kami dapat menghitung tarif IO untuk yang sudah ada HDD sistem, kami membuat sejumlah besar perubahan dengan beralih ke sistem baru. Beralih ke sistem file COW seperti ZFS, menghapus partisi meta/data/arsip casing khusus, dan pengurangan latensi besar-besaran serta peningkatan kinerja berarti bahwa hal-hal yang sebelumnya mungkin memerlukan waktu ekstra dan akhirnya menggabungkan IO menjadi satu, kini menjadi sangat cepat. menyebabkan tindakan IO terpisah tambahan.
Jadi, satu pertanyaan besar yang tidak diketahui yang kami miliki adalah seberapa cepat SSD akan dipakai di lingkungan produksi sebenarnya? Setelah beberapa tahun, kami sekarang memiliki beberapa data yang jelas. Dari satu server secara acak tetapi ini cukup konsisten di seluruh armada server tertua kami:
# smartctl -a /dev/nvme14
...
Percentage Used: 4%
Pada tingkat ini, kami akan mengganti drive ini karena peningkatan ukuran drive, atau format drive fisik yang benar-benar baru (seperti E3.S yang tampaknya akhirnya mendapatkan daya tarik) jauh sebelum mereka mendekati kapasitas tulis terukurnya.
Kami juga secara anekdot menemukan bahwa SSD jauh lebih andal dibandingkan dengan HDD bagi kami. Meskipun kami hanya pernah menggunakannya pusat data kelas SSD dan HDD kegagalan dan penggantian setiap beberapa minggu merupakan kejadian biasa pada armada server lama. Selama 3+ tahun terakhir, kami hanya melihat beberapa kegagalan SSD secara total di seluruh armada server yang ditingkatkan. Angka ini kurang dari sepersepuluh tingkat kegagalan yang biasa kita alami pada HDD.
Perhitungan biaya penyimpanan
Setelah mengonversi semua penyimpanan email kami ke SSD NVMe, baru-baru ini kami mencari solusi pencadangan data. Pada saat itu, server ini terdiri dari sejumlah server 2U lama dengan ruang drive SATA 12 x 3,5″ dan kami memutuskan untuk melakukan beberapa perhitungan biaya pada:
- Pindah ke penyimpanan cloud.
- Tingkatkan drive HD di server yang ada.
- Tingkatkan ke mesin SSD NVMe.
1. Penyimpanan awan:
Melihat berbagai penyedia, harga per TB per bulan, dan harga tahunan untuk 1000Tb/1Pb (harga per Des 2024)
Beberapa di antaranya (misalnya Amazon) juga berpotensi memiliki biaya bandwidth yang signifikan.
Menarik sekali melihat penyebaran harga di sini. Beberapa juga memiliki banyak casing tepi yang aneh. misalnya “Kelas penyimpanan S3 Glacier Fleksibel Retrieval dan S3 Glacier Deep Archive memerlukan tambahan data sebesar 32 KB per objek”. Mengingat waktu pengambilan yang besar dan overhead tambahan per objek, Anda mungkin ingin menyimpan cadangan tambahan kecil di S3 biasa, lalu ketika Anda sudah mengumpulkan cukup banyak, buatlah objek yang lebih besar untuk dipindahkan ke Glacier. Hal ini menambah kompleksitas implementasi.
- Kelebihan: Tidak ada batasan jumlah yang kami simpan. Dengan asumsi kita menggunakan API yang kompatibel dengan S3, dapat memilih di antara beberapa penyedia.
- Kontra: Biaya implementasi untuk mengonversi sistem cadangan yang ada yang mengasumsikan file POSIX lokal ke API objek gaya S3 tidak pasti dan mungkin signifikan. Opsi berbiaya terendah memerlukan pertimbangan ekstra hati-hati seputar detail penerapan dan batasan khusus. Biaya bulanan berkelanjutan yang hanya akan meningkat seiring bertambahnya jumlah data yang kami simpan. Belum bisa dipastikan apakah harga akan turun atau tidak, atau malah naik. Kemungkinan biaya bandwidth yang signifikan tergantung pada penyedia.
2. Tingkatkan HDD
Seagate Exos 24 HD adalah HDD 3,5″ 24T. Ini akan memungkinkan kami melipatgandakan penyimpanan di server yang ada. Setiap HDD berharga sekitar $500, jadi meningkatkan satu mesin 2U akan memakan biaya sekitar $6.000 dan memiliki penyimpanan sekitar 220T.
- Kelebihan: Menggunakan kembali perangkat keras yang sudah kita miliki. Peningkatan dapat dilakukan mesin dalam satu waktu. Harga yang cukup murah
- Kontra: Akankah unit yang ada dapat menangani drive 24T? Seperti apa waktu pembangunan kembali pada kegagalan drive? Sudah hampir satu hari untuk drive 8T, jadi mungkin hampir seminggu untuk drive 24T yang gagal? Apakah kinerja IO cukup untuk menangani pencadangan harian sesuai kapasitasnya?
3. Tingkatkan ke perangkat keras baru
Seperti yang kita ketahui, SSD lebih padat (2,5″ -> 24 per 2U vs 3,5″ -> 12 per 2U), lebih andal, dan kini berkapasitas lebih tinggi – hingga 61T per drive 2,5″.. Server 2U tunggal dengan drive 24 x 61T dengan 2 x 12 RAIDz2 = 1220T. Setiap drive adalah sekitar $7k saat ini, harga berfluktuasi. Jadi semuanya 24 x $7k = $168k + ~$20k server =~ $190k untuk > 1000T penyimpanan biaya satu kali.
- Kelebihan: Banyak IO sekuensial dan acak yang lebih tinggi daripada yang pernah dimiliki HDD. Harga <1 tahun penyimpanan S3 standar. Internal pada WAN kami, tanpa biaya bandwidth dan latensi sangat rendah. Tidak diperlukan pengembangan baru, sistem cadangan yang ada hanya akan berfungsi. Konsolidasikan pada platform 2U tunggal untuk semua penyimpanan (cyrus, db, cadangan) dan SSD untuk semua penyimpanan. Penghematan ruang dan daya yang signifikan dibandingkan server berbasis HDD yang ada
- Kontra: Biaya dimuka yang lebih besar. Masih perlu memprediksi dan membeli lebih banyak server seiring bertambahnya cadangan.
Satu hal yang tidak Anda lihat dalam perhitungan ini adalah ruang pusat data, daya, pendinginan, dll. Alasannya adalah bahwa dibandingkan dengan biaya tahunan yang diamortisasi dari server penyimpanan seperti ini, biaya tersebut sebenarnya cukup minimal saat ini, sekitar $3000 /2U/tahun. Menghitung waktu seseorang lebih sulit. Kami memiliki banyak sistem otomasi buatan rumah yang berarti memasang dan menjalankan satu server lagi memiliki biaya marjinal yang minimal.
Hasil
Kami akhirnya menggunakan opsi server 2U yang baru:
- Platform AMD NVMe 2U dengan ZFS adalah platform yang sudah kami miliki pengalamannya
- SSD jauh lebih andal dan IO jauh lebih tinggi dibandingkan HDD
- Tidak ada ketidakpastian seputar HDD super besar, pengontrol RAID, waktu pembangunan kembali, pengacakan data, dll.
- Penghematan ruang dan daya yang signifikan dibandingkan server berbasis HDD yang ada
- Tidak diperlukan pengembangan baru, dapat menggunakan sistem dan kode cadangan yang ada
- Masa pakai perangkat keras yang diperkirakan lama, biaya awal yang terkendali, dapat menurunkan biaya perangkat keras
Sejauh ini hal ini telah berjalan dengan baik. Mesin-mesin tersebut telah mengikat jaringan 25Gbps dan ketika mengisinya dari awal kami dapat menjenuhkan tautan jaringan yang mengalirkan sekitar 5Gbytes/detik data dari server IMAP kami, mengompresi dan menuliskan semuanya ke dalam kumpulan data ZFS terkompresi RAIDz2 zstd-3.
Kesimpulan
Menjalankan perangkat keras Anda sendiri mungkin tidak cocok untuk semua orang dan memiliki dampak tersendiri. Namun bila Anda memiliki pengalaman dan pengetahuan tentang bagaimana Anda mengharapkan peningkatan, peningkatan biaya bisa menjadi signifikan.
