Introduzione
Questo documento descrive le funzionalità relative al database DME (Data Management Engine) (DB) introdotte in Unified Computing System Manager (UCSM) 3.1.3a release.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- Software UCSM versione 3.1.3a
- Fabric Interconnect (FI) serie 6200 e modelli 6332
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
DME è il componente centrale dell'architettura software UCSM che contiene le informazioni sullo stato del sistema. Le informazioni sono archiviate in
il dispositivo FI di archiviazione locale sotto forma di database incorporato noto come DME DB.
L'integrità dei dati nel database può danneggiarsi a causa di un errore del dispositivo hardware di archiviazione. Con UCSM 3.1.3a, molte nuove funzioni
sono stati aggiunti per rendere UCSM più resiliente utilizzando il controllo periodico dello stato del database, il ripristino senza problemi del database danneggiato e la protezione dei dati tramite un backup automatico del database DME.
Funzioni di verifica dello stato del database DME UCSM
Controllo periodico dello stato del database
UCS Manager avvia il controllo di integrità del database a intervalli periodici per convalidare l'integrità dei dati.
Il sistema consente inoltre agli utenti di eseguire manualmente il controllo di integrità e verificare l'integrità del database.
Verifica configurazione predefinita
Per impostazione predefinita, il controllo dello stato viene eseguito ogni 12 ore per visualizzare lo stato corrente. Utilizzare i seguenti comandi:
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 #
Modificare l'intervallo
Sebbene sia possibile modificare l'intervallo di tempo o disabilitare il controllo di integrità, si consiglia di non apportare modifiche alla configurazione predefinita.
Attenzione: È consigliabile non modificare questi valori rispetto a quelli predefiniti
Nell'esempio, l'intervallo viene modificato da 12 ore a 48 ore.
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
Per disattivare il controllo dello stato, impostare il valore su zero.
Esegui manualmente il controllo di integrità
Per verificare il controllo dello stato del database, è possibile eseguire questi comandi. Se sul terminale non viene stampato alcun messaggio, il DB è in buone condizioni.
UCS # scope system
UCS /system # start-db-check
UCS /system* # commit-buffer
Inoltre, qualsiasi messaggio di errore verrà registrato nel file di log FI DME primario (parte del pacchetto di supporto tecnico UCSM).
[prt:executeHealthCheck] Health Check complete with no corruption
Questo comando consente di verificare ulteriormente lo stato del database:
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
Danneggiamento del database: errore a livello utente e meccanismo di ripristino
Se UCSM rileva un danneggiamento nel database durante il controllo di integrità, genera messaggi di errore.
Un errore di livello INFO viene generato quando si verifica una singola occorrenza e se il danneggiamento si è verificato più di una volta, vengono registrati gli errori di livello PRINCIPALE e occorre intraprendere ulteriori azioni per contattare Cisco TAC. Raccogliere un pacchetto di supporto tecnico.
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
Meccanismo di recupero
UCSM risolve automaticamente il danneggiamento senza alcun effetto sul traffico dei servizi o del piano dati, sovrascrive il DB dalla memoria o copia il DB corretto da FI peer.
| Evento di danneggiamento |
Meccanismo di ripristino del sistema |
| FI primario |
Il database viene recuperato dalla struttura informazioni di gestione in memoria ( MIT ) |
| FI subordinato |
Il file di database viene recuperato da FI primario |
Reimposta conteggio danneggiamenti
Il danneggiamento del database persiste finché non viene eliminato manualmente. Ad esempio, se l'hardware FI è stato sostituito in base a ulteriori indagini per risolvere il problema, è possibile eseguire questo comando per reimpostare il conteggio degli errori di danneggiamento.
ucs-A # scope system
ucs-A /system # set mgmt-db-check-policy reset-corruption-count yes
ucs-A /system* # commit-buffer
Backup periodico
Per ottimizzare la protezione dei dati, UCSM esegue ogni due settimane il backup completo della configurazione UCSM (DME DB) che può essere utilizzato a scopo di ripristino.
Inoltre, il controllo dell'integrità del database viene convalidato in modo che il backup includa la configurazione da uno stato valido.
Il file di backup dello stato completo viene salvato nella directory /workspace/backup di ogni FI.
UCS # connect local-mgmt
UCS(local-mgmt)# dir backup/
1 1823454 Apr 28 14:53:23 2017 internalBackup.1493391132.tgz
Modifica intervallo processo di backup
La frequenza del processo di backup può essere modificata da 1 a 60 giorni. Come mostrato nell'esempio, il valore è stato modificato in 28 giorni.
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 #
Informazioni correlate
Feedback