Kumusta, Habr! Ako si Artem Karamyshev, pangulo sa systems administration team. Daghan na mig gilunsad nga mga bag-ong produkto sa miaging tuig. Gusto namo nga ang among mga serbisyo sa API dali ra ma-scalable, dili dali maapektuhan sa mga sayop, ug andam na alang sa paspas nga pagtubo sa user load. Ang among plataporma gitukod sa OpenStack, ug gusto nakong ipaambit ang pipila sa mga isyu sa fault-tolerance sa mga component nga kinahanglan namong sulbaron aron makab-ot ang usa ka fault-tolerant system. Sa akong hunahuna kini makapainteres sa mga nagpalambo usab og mga produkto sa OpenStack.
Ang kinatibuk-ang kalig-on sa plataporma nagdepende sa kalig-on sa mga sangkap niini. Busa, hinay-hinay natong tun-an ang tanang mga lut-od diin atong nailhan ug natubag ang mga risgo.
Usa ka video nga bersyon niini nga istorya, ang orihinal nga tinubdan niini gikan sa usa ka presentasyon sa Uptime day 4 conference, nga giorganisar sa , pwede nimo tan-awon .
Pagtugot sa sayop sa pisikal nga arkitektura
Ang publikong bahin sa MCS cloud karon nahimutang sa duha ka Tier III data center, nga konektado sa usa ka dedikado nga dark fiber network nga adunay managlahing pisikal nga redundancies ug throughput nga 200 Gbps. Ang Tier III naghatag sa gikinahanglan nga lebel sa fault tolerance para sa pisikal nga imprastraktura.
Ang dark fiber kay redundant sa pisikal ug lohikal nga lebel. Ang proseso sa channel redundancy kay balik-balik lang, ug bisan pa man og adunay mga problema nga mitumaw, padayon namong gipaayo ang koneksyon tali sa mga data center.
Pananglitan, dili pa lang dugay, samtang nagtrabaho sa usa ka atabay duol sa usa sa among mga data center, usa ka excavator ang nakabuslot sa usa ka tubo, nga adunay sulod nga panguna ug backup nga fiber optic cable. Ang among fail-safe nga communication channel sa data center naapektuhan sa usa ka punto, ang atabay. Tungod niini, nawad-an kami og bahin sa among imprastraktura. Nakakat-on kami gikan niini ug mihimo og daghang mga aksyon, lakip ang pag-instalar og dugang nga fiber optic cable sa silingang atabay.
Ang among mga data center adunay mga punto sa presensya para sa mga telecom provider, diin among gipa-broadcast ang among mga prefix pinaagi sa BGP. Ang pinakamaayong sukdanan gipili para sa matag direksyon sa network, nga nagtugot kanamo sa paghatag sa pinakamaayong kalidad sa koneksyon sa lain-laing mga kliyente. Kon ang koneksyon pinaagi sa usa ka provider mabalda, among gi-reconfigure ang among routing pinaagi sa mga available nga provider.
Kon mapakyas ang usa ka provider, awtomatiko kaming mobalhin sa sunod nga provider. Kon mapakyas ang usa ka data center, naa miy kopya sa among mga serbisyo sa ikaduhang data center, nga mao ang modawat sa tibuok load.
Kalig-on sa pisikal nga imprastraktura
Unsay among gigamit para sa application-level fault tolerance
Ang among serbisyo gibase sa daghang mga opensource nga sangkap.
ExaBGP — usa ka serbisyo nga nagpatuman sa daghang mga gimbuhaton gamit ang BGP-based dynamic routing protocol. Aktibo namong gigamit kini aron i-advertise ang among mga whitelisted IP address, diin ang mga tiggamit maka-access sa API.
HAProxy — usa ka high-load load balancer nga nagtugot kanimo sa pag-configure sa mga lagda sa pagbalanse sa trapiko nga flexible kaayo sa lainlaing mga layer sa modelo sa OSI. Gigamit namo kini alang sa pagbalanse sa load sa tanan nga mga serbisyo: mga database, mga message broker, mga serbisyo sa API, mga serbisyo sa web, ug ang among mga internal nga proyekto—tanan gipadagan sa HAProxy.
Aplikasyon sa API — usa ka web application nga gisulat sa Python, diin ang tiggamit nagdumala sa ilang imprastraktura, sa ilang serbisyo.
Aplikasyon sa trabahante (dinhi tawgon lang nga worker) usa ka infrastructure daemon sa OpenStack services nga nagtugot sa mga API command nga ipadala ngadto sa infrastructure. Pananglitan, ang paghimo og disk mahitabo sa usa ka worker, ug ang creation request ipadala ngadto sa API application.
Sumbanan nga Arkitektura sa Aplikasyon sa OpenStack
Kadaghanan sa mga serbisyo nga gihimo para sa OpenStack naningkamot sa pagsunod sa usa ka nahiusang paradigma. Ang usa ka serbisyo kasagaran gilangkoban sa duha ka bahin: usa ka API ug mga worker (backend executors). Kasagaran, ang API usa ka aplikasyon sa WSGI nga gisulat sa Python, nga modagan isip usa ka standalone nga proseso (daemon) o gamit ang usa ka web server sama sa Nginx o Apache. Ang API moproseso sa hangyo sa tiggamit ug mopasa sa dugang nga mga instruksyon ngadto sa aplikasyon sa trabahante para sa pagpatuman. Kini nga pagpadala mahitabo pinaagi sa usa ka message broker, kasagaran RabbitMQ; ang ubang mga tipo dili maayo nga gisuportahan. Kung ang mga mensahe makaabot sa broker, ang mga trabahante moproseso niini ug, kung kinahanglan, mobalik og tubag.
Kini nga paradigma nagpasabot sa nahimulag nga komon nga mga punto sa kapakyasan: ang RabbitMQ ug ang database. Bisan pa, ang RabbitMQ nahimulag sulod sa usa ka serbisyo ug, sa teorya, mahimong espesipiko sa matag serbisyo. Busa, sa MCS, among gibulag kini nga mga serbisyo kutob sa mahimo, nga naghimo og usa ka lahi nga database ug usa ka lahi nga RabbitMQ alang sa matag indibidwal nga proyekto. Kini nga pamaagi mapuslanon tungod kay kung ang usa ka kapakyasan mahitabo sa usa ka mahuyang nga punto, usa lamang ka bahin sa serbisyo, dili ang tibuuk nga serbisyo, ang maapektuhan.
Walay limitasyon sa gidaghanon sa mga aplikasyon sa mga trabahante, busa ang API dali nga ma-scale nga pinahigda sa luyo sa mga balancer aron madugangan ang performance ug fault tolerance.
Ang ubang mga serbisyo nanginahanglan og intra-service coordination—kung ang komplikado nga sunod-sunod nga mga operasyon mahitabo tali sa mga API ug mga trabahante. Niini nga kaso, usa ra ka coordination center ang gigamit, usa ka cluster system sama sa Redis, Memcache, etcd, nga nagtugot sa usa ka trabahante sa pagsulti sa lain nga ang usa ka buluhaton gi-assign kanila ("palihug ayaw kini kuhaa"). Gigamit namo ang etcd. Kasagaran, ang mga trabahante aktibong nakigkomunikar sa database, nagsulat ug nagbasa sa impormasyon gikan niini. Gigamit namo ang mariadb isip among database, nga nahimutang sa among multi-master cluster.
Kining klasiko nga single service giorganisar sa paagi nga kasagarang gidawat para sa OpenStack. Mahimo kining tan-awon isip usa ka closed system, nga adunay prangka nga scaling ug fault-tolerance options. Pananglitan, aron masiguro ang API fault-tolerance, ibutang lang ang load balancer sa atubangan sa API. Ang worker scaling makab-ot pinaagi sa pagdugang sa ilang gidaghanon.
Ang mga kahuyang sa tibuok nga laraw mao ang RabbitMQ ug MariaDB. Ang ilang arkitektura angay nga hisgotan sa laing artikulo. Niini nga artikulo, gusto nakong mag-focus sa API fault tolerance.
Arkitektura sa Aplikasyon sa OpenStack: Pagbalanse ug Pagkamatugtanon sa Sayop para sa usa ka Cloud Platform
Paghimo sa HAProxy Load Balancer nga Fault-Tolerant gamit ang ExaBGP
Aron masiguro nga ang among mga API kay scalable, paspas, ug fault-tolerant, nag-instalar kami og load balancer. Gipili namo ang HAProxy. Sa akong opinyon, kini adunay tanan nga gikinahanglan nga mga kinaiya para sa among mga panginahanglan: load balancing sa daghang OSI layers, usa ka management interface, flexibility ug scalability, usa ka halapad nga mga pamaagi sa load balancing, ug suporta sa session table.
Ang unang problema nga kinahanglan sulbaron mao ang fault tolerance sa load balancer mismo. Ang pag-instalar lang sa load balancer makamugna og usa ka punto sa kapakyasan: kon mapakyas ang load balancer, ang serbisyo ma-down. Aron malikayan kini, among gigamit ang HAProxy kauban ang ExaBGP.
Ang ExaBGP nagpahimo og mekanismo sa pagsusi sa kahimtang sa serbisyo. Gigamit namo kini nga mekanismo aron masusi ang kahimtang sa HAProxy ug, kung adunay motumaw nga mga problema, aron i-disable ang serbisyo sa HAProxy gikan sa BGP.
Eskema sa ExaBGP+HAProxy
- Among gi-install ang gikinahanglan nga software, ang ExaBGP ug HAProxy, sa tulo ka server.
- Naghimo mig loopback interface sa matag server.
- Sa tanang tulo ka server, parehas ra ang puti nga IP address nga among girehistro niini nga interface.
- Ang puti nga IP address gipahibalo sa Internet pinaagi sa ExaBGP.
Ang fault tolerance makab-ot pinaagi sa pag-advertise sa parehas nga IP address gikan sa tanang tulo ka server. Gikan sa perspektibo sa network, ang parehas nga address ma-access gikan sa tulo ka lain-laing sunod nga hops. Ang router makakita og tulo ka parehas nga ruta, mopili sa pinakataas nga prayoridad nga ruta base sa kaugalingon niining metric (kasagaran parehas nga ruta), ug ang trapiko i-ruta ngadto sa usa lang sa mga server.
Kon adunay mga problema sa HAProxy o pagkapakyas sa server, ang ExaBGP mohunong sa pag-advertise sa ruta, ug ang trapiko hapsay nga mabalhin ngadto sa laing server.
Niining paagiha, nakab-ot namo ang fault tolerance sa balancer.
Pagtugot sa Sayop sa HAProxy Load Balancer
Dili perpekto ang setup: nakakat-on mi unsaon pag-backup sa HAProxy, pero wala mi nakakat-on unsaon pag-apod-apod sa load sa mga serbisyo. Mao nga among gipalapdan gamay ang setup, nibalhin sa load balancing sa daghang public IP addresses.
Pagbalanse sa load nga nakabase sa DNS ug BGP
Ang isyu sa load balancing atubangan sa atong HAProxy wala pa masulbad. Apan, dali ra kini masulbad, sama sa atong gibuhat sa atong kaugalingon.
Para mabalanse ang tulo ka server, kinahanglan nimo ang tulo ka public IP address ug maayong DNS. Ang matag usa niini nga mga address gi-assign sa loopback interface sa matag HAProxy ug gi-advertise sa internet.
Ang OpenStack mogamit og service catalog aron pagdumala sa mga resources, nga maoy mo-define sa API endpoint para sa matag serbisyo. Niini nga catalog, atong i-specify ang usa ka domain name—public.infra.mail.ru—nga mo-resolve pinaagi sa DNS ngadto sa tulo ka lain-laing IP addresses. Kini moresulta sa load balancing sa tulo ka addresses gamit ang DNS.
Apan, tungod kay dili namo makontrol ang mga prayoridad sa pagpili sa server sa pag-anunsyo sa mga whitelisted IP address, wala pa kini mabalanse. Kasagaran, usa ra ka server ang pilion base sa pinakataas nga IP address, samtang ang laing duha magpabilin nga idle tungod kay walay mga sukdanan nga gitino sa BGP.
Nagsugod na mi og apod-apod sa mga ruta pinaagi sa ExaBGP nga adunay lain-laing mga sukdanan. Ang matag load balancer nag-advertise sa tanang tulo ka whitelisted nga mga IP address, apan ang usa niini, ang pangunang IP address para sa maong load balancer, gi-advertise nga adunay minimum nga sukdanan. Busa, samtang ang tanang tulo ka load balancer naglihok, ang mga hangyo sa unang IP address moadto sa unang load balancer, ang mga hangyo sa ikaduha ngadto sa ikaduha, ug ang mga hangyo sa ikatulo ngadto sa ikatulo.
Unsay mahitabo kon ang usa sa mga load balancer mapakyas? Kon ang bisan unsang load balancer mapakyas, ang pangunang address niini ipahibalo gihapon sa laing duha, ug ang trapiko iapod-apod pag-usab taliwala kanila. Niining paagiha, makahatag kita sa tiggamit og daghang IP address pinaagi sa DNS. Pinaagi sa pagbalanse pinaagi sa DNS ug lain-laing mga sukdanan, makab-ot nato ang patas nga pag-apod-apod sa load sa tanang tulo ka load balancer, samtang gipadayon ang fault tolerance.
Pagbalanse sa Load sa HAProxy gamit ang DNS ug BGP
Interaksyon tali sa ExaBGP ug HAProxy
Mao nga, among gipatuman ang failover protection batok sa server downtime pinaagi sa paghunong sa mga anunsyo sa ruta. Apan ang HAProxy mahimong ma-down tungod sa mga hinungdan gawas sa pagkapakyas sa server: mga sayop sa administrasyon, mga pagkapakyas sa internal nga serbisyo. Gusto usab namong tangtangon ang na-down nga load balancer gikan sa load balancing niini nga mga kaso, busa kinahanglan namon ang lahi nga mekanismo.
Busa, sa pagpalapad sa miaging eskema, among gipatuman ang usa ka heartbeat tali sa ExaBGP ug HAProxy. Kini usa ka software implementation sa interaksyon tali sa ExaBGP ug HAProxy, diin ang ExaBGP naggamit ug custom scripts aron masusi ang status sa mga aplikasyon.
Aron mahimo kini, kinahanglan nimong i-configure ang usa ka health checker sa ExaBGP configuration nga makasusi sa status sa HAProxy. Sa among kaso, among gi-configure ang usa ka health backend sa HAProxy, ug sa bahin sa ExaBGP, among gisusi gamit ang usa ka yano nga GET request. Kung mohunong ang announcement, ang HAProxy lagmit nga down ug dili kinahanglan nga i-advertise.
Pagsusi sa Panglawas sa HAProxy
Mga Kauban sa HAProxy: Pag-synchronize sa Sesyon
Ang sunod nga buhaton mao ang pag-synchronize sa mga sesyon. Kung nagtrabaho gamit ang mga distributed load balancer, lisod ang pagtipig sa impormasyon sa client session. Apan ang HAProxy usa sa pipila ka load balancer nga makahimo niini tungod sa Peers feature niini, nga nagtugot sa session table nga ipaambit taliwala sa lain-laing mga proseso sa HAProxy.
Adunay lain-laing mga pamaagi sa pagbalanse: mga yano, sama sa , ug mga gipalugway, diin ang sesyon sa kliyente mahinumduman ug sila ipadala sa parehas nga server matag higayon. Gusto namong ipatuman ang ikaduha nga kapilian.
Ang HAProxy mogamit og stick tables aron tipigan ang client sessions. Gitipigan nila ang source IP address sa kliyente, ang napili nga target address (backend), ug pipila ka impormasyon sa serbisyo. Ang stick tables kasagarang gigamit sa pagtipig sa source-IP ug destination-IP pairs, nga labi ka mapuslanon alang sa mga aplikasyon nga dili makabalhin sa konteksto sa user session kung mobalhin sa lahi nga load balancer, sama sa RoundRobin load balancing mode.
Pinaagi sa pagtudlo sa stick table sa pagbalhin-balhin tali sa lain-laing mga proseso sa HAProxy (diin nahitabo ang load balancing), ang atong mga load balancer makahimo sa pagtrabaho uban sa usa ka pool sa stick tables. Kini makapahimo sa seamless client network failover kung ang usa ka load balancer mapakyas, ug ang mga client session magpadayon sa pagserbisyo sa parehas nga mga backend nga kaniadto gipili.
Para sa hustong operasyon, kinahanglan nga masulbad ang isyu sa source IP address sa load balancer diin gitukod ang session. Sa atong kaso, kini usa ka dynamic address sa loopback interface.
Ang mga peer mogana lang og tarong ubos sa pipila ka mga kondisyon. Sa piho, ang mga TCP timeout kinahanglan nga igo ang gitas-on, o ang switchover kinahanglan nga igo ang katulin aron mapugngan ang pagtapos sa TCP session. Bisan pa niana, kini nagtugot sa hapsay nga pagbalhin.
Naa mi serbisyo sa IaaS nga gihimo gamit ang parehas nga teknolohiya. , gitawag og Octavia. Kini gibase sa duha ka proseso sa HAProxy ug adunay lumad nga suporta para sa mga kaedad. Napamatud-an nila ang ilang kaugalingon nga maayo kaayo alang niini nga serbisyo.
Ang hulagway eskematikong naghulagway sa paglihok sa mga peer table taliwala sa tulo ka HAProxy instances, ug usa ka configuration ang gihatag aron ipakita kung giunsa kini ma-set up:
Mga Kauban sa HAProxy (pag-synchronize sa sesyon)
Kon mogamit kag susamang pamaagi, kinahanglan nimo kining sulayan pag-ayo. Dili kini garantiya nga mogana og 100% sa tanang panahon. Apan labing menos dili mawala ang imong sticky tables kon kinahanglan nimong hinumdoman ang source IP sa kliyente.
Limitahan ang gidaghanon sa dungan nga mga hangyo gikan sa parehas nga kliyente
Ang bisan unsang serbisyo nga magamit sa publiko, lakip ang among mga API, mahimong maapektuhan sa daghang mga hangyo. Ang mga hinungdan mahimong magkalainlain, gikan sa mga sayop sa tiggamit hangtod sa mga gitarget nga pag-atake. Matag karon ug unya, makasinati kami og mga pag-atake sa IP DDoS. Ang mga kliyente kanunay nga makahimo og mga sayop sa ilang mga script, nga hinungdan sa mga mini-DDoS nga pag-atake.
Bisan hain nga paagi, gikinahanglan ang dugang nga mga lakang sa seguridad. Usa ka klaro nga solusyon mao ang paglimita sa gidaghanon sa mga hangyo sa API ug paglikay sa pag-usik sa oras sa CPU sa pagproseso sa mga malisyosong hangyo.
Aron mapatuman kini nga mga restriksyon, among gigamit ang mga rate limit nga gitukod sa HAProxy gamit ang parehas nga stick tables. Ang mga limit dali ra i-configure ug nagtugot kanimo sa paglimite sa gidaghanon sa mga API request nga mahimo sa usa ka user. Ang algorithm nahinumdom sa source IP diin gihimo ang mga request ug gilimitahan ang gidaghanon sa dungan nga mga request matag user. Natural lang, among gikalkulo ang average nga API load profile para sa matag serbisyo ug nagbutang og limit nga gibana-bana nga 10 ka pilo nga mas taas kaysa niini nga kantidad. Padayon namong gibantayan pag-ayo ang sitwasyon, nga nagbantay sa pulso.
Giunsa kini molihok sa praktis? Kami adunay mga kustomer nga kanunay nga naggamit sa among mga API alang sa autoscaling. Naghimo sila og gibana-bana nga duha ngadto sa tulo ka gatos nga mga virtual machine sa buntag ug gitangtang kini sa gabii. Alang sa OpenStack, ang paghimo og virtual machine, labi na sa mga serbisyo sa PaaS, nanginahanglan labing menos 1000 nga mga hangyo sa API, tungod kay ang mga interaksyon tali sa mga serbisyo mahitabo usab pinaagi sa mga API.
Kining mga pagbalhin sa buluhaton makamugna og dakong karga. Among gisusi kini nga karga, gikolekta ang adlaw-adlaw nga peak, gipataas kini og napulo ka pilo, ug kini ang among nahimong limitasyon sa rate. Kanunay namong gibantayan ang among pulso. Kanunay namong makita ang mga bot ug scanner nga naningkamot sa pagtan-aw kon aduna ba kami'y mga CGA script nga mahimong ipadagan, ug aktibo namong giputol kini.
Unsaon pag-update sa imong codebase nga walay problema para sa mga tiggamit
Nagpatuman usab kami og fault tolerance sa lebel sa proseso sa pag-deploy sa code. Adunay mga kapakyasan nga mahitabo atol sa mga pag-deploy, apan ang epekto niini sa pagkaanaa sa serbisyo mahimong maminusan.
Kanunay namong gi-update ang among mga serbisyo ug kinahanglan namong sigurohon nga ang mga pag-update sa codebase gihimo nga dili makaapekto sa mga tiggamit. Nakab-ot namo kini pinaagi sa paggamit sa mga kapabilidad sa pagdumala sa HAProxy ug pagpatuman sa Graceful Shutdown sa among mga serbisyo.
Aron masulbad kini nga problema, gikinahanglan aron masiguro ang pagdumala sa balancer ug ang "sakto" nga pagsira sa serbisyo:
- Sa HAProxy, ang pagdumala gidumala pinaagi sa usa ka stats file, nga sa panguna usa ka socket nga gihubit sa HAProxy configuration file. Ang mga sugo mahimong ipasa niini pinaagi sa stdio. Bisan pa, ang among panguna nga himan sa pagdumala sa configuration mao ang Ansible, mao nga kini adunay built-in nga module alang sa pagdumala sa HAProxy, nga aktibo namong gigamit.
- Kadaghanan sa among mga serbisyo sa API ug Engine nagsuporta sa graceful shutdown: kung mag-shutdown, maghulat sila nga makompleto ang kasamtangang buluhaton, kini man usa ka HTTP request o uban pang buluhaton sa serbisyo. Parehas kini nga mahitabo sa usa ka trabahante. Nahibal-an niini ang tanan nga mga buluhaton nga iyang gihimo ug matapos kung ang tanan malampuson nga nahuman.
Tungod niining duha ka punto, ang atong secure deployment algorithm mao kini ang hitsura.
- Ang developer mohimo og bag-ong code package (sa among kaso, kini ang RPM), sulayan kini sa dev environment, sulayan kini sa stage environment, ug ibilin kini sa stage repository.
- Ang developer magbutang og deployment task nga adunay detalyado kaayong deskripsyon sa "mga artifact": ang bersyon sa bag-ong package, usa ka deskripsyon sa bag-ong functionality, ug uban pang detalye sa deployment, kon gikinahanglan.
- Ang system administrator magsugod sa pag-update. Ilang ipadagan ang Ansible playbook, nga mohimo sa mosunod:
- Mokuha og package gikan sa stage repository ug mo-update sa package version sa production repository base niini.
- Nagmugna og lista sa mga backend para sa serbisyo nga gi-update.
- Mopalong sa unang serbisyo nga gi-update sa HAProxy ug maghulat nga matapos ang mga proseso niini. Tungod sa graceful shutdown, among giseguro nga ang tanang kasamtangang hangyo sa kliyente malampusong makompleto.
- Human hingpit nga mahunong ang API ug ang mga trabahante ug mapalong ang HAProxy, ang code i-update.
- Ang Ansible magsugod sa mga serbisyo.
- Alang sa matag serbisyo, ang piho nga mga "handle" gibira nga naghimo sa unit testing batok sa usa ka serye sa mga gitakda nang daan nga mga pagsulay sa yawe. Ang sukaranan nga pag-verify sa bag-ong code mahitabo.
- Kon walay nakitang sayop sa miaging lakang, ang backend ma-activate.
- Padayon ta sa sunod nga backend.
- Human ma-update ang tanang backend, ipadagan ang mga functional test. Kon kini kulang, susihon sa developer ang bisan unsang bag-ong functionality nga ilang gipatuman.
Kini mokompleto sa deployment.
Siklo sa pag-update sa serbisyo
Dili mogana kining sistema kon wala mi usa ka lagda. Among gimentinar ang daan ug bag-ong mga bersyon sa samang higayon. Giseguro namo gikan sa sinugdanan, atol sa pagpalambo sa software, nga bisan kon adunay mga pagbag-o nga gihimo sa database sa serbisyo, dili kini makalapas sa miaging code. Tungod niini, ang codebase hinay-hinay nga gi-update.
konklusyon
Sa pagpaambit sa akong mga hunahuna bahin sa fault-tolerant web architecture, gusto nakong balikon ang mga importanteng punto niini:
- pisikal nga pagtugot sa sayop;
- pagkamatugtanon sa sayop sa network (mga tigbalanse, BGP);
- pagtugot sa sayop sa software nga gigamit ug gihimo.
Pagbaton og lig-on nga uptime sa tanan!
Source: www.habr.com
