Clusters e tipos de clusters

Cluster, esse termo está ficando cada vez mais comuns em bate papos de DBAs e administradores, afinal é a tecnologia de ponta pensando-se em alta disponibilidade (HA High Availability), ainda mais lidando na disponibilidade de ambientes críticos. O conceito de cluster é você ter ambientes homogêneos ,isto é, contendo o mesmo hardware, arquitetura, software e atualização. Cluster poderá ser utilizado para escalonar sistemas, fornecer um melhor desempenho e ainda sobreviver falhas. Os tipos de cluster estão relacionados ao tipo de armazenamento que é feito.

Estarei dando foco nesse artigo sobre os tipos de clusters disponíveis e suas aplicações. Segue abaixo os tipos de clusters:

• Cluster não compartilhado (Shared Nothing Architecture).
  
• Arquitetura de compartilhamento de discos (Shared disk architecture).
  
• Arquitetura de compartilhamento de recursos (Shared everything architecture).
  

 

Todos os tipos de clusters apresentados são usados em tecnologias diferentes e para diferentes tipos de aplicações.

Funcionalidade	Cluster não compartilhado	Arquitetura de compartilhamento de discos	Arquitetura de compartilhamento de recursos
Discos/ Compartilhamento	Os donos dos discos não compartilham informação entre os nos ao mesmo tempo.	Os donos dos discos são geralmente os nos do cluster. E em caso de falha o conteúdo de um disco e copiado para outro.	O compartilhamento e feito a nível disco para todos os nos, ou seja, todos os nos conseguem fazer a escrita/leitura de todos os discos.
Numero de nós	Usualmente o numero de nos é muito grande.	Normalmente 2 nos fazem parte desse cluster, com um deles trabalhando em contingenciamento.	2 ou mais nos dependendo da configuração de arquitetura. Nessa arquitetura é limitado apenas pelo licenciamento do cluster.
Particionamento de informação	Nós podem acessar apenas dados pertencentes ao seu nó. Relação de 1 para 1.	Não necessário particionamento, já que a arquitetura foi criada para o acesso completo da informação.	Não necessário particionamento, já que a arquitetura foi criada para o acesso completo da informação.
Coordenador client	Servidor externo ou qualquer membro do grupo	Não requer coordenador, o outro nos de contingência só é usando em caso de failover.	Não requer coordenador, qualquer um pode acessar a informação.
Escalabilidade	Altamente escalavel, mas é limitada a quantidade de nós individuais.	Escalabilidade limitada devido as limitações no hardware utilizado.	Escalabilidade infinita devido a quantidade de nós independentes e compartilhamento de recursos.
Acesso de escrita	Cada nó é pode escrever apenas na sua instancia. Uma instancia não pode escrever em discos de outra instancia.	Um no pode escrever em todos os discos, mas somente um por vez.	Todos os nos podem escrever em todos os discos limitados apenas pelo controlador de recursos de escrita (lock manager control)
Carga de balanciamento (Load Balancing)	Não é possível	Não é possível	Possui perfeita carga de balanciamento.
Particionamento da aplicação	Requer em toda a aplicação.	Não é requerimento, mas quando ativado é apenas para um nó (No ativo)	Não necessário.
Adicionar novos nós	Não é possível	É possível mas apenas 1 no estará disponível por vez.	É possível. O conceito é baseado nessa idéia de acionamento de novos membros e prover maior disponibilidade.
Capacidade de falhas (failover)	Não há failover devido 1 no acessar seus discos devidos, e não prover acesso a outros discos disponíveis em outras instancias.	Poderá reverter o nó ativo com um script automático ou a transição dos servidores manuais.	Provem toda e qualquer garantia, sua arquitetura foi construída para a alta disponibilidade removendo assim perigos no contingenciamento de recursos.
I/O	Escrita normal.	Escrita normal.	A escrita/leitura é controlada pelo DLM (Data Locker Manager) e pelo Controlador de Cluster.
Falhas de um no	As informações providas pelo cluster que falhou ficaram indisponíveis.	As informações momentaneamente ficaram indisponíveis para utilização, até o outro nó assumir o controle.	As conexões no no danificado é distribuída entre os nos restantes e toda a informação é disponibilizada novamente. Não há perdas e nem falhas todas são transparentes para a aplicação.
Adicionar nó (disponibilidade)	Requer completa reorganização da arquitetura.	É possível a adição de novos nós, mas a adição não resolverá em nada, devido a mesma oferecer uma disponibilidade que já existem.	Podem ser removidos e adicionados novos nós com os bancos de dados online sem necessidade de parada no ambiente. Após a conclusão de adição do novo nó é feito o balanciamento automáticamente.
Exemplos	IBM SP2, Informix Online XPS, Microsoft Cluster Server, etc.	ServiceGuard, Veritas Cluster Server, etc.	Oracle RAC, Oracle Parallel Server, etc.

Obs. Tabela acima foi extraída do livro de Oracle RAC 10G da Oracle Press e traduzida.

Horário de Verão – Impactos em banco de dados

Sabado (22/10/2008) houve a mudança de horários, ajustando o relógio para +1 hora, ou seja, as 0hs todos os relógios deverão ser ajustado para 01:00:00 da manhã. Muitos profissionais a quais trocamos informações sobre isso acharam que essa mudança no sistema operacional não reflete problemas no banco de dados.

Um dos ambientes a qual eu administro, sofreu impacto, o banco de dados não foi aprovado o shutdown/startup devido o horário apenas avançar, não gerando assim maiores problemas. Não foi bem o que aconteceu. Esse banco de dados é um Oracle 10G release 2.4 rodando em Red Hat E/S 4.3. Os problemas encontrados foram:

