Einführung
Dieses Dokument beschreibt Funktionen im Zusammenhang mit Data Management Engine (DME) Database (DB), die in der Version Unified Computing System Manager (UCSM) 3.1.3a eingeführt wurden.
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
- UCSM-Softwareversion 3.1.3a
- Fabric Interconnect (FI)-Modelle der Serien 6200 und 6332
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Hintergrundinformationen
DME ist die zentrale Komponente der UCSM-Softwarearchitektur, die Informationen zum Systemstatus enthält. Die Informationen werden 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 der Speicherhardware beschädigt werden. Mit der Version UCSM 3.1.3a stehen zahlreiche neue Funktionen zur Verfügung.
werden hinzugefügt, um die Ausfallsicherheit von UCSM zu erhöhen. Hierzu werden regelmäßige DB-Statusprüfungen, die nahtlose Wiederherstellung der beschädigten DB und der Datenschutz durch eine automatische Sicherung der DME-DB verwendet.
UCSM DME Database Health Check-Funktionen
Periodische Integritätsprüfung der Datenbank
Der UCS Manager initiiert in regelmäßigen Abständen eine Integritätsprüfung der DB, um die Integrität der Daten zu überprüfen.
Das System ermöglicht es Benutzern außerdem, 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, um den aktuellen Status mithilfe der folgenden Befehle anzuzeigen:
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 Statusprüfung deaktivieren, es wird jedoch dringend empfohlen, keine Änderungen an der Standardkonfiguration vorzunehmen.
Vorsicht: Es wird dringend empfohlen, diese Werte nicht von der Standardeinstellung 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 Null.
Führen Sie die Integritätsprüfung manuell aus.
Zur Überprüfung der DB-Statusprüfung können Sie diese Befehle ausführen. Wenn keine Nachricht auf dem Terminal gedruckt wird, ist die DB gesund.
UCS # scope system
UCS /system # start-db-check
UCS /system* # commit-buffer
Darüber hinaus wird jede Fehlermeldung in der primären FI DME-Protokolldatei (Teil des UCSM-Technologieunterstützungspakets) protokolliert.
[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-Korruption - Fehler- und Wiederherstellungsmechanismus auf Benutzerebene
Wenn UCSM eine Beschädigung in der DB während der Statusprüfung erkennt, werden Fehlermeldungen generiert.
Ein INFO-Level-Fehler wird generiert, wenn ein einziger Vorfall auftritt und wenn die Beschädigung mehr als einmal aufgetreten ist, MAJOR-Level-Fehler protokolliert werden. Sie müssen weitere Maßnahmen ergreifen und sich an das Cisco TAC wenden. Sammeln Sie ein Technologieunterstützungspaket.
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 Beeinträchtigung des Services- oder Datenverkehrs auf der Datenebene auf, überschreibt die DB aus dem Speicher oder kopiert die gute DB aus dem Peer-FI.
| Korruptionsereignis |
Systemwiederherstellungsmechanismus |
| Primäres FI |
Die Datenbank wird in der Speichermanagement Information Tree (MIT) wiederhergestellt. |
| Untergeordnete FI |
Die Datenbankdatei wird aus dem primären FI abgerufen |
Korruptionszählung zurücksetzen
Die DB-Korruption besteht so lange, bis sie manuell behoben wird. Wenn beispielsweise FI-Hardware aufgrund weiterer Untersuchungen zur Behebung der Beschädigung ausgetauscht wurde, können Sie diesen Befehl ausführen, um die Anzahl der Korruptionsfehler zurückzusetzen.
ucs-A /system # set mgmt-db-check-policy reset-corruption-count yes
ucs-A /system* # commit-buffer
Periodische Sicherung
Zur Maximierung der Datensicherheit nimmt UCSM alle zwei Wochen ein vollständiges Backup der UCSM-Konfiguration (DME DB) vor, das zu Wiederherstellungszwecken verwendet werden kann.
Darüber hinaus wird die DB-Integritätsprüfung validiert, sodass die Datensicherung auch die Konfiguration aus einem guten Zustand umfasst.
Die vollständige Sicherungsdatei wird im Verzeichnis /workspace/backup der 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 Sicherungsaufträge ä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