Amazon Web Services tarmog'ining miqyosi butun dunyo bo'ylab 69 mintaqada: AQSh, Yevropa, Osiyo, Afrika va Avstraliyada 22 zonani tashkil etadi. Har bir zonada 8 tagacha ma'lumotlar markazlari - Ma'lumotlarni qayta ishlash markazlari mavjud. Har bir ma'lumot markazida minglab yoki yuz minglab serverlar mavjud. Tarmoq shunday yaratilganki, barcha mumkin bo'lmagan uzilishlar stsenariylari hisobga olinadi. Masalan, barcha hududlar bir-biridan ajratilgan va foydalanish imkoniyati zonalari bir necha kilometr masofada ajratilgan. Agar siz kabelni kesib qo'ysangiz ham, tizim zaxira kanallariga o'tadi va ma'lumotlarning yo'qolishi bir nechta ma'lumot paketlarini tashkil qiladi. Vasiliy Pantyuxin tarmoq yana qanday tamoyillar asosida qurilganligi va u qanday tuzilganligi haqida gapiradi.
Vasiliy Pantyuxin .ru kompaniyalarida Unix administratori sifatida ish boshlagan, 6 yil davomida Sun Microsystemning yirik uskunasida ishlagan va EMCda 11 yil davomida ma'lumotlarga asoslangan dunyoni va'z qilgan. U tabiiy ravishda shaxsiy bulutlarga aylandi, keyin esa ommaviy bulutlarga o'tdi. Endi Amazon Web Services arxitektori sifatida u AWS bulutida yashash va rivojlanishga yordam berish uchun texnik maslahatlar beradi.
AWS trilogiyasining oldingi qismida Vasiliy jismoniy serverlar dizayni va ma'lumotlar bazasini masshtablash bilan shug'ullangan. Nitro kartalari, maxsus KVM-ga asoslangan gipervizor, Amazon Aurora ma'lumotlar bazasi - bularning barchasi haqida materialda "" Kontekst uchun o'qing yoki tomosha qiling nutqlar.
Ushbu qism AWSdagi eng murakkab tizimlardan biri bo'lgan tarmoq masshtablashiga qaratiladi. Yassi tarmoqdan Virtual Private Cloudgacha bo'lgan evolyutsiya va uning dizayni, Blackfoot va HyperPlane ichki xizmatlari, shovqinli qo'shni muammosi va oxirida - tarmoq, magistral va jismoniy kabellar miqyosi. Bularning barchasi haqida kesma ostida.
Rad etish: quyida keltirilgan hamma narsa Vasiliyning shaxsiy fikri va Amazon Web Services pozitsiyasiga to'g'ri kelmasligi mumkin.
Tarmoqni masshtablash
AWS buluti 2006 yilda ishga tushirilgan. Uning tarmog'i juda ibtidoiy edi - tekis tuzilishga ega. Shaxsiy manzillar oralig'i barcha bulutli ijarachilar uchun umumiy edi. Yangi virtual mashinani ishga tushirganda, siz tasodifan ushbu diapazondan mavjud bo'lgan IP-manzilni oldingiz.
Ushbu yondashuvni amalga oshirish oson edi, lekin bulutdan foydalanishni tubdan cheklab qo'ydi. Xususan, erdagi va AWS-da xususiy tarmoqlarni birlashtirgan gibrid echimlarni ishlab chiqish juda qiyin edi. Eng keng tarqalgan muammo IP-manzil diapazonlarining bir-biriga mos kelishi edi.
Virtual shaxsiy bulut
Bulut talabga ega bo'lib chiqdi. Kengaytirish va undan o'n millionlab ijarachilar foydalanish imkoniyati haqida o'ylash vaqti keldi. Yassi tarmoq asosiy to'siqga aylandi. Shuning uchun biz foydalanuvchilarni IP diapazonlarini mustaqil tanlashlari uchun tarmoq darajasida bir-biridan qanday ajratish haqida o'yladik.
Tarmoqni izolyatsiya qilish haqida o'ylaganingizda, birinchi navbatda nima esga tushadi? Albatta VLANlar ΠΈ VRF - Virtual marshrutlash va yo'naltirish.
Afsuski, bu ish bermadi. VLAN identifikatori atigi 12 bit, bu bizga faqat 4096 ta ajratilgan segmentlarni beradi. Hatto eng katta kalitlar ham maksimal 1-2 ming VRF dan foydalanishi mumkin. VRF va VLAN-dan birgalikda foydalanish bizga bir necha million pastki tarmoqni beradi. Bu, albatta, o'n millionlab ijarachilar uchun etarli emas, ularning har biri bir nechta pastki tarmoqlardan foydalanishi kerak.
Shuningdek, biz kerakli miqdordagi katta qutilarni, masalan, Cisco yoki Juniper-dan sotib olishga qodir emasmiz. Ikkita sabab bor: bu juda qimmat va biz ularning rivojlanishi va tuzatish siyosati rahm-shafqatiga duchor bo'lishni xohlamaymiz.
Faqat bitta xulosa bor - o'z yechimingizni qiling.
2009 yilda biz e'lon qildik VPC - Virtual shaxsiy bulut. Ism saqlanib qolgan va endi ko'plab bulutli provayderlar ham undan foydalanishadi.
VPC virtual tarmoqdir SDN (Dasturiy ta'minot bilan belgilangan tarmoq). Biz L2 va L3 darajalarida maxsus protokollarni ixtiro qilmaslikka qaror qildik. Tarmoq standart Ethernet va IP-da ishlaydi. Tarmoq orqali uzatish uchun virtual mashina trafigini o'zimizning protokol o'ramiga qamrab oladi. Bu ijarachining VPC ga tegishli bo'lgan identifikatorni ko'rsatadi.
Oddiy eshitiladi. Biroq, engib o'tish kerak bo'lgan bir qancha jiddiy texnik muammolar mavjud. Masalan, virtual MAC/IP manzillarini, VPC identifikatorini va mos keladigan jismoniy MAC/IP-ni xaritalash bo'yicha ma'lumotlarni qaerda va qanday saqlash kerak. AWS miqyosida bu juda katta jadval bo'lib, minimal kirish kechikishlari bilan ishlashi kerak. Buning uchun javobgar xaritalash xizmati, bu butun tarmoq bo'ylab nozik bir qatlamda yoyilgan.
Yangi avlod mashinalarida inkapsulyatsiya Nitro kartalari tomonidan apparat darajasida amalga oshiriladi. Eski holatlarda inkapsulyatsiya va dekapsulyatsiya dasturiy ta'minotga asoslangan.
Keling, umumiy ma'noda qanday ishlashini aniqlaylik. L2 darajasidan boshlaylik. Keling, 10.0.0.2 jismoniy serverida IP 192.168.0.3 bo'lgan virtual mashinamiz bor deb faraz qilaylik. U ma'lumotlarni 10.0.0.3 da yashaydigan 192.168.1.4 virtual mashinasiga yuboradi. ARP so'rovi yaratiladi va tarmoq Nitro kartasiga yuboriladi. Oddiylik uchun ikkala virtual mashina ham bir xil "ko'k" VPCda yashaydi deb taxmin qilamiz.
Xarita manba manzilini o'zi bilan almashtiradi va ARP ramkasini xaritalash xizmatiga yo'naltiradi.
Xaritalash xizmati L2 jismoniy tarmog'i orqali uzatish uchun zarur bo'lgan ma'lumotlarni qaytaradi.
ARP javobidagi Nitro kartasi jismoniy tarmoqdagi MAC-ni VPC-dagi manzil bilan almashtiradi.
Ma'lumotlarni uzatishda biz mantiqiy MAC va IP-ni VPC o'ramiga o'tkazamiz. Biz bularning barchasini tegishli manba va maqsadli IP Nitro kartalari yordamida jismoniy tarmoq orqali uzatamiz.
Paket mo'ljallangan jismoniy mashina tekshirishni amalga oshiradi. Bu manzilni buzish ehtimolini oldini olish uchun zarur. Mashina xaritalash xizmatiga maxsus so'rov yuboradi va so'raydi: β192.168.0.3 jismoniy mashinasidan men ko'k VPCda 10.0.0.3 uchun mo'ljallangan paketni oldim. U qonuniymi?
Xaritalash xizmati o'zining resurslarni taqsimlash jadvalini tekshiradi va paketni o'tkazishga ruxsat beradi yoki rad etadi. Barcha yangi holatlarda qo'shimcha tekshirish Nitro kartalariga kiritilgan. Hatto nazariy jihatdan ham uni chetlab o'tish mumkin emas. Shuning uchun, boshqa VPC-dagi resurslarni aldash ishlamaydi.
Keyinchalik, ma'lumotlar u uchun mo'ljallangan virtual mashinaga yuboriladi.
Xaritalash xizmati, shuningdek, turli pastki tarmoqlardagi virtual mashinalar o'rtasida ma'lumotlarni uzatish uchun mantiqiy router sifatida ishlaydi. Hammasi kontseptual jihatdan oddiy, men batafsil ma'lumot bermayman.
Ma'lum bo'lishicha, har bir paketni uzatishda serverlar xaritalash xizmatiga murojaat qilishadi. Muqarrar kechikishlar bilan qanday kurashish mumkin? Keshlash, albatta.
Chiroyli tomoni shundaki, butun katta stolni keshlash shart emas. Jismoniy serverda nisbatan kam sonli VPClardan virtual mashinalar joylashgan. Siz faqat ushbu VPClar haqidagi ma'lumotlarni keshlashingiz kerak. Ma'lumotlarni "standart" konfiguratsiyadagi boshqa VPC-larga o'tkazish hali ham qonuniy emas. Agar VPC-peering kabi funksionallik ishlatilsa, tegishli VPClar haqidagi ma'lumotlar qo'shimcha ravishda keshga yuklanadi.
Biz VPC-ga ma'lumotlarni uzatishni tartibga soldik.
Qora oyoq
Trafik tashqariga, masalan, Internetga yoki VPN orqali erga uzatilishi kerak bo'lgan hollarda nima qilish kerak? Bu erda bizga yordam beradi Qora oyoq β AWS ichki xizmati. Bu bizning Janubiy Afrika jamoamiz tomonidan ishlab chiqilgan. Shuning uchun xizmat Janubiy Afrikada yashovchi pingvin nomi bilan atalgan.
Blackfoot trafikni dekapsulatsiya qiladi va u bilan kerakli narsani qiladi. Ma'lumotlar Internetga xuddi shunday yuboriladi.
VPN-dan foydalanganda ma'lumotlar dekapsulatsiyalanadi va IPsec-ga qayta o'raladi.
Direct Connect-dan foydalanilganda, trafik teglanadi va tegishli VLAN-ga yuboriladi.
HyperPlane
Bu ichki oqimni boshqarish xizmati. Ko'pgina tarmoq xizmatlari monitoringni talab qiladi ma'lumotlar oqimi holati. Misol uchun, NAT dan foydalanilganda, oqimni boshqarish har bir IP: maqsadli port juftligi noyob chiqish portiga ega bo'lishini ta'minlashi kerak. Balanslashtiruvchi holatda NLB - Tarmoq yuk balansi, ma'lumotlar oqimi har doim bir xil maqsadli virtual mashinaga yo'naltirilishi kerak. Xavfsizlik guruhlari - bu statistik xavfsizlik devori. U kiruvchi trafikni kuzatib boradi va chiquvchi paketlar oqimi uchun portlarni bilvosita ochadi.
AWS bulutida uzatishni kechiktirish talablari juda yuqori. Shunung uchun HyperPlane butun tarmoqning ishlashi uchun juda muhim.
Hyperplane EC2 virtual mashinalarida qurilgan. Bu erda hech qanday sehr yo'q, faqat ayyorlik. Ayyorlik shundaki, bu katta operativ xotiraga ega virtual mashinalar. Operatsiyalar tranzaktsion va faqat xotirada bajariladi. Bu faqat o'nlab mikrosekundlik kechikishlarga erishish imkonini beradi. Disk bilan ishlash barcha unumdorlikni o'ldiradi.
Giperplan - bu juda ko'p sonli EC2 mashinalarining taqsimlangan tizimi. Har bir virtual mashinaning tarmoqli kengligi 5 Gb/s. Butun mintaqaviy tarmoq bo'ylab, bu ajoyib o'tkazish qobiliyatini ta'minlaydi va qayta ishlashga imkon beradi soniyada millionlab ulanishlar.
HyperPlane faqat oqimlar bilan ishlaydi. VPC paketining inkapsulyatsiyasi uning uchun mutlaqo shaffofdir. Ushbu ichki xizmatdagi potentsial zaiflik hali ham VPC izolyatsiyasining buzilishini oldini oladi. Quyidagi darajalar xavfsizlik uchun javobgardir.
Shovqinli qo'shni
Hali muammo bor shovqinli qo'shni - shovqinli qo'shni. Faraz qilaylik, bizda 8 ta tugun bor. Ushbu tugunlar barcha bulut foydalanuvchilarining oqimlarini qayta ishlaydi. Har bir narsa yaxshi ko'rinadi va yuk barcha tugunlar bo'ylab teng taqsimlanishi kerak. Tugunlar juda kuchli va ularni ortiqcha yuklash qiyin.
Ammo biz arxitekturamizni hatto kutilmagan stsenariylar asosida quramiz.
Kam ehtimollik imkonsiz degani emas.
Biz bir yoki bir nechta foydalanuvchi juda ko'p yuk hosil qiladigan vaziyatni tasavvur qilishimiz mumkin. Barcha HyperPlane tugunlari ushbu yukni qayta ishlashda ishtirok etadi va boshqa foydalanuvchilar potentsial ravishda qandaydir ish faoliyatini boshdan kechirishlari mumkin. Bu bulut tushunchasini buzadi, unda ijarachilar bir-biriga ta'sir qilish qobiliyatiga ega emaslar.
Shovqinli qo'shnining muammosini qanday hal qilish mumkin? Aqlga keladigan birinchi narsa - sharding. Bizning 8 ta tugunimiz mantiqiy ravishda har biri 4 ta tugunning 2 ta bo'lagiga bo'lingan. Endi shovqinli qo'shni barcha foydalanuvchilarning to'rtdan bir qismini bezovta qiladi, lekin bu ularni juda bezovta qiladi.
Keling, ishlarni boshqacha qilaylik. Biz har bir foydalanuvchiga faqat 3 ta tugun ajratamiz.
Ayyorlik tugunlarni turli foydalanuvchilarga tasodifiy belgilashdir. Quyidagi rasmda ko'k foydalanuvchi tugunlarni boshqa ikkita foydalanuvchidan biri - yashil va to'q sariq rang bilan kesishadi.
8 ta tugun va 3 foydalanuvchi bilan shovqinli qo'shnining foydalanuvchilardan biri bilan kesishishi ehtimoli 54% ni tashkil qiladi. Aynan shu ehtimol bilan ko'k foydalanuvchi boshqa ijarachilarga ta'sir qiladi. Shu bilan birga, uning yukining faqat bir qismi. Bizning misolimizda, bu ta'sir hech bo'lmaganda hamma uchun emas, balki barcha foydalanuvchilarning uchdan bir qismi uchun sezilarli bo'ladi. Bu allaqachon yaxshi natija.
Kesishadigan foydalanuvchilar soni
Ehtimollik foizda
0
18%
1
54%
2
26%
3
2%
Keling, vaziyatni haqiqatga yaqinlashtiramiz - keling, 100 ta tugun va 5 ta tugun bo'yicha 5 foydalanuvchini olaylik. Bunday holda, tugunlarning hech biri 77% ehtimollik bilan kesishmaydi.
Kesishadigan foydalanuvchilar soni
Ehtimollik foizda
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Haqiqiy vaziyatda juda ko'p sonli HyperPlane tugunlari va foydalanuvchilari bilan shovqinli qo'shnining boshqa foydalanuvchilarga ta'siri minimaldir. Bu usul deyiladi shardingni aralashtirish - aralashtirish. Bu tugun etishmovchiligining salbiy ta'sirini kamaytiradi.
Ko'pgina xizmatlar HyperPlane asosida qurilgan: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Tarmoq shkalasi
Endi tarmoqning o'zi ko'lami haqida gapiraylik. 2019 yil oktyabr oyida AWS o'z xizmatlarini taklif etadi 22 viloyat, va yana 9 tasi rejalashtirilgan.
- Har bir hududda bir nechta mavjudlik zonalari mavjud. Dunyo bo'ylab ularning 69 tasi bor.
- Har bir AZ ma'lumotlarni qayta ishlash markazlaridan iborat. Ularning umumiy soni 8 tadan oshmaydi.
- Ma'lumotlar markazida juda ko'p serverlar mavjud, ba'zilarida 300 000 tagacha.
Keling, bularning barchasini o'rtacha hisoblaymiz, ko'paytiramiz va aks ettiruvchi ta'sirchan raqamni olamiz Amazon bulut shkalasi.
Mavjudlik zonalari va ma'lumotlar markazi o'rtasida ko'plab optik aloqalar mavjud. Eng yirik hududlarimizdan birida bir-biri va boshqa mintaqalar bilan aloqa markazlari (Tranzit markazlari) o'rtasida faqat AZ aloqasi uchun 388 ta kanal yotqizilgan. Umuman olganda, bu aqldan ozish imkonini beradi 5000 Tbit.
Backbone AWS bulut uchun maxsus ishlab chiqilgan va optimallashtirilgan. Biz uni kanallarda quramiz 100 GB / s. Biz ularni butunlay nazorat qilamiz, Xitoydagi hududlar bundan mustasno. Trafik boshqa kompaniyalarning yuklari bilan taqsimlanmaydi.
Albatta, biz xususiy magistral tarmoqqa ega yagona bulut provayderi emasmiz. Bu yo'ldan tobora ko'proq yirik kompaniyalar ketmoqda. Bu mustaqil tadqiqotchilar tomonidan tasdiqlangan, masalan .
Grafik kontent provayderlari va bulutli provayderlarning ulushi ortib borayotganini ko'rsatadi. Shu sababli, magistral provayderlarning Internet-trafik ulushi doimiy ravishda kamayib bormoqda.
Nima uchun bu sodir bo'lishini tushuntiraman. Ilgari ko'pgina veb-xizmatlar to'g'ridan-to'g'ri Internetdan foydalanish mumkin edi va iste'mol qilinadi. Hozirgi vaqtda tobora ko'proq serverlar bulutda joylashgan va ular orqali kirish mumkin CDN - Kontentni tarqatish tarmog'i. Resursga kirish uchun foydalanuvchi Internet orqali faqat eng yaqin CDN PoP-ga o'tadi - Mavjudlik nuqtasi. Ko'pincha u yaqin joyda joylashgan. Keyin u umumiy Internetni tark etadi va masalan, Atlantika okeani bo'ylab xususiy magistral orqali uchadi va to'g'ridan-to'g'ri resursga kiradi.
Qiziq, bu tendentsiya davom etsa, 10 yildan keyin internet qanday o'zgaradi?
Jismoniy kanallar
Olimlar hali koinotdagi yorug'lik tezligini qanday oshirishni aniqlay olishmadi, lekin ular optik tolalar orqali uni uzatish usullarida katta yutuqlarga erishdilar. Hozirda biz 6912 ta tolali kabellardan foydalanamiz. Bu ularni o'rnatish xarajatlarini sezilarli darajada optimallashtirishga yordam beradi.
Ba'zi hududlarda biz maxsus kabellardan foydalanishimiz kerak. Misol uchun, Sidney viloyatida biz termitlarga qarshi maxsus qoplamali kabellardan foydalanamiz.
Hech kim muammolardan himoyalanmaydi va ba'zida kanallarimiz buziladi. O'ngdagi fotosuratda Amerika mintaqalaridan birida qurilish ishchilari tomonidan yirtilgan optik kabellar ko'rsatilgan. Baxtsiz hodisa natijasida bor-yo'g'i 13 ta ma'lumot paketi yo'qolgan, bu ajablanarli. Yana bir bor - atigi 13! Tizim tom ma'noda zahira kanallariga o'tdi - o'lchov ishlamoqda.
Biz Amazonning ba'zi bulut xizmatlari va texnologiyalari orqali yugurdik. Umid qilamanki, muhandislarimiz hal qilishlari kerak bo'lgan vazifalar ko'lami haqida hech bo'lmaganda tasavvurga egasiz. Shaxsan men buni juda hayajonli deb bilaman.
Bu Vasiliy Pantyuxinning AWS qurilmasi haqidagi trilogiyasining yakuniy qismi. IN qismlar server optimallashtirish va ma'lumotlar bazasini masshtablash tasvirlab, va β serversiz funksiyalar va Firecracker.
ning noyabr oyida Vasiliy Pantyuxin Amazon qurilmasining yangi tafsilotlari bilan o'rtoqlashadi. U nosozliklar sabablari va Amazonda taqsimlangan tizimlarning dizayni haqida. 24 oktyabr hali ham mumkin yaxshi narxda chipta oling va keyinroq to'lang. Sizni HighLoad++ da kutamiz, keling va suhbatlashamiz!
Manba: www.habr.com