1. Listener na porta 1521 encontrava-se com intermitência de horário, mostrando randomicamente o horário antigo e novo. Uma verdadeira coisa de louco :P
   
2. Os registros no alert log estavam sendo gravados com o horário antigo.
   

A primeira solução foi reinicializar os serviços de listener, fazendo apenas o reload dos listeners mas ainda assim o horário continuava instável. Foi realizado, portanto um STOP/START de todos eles, e com isso o horário se manteve estável, mas o horário apresentado era incorreto. A solução então foi fazer um shutdown do banco de dados, após sincronização de bases de dados de contingências com o ultimo redo, foi realizado shutdown da base primaria e a mesma retornou com sucesso.

Em conversa com outros DBAs outros problemas a qual ocorreram foi:

1. Linux Suse 10 – Apresentou problemas na crontab durante os processos de adiantamento de horário. A solução foi reinicializar os serviços atrelados a cron.
   
2. Windows – A Microsoft sempre adianta o horário de verão, nessa virada por exemplo o adiantamento foi de 3 dias. Devido a preocupação de diversos administrador a opção de alteração automática para horário de verão e desabilitada. No dia da virada mesmo com o horário certo o Oracle estava apresentando horário incorreto, isso se deu devido o botão de atualização automática estar desabilitado.
   

Ufá, nunca vi um horário de verão dar tantos problemas. Devemos sempre nos precaver desses "detalhes", pois uma inserção errada, pode causar um transtorno muito grande dentro de uma corporação. Muito obrigado e até a próxima.

ASM – Conceitos, Arquitetura e Gerenciamento – Parte 1/2

ASM - Vantagens

1. É capaz de identificar melhor o nivel de RAID para cada tipo de arquivo do banco de dados
   
2. Gerencia melhor o espaço alocado e a forma com a qual ela é armazenada
   
3. Idêntico em todas as plataformas
   

Arquitetura ASM

Uma instancia RDBMS é uma instancia padrão de banco de dados. Definir esse parametro como ASM iniciará uma instancia do gerenciamento automático, que é bastante diferente.

Os discos ASM precisam ser dispositivos puros, sem um sistema de arquivos, mas não precisam ser dispositivos reais. Elem podem ser discos, partições de um disco ou volumes lógicos gerenciados por um LVM.

Você pode usar o ASM para arquivos do banco de dados, e não para o seu diretório inicial do Oracle nem para nenhuma finalidade. (Pergunta bem comum quando você irá prestar o OCP 1z0-043).

 
 

Processos dentro do ASM

Um dos principais processo encontrados no ASM é o RBAL
coordena o equilibrio e o ARB faz o stripping e o espelhamento da informação. O processo RBAL abre os discos ASM, o qual é localizado através da instancia ASM.

Não é necessário informar à instancia RDBMS o nome da instancia ASM, pois ela se registra com o serviço de Cluster Synchronization o seu nome e os nomes dos Grupos de disco ASM. Permite a instancia do processo ASMB localizar a instancia ASM que está gerenciando esses grupos, interrogando o serviço de Cluster Synchronization.

Arquivos armazenados no ASM

Por ser uma pergunta fundamental para quem está querendo adquirir essa solução deixei ou até mesmo estudando para o exame OCP.

1. ControlFile
   
2. Arquivos de Parametro de inicializacao
   
3. Logs de Redo On-Line
   
4. Logs de Redo Archived
   
5. Arquivo de dados
   
6. TempFiles
   
7. Conjunto de backup do RMAN
   
8. Copias imagens do RMAN
   
9. Logs de FlashBack
   
10. AutoBackup do ControlFile
    
11. Arquivo de dump do Data Pump
    

O ASM não gerencia os arquivos binarios do Oracle, logs de alertas, arquivos de trace e arquivos de senha

 

Obs.

striping = escrita simultanea => Desempenho
mirroring = espelhamento => tolerancia a erros

 
 

Parametros para o ASM

instance_type - precisa ser ASM para uma instance ASM <Default = RDBMS>
instance_name - Nome da instancia prefixado no inicio com + Ex. +ORCL
asm_power_limit - Controla os recursos a serem usados para operações de reequilíbrio
asm_diskstring - Lista de discos Ex: C:/,D:/,E:
asm_diskgroups - São os grupos de discos a serem montados durante a inicializacao <Default = NULL>

Exemplo Windows:

instance_name='+asm'
instance_type='asm'
asm_diskstring='\\.\*:'
asm_diskgroup=dgroupA,dgroupB
background_dump_dest='d:\oracle\admin\dump\asm'

 Exemplo Linux:

instance_name='+asm'
instance_type='asm'
asm_diskstring='/dev/md2','/dev/md3','/dev/md4','/dev/md5'
asm_diskgroup=dgroupA,dgroupB
remote_login_passwordfile=exclusive

IMPORTANTE:

Se uma instancia RDBMS falhar, a instancia ASM não será afetada.
Se uma instancia ASM falhar, as instancias RDBMS irão abortar.

Com isso finalizo a primeira parte do ASM, na próxima sessão irei abordar os tópicos abaixo:

1. Criando a instancia ASM passo a passo
   
2. Tipos de redundância do ASM
   
3. Tipos de espelhamento do ASM
   
4. ASM e RMAN
   
5. Administração do ASM
   
6. Conclusão
   

Obrigado e até a próxima.