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.