Solucionando problemas no ambiente de serviços de cluster do DB2

Antes de iniciar

Introdução

O IBM DB2 pureScale Feature for Enterprise Server Edition oferece tecnologia de armazenamento em cluster que ajuda a entregar alta disponibilidade e escalabilidade excepcional transparente para aplicativos, e oferece a melhor arquitetura para a plataforma distribuída. O DB2 pureScale Feature permite que o banco de dados continue o processamento durante indisponibilidades não planejadas e fornece capacidade quase ilimitada para qualquer carga de trabalho transacional. O ajuste de escala de seu sistema é simplesmente uma questão de conectar um host e emitir dois comandos simples. A arquitetura com base em cluster de disco compartilhado do DB2 pureScale Feature também ajuda a reduzir os custos por meio do uso eficiente de recursos do sistema.

O DB2 pureScale Feature combina vários componentes de software estreitamente integrados, que são instalados e configurados automaticamente ao implementar o DB2 pureScale Feature. Você interage com componentes como o gerenciador de cluster do DB2 e os serviços de cluster do DB2 por meio das visualizações e comandos de administração do DB2, como db2instance, db2icrt, db2iupdte db2cluster . A ferramenta db2cluster também fornece opções para resolução de problemas e determinação de problema. Adicionalmente, as mensagens que são geradas pelos subsistemas do gerenciador de cluster do DB2 são uma excelente fonte de informações para determinação de problema. Por exemplo, cada um dos gerenciadores de recurso das classes de recurso usadas por serviços de cluster do DB2 gravam informações de status em seus arquivos de log. Os arquivos de log do db2diag também fornecem informações úteis. Frequentemente, mensagens nos arquivos de log do db2diag explicam o motivo de uma falha e aconselham sobre como resolvê-la.

Os serviços de cluster do DB2 são capazes de manipular automaticamente a maioria das falhas em tempo de execução. No entanto, há tipos específicos de falhas que requerem que você tome ações para resolver as falhas. Por exemplo, o cabo de energia poderá ser desligado do host ou um cabo de rede poderá ser desconectado. Se os serviços de cluster do DB2 não puderem resolver a falha automaticamente, um campo de alerta será definido para notificar o DBA de que ocorreu um problema que requer atenção. Os DBAs podem ver o alerta quando verificarem o status da instância do DB2, como mostrado posteriormente.

Entendimento do modelo de recurso do DB2 pureScale Feature

O modelo de recurso da Versão 9.8 do DB2 pureScale Feature difere do modelo de recurso usado em uma instância de HA DB2 nos ambientes de banco de dados de uma e várias partições da Versão 9.7. Para obter informações adicionais sobre instâncias do HA DB2 em versões do DB2 anteriores ao 9.8 DB2 pureScale Feature, consulte os links de informações de histórico na seção Recursos no final do tutorial.

O novo modelo de recurso implementado na Versão do 9.8 DB2 pureScale Feature é necessário para representar cluster caching facilities (CFs) e o sistema de arquivos em cluster compartilhado.

Em uma instância de dados compartilhados do DB2 pureScale, um CF preenche a função principal, que contém os dados atualmente ativos para a instância de dados compartilhada. O segundo CF mantém uma cópia das informações pertinentes para recuperação imediata da função principal.

O novo modelo de recurso permite que o IBM Tivoli® System Automation for Multiplatforms (Tivoli SA MP) automatize adequadamente o movimento da função principal no caso de falha do nó principal do CF.

Os serviços de cluster do DB2 incluem três componentes principais:

• Gerenciador do cluster: Tivoli SA MP, que inclui Reliable Scalable Cluster Technology (RSCT)
• Sistema de arquivos em cluster compartilhado: IBM General Parallel File System (GPFS)
• Administração do cluster do DB2: comandos e visualizações de administração do DB2 para gerenciar e monitorar o cluster

Os serviços de cluster do DB2 fornecem a infraestrutura essencial para que a instância de dados compartilhados esteja altamente disponível e para fornecer failover automático e reiniciar assim que a instância tiver sido criada.

