Installation und Verwendung des Directors

Red Hat Enterprise Linux OpenStack Platform 7

End-to-End Szenario zur Erstellung einer OpenStack Cloud mit dem Red Hat Enterprise Linux OpenStack Platform Director

OpenStack Dokumentations-Team

Red Hat Customer Content Services

Zusammenfassung

Dieses Handbuch erklärt, wie man Red Hat Enterprise Linux OpenStack Platform 7 mithilfe des Red Hat Enterprise Linux OpenStack Platform Directors in eine Unternehmensumgebung installiert. Dies beinhaltet die Installation des Directors, die Planung der Umgebung und die Erstellung der OpenStack Umgebung mit dem Director.

Kapitel 1. Einführung

Der Red Hat Enterprise Linux OpenStack Platform Director ist ein Toolset für die Installation und Verwaltung einer kompletten OpenStack Umgebung. Er basiert hauptsächlich auf dem OpenStack Projekt TripleO, was für "OpenStack-On-OpenStack" steht. Dieses Projekt nutzt OpenStack Komponenten um eine voll funktionstüchtige OpenStack Umgebung zu installieren. Dies umfasst neue OpenStack Komponenten, die Bare-Metal-Systeme bereitstellen und steuern, um sie als OpenStack Knoten zu verwenden. Das bietet eine einfache Methode um eine komplette Red Hat Enterprise Linux OpenStack Platform Umgebung zu installieren, die sowohl schlank als auch robust ist.
Der Red Hat Enterprise Linux OpenStack Platform Director benutzt zwei Hauptkonzepte: eine Undercloud und eine Overcloud. Die Undercloud installiert und konfiguriert die Overcloud. In den folgenden Abschnitten werden diese Konzepte näher erläutert.
Basic Layout of Undercloud and Overcloud

Abbildung 1.1. Grundsätzliches Layout von Undercloud und Overcloud

1.1. Undercloud

Die Undercloud ist der Haupt-Director-Knoten. Dies ist eine Einzelsystem-Installation von OpenStack mit Komponenten für Provisioning und Verwaltung der OpenStack Knoten, die aus Ihrer OpenStack Umgebung (der Overcloud) bestehen. Die Komponenten, die die Undercloud bilden, bieten folgende Funktionen:
  • Umgebungsplanung - Die Undercloud bietet den Benutzern Planungsfunktionen um der Red Hat Enterprise Linux OpenStack Platform Rollen zuzuweisen, einschließlich Compute, Controller und verschiedener Speicherrollen.
  • Bare-Metal-System Kontrolle - Die Undercloud verwendet das Intelligent Platform Management Interface (IPMI) jedes Knotens um die Energieverwaltung zu steuern und einen PXE-basierten Dienst um Hardware Eigenschaften zu ermitteln und OpenStack in jedem Knoten zu installieren. Dies bietet eine Methode um Bare-Metal-Systeme als OpenStack Knoten bereitzustellen.
  • Orchestrierung - Die Undercloud liefert und liest eine Reihe von YAML-Vorlagen um eine OpenStack Umgebung zu erstellen.
Der Red Hat Enterprise Linux OpenStack Platform Director verwendet diese Undercloud-Funktionen sowohl durch eine web-basierte, graphische Benutzeroberfläche, als auch durch eine Terminal-basierte Befehlszeilenschnittstelle.
Die Undercloud verwendet folgende Komponenten:
  • OpenStack Dashboard (Horizon) - Web-basiertes Dashboard für den Director.
  • OpenStack Bare Metal (Ironic) und OpenStack Compute (Nova) - Verwaltet Bare-Metal-Knoten.
  • OpenStack Networking (Neutron) und Open vSwitch- Kontrolliert das Netzwerk für Bare-Metal-Knoten.
  • OpenStack Image Server (Glance) - Speichert Images, die Bare-Metal-Rechnern zugeschrieben sind.
  • OpenStack Orchestrierung (Heat) und Puppet - Regelt Orchestrierung der Knoten, sowie Konfiguration der Knoten, nachdem der Director das Overcloud Image auf den Datenträger geschrieben hat.
  • OpenStack Telemetry (Ceilometer) - Zur Überwachung und Datensammlung.
  • OpenStack Identity (Keystone) - Authentifizierung der Director-Komponenten.
  • MariaDB - Datenbank für den Director.
  • RabbitMQ - Nachrichten-Warteschlange für die Director-Komponenten.

1.2. Overcloud

Die Overcloud ist die resultierende Red Hat Enterprise Linux OpenStack Platform Umgebung, die unter Verwendung der Undercloud erstellt wurde. Das umfasst einen oder mehrere der folgenden Knotentypen:
  • Controller - Knoten, die Administration, Networking und hohe Verfügbarkeit für die OpenStack Umgebung bieten. Für eine ideale OpenStack Umgebung werden drei dieser Knoten zusammen in einem Hochverfügbarkeitscluster empfohlen.
    Ein Standard Controller-Knoten enthält die folgenden Komponenten: Horizon, Keystone, Nova API, Neutron Server, Open vSwitch, Glance, Cinder Volume, Cinder API, Swift Storage, Swift Proxy, Heat Engine, Heat API, Ceilometer, MariaDB, RabbitMQ. Der Controller verwendet auch Pacemaker und Galera für Hochverfügbarkeitsfunktionen.
  • Compute - Knoten, die verwendet werden um Rechenressourcen für die OpenStack Umgebung bereitzustellen. Fügen sie weitere Compute-Knoten hinzu um Ihre Umgebung mit der Zeit zu skalieren.
    Ein Standard Compute-Knoten enthält folgende Komponenten: Nova Compute, Nova KVM, Ceilometer Agent, Open vSwitch
  • Speicher - Knoten, die Speicher für die OpenStack Umgebung bereitstellen. Dies umfasst Knoten für:
    • Ceph-Storage-Knoten - Werden verwendet um Speichercluster zu bilden. Jeder Knoten enthält ein Ceph Object Storage Daemon (OSD). Zusätzlich installiert der Director immer, wenn er Ceph-Storage-Knoten bereitstellt, Ceph-Monitor auf die Controller-Knoten.
    • Block storage (Cinder) - Wird als externer Blockspeicher für HA Controller-Knoten verwendet. Dieser Knoten enthält folgende Komponenten: Cinder Volume, Ceilometer Agent, Open vSwitch.
    • Object storage (Swift) - Wird als externer Objektspeicher für HA Controller-Knoten verwendet. Dieser Knoten enthält folgende Komponenten: Cinder Storage, Ceilometer Agent, Open vSwitch.

1.3. Hochverfügbarkeit

Hochverfügbarkeit bietet einem System oder Komponenten kontinuierliche Ausführung über eine ausgedehnte Zeitspanne hinweg. Der Red Hat Enterprise Linux OpenStack Platform Director bietet einer OpenStack Platform Umgebung mittels eines Controller-Knotenclusters Hochverfügbarkeit. Der Director installiert eine bestimmte Anzahl von gleichen Komponenten bei jedem Controller-Knoten und verwaltet diese als einen Gesamtdienst. Ein Cluster bietet ein Fallback, falls bei einem einzelnen Controller-Knoten Betriebsfehler auftreten. Das bietet OpenStack Benutzern einen gewissen Grad von kontinuierlicher Ausführung.
Der OpenStack Platform Director verwendet einige Schlüsselbestandteile der Software um Komponenten am Controller-Knoten zu verwalten:
  • Pacemaker - Pacemaker ist ein Clusterressourcen-Manager. Pacemaker verwaltet und überwacht die Verfügbarkeit von OpenStack Komponenten aller Rechner in einem Cluster.
  • HA Proxy - Regelt Lastenausgleich und Proxydienste im Cluster.
  • Galera - Regelt Replikation der OpenStack Platform Datenbank im Cluster.
  • Memcached - Regelt Datanbank-Caching.
Der Director installiert und konfiguriert die Hochverfügbarkeitstools automatisch darauf, die erforderlichen OpenStack Komponenten und Datenbanken zu verwalten. Weitere Konzeptinformationen über Red Hat Enterprise Linux OpenStack Platform und Hochverfügbarkeitsfeatures finden Sie unter RHEL OpenStack High Availability (RHEL OSP7) im Red Hat Kundenportal.

Anmerkung

OpenStack Platform Director konfiguriert automatisch das Hochverfügbarkeitsgebinde auf Controller-Knoten. Die Knoten benötigen jedoch manuelle Konfiguration um Fencing und Energieverwaltungssteuerung zu aktivieren. Das vorliegende Handbuch enthält diese Anleitungen.

1.4. Ceph-Storage

Große Unternehmen, die OpenStack verwenden, dienen häufig Tausenden von Clients. Jeder OpenStack Client verwendet Blockspeicherressourcen nach seinen eigenen, speziellen Bedürfnissen. Die Bereitstellung von Glance (Images), Cinder (Volumen) und/oder Nova (Compute) auf einem einzelnen Knoten ist bei großen Bereitstellungen mit Tausenden von Client unmöglich zu verwalten. Eine externe Skalierung von OpenStack kann diese Herausforderung meistern.
Dennoch wird es zu einer praktischen Anforderung, die Speicherebenen mit einer Lösung wie Red Hat Ceph-Storage zu virtualisieren, damit Sie die Red Hat Enterprise Linux OpenStack Platform Speicherebene vom zweistelligen Terabytebereich des Speichers auf Petabyte oder sogar Exabyte skalieren können. Red Hat Ceph-Storage bietet diese Speichervirtualisierungsebene mit Hochverfügbarkeit und Hochleistung unter Verwendung von gewöhnlicher Hardware. Während Virtualisierung vielleicht den Anschein erweckt mit Leistungseinbußen einherzugehen, blockieren Ceph-Streifen Gerätebilder als Objekte im ganzen Cluster. Das bedeutet, dass große Ceph Block Device Images eine bessere Leistung erzielen, als alleinstehende Datenträger. Ceph Block Geräte unterstützen auch Caching, copy-on-write Cloning und copy-on-read Cloning für bessere Leistung.
Unter Red Hat Ceph Storage finden Sie weitere Informationen über Red Hat Ceph Storage.

Kapitel 2. Anforderungen

Dieses Kapitel erläutert die Hauptanforderungen bei der Einrichtung einer Umgebung um Red Hat Enterprise Linux OpenStack Platform unter Verwendung des Directors bereitzustellen. Dies beinhaltet die Anforderungen bei Einrichtung und Zugriff auf den Director und die Hardwareanforderungen an Hosts, die der Director für OpenStack Services bereitstellt.

2.1. Umgebungsanforderungen

Minimale Anforderungen

  • 1 Host Rechner für den Red Hat Enterprise Linux OpenStack Platform Director
  • 1 Host Rechner für einen Red Hat Enterprise Linux OpenStack Platform Compute-Knoten
  • 1 Host Rechner für einen Red Hat Enterprise Linux OpenStack Platform Controller-Knoten

Empfohlene Anforderungen

  • 1 Host Rechner für den Red Hat Enterprise Linux OpenStack Platform Director
  • 3 Host Rechner für Red Hat Enterprise Linux OpenStack Platform Compute-Knoten
  • 3 Host Rechner für Red Hat Enterprise Linux OpenStack Platform Controller-Knoten in einem Cluster
  • 3 Host Rechner für Red Hat Ceph-Storage-Knoten in einem Cluster
Beachten Sie bitte Folgendes:
  • Es wird empfohlen für alle Knoten Bare-Metal-Systeme zu verwenden. Jedoch erfordern zumindest die Compute-Knoten Bare-Metal-Systeme.
  • Alle Overcloud Bare-Metal-Systeme erfordern eine Intelligent Platform Management Interface (IPMI). Das liegt daran, dass der Director die Energieverwaltung steuert.

2.2. Undercloud-Anforderungen

Das Undercloud System, das den Director hostet, bietet Provisioning und Verwaltung für alle Knoten in der Overcloud.
  • 64-bit x86 Prozessor mit Support für Intel 64 oder AMD64 CPU Erweiterung.
  • Mindestens 6 GB RAM
  • Mindestens 40 GB von verfügbarem Disk-Speicherplatz
  • Ein Minimum von 2 x 1 Gbps Netzwerkkarten. Es wird jedoch empfohlen eine 10Gbps Schnittstelle für Provisioning Datenverkehr zu verwenden, besonders wenn eine große Anzahl von Knoten in Ihrer Overcloud-Umgebung bereitgestellt wird.
  • Red Hat Enterprise Linux 7.1 ist als Host Betriebssystem installiert.

2.3. Netzwerkanforderungen

Der Undercloud Host erfordert mindestens zwei Netzwerke:
  • Provisioning-Netzwerk - Dies ist ein privates Netzwerk, das der Director benutzt um die Overcloud-Knoten bereitzustellen und zu verwalten. Das Provisioning-Netzwerk bietet DHCP und PXE Boot Funktionen um zu helfen Bare-Metal-Systeme zur Verwendung in der Overcloud ausfindig zu machen. Dieses Netzwerk sollte am besten ein systemeigenes VLAN auf einer Trunk-Schnittstelle verwenden, sodass der Director PXE Boot und DHCP Anfragen bedient. Dieses Netzwerk muss auch benutzt werden um die Energieverwaltung mit der Intelligent Platform Management Interface (IPMI) auf allen Overcloud Knoten zu steuern.
  • Externes Netzwerk - Ein separates Netzwerk für Remoteverbindungen zu allen Knoten. Die Schnittstelle, die mit diesem Netzwerk verbunden ist, benötigt eine routingfähige IP Adresse, entweder statistisch oder dynamisch durch eine externen DHCP Dienst bestimmt.
Beachten Sie bitte Folgendes:
  • Alle Rechner erfordern mindestens zwei NICs. Ein NIC wird für das Provisioning-Netzwerk über ein systemeigenes VLAN verwendet. Der andere NIC wird für markierte VLANs benutzt, die Subnetze für verschiedene Overcloud Netzwerktypen verwenden.
  • Die Netzwerkinfrastruktur erfordert ein Switch, das die 802.1Q-Standards unterstützt um markierte VLANs bereitzustellen.
  • Alle Overcloud Bare-Metal-Systeme erfordern ein Intelligent Platform Management Interface (IPMI), das mit dem Provisioning-Netzwerk verbunden ist. Der Director steuert die Energieverwaltung jedes Knotens.
  • Während der Erstellung der Overcloud wird darauf verwiesen, dass NICs in allen Overcloud Rechnern einen einzigen Namen benutzen. Idealerweise sollte bei jedem System für jedes jeweilige Netzwerk derselbe NIC benutzt werden um Verwechslungen zu vermeiden. Benutzen Sie zum Beispiel den primären NIC für das Provisioning-Netzwerk und den sekundären NIC für die OpenStack Dienste.
  • Zusätzliche NICs können verwendet werden um verbundene Schnittstellen zu erstellen oder um markierten VLAN-Datenverkehr zu delegieren.
  • Stellen Sie sicher, dass der NIC des Provisioning-Netzwerks nicht derselbe NIC ist, der für Remoteverbindungen auf dem Director-Rechner benutzt wird. Die Installation des Directors erzeugt unter Verwendung des Provisioning NICs eine Brücke, was alle Remoteverbindungen trennt. Verwenden Sie den Externen NIC für Remoteverbindungen zum Directorsystem.
  • Stellen Sie alle Overcloud Systeme auf PXE-Boot vom Provisioning NIC und deaktivieren Sie PXE Boot auf dem Externen NIC und allen anderen NICs im System. Stellen Sie zudem sicher, dass PXE Boot für Provisioning NIC an der Spitze der Boot Reihenfolge steht, vor Festplatten und CD/DVD Laufwerken.
  • Beachten Sie folgende Details für jedes Overcloud System: die MAC-Adresse des Provisioning NIC, die IP-Adresse des IPMI NIC, IPMI-Benutzername und IPMI-Passwort. Diese Information ist hilfreich bei der Einstellung der Overcloud-Knoten.

2.4. Overcloud-Anforderungen

Die folgenden Abschnitte führen die Anforderungen für individuelle Systeme und Knoten in der Overcloud-Installation an.

2.4.1. Compute-Knotenanforderungen

Compute-Knoten sind für die Ausführung von Instanzen der virtuellen Maschine zuständig, nachdem sie gestartet wurden. Compute-Knoten müssen Hardwarevirtualisierung unterstützen. Sie müssen zudem über ausreichend Speicher und Datenträgerspeicherplatz verfügen, um die Anforderungen der Instanzen der virtuellen Maschine zu unterstützen, die sie hosten.
Prozessor
64-bit x86 Prozessor mit Support für Intel 64 oder AMD64 CPU-Erweiterungen und die aktivierten AMD-V oder Intel VT Hardwarevirtualisierungs-Erweiterungen. Es wird empfohlen, dass dieser Prozessor mindestens 4 Kerne hat.
Speicher
Mindestens 6 GB RAM
Zusätzliches RAM zu dieser Anforderung hinzufügen, basierend auf der Speichermenge, die Sie für Instanzen der virtuellen Maschine verfügbar machen möchten.
Disk-Speicherplatz
Mindestens 40 GB verfügbarer Disk-Speicherplatz
Netzwerkkarten
Ein Minimum von 2 x 1 Gbps Netzwerkkarten. Benutzen Sie zusätzliche Netzwerkkarten für verbundene Schnittstellen oder um markierten VLAN-Datenverkehr zu delegieren.
Intelligent Platform Management Interface (IPMI)
Jeder Compute-Knoten erfordert IPMI-Funktionalität auf der Hauptplatine des Servers.

2.4.2. Controller-Knotenanforderungen

Controller-Knoten sind zuständig für das Hosting der Kerndienste in einer RHEL OpenStack Platform Umgebung, wie Horizon Dashboard, Back-End Datenbank Server, Keystone Authentifizierung und Hochverfügbarkeitsdiensten.
Prozessor
64-bit x86 Prozessor mit Unterstützung für die Intel 64 oder AMD64 CPU-Erweiterungen.
Speicher
Mindestens 6 GB RAM
Disk-Speicherplatz
Mindestens 40 GB verfügbarer Disk-Speicherplatz
Netzwerkkarten
Ein Minimum von 2 x 1 Gbps Netzwerkkarten. Benutzen Sie zusätzliche Netzwerkkarten für verbundene Schnittstellen oder um markierten VLAN-Datenverkehr zu delegieren.
Intelligent Platform Management Interface (IPMI)
Jeder Controller-Knoten erfordert IPMI-Funktionalität auf der Hauptplatine des Servers.

2.4.3. Ceph-Storage-Knotenanforderung

Ceph-Storage-Knoten sind verantwortlich für die Bereitstellung von Speicherplatz in einer RHEL OpenStack Platform Umgebung.
Prozessor
64-bit x86 Prozessor mit Support für Intel 64 oder AMD64 CPU Erweiterungen.
Speicher
Speicheranforderungen hängen von der Menge des Speicherplatzes ab. Ideal ist ein Gebrauch von mindestens 1 GB Speicher pro 1 TB Festplatten-Speicherplatz.
Speicherplatz
Speicheranforderungen hängen von der Menge des Speichers ab. Ideal ist ein Gebrauch von mindestens 1 GB Speicher pro 1 TB Festplatten-Speicherplatz.
Datenträger-Layout
Jeder Ceph-Storage-Knoten benötigt ein Datenträger-Layout ähnlich dem Folgenden:
  • /dev/sda - Der Stammdatenträger. Der Director kopiert das Haupt-Overcloudimage auf den Datenträger.
  • /dev/sdb - Der Journal-Datenträger. Dieser Datenträger unterteilt für Ceph OSD-Journale in Partitionen. Zum Beispiel, /dev/sdb1, /dev/sdb2, /dev/sdb3 und weitere.
  • /dev/sdc und weiter - Der OSD-Datenträger. Verwenden Sie so viele Datenträger, wie für Ihre Speicheranforderungen nötig sind.
Dieses Handbuch enthält die nötigen Anweisungen, wie Sie Ihre Ceph-Storage-Datenträger dem Director zuweisen können
Netzwerkkarten
Ein Minimum von 2 x 1 Gbps Netzwerkkarten. Benutzen Sie zusätzliche Netzwerkkarten für verbundene Schnittstellen, oder um markierten VLAN-Datenverkehr zu delegieren. Empfohlen wird die Verwendung einer 10 Gbps Schnittstelle für Speicherknoten, besonders wenn eine Open Stack Platform Umgebung erstellt wird, die ein hohes Volumen von Datenverkehr verarbeitet.
Intelligent Platform Management Interface (IPMI)
Jeder Ceph Knoten erfordert IPMI Funktionalität auf der Hauptplatine des Servers.

Kapitel 3. Installieren der Undercloud

Der erste Schritt zur Erstellung Ihrer Red Hat Enterprise Linux OpenStack Platform Umgebung ist die Installation des Directors im Undercloud-System. Das setzt ein paar Schritte zur Aktivierung der notwendigen Abonnements und Repositorys voraus.

3.1. Erstellen eines Benutzers für die Director-Installation

