Acho que quando as pessoas estão projetando a arquitetura Oracle RAC, muitas vezes não pensam na redundância N+1 em seus planos de implementação. Há dois motivos para implementar o Oracle RAC:disponibilidade e escalabilidade. Para os propósitos desta discussão, estou focando apenas no lado da disponibilidade. Se suas implantações de RAC forem apenas por motivos de escalabilidade, este tópico pode não se aplicar a você.

Então, o que é redundância N+1? Simplificando, se você precisar de N unidades de algo, para fins de redundância, você deve ter N + 1 desse item. Vejamos um servidor de banco de dados. Deve ter uma fonte de alimentação. Isso é um requisito. Sem uma fonte de alimentação em funcionamento, o servidor não funcionará. O número mínimo de fontes de alimentação é 1. Se quisermos que este servidor tenha um alto grau de disponibilidade, garantiremos que ele tenha fontes de alimentação N+1 ou, neste caso, fontes de alimentação duplas. Se houver apenas uma fonte de alimentação e ela falhar, leva o servidor com ela. Se tivermos uma fonte de alimentação extra, uma unidade sobressalente, a perda de uma fonte de alimentação não derrubará o servidor com ela. A redundância é uma ótima coisa para se ter e um componente essencial para uma infraestrutura de alta disponibilidade.

Ao projetar um sistema Oracle RAC, o DBA precisa determinar quantos nós são necessários para atender às demandas do usuário final. Se o DBA determinar que 4 nós são necessários e esse cluster RAC deve apresentar características de alta disponibilidade, é vital para o DBA criar um cluster de 5 nós (4+1). Se as demandas de recursos forem suficientes para manter 4 nós ocupados e um nó for perdido, os 3 restantes não poderão acompanhar a carga de trabalho. Se o DBA construir o sistema RAC com capacidade N+1 em mente, a perda de um nó não será percebida pelos usuários finais. Se o DBA construir o cluster RAC sem redundância N+1, a perda de um nó pode ser tão terrível para o desempenho do usuário final que todo o cluster pode ficar inativo. Ao projetar suas implementações de RAC, esforce-se pela redundância N+1.

Lembro-me de dois anos atrás, eu tinha um cluster RAC que perdeu um nó. Sem problemas, ainda tínhamos dois nós disponíveis. Enquanto observava o desempenho dos dois nós restantes, eles pareciam bastante sobrecarregados. Nosso call center começou a receber reclamações. Trabalhei com outros administradores da equipe de TI para que o nó voltasse a funcionar o mais rápido possível, mas isso nem sempre é o caso se o motivo da interrupção estiver relacionado ao hardware e as peças precisarem ser substituídas. Depois que o nó voltou a funcionar, monitorei o desempenho do cluster por semanas depois. Nosso uso cresceu desde que este sistema foi inicialmente projetado. Inicialmente projetamos este sistema com redundância N+1 em mente, mas nosso uso cresceu e N passou de 2 para 3. Nosso cluster atual de 3 nós não era mais N+1 redundante. Então, trabalhei com a gerência para colocar no orçamento do próximo ano fundos suficientes para adquirir um novo nó e garantir que a Oracle fosse licenciada para ele. Durmo muito melhor à noite sabendo que estou de volta à redundância N+1.

Como muitas implementações por aí, meu sistema RAC não é o único recurso de alta disponibilidade integrado à nossa infraestrutura. Esse banco de dados RAC é primário para um banco de dados físico em espera com o Data Guard da Oracle. Estou surpreso ao discutir os bancos de dados RAC standby com outros DBAs Oracle quantos deles não estão pensando em capacidade N+1 para seu standby. O banco de dados em standby físico é minha rede de segurança caso o data center principal esteja indisponível por algum motivo. Já vi muitos DBAs Oracle implementarem uma única instância em espera para um primário RAC de vários nós. Ai! Espero que nunca tenham que falhar. A carga de trabalho de todo o cluster RAC de vários nós sofrerá muito nesse modo de espera de instância única. Assim, ao projetar suas implementações de RAC para o primário e o de espera, considere suas implicações de redundância N+1 no projeto da arquitetura.

