Apéndice A Zonas de Java ES y Solaris 10

En este apéndice se describen los problemas que surgen cuando se instalan y configuran componentes de Java ES en zonas de Solaris 10, y se recomiendan maneras de proceder para resolver dichos problemas. Este apéndice contiene las secciones siguientes:

• ¿Qué son las zonas?

• ¿Por qué utilizar zonas para Java ES?

• Limitaciones de zonas de los componentes de Java ES

• Compatibilidad de zonas en el instalador de Java ES

• Uso recomendado de zonas con Java ES

• Casos especiales o excepciones

• Un ejemplo ilustrativo: Instalación de Application Server en una zona de poca raíz.

¿Qué son las zonas?

Las zonas son una funcionalidad de gestión de recursos del sistema operativo Solaris 10. Esta función permite al sistema operativo presentarse a las aplicaciones como entornos (zonas) del sistema operativo virtual que están aisladas y protegidas. Estas zonas proporcionan las ventajas de la independencia de los sistemas operativos junto con un cierto nivel de gestión de recursos centralizada. Así las aplicaciones se pueden aislar las unas de las otras al estar instaladas y ejecutarse desde zonas diferentes, a la vez que se asignan y utilizan centralmente ciertos recursos del sistema operativo.

Desde el punto de vista de un sistema operativo compatible con varias zonas, los recursos del sistema operativo incluyen recursos como la gestión de procesos, memoria, configuración de la red, sistemas de archivos, registros de paquetes, cuentas de usuario, bibliotecas compartidas y, en algunos casos, aplicaciones instaladas.

Estructura de un entorno de varias zonas

Los entornos de varias zonas consisten en una zona global (el sistema operativo predeterminado) y una o más zonas no globales. La zona global contiene recursos que un administrador global (de zonas) puede asignar a zonas no globales. Las zonas no globales proporcionan las características siguientes:

• Security (Seguridad). Al ejecutar servicios distribuidos en zonas no globales, se pueden limitar los daños posibles en caso de una violación de la seguridad. Un intruso que se aproveche de un defecto de seguridad dentro de una zona estará limitado a dicha zona. Los privilegios disponibles dentro de una zona no global son un subconjunto de los disponibles en una zona global.

• Aislamiento durante el tiempo de ejecución. Las zonas no globales permiten la implementación de varias aplicaciones en un mismo equipo, incluso si dichas aplicaciones requieren distintos niveles de seguridad, acceso exclusivo a recursos globales o una configuración personalizada. Por ejemplo, varias aplicaciones que se están ejecutando en diferentes zonas pueden utilizar el mismo puerto de la red mediante direcciones IP diferentes asociadas con cada zona no global. Las aplicaciones no pueden ver ni interceptar el tráfico de red, datos de sistema de archivos o de los procesos de las otras aplicaciones.

• Aislamiento de la gestión. El entorno del sistema operativo virtualizado permite separar la gestión de cada zona no global. Las acciones llevadas a cabo por un administrador de zona (los que no son administradores globales) en una zona no global, tal como crear cuentas de usuario, instalar y configurar software y gestionar procesos no afectan las demás zonas.

Existen dos tipos de zonas no globales: zonas de raíz completa y zonas de poca raíz:

• Zonas de raíz completa. Contienen una copia de lectura/escritura del sistema de archivos que existe en la zona global. Cuando se crea una zona de raíz completa, todos los paquetes que se instalan en la zona global están a disposición de la zona de raíz completa: se crea una base de datos de paquete y se copian todos los archivos en la zona raíz entera para el uso dedicado e independente de la zona.

• Zonas de poca raíz. Contienen una copia de lectura/escritura de sólo una parte del sistema de archivos existente en la zona global (por esto se llaman de poca raíz) mientras otros sistemas de archivos están montados de forma de sólo escritura desde la zona global como sistemas de archivo virtuales loop-back. Cuando se crea una zona de poca raíz, el administrador global selecciona los sistemas de archivos para compartir la zona de poca raíz (de manera predeterminada, los directorios /usr, /lib, /sbin y /platform se comparten como sistemas de archivos de sólo lectura). Todos los paquetes instalados en la zona global se encuentran disponibles en la zona de poca raíz: se crea una base de datos de paquetes y todos los archivos del sistema de archivos montado se comparten con la zona.

Zonas de raíz completa / zonas de poca raíz

La decisión de utilizar zonas no globales de raíz completa o utilizar zonas no globales de poca raíz depende de si se quiere potenciar la eficiencia de recursos o el control de gestión. Las zonas de raíz completa le permite maximizar el control de la gestión (independencia y aislamiento) pero pagando el precio del incremento de uso de la memoria y otros recursos, mientras que las zonas de poca raíz optimizan el uso compartido eficiente de ejecutables y bibliotecas compartidas (a la vez que utiliza menos espacio de disco) pero pagando el precio de falta de independencia de gestión. Actualmente no existe ningún sistema de medición de las ventajas de rendimiento de zonas de poca raíz en relación a las zonas de raíz completa. Depende en buena medida en el software.

Propagación de paquetes

Los paquetes instalados en una zona global están (por defecto) disponibles para todas las zonas no globales: un proceso llamado propagación de paquetes. (Para que sea posible la propagación, las zonas no globales nuevas tienen que estar iniciadas, es decir estar en estado de ejecución) La propagación proporciona visibilidad y disponibilidad local (no global) a los paquetes instalados en la zona global. La propagación permite que la gestión de ciclos de vida de los paquetes de las aplicaciones (instalación, actualización, desinstalación) se realice de forma centralizada por un administrador global, mientras que la configuración de las aplicaciones y la gestión del tiempo de ejecución las realizan administradores de zonas (no globales).

