Opsi dan pertimbangan HA/DR

Meskipun kemungkinan AWS Availability Zone atau Region benar-benar offline sangat jarang, kami merekomendasikan pendekatan multi-cabang untuk pencadangan dan pemulihan jika terjadi bencana karena redundansi dan untuk meminimalkan kehilangan data. Proses pencadangan dan pemulihan harus mencakup tingkat perincian yang sesuai untuk memenuhi tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) untuk beban kerja dan untuk mendukung proses bisnis, dan seringkali bergantung pada aplikasi. Dalam kasus database, AWS juga mendukung semua rekomendasi Microsoft untuk penyiapan dan konfigurasi SQL Server untuk ketersediaan tinggi dan pemulihan bencana (HA/DR). Different editions of SQL Server support various HA/DR options, and you should consider special cases such as very large databases (VLDBs) on a case-by-case basis. As with any DR configuration, testing is essential to ensure that each application meets its service-level agreements (SLAs) for HA/DR. For your test/developmentlingkungan, pertimbangkan untuk menggunakan edisi Pengembang SQL Server, yang gratis tetapi dilengkapi dengan batasan.

Untuk kasus penggunaan yang memerlukan RPO 15 menit dan RTO 4 jam, Anda dapat mempertimbangkan kombinasi opsi HA/DR berikut:

• Opsi HA/DR asli SQL Server dengan siaga hangat (tingkat basis data) - Untuk ilustrasi dari beberapa arsitektur ini, lihat bagian nanti dalam SQL Server pada diagram EC2 arsitektur Amazon panduan ini.

  • Dua node, Multi-AZ dalam satu Wilayah (mode komit sinkron) atau di beberapa Wilayah (mode komit asinkron, grup ketersediaan dasar)

  • Tiga node (atau lebih), Multi-AZ di beberapa Wilayah (mode komit sinkron dan komit asinkron)

  • Pengiriman dua node, Multi-AZ, dan log di beberapa Wilayah (dengan cadangan log setiap 5 menit)

• Pencadangan asli SQL Server ke Amazon S3 (tingkat basis data, hanya DR) - Cadangan penuh (satu kali sehari)

  • Pencadangan diferensial (setiap 2-4 jam).

  • Pencadangan log (setiap 5-10 menit).

  • Cadangan harus diambil dan disalin ke Amazon Simple Storage Service (Amazon S3) dengan menggunakan skrip khusus atau opsi seperti File Gateway untuk pencadangan dan transfer yang efisien.

  • Jika Anda memiliki ratusan database, Anda dapat terus menggunakan alat cadangan yang ada (seperti Commvault atau Litespeed) untuk mengelola cadangan secara efisien dan menyimpannya langsung di Amazon S3.

  • Gunakan Amazon S3 Cross-Region Replication (CRR) dengan S3 Replication Time Control (RTC) untuk mengontrol dan memantau replikasi objek dalam SLA 15 menit.

  • Untuk kepatuhan dan penghematan biaya, Anda juga dapat menggunakan manajemen Siklus Hidup S3 untuk memindahkan dan menyimpan cadangan lama untuk penyimpanan jangka panjang.

  • Jika Anda mengambil cadangan asli SQL Server dan memindahkannya ke Amazon S3 secara teratur, jika terjadi bencana, cadangan akan tersedia di Wilayah target. Ini menghilangkan kebutuhan untuk mentransfer cadangan atau memulihkan snapshot.

  • Sebaiknya gunakan SQL Native Backup Compression untuk mengurangi ukuran file.

• AWS snapshot (tingkat instance dan volume, hanya DR)

  • Amazon Elastic Compute Cloud (Amazon EC2) Amazon Machine Image (AMI) backup untuk membangun kembali database dari awal

  • Snapshot volume Amazon Elastic Block Store (Amazon EBS) untuk melampirkan volume EBS ke Amazon EC2

Mengelola sumber daya HA/DR di AWS Backup

