Како AWS ги подготвува своите еластични услуги. Мрежно скалирање

Размерот на мрежата на веб-услуги на Амазон е 69 зони низ светот во 22 региони: САД, Европа, Азија, Африка и Австралија. Секоја зона содржи до 8 центри за податоци - центри за обработка на податоци. Секој центар за податоци има илјадници или стотици илјади сервери. Мрежата е дизајнирана на таков начин што се земаат предвид сите неверојатни сценарија за прекин. На пример, сите региони се изолирани еден од друг, а зоните за пристап се одвоени на растојанија од неколку километри. Дури и ако го пресечете кабелот, системот ќе се префрли на резервни канали, а загубата на информации ќе изнесува неколку пакети со податоци. Василиј Пантјухин ќе зборува за тоа на кои други принципи е изградена мрежата и како е структурирана.

Василиј Пантјухин започна како администратор на Unix во компаниите .ru, работеше на голем хардвер Sun Microsystem 6 години и проповедаше свет фокусиран на податоци 11 години во EMC. Природно еволуираше во приватни облаци, а потоа се пресели во јавни. Сега, како архитект на веб-услугите на Амазон, тој обезбедува технички совети за да помогне во живеењето и развојот во облакот AWS.

Во претходниот дел од трилогијата AWS, Васили се навлезе во дизајнот на физички сервери и скалирање на базата на податоци. Нитро картички, прилагоден хипервизор базиран на KVM, база на податоци на Amazon Aurora - за сето ова во материјалот "Како AWS ги подготвува своите еластични услуги. Скалирачки сервери и база на податоци" Читајте за контекст или гледајте видео касета говори.

Овој дел ќе се фокусира на мрежно скалирање, еден од најкомплексните системи во AWS. Еволуцијата од рамна мрежа до виртуелен приватен облак и неговиот дизајн, внатрешните услуги на Blackfoot и HyperPlane, проблемот на бучниот сосед и на крајот - обемот на мрежата, столбот и физичките кабли. За сето ова под сечењето.

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

Мрежно скалирање

Облакот AWS беше лансиран во 2006 година. Неговата мрежа беше прилично примитивна - со рамна структура. Опсегот на приватни адреси беше заеднички за сите станари на облак. Кога стартувате нова виртуелна машина, случајно сте примиле достапна IP адреса од овој опсег.

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

Виртуелен приватен облак

Облакот се покажа како баран. Дојде време да се размислува за приспособливост и можноста за нејзино користење од десетици милиони станари. Рамната мрежа стана главна пречка. Затоа, размислувавме како да ги изолираме корисниците едни од други на ниво на мрежа за да можат самостојно да избираат опсег на IP.

Што е првото нешто што ви паѓа на ум кога размислувате за изолација на мрежата? Секако VLAN и VRF - Виртуелно рутирање и препраќање.

За жал, тоа не функционираше. VLAN ID е само 12 бита, што ни дава само 4096 изолирани сегменти. Дури и најголемите прекинувачи можат да користат најмногу 1-2 илјади VRFs. Користењето на VRF и VLAN заедно ни дава само неколку милиони подмрежи. Ова дефинитивно не е доволно за десетици милиони станари, од кои секоја мора да може да користи повеќе подмрежи.

Ние, исто така, едноставно не можеме да си дозволиме да го купиме потребниот број големи кутии, на пример, од Cisco или Juniper. Има две причини: тоа е лудо скапо и не сакаме да бидеме на милост и немилост на нивните политики за развој и крпење.

Има само еден заклучок - направете свое решение.

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

VPC е виртуелна мрежа SDN (Мрежа дефинирана со софтвер). Решивме да не измислуваме специјални протоколи на нивоата L2 и L3. Мрежата работи на стандарден етернет и IP. За пренос преку мрежата, сообраќајот на виртуелната машина е инкапсулиран во нашата сопствена обвивка на протокол. Го означува личната карта што му припаѓа на VPC на закупецот.

