test

Introducción a Sun Identity Manager

Capítulo 3 Agrupamiento en clúster y alta disponibilidad

Este capítulo ofrece orientación para implementar un entorno de Identity Manager de alta disponibilidad / tolerante a fallos (HA/FT).

Nota –

Consulte las prácticas recomendadas para asegurar una implementación de alta disponibilidad con cada tecnología en la documentación de su servidor web, servidor de aplicaciones y proveedor de base de datos. Esta guía no sustituye en absoluto a las recomendaciones específicas de los proveedores sobre los servidores web.

Evaluación de los requisitos de disponibilidad

En esta sección se explica cómo evaluar cuánta disponibilidad requiere una implementación específica.

Cálculo del coste del tiempo de inactividad

Como Identity Manager no se halla en la ruta de transacción entre los usuarios generales y los sistemas y aplicaciones a los que ya tienen acceso, el tiempo de inactividad de Identity Manager no se convierte en la pesadilla que podríamos temer. Si Identity Manager no está disponible, los usuarios finales aún pueden acceder a los recursos a través de sus cuentas abastecidas.

El coste principal del tiempo de inactividad de Identity Manager es la pérdida de productividad. Si Identity Manager no funciona, los usuarios finales no pueden utilizarlo para obtener acceso a los sistemas que tienen bloqueados o desabastecidos.

La primera cifra necesaria para calcular el coste del tiempo de inactividad es el coste medio por la pérdida de productividad de los usuarios finales que no pueden acceder a recursos de computación dentro de la empresa. En nuestra evaluación, esta cifra se denomina productividad por hora de empleado.

La otra cifra importante que interesa averiguar es el porcentaje de usuarios finales del total de usuarios que necesitan utilizar Identity Manager a cualquier hora. Esta población suele incluir las nuevas incorporaciones que es preciso abastecer y los usuarios finales que han olvidado su contraseña, en caso de que la administración de contraseñas forme parte de la implementación.

Consideremos la siguiente situación hipotética:

Número total de empleados 

20.000 

 

Número diario de contraseñas restablecidas 

130 

 

Número diario de nuevas incorporaciones 

30 

 

Número de horas de trabajo diarias 

8 

 

En esta situación específica se puede calcular lo siguiente:

Estas cifras nos permiten estimar el coste de una interrupción del funcionamiento de Identity Manager:

Productividad por hora de empleado 

100$ 

   

Pérdida de productividad 

0,5 

 

(50% de reducción de la productividad por la imposibilidad de acceder al sistema) 

Número de empleados afectados 

20 

   

Subtotal 

1.000$ 

   
       

Duración de la interrupción 

2 horas 

   

Pérdida total inmediata 

2.000$ 

   

Este ejemplo indica que incluso aunque el número de usuarios administrados por Identity Manager sea alto, el número de usuarios que necesitan Identity Manager para obtener acceso a los sistemas a cualquier hora suele ser bajo.

Otro factor importante es que el tiempo que se tarda en volver a poner en funcionamiento un sistema como Identity Manager suele ser inferior al tiempo que se tarda en ejecutar los procesos de abastecimiento manuales que automatiza Identity Manager. Por tanto, aunque el tiempo de inactividad de Identity Manager acarrea un coste, suele ser menor que el coste de utilizar procesos manuales para proporcionar a los usuarios acceso a los recursos.

Causas del tiempo de inactividad

Al planificar una implementación de Identity Manager de alta disponibilidad, vale la pena determinar las causas del tiempo de inactividad.

Son las siguientes:

Cálculo de la rentabilidad de la inversión

Identity Manager automatiza los procesos y reduce la pérdida de productividad. La rentabilidad de invertir en una arquitectura de Identity Manager de alta disponibilidad se consigue al minimizar el tiempo de inactividad y evitar la pérdida de productividad.

El coste del tiempo de inactividad se puede aprovechar para averiguar cuánta disponibilidad se necesita en último término para Identity Manager. En general, una inversión moderada para que Identity Manager esté altamente disponible.

