Il cloud computing sta penetrando sempre più profondamente nelle nostre vite e probabilmente non c'è una sola persona che non abbia utilizzato almeno una volta i servizi cloud. Tuttavia, cos'è esattamente una nuvola e come funziona, poche persone lo sanno, anche a livello di idea. Il 5G sta già diventando una realtà e l’infrastruttura delle telecomunicazioni sta iniziando a passare da soluzioni pilastro a soluzioni cloud, proprio come ha fatto quando è passata da soluzioni completamente hardware a “pilastri” virtualizzati.
Oggi parleremo del mondo interno dell’infrastruttura cloud, in particolare vedremo i fondamenti della parte rete.
Cos'è una nuvola? La stessa virtualizzazione: vista profilo?
Più che una domanda logica. No, questa non è virtualizzazione, anche se senza di essa non sarebbe possibile farla. Consideriamo due definizioni:
Cloud computing (di seguito denominato Cloud) è un modello per fornire un accesso user-friendly alle risorse informatiche distribuite che devono essere implementate e lanciate su richiesta con la latenza più bassa possibile e un costo minimo per il fornitore di servizi.
Virtualizzazione - questa è la capacità di dividere un'entità fisica (ad esempio un server) in più entità virtuali, aumentando così l'utilizzo delle risorse (ad esempio, hai 3 server caricati al 25-30%, dopo la virtualizzazione ottieni 1 server caricato all'80-90 per cento). Naturalmente, la virtualizzazione consuma alcune risorse: è necessario alimentare l'hypervisor, tuttavia, come ha dimostrato la pratica, il gioco vale la candela. Un esempio ideale di virtualizzazione è VMWare, che prepara perfettamente le macchine virtuali, o ad esempio KVM, che preferisco, ma questa è una questione di gusti.
Usiamo la virtualizzazione senza rendercene conto e anche i router di ferro utilizzano già la virtualizzazione: ad esempio, nell'ultima versione di JunOS, il sistema operativo è installato come macchina virtuale sopra una distribuzione Linux in tempo reale (Wind River 9). Ma la virtualizzazione non è il cloud, ma il cloud non può esistere senza virtualizzazione.
La virtualizzazione è uno degli elementi costitutivi su cui è costruito il cloud.
Creare un cloud semplicemente raccogliendo diversi hypervisor in un dominio L2, aggiungendo un paio di playbook yaml per la registrazione automatica dei vlan tramite una sorta di Ansible e inserendovi sopra qualcosa come un sistema di orchestrazione per la creazione automatica di macchine virtuali non funzionerà. Sarà più accurato, ma il Frankenstein che ne risulta non è la nuvola di cui abbiamo bisogno, anche se per altri potrebbe essere il sogno finale. Inoltre, se prendi lo stesso Openstack, essenzialmente è ancora Frankenstein, ma vabbè, non ne parliamo per ora.
Ma capisco che dalla definizione presentata sopra non è del tutto chiaro cosa possa effettivamente essere chiamato nuvola.
Pertanto un documento del NIST (National Institute of Standards and Technology) prevede 5 caratteristiche principali che dovrebbe avere un’infrastruttura cloud:
Fornitura di servizi su richiesta. L'utente deve avere libero accesso alle risorse informatiche a lui assegnate (come reti, dischi virtuali, memoria, core del processore, ecc.) e queste risorse devono essere fornite automaticamente, cioè senza intervento da parte del fornitore di servizi.
Ampia disponibilità di servizio. L'accesso alle risorse deve essere fornito tramite meccanismi standard per consentire l'utilizzo sia di PC standard che di thin client e dispositivi mobili.
Combinazione delle risorse in pool. I pool di risorse devono essere in grado di fornire risorse a più clienti contemporaneamente, garantendo che i clienti siano isolati e liberi da influenze reciproche e competizione per le risorse. Nei pool sono incluse anche le reti, il che indica la possibilità di utilizzare indirizzi sovrapposti. I pool devono essere in grado di scalare su richiesta. L'uso dei pool consente di fornire il livello necessario di tolleranza agli errori delle risorse e di astrazione delle risorse fisiche e virtuali: al destinatario del servizio viene semplicemente fornito l'insieme delle risorse richieste (dove si trovano fisicamente queste risorse, su quante server e switch: per il client non ha importanza). Tuttavia, dobbiamo tenere conto del fatto che il fornitore deve garantire una prenotazione trasparente di queste risorse.
Adattamento rapido alle diverse condizioni. I servizi devono essere flessibili: fornitura rapida delle risorse, loro ridistribuzione, aggiunta o riduzione delle risorse su richiesta del cliente e da parte del cliente dovrebbe esserci la sensazione che le risorse del cloud siano infinite. Per facilità di comprensione, ad esempio, non vedi un avviso che indica che parte dello spazio su disco in Apple iCloud è scomparso perché il disco rigido del server si è rotto e le unità si rompono. Inoltre, da parte tua, le possibilità di questo servizio sono quasi illimitate - hai bisogno di 2 TB - nessun problema, hai pagato e ricevuto. Un esempio simile può essere fornito con Google.Drive o Yandex.Disk.
Possibilità di misurazione del servizio fornito. I sistemi cloud devono controllare e ottimizzare automaticamente le risorse consumate e questi meccanismi devono essere trasparenti sia per l’utente che per il fornitore di servizi. Cioè, puoi sempre controllare quante risorse stai consumando tu e i tuoi clienti.
Vale la pena considerare il fatto che questi requisiti sono per lo più requisiti per un cloud pubblico, quindi per un cloud privato (ovvero un cloud lanciato per le esigenze interne dell'azienda), questi requisiti possono essere leggermente modificati. Tuttavia, occorre ancora realizzarli, altrimenti non otterremo tutti i vantaggi del cloud computing.
Perché abbiamo bisogno di una nuvola?
Tuttavia, qualsiasi tecnologia nuova o esistente, qualsiasi nuovo protocollo viene creato per qualcosa (beh, ad eccezione di RIP-ng, ovviamente). Nessuno ha bisogno di un protocollo fine a se stesso (beh, tranne RIP-ng, ovviamente). È logico che il Cloud venga creato per fornire un qualche tipo di servizio all'utente/cliente. Conosciamo tutti almeno un paio di servizi cloud, ad esempio Dropbox o Google.Docs, e credo che la maggior parte delle persone li utilizzi con successo: ad esempio, questo articolo è stato scritto utilizzando il servizio cloud Google.Docs. Ma i servizi cloud che conosciamo rappresentano solo una parte delle capacità del cloud, più precisamente sono solo servizi di tipo SaaS. Possiamo fornire un servizio cloud in tre modi: sotto forma di SaaS, PaaS o IaaS. Il servizio di cui hai bisogno dipende dai tuoi desideri e capacità.
Diamo un'occhiata a ciascuno in ordine:
Software as a Service (SaaS) è un modello per fornire un servizio completo al cliente, ad esempio un servizio di posta elettronica come Yandex.Mail o Gmail. In questo modello di fornitura dei servizi, tu, come cliente, in realtà non fai altro che utilizzare i servizi, ovvero non devi pensare alla configurazione del servizio, alla sua tolleranza agli errori o alla ridondanza. La cosa principale è non compromettere la tua password; il fornitore di questo servizio farà il resto per te. Dal punto di vista del fornitore di servizi, è pienamente responsabile dell'intero servizio, dall'hardware del server e dai sistemi operativi host alle impostazioni del database e del software.
Piattaforma come servizio (PaaS) — quando si utilizza questo modello, il fornitore di servizi fornisce al cliente un pezzo per il servizio, ad esempio, prendiamo un server Web. Il fornitore di servizi ha fornito al cliente un server virtuale (di fatto, un insieme di risorse, come RAM/CPU/Storage/Reti, ecc.) e ha anche installato il sistema operativo e il software necessario su questo server, tuttavia, la configurazione di tutto questo viene fatto dal cliente stesso e per l'esecuzione del servizio il cliente risponde. Il fornitore di servizi, come nel caso precedente, è responsabile delle prestazioni dell'attrezzatura fisica, degli hypervisor, della stessa macchina virtuale, della sua disponibilità di rete, ecc., ma il servizio stesso non rientra più nella sua area di responsabilità.
Infrastruttura come servizio (IaaS) - questo approccio è già più interessante, infatti, il fornitore di servizi fornisce al cliente un'infrastruttura virtualizzata completa, ovvero un insieme (pool) di risorse, come core CPU, RAM, reti, ecc. Tutto il resto spetta a il cliente - cosa vuole fare il cliente con queste risorse all'interno del pool assegnato (quota) - non è particolarmente importante per il fornitore. Non c'è dubbio che il cliente voglia creare il proprio vEPC o addirittura creare un mini operatore e fornire servizi di comunicazione. In tale scenario, il fornitore di servizi è responsabile del provisioning delle risorse, della loro tolleranza agli errori e disponibilità, nonché del sistema operativo che consente loro di mettere in comune queste risorse e renderle disponibili al cliente con la possibilità di aumentare o diminuire le risorse in qualsiasi momento su richiesta del cliente. Il cliente configura personalmente tutte le macchine virtuali e altri orpelli tramite il portale e la console self-service, inclusa la configurazione delle reti (ad eccezione delle reti esterne).
Cos'è OpenStack?
In tutte e tre le opzioni, il fornitore di servizi necessita di un sistema operativo che consenta la creazione di un'infrastruttura cloud. In effetti, con SaaS, più di una divisione è responsabile dell'intero stack di tecnologie - esiste una divisione responsabile dell'infrastruttura - ovvero fornisce IaaS a un'altra divisione, questa divisione fornisce SaaS al cliente. OpenStack è uno dei sistemi operativi cloud che consente di raccogliere un gruppo di switch, server e sistemi di archiviazione in un unico pool di risorse, dividere questo pool comune in sottopool (tenant) e fornire queste risorse ai client sulla rete.
OpenStack è un sistema operativo cloud che consente di controllare ampi pool di risorse informatiche, archiviazione dati e risorse di rete, fornite e gestite tramite API utilizzando meccanismi di autenticazione standard.
In altre parole, si tratta di un insieme di progetti software gratuiti progettati per creare servizi cloud (sia pubblici che privati), ovvero un insieme di strumenti che consentono di combinare server e apparecchiature di commutazione in un unico pool di risorse, gestire queste risorse, fornendo il livello necessario di tolleranza agli errori.
Al momento della stesura di questo materiale, la struttura di OpenStack si presenta così:
Immagine tratta da
Ciascuno dei componenti inclusi in OpenStack svolge una funzione specifica. Questa architettura distribuita ti consente di includere nella soluzione l'insieme di componenti funzionali di cui hai bisogno. Tuttavia, alcuni componenti sono componenti root e la loro rimozione comporterà l'inoperabilità totale o parziale della soluzione nel suo insieme. Questi componenti sono solitamente classificati come:
- Performance modelli/hostess — GUI basata sul Web per la gestione dei servizi OpenStack
- Chiave di volta è un servizio di identità centralizzato che fornisce funzionalità di autenticazione e autorizzazione per altri servizi, oltre a gestire le credenziali degli utenti e i relativi ruoli.
- neutrone - un servizio di rete che fornisce connettività tra le interfacce di vari servizi OpenStack (inclusa la connettività tra le VM e il loro accesso al mondo esterno)
- tizzone — fornisce l'accesso allo storage a blocchi per le macchine virtuali
- Nova — gestione del ciclo di vita delle macchine virtuali
- Sguardo — repository di immagini e snapshot di macchine virtuali
- Swift — fornisce l'accesso all'oggetto di archiviazione
- telemetro di plafond — un servizio che offre la possibilità di raccogliere dati di telemetria e misurare le risorse disponibili e consumate
- calore — orchestrazione basata su modelli per la creazione automatica e il provisioning delle risorse
È possibile visualizzare un elenco completo di tutti i progetti e il loro scopo .
Ogni componente OpenStack è un servizio che esegue una funzione specifica e fornisce un'API per gestire tale funzione e interagire con altri servizi del sistema operativo cloud per creare un'infrastruttura unificata. Ad esempio, Nova fornisce la gestione delle risorse di calcolo e un'API per accedere alla configurazione di tali risorse, Glance fornisce la gestione delle immagini e un'API per gestirle, Cinder fornisce l'archiviazione a blocchi e un'API per gestirla, ecc. Tutte le funzioni sono interconnesse in modo molto stretto.
Tuttavia, se lo guardi, tutti i servizi in esecuzione in OpenStack sono in definitiva una sorta di macchina virtuale (o contenitore) connessa alla rete. Sorge la domanda: perché abbiamo bisogno di così tanti elementi?
Esaminiamo l'algoritmo per creare una macchina virtuale e collegarla alla rete e all'archiviazione persistente in Openstack.
- Quando crei una richiesta per creare una macchina, sia essa una richiesta tramite Horizon (Dashboard) o una richiesta tramite la CLI, la prima cosa che accade è l'autorizzazione della tua richiesta su Keystone: puoi creare una macchina, ha la diritto di utilizzare questa rete, la tua quota di bozza, ecc.
- Keystone autentica la tua richiesta e genera un token di autenticazione nel messaggio di risposta, che verrà utilizzato ulteriormente. Ricevuta risposta da Keystone, la richiesta viene inviata verso Nova (nova api).
- Nova-api verifica la validità della tua richiesta contattando Keystone utilizzando il token di autenticazione precedentemente generato
- Keystone esegue l'autenticazione e fornisce informazioni su autorizzazioni e restrizioni in base a questo token di autenticazione.
- Nova-api crea una voce per la nuova VM in nova-database e passa la richiesta di creare la macchina a nova-scheduler.
- Nova-scheduler seleziona l'host (nodo del computer) su cui verrà distribuita la VM in base ai parametri, ai pesi e alle zone specificati. Un record di questo e l'ID della VM vengono scritti nel database nova.
- Successivamente, nova-scheduler contatta nova-compute con una richiesta di distribuire un'istanza. Nova-compute contatta nova-conductor per ottenere informazioni sui parametri della macchina (nova-conductor è un elemento nova che funge da server proxy tra nova-database e nova-compute, limitando il numero di richieste a nova-database per evitare problemi con il database riduzione del carico di consistenza).
- Nova-conductor riceve le informazioni richieste da nova-database e le trasmette a nova-compute.
- Successivamente, nova-compute chiama "Gate" per ottenere l'ID dell'immagine. Glace convalida la richiesta in Keystone e restituisce le informazioni richieste.
- Nova-compute contatta Neutron per ottenere informazioni sui parametri di rete. Similmente a sguardo, neutron convalida la richiesta in Keystone, dopo di che crea una voce nel database (identificatore di porta, ecc.), crea una richiesta per creare una porta e restituisce le informazioni richieste a nova-compute.
- Nova-compute contatta Cinder con una richiesta di allocare un volume alla macchina virtuale. Similmente al colpo d'occhio, il sidro convalida la richiesta in Keystone, crea una richiesta di creazione del volume e restituisce le informazioni richieste.
- Nova-compute contatta libvirt con una richiesta di distribuire una macchina virtuale con i parametri specificati.
In effetti, l'operazione apparentemente semplice di creazione di una semplice macchina virtuale si trasforma in un tale vortice di chiamate API tra gli elementi della piattaforma cloud. Inoltre, come puoi vedere, anche i servizi precedentemente designati sono costituiti anche da componenti più piccoli tra i quali avviene l'interazione. La creazione di una macchina è solo una piccola parte di ciò che la piattaforma cloud ti consente di fare: c'è un servizio responsabile del bilanciamento del traffico, un servizio responsabile dello storage a blocchi, un servizio responsabile del DNS, un servizio responsabile del provisioning dei server bare metal, ecc. Il cloud ti consente di trattare le tue macchine virtuali come un gregge di pecore (al contrario della virtualizzazione). Se succede qualcosa alla tua macchina in un ambiente virtuale - la ripristini da backup, ecc., ma le applicazioni cloud sono costruite in modo tale che la macchina virtuale non svolga un ruolo così importante - la macchina virtuale "è morta" - nessun problema - ne viene semplicemente creato uno nuovo, il veicolo è basato sul modello e, come si suol dire, la squadra non ha notato la perdita del combattente. Naturalmente, ciò prevede la presenza di meccanismi di orchestrazione: utilizzando i modelli Heat, puoi facilmente implementare una funzione complessa composta da dozzine di reti e macchine virtuali.
Vale sempre la pena tenere presente che non esiste infrastruttura cloud senza rete: ogni elemento in un modo o nell'altro interagisce con altri elementi attraverso la rete. Inoltre, il cloud ha una rete assolutamente non statica. Naturalmente, la rete sottostante è ancora più o meno statica: nuovi nodi e switch non vengono aggiunti ogni giorno, ma il componente sovrapposto può e cambierà inevitabilmente costantemente: nuove reti verranno aggiunte o eliminate, appariranno nuove macchine virtuali e quelle vecchie morire. E come ricorderete dalla definizione di cloud data all'inizio dell'articolo, le risorse dovrebbero essere assegnate all'utente automaticamente e con il minimo (o meglio ancora senza) intervento da parte del fornitore di servizi. Cioè, il tipo di fornitura di risorse di rete che ora esiste sotto forma di front-end sotto forma di account personale accessibile tramite http/https e l'ingegnere di rete di turno Vasily come backend non è un cloud, nemmeno se Vasily ha otto mani.
Neutron, come servizio di rete, fornisce un'API per la gestione della porzione di rete dell'infrastruttura cloud. Il servizio alimenta e gestisce la parte di rete di Openstack fornendo un livello di astrazione chiamato Network-as-a-Service (NaaS). Cioè, la rete è la stessa unità misurabile virtuale come, ad esempio, i core virtuali della CPU o la quantità di RAM.
Ma prima di passare all'architettura della parte di rete di OpenStack, consideriamo come funziona questa rete in OpenStack e perché la rete è una parte importante e integrante del cloud.
Quindi abbiamo due VM client ROSSE e due VM client VERDI. Supponiamo che queste macchine si trovino su due hypervisor in questo modo:
Per il momento si tratta solo della virtualizzazione di 4 server e niente di più, dato che finora non abbiamo fatto altro che virtualizzare 4 server, posizionandoli su due server fisici. E finora non sono nemmeno connessi alla rete.
Per creare una nuvola, dobbiamo aggiungere diversi componenti. Per prima cosa virtualizziamo la parte di rete: dobbiamo connettere queste 4 macchine in coppia e i client desiderano una connessione L2. Puoi utilizzare uno switch e configurare un trunk nella sua direzione e risolvere il tutto utilizzando un bridge linux o, per gli utenti più avanzati, openvswitch (torneremo su questo più avanti). Ma possono esserci molte reti e spingere costantemente L2 attraverso uno switch non è l'idea migliore: ci sono diversi dipartimenti, un service desk, mesi di attesa per il completamento di una domanda, settimane di risoluzione dei problemi - nel mondo moderno questo l'approccio non funziona più. E prima un’azienda lo capisce, più facile sarà andare avanti. Pertanto, tra gli hypervisor selezioneremo una rete L3 attraverso la quale comunicheranno le nostre macchine virtuali, e su questa rete L3 costruiremo reti virtuali overlay L2 dove verrà eseguito il traffico delle nostre macchine virtuali. Puoi utilizzare GRE, Geneve o VxLAN come incapsulamento. Concentriamoci per ora su quest'ultimo, anche se non è particolarmente importante.
Dobbiamo individuare VTEP da qualche parte (spero che tutti abbiano familiarità con la terminologia VxLAN). Dato che abbiamo una rete L3 proveniente direttamente dai server, nulla ci impedisce di posizionare VTEP sui server stessi e OVS (OpenvSwitch) è eccellente in questo. Di conseguenza, abbiamo ottenuto questo design:
Poiché il traffico tra le VM deve essere suddiviso, le porte verso le macchine virtuali avranno numeri vlan diversi. Il numero del tag gioca un ruolo solo all'interno di uno switch virtuale, poiché quando incapsulato in VxLAN possiamo rimuoverlo facilmente, poiché avremo una VNI.
Ora possiamo creare per loro le nostre macchine e le nostre reti virtuali senza problemi.
Tuttavia, cosa succede se il client dispone di un'altra macchina, ma si trova su una rete diversa? Abbiamo bisogno del rooting tra le reti. Considereremo un'opzione semplice quando viene utilizzato il routing centralizzato, ovvero il traffico viene instradato attraverso speciali nodi di rete dedicati (beh, di regola, sono combinati con nodi di controllo, quindi avremo la stessa cosa).
Sembra che non ci sia niente di complicato: creiamo un'interfaccia bridge sul nodo di controllo, indirizziamo il traffico verso di esso e da lì lo instradiamo dove ne abbiamo bisogno. Ma il problema è che il client ROSSO vuole utilizzare la rete 10.0.0.0/24 e il client VERDE vuole utilizzare la rete 10.0.0.0/24. Cioè, iniziamo a intersecare gli spazi degli indirizzi. Inoltre, i client non vogliono che altri client possano accedere alle loro reti interne, il che è logico. Per separare le reti e il traffico dati dei clienti, assegneremo uno spazio dei nomi separato per ciascuno di essi. Il namespace è in effetti una copia dello stack di rete Linux, ovvero i client nel namespace RED sono completamente isolati dai client del namespace GREEN (beh, l'instradamento tra queste reti client è consentito tramite il namespace predefinito o su apparecchiature di trasporto a monte).
Cioè, otteniamo il seguente diagramma:
I tunnel L2 convergono da tutti i nodi di calcolo al nodo di controllo. nodo in cui si trova l'interfaccia L3 per queste reti, ciascuna in uno spazio dei nomi dedicato per l'isolamento.
Tuttavia, abbiamo dimenticato la cosa più importante. La macchina virtuale deve fornire un servizio al client, ovvero deve avere almeno un'interfaccia esterna attraverso la quale può essere raggiunta. Cioè, dobbiamo uscire nel mondo esterno. Ci sono diverse opzioni qui. Facciamo l'opzione più semplice. Aggiungeremo una rete a ciascun cliente, che sarà valida nella rete del provider e non si sovrapporrà ad altre reti. Le reti possono anche intersecarsi e guardare diversi VRF sul lato della rete del provider. I dati di rete vivranno anche nello spazio dei nomi di ciascun client. Tuttavia, usciranno comunque verso il mondo esterno attraverso un’interfaccia fisica (o legame, che è più logico). Per separare il traffico client, il traffico in uscita verrà contrassegnato con un tag VLAN assegnato al client.
Di conseguenza, abbiamo ottenuto questo diagramma:
Una domanda ragionevole è: perché non creare gateway sui nodi di calcolo stessi? Questo non è un grosso problema; inoltre, se accendi il router distribuito (DVR), funzionerà. In questo scenario, consideriamo l'opzione più semplice con un gateway centralizzato, utilizzato per impostazione predefinita in Openstack. Per le funzioni ad alto carico, utilizzeranno sia un router distribuito che tecnologie di accelerazione come SR-IOV e Passthrough, ma come si suol dire, questa è una storia completamente diversa. Per prima cosa affrontiamo la parte base, poi entreremo nei dettagli.
In realtà, il nostro schema è già realizzabile, ma ci sono un paio di sfumature:
- Dobbiamo in qualche modo proteggere le nostre macchine, cioè mettere un filtro sull'interfaccia dello switch verso il client.
- Consentire a una macchina virtuale di ottenere automaticamente un indirizzo IP, in modo da non dover accedere ogni volta tramite la console e registrare l'indirizzo.
Cominciamo con la protezione della macchina. Per questo puoi usare iptables banali, perché no.
Cioè, ora la nostra topologia è diventata un po’ più complicata:
Andiamo avanti. Dobbiamo aggiungere un server DHCP. Il luogo ideale per individuare i server DHCP per ciascun client sarebbe il nodo di controllo già menzionato sopra, dove si trovano gli spazi dei nomi:
Tuttavia, c’è un piccolo problema. Cosa succede se tutto si riavvia e tutte le informazioni sull'affitto degli indirizzi su DHCP scompaiono. È logico che alle macchine vengano assegnati nuovi indirizzi, il che non è molto conveniente. Ci sono due vie d'uscita: utilizzare i nomi di dominio e aggiungere un server DNS per ciascun client, quindi l'indirizzo non sarà particolarmente importante per noi (simile alla parte di rete in k8s) - ma c'è un problema con le reti esterne, poiché gli indirizzi possono anche essere emessi in essi tramite DHCP: è necessaria la sincronizzazione con i server DNS nella piattaforma cloud e un server DNS esterno, che a mio avviso non è molto flessibile, ma è del tutto possibile. Oppure la seconda opzione è utilizzare i metadati, ovvero salvare le informazioni sull'indirizzo fornito alla macchina in modo che il server DHCP sappia quale indirizzo fornire alla macchina se la macchina ha già ricevuto un indirizzo. La seconda opzione è più semplice e flessibile, poiché consente di salvare informazioni aggiuntive sull'auto. Ora aggiungiamo i metadati dell'agente al diagramma:
Un'altra questione che vale la pena discutere è la possibilità di utilizzare una rete esterna da parte di tutti i client, poiché le reti esterne, se devono essere valide su tutta la rete, sarà difficile: è necessario allocare e controllare costantemente l'allocazione di queste reti. La possibilità di utilizzare un'unica rete esterna preconfigurata per tutti i client sarà molto utile durante la creazione di un cloud pubblico. Ciò renderà più semplice la distribuzione delle macchine perché non dobbiamo consultare un database di indirizzi e selezionare uno spazio di indirizzi univoco per la rete esterna di ciascun client. Inoltre, potremo registrare in anticipo una rete esterna e al momento dell'implementazione dovremo solo associare gli indirizzi esterni alle macchine client.
E qui NAT ci viene in aiuto: consentiremo semplicemente ai clienti di accedere al mondo esterno attraverso lo spazio dei nomi predefinito utilizzando la traduzione NAT. Bene, ecco un piccolo problema. Ciò è utile se il client-server agisce come client e non come server, ovvero avvia anziché accettare connessioni. Ma da noi sarà il contrario. In questo caso, dobbiamo fare il NAT di destinazione in modo che quando riceve il traffico, il nodo di controllo capisca che questo traffico è destinato alla macchina virtuale A del client A, il che significa che dobbiamo fare una traduzione NAT da un indirizzo esterno, ad esempio 100.1.1.1 .10.0.0.1, ad un indirizzo interno 100. In questo caso, anche se tutti i client utilizzeranno la stessa rete, l'isolamento interno viene completamente preservato. Cioè, dobbiamo eseguire dNAT e sNAT sul nodo di controllo. Se utilizzare una singola rete con indirizzi mobili o reti esterne, o entrambe contemporaneamente, dipende da cosa vuoi portare nel cloud. Non aggiungeremo indirizzi mobili al diagramma, ma lasceremo le reti esterne già aggiunte in precedenza: ogni client ha la propria rete esterna (nel diagramma sono indicate come vlan 200 e XNUMX sull'interfaccia esterna).
Di conseguenza, abbiamo ricevuto una soluzione interessante e allo stesso tempo ben ponderata, che ha una certa flessibilità ma non dispone ancora di meccanismi di tolleranza agli errori.
Innanzitutto, abbiamo un solo nodo di controllo: il suo fallimento porterà al collasso di tutti i sistemi. Per risolvere questo problema, è necessario raggiungere almeno un quorum di 3 nodi. Aggiungiamo questo al diagramma:
Naturalmente, tutti i nodi sono sincronizzati e quando un nodo attivo lascia, un altro nodo assumerà le sue responsabilità.
Il problema successivo sono i dischi delle macchine virtuali. Al momento, sono archiviati sugli hypervisor stessi e, in caso di problemi con l'hypervisor, perdiamo tutti i dati e la presenza di un raid qui non aiuterà se perdiamo non il disco, ma l'intero server. Per fare ciò, dobbiamo creare un servizio che fungerà da front-end per una sorta di archiviazione. Che tipo di archiviazione sarà non è particolarmente importante per noi, ma dovrebbe proteggere i nostri dati da guasti sia del disco che del nodo, e possibilmente dell'intero cabinet. Ci sono diverse opzioni qui - ci sono, ovviamente, reti SAN con Fibre Channel, ma siamo onesti - FC è già una reliquia del passato - un analogo di E1 nei trasporti - sì, sono d'accordo, è ancora usato, ma solo dove è assolutamente impossibile senza di essa. Pertanto non implementerei volontariamente una rete FC nel 2020, sapendo che esistono altre alternative più interessanti. Anche se a ciascuno la sua, potrebbe esserci chi crede che l'FC con tutti i suoi limiti sia tutto ciò di cui abbiamo bisogno - non discuto, ognuno ha la propria opinione. Tuttavia la soluzione più interessante secondo me è utilizzare una SDS, come ad esempio Ceph.
Ceph consente di creare una soluzione di archiviazione dei dati ad alta disponibilità con una serie di possibili opzioni di backup, a partire dai codici con controllo di parità (analoghi al raid 5 o 6) per finire con la replica completa dei dati su dischi diversi, tenendo conto della posizione dei dischi in server e server in armadietti, ecc.
Per costruire Ceph sono necessari altri 3 nodi. L'interazione con lo storage avverrà anche via rete utilizzando servizi di block, object e file storage. Aggiungiamo spazio di archiviazione allo schema:
Nota: puoi anche creare nodi di calcolo iperconvergenti - questo è il concetto di combinare diverse funzioni su un nodo - ad esempio storage+calcolo - senza dedicare nodi speciali per l'archiviazione ceph. Otterremo lo stesso schema di tolleranza agli errori, poiché SDS riserverà i dati con il livello di prenotazione da noi specificato. Tuttavia, i nodi iperconvergenti sono sempre un compromesso, poiché il nodo di archiviazione non si limita a riscaldare l'aria come sembra a prima vista (poiché non ci sono macchine virtuali su di esso), ma spende le risorse della CPU per servire SDS (in effetti, fa tutto la replica e il ripristino dopo guasti di nodi, dischi, ecc.). Cioè, perderai parte della potenza del nodo di calcolo se lo combini con lo storage.
Tutte queste cose devono essere gestite in qualche modo: abbiamo bisogno di qualcosa attraverso il quale possiamo creare una macchina, una rete, un router virtuale, ecc. Per fare ciò, aggiungeremo un servizio al nodo di controllo che fungerà da dashboard: il il cliente potrà connettersi a questo portale tramite http/https e fare tutto ciò di cui ha bisogno (beh, quasi).
Di conseguenza, ora disponiamo di un sistema tollerante ai guasti. Tutti gli elementi di questa infrastruttura devono essere gestiti in qualche modo. In precedenza è stato descritto che Openstack è un insieme di progetti, ognuno dei quali fornisce una funzione specifica. Come vediamo, ci sono più che sufficienti elementi che devono essere configurati e controllati. Oggi parleremo della parte rete.
Architettura dei neutroni
In OpenStack, Neutron è responsabile della connessione delle porte delle macchine virtuali a una rete L2 comune, garantendo l'instradamento del traffico tra VM situate su diverse reti L2, nonché l'instradamento verso l'esterno, fornendo servizi come NAT, IP mobile, DHCP, ecc.
Ad alto livello, il funzionamento del servizio di rete (la parte base) può essere descritto come segue.
All'avvio della VM, il servizio di rete:
- Crea una porta per una determinata VM (o porte) e ne informa il servizio DHCP;
- Viene creato un nuovo dispositivo di rete virtuale (tramite libvirt);
- La VM si connette alle porte create nel passaggio 1;
Stranamente, il lavoro di Neutron si basa su meccanismi standard familiari a chiunque si sia mai tuffato in Linux: namespace, iptables, linux bridge, openvswitch, conntrack, ecc.
Va subito chiarito che Neutron non è un controller SDN.
Neutron è costituito da diversi componenti interconnessi:
Openstack-neutron-server è un demone che funziona con le richieste degli utenti tramite l'API. Questo demone non è coinvolto nella registrazione delle connessioni di rete, ma fornisce le informazioni necessarie ai suoi plugin, che poi configurano l'elemento di rete desiderato. Gli agenti Neutron sui nodi OpenStack si registrano con il server Neutron.
Neutron-server è in realtà un'applicazione scritta in python, composta da due parti:
- Servizio RIPOSO
- Plugin Neutron (core/servizio)
Il servizio REST è progettato per ricevere chiamate API da altri componenti (ad esempio, una richiesta di fornire alcune informazioni, ecc.)
I plugin sono componenti/moduli software plug-in che vengono richiamati durante le richieste API, ovvero attraverso di essi avviene l'attribuzione di un servizio. I plugin sono divisi in due tipi: service e root. Di norma il plugin horse è principalmente responsabile della gestione dello spazio degli indirizzi e delle connessioni L2 tra le VM, mentre i plugin di servizio forniscono già funzionalità aggiuntive come VPN o FW.
L'elenco dei plugin oggi disponibili può essere visualizzato ad esempio
Possono esserci diversi plugin di servizio, ma può esserci solo un plugin per cavalli.
openstack-neutron-ml2 è il plugin root standard di OpenStack. Questo plugin ha un'architettura modulare (a differenza del suo predecessore) e configura il servizio di rete tramite driver ad esso collegati. Vedremo il plugin stesso un po' più tardi, poiché in effetti offre la flessibilità che OpenStack ha nella parte di rete. Il plugin root può essere sostituito (ad esempio, Contrail Networking esegue tale sostituzione).
Servizio RPC (server RabbitMQ) — un servizio che fornisce la gestione delle code e l'interazione con altri servizi OpenStack, nonché l'interazione tra gli agenti dei servizi di rete.
Agenti di rete — agenti che si trovano in ciascun nodo, attraverso i quali vengono configurati i servizi di rete.
Esistono diversi tipi di agenti.
L'agente principale è Agente L2. Questi agenti vengono eseguiti su ciascuno degli hypervisor, inclusi i nodi di controllo (più precisamente, su tutti i nodi che forniscono qualsiasi servizio agli inquilini) e la loro funzione principale è connettere le macchine virtuali a una rete L2 comune e anche generare avvisi quando si verificano eventi ( ad esempio disabilitare/abilitare la porta).
Il prossimo agente, non meno importante, è Agente L3. Per impostazione predefinita, questo agente viene eseguito esclusivamente su un nodo di rete (spesso il nodo di rete è combinato con un nodo di controllo) e fornisce l'instradamento tra le reti dei tenant (sia tra le sue reti che tra le reti di altri tenant, ed è accessibile al mondo esterno, fornendo NAT, nonché il servizio DHCP). Tuttavia, quando si utilizza un DVR (router distribuito), la necessità di un plug-in L3 appare anche sui nodi di calcolo.
L'agente L3 utilizza gli spazi dei nomi Linux per fornire a ciascun tenant un set di reti isolate e la funzionalità di router virtuali che instradano il traffico e forniscono servizi gateway per le reti Layer 2.
Banca Dati — un database di identificatori di reti, sottoreti, porte, pool, ecc.
Neutron, infatti, accetta richieste API fin dalla creazione di eventuali entità di rete, autentica la richiesta, e tramite RPC (se accede a qualche plugin o agente) o REST API (se comunica in SDN) trasmette agli agenti (tramite plugin) il istruzioni necessarie per organizzare il servizio richiesto.
Passiamo ora all'installazione di prova (come viene distribuita e cosa è incluso, vedremo più avanti nella parte pratica) e vediamo dove si trova ciascun componente:
(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 ~]$
In realtà, questa è l'intera struttura di Neutron. Ora vale la pena dedicare un po’ di tempo al plugin ML2.
Livello modulare 2
Come accennato in precedenza, il plugin è un plugin root OpenStack standard e ha un'architettura modulare.
Il predecessore del plugin ML2 aveva una struttura monolitica, che non consentiva, ad esempio, di utilizzare un mix di diverse tecnologie in un'unica installazione. Ad esempio, non è possibile utilizzare contemporaneamente openvswitch e linuxbridge, né il primo né il secondo. Per questo motivo è stato creato il plugin ML2 con la sua architettura.
ML2 ha due componenti: due tipi di driver: driver di tipo e driver di meccanismo.
Digitare i driver determinare le tecnologie che verranno utilizzate per organizzare le connessioni di rete, ad esempio VxLAN, VLAN, GRE. Allo stesso tempo, il conducente consente l'uso di diverse tecnologie. La tecnologia standard è l'incapsulamento VxLAN per reti overlay e reti esterne vlan.
I driver di tipo includono i seguenti tipi di rete:
Piatto - rete senza tag
VLAN - rete contrassegnata
Locali — un tipo speciale di rete per installazioni all-in-one (tali installazioni sono necessarie sia per gli sviluppatori che per la formazione)
GRE — rete sovrapposta che utilizza tunnel GRE
VxLAN — rete sovrapposta utilizzando tunnel VxLAN
Driver del meccanismo definire strumenti che garantiscono l'organizzazione delle tecnologie specificate nel tipo driver, ad esempio openvswitch, sr-iov, opendaylight, OVN, ecc.
A seconda dell'implementazione di questo driver, verranno utilizzati agenti controllati da Neutron oppure verranno utilizzate connessioni a un controller SDN esterno, che si occupa di tutte le questioni relative all'organizzazione delle reti L2, al routing, ecc.
Esempio: se utilizziamo ML2 insieme a OVS, allora su ciascun nodo di calcolo che gestisce OVS viene installato un agente L2. Tuttavia, se utilizziamo, ad esempio, OVN o OpenDayLight, il controllo di OVS rientra nella loro giurisdizione: Neutron, tramite il plug-in root, fornisce comandi al controller e fa già ciò che gli è stato detto.
Rispolveriamo Open vSwitch
Al momento, uno dei componenti chiave di OpenStack è Open vSwitch.
Quando si installa OpenStack senza alcun fornitore SDN aggiuntivo come Juniper Contrail o Nokia Nuage, OVS è il componente di rete principale della rete cloud e, insieme a iptables, conntrack e namespaces, consente di organizzare reti overlay multi-tenancy a tutti gli effetti. Naturalmente questo componente può essere sostituito, ad esempio, quando si utilizzano soluzioni SDN proprietarie di terzi (vendor).
OVS è uno switch software open source progettato per l'uso in ambienti virtualizzati come spedizioniere di traffico virtuale.
Al momento, OVS ha funzionalità molto decenti, che includono tecnologie come QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, ecc.
Nota: OVS inizialmente non è stato concepito come un soft switch per funzioni di telecomunicazione ad alto carico ed è stato più progettato per funzioni IT che richiedono meno larghezza di banda come server WEB o server di posta. Tuttavia, OVS è in fase di ulteriore sviluppo e le attuali implementazioni di OVS ne hanno notevolmente migliorato le prestazioni e le capacità, il che ne consente l'utilizzo da parte di operatori di telecomunicazioni con funzioni ad alto carico, ad esempio esiste un'implementazione OVS con supporto per l'accelerazione DPDK.
Ci sono tre componenti importanti di OVS di cui devi essere a conoscenza:
- Modulo kernel — un componente situato nello spazio del kernel che elabora il traffico in base alle regole ricevute dall'elemento di controllo;
- Commutatore virtuale daemon (ovs-vswitchd) è un processo lanciato nello spazio utente che è responsabile della programmazione del modulo del kernel, ovvero rappresenta direttamente la logica di funzionamento dello switch
- Server di database - un database locale situato su ciascun host che esegue OVS, in cui è archiviata la configurazione. I controller SDN possono comunicare attraverso questo modulo utilizzando il protocollo OVSDB.
Il tutto è accompagnato da una serie di utilità diagnostiche e gestionali, come ovs-vsctl, ovs-appctl, ovs-ofctl, ecc.
Attualmente, Openstack è ampiamente utilizzato dagli operatori di telecomunicazioni per migrare su di esso le funzioni di rete, come EPC, SBC, HLR, ecc. Alcune funzioni possono vivere senza problemi con OVS così com'è, ma ad esempio EPC elabora il traffico degli abbonati, quindi passa attraverso un'enorme quantità di traffico (ora i volumi di traffico raggiungono diverse centinaia di gigabit al secondo). Naturalmente, indirizzare tale traffico attraverso lo spazio del kernel (poiché lo spedizioniere si trova lì per impostazione predefinita) non è l'idea migliore. Pertanto, OVS viene spesso implementato interamente nello spazio utente utilizzando la tecnologia di accelerazione DPDK per inoltrare il traffico dalla NIC allo spazio utente bypassando il kernel.
Nota: per un cloud utilizzato per funzioni di telecomunicazione, è possibile inviare il traffico da un nodo di calcolo bypassando OVS direttamente alle apparecchiature di commutazione. A questo scopo vengono utilizzati i meccanismi SR-IOV e Passthrough.
Come funziona su un layout reale?
Bene, ora passiamo alla parte pratica e vediamo come funziona il tutto nella pratica.
Innanzitutto, distribuiamo una semplice installazione Openstack. Poiché non ho un set di server a portata di mano per gli esperimenti, assembleremo il prototipo su un server fisico da macchine virtuali. Sì, naturalmente, una soluzione del genere non è adatta a scopi commerciali, ma per vedere un esempio di come funziona la rete in Openstack, un'installazione del genere è sufficiente per gli occhi. Inoltre, tale installazione è ancora più interessante per scopi di formazione, poiché puoi catturare il traffico, ecc.
Poiché dobbiamo vedere solo la parte base, non possiamo utilizzare più reti ma aumentare il tutto utilizzando solo due reti, e la seconda rete in questo layout verrà utilizzata esclusivamente per l'accesso all'undercloud e al server DNS. Per ora non toccheremo le reti esterne: questo è un argomento per un ampio articolo separato.
Allora, cominciamo con ordine. Innanzitutto, una piccola teoria. Installeremo Openstack utilizzando TripleO (Openstack su Openstack). L'essenza di TripleO è che installiamo Openstack all-in-one (ovvero su un nodo), chiamato undercloud, e quindi utilizziamo le capacità dell'Openstack distribuito per installare Openstack destinato al funzionamento, chiamato overcloud. Undercloud utilizzerà la sua capacità intrinseca di gestire server fisici (bare metal) - il progetto Ironic - per fornire hypervisor che svolgeranno i ruoli di nodi di elaborazione, controllo e archiviazione. Cioè, non utilizziamo strumenti di terze parti per distribuire Openstack: distribuiamo Openstack utilizzando Openstack. Diventerà molto più chiaro man mano che l'installazione procede, quindi non ci fermeremo qui e andremo avanti.
Nota: in questo articolo, per semplicità, non ho utilizzato l'isolamento della rete per le reti Openstack interne, ma tutto viene distribuito utilizzando una sola rete. Tuttavia, la presenza o l'assenza dell'isolamento della rete non influisce sulla funzionalità di base della soluzione: tutto funzionerà esattamente come quando si utilizza l'isolamento, ma il traffico scorrerà sulla stessa rete. Per un'installazione commerciale è naturalmente necessario utilizzare l'isolamento utilizzando vlan e interfacce diverse. Ad esempio, il traffico di gestione dello storage ceph e il traffico dati stesso (accesso della macchina ai dischi, ecc.) quando isolati utilizzano sottoreti diverse (gestione dello storage e storage) e ciò consente di rendere la soluzione più tollerante agli errori dividendo questo traffico, ad esempio , su porte diverse o utilizzando profili QoS diversi per traffico diverso in modo che il traffico dati non sopprima il traffico di segnalazione. Nel nostro caso andranno sulla stessa rete e infatti questo non ci limita in alcun modo.
Nota: poiché eseguiremo macchine virtuali in un ambiente virtuale basato su macchine virtuali, dobbiamo prima abilitare la virtualizzazione nidificata.
Puoi verificare se la virtualizzazione nidificata è abilitata o meno in questo modo:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Se vedi la lettera N, abilitiamo il supporto per la virtualizzazione nidificata secondo qualsiasi guida che trovi sulla rete, ad esempio .
Dobbiamo assemblare il seguente circuito da macchine virtuali:
Nel mio caso, per connettere le macchine virtuali che faranno parte della futura installazione (e ne ho prese 7, ma puoi cavartela con 4 se non hai molte risorse), ho utilizzato OpenvSwitch. Ho creato un bridge ovs e vi ho collegato le macchine virtuali tramite gruppi di porte. Per fare ciò, ho creato un file xml come questo:
[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>Qui vengono dichiarati tre gruppi di porte: due di accesso e un trunk (quest'ultimo era necessario per il server DNS, ma puoi farne a meno o installarlo sulla macchina host, a seconda di quale sia più conveniente per te). Successivamente, utilizzando questo template, dichiariamo il nostro tramite virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Ora modifichiamo le configurazioni delle porte dell'hypervisor:
[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: in questo scenario, l'indirizzo sulla porta ovs-br1 non sarà accessibile perché non ha un tag vlan. Per risolvere questo problema, è necessario eseguire il comando sudo ovs-vsctl set port ovs-br1 tag=100. Tuttavia, dopo un riavvio, questo tag scomparirà (se qualcuno sa come farlo rimanere al suo posto, gliene sarei molto grato). Ma questo non è così importante, perché avremo bisogno di questo indirizzo solo durante l'installazione e non ci servirà quando Openstack sarà completamente distribuito.
Successivamente, creiamo una macchina 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 l'installazione imposti tutti i parametri necessari, come nome della macchina, password, utenti, server ntp, ecc., puoi configurare subito le porte, ma per me personalmente, dopo l'installazione, è più semplice accedere alla macchina tramite la console e correggere i file necessari. Se hai già un'immagine già pronta, puoi usarla o fare quello che ho fatto io: scarica l'immagine minima di Centos 7 e usala per installare la VM.
Al termine dell'installazione, dovresti avere una macchina virtuale su cui puoi installare Undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningInnanzitutto, installa gli strumenti necessari per il processo di installazione:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Installazione sottocloud
Creiamo uno stack utente, impostiamo una password, la aggiungiamo a sudoer e gli diamo la possibilità di eseguire comandi root tramite sudo senza dover inserire una password:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackOra specifichiamo il nome completo dell'undercloud nel file host:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Successivamente, aggiungiamo repository e installiamo il software di cui abbiamo bisogno:
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 si prevede di installare ceph, non è necessario inserire i comandi relativi a ceph. Ho usato la versione Queens, ma puoi usarne un'altra che preferisci.
Successivamente, copia il file di configurazione undercloud nello stack di directory home dell'utente:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confOra dobbiamo correggere questo file, adattandolo alla nostra installazione.
È necessario aggiungere queste righe all'inizio del file:
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 = 10Quindi, esaminiamo le impostazioni:
nomehost_undercloud — il nome completo del server undercloud deve corrispondere alla voce sul server DNS
local_ip — indirizzo locale undercloud verso il provisioning della rete
rete_gateway — lo stesso indirizzo locale, che fungerà da gateway per l'accesso al mondo esterno durante l'installazione dei nodi overcloud, coincide anche con l'ip locale
undercloud_public_host — indirizzo API esterno, viene assegnato qualsiasi indirizzo libero dalla rete di provisioning
undercloud_admin_host indirizzo API interno, viene assegnato qualsiasi indirizzo libero dalla rete di provisioning
undercloud_nameservers —Server DNS
generare_certificato_di_servizio - questa riga è molto importante nell'esempio corrente, perché se non la imposti su false riceverai un errore durante l'installazione, il problema è descritto nel bug tracker di Red Hat
interfaccia_locale interfaccia nel provisioning della rete. Questa interfaccia verrà riconfigurata durante la distribuzione undercloud, quindi è necessario disporre di due interfacce su undercloud: una per accedervi, la seconda per il provisioning
local_mtu — MTU. Dato che abbiamo un laboratorio di test e ho una MTU pari a 1500 sulle porte dello switch OVS, è necessario impostarla a 1450 affinché i pacchetti incapsulati in VxLAN possano passare
rete_cidr — rete di fornitura
mascherata — utilizzando NAT per accedere a una rete esterna
masquerade_network - rete che verrà NATata
dhcp_start — l'indirizzo iniziale del pool di indirizzi da cui gli indirizzi verranno assegnati ai nodi durante la distribuzione overcloud
dhcp_end — l'indirizzo finale del pool di indirizzi da cui gli indirizzi verranno assegnati ai nodi durante l'implementazione dell'overcloud
ispezione_iprange — un pool di indirizzi necessari per l'introspezione (non dovrebbe sovrapporsi al pool di cui sopra)
scheduler_max_attempts — numero massimo di tentativi di installazione di overcloud (deve essere maggiore o uguale al numero di nodi)
Dopo che il file è stato descritto, puoi dare il comando per distribuire undercloud:
openstack undercloud install
La procedura dura dai 10 ai 30 minuti a seconda del ferro da stiro. Alla fine dovresti vedere un output come questo:
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.
#############################################################################Questo output indica che hai installato Undercloud con successo e ora puoi controllare lo stato di Undercloud e procedere con l'installazione di Overcloud.
Se guardi l'output di ifconfig, vedrai che è apparsa una nuova interfaccia bridge
[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 0La distribuzione dell'overcloud verrà ora eseguita tramite questa interfaccia.
Dall'output seguente puoi vedere che abbiamo tutti i servizi su un 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 |
+--------------------------+-----------+----------+Di seguito la configurazione della parte di rete 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 ~]$Installazione overcloud
Al momento abbiamo solo Undercloud e non abbiamo abbastanza nodi da cui verrà assemblato Overcloud. Pertanto, prima di tutto, distribuiamo le macchine virtuali di cui abbiamo bisogno. Durante la distribuzione, undercloud stesso installerà il sistema operativo e il software necessario sulla macchina overcloud, ovvero non è necessario distribuire completamente la macchina, ma solo creare un disco (o dischi) per essa e determinarne i parametri, ovvero , infatti, otteniamo un server nudo senza sistema operativo installato su di esso.
Andiamo nella cartella con i dischi delle nostre macchine virtuali e creiamo dei dischi della dimensione richiesta:
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 160GDato che operiamo come root, dobbiamo cambiare il proprietario di questi dischi per non avere problemi con i diritti:
[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 si prevede di installare ceph per studiarlo, i comandi non creano almeno 3 nodi con almeno due dischi, ma nel modello indicano che verranno utilizzati i dischi virtuali vda, vdb, ecc.
Ottimo, ora dobbiamo definire tutte queste macchine:
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 Alla fine c'è un comando -print-xml > /tmp/storage-1.xml, che crea un file xml con la descrizione di ogni macchina nella cartella /tmp/; se non lo aggiungi non sarai in grado di identificare le macchine virtuali.
Ora dobbiamo definire tutte queste macchine in 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 ~]#Ora una piccola sfumatura: tripleO utilizza IPMI per gestire i server durante l'installazione e l'introspezione.
L'introspezione è il processo di ispezione dell'hardware al fine di ottenere i parametri necessari per l'ulteriore provisioning dei nodi. L'introspezione viene effettuata utilizzando ironic, un servizio progettato per funzionare con server bare metal.
Ma ecco il problema: mentre i server IPMI hardware hanno una porta separata (o una porta condivisa, ma questo non è importante), le macchine virtuali non hanno tali porte. Qui viene in nostro aiuto una stampella chiamata vbmc, un'utilità che consente di emulare una porta IPMI. Vale la pena prestare attenzione a questa sfumatura soprattutto per coloro che vogliono creare un laboratorio del genere su un hypervisor ESXI - ad essere onesti, non so se abbia un analogo di vbmc, quindi vale la pena interrogarsi su questo problema prima di distribuire tutto .
Installa vbmc:
yum install yum install python2-virtualbmcSe il tuo sistema operativo non riesce a trovare il pacchetto, aggiungi il repository:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmOra impostiamo l'utilità. Tutto qui è banale fino al disonore. Ora è logico che non ci siano server nell'elenco vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Affinché appaiano, devono essere dichiarati manualmente in questo modo:
[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 ~]#Penso che la sintassi del comando sia chiara senza spiegazioni. Tuttavia, per ora tutte le nostre sessioni sono in stato DOWN. Affinché possano passare allo stato UP, è necessario abilitarli:
[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 il tocco finale: devi correggere le regole del firewall (o disabilitarlo completamente):
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
Adesso andiamo su undercloud e controlliamo che tutto funzioni. L'indirizzo della macchina host è 192.168.255.200, su undercloud abbiamo aggiunto il pacchetto ipmitool necessario durante la preparazione per la distribuzione:
[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 runningCome puoi vedere, abbiamo avviato con successo il nodo di controllo tramite vbmc. Ora spegniamolo e andiamo avanti:
[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 ~]#Il passo successivo è l'introspezione dei nodi su cui verrà installato overcloud. Per fare ciò dobbiamo preparare un file json con la descrizione dei nostri nodi. Tieni presente che, a differenza dell'installazione su bare server, il file indica per ciascuna macchina la porta su cui è in esecuzione vbmc.
[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: il nodo di controllo ha due interfacce, ma in questo caso questo non è importante, in questa installazione ci basterà una.
Adesso prepariamo il file json. Dobbiamo indicare l'indirizzo papavero della porta attraverso la quale verrà effettuato il provisioning, i parametri dei nodi, dare loro dei nomi e indicare come arrivare 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"
}
]
}Ora dobbiamo preparare le immagini per ironizzare. Per fare ciò, scaricali tramite wget e installa:
(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 ~]$Caricamento di immagini su 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 ~]$Verifica che tutte le immagini siano state caricate
(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 ~]$Ancora una cosa: devi aggiungere un server 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 ~]$Ora possiamo dare il comando per l'introspezione:
(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 ~]$Come puoi vedere dall'output, tutto è stato completato senza errori. Controlliamo che tutti i nodi siano nello stato disponibile:
(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 i nodi si trovano in uno stato diverso, solitamente gestibile, qualcosa è andato storto ed è necessario esaminare il registro e capire perché è successo. Tieni presente che in questo scenario stiamo utilizzando la virtualizzazione e potrebbero esserci bug associati all'uso di macchine virtuali o vbmc.
Successivamente, dobbiamo indicare quale nodo eseguirà quale funzione, ovvero indicare il profilo con cui il nodo verrà distribuito:
(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 ~]$Specificare il profilo per ciascun 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-d9afb69d1167Controlliamo di aver fatto tutto correttamente:
(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 tutto è corretto, diamo il comando per implementare 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 qemuIn un'installazione reale verranno naturalmente utilizzati modelli personalizzati, nel nostro caso ciò complicherà notevolmente il processo, poiché ogni modifica al modello dovrà essere spiegata. Come già scritto in precedenza, basterà anche una semplice installazione per vedere come funziona.
Nota: in questo caso è necessaria la variabile qemu di tipo --libvirt, poiché utilizzeremo la virtualizzazione nidificata. Altrimenti non sarai in grado di eseguire macchine virtuali.
Ora hai circa un'ora, o forse di più (a seconda delle capacità dell'hardware) e puoi solo sperare che trascorso questo tempo vedrai il seguente messaggio:
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 ~]$Ora hai una versione quasi completa di OpenStack, sulla quale puoi studiare, sperimentare, ecc.
Controlliamo che tutto funzioni correttamente. Nello stack della directory home dell'utente sono presenti due file: uno stackrc (per la gestione dell'undercloud) e il secondo overcloudrc (per la gestione dell'overcloud). Questi file devono essere specificati come origine, poiché contengono le informazioni necessarie per l'autenticazione.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$La mia installazione richiede ancora un piccolo tocco: l'aggiunta di un percorso sul controller, poiché la macchina con cui sto lavorando si trova su una rete diversa. Per fare ciò, vai su control-1 sotto l'account heat-admin e registra il percorso
(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.254Bene, ora puoi andare all'orizzonte. Tutte le informazioni - indirizzi, login e password - si trovano nel file /home/stack/overcloudrc. Il diagramma finale è simile al seguente:
A proposito, nella nostra installazione, gli indirizzi delle macchine sono stati assegnati tramite DHCP e, come puoi vedere, vengono assegnati "in modo casuale". Puoi definire rigorosamente nel modello quale indirizzo deve essere collegato a quale macchina durante la distribuzione, se ne hai bisogno.
Come scorre il traffico tra le macchine virtuali?
In questo articolo esamineremo tre opzioni per il passaggio del traffico
- Due macchine su un hypervisor su una rete L2
- Due macchine su hypervisor diversi sulla stessa rete L2
- Due macchine su reti diverse (rooting su più reti)
I casi con accesso al mondo esterno tramite una rete esterna, utilizzando indirizzi mobili e routing distribuito, verranno presi in considerazione la prossima volta, per ora ci concentreremo sul traffico interno.
Per verificare, costruiamo il seguente diagramma:
Abbiamo creato 4 macchine virtuali: 3 su una rete L2 - net-1 e un'altra sulla rete net-1
(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 ~]$ Vediamo su quali hypervisor si trovano le macchine create:
(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 ~]$
Le macchine VM-1 e VM-3 si trovano sul nodo compute-0, le macchine VM-2 e VM-4 si trovano sul nodo compute-1.
Inoltre è stato creato un router virtuale per consentire il routing tra le reti specificate:
(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 ~]$ Il router dispone di due porte virtuali, che fungono da gateway per le reti:
(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 ~]$ Ma prima di considerare come scorre il traffico, diamo un'occhiata a ciò che abbiamo attualmente sul nodo di controllo (che è anche un nodo di rete) e sul nodo di calcolo. Iniziamo con il nodo di calcolo.
[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 ~]$Al momento, il nodo ha tre ponti ovs: br-int, br-tun, br-ex. Tra di loro, come vediamo, c'è una serie di interfacce. Per facilitare la comprensione, tracciamo tutte queste interfacce sul diagramma e vediamo cosa succede.
Osservando gli indirizzi a cui vengono collegati i tunnel VxLAN, si può vedere che un tunnel viene collegato a compute-1 (192.168.255.26), il secondo tunnel guarda a control-1 (192.168.255.15). Ma la cosa più interessante è che br-ex non ha interfacce fisiche e se guardi quali flussi sono configurati, puoi vedere che questo ponte al momento può solo far cadere il traffico.
[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 ~]$ Come puoi vedere dall'output, l'indirizzo è collegato direttamente alla porta fisica e non all'interfaccia del bridge virtuale.
[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 ~]$
Secondo la prima regola tutto ciò che proviene dal porto phy-br-ex deve essere scartato.
In realtà, attualmente non c'è nessun altro posto in cui il traffico possa entrare in questo bridge se non da questa interfaccia (l'interfaccia con br-int) e, a giudicare dai cali, il traffico BUM è già entrato nel bridge.
Cioè, il traffico può lasciare questo nodo solo attraverso il tunnel VxLAN e nient'altro. Se però accendi il DVR la situazione cambierà, ma di questo parleremo un'altra volta. Quando si utilizza l'isolamento della rete, ad esempio utilizzando vlan, non si avrà un'interfaccia L3 in vlan 0, ma diverse interfacce. Tuttavia, il traffico VxLAN lascerà il nodo allo stesso modo, ma anche incapsulato in una sorta di vlan dedicata.
Abbiamo risolto il nodo di calcolo, passiamo al nodo di controllo.
[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 ~]$In effetti possiamo dire che è tutto uguale, ma l'indirizzo IP non è più sull'interfaccia fisica ma sul bridge virtuale. Questo viene fatto perché questa porta è la porta attraverso la quale il traffico uscirà verso il mondo esterno.
[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 ~]$ Questa porta è collegata al bridge br-ex e poiché non ci sono tag vlan su di essa, questa porta è una porta trunk su cui sono consentiti tutti i vlan, ora il traffico esce senza tag, come indicato da vlan-id 0 nel uscita sopra.
Tutto il resto al momento è simile al nodo di calcolo: gli stessi ponti, gli stessi tunnel che vanno a due nodi di calcolo.
Non considereremo i nodi di archiviazione in questo articolo, ma per capirlo è necessario dire che la parte di rete di questi nodi è banale fino alla vergogna. Nel nostro caso c’è solo una porta fisica (eth0) a cui è assegnato un indirizzo IP e il gioco è fatto. Non ci sono tunnel VxLAN, ponti tunnel, ecc. - non ci sono affatto ov, poiché non ha senso. Quando si utilizza l'isolamento della rete, questo nodo avrà due interfacce (porte fisiche, bodny o solo due vlan - non importa - dipende da cosa si desidera): una per la gestione, la seconda per il traffico (scrittura sul disco della VM , lettura da disco, ecc.)
Abbiamo capito cosa abbiamo sui nodi in assenza di servizi. Ora lanciamo 4 macchine virtuali e vediamo come cambia lo schema sopra descritto: dovremmo avere porte, router virtuali, ecc.
Finora la nostra rete si presenta così:
Abbiamo due macchine virtuali su ciascun nodo del computer. Utilizzando compute-0 come esempio, vediamo come è incluso tutto.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ La macchina ha solo un'interfaccia virtuale: 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 ~]$
Questa interfaccia appare nel bridge 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 ~]$ Come puoi vedere dall'output, ci sono solo due interfacce nel bridge: tap95d96a75-a0 e qvb95d96a75-a0.
Qui vale la pena soffermarsi un po' sulle tipologie di dispositivi di rete virtuale in OpenStack:
vtap: interfaccia virtuale collegata a un'istanza (VM)
qbr - Ponte Linux
Coppia qvb e qvo - vEth connessa al bridge Linux e al bridge Open vSwitch
br-int, br-tun, br-vlan — Apre i bridge vSwitch
patch-, int-br-, phy-br- - Interfacce patch vSwitch aperte che collegano i bridge
qg, qr, ha, fg, sg - Apre le porte vSwitch utilizzate dai dispositivi virtuali per connettersi a OVS
Come hai capito, se abbiamo una porta qvb95d96a75-a0 nel bridge, che è una coppia vEth, da qualche parte c'è la sua controparte, che logicamente dovrebbe essere chiamata qvo95d96a75-a0. Vediamo quali porte ci sono su 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 ~]$ Come possiamo vedere, il porto è in br-int. Br-int agisce come uno switch che termina le porte della macchina virtuale. Oltre a qvo95d96a75-a0, nell'output è visibile la porta qvo5bd37136-47. Questa è la porta per la seconda macchina virtuale. Di conseguenza, il nostro diagramma ora assomiglia a questo:
Una domanda che dovrebbe interessare immediatamente il lettore attento: qual è il bridge Linux tra la porta della macchina virtuale e la porta OVS? Il fatto è che per proteggere la macchina vengono utilizzati gruppi di sicurezza, che non sono altro che iptables. OVS non funziona con iptables, quindi è stata inventata questa “stampella”. Tuttavia, sta diventando obsoleto: nelle nuove versioni verrà sostituito da conntrack.
Cioè, alla fine lo schema è simile a questo:
Due macchine su un hypervisor su una rete L2
Poiché queste due VM si trovano sulla stessa rete L2 e sullo stesso hypervisor, il traffico tra di loro fluirà logicamente localmente attraverso br-int, poiché entrambe le macchine si troveranno sulla stessa 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 ~]$ Due macchine su hypervisor diversi sulla stessa rete L2
Ora vediamo come andrà il traffico tra due macchine sulla stessa rete L2, ma situate su hypervisor diversi. A dire il vero non cambierà molto, solo il traffico tra gli hypervisor passerà attraverso il tunnel vxlan. Diamo un'occhiata a un esempio.
Indirizzi di macchine virtuali tra le quali controlleremo il traffico:
[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 ~]$ Osserviamo la tabella di inoltro in br-int su 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 ~]Il traffico dovrebbe dirigersi verso la porta 2, vediamo di che tipo di porta si tratta:
[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 ~]$Questo è patch-tun, ovvero l'interfaccia in br-tun. Vediamo cosa succede al pacchetto su 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 ~]$ Il pacchetto viene confezionato in VxLAN e inviato alla porta 2. Vediamo dove porta la porta 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 ~]$Questo è un tunnel vxlan su 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 ~]$Andiamo a compute-1 e vediamo cosa succede dopo con il pacchetto:
[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 ~]$ Il Mac è nella tabella di inoltro br-int su compute-1 e, come si può vedere dall'output sopra, è visibile attraverso la porta 2, che è la porta verso 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:46Bene, allora vediamo che in br-int su compute-1 c'è un papavero di destinazione:
[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 ~]$ Cioè, il pacchetto ricevuto volerà alla porta 3, dietro la quale c'è già un'istanza della macchina virtuale-00000003.
Il bello di implementare Openstack per l'apprendimento su un'infrastruttura virtuale è che possiamo facilmente acquisire il traffico tra gli hypervisor e vedere cosa succede con esso. Questo è ciò che faremo ora, eseguiamo tcpdump sulla porta vnet verso compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************La prima riga mostra che Patek dall'indirizzo 10.0.1.85 va all'indirizzo 10.0.1.88 (traffico ICMP), ed è avvolto in un pacchetto VxLAN con vni 22 e il pacchetto va dall'host 192.168.255.19 (compute-0) all'host 192.168.255.26 .1 (calcolo-XNUMX). Possiamo verificare che il VNI corrisponda a quello specificato in ovs.
Torniamo a questa riga actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 è vni nel sistema numerico esadecimale. Convertiamo questo numero nel 16° sistema:
16 = 6*16^0+1*16^1 = 6+16 = 22Cioè, vni corrisponde alla realtà.
La seconda riga mostra il traffico di ritorno, beh, non ha senso spiegarlo, lì è tutto chiaro.
Due macchine su reti diverse (routing interrete)
L'ultimo caso per oggi è il routing tra reti all'interno di un progetto utilizzando un router virtuale. Stiamo considerando un caso senza DVR (lo vedremo in un altro articolo), quindi il routing avviene sul nodo di rete. Nel nostro caso il nodo di rete non è posto in un'entità separata e si trova sul nodo di controllo.
Per prima cosa, vediamo che il routing funziona:
$ 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 msDato che in questo caso il pacchetto deve raggiungere il gateway e lì essere instradato, dobbiamo trovare l'indirizzo MAC del gateway, per il quale esaminiamo la tabella ARP nell'istanza:
$ 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 eth0Vediamo ora dove deve essere inviato il traffico con destinazione (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 ~]$ Diamo un'occhiata a dove conduce la porta 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 ~]$ Tutto è logico, il traffico va a br-tun. Vediamo in quale tunnel vxlan verrà avvolto:
[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 ~]$ La terza porta è un tunnel 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 ~]$ Che guarda il nodo di controllo:
[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 ~]$ Il traffico ha raggiunto il nodo di controllo, quindi dobbiamo andare lì e vedere come avverrà il routing.
Come ricorderete, il nodo di controllo all'interno sembrava esattamente lo stesso del nodo di calcolo: gli stessi tre bridge, solo che br-ex aveva una porta fisica attraverso la quale il nodo poteva inviare il traffico all'esterno. La creazione di istanze ha modificato la configurazione sui nodi di calcolo: ai nodi sono stati aggiunti linux bridge, iptables e interfacce. La creazione di reti e di un router virtuale ha lasciato il segno anche nella configurazione del nodo di controllo.
Pertanto, è ovvio che l'indirizzo MAC del gateway deve trovarsi nella tabella di inoltro br-int sul nodo di controllo. Controlliamo che sia lì e dove sta guardando:
[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 ~]$ Il Mac è visibile dalla porta qr-0c52b15f-8f. Se torniamo all'elenco delle porte virtuali in Openstack, questo tipo di porta viene utilizzato per connettere diversi dispositivi virtuali a OVS. Per essere più precisi, qr è una porta del router virtuale, rappresentato come uno spazio dei nomi.
Vediamo quali spazi dei nomi sono sul server:
[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 ~]$ Ben tre copie. Ma a giudicare dai nomi, puoi indovinare lo scopo di ciascuno di essi. Torneremo alle istanze con ID 0 e 1 più tardi, ora siamo interessati al namespace 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 ~]$ Questo spazio dei nomi ne contiene due interni che abbiamo creato in precedenza. Entrambe le porte virtuali sono state aggiunte a br-int. Controlliamo l'indirizzo mac della porta qr-0c52b15f-8f, poiché il traffico, a giudicare dall'indirizzo mac di destinazione, è andato a questa interfaccia.
[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 ~]$ Cioè, in questo caso, tutto funziona secondo le leggi del routing standard. Poiché il traffico è destinato all'host 10.0.2.8, deve uscire attraverso la seconda interfaccia qr-92fa49b5-54 e passare attraverso il tunnel vxlan fino al nodo di calcolo:
[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 ~]$ Tutto è logico, senza sorprese. Vediamo dove è visibile in br-int l'indirizzo poppy dell'host 10.0.2.8:
[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 ~]$ Come previsto, il traffico va a br-tun, vediamo in quale tunnel va il traffico successivo:
[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 ~]$ Il traffico entra nel tunnel per calcolare-1. Bene, su compute-1 tutto è semplice: da br-tun il pacchetto va a br-int e da lì all'interfaccia della macchina virtuale:
[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 ~]$ Verifichiamo che questa sia effettivamente l'interfaccia corretta:
[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 ~]$
In realtà, abbiamo esaminato fino in fondo il pacchetto. Penso che tu abbia notato che il traffico attraversava diversi tunnel vxlan ed usciva con diversi VNI. Vediamo di che tipo di VNI si tratta, dopodiché raccoglieremo un dump sulla porta di controllo del nodo e ci assicureremo che il traffico scorra esattamente come descritto sopra.
Quindi, il tunnel per calcolare-0 ha le seguenti azioni=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Convertiamo 0x16 nel sistema numerico decimale:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Il tunnel per compute-1 ha il seguente VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Convertiamo 0x63 nel sistema numerico decimale:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Bene, ora diamo un'occhiata al dump:
[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*******************Il primo pacchetto è un pacchetto vxlan dall'host 192.168.255.19 (compute-0) all'host 192.168.255.15 (control-1) con vni 22, all'interno del quale viene impacchettato un pacchetto ICMP dall'host 10.0.1.85 all'host 10.0.2.8. Come calcolato sopra, vni corrisponde a ciò che abbiamo visto nell'output.
Il secondo pacchetto è un pacchetto vxlan dall'host 192.168.255.15 (control-1) all'host 192.168.255.26 (compute-1) con vni 99, all'interno del quale viene impacchettato un pacchetto ICMP dall'host 10.0.1.85 all'host 10.0.2.8. Come calcolato sopra, vni corrisponde a ciò che abbiamo visto nell'output.
I due pacchetti successivi sono traffico di ritorno da 10.0.2.8 e non da 10.0.1.85.
Cioè, alla fine abbiamo ottenuto il seguente schema del nodo di controllo:
Sembra che sia tutto? Abbiamo dimenticato due spazi dei nomi:
[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 ~]$ Poiché abbiamo parlato dell’architettura della piattaforma cloud, sarebbe opportuno che le macchine ricevessero automaticamente gli indirizzi da un server DHCP. Questi sono due server DHCP per le nostre due reti 10.0.1.0/24 e 10.0.2.0/24.
Verifichiamo che questo sia vero. C'è solo un indirizzo in questo spazio dei nomi - 10.0.1.1 - l'indirizzo del server DHCP stesso, ed è anche incluso in 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 0Vediamo se i processi che contengono qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 nel loro nome sul nodo di controllo:
[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 ~]$ Esiste un tale processo e in base alle informazioni presentate nell'output sopra, possiamo, ad esempio, vedere cosa abbiamo attualmente in affitto:
[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 ~]$Di conseguenza, otteniamo il seguente set di servizi sul nodo di controllo:
Bene, tieni presente: si tratta solo di 4 macchine, 2 reti interne e un router virtuale... Non abbiamo reti esterne qui adesso, un mucchio di progetti diversi, ciascuno con le proprie reti (sovrapposte), e abbiamo un router distribuito si è spento e alla fine c'era un solo nodo di controllo sul banco di prova (per la tolleranza agli errori deve esserci un quorum di tre nodi). È logico che nel commercio tutto sia “un po'” più complicato, ma in questo semplice esempio capiamo come dovrebbe funzionare: se hai 3 o 300 namespace è ovviamente importante, ma dal punto di vista del funzionamento del nell'intera struttura, non cambierà molto... anche se non collegherai alcun fornitore SDN. Ma questa è una storia completamente diversa.
Spero che sia stato interessante. Se hai commenti/aggiunte o in qualche punto ho mentito apertamente (sono umano e la mia opinione sarà sempre soggettiva) - scrivi ciò che deve essere corretto/aggiunto - correggeremo/aggiungeremo tutto.
In conclusione, vorrei spendere qualche parola sul confronto tra Openstack (sia Vanilla che Vendor) con la soluzione cloud di VMWare: mi è stata posta questa domanda troppo spesso negli ultimi due anni e, francamente, non sono d'accordo già stanco, ma comunque. A mio avviso è molto difficile confrontare queste due soluzioni, ma possiamo sicuramente affermare che entrambe le soluzioni presentano degli svantaggi e quando si sceglie una soluzione è necessario valutare i pro e i contro.
Se OpenStack è una soluzione guidata dalla comunità, allora VMWare ha il diritto di fare solo ciò che vuole (leggi - ciò che è redditizio per lui) e questo è logico, perché è una società commerciale abituata a guadagnare denaro dai propri clienti. Ma c'è un grande e grosso MA: puoi uscire da OpenStack, ad esempio da Nokia, e con poca spesa passare a una soluzione, ad esempio, da Juniper (Contrail Cloud), ma è improbabile che tu riesca a uscire da VMWare . Per me, queste due soluzioni assomigliano a questa: Openstack (venditore) è una semplice gabbia in cui vieni messo, ma hai una chiave e puoi andartene in qualsiasi momento. VMWare è una gabbia dorata, il proprietario ha la chiave della gabbia e ti costerà molto.
Non sto promuovendo né il primo prodotto né il secondo: scegli tu ciò di cui hai bisogno. Ma se potessi scegliere, sceglierei entrambe le soluzioni - VMWare per il cloud IT (carico ridotto, gestione facile), OpenStack di qualche fornitore (Nokia e Juniper forniscono ottime soluzioni chiavi in mano) - per il cloud delle telecomunicazioni. Non utilizzerei Openstack per l'IT puro: è come sparare ai passeri con un cannone, ma non vedo alcuna controindicazione all'utilizzo oltre alla ridondanza. Tuttavia, utilizzare VMWare nelle telecomunicazioni è come trasportare pietrisco in una Ford Raptor: è bellissimo dall'esterno, ma l'autista deve fare 10 viaggi invece di uno.
Secondo me, il più grande svantaggio di VMWare è la sua completa chiusura - l'azienda non ti fornirà alcuna informazione su come funziona, ad esempio vSAN o cosa c'è nel kernel dell'hypervisor - semplicemente non è redditizio per questo - cioè lo farai non diventare mai un esperto di VMWare: senza il supporto del fornitore sei condannato (molto spesso incontro esperti di VMWare che sono sconcertati da domande banali). Per me VMWare sta acquistando un'auto con il cofano chiuso: sì, potresti avere specialisti che possono cambiare la cinghia di distribuzione, ma solo chi ti ha venduto questa soluzione può aprire il cofano. Personalmente non mi piacciono le soluzioni in cui non riesco ad adattarmi. Dirai che potresti non dover andare sotto il cofano. Sì, questo è possibile, ma ti guarderò quando avrai bisogno di assemblare una grande funzione nel cloud da 20-30 macchine virtuali, 40-50 reti, metà delle quali vogliono uscire, e la seconda metà chiede Accelerazione SR-IOV, altrimenti avrai bisogno di un paio di dozzine di queste auto, altrimenti le prestazioni non saranno sufficienti.
Esistono altri punti di vista, quindi solo tu puoi decidere cosa scegliere e, soprattutto, sarai poi responsabile della tua scelta. Questa è solo la mia opinione, quella di una persona che ha visto e toccato con mano almeno 4 prodotti: Nokia, Juniper, Red Hat e VMWare. Cioè, ho qualcosa con cui confrontarmi.
Fonte: habr.com