Мащабът на мрежата 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, проблемът с шумните съседни мрежи, а накрая — мащабите на мрежата, backbone и физически кабели. Всичко това е под кат.
Дисклеймер: всичко, което следва, е лично мнение на Василий и може да не отразява позицията на 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 на хардуерно ниво. В старите инстанции инкапсулацията и декapsulation са софтуерни.
Нека разберем как всичко това работи в общи линии. Нека започнем с ниво L2. Да предположим, че имаме виртуална машина с IP 10.0.0.2 на физически сървър 192.168.0.3. Тя изпраща данни на виртуална машина 10.0.0.3, която се намира на 192.168.1.4. Създава се ARP-заявка, която попада на мрежовата Nitro-карта. За опростяване, приемаме, че и двете виртуални машини са в един и същ
Картата заменя адреса на източника със собствения си и препраща 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 се справихме.
Блекфут
Как да действаме в случаи, когато трафикът трябва да бъде предаден навън, например в Интернет или чрез VPN на земята? Тук ни помага Блекфут вътрешният сервис AWS. Той е разработен от нашия южноафрикански екип. Затова услугата е наречена на името на пингвин, който живее в Южна Африка.
Блекфут декапсулира трафика и прави с него това, което е необходимо. Данните в Интернет се изпращат такови, каквито са.
Данните се декапсулират и отново се увиват в обвивка IPsec при използване на VPN.
При използване на Direct Connect, трафикът се тагира и предава в съответния VLAN.
ХиперПлан
Това е вътрешна услуга за контрол на потока. Много мрежови услуги изискват контрол на състоянието на данните. Например, при използване на NAT, контролът на потока трябва да гарантира, че всяка двойка "IP: порт на назначения" съответства на уникален изходящ порт. В случай на балансировщик NLB — Network Load Balancer, потокът от данни винаги трябва да се насочва към една и съща целева виртуалка. Security Groups — това е защитна стена с поддържане на състоянието. Тя следи входящия трафик и неявно отваря портове за изходящия поток на пакетите.
В облака AWS изискванията за закъснения на предаване са изключително високи. Затова ХиперПлан това е критично за функционирането на цялата мрежа.
ХиперПлан е построен на виртуални машини EC2. Тук няма никаква магия, само хитрост. Хитростта е, че това са виртуалки с голям RAM. Операциите са транзакционни и се извършват изключително в паметта. Това позволява да се постигнат закъснения от само десетки микро секунди. Работа с диск би убила цялата производителност.
ХиперПлан е разпределена система, съставена от огромен брой такива EC2-машини. Всяка виртуалка има пропускна способност от 5 ГБ/с. В мащабите на цялата регионална мрежа това дава лудо количество терабити пропускна способност и позволява обработката на милиони връзки в секунда.
ХиперПлан работи само с потоци. VPC инкапсулацията на пакетите е напълно прозрачна за него. Потенциалната уязвимост в тази вътрешна услуга все пак няма да позволи пробив в изолацията на VPC. За безопасността отговарят по-ниските нива.
Шумен съсед
Има и още един проблем на шумния съсед — shumен съсед. Да предположим, че имаме 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