Звучи едноставно. Сепак, постојат неколку сериозни технички предизвици кои треба да се надминат. На пример, каде и како да се складираат податоци за мапирање на виртуелни MAC/IP адреси, VPC ID и соодветните физички MAC/IP. На скалата AWS, ова е огромна табела што треба да работи со минимални доцнења за пристап. Одговорен за ова услуга за мапирање, кој се шири во тенок слој низ целата мрежа.

Кај машините од новата генерација, инкапсулацијата се изведува со Nitro картички на хардверско ниво. Во постарите случаи, инкапсулацијата и декапсулацијата се базирани на софтвер. 

Ајде да дознаеме како функционира во општи услови. Да почнеме со нивото L2. Да претпоставиме дека имаме виртуелна машина со IP 10.0.0.2 на физички сервер 192.168.0.3. Испраќа податоци до виртуелната машина 10.0.0.3, која живее на 192.168.1.4. Се генерира барање ARP и се испраќа до мрежната Nitro картичка. За едноставност, претпоставуваме дека и двете виртуелни машини живеат во истиот „син“ VPC.

Мапата ја заменува изворната адреса со своја и ја препраќа рамката ARP до услугата за мапирање.

Услугата за мапирање враќа информации кои се неопходни за пренос преку физичката мрежа L2.

Нитро-картичката во одговорот ARP го заменува MAC на физичката мрежа со адреса во VPC.

Кога префрламе податоци, ги завиткуваме логичките MAC и IP во VPC обвивка. Сето ова го пренесуваме преку физичката мрежа користејќи ги соодветните IP Nitro картички за извор и дестинација.

Физичката машина на која е наменет пакетот ја врши проверката. Ова е неопходно за да се спречи можноста за измама на адресата. Машината испраќа посебно барање до сервисот за мапирање и прашува: „Од физичка машина 192.168.0.3 добив пакет што е наменет за 10.0.0.3 во синиот VPC. Дали е тој легитимен? 

Услугата за мапирање ја проверува својата табела за распределба на ресурси и дозволува или негира пакетот да помине низ. Во сите нови случаи, дополнителна валидација е вградена во Nitro картичките. Невозможно е да се заобиколи дури и теоретски. Затоа, измама на ресурси во друг VPC нема да работи.

Следно, податоците се испраќаат до виртуелната машина за која се наменети. 

Услугата за мапирање работи и како логичен рутер за пренос на податоци помеѓу виртуелни машини во различни подмрежи. Сè е концептуално едноставно, нема да навлегувам во детали.

Излегува дека при пренос на секој пакет, серверите се свртуваат кон услугата за мапирање. Како да се справите со неизбежните одложувања? Кеширање, секако.

Убавината е во тоа што не треба да ја кеширате целата огромна маса. Физички сервер е домаќин на виртуелни машини од релативно мал број VPC. Треба само да ги кеширате информациите за овие VPC. Пренесувањето податоци на други VPC во „стандардна“ конфигурација сè уште не е легитимно. Ако се користи функционалност како VPC-peering, тогаш информациите за соодветните VPC се дополнително вчитани во кешот. 

Го средивме преносот на податоци до VPC.

Blackfoot

Што да се прави во случаи кога сообраќајот треба да се пренесе надвор, на пример на Интернет или преку VPN на земја? Ни помага овде Blackfoot — Внатрешна услуга AWS. Таа е развиена од нашиот јужноафрикански тим. Затоа услугата го добила името по пингвин кој живее во Јужна Африка.

Blackfoot го декапсулира сообраќајот и го прави она што е потребно со него. Податоците се испраќаат на Интернет како што се.

Податоците се декапсулираат и повторно се завиткуваат во IPsec кога се користи VPN.

Кога користите Direct Connect, сообраќајот се означува и се испраќа до соодветниот VLAN.

Хиперавион

