El teorema CAP es la piedra angular de la teoría de sistemas distribuidos. Por supuesto, la controversia que lo rodea no disminuye: las definiciones que contiene no son canónicas y no existe una prueba estricta... Sin embargo, apoyándonos firmemente en las posiciones del sentido común cotidiano™, entendemos intuitivamente que el teorema es verdadero.
Lo único que no es obvio es el significado de la letra "P". Cuando el clúster se divide, decide si no responder hasta alcanzar el quórum o devolver los datos que estén disponibles. Dependiendo de los resultados de esta elección, el sistema se clasifica como CP o AP. Cassandra, por ejemplo, puede comportarse de cualquier 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 divide, ¿entonces qué?
La respuesta a esta pregunta es algo inesperada: un clúster de CA no se puede dividir.
¿Qué clase de grupo es éste que no puede dividirse?
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 capaces de mantener una infraestructura SAN. Para que varios servidores funcionen con los mismos datos, se requiere un sistema de archivos en clúster. Estos sistemas de archivos están disponibles en las carteras HPE (CFS), Veritas (VxCFS) e IBM (GPFS).
RAC de Oracle
La opción Real Application Cluster apareció por primera vez en 2001 con el lanzamiento de Oracle 9i. En dicho clúster, varias instancias de servidor trabajan con la misma base de datos.
Oracle puede trabajar tanto con un sistema de archivos en clúster como con su propia solución: ASM, Gestión automática de almacenamiento.
Cada copia lleva su propio diario. La transacción es ejecutada y confirmada por una instancia. Si una instancia falla, uno de los nodos del clúster supervivientes (instancias) lee su registro y restaura los datos perdidos, garantizando así la disponibilidad.
Todas las instancias mantienen su propio caché y las mismas páginas (bloques) pueden estar en los cachés de varias instancias al mismo tiempo. Además, si una instancia necesita una página y está en la caché de otra instancia, puede obtenerla de su vecina utilizando el mecanismo de fusión de caché en lugar de leerla desde el disco.
Pero, ¿qué sucede si una de las instancias necesita cambiar 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. Gracias a este enfoque, Oracle es el campeón de rendimiento entre las bases de datos monolíticas: el servicio de bloqueo nunca se convierte en un cuello de botella. Pero en una configuración de clúster, dicha arquitectura puede provocar un intenso tráfico de red y bloqueos.
Una vez que se bloquea un registro, una instancia notifica a todas las demás instancias que la página que almacena ese registro tiene una retención exclusiva. 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 un diario en el disco (y la transacción puede continuar). También puede suceder que una página se cambie secuencialmente mediante varias copias y luego, al escribir la página en el disco, tendrá que averiguar quién almacena la versión actual de esta página.
La actualización aleatoria de las mismas páginas en diferentes nodos RAC hace que el rendimiento de la base de datos disminuya drásticamente, hasta el punto de que el rendimiento del clúster puede ser inferior al de una sola instancia.
El uso correcto de Oracle RAC es particionar físicamente los datos (por ejemplo, utilizando un mecanismo de tabla particionada) y acceder a cada conjunto de particiones a través de un nodo dedicado. El objetivo principal de RAC no era el escalamiento horizontal, sino garantizar la tolerancia a fallas.
Si un nodo deja de responder a un latido, entonces el nodo que lo detectó inicia primero un procedimiento de votación en el disco. Si el nodo que falta no se indica 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, verificando simultáneamente si otros nodos tienen versiones más recientes de las páginas que se están cambiando;
- revierte las transacciones pendientes.
Para simplificar el cambio entre nodos, Oracle tiene el concepto de servicio: una instancia virtual. Una instancia puede prestar servicios a múltiples servicios y un servicio puede moverse entre nodos. Una instancia de aplicación que sirve a una determinada parte de la base de datos (por ejemplo, un grupo de clientes) funciona con un servicio y el servicio responsable de esta parte de la base de datos se traslada a otro nodo cuando un nodo falla.
IBM Pure Data Systems para transacciones
En 2009 apareció en la cartera de Blue Giant una solución de clúster para DBMS. Ideológicamente, es el sucesor del clúster Parallel Sysplex, construido sobre equipos "normales". En 2009, DB2 pureScale se lanzó como un paquete de software y, en 2012, IBM ofreció un dispositivo llamado Pure Data Systems for Transactions. No debe confundirse con Pure Data Systems for Analytics, que no es más que un Netezza rebautizado.
A primera vista, la arquitectura pureScale es similar a Oracle RAC: de la misma manera, varios nodos están conectados a un sistema de almacenamiento de datos común y cada nodo ejecuta su propia instancia de 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 un 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;
- área de comunicaciones entre procesos.
Para transferir datos desde PowerHA a los nodos de la base de datos y viceversa, se utiliza el acceso a la memoria remota, por lo que la interconexión del clúster debe admitir el protocolo RDMA. PureScale puede utilizar tanto Infiniband como RDMA a través de Ethernet.
Si un nodo necesita una página y esta página no está en la memoria caché, entonces el nodo solicita la página en la memoria caché global y, solo si no está allí, la lee del disco. A diferencia de Oracle, la solicitud se dirige únicamente a PowerHA y no a los nodos vecinos.
Si una instancia va a cambiar una fila, la bloquea en modo exclusivo y la página donde se encuentra la fila en modo compartido. Todos los bloqueos se registran en el administrador de bloqueo 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 en la que se encuentra la fila modificada ya está bloqueada, entonces el administrador de bloqueo leerá la página modificada de la memoria del nodo que realizó el cambio, liberará el bloqueo, invalidará la página modificada en las cachés de otros nodos y dar 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 se completaron en el momento del error: las páginas modificadas por ese nodo en las transacciones completadas están en la caché global de PowerHA. El nodo se reinicia en una configuración reducida en uno de los servidores del clúster, revierte las transacciones pendientes y libera bloqueos.
PowerHA se ejecuta en dos servidores y el nodo maestro replica su estado de forma sincrónica. Si el nodo principal de PowerHA falla, el clúster continúa funcionando con el nodo de respaldo.
Por supuesto, si accede al conjunto de datos a través de un solo nodo, el rendimiento general del clúster será mayor. PureScale puede incluso notar que un nodo está procesando un área determinada de datos, y luego el nodo procesará todos los bloqueos relacionados con esa área localmente sin comunicarse 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.
Las pruebas internas de IBM en una carga de trabajo de 90% de lectura y 10% de escritura, que es muy similar a las cargas de trabajo de producción del mundo real, muestran un escalamiento casi lineal hasta 128 nodos. Desafortunadamente, las condiciones de prueba no se divulgan.
HPE SQL sin parar
La cartera de Hewlett-Packard Enterprise también tiene su propia plataforma de alta disponibilidad. Se trata de la plataforma NonStop, lanzada al mercado en 1976 por Tandem Computers. En 1997, la empresa 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, un sistema de almacenamiento de datos y equipos de comunicación. La red ServerNet (en sistemas modernos, Infiniband) sirve tanto para el intercambio entre nodos como para el acceso al sistema de almacenamiento de datos.
Las primeras versiones del sistema utilizaban procesadores propietarios que se sincronizaban entre sí: todas las operaciones se realizaban sincrónicamente mediante varios procesadores y, tan pronto como uno de los procesadores cometía un error, 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 para la sincronización:
- mensajes: cada proceso del sistema tiene un gemelo "sombra", al cual el proceso activo envía periódicamente mensajes sobre su estado; si el proceso principal falla, el proceso sombra comienza a funcionar desde el momento determinado por el último mensaje;
- votación: el sistema de almacenamiento tiene un componente de hardware especial que acepta múltiples accesos idénticos y los ejecuta solo si los accesos coinciden; En lugar de sincronización física, los procesadores funcionan de forma asíncrona y los resultados de su trabajo se comparan sólo en los momentos de E/S.
Desde 1987, se ejecuta 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 de Administrador de acceso a datos (DAM). Proporciona mecanismos de registro, almacenamiento en caché y bloqueo de datos. El procesamiento de datos lo llevan a cabo los Procesos del Servidor Ejecutor que se ejecutan en los mismos nodos que los administradores de datos correspondientes. El programador SQL/MX divide las tareas entre los ejecutores y agrega los resultados. Cuando es necesario realizar cambios acordados, se utiliza el protocolo de confirmación de dos fases proporcionado por la biblioteca TMF (Transaction Management Facility).
NonStop SQL puede priorizar procesos para que las consultas analíticas largas no interfieran con la ejecución de la transacción. Sin embargo, su finalidad es precisamente el procesamiento de transacciones cortas y no el análisis. 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) tuvo lugar en noviembre de 2010 y el paquete SAP ERP cambió a HANA en mayo de 2013. La plataforma se basa en tecnologías adquiridas: TREX Search Engine (búsqueda en almacenamiento en columnas), P*TIME DBMS y MAX DB.
La palabra "HANA" en sí misma es un acrónimo: Dispositivo analítico de alto rendimiento. Este DBMS se suministra en forma de código que puede ejecutarse en cualquier servidor x86; sin embargo, las instalaciones industriales solo están permitidas en equipos certificados. Soluciones disponibles de HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Algunas configuraciones de Lenovo incluso permiten el funcionamiento sin una SAN: el papel de un sistema de almacenamiento común lo desempeña un clúster GPFS en discos locales.
A diferencia de las plataformas enumeradas anteriormente, HANA es un DBMS en memoria, es decir, la imagen de datos principal 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 un desastre.
Cada nodo del clúster 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 no se duplican entre nodos. La información de bloqueo también se almacena en cada nodo, pero el sistema tiene un detector de bloqueo global.
Cuando un cliente HANA se conecta a un clúster, descarga su topología y luego puede acceder a cualquier nodo directamente, según los datos que necesite. Si una transacción afecta los datos de un solo nodo, entonces ese nodo puede ejecutarla localmente, pero si los datos de varios nodos cambian, el nodo iniciador contacta al nodo coordinador, que abre y coordina la transacción distribuida, comprometiéndola mediante un protocolo de confirmación de dos fases optimizado.
El nodo coordinador está duplicado, por lo que si el coordinador falla, el nodo de respaldo se hace cargo inmediatamente. Pero si un nodo con datos falla, entonces la única forma de acceder a sus datos es reiniciar el nodo. Como regla general, los clústeres de HANA mantienen un servidor de repuesto para reiniciar un nodo perdido lo más rápido posible.
Fuente: habr.com