Wolke is soos 'n towerboks - jy vra wat jy nodig het, en die hulpbronne verskyn sommer uit die niet. Virtuele masjiene, databasisse, netwerk - dit alles behoort net aan jou. Daar is ander wolkhuurders, maar in jou Heelal is jy die enigste heerser. Jy is seker dat jy altyd die nodige hulpbronne sal ontvang, jy neem niemand in ag nie en jy bepaal onafhanklik hoe die netwerk sal wees. Hoe werk hierdie towerkrag wat die wolk hulpbronne elasties laat toeken en huurders heeltemal van mekaar isoleer?
Die AWS-wolk is 'n mega-super komplekse stelsel wat sedert 2006 evolusionêr ontwikkel het. Deel van hierdie ontwikkeling het plaasgevind Vasily Pantyukhin - Amazon Web Services-argitek. As argitek kry hy nie net 'n kykie van binne na die eindresultaat nie, maar ook na die uitdagings wat AWS oorkom. Hoe groter die begrip van hoe die stelsel werk, hoe groter is die vertroue. Daarom sal Vasily die geheime van AWS-wolkdienste deel. Hieronder is die ontwerp van fisiese AWS-bedieners, elastiese databasisskaalbaarheid, 'n pasgemaakte Amazon-databasis en metodes om die werkverrigting van virtuele masjiene te verhoog en terselfdertyd hul prys te verlaag. Kennis van Amazon se argitektoniese benaderings sal jou help om AWS-dienste meer effektief te gebruik en kan jou nuwe idees gee om jou eie oplossings te bou.
Oor die spreker: Vasily Pantyukhin () het begin as 'n Unix-administrateur by .ru-maatskappye, het vir 6 jaar aan groot Sun Microsystem-hardeware gewerk en vir 11 jaar 'n data-gesentreerde wêreld by EMC gepreek. Dit het natuurlik in private wolke ontwikkel en in 2017 na openbare wolke verskuif. Nou gee hy tegniese advies om te help leef en ontwikkel in die AWS-wolk.
Vrywaring: alles hieronder is Vasily se persoonlike mening en mag nie saamval met die posisie van Amazon Web Services nie. Die verslag waarop die artikel gebaseer is, is op ons YouTube-kanaal beskikbaar.
Hoekom praat ek van die Amazon-toestel?
My eerste motor het 'n handratkas gehad. Dit was wonderlik vanweë die gevoel dat ek die motor kon bestuur en volkome beheer daaroor het. Ek het ook daarvan gehou dat ek die beginsel van die werking daarvan ten minste min of meer verstaan het. Natuurlik het ek my voorgestel dat die struktuur van die boks nogal primitief is – iets soos 'n ratkas op 'n fiets.
Alles was wonderlik, behalwe vir een ding - vas in verkeersknope. Dit wil voorkom asof jy sit en niks doen nie, maar jy wissel gedurig van ratte, druk die koppelaar, petrol, rem – dit maak jou regtig moeg. Die verkeersknoopprobleem is gedeeltelik opgelos toe die gesin ’n outomatiese motor gekry het. Terwyl ek bestuur het, het ek tyd gehad om oor iets te dink en na 'n oudioboek te luister.
Nog 'n raaisel het in my lewe verskyn, want ek het heeltemal opgehou verstaan hoe my kar werk. 'n Moderne motor is 'n komplekse toestel. Die motor pas gelyktydig aan by dosyne verskillende parameters: petroldruk, rem, bestuurstyl, padkwaliteit. Ek verstaan nie meer hoe dit werk nie.
Toe ek aan die Amazon-wolk begin werk het, was dit ook vir my 'n raaisel. Net hierdie raaisel is 'n orde van grootte groter, want daar is een bestuurder in die motor, en in AWS is daar miljoene van hulle. Alle gebruikers stuur gelyktydig, druk die gas en rem. Dit is ongelooflik dat hulle gaan waar hulle wil – dit is vir my 'n wonderwerk! Die stelsel pas outomaties aan, skaal en pas elasties by elke gebruiker aan sodat dit vir hom lyk of hy alleen in hierdie Heelal is.
Die magie het 'n bietjie afgeneem toe ek later as argitek by Amazon kom werk het. Ek het gesien watter probleme ons in die gesig staar, hoe ons dit oplos en hoe ons dienste ontwikkel. Met toenemende begrip van hoe die stelsel werk, verskyn meer vertroue in die diens. Ek wil dus 'n foto deel van wat onder die enjinkap van die AWS-wolk is.
Waaroor sal ons praat
Ek het 'n gediversifiseerde benadering gekies - ek het 4 interessante dienste gekies wat die moeite werd is om oor te praat.
Bediener optimalisering. Efemere wolke met 'n fisiese beliggaming: fisiese datasentrums waar daar fisiese bedieners is wat neurie, verhit en met ligte flikker.
Bedienerlose funksies (Lambda) is waarskynlik die mees skaalbare diens in die wolk.
Databasis skaal. Ek sal jou vertel van hoe ons ons eie skaalbare databasisse bou.
Netwerk skaal. Die laaste deel waarin ek die toestel van ons netwerk sal oopmaak. Dit is 'n wonderlike ding - elke wolkgebruiker glo dat hy alleen in die wolk is en glad nie ander huurders sien nie.
Let wel. Hierdie artikel sal bedieneroptimalisering en databasisskaal bespreek. Ons sal netwerkskaal in die volgende artikel oorweeg. Waar is die bedienerlose funksies? 'n Afsonderlike transkripsie is oor hulle gepubliseer "" Dit praat oor verskeie verskillende skaalmetodes, en bespreek in detail die Firecracker-oplossing - 'n simbiose van die beste eienskappe van 'n virtuele masjien en houers.
Bedieners
Die wolk is kortstondig. Maar hierdie kortstondigheid het steeds 'n fisiese beliggaming - bedieners. Aanvanklik was hul argitektuur klassiek. Standaard x86-skyfiestel, netwerkkaarte, Linux, Xen-hypervisor waarop virtuele masjiene uitgevoer is.
In 2012 het hierdie argitektuur sy take redelik goed hanteer. Xen is 'n goeie hiperviseerder, maar dit het een groot nadeel. Hy het genoeg hoë bokoste vir toestelemulasie. Soos nuwe, vinniger netwerkkaarte of SSD-aandrywers beskikbaar word, word hierdie bokoste te hoog. Hoe om hierdie probleem te hanteer? Ons het besluit om op twee fronte tegelyk te werk - optimaliseer beide hardeware en hypervisor. Die taak is baie ernstig.
Optimalisering van hardeware en hipervisor
Om alles op een slag te doen en dit goed te doen, sal nie werk nie. Wat “goed” was, was aanvanklik ook onduidelik.
Ons het besluit om 'n evolusionêre benadering te volg - ons verander een belangrike element van die argitektuur en gooi dit in produksie.
Ons trap op elke hark, luister na klagtes en voorstelle. Dan verander ons 'n ander komponent. Dus, in klein inkremente, verander ons die hele argitektuur radikaal op grond van terugvoer van gebruikers en ondersteuning.
Die transformasie het in 2013 begin met die mees komplekse ding – die netwerk. IN С3 In gevalle is 'n spesiale Network Accelerator-kaart by die standaard netwerkkaart gevoeg. Dit is letterlik verbind met 'n kort terugluskabel op die voorpaneel. Dit is nie mooi nie, maar dit is nie sigbaar in die wolk nie. Maar direkte interaksie met hardeware het jitter en netwerkdeurset fundamenteel verbeter.
Vervolgens het ons besluit om toegang tot blokdataberging EBS - Elastic Block Storage te verbeter. Dit is 'n kombinasie van netwerk en berging. Die moeilikheid is dat hoewel Network Accelerator-kaarte op die mark bestaan het, daar geen opsie was om bloot Storage Accelerator-hardeware te koop nie. Ons het dus na 'n beginonderneming gewend Annapurna Labs, wat spesiale ASIC-skyfies vir ons ontwikkel het. Hulle het toegelaat dat afgeleë EBS-volumes as NVMe-toestelle gemonteer word.
In gevalle C4 ons het twee probleme opgelos. Die eerste is dat ons 'n grondslag vir die toekoms van belowende, maar nuut op daardie tydstip, NVMe-tegnologie geïmplementeer het. Tweedens het ons die sentrale verwerker aansienlik afgelaai deur die verwerking van versoeke na EBS na 'n nuwe kaart oor te dra. Dit het goed uitgedraai, so nou is Annapurna Labs deel van Amazon.
Teen November 2017 het ons besef dat dit tyd was om die hiperviser self te verander.
Die nuwe hipervisor is ontwikkel op grond van gewysigde KVM-kernmodules.
Dit het dit moontlik gemaak om die bokoste van toestelemulasie fundamenteel te verminder en direk met nuwe ASIC's te werk. Gevalle С5 was die eerste virtuele masjiene met 'n nuwe hypervisor wat onder die enjinkap loop. Ons het hom genoem Nitro.
Evolusie van gevalle op die tydlyn.
Alle nuwe soorte virtuele masjiene wat sedert November 2017 verskyn het, werk op hierdie hiperviser. Bare Metal-gevalle het nie 'n hypervisor nie, maar hulle word ook Nitro genoem, aangesien hulle gespesialiseerde Nitro-kaarte gebruik.
Oor die volgende twee jaar het die aantal tipes Nitro-gevalle 'n paar dosyn oorskry: A1, C5, M5, T3 en ander.
Instance tipes.
Hoe moderne Nitro-masjiene werk
Hulle het drie hoofkomponente: die Nitro-hypervisor (hierbo bespreek), die sekuriteitskyfie en die Nitro-kaarte.
Sekuriteitskyfie direk in die moederbord geïntegreer. Dit beheer baie belangrike funksies, soos die beheer van die laai van die gasheer-bedryfstelsel.
Nitro kaarte - Daar is vier tipes van hulle. Almal van hulle is ontwikkel deur Annapurna Labs en is gebaseer op algemene ASIC's. Sommige van hul firmware is ook algemeen.
Vier tipes Nitro-kaarte.
Een van die kaarte is ontwerp om mee te werk netwerkVPC. Dit is wat sigbaar is in virtuele masjiene as 'n netwerkkaart ENA - Elastiese netwerkadapter. Dit omsluit ook verkeer wanneer dit deur 'n fisiese netwerk versend word (ons sal hieroor praat in die tweede deel van die artikel), beheer die Security Groups-brandmuur, en is verantwoordelik vir roetering en ander netwerkdinge.
Kies kaarte werk met blokberging EBS en skywe wat in die bediener ingebou is. Hulle verskyn aan die gas virtuele masjien as NVMe-adapters. Hulle is ook verantwoordelik vir data-enkripsie en skyfmonitering.
Die stelsel van Nitro-kaarte, hypervisor en sekuriteitskyfie is geïntegreer in 'n SDN-netwerk of Sagteware-gedefinieerde netwerk. Verantwoordelik vir die bestuur van hierdie netwerk (Beheervliegtuig) kontroleerder kaart.
Natuurlik gaan ons voort om nuwe ASIC's te ontwikkel. Byvoorbeeld, aan die einde van 2018 het hulle die Inferentia-skyfie vrygestel, wat jou toelaat om meer doeltreffend met masjienleertake te werk.
Inferentia Machine Learning Processor-skyfie.
Skaalbare databasis
'n Tradisionele databasis het 'n gelaagde struktuur. Om baie te vereenvoudig, word die volgende vlakke onderskei.
- SQL — kliënt- en versoekversenders werk daaraan.
- Bepalings transaksies - alles is duidelik hier, ACID en dit alles.
- kas, wat deur bufferpoele verskaf word.
- Tekening - verskaf werk met oordoen logs. In MySQL word hulle Bin Logs genoem, in PosgreSQL - Write Ahead Logs (WAL).
- Storage - direkte opname na skyf.
Gelaagde databasisstruktuur.
Daar is verskillende maniere om databasisse te skaal: sharding, Shared Nothing-argitektuur, gedeelde skywe.
Al hierdie metodes handhaaf egter dieselfde monolitiese databasisstruktuur. Dit beperk skaal aansienlik. Om hierdie probleem op te los, het ons ons eie databasis ontwikkel − Amazon Aurora. Dit is versoenbaar met MySQL en PostgreSQL.
Amazon Aurora
Die hoof argitektoniese idee is om die stoor- en logvlakke van die hoofdatabasis te skei.
As ek vorentoe kyk, sal ek sê dat ons ook die kasvlak onafhanklik gemaak het. Die argitektuur hou op om 'n monoliet te wees, en ons kry bykomende grade van vryheid in die skaal van individuele blokke.
Die log- en bergingsvlakke is apart van die databasis.
'n Tradisionele DBBS skryf data na 'n stoorstelsel in die vorm van blokke. By Amazon Aurora het ons slim berging geskep wat taal kan praat oordoen-logs. Binne verander die stoor logs in datablokke, monitor hul integriteit en maak outomaties rugsteun.
Hierdie benadering laat jou toe om sulke interessante dinge te implementeer soos kloning. Dit werk fundamenteel vinniger en meer ekonomies as gevolg van die feit dat dit nie die skep van 'n volledige kopie van alle data vereis nie.
Die bergingslaag word as 'n verspreide stelsel geïmplementeer. Dit bestaan uit 'n baie groot aantal fisiese bedieners. Elke oordoen log word gelyktydig verwerk en gestoor ses knope. Dit verseker databeskerming en vragbalansering.
Leesskaal kan verkry word deur toepaslike replikas te gebruik. Verspreide berging elimineer die behoefte aan sinchronisasie tussen die hoofdatabasisinstansie, waardeur ons data skryf, en die oorblywende replikas. Bygewerkte data is gewaarborg om beskikbaar te wees vir alle replikas.
Die enigste probleem is om ou data op gelees replikas te kas. Maar hierdie probleem word opgelos oordrag van alle oordoen logs na replikas oor die interne netwerk. As die log in die kas is, word dit as verkeerd gemerk en oorgeskryf. As dit nie in die kas is nie, word dit eenvoudig weggegooi.
Ons het die stoor uitgesorteer.
Hoe om DBMS-vlakke te skaal
Hier is horisontale skaal baie moeiliker. So kom ons gaan die gebaande paadjie af klassieke vertikale skaal.
Kom ons neem aan dat ons 'n toepassing het wat met die DBBS kommunikeer deur 'n meesternodus.
Wanneer ons vertikaal skaal, ken ons 'n nuwe nodus toe wat meer verwerkers en geheue sal hê.
Vervolgens skakel ons die toepassing van die ou meesterknoop na die nuwe een oor. Probleme ontstaan.
- Dit sal aansienlike stilstand van die toepassing vereis.
- Die nuwe hoofnodus sal koue kas hê. Databasiswerkverrigting sal slegs maksimum wees nadat die kas opgewarm het.
Hoe om die situasie te verbeter? Stel 'n instaanbediener op tussen die toepassing en die hoofnodus.
Wat sal dit ons gee? Nou hoef alle toepassings nie handmatig na die nuwe nodus herlei te word nie. Die oorskakeling kan onder 'n instaanbediener gedoen word en is fundamenteel vinniger.
Dit blyk dat die probleem opgelos is. Maar nee, ons ly steeds aan die behoefte om die kas op te warm. Daarbenewens het 'n nuwe probleem verskyn - nou is die proxy 'n potensiële punt van mislukking.
Finale oplossing met Amazon Aurora bedienerloos
Hoe het ons hierdie probleme opgelos?
Het 'n gevolmagtigde gelaat. Dit is nie 'n aparte geval nie, maar 'n hele verspreide vloot gevolmagtigdes waardeur toepassings aan die databasis koppel. In die geval van mislukking, kan enige van die nodusse byna onmiddellik vervang word.
Bygevoeg 'n poel warm nodusse van verskillende groottes. As dit dus nodig is om 'n nuwe nodus van 'n groter of kleiner grootte toe te ken, is dit onmiddellik beskikbaar. Nie nodig om te wag vir dit om te laai nie.
Die hele skaalproses word deur 'n spesiale moniteringstelsel beheer. Monitering monitor voortdurend die toestand van die huidige hoofnodus. As dit byvoorbeeld bespeur dat die verwerkerlading 'n kritieke waarde bereik het, stel dit die poel warm gevalle in kennis van die behoefte om 'n nuwe nodus toe te ken.
Versprei gevolmagtigdes, warm gevalle en monitering.
'n Nodus met die vereiste krag is beskikbaar. Bufferpoele word daarna gekopieer, en die stelsel begin wag vir 'n veilige oomblik om oor te skakel.
Gewoonlik kom die oomblik om oor te skakel redelik vinnig. Dan word kommunikasie tussen die instaanbediener en die ou meesterknoop opgeskort, alle sessies word na die nuwe nodus oorgeskakel.
Werk met die databasis hervat.
Die grafiek wys dat die vering inderdaad baie kort is. Die blou grafiek wys die las, en die rooi stappe wys die skaalmomente. Korttermyn-dalings in die blou grafiek is presies daardie kort vertraging.
Terloops, Amazon Aurora laat jou toe om heeltemal geld te spaar en die databasis af te skakel wanneer dit nie in gebruik is nie, byvoorbeeld oor naweke. Nadat die vrag gestop is, verminder die DB sy krag geleidelik en skakel dit vir 'n geruime tyd af. Wanneer die vrag terugkom, sal dit weer glad styg.
In die volgende deel van die storie oor die Amazon-toestel, sal ons praat oor netwerkskaal. Teken in en bly ingeskakel sodat jy nie die artikel mis nie.
Op Vasily Pantyukhin sal 'n verslag gee "" Watter ontwerppatrone vir verspreide stelsels word deur Amazon-ontwikkelaars gebruik, wat is die redes vir diensmislukkings, wat is Sel-gebaseerde argitektuur, Constant Work, Shuffle Sharding - dit sal interessant wees. Minder as 'n maand tot die konferensie - . 24 Oktober finale prysverhoging.
Bron: will.com