sql >> Base de Datos >  >> RDS >> MariaDB

Comparación de la solución Oracle RAC HA con Galera Cluster para MySQL o MariaDB

Las empresas siempre han deseado obtener conocimientos de la información para tomar decisiones confiables, más inteligentes, en tiempo real y basadas en hechos. A medida que las empresas confían más en los datos y las bases de datos, la información y el procesamiento de datos es el núcleo de muchas operaciones comerciales y decisiones comerciales. La fe en la base de datos es total. Ninguno de los servicios cotidianos de la empresa puede ejecutarse sin las plataformas de bases de datos subyacentes. Como consecuencia, la necesidad de escalabilidad y rendimiento del software del sistema de base de datos es más crítica que nunca. Los principales beneficios del sistema de base de datos en clúster son la escalabilidad y la alta disponibilidad. En este blog, intentaremos comparar Oracle RAC y Galera Cluster a la luz de estos dos aspectos. Real Application Clusters (RAC) es la solución premium de Oracle para agrupar bases de datos Oracle y proporciona alta disponibilidad y escalabilidad. Galera Cluster es la tecnología de agrupación en clústeres más popular para MySQL y MariaDB.

Descripción general de la arquitectura

Oracle RAC utiliza el software Oracle Clusterware para vincular varios servidores. Oracle Clusterware es una solución de administración de clústeres que se integra con Oracle Database, pero también se puede usar con otros servicios, no solo con la base de datos. Oracle Clusterware es un software adicional instalado en servidores que ejecutan el mismo sistema operativo, lo que permite que los servidores se encadenen para operar como si fueran un solo servidor.

Oracle Clusterware observa la instancia y la reinicia automáticamente si se produce un bloqueo. Si su aplicación está bien diseñada, es posible que no experimente ninguna interrupción del servicio. Solo un grupo de sesiones (aquellas conectadas a la instancia fallida) se ve afectado por la falla. El apagón se puede enmascarar de manera eficiente para el usuario final mediante funciones avanzadas de RAC, como la notificación rápida de aplicaciones y la conmutación por error de conexión rápida del cliente de Oracle. Oracle Clusterware controla la pertenencia a nodos y evita los síntomas de cerebro dividido en los que dos o más instancias intentan controlar la instancia.

Galera Cluster es una tecnología de agrupación de bases de datos activa-activa síncrona para MySQL y MariaDB. Galera Cluster se diferencia de lo que se conoce como MySQL Cluster de Oracle - NDB. El clúster de MariaDB se basa en el complemento de replicación multimaestro proporcionado por Codership. Desde la versión 5.5, el complemento Galera (API wsrep) es una parte integral de MariaDB. Percona XtraDB Cluster (PXC) también se basa en el complemento Galera. La arquitectura del complemento de Galera se basa en tres capas principales:certificación, replicación y marco de comunicación grupal. La capa de certificación prepara los conjuntos de escritura y realiza las comprobaciones de certificación sobre ellos, lo que garantiza que se puedan aplicar. La capa de replicación administra el protocolo de replicación y proporciona la capacidad de pedido total. Group Communication Framework implementa una arquitectura de complementos que permite que otros sistemas se conecten a través del esquema de back-end de gcomm.

Para mantener el estado idéntico en todo el clúster, la API de wsrep utiliza un ID de transacción global. El identificador único de GTID se crea y asocia con cada transacción confirmada en el nodo de la base de datos. En Oracle RAC, varias instancias de bases de datos comparten el acceso a recursos como bloques de datos en la memoria caché del búfer para poner en cola los bloques de datos. El acceso a los recursos compartidos entre las instancias de RAC debe coordinarse para evitar conflictos. Para organizar el acceso compartido a estos recursos, la caché distribuida mantiene información como el ID del bloque de datos, qué instancia de RAC contiene la versión actual de este bloque de datos y el modo de bloqueo en el que cada instancia contiene el bloque de datos.

Conceptos clave de almacenamiento de datos