Al calcular el coste de la inversión, recuerde que adquirir hardware y software de HA/FT es sólo una parte de la implementación de una solución disponible. Otro coste es contar con personal experto para mantenerla activa y funcionando.

Características de alta disponibilidad de Identity Manager

Identity Manager está diseñado para aprovechar la infraestructura de alta disponibilidad que pueda haber. Por ejemplo, Identity Manager no necesita un clúster de servidores de aplicaciones para lograr alta disponibilidad, pero puede aprovecharlo si existe.

El diagrama siguiente ilustra los principales componentes de Identity Manager implementados en una arquitectura no redundante. En las secciones siguientes se explica cómo asignar alta disponibilidad al depósito, el servidor de aplicaciones y la puerta de enlace de Identity Manager.

Figura 3–1 Arquitectura del sistema estándar de Identity Manager

Diagrama lógico que representa la arquitectura del sistema estándar de Identity Manager.

Nota –

En Instrucciones sobre la separación y la proximidad física de los componentes del sistema encontrará información sobre los componentes que deben situarse próximos entre sí para reducir los problemas de rendimiento que pueden surgir debido a la latencia y la congestión de la red.

Asignación de alta disponibilidad al depósito

Identity Manager almacena toda la información de abastecimiento y de estado en el depósito de Identity Manager.

La disponibilidad de la instancia de la base de datos donde se almacena el depósito de Identity Manager es el factor más crítico para lograr una implementación de Identity Manager altamente disponible. El depósito representa toda la instalación de Identity Manager, y los datos que contiene deben protegerse, como en el caso de otras aplicaciones de base de datos importantes. Como mínimo hay que realizar copias de seguridad periódicas.

Nota –

No aloje el depósito de Identity Manager en una plataforma virtual, como una máquina virtual VMware, porque se verá seriamente afectado el rendimiento (transacciones por segundo).

Sólo puede haber una imagen del depósito. No es posible tener dos bases de datos distintas para Identity Manager e intentar sincronizarlas por las noches. Sun recomienda usar las funciones de duplicación o agrupamiento en clúster de la base de datos para proporcionar tolerancia a fallos.

Asignación de alta disponibilidad al servidor de aplicaciones

Identity Manager puede ejecutarse dentro de un clúster de servidores de aplicaciones y aprovechar la mayor disponibilidad y equilibrio de carga que ofrece el clúster. Sin embargo, Identity Manager no usa las funciones de J2EE que requieren agrupamiento en clúster.

Identity Manager utiliza el objeto de sesión HTTP que está disponible a través de la API de servlet. Este objeto de sesión lleva un seguimiento de la visita del usuario cuando éste inicia la sesión y realiza acciones. Un clúster ofrece la posibilidad de que varios nodos gestionen las solicitudes del usuario durante una sesión concreta. Sin embargo, esto suele estar desaconsejado y la mayoría de las instalaciones se configuran para enviar al mismo servidor la solicitud completa de un usuario para una sesión determinada.

Es posible ampliar la disponibilidad y la capacidad del servidor de aplicaciones donde se ejecuta Identity Manager incluso sin configuración de clúster. Para ello, se instalan varios servidores de aplicaciones con Identity Manager, se conectan al mismo depósito y se sitúa un equilibrador de carga con afinidad de sesiones al frente de todos los servidores de aplicaciones.

Nota –

Para obtener más información sobre la afinidad de sesiones, consulte Preguntas frecuentes sobre afinidad de sesiones y persistencia de sesiones.

Identity Manager ejecuta determinadas tareas en segundo plano, por ejemplo, las tareas de reconciliación programadas. Estas tareas se almacenan en la base de datos y cualquier servidor de Identity Manager puede seleccionarlas para su ejecución. Identity Manager utiliza la base de datos para asegurarse de que estas tareas siempre se ejecuten por completo, incluso en caso de conmutación por error a otro nodo.

Configuración de clúster de Active Sync en nodos de servidor de aplicaciones

El valor de configuración sources.hosts del archivo Waveset.properties determina qué hosts de un entorno de instancias múltiples se utilizan para ejecutar las solicitudes de Active Sync. Este valor proporciona una lista de hosts donde pueden ejecutarse adaptadores de origen. Si se configura en localhost o null, los adaptadores de origen podrán ejecutarse en cualquier host de la granja de servidores web. (Éste es el comportamiento predeterminado.) Con una lista de uno o más hosts, puede restringir la ejecución a dicha lista. Si hay actualizaciones entrantes que proceden de otro sistema y van a un host concreto, utilice el valor sources.hosts para registrar los nombres de host.

También puede definir una propiedad llamada sources. resourceName.hosts, que controla dónde se ejecutará la tarea de Active Sync del recurso. Sustituya resourceName por el nombre del objeto de recurso que desea especificar.

Asignación de alta disponibilidad a la puerta de enlace

Identity Manager necesita una puerta de enlace liviana para administrar los recursos a los que no se puede acceder directamente desde el servidor. Ello incluye los sistemas que requieren llamadas a la API en el lado del cliente que son específicas de la plataforma. Por ejemplo, si Identity Manager se ejecuta en un servidor de aplicaciones basado en UNIX, no es posible realizar llamadas NTLM o ADSI a dominios administrados de NT o Active Directory. Como Identity Manager necesita una puerta de enlace para administrar estos recursos, es importante asegurarse de que la puerta de enlace de Identity Manager esté altamente disponible.

Para evitar que la puerta de enlace constituya un único punto de fallo, Sun recomienda ejecutar una instancia de puerta de enlace en varias máquinas. Conviene configurar un dispositivo de enrutamiento de red para suministrar conmutación por error en caso de que sucumba la instancia principal de la puerta de enlace. El dispositivo de conmutación por error debe configurarse para sesiones persistentes y utilizar un único esquema de operación por turnos. ¡No sitúe las puertas de enlace detrás de un dispositivo equilibrador de carga! Esta configuración no es compatible y hará que fallen algunas funciones de Identity Manager.

Todos los dominios de Windows administrados por una Puerta de enlace deben formar parte del mismo bosque. No es posible administrar dominios traspasando los límites del bosque. Si tiene varios bosques, instale al menos una Puerta de enlace en cada bosque.

Las herramientas de supervisión de Win32 pueden configurarse para observar el proceso de gateway.exe en el host de Win32. En caso de que falle gateway.exe, el proceso podrá reiniciarse automáticamente.

Arquitectura de alta disponibilidad recomendada

El diagrama siguiente ilustra la arquitectura de Identity Manager que Sun recomienda cuando no existe ninguna infraestructura de aplicación web.

Figura 3–2 Arquitectura de alta disponibilidad de Identity Manager

Diagrama lógico que representa la arquitectura de alta disponibilidad recomendada para Identity Manager.

En una implementación real, conviene utilizar en la mayor medida posible la infraestructura de servidor de aplicaciones redundante existente. El valor de esta arquitectura estriba en que sólo utiliza equilibradores de carga para lograr la redundancia en el servidor de aplicaciones. Los equilibradores de carga con afinidad de sesiones detectan las instancias de servidor de aplicaciones fallidas y conmutan por error a las instancias activas. Los equilibradores de carga también sirven para aportar escalamiento horizontal al entorno web repartiendo las solicitudes de usuario entre un clúster de servidores.

Aunque se trata de una arquitectura sencilla, las características de tiempo de actividad son equiparables a las de implementaciones más complejas. Dada su simplicidad, hay menos software que mantener y supervisar o menos piezas que puedan fallar. Como la causa principal del tiempo de inactividad son los errores humanos, una solución relativamente simple puede aportar mejores características de tiempo de actividad que otras más complejas. No existe una respuesta universal acertada. Lo que importa es conocer todas las causas del tiempo de inactividad y elegir la arquitectura que entrañe la mejor disponibilidad para el entorno.

