Un número considerable de aplicaciones empresariales y sistemas de virtualización tienen sus propios mecanismos para crear soluciones tolerantes a fallos. Específicamente, Oracle RAC (Oracle Real Application Cluster) es un clúster de dos o más servidores de bases de datos Oracle que trabajan juntos para equilibrar la carga y proporcionar tolerancia a fallas en el nivel de servidor/aplicación. Para trabajar en este modo, necesita un almacenamiento compartido, que suele ser un sistema de almacenamiento.
Como ya hemos comentado en uno de nuestros , el propio sistema de almacenamiento, a pesar de la presencia de componentes duplicados (incluidos los controladores), todavía tiene puntos de falla, principalmente en forma de un único conjunto de datos. Por lo tanto, para construir una solución Oracle con mayores requisitos de confiabilidad, el esquema “N servidores - un sistema de almacenamiento” debe ser complicado.
Primero, por supuesto, debemos decidir contra qué riesgos intentamos asegurarnos. En este artículo, no consideraremos la protección contra amenazas como "ha llegado un meteorito". Por lo tanto, la creación de una solución de recuperación ante desastres geográficamente dispersa seguirá siendo el tema de uno de los siguientes artículos. Aquí veremos la llamada solución de recuperación ante desastres Cross-Rack, cuando la protección se construye al nivel de los gabinetes de servidores. Los propios armarios pueden estar ubicados en la misma habitación o en habitaciones diferentes, pero normalmente dentro del mismo edificio.
Estos gabinetes deben contener todo el conjunto necesario de equipos y software que permitirán el funcionamiento de las bases de datos Oracle independientemente del estado del “vecino”. En otras palabras, utilizando la solución de recuperación ante desastres Cross-Rack eliminamos los riesgos de fallo:
- Servidores de aplicaciones Oracle
- Sistemas de almacenamiento
- Sistemas de conmutación
- Fallo total de todos los equipos del gabinete:
- Rechazo de poder
- Fallo del sistema de refrigeración
- Factores externos (humanos, naturales, etc.)
La duplicación de servidores Oracle implica el principio operativo mismo de Oracle RAC y se implementa a través de una aplicación. La duplicación de instalaciones de conmutación tampoco supone un problema. Pero con la duplicación del sistema de almacenamiento no todo es tan sencillo.
La opción más sencilla es la replicación de datos desde el sistema de almacenamiento principal al de respaldo. Síncrono o asíncrono, según las capacidades del sistema de almacenamiento. Con la replicación asíncrona, surge inmediatamente la cuestión de garantizar la coherencia de los datos en relación con Oracle. Pero incluso si hay integración de software con la aplicación, en cualquier caso, en caso de una falla en el sistema de almacenamiento principal, será necesaria la intervención manual de los administradores para cambiar el clúster al almacenamiento de respaldo.
Una opción más compleja son los “virtualizadores” de almacenamiento de software y/o hardware que eliminarán los problemas de coherencia y la intervención manual. Pero la complejidad del despliegue y la posterior administración, así como el coste muy indecente de este tipo de soluciones, asusta a muchos.
La solución de matriz AccelStor NeoSapphire™ All Flash es perfecta para escenarios como la recuperación de desastres entre bastidores utilizando la arquitectura Shared-Nothing. Este modelo es un sistema de almacenamiento de dos nodos que utiliza tecnología patentada FlexiRemap® para trabajar con unidades flash. Gracias a NeoSapphire™ H710 es capaz de ofrecer un rendimiento de hasta 600 4 IOPS a 1 K de escritura aleatoria y más de 4 millón de IOPS a XNUMX K de lectura aleatoria, lo cual es inalcanzable cuando se utilizan sistemas de almacenamiento clásicos basados en RAID.
Pero la característica principal de NeoSapphire™ H710 es la ejecución de dos nodos en forma de casos separados, cada uno de los cuales tiene su propia copia de los datos. La sincronización de nodos se realiza a través de la interfaz externa InfiniBand. Gracias a esta arquitectura, es posible distribuir nodos en diferentes ubicaciones a una distancia de hasta 100 m, proporcionando así una solución de recuperación ante desastres Cross-Rack. Ambos nodos funcionan de forma completamente sincrónica. Desde el punto de vista del host, el H710 parece un sistema de almacenamiento de controlador dual normal. Por lo tanto, no es necesario realizar ninguna opción adicional de software o hardware ni configuraciones particularmente complejas.
Si comparamos todas las soluciones de recuperación ante desastres Cross-Rack descritas anteriormente, la opción de AccelStor se destaca notablemente del resto:
AccelStor NeoSapphire™ Arquitectura nada compartida
Sistema de almacenamiento “virtualizador” de software o hardware
Solución basada en replicación
Disponibilidad
Fallo del servidor
Sin tiempo de inactividad
Sin tiempo de inactividad
Sin tiempo de inactividad
Fallo del interruptor
Sin tiempo de inactividad
Sin tiempo de inactividad
Sin tiempo de inactividad
Fallo del sistema de almacenamiento
Sin tiempo de inactividad
Sin tiempo de inactividad
El tiempo de inactividad
Fallo de todo el gabinete
Sin tiempo de inactividad
Sin tiempo de inactividad
El tiempo de inactividad
Costo y complejidad
Costo de la solución
Bajo*
Alto
Alto
Complejidad de implementación
bajo
Alto
Alto
*AccelStor NeoSapphire™ sigue siendo una matriz All Flash, que por definición no cuesta “3 kopeks”, especialmente porque tiene una reserva de capacidad doble. Sin embargo, al comparar el coste final de una solución basada en ella con otras similares de otros proveedores, el coste puede considerarse bajo.
La topología para conectar servidores de aplicaciones y nodos de matriz All Flash se verá así:
Al planificar la topología, también se recomienda duplicar los conmutadores de administración e interconectar servidores.
Aquí y más hablaremos sobre la conexión a través de Fibre Channel. Si usa iSCSI, todo será igual, ajustado según los tipos de conmutadores utilizados y configuraciones de matriz ligeramente diferentes.
Trabajo preparatorio en la matriz.
Equipos y software utilizados.
Especificaciones de servidores y conmutadores
Компоненты
Descripción
Servidores de base de datos Oracle 11g
Dos
Sistema operativo del servidor
Oracle Linux
Versión de la base de datos Oracle
11g (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
red FC
FC de 16 Gb/s con rutas múltiples
FC HBA
Emulex Lpe-16002B
Puertos públicos dedicados de 1 GbE para la gestión de clústeres
Adaptador ethernet Intel RJ45
Conmutador FC de 16 Gb/s
Brocado 6505
Puertos privados dedicados de 10 GbE para sincronización de datos
Intel X520
Especificación de matriz totalmente flash AccelStor NeoSapphire™
Компоненты
Descripción
Sistema de almacenamiento
Modelo de alta disponibilidad NeoSapphire™: H710
Versión de imagen
4.0.1
Número total de unidades
48
Tamaño de la unidad
1.92TB
Tipo de unidad
SSD
Puertos de destino FC
16 puertos de 16 Gb (8 por nodo)
Puertos de gestión
El cable Ethernet de 1 GbE que se conecta a los hosts mediante un conmutador Ethernet
Puerto de latido
El cable Ethernet de 1 GbE que se conecta entre dos nodos de almacenamiento
Puerto de sincronización de datos
Cable InfiniBand de 56 Gb/s
Antes de poder utilizar una matriz, debe inicializarla. Por defecto, la dirección de control de ambos nodos es la misma (192.168.1.1). Debe conectarse a ellos uno por uno y configurar nuevas direcciones de administración (ya diferentes) y configurar la sincronización horaria, después de lo cual los puertos de administración se pueden conectar a una sola red. Luego, los nodos se combinan en un par HA asignando subredes para conexiones Interlink.
Una vez completada la inicialización, puede administrar la matriz desde cualquier nodo.
A continuación, creamos los volúmenes necesarios y los publicamos en los servidores de aplicaciones.
Se recomienda encarecidamente crear varios volúmenes para Oracle ASM, ya que esto aumentará la cantidad de destinos para los servidores, lo que en última instancia mejorará el rendimiento general (más sobre las colas en otro ).
Configuración de prueba
Nombre del volumen de almacenamiento
Tamaño de volumen
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
Rehacer01
100GB
Rehacer02
100GB
Rehacer03
100GB
Rehacer04
100GB
Rehacer05
100GB
Rehacer06
100GB
Rehacer07
100GB
Rehacer08
100GB
Rehacer09
100GB
Rehacer10
100GB
Algunas explicaciones sobre los modos de funcionamiento del array y los procesos que ocurren en situaciones de emergencia.
El conjunto de datos de cada nodo tiene un parámetro de "número de versión". Después de la inicialización inicial, es igual e igual a 1. Si por alguna razón el número de versión es diferente, entonces los datos siempre se sincronizan de la versión anterior a la más reciente, después de lo cual el número de la versión más reciente se alinea, es decir. esto significa que las copias son idénticas. Razones por las que las versiones pueden ser diferentes:
- Reinicio programado de uno de los nodos.
- Un accidente en uno de los nodos por un apagado repentino (alimentación eléctrica, sobrecalentamiento, etc.).
- Se perdió la conexión InfiniBand con imposibilidad de sincronizar
- Un fallo en uno de los nodos debido a corrupción de datos. Aquí deberá crear un nuevo grupo HA y completar la sincronización del conjunto de datos.
En cualquier caso, el nodo que permanece en línea aumenta en uno su número de versión para sincronizar su conjunto de datos una vez restablecida la conexión con el par.
Si se pierde la conexión a través del enlace Ethernet, Heartbeat cambia temporalmente a InfiniBand y regresa dentro de 10 segundos cuando se restablece.
Configurar hosts
Para garantizar la tolerancia a fallos y mejorar el rendimiento, debe habilitar la compatibilidad con MPIO para la matriz. Para hacer esto, debe agregar líneas al archivo /etc/multipath.conf y luego reiniciar el servicio de múltiples rutas.
Texto ocultodispositivos {
dispositivo {
proveedor "AStor"
path_grouping_policy "grupo_por_prio"
path_selector "longitud de cola 0"
path_checker "tur"
características "0"
controlador_hardware "0"
prio "constante"
recuperación inmediata
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names sí
detectar_prio si
rr_min_io_rq 1
no_path_reintentar 0
}
}
A continuación, para que ASM funcione con MPIO a través de ASMLib, debe cambiar el archivo /etc/sysconfig/oracleasm y luego ejecutar /etc/init.d/oracleasm scandisks
Texto oculto
# ORACLEASM_SCANORDER: Coincidencia de patrones para ordenar el escaneo del disco
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Patrones coincidentes para excluir discos del análisis
ORACLEASM_SCANEXCLUDE="sd"
Nota
Si no desea utilizar ASMLib, puede utilizar las reglas UDEV, que son la base de ASMLib.
A partir de la versión 12.1.0.2 de Oracle Database, la opción está disponible para su instalación como parte del software ASMFD.
Es imperativo asegurarse de que los discos creados para Oracle ASM estén alineados con el tamaño de bloque con el que opera físicamente el arreglo (4K). De lo contrario, pueden ocurrir problemas de rendimiento. Por tanto, es necesario crear volúmenes con los parámetros adecuados:
parted /dev/mapper/nombre-dispositivo mklabel gpt mkpart primario 2048s 100% align-check óptimo 1
Distribución de bases de datos entre volúmenes creados para nuestra configuración de prueba.
Nombre del volumen de almacenamiento
Tamaño de volumen
Mapeo de LUN de volumen
Detalle del dispositivo de volumen ASM
Tamaño de unidad de asignacion
Data01
200GB
Asigne todos los volúmenes de almacenamiento al sistema de almacenamiento y todos los puertos de datos.
Redundancia: Normal
Nombre:DGDATA
Finalidad: Ficheros de datos
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundancia: Normal
Nombre: DGGRID1
Propósito: Cuadrícula: CRS y Votación
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundancia: Normal
Nombre: DGGRID2
Propósito: Cuadrícula: CRS y Votación
4MB
Grid05
1GB
Grid06
1GB
Rehacer01
100GB
Redundancia: Normal
Nombre: DGREDO1
Propósito: Rehacer el registro del hilo 1
4MB
Rehacer02
100GB
Rehacer03
100GB
Rehacer04
100GB
Rehacer05
100GB
Rehacer06
100GB
Redundancia: Normal
Nombre: DGREDO2
Propósito: Rehacer el registro del hilo 2
4MB
Rehacer07
100GB
Rehacer08
100GB
Rehacer09
100GB
Rehacer10
100GB
Configuración de la base de datos
- Tamaño de bloque = 8K
- Espacio de intercambio = 16 GB
- Deshabilitar AMM (Administración automática de memoria)
- Deshabilitar páginas enormes transparentes
Otros ajustes
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.archivo-max = 6815744
✓ núcleo.shmmax 103079215104
✓ kernel.shmall 31457280
✓ núcleo.shmmn 4096
✓ núcleo.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.intercambio=10
✓ vm.min_free_kbytes=524288 # no configures esto si estás usando Linux x86
✓ vm.vfs_cache_pression=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ cuadrícula suave nproc 2047
✓ cuadrícula dura nproc 16384
✓ rejilla suave nofile 1024
✓ rejilla dura nofile 65536
✓ pila suave de rejilla 10240
✓ pila dura de rejilla 32768
✓ Oracle suave nproc 2047
✓ oráculo duro nproc 16384
✓ archivo suave de Oracle 1024
✓ archivo duro Oracle 65536
✓ pila suave de Oracle 10240
✓ pila dura de Oracle 32768
✓ memlock suave 120795954
✓ memlock duro 120795954
sqlplus “/como sysdba”
alterar los procesos establecidos en el sistema = 2000 alcance = spfile;
alterar el conjunto del sistema open_cursors=2000 alcance=spfile;
alterar el conjunto del sistema session_cached_cursors=300 alcance=spfile;
alterar el conjunto del sistema db_files=8192 alcance=spfile;
prueba de falla
Para fines de demostración, se utilizó HammerDB para emular una carga OLTP. Configuración de HammerDB:
Número de almacenes
256
Transacciones totales por usuario
1000000000000
Usuarios virtuales
256
El resultado fue un TPM de 2.1 millones, que está lejos del límite de rendimiento de la matriz. , pero es un "techo" para la configuración de hardware actual de los servidores (principalmente debido a los procesadores) y su número. El propósito de esta prueba sigue siendo demostrar la tolerancia a fallas de la solución en su conjunto y no lograr el máximo rendimiento. Por lo tanto, simplemente nos basaremos en esta figura.
Prueba de fallo de uno de los nodos.
Los hosts perdieron parte de las rutas al almacenamiento y continuaron trabajando en las restantes con el segundo nodo. El rendimiento disminuyó durante unos segundos debido a que se reconstruyeron las rutas y luego volvió a la normalidad. No hubo interrupción en el servicio.
Prueba de falla del gabinete con todo el equipo.
En este caso, el rendimiento también bajó durante unos segundos debido a la reestructuración de los caminos, y luego volvió a la mitad del valor original. El resultado se redujo a la mitad respecto al inicial debido a la exclusión del funcionamiento de un servidor de aplicaciones. Tampoco hubo interrupción del servicio.
Si es necesario implementar una solución de recuperación ante desastres Cross-Rack tolerante a fallas para Oracle a un costo razonable y con poco esfuerzo de implementación/administración, entonces Oracle RAC y la arquitectura trabajan juntos será una de las mejores opciones. En lugar de Oracle RAC, puede haber cualquier otro software que proporcione clustering, el mismo DBMS o sistemas de virtualización, por ejemplo. El principio de construcción de la solución seguirá siendo el mismo. Y el resultado final es cero para RTO y RPO.
Fuente: habr.com