Oracle RAC se basa en una arquitectura de disco distribuido. Los archivos de la base de datos, los archivos de control y los registros de rehacer en línea para la base de datos deben ser accesibles para cada nodo del clúster. Existe una variedad de formas de configurar el almacenamiento compartido, incluidos los discos conectados directamente, las redes de área de almacenamiento (SAN) y el almacenamiento conectado a la red (NAS) y Oracle ASM. Los dos más populares son OCFS y ASM. Oracle Cluster File System (OCFS) es un sistema de archivos compartido diseñado específicamente para Oracle RAC. OCFS elimina el requisito de que los archivos de la base de datos de Oracle estén conectados a unidades lógicas y permite que todos los nodos compartan un único dispositivo Oracle Home ASM, RAW. Oracle ASM es la solución de administración de almacenamiento recomendada por Oracle que ofrece una alternativa a los administradores de volúmenes, sistemas de archivos y dispositivos sin procesar convencionales. Oracle ASM proporciona una capa de virtualización entre la base de datos y el almacenamiento. Trata varios discos como un solo grupo de discos y le permite agregar o quitar unidades dinámicamente mientras mantiene las bases de datos en línea.

No es necesario crear un almacenamiento de disco compartido sofisticado para Galera, ya que cada nodo tiene su copia completa de datos. Sin embargo, es una buena práctica hacer que el almacenamiento sea confiable con cachés de escritura respaldados por batería.

Oracle RAC, almacenamiento en clúster Replicación de Galera, discos conectados a nodos de base de datos

Comunicación y caché de los nodos del clúster

Oracle Real Application Clusters tiene una arquitectura de caché compartida, utiliza Oracle Grid Infrastructure para permitir el uso compartido de servidores y recursos de almacenamiento. La comunicación entre nodos es el aspecto crítico de la integridad del clúster. Cada nodo debe tener al menos dos adaptadores de red o tarjetas de interfaz de red:uno para la interfaz de red pública y otro para la interconexión. Cada nodo del clúster está conectado a todos los demás nodos a través de una red privada de alta velocidad, también reconocida como la interconexión del clúster.

Oracle RAC, arquitectura de red

La red privada generalmente se forma con Gigabit Ethernet, pero para entornos de alto volumen, muchos proveedores ofrecen soluciones de baja latencia y alto ancho de banda diseñadas para Oracle RAC. Linux también amplía un medio para vincular varias NIC físicas en una sola NIC virtual para proporcionar un mayor ancho de banda y disponibilidad.

Si bien el enfoque predeterminado para conectar los nodos de Galera es usar una sola NIC por host, puede tener más de una tarjeta. ClusterControl puede ayudarlo con dicha configuración. La principal diferencia es el requisito de ancho de banda en la interconexión. Oracle RAC envía bloques de datos entre instancias, por lo que coloca una carga más pesada en la interconexión en comparación con los conjuntos de escritura de Galera (que consisten en una lista de operaciones).

Con el uso de interconexión redundante en RAC, puede identificar múltiples interfaces para usar en la red de clústeres privados, sin necesidad de usar vinculación u otras tecnologías. Esta funcionalidad está disponible a partir de Oracle Database 11gR2. Si utiliza la función de interconexión excesiva de Oracle Clusterware, debe utilizar direcciones IPv4 para las interfaces (UDP es un valor predeterminado).

Para administrar la alta disponibilidad, a cada nodo del clúster se le asigna una dirección IP virtual (VIP). En caso de falla del nodo, la dirección IP del nodo fallido se puede reasignar a un nodo sobreviviente para permitir que las aplicaciones continúen llegando a la base de datos a través de la misma dirección IP.

La configuración de red sofisticada es necesaria para que la tecnología Cache Fusion de Oracle acople la memoria física en cada host en un solo caché. Oracle Cache Fusion proporciona datos almacenados en la memoria caché de una instancia de Oracle para que cualquier otra instancia pueda acceder a ellos transportándolos a través de la red privada. También protege la integridad de los datos y la coherencia de la memoria caché mediante la transmisión de información de bloqueo y sincronización adicional más allá de los nodos del clúster.

