6.2. Szenario 2: Erstellen einer Einfachen Overcloud mithilfe des CLI

Dieses Szenario erstellt eine OpenStack Platform Umgebung auf Ebene eines kleinen Unternehmens. Dieses Szenario besteht aus zwei Knoten in der Overcloud: einem Controller-Knoten und einem Compute-Knoten. Beide Rechner sind Bare-Metal Systeme, die IPMI für die Energieverwaltung benutzen. Dieses Szenario konzentriert sich auf die Befehlszeilentools, um die Fähigkeit des Directors zu demonstrieren, eine Red Hat Enterprise Linux OpenStack Platform Umgebung auf niedriger Produktionsebene zu erstellen, die zukünftig Compute-Knoten skalieren kann.

Arbeitsablauf

  1. Knoten-Definitionsvorlage erstellen und leere Knoten im Director registrieren
  2. Hardware aller Knoten überprüfen.
  3. Knoten manuell in Rollen taggen.
  4. Varianten erstellen und in Rollen taggen
  5. Heat-Vorlagen erstellen um das Externe Netzwerk zu isolieren.
  6. Overcloud-Umgebung mit dem Standardplan des Directors und den Isolationsvorlagen des Zusatznetzwerks erstellen

Anforderungen

  • Der in Kapitel 3, Installieren der Undercloud erstellte Director-Knoten
  • Zwei Bare-Metal Rechner. Diese Rechner müssen den Anforderungen entsprechen, die für Controller- und Compute-Knoten festgelegt sind. Mehr zu diesen Anforderungen unter:
    Diese Knoten benötigen kein Betriebssystem, da der Director ein Red Hat Enterprise Linux 7 Image zu jedem Knoten kopiert.
  • Eine Netzwerkverbindung für Ihr Provisioning-Netzwerk, die als systemeigene VLAN konfiguriert ist. Alle Knoten müssen mit diesem Netzwerk verbunden sein und den in Abschnitt 2.3, »Netzwerkanforderungen« gesetzten Anforderungen entsprechen. Für dieses Beispiel benutzt man 192.0.2.0/24 als Provisioning-Subnetz mit den folgenden IP-Adresszuweisungen:

    Tabelle 6.2. IP-Zuweisungen des Provisioning-Netzwerks

    Knotenname
    IP-Adresse
    MAC-Adresse
    IPMI IP-Adresse
    Director
    192.0.2.1
    aa:aa:aa:aa:aa:aa
    Controller
    DHCP definiert
    bb:bb:bb:bb:bb:bb
    192.0.2.205
    Compute
    DHCP definiert
    cc:cc:cc:cc:cc:cc
    192.0.2.206
  • Eine Netzwerkverbindung für Ihr Externes Netzwerk. Alle Knoten müssen mit diesem Netzwerk verbunden sein. Für dieses Beispiel benutzt man 10.1.1.0/24 für das Externe Netzwerk.
  • Alle anderen Netzwerktypen benutzen das Provisioning-Netzwerk für OpenStack Dienste

6.2.1. Registrieren der Knoten für die Einfache Overcloud

