Reka bentuk seni bina ketersediaan tinggi di Amazon Cloud International Station: zon ketersediaan silang (AZ) pemulihan bencana dan pengimbangan beban ELB
Pada era pengkomputeran awan, "High Availability (HA)" hampir menjadi kata yang dibincangkan oleh pelbagai arkitek. Ramai orang percaya bahawa selagi sistem ini dipindahkan ke Amazon Cloud (AWS), EC2 dibeli, dan pengimbangan beban dilengkapi, ketersediaan tinggi akan dapat dicapai secara semula jadi.
Walau bagaimanapun, persekitaran pengeluaran sebenar sering memberi optimisme buta seperti ini.
Apabila zon tersedia AWS (AZ) lumpuh kerana kabel optik yang mendasari, kegagalan kuasa atau rangkaian yang ditentukan perisian (SDN) yang tidak normal, adakah perkhidmatan anda akan beralih secara automatik dan lancar, atau akan mati bersama, Telefon perkhidmatan pelanggan rosak?
Betul
Senibina ketersediaan tinggi tidak dibeli, tetapi dirancang
。 Artikel ini akan sepenuhnya meninggalkan kata-kata hitam PPT yang rumit, dan menggunakan "vernakular besar" yang paling mudah difahami untuk membawa anda membongkar dua cadangan utama yang sangat tersedia di Amazon Cloud International:
Pemulihan bencana merentasi zon yang ada (Cross-AZ)
Dengan
Pengimbangan beban ELB
。
1. Mendefinisikan semula "ketersediaan tinggi": kebenaran yang mendasari Wilayah dan AZ
Sebelum kita mula merancang seni bina, kita mesti mengenali infrastruktur fizikal asas AWS. Ini adalah asas semua reka bentuk yang tinggi.
Wilayah: Kawasan terpencil sepenuhnya secara geografi (seperti Tokyo, Virginia, Ireland). Jarak antara wilayah sangat jauh. Kecuali bencana geopolitik berlaku, pemadaman elektrik di satu kawasan tidak akan mempengaruhi yang lain.
Kawasan yang ada (AZ): Terdapat banyak kawasan yang ada dalam satu kawasan. Ingat: satu AZ tidak sama dengan pusat data (Pusat Data). AZ mungkin terdiri daripada beberapa kumpulan pusat data yang berdekatan antara satu sama lain tetapi benar-benar bebas dari kuasa dan rangkaian.
💡Titik sakit teras: Mengapa seni bina AZ tunggal mati? Untuk menjimatkan wang, banyak syarikat luar negara meninggalkan pelayan web dan pangkalan data di AZ yang sama (seperti ap-northeast-1a). Ini sama dengan meletakkan semua telur di dalam bakul yang disebut "kalis peluru" tetapi masih boleh bocor. Setelah AZ mengalami kegagalan rangkaian tulang belakang, perniagaan anda akan terputus seketika.
Oleh itu, seni bina silang AZ(Multi-AZ) bukan "pilihan lanjutan", tetapi persekitaran pengeluaran
Garis bawah keras
。
2. Polis trafik lalu lintas: cara yang betul untuk membuka ELB (Elastic load balancing)
Untuk mencapai pemulihan bencana lintas AZ, langkah pertama mesti mempunyai "polis trafik lalu lintas" untuk menyebarkan permintaan dari pengguna di seluruh dunia secara merata dan pintar ke pelayan di kawasan yang berbeza. Di AWS, peranan ini terdiri daripada
ELB(Elastic Load Balancing)
Berkhidmat.
AWS menyediakan pelbagai pengimbang beban, tetapi dalam seni bina web moden, kami memberi tumpuan terutamanya pada
ALB (Aplikasi Load Balancer)
Dan
NLB (Rangkaian Load Balancer)
。
1. ALB vs NLB: Jangan pilih
Senjata yang salah
Ciri-ciri
ALB (menggunakan pengimbang beban)
NLB (rangkaian beban penyamaan)
Kerja OSI Hierarki
Lapisan 7 (lapisan aplikasi: HTTP/HTTPS)
Lapisan 4 (Lapisan Pengangkutan: TCP/UDP/TLS)
Kelebihan teras
Pintar. Ia dapat mengenal pasti jalur URL, kuki, HTTP Header untuk penghalaan lanjutan. Menyokong penyahpasangan sijil SSL.
Sangat pantas. Kelewatan ultra rendah, dapat menangani puluhan juta permintaan serentak sesaat, dan menyokong IP tetap.
Senario yang sesuai
Sebilangan besar aplikasi web, API perkhidmatan mikro, laman web e-dagang.
Gerbang permainan, penerima Internet of Things (IoT), perkhidmatan TCP asal tanpa protokol HTTP.
Bagi kebanyakan syarikat luar negara,
ALB
Adalah pilihan yang paling disyorkan.
2. Load Balancing Cross-Zone (Cross-Zone Load Balancing)
Ini adalah tempat paling mudah bagi orang untuk melangkah ke lubang dalam reka bentuk ELB.
Secara lalai, pengimbangan beban merentas zon tersedia ALB adalah
Membuka
, Dan NLB lalai
Tutup
Yang itu. Apakah perbezaannya?
Tutup: Sekiranya DNS memperuntukkan 50% lalu lintas ke nod pengimbangan beban AZ-A, 50% ke nod pengimbangan beban AZ-B. Walaupun hanya ada 1 pelayan di AZ-A dan 4 pelayan di AZ-B, pelayan di AZ-A akan habis dengan 50% lalu lintas.
Dalam keadaan terbuka: Tidak kira di mana aliran mencapai simpul pengimbangan beban AZ terlebih dahulu, ELB akan sama-sama menyebarkan permintaan ke semua contoh belakang di semua AZ di belakangnya.
Kesimpulan:
Kecuali anda mempunyai keperluan kelewatan yang sangat menuntut (tahap mikrodetik), jika tidak
Sangat disarankan untuk mengekalkan pengimbangan beban di seluruh kawasan yang tersedia
Untuk memastikan bahawa tekanan belakang benar-benar rata-rata.
3. Segitiga besi di seberang pemulihan bencana AZ: pengkomputeran, rangkaian dan penyimpanan
Dengan ELB, polis trafik tidak mencukupi. Lorong belakang (pengiraan), rangkaian jalan raya (rangkaian) dan gudang (penyimpanan) juga mesti mempunyai kemampuan untuk melintasi AZ untuk mencapai "peralihan tanpa perasaan" apabila AZ tertentu mati.
1. Lapisan pengiraan: Auto Scaling (kumpulan pengembangan automatik) adalah satu-satunya postur yang betul
Jangan sekali-kali pergi secara manual untuk membuat dua mesin untuk meletakkan dua AZ. Anda harus menggunakan
AWS Auto Scaling Group (ASG)
。
Anda hanya perlu mengkonfigurasi templat permulaan dan memberitahu ASG: "Saya memerlukan sekurang-kurangnya 2 mesin dan maksimum 10 mesin. Tolong bantu saya menyebarkannya di
Ap-northeast-1a
Dan
Ap-northeast-1b
Dalam kedua-dua AZ ini."
Mekanisme Pemeriksaan Kesihatan (Pemeriksaan Kesihatan): Jangan biarkan ELB hanya memeriksa sama ada EC2 dihidupkan (Ping). Untuk mengkonfigurasi ELB untuk meminta antara muka tertentu dalam kod anda (seperti/kesihatan). Sekiranya antara muka ini kembali 500, atau sambungan pangkalan data gagal, ELB akan berdiri
Tentukan bahawa contoh itu "tidak sihat" dan berhenti menghantar lalu lintas kepadanya.
Keupayaan penyembuhan diri: Setelah AZ tertentu digantung dan semua mesin di AZ hilang, ASG akan segera mencetuskan penggera dan secara automatik membuka mesin baru di AZ lain yang sihat untuk mengisi jurang.
2. Lapisan Rangkaian: Peraturan Emas Subnet dan Routing
Dalam reka bentuk rangkaian peribadi (VPC), banyak orang akan membuat kesalahan struktur. Senibina rangkaian ketersediaan tinggi standard harus mengikuti prinsip "penampilan berpasangan dan pengasingan mutlak".
Subnet awam: Letakkan pintu masuk Internet Gateway, ELB dan NAT. Setiap AZ dilengkapi dengan satu.
Subnet Peribadi: Letakkan pelayan aplikasi EC2 sebenar. Mesin-mesin ini tidak memerlukan IP rangkaian awam dan tidak boleh didedahkan secara langsung ke Internet. Setiap AZ dilengkapi dengan satu.
Perangkap gerbang NAT yang tersedia tinggi: Untuk menjimatkan wang, banyak pasukan hanya membina gerbang NAT di seluruh VPC dan meletakkannya di AZ-A, yang membolehkan EC2 peribadi AZ-B melewati AZ untuk melayari Internet. Setelah AZ-A digantung, walaupun pelayan AZ-B masih hidup, ia juga dihapuskan kerana tidak dapat mengakses Internet (tidak dapat mengakses API luaran, tidak dapat memuat turun ketergantungan). Pendekatan yang betul: Setiap AZ mempunyai pintu masuk NAT yang berasingan.
3. Penyimpanan dan lapisan pangkalan data: mengucapkan selamat tinggal kepada satu titik, merangkul Multi-AZ
Nod pengkomputeran adalah tanpa keadaan dan boleh dibuka semula pada bila-bila masa ketika mati. Tetapi
Data mempunyai status, dan data tidak boleh hilang.
Pangkalan Data Perhubungan (RDS / Aurora): Sangat membuka penyebaran Multi-AZ. AWS secara automatik membuat contoh sandaran (Standby) yang disegerakkan sepenuhnya di AZ yang lain. Apabila AZ di mana perpustakaan utama berada gagal, RDS secara automatik akan melakukan drift DNS, menaikkan perpustakaan ganti ke perpustakaan utama dalam beberapa s hingga puluhan s, dan kod aplikasi anda bahkan tidak perlu mengubah rentetan sambungan (Endpoint).
Penyimpanan fail (EFS vs EBS):EBS (cakera keras awan): Ia terikat pada AZ tertentu. Ini bermaksud bahawa EC2 AZ-A digantung, dan anda tidak boleh memasang EBS secara langsung ke EC2 AZ-B. EFS (Sistem Fail Fleksibel): Sokongan asli di seluruh AZ. EC2 berbilang AZ boleh membaca dan menulis EFS yang sama pada masa yang sama. Sekiranya perniagaan anda perlu berkongsi penyimpanan fail (seperti katalog muat naik gambar Wordpress), jangan ragu untuk memilih EFS.
Keempat, pertempuran sebenar: latihan seni bina ketersediaan tinggi multi-AZ standard
Untuk memberi anda perasaan yang lebih intuitif, mari kita mensimulasikan bagaimana permintaan pengguna standard mengalir dalam seni bina ketersediaan tinggi AWS trans-AZ.
Senario: Pengguna mengunjungi laman web e-dagang [https: // example.com]
Resolusi nama domain: Pengguna memulakan permintaan, dan AWS Route 53 (Smart DNS) menyelesaikan nama domain. Kerana konfigurasi
Dengan strategi penundaan atau pengundian, Route 53 mengarahkan lalu lintas ke ALB yang digunakan di subnet awam.
Pengedaran lalu lintas: ALB menerima permintaan HTTPS, menyelesaikan penyahsulitan sijil SSL (tekanan nyahpasang) secara tempatan, dan kemudian meneruskan permintaan tersebut ke contoh EC2 yang terletak di AZ-A atau subnet peribadi AZ-B mengikut strategi pengimbangan beban merentas zon yang tersedia.
Pemprosesan perniagaan dan membaca dan menulis data: Perniagaan pemprosesan aplikasi di EC2. Jika anda perlu membaca dan menulis pangkalan data, ia disambungkan ke perpustakaan utama RDS (terletak di AZ-A). Pada ketika ini, RDS secara automatik menyalin penyegerakan data ke pangkalan data sandaran RDS (terletak di AZ-B).
Bencana berlaku (AZ-A simulasi terputus sepenuhnya): Reaksi ELB: ALB mendapati bahawa degupan jantung EC2 dalam AZ-A berhenti, atau pemeriksaan kesihatan gagal secara berterusan, dan segera membuang AZ-A dari senarai penerusan. 100% lalu lintas langsung diimport ke dalam EC2 AZ-B. Penyembuhan diri RDS: AWS memantau bahawa perpustakaan utama RDS terputus hubungan dan secara automatik memulakan Failover. Perpustakaan ganti AZ-B dinaik taraf ke perpustakaan utama baru dalam masa 30 saat, dan Route 53 secara automatik mengemas kini Endpoint dalaman RDS. EC2 AZ-B kembali membaca dan menulis normal setelah melaporkan kesalahan sebentar. Pengembangan ASG: Auto Scaling Group mendapati bahawa jumlah mesin yang masih hidup kurang dari nilai jangkaan minimum yang ditetapkan, dan EC2 baru muncul dalam AZ-B yang sihat dan secara automatik mendaftar di belakang ALB.
Keputusan:
Dalam keseluruhan proses, kecuali sebilangan kecil pengguna yang memulakan permintaan pada saat beralih, mereka mungkin menghadapi percubaan semula (502/504). 99% pengguna sama sekali tidak dapat merasakan bahawa latar belakang telah mengalami bencana tingkat komputer "kepantasan hidup dan mati".
5. Panduan untuk mengelakkan lubang: tiga kesalahan maut yang sering dilakukan oleh arkitek
Semasa benar-benar melaksanakan struktur ini, berdasarkan sebilangan besar kes rollover, saya meringkaskan tiga terumbu berikut yang paling mudah diabaikan:
1. Kos penghantaran merentasi AZ (Cross-AZ Data Transfer Costs)
Trafik masuk AWS (masuk dari Internet) adalah percuma, tetapi dalam Wilayah yang sama,
Lalu lintas melintasi transmisi AZ yang berbeza dikenakan
(Biasanya $0.01/GB).
Sekiranya perkhidmatan mikro anda terlalu rosak, Perkhidmatan A(AZ-A) sering memanggil Perkhidmatan B(AZ-B) melalui RPC, dan pada akhir bulan, anda akan menerima bil rangkaian yang sangat menakutkan.
Pelan pengoptimuman: Cuba biarkan lalu lintas melengkapkan gelung tertutup intranet dalam AZ yang sama, dan hanya menyeberangi AZ apabila pemulihan bencana beralih.
2. Pangkalan data "pecahan otak" dan kelewatan penyegerakan
Walaupun RDS Multi-AZ adalah replikasi segerak, prestasinya sangat baik, tetapi jika anda membina kluster pangkalan data yang dibina sendiri (seperti MySQL MHA yang diubah suai oleh inti keras anda sendiri), apabila anda menggegarkan rangkaian AZ, kedua-dua nod cenderung berlaku. Fikirkan bahawa anda adalah fenomena "otak-otak" perpustakaan utama, ini menyebabkan kekeliruan dalam penulisan data.
Pelan pengoptimuman: menyerahkan perkara profesional kepada alat profesional, persekitaran pengeluaran yang kuat
Dianjurkan untuk memberi keutamaan kepada RDS atau Aurora, dan menyerahkan masalah konsistensi yang diedarkan di bahagian bawah kepada AWS untuk diselesaikan.
3. Lupa ujian: ketersediaan tinggi di atas kertas bukan ketersediaan tinggi
Banyak struktur pasukan dirancang dengan sempurna, tetapi mereka tidak pernah melakukan latihan pemulihan bencana dalam tiga tahun. Apabila hasilnya benar-benar tidak berfungsi, didapati bahawa IP pangkalan data ditulis dalam kod, atau kumpulan keselamatan (Kumpulan Keselamatan) lupa melepaskan segmen rangkaian AZ yang lain.
Pelan pengoptimuman: Lakukan Chaos Engineering (Chaos Engineering) secara berkala. Pada waktu puncak rendah, pergi ke konsol RDS secara manual dan klik "Failover", atau sengaja mematikan semua EC2 AZ untuk melihat apakah sistem dapat sembuh seperti yang diharapkan.
Kesimpulan
Pada era awan,
Pemulihan bencana tidak boleh menjadi tugas fizikal yang mahal dan membebankan, tetapi intuisi reka bentuk.
Melalui
Pengedaran pintar ELB
,
Penyembuhan diri tanpa status Auto Scaling
Serta
Penyegerakan silang AZ RDS
Bersama-sama, kami hanya menggunakan beberapa perkhidmatan stesen antarabangsa awan Amazon standard untuk membina struktur keluli yang dapat menahan bencana di ruang komputer.
Ingat, tahap ketersediaan tinggi yang tertinggi bukanlah untuk memberkati kegagalan yang tidak pernah berlaku; tetapi apabila kegagalan tiba seperti yang dijadualkan, sistem anda hanya bergetar sedikit dan terus bergerak dengan stabil dalam angin dan hujan.