Category: Clusterware

Olá amigos!

Depois de uma longa pausa, continuamos hoje a série de artigos que aborda a arquitetura do Oracle Clusterware.

No post de hoje, veremos sobre as redes utilizadas no Oracle Clusterware: pública e privada.

  • Pública:
    • É nessa rede que o endereço IP virtual (VIP) será inicializado;
    • As conexões realizadas através de Oracle Net (Client Oracle) ou JDBC deverão apontar para os IP’s VIP, para que haja transparência no momento do failover;
    • Em caso de falha no nó 1, o VIP será inicializado no nó 2;
    • Enquanto houver pelo menos um servidor dentro do Cluster, todos os VIP’s estarão online neste servidor;
    • Quando o servidor que sofreu o problema inicializar a camada do Cluster, o CRS tentará subir o VIP nesse servidor, por 5 tentativas, e caso não consiga, outro servidor do Cluster ficará com esse VIP online;
    • Os IP’s VIP deverão ser registrados no DNS, pois os usuários devem se conectar o hostname do VIP ao invés do endereço IP. Isso é necessário pois quando ocorre o failover, o Listener do nó que permanecerá online, reencaminhará ao Client Oracle a string de conexão do nó 2 contendo a informação do hostname do VIP, e não do endereço IP, nesse momento, a estação de trabalho deverá ter a capacidade de resolver o nome no endereço IP. Seja através de DNS ou através do arquivo hosts na estação local.
  • Privada (InterConnect):
    • É a conexão privada entre os nós do cluster;
    • O uso de cabo cross-over é permitido tecnicamente, mas não suportado pela Oracle;
    • É a mídia do Cache-Fusion: global cache;
    • Deve ter baixa latência e alta largura de banda (gigabit ethernet é recomendado);
    • Deve ser utilizado em switchs gigabit;
    • Não deve estar no mesmo switch (ou VLAN) que a rede corporativa (pública);
    • Recomendado o uso de tecnologias para garantir maior disponibilidade. No Linux, há o bond networking, onde se utiliza 2 placas de rede físicas, com 2 switches, e é criada uma interface de rede virtual, para que a a rede InterConnect nunca fique indisponível, pois se ela ficar, o nó sofrerá reboot, já que ela faz parte da arquitetura do CSS. Essa tenologia de bonding networki é chamada de network teaming em outros sistemas operacionais.

Pessoal, essa foi a forma mais simples que eu tinha de explicar sobre as redes utilizadas no Clusterware. No próximo artigo, começaremos uma série que tratará sobre a administração do Clusterware.

Abraços!

Vinicius







----------------------------------------------------------------------------

Copyright:

Este site e todo o conteúdo aqui publicado pertence ao Blog ViniciusDBA.com.br e possui seus respectivos direitos autorais.

O Conteúdo desde Blog não deve ser publicado, distribuído ou transmitido sem autorização prévia de seu autor.