Nota –

Es imposible describir todas las distintas arquitecturas HA que pueden establecerse con una aplicación web como Identity Manager.

Como Identity Manager se puede implementar con gran variedad de combinaciones, quizá resulte más económico identificar la infraestructura existente y aprovecharla todo lo posible al implantar Identity Manager.

Arquitectura de alta disponibilidad recomendada de Service Provider

Si se va a utilizar la funcionalidad de Identity Manager Service Provider, Sun recomienda añadir un nivel de web entre el nivel de usuario y el de aplicación. El nivel de web consta de uno o varios servidores web ubicados en una zona desmilitarizada (DMZ) y separada del nivel de aplicación por un servidor de seguridad.

Para utilizar la funcionalidad de Service Provider se necesita un depósito LDAP. Cuando Identity Manager sólo va a usarse con clientes de extranet, se recomienda un depósito estándar de Identity Manager, aunque no es imprescindible. En cambio, si Identity Manager se va a utilizar con usuarios de intranet y de extranet, es indispensable un depósito estándar de Identity Manager.

Figura 3–3 Arquitectura de alta disponibilidad de Identity Manager Service Provider

Diagrama lógico que representa la arquitectura de alta disponibilidad de Identity Manager recomendada para una implementación de Service Provider.

Escenarios de fallos

En esta sección se describen ocho escenarios de fallos y se comparan dos implementaciones: una con persistencia de sesiones y otra sin ella.

Escenario 1: fuera del flujo de trabajo

Descripción del escenario

El usuario final o el administrador editan un formulario no perteneciente a un flujo de trabajo. Deja de funcionar la instancia donde el usuario ha establecido la sesión.

Sin persistencia de sesiones

Experiencia de usuario: Una conmutación por error no transparente. Tras enviar el formulario, se devuelve al usuario a la página de inicio de sesión.

Acciones de recuperación: El usuario reintroduce su nombre de usuario y contraseña. A continuación, Identity Manager procesa el formulario y presenta los resultados en la página inmediatamente posterior a la de inicio de sesión.

Con persistencia de sesiones

Experiencia de usuario: El formulario del usuario se envía y los resultados se devuelven sin que salga de la sesión y deba volver a iniciarla.

Acciones de recuperación: No es necesaria ninguna acción del usuario.

Otros escenarios de ejemplo

Escenario 2: Con flujo de trabajo en curso

Descripción del escenario

El usuario final o el administrador han enviado un formulario que ha activado un flujo de trabajo. La instancia donde se ejecuta el flujo de trabajo y donde se encuentra la sesión del usuario suele ser la misma, excepto con algunas tareas programadas, que pueden realizarse en distintas instancias. Esta instancia deja de funcionar mientras el flujo de trabajo está en curso.

Sin persistencia de sesiones

Experiencia de usuario: Una conmutación por error no transparente. El envío del formulario devuelve el usuario a la página de inicio de sesión. La instancia de la tarea del flujo de trabajo que se está ejecutando debe estar en el depósito, pero como el nodo de ejecución no funciona, el estado del flujo de trabajo es "terminado".

Acciones de recuperación: El flujo de trabajo debe volver a enviarse. Para ello hay que regresar al mismo formulario y reintroducir la misma información que sirvió para activar el flujo de trabajo antes de que fallara el nodo.

Enviar los mismos datos de solicitud no siempre funciona. Si el flujo de trabajo abastece más de un recurso durante su ejecución y alguno de esos recursos se había abastecido antes del fallo, el reenvío del flujo de trabajo por parte del usuario tendría que asumir los recursos ya abastecidos. No olvide que el flujo de trabajo terminado persiste en el depósito hasta que resultLimit caduca en el objeto TaskInstance .

