Um número considerável de aplicativos empresariais e sistemas de virtualização possuem seus próprios mecanismos para construir soluções tolerantes a falhas. Especificamente, 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, você precisa de um armazenamento compartilhado, que geralmente é um sistema de armazenamento.
Como já discutimos em um de nossos , o próprio sistema de armazenamento, apesar da presença de componentes duplicados (incluindo controladores), ainda apresenta pontos de falha - principalmente na forma de um único conjunto de dados. Portanto, para construir uma solução Oracle com maiores requisitos de confiabilidade, o esquema “N servidores – um sistema de armazenamento” precisa ser complicado.
Primeiro, é claro, precisamos decidir contra quais riscos estamos tentando nos segurar. Neste artigo, não consideraremos a proteção contra ameaças como “chegou um meteorito”. Portanto, a construção de uma solução de recuperação de desastres geograficamente dispersa continuará a ser um tema para um dos artigos seguintes. Aqui veremos a chamada solução de recuperação de desastres Cross-Rack, quando a proteção é construída no nível dos gabinetes dos servidores. Os próprios armários podem estar localizados na mesma sala ou em salas diferentes, mas geralmente dentro do mesmo prédio.
Esses gabinetes deverão conter todo o conjunto necessário de equipamentos e softwares que permitirão o funcionamento dos bancos de dados Oracle independente do estado do “vizinho”. Ou seja, utilizando a solução de recuperação de desastres Cross-Rack, eliminamos os riscos de falha:
- Servidores de aplicativos Oracle
- Sistemas de armazenamento
- Sistemas de comutação
- Falha completa de todos os equipamentos do gabinete:
- Recusa de energia
- Falha no sistema de refrigeração
- Fatores externos (humanos, natureza, etc.)
A duplicação de servidores Oracle implica o próprio princípio de funcionamento do Oracle RAC e é implementada através de uma aplicação. A duplicação de instalações de comutação também não é um problema. Mas com a duplicação do sistema de armazenamento nem tudo é tão simples.
A opção mais simples é a replicação de dados do sistema de armazenamento principal para o sistema de backup. Síncrono ou assíncrono, dependendo das capacidades do sistema de armazenamento. Com a replicação assíncrona, surge imediatamente a questão de garantir a consistência dos dados em relação ao Oracle. Mas mesmo que haja integração do software com a aplicação, em qualquer caso, em caso de falha no sistema de armazenamento principal, será necessária a intervenção manual dos administradores para mudar o cluster para armazenamento de backup.
Uma opção mais complexa são os “virtualizadores” de armazenamento de software e/ou hardware que eliminarão problemas de consistência e intervenção manual. Mas a complexidade da implantação e administração subsequente, bem como o custo indecente de tais soluções, assusta muitos.
A solução de array AccelStor NeoSapphire™ All Flash é perfeita para cenários como recuperação de desastres Cross-Rack usando arquitetura Shared-Nothing. Este modelo é um sistema de armazenamento de dois nós que usa tecnologia proprietária FlexiRemap® para funcionar com unidades flash. Graças a NeoSapphire™ H710 é capaz de fornecer desempenho de até 600K IOPS@4K de gravação aleatória e 1M+ IOPS@4K de leitura aleatória, o que é inatingível ao usar sistemas de armazenamento clássicos baseados em RAID.
Mas a principal característica do NeoSapphire™ H710 é a execução de dois nós na forma de casos separados, cada um com sua própria cópia dos dados. A sincronização dos nós é realizada através da interface externa InfiniBand. Graças a esta arquitetura, é possível distribuir nós para diferentes locais a uma distância de até 100m, proporcionando assim uma solução de recuperação de desastres Cross-Rack. Ambos os nós operam de forma totalmente síncrona. Do lado do host, o H710 parece um sistema de armazenamento comum com controlador duplo. Portanto, não há necessidade de executar quaisquer opções adicionais de software ou hardware ou configurações particularmente complexas.
Se compararmos todas as soluções de recuperação de desastres Cross-Rack descritas acima, a opção do AccelStor se destaca visivelmente das demais:
Arquitetura de nada compartilhado AccelStor NeoSapphire™
Sistema de armazenamento “virtualizador” de software ou hardware
Solução baseada em replicação
Disponibilidade
Falha no servidor
Sem tempo de inatividade
Sem tempo de inatividade
Sem tempo de inatividade
Falha no switch
Sem tempo de inatividade
Sem tempo de inatividade
Sem tempo de inatividade
Falha no sistema de armazenamento
Sem tempo de inatividade
Sem tempo de inatividade
O tempo de inatividade
Falha em todo o gabinete
Sem tempo de inatividade
Sem tempo de inatividade
O tempo de inatividade
Custo e complexidade
Custo da solução
Baixo*
Alto
Alto
Complexidade de implantação
Baixo
Alto
Alto
*AccelStor NeoSapphire™ ainda é um array All Flash, que por definição não custa “3 copeques”, especialmente porque tem uma reserva de capacidade dupla. Porém, ao comparar o custo final de uma solução baseada nele com outras similares de outros fornecedores, o custo pode ser considerado baixo.
A topologia para conectar servidores de aplicativos e todos os nós do array Flash será semelhante a esta:
Ao planejar a topologia, também é altamente recomendável duplicar switches de gerenciamento e interconectar servidores.
Aqui e mais adiante falaremos sobre conexão via Fibre Channel. Se você usar iSCSI, tudo será igual, ajustado para os tipos de switches usados e configurações de array ligeiramente diferentes.
Trabalho preparatório na matriz
Equipamentos e software usados
Especificações de servidor e switch
Componentes
descrição
Servidores Oracle Database 11g
Dois
Sistema operacional de servidor
Oracle Linux
Versão do banco de dados Oracle
11g (RAC)
Processadores por servidor
Duas CPUs Intel® Xeon® E16-5 v2667 de 2 núcleos a 3.30 GHz
Memória física por servidor
128GB
Rede FC
FC de 16 Gb/s com multicaminhos
FC HBA
Emulex Lpe-16002B
Portas públicas dedicadas de 1 GbE para gerenciamento de cluster
Adaptador Ethernet Intel RJ45
Comutador FC de 16 Gb/s
Brocado 6505
Portas privadas dedicadas de 10 GbE para sincronização de dados
Intel X520
Especificação de array totalmente flash AccelStor NeoSapphire™
Componentes
descrição
Sistema de armazenamento
Modelo de alta disponibilidade NeoSapphire™: H710
Versão da imagem
4.0.1
Número total de unidades
48
Tamanho da unidade
1.92TB
Tipo de unidade
SSD
Portas de destino FC
16 portas de 16 Gb (8 por nó)
Portas de gerenciamento
O cabo Ethernet de 1 GbE conectado aos hosts por meio de um switch Ethernet
Porta de pulsação
O cabo Ethernet de 1 GbE conectado entre dois nós de armazenamento
Porta de sincronização de dados
Cabo InfiniBand de 56 Gb/s
Antes de poder usar um array, você deve inicializá-lo. Por padrão, o endereço de controle de ambos os nós é o mesmo (192.168.1.1). Você precisa conectar-se a eles um por um e definir novos endereços de gerenciamento (já diferentes) e configurar a sincronização de horário, após a qual as portas de gerenciamento podem ser conectadas a uma única rede. Posteriormente, os nós são combinados em um par HA atribuindo sub-redes para conexões Interlink.
Após a conclusão da inicialização, você poderá gerenciar o array a partir de qualquer nó.
A seguir, criamos os volumes necessários e os publicamos nos servidores de aplicativos.
É altamente recomendável criar vários volumes para o Oracle ASM, pois isso aumentará o número de destinos para os servidores, o que acabará melhorando o desempenho geral (mais sobre filas em outro tópico). ).
Configuração de teste
Nome do volume de armazenamento
Tamanho do volume
Data01
200GB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Refazer01
100GB
Refazer02
100GB
Refazer03
100GB
Refazer04
100GB
Refazer05
100GB
Refazer06
100GB
Refazer07
100GB
Refazer08
100GB
Refazer09
100GB
Refazer10
100GB
Algumas explicações sobre os modos de operação do array e os processos que ocorrem em situações de emergência
O conjunto de dados de cada nó possui um parâmetro “número de versão”. Após a inicialização inicial, é igual e igual a 1. Se por algum motivo o número da versão for diferente, os dados são sempre sincronizados da versão mais antiga para a mais nova, após o que o número da versão mais nova é alinhado, ou seja, isso significa que as cópias são idênticas. Razões pelas quais as versões podem ser diferentes:
- Reinicialização agendada de um dos nós
- Um acidente em um dos nós devido a um desligamento repentino (fonte de alimentação, superaquecimento, etc.).
- Conexão InfiniBand perdida com incapacidade de sincronizar
- Uma falha em um dos nós devido à corrupção de dados. Aqui você precisará criar um novo grupo HA e concluir a sincronização do conjunto de dados.
Em qualquer caso, o nó que permanece online aumenta seu número de versão em um para sincronizar seu conjunto de dados após a conexão com o par ser restaurada.
Se a conexão pelo link Ethernet for perdida, o Heartbeat alternará temporariamente para InfiniBand e retornará dentro de 10 segundos quando for restaurado.
Configurando hosts
Para garantir a tolerância a falhas e melhorar o desempenho, você deve ativar o suporte MPIO para o array. Para fazer isso, você precisa adicionar linhas ao arquivo /etc/multipath.conf e, em seguida, reiniciar o serviço multipath
Texto ocultodispositivos {
dispositivo {
fornecedor "AStor"
path_grouping_policy "group_by_prio"
path_selector "comprimento da fila 0"
path_checker "tur"
apresenta "0"
hardware_handler "0"
primeiro "const"
failback imediato
fast_io_fail_tmo5
dev_loss_tmo 60
user_friendly_names sim
detect_prio sim
rr_min_io_rq 1
no_path_retry 0
}
}
A seguir, para que o ASM funcione com MPIO via ASMLib, você precisa alterar o arquivo /etc/sysconfig/oracleasm e então executar /etc/init.d/oracleasm scandisks
Texto oculto
# ORACLEASM_SCANORDER: Padrões correspondentes para ordenar a varredura do disco
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Padrões correspondentes para excluir discos da verificação
ORACLEASM_SCANEXCLUDE="sd"
Nota
Se não quiser usar ASMLib, você pode usar as regras UDEV, que são a base do ASMLib.
A partir da versão 12.1.0.2 do Oracle Database, a opção está disponível para instalação como parte do software ASMFD.
É imperativo garantir que os discos criados para o Oracle ASM estejam alinhados com o tamanho do bloco com o qual o array opera fisicamente (4K). Caso contrário, poderão ocorrer problemas de desempenho. Portanto, é necessário criar volumes com os parâmetros adequados:
parted /dev/mapper/device-name mklabel gpt mkpart primário 2048s 100% alinhamento-verificação ideal 1
Distribuição de bancos de dados em volumes criados para nossa configuração de teste
Nome do volume de armazenamento
Tamanho do volume
Mapeamento de LUNs de volume
Detalhe do dispositivo de volume ASM
Tamanho da unidade de alocação
Data01
200GB
Mapeie todos os volumes de armazenamento para todas as portas de dados do sistema de armazenamento
Redundância: Normal
Nome:DGDATA
Finalidade:Arquivos de dados
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundância: Normal
Nome: DGGRID1
Objetivo: Grade: CRS e Votação
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundância: Normal
Nome: DGGRID2
Objetivo: Grade: CRS e Votação
4MB
Grid05
1GB
Grid06
1GB
Refazer01
100GB
Redundância: Normal
Nome: DGREDO1
Objetivo: Refazer log do thread 1
4MB
Refazer02
100GB
Refazer03
100GB
Refazer04
100GB
Refazer05
100GB
Refazer06
100GB
Redundância: Normal
Nome: DGREDO2
Objetivo: Refazer log do thread 2
4MB
Refazer07
100GB
Refazer08
100GB
Refazer09
100GB
Refazer10
100GB
Configurações do banco de dados
- Tamanho do bloco = 8K
- Espaço de troca = 16 GB
- Desative AMM (gerenciamento automático de memória)
- Desativar páginas enormes transparentes
Outras configurações
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # não defina isso se estiver usando Linux x86
✓ vm.vfs_cache_pression=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grade macia nproc 2047
✓ grade rígida nproc 16384
✓ grade soft nofile 1024
✓ nofile rígido de grade 65536
✓ pilha flexível de grade 10240
✓ pilha rígida de grade 32768
✓ oracle soft nproc 2047
✓ oráculo rígido nproc 16384
✓ nofile soft oracle 1024
✓ arquivo rígido oracle 65536
✓ pilha flexível oracle 10240
✓ pilha rígida oracle 32768
✓ memlock macio 120795954
✓ memlock rígido 120795954
sqlplus “/as sysdba”
alterar conjunto de processos do sistema = 2000 escopo = spfile;
altere o conjunto do sistema open_cursors=2000 scope=spfile;
altere o conjunto do sistema session_cached_cursors=300 scope=spfile;
altere o conjunto do sistema db_files=8192 scope=spfile;
Teste de falha
Para fins de demonstração, o HammerDB foi usado para emular uma carga OLTP. Configuração do HammerDB:
Número de armazéns
256
Total de transações por usuário
1000000000000
Usuários Virtuais
256
O resultado foi um TPM de 2.1M, que está longe do limite de desempenho do array , mas é um “teto” para a configuração atual 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, iremos simplesmente construir sobre este número.
Teste para falha de um dos nós
Os hosts perderam parte dos caminhos de armazenamento, continuando a trabalhar nos demais com o segundo nó. O desempenho caiu por alguns segundos devido à reconstrução dos caminhos e depois voltou ao normal. Não houve interrupção no serviço.
Teste de falha do gabinete com todos os equipamentos
Neste caso, o desempenho também caiu por alguns segundos devido à reestruturação dos caminhos, e depois voltou à metade do valor original. O resultado foi reduzido pela metade em relação ao inicial devido à exclusão de um servidor de aplicação da operação. Também não houve interrupção no serviço.
Se houver necessidade de implementar uma solução de recuperação de desastres Cross-Rack tolerante a falhas para Oracle a um custo razoável e com pouco esforço de implantação/administração, o Oracle RAC e a arquitetura trabalharão juntos será uma das melhores opções. Em vez do Oracle RAC, pode haver qualquer outro software que forneça clustering, o mesmo SGBD ou sistemas de virtualização, por exemplo. O princípio de construção da solução permanecerá o mesmo. E o resultado final é zero para RTO e RPO.
Fonte: habr.com