Un VMScluster , originalmente conocido como VAXcluster , es un clúster de computadoras que involucra un grupo de computadoras que ejecutan el sistema operativo OpenVMS . Mientras que los sistemas multiprocesador estrechamente acoplados ejecutan una sola copia del sistema operativo , un VMScluster está acoplado de manera flexible : cada máquina ejecuta su propia copia de OpenVMS, pero el almacenamiento en disco, el administrador de bloqueos y el dominio de seguridad son todos de todo el clúster, lo que proporciona una única abstracción de imagen del sistema. Las máquinas pueden unirse o abandonar un VMScluster sin afectar al resto del clúster. Para una mayor disponibilidad, los VMSclusters admiten el uso de discos de doble puerto conectados a dos máquinas o controladores de almacenamiento simultáneamente.
Digital Equipment Corporation (DEC) anunció por primera vez los VAXclusters en mayo de 1983. En esa etapa, la agrupación en clústeres requería hardware de comunicaciones especializado, así como algunos cambios importantes en los subsistemas de bajo nivel del sistema operativo VMS. El software y el hardware se diseñaron en conjunto. La compatibilidad con VAXclusters se agregó por primera vez en VAX/VMS V4.0, que se lanzó en 1984. Esta versión solo admitía la agrupación en clústeres a través de la interconexión informática (CI) patentada de DEC.
En el centro de cada grupo había un acoplador en estrella , al que cada nodo (computadora) y dispositivo de almacenamiento de datos del grupo estaba conectado mediante uno o dos pares de cables CI . Cada par de cables tenía una velocidad de transmisión de 70 megabits por segundo, una velocidad alta para esa época. El uso de dos pares daba una velocidad de transmisión agregada de 140 megabits por segundo, con redundancia en caso de que fallara un cable; los acopladores en estrella también tenían cableado redundante para una mejor disponibilidad.
Cada cable CI se conectaba a su ordenador a través de un puerto CI , que podía enviar y recibir paquetes sin la intervención de la CPU. Para enviar un paquete, una CPU solo tenía que crear una pequeña estructura de datos en la memoria y adjuntarla a una cola de "envío"; de manera similar, el puerto CI adjuntaría cada mensaje entrante a una cola de "recepción". Las pruebas mostraron que un VAX-11/780 podía enviar y recibir 3000 mensajes por segundo, aunque nominalmente era una máquina de 1 MIPS . El Protocolo de control de almacenamiento masivo (MSCP), estrechamente relacionado, permitía un rendimiento igualmente alto del subsistema de almacenamiento masivo. Además, los paquetes MSCP se transportaban fácilmente a través del CI, lo que permitía el acceso remoto a los dispositivos de almacenamiento.
VAXclustering fue uno de los primeros sistemas de agrupamiento en alcanzar el éxito comercial (junto con AT&T, Tandem Computers [1] [2] y Stratus Computers [3] ) y fue un importante argumento de venta para los sistemas VAX.
En 1986, DEC agregó soporte para VAXclustering a sus minicomputadoras MicroVAX , que se ejecutaban sobre Ethernet en lugar de hardware de propósito especial. Si bien no brindaban las ventajas de alta disponibilidad del hardware CI, estos VAXclusters de área local (LAVc) brindaban una vía de expansión atractiva para los compradores de minicomputadoras de gama baja. LAVc también permitía que los nodos satélite sin disco se iniciaran a través de la red utilizando el disco del sistema de un nodo de arranque .
Las versiones posteriores de OpenVMS (V5.0 y posteriores) admitieron VAXclusters de "interconexión mixta" (utilizando tanto CI como Ethernet) y VAXclustering sobre DSSI ( Digital Systems and Storage Interconnect ), SCSI y FDDI , entre otros transportes. Finalmente, a medida que se hicieron disponibles las redes de área extensa de gran ancho de banda, se amplió la agrupación en clústeres para permitir enlaces de datos satelitales y enlaces terrestres de larga distancia. Esto permitió la creación de clústeres tolerantes a desastres ; al ubicar el único VAXcluster en varias áreas geográficas diversas, el clúster podría sobrevivir a fallas de infraestructura y desastres naturales.
La introducción de servidores de terminales que utilizan el protocolo LAT facilitó enormemente la creación de VAXclustering . Al permitir que los terminales seriales comunes accedieran a los nodos host a través de Ethernet, cualquier terminal pudo conectarse rápida y fácilmente a cualquier nodo host. Esto hizo que fuera mucho más sencillo realizar la conmutación por error de los terminales de usuario de un nodo del clúster a otro.
La compatibilidad con clusters mediante TCP/IP se agregó en la versión 8.4 de OpenVMS, que se lanzó en 2010. Ahora que Gigabit Ethernet es común y se está introduciendo 10 Gigabit Ethernet , los cables y tarjetas de red estándar son suficientes para soportar la agrupación en clústeres de VMS.
OpenVMS admite hasta 96 nodos en un solo clúster y permite clústeres de arquitectura mixta, donde los sistemas VAX y Alpha, o los sistemas Alpha e Itanium pueden coexistir en un solo clúster (varias organizaciones han demostrado clústeres de arquitectura triple y configuraciones de clústeres con hasta 150 nodos, pero estas configuraciones no son compatibles oficialmente).
A diferencia de muchas otras soluciones de clustering, VMScluster ofrece lectura y escritura transparentes y totalmente distribuidas con bloqueo a nivel de registro, lo que significa que varios nodos del cluster pueden acceder al mismo disco e incluso al mismo archivo a la vez; el bloqueo se produce solo a nivel de un único registro de un archivo, que normalmente sería una línea de texto o un único registro en una base de datos. Esto permite la construcción de servidores de bases de datos con redundancia múltiple y alta disponibilidad.
Las conexiones de clúster pueden abarcar más de 500 millas (800 km), lo que permite que los nodos miembros estén ubicados en diferentes edificios de un campus de oficinas o en diferentes ciudades.
El sombreado de volúmenes basado en host permite que los volúmenes (del mismo tamaño o de diferentes tamaños) se sombreen (dupliquen) en múltiples controladores y múltiples hosts, lo que permite la construcción de entornos tolerantes a desastres.
Los programadores de aplicaciones tienen acceso total al administrador de bloqueos distribuidos (DLM), lo que permite que las aplicaciones coordinen recursos y actividades arbitrarios en todos los nodos del clúster. Esto incluye la coordinación a nivel de archivo, pero los recursos, las actividades y las operaciones que se pueden coordinar con el DLM son completamente arbitrarios.
Con la capacidad de actualizaciones continuas y múltiples discos de sistema, las configuraciones de clúster se pueden mantener en línea y actualizar de forma incremental. Esto permite que las configuraciones de clúster sigan brindando acceso a aplicaciones y datos mientras un subconjunto de los nodos miembro se actualizan a versiones de software más nuevas. [4] [5] Los tiempos de actividad de los clústeres se miden con frecuencia en años, y el tiempo de actividad más largo actual es de al menos dieciséis años. [6]