Hei, semuanya.
Dan selamat datang kembali.
Sekarang ke dalam video ini pada gambaran umum tingkat tinggi, kita akan membahas tentang ide-ide Amazon
penyebaran zona multi ketersediaan juga disebut sebagai penyebaran multi.
Sekarang, sebelum kita membahas lebih detail tentang hal itu, mari kita lihat tantangan yang khas.
Jadi, mari kita asumsikan bahwa Anda memiliki database yang berjalan di zona ketersediaan, nomor satu.
Sekarang, karena beberapa alasan, jika zona ketersediaan satu ini turun atau mungkin perangkat keras tempat
database berjalan turun, maka seluruh aplikasi Anda akan turun karena jantung aplikasi
di mana data terutama disimpan adalah database.
Jika database down, maka seluruh situs web bisa down.
Dan ini adalah sesuatu yang sebenarnya tidak Anda inginkan untuk lingkungan produksi.
Dan inilah alasan mengapa sangat penting bahwa kapan pun Anda menggunakan ide untuk produksi, Anda harus
menghindari penyebaran berdasarkan zona ketersediaan tunggal saja.
Dan arsitektur yang lebih baik adalah dengan menggunakan penyebaran zona multi ketersediaan.
Jadi dalam arsitektur penyebaran berbasis multi AC, apa yang terjadi adalah Anda memiliki basis data
utama di sini dan Anda memiliki basis data sekunder yang berjalan di zona ketersediaan yang berbeda di wilayah
yang sama dan ada replikasi yang terjadi di antara kedua basis data ini.
Sekarang, karena beberapa alasan, katakanlah basis data utama turun dalam kasus seperti itu, ide akan mengalihkan
semua permintaan ke instance stand by.
Baiklah.
Jadi ini adalah proses otomatis.
Sebagai pengguna atau sebagai aplikasi, Anda tidak perlu mengkhawatirkan hal itu.
Sekarang, salah satu pertanyaan yang muncul di sini adalah bahwa dalam skenario mana failover otomatis ini terjadi
dari instance primer ke instance standby?
Sekarang, sebelum kita melihat ke dalam bidang kondisi, mari kita segera merevisi bahwa jika ada pemadaman
terencana atau tidak terencana dari instance database Anda, maka ini secara otomatis beralih ke replika siaga di zona
ketersediaan lain dalam penerapan multi AC.
Ini adalah sesuatu yang telah kita lihat.
Sekarang mari kita lihat beberapa kondisi.
Pertama, jika ada kehilangan ketersediaan di zona ketersediaan primer.
Kedua adalah jika ada kehilangan konektivitas jaringan ke instance utama, jika ada kegagalan
unit komputasi pada instance utama, sekali lagi, kondisi failover terjadi.
Jika ada kegagalan penyimpanan pada instance database utama dalam kasus seperti itu, juga failover otomatis
terjadi.
Dan ketika kita melihat ke dalam waktu failover, biasanya berkisar antara 60 hingga 1 hingga 20 detik.
Sekarang, mari kita lakukan satu hal.
Mari kita lanjutkan dan pahami hal ini dari perspektif demo agar konsep kita jelas.
Sekarang untuk demo hari ini, saya memiliki database yang dibuat berdasarkan penyebaran multi AC.
Nama database adalah Demo DB, Multi AC.
Sekarang, jika Anda melihat ke dalam basis data spesifik ini, izinkan saya pergi ke konfigurasi.
Mari kita turun sedikit.
Anda melihat bahwa itu menyatakan bahwa multi AC diaktifkan sehingga dinyatakan sebagai ya.
Jadi, mari kita lanjutkan dan melihat bagaimana tepatnya fungsinya.
Jadi kita akan pergi ke konektivitas di sini.
Izinkan saya menyalin titik akhir dari instance ID.
Dan mari kita cepat-cepat melakukan pencarian untuk melihat apa alamat IP yang dikembalikan di sini.
Alamat IP adalah satu 7231 37. 32.
Jadi pada tahap ini, jika saya harus menunjukkan ini kepada Anda dalam bentuk diagram, Anda dapat mempertimbangkan bahwa alamat
IP yang telah dikembalikan ini adalah alamat IP dari instance utama di sini.
Sekarang untuk perspektif demo, kita akan melakukan failover dan kita akan melihat bagaimana alamat IP berubah menjadi alamat
IP instance sekunder.
Jadi mari kita lakukan satu hal.
Mari kita lanjutkan dan reboot instance database.
Sekarang, kapan pun Anda reboot, Anda memiliki opsi reboot dengan Failover.
Jadi, mari kita lanjutkan dan lakukan konfirmasi.
Jadi, ini hanyalah cara sederhana untuk mengidentifikasi bagaimana penyebaran multi AC bekerja dalam skenario dunia nyata.
Jika ada masalah yang terkait dengan jaringan dan semua failover terjadi secara otomatis, Anda tidak perlu
khawatir tentang itu.
Jadi, izinkan saya segera melakukan konfirmasi.
Baiklah.
Jadi, pembangunan kembali sedang berlangsung.
Jadi, mari kita tunggu sejenak di sini.
Jadi pada refresh, status kita sekarang tersedia.
Sekarang, pada tahap ini, jika Anda melakukan pencarian NSS lagi untuk menemukan alamat IP yang terkait dengan instance
database, kali ini Anda akan melihat alamat IP-nya berbeda.
Sebelumnya adalah satu 7231 3732 sekarang menjadi satu 7231 79. 1 47.
Jadi di balik layar RDC secara otomatis telah mengalihkan permintaan ke instance siaga di sini.
Sekarang, satu hal penting yang perlu dicatat adalah bahwa URL endpoint yang kita diskusikan
di sini, ini tetap sama.
Jadi, bahkan jika basis data utama mati dan jika permintaan akan menuju ke titik akhir ini, ide akan secara
otomatis mengarahkan permintaan ke instance siaga.
Dan inilah alasan mengapa ketersediaan tinggi lisan bekerja dalam arsitektur berbasis multi AC.