Amazon Web Services желісінің ауқымы бүкіл әлем бойынша 69 аймақтағы 22 аймақты құрайды: АҚШ, Еуропа, Азия, Африка және Австралия. Әрбір аймақта 8 деректер орталығына дейін бар - Деректерді өңдеу орталықтары. Әрбір деректер орталығында мыңдаған немесе жүздеген мың серверлер бар. Желі барлық ықтимал үзіліс сценарийлері ескерілетін етіп жасалған. Мысалы, барлық аймақтар бір-бірінен оқшауланған, ал қолжетімділік аймақтары бірнеше километр қашықтықта бөлінген. Кабельді кесіп тастасаңыз да, жүйе резервтік арналарға ауысады және ақпараттың жоғалуы бірнеше деректер пакетін құрайды. Василий Пантюхин желі тағы қандай принциптерге негізделгенін және оның құрылымын айтады.
Василий Пантюхин .ru компанияларында Unix әкімшісі ретінде бастады, үлкен 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 идентификаторы тек 12 бит, бұл бізге тек 4096 оқшауланған сегменттерді береді. Тіпті ең үлкен қосқыштар ең көбі 1-2 мың VRF пайдалана алады. VRF және VLAN бірге пайдалану бізге тек бірнеше миллион ішкі желіні береді. Бұл, әрине, ондаған миллион жалға алушылар үшін жеткіліксіз, олардың әрқайсысы бірнеше ішкі желілерді пайдалана алуы керек.
Біз сондай-ақ, мысалы, Cisco немесе Juniper сияқты үлкен қораптардың қажетті санын сатып ала алмаймыз. Екі себеп бар: бұл өте қымбат, және біз олардың дамуы мен патч саясатының мейіріміне ұшырағымыз келмейді.
Бір ғана қорытынды бар - өз шешіміңізді жасаңыз.
2009 жылы хабарлаған болатынбыз VPC - Виртуалды жеке бұлт. Атау кептеліп қалды және қазір көптеген бұлттық провайдерлер де оны пайдаланады.
VPC - бұл виртуалды желі SDN (Бағдарламалық құрал анықталған желі). Біз L2 және L3 деңгейлерінде арнайы хаттамаларды ойлап таппауды шештік. Желі стандартты Ethernet және IP желілерінде жұмыс істейді. Желі арқылы тасымалдау үшін виртуалды машина трафигі біздің жеке протокол қаптамасында инкапсуляцияланады. Ол жалға алушының VPC-ге жататын идентификаторды көрсетеді.
Қарапайым естіледі. Дегенмен, еңсеруді қажет ететін бірнеше күрделі техникалық қиындықтар бар. Мысалы, виртуалды MAC/IP мекенжайларын, VPC идентификаторын және сәйкес физикалық MAC/IP салыстыру бойынша деректерді қайда және қалай сақтауға болады. AWS масштабында бұл ең аз қол жеткізу кідірістерімен жұмыс істеуі керек үлкен кесте. Бұған жауапты картаға түсіру қызметі, ол бүкіл желіге жұқа қабатта таралған.
Жаңа буын машиналарында инкапсуляция аппараттық деңгейде Nitro карталарымен орындалады. Ескі жағдайларда инкапсуляция және декапсуляция бағдарламалық құралға негізделген.
Оның жалпы мағынада қалай жұмыс істейтінін анықтайық. L2 деңгейінен бастайық. Бізде 10.0.0.2 физикалық серверінде IP 192.168.0.3 виртуалды машина бар деп есептейік. Ол деректерді 10.0.0.3 нұсқасында тұратын 192.168.1.4 виртуалды машинасына жібереді. ARP сұрауы жасалады және желілік Nitro картасына жіберіледі. Қарапайымдылық үшін екі виртуалды машина бірдей «көк» VPC-де тұрады деп есептейміз.
Карта бастапқы мекенжайды өзінің мекен-жайымен ауыстырады және ARP кадрын салыстыру қызметіне жібереді.
Карталау қызметі L2 физикалық желі арқылы тасымалдауға қажетті ақпаратты қайтарады.
ARP жауапындағы Nitro картасы физикалық желідегі MAC-ды VPC мекенжайымен ауыстырады.
Деректерді тасымалдау кезінде біз логикалық MAC және IP-ді VPC қаптамасына орап аламыз. Біз мұның бәрін физикалық желі арқылы тиісті бастапқы және тағайындалған IP Nitro карталарын пайдаланып жібереміз.
Пакет тағайындалған физикалық машина тексеруді орындайды. Бұл мекенжайды бұрмалау мүмкіндігін болдырмау үшін қажет. Құрылғы карта жасау қызметіне арнайы сұрау жібереді және сұрайды: «192.168.0.3 физикалық машинасынан көк VPC-де 10.0.0.3 үшін арналған пакетті алдым. Ол заңды ма?
Карталау қызметі өзінің ресурстарды бөлу кестесін тексереді және пакеттің өтуіне рұқсат береді немесе бас тартады. Барлық жаңа жағдайларда қосымша тексеру Nitro карталарына енгізілген. Оны теориялық тұрғыдан да айналып өту мүмкін емес. Сондықтан басқа VPC-дегі ресурстарға спуфинг жұмыс істемейді.
Әрі қарай, деректер ол арналған виртуалды машинаға жіберіледі.
Карталау қызметі әртүрлі ішкі желілердегі виртуалды машиналар арасында деректерді тасымалдауға арналған логикалық маршрутизатор ретінде де жұмыс істейді. Барлығы қарапайым, мен егжей-тегжейлі айтпаймын.
Әрбір пакетті жіберген кезде серверлер карта жасау қызметіне жүгінеді екен. Еріксіз кешігулермен қалай күресуге болады? Кэштеу, Әрине.
Сұлулық мынада: бүкіл үлкен кестені кэштеу қажет емес. Физикалық серверде VPC салыстырмалы аз санынан виртуалды машиналар орналасады. Сізге тек осы VPC туралы ақпаратты кэштеу қажет. Деректерді «әдепкі» конфигурациядағы басқа VPC-ге тасымалдау әлі де заңды емес. VPC-peering сияқты функционалдылық пайдаланылса, сәйкес VPC туралы ақпарат кэшке қосымша жүктеледі.
Біз деректерді VPC-ге тасымалдауды сұрыптадық.
Қара аяқ
Трафикті сыртқа, мысалы, Интернетке немесе VPN арқылы жерге жіберу қажет болған жағдайда не істеу керек? Бұл жерде бізге көмектеседі Қара аяқ — AWS ішкі қызметі. Оны біздің Оңтүстік Африка командасы әзірледі. Сондықтан бұл қызмет Оңтүстік Африкада тұратын пингвиннің атымен аталған.
Blackfoot трафикті декапсуляциялайды және онымен қажет нәрсені жасайды. Деректер Интернетке сол күйінде жіберіледі.
Деректер декапсуляцияланады және VPN пайдаланған кезде IPsec ішіне қайта оралады.
Direct Connect пайдалану кезінде трафик тегтеліп, сәйкес VLAN желісіне жіберіледі.
HyperPlane
Бұл ішкі ағынды басқару қызметі. Көптеген желі қызметтері бақылауды қажет етеді деректер ағынының күйлері. Мысалы, NAT пайдалану кезінде ағынды басқару әрбір IP: тағайындалған порт жұбының бірегей шығыс порты болуын қамтамасыз етуі керек. Баланстаушы жағдайында NLB - Желілік жүктеме балансы, деректер ағыны әрқашан бірдей мақсатты виртуалды машинаға бағытталуы керек. Қауіпсіздік топтары күйі бар брандмауэр болып табылады. Ол кіріс трафикті бақылайды және шығыс пакеттер ағыны үшін жанама түрде порттарды ашады.
AWS бұлтында жіберудің кешігуіне қойылатын талаптар өте жоғары. Сондықтан HyperPlane бүкіл желінің өнімділігі үшін маңызды.
Гиперплан EC2 виртуалды машиналарында құрастырылған. Мұнда ешқандай сиқыр жоқ, тек қулық. Бұл үлкен оперативті жады бар виртуалды машиналар. Операциялар транзакциялық және тек жадта орындалады. Бұл тек ондаған микросекундтық кідірістерге қол жеткізуге мүмкіндік береді. Дискпен жұмыс істеу барлық өнімділікті жояды.
Гиперплан - бұл көптеген 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 түйіндері мен пайдаланушыларының үлкен саны бар, шулы көршінің басқа пайдаланушыларға ықтимал әсері аз. Бұл әдіс деп аталады араластыру - араластыру. Ол түйіннің істен шығуының теріс әсерін азайтады.
Көптеген қызметтер HyperPlane негізінде құрастырылған: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Желі масштабы
Енді желінің өзінің ауқымы туралы сөйлесейік. 2019 жылдың қазан айында AWS өз қызметтерін ұсынады 22 облыс, және тағы 9-ы жоспарланған.
- Әр аймақта бірнеше қолжетімділік аймақтары бар. Дүние жүзінде олардың 69-ы бар.
- Әрбір AZ мәліметтерді өңдеу орталықтарынан тұрады. Олардың жалпы саны 8-ден аспайды.
- Деректер орталығында көптеген серверлер бар, олардың кейбіреулері 300 000-ға дейін жетеді.
Енді осының барлығын орташалап, көбейтіп, көрсететін әсерлі фигураны алайық Amazon бұлтты шкаласы.
Қолжетімділік аймақтары мен деректер орталығы арасында көптеген оптикалық байланыстар бар. Біздің ірі өңірлеріміздің бірінде бір-бірімен және басқа аймақтармен байланыс орталықтары (Транзиттік орталықтар) арасындағы AZ байланысы үшін ғана 388 арна тартылған. Жалпы алғанда, бұл ақылсыздықты береді 5000 Тбит.
Backbone AWS бұлт үшін арнайы жасалған және оңтайландырылған. Біз оны арналарға саламыз 100 ГБ / с. Біз Қытайдағы аймақтарды қоспағанда, оларды толығымен басқарамыз. Трафик басқа компаниялардың жүктемелерімен бөлісілмейді.
Әрине, біз жеке магистральдық желісі бар жалғыз бұлттық провайдер емеспіз. Бұл жолды таңдаған ірі компаниялар көбейіп келеді. Мұны тәуелсіз зерттеушілер растайды, мысалы .
График контент провайдерлері мен бұлттық провайдерлердің үлесі өсіп келе жатқанын көрсетеді. Осыған байланысты магистральдық провайдерлердің интернет-трафик үлесі үнемі азайып келеді.
Мен мұның себебін түсіндіремін. Бұрын веб-қызметтердің көпшілігі қол жетімді және Интернеттен тікелей тұтынылатын. Қазіргі уақытта көбірек серверлер бұлтта орналасқан және олар арқылы қол жетімді CDN - Мазмұнды тарату желісі. Ресурсқа қол жеткізу үшін пайдаланушы Интернет арқылы тек ең жақын CDN PoP-ге өтеді - Болу нүктесі. Көбінесе ол жақын жерде болады. Содан кейін ол жалпыға ортақ Интернеттен шығып, Атлант мұхиты арқылы жеке магистраль арқылы ұшып, ресурсқа тікелей түседі.
Қызық, бұл үрдіс жалғаса берсе, 10 жылдан кейін интернет қалай өзгереді?
Физикалық арналар
Ғалымдар Әлемдегі жарық жылдамдығын қалай арттыруға болатынын әлі анықтаған жоқ, бірақ оны оптикалық талшық арқылы беру әдістерінде үлкен жетістіктерге жетті. Қазіргі уақытта 6912 талшықты кабельді қолданамыз. Бұл оларды орнату құнын айтарлықтай оңтайландыруға көмектеседі.
Кейбір аймақтарда арнайы кабельдерді қолдануға тура келеді. Мысалы, Сидней аймағында термиттерге қарсы арнайы жабыны бар кабельдерді пайдаланамыз.
Ешкім қиындықтан қорғанбайды, кейде арналарымыз бұзылады. Оң жақтағы фотосуретте американдық аймақтардың бірінде құрылыс жұмысшылары үзген оптикалық кабельдер көрсетілген. Апат салдарынан тек 13 деректер пакеті жоғалды, бұл таң қалдырады. Тағы да - бар болғаны 13! Жүйе бірден резервтік арналарға ауысты - шкала жұмыс істейді.
Біз Amazon-ның кейбір бұлттық қызметтері мен технологиялары арқылы жүгірдік. Сізде кем дегенде біздің инженерлер шешуі керек міндеттердің ауқымы туралы түсінік бар деп үміттенемін. Жеке өзім бұл өте қызықты деп ойлаймын.
Бұл Василий Пантюхиннің AWS құрылғысы туралы трилогиясының соңғы бөлігі. IN бөліктер серверді оңтайландыруды және дерекқорды масштабтауды сипаттайды — серверсіз функциялар және Firecracker.
туралы қарашада Василий Пантюхин Amazon құрылғысының жаңа мәліметтерімен бөліседі. Ол сәтсіздіктердің себептері және Amazon-дағы бөлінген жүйелердің дизайны туралы. 24 қазан әлі де мүмкін билетті жақсы бағамен алып, кейінірек төлеңіз. Біз сізді HighLoad++ бағдарламасында күтеміз, келіңіз, сөйлесейік!
Ақпарат көзі: www.habr.com