Un número considerable de aplicacións empresariais e sistemas de virtualización teñen os seus propios mecanismos para crear solucións tolerantes a fallos. En concreto, Oracle RAC (Oracle Real Application Cluster) é un clúster de dous ou máis servidores de bases de datos Oracle que traballan xuntos para equilibrar a carga e proporcionar tolerancia a fallos a nivel de servidor/aplicación. Para traballar neste modo, necesitas un almacenamento compartido, que normalmente é un sistema de almacenamento.
Como xa comentamos nun dos nosos , o propio sistema de almacenamento, a pesar da presenza de compoñentes duplicados (incluídos controladores), aínda ten puntos de fallo, principalmente en forma dun único conxunto de datos. Polo tanto, para construír unha solución Oracle con requisitos de fiabilidade aumentados, o esquema "N servidores: un sistema de almacenamento" debe ser complicado.
En primeiro lugar, por suposto, temos que decidir contra que riscos intentamos asegurarnos. Neste artigo, non consideraremos a protección contra ameazas como "chegou un meteorito". Polo tanto, a construción dunha solución de recuperación de desastres xeograficamente dispersa seguirá sendo un tema para un dos seguintes artigos. Aquí veremos a chamada solución de recuperación de desastres Cross-Rack, cando a protección se constrúe a nivel de armarios de servidores. Os propios armarios poden estar situados no mesmo cuarto ou noutros diferentes, pero normalmente dentro do mesmo edificio.
Estes armarios deben conter todo o conxunto necesario de equipos e software que permitan o funcionamento das bases de datos Oracle independentemente do estado do "veciño". Noutras palabras, usando a solución de recuperación ante desastres Cross-Rack, eliminamos os riscos de falla:
- Servidores de aplicacións Oracle
- Sistemas de almacenamento
- Sistemas de conmutación
- Fallo total de todos os equipos do armario:
- Falla de enerxía
- Fallo do sistema de refrixeración
- Factores externos (humano, natureza, etc.)
A duplicación de servidores Oracle implica o propio principio de funcionamento de Oracle RAC e implícase a través dunha aplicación. A duplicación de instalacións de conmutación tampouco é un problema. Pero coa duplicación do sistema de almacenamento, todo non é tan sinxelo.
A opción máis sinxela é a replicación de datos desde o sistema de almacenamento principal ata o de copia de seguridade. Sincrónico ou asíncrono, dependendo das capacidades do sistema de almacenamento. Coa replicación asíncrona, xorde inmediatamente a cuestión de garantir a coherencia dos datos en relación con Oracle. Pero aínda que exista integración de software coa aplicación, en todo caso, no caso de producirse un fallo no sistema de almacenamento principal, será necesaria a intervención manual dos administradores para cambiar o clúster ao almacenamento de copia de seguridade.
Unha opción máis complexa son os "virtualizadores" de almacenamento de software e/ou hardware que eliminarán os problemas de consistencia e a intervención manual. Pero a complexidade do despregamento e a posterior administración, así como o moi indecente custo deste tipo de solucións, asusta a moitos.
A solución de matriz AccelStor NeoSapphire™ All Flash é perfecta para escenarios como a recuperación de desastres Cross-Rack usando a arquitectura Shared-Nothing. Este modelo é un sistema de almacenamento de dous nodos que utiliza a tecnoloxía propietaria FlexiRemap® para traballar con unidades flash. Grazas a NeoSapphire™ H710 é capaz de ofrecer un rendemento de ata 600 IOPS@4K de escritura aleatoria e 1M+ de IOPS@4K de lectura aleatoria, o que é inalcanzable cando se usan sistemas de almacenamento clásicos baseados en RAID.
Pero a característica principal de NeoSapphire™ H710 é a execución de dous nodos en forma de casos separados, cada un dos cales ten a súa propia copia dos datos. A sincronización dos nodos realízase a través da interface externa InfiniBand. Grazas a esta arquitectura, é posible distribuír nodos a diferentes localizacións a unha distancia de ata 100 m, proporcionando así unha solución de recuperación ante desastres Cross-Rack. Ambos nodos funcionan de forma completamente sincrónica. Desde o lado do host, o H710 parece un sistema de almacenamento de controlador dual normal. Polo tanto, non é necesario realizar ningunha opción adicional de software ou hardware ou configuración particularmente complexa.
Se comparamos todas as solucións de recuperación ante desastres Cross-Rack descritas anteriormente, entón a opción de AccelStor destaca notablemente do resto:
Arquitectura de nada compartido de AccelStor NeoSapphire™
Sistema de almacenamento “virtualizador” de software ou hardware
Solución baseada na replicación
Dispoñibilidade
Fallo do servidor
Sen tempo de inactividade
Sen tempo de inactividade
Sen tempo de inactividade
Fallo do interruptor
Sen tempo de inactividade
Sen tempo de inactividade
Sen tempo de inactividade
Fallo do sistema de almacenamento
Sen tempo de inactividade
Sen tempo de inactividade
O tempo de inactividade
Fallo de todo o gabinete
Sen tempo de inactividade
Sen tempo de inactividade
O tempo de inactividade
Custo e complexidade
Custo da solución
Baixo*
Alto
Alto
Complexidade de implantación
Baixo
Alto
Alto
*AccelStor NeoSapphire™ segue sendo unha matriz All Flash, que por definición non custa "3 copeques", especialmente porque ten unha dobre reserva de capacidade. Non obstante, ao comparar o custo final dunha solución baseada nela con outras similares doutros provedores, o custo pode considerarse baixo.
A topoloxía para conectar os servidores de aplicacións e os nodos de matriz All Flash terá o seguinte aspecto:
Á hora de planificar a topoloxía, tamén é moi recomendable duplicar conmutadores de xestión e interconectar servidores.
Aquí e máis adiante falaremos sobre a conexión a través de Fibre Channel. Se usas iSCSI, todo será o mesmo, axustado para os tipos de interruptores utilizados e configuracións de matriz lixeiramente diferentes.
Traballos preparatorios na matriz
Equipos e software utilizados
Especificacións do servidor e do switch
Compoñentes
Descrición
Servidores Oracle Database 11g
Dous
Sistema operativo servidor
oracle linux
Versión de base de datos Oracle
11 g (RAC)
Procesadores por servidor
Dos CPU Intel® Xeon® E16-5 v2667 de 2 núcleos a 3.30 GHz
Memoria física por servidor
128GB
Rede FC
FC de 16 Gb/s con rutas múltiples
FC HBA
Emulex Lpe-16002B
Portos públicos de 1 GbE dedicados para a xestión de clústeres
Adaptador Intel Ethernet RJ45
Conmutador FC de 16 Gb/s
Brocado 6505
Portos privados de 10 GbE dedicados para sincronización de datos
Intel X520
Especificación de AccelStor NeoSapphire™ All Flash Array
Compoñentes
Descrición
Sistema de almacenamento
Modelo de alta dispoñibilidade NeoSapphire™: H710
Versión da imaxe
4.0.1
Número total de unidades
48
Tamaño da unidade
1.92TB
Tipo de unidade
SSD
Portos de destino FC
16 portos de 16 Gb (8 por nodo)
Xestión de portos
O cable ethernet de 1 GbE que se conecta aos anfitrións mediante un interruptor ethernet
Porto de latido do corazón
O cable Ethernet de 1 GbE que se conecta entre dous nodos de almacenamento
Porto de sincronización de datos
Cable InfiniBand de 56 Gb/s
Antes de poder usar unha matriz, debes inicializala. Por defecto, o enderezo de control de ambos os nós é o mesmo (192.168.1.1). Debe conectarse a eles un por un e establecer novos enderezos de xestión (xa diferentes) e configurar a sincronización horaria, despois de que os portos de xestión pódense conectar a unha única rede. Despois, os nodos combínanse nun par HA asignando subredes para as conexións de Interlink.
Despois de completar a inicialización, pode xestionar a matriz desde calquera nodo.
A continuación, creamos os volumes necesarios e publícaos nos servidores de aplicacións.
Recoméndase encarecidamente crear varios volumes para Oracle ASM xa que isto aumentará o número de destinos para os servidores, o que finalmente mellorará o rendemento xeral (máis sobre as colas noutro ).
Configuración de proba
Nome do volume de almacenamento
Tamaño do volume
Datos01
200GB
Datos02
200GB
Datos03
200GB
Datos04
200GB
Datos05
200GB
Datos06
200GB
Datos07
200GB
Datos08
200GB
Datos09
200GB
Datos10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Refacer 01
100GB
Refacer 02
100GB
Refacer 03
100GB
Refacer 04
100GB
Refacer 05
100GB
Refacer 06
100GB
Refacer 07
100GB
Refacer 08
100GB
Refacer 09
100GB
Refacer 10
100GB
Algunhas explicacións sobre os modos de funcionamento da matriz e os procesos que se producen en situacións de emerxencia
O conxunto de datos de cada nodo ten un parámetro "número de versión". Despois da inicialización inicial, é igual e igual a 1. Se por algún motivo o número de versión é diferente, entón os datos sempre se sincronizan desde a versión anterior á máis nova, despois de que se aliña o número da versión máis nova, é dicir. isto significa que as copias son idénticas. Razóns polas que as versións poden ser diferentes:
- Reinicio programado dun dos nodos
- Un accidente nun dos nodos debido a unha parada súbita (alimentación, sobrequecemento, etc.).
- Perdeuse a conexión de InfiniBand coa imposibilidade de sincronizar
- Un fallo nun dos nodos debido á corrupción dos datos. Aquí terás que crear un novo grupo HA e completar a sincronización do conxunto de datos.
En calquera caso, o nodo que permanece en liña aumenta un número de versión para sincronizar o seu conxunto de datos despois de restablecer a conexión co par.
Se se perde a conexión a través da ligazón Ethernet, Heartbeat cambia temporalmente a InfiniBand e regresa dentro de 10 segundos cando se restaure.
Configurando hosts
Para garantir a tolerancia a fallos e mellorar o rendemento, debes activar a compatibilidade con MPIO para a matriz. Para iso, cómpre engadir liñas ao ficheiro /etc/multipath.conf e, a continuación, reiniciar o servizo multipath.
Texto ocultodispositivos {
dispositivo {
vendedor "AStor"
path_grouping_policy "group_by_prio"
path_selector "longitude da cola 0"
path_checker "tur"
características "0"
controlador_hardware "0"
prio "const"
fallo inmediato
fast_io_fail_tmo 5
dev_loss_tmo 60
nomes_de_usuarios si
detect_prio si
rr_min_io_rq 1
sen_ruta_reintento 0
}
}
A continuación, para que ASM funcione con MPIO a través de ASMLib, cómpre cambiar o ficheiro /etc/sysconfig/oracleasm e executar /etc/init.d/oracleasm scandisks
Texto oculto
# ORACLEASM_SCANORDER: Patróns coincidentes para ordenar a dixitalización do disco
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Patróns coincidentes para excluír discos da exploración
ORACLEASM_SCANEXCLUDE="sd"
Nota
Se non queres usar ASMLib, podes usar as regras UDEV, que son a base para ASMLib.
A partir da versión 12.1.0.2 de Oracle Database, a opción está dispoñible para a instalación como parte do software ASMFD.
É imperativo asegurarse de que os discos creados para Oracle ASM estean aliñados co tamaño de bloque co que opera fisicamente a matriz (4K). En caso contrario, poden ocorrer problemas de rendemento. Polo tanto, é necesario crear volumes cos parámetros axeitados:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check óptimo 1
Distribución de bases de datos en volumes creados para a nosa configuración de proba
Nome do volume de almacenamento
Tamaño do volume
Mapeo de LUN de volume
Detalle do dispositivo de volume ASM
Tamaño da unidade de asignación
Datos01
200GB
Asigne todos os volumes de almacenamento ao sistema de almacenamento de todos os portos de datos
Redundancia: normal
Nome: DGDATA
Finalidade: ficheiros de datos
4MB
Datos02
200GB
Datos03
200GB
Datos04
200GB
Datos05
200GB
Datos06
200GB
Datos07
200GB
Datos08
200GB
Datos09
200GB
Datos10
200GB
Grid01
1GB
Redundancia: normal
Nome: DGGRID1
Obxecto:Grid: CRS e Votación
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundancia: normal
Nome: DGGRID2
Obxecto:Grid: CRS e Votación
4MB
Grid05
1GB
Grid06
1GB
Refacer 01
100GB
Redundancia: normal
Nome: DGREDO1
Finalidade: Refacer o rexistro do fío 1
4MB
Refacer 02
100GB
Refacer 03
100GB
Refacer 04
100GB
Refacer 05
100GB
Refacer 06
100GB
Redundancia: normal
Nome: DGREDO2
Finalidade: Refacer o rexistro do fío 2
4MB
Refacer 07
100GB
Refacer 08
100GB
Refacer 09
100GB
Refacer 10
100GB
Configuración da base de datos
- Tamaño do bloque = 8K
- Espazo de intercambio = 16 GB
- Desactivar AMM (Xestión automática de memoria)
- Desactivar páxinas enormes transparentes
Outras configuracións
# 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 # non configure isto se está a usar Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ Grid Soft Stack 10240
✓ Grid Hard Stack 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle Soft Nofile 1024
✓ Oracle Hard nofile 65536
✓ Oracle Soft Stack 10240
✓ Oracle hard stack 32768
✓ Soft Memlock 120795954
✓ Hard memlock 120795954
sqlplus "/as sysdba"
alterar o conxunto de procesos do sistema = 2000 alcance = ficheiro sp;
alterar o conxunto do sistema open_cursors=2000 scope=spfile;
alterar o conxunto do sistema session_cached_cursors=300 scope=spfile;
alterar o conxunto do sistema db_files=8192 scope=spfile;
Proba de fallo
Para fins de demostración, utilizouse HammerDB para emular unha carga OLTP. Configuración de HammerDB:
Número de almacéns
256
Total de transaccións por usuario
1000000000000
Usuarios virtuais
256
O resultado foi un TPM de 2.1 millóns, que está lonxe do límite de rendemento da matriz , pero é un "teito" para a configuración de hardware actual dos servidores (principalmente debido aos procesadores) e o seu número. O obxectivo desta proba aínda é demostrar a tolerancia a fallos da solución no seu conxunto, e non acadar o máximo rendemento. Polo tanto, simplemente basaremos esta figura.
Proba de fallo dun dos nodos
Os anfitrións perderon parte dos camiños ao almacenamento, continuando traballando polos restantes co segundo nodo. O rendemento baixou durante uns segundos debido a que se reconstruían os camiños e despois volveu á normalidade. Non houbo interrupción no servizo.
Proba de fallo do armario con todos os equipos
Neste caso, o rendemento tamén baixou durante uns segundos debido á reestruturación dos camiños, e despois volveu á metade do valor orixinal. O resultado reduciuse á metade do inicial debido á exclusión dun servidor de aplicacións da operación. Tampouco houbo interrupción no servizo.
Se hai que implementar unha solución de recuperación de desastres Cross-Rack tolerante a fallos para Oracle a un custo razoable e con pouco esforzo de implementación/administración, entón Oracle RAC e a arquitectura traballan xuntos. será unha das mellores opcións. En lugar de Oracle RAC, pode haber calquera outro software que proporcione clustering, o mesmo DBMS ou sistemas de virtualización, por exemplo. O principio de construción da solución seguirá sendo o mesmo. E o resultado final é cero para RTO e RPO.
Fonte: www.habr.com