Einleitung
In diesem Dokument werden Funktionen im Zusammenhang mit der Data Management Engine (DME)-Datenbank (DB) beschrieben, die in der Version 3.1.3a von Unified Computing System Manager (UCSM) eingeführt wurde.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- UCSM-Softwareversion 3.1.3a
- Fabric Interconnect (FI) der Serie 6200 und 6332
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
DME ist die zentrale Komponente der UCSM-Softwarearchitektur und enthält Systemstatusinformationen. Die Informationen werden gespeichert auf
das lokale Speicher-FI-Gerät in Form einer eingebetteten Datenbank, die als DME DB bezeichnet wird.
Die Datenintegrität in der Datenbank kann aufgrund eines Ausfalls des Speicherhardware-Geräts beschädigt werden. UCSM 3.1.3a bietet zahlreiche neue Funktionen
wurden hinzugefügt, um UCSM ausfallsicherer zu machen. Dies wird durch regelmäßige DB-Statusprüfungen, die nahtlose Wiederherstellung beschädigter DB und den Datenschutz durch ein automatisches Backup der DME-DB erreicht.
Funktionen der UCSM DME-Datenbankintegritätsprüfung
Regelmäßige Statusüberprüfung der Datenbank
Der UCS Manager startet in regelmäßigen Abständen eine Integritätsprüfung der DB, um die Integrität der Daten zu validieren.
Das System ermöglicht es Benutzern auch, die Integritätsprüfung manuell durchzuführen und die DB-Integrität zu überprüfen.
Standardkonfiguration überprüfen
Standardmäßig wird die Integritätsprüfung alle 12 Stunden durchgeführt. Verwenden Sie dazu die folgenden Befehle:
UCS # scope system
UCS /system # show mgmt-db-check-policy detail
Management Database Integrity Check Policy:
Health Check Interval (hours): 12
Last Integrity Check Time: 2017-05-07T14:42:47.019
Internal Backup Interval (days): 14
Last Internal Backup Time: 2017-04-28T14:52:12.648
UCS /system #
Intervall ändern
Sie können zwar das Zeitintervall ändern oder die Integritätsprüfung deaktivieren, es wird jedoch dringend empfohlen, die Standardkonfiguration nicht zu ändern.
Vorsicht: Es wird dringend empfohlen, diese Standardwerte nicht zu ändern.
In diesem Beispiel wird das Intervall von 12 Stunden auf 48 Stunden geändert.
UCS /system # set mgmt-db-check-policy health-check-interval 48
UCS /system* # commit-buffer
UCS /system # show mgmt-db-check-policy detail
Management Database Integrity Check Policy:
Health Check Interval (hours): 48
Last Integrity Check Time: 2017-05-07T14:42:47.019
Internal Backup Interval (days): 14
Last Internal Backup Time: 2017-04-28T14:52:12.648
Um die Integritätsprüfung zu deaktivieren, legen Sie den Wert auf 0 fest.
Führen Sie die Integritätsprüfung manuell aus.
Zur Überprüfung der DB-Integritätsprüfung können Sie diese Befehle ausführen. Wenn keine Nachricht auf dem Terminal ausgegeben wird, ist DB fehlerfrei.
UCS # scope system
UCS /system # start-db-check
UCS /system* # commit-buffer
Darüber hinaus werden alle Fehlermeldungen in der primären FI DME-Protokolldatei protokolliert (Teil des UCSM-Technologie-Support-Pakets).
[prt:executeHealthCheck] Health Check complete with no corruption
Mit diesem Befehl können Sie den DB-Status weiter überprüfen:
UCS # scope system
UCS /system # show mgmt-db
Management Database Status:
Fabric Id Corrupted Count Last Occurrence Time
--------- ----------------------- --------------------
A 0 1970-01-01T00:00:00.000
B 0 1970-01-01T00:00:00.000
DB-Beschädigung - Fehler- und Wiederherstellungsmechanismus auf Benutzerebene
Wenn UCSM während der Integritätsprüfung eine Beschädigung der DB erkennt, generiert es Fehlermeldungen.
Ein Fehler auf INFO-Ebene wird generiert, wenn ein einziger Vorfall auftritt. Wenn die Beschädigung mehrmals aufgetreten ist, werden schwerwiegende Fehler protokolliert, und Sie müssen weitere Maßnahmen ergreifen und sich an das Cisco TAC wenden. Sammeln Sie ein Technologiesupportpaket.
ucs /system # show fault
Severity Code Last Transition Time ID Description
--------- -------- ------------------------ -------- -----------
Info F1899 2017-04-28T01:09:23.332 263649 Management database corruption detected and recovered on Fabric Interconnect B. Number of corruption events: 1. Last corruption event timestamp: 2017-04-28T01:09:23.332
Major F1900 2017-05-02T00:52:07.846 263651 High number of management database corruption events on Fabric Interconnect A. Number of corruption events: 3. Last corruption event timestamp: 2017-05-02T01:06:06.387
Wiederherstellungsmechanismus
UCSM löst die Beschädigung automatisch ohne Auswirkungen auf den Service- oder Datenverkehr auf Datenebene auf, überschreibt die DB aus dem Speicher oder kopiert die gute DB aus dem Peer-FI.
| Korruptionsfall |
Systemwiederherstellungsmechanismus |
| Primärer FI |
Datenbank wird im Speicher-Management-Informationsbaum (MIT) wiederhergestellt |
| Nachrangige FI |
Datenbankdatei wird vom primären FI abgerufen |
Korruptionszahl zurücksetzen
Die Beschädigung der DB besteht so lange fort, bis sie manuell gelöscht wird. Wenn beispielsweise FI-Hardware aufgrund weiterer Untersuchungen zur Behebung der Beschädigung ersetzt wurde, können Sie diesen Befehl ausführen, um die Anzahl der Beschädigungen zurückzusetzen.
ucs-A # scope system
ucs-A /system # set mgmt-db-check-policy reset-corruption-count yes
ucs-A /system* # commit-buffer
Periodisches Backup
Um den Datenschutz zu maximieren, erstellt UCSM alle zwei Wochen eine vollständige Sicherung der UCSM-Konfiguration (DME DB), die für Wiederherstellungszwecke verwendet werden kann.
Darüber hinaus wird die DB-Integritätsprüfung validiert, sodass die Sicherung die Konfiguration in einem einwandfreien Zustand beinhaltet.
Die vollständige Sicherungsdatei wird im Verzeichnis "/workspace/backup" jedes FI gespeichert.
UCS # connect local-mgmt
UCS(local-mgmt)# dir backup/
1 1823454 Apr 28 14:53:23 2017 internalBackup.1493391132.tgz
Intervall für Sicherungsauftrag ändern
Die Häufigkeit des Sicherungsauftrags kann von 1 auf 60 Tage geändert werden. Wie in diesem Beispiel gezeigt, haben wir den Wert auf 28 Tage geändert.
UCS # scope system
UCS /system # set mgmt-db-check-policy internal-backup-interval 28
UCS /system* # commit-buffer
UCS /system # show mgmt-db-check-policy detail
Management Database Integrity Check Policy:
Health Check Interval (hours): 24
Last Integrity Check Time: 2017-05-10T10:35:24.909
Internal Backup Interval (days): 28
Last Internal Backup Time: 2017-04-28T14:52:12.648
UCS /system #
Zugehörige Informationen
Feedback