Ова е услуга за внатрешна контрола на протокот. Многу мрежни услуги бараат мониторинг состојби на проток на податоци. На пример, кога се користи NAT, контролата на протокот мора да осигури дека секој пар IP:дестинациона порта има единствена излезна порта. Во случај на балансер НЛБ - Мрежен Load Balancer, протокот на податоци секогаш треба да биде насочен кон истата целна виртуелна машина. Безбедносните групи е државен заштитен ѕид. Го следи дојдовниот сообраќај и имплицитно отвора порти за проток на појдовни пакети.

Во облакот AWS, барањата за латентност на преносот се исклучително високи. Затоа Хиперавион критични за перформансите на целата мрежа.

Hyperplane е изграден на EC2 виртуелни машини. Тука нема магија, само лукавство. Трикот е што тоа се виртуелни машини со голема RAM меморија. Операциите се трансакциски и се вршат исклучиво во меморија. Ова ви овозможува да постигнете одложувања од само десетици микросекунди. Работата со дискот би ја уништила целата продуктивност. 

Hyperplane е дистрибуиран систем на огромен број такви EC2 машини. Секоја виртуелна машина има пропусен опсег од 5 GB/s. Низ целата регионална мрежа, ова обезбедува неверојатни терабити на пропусен опсег и овозможува обработка милиони врски во секунда.

HyperPlane работи само со стримови. Енкапсулацијата на VPC пакетите е целосно транспарентна за неа. Потенцијалната ранливост во оваа внатрешна услуга сепак би спречила прекинување на изолацијата на VPC. Нивоата подолу се одговорни за безбедноста.

Бучен сосед

Сè уште има проблем бучен сосед - бучен сосед. Да претпоставиме дека имаме 8 јазли. Овие јазли ги обработуваат тековите на сите корисници на облак. Се чини дека сè е во ред и товарот треба да биде рамномерно распределен низ сите јазли. Јазлите се многу моќни и тешко е да се преоптоварат.

Но, ние ја градиме нашата архитектура врз основа на дури и неверојатни сценарија. 

Ниската веројатност не значи невозможно.

Можеме да замислиме ситуација во која еден или повеќе корисници би генерирале премногу оптоварување. Сите HyperPlane јазли се вклучени во обработката на ова оптоварување и другите корисници потенцијално би можеле да доживеат некаков вид на хит на перформансите. Ова го нарушува концептот на облакот, во кој станарите немаат способност да влијаат еден на друг.

Како да се реши проблемот со бучниот сосед? Првото нешто што ми паѓа на ум е сечењето. Нашите 8 јазли се логично поделени на 4 парчиња од по 2 јазли. Сега бучниот сосед ќе вознемири само четвртина од сите корисници, но многу ќе ги вознемири.

Ајде да ги правиме работите поинаку. Ќе доделиме само 3 јазли на секој корисник. 

Трикот е случајно да се доделат јазли на различни корисници. На сликата подолу, синиот корисник ги пресекува јазлите со еден од другите двајца корисници - зелена и портокалова.

Со 8 јазли и 3 корисници, веројатноста бучниот сосед да се вкрсти со еден од корисниците е 54%. Тоа е со оваа веројатност дека синиот корисник ќе влијае на другите станари. Во исто време, само дел од својот товар. Во нашиот пример, ова влијание ќе биде барем некако забележливо не за секого, туку само за една третина од сите корисници. Ова е веќе добар резултат.

Број на корисници кои ќе се вкрстат

Веројатност во проценти

0

18%

1

54%

2

26%

3

2%

Ајде да ја приближиме ситуацијата до реалноста - да земеме 100 јазли и 5 корисници на 5 јазли. Во овој случај, ниту еден од јазлите нема да се вкрсти со веројатност од 77%. 

Број на корисници кои ќе се вкрстат

Веројатност во проценти

0

77%

1

21%

2

1,8%

3

0,06%

4

0,0006%

5

0,00000013%

Во реална ситуација, со огромен број HyperPlane јазли и корисници, потенцијалното влијание на бучниот сосед врз другите корисници е минимално. Овој метод се нарекува мешање распарчување - измешано делење. Го минимизира негативниот ефект од неуспехот на јазолот.

