Skenario pemulihan bencana

Bagian ini memberikan contoh kegagalan Availability Zone atau AWS Region tunggal, dan membahas opsi untuk pemulihan bencana (DR). Contoh mengasumsikan tujuan titik pemulihan (RPO) 15 menit dan tujuan waktu pemulihan (RTO) 4 jam.

Kegagalan Zona Ketersediaan

Anda dapat menggunakan salah satu opsi berikut untuk memulihkan dari kegagalan Availability Zone tunggal dalam parameter yang diberikan (RPO 15 menit, RTO 4 jam).

• Menyediakan pemulihan aplikasi dengan menggunakan cadangan gambar Amazon Elastic Compute Cloud (Amazon EC2) terbaru, dan sambungkan ke instance database siaga hangat yang ada melalui penyebaran grup ketersediaan Selalu Aktif atau pengiriman log.

  • Pengaturan grup ketersediaan SQL Server Always On untuk DR dengan dua atau lebih node menyediakan failover otomatis ke node sekunder melalui mode synchronous-commit atau asynchronous-commit, sehingga database segera tersedia. Untuk pengaturan HA, kedua node tersedia untuk operasi baca. Opsi ini memenuhi persyaratan RTO dan RPO dengan nyaman. Dalam edisi Standar SQL Server, menggunakan grup ketersediaan dasar juga merupakan pilihan, tetapi terbatas pada dua node, karena grup ketersediaan hanya dapat menyertakan satu database. Namun, Anda dapat mengatur beberapa grup ketersediaan dalam satu Wilayah atau di seluruh Wilayah. Pengaturan ini memberikan penghematan biaya, karena tidak ada biaya tambahan untuk node sekunder, yang tidak dapat diakses untuk operasi baca. SQL Server Enterprise edition menyediakan fungsionalitas penuh dan failover untuk semua database dalam satu grup ketersediaan. Untuk contoh opsi ini, lihat diagram arsitektur berikut:

    • Arsitektur HA/DR dua simpul dengan klaster grup ketersediaan Selalu Aktif (Wilayah tunggal, Multi-AZ)

    • Arsitektur HA/DR tiga simpul (Wilayah tunggal, Multi-AZ)

    • Arsitektur HA/DR empat simpul dengan klaster grup ketersediaan terdistribusi Selalu Aktif (Multi-wilayah, Multi-AZ)

    • Arsitektur HA/DR tiga simpul dengan grup ketersediaan tunggal (Multi-wilayah)

  • Pengiriman log SQL Server sebagai solusi DR memerlukan failover manual ke server siaga dan tergantung pada frekuensi pencadangan log. Ini adalah salah satu opsi DR yang paling murah. Edisi SQL Server untuk situs DR primer dan log-shipped tidak perlu cocok. Opsi ini memenuhi RPO (menggunakan backup log transaksi setiap 5 menit dan RTO, tetapi membutuhkan pemeliharaan melalui manual, skrip kustom. Untuk contoh opsi ini, lihat diagram arsitektur berikut:

    • Arsitektur HA/DR tiga simpul dengan pengiriman log (Multi-wilayah)

• Jika Anda memiliki aplikasi seperti aplikasi SQL Server Reporting Services (SSRS) yang memiliki penyebaran skala, penyeimbang beban dapat mengarahkan semua lalu lintas ke node sekunder.

• Anda dapat menggunakan EC2 basis Amazon AMIs untuk aplikasi dan server database untuk menyediakan infrastruktur. Database dapat dipulihkan di Availability Zone baru, tergantung pada ukuran dan frekuensi cadangannya, dari cadangan asli terbaru (cadangan penuh, cadangan diferensial, atau cadangan log transaksi setiap 5 menit) atau dengan menggunakan snapshot EBS. Opsi ini memenuhi persyaratan RPO dan RTO tetapi memerlukan skrip khusus. Anda juga harus mempertimbangkan waktu yang diperlukan untuk menyediakan infrastruktur, dan memenuhi persyaratan RPO dan RTO dapat menjadi tantangan.

• EC2 Gambar Amazon (termasuk volume EBS) untuk kedua aplikasi dan server database dapat dipulihkan di Availability Zone baru. RPO dapat menjadi tantangan, tergantung pada cadangan terbaru, tetapi opsi ini dapat dikombinasikan dengan log transaksi terbaru untuk memenuhi persyaratan. Opsi ini mendukung snapshot Windows Volume Shadow Copy Service (VSS).

Kegagalan wilayah

Anda dapat menggunakan salah satu opsi berikut untuk memulihkan dari kegagalan AWS Wilayah tunggal dalam parameter yang diberikan (RPO 15 menit, RTO 4 jam).

• Anda dapat menggunakan Amazon EC2 base Amazon Machine Images (AMIs) untuk aplikasi dan server database untuk menyediakan infrastruktur. Database dapat dipulihkan di Wilayah baru, tergantung pada ukuran dan frekuensi cadangannya, dari cadangan asli terbaru (cadangan penuh, cadangan diferensial, atau cadangan log transaksi setiap 5 menit). Opsi ini memenuhi persyaratan RPO dan RTO tetapi memerlukan skrip khusus.

  • Pengiriman log SQL Server sebagai solusi DR memerlukan failover manual ke server siaga dan tergantung pada frekuensi pencadangan log. Ini adalah salah satu opsi DR yang paling murah. Edisi SQL Server untuk situs DR primer dan log-shipped tidak perlu cocok. Opsi ini memenuhi RPO (dengan menggunakan backup log transaksi setiap 5 menit) dan RTO, tetapi membutuhkan pemeliharaan melalui manual, skrip kustom. Database besar membutuhkan waktu restorasi yang lama.

• Anda dapat menggunakan Amazon EC2 AMI untuk aplikasi dan server database dan mengembalikannya ke target di Wilayah baru. RPO tergantung pada ukuran dan frekuensi backup.

  • Gambar aplikasi terbaru dapat dipulihkan dengan menggunakan AMI. Anda dapat menggunakan diferensial asli terbaru atau cadangan log transaksi setiap 5 menit untuk memperbarui database agar memenuhi RPO.

  • RTO bergantung pada ukuran dan waktu untuk mentransfer dan mengembalikan snapshot ke Wilayah baru, jika sumbernya belum sinkron dengan target.

• Solusi dengan waktu henti paling sedikit adalah mengembalikan gambar cadangan aplikasi dan memiliki simpul SQL Server siaga hangat di Wilayah terpencil dengan menggunakan pengaturan grup ketersediaan dua simpul, tiga simpul, atau empat simpul (dasar, klasik, atau terdistribusi) dan untuk terhubung ke server database siaga setelah failover. Replika mode komit sinkron memenuhi persyaratan RPO, sedangkan replika mode komit asinkron mungkin tertunda tergantung pada volume transaksi. Anda dapat menggunakan konfigurasi grup ketersediaan terdistribusi untuk skala node database di Wilayah baru, jika diperlukan. Konfigurasi ini juga mengurangi kompleksitas karena menggunakan dua grup ketersediaan independen alih-alih satu grup ketersediaan yang tersebar di seluruh Wilayah baik dalam mode komit sinkron atau komit asinkron, dan memenuhi persyaratan RTO dan RPO dengan nyaman. Atau, menggunakan grup ketersediaan dasar SQL Server dalam edisi Standar juga merupakan pilihan. Namun, ia memiliki keterbatasan karena hanya mendukung hingga dua node, dan hanya satu database yang dapat berada dalam satu grup ketersediaan meskipun beberapa grup ketersediaan didukung. Anda dapat mengatur edisi Standar SQL Server dalam satu Wilayah atau di seluruh Wilayah. Edisi ini memberikan penghematan biaya karena tidak mengenakan biaya untuk node sekunder, yang tidak dapat diakses untuk operasi baca. SQL Server Enterprise edition menyediakan fungsionalitas penuh, dan mendukung failover semua database sebagai failover grup ketersediaan tunggal.

Kasus penggunaan umum

Sebagai latihan ukuran, 80% aplikasi SQL Server yang berjalan di Amazon EC2 yang memiliki beban kerja pemrosesan transaksi online (OLTP) normal dapat dikelompokkan ke dalam salah satu dari tiga kategori berdasarkan seberapa pentingnya mereka:

• SQL Server HA/DR dengan cadangan SQL Server, menggunakan dua replika komit sinkron dan satu replika mode komit asinkron

• AWS Backup HA/DR dengan cadangan SQL Server, menggunakan Amazon EC2 AMI untuk aplikasi dan database, dan penyimpanan Amazon EBS

• AWS Backup HA/DR dengan cadangan SQL Server, menggunakan EC2 AMI basis Amazon untuk server database, EC2 gambar Amazon untuk aplikasi, dan snapshot Amazon EBS

Tabel berikut memberikan rincian tentang setiap kategori.

	SQL Server HA/DR dengan cadangan SQL Server	AWS Backup HA/DR dengan AMIs, penyimpanan EBS, dan cadangan SQL Server	AWS Backup HA/DR dengan AMIs, snapshot EBS, dan cadangan SQL Server
Memulihkan proses jika terjadi bencana	Kembalikan AMI EC2 basis Amazon untuk aplikasi dari AWS Backup Gagal ke instans siaga di Wilayah (dalam kasus kegagalan Availability Zone) atau ke instance Lintas wilayah (jika terjadi kegagalan Wilayah) Memenuhi persyaratan RPO dan RTO	Kembalikan EC2 gambar Amazon dari cadangan untuk aplikasi dan database Memberikan dukungan In-region dan Cross-region Terapkan pencadangan log diferensial dan transaksi SQL Server terbaru (setiap 15 menit) untuk memenuhi persyaratan RPO dan RTO untuk database	Kembalikan EC2 gambar Amazon dari cadangan untuk aplikasi Kembalikan AMI EC2 basis Amazon untuk server database Kembalikan snapshot EBS (jika ada) Cluster harus dibangun kembali Memberikan dukungan In-region dan Cross-region Terapkan pencadangan log diferensial dan transaksi terbaru ke database untuk memenuhi persyaratan RPO, tetapi RTO mungkin tidak terpenuhi
Sumber daya primer	Tiga lisensi edisi SQL Server Enterprise (lisensi node HA dan DR pasif gratis jika Anda memiliki perjanjian lisensi Jaminan Perangkat Lunak yang ada dengan Microsoft; lihat pengumuman) Ruang EC2 cadangan Amazon di Amazon Simple Storage Service (Amazon S3) Transfer data lintas wilayah	Satu lisensi SQL Server (edisi apa pun). Ruang EC2 cadangan Amazon di Amazon S3 Pencadangan SQL Server (file diferensial dan log) di Amazon S3 Transfer data lintas wilayah	Satu lisensi SQL Server (edisi apa pun). Ruang EC2 cadangan Amazon di Amazon S3 Pencadangan SQL Server (file diferensial dan log) di Amazon S3 Transfer data lintas wilayah
HA/DR	Penawaran HA dan DR	Hanya menawarkan DR	Hanya menawarkan DR
RPO	Failover ditangani oleh grup ketersediaan SQL Server (DR adalah manual)	Naskah manual atau kustom	Naskah manual atau kustom
RTO	Detik hingga menit	Menit hingga jam	Beberapa jam
Risiko hilang SLAs	Rendah	Sedang	Tinggi
Pengelolaan	Sederhana	Sedang	Sedang
Penskalaan	Sederhana	Sedang	Sedang
Batasan ukuran file untuk upload ke Amazon S3 atau transfer lintas wilayah	N/A - Ditangani dalam mode komit sinkron atau mode komit asinkron ke siaga hangat	Ya	Ya
Kehilangan data	Mendekati nol (tergantung pada beban kerja dan infrastruktur yang disediakan)	Tergantung pada frekuensi gambar EC2 cadangan Amazon dan cadangan SQL Server	Tergantung pada frekuensi gambar EC2 cadangan Amazon atau snapshot EBS dan cadangan SQL Server
Biaya	Sedang	Rendah - sedang	Rendah - sedang