Ersatz des OSPD-Servers UCS 240M4 - CPAR

Einführung

In diesem Dokument werden die erforderlichen Schritte beschrieben, um einen fehlerhaften Server zu ersetzen, der den OpenStack Platform Director (OSPD) in einer Ultra-M-Konfiguration hostet. Dieses Verfahren gilt für eine OpenStack-Umgebung unter Verwendung der NEWTON-Version, in der Cisco Prime Access Registrar (CPAR) von ESC nicht verwaltet wird und CPAR direkt auf dem auf OpenStack bereitgestellten virtuellen System installiert wird.

Hintergrundinformationen

Ultra-M ist eine vorkonfigurierte und validierte Kernlösung für virtualisierte mobile Pakete, die die Bereitstellung von VNFs vereinfacht. OpenStack ist der Virtualized Infrastructure Manager (VIM) für Ultra-M und besteht aus den folgenden Knotentypen:

• Computing
• Object Storage Disk - Computing (OSD - Computing)
• Controller
• OSPD

Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind in diesem Bild dargestellt:

Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind. Es beschreibt die Schritte, die bei OpenStack und Redhat OS ausgeführt werden müssen. 

---

Hinweis: Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument berücksichtigt.

---

Abkürzungen

MOP	Verfahrensweise
OSD	Objektspeicherdatenträger
OSPD	OpenStack Platform Director
HDD	Festplattenlaufwerk
SSD	Solid-State-Laufwerk
VIM	Virtueller Infrastrukturmanager
VM	Virtuelles System
EM	Element Manager
USA	Ultra-Automatisierungsservices
UUID	Universell eindeutige IDentifier

Workflow des MoP

Umfassender Workflow des Austauschverfahrens

Voraussetzungen

Statusprüfung

Bevor Sie einen OSPD-Server ersetzen, ist es wichtig, den aktuellen Zustand der Red Hat OpenStack Platform-Umgebung zu überprüfen und sicherzustellen, dass dieser fehlerfrei ist, um Komplikationen zu vermeiden, wenn der Austauschprozess eingeschaltet ist. 

1. Überprüfen Sie den Status des OpenStack-Stacks und der Knotenliste:

[stack@director ~]$ source stackrc 
[stack@director ~]$ openstack stack list --nested
[stack@director ~]$ ironic node-list
[stack@director ~]$ nova list

2. Überprüfen Sie, ob alle unterCloud-Services über den OSP-D-Knoten den Status "geladen", "aktiv" und "ausgeführt" haben:

[stack@al03-pod2-ospd ~]$ systemctl list-units "openstack*" "neutron*" "openvswitch*"
 UNIT LOAD ACTIVE SUB DESCRIPTION
 neutron-dhcp-agent.service loaded active running OpenStack Neutron DHCP Agent
 neutron-metadata-agent.service loaded active running OpenStack Neutron Metadata Agent
 neutron-openvswitch-agent.service loaded active running OpenStack Neutron Open vSwitch Agent
 neutron-server.service loaded active running OpenStack Neutron Server
 openstack-aodh-evaluator.service loaded active running OpenStack Alarm evaluator service
 openstack-aodh-listener.service loaded active running OpenStack Alarm listener service
 openstack-aodh-notifier.service loaded active running OpenStack Alarm notifier service
 openstack-ceilometer-central.service loaded active running OpenStack ceilometer central agent
 openstack-ceilometer-collector.service loaded active running OpenStack ceilometer collection service
 openstack-ceilometer-notification.service loaded active running OpenStack ceilometer notification agent
 openstack-glance-api.service loaded active running OpenStack Image Service (code-named Glance) API server
 openstack-glance-registry.service loaded active running OpenStack Image Service (code-named Glance) Registry server
 openstack-heat-api-cfn.service loaded active running Openstack Heat CFN-compatible API Service
 openstack-heat-api.service loaded active running OpenStack Heat API Service
 openstack-heat-engine.service loaded active running Openstack Heat Engine Service
 openstack-ironic-api.service loaded active running OpenStack Ironic API service
 openstack-ironic-conductor.service loaded active running OpenStack Ironic Conductor service
 openstack-ironic-inspector-dnsmasq.service loaded active running PXE boot dnsmasq service for Ironic Inspector
 openstack-ironic-inspector.service loaded active running Hardware introspection service for OpenStack Ironic
 openstack-mistral-api.service loaded active running Mistral API Server
 openstack-mistral-engine.service loaded active running Mistral Engine Server
 openstack-mistral-executor.service loaded active running Mistral Executor Server
 openstack-nova-api.service loaded active running OpenStack Nova API Server
 openstack-nova-cert.service loaded active running OpenStack Nova Cert Server
 openstack-nova-compute.service loaded active running OpenStack Nova Compute Server
 openstack-nova-conductor.service loaded active running OpenStack Nova Conductor Server
 openstack-nova-scheduler.service loaded active running OpenStack Nova Scheduler Server
 openstack-swift-account-reaper.service loaded active running OpenStack Object Storage (swift) - Account Reaper
 openstack-swift-account.service loaded active running OpenStack Object Storage (swift) - Account Server
 openstack-swift-container-updater.service loaded active running OpenStack Object Storage (swift) - Container Updater
 openstack-swift-container.service loaded active running OpenStack Object Storage (swift) - Container Server
 openstack-swift-object-updater.service loaded active running OpenStack Object Storage (swift) - Object Updater
 openstack-swift-object.service loaded active running OpenStack Object Storage (swift) - Object Server
 openstack-swift-proxy.service loaded active running OpenStack Object Storage (swift) - Proxy Server
 openstack-zaqar.service loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server
 openstack-zaqar@1.service loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server Instance 1
 openvswitch.service loaded active exited Open vSwitch

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
lines 1-43 
lines 2-44 37 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END)