Con persistencia de sesiones

Experiencia de usuario: Una conmutación por error no transparente. El usuario no logra cerrar la sesión porque es persistente y se restablece en la nueva instancia. Sin embargo, el envío del formulario seguramente generará un error, porque el flujo de trabajo se habrá terminado. Se trata de una conmutación por error no transparente, ya que son necesarias acciones de recuperación.

Acciones de recuperación: Las mismas que sin persistencia de sesiones. El usuario debe reenviar la solicitud que desactivó el flujo de trabajo anterior con parámetros iguales o modificados.

Otros escenarios de ejemplo

Escenario 3: Flujo de trabajo suspendido o postergado

Descripción del escenario

Este escenario abarca situaciones en que el flujo de trabajo ha comenzado, pero está esperando que un aprobador realice una acción manual.

Sin persistencia de sesiones

Experiencia de usuario: Conmutación por error transparente con respecto al aprobador siempre que éste aún no haya iniciado la sesión. Tras fallar el nodo, cuando el aprobador inicia la sesión todavía aparece la solicitud de aprobación en su bandeja de entrada, incluso aunque la solicitud haya sido activada desde un nodo que ha quedado inactivo.

Acciones de recuperación: No es necesaria ninguna acción del usuario.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Otros escenarios de ejemplo

Escenario 4: Edición de un elemento de trabajo

Descripción del escenario

Este escenario incluye los casos en que un usuario está editando un elemento de trabajo y el nodo donde se halla la sesión del usuario deja de funcionar antes de poder enviar el elemento de trabajo.

Sin persistencia de sesiones

Experiencia de usuario: Una conmutación por error no transparente. Cuando se envía el formulario de edición del elemento de trabajo, se cierra la sesión del usuario, que vuelve a la página de inicio de sesión.

Acciones de recuperación: Tras reenviar las credenciales de inicio de sesión, el elemento de trabajo del usuario se marca como completado y el flujo de trabajo puede reanudarse a partir de ese punto. El flujo de trabajo debe seleccionarse en el nuevo modo para ejecutarlo a partir del punto en que se ha marcado como completada la acción manual del usuario.

Con persistencia de sesiones

Experiencia de usuario: Cuando se envía el formulario de edición del elemento de trabajo, el usuario ve el resultado de dicho envío; por ejemplo, el siguiente formulario del flujo de trabajo personalizado si lo hay o un mensaje satisfactorio.

Acciones de recuperación: No es necesaria ninguna acción del usuario.

Otros escenarios de ejemplo

Escenario 5: Tareas programadas en curso

Descripción del escenario

Este escenario abarca los casos en que falla un nodo mientras está en curso una reconciliación o durante la ejecución de un informe.

Sin persistencia de sesiones

Experiencia de usuario: La tarea programada termina durante el proceso.

Acciones de recuperación: Hay que reiniciar la tarea programada que estaba realizándose. La tarea volverá a empezar desde el principio. (La tarea no se reiniciará a partir del punto de fallo.) Es parecido a crear e iniciar una tarea nueva.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Otros escenarios de ejemplo

Escenario 6: Tarea programada en suspensión

Descripción del escenario

Este escenario abarca los casos en que el flujo de trabajo personalizado de un usuario tiene una tarea programada para ejecutarse en una fecha posterior en un nodo específico. Antes de la fecha programada, falla el nodo donde estaba programada la tarea.

Sin persistencia de sesiones

Experiencia de usuario: La conmutación por error es transparente con respecto a las acciones de recuperación necesarias para asegurar la ejecución de esta tarea en la fecha prevista.

Acciones de recuperación: Cualquier nodo activo asume la tarea programada cuando llega la fecha de ejecución prevista.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Otros escenarios de ejemplo

Escenario 7: Solicitud de flujo de trabajo de servicios webaún no recibida por Identity Manager

Descripción del escenario

