Com a introdução dos Oracle Engineered Systems, o DBA está um pouco mais próximo das decisões de design de infraestrutura e espera-se que tenha pelo menos algumas opiniões sobre os requisitos de design de rede para o banco de dados. Pelo menos é essa a situação em que me encontro :)
Depois de implantar um ODA para teste, encontro-me com a configuração atual:
O controlador de sistema 0 tem a interface vinculada pública (bond0) conectada a um switch de borda típico, um Catalyst 2960 series. Uma interface de gerenciamento (bond1) é conectada a um segundo switch de borda do mesmo tipo.
Da mesma forma, o controlador do sistema 1 tem sua interface pública conectada ao segundo switch, enquanto a interface de gerenciamento está conectada ao primeiro switch.
Dessa forma, se um dos interruptores cair, um operador poderá acessar cada controlador do sistema por meio da interface pública ou de gerenciamento para facilitar o diagnóstico.
No lado da Cisco, os grupos EtherChannel são configurados para as 4 interfaces vinculadas do ODA. Os dois switches são conectados individualmente ao restante da rede, sem links diretos entre os dois.
À primeira vista, isso parece um design razoável, mas quanto mais penso em diferentes cenários de falha, mais perguntas parecem surgir.
Levando em consideração que esses switches do tipo edge não são redundantes em si mesmos, parece bastante importante que o cluster possa lidar com um switch que se torne indisponível devido a uma falha na fonte de alimentação ou um switch que não consiga encaminhar pacotes.
Os clientes do banco de dados (servidores de aplicativos do servidor Zend, neste caso) são conectados de forma semelhante com uma interface vinculada a apenas um dos dois switches. Isso levanta algumas questões em relação ao balanceamento de carga: Do jeito que eu entendo 11gR2 RAC, simplesmente conectar ao endereço SCAN provavelmente permitirá que o cliente percorra o longo caminho até a rede principal e volte por outro switch, o que dificilmente pode ser considerado para ser muito eficiente.
O que acontece se um switch falhar ou parar de encaminhar pacotes? As conexões encontrarão o ouvinte VIP acessível por meio do SCAN? O RAC detectará de alguma forma a falha na rede e moverá o SCAN e o VIP para o controlador do sistema com uma interface pública funcional e acessível? Sinceramente, não consigo ver como seria.
E embora os clientes que percorrem o caminho mais longo pela rede principal e voltem seja aceitável durante um cenário de failover, com certeza seria bom evitá-lo na produção normal.
Tenho certeza de que a Oracle tem uma ideia muito clara de como tudo isso deve funcionar junto, mas infelizmente não vejo tudo com tanta clareza.
É possível obter redundância total com switches edge-class/não redundantes? Podemos de alguma forma adicionar algum controle sobre onde as conexões do cliente são roteadas em situações de produção e failover? Talvez haja uma boa maneira de interconectar os dois switches para permitir o tráfego diretamente entre os clientes em um switch e o ouvinte do banco de dados no outro?
Neste ponto, estou procurando as melhores práticas e considerações fundamentais de design de rede que devem ser aplicadas a uma implementação típica de ODA de alta disponibilidade.
Esperançosamente, isso será útil para qualquer DBA que se depare com a tomada de decisões de design de rede para seu ODA :)
Atualizar:
O ODA é configurado com vínculos na configuração de backup ativo. Acho que isso pode permitir uma configuração em que cada interface no vínculo seja conectada a um comutador diferente, sem nenhuma configuração do lado do comutador.
Alguém sabe se é este o caso?
[root@oma1 ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth2
Acontece que o ODA é configurado de fábrica com vínculos de backup ativo. Eu testei isso para funcionar bem sem nenhuma configuração LACP/EtherChannel do lado do switch, e cada conexão vinculada pode ser dividida em dois switches. Em meus testes, nenhuma falha simulada ou reconfiguração de rede causou mais do que algumas centenas de milissegundos de interrupção de rede.
Isso significa que é possível configurar uma rede frontal redundante isolada para aplicativos da Web usando qualquer switch de camada dois que não seja inerentemente redundante.
Para evitar que as conexões do cliente tomem um longo caminho na rede da empresa e voltem pelo outro switch (e, portanto, tornando a produção dependente desse equipamento), pode-se ter uma VLAN privada que viva apenas nos dois switches de borda e em um tronco EtherChannel entre eles .
Dessa forma, apenas os servidores de aplicativos e o dispositivo de banco de dados existirão nesse segmento de rede virtual.
Não vejo como controlar qual caminho as conexões dos servidores de aplicação levam até os listeners do banco de dados, então o link entre os dois switches terá que ser redundante, senão esse link se torna um único ponto de falha. Isso exclui o uso de switches não gerenciados sem suporte para VLAN e LACP ou STP.
Usando os switches da série Cisco Catalyst 2960, acredito que uma combinação de EtherChannel e Port Fast seria a melhor escolha para uma conexão sólida e independente entre os dois. Eu também usaria o Port Fast nas portas para todas as conexões vinculadas ao ODA e aos servidores de aplicativos.
Como a rede de produção é isolada, seriam necessárias conexões de rede separadas para gerenciamento, backup e conectividade com o restante da rede da empresa.
Naturalmente, para que essa rede de produção frontal seja totalmente autocontida, quaisquer dependências de recursos externos, como DNS ou serviços de autenticação, também devem ser resolvidas. Idealmente, a produção seria capaz de continuar de forma independente, sem levar em consideração quaisquer falhas, manutenção contínua ou interrupções de rede em qualquer outro local do data center ou da rede da empresa.