- Perangkat penyimpanan non-volatil telah berevolusi dari tape ke HDD, SSD, hingga penyimpanan jaringan cloud, tetapi lokasi dan penempatan data tetap menentukan latensi IO
- Penyimpanan tape unggul untuk baca-tulis berurutan, tetapi saat membaca data yang letaknya jauh bisa memakan waktu hingga puluhan detik, sehingga tidak cocok untuk database transaksional dengan trafik tinggi
- HDD jauh menurunkan latensi dibanding tape, tetapi karena platter yang berputar dan pergerakan head, pembacaan acak biasanya berada di kisaran 1–3ms, dan performanya sangat bergantung pada urutan permintaan
- SSD bekerja dengan NAND flash tanpa komponen mekanis sehingga pembacaan acak bisa secepat 16μs, tetapi penempatan data tetap penting karena pemanfaatan paralelisme dan garbage collection
- Pemisahan storage dan compute di cloud memudahkan skalabilitas dan penanganan kegagalan, tetapi menambahkan perjalanan bolak-balik jaringan dan batas IOPS; PlanetScale Metal berupaya mengurangi biaya ini dengan NVMe SSD yang terhubung langsung dan replikasi
Faktor dasar yang menentukan latensi penyimpanan
- Penyimpanan non-volatil mempertahankan data meski daya dimatikan, dan menjadi fondasi untuk menyimpan data seperti foto, email, saldo bank, dan rekam medis
- Penyimpanan volatil seperti register CPU, cache CPU, dan RAM lebih cepat, tetapi membutuhkan daya yang terus-menerus
- Performa penyimpanan bukan hanya soal kapasitas; ia bergantung pada cara data dijangkau, unit baca-tulis, antrean, paralelisme, dan apakah ada perjalanan bolak-balik jaringan
- Bersamaan dengan peluncuran PlanetScale Metal, PlanetScale menyatakan bahwa Metal menjalankan database cloud dengan drive NVMe lokal, bukan penyimpanan yang terhubung lewat jaringan
Penyimpanan tape: kuat untuk akses berurutan, lemah untuk akses acak
- Komputer telah menggunakan tape drive sebagai penyimpanan digital non-volatil sejak 1950-an
- Kartrid tape terdiri dari banyak track dan banyak cell, dan status polarisasi magnetik tiap cell merepresentasikan data biner
- Saat kartrid dimasukkan ke reader dan digulung oleh motor, IO head membaca data yang dilewatinya
- Jika posisi baca-tulis dekat dengan head, prosesnya cepat; jika jauh, latensinya meningkat
- Bahkan pada sistem tape modern, membaca data yang jauh bisa mengharuskan penggulungan ratusan meter tape
- Dalam kasus seperti ini, pembacaan bisa memakan waktu puluhan detik
- Meski jumlah operasi baca-tulis sama, data yang tersebar akan memakan waktu jauh lebih lama dibanding penempatan berurutan
- Contoh dalam tulisan menunjukkan situasi ketika baca-tulis yang tersebar membutuhkan waktu sekitar 7 kali lebih lama untuk jumlah pekerjaan yang sama
- Tape memiliki latensi baca-tulis acak yang buruk, tetapi masih cocok untuk baca-tulis berurutan yang panjang
- Biaya per GB lebih rendah dibanding SSD dan HDD, dan umur penyimpanannya panjang
- CERN mengelola data sebesar lebih dari 400PB di data warehouse penyimpanan tape
- AWS juga menyediakan layanan arsip tape
- Tape tidak cocok untuk database transaksional dengan trafik tinggi
HDD: kompromi antara disk berputar dan command queueing
- HDD menyimpan data pada platter, yaitu disk logam bundar, sebagai pengganti tape
- Platter berputar cepat di dalam enclosure; sebagai contoh, 7200 RPM disebut sebagai kecepatan yang umum
- Track pada HDD berbentuk lingkaran, dan satu disk dapat memiliki lebih dari 100.000 track
- Setiap track berisi ratusan ribu page, dan tiap page menampung data sekitar 4KB
- HDD menyesuaikan posisi baca-tulis melalui pergerakan head dan putaran platter
- Berbeda dari tape, bit di seluruh permukaan selalu dapat diakses
- Tidak perlu menggulung tape sampai data yang diinginkan muncul
- Pembacaan acak umumnya dapat dilakukan dalam 1–3ms
- Urutan permintaan sangat memengaruhi performa
- Baca-tulis dengan tingkat keberurutan tinggi selesai dengan cepat
- Bahkan untuk 6 operasi baca-tulis yang sama, jika urutannya tercampur, waktu tunggu hingga platter berada di posisi yang benar akan bertambah
- Disk magnetik telah lama mendukung command queueing
- SCSI menyediakan fitur terkait sejak 1980-an, dan SATA sejak 2000-an
- OS dapat mengirim beberapa perintah agar dijalankan secara paralel atau tidak sesuai urutan
- Controller disk dapat memanfaatkan antrean pekerjaan untuk menjadwalkan baca-tulis sesuai struktur disk
- HDD memang lebih baik daripada tape, tetapi masih bisa lambat, terutama untuk baca-tulis acak
SSD: variabel performa yang tetap ada meski komponen mekanis hilang
- SSD atau penyimpanan flash ditemukan pada 1980-an, tetapi baru menjadi arus utama sebagai penyimpanan konsumen pada 2000-an
- SSD tidak bergantung pada komponen mekanis untuk membaca data
- SSD menggunakan transistor non-volatil yang disebut NAND flash
- Angka 1 dan 0 dibaca, ditulis, dan dihapus sebagai sinyal listrik tanpa pergerakan komponen fisik
- SSD terdiri dari satu atau lebih target; tiap target berisi beberapa block, dan block berisi beberapa page
- SSD membaca dan menulis dalam satuan page
- Meski hanya sebagian data yang dibutuhkan, unit permintaan drive tetap page
- Dalam contoh konfigurasi, jika page berukuran 4096 bit, block berisi 16K page, target berisi 16K block, dan perangkat memiliki 8 target, totalnya menjadi
4k * 16k * 16k * 8 = 8,796,093,022,208bit, yaitu 8TB - Pembacaan acak SSD bervariasi menurut model, tetapi bisa secepat 16μs
- Meski tidak ada komponen mekanis, penempatan data tetap penting
- Faktor performa SSD mencakup paralelisme dan garbage collection
Paralelisme SSD: distribusi target mengubah throughput
- Umumnya setiap target memiliki line khusus yang terhubung ke unit kontrol
- Setiap line menangani baca-tulis, tetapi hanya dapat mengirim satu page pada satu waktu
- Pengiriman page sangat cepat, tetapi tetap membutuhkan sedikit waktu
- Jika 8 write tersebar ke 4 target, 4 line dapat digunakan secara paralel sehingga penulisan selesai dalam dua potongan waktu
- Jika semua 8 write terkonsentrasi pada target yang sama, hanya satu line yang digunakan dan line lain menganggur
- Urutan baca-tulis dan penempatan data juga memengaruhi performa pada SSD
- Saat merancang perangkat lunak seperti MySQL, perlu diperhatikan data disimpan dalam struktur apa dan bagaimana penempatannya di disk
Garbage collection SSD: biaya menghapus sebelum menulis
- Page SSD dapat dibaca berkali-kali, tetapi page yang sudah pernah ditulis tidak dapat ditimpa dengan data baru sebelum data lama dihapus secara eksplisit
- Page individual tidak dapat dihapus; yang harus dihapus adalah seluruh block
- SSD membutuhkan algoritme internal untuk mengelola page empty, in-use, dan dirty
- Dirty page adalah page yang pernah ditulis, tetapi datanya tidak lagi diperlukan dan siap dihapus
- Ada kalanya data harus dipindahkan agar write baru dapat diterima, dan algoritme yang mengelolanya disebut garbage collector
- Jika tersedia cukup unused page, data baru dapat langsung ditulis
- Jika unused page kurang dan dirty page banyak, garbage collection harus dijalankan terlebih dahulu
- Dalam contoh, untuk menulis 5 page baru, 2 non-dirty page dipindahkan ke lokasi lain
- Setelah itu, semua page pada target tersebut dibuat menjadi dirty agar dapat dihapus
- Langkah tambahan seperti ini dapat sangat memperlambat performa write
- Pada SSD sibuk dengan banyak operasi baca, tulis, dan hapus, garbage collection dapat memperlambat pekerjaan lain
Perubahan yang ditambahkan cloud: pemisahan storage dan compute
- Peralihan dari tape ke HDD dan SSD sangat meningkatkan performa IO yang tahan lama
- Migrasi ke cloud menciptakan perubahan lain pada performa IO
- AWS disebut sebagai layanan yang sangat memperluas migrasi ke cloud sejak diluncurkan pada 2006
- Dalam lingkungan cloud, pengguna menyewa server tervirtualisasi di atas perangkat keras mana pun di pusat data besar
- Server dapat berhenti kapan saja karena berbagai alasan, seperti kegagalan perangkat keras, penggantian, atau putusnya jaringan
- Saat membangun sistem di atas infrastruktur cloud sewaan, sistem harus mampu menoleransi kegagalan yang lebih sering
- Kondisi seperti ini, bersama kebutuhan volume storage yang dapat diskalakan secara dinamis, mengarah pada pemisahan storage dan compute
Kelebihan dan biaya penyimpanan yang terhubung lewat jaringan
- Secara tradisional, server, desktop, laptop, dan ponsel menghubungkan penyimpanan non-volatil secara langsung
- Kabel SATA, antarmuka PCIe, atau bentuk terintegrasi dalam SoC yang sama digunakan
- Penyimpanan yang terhubung langsung memang cepat, tetapi memiliki dua batasan
- Jika server turun, data juga tidak dapat digunakan
- Ukuran storage bersifat tetap
- Server aplikasi biasanya cocok dengan lingkungan sementara (ephemeral), dan banyak pekerjaan terjadi di memori, sehingga masalah ini tidak besar
- Database tidak boleh kehilangan data meski server turun, dan ukuran data dapat tumbuh cepat hingga mencapai batas storage
- Banyak penyedia cloud memungkinkan storage yang terhubung lewat jaringan dan dapat dikonfigurasi secara terpisah dipasang ke instance compute
- Konfigurasi dasar EC2 biasanya memasang volume storage jaringan EBS
- Layanan database seperti Amazon RDS, Amazon Aurora, Google Cloud SQL, dan PlanetScale juga bergantung pada sistem yang memisahkan compute dan storage melalui jaringan
- Pendekatan ini memungkinkan volume storage disesuaikan secara dinamis mengikuti pertambahan atau pengurangan data
- Meski server turun, data tetap aman dan dapat dipasang kembali ke server lain
- Sebagai gantinya, muncul biaya performa berupa perjalanan bolak-balik jaringan dan batas IOPS
Perbedaan latensi antara NVMe lokal dan penyimpanan jaringan
- NVMe SSD yang terhubung langsung adalah SSD yang menggunakan spesifikasi antarmuka host controller memori non-volatil untuk menyediakan kecepatan IO dan bandwidth tinggi
- Perjalanan bolak-balik dari CPU ke RAM disebut sekitar 100ns
- Perjalanan bolak-balik dari CPU ke NVMe SSD lokal yang terhubung adalah sekitar 50.000ns, yaitu 50μs
- Volume storage yang terhubung lewat jaringan membutuhkan perjalanan bolak-balik jaringan singkat di dalam pusat data
- Storage yang terhubung lewat jaringan seperti EBS disebut memiliki round-trip time sekitar 250.000ns, yaitu 250μs atau 0,25ms
- Meski menggunakan SSD modern yang sama, koneksi jaringan membuat waktu pemrosesan tiap permintaan baca-tulis lebih lama dalam orde satu digit kali lipat
- Pada IO berurutan dalam jumlah besar, dampak negatifnya dapat dikurangi, tetapi tidak dapat dihilangkan
- Storage yang terhubung lewat jaringan menciptakan latensi tambahan setiap kali sistem mengakses storage
Batas IOPS dan perbedaan dengan penyimpanan yang terhubung langsung
- Banyak penyedia cloud, termasuk AWS dan Google Cloud, membatasi jumlah operasi IO yang dapat dikirim melalui wire dalam model storage yang terhubung lewat jaringan
- Instance Amazon GP3 EBS secara default mengizinkan 3000 IOPS per detik
- Nilainya dapat disetel lebih tinggi, tetapi memerlukan biaya tambahan
- Volume EBS GP2 sebelumnya bekerja dengan cara mengumpulkan pool IOPS agar sesekali dapat melakukan burst
- Jika storage dihubungkan langsung ke instance compute, tidak ada batas operasi IO buatan
- Pada koneksi langsung, sistem dapat membaca dan menulis sebanyak yang diizinkan perangkat keras
Cara mempertahankan durabilitas dan skalabilitas
- Masalah pertama pada SSD yang terhubung langsung, yaitu durabilitas data, dapat diselesaikan dengan replikasi
- Pola umumnya adalah menempatkan satu server sebagai primary yang menerima semua permintaan write, sementara dua atau lebih server tambahan mereplikasi data
- Jika data berada di tiga tempat, kemungkinan kehilangan data menjadi kecil
- Dengan angka contoh, jika probabilitas kegagalan server bulanan diasumsikan 1%:
- Pada satu server, probabilitas kehilangan data setiap bulan adalah 1%
- Pada tiga server, probabilitasnya turun menjadi
1% × 1% × 1% = 0,0001%, yaitu 1 banding 1 juta
- PlanetScale secara otomatis mendeteksi dan mengganti node yang gagal, serta sering mencadangkan data database secara andal
- Masalah kedua, yaitu skalabilitas drive, membutuhkan lebih banyak intervensi manual
- Diperlukan pemantauan dan peringatan saat disk mendekati batas kapasitas
- Diperlukan alat untuk meningkatkan kapasitas dengan mudah saat dibutuhkan
Pendekatan PlanetScale Metal
- Metal menyediakan cluster database yang menggunakan NVMe SSD yang terhubung langsung
- Setiap instance database berjalan dengan direct-attached NVMe SSD
- Cluster Metal secara default terdiri dari 1 primary dan 2 replica
- Cluster database yang didukung adalah Vitess atau Postgres
- Saat mencapai batas storage, ukurannya dapat disesuaikan ke server dengan drive yang lebih besar hanya dengan beberapa klik
- Secara internal, node baru dijalankan dan data dimigrasikan dari instance lama ke instance baru; proses ini ditangani dengan zero downtime
- Database Metal tidak memiliki IOPS cap buatan
- Pengguna dapat menjalankan operasi IO dengan latensi rendah, dan menggunakan perangkat keras sebanyak yang diizinkan tanpa biaya kelas IOPS mahal dari penyedia cloud atau throttle
1 komentar
Opini di Hacker News
Saya penulis blognya. Proses menulis artikel ini benar-benar menyenangkan, dan sejauh ini ini jelas artikel paling kompleks yang pernah saya buat.
Untuk membuat visualisasi interaktifnya, saya benar-benar menulis ribuan baris JavaScript, jadi semoga semuanya menikmatinya.
Namun, ungkapan “1 banding 1 juta” untuk durabilitas terasa terlalu pesimistis jika mempertimbangkan singkatnya waktu gangguan sampai server baru masuk dan replikasi ulang dilakukan.
Misalnya, jika pemulihan memakan 10 menit, bahkan jika tiga server pasti gagal masing-masing sebulan sekali, peluang ketiganya gagal bersamaan rasanya sudah sekitar 1 banding 2 juta; dan jika peluang gagal per bulan 1%, kemungkinan tiga gangguan itu tumpang tindih menjadi sangat kecil.
Saya menambahkan ini karena kalau pelanggannya 1 juta orang, angka 1 banding 1 juta bukanlah angka yang terlalu bagus.
Saya tahu waktu mengetik di keyboard dan waktu memikirkannya di kepala bisa cukup berbeda.
Topik ini sangat familier bagi saya, jadi tidak ada yang bisa saya tambahkan soal isinya, dan setelah saya skim pun terlihat bagus. Namun saya sedang merancang animasi untuk blog saya sendiri, dan beberapa library yang saya coba belakangan ini kurang memuaskan.
Selama beberapa waktu saya mendorong kombinasi SQLite+NVMe. Secara pribadi, ini tampak seperti pola baru yang memungkinkan kita melangkah jauh lebih jauh dari biasanya, dan dalam beberapa kasus bisa bertahan sampai akhir tanpa penskalaan horizontal.
Dalam performa, latensi adalah raja, terutama ketika item harus diproses secara serial. Menjalankan SQLite di atas NVMe memberi keuntungan latensi yang tidak bisa diberikan penyedia lain.
Untuk sebagian besar use case realistis, saya juga tidak berpikir eksekusi di memori jauh lebih baik daripada penyimpanan persisten NVMe.
Di satu host mungkin sedikit lebih cepat, tetapi begitu web server bertambah dari 1 menjadi 2 dan keduanya harus menulis ke database, sepertinya Anda membuat masalah jadi lebih sulit sendiri.
Pernyataan bahwa latensi itu penting juga bisa menyesatkan. Tanpa konsistensi, performa tidak ada artinya, dan begitu ada beberapa web server, Anda harus menyelesaikan konsistensi itu sendiri.
Selain itu, latensi database biasanya jauh lebih kecil daripada latensi round-trip internet, dan latensi internet itu pun kecil dibandingkan “latensi” menunggu aset halaman seperti gambar atau library kode dimuat.
Sejak awal, query database serial harus dihindari sebisa mungkin; gunakan join jika memungkinkan, dan jika tidak memungkinkan pun, kirim query secara asinkron dan serentak sebisa mungkin agar dieksekusi paralel.
Untuk menghindari masalah penulisan paralel, selain mengatur mode operasi tertentu yang agak kasar, ada trik menggunakan satu thread khusus penulisan di aplikasi.
Dengan begitu, kode paralel yang sudah kompleks biasanya menjadi sedikit lebih kompleks. Jika hanya ada satu thread penulisan, SQLite bekerja dengan sangat baik.
fsync()pada sebuah file di sistem file ext4 di komputer desktop, bahkan pada disk NVMe masih terukur latensi 1–2 ms.Pada sistem yang lebih baru, angkanya sekitar 800µs.
Kandungan informasinya begitu bagus sampai saya benar-benar lupa bahwa ini adalah promosi produk. Visualisasi dan interaksinya luar biasa.
Animasi I/O disk itu mengingatkan saya pada Melvin Kaye.
Mel tidak menggunakan loop penundaan waktu bahkan ketika Flexowriter yang lambat membutuhkan jeda di antara karakter keluaran.
Sebagai gantinya, ia menyesuaikan posisi instruksi di drum sehingga setiap kali instruksi berikutnya dibutuhkan, head baca baru saja melewatinya, dan drum harus berputar satu putaran lagi untuk menemukan instruksi berikutnya.
https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/The...
Metal memang terlihat sangat keren, tetapi ketika di tempat kerja sebelumnya saya memakai instance local SSD di GCP, ada masalah reliabilitas serius seperti blok perangkat kehilangan data.
Saya penasaran apakah sekarang situasinya sudah berubah, dan tipe mesin apa yang dipakai.
Waktu itu workaround-nya adalah ini: https://discord.com/blog/how-discord-supercharges-network-di...
Namun kami menjalankan sistem redundan dengan replikasi semi-sinkron MySQL, sehingga semua penulisan dipersistenkan di dua mesin di zona ketersediaan berbeda sebelum diakui ke klien.
Operator Kubernetes dan proses
vtorcdari Vitess bekerja bersama untuk secara aktif mendeteksi dan mengganti replika yang gagal atau mencurigakan.Di GCP kami melihat hasil terbaik pada mesin n2d-highmem, dan di AWS kami memakai hampir semua tipe generasi terbaru yang memiliki instance storage.
Tulisan yang bagus. Secara umum, cloud storage juga punya masalah karena sangat lambat
Ini sudah dibahas di tempat lain, tetapi tulisan ini merangkum masalahnya dengan baik: http://databasearchitects.blogspot.com/2024/02/ssds-have-bec...
Baru-baru ini https://github.com/feldera/feldera menambahkan dukungan untuk menyimpan indeks inkremental di S3/object storage, sementara NVMe sudah didukung lebih lama karena keunggulan performa yang jelas seperti disebutkan di tulisan sebelumnya
Semoga ada yang mengguncang area ini dengan cara penyediaan yang lebih baik
Ada bagian tentang distributed storage yang kurang dinilai secara memadai dalam tulisan ini
Pertama, sebagian sistem tidak menyediakan replikasi secara bawaan. Cluster Cassandra atau MySQL bisa memakai replikasi master-slave, tetapi banyak sistem lain tidak demikian
Kedua, jika memakai NVMe storage di cloud, operasinya jadi jauh lebih sulit karena harus memikirkan jendela pemeliharaan dan drain yang dimulai oleh cloud
Jika tidak terintegrasi dengan sistem semacam itu untuk memindahkan data ke node lain, datanya akan hilang
Dengan memisahkan storage dan compute, operator cloud dapat mengosongkan dan memindahkan compute saat diperlukan, data tetap independen dari compute, dan karena operator cloud juga mengelola sistem data serta drain tersebut, mereka bisa menyesuaikan penempatan workload tanpa intervensi pelanggan
Network-attached storage yang direplikasi dan terlihat seperti API filesystem “lokal” adalah cara yang kuat untuk memberi durability pada sistem yang tidak memiliki replikasi bawaan seperti milik kami
Benar-benar keren, dan PlanetScale Metal juga terlihat cukup solid. Saya terutama suka melihat latency turun besar dalam rilisnya: https://planetscale.com/blog/upgrading-query-insights-to-met...
Selama bertahun-tahun saya tidak paham mengapa database yang direplikasi selalu bertahan memakai EBS dan menerima latency-nya. Kalau sudah ada replikasi, mengapa tidak berani memakai disk lokal?
Di organisasi sebelumnya, saat menjalankan Elasticsearch sebagai penyimpanan sementara untuk log/metrik, saya mengusulkan itu karena kebutuhan reliability juga tidak besar, tetapi tidak berhasil meyakinkan mereka dan akhirnya kami memakai AWS Elasticsearch yang lebih buruk
Saya tahu kapasitas disk lokal terbatas, tetapi rasio core/memori/disk rasanya cukup untuk sebagian besar use case. Ada juga banyak instance dengan disk lokal yang rasionya berbeda, jadi keseimbangan yang sesuai bisa dicari
Instance hard disk lokal 20TB ke atas juga bisa dipakai untuk menerapkan hot/cold storage
Saya ingin memberi pujian besar kepada tim PlanetScale karena akhirnya melakukan hal yang masuk akal. Bahkan AWS tidak menjalankan Elasticsearch di disk lokal; bayangkan saja kalau hal-hal seperti ClickHouse atau Cassandra semuanya dijalankan di disk lokal
Masalah utamanya adalah disk akan terhapus setelah event stop-start. Meski sisa cluster baik-baik saja dan ada replika yang bisa digunakan, SQL Server tidak bisa menanganinya secara otomatis
Karena node yang sudah diinisialisasi ulang tidak dipulihkan otomatis, scripting dan pengujian untuk mengakalinya sulit ditanggung di production kecuali oleh organisasi yang paling berani dan kompeten
Kami menjalankan ratusan cluster ClickHouse dengan model seperti ini. Mengubah ukuran untuk menyelesaikan masalah performa jauh lebih sering terjadi daripada karena kegagalan
Misalnya, jika ada masalah performa tenant pada Minggu pagi waktu AS, solusi paling sederhana adalah menaikkannya ke VM yang lebih besar selama akhir pekan dan membiarkan tim inti melihat akar masalahnya pada Senin pagi
Biaya tambahannya kecil, dan dapat menghindari burnout karyawan yang jauh lebih mahal
Tulisan yang benar-benar bagus, dan visualisasi random write-nya dibuat dengan sangat baik
Saya punya beberapa pertanyaan yang mungkin bodoh tentang batas IOPS pada network-attached storage
Pertama, saya penasaran apakah batas “IOPS” adalah rate limit untuk jenis traffic jaringan tertentu, yaitu traffic ke dan dari volume EBS. Pada akhirnya saya ingin bertanya apakah “IOPS” berarti “traffic jaringan volume EBS”
Kedua, saya juga penasaran apakah pendekatan ini menghemat biaya. Jika ya, apakah karena arbitrase harga AWS yang aneh, atau karena ada keuntungan efisiensi dari berkurangnya networking EBS
Menempatkan storage dan compute di mesin yang sama jelas tampak punya keuntungan struktural dalam hal latency karena mengurangi satu hop, tetapi saya ingin tahu apakah juga menguntungkan dari sisi throughput per dolar
Saya cenderung melihatnya dengan model lain. Volume EBS bukan bagian dari papan fisik yang menempel ke bus PCIe, melainkan semacam saham dalam sistem terdistribusi berskala besar yang terdiri dari banyak drive fisik, lebih mirip SAN dengan kapasitas jaringan khusus ke dan dari compute
Biaya bisa saja lebih hemat, tetapi pada akhirnya ini adalah sekumpulan trade-off