Además de la configuración de red descrita, puede establecer una única dirección de base de datos para su aplicación:Nombre de acceso de cliente único (SCAN). El objetivo principal de SCAN es facilitar la administración de la conexión. Por ejemplo, puede agregar nuevos nodos al clúster sin cambiar la cadena de conexión de su cliente. Esta funcionalidad se debe a que Oracle distribuirá automáticamente las solicitudes en función de las IP de ESCANEO que apuntan a los VIP subyacentes. Los oyentes de exploración hacen de puente entre los clientes y los oyentes locales subyacentes que dependen de VIP.

Para Galera Cluster, el equivalente de SCAN sería agregar un proxy de base de datos frente a los nodos de Galera. El proxy sería un único punto de contacto para las aplicaciones, puede incluir en la lista negra los nodos fallidos y enrutar las consultas a los nodos en buen estado. El propio proxy se puede hacer redundante con Keepalived y Virtual IP.

Conmutación por error y recuperación de datos

La principal diferencia entre Oracle RAC y MySQL Galera Cluster es que Galera no comparte arquitectura. En lugar de discos compartidos, Galera utiliza la replicación basada en certificación con comunicación grupal y ordenación de transacciones para lograr la replicación síncrona. Un clúster de base de datos debería poder sobrevivir a la pérdida de un nodo, aunque se logra de diferentes maneras. En el caso de Galera, el aspecto crítico es la cantidad de nodos, Galera requiere un quórum para mantenerse operativo. Un clúster de tres nodos puede sobrevivir al bloqueo de un nodo. Con más nodos en su clúster, su disponibilidad aumentará. Oracle RAC no requiere un quórum para permanecer operativo después de un bloqueo del nodo. Es debido al acceso al almacenamiento distribuido que mantiene información consistente sobre el estado del clúster. Sin embargo, su almacenamiento de datos podría ser un punto potencial de falla en su plan de alta disponibilidad. Si bien es una tarea razonablemente sencilla tener nodos de clúster de Galera distribuidos en centros de datos de geolocalización, no sería tan fácil con RAC. Oracle RAC requiere duplicación de disco de gama alta adicional; sin embargo, se puede lograr una redundancia básica similar a RAID dentro de un grupo de discos ASM.

Tipo de grupo de discos Niveles de duplicación admitidos Nivel de duplicación predeterminado
Redundancia externa Desprotegido (ninguno) Desprotegido
Redundancia normal Bidireccional, tridireccional, sin protección (ninguno) Bidireccional
Alta redundancia Tres vías Tres vías
Redundancia flexible Bidireccional, tridireccional, sin protección (ninguno) Bidireccional (recién creado)
Redundancia extendida Bidireccional, tridireccional, sin protección (ninguno) Bidireccional
Redundancia de grupo de discos ASM

Esquemas de bloqueo

En una base de datos de un solo usuario, un usuario puede modificar los datos sin preocuparse de que otras sesiones modifiquen los mismos datos al mismo tiempo. Sin embargo, en un entorno de múltiples nodos de base de datos de múltiples usuarios, esto se vuelve más complicado. Una base de datos multiusuario debe proporcionar lo siguiente:

  • concurrencia de datos:la seguridad de que los usuarios pueden acceder a los datos al mismo tiempo,
  • coherencia de los datos:la seguridad de que cada usuario ve una vista coherente de los datos.

Las instancias de clúster requieren tres tipos principales de bloqueo de simultaneidad:

  • Lectura de simultaneidad de datos en diferentes instancias,
  • La simultaneidad de datos lee y escribe en diferentes instancias,
  • La simultaneidad de datos escribe en diferentes instancias.

Oracle le permite elegir la política de bloqueo, ya sea pesimista u optimista, según sus requisitos. Para obtener el bloqueo de concurrencia, RAC tiene dos búferes adicionales. Son Global Cache Service (GCS) y Global Enqueue Service (GES). Estos dos servicios cubren el proceso de Cache Fusion, las transferencias de recursos y las escaladas de recursos entre las instancias. GES incluye bloqueos de caché, bloqueos de diccionario, bloqueos de transacciones y bloqueos de tablas. GCS mantiene los modos de bloqueo y las transferencias de bloques entre las instancias.

