Servicios de datos

El término servicio de datos describe una aplicación, como por ejemplo Oracle o Sun Java System Web Server, que se ha configurado para ejecutarse en un clúster en lugar de en un servidor individual. Un servicio de datos se compone de una aplicación, archivos de configuración especializados de Sun Cluster y métodos de gestión de Sun Cluster que controlan las acciones siguientes de la aplicación.

• Inicio

• Detener

• Supervisar y tomar acciones correctoras

Para obtener información acerca de los tipos de servicios de datos, consulte Servicios de datos de Sun Cluster para el sistema operativo Solaris: Visión general.

En la Figura 3–4 se compara una aplicación que se ejecuta en un único servidor de aplicaciones (modelo de servidor único) con la misma aplicación pero ejecutándose en un clúster (modelo de servidor en clúster). La única diferencia entre las dos configuraciones es que la aplicación en clúster puede que se ejecute más rápidamente y tenga una mayor disponibilidad.

Figura 3–4 Configuración estándar y configuración cliente-servidor

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

En el modelo de servidor 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 requieren que se especifiquen los nombres de sistema lógicos o las direcciones compartidas como interfaces de red. Los nombres de sistema lógicos y las direcciones compartidas no se pueden intercambiar; otros, en cambio, permiten especificar nombres de sistema lógicos o direcciones compartidas. Consulte la instalación y la configuración para cada servicio de datos para obtener detalles acerca del tipo de interfaz que debe especificar.

Un recurso de red no está asociado a un servidor físico específico. Un recurso de red puede migrar entre servidores físicos.

