Kiwango cha mtandao wa Amazon Web Services ni kanda 69 duniani kote katika mikoa 22: Marekani, Ulaya, Asia, Afrika na Australia. Kila eneo lina hadi vituo 8 vya data - Vituo vya Kuchakata Data. Kila kituo cha data kina maelfu au mamia ya maelfu ya seva. Mtandao umeundwa kwa njia ambayo matukio yote yasiyowezekana ya kukatika huzingatiwa. Kwa mfano, mikoa yote imetengwa kutoka kwa kila mmoja, na maeneo ya ufikiaji yanatenganishwa kwa umbali wa kilomita kadhaa. Hata ukikata kebo, mfumo utabadilika kuwa chaneli chelezo, na upotevu wa taarifa utafikia pakiti chache za data. Vasily Pantyukhin atazungumza juu ya kanuni zingine ambazo mtandao umejengwa na jinsi umeundwa.
Vasily Pantyukhin ilianza kama msimamizi wa Unix katika makampuni ya .ru, ilifanya kazi kwenye maunzi makubwa ya mfumo wa Sun Microsystem kwa miaka 6, na kuhubiri ulimwengu unaozingatia data kwa miaka 11 katika EMC. Kwa kawaida ilibadilika kuwa mawingu ya kibinafsi, kisha ikahamia kwa umma. Sasa, kama mbunifu wa Huduma za Wavuti za Amazon, anatoa ushauri wa kiufundi kusaidia kuishi na kukuza katika wingu la AWS.
Katika sehemu ya awali ya trilojia ya AWS, Vasily alijikita katika muundo wa seva za kimwili na kuongeza hifadhidata. Kadi za Nitro, hypervisor ya msingi ya KVM, hifadhidata ya Amazon Aurora - juu ya haya yote kwenye nyenzo "" Soma kwa muktadha au tazama hotuba.
Sehemu hii itazingatia kuongeza mtandao, mojawapo ya mifumo ngumu zaidi katika AWS. Mageuzi kutoka kwa mtandao wa gorofa hadi Wingu la Kibinafsi la Virtual na muundo wake, huduma za ndani za Blackfoot na HyperPlane, tatizo la jirani yenye kelele, na mwisho - ukubwa wa mtandao, uti wa mgongo na nyaya za kimwili. Kuhusu haya yote chini ya kukata.
Kanusho: kila kitu hapa chini ni maoni ya kibinafsi ya Vasily na huenda yasiendane na msimamo wa Huduma za Wavuti za Amazon.
Kuongeza mtandao
Wingu la AWS lilizinduliwa mnamo 2006. Mtandao wake ulikuwa wa zamani kabisa - na muundo wa gorofa. Aina mbalimbali za anwani za kibinafsi zilikuwa za kawaida kwa wapangaji wote wa wingu. Wakati wa kuanzisha mashine mpya pepe, ulipokea kwa bahati mbaya anwani ya IP inayopatikana kutoka kwa safu hii.
Mbinu hii ilikuwa rahisi kutekeleza, lakini kimsingi ilipunguza matumizi ya wingu. Hasa, ilikuwa ngumu sana kuunda suluhisho za mseto ambazo zilichanganya mitandao ya kibinafsi chini na katika AWS. Tatizo la kawaida lilikuwa kuingiliana kwa safu za anwani za IP.
Wingu la Kibinafsi la kweli
Wingu liligeuka kuwa katika mahitaji. Wakati umefika wa kufikiria juu ya hatari na uwezekano wa matumizi yake na makumi ya mamilioni ya wapangaji. Mtandao wa gorofa umekuwa kikwazo kikubwa. Kwa hivyo, tulifikiria jinsi ya kuwatenga watumiaji kutoka kwa kila mmoja kwenye kiwango cha mtandao ili waweze kuchagua kwa uhuru safu za IP.
Ni jambo gani la kwanza linalokuja akilini unapofikiria kuhusu kutengwa kwa mtandao? Hakika VLAN ΠΈ VRF - Usambazaji na Usambazaji Pembeni.
Kwa bahati mbaya, haikufanya kazi. Kitambulisho cha VLAN ni biti 12 pekee, ambayo inatupa sehemu 4096 pekee. Hata swichi kubwa zaidi zinaweza kutumia kiwango cha juu cha VRF 1-2 elfu. Kutumia VRF na VLAN pamoja hutupatia subneti milioni chache tu. Kwa hakika hii haitoshi kwa makumi ya mamilioni ya wapangaji, ambayo kila mmoja lazima awe na uwezo wa kutumia subnets nyingi.
Pia hatuwezi kumudu kununua idadi inayotakiwa ya masanduku makubwa, kwa mfano, kutoka Cisco au Juniper. Kuna sababu mbili: ni ghali sana, na hatutaki kuwa katika huruma ya maendeleo yao na sera za kuweka viraka.
Kuna hitimisho moja tu - fanya suluhisho lako mwenyewe.
Mwaka 2009 tulitangaza VPC - Wingu la Kibinafsi la kweli. Jina lilikwama na sasa watoa huduma wengi wa wingu pia wanalitumia.
VPC ni mtandao pepe SDN (Mtandao Uliofafanuliwa wa Programu). Tuliamua kutoanzisha itifaki maalum katika viwango vya L2 na L3. Mtandao unatumia Ethaneti ya kawaida na IP. Kwa utumaji kwenye mtandao, trafiki ya mashine pepe imeambatanishwa kwenye karatasi yetu ya itifaki. Inaonyesha kitambulisho ambacho ni cha VPC ya mpangaji.
Inaonekana rahisi. Walakini, kuna changamoto kadhaa kubwa za kiufundi ambazo zinahitaji kushinda. Kwa mfano, wapi na jinsi ya kuhifadhi data kwenye ramani za anwani pepe za MAC/IP, Kitambulisho cha VPC na MAC/IP halisi inayolingana. Kwa kiwango cha AWS, hii ni jedwali kubwa ambalo linapaswa kufanya kazi na ucheleweshaji mdogo wa ufikiaji. Kuwajibika kwa hili huduma ya ramani, ambayo imeenea kwenye safu nyembamba kwenye mtandao.
Katika mashine za kizazi kipya, encapsulation inafanywa na kadi za Nitro kwenye ngazi ya vifaa. Katika matukio ya zamani, encapsulation na decapsulation ni programu-msingi.
Wacha tuone jinsi inavyofanya kazi kwa jumla. Wacha tuanze na kiwango cha L2. Hebu tuchukue kuwa tuna mashine ya kawaida na IP 10.0.0.2 kwenye seva ya kimwili 192.168.0.3. Inatuma data kwa mashine ya kawaida 10.0.0.3, ambayo inaishi 192.168.1.4. Ombi la ARP linatolewa na kutumwa kwa kadi ya mtandao ya Nitro. Kwa urahisi, tunadhania kuwa mashine zote mbili pepe zinaishi katika VPC sawa ya "bluu".
Ramani hubadilisha anwani ya chanzo na yake na kupeleka mbele fremu ya ARP kwa huduma ya uchoraji ramani.
Huduma ya uchoraji ramani hurejesha taarifa ambayo ni muhimu kwa uwasilishaji kupitia mtandao halisi wa L2.
Kadi ya Nitro katika majibu ya ARP inachukua nafasi ya MAC kwenye mtandao halisi na anwani katika VPC.
Wakati wa kuhamisha data, tunafunga MAC na IP yenye mantiki kwenye karatasi ya VPC. Tunasambaza haya yote kupitia mtandao halisi kwa kutumia chanzo na kadi za IP Nitro zinazofaa.
Mashine ya kimwili ambayo kifurushi kinakusudiwa hufanya ukaguzi. Hii ni muhimu ili kuzuia uwezekano wa uharibifu wa anwani. Mashine hutuma ombi maalum kwa huduma ya uchoraji wa ramani na inauliza: "Kutoka kwa mashine halisi 192.168.0.3 nilipokea pakiti ambayo imekusudiwa 10.0.0.3 kwenye VPC ya bluu. Je, yeye ni halali?
Huduma ya uchoraji ramani hukagua jedwali lake la mgao wa rasilimali na kuruhusu au kukataa pakiti kupita. Katika matukio yote mapya, uthibitishaji wa ziada umepachikwa kwenye kadi za Nitro. Haiwezekani kuikwepa hata kinadharia. Kwa hivyo, kudanganya rasilimali katika VPC nyingine haitafanya kazi.
Ifuatayo, data inatumwa kwa mashine pepe ambayo imekusudiwa.
Huduma ya uchoraji ramani pia inafanya kazi kama kipanga njia cha kimantiki cha kuhamisha data kati ya mashine pepe katika nyavu tofauti. Kila kitu ni rahisi kimawazo, sitaenda kwa undani.
Inabadilika kuwa wakati wa kusambaza kila pakiti, seva hugeuka kwenye huduma ya ramani. Jinsi ya kukabiliana na ucheleweshaji usioepukika? Kuhifadhi akiba, bila shaka.
Uzuri ni kwamba hauitaji kuweka akiba ya meza nzima kubwa. Seva halisi hupangisha mashine pepe kutoka kwa idadi ndogo ya VPC. Unahitaji tu kuweka akiba habari kuhusu VPC hizi. Kuhamisha data kwa VPC zingine katika usanidi wa "chaguo-msingi" bado si halali. Ikiwa utendakazi kama vile uchunguzi wa VPC unatumiwa, basi taarifa kuhusu VPC zinazolingana hupakiwa kwenye kache.
Tulipanga uhamishaji wa data kwa VPC.
Blackfoot
Nini cha kufanya katika hali ambapo trafiki inahitaji kupitishwa nje, kwa mfano kwenye Mtandao au kupitia VPN hadi chini? Inatusaidia hapa Blackfoot - huduma ya ndani ya AWS. Inatengenezwa na timu yetu ya Afrika Kusini. Ndiyo maana huduma hiyo imepewa jina la pengwini anayeishi Afrika Kusini.
Blackfoot hupunguza trafiki na hufanya kile kinachohitajika nayo. Data inatumwa kwa Mtandao kama ilivyo.
Data hukatwa kichwa na kufungwa tena katika IPsec unapotumia VPN.
Unapotumia Direct Connect, trafiki huwekwa alama na kutumwa kwa VLAN inayofaa.
HyperPlane
Hii ni huduma ya udhibiti wa mtiririko wa ndani. Huduma nyingi za mtandao zinahitaji ufuatiliaji hali ya mtiririko wa data. Kwa mfano, unapotumia NAT, udhibiti wa mtiririko lazima uhakikishe kwamba kila IP:jozi ya bandari lengwa ina mlango wa kipekee unaotoka. Katika kesi ya kusawazisha NLB - Kisawazisha cha Mizigo ya Mtandao, mtiririko wa data unapaswa kuelekezwa kwa mashine inayolengwa kila wakati. Vikundi vya Usalama ni ngome ya serikali. Inafuatilia trafiki inayoingia na kufungua bandari kwa mtiririko wa pakiti zinazotoka.
Katika wingu la AWS, mahitaji ya muda wa uwasilishaji ni ya juu sana. Ndiyo maana HyperPlane muhimu kwa utendaji wa mtandao mzima.
Hyperplane imeundwa kwenye mashine pepe za EC2. Hakuna uchawi hapa, ni ujanja tu. Ujanja ni kwamba hizi ni mashine za kawaida zilizo na RAM kubwa. Uendeshaji ni wa shughuli na hufanywa kwa kumbukumbu pekee. Hii inakuwezesha kufikia ucheleweshaji wa makumi ya microseconds tu. Kufanya kazi na diski kunaweza kuua tija yote.
Hyperplane ni mfumo uliosambazwa wa idadi kubwa ya mashine kama hizo za EC2. Kila mashine pepe ina kipimo data cha GB 5/s. Katika mtandao mzima wa kikanda, hii hutoa terabiti za ajabu za kipimo data na inaruhusu usindikaji mamilioni ya viunganisho kwa sekunde.
HyperPlane inafanya kazi na mitiririko pekee. Ufungaji wa pakiti za VPC ni wazi kabisa kwake. Athari inayoweza kutokea katika huduma hii ya ndani bado inaweza kuzuia utengaji wa VPC usivunjwe. Viwango vilivyo hapa chini vinawajibika kwa usalama.
Jirani mwenye kelele
Bado kuna tatizo jirani mwenye kelele - jirani mwenye kelele. Wacha tufikirie kuwa tuna nodi 8. Nodi hizi huchakata mtiririko wa watumiaji wote wa wingu. Kila kitu kinaonekana kuwa sawa na mzigo unapaswa kusambazwa sawasawa katika nodi zote. Nodes ni nguvu sana na ni vigumu kuzipakia.
Lakini tunaunda usanifu wetu kulingana na hali zisizowezekana.
Uwezekano mdogo haimaanishi kuwa haiwezekani.
Tunaweza kufikiria hali ambayo mtumiaji mmoja au zaidi angetoa mzigo mwingi. Nodi zote za HyperPlane zinahusika katika kuchakata mzigo huu na watumiaji wengine wanaweza kupata aina fulani ya utendakazi. Hii inavunja dhana ya wingu, ambayo wapangaji hawana uwezo wa kushawishi kila mmoja.
Jinsi ya kutatua tatizo la jirani mwenye kelele? Jambo la kwanza linalokuja akilini ni kugawanyika. Nodi zetu 8 zimegawanywa kimantiki katika shards 4 za nodi 2 kila moja. Sasa jirani mwenye kelele atasumbua robo tu ya watumiaji wote, lakini itawasumbua sana.
Hebu tufanye mambo tofauti. Tutatenga nodi 3 tu kwa kila mtumiaji.
Ujanja ni kugawa nodi kwa nasibu kwa watumiaji tofauti. Katika picha hapa chini, mtumiaji wa bluu huingilia nodes na mmoja wa watumiaji wengine wawili - kijani na machungwa.
Na nodi 8 na watumiaji 3, uwezekano wa jirani mwenye kelele kuingiliana na mmoja wa watumiaji ni 54%. Ni kwa uwezekano huu ambapo mtumiaji wa bluu ataathiri wapangaji wengine. Wakati huo huo, sehemu tu ya mzigo wake. Katika mfano wetu, ushawishi huu utaonekana angalau kwa namna fulani si kwa kila mtu, lakini kwa theluthi moja tu ya watumiaji wote. Hii tayari ni matokeo mazuri.
Idadi ya watumiaji ambao watapita
Uwezekano katika asilimia
0
18%
1
54%
2
26%
3
2%
Wacha tulete hali hiyo karibu na ukweli - wacha tuchukue nodi 100 na watumiaji 5 kwenye nodi 5. Katika kesi hii, hakuna nodes itaingiliana na uwezekano wa 77%.
Idadi ya watumiaji ambao watapita
Uwezekano katika asilimia
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Katika hali halisi, na idadi kubwa ya nodi za HyperPlane na watumiaji, athari inayowezekana ya jirani mwenye kelele kwa watumiaji wengine ni ndogo. Njia hii inaitwa kuchanganya sharding - shuffle sharding. Inapunguza athari mbaya ya kushindwa kwa nodi.
Huduma nyingi zimejengwa kwa misingi ya HyperPlane: Mizani ya Mzigo wa Mtandao, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Kiwango cha mtandao
Sasa hebu tuzungumze juu ya ukubwa wa mtandao yenyewe. Kwa Oktoba 2019 AWS inatoa huduma zake katika Mikoa 22, na 9 zaidi zimepangwa.
- Kila eneo lina Kanda kadhaa za Upatikanaji. Kuna 69 kati yao kote ulimwenguni.
- Kila AZ ina Vituo vya Kuchakata Data. Hakuna zaidi ya 8 kati yao kwa jumla.
- Kituo cha data kina idadi kubwa ya seva, zingine na hadi 300.
Sasa hebu tufanye wastani haya yote, tuzidishe na kupata takwimu ya kuvutia inayoonyesha Kiwango cha wingu cha Amazon.
Kuna viungo vingi vya macho kati ya Maeneo ya Upatikanaji na kituo cha data. Katika mojawapo ya mikoa yetu kubwa, chaneli 388 zimewekwa kwa ajili ya mawasiliano ya AZ kati ya kila mmoja na mwingine na vituo vya mawasiliano na mikoa mingine (Vituo vya Usafiri). Kwa jumla hii inatoa mambo 5000 Tbit.
AWS ya Uti wa mgongo imeundwa mahususi kwa ajili ya wingu na kuboreshwa. Tunaijenga kwenye chaneli 100 GB / s. Tunazidhibiti kabisa, isipokuwa mikoa nchini Uchina. Trafiki haishirikiwi na mizigo ya makampuni mengine.
Bila shaka, sisi sio tu mtoaji wa wingu na mtandao wa mgongo wa kibinafsi. Makampuni makubwa zaidi na zaidi yanafuata njia hii. Hii inathibitishwa na watafiti wa kujitegemea, kwa mfano kutoka .
Grafu inaonyesha kwamba sehemu ya watoa huduma wa maudhui na watoa huduma za wingu inakua. Kwa sababu hii, sehemu ya trafiki ya mtandao ya watoa huduma wa uti wa mgongo inapungua kila mara.
Nitaelezea kwa nini hii inatokea. Hapo awali, huduma nyingi za wavuti zilipatikana na kutumiwa moja kwa moja kutoka kwa Mtandao. Siku hizi, seva zaidi na zaidi ziko kwenye wingu na zinapatikana kupitia CDN - Mtandao wa Usambazaji wa Maudhui. Ili kupata rasilimali, mtumiaji hupitia Mtandao tu kwa CDN PoP ya karibu - Point ya Uwepo. Mara nyingi ni mahali fulani karibu. Kisha huacha Mtandao wa umma na kuruka kupitia uti wa mgongo wa kibinafsi kuvuka Atlantiki, kwa mfano, na kufika moja kwa moja kwenye rasilimali.
Ninashangaa jinsi mtandao utabadilika katika miaka 10 ikiwa hali hii itaendelea?
Njia za kimwili
Wanasayansi bado hawajafikiria jinsi ya kuongeza kasi ya mwanga katika Ulimwengu, lakini wamepata maendeleo makubwa katika njia za kuisambaza kupitia nyuzi za macho. Kwa sasa tunatumia nyaya 6912 za nyuzi. Hii inasaidia kwa kiasi kikubwa kuongeza gharama ya ufungaji wao.
Katika baadhi ya mikoa tunapaswa kutumia nyaya maalum. Kwa mfano, katika mkoa wa Sydney tunatumia nyaya na mipako maalum ya kupambana na mchwa.
Hakuna mtu aliye salama kutokana na matatizo na wakati mwingine njia zetu huharibika. Picha iliyo upande wa kulia inaonyesha nyaya za macho katika mojawapo ya mikoa ya Marekani ambazo zilichanwa na wafanyakazi wa ujenzi. Kutokana na ajali hiyo, pakiti 13 pekee za data zilipotea, jambo ambalo linashangaza. Kwa mara nyingine tena - 13 tu! Mfumo ulibadilishwa moja kwa moja kwa vituo vya chelezo - kiwango kinafanya kazi.
Tulipitia baadhi ya huduma za wingu na teknolojia za Amazon. Natumai kuwa una angalau wazo fulani la ukubwa wa kazi ambazo wahandisi wetu wanapaswa kutatua. Binafsi, ninaona hii inasisimua sana.
Hii ni sehemu ya mwisho ya trilogy kutoka kwa Vasily Pantyukhin kuhusu kifaa cha AWS. KATIKA sehemu zinaelezea uboreshaji wa seva na kuongeza hifadhidata, na ndani - vitendaji visivyo na seva na Firecracker.
Cha mnamo Novemba Vasily Pantyukhin atashiriki maelezo mapya ya kifaa cha Amazon. Yeye kuhusu sababu za kushindwa na muundo wa mifumo iliyosambazwa huko Amazon. Oktoba 24 bado inawezekana tikiti kwa bei nzuri, na ulipe baadaye. Tunakungoja kwenye HighLoad++, njoo tuzungumze!
Chanzo: mapenzi.com