OpenStack Liberty CLI e Gateway NAT Multipli

2016-05-26

Machine-translated — the English original is authoritative.

I clienti cercano sempre soluzioni di produzione nel mondo reale, mai la semplice configurazione di laboratorio greenfield su cui tutti siamo stati addestrati – se abbiamo fortuna! Il progetto attuale non fa eccezione e, sebbene si discosti effettivamente dalla configurazione di laboratorio, immagino che i loro requisiti non siano affatto unici. Piano di controllo OpenStack HA "MidScale" a singola regione con iperervisor ESX e KVM e, naturalmente, non un solo gateway NAT ma più gateway NAT. Se siete ancora interessati, continuate a leggere – l'ambiente è già stato costruito, inclusi i gateway NAT multipli [Nota per me stesso: merita probabilmente un altro post sul blog]. Le VLAN sono utilizzate per le reti Tenant con 3 nodi di rete dedicati configurati con CVR – Centralized Virtual Routing (Routing Virtuale Centralizzato), noto anche come Routing Legacy.

Panoramica

Questo blog descrive i passaggi necessari per costruire il seguente ambiente utilizzando esclusivamente l'interfaccia a riga di comando (CLI) di OpenStack

• progetto dev/test
• rete tenant privata singola /24
• 2 x server applicativi a 3 livelli: Web-1, App-1, DB-1 & Web-2, App-2, DB-2.

• Gruppi di sicurezza per fornire isolamento tra entrambe le applicazioni a 3 livelli.

• progetto di produzione

• 3 x reti tenant private /24 – una per ogni livello dell'applicazione
• 2 x server applicativi a 3 livelli: Web-1, App-1, DB-1 & Web-2, App-2, DB-2 con le VM del server sui rispettivi livelli di rete.

• Gruppi di sicurezza per fornire isolamento tra entrambe le applicazioni a 3 livelli.

• progetto server remoti

• Questo progetto sarà utilizzato per ospitare due diversi server di database a cui verranno assegnati IP fluttuanti e che verranno utilizzati per rappresentare server esterni per le dimostrazioni di accesso.

• SNAT per tutti i server

• Gateway NAT Multipli o Reti Esterne Multiple con IP Fluttuanti.

L'installazione HOS 3.0 multi-iperervisor è già stata completata con successo e la sua architettura di alto livello può essere vista di seguito.

Procedura

• Creare 3 nuovi progetti – dev_test, production & remote
• openstack project create –domain default –description “Dev-Test Project” dev_test
• openstack project create –domain default –description “Production Project” production
• openstack project create –domain default –description “Remote Servers for Demo Only” remote

• Creare due nuovi utenti – Bart l'Admin & Lisa l'Operatore
• openstack user create –domain default –password homer bart
• openstack user create –domain default –password homer lisa

• Aggiungere il ruolo admin ai progetti e a bart
• openstack role add –project remote –user bart admin
• openstack role add –project production –user bart admin
• openstack role add –project dev_test –user bart admin
• Aggiungere il ruolo member ai progetti e a lisa
• openstack role add –project remote –user lisa _member_
• openstack role add –project production –user lisa _member_
• openstack role add –project dev_test –user lisa _member_

• Creare le nuove reti tenant VLAN utilizzando gli ID VLAN 4000-4010 e associarle ai rispettivi progetti come delineato sopra
• neutron net-create –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –provider:physical_network physnet1 –provider:segmentation_id 4000 –provider:network_type vlan dev_test_net

• • neutron net-create –tenant-id cd506c50142d4a6e9618087ecbd5599f –provider:physical_network physnet1 –provider:segmentation_id 4001 –provider:network_type vlan prod_web_net
• neutron net-create –tenant-id cd506c50142d4a6e9618087ecbd5599f –provider:physical_network physnet1 –provider:segmentation_id 4002 –provider:network_type vlan prod_app_net
• neutron net-create –tenant-id cd506c50142d4a6e9618087ecbd5599f  –provider:physical_network physnet1 –provider:segmentation_id 4003 –provider:network_type vlan prod_db_net

• neutron net-create –tenant-id 3857ea74aa9e47b081d2781e9a661fa9  –provider:physical_network physnet1 –provider:segmentation_id 4004 –provider:network_type vlan remote_net

• Creare le subnet per ogni rete
• neutron subnet-create dev_test_net 172.17.175.0/24 –name subnet_dev_test –gateway 172.17.175.1 –allocation-pool start=172.17.175.20,end=172.17.175.250 –enable-dhcp

• neutron subnet-create prod_web_net 172.17.176.0/24 –name subnet_prod_web –gateway 172.17.176.1 –allocation-pool start=172.17.176.20,end=172.17.176.250 –enable-dhcp

• neutron subnet-create prod_app_net 172.17.177.0/24 –name subnet_prod_app –gateway 172.17.177.1 –allocation-pool start=172.17.177.20,end=172.17.177.250 –enable-dhcp

• neutron subnet-create prod_db_net 172.17.178.0/24 –name subnet_prod_db –gateway 172.17.178.1 –allocation-pool start=172.17.178.20,end=172.17.178.250 –enable-dhcp

