Installation und Verwendung des Directors
End-to-End Szenario zur Erstellung einer OpenStack Cloud mit dem Red Hat Enterprise Linux OpenStack Platform Director
Zusammenfassung
Kapitel 1. Einführung
Abbildung 1.1. Grundsätzliches Layout von Undercloud und Overcloud
1.1. Undercloud
- 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.
- 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
- 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
- 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.
Anmerkung
1.4. Ceph-Storage
Kapitel 2. Anforderungen
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
- 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
- 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
- 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.
- 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
2.4.1. Compute-Knotenanforderungen
- 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 RAMZusä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
- 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
- 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
3.1. Erstellen eines Benutzers für die Director-Installation
stack
anzulegen und ein Passwort einzurichten:
[root@director ~]# useradd stack [root@director ~]# passwd stack # specify a password
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
stack
Benutzer wechseln:
[root@director ~]# su - stack [stack@director ~]$
stack
Benutzer fortsetzen.
3.2. Erstellen von Verzeichnissen für Vorlagen und Images
$ mkdir ~/images $ mkdir ~/templates
3.3. IP-Weiterleitung auf dem Director-Host aktivieren
/etc/sysctl.conf
Datei und fügen Sie folgende Zeile hinzu:
net.ipv4.ip_forward = 1
$ sudo sysctl -p /etc/sysctl.conf
3.4. Bestimmen des Hostnamens für das System
$ hostname # Checks the base hostname $ hostname -f # Checks the long hostname (FQDN)
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
/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
Prozedur 3.1. Abonnieren der Erforderlichen Channels über den Subscription Manager
- Registrieren Sie Ihr System im Content Delivery Network, indem Sie Ihren Benutzernamen und Ihr Passwort für das Kundenpoprtal eingeben:
$ sudo subscription-manager register
- Suchen Sie den Berechtigungspool für den Red Hat Enterprise Linux OpenStack Platform Director.
$ sudo subscription-manager list --available --all
- 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
- 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. - Aktualisieren Sie Ihr System um sicherzustellen, dass Sie über die neusten Basissystem-Pakete verfügen:
$ sudo yum update -y
3.6. Installieren der Director-Pakete
[stack@director ~]$ sudo yum install -y python-rdomanager-oscplugin
3.7. Konfiguration des Directors
stack
Home-Verzeichnis des Benutzers gespeichert als undercloud.conf
stack
Home-Verzeichnis des Benutzers:
$ cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
- image_path
- Definiert den Pfad zu den für Bereitstellungsrollen benutzten Images. Setzen Sie den Wert auf den
stack
Benutzerimages
:/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 eineundercloud.pem
zur Verwendung mit derundercloud_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 einesip 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 NICeth0
und der Provisioning NICeth1
, welche momentan nicht konfiguriert sind. In diesem Fall stellen Sielocal_interface
aufeth1
. Das Konfigurationsskript fügt diese Schnittstelle einer benutzerdefinierten, mit demdiscovery_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 Standardeinstellungbr-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 vondhcp_start
unddhcp_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 auftrue
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.
$ openstack undercloud install
undercloud.conf
anzupassen. Die Ausführung dieses Skripts dauert einige Minuten.
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.
stack
Benutzer zu initialisieren, führen Sie folgenden Befehl aus:
$ source ~/stackrc
3.8. Abrufen von Images für die Overcloud-Knoten
- 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.
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
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.
$ 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 | +--------------------------------------+------------------------+
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
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]
$ neutron subnet-show [subnet-uuid] +-------------------+-----------------------------------------------+ | Field | Value | +-------------------+-----------------------------------------------+ | ... | | | dns_nameservers | 8.8.8.8 | | ... | | +-------------------+-----------------------------------------------+
3.10. Fertigstellen der Undercloud-Konfiguration
Kapitel 4. Planung Ihrer Overcloud
4.1. Planen der Knotenbereitstellungsrollen
- 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.
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
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
|
- Internes API
- Speicher
- Speicherverwaltung
- Mandantennetzwerk
- Extern
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.
Abbildung 4.1. Beispiel für VLAN-Topologie, die verbundene Schnittstellen benutzt
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
- 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 zweckdienlichnova 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-ImageformatRAW
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
5.1. Heat-Vorlagen
- 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.
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 ] }
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
- 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.
resource_registry: OS::Nova::Server::MyServer: myserver.yaml parameter_defaults: NetworkName: my_network parameters: MyIP: 192.168.0.1
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
$ openstack management plan list
overcloud
, welcher Ihre Overcloud Konfiguration ist. Um weitere Details im Overcloud-Plan einzusehen, führen Sie folgenden Befehl aus:
$ openstack management plan show [UUID]
stack
Benutzer templates
Verzeichnis herunterzuladen:
$ mkdir ~/templates/overcloud-plan $ openstack management plan download [UUID] -O ~/templates/overcloud-plan/
plan.yaml
) und eine Umgebungsdatei (environment.yaml
). Die Vorlagensammlung enthält auch verschiedene Verzeichnisse und Vorlagendateien, die als Ressourcen in der Umgebungsdatei registriert sind.
5.4. Standardvorlagen des Directors
/usr/share/openstack-tripleo-heat-templates
.
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. Derovercloud-resource-registry-puppet.yaml
basiert auf dieser Datei. Diese Datei wird für die benutzerdefinierte Konfiguration Ihrer Umgebung verwendet.
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
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
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
Arbeitsablauf
- Registrieren der leeren Knoten im Web-UI des Directors.
- Hardware aller Knoten prüfen.
- Standardvariante für die Knoten erstellen.
- Varianten und Images den Bereitstellungsrollen zuweisen.
- Overcloud-Umgebung mit Standardplan des Directors erstellen.
Anforderungen
- Director-Knoten, erstellt in Abschnitt 3.1, »Erstellen eines Benutzers für die Director-Installation «
- 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 derlibvirt
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
Prozedur 6.1. Erstellen von virtuellen Maschinen im Overcloud-Host
- Zugriff auf Virtual Machine Manager von Ihrem Overcloud-Host.
- 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. - Beide virtuellen Maschinen herunterfahren.
- 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
undbb:bb:bb:bb:bb:bb
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
- 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
). - Kopieren Sie den Inhalt des öffentlichen Schlüssels in die
/root/.ssh/authorized_keys
Datei des Overcloud-Hostroot
Benutzers:[stack@director ~]$ ssh-copy-id -i virtkey root@192.0.2.2
- Speichern Sie den privaten Schlüssel (
virtkey
) für später, wenn die Knoten registriert werden.
6.1.2. Zugriff auf den Director
http://192.0.2.1
. Die Anmeldeseite für den Director wird daraufhin angezeigt:
Abbildung 6.1. Der Anmeldebildschirm des OpenStack Platform-Directors
stack
Benutzer auf dem Director-Host aus:
[stack@director ~]$ sudo hiera admin_password 3f2f4295a5eb6ad967b832d35e048852
admin
Benutzer um sich in das UI des Directors einzuloggen.
6.1.3. Registrieren der Knoten
Prozedur 6.3. Registrieren der Knoten
- Melden Sie sich als
admin
Benutzer im Director an. - Gehen Sie zu Nodes im Hauptmenü.
- Klicken Sie auf die + Schaltfläche. Es erscheint diese Anzeige zur Knoten-Registrierung.
Abbildung 6.2. Bildschirm zur Knoten-Registrierung
- 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
- Klicken Sie auf Register Nodes.
$ openstack baremetal introspection bulk start
6.1.4. Generieren der Hardware-Profile
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
- Gehen Sie zu Flavors im Hauptmenü.
- Klicken Sie auf die + Schaltfläche. Es erscheint diese Anzeige zur Variantenerstellung.
Abbildung 6.3. Bildschirm zur Variantenerstellung
- Geben Sie folgende Details für Ihre beiden Knoten ein:
- Name:
baremetal
- CPUs: 1
- RAM (MB): 6144
- Disk GB: 40 GB
- Architecture: x86_64
- Klicken Sie auf Create Flavor.
- 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
6.1.5. Zuweisen der Images zu den Bereitstellungsrollen
baremetal
Variante zu. Jede Bereitstellungsrolle benötigt jedoch immer noch eine Imagezuordnung.
Prozedur 6.5. Zuweisen der Images zu den Bereitstellungsrollen
- Gehen Sie zu Deployment Roles im Hauptmenü.
- Klicken Sie auf die Edit Schaltfläche für die Compute Bereitstellungsrolle. Dies zeigt Ihnen die Bearbeitungsanzeige für Bereitstellungsrollen an.
Abbildung 6.4. Bearbeiten der Bereitstellungsrollen
- Stellen Sie sicher, dass
baremetal
für Flavor undovercloud-full
für Image gesetzt ist. Klicken Sie Save um Ihre Änderungen zu speichern. - Wiederholen Sie diesen Vorgang für die übrigen Bereitstellungsrollen.
6.1.6. Erstellen der Test-Overcloud
Prozedur 6.6. Erstellen der Overcloud
- Gehen Sie zu Overview im Hauptmenü.
- Ü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.Abbildung 6.5. Overcloud-Plan
- Wenn Sie bereit sind den Erstellungsprozess zu starten, klicken Sie auf die Verify and Deploy Schaltfläche.
Abbildung 6.6. Prüfen und Bereitstellen
6.1.7. Zugriff auf die Test-Overcloud
6.1.8. Abschluss der Test-Overcloud
6.2. Szenario 2: Erstellen einer Einfachen Overcloud mithilfe des CLI
Arbeitsablauf
- Knoten-Definitionsvorlage erstellen und leere Knoten im Director registrieren
- Hardware aller Knoten überprüfen.
- Knoten manuell in Rollen taggen.
- Varianten erstellen und in Rollen taggen
- Heat-Vorlagen erstellen um das Externe Netzwerk zu isolieren.
- 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
KnotennameIP-AdresseMAC-AdresseIPMI IP-AdresseDirector192.0.2.1aa:aa:aa:aa:aa:aaControllerDHCP definiertbb:bb:bb:bb:bb:bb192.0.2.205ComputeDHCP definiertcc:cc:cc:cc:cc:cc192.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
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" } ] }
- 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
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
$ openstack baremetal configure boot
$ openstack baremetal list
6.2.2. Prüfen der Knoten-Hardware
$ openstack baremetal introspection bulk start
Wichtig
6.2.3. Manuelles Taggen der Knoten
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'
profile:compute
und profile:control
Optionen taggt die zwei Knoten in die jeweiligen Profile.
boot_option:local
Parameter, der den Startmodus für jeden Knoten definiert.
6.2.4. Erstellen von Varianten für das Einfache Szenario
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 control $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute
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
- 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.
6.2.5.1. Erstellen von benutzerdefinierten Schnittstellenvorlagen
/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.
stack
Home-Verzeichnis des Benutzers als nic-configs
.
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans ~/templates/nic-configs
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:
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
undvlan
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}
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}
nic2
) und weist die Adressen und Routen des Externen Netzwerks der neuen Schnittstelle zu.
get_param
Funktion verwenden. Man definiert diese in einer Umgebungsdatei, die man speziell für Ihre Netzwerke erstellt.
Wichtig
- type: interface name: nic1 use_dhcp: true
6.2.5.2. Erstellen der Netzwerkumgebungs-Vorlage einer Einfachen Overcloud
/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
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.
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
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.
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.
Wichtig
6.2.6. Erstellen der Einfachen Overcloud
Prozedur 6.7. Erstellen der Overcloud
- 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. - 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
$ openstack help overcloud deploy
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
heat stack-list --show-nested
Befehl zeigt die aktuelle Phase der Overcloud-Erstellung an.
Wichtig
-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
overcloudrc
im stack
Home-Verzeichnis Ihres Benutzers. Um diese Datei zu benutzen führen Sie folgenden Befehl aus:
$ source ~/overcloudrc
$ source ~/stackrc
6.2.8. Fertigstellen der Einfachen Overcloud
6.3. Szenario 3: Erstellen einer Erweiterten Overcloud mit Ceph Knoten unter Verwendung des CLI
- Drei Controller-Knoten mit Hochverfügbarkeit
- Drei Compute-Knoten
- Drei Red Hat Ceph-Storage-Knoten in einem Cluster
Arbeitsablauf
- Erstellen Sie eine Knoten-Definitionstabelle und registrieren Sie leere Knoten im Director.
- Überprüfen Sie die Hardware und bewerten Sie alle Knoten.
- Benutzen Sie Automated Health Check (AHC) Tools um Richtlinien zu bestimmen, die automatisch die Knoten in Rollen taggen.
- Erstellen Sie Varianten und taggen Sie diese in Rollen.
- Erstellen Sie eine Kopie der Standard Heat-Vorlagen des Directors.
- Erstellen Sie Heat-Vorlagen um alle Netzwerke zu isolieren.
- Erstellen Sie die Overcloud-Umgebung unter Verwendung der Standard Heat-Vorlage und der zusätzlichen Netzwerkisolations-Vorlagen.
- 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
KnotennameIP-AdresseMAC-AdresseIPMI IP-AdresseDirector192.0.2.1aa:aa:aa:aa:aa:aaController 1DHCP definiertb1:b1:b1:b1:b1:b1192.0.2.205Controller 2DHCP definiertb2:b2:b2:b2:b2:b2192.0.2.206Controller 3DHCP definiertb3:b3:b3:b3:b3:b3192.0.2.207Compute 1DHCP definiertc1:c1:c1:c1:c1:c1192.0.2.208Compute 2DHCP definiertc2:c2:c2:c2:c2:c2192.0.2.209Compute 3DHCP definiertc3:c3:c3:c3:c3:c3192.0.2.210Ceph 1DHCP definiertd1:d1:d1:d1:d1:d1192.0.2.211Ceph 2DHCP definiertd2:d2:d2:d2:d2:d2192.0.2.212Ceph 3DHCP definiertd3:d3:d3:d3:d3:d3192.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
NetzwerktypSubnetzVLANInterne API172.16.0.0/24201Mandant172.17.0.0/24202Speicher172.18.0.0/24203Speicherverwaltung172.19.0.0/24204Externe / Floating IP10.1.1.0/24100
6.3.1. Registrieren der Knoten für die Erweiterte Overcloud
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" } ] }
- 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
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
$ openstack baremetal configure boot
$ openstack baremetal list
6.3.2. Überprüfen der Knoten-Hardware
Wichtig
discovery_runbench
Option auf wahr gestellt ist, wenn der Director erstmals konfiguriert wird (vgl. Abschnitt 3.7, »Konfiguration des Directors«).
/httpboot/discoverd.ipxe
und stellen Sie den RUNBENCH
Kernel Parameter auf 1
.
$ openstack baremetal introspection bulk start
Wichtig
6.3.3. Automatisches Knoten-Tagging mit Automated Health Check (AHC) Tools
$ sudo yum install -y ahc-tools
ahc-report
, was die Berichte aus den Benchmark Tests abfragt.ahc-match
, was Knoten je nach Richtlinien in bestimmte Rollen taggt.
Wichtig
/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
ahc-report
Skript produziert verschiedene Berichte über Ihre Knoten. Um einen vollständigen Bericht anzuzeigen, benutzen Sie die --full
Option.
$ ahc-report --full
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') ... ]
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 ...
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.
ahc-match
Befehl den Knoten eine bestimmte Rolle zuweisen.
6.3.3.2. ahc-match
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.
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
state
Datei zeigt die Anzahl von Knoten für jede Rolle an. Die Standard Konfigurationsdatei zeigt:
[('control', '1'), ('compute', '*')]
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', '*')]
Richtliniendateien
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)'), ]
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()
undand()
übernehmen zwei Parameter undnot()
einen Parameter.
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)') ]
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
ahc-match
Tool aus um Ihre Knoten zuzuweisen.
$ sudo ahc-match
/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 |
profile
Tag von jedem Knoten um ihn den Rollen und Varianten mit demselben Tag anzupassen.
6.3.4. Erstellen von Hardware-Profilen
$ 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
$ 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
/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
openstack overcloud deploy
benutzen wir die --templates
Option um Ihr lokales Vorlagenverzeichnis anzugeben.
Anmerkung
/usr/share/openstack-tripleo-heat-templates
), wenn Sie die --templates
Option ohne ein Verzeichnis angeben.
6.3.6. Konfiguration von Ceph-Storage
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.
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
puppet/hieradata/ceph.yaml
Folgendes enthalten:
ceph::profile::params::osds: '/dev/sdc': journal: '/dev/sdb1' '/dev/sdd': journal: '/dev/sdb2'
puppet/hieradata/ceph.yaml
um Ihrem Speicherbedarf einschließlich Journalgröße und Poolstandard zu entsprechen.
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
- Netzwerk 1 - Provisioning
- Netzwerk 2 - Interne API
- Netzwerk 3 - Mandantennetzwerke
- Netzwerk 4 - Speicher
- Netzwerk 5 - Speicherverwaltung
- Netzwerk 6 - Extern
6.3.7.1. Erstellung von benutzerdefinierten Schnittstellenvorlagen
/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.
stack
Home-Verzeichnis des Benutzers als nic-configs
.
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans ~/templates/nic-configs
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:
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
undvlan
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}
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}
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.
get_param
Funktion verwenden. Definieren Sie diese in einer Umgebungsdatei, die Sie speziell für Ihre Netzwerke anlegen.
Wichtig
- type: interface name: nic1 use_dhcp: true
ovs_bridge
Geräten entfernt wurden.
6.3.7.2. Erstellen einer Netzwerkumgebungsdatei einer Erweiterten Overcloud
/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"
resource_registry
Abschnitt enthält Links zu den Netzwerkschnittstellenvorlagen für jede Knotenrolle.
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
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.
Wichtig
6.3.7.3. Zuweisung der OpenStack Dienste zu isolierten Netzwerken
/home/stack/templates/network-environment.yaml
)angeben. Der ServiceNetMap
Parameter bestimmt die Netzwerktypen für jeden Dienst.
... 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
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
$ 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
--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
$ openstack help overcloud deploy
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
heat stack-list --show-nested
Befehl zeigt die aktuelle Phase der Overcloud-Erstellung an.
Wichtig
-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
overcloudrc
in Ihrem stack
Benutzer Home-Verzeichnis. Um diese Datei zu benutzen, führen Sie folgenden Befehl aus:
$ source ~/overcloudrc
$ source ~/stackrc
6.3.10. Fencing der Controller-Knoten
Anmerkung
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.
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
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
$ sudo pcs stonith describe fence_ipmilan
stonith
Geräts in Pacemaker für jeden Knoten. Benutzen Sie folgenden Befehl für das Cluster:
$ 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
$ 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
$ 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
$ sudo pcs stonith show
$ sudo pcs stonith show [stonith-name]
stonith
Eigenschaft auf true
stellen:
$ sudo pcs property set stonith-enabled=true
$ sudo pcs property show
6.3.11. Abschließen der Erweiterten Overcloud
Kapitel 7. Aufgabenausführung nach Erstellung der Overcloud
7.1. Erstellung des Externen Netzwerks der Overcloud
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
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
heat_stack_owner
Rolle in Ihrer Overcloud existiert:
$ source ~/overcloudrc $ openstack role list +----------------------------------+------------------+ | ID | Name | +----------------------------------+------------------+ | 6226a517204846d1a26d15aae1af208f | swiftoperator | | 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner | +----------------------------------+------------------+
$ keystone role-create --name heat_stack_owner
$ openstack overcloud validate --overcloud-auth-url $OS_AUTH_URL --overcloud-admin-password $OS_PASSWORD
$OS_AUTH_URL
und $OS_PASSWORD
Umgebungsvariablen benutzen in overcloudrc
festgelegte Werte.
Anmerkung
--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
Skalierung mit dem Overcloud-Plan
overcloud
Plan im Director. Identifizieren Sie zuerst den UUID des Plans:
$ openstack management plan list
$ openstack management role list
$ openstack management plan set [UUID] -S Compute-1=5
overcloud
Plan. Nach Aktualisierung des Plans führen Sie erneut den overcloud deploy
Befehl aus:
$ openstack overcloud deploy --plan "[UUID]" -e [ENVIRONMENT_FILE]
Wichtig
-e
oder --environment-file
Option um unerwünschte Änderungen der Overcloud zu vermeiden.
Skalieren mit Heat-Vorlagen
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]
Wichtig
-e
oder --environment-file
Option um unerwünschte Änderungen der Overcloud zu vermeiden.
7.4. Entfernen von Knoten aus der Overcloud
Wichtig
Entfernen von Knoten mit dem Overcloud Plan
overcloud
Plan und Stack im Director. Identifizieren Sie zuerst den UUID des Plans:
$ openstack management plan list
$ heat stack-list
$ nova list
$ openstack overcloud node delete --stack [STACK] --plan [PLAN_UUID] -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]
Wichtig
-e
oder --environment-file
Option um unerwünschte Änderungen der Overcloud zu vermeiden.
Entfernen von Knoten mit Heat-Vorlagen
overcloud
Stacks im Director unter Verwendung von lokalen Vorlagendateien. Identifizieren Sie zuerst den UUID des Overcloud-Stacks:
$ heat stack-list
$ nova list
$ openstack overcloud node delete --stack [STACK] --templates ~/my-overcloud -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]
Wichtig
-e
oder --environment-file
Option um unerwünschte Änderungen der Overcloud zu vermeiden.
7.5. Ersetzen von Compute-Knoten
- Arbeitsauslastung aus dem bestehenden Compute-Knoten migrieren
- Bestehenden Compute-Knoten herunterfahren
- Compute-Knoten aus dem Overcloud entfernen
- Overcloud mit neuem Compute-Knoten skalieren
Prozedur 7.1. Einrichten von Schlüsseln
nova
Benutzer während dem Migrationsprozess Zugriff hat. Mit folgendem Prozess können Sie für jeden Compute-Knoten ein SSH-Schlüsselpaar einrichten.
- SSH-Schlüssel aktivieren:
$ ssh-keygen -t rsa -f nova_id_rsa
- Bei jedem Compute-Knoten den SSH-Schlüssel ins
nova
Home-Verzeichnis des Benutzers kopieren. - 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
- Beziehen Sie
overcloudrc
aus dem Director und rufen Sie eine Liste der aktuellen Nova Dienste ab:$ source ~stack/overcloudrc $ nova service-list
- 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. - Prozess zur Migration der VMs aus dem Knoten starten:
# nova host-servers-migrate [service-id]
- Der aktuelle Status des Migrationsprozesses kann mit folgendem Befehl abgefragt werden:
# nova migration-list
- 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]
- 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
- Folgen Sie dem entsprechenden Prozess von Abschnitt 7.4, »Entfernen von Knoten aus der Overcloud«.
Prozedur 7.4. Skalieren der Overcloud mit einem neuen Compute-Knoten
- Folgen Sie dem entsprechenden Prozess von Abschnitt 7.3, »Skalierung der Overcloud«.
7.6. Importieren von Virtuellen Maschinen in die Overcloud
$ nova image-create instance_name image_name $ glance image-download image_name --file exported_vm.qcow2
$ 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
7.7. Aktualisieren von Director-Paketen und Images
yum
:
$ sudo yum update
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
- Entfernen Sie bestehende Images aus dem Director.
$ openstack image list $ openstack image delete [IMAGE-UUID] [IMAGE-UUID] [IMAGE-UUID] [IMAGE-UUID] [IMAGE-UUID]
- Importieren Sie die neusten Images in den Director.
$ cd ~/images $ openstack overcloud image upload $ openstack baremetal configure boot
Warnung
Die Ausführung vonopenstack baremetal configure boot
entfernt alle Profilinformationen und Bootoptionen aus dencapabilities
Eigenschaften aller Knoten. Diese Information muss für jeden Knoten ersetzt werden. Weitere Informationen finden Sie unter BZ#1241199.
7.8. Aktualisieren von Overcloud-Paketen
openstack overcloud update
im Director Updates durchzuführen.
-i
Option bietet jedoch einen interaktiven Modus, der bei jedem Breakpoint Bestätigung erfordert.
Paket-Aktualisierungen bei mit einem Plan erstellten Overclouds
overcloud
Plans. Identifizieren Sie zuerst den UUID des Plans:
$ openstack management plan list
$ openstack overcloud update stack --plan [PLAN_UUID] -e [ENVIRONMENT_FILE] -i overcloud
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
-e
oder --environment-file
Option um unerwünschte Änderungen der Overcloud zu vermeiden.
Aktualisieren von Paketen bei mit Heat-Vorlagensammlung erstellten Overclouds
$ openstack overcloud update stack --templates [TEMPLATES_DIR] -e [ENVIRONMENT_FILE] -i overcloud
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
-e
oder --environment-file
Option um unerwünschte Änderungen der Overcloud zu vermeiden.
7.9. Entfernen der Overcloud
Prozedur 7.6. Entfernen der Overcloud
- Löschen einer vorhandenen Overcloud:
$ heat stack-delete overcloud
- Löschen der Overcloud bestätigen:
$ heat stack-list
Der Löschvorgang kann ein paar Minuten dauern.
Kapitel 8. Erstellen benutzerdefinierter Konfigurationen
8.1. Konfiguration beim Erststart
cloud-init
, was man unter Verwendung des OS::TripleO::NodeUserData
Ressourcentyps abrufen kann.
/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}
/home/stack/templates/firstboot.yaml
), die Ihre Heat-Vorlagen als OS::TripleO::NodeUserData
Ressourcentyp registriert.
resource_registry: OS::TripleO::NodeUserData: ~/templates/nameserver.yaml
$ openstack overcloud deploy --templates -e ~/templates/firstboot.yaml
-e
wendet die Umgebungsdatei auf den Overcloud-Stack an.
8.2. Konfiguration nach Erstellung der Overcloud
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.
/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
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.
/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
$ openstack overcloud deploy --templates -e ~/templates/post_config.yaml
8.3. Änderung von Puppet-Konfigurationsdaten
puppet/hieradata
. Das bietet Ihnen die Möglichkeit, die ursprünglichen Konfigurations-Parameter zu ändern, die auf Overcloud-Knoten übertragen wurden.
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
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
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}
/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
.
/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
$ openstack overcloud deploy --templates -e ~/templates/custom_puppet_config.yaml
motd.pp
auf alle Knoten in der Overcloud an.
Kapitel 9. Problembehandlung bei Problemen mit dem Director
- 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
undopenstack-ironic-conductor
. Ebenso verwendetironic-discoverd
zwei Einheiten:openstack-ironic-discoverd
undopenstack-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
ironic
um Probleme mit den angegebenen Knotendaten zu beheben. Hier ein paar Beispiele:
Prozedur 9.1. Reparieren einer fehlerhaften MAC-Adresse
- Zugewiesenen Port-UUID ermitteln
$ ironic node-port-list [NODE UUID]
- 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
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.
Fehler beim Start von Knoten-Introspektion
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
$ ironic node-set-provision-state [NODE UUID] provide
Anhalten des Discovery-Prozesses
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.
Prozedur 9.3. Anhalten des Discovery-Prozesses
- Ändern Sie den Energiezustand jedes Knotens auf Aus:
$ ironic node-set-power-state [NODE UUID] off
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
- Orchestrierung (Heat und Nova Dienste)
- Bare-Metal Provisioning (Ironic Dienst)
- Konfiguration nach Bereitstellung (Puppet)
9.3.1. Orchestrierung
$ heat stack-list +-----------------------+------------+--------------------+----------------------+ | id | stack_name | stack_status | creation_time | +-----------------------+------------+--------------------+----------------------+ | 7e88af95-535c-4a55... | overcloud | CREATE_FAILED | 2015-04-06T17:57:16Z | +-----------------------+------------+--------------------+----------------------+
openstack overcloud deploy
Fehlermeldungen angezeigt werden.
9.3.2. Bare-Metal Provisioning
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 | +----------+------+---------------+-------------+-----------------+-------------+
- Ü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 alspower 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
oderdeploy 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 demlast_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 alspower on
angezeigt wird, stellen Sie eine Verbindung zur virtuellen Konsole des fehlerhaften Knotens her und überprüfen Sie die Ausgabe.
9.3.3. Konfiguration nach Bereitstellung
Prozedur 9.4. Erkennen von Konfigurationsproblemen nach der Bereitstellung
- 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 mitCREATE_FAILED
. - Fehlerhafte Ressource anzeigen:
$ heat resource-show overcloud [FAILED RESOURCE]
Suchen Sie nach Informationen imresource_status_reason
Feld, die Ihnen bei der Diagnose helfen. - Benutzen Sie den
nova
Befehl um die IP-Adressen der Overcloud-Knoten sehen zu können.$ nova list
Loggen Sie sich alsheat-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. Derheat-admin
Benutzer hat Sudo Zugriff.$ ssh heat-admin@192.0.2.14
- Überprüfen Sie den
os-collect-config
Log auf einen möglichen Grund für den Fehler.$ sudo journalctl -u os-collect-config
- 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 Sienova
um den Fehler in diesem Fall einsehen zu können.$ nova list $ nova show [SERVER ID]
Der häufigste Fehler wird mit der FehlermeldungNo 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/*
- 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"
/var/log/nova/nova-conductor.log
folgende Fehler:
NoValidHost: No valid host was found. There are not enough hosts available.
- 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 dasproperties
JSON-Feld gültige Werte für die Schlüsselcpus
,cpu_arch
,memory_mb
undlocal_gb
hat. - Ü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]
- Überprüfen Sie, dass der Zustand einer ausreichenden Anzahl von Knoten
available
ist, entsprechendironic node-list
. Ist der Zustand der Knotenmanageable
, bedeutet dies normalerweise, dass die Introspektion fehlgeschlagen ist. - Ü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
- 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 improperties
Feld fürironic node-show
. Ein Knoten, der für die Compute-Rolle getagged ist, sollte zum Beispielprofile:compute
enthalten. - 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
Freigegebene Bibliotheken
- Datenträgerimage-Builder
diskimage-builder
ist ein Tool zur Image-Erzeugung.- dib-utils
dib-utils
enthält Tools, diediskimage-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 vondiskimage-builder
Stilelementen für die Installation verschiedener Software-Komponenten.
Installer
- instack
instack
führtdiskimage-builder
Stilelemente auf dem aktuellen System aus. Das ermöglicht einem aktuell laufenden System ein Element auf dieselbe Weise anzuwenden, wiediskimage-builder
das Element zur Erstellung eines Images anwendet.- instack-undercloud
instack-undercloud
ist ein Undercloud-Installer basierend aufinstack
.
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 inpython-openstackclient
. Es bietet Funktionen bezüglich derinstack
Installation und anfänglichen Konfiguration.
Anhang B. Energieverwaltungs-Driver
B.1. Dell Remote Access Controller (DRAC)
- 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)
- 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 Siepxe_ilo
zurenabled_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 denopenstack-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
- 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 Siepxe_iboot
zurenabled_drivers
Option hinzu um diesen Driver zu deaktivieren.
B.4. SSH und Virsh
Wichtig
- 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
C.1. Festplatte
- Reguläre SATA Controller oder logische Driver von RAID Controllern
- 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
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
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
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
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
E.1. Konfigurieren von Schnittstellen
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
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.
nic1
auf nic4
benutzen und nur vier Kabel an jeden Host anschließen.
E.2. Konfigurieren von Routen und Standardrouten
defroute=no
für Schnittstellen einzustellen, außer für diejenige, die die Standardroute benutzt.
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
- 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
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.
parameters: # Set to "br-ex" when using floating IPs on the native VLAN Controller-1::NeutronExternalNetworkBridge: "''"
parameter_defaults: # Set to "br-ex" when using floating IPs on the native VLAN NeutronExternalNetworkBridge: "''"
E.4. Verwendung des systemeigenen VLANs auf einer Trunk-Schnittstelle
NeutronExternalNetworkBridge
Parameter auf br-ex
anstatt auf ''
in der network-environment.yaml
.
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
E.5. Konfigurieren von Jumbo Frames
Anmerkung
- 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
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.1 | Fri Sep 25 2015 | Red Hat Localization Services | |
| |||
Version 7.0-2 | Wed Aug 5 2015 | Dan Macpherson | |
| |||
Version 7.0-1 | Wed May 20 2015 | Dan Macpherson | |
|