Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Облаци су као магична кутија - питате шта вам треба, а ресурси се појављују ниоткуда. Виртуелне машине, базе података, мрежа - све ово припада само вама. Постоје и други закупци облака, али у вашем Универзуму ви сте једини владар. Сигурни сте да ћете увек добити потребне ресурсе, не водите рачуна о никоме и самостално одређујете каква ће бити мрежа. Како функционише ова магија која чини да облак еластично додељује ресурсе и потпуно изолује станаре једни од других?

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

АВС облак је мега-супер сложен систем који се еволутивно развија од 2006. године. Део овог развоја се десио Василиј Пантјухин - Амазон Веб Сервицес Арцхитецт. Као архитекта, он добија поглед изнутра не само на крајњи резултат, већ и на изазове које АВС превазилази. Што је веће разумевање како систем функционише, веће је поверење. Стога ће Василиј поделити тајне АВС услуга у облаку. Испод је дизајн физичких АВС сервера, еластична скалабилност базе података, прилагођена Амазон база података и методе за повећање перформанси виртуелних машина уз истовремено смањење њихове цене. Познавање Амазонових архитектонских приступа ће вам помоћи да ефикасније користите АВС услуге и може вам дати нове идеје за прављење сопствених решења.

О говорнику: Василиј Пантјухин (Кокошка) почео је као Уник администратор у компанијама .ру, радио на великом хардверу компаније Сун Мицросистем 6 година и проповедао свет усредсређен на податке у ЕМЦ-у 11 година. Природно је еволуирао у приватне облаке, а 2017. прешао у јавне. Сада пружа техничке савете за живот и развој у АВС облаку.

Одрицање од одговорности: све испод је Василијево лично мишљење и можда се не поклапа са позицијом Амазон Веб Сервицес. Видео снимање Извештај на коме се заснива чланак доступан је на нашем ИоуТубе каналу.

Зашто говорим о Амазон уређају?

Мој први ауто је имао ручни мењач. Било је сјајно због осећаја да могу да возим ауто и да имам потпуну контролу над њим. Такође ми се допало што сам бар приближно разумео принцип његовог рада. Наравно, замислио сам да је структура кутије прилично примитивна - нешто попут мењача на бициклу.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Све је било одлично, осим једне ствари - заглављени у саобраћајној гужви. Чини се да седите и не радите ништа, али стално мењате брзине, притискате квачило, гас, кочницу - то вас заиста умара. Проблем саобраћајне гужве је делимично решен када је породица добила ауто-аутомат. Док сам се возио, имао сам времена да размислим о нечему и послушам аудио-књигу.

Још једна мистерија се појавила у мом животу, јер сам потпуно престао да разумем како мој ауто ради. Савремени аутомобил је сложен уређај. Аутомобил се истовремено прилагођава на десетине различитих параметара: притискање гаса, кочница, стил вожње, квалитет пута. Не разумем више како то функционише.

Када сам почео да радим на Амазон облаку, и за мене је био мистерија. Само је ова мистерија за ред величине већа, јер у аутомобилу је један возач, а у АВС-у их има на милионе. Сви корисници истовремено управљају, притискају гас и кочницу. Невероватно је да иду где хоће – за мене је то чудо! Систем се аутоматски прилагођава, скалира и еластично прилагођава сваком кориснику тако да му се чини да је сам у овом Универзуму.

Магија је мало нестала када сам касније дошао да радим као архитекта у Амазону. Видео сам са каквим проблемима се суочавамо, како их решавамо и како развијамо услуге. Са све већим разумевањем како систем функционише, појављује се више поверења у услугу. Зато желим да поделим слику онога што се налази испод хаубе АВС облака.

О чему да причамо

Изабрао сам разнолик приступ - одабрао сам 4 занимљиве услуге о којима вреди говорити.

Оптимизација сервера. Ефемерни облаци са физичким оличењем: физички центри података у којима постоје физички сервери који брује, греју и трепћу светлима.