En el clúster de Galera, cada nodo tiene su almacenamiento y búfer. Cuando se inicia una transacción, los recursos de la base de datos locales de ese nodo están involucrados. En el momento de la confirmación, las operaciones que forman parte de esa transacción se transmiten como parte de un conjunto de escritura al resto del grupo. Dado que todos los nodos tienen el mismo estado, el conjunto de escritura tendrá éxito en todos los nodos o fallará en todos los nodos.

Galera Cluster utiliza un control de concurrencia optimista a nivel de clúster, que puede aparecer en transacciones que resultan en un aborto de COMMIT. El primer compromiso gana. Cuando se producen anulaciones a nivel de clúster, Galera Cluster genera un error de interbloqueo. Esto puede o no afectar la arquitectura de su aplicación. Una gran cantidad de filas para replicar en una sola transacción afectaría las respuestas de los nodos, aunque existen técnicas para evitar ese comportamiento.

Requisitos de hardware y software

La configuración del hardware de ambos clústeres no requiere recursos potentes. La configuración mínima del clúster Oracle RAC estaría satisfecha con dos servidores con dos CPU, memoria física de al menos 1,5 GB de RAM, una cantidad de espacio de intercambio igual a la cantidad de RAM y dos NIC Gigabit Ethernet. La configuración mínima de nodos de Galera es de tres nodos (uno de los nodos puede ser un árbitro, gardb), cada uno con una CPU de un solo núcleo de 1 GHz, 512 MB de RAM y una tarjeta de red de 100 Mbps. Si bien estos son los mínimos, podemos decir con seguridad que en ambos casos probablemente le gustaría tener más recursos para su sistema de producción.

Cada nodo almacena software, por lo que deberá preparar varios gigabytes de su almacenamiento. Tanto Oracle como Galera tienen la capacidad de parchear individualmente los nodos derribándolos uno a la vez. Este parche continuo evita una interrupción completa de la aplicación, ya que siempre hay nodos de base de datos disponibles para manejar el tráfico.

Lo que es importante mencionar es que un clúster Galera de producción puede ejecutarse fácilmente en VM o bare metal básico, mientras que RAC necesitaría una inversión en almacenamiento compartido sofisticado y comunicación por fibra.

Monitoreo y Gestión

Oracle Enterprise Manager es el enfoque preferido para monitorear Oracle RAC y Oracle Clusterware. Oracle Enterprise Manager es un sistema de administración unificado basado en Web de Oracle para monitorear y administrar su entorno de base de datos. Es parte de Oracle Enterprise License y debe instalarse en un servidor separado. El monitoreo y la administración del control de clúster se realizan mediante la combinación de los comandos crsctl y srvctl que forman parte de los binarios del clúster. A continuación puede encontrar un par de comandos de ejemplo.

Comprobación del estado de los recursos de Clusterware:

    crsctl status resource -t (or shorter: crsctl stat res -t)

Ejemplo:

$ crsctl stat res ora.test1.vip
NAME=ora.test1.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=ONLINE on test1

Compruebe el estado de la pila de Oracle Clusterware:

    crsctl check cluster

Ejemplo:

$ crsctl check cluster -all
*****************************************************************
node1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
*****************************************************************
node2:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Compruebe el estado de los servicios de alta disponibilidad de Oracle y la pila de Oracle Clusterware en el servidor local:

    crsctl check crs

Ejemplo:

$ crsctl check crs
CRS-4638: Oracle High Availablity Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Detenga los servicios de alta disponibilidad de Oracle en el servidor local.

    crsctl stop has

Detenga los servicios de alta disponibilidad de Oracle en el servidor local.

    crsctl start has

Muestra el estado de las aplicaciones del nodo:

    srvctl status nodeapps

Muestra la información de configuración para todos los VIP de SCAN

    srvctl config scan

Ejemplo:

srvctl config scan -scannumber 1
SCAN name: testscan, Network: 1
Subnet IPv4: 192.51.100.1/203.0.113.46/eth0, static
Subnet IPv6: 
SCAN 1 IPv4 VIP: 192.51.100.195
SCAN VIP is enabled.
SCAN VIP is individually enabled on nodes:
SCAN VIP is individually disabled on nodes:

