Gambaran umum migrasi pita Azure Storage
Artikel ini berfokus pada migrasi pita. Ini bertujuan untuk menyederhanakan, memberikan panduan, dan pertimbangan untuk berjalan melalui keberhasilan migrasi data yang disimpan di berbagai media pita ke layanan penyimpanan Azure.
Gambaran Umum
Pita menyimpan sebagian besar data dunia, dan tetap menjadi salah satu jenis media penyimpanan yang dominan. Media pita ada selama beberapa dekade, dan masih banyak digunakan dengan ratusan eksabyte kaset baru yang dikirim setiap tahun.
Kaset adalah media yang bagus untuk menyimpan data dingin. Mereka cepat dalam pembacaan berurutan, tetapi tahapan yang membutuhkan gerakan mekanis (seperti memuat, dan membongkar kaset, pencarian pita, dll.) lebih lambat. Itu membuat kaset tidak dapat digunakan untuk akses tradisional berbasis acak, dan merupakan alasan utama bahwa bahkan saat ini data yang disimpan pada kaset jarang digunakan. Selain itu, pita adalah media magnetik yang membutuhkan penanganan khusus. Mereka sensitif terhadap lingkungan, terutama suhu, dan kelembaban. Jika disimpan dalam rentang lingkungan operasi mereka, mereka dapat mencapai durabilitas tinggi, dan tingkat keberhasilan pemulihan yang baik. Namun, ketika disimpan di lingkungan yang tidak ramah, kemunduran sering terjadi, dan merender pita tidak dapat dibaca.
Sebagian besar pita menyimpan data gelap (data yang dibuat, dan disimpan, tetapi tidak digunakan untuk tujuan apa pun). Data gelap tidak membawa nilai bagi pemilik data. Dengan peningkatan kemampuan AI, dan aksesibilitas, tren berubah. Pelanggan mencari tahu bagaimana data gelap dapat membantu mereka meningkatkan efisiensi, membuka aliran pendapatan baru, atau meningkatkan keunggulan kompetitif mereka. Untuk memanfaatkan data gelap, banyak organisasi mempertimbangkan untuk memigrasikan data dari kaset ke penyimpanan cloud. Penyimpanan cloud menyediakan cara mudah untuk menganalisis data, mengekstrak nilai bisnis (dengan layanan seperti AI, Pembelajaran Mesin, Azure Search, dll.), atau mengurangi biaya dengan memanfaatkan penyimpanan arsip untuk retensi jangka panjang.
Beberapa alasan utama kami melihat peningkatan migrasi pita ke cloud adalah:
- Mengekstrak nilai bisnis dari data gelap,
- Kurangi upaya yang diperlukan untuk mengelola data dengan retensi jangka panjang,
- Hindari proses migrasi dari satu pembuatan pita ke generasi lainnya,
- Mengurangi risiko kehilangan data, terutama untuk generasi kaset yang lebih lama,
- Ganti fasilitas penyimpanan pita di luar situs,
- Menyederhanakan proses pemulihan bencana,
- Menerapkan alat modern seperti AI, dan ML ke data historis.
Pertimbangan
Sebelum proses migrasi pita dimulai, opsi harus dipertimbangkan dengan hati-hati. Pertimbangan pertama adalah memutuskan siapa yang menjalankan migrasi. Dua opsi umumnya digunakan:
- Pelanggan melakukan migrasi di mana pelanggan menjalankan migrasi end-to-end,
- Mitra migrasi pita tempat pelanggan mengirimkan kaset ke mitra, dan mitra menjalankan proses migrasi.
| Pendekatan | Pro | Kontra |
|---|---|---|
| Migrasi yang dilakukan pelanggan | - Data tidak pernah meninggalkan situs - Tidak ada logistik untuk kaset pengiriman |
- Membutuhkan sumber daya perangkat keras - Menambahkan lebih banyak pekerjaan ke personel - Membutuhkan pengetahuan khusus dalam menangani kaset - Kemungkinan biaya yang tidak diketahui |
| Mitra migrasi pita | - Harga sederhana, dan biaya yang diketahui di muka (dibayar per pita) - Tidak ada dampak pada produksi - Tidak ada dampak pada personel |
- Membutuhkan logistik untuk kaset pengiriman - Pertimbangan keamanan diperlukan karena pita pengiriman - Beberapa salinan yang diperlukan untuk ketersediaan data selama migrasi |
Beberapa pertimbangan utama dapat dengan mudah memandu keputusan kami tentang siapa yang dapat menjalankan migrasi, pelanggan, atau mitra.
Sumber
Sumber daya adalah bagian paling penting dari proses migrasi pita, dan kami membaginya dalam kategori berikut:
| Kategori | Catatan |
|---|---|
| Rakyat | - Set keterampilan khusus diperlukan - Prosesnya padat karya |
| Perangkat Keras | - Generasi pita yang berbeda memerlukan berbagai jenis perangkat keras - Kecepatan migrasi sebanding dengan drive yang tersedia, dan bandwidth jaringan |
| Perangkat lunak | - Akses ke perangkat lunak yang membuat data diperlukan - Akses ke kunci enkripsi diperlukan |
Perangkat keras biasanya merupakan bagian yang paling menantang. Jika kita memigrasikan generasi pita yang ada, perangkat keras tersedia, tetapi digunakan sebagai bagian dari produksi yang ada. Tetapi untuk generasi pita yang lebih lama, perangkat keras seringkali akhir masa pakai, dan lebih sulit untuk diperoleh. Dengan pembuatan pita yang lebih lama, menggunakan mitra migrasi pita adalah pilihan yang lebih disukai, dan lebih sederhana. Ketika perangkat keras produksi digunakan untuk migrasi, perencanaan yang cermat diperlukan untuk memastikan migrasi tidak mengganggu beban kerja produksi. Di sini kita dapat menerapkan tiga model berbeda:
- Gunakan perangkat keras khusus untuk migrasi: model migrasi paling sederhana, mudah dijadwalkan, dan rencanakan tanpa dampak terhadap produksi. Ini menambahkan biaya untuk memperoleh perangkat keras (jika belum tersedia), dan menyebabkan pemanfaatan perangkat keras yang rendah pascamigrasi.
- Menjalankan migrasi di luar jam kerja pada perangkat keras produksi: model migrasi tanpa dampak terhadap produksi. Memerlukan penjadwalan, eksekusi, dan orang yang bekerja di luar jam kerja yang kompleks. Mungkin hanya jika perangkat keras produksi tidak digunakan 24x7.
- Jalankan produksi, dan migrasi bersama- sama: model migrasi yang paling tidak disukai karena dapat dengan mudah memengaruhi produksi. Model ini mengurangi perangkat keras yang tersedia untuk produksi, memerlukan penjadwalan yang kompleks, dan perencanaan. Jika model ini digunakan, proses sekeliling mengurangi dampak terhadap produksi sangat penting untuk menjaga garis waktu migrasi tetap terkendali. Model ini direkomendasikan hanya ketika perangkat keras produksi memiliki pemanfaatan yang rendah.
Opsi transfer data
Setelah data dibaca dari rekaman, data perlu dipindahkan ke Azure Storage. Data dapat dipindahkan menggunakan jaringan, atau perangkat offline seperti Azure Data Box. Beberapa parameter yang memengaruhi pilihan opsi transfer data adalah:
- Bandwidth jaringan yang tersedia
- Garis waktu yang diperlukan untuk menyelesaikan migrasi
- Frekuensi perubahan data
Pelajari selengkapnya tentang panduan untuk memilih opsi optimal di sini. Transfer jaringan lebih sederhana dan lebih disukai. Kombinasi jaringan, dan metode offline juga dimungkinkan, tetapi memerlukan lebih banyak perencanaan untuk memastikan bahwa data yang dimigrasikan tidak tumpang tindih.
Jika tidak ada sumber daya yang tersedia untuk melakukan migrasi, apa pun jenis sumber dayanya, satu-satunya opsi kami adalah menggunakan mitra migrasi pita. Dalam hal ini, kita dapat memilih antara dua opsi:
- Migrasi yang dilakukan di situs pelanggan: mitra migrasi pita mengirimkan perangkat keras, mempekerjakan orang, dan melakukan pekerjaan di lokasi pelanggan. Pelanggan perlu menyediakan akses ke kaset, ruang khusus untuk peralatan, koneksi jaringan, dan akses ke layanan Azure Storage. Mitra bertanggung jawab atas semua aktivitas lainnya.
- Migrasi yang dilakukan di situs mitra: pelanggan mengirimkan rekaman ke mitra, dan menyediakan akses ke layanan Azure Storage. Mitra migrasi pita melakukan semua pekerjaan untuk memigrasikan data dari kaset ke Azure Storage.
Opsi kedua lebih mudah, dan lebih umum digunakan. Mitra migrasi pita memiliki fasilitas yang dirancang, dan dilengkapi untuk melakukan migrasi pita dalam skala besar. Opsi ini juga mengurangi risiko, dan garis waktu karena mitra memiliki lebih banyak sumber daya perangkat keras yang tersedia. Melakukan migrasi di situs pelanggan hanya digunakan ketika masalah keamanan, dan privasi tidak memungkinkan pelanggan untuk mengirimkan kaset ke mitra.
Beberapa mitra dapat melakukan migrasi pita ke Azure. Daftar lengkap mitra dapat ditemukan pada impor media offline.
Berikut adalah diagram alur sederhana untuk memudahkan proses pemilihan.
Format data
Format data memiliki dampak besar pada desain migrasi, dan merupakan pertimbangan penting untuk kegunaan data di masa mendatang. Data dapat disimpan dalam format kepemilikan, atau asli. Format kepemilikan umumnya disimpan sebagai kaset virtual. Format asli memerlukan pemulihan file dari kaset, dan menyimpannya sebagai file, atau objek.
| Model | Pro | Kontra |
|---|---|---|
| Kaset virtual | - Migrasi yang lebih mudah, dan lebih cepat - Dapat membuat ulang media pita yang identik sebagai aslinya - Tidak perlu memiliki akses ke perangkat lunak asli untuk menulis data |
- Membutuhkan pemeliharaan inventarisasi pita virtual - Data yang disimpan dalam format dependen aplikasi, memerlukan perangkat lunak asli untuk memulihkan data - Data tidak dapat diakses oleh layanan Azure (AI / ML) tanpa pemulihan |
| File asli | - File yang dapat diakses oleh aplikasi apa pun, dan layanan (AI / ML) - Mungkin untuk memonetisasi data - Tidak perlu memiliki akses ke perangkat lunak asli untuk pemulihan |
- Migrasi yang lebih kompleks - Memerlukan akses ke perangkat lunak asli untuk menulis data |
Kriteria utama untuk memutuskan format adalah cara kami berencana untuk menggunakan data. Jika data dimigrasikan hanya untuk retensi jangka panjang, maka kaset virtual adalah pilihan yang bagus. Dalam kasus lain, menyimpan data dalam format asli adalah opsi pilihan. Ini memungkinkan penggunaan data sederhana di masa depan, dan membuka banyak kemungkinan dengan analisis data.
Proses migrasi
Setelah membuat keputusan tentang eksekusi migrasi, dan format data pilihan, kita dapat memulai dengan migrasi. Migrasi melewati beberapa fase.
Fase informasi
Fase informasi sangat penting untuk mengumpulkan persyaratan utama. Informasi yang dikumpulkan memandu desain yang benar, dan perencanaan. Meskipun beberapa informasi dapat diperbarui di tahap selanjutnya, memberikan informasi yang tepat mengatur adegan, dan menghindari kebutuhan untuk membuat perubahan besar pada proses. Beberapa pertanyaan utama yang perlu dijawab oleh fase ini adalah:
- Jenis kaset apa yang perlu dimigrasikan (misalnya, LTO3, LTO6, 3592JC, dll.)?
- Kuantitas kaset apa untuk setiap model yang perlu dimigrasikan (misalnya, 100xLTO3, 200xLTO6, dll.)?
- Perangkat lunak apa yang digunakan untuk menulis data pada kaset, apakah perangkat lunak tersebut masih tersedia?
- Apa format yang digunakan untuk menulis data pada kaset, apakah format terbuka, atau eksklusif, apakah kompresi diterapkan?
- Apakah enkripsi digunakan, dan jika ya, apa opsi yang paling aman untuk bertukar kunci enkripsi?
- Apa wilayah targetnya?
- Layanan penyimpanan apa yang digunakan?
- Persyaratan peraturan apa yang penting (HIPAA, GDPR, dll.)? Apakah rantai hak asuh wajib?
- Apa itu tenggat waktu migrasi? Apakah ada tonggak penting?
- Berapa banyak bandwidth jaringan yang tersedia untuk migrasi?
- Di mana kaset disimpan secara fisik, dan dapatkah mereka dikirim?
- Apakah Anda sudah memiliki nilai hash untuk semua file? Jika ya, algoritma hashing mana yang digunakan?
- Apakah pita diperlukan setelah migrasi?
- Bagaimana cara menjaga suhu, dan kelembaban untuk pita selama migrasi / transportasi?
- Siapa saja pemangku kepentingan utama?
Tahap persiapan
Setelah mengumpulkan informasi dasar, kami dapat mempersiapkan migrasi. Fase persiapan dapat mencakup banyak langkah berbeda, tetapi ada beberapa langkah umum yang dilalui sebagian besar migrasi:
Analisis data menyediakan informasi tentang data yang perlu dimigrasikan. Informasi sangat penting untuk memperkirakan seberapa cepat data dapat dibaca dari pita, dan berapa banyak paralelisme yang perlu kita capai untuk berhasil menyelesaikan migrasi sebelum tenggat waktu. Ini berdampak pada perkiraan pada perangkat keras yang diperlukan (pustaka, robot, drive). Analisis data dilakukan dengan mengambil sampel beberapa pita yang mewakili himpunan data yang akan dimigrasikan. Informasi umum yang kami cari adalah:
- ukuran file,
- jumlah data yang disimpan per pita,
- jumlah file per pita,
- ukuran file minimum, dan maksimum,
- jenis file.
Kualitas data membantu memperkirakan himpunan data final dan unik yang perlu dimigrasikan. Salah satu masalah paling umum dengan migrasi pita adalah duplikasi data. Migrasi pita adalah waktu yang ideal untuk membersihkan data duplikat. Proses ini meningkatkan kualitas data untuk penggunaan di masa mendatang, mengurangi biaya, dan durasi migrasi.
Prioritas data menentukan urutan di mana data dapat dimigrasikan. Idealnya, kita ingin mencapai streaming langsung dari setiap pita alih-alih membaca file secara acak dari kaset yang berbeda (untuk menghindari pemuatan, bongkar, dan pencarian yang konstan). Pendekatan ini mencapai throughput setinggi mungkin, dan selalu merupakan jalur migrasi tercepat. Prioritas data membutuhkan persyaratan bisnis, dan kelayakan teknis untuk mencapai hasil terbaik.
Desain migrasi mencakup semua aspek teknis migrasi, dan informasi yang dikumpulkan untuk membentuk proses migrasi akhir. Ini adalah dokumen tertulis yang menjadi sumber kebenaran untuk tahap yang tersisa. Ini harus berisi setidaknya:
- proses migrasi yang jelas, dan tenggat waktu migrasi,
- perangkat keras, dan persyaratan personel,
- infrastruktur, dan desain jaringan,
- pertimbangan keamanan,
- cara menangani kaset yang tidak dapat dibaca,
- peran, dan tanggung jawab, dll.
Fase migrasi
Setelah desain migrasi selesai, kami memulai proses migrasi. Sebelum meningkatkan kecepatan migrasi penuh, kami selalu melakukan pengujian dengan sampel yang lebih kecil. Tujuan pengujian adalah untuk memastikan bahwa proses end-to-end berfungsi. Ini memungkinkan kita untuk membuat tweak, dan meningkatkan prosesnya. Setelah pengujian berhasil, dan kami senang dengan hasilnya, kami menjalankan migrasi. Fase migrasi sedikit berbeda jika kita menggunakan file asli vs. kaset virtual. Dalam kedua kasus, ini adalah proses berulang yang melingkari semua kaset, dan membaca seluruh kontennya. Diagram alur ini menunjukkan fase migrasi saat bermigrasi ke file asli.
Validasi Data
Untuk setiap file yang kami migrasikan, kami perlu melakukan validasi data untuk memastikan bahwa data tidak rusak selama proses migrasi. Validasi data dilakukan dengan membandingkan nilai hash sebelum migrasi, dan setelah migrasi. Ada banyak jenis algoritma hashing yang dapat digunakan. Pendekatan umum adalah menggunakan MD5 karena Azure Storage berisi bidang metadata yang telah ditentukan sebelumnya Content-MD5 yang dapat diisi selama migrasi. Pendekatan ini memungkinkan pemeriksaan nilai MD5 yang sama ketika kita mengakses data untuk memvalidasi data tidak diubah, atau rusak. Dalam situasi ideal, data sumber sudah berisi nilai hash yang dapat dengan mudah dibandingkan dengan nilai hash pascamigrasi. Jika hash tidak ada, hash harus dihitung sebelum file dimigrasikan. Jika hash cocok, file ditandai sebagai dimigrasikan. Jika tidak, file dibuang, dan dimigrasikan lagi. Terkadang data rusak pada kaset sumber. Memiliki nilai hash asli membantu menangkap kasus langka tersebut. Jika itu terjadi, kita dapat membaca data dari salinan sekunder jika ada. Proses validasi data adalah komponen penting untuk desain migrasi. Proses untuk menangani validasi yang gagal harus ditentukan. Fase migrasi juga terus dipantau untuk memastikan kita dapat bereaksi terhadap situasi yang tidak dapat diprediksi, dan beradaptasi dengannya. Pelaporan rutin kepada pemangku kepentingan utama penting untuk menjaga migrasi tetap berjalan.
Fase pasca-migrasi
Setelah migrasi selesai, masih ada beberapa langkah yang perlu kita pertimbangkan, sebelum berhasil menutup proyek migrasi. Kita perlu membuang perangkat keras yang digunakan untuk migrasi, jika tidak diperlukan lagi. Pertanyaan terpenting adalah cara membuang kaset. Pembuangan pita adalah proses dua langkah. Jika kaset menyimpan informasi sensitif, dan rahasia (dan biasanya mereka lakukan), mereka harus dilewati terlebih dahulu. Degaussing memastikan bahwa semua data dihapus secara magnetik dari media. Setelah penghapusan, kaset harus dihancurkan dengan benar, dan didaur ulang. Jika kami menggunakan mitra migrasi pita, kami juga dapat membiarkan mitra membuang kaset dengan aman.
Langkah berikutnya
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk