Servicios de datos

El término servicio de datos describe una aplicación de otras fabricantes, como Sun Java System Web Server (anteriormente Sun Java System Web Server) o, en el caso de clústers basados en plataformas SPARC, Oracle, configurada para ejecutarse en un clúster antes que en un único servidor. Un servicio de datos se compone de una aplicación, archivos de configuración de Sun Cluster y métodos de gestión Sun Cluster que controlan las acciones siguientes de la aplicación.

• Iniciar

• Detener

• Supervisar y tomar acciones correctoras

• Para obtener información acerca de los servicios de datos, consulte “Data Services” in Sun Cluster Overview for Solaris OS.

En la Figura 3–3 se compara una aplicación que se ejecuta en un servidor de aplicaciones individual (el modelo de servidor individual) con la misma aplicación que se ejecuta en un clúster (el modelo de servidores en clúster). Tenga en cuenta que desde el punto de vista del usuario, no hay diferencia entre las dos configuraciones, excepto en que la aplicación en clúster podría ejecutarse más rápido y con alta disponibilidad.

Figura 3–3 Configuración cliente/servidor estándar frente a configuración en clúster

En el modelo de servidor individual la aplicación se configura para que acceda al servidor a través de una interfaz de red pública determinada (un nombre de sistema). El nombre de sistema está asociado con este servidor físico.

En el modelo basado en clúster, la interfaz de red pública es un nombre de sistema lógico o una dirección compartida. El término recursos de red se utiliza para referirse a los nombres de sistema lógicos y para las direcciones compartidas.

Algunos servicios de datos obligan a especificar nombres de sistema lógicos o direcciones compartidas como interfaces de red, no son intercambiables; otros, en cambio, permiten especificar nombres de sistema lógicos o direcciones compartidas. Consulte la instalación y configuración de cada servicio de datos para obtener los detalles que se deben especificar.

Un recurso de red no está asociado con ningún servidor físico determinado, puede cambiar entre servidores físicos.

Un recurso de red está asociado inicialmente con un nodo, el primario. Si éste falla, los recursos de la red y de la aplicación se trasladan a otro nodo del clúster (uno secundario). Cuando el recurso de red se recupera del problema, después de un breve intervalo, el recurso de aplicación continúa ejecutándose en el secundario.

En la Figura 3–4 se compara el modelo de servidor individual con el basado en clúster. Tenga en cuenta que en el modelo de servidor basado en clúster un recurso de red (nombre de sistema lógico, en este ejemplo) puede trasladarse entre dos o más nodos del clúster. La aplicación está configurada para usar este nombre de sistema lógico en lugar de uno asociado a un servidor en particular.

Figura 3–4 Comparación entre los nombres de sistema fijo y lógico

Una dirección compartida también está asociada inicialmente con un nodo denominado nodo de interfaz global (GIF). La dirección compartida se usa como interfaz de red única en el clúster y se conoce como interfaz global.

La diferencia entre los modelos de nombre de sistema lógico y de servicio escalable es que en éste cada nodo también tiene la dirección compartida configurada activamente en su interfaz de bucle. Esta configuración hace posible tener activas varias instancias de un servicio de datos en varios nodos simultáneamente. El término “servicio escalable” significa que puede agregarse más potencia de CPU a la aplicación agregando nodos adicionales del clúster con lo que el rendimiento se multiplicará..

Si el nodo GIF falla, la dirección compartida puede llevarse a otro nodo que también esté ejecutando una instancia de la aplicación (convirtiendo así al otro nodo en el nuevo GIF). O, la dirección compartida puede trasladarse a otro nodo del clúster que no estuviera ejecutando la aplicación previamente.

En la Figura 3–5 se compara la configuración de servidor individual con la configuración de servicio escalable en clúster. Tenga en cuenta que, en la configuración de servicio escalable, la dirección compartida está presente en todos los nodos. De forma análoga a como se usan los nombres de sistema para los servicios de datos de recuperación de fallos, la aplicación se configura para usar esta dirección compartida en lugar de un nombre de sistema asociado a un servidor determinado.

Figura 3–5 Comparación entre los nombres de sistema fijos y las direcciones compartidas

Métodos de servicios de datos

El software Sun Cluster proporciona un conjunto de métodos de gestión de servicios que se ejecutan bajo el control del Gestor de grupos de recursos (RGM), el cual los usa para iniciar, detener y supervisar la aplicación en los nodos del clúster. Estos métodos, junto con el software de la estructura del clúster y los discos multisistema, permiten a las aplicaciones convertirse en servicios de datos a prueba de fallos o escalables.

RGM también gestiona los recursos del clúster, incluidas las instancias de una aplicación y de los recursos de red (nombres de sistema lógicos y direcciones compartidas).

Además de los métodos proporcionados por el software Sun Cluster, el sistema SunPlex también proporciona una API y varias herramientas de desarrollo de servicios de datos que permiten a los programadores de aplicaciones desarrollar los métodos de servicio de datos necesarios para que otras aplicaciones se ejecuten como servicios de datos de alta disponibilidad con el software de Sun Cluster.

Servicios de datos a prueba de fallos

Si el nodo en el que se está ejecutando el servicio de datos (el primario) falla, el servicio migra a otro nodo en funcionamiento sin intervención del usuario. Los servicios a prueba de fallos usan un grupo de recursos de recuperación de fallos, que es un contenedor para recursos de instancias de aplicaciones y de red (nombres de sistema lógicos). Éstos son direcciones IP que pueden configurarse como activas en un nodo y, posteriormente, configurarse automáticamente como inactivas en el nodo original y activarse en otro nodo.

En los servicios de datos a prueba de fallos, las instancias de las aplicaciones sólo se ejecutan en un nodo individual. Si el supervisor de fallos detecta un error, intenta reiniciar la instancia del mismo nodo o la de otro nodo (recuperación de fallos), dependiendo de la forma en que se haya configurado el servicio de datos.

Servicios de datos escalables

Los servicios de datos escalables tienen la capacidad de activar instancias en varios nodos; usan dos grupos de recursos: un grupo de recursos escalable que contiene los recursos de aplicaciones y un grupo de recursos a prueba de fallos que contiene los recursos de red (direcciones compartidas) de los que depende un servicio escalable. El grupo de recursos escalable puede estar en línea en varios nodos, de forma que se puedan ejecutar varias instancias del servicio simultáneamente. El grupo de recurso a prueba de fallos que aloja la dirección compartida está disponible en un solo nodo cada vez. Todos los nodos que alojan un servicio escalable usan la misma dirección compartida para alojar el servicio.

Las peticiones de servicio llegan al clúster a través de una interfaz de red individual (interfaz global) y se distribuyen a los nodos según uno de varios algoritmos definidos por la política de equilibrio de cargas que el clúster puede usar para equilibrar la carga del servicio entre varios nodos. Tenga en cuenta que pueden haber varias interfaces globales en distintos nodos alojando otras direcciones compartidas.

En los servicios escalables, las instancias de las aplicaciones se ejecutan en varios nodos simultáneamente. Si el nodo que aloja la interfaz global falla, ésta se traspasa a otro nodo. Si falla una instancia de aplicación en ejecución, ésta intenta reiniciarse en el mismo nodo.

Si no se puede reiniciar una instancia de una aplicación en el mismo nodo, y se configura otro nodo que no esté en uso para ejecutar el servicio, éste se transfiere a este nodo. En caso contrario, continúa ejecutándose en los nodos restantes, lo que podría provocar una degradación en el rendimiento del servicio.

---

Nota –

El estado TCP para cada instancia de aplicación se conserva en el nodo de la instancia, no en el de la interfaz global. Por tanto el fallo en el nodo de interfaz global no afecta a la conexión.

---

En la Figura 3–6 se muestra un ejemplo de grupo de recursos escalable y las dependencias que existen entre ellos para los servicios escalables. Este ejemplo muestra tres grupos de recursos. El grupo de recursos a prueba de fallos contiene recursos de aplicación que usan los DNS de alta disponibilidad y recursos de red que usan éstos y el servidor Apache Web Server de alta disponibilidad. Los grupos de recursos escalables sólo contienen instancias de la aplicación de Apache Web Server. Tenga en cuenta que existen dependencias de grupos de recursos entre los grupos de recursos escalables y los a prueba de fallos (líneas sólidas) y que todos los demás recursos de la aplicación de Apache dependen del recurso de red schost-2, que es una dirección compartida (líneas punteadas).

Figura 3–6 SPARC: Ejemplo de los grupos de recursos a prueba de fallos y escalables

Política de equilibrio de cargas

El equilibrio de cargas mejora el rendimiento del servicio escalable, tanto en tiempo de respuesta como como en rendimiento.

Existen dos clases de servicios de datos escalables: puros y adosados. Un servicio puro es aquel cuyas instancias pueden responder a peticiones de clientes sin restricciones. Un servicio adosado es uno en el que un cliente envía peticiones a la misma instancia. Estas peticiones no se redirigen a otras instancias.

Un servicio puro usa una política de equilibrio de cargas ponderada bajo la cual, predeterminadamente, las peticiones de los clientes se distribuyen de manera uniforme entre las instancias del servidor en el clúster. Por ejemplo en un cluster de tres nodos supongamos que cada nodo pesa una unidad. Cada nodo dará servicio a 1/3 de las peticiones de cualquier cliente en nombre de ese servicio. El administrador puede cambiar los pesos en todo momento con la interfaz de órdenes scrgadm(1M) o con la GUI de administración de SunPlex.

Existen dos variedades de servicios adosados, normales y comodín, ambos permiten que sesiones simultáneas de aplicación a través de varias conexiones TCP compartan el estado de la memoria (estado de la sesión de aplicación).