Para las zonas de raíz completa, la propagación se logra a través de la copia automática de los archivos instalados de la zona global a las zonas de raíz completa y a través de la sincronización automática de información de registro. Para las zonas de poca raíz la propagación se logra mediante sistemas de archivos de sólo lectura compartidos entre las zonas globales y de poca raíz y mediante la sincronización automática de información del registro.

La propagación de paquetes a zonas no globales se controla a nivel de paquetes mediante atributos de paquete internos. Para algunos valores de estos atributos (los valores predeterminados, como mínimo), la propagación se puede deshabilitar en el momento de instalación mediante la opción pkgadd —G, que anula los valores de atributo. Una vez instalado, el comportamiento de propagación de un paquete no se puede modificar, excepto si se desinstala y se vuelve a instalar. Los parches, por ejemplo, no pueden cambiar el comportamiento de propagación de un paquete; de hecho, los parches deben aplicarse según el comportamiento de propagación del paquete que están actualizando.

¿Por qué utilizar zonas para Java ES?

El aislamiento que se proporciona a aplicaciones que se ejecutan en diferentes zonas es parecido al aislamiento proporcionado por aplicaciones que se ejecutan en los sistemas operativos de diferentes equipos. Por esto, en vez de instalar, configurar y ejecutar componentes Java ES en diferentes equipos para aislarlos y protegerlos, dichos componentes se pueden instalar, configurar y ejecutar en diferentes zonas dentro de un mismo equipo.

Esta consolidación de componentes Java ES también puede permitir un uso más eficiente de los recursos. Los componentes Java ES que se ejecutan en equipos de uso exclusivo para ellos con poco nivel de uso, pueden ejecutarse en diferentes zonas no globales de un mismo equipo. Los administradores globales pueden asignar recursos de forma dinámica entre las diferentes zonas según los requisitos de recursos de los componentes que se estén ejecutando en dichas zonas. (Tenga en cuenta que esta posibilidad requiere más conocimientos y comprensión de los requisitos de recursos de los diferentes componentes de lo que está disponible por ahora).

Un entorno de varias zonas puede ayudar a conseguir otros objetivos:

• Separación de versiones. Se pueden ejecutar conjuntos paralelos de componentes Java ES en diferentes zonas. Esto permite la migración de una versión Java ES a otra versión dentro de un periodo de tiempo específico. Por ejemplo, los componentes Java ES versión 4 en una zona no global se pueden ejecutar en paralelo con componentes de Java ES versión 5 en otra zona no global. Para alcanzar este tipo de separación de versiones, la gestión de ciclos de vida (y la gestión de configuración y tiempo de ejecución) queda delegada a los administradores de zona.

• Gestión centralizada de ciclos de vida. Aunque no son totalmente compatibles debido a las limitaciones de Java ES, las zonas permiten que sea posible centralizar la administración del ciclo de vida de componentes de Java ES: los componentes se pueden instalar, actualizar y desinstalar en la zona global pero configurarse y ejecutarse en varias zonas no globales para permitir el aislamiento del tiempo de ejecución, la seguridad, escalabilidad y otras necesidades. La centralización de la gestión de los ciclos de vida es ventajosa cuando existen varias instancias de un componente ejecutándose en diferentes zonas o cuando quiere asegurar que dichas instancias están sincronizadas con una misma versión.

  Por ejemplo, puede instalar Application Server una vez en la zona global y ejecutar varias instancias en diferentes zonas no globales. Las diferentes instancias de Application Server son compatibles con Access Manager, Portal Server y otros componentes Java ES (pueden ser los mismos componentes o componentes distintos en diferentes zonas no globales). O diferentes instancias de Application Server pueden ser utilizadas por diferentes equipos de desarrollo en diferentes zonas.

  Para alcanzar este objetivo la gestión de ciclos de vida lo realiza un administrador global, mientras que la gestión de configuración y de tiempo de ejecución se delega a los administradores de zona correspondientes. Este enfoque requiere una amplia coordinación cuando se realizan tareas de gestión de ciclos de vida (tal como actualizaciones).

• Independencia organizativa. Diferentes organizaciones pueden tener diferentes implementaciones de componentes Java ES o diferentes instancias de tiempo de ejecución de componentes Java ES, todas presentes ejecutándose en el mismo equipo. Por ejemplo, diferentes grupos de desarrolladores pueden utilizar diferentes instancias de componentes Java ES propias o bien diferentes implementaciones de Java ES para realizar pruebas, tareas de pre-producción o producción. La independencia en la organización se puede alcanzar de diversas maneras, según los objetivos específicos: o bien centralizando la gestión de ciclos de vida de java ES mientras se delega la gestión de la configuración y del tiempo de ejecución a los administradores de zona, o bien delegando todas las funciones de gestión (ciclo de vida, configuración y tiempo de ejecución) a los administradores de zona.

Los diferentes objetivos que se pueden alcanzar mediante el uso de Java ES en un entorno de varias zonas y los casos de uso que implican requieren distintas estrategias de implementación y administración de componentes Java ES en un entorno de varias zonas. Algunos objetivos requieren el uso del aislamiento de diferentes zonas para gestionar de forma independiente diferentes componentes Java ES y sus instancias de tiempo de ejecución, mientras que otros objetivos requieren el uso de las capacidades de propagación de la zona global para simplificar la gestión de ciclos de vida de los componentes Java ES.

Las estrategias de instalación y administración para el uso de Java ES en un entorno de varias zonas se repasarán tras hablar de algunas de las limitaciones de los entornos de varias zonas impuestas por la naturaleza del software de Java ES.

