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

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

Arbeitsablauf

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

Anforderungen

  • Der in Kapitel 3, Installieren der Undercloud erstellte Director-Knoten
  • Neun Bare-Metal-Rechner. Diese Rechner müssen die für Controller, Compute und Ceph-Storage-Knoten festgelegten Anforderungen erfüllen. Näheres zu diesen Anforderungen finden Sie unter:
    Diese Knoten benötigen kein Betriebssystem, da der Director ein Red Hat Enterprise Linux 7 Image zu jedem Knoten kopiert.
  • Eine Netzwerkverbindung für Ihr Provisioning-Netzwerk, die als systemeigenes VLAN konfiguriert ist. Alle Knoten müssen mit diesem Netzwerk verbunden sein und die in Abschnitt 2.3, »Netzwerkanforderungen« festgelegten Anforderungen erfüllen. Für dieses Beispiel benutzen wir 192.0.2.0/24 als Provisioning-Subnetz mit folgender IP-Adresszuweisungen:

    Tabelle 6.3. Provisioning-Netzwerk IP-Zuweisungen

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

    Tabelle 6.4. Netzwerk Subnetz und VLAN-Zuweisungen

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

6.3.1. Registrieren der Knoten für die Erweiterte Overcloud

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

Anmerkung

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

6.3.2. Überprüfen der Knoten-Hardware

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

Wichtig

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

Wichtig

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

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

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

Wichtig

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

6.3.3.1. ahc-Bericht

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

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

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

6.3.3.2. ahc-match

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

6.3.4. Erstellen von Hardware-Profilen

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

6.3.5. Verwendung der Standard Overcloud Heat-Vorlagen

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

Anmerkung

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

6.3.6. Konfiguration von Ceph-Storage

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

6.3.7. Alle Netzwerke in VLANs isolieren

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

6.3.7.1. Erstellung von benutzerdefinierten Schnittstellenvorlagen

Die Konfiguration des Overcloud Netzwerks erfordert eine Reihe von Netzwerkschnittstellen-Vorlagen. Diese Vorlagen werden von Ihnen angepasst um die Knotenschnittstellen auf einer pro-Rolle Basis zu konfigurieren. Diese Vorlagen sind Standard Heat-Vorlagen im YAML Format (vgl. Kapitel 5, Heat-Vorlagen verstehen). Der Director beinhaltet eine bestimmte Anzahl von Beispiel-Vorlagen um Ihnen den Einstieg zu erleichtern:
  • /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans - Verzeichnis, das Vorlagen für einen einzelnen NIC mit VLAN Konfiguration auf einer pro-Rolle Basis enthält.
  • /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans - Verzeichnis, das Vorlagen für verbundene NIC-Konfiguration auf einer pro-Rolle Basis enthält.
Für das Erweiterte Overcloud Szenario verwenden wir die standardmäßig verbundene NIC Beispielkonfiguration als Basis. Kopieren Sie das Standard-Konfigurationsverzeichnis ins stack Home-Verzeichnis des Benutzers als nic-configs. 
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans ~/templates/nic-configs
Dies erstellt einen lokalen Satz von Heat-Vorlagen, die eine verbundene Netzwerkschnittstellen-Konfiguration für jede Rolle angeben. Jede Vorlage enthält die standardmäßigen parameters, resources, und output Abschnitte. Für Ihre Zwecke bearbeiten wir nur den resources Abschnitt. Jeder resources Abschnitt beginnt mit dem Folgenden: 
resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
Dies erstellt eine Anforderung für den os-apply-config Befehl und os-net-config Subbefehl, um die Netzwerkeigenschaften für einen Knoten zu konfigurieren. Der network_config Abschnitt enthält Ihre benutzerdefinierte Schnittstellenkonfiguration, angeordnet in einer Typ-basierten Sequenz, die Folgendes beinhaltet:
Schnittstelle
Definiert eine einzelne Netzwerkschnittstelle. Die Konfiguration bestimmt jede Schnittstelle, indem sie entweder den eigentlichen Schnittstellennamen verwendet ("eth0", "eth1", "enp0s25") oder eine Reihe von nummerierten Schnittstellen ("nic1", "nic2", "nic3"). 
            - type: interface
              name: nic2
