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 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 дахь хаягаар сольдог.
Өгөгдөл дамжуулахдаа бид логик 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-д дахин боосон байна.
Шууд холболтыг ашиглах үед урсгалыг тэмдэглэж, зохих VLAN руу илгээдэг.
HyperPlane
Энэ бол дотоод урсгалын хяналтын үйлчилгээ юм. Сүлжээний олон үйлчилгээ хяналт шаарддаг өгөгдлийн урсгалын төлөв. Жишээлбэл, NAT ашиглах үед урсгалын удирдлага нь IP: очих портын хос бүр өвөрмөц гадагшлах порттой байх ёстой. Тэнцвэржүүлэгчийн хувьд NLB - Сүлжээний ачаалал тэнцвэржүүлэгч, өгөгдлийн урсгал үргэлж ижил зорилтот виртуал машин руу чиглэсэн байх ёстой. Security Groups нь статустай галт хана юм. Энэ нь ирж буй траффикийг хянаж, гарч буй пакетын урсгалын портуудыг далд хэлбэрээр нээдэг.
AWS үүлэнд дамжуулалтын хоцрогдлын шаардлага маш өндөр байдаг. Тийм ч учраас HyperPlane бүх сүлжээний гүйцэтгэлд чухал ач холбогдолтой.
Hyperplane нь EC2 виртуал машин дээр бүтээгдсэн. Энд ид шид байхгүй, зөвхөн заль мэх л байна. Гол нь эдгээр нь том RAM-тай виртуал машинууд юм. Үйлдлүүд нь гүйлгээний шинж чанартай бөгөөд зөвхөн санах ойд хийгддэг. Энэ нь зөвхөн хэдэн арван микросекундын саатал гаргах боломжийг танд олгоно. Дисктэй ажиллах нь бүх бүтээмжийг устгах болно.
Hyperplane бол асар олон тооны ийм EC2 машинуудын тархсан систем юм. Виртуал машин бүр 5 ГБ/с зурвасын өргөнтэй. Бүс нутгийн бүх сүлжээгээр энэ нь гайхалтай терабитийн зурвасын өргөнийг хангаж, боловсруулах боломжийг олгодог секундэд сая сая холболт.
HyperPlane нь зөвхөн урсгалтай ажилладаг. VPC пакетийн капсулжуулалт нь түүний хувьд бүрэн ил тод байдаг. Энэхүү дотоод үйлчилгээний боломжит эмзэг байдал нь VPC тусгаарлалтыг эвдэхээс сэргийлнэ. Доорх түвшин нь аюулгүй байдлыг хариуцдаг.
Шуугиантай хөрш
Асуудал байсаар л байна шуугиантай хөрш - чимээ шуугиантай хөрш. Бидэнд 8 зангилаа байна гэж бодъё. Эдгээр зангилаа нь бүх үүл хэрэглэгчдийн урсгалыг боловсруулдаг. Бүх зүйл зүгээр юм шиг санагдаж, ачааллыг бүх зангилаанд жигд хуваарилах ёстой. Зангилаа нь маш хүчтэй бөгөөд тэдгээрийг хэт ачаалахад хэцүү байдаг.
Гэхдээ бид архитектураа магадлал багатай хувилбарууд дээр тулгуурлан бүтээдэг.
Бага магадлал нь боломжгүй гэсэн үг биш юм.
Нэг буюу хэд хэдэн хэрэглэгчид хэт их ачаалал үүсгэх нөхцөл байдлыг бид төсөөлж болно. Бүх HyperPlane зангилаанууд энэ ачааллыг боловсруулахад оролцдог бөгөөд бусад хэрэглэгчид ямар нэгэн гүйцэтгэлийн цохилтыг мэдрэх боломжтой. Энэ нь түрээслэгчид бие биедээ нөлөөлөх чадваргүй үүл гэсэн ойлголтыг эвддэг.
Дуу чимээтэй хөршийн асуудлыг хэрхэн шийдвэрлэх вэ? Хамгийн түрүүнд санаанд орж ирдэг зүйл бол sharding юм. Манай 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 оны XNUMX-р сард AWS нь үйлчилгээгээ санал болгож байна 22 бүс нутаг, мөн 9 дахин төлөвлөгдөж байна.
- Бүс бүр хэд хэдэн Боломжит бүсийг агуулдаг. Тэдний 69 нь дэлхий даяар байдаг.
- AZ бүр Мэдээлэл боловсруулах төвүүдээс бүрддэг. Нийтдээ 8-аас илүүгүй байна.
- Дата төвд асар олон тооны серверүүд байрладаг бөгөөд зарим нь 300 хүртэл байдаг.
Одоо энэ бүгдийг дунджаар тооцож, үржүүлж, тусгах гайхалтай тоог гаргацгаая Амазоны үүл масштаб.
Боломжийн бүсүүд болон дата төвийн хооронд олон оптик холбоосууд байдаг. Манай хамгийн том бүс нутгуудын нэгд зөвхөн өөр хоорондоо болон бусад бүс нутагтай харилцах төвүүд (Транзит төвүүд) хооронд AZ холбоо барихад зориулагдсан 388 суваг тавигдсан. Нийтдээ энэ нь галзуу юм 5000 Тбит.
Backbone AWS нь тусгайлан бүтээгдсэн бөгөөд үүлд зориулагдсан. Бид үүнийг суваг дээр бүтээдэг 100 ГБ / с. БНХАУ-ын бүс нутгийг эс тооцвол бид тэднийг бүрэн хянадаг. Замын хөдөлгөөнийг бусад компаниудын ачаалалтай хуваалцдаггүй.
Мэдээжийн хэрэг, бид хувийн үндсэн сүлжээтэй цорын ганц үүлэн үйлчилгээ үзүүлэгч биш юм. Энэ замаар том компаниуд улам олон болж байна. Үүнийг бие даасан судлаачид баталж байна, жишээлбэл .
Графикаас харахад контент нийлүүлэгчид болон үүлэн үйлчилгээ үзүүлэгчдийн эзлэх хувь нэмэгдэж байна. Үүнээс болж үндсэн үйлчилгээ үзүүлэгчдийн интернет траффикийн эзлэх хувь байнга буурч байна.
Яагаад ийм зүйл болдгийг би тайлбарлах болно. Өмнө нь ихэнх вэб үйлчилгээг интернетээс шууд ашиглах боломжтой байсан. Өнөө үед улам олон серверүүд үүлэн дээр байрлаж, дамжуулан хандах боломжтой болсон CDN - Контент түгээлтийн сүлжээ. Нөөцөд хандахын тулд хэрэглэгч зөвхөн хамгийн ойрын CDN PoP руу интернетээр дамждаг. Орших цэг. Ихэнхдээ энэ нь ойролцоо байдаг. Дараа нь нийтийн интернетийг орхиж, жишээлбэл, Атлантын далайг дамнан хувийн нуруугаар нисч, нөөцөд шууд хүрдэг.
Энэ чиг хандлага үргэлжилбэл 10 жилийн дараа интернет хэрхэн өөрчлөгдөх бол гэж бодож байна?
Физик сувгууд
Эрдэмтэд орчлон ертөнц дэх гэрлийн хурдыг хэрхэн нэмэгдүүлэх талаар хараахан олж чадаагүй байгаа ч үүнийг оптик шилэн кабелиар дамжуулах аргад ихээхэн ахиц дэвшил гаргажээ. Одоогоор 6912 ширхэг шилэн кабель ашиглаж байна. Энэ нь тэдгээрийн суурилуулалтын зардлыг мэдэгдэхүйц оновчтой болгоход тусалдаг.
Зарим бүс нутагт бид тусгай кабель ашиглах шаардлагатай болдог. Жишээлбэл, Сидней мужид бид могойн эсрэг тусгай бүрээстэй кабелийг ашигладаг.
Хэн ч бэрхшээлээс ангид байдаггүй бөгөөд заримдаа бидний суваг гэмтдэг. Баруун талд байгаа зураг дээр барилгын ажилчид урагдсан Америкийн бүс нутгийн аль нэгэнд байрлах оптик кабелийг харуулж байна. Ослын улмаас ердөө 13 дата пакет алдагдсан нь гайхмаар. Дахин нэг удаа - ердөө 13! Систем шууд утгаараа нөөц суваг руу шилжсэн - масштаб ажиллаж байна.
Бид Амазоны зарим үүлэн үйлчилгээ, технологиудыг давхилаа. Та манай инженерүүдийн шийдэх ёстой ажлын цар хүрээний талаар ядаж л ойлголттой байгаа гэж найдаж байна. Би хувьдаа энэ нь маш сэтгэл хөдөлгөм санагддаг.
Энэ бол AWS төхөөрөмжийн тухай Василий Пантюхины гурвалсан зохиолын эцсийн хэсэг юм. IN хэсэг нь серверийн оновчлол болон мэдээллийн сангийн масштабыг тайлбарлах ба дотор — сервергүй функцууд болон Firecracker.
дээр XNUMX-р сард Василий Пантюхин Amazon төхөөрөмжийн шинэ мэдээллийг хуваалцах болно. Тэр бүтэлгүйтлийн шалтгаан, Амазон дахь тархсан системийн дизайны талаар. 24-р сарын XNUMX ч боломжтой хэвээр байна сайн үнээр тасалбар авч, дараа нь төлөх. Бид таныг HighLoad++ дээр хүлээж байна, ирээд чатлацгаая!
Эх сурвалж: www.habr.com