Keandalan di Azure Storage Mover

Artikel ini menjelaskan dukungan keandalan di Azure Storage Mover dan mencakup ketahanan intra-regional dengan zona ketersediaan dan pemulihan bencana lintas wilayah dan kelangsungan bisnis. Untuk gambaran umum yang lebih rinci tentang prinsip keandalan di Azure, lihat Keandalan Azure.

Dukungan zona ketersediaan

Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.

Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.

Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.

Azure Storage Mover mendukung model penyebaran zona-redundan.

Saat menyebarkan sumber daya Azure Storage Mover, Anda harus memilih wilayah tertentu tempat metadata instans sumber daya disimpan.

Jika wilayah mendukung zona ketersediaan, metadata instans secara otomatis direplikasi di beberapa zona ketersediaan dalam wilayah tersebut.

Penting

Metadata instans Azure Storage Mover mencakup proyek, titik akhir, agen, definisi pekerjaan, dan riwayat eksekusi pekerjaan, tetapi tidak menyertakan data aktual yang akan dimigrasikan. Akun penyimpanan Azure yang digunakan sebagai target migrasi memiliki dukungan keandalannya sendiri.

Prasyarat

• Untuk menyebarkan dengan dukungan zona ketersediaan, Anda harus memilih wilayah yang mendukung zona ketersediaan. Untuk melihat wilayah mana yang mendukung zona ketersediaan, lihat daftar wilayah yang didukung.

• (Opsional) Jika akun penyimpanan target Anda tidak mendukung zona ketersediaan, dan Anda ingin memigrasikan akun ke dukungan AZ, lihat Memigrasikan akun Azure Storage ke dukungan zona ketersediaan.

Pengalaman zona tidak berfungsi

Selama pemadaman di seluruh zona, tidak ada tindakan yang diperlukan selama pemulihan zona. Azure Storage Mover dirancang untuk menyembuhkan diri sendiri dan menyeimbangkan kembali dirinya sendiri untuk memanfaatkan zona sehat secara otomatis.

Setiap akun penyimpanan target migrasi mungkin memerlukan langkah-langkah pemulihannya sendiri. Persyaratan ini tergantung pada opsi redundansi yang dipilih untuk setiap akun penyimpanan. Lihat panduan pemulihan bencana akun penyimpanan untuk menentukan apakah langkah-langkah lebih lanjut diperlukan.

Jika penyimpanan lokal dipilih sebagai pengganti opsi redundansi, Anda mungkin perlu membuat akun penyimpanan baru untuk digunakan dalam migrasi selama pemadaman.

Pemulihan bencana lintas wilayah dan kelangsungan bisnis

Pemulihan bencana (DR) adalah tentang pemulihan dari peristiwa berdampak tinggi, seperti bencana alam atau penyebaran gagal yang mengakibatkan waktu henti dan kehilangan data. Terlepas dari penyebabnya, obat terbaik untuk bencana adalah rencana DR yang terdefinisi dan teruji dengan baik dan desain aplikasi yang secara aktif mendukung DR. Sebelum Anda mulai berpikir tentang membuat rencana pemulihan bencana Anda, lihat Rekomendasi untuk merancang strategi pemulihan bencana.

Ketika datang ke DR, Microsoft menggunakan model tanggung jawab bersama. Dalam model tanggung jawab bersama, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Pada saat yang sama, banyak layanan Azure tidak secara otomatis mereplikasi data atau mundur dari wilayah yang gagal untuk mereplikasi silang ke wilayah lain yang diaktifkan. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan pada penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR dan Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat untuk membantu mengembangkan rencana DR Anda.

Saat agen Storage Mover terdaftar, agen tersebut terhubung ke wilayah tempat sumber daya Storage Mover terdaftar. Jika wilayah Azure agen mengalami pemadaman, agen itu sendiri tidak terpengaruh, tetapi operasi manajemen yang mengandalkan Azure mungkin tidak dapat diselesaikan. Selain itu, setiap migrasi data aktif ke akun penyimpanan yang terletak di wilayah yang terpengaruh mungkin gagal.

Storage Mover mendukung dua bentuk pemulihan bencana:

• Pemulihan bencana yang dimulai Azure
• Pemulihan bencana yang dimulai pelanggan

Penting

Pemulihan bencana untuk sumber data lokal adalah tanggung jawab pelanggan.

Pemulihan bencana yang dimulai Azure

Pemulihan bencana yang dimulai Azure hanya berlaku untuk wilayah yang memiliki pasangan wilayah. Ketika replikasi lintas wilayah digunakan, metadata instans direplikasi ke setiap wilayah, tetapi tidak pernah diizinkan untuk meninggalkan geografi.

Azure Storage Mover menggunakan Cosmos DB untuk menyimpan metadata instans. Kehilangan data hanya dapat terjadi dengan bencana yang tidak dapat dipulihkan di Azure Cosmos DB . Untuk informasi selengkapnya, lihat Pemadaman wilayah. Pemulihan yang dimulai Azure bersifat pasif aktif, dan pemulihan penuh suatu wilayah mungkin hingga 24 jam.

