Amazon Web Services тармагынын масштабы дүйнө жүзү боюнча 69 аймактагы 22 зонаны түзөт: АКШ, Европа, Азия, Африка жана Австралия. Ар бир зонада 8ге чейин маалымат борборлору бар - Маалыматтарды иштетүү борборлору. Ар бир маалымат борборунда миңдеген же жүз миңдеген серверлер бар. Тармак бардык күтүлбөгөн өчүрүү сценарийлери эске алынгандай иштелип чыккан. Мисалы, бардык аймактар бири-биринен обочолонуп, ал эми жеткиликтүүлүк зоналары бир нече километр аралыкта бөлүнгөн. Кабелди кесип салсаңыз да, система резервдик каналдарга өтөт жана маалыматтын жоголушу бир нече маалымат пакеттерин түзөт. Василий Пантюхин тармак дагы кандай принциптердин негизинде курулганы жана анын структурасы тууралуу айтып берет.
Василий Пантюхин .ru компанияларында Unix администратору болуп баштаган, 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 - Virtual Routing and Forwarding.
Тилекке каршы, ал ишке ашкан жок. VLAN ID болгону 12 бит, бул бизге 4096 обочолонгон сегменттерди гана берет. Эң чоң өчүргүчтөр да эң көп дегенде 1-2 миң VRF колдоно алышат. VRF менен VLANды чогуу колдонуу бизге бир нече миллион субсеттерди гана берет. Бул, албетте, он миллиондогон ижарачылар үчүн жетишсиз, алардын ар бири бир нече субсеттерди колдоно алышы керек.
Биз ошондой эле керектүү сандагы чоң кутуларды сатып ала албайбыз, мисалы, Cisco же Juniper. Эки себеп бар: бул жинди кымбат, жана биз алардын өнүгүүсүнө жана жамаачы саясатына ырайым кылгыбыз келбейт.
Бир гана тыянак бар - өзүңүздүн чечимиңизди жасаңыз.
2009-жылы жарыялаганбыз VPC - Виртуалдык Жеке Булут. Аты тыгылып, азыр көптөгөн булут провайдерлери да колдонушат.
VPC бул виртуалдык тармак SDN (Программалык камсыздоо аныкталган тармак). Биз L2 жана L3 деңгээлинде атайын протоколдорду ойлоп таппоону чечтик. Тармак стандарттуу Ethernet жана IP менен иштейт. Тармак аркылуу өткөрүү үчүн виртуалдык машина трафиги биздин өзүбүздүн протоколдук пакетте капсулдалат. Бул ижарачынын VPC таандык ID көрсөтөт.
Жөнөкөй угулат. Бирок, жоюу керек болгон бир нече олуттуу техникалык кыйынчылыктар бар. Мисалы, виртуалдык MAC/IP даректерин, VPC ID жана тиешелүү физикалык 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деги дарек менен алмаштырат.
Маалыматтарды өткөрүп жатканда, биз VPC орогучка логикалык MAC жана IP ороп алабыз. Биз мунун бардыгын тиешелүү булак жана көздөгөн 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 ичинде кайра оролгон.
Түз байланышты колдонууда трафик белгиленет жана тиешелүү VLANга жөнөтүлөт.
HyperPlane
Бул ички агымын көзөмөлдөө кызматы. Көптөгөн тармак кызматтары мониторингди талап кылат маалымат агымынын абалы. Мисалы, NAT колдонуп жатканда, агымды башкаруу ар бир IP: көздөгөн порт жупунун уникалдуу чыгуучу портуна ээ болушун камсыз кылышы керек. баланстоочу учурда NLB - Network Load Balancer, маалымат агымы ар дайым бир эле максаттуу виртуалдык машинага багытталышы керек. Коопсуздук топтору – бул абалды көрсөткөн брандмауэр. Ал кирүүчү трафикти көзөмөлдөйт жана чыгуучу пакет агымы үчүн портторду ачык түрдө ачат.
AWS булутунда берүүлөрдүн кечигүү талаптары өтө жогору. Ошол үчүн HyperPlane бүт тармактын иштеши үчүн абдан маанилүү.
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 булут масштабы.
Жеткиликтүүлүк зоналары менен маалымат борборунун ортосунда көптөгөн оптикалык байланыштар бар. Биздин ири региондорубуздун биринде бири-бири менен байланыш борборлору (Транзиттик борборлор) менен АЗ байланышы үчүн гана 388 канал тартылган. Жалпысынан алганда, бул жинди берет 5000 Тбит.
Backbone AWS атайын булут үчүн курулган жана оптималдаштырылган. Биз аны каналдарга курабыз 100 ГБ / с. Кытайдагы аймактарды кошпогондо, биз аларды толугу менен көзөмөлдөйбүз. Трафик башка компаниялардын жүктөрү менен бөлүшүлбөйт.
Албетте, биз жеке магистралдык тармакка ээ болгон жалгыз булут провайдери эмеспиз. Бул жол менен барган сайын ири компаниялар көбөйүүдө. Бул, мисалы, көз карандысыз изилдөөчүлөр тарабынан тастыкталат .
График мазмун провайдерлеринин жана булут провайдерлеринин үлүшү өсүп жатканын көрсөтүп турат. Ушундан улам магистралдык провайдерлердин интернет-трафикинин үлүшү дайыма азайып баратат.
Мен эмне үчүн мындай болгонун түшүндүрөм. Мурда көпчүлүк веб-кызматтар жеткиликтүү жана түздөн-түз Интернеттен керектелчү. Бүгүнкү күндө көбүрөөк серверлер булуттун ичинде жайгашкан жана алар аркылуу жеткиликтүү ИНК - Content Distribution Network. Ресурска жетүү үчүн колдонуучу Интернет аркылуу эң жакын CDN PoPге гана барат - Presence Point. Көбүнчө жакын жерде болот. Андан кийин ал коомдук Интернеттен чыгып, Атлантика океаны аркылуу жеке магистрал аркылуу учуп, түздөн-түз ресурска кирет.
Кызык, бул тенденция улана берсе интернет 10 жылдан кийин кандай өзгөрөт?
Физикалык каналдар
Окумуштуулар Ааламдагы жарыктын ылдамдыгын кантип жогорулатууну али аныктай элек, бирок аны оптикалык була аркылуу өткөрүү ыкмаларында чоң ийгиликтерге жетишти. Учурда 6912 була кабелин колдонобуз. Бул аларды орнотуунун баасын кыйла оптималдаштырууга жардам берет.
Кээ бир аймактарда атайын кабелдерди колдонууга туура келет. Мисалы, Сидней аймагында термиттерге каршы атайын капталган кабелдерди колдонобуз.
Кыйынчылыктардан эч ким корголбойт, кээде каналдарыбыз бузулуп калат. Оң жактагы сүрөттө Американын аймактарынын биринде курулуш жумушчулары тарабынан үзүлгөн оптикалык кабелдер көрсөтүлгөн. Кырсыктын кесепетинен 13 гана маалымат пакети жоголгон, бул таң калыштуу. Дагы бир жолу - 13 гана! Система түзмө-түз заматта резервдик каналдарга которулду - шкала иштеп жатат.
Биз Amazon'дун кээ бир булут кызматтары жана технологиялары аркылуу чуркап чыктык. Биздин инженерлер чечиши керек болгон милдеттердин масштабы жөнүндө сизде жок дегенде кандайдыр бир түшүнүк бар деп үмүттөнөм. Жеке мен муну абдан кызыктуу деп эсептейм.
Бул Василий Пантюхиндин AWS түзмөгү тууралуу үчилтигинин акыркы бөлүгү. IN бөлүктөрү серверди оптималдаштырууну жана маалымат базасын масштабдоону сүрөттөйт жана ичинде — серверсиз функциялар жана Firecracker.
боюнча ноябрда Василий Пантюхин Amazon аппаратынын жаңы деталдары менен бөлүшөт. Ал бузулуулардын себептери жана Amazon боюнча бөлүштүрүлгөн системаларды долбоорлоо жөнүндө. 24-октябрь дагы болушу мүмкүн билет жакшы баада жана кийинчерээк төлөө. Биз сизди HighLoad++то күтөбүз, келиңиз, баарлашалы!
Source: www.habr.com