Многу услуги се изградени врз основа на HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

Мрежна скала

Сега да зборуваме за обемот на самата мрежа. За октомври 2019 година AWS ги нуди своите услуги во 22 региони, а планирани се уште 9.

• Секој регион содржи неколку зони на достапност. Низ светот ги има 69.
• Секој АЗ се состои од Центри за обработка на податоци. Вкупно нема повеќе од 8 од нив.
• Во центарот за податоци се сместени огромен број сервери, некои и до 300.

Сега да го просецираме сето ова, да се умножиме и да добиеме импресивна бројка што се одразува Облак скала на Амазон.

Има многу оптички врски помеѓу зоните за достапност и центарот за податоци. Во еден од нашите најголеми региони, поставени се 388 канали само за АЗ комуникација меѓу себе и центрите за комуникација со другите региони (Транзитни центри). Севкупно ова дава лудо 5000 Tbit.

Backbone AWS е изграден специјално и оптимизиран за облакот. Ние го градиме на каналите 100 GB/s. Ние ги контролираме целосно, со исклучок на регионите во Кина. Сообраќајот не се дели со товарите на другите компании.

Се разбира, ние не сме единствениот провајдер на облак со приватна мрежа. Сè повеќе големи компании го следат овој пат. Ова го потврдуваат независни истражувачи, на пример од Телегеографија.

Графиконот покажува дека уделот на давателите на содржини и провајдерите на облакот расте. Поради ова, уделот на интернет сообраќајот на основните провајдери постојано се намалува.

Ќе објаснам зошто се случува ова. Претходно, повеќето веб-услуги беа достапни и консумирани директно од Интернет. Во денешно време, сè повеќе сервери се наоѓаат во облакот и се достапни преку CDN - Мрежа за дистрибуција на содржина. За да пристапи до ресурс, корисникот оди преку Интернет само до најблискиот CDN PoP - Точка на присуство. Најчесто тоа е некаде во близина. Потоа го напушта јавниот Интернет и лета преку приватен столб преку Атлантикот, на пример, и доаѓа директно до ресурсот.

Се прашувам како ќе се промени интернетот за 10 години ако продолжи овој тренд?

Физички канали

Научниците сè уште не сфатиле како да ја зголемат брзината на светлината во Универзумот, но постигнале голем напредок во методите за нејзино пренесување преку оптички влакна. Во моментов користиме 6912 кабли со влакна. Ова помага значително да се оптимизираат трошоците за нивната инсталација.

Во некои региони мораме да користиме специјални кабли. На пример, во регионот Сиднеј користиме кабли со специјална обвивка против термити. 

Никој не е имун од неволји и понекогаш нашите канали се оштетуваат. На фотографијата десно се гледаат оптички кабли во еден од американските региони кои биле искинати од градежни работници. Како резултат на несреќата, изгубени се само 13 пакети со податоци, што е изненадувачки. Уште еднаш - само 13! Системот буквално веднаш се префрли на резервни канали - вагата работи.

Галопиравме низ некои од облак услугите и технологиите на Amazon. Се надевам дека имате барем малку идеја за обемот на задачите што треба да ги решат нашите инженери. Лично, ова го сметам за многу возбудливо. 

Ова е последниот дел од трилогијата на Василиј Пантјухин за уредот AWS. ВО Првиот делови опишуваат оптимизација на серверот и скалирање на базата на податоци, и во вториот — Функции без сервер и Firecracker.

На HighLoad ++ во ноември Василиј Пантјухин ќе сподели нови детали за уредот Амазон. Тој ќе кажам за причините за неуспесите и дизајнот на дистрибуираните системи во Amazon. Сè уште е можен 24 октомври да резервирам билет по добра цена, а платите подоцна. Ве чекаме на HighLoad++, дојдете да разговараме!

Извор: www.habr.com