Hei, nimeni on Kostya Kramlikh, olen Yandex.Cloudin Virtual Private Cloud -divisioonan johtava kehittäjä. Olen virtuaalinen verkkokäyttäjä, ja kuten arvata saattaa, tässä artikkelissa puhun Virtual Private Cloud (VPC) -laitteesta yleensä ja virtuaaliverkosta erityisesti. Saat myös selville, miksi me palvelun kehittäjät arvostamme käyttäjiemme palautetta. Mutta ensin asiat ensin.
Mikä on VPC?
Nykyään on olemassa useita vaihtoehtoja palvelujen käyttöönottoon. Olen varma, että joku pitää edelleen palvelinta järjestelmänvalvojan pöydän alla, vaikka toivonkin, että tällaisia tarinoita on vähemmän.
Nyt palvelut yrittävät mennä julkisiin pilviin, ja tässä ne törmäävät VPC:ihin. VPC on osa julkista pilvipalvelua, joka yhdistää käyttäjän, infrastruktuurin, alustan ja muut kapasiteetit riippumatta siitä, missä ne ovat, pilvessämme tai sen ulkopuolella. Samalla VPC sallii, että et altista näitä kapasiteettia tarpeettomasti Internetille, ne pysyvät eristetyssä verkossasi.
Miltä virtuaaliverkko näyttää ulkopuolelta?
VPC:llä tarkoitamme ensisijaisesti peittoverkkoa ja verkkopalveluita, kuten VPNaaS, NATaas, LBaas jne. Ja kaikki tämä toimii vikasietoisen verkkoinfrastruktuurin päällä, joka on jo täällä, Habrella.
Katsotaanpa tarkemmin virtuaaliverkkoa ja sen laitetta.
Harkitse kahta käytettävyysaluetta. Tarjoamme virtuaalisen verkon, jota kutsuimme VPC:ksi. Itse asiassa se määrittelee "harmaiden" osoitteiden ainutlaatuisuuden tilan. Jokaisessa virtuaaliverkossa voit hallita täysin osoitetilaa, jonka voit määrittää laskentaresursseille.
Verkosto on maailmanlaajuinen. Samalla se projisoidaan jokaiselle käytettävyysvyöhykkeelle aliverkko-nimisen entiteetin muodossa. Määrität kullekin aliverkolle CIDR:n, jonka koko on 16 tai pienempi. Jokaisella käytettävyysvyöhykkeellä voi olla useampi kuin yksi tällainen entiteetti, ja niiden välillä on aina läpinäkyvä reititys. Tämä tarkoittaa, että kaikki saman VPC:n resurssit voivat "puhua" toisilleen, vaikka ne olisivatkin eri saatavuusvyöhykkeillä. "Kommunikoi" ilman Internet-yhteyttä sisäisten kanavien kautta "ajatellen" olevansa samassa yksityisessä verkossa.
Yllä oleva kaavio näyttää tyypillisen tilanteen: kaksi VPC:tä, jotka leikkaavat jossain osoitteissa. Molemmat voivat olla sinun. Esimerkiksi yksi kehitystä varten, toinen testausta varten. Käyttäjiä voi yksinkertaisesti olla erilaisia - tässä tapauksessa sillä ei ole väliä. Ja yksi virtuaalikone on kytketty kuhunkin VPC:hen.
Tehdään suunnitelmasta huonompi. Voit tehdä sen niin, että yksi virtuaalikone on juuttunut useisiin aliverkkoihin kerralla. Eikä vain niin, vaan erilaisissa virtuaaliverkoissa.
Samanaikaisesti, jos sinun on altistettava koneet Internetiin, tämä voidaan tehdä API:n tai käyttöliittymän kautta. Tätä varten sinun on määritettävä "harmaa" sisäisen osoitteesi NAT-käännös "valkoiseksi" - julkiseksi. Et voi valita "valkoista" osoitetta, se määrätään satunnaisesti osoitevalikoimastamme. Heti kun lopetat ulkoisen IP:n käytön, se palautetaan pooliin. Maksat vain "valkoisen" osoitteen käyttöajasta.
On myös mahdollista antaa koneelle pääsy Internetiin NAT-ilmentymän avulla. Voit reitittää liikennettä esiintymään staattisen reititystaulukon kautta. Olemme tarjonneet tällaisen tapauksen, koska käyttäjät tarvitsevat sitä joskus ja tiedämme siitä. Näin ollen kuvaluettelomme sisältää erityisesti määritetyn NAT-kuvan.
Mutta vaikka valmis NAT-kuva olisi olemassa, asennus voi olla hankalaa. Ymmärsimme, että joillekin käyttäjille tämä ei ole kätevin vaihtoehto, joten lopulta teimme mahdolliseksi ottaa NAT:n käyttöön halutussa aliverkossa yhdellä napsautuksella. Tämä ominaisuus on edelleen suljetussa esikatselussa, jossa sitä testataan yhteisön jäsenten avulla.
Kuinka virtuaaliverkko on järjestetty sisältäpäin
Miten käyttäjä on vuorovaikutuksessa virtuaaliverkon kanssa? Verkko näyttää ulospäin API:nsa ansiosta. Käyttäjä tulee API:lle ja työskentelee kohdetilan kanssa. API:n kautta käyttäjä näkee kuinka kaikki pitäisi järjestää ja konfiguroida, samalla kun hän näkee tilan, kuinka paljon todellinen tila poikkeaa halutusta. Tämä on kuva käyttäjästä. Mitä sisällä tapahtuu?
Kirjoitamme halutun tilan Yandex-tietokantaan ja siirrymme konfiguroimaan VPC:n eri osia. Yandex.Cloudin peittoverkko perustuu valittuihin OpenContrailin osiin, jota äskettäin kutsuttiin nimellä Tungsten Fabric. Verkkopalvelut toteutetaan yhdelle CloudGate-alustalle. CloudGatessa käytimme myös useita avoimen lähdekoodin komponentteja: GoBGP - pääsynhallintatietoihin sekä VPP - ohjelmistoreitittimen toteuttaminen, joka toimii DPDK:n päällä tietopolussa.
Tungsten Fabric kommunikoi CloudGaten kanssa GoBGP:n kautta. Kertoo mitä peittoverkossa tapahtuu. CloudGate puolestaan yhdistää peittoverkot toisiinsa ja Internetiin.
Katsotaan nyt, kuinka virtuaaliverkko ratkaisee skaalaukseen ja saatavuuteen liittyvät ongelmat. Tarkastellaanpa yksinkertaista tapausta. On yksi käytettävyysvyöhyke ja siihen luodaan kaksi VPC:tä. Otimme käyttöön yhden Tungsten Fabric -esiintymän, ja se vetää useita kymmeniä tuhansia verkkoja. Verkot kommunikoivat CloudGaten kanssa. CloudGate, kuten olemme jo sanoneet, varmistaa niiden yhteyden toisiinsa ja Internetiin.
Oletetaan, että toinen käytettävyysvyöhyke on lisätty. Sen pitäisi epäonnistua täysin ensimmäisestä riippumatta. Siksi toiselle käytettävyysalueelle meidän on asennettava erillinen Tungsten Fabric -esiintymä. Tämä on erillinen järjestelmä, joka käsittelee peittokuvaa ja tietää vähän ensimmäisestä järjestelmästä. Ja näkyvyys siitä, että virtuaaliverkkomme on maailmanlaajuinen, luo itse asiassa VPC-sovellusliittymämme. Tämä on hänen tehtävänsä.
VPC1 on kartoitettu saatavuusvyöhykkeelle B, jos saatavuusvyöhykkeellä B on resursseja, jotka on työnnetty VPC1:een. Jos VPC2:lta ei ole resursseja saatavuusvyöhykkeellä B, emme toteuta VPC2:ta tälle vyöhykkeelle. Koska VPC3:n resurssit ovat puolestaan vain vyöhykkeellä B, VPC3:a ei ole vyöhykkeellä A. Kaikki on yksinkertaista ja loogista.
Mennään hieman syvemmälle ja katsotaan kuinka tietty isäntä Y.Cloudissa toimii. Tärkein asia, jonka haluan huomauttaa, on, että kaikki isännät on järjestetty samalla tavalla. Teemme sen niin, että vain tarvittava vähimmäismäärä palveluista toimii laitteistolla, kaikki loput virtuaalikoneilla. Rakennamme perusinfrastruktuuripalveluihin perustuvia korkeamman asteen palveluita ja käytämme Pilviä myös joidenkin suunnitteluongelmien ratkaisemiseen esimerkiksi Continuous Integrationin puitteissa.
Jos tarkastelemme tiettyä isäntäkonetta, voimme nähdä, että isäntäkäyttöjärjestelmässä toimii kolme komponenttia:
- Compute - osa, joka vastaa laskentaresurssien jakamisesta isännässä.
- VRouter on osa Tungsten Fabricia, joka järjestää peiton, eli se tunneloi paketit aluskerroksen läpi.
- VDiskit ovat tallennusvirtualisoinnin paloja.
Lisäksi virtuaalikoneissa lanseerataan palveluita: Pilviinfrastruktuuripalvelut, alustapalvelut ja asiakaskapasiteetit. Asiakaskapasiteetit ja alustapalvelut menevät aina peittoon VRouterin kautta.
Infrastruktuuripalvelut voivat tarttua peittoon, mutta periaatteessa ne haluavat toimia aluskatteessa. Ne kiinnitetään alustaan SR-IOV:n avulla. Itse asiassa leikkasimme kortin virtuaalisiksi verkkokorteiksi (virtuaalitoiminnoiksi) ja työnnämme ne infrastruktuurin virtuaalikoneen, jotta suorituskyky ei heikkene. Esimerkiksi sama CloudGate käynnistetään yhtenä näistä infrastruktuurin virtuaalikoneista.
Nyt kun olemme kuvanneet virtuaaliverkon globaalit tehtävät ja pilven peruskomponenttien rakenteen, katsotaan kuinka tarkalleen virtuaaliverkon eri osat ovat vuorovaikutuksessa keskenään.
Erottelemme järjestelmässämme kolme kerrosta:
- Config Plane - määrittää järjestelmän tavoitetilan. Tämän käyttäjä määrittää API:n kautta.
- Ohjaustaso - tarjoaa käyttäjän määrittämän semantiikan, eli tuo tietotason tilan siihen, mitä käyttäjä on kuvannut konfigurointitasossa.
- Data Plane - käsittelee suoraan käyttäjän paketteja.
Kuten edellä sanoin, kaikki alkaa siitä, että käyttäjä tai sisäinen alustapalvelu tulee API:lle ja kuvaa tietyn kohdetilan.
Tämä tila kirjoitetaan välittömästi Yandex-tietokantaan, se palauttaa asynkronisen toimintotunnuksen API:n kautta ja käynnistää sisäisen koneistomme palauttamaan käyttäjän halutun tilan. Konfigurointitehtävät menevät SDN-ohjaimeen ja kerro Tungsten Fabricille, mitä tehdä peittokuvassa. He esimerkiksi varaavat portteja, virtuaalisia verkkoja ja vastaavia.
Config Plane in Tungsten Fabric lähettää vaaditun tilan ohjaustasolle. Sen kautta Config Plane kommunikoi isäntien kanssa ja kertoo, mitä heissä pian pyörii.
Katsotaan nyt, miltä järjestelmä näyttää isännissä. Virtuaalikoneessa on verkkosovitin kytkettynä VRouteriin. VRouter on ydin Tungsten Fabric -moduuli, joka tarkastelee paketteja. Jos jollekin paketille on jo olemassa vuo, moduuli käsittelee sen. Jos kulkua ei ole, moduuli tekee ns. puntingin eli lähettää paketin usermod-prosessiin. Prosessi jäsentää paketin ja joko vastaa siihen itse, kuten DHCP ja DNS, tai kertoo VRouterille, mitä sille tehdään. Sen jälkeen VRouter voi käsitellä paketin.
Lisäksi virtuaalikoneiden välinen liikenne saman virtuaaliverkon sisällä kulkee läpinäkyvästi, sitä ei ohjata CloudGateen. Isännät, joilla virtuaalikoneita on otettu käyttöön, kommunikoivat suoraan toistensa kanssa. Ne tunneloivat liikennettä ja välittävät sen toisilleen aluskatteen kautta.
Ohjaustasot viestivät toistensa kanssa käytettävyysalueiden välillä BGP:n kautta, kuten toisen reitittimen kanssa. Ne kertovat, mitkä koneet ovat ylhäällä, jotta yhden vyöhykkeen virtuaalikoneet voivat kommunikoida suoraan muiden virtuaalikoneiden kanssa.
Ja Control Plane kommunikoi CloudGaten kanssa. Samoin se raportoi missä ja mitkä virtuaalikoneet nostetaan, mitkä osoitteet niillä on. Tämän avulla voit ohjata ulkoista liikennettä ja liikennettä tasapainottimista niihin.
VPC:stä lähtevä liikenne tulee CloudGateen, datapolulle, jossa VPP liitännäisillämme pureskellaan nopeasti. Sitten liikenne ohjataan joko muille VPC:ille tai ulkopuolelle, rajareitittimille, jotka on määritetty CloudGaten ohjaustason kautta.
Suunnitelmia lähitulevaisuudelle
Jos tiivistää kaikki edellä sanottu muutamaan lauseeseen, voimme sanoa, että VPC Yandex.Cloudissa ratkaisee kaksi tärkeää tehtävää:
- Tarjoaa eristäytymisen eri asiakkaiden välillä.
- Yhdistää resurssit, infrastruktuurin, alustapalvelut, muut pilvet ja paikan päällä yhdeksi verkkoksi.
Ja jotta nämä ongelmat voitaisiin ratkaista hyvin, sinun on tarjottava skaalautuvuus ja vikasietoisuus sisäisen arkkitehtuurin tasolla, minkä VPC tekee.
Vähitellen VPC hankkii toimintoja, otamme käyttöön uusia ominaisuuksia, yritämme parantaa jotain käyttömukavuuden suhteen. Jotkut ideat tulevat esille ja pääsevät prioriteettilistalle yhteisömme jäsenten ansiosta.
Meillä on tällä hetkellä seuraava lista lähitulevaisuuden suunnitelmista:
- VPN palveluna.
- Yksityiset DNS-esiintymät ovat kuvia virtuaalikoneiden nopeaa käyttöönottoa varten esikonfiguroidulla DNS-palvelimella.
- DNS palveluna.
- Sisäinen kuormantasauslaite.
- "Valkoisen" IP-osoitteen lisääminen ilman virtuaalikoneen uudelleenluomista.
Tasapainotin ja mahdollisuus vaihtaa jo luodun virtuaalikoneen IP-osoite olivat tässä luettelossa käyttäjien pyynnöstä. Ollakseni rehellinen, ilman nimenomaista palautetta olisimme ottaneet nämä toiminnot käyttöön hieman myöhemmin. Ja siksi työskentelemme jo osoitteiden ongelman parissa.
Aluksi "valkoinen" IP-osoite voitiin lisätä vain konetta luotaessa. Jos käyttäjä unohti tehdä tämän, virtuaalikone oli luotava uudelleen. Sama ja poista tarvittaessa ulkoinen IP. Pian on mahdollista kytkeä julkinen IP päälle ja pois ilman, että konetta tarvitsee luoda uudelleen.
Voit vapaasti ilmaista mielipiteesi muita käyttäjiä. Autat meitä parantamaan pilvipalvelua ja saamaan tärkeitä ja hyödyllisiä ominaisuuksia nopeammin!
Lähde: will.com