Los normales permiten a un cliente compartir el estado entre varias conexiones TCP simultáneas. Al cliente se le denomina “adosado” con respecto a esa instancia del servidor que recibe en un único puerto. Al cliente se le garantiza que todas sus solicitudes vayan a la misma instancia del servidor, siempre que ésta permanezca activa y accesible y que la política de equilibrio de cargas no cambie mientras el servicio esté en línea.

Por ejemplo, un explorador web en el cliente se conecta a una dirección IP compartida en el puerto 80 usando tres conexiones TCP distintas, pero las conexiones están intercambiando información de sesión en memoria intermedia entre ellas en el servicio.

Una generalización de política de adosamiento se aplica a varios servicios escalables que intercambien información de forma no visible en la misma instancia. Cuando estos servicios intercambian información de la sesión de forma no visible en la misma instancia, se dice que el cliente está “adosado” con respecto a varias instancias de servidor del mismo nodo que recibe en varios puertos.

Por ejemplo, un cliente de una sede web de comercio electrónico llena su carro de la compra con artículos mediante HTTP normal en el puerto 80, pero cambia a SSL en el puerto 443 para enviar datos seguros y pagar con tarjeta de crédito los artículos escogidos.

Los servicios adosados comodín usan números de puerto asignados dinámicamente, pero siguen esperando que las peticiones de clientes vayan al mismo nodo. El cliente está “adosado con comodín” a los puertos con respecto a la misma dirección IP.

Un buen ejemplo de esta política es el FTP de modalidad pasiva. Un cliente se conecta a un servidor FTP en el puerto 21 y después el servidor le informa que vuelva a conectarse a un servidor de puertos que está a la escucha en el rango de puertos dinámico. Todas las solicitudes para esta dirección IP se redirigen al mismo nodo que el servidor informó al cliente a través de la información de control.

Tenga en cuenta que además de estas políticas de adosamiento también está vigente de forma predeterminada la política de equilibrio de cargas ponderada, por tanto la petición inicial de un cliente se dirige a la instancia que dicta el repartidor de cargas. Cuando el cliente ha establecido una afinidad para el nodo en que se está ejecutando la instancia, las futuras peticiones se dirigen a esa instancia siempre que el nodo esté accesible y la política de equilibrio de cargas no cambie.

A continuación se explican detalles adicionales sobre las políticas de equilibrio de cargas específicas.

• Ponderada: la carga se distribuye entre varios nodos según valores de peso especificados. Esta política se establece mediante el valor LB_WEIGHTED para la propiedad Load_balancing_weights. Si no se establece explícitamente el peso de un nodo, éste toma de forma predeterminada el valor uno.

  La política de ponderación redirije cierta parte del tráfico de los clientes a un nodo determinado. Dado X=peso y A=peso total de todos los nodos activos, cada uno puede esperar recibir aproximadamente X/A del total de conexiones nuevas, cuando éste sea lo bastante grande. Esta política no trata de peticiones individuales.

  Tenga en cuenta que esta política no es de tipo giratoria. Una política de puerta giratoria siempre haría que todas las peticiones de un cliente fueran a un nodo distinto: la primera petición al nodo 1, la segunda al nodo 2, etc.

• Adosada: en esta norma el conjunto de puertos se da a conocer en el momento en el que se configuran los recursos de la aplicación. Se establece mediante el valor LB_STICKY para la propiedad del recurso Load_balancing_policy.

• Adosada-comodín: esta política tiene menos limitaciones que la “adosada” normal. En un servicio escalable identificado por su dirección IP, el servidor asigna los puertos (y no se conocen de antemano). Los puertos podrían cambiar. Esta política se establece mediante el valor LB_STICKY_WILD para la propiedad del recurso Load_balancing_policy.

Valores de retroceso

Los grupos de recurso se cubren entre nodos. Cuando esto se produce, el que hacía el papel de secundario se convierte en el nuevo primario. La configuración de retroceso especifica las acciones que acontecen cuando el primario original vuelve a estar en línea. Las opciones son hacer que el primario original se convierta de nuevo en primario (retroceso) o permitir que el que haya tomado su papel continúe con él. La opción deseada se especifica mediante el valor Failback de la propiedad del grupo de recurso.

En algunos casos si el nodo original que aloja al grupo de recursos está fallando y rearrancando continuamente, configurar la rectificación podría producir una disponibilidad menor para el grupo de recursos.

Supervisores de fallos de servicios de datos

Cada servicio de datos de SunPlex proporciona un supervisor de fallos que explora periódicamente el servicio de datos para determinar su buen estado. Un supervisor de fallos comprueba que los daemons de las aplicaciones estén funcionando y que se esté dando servicio a los clientes. De acuerdo con la información que devuelven las sondas, se pueden tomar acciones predefinidas, como reiniciar daemons o producir una recuperación de fallos.