In diesem Abschnitt wird eine Knoten-Definitionsvorlage erstellt. Diese Datei (instackenv.json) ist eine JSON Formatdatei und enthält die Hardware und Energieverwaltungsdetails für Ihre zwei Knoten. Zum Beispiel: 
{
    "nodes":[
        {
            "mac":[
                "bb:bb:bb:bb:bb:bb"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.205"
        },
        {
            "mac":[
                "cc:cc:cc:cc:cc:cc"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.206"
        }
    ]
}
Diese Vorlage benutzt folgende Attribute
mac
Eine Liste von MAC-Adressen für die Netzwerkschnittstellen auf dem Knoten. Benutzen Sie nur die MAC-Adresse für den Provisioning NIC jedes Systems.
cpu
Die Anzahl der CPUs auf dem Knoten.
Speicher
Die Speichermenge in MB.
Datenträger
Die Größe der Festplatte in GB.
arch
Die Systemarchitektur
pm_type
Zu verwendender Energieverwaltungs-Driver. Dieses Beispiel benutzt den IPMI-Driver (pxe_ipmitool).
pm_user, pm_password
IPMI-Benutzername und Passwort.
pm_addr
Die IP-Adresse des IPMI-Geräts.

Anmerkung

Weitere unterstützte Energieverwaltungstypen und deren Optionen finden Sie unter Anhang B, Energieverwaltungs-Driver.
Speichern Sie die Datei nach Erstellung der Vorlage im stack Home-Verzeichnis des Benutzers (/home/stack/instackenv.json) und importieren Sie sie dann in den Director. Benutzen Sie dafür folgenden Befehl: 
$ openstack baremetal import --json ~/instackenv.json
Das importiert die Vorlage und registriert jeden Knoten aus der Vorlage im Director.
Kernel und ramdisk Images allen Knoten zuweisen: 
$ openstack baremetal configure boot
Die Knoten sind jetzt im Director registriert und konfiguriert. Mit folgendem Befehl wird Ihnen eine Liste dieser Knoten im CLI angezeigt: 
$ openstack baremetal list

6.2.2. Prüfen der Knoten-Hardware

Nach Registrierung der Knoten überprüft man die Hardware-Attribute jedes Knotens. Führen Sie folgenden Befehl aus um die Hardwareattribute jedes Knotens zu überprüfen: 
$ openstack baremetal introspection bulk start

Wichtig

Lassen Sie diesen Prozess bis zum Ende durchlaufen. Dieser Prozess dauert gewöhnlich 15 Minuten für Bare-Metal Knoten.

6.2.3. Manuelles Taggen der Knoten

Nach Registrierung und Überprüfung der Hardware jedes Knotens müssen sie in bestimmte Profile getaggt werden. Diese Profil-Tags sind mit den Varianten Ihrer Knoten abgestimmt und die Varianten sind wiederum einer Bereitstellungsrolle zugewiesen. Für das Einfache Bereitstellungsszenario taggt man die Knoten manuell, da es nur zwei gibt. Für eine größere Anzahl von Knoten, verwenden Sie die Tools zum Automated Health Check (AHC) im Erweiterten Bereitstellungsszenario. Weitere Details über die Tools zum Automated Health Check (AHC) unter Abschnitt 6.3.3, »Automatisches Knoten-Tagging mit Automated Health Check (AHC) Tools«.
Um einen Knoten manuell zu einem bestimmten Profil zu taggen, fügen Sie eine profile Option zum properties/capabilities Parameter für jeden Knoten hinzu. Zum Beispiel können Sie mit folgendem Befehl Ihre beiden Knoten tagen jeweils ein Controller-Profil und ein Compute-Profil zu benutzen: 
$ ironic node-update 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 add properties/capabilities='profile:compute,boot_option:local'
$ ironic node-update 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 add properties/capabilities='profile:control,boot_option:local'
Das Hinzufügen der profile:compute und profile:control Optionen taggt die zwei Knoten in die jeweiligen Profile.
Diese Befehle setzen auch den boot_option:local Parameter, der den Startmodus für jeden Knoten definiert.

6.2.4. Erstellen von Varianten für das Einfache Szenario

Der Director benötigt auch eine Reihe von Hardware-Profilen oder Varianten für die registrierten Knoten. In diesem Szenario wird ein Profil für den Compute und ein Profil für den Controller-Knoten erstellt. 
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 control
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute
Dies erstellt zwei Varianten für Ihre Knoten: control und compute. Zudem werden auch die zusätzlichen Eigenschaften für jede Variante bestimmt. 
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="compute" compute
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="control" control
capabilities:boot_option setzt den Startmodus für die Variante und capabilities:profile bestimmt das zu verwendende Profil. Dies verknüpft mit demselben Tag auf dem jeweiligen Knoten gemäß Abschnitt 6.2.3, »Manuelles Taggen der Knoten«.

6.2.5. Isolieren des Externen Netzwerks

Der Director bietet Methoden um isolierte Overcloud-Netzwerke zu konfigurieren. Das bedeutet, dass die Overcloud-Umgebung Netzwerkdatenverkehrstypen auf verschiedene Netzwerke aufteilt, was wiederum Netzwerkdatenverkehr bestimmten Netzwerkschnittstellen oder Bonds zuweist. Nach dem Konfigurieren isolierter Netzwerke konfiguriert der Director die OpenStack Dienste darauf, isolierte Netzwerke zu benutzen. Wenn keine isolierten Netzwerke konfiguriert sind, laufen alle Dienste auf dem Provisioning-Netzwerk.
Dieses Szenario benutzt zwei separate Netzwerke:
  • Netzwerk 1 - Provisioning-Netzwerk. Das Interne API, Speicher, Speicherverwaltung und auch Mandantennetzwerke verwenden dieses Netzwerk.
  • Netzwerk 2 - Externes Netzwerk. Dieses Netzwerk verwendet eine dedizierte Schnittstelle zur Verbindung außerhalb der Overcloud.
Die folgenden Abschnitte zeigen, wie man Heat-Vorlagen erstellt um das Externe Netzwerk von den übrigen Diensten zu isolieren.

6.2.5.1. Erstellen von benutzerdefinierten Schnittstellenvorlagen

Die Netzwerkkonfiguration der Overcloud erfordert eine Reihe von Netzwerkschnittstellenvorlagen. Passen Sie diese Vorlagen an um die Knotenschnittstellen auf einer pro-Rolle-Basis zu konfigurieren. Diese Vorlagen sind Standard-Heat-Vorlagen im YAML Format (vgl. Kapitel 5, Heat-Vorlagen verstehen). Der Director enthält eine Reihe von Beispielvorlagen um Ihnen den Einstig zu erleichtern:
  • /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans - Verzeichnis mit Vorlagen für einzelnen NIC mit VLANs Konfiguration auf pro-Rolle-Basis.
  • /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans - Verzeichnis mit Vorlagen für verbundene NIC Konfiguration auf einer pro-Rolle-Basis.
Für das Einfache Overcloud-Szenario benutzt man die standardmäßige, einfache NIC-Beispielkonfiguration. Kopieren Sie das Standard-Konfiguationsverzeichnis in das stack Home-Verzeichnis des Benutzers als nic-configs. 
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans ~/templates/nic-configs
Dies erstellt eine lokale Gruppe von Heat-Vorlagen, die eine einzelne Netzwerkschnittstellenkonfiguration definieren, welche das Externe Netzwerk benutzt. Jede Vorlage enthält Standard parameters, resources und output Abschnitte. Für Ihre Zwecke muss nur der resources Abschnitt bearbeitet werden. Jeder resources Abschnitt beginnt folgendermaßen: 
resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
Dies erstellt eine Anforderung für den os-apply-config Befehl und os-net-config Sub-Befehl um die Netzwerkeigenschaften für einen Knoten zu konfigurieren. Der network_config Abschnitt enthält Ihre benutzerdefinierte Schnittstellenkonfiguration, angeordnet in einer Typ-basierten Sequenz, die Folgendes beinhaltet:
Schnittstelle
Definiert eine einzelne Netzwerkschnittstelle. Die Konfiguration definiert jede Schnittstelle, indem sie entweder den eigentlichen Schnittstellennamen ("eth0", "eth1", "enp0s25") oder eine Reihe von nummerierten Schnittstellen ("nic1", "nic2", "nic3") verwendet. 
            - type: interface
              name: nic2
vlan
Definiert ein VLAN. Benutzen Sie VLAN-ID und Subnetz aus dem parameters Abschnitt. 
            - type: vlan
              vlan_id: {get_param: ExternalNetworkVlanID}
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}
ovs_bond
Definiert ein Bond in Open vSwitch. Ein Bond verbindet zwei oder mehrere interfaces miteinander um mit Redundanz zu helfen und die Bandbreite zu erhöhen. 
            - type: ovs_bond
              name: bond1
              members:
              - type: interface
                name: nic2
              - type: interface
                name: nic3
ovs_bridge
Definiert eine Brücke in Open vSwitch. Eine Brücke verbindet mehrere interface, bond und vlan Objekte miteinander. 
            - type: ovs_bridge
              name: {get_input: bridge_name}
              members:
                - type: ovs_bond
                  name: bond1
                  members:
                    - type: interface
                      name: nic2
                      primary: true
                    - type: interface
                      name: nic3
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ExternalIpSubnet}
Unter Anhang D, Netzwerkschnittstellen-Parameter finden Sie eine vollständige Liste von Parametern für jedes dieser Elemente.
Ändern Sie für das Einfache Szenario jede Schnittstellen-Vorlage, um das Externe Netzwerk auf nic2 zu verschieben. So wird sichergestellt, dass die zweite Netzwerkschnittstelle auf jedem Knoten für das Externe Netzwerk benutzt wird. Zum Beispiel bei der templates/nic-configs/controller.yaml Vorlage: 
          network_config:
            - type: ovs_bridge
              name: {get_input: bridge_name}
              use_dhcp: true
              members:
                - type: interface
                  name: nic1
                  # force the MAC address of the bridge to this interface
                  primary: true
                - type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: InternalApiIpSubnet}
                - type: vlan
                  vlan_id: {get_param: StorageNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: StorageIpSubnet}
                - type: vlan
                  vlan_id: {get_param: StorageMgmtNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: StorageMgmtIpSubnet}
                - type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: TenantIpSubnet}
            - type: interface
              name: nic2
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}
              routes:
                - ip_netmask: 0.0.0.0/0
                  next_hop: {get_param: ExternalInterfaceDefaultRoute}
