Corak Multi-AZ untuk Perkhidmatan Berkeadaan

Perkhidmatan berkeadaan — pangkalan data, cache dan sistem fail — ialah komponen paling sukar untuk dijadikan sangat tersedia kerana perkhidmatan ini menyimpan data yang mesti kekal selepas kegagalan. Jika pangkalan data AZ tunggal gagal, seluruh aplikasi anda kehilangan stor datanya. Jawapan AWS ialah pelaksanaan Multi-AZ, yang mengekalkan replika segerak atau hampir segerak dalam Availability Zone kedua yang boleh mengambil alih dengan pantas apabila primer gagal.

RDS Multi-AZ mengekalkan replika standby segerak dalam AZ yang berbeza. Setiap penulisan kepada primer direplikasi secara segerak sebelum kejayaan diakui — ini bermaksud tiada kehilangan data (RPO=0), tetapi kependaman penulisan meningkat sedikit. Apabila primer gagal, RDS mengemas kini titik akhir DNS secara automatik supaya menunjuk kepada standby dalam masa 60-120 saat. Aplikasi anda hanya perlu menyambung semula ke titik akhir yang sama — tiada perubahan kod diperlukan.

Amazon Aurora mengembangkan lagi Multi-AZ dengan lapisan storan teragih dikongsi yang mereplikasi data secara automatik merentas tiga AZ dalam enam salinan. Instance Aurora tidak menyimpan keadaan — instance tersebut membaca dan menulis pada storan dikongsi ini. Apabila Aurora Writer PRIMARY gagal, Read Replica dalam AZ lain dinaikkan taraf menjadi Writer dalam masa kurang daripada 30 saat. Proses ini lebih pantas berbanding failover RDS Multi-AZ, dan data sentiasa konsisten merentas AZ tanpa Replication Standby yang dikonfigurasi secara eksplisit.

ElastiCache untuk Redis menyokong Multi-AZ melalui kumpulan Replicas. Nod PRIMARY menerima penulisan dan mereplikasikannya secara Asynchronous kepada Read Replicas dalam AZ lain. Apabila PRIMARY gagal, ElastiCache secara automatik menaikkan taraf Replica kepada PRIMARY. Bagi Redis dengan mod kluster didayakan, data dipecahkan merentas beberapa kumpulan nod, setiap satunya mempunyai PRIMARY dan Replicas sendiri merentas AZ — ini menyediakan HA serta penskalaan mendatar.

Amazon Elastic File System (EFS) sememangnya Multi-AZ — ia ialah perkhidmatan serantau yang menyimpan data secara berlebihan merentas beberapa AZ dalam sesuatu Region. Anda mencipta sasaran Mount dalam subnet setiap AZ, dan instance EC2 dalam mana-mana AZ boleh Mount sistem fail melalui sasaran Mount setempatnya. Tiada konfigurasi Multi-AZ manual diperlukan. EFS menyediakan storan fail POSIX dikongsi yang boleh diakses serentak oleh beberapa instance merentas AZ.

Elastic Load Balancers sendiri bersifat Multi-AZ — ALB dan NLB menggunakan nod pengimbang beban dalam setiap AZ yang anda tentukan. Dengan penyeimbangan beban merentas zon didayakan (tetapan lalai untuk ALB), setiap nod pengimbang beban mengagihkan trafik secara sama rata kepada semua sasaran yang didaftarkan dalam semua AZ, bukan hanya AZnya sendiri. Ini memastikan bahawa walaupun semua instance dalam satu AZ gagal, pengimbang beban masih meneruskan penyampaian trafik melalui instance dalam AZ yang masih berfungsi.

Kesilapan lazim ialah menggunakan satu NAT Gateway dalam satu AZ sedangkan subnet persendirian dalam AZ lain menghala melaluinya. Jika AZ tersebut gagal, semua instance persendirian kehilangan akses Internet. Corak Multi-AZ yang betul ialah menggunakan satu NAT Gateway bagi setiap AZ dan mengkonfigurasi setiap jadual route persendirian AZ supaya route 0.0.0.0/0 melalu NAT Gatewaynya sendiri. Ini menghapuskan NAT Gateway sebagai SPOF merentas AZ dan mengurangkan kos pemindahan data merentas AZ.

DynamoDB ialah perkhidmatan terurus sepenuhnya yang mereplikasi data secara automatik merentas tiga AZ dalam sesuatu Region — anda tidak perlu mengkonfigurasi Multi-AZ secara manual. Setiap penulisan disimpan secara tahan lasak merentas ketiga-tiga AZ sebelum kejayaan dikembalikan. DynamoDB sememangnya tahan terhadap kegagalan pada peringkat AZ sejak awal. Oleh sebab itu, DynamoDB sering disyorkan sebagai pilihan Database apabila soalan peperiksaan menekankan ketersediaan tinggi dengan beban operasi yang minimum.

Semasa failover RDS Multi-AZ, Applications yang mengekalkan Connection Database berterusan mungkin mengalami kegagalan apabila Endpoint berubah. RDS Proxy berada di antara Application anda dengan RDS dan mengekalkan kumpulan Connection ke Database. Semasa failover, RDS Proxy secara automatik menghalakan semula trafik ke PRIMARY baharu — mengurangkan kesan failover daripada 60-120 saat kepada kurang daripada 30 saat untuk Applications yang menggunakan Endpoint Proxy. RDS Proxy juga membantu fungsi Lambda yang mencipta banyak Connection berjangka pendek.

Memahami mod Replication amat penting untuk memilih corak Multi-AZ. Replication Synchronous (RDS Multi-AZ, EFS) memastikan RPO=0 kerana setiap penulisan disahkan dalam kedua-dua AZ sebelum kejayaan. Imbangannya ialah kependaman penulisan yang sedikit lebih tinggi. Replication Asynchronous (Replica Redis ElastiCache, RDS Read Replicas) menawarkan kependaman penulisan yang lebih rendah tetapi menerima sedikit ketinggalan Replication — ini bermakna sebahagian data mungkin hilang jika PRIMARY gagal sebelum Replication selesai.

Anda hendaklah menguji failover Multi-AZ secara berkala untuk mengesahkan andaian RTO anda. Untuk RDS, anda boleh mencetuskan failover menggunakan pilihan Mulakan semula dengan failover dalam konsol atau CLI. Pantau CloudWatch untuk metrik FailedSQLServerAgentJobsCount dan perhatikan log Application anda untuk mengesahkan bahawa ia berjaya menyambung semula. Dokumentasikan tempoh failover sebenar — tempoh itu mungkin berbeza daripada dokumentasi AWS bergantung pada kelas instance dan beban kerja anda.

Dalam pelajaran ini, anda mempelajari bahawa: RDS Multi-AZ menggunakan Replication Synchronous dengan failover DNS automatik, Aurora menggunakan lapisan storan dikongsi merentas tiga AZ untuk failover yang lebih pantas, dan EFS serta DynamoDB sememangnya Multi-AZ tanpa konfigurasi manual. Gunakan satu NAT Gateway bagi setiap AZ untuk mengelakkan SPOF merentas AZ. Seterusnya, kita akan meneroka corak active-active dan active-passive merentas beberapa Region.