Os elementos do cluster do DB2 são representações de entidades que são monitoradas e cujas mudanças de status são gerenciadas por serviços de cluster do DB2. Para fins desse tutorial, endereçaremos três tipos de elementos do cluster do DB2:

• Hosts: Um host pode ser uma máquina física, uma LPAR (partição lógica de uma máquina física) ou uma máquina virtual.
• Membros do DB2: Um membro do DB2 é o mecanismo de processamento principal e normalmente reside em seu host inicial. O host inicial de um membro do DB2 é o nome do host que foi fornecido como o local do membro quando ele foi adicionado à instância de dados compartilhada do DB2. Um membro do DB2 tem um único host inicial. Membros do DB2 podem aceitar conexões de clientes somente quando estiverem em execução em seu host inicial.
• Cluster caching facilities (CFs): O cluster caching facility (CF) é um aplicativo de software gerenciado pelos serviços de cluster do DB2 que fornece serviços operacionais internos para uma instância de dados compartilhada do DB2.

Não há necessariamente um mapeamento um-para-um entre elementos do cluster do DB2 e os recursos e grupos de recursos do gerenciador do cluster subjacente.

Entendimento sobre como o DB2 pureScale Feature manipula falhas automaticamente

Quando uma falha ocorre na instância do DB2 pureScale, os serviços de cluster do DB2 automaticamente tentam reiniciar os recursos com falha. Quando e onde a reinicialização ocorre depende de diferentes fatores, como o tipo de recurso que apresentou falha e o ponto no ciclo de vida do recurso no qual a falha ocorreu.

Se uma falha de software ou de hardware em um host causar falha em um membro do DB2, os serviços de cluster do DB2 automaticamente reiniciarão o membro. Os membros do DB2 podem ser reiniciados no mesmo host (reinicialização local) ou, se ele falhar, em um host diferente (reinicializa do membro em modo de reinicialização simples. Reiniciar um membro em outro host é chamado de failover.

A reinicialização de membro inclui reinicializar processos do DB2 com falha e realizar recuperação de falha de membro (desfazer ou reaplicar transações do log) para recuperar quaisquer transações em andamento e liberar quaisquer bloqueios mantidos por elas. A reinicialização de membro também garante que páginas atualizadas foram gravadas no CF.

Quando um membro é reinicializado em um host diferente em modo de reinicialização simples, recursos mínimos são usados no novo host (que é o host inicial de outro membro do DB2). Um membro em execução em modo de reinicialização simples não processa novas transações, porque sua única finalidade é realizar a recuperação de falha de membro. Os bancos de dados no membro com falha são recuperados para um ponto de consistência o mais rapidamente possível. Isto permite que outros membros ativos acessem e alterem objetos de banco de dados que estavam bloqueados pelo membro encerrado anormalmente. Todas as transações em andamento do membro com falha são recuperadas e todos os bloqueios que estavam retidos no momento do encerramento anormal do membro são liberados. Apesar de o membro não aceitar novas transações, ele permanece disponível para resolução de transações em dúvida. Quando um membro do DB2 tiver realizado failover para um novo host, a capacidade total de processamento do cluster completo é reduzida temporariamente. Quando o host inicial estiver ativo e disponível novamente, o membro do DB2 realiza fail back automaticamente para o host inicial e o membro do DB2 é reiniciado em seu host inicial. A capacidade de processamento do cluster é restaurada assim que o membro do DB2 tiver realizado fail back e reinicializado em seu host inicial. Transações em todos os outros membros do DB2 não são afetadas durante o processo de failback.

1 de 11 | Próximo

Comentários

Voltar para parte superior

Índice

• Antes de iniciar
• Gerenciamento do ambiente de cluster para o DB2 pureScale Feature
• Cenário 1: Falha de membro e reinicialização em seu host inicial, com logs comentados
• Cenário 2: Failover e failback de membro (cenário do cabo desconectado), com logs comentados
• Cenário 3: Controle do Cluster Caching Facility (CF)
• Conclusão
• Apêndice A: Privilégios de acesso necessários para ler rastreios dos gerenciadores de recursos
• Informações de segundo plano
• Agradecimentos
• Recursos
• Sobre os autores

---

1 de 11 | Próximo