La utilidad de verificación de clústeres (CVU) realiza comprobaciones del sistema en preparación para la instalación, actualizaciones de parches u otros cambios en el sistema:

    cluvfy comp ocr

Ejemplo:

Verifying OCR integrity
Checking OCR integrity...
Checking the absence of a non-clustered configurationl...
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc"...
OCR config file “/etc/oracle/ocr.loc" check successful
Disk group for ocr location “+DATA" available on all the nodes
NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck' as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

Los nodos de Galera y el clúster requieren la API de wsrep para informar sobre varios estados, que están expuestos. Actualmente hay 34 variables de estado dedicadas que se pueden ver con la declaración SHOW STATUS.

mysql> SHOW STATUS LIKE 'wsrep_%';
wsrep_apply_oooe
wsrep_apply_oool
wsrep_cert_deps_distance
wsrep_cluster_conf_id
wsrep_cluster_size
wsrep_cluster_state_uuid
wsrep_cluster_status
wsrep_conectado
wsrep_flow_control_paused
wsrep_flow_control_paused_ns
wsrep_flow_control_recv
wsrep_local_send_queue_avg
wsrep_local_state_uuid
wsrep_protocol_version
wsrep_provider_name
wsrep_provider_vendor
wsrep_provider_version
wsrep_flow_control_sent
wsrep_control_sent
wsrep_uuid wsrep_last_committed
wsrep_local_bf_aborts
wsrep_local_cert_failures
wsrep_local_commits
wsrep_local_index
wsrep_local_recv_queue
wsrep_local_recv_queue_avg
wsrep_local_replays
wsrep_local_send_queue
wsrep_ready
wsrep_received
wsrep_received_bytes
wsrep_replicated
wsrep_replicated_bytes
wsrep_thread_count

La administración de MySQL Galera Cluster en muchos aspectos es muy similar. Hay algunas excepciones, como arrancar el clúster desde el nodo inicial o recuperar nodos a través de operaciones SST o IST.

Clúster de arranque:

$ service mysql bootstrap # sysvinit
$ service mysql start --wsrep-new-cluster # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

La solución equivalente basada en la web y lista para usar para administrar y monitorear Galera Cluster es ClusterControl. Proporciona una interfaz basada en web para implementar clústeres, monitorea métricas clave, proporciona asesores de bases de datos y se ocupa de tareas de administración como respaldo y restauración, parches automáticos, encriptación de tráfico y administración de disponibilidad.

Restricciones en la carga de trabajo

Oracle proporciona la tecnología SCAN que encontramos que falta en Galera Cluster. El beneficio de SCAN es que la información de conexión del cliente no necesita cambiar si agrega o elimina nodos o bases de datos en el clúster. Cuando se usa SCAN, la base de datos de Oracle se conecta aleatoriamente a uno de los oyentes de SCAN disponibles (generalmente tres) en forma rotativa y equilibra las conexiones entre ellos. Se pueden configurar dos tipos de balanceo de carga:lado del cliente, balanceo de carga en tiempo de conexión y en el lado del servidor, balanceo de carga en tiempo de ejecución. Aunque no hay nada similar dentro del propio clúster de Galera, la misma funcionalidad se puede abordar con software adicional como ProxySQL, HAProxy, Maxscale combinado con Keepalived.

Cuando se trata del diseño de la carga de trabajo de la aplicación para Galera Cluster, debe evitar las actualizaciones en conflicto en la misma fila, ya que esto genera interbloqueos en todo el clúster. Evite las inserciones o actualizaciones masivas, ya que pueden ser más grandes que el conjunto de escritura máximo permitido. Eso también podría provocar que el clúster se detenga.

