La skalo de la reto de Amazon Web Services estas 69 zonoj tra la mondo en 22 regionoj: Usono, Eŭropo, Azio, Afriko kaj Aŭstralio. Ĉiu zono enhavas ĝis 8 datumcentrojn - Datumtraktadcentroj. Ĉiu datumcentro havas milojn aŭ centojn da miloj da serviloj. La reto estas dizajnita tiel ke ĉiuj neverŝajnaj malfunkciaj scenaroj estas konsiderataj. Ekzemple, ĉiuj regionoj estas izolitaj unu de la alia, kaj alireblaj zonoj estas apartigitaj laŭ distancoj de pluraj kilometroj. Eĉ se vi tranĉas la kablon, la sistemo ŝanĝos al rezervaj kanaloj, kaj la perdo de informoj sumiĝos al kelkaj datumpakaĵoj. Vasily Pantyukhin parolos pri kiaj aliaj principoj la reto estas konstruita kaj kiel ĝi estas strukturita.
Vasilij Pantyukhin komencis kiel administranto de Unikso en .ru-kompanioj, laboris pri granda Sun Microsystem-aparataro dum 6 jaroj, kaj predikis datumcentran mondon dum 11 jaroj ĉe EMC. Ĝi nature evoluis al privataj nuboj, poste moviĝis al publikaj. Nun, kiel arkitekto de Amazon Web Services, li provizas teknikajn konsilojn por helpi vivi kaj disvolviĝi en la AWS-nubo.
En la antaŭa parto de la AWS-trilogio, Vasily enprofundiĝis en la dezajnon de fizikaj serviloj kaj datumbaza skalo. Nitro-kartoj, kutima KVM-bazita hiperviziero, Amazon Aurora datumbazo - pri ĉio ĉi en la materialo "" Legu por kunteksto aŭ rigardi paroladoj.
Ĉi tiu parto fokusiĝos al reto-skalado, unu el la plej kompleksaj sistemoj en AWS. La evoluo de plata reto al Virtuala Privata Nubo kaj ĝia dezajno, internaj servoj de Blackfoot kaj HyperPlane, la problemo de brua najbaro, kaj fine - la skalo de la reto, spino kaj fizikaj kabloj. Pri ĉio ĉi sub la tranĉo.
Malgarantio: ĉio ĉi sube estas la persona opinio de Vasily kaj eble ne koincidas kun la pozicio de Amazon Web Services.
Reto-skalado
La AWS-nubo estis lanĉita en 2006. Lia reto estis sufiĉe primitiva - kun plata strukturo. La gamo da privataj adresoj estis komuna al ĉiuj nubaj luantoj. Ekfunkciigante novan virtualan maŝinon, vi hazarde ricevis disponeblan IP-adreson de ĉi tiu gamo.
Ĉi tiu aliro estis facile efektivigebla, sed esence limigis la uzon de la nubo. Precipe, estis sufiĉe malfacile evoluigi hibridajn solvojn, kiuj kombinis privatajn retojn surloke kaj en AWS. La plej ofta problemo estis interkovrado de IP-adresintervaloj.
Virtuala Privata Nubo
La nubo montriĝis postulata. Venis la tempo pensi pri skaleblo kaj la ebleco de ĝia uzo de dekoj da milionoj da luantoj. La plata reto fariĝis grava obstaklo. Tial ni pensis pri kiel izoli uzantojn unu de la alia ĉe la retonivelo por ke ili povu sendepende elekti IP-intervalojn.
Kio estas la unua afero, kiu venas al la menso, kiam vi pensas pri retizolado? Certe VLANO и VRF - Virtuala Vokado kaj Plusendado.
Bedaŭrinde, ĝi ne funkciis. VLAN ID estas nur 12 bitoj, kio donas al ni nur 4096 izolitajn segmentojn. Eĉ la plej grandaj ŝaltiloj povas uzi maksimume 1-2 mil VRF-ojn. Uzado de VRF kaj VLAN kune donas al ni nur kelkajn milionojn da subretoj. Ĉi tio certe ne sufiĉas por dekoj da milionoj da luantoj, ĉiu el kiuj devas povi uzi plurajn subretojn.
Ni ankaŭ simple ne povas pagi aĉeti la bezonatan nombron da grandaj skatoloj, ekzemple, de Cisco aŭ Juniper. Estas du kialoj: ĝi estas freneze multekosta, kaj ni ne volas esti je la merdo de iliaj disvolvaj kaj flikaj politikoj.
Estas nur unu konkludo - faru vian propran solvon.
En 2009 ni anoncis VPC - Virtuala Privata Nubo. La nomo restis kaj nun multaj nubaj provizantoj ankaŭ uzas ĝin.
VPC estas virtuala reto SDN (Programaro Difinita Reto). Ni decidis ne inventi specialajn protokolojn ĉe la niveloj L2 kaj L3. La reto funkcias per norma Ethernet kaj IP. Por transsendo tra la reto, virtuala maŝina trafiko estas enkapsuligita en nia propra protokola envolvaĵo. Ĝi indikas la ID kiu apartenas al la VPC de la luanto.
Sonas simple. Tamen, estas pluraj gravaj teknikaj defioj, kiuj devas esti venkitaj. Ekzemple, kie kaj kiel konservi datumojn pri mapado de virtualaj MAC/IP-adresoj, VPC-ID kaj responda fizika MAC/IP. Sur AWS-skalo, ĉi tio estas grandega tablo, kiu devus funkcii kun minimumaj alirprokrastoj. Respondeca pri tio mapa servo, kiu estas disvastigita en maldika tavolo tra la reto.
En novageneraciaj maŝinoj, enkapsuligo estas farita per Nitro-kartoj sur la hardvarnivelo. En pli malnovaj kazoj, enkapsuligo kaj senkapsuligo estas softvar-bazitaj.
Ni eltrovu kiel ĝi funkcias ĝenerale. Ni komencu per la L2-nivelo. Ni supozu, ke ni havas virtualan maŝinon kun IP 10.0.0.2 sur fizika servilo 192.168.0.3. Ĝi sendas datumojn al virtuala maŝino 10.0.0.3, kiu vivas sur 192.168.1.4. ARP-peto estas generita kaj sendita al la reto Nitro-karto. Por simpleco, ni supozas, ke ambaŭ virtualaj maŝinoj vivas en la sama "blua" VPC.
La mapo anstataŭigas la fontadreson kun sia propra kaj plusendas la ARP-kadron al la mapa servo.
La mapa servo resendas informojn, kiuj estas necesaj por dissendo tra la fizika reto L2.
La Nitro-karto en la ARP-respondo anstataŭigas la MAC sur la fizika reto kun adreso en la VPC.
Dum transdono de datumoj, ni envolvas logikan MAC kaj IP en VPC-envolvilon. Ni transdonas ĉion ĉi tra la fizika reto uzante la taŭgajn fontajn kaj celajn IP Nitro-kartojn.
La fizika maŝino al kiu la pakaĵo estas destinita faras la kontrolon. Ĉi tio estas necesa por malhelpi la eblecon de adresfalsado. La maŝino sendas specialan peton al la mapa servo kaj demandas: “De fizika maŝino 192.168.0.3 mi ricevis paketon, kiu estas destinita por 10.0.0.3 en la blua VPC. Ĉu li estas legitima?
La mapa servo kontrolas sian rimedan asignotabelon kaj permesas aŭ neas la pakaĵeton trapasi. En ĉiuj novaj kazoj, kroma validumado estas enigita en Nitro-kartojn. Estas neeble preteriri ĝin eĉ teorie. Tial, parodiado al rimedoj en alia VPC ne funkcios.
Poste, la datumoj estas senditaj al la virtuala maŝino por kiu ĝi estas celita.
La mapa servo ankaŭ funkcias kiel logika enkursigilo por transdoni datumojn inter virtualaj maŝinoj en malsamaj subretoj. Ĉio estas koncepte simpla, mi ne eniros en detalojn.
Montriĝas, ke dum transdono de ĉiu pako, la serviloj turnas sin al la mapa servo. Kiel trakti neeviteblajn malfruojn? Kaŝmemoro, Kompreneble.
La beleco estas, ke vi ne bezonas konservi la tutan grandegan tablon. Fizika servilo gastigas virtualajn maŝinojn de relative malgranda nombro da VPCoj. Vi nur bezonas konservi informojn pri ĉi tiuj VPC-oj. Transdoni datumojn al aliaj VPC-oj en la "defaŭlta" agordo ankoraŭ ne estas legitima. Se funkcieco kiel ekzemple VPC-peering estas uzata, tiam informoj pri la respondaj VPC-oj estas aldone ŝargitaj en la kaŝmemoron.
Ni ordigis la translokigon de datumoj al la VPC.
Nigrapiedo
Kion fari en kazoj kie trafiko devas esti elsendita ekstere, ekzemple al la Interreto aŭ per VPN al la grundo? Helpas nin ĉi tie Nigrapiedo — AWS interna servo. Ĝi estas evoluigita de nia sudafrika teamo. Tial la servo estas nomita laŭ pingveno kiu loĝas en Sudafriko.
Blackfoot malkapsulas trafikon kaj faras tion, kion necesas per ĝi. Datumoj estas senditaj al Interreto kiel estas.
La datumoj estas senkapsuligitaj kaj reenvolvitaj en IPsec kiam vi uzas VPN.
Kiam vi uzas Rektan Konekton, trafiko estas etikedita kaj sendita al la taŭga VLAN.
HiperEbeno
Ĉi tio estas interna fluo-kontrolservo. Multaj retaj servoj postulas monitoradon statoj de fluo de datumoj. Ekzemple, dum uzado de NAT, fluo-kontrolo devas certigi, ke ĉiu IP:destina haveno paro havas unikan eliran havenon. En la kazo de ekvilibristo NLB - Reta Ŝarĝbalancilo, la datumfluo ĉiam estu direktita al la sama cela virtuala maŝino. Sekurecaj Grupoj estas ŝtata fajroŝirmilo. Ĝi monitoras envenantan trafikon kaj implicite malfermas havenojn por eksiĝinta paka fluo.
En la AWS-nubo, dissendaj latencia postuloj estas ekstreme altaj. Tial HiperEbeno kritika por la agado de la tuta reto.
Hyperplane estas konstruita sur EC2 virtualaj maŝinoj. Ne estas magio ĉi tie, nur ruzo. La lertaĵo estas, ke ĉi tiuj estas virtualaj maŝinoj kun granda RAM. Operacioj estas transakciaj kaj faritaj ekskluzive en memoro. Ĉi tio ebligas al vi atingi prokrastojn de nur dekoj da mikrosekundoj. Labori kun la disko mortigus ĉian produktivecon.
Hyperplane estas distribuita sistemo de grandega nombro da tiaj EC2-maŝinoj. Ĉiu virtuala maŝino havas larĝan bandon de 5 GB/s. Tra la tuta regiona reto, ĉi tio disponigas nekredeblajn terabitojn da bendolarĝo kaj permesas pretigon milionoj da konektoj sekundo.
HyperPlane funkcias nur kun riveretoj. VPC-paka enkapsuligo estas tute travidebla por ĝi. Ebla vundebleco en ĉi tiu interna servo ankoraŭ malhelpus la rompon de la VPC-izolado. La subaj niveloj respondecas pri sekureco.
Brua najbaro
Ankoraŭ estas problemo brua najbaro - brua najbaro. Ni supozu, ke ni havas 8 nodojn. Ĉi tiuj nodoj prilaboras la fluojn de ĉiuj nubaj uzantoj. Ĉio ŝajnas esti bona kaj la ŝarĝo devus esti egale distribuita tra ĉiuj nodoj. Nodoj estas tre potencaj kaj estas malfacile troŝarĝi ilin.
Sed ni konstruas nian arkitekturon surbaze de eĉ neverŝajnaj scenaroj.
Malalta probablo ne signifas neebla.
Ni povas imagi situacion en kiu unu aŭ pluraj uzantoj generus tro da ŝarĝo. Ĉiuj HyperPlane-nodoj estas implikitaj en prilaborado de ĉi tiu ŝarĝo kaj aliaj uzantoj eble povus sperti ian rendimentan sukceson. Ĉi tio rompas la koncepton de la nubo, en kiu luantoj ne havas kapablon influi unu la alian.
Kiel solvi la problemon de brua najbaro? La unua afero, kiu venas al la menso, estas sharding. Niaj 8 nodoj estas logike dividitaj en 4 pecetojn de 2 nodoj ĉiu. Nun brua najbaro ĝenos nur kvaronon de ĉiuj uzantoj, sed ĝi multe ĝenos ilin.
Ni faru aferojn alimaniere. Ni asignos nur 3 nodojn al ĉiu uzanto.
La lertaĵo estas hazarde asigni nodojn al malsamaj uzantoj. En la suba bildo, la blua uzanto intersekcas nodojn kun unu el la aliaj du uzantoj - verda kaj oranĝa.
Kun 8 nodoj kaj 3 uzantoj, la probablo de brua najbaro intersekciĝi kun unu el la uzantoj estas 54%. Estas kun ĉi tiu probableco ke blua uzanto influos aliajn luantojn. Samtempe, nur parto de ĝia ŝarĝo. En nia ekzemplo, ĉi tiu influo estos almenaŭ iel rimarkebla ne por ĉiuj, sed por nur triono de ĉiuj uzantoj. Ĉi tio jam estas bona rezulto.
Nombro de uzantoj kiuj intersekcos
Probableco en procento
0
18%
1
54%
2
26%
3
2%
Ni proksimigu la situacion al la realo - ni prenu 100 nodojn kaj 5 uzantojn sur 5 nodoj. En ĉi tiu kazo, neniu el la nodoj intersekcos kun probableco de 77%.
Nombro de uzantoj kiuj intersekcos
Probableco en procento
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
En reala situacio, kun grandega nombro da HyperPlane-nodoj kaj uzantoj, la ebla efiko de brua najbaro sur aliaj uzantoj estas minimuma. Ĉi tiu metodo nomiĝas miksante sharding - miksi sharding. Ĝi minimumigas la negativan efikon de noda fiasko.
Multaj servoj estas konstruitaj surbaze de HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Reta skalo
Nun ni parolu pri la skalo de la reto mem. Por oktobro 2019 AWS ofertas siajn servojn en 22 regionoj, kaj 9 pli estas planitaj.
- Ĉiu regiono enhavas plurajn Disponeblajn Zonojn. Estas 69 el ili tra la mondo.
- Ĉiu AZ konsistas el Datumtraktado-Centroj. Estas ne pli ol 8 el ili entute.
- La datumcentro enhavas grandegan nombron da serviloj, iuj kun ĝis 300.
Nun ni mezuru ĉion ĉi, multobligu kaj ricevu imponan ciferon, kiu reflektas Amazon-nuba skalo.
Estas multaj optikaj ligoj inter Disponeblaj Zonoj kaj la datumcentro. En unu el niaj plej grandaj regionoj, 388 kanaloj estis starigitaj nur por AZ-komunikado inter si kaj komunikadcentroj kun aliaj regionoj (Transit-Centroj). Entute ĉi tio donas frenezon 5000 Tbit.
Backbone AWS estas konstruita specife por kaj optimumigita por la nubo. Ni konstruas ĝin sur la kanaloj 100 GB / s. Ni regas ilin tute, escepte de regionoj en Ĉinio. Trafiko ne estas dividita kun la ŝarĝoj de aliaj kompanioj.
Kompreneble, ni ne estas la sola nuba provizanto kun privata spina reto. Pli kaj pli da grandaj kompanioj sekvas ĉi tiun vojon. Ĉi tio estas konfirmita de sendependaj esploristoj, ekzemple de .
La grafikaĵo montras, ke la proporcio de enhavaj provizantoj kaj nubaj provizantoj kreskas. Pro tio, la parto de interreta trafiko de spinaj provizantoj konstante malpliiĝas.
Mi klarigos kial tio okazas. Antaŭe, la plej multaj retservoj estis alireblaj kaj konsumitaj rekte de la Interreto. Nuntempe, pli kaj pli da serviloj situas en la nubo kaj estas alireblaj pere CDN - Enhava Distribua Reto. Por aliri rimedon, la uzanto iras tra la Interreto nur al la plej proksima CDN PoP - Punkto de Ĉeesto. Plej ofte ĝi estas ie proksime. Tiam ĝi forlasas la publikan Interreton kaj flugas tra privata spino trans Atlantikon, ekzemple, kaj atingas rekte la rimedon.
Mi scivolas kiel la Interreto ŝanĝos en 10 jaroj se ĉi tiu tendenco daŭras?
Fizikaj kanaloj
Sciencistoj ankoraŭ ne eltrovis kiel pliigi la lumrapidecon en la Universo, sed ili faris grandan progreson en metodoj de transdoni ĝin per optika fibro. Nuntempe ni uzas 6912 fibrajn kablojn. Ĉi tio helpas signife optimumigi la koston de ilia instalado.
En iuj regionoj ni devas uzi specialajn kablojn. Ekzemple, en la Sidneja regiono ni uzas kablojn kun speciala tegaĵo kontraŭ termitoj.
Neniu estas imuna de problemoj kaj foje niaj kanaloj estas difektitaj. La foto dekstre montras optikajn kablojn en unu el la usonaj regionoj, kiuj estis disŝiritaj de konstrulaboristoj. Sekve de la akcidento, nur 13 datumpakaĵoj estis perditaj, kio estas surpriza. Denove - nur 13! La sistemo laŭvorte tuj ŝanĝis al rezervaj kanaloj - la skalo funkcias.
Ni galopis tra iuj el la nubaj servoj kaj teknologioj de Amazon. Mi esperas, ke vi havas almenaŭ ian ideon pri la skalo de la taskoj, kiujn niaj inĝenieroj devas solvi. Persone, mi trovas ĉi tion tre ekscita.
Ĉi tiu estas la fina parto de la trilogio de Vasily Pantyukhin pri la AWS-aparato. EN partoj priskribas servilan optimumigon kaj datumbazan skalon, kaj en — senservilaj funkcioj kaj Fajrokraĉulo.
En en novembro Vasily Pantyukhin dividos novajn detalojn pri la Amazon-aparato. Li pri la kaŭzoj de fiaskoj kaj la dezajno de distribuitaj sistemoj ĉe Amazon. La 24-an de oktobro ankoraŭ eblas bileton je bona prezo, kaj pagu poste. Ni atendas vin ĉe HighLoad++, venu kaj ni babilu!
fonto: www.habr.com