Salve, nomen meum Kostya Kramlich, ego praecipuus elit Virtualis Privati Clouds divisio apud Yandex.Cloud. In retis virtualis laboro, et, ut coniicere possis, in hoc articulo loquar de artificio in genere et de retis virtualis in particulari (VPC) de arte privata. Et invenies etiam cur nos, servicium tincidunt, opiniones a nostris usoribus aestimares. Prima autem.
Quid est VPC?
Nunc in variis bene disponendis officia sunt. Certus sum adhuc aliquem ministratorem sub scrinio administratoris esse, quamquam spero tales fabulas minus et minus communes fieri.
Nunc officia publica nubes movere conantur, et hoc est ubi VPCs offendunt. VPC est pars nubis publicae quae ligat usuin, infrastructuram, suggestum et alias facultates in unum, ubicumque sunt, in nostra Cloud vel ultra. Simul, VPC te permittit ut has facultates in Interreti necessario patefacias, intus in retia tua solitaria manent.
Quod virtualis network similis ab extra
Per VPC intelligimus primum omnium retis et retis obduces, ut VPNaaS, NATaas, LBaas, etc. Atque haec omnia opera reticulati substructurae vitiosae, de qua iam disputatum est. hic in Habre.
Propius inspiciamus in retis virtualis et structuram eius.
Intueamur duas regiones disponibilitate. Reticulum virtualem praebemus - quod vocavimus VPC. Re vera, definit singularitatem spatii inscriptionum vestrarum "griseorum". In unaquaque retis virtualis, plenam potestatem habes in inscriptionum spatio quas ad facultates computandas assignare potes.
Retis global est. Eodem tempore in singulas climata promptitudinis forma entis, quae Subnet, proiicitur. Pro unoquoque Subnet, quem CIDR quantitatis XVI vel minus assignabis. Quaelibet dispositio zona plus quam unum tale entitatem habere potest, et inter eas fugare semper perlucidum est. Hoc significat omnes facultates tuas in eodem VPC inter se "loqui" posse, etiam si Zonae disponibilitate diversa sunt. "Communicare" sine accessu ad Interreti, per vias internas, "cogitare" se in eadem retia privata esse.
Tabula supra figuram condicionem typicam ostendit: duo VPCs qui alicubi in suis inscriptionibus secant. Utrumque potest esse tuum. Exempli causa, alterum ad progressionem, alterum ad probationem. Licet simpliciter esse diversorum utentium - in hoc casu non refert. Et quilibet VPC unam machinam virtualem habet.
Consilium peius faciamus. Facere unam machinam virtualem potes simul coniungere pluribus Subnets. Ut nec justo ipsum, sed varius ligula.
Eodem tempore, si machinas in interreti exponere necesse est, id fieri potest per API vel UI. Ad hoc faciendum, debes translationem tuam "griseo", internam electronicam, in "album" configurare, in oratione publica. Inscriptionem "album" eligere non licet, sed passim ex inscriptione nostra piscinam assignatur. Quamprimum IP externo utere desinis, ad piscinam revertitur. Tantum tempus solves electronicam "album" uteris.
Potest etiam accessum machinae interretialem uti exempli gratia NAT. Potes iter negotiationis tuae ad instantiam tuam per mensam excitandam stabili. Talem casum paravimus quod utentes interdum egent et de eo scimus. Itaque in directorio imaginis nostri est imago proprie figurata NAT.
Sed etiam, cum imago NAT, prompta facta est, figuratio multiplex esse potest. Intelleximus aliquot usoribus hanc optionem commodissimam non esse, in fine igitur eam posse efficere ut NAT pro optato Subnet in unum cliccum efficeret. Haec factura in accessu praevisionis clausa adhuc est, ubi ope membrorum communitariorum comprobatur.
Quomodo virtualis network operatur ab intus
Quomodo user penitus cum network virtualis? Retiaculum exterius cum suis API spectat. Usor ad API venit et cum statu scopo operatur. Per API, videt user quomodo omnia sint disposita et configurata, dum statum videt, quomodo res publica differt a desiderato. Haec est imago usoris. Quid intus agitur?
Statum desideratum in Yandex Database ac varias partes VPC nostri configurare valemus. Reticulum deauratum in Yandex.Cloud aedificatur ex componentibus delectorum OpenContrail, quod nuper Tungsten Fabric appellatum est. Network officia in uno suggestu CloudGate implentur. In CloudGate, pluribus componentibus apertis fonte usi sumus: GoBGP ad tractandas informationes moderandas, ac VPP ad exsequendam iter itineris programmatum super DPDK ad iter datae.
Tungsten Fabricae cum CloudGate per GoBGP communicat. Narrat quid agatur in ornatum ornatum. CloudGate, in uicem, retiacula ipsasque sibi invicem connectit et cum lorem.
Nunc inspiciamus quomodo virtualis retis scalabilitas et quaestiones promptitudinis solvit. Consideremus causam simplicem. Una promptitudo zonae et duae VPC in ea creatae sunt. Unam Tungsten Fabricae exemplum explicavimus et plura myriades reticulorum continet. Networks cum CloudGate communicant. CloudGate, ut iam diximus, earum nexum praestat inter se et cum Interreti.
Dicamus alterum Zonam Availability additum est. Ei tota omittantur pri. Ideo separatim Tungsten Fabricae instantiam in secunda zona disponibilitate instituere debemus. Se- ratio haec erit quae operies tractat et parum novit de prima systemate. Et species quae virtualis retis nostri globalis est, re vera nostrum VPC API creat. Hoc est opus eius.
VPC1 ad Zonam B disponibilitate provisa est, si Availability Zona B has facultates in VPC1 baculo habet. Si nullae sunt copiae ex VPC2 in promptitudine zona B, non materiamus VPC2 in hac zona. Rursus, cum opes ex VPC3 tantum in zona B existant, VPC3 in zona non sint A. Omnia simplicia et logica sunt.
Paululum profundius eamus et vide quomodo hospes specificus in operibus Y.Cloud. Summa notare velim est quod omnes exercitus idem designantur. Facimus nos solum necessarium minimum operarum in ferramentis currere, reliquae omnes in machinis virtualibus currunt. Officia altioris ordinis aedificamus fundatis officiis infrastructuris fundatis, et etiam Nube utimur ad solvendas nonnullas machinas quaestiones, exempli gratia, partem Integration Continuae.
Si exercitum specificum intuemur, videre possumus tria elementa in exercitu OS currere;
- Computus est pars responsalis pro facultates in exercitu distribuendi.
- VRouter Tungsten Fabricae pars est, quae operies ordinat, id est, cuniculis per substratas facis.
- VDisks sunt fragmenta virtualis repositionis.
Praeterea machinis virtualis officia currunt: infrastructurae officia Cloud, officia suggesta et facultatem mos gerendi. Clientariorum facultates et officia tribunalia semper ad deauraturam per VRouter eunt.
Officia infrastructura in operimento plug possunt, sed plerumque in substrata operari volunt. Haesitantur in substrata SR-IOV utendo. Re vera card in schedas retis virtualis (munus virtualis) incidimus eosque in machinis virtualis infrastructuram inpellimus ne effectum perdatis. Exempli gratia, eadem CloudGate educitur ut una ex his infrastructura virtualis machinis.
Nunc quod descripsimus opera global retis virtualis et consilium elementorum nubis fundamentalium, inspiciamus quomodo partes retis virtualis inter se prorsus inter se cohaereant.
Tres ordines in nostro systemate distinguimus:
- Mando Planum - target status systematis ponit. Hoc est quod usor conformat per API.
- Planum imperium - semantics user-specificatas praebet, id est, statum Plani Datae affert ad id quod ab usuario in Mando Plane descriptum est.
- Data Plane - directe procedit user facis.
Ut supra dixi, omnia incipit a servitio suggestu usoris seu interni ad API venientem et statum quendam scopum describens.
Hic status statim ad Yandex Database scriptus, ID operationis asynchronae per API redit, et machinam nostram internam immittit ad statum quem user volebat producere. Officia configurationis ad SDN moderatorem eunt et nuntia Fabricae Tungsten quid in operiendo fieri oporteat. Exempli gratia, reservant portus, virtualis ligula, et similia.
Mando Planum in Tungsten Fabricae onerariae statum debitum ad Planum Imperium. Per eam, Mando Plane cum exercitibus communicat, nuncians quid de illis in proximo futurum sit exacte.
Nunc videamus quae ratio exercituum similis sit. Apparatus virtualis quidam adaptor retis in VRouter inplenda est. VRouter est nucleus fabricae Tungsten moduli qui fasciculos spectat. Si iam fluxus alicuius fasciculi est, modulus processit. Si nullus fluit, modulus punting sic dictus, hoc est, fasciculum ad usormorum processum emittit. Processus partem conlecit et vel sibi ipsi respondet, sicut DHCP et DNS, vel VRouter narrat quid cum illo agat. VRouter tunc aliquid conleci potest.
Praeterea, commercium inter machinis virtualis in eodem reticulo virtuali perlucidum fluit, ad CloudGate non mittitur. Exercitus quibus virtualis machinis explicantur, directe inter se communicant. Nuntiant cuniculum et deinceps ad invicem per underlay.
Imperium Plane inter se communicant per Zonas Availability per BGP, sicut cum alio itinere. Narrant quas machinae ubi instituuntur, ut machinae virtualis in una zona directe cum aliis machinis virtualibus communicare possint.
Imperium Planum etiam cum CloudGate communicat. Similiter refert ubi et quae machinae virtuales instituantur, quales sint inscriptiones eorum. Hoc permittit ut negotiatio externa et negotiatio ab illis libratoribus dirigat.
Negotiatio quae VPC relinquit ad CloudGate venit, in notitia itineris, ubi VPP cum nostris plugins celeriter manditur. Inde mercatura emissa est vel aliis VPCs, vel externis, ad itinera crepidines, quae per ipsum Planum CloudGate Imperium configurantur.
Consilia ad proximo futuro
Si omnia supra paucis sententiis compendiamus, dicere possumus VPC in Yandex.Cloud solvere duas magnas difficultates:
- Solitudinem praebet inter clientes diversos.
- Opes, infrastructuras, officia suggesta, alias nubes et in-praemissa in unum retem coniungit.
Et ad has difficultates bene solvendas, scalabilitatis et culpae tolerantiae opus est curare in ambitu architecturae internae, quae VPC facit.
Paulatim VPC acquirit functiones, novas lineamenta exsequentes, et aliquid ex opportunitate pro users emendare conamur. Nonnullae notiones sonant et includuntur in album prioritatis gratia sodalibus nostrae communitatis.
Nunc proxime sequentem indicem consiliorum proximo futurum habemus;
- ut servitium VPN.
- Instantiae privatae DNS - imagines pro celeriter erigendis machinis virtualibus cum servo DNS praefigurato.
- DNS pro servitio.
- Internum onus librator.
- Addit "album" IP oratio sine apparatus virtualis recreans.
Librarius et facultatem IP oratio mutandi causa machinae virtualis iam creatae in hoc indice inclusae sunt rogatu utentium. Esse honestum, sine expressa opinione de his muneribus paulo post suscepimus. Itaque iam in problemate de inscriptionibus laboramus.
Initio IP oratio "alba" tantum addi potest cum machina creando. Si user facere oblitus est, apparatus virtualis recreandus erat. Idem valet de IP externo tollendo, si opus sit. Mox licebit in publica IP in et off vertere sine machina recreare.
Libenter exprimere tua aliis utentibus. Adiuva nos ut nubes melius efficias et features magnas et utiles citius possideas!
Source: www.habr.com