De que se trata o artigo:
Veremos as melhores práticas para a configuração do ambiente Oracle RAC, conheceremos o motivo dessa plataforma ter o potencial para resolver diversos problemas de performance e alta disponibilidade, e citaremos as principais causas dos fracassos de projetos dessa natureza, geralmente associados ao seu planejamento e à sua implementação.
Para que serve:
Evitar as armadilhas escondidas em um projeto de instalação do Oracle RAC e assim resguardar seu investimento, com a certeza da satisfação plena dos usuários dos sistemas de informática.
Em que situação o tema útil:
Empresas de médio e grande porte que necessitam de uma infraestrutura de banco de dados confiável, com escalabilidade, alta performance e disponibilidade,requisitos básicos para rodar grandes aplicativos corporativos de missão crítica.
Resumo DevMan
O Oracle Real Application Cluster (RAC) é uma solução de alta disponibilidade (High-Availability – HA) que fornece a capacidade de um cluster ser ativo em todos os seus nós. Neste sentido, neste artigo veremos as melhores práticas para a configuração do ambiente Oracle RAC, conheceremos o motivo dessa plataforma ter o potencial para resolver diversos problemas de performance e alta disponibilidade, e citaremos as principais causas dos fracassos de projetos dessa natureza, geralmente associados ao seu planejamento e à sua implementação.
O Oracle Real Application Cluster (RAC) é uma solução de alta disponibilidade (High-Availability – HA) que fornece a capacidade de um cluster ser ativo em todos os seus nós. Comparada à antiga solução de ativo/passivo, já seria uma boa razão para implementá-lo em sua empresa. Contudo, o Oracle RAC acrescenta certo grau de complexidade, aumento dos custos com a necessidade de aquisição de licenças, hardwares de rede e storage, além do treinamento das equipes de suporte.
O RAC não é um produto recomendado para todos os ambientes, isso é um fato. Mas em muitos casos poderá ser a solução de vários problemas. No entanto, para alcançar os objetivos pretendidos é importante saber configurá-lo. Muitas dificuldades nesse ambiente estão relacionadas à sua configuração inadequada. Outras são mais complexas, como problemas na lógica em aplicativos que somente aparecerão quando em produção.
No entanto, seguindo as recomendações deste artigo, será possível resolver diversas questões de performance e alta disponibilidade. Na maioria das vezes, não será necessário o conhecimento de detalhes dos intrincados subsistemas do Oracle RAC ou mudança no código da aplicação. Segue abaixo as principais questões que devem ser respondidas em um projeto de RAC:
- Como a carga de trabalho se comportará com a queda de um nó do cluster? Geralmente configuramos dois ou três servidores (nós);
- Como administrar o custo adicional do storage compartilhado, redes redundantes e com maior vazão (throughput)? Para evitar que exista um ponto único de falha, além do investimento em hardware, será preciso esforço maior para gerência e teste da solução;
- Como treinar as equipes de suporte de sistemas e banco de dados? Para que se obtenham as vantagens prometidas pelo RAC é preciso ter uma equipe capacitada para desenho e gerência da solução. Saber configurar o storage também não é uma tarefa trivial;
- Como tirar vantagens do Linux da Oracle? Essa iniciativa em lançar o Oracle Enterprise Linux (Unbreakable) ajuda no sentido de ter um suporte mais adequado, pois evita a situação de empurra-empurra, ou como é chamado em inglês: “blame storm” (veja a Nota DevMan 1) ou tempestade de culpas – famosas discussões sobre aonde se encontra o problema e quem é o culpado. Por exemplo: se o erro se encontra no sistema operacional ou no banco de dados.
O Oracle na versão 10g já suporta a ORACLE_HOME compartilhada para reduzir o custo de se administrar o ambiente. A ORACLE_HOME é a variável que define o ambiente onde rodam os programas do Oracle, contém subdiretórios para os executáveis do Oracle e arquivos de rede.
Nota DevMan 1. Blame Storm
O termo “blame storm” é usado para definir as reuniões onde se procuram ou se apontam os culpados para os problemas ocorridos. Este termo foi propositadamente copiado da frase usada em negócios “Brain Storm”, ou tempestade de ideias, onde os participantes das reuniões priorizam ideias e sugestões que levem a soluções para problemas ou aprimoramento dos processos.
Como se trata de subsistemas que envolvem outras especialidades, além das do DBA, é importante incluir na fase de planejamento do projeto as diversas áreas envolvidas e certificar-se de que todos os aspectos do projeto estão claros." [...] continue lendo...
