OpenStack Liberty CLI & Multi-NAT-Gateways

2016-05-26

Machine-translated — the English original is authoritative.

Kunden suchen immer nach realen Produktionslösungen, nie nach dem einfachen Greenfield-Lab-Setup, auf das wir alle trainiert wurden – wenn wir Glück haben! Das aktuelle Projekt ist keine Ausnahme und obwohl es tatsächlich vom Lab-Setup abweicht, stelle ich mir vor, dass sie mit ihren Anforderungen keineswegs einzigartig sind. Single-Region „MidScale“ OpenStack HA-Steuerungsebene mit sowohl ESX- als auch KVM-Hypervisoren und natürlich nicht nur ein NAT-Gateway, sondern mehrere NAT-Gateways. Wenn Sie noch interessiert sind, lesen Sie weiter – die Umgebung wurde bereits aufgebaut, einschließlich der mehreren NAT-Gateways [Notiz an mich: möglicherweise eine weitere Blog-Post wert]. VLANs werden für die Tenant-Netzwerke verwendet, mit 3 dedizierten Netzwerk-Knoten, die mit CVR – Centralised Virtual Routing – auch bekannt als Legacy Routing, eingerichtet sind.

Übersicht

Dieser Blog beschreibt die Schritte, die erforderlich sind, um die folgende Umgebung ausschließlich mit der OpenStack-Befehlszeilenschnittstelle (CLI) aufzubauen.

• dev/test-Projekt
• ein /24 privates Tenant-Netzwerk
• 2 x 3-Tier-Anwendungsserver: Web-1, App-1, DB-1 & Web-2, App-2, DB-2.

• Sicherheitsgruppen zur Bereitstellung der Isolation zwischen beiden 3-Tier-Anwendungen.

• Produktionsprojekt

• 3 x /24 private Tenant-Netzwerke – eines für jede Anwendungsschicht
• 2 x 3-Tier-Anwendungsserver: Web-1, App-1, DB-1 & Web-2, App-2, DB-2 mit den Server-VMs in ihren jeweiligen Netzwerkschichten.

• Sicherheitsgruppen zur Bereitstellung der Isolation zwischen beiden 3-Tier-Anwendungen.

• Remote-Server-Projekt

• Dieses Projekt wird verwendet, um zwei verschiedene Datenbankserver zu hosten, denen Floating-IPs zugewiesen werden und die zur Darstellung externer Server für Zugriffs-Demonstrationen dienen.

• SNAT für alle Server

• Mehrere NAT-Gateways oder mehrere externe Netzwerke mit Floating-IPs.

Die Multi-Hypervisor-HOS 3.0-Installation wurde bereits erfolgreich abgeschlossen, und die hochrangige Architektur kann unten gesehen werden.

Verfahren

• Erstellen Sie 3 neue Projekte – 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

• Erstellen Sie zwei neue Benutzer – Bart the Admin & Lisa the Operator
• openstack user create –domain default –password homer bart
• openstack user create –domain default –password homer lisa

• Fügen Sie die Admin-Rolle zu den Projekten und bart hinzu
• 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
• Fügen Sie die Member-Rolle zu den Projekten und lisa hinzu
• 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_

• Erstellen Sie die neuen VLAN-Tenant-Netzwerke unter Verwendung der VLAN-IDs 4000-4010 und weisen Sie sie den jeweiligen Projekten gemäß der obigen Beschreibung zu
• 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

• Erstellen Sie die Subnetze für jedes Netzwerk
• 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

• Erstellen Sie die Anwendungsschicht-VMs wie zuvor beschrieben
• nova flavor-list

• nova image-list

• neutron net-list

• nova secgroup-list

• Quellcode der Projekt-Admin-rc-Datei
• 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

• Beispiel für den Zugriff auf die Konsole einer Instanz [sowohl vmware als auch 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

• SNAT-Route für Server hinzufügen (setzen Sie Ha unten auf false, da ich durch freie VLAN-IDs eingeschränkt bin)
• 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

• Legen Sie das externe Router-Gateway fest
• neutron router-gateway-set app-router NGOne
• neutron router-gateway-set web-router NGTwo
• neutron router-gateway-set db-router NGPhysical2

• Schließen Sie das erforderliche Subnetz an den Router an
• neutron router-interface-add d33d1ca0-e25c-4972-83b8-c7f1b62a4156 167f394a-ac53-432b-8077-169b0389c725

• Der Standard-Gateway-Port wurde bereits vom ersten Router im Netzwerk verbraucht. Wir müssen zwei neue Ports im Subnetz erstellen und diese Details den zweiten und dritten Routern hinzufügen.
• neutron port-create  –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –name NGTwo-if dev_test_net
• neutron port-create  –tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e –name NGPhysical2 dev_test_net

• Nun können wir den neuen Schnittstellenport mit dem Router verknüpfen
• 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

• Das dev-test-Projekt sollte jetzt in etwa so aussehen:

• Die 3 verschiedenen NAT-Gateways können sowohl SNAT- als auch DNAT-Funktionalität bereitstellen. Sicherheitsgruppen werden verwendet, um die Isolation zwischen den Servern und den Gateways bereitzustellen.

• Die Standard-Sicherheitsgruppe erlaubt den Verkehr zwischen virtuellen Maschinen im selben Tenant-Netzwerk. In diesem Szenario verwenden wir die kvm-basierte VM dev-app-1 und zeigen die Isolation von der esx-basierten VM dev-app-2.

• Die folgende Sicherheitsgruppe wird die Isolation zwischen diesen beiden Servern bereitstellen.
• 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

• Entfernen Sie die bereits angewendete „default“-Sicherheitsgruppe

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

• Ping schlägt nun zwischen dev-app-1 und dev-app2 fehl

• Das Anwenden der neuen Sicherheitsgruppe auf dev-app-2 ermöglicht gezielte Gruppenkommunikation
• nova  –os-tenant-id 244fbcbe8c444dacbfc6dbbbf89f744e add-secgroup dev-app-2 AppGroup-1

Dies ist offensichtlich eine sehr grundlegende Demonstration von Sicherheitsgruppen – es ist nur eine Frage der klaren Definition der Kommunikationsanforderungen und ihrer Übersetzung in Regeln.

Was die Erstellung der verbleibenden zwei Projekte, production & remote, betrifft, ist der Prozess genau derselbe, und Sie sollten am Ende diese zusätzlichen Topologien haben, wenn Sie fertig sind.

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