Helló, a nevem Kostya Krmlich, a Yandex.Cloud Virtual Private Cloud részlegének vezető fejlesztője vagyok. Egy virtuális hálózaton dolgozom, és ahogy sejtheti, ebben a cikkben általában a Virtual Private Cloud (VPC) eszközről fogok beszélni, és különösen a virtuális hálózatról. És azt is megtudhatja, hogy mi, szolgáltatásfejlesztők miért értékeljük felhasználóink visszajelzéseit. De először a dolgok.
Mi az a VPC?
Manapság számos lehetőség kínálkozik a szolgáltatások telepítésére. Biztos vagyok benne, hogy valaki még mindig tart szervert az adminisztrátor asztala alatt, bár remélem, az ilyen sztorik egyre ritkábban fordulnak elő.
Most a szolgáltatások nyilvános felhőkbe próbálnak költözni, és itt találkoznak a VPC-kkel. A VPC a nyilvános felhő része, amely összekapcsolja a felhasználókat, az infrastruktúrát, a platformot és az egyéb kapacitásokat, bárhol is legyenek, a felhőnkban vagy azon túl. Ugyanakkor a VPC lehetővé teszi, hogy elkerülje, hogy ezeket a kapacitásokat szükségtelenül kiszolgáltassa az Internetnek; az elszigetelt hálózaton belül maradnak.
Hogyan néz ki egy virtuális hálózat kívülről
VPC alatt mindenekelőtt egy átfedő hálózatot és hálózati szolgáltatásokat értünk, mint a VPNaaS, NATaas, LBaas stb. És mindez egy hibatűrő hálózati infrastruktúra mellett működik, amiről már volt szó. itt a Habrén.
Nézzük meg közelebbről a virtuális hálózatot és annak felépítését.
Nézzünk két rendelkezésre állási zónát. Egy virtuális hálózatot biztosítunk – amit VPC-nek hívtunk. Valójában ez határozza meg a „szürke” címek egyediségi terét. Az egyes virtuális hálózatokon belül teljes ellenőrzése alatt áll a számítási erőforrásokhoz hozzárendelhető címek területe.
A hálózat globális. Ezzel egyidejűleg minden rendelkezésre állási zónára kivetítik egy alhálózat nevű entitás formájában. Minden alhálózathoz hozzárendel egy 16-os vagy kisebb méretű CIDR-t. Minden rendelkezésre állási zónához több ilyen entitás tartozhat, és mindig átlátható az útválasztás közöttük. Ez azt jelenti, hogy ugyanazon a VPC-n belül az összes erőforrás „beszélgethet” egymással, még akkor is, ha különböző elérhetőségi zónákban vannak. „Kommunikáljunk” internet-hozzáférés nélkül, belső csatornáinkon keresztül, „gondolva”, hogy ugyanazon a magánhálózaton belül vannak.
A fenti diagram egy tipikus helyzetet mutat: két VPC, amelyek valahol a címükben metszik egymást. Mindkettő a tiéd lehet. Például az egyik fejlesztésre, a másik tesztelésre. Lehet, hogy egyszerűen különböző felhasználók vannak – ebben az esetben ez nem számít. És minden VPC-nek van egy virtuális gépe.
Tegyük még rosszabbá a sémát. Egy virtuális gépet egyszerre több alhálózathoz is csatlakoztathat. És nem csak így, hanem különböző virtuális hálózatokban.
Ugyanakkor, ha gépeket kell közzétenni az interneten, ezt megteheti az API-n vagy a felhasználói felületen keresztül. Ehhez be kell állítania a „szürke” belső cím NAT-fordítását „fehér” - nyilvános címre. „Fehér” címet nem választhat, az véletlenszerűen kerül kiosztásra a címkészletünkből. Amint abbahagyja a külső IP-cím használatát, az visszatér a készlethez. Csak a „fehér” cím használatának idejéért fizet.
Lehetőség van arra is, hogy a gépnek internet-hozzáférést biztosítsunk egy NAT-példány segítségével. Statikus útválasztási táblázaton keresztül irányíthatja a forgalmat a példányhoz. Azért biztosítunk ilyen esetet, mert a felhasználóknak néha szükségük van rá, és tudunk róla. Ennek megfelelően a képkönyvtárunkban van egy speciálisan konfigurált NAT-kép.
De még akkor is, ha van kész NAT-kép, a konfiguráció bonyolult lehet. Megértettük, hogy néhány felhasználó számára ez nem a legkényelmesebb lehetőség, így végül lehetővé tettük a NAT engedélyezését a kívánt alhálózaton egy kattintással. Ez a funkció még zárt előzetes hozzáférésben van, ahol a közösség tagjai segítségével tesztelik.
Hogyan működik egy virtuális hálózat belülről
Hogyan lép kapcsolatba a felhasználó egy virtuális hálózattal? A hálózat kifelé néz az API-jával. A felhasználó belép az API-ba, és a célállapottal dolgozik. Az API-n keresztül a felhasználó látja, hogyan kell mindent elrendezni, konfigurálni, miközben látja az állapotot, hogy a tényleges állapot miben tér el a kívánttól. Ez a felhasználó képe. Mi történik odabent?
Rögzítjük a kívánt állapotot a Yandex adatbázisban, és konfiguráljuk a VPC különböző részeit. A Yandex.Cloud átfedő hálózata az OpenContrail kiválasztott összetevői alapján épül fel, amelyet nemrégiben Tungsten Fabricnak neveztek. A hálózati szolgáltatások egyetlen CloudGate platformon valósulnak meg. A CloudGate-nél számos nyílt forráskódú komponenst is használtunk: a GoBGP-t a vezérlési információk kezelésére, valamint a VPP-t a DPDK-n futó szoftverútválasztó implementálására az adatúthoz.
A Tungsten Fabric GoBGP-n keresztül kommunikál a CloudGate-tel. Megmondja, mi történik az átfedő hálózatban. A CloudGate pedig összeköti az overlay hálózatokat egymással és az internettel.
Most pedig nézzük meg, hogyan oldja meg a virtuális hálózat a skálázhatósági és elérhetőségi problémákat. Nézzünk egy egyszerű esetet. Egy rendelkezésre állási zóna van, és két VPC-t hoztak létre benne. Egy Tungsten Fabric példányt telepítettünk, amely több tízezer hálózatot tartalmaz. A hálózatok a CloudGate-tel kommunikálnak. A CloudGate, mint már említettük, biztosítja kapcsolatukat egymással és az internettel.
Tegyük fel, hogy egy második rendelkezésre állási zóna is hozzáadásra kerül. Teljesen az elsőtől függetlenül meg kell buknia. Ezért külön Tungsten Fabric példányt kell telepítenünk a második rendelkezésre állási zónába. Ez egy külön rendszer lesz, amely kezeli az átfedést, és keveset tud az első rendszerről. És az a látszat, hogy virtuális hálózatunk globális, valójában létrehozza a VPC API-nkat. Ez az ő feladata.
A VPC1 a B rendelkezésre állási zónához van hozzárendelve, ha a B rendelkezésre állási zónának vannak olyan erőforrásai, amelyek a VPC1-hez tapadnak. Ha a B rendelkezésre állási zónában nincsenek erőforrások a VPC2-től, akkor ebben a zónában nem valósítjuk meg a VPC2-t. Viszont mivel a VPC3 erőforrásai csak a B zónában léteznek, a VPC3 nem létezik az A zónában. Minden egyszerű és logikus.
Menjünk egy kicsit mélyebbre, és nézzük meg, hogyan működik egy adott gazdagép az Y.Cloudban. A legfontosabb dolog, amit szeretnék megjegyezni, az az, hogy minden hostot egyformán terveztek. Gondoskodunk arról, hogy csak a szükséges minimális szolgáltatások fussanak hardveren, a többi pedig virtuális gépeken. Alapvető infrastrukturális szolgáltatásokra építünk magasabb rendű szolgáltatásokat, és a Felhőt használjuk egyes mérnöki problémák megoldására is, például a Continuous Integration részeként.
Ha megnézünk egy adott gazdagépet, láthatjuk, hogy három összetevő fut a gazdagép operációs rendszerben:
- A Compute a számítási erőforrások gazdagépen történő elosztásáért felelős rész.
- A VRouter a Tungsten Fabric része, amely megszervezi az átfedést, vagyis a csomagokat az alátéten keresztül alagútba vezeti.
- A VDisk a tárolási virtualizáció részei.
Emellett a virtuális gépek szolgáltatásokat is futtatnak: felhő infrastruktúra-szolgáltatásokat, platformszolgáltatásokat és ügyfélkapacitást. Az ügyfelek kapacitásai és platformszolgáltatásai mindig a VRouteren keresztül mennek át az átfedésbe.
Az infrastrukturális szolgáltatások csatlakoztathatók az átfedéshez, de többnyire az alátétben szeretnének dolgozni. Az alátétbe SR-IOV segítségével vannak beragasztva. Valójában a kártyát virtuális hálózati kártyákra (virtuális funkciókra) vágjuk, és az infrastruktúra virtuális gépeibe toljuk, hogy ne veszítsünk teljesítményből. Például ugyanaz a CloudGate indul el ezen infrastrukturális virtuális gépek egyikeként.
Most, hogy leírtuk a virtuális hálózat globális feladatait és a felhő alapvető összetevőinek kialakítását, nézzük meg, hogy a virtuális hálózat különböző részei pontosan hogyan hatnak egymásra.
Rendszerünkben három réteget különböztetünk meg:
- Konfigurációs sík – beállítja a rendszer célállapotát. Ezt konfigurálja a felhasználó az API-n keresztül.
- Vezérlési sík – felhasználó által megadott szemantikát biztosít, azaz az adatsík állapotát a felhasználó által a konfigurációs síkon leírtakra hozza.
- Data Plane – közvetlenül feldolgozza a felhasználói csomagokat.
Ahogy fentebb mondtam, minden azzal kezdődik, hogy a felhasználói vagy belső platformszolgáltatás az API-hoz érkezik, és leír egy bizonyos célállapotot.
Ez az állapot azonnal beírásra kerül a Yandex adatbázisba, visszaadja az aszinkron művelet azonosítóját az API-n keresztül, és elindítja a belső gépezetünket, hogy a felhasználó által kívánt állapotot hozza létre. A konfigurációs feladatok az SDN-vezérlőhöz mennek, és elmondják a Tungsten Fabricnak, hogy mit kell tennie az átfedésben. Például lefoglalnak portokat, virtuális hálózatokat és hasonlókat.
A Tungsten Fabric konfigurációs síkja feltölti a kívánt állapotot a vezérlősíkra. A Config Plane ezen keresztül kommunikál a gazdagépekkel, és elmondja nekik, hogy pontosan mi fog futni rajtuk a közeljövőben.
Most nézzük meg, hogyan néz ki a rendszer a gazdagépeken. A virtuális gép egy bizonyos hálózati adapterrel van csatlakoztatva a VRouterhez. A VRouter egy Tungsten Fabric magmodul, amely a csomagokat nézi. Ha már van folyam egy csomaghoz, a modul feldolgozza azt. Ha nincs áramlás, akkor a modul úgynevezett puntingot végez, vagyis elküldi a csomagot a usermod folyamatnak. A folyamat elemzi a csomagot, és vagy magának válaszol rá, például a DHCP-re és a DNS-re, vagy megmondja a VRouternek, hogy mit tegyen vele. A VRouter ezután feldolgozhatja a csomagot.
Ezenkívül az ugyanazon a virtuális hálózaton belüli virtuális gépek közötti forgalom átláthatóan folyik, nem kerül elküldésre a CloudGate-nek. Azok a gazdagépek, amelyeken a virtuális gépek telepítve vannak, közvetlenül kommunikálnak egymással. Alagútba vezetik a forgalmat, és az alátéten keresztül továbbítják egymásnak.
A vezérlősíkok az elérhetőségi zónákon keresztül BGP-n keresztül kommunikálnak egymással, akárcsak egy másik router. Megmondják, hogy mely gépek hol vannak telepítve, így az egyik zónában lévő virtuális gépek közvetlenül kommunikálhatnak más virtuális gépekkel.
A Control Plane a CloudGate-tel is kommunikál. Hasonlóképpen jelenti, hogy hol és mely virtuális gépek vannak telepítve, mi a címük. Ez lehetővé teszi, hogy a külső forgalmat és a kiegyensúlyozók forgalmát rájuk irányítsa.
A VPC-t elhagyó forgalom a CloudGate-be érkezik, az adatútvonalon, ahol a VPP-t a bővítményeinkkel gyorsan megrágják. Ezután a forgalom vagy más VPC-kre, vagy kifelé, a szélső útválasztókra irányul, amelyek a CloudGate vezérlősíkján keresztül vannak konfigurálva.
Tervek a közeljövőre
Ha néhány mondatban összefoglaljuk a fent leírtakat, elmondhatjuk, hogy a VPC a Yandex.Cloudban két fontos problémát old meg:
- Elszigeteltséget biztosít a különböző ügyfelek között.
- Egyesíti az erőforrásokat, az infrastruktúrát, a platformszolgáltatásokat, az egyéb felhőket és a helyszíni hálózatot egyetlen hálózatban.
És ahhoz, hogy ezeket a problémákat jól megoldjuk, biztosítani kell a skálázhatóságot és a hibatűrést a belső architektúra szintjén, amit a VPC tesz.
Fokozatosan a VPC funkciókat szerez, új funkciókat vezetünk be, és próbálunk valamit javítani a felhasználók kényelmén. Egyes ötletek elhangzottak és felkerültek a prioritási listára közösségünk tagjainak köszönhetően.
Most körülbelül a következő terveink vannak a közeljövőre vonatkozóan:
- VPN mint szolgáltatás.
- Privát DNS-példányok – képek a virtuális gépek gyors beállításához előre konfigurált DNS-kiszolgálóval.
- DNS mint szolgáltatás.
- Belső terheléselosztó.
- „Fehér” IP-cím hozzáadása a virtuális gép újbóli létrehozása nélkül.
Ebbe a listába került a felhasználók kérésére egy kiegyenlítő és egy már létrehozott virtuális gép IP-címének megváltoztatásának lehetősége. Őszintén szólva, kifejezett visszajelzés nélkül kicsit később vállaltuk volna ezeket a funkciókat. Így már dolgozunk a címekkel kapcsolatos problémán.
Kezdetben „fehér” IP-címet csak a gép létrehozásakor lehetett hozzáadni. Ha a felhasználó elfelejtette ezt megtenni, a virtuális gépet újra létre kellett hozni. Ugyanez vonatkozik a külső IP eltávolítására is, ha szükséges. Hamarosan lehetőség nyílik nyilvános IP-cím be- és kikapcsolására anélkül, hogy újra létre kellene hozni a gépet.
Nyugodtan fejezze ki a sajátját más felhasználók. Segít abban, hogy jobbá tegyük a Felhőt, és gyorsabban juthassunk hozzá a fontos és hasznos funkciókhoz!
Forrás: will.com