Un número considerable de aplicaciones empresariales y sistemas de virtualización tienen sus propios mecanismos para construir soluciones tolerantes a fallas. En particular, Oracle RAC (Oracle Real Application Cluster) es un grupo de dos o más servidores de bases de datos Oracle que trabajan juntos para equilibrar la carga y proporcionar tolerancia a fallas a nivel de servidor / aplicación. Para trabajar en este modo, se requiere un almacenamiento común, cuya función suele ser el almacenamiento.
Como ya discutimos en uno de nuestros artículos , en sí mismo el 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 solo conjunto de datos. Por lo tanto, para construir una solución Oracle con mayores requisitos de confiabilidad, el esquema "N servidores - un almacenamiento" debe ser complicado.
Primero, por supuesto, debe decidir contra qué riesgos estamos tratando de asegurarnos. En este artículo, no consideraremos la protección contra amenazas como la llegada de un meteorito. Por lo tanto, la creación de una solución de recuperación ante desastres dispersa geográficamente seguirá siendo un tema para uno de los siguientes artículos. Aquí observamos la llamada solución de recuperación de desastres Cross-Rack, cuando la protección se construye a nivel de gabinetes de servidores. Los gabinetes pueden ubicarse en la misma habitación o en diferentes, pero generalmente dentro del mismo edificio.
Estos gabinetes deben contener todo el conjunto de equipos y software necesarios que garantizarán el funcionamiento de las bases de datos Oracle independientemente del estado del "vecino". En otras palabras, utilizando la solución de recuperación de desastres Cross-Rack, eliminamos los riesgos de falla:
- Servidores de aplicaciones Oracle
- Sistemas de almacenamiento
- Sistemas de conmutación
- Falla completa de todos los equipos en el gabinete:
- Falla de energía
- Falla del sistema de enfriamiento.
- Factores externos (hombre, naturaleza, etc.)
La duplicación de servidores Oracle implica el principio mismo de Oracle RAC y se implementa a través de la aplicación. La duplicación de herramientas de conmutación tampoco es un problema. Pero con la duplicación del sistema de almacenamiento, no todo es tan simple.
La opción más fácil es replicar datos del almacenamiento primario a la copia de seguridad. Sincrónico o asincrónico, dependiendo de las capacidades de almacenamiento. La replicación asincrónica plantea inmediatamente la cuestión de garantizar la coherencia de los datos con Oracle. Pero incluso si hay integración de software con la aplicación, en cualquier caso, en caso de accidente en el sistema de almacenamiento principal, se requerirá 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 software y / o hardware de los sistemas de almacenamiento, que eliminarán los problemas de coherencia e intervención manual. Pero la complejidad de la implementación y la administración posterior, así como el costo muy indecente de tales soluciones, asustan a muchos.
Solo para escenarios como la recuperación ante desastres Cross-Rack, la matriz All Flash AccelStor NeoSapphire ™ H710 que utiliza la arquitectura Shared-Nothing es perfecta . Este modelo es un sistema de almacenamiento doble que utiliza su propia tecnología FlexiRemap® para trabajar con unidades flash. Gracias al FlexiRemap® NeoSapphire ™ H710, puede entregar hasta 600K IOPS @ 4K de escritura aleatoria y 1M + IOPS @ 4K de lectura aleatoria, que es inalcanzable con el almacenamiento clásico basado en RAID.
Pero la característica principal del NeoSapphire ™ H710 es la ejecución de dos nodos como recintos 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, los nodos se pueden distribuir en diferentes ubicaciones a distancias de hasta 100 m, lo que proporciona la solución de recuperación ante desastres Cross-Rack. Ambos nodos funcionan completamente en modo síncrono. Desde el lado del host, el H710 parece un almacenamiento de controlador dual ordinario. Por lo tanto, no es necesario realizar opciones adicionales de software y hardware y configuraciones particularmente complejas.
Si compara todas las soluciones de recuperación de desastres Cross-Rack descritas anteriormente, la versión AccelStor se destaca del resto:
| Arquitectura AccelStor NeoSapphire ™ Shared Nothing | Software o hardware "virtualizador" de almacenamiento | Solución de replicación |
|---|
| Disponibilidad |
| Falla del servidor | Sin tiempo de inactividad | Sin tiempo de inactividad | Sin tiempo de inactividad |
| Falla del interruptor | Sin tiempo de inactividad | Sin tiempo de inactividad | Sin tiempo de inactividad |
| Falla de almacenamiento | Sin tiempo de inactividad | Sin tiempo de inactividad | Tiempo de inactividad |
| Falla de todo el gabinete. | Sin tiempo de inactividad | Sin tiempo de inactividad | Tiempo de inactividad |
| Costo y complejidad. |
| Costo de la solución | Bajo * | Alta | Alta |
| Dificultad de implementación | Bajo | Alta | Alta |
* AccelStor NeoSapphire ™ sigue siendo una matriz All Flash, que por definición no cuesta "3 kopecks", especialmente porque tiene una reserva de capacidad doble. Sin embargo, al comparar el costo total de la solución basada en ella con otros similares de otros proveedores, el costo 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 que duplique los conmutadores de administración y las interconexiones del servidor.
A continuación, hablaremos sobre la conexión a través de Fibre Channel. En el caso de usar iSCSI, todo será igual, ajustado para los tipos de interruptores utilizados y configuraciones de matriz ligeramente diferentes.
Trabajo preparatorio en la matriz.
Hardware y software usadosEspecificaciones del servidor y conmutador
| Componentes | Descripción |
|---|
| Servidores Oracle Database 11g | Dos |
| Sistema operativo del servidor | Oracle Linux |
| Versión de la base de datos Oracle | 11 g (RAC) |
| Procesadores por servidor | Dos CPU de 16 núcleos Intel® Xeon® E5-2667 v2 @ 3.30GHz |
| Memoria física por servidor | 128GB |
| Red FC | 16 Gb / s FC con múltiples rutas |
| 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 | Brocade 6505 |
| Puertos privados dedicados de 10 GbE para sincronización de datos | Intel X520 |
AccelStor NeoSapphhire ™ All Flash Array Especificación
| Componentes | Descripción |
|---|
| Sistema de almacenamiento | Modelo de alta disponibilidad NeoSapphire ™: H710 |
| Versión de la 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 de ethernet de 1 GbE que se conecta a los hosts a través de un conmutador de 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 comenzar a usar 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 a la vez y establecer nuevas direcciones de administración (ya diferentes) y configurar la sincronización de tiempo, después de lo cual los puertos de administración se pueden conectar a una sola red. Después de eso, los nodos se combinan en un par HA asignando subredes a las conexiones de Interlink.
Una vez completada la inicialización, puede controlar la matriz desde cualquier nodo.
A continuación, cree los volúmenes necesarios y publíquelos para los servidores de aplicaciones.
Se recomienda encarecidamente que cree varios volúmenes para Oracle ASM, ya que esto aumentará el número de objetivos para los servidores, lo que finalmente mejorará el rendimiento general (más información sobre las colas en otro artículo ).
Configuración de prueba| Nombre del volumen de almacenamiento | Tamaño del volumen |
|---|
| Data01 | 200GB |
| Datos02 | 200GB |
| Datos03 | 200GB |
| Datos04 | 200GB |
| Datos05 | 200GB |
| Datos06 | 200GB |
| Datos07 | 200GB |
| Datos08 | 200GB |
| Data09 | 200GB |
| Datos10 | 200GB |
| Rejilla01 | 1GB |
| Rejilla02 | 1GB |
| Rejilla03 | 1GB |
| Rejilla04 | 1GB |
| Rejilla05 | 1GB |
| Rejilla06 | 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 de la matriz y los procesos que ocurren en situaciones de emergencia.
Cada conjunto de datos de 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 siempre hay sincronización de los datos de la versión anterior a la más joven, después de lo cual el número se alinea para la versión más joven, es decir. Esto significa que las copias son idénticas. Razones por las que las versiones pueden variar:
- Reinicio programado de uno de los nodos
- Un accidente en uno de los nodos debido a un apagado repentino (energía, sobrecalentamiento, etc.).
- Conexión rota InfiniBand con incapacidad para sincronizar
- Accidente en uno de los nodos debido a la corrupción de datos. Ya requerirá la creación de un nuevo grupo HA y la sincronización completa del conjunto de datos.
En cualquier caso, el nodo que permanece en línea aumenta su número de versión en uno, de modo que después de reconectarse con el par, sincronice su conjunto de datos.
Si la conexión se pierde a través del enlace Ethernet, Heartbeat cambia temporalmente a InfiniBand y regresa en 10 segundos cuando se restablece.
Configuración de host
Para garantizar la tolerancia a fallos y aumentar el rendimiento, debe habilitar el soporte de MPIO para la matriz. Para hacer esto, agregue líneas al archivo /etc/multipath.conf y luego vuelva a cargar el servicio multirruta
Texto ocultodispositivos {
dispositivo {
vendedor "AStor"
path_grouping_policy "group_by_prio"
path_selector "longitud de cola 0"
path_checker "tur"
cuenta con "0"
hardware_handler "0"
prio "const"
recuperación inmediata
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names sí
detect_prio si
rr_min_io_rq 1
no_path_retry 0
}
}
A continuación, para que ASM funcione con MPIO a través de ASMLib, debe modificar el archivo / etc / sysconfig / oracleasm y luego ejecutar /etc/init.d/oracleasm scandisks
Texto oculto# ORACLEASM_SCANORDER: patrones coincidentes para ordenar el escaneo de disco
ORACLEASM_SCANORDER = "dm"
# ORACLEASM_SCANEXCLUDE: patrones coincidentes para excluir discos del escaneo
ORACLEASM_SCANEXCLUDE = "sd"
Nota
Si no desea usar ASMLib, puede usar 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 la instalación como parte del software ASMFD.
Asegúrese de asegurarse de que los discos creados para Oracle ASM estén alineados con el tamaño del bloque con el que la matriz está trabajando físicamente (4K). De lo contrario, pueden ocurrir problemas de rendimiento. Por lo tanto, debe crear volúmenes con los parámetros apropiados:
parted / dev / mapper / device-name mklabel gpt mkpart primary 2048s 100% align-check óptimo 1
Distribución de bases de datos en volúmenes creados para nuestra configuración de prueba
| Nombre del volumen de almacenamiento | Tamaño del volumen | Mapeo de LUN de volumen | Detalle del dispositivo de volumen ASM | Tamaño de la unidad de asignación |
|---|
| Data01 | 200GB | Asigne todos los volúmenes de almacenamiento al sistema de almacenamiento todos los puertos de datos | Redundancia: normal
Nombre: DGDATA
Propósito: archivos de datos
| 4MB |
| Datos02 | 200GB |
| Datos03 | 200GB |
| Datos04 | 200GB |
| Datos05 | 200GB |
| Datos06 | 200GB |
| Datos07 | 200GB |
| Datos08 | 200GB |
| Data09 | 200GB |
| Datos10 | 200GB |
| Rejilla01 | 1GB | Redundancia: normal
Nombre: DGGRID1
Propósito: Cuadrícula: CRS y votación
| 4MB |
| Rejilla02 | 1GB |
| Rejilla03 | 1GB |
| Rejilla04 | 1GB | Redundancia: normal
Nombre: DGGRID2
Propósito: Cuadrícula: CRS y votación
| 4MB |
| Rejilla05 | 1GB |
| Rejilla06 | 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 |
Configuraciones de base de datos- Tamaño de bloque = 8K
- Espacio de intercambio = 16 GB
- Desactivar AMM (gestión automática de memoria)
- Deshabilitar páginas transparentes enormes
Otras configuraciones# 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 32000100128
✓ 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 # no establezca esto si está utilizando Linux x86
✓ vm.vfs_cache_pressure = 200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ rejilla suave nproc 2047
✓ rejilla rígida nproc 16384
✓ grid soft nofile 1024
✓ rejilla rígida nofile 65536
✓ rejilla soft stack 10240
✓ pila rígida de rejilla 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ nofile duro oracle 65536
✓ pila suave oracle 10240
✓ pila dura oracle 32768
✓ memlock suave 120795954
✓ memlock duro 120795954
sqlplus "/ como sysdba"
alterar procesos establecidos del sistema = 2000 alcance = 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;
Prueba de tolerancia a fallos
Para fines de demostración, se usó HammerDB para emular la carga OLTP. Configuración de HammerDB:
| Cantidad de almacenes | 256 |
| Transacciones totales por usuario | 1000000000000 |
| Usuarios virtuales | 256 |
Como resultado, se obtuvo el indicador 2.1M TPM, que está lejos del límite de rendimiento de la matriz H710 , pero es el "techo" para la configuración actual de hardware 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 como un todo, y no lograr el máximo rendimiento. Por lo tanto, simplemente construiremos sobre esta figura.
Prueba de falla de uno de los nodos
Los hosts perdieron algunos de los caminos a la tienda, y continuaron trabajando a través de los restantes con el segundo nodo. El rendimiento bajó durante unos segundos debido a la reestructuración de los caminos y luego volvió a la normalidad. No se produjo interrupción del 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 las rutas, y luego volvió a la mitad del valor del indicador original. El resultado se redujo a la mitad del original debido a la exclusión de la operación de un servidor de aplicaciones. La interrupción del servicio tampoco sucedió.
Si necesita implementar una solución de recuperación de desastres Cross-Rack tolerante a fallas para Oracle a un costo razonable y con poco esfuerzo de implementación / administración, entonces trabajar junto con Oracle RAC y la arquitectura AccelStor Shared-Nothing sería una de las mejores opciones. En lugar de Oracle RAC, puede haber cualquier otro software que proporcione agrupación, el mismo DBMS o sistemas de virtualización, por ejemplo. El principio de construir la solución seguirá siendo el mismo. Y el puntaje final es cero para RTO y RPO.