Limitaciones de zonas de los componentes de Java ES

Los componentes de Java ES están agrupados en tipos diferentes, tal como se describe en Descripción general técnica de Sun Java Enterprise System 5. Los componentes de servicio de sistema proporcionan la infraestructura básica de servicios de Java ES, mientras que los componentes de calidad de servicio mejoran dichos servicios de sistema. Estos dos tipos de componentes Java ES son conocidos como componentes de producto, componentes seleccionables con el instalador de Java ES.

Cada componente de producto depende de una o más bibliotecas compartidas conocidas como componentes compartidos Java ES. Los componentes compartidos los instala automáticamente el instalador de Java ES durante la instalación de componentes del producto, según los componentes del producto que se estén instalando. No se seleccionan, instalan o configuran uno por uno durante la implementación de componentes de producto Java ES.

Componentes compartidos de Java ES y zonas

El debate de la sección ¿Por qué utilizar zonas para Java ES? se centra en el uso de zonas por componentes del producto de Java ES: los que se pueden seleccionar de forma explícita en el instalador de Java ES e instalarse y configurarse en varias zonas para obtener la arquitectura de implementación y capacidad funcional deseada. Sin embargo, los componentes compartidos en los que los componentes del producto dependen establecen una serie de limitaciones sobre cómo se implementa Java ES en un entorno de varias zonas. Existen dos problemas relacionados con los componentes compartidos de Java ES y las zonas:

Sincronización de componentes compartidos

La dificultad de poner a prueba y admitir el alto número (unos 30) de componentes y las interacciones complejas entre componentes compartidos de Java ES y los componentes de producto Java ES hace que sea necesario que todos los componentes compartidos dentro de una misma instancia del sistema operativo se tengan que sincronizar con la misma versión de Java ES. En otras palabras, todos los componentes compartidos de Java ES instalados en un entorno que no sea de zonas o en una sola zona de un entorno Solaris 10 tienen que ser de la misma versión. Este requisito pone ciertos límites a cómo se puede utilizar Java ES en un entorno de varias zonas.

El requisito de sincronización implica lo siguiente:

• Las diferentes versiones de los componentes compartidos de Java ES sólo pueden residir en diferentes zonas. Por ejemplo, puede instalar componentes compartidos Java ES versión 4 en una zona y componentes compartidos Java ES versión 5 en otra zona, pero no podrá combinarlos en la misma zona.

• Si se actualiza un componente compartido en una zona o se introduce un componente compartido nuevo de una versión más reciente, entonces todos los componentes de la zona deberán actualizarse a la vez. (Es necesario que los componentes compartidos sean compatibles con versiones anteriores, de forma que los componentes de producto de la versión 4 funcionen con los componentes compartidos de la versión 5.) Por ejemplo, supongamos que un componente de producto de la versión 5 se instala en una zona donde residen uno o más componentes de producto de la versión 4. Como el componente de producto de la versión 5 requiere una serie de componentes compartidos de la versión 5, el requisito de sincronización significa que todos los componentes compartidos de la versión 4 que residan en dicha zona se tendrán que actualizar a la versión 5 cuando se instale el componente de producto de la versión 5. Esto es así aunque el componente de producto de la versión 5 que se esté instalando requiera diferentes componentes compartidos de los que ya están instalados en la zona.

• Cuando se instalan componentes compartidos en la zona global y se propagan desde la misma (consulte la sección Reglas de propagación de Java ES), debe tenerse especial cuidado en el mantenimiento de la sincronización de componentes compartidos en todas las zonas. En caso contrario, existe la posibilidad que componentes compartidos de una versión anterior de una zona no global se entremezclen con los componentes compartidos de la versión 5 que se han propagado desde la zona global. (Especial cuidado no significa que la administración del ciclo de vida de los componentes tenga lugar únicamente en la zona global. Para otener más información, consulte la Tabla A–2 y Casos especiales de componentes compartidos..)

El requisito de sincronización de componentes compartidos impone restricciones sobre qué limitaciones tiene el instalador de Java ES en un entorno de varias zonas (para obtener más información, consulte Compatibilidad de zonas en el instalador de Java ES) y afecta también a los procedimientos para instalar y actualizar componentes de producto de Java ES en un entorno de varias zonas.

Componentes compartidos y zonas de poca raíz

Otro problema que afecta el uso de Java ES en un entorno de varias zonas es que no se puede instalar un número elevado de componentes compartidos en zonas de poca raíz debido a los sistemas de archivos de sólo lectura de las zonas de poca raíz. Así los componentes compartidos cuyo directorio base es /usr (un directorio que, de manera predeterminada, se comparte en la zona global) deben instalarse en la zona global para que estén disponibles en una zona de poca raíz.

La incapacidad de instalar varios componentes compartidos Java ES en zonas de poca raíz significa que para poder instalar correctamente componentes de producto con dependencias en componentes compartidos de este tipo en zonas de poca raíz, los componentes compartidos se deben instalar primero en la zona global y posteriormente propagarlos hacia las zonas no globales.

Componentes de producto de Java ES y zonas

Algunos de los objetivos tratados en ¿Por qué utilizar zonas para Java ES? sobre el uso de Java ES en un entorno de varias zonas y los casos de uso que suponen hacen uso de las capacidades de propagación de la zona global para simplificar la gestión de los ciclos de vida de los componentes de producto de Java ES. Estos casos de uso, por ejemplo, requieren que la gestión de ciclos de vida de los componentes de producto de Java ES las realice el administrador global en la zona global, mientras que la gestión de la configuración y del tiempo de ejecución de dichos componentes las realizan los administradores de zona en las zonas no globales.

