2.1 Topología
El número de instancias de cada subsistema principal y las formas en que éstas se pueden conectar son, potencialmente, elevadas. No todos los diseños están admitidos. Es importante no sólo comprender las posibilidades, sino también por qué se prefieren algunas configuraciones sobre otras.
2.1.1 Diseño mínimo
La configuración lógica más sencilla de la aplicación de usuario corresponde a una instalación del tipo "uno de cada", que consiste en un árbol de repositorio seguro de identidades, una instancia del motor del Gestor de identidades y controladores y una instancia de JBoss ejecutando una única instancia de la aplicación de usuario. Desde el punto de vista de la aplicación física, en teoría, se pueden ejecutar todos juntos. Aunque en una situación real, esta disposición no es recomendable por una serie de motivos (principalmente de seguridad, mantenimiento y rendimiento). A la hora de decidir el número de máquinas necesarias para una instalación real, tendrá que tener en cuenta (como mínimo) las consideraciones siguientes:
- Servidor de Novell Audit: Esta parte es la encargada de capturar información relativa a eventos (y posiblemente buena parte de la información restante) en el entorno de la aplicación de usuario en el momento de ejecutarse. Es posible que su tarea sea también doble como almacén de consolidación para otras aplicaciones de su empresa. Por una serie de motivos, probablemente no deseará poner otras partes importantes del sistema del Gestor de identidades (como, por ejemplo, JBoss o el repositorio seguro de identidades) en la misma máquina que el servidor de Audit.
- Repositorio seguro de identidades: Este componente tiene una carga de tráfico elevada y tanto su rendimiento como su capacidad de ampliación deben ser buenos. Por todo ello, es muy probable que piense en poner el repositorio seguro de identidades en una máquina dedicada. Es decir, probablemente no deseará que otro sistema con tráfico elevado como JBoss, con una implantación de la aplicación de usuario, se ejecute junto con el repositorio seguro de identidades en la misma máquina.
- Base de datos: Si esta instancia de MySQL (u otra base de datos admitida) es también la base de datos de Novell Audit, probablemente estará en una máquina dedicada. Tenga en cuenta que la aplicación de usuario utiliza esta parte de la forma siguiente:
- Como almacén de consolidación de los datos de configuración del portal
- Como almacén de consolidación de la información de estado acerca de los flujos de trabajo que están en curso (si el módulo de provisión está instalado).
- Opcionalmente, como almacén de registros de Novell Audit.
- JBoss: Por motivos de rendimiento y capacidad, es probable que desee ejecutar esta parte en una máquina dedicada.
Basándose en las observaciones anteriores, se sugiere el uso de las configuraciones con un mínimo de 3 máquinas que se detallan a continuación:
2.1.2 Diseño de alta disponibilidad
La agrupación en clúster para obtener una mayor capacidad y disponibilidad se trata con más detalle en una sección posterior de este capítulo. Por ahora, tenga en cuenta que:
- El Gestor de identidades admite una alta disponibilidad del repositorio seguro de identidades, el motor y los controladores mediante mecanismos de instalación multinodo y de almacenamiento compartido descritos en el capítulo relativo a la “Alta disponibilidad” de la guía de administración principal del Gestor de identidades. Encontrará instrucciones completas acerca de cómo configurar un sistema de este tipo con SUSE Linux en el artículo que se encuentra en:
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10093317.htm
- Se puede conseguir una alta disponibilidad de la aplicación de usuario a través de la agrupación en clúster de JBoss. Por ejemplo, puede configurar un clúster de JBoss de tal manera que cada nodo ejecute una instancia de la aplicación de usuario. Todas las instancias serán iguales (pares). No obstante, tenga en cuenta que no se producen réplicas de sesiones entre las instancias. Cada instancia es responsable de su propia unidad de trabajo y no terminará ninguna sesión iniciada en un nodo hermano.
- No se admite una migración de recursos automática (por los motivos que acabamos de indicar). Si bien, se puede reanudar un flujo de trabajo interrumpido después de la pérdida de un nodo de clúster, si se conecta otro nodo con el mismo ID del motor del flujo de trabajo que el nodo desactivado. (En este caso, la reanudación del flujo de trabajo interrumpido se produce automáticamente, tan pronto como el nuevo motor del flujo de trabajo se inicia).
Consulte también Sección 2.4, Agrupación en clúster (más adelante) para obtener información detallada acerca de estas cuestiones.
2.1.3 Restricciones de diseño
Por lo general, las dos restricciones arquitectónicas principales que deben tenerse en cuenta son:
- Ninguna instancia de la aplicación de usuario puede atender (buscar y consultar, añadir usuarios a, etc.) a más de un contenedor de usuarios. Asimismo, una vez que se ha asociado un contenedor de usuario a la aplicación, dicha asociación será permanente.
- Ningún controlador de la aplicación de usuario puede asociarse a más de una aplicación de usuario, salvo en el caso en que las aplicaciones de usuario estén instaladas en nodos hermano del mismo clúster de JBoss. Dicho de otro modo, no se admite una asignación del tipo "uno a varias" de controlador a varias aplicaciones de usuario.
La primera restricción aplica un alto grado de encapsulación en el diseño de la aplicación de usuario.
Supongamos que tiene la siguiente estructura administrativa:
Durante la instalación de la aplicación de usuario, el sistema le solicita que especifique el contenedor de usuario de máximo nivel que la instalación buscará en el repositorio seguro de identidades. En dicho caso, puede especificar ou=Marketing,o=ACME o bien (como alternativa) ou=Finance,o=ACME. No se pueden especificar ambos. Todas las búsquedas y consultas de la aplicación de usuario (y entradas del administrador) se realizarán en el ámbito del contenedor que especifique.
NOTA:En teoría, puede especificar un ámbito de o=ACME a fin de incluir Marketing y Finance. No obstante, en las grandes organizaciones con posiblemente varios contenedores ou (en vez de sólo dos relativos a Marketing y Finance), probablemente esto no sea práctico.
Evidentemente, es posible crear dos instalaciones independientes de la aplicación de usuario (que no compartan recursos comunes), una para Marketing y otra para Finance. En tal caso, cada instalación tendrá su propia base de datos, su propio controlador de la aplicación de usuario configurado de forma adecuada, y cada aplicación de usuario se administrará por separado y, posiblemente, poseerá temas únicos.
Si realmente necesita tener Marketing y Finance en el mismo ámbito para una instalación de la aplicación de usuario, puede aplicar una de las dos tácticas siguientes. Una de ellas consiste en insertar un objeto Contenedor nuevo (por ejemplo, ou=MarketingAndFinance) en la jerarquía, por encima de los dos nodos hermanos y, a continuación, indicar el nuevo contenedor como la raíz del ámbito. La otra táctica consiste en crear una réplica filtrada (un tipo especial de árbol eDirectory) que combina las partes que se necesitan del árbol ACME original y en apuntar aplicación de usuario al contenedor raíz de la réplica. (Consulte la publicación Novell eDirectory Administration Guide [Novell eDirectory: Guía de administración] para obtener más información acerca de las réplicas filtradas).
Si tiene alguna duda o pregunta acerca de una determinada disposición del sistema, póngase en contacto con el representante de Novell para que éste le aconseje o le ayude.