vlan
Definiert ein VLAN. Verwendet VLAN-ID und Subnetz aus dem parameters Abschnitt. 
            - type: vlan
              vlan_id: {get_param: ExternalNetworkVlanID}
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}
ovs_bond
Definiert einen Bond in vSwitch. Ein Bond verbindet zwei oder mehrere interfaces miteinander um mit Redundanz zu helfen und die Bandbreite zu erweitern. 
            - type: ovs_bond
              name: bond1
              members:
              - type: interface
                name: nic2
              - type: interface
                name: nic3
ovs_bridge
Definiert eine Brücke in Open vSwitch. Eine Brücke verbindet mehrere interface, bond und vlan Objekte miteinander. 
            - type: ovs_bridge
              name: {get_input: bridge_name}
              members:
                - type: ovs_bond
                  name: bond1
                  members:
                    - type: interface
                      name: nic2
                      primary: true
                    - type: interface
                      name: nic3
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ExternalIpSubnet}
Unter Anhang D, Netzwerkschnittstellen-Parameter finden Sie eine vollständige Liste von Parametern für jedes dieser Elemente.
Für das Erweiterte Szenario verwenden wir die Standardkonfiguration für verbundene Schnittstellen. Die templates/nic-configs/controller.yaml Vorlage benutzt zum Beispiel folgende network_config: 
          network_config:
            - type: ovs_bridge
              name: {get_input: bridge_name}
              members:
                - type: ovs_bond
                  name: bond1
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  members:
                    - type: interface
                      name: nic2
                      primary: true
                    - type: interface
                      name: nic3
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ExternalIpSubnet}
                  routes:
                    - ip_netmask: 0.0.0.0/0
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: InternalApiIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: StorageIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageMgmtNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: StorageMgmtIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                  - ip_netmask: {get_param: TenantIpSubnet}
Diese Vorlage definiert eine Brücke (gewöhnlich die externe Brücke namens br-ex) und erstellt eine verbundene Schnittstelle namens bond1 aus zwei nummerierten Schnittstellen: nic2 und nic3. Die Brücke beinhaltet auch mehrere markierte VLAN Geräte, die bond1 als übergeordnetes Gerät verwenden.
Weitere Beispiele für Vorlagen von Netzwerkschnittstellen finden Sie unter Anhang E, Beispiele für Netzwerkschnittstellenvorlagen.
Beachten Sie, dass viele dieser Parameter die get_param Funktion verwenden. Definieren Sie diese in einer Umgebungsdatei, die Sie speziell für Ihre Netzwerke anlegen.

Wichtig

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

6.3.7.2. Erstellen einer Netzwerkumgebungsdatei einer Erweiterten Overcloud

Die Netzwerkumgebungsdatei ist eine Heat-Umgebungsdatei, die die Netzwerkumgebung der Overcloud beschreibt und auf die Netzwerkschnittstellen-Konfigurationsvorlage aus dem vorherigen Abschnitt verweist. Die Subnetze und VLANs für Ihr Netzwerk werden zusammen mit den IP-Adressbereichen definiert. Wir passen diese Werte der lokalen Umgebung an.
Dieses Szenario benutzt folgende Netzwerkumgebungsdatei, die als /home/stack/templates/network-environment.yaml gespeichert ist: 
resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/ceph-storage.yaml

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

Wichtig

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

Wichtig

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

6.3.7.3. Zuweisung der OpenStack Dienste zu isolierten Netzwerken

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

parameters:

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

6.3.8. Erstellen der Erweiterten Overcloud

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

Anmerkung

Für eine vollständige Liste von Optionen folgenden Befehl ausführen: 
$ openstack help overcloud deploy
Parameterbeispiele finden Sie unter Anhang G, Bereitstellungsparameter.
Der Prozess zur Erstellung der Overcloud beginnt und der Directort stellt Ihre Knoten bereit. Dieser Prozess wird eine Weile dauern. Um den Status der Overcloud-Erstellung zu überprüfen, öffnen Sie ein separates Terminal als stack Benutzer und führen Sie folgenden Befehl aus: 
$ source ~/stackrc                # Initializes the stack user to use the CLI commands
$ heat stack-list --show-nested
Der heat stack-list --show-nested Befehl zeigt die aktuelle Phase der Overcloud-Erstellung an.

Wichtig

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

6.3.9. Zugriff auf die Erweiterte Overcloud

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

6.3.10. Fencing der Controller-Knoten

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

Anmerkung

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

Anmerkung

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

6.3.11. Abschließen der Erweiterten Overcloud

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