En otras palabras, los componentes de producto se instalarían y actualizarían en la zona global, pero las instancias se configuran y ejecutan en zonas no globales. Este caso de uso combinaría las ventajas de una gestión centralizada de los ciclos de vida con las ventajas del aislamiento y seguridad que proporcionan las zonas no globales.

Este caso, sin embargo, depende de la capacidad que tiene cada componente de producto de instalarse en la zona global y de poderse configurar y ejecutar en una zona no global. Esta separación depende de cómo se obtiene la configuración de cada componente de producto, dónde se almacenan los datos de configuración y datos dinámicos de aplicación, cómo se buscan los datos de configuración mediante la ejecución de archivos ejecutables y cómo se llevan a cabo las actualizaciones. Por ejemplo, la separación puede depender de qué hacen las secuencias de comandos de preinstalación y postinstalación: si inician o detienen instancias de componentes, si establecen enlaces a datos de configuración o realizan otras tareas que atenúan la diferencia entre gestión de ciclos de vida y gestión de configuración.

Esta separación también puede depender de si la configuración se realiza en una zona de raíz completa o en una zona de poca raíz. Por ejemplo, si una secuencia de comandos de configuración de componentes de producto graba en un sistema de archivos de sólo lectura de una zona de poca raíz (por ejemplo /usr) o si los sistemas de archivos no predeterminados (como /opt) están compartidos con una zona de poca raíz, entonces la configuración de un componente puede fallar.

---

Nota –

Casi todos los componentes de producto de Java ES se instalan en /opt , que de forma predeterminada, se puede escribir en zonas de poca raíz. Para obtener más información, consulte Guía de referencia de instalación de Sun Java Enterprise System para UNIX

---

Actualmente la capacidad de cada uno de los aproximadamente 20 componentes de producto Java ES de ser compatibles con la separación de la gestión de ciclos de vida y la gestión de configuración/tiempo de ejecución entre zonas globales y no globales no ha sido establecida. Los diferentes componentes de producto han adoptado diferentes enfoques de la configuración y de la actualización. En tal situación, actualmente no se admite la propagación de componentes de producto de Java ES (excepto para Message Queue). Para obtener más información, consulte Reglas de propagación de Java ES.

Compatibilidad de zonas en el instalador de Java ES

Según los caso de uso que se tratan en ¿Por qué utilizar zonas para Java ES? y los requisitos y limitaciones de componentes de Java ES que se tratan en Limitaciones de zonas de los componentes de Java ES , el instalador de Java ES proporciona compatiblilidad de zonas cualificadas para la instalación (y actualización) de componentes de producto de Java ES y para la sincronización de componentes compartidos. Las reglas se han implementado en el instalador para ayudar a prevenir casos de instalación y actualización problemáticos.

Reglas de propagación de Java ES

Basándose en las limitaciones mencionadas en la sección 3, el instalador de Java ES implementa dos reglas de propagación de Java ES:

• Cuando se instalan componentes de producto en la zona global, están configurados de forma predeterminada para que no se propaguen a zonas no globales (Message Queue es una excepción). Por esto las zonas no globales no los ven en sus registros ni tienen acceso a los componentes instalados.

• Cuando se instalan componentes compartidos en la zona global (por ejemplo, como parte de la instalación de componentes de producto) se establecen para que se propaguen hacia las zonas no globales. Por este motivo las zonas no globales los ven en sus registros y tienen acceso a los componentes compartidos instalados. Esta regla le permite imponer el requisito de sincronización de las versiones de componentes compartidos dentro de cualquier zona tal como se describe en Componentes compartidos de Java ES y zonas.

Instalación de componentes de producto

El instalador de Java ES puede instalar componentes de producto así como los componentes compartidos necesarios para admitir cada componente de producto. Antes de instalar un componente de producto, el instalador comprueba la existencia de versiones actuales y anteriores de los componentes compartidos. Si el instalador detecta que un componente compartido requerido por el componente seleccionado pertenece a una versión anterior o no está presente, el instalador actualizará todos los componentes compartidos instalados actualmente e instalará los componentes compartidos que falten y que sean requeridos por el componente seleccionado. Este comportamiento que cumple los requisitos de Sincronización de componentes compartidos, es aplicable a todos los sistemas operativos que no sean de zonas, a las zonas globales y a las zonas no globales.

Sin embargo, existen dos excepciones para este comportamiento:

• En zonas de poca raíz algunos componentes compartidos no se pueden instalar ni actualizar (consulte la sección Componentes compartidos y zonas de poca raíz) y la instalación se detiene hasta que se hayan instalado o actualizado en la zona global de dichos componentes compartidos. El instalador mostrará el mensaje siguiente: ?Los siguientes componentes compartidos, requeridos por los componentes seleccionados, no se pueden instalar ni actualizar en una zona de poca raíz. Instale o actualice estos componentes compartidos en la zona global antes de continuar. Utilice la opción Todos los componentes compartidos.? Para obtener más información, consulte Sincronizar todos los componentes compartidos.

• Si existen zonas no globales, en la zona global el instalador sincroniza todos los componentes compartidos de Java ES, sean o no requeridos por un componente de producto específico, en vez de actualizar todos los componentes compartidos actualmente instalados e instalando los componentes compartidos que faltan y que son requeridos por un componente seleccionado. Esto permite a todos los componentes compartidos propagarse a zonas no globales, asegurando así que no se entremezclen las versiones de componentes compartidos en las zonas no globales.

Actualización de componentes de producto

