Ersetzen Sie die Hauptplatine im Ultra-M UCS 240M4 Server - vEPC.

Download-Optionen

PDF (432.0 KB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (339.0 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (310.0 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:19. Juli 2021

Dokument-ID:213580

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einführung

Hintergrundinformationen

Abkürzungen

Workflow des MoP

Austausch der Hauptplatine im Ultra-M-Setup

Austausch des Motherboards im Computing-Knoten

Identifizieren der im Compute-Knoten gehosteten VMs

Graceful Power Aus

Fall 1. Computing-Knoten-Hosts nur SF VM

Fall 2. Computing-Knoten-Hosts CF/ESC/EM/UAS

Hauptplatine ersetzen

Stellen Sie die VMs wieder her

Fall 1. Computing-Knoten-Hosts nur SF VM

Fall 2. Computing-Knoten-Hosts für UAS, ESC, EM und CF

Hauptplatinenaustausch im OSD-Computing-Knoten

Ceph im Servicemodus aktivieren

Identifizieren der im Osd-Compute-Knoten gehosteten VMs

Graceful Power Aus

Fall 1. OSD-Compute-Knoten-Hosts CF/ESC/EM/UAS

Fall 2. Automatische Bereitstellung/Auto-It/EM/UAS durch OSD-Compute-Node-Hosts

Backup des CDB der automatischen Bereitstellung

Backup System.cfg von Auto-IT

Hauptplatine ersetzen

Ceph aus dem Servicemodus entfernen

Stellen Sie die VMs wieder her

Fall 1. OSD-Compute-Knoten-Hosts CF, ESC, EM und UAS

Fall 2. Automatische Bereitstellung, EM und UAS durch OSD-Computing-Node-Hosts

Auto-IT VM wiederherstellen

Ersetzen der Hauptplatine im Controller-Knoten

Controller-Status überprüfen und Cluster in Servicemodus setzen

Hauptplatine ersetzen

Cluster-Status wiederherstellen

Einführung

Dieses Dokument beschreibt die erforderlichen Schritte, um das fehlerhafte Motherboard eines Servers in einer Ultra-M-Konfiguration zu ersetzen, die StarOS Virtual Network Functions (VNFs) hostet.

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
OpenStack-Plattform - Director (OSPD)

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

UltraM-Architektur

Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind. Es enthält eine Beschreibung der Schritte, die auf der Ebene von OpenStack und StarOS VNF zum Zeitpunkt des Hauptplatinenaustauschs in einem Server durchgeführt werden müssen.

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

Abkürzungen

VNF	Virtuelle Netzwerkfunktion
CF	Kontrollfunktion
SF	Servicefunktion
WSA	Elastic Service Controller
MOP	Verfahrensweise
OSD	Objektspeicherdatenträger
HDD	Festplattenlaufwerk
SSD	Solid-State-Laufwerk
VIM	Virtueller Infrastrukturmanager
VM	Virtuelles System
EM	Element Manager
USA	Ultra-Automatisierungsservices
UUID	Universeller Identifikator

Workflow des MoP

Workflow für den Austausch

Austausch der Hauptplatine im Ultra-M-Setup

In einer Ultra-M-Konfiguration kann es Szenarien geben, in denen ein Austausch des Motherboards bei folgenden Servertypen erforderlich ist: Computing, OSD-Computing und Controller.

Hinweis: Die Boot-Laufwerke mit der OpenStack-Installation werden nach dem Austausch der Hauptplatine ersetzt. Daher ist es nicht erforderlich, den Knoten wieder zur Cloud hinzuzufügen. Wenn der Server nach der Ersetzungsaktivität eingeschaltet wird, meldet er sich wieder beim Overcloud-Stack an.

Austausch des Motherboards im Computing-Knoten

Vor der Aktivität werden die im Knoten Compute gehosteten VMs ordnungsgemäß heruntergefahren. Nachdem die Hauptplatine ausgetauscht wurde, werden die VMs wiederhergestellt.

Identifizieren der im Compute-Knoten gehosteten VMs

Identifizieren Sie die VMs, die auf dem Computing-Server gehostet werden. Es gibt zwei Möglichkeiten:

Der Compute-Server enthält nur SF VM:

[stack@director ~]$ nova list --field name,host | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  
pod1-compute-10.localdomain    |

Der Compute-Server enthält eine Kombination aus VMs (CF/ESC/EM/UAS):

[stack@director ~]$ nova list --field name,host | grep compute-8
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

Hinweis: In der hier gezeigten Ausgabe entspricht die erste Spalte der UUID, die zweite Spalte dem VM-Namen und die dritte Spalte dem Hostnamen, in dem die VM vorhanden ist. Die Parameter aus dieser Ausgabe werden in den nachfolgenden Abschnitten verwendet.

Graceful Power Aus

Fall 1. Computing-Knoten-Hosts nur SF VM

Melden Sie sich beim StarOS VNF an, und identifizieren Sie die Karte, die dem SF VM entspricht. Verwenden Sie die UUID des im Abschnitt Identifizieren der im Compute-Knoten gehosteten VMs und identifizieren Sie die Karte, die der UUID entspricht:

[local]VNF2# show card hardware
Tuesday might 08 16:49:42 UTC 2018
<snip>
Card 8:
  Card Type               : 4-Port Service Function Virtual Card
  CPU Packages            : 26 [#0, #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25]
  CPU Nodes               : 2
  CPU Cores/Threads       : 26
  Memory                  : 98304M (qvpc-di-large)
  UUID/Serial Number      :  49AC5F22-469E-4B84-BADC-031083DB0533
<snip>

Überprüfen Sie den Status der Karte:

[local]VNF2# show card table
Tuesday might 08 16:52:53 UTC 2018
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Active         No         
 2: CFC      Control Function Virtual Card           Standby        -          
 3: FC       4-Port Service Function Virtual Card    Active         No         
 4: FC       4-Port Service Function Virtual Card    Active         No         
 5: FC       4-Port Service Function Virtual Card    Active         No         
 6: FC       4-Port Service Function Virtual Card    Active         No         
 7: FC       4-Port Service Function Virtual Card    Active         No         
8: FC       4-Port Service Function Virtual Card    Active         No         
 9: FC       4-Port Service Function Virtual Card    Active         No         
10: FC       4-Port Service Function Virtual Card    Standby        -

Wenn sich die Karte im aktiven Zustand befindet, verschieben Sie sie in den Standby-Status:

  [local]VNF2# card migrate from 8 to 10

Melden Sie sich beim ESC-Knoten an, der der VNF entspricht, und überprüfen Sie den Status der SF VM:

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name> VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

Beenden Sie die SF VM mit dem VM-Namen. (VM-Name siehe Abschnitt Identifizieren der im Compute-Knoten gehosteten VMs):

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

Nach dem Beenden muss die VM in den SHUTOFF-Status wechseln:

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
<snip>

Fall 2. Computing-Knoten-Hosts CF/ESC/EM/UAS

Melden Sie sich beim StarOS VNF an, und identifizieren Sie die Karte, die dem CF VM entspricht. Verwenden Sie die UUID des CF VM, die im Abschnitt Identifizieren der im Compute-Knoten gehosteten VMs angegeben ist, und suchen Sie die Karte, die der UUID entspricht:

[local]VNF2# show card hardware
Tuesday might 08 16:49:42 UTC 2018
<snip>
Card 2:
  Card Type               : Control Function Virtual Card
  CPU Packages            : 8 [#0, #1, #2, #3, #4, #5, #6, #7]
  CPU Nodes               : 1
  CPU Cores/Threads       : 8
  Memory                  : 16384M (qvpc-di-large)
  UUID/Serial Number      : F9C0763A-4A4F-4BBD-AF51-BC7545774BE2
<snip>

Überprüfen Sie den Status der Karte:

[local]VNF2# show card table
Tuesday might 08 16:52:53 UTC 2018
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Standby        -
 2: CFC      Control Function Virtual Card           Active         No          
 3: FC       4-Port Service Function Virtual Card    Active         No         
 4: FC       4-Port Service Function Virtual Card    Active         No         
 5: FC       4-Port Service Function Virtual Card    Active         No         
 6: FC       4-Port Service Function Virtual Card    Active         No         
 7: FC       4-Port Service Function Virtual Card    Active         No         
 8: FC       4-Port Service Function Virtual Card    Active         No         
 9: FC       4-Port Service Function Virtual Card    Active         No         
10: FC       4-Port Service Function Virtual Card    Standby        -

Wenn sich die Karte im aktiven Zustand befindet, stellen Sie die Karte in den Standby-Status:

[local]VNF2# card migrate from 2 to 1

Melden Sie sich beim ESC-Knoten an, der der VNF entspricht, und überprüfen Sie den Status der VMs:

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

Beenden Sie das CF- und EM VM einzeln mit dem VM-Namen. (VM-Name siehe Abschnitt Identifizieren der im Compute-Knoten gehosteten VMs):

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

Nach dem Beenden müssen die VMs in den SHUTOFF-Status wechseln:

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    
       
       
         VM_SHUTOFF_STATE 
       
<snip>

Melden Sie sich beim im Compute-Knoten gehosteten ESC an, und prüfen Sie, ob er sich im Master-Status befindet. Wenn ja, schalten Sie den ESC in den Standby-Modus um:

[admin@VNF2-esc-esc-0 esc-cli]$ escadm status
0 ESC status=0 ESC Master Healthy


[admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop
Stopping keepalived:                                       [  OK  ]

[admin@VNF2-esc-esc-0 ~]$ escadm status
1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@VNF2-esc-esc-0 ~]$ sudo reboot
Broadcast message from admin@vnf1-esc-esc-0.novalocal
       (/dev/pts/0) at 13:32 ...
The system is going down for reboot NOW!

Hauptplatine ersetzen

Die Schritte zum Ersetzen des Motherboards in einem UCS C240 M4 Server können unter folgender Adresse aufgerufen werden: Cisco UCS C240 M4 Server Installations- und Serviceleitfaden

Melden Sie sich mit der CIMC IP-Adresse beim Server an.

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

Stellen Sie die VMs wieder her

Fall 1. Computing-Knoten-Hosts nur SF VM

Die SF VM befindet sich in der nova-Liste im Fehlerzustand:

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     |

Stellen Sie die SF VM vom ESC wieder her:

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

Überwachen Sie yangesc.log:

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

Stellen Sie sicher, dass die SF-Karte als Standby-SF im VNF verfügbar ist.

Fall 2. Computing-Knoten-Hosts für UAS, ESC, EM und CF

Recovery von UAS VM

Überprüfen Sie den Status der UAS VM in der nova-Liste, und löschen Sie sie:

[stack@director ~]$ nova list | grep VNF2-UAS-uas-0
| 307a704c-a17c-4cdc-8e7a-3d6e7e4332fa | VNF2-UAS-uas-0                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.10; VNF2-UAS-uas-management=172.168.10.3
[stack@tb5-ospd ~]$ nova delete VNF2-UAS-uas-0
Request to delete server VNF2-UAS-uas-0 has been accepted.

Um das AutoVNF-UAS VM wiederherzustellen, führen Sie das UAS-Check-Skript aus, um den Status zu überprüfen. Sie muss einen Fehler melden. Führen Sie dann erneut mit —fix-Option aus, um die fehlende UAS VM wiederherzustellen:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts/
[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS
2017-12-08 12:38:05,446 - INFO: Check of AutoVNF cluster started
2017-12-08 12:38:07,925 - INFO: Instance 'vnf1-UAS-uas-0' status is 'ERROR'
2017-12-08 12:38:07,925 - INFO: Check completed, AutoVNF cluster has recoverable errors

[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS --fix
2017-11-22 14:01:07,215 - INFO: Check of AutoVNF cluster started
2017-11-22 14:01:09,575 - INFO: Instance VNF2-UAS-uas-0' status is 'ERROR'
2017-11-22 14:01:09,575 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-22 14:01:09,778 - INFO: Removing instance VNF2-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Removed instance VNF2-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Creating instance VNF2-UAS-uas-0' and attaching volume ‘VNF2-UAS-uas-vol-0'
2017-11-22 14:01:49,525 - INFO: Created instance ‘VNF2-UAS-uas-0'

Melden Sie sich bei AutoVNF-UAS an. Warten Sie einige Minuten, und dann sehen Sie, dass die USA wieder in den guten Zustand zurückkehren:

VNF2-autovnf-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.17.181.101
INSTANCE IP   STATE  ROLE
-----------------------------------
172.17.180.6  alive  CONFD-SLAVE
172.17.180.7  alive  CONFD-MASTER
172.17.180.9  alive  NA

Wiederherstellung des ESC VM

Überprüfen Sie den Status des ESC VM in der Nova-Liste, und löschen Sie ihn:

stack@director scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | VNF2-ESC-ESC-1                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |
[stack@director scripts]$ nova delete VNF2-ESC-ESC-1
Request to delete server VNF2-ESC-ESC-1 has been accepted.

Suchen Sie in AutoVNF-UAS die ESC-Bereitstellungstransaktion, und suchen Sie im Protokoll für die Transaktion die Befehlszeile boot_vm.py, um die ESC-Instanz zu erstellen:

ubuntu@VNF2-uas-uas-0:~$ sudo -i
root@VNF2-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI    
admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
VNF2-uas-uas-0#show transaction
TX ID                                 TX TYPE          DEPLOYMENT ID    TIMESTAMP                         STATUS
-----------------------------------------------------------------------------------------------------------------------------
35eefc4a-d4a9-11e7-bb72-fa163ef8df2b  vnf-deployment   VNF2-DEPLOYMENT  2017-11-29T02:01:27.750692-00:00  deployment-success
73d9c540-d4a8-11e7-bb72-fa163ef8df2b  vnfm-deployment  VNF2-ESC         2017-11-29T01:56:02.133663-00:00  deployment-success


VNF2-uas-uas-0#show logs 73d9c540-d4a8-11e7-bb72-fa163ef8df2b | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
  <logs xmlns="http://www.cisco.com/usp/nfv/usp-autovnf-oper">
    <tx-id>73d9c540-d4a8-11e7-bb72-fa163ef8df2b</tx-id>
    <log>2017-11-29 01:56:02,142 - VNFM Deployment RPC triggered for deployment: VNF2-ESC, deactivate: 0
2017-11-29 01:56:02,179 - Notify deployment
..
2017-11-29 01:57:30,385 - Creating VNFM 'VNF2-ESC-ESC-1' with [python //opt/cisco/vnf-staging/bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username ****** --os_password ****** --bs_os_auth_url http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username ****** --bs_os_password ****** --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --encrypt_key ****** --user_pass ****** --user_confd_pass ****** --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

Speichern Sie die Zeile boot_vm.py in einer Shell-Skriptdatei (esc.sh) und aktualisieren Sie alle Zeilen mit dem Benutzernamen ***** und dem Kennwort **** mit den richtigen Informationen (in der Regel Kern/<PASSWORD>). Sie müssen die Option —encrypt_key ebenfalls entfernen. Für user_pass und user_cond_pass müssen Sie das Format - Benutzername: Kennwort (Beispiel - admin:<PASSWORD>).

Suchen Sie die URL zu bootvm.py aus running-config, und rufen Sie die Datei bootvm.py auf die AutoVNF UAS VM. In diesem Fall ist 10.1.2.3 die IP-Adresse der AutoIT VM:

root@VNF2-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
VNF2-uas-uas-0#show running-config autovnf-vnfm:vnfm
…
configs bootvm
  value http:// 10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
!

root@VNF2-uas-uas-0:~# wget http://10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
--2017-12-01 20:25:52--  http://10.1.2.3 /bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
Connecting to 10.1.2.3:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127771 (125K) [text/x-python]
Saving to: ‘bootvm-2_3_2_155.py’
100%[=====================================================================================>] 127,771  --.-K/s   in 0.001s
2017-12-01 20:25:52 (173 MB/s) - ‘bootvm-2_3_2_155.py’ saved [127771/127771]

Erstellen Sie eine /tmp/esc_params.cfg-Datei:

root@VNF2-uas-uas-0:~# echo "openstack.endpoint=publicURL" > /tmp/esc_params.cfg

Führen Sie Shell-Skript aus, um ESC vom UAS-Knoten bereitzustellen:

root@VNF2-uas-uas-0:~# /bin/sh esc.sh
+ python ./bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689
 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url 
http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username core --os_password <PASSWORD> --bs_os_auth_url 
http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username core --bs_os_password <PASSWORD> 
--esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --user_pass admin:<PASSWORD> --user_confd_pass 
admin:<PASSWORD> --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3
172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh 
--file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py 
--file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

Melden Sie sich beim neuen ESC an, und überprüfen Sie den Backup-Zustand:

ubuntu@VNF2-uas-uas-0:~$ ssh admin@172.168.11.14
…
   ####################################################################
   #   ESC on VNF2-esc-esc-1.novalocal is in BACKUP state.
   ####################################################################

[admin@VNF2-esc-esc-1 ~]$ escadm status
0 ESC status=0 ESC Backup Healthy

[admin@VNF2-esc-esc-1 ~]$ health.sh
============== ESC HA (BACKUP) ===================================================
ESC HEALTH PASSED

FC- und EM-VMs vom ESC wiederherstellen

Überprüfen Sie den Status der CF- und EM-VMs aus der Nova-Liste. Sie müssen sich im FEHLERzustand befinden:

[stack@director ~]$ source corerc
[stack@director ~]$ nova list --field name,host,status |grep -i err   
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | None                                 | ERROR|
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     |None                                 | ERROR

Melden Sie sich bei ESC Master an, führen Sie Recovery-vm-action für jedes betroffene EM und CF VM aus. Sei geduldig! ESC plant die Wiederherstellungsaktion, die möglicherweise nicht für einige Minuten erfolgt. Überwachen Sie yangesc.log:

sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO 
       
       

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

[admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8]

Melden Sie sich beim neuen EM an, und überprüfen Sie, ob der EM-Status aktiv ist:

ubuntu@VNF2vnfddeploymentem-1:~$ /opt/cisco/ncs/current/bin/ncs_cli -u admin -C
admin connected from 172.17.180.6 using ssh on VNF2vnfddeploymentem-1
admin@scm# show ems
EM            VNFM
ID  SLA  SCM  PROXY
---------------------
2   up   up   up
3   up   up   up

Melden Sie sich beim StarOS VNF an, und überprüfen Sie, ob sich die CF-Karte im Standby-Modus befindet.

Handhabung von ESC-Wiederherstellungsfehlern

Falls ESC aufgrund eines unerwarteten Zustands nicht starten kann, wird empfohlen, einen ESC-Switchover durch einen Neustart des Master-ESC durchzuführen. Der ESC-Switchover dauert etwa eine Minute. Führen Sie das Skript health.sh auf dem neuen Master-ESC aus, um zu überprüfen, ob der Status aktiv ist. Master-ESC zum Starten der VM und zum Beheben des VM-Status. Diese Wiederherstellungsaufgabe dauert bis zu 5 Minuten.

Sie können /var/log/esc/yangesc.log und /var/log/esc/escmanager.log überwachen. Wenn Sie nicht sehen, dass VM nach 5-7 Minuten wiederhergestellt wird, muss der Benutzer die manuelle Wiederherstellung der betroffenen VM(s) durchführen.

Hauptplatinenaustausch im OSD-Computing-Knoten

Vor der Aktivität werden die im Knoten Compute gehosteten VMs ordnungsgemäß heruntergefahren und der Ceph in den Wartungsmodus versetzt. Nach dem Austausch der Hauptplatine werden die VMs wiederhergestellt und Ceph aus dem Wartungsmodus entfernt.

Ceph im Servicemodus aktivieren

Überprüfen Sie, ob der Status ceph osd tree auf dem Server aktiv ist.

[heat-admin@pod1-osd-compute-1 ~]$ sudo ceph osd tree

ID WEIGHT     TYPE NAME                           UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default
-2    4.35999       host pod1-osd-compute-0
   0    1.09000           osd.0                            up    1.00000            1.00000
   3    1.09000           osd.3                              up   1.00000            1.00000
   6    1.09000           osd.6                            up    1.00000            1.00000
   9    1.09000           osd.9                            up    1.00000            1.00000

-3    4.35999       host pod1-osd-compute-2
   1    1.09000            osd.1                            up    1.00000            1.00000
   4    1.09000           osd.4                            up    1.00000            1.00000
   7    1.09000           osd.7                            up    1.00000            1.00000
10    1.09000           osd.10                           up    1.00000            1.00000

-4    4.35999       host pod1-osd-compute-1
   2    1.09000           osd.2                            up    1.00000            1.00000
   5    1.09000           osd.5                            up    1.00000            1.00000
   8    1.09000           osd.8                            up    1.00000            1.00000
 11  1.09000         osd.11                         up  1.00000          1.00000

Melden Sie sich beim Knoten OSD Compute an, und stellen Sie Ceph in den Servicemodus.

[root@pod1-osd-compute-1 ~]# sudo ceph osd set norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd set noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_WARN
 noout,norebalance,sortbitwise,require_jewel_osds flag(s) set
 monmap e1: 3 mons at {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap e194: 12 osds: 12 up, 12 in
 flags noout,norebalance,sortbitwise,require_jewel_osds
 pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects
 1585 GB used, 11808 GB / 13393 GB avail
 704 active+clean
 client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr

Hinweis: Wenn Ceph entfernt wird, wechselt VNF HD RAID in den Status "Degraded" (Heruntergestuft), aber die Festplatte muss weiterhin zugänglich sein.

Identifizieren der im Osd-Compute-Knoten gehosteten VMs

Identifizieren Sie die VMs, die auf dem OSD-Computing-Server gehostet werden. Es gibt zwei Möglichkeiten:

Der osd-Computing-Server enthält die VM-Kombination Element Manager (EM)/UAS/Auto-Deploy/Auto-IT:

[stack@director ~]$ nova list --field name,host | grep osd-compute-0
| c6144778-9afd-4946-8453-78c817368f18 | AUTO-DEPLOY-VNF2-uas-0                                   | pod1-osd-compute-0.localdomain |
| 2d051522-bce2-4809-8d63-0c0e17f251dc | AUTO-IT-VNF2-uas-0                                       | pod1-osd-compute-0.localdomain |
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-osd-compute-0.localdomain |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                           | pod1-osd-compute-0.localdomain |

Der Compute-Server enthält eine Kombination aus VMs:

[stack@director ~]$ nova list --field name,host | grep osd-compute-1
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

Graceful Power Aus

Fall 1. OSD-Compute-Knoten-Hosts CF/ESC/EM/UAS

Das Verfahren zur sanften Stromversorgung von CF/ESC/EM/UAS VMs ist identisch, unabhängig davon, ob die VMs im Knoten Compute oder OSD-Compute gehostet werden. Folgen Sie den Schritten vom Hauptplatinenaustausch im Computing-Knoten, um die VMs ordnungsgemäß abzuschalten.

Fall 2. Automatische Bereitstellung/Auto-It/EM/UAS durch OSD-Compute-Node-Hosts

Backup des CDB der automatischen Bereitstellung

Sichern Sie die automatische Bereitstellung der CDB-Daten regelmäßig oder nach jeder Aktivierung/Deaktivierung und speichern Sie die Datei auf einem Backup-Server. Die automatische Bereitstellung ist nicht redundant, und wenn diese Daten verloren gehen, können Sie die Bereitstellung nicht ordnungsgemäß deaktivieren.

Melden Sie sich bei AutoDeploy VM an, und sichern Sie das CDB-Verzeichnis.

ubuntu@auto-deploy-iso-2007-uas-0:~ $sudo -i 

 root@auto-deploy-iso-2007-uas-0:~#service uas-confd stop 
uas-confd stop/waiting

root@auto-deploy-iso-2007-uas-0:~# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd
root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd#tar cvf autodeploy_cdb_backup.tar cdb/
cdb/
cdb/O.cdb
cdb/C.cdb
cdb/aaa_init.xml
cdb/A.cdb

root@auto-deploy-iso-2007-uas-0:~# service uas-confd start
uas-confd start/running, process 13852

Hinweis: Opy autodeploy_cdb_backup.tar, um den Server zu sichern.

Backup System.cfg von Auto-IT

Sichern Sie den Server mit der Datei system.cfg:

  Auto-it = 10.1.1.2
  Backup server = 10.2.2.2

[stack@director ~]$ ssh ubuntu@10.1.1.2
ubuntu@10.1.1.2's password: 
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-76-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Wed Jun 13 16:21:34 UTC 2018

  System load:  0.02               Processes:           87
  Usage of /:   15.1% of 78.71GB   Users logged in:     0
  Memory usage: 13%                IP address for eth0: 172.16.182.4
  Swap usage:   0%

  Graph this data and manage this system at:
    https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

  Cisco Ultra Services Platform (USP) 
    Build Date: Wed Feb 14 12:58:22 EST 2018
    Description: UAS build assemble-uas#1891
    sha1: bf02ced


ubuntu@auto-it-vnf-uas-0:~$ scp -r /opt/cisco/usp/uploads/system.cfg root@10.2.2.2:/home/stack
root@10.2.2.2's password: 
system.cfg                                                                                                                                                                                                          100%  565     0.6KB/s   00:00    
ubuntu@auto-it-vnf-uas-0:~$

Hinweis: Das Verfahren zur sanften Stromversorgung von EM/UAS VMs ist unabhängig davon, ob die VMs im Knoten Compute oder OSD-Compute gehostet werden, identisch.

Befolgen Sie die Schritte vom Hauptplatinenaustausch im Compute-Knoten, um diese VMs ordnungsgemäß abzuschalten.

Hauptplatine ersetzen

Die Schritte zum Ersetzen des Motherboards in einem UCS C240 M4 Server können unter folgender Adresse aufgerufen werden: Cisco UCS C240 M4 Server Installations- und Serviceleitfaden

Melden Sie sich mit der CIMC IP-Adresse beim Server an.

Ceph aus dem Servicemodus entfernen

Melden Sie sich beim Knoten OSD Compute an, und verschieben Sie Ceph aus dem Wartungsmodus.

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd unset noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_OK
 monmap e1: 3 mons at {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap e196: 12 osds: 12 up, 12 in
 flags sortbitwise,require_jewel_osds
 pgmap v584954: 704 pgs, 6 pools, 531 GB data, 344 kobjects
 1585 GB used, 11808 GB / 13393 GB avail
 704 active+clean
 client io 12888 kB/s wr, 0 op/s rd, 81 op/s wr

Stellen Sie die VMs wieder her

Fall 1. OSD-Compute-Knoten-Hosts CF, ESC, EM und UAS

Das Verfahren zur Wiederherstellung von CF/ESC/EM/UAS VMs ist unabhängig davon, ob die VMs im Knoten Compute oder OSD-Compute gehostet werden, identisch. Folgen Sie den Schritten aus Fall 2. Computing-Knoten-Hosts CF/ESC/EM/UAS zur Wiederherstellung der VMs.

Fall 2. Automatische Bereitstellung, EM und UAS durch OSD-Computing-Node-Hosts

Auto-Deploy VM wiederherstellen

Wenn die automatische Bereitstellung des virtuellen Systems vom OSPD betroffen war, aber weiterhin "ACTIVE/Running" (AKTIV/Ausführen) anzeigt, müssen Sie es zuerst löschen. Wenn die automatische Bereitstellung nicht beeinträchtigt wurde, fahren Sie mit Recovery der Auto-it-VM fort:

[stack@director ~]$ nova list |grep auto-deploy
| 9b55270a-2dcd-4ac1-aba3-bf041733a0c9 | auto-deploy-ISO-2007-uas-0                                     | ACTIVE | -          | Running     | mgmt=172.16.181.12, 10.1.2.7 [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director ~]$ ./auto-deploy-booting.sh --floating-ip 10.1.2.7 --delete

Nachdem die automatische Bereitstellung gelöscht wurde, erstellen Sie sie erneut mit derselben floatingip-Adresse:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director scripts]$ ./auto-deploy-booting.sh --floating-ip 10.1.2.7

2017-11-17 07:05:03,038 - INFO: Creating AutoDeploy deployment (1 instance(s)) on 'http://10.84.123.4:5000/v2.0' tenant 'core' user 'core', ISO 'default'
2017-11-17 07:05:03,039 - INFO: Loading image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'
2017-11-17 07:05:14,603 - INFO: Loaded image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'
2017-11-17 07:05:15,787 - INFO: Assigned floating IP '10.1.2.7' to IP '172.16.181.7'
2017-11-17 07:05:15,788 - INFO: Creating instance 'auto-deploy-ISO-5-1-7-2007-uas-0'
2017-11-17 07:05:42,759 - INFO: Created instance 'auto-deploy-ISO-5-1-7-2007-uas-0'
2017-11-17 07:05:42,759 - INFO: Request completed, floating IP: 10.1.2.7

Kopieren Sie die Datei Autodeploy.cfg, ISO und die tar-Datei cond_backup von Ihrem Backup-Server, um die VM automatisch bereitzustellen und die CDB-Dateien aus der TAR-Datei wiederherzustellen:

ubuntu@auto-deploy-iso-2007-uas-0:~# sudo -i

ubuntu@auto-deploy-iso-2007-uas-0:#  service uas-confd stop
uas-confd stop/waiting

root@auto-deploy-iso-2007-uas-0:# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd
root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar xvf /home/ubuntu/ad_cdb_backup.tar

cdb/
cdb/O.cdb
cdb/C.cdb
cdb/aaa_init.xml
cdb/A.cdb

root@auto-deploy-iso-2007-uas-0~# service uas-confd start
uas-confd start/running, process 2036

Überprüfen Sie, ob das Paket korrekt geladen wurde, indem Sie frühere Transaktionen überprüfen. Aktualisieren Sie die Datei autodeploy.cfg mit einem neuen Namen für osd-Computing. Siehe Abschnitt - Letzter Schritt: AutoDeploy-Konfiguration aktualisieren.

root@auto-deploy-iso-2007-uas-0:~# confd_cli -u admin -C

Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0

auto-deploy-iso-2007-uas-0#show transaction

                                   SERVICE                                                              SITE
                                   DEPLOYMENT                                                     SITE  TX    AUTOVNF  VNF  AUTOVNF
TX ID          TX TYPE             ID          DATE AND TIME                  STATUS              ID    ID    ID       ID   TX ID
-------------------------------------------------------------------------------------------------------------------------------------
1512571978613  service-deployment  tb5bxb      2017-12-06T14:52:59.412+00:00  deployment-success

auto-deploy-iso-2007-uas-0# exit

Auto-IT VM wiederherstellen

Wenn das Auto-it-virtuelle System vom OSPD betroffen war, aber immer noch als ACTIVE/Running angezeigt wird, müssen Sie es löschen. Wenn die automatische Verarbeitung nicht beeinträchtigt wurde, fahren Sie mit dem nächsten Schritt fort:

[stack@director ~]$ nova list |grep auto-it
| 580faf80-1d8c-463b-9354-781ea0c0b352 | auto-it-vnf-ISO-2007-uas-0                                     | ACTIVE | -          | Running     | mgmt=172.16.181.3, 10.1.2.8 [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director ~]$ ./ auto-it-vnf-staging.sh --floating-ip 10.1.2.8 --delete

Erstellen Sie Auto-IT mithilfe eines automatischen IT-VNF-Staging-Skripts neu:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director scripts]$ ./auto-it-vnf-staging.sh --floating-ip 10.1.2.8

2017-11-16 12:54:31,381 - INFO: Creating StagingServer deployment (1 instance(s)) on 'http://10.84.123.4:5000/v2.0' tenant 'core' user 'core', ISO 'default'
2017-11-16 12:54:31,382 - INFO: Loading image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'
2017-11-16 12:54:51,961 - INFO: Loaded image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'
2017-11-16 12:54:53,217 - INFO: Assigned floating IP '10.1.2.8' to IP '172.16.181.9'
2017-11-16 12:54:53,217 - INFO: Creating instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'
2017-11-16 12:55:20,929 - INFO: Created instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'
2017-11-16 12:55:20,930 - INFO: Request completed, floating IP: 10.1.2.8

Laden Sie das ISO-Image neu. In diesem Fall ist die Auto-IT-IP-Adresse 10.1.2.8. Das Laden dauert einige Minuten:

[stack@director ~]$ cd images/5_1_7-2007/isos

[stack@director isos]$ curl -F file=@usp-5_1_7-2007.iso http://10.1.2.8:5001/isos
{                                                   
  "iso-id": "5.1.7-2007"
}

to check the ISO image:

[stack@director isos]$ curl http://10.1.2.8:5001/isos

{                                       
  "isos": [
    {
      "iso-id": "5.1.7-2007"
    }
  ]
}

Kopieren Sie die Dateien "VNF system.cfg" aus dem OSPD Auto-Deploy-Verzeichnis in Auto-IT VM:

[stack@director autodeploy]$ scp system-vnf* ubuntu@10.1.2.8:.

ubuntu@10.1.2.8's password:
system-vnf1.cfg                                                                                               100% 1197     1.2KB/s   00:00
system-vnf2.cfg                                                                                               100% 1197     1.2KB/s   00:00

ubuntu@auto-it-vnf-iso-2007-uas-0:~$ pwd

/home/ubuntu
ubuntu@auto-it-vnf-iso-2007-uas-0:~$ ls
system-vnf1.cfg  system-vnf2.cfg

Hinweis: Das Wiederherstellungsverfahren von EM und UAS VM ist unabhängig davon, ob das virtuelle System im Compute- oder OSD-Computing gehostet wird, identisch. Folgen Sie den Schritten unter Motherboard im Compute-Knoten ersetzen, um diese VMs ordnungsgemäß abzuschalten.

Ersetzen der Hauptplatine im Controller-Knoten

Controller-Status überprüfen und Cluster in Servicemodus setzen

Melden Sie sich vom OSPD-System beim Controller an, und prüfen Sie, ob die PCs in einem guten Zustand sind. Alle drei Controller Online und Galera zeigen alle drei Controller als Master an.

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec 4 00:46:10 2017 Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: redis-master [redis]
 Masters: [ pod1-controller-2 ]
 Slaves: [ pod1-controller-0 pod1-controller-1 ]
 ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2
 my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0

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

Aktivieren Sie den Wartungsmodus für den Cluster:

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec 4 00:48:24 2017 Last change: Mon Dec 4 00:48:18 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Node pod1-controller-0: standby
Online: [ pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod1-controller-1 pod1-controller-2 ]
 Stopped: [ pod1-controller-0 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod1-controller-1 pod1-controller-2 ]
 Slaves: [ pod1-controller-0 ]
 ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: redis-master [redis]
 Masters: [ pod1-controller-2 ]
 Slaves: [ pod1-controller-1 ]
 Stopped: [ pod1-controller-0 ]
 ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2
 my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Hauptplatine ersetzen

Die Schritte zum Ersetzen des Motherboards in einem UCS C240 M4 Server können unter folgender Adresse aufgerufen werden: Cisco UCS C240 M4 Server Installations- und Serviceleitfaden

Melden Sie sich mit der CIMC IP-Adresse beim Server an.

Cluster-Status wiederherstellen

Melden Sie sich bei dem betroffenen Controller an, und entfernen Sie den Standby-Modus, indem Sie den Standby-Modus festlegen. Überprüfen Sie, ob der Controller mit Cluster online ist und Galera alle drei Controller als Master anzeigt. Dies kann einige Minuten dauern.

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster unstandby

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec 4 01:08:10 2017 Last change: Mon Dec 4 01:04:21 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: redis-master [redis]
 Masters: [ pod1-controller-2 ]
 Slaves: [ pod1-controller-0 pod1-controller-1 ]
 ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2
 my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

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

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	22-Aug-2018	Erstveröffentlichung

Beiträge von Cisco Ingenieuren

Padmaraj Ramanoudjam and
Cisco Advanced Services
Partheeban Rajagopal
Cisco Advanced Services

Ersetzen Sie die Hauptplatine im Ultra-M UCS 240M4 Server - vEPC.

Download-Optionen

Inklusive Sprache

Informationen zu dieser Übersetzung

Inhalt

Einführung

Hintergrundinformationen

Abkürzungen

Workflow des MoP

Austausch der Hauptplatine im Ultra-M-Setup

Austausch des Motherboards im Computing-Knoten

Identifizieren der im Compute-Knoten gehosteten VMs

Graceful Power Aus

Fall 1. Computing-Knoten-Hosts nur SF VM

Fall 2. Computing-Knoten-Hosts CF/ESC/EM/UAS

Hauptplatine ersetzen

Stellen Sie die VMs wieder her

Fall 1. Computing-Knoten-Hosts nur SF VM

Fall 2. Computing-Knoten-Hosts für UAS, ESC, EM und CF

Hauptplatinenaustausch im OSD-Computing-Knoten

Ceph im Servicemodus aktivieren

Identifizieren der im Osd-Compute-Knoten gehosteten VMs

Graceful Power Aus

Fall 1. OSD-Compute-Knoten-Hosts CF/ESC/EM/UAS

Fall 2. Automatische Bereitstellung/Auto-It/EM/UAS durch OSD-Compute-Node-Hosts

Backup des CDB der automatischen Bereitstellung

Backup System.cfg von Auto-IT

Hauptplatine ersetzen

Ceph aus dem Servicemodus entfernen

Stellen Sie die VMs wieder her

Fall 1. OSD-Compute-Knoten-Hosts CF, ESC, EM und UAS

Fall 2. Automatische Bereitstellung, EM und UAS durch OSD-Computing-Node-Hosts

Auto-IT VM wiederherstellen

Ersetzen der Hauptplatine im Controller-Knoten

Controller-Status überprüfen und Cluster in Servicemodus setzen

Hauptplatine ersetzen

Cluster-Status wiederherstellen

Revisionsverlauf

Beiträge von Cisco Ingenieuren

War dieses Dokument hilfreich?

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.