Introdução
Este documento descreve os recursos relacionados ao banco de dados (DB) do Data Management Engine (DME) introduzidos no Unified Computing System Manager (UCSM) versão 3.1.3a.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- Software UCSM versão 3.1.3a
- Interconexão de estrutura (FI) série 6200 e modelos 6332
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
O DME é o componente central da arquitetura de software do UCSM que armazena informações de estado do sistema. As informações são armazenadas em
o dispositivo de armazenamento local na forma de banco de dados incorporado conhecido como DME DB.
A integridade dos dados no banco de dados pode ser corrompida devido a uma falha no dispositivo de hardware de armazenamento. Com a versão 3.1.3a do UCSM, muitos recursos novos
são adicionados para tornar o UCSM mais resiliente, usando a verificação periódica de integridade do DB, a recuperação transparente de proteção de dados e de bancos de dados corrompidos por um backup automático do DME DB.
Recursos de Verificação de Integridade do Banco de Dados UCSM DME
Verificação periódica da integridade do banco de dados
O UCS Manager inicia a verificação de integridade do BD em intervalos periódicos para validar a integridade dos dados.
O sistema também permite que os usuários executem manualmente a verificação de integridade e verifiquem a integridade do BD.
Verificar a configuração padrão
Por padrão, a verificação de integridade é executada a cada 12 horas, para mostrar o status atual, use estes comandos:
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 #
Alterar o intervalo
Embora você possa modificar o intervalo de tempo ou desativar a verificação de integridade, é altamente recomendável não fazer alterações na configuração padrão.
Caution: É altamente recomendável não alterar esses valores do padrão
Neste exemplo, o intervalo é alterado de 12 para 48 horas.
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
Para desativar a verificação de integridade, defina o valor como zero.
Executar manualmente a verificação de integridade
Para verificar a verificação de integridade do BD, você pode executar esses comandos. Se nenhuma mensagem for impressa no terminal, o DB está em bom estado de saúde.
UCS # scope system
UCS /system # start-db-check
UCS /system* # commit-buffer
Além disso, qualquer mensagem de erro será registrada no arquivo de registro primário do FI DME (parte do pacote UCSM techsupport).
[prt:executeHealthCheck] Health Check complete with no corruption
Esse comando permite verificar ainda mais o status do BD:
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 Corruption - Mecanismo de recuperação e falha no nível do usuário
Se o UCSM detectar corrupção no BD durante a verificação de integridade, ele gerará mensagens de falha.
Uma falha no nível INFO é gerada quando há uma única ocorrência e, se a corrupção tiver ocorrido mais de uma vez, as falhas no nível MAJOR serão registradas e você precisará tomar outras medidas e entrar em contato com o TAC da Cisco. Reúna um pacote de suporte técnico.
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
Mecanismo de recuperação
O UCSM resolve automaticamente a corrupção sem afetar qualquer tráfego de serviços ou plano de dados, sobrescreve o DB da memória ou copia o DB bom do peer FI.
| Evento de Corrupção |
Mecanismo de recuperação do sistema |
| FI primário |
O banco de dados é recuperado da MIT (Management Information Tree, árvore de informações de gerenciamento) na memória |
| FI subordinado |
O arquivo de banco de dados é recuperado do arquivo primário |
Redefinir contagem de corrupções
A corrupção do banco de dados persiste até que seja apagada manualmente. Por exemplo, se o hardware do FI tiver sido substituído com base em investigações adicionais para resolver a corrupção, você poderá executar esse comando para redefinir a contagem de falhas de corrupção.
ucs-A # scope system
ucs-A /system # set mgmt-db-check-policy reset-corruption-count yes
ucs-A /system* # commit-buffer
Backup periódico
Para maximizar a proteção de dados, o UCSM realiza o backup de estado completo da configuração do UCSM (DME DB) a cada duas semanas, que pode ser usado para fins de recuperação.
Além disso, a verificação de integridade do BD é validada para que o backup inclua a configuração a partir de um bom estado.
O arquivo de backup de estado completo é salvo no diretório /workspace/backup de cada FI.
UCS # connect local-mgmt
UCS(local-mgmt)# dir backup/
1 1823454 Apr 28 14:53:23 2017 internalBackup.1493391132.tgz
Alterar intervalo de trabalho de backup
A frequência da tarefa de backup pode ser alterada de 1 para 60 dias. Como mostrado neste exemplo, alteramos o valor para 28 dias.
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 #
Informações Relacionadas
Feedback