Penjual awan AWS Amazon: ajar anda untuk mengkonfigurasi zon multi-tersedia AWS (zon multi-tersedia) dan seni bina pemulihan bencana automatik rentas rantau
Rakan teknikal semestinya pernah mendengar satu kalimat: "Semuanya akan gagal, hanya masalah masa."
Dalam seni bina awan, meletakkan semua telur dalam satu bakul adalah pantang larang terbesar. Banyak pasukan berpendapat bahawa semuanya akan baik-baik saja jika mereka memindahkan perniagaan mereka ke AWS (Amazon Cloud Technology). Akibatnya, kabel optik di kawasan yang boleh digunakan (AZ) terputus, atau seluruh wilayah (Wilayah) terputus kerana cuaca yang melampau, dan perkhidmatan segera ditutup. Barulah anda dapati bahawa apa yang disebut "ketersediaan tinggi" adalah jenaka di hadapan seni bina yang tidak dikonfigurasi dengan betul.
Hari ini kita tidak membincangkan konsep maya, atau menghafal dokumen rasmi. Sediakan akaun AWS anda, mari pergi terus ke barang kering tegar, dan bawa anda untuk mengkonfigurasi satu set
Senibina emas Internet yang mengambil kira "Multi-AZ yang sangat tersedia di kawasan yang sama" dan "Pemulihan bencana automatik rentas wilayah"
。
Tahap pertama: Multi-AZ di kawasan yang sama-untuk memadamkan api satu titik kegagalan
"Zon Available" adalah konsep teras AWS. Wilayah (seperti Oregon
Us-west-2
) Mengandungi beberapa kawasan yang ada (seperti
Us-west-2a
,
Us-west-2b
), Setiap zon yang tersedia secara fizikal diasingkan (bekalan kuasa bebas, pelesapan haba dan rangkaian), tetapi terdapat sambungan gentian optik berkelajuan tinggi di antara mereka.
Matlamat pertama kami ialah:
Walaupun salah satu kawasan yang ada lumpuh sepenuhnya, kawasan yang ada dapat mengambil alih perniagaan dalam beberapa saat, dan pengguna sama sekali tidak dapat merasakannya.
1. Reka bentuk halus VPC dan subnet (Subnet)
Ini adalah asas. Anda tidak boleh membuang semua pelayan ke dalam subnet.
Operasi standard: Di VPC anda, pilih sekurang-kurangnya dua kawasan yang berbeza (seperti AZ-A dan AZ-B).
Di setiap kawasan yang tersedia, bina subnet awam (load-load penyamaan) dan subnet peribadi (pelayan dan pangkalan data perkhidmatan EC2). Dengan cara ini, anda mempunyai 4 subnet, yang secara semula jadi membentuk pertahanan silang.
2. Lapisan pengiraan: ALB load balancing Auto Scaling (kumpulan teleskopik automatik)
Jangan mengikat IP rangkaian awam EC2 secara langsung kepada pengguna.
Buat Aplikasi Load Balancer (ALB) dan letakkan di subnet awam dua kawasan yang boleh digunakan. ALB akan berubah menjadi pintu gerbang, dan setelah lalu lintas masuk, ia akan menyebarkan permintaan secara merata ke pelayan belakang.
Buat kumpulan Auto Scaling (ASG): Mulakan templat untuk memilih cermin perniagaan anda. Konfigurasi utama: Semasa memilih rangkaian, periksa semua subnet peribadi dari dua kawasan yang tersedia. Tetapkan kapasiti yang diperlukan menjadi 2 (bermaksud menyimpan 2 mesin dalam perniagaan). Logik yang mendasari: AWS akan sangat pintar untuk memulakan EC2 pada AZ-A dan AZ-B masing-masing. Sekiranya mesin AZ-A gagal secara tiba-tiba pada suatu hari
, ASG akan segera merasakannya, dan secara automatik menarik mesin baru untuk menebusnya pada AZ-B yang sihat, dan bekerjasama dengan ALB untuk secara automatik menghilangkan mesin mati, dan keseluruhan proses akan automatik.
3. Lapisan data: Pangkalan data RDS Satu klik Multi-AZ
Sekiranya pelayan digantung, anda boleh memulakan semula sesuka hati. Sekiranya data digantung atau kacau, syarikat akan memulakan secara langsung.
Semasa membuat AWS RDS (seperti MySQL), ada suis emas yang disebut "Penyebaran Multi-AZ", dan saya tidak teragak-agak untuk memilihnya.
Orang dalam operasi: AWS akan membuat perpustakaan utama di kawasan tersedia utama (AZ-A), dan pada masa yang sama membuat perpustakaan siap sedia cermin yang diselaraskan sepenuhnya di kawasan siap sedia (AZ-B). Semua data yang ditulis ke perpustakaan utama akan diselaraskan ke perpustakaan siap sedia dalam masa nyata pada tahap blok.
Setelah bencana berlaku di AZ-A, RDS secara automatik akan memulakan Failover, meletakkan pangkalan data di atas pangkalan data utama, dan secara automatik menyelesaikan nama domain sambungan pangkalan data ke pangkalan data utama yang baru. Kod belakang anda tidak perlu mengubah suai mana-mana baris alamat IP, biasanya secara automatik dihidupkan semula dalam masa 30 saat.
Tahap kedua: Pemulihan bencana lintas wilayah-mempertahankan musuh dari jarak ribuan batu
Setelah menyelesaikan zon yang boleh digunakan, sistem anda dapat kebal terhadap 99% kegagalan fizikal harian. Tetapi bagaimana jika anda menghadapi bencana gempa besar seperti kelumpuhan rangkaian di seluruh wilayah dan ribut pematuhan polisi? Ini perlu diperkenalkan
Pemulihan bencana automatik merentas wilayah
。
Kami menganggap:
Kawasan pengeluaran (Primary) di Tokyo (ap-northeast-1), kawasan pemulihan bencana (DR) di Singapura (ap-southeast-1).
1. Replikasi data antara wilayah
Untuk menyegerakkan data Tokyo ke Singapura dalam masa nyata.
Tahap pangkalan data: Pada perpustakaan utama RDS di Tokyo, klik Operasi-> "Buat replika rentas rantau", dan pilih Singapura secara geografi. AWS akan menggunakan rangkaian tulang belakang globalnya untuk menyalin data Tokyo secara tidak segerak ke Singapura.
Tahap penyimpanan fail: Sekiranya anda menggunakan baldi S3 untuk menyimpan gambar atau fail pengguna, buka fungsi "CRR, Cross-Region Replication" baldi, sehingga fail di baldi Tokyo secara automatik akan terbang ke baldi Singapura.
2. Prasarana sejuk di kawasan pemulihan bencana (Singapura)
Di Singapura, satu set kumpulan VPC, ALB dan Auto Scaling juga dikerahkan.
Trik penjimatan wang: Untuk menjimatkan wang, anda boleh menetapkan "kapasiti minimum" dan "kapasiti yang diharapkan" dari kumpulan Auto Scaling di Singapura ke 0 (atau mesin berprofil rendah untuk ujian degupan jantung). Pada masa ini, Singapura tidak menanggung kos pengiraan EC2 yang besar.
Terdapat hanya yuran simpanan murah dan yuran penyegerakan pangkalan data.
3. Komander Jiwa: Route 53 Smart Routing dan Kegagalan
Bagaimana cara menukar lalu lintas pengguna global dari Tokyo ke Singapura dengan satu klik ketika bencana berlaku? Ini memerlukan perkhidmatan DNS AWS --
Laluan 53
。
Konfigurasikan "Failover Routing Policy" untuk nama domain laman web anda (seperti api.yourcompany.com) di Route 53.
Konfigurasikan dua rekod: Utama: ALB load penyamaan yang menunjuk ke Tokyo. Sub-rekod: ALB load penyamaan yang menunjuk ke Singapura.
Pemeriksaan Kesihatan Terikat: Berikan ALB Tokyo dengan pemeriksaan kesihatan Route 53, yang membolehkan laluan AWS mengesan laman web Tokyo setiap 10 saat.
Logik latihan bencana: Sekiranya seluruh Wilayah Tokyo meletup, pemeriksaan kesihatan Route 53 akan menyala setelah beberapa kegagalan berturut-turut. Ia akan segera mengaktifkan mekanisme pemutus litar dan secara langsung memotong resolusi nama domain ke ALB Singapura.
Tahap ketiga: proses kebangkitan sebenar semasa bencana
Setelah Wilayah Tokyo benar-benar terputus hubungan, Route 53 secara automatik membawa lalu lintas ke Singapura. Pada masa ini, kakitangan operasi dan penyelenggaraan hanya perlu melakukan dua langkah terakhir "meningkatkan hak", dan sistem dapat memulakan pengeluaran sepenuhnya:
Promote: Log masuk ke konsol AWS Singapura, pilih salinan baca sahaja yang diselaraskan dari Tokyo, dan klik "Promote Read Replica". Ia akan memutuskan hubungan segerak dengan Tokyo dalam beberapa minit dan menjadi perpustakaan utama standard yang boleh dibaca dan ditulis.
Bangun satu klik pada lapisan pengiraan: ubah kapasiti yang diharapkan dari kumpulan Auto Scaling Singapura dari 0 ke kuantiti pengeluaran yang anda perlukan (seperti 10). Dalam beberapa minit, sebilangan besar pelayan EC2 muncul di Singapura untuk membaca pangkalan data baru yang ditingkatkan secara automatik.
Lalu lintas masuk, pelayan dapat dihubungkan, dan pangkalan data dapat membaca dan menulis. Bencana wilayah ini yang cukup untuk muflis syarikat biasa, di bawah seni bina anda yang tepat, hanya berubah menjadi kelewatan pemuatan puluhan saat di sisi pengguna.
Tahap keempat: kos seni bina yang tinggi dan sejarah mengelakkan darah dan air mata
Data Transfer Fee: AWS menetapkan bahawa penghantaran data merentasi zon tersedia dalam VPC yang sama dikenakan (walaupun sangat murah). Oleh itu, cuba buat EC2 depan dan perkhidmatan intranet belakang anda berinteraksi dalam AZ yang sama. Hanya semasa melakukan penyegerakan pangkalan data atau penyegerakan nod kluster yang diedarkan, lalu lintas silang AZ digunakan.
Pertukaran antara RPO dan RTO: RPO (saat mana data dapat dipulihkan): kerana pangkalan data rentas rantau "berbeza
"Salin langkah demi langkah", pada saat Tokyo jatuh, mungkin ada satu atau dua saat data sebelum sampai ke Singapura, dan bahagian data ini akan tetap sementara. Syarikat mesti bersedia untuk mendamaian data. RTO (berapa lama masa yang diperlukan untuk pulih): Dengan menggunakan seni bina artikel ini, automasi dan sejumlah kecil intervensi manual dapat mengawal RTO dalam 5 hingga 15 minit.
Kemusnahan biasa (projek huru-hara): Struktur ketersediaan tinggi adalah pantang larang yang paling banyak, "letakkan di sana untuk makan abu". Banyak syarikat dilengkapi dengan pemulihan bencana antara wilayah dan tidak bergerak selama tiga tahun. Pada tahun keempat kemalangan, mereka mendapati bahawa gambar cermin Singapura telah lama habis dan tidak dapat berjalan. Dianjurkan untuk memilih hujung minggu setiap enam bulan pada awal pagi, memotong secara manual Route 53 ke kawasan pemulihan bencana, dan melakukan latihan pemutusan hubungan sebenar.
Ringkasan
Kegagalan titik sifar tidak bergantung pada keberuntungan, tetapi pada reka bentuk seni bina saintifik.
Kawasan yang boleh digunakan di kawasan yang sama menyelesaikan "ketersediaan tinggi (HA)" untuk memastikan bahawa ia tidak akan terputus setiap hari; pemulihan bencana automatik rentas wilayah menyelesaikan "pemulihan bencana (DR)" untuk memastikan syarikat dapat bertahan dalam keadaan yang melampau.
Kimpalan dua set garis pertahanan ini ke dalam akaun AWS anda. Sejak itu, tidak kira seberapa kuat rangkaian luaran, anda boleh duduk di depan komputer dan stabil seperti gunung.
