Penyimpanan Perusahaan
SAN vs NAS: Kapan Block Storage Menjadi Pilihan Tepat
Kebutuhan storage lebih besar tidak otomatis berarti SAN. Pahami manfaat blok, tempat NAS cocok serta pemeriksaan performa, redundansi dan pemulihan sebelum membeli.
Bisnis menambah server kedua. Backup masuk jam kantor, database tersendat saat sibuk dan seseorang menyarankan mengganti NAS dengan SAN. Mungkin tepat, tetapi pastikan dahulu apakah masalahnya latensi disk, jaringan jenuh, tugas bersaing atau desain ketersediaan tidak ada. Mengganti label storage tidak otomatis memperbaikinya.
File dan Blok: Siapa Mengelola Sistem File?
Network-attached storage (NAS) menyajikan file dan folder. NAS atau server file mengelola sistem file, izin dan akses bersama; klien biasanya melalui SMB atau NFS. Ini dapat melayani kantor kecil, tim kreatif atau lingkungan file enterprise jauh lebih besar.
Storage area network (SAN) memberi block storage ke host, umumnya melalui iSCSI atau Fibre Channel. Server atau cluster didukung memakai volume atau LUN dan menyediakan sistem file atau aplikasi. iSCSI dapat memakai Ethernet; Fibre Channel memakai fabric kompatibel sendiri. Keduanya tidak menentukan media, kapasitas usable atau respons yang dicapai.
Akses File: NAS Mengelola Sistem File
- Pengguna / Aplikasi
- Jaringan Ethernet
- NAS / Layanan File
Klien meminta file dan folder. Layanan file mengelola akses bersama serta izin.
Akses Blok: Host Mengelola Volume
- Server / Cluster
- Jalur SAN Didukung
- Block Storage
Host memakai volume atau LUN. Penulisan bersama perlu desain koordinasi dan fencing didukung.
Peran dapat berdampingan. Server file dapat menyimpan data di SAN sambil tetap memberi SMB kepada staf. Sebagian platform memberi file dan blok. Beli layanan serta perilaku kegagalan yang diperlukan, bukan menganggap NAS dan SAN kelas hardware saling meniadakan.
Cocokkan Storage dengan Beban
| Beban kerja | Titik awal masuk akal | Yang wajib diperiksa |
|---|---|---|
| Dokumen bersama, folder proyek dan izin | NAS atau layanan file terkelola | Integrasi identitas, penguncian file, snapshot dan restore |
| Arsip media besar atau repositori backup | NAS berorientasi kapasitas, server file atau object storage | Retensi, stream bersamaan, pertumbuhan dan throughput restore |
| Mesin virtual | Datastore file atau blok didukung hypervisor | Protokol didukung, latensi, multipathing dan perilaku cluster |
| Database transaksional | Desain storage didukung vendor database | Latensi berkelanjutan, durabilitas tulis, log dan pemulihan |
| Beberapa host berbagi volume blok | SAN dan desain cluster didukung | Fencing, akses terkoordinasi dan tes kegagalan |
Tanyakan “Konfigurasi storage apa yang didukung aplikasi ini?” Hypervisor mungkin mendukung datastore NFS dan blok. Database mungkin mensyaratkan urutan tulis atau ketahanan tertentu. Periksa sebelum menganggap satu protokol secara bawaan lebih profesional.
Tidak Ada Batas Peralihan Otomatis 500 TB
Melewati 100 TB, 500 TB atau angka bulat lain ialah peristiwa perencanaan kapasitas, bukan perintah pindah ke SAN. Arsip sekuensial dengan konkurensi ringan berbeda dari sistem transaksi kecil yang sibuk.
Rencanakan ruang usable setelah RAID atau erasure coding, overhead sistem file, snapshot, pertumbuhan dan ruang kerja. Nilai waktu rebuild perlindungan, backup perubahan dan pemulihan bisnis. Rujukan kami, kalkulator RAID membantu hitungan kapasitas, bukan menentukan kompatibilitas aplikasi atau desain pemulihan tepat.
Ukur Latensi dan Perebutan Sumber Daya Sebelum Mengganti Storage
Ambil bukti saat benar-benar lambat. Catat waktu respons aplikasi, latensi dan antrean storage, campuran baca/tulis, utilisasi disk dan throughput jaringan. Periksa tugas lain: backup, antivirus, snapshot atau replikasi dapat mengubah hasil.
- Untuk file besar, periksa throughput berkelanjutan di klien, switch, antarmuka storage dan pool disk.
- Untuk database dan VM, lihat latensi pada campuran permintaan kecil representatif, bukan hanya salinan sekuensial.
- Uji cukup banyak data agar lonjakan cache singkat tidak disangka performa disk berkelanjutan.
- Bandingkan operasi normal dengan kondisi degraded atau rebuild realistis bila platform mendukung tes terkontrol.
Antarmuka lebih cepat dapat mengatasi hambatan tanpa mengubah protokol. Sebaliknya, 25GbE tidak memperbaiki pool yang dibatasi akses disk atau aplikasi berlebih beban. Rujukan panduan penanganan transfer NAS lambat memberi urutan praktis memisahkan penyebabnya.
Akses Blok Bersama Perlu Koordinasi
Memberikan satu LUN ke dua server tidak membuat sistem file biasa aman menulis bersamaan. Tanpa cluster, locking dan fencing didukung, host dapat menimpa metadata satu sama lain dan merusak volume.
Gunakan susunan shared storage didukung OS, hypervisor dan vendor. Bisa berupa sistem file sadar-cluster, datastore tercluster didukung atau aplikasi yang eksplisit mengoordinasi akses. Tentukan pemilik tiap volume dan tindakan saat host kehilangan cluster. Jangan pernah mengujinya dengan memasang volume produksi yang ada ke host lain yang dapat menulis.
Dua Controller Hanya Bagian Ketersediaan
Array dual-controller mengurangi risiko tertentu. Layanan end to end tetap bergantung adapter host, kabel, switch, daya, konfigurasi jalur dan aplikasi. Dua jalur lewat switch atau daya sama dapat menyisakan titik gagal bersama.
Sistem Synology UC3400 merupakan contoh layanan SAN active-active dengan dukungan iSCSI dan Fibre Channel sesuai konfigurasi didukung yang tepat. Perannya berbeda dari NAS desktop berbagi file. Pastikan host, adapter, firmware serta multipathing sebagai satu desain.
Dokumentasikan perilaku sebelum tes penerimaan: jalur yang gagal, deteksi host, kelanjutan I/O dalam batas aplikasi dan pemulihan layanan setelah perawatan. Redundansi belum pernah diuji masih asumsi.
Siapkan Rencana Operasi untuk Masa Depan
Lihat lebih dari bay kosong. Sediakan uplink, adapter dan transceiver terkualifikasi, dukungan, perawatan firmware, monitoring, daya rack dan kapasitas backup. Pastikan penambahan shelf atau perubahan drive didukung tanpa mengganggu layanan.
Tugaskan seseorang untuk alarm kapasitas, jalur gagal dan pemeriksaan pemulihan. Sistem sederhana dengan rencana jelas bisa lebih sesuai daripada platform besar yang tidak mampu dirawat tim. Untuk kapasitas padat di belakang host, baca panduan arsitektur Exos CORVAULT; dijelaskan mengapa SAS storage tetap perlu server dan front end sesuai.
Tetapkan Tes Penerimaan Sebelum Membeli
- Sebut aplikasi, protokol didukung, versi host dan kapasitas usable diperlukan.
- Tentukan latensi dan throughput diterima pada beban representatif tersibuk.
- Tetapkan tujuan recovery point dan recovery time untuk hardware gagal serta data hilang atau rusak.
- Sepakati tes kegagalan jalur, controller dan daya yang aman dilakukan.
- Pulihkan aplikasi atau dataset representatif dari backup independen.
Sebuah proof of concept sangat berguna bila keputusan bergantung perilaku aplikasi, bukan kecepatan antarmuka publikasi. Jaga tes berulang dan simpan konfigurasi serta hasil.
Pertanyaan yang Sering Diajukan
Apakah SAN selalu lebih cepat dari NAS?
Tidak. Media, controller, jalur, ukuran permintaan, konkurensi dan desain aplikasi menentukan performa. Layanan file berukuran tepat dapat mengungguli blok kurang memadai. Bandingkan beban dan latensi yang diperlukan.
Haruskah bisnis pindah ke SAN di atas 500 TB?
Tidak ada ambang kapasitas universal. Arsip file besar tetap bisa NAS atau layanan file lain. Keputusan bergantung metode akses, performa, pertumbuhan, ketersediaan dan pemulihan.
Bisakah VM berjalan pada NAS?
Ya, bila hypervisor dan platform mendukung protokol file serta konfigurasi terpilih. Periksa matriks kompatibilitas terkini, kebutuhan datastore dan perilaku gagal produk tepatnya.
Bisakah dua server menulis ke LUN iSCSI sama?
Hanya dengan desain didukung yang mengoordinasi akses, seperti cluster atau aplikasi sesuai. Memasang sistem file writable biasa pada dua host independen dapat merusak data.
Apakah dual-controller menghapus kebutuhan backup?
Tidak. Redundansi controller menangani kegagalan hardware tertentu, bukan salinan pemulihan independen untuk penghapusan, ransomware, kerusakan aplikasi atau insiden lokasi.
Informasi apa untuk sizing SAN atau NAS?
Berikan aplikasi dan versi host, usable dan pertumbuhan, beban baca/tulis, kebutuhan latensi, desain jaringan, jendela backup, tujuan pemulihan dan harapan dukungan.
Jalur Storage Mana yang Masuk Akal?
Pertahankan NAS sebagai opsi untuk file bersama, arsip dan aplikasi berbasis file yang didukung. Pertimbangkan SAN bila aplikasi, clustering atau ketersediaan perlu blok. Validasi beban dan seluruh jalur sebelum membayar migrasi.
Untuk proyek baru, mulai dengan panduan pemilihan NAS atau diskusikan beban terdefinisi melalui konsultasi jaringan dan storage. Spesifikasi paling berguna menjelaskan layanan yang harus tetap dijalankan bisnis.
