Server penyimpanan cadangan dengan ZFS

Saya adalah segalanya di perusahaan kecil. Saya ingin merancang infrastruktur baru termasuk server baru dan server cadangan terpisah dengan kebijakan cadangan perusahaan yang luas.

Hal terpenting dalam perusahaan adalah SQL Server dan databasenya. Ada 10 database, tetapi hanya 2 yang benar-benar penting. Yang pertama 8GB, sebagian besar data teks dan angka. Yang kedua sekitar 300GB dengan 16GB / bulan tumbuh berisi PDF dan GIF.

Untuk menyimpan kebijakan cadangan penyimpanan saat ini terdiri dari satu cadangan penuh per minggu dan 6 diferensial. Saya pikir ini sekitar 350GB per minggu, 1,4TB per bulan.

Setelah membaca artikel tentang korupsi data diam, saya memutuskan untuk mencoba ZFS dengan edisi Komunitas Nexenta.

Pertanyaan saya: apakah ZFS dengan deduplikasi baik untuk menyimpan file cadangan dalam hal keandalan atau haruskah saya berpikir tentang beberapa tape backup atau sesuatu yang lain?

EDIT: Saya tahu bahwa saat ini kami tidak dapat memprediksi kinerja, rasio deduplikasi dll, tetapi saya ingin tahu apakah itu ide yang bagus sama sekali.

Tentu saja ZFS cukup stabil untuk melakukan hal semacam ini, ada banyak platform produksi yang sangat besar dan dapat diandalkan di luar sana yang sepenuhnya berbasis ZFS dan Nexenta.

Yang mengatakan selalu ingin memiliki cadangan berbasis disk di tempat seperti yang Anda sarankan DAN backup berbasis disk atau tape yang pergi setiap hari untuk melindungi dari kebakaran / gempa bumi / Cthulhu dll.

Jadi jawaban saya adalah ya, tidak masalah, tetapi saya akan memilih kedua opsi jika Anda bisa.

(dengan asumsi Anda merujuk menggunakan dedupe dalam ZFS versus perangkat lunak cadangan Anda)

Saya tidak akan merekomendasikan menggunakan deduplikasi asli ZFS untuk sistem cadangan Anda kecuali Anda merancang sistem penyimpanan khusus untuk itu.

Menggunakan dedupe di ZFS sangat intensif RAM. Karena deduplikasi terjadi secara waktu nyata saat data dialirkan / ditulis ke kumpulan penyimpanan, ada tabel yang disimpan dalam memori yang melacak blok data. Ini adalah tabel DDT . Jika server penyimpanan ZFS Anda tidak memiliki cukup RAM untuk mengakomodasi tabel ini, kinerja akan sangat menderita. Nexenta akan memperingatkan Anda saat meja tumbuh melewati ambang tertentu, tetapi saat itu, sudah terlambat. Ini dapat diperbesar dengan menggunakan perangkat L2ARC (baca cache), tetapi banyak pengguna awal ZFS masuk ke dalam perangkap ini.

Lihat:

ZFS - menghancurkan deduplicated zvol atau kumpulan data yang menghentikan server. Bagaimana cara memulihkan?

ZFS - Dampak kegagalan perangkat cache L2ARC (Nexenta)

Ketika saya mengatakan bahwa persyaratan RAM tinggi untuk menggunakan dedupe, saya akan memperkirakan kebutuhan RAM dan L2ARC untuk kumpulan data yang Anda gambarkan pada 64GB + RAM dan 200GB + L2ARC. Itu bukan investasi kecil. Menyimpan banyak file sistem Windows dan dokumen gambar yang tidak akan dibaca ulang akan mengisi DDT dengan sangat cepat. Imbalannya mungkin tidak sebanding dengan pekerjaan teknik yang harus dilakukan dimuka.

Ide yang lebih baik adalah dengan menggunakan kompresi pada zpool, mungkin meningkatkan kemampuan gzip untuk tipe data yang lebih kompresibel. Deduplikasi tidak akan sia-sia karena ada hit ketika Anda perlu menghapus data deduplikasi (perlu merujuk pada DDT).

Juga, bagaimana Anda akan mempresentasikan penyimpanan ke perangkat lunak cadangan Anda? Suite perangkat lunak cadangan mana yang akan Anda gunakan? Di lingkungan Windows, saya menghadirkan ZFS sebagai penyimpanan blok ke Backup Exec melalui iSCSI. Saya tidak pernah menemukan fitur ZFS CIFS cukup kuat dan lebih menyukai keunggulan perangkat yang diformat secara asli.

Juga, inilah sumber daya ZFS yang sangat baik untuk ide-ide desain. Hal Tentang ZFS Yang Tidak Ada Yang Memberitahu Anda

OS alternatif adalah OpenIndiana yang, sama baiknya dan menerima pembaruan lebih sering beberapa waktu.

Pilihan lain adalah menyiapkan server ZFS kedua dengan kumpulan penyimpanan yang lebih kecil (berpotensi) dengan kompresi diaktifkan. Anda dapat menggunakan perangkat kedua ini untuk cadangan statis. Dengan demikian Anda dapat membuang read cache dan juga tidak perlu jumlah CPU / RAM yang konyol untuk menanganinya.

Kami menjalankan pengaturan seperti ini di mana saya bekerja:

• Server penyimpanan utama OpenIndiana [ utama ] dengan enam disk 2TB dalam kumpulan RaidZ1 dengan tiga set pasangan cermin. Ini, sambil memotong ruang penyimpanan Anda yang tersedia, menjadikan kolam penyimpanan yang cepat dan berlipat ganda.
• Server cadangan sekunder [ cadangan ] juga menjalankan OpenIndiana dengan konfigurasi disk yang sama yang hanya berfungsi sebagai perangkat cadangan.
• main memiliki skrip yang dijalankan dari pekerjaan cron yang snapshots / tank / [dataset] secara teratur sepanjang hari
• Setiap malam, pekerjaan cron lain dijalankan yang mendorong snapshot hari itu melalui jaringan ke cadangan . Setelah sinkronisasi awal dari semua foto Anda dilakukan (prosedur sekali saja), sifat tambahan foto itu berarti bahwa perubahan didorong ke perangkat cadangan Anda dengan sangat cepat.

Saya memiliki ikhtisar singkat tentang cara memasang / mengirim ZFS ke sini: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/