Apakah ada cara yang baik untuk mencadangkan satu petabyte data dan menyimpannya?

Saya mulai melihat klien dengan ratusan terabyte data (dalam instalasi SQL Server). Ketika volume total data di beberapa perusahaan mendekati fraksi yang bermakna dari satu petabyte, saya ingin menelusuri basis pengetahuan kolektif di luar sana untuk melihat apa yang dilakukan orang-orang dengan besarnya data yang dilakukan untuk melindunginya.

Masalah yang jelas adalah bahwa menyimpan banyak cadangan data sebanyak itu sangat mahal, menggunakan penyimpanan kelas perusahaan, heck, bahkan hanya RAID-5.

Pilihan yang saya lihat adalah sebagai berikut:

1. Membuat salinan cermin dari data di pusat data lain, dan terus mengirimkan perbedaan padanya (menggunakan mekanisme apa pun yang tersedia untuk sumber data Anda - misalnya pengiriman log atau mirroring basis data dengan SQL Server)
2. Mengambil cadangan reguler menggunakan algoritma kompresi yang lumayan (mungkin hanya cocok jika data cocok untuk menjadi sangat terkompresi)
3. Ambil cadangan sedikit demi sedikit dari bagian penting / perubahan data.
4. Jangan membackup data dan percaya pada dewa korupsi.

Saya melihat opsi # 4 diadopsi sebagai default, dan sebagai ahli HA / DR itu benar-benar menakutkan, tetapi apa yang saya sarankan sebagai alternatif? Saya pikir # 1 adalah pendekatan terbaik, tetapi "Saya tidak berpikir begitu" adalah jawaban yang biasa ketika alternatif selain # 4 dan mungkin # 3 disarankan.

Sekarang, tentu saja itu tergantung pada tingkat perubahan dan kekritisan data. Tidak perlu menjawab dengan itu karena saya dulu bertanggung jawab untuk semua fitur HA dari SQL Server sementara saya bekerja di Microsoft jadi saya berpengalaman dalam argumen 'itu tergantung' - itulah frase-frase saya :-)

Saya akan sangat tertarik untuk mendengar alternatif apa pun yang saya lewatkan, atau mendengar bahwa semua orang ada di kapal yang sama dan tidak ada alternatif realistis untuk menghabiskan banyak uang untuk penyimpanan lebih banyak.

Terima kasih sebelumnya - kredit jatuh tempo akan diberikan untuk semua jawaban yang dipikirkan dengan matang dan diungkapkan.

Gagasan dinding - apakah semua informasi yang disimpan diperlukan atau bahkan berguna?

Berapa nilai sebenarnya informasi itu? Tampaknya konyol untuk menghabiskan lebih banyak dalam pemeliharaan dan manajemen daripada nilai data.

Apakah data dalam database sesuai untuk penyimpanan dalam database? Misalnya, apakah menyimpan file inti multi-gigabyte terkompresi dalam database organisasi pendukung benar-benar memberikan manfaat yang sebenarnya?

Apakah ada banyak data duplikat dalam database? Misalnya, apakah seribu orang menyimpan sepuluh salinan setiap buletin mingguan 10MB?

Apakah beberapa data memiliki "tanggal kedaluwarsa" setelah itu tidak memberikan nilai apa pun? Kembali ke contoh organisasi pendukung, karena berbagai alasan, hampir tidak ada manfaatnya menjaga file inti pelanggan lebih dari beberapa bulan setelah perbaikan dikirimkan.

Pemikiran lain - menjaga agar banyak data yang membuka perusahaan menjadi liabilitas. Beberapa data harus, oleh hukum, disimpan. Beberapa data, bagaimanapun, harus "dihancurkan" karena risiko yang ditimbulkan jika secara tidak sengaja, atau jahat, dirilis ke pihak yang tidak pantas.

Ya, opsi lain adalah virtualisasi penyimpanan: perangkat yang berada di antara server Anda dan SAN, seperti IBM SVC. SVC mengelola salinan SAN-ke-SAN, dan dapat melakukan replikasi jarak jauh (meskipun itu jelas sangat menyakitkan di tingkat petabyte kecuali Anda memiliki tingkat perubahan data yang sangat rendah dan bandwidth yang sangat tinggi.)