Un recurso de red está asociado inicialmente a un nodo, el primario. Si el primario falla, el recurso de red y el recurso de aplicación se recuperan del fallo usando un nodo de clúster diferente (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–5 se compara un modelo de servidor único con un modelo de servidor 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–5 Comparación entre los nombres de sistema fijo y lógico

Una dirección de red también está asociada inicialmente a otro nodo. Este nodo se denomina nodo de interfaz global. Una dirección compartida (conocida como interfaz global) se utiliza como interfaz de red única para el clúster.

La diferencia entre el modelo de nombre de sistema lógico y el modelo de servicio escalable es que en este último, cada nodo tiene la dirección de red activamente configurada en su interfaz de bucle inverso. Esta configuración permite que haya múltiples instancias de un servicio de datos activas 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 del clúster adicionales con lo que el rendimiento se multiplicará.

Si el nodo de interfaz global falla, la dirección compartida puede iniciarse en otro nodo que también esté ejecutando una instancia de la aplicación (convirtiendo así al otro nodo en el nuevo nodo de interfaz global). 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–6 se compara una configuración de servidor único con una configuración de servicio escalable basada 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–6 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 Estos métodos se ejecutan bajo el control de Gestor de grupos de recursos (RGM), que los utiliza 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 dispositivos 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 mediante el software de Sun Cluster, el sistema Sun Cluster también proporciona una API y varias herramientas de desarrollo de servicio de datos. Estas herramientas permiten a los desarrolladores de aplicaciones desarrollar los métodos de servicios de datos necesarios para que otras aplicaciones se puedan ejecutar como servicios de datos de alta disponibilidad con el software Sun Cluster.

Servicios de datos de recuperación 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 de recuperación de fallos usan un grupo de recursos de recuperación de fallos, que es un contenedor para los recursos de instancias de aplicaciones y recursos de la red (nombres de sistemas lógicos). Los nombres de sistemas lógicos 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 en el mismo nodo o bien intenta iniciarla en otro nodo (el de recuperación de fallos). El resultado depende 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; Los servicios escalables utilizan los dos siguientes grupos de recursos:

• Un grupo de recursos escalables contiene los recursos de aplicación.

• Un grupo de recursos de recuperación de fallos contiene los recursos de red (direcciones compartidas) de los que depende el 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 solicitudes de servicio entran en el clúster a través de una interfaz de red única (la interfaz global). Estas solicitudes se distribuyen a los nodos, basándose en uno de los algoritmos predefinidos especificados por la directiva de equilibrado de cargas que el clúster puede usar para equilibrar la carga del servicio entre varios nodos. Puede haber varias interfaces globales en distintos nodos que alojen 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 que se está ejecutando, la instancia 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. De lo contrario, el servicio continúa ejecutándose en los nodos restantes, lo que posiblemente provocará una degradación del 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.

---

La Figura 3–7 muestra un ejemplo de grupo de recursos escalables y de recuperación de fallos y las dependencias que existen entre ellos en cuanto a los servicios escalables. Este ejemplo muestra tres grupos de recursos. El grupo de recursos de recuperación 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 (sólo en clústeres basados en SPARC). Los grupos de recursos escalables sólo contienen instancias de la aplicación de Apache Web Server. Tenga en cuenta que las dependencias de los grupos de recursos existen entre los grupos de recursos de recuperación de fallos y los escalables (líneas sólidas). Adicionalmente, todos los recursos de aplicación de Apache dependen del recurso de red schost-2, que es una dirección compartida (líneas de puntos).

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

Políticas de equilibrio de cargas

El equilibrio de cargas mejora el rendimiento del servicio escalable, tanto en tiempo de respuesta como como en rendimiento. Hay dos clases de servicios de datos escalables.

• Puro

• Adosado

En un servicio puro, todas las instancias pueden responder a las solicitudes del cliente. En un servicio adosado, un cliente puede enviar solicitudes 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 clúster de tres nodos, suponga que cada nodo tiene un peso de 1. Cada nodo atenderá 1/3 de las solicitudes procedentes de cualquier cliente en nombre de dicho servicio. El administrador puede cambiar el peso en cualquier momento usando la interfaz de comando scrgadm(1M) o la GUI de SunPlex Manager.

Un servicio adosado tiene dos perspectivas: adosado normal y adosado con comodines. Los servicios adosados permiten sesiones simultáneas de aplicación a través de varias conexiones TCP para que compartan la memoria en estado (estado de la sesión de aplicación).

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

Por ejemplo, un navegador Web en el cliente conecta con una dirección IP compartida en el puerto 80 usando tres conexiones TCP diferentes. Sin embargo, las conexiones intercambian con el servicio información de sesión almacenada en caché.

Una generalización de una directiva adosada amplía a varios servicios escalables dicha información de sesión de intercambio en segundo plano y en la misma instancia. Cuando estos servicios intercambian información de sesión en segundo plano y en la misma instancia, se considera que el cliente está “adosado” a varias instancias de servidor en el mismo nodo recibiendo información a través de distintos puertos. .

Por ejemplo, un cliente de un sitio de comercio electrónico llena su carro de la compra con artículos utilizando HTTP en el puerto 80. El cliente entonces cambia a SSL en el puerto 443 para enviar los datos de forma segura para pagar con tarjeta de crédito los artículos del carro.

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 que tienen la misma dirección IP.

Un buen ejemplo de esta política es el FTP de modalidad pasiva. Por ejemplo, un cliente se conecta a un servidor FTP mediante el puerto 21. El servidor entonces da instrucciones al cliente para que se vuelva a conectar a un servidor con puerto de escucha que esté en el intervalo de puertos dinámicos. Todos los requisitos para esta dirección IP se reenvían al mismo nodo mediante el que el servidor informó al cliente a través de la información de control .

Para cada una de estas directivas adosadas, la directiva de equilibrio de carga en función del peso está activada de forma predeterminada. Por lo tanto, una solicitud inicial del cliente se dirige a la instancia que indica el equilibrador de carga. Después de que el cliente establezca una afinidad para el nodo en el que se está ejecutando la instancia, las solicitudes futuras estarán dirigidas condicionalmente a dicha instancia. El nodo debe estar accesible y la directiva de equilibrado de carga no se debe haber modificado.

Los detalles adicionales de las directivas específicas de equilibrado de carga son las siguientes.

• Ponderada: la carga se distribuye entre varios nodos según valores de peso especificados. Esta directiva se define usando 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. Si consideramos que X=peso y A=el peso total de todos los nodos activos, un nodo activo recibirá aproximadamente X/A del total de conexiones nuevas que se dirijan al nodo activo. Sin embargo, el número total de conexiones debe ser lo suficientemente 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 este tipo provocará que cada solicitud de un cliente vaya a un nodo distinto. Por ejemplo, la primera solicitud iría 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. Esta directiva se define usando el valor LB_STICKY para la propiedad Load_balancing_policy.

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

Configuración de retroceso

Los grupos de recurso se cubren entre nodos. Cuando se produce una recuperación de fallos, el nodo secundario original pasa a ser el nuevo primario. La configuración de retroceso especifica las acciones que se producirán cuando el nodo principal vuelva 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. Las opciones se especifican usando la configuración de la propiedad del grupo de recursos Failback .

Si falla el nodo original que alberga el grupo de recursos y se reinicia varias veces, la configuración de un retroceso podría reducir la disponibilidad del grupo de recursos.

Supervisor de fallos del servicio de datos

Cada servicio de datos de Sun Cluster 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 comprobaciones, se pueden llevar a cabo acciones predefinidas, como reiniciar daemons o producir una recuperación de fallos.