Bagikan melalui

Melindungi VM yang disebarkan di Azure Stack Hub

  • Artikel

Gunakan artikel ini sebagai panduan untuk membantu Anda mengembangkan perlindungan data dan strategi pemulihan bencana untuk mesin virtual (VM) IaaS yang disebarkan pengguna di Azure Stack Hub.

Untuk melindungi terhadap kehilangan data dan waktu henti yang diperpanjang, terapkan rencana pemulihan cadangan atau pemulihan bencana untuk aplikasi pengguna beserta data mereka. Setiap aplikasi harus dievaluasi sebagai bagian dari strategi kelangsungan bisnis dan pemulihan bencana (BC/DR) organisasi Anda yang komprehensif.

Pertimbangan untuk melindungi VM infrastruktur sebagai layanan

Peran dan tanggung jawab

Pertama, pastikan terdapat pemahaman yang jelas mengenai peran dan tanggung jawab yang dikaitkan dengan pemilik aplikasi dan operator dalam konteks perlindungan dan pemulihan.

Pengguna bertanggung jawab untuk melindungi VM. Operator bertanggung jawab untuk menjaga Azure Stack Hub tetap online dan sehat. Azure Stack Hub mencakup layanan yang mencadangkan data layanan internal dari layanan infrastruktur dan tidak menyertakan data pengguna apa pun termasuk VM buatan pengguna, akun penyimpanan dengan data pengguna atau aplikasi, atau database pengguna.

Pemilik aplikasi/arsitek Operator Azure Stack Hub
- Menyelaraskan arsitektur aplikasi dengan prinsip desain cloud.
- Memodernisasi aplikasi tradisional sesuai kebutuhan, untuk mempersiapkannya untuk lingkungan cloud.
- Tentukan RTO dan RPO yang dapat diterima untuk aplikasi.
- Identifikasi sumber daya aplikasi dan repositori data yang perlu dilindungi.
- Terapkan metode pemulihan data dan aplikasi yang paling selaras dengan arsitektur aplikasi dan persyaratan pelanggan.		 - Identifikasi kelangsungan bisnis organisasi dan tujuan pemulihan bencana.
- Sebarkan instans Azure Stack Hub yang cukup untuk memenuhi tujuan BC/DR organisasi.
- Merancang dan mengoperasikan infrastruktur perlindungan aplikasi/data.
- Menyediakan solusi terkelola atau akses layanan mandiri ke layanan perlindungan.
- Bekerja dengan pemilik/arsitek aplikasi untuk memahami desain aplikasi dan merekomendasikan strategi perlindungan.
- Aktifkan pencadangan infrastruktur untuk penyembuhan layanan dan pemulihan cloud.

Kombinasi sumber/target

Pengguna yang perlu melindungi terhadap pemadaman pusat data atau situs dapat menggunakan Azure Stack Hub atau Azure lainnya untuk menyediakan ketersediaan tinggi atau pemulihan cepat. Dengan lokasi primer dan sekunder, pengguna dapat menyebarkan aplikasi dalam konfigurasi aktif/aktif atau aktif/pasif di dua lingkungan. Untuk beban kerja yang kurang penting, pengguna dapat menggunakan kapasitas di lokasi sekunder untuk melakukan pemulihan aplikasi sesuai permintaan dari pencadangan.

Satu atau lebih cloud Azure Stack Hub dapat disebarkan ke pusat data. Untuk bertahan dari bencana besar, menyebarkan setidaknya satu cloud Azure Stack Hub di pusat data yang berbeda memastikan bahwa Anda dapat melakukan fail over beban kerja dan meminimalkan waktu henti yang tidak direncanakan. Apabila Anda hanya memiliki satu Azure Stack Hub, sebaiknya pertimbangkan untuk menggunakan cloud publik Azure sebagai cloud pemulihan Anda. Penentuan di mana aplikasi Anda dapat berjalan akan ditentukan oleh peraturan pemerintah, kebijakan perusahaan, dan persyaratan latensi yang ketat. Anda memiliki fleksibilitas untuk menentukan lokasi pemulihan yang sesuai per aplikasi. Misalnya, Anda dapat memiliki aplikasi dalam satu langganan yang mencadangkan data ke pusat data lain dan di langganan lain, mereplikasi data ke cloud publik Azure.

Tujuan pemulihan aplikasi

Pemilik aplikasi utamanya bertanggung jawab untuk menentukan jumlah waktu henti dan kehilangan data yang dapat ditoleransi oleh aplikasi dan organisasi. Dengan mengukur waktu henti yang dapat diterima dan kehilangan data yang dapat diterima, Anda dapat membuat rencana pemulihan yang meminimalkan dampak bencana pada organisasi Anda. Untuk setiap aplikasi, pertimbangkan hal-hal berikut:

  • Tujuan waktu pemulihan (RTO)
    RTO adalah waktu maksimum yang dapat diterima bahwa aplikasi dapat menjadi tidak tersedia setelah insiden. Misalnya, RTO 90 menit berarti Anda harus dapat memulihkan aplikasi ke status berjalan dalam waktu 90 menit sejak awal bencana. Jika Anda memiliki RTO rendah, Anda dapat menjaga penyebaran kedua terus berjalan saat siaga untuk melindungi terhadap pemadaman regional.
  • Tujuan titik pemulihan (RPO)
    RPO adalah durasi maksimum kehilangan data yang dapat diterima selama bencana. Misalnya, jika Anda menyimpan data dalam database tunggal, yang dicadangkan per jam dan tidak memiliki replikasi ke database lain, Anda dapat kehilangan hingga satu jam data.

