Hoe Virtual Private Cloud in Yandex Cloud is georganiseerd en hoe onze gebruikers ons helpen nuttige functies te implementeren

Hallo, mijn naam is Kostya Kramlikh, ik ben de lead developer van de Virtual Private Cloud divisie bij Yandex.Cloud. Ik houd me bezig met virtuele netwerken en zoals je kunt raden, zal ik in dit artikel uitleggen wat een Virtual Private Cloud (VPC) is in het algemeen en een virtueel netwerk in het bijzonder. Daarnaast leer je waarom wij, de ontwikkelaars van de service, de feedback van onze gebruikers waarderen. Maar laten we alles stap voor stap bekijken.

Wat is een VPC?

Tegenwoordig zijn er vele mogelijkheden om services uit te rollen. Ik ben ervan overtuigd dat er nog steeds iemand is die een server onder het bureau van de administrator houdt, hoewel ik hoop dat zulke verhalen steeds zeldzamer worden.

Tegenwoordig proberen services zich te verplaatsen naar openbare clouds, en precies daar komen ze de VPC tegen. Een VPC is een deel van de openbare cloud dat de gebruikers-, infrastructuur-, platform- en andere bronnen met elkaar verbindt, waar ze ook zijn, in onze Cloud of daarbuiten. Daarbij maakt de VPC het mogelijk om deze bronnen niet onnodig aan het internet bloot te stellen; ze blijven binnen jouw geïsoleerde netwerk.

Hoe een virtueel netwerk eruitziet van buitenaf

Met VPC bedoelen we vooral een overlay-netwerk en netwerkservices zoals VPNaaS, NATaaS, LBaaS, enzovoorts. En dit alles werkt bovenop een robuuste netwerkinfrastructuur waarover eerder is gesproken. geweldig artikel hier op Habr.

Laten we eens wat dieper kijken naar het virtuele netwerk en de opbouw ervan.

Laten we eens kijken naar twee beschikbaarheidszones. We bieden een virtueel netwerk aan, wat wij VPC noemen. In feite definieert het de unieke ruimte van jouw "grijze" IP-adressen. Binnen elk virtueel netwerk heb je volledige controle over het adresruimte die je kunt toewijzen aan rekenbronnen.

Het netwerk is globaal. Het projecteert zich echter op elke beschikbaarheidszone in de vorm van een entiteit genaamd Subnet. Voor elke Subnet wijs je een bepaalde CIDR toe van 16 of kleiner. In elke beschikbaarheidszone kan er meer dan één dergelijke entiteit zijn, terwijl er altijd transparante routing tussen hen bestaat. Dit betekent dat al jouw bronnen binnen één VPC met elkaar kunnen 'communiceren', zelfs als ze zich in verschillende beschikbaarheidszones bevinden. 'Communiceren' zonder toegang tot het internet, via onze interne kanalen, 'denkend' dat ze zich binnen één privét netwerk bevinden.

In het bovenstaande schema wordt een typische situatie weergegeven: twee VPC's die ergens overlappen in adressen. Beide kunnen aan jou behoren. Bijvoorbeeld, de ene voor ontwikkeling, de andere voor testen. Het kunnen gewoon verschillende gebruikers zijn - in dit geval maakt dat niet uit. En in elke VPC is één virtuele machine geplaatst.

Laten we het schema compliceren. Het is mogelijk om één virtuele machine tegelijkertijd in meerdere Subnets te plaatsen. En niet zomaar, maar in verschillende virtuele netwerken.

Als je de machines toegankelijk wilt maken voor het internet, kan dat via de API of UI. Hiervoor moet je de NAT-translatie van je 'grijze', interne adres naar 'witte' – openbare adres instellen. Je kunt het 'witte' adres niet kiezen; het wordt willekeurig toegewezen uit onze pool van adressen. Zodra je stopt met het gebruik van het externe IP, komt het terug in de pool. Je betaalt alleen voor de tijd dat je het 'witte' adres gebruikt.

Je hebt ook de mogelijkheid om een machine toegang tot internet te geven via een NAT-instantie. Verkeer kan via een statische routeringstabel naar de instantie worden geleid. We hebben deze casus overwogen omdat gebruikers daar behoefte aan hebben, en we zijn ons daarvan bewust. Daarom ligt er in onze beeldengalerij een speciaal geconfigureerd NAT-image.

Maar zelfs met een kant-en-klaar NAT-image kan de configuratie ingewikkeld zijn. We begrepen dat dit voor sommige gebruikers niet de meest handige optie is, dus hebben we uiteindelijk de mogelijkheid gemaakt om NAT voor de gewenste Subnet met één klik in te schakelen. Deze functie is voorlopig nog in gesloten preview-toegang, waarbij deze wordt getest met behulp van deelnemers uit de gemeenschap.

Hoe een virtueel netwerk intern is opgebouwd