Una nueva capacidad se ha implementado en la versión 5 de Java ES para actualizar componentes en algunos casos especiales: Application Server, Message Queue, HADB y Java DB. Cuando el instalador de Java ES detecta las versiones anteriores instaladas de estos componentes de producto, los marca como actualizables en la página de selección de componentes. Si se selecciona cualquiera de estos cuatro componentes de producto, el instalador los actualizará utilizando un sistema parecido al de una instalación nueva.

Concretamente, antes de actualizar un componente de producto seleccionado, el instalador comprueba la existencia de versiones actuales y anteriores de componentes compartidos. Si el instalador detecta que un componente compartido requerido por el componente seleccionado pertenece a una versión anterior o no está presente, el instalador actualizará todos los componentes compartidos instalados actualmente e instalará los componentes compartidos que falten y que sean requeridos por el componente seleccionado. Este comportamiento, que cumple los requisitos descritos en Sincronizar todos los componentes compartidos, es aplicable a todos los sistemas operativos que no sean de zonas, a las zonas globales y a las zonas no globales.

Sin embargo, existen tres excepciones para este comportamiento:

• En zonas de poca raíz algunos componentes compartidos no se pueden instalar ni actualizar y la operación de actualización se detiene hasta que se hayan instalado o actualizado en la zona global dichos componentes compartidos. (Para obtener más información, consulte Componentes compartidos y zonas de poca raíz.) El instalador muestra el mensaje siguiente: ?Los siguientes componentes compartidos, requeridos por los componentes seleccionados, no se pueden instalar ni actualizar en una zona de poca raíz. Instale o actualice estos componentes compartidos en la zona global antes de continuar. Utilice la opción Todos los componentes compartidos.?( Para obtener más información, consulte Sincronizar todos los componentes compartidos..)

• Application Server y Message Queue vienen con el sistema operativo Solaris. Ninguna de estas versiones se puede actualizar directamente en una zona de poca raíz. Para obtener detalles sobre estos dos componentes agrupados, consulte Casos especiales de componentes de producto.

• Si existen zonas no globales en la zona global el instalador sincroniza todos los componentes compartidos de Java ES, sean o no requeridos por un componente seleccionado para la instalación, en vez de actualizar todos los componentes compartidos actualmente instalados e instala los componentes compartidos que faltan y que son requeridos por cualquier componente seleccionado. Esto permite a todos los componentes compartidos propagarse a zonas no globales, así asegurando que no se entremezclan las versiones de componentes compartidos en las zonas no globales.

---

Nota –

Existen varios casos o excepciones especiales que pueden interferir en la instalación o la actualización de componentes de producto en zonas no globales. Estos casos se describen en Casos especiales o excepciones.

---

Sincronizar todos los componentes compartidos

Se facilita una opción de sincronización de componente compartido para afrontar situaciones en las que todos los componentes compartidos deben estar sincronizados. Cuando se selecciona la opción Todos los componentes compartidos, el instalador actualiza los componentes compartidos actualmente instalados e instala los componentes compartidos que faltan, sean o no requeridos por algún componente de producto específico. Esta opción es aplicable a zonas globales y zonas de raíz completa, pero no a zonas de poca raíz.

La opción Todos los componentes compartidos es necesaria en los dos escenarios basados en zonas siguientes:

• Actualización manual de componentes de producto. La opción Todos los componentes compartidos es necesaria para realizar la instalación de componentes compartidos al actualizar componentes de producto que no pueden actualizarse con el instalador de Java ES.

• Instalaciones o actualizaciones en una zona de poca raíz Algunos componentes compartidos no se pueden instalar en zonas de poca raíz predeterminadas. (Para obtener información detallada, consulte Instalación de componentes de producto y Actualización de componentes de producto.) Por tanto, al ejecutar el instalador en zonas de poca raíz, es posible que primero deba sincronizar componentes compartidos en la zona global, dependiendo de los componentes compartidos implicados. Utilice la opción Todos los componentes compartidos en la zona global para realizar la instalación de componentes compartidos y si es necesario realizar una actualización.

Resumen del comportamiento del instalador de Java ES en relación a los componentes compartidos

Los comportamientos anteriormente descritos se resumen en la siguiente tabla, que muestra cómo el tratamiento de los componentes compartidos por parte del instalador de Java ES depende del contexto de la zona además de lo que se haya seleccionado en la página de selección de componentes.

Tabla A–1 Comportamiento del Instalador en relación a los componentes compartidos

Contexto de zonas	Componente de producto seleccionado	Todos los componentes compartidos seleccionados
Sistema operativo que no es de zonas	Actualizar todos los componentes compartidos actualmente instalados  Instalar los componentes compartidos que faltan que son requeridos por el componente de producto seleccionado	Actualizar todos los componentes compartidos actualmente instalados  Instalar los componentes compartidos que faltan, sean requeridos o no por componentes de producto específicos
Zona global: ninguna zona no global	Actualizar todos los componentes compartidos actualmente instalados  Instalar los componentes compartidos que faltan que son requeridos por el componente de producto seleccionado	Actualizar todos los componentes compartidos actualmente instalados   Instalar los componentes compartidos que faltan, sean requeridos o no por componentes de producto específicos
Zona global: existen zonas no globales	Actualizar todos los componentes compartidos actualmente instalados   Instalar los componentes compartidos que faltan, sean requeridos o no por componentes de producto específicos	Actualizar todos los componentes compartidos actualmente instalados. Instale los componentes compartidos que falten, sean requeridos o no por componentes de producto específicos
Zona de raíz completa	Actualizar todos los componentes compartidos actualmente instalados  Instalar los componentes compartidos que faltan que son requeridos por el componente de producto seleccionado	Actualizar todos los componentes compartidos actualmente instalados  Instalar los componentes compartidos que faltan, sean requeridos o no por componentes de producto específicos
Zona de poca raíz	No se pueden actualizar o instalar algunos componentes compartidos en directorios de sólo lectura. Si el instalador se encuentra con componentes compartidos de este tipo, se quedará bloqueado e indicará al usuario que gestiones los componentes compartidos en la zona global.	No se pueden actualizar o instalar algunos componentes compartidos en directorios de sólo lectura. El Instalador se bloquea e indica al usuario que gestione los componentes compartidos en la zona global.