Функције без сервера (Ламбда) је вероватно најскалабилнија услуга у облаку.

Скалирање базе података. Рећи ћу вам о томе како градимо сопствене скалабилне базе података.

Мрежно скалирање. Последњи део у коме ћу отворити уређај наше мреже. Ово је дивна ствар - сваки корисник облака верује да је сам у облаку и да уопште не види друге станаре.

Белешка. Овај чланак ће говорити о оптимизацији сервера и скалирању базе података. Размотрићемо скалирање мреже у следећем чланку. Где су функције без сервера? О њима је објављен посебан транскрипт “Мали, али паметан. Отпакивање микровиртуелне Фирецрацкер" Говори о неколико различитих метода скалирања и детаљно разматра решење Фирецрацкер – симбиозу најбољих квалитета виртуелне машине и контејнера.

Сервери

Облак је ефемеран. Али ова ефемерност и даље има физичко оличење - сервере. У почетку је њихова архитектура била класична. Стандардни к86 чипсет, мрежне картице, Линук, Ксен хипервизор на коме су покренуте виртуелне машине.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

У 2012. години ова архитектура се прилично добро носила са својим задацима. Ксен је одличан хипервизор, али има један велики недостатак. Доста му је високи трошкови за емулацију уређаја. Како нове, брже мрежне картице или ССД дискови постају доступни, ови трошкови постају превисоки. Како се носити са овим проблемом? Одлучили смо да радимо на два фронта одједном - оптимизовати и хардвер и хипервизор. Задатак је веома озбиљан.

Оптимизација хардвера и хипервизора

Урадити све одједном и то добро неће радити. Шта је „добро“ такође у почетку није било јасно.

Одлучили смо се за еволутивни приступ - мењамо један важан елемент архитектуре и бацамо га у производњу.

Нагазимо на сваку грабу, слушамо жалбе и сугестије. Затим мењамо другу компоненту. Дакле, у малим корацима, радикално мењамо целокупну архитектуру на основу повратних информација корисника и подршке.

Трансформација је почела 2013. најкомплекснијом ствари – мрежом. ИН СКСНУМКС У случајевима, стандардној мрежној картици је додата посебна картица Нетворк Аццелератор. Био је повезан буквално кратким лоопбацк каблом на предњој плочи. Није лепо, али се не види у облаку. Али директна интеракција са хардвером је суштински побољшала подрхтавање и пропусност мреже.

Затим смо одлучили да побољшамо приступ блок складиштењу података ЕБС - Еластиц Блоцк Стораге. То је комбинација мреже и складишта. Потешкоћа је у томе што док су картице Нетворк Аццелератор постојале на тржишту, није било опције да се једноставно купи хардвер за убрзање складиштења. Па смо се окренули стартапу Аннапурна Лабс, који је за нас развио посебне АСИЦ чипове. Омогућили су да се удаљени ЕБС волумени монтирају као НВМе уређаји.

У случајевима C4 решили смо два проблема. Први је да смо имплементирали основу за будућност обећавајуће, али нове у то време, НВМе технологије. Друго, значајно смо растеретили централни процесор пребацивањем обраде захтева у ЕБС на нову картицу. Испало је добро, тако да је сада Аннапурна Лабс део Амазона.

До новембра 2017. схватили смо да је време да променимо сам хипервизор.

Нови хипервизор је развијен на основу модификованих модула КВМ кернела.

То је омогућило да се суштински смање трошкови емулације уређаја и директан рад са новим АСИЦ-овима. Инстанце СКСНУМКС биле су прве виртуелне машине са новим хипервизором који је радио испод хаубе. Дали смо му име Нитро.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе податакаЕволуција инстанци на временској линији.

Све нове врсте виртуелних машина које су се појавиле од новембра 2017. раде на овом хипервизору. Баре Метал инстанце немају хипервизор, али се називају и Нитро, пошто користе специјализоване Нитро картице.