Das Beispiel oben erstellt eine neue Schnittstelle (nic2) und weist die Adressen und Routen des Externen Netzwerks der neuen Schnittstelle zu.
Weitere Beispiele für Vorlagen von Netzwerkschnittstellen finden Sie unter Anhang E, Beispiele für Netzwerkschnittstellenvorlagen.
Beachten Sie, dass viele dieser Parameter die get_param Funktion verwenden. Man definiert diese in einer Umgebungsdatei, die man speziell für Ihre Netzwerke erstellt.

Wichtig

Deaktivieren Sie unbenutzte Schnittstellen um ungewollte Standardrouten und Netzwerkschleifen zu vermeiden. Zum Beispiel: 
- type: interface
  name: nic1
  use_dhcp: true
Stellen Sie sicher, dass diese Schnittstellen aus allen Brücken entfernt sind.

6.2.5.2. Erstellen der Netzwerkumgebungs-Vorlage einer Einfachen Overcloud

Die Netzwerkumgebungsdatei beschreibt die Netzwerkumgebung der Overcloud und verweist auf die Netzwerkschnittstellen-Konfigurationsdateien des vorherigen Abschnitts. Man definiert die Subnetze für das Netzwerk mit IP-Adressbereichen und passt diese Werte der lokalen Umgebung an.
Dieses Szenario benutzt die folgende, als /home/stack/templates/network-environment.yaml gespeicherte Netzwerkumgebungsdatei: 
resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/ceph-storage.yaml