Uso recomendado de zonas con Java ES

Mientras que la implementación de Java ES en un entorno de varias zonas tiene el objetivo general de proporcionar aislamiento de componentes de producto en tiempo de ejecución y el uso eficiente de recursos, existe una serie de objetivos más específicos para los que se puede utilizar un entorno de varias zonas. Estos objetivos se tratan en la sección ¿Por qué utilizar zonas para Java ES?. Las estrategias de instalación y administración de Java ES en un entorno de varias zonas depende en gran medida en qué objetivos quiere alcanzar.

En la Tabla A–2 se comparan cinco escenarios, las estrategias de instalación y administración correspondientes y los objetivos que se van a lograr. Aunque a veces será posible mezclar estos casos, los resultados pueden ser problemáticos y susceptibles de causar problemas administrativos. Por este motivo Java ES versión 5 normalmente no admite implementaciones que mezclen estos casos.

Además, el caso 1 y el caso 2 son problemáticos, por lo que Java ES versión 5 no los admite actualmente (aunque se pueden crear compatibilidades para componentes de producto específicos en el caso 5).

Tabla A–2 Instalación de zonas y estrategias de administración para Java ES

Caso (estrategia de instalación)	Estrategia de administración	Objetivo (consulte ¿Por qué utilizar zonas para Java ES?)	Comentarios
1: Instalar componentes de producto y componentes compartidos en la zona global con la propagación activada. Ningún componente instalado en zonas no globales.*	Gestión de los ciclos de vida de los componentes: Administrador global   Configuración y administración de tiempo de ejecución: Administradores de zona	Administración centralizada de ciclo de vida de componente de producto   Independencia organizativa para la configuración de componente de producto y administración de tiempo de ejecución	Problemático: No compatible aún para los componentes de producto de Java ES, excepto para Message Queue. Requiere que los componentes de producto admitan la instalación en una zona global pero la gestión de la configuración y del tiempo de ejecución en zonas no globales.
2: Instalar componentes compartidos en la zona global y los componentes de producto en las zonas de raíz completa	Gestión de los ciclos de vida de los componentes compartidos: Administrador global   Administración de los ciclos de vida de los componentes de producto: Administradores de zona   Configuración y administración de tiempo de ejecución: Administradores de zona	Administración centralizada de ciclo de vida de componente compartido   Independencia organizativa para la configuración de ciclo de vida de componente de producto y administración de tiempo de ejecución	Principalmente aplicable cuando todos los componentes son de la misma versión de Java ES o cuando se actualizan todos los componentes de producto en todas las zonas de raíz completa.
3: Instalar componentes compartidos en la zona global y los componentes de producto en las zonas de poca raíz**	Igual que en el caso nº 2	Administración centralizada del ciclo de vida de componente compartido.   Independencia organizativa para la configuración de ciclo de vida de componente de producto y administración de tiempo de ejecución   Aumento de la eficacia de los recursos en el caso nº 2 (consulte Zonas de raíz completa / zonas de poca raíz)	Este caso se recomienda al instalar componentes de producto en zonas de poca raíz. (Algunos componentes compartidos no se pueden instalar en zonas de poca raíz y por lo tanto se deben instalar en la zona global.)
4: Instalar componentes de producto y componentes compartidos en zonas de raíz completa	Gestión de los ciclos de vida de los componentes: Administradores de zonas Gestión de la configuración y del tiempo de ejecución: Administradores de zona	Separación de versiones	No se deben instalar componentes compartidos ni componentes de producto en la zona global. Caso recomendado para zonas de raíz completa.
5: Instalar componentes de producto y componentes compartidos en zonas de poca raíz.	Igual que en el caso nº 4	Independencia organizativa para la configuración de ciclo de vida de componente de producto y administración de tiempo de ejecución  Aumento de la eficacia de los recursos en el caso nº 4 (consulte Zonas de raíz completa / zonas de poca raíz)	Problemático. No se puede implementar de forma generalizada porque no se pueden instalar varios componentes compartidos en zonas de poca raíz.

* El caso 1 no distingue entre entornos de zona de raíz completa y entornos de zona de poca raíz; parte de que no hay ningún componente de producto instalado en zonas no globales. La instalación de componentes de producto en zonas no globales se cubre en los casos 2-5.

** En el caso 3 se parte de que /opt no se ha establecido como directorio de sólo lectura en la zona de poca raíz. Si /opt fuera de sólo lectura, la mayoría de componentes de Java ES no se podrían instalar en zonas de poca raíz y se tendrían que instalar en la zona global, como en el caso 1, como procedimiento alternativo.

Metodologías recomendables

Teniendo en cuenta la Tabla A–2, a continuación le mostramos una serie de metodologías recomendables:

• Planifique su estrategia de implementación de zonas Java ES con antelación según el objetivo de la sección ¿Por qué utilizar zonas para Java ES?que esté intentando cumplir. Diferentes objetivos requieren estrategias de instalación y gestión diferentes, tal como se muestra en los casos diferentes de la Tabla A–2.