Током наредне две године, број типова Нитро инстанци је премашио неколико десетина: А1, Ц5, М5, Т3 и други.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података
Типови инстанци.

Како раде модерне Нитро машине

Имају три главне компоненте: Нитро хипервизор (о коме је већ било речи), безбедносни чип и Нитро картице.

Сигурносни чип интегрисан директно у матичну плочу. Он контролише многе важне функције, као што је контрола учитавања ОС-а домаћина.

Нитро картице - Има их четири врсте. Све их је развила Аннапурна Лабс и засновани су на уобичајеним АСИЦ-овима. Неки од њихових фирмвера су такође уобичајени.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података
Четири врсте Нитро картица.

Једна од картица је дизајнирана за рад мрежаВПЦ. То је оно што је видљиво у виртуелним машинама као мрежна картица ЕНА - Еластични мрежни адаптер. Такође инкапсулира саобраћај када га преноси преко физичке мреже (о томе ћемо говорити у другом делу чланка), контролише заштитни зид безбедносних група и одговоран је за рутирање и друге мрежне ствари.

Одабране картице раде са блок меморијом ЕБС и дискове који су уграђени у сервер. Гостујућој виртуелној машини се појављују као НВМе адаптери. Они су такође одговорни за шифровање података и надгледање диска.

Систем Нитро картица, хипервизора и сигурносног чипа интегрисан је у СДН мрежу одн Softverski definisana mreža. Одговоран за управљање овом мрежом (Цонтрол Плане) картица контролера.

Наравно, настављамо да развијамо нове АСИЦ-ове. На пример, крајем 2018. објавили су чип Инферентиа, који вам омогућава да ефикасније радите са задацима машинског учења.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података
Инферентиа чип процесора за машинско учење.

Сцалабле Датабасе

Традиционална база података има слојевиту структуру. Да бисмо увелико поједноставили, разликују се следећи нивои.

  • СКЛ — на томе раде диспечери клијената и захтева.
  • Одредбе трансакције - овде је све јасно, АЦИД и све то.
  • кеширање, коју обезбеђују пуферски пулови.
  • Логгинг — обезбеђује рад са редо дневникима. У МиСКЛ-у се зову Бин Логс, у ПосгреСКЛ-у - Врите Ахеад Логс (ВАЛ).
  • Складиштење – директно снимање на диск.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података
Слојевита структура базе података.

Постоје различити начини за скалирање база података: дељење, архитектура Схаред Нотхинг, дељени дискови.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Међутим, све ове методе одржавају исту монолитну структуру базе података. Ово значајно ограничава скалирање. Да бисмо решили овај проблем, развили смо сопствену базу података − Амазон Аурора. Компатибилан је са МиСКЛ и ПостгреСКЛ.

Амазон Аурора

Главна архитектонска идеја је да се нивои складиштења и евидентирања одвоје од главне базе података.

Гледајући унапред, рећи ћу да смо такође учинили независним ниво кеширања. Архитектура престаје да буде монолит и добијамо додатне степене слободе у скалирању појединачних блокова.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података
Нивои евидентирања и складиштења су одвојени од базе података.

Традиционални ДБМС записује податке у систем за складиштење у облику блокова. У Амазон Аурора смо направили паметно складиште које може да говори језиком редо-логови. Унутрашњост, складиште претвара евиденције у блокове података, надгледа њихов интегритет и аутоматски прави резервне копије.

Овај приступ вам омогућава да имплементирате такве занимљиве ствари као што су клонирање. Функционално ради брже и економичније због чињенице да не захтева креирање комплетне копије свих података.

Слој за складиштење је имплементиран као дистрибуирани систем. Састоји се од веома великог броја физичких сервера. Сваки редо лог се обрађује и чува истовремено шест чворова. Ово обезбеђује заштиту података и балансирање оптерећења.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Скалирање читања може се постићи коришћењем одговарајућих реплика. Дистрибуирано складиште елиминише потребу за синхронизацијом између главне инстанце базе података, преко које пишемо податке, и преосталих реплика. Загарантовано је да ће ажурирани подаци бити доступни свим репликама.