Bagian yang licin adalah bahwa seluruh proses tidak terlihat oleh server yang terlibat. Jika Anda menggunakan SQL Server, Anda mendesain filegroup Anda untuk menjaga hal-hal dengan tingkat perubahan rendah bersama-sama (seperti arsip penjualan dari> 3 tahun yang lalu), dan hal-hal dengan tingkat perubahan tinggi (seperti penjualan saat ini) pada grup grup terpisah. Mereka bahkan tidak harus sepenuhnya hanya baca - Anda hanya ingin mendesainnya sehingga Anda dapat menggunakan metode replikasi yang berbeda untuk setiap grup file. Gigi SAN dapat menyinkronkan lun melalui jaringan, pita, atau melalui SAN - artinya, Anda dapat mengirim bagian SAN bolak-balik. Ini lebih efektif dengan gigi seperti LeftHand, di mana SAN terdiri dari kumpulan unit yang berpartisipasi.

Kemudian Anda dapat menyinkronkan item laju perubahan rendah melalui kabel secara otomatis, dan menyinkronkan laju perubahan tinggi dengan sneakernet. (Kedengarannya saya mendapatkan itu dari belakang, tapi itu benar - Anda tidak dapat menyinkronkan hal-hal tingkat perubahan tinggi melalui kabel karena volume.) Bahkan beberapa gigi kelas bawah mengakomodasi ini sekarang: LeftHand memungkinkan Anda menggandakan ke yang lain LeftHand unit di pusat data Anda, dan kemudian kirim ke pusat data luar kantor Anda. Hubungkan mereka, gabungkan mereka ke sisi jarak jauh dengan mengubah IP dan grup, dan sekarang mereka menjadi bagian dari SAN cadangan jarak jauh Anda. Pidato penjualan LeftHand hanya brilian: atur dua SAN Anda secara berdampingan di pusat data utama Anda, selaraskan, lalu Anda bisa mengirimkan sebagiannya ke pusat data yang jauh sementara beberapa dari mereka tetap di arus Anda pusat data untuk tetap sinkron. Berangsur-angsur bergerak '

Saya belum melakukan ini pada tingkat petabyte. Anda tahu apa yang mereka katakan - dalam teori, dalam teori dan dalam praktik adalah sama. Dalam praktek...

Opsi 1 mirroring, yang hampir seburuk # 4: bug apa pun yang merusak data, dan tidak segera ditemukan, akan merusak kedua salinan.

Jika data sangat penting, pertimbangkan solusi khusus; baca tentang produk Shark IBM, misalnya, atau produk pesaing dari EMS, dll. Mereka memiliki fitur seperti salinan-Flash, yang memungkinkan Anda untuk secara instan membuat salinan logis file tanpa menggandakan persyaratan disk; dan kemudian Anda dapat membuat cadangan salinan ini ke (misalnya) rekaman. Lihatlah cadangan pita robot juga.

Tunjukkan kepada mereka yang ingin menyimpan Petabyte data yang penyimpanannya tidak murah.

Saya sangat muak dengan orang-orang yang mengeluh tentang tidak memiliki ekstra Terabyte penyimpanan online karena disc murah - disc mungkin, tetapi penyimpanan dikelola pasti tidak.

Jika sangat mahal untuk menyimpan cadangan maka sangat mahal untuk menyimpan data dengan cara yang aman, sehingga solusi yang diusulkan tidak layak.

Salah satu alasan paling penting untuk memiliki cadangan adalah perlindungan dari kesalahan pengguna (sebagian besar masalah kegagalan perangkat keras dapat ditangani dengan solusi perangkat keras) tetapi bahkan pencerminan basis data tidak ada perlindungan terhadap tabel yang terjatuh (OK, Anda dapat melindungi dari itu, tetapi masih mungkin untuk memasukkan masalah yang tidak dapat dilepaskan ke dalam DB Anda - kecuali alasan DB begitu besar adalah karena ia hanya akan memasukkan sisipan).

Seperti yang saya lihat, tape tidak lagi menjadi solusi yang layak - sekarang lebih murah hanya bekerja dengan array disk (meskipun penyimpanan fisik dapat menjadi canggung). Jadi saya pikir satu-satunya pilihan Anda adalah beberapa metode untuk membagi data menjadi potongan-potongan yang cukup kecil untuk dipulihkan dalam jangka waktu yang masuk akal dan kemudian membawanya ke penyimpanan disk secara teratur (dan di sini solusi jenis EMS dapat membantu, jika Anda punya tunai).

Video menarik yang merinci arsitektur myspace.com (SQL2005 backend). Tidak yakin apakah mereka memiliki dbs petabyte individual karena mereka berskala dengan beberapa dbs. Mereka menggunakan backup snap SAN.

http://wtv.watchtechvideos.com/topic70.html