• Evite mezclar casos. Especialmente:

  • Mantenga su estrategia de implementación y administración de zonas Java ES lo más sencilla posible. No mezcle implementaciones de raíz completa y de poca raíz de los componentes de Java ES en un mismo equipo. (Los procedimientos y métodos necesarios para poder llevar a cabo implementaciones de zona de poca raíz, tal como el caso 3, interfieren con las implementaciones de zona de raíz completa, tal como el caso 4).

  • No instale el mismo componente de producto Java ES en la zona global y en zonas no globales, aun en el caso que se trate de versiones diferentes. (Los procedimientos necesarios para actualizar una instalación de zona global, como en el caso 1, puede estropear las instalaciones de zonas no globales, tales como las del caso 4.)

  • Cuando los componentes Java ES versión 4 (o anterior) se han instalado en una zona de raíz completa, no instale los componentes de la versión 5 de Java ES (ni los componentes de producto ni los compartidos) en la zona global, ni actualice los componentes Java ES con la versión 5 en la zona global. En otras palabras, el Caso 2 no se admite cuando existen instalaciones preexistentes de Java ES en una zona de raíz completa. (La instalación o actualización en la zona global puede tener como resultado una mezcla de archivos de las versiones 4 y 5 en las zonas de raíz completa.)

• Prácticas de instalación recomendadas:

  • Si quiere ejecutar diferentes componentes de producto de Java ES en diferentes zonas, instale los componentes de producto en zonas no globales (casos 2, 3, 4, 5).

  • Si quiere ejecutar diferentes componentes de producto Java ES en diferentes zonas pero gestionar de forma centralizada los ciclos de vida de los componentes compartidos, entonces sincronice los componentes compartidos en la zona global y a continuación instale los componentes de producto en las zonas no globales (casos 2 y 3). (Esto es un método recomendado cuando se instalan componentes de producto en zonas de poca raíz.)

  • Si quiere obtener una separación de versiones de componentes de producto de Java ES o por otro motivo aislar las implementaciones de los componentes de producto de Java ES (caso 4), entonces instale y configure todos los componentes Java ES en las zonas de raíz completa. No instale ningún componente Java ES en la zona global.

• Prácticas de actualización recomendadas:

  • Si quiere actualizar todos los componentes de producto de la versión 4 a la versión 5, sincronice todos los componentes compartidos Java ES en la zona global, y a continuación lleve a cabo la actualización de los componentes de producto en las zonas donde han sido instalados. (Los componentes compartidos de la versión 5 son compatibles con versiones anteriores.)

  • Si tiene componentes de producto de la versión 4 ó 5 instalados en un entorno que no es de zonas y desea añadir zonas no globales al entorno e instalar componentes de producto en las nuevas zonas no globales, asegúrese de que lo hace según la metodología recomendada anteriormente. Esto puede significar desinstalar componentes de la zona global y reinstalarlos en zonas no globales.

Arquitecturas de implementación

Las descripciones de los casos de la Tabla A–2 y las metodologías recomendadas mencionadas anteriormente no incluyen arquitecturas de implementación de Java ES recomendadas para un entorno de varias zonas. Este tipo de arquitecturas son una adaptación de las arquitecturas creadas para entornos de red de varios equipos. En otras palabras, la disponibilidad de entornos de varias zonas no cambia los enfoques de diseño de implementaciones básicas para alcanzar un alto nivel de rendimiento, alta disponibilidad, escalabilidad, seguridad y servicios para sistemas de implementación Java ES. Lo que un entorno de varias zonas le permite hacer es consolidar este tipo de arquitecturas de implementación en un número menor de equipos.

Los detalles sobre cómo adaptar una arquitectura de implementación de Java ES a un entorno de varias zonas, sin embargo, dependen en gran medida en las estrategias que desea, tal como se describe en las secciones anteriores. Las arquitecturas de implementación también dependen en su estrategia de obtener un alto nivel de disponibilidad.

Tenga en cuenta que la Tabla A–2 y las metodologías recomendadas anteriormente no incluyen las metodologías recomendadas para implementar los casos descritos. En algunos casos el orden en que se instalan los componentes Java ES y el orden en que se crean las zonas no locales pueden ser importantes.

Casos especiales o excepciones

Existen varios casos especiales que nacen del hecho que algunos componentes compartidos de Java ES y algunos componentes de producto de Java ES vienen con Solaris 10. Debido a este hecho, estos componentes Java ES existen en la zona global y por lo tanto en cualquier zona no global que se haya creado a partir de la zona global.

Casos especiales de componentes de producto

• Message Queue viene con Solaris 10 y, como resultado, se propaga automáticamente cuando se crean zonas no globales (excepto si primero ha eliminado Message Queue de la zona global). Message Queue no se puede instalar en una zona de poca raíz. Message Queue, cuando se instala o actualiza en una zona global por parte del instalador de Java ES, por defecto se propaga a las zonas no globales, a diferencia de otros componentes de producto.

• Application Server viene con Solaris 10 y, como consecuencia de esto, se propaga automáticamente cuando se crean zonas no globales (excepto si primero ha eliminado Application Server de la zona global). Cuando se propaga de esta manera, Application Server, que está instalado en /usr , no puede ser actualizado por el instalador de Java ES en una zona de poca raíz (de manera predeterminada /usr es de sólo lectura). Para solucionar este problema, Application Server debe eliminarse manualmente de la zona global antes de instalar la versión 5 de Application Server en una zona de poca raíz.

• Sun Cluster sólo se puede instalar en una zona global. Sun Cluster no es compatible con las zonas no globales.

Casos especiales de componentes compartidos