Hoe interacteert de gebruiker met het virtuele netwerk? Het netwerk kijkt naar buiten via zijn API. De gebruiker komt bij de API en werkt met de gewenste toestand. Via de API ziet de gebruiker hoe alles moet zijn ingericht en geconfigureerd, terwijl hij de status ziet, hoe ver de daadwerkelijke toestand afwijkt van de gewenste. Dit is het perspectief van de gebruiker. Maar wat gebeurt er van binnen?

We registreren de gewenste staat in de Yandex Database en gaan de verschillende onderdelen van onze VPC configureren. Het overlay-netwerk in Yandex.Cloud is gebaseerd op gekozen componenten van OpenContrail, dat sinds kort de naam Tungsten Fabric heeft. Netwerkservices zijn gerealiseerd op een enkel platform, CloudGate. In CloudGate hebben we ook een aantal open source componenten gebruikt: GoBGP - voor het beheren van controleinformatie, en VPP - voor de implementatie van een software-router die werkt bovenop DPDK voor de dataverwerking.

Tungsten Fabric communiceert met CloudGate via GoBGP. Het geeft aan wat er in het overlay-netwerk gebeurt. CloudGate verbindt op zijn beurt de overlay-netwerken met elkaar en met het internet.

Laten we nu eens kijken hoe het virtuele netwerk schalings- en beschikbaarheidsproblemen oplost. Laten we een eenvoudig geval bekijken. Hier is er één beschikbaarheidszone waarin twee VPC's zijn gemaakt. We hebben één Tungsten Fabric-instantie uitgerold, en deze ondersteunt verschillende tienduizenden netwerken. De netwerken zijn verbonden met CloudGate. CloudGate, zoals we al zeiden, zorgt voor de onderlinge verbondenheid en met het internet.

Stel dat er een tweede beschikbaarheidszone wordt toegevoegd. Deze moet volledig onafhankelijk van de eerste kunnen falen. Daarom moeten we in de tweede beschikbaarheidszone een aparte Tungsten Fabric-instantie plaatsen. Dit wordt een afzonderlijk systeem dat zich bezighoudt met de overlay en weinig weet over het eerste systeem. De zichtbaarheid dat ons virtuele netwerk globaal is, wordt eigenlijk gecreëerd door onze VPC API. Dat is de taak ervan.

VPC1 projecteert zich in beschikbaarheidszone B, als er in beschikbaarheidszone B middelen zijn die in VPC1 worden aangesloten. Als er geen middelen uit VPC2 in beschikbaarheidszone B zijn, maken we VPC2 in deze zone niet toegankelijk. Aan de andere kant, aangezien middelen uit VPC3 alleen in zone B bestaan, is VPC3 niet beschikbaar in zone A. Het is simpel en logisch.

Laten we wat dieper gaan en kijken hoe een specifieke host in Yandex.Cloud is ingericht. Het belangrijkste om op te merken is dat alle hosts op dezelfde manier zijn ingericht. We zorgen ervoor dat alleen het noodzakelijke minimum aan services op de "hardware" draait, terwijl alle anderen operationeel zijn op virtuele machines. We bouwen hogere orde diensten op basis van basisinfrastructuurdiensten en gebruiken de Cloud ook om sommige engineeringtaken op te lossen, bijvoorbeeld in het kader van Continuous Integration.

Als we naar een specifieke host kijken, zien we dat er drie componenten draait in het besturingssysteem van de host:

• Compute – het gedeelte dat verantwoordelijk is voor het verdelen van rekenkracht op de host.
• VRouter – het onderdeel van Tungsten Fabric dat de overlay organiseert, dat wil zeggen, het tunnelend verpakt via de underlay.
• VDisk – dit zijn de stukjes virtualisatie van opslag.

Daarnaast zijn er virtuele machines diensten actief: infrastructuurdiensten van de Cloud, platformdiensten en klantcapaciteit. Klantcapaciteit en platformdiensten lopen altijd via de overlay via VRouter.

Infrastructuurdiensten kunnen op de overlay werken, maar willen in principe werken in de underlay. In de underlay worden ze aangesloten via SR-IOV. In feite splitsen we de kaart in virtuele netwerkkaarten (virtuele functies) en steken deze in infrastructuur-VM's om prestaties niet te verliezen. Bijvoorbeeld, diezelfde CloudGate is gestart als één van deze infrastructuurlijke virtuele machines.

Nu we de globale taken van het virtuele netwerk en de structuur van de basiscomponenten van de cloud hebben beschreven, laten we eens kijken hoe verschillende delen van het virtuele netwerk met elkaar interactie hebben.

We onderscheiden drie lagen in ons systeem:

• Config Plane – stelt de gewenste staat van het systeem in. Dit is wat de gebruiker configureert via de API.
• Control Plane – zorgt ervoor dat de door de gebruiker gedefinieerde semantiek wordt toegepast, dat wil zeggen, het brengt de staat van de Data Plane in overeenstemming met de beschrijving die door de gebruiker in de Config Plane is gegeven.
• Data Plane – verwerkt de gebruikerspakketten direct.