Sicherung

1. Vergewissern Sie sich, dass genügend Speicherplatz verfügbar ist, bevor Sie den Sicherungsvorgang durchführen. Dieser Tarball soll mindestens 3,5 GB umfassen.

[stack@director ~]$ df -h

2. Führen Sie diese Befehle als Root-Benutzer aus, um die Daten vom unterCloud-Knoten in eine Datei mit dem Namen undercloud-backup-[timestamp].tar.gz zu sichern.

[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql 
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names

Neuen OSPD-Knoten installieren

UCS-Serverinstallation

1. Die Schritte zur Installation eines neuen UCS C240 M4 Servers und die ersten Installationsschritte können im Cisco UCS C240 M4 Server Installations- und Serviceleitfaden beschrieben werden.

2. Nach der Installation des Servers legen Sie die Festplatten in die entsprechenden Steckplätze als alten Server ein.

3. Melden Sie sich mit der Cisco Integrated Management Controller (CIMC) IP beim Server an.

4. Führen Sie ein BIOS-Upgrade durch, wenn die Firmware nicht der zuvor verwendeten empfohlenen Version entspricht. Schritte für BIOS-Upgrades finden Sie hier: BIOS-Upgrade-Leitfaden für Cisco UCS Rackmount-Server der C-Serie.

5. Überprüfen Sie den Status der physischen Laufwerke. Es muss nicht konfiguriert sein "Gut". Navigieren Sie zu Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info (Informationen zum physischen Laufwerk), wie im Bild gezeigt.

6. Erstellen Sie eine virtuelle Festplatte von den physischen Laufwerken mit RAID Level 1. Navigieren Sie zu Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Controller Info > Create Virtual Drive from Unused Physical Drives (Virtuelles Laufwerk aus nicht verwendeten physischen Laufwerken erstellen), wie im Bild gezeigt.

7. Wählen Sie die VD aus, und konfigurieren Sie Set as Boot Drive (Als Startlaufwerk festlegen) wie im Bild gezeigt.

8. Aktivieren Sie IPMI over LAN. Navigieren Sie zu Admin > Communication Services > Communication Services (Verwaltung > Kommunikationsdienste > Kommunikationsdienste), wie im Bild gezeigt.

  

9. Deaktivieren Sie Hyperthreading. Navigieren Sie zu Compute > BIOS > Configure BIOS > Advanced > Processor Configuration wie im Bild gezeigt.

---

Hinweis: Das hier abgebildete Image und die in diesem Abschnitt beschriebenen Konfigurationsschritte beziehen sich auf die Firmware-Version 3.0(3e). Wenn Sie an anderen Versionen arbeiten, kann es zu geringfügigen Abweichungen kommen.

---

Installation von Redhat

Mount the Red Hat ISO Image

1. Melden Sie sich beim OSP-D-Server an.

2. Starten Sie die KVM Console.

3. Navigieren zu Virtual Media > Virtuelle Geräte aktivieren. Akzeptieren Sie die Sitzung, und aktivieren Sie Erinnerungen an zukünftige Verbindungen.

4. Navigieren zu Virtual Media > Karte CD/DVDund ordnen Sie das Red Hat ISO-Image zu.

5. Navigieren zu Stromversorgung > System zurücksetzen (Warmstart) in der Reihenfolge um das System neu zu starten.

6. Drücken Sie nach dem Neustart die F6und wählen SieCisco vKVM-Mapped vDVD1.22und drücken Sie die Eingabetaste.

RHEL installieren

UnterCloud-Installation basierend auf Backup vorbereiten

Wenn der Computer mit RHEL 7.3 installiert ist und sich in einem sauberen Zustand befindet, aktivieren Sie alle Abonnements/Repositories, die für die Installation und Ausführung von Director erforderlich sind, erneut.

1. Hostnamenkonfiguration.

[root@director ~]$sudo hostnamectl set-hostname <FQDN_hostname> 
[root@director ~]$sudo hostnamectl set-hostname --transient <FQDN_hostname>

2. Bearbeiten /etc/hosts-Datei.

[root@director ~]$ vi /etc/hosts
<ospd_external_address>  <server_hostname>  <FQDN_hostname>
192.168.247.142  pod2-stack-ospd pod2-stack-ospd.cisco.com

3. Validieren Sie den Hostnamen.

[root@director ~]$ cat /etc/hostname
pod2-stack-ospd.cisco.com

4. Validieren Sie die DNS-Konfiguration.

[root@director ~]$ cat /etc/resolv.conf

#Generated by NetworkManager
nameserver <DNS_IP>

5. Ändern der Bereitstellungsnic-Schnittstelle

[root@director ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eno1

DEVICE=eno1
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=br-ctlplane
BOOTPROTO=none
MTU=1500

Schließen Sie die Redhat-Registrierung ab

  

1. Laden Sie dieses Paket herunter, um den Abonnement-Manager so zu konfigurieren, dass rh-satellit verwendet wird.

[root@director ~]$ rpm -Uvh http://
       
       
         /pub/katello-ca-consumer-latest.noarch.rpm 
       
[root@director ~]$ subscription-manager config

2. Registrieren Sie sich mit diesem Aktivierungsschlüssel für RHEL 7.3 beim rh-satelliten. 

[root@director ~]$subscription-manager register --org="<ORG>" --activationkey="<KEY>"

3. Um das Abonnement anzuzeigen.

[root@director ~]$ subscription-manager list –consumed

4. Aktivieren Sie die Repositorys wie die alten OSPD-Repos.

[root@director ~]$ sudo subscription-manager repos --disable=*
[root@director ~]$ subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rh
el-7-server-openstack-10-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpm

5. Führen Sie ein Update Ihres Systems durch, um sicherzustellen, dass Sie die neuesten Basissystem-Pakete haben, und starten Sie das System neu.

[root@director ~]$sudo yum update -y
[root@director ~]$sudo reboot

UnterCloud-Wiederherstellung

Nachdem Sie das Abonnement aktiviert haben, importieren Sie die gesicherte Untercloud-TAR-Datei "undercloud-backup-`date +%F`.tar.gz" in das neue OSP-D-Server-Stammverzeichnis /root

1. Installieren Sie den Mariadb-Server.

[root@director ~]$ yum install -y mariadb-server

2. Extrahieren Sie die MariaDB-Konfigurationsdatei und die Datenbank-Sicherung. Führen Sie diesen Vorgang als Root-Benutzer aus.

[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz etc/my.cnf.d/server.cnf
[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz root/undercloud-all-databases.sql

3. Bearbeiten Sie /etc/my.cnf.d/server.cnf, und kommentieren Sie ggf. den Eintrag für bind-address.

[root@tb3-ospd ~]# vi /etc/my.cnf.d/server.cnf

4. Starten Sie den MariaDB-Dienst, und aktualisieren Sie vorübergehend die Einstellung max_allowed_paket.

[root@director ~]$ systemctl start mariadb
[root@director ~]$ mysql -uroot -e"set global max_allowed_packet = 16777216;"

5. Reinigen Sie bestimmte Berechtigungen (diese müssen später neu erstellt werden).

[root@director ~]$ for i in ceilometer glance heat ironic keystone neutron nova;do mysql -e "drop user $i";done
[root@director ~]$ mysql -e 'flush privileges'

---

Hinweis: Wenn der Dienst Deckenmesser zuvor deaktiviert wurde, führen Sie den obigen Befehl aus, indem Sie "Deckenmesser" entfernen.

---

6. Erstellen Sie das Stackuser-Konto.

[root@director ~]$ sudo useradd stack
[root@director ~]$ sudo passwd stack << specify a password
[root@director ~]$ echo "stack ALL=(root) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/stack
[root@director ~]$ sudo chmod 0440 /etc/sudoers.d/stack 

7. Stellen Sie das Stammverzeichnis des Stapelbenutzers wieder her.

[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz home/stack

8. Installieren Sie die Pakete "swift" und "glance", und stellen Sie dann deren Daten wieder her.

[root@director ~]$ yum install -y openstack-glance openstack-swift
[root@director ~]$ tar --xattrs -xzC / -f undercloud-backup-$DATE.tar.gz srv/node var/lib/glance/images

9. Bestätigen Sie, dass die Daten dem richtigen Benutzer gehören.

[root@director ~]$ chown -R swift: /srv/node
[root@director ~]$ chown -R glance: /var/lib/glance/images

10. Stellen Sie die SSL-Zertifikate unter der Cloud wieder her (optional - nur bei Verwendung von SSL-Zertifikaten).

[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz etc/pki/instack-certs/undercloud.pem
[root@director ~]$ tar -xzC / -f undercloud-backup-$DATE.tar.gz etc/pki/ca-trust/source/anchors/ca.crt.pem

11. Führen Sie die Undercloud-Installation erneut als Stackuser aus. Stellen Sie dabei sicher, dass sie im Stack-Benutzerverzeichnis ausgeführt wird:

[root@director ~]$ su - stack
[stack@director ~]$ sudo yum install -y python-tripleoclient

12. Vergewissern Sie sich, dass der Hostname in /etc/hosts korrekt festgelegt ist.

13. Installieren Sie die Unterwolke neu.

[stack@director ~]$ openstack undercloud install

<snip>
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and must be
secured.

#############################################################################

Schließen Sie die Wiederhergestellte Undercloud wieder an die Overcloud an.

Nach Abschluss der obigen Schritte kann davon ausgegangen werden, dass die Unterwolke ihre Verbindung automatisch wieder in die Cloud einstellt. Die Knoten werden weiterhin Orchestrierung (Wärme) für ausstehende Aufgaben abfragen, indem sie eine einfache HTTP-Anfrage verwenden, die alle paar Sekunden erstellt wird.

Überprüfen der abgeschlossenen Wiederherstellung

Verwenden Sie diese Befehle, um eine Integritätsprüfung Ihrer neu wiederhergestellten Umgebung durchzuführen.

[root@director ~]$ su - stack
Last Log in: Tue Nov 28 21:27:50 EST 2017 from 192.182.255.20 on pts/0

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list
+--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod2-stack-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.106 |
| 1f725ce3-948d-49e9-aed9-b99e73d82644 | pod2-stack-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.107 |
| fbc13c78-dc06-4ac9-a3c5-595ccc147adc | pod2-stack-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.119 |
| 3b94e0b1-47dc-4960-b3eb-d02ffe9ae693 | pod2-stack-compute-3 | ACTIVE | - | Running | ctlplane=192.200.0.112 |
| 5dbac94d-19b9-493e-a366-1e2e2e5e34c5 | pod2-stack-compute-4 | ACTIVE | - | Running | ctlplane=192.200.0.116 |
| b896c73f-d2c8-439c-bc02-7b0a2526dd70 | pod2-stack-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.113 |
| 2519ce67-d836-4e5f-a672-1a915df75c7c | pod2-stack-controller-1 | ACTIVE | - | Running | ctlplane=192.200.0.105 |
| e19b9625-5635-4a52-a369-44310f3e6a21 | pod2-stack-controller-2 | ACTIVE | - | Running | ctlplane=192.200.0.120 |
| 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.109 |
| 26d3f7b1-ba97-431f-aa6e-ba91661db45d | pod2-stack-osd-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.117 |
| 6e4a8aa9-4870-465a-a7e2-0932ff55e34b | pod2-stack-osd-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.103 |
+--------------------------------------+--------------------------+--------+------------+-------------+------------------------+
<snip>

[stack@director ~]$ ssh heat-admin@192.200.0.113
Last login: Fri Jul 6 09:02:41 2018 from 192.200.0.1 
[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Tue Jul 10 10:04:15 2018Last change: Fri Jul 6 09:03:35 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Online: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

 ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]
 ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1
 Master/Slave Set: redis-master [redis]
 Masters: [ pod2-stack-controller-2 ]
 Slaves: [ pod2-stack-controller-0 pod2-stack-controller-1 ]
 ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2
 openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

[heat-admin@pod2-stack-controller-0 ~]$ sudo ceph status
 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_OK
 monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}
 election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2
 osdmap e81: 12 osds: 12 up, 12 in
 flags sortbitwise,require_jewel_osds
 pgmap v23094282: 704 pgs, 6 pools, 809 GB data, 424 kobjects
 2418 GB used, 10974 GB / 13393 GB avail
 704 active+clean
 client io 1841 kB/s wr, 0 op/s rd, 220 op/s wr
[heat-admin@pod2-stack-controller-0 ~]$ exit
logout
Connection to 192.200.0.113 closed.

Identitätsdienst (Keystone) überprüfen

In diesem Schritt werden Identitätsdienstvorgänge validiert, indem nach einer Liste von Benutzern abgefragt wird.

[stack@director ~]$ source stackerc
[stack@director~]$ openstack user list
+----------------------------------+------------------+
| ID | Name |
+----------------------------------+------------------+
| 4d93cc08ed314b87b4c6dce95c19558f | admin |
| c499bd1a65d94029804350e3bca19888 | aodh |
| d9b59136b2794ec1b9c18c4f7b95c674 | ceilometer |
| 4650cdca79b44f2b9d2426b7a9df9495 | glance |
| 4a6724a623f4463c971658462b505c8a | heat |
| e18ae9a5b7f14aefb9e93931dcec476e | ironic |
| 9831160669c44c10b04d6f78b7517a55 | ironic-inspector |
| 6a5d6f02b9a74dfb9f679eecfebb28e0 | mistral |
| 462c8ec91fb0485fbc7dfec6d4ecf480 | neutron |
| f3a66d84e39c47a0bdcd14d24bd72816 | nova |
| 1f16ea9035ab424a88d5f34681d3f893 | swift |
| ab4a1e5f62be4609b290c32dc93bfbce | zaqar |
| fac68a166f5f442284f7d06355369c53 | zaqar-websocket |
+----------------------------------+------------------+

[stack@director ~]$ source <overcloudrc>
[stack@director ~]$ openstack user list
+----------------------------------+------------+
| ID | Name |
+----------------------------------+------------+
| 7285a65e0c8c4447b10875d0e9c9da69 | admin |
| c7c78ac31ec24926b3eed79e7f5bd59e | neutron |
| 191c2a293beb48edb4d2c1160c9a0523 | heat |
| 1445a6ef2ae94b6f9365ffbc6b56a231 | gnocchi |
| fb8b006129554c6b8465310fcfc0ba8c | aodh |
| 5afcb816f93b4f20998c9edaf3b143a0 | nova |
| 37444af1295344809eca6058a782f871 | glance |
| e74d2d9e59f34ddfb4408a8beb88db7b | ceilometer |
| 9baab90178c141478ce7c0084e930f40 | cinder |
| 5a964c651c11402284eecb0e8f40ee33 | heat-cfn |
| 6d49ebae55da432580943d6080efcf90 | swift |
| 41a666fe64c64df593d73b4f467885be | core |
| ab004ba966bf4ddc92783fbb6045e48b | cpar |
| fce5b5c5dc7647ccbc2170b56a64db33 | cpardemo |
| 28ead2dab0ef486ba449b441715a3e04 | pcrf |
| 0aac4107e3d443dc93ca62c3928a1998 | pcrfdemo |
+----------------------------------+------------+

Hochladen von Bildern für eine zukünftige Node-Einführung

1. Validieren Sie /httpboot alle diese Dateien "inspector.ipxe, agent.kernel, agent.ramdisk", wenn nicht die folgenden Schritte zur Aktualisierung im Image ausgeführt werden.

[stack@director ~]$ ls /httpboot
inspector.ipxe
[stack@director ~]$ source stackrc 
[stack@director ~]$ cd images/
[stack@director images]$ openstack overcloud image upload --image-path /home/stack/images
Image "overcloud-full-vmlinuz" is up-to-date, skipping.
Image "overcloud-full-initrd" is up-to-date, skipping.
Image "overcloud-full" is up-to-date, skipping.
Image "bm-deploy-kernel" is up-to-date, skipping.
Image "bm-deploy-ramdisk" is up-to-date, skipping.
[stack@director images]$ ls /httpboot
agent.kernel agent.ramdisk inspector.ipxe
[stack@director images]$ 

Neustarten der Konferenz

Die Zählung befand sich nach der OSPD-Wiederherstellung im gestoppten Zustand, während das Verfahren eine Zähmung ermöglicht. 

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs property set stonith-enabled=true
[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status
[heat-admin@pod2-stack-controller-0 ~]$sudo pcs stonith show 

Zugehörige Informationen

• Sichern und Wiederherstellen der Director Undercloud

• Bestimmen der Controller-Knoten

• Technischer Support und Dokumentation - Cisco Systems