Hallo, mijn naam is Kostya Kramlikh, ik ben de hoofdontwikkelaar van de Virtual Private Cloud-divisie in Yandex.Cloud. Ik ben een virtuele netwerker, en zoals je misschien al vermoedt, zal ik het in dit artikel hebben over het Virtual Private Cloud (VPC)-apparaat in het algemeen en het virtuele netwerk in het bijzonder. En u zult ook ontdekken waarom wij, de ontwikkelaars van de dienst, feedback van onze gebruikers waarderen. Maar de eerste dingen eerst.
Wat is VPC?
Tegenwoordig zijn er verschillende mogelijkheden om services in te zetten. Ik weet zeker dat iemand de server nog steeds onder het bureau van de beheerder houdt, hoewel ik hoop dat er minder van dergelijke verhalen zijn.
Nu proberen services naar openbare clouds te gaan, en dit is waar ze in botsing komen met VPC's. VPC is een onderdeel van een openbare cloud die gebruiker, infrastructuur, platform en andere capaciteiten met elkaar verbindt, waar ze zich ook bevinden, in onze cloud of daarbuiten. Tegelijkertijd stelt VPC u in staat om deze capaciteiten niet onnodig aan internet bloot te stellen, ze blijven binnen uw geïsoleerde netwerk.
Hoe ziet een virtueel netwerk er van buiten uit?
Met VPC bedoelen we in de eerste plaats een overlay-netwerk en netwerkdiensten, zoals VPNaaS, NATaas, LBaas, etc. En dit alles werkt bovenop een fouttolerante netwerkinfrastructuur, die al hier, op Habré.
Laten we het virtuele netwerk en het bijbehorende apparaat eens nader bekijken.
Overweeg twee beschikbaarheidszones. We bieden een virtueel netwerk - wat we VPC noemden. In feite definieert het de unieke ruimte van uw "grijze" adressen. Binnen elk virtueel netwerk heeft u volledige controle over de ruimte van adressen die u kunt toewijzen aan rekenresources.
Het netwerk is wereldwijd. Tegelijkertijd wordt het geprojecteerd op elk van de beschikbaarheidszones in de vorm van een entiteit genaamd Subnet. Voor elk subnet wijst u een CIDR van grootte 16 of minder toe. Er kan meer dan één dergelijke entiteit in elke beschikbaarheidszone zijn en er is altijd een transparante routering daartussen. Dit betekent dat al uw bronnen binnen dezelfde VPC met elkaar kunnen "praten", zelfs als ze zich in verschillende beschikbaarheidszones bevinden. "Communiceren" zonder toegang tot internet, via onze interne kanalen, "denkend" dat ze zich binnen hetzelfde privé-netwerk bevinden.
Het bovenstaande diagram toont een typische situatie: twee VPC's die elkaar ergens in adressen kruisen. Beide kunnen van jou zijn. Bijvoorbeeld de ene voor ontwikkeling, de andere voor testen. Er kunnen gewoon verschillende gebruikers zijn - in dit geval maakt het niet uit. En op elke VPC is één virtuele machine aangesloten.
Laten we het schema erger maken. U kunt ervoor zorgen dat één virtuele machine in meerdere subnetten tegelijk vastzit. En niet zomaar, maar in verschillende virtuele netwerken.
Tegelijkertijd, als u machines moet blootstellen aan internet, kan dit worden gedaan via de API of UI. Om dit te doen, moet u de NAT-vertaling van uw "grijze", interne adres naar "wit" - openbaar configureren. U kunt geen "wit" adres kiezen, het wordt willekeurig toegewezen uit onze verzameling adressen. Zodra u het externe IP-adres niet meer gebruikt, wordt het teruggestuurd naar de pool. U betaalt alleen voor de tijd dat u het "witte" adres gebruikt.
Het is ook mogelijk om de machine via een NAT-instantie toegang te geven tot het internet. U kunt verkeer naar een instantie routeren via een statische routeringstabel. We hebben zo'n hoesje geleverd, omdat gebruikers het soms nodig hebben, en we weten ervan. Daarom bevat onze image-catalogus een speciaal geconfigureerde NAT-image.
Maar zelfs als er een kant-en-klare NAT-image is, kan de installatie lastig zijn. We begrepen dat dit voor sommige gebruikers niet de handigste optie is, dus uiteindelijk hebben we het mogelijk gemaakt om NAT voor het gewenste subnet met één klik in te schakelen. Deze functie bevindt zich nog steeds in gesloten preview-toegang, waar deze wordt getest met de hulp van communityleden.
Hoe het virtuele netwerk van binnenuit is ingericht
Hoe communiceert de gebruiker met het virtuele netwerk? Het web kijkt naar buiten met zijn API. De gebruiker komt naar de API en werkt met de doelstatus. Via de API ziet de gebruiker hoe alles geregeld en geconfigureerd moet worden, terwijl hij de status ziet, hoeveel de werkelijke status afwijkt van de gewenste. Dit is een foto van de gebruiker. Wat gebeurt er binnen?
We schrijven de gewenste status naar de Yandex-database en gaan verschillende delen van onze VPC configureren. Het overlay-netwerk in Yandex.Cloud is gebaseerd op geselecteerde componenten van OpenContrail, dat onlangs Tungsten Fabric is genoemd. Netwerkdiensten worden geïmplementeerd op één enkel CloudGate-platform. In CloudGate hebben we ook een aantal open source-componenten gebruikt: GoBGP - om toegang te krijgen tot controle-informatie, evenals VPP - om een softwarerouter te implementeren die bovenop DPDK draait voor het gegevenspad.
Tungsten Fabric communiceert met CloudGate via GoBGP. Vertelt wat er gaande is in het overlay-netwerk. CloudGate verbindt op zijn beurt overlay-netwerken met elkaar en met internet.
Laten we nu eens kijken hoe een virtueel netwerk de problemen van schaalvergroting en beschikbaarheid oplost. Laten we een eenvoudig geval bekijken. Er is één beschikbaarheidszone en daarin worden twee VPC's gemaakt. We hebben één Tungsten Fabric-instantie geïmplementeerd en deze trekt enkele tienduizenden netwerken aan. Netwerken communiceren met CloudGate. CloudGate zorgt, zoals we al zeiden, voor hun connectiviteit met elkaar en met internet.
Stel dat er een tweede beschikbaarheidszone wordt toegevoegd. Het zou volledig onafhankelijk van de eerste moeten mislukken. Daarom moeten we in de tweede beschikbaarheidszone een afzonderlijke Tungsten Fabric-instantie installeren. Dit wordt een apart systeem dat zich bezighoudt met de overlay en weinig weet over het eerste systeem. En de zichtbaarheid dat ons virtuele netwerk wereldwijd is, creëert in feite onze VPC API. Dit is zijn taak.
VPC1 wordt toegewezen aan beschikbaarheidszone B als er resources in beschikbaarheidszone B zijn die naar VPC1 worden gepusht. Als er geen resources van VPC2 in beschikbaarheidszone B zijn, zullen we VPC2 niet realiseren in deze zone. Aangezien bronnen van VPC3 alleen in zone B bestaan, bestaat VPC3 op zijn beurt niet in zone A. Alles is eenvoudig en logisch.
Laten we wat dieper gaan en kijken hoe een bepaalde host in Y.Cloud werkt. Het belangrijkste dat ik wil opmerken, is dat alle hosts op dezelfde manier zijn gerangschikt. We zorgen ervoor dat alleen het noodzakelijke minimum aan services op hardware draait, de rest draait op virtuele machines. We bouwen diensten van hogere orde op basis van basisinfrastructuurdiensten en gebruiken de Cloud ook om enkele engineeringproblemen op te lossen, bijvoorbeeld in het kader van Continuous Integration.
Als we naar een specifieke host kijken, kunnen we zien dat er drie componenten draaien op het host-besturingssysteem:
- Compute - het deel dat verantwoordelijk is voor de distributie van computerbronnen op de host.
- VRouter is een onderdeel van Tungsten Fabric dat een overlay organiseert, dat wil zeggen dat het pakketten door een onderlaag tunnelt.
- VDisks zijn stukjes opslagvirtualisatie.
Daarnaast worden services gelanceerd in virtuele machines: cloudinfrastructuurservices, platformservices en klantcapaciteiten. Klantcapaciteiten en platformdiensten gaan via VRouter altijd naar de overlay.
Infrastructuurdiensten kunnen in de overlay blijven steken, maar in principe willen ze in de underlay werken. Met behulp van SR-IOV worden ze in de ondervloer geplakt. In feite knippen we de kaart in virtuele netwerkkaarten (virtuele functies) en duwen ze in virtuele infrastructuurmachines om de prestaties niet te verliezen. Zo wordt dezelfde CloudGate gelanceerd als een van deze virtuele infrastructuurmachines.
Nu we de globale taken van het virtuele netwerk en de structuur van de basiscomponenten van de cloud hebben beschreven, gaan we kijken hoe de verschillende delen van het virtuele netwerk precies met elkaar omgaan.
We onderscheiden drie lagen in ons systeem:
- Config Plane - stelt de doelstatus van het systeem in. Dit is wat de gebruiker configureert via de API.
- Control Plane - biedt door de gebruiker gedefinieerde semantiek, dat wil zeggen, brengt de status van het gegevensvlak naar wat door de gebruiker in Config Plane is beschreven.
- Data Plane - verwerkt direct de pakketten van de gebruiker.
Zoals ik hierboven al zei, begint het allemaal met het feit dat de gebruiker of interne platformservice naar de API komt en een bepaalde doelstatus beschrijft.
Deze status wordt onmiddellijk naar de Yandex-database geschreven, retourneert de asynchrone bewerkings-ID via de API en start onze interne machines om de status te retourneren die de gebruiker wilde. Configuratietaken gaan naar de SDN-controller en vertellen Tungsten Fabric wat te doen in de overlay. Ze reserveren bijvoorbeeld poorten, virtuele netwerken en dergelijke.
Config Plane in Tungsten Fabric stuurt de vereiste status naar het Control Plane. Hierdoor communiceert Config Plane met de hosts en vertelt wat hen binnenkort precies te wachten staat.
Laten we nu eens kijken hoe het systeem eruitziet op de hosts. De virtuele machine heeft een netwerkadapter die is aangesloten op VRouter. VRouter is een Tungsten Fabric-kernmodule die naar pakketten kijkt. Als er al een stroom is voor een bepaald pakket, verwerkt de module deze. Als er geen flow is, doet de module het zogenaamde punting, dat wil zeggen, het stuurt een pakket naar het usermod-proces. Het proces ontleedt het pakket en reageert er zelf op, zoals DHCP en DNS, of vertelt VRouter wat het ermee moet doen. Daarna kan VRouter het pakket verwerken.
Verder verloopt het verkeer tussen virtuele machines binnen hetzelfde virtuele netwerk transparant, het wordt niet naar CloudGate geleid. De hosts waarop de virtuele machines worden ingezet, communiceren rechtstreeks met elkaar. Ze tunnelen het verkeer en sturen het voor elkaar door de ondervloer.
Control Planes communiceren met elkaar tussen beschikbaarheidszones via BGP, net als bij een andere router. Ze vertellen welke machines waar zijn, zodat VM's in de ene zone rechtstreeks kunnen communiceren met andere VM's.
En Control Plane communiceert met CloudGate. Evenzo rapporteert het waar en welke virtuele machines worden opgericht, welke adressen ze hebben. Hiermee kunt u extern verkeer en verkeer van balancers naar hen leiden.
Het verkeer dat de VPC verlaat, komt bij CloudGate, bij het datapad, waar de VPP met onze plugins snel wordt opgevreten. Vervolgens wordt het verkeer naar andere VPC's of naar buiten gestuurd, naar grensrouters die zijn geconfigureerd via het controlevlak van CloudGate zelf.
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:
- Biedt isolatie tussen verschillende klanten.
- Combineert resources, infrastructuur, platformdiensten, andere clouds en on-premise in één netwerk.
En om deze problemen goed op te lossen, moet je zorgen voor schaalbaarheid en fouttolerantie op het niveau van de interne architectuur, wat VPC doet.
Gaandeweg krijgt VPC functies, implementeren we nieuwe features, proberen we iets te verbeteren op het gebied van gebruikersgemak. Sommige ideeën worden geuit en komen op de prioriteitenlijst dankzij de leden van onze community.
We hebben momenteel de volgende lijst met plannen voor de nabije toekomst:
- VPN als een dienst.
- Private DNS-instanties zijn afbeeldingen voor het snel instellen van virtuele machines met een vooraf geconfigureerde DNS-server.
- DNS als een service.
- Interne loadbalancer.
- Een "wit" IP-adres toevoegen zonder de virtuele machine opnieuw te maken.
De balancer en de mogelijkheid om het IP-adres te wisselen voor een reeds gemaakte virtuele machine stonden op deze lijst op verzoek van gebruikers. Om eerlijk te zijn, zonder expliciete feedback zouden we deze functies wat later op ons hebben genomen. En dus werken we al aan het probleem over adressen.
Aanvankelijk kon een "wit" IP-adres alleen worden toegevoegd bij het aanmaken van een machine. Als de gebruiker dit vergat, moest de virtuele machine opnieuw worden gemaakt. Hetzelfde en verwijder indien nodig het externe IP-adres. Het zal binnenkort mogelijk zijn om het openbare IP-adres aan en uit te zetten zonder de machine opnieuw te hoeven maken.
Voel je vrij om je te uiten andere gebruikers. Je helpt ons de Cloud beter te maken en belangrijke en handige functies sneller te krijgen!
Bron: www.habr.com