OpenStack Liberty CLI y Puertas de Enlace NAT Múltiples

2016-05-26

Machine-translated — the English original is authoritative.

Los clientes siempre buscan soluciones de producción del mundo real, nunca la sencilla configuración de laboratorio verde que todos hemos aprendido – ¡si tenemos suerte! El proyecto actual no es una excepción y, aunque se desvía de la configuración de laboratorio, imagino que no son únicos en sus requisitos. Plano de control HA de OpenStack de "Mediana Escala" en una sola región con hipervisores ESX y KVM y, por supuesto, no solo una puerta de enlace NAT, sino múltiples puertas de enlace NAT. Si aún está interesado, siga leyendo: el entorno ya ha sido construido, incluidas las múltiples puertas de enlace NAT [Nota para mí mismo: posiblemente merezca otro artículo de blog]. Se utilizan VLAN para las redes de inquilino con 3 nodos de red dedicados configurados con CVR – Enrutamiento Virtual Centralizado – también conocido como Enrutamiento Heredado.

Descripción general

Este blog detalla los pasos necesarios para construir el siguiente entorno utilizando únicamente la interfaz de línea de comandos (CLI) de OpenStack

• proyecto de desarrollo/pruebas
• red de inquilino privada única /24
• 2 x servidores de aplicaciones de 3 capas: Web-1, App-1, DB-1 y Web-2, App-2, DB-2.

• Grupos de seguridad para proporcionar aislamiento entre ambas aplicaciones de 3 capas.

• proyecto de producción

• 3 x redes de inquilino privadas /24 – una para cada capa de la aplicación
• 2 x servidores de aplicaciones de 3 capas: Web-1, App-1, DB-1 y Web-2, App-2, DB-2 con las máquinas virtuales del servidor en sus respectivas capas de red.

• Grupos de seguridad para proporcionar aislamiento entre ambas aplicaciones de 3 capas.

• proyecto de servidores remotos

• Este proyecto se utilizará para alojar dos servidores de bases de datos diferentes que se asignarán con IPs flotantes y se utilizarán para representar servidores externos para demostraciones de acceso.

• SNAT para todos los servidores

• Múltiples puertas de enlace NAT o Múltiples Redes Externas con IPs Flotantes.

La instalación de HOS 3.0 multi-hipervisor ya se ha completado con éxito y su arquitectura de alto nivel se puede ver a continuación.

Procedimiento

• Crear 3 nuevos proyectos – dev_test, production y 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

• Crear dos nuevos usuarios – Bart el Administrador y Lisa la Operadora
• openstack user create –domain default –password homer bart
• openstack user create –domain default –password homer lisa

• Añadir el rol de administrador a los proyectos y 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
• Añadir el rol de miembro a los proyectos y 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_

• Crear las nuevas redes de inquilino VLAN utilizando los IDs de VLAN 4000-4010 y asociarlos con los respectivos proyectos como se ha descrito anteriormente
• 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

• Crear las subredes para cada red
• 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

• Crear las VMs de la capa de aplicación como se ha descrito anteriormente
• nova flavor-list

• nova image-list

• neutron net-list

• nova secgroup-list

• Origen del archivo rc de administrador del proyecto
• 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

• Ejemplo de cómo acceder a la consola de una instancia [tanto vmware como 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

• Añadir ruta SNAT para Servidores (establecer Ha en false a continuación ya que estoy limitado por IDs de VLAN disponibles)
• 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

• Establecer la puerta de enlace externa del enrutador
• neutron router-gateway-set app-router NGOne
• neutron router-gateway-set web-router NGTwo
• neutron router-gateway-set db-router NGPhysical2

• Conectar la subred requerida al enrutador
• neutron router-interface-add d33d1ca0-e25c-4972-83b8-c7f1b62a4156 167f394a-ac53-432b-8077-169b0389c725

• El puerto de puerta de enlace predeterminado ya habrá sido consumido por el primer enrutador en la red. Necesitamos crear dos nuevos puertos en la subred y añadir estos detalles a los segundo y tercer enrutadores.
• neutron port-create –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –name NGTwo-if dev_test_net
• neutron port-create –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –name NGPhysical2 dev_test_net

• Ahora podemos asociar el nuevo puerto de interfaz con el enrutador
• 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

• El proyecto dev-test ahora debería verse algo así:

• Las 3 puertas de enlace NAT diferentes pueden proporcionar tanto funcionalidad SNAT como DNAT. Los Grupos de Seguridad se utilizarán para proporcionar aislamiento entre los servidores y las puertas de enlace.

• El grupo de seguridad predeterminado permite el tráfico entre máquinas virtuales en la misma red de inquilino. En este escenario estamos utilizando la vm basada en kvm dev-app-1 y mostraremos el aislamiento de la vm basada en esx dev-app-2

• El siguiente Grupo de Seguridad proporcionará aislamiento entre estos dos servidores.
• 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

• Eliminar el grupo de seguridad “default” ya aplicado

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

• El ping ahora falla entre dev-app-1 y dev-app2

• Aplicar el nuevo grupo de seguridad a dev-app-2 habilitará la comunicación grupal dirigida
• nova –os-tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e add-secgroup dev-app-2 AppGroup-1

Esto es obviamente una demostración muy básica de grupos de seguridad – es solo una cuestión de definir claramente los requisitos de comunicación y traducirlos en reglas.

En cuanto a la creación de los dos proyectos restantes, production y remote, el proceso es exactamente el mismo y deberías terminar con estas topologías adicionales cuando termines.

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