Wolken zijn als een magische doos: je vraagt wat je nodig hebt, en de hulpbronnen verschijnen zomaar uit het niets. Virtuele machines, databases, netwerk - dit alles is alleen van jou. Er zijn andere cloudtenants, maar in jouw universum ben jij de enige heerser. Je bent er zeker van dat je altijd de benodigde middelen krijgt, je houdt met niemand rekening en bepaalt zelfstandig hoe het netwerk eruit komt te zien. Hoe werkt deze magie die ervoor zorgt dat de cloud bronnen elastisch toewijst en tenants volledig van elkaar isoleert?
De AWS-cloud is een mega-supercomplex systeem dat sinds 2006 evolutionair evolueert. Een deel van deze ontwikkeling vond plaats Vasili Pantjoechin - Amazon Web Services-architect. Als architect krijgt hij niet alleen een kijkje in het eindresultaat, maar ook in de uitdagingen die AWS overwint. Hoe groter het begrip van hoe het systeem werkt, hoe groter het vertrouwen. Daarom zal Vasily de geheimen van AWS-clouddiensten delen. Hieronder vindt u het ontwerp van fysieke AWS-servers, elastische databaseschaalbaarheid, een aangepaste Amazon-database en methoden om de prestaties van virtuele machines te verbeteren en tegelijkertijd de prijs ervan te verlagen. Kennis van de architecturale benaderingen van Amazon zal je helpen AWS-services effectiever te gebruiken en kan je nieuwe ideeën geven voor het bouwen van je eigen oplossingen.
Over de spreker: Vasily Pantyukhin () begon als Unix-beheerder bij .ru-bedrijven, werkte zes jaar aan grote Sun Microsystem-hardware en predikte elf jaar lang een datacentrische wereld bij EMC. Het evolueerde op natuurlijke wijze naar private clouds en verhuisde in 6 naar publieke clouds. Nu geeft hij technisch advies om te helpen leven en ontwikkelen in de AWS-cloud.
Disclaimer: alles hieronder is de persoonlijke mening van Vasily en valt mogelijk niet samen met het standpunt van Amazon Web Services. Het rapport waarop het artikel is gebaseerd, is beschikbaar op ons YouTube-kanaal.
Waarom heb ik het over het Amazon-apparaat?
Mijn eerste auto had een handgeschakelde versnellingsbak. Het was geweldig vanwege het gevoel dat ik de auto kon besturen en er volledige controle over had. Ik vond het ook leuk dat ik het principe van de werking ervan in ieder geval ongeveer begreep. Natuurlijk stelde ik me de structuur van de doos vrij primitief voor - zoiets als een versnellingsbak op een fiets.
Alles was geweldig, behalve één ding: vastzitten in de file. Het lijkt alsof je zit en niets doet, maar je bent voortdurend aan het schakelen, de koppeling intrapt, gas geeft, remt - je wordt er echt moe van. Het fileprobleem werd gedeeltelijk opgelost toen het gezin een automaat kreeg. Tijdens het rijden had ik tijd om ergens over na te denken en naar een audioboek te luisteren.
Er verscheen een ander mysterie in mijn leven, omdat ik helemaal niet meer begreep hoe mijn auto werkt. Een moderne auto is een complex apparaat. De auto past zich tegelijkertijd aan aan tientallen verschillende parameters: gas geven, remmen, rijstijl, wegkwaliteit. Ik begrijp niet meer hoe het werkt.
Toen ik aan de Amazon-cloud begon te werken, was het voor mij ook een mysterie. Alleen dit mysterie is een orde van grootte groter, omdat er één bestuurder in de auto zit, en in AWS zijn dat er miljoenen. Alle gebruikers sturen tegelijkertijd, geven gas en remmen. Het is verbazingwekkend dat ze gaan waar ze willen - voor mij is het een wonder! Het systeem past zich automatisch aan, schaalt en past zich elastisch aan elke gebruiker aan, zodat het voor hem lijkt alsof hij alleen is in dit universum.
De magie verdween een beetje toen ik later als architect bij Amazon kwam werken. Ik zag met welke problemen we worden geconfronteerd, hoe we deze oplossen en hoe we diensten ontwikkelen. Naarmate het inzicht in de werking van het systeem toeneemt, ontstaat er meer vertrouwen in de dienstverlening. Daarom wil ik een foto delen van wat zich onder de motorkap van de AWS-cloud bevindt.
Waar zullen we over praten
Ik heb voor een gediversifieerde aanpak gekozen: ik heb 4 interessante diensten geselecteerd die de moeite waard zijn om over te praten.
Serveroptimalisatie. Kortstondige wolken met een fysieke belichaming: fysieke datacenters waar fysieke servers staan die zoemen, opwarmen en knipperen met licht.
Serverloze functies (Lambda) is waarschijnlijk de meest schaalbare dienst in de cloud.
Schalen van databases. Ik zal je vertellen hoe we onze eigen schaalbare databases bouwen.
Netwerkschaling. Het laatste deel waarin ik het apparaat van ons netwerk zal openen. Dit is iets geweldigs: elke cloudgebruiker gelooft dat hij alleen in de cloud is en helemaal geen andere huurders ziet.
Opmerking. In dit artikel worden serveroptimalisatie en databaseschaling besproken. In het volgende artikel zullen we netwerkschaling bespreken. Waar zijn de serverloze functies? Er werd een apart transcript over hen gepubliceerd “" Er wordt gesproken over verschillende schaalmethoden en in detail wordt de Firecracker-oplossing besproken: een symbiose van de beste eigenschappen van een virtuele machine en containers.
Servers
De wolk is vluchtig. Maar deze kortstondigheid heeft nog steeds een fysieke belichaming: servers. Aanvankelijk was hun architectuur klassiek. Standaard x86 chipset, netwerkkaarten, Linux, Xen hypervisor waarop virtuele machines draaiden.
In 2012 kon deze architectuur zijn taken redelijk goed aan. Xen is een geweldige hypervisor, maar heeft één groot nadeel. Hij heeft genoeg hoge overhead voor apparaatemulatie. Naarmate er nieuwe, snellere netwerkkaarten of SSD-schijven beschikbaar komen, wordt deze overhead te hoog. Hoe dit probleem aan te pakken? We besloten om op twee fronten tegelijk te werken: optimaliseer zowel hardware als hypervisor. De taak is zeer serieus.
Optimaliseren van hardware en hypervisor
Alles tegelijk doen en het goed doen, zal niet werken. Wat ‘goed’ was, was aanvankelijk ook onduidelijk.
We besloten een evolutionaire aanpak te volgen: we veranderen een belangrijk element van de architectuur en brengen het in productie.
We trappen op elke hark, luisteren naar klachten en suggesties. Dan veranderen we een ander onderdeel. Dus in kleine stappen veranderen we de hele architectuur radicaal op basis van feedback van gebruikers en ondersteuning.
De transformatie begon in 2013 met het meest complexe ding: het netwerk. IN С3 In sommige gevallen werd een speciale Network Accelerator-kaart toegevoegd aan de standaard netwerkkaart. Het was letterlijk verbonden met een korte loopback-kabel op het voorpaneel. Het is niet mooi, maar het is niet zichtbaar in de cloud. Maar directe interactie met hardware verbeterde de jitter en de netwerkdoorvoer fundamenteel.
Vervolgens hebben we besloten om de toegang tot blokgegevensopslag EBS - Elastic Block Storage te verbeteren. Het is een combinatie van netwerk en opslag. Het probleem is dat hoewel er Network Accelerator-kaarten op de markt waren, er geen optie was om simpelweg Storage Accelerator-hardware te kopen. Daarom zijn we overgestapt op een startup Annapurna Labs, die speciale ASIC-chips voor ons heeft ontwikkeld. Ze maakten het mogelijk om externe EBS-volumes als NVMe-apparaten te koppelen.
In gevallen C4 we hebben twee problemen opgelost. De eerste is dat we een basis hebben gelegd voor de toekomst van de veelbelovende, maar toen nieuwe NVMe-technologie. Ten tweede hebben we de centrale processor aanzienlijk ontlast door de verwerking van verzoeken aan EBS over te dragen naar een nieuwe kaart. Het pakte goed uit, dus nu is Annapurna Labs onderdeel van Amazon.
In november 2017 beseften we dat het tijd was om de hypervisor zelf te veranderen.
De nieuwe hypervisor is ontwikkeld op basis van aangepaste KVM-kernelmodules.
Het maakte het mogelijk om de overhead van apparaatemulatie fundamenteel te verminderen en rechtstreeks met nieuwe ASIC's te werken. Instanties С5 waren de eerste virtuele machines met een nieuwe hypervisor onder de motorkap. Wij hebben hem genoemd Nitro.
Evolutie van instanties op de tijdlijn.
Op deze hypervisor draaien alle nieuwe soorten virtuele machines die sinds november 2017 zijn verschenen. Bare Metal-instanties hebben geen hypervisor, maar ze worden ook Nitro genoemd, omdat ze gespecialiseerde Nitro-kaarten gebruiken.
In de daaropvolgende twee jaar overschreed het aantal typen Nitro-instanties enkele tientallen: A1, C5, M5, T3 en andere.
Instantietypen.
Hoe moderne Nitro-machines werken
Ze hebben drie hoofdcomponenten: de Nitro-hypervisor (hierboven besproken), de beveiligingschip en de Nitro-kaarten.
Beveiligingschip rechtstreeks in het moederbord geïntegreerd. Het bestuurt veel belangrijke functies, zoals het regelen van het laden van het host-besturingssysteem.
Nitro-kaarten - Er zijn vier soorten. Ze zijn allemaal ontwikkeld door Annapurna Labs en zijn gebaseerd op gemeenschappelijke ASIC's. Sommige van hun firmware zijn ook gebruikelijk.
Vier soorten Nitro-kaarten.
Eén van de kaarten is ontworpen om mee te werken netwerkVPC. Dit is wat in virtuele machines zichtbaar is als een netwerkkaart ENA - Elastische netwerkadapter. Het kapselt ook verkeer in wanneer het via een fysiek netwerk wordt verzonden (we zullen hierover praten in het tweede deel van het artikel), controleert de firewall van Security Groups en is verantwoordelijk voor routering en andere netwerkzaken.
Bepaalde kaarten werken met blokopslag EBS en schijven die in de server zijn ingebouwd. Ze verschijnen voor de virtuele gastmachine als NVMe-adapters. Ze zijn ook verantwoordelijk voor gegevensversleuteling en schijfmonitoring.
Het systeem van Nitro-kaarten, hypervisor en beveiligingschip is geïntegreerd in een SDN-netwerk of Softwaregedefinieerd netwerk. Verantwoordelijk voor het beheer van dit netwerk (Control Plane) controlekaart.
Uiteraard blijven we nieuwe ASIC’s ontwikkelen. Zo brachten ze eind 2018 de Inferentia-chip uit, waarmee je efficiënter kunt werken met machine learning-taken.
Inferentia Machine Learning-processorchip.
Schaalbare database
Een traditionele database heeft een gelaagde structuur. Ter vereenvoudiging worden de volgende niveaus onderscheiden.
- SQL — klant- en verzoekcoördinatoren werken eraan.
- Bepalingen transacties - alles is hier duidelijk, ZUUR en zo.
- caching, die wordt geleverd door bufferpools.
- Loggen — biedt werk met redo-logboeken. In MySQL worden ze Bin Logs genoemd, in PosgreSQL - Write Ahead Logs (WAL).
- opslagruimte – directe opname op schijf.
Gelaagde databasestructuur.
Er zijn verschillende manieren om databases te schalen: sharding, Shared Nothing-architectuur, gedeelde schijven.
Al deze methoden behouden echter dezelfde monolithische databasestructuur. Dit beperkt de schaalvergroting aanzienlijk. Om dit probleem op te lossen, hebben we onze eigen database ontwikkeld − Amazon Aurora. Het is compatibel met MySQL en PostgreSQL.
Amazon Aurora
Het belangrijkste architectonische idee is om de opslag- en logboekniveaus te scheiden van de hoofddatabase.
Vooruitkijkend zal ik zeggen dat we ook het cachingniveau onafhankelijk hebben gemaakt. De architectuur is niet langer een monoliet en we krijgen extra vrijheidsgraden bij het schalen van individuele blokken.
De log- en opslagniveaus zijn gescheiden van de database.
Een traditioneel DBMS schrijft gegevens in de vorm van blokken naar een opslagsysteem. Bij Amazon Aurora hebben we slimme opslag gecreëerd die taal spreekt logs opnieuw uitvoeren. Binnenin zet de opslag logs om in datablokken, bewaakt hun integriteit en maakt automatisch back-ups.
Met deze aanpak kun je zulke interessante dingen implementeren als klonen. Het werkt fundamenteel sneller en zuiniger omdat er geen volledige kopie van alle gegevens hoeft te worden gemaakt.
De opslaglaag is geïmplementeerd als een gedistribueerd systeem. Het bestaat uit een zeer groot aantal fysieke servers. Elk redo-logboek wordt tegelijkertijd verwerkt en opgeslagen zes knopen. Dit garandeert gegevensbescherming en taakverdeling.
Leesschaling kan worden bereikt met behulp van geschikte replica's. Gedistribueerde opslag elimineert de noodzaak van synchronisatie tussen het hoofddatabase-exemplaar, waarmee we gegevens schrijven, en de resterende replica's. Voor alle replica's zijn gegarandeerd actuele gegevens beschikbaar.
Het enige probleem is het cachen van oude gegevens op leesreplica's. Maar dit probleem wordt opgelost overdracht van alle redo-logs naar replica's via het interne netwerk. Als het logboek zich in de cache bevindt, wordt het als onjuist gemarkeerd en overschreven. Als het niet in de cache staat, wordt het gewoon weggegooid.
Wij hebben de opslag geregeld.
DBMS-lagen schalen
Hier is horizontaal schalen veel moeilijker. Laten we dus de gebaande paden bewandelen klassieke verticale schaling.
Laten we aannemen dat we een applicatie hebben die via een masternode met het DBMS communiceert.
Bij verticaal schalen wijzen we een nieuw knooppunt toe dat meer processors en geheugen zal hebben.
Vervolgens schakelen we de applicatie over van het oude masterknooppunt naar het nieuwe. Er ontstaan problemen.
- Dit vergt aanzienlijke downtime van applicaties.
- Het nieuwe hoofdknooppunt heeft een koude cache. De databaseprestaties zijn pas maximaal nadat de cache is opgewarmd.
Hoe de situatie verbeteren? Stel een proxy in tussen de applicatie en het masterknooppunt.
Wat zal dit ons opleveren? Nu hoeven niet alle applicaties handmatig doorgestuurd te worden naar het nieuwe knooppunt. De overstap kan onder een proxy worden uitgevoerd en is fundamenteel sneller.
Het lijkt erop dat het probleem is opgelost. Maar nee, we hebben nog steeds last van de noodzaak om de cache op te warmen. Bovendien is er een nieuw probleem opgedoken: nu is de proxy een potentieel faalpunt.
Eindoplossing met Amazon Aurora serverloos
Hoe hebben we deze problemen opgelost?
Heeft een proxy achtergelaten. Dit is geen afzonderlijk exemplaar, maar een hele gedistribueerde vloot van proxy's waarmee applicaties verbinding maken met de database. In geval van een storing kan elk knooppunt vrijwel onmiddellijk worden vervangen.
Een pool van warme knooppunten van verschillende groottes toegevoegd. Als het nodig is om een nieuw knooppunt van grotere of kleinere omvang toe te wijzen, is dit daarom onmiddellijk beschikbaar. U hoeft niet te wachten tot het is geladen.
Het gehele schaalproces wordt gecontroleerd door een speciaal monitoringsysteem. Monitoring bewaakt voortdurend de status van het huidige masterknooppunt. Als het bijvoorbeeld detecteert dat de processorbelasting een kritieke waarde heeft bereikt, informeert het de pool van warme instances over de noodzaak om een nieuw knooppunt toe te wijzen.
Gedistribueerde proxy's, warme instanties en monitoring.
Er is een knooppunt met het benodigde vermogen beschikbaar. Bufferpools worden ernaar gekopieerd en het systeem begint te wachten op een veilig moment om over te schakelen.
Meestal komt het moment om te wisselen vrij snel. Vervolgens wordt de communicatie tussen de proxy en het oude masterknooppunt opgeschort, alle sessies worden overgeschakeld naar het nieuwe knooppunt.
Werken met de database-cv's.
Uit de grafiek blijkt dat de schorsing inderdaad erg kort is. De blauwe grafiek toont de belasting, en de rode stappen tonen de schaalmomenten. Kortetermijndalingen in de blauwe grafiek zijn precies die korte vertraging.
Trouwens, met Amazon Aurora kun je volledig geld besparen en de database uitschakelen wanneer deze niet in gebruik is, bijvoorbeeld in het weekend. Na het stoppen van de belasting vermindert de DB geleidelijk zijn vermogen en schakelt hij enige tijd uit. Wanneer de lading terugkeert, komt deze weer soepel omhoog.
In het volgende deel van het verhaal over het Amazon-apparaat zullen we het hebben over netwerkschaling. Abonneren en blijf op de hoogte, zodat je het artikel niet mist.
Op Vasily Pantyukhin zal een rapport geven “" Welke ontwerppatronen voor gedistribueerde systemen worden gebruikt door Amazon-ontwikkelaars, wat zijn de redenen voor servicestoringen, wat is Cell-gebaseerde architectuur, Constant Work, Shuffle Sharding - het zal interessant zijn. Minder dan een maand tot de conferentie - . 24 oktober definitieve prijsverhoging.
Bron: www.habr.com