ZFS. Tentu, ini masih baru saja dimulai, tetapi ada sejumlah area di mana ZFS dirancang untuk menangani hal-hal semacam ini. Pertama, kemampuannya untuk menangani sejumlah besar data, serta banyak perangkat penyimpanan yang berbeda (lokal, SAN, serat, dll.), Semuanya menjaga data tetap aman dengan checksum dan "lapisan melanggar" kesadaran akan kesehatan perangkat dan kegagalan. Namun bagaimana hal ini membantu menyelesaikan pencadangan data sebanyak ini?

Salah satu metode adalah dengan menggunakan snapshot. Ambil snapshot, kirimkan ke tape / disk / net untuk transfer ke situs jarak jauh. Snapshots berikutnya hanya mengirim data yang telah dikirim, dan Anda dapat menyimpan data langsung di kedua ujungnya jika perlu.

Yang lain adalah dengan menggunakan perangkat lunak Solaris Cluster di mana (selama Anda memiliki bandwidth jaringan yang cukup) Anda dapat memiliki mirroring langsung antara dua server dan jika yang turun, yang kedua dapat mengambil alih. Ini lebih untuk digunakan di mana ketersediaan tinggi (HA) penting, tapi saya kira sebagian besar tempat dengan data sebanyak itu menginginkan HA.

Dan Anda mengatakan bahwa ZFS tidak didukung pada Windows, tempat biasa Anda mungkin menemukan sqlserver, mungkin Anda menjalankan Sun / ZFS di backend dan terhubung melalui iSCSI. Mungkin itu ide yang mengerikan juga, tapi setidaknya patut untuk dipikirkan sehingga Anda tahu apa yang tidak boleh dilakukan.

Sudahkah Anda melihat Gletser Amazon sebagai opsi?

IMO, kecuali Anda memiliki beberapa jenis perangkat keras tingkat godzilla, jika Anda memiliki banyak data Anda harus menggunakan teknologi kompresi cadangan. Saya paling akrab dengan LiteSpeed, tetapi ada produk serupa dari vendor lain dan (tentu saja) fitur serupa dibangun ke dalam SQL2008. Anda mungkin tidak mendapatkan kompresi 10-ke-1, tetapi tidak memangkas persyaratan penyimpanan untuk cadangan, dan juga dapat mengecilkan persyaratan cadangan Anda. Jika tujuan Anda adalah menyimpan beberapa set cadangan (kemarin plus hari sebelumnya, ditambah satu dari minggu lalu dan satu dari bulan lalu, atau serangkaian diferensial plus penuh, yang bisa menjadi sangat besar jika Anda mengubah banyak data di database), ini masalah ruang penyimpanan sederhana.

Cadangan berbasis filegroup (TKI, memasukkan data yang tidak mudah menguap ke FG tertentu dan jarang melakukan backup) sepertinya tidak pernah terbang karena pengembang atau pengguna tidak akan atau tidak dapat memutuskan data apa yang volatil dan tidak, dan di brownfield skenario Anda sering tidak dapat mengambil risiko.

Jika situs failover adalah persyaratan, selain memikirkan Database Mirror) Anda mungkin ingin berbicara dengan vendor penyimpanan klien Anda untuk melihat apakah mereka menawarkan sesuatu seperti SRDF, yang merupakan teknologi replikasi data berbasis perangkat keras. Tentu saja, replikasi (dalam bentuk apa pun, tetapi khususnya replikasi real-time atau hampir-real-time) bukan pengganti cadangan.

Saya tidak berpikir Anda punya banyak pilihan di sini di tape v. Disk. Kaset kemungkinan tidak akan memotongnya di jendela cadangan reguler kecuali Anda menghapusnya, dan saya tidak yakin keandalannya ada.

Jadi Anda ke cadangan disk. Apakah Anda versi? Berarti apakah Anda khawatir tentang kembali ke cadangan 2 (cadangan db saat ini dikurangi 2 cadangan)? Atau cadangan 3? Dalam hal ini, Anda mungkin memiliki masalah, tetapi kemungkinan yang harus Anda tangani adalah pencadangan log, bukan cadangan data yang begitu banyak.

Jika Anda dapat memisahkan sebagian data sebagai hanya baca / tidak berubah, maka mungkin Anda memiliki ukuran / jendela cadangan yang dapat dikelola. Atau setidaknya Anda berharap bahwa teknologi cadangan dan bandwidth dapat mengejar pertumbuhan data.

Saya tidak berpikir Anda mendukung sebanyak Anda menyimpan salinan ke-2 untuk pulih dari masalah dengan utama Anda. Itu berarti perangkat keras, korupsi, dll., Dan Anda berdoa setiap hari bahwa kesalahan tidak dikirim ke salinan kedua. Salinan yang paling mungkin sedang dibuat SAN-SAN, dengan beberapa teknologi snap-shot'ing. meskipun salinan aslinya mungkin melalui Fed-Ex daripada melintasi kawat. Bandwidth untuk bergerak 100TB tidak mudah didapat oleh siapa pun.