Metrik lainnya adalah Mean Time to Recover (MTTR), yang merupakan waktu rata-rata yang diperlukan untuk memulihkan aplikasi setelah kegagalan. MTTR adalah nilai empiris untuk suatu sistem. Jika MTTR melebihi RTO, maka kegagalan dalam sistem menyebabkan gangguan bisnis yang tidak dapat diterima karena tidak akan mungkin untuk memulihkan sistem dalam RTO yang ditentukan.

Opsi perlindungan

Backup-restore

Mencadangkan aplikasi dan himpunan data memungkinkan Anda untuk memulihkan dengan cepat dari waktu henti akibat kerusakan data, penghapusan yang tidak disengaja, atau bencana. Untuk aplikasi berbasis VM IaaS, Anda dapat menggunakan agen in-guest untuk melindungi data aplikasi, konfigurasi sistem operasi, dan data yang disimpan pada volume.

Pencadangan menggunakan agen in-guest

Mencadangkan VM menggunakan agen OS tamu umumnya mencakup pengambilan konfigurasi sistem operasi, file/folder, disk, biner aplikasi, atau data aplikasi.

Memulihkan aplikasi dari agen memerlukan pembuatan ulang VM secara manual, penginstalan sistem operasi, dan penginstalan agen tamu. Pada titik tersebut, data dapat dipulihkan ke OS tamu atau langsung ke aplikasi.

Pencadangan menggunakan snapshot disk untuk VM yang dihentikan

Produk cadangan dapat melindungi konfigurasi VM IaaS dan disk yang terlampir ke VM yang dihentikan. Gunakan produk cadangan yang berintegrasi dengan Azure Stack Hub API untuk mengambil konfigurasi VM dan membuat snapshot disk. Jika waktu henti yang direncanakan untuk aplikasi memungkinkan, maka pastikan VM berada dalam kondisi dihentikan sebelum memulai alur kerja cadangan.

Pencadangan menggunakan snapshot disk untuk menjalankan VM

Penting

Menggunakan rekam jepret disk dari portal saat ini tidak didukung untuk VM dalam keadaan berjalan. Membuat snapshot dari disk yang dilampirkan ke VM yang sedang berjalan dapat menurunkan kinerja atau memengaruhi ketersediaan sistem operasi atau aplikasi di VM. Rekomendasinya adalah menggunakan solusi vendor cadangan yang terintegrasi dengan kemampuan rekam jepret inkremental Storage RP, atau agen dalam tamu untuk melindungi aplikasi jika waktu henti yang direncanakan bukanlah pilihan.

VM dalam set skala atau set ketersediaan

VM dalam set skala atau grup ketersediaan yang dianggap sebagai sumber daya sementara tidak boleh dicadangkan di tingkat VM, terutama jika aplikasi tersebut tanpa status. Untuk aplikasi berstatus yang disebarkan dalam set skala atau set ketersediaan, pertimbangkan untuk melindungi data aplikasi (misalnya, database atau volume dalam kumpulan penyimpanan).

Replikasi/failover manual

Untuk aplikasi yang memerlukan kehilangan data minimal atau waktu henti minimal, replikasi data dapat diaktifkan di OS tamu atau tingkat aplikasi untuk mereplikasi data ke lokasi lain. Beberapa aplikasi, seperti Microsoft SQL Server, secara native mendukung replikasi. Apabila aplikasi tidak mendukung replikasi, Anda dapat menggunakan perangkat lunak di OS tamu untuk mereplikasi disk, atau solusi mitra yang diinstal sebagai agen di OS tamu.

Dengan pendekatan ini, aplikasi ini disebarkan dalam satu cloud dan data direplikasi ke cloud lokal lainnya atau ke Azure. Ketika failover dipicu, aplikasi dalam target perlu dimulai dan dilampirkan ke data yang direplikasi sebelum dapat mulai melayani permintaan.

Ketersediaan tinggi/failover otomatis

Untuk aplikasi tanpa status yang hanya dapat mentoleransi waktu henti selama beberapa detik atau menit, pertimbangkan konfigurasi ketersediaan tinggi. Aplikasi dengan ketersediaan tinggi dirancang untuk disebarkan di beberapa lokasi dalam topologi aktif/aktif di mana semua instans dapat melayani permintaan. Untuk kesalahan perangkat keras lokal, infrastruktur Azure Stack Hub menerapkan ketersediaan tinggi di jaringan fisik menggunakan dua sakelar rak teratas. Untuk kesalahan tingkat komputasi, Azure Stack Hub menggunakan beberapa node dalam unit skala dan secara otomatis akan melakukan failover VM. Pada tingkat VM, Anda dapat menggunakan set skala atau VM dalam set ketersediaan untuk memastikan kegagalan node tidak menonaktifkan aplikasi Anda. Aplikasi yang sama perlu disebarkan ke lokasi sekunder dalam konfigurasi yang sama. Untuk membuat aplikasi menjadi aktif/aktif, penyeimbang muatan atau DNS dapat digunakan untuk mengarahkan permintaan ke semua instans yang tersedia.

