Halo, Habr! Abdi Artem Karamyshev, kapala tim administrasi sistem . Kami ngagaduhan seueur peluncuran produk anyar dina taun katukang. Kami hoyong mastikeun yén ladenan API éta gampang skala, toleran lepat, sareng siap pikeun kamekaran gancang dina beban pangguna. Platform kami dilaksanakeun dina OpenStack, sareng abdi hoyong nyarioskeun ka anjeun naon masalah kasabaran sesar komponén anu kedah urang rengsekeun pikeun kéngingkeun sistem toleran lepat. Jigana ieu bakal metot pikeun maranéhanana anu ogé ngamekarkeun produk on OpenStack.
Kasabaran lepat sakabéh platform diwangun ku daya tahan komponénna. Janten urang laun-laun bakal ngalangkungan sadaya tingkat dimana urang ngaidentipikasi résiko sareng nutupana.
Vérsi pidéo carita ieu, sumber utama nyaéta laporan dina konperénsi dinten Uptime 4, diayakeun ku , anjeun tiasa ningali .
Ketahanan arsitéktur fisik
Bagian umum tina awan MCS ayeuna dumasar kana dua puseur data Tier III, diantara aranjeunna aya serat poék sorangan, ditangtayungan di tingkat fisik ku ruteu béda, kalawan throughput 200 Gbit / s. Tingkat III nyayogikeun tingkat kasabaran sesar anu diperyogikeun pikeun infrastruktur fisik.
Serat poék ditangtayungan dina tingkat fisik sareng logis. Prosés reservasi saluran éta iterative, timbul masalah, sarta kami terus ngaronjatkeun komunikasi antara puseur data.
Salaku conto, teu lami pisan, nalika damel di sumur caket salah sahiji pusat data, hiji excavator peupeus pipa, sareng di jero pipa ieu aya kabel optik utama sareng cadangan. Saluran komunikasi toleran kasalahan kami sareng pusat data tétéla rentan dina hiji waktos, dina sumur. Sasuai, urang geus leungit bagian tina infrastruktur. Kami narik kasimpulan sareng nyandak sababaraha tindakan, kalebet masang optik tambahan dina sumur anu caket.
Dina puseur data aya titik ayana panyadia komunikasi ka saha urang nyiarkeun awalan urang ngaliwatan BGP. Pikeun unggal arah jaringan, métrik anu pangsaéna dipilih, anu ngamungkinkeun para klien anu béda pikeun nyayogikeun kualitas sambungan anu pangsaéna. Lamun komunikasi ngaliwatan hiji panyadia turun, urang ngawangun deui routing urang ngaliwatan panyadia sadia.
Lamun panyadia gagal, urang otomatis pindah ka nu salajengna. Upami aya kagagalan salah sahiji pusat data, kami gaduh salinan eunteung jasa kami di pusat data kadua, anu nyandak sadayana beban.
Daya tahan infrastruktur fisik
Naon anu kami anggo pikeun kasabaran kasalahan tingkat aplikasi
Jasa kami diwangun dina sababaraha komponén opensource.
ExaBGP nyaéta layanan nu implements sababaraha fungsi ngagunakeun basis BGP protokol routing dinamis. Kami aktip ngagunakeun éta pikeun ngiklankeun alamat IP kami anu didaptarkeun bodas dimana pangguna ngaksés API.
HAProxy mangrupakeun balancer beban tinggi nu ngidinan Anjeun pikeun ngonpigurasikeun aturan balancing lalulintas pisan fléksibel dina tingkat nu beda-beda model OSI. Kami nganggo éta pikeun nyaimbangkeun di payun sadaya jasa: pangkalan data, calo pesen, jasa API, jasa wéb, proyék internal kami - sadayana aya di tukangeun HAProxy.
aplikasi API - aplikasi wéb anu ditulis dina python, dimana pangguna ngatur infrastruktur sareng jasa na.
Aplikasi pagawe (saterusna ngan saukur worker) - dina jasa OpenStack, ieu mangrupikeun daemon infrastruktur anu ngamungkinkeun anjeun nyiarkeun paréntah API kana infrastruktur. Contona, kreasi disk lumangsung dina worker, sarta pamundut kreasi lumangsung dina API aplikasi.
Arsitéktur Aplikasi OpenStack Standar
Seuseueurna jasa anu dikembangkeun pikeun OpenStack nyobian nuturkeun paradigma tunggal. Hiji layanan biasana diwangun ku 2 bagian: API jeung pagawe (backend executors). Sakumaha aturan, API mangrupikeun aplikasi WSGI dina python, anu diluncurkeun boh salaku prosés mandiri (daemon), atanapi nganggo server wéb Nginx atanapi Apache anu siap-siap. API ngolah pamundut pamaké sarta ngaliwatan parentah salajengna ka aplikasi worker pikeun palaksanaan. Transperna lumangsung ngagunakeun calo pesen, biasana RabbitMQ, anu sanésna henteu didukung. Nalika pesen dugi ka calo, aranjeunna diolah ku pagawé sareng, upami diperyogikeun, uih deui réspon.
Paradigma ieu ngalibatkeun titik gagalna anu terasing: RabbitMQ sareng pangkalan data. Tapi RabbitMQ diisolasi dina hiji layanan sareng, dina tiori, tiasa individu pikeun tiap jasa. Janten di MCS kami misahkeun jasa ieu sabisa-bisa; pikeun tiap proyék individu kami nyiptakeun database anu misah, RabbitMQ anu misah. Pendekatan ieu alus sabab dina acara kacilakaan di sababaraha titik rentan, teu sakabéh jasa ngarecah, tapi ngan bagian tina eta.
Jumlah aplikasi worker henteu kawates, jadi API bisa kalayan gampang skala horizontal balik balancers guna ngaronjatkeun kinerja sarta kasabaran sesar.
Sababaraha jasa ngabutuhkeun koordinasi dina jasa nalika operasi sequential kompléks lumangsung antara API jeung pagawe. Dina hal ieu, dipaké hiji puseur koordinasi tunggal, sistem klaster kayaning Redis, Memcache, jsb, anu ngamungkinkeun hiji pagawe pikeun ngabejaan sejen yen tugas ieu ditugaskeun ka anjeunna ("punten ulah nyandak eta"). Kami nganggo jsb. Sakumaha aturan, pagawé aktip komunikasi sareng database, nyerat sareng maca inpormasi ti dinya. Kami nganggo mariadb salaku pangkalan data, anu aya dina klaster multimaster.
Ladenan tunggal klasik ieu diatur dina cara anu ditarima sacara umum pikeun OpenStack. Éta tiasa dianggap salaku sistem katutup, dimana metode skala sareng kasabaran sesar cukup jelas. Contona, pikeun kasabaran sesar API, cukup nempatkeun balancer di hareup aranjeunna. Scaling pagawe kahontal ku ngaronjatna jumlah maranéhanana.
Titik lemah dina sakabéh skéma nyaéta RabbitMQ sareng MariaDB. Arsitéktur maranéhanana pantes artikel misah.Dina artikel ieu abdi hoyong difokuskeun toleransi sesar API.
Arsitéktur Aplikasi Openstack. Balancing sareng kasabaran lepat tina platform awan
Nyieun HAProxy balancer lepat-tolerant maké ExaBGP
Pikeun ngajantenkeun API urang tiasa diskalakeun, gancang sareng toleran kasalahan, kami nempatkeun penyeimbang beban di payuneunana. Kami milih HAProxy. Dina pamadegan mah, eta boga sagala ciri dipikabutuh pikeun tugas urang: balancing dina sababaraha tingkat OSI, a panganteur manajemén, kalenturan na scalability, angka nu gede ngarupakeun métode balancing, rojongan pikeun tabel sési.
Masalah kahiji anu kedah direngsekeun nyaéta kasabaran kasalahan tina panyimbang sorangan. Kantun masang pangimbang ogé nyiptakeun titik gagal: pangimbang rusak sareng jasa nabrak. Pikeun nyegah ieu kajadian, kami nganggo HAProxy sareng ExaBGP.
ExaBGP ngamungkinkeun anjeun pikeun nerapkeun mékanisme pikeun mariksa kaayaan jasa. Kami nganggo mékanisme ieu pikeun pariksa fungsionalitas HAProxy sareng, upami aya masalah, mareuman jasa HAProxy ti BGP.
Skéma ExaBGP+HAProxy
- Kami masang parangkat lunak anu diperyogikeun, ExaBGP sareng HAProxy, dina tilu server.
- Urang nyieun panganteur loopback on unggal server.
- Dina sadaya tilu server kami napelkeun alamat IP bodas sami ka panganteur ieu.
- Alamat IP bodas diémbarkeun ka Internét via ExaBGP.
Kasabaran kasalahan kahontal ku iklan alamat IP anu sami tina tilu server. Tina sudut pandang jaringan, alamat anu sami tiasa diaksés tina tilu hops salajengna anu béda. Router nilik tilu ruteu idéntik, milih prioritas pangluhurna di antarana dumasar kana métrik sorangan (ieu biasana pilihan sarua), sarta lalulintas mana ngan ka salah sahiji server.
Upami aya masalah sareng operasi HAProxy atanapi kagagalan server, ExaBGP ngeureunkeun ngumumkeun rute, sareng lalu lintas lancar ngalih ka server anu sanés.
Ku kituna, urang ngahontal toleransi lepat tina balancer.
Kasabaran lepat tina HAProxy balancers
Skéma éta tétéla henteu sampurna: urang diajar kumaha cagar HAProxy, tapi henteu diajar kumaha ngadistribusikaeun beban dina jasa. Ku alatan éta, urang ngalegaan skéma ieu saeutik: urang pindah ka kasaimbangan antara sababaraha alamat IP bodas.
Balancing dumasar kana DNS tambah BGP
Isu balancing beban pikeun HAProxy kami tetep teu direngsekeun. Nanging, éta tiasa direngsekeun saderhana, sapertos anu urang lakukeun di dieu.
Pikeun nyaimbangkeun tilu server anjeun peryogi 3 alamat IP bodas sareng DNS lami anu saé. Unggal alamat ieu ditangtukeun dina panganteur loopback unggal HAProxy sarta diémbarkeun ka Internét.
Dina OpenStack, pikeun ngatur sumber daya, diréktori jasa dianggo, anu netepkeun API titik tungtung tina jasa anu tangtu. Dina diréktori ieu urang ngadaptar ngaran domain - public.infra.mail.ru, nu direngsekeun ngaliwatan DNS ku tilu alamat IP béda. Hasilna, urang meunang distribusi beban antara tilu alamat via DNS.
Tapi saprak nalika ngumumkeun alamat IP bodas urang teu ngadalikeun prioritas pilihan server, ieu teu balancing acan. Ilaharna, ngan hiji server bakal dipilih dumasar kana alamat IP senioritas, sarta dua lianna bakal dianggurkeun sabab euweuh metrics dieusian dina BGP.
Urang mimitian ngirim rute via ExaBGP kalawan metrics béda. Unggal balancer advertises sakabeh tilu alamat IP bodas, tapi salah sahijina, nu utama pikeun balancer ieu, diémbarkeun ku métrik minimum. Janten samentawis sadaya tilu pangimbang dijalankeun, telepon ka alamat IP anu munggaran angkat ka pangimbang kahiji, nelepon ka kadua ka kadua, sareng nelepon ka katilu ka katilu.
Naon kajadian nalika salah sahiji balancers ragrag? Upami aya pangimbang anu gagal, alamat utamana masih diémbarkeun ti dua anu sanés, sareng lalu lintas disebarkeun deui diantara aranjeunna. Ku kituna, urang masihan pamaké sababaraha alamat IP sakaligus via DNS. Ku saimbang ku DNS sareng métrik anu béda, urang nampi distribusi beban anu rata dina sadaya tilu pangimbang. Sareng dina waktos anu sami urang henteu kaleungitan kasabaran kasalahan.
Balancing HAProxy dumasar kana DNS + BGP
Interaksi antara ExaBGP sareng HAProxy
Janten, urang ngalaksanakeun toleransi sesar upami server angkat, dumasar kana ngeureunkeun pengumuman rute. Tapi HAProxy tiasa mareuman alesan sanés tina kagagalan server: kasalahan administrasi, gagal dina jasa. Kami hoyong nyabut kasaimbangan anu rusak tina handapeun beban dina kasus ieu ogé, sareng kami peryogi mékanisme anu béda.
Ku alatan éta, ngembangna skéma saméméhna, urang nerapkeun keteg jajantung antara ExaBGP na HAProxy. Ieu palaksanaan software interaksi antara ExaBGP na HAProxy, lamun ExaBGP ngagunakeun Aksara custom pikeun pariksa status tina aplikasi.
Jang ngalampahkeun ieu, anjeun kudu ngonpigurasikeun hiji checker kaséhatan dina config ExaBGP, nu bisa pariksa status HAProxy. Dina kasus urang, urang ngonpigurasi backend kaséhatan di HAProxy, sarta ti sisi ExaBGP urang pariksa ku pamundut GET basajan. Upami pengumumanna lirén, maka HAProxy sigana henteu tiasa dianggo sareng henteu kedah ngiklankeunana.
Cék Kaséhatan HAProxy
HAProxy Peers: sinkronisasi sési
Hal salajengna anu kedah dilakukeun nyaéta nyinkronkeun sesi. Nalika digawé ngaliwatan balancers disebarkeun, hese ngatur neundeun informasi ngeunaan sesi klien. Tapi HAProxy mangrupikeun salah sahiji ti saeutik pangimbang anu tiasa ngalakukeun ieu kusabab fungsionalitas Peers - kamampuan pikeun mindahkeun tabel sési antara prosés HAProxy anu béda.
Aya metode balancing anu béda: anu saderhana sapertos , sarta ngalegaan, nalika sési klien urang inget, sarta unggal waktos anjeunna ends up on server sarua sakumaha saméméhna. Urang hayang nerapkeun pilihan kadua.
HAProxy ngagunakeun iteuk-tabel pikeun nyimpen sesi klien mékanisme ieu. Aranjeunna ngahemat alamat IP asli klien, alamat target anu dipilih (backend) sareng sababaraha inpormasi jasa. Ilaharna, tabel iteuk dipaké pikeun nyimpen hiji sumber-IP + tujuan-IP pasangan, nu hususna kapaké pikeun aplikasi nu teu bisa mindahkeun konteks sési pamaké nalika pindah ka balancer sejen, Contona, dina mode balancing RoundRobin.
Lamun tabel iteuk diajar mindahkeun antara prosés HAProxy béda (antara nu balancing lumangsung), balancers urang bakal tiasa dianggo kalayan hiji kolam renang tabel iteuk. Ieu bakal ngamungkinkeun pikeun mindahkeun jaringan klien sacara lancar upami salah sahiji pangimbang gagal; damel sareng sesi klien bakal diteruskeun dina tonggong anu sami anu dipilih sateuacana.
Pikeun operasi anu leres, masalah alamat IP sumber tina balancer ti mana sési didirikan kedah direngsekeun. Dina hal urang, ieu alamat dinamis dina panganteur loopback.
Karya bener tina peers kahontal ngan dina kaayaan nu tangtu. Hartina, TCP timeouts kudu cukup badag atawa switching kudu cukup gancang ku kituna sési TCP teu boga waktu pikeun nungtungan. Sanajan kitu, éta ngamungkinkeun pikeun switching seamless.
Dina IaaS kami ngagaduhan jasa anu diwangun nganggo téknologi anu sami. Ieu , nu disebut Octavia. Ieu dumasar kana dua prosés HAProxy sarta mimitina ngawengku rojongan pikeun peers. Aranjeunna geus ngabuktikeun dirina alus teuing di layanan ieu.
Gambar schematically nembongkeun gerakan tabel peer antara tilu instansi HAProxy, config diusulkeun on kumaha ieu bisa ngonpigurasi:
HAProxy Peers (sinkronisasi sési)
Upami anjeun ngalaksanakeun skéma anu sami, operasina kedah diuji sacara saksama. Éta sanés kanyataan yén éta bakal tiasa dianggo dina cara anu sami 100% waktos. Tapi sahenteuna anjeun moal kaleungitan tabel iteuk nalika anjeun kedah émut IP sumber klien.
Ngawatesan jumlah requests simultaneous ti klien sarua
Sakur jasa anu sayogi umum, kalebet API kami, tiasa tunduk kana paménta longsoran. Alesan pikeun aranjeunna tiasa béda-béda, tina kasalahan pangguna dugi ka serangan anu dituju. Kami périodik DDoSed ku alamat IP. Klién sering ngalakukeun kasalahan dina naskahna sareng masihan kami mini-DDoSs.
Hiji cara atanapi anu sanés, panyalindungan tambahan kedah disayogikeun. Solusi anu atra nyaéta pikeun ngawatesan jumlah pamundut API sareng henteu miceunan waktos CPU ngolah pamundut jahat.
Pikeun nerapkeun larangan sapertos, kami nganggo wates laju, diatur dina dasar HAProxy, ngagunakeun tabel iteuk sarua. Nyetel wates cukup basajan tur ngidinan Anjeun pikeun ngawatesan pamaké ku Jumlah requests ka API. Algoritma nginget IP sumber ti mana pamenta didamel sareng ngabatesan jumlah pamundut sakaligus ti hiji pangguna. Tangtosna, urang ngitung profil beban API rata-rata pikeun tiap jasa sareng nyetél wates ≈ 10 kali nilai ieu. Urang terus-terusan ngawas kaayaan sareng ngajaga ramo dina pulsa.
Naon rupa ieu dina prakna? Kami ngagaduhan palanggan anu ngagunakeun API autoscaling kami sepanjang waktos. Aranjeunna nyiptakeun kira-kira dua dugi ka tilu ratus mesin virtual isuk-isuk sareng ngahapusna magrib. Pikeun OpenStack, nyieun mesin virtual, ogé kalayan layanan PaaS, merlukeun sahenteuna 1000 requests API, saprak interaksi antara jasa ogé lumangsung ngaliwatan API.
Mindahkeun tugas sapertos kitu nyababkeun beban anu lumayan ageung. Urang ditaksir beban ieu, dikumpulkeun puncak poean, ngaronjatna sapuluh kali lipat, sarta ieu jadi wates laju urang. Urang nyimpen ramo urang dina pulsa. Urang mindeng ningali bot na scanner anu nyobian kasampak di urang pikeun nempo lamun urang boga Aksara CGA nu bisa dijalankeun, kami aktip motong aranjeunna.
Kumaha ngapdet basis kode anjeun tanpa perhatikeun pangguna
Urang ogé nerapkeun kasabaran kasalahan dina tingkat prosés panyebaran kode. Bisa jadi aya gangguan salila rollouts, tapi dampak maranéhanana dina kasadiaan jasa bisa minimal.
Kami terus-terusan ngamutahirkeun jasa kami sareng kedah mastikeun yén basis kode diropéa tanpa mangaruhan pangguna. Kami junun ngabéréskeun masalah ieu nganggo kamampuan manajemén HAProxy sareng palaksanaan Graceful Shutdown dina jasa kami.
Pikeun ngajawab masalah ieu, perlu pikeun mastikeun kontrol balancer jeung "bener" shutdown tina jasa:
- Dina kasus HAProxy, kontrol dipigawé ngaliwatan file stats, nu dasarna stop kontak sarta didefinisikeun dina config HAProxy. Anjeun tiasa ngirim paréntah ka éta via stdio. Tapi alat kontrol konfigurasi utama urang téh ansible, ku kituna mibanda modul diwangun-di pikeun ngatur HAProxy. Anu kami aktip dianggo.
- Seuseueurna jasa API sareng Mesin kami ngadukung téknologi pareum anu saé: nalika mareuman, aranjeunna ngantosan tugas ayeuna parantos réngsé, janten pamundut http atanapi sababaraha tugas jasa. Hal anu sarua kajadian jeung pagawe. Éta terang sadaya pancén anu di lakukeun sareng ditungtungan nalika parantos suksés réngsé sadayana.
Hatur nuhun kana dua titik ieu, algoritma anu aman pikeun panyebaran urang sapertos kieu.
- Pamekar ngumpul pakét kode anyar (kanggo urang ieu RPM), nguji éta di lingkungan dev, nguji éta di panggung, sarta ninggalkeun eta dina Repository panggung.
- Pamekar netepkeun tugas pikeun panyebaran sareng katerangan anu paling detil ngeunaan "artefak": versi pakét énggal, pedaran fungsionalitas énggal sareng detil sanésna ngeunaan panyebaran upami diperyogikeun.
- Administrator sistem ngamimitian apdet. Ngajalankeun buku play Ansible, anu salajengna ngalakukeun ieu:
- Nyokot pakét ti gudang panggung tur ngagunakeun eta pikeun ngapdet versi pakét dina gudang produk.
- Compiles daptar backends tina jasa diropéa.
- Mareuman layanan pangheulana diropéa dina HAProxy sareng ngantosan prosésna réngsé. Hatur nuhun kana shutdown anggun, kami yakin yén sakabéh requests klien ayeuna bakal ngalengkepan junun.
- Saatos API sareng pagawe parantos dieureunkeun, sareng HAProxy dipareuman, kodeu diropéa.
- Ansible ngajalankeun jasa.
- Pikeun unggal jasa, "cekelan" tinangtu ditarik, anu ngalaksanakeun tés unit dina sababaraha tés konci anu tos ditetepkeun. A dipariksa dasar kode anyar lumangsung.
- Upami teu aya kasalahan anu kapendak dina léngkah sateuacana, backend diaktipkeun.
- Hayu urang ngaléngkah ka backend salajengna.
- Saatos sadaya backends diropéa, tés fungsional diluncurkeun. Upami aranjeunna leungit, maka pamekar ningali fungsionalitas énggal anu anjeunna ciptakeun.
Ieu ngalengkepan deployment.
Siklus update jasa
Skéma ieu moal jalan mun urang teu boga hiji aturan. Urang ngarojong duanana versi heubeul jeung anyar dina perangna. Sateuacanna, dina tahap pamekaran parangkat lunak, ditetepkeun yén sanajan aya parobihan dina pangkalan data jasa, aranjeunna moal ngarobih kodeu sateuacana. Hasilna, dasar kode ieu laun diropéa.
kacindekan
Ngabagikeun pamikiran kuring sorangan ngeunaan arsitéktur WEB anu toleran lepat, kuring hoyong sakali deui perhatikeun titik konci na:
- kasabaran kasalahan fisik;
- kasabaran jaringan kasalahan (balancers, BGP);
- kasabaran kasalahan tina parangkat lunak anu dianggo sareng dikembangkeun.
Uptime stabil sadayana!
sumber: www.habr.com
