Lo único que no es obvio es el significado de la letra "P". Cuando el clúster se divide, decide si no responder hasta que se alcance el quórum o dar los datos que sí. Dependiendo de los resultados de esta selección, el sistema se clasifica como CP o AP. Cassandra, por ejemplo, puede comportarse de esta o aquella manera, dependiendo ni siquiera de la configuración del clúster, sino de los parámetros de cada solicitud específica. Pero si el sistema no es "P" y se ha dividido, ¿entonces qué?
La respuesta a esta pregunta es algo inesperada: el clúster de CA no se puede dividir.
¿Qué es este grupo que no se puede dividir?
Un atributo indispensable de dicho clúster es un sistema de almacenamiento de datos compartido. En la gran mayoría de los casos, esto significa conectarse a través de una SAN, lo que limita el uso de soluciones de CA a grandes empresas que pueden contener una infraestructura SAN. Para que varios servidores puedan trabajar con los mismos datos, se requiere un sistema de archivos en clúster. Estos sistemas de archivos se encuentran en las carteras de HPE (CFS), Veritas (VxCFS) e IBM (GPFS).
Oracle RAC
La opción Real Application Cluster apareció por primera vez en la versión 2001 de Oracle 9i. En un clúster en el que varias instancias de servidor funcionan con la misma base de datos.
Oracle puede trabajar tanto con un sistema de archivos de clúster como con su propia solución: ASM, Automatic Storage Management.
Cada copia lleva su propio diario. La transacción se ejecuta y confirma en una instancia. En caso de falla de una instancia, uno de los nodos de clúster sobrevivientes (instancias) lee su registro y recupera los datos perdidos, asegurando así la disponibilidad.
Todas las instancias mantienen su propia caché y las mismas páginas (bloques) pueden estar simultáneamente en las cachés de varias instancias. Además, si una instancia necesita una página y está en la caché de otra instancia, puede obtenerla del "vecino" mediante el mecanismo de fusión de caché en lugar de leer desde el disco.
Pero, ¿qué sucede si una de las instancias necesita cambiar los datos?
La peculiaridad de Oracle es que no tiene un servicio de bloqueo dedicado: si el servidor quiere bloquear una fila, entonces el registro de bloqueo se coloca directamente en la página de memoria donde se encuentra la fila bloqueada. Este enfoque convierte a Oracle en el campeón de rendimiento de la base de datos monolítica: el servicio de bloqueo nunca se convierte en un cuello de botella. Pero en una configuración en clúster, esta arquitectura puede generar un tráfico de red intenso y puntos muertos.
Tan pronto como se bloquea un registro, la instancia notifica a todas las demás instancias que la página que almacena el registro se ha adquirido en modo exclusivo. Si otra instancia necesita cambiar un registro en la misma página, debe esperar hasta que se confirmen los cambios en la página, es decir, la información del cambio se escribe en el registro del disco (y la transacción puede continuar). También puede suceder que la página sea cambiada secuencialmente por varias copias, y luego, al escribir la página en el disco, tendrás que averiguar quién tiene la versión actual de esta página.
La actualización accidental de las mismas páginas en diferentes nodos RAC degrada drásticamente el rendimiento de la base de datos, hasta el punto en que el rendimiento del clúster puede ser más lento que el de una sola instancia.
El uso correcto de Oracle RAC es particionar datos físicamente (por ejemplo, usando el mecanismo de tabla particionada) y acceder a cada conjunto de particiones a través de un nodo dedicado. El propósito principal de RAC no era el escalado horizontal, sino proporcionar tolerancia a fallas.
Si un nodo deja de responder a los latidos, el nodo que detecta esto primero inicia el procedimiento de votación del disco. Si el nodo faltante no se anotó aquí, entonces uno de los nodos asume la responsabilidad de la recuperación de datos:
- "Congela" todas las páginas que estaban en la caché del nodo faltante;
- Lee los registros (rehacer) del nodo que falta y vuelve a aplicar los cambios registrados en estos registros, mientras verifica si otros nodos tienen versiones más recientes de las páginas modificadas;
- revierte transacciones no comprometidas.
Para simplificar el cambio entre nodos, Oracle tiene el concepto de un servicio: una instancia virtual. Una instancia puede prestar servicios a varios servicios y un servicio puede moverse entre nodos. Una instancia de aplicación que sirve a una determinada parte de la base (por ejemplo, un grupo de clientes) funciona con un servicio, y el servicio responsable de esta parte de la base, cuando falla un nodo, se mueve a otro nodo.
IBM Pure Data Systems para transacciones
La solución de clúster para DBMS apareció en la cartera de Blue Giant en 2009. Ideológicamente, es el heredero del clúster Parallel Sysplex construido sobre hardware "convencional". En 2009, DB2 pureScale se lanzó como una suite de software, y en 2012 IBM ofrece un dispositivo llamado Pure Data Systems for Transactions. No debe confundirse con Pure Data Systems for Analytics, que no es más que el renombrado Netezza.
La arquitectura pureScale se parece a Oracle RAC a primera vista: de la misma manera, varios nodos están conectados a un sistema de almacenamiento compartido y cada nodo ejecuta su propia instancia de un DBMS con sus propias áreas de memoria y registros de transacciones. Pero a diferencia de Oracle, DB2 tiene un servicio de bloqueo dedicado representado por el conjunto de procesos db2LLM *. En una configuración de clúster, este servicio se coloca en un nodo separado, que se denomina instalación de acoplamiento (CF) en Parallel Sysplex y PowerHA en Pure Data.
PowerHA proporciona los siguientes servicios:
- administrador de bloqueo;
- caché de búfer global;
- el área de las comunicaciones entre procesos.
El acceso a memoria remota se utiliza para transferir datos desde PowerHA a los nodos de la base de datos y viceversa, por lo que la interconexión del clúster debe admitir el protocolo RDMA. PureScale puede utilizar Infiniband y RDMA a través de Ethernet.
Si un nodo necesita una página, y esta página no está en la caché, entonces el nodo solicita una página en la caché global, y solo si no está allí, la lee del disco. A diferencia de Oracle, la consulta solo va a PowerHA y no a los nodos vecinos.
Si la instancia está a punto de cambiar la cadena, la bloquea en modo exclusivo y la página donde reside la cadena en modo compartido. Todos los bloqueos se registran en el administrador de bloqueos global. Cuando se completa la transacción, el nodo envía un mensaje al administrador de bloqueos, que copia la página modificada en la caché global, libera los bloqueos e invalida la página modificada en las cachés de otros nodos.
Si la página que contiene la cadena modificada ya está bloqueada, entonces el administrador de bloqueo leerá la página modificada de la memoria del nodo que realizó los cambios, liberará el bloqueo, invalidará la página modificada en las cachés de otros nodos y otorgará el bloqueo de página al nodo que lo solicitó.
Las páginas "sucias", es decir, modificadas, se pueden escribir en el disco tanto desde un nodo normal como desde PowerHA (castout).
Si uno de los nodos pureScale falla, la recuperación se limita solo a aquellas transacciones que aún no estaban completas en el momento del error: las páginas modificadas por ese nodo en las transacciones completadas están en la caché global en PowerHA. El nodo se reinicia en una configuración simplificada en uno de los servidores del clúster, revierte transacciones no confirmadas y libera bloqueos.
PowerHA se ejecuta en dos servidores y el nodo principal replica su estado de forma sincrónica. Si el nodo principal de PowerHA falla, el clúster continúa funcionando con el nodo en espera.
Por supuesto, si accede al conjunto de datos a través de un solo nodo, el rendimiento general del clúster será mejor. PureScale puede incluso notar que un nodo está procesando un área de datos, y luego todos los bloqueos relacionados con esta área serán procesados por el nodo localmente sin comunicación con PowerHA. Pero tan pronto como la aplicación intente acceder a estos datos a través de otro nodo, se reanudará el procesamiento de bloqueo centralizado.
Los puntos de referencia internos de IBM con un 90% de carga de trabajo de lectura y un 10% de escritura, muy similar a una carga de producción real, muestran un escalado casi lineal hasta 128 nodos. Las condiciones de prueba, lamentablemente, no fueron reveladas.
HPE NonStop SQL
La cartera de Hewlett-Packard Enterprise también tiene su propia plataforma de alta disponibilidad. Esta es la plataforma NonStop lanzada en 1976 por Tandem Computers. En 1997, la compañía fue adquirida por Compaq, que a su vez se fusionó con Hewlett-Packard en 2002.
NonStop se utiliza para crear aplicaciones críticas, por ejemplo, HLR o procesamiento de tarjetas bancarias. La plataforma se entrega en forma de un complejo de software y hardware (dispositivo), que incluye nodos informáticos, sistema de almacenamiento de datos y equipos de comunicación. ServerNet (en sistemas modernos, Infiniband) sirve tanto para el intercambio entre nodos como para el acceso al sistema de almacenamiento de datos.
Las versiones anteriores del sistema usaban procesadores propietarios que estaban sincronizados entre sí: todas las operaciones se realizaban sincrónicamente por varios procesadores, y tan pronto como uno de los procesadores se equivocaba, se apagaba y el segundo continuaba funcionando. Posteriormente, el sistema pasó a procesadores convencionales (primero MIPS, luego Itanium y finalmente x86), y se empezaron a utilizar otros mecanismos de sincronización:
- mensajes: cada proceso del sistema tiene un gemelo "sombra", al que el proceso activo envía periódicamente mensajes sobre su estado; si el proceso principal falla, el proceso de sombra comienza a funcionar desde el momento determinado por el último mensaje;
- : , , ; , /.
Desde 1987, se ha estado ejecutando un DBMS relacional en la plataforma NonStop: primero SQL / MP y luego SQL / MX.
Toda la base de datos está dividida en partes, y cada parte es responsable de su propio proceso Data Access Manager (DAM). Proporciona un mecanismo de bloqueo, almacenamiento en caché y escritura de datos. El procesamiento de datos es manejado por el Proceso del Servidor Ejecutor, que se ejecuta en los mismos nodos que los respectivos administradores de datos. El programador SQL / MX divide las tareas entre ejecutores y fusiona los resultados. Si necesita realizar cambios consistentes, utilice el protocolo de confirmación de dos fases proporcionado por la biblioteca TMF (Transaction Management Facility).
NonStop SQL sabe cómo priorizar procesos para que largas consultas analíticas no interfieran con la ejecución de transacciones. Sin embargo, su propósito es precisamente el procesamiento de transacciones cortas, no la analítica. El desarrollador garantiza la disponibilidad del clúster NonStop al nivel de cinco "nueves", es decir, el tiempo de inactividad es de solo 5 minutos por año.
SAP HANA
La primera versión estable de HANA DBMS (1.0) se llevó a cabo en noviembre de 2010 y el paquete SAP ERP se trasladó a HANA en mayo de 2013. La plataforma se basa en tecnologías adquiridas: TREX Search Engine (búsqueda en almacenamiento columnar), P * TIME y MAX DB.
La palabra "HANA" en sí es un acrónimo, Aparato analítico de alto rendimiento. Este DBMS se entrega en forma de código que puede ejecutarse en cualquier servidor x86, sin embargo, las instalaciones industriales solo se permiten en equipos certificados. Hay soluciones de HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Algunas configuraciones de Lenovo incluso permiten el funcionamiento sin una SAN: un clúster GPFS en discos locales desempeña la función de almacenamiento compartido.
A diferencia de las plataformas enumeradas anteriormente, HANA es un DBMS en memoria, es decir, la imagen principal de los datos se almacena en la RAM y solo los registros y las instantáneas periódicas se escriben en el disco para su recuperación en caso de desastre.
Cada nodo del clúster de HANA es responsable de su propia parte de los datos, y el mapa de datos se almacena en un componente especial, el servidor de nombres, ubicado en el nodo coordinador. Los datos entre nodos no se duplican. La información de bloqueo también se almacena en cada nodo, pero el sistema tiene un detector de interbloqueo global.
Un cliente HANA, cuando se conecta a un clúster, carga su topología y luego puede acceder directamente a cualquier nodo, según los datos que necesite. Si una transacción afecta los datos de un solo nodo, entonces este nodo puede realizarla localmente, pero si los datos de varios nodos cambian, entonces el nodo iniciador contacta con el nodo coordinador, que abre y coordina la transacción distribuida, comprometiéndola usando un protocolo optimizado de confirmación de dos fases.
El nodo coordinador está duplicado, por lo que en caso de falla del coordinador, el nodo de respaldo se hace cargo de inmediato. Pero si un nodo con datos falla, la única forma de acceder a sus datos es reiniciar el nodo. Como regla general, en los clústeres de HANA se mantiene un servidor de repuesto para reiniciar el nodo perdido lo antes posible.