Tidak ada pemulihan

Beberapa aplikasi di lingkungan Anda mungkin tidak memerlukan perlindungan terhadap waktu henti yang tidak direncanakan atau kehilangan data. Misalnya, VM yang digunakan untuk pengembangan dan pengujian umumnya tidak perlu dipulihkan. Ini adalah keputusan Anda untuk melakukannya tanpa perlindungan untuk aplikasi atau himpunan data.

Pertimbangan penting untuk penyebaran Azure Stack Hub Anda:

Rekomendasi Komentar
Mencadangkan/memulihkan VM ke target cadangan eksternal yang sudah disebarkan di pusat data Anda Disarankan Manfaatkan infrastruktur cadangan dan keterampilan operasional yang ada. Pastikan untuk mengukur infrastruktur cadangan sehingga siap untuk melindungi instans VM tambahan. Pastikan infrastruktur cadangan tidak berada dekat dengan sumber Anda. Anda dapat memulihkan VM ke sumber Azure Stack Hub, ke instans Azure Stack Hub sekunder, atau Azure.
Mencadangkan/memulihkan VM ke target cadangan eksternal yang didedikasikan untuk Azure Stack Hub Disarankan Anda dapat membeli infrastruktur cadangan baru atau memprovisikan infrastruktur cadangan khusus untuk Azure Stack Hub. Pastikan infrastruktur cadangan tidak berada dekat dengan sumber Anda. Anda dapat memulihkan VM ke sumber Azure Stack Hub, ke instans Azure Stack Hub sekunder, atau Azure.
Mencadangkan/memulihkan VM langsung ke Azure global atau penyedia layanan tepercaya Disarankan Selama Anda dapat memenuhi persyaratan privasi dan peraturan data, Anda dapat menyimpan cadangan di Azure global atau penyedia layanan tepercaya. Idealnya penyedia layanan juga menjalankan Azure Stack Hub sehingga Anda mendapatkan konsistensi dalam pengalaman operasional saat memulihkan.
Replikasi/failover VM ke instans Azure Stack Hub terpisah Disarankan Dalam kasus failover, Anda harus memiliki cloud Azure Stack Hub kedua yang beroperasi penuh sehingga Anda dapat menghindari waktu henti aplikasi yang diperpanjang.
Replikasi/failover VM langsung ke Azure atau penyedia layanan tepercaya Disarankan Selama Anda dapat memenuhi persyaratan privasi dan peraturan data, Anda dapat mereplikasi data ke Azure global atau penyedia layanan tepercaya. Idealnya penyedia layanan juga menjalankan Azure Stack Hub sehingga Anda mendapatkan konsistensi dalam pengalaman operasional setelah failover.
Sebarkan target cadangan pada Azure Stack Hub yang sama yang juga menghosting semua aplikasi yang dilindungi oleh target cadangan yang sama. Target yang berdiri sendiri: Tidak disarankan
Target yang mereplikasi data cadangan secara eksternal: Direkomendasikan		 Jika Anda memilih untuk menyebarkan appliance cadangan di Azure Stack Hub (untuk tujuan mengoptimalkan pemulihan operasional), Anda harus memastikan semua data terus disalin ke lokasi cadangan eksternal.
Menyebarkan appliance cadangan fisik ke rak yang sama tempat solusi Azure Stack Hub diinstal Tidak didukung Saat ini, Anda tidak dapat menyambungkan perangkat lainnya ke bagian atas sakelar rak yang bukan bagian dari solusi asli.

Pertimbangan untuk VM IaaS yang dipulihkan

Anda perlu membuat beberapa perubahan pada VM setelah memulihkan mesin dari cadangan. Hal ini termasuk:

  • Alamat MAC
    Adaptor jaringan virtual akan mendapatkan alamat MAC baru. Tidak ada metode untuk mempertahankan alamat MAC asli.
  • Alamat IP
    Jika VM Anda memiliki IP statis yang diatur secara internal, IP internal pada adaptor jaringan virtual dapat diatur agar sesuai dengan aslinya. Anda mungkin perlu mempertimbangkan apakah VNET memiliki VPN S2S ke lingkungan eksternal tempat alamat IP mungkin digunakan.
  • Artefak yang tidak dibutuhkan
    Apabila VM dicadangkan pada platform yang berbeda, seperti vSphere VMware, Anda harus mengikuti beberapa langkah tambahan untuk membersihkan artefak yang tidak dibutuhkan dari sumber.

Langkah berikutnya

Artikel ini menyediakan panduan umum untuk melindungi VM pengguna yang disebarkan di Azure Stack Hub. Untuk informasi tentang menggunakan layanan Azure untuk melindungi VM pengguna, lihat: