{"id":39302,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","title":{"rendered":"Hoe AWS zijn elastische services \"bereidt\". Schalen van servers en databases","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De cloud lijkt op een magische doos \u2014 je vraagt wat je nodig hebt en de bronnen verschijnen zomaar uit het niets. Virtuele machines, databases, netwerken \u2014 dit alles behoort uitsluitend jou toe. Er zijn ook andere tenants in de cloud, maar in jouw universum ben jij de enige heerser. Je bent ervan verzekerd dat je altijd de benodigde bronnen krijgt, houdt rekening met niemand en bepaalt zelf hoe het netwerk eruitziet. Hoe werkt deze magie die de cloud in staat stelt om flexibel bronnen toe te wijzen en tenants volledig van elkaar te isoleren?<\/p>\n

\"Hoe
\n
\nDe AWS-cloud is een megacomplex systeem dat zich evolutionair ontwikkelt sinds 2006. Een deel van deze ontwikkeling heeft Vasily Pantyukhin<\/strong> \u2014 architect van Amazon Web Services. Als architect ziet hij niet alleen het eindresultaat, maar ook de complexiteiten die AWS overwint. Hoe beter je de werking van het systeem begrijpt, hoe meer vertrouwen je hebt. Daarom zal Vasily de geheimen van AWS-cloudservices delen. Onder de knop bespreekt hij de inrichting van fysieke AWS-servers, elastische schaalbaarheid van databases, de op maat gemaakte Amazon-database en methoden om de prestaties van virtuele machines te verhogen terwijl de kosten tegelijkertijd worden verlaagd. Kennis van de architecturale benaderingen van Amazon zal je helpen de AWS-services effectiever te gebruiken en mogelijk nieuwe idee\u00ebn geven voor het bouwen van je eigen oplossingen.
\n<\/a><\/noindex>
\nOver de spreker: Vasily Pantyukhin (Hen<\/a><\/noindex>) begon als Unix-beheerder in .ru-bedrijven, werkzaam met grote machines van Sun Microsystem gedurende 6 jaar, en heeft 11 jaar de datacenterheid van de wereld gepredikt bij EMC. Hij evolueerde natuurlijk naar private clouds en stapte in 2017 over naar publieke clouds. Nu helpt hij met technische adviezen om te leven en te groeien in de AWS-cloud.<\/p>\n

Disclaimer: alles hieronder is de persoonlijke mening van Vasily en deze kan afwijken van de positie van Amazon Web Services. De videoregistratie<\/a><\/noindex> van de presentatie waarop dit artikel is gebaseerd, is beschikbaar op ons YouTube-kanaal.<\/i><\/p>\n

Waarom ik vertel over het functioneren van Amazon<\/h2>\n

\nMijn eerste auto had een \u2018handvat\u2019 \u2014 met een handgeschakelde versnellingsbak. Dat was geweldig omdat het gevoel gaf dat ik de auto kon besturen en volledige controle had. Ook vond ik het leuk dat ik tenminste een globaal begrip had van hoe het werkte. Natuurlijk stelde ik me de werking van de versnellingsbak vrij primitief voor - ongeveer zoals de versnellingsbak van een fiets.<\/p>\n

\"Hoe
\n
\nAlles was geweldig was, behalve \u00e9\u00e9n ding - vastzitten in het verkeer. Je zit daar en doet feitelijk niets, maar je schakelt constant, drukt op de koppeling, gas, rem - dat maakt je echt moe. Het probleem van verkeersopstoppingen werd gedeeltelijk opgelost toen we een automatische auto in de familie kregen. Achter het stuur heb je tijd om over dingen na te denken en naar audioboeken te luisteren.<\/p>\n

Er kwam ook een raadsel 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 tientallen verschillende parameters aan: het indrukken van het gas, de rem, de rijstijl, de wegkwaliteit. Ik begrijp al niet meer hoe dit werkt.<\/p>\n

Toen ik begon met Amazon Cloud, was dat voor mij ook een mysterie. Maar dit mysterie is van een heel andere orde, omdat er in de auto \u00e9\u00e9n bestuurder is en in AWS zijn het er miljoenen. Alle gebruikers sturen tegelijkertijd, drukken op het gas en de rem. Het is verbazingwekkend dat ze gaan waar ze willen - voor mij is dat een wonder! Het systeem past zich automatisch aan, schaalt op en elastisch aan elke gebruiker aan, zodat het lijkt alsof diegene alleen is in dit universum.<\/p>\n

De magie vervaagde een beetje toen ik later architect bij Amazon werd. Ik zag met welke problemen we te maken hebben, hoe we deze oplossen, hoe we de diensten ontwikkelen. Met de groei van mijn begrip van de werking van het systeem groeit ook het vertrouwen in de dienst. Daarom wil ik het beeld delen van wat er onder de motorkap van AWS Cloud gebeurt.<\/p>\n

Waar gaan we het over hebben<\/h2>\n

\nIk heb een gediversifieerde aanpak gekozen - ik heb vier interessante diensten geselecteerd waarover het de moeite waard is om te praten.<\/p>\n

Serveroptimalisatie<\/strong>. Vergankelijk cloud met fysieke belichaming: fysieke datacentra waar fysieke servers staan die zoemen, warm worden en knipperende lampjes hebben.<\/p>\n

Serverless-functies <\/strong>(Lambda) - waarschijnlijk de meest schaalbare dienst in de cloud.<\/p>\n

Schaalvergroting van databases<\/strong>. Ik zal vertellen hoe we onze eigen schaalbare databases bouwen.<\/p>\n

Schaalvergroting van netwerken<\/strong>. Het laatste deel waarin ik de werking van ons netwerk zal onthullen. Het is een wonderlijke zaak - elke gebruiker van de cloud denkt dat hij alleen in de cloud is en andere huurders helemaal niet ziet.<\/p>\n

Opmerking. In dit artikel zullen we het hebben over serveroptimalisatie en database-scaling. Netwerk-scaling wordt in het volgende artikel besproken. Waar zijn de serverless functies? Daarover is een afzonderlijke verklaring verschenen.Klein, maar fijn. Unboxing van de micro-virtualisatie Firecracker<\/a><\/noindex>. Hierin worden verschillende manieren van schaalvergroting besproken, en de oplossing Firecracker wordt grondig behandeld \u2014 een symbiose van de beste eigenschappen van virtuele machines en containers.<\/i><\/p><\/blockquote>\n

<\/p>\n

Servers<\/h2>\n

\nDe cloud is vluchtig. Maar deze vluchtigheid heeft nog steeds een fysieke belichaming \u2014 servers. Oorspronkelijk was hun architectuur klassiek. Standaard x86-chipset, netwerkkaarten, Linux, hypervisor Xen, waarop virtuele machines werden uitgevoerd.<\/p>\n

\"Hoe
\n
\nIn 2012 voldeed deze architectuur prima aan zijn taken. Xen is een uitstekende hypervisor, maar heeft \u00e9\u00e9n ernstig nadeel. Het heeft behoorlijk hoge overheadkosten voor apparaatsimulatie.<\/strong>Bij de komst van nieuwe, snellere netwerkkaarten of SSD's worden deze overheadkosten te hoog. Hoe met dit probleem om te gaan? We besloten om op twee fronten tegelijk te werken \u2014 zowel de hardware als de hypervisor te optimaliseren.<\/strong>De taak is zeer serieus.<\/p>\n

Optimalisatie van hardware en hypervisor<\/h3>\n

\nAlles in \u00e9\u00e9n keer goed doen zal niet mogelijk zijn. Wat 'goed' is, was aanvankelijk ook onduidelijk.<\/p>\n

We besloten een evolutionaire benadering te hanteren \u2014 we veranderen \u00e9\u00e9n belangrijk element van de architectuur en brengen het in productie.<\/p><\/blockquote>\n

We lopen tegen alle problemen aan, luisteren naar klachten en voorstellen. Daarna veranderen we het andere component. Zo, in kleine stappen, veranderen we de gehele architectuur op basis van feedback van gebruikers en ondersteuning.<\/p>\n

De transformaties begonnen in 2013 met het meest gecompliceerde \u2014 het netwerk. In C3<\/strong> instellingen werd aan de standaard netwerkkaart een speciale Network Accelerator-kaart toegevoegd. Deze werd letterlijk aangesloten met een korte loopback-kabel aan de voorzijde. Niet mooi, maar in de cloud zie je het niet. Toch verbeterde de directe interactie met de hardware de jitter en netwerksnelheid aanzienlijk.<\/p>\n

Daarna besloten we de toegang tot de Elastic Block Storage (EBS) te verbeteren \u2014 een combinatie van netwerk en opslag. De moeilijkheid was dat, hoewel er Network Accelerator-kaarten op de markt waren, het niet mogelijk was om gewoon een Storage Accelerator-hardware te kopen. Daarom hebben we contact opgenomen met de startup Annapurna Labs<\/strong>, die speciaal ontwikkelde ASIC-chips voor ons. Hiermee kunnen externe EBS-volumes als NVMe-apparaten worden aangesloten.<\/p>\n

In instanties C4<\/strong> hebben we twee problemen opgelost. De eerste was het cre\u00ebren van een toekomstbestendig fundament voor een in dat moment veelbelovende, maar nieuwe technologie: NVMe. De tweede was het aanzienlijk ontlasten van de centrale processor door de verwerking van verzoeken naar EBS naar een nieuwe kaart te verplaatsen. Het is goed gelukt, en daarom is Annapurna Labs nu onderdeel van Amazon.<\/p>\n

In november 2017 realiseerden we ons dat het tijd was om ook de hypervisor te vernieuwen.<\/p>\n

De nieuwe hypervisor is ontwikkeld op basis van aangepaste KVM-kernelmodules.<\/p><\/blockquote>\n

Deze heeft de overhead voor de emulatie van apparaten aanzienlijk verminderd en maakt directe samenwerking met de nieuwe ASIC mogelijk. Instanties C5<\/strong> waren de eerste virtuele machines die draaien op de nieuwe hypervisor. We hebben het genoemd Nitro<\/strong>.<\/p>\n

\"HoeDe evolutie van instanties op de tijdlijn.<\/em><\/p>\n

Alle nieuwe typen virtuele machines die sinds november 2017 zijn verschenen, draaien op deze hypervisor. Bare Metal-instanties hebben geen hypervisor<\/strong>, maar ze worden ook Nitro genoemd, omdat ze gespecialiseerde Nitro-kaarten gebruiken.<\/p>\n

In de volgende twee jaar nam het aantal Nitro-instanties toe tot meer dan een paar dozijn: A1, C5, M5, T3 en anderen.<\/p>\n

\"Hoe
\nTypen instanties.<\/em><\/p>\n

Hoe moderne Nitro-machines zijn opgebouwd<\/h3>\n

\nZe hebben drie hoofdbestanddelen: de Nitro-hypervisor (daarboven genoemd), een beveiligingschip en Nitro-kaarten.<\/p>\n

De beveiligingschip<\/strong> is rechtstreeks op het moederbord ge\u00efntegreerd. Hij controleert tal van belangrijke functies, zoals het controleren van de opstart van het host-besturingssysteem.<\/p>\n

Nitro-kaarten<\/strong> zijn er in vier types. Al deze zijn ontwikkeld door Annapurna Labs en zijn gebaseerd op gemeenschappelijke ASIC's. Een deel van hun firmware is ook gemeenschappelijk.<\/p>\n

\"Hoe
\nVier types Nitro-kaarten.<\/em><\/p>\n

Een van de kaarten is bedoeld voor gebruik met het netwerk<\/strong>VPC<\/strong>. Dit is zichtbaar in virtuele machines als een netwerkadapter ENA \u2014 Elastic Network Adaptor<\/strong>. Hiermee wordt ook het verkeer ingekapseld bij overdracht via het fysieke netwerk (hierover zullen we in het tweede deel van het artikel spreken), en het beheert de firewall Security Groups, verantwoordelijk voor routering en andere netwerkzaken.<\/p>\n

Verschillende kaarten werken met block storage EBS<\/strong> en schijven die in de server zijn ingebouwd. Voor de gast-VM worden ze gepresenteerd als NVMe-adapters<\/strong>. Ze zijn ook verantwoordelijk voor de versleuteling van gegevens en schijfmonitoring.<\/p>\n

Het Nitro-kaartsysteem, de hypervisor en de beveiligingschip zijn verenigd in een SDN-netwerk of Software Defined Network<\/strong>. Het beheer van dit netwerk (Control Plane) is verantwoordelijk voor kaartcontroller<\/strong>.<\/p>\n

Zeker, we blijven werken aan de ontwikkeling van nieuwe ASIC's. Zo hebben we eind 2018 de Inferentia-chip gelanceerd, die effici\u00ebnter omgaat met machine learning-taken.<\/p>\n

\"Hoe
\nInferentia Chip Machine Learning Processor.<\/em><\/p>\n

Schaalbare database<\/h2>\n

\nEen traditionele database heeft een gelaagde structuur. Als we het sterk vereenvoudigen, kunnen we de volgende lagen onderscheiden.<\/p>\n