Crie uma solução de failover baseada na arquitetura Oracle RAC e AccelStor Shared-Nothing

Um número considerável de aplicativos corporativos e sistemas de virtualização possui seus próprios mecanismos para criar soluções tolerantes a falhas. Em particular, o Oracle RAC (Oracle Real Application Cluster) é um cluster de dois ou mais servidores de banco de dados Oracle trabalhando juntos para equilibrar a carga e fornecer tolerância a falhas no nível do servidor / aplicativo. Para trabalhar neste modo, é necessário um armazenamento comum, cuja função é geralmente armazenamento.

Como já discutimos em um de nossos artigos , o sistema de armazenamento, apesar da presença de componentes duplicados (incluindo controladores), ainda possui pontos de falha - principalmente na forma de um único conjunto de dados. Portanto, para criar uma solução Oracle com maiores requisitos de confiabilidade, o esquema "N servidores - um armazenamento" deve ser complicado.

Primeiro, é claro, você precisa decidir contra quais riscos estamos tentando garantir. Neste artigo, não consideraremos a proteção contra ameaças como a chegada de um meteorito. Portanto, a criação de uma solução de recuperação de desastre geograficamente dispersa continuará sendo um tópico para um dos seguintes artigos. Aqui, examinamos a chamada solução de recuperação de desastre entre rack, quando a proteção é criada no nível dos gabinetes de servidor. Os próprios armários podem estar localizados na mesma sala ou em diferentes, mas geralmente dentro do mesmo prédio.

Esses gabinetes devem conter todo o conjunto de equipamentos e software necessários para garantir a operação dos bancos de dados Oracle, independentemente do estado do “vizinho”. Em outras palavras, usando a solução de recuperação de desastre Cross-Rack, eliminamos os riscos de falha:

• Servidores de Aplicativos Oracle
• Sistemas de armazenamento
• Sistemas de comutação
• Falha completa de todos os equipamentos no gabinete:
  
  • Falha de energia
  • Falha no sistema de refrigeração
  • Fatores externos (homem, natureza, etc.)

A duplicação de servidores Oracle implica o próprio princípio do Oracle RAC e é implementada através do aplicativo. A duplicação de ferramentas de comutação também não é um problema. Mas a duplicação do sistema de armazenamento não é tão simples.

A opção mais fácil é replicar dados do armazenamento primário para o backup. Síncrono ou assíncrono, dependendo dos recursos de armazenamento. A replicação assíncrona levanta imediatamente a questão de garantir a consistência dos dados com o Oracle. Porém, mesmo se houver integração de software com o aplicativo, em qualquer caso, em caso de acidente no sistema de armazenamento principal, será necessária uma intervenção manual dos administradores para alternar o cluster para o armazenamento de backup.

Uma opção mais complexa são os “virtualizadores” de software e / ou hardware de sistemas de armazenamento, que eliminam problemas com consistência e intervenção manual. Mas a complexidade da implantação e administração subsequente, bem como o custo muito indecente de tais soluções, assusta muitos.

Apenas para cenários como recuperação de desastre entre bastidores, o array All Flash AccelStor NeoSapphire ™ H710 usando a arquitetura Shared-Nothing é perfeito . Este modelo é um sistema de armazenamento duplo usando sua própria tecnologia FlexiRemap® para trabalhar com pen drives. Graças ao FlexiRemap® NeoSapphire ™ H710, ele pode fornecer até 600K de gravação aleatória IOPS @ 4K e 1M + IOPS @ 4K de leitura aleatória, o que é inatingível com o armazenamento clássico baseado em RAID.

Mas a principal característica do NeoSapphire ™ H710 é a execução de dois nós como gabinetes separados, cada um com sua própria cópia dos dados. A sincronização do nó é realizada através da interface externa do InfiniBand. Graças a essa arquitetura, os nós podem se espalhar por diferentes locais, por distâncias de até 100m, fornecendo a solução de recuperação de desastre Cross-Rack. Ambos os nós funcionam completamente no modo síncrono. Do lado do host, o H710 parece um armazenamento comum de controlador duplo. Portanto, nenhuma opção adicional de software e hardware e configurações particularmente complexas precisam ser executadas.

Se você comparar todas as soluções de recuperação de desastre Cross-Rack descritas acima, a versão AccelStor se destacará das demais:

* O AccelStor NeoSapphire ™ ainda é um array All Flash, que por definição não custa “3 copeques”, especialmente porque possui uma reserva de capacidade dupla. No entanto, comparando o custo total da solução com base em soluções similares de outros fornecedores, o custo pode ser considerado baixo.

A topologia para conectar servidores de aplicativos e todos os nós da matriz Flash terá a seguinte aparência:

Ao planejar a topologia, também é altamente recomendável que você duplique os comutadores de gerenciamento e as interconexões do servidor.

