Мащабът на мрежата на Amazon Web Services е 69 зони по целия свят в 22 региона: САЩ, Европа, Азия, Африка и Австралия. Всяка зона съдържа до 8 центъра за данни - Data Processing Centers. Всеки център за данни има хиляди или стотици хиляди сървъри. Мрежата е проектирана по такъв начин, че да се вземат предвид всички малко вероятни сценарии на прекъсване. Например, всички региони са изолирани един от друг, а зоните на достъпност са разделени на разстояние от няколко километра. Дори ако прережете кабела, системата ще превключи на резервни канали и загубата на информация ще достигне до няколко пакета данни. Василий Пантюхин ще разкаже на какви други принципи е изградена мрежата и как е структурирана.
Василий Пантюхин започва като Unix администратор в .ru компании, работи върху голям хардуер на Sun Microsystem в продължение на 6 години, проповядва свят, ориентиран към данни, в EMC в продължение на 11 години. Той естествено еволюира в частни облаци, след което се премести в публични. Сега, като архитект на Amazon Web Services, той предоставя технически съвети, за да ви помогне да живеете и да се развивате в облака на AWS.
В предишната част от трилогията на AWS Василий се задълбочи в проектирането на физически сървъри и мащабиране на бази данни. Nitro карти, персонализиран KVM-базиран хипервизор, база данни Amazon Aurora - за всичко това в материала "" Прочетете за контекст или гледайте речи.
Тази част ще се фокусира върху мрежовото мащабиране, една от най-сложните системи в AWS. Еволюцията от плоска мрежа към виртуален частен облак и неговия дизайн, вътрешните услуги на 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. За предаване по мрежата трафикът на виртуална машина е капсулиран в нашата собствена обвивка на протокола. Показва идентификатора, който принадлежи на 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 картите е вградено допълнително валидиране. Невъзможно е да го заобиколите дори теоретично. Следователно подправянето на ресурси в друг VPC няма да работи.
След това данните се изпращат до виртуалната машина, за която са предназначени.
Услугата за картографиране също работи като логически рутер за прехвърляне на данни между виртуални машини в различни подмрежи. Всичко е концептуално просто, няма да навлизам в подробности.
Оказва се, че при предаване на всеки пакет сървърите се обръщат към услугата за картографиране. Как да се справим с неизбежните закъснения? Кеширане, разбира се.
Красотата е, че не е необходимо да кеширате цялата огромна маса. Физическият сървър хоства виртуални машини от сравнително малък брой VPC. Трябва само да кеширате информация за тези VPC. Прехвърлянето на данни към други VPC в конфигурацията „по подразбиране“ все още не е законно. Ако се използва функционалност като VPC-peering, тогава информацията за съответните VPC се зарежда допълнително в кеша.
Уредихме прехвърлянето на данни към VPC.
Blackfoot
Какво да направите в случаите, когато трафикът трябва да се предаде навън, например към интернет или чрез VPN към земята? Помага ни тук Blackfoot — Вътрешна услуга на AWS. Разработено е от нашия южноафрикански екип. Ето защо услугата е кръстена на пингвин, който живее в Южна Африка.
Blackfoot декапсулира трафика и прави каквото е необходимо с него. Данните се изпращат до интернет така, както са.
Данните се декапсулират и отново се опаковат в IPsec при използване на VPN.
Когато използвате Direct Connect, трафикът се маркира и изпраща към подходящата VLAN.
Хиперплан
Това е услуга за вътрешен контрол на потока. Много мрежови услуги изискват наблюдение състояния на потока от данни. Например, когато използвате NAT, контролът на потока трябва да гарантира, че всеки IP: двойка портове на местоназначение има уникален изходящ порт. В случай на балансьор NLB - Балансиране на мрежовото натоварване, потокът от данни винаги трябва да бъде насочен към една и съща целева виртуална машина. Групите за сигурност са защитна стена с проследяване на състоянието. Той следи входящия трафик и имплицитно отваря портове за изходящ пакетен поток.
В облака 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 от тях по света.
- Всяка AZ се състои от центрове за обработка на данни. Те са общо не повече от 8.
- Центърът за данни съдържа огромен брой сървъри, някои с до 300 000.
Сега нека осредним всичко това, умножим и получим впечатляваща цифра, която отразява Облачен мащаб на Amazon.
Има много оптични връзки между зоните на достъпност и центъра за данни. В един от най-големите ни региони са положени 388 канала само за AZ комуникация помежду си и комуникационни центрове с други региони (Транзитни центрове). Като цяло това дава лудост 5000 Tbit.
Backbone AWS е създаден специално за и оптимизиран за облака. Ние го изграждаме върху каналите 100 GB / s. Ние ги контролираме напълно, с изключение на регионите в Китай. Трафикът не се споделя с товарите на други компании.
Разбира се, ние не сме единственият облачен доставчик с частна опорна мрежа. Все повече големи компании следват този път. Това се потвърждава от независими изследователи, например от .
Графиката показва, че делът на доставчиците на съдържание и облачните доставчици нараства. Поради това делът на интернет трафика на опорните доставчици непрекъснато намалява.
Ще обясня защо това се случва. Преди повечето уеб услуги бяха достъпни и консумирани директно от Интернет. В днешно време все повече и повече сървъри се намират в облака и са достъпни чрез CDN - Мрежа за разпространение на съдържание. За достъп до ресурс потребителят преминава през интернет само до най-близкия CDN PoP - Точка на присъствие. Най-често е някъде наблизо. След това напуска публичния интернет и лети през частен гръбнак през Атлантика, например, и стига директно до ресурса.
Чудя се как ще се промени интернет след 10 години, ако тази тенденция продължи?
Физически канали
Учените все още не са измислили как да увеличат скоростта на светлината във Вселената, но са постигнали голям напредък в методите за предаването й през оптични влакна. В момента използваме 6912 влакнести кабели. Това спомага за значително оптимизиране на разходите за тяхното инсталиране.
В някои региони трябва да използваме специални кабели. Например в района на Сидни използваме кабели със специално покритие срещу термити.
Никой не е имунизиран от неприятности и понякога каналите ни се повреждат. Снимката вдясно показва оптични кабели в един от американските региони, които бяха разкъсани от строителни работници. В резултат на инцидента са загубени само 13 пакета данни, което е изненадващо. Още веднъж - само 13! Системата буквално моментално превключи на резервни канали - кантарът работи.
Препуснахме в галоп през някои от облачните услуги и технологии на Amazon. Надявам се, че имате поне някаква представа за мащаба на задачите, които нашите инженери трябва да решат. Лично аз намирам това за много вълнуващо.
Това е последната част от трилогията от Василий Пантюхин за устройството AWS. IN части описват оптимизиране на сървъра и мащабиране на база данни, и в — функции без сървър и Firecracker.
На през ноември Василий Пантюхин ще сподели нови подробности за устройството Amazon. Той за причините за неуспехите и дизайна на разпределени системи в Amazon. 24 октомври все още е възможен билет на добра цена и плащане по-късно. Очакваме ви в HighLoad++, елате да поговорим!
Източник: www.habr.com