Мащабът на мрежата на Amazon Web Services е 69 зони по целия свят в 22 региона: САЩ, Европа, Азия, Африка и Австралия. Във всяка зона се намират до 8 центрове за данни (ЦД). Във всеки ЦД има хиляди или стотици хиляди сървъри. Мрежата е изградена така, че всички малко вероятни сценарии на прекъсвания да бъдат предвидени. Например, всички региони са изолирани един от друг, а зоните на достъп са разположени на разстояния от няколко километра. Дори ако кабелът бъде прекъснат, системата ще премине на резервни канали, а загубите на информация ще бъдат единици пакети данни. За принципите, на които е изградена мрежата и как е организирана, ще разкаже Василий Пантюхин.
Василий Пантюхин започва като администратор на Unix в компании .ru, 6 години се занимава с големи съоръжения на Sun Microsystem, 11 години проповядва дата-центричността на света в EMC. Природният му път на еволюция е в частни облаци, след което преминава към публични. В момента, като архитект на Amazon Web Services, с технически съвети помага за живота и развитието в облака AWS.
В предишната част от трилогията за устройството на AWS Василий задълбочи темата за физическите сървъри и мащабирането на базата данни. Nitro карти, персонализиран хипервизор на базата на KVM, база данни Amazon Aurora — всичко това в материала „“. Прочетете, за да се потопите в контекста, или вижте изпълнението.
В тази част ще се обсъжда мащабирането на мрежата — една от най-сложните системи в AWS. Еволюцията от плоска мрежа към Virtual Private Cloud и нейното устройство, вътрешните услуги Blackfoot и HyperPlane, проблемът с шумния съсед и накрая — мащабите на мрежата, основната линия и физическите кабели. Всичко това под кат.
Дисклеймер: всичко, което следва, е личното мнение на Василий и може да не съвпада с позицията на Amazon Web Services.
Мащабиране на мрежата
Облака AWS стартира през 2006 година. Неговата мрежа беше достатъчно примитивна — с плоска структура. Диапазонът на частните адреси беше общ за всички наематели на облака. При стартиране на нова виртуална машина случайно получавахте наличен IP адрес от този диапазон.
Този подход беше лесен за реализиране, но принципно ограничаваше използването на облака. В частност, беше доста сложно да се разработват хибридни решения, в които се обединяваха частни мрежи на земята и в AWS. Най-разпространената проблема беше в пресичането на диапазоните на IP адресите.
Виртуално Частно Общество
Облакът стана популярен. Дойде време да помислим за мащабируемост и възможността му да бъде използван от десетки милиони наематели. Плоската мрежа се оказа основна пречка. Затова се замислихме как да изолираме потребителите един от друг на мрежово ниво, така че да могат самостоятелно да избират диапазони IP.
Какво първо ви идва на ум, когато помислите за мрежова изолация? Разбира се VLAN и VRF — Виртуално маршрутизиране и предаване.
За съжаление, това не проработи. VLAN ID е само 12 бита, което ни дава само 4096 изолирани сегмента. Дори в най-големите комутатори могат да се използват максимум 1-2 хиляди VRF. Споделянето на VRF и VLAN ни дава само няколко милиона подмрежи. Това определено е недостатъчно за десетки милиони наематели, всеки от които трябва да има опцията да използва няколко подмрежи.
Освен това просто не можем да си позволим да купим изискващото се количество големи устройства, например от Cisco или Juniper. Има две причини: това е безумно скъпо, и не искаме да зависим от тяхната политика за разработка и обновяване.
Изводът е един – да създадем собствено решение.
През 2009 година обявихме VPC — Виртуално Частно Общество. Името се утвърди и сега много облачни доставчици също го използват.
VPC – това е виртуална мрежа SDN (Софтверно дефинирана мрежа). Решихме да не изобретяваме специални протоколи на ниво L2 и L3. Мрежата работи на стандартни Ethernet и IP. За предаване през мрежата трафикът на виртуалните машини е инкапсулиран в обвивка на нашия собствен протокол. В него се посочва ID, което принадлежи на 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.
Nitro картата в ARP отговора заменя MAC адреса в физическата мрежа с адрес в VPC.
При предаване на данни обвиваме логическите MAC и IP в VPC обвивка. Всичко това предаваме по физическата мрежа с помощта на съответните IP Nitro карти на източника и получателя.
Физическата машина, на която е предназначен пакета, извършва проверка. Това е необходимо, за да се предотврати възможността за подмяна на адреси. Машината изпраща специално запитване към службата за мапиране и пита: „От физическата машина 192.168.0.3 получих пакет, който е предназначен за 10.0.0.3 в „син“ VPC. Легитимен ли е?“
Службата за мапиране проверява таблицата си за разпределение на ресурси и разрешава или забранява преминаването на пакета. Във всички нови инстанции допълнителната валидация е вградена в Nitro картите. Те не могат да бъдат заобиколени дори теоретично. Затова spoofing на ресурси в друг VPC няма да сработи.
След това данните се изпращат до виртуалната машина, за която са предназначени.
Службата за мапиране също работи като логичен маршрутизатор за предаване на данни между виртуалките в различни подсети. Там концептуално всичко е просто, няма да разглеждам подробностите.
Получава се, че при предаване на всеки пакет сървърите се обръщат към службата за мапиране. Как да се справим с неизбежните забавяния? С кеширане, разбира се.
Цялата магия е в това, че не е нужно да кеширате цялата огромна таблица. На физическия сървър живеят виртуалки от сравнително малко на брой VPC. Кеширането на информацията трябва да бъде само за тези VPC. Предаването на данни в други VPC в "дефолтната" конфигурация все пак не е легитимно. Ако се използва такава функционалност като VPC-peering, то в кеша допълнително се зарежда информация за съответните VPC.
Разбрахме се с предаването на данни в VPC.
Blackfoot
Как да постъпим в случаите, когато трафикът трябва да се предава навън, например в Internet или чрез VPN на земята? Тук ни спасява Blackfoot — вътрешен сервиз на AWS. Той е разработен от нашия южноафрикански екип. Затова сервизът е наречен на име на пингвин, който живее в Южна Африка.
Blackfoot декапсулира трафика и прави с него това, което е нужно. Данните в Internet се изпращат такъв, какъвто е.
Данните се декапсулират и отново се опаковат в IPsec обвивка при използване на VPN.
При използването на Direct Connect трафикът се тагва и предава в съответния VLAN.
HyperPlane
Това е вътрешен контролен сервиз. Много мрежови услуги изискват контрол на състоянието на потока данни. Например, при използване на NAT, контролът на потока трябва да гарантира, че всяка двойка "IP: порт на дестинацията" съответства на уникален изходящ порт. В случай на балансировщик NLB — Network Load Balancer, потокът данни винаги трябва да бъде насочен към един и същ целеви виртуалка. Security Groups е фаервол с поддържане на състояние. Той следи входящия трафик и неявно отваря портове за изходящия поток на пакети.
В облака AWS изискванията към закъсненията на предаване са крайно високи. Затова HyperPlane е критично за функционирането на цялата мрежа.
Hyperplane е построен на виртуални машини EC2. Тук няма никаква магия, само хитрост. Хитростта е, че това са виртуалки с голям RAM. Операциите са транзакционни и се извършват изключително в паметта. Това позволява да се постигнат закъснения от само десетки микросекунди. Работата с диска би убила цялата производителност.
Hyperplane е разпределена система от огромен брой такива EC2 машини. Всяка виртуалка има пропускна способност от 5 ГБ/с. В мащабите на цялата регионална мрежа това дава безумни терабити пропускна способност и позволява да се обработват милиони свързвания в секунда.
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 ноди и потребители, потенциалното влияние на шумния съсед върху другите потребители е минимално. Този метод се нарича разпределено шардирване — shuffle sharding. То минимизира негативния ефект от извеждането на нодовете от строя.
На базата на HyperPlane са изградени множество услуги: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Мащабите на мрежата
Сега да поговорим за мащабите на самата мрежа. Към октомври 2019 AWS предлага своите услуги в 22 региона, а още 9 са планирани.
- Всеки регион съдържа няколко зони на достъп — Availability Zone. Общият им брой в света е 69.
- Всяка AZ се състои от центрове за обработка на данни. Общият им брой е не повече от 8.
- В ЦОД се намира огромно количество сървъри, в някои до 300 000.
Сега всичко това ще усредним, умножим и получим впечатляваща цифра, която показва мащаба на облака Amazon.
Между зоните на достъп и ЦОД са положени много оптични канали. В един от най-големите ни региони само за свързването на AZ помежду им и с центровете за свързване с други региони (Transit Centers) са положени 388 канала. В сумата това дава умуващи 5000 Тбит.
Backbone на AWS е специално изградена за облака и е оптимизирана за работа с него. Изграждаме я на канали 100 ГБ/с. Ние ги контролираме изцяло, с изключение на регионите в Китай. Трафикът не се споделя с натоварвания на други компании.
Разбира се, ние не сме единственият облачен провайдър с частна backbone мрежа. Все повече големи компании поемат по този път. Това се потвърдва от независими изследователи, например, от .
На графиката е видно, че делът на провайдерите на съдържание и облачните провайдери нараства. Поради това, делът на интернет трафика на backbone провайдерите постоянно намалява.
Ще обясня защо се случва това. По-рано, повечето уеб услуги бяха достъпни и консумирани директно от интернет. В момента все повече сървъри са разположени в облака и са достъпни чрез CDN — Content Distribution Network. За достъп до ресурса потребителят преминава през интернет само до най-близкия PoP на CDN — Point of Presence. Най-често това е някъде наблизо. След това напуска публичния интернет и по частния backbone преминава през Атлантика, например, и попада директно на ресурса.
Интересно е как ще се промени интернет след 10 години, ако тази тенденция продължи?
Физически канали
Учените все още не са измислили как да увеличат скоростта на светлината във Вселената, но напредват значително в методите за нейното предаване по оптични влакна. В момента използваме кабели с 6912 влакна. Това помага значително да се оптимизира разходът за техния монтаж.
В някои региони сме принудени да използваме специални кабели. Например, в региона Сидни прилагаме кабели със специално покритие против термити.
Никой не е застрахован от неприятности и понякога нашите канали са повредени. На снимката вдясно са оптични кабели в един от американските региони, които са били скъсани от строители. В резултат на инцидента загубихме само 13 пакета данни, което е невероятно. Още веднъж – само 13! Системата буквално мигновено превключи на резервни канали — мащабът работи.
Бързо прегледахме някои услуги и технологии на облака Amazon. Надявам се, че вече имате поне известно представа за мащаба на задачите, с които нашите инженери се справят. Лично мен това много ме вълнува.
Това е финалната част от трилогията на Василий Пантюхин за устройството на AWS. В част са описани оптимизация на сървъри и мащабиране на бази данни, а във — безсървърни функции и Firecracker.
На През ноември Василий Пантюхин ще сподели нови подробности за устройството на Amazon. Той за причините за откази и проектиране на разпределени системи в Amazon. До 24 октомври все още можете да билет на добра цена, а да платите по-късно. Очакваме ви на HighLoad++, заповядайте — ще се видим!
Източник: habr.com
