Beruflich Dokumente
Kultur Dokumente
Registrarse/Entrar
Navegacin Pgina Principal Ayuda Cmo buscar? Portal del colaborador Polticas de Moderacin Artculos de referencia Artculos destacados Artculos certificados Notificar error o fusin Esquina de dudas Blog EcuRed En Facebook En Tw itter Biblioteca Foro de EcuRed rbol de Categoras Plantillas recomendadas Actualidad Cambios recientes Pgina aleatoria Solicitudes Artculos requeridos Artculos a normalizar Artculos a fusionar Artculos hurfanos Artculos a validar Herramientas Lo que enlaza aqu Cambios relacionados Pginas especiales Versin para imprimir Enlace permanente Denunciar vandalismo
No sabes por donde empezar? Aydanos normalizando artculos. Tienes experiencia? Crea alguno de estos artculos requeridos.
Cluster de alta disponibilidad (HA). En la actualidad las organizaciones dependen cada vez ms de sus sistemas de informacin, y como es obvio se desea que estos sean seguros y permanezcan disponibles el mayor tiempo posible. Para cualquier empresa, una interrupcin de sus sistemas de informacin supone un serio problema. Contenido [ocultar] 1 Efectos por la interrupcin de un sistema de informacin 2 Tipos de cluster 3 Disponibilidad 4 Clculo de la disponibilidad 5 Las razones para implementar un cluster de alta disponibilidad son 6 Configuraciones de alta disponibilidad 7 Funcionamiento de un cluster de alta disponibilidad 8 Elementos y conceptos bsicos en el funcionamiento del cluster 8.1 Recurso y Grupos de Recursos 8.2 Intercomunicacin 8.3 Heartbeat 8.4 Escenario Split-Brain 8.5 Monitorizacin de Recursos 8.6 Reiniciar Recursos 8.7 Migracin de Recursos 8.8 Dependencia entre recursos 8.9 Preferencia de nodos 8.10 Comunicacin con otros sistemas 8.11 Fencing 8.12 Quorum 9 Fuentes
Tipos de cluster
1. Alta disponibilidad de infraestructura: Si se produce un fallo de hardware en alguna de las mquinas del cluster, el software de alta disponibilidad es capaz de arrancar automticamente los servicios en cualquiera de las otras mquinas del cluster (failover). Y cuando la mquina que ha fallado se recupera, los servicios son nuevamente migrados a la mquina original (failback). Esta capacidad de recuperacin automtica de servicios nos garantiza la alta disponibilidad de los servicios ofrecidos por el cluster, minimizando as la percepcin del fallo por parte de los usuarios. 2. Alta disponibilidad de aplicacin: Si se produce un fallo del hardware o de las aplicaciones de alguna de las mquinas del cluster, el software de alta disponibilidad es capaz de arrancar automticamente los servicios que han fallado en cualquiera de las otras mquinas del cluster. Y cuando la mquina que ha fallado se recupera, los servicios son nuevamente migrados a la mquina original. Esta capacidad de recuperacin automtica de servicios nos garantiza la integridad de la informacin, ya que no hay prdida de datos, y adems evita molestias a los usuarios, que no tienen por qu notar que se ha producido un problema.
converted by Web2PDFConvert.com
Disponibilidad
La disponibilidad es el grado en que una aplicacin o servicio est disponible cundo y cmo los usuarios esperan. La disponibilidad se mide por la percepcin de una aplicacin del usuario final. Los usuarios finales experimentan frustracin cuando sus datos no estn disponibles, y ellos no entienden o son capaces de diferenciar los complejos componentes de una solucin global. Fiabilidad, valorizacin, continuas operaciones y deteccin de errores son caractersticas de una solucin de alta disponibilidad. 1. Fiabilidad: Los componentes hardware fiables de una solucin de HA, el software fiable, incluida la base de datos, servidores web y aplicaciones, es la parte crtica de una implementacin de una solucin de alta disponibilidad. 2. Recuperacin: Puede haber muchas opciones para recuperarse de un fracaso si ocurre alguno. Es importante determinar qu tipo de fallos pueden ocurrir en su entorno de alta disponibilidad y la forma de recuperarse de estos fallos en el tiempo que satisface las necesidades comerciales. Por ejemplo, si una tabla importante es eliminada de la base de datos, qu medidas adoptaras para recuperarla? Su arquitectura ofrece la capacidad de recuperarse en el tiempo especificado en un acuerdo de nivel de servicio (SLA)? 3. Deteccin de errores: Si un componente en su arquitectura falla, entonces la rpida deteccin, de dicho componente es esencial en la recuperacin de un posible fracaso inesperado. Si bien es posible que pueda recuperarse rpidamente de un corte de luz, si se lleva a otros 90 minutos para descubrir el problema, entonces usted no puede satisfacer su SLA. La monitorizacin del estado del entorno de trabajo requiere un software fiable, para ver de forma rpida y notificar al administrador de bases de datos (DBA) un problema. 4. Continuas operaciones: El continuo acceso a sus datos es esencial, por muy pequeo o inexistente que sea el tiempo de cada del sistema, para llevar a cabo las tareas de mantenimiento. Actividades como mover una tabla de un lado a otro dentro de la base de datos, o incluso aadir nuevas CPU's a su hardware debe ser transparente para el usuario final en una arquitectura HA.
Clculo de la disponibilidad
En un sistema real, si falla uno de los componentes, es reparado o sustituido por un nuevo componente. Si este nuevo componente falla, es sustituido por otro, y as sucesivamente. El componente fijo se considera en el mismo estado que un nuevo componente. Durante su vida til, uno de los componentes pueden ser considerado en uno de estos estados: Funcionando o en Reparacin; El estado funcionando indica que el componente est operacional y el en reparacin significa que ha fallado y todava no ha sido sustituido por un nuevo componente. En caso de defectos, el sistema va de funcionando en modo reparacin, y cuando se hace la sustitucin volver al estado funcionando. Por lo tanto, podemos decir que el sistema tiene durante su vida, una media de tiempo para presentar fallas (MTTF) y un tiempo medio de reparacin (MTTR). Su tiempo de vida es una sucesin de MTTFs y MTTRs, a medida que este va fallando y siendo reparado. El tiempo de vida til del sistema es la suma de MTTFs en ciclos MTTF + MTTR ya vividos. En forma simplificada, se dice que la disponibilidad de un sistema es la relacin entre la duracin de la vida til de este sistema y de su tiempo total de vida. Esto puede ser representado por la frmula de abajo: Disponibilidad = MTTF / (MTTF + MTTR)
En la evaluacin de una solucin de Alta Disponibilidad, es importante tener en cuenta si en la medicin de MTTF son vistos como fallas las posibles paradas planificadas. En la actualidad, eligiendo correctamente el hardware y software adecuados, es relativamente sencillo disear un sistema con una disponibilidad del 98% del tiempo. Pero el paso del 98% al 99% y de aqu al 99,9999% es una tarea compleja y a la par supone un aumento exponencial del coste total del sistema. En la prctica se alcanza un compromiso entre la disponibilidad pretendida y el coste abordable.
converted by Web2PDFConvert.com
servidores del cluster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen estando accesibles a travs de los otros servidores del cluster. La ventaja principal de esta configuracin es que los servidores en el cluster son mas eficientes ya que pueden trabajar todos a la vez. Sin embargo, cuando uno de los servidores deja de estar accesible, su carga de trabajo pasa a los nodos restantes, lo que produce una degradacin del nivel global de servicio ofrecido a los usuarios. En la siguiente figura se muestra como ambos servidores estn activos, proporcionando un mismo servicio a los diferentes usuarios. Los clientes acceden al servicio o recursos deforma transparente y no tienen conocimiento de la existencia de varios servidores formando un cluster. Configuracin Activo/Pasivo Un cluster de alta disponibilidad, en una configuracin activo/pasivo, consiste en un servidor que posee los recursos del cluster y otros servidores que son capaces de acceder a esos recursos, pero no los activan hasta que el el propietario de los recursos ya no este disponible. Las ventajas de la configuracin activo/pasivo son que no hay degradacin de servicio y que los servicios solo se reinician cuando el servidor activo deja de responder. Sin embargo, una desventaja de esta configuracin es que los servidores pasivos no proporcionan ningn tipo de recurso mientras estn en espera, haciendo que la solucin sea menos eficiente que el cluster de tipo activo/activo. Otra desventaja es que los sistemas tardan un tiempo en migrar los recursos (failover) al nodo en espera.
Intercomunicacin
El software de cluster gestiona servicios y recursos en los nodos. Pero adems, tiene que mantener continuamente entre estos una visin global de la configuracin y estado del cluster. De esta forma, ante el fallo de un nodo, el resto conoce que servicios se deben restablecer. Ya que la comunicacin entre los nodos del cluster es crucial para el funcionamiento de este, es habitual utilizar un canal especifico como una red IP independiente o una conexin serie, que no se pueda ver afectada por problemas de seguridad o rendimiento.
Heartbeat
El software de cluster conoce en todo momento la disponibilidad de los equipos fsicos, gracias a la tcnica de heartbeat. El funcionamiento es sencillo, cada nodo informa peridicamente de su existencia enviando al resto una "seal de vida".
Escenario Split-Brain
En un escenario split-brain, mas de un servidor o aplicacin pertenecientes a un mismo cluster intentan acceder a los mismos recursos, lo que puede causar daos a dichos recursos. Este escenario ocurre cuando cada servidor en el cluster cree que los otros servidores han fallado e intenta activar y utilizar dichos recursos.
Monitorizacin de Recursos
(Resource Monitoring) Ciertas soluciones de clustering HA permiten no solo monitorizar si un host fsico esta disponible, tambin pueden realizar seguimientos a nivel de recursos o servicios y detectar el fallo de estos. El administrador puede configurar la periodicidad de estos monitores as como las acciones a llevar a cabo en caso de fallo.
Reiniciar Recursos
converted by Web2PDFConvert.com
Cuando un recurso falla, la primera medida que toman las soluciones de cluster es intentar reiniciar dicho recurso en el mismo nodo. Lo que supone detener una aplicacin o liberar un recurso y posteriormente volverlo a activar. Algunas implementaciones no permiten reiniciar un nico recurso, y lo que realizan es un reinicio completo de todo un grupo de recursos (servicio). Esto puede llegar a demorar bastante para servicios como las bases de datos.
Migracin de Recursos
(Failover) Cuando un nodo ya no esta disponible, o cuando un recurso fallido no se puede reiniciar satisfactoriamente en un nodo, el software de cluster reacciona migrando el recurso o grupo de recursos a otro nodo disponible en el cluster. De este modo el tiempo de inactividad por el posible fallo es mnimo, y el cluster seguir proporcionando el correspondiente servicio.
Preferencia de nodos
(Resource Stickiness) En configuraciones de cluster con mltiples nodos, es comn distribuir los servicios a proporcionar entre los diferentes servidores. Adems puede que los servidores tengan caractersticas hardware diferentes (cpu, memoria ram) y nos interese que, para un estado ideal del cluster, determinados servicios se ejecuten siempre en un determinado servidor. Este comportamiento se define mediante la preferencia de nodo en la definicin de cada recurso.
Fencing
En los clusters HA existe una situacin donde un nodo deja de funcionar correctamente pero todava sigue levantado, accediendo a ciertos recursos y respondiendo peticiones. Para evitar que el nodo corrompa recursos o responda con peticiones, los clusters lo solucionan utilizando una tcnica llamada Fencing. La funcin principal del Fencing es hacerle saber a dicho nodo que esta funcionando en mal estado, retirarle sus recursos asignados para que los atiendan otros nodos, y dejarlo en un estado inactivo.
Quorum
Para evitar que se produzca un escenario de Split-Brain, algunas implementaciones de cluster HA introducen un canal de comunicacin adicional que se emplea para determinar exactamente que nodos estn disponibles en el cluster y cuales no. Tradicionalmente se implementa utilizando los llamados quorum devices, que habitualmente son un volumen de almacenamiento compartido exclusivo (disk heart beating). Tambin existen implementaciones que utilizan una conexiones de red adicional o una conexin serie. Esta ltima tiene limitaciones de distancia y actualmente ha quedado en desuso.
Fuentes
1. Artculo: Cluster de alta disponibilidad . Disponible en: "es.wikipedia.org". Consultado: 5 de diciembre de 2011. 2. Artculo: Clusters de alta disponibilidad (HA) . Disponible en: "www.lintips.com". Consultado: 5 de diciembre de 2011. 3. Artculo: Clustering de alta disponibilidad . Disponible en: "images.linuxidx.com". Consultado: 5 de diciembre de 2011. 4. Documento: LinuxHa . Disponible en: "www.ibiblio.org". Consultado: 5 de diciembre de 2011. Categoras: Ciencias informticas | Informtica Trminos y Condiciones Aviso legal Acerca de EcuRed Poltica de proteccin de datos
converted by Web2PDFConvert.com