Onde eu provavelmente difere de muitas pessoas é que minhas implementações de standby físico não são capazes de N+1, mas sim N. Eu pulo o nó extra redundante para meu standby físico. Por que é que? Puramente de uma perspectiva de custo. Minha espera física é apenas uma rede de segurança. Eu quero que funcione para mim no dia que eu precisar. Mas espero nunca precisar. A reserva física é minha apólice de seguro caso o risco se torne realidade. Para mim, esse “+1” extra no local de espera é excesso de seguro. Posso economizar no hardware físico e no licenciamento da Oracle.

Então, digamos que o dia chegue e eu faça failover para o modo de espera. Perdi minha redundância N+1. Mas quais são as chances de eu perder o data center primário *e* perder um dos nós do meu cluster em espera? Chances bem escassas. A probabilidade de falhas em dois sites ao mesmo tempo é muito pequena. Neste ponto, nossa equipe de TI está avaliando por que nosso data center principal foi perdido e quando é mais provável que possamos retornar nossas operações a essa instalação. Se o data center primário perder toda a sua energia e a concessionária disser que o serviço será restaurado até amanhã, então simplesmente rodaremos no data center em espera, mesmo que tenhamos apenas N nós para o banco de dados RAC lá. No entanto, se o data center principal for destruído por um incêndio, levará muitos meses até que ele volte a funcionar. É neste ponto que preciso planejar obter essa espera física até a redundância N + 1, pois nosso tempo usando essa espera como primária será um período muito mais longo. Então, apressamos o pedido de outro servidor e o adicionamos ao cluster o mais rápido possível. Então eu projeto meu banco de dados RAC standby como N, não N+1 com o objetivo de aumentá-lo para N+1 em pouco tempo se determinarmos que usaremos o standby por um longo período de tempo.

Portanto, há um outro caso especial que eu gostaria de discutir. É aí que o DBA determina que N=1. Para os requisitos de carga de trabalho atuais, um nó é suficiente. Mas queremos ter alta disponibilidade, então projetamos um cluster RAC de dois nós para o banco de dados primário. Agora temos redundância N+1 embutida no primário. Seguindo meu último parágrafo, meu banco de dados standby só precisa de 1 nó. O erro que vejo algumas pessoas cometerem é criar o standby como um banco de dados de instância única. Até agora, a lógica deles faz sentido. O primário é N+1 e o standby é N. Até agora tudo bem. A diferença é que faço do standby um cluster RAC de um nó, não uma implementação de instância única pura. A razão é para o crescimento futuro. Em algum momento, o DBA pode descobrir que N não é mais igual a 1 no primário. O uso cresceu e N precisa ser 2 agora. O DBA deseja aumentar o primário para 3 nós (2+1). Isso é facilmente desativado com tempo de inatividade zero para adicionar um novo nó ao cluster e estender o banco de dados RAC para esse novo nó. Mas não é tão fácil no modo de espera tornar o modo de espera um cluster de 2 nós se esse 1 nó que existe não estiver habilitado para RAC. Se uma espera de instância única pura é tudo o que existe, o DBA precisa descartá-la e movê-la para um cluster de dois nós. Se o DBA teve previsão e instalou o Grid Infrastructure como se o standby físico fosse um cluster de nó único, tudo o que o DBA precisa fazer é adicionar um novo nó, assim como fizeram no lado primário.

Ao projetar suas implementações de RAC, considere garantir que você tenha capacidade N+1 no primário e pelo menos N no modo de espera. Se uma empresa determinar que o standby é muito crítico, ela pode querer implementar N+1 no standby também. Se o DBA determinar que N=1, considere tornar a espera pelo menos um cluster RAC de nó único.