Saya pikir Anda memerlukan kombinasi 1, 2, dan 3 (bukan 4), dengan manajemen cadangan log yang sangat baik.

Sebenarnya saya pikir pada suatu saat Anda benar-benar melihat 3 salinan data Anda. Menjalankan CHECKDB pada 1 salinan sementara salinan ke-2 digunakan untuk benar-benar menerima perubahan. Kemudian Anda mengambil salinan ke-2 itu ke yang pertama dan melanjutkan. Dengan data sebanyak ini, saya bayangkan Anda akan membutuhkan ketekunan di sini. Paul, bagaimana checkdb bekerja pada multi-user, 100TB db yang sedang online?

Seperti disebutkan, bukankah cadangan log, dan mungkin pembaca log, penting? Tidakkah Anda perlu memulihkan tabel drop / kesalahan pengguna dari log daripada cadangan? Anda dapat berpotensi melakukan pintasan ini dengan mengirimkan salinan SAN melalui beberapa penundaan, tetapi saya belum melihat teknologi itu. Log Pengiriman SAN yang dapat menunda perubahan hingga 4 jam (atau beberapa interval) untuk memungkinkan Anda pulih dari masalah sebelum menimpa data. Atau alat log-reader-of-SAN-block-changes? Tanpa itu, Anda perlu mengelola log transaksi tersebut, yang mungkin merupakan tingkat lain dari pelacakan cadangan tersebut pada berbagai sistem file selama beberapa jam xxx untuk memungkinkan Anda pulih dari kesalahan tidak fatal.

Secara teknis, penyimpanan adalah murah, tapi di tingkat petabyte, tidak begitu banyak. Itu benar-benar tergantung pada aplikasinya, tetapi saya akan mengatakan beberapa kombinasi strategi # 2 dan # 3 akan menjadi jawabannya, dengan # 2 diberikan dan # 3 tergantung pada berapa banyak investasi yang dapat Anda lakukan dalam penyimpanan dan jenis penyimpanan dan IO / daya komputasi yang akan membuat Anda lolos dengan sedikit incrementalism dan sebanyak mungkin, cadangan penuh sebanyak mungkin.

Atau, sesuatu seperti Amazon S3 juga dapat ikut bermain tergantung pada bandwidth Anda dan seberapa banyak perubahan yang ada dalam data - pada volume ini, menempatkan setidaknya beberapa di server orang lain dan membiarkan mereka khawatir tentang redundansi semakin dan semakin banyak hemat biaya.

Bicaralah dengan vendor penyimpanan Anda, mereka akan memiliki produk deduplikasi yang telah mereka gunakan sebelumnya, dikombinasikan dengan kompresi reguler Anda sering dapat mengurangi jejak data Anda hingga 70%. Tentu saja siapa pun yang memiliki uang untuk dibelanjakan pada penyimpanan petabyte juga cenderung memiliki anggaran untuk membeli solusi cadangan yang layak juga - jika mereka belum melakukannya, Anda hanya perlu bertanya kepada mereka apa kehilangan petabyte yang akan menelan biaya bisnis mereka.

Di gudang data perusahaan besar, banyak data berasal dari sumber yang sudah dicadangkan. Saya telah bekerja pada instalasi Teradata dan ODW di mana mereka telah mengambil opsi # 4, tetapi diketahui bahwa mereka dapat memulihkan satu atau dua hari data transaksional dan mengubahnya dari sistem sumber.

Di satu klien ritel (pada saat itu mereka memiliki salah satu dari 5 DWs terbesar di dunia, sekitar 200TB ... memberi Anda ide untuk berapa lama ini), mereka pergi dengan opsi # 1 setelah membeli Petabyte baru -kelas Teradata server. Node yang lama akan digunakan untuk snapshot dari sistem hari sebelumnya, sementara yang baru mempertahankan yang sudah ada. Ini juga bagus dari perspektif failover - sesekali mereka akan melakukan semuanya untuk pemeliharaan dan kami hanya akan beralih menggunakan server lambat lama dengan data lama.

Jujur saja, sepertinya membuang-buang besar pemrosesan / penyimpanan / dll untuk menjaga hal itu terjadi ... terutama ketika keuntungan terbesar adalah bahwa admin dan teknisi NCR mereka harus bekerja lebih sedikit malam untuk melakukan pemeliharaan yang tidak teratur.