• neutron subnet-create remote_net 172.17.179.0/24 –name subnet_remote –gateway 172.17.179.1 –allocation-pool start=172.17.179.20,end=172.17.179.250 –enable-dhcp

• Creare le VM dei livelli dell'applicazione come delineato in precedenza
• nova flavor-list

• nova image-list

• neutron net-list

• nova secgroup-list

• Eseguire il source del file rc dell'amministratore del progetto
• nova boot –flavor m1.tiny –image cirros-0.3.3-x86_64 –nic net-id=7271c4de-3f91-4a12-bb8c-45113610ce08 –security-group default dev-web-1

• nova boot –flavor m1.tiny –image cirros-0.3.3-x86_64 –nic net-id=7271c4de-3f91-4a12-bb8c-45113610ce08 –security-group default dev-app-1
• nova boot –flavor m1.tiny –image cirros-0.3.3-x86_64 –nic net-id=7271c4de-3f91-4a12-bb8c-45113610ce08 –security-group default dev-db-1
• nova boot –flavor m1.tiny –image debian-vmware –nic net-id=7271c4de-3f91-4a12-bb8c-45113610ce08 –security-group default dev-web-2
• nova boot –flavor m1.tiny –image debian-vmware –nic net-id=7271c4de-3f91-4a12-bb8c-45113610ce08 –security-group default dev-app-2
• nova boot –flavor m1.tiny –image debian-vmware –nic net-id=7271c4de-3f91-4a12-bb8c-45113610ce08 –security-group default dev-db-2

• Esempio di come accedere alla console di un'istanza [sia vmware che kvm]
• nova get-vnc-console dev-app-1 novnc
• nova get-vnc-console dev-web-1 novnc
• nova get-vnc-console dev-db-1 novnc
• nova get-vnc-console dev-app-2 novnc
• nova get-vnc-console dev-web-2 novnc
• nova get-vnc-console dev-db-2 novnc

• Aggiungere la rotta SNAT per i Server (impostare Ha a false qui sotto poiché sono vincolato dagli ID VLAN disponibili)
• neutron router-create –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –distributed False –ha False db-router
• neutron router-create –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –distributed False –ha False app-router
• neutron router-create –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –distributed False –ha False web-router

• Impostare il gateway esterno del router
• neutron router-gateway-set app-router NGOne
• neutron router-gateway-set web-router NGTwo
• neutron router-gateway-set db-router NGPhysical2

• Collegare la subnet richiesta al router
• neutron router-interface-add d33d1ca0-e25c-4972-83b8-c7f1b62a4156 167f394a-ac53-432b-8077-169b0389c725

• La porta del gateway predefinita sarà già stata consumata dal primo router sulla rete. Dobbiamo creare due nuove porte sulla subnet e aggiungere questi dettagli ai secondi e terzi router.
• neutron port-create  –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –name NGTwo-if dev_test_net
• neutron port-create  –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –name NGPhysical2 dev_test_net

• Ora possiamo associare la nuova porta dell'interfaccia al router
• neutron router-interface-add  8e7c9b58-1f25-4f9e-8a8d-7335149512de port=e3df0352-ebf8-4869-8ee5-44c6fc866a31
• neutron router-interface-add 019439b1-c525-4047-b9d5-5c6cf0cca24d port=bf8832a1-d13b-4416-965b-3e09137452c6

• Il progetto dev-test dovrebbe ora apparire più o meno così:

• I 3 diversi Gateway NAT possono fornire funzionalità sia SNAT che DNAT. I Gruppi di sicurezza saranno utilizzati per fornire isolamento tra i server e i gateway.

• Il gruppo di sicurezza predefinito consente il traffico tra le macchine virtuali sulla stessa rete tenant. In questo scenario stiamo utilizzando la vm basata su kvm dev-app-1 e mostreremo l'isolamento dalla vm basata su esx dev-app-2

• Il seguente Gruppo di sicurezza fornirà isolamento tra questi due server.
• neutron security-group-create –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e AppGroup-1 –description “Allow traffic flow within application group 1 only”

• • neutron security-group-rule-create –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –direction ingress –ethertype IPv4 –remote-group-id  2a659276-9797-45c5-b9f7-b02cc4470147 AppGroup-1

• • nova  –os-tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e add-secgroup dev-app-1 AppGroup-1

• Rimuovere il gruppo di sicurezza "default" già applicato

• nova –os-tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e remove-secgroup dev-app-1 default

• Ora il ping fallisce tra dev-app-1 e dev-app2

• L'applicazione del nuovo gruppo di sicurezza a dev-app-2 abiliterà la comunicazione di gruppo mirata
• nova  –os-tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e add-secgroup dev-app-2 AppGroup-1

Questa è ovviamente una dimostrazione molto basilare dei gruppi di sicurezza – si tratta semplicemente di definire chiaramente i requisiti di comunicazione e tradurli in regole.

Per quanto riguarda la creazione degli altri due progetti, production & remote, il processo è esattamente lo stesso e dovresti finire con queste topologie aggiuntive una volta completato.

Originally published on allthingscloud.eu (2016-05-26).