Clúster de conmutación

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 4 de agosto de 2016; las comprobaciones requieren 9 ediciones .

Clúster de conmutación por error ( clúster de alta disponibilidad en inglés  , clúster HA  - clúster de alta disponibilidad ) - un clúster (grupo de servidores ), diseñado de acuerdo con técnicas de alta disponibilidad y que garantiza un tiempo de inactividad mínimo debido a la redundancia del hardware. Sin agrupamiento, una falla del servidor hace que las aplicaciones o los servicios de red que admite fallen.no están disponibles hasta que se restaura. La agrupación en clústeres de conmutación por error corrige esta situación reiniciando aplicaciones en otros nodos del clúster sin la intervención del administrador si se detectan fallas de hardware o software. El proceso de reinicio se conoce como conmutación por error . Como parte de este proceso, el software de agrupación en clúster puede configurar aún más el nodo antes de ejecutar la aplicación en él (por ejemplo, importar y montar los sistemas de archivos apropiados, reconfigurar el hardware de la red o ejecutar cualquier aplicación de utilidad).

Los clústeres de conmutación por error se usan ampliamente para admitir bases de datos críticas , almacenamiento de archivos en red, aplicaciones comerciales y sistemas de servicio al cliente, como sitios de comercio electrónico .

Las implementaciones de clústeres HA son intentos de lograr la tolerancia a fallas del clúster en su conjunto al eliminar los puntos críticos de falla, incluso a través de la redundancia de potencia informática, conexiones de red y almacenamiento de datos, combinados en una red SAN redundante .

Requisitos de la arquitectura de la aplicación

No todas las aplicaciones pueden ejecutarse en un entorno agrupado de alta disponibilidad. Las decisiones apropiadas deben establecerse en una etapa temprana del desarrollo del software. Para ejecutarse en un clúster HA, una aplicación debe cumplir al menos los siguientes requisitos técnicos, los dos últimos de los cuales son fundamentales para su funcionamiento confiable en un clúster y son los más difíciles de satisfacer por completo:

Esquemas de construcción

Los clústeres HA de dos nodos más comunes son la configuración mínima requerida para proporcionar tolerancia a fallas. Pero a menudo los clústeres contienen mucho más, a veces decenas de nodos. Todas estas configuraciones generalmente se pueden describir mediante uno de los siguientes modelos:

Los términos host lógico o host lógico en clúster se utilizan para hacer referencia a la dirección de red que se utiliza para acceder a los servicios proporcionados por el clúster. El ID de host lógico no está vinculado a un solo nodo de clúster. En realidad, es una dirección/nombre de red que está asociado con los servicios proporcionados por el clúster. Si un nodo de clúster con, por ejemplo, una base de datos en ejecución deja de funcionar, la base de datos se reiniciará en otro nodo de clúster y la dirección de red donde los usuarios acceden a la base de datos se conservará para cualquier nodo nuevo, por lo que los usuarios seguirán teniendo acceso a la base de datos.

Confiabilidad de un solo nodo

Los clústeres de alta disponibilidad, además de los esquemas de redundancia entre nodos descritos, utilizan todos los métodos que generalmente se usan en sistemas e infraestructura de red separados (sin clúster) para maximizar la confiabilidad. Éstos incluyen:

Las medidas de tiempo de actividad de los nodos individuales ayudan a minimizar las posibilidades de recurrir a mecanismos nativos de agrupación en clústeres de conmutación por error. Si estos últimos están activados, el acceso al servicio puede verse interrumpido, aunque sea por poco tiempo, y es más conveniente para prevenir fallas en los equipos críticos.

Algoritmos de recuperación de fallos

Los sistemas que manejan errores en sistemas informáticos distribuidos utilizan diferentes estrategias para lidiar con las consecuencias de una falla. Por ejemplo, Apache Cassandra API Hector (API) proporciona tres opciones para el manejo de errores:

Para controlar la salud de los nodos en un clúster, se suele transmitir una señal periódica continua (“pulso”, latido del corazón en inglés  ) en la red interna del clúster desde cada uno de los nodos, por cuya presencia el software de control juzga el funcionamiento normal. de nodos vecinos. Un problema no obvio, pero serio, del "cerebro dividido_ (computación)" está relacionado con esto : en el caso de una interrupción simultánea en muchas conexiones en la red interna del clúster debido a una falla de energía, falla del equipo de red, etc. , el nodo no será capaz de manejar correctamente esta situación, comienza a comportarse como si todos los demás nodos del clúster hubieran fallado, iniciando servicios duplicados que ya se están ejecutando en el clúster, lo que puede provocar daños en los datos en el almacenamiento compartido.  

Véase también

Notas

Enlaces