Једини проблем је кеширање старих података на прочитаним репликама. Али овај проблем се решава пренос свих редо дневника на реплике преко интерне мреже. Ако је евиденција у кешу, означена је као нетачна и преписана. Ако није у кешу, једноставно се одбацује.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Средили смо складиште.

Како скалирати нивое ДБМС-а

Овде је хоризонтално скалирање много теже. Па хајдемо утабаним путем класично вертикално скалирање.

Претпоставимо да имамо апликацију која комуницира са ДБМС-ом преко главног чвора.

Приликом вертикалног скалирања, додељујемо нови чвор који ће имати више процесора и меморије.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Затим пребацимо апликацију са старог главног чвора на нови. Настају проблеми.

  • Ово ће захтевати значајно време застоја апликације.
  • Нови главни чвор ће имати хладну кеш меморију. Перформансе базе података ће бити максималне тек након што се кеш загреје.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Како побољшати ситуацију? Подесите прокси између апликације и главног чвора.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Шта ће нам ово дати? Сада све апликације не морају бити ручно преусмерене на нови чвор. Пребацивање се може извршити под прокси сервером и суштински је брже.

Чини се да је проблем решен. Али не, и даље патимо од потребе да загрејемо кеш меморију. Поред тога, појавио се нови проблем - сада је проки потенцијална тачка квара.

Коначно решење са Амазон Аурора без сервера

Како смо решили ове проблеме?

Оставио проки. Ово није посебна инстанца, већ читава дистрибуирана флота проксија преко којих се апликације повезују са базом података. У случају квара, било који од чворова се може заменити скоро тренутно.

Додан базен топлих чворова различитих величина. Стога, ако је потребно доделити нови чвор веће или мање величине, он је одмах доступан. Нема потребе да чекате да се учита.

Цео процес скалирања контролише посебан систем за праћење. Мониторинг стално прати стање тренутног главног чвора. Ако открије, на пример, да је оптерећење процесора достигло критичну вредност, обавештава скуп топлих инстанци о потреби да се додели нови чвор.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података
Дистрибуирани проксији, топле инстанце и праћење.

Доступан је чвор са потребном снагом. Скупови бафера се копирају у њега и систем почиње да чека сигуран тренутак за пребацивање.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Обично тренутак за пребацивање дође прилично брзо. Тада се прекида комуникација између проксија и старог главног чвора, све сесије се пребацују на нови чвор.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Рад са базом података се наставља.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Графикон показује да је суспензија заиста веома кратка. Плави графикон приказује оптерећење, а црвени кораци показују моменте скалирања. Краткорочни падови на плавом графикону су управо то кратко кашњење.

Како АВС припрема своје еластичне услуге. Скалирање сервера и базе података

Иначе, Амазон Аурора вам омогућава да потпуно уштедите новац и искључите базу података када се не користи, на пример, викендом. Након заустављања оптерећења, ДБ постепено смањује снагу и гаси се неко време. Када се оптерећење врати, поново ће се глатко подићи.

У следећем делу приче о Амазон уређају, говорићемо о скалирању мреже. претплатити се Пошта и останите са нама како не бисте пропустили чланак.

На ХигхЛоад++ Василиј Пантјухин ће дати извештај „Хјустон имамо проблем. Дизајн система за отказ, развојни обрасци за интерне Амазон цлоуд сервисе" Које шаблоне дизајна за дистрибуиране системе користе програмери Амазона, који су разлози отказивања сервиса, шта је архитектура заснована на ћелијама, Констант рад, Схуффле Схардинг – биће занимљиво. Мање од месец дана до конференције - резервишите своје карте. 24. октобар коначно повећање цене.

Извор: ввв.хабр.цом

Додај коментар