Helló, a nevem Kostya Kramlih, a Yandex.Cloud Virtuális Magánfelhő részlegének vezető fejlesztője vagyok. A virtuális hálózatokkal foglalkozom, és, ahogy azt már kitalálhattátok, ebben a cikkben a Virtuális Magánfelhő (VPC) általános felépítéséről és a virtuális hálózatokról mesélek. Emellett megtudjátok, miért értékeljük, mint a szolgáltatás fejlesztői, a felhasználók visszajelzéseit. De mindent sorjában.
Mi az a VPC?
Napjainkban a szolgáltatások telepítésének számos lehetősége létezik. Biztos vagyok benne, hogy valakinek még mindig van egy szervere az adminisztrátor asztala alatt, bár remélem, hogy az ilyen történetek száma egyre csökken.
Jelenleg a szolgáltatások a nyilvános felhők felé mozdulnak el, és itt éppen a VPC-vel találkoznak. A VPC egy nyilvános felhő része, amely összeköti a felhasználói, infrastrukturális, platform- és egyéb erőforrásokat, bárhol is helyezkedjenek el, a mi felhőnkben vagy azon kívül. A VPC lehetővé teszi, hogy ezeket az erőforrásokat ne helyezzük ki az internetre, hanem a saját elkülönített hálózatunkon belül tartsuk őket.
Hogyan néz ki a virtuális hálózat kívülről
A VPC alatt alapvetően egy overlay hálózatot és hálózati szolgáltatásokat értünk, mint például VPNaaS, NATaas, LBaas stb. És mindez egy olyan redundáns hálózati infrastruktúrára épít, amiről már volt szó egy kiváló cikkben itt, a Habr-on.
Nézzük meg közelebbről a virtuális hálózatot és annak felépítését.
Vizsgáljunk meg két elérhetőségi zónát. Mi kínálunk egy virtuális hálózatot – amit VPC-nek nevezünk. Valójában ez határozza meg az „szürke” címeitek egyediségének terét. Minden virtuális hálózaton belül teljes mértékben ellenőrizhetitek azokat a címhelyeket, amelyeket a számítási erőforrásoknak rendelhettek.
A hálózat globális. Ugyanakkor minden elérhetőségi zónában egy Subnet nevű entitás formájában van leképezve. Minden Subnethez egy 16-os vagy kisebb CIDR-t rendeltek. Minden elérhetőségi zónában lehet több ilyen entitás, és a köztük lévő routing mindig átlátható. Ez azt jelenti, hogy az összes erőforrásod egyetlen VPC-n belül „kommunikálhat” egymással, még akkor is, ha különböző elérhetőségi zónákban találhatók. „Kommunikálni” anélkül, hogy az internetre kellene lépniük, a belső csatornáinkon keresztül, úgy „gondolva”, mintha egyetlen privát hálózaton belül lennének.
A fenti ábrán egy tipikus helyzet látható: két VPC, amelyek valahol átfedésben vannak a címek szerint. Mindkettő lehet az Öné. Például, az egyik a fejlesztéshez, a másik a teszteléshez. Lehetnek egyszerűen csak különböző felhasználók – ebben az esetben ez nem számít. És mindkét VPC-be egy-egy virtuális gép van csatlakoztatva.
Fokozzuk a helyzetet. Lehet úgy is kialakítani a rendszert, hogy egy virtuális gép egyszerre több alhálózatra csatlakozzon. És nem csak úgy, hanem különböző virtuális hálózatokban.
Ha internetre kell helyeznie a gépeket, ezt API-n vagy UI-n keresztül megteheti. Ehhez be kell állítania a NAT átkonfigurálását a "szürke", belső címről a "fehér" – nyilvános címre. A "fehér" címet nem választhatja meg, az véletlenszerűen van kiválasztva a mi címkínálatunkból. Amint abbahagyja a külső IP használatát, az visszakerül a címkínálatba. Csak az "fehér" cím használati idejéért kell fizetnie.
Lehetőség van arra is, hogy a gép internet-hozzáférést kapjon NAT-instanccal. Az forgalmat át lehet irányítani az állandó útválasztási táblán keresztül. Ezt a megoldást olyan felhasználók számára terveztük, akiknek szüksége van rá, és erről tudunk. Ennek megfelelően a képek katalógusunkban egy speciálisan konfigurált NAT kép található.
De még amikor készen áll a NAT-kép, a beállítás bonyolult lehet. Tudtuk, hogy egyes felhasználók számára ez nem a legkényelmesebb megoldás, ezért végül lehetőséget adtunk arra, hogy egy kattintással engedélyezze a NAT-ot a szükséges alhálózatra. Ez a funkció még zárt előzetes hozzáférés alatt áll, ami a közösségi résztvevők segítségével van tesztelve.
Hogyan működik a virtuális hálózat belülről
Hogyan interakciózik a felhasználó a virtuális hálózattal? A hálózat kifelé figyel az API-jával. A felhasználó az API-n keresztül érkezik, és a célállapotával dolgozik. Az API-n keresztül a felhasználó látja, hogyan kellene mindennek kinéznie és beállítva lennie, miközben azt is látja, hogy az aktuális állapot mennyire különbözik a kívánttól. Ez a felhasználó látképe. De mi történik belül?
A kívánt állapotot elmentjük a Yandex Database-be, majd konfiguráljuk a VPC különböző részeit. Az overlay hálózat a Yandex Felhőben az OpenContrail válogatott komponensei alapján készült, amely mostanra Tungsten Fabric néven ismert. A hálózati szolgáltatások egyetlen CloudGate platformon valósulnak meg. A CloudGate-ben szintén alkalmaztunk néhány open source komponenst: a GoBGP-t a vezérlő információk elérésére, valamint a VPP-t a DPDK felett működő programozható router megvalósítására az adatsávban.
A Tungsten Fabric a GoBGP-n keresztül kommunikál a CloudGate-tel. Beszámol arról, hogy mi történik az overlay hálózatban. A CloudGate viszont összeköti az overlay hálózatokat egymással és az internettel.
Most nézzük meg, hogyan oldja meg a virtuális hálózat a skálázási és elérhetőségi feladatokat. Vegyünk egy egyszerű esetet. Van egy elérhetőségi zóna, amelyben két VPC-t hoztunk létre. Telepítettünk egy Tungsten Fabric példányt, amely több tízezer hálózatot kezel. A hálózatok csatlakoznak a CloudGate-hez. A CloudGate, ahogy már említettük, biztosítja a kölcsönös kapcsolódásukat és az internethez való hozzáférésüket.
Tegyük fel, hogy hozzáadunk egy második elérhetőségi zónát. Ennek függetlennek kell működnie az elsőtől. Ezért a második elérhetőségi zónában egy külön Tungsten Fabric példányt kell telepítenünk. Ez egy külön rendszer, amely a overlay kezeléséért felel, és alig tud valamit az első rendszerről. A láthatóság, hogy a virtuális hálózatunk globális, valójában a VPC API-nk létrehozásának a feladata.
A VPC1 a B zónába vetül, ha a B zónában olyan erőforrások vannak, amelyek csatlakoznak a VPC1-hez. Ha a B zónában nincsenek VPC2-ből származó erőforrások, akkor a VPC2-t nem materializáljuk ebben a zónában. Ezzel szemben, mivel a VPC3-ból származó erőforrások kizárólag a B zónában léteznek, a VPC3 nincs az A zónában. Mindez egyszerű és logikus.
Nézzük meg kicsit mélyebben, hogyan épül fel egy konkrét hoszt a Yandex Felhőben. Az alapvető dolog, amit meg kell említeni, hogy minden hoszt azonos módon van kialakítva. Úgy alakítjuk, hogy csak a szükséges minimális szolgáltatások fussanak a „hardveren”, minden más pedig a virtuális gépekben. Magasabb szintű szolgáltatásokat építünk az alapvető infrastruktúra szolgáltatásokra alapozva, és a Felhőt használjuk bizonyos mérnöki feladatok megoldására is, például a Continuous Integration keretén belül.
Ha megnézzük a konkrét hostot, látni fogjuk, hogy a host operációs rendszerében három komponens fut:
- Compute – a rész, amely a számítási erőforrások elosztásáért felelős a hoston.
- VRouter – a Tungsten Fabric része, amely a rétegeket szervezi meg, vagyis csomagokat alagútba vezet az underlay-n keresztül.
- VDisk – a tárolóvirtualizáció darabjai.
Ezen kívül virtuális gépekben szolgáltatások futnak: a Cloud infrastruktúra szolgáltatásai, platform szolgáltatások és az ügyfelek erőforrásai. Az ügyfelek erőforrásai és a platform szolgáltatások mindig alagúton keresztül haladnak a VRouteren.
Az infrastruktúra szolgáltatások bekapcsolódhatnak az alagútba, de főként az underlay-ban kívánnak működni. Az underlay-ban SR-IOV-n keresztül kapcsolódnak be. Valójában felosztjuk a kártyát virtuális hálózati kártyákra (virtuális funkciókra), és átnyomjuk őket az infrastruktúra virtuális gépekbe, hogy ne veszítsünk teljesítményt. Például a CloudGate maga is egy ilyen infrastruktúra virtuális gépként fut.
Most, hogy leírtuk a virtuális hálózat globális feladatait és a felhő alapvető komponenseit, nézzük meg, hogyan kölcsönhatnak egymással a virtuális hálózat különböző részei.
Rendszerünkben három réteget különböztetünk meg:
- Config Plane – meghatározza a rendszer célállapotát. Ez az, amit a felhasználó API-n keresztül konfigurál.
- Control Plane – biztosítja a felhasználó által megadott szemantikát, azaz eljuttatja a Data Plane állapotát a felhasználó által a Config Plane-ben leírtaknak megfelelően.
- Data Plane – közvetlenül a felhasználói csomagokat kezeli.
Ahogy már korábban említettem, minden azzal kezdődik, hogy a felhasználó vagy egy belső platform szolgáltatás belép az API-ba, és leírja a kívánt célállapotot.
Ez az állapot azonnal rögzítésre kerül a Yandex Database-ben, az API-n keresztül visszaad egy aszinkron művelet ID-t, és elindítja belső gépezetünket, hogy előállítsa a felhasználó által kívánt állapotot. A konfigurációs feladatok az SDN-vezérlőhöz mennek és elmondják a Tungsten Fabric-nek, mit kell tenni az alagútban. Például portokat, virtuális hálózatokat és hasonlókat tartanak fenn.
A Config Plane a Tungsten Fabric-ban elküldi a Control Plane-nek a kívánt állapotot. Ezen keresztül a Config Plane kommunikál a hostokkal, mondva, hogy mi fog futni rajta hamarosan.
Most nézzük meg, hogyan néz ki a rendszer a hosztokon. A virtuális gépben Van egy hálózati adapter, amely a VRouterbe van dugva. A VRouter a Tungsten Fabric magmodulja, amely figyeli a csomagokat. Ha egy csomaghoz már létezik flow, a modul feldolgozza azt. Ha nincs flow, a modul úgynevezett puntingot végez, azaz a csomagot elküldi a felhasználói módban futó folyamatnak. A folyamat elemzi a csomagot, és vagy közvetlenül válaszol rá, mint például a DHCP és DNS esetén, vagy megmondja a VRouternek, hogy mit tegyen vele. Ezt követően a VRouter képes feldolgozni a csomagot.
Ezen kívül a forgalom a virtuális gépek között egy virtuális hálózaton belül átlátszó módon halad, nem irányítják a CloudGate-en keresztül. Azok a hosztok, amelyeken a virtuális gépek futnak, közvetlenül kommunikálnak egymással. A forgalom alagútba kerül, és egymás számára irányítják az alulról.
A Control Plane egymással kommunikál a rendelkezésre állási zónák között BGP-n keresztül, mint egy másik router. Elmondják, hogy mely gépek hol futnak, hogy a virtuális gépek egy zónán belül közvetlenül kölcsönhatásba léphessenek más virtuális gépekkel.
Ezen kívül a Control Plane kommunikál a CloudGate-tel. Hasonló módon jelzi, hogy hol és milyen virtuális gépek futnak, milyen címekkel rendelkeznek. Ez lehetővé teszi a külső forgalom és a terheléselosztók által irányított forgalom számukra történő irányítását.
A VPC-ből kilépő forgalom a CloudGate-re érkezik, ahol a VPP a mi plug-injeinkkel gyorsan feldolgozza. Ezután a forgalom vagy más VPC-kbe, vagy kifelé, a határ routerekhez kerül, amelyeket a CloudGate Control Plane-jén keresztül állítanak be.
Tervek a közeli jövőre
Ha az eddig elmondottakat összegezzük néhány mondatban, azt mondhatjuk, hogy a VPC a Yandex Felhőben két fontos feladatot lát el:
- Biztosítja a különböző ügyfelek közötti izolációt.
- Összehozza az erőforrásokat, az infrastruktúrát, a platformszolgáltatásokat, más felhőket és a helyi hálózatot egyetlen hálózatba.
Ahhoz, hogy ezeket a feladatokat jól megvalósítsuk, biztosítani kell a skálázhatóságot és a hibamentességet a belső architektúra szintjén, amit a VPC biztosít.
Fokozatosan a VPC új funkciókkal bővül, új lehetőségeket valósítunk meg, és igyekszünk javítani a felhasználói élményt. Néhány ötlet kifejezésre kerül, és a közösségünk tagjainak segítségével bekerül a prioritási listára.
Jelenleg a közeljövőre vonatkozó terveink körülbelül a következőképpen alakulnak:
- VPN mint szolgáltatás.
- Privát DNS példányok – gyorsan beállítható virtuális gépek képei előre konfigurált DNS-szerverrel.
- DNS mint szolgáltatás.
- Belső terheléselosztó.
- A "fehér" IP-cím hozzáadása virtuális gép újbóli létrehozása nélkül.
A terheléselosztó és a már létrehozott virtuális gép IP-címének váltási lehetősége a felhasználói igények alapján került a listába. Bevallom, ha nem kapunk egyértelmű visszajelzéseket, ezekkel a funkciókkal később foglalkoznánk. Jelenleg már dolgozunk az IP-címek feladatán.
Eredetileg a "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 kellett létrehozni. Ugyanez vonatkozik a külső IP-cím eltávolítására is. Hamarosan lehetőség lesz a nyilvános IP be- és kikapcsolására gép újra létrehozása nélkül.
Ne habozzon megosztani a gondolatait és támogatni a javaslatokat más felhasználóktól. Segít nekünk abban, hogy a Felhőt jobban csináljuk és gyorsabban kapjuk meg az fontos és hasznos funkciókat!
Forrás: habr.com