Este escenario abarca los casos en que no se utiliza la GUI de Identity Manager para iniciar el abastecimiento. En su lugar, la interfaz de usuario la suministra una aplicación que realiza una llamada interna a Identity Manager a través de SPML u otra interfaz de servicio web personalizada. La sesión relacionada con el usuario a través de la interfaz de usuario se administra mediante la aplicación que realiza la llamada. Para Identity Manager, todas las solicitudes se inician como asunto del administrador de SOAP (“soapadmin”).

En tal caso de uso, este escenario de fallo abarca las situaciones en que aún no se ha recibido la solicitud por medio del punto final de Identity Manager y falla el nodo de destino.

Sin persistencia de sesiones

Experiencia de usuario: Una conmutación por error transparente. Las credenciales del administrador de SOAP se transmiten con cada solicitud de SOAP, ya sea mediante conexión o dentro de Identity Manager con un valor de configuración Waveset.properties. En tanto que el nodo que debía recibir esta solicitud de SOAP no la ha recibido antes de fallar, la conmutación por error es transparente con o sin persistencia de sesiones.

Acciones de recuperación: No es necesaria ninguna acción. La solicitud de SOAP se envía a un nodo activo que la ejecuta.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Escenario 8: Solicitud de flujo de trabajo de servicios web en curso por Identity Manager

Descripción del escenario

Es similar al escenario 7. La única diferencia es que el flujo de trabajo se está efectuando cuando el nodo falla, o que el nodo ha recibido la solicitud de SOAP cuando falla.

Sin persistencia de sesiones

Experiencia de usuario: Es similar al escenario 2 (flujo de trabajo en curso). El flujo de trabajo se marca como terminado y el usuario ve un error como resultado de la solicitud de SOAP.

Acciones de recuperación: El usuario debe reenviar el formulario con parámetros iguales o modificados (según dónde se produzca el fallo en el flujo de trabajo) a través de la interfaz de usuario en la aplicación de terceros.

Con persistencia de sesiones

Experiencia de usuario: La misma que sin persistencia de sesiones.

Acciones de recuperación: Las mismas que sin persistencia de sesiones.

Preguntas frecuentes sobre afinidad de sesiones y persistencia de sesiones

¿Debe estar habilitada la afinidad de sesiones al escalar horizontalmente los servidores de aplicaciones?

Sí.

¿Debe haber persistencia de sesiones al escalar horizontalmente los servidores de aplicaciones?

A no ser que sus requisitos de negocio hagan especial hincapié en tener conmutación por error transparente en las raras circunstancias en que la persistencia de sesiones puede suponer una diferencia, Sun desaconseja el uso de persistencia de sesiones. La persistencia de sesiones produce un deterioro específico del rendimiento, por lo que conviene prescindir de ella salvo que los requisitos de negocio impongan a toda costa la conmutación por errores transparente.

Si analiza las situaciones expuestas en Escenarios de fallos, comprobará que seis de los casos no presentan ninguna diferencia en cuanto a la experiencia del usuario o las acciones de recuperación necesarias, con independencia de que esté habilitada la persistencia de sesiones. Sólo los escenarios 1 y 4 presentan diferencias en los casos con y sin persistencia de sesiones.

En ambos escenarios, la persistencia de sesiones puede aportar cierta transparencia a la conmutación por error, pero siempre a costa del rendimiento. Según el tamaño de los objetos de sesión, el depósito utilizado para la persistencia de sesiones y la optimización del código de administración de sesiones del servidor de aplicaciones específico, el rendimiento puede resultar perjudicado entre un 10% y un 20%, o incluso más.

¿Debe haber varias instancias de servidor de aplicaciones en un clúster al escalar horizontalmente?

No hay ninguna necesidad de tener varias instancias de servidor de aplicaciones salvo que se quiera persistencia de sesiones. Se puede conseguir conmutación por error sin persistencia de sesiones incluso aunque todos los nodos de servidor de aplicaciones no se encuentren en un clúster.