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