OpenStack Liberty CLI & Passerelles NAT Multiples

2016-05-26

Machine-translated — the English original is authoritative.

Les clients recherchent toujours des solutions de production réelles, jamais la configuration de laboratoire simple « greenfield » sur laquelle nous avons tous été formés – si nous avons de la chance ! Le projet actuel ne fait pas exception et, bien qu’il s’écarte effectivement de la configuration de laboratoire, j’imagine qu’ils ne sont en aucun cas uniques dans leurs exigences. Plan de contrôle OpenStack HA « MidScale » à région unique avec des hyperviseurs ESX et KVM, et bien sûr, non pas une seule passerelle NAT, mais plusieurs passerelles NAT. Si vous êtes toujours intéressé, lisez la suite – l’environnement a déjà été construit, y compris les multiples passerelles NAT [Note à moi-même : cela mérite peut-être un autre article de blog]. Des VLAN sont utilisés pour les réseaux locataires avec 3 nœuds réseau dédiés configurés avec CVR – Routing Virtuel Centralisé – également connu sous le nom de Routing Hérité.

Aperçu

Cet article détaille les étapes nécessaires pour construire l’environnement suivant en utilisant uniquement l’interface de ligne de commande (CLI) d’OpenStack

• projet dev/test
• réseau locataire privé unique /24
• 2 serveurs d’application à 3 niveaux : Web-1, App-1, DB-1 & Web-2, App-2, DB-2.

• Groupes de sécurité pour assurer l’isolation entre les deux applications à 3 niveaux.

• projet de production

• 3 réseaux locataires privés /24 – un pour chaque niveau d’application
• 2 serveurs d’application à 3 niveaux : Web-1, App-1, DB-1 & Web-2, App-2, DB-2 avec les machines virtuelles des serveurs sur leurs niveaux de réseau respectifs.

• Groupes de sécurité pour assurer l’isolation entre les deux applications à 3 niveaux.

• projet de serveurs distants

• Ce projet sera utilisé pour héberger deux serveurs de base de données différents qui se verront attribuer des adresses IP flottantes et seront utilisés pour représenter des serveurs externes à des fins de démonstration d’accès.

• SNAT pour tous les serveurs

• Passerelles NAT multiples ou Réseaux Externes Multiples avec Adresses IP Flottantes.

L’installation HOS 3.0 multi-hyperviseur a déjà été effectuée avec succès et son architecture de haut niveau peut être vue ci-dessous.

Procédure

• Créer 3 nouveaux projets – 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

• Créer deux nouveaux utilisateurs – Bart l’Admin & Lisa l’Opérateur
• openstack user create –domain default –password homer bart
• openstack user create –domain default –password homer lisa

• Ajouter le rôle admin aux projets et à 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
• Ajouter le rôle member aux projets et à 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_

• Créer les nouveaux réseaux locataires VLAN en utilisant les IDs VLAN 4000-4010 et les associer aux projets respectifs comme indiqué ci-dessus
• 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

• Créer les sous-réseaux pour chaque réseau
• 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

• Créer les VMs de niveau application comme indiqué plus tôt
• nova flavor-list

• nova image-list

• neutron net-list

• nova secgroup-list

• Sourcez le fichier rc admin du projet
• 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

• Exemple d’accès à la console d’une instance [vmware et 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

• Ajouter la route SNAT pour les serveurs (définir Ha à false ci-dessous car je suis limité par les IDs 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

• Définir la passerelle externe du routeur
• neutron router-gateway-set app-router NGOne
• neutron router-gateway-set web-router NGTwo
• neutron router-gateway-set db-router NGPhysical2

• Connecter le sous-réseau requis au routeur
• neutron router-interface-add d33d1ca0-e25c-4972-83b8-c7f1b62a4156 167f394a-ac53-432b-8077-169b0389c725

• Le port de passerelle par défaut aura déjà été consommé par le premier routeur sur le réseau. Nous devons créer deux nouveaux ports sur le sous-réseau et ajouter ces détails aux deuxième et troisième routeurs.
• neutron port-create  –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –name NGTwo-if dev_test_net
• neutron port-create  –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –name NGPhysical2 dev_test_net

• Maintenant, nous pouvons associer le nouveau port d’interface au routeur
• 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

• Le projet dev-test devrait maintenant ressembler à ceci :

• Les 3 passerelles NAT différentes peuvent fournir à la fois les fonctionnalités SNAT et DNAT. Les groupes de sécurité seront utilisés pour assurer l’isolation entre les serveurs et les passerelles.

• Le groupe de sécurité par défaut autorise le trafic entre les machines virtuelles sur le même réseau locataire. Dans ce scénario, nous utilisons la vm basée sur kvm dev-app-1 et montrerons l’isolation par rapport à la vm basée sur esx dev-app-2

• Le groupe de sécurité suivant assurera l’isolation entre ces deux serveurs.
• 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

• Supprimer le groupe de sécurité “default” déjà appliqué

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

• Le ping échoue maintenant entre dev-app-1 et dev-app2

• L’application du nouveau groupe de sécurité sur dev-app-2 activera la communication de groupe ciblée
• nova  –os-tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e add-secgroup dev-app-2 AppGroup-1

Ceci est évidemment une démonstration très basique des groupes de sécurité – il s’agit simplement de définir clairement les exigences de communication et de les traduire en règles.

En ce qui concerne la création des deux projets restants, production & remote, le processus est exactement le même et vous devriez obtenir ces topologies supplémentaires une fois terminé.

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