Pemulihan bencana yang dimulai pelanggan

Pemulihan bencana yang dimulai pelanggan tidak dibatasi untuk wilayah yang dipasangkan.

Sebelum pemadaman regional terjadi:

• Sebarkan Storage Mover zona-redundan dengan membuat sumber daya Storage Mover di wilayah yang mendukung zona ketersediaan.

• Secara berkala - baik pada jadwal atau setelah Anda membuat perubahan substansial - ambil rekam jepret sumber daya Storage Mover Anda. Menyimpan rekam jepret menggunakan sistem kontrol versi adalah cara yang baik untuk menyimpan dan melacak riwayat rekam jepret. Anda akan menggunakan rekam jepret terakhir yang baik jika terjadi bencana di mana Anda perlu memulihkan sumber daya Anda di wilayah baru.

Selama pemadaman regional:

Anda dapat melakukan salah satu dari dua hal berikut:

• Pilih untuk menunggu Azure memulihkan wilayah.
• Minimalkan waktu henti dengan menyebarkan ulang sumber daya Anda ke wilayah yang berbeda. Karena akses ke sumber daya Anda mungkin terpengaruh selama pemadaman, Anda harus menggunakan rekam jepret terakhir yang baik dari sumber daya Anda.

Tip

Salah satu strategi ini mungkin masih mengharuskan Anda untuk mengambil langkah-langkah lebih lanjut sebelum bencana, jadi pastikan untuk meninjau dan merencanakan yang sesuai.

Menyebarkan sumber daya ke wilayah lain

Lihat dokumentasi tentang mengekspor templat untuk instruksi lebih lanjut tentang mengekspor sumber daya sebagai templat Azure Resource Manager (ARM).

Jika Storage Mover dan sumber daya terkait Berada di kontainer tanpa sumber daya tambahan, Anda harus melakukan ekspor Grup Sumber Daya untuk menangkap status saat ini. Namun, jika grup sumber daya Anda berisi sumber daya yang tidak terkait, Anda mungkin perlu menghapus atau mengecualikan sumber daya dari templat.

Agen yang ada tidak dapat disebarkan ulang ke wilayah yang berbeda. Jika wilayah tempat mereka awalnya dikonfigurasi mengalami pemadaman, mungkin tidak mungkin untuk sepenuhnya membatalkan pendaftaran dan mendaftarkan ulang agen. Dokumen ini mengasumsikan bahwa agen baru terdaftar dalam wilayah baru.

Untuk menggunakan templat yang diekspor untuk pemulihan bencana, diperlukan beberapa perubahan pada templat.

• Pertama, hapus sumber daya dan Microsoft.HybridCompute/machines apa pun Microsoft.StorageMover/agents dari templat. Pastikan untuk menghapus referensi dependensi apa pun ke sumber daya ini juga.
• Selanjutnya, hapus agentResourceId properti dari semua definisi pekerjaan. Anda harus menetapkannya ke Agen baru setelah penyebaran.
• Setelah menghapus semua referensi ke agen dan sumber daya komputer Hybrid Compute, perbarui properti lokasi sumber daya Storage Mover tingkat atas. Ganti nama wilayah yang saat ini disebarkan dengan nama wilayah baru.
• Terakhir, tentukan apakah akan menyimpan ID sumber daya akun penyimpanan yang ada. Jika perlu, ganti dengan akun penyimpanan yang berbeda.

Setelah menyelesaikan langkah-langkah sebelumnya dan memverifikasi bahwa parameter templat sudah benar, templat siap untuk penyebaran ke wilayah baru. Anda harus menyebarkan templat ke grup sumber daya baru yang memiliki wilayah default yang sama dengan properti lokasi dalam templat.

Mendaftarkan agen baru

Ikuti langkah-langkah dalam artikel menyebarkan agen Azure Storage Mover untuk mendaftarkan agen baru di sumber daya Storage Mover baru.

Menetapkan agen ke definisi pekerjaan

Setelah agen baru terdaftar dan melaporkan sebagai online, gunakan portal Azure atau PowerShell untuk mengaitkan definisi pekerjaan yang ada ke agen baru. Contoh PowerShell berikut disediakan untuk kenyamanan.

Lihat menentukan pekerjaan migrasi baru untuk panduan tentang cara mengakses definisi pekerjaan untuk proyek Anda.

## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

Memberikan akses agen ke kontainer penyimpanan target

Anda perlu menetapkan peran kontributor data ke identitas terkelola agar berhasil melakukan pekerjaan migrasi. Tetapkan akses identitas terkelola sistem sumber daya Hybrid Compute ke sumber daya akun penyimpanan target. Artikel menetapkan akses identitas terkelola ke sumber daya memberikan panduan tentang cara memberikan akses ke sumber daya target.

Anda sekarang siap untuk memulai pekerjaan migrasi menggunakan sumber daya Storage Mover yang baru disebarkan.

Langkah berikutnya

• Keandalan di Azure
• Pemulihan bencana akun penyimpanan