A seguir, falaremos sobre a conexão via Fibre Channel. No caso de usar o iSCSI, tudo será o mesmo, ajustado para os tipos de comutadores usados ​​e configurações de matriz ligeiramente diferentes.

Trabalho preparatório na matriz

Antes de começar a usar uma matriz, você deve inicializá-la. Por padrão, o endereço de controle dos dois nós é o mesmo (192.168.1.1). Você precisa se conectar a eles um de cada vez, definir novos endereços de gerenciamento (já diferentes) e configurar a sincronização de horário, após o qual as portas de gerenciamento podem ser conectadas a uma única rede. Depois disso, os nós são combinados em um par de HA atribuindo sub-redes às conexões de Interlink.

Após a conclusão da inicialização, você pode controlar a matriz a partir de qualquer nó.

Em seguida, crie os volumes necessários e publique-os para servidores de aplicativos.

É altamente recomendável que você crie vários volumes para o Oracle ASM, pois isso aumentará o número de destinos para os servidores, o que acabará por melhorar o desempenho geral (mais sobre filas em outro artigo ).

Algumas explicações sobre os modos de operação do array e os processos que ocorrem em situações de emergência

Cada conjunto de dados do nó possui um parâmetro "número da versão". Após a inicialização, é igual e igual a 1. Se, por algum motivo, o número da versão for diferente, sempre haverá sincronização dos dados da versão mais antiga para a mais recente, após o qual o número será alinhado para a versão mais nova, ou seja, isso significa que as cópias são idênticas. Razões pelas quais as versões podem variar:

• Reinicialização agendada de um dos nós
• Um acidente em um dos nós devido a um desligamento repentino (energia, superaquecimento, etc.).
• Conexão quebrada do InfiniBand com incapacidade de sincronizar
• Falha em um dos nós devido à corrupção de dados. Isso já exigirá a criação de um novo grupo de alta disponibilidade e a sincronização completa do conjunto de dados.

De qualquer forma, o nó que permanece on-line aumenta seu número de versão em um, para que, após reconectar-se ao par, sincronize seu conjunto de dados.

Se a conexão for perdida através do link Ethernet, o Heartbeat alternará temporariamente para o InfiniBand e retornará dentro de 10 segundos quando for restaurado.

Configuração do host

Para garantir a tolerância a falhas e aumentar o desempenho, você deve habilitar o suporte MPIO para a matriz. Para fazer isso, adicione linhas ao arquivo /etc/multipath.conf e recarregue o serviço de caminhos múltiplos

Além disso, para que o ASM funcione com o MPIO através do ASMLib, você precisa modificar o arquivo / etc / sysconfig / oracleasm e, em seguida, executar os escândiscos /etc/init.d/oracleasm

Certifique-se de que os discos criados para o Oracle ASM estejam alinhados com o tamanho do bloco com o qual a matriz está trabalhando fisicamente (4K). Caso contrário, poderão ocorrer problemas de desempenho. Portanto, você deve criar volumes com os parâmetros apropriados:

parted / dev / mapper / nome do dispositivo mklabel gpt mkpart primário 2048s verificação 100% alinhada ideal 1

Distribuição de bancos de dados em volumes criados para nossa configuração de teste

Teste de tolerância a falhas

Para fins de demonstração, o HammerDB foi usado para emular a carga OLTP. Configuração do HammerDB:

Como resultado, foi obtido o indicador de 2,1M TPM, que está longe do limite de desempenho do array H710 , mas é o "teto" para a atual configuração de hardware dos servidores (principalmente devido aos processadores) e seu número. O objetivo deste teste ainda é demonstrar a tolerância a falhas da solução como um todo e não atingir o desempenho máximo. Portanto, simplesmente construiremos esse valor.

Teste de falha de um dos nós

Os hosts perderam alguns dos caminhos para a loja, continuando a trabalhar pelos demais com o segundo nó. O desempenho caiu por alguns segundos devido à reestruturação dos caminhos e depois voltou ao normal. Nenhuma interrupção de serviço ocorreu.

Teste de falha do gabinete com todos os equipamentos

Nesse caso, o desempenho também caiu por alguns segundos devido à reestruturação dos caminhos e retornou à metade do valor do indicador original. O resultado foi dividido pela metade do original devido à exclusão da operação de um servidor de aplicativos. A interrupção do serviço também não aconteceu.

Se você precisar implementar uma solução de recuperação de desastre entre rack e tolerante a falhas para Oracle a um custo razoável e com pouco esforço de implantação / administração, trabalhar em conjunto com a arquitetura Oracle RAC e AccelStor Shared-Nothing seria uma das melhores opções. Em vez do Oracle RAC, pode haver qualquer outro software que forneça cluster, o mesmo DBMS ou sistemas de virtualização, por exemplo. O princípio de construir a solução permanecerá o mesmo. E a pontuação final é zero para RTO e RPO.