Der Prozess zur Director-Installation erfordert einen non-root Benutzer zum Ausführen der Befehle. Benutzen Sie folgende Befehle um einen Benutzer namens stack anzulegen und ein Passwort einzurichten:
[root@director ~]# useradd stack
[root@director ~]# passwd stack  # specify a password
Passwortanforderungen für diesen Benutzer deaktivieren, wenn sudo benutzt wird:
[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
[root@director ~]# chmod 0440 /etc/sudoers.d/stack
Zum neuen stack Benutzer wechseln:
[root@director ~]# su - stack
[stack@director ~]$
Director-Installation als stack Benutzer fortsetzen.

3.2. Erstellen von Verzeichnissen für Vorlagen und Images

Das Verzeichnis benutzt System-Images und Heat-Vorlagen um die Overcloud-Umgebung zu erstellen. Um diese Dateien übersichtlich zu halten wird empfohlen, Verzeichnisse für Images und Vorlagen anzulegen:
$ mkdir ~/images
$ mkdir ~/templates
In anderen Abschnitten dieses Handbuches werden diese beiden Verzeichnisse benutzt um bestimmte Dateien zu speichern.

3.3. IP-Weiterleitung auf dem Director-Host aktivieren

Man kann den Director-Host als Gatewaysystem für das Provisioning-Netzwerk verwenden. Dafür muss der IP-Weiterleitungskernelparameter auf dem Director-Host eingestellt sein. Um IP-Weiterleitung dauerhaft einzustellen, bearbeiten Sie die /etc/sysctl.conf Datei und fügen Sie folgende Zeile hinzu:
net.ipv4.ip_forward = 1
Aktualisieren Sie dann Ihre Systemparameter mit folgendem Befehl:
$ sudo sysctl -p /etc/sysctl.conf

3.4. Bestimmen des Hostnamens für das System

Der Director benötigt für seinen Installations- und Konfigurationsprozess einen voll qualifizierten Domänennamen. Das bedeutet, dass Sie den Hostnamen für den Host Ihres Directors festlegen müssen. Überprüfen Sie den Hostnamen Ihres Hosts:
$ hostname    # Checks the base hostname
$ hostname -f # Checks the long hostname (FQDN)
Benutzen Sie gegebenenfalls hostnamectl um den Hostnamen festzulegen:
$ sudo hostnamectl set-hostname manager.example.com
$ sudo hostnamectl set-hostname --transient manager.example.com
$ sudo export HOSTNAME=manager.example.com
Der Director benötigt auch einen Eintrag für den Hostnamen des Systems und den Basisnamen in /etc/hosts. Wenn das System zum Beispiel manager.example.com genannt ist, benötigt /etc/hosts einen Eintrag wie:
127.0.0.1   manager.example.com manager

3.5. Registrieren Ihres Systems

Um den RHEL OpenStack Platform Installer zu installieren, registrieren Sie zuerst das Hostsystem über den Red Hat Subscription Manager und abonnieren Sie die nötigen Channels.

Prozedur 3.1. Abonnieren der Erforderlichen Channels über den Subscription Manager

  1. Registrieren Sie Ihr System im Content Delivery Network, indem Sie Ihren Benutzernamen und Ihr Passwort für das Kundenpoprtal eingeben:
    $ sudo subscription-manager register
  2. Suchen Sie den Berechtigungspool für den Red Hat Enterprise Linux OpenStack Platform Director.
    $ sudo subscription-manager list --available --all
    
  3. Benutzen Sie die im vorherigen Schritt gefundene Pool ID um die Red Hat Enterprise Linux OpenStack Platform 7 Berechtigung beizufügen:
    $ sudo subscription-manager attach --pool=pool_id
  4. Erforderliche Red Hat Enterprise Linux Repositorys aktivieren:
              $ sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-optional-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-openstack-7.0-rpms --enable=rhel-7-server-openstack-7.0-director-rpms
    
    Diese Repositorys enthalten Pakete, die zur Installation des Directors erforderlich sind.
  5. Aktualisieren Sie Ihr System um sicherzustellen, dass Sie über die neusten Basissystem-Pakete verfügen:
    $ sudo yum update -y
Das System ist jetzt bereit zur Installation des Directors.

3.6. Installieren der Director-Pakete

Benutzen Sie folgenden Befehl um die erforderlichen Befehlszeilentools für die Installation und Konfiguration des Directors zu installieren:
[stack@director ~]$ sudo yum install -y python-rdomanager-oscplugin
Dies installiert alle Pakete, die für die Installation des Directors erforderlich sind.

3.7. Konfiguration des Directors

Der Installationsprozess des Directors erfordert bestimmte Einstellungen um Ihre Netzwerkkonfigurationen festzulegen. Die Einstellungen sind in einer Vorlage im stack Home-Verzeichnis des Benutzers gespeichert als undercloud.conf
Red Hat bietet eine Basisvorlage um bei der Festlegung der für Ihre Installation erforderlichen Einstellungen zu helfen. Kopieren Sie diese Vorlage in das stack Home-Verzeichnis des Benutzers:
$ cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
Die Basisvorlage enthält folgende Parameter:
image_path
Definiert den Pfad zu den für Bereitstellungsrollen benutzten Images. Setzen Sie den Wert auf den stack Benutzer images: /home/stack/images
local_ip
Die für den Provisioning NIC des Directors definierte IP-Adresse. Dies ist auch die IP-Adresse, die der Director für seine DHCP und PXE-Boot-Dienste benutzt. Lassen Sie diesen Wert als Standard 192.0.2.1/24, außer Sie benutzen ein anderes Subnetz für das Provisioning-Netzwerk, d.h. es steht in Konflikt mit einer existierenden IP-Adresse oder einem existierenden Subnetz in Ihrer Umgebung.
undercloud_public_vip
Die für das Öffentliche API definierte IP-Adresse. Benutzen Sie eine IP-Adresse auf dem Provisioning-Netzwerk, die mit keiner anderen IP-Adresse oder Adressbereich in Konflikt steht.
undercloud_admin_vip
Die für das Admin-API des Directors deifnierte IP-Adresse. Benutzen Sie eine IP-Adresse auf dem Provisioning-Netzwerk, die mit keiner anderen IP-Adresse oder Adressbereich in Konflikt steht.
undercloud_service_certificate
Ort und Dateiname des Zertifikats für OpenStack SSL Kommunikation. Idealerweise beziehen Sie dieses Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle. Generieren Sie andernfalls mit folgendem Befehl Ihr selbstsigniertes Zertifikat:
$ openssl genrsa -out privkey.pem 2048
$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 365
$ cat cacert.pem privkey.pem > undercloud.pem
Dies erstellt eine undercloud.pem zur Verwendung mit der undercloud_service_certificate Option. Diese Datei erfordert einen speziellen SELinux Kontext, damit das HAProxy Tool ihn lesen kann. Benutzen Sie folgendes Beispiel als Leitfaden:
$ sudo mkdir /etc/pki/instack-certs
$ sudo cp ~/undercloud.pem /etc/pki/instack-certs/.
$ sudo semanage fcontext haproxy_t /etc/pki/instack-certs/*
$ sudo restorecon -R /etc/pki/instack-certs
local_interface
Die ausgewählte Schnittstelle für den Provisioning NIC des Directors. Dies ist auch das Gerät, das der Director für seine DHCP und PXE-Boot-Dienste benutzt. Ändern Sie diesen Wert auf das ausgewählte Gerät. ip addr zeigt Ihnen an, welches Gerät verbunden ist. Dies ist zum Beispiel das Resultat eines ip addr Befehls:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:75:24:09 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.178/24 brd 192.168.122.255 scope global dynamic eth0
       valid_lft 3462sec preferred_lft 3462sec
    inet6 fe80::5054:ff:fe75:2409/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noop state DOWN
    link/ether 42:0b:c2:a5:c1:26 brd ff:ff:ff:ff:ff:ff
In diesem Beispiel benutzt der Externe NIC eth0 und der Provisioning NIC eth1, welche momentan nicht konfiguriert sind. In diesem Fall stellen Sie local_interface auf eth1. Das Konfigurationsskript fügt diese Schnittstelle einer benutzerdefinierten, mit dem discovery_interface Parameter angegebenen Brücke an.
masquerade_network
Bestimmt die Masquerade des Netzwerks bei externem Zugriff. Dies bietet dem Provisioning-Netzwerk einen gewissen Grad an Netzwerkadressen Übersetzung (network adress translation; NAT), damit es externen Zugriff durch den Director hat. Lassen Sie dies als Standardeinstellung (192.0.2.0/24), außer Sie verwenden ein anderes Subnetz für das Provisioning-Netzwerk.
dhcp_start, dhcp_end
Start und Ende des DHCP-Zuweisungsbereiches für Overcloud-Knoten. Stellen Sie sicher, dass dieser Bereich genügend IP-Adressen enthält um Ihre Knoten zuzuweisen.
network_cidr
Das vom Director benutzte Netzwerk zur Verwaltung von Overcloud-Instanzen. Dies ist das Provisioning-Netzwerk. Lassen Sie dies als Standardeinstellung 192.0.2.0/24, außer Sie benutzen ein anderes Subnetz für das Provisioning-Netzwerk.
network_gateway
Das Gateway für die Overcloud-Instanzen. Dies ist der Discovery Host, der Datenverkehr an das Externe Netzwerk weitergibt. Lassen Sie dies als Standardeinstellung 192.0.2.1, außer Sie benutzen entweder eine andere IP-Adresse für den Director oder Sie wollen direkt ein externes Gateway benutzen.
discovery_interface
Die vom Director benutzte Brücke zur Knotensuche. Dies ist eine benutzerdefinierte, bei der Director-Konfiguration erstellte Brücke. Die LOCAL_INTERFACE heftet sich der Brücke an. Lassen Sie dies als Standardeinstellung br-ctlplane.
discovery_iprange
Ein Bereich von IP-Adressen, den der Suchdienst des Directors während dem PXE-boot und Provisioning-Prozess benutzt. Benutzen Sie kommagetrennte Werte um Start und Ende dieses Bereiches zu definieren. Zum Beispiel 192.0.2.100,192.0.2.120. Stellen Sie sicher, dass dieser Bereich genügend IP-Adressen für Ihre Knoten enthält und nicht mit dem Bereich von dhcp_start und dhcp_end in Konflikt steht.
discovery_runbench
Führt während der Knotensuche eine Reihe von Benchmarks durch. Aktivieren Sie dies, indem Sie 1 setzen. Das ist für die Durchführung einer Benchmark-Analyse notwendig, wenn Sie die Hardware auf registrierte Knoten im Erweiterten Szenario überprüfen wollen. Unter Abschnitt 6.3.3, »Automatisches Knoten-Tagging mit Automated Health Check (AHC) Tools« finden Sie weitere Details.
undercloud_debug
Stellt die Log-Ebene von Undercloud-Diensten auf DEBUG. Stellen Sie diesen Wert auf true zur Aktivierung.
undercloud_db_password, undercloud_admin_token, undercloud_admin_password, undercloud_glance_password, etc.
Die übrigen Parameter sind die Zugriffsdetails für alle Dienste des Directors. Es wird empfohlen diese Parameter leer zu lassen, damit das Konfigurationsskript des Directors automatisch diese Werte erzeugt. Sie können alle Werte nach Abschluss des Konfigurationsskripts abfragen.
Ändern Sie die Werte für diese Parameter um sie Ihrem Netzwerk anzupassen. Wenn dieser Vorgang abgeschlossen ist, speichern Sie die Datei und führen Sie folgenden Befehl aus:
$ openstack undercloud install
Dies startet das Konfigurationsskript des Directors. Der Director installiert zusätzliche Pakete und konfiguriert seine Dienste um sie den Einstellungen in undercloud.conf anzupassen. Die Ausführung dieses Skripts dauert einige Minuten.
Wenn das Konfigurationsskript abgeschlossen ist, erzeugt es zwei Dateien:
  • undercloud-passwords.conf - Eine Liste aller Passworte für die Dienste des Directors.
  • stackrc - Eine Reihe von Initialisierungsvariablen, die Ihnen den Zugriff auf die Befehlszeilentools des Directors erleichtern.
Um die Verwendung der Befehlszeilentools durch den stack Benutzer zu initialisieren, führen Sie folgenden Befehl aus:
$ source ~/stackrc
Sie können jetzt die Befehlszeilentools des Directors benutzen.

3.8. Abrufen von Images für die Overcloud-Knoten

Der Director benötigt mehrere Diskimages um Overcloud-Knoten bereitstellen zu können. Dies beinhaltet:
  • Ermittlungs-Kernel und Ramdisk - Wird für Bare-Metal Systemermittlung über PXE-Boot verwendet.
  • Bereitstellungs-Kernel und Ramdisk - Wird für Provisioning und Bereitstellung des Systems verwendet.
  • Overcloud Kernel, Ramdisk und volles Image - Ein Basissystem der Overcloud, das zur Festplatte des Knotens geschrieben ist.
Sie können diese Images auf der Red Hat Enterprise Linux OpenStack Platform Downloads Seite im Red Hat Kundenportal abrufen https://access.redhat.com/site/products/red-hat-enterprise-linux-openstack-platform/.
Laden Sie diese Images herunter in das images Verzeichnis im stack Home des Benutzers auf dem Verzeichnis-Host (/home/stack/images/). Führen Sie folgenden Befehl aus um diese Images in den Director zu importieren:
$ openstack overcloud image upload
Dies lädt folgende Images in den Director hoch: bm-deploy-kernel, bm-deploy-ramdisk, overcloud-full, overcloud-full-initrd, overcloud-full-vmlinuz. Diese Images sind für die Bereitstellung und die Overcloud. Das Skript installiert auch die Ermittlungsimages auf dem PXE-Server des Directors.
Mit folgendem Befehl rufen Sie eine Liste der Images im CLI ab:
$ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+
Diese Liste wird Ihnen nicht die Ermittlungs-PXE-Images anzeigen (discovery-ramdisk.*). Der Director kopiert diese Dateien zu /httpboot.
[stack@host1 ~]$ ls /httpboot -l
total 151636
-rw-r--r--. 1 ironic ironic       269 Sep 19 02:43 boot.ipxe
-rw-r--r--. 1 root   root         252 Sep 10 15:35 discoverd.ipxe
-rwxr-xr-x. 1 root   root     5027584 Sep 10 16:32 discovery.kernel
-rw-r--r--. 1 root   root   150230861 Sep 10 16:32 discovery.ramdisk
drwxr-xr-x. 2 ironic ironic      4096 Sep 19 02:45 pxelinux.cfg

3.9. Bestimmen eines Nameservers für die Overcloud

Overcloud-Knoten erfordern einen Nameserver, damit sie Hostnamen durch DNS auflösen können. Der Nameserver ist im neutron Subnetz der Undercloud definiert. Bestimmen Sie mit folgendem Befehl den Nameserver für die Umgebung:
$ neutron subnet-list
$ neutron subnet-update [subnet-uuid] --dns-nameserver [nameserver-ip]
Subnetz ansehen um den Nameserver zu prüfen:
$ neutron subnet-show [subnet-uuid]
+-------------------+-----------------------------------------------+
| Field             | Value                                         |
+-------------------+-----------------------------------------------+
| ...               |                                               |
| dns_nameservers   | 8.8.8.8                                       |
| ...               |                                               |
+-------------------+-----------------------------------------------+

3.10. Fertigstellen der Undercloud-Konfiguration

Dies schließt die Konfiguration der Undercloud ab. Die nächsten Kapitel befassen sich mit der Planung und Erstellung Ihrer Overcloud.

Kapitel 4. Planung Ihrer Overcloud

Der folgende Abschnitt gibt Ihnen einige Richtlinien zur Planung verschiedener Aspekte Ihrer Overcloud-Umgebung. Dies beinhaltet die Definition von Knotenrollen, die Planung Ihrer Netzwerktopologie und die Speicherung.

4.1. Planen der Knotenbereitstellungsrollen

Der Director bietet mehrere Standardknotentypen für die Bildung Ihrer Overcloud. Diese Knotentypen sind:
Controller
Bietet Schlüsseldienste zur Kontrolle Ihrer Umgebung. Dies umfasst das Dashboard (Horizon), Authentifizierung (Keystone), Imagespeicherung (Glance), Networking (Neutron), Orchestrierung (Heat) und Hochverfügbarkeitsdienste, wenn mehr als ein Controller-Knoten benutzt wird. Eine grundlegende Red Hat Enterprise Linux OpenStack Platform Umgebung erfordert mindestens einen Controller-Knoten.
Compute
Ein Host, der als Hypervisor agiert und die zur Ausführung von virtuellen Maschinen in der Umgebung benötigten Verarbeitungsfähigkeiten bietet. Eine grundlegende Red Hat Enterprise Linux OpenStack Platform Umgebung erfordert mindestens einen Compute-Knoten.
Ceph-Storage
Ein Host, der Red Hat Ceph-Storage bereitstellt. Zusätzliche Ceph-Storage Hosts skalieren zu einem Cluster. Diese Bereitstellungsrolle ist optional.
Cinder-Storage
Ein Host, der externen Blockspeicher für den Cinder Dienst von OpenStack bereitstellt. Diese Bereitstellungsrolle ist optional.
Swift-Storage
Ein Host, der externen Objektspeicher für den Swift-Dienst von OpenStack bereitstellt. Diese Bereitstellungsrolle ist optional.
Dieses Handbuch enthält mehrere Szenarien basierend auf der von Ihnen gewünschten Umgebung. Die folgende Tabelle definiert die Knotentypen für jedes Szenario.

Tabelle 4.1. Knotenbereitstellungsrollen für Szenarien

Controller
Compute
Ceph-Storage
Swift-Storage
Cinder-Storage
Gesamt
Testumgebung
1
1
-
-
-
2
Basisumgebung
1
1
-
-
-
2
Erweiterte Umgebung mit Ceph-Storage
3
3
3
-
-
9

4.2. Planungsnetzwerke

Es ist wichtig, die Netzwerktopologie Ihrer Umgebung und die Subnetze zu planen, damit Sie die Rollen und Dienste ordnungsgemäß zuordnen und diese korrekt miteinander kommunizieren können. Red Hat Enterprise Linux OpenStack Platform 7 benutzt den Neutron Networking-Dienst, der autonom arbeitet und Software-basierte Netzwerke, statische und floating IP-Adresssen und DCHP verwaltet. Der Director stellt diesen Dienst an jedem Controller-Knoten einer Overcloud-Umgebung bereit.
Red Hat Enterprise Linux OpenStack Platform ordnet verschiedene Dienste den separaten Netzwerkdatenverkehrstypen zu, die den verschiedenen Subnetzen in Ihrer Umgebung zugewiesen sind. Diese Netzwerkdatenverkehrstypen sind:

Tabelle 4.2. Netzwerktypen-Zuweisung

Netzwerktypen
Beschreibung
Verwendet von
IPMI
Für Energieverwaltung der Knoten verwendetes Netzwerk. Dieses Netzwerk wird vor der Installation der Undercloud definiert.
Alle Knoten
Provisioning
Der Director benutzt diese Netzwerkdatenverkehrstypen um neue Knoten über PXE Boot bereitzustellen und die Installation der OpenStack Platform auf den Bare-Metal-Servern der Overcloud zu orchestrieren. Dieses Netzwerk wird vor der Installation der Undercloud definiert.
Alle Knoten
Internes API
Das interne API-Netzwerk wird für die Kommunikation zwischen den OpenStack Diensten via API-Kommunikation, RPC-Meldungen und Datenbankkommunikation benutzt.
Controller, Compute, Cinder Storage, Swift Storage
Mandant
Neutron versorgt jeden Mandanten mit seinen eigenen Netzwerken, entweder unter Verwendung von VLAN-Aufgabentrennung, wobei jedes Mandantennetzwerk ein Netzwerk-VLAN ist, oder mithilfe von Tunneling durch VXLAN oder GRE. Netzwerkdatenverkehr ist innerhalb jedes Mandantennetzwerks isoliert. Jedes Mandantennetzwerk hat ein zugehöriges IP-Subnetz und mehrere Mandantennetzwerke können dieselbe Adresse verwenden.
Controller, Compute
Speicher
Block Storage, NFS, iSCSI und andere. Idealerweise wäre dies aus Leistungsgründen auf eine vollkommen separate Switch-Fabric isoliert.
Alle Knoten
Speicherverwaltung
Der OpenStack Objektspeicher (swift) benutzt dieses Netzwerk um Datenobjekte zwischen teilnehmenden Replika-Knoten zu synchronisieren. Der Proxy-Dienst agiert als Zwischenschnittstelle zwischen Benutzeranforderungen und der zugrunde liegenden Speicherebene. Der Proxy empfängt eingehende Anforderungen und sucht die nötigen Replikas um die angeforderten Daten abzurufen. Dienste, die ein Ceph Back-End benutzen, verbinden über das Speicherverwaltungsnetzwerk, da sie nicht mit Ceph direkt interagieren, sondern einen Front-End Dienst verwenden. Beachten Sie, dass der RBD-Driver eine Ausnahme darstellt; dieser Datenverkehr verbindet direkt mit Ceph.
Controller, Ceph Storage, Cinder Storage, Swift Storage
Extern
Ermöglicht dem eingehenden Datenverkehr Instanzen zu erreichen unter Verwendung von 1-zu-1 IP-Adressen Mapping zwischen den floating IP-Adressen und den tatsächlich an Instanzen im Mandantennetzwerk zugewiesenen IP-Adressen. Hostet außerdem das OpenStack Dashboard (horizon) für graphische Systemverwaltung, öffentliche APIs für OpenStack Dienste und führt SNAT bei für Instanzen bestimmtem, eingehenden Datenverkehr aus. Benutzt das externe Netzwerk private IP-Adressen (gemäß RFC-1918), so muss weitere NAT bei aus dem Internet stammendem Datenverkehr durchgeführt werden.
Controller
Bei einer typischen Red Hat Enterprise Linux OpenStack Platform Installation übertrifft die Anzahl von Netzwerktypen häufig die Anzahl von physischen Netzwerkverbindungen. Um alle Netzwerke mit den richtigen Hosts zu verbinden, benutzt die Overcloud VLAN -Tagging um mehr als ein Netzwerk pro Schnittstelle zu liefern. Die meisten Netzwerke sind isolierte Subnetze, aber manche erfordern ein Layer 3 Gateway um Routing für Internet oder Infrastrukturnetzwerkkonnektivität bereitzustellen.
Der Director bietet eine Methode für das Mapping von fünf dieser Datenverkehrstypen zu einem bestimmten Subnetz oder VLANs. Diese Datenverkehrstypen beinhalten:
  • Internes API
  • Speicher
  • Speicherverwaltung
  • Mandantennetzwerk
  • Extern
Jedes nicht zugewiesene Netzwerk ist automatisch demselben Subnetz als Provisioning-Netzwerk zugewiesen.
Das Diagramm unten gibt Ihnen ein Beispiel für eine Netzwerktopologie, bei der die Netzwerke auf separaten VLANs isoliert sind. Jeder Overcloud-Knoten benutzt zwei Schnittstellen (nic2 und nic3) in einem Bond um diese Netzwerke über ihre jeweiligen VLANs zu liefern. Unterdessen kommuniziert jeder Overcloud-Knoten mit der Undercloud über das Provisioning Netzwerk durch ein systemeigenes VLAN, das nic1 verwendet.
Example VLAN Topology using Bonded Interfaces

Abbildung 4.1. Beispiel für VLAN-Topologie, die verbundene Schnittstellen benutzt

Dieses Handbuch bietet mehrere Szenarien, basierend auf der von Ihnen gewünschten Umgebung. Die folgende Tabelle definiert Netzwerkdatenverkehr-Mapping für jedes Szenario:

Tabelle 4.3. Netzwerk-Mappings

Mappings
Gesamtschnittstellen
Gesamt-VLANs
Testumgebung
Netzwerk 1 - Provisioning, Interne API, Speicher, Speicherverwaltung, Mandantennetzwerke, Extern
1
1
Basisumgebung
Netzwerk 1 - Provisioning, Interne API, Speicher, Speicherverwaltung, Mandantennetzwerke
Netzwerk 2 - Extern
2
2
Erweiterte Umgebung mit Ceph-Storage
Netzwerk 1 - Provisioning
Netzwerk 2 - Interne API
Netzwerk 3 - Mandantennetzwerk
Netzwerk 4 - Speicher
Netzwerk 5 - Speicherverwaltung
Netzwerk 6 - Extern
3 (umfasst 2 verbundene Schnittstellen)
6

4.3. Speicherplanung

Der Director bietet verschiedene Speicheroptionen für die Umgebung der Overcloud. Diese beinhalten:
Ceph-Storage-Knoten
Der Director erstellt eine Reihe von skalierbaren Speicherknoten unter Verwendung von Red Hat Ceph Storage. Die Overcloud verwendet diese Knoten für:
  • Images - OpenStack Glance verwaltet Images für VMs. Images sind unveränderlich. OpenStack behandelt Images als binäre Blobs und lädt sie entsprechend herunter. Sie können OpenStack Glance benutzen um Images in einem Ceph Block Gerät zu speichern.
  • Volumes - OpenStack Cinder Volumen sind Blockgeräte. OpenStack benutzt Volumes um VMs zu starten oder um Volumes laufenden VMs anzufügen. OpenStack verwaltet Volumes über Cinder Dienste. Sie können Cinder benutzen um eine VM zu starten, indem Sie einen copy-on-write Klon eines Images verwenden.
  • Guest Disks - Gast-Datenträger sind Datenträger von Gast-Betriebssystemen. Wenn Sie eine virtuelle Maschine mit Nova starten, erscheint ihr Datenträger standardmäßig als Datei auf dem Dateisystem des Hypervisors (gewöhnlich unter /var/lib/nova/instances/<uuid>/). Jede virtuelle Maschine kann in Ceph direkt gestartet werden, ohne Cinder zu benutzen, was nützlich sein kann, da es Ihnen ermöglicht Wartungsvorgänge einfach mit dem live-Migrationsprozess durchzuführen. Falls Ihr Hypervisor abstürzt, ist es außerdem zweckdienlich nova evacuate auszulösen und die virtuelle Maschine an einem anderen Ort nahezu nahtlos auszuführen.

Wichtig

Ceph unterstützt QCOW2 nicht beim Hosting eines virtuellen Maschinendatenträgers. Wenn Sie virtuelle Maschinen in Ceph starten möchten (ephemeral Back-End oder von Volumen starten), muss das Glance-Imageformat RAW sein.
Unter Red Hat Ceph Storage Architecture Guide finden Sie zusätzliche Informationen.
Cinder-Storage-Knoten
Der Director erstellt einen externen Blockspeicher-Knoten. Das kann nützlich sein, wenn Sie Controller-Knoten in Ihrer Overcloud-Umgebung skalieren oder ersetzen müssen, aber Blockspeicher außerhalb eines Hochverfügbarkeits-Clusters erhalten müssen.
Swift-Storage-Knoten
Der Director erstellt einen externen Objektspeicher-Knoten. Das kann nützlich sein, wenn Sie Controller-Knoten in Ihrer Overcloud-Umgebung skalieren oder ersetzen müssen, aber Objektspeicher außerhalb eines Hochverfügbarkeits-Clusters erhalten müssen.

Kapitel 5. Heat-Vorlagen verstehen

Einige der Szenarien in diesem Handbuch verwenden benutzerdefinierte Heat-Vorlagen um bestimmte Aspekte der Overcloud, wie Netzwerkisolation und Netzwerkschnittstellenkonfiguration, zu definieren. Dieser Abschnitt bietet Ihnen eine grundlegende Einführung in Heat-Vorlagen, damit Sie Struktur und Format dieser Vorlagen im Zusammenhang mit dem Red Hat Enterprise Linux OpenStack Platform Director besser verstehen können.

5.1. Heat-Vorlagen

Der Director verwendet Heat-Orchestrierungsvorlagen (Heat Orchestration Templates, kurz HOT) als Vorlagenformat für seinen Overcloud-Bereiststellungsplan. Vorlagen im HOT-Format sind meistens als YAML dargestellt. Der Zweck einer Vorlage ist die Definition und Erstellung eines stack, welches eine Sammlung der von Heat erstellten Ressourcen ist, und der Konfiguration pro Ressource. Ressourcen sind Objekte in OpenStack und können Compute-Ressourcen, Netzwerkkonfiguration, Sicherheitsgruppen, Skalierungsregeln und benutzerdefinierte Ressourcen beinhalten.
Heat-Vorlagen sind in drei Hauptabschnitte strukturiert:
  • Parameters - Dies sind an Heat übergebene Einstellungen, anhand derer man einen Stack und jegliche Standardwerte für Parameter ohne übergebene Werte anpassen kann. Diese sind im parameters Abschnitt einer Vorlage definiert.
  • resources - Dies sind die spezifischen Objekte, die als Teil eines Stacks zu erstellen und zu konfigurieren sind. OpenStack enthält eine Reihe von Kernressourcen, die sich über alle Komponenten erstrecken. Definiert sind diese im resources Abschnitt einer Vorlage.
  • Output - Dies sind Werte, die nach Erstellung des Stacks von Heat übergeben wurden. Zugreifen können Sie auf diese Werte entweder über Heat-API oder Client-Tools. Sie sind im output Abschnitt einer Vorlage definiert.
Hier ist ein Beispiel für eine einfache Heat-Vorlage:
heat_template_version: 2013-05-23

description: > A very basic Heat template.

parameters:
  key_name:
    type: string
    default: lars
    description: Name of an existing key pair to use for the instance
  flavor:
    type: string
    description: Instance type for the instance to be created
    default: m1.small
  image:
    type: string
    default: cirros
    description: ID or name of the image to use for the instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: My Cirros Instance
      image: { get_param: image }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }

output:
  instance_name:
    description: Get the instance's name
    value: { get_attr: [ my_instance, name ] }
Diese Vorlage benutzt den Ressourcentyp type: OS::Nova::Server um eine Instanz namens my_instance mit bestimmter Variante, Image und Schlüssel zu erstellen. Der Stack kann den Wert von instance_name zurückbringen, der My Cirros Instance ist.

5.2. Umgebungsdateien

Eine Umgebungsdatei ist ein besonderer Vorlagentyp, der die Anpassung Ihrer Heat-Vorlagen ermöglicht. Dies beinhaltet zwei Hauptbestandteile:
  • Parameters - Dies sind allgemeine Einstellungen, die Sie auf die Parameter einer Vorlage anwenden. Definiert sind diese im parameters Abschnitt einer Umgebungsdatei.
  • Parameter Defaults - Diese Parameter ändern die Standardwerte für Parameter in Ihren Vorlagen. Definiert sind diese im parameter_defaults Abschnitt einer Umgebungsdatei.
  • Resource Registry - Dieser Abschnitt bestimmt benutzerdefinierte Ressourcennamen, verbunden mit anderen Heat-Vorlagen. Dies bietet im Prinzip eine Methode benutzerdefinierte Ressourcen zu erstellen, die in der Kernressourcensammlung nicht existieren. Definiert sind diese im resource_registry Abschnitt einer Umgebungsdatei.
Hier ist ein Beispiel für eine einfache Umgebungsdatei:
resource_registry:
  OS::Nova::Server::MyServer: myserver.yaml

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1
Dies erstellt einen neuen Ressourcentyp namens OS::Nova::Server::MyServer. Die myserver.yaml Datei ist eine Heat-Vorlagendatei, die eine Implementierung für diesen Ressourcentyp bietet, der alle Vorinstallierten überschreibt.

5.3. Standardmäßige Director-Pläne

Der Director enthält eine Heat-Vorlagensammlung in seiner Datenbank. Diese ist als plan gespeichert. Um eine Liste von Plänen im Director einzusehen, führen Sie folgenden Befehl aus:
$ openstack management plan list
Dies zeigt einen Plan: overcloud, welcher Ihre Overcloud Konfiguration ist. Um weitere Details im Overcloud-Plan einzusehen, führen Sie folgenden Befehl aus:
$ openstack management plan show [UUID]
Sie können auch die Heat-Vorlagendateien für den Overcloud-Plan herunterladen und einsehen. Benutzen Sie folgende Befehle um die Heat-Vorlagen aus dem Plan in ein Verzeichnis im stack Benutzer templates Verzeichnis herunterzuladen:
$ mkdir ~/templates/overcloud-plan
$ openstack management plan download [UUID] -O ~/templates/overcloud-plan/
Diese Sammlung enthält die primären Heat-Vorlagen (plan.yaml) und eine Umgebungsdatei (environment.yaml). Die Vorlagensammlung enthält auch verschiedene Verzeichnisse und Vorlagendateien, die als Ressourcen in der Umgebungsdatei registriert sind.
Diese Plan-basierte Vorlage wird verwendet um die Overcloud im Test Overcloud-Szenario und im Einfachen Overcloud-Szenario zu erstellen. Zudem werden Sie auch eine Umgebungsdatei erstellen um Netzwerkisolation im Einfachen Szenario zu konfigurieren.

5.4. Standardvorlagen des Directors

Der Director enthält auch eine erweiterte Heat-Vorlagensammlung für die Overcloud. Diese Sammlung ist gespeichert in /usr/share/openstack-tripleo-heat-templates.
In dieser Sammlung gibt es viele Heat-Vorlagen und Umgebungsdateien. Die drei Hauptdateien in dieser Vorlagensammlung sind jedoch:
  • overcloud-without-mergepy.yaml - Diese Haupt-Vorlagendatei wird bei der Erstellung der Overcloud-Umgebung benutzt.
  • overcloud-resource-registry-puppet.yaml - Diese Haupt-Umgebungsdatei wird bei der Erstellung der Overcloud-Umgebung benutzt. Sie bietet eine Reihe von Konfigurationen für Puppet-Module, die im Overcloud-Image gespeichert sind. Nachdem der Director das Overcloud-Image zu jedem Knoten geschrieben hat, startet Heat die Puppet-Konfiguration für jeden Knoten unter Verwendung der in dieser Umgebungsdatei registrierten Ressourcen.
  • overcloud-resource-registry.yaml - Diese Standard-Umgebungsdatei wird bei der Erstellung der Overcloud-Umgebung benutzt. Der overcloud-resource-registry-puppet.yaml basiert auf dieser Datei. Diese Datei wird für die benutzerdefinierte Konfiguration Ihrer Umgebung verwendet.
Das Erweiterte Overcloud-Szenario benutzt diese Vorlagensammlung. Es benutzt die overcloud-without-mergepy.yaml Vorlage und die overcloud-resource-registry-puppet.yaml Umgebungsdatei um das Overcloud-Image für jeden Knoten zu konfigurieren. Sie werden auch eine Umgebungsdatei zur Konfiguration von Netzwerkisolation im Erweiterten Szenario erstellen.

Kapitel 6. Installieren der Overcloud

Ihre Undercloud ist jetzt mit konfiguriertem Red Hat Enterprise Linux OpenStack Platform Director installiert. In diesem Kapitel benutzen Sie den Director um die Overcloud-Umgebung zu erstellen. Um den Benutzern auf verschiedenen Ebenen zu helfen, werden drei verschiedene Installations-Szenarien zur Erstellung einer Overcloud beschrieben. Diese Szenarien variieren in Komplexität und Themen.

Tabelle 6.1. Szenarienüberblick

Szenario
Ebene
Themen
Test-Overcloud
Niedrig
Web UI Auslastung, Knotenregistrierung, manuelles Knotentagging, Plan-basierte Erstellung der Overcloud
Einfache Overcloud
Medium
CLI-Tool Auslastung, Knotenregistrierung, manuelles Knotentagging, einfache Netzwerkisolation, Plan-basierte Erstellung der Overcloud
Erweiterte Overcloud
Hoch
CLI-Tool Auslastung, Knotenregistrierung, automatisches Knotentagging basierend auf Hardware, Ceph-Storage Setup, erweiterte Netzwerkisolation, Erstellung der Overcloud, Hochverfügbarkeits-Fencing-Konfiguration

6.1. Szenario 1: Verwenden des Web-UI um eine Test-Overcloud zu erstellen

In diesem Szenario wird eine OpenStack-Platform Testumgebung erstellt. Dieses Szenario besteht aus zwei Knoten in der Overcloud: einem Controller-Knoten und einem Compute-Knoten. Beide Rechner werden mit libvirt/virsh virtualisiert. Dieses Szenario benutzt hauptsächlich das Web-UI des Directors um die Erstellung der Test-Overcloud zu steuern. Dieses Szenario soll die Fähigkeit des Directors zeigen, eine Red Hat Enterprise Linux OpenStack Platform Umgebung für eine einfache Konzeptprüfung zu erzeugen.

Wichtig

Diese Umgebung ist nur zum Testen und nicht als Produktionsumgebung auf Unternehmensebene empfohlen.

Arbeitsablauf

  1. Registrieren der leeren Knoten im Web-UI des Directors.
  2. Hardware aller Knoten prüfen.
  3. Standardvariante für die Knoten erstellen.
  4. Varianten und Images den Bereitstellungsrollen zuweisen.
  5. Overcloud-Umgebung mit Standardplan des Directors erstellen.

Anforderungen

  • Ein Bare-Metal Rechner mit installiertem Red Hat Enterprise Linux 7.1 und libvirt Virtualisierungstools. Dieses System wirkt als Host, der virtualisierte Knoten der Overcloud enthält. Informationen zur Einstellung der libvirt Virtualisierung finden Sie unter Virtualization Getting Started Guide für Red Hat Enterprise Linux 7.
  • Eine Netzwerkverbindung zwischen dem Director-Host und dem Overcloud-Host. Dieses Netzwerk wirkt als Provisioning-Netzwerk. Für dieses Beispiel wird 192.0.2.0/24 als Provisioning-Netzwerk verwendet, wobei der Director 192.0.2.1 und der Overcloud-Host 192.0.2.2 für seine IP-Adresse verwendet.

6.1.1. Konfigurieren des Overcloud-Hosts

Der erste Schritt in diesem Szenario ist die Erstellung Ihrer virtuellen Maschinen im Overcloud-Host.

Prozedur 6.1. Erstellen von virtuellen Maschinen im Overcloud-Host

  1. Zugriff auf Virtual Machine Manager von Ihrem Overcloud-Host.
  2. Zwei virtuelle Maschinen mit folgender Konfiguration erstellen:
    • 1 vCPU
    • 6144 MB Speicher
    • Netzwerk Boot (PXE)
    • 40 GiB Speicher
    • Netzwerkauswahl: Hostgerät eth0: macvtap, Quellmodus: Brücke
    Wählt man macvtap aus, werden die virtuellen Maschinen der ethernet Netzwerkschnittstelle des Hosts freigegeben. Auf diese Art hat der Director direkten Zugriff auf diese Knoten.
  3. Beide virtuellen Maschinen herunterfahren.
  4. Notieren Sie die MAC-Adresse der virtuellen Maschinen, da diese später benötigt werden. Für Ihr Beispiel werden folgende MAC-Adressen benutzt: aa:aa:aa:aa:aa:aa und bb:bb:bb:bb:bb:bb
Der Overcloud-Host enthält jetzt zwei virtuelle Maschinen für Ihre Testumgebung. Der Director muss auf virsh über SSH zugreifen können um den Energiestatus der virtuellen Maschinen steuern zu können. Der nächste Vorgang erstellt ein SSH-Schlüsselpaar, damit der Director sich mit dem Overcloud-Host verbinden kann.

Prozedur 6.2. Erstellen eines SSH-Schlüsselpaares

  1. Melden Sie sich als stack beim Director-Host an und erstellen Sie einen neuen SSH -Schlüssel:
    [stack@director ~]$ ssh-keygen -t rsa -b 2048 -C "dmacpher@redhat.com" -f ./virtkey
    
    Der Befehl führt zur Aufforderung einer Passphrase. Für Keine Passphrase drücken Sie die Eingabetaste. Der Befehl erstellt zwei Dateien: den privaten Schlüssel (virtkey) und den öffentlichen Schlüssel (virtkey.pub).
  2. Kopieren Sie den Inhalt des öffentlichen Schlüssels in die /root/.ssh/authorized_keys Datei des Overcloud-Host root Benutzers:
    [stack@director ~]$ ssh-copy-id -i virtkey root@192.0.2.2
    
  3. Speichern Sie den privaten Schlüssel (virtkey) für später, wenn die Knoten registriert werden.
Ihr Overcloud-Host ist jetzt bereit und kann vom Director geöffnet werden.

6.1.2. Zugriff auf den Director

Öffnen Sie einen Web-Browser und rufen Sie die IP-Adresse des Web-UI des Directors ab. Für dieses Szenario ist die IP-Adresse http://192.0.2.1. Die Anmeldeseite für den Director wird daraufhin angezeigt:
The OpenStack Platform Director Login Screen

Abbildung 6.1. Der Anmeldebildschirm des OpenStack Platform-Directors

Um das Administrationspasswort für Ihre Umgebung abzurufen, führen Sie folgenden Befehl als stack Benutzer auf dem Director-Host aus:
[stack@director ~]$ sudo hiera admin_password
3f2f4295a5eb6ad967b832d35e048852
Benutzen Sie dieses Passwort mit dem admin Benutzer um sich in das UI des Directors einzuloggen.

6.1.3. Registrieren der Knoten

Die Overcloud erfordert eine bestimmte Anzahl von Knoten für verschiedene Bereitstellungsrollen. Das bedeutet, dass Sie eine bestimmte Anzahl von Knoten im Director registrieren. Für dieses Szenario registrieren Sie die Knoten im UI des Directors.

Prozedur 6.3. Registrieren der Knoten

  1. Melden Sie sich als admin Benutzer im Director an.
  2. Gehen Sie zu Nodes im Hauptmenü.
  3. Klicken Sie auf die + Schaltfläche. Es erscheint diese Anzeige zur Knoten-Registrierung.
    Node Registration Screen

    Abbildung 6.2. Bildschirm zur Knoten-Registrierung

  4. Geben Sie folgende Details für Ihre beiden Knoten ein:
    • Knoten 1:
      • Driver: PXE + SSH
      • SSH Address: Der Overcloud-Host
      • SSH User: root
      • SSH Key Contents: Fügen Sie den Inhalt von virtkey ein
      • NIC MAC Adressen: aa:aa:aa:aa:aa:aa
      • Architecture: x86_64
      • CPUs: 1 Einheit
      • Memory: 6144 MB
      • Local Disk: 40 GB
      • Kernel: bm-deploy-kernel
      • Ramdisk: bm-deploy-ramdisk
    • Knoten 2:
      • Driver: PXE + SSH
      • SSH Address: Der Overcloud-Host
      • SSH User: root
      • SSH Key Contents: Fügen Sie den Inhalt von virtkey ein
      • NIC MAC Addresses: bb:bb:bb:bb:bb:bb
      • Architecture: x86_64
      • CPUs: 1 Einheit
      • Memory: 6144 MB
      • Local Disk: 40 GB
      • Kernel: bm-deploy-kernel
      • Ramdisk: bm-deploy-ramdisk
  5. Klicken Sie auf Register Nodes.
Führen Sie nach Registrierung der Knoten folgenden Befehl im Terminal aus um die Hardware-Eigenschaften jedes Knotens zu ermitteln:
$ openstack baremetal introspection bulk start
Die Knoten sind jetzt registriert und im Director ermittelt.

6.1.4. Generieren der Hardware-Profile

Der Director muss auch ein Hardware-Profil oder eine Variante für die registrierten Knoten generieren. Der Director benutzt die baremetal Variante als Standard für nicht zugewiesene Knoten. Benutzen Sie das UI um eine Variante namens baremetal zu erzeugen:

Prozedur 6.4. Generieren der Hardware-Profile

  1. Gehen Sie zu Flavors im Hauptmenü.
  2. Klicken Sie auf die + Schaltfläche. Es erscheint diese Anzeige zur Variantenerstellung.
    Flavors Creations Screen

    Abbildung 6.3. Bildschirm zur Variantenerstellung

  3. Geben Sie folgende Details für Ihre beiden Knoten ein:
    • Name: baremetal
    • CPUs: 1
    • RAM (MB): 6144
    • Disk GB: 40 GB
    • Architecture: x86_64
  4. Klicken Sie auf Create Flavor.
  5. Führen Sie folgenden Befehl im Terminal aus um die Funktionen für die Variante festzulegen:
    $ openstack flavor set --property "capabilities:boot_option"="local" baremetal
    
Das erstellt eine Variante für Ihre Knoten.

6.1.5. Zuweisen der Images zu den Bereitstellungsrollen

Jede Bereitstellungsrolle im Director-UI benötigt zwei Dinge: eine Variante, die als Knotenpool agiert, und ein Image, das zu jedem ausgewählten Knoten in der Overcloud bereitgestellt wird. Der Director weist automatisch jeder Rolle die baremetal Variante zu. Jede Bereitstellungsrolle benötigt jedoch immer noch eine Imagezuordnung.

Prozedur 6.5. Zuweisen der Images zu den Bereitstellungsrollen

  1. Gehen Sie zu Deployment Roles im Hauptmenü.
  2. Klicken Sie auf die Edit Schaltfläche für die Compute Bereitstellungsrolle. Dies zeigt Ihnen die Bearbeitungsanzeige für Bereitstellungsrollen an.
    Editing Deployment Roles

    Abbildung 6.4. Bearbeiten der Bereitstellungsrollen

  3. Stellen Sie sicher, dass baremetal für Flavor und overcloud-full für Image gesetzt ist. Klicken Sie Save um Ihre Änderungen zu speichern.
  4. Wiederholen Sie diesen Vorgang für die übrigen Bereitstellungsrollen.
Ihre Bereitstellungsrollen haben jetzt eine Varianten- und Image-Zuweisung.

6.1.6. Erstellen der Test-Overcloud

Um die Erstellung Ihrer OpenStack Umgebung abzuschließen, muss die Bereitstellung des Plans im Director gestartet werden. Der Standard-Plan installiert einen Controller-Knoten und einen Compute-Knoten.

Prozedur 6.6. Erstellen der Overcloud

  1. Gehen Sie zu Overview im Hauptmenü.
  2. Überprüfen Sie die Anzahl der Knoten im Bereitstellungsplan links. Der Standard-Plan sollte einen Controller-Knoten und einen Compute-Knoten aus der baremetal Variante zuweisen.
    Overcloud Plan

    Abbildung 6.5. Overcloud-Plan

  3. Wenn Sie bereit sind den Erstellungsprozess zu starten, klicken Sie auf die Verify and Deploy Schaltfläche.
    Verify and Deploy

    Abbildung 6.6. Prüfen und Bereitstellen

Der Prozess zur Erstellung der Overcloud beginnt und der Director stellt Ihre Knoten mithilfe der Bereitstellungsrollen zur Definition der Knotentypen bereit.

6.1.7. Zugriff auf die Test-Overcloud

Wenn der Prozess zur Erstellung der Overcloud abgeschlossen ist, kann das UI Sie auffordern, Ihre Overcloud-Umgebung zu initialisieren. In diesem Fall klicken Sie auf die Initialize Schaltfläche um Ihre Overcloud zu aktualisieren.
Wenn die Overcloud aktualisiert ist, wird der Director Ihnen Ihre Zugriffsdetails für die Overcloud zur Verfügung angeben. Das umfasst Ihre Horizon URL, Ihren User Name und Ihr Password.

6.1.8. Abschluss der Test-Overcloud

Damit ist die Erstellung der Test-Overcloud abgeschlossen. Benutzen Sie diese Umgebung um das Konzept zu überprüfen und um eine Umgebung auf Produktionsebene entweder im Abschnitt 6.2, »Szenario 2: Erstellen einer Einfachen Overcloud mithilfe des CLI« oder im Abschnitt 6.3, »Szenario 3: Erstellen einer Erweiterten Overcloud mit Ceph Knoten unter Verwendung des CLI« zu planen.

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.

6.3. Szenario 3: Erstellen einer Erweiterten Overcloud mit Ceph Knoten unter Verwendung des CLI

Dieses Szenario erstellt eine große OpenStack Platform Umgebung auf Unternehmensebene mit Red Hat Ceph-Storage-Knoten. Dieses Szenario besteht aus neun Knoten in der Overcloud:
  • Drei Controller-Knoten mit Hochverfügbarkeit
  • Drei Compute-Knoten
  • Drei Red Hat Ceph-Storage-Knoten in einem Cluster
Alle Rechner sind Bare-Metal-Systeme, die IPMI zur Energieverwaltung benutzen. Dieses Szenario soll die Fähigkeit des Directors demonstrieren, eine Red Hat Enterprise Linux OpenStack Platform Umgebung auf Produktionsebene zu erstellen, die zukünftig Compute-Knoten skalieren kann. Dieses Szenario benutzt die Befehlszeilen-Tools um einige der erweiterten Features des Directors zu demonstrieren, einschließlich der Verwendung des Automated Health Check Tools zur Rollenanpassung und erweiterten Netzwerkisolation.

Arbeitsablauf

  1. Erstellen Sie eine Knoten-Definitionstabelle und registrieren Sie leere Knoten im Director.
  2. Überprüfen Sie die Hardware und bewerten Sie alle Knoten.
  3. Benutzen Sie Automated Health Check (AHC) Tools um Richtlinien zu bestimmen, die automatisch die Knoten in Rollen taggen.
  4. Erstellen Sie Varianten und taggen Sie diese in Rollen.
  5. Erstellen Sie eine Kopie der Standard Heat-Vorlagen des Directors.
  6. Erstellen Sie Heat-Vorlagen um alle Netzwerke zu isolieren.
  7. Erstellen Sie die Overcloud-Umgebung unter Verwendung der Standard Heat-Vorlage und der zusätzlichen Netzwerkisolations-Vorlagen.
  8. Fügen Sie Fencing-Information für jeden Controller-Knoten im Hochverfügbarkeitscluster hinzu.

Anforderungen

  • Der in Kapitel 3, Installieren der Undercloud erstellte Director-Knoten
  • Neun Bare-Metal-Rechner. Diese Rechner müssen die für Controller, Compute und Ceph-Storage-Knoten festgelegten Anforderungen erfüllen. Näheres zu diesen Anforderungen finden Sie 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 systemeigenes VLAN konfiguriert ist. Alle Knoten müssen mit diesem Netzwerk verbunden sein und die in Abschnitt 2.3, »Netzwerkanforderungen« festgelegten Anforderungen erfüllen. Für dieses Beispiel benutzen wir 192.0.2.0/24 als Provisioning-Subnetz mit folgender IP-Adresszuweisungen:

    Tabelle 6.3. Provisioning-Netzwerk IP-Zuweisungen

    Knotenname
    IP-Adresse
    MAC-Adresse
    IPMI IP-Adresse
    Director
    192.0.2.1
    aa:aa:aa:aa:aa:aa
    Controller 1
    DHCP definiert
    b1:b1:b1:b1:b1:b1
    192.0.2.205
    Controller 2
    DHCP definiert
    b2:b2:b2:b2:b2:b2
    192.0.2.206
    Controller 3
    DHCP definiert
    b3:b3:b3:b3:b3:b3
    192.0.2.207
    Compute 1
    DHCP definiert
    c1:c1:c1:c1:c1:c1
    192.0.2.208
    Compute 2
    DHCP definiert
    c2:c2:c2:c2:c2:c2
    192.0.2.209
    Compute 3
    DHCP definiert
    c3:c3:c3:c3:c3:c3
    192.0.2.210
    Ceph 1
    DHCP definiert
    d1:d1:d1:d1:d1:d1
    192.0.2.211
    Ceph 2
    DHCP definiert
    d2:d2:d2:d2:d2:d2
    192.0.2.212
    Ceph 3
    DHCP definiert
    d3:d3:d3:d3:d3:d3
    192.0.2.213
  • Jeder Overcloud-Knoten benutzt die übrigen beiden Netzwerkschnittstellen in einem Bond um Netzwerke in getaggten VLANs zu verarbeiten. Folgende Netzwerkzuweisungen gelten für dieses Bond:

    Tabelle 6.4. Netzwerk Subnetz und VLAN-Zuweisungen

    Netzwerktyp
    Subnetz
    VLAN
    Interne API
    172.16.0.0/24
    201
    Mandant
    172.17.0.0/24
    202
    Speicher
    172.18.0.0/24
    203
    Speicherverwaltung
    172.19.0.0/24
    204
    Externe / Floating IP
    10.1.1.0/24
    100

6.3.1. Registrieren der Knoten für die Erweiterte Overcloud

In diesem Abschnitt erstellen wir eine Knoten-Definitionsvorlage. Diese Datei (instackenv.json) ist eine JSON-Formatdatei und enthält die Hardware- und Energieverwaltungsdetails für Ihre neun Knoten. Zum Beispiel:
{
    "nodes":[
        {
            "mac":[
                "b1:b1:b1:b1:b1:b1"
            ],
            "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":[
                "b2:b2:b2:b2:b2:b2"
            ],
            "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"
        },
        {
            "mac":[
                "b3:b3:b3:b3:b3:b3"
            ],
            "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.207"
        },
        {
            "mac":[
                "c1:c1:c1:c1:c1:c1"
            ],
            "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.208"
        },
        {
            "mac":[
                "c2:c2:c2:c2:c2:c2"
            ],
            "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.209"
        },
        {
            "mac":[
                "c3:c3:c3:c3:c3:c3"
            ],
            "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.210"
        },
        {
            "mac":[
                "d1:d1:d1:d1:d1:d1"
            ],
            "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.211"
        },
        {
            "mac":[
                "d2:d2:d2:d2:d2:d2"
            ],
            "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.212"
        },
        {
            "mac":[
                "d3:d3:d3:d3:d3:d3"
            ],
            "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.213"
        }
    ]
}
Diese Vorlage benutzt folgende Attribute:
mac
Eine Liste von MAC-Adressen für die Netzwerkschnittstellen auf dem Knoten. Benutzen Sie nur MAC-Adressen für den Provisioning NIC jedes Systems.
cpu
Anzahl der CPUs auf dem Knoten.
Speicher
Die Größe des Speichers 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
IP-Adresse des IPMI Geräts.

Anmerkung

Weitere unterstützte Energieverwaltungstypen und ihre Optionen finden Sie unter Anhang B, Energieverwaltungs-Driver.
Speichern Sie die Datei nach Erstellung der Vorlage in stack Home-Verzeichnis des Benutzers als instackenv.json und importieren Sie sie dann in den Director. Benutzen Sie dafür folgenden Befehl:
$ openstack baremetal import --json ~/instackenv.json
Dies importiert die Vorlagen und registriert jeden Knoten der Vorlage im Director.
Kernel und Ramdisk Images allen Knoten zuweisen:
$ openstack baremetal configure boot
Die Knoten sind jetzt im Director registriert und konfiguriert. Sie können eine Liste dieser Knoten im CLI mit folgendem Befehl abrufen:
$ openstack baremetal list

6.3.2. Überprüfen der Knoten-Hardware

Nach Registrierung der Knoten muss das Hardware-Attribut jedes Knotens überprüft werden. Dieses Szenario bewertet gleichzeitig den Knoten für die Verwendung mit Automated Health Check (AHC) Tools, mit denen die Knoten automatisch in Bereitstellungsprofile getaggt werden. Diese Profiltags ordnen Ihre Knoten den Varianten zu, die Varianten werden wiederum einer Bereitstellungsrolle zugewiesen.

Wichtig

Das Benchmarking-Feature verlangt, dass die discovery_runbench Option auf wahr gestellt ist, wenn der Director erstmals konfiguriert wird (vgl. Abschnitt 3.7, »Konfiguration des Directors«).
Wenn Sie das Benchmarking nach Installation des Directors aktivieren müssen, bearbeiten Sie /httpboot/discoverd.ipxe und stellen Sie den RUNBENCH Kernel Parameter auf 1.
Führen Sie folgenden Befehl aus um die Hardware-Attribute jedes Knotens zu überprüfen:
$ openstack baremetal introspection bulk start

Wichtig

Stellen Sie sicher, dass dieser Prozess bis zum Ende durchläuft. Dieser Prozess dauert für Bare-Metal-Knoten normalerweise 15 Minuten.

6.3.3. Automatisches Knoten-Tagging mit Automated Health Check (AHC) Tools

Wenn der Ermittlungsprozess seine Benchmark-Tests abgeschlossen hat, können Sie eine Reihe von Berichten abfragen um Knoten, die eine zu geringe Leistung erbringen oder nicht stabil sind, zu identifizieren und aus der Overcloud zu isolieren. Dieser Abschnitt untersucht, wie diese Berichte generiert werden und wie Richtlinien erstellt werden können, um Knoten automatisch in bestimmte Rollen zu taggen.
Installieren Sie die folgenden Automated Health Check (AHC) Tools mit folgendem Befehl:
$ sudo yum install -y ahc-tools
Das Paket enthält zwei Tools:
  • ahc-report, was die Berichte aus den Benchmark Tests abfragt.
  • ahc-match, was Knoten je nach Richtlinien in bestimmte Rollen taggt.

Wichtig

Diese Tools erfordern Anmeldedaten für Ironic und Swift, die in der /etc/ahc-tools/ahc-tools.conf Datei gesetzt sind. Dies sind dieselben Anmeldedaten, wie in /etc/ironic-discoverd/discoverd.conf. Benutzen Sie folgende Befehle um die Konfigurationsdatei für /etc/ahc-tools/ahc-tools.conf zu konfigurieren und anzupassen:
$ sudo -i
# sed 's/\[discoverd/\[ironic/' /etc/ironic-discoverd/discoverd.conf > /etc/ahc-tools/ahc-tools.conf
# chmod 0600 /etc/ahc-tools/ahc-tools.conf
# exit

6.3.3.1. ahc-Bericht

Das ahc-report Skript produziert verschiedene Berichte über Ihre Knoten. Um einen vollständigen Bericht anzuzeigen, benutzen Sie die --full Option.
$ ahc-report --full
Der ahc-report Befehl kann sich auch auf bestimmte Teile des Berichts richten. Benutzen Sie zum Beispiel --categories um Knoten anhand ihrer Hardware (Prozessoren, Netzwerkschnittstellen, Firmware, Speicher und verschiedene Hardware Controller) zu kategorisieren. Das gruppiert diese Knoten zudem mit ähnlichen Hardware Profilen. Zum Beispiel kann der Processors Abschnitt für Ihre beiden Beispiel-Knoten Folgendes auflisten:
######################
##### Processors #####
2 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[(u'cpu', u'logical', u'number', u'4'),
 (u'cpu', u'physical', u'number', u'4'),
 (u'cpu',
  u'physical_0',
  u'flags',
  u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
 (u'cpu', u'physical_0', u'frequency', u'2000000000'),
 (u'cpu', u'physical_0', u'physid', u'0'),
 (u'cpu', u'physical_0', u'product', u'Intel(R) Xeon(TM) CPU       E3-1271v3 @ 3.6GHz'),
 (u'cpu', u'physical_0', u'vendor', u'GenuineIntel'),
 (u'cpu',
  u'physical_1',
  u'flags',
  u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
 (u'cpu', u'physical_0', u'frequency', u'2000000000'),
 (u'cpu', u'physical_0', u'physid', u'0'),
 (u'cpu', u'physical_0', u'product', u'Intel(R) Xeon(TM) CPU       E3-1271v3 @ 3.6GHz'),
 (u'cpu', u'physical_0', u'vendor', u'GenuineIntel')
 ...
 ]
Das ahc-report Tool identifiziert auch die Ausreißer in Ihrer Knotensammlung. Benutzen Sie das --outliers Switch um es zu aktivieren:
$ ahc-report --outliers

Group 0 : Checking logical disks perf
standalone_randread_4k_KBps   : INFO    : sda   : Group performance : min=45296.00, mean=53604.67, max=67923.00, stddev=12453.21
standalone_randread_4k_KBps   : ERROR   : sda   : Group's variance is too important :   23.23% of 53604.67 whereas limit is set to 15.00%
standalone_randread_4k_KBps   : ERROR   : sda   : Group performance : UNSTABLE
standalone_read_1M_IOps       : INFO    : sda   : Group performance : min= 1199.00, mean= 1259.00, max= 1357.00, stddev=   85.58
standalone_read_1M_IOps       : INFO    : sda   : Group performance = 1259.00   : CONSISTENT
standalone_randread_4k_IOps   : INFO    : sda   : Group performance : min=11320.00, mean=13397.33, max=16977.00, stddev= 3113.39
standalone_randread_4k_IOps   : ERROR   : sda   : Group's variance is too important :   23.24% of 13397.33 whereas limit is set to 15.00%
standalone_randread_4k_IOps   : ERROR   : sda   : Group performance : UNSTABLE
standalone_read_1M_KBps       : INFO    : sda   : Group performance : min=1231155.00, mean=1292799.67, max=1393152.00, stddev=87661.11
standalone_read_1M_KBps       : INFO    : sda   : Group performance = 1292799.67   : CONSISTENT

...
Im oben angeführten Beispiel markierte ahc-report die standalone_randread_4k_KBps und standalone_randread_4k_IOps Datenträgermetrik als instabil, da die Standardabweichung aller Knoten höher war als der zulässige Schwellenwert. Bei Ihrem Beispiel könnte das eintreten, wenn Ihre zwei Knoten einen signifikanten Unterschied in der Datenträgerübertragungsrate aufweisen.
Es ist nützlich Ausreißer in Ihrer Knotensammlung zu bestimmen, da Sie auf diese Art Hochleistungsknoten geeigneteren Aufgaben zuweisen können. Beispielsweise eignen sich Knoten mit besseren Datenträgerübertragungsraten besonders gut als Speicherknoten, während Knoten mit besserer Speicherleistung sich als Compute-Knoten eignen. Sobald die Hardwareleistung jedes Knotens identifiziert ist, können Sie eine bestimmte Anzahl von Richtlinien erstellen und über den ahc-match Befehl den Knoten eine bestimmte Rolle zuweisen.

6.3.3.2. ahc-match

Der ahc-match Befehl wendet eine Reihe von Richtlinien auf Ihren Overcloud-Plan an um den Knoten bestimmte Rollen zuzuweisen. Bevor Sie diesen Befehl benutzen, erstellen Sie eine bestimmte Anzahl von Richtlinien um geeignete Knoten ihren Rollen zuzuweisen.
Das ahc-tools Paket installiert eine bestimmte Anzahl von Richtliniendateien unter /etc/ahc-tools/edeploy. Dies beinhaltet:
  • state - Die Statusdatei, die die Anzahl von Knoten für jede Rolle bestimmt.
  • compute.specs, controller.specs - Richtliniendateien zur Zuordnung von Compute und Controller-Knoten.
Statusdatei
Die state Datei zeigt die Anzahl von Knoten für jede Rolle an. Die Standard Konfigurationsdatei zeigt:
[('control', '1'), ('compute', '*')]
Das bedeutet, dass ahc-match einen Controller-Knoten und eine beliebige Anzahl von Compute-Knoten zuweist. Für dieses Szenario bearbeiten Sie folgende Datei:
[('control', '3'), ('ceph-storage', '3'), ('compute', '*')]
Das entspricht drei Controller-Knoten, drei Red Hat Ceph-Storage-Knoten und einer unbegrenzten Anzahl von Compute-Knoten.
Richtliniendateien
Die compute.specs und controller.specs Dateien listen die Zuweisungsregeln für die jeweilige Rolle auf. Der Inhalt der Datei ist im Tupel-Format, wie:
[
 ('cpu', 'logical', 'number', 'ge(2)'),
 ('disk', '$disk', 'size', 'gt(4)'),
 ('network', '$eth', 'ipv4', 'network(192.0.2.0/24)'),
 ('memory', 'total', 'size', 'ge(4294967296)'),
]
Das bietet eine Möglichkeit Zuweisungsregeln basierend auf Hardware-Parametern zu definieren. Den vollständigen Verweis aller verfügbaren Parameter finden Sie unter Anhang C, Automated Health Check (AHC) Tool Parameter.
Die Richtliniendateien benutzen auch eine Reihe von Hilfsfunktionen um den Wertebereich anzupassen. Diese Funktionen sind
  • network() - Die Netzwerkschnittstelle ist im angegebenen Netzwerk.
  • gt(), ge() -Größer als (oder gleich).
  • lt(), le() - Kleiner als (oder gleich).
  • in() - Das anzupassende Element soll in einem bestimmten Set sein.
  • regexp() - Einen regulären Ausdruck abgleichen.
  • or(), and(), not() - Boolean Funktionen. or() und and() übernehmen zwei Parameter und not() einen Parameter.
Zum Beispiel benutzt dieses Szenario standalone_randread_4k_KBps und standalone_randread_4k_IOps Werte aus dem Abschnitt 6.3.3.1, »ahc-Bericht« um die Controller-Rolle auf den Knoten mit überdurchschnittlicher Datenträgerzugriffsrate zu limitieren. Die Regeln für jeden wären:
[
 ('disk', '$disk', 'standalone_randread_4k_KBps', 'gt(53604)'),
 ('disk', '$disk', 'standalone_randread_4k_IOps', 'gt(13397)')
]
Sie können auch zusätzliche Richtlinienprofile für andere Rollen hinzufügen. Erstellen Sie zum Beispiel einen ceph-storage.spec für ein Profil, speziell für Red Hat Ceph-Storage. Stellen Sie sicher, dass diese neuen Dateinamen (ohne Erweiterung) in der state Datei eingeschlossen sind.
Ausführung des Anpassungs-Tools
Wenn Sie Ihre Regeln definiert haben, führen Sie das ahc-match Tool aus um Ihre Knoten zuzuweisen.
$ sudo ahc-match
Das passt alle Knoten den in /etc/ahc-tools/edeploy/state definierten Rollen an. Wenn ein Knoten einer Rolle entspricht, fügt der ahc-match die Rolle dem Knoten in Ironic als Funktion hinzu.
$ ironic node-show b73fb5fa-1a2c-49c6-b38e-8de41e3c0532 | grep properties -A2
| properties    | {u'memory_mb': u'6144', u'cpu_arch': u'x86_64', u'local_gb': u'40',      |
|               | u'cpus': u'4', u'capabilities': u'profile:control,boot_option:local'}    |
| instance_uuid | None                                                                     |
Der Director benutzt dieses profile Tag von jedem Knoten um ihn den Rollen und Varianten mit demselben Tag anzupassen.

6.3.4. Erstellen von Hardware-Profilen

Der Director benötigt auch eine bestimmte Anzahl von Hardware-Profilen oder Varianten für die registrierten Knoten. In diesem Szenario werden wir je ein Profil für den Compute, den Controller und den Ceph-Storage-Knoten erstellen:
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 control
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-storage
Dies erstellt drei Varianten für Ihre Knoten. Man stellt auch die zusätzlichen Eigenschaften für jede Variante ein.
$ 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
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-storage" ceph-storage
capabilities:boot_option stellt den Startmodus für die Varianten ein und capabilities:profile bestimmt das zu verwendende Profil.

6.3.5. Verwendung der Standard Overcloud Heat-Vorlagen

Bei der Erstellung der Overcloud benutzt der Director einen in seiner Datenbank gespeicherten Plan. Dieser Plan basiert auf einer Reihe von Heat-Vorlagen. Es ist jedoch möglich die Standard-Heat-Vorlagen in ein lokales Verzeichnis zu kopieren und diese Vorlagen zur Erstellung Ihrer Overcloud zu benutzen. Das ist bei der Anpassung bestimmter Teile Ihrer Overcloud von Nutzen.
Für dieses Szenario kopieren wir die lokale Vorlagensammlung und passen sie an, um Ihr Ceph-Storage Datenträger-Layout einzuschließen.
Der Speicherort für die Standard Heat-Vorlagen der Overcloud ist /usr/share/openstack-tripleo-heat-templates. Für dieses Szenario kopieren wir die Vorlagen in das stack Home-Verzeichnis des Benutzers:
$ cp -r /usr/share/openstack-tripleo-heat-templates ~/templates/my-overcloud
Dies erstellt einen Klon der Overcloud Heat-Vorlagen. Bei der Ausführung von openstack overcloud deploy benutzen wir die --templates Option um Ihr lokales Vorlagenverzeichnis anzugeben.

Anmerkung

Der Director verwendet das Standard Vorlagenverzeichnis (/usr/share/openstack-tripleo-heat-templates), wenn Sie die --templates Option ohne ein Verzeichnis angeben.

6.3.6. Konfiguration von Ceph-Storage

Dieser Abschnitt beschreibt die Installation und Konfiguration von Red Hat Ceph-Storage unter Verwendung des Directors zum Gebrauch mit OpenStack. Der Installations- und Konfigurationsprozess basiert auf einer Kombination aus Heat-Vorlagen und Puppet-Konfiguration.
Das Overcloud-Image enthält bereits die Ceph-Storage Software und die notwendigen Puppet-Module um sowohl die Ceph-OSD-Knoten, als auch den Ceph-Monitor automatisch auf Controller-Cluster zu konfigurieren. Diese in Ihr Home-Verzeichnis kopierte Overcloud Vorlagensammlung (vgl. Abschnitt 6.3.5, »Verwendung der Standard Overcloud Heat-Vorlagen«) beinhaltet folgende, für die Ceph-Storage Konfiguration relevanten Dateien:
  • puppet/ceph-storage-puppet.yaml - Die zur Orchestrierung der Ceph-Storage-Knoten verwendete Heat-Vorlage, ihre Integration mit der Overcloud und ihre Puppet-Konfiguration.
  • puppet/manifest/overcloud_cephstorage.pp - Das Puppet-Manifest, das zur Konfiguration der Basisumgebung für Ceph-Storage-Knoten und zur Anwendung von Klassen aus den Ceph Puppet-Modulen auf dem Overcloud Image verwendet wird.
  • puppet/hieradata/ceph.yaml - Die zur Puppet Konfiguration auf Ceph-Storage-Knoten übergebene Puppet hiera Daten.
  • puppet/ceph-storage-post-puppet.yaml - Die zur Orchestrierung von Post-Konfigurationsvorgängen der Ceph-Storage-Knoten verwendete Heat-Vorlage.
  • puppet/ceph-cluster-config.yaml - Die zur Orchestrierung des Ceph-Monitors auf den Controller-Knoten verwendete Heat-Vorlage.
Das Ceph-Storage-Cluster erfordert geringfügige Konfigurationsarbeiten, insbesondere am Datenträgerlayout auf den Ceph-Storage-Knoten. Um diese Information zu übergeben, bearbeitet man puppet/hieradata/ceph.yaml und ändert den ceph::profile::params::osds Parameter, um die relevanten Journal-Partitionen und Datenträger zuzuordnen. Ein Ceph-Knoten mit vier Datenträgern kann folgende Zuweisungen haben:
  • /dev/sda - Das Overcloud-Image enthaltende Stammdatenträger
  • /dev/sdb - Die Journal-Partitionen enthaltende Datenträger
  • /dev/sdc und /dev/sdd - Die OSD Datenträger
Bei diesem Beispiel würde puppet/hieradata/ceph.yaml Folgendes enthalten:
ceph::profile::params::osds:
    '/dev/sdc':
        journal: '/dev/sdb1'
    '/dev/sdd':
        journal: '/dev/sdb2'
Ändern Sie zusätzliche Parameter in puppet/hieradata/ceph.yaml um Ihrem Speicherbedarf einschließlich Journalgröße und Poolstandard zu entsprechen.
Wenn diese Änderungen abgeschlossen sind, speichern Sie puppet/hieradata/ceph.yaml, damit die Ceph-Storage-Knoten Ihr Datenträger-Mapping und Ihre benutzerdefinierten Einstellungen verwenden, wenn Sie die Overcloud bereitstellen.

6.3.7. Alle Netzwerke in VLANs isolieren

Der Director stellt Methoden zur Konfiguration isolierter Overcloud-Netzwerke bereit. Das bedeutet, dass die Overcloud-Umgebung Netzwerkdatenverkehrstypen auf verschiedene Netzwerke aufteilt, die wiederum Netzwerkdatenverkehr bestimmten Netzwerkschnittstellen oder Bonds zuweisen. Nach der Konfiguration isolierter Netzwerke konfiguriert der Director die OpenStack Dienste darauf, die isolierten Netzwerke zu benutzen. Wenn keine isolierten Netzwerke konfiguriert sind, werden alle Dienste auf dem Provisioning-Netzwerk ausgeführt.
Dieses Szenario benutzt separate Netzwerke für alle Dienste:
  • Netzwerk 1 - Provisioning
  • Netzwerk 2 - Interne API
  • Netzwerk 3 - Mandantennetzwerke
  • Netzwerk 4 - Speicher
  • Netzwerk 5 - Speicherverwaltung
  • Netzwerk 6 - Extern
Die folgenden Abschnitte zeigen, wie man Heat-Vorlagen erstellen kann um alle Netzwerktypen zu isolieren.

6.3.7.1. Erstellung von benutzerdefinierten Schnittstellenvorlagen

Die Konfiguration des Overcloud Netzwerks erfordert eine Reihe von Netzwerkschnittstellen-Vorlagen. Diese Vorlagen werden von Ihnen angepasst 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 beinhaltet eine bestimmte Anzahl von Beispiel-Vorlagen um Ihnen den Einstieg zu erleichtern:
  • /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans - Verzeichnis, das Vorlagen für einen einzelnen NIC mit VLAN Konfiguration auf einer pro-Rolle Basis enthält.
  • /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans - Verzeichnis, das Vorlagen für verbundene NIC-Konfiguration auf einer pro-Rolle Basis enthält.
Für das Erweiterte Overcloud Szenario verwenden wir die standardmäßig verbundene NIC Beispielkonfiguration als Basis. Kopieren Sie das Standard-Konfigurationsverzeichnis ins stack Home-Verzeichnis des Benutzers als nic-configs.
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans ~/templates/nic-configs
Dies erstellt einen lokalen Satz von Heat-Vorlagen, die eine verbundene Netzwerkschnittstellen-Konfiguration für jede Rolle angeben. Jede Vorlage enthält die standardmäßigen parameters, resources, und output Abschnitte. Für Ihre Zwecke bearbeiten wir nur den resources Abschnitt. Jeder resources Abschnitt beginnt mit dem Folgenden:
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 Subbefehl, 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 bestimmt jede Schnittstelle, indem sie entweder den eigentlichen Schnittstellennamen verwendet ("eth0", "eth1", "enp0s25") oder eine Reihe von nummerierten Schnittstellen ("nic1", "nic2", "nic3").
            - type: interface
              name: nic2
vlan
Definiert ein VLAN. Verwendet VLAN-ID und Subnetz aus dem parameters Abschnitt.
            - type: vlan
              vlan_id: {get_param: ExternalNetworkVlanID}
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}
ovs_bond
Definiert einen Bond in vSwitch. Ein Bond verbindet zwei oder mehrere interfaces miteinander um mit Redundanz zu helfen und die Bandbreite zu erweitern.
            - 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.
Für das Erweiterte Szenario verwenden wir die Standardkonfiguration für verbundene Schnittstellen. Die templates/nic-configs/controller.yaml Vorlage benutzt zum Beispiel folgende network_config:
          network_config:
            - type: ovs_bridge
              name: {get_input: bridge_name}
              members:
                - type: ovs_bond
                  name: bond1
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  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}
                  routes:
                    - ip_netmask: 0.0.0.0/0
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: InternalApiIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: StorageIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageMgmtNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: StorageMgmtIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: TenantIpSubnet}
Diese Vorlage definiert eine Brücke (gewöhnlich die externe Brücke namens br-ex) und erstellt eine verbundene Schnittstelle namens bond1 aus zwei nummerierten Schnittstellen: nic2 und nic3. Die Brücke beinhaltet auch mehrere markierte VLAN Geräte, die bond1 als übergeordnetes Gerät verwenden.
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. Definieren Sie diese in einer Umgebungsdatei, die Sie speziell für Ihre Netzwerke anlegen.

Wichtig

Unbenutzte Schnittstellen deaktivieren um unerwünschte Standardrouten und Netzwerkschleifen zu vermeiden. Zum Beispiel:
- type: interface
  name: nic1
  use_dhcp: true
Stellen Sie sicher, dass diese Schnittstellen aus allen ovs_bridge Geräten entfernt wurden.

6.3.7.2. Erstellen einer Netzwerkumgebungsdatei einer Erweiterten Overcloud

Die Netzwerkumgebungsdatei ist eine Heat-Umgebungsdatei, die die Netzwerkumgebung der Overcloud beschreibt und auf die Netzwerkschnittstellen-Konfigurationsvorlage aus dem vorherigen Abschnitt verweist. Die Subnetze und VLANs für Ihr Netzwerk werden zusammen mit den IP-Adressbereichen definiert. Wir passen diese Werte der lokalen Umgebung an.
Dieses Szenario benutzt folgende Netzwerkumgebungsdatei, die als /home/stack/templates/network-environment.yaml gespeichert ist:
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

parameter_defaults:
  InternalApiNetCidr: 172.16.0.0/24
  TenantNetCidr: 172.17.0.0/24
  StorageNetCidr: 172.18.0.0/24
  StorageMgmtNetCidr: 172.19.0.0/24
  ExternalNetCidr: 10.1.1.0/24
  InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}]
  TenantAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}]
  StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}]
  # Leave room for floating IPs in the External allocation pool
  ExternalAllocationPools: [{'start': '10.1.1.10', 'end': '10.1.1.50'}]
  InternalApiNetworkVlanID: 201
  StorageNetworkVlanID: 202
  StorageMgmtNetworkVlanID: 203
  TenantNetworkVlanID: 204
  ExternalNetworkVlanID: 100
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 10.1.1.1
  # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: default: "''"
  # Customize bonding options if required
  BondInterfaceOvsOptions:
    "bond_mode=balance-tcp lacp=active other-config:lacp-fallback-ab=true"
Der resource_registry Abschnitt enthält Links zu den Netzwerkschnittstellenvorlagen für jede Knotenrolle.
Der parameter_defaults Abschnitt enthält eine Liste von Parametern, die die Netzwerkoptionen für jeden Netzwerktyp definieren. Eine vollständige Liste dieser Optionen finden Sie unter Anhang F, Netzwerkumgebungs-Optionen.

Wichtig

Der NeutronExternalNetworkBridge Parameter muss Teil des parameter_defaults Abschnitts sein, wenn eine Overcloud erstellt wird, die auf einer Heat-Vorlage basiert. Das liegt an der Art und Weise, wie die Vorlage ihre Parameter verarbeitet. Wenn Sie eine Plan-basierte Overcloud erstellen, wie im Einfachen Overcloud Szenario, ist der Parameter Controller-1::NeutronExternalNetworkBridge und befindet sich im parameters Abschnitt. Unter Abschnitt 6.2.5.2, »Erstellen der Netzwerkumgebungs-Vorlage einer Einfachen Overcloud « können Sie diesen Unterschied einsehen.
Dieses Szenario definiert Optionen für jedes Netzwerk. Alle Netzwerktypen benutzen ein indivduelles VLAN und Subnetz. Das bedeutet, dass keines Ihrer Netzweke das Provisioning-Netzwerk benutzt.

Wichtig

Wenn Sie die Netzwerkkonfiguration nach Erstellung der Overcloud ändern, kann das aufgrund der Verfügbarkeit der Ressourcen zu Konfigurationsproblemen führen. Wenn ein Benutzer beispielsweise einen Subnetzbereich für ein Netzwerk in den Netzwerkisolations-Vorlagen ändert, könnte die Neukonfiguration fehlschlagen, weil das Subnetz bereits benutzt wird.

6.3.7.3. Zuweisung der OpenStack Dienste zu isolierten Netzwerken

Jeder OpenStack Dienst ist einem Standardnetzwerktyp im Ressourcenverzeichnis zugewiesen. Diese Dienste sind verbunden mit IP-Adressen innerhalb des dem Netzwerktypen zugewiesenen Netzwerks. Obwohl die OpenStack Dienste auf diese Netzwerke aufgeteilt sind, kann die Anzahl der tatsächlichen physischen Netzwerke von den Angaben in der Netzwerkumgebungsdatei abweichen. Sie können die OpenStack Dienste den verschiedenen Netzwerktypen neu zuweisen, indem Sie eine neue Netzwerkübersicht in Ihrer Netzwerkumgebungsdatei (/home/stack/templates/network-environment.yaml)angeben. Der ServiceNetMap Parameter bestimmt die Netzwerktypen für jeden Dienst.
Wir können beispielsweise die Netzwerkdienste zur Speicherverwaltung neu zuweisen, indem die markierten Abschnitte geändert werden:
...

parameters:

  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: storage_mgmt
    SwiftProxyNetwork: storage
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitMqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage_mgmt
    CephPublicNetwork: storage
Eine Änderung dieser Parameter auf storage verlegt diese Dienste ins Speichernetzwerk anstatt ins Speicherverwaltungsnetzwerk. Das bedeutet, dass Sie nur eine bestimmte Anzahl von parameter_defaults für das Speichernetzwerk und nicht für das Speicherverwaltungsnetzwerk definieren müssen.

6.3.8. Erstellen der Erweiterten Overcloud

Als letzter Schritt zur Erstellung der Overcloud-Umgebung müssen Sie die notwendigen Befehle geben. Die Befehlsoptionen, die Sie dafür benutzen, installieren drei Controller-Knoten, drei Compute-Knoten und drei Ceph-Storage-Knoten. Sie benötigen auch den benutzerdefinierten Heat-Vorlagen Stack aus Abschnitt 6.3.5, »Verwendung der Standard Overcloud Heat-Vorlagen«.
Folgenden Befehl ausführen um die Bildung der Erweiterten Overcloud zu starten:
$ openstack overcloud deploy --templates ~/templates/my-overcloud -e ~/templates/my-overcloud/environments/network-isolation.yaml -e ~/templates/network-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan
Dieser Befehl enthält folgende Zusatzoptionen:
  • --templates ~/templates/my-overcloud - Erstellt die Overcloud aus einer benutzerdefinierten Reihe von Heat-Vorlagen, anstatt dem im Director gespeicherten Plan.
  • -e ~/templates/my-overcloud/environments/network-isolation.yaml - Die -e Option fügt dem Overcloud-Plan eine zusätzliche Umgebungsdatei hinzu. In diesem Fall ist es eine Umgebungsdatei, die Netzwerkisolations-Konfiguration einleitet.
  • -e ~/templates/network-environment.yaml - Die -e Option fügt dem Overcloud-Plan eine zusätzliche Umgebungsdatei hinzu. In diesem Fall ist es die Netzwerk-Umgebungsdatei von Abschnitt 6.3.7.2, »Erstellen einer Netzwerkumgebungsdatei einer Erweiterten Overcloud «.
  • --control-scale 3 - Controller-Knoten auf drei skalieren.
  • --compute-scale 3 - Compute-Knoten auf drei skalieren.
  • --ceph-storage-scale 3 - Ceph-Storage-Knoten auf drei skalieren.
  • --control-flavor control - Bestimmte Variante für die Controller-Knoten verwenden.
  • --compute-flavor compute - Bestimmte Variante für die Compute-Knoten verwenden.
  • --ceph-storage-flavor ceph-storage - Bestimmte Variante für die Ceph-Storage-Knoten verwenden.
  • --ntp-server pool.ntp.org - NTP-Server zur Zeit-Synchronisierung verwenden. Das ist nützlich um die Controller-Knoten-Cluster synchron zu halten.
  • --neutron-network-type vxlan - Virtual Extensible LAN (VXLAN) für Neutron-Networking in der Overcloud verwenden.
  • --neutron-tunnel-types vxlan - Virtual Extensible LAN (VXLAN) für Neutron-Tunneling in der Overcloud verwenden.

Anmerkung

Für eine vollständige Liste von Optionen folgenden Befehl ausführen:
$ openstack help overcloud deploy
Parameterbeispiele finden Sie unter Anhang G, Bereitstellungsparameter.
Der Prozess zur Erstellung der Overcloud beginnt und der Directort stellt Ihre Knoten bereit. Dieser Prozess wird eine Weile dauern. Um den Status der Overcloud-Erstellung zu überprüfen, ö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 die mit der -e Option zur Overcloud hinzugefügten Umgebungsdateien. Der Director verwendet diese Umgebungsdateien für gewisse Funktionen in Kapitel 7, Aufgabenausführung nach Erstellung der Overcloud.

6.3.9. Zugriff auf die Erweiterte Overcloud

Der Director erzeugt ein Skript um Interaktionen mit Ihrer Overcloud vom Director-Host aus zu konfigurieren und zu authentifizieren. Der Director speichert diese Datei overcloudrc in Ihrem stack Benutzer Home-Verzeichnis. Um diese Datei zu benutzen, führen Sie folgenden Befehl aus:
$ source ~/overcloudrc
Dies lädt die nötigen Umgebungsvariablen um mit Ihrer Overcloud von der CLI des Director-Hosts zu interagieren. Um wieder zur Interaktion mit dem Director-Host zu gelangen, führen Sie folgenden Befehl aus:
$ source ~/stackrc

6.3.10. Fencing der Controller-Knoten

Fencing ist der Prozess zur Isolation eines Knotens um ein Cluster und seine Ressourcen zu schützen. Ohne Fencing kann ein fehlerhafter Knoten Datenbeschädigung in einem Cluster verursachen.
Der Director verwendet ein Tool namens Pacemaker um ein hochverfügbares Cluster von Controller-Knoten bereitzustellen. Pacemaker verwendet einen Prozess namens STONITH (Shoot-The-Other-Node-In-The-Head) um fehlerhafte Knoten abzugrenzen. STONITH ist in Ihrem Cluster standardmäßig deaktiviert und muss manuell konfiguriert werden, damit der Pacemaker die Energieverwaltung jedes Knotens im Cluster steuern kann.

Anmerkung

Melden Sie sich bei jedem Knoten als heat-admin Benutzer vom stack Benutzer im Director an. Die Erstellung der Overcloud kopiert automatisch den stack SSH Schlüssel des Benutzers zum heat-admin jedes Knotens.
Überprüfen Sie mit pcs status, dass Sie ein laufendes Cluster haben:
$ sudo pcs status
Cluster name: openstackHA
Last updated: Wed Jun 24 12:40:27 2015
Last change: Wed Jun 24 11:36:18 2015
Stack: corosync
Current DC: lb-c1a2 (2) - partition with quorum
Version: 1.1.12-a14efad
3 Nodes configured
141 Resources configured
Überprüfen Sie mit pcs property show, dass stonith deaktiviert ist:
$ sudo pcs property show
Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: openstackHA
 dc-version: 1.1.12-a14efad
 have-watchdog: false
 stonith-enabled: false
Lassen Sie sich eine vollständige Liste von IPMI-Optionen anzeigen, die von Pacemaker unterstützt werden:
$ sudo pcs stonith describe fence_ipmilan
Jeder Knoten erfordert Konfiguration von IPMI-Geräten um die Energieverwaltung zu steuern. Das beinhaltet das Hinzufügen eines stonith Geräts in Pacemaker für jeden Knoten. Benutzen Sie folgenden Befehl für das Cluster:
Für Controller-Knoten 1:
$ sudo pcs stonith create my-ipmilan-for-controller01 fence_ipmilan pcmk_host_list=overcloud-controller-0 ipaddr=192.0.2.205 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller01 avoids overcloud-controller-0
Für Controller-Knoten 2:
$ sudo pcs stonith create my-ipmilan-for-controller02 fence_ipmilan pcmk_host_list=overcloud-controller-1 ipaddr=192.0.2.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller02 avoids overcloud-controller-1
Für Controller-Knoten 3:
$ sudo pcs stonith create my-ipmilan-for-controller03 fence_ipmilan pcmk_host_list=overcloud-controller-2 ipaddr=192.0.2.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller03 avoids overcloud-controller-2

Anmerkung

Der zweite Befehl in jedem Beispiel stellt sicher, dass der Knoten sich nicht selbst abgrenzt.
Führen Sie folgenden Befehl aus um alle stonith-Ressourcen zu sehen:
$ sudo pcs stonith show
Führen Sie folgenden Befehl aus um eine bestimmte stonith-Ressource zu sehen:
$ sudo pcs stonith show [stonith-name]
Als letzten Schritt aktivieren Sie das Fencing, indem Sie die stonith Eigenschaft auf true stellen:
$ sudo pcs property set stonith-enabled=true
Überprüfen Sie die Eigenschaft:
$ sudo pcs property show

6.3.11. Abschließen der Erweiterten Overcloud

Dies schließt die Erstellung der Erweiterten Overcloud ab. Funktionen zur Bearbeitung nach Abschluss der Erstellung finden Sie unter Kapitel 7, Aufgabenausführung nach Erstellung der Overcloud.

Kapitel 7. Aufgabenausführung nach Erstellung der Overcloud

Dieses Kapitel erläutert einige der Funktionen, die Sie nach Erstellung der gewünschten Overcloud ausführen können.

7.1. Erstellung des Externen Netzwerks der Overcloud

In Einfachen und Erweiterten Overcloud-Szenarien wurden die Knotenschnittstellen darauf konfiguriert, das Externe Netzwerk zu benutzen. Dieses Netzwerk muss jedoch noch immer auf der Overcloud erstellt werden, damit man den Instanzen Floating IP-Adressen zuweisen kann. Dieses Verfahren geht von einer dedizierten Schnittstelle oder einem systemeigenen VLAN für das Externe Netzwerk aus.
overcloud beziehen und Externes Netzwerk in Neutron erstellen:
$ source ~/overcloudrc
$ neutron net-create nova --router:external --provider:network_type flat --provider:physical_network datacentre
$ neutron subnet-create --name nova --enable_dhcp=False --allocation-pool=start=10.1.1.51,end=10.1.1.250 --gateway=10.1.1.1 nova 10.1.1.0/24
Erstellte Netzwerke mit neutron net-list bestätigen:
$ neutron net-list
+-----------------------+-------------+---------------------------------------------------+
| id                    | name        | subnets                                           |
+-----------------------+-------------+---------------------------------------------------+
| d474fe1f-222d-4e32... | ext-net     | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f 192.0.2.0/24 |
| d4746a34-76a4-4b88... | default-net | 4c85b94d-f868-4300-bbbc-8c499cdbbe5e 10.0.0.0/24  |
+-----------------------+-------------+---------------------------------------------------+

7.2. Validieren der Overcloud

Die Overcloud benutzt Tempest um eine Reihe von Integrationstests durchzuführen. Dieses Verfahren zeigt, wie man seine Overcloud mit Tempest validiert. Überprüfen Sie vor der Ausführung von Tempest, dass die heat_stack_owner Rolle in Ihrer Overcloud existiert:
$ source ~/overcloudrc
$ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+
Falls die Rolle nicht existiert, muss sie erstellt werden:
$ keystone role-create --name heat_stack_owner
Führen Sie folgenden Befehl aus um die Overcloud zu überprüfen
$ openstack overcloud validate --overcloud-auth-url $OS_AUTH_URL --overcloud-admin-password $OS_PASSWORD
Die $OS_AUTH_URL und $OS_PASSWORD Umgebungsvariablen benutzen in overcloudrc festgelegte Werte.

Anmerkung

Die vollständige Tempest-Testauflistung kann Stunden dauern. Alternativ können Sie Teile des Tests mit der --tempest-args smoke Option durchführen.
$ openstack overcloud validate --overcloud-auth-url $OS_AUTH_URL --overcloud-admin-password $OS_PASSWORD --tempest-args smoke

7.3. Skalierung der Overcloud

Es kann vorkommen, dass Sie nach der Erstellung der Overcloud mehr Knoten hinzufügen müssen. Zum Beispiel müssen Sie vielleicht mehr Compute-Knoten zur Overcloud hinzufügen. Diese Situation würde eine Aktualisierung der Overcloud erfordern.

Skalierung mit dem Overcloud-Plan

Wenn Sie Abschnitt 6.2, »Szenario 2: Erstellen einer Einfachen Overcloud mithilfe des CLI« benutzt haben um eine Overcloud zu erstellen, erfordert die Skalierung der Overcloud ein Update zum overcloud Plan im Director. Identifizieren Sie zuerst den UUID des Plans:
$ openstack management plan list
Bestimmen Sie die zu skalierende Rolle. Zu einer Auflistung der Rollen gelangen Sie mit folgendem Befehl:
$ openstack management role list
Aktualisieren Sie den Plan um die gewünschte Anzahl von Knoten zu benutzen. In diesem Fall wird auf fünf Knoten skaliert.
$ openstack management plan set [UUID] -S Compute-1=5
Dies ändert die gewünschte Anzahl von Compute-Knoten auf 5 im overcloud Plan. Nach Aktualisierung des Plans führen Sie erneut den overcloud deploy Befehl aus:
$ openstack overcloud deploy --plan "[UUID]" -e [ENVIRONMENT_FILE]
Dies aktualisiert den gesamten Overcloud-Stack. Beachten Sie, dass lediglich der Stack aktualisiert wird. Die Overcloud wird nicht gelöscht und der Stack wird nicht ersetzt.

Wichtig

Wenn Sie bei der Erstellung der Overcloud zusätzliche Umgebungsdateien übertragen haben, übertragen Sie diese nun erneut unter der -e oder --environment-file Option um unerwünschte Änderungen der Overcloud zu vermeiden.

Skalieren mit Heat-Vorlagen

Wenn Sie Abschnitt 6.3, »Szenario 3: Erstellen einer Erweiterten Overcloud mit Ceph Knoten unter Verwendung des CLI« benutzt haben um die Overcloud zu erstellen, müssen Sie zur Skalierung der Overcloud openstack overcloud deploy noch einmal mit der gewünschten Anzahl von Knoten für eine Rolle ausführen. Zum Beispiel um 5 Compute-Knoten zu skalieren:
$ openstack overcloud deploy --templates ~/my-overcloud --compute-scale 5 -e [ENVIRONMENT_FILE]
Dies aktualisiert den gesamten Overcloud-Stack. Beachten Sie, dass lediglich der Stack aktualisiert wird. Die Overcloud wird nicht gelöscht und der Stack wird nicht ersetzt.

Wichtig

Wenn Sie bei der Erstellung der Overcloud zusätzliche Umgebungsdateien übertragen haben, übertragen Sie diese nun erneut unter der -e oder --environment-file Option um unerwünschte Änderungen der Overcloud zu vermeiden.

7.4. Entfernen von Knoten aus der Overcloud

Es kann vorkommen, dass Sie Knoten aus der Overcloud entfernen müssen. Zum Beispiel, wenn Sie einen problematischen Compute-Knoten ersetzen müssen.

Wichtig

Bevor Sie einen Compute-Knoten aus der Overcloud entfernen, migrieren Sie die Arbeitsauslastung aus dem Knoten zu anderen Compute-Knoten. Weitere Details finden Sie unter Abschnitt 7.5, »Ersetzen von Compute-Knoten«.

Entfernen von Knoten mit dem Overcloud Plan

Wenn Sie Abschnitt 6.2, »Szenario 2: Erstellen einer Einfachen Overcloud mithilfe des CLI« benutzt haben um eine Overcloud zu erstellen, erfordert die Entfernung von Knoten ein Update im overcloud Plan und Stack im Director. Identifizieren Sie zuerst den UUID des Plans:
$ openstack management plan list
UUID des Overcloud-Stacks identifizieren:
$ heat stack-list
UUID der zu löschenden Knoten identifizieren:
$ nova list
Folgenden Befehl ausführen um Knoten aus dem Stack zu löschen und den Plan entsprechend zu aktualisieren:
$ openstack overcloud node delete --stack [STACK] --plan [PLAN_UUID] -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]

Wichtig

Wenn Sie bei der Erstellung der Overcloud zusätzliche Umgebungsdateien übertragen haben, übertragen Sie diese nun erneut unter der -e oder --environment-file Option um unerwünschte Änderungen der Overcloud zu vermeiden.

Entfernen von Knoten mit Heat-Vorlagen

Wenn Sie Abschnitt 6.3, »Szenario 3: Erstellen einer Erweiterten Overcloud mit Ceph Knoten unter Verwendung des CLI« benutzt haben um eine Overcloud zu erstellen, erfordert die Entfernung von Overcloud Knoten ein Update des overcloud Stacks im Director unter Verwendung von lokalen Vorlagendateien. Identifizieren Sie zuerst den UUID des Overcloud-Stacks:
$ heat stack-list
UUID der zu löschenden Knoten identifizieren:
$ nova list
Folgenden Befehl ausführen um Knoten aus dem Stack zu löschen und den Plan entsprechend zu aktualisieren:
$ openstack overcloud node delete --stack [STACK] --templates ~/my-overcloud -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]

Wichtig

Wenn Sie bei der Erstellung der Overcloud zusätzliche Umgebungsdateien übertragen haben, übertragen Sie diese nun erneut unter der -e oder --environment-file Option um unerwünschte Änderungen der Overcloud zu vermeiden.

7.5. Ersetzen von Compute-Knoten

Falls ein Compute-Knoten fehlschlägt, können Sie diesen Knoten mit einem Funktionstüchtigen ersetzen. Einen Compute-Knoten ersetzen Sie mit dem folgenden Verfahren:
  • Arbeitsauslastung aus dem bestehenden Compute-Knoten migrieren
  • Bestehenden Compute-Knoten herunterfahren
  • Compute-Knoten aus dem Overcloud entfernen
  • Overcloud mit neuem Compute-Knoten skalieren
Dieser Prozess stellt sicher, dass ein Knoten ersetzt werden kann, ohne die Verfügbarkeit der VMs zu beeinträchtigen.

Prozedur 7.1. Einrichten von Schlüsseln

Alle Compute-Knoten erfordern einen freigegebenen SSH-Schlüssel, damit jeder Host nova Benutzer während dem Migrationsprozess Zugriff hat. Mit folgendem Prozess können Sie für jeden Compute-Knoten ein SSH-Schlüsselpaar einrichten.
  1. SSH-Schlüssel aktivieren:
    $ ssh-keygen -t rsa -f nova_id_rsa
    
  2. Bei jedem Compute-Knoten den SSH-Schlüssel ins nova Home-Verzeichnis des Benutzers kopieren.
  3. Logen Sie sich in jeden Compute-Knoten als nova Benutzer ein und führen Sie das folgende Skript aus um die Schlüssel einzurichten:
    NOVA_SSH=/var/lib/nova/.ssh
    mkdir ${NOVA_SSH}
    
    cp nova_id_rsa ${NOVA_SSH}/id_rsa
    chmod 600 ${NOVA_SSH}/id_rsa
    cp nova_id_rsa.pub ${NOVA_SSH}/id_rsa.pub
    cp nova_id_rsa.pub ${NOVA_SSH}/authorized_keys
    
    chown -R nova.nova ${NOVA_SSH}
    
    # enable login for nova user on compute hosts:
    usermod -s /bin/bash nova
    
    # add ssh keys of overcloud nodes into known hosts:
    ssh-keyscan -t rsa `os-apply-config --key hosts --type raw --key-default '' | awk '{print $1}'` >>/etc/ssh/ssh_known_hosts
    

Prozedur 7.2. Virtuelle Maschinen aus den Compute-Knoten migrieren

  1. Beziehen Sie overcloudrc aus dem Director und rufen Sie eine Liste der aktuellen Nova Dienste ab:
    $ source ~stack/overcloudrc
    $ nova service-list
    
  2. Zum Migrieren den nova-compute Dienst auf dem Knoten deaktivieren.
    $ nova service-disable [service-id] nova-compute
    
    Das verhindert, dass neue VMs darauf geplant werden.
  3. Prozess zur Migration der VMs aus dem Knoten starten:
    # nova host-servers-migrate [service-id]
    
  4. Der aktuelle Status des Migrationsprozesses kann mit folgendem Befehl abgefragt werden:
    # nova migration-list
    
  5. Wenn die Migration aller VMs abgeschlossen ist, wird ihr Status in Nova auf VERIFY_RESIZE geändert. Das gibt Ihnen die Möglichkeit den Abschluss der Migration zu bestätigen oder sie zurückzusetzen. Bestätigen Sie die Migration mit dem Befehl:
    # nova resize-confirm [server-name]
    
  6. Wenn schließlich alle Migrationen abgeschlossen und bestätigt sind, entfernen Sie den auf dem Compute-Knoten ausgeführten (aber deaktivierten) Dienst ganz aus Nova:
    # nova service-delete [service-id]
    
    Jetzt können Sie den Knoten neu starten oder herunterfahren (unter Verwendung des Ironic API), oder sogar komplett aus der Overcloud entfernen, indem Sie die Overcloud-Bereitstellung herunterskalieren.

Prozedur 7.3. Entfernen des Compute-Knotens aus der Overcloud

Prozedur 7.4. Skalieren der Overcloud mit einem neuen Compute-Knoten

7.6. Importieren von Virtuellen Maschinen in die Overcloud

Benutzen Sie folgendes Verfahren, wenn Sie eine bestehende OpenStack Umgebung haben und deren virtuelle Maschinen zu Ihrer Red Hat Enterprise Linux Open Stack Platform Umgebung migrieren möchten.
Erstellen Sie ein neues Image, indem Sie einen Snapshot von einem laufenden Server machen und das Image herunterladen.
$ nova image-create instance_name image_name
$ glance image-download image_name --file exported_vm.qcow2
Laden Sie das exportierte Image in die Overcloud hoch und starten Sie eine neue Instanz.
$ glance image-create --name imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
$ nova boot --poll --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id imported

Wichtig

Jeder VM-Datenträger muss aus der bestehenden OpenStack Umgebung in die neue Red Hat Enterprise Linux OpenStack Platform kopiert werden. Snapshots, die QCOW benutzen, werden ihr ursprüngliches Schichtsystem verlieren.

7.7. Aktualisieren von Director-Paketen und Images

Der Director ist abhängig von RPM-Methoden um Ihre Umgebung zu aktualisieren. Dazu gehört auch sicher zu stellen, dass der Host Ihres Directors das neuste Paket verwendet yum:
$ sudo yum update
Gelegentlich müssen Sie vielleicht die Images für Knotensuche und Overcloud-Bereitstellung aktualisieren. Neue Images beziehen Sie von der Seite für Red Hat Enterprise Linux OpenStack Platform Downloads im Red Hat Kundenportal bei https://access.redhat.com/site/products/red-hat-enterprise-linux-openstack-platform/.
Laden Sie diese Images ins images Verzeichnis auf dem stack Home des Benutzers (/home/stack/images). Wenn Sie diese Images abgerufen haben, folgen Sie diesem Verfahren um sie zu erstetzen:

Prozedur 7.5. Aktualisieren von Director-Images

  1. Entfernen Sie bestehende Images aus dem Director.
    $ openstack image list
    $ openstack image delete [IMAGE-UUID] [IMAGE-UUID] [IMAGE-UUID] [IMAGE-UUID] [IMAGE-UUID]
    
  2. Importieren Sie die neusten Images in den Director.
    $ cd ~/images
    $ openstack overcloud image upload
    $ openstack baremetal configure boot
    

    Warnung

    Die Ausführung von openstack baremetal configure boot entfernt alle Profilinformationen und Bootoptionen aus den capabilities Eigenschaften aller Knoten. Diese Information muss für jeden Knoten ersetzt werden. Weitere Informationen finden Sie unter BZ#1241199.
Der Director ist jetzt aktualisiert und benutzt das neueste Paket und die neuesten Images. Sie müssen nach diesem Update keine Dienste neu starten.

7.8. Aktualisieren von Overcloud-Paketen

Die Overcloud ist abhängig von Standard-RPM-Methoden um die Umgebung zu aktualisieren. Das beinhaltet auch an allen Knoten mit dem Befehl openstack overcloud update im Director Updates durchzuführen.
Die parallele Durchführung von Updates an allen Knoten kann Probleme verursachen. Ein Paket-Update kann beispielsweise einen Neustart beinhalten, was andere Knoten unterbrechen würde. Deswegen aktualisiert der Update-Prozess jeden Knoten unter Verwendung einer bestimmten Anzahl von Breakpoints. Das heißt, dass jeder Knoten einzeln aktualisiert wird. Wenn das Paket-Update für einen Knoten abgeschlossen wurde, wird der Aktualisierungsprozess für den nächsten Knoten gestartet.
Der Breakpoint Prozess ist gewöhnlich automatisch. Die -i Option bietet jedoch einen interaktiven Modus, der bei jedem Breakpoint Bestätigung erfordert.

Paket-Aktualisierungen bei mit einem Plan erstellten Overclouds

Wenn Sie Abschnitt 6.2, »Szenario 2: Erstellen einer Einfachen Overcloud mithilfe des CLI« verwendet haben um eine Overcloud zu erstellen, benötigt die Aktualisierung des Overcloud-Knoten-Pakets ein Update unter Verwendung des overcloud Plans. Identifizieren Sie zuerst den UUID des Plans:
$ openstack management plan list
Führen Sie folgenden Befehl aus um die Knoten im Stack zu aktalisieren:
$ openstack overcloud update stack --plan [PLAN_UUID] -e [ENVIRONMENT_FILE] -i overcloud
Das leitet den Aktualisierungsprozess des Paketes für alle Knoten im overcloud Stack ein. Es stellt den UpdateIdentifier Parameter im overcloud Plan ein und löst dann den Vorgang zur Stack-Aktualisierung aus. Das wiederum führt yum update bei jedem Knoten aus.

Wichtig

Wenn Sie bei der Erstellung der Overcloud zusätzliche Umgebungsdateien übertragen haben, übertragen Sie diese nun erneut unter der -e oder --environment-file Option um unerwünschte Änderungen der Overcloud zu vermeiden.

Aktualisieren von Paketen bei mit Heat-Vorlagensammlung erstellten Overclouds

Wenn Sie Abschnitt 6.3, »Szenario 3: Erstellen einer Erweiterten Overcloud mit Ceph Knoten unter Verwendung des CLI« benutzt haben um eine Overcloud zu erstellen, erfordert die Aktualisierung des Overcloud-Knoten-Pakets ein Update unter Verwendung der lokalen Heat-Vorlagensammlung.
Führen Sie folgenden Befehl aus um die Knoten im Stack zu aktalisieren:
$ openstack overcloud update stack --templates [TEMPLATES_DIR] -e [ENVIRONMENT_FILE] -i overcloud
Das leitet den Aktualisierungsprozess des Pakets für alle Knoten im overcloud Stack ein. Es setzt den UpdateIdentifier Parameter in der Overcloud Heat-Vorlagensammlung und löst dann den Stack Update Vorgang aus. Das wiederum führt yum update bei jedem Knoten aus.

Wichtig

Wenn Sie bei der Erstellung der Overcloud zusätzliche Umgebungsdateien übertragen haben, übertragen Sie diese nun erneut unter der -e oder --environment-file Option um unerwünschte Änderungen der Overcloud zu vermeiden.

7.9. Entfernen der Overcloud

Die Overcloud kann auf Wunsch entfernt werden.

Prozedur 7.6. Entfernen der Overcloud

  1. Löschen einer vorhandenen Overcloud:
    $ heat stack-delete overcloud
    
  2. Löschen der Overcloud bestätigen:
    $ heat stack-list
    
    Der Löschvorgang kann ein paar Minuten dauern.
Wenn die Entfernung abgeschlossen ist, folgen Sie den Standardschritten in den Bereitstellungsszenarien um Ihre Overcloud neu zu erstellen.

Kapitel 8. Erstellen benutzerdefinierter Konfigurationen

In bestimmten Fällen möchten Sie vielleicht Konfigurationen für zusätzliche Anwendungen bereitstellen, die mit Ihrer Red Hat Enterprise Linux OpenStack Platform Umgebung integrierbar sind. Diese benutzerdefinierte Konfiguration erfordert zusätzliche Heat Volagen in Ihrem Overcloud-Stack. Dieser Abschnitt erläutert einige der für Sie verfügbaren benutzerdefinierten Konfigurationsvorgänge.

8.1. Konfiguration beim Erststart

Der Director bietet einen Mechanismus um an allen Knoten bei erstmaliger Erstellung der Overcloud eine Konfiguration durchzuführen. Das erreicht der Director durch cloud-init, was man unter Verwendung des OS::TripleO::NodeUserData Ressourcentyps abrufen kann.
In diesem Beispiel erstellen Sie zuerst eine einfache Heat-Vorlage (/home/stack/templates/nameserver.yaml), die ein Skript ausführt um dem resolv.conf jedes Knotens einen bestimmten Nameserver anzufügen. Sie benutzen den OS::TripleO::MultipartMime Ressourcentypen um das Konfigurationsskript zu senden.
heat_template_version: 2014-10-16

resources:
  userdata:
    type: OS::Heat::MultipartMime
    properties:
      parts:
      - config: {get_resource: nameserver_config}

  nameserver_config:
    type: OS::Heat::SoftwareConfig
    properties:
      config: |
        #!/bin/bash
        echo "nameserver 192.168.1.1" >> /etc/resolve.conf

outputs:
  OS::stack_id:
    value: {get_resource: userdata}
Erstellen Sie als nächstes eine Umgebungsdatei (/home/stack/templates/firstboot.yaml), die Ihre Heat-Vorlagen als OS::TripleO::NodeUserData Ressourcentyp registriert.
resource_registry:
  OS::TripleO::NodeUserData: ~/templates/nameserver.yaml
Um die Konfiguration beim Erststart hinzuzufügen, fügen Sie die Umgebungsdatei dem Stack hinzu, wenn Sie die Overcloud erstmals erstellen. Zum Beispiel:
$ openstack overcloud deploy --templates -e ~/templates/firstboot.yaml
Die -e wendet die Umgebungsdatei auf den Overcloud-Stack an.
Dies fügt die Konfiguration allen Knoten bei ihrer Erstellung und ihrem Erststart hinzu. Eine weitere Einbeziehung dieser Vorlagen, wie bei der Aktualisierung des Overcloud-Stacks, führt dieses Skript nicht aus.

8.2. Konfiguration nach Erstellung der Overcloud

Es kann vorkommen, dass Sie nach der Erstellung Ihrer Overcloud eine zusätzliche Konfiguration hinzufügen möchten, entweder bei erstmaliger Erstellung oder nachfolgender Aktualisierung der Overcloud. In diesem Fall verwenden Sie die OS::TripleO::NodeExtraConfigPost Ressource, um die Konfiguration unter Verwendung der Standard OS::Heat::SoftwareConfig Typen anzuwenden. So werden zusätzliche Konfigurationen nach Abschluss der Overcloud-Hauptkonfiguration angewendet.
In diesem Beispiel erstellen Sie zuerst eine einfache Heat-Vorlage (/home/stack/templates/nameserver.yaml), die ein Skript ausführt um resolv.conf jedem Knoten einen variablen Nameserver anzufügen.
heat_template_version: 2014-10-16

parameters:
  servers:
    type: json

  nameserver_ip:
    type: string

resources:

  ExtraConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolve.conf
          parameters:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  ExtraDeployments:
    type: OS::Heat::SoftwareDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ExtraConfig}
      actions: ['CREATE','UPDATE']

Wichtig

Der servers Parameter ist die Serverliste zur Anwendung der Konfiguration und wird von der Parent-Vorlage bereitgestellt. Dieser Parameter ist in allen OS::TripleO::NodeExtraConfigPost Vorlagen erforderlich.
Erstellen Sie als nächstes eine Umgebungsdatei (/home/stack/templates/post_config.yaml), die Ihre Heat-Vorlage als OS::TripleO::NodeExtraConfigPost: Ressourcentyp registriert.
resource_registry:
  OS::TripleO::NodeExtraConfigPost: nameserver.yaml
parameter_defaults:
  nameserver_ip: 192.168.1.1
Um die Konfiguration hinzuzufügen, fügen Sie die Umgebungsdatei dem Stack bei Erstellung oder Aktualisierung der Overcloud hinzu. Zum Beispiel:
$ openstack overcloud deploy --templates -e ~/templates/post_config.yaml
Das fügt die Konfiguration allen Knoten hinzu, nachdem die Hauptkonfiguration bei ihrer erstmaligen Erstellung oder einer nachfolgenden Aktualisierung abgeschlossen ist.

8.3. Änderung von Puppet-Konfigurationsdaten

Wenn Sie eine Reihe von lokalen Vorlagen verwendet haben um Ihre Overcloud zu erstellen (vgl. Abschnitt 6.3.5, »Verwendung der Standard Overcloud Heat-Vorlagen« im Erweiterten Bereitstellungs-Szenario), haben Sie die Option, die ursprünglichen Konfigurationsdaten zu ändern, entweder vor der erstmaligen Erstellung der Overcloud oder bei nachfolgenden Aktualisierungen. Diese Daten befinden sich in der Heat-Vorlagensammlung unter puppet/hieradata. Das bietet Ihnen die Möglichkeit, die ursprünglichen Konfigurations-Parameter zu ändern, die auf Overcloud-Knoten übertragen wurden.
Fügen Sie beispielsweise Folgendes zu puppet/hieradata/compute.yaml hinzu um den reservierten Arbeitsspeicher für Compute-Hosts auf 1024 MB zu erhöhen:
nova::compute::reserved_host_memory: 1024

Anmerkung

Die in puppet/hieradata/compute.yaml festgelegten, benutzerdefinierten Puppet-Klassen müssen in der OpenStack Puppet Modulsammlung existieren. Wenn nicht, fügen Sie entweder die Klasse zum relevanten Puppet-Manifest in puppet/manifests hinzu, oder erstellen Sie ein benutzerdefiniertes Puppet-Manifest und wenden Sie es als Post-Konfiguration an.

8.4. Anwendung benutzerdefinierter Puppet-Konfigurationen

Unter gewissen Umständen müssen Sie einige zusätzliche Komponenten zu Ihren Overcloud-Knoten installieren und konfigurieren. Das können Sie mit einem benutzerdefinierten Puppet-Manifest erreichen, das auf die Knoten angewandt wird, nachdem die Hauptkonfiguration abgeschlossen ist. Als einfaches Beispiel können Sie motd zu jedem Knoten installieren. Um das zu erreichen müssen Sie zuerst eine Heat-Vorlage (/home/stack/templates/custom_puppet_config.yaml) erstellen, die die Puppet-Konfiguration startet.
resources:
  ExtraPuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      config: {get_file: motd.pp}
      group: puppet
      options:
        enable_hiera: True
        enable_facter: False

  ExtraPuppetDeployments:
    type: OS::Heat::SoftwareDeployments
    properties:
      config: {get_resource: ExtraPuppetConfig}
      servers: {get_param: servers}
Das umfasst den /home/stack/templates/motd.pp innerhalb der Vorlage und übergibt ihn den Knoten zur Konfiguration. Die motd.pp Datei selbst enthält Ihre Puppet-Klassen zum Installieren und Konfigurieren motd.
Erstellen Sie dann eine Umgebungsdatei (/home/stack/templates/puppet_post_config.yaml), die Ihre Heat-Vorlage als OS::TripleO::NodeExtraConfigPost: Ressourcentyp registriert.
resource_registry:
  OS::TripleO::NodeExtraConfigPost: ~/templates/custom_puppet_config.yaml
Zuletzt nehmen Sie diese Umgebungsdatei bei der Erstellung des Overcloud-Stacks auf:
$ openstack overcloud deploy --templates -e ~/templates/custom_puppet_config.yaml
Das wendet die Konfiguration aus motd.pp auf alle Knoten in der Overcloud an.

Kapitel 9. Problembehandlung bei Problemen mit dem Director

Probleme können in verschiedenen Phasen der Director-Prozesse auftreten. Dieser Abschnitt gibt Informationen zur Diagnose der häufigsten Probleme.
Beachten Sie die allgemeinen Logs für die Komponenten des Directors:
  • Das /var/log Verzeichnis beinhaltet Logs für viele allgemeine OpenStack Platform Komponenten, aber auch Logs für standardmäßige Red Hat Enterprise Linux Anwendungen.
  • Der journald Dienst bietet Logs für verschiedene Komponenten. Beachten Sie, dass Ironic zwei Einheiten benutzt: openstack-ironic-api und openstack-ironic-conductor. Ebenso verwendet ironic-discoverd zwei Einheiten: openstack-ironic-discoverd und openstack-ironic-discoverd-dnsmasq. Benutzen Sie für jede jeweilige Komponente beide Einheiten. Zum Beispiel:
    $ sudo journalctl -u openstack-ironic-discoverd -u openstack-ironic-discoverd-dnsmasq
    
  • ironic-discoverd speichert auch die Ramdisk-Logs in /var/log/ironic-discoverd/ramdisk/ als gz-komprimierte tar-Dateien. Dateinamen beinhalten Datum, Zeit und IPMI-Adresse des Knotens. Benutzen Sie diese Logs zur Diagnose von Introspektionsproblemen.

9.1. Problembehandlung bei der Knotenregistrierung

Probleme bei der Registrierung von Knoten hängen gewöhnlich mit falschen Knotendetails zusammen. Benutzen Sie in diesem Fall ironic um Probleme mit den angegebenen Knotendaten zu beheben. Hier ein paar Beispiele:

Prozedur 9.1. Reparieren einer fehlerhaften MAC-Adresse

  1. Zugewiesenen Port-UUID ermitteln
    $ ironic node-port-list [NODE UUID]
    
  2. MAC-Adresse aktualisieren:
    $ ironic port-update [PORT UUID] replace address=[NEW MAC]
    

Prozedur 9.2. Fehlerhafte IPMI-Adresse reparieren

  • Führen Sie folgenden Befehl aus:
    $ ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]
    

9.2. Problembehandlung bei Hardware-Introspektion

Der Ermittlungs- und Introspektionsprozess muss bis zum Ende durchlaufen. Der Discovery Daemon von Ironic (ironic-discoverd) läuft nach einem Standardzeitraum von 1 Stunde ab, wenn die Discovery Ramdisk keine Antwort bereitstellt. Manchmal deutet das auf einen Fehler in der Discovery Ramdisk hin, aber normalerweise passiert dies aufgrund eines Konfigurationsfehlers der Umgebung, insbesondere der BIOS Boot Einstellungen.
Hier finden Sie allgemeine Szenarien von Umgebungs-Konfigurationsfehlern und Tipps diese zu erkennen und zu lösen.

Fehler beim Start von Knoten-Introspektion

Normalerweise benutzt der Introspektionsprozess baremetal introspection, welcher als übergeordneter Befehl für Ironic-Dienste agiert. Wenn die Introspektion jedoch direkt mit ironic-discoverd ausgeführt wird, kann sie Knoten im AVAILABLE Zustand übersehen, was jedoch für die Bereitstellung, nicht für die Ermittlung gemeint ist. Ändern Sie den Status der Knoten vor der Ermittlung auf MANAGEABLE:
$ ironic node-set-provision-state [NODE UUID] manage
Wenn die Ermittlung abgeschlossen ist, ändern Sie den Status vor der Bereitstellung wieder auf AVAILABLE:
$ ironic node-set-provision-state [NODE UUID] provide

Anhalten des Discovery-Prozesses

Aktuell bietet ironic-discoverd keine direkte Möglichkeit die Ermittlung anzuhalten. Es wird empfohlen abzuwarten, bis der Prozess abgelaufen ist. Ändern Sie wenn nötig die timeout Einstellung auf /etc/ironic-discoverd/discoverd.conf um das Zeitlimit auf eine andere Zeitspanne in Minuten zu ändern.
Im schlechtesten Fall können Sie die Ermittlung für alle Knoten mit folgendem Prozess anhalten:

Prozedur 9.3. Anhalten des Discovery-Prozesses

  1. Ändern Sie den Energiezustand jedes Knotens auf Aus:
    $ ironic node-set-power-state [NODE UUID] off
    
  2. ironic-discoverd Cache entfernen und neu starten:
    $ rm /var/lib/ironic-discoverd/discoverd.sqlite
    $ sudo systemctl restart openstack-ironic-discoverd
    

9.3. Problembehandlung bei Erstellen der Overcloud

Die Bereitstellung kann auf drei Ebenen scheitern:
  • Orchestrierung (Heat und Nova Dienste)
  • Bare-Metal Provisioning (Ironic Dienst)
  • Konfiguration nach Bereitstellung (Puppet)
Wenn eine Overcloud-Bereitstellung auf einer dieser Ebenen scheitert, benutzen Sie die OpenStack Clients und Dienst-Logdateien um die gescheiterte Bereitstellung zu finden.

9.3.1. Orchestrierung

In den meisten Fällen zeigt Heat den fehlerhaften Overcloud-Stack an, nachdem die Erstellung der Overcloud fehlgeschlagen ist.
$ heat stack-list

+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+
Wenn der Stack leer ist, weist das auf ein Problem mit der ursprünglichen Orchestrierungseinstellung hin. Überprüfen Sie Ihre Heat-Vorlagen und Konfigurationsoptionen, und prüfen Sie, ob nach der Ausführung von openstack overcloud deploy Fehlermeldungen angezeigt werden.

9.3.2. Bare-Metal Provisioning

Prüfen Sie ironic um alle registrierten Knoten und deren aktuellen Status zu überprüfen:
$ ironic node-list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+
Hier finden Sie allgemeine Probleme, die sich aus dem Provisioning-Prozess ergeben können.
  • Überprüfen Sie die Provision State und Maintenance Spalten in der entstandenen Tabelle. Achten Sie dabei auf Folgendes:
    • Eine leere Tabelle oder weniger Knoten als erwartet
    • Maintenance steht auf Wahr
    • Provision State steht auf manageable
    Das weist normalerweise auf ein Problem im Registrierungs- oder Ermittlungsprozess hin. Wenn zum Beispiel Maintenance automatisch auf Wahr gestellt ist, benutzen die Knoten gewöhnlich die falschen Anmeldedaten zur Energieversorgung.
  • Wenn Provision State als available angezeigt wird, ist das Problem bereits aufgetreten, bevor die Bare-Metal Bereitstellung begonnen hat.
  • Wenn Provision State als active und Power State als power on angezeigt wird, wurde die Bare-Metal Bereitstellung erfolgreich abgeschlossen. Das heißt, dass das Problem bei einer Konfiguration nach der Bereitstellung entstanden ist.
  • Wenn Provision State für einen Knoten als wait call-back angezeigt wird, ist der Bare-Metal Provisioning-Prozess für diesen Knoten noch nicht abgeschlossen. Warten Sie, bis sich der Status entsprechend ändert. Stellen Sie ansonsten eine Verbindung mit der virtuellen Konsole des fehlerhaften Knotens her und überprüfen Sie die Ausgabe.
  • Wenn Provision State als error oder deploy failed angezeigt wird, ist das Bare-Metal Provisioning für diesen Knoten fehlgeschlagen. Überprüfen Sie die Details des Bare-Metal Knotens:
    $ ironic node-show [NODE UUID]
    
    Sehen Sie nach dem last_error Feld, welches Fehlerbeschreibungen enthält. Wenn die Fehlermeldung unklar ist, können Sie diese mithilfe von Logs klären:
    $ sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-api
    
  • Wenn Sie sehen, dass wait timeout error und der Knoten Power State als power onangezeigt wird, stellen Sie eine Verbindung zur virtuellen Konsole des fehlerhaften Knotens her und überprüfen Sie die Ausgabe.

9.3.3. Konfiguration nach Bereitstellung

In der Konfigurationsphase kann vieles schief laufen. Es könnte zum Beispiel aufgrund eines Einstellungsfehlers Probleme geben, ein bestimmtes Puppet-Modul abzuschließen. Dieser Abschnitt bietet Ihnen einen Prozess, solche Probleme zu diagnostizieren.

Prozedur 9.4. Erkennen von Konfigurationsproblemen nach der Bereitstellung

  1. Listen Sie alle Ressourcen aus dem Overcloud-Stack auf um erkennen zu können, welche fehlerhaft ist:
    $ heat resource-list overcloud
    
    Dies zeigt eine Tabelle aller Ressourcen mit ihrem jeweiligen Status an. Suchen Sie nach Ressourcen mit CREATE_FAILED.
  2. Fehlerhafte Ressource anzeigen:
    $ heat resource-show overcloud [FAILED RESOURCE]
    
    Suchen Sie nach Informationen im resource_status_reason Feld, die Ihnen bei der Diagnose helfen.
  3. Benutzen Sie den nova Befehl um die IP-Adressen der Overcloud-Knoten sehen zu können.
    $ nova list
    
    Loggen Sie sich als heat-admin Benutzer in einen der bereitgestellten Knoten ein. Wenn zum Beispiel die Ressourcenliste des Stacks den bei einem Controller-Knoten aufgetretenen Fehler anzeigt, loggen Sie sich bei einem Controller-Knoten ein. Der heat-admin Benutzer hat Sudo Zugriff.
    $ ssh heat-admin@192.0.2.14
    
  4. Überprüfen Sie den os-collect-config Log auf einen möglichen Grund für den Fehler.
    $ sudo journalctl -u os-collect-config
    
  5. In manchen Fällen scheitert Nova bei der Bereitstellung der Knoten auf ganzer Linie. Diese Situation würde mit einer fehlerhaften OS::Heat::ResourceGroup für einen der Overcloud-Rollentypen angezeigt werden. Benutzen Sie nova um den Fehler in diesem Fall einsehen zu können.
    $ nova list
    $ nova show [SERVER ID]
    
    Der häufigste Fehler wird mit der Fehlermeldung No valid host was found angezeigt. Unter Abschnitt 9.4, »Problembehandlung bei Fehlermeldung "Keine gültigen Hosts gefunden"« finden Sie Details zur Problembehandlung dieses Fehlers. Ansonsten können Sie folgende Logdateien auf weiterführende Problembehandlung überprüfen:
    • /var/log/nova/*
    • /var/log/heat/*
    • /var/log/ironic/*
  6. Benutzen Sie das SOS-Toolset, welches Informationen über die Systemhardware und Konfiguration sammelt. Benutzen Sie diese Informationen zur Diagnose und zum Debuggen. SOS wird allgemein zur Unterstützung von Technikern und Entwicklern verwendet. SOS ist hilfreich bei der Undercloud und Overcloud. Installieren des sos Pakets:
    $ sudo yum install sos
    
    Bericht erstellen
    $ sudo sosreport --all-logs
    

9.4. Problembehandlung bei Fehlermeldung "Keine gültigen Hosts gefunden"

Manchmal enthält das /var/log/nova/nova-conductor.log folgende Fehler:
NoValidHost: No valid host was found. There are not enough hosts available.
Das bedeutet, dass der Nova-Planer keinen geeigneten Bare-Metal-Knoten finden konnte um die neue Instanz zu starten. Das wiederum bedeutet normalerweise eine fehlende Übereinstimmung von Ressourcen, die Nova zu finden erwartet und Ressourcen, die Ironic Nova angekündigt hat. In diesem Fall überprüfen Sie Folgendes:
  1. Stellen Sie sicher, dass die Introspektion für Sie erfolgreich verläuft. Überprüfen Sie andererseits, dass jeder Knoten die erforderlichen Ironic-Knoteneigenschaften enthält. Für jeden Knoten:
    $ ironic node-show [NODE UUID]
    
    Überprüfen Sie, dass das properties JSON-Feld gültige Werte für die Schlüssel cpus, cpu_arch, memory_mb und local_gb hat.
  2. Überprüfen Sie, dass die verwendete Nova-Variante nicht die Ironic-Knoteneigenschaften für eine erforderliche Anzahl von Knoten übersteigt:
    $ nova flavor-show [FLAVOR NAME]
    
  3. Überprüfen Sie, dass der Zustand einer ausreichenden Anzahl von Knoten available ist, entsprechend ironic node-list. Ist der Zustand der Knoten manageable, bedeutet dies normalerweise, dass die Introspektion fehlgeschlagen ist.
  4. Überprüfen Sie, dass die Knoten nicht im Wartungsmodus sind. Benutzen Sie dafür die ironic node-list. Wurde ein Knoten automatisch in den Wartungsmodus geändert, bedeutet das normalerweise, dass die Energie-Anmeldedaten nicht korrekt sind. Überprüfen Sie diese und beseitigen Sie den Wartungsmodus:
    $ ironic node-set-maintenance [NODE UUID] off
    
  5. Wenn Sie die Tools zum Automated Health Check (AHC) verwenden um automatisches Knotentagging auszuführen, stellen Sie sicher, dass Sie genügend Knoten entsprechend jeder Variante/jedes Profils haben. Überprüfen Sie den capabilities Schlüssel im properties Feld für ironic node-show. Ein Knoten, der für die Compute-Rolle getagged ist, sollte zum Beispiel profile:compute enthalten.
  6. Es dauert eine Weile, bis Knoteninformationen nach der Introspektion von Ironic zu Nova übertragen wurden. Gewöhnlich ist das Directortool dafür zuständig. Wenn Sie aber einige Schritte manuell durchgeführt haben, kann es vorkommen, dass die Knoten eine Zeit lang nicht in Nova verfügbar sind. Benutzen Sie folgenden Befehl um die Gesamtressourcen in Ihrem System zu prüfen:
    $ nova hypervisor-stats
    

Anhang A. Komponenten

Dieser Abschnitt enthält eine Liste von Komponenten, die der Director benutzt.

Freigegebene Bibliotheken

Datenträgerimage-Builder
diskimage-builder ist ein Tool zur Image-Erzeugung.
dib-utils
dib-utils enthält Tools, die diskimage-builder verwendet.
os-collect-config, os-refresh-config, os-apply-config, os-net-config
Eine Reihe von Tools, die zur Konfiguration von Instanzen verwendet werden.
tripleo-image-elements
tripleo-image-elements ist ein Repository von diskimage-builder Stilelementen für die Installation verschiedener Software-Komponenten.

Installer

instack
instack führt diskimage-builder Stilelemente auf dem aktuellen System aus. Das ermöglicht einem aktuell laufenden System ein Element auf dieselbe Weise anzuwenden, wie diskimage-builder das Element zur Erstellung eines Images anwendet.
instack-undercloud
instack-undercloud ist ein Undercloud-Installer basierend auf instack.

Knoten-Verwaltung

ironic
Das Projekt OpenStack Ironic ist zuständig für Provisioning und Verwaltung von Bare-Metal Instanzen.
ironic-discoverd
ironic-discoverd ermittelt Hardware-Eigenschaften für neu registrierte Knoten.

Bereitstellungsplanung

tuskar
Das Projekt OpenStack Tuskar ist zuständig für die Planung von Bereitstellungen

Bereitstellung und Orchestrierung

heat
Das Projekt OpenStack Heat ist ein Orchestrierungs-Tool. Es liest YAML-Dateien, die die Ressourcen der OpenStack Umgebung beschreiben und setzt diese Ressourcen auf den gewünschten Status.
heat-templates
Das openstack-heat-templates Repository enthält zusätzliche Image-Elemente zur Produktion von Datenträger-Images für Puppet-Konfigurationen, die Heat verwenden.
tripleo-heat-templates
Das openstack-tripleo-heat-templates Repository beschreibt die OpenStack Umgebung in Heat Orchestrierungsvorlagen YAML-Dateien und Puppet-Manifesten. Tuskar verarbeitet diese Vorlagen, die durch Heat zur eigentlichen Umgebung werden.
puppet-modules
OpenStack Puppet-Module werden zur Konfiguration der OpenStack Umgebung verwendet durch tripleo-heat-templates.
tripleo-puppet-elements
tripleo-puppet-elements beschreibt die Inhalte von Datenträger-Images, die der Director verwendet um die Red Hat Enterprise Linux OpenStack Platform zu installieren.

Benutzeroberfläche

tuskar-ui
Bietet ein GUI um OpenStack zu installieren und zu verwalten. Es wird als Plugin zum Horizon Dashboard implementiert.
tuskar-ui-extras
Bietet GUI Verbesserungen für tuskar-ui. Es wird als Plugin zum Horizon-Dashboard implementiert.
python-openstackclient
python-openstackclient ist ein CLI-Tool, das mehrere Openstack Dienste und Clients verwaltet.
python-rdomanager-oscplugin
python-rdomanager-oscplugin ist ein CLI Tool, integriert in python-openstackclient. Es bietet Funktionen bezüglich der instack Installation und anfänglichen Konfiguration.

Anhang B. Energieverwaltungs-Driver

Obwohl IPMI die Hauptmethode des Directors bei der Kontrolle der Energieverwaltung ist, unterstützt der Director auch andere Energieverwaltungstypen. Dieser Anhang stellt Ihnen eine Liste von unterstützten Energieverwaltungs-Features zur Verfügung. Benutzen Sie die Energieverwaltungseinstellungen für Abschnitt 6.2.1, »Registrieren der Knoten für die Einfache Overcloud« oder Abschnitt 6.3.1, »Registrieren der Knoten für die Erweiterte Overcloud«.

B.1. Dell Remote Access Controller (DRAC)

DRAC ist eine Schnittstelle, die out-of-band Remoteverwaltungsfeatures einschließlich Energieverwaltung und Serverüberwachung bereitstellt.
pm_type
Stellen Sie diese Option auf pxe_drac.
pm_user, pm_password
DRAC Benutzername und Passwort.
pm_addr
IP Adresse des DRAC-Hosts.

B.2. Integrated Lights-Out (iLO)

Die Schnittstelle iLO von Hewlett-Packard bietet out-of-band Remoteverwaltungsfeatures einschließlich Energieverwaltung und Serverüberwachung.
pm_type
Stellen Sie diese Option auf pxe_ilo.
pm_user, pm_password
iLO Benutzername und Passwort.
pm_addr
IP-Adresse der iLO Schnittstelle.

Weitere Anmerkungen

  • Bearbeiten Sie die /etc/ironic/ironic.conf Datei und fügen Sie pxe_ilo zur enabled_drivers Option hinzu um diesen Driver zu aktivieren.
  • Der Director erfordert eine zusätzliche Reihe von Dienstprogrammen für iLo. Installieren Sie das python-proliantutils Paket und starten Sie den openstack-ironic-conductor Dienst neu:
    $ sudo yum install python-proliantutils
    $ sudo systemctl restart openstack-ironic-conductor.service
    
  • HP Knoten brauchen eine 2015 Firmware Version für erfolgreiche Introspection. Der Director wurde erfolgreich getestet mit Knoten, die die Firmware Version 1.85 (May 13 2015) verwenden.

B.3. iBoot

iBoot von Dataprobe ist eine Stromversorgungseinheit, die Remote-Energieversorgung für Systeme bereitstellt.
pm_type
Stellen Sie diese Option auf pxe_iboot.
pm_user, pm_password
iBoot Benutzername und Passwort
pm_addr
IP Adresse der iBoot Schnittstelle.
pm_relay_id (Optional)
iBoot Relay ID für den Host. Der Standard ist 1.
pm_port (Optional)
iBoot Port. Der Standard ist 9100.

Weitere Anmerkungen

  • Bearbeiten Sie die /etc/ironic/ironic.conf Datei und fügen Sie pxe_iboot zur enabled_drivers Option hinzu um diesen Driver zu deaktivieren.

B.4. SSH und Virsh

Der Director kann auf einen libvirt ausführenden Host über SSH zugreifen und virtuelle Maschinen als Knoten benutzen. Der Director benutzt virsh um die Energieverwaltung dieser Knoten zu steuern.

Wichtig

Diese Option steht nur für Test- und Evaluierungszwecke zur Verfügung. Sie wird für Red Hat Enterprise Linux OpenStack Platform Unternehmensumgebungen nicht empfohlen.
pm_type
Stellen Sie diese Option auf pxe_ssh.
pm_user, pm_password
SSH Benutzername und Inhalte des SSH öffentlichen Schlüssels.
pm_addr
IP Adresse des virsh Host.

Weitere Anmerkungen

  • Der libvirt hostende Server benötigt ein SSH Schlüsselpaar mit dem öffentlichen Schlüssel als pm_password Attribut.
  • Stellen Sie sicher, dass die ausgewählte pm_user vollen Zugriff auf die libvirt Umgebung hat.

Anhang C. Automated Health Check (AHC) Tool Parameter

Die folgenden Tabellen dienen als Referenz für die verschiedenen Parameter, die Sie als AHC Tools Richtlinien verwenden können.

C.1. Festplatte

AHC Tools berichten Datenträgereigenschaften von:
  1. Reguläre SATA Controller oder logische Driver von RAID Controllern
  2. Datenträger, die an einen Hewlett Packard RAID Controller angeschlossen sind

Tabelle C.1. Reguläre SATA Controller Parameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
Größe
Größe des Datenträgers
('disk', 'sda', 'size', '899')
Medium
Anbieter
Anbieter des Datenträgers
('disk', 'sda', 'vendor', 'HP')
Medium
Modell
Modell des Datenträgers
('disk', 'sda', 'model', 'LOGICAL VOLUME')
Hoch
rev
Firmware Revision des Datenträgers
('disk', 'sda', 'rev', '3.42')
Medium
WCE
Cache Schreiben Aktiviert
('disk', 'sda', 'WCE', '1')
Niedrig
RCD
Cache Lesen Deaktiviert
('disk', 'sda', 'RCD, '1')
Niedrig

Tabelle C.2. Hewlett Packard Raid Controller Parameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
Größe
Größe des Rohdatenträgers
('disk', '1I:1:1', 'size', '300')
Medium
Typ
Typ des Rohdatenträgers
('disk', '1I:1:1', 'type', 'SAS')
Niedrig
Slot
Slot ID des Rohdatenträgers
('disk', '1I:1:1', 'slot', '0')
Medium

C.2. System

Produktinformation wird von den DMI Strukturen des Hosts gegeben. Diese Information wird nicht immer vom Hardware-Hersteller gegeben.

Tabelle C.3. Produktparameter des Systems

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
Serienmäßig
Seriennummer der Hardware
('system', 'product', 'serial', 'XXXXXX'')
Unique*
Name
Produktname
('system', 'product', 'name', 'ProLiant DL360p Gen8 (654081-B21)')
Hoch
Anbieter
Name des Anbieters
('system', 'product', 'vendor', 'HP')
Medium

Tabelle C.4. System IPMI Parameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
ipmi
Die IPMI Kanalnummer
('system', 'ipmi', 'channel', 2)
Niedrig
ipmi-fake
IPMI Schnittstelle für Test fälschen
('system', 'ipmi-fake', 'channel', '0')
Niedrig

C.3. Firmware

Firmware-Information wird von den DMI Strukturen des Hosts gegeben. Diese Information wird nicht immer vom Hardware-Hersteller gegeben.

Tabelle C.5. Veröffentlichungsdatum\

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
Version
Version der BIOS
('firmware', 'bios', 'version', 'G1ET73WW (2.09 )')
Medium
Datum
Datum der BIOS Release
('firmware', 'bios', 'date', '10/19/2012')
Medium
Anbieter
Anbieter
('firmware', 'bios', 'vendor', 'LENOVO')
Niedrig

C.4. Netzwerk

Tabelle C.6. Netzwerkparameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
Serienmäßig
MAC-Adresse
('network', 'eth0', 'serial', 'd8:9d:67:1b:07:e4')
Unique
Anbieter
NIC Anbieter
('network', 'eth0', 'vendor', 'Broadcom Corporation')
Niedrig
Produkt
NIC Beschreibung
('network', 'eth0', 'product', 'NetXtreme BCM5719 Gigabit Ethernet PCIe')
Medium
Größe
Link Fähigkeit in bits/sec
('network', 'eth0', 'size', '1000000000')
Niedrig
ipv4
IPv4 Adresse
('network', 'eth0', 'ipv4', '10.66.6.136')
Hoch
ipv4-Netzmaske
IPv4 Netzmaske
('network', 'eth0', 'ipv4-netmask', '255.255.255.0')
Niedrig
ipv4-cidr
IPv4 cidr
('network', 'eth0', 'ipv4-cidr', '24')
Niedrig
ipv4-Netzwerk
IPv4 Netzwerkadresse
('network', 'eth0', 'ipv4-network', '10.66.6.0')
Medium
Link
Physicher Status des Links
('network', 'eth0', 'link', 'yes')
Medium
Driver
NIC Driver Name
('network', 'eth0', 'driver', 'tg3')
Niedrig
Duplex
NIC Duplex Typ
('network', 'eth0', 'duplex', 'full')
Niedrig
Geschwindigkeit
NIC aktuelle Verbindungsgeschwindigkeit
('network', 'eth0', 'speed', '10Mbit/s')
Medium
Latenz
PCI Latenz des Netzwerkgeräts
('network', 'eth0', 'latency', '0')
Niedrig
Automatische Aushandlung
NIC Automatische Aushandlung
('network', 'eth0', 'autonegotiation', 'on')
Niedrig

C.5. CPU

Tabelle C.7. Per CPU Parameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
physid
Physische ID der CPU
('cpu', 'physical_0', 'physid', '1')
Niedrig
Kerne
CPU Anzahl der Kerne
('cpu', 'physical_0', 'cores', '2')
Medium
enabled_cores
CPU Anzahl der aktivierten Kerne
('cpu', 'physical_0',' enabled_cores', '2')
Medium
Threads
CPU Anzahl der Kerne
('cpu', 'physical_0', 'threads', '4')
Medium
Produkt
CPU Identifikationsstring
('cpu', 'physical_0', 'product', 'Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz')
Hoch
Anbieter
CPU Anbieter
('cpu', 'physical_0', 'vendor', 'Intel Corp.')
Niedrig
Frequenz
CPU interne Frequenz in Hz
('cpu', 'physical_0', 'frequency', '1200000000')
Niedrig
Uhr
CPU Uhr in Hz
('cpu', 'physical_0', 'clock', '100000000')
Niedrig

Tabelle C.8. CPU Aggregat Parameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
Anzahl (physisch)
Anzahl der physischen CPUs
('cpu', 'physical', 'number', 2)
Medium
Anzahl (logisch)
Anzahl der logischen CPUs
('cpu', 'logical', 'number', '8')
Medium

C.6. Speicher

Speicherinformation wird von den DMI Strukturen des Hosts gegeben. Diese Information wird nicht immer vom Hardware-Hersteller gegeben.

Tabelle C.9. Speicherparameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
Gesamt
Speichermenge auf dem Host in Bytes
('memory', 'total', 'size', '17179869184')
Hoch
Größe
Bankgröße in Bytes
('memory', 'bank:0', 'size', '4294967296')
Medium
Uhr
Speichertaktgeschwindigkeit in Hz
('memory', 'bank:0', 'clock', '667000000')
Niedrig
Beschreibung
Speicherbeschreibung
('memory', 'bank:0', 'description', 'FB-DIMM DDR2 FB-DIMM Synchronous 667 MHz (1.5 ns)')
Medium
Anbieter
Speicheranbieter
('memory', 'bank:0', 'vendor', 'Nanya Technology')
Medium
Serienmäßig
Seriennummer des Speichers
('memory', 'bank:0', 'serial', 'C7590943')
Unique*
Slot
Physischer Slot dieser Bank
('memory', 'bank:0', 'slot', 'DIMM1')
Hoch
Banken
Anzahl der Speicherbanken
('memory', 'banks', 'count', 8)
Medium

C.7. Infiniband

Tabelle C.10. Infiniband per Kartenparameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
card_type
Kartentyp
('infiniband', 'card0', 'card_type', 'mlx4_0')
Medium
device_type
Karten-Gerätetyp
('infiniband', 'card0', 'device_type', 'MT4099')
Medium
fw_version
Firmware-Version der Karte
('infiniband', 'card0', 'fw_version', '2.11.500')
Hoch
hw_version
Hardware-Version der Karte
('infiniband', 'card0', 'hw_version', '0')
Niedrig
nb_ports
Anzahl der Ports
('infiniband', 'card0', 'nb_ports', '2')
Niedrig
sys_guid
Globally Unique ID der Karte
('infiniband', 'card0', 'sys_guid', '0x0002c90300ea7183')
Unique
node_guid
Globally Unique ID des Knotens
('infiniband', 'card0', 'node_guid', '0x0002c90300ea7180')
Unique

Tabelle C.11. Infiniband pro Port Parameter

Wert
Beschreibung
Beispielkonfiguration
Unterscheidungsebene
Status
Schnittstellen-Status
('infiniband', 'card0_port1', 'state', 'Down')
Hoch
physical_state
Physischer Status der Verbindung
('infiniband', 'card0_port1', 'physical_state', 'Down')
Hoch
Rate
Geschwindigkeit in Gbit/sec
('infiniband', 'card0_port1', 'rate', '40')
Hoch
base_lid
Lokale Basis-ID des Ports
('infiniband', 'card0_port1', 'base_lid', '0'
Niedrig
lmc
Lokale ID Maskenanzahl
('infiniband', 'card0_port1', 'lmc', '0')
Niedrig
sm_lid
Lokale ID des Subnetz Managers
('infiniband', 'card0_port1', 'sm_lid', '0')
Niedrig
port_guid
Globally Unique ID des Ports
('infiniband', 'card0_port1', 'port_guid', '0x0002c90300ea7181')
Unique

Anhang D. Netzwerkschnittstellen-Parameter

Die folgende Tabelle bestimmt die Parameter der Heat-Vorlagen für Netzwerkschnittstellentypen.

Tabelle D.1. Schnittstellenoptionen

Option
Standard
Beschreibung
Name
Name der Schnittstelle
use_dhcp
Falsch
DHCP benutzen um eine IP-Adresse zu bekommen
use_dhcpv6
Falsch
DHCP benutzen um eine v6 IP-Adresse zu bekommen
Adressen
Eine der Schnittstelle zugewiesene Sequenz von IP-Adressen
Routen
Eine der Schnittstelle zugewiesene Sequenz von Routen
mtu
1500
Die maximale Übertragungseinheit der Verbindung (maximum transmission unit oder MTU)
Primär
Falsch
Definiert die Schnittstelle als primäre Schnittstelle
defroute
Wahr
Diese Schnittstelle als Standardroute benutzen
nic_mapping
Benutzerdefinierte Zuordnung von nummerierten NICs für Systemnamen oder MAC-Adressen bereitstellen
persist_mapping
Falsch
Geräte-Alias-Konfiguration anstatt Systemnamen schreiben

Tabelle D.2. VLAN Optionen

Option
Standard
Beschreibung
vlan_id
Die VLAN-ID
Gerät
Dem VLAN anzufügendes, übergeordnetes VLAN-Gerät
use_dhcp
Falsch
DHCP benutzen um eine IP-Adresse zu bekommen
use_dhcpv6
Falsch
DHCP benutzen um eine v6 IP-Adresse zu bekommen
Adressen
Eine dem VLAN zugewiesene Sequenz von IP-Adressen
Routen
Eine dem VLAN zugewiesene Sequenz von Routen
mtu
1500
Die maximale Übertragungseinheit der Verbindung (maximum transmission unit oder MTU)
Primär
Falsch
Definiert das VLAN als primäre Schnittstelle
defroute
Wahr
Diese Schnittstelle als Standardroute benutzen
nic_mapping
Benutzerdefinierte Zuordnung von nummerierten NICs für Systemnamen oder MAC-Adressen bereitstellen
persist_mapping
Falsch
Geräte-Alias-Konfiguration anstatt Systemnamen schreiben

Tabelle D.3. OVS-Bondoptionen

Option
Standard
Beschreibung
Name
Name des Bonds
use_dhcp
Falsch
DHCP benutzen um eine IP-Adresse zu bekommen
use_dhcpv6
Falsch
DHCP benutzen um eine v6 IP-Adresse zu bekommen
Adressen
Eine dem Bond zugewiesene Sequenz von IP-Adressen
Routen
Eine dem Bond zugewiesene Sequenz von Routen
mtu
1500
Die maximale Übertragungseinheit der Verbindung (maximum transmission unit oder MTU)
Primär
Falsch
Definiert die Schnittstelle als primäre Schnittstelle
Mitglieder
Eine Sequenz von im Bond zu verwendenden Schnittstellenobjekten
ovs_options
Eine bei Erstellung des Bonds an OVS zu gegebene Reihe von Optionen
ovs_extra
Eine als OVS_EXTRA Parameter in der Bond-Netzwerkkonfigurationsdatei festzulegende Reihe von Optionen
defroute
Wahr
Diese Schnittstelle als Standardroute benutzen
nic_mapping
Benutzerdefinierte Zuordnung von nummerierten NICs für Systemnamen oder MAC-Adressen bereitstellen
persist_mapping
Falsch
Geräte-Alias-Konfiguration anstatt Systemnamen schreiben

Tabelle D.4. OVS Brückenoptionen

Option
Standard
Beschreibung
Name
Name der Brücke
use_dhcp
Falsch
DHCP benutzen um eine IP-Adresse zu bekommen
use_dhcpv6
Falsch
DHCP benutzen um eine v6 IP-Adresse zu bekommen
Adressen
Eine der Brücke zugewiesene Sequenz von IP-Adressen
Routen
Eine der Brücke zugewiesene Sequenz von Routen
mtu
1500
Die maximale Übertragungseinheit der Verbindung (maximum transmission unit oder MTU)
Mitglieder
Eine in der Brücke zu verwendende Sequenz von Schnittstelle, VLAN und Bond-Objekten
ovs_options
Eine bei Erstellung der Brücke an OVS zu übertragende Reihe von Optionen
ovs_extra
Eine als OVS_EXTRA Parameter in der Netzwerkkonfigurationsdatei der Brücke festzulegende Reihe von Optionen
defroute
Wahr
Diese Schnittstelle als Standardroute benutzen
nic_mapping
Benutzerdefinierte Zuordnung von nummerierten NICs für Systemnamen oder MAC-Adressen bereitstellen
persist_mapping
Falsch
Geräte-Alias-Konfiguration anstatt Systemnamen schreiben

Anhang E. Beispiele für Netzwerkschnittstellenvorlagen

Dieser Anhang stellt einige Beispiele für Heat-Vorlagen bereit, um eine Netzwerkschnittstellenkonfiguration zu demonstrieren.

E.1. Konfigurieren von Schnittstellen

Individulle Schnittstellen erfordern gegebenenfalls Änderungen. Das folgende Beispiel zeigt, welche Änderungen erforderlich sind um den zweiten NIC mit einem Infrastrukturnetzwerk mit DHCP Adressen zu verbinden und den dritten und vierten NIC für den Bond zu verwenden:
network_config:
  # Add a DHCP infrastructure network to nic2
  -
    type: interface
    name: nic2
    use_dhcp: true
  -
    type: ovs_bridge
    name: br-bond
    members:
      -
        type: ovs_bond
        name: bond1
        ovs_options: {get_param: BondInterfaceOvsOptions}
        members:
          # Modify bond NICs to use nic3 and nic4
          -
            type: interface
            name: nic3
            primary: true
          -
            type: interface
            name: nic4
Die Netzwerkschnittstellen von Hosts innerhalb einer Rolle müssen nicht genau die gleichen sein, wenn nummerierte Schnittstellen (nic1, nic2, etc.) anstelle von benannten Schnittstellen (eth0, eno2, etc.) benutzt werden. Zum Beispiel kann ein Host Schnittstellen haben em1 and em2, während ein anderer eno1 und eno2 hat, aber Sie können auf die NICs beider Hosts als nic1 und nic2 verweisen.
Das nummerierte NIC Schema berücksichtigt nur live-Schnittstellen, d.h. solche, an deren Switch ein Kabel angeschlossen ist. Wenn Sie Hosts mit vier Schnittstellen und Hosts mit sechs Schnittstellen haben, sollten Sie nic1 auf nic4 benutzen und nur vier Kabel an jeden Host anschließen.

E.2. Konfigurieren von Routen und Standardrouten

Es gibt zwei Möglichkeiten, wie die Standardrouten eines Hosts eingestellt sein können. Wenn die Schnittstelle DHCP benutzt und der DHCP Server eine Gateway-Adresse anbietet, benutzt das System eine Standardroute für dieses Gateway. Ansonsten können Sie eine Standardroute auf einer Schnittstelle mit einer statischen IP einrichten.
Obwohl Linux Kernel mehrere Standard Gateways unterstützt, benutzt er nur das mit der niedrigsten Metrik. Wenn mehrere DHCP Schnittstellen vorhanden sind, kann das zu einem unvorhersehbaren Standard Gateway führen. In diesem Fall wird empfohlen defroute=no für Schnittstellen einzustellen, außer für diejenige, die die Standardroute benutzt.
Möchte man beispielsweise eine DHCP-Schnittstelle (nic2) als Standardroute, anstatt der Provisioning Schnittstelle, muss man die Standardroute auf der Provisioning Schnittstelle deaktivieren:
# No default route on the Provisioning network
- type: interface
  name: nic1
  use_dhcp: true
  defroute: no
# Instead use this DHCP infrastructure VLAN as the default route
- type: interface
  name: nic2
  use_dhcp: true
Um eine statische Route auf einer Schnittstelle mit einem statischen IP einzurichten, müssen Sie eine Route zum Subnetz angeben. Zum Beispiel kann man eine Route zum 10.1.2.0/24 Subnetz durch das Gateway bei 172.17.0.1 auf dem internen API-Netzwerk erstellen:
    - type: vlan
      device: bond1
      vlan_id: {get_param: InternalApiNetworkVlanID}
      addresses:
      - ip_netmask: {get_param: InternalApiIpSubnet}
      routes:
      - ip_netmask: 10.1.2.0/24
        next_hop: 172.17.0.1

E.3. Natives VLAN für Floating IPs verwenden

Neutron erwartet Übermittlung der floating IP auf einem getaggten VLAN. Wenn das floating IP Netzwerk das systemeigene VLAN benutzt, erfordert Neutron die floating IPs direkt auf der br-ex Brücke. Der Parametername und sein Abschnitt weichen voneinander ab, je nachdem, ob ein Plan oder eine benutzerdefinierte Heat-Vorlagensammlung verwendet wird um Ihre Overcloud zu erstellen.
Für Plan-basierte Overclouds:
  parameters:
    # Set to "br-ex" when using floating IPs on the native VLAN
    Controller-1::NeutronExternalNetworkBridge: "''"
Für Vorlagen-basierte Overclouds:
  parameter_defaults:
    # Set to "br-ex" when using floating IPs on the native VLAN
    NeutronExternalNetworkBridge: "''"
Der nächste Abschnitt enthält Änderungen an der NIC config um das Externe Netzwerk auf das systemeigene VLAN zu legen. Das Externe Netzwerk kann für floating IPs verwendet werden, zusätzlich zum Horizon Dashboard und Öffentlichen APIs.

E.4. Verwendung des systemeigenen VLANs auf einer Trunk-Schnittstelle

Wenn eine Trunk-Schnittstelle oder Bond ein Netzwerk auf einem systemeigenen VLAN hat, ist die IP-Adresse direkt der Brücke zugewiesen und erstellt keine VLAN-Schnittstelle. Wenn das systemeigene VLAN für das Externe Netzwerk benutzt wird, stellen Sie den NeutronExternalNetworkBridge Parameter auf br-ex anstatt auf '' in der network-environment.yaml.
Wenn zum Beispiel das Externe Netzwerk auf dem systemeigenen VLAN ist, sieht eine verbundene Konfiguration folgendermaßen aus:
network_config:
  - type: ovs_bridge
    name: {get_input: bridge_name}
    addresses:
      - ip_netmask: {get_param: ExternalIpSubnet}
    routes:
      - ip_netmask: 0.0.0.0/0
        next_hop: {get_param: ExternalInterfaceDefaultRoute}
    members:
      - type: ovs_bond
        name: bond1
        ovs_options: {get_param: BondInterfaceOvsOptions}
        members:
          - type: interface
            name: nic3
            primary: true
          - type: interface
            name: nic4

Anmerkung

Entfernen Sie die entsprechende VLAN-Schnittstelle aus der Brücke, wenn Sie die Adressen- (und möglicherweise Routen-) Statements auf die Brücke verschieben. Ändern Sie alle zutreffenden Rollen entsprechend. Da das Externe Netzwerk nur auf den Controllern ist, muss nur die Controller-Vorlage geändert werden. Das Speichernetzwerk ist hingegen allen Rollen angefügt, wenn das Speichernetzwerk also auf dem Standard-VLAN ist, müssen alle Rollen geändert werden.

E.5. Konfigurieren von Jumbo Frames

Die Einstellungen des Maximum Transmission Units (MTU) bestimmen die maximale Datenmenge, die mit einem einzelnen Ethernet Frame übermittelt wird. Die Verwendung eines größeren Wertes bedeutet geringeren Aufwand, da jeder Frame Daten in Form einer Kopfzeile hinzufügt. Der Standardwert ist 1500 und die Verwendung eines höheren Wertes erfordert die Konfiguration des Switchports um Jumbo Frames zu unterstützen. Die meisten Schalter unterstützen ein MTU von mindestens 9000, aber viele sind standardmäßig für 1500 konfiguriert.
Die MTU eines VLANs kann nicht die MTU einer physischen Schnittstelle übersteigen. Stellen Sie sicher, dass Sie den MTU Wert im Bond und/oder in der Schnittstelle einschließen.
Speicher, Speicherverwaltung, Interne API und Mandantennetzwerk profitieren von Jumbo Frames. Im Testlauf war der Durchsatz des Mandantennetzwerks über 300% größer, wenn Jumbo Frames in Verbindung mit VXLAN Tunnel verwendet wurden.

Anmerkung

Es wird empfohlen, dass Provisioning-Schnittstelle, Externe Schnittstelle und jegliche floating-IP Schnittstellen auf der Standard MTU von 1500 belassen werden. Ansonsten treten mit wachsender Wahrscheinlichkeit Verbindungsprobleme auf.
- type: ovs_bond
  name: bond1
  mtu: 9000
  ovs_options: {get_param: BondInterfaceOvsOptions}
  members:
    - type: interface
      name: nic3
      mtu: 9000
      primary: true
    - type: interface
      name: nic4
      mtu: 9000

# The external interface should stay at default
- type: vlan
  device: bond1
  vlan_id: {get_param: ExternalNetworkVlanID}
  addresses:
    - ip_netmask: {get_param: ExternalIpSubnet}
  routes:
    - ip_netmask: 0.0.0.0/0
      next_hop: {get_param: ExternalInterfaceDefaultRoute}

# MTU 9000 for Internal API, Storage, and Storage Management
- type: vlan
  device: bond1
  mtu: 9000
  vlan_id: {get_param: InternalApiNetworkVlanID}
  addresses:
  - ip_netmask: {get_param: InternalApiIpSubnet}

Anhang F. Netzwerkumgebungs-Optionen

Tabelle F.1. Netzwerkumgebungs-Optionen

Parameter
Beschreibung
Beispiel
InternalApiNetCidr
Das Netzwerk und Subnetz für das Interne API-Netzwerk
172.17.0.0/24
StorageNetCidr
Das Netzwerk und Subnetz für das Speichernetzwerk
StorageMgmtNetCidr
Das Netzwerk und Subnetz für das Speicher-Management Netzwerk
TenantNetCidr
Das Netzwerk und Subnetz für das Mandantennetzwerk
ExternalNetCidr
Netzwerk und Subnetz für das Externe Netzwerk
InternalApiAllocationPools
Der Zuweisungspool für das Interne API-Netzwerk in einem Tupelformat
[{'start': '172.17.0.10', 'end': '172.17.0.200'}]
StorageAllocationPools
Der Zuweisungspool für das Speichernetzwerk in einem Tupelformat
StorageMgmtAllocationPools
Der Zuweisungspool für das Speicher-Management Netzwerk in einem Tupelformat
TenantAllocationPools
Der Zuweisungspool für das Mandantennetzwerk in einem Tupelformat
ExternalAllocationPools
Der Zuweisungspool für das Externe Netzwerk in einem Tupelformat
InternalApiNetworkVlanID
Die VLAN-ID für das Interne API-Netzwerk
200
StorageNetworkVlanID
Die VLAN-ID für das Speichernetzwerk
StorageMgmtNetworkVlanID
Die VLAN-ID für das Speicher-Management Netzwerk
TenantNetworkVlanID
Die VLAN-ID für das Mandantennetzwerk
ExternalNetworkVlanID
Die VLAN-ID für das Externe Netzwerk
ExternalInterfaceDefaultRoute
Die Gateway-IP-Adresse für das Externe Netzwerk
10.1.2.1
BondInterfaceOvsOptions
Die Optionen für Bonding-Schnittstellen
bond_mode=balance-tcp lacp=active other-config:lacp-fallback-ab=true"

Anhang G. Bereitstellungsparameter

Die folgende Tabelle listet die zusätzlichen Parameter bei Verwendung des openstack overcloud deploy Befehls auf.

Tabelle G.1. Bereitstellungsparameter

Parameter
Beschreibung
Beispiel
--plan [PLAN]
Name oder UUID des bereitzustellenden Tuskarplans
619ecc30-5a5d-4df4-9967-502c77ed90f6
--templates [TEMPLATES]
Das Verzeichnis mit den bereitzustellenden Heat-Tabellen
~/templates/my-overcloud
-t [TIMEOUT], --timeout [TIMEOUT]
Bereitstellungs-Timeout in Minuten
240
--control-scale [CONTROL_SCALE]
Anzahl der Controller-Knoten zur Horizontalskalierung
3
--compute-scale [COMPUTE_SCALE]
Anzahl der Compute-Knoten zur Horizontalskalierung
3
--ceph-storage-scale [CEPH_STORAGE_SCALE]
Anzahl der Ceph-Storage-Knoten zur Horizontalskalierung
3
--block-storage-scale [BLOCK_STORAGE_SCALE]
Anzahl der Cinder-Knoten zur Horizontalskalierung
3
--swift-storage-scale [SWIFT_STORAGE_SCALE]
Anzahl der Swift-Knoten zur Horizontalskalierung
3
--control-flavor [CONTROL_FLAVOR]
Für Controller-Knoten zu verwendende Variante
Kontrolle
--compute-flavor [COMPUTE_FLAVOR]
Für Compute-Knoten zu verwendende Variante
Compute
--ceph-storage-flavor [CEPH_STORAGE_FLAVOR]
Für Ceph-Storage-Knoten zu verwendende Variante
ceph-storage
--block-storage-flavor [BLOCK_STORAGE_FLAVOR]
Für Cinder-Knoten zu verwendende Variante
cinder-storage
--swift-storage-flavor [SWIFT_STORAGE_FLAVOR]
Für Swift-Knoten zu verwendende Variante
swift-storage
--neutron-flat-networks [NEUTRON_FLAT_NETWORKS]
Bestimmt die in Neutron-Plugins zu konfigurierenden flachen Netzwerke. Setzt Standardwerte auf "datacentre" um Erstellung eines externen Netzwerks zu genehmigen
datacentre
--neutron-physical-bridge [NEUTRON_PHYSICAL_BRIDGE]
Auf jedem Hypervisor herzustellende Open vSwitch Brücke. Dies setzt Standard auf "br-ex". Das muss normalerweise nicht geändert werden
br-ex
--neutron-bridge-mappings [NEUTRON_BRIDGE_MAPPINGS]
Zu verwendendes logisch-zu-physisch Brücken-Mapping. Standardeinstellungen zum Mapping der externen Brücke auf Hosts (br-ex) zu einem physischen Namen (datacentre). Dies wird für das standardmäßige Floating-Netzwerk benutzt
datacentre:br-ex
--neutron-public-interface [NEUTRON_PUBLIC_INTERFACE]
Definiert die Schnittstelle als Brücke auf br-ex für Netzwerk-Knoten
nic1, eth0
--hypervisor-neutron-public-interface [HYPERVISOR_NEUTRON_PUBLIC_INTERFACE]
Welche Schnittstelle bei jedem Hypervisor zur Brücke hinzugefügt werden soll
nic1, eth0
--neutron-network-type [NEUTRON_NETWORK_TYPE]
Der Mandantennetzwerktyp für Neutron
gre or vxlan
--neutron-tunnel-types [NEUTRON_TUNNEL_TYPES]
Die Tunneltypen für das Neutron-Mandantennetzwerk. Benutzen Sie einen kommagetrennten String um mehrere Werte zu anzugeben
'vxlan' 'gre,vxlan'
--neutron-tunnel-id-ranges [NEUTRON_TUNNEL_ID_RANGES]
Für Mandantennetzwerkzuordnung verfügbar zu machende Bereiche von GRE Tunnel-IDs
1:1000
--neutron-vni-ranges [NEUTRON_VNI_RANGES]
Für Mandantennetzwerkzuordnung verfügbar zu machende Bereiche von VXLAN VNI IDs
1:1000
--neutron-disable-tunneling
Deaktiviert Tunneling, falls Sie ein VLAN segmentiertes Netzwerk oder ein flaches Netzwerk mit Neutron benutzen möchten
--neutron-network-vlan-ranges [NEUTRON_NETWORK_VLAN_RANGES]
Zu unterstützender Neutron ML2 und Open vSwitch VLAN Mappingbereich. Setzt Standardwerte auf Zulassung jedes VLANs im 'datacentre' physischen Netzwerk
datacentre:1:1000
--neutron-mechanism-drivers [NEUTRON_MECHANISM_DRIVERS]
Die Mechanismus-Driver für das Neutron-Mandantennetzwerk. Setzt Standardwerte auf "openvswitch". Benutzen Sie einen kommagetrennten String um mehrere Werte anzugeben
'openvswitch,l2_population'
--libvirt-type [LIBVIRT_TYPE]
Für Hypervisoren zu verwendender Virtualisierungstyp
kvm,qemu
--ntp-server [NTP_SERVER]
Zur Zeitsynchronisierung zu verwendender Network Time Protocol (NTP) Server
pool.ntp.org
--cinder-lvm
Benutzen Sie den LVM iSCSI Driver für Cinder storage
--tripleo-root [TRIPLEO_ROOT]
Das Verzeichnis für die Konfigurationsdateien des Directors. Lassen Sie diese als Standardeinstellung
--nodes-json [NODES_JSON]
Die für Knotenregistrierung verwendete Original JSON-Datei. Der Director bietet nach Erstellung Ihrer Overcloud einige Änderungen für diese Datei an. Setzt Standartwerte auf instackenv.json
--no-proxy [NO_PROXY]
Bestimmt benutzerdefinierte Werte für die Umgebungsvariable no_proxy, die bestimmte Domänenerweiterungen von der Proxy-Kommunikation ausschließt
-O [OUTPUT DIR], --output-dir [OUTPUT DIR]
Verzeichnis, in das Tuskar-Vorlagendateien eingetragen werden. Dieses wird erstellt, wenn es nicht vorhanden ist. Wenn es nicht bereitsteht, wird ein temporäres Verzeichnis benutzt
~/templates/plan-templates
-e [EXTRA HEAT TEMPLATE], --extra-template [EXTRA HEAT TEMPLATE]
Zusätzliche Umgebungsdateien zur Übergabe an die Overcloud-Bereitstellung. Kann mehr als einmal angegeben werden
-e ~/templates/my-config.yaml
--rhel-reg
Overcloud-Knoten im Kundenportal oder Satellite 6 registrieren
--reg-method
Für die Overcloud-Knoten zu verwendende Registrierungsmethode
satellite für Satellite 6,portal für Kundenportal
--reg-org [REG_ORG]
Für Registrierung zu verwendende Organisation
--reg-force
Das System registrieren, auch wenn es bereits registriert ist
--reg-sat-url [REG_SAT_URL]
Satellite 6 Server um Overcloud-Knoten zu registrieren
--reg-activation-key [REG_ACTIVATION_KEY]
Für Registrierung zu verwendender Aktivierungsschlüssel

Anhang H. Versionsgeschichte

Versionsgeschichte
Version 7.0-2.1Fri Sep 25 2015Red Hat Localization Services
Übersetzungsdateien synchronisiert mit XML-Quellen 7.0-2
Version 7.0-2Wed Aug 5 2015Dan Macpherson
Erstellen mit neuer Sortierungs-Reihenfolge
Version 7.0-1Wed May 20 2015Dan Macpherson
Erster Entwurf der Dokumentation

Rechtlicher Hinweis

Copyright © 2015 Red Hat.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.