Oracle e seus produtos são marcas registradas da Oracle Corporation® (http://www.oracle.com) Todo o material aqui encontrado é mantido sem ajuda financeira e mantém como propriedade de seu fundador/escritor.

Disclaimer:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
As opiniões publicadas neste blog (http://www.viniciusdba.com.br) são pessoais e não necessariamente representam a visão da Oracle.


Toda informação aqui encontrado é oferecida através do uso do bom senso e boa fé do seus leitores e não deve ser considerada como material oficial da Oracle Corporation (http://www.oracle.com).

O Autor (e contribuidores) não considera as informações aqui como oficiais e/ou permitidas para redistribuição. Ao utilizar o site http://www.viniciusdba.com.br o leitor deve entender e aceitar que as informações aqui encontradas são de direitos autorais do Autor e contribuidores.

O blog http://www.viniciusdba.com.br não faz revisão de conteúdo publicado por outros como comentários bem como posts em grupo de usuários ou portais.

Seus autores não necessariamente concordam ou apoiam opiniões de seus leitores.

ESTE É UM SITE INDEPENDENTE E NÃO REPRESENTA A ORACLE CORPORATION® (http://www.oracle.com) EM NENHUM SENTIDO. AS OPINIÕES E CONTEÚDOS AQUI ENCONTRADOS NÃO POSSUEM RELAÇÃO COM A VISÃO DA ORACLE CORPORATION®. ESTE SITE NÃO POSSUI NENHUM APOIO OU PATROCINIO DA ORACLE CORPORATION®.

Olá amigos!

Continuamos hoje a série de artigos que aborda a arquitetura do Oracle Clusterware.

No post de hoje, veremos sobre os principais arquivos na arquitetura do Oracle Clusterware: Voting Disk e OCR.

  • Voting Disk
    • Deve estar em storage compartilhado entre os nós: raw devices (até o Kernel 2.5.x), block devices, ou um cluster file system suportado;
    • Ele também é chamado de Disco de Quórum (Quorum Disk);
    • Pode ou não ser multiplexado: 1, 2 ou 3 cópias (é possível colocar mais de 3 cópias);
    • Sua utilidade ocorre quando há falha na rede de InterConnect, onde, todos os nós do Cluster precisam “votar” num lugar acessível a todos os nós (storage), o nó que tiver o menor número de votos como disponível (available) é eleito a sair do cluster (node eviction), e o processo de CSS faz o restart abrupto do nó;
    • O backup deve ser executado manualmente com o usuário root (em sistemas Unix/Linux), o utilitário dd é utilizado. Veremos na série sobre Administração do Clusterware como realizar essa tarefa;
    • Sempre que houver adição ou remoção de nós no cluster, é recomendado fazer o backup. Isso significa que um backup pode ser armazenado por muitos meses, que mesmo assim, continuará válido;
    • Se um nó perder acesso aos Voting Disks (problemas na fibra, controladora, etc.), o nó será reiniciado imediatamente, pois faz parte da arquitetura do CSS, e, sendo assim, qualquer componente da arquitetura do CSS que falhar, o servidor será reiniciado imediatemente.
    • A figura abaixo exemplifica o funcionamento do Voting Disk:

Na figura acima, podemos observar que num cluster de 3 nós, todos os nós se enxergam através do que chamamos de heart-beat (batida de coração), que é feita pela rede InterConnect. Essa informação é registrada no Voting Disk informando que todos os nós estão ativos no cluster.

Na figura acima, observamos que o nó 3 sofreu algum problema de conexão com a rede privada (InterConnect). O CSS realiza a votação, e o nó 1 “diz” que enxerga os nós 1 e 2; o nó 2 “diz” que enxerga os nós 1 e 2; e o nó 3 “diz” que enxerga somente o nó 3. Dessa forma, o nó 1 tem 2 votos como disponível, o nó 2 tem 2 votos como disponível, e o nó 3 tem apenas 1 voto com disponível. Logo, o nó 3 será evitado e será reiniciado imediatamente.

OK, o funcionamento do Voting Disk é fácil de ser entendido com um cluster de 3 ou mais nós. Mas, aí vem a pergunta, e no caso de um cluster de 2 nós, onde o nó 2 sofrerá o problema de conexão com a rede InterConnect. Como ficarão os votos dentro do Voting Disk? Ficarão da seguinte forma: o nó 1 “diz” que enxerga somente o nó 1, e o nó 2 “diz” que enxerga somente o nó 2. E aí, quem deverá sair do cluster temporariamente?

De acordo com o Metalink Note (RAC: Frequently Asked Questions [ID 220970.1]), o nó que será o “sobrevivente” no cluster será aquele que entrou primeiro no cluster, isto é, supondo que o nó 2 tenha entrado no cluster no dia 05/05/2010 às 0:01 e o nó 1 tenha entrado no cluster no dia 05/05/2010 às 0:02, o nó 2 será o nó sobrevivente no cluster, e o nó 1 será reiniciado.

  • OCR (Oracle Cluster Registry)
    • Deve estar em storage compartilhado entre os nós: raw devices (até o Kernel 2.5.x), block devices, ou um cluster file system suportado;
    • Ele também é chamado arquivo de controle (control file) do Cluster, sendo o centro das informações no cluster;
    • Pode ou não ser multiplexado: 1 ou 2 cópias;
    • Ele armazena informações como:
      • Lista dos nós, bancos de dados, instâncias, listeners, ASM, etc -> todos esses componentes são chamados de recursos;
      • Status esperado de cada um dos recursos do cluster;
    • A perda implica em parada do ambiente;
    • Os backups são executados automaticamente a cada 4 horas, e tem a seguinte política de retenção:
      • Armazena 1 backup a cada 4 horas no dia, totalizando 6 backups num intervalo de 24 horas;
      • Armazena 1 backup diário (sempre 1 backup do dia anterior, mas nunca o backup de 2 dias anteriores ou mais);
      • Armazena 1 backup semanal;
    • Além do backup automático, também é possível realizar um backup lógico.

Bom pessoal, como vocês puderam ver, esses arquivos são a espinha dorsal do cluster. Sem eles, o cluster não entra em funcionamento. Também foi possível observar que para um DBA perder um backup do OCR, tem que estar muito desatento mesmo, pois com backup a cada 4 horas, é praticamente “impossível” perder um backup desses.

Novamente, espero que esse post seja útil!

No próximo artigo, da semana que vem, veremos sobre as redes utilizadas no cluster: pública e privada (InterConnect).

Um abraço!

Vinicius







----------------------------------------------------------------------------

Copyright:

Este site e todo o conteúdo aqui publicado pertence ao Blog ViniciusDBA.com.br e possui seus respectivos direitos autorais.

O Conteúdo desde Blog não deve ser publicado, distribuído ou transmitido sem autorização prévia de seu autor.

Oracle e seus produtos são marcas registradas da Oracle Corporation® (http://www.oracle.com) Todo o material aqui encontrado é mantido sem ajuda financeira e mantém como propriedade de seu fundador/escritor.

Disclaimer:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
As opiniões publicadas neste blog (http://www.viniciusdba.com.br) são pessoais e não necessariamente representam a visão da Oracle.


Toda informação aqui encontrado é oferecida através do uso do bom senso e boa fé do seus leitores e não deve ser considerada como material oficial da Oracle Corporation (http://www.oracle.com).

O Autor (e contribuidores) não considera as informações aqui como oficiais e/ou permitidas para redistribuição. Ao utilizar o site http://www.viniciusdba.com.br o leitor deve entender e aceitar que as informações aqui encontradas são de direitos autorais do Autor e contribuidores.

O blog http://www.viniciusdba.com.br não faz revisão de conteúdo publicado por outros como comentários bem como posts em grupo de usuários ou portais.

Seus autores não necessariamente concordam ou apoiam opiniões de seus leitores.

ESTE É UM SITE INDEPENDENTE E NÃO REPRESENTA A ORACLE CORPORATION® (http://www.oracle.com) EM NENHUM SENTIDO. AS OPINIÕES E CONTEÚDOS AQUI ENCONTRADOS NÃO POSSUEM RELAÇÃO COM A VISÃO DA ORACLE CORPORATION®. ESTE SITE NÃO POSSUI NENHUM APOIO OU PATROCINIO DA ORACLE CORPORATION®.

Olá amigos!

Hoje começaremos uma série de artigos onde discutiremos sobre a arquitetura do Oracle Clusterware.

No post de hoje, começaremos a falar dos daemons do Clusterware e de um processo no Linux que é fundamental para a utilização do Clusterware: hangcheck-timer.

Primeiramente, o que são daemons?

Basicamente, daemon é um programa de computador que é executado em background.

Geralmente eles respondem a requisições de rede, atividades de hardware, ou outros programas.

Comumente, o seu nome termina com a letra d, mas isso não é uma regra.

Referência: Wikipédia

Bom, vamos lá. No Oracle Clusterware, há basicamente 3 daemons, todos eles são iniciados com a opção de respawn, que significa que caso o processo termine abruptamente, o processo será reiniciado automaticamente.

O ambiente-base citado para exemplificar sobre os processos é o Red Hat Enterprise Linux.

  • CSSD (Cluster Syncronization Services Daemon)
    • Controla os membros do cluster;
    • Ele ajuda no monitoramento da “saúde dos nós, usando o Voting Disk e o InterConnect;
    • Também é responsável pela sincronização entre as instâncias de ASM e Banco de Dados;
    • É executado com o usuário oracle;
    • Considerado o principal processo no Cluster;
    • Como ele controla os membros do cluster, caso ele falhe abruptamente, o servidor em questão é reiniciado imediatemente.
  • CRSD (Cluster Ready Services Daemon)
    • Principal processo no gerenciamento de alta disponibilidade;
    • Realiza todas as operações de recuperação e gerenciamento da alta disponibilidade, como o gerenciamento do OCR e o gerenciamento dos recursos de aplicação (recursos do cluster);
    • Lê as configurações dos recursos que estão armazenadas no OCR;
    • Se um recurso falhar, tentará reiniciá-lo, até um limite definido pelo parâmetro RESTART_ATTEMPTS, o que geralmente é 5;
    • É executado com o usuário root;
    • Se o processo falhar, ele é automaticamente reiniciado (sem reinício do servidor).
  • EVMD (Event Manager Daemon)
    • Publica os eventos que o CRS cria (exemplo: instância up, instância down, listener up, listener down);
    • É executado com o usuário oracle;
    • Se o processo falhar, ele é automaticamente reiniciado (sem reinício do servidor).

Há também o seguinte daemon no Clusterware:

  • OPROCD (Process Monitor Daemon)
    • Monitora o cluster e fornece I/O fencing (quando um nó apresentar problemas, ele não poderá mais realizar operações de I/O);
    • O I/O fencing é garantido através do reinício imediato do servidor;
    • É executado com o usuário root (é um processo filho do CSSD);
    • Se o processo falhar, o servidor é reiniciado imediatamente;
    • No Linux, usa o hangcheck-timer para verificar a “saúde” do nó.

E também, há o módulo de kernel no Linux:

  • Hangcheck-Timer
    • Módulo do kernel que é lido no momento do boot;
    • Monitora o kernel do Linux em busca de operações longas que podem travar o sistema operacional e afetar a confiabilidade de um nó no RAC;
    • Usa o Time Stamp Counter (TSC) para obter delays previstos, ou então o travamento do nó;
    • O TSC é basicamente, um “ping” no kernel onde utiliza a CPU para fazer isso, portanto, é muito preciso. Caso ocorra delay nesse ping, significa que o nó está travando (hanging);
    • O hangcheck-timer, obviamente, usa um timer, onde se o valor do timer for ultrapassado, o servidor será reiniciado.
    • É usado em TODOS os clusters Oracle Clusterware no 10gR1, 10gR2 e 11gR1;
    • No 10gR2, tem como default, os seguintes parâmetros:
      • hangcheck_tick = 1: define com qual frequência, em segundos, o hangcheck-timer verificará por travamentos no nó;
      • hangcheck_margin = 10: define qual é a margem de erro tolerada, em segundos, antes do hangcheck_timer reiniciar o nó;
      • hangcheck_reboot = 1: define se o hangcheck_timer reiniciará o nó ou não. Se o valor estiver definido como 1, o nó será reiniciado caso esteja “travando”, se estiver diferente deste valor, o nó não será reiniciado.
    • O nó será reiniciado se o valor de hangcheck_tick + hangcheck_margin for atingido, isso é, no 10gR2, 11 segundos.

Bom pessoal, é isso, espero que esse post seja útil!

No próximo artigo, na próxima semana, veremos sobre os arquivos vitais para o funcionamento do Clusterware: OCR e Voting Disk.

Um abraço!

Vinicius







----------------------------------------------------------------------------

Copyright:

Este site e todo o conteúdo aqui publicado pertence ao Blog ViniciusDBA.com.br e possui seus respectivos direitos autorais.

O Conteúdo desde Blog não deve ser publicado, distribuído ou transmitido sem autorização prévia de seu autor.

Oracle e seus produtos são marcas registradas da Oracle Corporation® (http://www.oracle.com) Todo o material aqui encontrado é mantido sem ajuda financeira e mantém como propriedade de seu fundador/escritor.

Disclaimer:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
As opiniões publicadas neste blog (http://www.viniciusdba.com.br) são pessoais e não necessariamente representam a visão da Oracle.


Toda informação aqui encontrado é oferecida através do uso do bom senso e boa fé do seus leitores e não deve ser considerada como material oficial da Oracle Corporation (http://www.oracle.com).

O Autor (e contribuidores) não considera as informações aqui como oficiais e/ou permitidas para redistribuição. Ao utilizar o site http://www.viniciusdba.com.br o leitor deve entender e aceitar que as informações aqui encontradas são de direitos autorais do Autor e contribuidores.

O blog http://www.viniciusdba.com.br não faz revisão de conteúdo publicado por outros como comentários bem como posts em grupo de usuários ou portais.

Seus autores não necessariamente concordam ou apoiam opiniões de seus leitores.

ESTE É UM SITE INDEPENDENTE E NÃO REPRESENTA A ORACLE CORPORATION® (http://www.oracle.com) EM NENHUM SENTIDO. AS OPINIÕES E CONTEÚDOS AQUI ENCONTRADOS NÃO POSSUEM RELAÇÃO COM A VISÃO DA ORACLE CORPORATION®. ESTE SITE NÃO POSSUI NENHUM APOIO OU PATROCINIO DA ORACLE CORPORATION®.