Perencanaan kapasitas menggunakan Azure Site Recovery
Sebagai organisasi, sangat penting untuk mengadopsi strategi kelangsungan bisnis dan pemulihan bencana (BCDR) yang menjaga keamanan data, aplikasi, dan beban kerja Anda secara online selama pemadaman yang direncanakan dan tidak direncanakan.
Melalui replikasi beban kerja komputer virtual (VM) dari situs utama ke lokasi sekunder, Azure Site Recovery di Azure Stack Hub menyediakan layanan yang dapat mendukung keamanan data organisasi, ketersediaan aplikasi, dan beban kerja selama pemadaman. Misalnya, ketika pemadaman terjadi di situs utama, Anda gagal ke lokasi sekunder untuk mengakses aplikasi Anda. Segera setelah situs utama berjalan lagi, Anda dapat gagal kembali ke situs tersebut. Untuk informasi selengkapnya, lihat Tentang Site Recovery.
Untuk mengaktifkan replikasi VM di dua stempel Azure Stack Hub, Anda mengonfigurasi dua lingkungan:
- Lingkungan sumber :
- Stempel Azure Stack Hub tempat VM penyewa berjalan.
- Lingkungan target :
- Tempat Penyedia Sumber Daya Azure Site Recovery berjalan.
Komponen penting untuk keberhasilan kelangsungan bisnis dan rencana pemulihan bencana adalah perencanaan kapasitas. Selama perencanaan kapasitas, ada beberapa faktor yang perlu dipertimbangkan:
Tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) untuk beban kerja tertentu yang ingin Anda lindungi.
Beban kerja dan karakteristik aplikasi:
- Seberapa sering data berubah dalam VM masing-masing.
- Berapa banyak data yang dihasilkan atau dihapus?
- Bagaimana tampilan desain aplikasi dan banyak lagi?
Ukuran VM, jumlah disk, dan bagaimana setiap VM terikat dengan VM lain.
- Untuk solusi yang memerlukan beberapa VM, pahami dalam urutan apa VM tersebut perlu dimulai.
Bandwidth jaringan antara lingkungan sumber dan target. Komponen ini dapat memengaruhi RPO.
Masing-masing poin ini penting dan memiliki implikasi luas saat membangun rencana BCDR.
Bagian berikut mencantumkan poin utama yang perlu dipertimbangkan dari perspektif Azure Site Recovery. Setiap paket BCDR berbeda dan didasarkan pada spesifikasi beban kerja yang Anda rencanakan untuk dilindungi. Oleh karena itu, daftar ini tidak komprehensif.
Pertimbangan sumber
Di lingkungan sumber, Azure Stack Hub menjalankan appliance Azure Site Recovery VM. VM adalah VM Standard_DS4_v2 (8 vCPU, memori 28 Gb, 32 disk data) VM yang berjalan di langganan pengguna Azure Stack Hub.
Pada lingkungan sumber, pertimbangkan area berikut:
Kuota:
- Anda harus memiliki kuota yang memadai untuk membuat appliance Azure Site Recovery VM. Anda memerlukan satu atau beberapa, tergantung pada rencana keseluruhan.
Penyimpanan untuk appliance Azure Site Recovery VM:
Appliance Azure Site Recovery VM itu sendiri memiliki persyaratan data yang ditentukan oleh ukuran VM-nya.
Saat merencanakan kapasitas, pastikan VM appliance memiliki penyimpanan yang cukup untuk menjalankan mekanisme fail-back dan perlindungan ulang.
Catatan
Jika ada batasan penyimpanan, fail-back dan perlindungan ulang dapat gagal dengan kesalahan Pesan kesalahan internal terjadi . Pengguna harus memeriksa log peristiwa pada appliance untuk mengonfirmasi kesalahan Azure Resource Manager yang sebenarnya. Untuk informasi selengkapnya, lihat Masalah yang diketahui untuk Azure Site Recovery.
Bandwidth:
- Replikasi awal menghasilkan penggunaan bandwidth tinggi.
- Perubahan pada setiap VM direplikasi, tergantung pada kebijakan replikasi dan setiap jenis aplikasi.
Pertimbangan target
Di lingkungan target, ada dua bagian yang perlu dipertimbangkan untuk perencanaan kapasitas:
Persyaratan layanan Azure Site Recovery: berapa banyak yang digunakan untuk menjalankan Azure Site Recovery, tanpa harus melindungi beban kerja apa pun.
Persyaratan beban kerja yang dilindungi.
Lingkungan target mengharuskan satu azure Site Recovery vault dibuat untuk setiap appliance Site Recovery, untuk melindungi VM dari sumbernya (satu appliance per vault). Meskipun ini bukan batasan dari perspektif kapasitas, ini harus dipertimbangkan saat merencanakan desain lingkungan secara keseluruhan.
Sumber daya Azure Site Recovery RP
Penginstalan Azure Site Recovery di Azure Stack Hub mengharuskan Anda menginstal Site Recovery Resource Provider (RP).
Catatan
Dengan Microsoft.SiteRecovery-1.2301.2216.2287, Azure Site Recovery di Azure Stack Hub tidak memerlukan Azure Event Hubs sebagai dependensi.
Layanan ini dibuat pada langganan admin Azure Stack Hub dan dikelola oleh Azure Stack Hub itu sendiri, oleh karena itu tidak ada konfigurasi yang diperlukan. Namun, seperti halnya layanan apa pun, sumber daya ini menggunakan memori, penyimpanan, dan memiliki vCPU tertentu yang dialokasikan:
| Layanan | vCore | Memori | Ukuran Disk |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
Catatan
Sumber daya ini adalah layanan Azure Stack Hub di sisi administrasi Azure Stack Hub. Setelah diinstal, platform mengelola sumber daya ini.
Beban kerja yang dilindungi
Saat membuat paket BCDR, pertimbangkan semua aspek beban kerja yang dilindungi. Daftar berikut ini tidak lengkap dan harus diperlakukan sebagai titik awal:
Ukuran VM, jumlah disk, ukuran disk, IOPS, churn data, dan data baru yang dibuat.
Pertimbangan bandwidth jaringan:
- Bandwidth jaringan yang diperlukan untuk replikasi delta.
- Jumlah throughput, pada lingkungan target, yang bisa Site Recovery Azure dapatkan dari lingkungan sumber.
- Jumlah VM yang akan di-batch pada satu waktu. Jumlah ini didasarkan pada perkiraan bandwidth untuk menyelesaikan replikasi awal dalam jumlah waktu tertentu.
- RPO yang dapat dicapai untuk bandwidth tertentu.
- Efek pada RPO yang diinginkan jika bandwidth yang lebih rendah disediakan.
Pertimbangan penyimpanan:
- Berapa banyak data yang diperlukan untuk replikasi awal.
- Berapa banyak titik pemulihan yang ditahan dan bagaimana data meningkat, untuk setiap VM yang dilindungi, selama interval ini.
- Berapa banyak kuota yang perlu ditetapkan ke langganan pengguna Azure Stack Hub target, sehingga pengguna memiliki alokasi yang memadai.
- Akun penyimpanan cache untuk replikasi.
Pertimbangan komputasi:
- Saat failover terjadi, VM dimulai pada langganan pengguna Azure Stack Hub target. Alokasi kuota yang cukup harus diberlakukan untuk dapat memulai sumber daya VM ini.
- Selama perlindungan VM, ketika VM yang dilindungi aktif pada lingkungan sumber, tidak ada sumber daya terkait VM seperti vCPU, memori, dll. dikonsumsi pada lingkungan target. Sumber daya ini menjadi relevan hanya selama proses failover seperti uji failover.
Untuk cakupan Azure Site Recovery di Azure Stack Hub, berikut adalah titik awal untuk perhitungan, terutama untuk akun penyimpanan cache yang digunakan:
Jika ada failover, selama operasi normal, kalikan jumlah disk yang direplikasi dengan RPO rata-rata. Misalnya, Anda mungkin memiliki (2MB * 250s). Akun penyimpanan cache biasanya beberapa KB hingga 500 MB per disk.
Jika ada failover, mengingat skenario kasus terburuk, kalikan jumlah disk yang direplikasi dengan RPO rata-rata selama sehari penuh.
Penting
Jika beberapa bagian Azure Site Recovery tidak berfungsi, tetapi yang lain berfungsi, mungkin ada paling banyak satu hari difflog di akun penyimpanan sebelum Azure Site Recovery memutuskan untuk kehabisan waktu.
Failback ke VM baru. Hitung jumlah ukuran disk dari setiap batch.
- Seluruh disk harus disalin ke akun penyimpanan cache agar VM target diterapkan, karena targetnya adalah disk kosong.
- Data terkait dihapus setelah disalin, tetapi kemungkinan akan melihat penggunaan puncak dengan jumlah semua ukuran disk.
Buat paket BDCR berdasarkan spesifik solusi yang ingin Anda lindungi.
Tabel berikut adalah contoh pengujian yang dijalankan di lingkungan kita. Anda dapat menggunakan wawasan ini untuk mendapatkan garis besar untuk aplikasi Anda sendiri, tetapi setiap beban kerja berbeda:
Konfigurasi
| Ukuran blok | Throughput/disk |
|---|---|
| 2 MB | 2 MB/dtk |
| 64 KB | 2 MB/dtk |
| 8 KB | 1 MB/dtk |
| 8 KB | 2 MB/dtk |
Hasil
| Jumlah disk yang didukung | Throughput total | Total OPS | Penyempitan |
|---|---|---|---|
| 68 | 136 MB/dtk | 68 | penyimpanan |
| 60 | 120 MB/dtk | 2048 | penyimpanan |
| 28 | 28 MB/dtk | 3584 | CPU dan memori Azure Site Recovery |
| 16 | 32 MB/dtk | 4096 |
Catatan
8Kb adalah ukuran blok terkecil dari data yang didukung Azure Site Recovery. Setiap perubahan kurang dari 8Kb diperlakukan sebagai 8Kb.
Untuk menguji lebih lanjut, kami menghasilkan jenis beban kerja yang konsisten; misalnya, perubahan penyimpanan yang konsisten dalam blok 8 Kb yang totalnya hingga 1 MB/dtk per disk. Skenario ini tidak mungkin dalam beban kerja nyata, mengingat bahwa perubahan dapat terjadi pada berbagai waktu dalam sehari, atau dalam lonjakan berbagai ukuran.
Untuk mereplikasi pola acak ini, kami juga telah menguji skenario dengan:
- 120 VM (80 Windows, 40 Linux) dilindungi melalui appliance Azure Site Recovery VM yang sama.
Setiap VM yang dihasilkan pada interval acak, setidaknya dua kali per jam, blok acak berjumlah 5 Gb data di lima file.
Replikasi berhasil di semua 120 VM dengan beban rendah hingga menengah pada layanan Azure Site Recovery.
Catatan
Angka-angka ini harus digunakan sebagai garis besar saja. Mereka tidak selalu menskalakan secara linier. Menambahkan batch lain dari jumlah VM yang sama mungkin memiliki dampak yang lebih sedikit daripada yang awal. Hasilnya sangat tergantung pada jenis beban kerja yang digunakan.
Bagaimana Anda harus merencanakan dan menguji
Beban kerja aplikasi dan solusi memiliki persyaratan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) tertentu. Desain kelangsungan bisnis dan pemulihan bencana (BCDR) yang efektif memanfaatkan kemampuan tingkat platform yang memenuhi persyaratan ini, karena kami menggunakan mekanisme khusus solusi. Untuk merancang kemampuan BCDR, ambil persyaratan pemulihan bencana platform (DR) dan pertimbangkan semua faktor ini dalam desain Anda:
Persyaratan ketersediaan aplikasi dan data:
- Persyaratan RTO dan RPO untuk setiap beban kerja.
- Dukungan untuk pola ketersediaan aktif-aktif dan aktif-pasif.
Dukungan untuk penerapan multi-wilayah untuk failover, dengan kedekatan komponen untuk performa. Anda mungkin mengalami operasi aplikasi dengan fungsionalitas yang berkurang atau penurunan performa selama pemadaman.
Catatan
Aplikasi mungkin tahu secara asli untuk dijalankan, atau memiliki komponen tertentu yang dapat berjalan di beberapa lingkungan Azure Stack Hub. Dalam hal ini, Anda dapat menggunakan Azure Site Recovery untuk mereplikasi hanya VM dengan komponen yang tidak memiliki fungsionalitas ini; misalnya, solusi jenis front-end atau back-end, di mana Anda dapat menyebarkan front-end di seluruh lingkungan Azure Stack Hub.
Hindari menggunakan rentang alamat IP yang tumpang tindih dalam jaringan produksi dan DR.
- Jaringan produksi dan DR yang memiliki alamat IP yang tumpang tindih memerlukan proses failover yang dapat mempersulit dan menunda failover aplikasi. Jika memungkinkan, rencanakan arsitektur jaringan BCDR yang menyediakan konektivitas bersamaan ke semua situs.
Mengukur lingkungan target Anda:
- Jika Anda menggunakan sumber dan target dengan cara 1:1, alokasikan sedikit lebih banyak penyimpanan pada lingkungan target Anda. Hal ini disebabkan oleh cara riwayat marka buku disk terjadi. Alokasi ini bukan peningkatan 2x, karena hanya menyertakan perubahan pada data. Bergantung pada jenis data dan perubahan yang diharapkan, dan kebijakan replikasi yang memiliki penyimpanan 1,5x hingga 2x lebih banyak pada target memastikan bahwa proses failover tidak menimbulkan kekhawatiran.
- Anda mungkin mempertimbangkan untuk memiliki lingkungan Azure Stack Hub target sebagai target untuk beberapa sumber Azure Stack Hub. Dalam hal ini, Anda menurunkan biaya keseluruhan, tetapi harus merencanakan apa yang terjadi ketika beban kerja tertentu turun; misalnya, sumber mana yang harus diprioritaskan.
- Jika lingkungan target Anda digunakan untuk menjalankan beban kerja lain, rencana BCDR harus menyertakan perilaku beban kerja ini. Misalnya, Anda dapat menjalankan Dev/Test VM pada lingkungan target, dan jika masalah terjadi pada lingkungan sumber, Anda dapat menonaktifkan semua VM pada target untuk memastikan sumber daya yang memadai tersedia untuk memulai VM yang dilindungi.
Anda harus menguji BCDR dan memvalidasi secara teratur. Anda dapat melakukan ini dengan menggunakan proses failover pengujian, atau dengan memindahkan seluruh beban kerja untuk memvalidasi alur secara end-to-end.
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