Облачните услуги са като магическа кутия – зададете нуждите си и ресурсите просто се появяват от нищото. Виртуални машини, бази данни, мрежа – всичко това принадлежи само на вас. Има и други тенанти в облака, но във вашата вселена вие сте единственият управител. Сигурни сте, че винаги ще получите нужните ресурси, без да се съобразявате с никой друг и сами определяте каква ще бъде мрежата. Как работи тази магия, която кара облака еластично да предоставя ресурси и напълно да изолира тенантите един от друг?
AWS облакът е мегасуперсложна система, която еволюира от 2006 г. Част от това развитие заварва Василий Пантюхин – архитект на Amazon Web Services. Като архитект, той вижда не само крайния резултат, но и трудностите, които AWS преодолява. Колкото по-добре разбирате как работи системата, толкова повече доверие имате. Затова Василий ще сподели тайните на облачните услуги на AWS. Под заглавието ще намерите устройството на физическите сървъри на AWS, еластичната мащабируемост на базата от данни, персонализираната база данни на Amazon и методи за повишаване на производителността на виртуалните машини с едновременно намаляване на разходите им. Познаването на архитектурните подходи на Amazon ще помогне за по-ефективното използване на услугите на AWS и, възможно, ще вдъхнови нови идеи за изграждане на ваши собствени решения.
За лектора: Василий Пантюхин () започва като Unix администратор в .ru компании, 6 години работи с големи сървъри на Sun Microsystem, 11 години проповядва централността на данните в EMC. Естественно, еволюира в частни облаци, а през 2017 година се насочва към публични. В момента дава технически съвети как да живеете и развивате облака AWS.
Дисклеймер: всичко, което следва, е личното мнение на Василий и не трябва непременно да съвпада с позицията на Amazon Web Services. на лекцията, на базата на която е написана статията, е достъпен на нашия YouTube канал.
Защо говоря за устройството на Amazon
Първата ми кола беше с „ръчна“ – с механична трансмисия. Това беше страхотно, защото се чувствах, че мога да управлявам колата и да я контролирам изцяло. Освен това ми харесваше, че поне донякъде разбирам как работи. Естествено, представях си устройството на трансмисията доста примитивно – горе-долу като трансмисия на велосипед.
Всичко беше страхотно, с изключение на едно — стоенето в задръствания. Изглежда, че просто седиш и нищо не правиш, но постоянно превключваш предавките, натискаш съединителя, газта, спирачките — от това наистина се уморяваш. Проблемът с задръстванията отчасти се реши, когато в семейството дойде кола с автоматична трансмисия. Зад волана имам време за размисъл, да слушам аудиокниги.
В живота ми се появи загадка, защото изобщо спрях да разбирам как работи колата ми. Съвременният автомобил е сложна машина. Той се адаптира едновременно към десетки различни параметри: натиск на газта, спирачка, стил на управление, качество на пътя. Аз вече не разбирам как работи това.
Когато започнах да се занимавам с облака на Amazon, това също беше тайна за мен. Но тази тайна е на порядък по-висока, защото в колата има един шофьор, а в AWS - милиони. Всички потребители едновременно шофират, натискат газта и спирачките. Учудващо е, че те отиват там, където искат — за мен е чудо! Системата автоматично се адаптира, мащабира се и еластично се приспособява към всеки потребител така, че му се струва, че той е единственият в тази Вселена.
Магията малко се развея, когато по-късно започнах работа като архитект в Amazon. Видях с какви проблеми се сблъскваме, как ги решаваме, как развиваме услугите. С нарастващото разбиране на работата на системата се появява повече доверие в услугата. Затова искам да споделя картината на това, което е под капака на облака AWS.
За какво ще говорим
Избрах диверсифициран подход — подбрах 4 интересни услуги, за които си струва да говоря.
Оптимизация на сървъри. Ефемерни облаци с физическо проявление: физически датацентрове, където стоят физически сървъри, които бучат, се нагряват и мигат с лампички.
Безсървърни функции (Lambda) — вероятно най-мащабируемата услуга в облака.
Мащабиране на база данни. Ще говоря за това как изграждаме собствените си мащабируеми БД.
Мащабиране на мрежата. Последната част, в която ще открия устройството на нашата мрежа. Това е чудесно нещо — всеки потребител на облака вярва, че е единствен в облака и изобщо не вижда други наематели.
Забележка. В тази статия ще обсъдим оптимизация на сървъри и мащабиране на БД. Мащабирането на мрежата ще бъде разгледано в следващата статия. Къде са безсървърните функции? За тях излезе отделно обяснение "'. В него се разказва за няколко различни начина за мащабиране и подробно е анализирано решението Firecracker — симбиоза на най-добрите характеристики на виртуалните машини и контейнерите.
Сървъри
Облачното ефимерно. Но тази ефимерност все пак има физическо проявление — сървъри. Първоначалната им архитектура беше класическа. Стандартен x86 чипсет, мрежови карти, Linux, хипервизор Xen, на който се стартираха виртуални машини.
През 2012 година тази архитектура напълно изпълняваше задачите си. Xen е отличен хипервизор, но с един сериозен недостатък. Той има достатъчно високи разходи за емуляция на устройства. С появата на нови по-бързи мрежови карти или SSD дискове тези разходи стават прекалено високи. Как да се справим с този проблем? Решихме да работим едновременно по два фронта — оптимизиране и на хардуера, и на хипервизора. Задачата е много сериозна.
Оптимизация на хардуера и хипервизора
Не можем да направим всичко едновременно и добре. Какво означава "добре", първоначално също не беше ясно.
Решихме да приложим еволюционен подход — променяме един важен елемент на архитектурата и го пускаме в продукция.
Настъпваме на всички грабли, изслушваме оплаквания и предложения. След това променяме друга компонента. Така, с малки инкременти, коренно променяме цялата архитектура на базата на обратна връзка от потребителите и поддръжката.
Преобразуванията започнаха през 2013 г. с най-сложния аспект — мрежата. В C3 инстанциите към стандартната мрежова карта добавиха специална карта Network Accelerator. Тя се свързваше буквално с кратък loopback кабел на предния панел. Непривлекателно, но в облака не е видимо. Затова прякото взаимодействие с хардуера принципно подобри jitter и пропускната способност на мрежата.
След това решихме да се погрижим за подобряване на достъпа до блочното съхранение на данни EBS — Elastic Block Storage. Това е комбинация от мрежа и хранилище. Сложността е в това, че ако на пазара имаше карти Network Accelerator, възможността просто да закупим хардуер Storage Accelerator не беше налична. Затова се обърнахме към стартапа Annapurna Labs, който разработи специализирани ASIC чипове за нас. Те позволиха свързването на отдалечени EBS обеми като NVMe устройства.
В инстансите C4 решихме две задачи. Първата — осигурихме основа за бъдещето с перспективната, но нова по това време технология NVMe. Втората — значително облекчихме централния процесор, прехвърляйки обработката на заявки към EBS на новата карта. Получи се успешно, затова сега Annapurna Labs е част от Amazon.
Към ноември 2017 г. осъзнахме, че е време да сменим и самия хипервизор.
Новият хипервизор беше разработен на базата на подобрени модули на ядрото KVM.
Той позволи принципно да се намалят разходите за емулация на устройства и да се работи директно с новите ASIC. Инстансите C5 бяха първите виртуални машини, под капака на които работи новият хипервизор. Нарекохме го Nitro.
Еволюция на инстансите на времевата ос.
Всички нови типове виртуални машини, които се появиха от ноември 2017 г., работят на този хипервизор. При физическите Bare Metal инстанси няма хипервизор, но тях също наричат Nitro, тъй като използват специализирани Nitro карти.
През следващите две години броят на типовете Nitro инстанси надхвърли десетките: A1, C5, M5, T3 и други.
Типове инстанси.
Как са устроени съвременните Nitro машини
Те имат три основни компонента: Nitro хипервизор (за него споменахме по-горе), чип за сигурност и Nitro карти.
Чипът за сигурност е интегриран директно в дънната платка. Той контролира множество важни функции, например, управлението на зареждането на хостовата операционна система.
Nitro картите — съществуват четири типа. Всички те са разработени от Annapurna Labs и се основават на общи ASIC. Част от фърмуера им също е общ.
Четирите типа Nitro карти.
Една от картите е предназначена за работа с мрежатаVPC. Точно тя се вижда в виртуалките като мрежова карта ENA — Elastic Network Adaptor. Също така инкапсулира трафика при предаване през физическата мрежа (за това ще говорим във втората част на статията), контролира защитната стена Security Groups, отговаря за маршрутизацията и други мрежови функции.
Отделни карти работят с блочно хранилище EBS и дискове, които са вградени в сървъра. На гостуващата виртуална машина те се представят като NVMe адаптери. Също така отговарят за шифроването на данните и мониторинга на дисковете.
Системата от Nitro карти, хипервизора и чипа за сигурност е обединена в мрежа SDN или Software Defined Network. За управлението на тази мрежа (Control Plane) отговаря контролер на карта.
Разбира се, продължаваме разработката на нови ASIC. Например, в края на 2018 г. публикувахме чип Inferentia, който позволява по-ефективно справяне с задачи на машинното обучение.
Чип Inferentia Машинен Процесор за Обучение.
Мащабируема база данни
Традиционната база данни има слоеста структура. Ако опростим значително, можем да откроим следните нива.
- SQL — на него работят клиентските и заявъчните диспетчери.
- Осигуряване на транзакции — тук всичко е ясно, ACID и всичко такова.
- Кеширане, което се осигурява от буферни пулове.
- Логиране — осигурява работа с redo-логовете. В MySQL те се наричат Bin Logs, в PosgreSQL — Write Ahead Logs (WAL).
- Съхранение – непосредствено запис на диск.
Слоеста структура на базата данни.
Съществуват различни методи за мащабиране на бази данни: шардировка, архитектура Shared Nothing, споделени дискове.
Въпреки това, всички тези методи запазват същата монолитна структура на базата данни. Това значително ограничава мащабирането. За да разрешим този проблем, разработихме собствена БД — Amazon Aurora. Тя е съвместима с MySQL и PostgreSQL.
Amazon Aurora
Основната архитектурна идея е да отделим нивата на съхранение и логиране от основната БД.
Говоря напред, ние също направихме нивото на кеширане независимо. Архитектурата престава да бъде монолитна и получаваме допълнителни степени на свобода в мащабирането на отделни блокове.
Нивата на логиране и съхранение са отделени от базата данни.
Традиционната СУБД записва данни в системата за съхранение под формата на блокове. В Amazon Aurora създадохме "умно" хранилище, което може да комуникира на езика redo-логове. Вътре в себе си хранилището превръща логовете в блокове данни, следи за тяхната цялост и автоматично прави резервни копия.
Този подход позволява реализирането на интересни неща като клониране. То работи принципно по-бързо и икономично, тъй като не изисква създаването на пълна копия на всички данни.
Нивото на съхранение е реализирано под формата на разпределена система. Тя се състои от много физически сървъри. Всеки redo-лог се обработва и съхранява едновременно от шест възела. Това осигурява защита на данните и разпределение на натоварването.
Мащабиране за четене може да се осигури чрез подходящи реплики. Разпределеното хранилище премахва необходимостта от синхронизация между главния инстанс на БД, през който записваме данни, и останалите реплики. Актуалните данни са гарантирано достъпни за всички реплики.
Единствената проблема е кеширането на стари данни на репликите за четене. Но този проблем може да бъде решен чрез предаване на всички redo логове на репликите през вътрешната мрежа. Ако логът е в кеша, той се маркира като некоректен и се презаписва. Ако го няма в кеша, той просто се отхвърля.
С хранилището разбрахме.
Как да мащабираме нивата на СУБД
Тук хоризонталното мащабиране е много по-сложно. Затова ще следваме утъпканата пътека на класическото вертикално мащабиране.
Да предположим, че имаме приложение, което комуникира с СУБД чрез мастер нода.
При вертикалното мащабиране отделяме нова нода, която ще има повече процесори и памет.
След това прехвърляме приложението от старата мастер нода на новата. Възникват проблеми.
- Това ще изисква значително разпространение на приложението.
- Новата мастер нода ще има студен кеш. Производителността на БД ще бъде максимална само след загряване на кеша.
Как да подобрим ситуацията? Да поставим прокси между приложението и мастер нода.
Какво ще ни даде това? Сега не е необходимо ръчно да пренасочваме всички приложения към новата нода. Преключването може да се направи под проксито и така принципно по-бързо.
Изглежда, че проблемът е решен. Но не, все още страдаме от необходимостта да загряваме кеша. Освен това, възникна нов проблем – сега проксито е потенциална точка на отхвърляне.
Крайното решение с Amazon Aurora serverless
Как решихме тези проблеми?
Оставихме прокси.. Това не е отделен инстанс, а цял разпределен флот прокси, през който приложенията се свързват с БД. Всяка от нодовете при повреда може да бъде заменена почти мигновено.
Добавихме пул от топли ноди с различен размер. Затова, при необходимост от отделяне на нова нода с по-голям или по-малък размер, тя е веднага достъпна. Не е нужно да чакаме, докато се зареди.
Целият процес на мащабиране се контролира от специализирана система за мониторинг. Мониторинг постоянно следи за състоянието на текущата мастер-нод. Ако открие, например, че натоварването на процесора е достигнало критично ниво, уведомява пула с топли инстанции за необходимостта от отделяне на нова нода.
Разпределени проксита, топли инстанции и мониторинг.
Нодата с необходимата мощност е налична. На нея се копират буферните пулове и системата започва да очаква безопасен момент за превключване.
Обикновено моментът за превключване настъпва доста бързо. Тогава комуникацията между проксито и старата мастер-ноода се прекъсва, всички сесии се пренасочват към новата нода.
Работата с базата данни се възобновява.
На графиката е видно, че прекъсването е наистина много кратко. На синята графика е натоварването, а на червените стъпала — моментите на мащабиране. Кратките спадове в синята графика именно са тази кратка закъснение.
Между другото, Amazon Aurora позволява да спестите и да изключите БД, когато не се използва, например, през уикендите. След спирането натоварването постепенно намалява мощността си и за известно време се изключва. Когато натоварването се върне, тя постепенно се повишава отново.
В следващата част от разказа за устройството на Amazon ще говорим за мащабирането на мрежата. Абонирайте се и следете актуализациите, за да не пропуснете статията.
На Василий Пантюхин ще изнесе доклад «». Какви проектни шаблони използват разработчиците на Amazon, какви могат да бъдат причините за откази на услугите, какво е Cell-based architecture, Constant Work, Shuffle Sharding — ще е интересно. До конференцията остават по-малко от един месец — . 24 октомври окончателно повишаване на цените.
Източник: habr.com
