La informàtica en núvol està penetrant cada cop més a fons a les nostres vides i probablement no hi ha una sola persona que no hagi utilitzat cap servei al núvol almenys una vegada. Tanmateix, què és exactament un núvol i com funciona, poca gent ho sap, fins i tot a nivell d'idea. El 5G ja s'està convertint en una realitat i la infraestructura de telecomunicacions comença a passar de solucions de pols a solucions al núvol, tal com ho va fer quan va passar de solucions totalment maquinari a "pilars" virtualitzats.
Avui parlarem del món interior de la infraestructura del núvol, en particular, veurem els conceptes bàsics de la part de xarxa.
Què és un núvol? La mateixa virtualització: vista de perfil?
Més que una pregunta lògica. No, això no és virtualització, encara que no es podria fer sense ella. Vegem dues definicions:
Cloud computing (d'ara endavant, Cloud) és un model per proporcionar un accés fàcil d'utilitzar als recursos informàtics distribuïts que s'han de desplegar i llançar sota demanda amb la latència més baixa possible i un cost mínim per al proveïdor de serveis.
Virtualització - aquesta és la capacitat de dividir una entitat física (per exemple, un servidor) en diverses de virtuals, augmentant així la utilització dels recursos (per exemple, teníeu 3 servidors carregats al 25-30 per cent, després de la virtualització obteniu 1 servidor carregat al 80-90 per cent). Naturalment, la virtualització consumeix alguns dels recursos: cal alimentar l'hipervisor, però, com ha demostrat la pràctica, el joc val la pena. Un exemple ideal de virtualització és VMWare, que prepara perfectament les màquines virtuals, o per exemple KVM, que jo prefereixo, però això és qüestió de gustos.
Utilitzem la virtualització sense adonar-nos-en, i fins i tot els encaminadors de ferro ja utilitzen la virtualització; per exemple, a l'última versió de JunOS, el sistema operatiu s'instal·la com a màquina virtual a sobre d'una distribució Linux en temps real (Wind River 9). Però la virtualització no és el núvol, però el núvol no pot existir sense virtualització.
La virtualització és un dels elements bàsics sobre els quals es construeix el núvol.
Fer un núvol simplement recollint diversos hipervisors en un domini L2, afegint un parell de llibres de jugades de Yaml per registrar automàticament vlans mitjançant algun tipus d'ansible i embullar alguna cosa com un sistema d'orquestració a tot això per crear màquines virtuals automàticament no funcionarà. Serà més precís, però el Frankenstein resultant no és el núvol que necessitem, tot i que pot ser el somni definitiu per als altres. A més, si agafeu el mateix Openstack, bàsicament encara és Frankenstein, però bé, no en parlem de moment.
Però entenc que a partir de la definició presentada anteriorment no queda del tot clar què es pot anomenar núvol.
Per tant, un document del NIST (National Institute of Standards and Technology) ofereix 5 característiques principals que hauria de tenir una infraestructura de núvol:
Prestació de servei a petició. S'ha de donar accés gratuït a l'usuari als recursos informàtics que se li assignin (com ara xarxes, discs virtuals, memòria, nuclis de processador, etc.), i aquests recursos s'han de facilitar de manera automàtica, és a dir, sense intervenció del proveïdor del servei.
Àmplia disponibilitat de servei. L'accés als recursos s'ha de proporcionar mitjançant mecanismes estàndard que permetin l'ús tant d'ordinadors estàndard com de clients lleugers i dispositius mòbils.
Combinació de recursos en grups. Els grups de recursos han de ser capaços de proporcionar recursos a diversos clients alhora, garantint que els clients estiguin aïllats i lliures d'influència mútua i competència pels recursos. Les xarxes també s'inclouen als pools, la qual cosa indica la possibilitat d'utilitzar l'adreçament superposat. Les piscines han de poder escalar segons la demanda. L'ús de pools permet proporcionar el nivell necessari de tolerància a errors de recursos i d'abstracció de recursos físics i virtuals: al destinatari del servei simplement se li proporciona el conjunt de recursos que ha sol·licitat (on es troben físicament aquests recursos, quants servidors i commutadors - no importa al client). Tanmateix, hem de tenir en compte el fet que el proveïdor ha de garantir la reserva transparent d'aquests recursos.
Adaptació ràpida a diferents condicions. Els serveis han de ser flexibles: subministrament ràpid de recursos, la seva redistribució, afegint o reduint recursos a petició del client, i per part del client hauria de tenir la sensació que els recursos del núvol són infinits. Per facilitar la comprensió, per exemple, no veieu cap avís que una part de l'espai del vostre disc a Apple iCloud ha desaparegut perquè el disc dur del servidor s'ha avariat i les unitats sí que s'han trencat. A més, per la teva banda, les possibilitats d'aquest servei són pràcticament il·limitades -necessites 2 TB- cap problema, l'has pagat i rebut. Un exemple similar es pot donar amb Google.Drive o Yandex.Disk.
Possibilitat de mesurar el servei prestat. Els sistemes en núvol han de controlar i optimitzar automàticament els recursos consumits, i aquests mecanismes han de ser transparents tant per a l'usuari com per al proveïdor del servei. És a dir, sempre pots comprovar quants recursos consumeixes tu i els teus clients.
Val la pena tenir en compte que aquests requisits són majoritàriament requisits per a un núvol públic, de manera que per a un núvol privat (és a dir, un núvol llançat per a les necessitats internes de l'empresa), aquests requisits es poden ajustar lleugerament. Tanmateix, encara s'han de fer, en cas contrari no obtindrem tots els avantatges de la computació en núvol.
Per què necessitem un núvol?
Tanmateix, qualsevol tecnologia nova o existent, qualsevol protocol nou es crea per a alguna cosa (bé, excepte per RIP-ng, és clar). Ningú necessita un protocol pel bé d'un protocol (bé, excepte RIP-ng, és clar). És lògic que el Cloud es creï per oferir algun tipus de servei a l'usuari/client. Tots estem familiaritzats amb almenys un parell de serveis al núvol, per exemple Dropbox o Google.Docs, i crec que la majoria de la gent els utilitza amb èxit; per exemple, aquest article s'ha escrit amb el servei al núvol de Google.Docs. Però els serveis al núvol que coneixem només són una part de les capacitats del núvol; més precisament, només són un servei de tipus SaaS. Podem oferir un servei al núvol de tres maneres: en forma de SaaS, PaaS o IaaS. El servei que necessiteu depèn dels vostres desitjos i capacitats.
Vegem-ho cadascun per ordre:
Programari com a servei (SaaS) és un model per oferir un servei complet al client, per exemple, un servei de correu electrònic com Yandex.Mail o Gmail. En aquest model de prestació de serveis, en realitat, com a client, no feu res més que utilitzar els serveis, és a dir, no cal que penseu a configurar el servei, la seva tolerància a errors o la seva redundància. El més important és no comprometre la vostra contrasenya; el proveïdor d'aquest servei farà la resta per vosaltres. Des del punt de vista del proveïdor de serveis, és totalment responsable de tot el servei, des del maquinari del servidor i els sistemes operatius de l'amfitrió fins a la configuració de la base de dades i el programari.
Plataforma com a servei (PaaS) — quan s'utilitza aquest model, el proveïdor de serveis proporciona al client una peça de treball per al servei, per exemple, prenem un servidor web. El proveïdor de serveis va proporcionar al client un servidor virtual (de fet, un conjunt de recursos, com ara RAM/CPU/emmagatzematge/xarxes, etc.), i fins i tot va instal·lar el sistema operatiu i el programari necessari en aquest servidor, però, la configuració de totes aquestes coses les fa el mateix client i per a la realització del servei el client respon. El proveïdor de serveis, com en el cas anterior, és el responsable del rendiment dels equips físics, dels hipervisors, de la pròpia màquina virtual, de la disponibilitat de la seva xarxa, etc., però el propi servei ja no es troba en la seva àrea de responsabilitat.
Infraestructura com a servei (IaaS) - aquest enfocament ja és més interessant, de fet, el proveïdor de serveis proporciona al client una infraestructura virtualitzada completa, és a dir, un conjunt (conjunt) de recursos, com ara nuclis de CPU, RAM, xarxes, etc. Tota la resta depèn de el client - el que el client vol fer amb aquests recursos dins del conjunt assignat (quota) - no és especialment important per al proveïdor. Si el client vol crear el seu propi vEPC o fins i tot crear un mini operador i oferir serveis de comunicació, sens dubte, feu-ho. En aquest escenari, el proveïdor de serveis és responsable d'aprovisionar els recursos, la seva tolerància a errors i disponibilitat, així com el sistema operatiu que els permet agrupar aquests recursos i posar-los a disposició del client amb la possibilitat d'augmentar o disminuir els recursos en qualsevol moment. a petició del client. El client configura totes les màquines virtuals i altres guix a través del portal d'autoservei i la consola, inclosa la configuració de xarxes (excepte les xarxes externes).
Què és OpenStack?
En les tres opcions, el proveïdor de serveis necessita un sistema operatiu que permeti la creació d'una infraestructura de núvol. De fet, amb SaaS, més d'una divisió és responsable de tota la pila de tecnologies -hi ha una divisió que s'encarrega de la infraestructura- és a dir, proporciona IaaS a una altra divisió, aquesta divisió proporciona SaaS al client. OpenStack és un dels sistemes operatius al núvol que us permet recollir un munt d'interruptors, servidors i sistemes d'emmagatzematge en un únic grup de recursos, dividir aquest grup comú en subgrups (inquilins) i proporcionar aquests recursos als clients a través de la xarxa.
OpenStack és un sistema operatiu al núvol que permet controlar grans grups de recursos informàtics, emmagatzematge de dades i recursos de xarxa, subministrats i gestionats mitjançant una API mitjançant mecanismes d'autenticació estàndard.
En altres paraules, es tracta d'un conjunt de projectes de programari lliure dissenyats per crear serveis al núvol (tant públics com privats), és a dir, un conjunt d'eines que permeten combinar un servidor i un equip de commutació en un sol conjunt de recursos, gestionar aquests recursos, proporcionant el nivell necessari de tolerància a fallades.
En el moment d'escriure aquest material, l'estructura d'OpenStack té aquest aspecte:
Imatge extreta de
Cadascun dels components inclosos a OpenStack realitza una funció específica. Aquesta arquitectura distribuïda permet incloure a la solució el conjunt de components funcionals que necessiteu. Tanmateix, alguns components són components arrel i la seva eliminació comportarà una inoperabilitat total o parcial de la solució en el seu conjunt. Aquests components solen classificar-se en:
- Resum — GUI basada en web per gestionar els serveis d'OpenStack
- Pedra clau és un servei d'identitat centralitzat que proporciona funcionalitat d'autenticació i autorització per a altres serveis, així com la gestió de les credencials d'usuari i les seves funcions.
- Neutron - un servei de xarxa que proporciona connectivitat entre les interfícies de diversos serveis d'OpenStack (inclosa la connectivitat entre les màquines virtuals i el seu accés al món exterior)
- Cinder — proporciona accés a l'emmagatzematge de blocs per a màquines virtuals
- Nou — Gestió del cicle de vida de les màquines virtuals
- Mirada — dipòsit d'imatges i instantànies de màquines virtuals
- Ràpid — proporciona accés a l'objecte d'emmagatzematge
- Ceilòmetre — un servei que ofereix la capacitat de recopilar telemetria i mesurar els recursos disponibles i consumits
- Calor — orquestració basada en plantilles per a la creació i subministrament automàtic de recursos
Es pot consultar una llista completa de tots els projectes i la seva finalitat .
Cada component d'OpenStack és un servei que realitza una funció específica i proporciona una API per gestionar aquesta funció i interactuar amb altres serveis del sistema operatiu al núvol per crear una infraestructura unificada. Per exemple, Nova proporciona una gestió de recursos informàtics i una API per accedir a la configuració d'aquests recursos, Glance proporciona una gestió d'imatges i una API per gestionar-los, Cinder proporciona emmagatzematge en blocs i una API per gestionar-los, etc. Totes les funcions estan interconnectades d'una manera molt estreta.
Tanmateix, si us fixeu, tots els serveis que s'executen a OpenStack són, en última instància, una mena de màquina virtual (o contenidor) connectada a la xarxa. Sorgeix la pregunta: per què necessitem tants elements?
Passem per l'algoritme per crear una màquina virtual i connectar-la a la xarxa i a l'emmagatzematge persistent a Openstack.
- Quan creeu una sol·licitud per crear una màquina, ja sigui una sol·licitud a través d'Horizon (Tauler de control) o una sol·licitud a través de la CLI, el primer que passa és l'autorització de la vostra sol·licitud a Keystone: podeu crear una màquina, té el dret a utilitzar aquesta xarxa, fa el vostre esborrany de quota, etc.
- Keystone autentica la vostra sol·licitud i genera un testimoni d'autenticació al missatge de resposta, que s'utilitzarà més endavant. Després d'haver rebut una resposta de Keystone, la sol·licitud s'envia a Nova (nova api).
- Nova-api comprova la validesa de la vostra sol·licitud posant-vos en contacte amb Keystone mitjançant el testimoni d'autenticació generat anteriorment
- Keystone realitza l'autenticació i proporciona informació sobre permisos i restriccions basats en aquest testimoni d'autenticació.
- Nova-api crea una entrada per a la nova VM a nova-database i passa la sol·licitud per crear la màquina a nova-scheduler.
- Nova-scheduler selecciona l'amfitrió (node de l'ordinador) on es desplegarà la VM en funció dels paràmetres, pesos i zones especificats. Un registre d'això i l'ID de VM s'escriuen a nova-database.
- A continuació, nova-scheduler contacta nova-compute amb una sol·licitud per desplegar una instància. Nova-compute contacta amb nova-conductor per obtenir informació sobre els paràmetres de la màquina (nova-conductor és un element nova que actua com a servidor intermediari entre nova-database i nova-compute, limitant el nombre de peticions a nova-database per evitar problemes amb la base de dades). reducció de càrrega de consistència).
- Nova-conductor rep la informació sol·licitada de nova-database i la passa a nova-compute.
- A continuació, nova-compute truca a un cop d'ull per obtenir l'ID de la imatge. Glace valida la sol·licitud a Keystone i retorna la informació sol·licitada.
- Nova-compute contacta amb neutrons per obtenir informació sobre els paràmetres de la xarxa. De manera semblant a la mirada, neutron valida la sol·licitud a Keystone, després de la qual cosa crea una entrada a la base de dades (identificador de port, etc.), crea una sol·licitud per crear un port i retorna la informació sol·licitada a nova-compute.
- Nova-compute es posa en contacte amb una sol·licitud per assignar un volum a la màquina virtual. De manera semblant a Glance, sidra valida la sol·licitud a Keystone, crea una sol·licitud de creació de volum i retorna la informació sol·licitada.
- Nova-compute contacta amb libvirt amb una sol·licitud per desplegar una màquina virtual amb els paràmetres especificats.
De fet, una operació aparentment senzilla de crear una màquina virtual senzilla es converteix en un remolí de trucades d'API entre elements de la plataforma del núvol. A més, com podeu veure, fins i tot els serveis designats anteriorment també consisteixen en components més petits entre els quals es produeix la interacció. La creació d'una màquina és només una petita part del que permet fer la plataforma al núvol: hi ha un servei encarregat d'equilibrar el trànsit, un servei encarregat de l'emmagatzematge en blocs, un servei responsable del DNS, un servei encarregat de proveir servidors bare metal, etc. El núvol us permet tractar les vostres màquines virtuals com un ramat d'ovelles (a diferència de la virtualització). Si li passa alguna cosa a la vostra màquina en un entorn virtual: la restaureu a partir de còpies de seguretat, etc., però les aplicacions al núvol es creen de tal manera que la màquina virtual no juga un paper tan important: la màquina virtual "va morir" - cap problema - Acaba de crear-ne un de nou, el vehicle es basa en la plantilla i, com diuen, l'equip no es va adonar de la pèrdua del lluitador. Naturalment, això preveu la presència de mecanismes d'orquestració: amb plantilles Heat, podeu implementar fàcilment una funció complexa que consta de desenes de xarxes i màquines virtuals.
Sempre val la pena tenir en compte que no hi ha infraestructura de núvol sense xarxa: cada element d'una manera o altra interactua amb altres elements a través de la xarxa. A més, el núvol té una xarxa absolutament no estàtica. Naturalment, la xarxa subjacent és encara més o menys estàtica: no s'afegeixen nous nodes i commutadors cada dia, però el component de superposició pot canviar i canviarà inevitablement constantment: s'afegiran o se suprimiran noves xarxes, apareixeran noves màquines virtuals i les antigues. morir. I com recordeu per la definició del núvol que es dóna al principi de l'article, els recursos s'han d'assignar a l'usuari de manera automàtica i amb la menor (o millor encara, sense) intervenció del proveïdor de serveis. És a dir, el tipus de subministrament de recursos de xarxa que ara existeix en forma de front-end en forma de compte personal accessible mitjançant http/https i l'enginyer de xarxa de servei Vasily com a backend no és un núvol, ni tan sols. si Vasily té vuit mans.
Neutron, com a servei de xarxa, proporciona una API per gestionar la part de xarxa de la infraestructura del núvol. El servei alimenta i gestiona la part de xarxa d'Openstack proporcionant una capa d'abstracció anomenada Network-as-a-Service (NaaS). És a dir, la xarxa és la mateixa unitat virtual mesurable que, per exemple, els nuclis de CPU virtuals o la quantitat de RAM.
Però abans de passar a l'arquitectura de la part de xarxa d'OpenStack, considerem com funciona aquesta xarxa a OpenStack i per què la xarxa és una part important i integral del núvol.
Així doncs, tenim dues màquines virtuals client RED i dues màquines virtuals client VERD. Suposem que aquestes màquines es troben en dos hipervisors d'aquesta manera:
De moment, això és només virtualització de 4 servidors i res més, ja que fins ara l'únic que hem fet és virtualitzar 4 servidors, col·locant-los en dos servidors físics. I fins ara ni tan sols estan connectats a la xarxa.
Per fer un núvol, hem d'afegir diversos components. Primer, virtualitzem la part de xarxa: hem de connectar aquestes 4 màquines per parelles i els clients volen una connexió L2. Podeu utilitzar un commutador i configurar un tronc en la seva direcció i resoldre-ho tot mitjançant un pont de Linux o, per als usuaris més avançats, openvswitch (hi tornarem més endavant). Però pot haver-hi moltes xarxes, i empènyer constantment L2 a través d'un commutador no és la millor idea: hi ha diferents departaments, un servei de servei, mesos d'espera que es completi una aplicació, setmanes de resolució de problemes, al món modern això l'enfocament ja no funciona. I com més aviat ho entengui una empresa, més fàcil li serà avançar. Per tant, entre els hipervisors seleccionarem una xarxa L3 a través de la qual es comunicaran les nostres màquines virtuals, i a sobre d'aquesta xarxa L3 construirem xarxes virtuals de superposició L2 on funcionarà el trànsit de les nostres màquines virtuals. Podeu utilitzar GRE, Geneve o VxLAN com a encapsulació. Centrem-nos ara en aquest últim, encara que no és especialment important.
Hem de localitzar VTEP en algun lloc (espero que tothom estigui familiaritzat amb la terminologia de VxLAN). Com que tenim una xarxa L3 que ve directament dels servidors, res no ens impedeix col·locar VTEP als propis servidors, i OVS (OpenvSwitch) és excel·lent per fer-ho. Com a resultat, hem obtingut aquest disseny:
Com que el trànsit entre màquines virtuals s'ha de dividir, els ports cap a les màquines virtuals tindran diferents números de vlan. El número d'etiqueta només juga un paper dins d'un commutador virtual, ja que quan està encapsulat a VxLAN el podem eliminar fàcilment, ja que tindrem un VNI.
Ara podem crear les nostres màquines i xarxes virtuals per a elles sense cap problema.
Tanmateix, què passa si el client té una altra màquina, però està en una xarxa diferent? Necessitem arrelament entre xarxes. Veurem una opció senzilla quan s'utilitza l'encaminament centralitzat, és a dir, el trànsit s'encamina a través de nodes de xarxa especials dedicats (bé, per regla general, es combinen amb nodes de control, de manera que tindrem el mateix).
No sembla res complicat: fem una interfície pont al node de control, conduïm el trànsit cap a ell i des d'allà l'encaminem on ho necessitem. Però el problema és que el client RED vol utilitzar la xarxa 10.0.0.0/24 i el client VERD vol utilitzar la xarxa 10.0.0.0/24. És a dir, comencem a tallar espais d'adreces. A més, els clients no volen que altres clients puguin encaminar-se a les seves xarxes internes, la qual cosa té sentit. Per separar les xarxes i el trànsit de dades del client, assignarem un espai de noms independent per a cadascuna d'elles. L'espai de noms és, de fet, una còpia de la pila de xarxa de Linux, és a dir, els clients de l'espai de noms RED estan completament aïllats dels clients de l'espai de noms VERD (bé, l'encaminament entre aquestes xarxes de client es permet mitjançant l'espai de noms predeterminat o en equips de transport amunt).
És a dir, obtenim el següent diagrama:
Els túnels L2 convergeixen des de tots els nodes informàtics al node de control. node on es troba la interfície L3 d'aquestes xarxes, cadascuna en un espai de noms dedicat per a l'aïllament.
Tanmateix, hem oblidat el més important. La màquina virtual ha de donar un servei al client, és a dir, ha de tenir almenys una interfície externa a través de la qual es pugui accedir. És a dir, hem de sortir al món exterior. Aquí hi ha diferents opcions. Fem l'opció més senzilla. Afegirem una xarxa a cada client, que serà vàlida a la xarxa del proveïdor i no es solaparà amb altres xarxes. Les xarxes també es poden creuar i mirar diferents VRF al costat de la xarxa del proveïdor. Les dades de la xarxa també viuran a l'espai de noms de cada client. Tanmateix, encara sortiran al món exterior a través d'una interfície física (o enllaç, que és més lògic). Per separar el trànsit del client, el trànsit que surt a l'exterior s'etiquetarà amb una etiqueta VLAN assignada al client.
Com a resultat, hem obtingut aquest diagrama:
Una pregunta raonable és per què no fer passarel·les als mateixos nodes de càlcul? Això no és un gran problema; a més, si enceneu l'encaminador distribuït (DVR), això funcionarà. En aquest escenari, estem considerant l'opció més senzilla amb una passarel·la centralitzada, que s'utilitza per defecte a Openstack. Per a funcions d'alta càrrega, utilitzaran tant un encaminador distribuït com tecnologies d'acceleració com SR-IOV i Passthrough, però com diuen, aquesta és una història completament diferent. Primer, tractem la part bàsica i després entrarem en els detalls.
De fet, el nostre esquema ja és viable, però hi ha un parell de matisos:
- Hem de protegir d'alguna manera les nostres màquines, és a dir, posar un filtre a la interfície del commutador cap al client.
- Feu possible que una màquina virtual obtingui automàticament una adreça IP, de manera que no haureu d'iniciar sessió a través de la consola cada vegada i registrar l'adreça.
Comencem amb la protecció de la màquina. Per a això podeu utilitzar iptables banals, per què no.
És a dir, ara la nostra topologia s'ha tornat una mica més complicada:
Posem-nos en marxa. Hem d'afegir un servidor DHCP. El lloc més ideal per localitzar servidors DHCP per a cada client seria el node de control ja esmentat anteriorment, on es troben els espais de noms:
Tanmateix, hi ha un petit problema. Què passa si tot es reinicia i desapareix tota la informació sobre el lloguer d'adreces a DHCP? És lògic que les màquines rebin noves adreces, cosa que no és gaire convenient. Hi ha dues maneres de sortir d'aquí: utilitzeu noms de domini i afegiu un servidor DNS per a cada client, aleshores l'adreça no serà especialment important per a nosaltres (semblant a la part de xarxa a k8s), però hi ha un problema amb les xarxes externes, ja que També s'hi poden emetre adreces mitjançant DHCP: necessiteu sincronització amb servidors DNS a la plataforma de núvol i un servidor DNS extern, que al meu entendre no és gaire flexible, però és molt possible. O la segona opció és utilitzar metadades, és a dir, desar informació sobre l'adreça emesa a la màquina perquè el servidor DHCP sàpiga quina adreça enviar a la màquina si la màquina ja ha rebut una adreça. La segona opció és més senzilla i flexible, ja que permet guardar informació addicional sobre el cotxe. Ara afegim metadades de l'agent al diagrama:
Un altre tema que també val la pena discutir és la capacitat d'utilitzar una xarxa externa per part de tots els clients, ja que les xarxes externes, si han de ser vàlides a tota la xarxa, seran difícils: cal assignar i controlar constantment l'assignació d'aquestes xarxes. La possibilitat d'utilitzar una única xarxa externa preconfigurada per a tots els clients serà molt útil a l'hora de crear un núvol públic. Això facilitarà el desplegament de màquines perquè no hem de consultar una base de dades d'adreces i seleccionar un espai d'adreces únic per a la xarxa externa de cada client. A més, podem registrar una xarxa externa prèviament i en el moment del desplegament només caldrà associar adreces externes amb màquines client.
I aquí NAT ens ajuda: només farem possible que els clients accedeixin al món exterior mitjançant l'espai de noms predeterminat mitjançant la traducció de NAT. Bé, aquí hi ha un petit problema. Això és bo si el servidor client actua com a client i no com a servidor, és a dir, inicia connexions en lloc d'acceptar. Però per a nosaltres serà al revés. En aquest cas, hem de fer la NAT de destinació perquè en rebre trànsit, el node de control entengui que aquest trànsit està destinat a la màquina virtual A del client A, la qual cosa vol dir que hem de fer una traducció de NAT des d'una adreça externa, per exemple 100.1.1.1. .10.0.0.1, a una adreça interna 100. En aquest cas, tot i que tots els clients utilitzaran la mateixa xarxa, l'aïllament intern es conserva completament. És a dir, hem de fer dNAT i sNAT al node de control. Si s'utilitza una única xarxa amb adreces flotants o xarxes externes, o totes dues alhora, depèn del que vulgueu introduir al núvol. No afegirem adreces flotants al diagrama, però deixarem les xarxes externes ja afegides anteriorment: cada client té la seva pròpia xarxa externa (al diagrama s'indiquen com a vlan 200 i XNUMX a la interfície externa).
Com a resultat, hem rebut una solució interessant i alhora molt pensada, que té una certa flexibilitat però que encara no disposa de mecanismes de tolerància a errors.
En primer lloc, només tenim un node de control: la seva fallada provocarà el col·lapse de tots els sistemes. Per solucionar aquest problema, heu de fer almenys un quòrum de 3 nodes. Afegim això al diagrama:
Naturalment, tots els nodes estan sincronitzats i quan surt un node actiu, un altre node es farà càrrec de les seves responsabilitats.
El següent problema són els discs de les màquines virtuals. De moment, s'emmagatzemen als mateixos hipervisors i, en cas de problemes amb l'hipervisor, perdem totes les dades, i la presència d'una incursió no ajudarà aquí si perdem no el disc, sinó tot el servidor. Per fer-ho, hem de fer un servei que faci de front end per a algun tipus d'emmagatzematge. Quin tipus d'emmagatzematge serà no és especialment important per a nosaltres, però hauria de protegir les nostres dades de fallades tant del disc com del node, i possiblement de tot l'armari. Aquí hi ha diverses opcions: hi ha, per descomptat, xarxes SAN amb canal de fibra, però siguem sincers: el FC ja és una relíquia del passat, un anàleg de l'E1 en el transport, sí, estic d'acord, encara s'utilitza, però només on és absolutament impossible sense ell. Per tant, no desplegaria voluntàriament una xarxa FC el 2020, sabent que hi ha altres alternatives més interessants. Encara que a cadascú el seu, hi pot haver qui creu que el FC amb totes les seves limitacions és tot el que necessitem -no discutiré, cadascú té la seva opinió. Tanmateix, la solució més interessant al meu entendre és utilitzar una SDS, com ara Ceph.
Ceph us permet crear una solució d'emmagatzematge de dades d'alta disponibilitat amb un munt de possibles opcions de còpia de seguretat, començant per codis amb comprovació de paritat (anàloga al raid 5 o 6) i acabant amb la replicació completa de dades a diferents discs, tenint en compte la ubicació dels discos en servidors, i servidors en armaris, etc.
Per construir Ceph necessiteu 3 nodes més. La interacció amb l'emmagatzematge també es durà a terme a través de la xarxa mitjançant serveis d'emmagatzematge de blocs, objectes i fitxers. Afegim emmagatzematge a l'esquema:
Nota: també podeu crear nodes de càlcul hiperconvergents (aquest és el concepte de combinar diverses funcions en un sol node, per exemple, emmagatzematge+computació), sense dedicar nodes especials per a l'emmagatzematge de ceph. Tindrem el mateix esquema tolerant a errors, ja que SDS reservarà dades amb el nivell de reserva que especifiquem. Tanmateix, els nodes hiperconvergents sempre són un compromís, ja que el node d'emmagatzematge no només escalfa l'aire com sembla a primera vista (ja que no hi ha màquines virtuals), sinó que gasta els recursos de la CPU en donar servei a SDS (de fet, ho fa tot). la replicació i la recuperació després de fallades de nodes, discs, etc.). És a dir, perdreu part de la potència del node de càlcul si el combineu amb l'emmagatzematge.
Totes aquestes coses s'han de gestionar d'alguna manera: necessitem alguna cosa a través del qual puguem crear una màquina, una xarxa, un encaminador virtual, etc. Per fer-ho, afegirem un servei al node de control que actuarà com a tauler: El client podrà connectar-se a aquest portal a través de http/https i fer tot el que necessita (bé, gairebé).
Com a resultat, ara tenim un sistema tolerant a fallades. Tots els elements d'aquesta infraestructura s'han de gestionar d'alguna manera. Abans es va descriure que Openstack és un conjunt de projectes, cadascun dels quals proporciona una funció específica. Com veiem, hi ha elements més que suficients que cal configurar i controlar. Avui parlarem de la part de la xarxa.
Arquitectura de neutrons
A OpenStack, és Neutron qui s'encarrega de connectar els ports de les màquines virtuals a una xarxa L2 comuna, assegurant l'encaminament del trànsit entre màquines virtuals situades en xarxes L2 diferents, així com l'encaminament cap a l'exterior, proporcionant serveis com NAT, Floating IP, DHCP, etc.
A un alt nivell, el funcionament del servei de xarxa (la part bàsica) es pot descriure de la següent manera.
Quan s'inicia la màquina virtual, el servei de xarxa:
- Crea un port per a una màquina virtual determinada (o ports) i en notifica al servei DHCP;
- Es crea un nou dispositiu de xarxa virtual (mitjançant libvirt);
- La màquina virtual es connecta als ports creats al pas 1;
Curiosament, el treball de Neutron es basa en mecanismes estàndards coneguts per a tothom que s'ha submergit mai a Linux: espais de noms, iptables, ponts de Linux, openvswitch, conntrack, etc.
S'ha d'aclarir immediatament que Neutron no és un controlador SDN.
El neutró consta de diversos components interconnectats:
Servidor de neutrons Openstack és un dimoni que funciona amb les sol·licituds dels usuaris mitjançant l'API. Aquest dimoni no participa en el registre de cap connexió de xarxa, però proporciona la informació necessària per a això als seus connectors, que després configuren l'element de xarxa desitjat. Els agents de neutrons dels nodes d'OpenStack es registren al servidor de neutrons.
Neutron-server és en realitat una aplicació escrita en python, que consta de dues parts:
- Servei REST
- Connector de neutrons (nucli/servei)
El servei REST està dissenyat per rebre trucades d'API d'altres components (per exemple, una sol·licitud per proporcionar informació, etc.)
Els connectors són components/mòduls de programari de connectors que es criden durant les sol·licituds d'API, és a dir, l'atribució d'un servei es produeix a través d'ells. Els connectors es divideixen en dos tipus: servei i arrel. Per regla general, el connector de cavall és el principal responsable de gestionar l'espai d'adreces i les connexions L2 entre les màquines virtuals, i els connectors de servei ja proporcionen funcionalitats addicionals com ara VPN o FW.
La llista de connectors disponibles avui es pot veure, per exemple
Hi pot haver diversos connectors de servei, però només hi pot haver un connector de cavall.
openstack-neutron-ml2 és el connector arrel estàndard d'Openstack. Aquest connector té una arquitectura modular (a diferència del seu predecessor) i configura el servei de xarxa mitjançant controladors connectats a ell. Mirarem el propi complement una mica més endavant, ja que de fet dóna la flexibilitat que té OpenStack a la part de xarxa. El connector d'arrel es pot substituir (per exemple, Contrail Networking fa aquesta substitució).
Servei RPC (servidor rabbitmq) — un servei que proporciona la gestió de cues i la interacció amb altres serveis d'OpenStack, així com la interacció entre els agents de serveis de xarxa.
Agents de xarxa — agents que es troben a cada node, a través dels quals es configuren els serveis de xarxa.
Hi ha diversos tipus d'agents.
L'agent principal és Agent L2. Aquests agents s'executen a cadascun dels hipervisors, inclosos els nodes de control (més precisament, a tots els nodes que presten qualsevol servei als inquilins) i la seva funció principal és connectar màquines virtuals a una xarxa L2 comuna, i també generar alertes quan es produeixi algun esdeveniment ( per exemple, desactivar/habilitar el port).
El següent agent no menys important és Agent L3. Per defecte, aquest agent s'executa exclusivament en un node de xarxa (sovint el node de xarxa es combina amb un node de control) i proporciona l'encaminament entre xarxes d'arrendataris (tant entre les seves xarxes com les xarxes d'altres inquilins, i és accessible al món exterior, proporcionant NAT, així com servei DHCP). Tanmateix, quan s'utilitza un DVR (encaminador distribuït), la necessitat d'un connector L3 també apareix als nodes de càlcul.
L'agent L3 utilitza espais de noms de Linux per proporcionar a cada inquilí un conjunt de xarxes aïllades pròpies i la funcionalitat d'encaminadors virtuals que encaminen el trànsit i proporcionen serveis de passarel·la per a xarxes de capa 2.
Base de dades — una base de dades d'identificadors de xarxes, subxarxes, ports, grups, etc.
De fet, Neutron accepta sol·licituds d'API des de la creació de qualsevol entitat de xarxa, autentica la sol·licitud i mitjançant RPC (si accedeix a algun connector o agent) o API REST (si es comunica en SDN) transmet als agents (mitjançant connectors) el instruccions necessàries per organitzar el servei sol·licitat.
Passem ara a la instal·lació de prova (com es desplega i què hi inclou, veurem més endavant a la part pràctica) i veurem on es troba cada component:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
De fet, aquesta és tota l'estructura de Neutron. Ara val la pena dedicar una estona al connector ML2.
Capa modular 2
Com s'ha esmentat anteriorment, el connector és un connector arrel estàndard d'OpenStack i té una arquitectura modular.
El predecessor del connector ML2 tenia una estructura monolítica, que no permetia, per exemple, utilitzar una barreja de diverses tecnologies en una instal·lació. Per exemple, no podeu utilitzar openvswitch i linuxbridge alhora, ni el primer ni el segon. Per aquest motiu, es va crear el connector ML2 amb la seva arquitectura.
ML2 té dos components: dos tipus de controladors: controladors de tipus i controladors de mecanisme.
Tipus de conductors determinar les tecnologies que s'utilitzaran per organitzar les connexions de xarxa, per exemple, VxLAN, VLAN, GRE. Al mateix temps, el controlador permet l'ús de diferents tecnologies. La tecnologia estàndard és l'encapsulació VxLAN per a xarxes de superposició i xarxes externes vlan.
Els controladors de tipus inclouen els següents tipus de xarxa:
Plànol - xarxa sense etiquetar
VLAN - Xarxa etiquetada
Local — un tipus especial de xarxa per a instal·lacions tot en un (aquestes instal·lacions són necessàries per als desenvolupadors o per a la formació)
GRE — Superposició de xarxa mitjançant túnels GRE
VxLAN — Superposició de xarxa mitjançant túnels VxLAN
Conductors de mecanismes definir eines que garanteixin l'organització de les tecnologies especificades al controlador de tipus, per exemple, openvswitch, sr-iov, opendaylight, OVN, etc.
En funció de la implementació d'aquest controlador, s'utilitzaran agents controlats per Neutron, o bé s'utilitzaran connexions a un controlador SDN extern, que s'encarrega de tots els problemes relacionats amb l'organització de xarxes L2, l'encaminament, etc.
Exemple: si fem servir ML2 juntament amb OVS, s'instal·la un agent L2 a cada node informàtic que gestiona OVS. Tanmateix, si fem servir, per exemple, OVN o OpenDayLight, aleshores el control d'OVS està sota la seva jurisdicció: Neutron, mitjançant el connector root, dóna ordres al controlador i ja fa el que se li va dir.
Anem a repassar Open vSwitch
De moment, un dels components clau d'OpenStack és Open vSwitch.
Quan instal·leu OpenStack sense cap SDN de proveïdor addicional, com ara Juniper Contrail o Nokia Nuage, OVS és el component de xarxa principal de la xarxa de núvol i, juntament amb iptables, conntrack, espais de noms, us permet organitzar xarxes de superposició de múltiples arrendataris. Naturalment, aquest component es pot substituir, per exemple, quan s'utilitzen solucions SDN de propietat (proveïdor) de tercers.
OVS és un commutador de programari de codi obert dissenyat per utilitzar-lo en entorns virtualitzats com a reenviador de trànsit virtual.
De moment, OVS té una funcionalitat molt decent, que inclou tecnologies com QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, etc.
Nota: OVS no es va concebre inicialment com un commutador suau per a funcions de telecomunicacions molt carregades i estava més dissenyat per a funcions informàtiques que exigeixen menys amplada de banda, com ara el servidor WEB o el servidor de correu. No obstant això, OVS s'està desenvolupant més i les implementacions actuals d'OVS han millorat molt el seu rendiment i capacitats, cosa que permet que sigui utilitzat per operadors de telecomunicacions amb funcions molt carregades, per exemple, hi ha una implementació OVS amb suport per a l'acceleració DPDK.
Hi ha tres components importants d'OVS que cal tenir en compte:
- Mòdul del nucli — un component situat a l'espai del nucli que processa el trànsit en funció de les regles rebudes de l'element de control;
- vCanvia daemon (ovs-vswitchd) és un procés llançat a l'espai d'usuari que s'encarrega de programar el mòdul del nucli, és a dir, representa directament la lògica del funcionament del commutador.
- Servidor de bases de dades - una base de dades local situada a cada host que executi OVS, en la qual s'emmagatzema la configuració. Els controladors SDN es poden comunicar mitjançant aquest mòdul mitjançant el protocol OVSDB.
Tot això s'acompanya d'un conjunt d'utilitats de diagnòstic i gestió, com ara ovs-vsctl, ovs-appctl, ovs-ofctl, etc.
Actualment, Openstack és àmpliament utilitzat pels operadors de telecomunicacions per migrar-hi funcions de xarxa, com ara EPC, SBC, HLR, etc. Algunes funcions poden viure sense problemes amb OVS tal com és, però per exemple, EPC processa el trànsit dels subscriptors; després passa per una gran quantitat de trànsit (ara els volums de trànsit arriben a diversos centenars de gigabits per segon). Naturalment, conduir aquest trànsit a través de l'espai del nucli (ja que el reenviador es troba allà per defecte) no és la millor idea. Per tant, OVS sovint es desplega completament a l'espai d'usuari mitjançant la tecnologia d'acceleració DPDK per reenviar el trànsit de la NIC a l'espai d'usuari sense passar pel nucli.
Nota: per a un núvol desplegat per a funcions de telecomunicacions, és possible generar trànsit des d'un node de càlcul sense passar OVS directament a l'equip de commutació. Amb aquesta finalitat s'utilitzen mecanismes SR-IOV i Passthrough.
Com funciona això en un disseny real?
Bé, ara passem a la part pràctica i veiem com funciona tot a la pràctica.
Primer, implementem una instal·lació senzilla d'Openstack. Com que no tinc un conjunt de servidors a mà per a experiments, muntarem el prototip en un servidor físic des de màquines virtuals. Sí, naturalment, aquesta solució no és adequada per a finalitats comercials, però per veure un exemple de com funciona la xarxa a Openstack, aquesta instal·lació és suficient per als ulls. A més, aquesta instal·lació és encara més interessant per a la formació, ja que podeu atrapar trànsit, etc.
Com que només ens cal veure la part bàsica, no podem utilitzar diverses xarxes sinó que ho aixequem tot utilitzant només dues xarxes, i la segona xarxa d'aquest disseny s'utilitzarà exclusivament per a l'accés al servidor subcloud i DNS. De moment, no tocarem les xarxes externes: aquest és un tema per a un article gran a part.
Per tant, comencem per ordre. Primer, una mica de teoria. Instal·larem Openstack mitjançant TripleO (Openstack a Openstack). L'essència de TripleO és que instal·lem Openstack tot en un (és a dir, en un node), anomenat undercloud, i després utilitzem les capacitats de l'Openstack desplegat per instal·lar Openstack destinat al funcionament, anomenat overcloud. Undercloud utilitzarà la seva capacitat inherent per gestionar servidors físics (el projecte Ironic) per subministrar hipervisors que faran les funcions de computació, control i nodes d'emmagatzematge. És a dir, no utilitzem cap eina de tercers per implementar Openstack; implementem Openstack mitjançant Openstack. Es farà molt més clar a mesura que avanci la instal·lació, així que no ens aturarem aquí i avançarem.
Nota: en aquest article, per simplificar, no vaig utilitzar l'aïllament de la xarxa per a xarxes internes d'Openstack, però tot es desplega amb una sola xarxa. Tanmateix, la presència o absència d'aïllament de xarxa no afecta la funcionalitat bàsica de la solució: tot funcionarà exactament igual que quan s'utilitza l'aïllament, però el trànsit fluirà a la mateixa xarxa. Per a una instal·lació comercial, és naturalment necessari utilitzar l'aïllament mitjançant vlans i interfícies diferents. Per exemple, el trànsit de gestió de l'emmagatzematge de ceph i el propi trànsit de dades (accés de la màquina als discs, etc.) quan estan aïllats utilitzen diferents subxarxes (gestió d'emmagatzematge i emmagatzematge) i això permet fer que la solució sigui més tolerant a errors dividint aquest trànsit, per exemple. , a través de diferents ports o utilitzant diferents perfils de QoS per a diferents trànsits, de manera que el trànsit de dades no s'extreu el trànsit de senyalització. En el nostre cas aniran a la mateixa xarxa i de fet això no ens limita de cap manera.
Nota: com que anem a executar màquines virtuals en un entorn virtual basat en màquines virtuals, primer hem d'habilitar la virtualització imbricada.
Podeu comprovar si la virtualització imbricada està habilitada o no així:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Si veieu la lletra N, habilitem el suport per a la virtualització imbricada segons qualsevol guia que trobeu a la xarxa, per exemple .
Hem de muntar el següent circuit des de màquines virtuals:
En el meu cas, per connectar les màquines virtuals que formen part de la futura instal·lació (i n'he tingut 7, però amb 4 te'n pots sortir si no tens molts recursos), he fet servir OpenvSwitch. Vaig crear un pont ovs i vaig connectar-hi màquines virtuals mitjançant grups de ports. Per fer-ho, he creat un fitxer xml com aquest:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Aquí es declaren tres grups de ports: dos d'accés i un tronc (aquest últim era necessari per al servidor DNS, però podeu prescindir-ne o instal·lar-lo a la màquina amfitrió, el que us resulti més convenient). A continuació, utilitzant aquesta plantilla, declarem la nostra a través de virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Ara editem les configuracions del port de l'hipervisor:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Nota: en aquest cas, l'adreça del port ovs-br1 no serà accessible perquè no té una etiqueta vlan. Per solucionar-ho, heu d'emetre l'ordre sudo ovs-vsctl set port ovs-br1 tag=100. Tanmateix, després d'un reinici, aquesta etiqueta desapareixerà (si algú sap com fer que es mantingui al seu lloc, li estaré molt agraït). Però això no és tan important, perquè només necessitarem aquesta adreça durant la instal·lació i no la necessitarem quan Openstack estigui completament desplegat.
A continuació, creem una màquina subnúvol:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Durant la instal·lació, configureu tots els paràmetres necessaris, com ara el nom de la màquina, les contrasenyes, els usuaris, els servidors ntp, etc., podeu configurar immediatament els ports, però per a mi personalment, després de la instal·lació, és més fàcil iniciar sessió a la màquina mitjançant la consola i corregir els fitxers necessaris. Si ja teniu una imatge preparada, podeu utilitzar-la o fer el que vaig fer jo: descarregar la imatge mínima de Centos 7 i utilitzar-la per instal·lar la VM.
Després d'una instal·lació correcta, hauríeu de tenir una màquina virtual en la qual pugueu instal·lar el subnúvol
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningPrimer, instal·leu les eines necessàries per al procés d'instal·lació:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instal·lació sota núvol
Creem un usuari de pila, establim una contrasenya, l'afegim a sudoer i li donem la possibilitat d'executar ordres root mitjançant sudo sense haver d'introduir una contrasenya:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackAra especifiquem el nom complet del subnúvol al fitxer hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6A continuació, afegim repositoris i instal·lem el programari que necessitem:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleNota: si no teniu previst instal·lar ceph, no cal que introduïu ordres relacionades amb ceph. Vaig utilitzar el llançament de Queens, però pots utilitzar-ne qualsevol que vulguis.
A continuació, copieu el fitxer de configuració del subnúvol a la pila de directoris d'inici de l'usuari:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confAra hem de corregir aquest fitxer, ajustant-lo a la nostra instal·lació.
Heu d'afegir aquestes línies al començament del fitxer:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Per tant, passem per la configuració:
undercloud_hostname — el nom complet del servidor undercloud, ha de coincidir amb l'entrada del servidor DNS
local_ip — adreça subcloud local cap al subministrament de xarxa
passarel·la_xarxa — la mateixa adreça local, que actuarà com a porta d'accés al món exterior durant la instal·lació de nodes d'overcloud, també coincideix amb la ip local
undercloud_public_host — adreça API externa, s'assigna qualsevol adreça gratuïta de la xarxa de subministrament
undercloud_admin_host adreça de l'API interna, s'assigna qualsevol adreça gratuïta de la xarxa de subministrament
servidors de noms_undercloud - Servidor DNS
generar_certificat_de_servei - aquesta línia és molt important en l'exemple actual, perquè si no la configureu com a fals, rebreu un error durant la instal·lació, el problema es descriu al rastrejador d'errors de Red Hat
interfície_local interfície en el subministrament de xarxa. Aquesta interfície es reconfigurarà durant el desplegament del subnúvol, de manera que cal tenir dues interfícies al núvol: una per accedir-hi, la segona per aprovisionament.
local_mtu - MTU. Com que tenim un laboratori de proves i tinc un MTU de 1500 als ports de commutació OVS, cal configurar-lo a 1450 perquè els paquets encapsulats a VxLAN puguin passar.
network_cidr - Xarxa de subministrament
mascarada — utilitzar NAT per accedir a una xarxa externa
xarxa_mascarada - xarxa que serà NAT
dhcp_start — l'adreça inicial del grup d'adreces des de la qual s'assignaran adreces als nodes durant el desplegament d'overcloud
dhcp_end — l'adreça final del grup d'adreces des de la qual s'assignaran les adreces als nodes durant el desplegament d'overcloud
inspecció_iprange — un conjunt d'adreces necessàries per a la introspecció (no s'ha de solapar amb el conjunt anterior)
scheduler_max_attempts — nombre màxim d'intents d'instal·lar overcloud (ha de ser superior o igual al nombre de nodes)
Després de descriure el fitxer, podeu donar l'ordre per desplegar undercloud:
openstack undercloud install
El procediment triga de 10 a 30 minuts, depenent de la planxa. Al final, hauríeu de veure una sortida com aquesta:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Aquesta sortida diu que heu instal·lat amb èxit undercloud i ara podeu comprovar l'estat del undercloud i procedir a instal·lar overcloud.
Si mireu la sortida ifconfig, veureu que ha aparegut una nova interfície de pont
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0El desplegament d'overcloud ara es durà a terme a través d'aquesta interfície.
A la sortida següent podeu veure que tenim tots els serveis en un node:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+A continuació es mostra la configuració de la part de la xarxa undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Instal·lació d'overcloud
De moment només tenim undercloud i no tenim prou nodes a partir dels quals es muntarà l'overcloud. Per tant, primer de tot, despleguem les màquines virtuals que necessitem. Durant el desplegament, el propi undercloud instal·larà el sistema operatiu i el programari necessari a la màquina d'overcloud, és a dir, no necessitem desplegar completament la màquina, sinó només crear-hi un disc (o discs) i determinar-ne els paràmetres, és a dir , de fet, tenim un servidor nu sense un sistema operatiu instal·lat.
Anem a la carpeta amb els discos de les nostres màquines virtuals i creem discos de la mida requerida:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GCom que estem operant com a root, hem de canviar el propietari d'aquests discs per no tenir cap problema amb els drets:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Nota: si no teniu previst instal·lar ceph per estudiar-lo, les ordres no creen almenys 3 nodes amb almenys dos discs, però a la plantilla indiqueu que s'utilitzaran els discos virtuals vda, vdb, etc.
Genial, ara hem de definir totes aquestes màquines:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml Al final hi ha una comanda -print-xml > /tmp/storage-1.xml, que crea un fitxer xml amb una descripció de cada màquina a la carpeta /tmp/; si no l'afegiu, no estarà capaç d'identificar màquines virtuals.
Ara hem de definir totes aquestes màquines a virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Ara un petit matís: tripleO utilitza IPMI per gestionar servidors durant la instal·lació i la introspecció.
La introspecció és el procés d'inspecció del maquinari per tal d'obtenir els seus paràmetres necessaris per a l'aprovisionament posterior dels nodes. La introspecció es realitza mitjançant ironic, un servei dissenyat per treballar amb servidors bare metal.
Però aquí hi ha el problema: si bé els servidors IPMI de maquinari tenen un port separat (o un port compartit, però això no és important), les màquines virtuals no tenen aquests ports. Aquí ens ajuda una crossa anomenada vbmc, una utilitat que us permet emular un port IPMI. Val la pena prestar atenció a aquest matís, especialment per a aquells que volen muntar un laboratori d'aquest tipus en un hipervisor ESXI; per ser sincer, no sé si té un anàleg de vbmc, així que val la pena preguntar-se sobre aquest problema abans de desplegar-ho tot. .
Instal·leu vbmc:
yum install yum install python2-virtualbmcSi el vostre sistema operatiu no troba el paquet, afegiu el repositori:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmAra configurem la utilitat. Aquí tot és banal fins a la desgràcia. Ara és lògic que no hi hagi servidors a la llista vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Perquè apareguin, s'han de declarar manualment així:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Crec que la sintaxi de l'ordre és clara sense explicacions. Tanmateix, de moment totes les nostres sessions estan en estat DOWN. Perquè puguin passar a l'estat UP, cal que els activeu:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#I el toc final: heu de corregir les regles del tallafoc (o desactivar-les completament):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Ara anem al undercloud i comprovem que tot funciona. L'adreça de la màquina amfitriona és 192.168.255.200, a undercloud hem afegit el paquet ipmitool necessari durant la preparació per al desplegament:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningCom podeu veure, hem llançat amb èxit el node de control mitjançant vbmc. Ara apaguem-lo i seguim:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#El següent pas és la introspecció dels nodes en els quals s'instal·larà l'overcloud. Per fer-ho, hem de preparar un fitxer json amb una descripció dels nostres nodes. Tingueu en compte que, a diferència de la instal·lació en servidors nus, el fitxer indica el port on s'executa vbmc per a cada màquina.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Nota: el node de control té dues interfícies, però en aquest cas això no és important, en aquesta instal·lació n'hi haurà prou amb una.
Ara preparem el fitxer json. Hem d'indicar l'adreça poppy del port a través del qual es realitzarà l'aprovisionament, els paràmetres dels nodes, donar-los noms i indicar com arribar a ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Ara hem de preparar imatges per irònic. Per fer-ho, descarregueu-los mitjançant wget i instal·leu:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Càrrega d'imatges al núvol:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Comprovant que s'han carregat totes les imatges
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Una cosa més: heu d'afegir un servidor DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Ara podem donar l'ordre per a la introspecció:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Com podeu veure a la sortida, tot es va completar sense errors. Comprovem que tots els nodes estiguin en l'estat disponible:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Si els nodes es troben en un estat diferent, normalment manejable, aleshores alguna cosa ha fallat i heu de mirar el registre i esbrinar per què ha passat això. Tingueu en compte que en aquest escenari estem utilitzant la virtualització i pot haver-hi errors associats a l'ús de màquines virtuals o vbmc.
A continuació, hem d'indicar quin node realitzarà quina funció, és a dir, indicar el perfil amb el qual es desplegarà el node:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Especifiqueu el perfil per a cada node:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Comprovem que ho hem fet tot correctament:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Si tot és correcte, donem l'ordre per desplegar l'overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuEn una instal·lació real, naturalment s'utilitzaran plantilles personalitzades, en el nostre cas això complicarà molt el procés, ja que s'haurà d'explicar cada edició de la plantilla. Com s'ha escrit anteriorment, fins i tot una simple instal·lació serà suficient per veure com funciona.
Nota: la variable --libvirt-type qemu és necessària en aquest cas, ja que utilitzarem la virtualització imbricada. En cas contrari, no podreu executar màquines virtuals.
Ara teniu aproximadament una hora, o potser més (segons les capacitats del maquinari) i només podeu esperar que després d'aquest temps vegeu el següent missatge:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Ara teniu una versió gairebé completa d'openstack, sobre la qual podeu estudiar, experimentar, etc.
Comprovem que tot funciona correctament. A la pila del directori d'inici de l'usuari hi ha dos fitxers: un stackrc (per gestionar el núvol) i el segon overcloudrc (per gestionar l'overcloud). Aquests fitxers s'han d'especificar com a font, ja que contenen informació necessària per a l'autenticació.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$La meva instal·lació encara requereix un petit toc: afegir una ruta al controlador, ja que la màquina amb la qual estic treballant està en una xarxa diferent. Per fer-ho, aneu a control-1 al compte heat-admin i registreu la ruta
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Bé, ara pots anar a l'horitzó. Tota la informació (adreces, inici de sessió i contrasenya) es troba al fitxer /home/stack/overcloudrc. El diagrama final té aquest aspecte:
Per cert, a la nostra instal·lació, les adreces de les màquines s'emeten mitjançant DHCP i, com podeu veure, s'emeten “a l'atzar”. Podeu definir estrictament a la plantilla quina adreça s'ha d'adjuntar a quina màquina durant el desplegament, si ho necessiteu.
Com flueix el trànsit entre màquines virtuals?
En aquest article veurem tres opcions per passar trànsit
- Dues màquines en un hipervisor en una xarxa L2
- Dues màquines en hipervisors diferents a la mateixa xarxa L2
- Dues màquines en xarxes diferents (arrelament entre xarxes)
Casos amb accés al món exterior a través d'una xarxa externa, utilitzant adreces flotants, així com enrutament distribuït, els tindrem en compte la propera vegada, de moment ens centrarem en el trànsit intern.
Per comprovar-ho, muntem el següent diagrama:
Hem creat 4 màquines virtuals - 3 en una xarxa L2 - net-1 i 1 més a la xarxa net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Vegem en quins hipervisors es troben les màquines creades:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Les màquines vm-1 i vm-3 es troben al compute-0, les màquines vm-2 i vm-4 es troben al node compute-1.
A més, s'ha creat un encaminador virtual per habilitar l'encaminament entre les xarxes especificades:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ L'encaminador té dos ports virtuals, que actuen com a passarel·les per a les xarxes:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Però abans de veure com flueix el trànsit, mirem el que tenim actualment al node de control (que també és un node de xarxa) i al node de càlcul. Comencem amb el node de càlcul.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$De moment, el node té tres ponts ovs: br-int, br-tun, br-ex. Entre ells, com veiem, hi ha un conjunt d'interfícies. Per facilitar la comprensió, tracem totes aquestes interfícies al diagrama i veiem què passa.
Si observem les adreces a les quals s'eleven els túnels VxLAN, es pot veure que un túnel s'eleva a compute-1 (192.168.255.26), el segon túnel mira a control-1 (192.168.255.15). Però el més interessant és que br-ex no té interfícies físiques, i si mireu quins fluxos estan configurats, podeu veure que aquest pont només pot deixar anar trànsit de moment.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Com podeu veure a la sortida, l'adreça es cargola directament al port físic i no a la interfície del pont virtual.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
Segons la primera regla, s'ha de descartar tot el que provingui del port phy-br-ex.
De fet, actualment no hi ha cap altre lloc on el trànsit entri en aquest pont excepte des d'aquesta interfície (la interfície amb br-int), i a jutjar per les caigudes, el trànsit BUM ja ha volat al pont.
És a dir, el trànsit només pot sortir d'aquest node a través del túnel VxLAN i res més. Tanmateix, si enceneu el DVR, la situació canviarà, però ho tractarem una altra vegada. Quan utilitzeu l'aïllament de xarxa, per exemple amb vlans, no tindreu una interfície L3 a la vlan 0, sinó diverses interfícies. Tanmateix, el trànsit VxLAN sortirà del node de la mateixa manera, però també encapsulat en algun tipus de vlan dedicat.
Hem resolt el node de càlcul, passem al node de control.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$De fet, podem dir que tot és igual, però l'adreça IP ja no es troba a la interfície física sinó al pont virtual. Això es fa perquè aquest port és el port pel qual sortirà el trànsit al món exterior.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Aquest port està lligat al pont br-ex i, com que no hi ha etiquetes vlan, aquest port és un port troncal en el qual es permeten tots els vlan, ara el trànsit surt sense etiqueta, tal com indica vlan-id 0 a la sortida a dalt.
Tota la resta en aquest moment és similar al node de càlcul: els mateixos ponts, els mateixos túnels que van a dos nodes de càlcul.
No considerarem els nodes d'emmagatzematge en aquest article, però per entendre-ho cal dir que la part de xarxa d'aquests nodes és banal fins al punt de la desgràcia. En el nostre cas, només hi ha un port físic (eth0) amb una adreça IP assignada i ja està. No hi ha túnels VxLAN, ponts de túnels, etc. - no hi ha cap ov, ja que no té cap sentit. Quan utilitzeu l'aïllament de la xarxa, aquest node tindrà dues interfícies (ports físics, bodny o només dues vlans, no importa, depèn del que vulgueu): una per a la gestió, la segona per al trànsit (escriptura al disc de la VM). , lectura des del disc, etc.)
Hem esbrinat què tenim als nodes en absència de serveis. Ara iniciem 4 màquines virtuals i veiem com canvia l'esquema descrit anteriorment: hauríem de tenir ports, encaminadors virtuals, etc.
Fins ara la nostra xarxa té aquest aspecte:
Tenim dues màquines virtuals a cada node informàtic. Utilitzant compute-0 com a exemple, vegem com s'inclou tot.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ La màquina només té una interfície virtual: tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Aquesta interfície es veu al pont de Linux:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Com podeu veure a la sortida, només hi ha dues interfícies al pont: tap95d96a75-a0 i qvb95d96a75-a0.
Aquí val la pena insistir una mica en els tipus de dispositius de xarxa virtual a OpenStack:
vtap: interfície virtual connectada a una instància (VM)
qbr - Pont de Linux
qvb i qvo - parell vEth connectat al pont Linux i al pont Open vSwitch
br-int, br-tun, br-vlan — Obriu els ponts de vSwitch
patch-, int-br-, phy-br- - Obriu les interfícies de patch de vSwitch que connecten els ponts
qg, qr, ha, fg, sg: obre els ports vSwitch utilitzats pels dispositius virtuals per connectar-se a OVS
Com enteneu, si tenim un port qvb95d96a75-a0 al pont, que és un parell vEth, en algun lloc hi ha el seu homòleg, que lògicament s'hauria d'anomenar qvo95d96a75-a0. Vegem quins ports hi ha a OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Com podem veure, el port està en br-int. Br-int actua com un commutador que finalitza els ports de les màquines virtuals. A més de qvo95d96a75-a0, el port qvo5bd37136-47 és visible a la sortida. Aquest és el port a la segona màquina virtual. Com a resultat, el nostre diagrama ara té aquest aspecte:
Una pregunta que hauria d'interessar immediatament al lector atent: quin és el pont de Linux entre el port de la màquina virtual i el port OVS? El cas és que per protegir la màquina s'utilitzen grups de seguretat, que no són més que iptables. OVS no funciona amb iptables, així que es va inventar aquesta "muleta". No obstant això, s'està convertint en obsolet: s'està substituint per conntrack en els nous llançaments.
És a dir, en última instància, l'esquema té aquest aspecte:
Dues màquines en un hipervisor en una xarxa L2
Com que aquestes dues màquines virtuals es troben a la mateixa xarxa L2 i al mateix hipervisor, el trànsit entre elles fluirà lògicament localment a través de br-int, ja que ambdues màquines estaran a la mateixa VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Dues màquines en hipervisors diferents a la mateixa xarxa L2
Ara vegem com anirà el trànsit entre dues màquines de la mateixa xarxa L2, però ubicades en hipervisors diferents. Per ser honest, res canviarà molt, només el trànsit entre hipervisors passarà pel túnel vxlan. Vegem un exemple.
Adreces de màquines virtuals entre les quals veurem el trànsit:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Mirem la taula de reenviament a br-int a compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]El trànsit hauria d'anar al port 2 - vegem quin tipus de port és:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Això és patch-tun, és a dir, la interfície de br-tun. Vegem què passa amb el paquet a br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ El paquet s'empaqueta a VxLAN i s'envia al port 2. Vegem on porta el port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Aquest és un túnel vxlan a compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Anem a compute-1 i veiem què passa després amb el paquet:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac es troba a la taula de reenviament br-int a compute-1 i, com es pot veure a la sortida anterior, és visible a través del port 2, que és el port cap a br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Bé, llavors veiem que a br-int a compute-1 hi ha una rosella de destinació:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ És a dir, el paquet rebut volarà al port 3, darrere del qual ja hi ha una instància de màquina virtual-00000003.
La bellesa de desplegar Openstack per a l'aprenentatge a la infraestructura virtual és que podem capturar fàcilment el trànsit entre hipervisors i veure què hi passa. Això és el que farem ara, executeu tcpdump al port vnet cap a compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************La primera línia mostra que Patek des de l'adreça 10.0.1.85 va a l'adreça 10.0.1.88 (trànsit ICMP) i està embolicat en un paquet VxLAN amb vni 22 i el paquet passa de l'amfitrió 192.168.255.19 (compute-0) a l'amfitrió 192.168.255.26. .1 ( calcular-XNUMX). Podem comprovar que el VNI coincideix amb el especificat a ovs.
Tornem a aquesta línia actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 és vni en el sistema numèric hexadecimal. Convertim aquest nombre al desè sistema:
16 = 6*16^0+1*16^1 = 6+16 = 22És a dir, vni correspon a la realitat.
A la segona línia hi ha el trànsit de tornada, bé, no té sentit explicar-ho, allà està tot clar.
Dues màquines en xarxes diferents (encaminament entre xarxes)
L'últim cas d'avui és l'encaminament entre xarxes dins d'un projecte mitjançant un encaminador virtual. Estem considerant un cas sense DVR (ho veurem en un altre article), de manera que l'encaminament es produeix al node de xarxa. En el nostre cas, el node de xarxa no es troba en una entitat independent i es troba al node de control.
Primer, vegem que l'encaminament funciona:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msCom que en aquest cas el paquet ha d'anar a la passarel·la i s'ha d'encaminar allà, hem d'esbrinar l'adreça poppy de la passarel·la, per a la qual cosa ens fixem en la taula ARP de la instància:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Ara vegem on s'ha d'enviar el trànsit amb destinació (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Vegem on porta el port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Tot és lògic, el trànsit va a br-tun. Vegem en quin túnel vxlan s'embolicarà:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ El tercer port és un túnel vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Que mira el node de control:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ El trànsit ha arribat al node de control, així que hem d'anar-hi i veure com es produirà l'encaminament.
Com recordeu, el node de control interior tenia exactament el mateix aspecte que el node de càlcul: els mateixos tres ponts, només br-ex tenia un port físic a través del qual el node podia enviar trànsit a l'exterior. La creació d'instàncies va canviar la configuració dels nodes de càlcul: es van afegir ponts de Linux, iptables i interfícies als nodes. La creació de xarxes i un encaminador virtual també va deixar empremta en la configuració del node de control.
Per tant, és obvi que l'adreça MAC de la passarel·la ha d'estar a la taula de reenviament br-int al node de control. Comprovem que hi és i on està buscant:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ El Mac és visible des del port qr-0c52b15f-8f. Si tornem a la llista de ports virtuals d'Openstack, aquest tipus de port s'utilitza per connectar diversos dispositius virtuals a OVS. Per ser més precisos, qr és un port per a l'encaminador virtual, que es representa com un espai de noms.
Vegem quins espais de noms hi ha al servidor:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Fins a tres exemplars. Però a jutjar pels noms, podeu endevinar el propòsit de cadascun d'ells. Tornarem a les instàncies amb ID 0 i 1 més endavant, ara ens interessa l'espai de noms qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Aquest espai de noms conté dos d'interns que hem creat anteriorment. Els dos ports virtuals s'han afegit a br-int. Comprovem l'adreça mac del port qr-0c52b15f-8f, ja que el trànsit, a jutjar per l'adreça mac de destinació, anava a aquesta interfície.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ És a dir, en aquest cas, tot funciona segons les lleis de l'encaminament estàndard. Com que el trànsit està destinat a l'amfitrió 10.0.2.8, ha de sortir per la segona interfície qr-92fa49b5-54 i passar pel túnel vxlan fins al node de càlcul:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Tot és lògic, sense sorpreses. Vegem on l'adreça de rosella de l'amfitrió 10.0.2.8 és visible a br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Com era d'esperar, el trànsit va a br-tun, anem a veure a quin túnel va el següent:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ El trànsit entra al túnel per calcular-1. Bé, a compute-1 tot és senzill: des de br-tun, el paquet passa a br-int i d'aquí a la interfície de la màquina virtual:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Comprovem que aquesta és realment la interfície correcta:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
De fet, vam anar tot el camí pel paquet. Crec que us heu adonat que el trànsit passava per diferents túnels vxlan i sortia amb diferents VNI. Vegem quin tipus de VNI són, després del qual recollirem un abocament al port de control del node i ens assegurarem que el trànsit flueix exactament com es descriu anteriorment.
Per tant, el túnel per calcular-0 té les següents accions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Convertim 0x16 al sistema de numeració decimal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22El túnel per calcular-1 té el següent VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Convertim 0x63 al sistema de numeració decimal:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Bé, ara mirem l'abocador:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************El primer paquet és un paquet vxlan de l'amfitrió 192.168.255.19 (compute-0) a l'amfitrió 192.168.255.15 (control-1) amb vni 22, dins del qual s'empaqueta un paquet ICMP des de l'amfitrió 10.0.1.85 a l'amfitrió 10.0.2.8. Tal com hem calculat anteriorment, vni coincideix amb el que hem vist a la sortida.
El segon paquet és un paquet vxlan de l'amfitrió 192.168.255.15 (control-1) a l'amfitrió 192.168.255.26 (compute-1) amb vni 99, dins del qual s'empaqueta un paquet ICMP des de l'amfitrió 10.0.1.85 a l'amfitrió 10.0.2.8. Tal com hem calculat anteriorment, vni coincideix amb el que hem vist a la sortida.
Els dos paquets següents són trànsit de retorn de 10.0.2.8 no 10.0.1.85.
És a dir, al final hem obtingut el següent esquema de nodes de control:
Sembla que és això? Ens hem oblidat de dos espais de noms:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Com hem parlat de l'arquitectura de la plataforma al núvol, estaria bé que les màquines rebin adreces automàticament d'un servidor DHCP. Aquests són dos servidors DHCP per a les nostres dues xarxes 10.0.1.0/24 i 10.0.2.0/24.
Comprovem que això és cert. Només hi ha una adreça en aquest espai de noms - 10.0.1.1 - l'adreça del propi servidor DHCP, i també s'inclou a br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Vegem si els processos que contenen qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 al seu nom al node de control:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Hi ha aquest procés i basant-nos en la informació que es presenta a la sortida anterior, podem, per exemple, veure què tenim actualment de lloguer:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Com a resultat, obtenim el següent conjunt de serveis al node de control:
Bé, tingueu en compte: això són només 4 màquines, 2 xarxes internes i un encaminador virtual... Ara no tenim xarxes externes aquí, un munt de projectes diferents, cadascun amb les seves pròpies xarxes (superposades), i tenim un encaminador distribuït apagat i, al final, al cap i a la fi, només hi havia un node de control al banc de proves (per a la tolerància a errors hi ha d'haver un quòrum de tres nodes). És lògic que en el comerç tot sigui “una mica” més complicat, però en aquest exemple senzill entenem com ha de funcionar: si teniu 3 o 300 espais de noms és, per descomptat, important, però des del punt de vista del funcionament del tota l'estructura, res canviarà molt... encara que no connectareu cap SDN de proveïdor. Però aquesta és una història completament diferent.
Espero que hagi estat interessant. Si teniu comentaris/afegits, o en algun lloc he mentit directament (sóc humà i la meva opinió sempre serà subjectiva) - escriviu el que cal corregir/afegir-ho corregirem/afegirem tot.
En conclusió, m'agradaria dir algunes paraules sobre la comparació d'Openstack (tant de vainilla com de proveïdor) amb la solució al núvol de VMWare: m'han fet aquesta pregunta massa sovint durant els darrers dos anys i, francament, estic ja n'he cansat, però encara. Al meu entendre, és molt difícil comparar aquestes dues solucions, però definitivament podem dir que hi ha desavantatges en ambdues solucions i a l'hora d'escollir una solució cal sospesar els pros i els contres.
Si OpenStack és una solució impulsada per la comunitat, aleshores VMWare té el dret de fer només el que vol (llegir, què és rendible) i això és lògic, perquè és una empresa comercial que està acostumada a guanyar diners amb els seus clients. Però hi ha un gran i gros PERÒ: podeu baixar d'OpenStack, per exemple de Nokia, i amb poca despesa canviar a una solució de, per exemple, Juniper (Contrail Cloud), però és poc probable que pugueu baixar de VMWare. . Per a mi, aquestes dues solucions semblen així: Openstack (proveïdor) és una gàbia senzilla en la qual et posen, però tens una clau i pots marxar en qualsevol moment. VMWare és una gàbia daurada, el propietari té la clau de la gàbia i us costarà molt.
No estic promocionant ni el primer producte ni el segon: tu tries el que necessites. Però si tingués aquesta opció, triaria ambdues solucions: VMWare per al núvol informàtic (càrregues baixes, fàcil gestió), OpenStack d'algun proveïdor (Nokia i Juniper ofereixen solucions clau en mà molt bones) per al núvol de Telecom. No faria servir Openstack per a la informàtica pura: és com disparar pardals amb un canó, però no veig cap contraindicació per utilitzar-lo a part de la redundància. Tanmateix, utilitzar VMWare a les telecomunicacions és com transportar pedra picada en un Ford Raptor: és bonic des de fora, però el conductor ha de fer 10 viatges en lloc d'un.
Al meu entendre, el major desavantatge de VMWare és el seu tancament total: l'empresa no us donarà cap informació sobre com funciona, per exemple, vSAN o què hi ha al nucli de l'hipervisor, simplement no és rendible per a això, és a dir, mai no us convertiu en un expert en VMWare: sense suport del venedor, esteu condemnats (molt sovint em trobo amb experts de VMWare que es veuen desconcertats per preguntes trivials). Per a mi, VMWare està comprant un cotxe amb el capó bloquejat: sí, és possible que tinguis especialistes que puguin canviar la corretja de distribució, però només el que t'ha venut aquesta solució pot obrir el capó. Personalment, no m'agraden les solucions en les quals no puc encaixar. Diràs que potser no hauràs d'anar sota el capó. Sí, això és possible, però us miraré quan necessiteu muntar una funció gran al núvol a partir de 20-30 màquines virtuals, 40-50 xarxes, la meitat de les quals vol sortir a l'exterior i la segona meitat demana Acceleració SR-IOV, en cas contrari, necessitareu més d'un parell de dotzenes d'aquests cotxes; en cas contrari, el rendiment no serà suficient.
Hi ha altres punts de vista, així que només tu pots decidir què triar i, el més important, llavors seràs responsable de la teva elecció. Aquesta és només la meva opinió: una persona que ha vist i tocat almenys 4 productes: Nokia, Juniper, Red Hat i VMWare. És a dir, tinc alguna cosa amb què comparar.
Font: www.habr.com