Muitos aplicativos corporativos e sistemas de virtualização possuem 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 que trabalham em conjunto para balancear a carga e garantir a tolerância a falhas no nível do servidor/aplicativo. Esse modo requer armazenamento compartilhado, que normalmente é fornecido por um sistema de armazenamento de dados.
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 requisitos de confiabilidade mais elevados, o esquema "N servidores, um sistema de armazenamento" precisa ser mais complexo.
Primeiramente, é claro, precisamos determinar contra quais riscos estamos tentando nos proteger. Neste artigo, não abordaremos a proteção contra ameaças como "impactos de meteoritos". Portanto, a construção de uma solução de recuperação de desastres geograficamente distribuída é um tópico para um artigo futuro. Aqui, consideraremos uma solução de recuperação de desastres chamada "cross-rack", onde a proteção é construída no nível do rack de servidores. Os racks em si podem estar localizados na mesma sala ou em salas diferentes, mas normalmente estão dentro do mesmo prédio.
Esses racks devem conter todo o hardware e software necessários para garantir a operação do banco de dados Oracle, independentemente do estado dos racks vizinhos. Em outras palavras, ao usar 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 total de todos os equipamentos no gabinete:
- Falha de energia
- Falha no sistema de refrigeração
- Fatores externos (humanos, natureza, etc.)
A duplicação de servidores Oracle é inerente ao princípio de funcionamento do Oracle RAC e é implementada por meio de um aplicativo. Duplicar recursos de comutação também é simples. No entanto, duplicar o sistema de armazenamento não é tão simples.
A opção mais simples é a replicação de dados do sistema de armazenamento primário para o backup. A replicação síncrona ou assíncrona é possível, dependendo dos recursos do sistema de armazenamento. A replicação assíncrona levanta imediatamente a questão de garantir a consistência dos dados com o Oracle. No entanto, mesmo com a integração de software com o aplicativo, em caso de falha no sistema de armazenamento primário, será necessária a intervenção manual do administrador para alternar o cluster para o armazenamento de backup.
Uma opção mais sofisticada são os virtualizadores de armazenamento de software e/ou hardware, que eliminam problemas de consistência e intervenção manual. No entanto, a complexidade da implementação e da administração subsequente, bem como o custo proibitivo dessas soluções, desencorajam muitos usuários.
O AccelStor NeoSapphire™ All Flash Array é ideal para cenários como recuperação de desastres em vários racks. Utilizando arquitetura Shared-Nothing. Este modelo é um sistema de armazenamento de dois nós que usa a tecnologia proprietária FlexiRemap® para trabalhar com unidades flash. O NeoSapphire™ H710 é capaz de oferecer desempenho de até 600 mil IOPS em gravação aleatória de 4K e mais de 1 milhão de IOPS em leitura aleatória de 4K, algo inatingível com sistemas de armazenamento clássicos baseados em RAID.
Mas a principal característica do NeoSapphire™ H710 são seus dois nós, cada um alojado em um gabinete separado, cada um com sua própria cópia dos dados. A sincronização dos nós é realizada por meio de uma interface InfiniBand externa. Essa arquitetura permite que os nós sejam distribuídos em diferentes locais a até 100 metros de distância, proporcionando uma solução de recuperação de desastres entre racks. Ambos os nós operam em modo totalmente síncrono. Do ponto de vista do host, o H710 se apresenta como um sistema de armazenamento padrão com controlador duplo. Portanto, não são necessárias opções adicionais de software ou hardware, nem configurações complexas.
Ao comparar todas as soluções de recuperação de desastres entre racks descritas acima, a solução da AccelStor se destaca das demais:
Arquitetura AccelStor NeoSapphire™ Shared Nothing
Virtualizador de software ou hardware para sistemas de armazenamento
Solução baseada em replicação
Disponibilidade
Falha no servidor
Sem tempo de inatividade
Sem tempo de inatividade
Sem tempo de inatividade
Falha no interruptor
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 de 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
*O AccelStor NeoSapphire™ é um array totalmente em flash, que por definição não é barato, especialmente com o dobro da capacidade. No entanto, ao comparar o custo final de uma solução baseada nele com soluções similares de outros fornecedores, o preço pode ser considerado baixo.
A topologia de conexão dos servidores de aplicativos e dos nós do array All Flash será semelhante a esta:
Ao planejar a topologia, é altamente recomendável duplicar os switches de gerenciamento e a interconexão dos servidores.
A partir daqui, discutiremos conexões via Fibre Channel. O uso do iSCSI será semelhante, com ajustes para os tipos de switch utilizados e configurações de array ligeiramente diferentes.
Trabalho preparatório no conjunto
Equipamentos e software utilizados
Especificações do servidor e do switch
Componentes
descrição
Servidores Oracle Database 11g
Dois
Sistema operacional do servidor
Oracle Linux
versão do banco de dados Oracle
11g (RAC)
Processadores por servidor
Dois processadores Intel® Xeon® E5-2667 v2 de 16 núcleos a 3.30 GHz
Memória física por servidor
128GB
Rede FC
FC de 16 Gb/s com multipathing
FC HBA
Emulex Lpe-16002B
Portas 1GbE públicas dedicadas para gerenciamento de clusters
Adaptador Ethernet Intel RJ45
Switch FC de 16 Gb/s
Brocado 6505
Portas 10GbE privadas dedicadas para sincronização de dados
Intel X520
Especificações do AccelStor NeoSapphire™ All Flash Array
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 1GbE conecta-se aos hosts através de um switch Ethernet.
Porta de batimento cardíaco
O cabo Ethernet 1GbE que conecta dois nós de armazenamento.
Porta de sincronização de dados
Cabo InfiniBand de 56 Gb/s
Antes de usar o array, ele precisa ser inicializado. Por padrão, o endereço de gerenciamento de ambos os nós é o mesmo (192.168.1.1). Você precisa se conectar a eles um por um, definir novos endereços de gerenciamento (diferentes) e configurar a sincronização de tempo. Depois disso, as portas de gerenciamento podem ser conectadas a uma única rede. Em seguida, os nós são combinados em um par de alta disponibilidade (HA) atribuindo sub-redes para as conexões Interlink.
Após a inicialização, o array pode ser controlado a partir de qualquer nó.
Em seguida, 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, em última análise, melhorará o desempenho geral (mais sobre filas em outro artigo). ).
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 considerações sobre os modos de operação do conjunto de antenas e os processos que ocorrem em situações de emergência.
O conjunto de dados de cada nó possui um parâmetro de "número de versão". Após a inicialização, ele é uniforme 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 recente para a mais antiga, após o que o número da versão mais antiga é alinhado, ou seja, as cópias ficam idênticas. Algumas razões pelas quais as versões podem ser diferentes incluem:
- Reinício planejado de um dos nós.
- Ocorreu um acidente em um dos nós devido a um desligamento repentino (falta de energia, superaquecimento, etc.).
- A conexão InfiniBand falhou devido à impossibilidade de sincronização.
- Uma falha em um dos nós devido à corrupção de dados exigirá a criação de um novo grupo de alta disponibilidade (HA) e a sincronização completa do conjunto de dados.
Em qualquer caso, o nó que permanece online incrementa seu número de versão em um para sincronizar seu conjunto de dados após se reconectar com o par.
Se a conexão Ethernet for interrompida, o Heartbeat alterna temporariamente para InfiniBand e retorna ao padrão em até 10 segundos após o restabelecimento da conexão.
Configurando hosts
Para garantir a tolerância a falhas e melhorar o desempenho, habilite o suporte a MPIO para o array. Para isso, adicione as seguintes linhas ao arquivo /etc/multipath.conf e reinicie o serviço multipath.
Texto ocultodispositivos {
dispositivo {
fornecedor "AStor"
política_de_agrupamento_de_caminhos "agrupar_por_prioridade"
path_selector "queue-length 0"
verificador_de_caminho "tur"
apresenta "0"
manipulador_de_hardware "0"
antes de "const"
failback imediato
fast_io_fail_tmo 5
perda_de_destino_tmo 60
user_friendly_names sim
detectar_prioridade sim
rr_min_io_rq 1
no_path_retry 0
}
}
Em seguida, para que o ASM funcione com MPIO via ASMLib, você precisa modificar o arquivo /etc/sysconfig/oracleasm e então executar /etc/init.d/oracleasm scandisks.
Texto oculto
# ORACLEASM_SCANORDER: Correspondência de padrões para ordenar a varredura de disco
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Padrões correspondentes para excluir discos da verificação
ORACLEASM_SCANEXCLUDE="sd"
Nota
Se você não quiser usar o ASMLib, 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.
É essencial garantir que os discos criados para o Oracle ASM estejam alinhados com o tamanho físico do bloco do array (4K). Caso contrário, podem ocorrer problemas de desempenho. Portanto, crie volumes com os parâmetros apropriados:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Distribuição de bancos de dados entre os volumes criados para nossa configuração de teste.
Nome do volume de armazenamento
Tamanho do volume
Mapeamento de LUNs de volume
Detalhes 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
Finalidade: Refazer o registro da thread 1
4MB
Refazer02
100GB
Refazer03
100GB
Refazer04
100GB
Refazer05
100GB
Refazer06
100GB
Redundância: Normal
Nome: DGREDO2
Finalidade: Refazer o registro da 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
- Desativar AMM (Gerenciamento Automático de Memória)
- Desativar páginas grandes 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 # don’t set this if you’re using Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ Grid Soft Nproc 2047
✓ grade rígida nproc 16384
✓ grade suave sem arquivo 1024
✓ grade rígida nofile 65536
✓ grade soft stack 10240
✓ pilha rígida de grade 32768
✓ Oracle Soft Nproc 2047
✓ Oracle Hard Nproc 16384
✓ Oracle Soft Nofile 1024
✓ Arquivo nofile rígido Oracle 65536
✓ Oracle Soft Stack 10240
✓ Oracle Hard Stack 32768
✓ soft memlock 120795954
✓ memlock rígido 120795954
sqlplus “/as sysdba”
alter system set processes=2000 scope=spfile;
alter system set open_cursors=2000 scope=spfile;
alter system set session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
teste de tolerância a falhas
Para fins de demonstração, o HammerDB foi usado para emular a carga de trabalho 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 valor de 2.1 milhões de TPMs, o que está muito aquém do limite de desempenho do conjunto. Mas esse é o "limite" para a configuração atual do hardware do servidor (principalmente devido aos processadores) e à sua quantidade. O objetivo deste teste é demonstrar a tolerância a falhas da solução como um todo, e não alcançar o desempenho máximo. Portanto, usaremos esse valor simplesmente como ponto de partida.
Teste de falha de nó
Os hosts perderam alguns caminhos de acesso ao armazenamento, continuando a utilizar os caminhos restantes com o segundo nó. O desempenho caiu por alguns segundos devido à reconstrução dos caminhos, retornando em seguida ao normal. Não houve interrupção do serviço.
Testar o gabinete com todos os equipamentos para garantir a falha.
Nesse caso, o desempenho também caiu por alguns segundos devido à reconstrução do caminho, retornando em seguida à metade do valor original. O resultado foi reduzido pela metade devido à remoção de um servidor de aplicativos. Também não houve interrupção do serviço.
Se você precisa implementar uma solução de recuperação de desastres tolerante a falhas entre racks para Oracle a um custo razoável e com pouco esforço de implantação/administração, então a combinação do Oracle RAC e da arquitetura é a solução ideal. Será uma das melhores opções. O Oracle RAC pode ser substituído por qualquer outro software que suporte clustering, como SGBDs ou sistemas de virtualização. O princípio de design da solução permanecerá o mesmo. E o resultado final é RTO e RPO zero.
Fonte: habr.com