Al diseñar Oracle HA con RAC, debe tener en cuenta que RAC solo protege contra fallas del servidor, y necesita duplicar el almacenamiento y tener redundancia de red. Las aplicaciones web modernas requieren acceso a servicios de datos independientes de la ubicación y, debido a las limitaciones de la arquitectura de almacenamiento de RAC, puede ser difícil de lograr. También debe dedicar una cantidad considerable de tiempo para obtener conocimientos relevantes para administrar el medio ambiente; Es un proceso largo. En el lado de la carga de trabajo de la aplicación, existen algunos inconvenientes. La distribución de operaciones de lectura o escritura separadas en el mismo conjunto de datos no es óptima porque la latencia se agrega mediante el intercambio de datos de entrenudos suplementarios. Antes de migrar a RAC, se deben revisar aspectos como el particionamiento, la caché de secuencias y las operaciones de clasificación.

Redundancia de varios centros de datos

Según la documentación de Oracle, la distancia máxima entre dos cajas conectadas punto a punto y funcionando sincrónicamente puede ser de solo 10 km. Usando dispositivos especializados, esta distancia se puede aumentar a 100 km.

Galera Cluster es bien conocido por sus capacidades de replicación de múltiples centros de datos. Tiene un rico soporte para la configuración de red de redes de área amplia. Se puede configurar para una alta latencia de red tomando medidas de tiempo de ida y vuelta (RTT) entre los nodos del clúster y ajustando los parámetros necesarios. Los parámetros wsrep_provider_options le permiten configurar ajustes como sospechoso_tiempo de espera, tiempo de espera interactivo, unión_retrans_timouts y muchos más.

Uso de Galera y RAC en la nube

Según la nota de Oracle www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf, actualmente ninguna nube de terceros cumple con los requisitos de Oracle con respecto al almacenamiento compartido proporcionado de forma nativa. "Nativo" en este contexto significa que el proveedor de la nube debe admitir el almacenamiento compartido como parte de su infraestructura según la política de soporte de Oracle.

Gracias a su arquitectura de nada compartido, que no está vinculada a una solución de almacenamiento sofisticada, el clúster de Galera se puede implementar fácilmente en un entorno de nube. Cosas como:

  • protocolo de red optimizado,
  • replicación con reconocimiento de topología,
  • cifrado de tráfico,
  • detección y desalojo automático de nodos no confiables,

hace que el proceso de migración a la nube sea más confiable.

Licencias y costos ocultos

La licencia de Oracle es un tema complejo y requeriría un artículo de blog por separado. El factor clúster lo hace aún más difícil. El costo aumenta ya que tenemos que agregar algunas opciones para licenciar una solución RAC completa. Aquí solo queremos resaltar qué esperar y dónde encontrar más información.

RAC es una característica de la licencia Oracle Enterprise Edition. La licencia de Oracle Enterprise se divide en dos tipos, por usuario designado y por procesador. Si considera Enterprise Edition con licencia por núcleo, entonces el costo de un solo núcleo es RAC 23 000 USD + Oracle DB EE 47 500 USD, y aún debe agregar una tarifa de soporte de ~ 22 %. Nos gustaría referirnos a un excelente blog sobre precios que se encuentra en https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba calculó el precio de un Oracle RAC de cuatro nodos. El monto total fue de 902 400 USD más 595 584 USD adicionales por tres años de mantenimiento de la base de datos, y eso no incluye funciones como partición o base de datos en memoria, todo eso con un 60 % de descuento de Oracle.

Galera Cluster es una solución de código abierto que cualquiera puede ejecutar de forma gratuita. Las suscripciones están disponibles para implementaciones de producción que requieren soporte de proveedores. Puede encontrar un buen cálculo de TCO en https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Conclusión

Si bien existen diferencias significativas en la arquitectura, ambos clústeres comparten los principios fundamentales y pueden lograr objetivos similares. El producto empresarial de Oracle viene con todo listo para usar (y su precio). Con un costo en el rango de>1M USD como se ve arriba, es una solución de alto nivel que muchas empresas no podrían permitirse. Galera Cluster se puede describir como una solución decente de alta disponibilidad para las masas. En ciertos casos, Galera bien puede ser una muy buena alternativa a Oracle RAC. Un inconveniente es que tiene que construir su propia pila, aunque eso puede automatizarse completamente con ClusterControl. Nos encantaría escuchar su opinión sobre esto.