• Los paquetes SJWC que vienen con Solaris 10 (actualizaciones 1 y 2) no se pueden eliminar del instalador de Java ES. Estos paquetes SJWC más antiguos tienen el parámetro SUNW_PKG_ALLZONES establecido como Verdadero, lo que significa que el paquete tiene que ser idéntico en todas las zonas y sólo puede ser administrado por el administrador global. Como resultado estos paquetes deben eliminarse de forma manual de la zona global para ser reemplazados por los paquetes correctos.

  Si el instalador de Java ES está intentando instalar un componente seleccionado en una zona no global y detecta que SJWC necesita actualizarse, el instalador se bloqueará. Esto tiene lugar al instalar en Solaris 10, actualización 1 y 2.

  Como solución temporal, se ha desarrollado una secuencia de comandos especial que eliminará los paquetes antiguos de SJWC de la zona global y reemplazarlos con SJWC 2.6.6, que tiene el parámetro de atributo de propagación de zonas correcto. Como resultado, SJWC 2 2.6 se propaga a todas las zonas no globales.

• Contenedor de agente común. La versión 1.1 se instala sólo si están instalados Sun Cluster, Sun Cluster GE o Sun Cluster Agents están instalados. No se instalará si la opción Sincronizar todos los componentes compartidos está seleccionada. En este caso sólo estará instalada la versión 2.0.

• Sun Explorer Data Collector. Este componente compartido se instala sólo si están instalados Sun Cluster, Sun Cluster GE o Sun Cluster Agents están instalados. No se instalará si la opción Todos los componentes compartidos está seleccionada.

Un ejemplo ilustrativo: Instalación de Application Server en una zona de poca raíz.

Proporcionamos el ejemplo siguiente para eliminar algunas de las dificultades relacionadas con la compatibilidad de zonas de Java ES. En este ejemplo el objetivo es instalar Application Server en una zona de poca raíz de Solaris 10. Esta instalación es complicada por el hecho de que Application Server (así como Message Queue, del que depende Application Server), se incluye con Solaris 10 y, por tanto, la versión que viene se instala en todas las zonas no globales. Para obtener más información, consulte Casos especiales de componentes de producto.

Para instalar Application Server en una zona de poca raíz, primero debe eliminar la versión incluida. (No puede simplemente actualizar la versión que viene con el sistema operativo en la zona de poca raíz, porque está instalada en un directorio de sólo lectura). Para ello, elimínela de la zona global.

Además, Message Queue está instalado en la zona global, lo que representa una diferencia respecto al caso 3 de la Tabla A–2, en el que sólo los componentes compartidos (ningún componente de producto) se van a instalar en la zona global. Sin embargo, Message Queue no se puede instalar en una zona de poca raíz, debido a que se instala en un directorio de sólo lectura, de manera que debe instalarse y actualizarse en la zona global.

El procedimiento es el siguiente:

1. Verifique que Solaris 10 se está ejecutando en el sistema.

   Este ejemplo parte de que se ha instalado explícitamente en la zona global una versión nueva de Solaris 10 sin componentes Java ES.

2. Cree una zona de poca raíz (configure, instale e inicie).

   Esta zona incluirá los componentes Java ES que ya se encuentran instalados en la zona global, concretamente las versiones de Message Queue y Application Server que vienen con Solaris 10.

3. Elimine la versión que viene con el sistema operativo de Application Server de la zona global.

   Esto se debe realizar mediante la eliminación manual de los paquetes de Application Server:

   pkgrm SUNWascmnse SUNWaslb SUNWasut ...

   Donde puede obtener el conjunto de paquetes completo con el comando siguiente:

   pkginfo -I|grep -I application server

   Los resultados incluirán paquetes como:

   SUNWascmnse, SUNWaslb, SUNWasut, SUNWasac, SUNWasdem, SUNWasman, SUNWaswbcr, SUNWasacee, SUNWashdm, SUNWasmanee, SUNWascml, SUNWasJdbcDrivers, SUNWasu, SUNWascmn, SUNWasjdoc, SUNWasuee

   Y puede incluir también paquetes de localización:

   SUNWLocaleasacee, SUNWLocaleascmnse, SUNWLocaleasu, SUNWLocaleasuee

   La eliminación de Application Server de la zona global se propaga a la zona de poca raíz creada en el paso 2. (Este paso y el paso 2 se pueden realizar de forma inversa..)

4. Instale los componentes compartidos de Java ES en la zona global.

   1. Ejecute el instalador de Java ES en la zona global.

   2. Seleccione Todos los componentes compartidos del panel de selección de componentes. No seleccione ningún componente adicional.

   3. Complete la sincronización de los componentes compartidos. Todos los componentes compartidos ahora estarán sincronizados en la zona global y se propagarán a todas las zonas no globales.

5. Actualice Message Queue en la zona global.

   La versión de Message Queue que viene con Solaris 10 ya está instalada en la zona de poca raíz gracias al paso 2. Para actualizar Message Queue en la zona de poca raíz, simplemente actualícelo en la zona global; la actualización se propagará a la zona de poca raíz. (Message Queue es el único componente de producto que no se puede instalar en una zona de poca raíz, pero que cuando se instala en la zona global se propaga a las zonas no globales..)

   1. Ejecute el instalador de Java ES en la zona global.

   2. Seleccione Message Queue en el panel de selección de componentes. No seleccione ningún componente adicional.

   3. Complete la actualización de Message Queue.

6. Instale Application Server en la zona de poca raíz.

   1. Ejecute el instalador de Java ES en la zona de poca raíz.

   2. Seleccione Application Server en el panel de selección de componentes. No seleccione ningún componente adicional para la actualización. Anule la selección de Message Queue si está seleccionado.

   3. Complete la instalación de Application Server.