Halló, Habr! Ég er Artem Karamyshev, yfirmaður kerfisstjórnunarteymis . Við höfum verið með margar nýjar vörur á markaðnum á síðasta ári. Við vildum tryggja að API-þjónusta væri auðstæranleg, bilanaþolin og tilbúin fyrir hraðan vöxt notendaálags. Pallurinn okkar er útfærður á OpenStack og ég vil segja þér hvaða bilanaþolsvandamál við þurftum að leysa til að fá bilunarþolið kerfi. Ég held að þetta verði áhugavert fyrir þá sem einnig þróa vörur á OpenStack.
Heildarbilunarþol palla samanstendur af seiglu íhlutanna. Þannig að við munum smám saman fara í gegnum öll stigin þar sem við greindum áhættur og lokuðum þeim.
Myndbandsútgáfa af þessari sögu, aðaluppspretta hennar var skýrsla á Uptime day 4 ráðstefnunni, skipulögð af , þú getur séð .
Seiglu eðlisfræðilegs arkitektúrs
Opinberi hluti MCS skýsins er nú byggður í tveimur Tier III gagnaverum, á milli þeirra er eigin dimm trefjar, frátekinn á líkamlegu stigi með mismunandi leiðum, með afköst upp á 200 Gbit/s. Tier III veitir nauðsynlega bilanaþol fyrir líkamlega innviði.
Dökk trefjar eru frátekin bæði á líkamlegu og rökréttu stigi. Rásapöntunarferlið var endurtekið, vandamál komu upp og við erum stöðugt að bæta samskipti milli gagnavera.
Sem dæmi má nefna að ekki alls fyrir löngu, þegar verið var að vinna í brunni nálægt einni af gagnaverunum, braut grafa rör og inni í þessari pípu var bæði aðal- og varasjónastrengur. Gallaþolin samskiptarás okkar við gagnaverið reyndist viðkvæm á einum stað, í brunninum. Í samræmi við það höfum við misst hluta af innviðum. Við drógum ályktanir og gripum til ýmissa aðgerða, þar á meðal að setja upp viðbótarljóstækni í aðliggjandi holu.
Í gagnaverum eru viðverustaður samskiptaveitna sem við sendum forskeyti okkar til í gegnum BGP. Fyrir hverja netstefnu er besta mælikvarðinn valinn, sem gerir mismunandi viðskiptavinum kleift að fá bestu tengigæði. Ef samskipti í gegnum eina þjónustuveitu fara niður, endurbyggjum við leiðina okkar í gegnum tiltæka þjónustuveitendur.
Ef veitandi mistakast skiptum við sjálfkrafa yfir í þann næsta. Komi til bilunar í einhverju gagnaveranna höfum við spegilafrit af þjónustu okkar í öðru gagnaverinu sem tekur á sig allt álagið.
Seiglu líkamlegra innviða
Það sem við notum fyrir villuþol á umsóknarstigi
Þjónustan okkar er byggð á fjölda opinna íhluta.
ExaBGP er þjónusta sem útfærir fjölda aðgerða með því að nota BGP-undirstaða dynamic routing protocol. Við notum það virkan til að auglýsa IP tölur okkar á hvítlista sem notendur fá aðgang að API.
HAProxy er mikið álagsjafnvægi sem gerir þér kleift að stilla mjög sveigjanlegar umferðarjafnvægisreglur á mismunandi stigum OSI líkansins. Við notum það til að halda jafnvægi fyrir framan alla þjónustu: gagnagrunna, skilaboðamiðlara, API þjónustu, vefþjónustu, innri verkefni okkar - allt er á bak við HAProxy.
API forrit — vefforrit skrifað í python, þar sem notandinn stjórnar innviðum sínum og þjónustu sinni.
Umsókn starfsmanna (hér eftir einfaldlega starfsmaður) - í OpenStack þjónustum er þetta innviðapúkinn sem gerir þér kleift að senda API skipanir til innviðanna. Til dæmis, sköpun disks á sér stað í starfsmanninum og stofnunarbeiðnin á sér stað í forritaskilum forritsins.
Hefðbundinn OpenStack forritaarkitektúr
Flestar þjónustur sem eru þróaðar fyrir OpenStack reyna að fylgja einni hugmyndafræði. Þjónusta samanstendur venjulega af 2 hlutum: API og starfsmenn (framkvæmdastjórar). Að jafnaði er API WSGI forrit í Python, sem er sett af stað annað hvort sem sjálfstætt ferli (púki), eða með því að nota tilbúinn Nginx eða Apache vefþjón. API vinnur úr notendabeiðninni og sendir frekari leiðbeiningar til vinnuforritsins til framkvæmdar. Flutningurinn á sér stað með því að nota skilaboðamiðlara, venjulega RabbitMQ, hinir eru illa studdir. Þegar skilaboð berast miðlara eru þau unnin af starfsmönnum og, ef nauðsyn krefur, skila svari.
Þessi hugmyndafræði felur í sér einangruð algeng mistök: RabbitMQ og gagnagrunninn. En RabbitMQ er einangrað innan einnar þjónustu og getur í orði verið einstaklingsbundið fyrir hverja þjónustu. Þannig að hjá MCS aðskiljum við þessa þjónustu eins mikið og mögulegt er; fyrir hvert einstakt verkefni búum við til sérstakan gagnagrunn, sérstakan RabbitMQ. Þessi nálgun er góð vegna þess að ef slys verður á einhverjum viðkvæmum stöðum bilar ekki öll þjónustan heldur aðeins hluti hennar.
Fjöldi starfsmannaforrita er ótakmarkaður, þannig að API getur auðveldlega skalað lárétt á bak við jafnvægistæki til að auka afköst og bilanaþol.
Sumar þjónustur krefjast samhæfingar innan þjónustunnar þegar flóknar raðaðgerðir eiga sér stað milli API og starfsmanna. Í þessu tilviki er ein samhæfingarstöð notuð, klasakerfi eins og Redis, Memcache, osfrv, sem gerir einum starfsmanni kleift að segja öðrum að honum sé úthlutað þessu verkefni ("vinsamlegast ekki taka það"). Við notum etcd. Að jafnaði hafa starfsmenn virkan samskipti við gagnagrunninn, skrifa og lesa upplýsingar þaðan. Við notum mariadb sem gagnagrunn, sem er staðsettur í fjölmeistaraklasa.
Þessi klassíska staka þjónusta er skipulögð á þann hátt sem almennt er viðurkenndur fyrir OpenStack. Það má líta á það sem lokað kerfi, þar sem aðferðir við mælikvarða og bilanaþol eru nokkuð augljósar. Til dæmis, fyrir API bilanaþol, er nóg að setja jafnvægistæki fyrir framan þá. Stækkun starfsmanna er náð með því að fjölga þeim.
Veiki punkturinn í öllu kerfinu er RabbitMQ og MariaDB. Arkitektúr þeirra verðskuldar sérstaka grein. Í þessari grein vil ég einbeita mér að API bilanaþoli.
Openstack forritaarkitektúr. Jafnvægi og bilanaþol skýjapallsins
Gerir HAProxy balancer bilanaþolinn með því að nota ExaBGP
Til að gera forritaskilin okkar skalanleg, hröð og bilanaþolin, setjum við álagsjafnara fyrir framan þau. Við völdum HAProxy. Að mínu mati hefur það alla nauðsynlega eiginleika fyrir verkefni okkar: jafnvægi á nokkrum OSI stigum, stjórnunarviðmót, sveigjanleiki og sveigjanleiki, mikill fjöldi jafnvægisaðferða, stuðningur við setutöflur.
Fyrsta vandamálið sem þurfti að leysa var bilunarþol jafnvægisbúnaðarins sjálfs. Einfaldlega uppsetning jafnvægisbúnaðar skapar einnig bilunarpunkt: jafnvægisbúnaðurinn bilar og þjónustan hrynur. Til að koma í veg fyrir að þetta gerðist notuðum við HAProxy í tengslum við ExaBGP.
ExaBGP gerir þér kleift að innleiða kerfi til að athuga stöðu þjónustu. Við notuðum þetta kerfi til að athuga virkni HAProxy og, ef vandamál koma upp, slökkva á HAProxy þjónustunni frá BGP.
ExaBGP+HAProxy kerfi
- Við setjum upp nauðsynlegan hugbúnað, ExaBGP og HAProxy, á þremur netþjónum.
- Við búum til loopback tengi á hverjum netþjóni.
- Á öllum þremur netþjónunum úthlutum við sama hvíta IP tölu við þetta viðmót.
- Hvítt IP-tala er auglýst á internetinu í gegnum ExaBGP.
Bilanaþol er náð með því að auglýsa sömu IP tölu frá öllum þremur netþjónunum. Frá sjónarhóli netkerfisins er sama heimilisfangið aðgengilegt frá þremur mismunandi næstu hoppum. Beininn sér þrjár eins leiðir, velur hæsta forgang þeirra út frá eigin mæligildi (þetta er venjulega sami kosturinn) og umferðin fer aðeins á einn af netþjónunum.
Ef upp koma vandamál með rekstur HAProxy eða bilun á miðlara hættir ExaBGP að tilkynna leiðina og umferðin skiptir mjúklega yfir á annan netþjón.
Þannig náðum við bilunarþoli jafnvægisbúnaðarins.
Bilunarþol HAProxy jafnvægistækja
Kerfið reyndist ófullkomið: við lærðum hvernig á að panta HAProxy, en lærðum ekki hvernig á að dreifa álaginu innan þjónustunnar. Þess vegna stækkuðum við þetta kerfi aðeins: við fórum að halda jafnvægi á milli nokkurra hvítra IP-tölu.
Jafnvægi byggt á DNS plús BGP
Málið um álagsjöfnun fyrir HAProxy okkar er enn óleyst. Hins vegar er hægt að leysa það á einfaldan hátt, eins og við gerðum hér.
Til að halda jafnvægi á þremur netþjónum þarftu 3 hvítar IP tölur og gamla góða DNS. Hvert af þessum netföngum er ákvarðað á bakviðmóti hvers HAProxy og auglýst á internetinu.
Í OpenStack, til að stjórna auðlindum, er þjónustuskrá notuð, sem tilgreinir endapunkta API tiltekinnar þjónustu. Í þessari möppu skráum við lén - public.infra.mail.ru, sem er leyst í gegnum DNS af þremur mismunandi IP tölum. Fyrir vikið fáum við álagsdreifingu á milli þriggja vistfönga í gegnum DNS.
En þar sem þegar við tilkynnum hvítar IP tölur stjórnum við ekki forgangsröðun netþjónsvals, þá er þetta ekki enn í jafnvægi. Venjulega verður aðeins einn netþjónn valinn miðað við starfsaldur IP-tölu og hinir tveir verða aðgerðalausir vegna þess að engar mælingar eru tilgreindar í BGP.
Við byrjuðum að senda leiðir í gegnum ExaBGP með mismunandi mæligildum. Hver jafnvægistæki auglýsir allar þrjár hvítu IP tölurnar, en ein þeirra, sú helsta fyrir þennan jafnvægisbúnað, er auglýst með lágmarksmæligildi. Þannig að á meðan allir þrír jafnvægistækin eru í gangi fara símtöl í fyrstu IP töluna í fyrsta jafnvægisbúnaðinn, símtöl í annan í annan og símtöl í þann þriðja í þann þriðja.
Hvað gerist þegar einn af jafnvægismönnum dettur? Ef einhver jafnvægisbúnaður bilar er aðal heimilisfang hans enn auglýst frá hinum tveimur og umferð er dreift á milli þeirra. Þannig gefum við notandanum nokkrar IP tölur í einu í gegnum DNS. Með því að jafna eftir DNS og mismunandi mæligildum fáum við jafna dreifingu álagsins á alla þrjá jafnvægisbúnaðinn. Og á sama tíma missum við ekki gallaþolið.
Jafnvægi á HAProxy byggt á DNS + BGP
Samspil ExaBGP og HAProxy
Þannig að við innleiddum bilanaþol ef þjónninn fer, byggt á því að stöðva tilkynningar um leiðir. En HAProxy getur lokað af öðrum ástæðum en bilun á netþjóni: stjórnunarvillur, bilanir innan þjónustunnar. Við viljum fjarlægja bilaða jafnvægisbúnaðinn úr álaginu líka í þessum tilvikum og við þurfum annað kerfi.
Þess vegna, með því að stækka fyrra kerfið, innleiddum við hjartslátt á milli ExaBGP og HAProxy. Þetta er hugbúnaðarútfærsla á samspili ExaBGP og HAProxy, þegar ExaBGP notar sérsniðnar forskriftir til að athuga stöðu forrita.
Til að gera þetta þarftu að stilla heilsufarsskoðun í ExaBGP stillingunni, sem getur athugað stöðu HAProxy. Í okkar tilviki stilltum við heilsubakendann í HAProxy og frá ExaBGP hliðinni athugum við með einfaldri GET beiðni. Ef tilkynningin hættir að gerast, þá er HAProxy líklegast ekki að virka og það er engin þörf á að auglýsa það.
HAProxy heilsuskoðun
HAProxy jafningjar: samstillingu lotu
Það næsta sem þurfti að gera var að samstilla fundina. Þegar unnið er í gegnum dreift jafnvægistæki er erfitt að skipuleggja geymslu upplýsinga um fundi viðskiptavina. En HAProxy er einn af fáum jafnvægismönnum sem geta gert þetta vegna virkni jafningja - getu til að flytja lotutöflur á milli mismunandi HAProxy ferla.
Það eru mismunandi jafnvægisaðferðir: einfaldar eins og td , og framlengdur, þegar fundur viðskiptavinarins er minnst, og í hvert skipti sem hann endar á sama netþjóni og áður. Við vildum útfæra seinni kostinn.
HAProxy notar stafsetningartöflur til að vista biðlarlotur af þessu kerfi. Þeir vista upprunalega IP-tölu viðskiptavinarins, valið markvistfang (bakenda) og nokkrar þjónustuupplýsingar. Venjulega eru stikutöflur notaðar til að geyma uppruna-IP + áfangastað-IP par, sem er sérstaklega gagnlegt fyrir forrit sem geta ekki flutt notendalotusamhengi þegar skipt er yfir í annan jafnvægisbúnað, til dæmis í RoundRobin jafnvægisstillingu.
Ef stafurborði er kennt að færa sig á milli mismunandi HAProxy ferla (á milli þess sem jafnvægi á sér stað), munu jafnvægistækin okkar geta unnið með einni laug af stafborðum. Þetta mun gera það mögulegt að skipta óaðfinnanlega um netkerfi viðskiptavinarins ef einn af jafnvægistækjunum bilar; vinna með viðskiptavinalotum mun halda áfram á sömu bakendunum og voru valdir áður.
Til að hægt sé að virka rétt verður að leysa vandamálið með uppruna IP-tölu jafnvægisbúnaðarins sem lotan var stofnuð frá. Í okkar tilviki er þetta kraftmikið heimilisfang á loopback viðmótinu.
Rétt vinna jafningja næst aðeins við ákveðnar aðstæður. Það er, TCP tímamörk verða að vera nógu stór eða að skipta verður að vera nógu hratt til að TCP lotan hafi ekki tíma til að ljúka. Hins vegar gerir það kleift að skipta um óaðfinnanlega.
Í IaaS erum við með þjónustu byggða með sömu tækni. Þetta , sem heitir Octavia. Það er byggt á tveimur HAProxy ferlum og felur upphaflega í sér stuðning við jafningja. Þeir hafa reynst vel í þessari þjónustu.
Myndin sýnir með skýrum hætti hreyfingu jafningjatafla á milli þriggja HAProxy tilvika, stillt er upp á hvernig hægt er að stilla þetta:
HAProxy jafningjar (samstilling lota)
Ef þú innleiðir sama kerfi verður að prófa virkni þess vandlega. Það er ekki staðreynd að það muni virka á sama hátt 100% af tímanum. En að minnsta kosti muntu ekki tapa stafborðum þegar þú þarft að muna uppruna IP viðskiptavinarins.
Takmörkun á fjölda beiðna samtímis frá sama viðskiptavini
Öll þjónusta sem er aðgengileg almenningi, þar á meðal API okkar, getur verið háð snjóflóðum beiðna. Ástæðurnar fyrir þeim geta verið allt aðrar, allt frá notendavillum til markvissra árása. Við erum reglulega DDoSed af IP tölum. Viðskiptavinir gera oft mistök í skriftum sínum og gefa okkur smá-DDoS.
Með einum eða öðrum hætti þarf að veita viðbótarvernd. Augljós lausn er að takmarka fjölda API beiðna og ekki sóa CPU tíma í að vinna illgjarn beiðnir.
Til að innleiða slíkar takmarkanir notum við taxtamörk, skipulögð á grundvelli HAProxy, með sömu spýtutöflum. Að setja upp mörk er frekar einfalt og gerir þér kleift að takmarka notandann með fjölda beiðna til API. Reikniritið man uppruna IP sem beiðnir eru gerðar frá og takmarkar fjölda beiðna samtímis frá einum notanda. Auðvitað reiknuðum við meðaltal API hleðslusniðs fyrir hverja þjónustu og settum mörk ≈ 10 sinnum þetta gildi. Við höldum áfram að fylgjast vel með gangi mála og erum með puttann á púlsinum.
Hvernig lítur þetta út í reynd? Við höfum viðskiptavini sem nota sjálfvirka mælikvarða API okkar allan tímann. Þeir búa til um það bil tvö til þrjú hundruð sýndarvélar á morgnana og eyða þeim á kvöldin. Fyrir OpenStack þarf að búa til sýndarvél, einnig með PaaS þjónustu, að minnsta kosti 1000 API beiðnir, þar sem samskipti milli þjónustu eiga sér einnig stað í gegnum API.
Slíkur verkefnaflutningur veldur nokkuð miklu álagi. Við mátum þetta álag, söfnuðum daglegum toppum, tífalduðum þá og þetta varð gjaldskrá okkar. Við erum með puttann á púlsinum. Við sjáum oft vélmenni og skanna sem eru að reyna að skoða okkur til að sjá hvort við höfum einhver CGA forskriftir sem hægt er að keyra, við erum virkir að klippa þau.
Hvernig á að uppfæra kóðagrunninn þinn án þess að notendur taki eftir því
Við innleiðum einnig bilanaþol á stigi kóða dreifingarferla. Það geta verið gallar við útfærslur, en hægt er að lágmarka áhrif þeirra á framboð þjónustu.
Við uppfærum þjónustu okkar stöðugt og verðum að tryggja að kóðagrunnurinn sé uppfærður án þess að hafa áhrif á notendur. Okkur tókst að leysa þetta vandamál með því að nota stjórnunargetu HAProxy og innleiðingu Graceful Shutdown í þjónustu okkar.
Til að leysa þetta vandamál var nauðsynlegt að tryggja stjórn jafnvægisbúnaðarins og „rétta“ lokun þjónustu:
- Þegar um HAProxy er að ræða er eftirlit framkvæmt í gegnum tölfræðiskrá, sem er í meginatriðum fals og er skilgreind í HAProxy stillingum. Þú getur sent skipanir á það í gegnum stdio. En aðal stillingarstýringartæki okkar er mögulegt, svo það er með innbyggða einingu til að stjórna HAProxy. Sem við notum virkan.
- Flestar API- og vélaþjónustur okkar styðja þokkafulla lokunartækni: þegar lokað er, bíða þeir eftir að núverandi verkefni ljúki, hvort sem það er http beiðni eða einhver þjónustuverkefni. Það sama gerist með starfsmanninn. Það þekkir öll verkefni sem það er að gera og lýkur þegar það hefur lokið öllu.
Þökk sé þessum tveimur atriðum lítur öruggt reiknirit fyrir uppsetningu okkar svona út.
- Framkvæmdaraðilinn setur saman nýjan pakka af kóða (fyrir okkur er þetta RPM), prófar hann í þróunarumhverfinu, prófar hann á sviðinu og skilur hann eftir í áfangageymslunni.
- Framkvæmdaraðilinn setur verkefnið fyrir dreifingu með ítarlegri lýsingu á „gripunum“: útgáfu nýja pakkans, lýsingu á nýju virkninni og öðrum upplýsingum um dreifinguna ef þörf krefur.
- Kerfisstjórinn byrjar uppfærsluna. Opnar Ansible leikbókina, sem aftur gerir eftirfarandi:
- Tekur pakka úr sviðsgeymslunni og notar hann til að uppfæra útgáfu pakkans í vörugeymslunni.
- Tekur saman lista yfir bakenda uppfærðu þjónustunnar.
- Lokar fyrstu þjónustunni sem verður uppfærð í HAProxy og bíður eftir að ferlum hennar ljúki. Þökk sé þokkalegri lokun, erum við fullviss um að allar núverandi beiðnir viðskiptavina muni ljúka með góðum árangri.
- Eftir að API og starfsmenn eru algjörlega stöðvaðir og slökkt er á HAProxy er kóðinn uppfærður.
- Ansible rekur þjónustu.
- Fyrir hverja þjónustu er dregið í ákveðin „handföng“ sem framkvæma einingaprófanir á fjölda fyrirfram skilgreindra lyklaprófa. Grunnathugun á nýja kóðanum fer fram.
- Ef engar villur fundust í fyrra skrefi er bakendinn virkjaður.
- Við skulum halda áfram í næsta bakenda.
- Eftir að allir bakenda eru uppfærðir eru virknipróf ræst. Ef þau vantar, þá skoðar verktaki hvers kyns nýja virkni sem hann bjó til.
Þetta lýkur dreifingunni.
Þjónustuuppfærsluferill
Þetta kerfi myndi ekki virka ef við hefðum ekki eina reglu. Við styðjum bæði gömlu og nýja útgáfuna í bardaga. Fyrirfram, á stigi hugbúnaðarþróunar, er mælt fyrir um að jafnvel þótt breytingar verði á þjónustugagnagrunninum muni þær ekki brjóta fyrri kóða. Fyrir vikið er kóðagrunnurinn uppfærður smám saman.
Ályktun
Með því að deila mínum eigin hugsunum um villuþolinn vefarkitektúr, vil ég enn og aftur benda á lykilatriði þess:
- líkamlegt bilunarþol;
- netbilunarþol (jafnvægi, BGP);
- bilanaþol hugbúnaðarins sem notaður er og þróaður.
Stöðugur spenntur allir!
Heimild: www.habr.com