AWS Backupadalah layanan yang dikelola sepenuhnya yang menawarkan kemampuan untuk membuat rencana dan jadwal cadangan, dan menetapkan AWS sumber daya yang terlibat dalam konfigurasi HA/DR — seperti volume Amazon EBS untuk membuat snapshot dan Amazon — ke paket cadangan ini. EC2 AMIs Anda juga dapat menggunakan AWS Backup untuk menjadwalkan salinan multi-wilayah dari snapshot EBS ini. Untuk penggunaan yang optimal, AWS Backup diperlukan mekanisme penandaan yang efisien agar sumber daya berada di tempat. AWS Backup juga mendukung backup yang konsisten aplikasi melalui Windows Volume Shadow Copy Service (VSS), yang dapat Anda gunakan untuk SQL Server. Untuk perlindungan tingkat penyimpanan, sebaiknya gunakan snapshot EBS. Snapshot EBS awal penuh, dan snapshot berikutnya bersifat inkremental. Meskipun snapshot EBS menawarkan perlindungan tingkat penyimpanan, mereka tidak menggantikan cadangan asli berbasis file SQL Server yang menawarkan pemulihan. point-in-time

Menggunakan AWS DMS untuk HA/DR

Jika Anda mencari alternatif untuk opsi SQL Server Always On untuk replikasi atau jika Anda memiliki database sumber dan target yang heterogen, baik dalam pengaturan hibrida atau di AWS, Anda dapat menggunakan AWS Database Migration Service (AWS DMS) dengan cara berikut.

Jika Anda menggunakan AWS DMS SQL Server dalam konteks yang dikelola sendiri (dihosting di Amazon EC2 atau di tempat), ini mendukung replikasi satu kali dan berkelanjutan dalam dua mode: dengan menggunakan MS-REPLICATION (untuk menangkap perubahan pada tabel yang memiliki kunci utama) dan MS-CDC (untuk menangkap perubahan pada tabel yang tidak memiliki kunci utama). Namun, jika Anda menggunakan Amazon Relational Database Service (Amazon RDS) sebagai sumber AWS DMS, hanya MS-CDC yang didukung. AWS DMS menawarkan berbagai titik akhir sumber dan target, mendukung mesin database heterogen, dan menawarkan kontrol halus atas proses replikasi. Anda juga dapat menggunakan AWS Schema Conversion Tool (AWS SCT) with AWS DMS untuk migrasi database heterogen. AWS SCT mengotomatiskan perubahan tingkat skema dan juga menghasilkan laporan untuk kesiapan dan perencanaan migrasi.

Anda menambahkan basis data sumber dan target sebagai titik akhir AWS DMS, seperti yang diilustrasikan dalam diagram berikut. Layanan ini mengimplementasikan proses replikasi logis dengan menggunakan MS-REPLICATION atau MS-CDC. Jika Anda memiliki pengaturan hybrid, Anda dapat mengonfigurasi replikasi yang AWS DMS sedang berlangsung antara di tempat dan AWS. Selama cutover, tugas AWS DMS migrasi dapat dihentikan dan aplikasi akan dapat terhubung ke database yang sudah disinkronkan dengan database lokal tanpa penundaan lebih lanjut. Menggunakan AWS DMS SQL Server sebagai sumber memiliki beberapa keterbatasan, yang diuraikan dalam dokumentasi.AWS DMS

Pertimbangkan untuk menggunakan AWS DMS alih-alih metode HA/DR asli dalam skenario berikut:

• Ketika Anda ingin menghemat biaya lisensi. Misalnya, jika Anda menggunakan versi lanjutan seperti edisi SQL Server Enterprise hanya untuk opsi Always On, Anda dapat mempertimbangkan untuk menyiapkan AWS DMS sebagai gantinya, karena dapat memberikan opsi replikasi logis tanpa biaya lisensi edisi Enterprise.

• Ketika Anda memiliki sumber dan target yang heterogen. Versi SQL Server pada node pemulihan primer dan bencana tidak perlu cocok (dalam AWS DMS batasan), yang memberikan fleksibilitas yang signifikan.

• Untuk menghindari overhead Windows, pengelompokan SQL Server, dan pengaturan dan manajemen grup ketersediaan terdistribusi. AWS DMS menawarkan pengaturan langsung dan manajemen tugas replikasi yang mudah.

• Untuk kasus penggunaan bisnis seperti transfer mendekati waktu nyata (tergantung pada contoh replikasi, konfigurasi jaringan, dan volume data), penyembunyian data, penyaringan selektif, pemetaan skema/tabel (homogen dan heterogen), penilaian pra-migrasi, dan dukungan JSON.

