Amazon Web Services -verkoston laajuus on 69 vyöhykettä ympäri maailmaa 22 alueella: Yhdysvalloissa, Euroopassa, Aasiassa, Afrikassa ja Australiassa. Jokainen vyöhyke sisältää enintään 8 datakeskusta - Data Processing Centers. Jokaisessa palvelinkeskuksessa on tuhansia tai satoja tuhansia palvelimia. Verkko on suunniteltu siten, että kaikki epätodennäköiset katkoskenaariot otetaan huomioon. Esimerkiksi kaikki alueet ovat eristettyjä toisistaan ja saavutettavuusvyöhykkeet on erotettu useiden kilometrien etäisyyksiltä. Vaikka katkaisisit kaapelin, järjestelmä siirtyy varakanaville ja tietojen menetys on muutama datapaketti. Vasily Pantyukhin kertoo, mille muille periaatteille verkosto on rakennettu ja miten se rakentuu.
Vasily Pantyukhin aloitti Unix-järjestelmänvalvojana .ru-yrityksissä, työskenteli suurten Sun Microsystem -laitteistojen parissa 6 vuotta ja saarnasi datakeskeistä maailmaa 11 vuotta EMC:ssä. Se kehittyi luonnollisesti yksityisiksi pilviksi ja siirtyi sitten julkisiin pilviin. Nyt Amazon Web Services -arkkitehtina hän tarjoaa teknisiä neuvoja, jotka auttavat elämään ja kehittymään AWS-pilvessä.
AWS-trilogian edellisessä osassa Vasily syventyi fyysisten palvelimien suunnitteluun ja tietokannan skaalaukseen. Nitro-kortit, mukautettu KVM-pohjainen hypervisor, Amazon Aurora -tietokanta - kaikesta tästä materiaalissa "" Lue konteksti tai katso puheita.
Tämä osa keskittyy verkon skaalaukseen, joka on yksi AWS:n monimutkaisimmista järjestelmistä. Evoluutio tasaisesta verkosta Virtual Private Cloudiin ja sen suunnittelu, Blackfootin ja HyperPlanen sisäiset palvelut, meluisan naapurin ongelma ja lopussa - verkon, rungon ja fyysisten kaapelien mittakaava. Kaikesta tästä leikkauksen alla.
Vastuuvapauslauseke: kaikki alla on Vasilyn henkilökohtaista mielipidettä, eikä se välttämättä vastaa Amazon Web Services -palvelua.
Verkon skaalaus
AWS-pilvi lanseerattiin vuonna 2006. Hänen verkostonsa oli melko alkeellista - litteällä rakenteella. Yksityisten osoitteiden valikoima oli yhteinen kaikille pilvivuokralaisille. Kun käynnistät uuden virtuaalikoneen, sait vahingossa käytettävissä olevan IP-osoitteen tältä alueelta.
Tämä lähestymistapa oli helppo toteuttaa, mutta rajoitti olennaisesti pilven käyttöä. Erityisesti oli melko vaikeaa kehittää hybridiratkaisuja, jotka yhdistäisivät yksityisiä verkkoja paikan päällä ja AWS:ssä. Yleisin ongelma oli päällekkäiset IP-osoitealueet.
Virtuaali yksityinen pilvi
Pilvi osoittautui kysytyksi. On tullut aika miettiä skaalautuvuutta ja sen mahdollisuutta käyttää kymmeniä miljoonia vuokralaisia. Tasaisesta verkosta on tullut suuri este. Siksi pohdimme, kuinka eristää käyttäjät toisistaan verkkotasolla, jotta he voisivat itsenäisesti valita IP-alueet.
Mikä tulee ensimmäisenä mieleen, kun ajattelet verkon eristämistä? Varmasti VLAN и VRF - Virtuaalinen reititys ja edelleenlähetys.
Valitettavasti se ei toiminut. VLAN ID on vain 12 bittiä, mikä antaa meille vain 4096 eristettyä segmenttiä. Jopa suurimmat kytkimet voivat käyttää enintään 1-2 tuhatta VRF:ää. VRF:n ja VLAN:n käyttö yhdessä antaa meille vain muutaman miljoonan aliverkon. Tämä ei todellakaan riitä kymmenille miljoonille vuokralaisille, joista jokaisen on voitava käyttää useita aliverkkoja.
Meillä ei myöskään yksinkertaisesti ole varaa ostaa tarvittavaa määrää suuria laatikoita esimerkiksi Ciscosta tai Juniperista. Syitä on kaksi: se on hullun kallista, emmekä halua olla heidän kehitys- ja korjauspolitiikan armoilla.
On vain yksi johtopäätös - tee oma ratkaisusi.
Vuonna 2009 julkistimme VPC - Virtuaali yksityinen pilvi. Nimi jäi kiinni, ja nyt monet pilvipalveluntarjoajat käyttävät sitä myös.
VPC on virtuaalinen verkko SDN (Ohjelmiston määrittämä verkko). Päätimme olla keksimättä erityisiä protokollia L2- ja L3-tasoilla. Verkko toimii tavallisella Ethernetillä ja IP:llä. Verkon yli tapahtuvaa lähetystä varten virtuaalikoneen liikenne kapseloidaan omaan protokollakääreeseen. Se osoittaa tunnuksen, joka kuuluu vuokralaisen VPC:hen.
Kuulostaa yksinkertaiselta. On kuitenkin olemassa useita vakavia teknisiä haasteita, jotka on voitettava. Esimerkiksi missä ja miten tallennetaan tietoja virtuaalisten MAC/IP-osoitteiden kartoittamisesta, VPC ID ja vastaava fyysinen MAC/IP. AWS-mittakaavassa tämä on valtava taulukko, jonka pitäisi toimia minimaalisilla pääsyviiveillä. Tästä vastuussa karttapalvelu, joka leviää ohuena kerroksena koko verkkoon.
Uuden sukupolven koneissa kapselointi suoritetaan Nitro-korteilla laitteistotasolla. Vanhemmissa tapauksissa kapselointi ja kapselin purkaminen ovat ohjelmistopohjaisia.
Selvitetään, miten se toimii yleisesti. Aloitetaan L2-tasosta. Oletetaan, että meillä on virtuaalikone, jonka IP-osoite on 10.0.0.2 fyysisellä palvelimella 192.168.0.3. Se lähettää tietoja virtuaalikoneen 10.0.0.3, joka elää 192.168.1.4. ARP-pyyntö luodaan ja lähetetään verkon Nitro-korttiin. Yksinkertaisuuden vuoksi oletamme, että molemmat virtuaalikoneet asuvat samassa "sinisessä" VPC:ssä.
Kartta korvaa lähdeosoitteen omalla osoitteellaan ja välittää ARP-kehyksen kartoituspalveluun.
Kartoituspalvelu palauttaa tiedot, jotka ovat välttämättömiä fyysisen L2-verkon kautta tapahtuvaa siirtoa varten.
Nitro-kortti ARP-vastauksessa korvaa fyysisen verkon MAC:n osoitteella VPC:ssä.
Dataa siirrettäessä käärimme loogisen MAC:n ja IP:n VPC-kääreeseen. Välitämme kaiken tämän fyysisen verkon kautta käyttämällä sopivia lähde- ja kohde IP Nitro -kortteja.
Fyysinen kone, jolle paketti on tarkoitettu, suorittaa tarkistuksen. Tämä on tarpeen osoitehuijauksen mahdollisuuden estämiseksi. Kone lähettää erikoispyynnön kartoituspalveluun ja kysyy: "Fyysiseltä koneelta 192.168.0.3 sain paketin, joka on tarkoitettu 10.0.0.3:lle sinisessä VPC:ssä. Onko hän laillinen?
Kartoituspalvelu tarkistaa resurssien allokointitaulukkonsa ja sallii tai estää paketin kulkemisen. Kaikissa uusissa tapauksissa lisävarmennus on upotettu Nitro-kortteihin. Sitä on mahdotonta ohittaa edes teoreettisesti. Siksi toisen VPC:n resurssien huijaus ei toimi.
Seuraavaksi tiedot lähetetään virtuaalikoneeseen, jolle ne on tarkoitettu.
Kartoituspalvelu toimii myös loogisena reitittimenä tiedon siirtämiseen eri aliverkoissa olevien virtuaalikoneiden välillä. Kaikki on käsitteellisesti yksinkertaista, en mene yksityiskohtiin.
Osoittautuu, että lähetettäessä jokaista pakettia palvelimet kääntyvät kartoituspalvelun puoleen. Kuinka käsitellä väistämättömiä viivästyksiä? Välimuisti, tietysti.
Kauneus on, että sinun ei tarvitse tallentaa välimuistiin koko valtavaa pöytää. Fyysinen palvelin isännöi virtuaalikoneita suhteellisen pienestä määrästä VPC:itä. Sinun tarvitsee vain tallentaa näiden VPC:iden tiedot välimuistiin. Tietojen siirtäminen muille VPC:ille oletuskokoonpanossa ei ole edelleenkään laillista. Jos käytetään toiminnallisuutta, kuten VPC-peering, niin tietoja vastaavista VPC:istä ladataan lisäksi välimuistiin.
Selvitimme tietojen siirron VPC:lle.
Blackfoot
Mitä tehdä tapauksissa, joissa liikenne on välitettävä ulkopuolelle, esimerkiksi Internetiin tai VPN:n kautta maahan? Auttaa meitä täällä Blackfoot - sisäinen AWS-palvelu. Sen on kehittänyt eteläafrikkalainen tiimimme. Siksi palvelu on nimetty Etelä-Afrikassa asuvan pingviinin mukaan.
Blackfoot purkaa liikenteen ja tekee sen kanssa mitä tarvitaan. Tiedot lähetetään Internetiin sellaisenaan.
Data puretaan ja kääritään uudelleen IPsec-muotoon VPN:ää käytettäessä.
Direct Connectia käytettäessä liikenne merkitään ja lähetetään sopivaan VLANiin.
HyperPlane
Tämä on sisäinen virtauksenohjauspalvelu. Monet verkkopalvelut vaativat valvontaa tiedonkulun tilat. Esimerkiksi NAT:ia käytettäessä vuonhallinnan on varmistettava, että jokaisella IP:kohdeporttiparilla on yksilöllinen lähtevä portti. Tasapainottimen tapauksessa NLB - Network Load Balancer, tietovirta tulee aina ohjata samaan virtuaalikoneeseen. Security Groups on tilallinen palomuuri. Se tarkkailee saapuvaa liikennettä ja avaa implisiittisesti portit lähteville pakettivirralle.
AWS-pilvessä lähetysviivevaatimukset ovat erittäin korkeat. Siksi HyperPlane kriittinen koko verkon suorituskyvyn kannalta.
Hyperplane on rakennettu EC2-virtuaalikoneille. Täällä ei ole taikuutta, vain viekkautta. Temppu on, että nämä ovat virtuaalikoneita, joissa on suuri RAM. Toiminnot ovat tapahtumia ja ne suoritetaan yksinomaan muistissa. Näin voit saavuttaa vain kymmenien mikrosekuntien viiveitä. Levyn kanssa työskentely tappaisi kaiken tuottavuuden.
Hyperplane on hajautettu järjestelmä, jossa on valtava määrä tällaisia EC2-koneita. Jokaisen virtuaalikoneen kaistanleveys on 5 Gt/s. Koko alueverkossa tämä tarjoaa uskomattoman terabitin kaistanleveyden ja mahdollistaa käsittelyn miljoonia yhteyksiä sekunnissa.
HyperPlane toimii vain streamien kanssa. VPC-pakettien kapselointi on sille täysin läpinäkyvä. Tämän sisäisen palvelun mahdollinen haavoittuvuus estäisi silti VPC-eristyksen rikkoutumisen. Alla olevat tasot vastaavat turvallisuudesta.
Meluisa naapuri
On edelleen ongelma meluisa naapuri - meluisa naapuri. Oletetaan, että meillä on 8 solmua. Nämä solmut käsittelevät kaikkien pilvikäyttäjien virtoja. Kaikki näyttää olevan kunnossa ja kuorman tulisi jakautua tasaisesti kaikkien solmujen kesken. Solmut ovat erittäin tehokkaita ja niitä on vaikea ylikuormittaa.
Mutta rakennamme arkkitehtuurimme jopa epätodennäköisten skenaarioiden perusteella.
Pieni todennäköisyys ei tarkoita mahdotonta.
Voimme kuvitella tilanteen, jossa yksi tai useampi käyttäjä synnyttäisi liikaa kuormaa. Kaikki HyperPlane-solmut ovat mukana tämän kuorman käsittelyssä, ja muut käyttäjät voivat kokea jonkinlaisen suorituskyvyn häiriön. Tämä rikkoo pilven käsitteen, jossa vuokralaisilla ei ole kykyä vaikuttaa toisiinsa.
Kuinka ratkaista meluisan naapurin ongelma? Ensimmäinen asia, joka tulee mieleen, on sirpalointi. 8 solmuamme on loogisesti jaettu 4 sirpaleeseen, joissa kussakin on 2 solmua. Nyt meluisa naapuri häiritsee vain neljännestä käyttäjistä, mutta häiritsee heitä suuresti.
Tehdään asiat toisin. Varaamme kullekin käyttäjälle vain 3 solmua.
Temppu on määrittää satunnaisesti solmut eri käyttäjille. Alla olevassa kuvassa sininen käyttäjä leikkaa solmut toisen käyttäjän kanssa - vihreän ja oranssin.
8 solmulla ja 3 käyttäjällä todennäköisyys, että meluisa naapuri leikkaa yhden käyttäjän kanssa, on 54 %. Tällä todennäköisyydellä sininen käyttäjä vaikuttaa muihin vuokralaisiin. Samaan aikaan vain osa sen kuormasta. Esimerkissämme tämä vaikutus ei ole ainakin jotenkin havaittavissa kaikille, mutta vain kolmannekselle käyttäjistä. Tämä on jo hyvä tulos.
Leikkaavien käyttäjien määrä
Todennäköisyys prosentteina
0
18%
1
54%
2
26%
3
2%
Viedään tilanne lähemmäs todellisuutta - otetaan 100 solmua ja 5 käyttäjää 5 solmussa. Tässä tapauksessa mikään solmuista ei leikkaa todennäköisyydellä 77%.
Leikkaavien käyttäjien määrä
Todennäköisyys prosentteina
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Todellisessa tilanteessa, jossa on valtava määrä HyperPlane-solmuja ja käyttäjiä, meluisan naapurin mahdollinen vaikutus muihin käyttäjiin on minimaalinen. Tätä menetelmää kutsutaan sekoittamalla sirpaleita - shuffle sharding. Se minimoi solmuhäiriön negatiivisen vaikutuksen.
Monet palvelut on rakennettu HyperPlanen pohjalle: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Verkko mittakaavassa
Puhutaanpa nyt itse verkon laajuudesta. Lokakuulle 2019 AWS tarjoaa palvelujaan 22 aluetta, ja 9 muuta on suunnitteilla.
- Jokaisella alueella on useita saatavuusvyöhykkeitä. Niitä on 69 eri puolilla maailmaa.
- Jokainen AZ koostuu tietojenkäsittelykeskuksista. Niitä on yhteensä enintään 8.
- Palvelinkeskuksessa on valtava määrä palvelimia, joissakin jopa 300 000.
Lasketaan nyt tämän kaiken keskiarvo, kerrotaan ja saadaan vaikuttava luku, joka heijastaa Amazonin pilvimittakaava.
Saatavuusvyöhykkeiden ja datakeskuksen välillä on monia optisia linkkejä. Yhdelle suurimmista alueistamme on rakennettu 388 kanavaa vain AZ-viestintään toistensa ja muiden alueiden kanssa olevien viestintäkeskusten (Transit Centers) välillä. Kaiken kaikkiaan tämä tekee hulluksi 5000 Tbit.
Backbone AWS on suunniteltu erityisesti pilvelle ja optimoitu sitä varten. Rakennamme sen kanaville 100 Gt / s. Hallitsemme niitä täysin Kiinan alueita lukuun ottamatta. Liikennettä ei jaeta muiden yritysten kuormien kanssa.
Emme tietenkään ole ainoa pilvipalveluntarjoaja, jolla on yksityinen runkoverkko. Yhä useammat suuret yritykset seuraavat tätä tietä. Tämän ovat vahvistaneet riippumattomat tutkijat, esimerkiksi vuodesta .
Kaaviosta näkyy, että sisällöntuottajien ja pilvipalvelujen tarjoajien osuus on kasvussa. Tästä johtuen runkoverkkopalveluntarjoajien Internet-liikenteen osuus pienenee jatkuvasti.
Selitän miksi näin tapahtuu. Aikaisemmin useimmat verkkopalvelut olivat saatavilla ja niitä käytettiin suoraan Internetistä. Nykyään yhä useammat palvelimet sijaitsevat pilvessä ja ovat käytettävissä sen kautta CDN - Sisällönjakeluverkosto. Päästäkseen resurssiin käyttäjä menee Internetin kautta vain lähimpään CDN PoP -pisteeseen - Läsnäolopiste. Useimmiten se on jossain lähellä. Sitten se poistuu julkisesta Internetistä ja lentää yksityisen runkoverkon kautta esimerkiksi Atlantin yli ja pääsee suoraan resurssiin.
Ihmettelen kuinka Internet muuttuu 10 vuodessa, jos tämä trendi jatkuu?
Fyysiset kanavat
Tiedemiehet eivät ole vielä keksineet, kuinka lisätä valon nopeutta universumissa, mutta he ovat edistyneet suuresti menetelmissä, joilla se lähetetään valokuidun kautta. Käytämme tällä hetkellä 6912 kuitukaapeleita. Tämä auttaa merkittävästi optimoimaan niiden asennuskustannukset.
Joillakin alueilla meidän on käytettävä erikoiskaapeleita. Esimerkiksi Sydneyn alueella käytämme kaapeleita, joissa on erityinen pinnoite termiittejä vastaan.
Kukaan ei ole immuuni ongelmille ja joskus kanavamme vaurioituvat. Oikealla olevassa kuvassa on optisia kaapeleita yhdellä Amerikan alueilla, jotka rakennustyöntekijät repivät. Onnettomuuden seurauksena vain 13 datapakettia katosi, mikä on yllättävää. Jälleen kerran - vain 13! Järjestelmä siirtyi kirjaimellisesti välittömästi varakanaviin - vaaka toimii.
Kävelimme läpi joitakin Amazonin pilvipalveluita ja -tekniikoita. Toivon, että sinulla on edes jonkinlainen käsitys insinööriemme ratkaistavien tehtävien laajuudesta. Henkilökohtaisesti pidän tätä erittäin jännittävää.
Tämä on Vasily Pantyukhinin AWS-laitetta käsittelevän trilogian viimeinen osa. SISÄÄN osissa kuvataan palvelimen optimointia ja tietokannan skaalausta ja sisään — palvelimettomat toiminnot ja Firecracker.
Päälle marraskuussa Vasily Pantyukhin jakaa uusia yksityiskohtia Amazon-laitteesta. Hän vikojen syistä ja Amazonin hajautettujen järjestelmien suunnittelusta. 24. lokakuuta on vielä mahdollista lippu hyvällä hinnalla ja maksa myöhemmin. Odotamme sinua HighLoad++:ssa, tule juttelemaan!
Lähde: will.com