Ský eru eins og töfrakassi - þú spyrð hvað þú þarft og auðlindirnar birtast bara upp úr engu. Sýndarvélar, gagnagrunnar, net - allt þetta tilheyrir aðeins þér. Það eru aðrir skýjaleigur, en í alheiminum þínum ert þú einvaldurinn. Þú ert viss um að þú munt alltaf fá nauðsynleg úrræði, þú tekur ekki tillit til neins og þú ákveður sjálfstætt hvernig netið verður. Hvernig virkar þessi galdur sem gerir skýið teygjanlegt að úthluta fjármagni og einangra leigjendur algjörlega frá hver öðrum?
AWS skýið er ofurflókið kerfi sem hefur verið að þróast síðan 2006. Hluti af þessari þróun átti sér stað Vasily Pantyukhin - Amazon Web Services arkitekt. Sem arkitekt fær hann innsýn ekki aðeins á lokaniðurstöðuna, heldur einnig á áskoranir AWS sigrast á. Því meiri skilningur sem er á því hvernig kerfið virkar, því meiri er traustið. Þess vegna mun Vasily deila leyndarmálum AWS skýjaþjónustu. Hér að neðan er hönnun líkamlegra AWS netþjóna, teygjanlegur sveigjanleiki gagnagrunns, sérsniðinn Amazon gagnagrunnur og aðferðir til að auka afköst sýndarvéla og lækka um leið verð þeirra. Þekking á byggingaraðferðum Amazon mun hjálpa þér að nota AWS þjónustu á skilvirkari hátt og gæti gefið þér nýjar hugmyndir um að byggja upp þínar eigin lausnir.
Um fyrirlesara: Vasily Pantyukhin () byrjaði sem Unix stjórnandi hjá .ru fyrirtækjum, vann við stóran Sun Microsystem vélbúnað í 6 ár og boðaði gagnamiðaðan heim hjá EMC í 11 ár. Það þróaðist náttúrulega í einkaský og árið 2017 færðist það yfir í opinbert. Nú veitir hann tæknilega ráðgjöf til að hjálpa til við að lifa og þróast í AWS skýinu.
Fyrirvari: allt hér að neðan er persónuleg skoðun Vasily og gæti ekki verið í samræmi við stöðu Amazon Web Services. Skýrslan sem greinin byggir á er aðgengileg á YouTube rásinni okkar.
Af hverju er ég að tala um Amazon tækið?
Fyrsti bíllinn minn var með beinskiptingu. Það var frábært vegna tilfinningarinnar að ég gæti keyrt bílinn og haft fulla stjórn á honum. Mér líkaði líka að ég skildi að minnsta kosti nokkurn veginn meginregluna um starfsemi þess. Eðlilega ímyndaði ég mér að uppbygging kassans væri frekar frumstæð - eitthvað eins og gírkassi á reiðhjóli.
Allt var frábært, nema eitt - fastur í umferðarteppu. Það virðist sem þú situr og gerir ekki neitt, en þú ert stöðugt að skipta um gír, ýta á kúplingu, bensín, bremsa - það gerir þig virkilega þreyttan. Umferðarteppuvandamálið leystist að hluta þegar fjölskyldan fékk sjálfskiptan bíl. Í akstri hafði ég tíma til að hugsa um eitthvað og hlusta á hljóðbók.
Önnur ráðgáta birtist í lífi mínu, því ég hætti alveg að skilja hvernig bíllinn minn virkar. Nútímabíll er flókið tæki. Bíllinn aðlagar sig samtímis að tugum mismunandi breytum: bensíngjöf, bremsa, aksturslag, vegagæði. Ég skil ekki lengur hvernig það virkar.
Þegar ég byrjaði að vinna í Amazon skýinu var það mér líka ráðgáta. Aðeins þessi ráðgáta er stærðargráðu meiri, því það er einn ökumaður í bílnum og í AWS eru milljónir þeirra. Allir notendur stýra samtímis, ýta á gasið og bremsa. Það er ótrúlegt að þeir fari þangað sem þeir vilja - það er kraftaverk fyrir mig! Kerfið aðlagar sig sjálfkrafa, skalar og aðlagar sig teygjanlega að hverjum notanda þannig að honum sýnist að hann sé einn í þessum alheimi.
Töfrarnir duttu aðeins niður þegar ég kom síðar til starfa sem arkitekt hjá Amazon. Ég sá hvaða vandamál við stöndum frammi fyrir, hvernig við leysum þau og hvernig við þróum þjónustu. Með auknum skilningi á því hvernig kerfið virkar birtist meira traust á þjónustunni. Svo ég vil deila mynd af því sem er undir hettunni á AWS skýinu.
Hvað eigum við að tala um
Ég valdi fjölbreytta nálgun - ég valdi 4 áhugaverðar þjónustur sem vert er að tala um.
Hagræðing netþjóns. Efnaleg ský með líkamlegri útfærslu: líkamleg gagnaver þar sem eru líkamlegir netþjónar sem raula, hitna og blikka með ljósum.
Serverlausar aðgerðir (Lambda) er líklega skalanlegasta þjónustan í skýinu.
Stærð gagnagrunns. Ég skal segja þér frá því hvernig við byggjum upp okkar eigin stigstæranlega gagnagrunna.
Stærð netkerfis. Síðasti hlutinn þar sem ég mun opna tækið á netinu okkar. Þetta er dásamlegur hlutur - sérhver skýnotandi trúir því að hann sé einn í skýinu og sjái alls ekki aðra leigjendur.
Athugið. Þessi grein mun fjalla um hagræðingu netþjóna og gagnagrunnsstærð. Við munum íhuga netskala í næstu grein. Hvar eru serverlausu aðgerðirnar? Sérstakt afrit var gefið út um þá “" Það fjallar um nokkrar mismunandi stærðaraðferðir og fjallar ítarlega um Firecracker lausnina - sambýli bestu eiginleika sýndarvélar og gáma.
Servers
Skýið er hverfult. En þessi hverfulleiki hefur samt líkamlega útfærslu - netþjóna. Upphaflega var arkitektúr þeirra klassískur. Staðlað x86 kubbasett, netkort, Linux, Xen hypervisor sem sýndarvélar voru keyrðar á.
Árið 2012 tókst þessi arkitektúr verkefni sín nokkuð vel. Xen er frábær hypervisor, en hann hefur einn stóran galla. Hann er kominn með nóg hár kostnaður fyrir eftirlíkingu tækja. Eftir því sem ný, hraðari netkort eða SSD drif verða fáanleg, verður þessi kostnaður of hár. Hvernig á að takast á við þetta vandamál? Við ákváðum að vinna á tveimur vígstöðvum í einu - fínstilla bæði vélbúnað og hypervisor. Verkefnið er mjög alvarlegt.
Hagræðing vélbúnaðar og hypervisor
Að gera allt í einu og gera það vel mun ekki virka. Hvað „gott“ var var líka óljóst í upphafi.
Við ákváðum að taka þróunarlega nálgun - við breytum einum mikilvægum þætti arkitektúrsins og hendum honum í framleiðslu.
Við stígum á hverja hrífu, hlustum á kvartanir og tillögur. Þá breytum við öðrum þætti. Svo, í litlum skrefum, breytum við allri arkitektúrnum á róttækan hátt byggt á endurgjöf frá notendum og stuðningi.
Umbreytingin hófst árið 2013 með því flóknasta - netkerfinu. IN С3 tilvik var sérstöku nethröðunarkorti bætt við venjulega netkortið. Það var bókstaflega tengt með stuttum snúru aftur á framhliðinni. Það er ekki fallegt, en það sést ekki í skýinu. En bein samskipti við vélbúnað bættu í grundvallaratriðum jitter og netafköst.
Næst ákváðum við að bæta aðgang að gagnageymslu EBS - Elastic Block Storage. Það er sambland af neti og geymslu. Erfiðleikarnir eru þeir að á meðan Network Accelerator spil voru til á markaðnum, þá var enginn möguleiki á að kaupa einfaldlega Storage Accelerator vélbúnað. Svo við snerum okkur að ræsingu Annapurna Labs, sem þróaði sérstaka ASIC flís fyrir okkur. Þeir leyfðu að fjarlæg EBS bindi væri fest upp sem NVMe tæki.
Í tilfellum C4 við leystum tvö vandamál. Hið fyrsta er að við innleiddum grunn fyrir framtíðina fyrir efnilega, en nýja á þeim tíma, NVMe tækni. Í öðru lagi affermuðum við miðlæga örgjörvanum verulega með því að flytja vinnslu beiðna til EBS yfir á nýtt kort. Það reyndist vel, svo nú er Annapurna Labs hluti af Amazon.
Í nóvember 2017 áttuðum við okkur á því að það væri kominn tími til að breyta sjálfum hypervisornum.
Nýi hypervisorinn var þróaður út frá breyttum KVM kjarnaeiningum.
Það gerði það mögulegt að draga í grundvallaratriðum úr kostnaði við eftirlíkingu tækja og vinna beint með nýjum ASIC. Tilvik С5 voru fyrstu sýndarvélarnar með nýjum hypervisor í gangi undir húddinu. Við nefndum hann Nitro.
Þróun tilvika á tímalínunni.
Allar nýjar gerðir sýndarvéla sem hafa birst síðan í nóvember 2017 keyra á þessum hypervisor. Bare Metal tilvik eru ekki með hypervisor, en þeir eru einnig kallaðir Nitro, þar sem þeir nota sérhæfð Nitro spil.
Á næstu tveimur árum fór fjöldi tegunda af Nitro-tilvikum yfir nokkra tugi: A1, C5, M5, T3 og fleiri.
Tilviksgerðir.
Hvernig nútíma Nitro vélar virka
Þeir hafa þrjá meginþætti: Nitro hypervisor (rædd hér að ofan), öryggiskubbinn og Nitro spilin.
Öryggisflís samþætt beint inn í móðurborðið. Það stjórnar mörgum mikilvægum aðgerðum, svo sem að stjórna hleðslu stýrikerfisins.
Nítró spil - Það eru fjórar tegundir af þeim. Öll þau eru þróuð af Annapurna Labs og eru byggð á algengum ASIC. Sum vélbúnaðar þeirra er líka algeng.
Fjórar tegundir af Nitro spilum.
Eitt af kortunum er hannað til að vinna með netkerfiVPC. Þetta er það sem er sýnilegt í sýndarvélum sem netkort ENA - Elastic Network Adapter. Það hylur einnig umferð þegar það sendir það í gegnum líkamlegt net (við munum tala um þetta í seinni hluta greinarinnar), stjórnar öryggishóps eldveggnum og ber ábyrgð á leiðsögn og öðrum nethlutum.
Valin kort virka með blokkargeymslu EBS og diska sem eru innbyggðir í netþjóninn. Þeir birtast gestur sýndarvél sem NVMe millistykki. Þeir bera einnig ábyrgð á dulkóðun gagna og eftirlit með diskum.
Kerfi Nitro korta, hypervisor og öryggiskubba er samþætt í SDN net eða Hugbúnaðarskilgreint net. Ber ábyrgð á stjórnun þessa nets (Control Plane) stjórnandi kort.
Auðvitað höldum við áfram að þróa nýja ASIC. Til dæmis, í lok árs 2018, gáfu þeir út Inferentia flöguna, sem gerir þér kleift að vinna á skilvirkari hátt með vélanámsverkefni.
Inferentia Machine Learning örgjörva flís.
Skalanlegur gagnagrunnur
Hefðbundinn gagnagrunnur er með lagskiptri uppbyggingu. Til að einfalda mjög, eru eftirfarandi stig aðgreind.
- SQL — viðskiptavinur og beiðni sendendur vinna að því.
- Ákvæði viðskipti - hér er allt á hreinu, SÝR og allt það.
- skyndiminni, sem er veitt af biðminni.
- Skógarhögg — veitir vinnu með endurgerða annálum. Í MySQL heita þeir Bin Logs, í PosgreSQL - Write Ahead Logs (WAL).
- Geymsla - beina upptöku á disk.
Lagskipt gagnagrunnsbygging.
Það eru mismunandi leiðir til að skala gagnagrunna: klippingu, Shared Nothing arkitektúr, sameiginlegir diskar.
Hins vegar viðhalda allar þessar aðferðir sömu einhæfu gagnagrunnsskipulaginu. Þetta takmarkar mælikvarða verulega. Til að leysa þetta vandamál þróuðum við okkar eigin gagnagrunn - Amazon-Aurora. Það er samhæft við MySQL og PostgreSQL.
Amazon-Aurora
Meginhugmynd byggingarlistarinnar er að aðskilja geymslu- og skráningarstig frá aðalgagnagrunninum.
Þegar ég horfi fram á veginn segi ég að við gerðum skyndiminnisstigið líka óháð. Arkitektúrinn hættir að vera einsleitur og við öðlumst aukið frelsi við að stækka einstaka blokkir.
Skráningar- og geymslustig eru aðskilin frá gagnagrunninum.
Hefðbundið DBMS skrifar gögn í geymslukerfi í formi kubba. Hjá Amazon Aurora bjuggum við til snjalla geymslu sem getur talað tungumál endurtaka logs. Að innan breytir geymslan annálum í gagnablokkir, fylgist með heilindum þeirra og tekur sjálfkrafa öryggisafrit.
Þessi nálgun gerir þér kleift að útfæra svo áhugaverða hluti eins og klónun. Það virkar í grundvallaratriðum hraðar og hagkvæmara vegna þess að það þarf ekki að búa til fullkomið afrit af öllum gögnum.
Geymslulagið er útfært sem dreift kerfi. Það samanstendur af mjög miklum fjölda líkamlegra netþjóna. Hver endurtakaskrá er unnin og vistuð samtímis sex hnútar. Þetta tryggir gagnavernd og álagsjafnvægi.
Hægt er að ná lestrarstærð með því að nota viðeigandi eftirmyndir. Dreifð geymsla útilokar þörfina fyrir samstillingu á milli aðalgagnagrunnstilviksins, sem við skrifum gögn í gegnum, og eftirmyndanna sem eftir eru. Tryggt er að uppfærð gögn séu tiltæk fyrir allar eftirmyndir.
Eina vandamálið er að geyma gömul gögn á lesnum eftirlíkingum. En það er verið að leysa þetta vandamál flutningur allra endurgerða annála til eftirlíkinga yfir innra netið. Ef annálinn er í skyndiminni er hann merktur sem rangur og skrifaður yfir. Ef það er ekki í skyndiminni er því einfaldlega hent.
Við redduðum geymslunni.
Hvernig á að skala DBMS flokka
Hér er lárétt skala mun erfiðara. Svo skulum við fara á troðnum slóðum klassísk lóðrétt mælikvarði.
Gerum ráð fyrir að við höfum forrit sem hefur samskipti við DBMS í gegnum aðalhnút.
Þegar við stækkum lóðrétt úthlutum við nýjum hnút sem mun hafa fleiri örgjörva og minni.
Næst skiptum við forritinu úr gamla aðalhnútnum yfir í það nýja. Vandamál koma upp.
- Þetta mun krefjast verulegs niður í miðbæ.
- Nýi aðalhnúturinn mun hafa kalt skyndiminni. Afköst gagnagrunnsins verða aðeins hámark eftir að skyndiminni hefur hitnað.
Hvernig á að bæta ástandið? Settu upp proxy á milli forritsins og aðalhnútsins.
Hvað mun þetta gefa okkur? Nú þarf ekki að beina öllum forritum handvirkt á nýja hnútinn. Hægt er að skipta um undir proxy og er í grundvallaratriðum hraðari.
Svo virðist sem vandinn hafi verið leystur. En nei, við þjáumst enn af því að þurfa að hita upp skyndiminni. Að auki hefur nýtt vandamál komið upp - nú er umboðið hugsanlegt bilunarpunktur.
Lokalausn með Amazon Aurora miðlaralausu
Hvernig leystum við þessi vandamál?
Skildi eftir umboð. Þetta er ekki sérstakt tilvik, heldur heill dreifður floti umboðsmanna þar sem forrit tengjast gagnagrunninum. Ef bilun er, er hægt að skipta um hvaða hnút sem er nánast samstundis.
Bætt við laug af hlýjum hnútum af ýmsum stærðum. Þess vegna, ef nauðsynlegt er að úthluta nýjum hnút af stærri eða minni stærð, er hann strax tiltækur. Engin þörf á að bíða eftir því að hlaðast.
Öllu kvarðaferlinu er stjórnað af sérstöku eftirlitskerfi. Vöktun fylgist stöðugt með stöðu núverandi aðalhnút. Ef það skynjar, til dæmis, að örgjörvaálagið hefur náð mikilvægu gildi, lætur það hóp heitra tilvika vita um nauðsyn þess að úthluta nýjum hnút.
Dreift umboð, hlý tilvik og eftirlit.
Hnútur með nauðsynlegan kraft er fáanlegur. Buffer laugar eru afritaðar til þess og kerfið byrjar að bíða eftir öruggu augnabliki til að skipta.
Venjulega kemur augnablikið til að skipta nokkuð fljótt. Þá stöðvast samskipti milli umboðsins og gamla aðalhnútsins, allar lotur eru færðar yfir í nýja hnútinn.
Vinna með gagnagrunninn fer aftur.
Grafið sýnir að fjöðrunin er sannarlega mjög stutt. Bláa línuritið sýnir álagið og rauðu skrefin sýna stigstærðarstundirnar. Skammtíma lækkanir í bláa línuritinu eru einmitt þessi stutta töf.
Við the vegur, Amazon Aurora gerir þér kleift að spara peninga og slökkva á gagnagrunninum þegar hann er ekki í notkun, til dæmis um helgar. Eftir að hleðslan er stöðvuð dregur DB smám saman úr krafti og slekkur á sér í nokkurn tíma. Þegar álagið kemur aftur mun það hækka mjúklega aftur.
Í næsta hluta sögunnar um Amazon tækið munum við tala um netstærð. Gerast áskrifandi og fylgstu með svo þú missir ekki af greininni.
Á Vasily Pantyukhin mun gefa skýrslu “" Hvaða hönnunarmynstur fyrir dreifð kerfi eru notuð af Amazon forriturum, hverjar eru ástæðurnar fyrir bilun í þjónustu, hvað er frumubundinn arkitektúr, Constant Work, Shuffle Sharding - það verður áhugavert. Innan við mánuður til ráðstefnunnar - . 24. október endanleg verðhækkun.
Heimild: www.habr.com