parameters:
  # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
  Controller-1::NeutronExternalNetworkBridge: "''"

parameter_defaults:
  ExternalNetCidr: 10.1.1.0/24
  ExternalAllocationPools: [{'start': '10.1.1.2', 'end': '10.1.1.50'}]
  ExternalNetworkVlanID: 100
  ExternalInterfaceDefaultRoute: 10.1.1.1
Der resource_registry Abschnitt enthält Links zu den Netzwerkschnittstellenvorlagen für jede Knotenrolle. Beachten Sie, dass der ExternalAllocationPools Parameter nur einen kleinen Bereich von IP-Adressen definiert, damit man später einen separaten Bereich von floating IP-Adressen definieren kann.
Der parameters Abschnitt definiert die für floating IP-Adressen zu verwendende Brücke. Wenn floating IP-Adressen ein getaggtes VLAN benutzen, lassen Sie den Wert als einfache Anführungszeichen (vorgegeben als br-int). Stellen Sie ihn ansonsten auf die vorgegebene externe Brücke, die normalerweise br-ex ist.

Wichtig

Der NeutronExternalNetworkBridge Parameter erfordert das Controller-1:: Präfix und muss bei der Erstellung einer Plan-basierten Overcloud Teil des parameters Abschnitts sein. Das liegt daran, dass der Plan seine Parameter auf eine bestimmte Weise verarbeitet. Bei der Erstellung einer benutzerdefinierten, auf Heat-Vorlagen basierten Overcloud, wie im Erweiterten Overcloud-Szenario, ist der Parameter NeutronExternalNetworkBridge und im parameter_defaults Abschnitt platziert. Diese Differenz können Sie unter Abschnitt 6.3.7.2, »Erstellen einer Netzwerkumgebungsdatei einer Erweiterten Overcloud « einsehen.
Der parameter_defaults Abschnitt enthält eine Liste von Parametern, die die Netzwerkoptionen für jeden Netzwerktyp definieren. Eine vollständige Referenz dieser Optionen finden Sie unter Anhang F, Netzwerkumgebungs-Optionen.
Dieses Szenario definiert nur die Optionen für das Externe Netzwerk. Alle anderen Datenverkehrstypen sind automatisch dem Provisioning-Netzwerk zugewiesen.

Wichtig

