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.