Zoals ik al eerder zei, begint alles met het feit dat de gebruiker of een interne platformsdienst de API benadert en een bepaalde gewenste staat beschrijft.

Deze staat wordt onmiddellijk vastgelegd in de Yandex Database, retourneert via de API de ID van de asynchrone operatie en start onze interne machinerie om de gewenste staat te leveren. Configuratietaken gaan naar de SDN-controller en vertellen Tungsten Fabric wat in de overlay moet gebeuren. Bijvoorbeeld, ze reserveren poorten, virtuele netwerken en dergelijke.

Config Plane in Tungsten Fabric levert de vereiste staat aan de Control Plane. Via deze route communiceert de Config Plane ook met de hosts, en vertelt wat er binnenkort op hen zal draaien.

Laten we nu eens kijken hoe het systeem eruit ziet op de hosts. In een virtuele machine Er is een netwerkadapter aangesloten op de VRouter. De VRouter is een kernmodule van Tungsten Fabric die naar pakketten kijkt. Als er al een flow voor een bepaald pakket is, verwerkt de module het. Als er geen flow is, doet de module wat men noemt 'punting', dat wil zeggen, het verzendt het pakket naar het gebruikersmodussproces. Dit proces analyseert het pakket en beantwoordt het zelf, zoals bijvoorbeeld bij DHCP en DNS, of het vertelt de VRouter wat ermee moet gebeuren. Hierna kan de VRouter het pakket verwerken.

Verder gaat het verkeer tussen virtuele machines binnen één virtueel netwerk transparant en wordt het niet naar CloudGate gestuurd. Hosts waarop de virtuele machines zijn uitgerold, communiceren rechtstreeks met elkaar. Ze tunnelen het verkeer en sturen het naar elkaar door het onderliggende netwerk.

De Control Plane communiceert met elkaar tussen beschikbaarheidszones via BGP, zoals met een andere router. Ze vertellen waar welke machines zijn opgezet, zodat virtuele machines in één zone rechtstreeks met andere virtuele machines kunnen interageren.

De Control Plane communiceert ook met CloudGate. Evenzo meldt het waar en welke virtuele machines zijn opgezet en welke adressen ze hebben. Dit maakt het mogelijk om extern verkeer en verkeer van balancers naar hen te leiden.

Het verkeer dat de VPC verlaat, komt aan op CloudGate, in het data pad, waar het snel wordt verwerkt door VPP met onze plugins. Vervolgens wordt het verkeer ofwel naar andere VPC's gestuurd, ofwel naar buiten, naar de randrouters, die via de Control Plane van CloudGate zelf worden geconfigureerd.

Plannen voor de nabije toekomst

Als we alles wat hierboven is gezegd in een paar zinnen samenvatten, kunnen we zeggen dat VPC in Yandex.Cloud twee belangrijke taken oplost:

• Het biedt isolatie tussen verschillende klanten.
• Het verenigt middelen, infrastructuur, platformdiensten, andere clouds en on-premise in één enkel netwerk.

En om deze taken goed uit te voeren, moet schaalbaarheid en veerkracht op het niveau van de interne architectuur worden gegarandeerd, wat de VPC ook doet.

G geleidelijk krijgt de VPC functies erbij, we realiseren nieuwe mogelijkheden en proberen dingen te verbeteren voor gebruiksvriendelijkheid. Enkele ideeën worden gepresenteerd en komen op de prioriteitenlijst dankzij de deelnemers van onze gemeenschap.

Momenteel hebben we ongeveer deze lijst van plannen voor de nabije toekomst:

• VPN als een dienst.
• Private DNS-instanties – afbeeldingen voor het snel instellen van virtuele machines met een vooraf geconfigureerde DNS-server.
• DNS als een service.
• Interne load balancer.
• Voeg een 'witte' IP-adres toe zonder de virtuele machine opnieuw te moeten creëren.

De load balancer en de mogelijkheid om het IP-adres van een reeds gemaakte virtuele machine te wisselen, zijn aan deze lijst toegevoegd op verzoek van gebruikers. Ik moet eerlijk zeggen, zonder duidelijke feedback zouden we deze functies wat later hebben opgepakt. Maar nu zijn we al bezig met de taak over adressen.

Oorspronkelijk kon een 'wit' IP-adres alleen worden toegevoegd bij het creëren van de machine. Als de gebruiker vergat dit te doen, moest de virtuele machine worden opnieuw aangemaakt. Hetzelfde gold voor het verwijderen van het externe IP. Binnenkort zal het mogelijk zijn om een openbaar IP in en uit te schakelen zonder de machine opnieuw aan te maken.

Aarzel niet om je ideeën kenbaar te maken en voorstellen van andere gebruikers te ondersteunen. Je helpt ons om de Cloud beter te maken en sneller belangrijke en nuttige functies te ontvangen!

Bron: habr.com