A felhők olyanok, mint egy varázsdoboz – megkérdezed, mire van szükséged, és az erőforrások egyszerűen előbukkannak a semmiből. Virtuális gépek, adatbázisok, hálózat – mindez csak az Öné. Vannak más felhőbérlők is, de az Univerzumban te vagy az egyedüli uralkodó. Biztos benne, hogy mindig megkapja a szükséges erőforrásokat, nem vesz figyelembe senkit, és önállóan határozza meg, hogy milyen lesz a hálózat. Hogyan működik ez a varázslat, amely arra készteti a felhőt, hogy rugalmasan allokálja az erőforrásokat, és teljesen elszigeteli egymástól a bérlőket?
Az AWS felhő egy mega-szuper komplex rendszer, amely 2006 óta evolúciósan fejlődik. Ennek a fejlődésnek egy része megtörtént Vaszilij Pantyukhin - Amazon Web Services Architect. Építészként nemcsak a végeredményt tekintheti meg belülről, hanem az AWS által leküzdött kihívásokat is. Minél jobban megértjük a rendszer működését, annál nagyobb a bizalom. Ezért Vaszilij megosztja az AWS felhőszolgáltatások titkait. Az alábbiakban bemutatjuk a fizikai AWS-kiszolgálók tervezését, az adatbázis rugalmas méretezhetőségét, az egyedi Amazon adatbázist és a virtuális gépek teljesítményének növelésére szolgáló módszereket, miközben csökkentik azok árát. Az Amazon építészeti megközelítéseinek ismerete segít az AWS-szolgáltatások hatékonyabb használatában, és új ötleteket adhat saját megoldásainak kidolgozásához.
Az előadóról: Vaszilij Pantyukhin () Unix adminisztrátorként indult a .ru cégeknél, 6 évig dolgozott nagy Sun Microsystem hardvereken, és 11 évig az EMC-nél hirdetett adatközpontú világot. Természetesen privát felhőkké fejlődött, és 2017-ben nyilvános felhőkké vált. Most technikai tanácsokat ad az AWS felhőben való élethez és fejlődéshez.
Jogi nyilatkozat: az alábbiakban leírtak Vaszilij személyes véleménye, és nem feltétlenül esnek egybe az Amazon Web Services álláspontjával. A cikk alapjául szolgáló riport elérhető YouTube csatornánkon.
Miért beszélek az Amazon készülékről?
Az első autómban manuális sebességváltó volt. Nagyszerű volt, mert az az érzésem, hogy vezethetem az autót, és teljesen irányíthatom azt. Az is tetszett, hogy legalább nagyjából megértettem a működési elvét. Természetesen a doboz szerkezetét meglehetősen primitívnek képzeltem el - olyasmi, mint egy sebességváltó a kerékpáron.
Minden nagyszerű volt, egy dolgot kivéve – elakadt a forgalmi dugókban. Úgy tűnik, ülsz és nem csinálsz semmit, de folyamatosan váltasz, nyomod a kuplungot, a gázt, a féket – ez nagyon elfárad. A dugóprobléma részben megoldódott, amikor a család automata autót kapott. Vezetés közben volt időm gondolkodni valamin, és hangoskönyvet hallgatni.
Újabb rejtély jelent meg az életemben, mert teljesen abbahagytam, hogy megértsem az autóm működését. A modern autó egy összetett eszköz. Az autó egyszerre több tucat különböző paraméterhez alkalmazkodik: gáznyomás, fék, vezetési stílus, útminőség. Már nem értem, hogy működik.
Amikor elkezdtem dolgozni az Amazon felhőjén, ez is rejtély volt számomra. Csak ez a rejtély egy nagyságrenddel nagyobb, mert az autóban egy sofőr van, az AWS-ben pedig több millióan. Minden felhasználó egyszerre kormányoz, nyomja meg a gázt és fékezzen. Csodálatos, hogy oda mennek, ahová akarnak – ez számomra egy csoda! A rendszer automatikusan alkalmazkodik, méreteződik és rugalmasan alkalmazkodik minden felhasználóhoz, hogy úgy tűnjön neki, hogy egyedül van ebben az Univerzumban.
A varázslat egy kicsit alábbhagyott, amikor később építészként dolgoztam az Amazonnál. Láttam, milyen problémákkal nézünk szembe, hogyan oldjuk meg azokat, és hogyan fejlesztjük a szolgáltatásokat. A rendszer működésének egyre jobban megértésével egyre nagyobb bizalom jelenik meg a szolgáltatás iránt. Ezért szeretnék megosztani egy képet arról, hogy mi van az AWS felhő burkolata alatt.
Miről beszélgessünk
Szerteágazó megközelítést választottam - kiválasztottam 4 érdekes szolgáltatást, amelyekről érdemes beszélni.
Szerver optimalizálás. Múlékony felhők fizikai megtestesüléssel: fizikai adatközpontok, ahol fizikai szerverek vannak, amelyek zúgnak, felmelegszenek és fényekkel villognak.
Szerver nélküli funkciók (Lambda) valószínűleg a leginkább méretezhető szolgáltatás a felhőben.
Adatbázis méretezése. Elmondom, hogyan építjük fel saját méretezhető adatbázisainkat.
Hálózati méretezés. Az utolsó rész, amelyben megnyitom a hálózatunk eszközét. Ez csodálatos dolog - minden felhőfelhasználó azt hiszi, hogy egyedül van a felhőben, és egyáltalán nem lát más bérlőket.
Jegyzet. Ez a cikk a szerveroptimalizálást és az adatbázis-méretezést tárgyalja. A következő cikkben megvizsgáljuk a hálózati skálázást. Hol vannak a szerver nélküli funkciók? Külön átirat jelent meg róluk" Számos különböző skálázási módszerről beszél, és részletesen tárgyalja a Firecracker megoldást – a virtuális gép és a konténerek legjobb tulajdonságainak szimbiózisát.
Kiszolgálók
A felhő mulandó. Ennek a mulandóságnak azonban van egy fizikai megtestesülése - a szerverek. Kezdetben építészetük klasszikus volt. Szabványos x86 lapkakészlet, hálózati kártyák, Linux, Xen hypervisor, amelyen a virtuális gépek futottak.
2012-ben ez az architektúra elég jól megbirkózott a feladataival. A Xen nagyszerű hipervizor, de van egy nagy hátránya. Elege van magas rezsi az eszköz emulációhoz. Ahogy új, gyorsabb hálózati kártyák vagy SSD-meghajtók válnak elérhetővé, ez a rezsi túl magas lesz. Hogyan kezeljük ezt a problémát? Úgy döntöttünk, hogy egyszerre két fronton dolgozunk - optimalizálja mind a hardvert, mind a hypervisort. A feladat nagyon komoly.
A hardver és a hypervisor optimalizálása
Ha mindent egyszerre és jól csinálsz, az nem fog működni. Kezdetben az sem volt világos, hogy mi a „jó”.
Úgy döntöttünk, hogy evolúciós megközelítést alkalmazunk – megváltoztatjuk az építészet egyik fontos elemét, és bedobjuk a gyártásba.
Minden gereblyére rálépünk, meghallgatjuk a panaszokat, javaslatokat. Ezután egy másik alkatrészt cserélünk. Így kis lépésekben gyökeresen megváltoztatjuk a teljes architektúrát a felhasználók visszajelzései és a támogatás alapján.
Az átalakulás 2013-ban kezdődött a legösszetettebb dologgal - a hálózattal. BAN BEN S3 Ilyen esetekben egy speciális Network Accelerator kártya került a szabványos hálózati kártyához. Szó szerint egy rövid hurokkábellel volt csatlakoztatva az előlapon. Nem szép, de nem látszik a felhőben. A hardverrel való közvetlen interakció azonban alapvetően javította a jittert és a hálózati átviteli sebességet.
Ezt követően úgy döntöttünk, hogy javítjuk az EBS - Elastic Block Storage blokkadattárhoz való hozzáférést. Ez a hálózat és a tárolás kombinációja. A nehézség az, hogy míg a Network Accelerator kártyák léteztek a piacon, nem volt lehetőség egyszerűen Storage Accelerator hardvert vásárolni. Így hát egy startuphoz fordultunk Annapurna Labs, aki speciális ASIC chipeket fejlesztett ki számunkra. Lehetővé tették a távoli EBS-kötetek NVMe-eszközként történő csatlakoztatását.
Esetekben C4 két problémát megoldottunk. Az első az, hogy megalapoztuk a jövő ígéretes, de akkoriban újszerű NVMe technológiáját. Másodszor, jelentősen tehermentesítettük a központi processzort azzal, hogy az EBS-hez intézett kérelmek feldolgozását egy új kártyára helyeztük át. Jól sikerült, így most az Annapurna Labs az Amazon része.
2017 novemberére rájöttünk, hogy ideje megváltoztatni magát a hypervisort.
Az új hipervizort módosított KVM kernelmodulok alapján fejlesztették ki.
Lehetővé tette az eszközemuláció többletköltségének alapvető csökkentését és az új ASIC-ekkel való közvetlen együttműködést. Példányok S5 voltak az első virtuális gépek, amelyeknek a burkolata alatt új hipervizor futott. Elneveztük Nitro.
Példányok alakulása az idővonalon.
A 2017 novembere óta megjelent összes új típusú virtuális gép ezen a hipervizoron fut. A Bare Metal példányok nem rendelkeznek hypervisorral, de Nitro-nak is hívják őket, mivel speciális Nitro kártyákat használnak.
A következő két évben a Nitro példányok száma meghaladta a pár tucatot: A1, C5, M5, T3 és mások.
Példánytípusok.
Hogyan működnek a modern Nitro gépek
Három fő összetevőjük van: a Nitro hypervisor (fentebb), a biztonsági chip és a Nitro kártyák.
Biztonsági chip közvetlenül az alaplapba integrálva. Számos fontos funkciót vezérel, például a gazdagép operációs rendszer betöltésének vezérlését.
Nitro kártyák - Négyféle van belőlük. Mindegyiket az Annapurna Labs fejlesztette ki, és közös ASIC-eken alapulnak. Egyes firmware-jük is gyakori.
Négyféle Nitro kártya.
Az egyik kártyát úgy tervezték, hogy működjön hálózatVPC. Ez látható a virtuális gépekben hálózati kártyaként ENA - Rugalmas hálózati adapter. Ezenkívül beágyazza a forgalmat, amikor azt fizikai hálózaton keresztül továbbítja (erről a cikk második részében lesz szó), vezérli a Security Groups tűzfalát, és felelős az útválasztásért és egyéb hálózati dolgokért.
Egyes kártyák blokktárolóval működnek EBS és a szerverbe beépített lemezek. Úgy jelennek meg a vendég virtuális gép számára, mint NVMe adapterek. Ők felelősek az adatok titkosításáért és a lemezfigyelésért is.
A Nitro kártyák, hypervisor és biztonsági chip rendszere SDN hálózatba integrálva ill Szoftver által meghatározott hálózat. Felelős ennek a hálózatnak a kezeléséért (Control Plane) vezérlő kártya.
Természetesen folytatjuk az új ASIC-ek fejlesztését. Például 2018 végén kiadták az Inferentia chipet, amivel hatékonyabban dolgozhat a gépi tanulási feladatokkal.
Inferencia gépi tanulási processzor chip.
Skálázható adatbázis
A hagyományos adatbázisok réteges szerkezetűek. A nagy leegyszerűsítés érdekében a következő szinteket különböztetjük meg.
- SQL — a kliens és a kérvény diszpécserek dolgoznak rajta.
- Rendelkezések tranzakciók - Itt minden világos, SAV és minden.
- gyorsítótárazás, amelyet puffermedencék biztosítanak.
- Fakitermelés — munkát biztosít a redo logokkal. A MySQL-ben ezeket Bin Logs-nak, a PosgreSQL-ben - Write Ahead Logs-nak (WAL) hívják.
- tárolás – közvetlen rögzítés lemezre.
Réteges adatbázis-struktúra.
Az adatbázisok méretezésének különböző módjai vannak: felosztás, Shared Nothing architektúra, megosztott lemezek.
Ezek a módszerek azonban ugyanazt a monolitikus adatbázis-struktúrát tartják fenn. Ez jelentősen korlátozza a méretezést. A probléma megoldására saját adatbázist fejlesztettünk ki − Amazon Aurora. Kompatibilis a MySQL-lel és a PostgreSQL-lel.
Amazon Aurora
A fő felépítési ötlet a tárolási és naplózási szintek elkülönítése a fő adatbázistól.
A jövőre nézve azt mondom, hogy a gyorsítótárazási szintet is függetlenítettük. Az architektúra megszűnik monolit lenni, és további szabadsági fokokat nyerünk az egyes blokkok méretezésében.
A naplózási és tárolási szintek elkülönülnek az adatbázistól.
A hagyományos DBMS blokkok formájában adatokat ír egy tárolórendszerbe. Az Amazon Aurora-nál olyan intelligens tárhelyet hoztunk létre, amely képes nyelvet beszélni redo-logs. A tároló belsejében a naplókat adatblokkokká alakítja, figyeli azok integritását, és automatikusan biztonsági másolatot készít.
Ez a megközelítés lehetővé teszi olyan érdekes dolgok megvalósítását, mint pl klónozás. Alapvetően gyorsabban és gazdaságosabban működik, mivel nem szükséges minden adatról teljes másolatot készíteni.
A tárolóréteg elosztott rendszerként valósul meg. Nagyon sok fizikai szerverből áll. Minden újraindítási napló egyidejűleg kerül feldolgozásra és mentésre hat csomó. Ez biztosítja az adatvédelmet és a terheléselosztást.
Az olvasási skálázás megfelelő replikák használatával érhető el. Az elosztott tárolás szükségtelenné teszi a szinkronizálást a fő adatbázispéldány, amelyen keresztül adatokat írunk, és a fennmaradó replikák között. A naprakész adatok garantáltan minden replika számára elérhetőek lesznek.
Az egyetlen probléma a régi adatok gyorsítótárazása az olvasott replikákon. De ez a probléma megoldódik az összes redo napló átvitele replikákhoz a belső hálózaton keresztül. Ha a napló a gyorsítótárban van, akkor a rendszer hibásként jelöli meg és felülírja. Ha nincs a gyorsítótárban, akkor egyszerűen eldobja.
Rendbe hoztuk a tárolót.
DBMS-szintek méretezése
Itt a vízszintes méretezés sokkal nehezebb. Menjünk tehát a kitaposott úton klasszikus függőleges méretezés.
Tegyük fel, hogy van egy alkalmazásunk, amely egy fő csomóponton keresztül kommunikál a DBMS-sel.
Függőleges skálázáskor egy új csomópontot foglalunk le, amely több processzorral és memóriával rendelkezik.
Ezután átkapcsoljuk az alkalmazást a régi főcsomópontról az újra. Problémák merülnek fel.
- Ez jelentős alkalmazáskimaradást igényel.
- Az új főcsomópont hideggyorsítótárral rendelkezik. Az adatbázis teljesítménye csak a gyorsítótár felmelegedése után lesz maximális.
Hogyan lehet javítani a helyzeten? Állítson be egy proxyt az alkalmazás és a fő csomópont között.
Mit fog ez adni nekünk? Most már nem kell minden alkalmazást kézzel átirányítani az új csomópontra. A váltás proxy alatt is elvégezhető, és alapvetően gyorsabb.
Úgy tűnik, hogy a probléma megoldódott. De nem, továbbra is szenvedünk attól, hogy fel kell melegíteni a gyorsítótárat. Emellett egy új probléma is megjelent - most a proxy potenciális meghibásodási pont.
Végső megoldás az Amazon Aurora szerver nélküli szolgáltatással
Hogyan oldottuk meg ezeket a problémákat?
Hagyott egy proxyt. Ez nem egy külön példány, hanem egy teljes elosztott proxyflotta, amelyen keresztül az alkalmazások csatlakoznak az adatbázishoz. Meghibásodás esetén bármelyik csomópont szinte azonnal cserélhető.
Különböző méretű meleg csomópontok készlete hozzáadva. Ezért, ha szükség van egy nagyobb vagy kisebb méretű új csomópont kiosztására, az azonnal elérhető. Nem kell várni, amíg betöltődik.
A teljes méretezési folyamatot egy speciális felügyeleti rendszer vezérli. A felügyelet folyamatosan figyeli az aktuális főcsomópont állapotát. Ha például azt észleli, hogy a processzor terhelése elérte a kritikus értéket, akkor értesíti a meleg példányok készletét egy új csomópont kiosztásának szükségességéről.
Elosztott proxyk, meleg példányok és felügyelet.
Rendelkezésre áll a szükséges teljesítménnyel rendelkező csomópont. A puffertárak átmásolódnak rá, és a rendszer várni kezd a biztonságos pillanatra a váltáshoz.
Általában elég gyorsan eljön a váltás pillanata. Ezután a proxy és a régi főcsomópont közötti kommunikáció felfüggesztésre kerül, és minden munkamenet átkapcsol az új csomópontra.
Az adatbázissal való munka folytatódik.
A grafikon azt mutatja, hogy a felfüggesztés valóban nagyon rövid. A kék grafikon a terhelést mutatja, a piros lépések pedig a skálázási momentumokat. A kék grafikon rövid távú csökkenése pontosan ezt a rövid késleltetést jelenti.
Az Amazon Aurora egyébként lehetővé teszi, hogy teljesen pénzt takarítson meg, és kikapcsolja az adatbázist, ha éppen nincs használatban, például hétvégén. A terhelés leállítása után a DB fokozatosan csökkenti a teljesítményét, és egy időre kikapcsol. Amikor a terhelés visszatér, simán újra felemelkedik.
Az Amazon eszközről szóló történet következő részében a hálózati skálázásról lesz szó. Iratkozz fel és maradj velünk, hogy ne maradj le a cikkről.
tovább Vaszilij Pantyuhin beszámolót fog tartani" Milyen tervezési mintákat használnak az elosztott rendszerekre az Amazon fejlesztői, mi a szolgáltatáshiba oka, mi a cellaalapú architektúra, állandó munka, véletlenszerű megosztás - érdekes lesz. Kevesebb, mint egy hónap a konferenciáig . október 24-i végső áremelés.
Forrás: will.com