A computación na nube está penetrando cada vez máis nas nosas vidas e probablemente non haxa unha soa persoa que non teña usado polo menos unha vez ningún servizo na nube. Non obstante, poucas persoas saben que é exactamente unha nube e como funciona, mesmo a nivel dunha idea. O 5G xa se está a converter nunha realidade e a infraestrutura de telecomunicacións comeza a pasar de solucións pilares a solucións na nube, do mesmo xeito que pasou de solucións completamente de hardware a "piares" virtualizados.
Hoxe falaremos do mundo interior da infraestrutura na nube, en particular, veremos os conceptos básicos da parte de rede.
Que é unha nube? A mesma virtualización - vista de perfil?
Máis que unha pregunta lóxica. Non, isto non é virtualización, aínda que non se podería facer sen ela. Vexamos dúas definicións:
Cloud computing (en diante Cloud) é un modelo para proporcionar un acceso fácil de usar aos recursos informáticos distribuídos que deben ser implantados e lanzados baixo demanda coa menor latencia posible e un custo mínimo para o provedor de servizos.
Virtualización - Esta é a capacidade de dividir unha entidade física (por exemplo, un servidor) en varias virtuais, aumentando así a utilización dos recursos (por exemplo, tiñas 3 servidores cargados ao 25-30 por cento, despois da virtualización tes 1 servidor cargado). nun 80-90 por cento). Por suposto, a virtualización consume algúns dos recursos: cómpre alimentar o hipervisor, pero, como demostrou a práctica, o xogo paga a pena. Un exemplo ideal de virtualización é VMWare, que prepara perfectamente as máquinas virtuais, ou por exemplo KVM, que prefiro, pero isto é cuestión de gustos.
Usamos a virtualización sen darnos conta, e mesmo os enrutadores de ferro xa usan a virtualización; por exemplo, na última versión de JunOS, o sistema operativo está instalado como unha máquina virtual encima dunha distribución Linux en tempo real (Wind River 9). Pero a virtualización non é a nube, pero a nube non pode existir sen virtualización.
A virtualización é un dos bloques de construción sobre os que se constrúe a nube.
Facer unha nube simplemente recollendo varios hipervisores nun dominio L2, engadindo un par de playbooks de yaml para rexistrar automaticamente vlans a través dalgún tipo de ansible e atascar algo así como un sistema de orquestración en todo para crear máquinas virtuais automaticamente non funcionará. Será máis preciso, pero o Frankenstein resultante non é a nube que necesitamos, aínda que pode ser o soño definitivo para outros. Ademais, se tomas o mesmo Openstack, é esencialmente Frankenstein, pero ben, non falemos diso por agora.
Pero entendo que a partir da definición presentada anteriormente non está do todo claro o que realmente se pode chamar nube.
Polo tanto, un documento do NIST (National Institute of Standards and Technology) proporciona 5 características principais que debe ter unha infraestrutura na nube:
Prestación de servizo baixo petición. O usuario debe ter acceso gratuíto aos recursos informáticos que se lle asignen (como redes, discos virtuais, memoria, núcleos de procesador, etc.), e estes recursos deben proporcionarse de forma automática, é dicir, sen intervención do provedor do servizo.
Ampla dispoñibilidade do servizo. O acceso aos recursos debe proporcionarse mediante mecanismos estándar que permitan o uso tanto de PC estándar como de clientes lixeiros e dispositivos móbiles.
Combinación de recursos en pools. As agrupacións de recursos deben poder proporcionar recursos a varios clientes ao mesmo tempo, garantindo que os clientes estean illados e libres de influencias e competencia mutuas polos recursos. As redes tamén se inclúen nos pools, o que indica a posibilidade de utilizar direccionamentos superpostos. As piscinas deben poder escalar segundo a demanda. O uso de pools permite proporcionar o nivel necesario de tolerancia a fallos de recursos e abstracción de recursos físicos e virtuais: o destinatario do servizo simplemente recibe o conxunto de recursos que solicitou (onde estes recursos están fisicamente situados, en cantos servidores e interruptores - non lle importa ao cliente). Non obstante, hai que ter en conta o feito de que o provedor debe garantir a reserva transparente destes recursos.
Adaptación rápida a diferentes condicións. Os servizos deben ser flexibles: subministración rápida de recursos, a súa redistribución, engadindo ou reducindo recursos a petición do cliente, e por parte do cliente debería haber a sensación de que os recursos da nube son infinitos. Para facilitar a comprensión, por exemplo, non ves unha advertencia de que parte do espazo do teu disco en Apple iCloud desapareceu porque o disco duro do servidor avaríase e as unidades si avarian. Ademais, pola túa banda, as posibilidades deste servizo son case ilimitadas -necesitas 2 TB- sen problema, pagaches e recibistes. Un exemplo similar pódese dar con Google.Drive ou Yandex.Disk.
Posibilidade de medir o servizo prestado. Os sistemas na nube deben controlar e optimizar automaticamente os recursos consumidos, e estes mecanismos deben ser transparentes tanto para o usuario como para o provedor do servizo. É dicir, sempre pode comprobar cantos recursos está a consumir vostede e os seus clientes.
Paga a pena ter en conta o feito de que estes requisitos son principalmente requisitos para unha nube pública, polo que para unha nube privada (é dicir, unha nube lanzada para as necesidades internas da empresa), estes requisitos pódense axustar lixeiramente. Non obstante, aínda teñen que facerse, se non, non conseguiremos todos os beneficios da computación na nube.
Por que necesitamos unha nube?
Non obstante, calquera tecnoloxía nova ou existente, calquera protocolo novo créase para algo (ben, excepto para RIP-ng, claro). Ninguén necesita un protocolo por mor dun protocolo (ben, salvo RIP-ng, claro). É lóxico que a Nube sexa creada para proporcionar algún tipo de servizo ao usuario/cliente. Todos estamos familiarizados con polo menos un par de servizos na nube, por exemplo Dropbox ou Google.Docs, e creo que a maioría da xente utilízaos con éxito; por exemplo, este artigo foi escrito usando o servizo na nube Google.Docs. Pero os servizos na nube que coñecemos son só parte das capacidades da nube; máis precisamente, son só un servizo de tipo SaaS. Podemos proporcionar un servizo na nube de tres formas: en forma de SaaS, PaaS ou IaaS. O servizo que necesita depende dos seus desexos e capacidades.
Vexamos cada un por orde:
Software como servizo (SaaS) é un modelo para ofrecer un servizo completo ao cliente, por exemplo, un servizo de correo electrónico como Yandex.Mail ou Gmail. Neste modelo de prestación de servizos, ti, como cliente, en realidade, non fas máis que usar os servizos, é dicir, non necesitas pensar na configuración do servizo, na súa tolerancia a fallos ou na súa redundancia. O principal é non comprometer o teu contrasinal; o provedor deste servizo fará o resto por ti. Desde o punto de vista do provedor de servizos, é totalmente responsable de todo o servizo, desde o hardware do servidor e os sistemas operativos do servidor ata a configuración de base de datos e software.
Plataforma como servizo (PaaS) — ao usar este modelo, o provedor de servizos proporciona ao cliente unha peza de traballo para o servizo, por exemplo, tomemos un servidor web. O provedor de servizos proporcionou ao cliente un servidor virtual (de feito, un conxunto de recursos, como RAM/CPU/Almacenamento/Redes, etc.), e mesmo instalou o SO e o software necesario neste servidor, non obstante, a configuración de todo isto faise polo propio cliente e para o desempeño do servizo responde o cliente. O provedor do servizo, como no caso anterior, é o responsable do rendemento dos equipos físicos, dos hipervisores, da propia máquina virtual, da súa dispoñibilidade de rede, etc., pero o servizo en si xa non está no seu ámbito de responsabilidade.
Infraestructura como servizo (IaaS) - este enfoque xa é máis interesante, de feito, o provedor de servizos proporciona ao cliente unha infraestrutura virtualizada completa, é dicir, algún conxunto (pool) de recursos, como núcleos de CPU, RAM, redes, etc. Todo o demais depende o cliente -o que o cliente quere facer con estes recursos dentro do pool asignado (cota)- non é especialmente importante para o provedor. Se o cliente quere crear o seu propio vEPC ou mesmo crear un mini operador e proporcionar servizos de comunicación, sen dúbida, faino. Neste escenario, o provedor de servizos é o responsable do aprovisionamento dos recursos, da súa tolerancia a fallos e da súa dispoñibilidade, así como do SO que lles permita agrupar estes recursos e poñelos a disposición do cliente coa posibilidade de aumentar ou diminuír os recursos en calquera momento. a petición do cliente. O cliente configura todas as máquinas virtuais e outros adornos a través do portal de autoservizo e da consola, incluída a configuración de redes (excepto as redes externas).
Que é OpenStack?
Nas tres opcións, o provedor de servizos necesita un SO que permita a creación dunha infraestrutura na nube. De feito, con SaaS, máis dunha división é responsable de toda a pila de tecnoloxías -hai unha división que se encarga da infraestrutura-, é dicir, proporciona IaaS a outra división, esta división proporciona SaaS ao cliente. OpenStack é un dos sistemas operativos na nube que che permite recoller unha morea de conmutadores, servidores e sistemas de almacenamento nun único grupo de recursos, dividir este grupo común en subgrupos (inquilinos) e proporcionar estes recursos aos clientes a través da rede.
OpenStack é un sistema operativo na nube que permite controlar grandes conxuntos de recursos informáticos, almacenamento de datos e recursos de rede, aprovisionados e xestionados mediante API mediante mecanismos de autenticación estándar.
Noutras palabras, trátase dun conxunto de proxectos de software libre deseñados para crear servizos na nube (tanto públicos como privados), é dicir, un conxunto de ferramentas que permiten combinar servidores e equipos de conmutación nun único conxunto de recursos, xestionar estes recursos, proporcionando o nivel necesario de tolerancia a fallos.
No momento de escribir este material, a estrutura de OpenStack ten o seguinte aspecto:
Imaxe tomada de
Cada un dos compoñentes incluídos en OpenStack realiza unha función específica. Esta arquitectura distribuída permite incluír na solución o conxunto de compoñentes funcionais que precisa. Non obstante, algúns compoñentes son compoñentes raíz e a súa eliminación levará á inoperabilidade total ou parcial da solución no seu conxunto. Estes compoñentes adoitan clasificarse como:
- panel de control — GUI baseada na web para xestionar os servizos de OpenStack
- Keystone é un servizo de identidade centralizado que ofrece funcionalidades de autenticación e autorización para outros servizos, así como xestionar as credenciais dos usuarios e os seus roles.
- Neutrón - un servizo de rede que proporciona conectividade entre as interfaces de varios servizos OpenStack (incluíndo a conectividade entre máquinas virtuales e o seu acceso ao mundo exterior)
- Cinder — proporciona acceso ao almacenamento en bloque para máquinas virtuais
- Nova — Xestión do ciclo de vida das máquinas virtuais
- Ollada — repositorio de imaxes e instantáneas de máquinas virtuais
- Rápido — proporciona acceso ao obxecto de almacenamento
- Ceilómetro — un servizo que ofrece a capacidade de recoller telemetría e medir os recursos dispoñibles e consumidos
- Calor — orquestración baseada en modelos para a creación e subministración automática de recursos
Pódese ver unha lista completa de todos os proxectos e o seu propósito .
Cada compoñente de OpenStack é un servizo que realiza unha función específica e proporciona unha API para xestionar esa función e interactuar con outros servizos do sistema operativo na nube para crear unha infraestrutura unificada. Por exemplo, Nova ofrece xestión de recursos informáticos e unha API para acceder á configuración destes recursos, Glance ofrece xestión de imaxes e unha API para xestionalos, Cinder ofrece almacenamento en bloque e unha API para xestionalos, etc. Todas as funcións están interconectadas dun xeito moi próximo.
Non obstante, se o miras, todos os servizos que se executan en OpenStack son, en definitiva, algún tipo de máquina virtual (ou contedor) conectada á rede. Xorde a pregunta: por que necesitamos tantos elementos?
Imos pasar polo algoritmo para crear unha máquina virtual e conectala á rede e ao almacenamento persistente en Openstack.
- Cando crea unha solicitude para crear unha máquina, xa sexa unha solicitude a través de Horizon (Panel de control) ou unha solicitude a través da CLI, o primeiro que ocorre é a autorización da súa solicitude en Keystone: pode crear unha máquina, se ten o dereito a usar esta rede, fai o teu borrador de cota, etc.
- Keystone autentica a túa solicitude e xera un token de autenticación na mensaxe de resposta, que se utilizará aínda máis. Tras recibir unha resposta de Keystone, a solicitude envíase a Nova (nova api).
- Nova-api comproba a validez da túa solicitude contactando con Keystone mediante o token de autenticación xerado anteriormente
- Keystone realiza a autenticación e ofrece información sobre permisos e restricións baseados neste token de autenticación.
- Nova-api crea unha entrada para a nova máquina virtual en nova-database e pasa a solicitude para crear a máquina a nova-scheduler.
- Nova-scheduler selecciona o host (nodo informático) no que se despregará a máquina virtual en función dos parámetros, pesos e zonas especificados. Un rexistro deste e o ID de VM escríbense en nova-database.
- A continuación, nova-scheduler contacta con nova-compute cunha solicitude para implementar unha instancia. Nova-compute contacta con nova-conductor para obter información sobre os parámetros da máquina (nova-conductor é un elemento nova que actúa como servidor proxy entre nova-database e nova-compute, limitando o número de solicitudes a nova-database para evitar problemas coa base de datos). redución da carga de consistencia).
- Nova-conductor recibe a información solicitada da nova-database e pásaa a nova-compute.
- A continuación, nova-compute chama a vistazo para obter o ID da imaxe. Glace valida a solicitude en Keystone e devolve a información solicitada.
- Nova-compute contacta con neutróns para obter información sobre os parámetros da rede. Do mesmo xeito que Glance, Neutron valida a solicitude en Keystone, despois de que crea unha entrada na base de datos (identificador de porto, etc.), crea unha solicitude para crear un porto e devolve a información solicitada a nova-compute.
- Nova-compute contacta cinder cunha solicitude para asignar un volume á máquina virtual. Do mesmo xeito que Glance, sidra valida a solicitude en Keystone, crea unha solicitude de creación de volume e devolve a información solicitada.
- Nova-compute contacta con libvirt cunha solicitude para implementar unha máquina virtual cos parámetros especificados.
De feito, unha operación aparentemente sinxela de crear unha máquina virtual sinxela convértese nun remuíño de chamadas API entre elementos da plataforma na nube. Ademais, como podes ver, incluso os servizos anteriormente designados tamén constan de compoñentes máis pequenos entre os que se produce a interacción. Crear unha máquina é só unha pequena parte do que permite facer a plataforma na nube: hai un servizo encargado de equilibrar o tráfico, un servizo responsable do almacenamento en bloque, un servizo responsable do DNS, un servizo responsable do aprovisionamento de servidores bare metal, etc. A nube permite que trates as túas máquinas virtuais como un rabaño de ovellas (en oposición á virtualización). Se ocorre algo coa túa máquina nun ambiente virtual: restauras a partir de copias de seguridade, etc., pero as aplicacións na nube están construídas de tal xeito que a máquina virtual non xoga un papel tan importante - a máquina virtual "morreu" - non hai problema - Acaba de crearse un novo, o vehículo está baseado no modelo e, como din, o escuadrón non se decatou da perda do loitador. Por suposto, isto prevé a presenza de mecanismos de orquestración: usando modelos de Heat, pode implementar facilmente unha función complexa formada por decenas de redes e máquinas virtuais.
Sempre vale a pena ter en conta que non hai infraestrutura na nube sen rede: cada elemento interactúa dun xeito ou doutro con outros elementos a través da rede. Ademais, a nube ten unha rede absolutamente non estática. Por suposto, a rede subxacente é aínda máis ou menos estática: non se engaden novos nodos e conmutadores todos os días, pero o compoñente de superposición pode e inevitablemente cambiará constantemente: engadiranse ou eliminaranse novas redes, aparecerán novas máquinas virtuais e as antigas. morrer. E como lembras pola definición da nube dada ao comezo do artigo, os recursos deberían asignarse ao usuario de forma automática e coa menor (ou mellor aínda, sen) intervención do provedor do servizo. É dicir, o tipo de subministración de recursos de rede que agora existe en forma de frontend en forma de conta persoal accesible a través de http/https e o enxeñeiro de rede de servizo Vasily como backend non é unha nube, nin sequera se Vasily ten oito mans.
Neutron, como servizo de rede, ofrece unha API para xestionar a parte da rede da infraestrutura na nube. O servizo potencia e xestiona a parte de rede de Openstack proporcionando unha capa de abstracción chamada Network-as-a-Service (NaaS). É dicir, a rede é a mesma unidade virtual medible que, por exemplo, os núcleos virtuais de CPU ou a cantidade de RAM.
Pero antes de pasar á arquitectura da parte de rede de OpenStack, consideremos como funciona esta rede en OpenStack e por que a rede é unha parte importante e integral da nube.
Polo tanto, temos dúas máquinas virtuales cliente RED e dúas máquinas virtuales cliente VERDE. Supoñamos que estas máquinas están situadas en dous hipervisores deste xeito:
Polo momento, isto é só virtualización de 4 servidores e nada máis, xa que ata agora o único que fixemos é virtualizar 4 servidores, colocándoos en dous servidores físicos. E ata agora nin sequera están conectados á rede.
Para facer unha nube, necesitamos engadir varios compoñentes. En primeiro lugar, virtualizamos a parte da rede: necesitamos conectar estas 4 máquinas en pares e os clientes queren unha conexión L2. Podes usar un interruptor e configurar un tronco na súa dirección e resolvelo todo usando unha ponte de linux ou, para usuarios máis avanzados, openvswitch (volveremos sobre isto máis adiante). Pero pode haber moitas redes, e presionar constantemente a L2 a través dun interruptor non é a mellor idea: hai diferentes departamentos, unha mesa de servizo, meses de espera para que se complete unha aplicación, semanas de resolución de problemas, no mundo moderno isto enfoque xa non funciona. E canto antes o entenda unha empresa, máis doado é que avance. Polo tanto, entre os hipervisores seleccionaremos unha rede L3 a través da cal se comunicarán as nosas máquinas virtuais, e enriba desta rede L3 construiremos redes de superposición L2 virtuais onde se executará o tráfico das nosas máquinas virtuais. Podes usar GRE, Geneve ou VxLAN como encapsulación. Centrémonos neste último por agora, aínda que non é especialmente importante.
Necesitamos localizar VTEP nalgún lugar (espero que todos estean familiarizados coa terminoloxía de VxLAN). Xa que temos unha rede L3 procedente directamente dos servidores, nada nos impide colocar VTEP nos propios servidores, e OVS (OpenvSwitch) é excelente para facelo. Como resultado, obtivemos este deseño:
Dado que o tráfico entre máquinas virtuales debe dividirse, os portos cara ás máquinas virtuais terán diferentes números de vlan. O número de etiqueta xoga un papel só dentro dun interruptor virtual, xa que cando está encapsulado en VxLAN podemos eliminalo facilmente, xa que teremos un VNI.
Agora podemos crear as nosas máquinas e redes virtuais para elas sen ningún problema.
Non obstante, que pasa se o cliente ten outra máquina, pero está nunha rede diferente? Necesitamos enraizamento entre redes. Observaremos unha opción sinxela cando se utilice o enrutamento centralizado, é dicir, o tráfico envíase a través de nós de rede dedicados especiais (ben, por regra xeral, combínanse con nós de control, polo que teremos o mesmo).
Parece que non é nada complicado: facemos unha interface ponte no nodo de control, diriximos o tráfico a el e desde alí encamiñamos onde o necesitamos. Pero o problema é que o cliente RED quere usar a rede 10.0.0.0/24 e o cliente VERDE quere usar a rede 10.0.0.0/24. É dicir, comezamos a cruzar espazos de enderezos. Ademais, os clientes non queren que outros clientes poidan enrutar ás súas redes internas, o que ten sentido. Para separar as redes e o tráfico de datos do cliente, asignaremos un espazo de nomes separado para cada unha delas. O espazo de nomes é de feito unha copia da pila de rede de Linux, é dicir, os clientes do espazo de nomes RED están completamente illados dos clientes do espazo de nomes VERDE (ben, o enrutamento entre estas redes de clientes está permitido a través do espazo de nomes predeterminado ou no equipo de transporte ascendente).
É dicir, obtemos o seguinte diagrama:
Os túneles L2 converxen desde todos os nodos de computación ata o nodo de control. nodo onde se atopa a interface L3 destas redes, cada unha nun espazo de nomes dedicado para o illamento.
Porén, esquecemos o máis importante. A máquina virtual debe proporcionar un servizo ao cliente, é dicir, debe ter polo menos unha interface externa a través da cal se poida acceder. É dicir, temos que saír ao mundo exterior. Aquí hai diferentes opcións. Imos facer a opción máis sinxela. Engadiremos unha rede a cada cliente, que será válida na rede do provedor e non se solapará con outras redes. As redes tamén poden cruzarse e mirar diferentes VRF ao lado da rede do provedor. Os datos da rede tamén vivirán no espazo de nomes de cada cliente. Non obstante, aínda sairán ao mundo exterior a través dunha interface física (ou enlace, o que é máis lóxico). Para separar o tráfico do cliente, o tráfico que vai fóra etiquetarase cunha etiqueta VLAN asignada ao cliente.
Como resultado, obtivemos este diagrama:
Unha pregunta razoable é por que non facer pasarelas nos propios nodos de cómputo? Este non é un gran problema; ademais, se activas o enrutador distribuído (DVR), isto funcionará. Neste escenario, estamos considerando a opción máis sinxela cunha pasarela centralizada, que se usa por defecto en Openstack. Para funcións de alta carga, utilizarán tanto un enrutador distribuído como tecnoloxías de aceleración como SR-IOV e Passthrough, pero como din, esa é unha historia completamente diferente. Primeiro, imos tratar a parte básica, e despois entraremos nos detalles.
En realidade, o noso esquema xa é viable, pero hai un par de matices:
- Necesitamos protexer dalgunha maneira as nosas máquinas, é dicir, poñer un filtro na interface do interruptor cara ao cliente.
- Fai posible que unha máquina virtual obteña automaticamente un enderezo IP, para que non teñas que iniciar sesión a través da consola cada vez e rexistrar o enderezo.
Comecemos coa protección da máquina. Para iso podes usar iptables banais, por que non.
É dicir, agora a nosa topoloxía volveuse un pouco máis complicada:
Sigamos adiante. Necesitamos engadir un servidor DHCP. O lugar máis ideal para localizar servidores DHCP para cada cliente sería o nodo de control xa mencionado anteriormente, onde se atopan os espazos de nomes:
Non obstante, hai un pequeno problema. E se todo se reinicia e desaparece toda a información sobre o aluguer de enderezos en DHCP. É lóxico que as máquinas reciban novos enderezos, o que non é moi cómodo. Hai dous xeitos de saír aquí - ou usar nomes de dominio e engadir un servidor DNS para cada cliente, entón o enderezo non será especialmente importante para nós (semellante á parte da rede en k8s) - pero hai un problema coas redes externas, xa que Tamén se poden emitir enderezos neles a través de DHCP: precisa sincronización con servidores DNS na plataforma de nube e un servidor DNS externo, que na miña opinión non é moi flexible, pero é bastante posible. Ou a segunda opción é usar metadatos, é dicir, gardar información sobre o enderezo emitido á máquina para que o servidor DHCP saiba que enderezo enviar á máquina se a máquina xa recibiu un enderezo. A segunda opción é máis sinxela e flexible, xa que permite gardar información adicional sobre o coche. Agora imos engadir metadatos do axente ao diagrama:
Outra cuestión que tamén paga a pena discutir é a capacidade de usar unha rede externa por parte de todos os clientes, xa que as redes externas, se deben ser válidas en toda a rede, serán difíciles: cómpre asignar e controlar constantemente a asignación destas redes. A posibilidade de utilizar unha única rede externa preconfigurada para todos os clientes será moi útil á hora de crear unha nube pública. Isto facilitará a implantación de máquinas porque non temos que consultar unha base de datos de enderezos e seleccionar un espazo de enderezos único para a rede externa de cada cliente. Ademais, podemos rexistrar unha rede externa previamente e no momento da implantación só necesitaremos asociar enderezos externos ás máquinas cliente.
E aquí NAT vén na nosa axuda: só faremos posible que os clientes accedan ao mundo exterior a través do espazo de nomes predeterminado mediante a tradución NAT. Ben, aquí hai un pequeno problema. Isto é bo se o servidor cliente actúa como cliente e non como servidor, é dicir, inicia conexións en lugar de aceptar. Pero para nós será ao revés. Neste caso, necesitamos facer o NAT de destino para que ao recibir tráfico, o nodo de control entenda que este tráfico está destinado á máquina virtual A do cliente A, o que significa que debemos facer unha tradución NAT desde un enderezo externo, por exemplo 100.1.1.1. .10.0.0.1, a un enderezo interno 100. Neste caso, aínda que todos os clientes usarán a mesma rede, o illamento interno consérvase por completo. É dicir, necesitamos facer dNAT e sNAT no nodo de control. Se usar unha única rede con enderezos flotantes ou redes externas, ou ambas á vez, depende do que queiras incorporar á nube. Non engadiremos enderezos flotantes ao diagrama, pero deixaremos as redes externas xa engadidas anteriormente: cada cliente ten a súa propia rede externa (no diagrama indícanse como vlan 200 e XNUMX na interface externa).
Como resultado, recibimos unha solución interesante e ao mesmo tempo pensada, que ten certa flexibilidade pero que aínda non dispón de mecanismos de tolerancia a fallos.
En primeiro lugar, só temos un nodo de control: o seu fallo levará ao colapso de todos os sistemas. Para solucionar este problema, cómpre facer polo menos un quórum de 3 nós. Engadimos isto ao diagrama:
Por suposto, todos os nodos están sincronizados e cando un nodo activo sae, outro nodo asumirá as súas responsabilidades.
O seguinte problema son os discos das máquinas virtuais. Polo momento, almacénanse nos propios hipervisores e, en caso de problemas co hipervisor, perdemos todos os datos e a presenza dunha incursión non axudará aquí se non perdemos o disco, senón todo o servidor. Para iso, necesitamos facer un servizo que actúe como frontend para algún tipo de almacenamento. O tipo de almacenamento que será non é especialmente importante para nós, pero debería protexer os nosos datos contra fallos tanto do disco como do nodo, e posiblemente de todo o gabinete. Aquí hai varias opcións - hai, por suposto, redes SAN con Fibre Channel, pero sexamos sinceros - FC xa é unha reliquia do pasado - un análogo de E1 no transporte - si, estou de acordo, aínda se usa, pero só onde é absolutamente imposible sen el. Polo tanto, non implantaría voluntariamente unha rede FC en 2020, sabendo que hai outras alternativas máis interesantes. Aínda que para cada un o seu, pode haber quen crea que o FC con todas as súas limitacións é todo o que necesitamos - non vou discutir, cada un ten a súa propia opinión. Non obstante, a solución máis interesante na miña opinión é utilizar unha SDS, como Ceph.
Ceph permítelle construír unha solución de almacenamento de datos de alta dispoñibilidade cunha morea de posibles opcións de copia de seguridade, comezando por códigos con comprobación de paridade (análoga ao raid 5 ou 6) e rematando coa replicación completa de datos en diferentes discos, tendo en conta a localización dos discos en servidores, e servidores en armarios, etc.
Para construír Ceph necesitas 3 nodos máis. A interacción co almacenamento tamén se realizará a través da rede mediante servizos de almacenamento de bloques, obxectos e ficheiros. Engadimos almacenamento ao esquema:
Nota: tamén podes facer nodos de cálculo hiperconverxentes (este é o concepto de combinar varias funcións nun nodo, por exemplo, almacenamento+compute), sen dedicar nós especiais para o almacenamento de ceph. Obteremos o mesmo esquema tolerante a fallos, xa que SDS reservará datos co nivel de reserva que especificamos. Non obstante, os nodos hiperconverxentes son sempre un compromiso, xa que o nodo de almacenamento non só quenta o aire como parece a primeira vista (xa que non hai máquinas virtuais nel), gasta os recursos da CPU no servizo de SDS (de feito, fai todo). a replicación e recuperación tras fallos de nodos, discos, etc.). É dicir, perderás parte da potencia do nodo de cómputo se o combinas co almacenamento.
Todo este material debe ser xestionado dalgún xeito: necesitamos algo a través do cal poidamos crear unha máquina, unha rede, un enrutador virtual, etc. Para iso, engadiremos un servizo ao nodo de control que actuará como panel: o o cliente poderá conectarse a este portal a través de http/ https e facer todo o que necesite (ben, case).
Como resultado, agora temos un sistema tolerante a fallos. Todos os elementos desta infraestrutura deben ser xestionados dalgún xeito. Describiuse anteriormente que Openstack é un conxunto de proxectos, cada un dos cales proporciona unha función específica. Como vemos, hai elementos máis que suficientes que hai que configurar e controlar. Hoxe falaremos da parte da rede.
Arquitectura de neutrones
En OpenStack, é Neutron quen se encarga de conectar os portos de máquinas virtuais a unha rede común L2, garantindo o enrutamento do tráfico entre máquinas virtuales situadas en diferentes redes L2, así como o enrutamento exterior, proporcionando servizos como NAT, Floating IP, DHCP, etc.
A un alto nivel, o funcionamento do servizo de rede (a parte básica) pódese describir do seguinte xeito.
Ao iniciar a máquina virtual, o servizo de rede:
- Crea un porto para unha VM (ou portos) determinadas e notifica ao servizo DHCP respecto diso;
- Créase un novo dispositivo de rede virtual (a través de libvirt);
- A máquina virtual conéctase aos portos creados no paso 1;
Curiosamente, o traballo de Neutron está baseado en mecanismos estándar coñecidos por todos os que se mergullaron algunha vez en Linux: espazos de nomes, iptables, linux bridges, openvswitch, conntrack, etc.
Debe aclararse inmediatamente que Neutron non é un controlador SDN.
O neutrón consta de varios compoñentes interconectados:
Servidor de neutrones Openstack é un daemon que funciona coas solicitudes dos usuarios a través da API. Este demo non participa no rexistro de ningunha conexión de rede, pero proporciona a información necesaria para iso aos seus complementos, que logo configuran o elemento de rede desexado. Os axentes de neutróns nos nodos de OpenStack rexístranse no servidor Neutron.
Neutron-server é en realidade unha aplicación escrita en python, que consta de dúas partes:
- Servizo REST
- Plugin Neutron (núcleo/servizo)
O servizo REST está deseñado para recibir chamadas de API doutros compoñentes (por exemplo, unha solicitude para proporcionar algunha información, etc.)
Os complementos son compoñentes/módulos de software complementarios que se chaman durante as solicitudes da API, é dicir, a asignación dun servizo prodúcese a través deles. Os complementos divídense en dous tipos: servizo e root. Como regra xeral, o complemento de cabalo é o principal responsable de xestionar o espazo de enderezos e as conexións L2 entre máquinas virtuales, e os complementos de servizo xa ofrecen funcionalidades adicionais como VPN ou FW.
A lista de complementos dispoñibles hoxe pódese ver, por exemplo
Pode haber varios complementos de servizo, pero só pode haber un complemento de cabalo.
openstack-neutron-ml2 é o complemento raíz estándar de Openstack. Este complemento ten unha arquitectura modular (a diferenza do seu predecesor) e configura o servizo de rede a través de controladores conectados a el. Miraremos o propio complemento un pouco máis tarde, xa que de feito dá a flexibilidade que ten OpenStack na parte da rede. O complemento raíz pódese substituír (por exemplo, Contrail Networking fai tal substitución).
Servizo RPC (servidor rabbitmq) — un servizo que ofrece xestión de filas e interacción con outros servizos OpenStack, así como interacción entre axentes de servizos de rede.
Axentes da rede — axentes que están situados en cada nodo, a través dos cales se configuran os servizos de rede.
Hai varios tipos de axentes.
O axente principal é Axente L2. Estes axentes execútanse en cada un dos hipervisores, incluídos os nodos de control (máis precisamente, en todos os nodos que prestan algún servizo aos inquilinos) e a súa función principal é conectar as máquinas virtuais a unha rede L2 común, e tamén xerar alertas cando se produza algún evento ( por exemplo, desactivar/activar o porto).
O seguinte, non menos importante axente é Axente L3. De forma predeterminada, este axente execútase exclusivamente nun nodo de rede (moitas veces o nodo de rede combínase cun nodo de control) e proporciona enrutamento entre redes de inquilinos (tanto entre as súas redes como as doutros inquilinos, e é accesible para o mundo exterior, proporcionando NAT, así como o servizo DHCP). Non obstante, cando se usa un DVR (router distribuído), a necesidade dun complemento L3 tamén aparece nos nodos de cálculo.
O axente L3 usa espazos de nomes de Linux para proporcionar a cada inquilino un conxunto de redes illadas propias e a funcionalidade dos enrutadores virtuais que encamiñan o tráfico e proporcionan servizos de pasarela para redes de capa 2.
Base de datos — unha base de datos de identificadores de redes, subredes, portos, pools, etc.
De feito, Neutron acepta solicitudes de API desde a creación de calquera entidade de rede, autentica a solicitude e a través de RPC (se accede a algún complemento ou axente) ou a API REST (se se comunica en SDN) transmite aos axentes (a través de complementos) o instrucións necesarias para organizar o servizo solicitado.
Agora imos pasar á instalación de proba (como se desprega e que inclúe nela, veremos máis adiante na parte práctica) e vexamos onde se atopa cada compoñente:
(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 ~]$
En realidade, esa é toda a estrutura de Neutron. Agora paga a pena dedicar un tempo ao complemento ML2.
Capa modular 2
Como se mencionou anteriormente, o complemento é un complemento raíz estándar de OpenStack e ten unha arquitectura modular.
O predecesor do complemento ML2 tiña unha estrutura monolítica, que non permitía, por exemplo, usar unha mestura de varias tecnoloxías nunha instalación. Por exemplo, non pode usar tanto openvswitch como linuxbridge ao mesmo tempo, nin o primeiro nin o segundo. Por este motivo, creouse o complemento ML2 coa súa arquitectura.
ML2 ten dous compoñentes: dous tipos de controladores: controladores de tipo e controladores de mecanismo.
Tipo de controladores determinar as tecnoloxías que se utilizarán para organizar as conexións de rede, por exemplo VxLAN, VLAN, GRE. Ao mesmo tempo, o controlador permite o uso de diferentes tecnoloxías. A tecnoloxía estándar é a encapsulación VxLAN para redes de superposición e redes externas vlan.
Os controladores de tipo inclúen os seguintes tipos de rede:
Plan - rede sen etiquetar
VLAN - rede etiquetada
Local — un tipo especial de rede para instalacións todo-en-un (estas instalacións son necesarias para desenvolvedores ou para formación)
GRE - superposición de rede mediante túneles GRE
VxLAN - superposición de rede mediante túneles VxLAN
Condutores de mecanismos definir ferramentas que garantan a organización das tecnoloxías especificadas no controlador de tipo, por exemplo, openvswitch, sr-iov, opendaylight, OVN, etc.
Dependendo da implantación deste controlador, empregaranse ou ben axentes controlados por Neutron, ou ben se utilizarán conexións a un controlador SDN externo, que se encarga de todas as cuestións relacionadas coa organización de redes L2, enrutamento, etc.
Exemplo: se usamos ML2 xunto con OVS, entón un axente L2 está instalado en cada nodo informático que xestiona OVS. Non obstante, se usamos, por exemplo, OVN ou OpenDayLight, entón o control de OVS está baixo a súa xurisdición: Neutron, a través do complemento raíz, dá comandos ao controlador e xa fai o que lle indicaron.
Repasemos o Open vSwitch
Polo momento, un dos compoñentes clave de OpenStack é Open vSwitch.
Ao instalar OpenStack sen ningún SDN de provedor adicional, como Juniper Contrail ou Nokia Nuage, OVS é o principal compoñente de rede da rede de nube e, xunto con iptables, conntrack, espazos de nomes, permítelle organizar redes de superposición de multitenencia completas. Por suposto, este compoñente pódese substituír, por exemplo, cando se usan solucións SDN propietarias de terceiros (proveedores).
OVS é un conmutador de software de código aberto que está deseñado para o seu uso en ambientes virtualizados como reenviador de tráfico virtual.
Polo momento, OVS ten unha funcionalidade moi decente, que inclúe tecnoloxías como QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, etc.
Nota: OVS non se concibiu inicialmente como un interruptor suave para funcións de telecomunicacións moi cargadas e foi máis deseñado para funcións informáticas que requiren menos ancho de banda, como o servidor WEB ou o servidor de correo. Non obstante, OVS estase a desenvolver aínda máis e as implementacións actuais de OVS melloraron moito o seu rendemento e as súas capacidades, o que permite que o usen operadores de telecomunicacións con funcións moi cargadas, por exemplo, existe unha implementación de OVS con soporte para a aceleración DPDK.
Hai tres compoñentes importantes de OVS que debes ter en conta:
- Módulo do núcleo — un compoñente situado no espazo do núcleo que procesa o tráfico en función das regras recibidas do elemento de control;
- vSwitch daemon (ovs-vswitchd) é un proceso lanzado no espazo do usuario que se encarga de programar o módulo do núcleo, é dicir, representa directamente a lóxica do funcionamento do interruptor.
- Servidor de base de datos - unha base de datos local situada en cada host que executa OVS, na que se almacena a configuración. Os controladores SDN poden comunicarse a través deste módulo mediante o protocolo OVSDB.
Todo isto vai acompañado dun conxunto de utilidades de diagnóstico e xestión, como ovs-vsctl, ovs-appctl, ovs-ofctl, etc.
Actualmente, Openstack é amplamente utilizado polos operadores de telecomunicacións para migrar funcións de rede a el, como EPC, SBC, HLR, etc. Algunhas funcións poden vivir sen problemas con OVS tal e como está, pero por exemplo, EPC procesa o tráfico de subscritores; despois pasa por unha enorme cantidade de tráfico (agora os volumes de tráfico alcanzan varios centos de gigabits por segundo). Por suposto, dirixir ese tráfico a través do espazo do núcleo (xa que o reenviador está situado alí por defecto) non é a mellor idea. Polo tanto, OVS adoita despregarse enteiramente no espazo do usuario mediante a tecnoloxía de aceleración DPDK para reenviar o tráfico da NIC ao espazo do usuario evitando o núcleo.
Nota: para unha nube implantada para funcións de telecomunicacións, é posible emitir o tráfico dun nodo de cómputo sen pasar OVS directamente ao equipo de conmutación. Para este fin úsanse mecanismos SR-IOV e de paso.
Como funciona isto nun deseño real?
Pois agora pasemos á parte práctica e vexamos como funciona todo na práctica.
Primeiro, imos implementar unha instalación sinxela de Openstack. Como non teño un conxunto de servidores a man para os experimentos, montaremos o prototipo nun servidor físico desde máquinas virtuais. Si, naturalmente, tal solución non é adecuada para fins comerciais, pero para ver un exemplo de como funciona a rede en Openstack, unha instalación deste tipo é suficiente para os ollos. Ademais, esta instalación é aínda máis interesante para fins de adestramento, xa que pode atrapar tráfico, etc.
Dado que só necesitamos ver a parte básica, non podemos usar varias redes senón elevar todo usando só dúas redes, e a segunda rede deste deseño empregarase exclusivamente para o acceso ao subcloud e ao servidor DNS. Non imos tocar as redes externas polo momento - este é un tema para un artigo grande separado.
Entón, imos comezar en orde. Primeiro, un pouco de teoría. Instalaremos Openstack usando TripleO (Openstack en Openstack). A esencia de TripleO é que instalamos Openstack todo en un (é dicir, nun nodo), chamado undercloud, e despois utilizamos as capacidades do Openstack despregado para instalar Openstack destinado a funcionar, chamado overcloud. Undercloud utilizará a súa capacidade inherente para xestionar servidores físicos (bare metal) -o proxecto Ironic- para proporcionar hipervisores que desempeñarán as funcións de nodos de cómputo, control e almacenamento. É dicir, non usamos ningunha ferramenta de terceiros para implementar Openstack; implantamos Openstack mediante Openstack. Será moito máis claro a medida que avance a instalación, polo que non nos deteremos aí e avanzaremos.
Nota: neste artigo, por razóns de simplicidade, non usei o illamento de rede para as redes internas de Openstack, pero todo se desprega usando só unha rede. Non obstante, a presenza ou ausencia de illamento da rede non afecta a funcionalidade básica da solución: todo funcionará exactamente igual que cando se usa o illamento, pero o tráfico fluirá pola mesma rede. Para unha instalación comercial, é naturalmente necesario usar o illamento mediante vlans e interfaces diferentes. Por exemplo, o tráfico de xestión de almacenamento de ceph e o tráfico de datos en si (acceso da máquina a discos, etc.) cando illado utilizan diferentes subredes (xestión de almacenamento e almacenamento) e isto permítelle facer que a solución sexa máis tolerante a fallas dividindo este tráfico, por exemplo. , a través de diferentes portos ou utilizando diferentes perfís de QoS para diferentes tráficos para que o tráfico de datos non exprimir o tráfico de sinalización. No noso caso, irán á mesma rede e de feito isto non nos limita de ningún xeito.
Nota: xa que imos executar máquinas virtuais nun ambiente virtual baseado en máquinas virtuais, primeiro necesitamos activar a virtualización aniñada.
Podes comprobar se a virtualización aniñada está activada ou non así:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Se ves a letra N, activaremos o soporte para a virtualización aniñada segundo calquera guía que atopes na rede, por exemplo .
Necesitamos montar o seguinte circuíto desde máquinas virtuais:
No meu caso, para conectar as máquinas virtuais que forman parte da futura instalación (e conseguín 7 delas, pero con 4 podes saír adiante se non tes moitos recursos), usei OpenvSwitch. Creei unha ponte ovs e conectei máquinas virtuais a ela a través de grupos de portos. Para iso, creei un ficheiro xml como este:
[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í decláranse tres grupos de portos: dous de acceso e un tronco (este último era necesario para o servidor DNS, pero pode prescindir del, ou instalalo na máquina anfitrión, o que sexa máis conveniente para vostede). A continuación, usando este modelo, declaramos o noso 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 Agora editamos as configuracións do porto do 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: neste escenario, o enderezo do porto ovs-br1 non será accesible porque non ten unha etiqueta vlan. Para solucionar isto, cómpre emitir o comando sudo ovs-vsctl set port ovs-br1 tag=100. Non obstante, despois dun reinicio, esta etiqueta desaparecerá (se alguén sabe como facelo permanecer no seu lugar, estarei moi agradecido). Pero isto non é tan importante, porque só necesitaremos este enderezo durante a instalación e non o necesitaremos cando Openstack estea totalmente implantado.
A continuación, creamos unha máquina undercloud:
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=ttyS0Durante a instalación, establece todos os parámetros necesarios, como o nome da máquina, contrasinais, usuarios, servidores ntp, etc., pode configurar inmediatamente os portos, pero para min persoalmente, despois da instalación, é máis fácil iniciar sesión na máquina a través de a consola e corrixa os ficheiros necesarios. Se xa tes unha imaxe preparada, podes usala ou facer o que fixen: descarga a imaxe mínima de Centos 7 e utilízaa para instalar a máquina virtual.
Despois da instalación exitosa, deberías ter unha máquina virtual na que poidas instalar undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningEn primeiro lugar, instale as ferramentas necesarias para o proceso de instalación:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalación undercloud
Creamos un usuario de pila, establecemos un contrasinal, engadímolo a sudoer e dámoslle a posibilidade de executar comandos root a través de sudo sen ter que introducir un contrasinal:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackAgora especificamos o nome completo do subcloud no ficheiro 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ón, engadimos repositorios e instalamos o software que necesitamos:
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: se non planeas instalar ceph, non necesitas introducir comandos relacionados con ceph. Usei a versión de Queens, pero podes usar calquera outra que che guste.
A continuación, copie o ficheiro de configuración de undercloud na pila de directorios de inicio do usuario:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confAgora necesitamos corrixir este ficheiro, axustándoo á nosa instalación.
Debe engadir estas liñas ao comezo do ficheiro:
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 = 10Entón, imos pasar pola configuración:
undercloud_hostname — o nome completo do servidor undercloud, debe coincidir coa entrada do servidor DNS
ip_local — enderezo de subcloud local para o aprovisionamento da rede
pasarela_de_rede — o mesmo enderezo local, que actuará como pasarela de acceso ao mundo exterior durante a instalación de nodos de overcloud, tamén coincide coa ip local
undercloud_public_host — enderezo API externo, asígnase calquera enderezo gratuíto da rede de aprovisionamento
undercloud_admin_host enderezo interno da API, asígnase calquera enderezo gratuíto da rede de aprovisionamento
servidores de nomes_subcloud - Servidor DNS
xerar_certificado_de_servizo - esta liña é moi importante no exemplo actual, porque se non a configuras como false, recibirás un erro durante a instalación, o problema descríbese no rastreador de erros de Red Hat
interface_local interface no aprovisionamento de rede. Esta interface volverase a configurar durante a implementación de subcloud, polo que debes ter dúas interfaces en undercloud: unha para acceder a ela e a segunda para aprovisionar
local_mtu - MTU. Como temos un laboratorio de probas e teño un MTU de 1500 nos portos do switch OVS, é necesario configuralo en 1450 para que os paquetes encapsulados en VxLAN poidan pasar.
rede_cidr - Rede de aprovisionamento
disfrazado — usar NAT para acceder a unha rede externa
rede_mascarada - rede que será NATed
dhcp_start — o enderezo inicial do grupo de enderezos desde o que se asignarán os enderezos aos nodos durante a implantación de overcloud
dhcp_end — o enderezo final do grupo de enderezos desde o que se asignarán os enderezos aos nodos durante a implantación de overcloud
inspección_iprange — un conxunto de enderezos necesarios para a introspección (non se deben solapar co grupo anterior)
scheduler_max_attempts — número máximo de intentos de instalar overcloud (debe ser maior ou igual ao número de nodos)
Despois de que se describa o ficheiro, pode dar o comando para implementar undercloud:
openstack undercloud install
O procedemento leva de 10 a 30 minutos dependendo do seu ferro. En definitiva, deberías ver unha saída como esta:
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.
#############################################################################Esta saída indica que instalou con éxito o undercloud e agora pode comprobar o estado do undercloud e proceder á instalación de overcloud.
Se miras a saída de ifconfig, verás que apareceu unha nova interface ponte
[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 0A implantación de overcloud agora realizarase a través desta interface.
A partir da seguinte saída podes ver que temos todos os servizos nun nodo:
(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ón móstrase a configuración da parte da rede 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 ~]$Instalación de overcloud
Polo momento só temos undercloud e non temos suficientes nodos desde os que se montará overcloud. Polo tanto, en primeiro lugar, implementemos as máquinas virtuais que necesitamos. Durante a implementación, o propio undercloud instalará o sistema operativo e o software necesario na máquina de overcloud, é dicir, non necesitamos implementar completamente a máquina, senón que só creamos un disco (ou discos) para ela e determinamos os seus parámetros, é dicir. , de feito, temos un servidor pelado sen un sistema operativo instalado.
Imos ao cartafol cos discos das nosas máquinas virtuais e creemos discos do tamaño necesario:
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 160GDado que estamos operando como root, necesitamos cambiar o propietario destes discos para non ter problemas cos dereitos:
[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: se non pensas instalar ceph para estudalo, os comandos non crean polo menos 3 nodos con polo menos dous discos, senón que no modelo indica que se utilizarán os discos virtuais vda, vdb, etc.
Xenial, agora necesitamos definir todas estas máquinas:
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 Ao final hai un comando -print-xml > /tmp/storage-1.xml, que crea un ficheiro xml cunha descrición de cada máquina no cartafol /tmp/; se non o engades, non estarás capaz de identificar máquinas virtuais.
Agora necesitamos definir todas estas máquinas en 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 ~]#Agora un pequeno matiz: tripleO usa IPMI para xestionar servidores durante a instalación e a introspección.
A introspección é o proceso de inspección do hardware para obter os seus parámetros necesarios para o aprovisionamento posterior dos nodos. A introspección realízase mediante ironic, un servizo deseñado para traballar con servidores bare metal.
Pero aquí está o problema: aínda que os servidores IPMI de hardware teñen un porto separado (ou un porto compartido, pero isto non é importante), as máquinas virtuais non teñen tales portos. Aquí vén na nosa axuda unha muleta chamada vbmc, unha utilidade que che permite emular un porto IPMI. Paga a pena prestar atención a este matiz, especialmente para aqueles que queiran montar un laboratorio deste tipo nun hipervisor ESXI; para ser sincero, non sei se ten un análogo de vbmc, polo que paga a pena preguntarse sobre este problema antes de implementar todo. .
Instalar vbmc:
yum install yum install python2-virtualbmcSe o teu sistema operativo non pode atopar o paquete, engade o repositorio:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmAgora configuramos a utilidade. Aquí todo é banal ata o punto de desgraza. Agora é lóxico que non haxa servidores na lista vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Para que aparezan, deben declararse manualmente así:
[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 ~]#Creo que a sintaxe do comando é clara sen explicación. Non obstante, polo de agora todas as nosas sesións están en estado DE BAIXO. Para que pasen ao estado UP, cómpre activalos:
[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 ~]#E o toque final: cómpre corrixir as regras do firewall (ou desactivalo por completo):
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
Agora imos ao subcloud e comprobemos que todo funciona. O enderezo da máquina host é 192.168.255.200, en undercloud engadimos o paquete ipmitool necesario durante a preparación para a implantación:
[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 runningComo podes ver, lanzamos con éxito o nodo de control a través de vbmc. Agora imos desactivalo e seguir adiante:
[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 ~]#O seguinte paso é a introspección dos nodos nos que se instalará o overcloud. Para iso, necesitamos preparar un ficheiro json cunha descrición dos nosos nodos. Teña en conta que, a diferenza da instalación en servidores simples, o ficheiro indica o porto no que se executa vbmc para 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: o nodo de control ten dúas interfaces, pero neste caso isto non é importante, nesta instalación será suficiente para nós.
Agora preparamos o ficheiro json. Necesitamos indicar o enderezo poppy do porto a través do cal se realizará o aprovisionamento, os parámetros dos nodos, darlles nomes e indicar como chegar 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"
}
]
}Agora necesitamos preparar imaxes para irónicas. Para iso, descárgaos a través de wget e instálelos:
(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 ~]$Cargando imaxes a undercloud:
(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 ~]$Comprobando que todas as imaxes se cargaron
(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 ~]$Unha cousa máis: necesitas engadir 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 ~]$Agora podemos dar o comando para a introspección:
(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 ~]$Como podes ver na saída, todo completouse sen erros. Comprobamos que todos os nodos están no estado dispoñible:
(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 ~]$ Se os nodos están nun estado diferente, xeralmente manexable, algo saíu mal e cómpre mirar o rexistro e descubrir por que pasou isto. Teña en conta que neste escenario estamos a utilizar a virtualización e pode haber erros asociados ao uso de máquinas virtuais ou vbmc.
A continuación, necesitamos indicar que nodo realizará que función, é dicir, indicar o perfil co que se implementará o nodo:
(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 ~]$Especifique o perfil para cada nodo:
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-d9afb69d1167Comprobamos que fixemos todo correctamente:
(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 ~]$Se todo está correcto, damos o comando para implementar 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 qemuNunha instalación real, naturalmente empregaranse modelos personalizados, no noso caso isto complicará moito o proceso, xa que cada edición no modelo terá que ser explicada. Como se escribiu anteriormente, ata unha simple instalación será suficiente para que vexamos como funciona.
Nota: a variable qemu --libvirt-type é necesaria neste caso, xa que usaremos a virtualización aniñada. En caso contrario, non poderás executar máquinas virtuais.
Agora tes aproximadamente unha hora, ou quizais máis (dependendo das capacidades do hardware) e só podes esperar que despois deste tempo vexa a seguinte mensaxe:
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 ~]$Agora tes unha versión case completa de openstack, na que podes estudar, experimentar, etc.
Comprobamos que todo funciona correctamente. Na pila de directorios de inicio do usuario hai dous ficheiros: un stackrc (para xestionar o subcloud) e o segundo overcloudrc (para xestionar o overcloud). Estes ficheiros deben especificarse como fonte, xa que conteñen información necesaria para a autenticación.
(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 ~]$A miña instalación aínda require un pequeno toque: engadir unha ruta ao controlador, xa que a máquina coa que estou a traballar está nunha rede diferente. Para iso, vai a control-1 na conta de administrador de calor e rexistra a 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.254Ben, agora podes ir ao horizonte. Toda a información (enderezos, inicio de sesión e contrasinal) está no ficheiro /home/stack/overcloudrc. O diagrama final ten este aspecto:
Por certo, na nosa instalación, os enderezos de máquina emitíronse a través de DHCP e, como podes ver, son emitidos "ao chou". Podes definir estrictamente no modelo que enderezo se debe anexar a que máquina durante a implantación, se o precisas.
Como circula o tráfico entre máquinas virtuais?
Neste artigo veremos tres opcións para pasar tráfico
- Dúas máquinas nun hipervisor nunha rede L2
- Dúas máquinas en diferentes hipervisores na mesma rede L2
- Dúas máquinas en redes diferentes (enraizamento entre redes)
Casos con acceso ao mundo exterior a través dunha rede externa, utilizando enderezos flotantes, así como enrutamento distribuído, teremos en conta a próxima vez, de momento centrarémonos no tráfico interno.
Para comprobar, imos montar o seguinte diagrama:
Creamos 4 máquinas virtuais - 3 nunha rede L2 - net-1 e 1 máis na rede 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 ~]$ Vexamos en que hipervisores se atopan as máquinas creadas:
(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 ~]$
As máquinas vm-1 e vm-3 están situadas en compute-0, as máquinas vm-2 e vm-4 están situadas no nodo compute-1.
Ademais, creouse un enrutador virtual para habilitar o enrutamento entre as redes especificadas:
(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 ~]$ O router ten dous portos virtuais, que actúan como pasarelas para as redes:
(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 ~]$ Pero antes de ver como circula o tráfico, vexamos o que temos actualmente no nodo de control (que tamén é un nodo de rede) e no nodo de cálculo. Imos comezar co nodo de cálculo.
[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 ~]$Polo momento, o nodo ten tres pontes ovs: br-int, br-tun, br-ex. Entre elas, como vemos, hai un conxunto de interfaces. Para facilitar a comprensión, tracemos todas estas interfaces no diagrama e vexamos que pasa.
Mirando os enderezos aos que se elevan os túneles VxLAN, pódese ver que un túnel se eleva a compute-1 (192.168.255.26), o segundo túnel mira a control-1 (192.168.255.15). Pero o máis interesante é que br-ex non ten interfaces físicas, e se miras que fluxos están configurados, podes ver que esta ponte só pode deixar o tráfico polo momento.
[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 ~]$ Como podes ver na saída, o enderezo está parafusado directamente ao porto físico e non á interface da ponte 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 ~]$
Segundo a primeira regra, todo o que veu do porto phy-br-ex debe ser descartado.
En realidade, actualmente non hai ningún outro lugar para que o tráfico entre nesta ponte, excepto desde esta interface (a interface con br-int) e, a xulgar polas caídas, o tráfico BUM xa voou cara a ponte.
É dicir, o tráfico pode saír deste nodo só a través do túnel VxLAN e nada máis. Non obstante, se acendes o DVR, a situación cambiará, pero tratarémolo noutra vez. Ao usar o illamento de rede, por exemplo usando vlans, non terá unha interface L3 na vlan 0, senón varias interfaces. Non obstante, o tráfico VxLAN deixará o nodo do mesmo xeito, pero tamén encapsulado nalgún tipo de vlan dedicado.
Resolvemos o nodo de cálculo, pasemos ao nodo 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 feito, podemos dicir que todo é igual, pero o enderezo IP xa non está na interface física senón na ponte virtual. Isto faise porque este porto é o porto polo que o tráfico sairá ao mundo 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 ~]$ Este porto está ligado á ponte br-ex e dado que non hai etiquetas vlan nel, este porto é un porto troncal no que están permitidos todos os vlan, agora o tráfico sae fóra sen etiqueta, como indica vlan-id 0 no saída anterior.
Todo o demais neste momento é semellante ao nodo de cálculo: as mesmas pontes, os mesmos túneles van a dous nodos de cálculo.
Non consideraremos os nós de almacenamento neste artigo, pero para entendelo é necesario dicir que a parte da rede destes nodos é banal ata o punto de desgraza. No noso caso, só hai un porto físico (eth0) cun enderezo IP asignado e iso é todo. Non hai túneles VxLAN, pontes de túneles, etc. - non hai ningún ov, xa que non ten sentido. Ao usar o illamento de rede, este nodo terá dúas interfaces (portos físicos, bodny ou só dúas vlans - non importa - depende do que queiras) - unha para a xestión, a segunda para o tráfico (escritura no disco da máquina virtual). , lectura do disco, etc.)
Descubrimos o que temos nos nodos en ausencia de servizos. Agora lancemos 4 máquinas virtuais e vexamos como cambia o esquema descrito anteriormente: deberíamos ter portos, enrutadores virtuais, etc.
Ata agora a nosa rede ten este aspecto:
Temos dúas máquinas virtuais en cada nodo informático. Usando compute-0 como exemplo, vexamos como se inclúe todo.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ A máquina só ten unha interface 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 ~]$
Esta interface mira na ponte 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 ~]$ Como podes ver na saída, só hai dúas interfaces na ponte: tap95d96a75-a0 e qvb95d96a75-a0.
Aquí paga a pena deterse un pouco sobre os tipos de dispositivos de rede virtuais en OpenStack:
vtap: interface virtual conectada a unha instancia (VM)
qbr - ponte Linux
qvb e qvo - par vEth conectado á ponte Linux e á ponte Open vSwitch
br-int, br-tun, br-vlan — Abre pontes de vSwitch
patch-, int-br-, phy-br- - Abre as interfaces de parches de vSwitch que conectan pontes
qg, qr, ha, fg, sg - Abre os portos vSwitch utilizados polos dispositivos virtuais para conectarse a OVS
Como entendes, se temos un porto qvb95d96a75-a0 na ponte, que é un par vEth, nalgún lugar está a súa contraparte, que loxicamente debería chamarse qvo95d96a75-a0. Vexamos que portos hai en 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 ~]$ Como podemos ver, o porto está en br-int. Br-int actúa como un interruptor que remata os portos de máquinas virtuais. Ademais de qvo95d96a75-a0, o porto qvo5bd37136-47 é visible na saída. Este é o porto para a segunda máquina virtual. Como resultado, o noso diagrama agora ten o seguinte aspecto:
Unha pregunta que debería interesar inmediatamente ao lector atento: cal é a ponte de Linux entre o porto da máquina virtual e o porto OVS? O caso é que para protexer a máquina utilízanse grupos de seguridade, que non son máis que iptables. OVS non funciona con iptables, polo que se inventou esta "muleta". Non obstante, está quedando obsoleto - está sendo substituído por conntrack nas novas versións.
É dicir, en última instancia, o esquema ten o seguinte aspecto:
Dúas máquinas nun hipervisor nunha rede L2
Dado que estas dúas máquinas virtuales están situadas na mesma rede L2 e no mesmo hipervisor, o tráfico entre elas fluirá loxicamente localmente a través de br-int, xa que ambas máquinas estarán na mesma 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 ~]$ Dúas máquinas en diferentes hipervisores na mesma rede L2
Agora vexamos como vai pasar o tráfico entre dúas máquinas da mesma rede L2, pero situadas en hipervisores diferentes. Para ser honesto, nada cambiará moito, só o tráfico entre hipervisores pasará polo túnel vxlan. Vexamos un exemplo.
Enderezos de máquinas virtuais entre as que veremos o tráfico:
[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 ~]$ Observamos a táboa de reenvío en br-int en 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 ~]O tráfico debería ir ao porto 2; vexamos que tipo de porto é:
[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 ~]$Este é patch-tun, é dicir, a interface en br-tun. Vexamos que pasa co paquete en 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 ~]$ O paquete está empaquetado en VxLAN e envíase ao porto 2. Vexamos onde leva o porto 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 ~]$Este é un túnel vxlan en 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 ~]$Imos a compute-1 e vexamos que pasa a continuación co paquete:
[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 está na táboa de reenvío br-int en compute-1 e, como se pode ver na saída anterior, é visible a través do porto 2, que é o porto cara 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:46Ben, entón vemos que en br-int en compute-1 hai unha papoula de destino:
[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 ~]$ É dicir, o paquete recibido voará ao porto 3, detrás do cal xa hai unha instancia de máquina virtual-00000003.
A beleza de implementar Openstack para aprender en infraestruturas virtuais é que podemos capturar facilmente o tráfico entre hipervisores e ver o que está a suceder con el. Isto é o que faremos agora, executar tcpdump no porto vnet cara 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*******************A primeira liña mostra que Patek desde o enderezo 10.0.1.85 vai ao enderezo 10.0.1.88 (tráfico ICMP), e está envolto nun paquete VxLAN con vni 22 e o paquete vai do host 192.168.255.19 (compute-0) ao host 192.168.255.26. .1 ( calcular-XNUMX). Podemos comprobar que o VNI coincide co especificado en ovs.
Volvamos a esta liña actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 é vni no sistema numérico hexadecimal. Imos converter este número ao décimo sistema:
16 = 6*16^0+1*16^1 = 6+16 = 22É dicir, vni corresponde á realidade.
A segunda liña amosa o tráfico de volta, ben, non ten sentido explicalo, alí está todo claro.
Dúas máquinas en redes diferentes (enrutamento entre redes)
O último caso de hoxe é o enrutamento entre redes dentro dun proxecto mediante un enrutador virtual. Estamos considerando un caso sen DVR (verémolo noutro artigo), polo que o enrutamento ocorre no nodo da rede. No noso caso, o nodo de rede non está situado nunha entidade separada e está situado no nodo de control.
Primeiro, vexamos que o enrutamento 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 msDado que neste caso o paquete debe ir á pasarela e encamiñarse alí, necesitamos descubrir o enderezo MAC da pasarela, para o que miramos a táboa ARP da instancia:
$ 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 eth0Agora vexamos onde se debe enviar o tráfico con destino (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 ~]$ Vexamos onde leva o porto 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 ~]$ Todo é lóxico, o tráfico vai a br-tun. Vexamos en que túnel vxlan estará envolto:
[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 ~]$ O terceiro porto é 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 o nodo 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 ~]$ O tráfico chegou ao nodo de control, polo que temos que ir a el e ver como vai ocorrer o enrutamento.
Como lembras, o nodo de control no interior parecía exactamente igual que o nodo de cálculo: as mesmas tres pontes, só br-ex tiña un porto físico a través do cal o nodo podía enviar tráfico ao exterior. A creación de instancias cambiou a configuración dos nodos de cálculo: engadíronse aos nodos linux bridge, iptables e interfaces. A creación de redes e un enrutador virtual tamén deixou pegada na configuración do nodo de control.
Polo tanto, é obvio que o enderezo MAC da pasarela debe estar na táboa de reenvío br-int no nodo de control. Comprobamos que está alí e onde está a buscar:
[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 ~]$ O Mac é visible desde o porto qr-0c52b15f-8f. Se volvemos á lista de portos virtuais en Openstack, este tipo de portos utilízanse para conectar varios dispositivos virtuais a OVS. Para ser máis precisos, qr é un porto para o enrutador virtual, que se representa como un espazo de nomes.
Vexamos cales son os espazos de nomes no 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 ~]$ Ata tres exemplares. Pero a xulgar polos nomes, podes adiviñar o propósito de cada un deles. Volveremos ás instancias con ID 0 e 1 máis tarde, agora estamos interesados no espazo de nomes 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 ~]$ Este espazo de nomes contén dous internos que creamos anteriormente. Engadíronse os dous portos virtuais a br-int. Comprobamos o enderezo mac do porto qr-0c52b15f-8f, xa que o tráfico, a xulgar polo enderezo mac de destino, dirixíase a esta interface.
[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 ~]$ É dicir, neste caso, todo funciona segundo as leis do enrutamento estándar. Dado que o tráfico está destinado ao host 10.0.2.8, debe saír pola segunda interface qr-92fa49b5-54 e pasar polo túnel vxlan ata o nodo de cálculo:
[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 ~]$ Todo é lóxico, sen sorpresas. Vexamos onde é visible o enderezo poppy do host 10.0.2.8 en 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 ~]$ Como era de esperar, o tráfico vai a br-tun, vexamos a que túnel vai o seguinte:
[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 ~]$ O tráfico entra no túnel para calcular-1. Ben, en compute-1 todo é sinxelo: desde br-tun o paquete pasa a br-int e de aí á interface da 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 ~]$ Comprobamos que esta é realmente a interface 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 ~]$
En realidade, percorremos todo o paquete. Creo que notaches que o tráfico pasou por diferentes túneles vxlan e saíu con diferentes VNI. Vexamos que tipo de VNI son estes, despois de que recolleremos un vertedoiro no porto de control do nodo e asegúrese de que o tráfico flúe exactamente como se describe anteriormente.
Entón, o túnel para calcular-0 ten as seguintes accións=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Imos converter 0x16 ao sistema numérico decimal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22O túnel para computar-1 ten o seguinte VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Imos converter 0x63 ao sistema numérico decimal:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Ben, agora vexamos o vertedoiro:
[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*******************O primeiro paquete é un paquete vxlan desde o host 192.168.255.19 (compute-0) ata o host 192.168.255.15 (control-1) con vni 22, no que se empaqueta un paquete ICMP desde o host 10.0.1.85 ata o host 10.0.2.8. Como calculamos anteriormente, vni coincide co que vimos na saída.
O segundo paquete é un paquete vxlan desde o host 192.168.255.15 (control-1) ata o host 192.168.255.26 (compute-1) con vni 99, no que se empaqueta un paquete ICMP desde o host 10.0.1.85 ata o host 10.0.2.8. Como calculamos anteriormente, vni coincide co que vimos na saída.
Os dous paquetes seguintes son tráfico de retorno desde 10.0.2.8 e non 10.0.1.85.
É dicir, ao final obtivemos o seguinte esquema de nodos de control:
Parece que é iso? Esquecemos dous espazos de nomes:
[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 ~]$ Como falamos da arquitectura da plataforma na nube, estaría ben que as máquinas recibisen enderezos automaticamente dun servidor DHCP. Estes son dous servidores DHCP para as nosas dúas redes 10.0.1.0/24 e 10.0.2.0/24.
Comprobamos que isto é certo. Só hai un enderezo neste espazo de nomes - 10.0.1.1 - o enderezo do propio servidor DHCP, e tamén se inclúe en 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 0Vexamos se os procesos que conteñen qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 no seu nome no nodo 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 ~]$ Existe un proceso deste tipo e en base á información presentada na saída anterior, podemos, por exemplo, ver o que temos actualmente en aluguer:
[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 ~]$Como resultado, obtemos o seguinte conxunto de servizos no nodo de control:
Ben, teña en conta: isto son só 4 máquinas, 2 redes internas e un enrutador virtual... Agora non temos redes externas aquí, un montón de proxectos diferentes, cada un coas súas propias redes (superpostas), e temos un enrutador distribuído apagado e, ao final, só había un nodo de control no banco de probas (para a tolerancia a fallos debe haber un quórum de tres nodos). É lóxico que no comercio todo sexa "un pouco" máis complicado, pero neste sinxelo exemplo entendemos como debería funcionar: se tes 3 ou 300 espazos de nomes é importante, por suposto, pero desde o punto de vista do funcionamento de todo o conxunto. estrutura, nada cambiará moito... aínda que ata que non conectes algún SDN do provedor. Pero esa é unha historia completamente diferente.
Espero que fose interesante. Se tes algún comentario/engadido, ou nalgún lugar que mentín directamente (son humano e a miña opinión sempre será subxectiva) - escribe o que hai que corrixir/engadir - corrixirémolo/engadirémolo todo.
En conclusión, gustaríame dicir algunhas palabras sobre a comparación de Openstack (tanto de vainilla como de provedor) coa solución na nube de VMWare. xa canso diso, pero aínda así. Na miña opinión, é moi difícil comparar estas dúas solucións, pero definitivamente podemos dicir que hai desvantaxes en ambas solucións e ao elixir unha solución hai que sopesar os pros e os contras.
Se OpenStack é unha solución impulsada pola comunidade, entón VMWare ten dereito a facer só o que quere (ler - o que é rendible para ela) e isto é lóxico - porque é unha empresa comercial que está afeita a gañar cartos cos seus clientes. Pero hai un grande e gordo PERO: podes saír de OpenStack, por exemplo de Nokia, e con poucos gastos cambiar a unha solución, por exemplo, de Juniper (Contrail Cloud), pero é improbable que poidas saír de VMWare. . Para min, estas dúas solucións parécense así: Openstack (vendedor) é unha gaiola sinxela na que te meten, pero tes unha chave e podes saír en calquera momento. VMWare é unha gaiola dourada, o propietario ten a chave da gaiola e custarache moito.
Non estou promocionando nin o primeiro produto nin o segundo: ti escolles o que necesitas. Pero se tivese tal opción, escollería ambas as dúas solucións: VMWare para a nube de TI (cargas baixas, xestión sinxela), OpenStack dalgún provedor (Nokia e Juniper ofrecen solucións chave en man moi boas) para a nube de Telecom. Non usaría Openstack para a informática pura: é como disparar a gorrións cun canón, pero non vexo ningunha contraindicación para usalo que non sexa a redundancia. Non obstante, usar VMWare nas telecomunicacións é como levar pedra triturada nun Ford Raptor: é fermoso dende fóra, pero o condutor ten que facer 10 viaxes en lugar dunha.
Na miña opinión, a maior desvantaxe de VMWare é a súa completa pechadura - a empresa non che dará ningunha información sobre como funciona, por exemplo, vSAN ou o que hai no núcleo do hipervisor - simplemente non é rendible para iso - é dicir, nunca te convertas nun experto en VMWare: sen apoio de provedores, estás condenado (moitas veces coñezo expertos en VMWare que están desconcertados por preguntas triviais). Para min, VMWare está a mercar un coche co capó bloqueado - si, pode ter especialistas que poden cambiar a correa de distribución, pero só o que vendeu esta solución pode abrir o capó. Persoalmente, non me gustan as solucións nas que non podo encaixar. Dirás que quizais non teñas que ir debaixo do capó. Si, isto é posible, pero mirareiche cando necesites montar unha gran función na nube de 20-30 máquinas virtuais, 40-50 redes, a metade das cales quere saír ao exterior e a segunda metade pida Aceleración SR-IOV, se non, necesitarás máis un par de ducias destes coches; se non, o rendemento non será suficiente.
Hai outros puntos de vista, polo que só ti podes decidir que escoller e, o máis importante, serás entón responsable da túa elección. Esta é só a miña opinión: unha persoa que viu e tocou polo menos 4 produtos: Nokia, Juniper, Red Hat e VMWare. É dicir, teño algo con que comparar.
Fonte: www.habr.com