Eine Änderung der Netzwerkkonfiguration nach Erstellung der Overcloud kann aufgrund der Ressourcenverfügbarkeit zu Konfigurationsproblemen führen. Wenn ein Benutzer zum Beispiel den Subnetzbereich für ein Netzwerk in den Netzwerkisolationsvorlagen ändert, könnte die Neukonfiguration fehlschlagen, weil das Subnetz bereits benutzt wird.

6.2.6. Erstellen der Einfachen Overcloud

Als letzten Schritt zur Erstellung Ihrer OpenStack Umgebung müssen die notwendigen Befehle ausgeführt werden. Der Standardplan installiert einen Controller-Knoten und einen Compute-Knoten.

Prozedur 6.7. Erstellen der Overcloud

  1. Führen Sie folgenden Befehl aus um den Overcloud-Plan anzuzeigen: 
    $ openstack management plan list
    Dies zeigt den Plan und seinen UUID an. Notieren Sie diesen UUID für den nächsten Schritt.
  2. Führen Sie folgenden Befehl aus um die Erstellung der Einfachen Overcloud zu starten. Achten Sie darauf [UUID] mit dem UUID des vorherigen Schrittes zu ersetzen: 
    $ openstack overcloud deploy --plan "[UUID]" -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /home/stack/network-environment.yaml --control-flavor control --compute-flavor compute
    Dieser Befehl enthält folgende Zusatzoptionen:
    • --plan - Bestimmt, welcher Plan zur Erstellung der Overcloud benutzt werden soll. Dies ist immer der UUID des Overcloud-Plans.
    • -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml - Die -e Option fügt eine zusätzliche Umgebungsdatei zum Overcloud-Plan hinzu. In diesem Fall handelt es sich um eine Umgebungsdatei, die die Netzwerkisolations-Konfiguration initiiert.
    • -e /home/stack/templates/network-environment.yaml - Die -e Option fügt eine zusätzliche Umgebungsdatei zum Overcloud-Plan hinzu. In diesem Fall handelt es sich um die Netzwerk-Umgebungsdatei, die Sie in Abschnitt 6.2.5.2, »Erstellen der Netzwerkumgebungs-Vorlage einer Einfachen Overcloud « erstellt haben.
    • --control-flavor control - Benutzen Sie eine spezielle Variante für die Controller-Knoten.
    • --compute-flavor compute - Benutzen Sie eine spezielle Variante für die Compute-Knoten.

Anmerkung

Um eine vollständige Liste anzuzeigen, führen Sie folgenden Befehl aus: 
$ openstack help overcloud deploy
Unter Anhang G, Bereitstellungsparameter finden Sie Beispiele für Parameter.
Der Prozess zur Erstellung der Overcloud beginnt und der Director stellt Ihre Knoten bereit. Dieser Prozess dauert eine Weile. Um den Status der Overcloud-Erstellung sehen zu können, öffnen Sie ein separates Terminal als stack Benutzer und führen Sie folgenden Befehl aus: 
$ source ~/stackrc                # Initializes the stack user to use the CLI commands
$ heat stack-list --show-nested
Der heat stack-list --show-nested Befehl zeigt die aktuelle Phase der Overcloud-Erstellung an.

Wichtig

Beachten Sie, dass die zur Overcloud hinzugefügten Umgebungsdateien die -e Option benutzen. Der Director benutzt diese Umgebungsdateien für bestimmte Funktionen in Kapitel 7, Aufgabenausführung nach Erstellung der Overcloud.

6.2.7. Zugriff auf die Einfache Overcloud

Der Director erzeugt eine Datei um Interaktionen mit Ihrer Overcloud von der Undercloud zu konfigurieren und zu authentifizieren. Der Director speichert diese Datei als overcloudrc im stack Home-Verzeichnis Ihres Benutzers. Um diese Datei zu benutzen führen Sie folgenden Befehl aus: 
$ source ~/overcloudrc
Dies lädt die notwendigen Umgebungsvariablen um mit Ihrer Overcloud vom CLI des Director Hosts zu interagieren. Um wieder mit dem Host des Directors zu interagieren, führen Sie folgenden Befehl aus: 
$ source ~/stackrc

6.2.8. Fertigstellen der Einfachen Overcloud

Dies schließt die Erstellung der Einfachen Overcloud ab. Funktionen, die Sie nach der Erstellung benutzen können, finden Sie unter Kapitel 7, Aufgabenausführung nach Erstellung der Overcloud.