Problemas relacionados con la planificación de la instalación
El objetivo del proceso de configuración e instalación es conseguir el sistema distribuido que se describe en la arquitectura de implementación. El sistema distribuido consta de instancias de componentes que se ejecutan en varios equipos e interactúan entre ellas. Para conseguir un sistema distribuido operativo, debe instalar las instancias de los componentes en varios equipos y realizar la configuración básica que hace posible la interacción entre las instancias de los componentes.
Los procedimientos para instalar y configurar están determinados por el comportamiento del instalador de Java ES y los requisitos para los componentes individuales. Para asegurarse de que consiga un sistema distribuido que funciona, debe desarrollar un plan de instalación que utilice el instalador de forma adecuada y considere los requisitos de los componentes que integran la solución. El plan debe describir el orden correcto para instalar las instancias de los componentes y realizar las tareas básicas de configuración. Asimismo, debe especificar los valores de configuración que requieren las instancias de los componentes para interactuar.
En esta sección se describen los principales problemas que deberá tener en cuenta cuando desarrolle un plan de instalación.
Instalaciones distribuidas
Los requisitos de calidad de servicio para las soluciones de producción de Java ES llevan a arquitecturas que distribuyen las instancias de componentes por varios equipos. Por ejemplo, para lograr unos servicios de mensajería fiables, la arquitectura puede requerir dos instancias de Messaging Server en dos equipos distintos y el uso del equilibrado de carga para establecer una relación de conmutación por error entre las dos instancias.
El instalador de Java ES, sin embargo, ejecuta sólo un equipo cada vez. En consecuencia, cuando instale una solución distribuida, deberá ejecutar el instalador en cada equipo usado en la solución.
En muchos casos, debe instalar uno o varios componentes en un equipo y, a continuación, ejecutar los asistentes de configuración con objeto de realizar las tareas básicas de configuración. Normalmente, se completa la configuración y la instalación en un equipo antes de continuar con la instalación y la configuración de otro conjunto de componentes en otro equipo. Para instalar y configurar instancias de componentes distribuidas, puede realizar una secuencia de tareas similar a la que se muestra en la Figura 3–1.
Figura 3–1 Ejemplo de procedimiento de instalación distribuida
Configuración de la interacción
El objetivo del proceso de instalación es un sistema de instancias de componentes que interactúen entre ellas. Cuando instale los componentes y realice una configuración básica, debe proporcionar los valores de configuración que darán como resultado la interacción de las instancias de componentes.
Los valores de configuración que dan como resultado la interacción incluyen valores como las direcciones URL o los números de puerto que usa una instancia de componente para comunicarse con otra, así como los Id. de cuenta de administrador y las contraseñas que utiliza una instancia de componente para autorizar el acceso a otra. Por ejemplo, si una solución usa Access Manager, primero deberá instalar y configurar un repositorio LDAP, como, por ejemplo, una instancia de Directory Server. A continuación, cuando instale y configure una instancia de Access Manager, deberá proporcionar los valores de configuración que indican a la instancia dónde se encuentra el directorio LDAP que ha preparado.
El instalador de Java ES no sabe qué componentes están instalados en los otros equipos que forman la solución. Por ejemplo, cuando instale Access Manager, el instalador no sabrá dónde está ubicado el directorio LDAP adecuado. Para garantizar el éxito de la instalación y el proceso de configuración, debe planificar por adelantado qué componentes se instalarán en cada equipo. A medida que agrega los componentes a la solución, debe configurarlos para que interactúen con los componentes que ya están instalados en otros equipos.
Puede ejecutar una secuencia de tareas de instalación y configuración semejante a la que se muestra en la Figura 3–2.
Figura 3–2 Configuración de los componentes para que interactúen
Con independencia de la arquitectura de la solución, debe desarrollar un plan de instalación que incluya todos los valores de configuración necesarios para configurar los componentes y conseguir una solución distribuida que interactúe con otros componentes.
Relaciones de dependencia de los componentes
Algunos componentes de Java ES no se pueden instalar ni configurar a menos que otros componentes se instalen y configuren primero. Las dependencias se producen por varios motivos:
-
Algunos componentes no pueden funcionar a menos que haya instalados y configurados otros componentes. Por ejemplo, la interfaz de Communications Express necesita los datos proporcionados por los servicios de calendario y mensajería. El procedimiento de configuración de Communications Express requiere la especificación de direcciones URL que permitan la interacción de Communications Express con los servicios de mensajería y calendario que ya estén funcionando. Debido a esta dependencia, Messaging Server y Calendar Server deben instalarse y configurarse antes de instalar y configurar Communications Express.
-
Una serie de componentes requiere un directorio LDAP para la autenticación y la autorización. Los procedimientos de instalación y configuración de las instancias de estos componentes requieren la especificación de direcciones URL para el servicio de directorio LDAP. A causa de esta dependencia, Directory Server (o algún otro repositorio de identidades) debe instalarse antes de instalar los componentes que usan el servicio de directorio LDAP.
-
Algunos componentes modifican la configuración de un componente existente. Por ejemplo, al instalar y configurar Access Manager, se modifica el esquema del directorio LDAP. Si la solución usa Access Manager, el plan de instalación debe especificar que un directorio LDAP está instalado y configurado antes de instalar Access Manager.
-
Una cantidad de componentes de Java ES son aplicaciones web. Estos componentes deben implementarse en contenedores web para que puedan funcionar. Hay que instalar y ejecutar un contenedor web para que sea posible instalar y configurar los componentes. Puede usar Web Server o Application Server (u otro contenedor web de otro fabricante), porque un contenedor web debe estar presente en el equipo cuando instale el componente de la aplicación web.
Consejo –Si la aplicación utiliza Web Server o Application Server, el instalador de Java ES podrá instalar el contenedor web y el componente de la aplicación web al mismo tiempo e implementar automáticamente el componente de la aplicación web en el contenedor web.
-
Los componentes pueden instalarse en un clúster de alta disponibilidad proporcionado por el software de Sun Cluster. El software de Sun Cluster debe instalarse y estar en ejecución antes de instalar y configurar otros componentes. Adicionalmente, Sun Cluster Agents debe estar instalado y configurado para los otros componentes.
Tenga en cuenta que algunas de estas dependencias pueden afectar a la solución entera y otras pueden ser sólo locales. Las dependencias que afectan a todo el sistema se administran de forma diferente de las dependencias locales cuando se desarrolla el plan de instalación. Las diferencias se describen en el siguiente ejemplo:
La dependencia de Access Manager con respecto a Directory Server es una dependencia que afecta a todo el sistema. Cuando se instala Access Manager, se debe proporcionar una dirección URL para un servicio de directorio proporcionado por una o varias instancias de Directory Server. Una vez que Directory Server esté instalado y configurado, el servicio de directorio estará disponible para todos los componentes de la solución. Este tipo de dependencia determina la secuencia para toda la solución a la hora de instalar y configurar las instancias de los componentes: Directory Server se debe instalar y configurar antes que Access Manager. En el plan de instalación, las dependencias que afectan a toda la solución determinan la secuencia general de instalación y los pasos que se deben realizar.
La dependencia de Access Manager con respecto a un contenedor web es una dependencia local. Para satisfacer esta dependencia, hay que instalar un contenedor web en el equipo en el que se ejecute Access Manager. Este contenedor web, no obstante, no proporciona servicios para toda la solución. En una solución distribuida, los contenedores web se suelen instalar en varios equipos. Cada contenedor web funciona con un componente distinto de forma local. En consecuencia, en una solución distribuida no hay una única ubicación para la instalación del contenedor web y no hay un único punto en la secuencia de instalación para instalar el contenedor web.
Para desarrollar un plan de instalación para la solución, debe analizar la arquitectura de implementación que describe la solución e identificar las dependencias existentes entre los componentes. En el plan se deben instalar y configurar los componentes en una secuencia tal que se satisfagan todas las dependencias. La secuencia de instalación general se suele desarrollar a partir de las dependencias que afectan a toda la solución. Después, hay que considerar las dependencias locales que existan en cada equipo.
Las dependencias de los componentes se incluyen en la Tabla 3–1. Para obtener más información acerca del trabajo con dichas dependencias, consulte las descripciones de los componentes individuales en Desarrollo de un plan de instalación.
Tabla 3–1 Dependencias de los componentes de Java ES
Estrategias de redundancia
La mayoría de las soluciones destinadas a la producción incluyen algún tipo de redundancia. Las estrategias de redundancia utilizan varias instancias de un componente para proporcionar un único servicio. La redundancia se usa para satisfacer los requisitos de calidad del servicio. Por ejemplo, la redundancia se usa para aumentar el ritmo de trabajo con objeto de satisfacer los requisitos de rendimiento o para evitar un punto único de fallo y así satisfacer también los requisitos de fiabilidad.
Hay disponibles tres estrategias para usar instancias redundantes de los componentes de Java ES: equilibrado de carga, uso de clústeres con el software de Sun Cluster y repetición de varias réplicas principales con Directory Server. Los procedimientos de instalación y configuración recomendados para cada una de estas estrategias se describen brevemente en los siguientes párrafos:
-
El equilibrado de carga se puede realizar mediante el hardware o el software. La mejor forma de configurar el equilibrado de carga es instalar y configurar una instancia del componente de equilibrado de carga y, a continuación, comprobar que el servicio que proporciona la primera instancia esté disponible a través del equilibrador de carga. Después de comprobar que el servicio esté disponible, deberá instalar y configurar instancias adicionales del componente requerido por la arquitectura de implementación. Este enfoque por fases para instalar y configurar facilita la resolución de los problemas de configuración.
-
Los sistemas organizados en clústeres se implementan en varios pasos. El primero de ellos consiste en instalar el software de Sun Cluster, y establecer y configurar el clúster. En el siguiente paso, debe instalar los componentes que se ejecutan en el clúster. Por ejemplo, el primer paso para implementar el clúster que se muestra en la Figura 2–1 es instalar el software de Sun Cluster en los equipos mscs01 y mscs02, y establecer y configurar el clúster. El segundo paso consiste en instalar y configurar Messaging Server y Calendar Server. En el tercer y último paso, hay que instalar y configurar Sun Cluster Agents para Messaging Server y Calendar Server. Cuando se configura Sun Cluster Agents, los nodos del clúster reconocen la existencia de Messaging Server y de las instancias de Calendar Server.
-
La repetición de varias réplicas principales de Directory Server también se implementa en varios pasos. En el primero de ellos se instalan, configuran y comprueban todas las instancias de Directory Server. En el segundo paso, hay que desconectar todas las instancias de Directory Server excepto una. La instalación y la configuración de los demás componentes de la solución se realizan en el tercer paso. Los cambios que se realizan en la estructura del directorio o en el esquema se aplicarán a la única instancia de Directory Server que esté en ejecución. El paso final, una vez que todas las instancias de los componentes estén instaladas, configuradas y comprobadas, consiste en reiniciar las demás instancias de Directory Server y usar la función de replicación para configurar la sincronización y la conmutación por error. De esta manera, se copian los datos del directorio modificado y actualizado en todas las instancias de Directory Server.
Cuando la arquitectura de implementación utiliza cualquiera de estas estrategias de redundancia, hay que desarrollar un plan para instalar varias instancias de un componente y configurarlas para que funcionen como un único servicio.
Subcomponentes distribuidos
Algunos componentes de Instant Messaging tienen subcomponentes que se pueden instalar y configurar por separado. Por ejemplo, Messaging Server tiene cuatro subcomponentes: agente de transferencia de mensajes (MTA, Message Transfer Agent), multiplexor de mensajes (MMP, Message Multiplexor), multiplexor de Messenger Express (MEM, Messenger Express Multiplexor) y almacén de mensajes (Message Store). Una arquitectura de implementación puede colocar estos subcomponentes en sistemas de equipos separados para satisfacer la calidad de los requisitos de servicio. Por ejemplo, la arquitectura de ejemplo que aparece en la Figura 2–1 coloca las instancias de MEM en los sistemas informáticos CX1 y CX2, el agente de transferencia de mensajes salientes en los sistemas informáticos MTA1 y MTA2, el agente de transferencia de mensajes entrantes en los sistemas informáticos MTA3 y MTA4, el MMP en los sistemas MMP1 y MMP2 y, por último, el almacén de mensajes en los sistemas STR1 y STR2.
En la Tabla 3–2 figuran los componentes de Java ES que tienen subcomponentes que se pueden instalar por separado. Analice la arquitectura de implementación de la solución y determine si se utilizan en ella subcomponentes distribuidos. Si la solución utiliza subcomponentes distribuidos, deberá desarrollar un plan para instalar los subcomponentes en los sistemas informáticos pertinentes en el orden correcto y configurarlos para que interactúen. Para obtener más información acerca de la configuración de los subcomponentes distribuidos, consulte las descripciones de los componentes individuales enDesarrollo de un plan de instalación.
Tabla 3–2 Componentes con subcomponentes|
Componente |
Subcomponente |
|---|---|
|
Instant Messaging Multiplexor Instant Messenger Resources Instant Messaging Server |
|
|
Message Transfer Agent (MTA) Message Store Messaging Multiplexor (MMP) Messenger Express Multiplexor (MEM) |
Los subcomponentes se pueden instalar por separado. Si la arquitectura de implementación requiere la ejecución de subcomponentes distribuidos, ejecute el instalador en cada equipo y seleccione los subcomponentes especificados en la arquitectura. Los valores de entrada requeridos por el programa de instalación o el asistente de configuración son un subconjunto de valores del componente entero. Para los componentes que no configure el instalador, inicie el asistente para la configuración, seleccione los subcomponentes que se deben configurar en el equipo y proporcione los valores de entrada que requiera el asistente.
Esquema LDAP y estructura del árbol del directorio LDAP
La mayoría de las soluciones de Java ES incluyen Directory Server. La instalación y la configuración de una solución requieren valores de entrada que establezcan tanto el esquema del directorio como la estructura del árbol de directorio. En el plan de instalación deben aparecer los valores de entrada que den como resultado una estructura del árbol de directorio y un esquema LDAP correctos.
La estructura del árbol de directorio y el esquema LDAP se especifican antes de comenzar el plan de instalación. Para ver ejemplos de especificaciones, consulte Desarrollo de las especificaciones de administración de usuarios.
El esquema LDAP se establece mediante los siguientes procesos de instalación y configuración:
-
Al instalar Directory Server, se crea de forma automática un directorio con Schema 1. No es necesario especificar ningún valor para seleccionar este esquema.
-
Al instalar Access Manager, se modifica de forma automática el directorio y se convierte en Schema 2. No es necesario especificar ningún valor para seleccionar este esquema.
-
Al ejecutar Directory Preparation Tool, se amplía el esquema para usarlo con Messaging Server, Calendar Server y Communications Express. Directory Preparation Tool amplía tanto los directorios Schema 1 como Schema 2. Los valores de entrada para Directory Preparation Tool aparecen en el plan de instalación.
-
Al ejecutar Delegated Administrator, se amplía el esquema con clases de objetos y atributos que se utilizan para autenticar usuarios para servicios específicos. Los valores de entrada dependen del servicio que proporcione la solución. Los valores de entrada aparecen en el plan de instalación. Para obtener más información acerca de los valores de entrada, consulte Cómo agregar procedimientos para Delegated Administrator al plan de instalación.
Los procesos de instalación y configuración también establecen la estructura básica del árbol de directorio:
-
Al instalar Directory Server se crea un sufijo base, también conocido como "root del árbol de directorio". El sufijo base es un valor de entrada obligatorio cuando el instalador de Java ES instala Directory Server. En el plan de instalación figuran los sufijos base como uno de los valores de entrada para el proceso de instalación.
-
La instalación y configuración de Messaging Server crea ramificaciones en el árbol de directorio y genera una organización LDAP. Esta organización representa el dominio de correo electrónico administrado por la instancia de Messaging Server. El nombre de la organización es una entrada obligatoria para el asistente de configuración de Messaging Server. En el plan de instalación se incluye el DN de la organización como uno de los valores de entrada para el proceso de configuración de Messaging Server.
-
Al instalar y configurar Calendar Server, Communications Express, Delegated Administrator y Instant Messaging, se especifica en qué lugar del directorio deben buscar estos componentes los datos de los usuarios. Un DN LDAP es una entrada obligatoria para todos los asistentes de configuración de los componentes. En el plan de instalación figura el DN como valor de entrada para cada asistente de configuración. Si la solución utiliza la función de inicio de sesión único de Access Manager, todos estos componentes deberán configurarse para que usen la misma ubicación para los datos de usuario, que es la organización que creó el asistente de configuración de Messaging Server. El mismo DN LDAP se utiliza como entrada en todos los asistentes de configuración. En el plan de instalación se incluye el DN de la organización como uno de los valores de entrada para todos los asistentes de configuración.
Los nombres para el sufijo base LDAP y la organización del dominio de correo electrónico se toman de la especificación de administración de usuarios y se agregan al plan de instalación. Para obtener más información acerca de la especificación de administración de usuarios, consulte Desarrollo de las especificaciones de administración de usuarios. Para obtener más información acerca de la adición de un sufijo base LDAP al plan de instalación, consulte Tabla 3–5. Para obtener más información acerca de la adición de la organización del dominio de correo electrónico al plan de instalación, consulte: Tabla 3–9, Tabla 3–10, Tabla 3–11, Tabla 3–13 y Tabla 3–14.
Comportamiento del instalador de Java ES
En esta sección se describen algunos comportamientos del instalador de Java ES que repercuten en la planificación de la instalación.
El instalador es local
El instalador de Java ES instala componentes de software en un equipo cada vez. Para la mayoría de las soluciones, esto supone que hay que ejecutar el instalador más de una vez. El plan de instalación debe indicar cuántas veces es necesario ejecutar el instalador. En esta sección se describe la forma de analizar una arquitectura de implementación y de determinar cuántas veces hay que ejecutar el instalador para instalar y configurar una solución.
Algunas soluciones se instalan solamente en un equipo y los planes de de instalación de estas soluciones indican los procedimientos para ejecutar el instalador sólo una vez. Las soluciones que requieren que el instalador se ejecute sólo una vez son las siguientes:
-
Una serie de componentes que se instalan en un equipo para evaluar el funcionamiento de Java ES.
-
Una instancia de componente que se agrega a una solución establecida. Esto incluye la adición de instancias de componentes que tengan dependencias de los componentes existentes.
La mayoría de las soluciones están distribuidas entre varios equipos. Los planes de instalación para estas soluciones deben incluir varias ejecuciones del instalador para instalar y configurar la solución entera. Para analizar estas soluciones, siga estas directrices:
-
La mayoría de combinaciones de componentes de un equipo pueden instalarse ejecutando el instalador una vez. Esta afirmación se cumple especialmente si el instalador se ejecuta en el modo Configure Now (Configurar ahora) porque en este modo, el instalador puede instalar tanto el contenedor web como el componente que se ejecuta en dicho contenedor web. En estos casos, el plan de instalación indica que se debe ejecutar el instalador una vez en el equipo y que se deben seleccionar todos los componentes especificados para el equipo en cuestión.
Consejo –Algunos componentes no se pueden configurar con el instalador, ni siquiera en el modo Configure Now (Configurar ahora). Cuando estos componentes se instalan en un equipo, el proceso de configuración se completa ejecutando un asistente de configuración para cada componente. Cuando estos componentes se instalan junto con otros componentes que se configuran con el instalador, éste se ejecuta primero. Después de que se ejecute, el proceso se completa ejecutando los asistentes de configuración para aquellos componentes que no configuró el instalador. En estos casos, el plan de instalación debe especificar que se ejecute el instalador, así como la secuencia correcta para ejecutar los asistentes de configuración.
-
Algunas combinaciones de componentes sólo se pueden instalar ejecutando el instalador más de una vez en un equipo. Entre estas combinaciones se incluyen las siguientes:
-
Algunas combinaciones de componentes que incluyen un contenedor web. Si Web Server o Application Server se instalan con el modo Configure Later (Configurar más tarde), una instancia de Web Server o Application Server debe configurarse y comprobarse antes de que el componente que se ejecuta en el servidor web pueda instalarse. Si la solución utiliza contenedores web de otros fabricantes, el contenedor web debe instalarse con su propio instalador, e iniciarse y comprobarse antes de instalar los componentes de Java ES. El plan de instalación debe indicar que es necesario ejecutar el instalador varias veces en cada equipo.
-
Combinaciones de componentes que usan el software de Sun Cluster. Si los componentes instalados en el clúster están instalados en un sistema de archivos en clúster, el software de Sun Cluster debe instalarse antes, al igual que el sistema de archivos en clúster también debe crearse antes para que otros componentes puedan instalarse en los nodos del clúster. El plan de instalación debe indicar que es necesario ejecutar el instalador varias veces en cada equipo.
-
El propósito de esta sección es presentar el concepto de que los planes de instalación deben especificar a veces que es necesario ejecutar el instalador y los asistentes de configuración sólo en un equipo o que es necesario ejecutar el instalador varias veces en un equipo. Para obtener más información acerca de los procedimientos de instalación reales para las distintas combinaciones de componentes, consulte Desarrollo de un plan de instalación.
Modos de funcionamiento del instalador
El instalador puede ejecutarse en dos modos de configuración, llamados Configure Now (Configurar ahora) y Configure Later (Configurar más tarde). Estos modos se diferencian en los siguientes aspectos:
-
En el modo Configure Now (Configurar ahora), el instalador configura las instancias ejecutables de algunos componentes, pero no de todos ellos. Los componentes configurados mediante el modo Configure Now (Configurar ahora) se pueden iniciar y comprobar en el momento mismo en que finalice el instalador. Las instancias ejecutables del resto de componentes se crean después de ejecutar el instalador mediante el uso de los asistentes de configuración de los productos componentes. Para los componentes que se configuran con el instalador, éste requiere que se especifiquen ciertos valores de configuración. El plan de instalación incluye estos valores como parte de las instrucciones para ejecutar el instalador. En el caso de los componentes configurados después de ejecutar el instalador, los asistentes de configuración requieren los valores de configuración y éstos se incluyen en las instrucciones para ejecutar los asistentes de configuración.
Consejo –Una función importante del modo Configure Now (Configurar ahora) es la posibilidad de instalar al mismo tiempo el contenedor web y los componentes que se ejecutan en él. El instalador implementa automáticamente los componentes en el contenedor web.
-
En el modo Configure Later (Configurar más tarde), el instalador copia los archivos de software de los componentes en el equipo, pero no crea instancias ejecutables. Las instancias se crean después de ejecutar el instalador, utilizando los asistentes de configuración de los productos componentes. Se deben especificar los valores de configuración como entradas de datos para los asistentes de configuración; estos valores se encuentran en las instrucciones para ejecutar los asistentes de configuración.
La opción de configuración seleccionada se aplica a toda la sesión de instalación. Si necesita seleccionar una opción de configuración diferente para algunos componentes, es posible que tenga que llevar a cabo sesiones de instalación adicionales.
Comprobaciones de compatibilidad del instalador
El instalador realiza algunas comprobaciones de dependencias y compatibilidad. Las comprobaciones se realizan sólo de forma local. Por ejemplo, si la solución utiliza una instancia remota de Directory Server, el instalador no podrá comprobar si dicha instancia remota de Directory Server es compatible con la instancia de Access Manager que está instalando. Si está instalando y configurando una solución totalmente nueva. Pueden surgir problemas en el momento de agregar un nuevo componente a una solución establecida o si está creando un Sun Java System en torno a componentes existentes. Por ejemplo, si ya usa Directory Server y crea una solución con Access Manager, Messaging Server, Calendar Server y Communications Express en torno al Directory Server existente, la compatibilidad entre estos componentes se convierte en un problema.
-
Comprobación de las dependencias existentes entre los componentes. El instalador de Java ES le impedirá omitir componentes requeridos por otros componentes que haya seleccionado para instalarlos, pero sólo en el host local. En una solución distribuida, el instalador no comprueba el host remoto para saber si el componente remoto está allí. Será el usuario el que deba averiguar si el componentes remoto es compatible y si su estado de ejecución es el adecuado.
-
Actualización. El instalador de Java ES no realiza ninguna actualización de componentes, excepto cuando Application Server y Message Queue se han instalado con el SO Solaris. En este caso, el instalador le preguntará si desea actualizar Application Server y Message Queue durante la instalación.
El instalador de Java ES sí realiza actualizaciones de componentes compartidos. Para obtener más información sobre este tema, consulte Análisis de los host existentes de Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX.
Otros problemas relacionados con la instalación
En esta sección se describen ciertos problemas específicos que se producen en algunas soluciones. Se proporcionan referencias para obtener información detallada sobre ellos.
Tabla 3–3 Problemas de instalación que se deben tener en cuenta|
Problema |
Directrices o instrucciones |
|---|---|
|
Uso de zonas de Solaris 10 |
Si va a realizar una instalación en zonas de Solaris 10, consulte Zonas de Solaris 10 de Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX. |
|
Uso de cifrado con Directory Server |
Configuración de LDAPS (SSL a través de LDAP) en la instancia de Directory Server Nota: Si el cifrado de Directory Server es obligatorio, será necesario instalar Administration Server al instalar Directory Server. |
|
Uso de un contenedor web de otros fabricantes con Access Manager |
Los contenedores web de otros fabricantes (BEA WebLogic Server o IBM WebSphere Application Server) se pueden usar con Portal Server y Access Manager. Estos contenedores se deben instalar y ejecutar antes de instalar cualquier componente de Java ES que dependa de ellos. Para usar un contenedor web de otro fabricante para Access Manager SDK, hay que configurar Access Manager SDK manualmente después de la instalación. Consulte Ejemplo de Access Manager SDK con configuración de contenedor de Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX. Nota: Portal Server sólo puede usar contenedores web de otros fabricantes con el SO Solaris. Nota: Access Manager y Portal Server deben usar el mismo tipo de contenedor web. |
|
Uso de Apache Web Server para el complemento de equilibrado de carga |
Apache Web Server se puede usar con el complemento de equilibrado de carga de Application Server. En este caso, Apache Web Server deberá estar instalado y en ejecución antes de instalar ningún otro componente de Java ES que dependa de él. Para obtener información adicional, consulte Requisitos previos de la instalación de Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX. |
|
En Ejemplo de Schema 1 de Calendar-Messaging de Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX aparece un ejemplo de instalación basado en LDAP Schema 1. Para una implementación de Schema 1, no se puede utilizar Access Manager. |
|
|
Configuración de una entrada única de usuario y del inicio de sesión único |
Los procedimientos para configurar un inicio de sesión único se encuentran en el Chapter 8, Configuring and Using Single Sign-On, de la Sun Java Enterprise System 2005Q1 Deployment Example Series: Evaluation Scenario. La presencia de Access Manager es obligatoria para el inicio de sesión único. |
|
Configuración de funciones de alta disponibilidad con HADB |
Un ejemplo de configuración de HADB para alta disponibilidad se incluye en Ejemplo de Web and Application Services de Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX. |
|
Equilibrado de carga de Application Server |
Un ejemplo que incluye el uso del complemento de equilibrado de carga de Application Server se incluye en Ejemplo de Web and Application Services de Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX. |
|
Propietario no root |
Si se requiere un propietario no root para Application Server o Web Server , consulte uno de los siguientes ejemplos: |
- © 2010, Oracle Corporation and/or its affiliates