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.