• Untuk dengan mudah menduplikasi, menghentikan, dan memulai tugas sesuai kebutuhan berdasarkan nomor urutan log (LSNs), stempel waktu, dan opsi serupa.

Diagram berikut menunjukkan pendekatan alternatif untuk bagaimana AWS DMS dapat memberikan dukungan replikasi. Dalam konfigurasi ini, sumbernya adalah cluster grup ketersediaan SQL Server Always On, dan AWS DMS menggunakan opsi change data capture (CDC) untuk terus mereplikasi data ke target di Wilayah yang berbeda. AWS Untuk kinerja yang paling optimal, sangat penting untuk memastikan bahwa instance replikasi berukuran tepat dan tetap berada di Wilayah sumber.

Mesin sumber dan target tidak harus cocok. Dalam diagram, node primer dan sekunder ditandai sebagai (1) dapat berupa cluster SQL Server dalam konfigurasi Single-AZ atau Multi-AZ. Atau sumbernya bisa berupa node SQL Server tunggal yang mendukung MS-CDC atau MS-REPLICATION.

Instans DB target, ditandai sebagai (2) dalam diagram, dapat berupa versi SQL Server apa pun di Amazon RDS EC2, Amazon, atau target heterogen lainnya. Itu tidak harus cocok dengan instance primer dan sekunder atau mendukung grup ketersediaan Selalu Aktif. Misalnya, sumbernya bisa berupa klaster grup ketersediaan SQL Server Always On, dan targetnya bisa berupa Amazon Aurora PostgreSQL Edisi yang kompatibel.

Menggunakan AWS Application Migration Service untuk DR

Kami merekomendasikan menggunakan AWS Application Migration Service for lift-and-shift migrasi ke AWS. Layanan Migrasi Aplikasi terus mereplikasi mesin Anda (termasuk sistem operasi, konfigurasi status sistem, database, aplikasi, dan file) ke area pementasan berbiaya rendah di AWS akun target Anda dan Wilayah pilihan Anda. Jika terjadi bencana, Anda dapat menggunakan Layanan Migrasi Aplikasi untuk secara otomatis meluncurkan ribuan mesin Anda dalam keadaan yang disediakan sepenuhnya dalam hitungan menit.

Pertimbangan tambahan

Daftar berikut mengidentifikasi kemungkinan kemacetan yang harus Anda pertimbangkan ketika Anda merancang strategi HA/DR.

• Bandwidth, latensi, kompleksitas jaringan, dan konektivitas dalam pengaturan node Multi-region.

• Ukuran EC2 snapshot Amazon EBS atau Amazon, dan waktu yang diperlukan untuk menyalinnya dengan menggunakan. AWS Backup

  • EC2 Snapshot Amazon EBS dan Amazon disimpan di Amazon S3 dengan menggunakan. AWS Backup

  • Snapshot EBS tidak mereplikasi ke Wilayah target di Amazon S3 hingga snapshot saat ini selesai. Durasi replikasi juga tergantung pada ukuran volume.

  • Ketika snapshot selesai, durasi waktu untuk menyalin snapshot bisa sesedikit 15 menit untuk 99,99% objek. Namun, pengujian menyeluruh diperlukan untuk kasus penggunaan tertentu dan volume besar yang kritis.

• Waktu yang diperlukan untuk memulihkan volume EBS di Zona dan Wilayah Ketersediaan target.

• Waktu yang diperlukan untuk memulihkan EC2 gambar Amazon di Zona dan Wilayah Ketersediaan target.

• Jika membangun dari awal, waktu yang diperlukan untuk menyediakan infrastruktur untuk EC2 gambar Amazon atau snapshot EBS yang dipulihkan di Zona dan Wilayah Ketersediaan target.

• Jika memulihkan dari awal, waktu yang diperlukan untuk memulihkan SQL Server native full, differential, dan log backup di Availability Zone target dan Region.

• Aplikasi dan dependensi eksternal yang perlu tersedia di seluruh Wilayah.

• Batasan ukuran file untuk volume dan untuk mengunggah ke Amazon S3.