Planificación del entorno de Oracle Solaris Cluster

En esta sección se proporcionan directrices de planificación y preparación para la instalación y la configuración de los siguientes componentes del software Oracle Solaris Cluster.

• Versión del software Oracle Solaris Cluster

• Requisitos de memoria

• Licencias

• Actualizaciones de software

• Geographic Edition

• Direcciones IP de red pública

• Dispositivos de acceso a la consola

• Configuración de red pública

• Configuración del servidor de quórum

• Directrices de NFS

• Restricciones de servicio

• Protocolo de tiempo de red (NTP)

• Componentes configurables de Oracle Solaris Cluster

• SPARC: directrices para dominios lógicos de Oracle VM Server para SPARC como nodos de cluster

• Clusters de zona

Para obtener información detallada sobre los componentes de Oracle Solaris Cluster, consulte la Oracle Solaris Cluster 4.3 Concepts Guide.

Versión del software Oracle Solaris Cluster

Todos los nodos de un cluster deben ejecutar la misma versión del software Oracle Solaris Cluster.

Requisitos de memoria

El software Oracle Solaris Cluster 4.3 requiere los siguientes requisitos de memoria para cada nodo del cluster:

• Como mínimo 1,5 GB de RAM física (lo normal son 2 GB)

• Como mínimo 6 GB de espacio disponible en el disco duro

Los requisitos reales de disco duro y memoria física reales dependen de las aplicaciones que se instalen. Consulte la documentación de la aplicación o póngase en contacto con el proveedor de la aplicación para calcular los requisitos de disco duro y memoria adicionales que pudiera necesitar.

Licencias

Asegúrese de que dispone de todos los certificados de licencia necesarios antes de iniciar la instalación del software. El software de Oracle Solaris Cluster no requiere un certificado de licencia, pero cada nodo instalado con él debe estar cubierto por el acuerdo de licencia de software Oracle Solaris Cluster.

Para conocer los requisitos de licencia del software del administrador de volúmenes y de las aplicaciones, consulte la documentación de instalación de estos productos.

Actualizaciones de software

Después de instalar cada producto de software, también debe instalar todas las actualizaciones de software requeridas. Para garantizar el correcto funcionamiento del cluster, asegúrese de que todos los nodos del cluster mantengan el mismo nivel de actualización.

Para conocer las directrices y los procedimientos generales de actualización de softwares, consulte el Capítulo 11, Actualización de software de Guía de administración del sistema de Oracle Solaris Cluster 4.3.

Geographic Edition

Si se configurará un cluster de zona en una configuración de Oracle Solaris Cluster Geographic Edition (Geographic Edition), el cluster de zona debe cumplir con los requisitos siguientes:

• Cada nodo del cluster de zona debe tener una dirección IP de red pública que corresponda al nombre de host del nodo del cluster de zona.

• Todos los nodos del cluster de socio de la configuración de Geographic Edition deben poder acceder a la dirección IP de red pública del nodo del cluster de zona.

• Cada nodo del cluster de zona debe tener una dirección IP de failover que se asigna al nombre de host correspondiente al nombre del cluster de zona.

Si va a utilizar la interfaz de explorador de Oracle Solaris Cluster Manager para administrar los componentes de Geographic Edition, todos los nodos del cluster deben tener la misma contraseña de usuario root. Para obtener más información sobre Oracle Solaris Cluster Manager, consulte el Capítulo 13, Uso de la interfaz de explorador de Oracle Solaris Cluster Manager de Guía de administración del sistema de Oracle Solaris Cluster 4.3.

Direcciones IP de red pública

Para obtener información sobre las de redes públicas que usa el cluster, consulte Public Network Adapters de Oracle Solaris Cluster 4.3 Concepts Guide.

Debe definir un número de direcciones IP de red pública para varios componentes de Oracle Solaris Cluster. El número de direcciones necesarias dependerá de los componentes que incluya en la configuración del cluster. Cada host de Oracle Solaris de la configuración del cluster debe tener, al menos, una conexión de red pública con el mismo conjunto de subredes públicas.

En la siguiente tabla, se enumeran los componentes que necesitan recibir la asignación de direcciones IP de red pública. Agregue estas direcciones IP a las siguientes ubicaciones:

• Cualquier servicio de nombres utilizado.

• El archivo local /etc/inet/hosts en cada nodo del cluster global después de instalar el software de Oracle Solaris.

• El archivo /etc/inet/hosts local en cualquier zona no global con una IP exclusiva.

Tabla 2  Componentes de Oracle Solaris Cluster que utilizan direcciones IP de red pública

Componente Número de direcciones IP necesarias Consola de administración 1 dirección IP por subred Nodos del cluster global 1 dirección IP por nodo y por subred Nodos del cluster de zona 1 dirección IP por nodo y por subred Interfaz de red de consola de dominio 1 dirección IP por dominio (Opcional) Zonas no globales 1 dirección IP por subred Dispositivo de acceso a la consola 1 dirección IP Direcciones lógicas 1 dirección IP por recurso de host lógico y por subred

Para obtener más información sobre la planificación, consulte Planificación de la implementación de red en Oracle Solaris 11.3.

Dispositivos de acceso a la consola

Debe disponer de acceso a la consola en todos los nodos del cluster. Se usa un procesador de servicios (SP, Service Processor) para establecer la comunicación entre la consola de administración y las consolas de los nodos del cluster global.

Para obtener más información sobre el acceso a la consola, consulte la Oracle Solaris Cluster 4.3 Concepts Guide.

Puede usar la utilidad pconsole de Oracle Solaris para conectarse con los nodos del cluster. Además, la utilidad proporciona una ventana de consola maestra desde la cuál puede propagar la entrada a todas las conexiones que haya abierto. Para obtener más información, consulte la página del comando man pconsole(1), que se encuentra disponible cuando instala el paquete terminal/pconsole de Oracle Solaris.

Configuración de red pública

Las redes públicas se comunican fuera del cluster. Tenga en cuenta los siguientes aspectos cuando planifique la configuración de red pública:

• Separación de red pública y red privada: las redes públicas y la red privada (interconexión del cluster) deben utilizar adaptadores independientes, o se deben configurar VLAN etiquetadas en adaptadores compatibles con VLAN etiquetadas y conmutadores compatibles con VLAN para que utilicen el mismo adaptador con la interconexión privada y con la red pública.

  De manera alternativa, cree NIC virtuales en la misma interfaz física y asigne diferentes NIC virtuales a las redes públicas y privadas.

• Mínimo: todos los nodos del cluster deben conectarse, al menos, a una red pública. Las conexiones de red pública pueden utilizar diferentes subredes para los distintos nodos.

• Máximo: puede tener todas las conexiones de red pública adicionales que permita su configuración de hardware.

• Servicios escalables: todos los nodos que ejecuten un servicio escalable deben utilizar la misma subred o conjunto de subredes, o utilizar diferentes subredes que puedan enrutarse entre sí.

• Direcciones lógicas: cada grupo de recursos de servicios de datos que usa una dirección lógica debe tener un nombre de host especificado para cada red pública desde la que se puede acceder a la dirección lógica. Para obtener más información sobre los recursos y los servicios de datos, también consulte la Oracle Solaris Cluster 4.3 Concepts Guide.

• IPv4: el software Oracle Solaris Cluster admite direcciones IPv4 en la red pública.

• IPv6: consulte Guía de compatibilidad de Oracle Solaris Cluster 4 para obtener una lista de servicios de datos que admitan direcciones IPv6 en la red pública.

• Gestión de red pública: cada adaptador de red pública que se utilice para el tráfico de servicio de datos debe pertenecer a un objeto PNM que incluya grupos IPMP, agregaciones de enlace y VNIC que estén directamente respaldados por agregaciones de enlace. Si no se utiliza un adaptador de red pública para el tráfico de servicios de datos, no es necesario que lo configure en un objeto PNM.

  A menos que existan una o más interfaces de red pública IPv6 que no sean de enlace local en la configuración de red pública, la utilidad scinstall configura automáticamente un grupo de IPMP de varios adaptadores para cada conjunto de adaptadores del cluster que utilice la misma subred. Estos grupos se basan en enlaces con sondeos transitivos.

  ---

  Notas -  Los grupos IPMP se crean solo en adaptadores físicos no utilizados.

  ---

  En los grupos IPMP puede configurar manualmente todas las interfaces que se usarán para el tráfico de servicio de datos. Puede configurar los grupos IPMP antes o después de que se establezca el cluster.

  La utilidad scinstall omite los adaptadores que ya se han configurado en un grupo IPMP. Puede utilizar grupos IPMP basados en sondeos o vínculos en un cluster. Los grupos IPMP basados en sondeos, que prueban la dirección IP de destino, proporcionan la mayor protección mediante el reconocimiento de más condiciones que pueden poner en peligro la disponibilidad.

  Si un adaptador de un grupo IPMP que la utilidad scinstall configura no va a utilizarse para el tráfico de servicios de datos, puede eliminar dicho adaptador del grupo.

  Para obtener directrices sobre grupos IPMP, consulte el Capítulo 2, Acerca de la administración de IPMP de Administración de redes TCP/IP, IPMP y túneles IP en Oracle Solaris 11.3. Para modificar los grupos IPMP después de la instalación del cluster, siga las directrices que aparecen en Administración de grupos de varias rutas de red IP en un cluster de Guía de administración del sistema de Oracle Solaris Cluster 4.3 y los procedimientos que aparecen en el Capítulo 3, Administración de IPMP de Administración de redes TCP/IP, IPMP y túneles IP en Oracle Solaris 11.3. Para obtener más información sobre las agregaciones de enlaces, consulte el Capítulo 2, Configuración de alta disponibilidad mediante agregaciones de enlaces de Gestión de enlaces de datos de red de Oracle Solaris 11.3.

• Compatibilidad con direcciones MAC locales: todos los adaptadores de red pública deben utilizar tarjetas de interfaz de red (NIC) que sean compatibles con la asignación de direcciones MAC locales. La asignación de direcciones MAC locales supone un requisito de IPMP.

• Configuración de local-mac-address: la variable local-mac-address? debe utilizar el valor por defecto true para los adaptadores Ethernet. El software Oracle Solaris Cluster no admite el valor local-mac-address? de false para los adaptadores Ethernet.

Para obtener más información sobre las interfaces de red pública, consulte la Oracle Solaris Cluster 4.3 Concepts Guide.

Configuración del servidor de quórum

Puede utilizar el software de Oracle Solaris Cluster Quorum Server para configurar un equipo como servidor de quórum y, a continuación, configurar éste como dispositivo del quórum del cluster. Puede utilizar un servidor de quórum además de los discos compartidos y los archivos NAS, o en lugar de ellos.

Tenga en cuenta los siguientes aspectos al planificar el uso del servidor de quórum en una configuración de Oracle Solaris Cluster.

• Conexión de red: el equipo del servidor de quórum debe conectarse al cluster mediante la red pública en la misma subred utilizada por los nodos del cluster a los cuales presta servicios. De lo contrario, es posible que el servidor de quórum no esté disponible para el cluster durante el reinicio de un nodo y evite que el cluster se forme.

• Hardware admitido: las plataformas de hardware compatibles con un servidor de quórum son las mismas que las de un nodo del cluster global.

• Sistema operativo: los requisitos del software de Oracle Solaris para el software de Oracle Solaris Cluster se aplican también al software de Quorum Server.

• Restricción para zonas no globales: en la versión Oracle Solaris Cluster 4.3, no se puede instalar ni configurar un servidor de quórum en una zona no global.

• Servicio para varios clusters: puede configurar un servidor de quórum como dispositivo del quórum para más de un cluster.

• Combinación de hardware y software: no es necesario que configure un servidor de quórum en la misma plataforma de hardware y software que los clusters para los que se proporciona el quórum. Por ejemplo, un equipo basado en SPARC que se ejecute en el SO Oracle Solaris 10 se puede configurar como servidor de quórum para un cluster basado en x86 que se ejecute en el SO Oracle Solaris 11.

• Algoritmo de árbol de expansión: debe desactivar el algoritmo de árbol de expansión en los conmutadores Ethernet para los puertos conectados a la red pública del cluster en la que se ejecutará el servidor de quórum.

• Uso de un nodo del cluster como servidor de quórum: puede configurar un servidor de quórum en un nodo del cluster para proporcionar quórum a otros clusters distintos al cluster al que pertenece el nodo. Sin embargo, un servidor de quórum configurado en un nodo del cluster no proporcionará alta disponibilidad.

Directrices de NFS

Tenga en cuenta los siguientes aspectos al planificar el uso del sistema de archivos de red (NFS, Network File System) en una configuración de Oracle Solaris Cluster:

• Cliente NFS: ningún nodo de Oracle Solaris Cluster puede ser un cliente NFS de un sistema de archivos exportado de HA para NFS que se esté supervisando en un nodo del mismo cluster. Esta clase de montaje cruzado de HA para NFS no está permitida. Utilice el sistema de archivos del cluster para compartir los archivos entre los nodos del cluster.

• Protocolo NFSv3: si está montando sistemas de archivos en los nodos del cluster desde servidores NFS externos, como archivos NAS, y está utilizando el protocolo NFSv3, no podrá ejecutar montajes de cliente NFS y los servicios de datos de HA para NFS en el mismo nodo del cluster. Si lo hace, determinadas actividades del servicio de datos de HA para NFS pueden provocar que los daemons NFS se detengan y se reinicien, con lo cual se interrumpirían los servicios NFS. Sin embargo, puede ejecutar de forma segura el servicio de datos de HA para NFS si utiliza el protocolo NFSv4 para montar sistemas de archivos NFS externos en los nodos del cluster.

• Bloqueo: las aplicaciones que se ejecuten de forma local en el cluster no deben bloquear los archivos en un sistema de archivos exportado mediante NFS. De lo contrario, el bloqueo local (por ejemplo, flock o fcntl) puede interferir en la capacidad para reiniciar el gestor de bloqueos (lockd). Durante el reinicio, se puede conceder a un proceso local bloqueado un bloqueo destinado a que un cliente remoto lo solicite. Esta situación podría provocar un comportamiento inesperado.

• Funciones de seguridad de NFS: el software Oracle Solaris Cluster no admite las siguientes opciones del comando share_nfs(1M):

  • secure

  • sec=dh

  Sin embargo, el software de Oracle Solaris Cluster admite las siguientes funciones de seguridad para NFS:

  • El uso de puertos seguros para NFS. Para activar los puertos seguros de NFS, agregue el conjunto de entradas nfssrv:nfs_portmon=1 al archivo /etc/system en los nodos de cluster.

  • El uso de Kerberos con NFS.

• Aislamiento: los clusters de zona admiten el aislamiento de todos los discos compartidos, matrices de almacenamiento y dispositivos NAS admitidos.

Restricciones de servicio

Tenga en cuenta las siguientes restricciones de servicio de las configuraciones de Oracle Solaris Cluster:

• Enrutadores: no configure los nodos de cluster como enrutadores (puertas de enlace) por los siguientes motivos:

  • Es posible que los protocolos de enrutamiento difundan la interconexión del cluster como una red de acceso público a otros enrutadores a pesar de la configuración de IFF_PRIVATE en las interfaces de interconexión.

  • Los protocolos de enrutamiento pueden interferir en el failover de las direcciones IP en los nodos del cluster, lo que podría afectar a la accesibilidad del cliente.

  • Los protocolos de enrutamiento pueden poner en peligro el correcto funcionamiento de los servicios escalables al aceptar paquetes de red de cliente y soltarlos en lugar de reenviarlos a otros nodos del cluster.

• Servidores NIS+: no configure los nodos del cluster como servidores NIS o NIS+. No hay ningún servicio de datos disponible para NIS o NIS+. Sin embargo, los nodos del cluster pueden ser clientes NIS o NIS+.

• Servidores de instalación: no utilice una configuración de Oracle Solaris Cluster para proporcionar un servicio de instalación de alta disponibilidad en los sistemas cliente.

• RARP: no utilice una configuración de Oracle Solaris Cluster para proporcionar un servicio rarpd.

• Números de programa de llamadas de procedimiento remoto (RPC): si instala un servicio RPC en el cluster, dicho servicio no debe utilizar ninguno de los siguientes números de programa:

  • 100141

  • 100142

  • 100248

  Estos números se reservan para los daemons rgmd_receptionist, fed y pmfd de Oracle Solaris Cluster, respectivamente.

  Si el servicio RPC que instale utiliza también uno de estos números de programas, deberá cambiarlo para que utilice un número de programa diferente.

• Clases de programación: el software Oracle Solaris Cluster no admite la ejecución de clases de programación de procesos de alta prioridad en los nodos del cluster. No ejecute ninguno de los siguientes tipos de procesos en los nodos del cluster:

  • Los procesos que se ejecutan en la clase de programación de tiempo compartido con alta prioridad

  • Los procesos que se ejecutan en la clase de programación en tiempo real

  El software Oracle Solaris Cluster utiliza los subprocesos del núcleo que no se ejecutan en la clase de programación en tiempo real. Otros procesos de tiempo compartido que se ejecutan con una prioridad superior a la normal o los procesos en tiempo real pueden evitar que los subprocesos del núcleo de Oracle Solaris Cluster adquieran los ciclos de CPU necesarios.

Protocolo de tiempo de red (NTP)

Tenga en cuenta las directrices siguientes de NTP:

• Sincronización: al configurar NTP o cualquier utilidad de sincronización de tiempo en el cluster, el primer requisito consiste en que todos los nodos del cluster deben sincronizarse al mismo tiempo.

• Precisión: la precisión del tiempo en los nodos es el segundo aspecto importante que debe tener en cuenta durante la sincronización del tiempo en los nodos. Puede configurar NTP como mejor desee siempre que se cumpla este requisito básico de sincronización.

Consulte la Oracle Solaris Cluster 4.3 Concepts Guide para obtener más información sobre la hora del cluster. Para obtener más información sobre NTP, consulte la página del comando man ntpd(1M) que se incluye en el paquete service/network/ntp de Oracle Solaris.

Componentes configurables de Oracle Solaris Cluster

En esta sección se proporcionan directrices para los siguientes componentes de Oracle Solaris Cluster que se van a configurar:

• Nombre del cluster global

• Nombres de nodos de cluster global e identificadores de nodos

• Configuración de red privada

• Nombres de host privados

• Interconexión de cluster

• Aislamiento global

• Dispositivos de quórum

Nombre del cluster global

Especifique un nombre para el cluster global durante la configuración de Oracle Solaris Cluster. El nombre del cluster global debe ser exclusivo en toda la empresa.

Para obtener información sobre cómo asignar un nombre a un cluster de zona, consulte la sección Clusters de zona.

Nombres de nodos de cluster global e identificadores de nodos

El nombre de un nodo de cluster global es el mismo que se asigna al host físico o virtual durante su instalación con el SO Oracle Solaris. Consulte la página del comando man hosts(4) para obtener información sobre los requisitos de denominación.

En las instalaciones de clusters con un único nodo, se utiliza por defecto el nombre del nodo.

Durante la configuración de Oracle Solaris Cluster, debe especificar los nombres de todos los nodos que va a instalar en el cluster global. El nombre del nodo debe ser igual a la salida del comando uname -n.

Se asigna un ID de nodo a cada nodo de cluster para el uso intracluster, empezando por el número 1. Se asignan números de ID de nodo a cada nodo de cluster en el orden en que el nodo se convierte en un miembro del cluster. Si todos los nodos de cluster se configuran en una sola operación, el nodo desde el que se ejecuta la utilidad scinstall es el último al que se asigna un número de ID de nodo. Un número de ID de nodo no se puede cambiar después de haberse asignado a un nodo de cluster.

Un nodo convertido en miembro del cluster recibe el número de ID de nodo más bajo posible. Si un nodo se elimina del cluster, su ID de nodo queda disponible asignarlo a un nodo nuevo. Por ejemplo, si se elimina un cluster de cuatro nodos al que se asigna el ID de nodo 3 y se agrega un nodo nuevo, a ese nodo nuevo se le asigna el ID de nodo 3, no el ID de nodo 5.

Si desea que los números de ID de nodo se correspondan con determinados nodos de cluster, configure los nodos de cluster uno a uno en el orden en que quiere asignar los números de ID de nodo. Por ejemplo, para que el software del cluster asigne el ID de nodo 1 a phys-schost-1, configure dicho nodo como nodo patrocinador del cluster. Si después agrega phys-schost-2 al cluster establecido por phys-schost-1, se asigna el ID de nodo 2 a phys-schost-2.

Para obtener información sobre los nombres de nodos de un cluster de zona, consulte la sección Clusters de zona.

Configuración de red privada

El software Oracle Solaris Cluster utiliza la red privada para la comunicación interna entre los nodos y entre las zonas no globales administradas por Oracle Solaris Cluster. Una configuración de Oracle Solaris Cluster necesita, al menos, dos conexiones con la interconexión del cluster en la red privada. Al configurar el software Oracle Solaris Cluster en el primer nodo del cluster, debe especificar la dirección de red privada y la máscara de red de una de las siguientes formas:

• Acepte la dirección de red privada (172.16.0.0) y la máscara de red (255.255.240.0) por defecto. Este rango de direcciones IP admite un máximo combinado de 64 nodos y zonas no globales, un máximo de 12 clusters de zona y un máximo de 10 redes privadas.

  ---

  Notas -  El número máximo de nodos que puede admitir un rango de direcciones IP no refleja el número máximo de nodos que puede admitir actualmente la configuración de hardware o software.

  ---

• Especifique una dirección de red privada válida diferente y acepte la máscara de red por defecto.

• Acepte la dirección de red privada por defecto y especifique una máscara de red diferente.

• Especifique una dirección de red privada y una máscara de red diferentes.

Si decide especificar una máscara de red diferente, la utilidad scinstall le solicitará el número de nodos y de redes privadas que desea que admita el intervalo de direcciones IP. La utilidad también solicita que se especifique el número de clusters de zona que desea permitir. El número de nodos del cluster global que especifique debe incluir también el número previsto de zonas globales no agrupadas en un cluster que utilizará la red privada.

La utilidad calcula la máscara de red para el intervalo mínimo de direcciones IP que admitirá el número de nodos, clusters de zona y redes privadas que se haya especificado. La máscara de red calculada podría admitir un mayor número de nodos de los que se han especificado, incluidas las zonas no globales, los clusters de zona y las redes privadas. La utilidad scinstall calcula también una segunda máscara de red que supondría la mínima para admitir el doble del número de nodos, clusters de zona y redes privadas. Esta segunda máscara de red permitiría que el cluster pudiera dar cabida a un futuro crecimiento sin necesidad de volver a configurar el intervalo de direcciones IP.

A continuación, la utilidad le pide que seleccione la máscara de red. Puede especificar una de las máscaras de red calculadas o proporcionar una diferente. La máscara de red que especifique debe admitir como mínimo el número de nodos y redes privadas que ha indicado en la utilidad.

Si especifica una dirección de red privada diferente a la por defecto, esta debe cumplir los siguientes requisitos:

• Tamaño de la dirección y la máscara de red: la dirección de red privada debe ser inferior a la máscara de red. Por ejemplo, puede utilizar la dirección de red privada 172.16.10.0 con la máscara de red 255.255.255.0. Sin embargo, no puede utilizar la dirección de red privada 172.16.10.0 con la máscara de red 255.255.0.0.

• Direcciones: la dirección debe estar incluida en el bloque de direcciones que RFC 1918 reserva para su uso en redes privadas. Puede ponerse en contacto con InterNIC para obtener copias de RFC o ver RFC en línea en http://www.rfcs.org.

• Uso en varios clusters: puede utilizar la misma dirección de red privada en más de un cluster, siempre que los clusters se encuentren en redes privadas diferentes. No se puede acceder a las direcciones IP de red privada fuera del cluster.

• Oracle VM Server para SPARC: cuando se crean los dominios invitados en una misma máquina física y se conectan al mismo conmutador virtual, los dominios comparten la red privada, que está visible para todos estos dominios. Tenga cuidado al especificar un intervalo de direcciones IP de red privada en la utilidad scinstall para su uso por parte de los dominios invitados. Asegúrese de que el intervalo de direcciones no esté siendo utilizado por otro dominio que resida en el mismo equipo físico y que comparta el conmutador virtual.

• VLAN compartidas por varios clusters: las configuraciones de Oracle Solaris Cluster permiten compartir la misma VLAN de interconexión privada entre varios clusters. No es necesario configurar una VLAN independiente para cada cluster. Sin embargo, para el nivel más elevado de aislamiento de errores y resiliencia de interconexión, limite el uso de una VLAN a un solo cluster.

• IPv6: el software Oracle Solaris Cluster no admite las direcciones IPv6 para la interconexión privada. A pesar de ello, el sistema sí configura direcciones IPv6 en los adaptadores de red privada para que se admitan servicios escalables que usen direcciones IPv6. Sin embargo, no se utilizan estas direcciones IPv6 en la comunicación entre los nodos en la red privada.

Consulte Planificación de la implementación de red en Oracle Solaris 11.3 para obtener más información sobre las redes privadas.

Nombres de host privados

El nombre de host privado es aquel que se utiliza para la comunicación entre los nodos a través de una interfaz de red privada. Los nombres de host privados se crean automáticamente durante la configuración de un cluster global o de zona en Oracle Solaris Cluster. Estos nombres de host privados siguen la siguiente nomenclatura: clusternodenode-id-priv, donde node-id es el valor numérico del ID de nodo interno. Durante la configuración de Oracle Solaris Cluster, el número de ID de nodo se asigna automáticamente a cada nodo cuando éste se convierte en miembro del cluster. Un nodo de cluster global y un nodo de un cluster de zona pueden tener el mismo nombre de host privado, pero cada nombre de host se resuelve en una dirección IP de red privada diferente.

Una vez configurado el cluster global, puede cambiar los nombres de host privados mediante la utilidad clsetup(1CL). Actualmente no se puede cambiar el nombre de host de un nodo de cluster de zona.

La creación de un nombre de host privado para una zona no global es opcional. No hay ninguna convención de nomenclatura para el nombre de host privado de una zona no global.

Interconexión de cluster

Las interconexiones del cluster proporcionan rutas de hardware para la comunicación de redes privadas entre los nodos del cluster. Cada interconexión consta de un cable que se conecta de uno de los siguientes modos:

• Entre dos adaptadores de transporte

• Entre un adaptador y un conmutador de transporte

Para obtener más información sobre el objetivo y la función de la interconexión del cluster, consulte Cluster Interconnect de Oracle Solaris Cluster 4.3 Concepts Guide.

Durante la configuración de Oracle Solaris Cluster, debe especificar la información de configuración para una o dos interconexiones del cluster.

• Si el número de puertos disponibles del adaptador es limitado, puede utilizar VLAN etiquetadas para compartir el mismo adaptador en las redes pública y privada. Para obtener más información, consulte las directrices relacionadas con los adaptadores VLAN etiquetadas en Adaptadores de transporte.

• Puede configurar de una a seis interconexiones en un cluster. Aunque una única interconexión del cluster reduce el número de adaptadores utilizados para la interconexión privada, ésta no proporciona ninguna redundancia y ofrece una menor disponibilidad. Si la interconexión única presenta errores, existe un alto riesgo de que el cluster tenga que realizar una recuperación automática. Siempre que sea posible, instale dos o más interconexiones del cluster para proporcionar redundancia y escalabilidad y, por lo tanto, una mayor disponibilidad, lo que permite evitar la presencia de un punto de error único.

Puede configurar interconexiones de cluster adicionales, hasta seis en total, una vez que el cluster se establece mediante la utilidad clsetup.

Para obtener directrices sobre el hardware de interconexión del clúster, consulte Interconnect Requirements and Restrictions de Oracle Solaris Cluster Hardware Administration Manual. Para obtener información general sobre la interconexión del cluster, consulte Cluster Interconnect de Oracle Solaris Cluster 4.3 Concepts Guide.

Adaptadores de transporte

Para los adaptadores de transporte como, por ejemplo, los puertos en las interfaces de red, especifique los nombres de los adaptadores y el tipo de transporte. Si utiliza una configuración de cluster con dos hosts, indique si la interconexión es una conexión de punto a punto (de adaptador a adaptador) o si emplea un conmutador de transporte.

Tenga en cuenta las siguientes directrices y restricciones:

• IPv6: el software Oracle Solaris Cluster no admite las comunicaciones IPv6 a través de interconexiones privadas.

• Asignación de direcciones MAC locales: todos los adaptadores de red privada deben usar tarjetas de interfaz de red (NIC) que admitan asignaciones de direcciones MAC locales. Las direcciones IPv6 de enlace local, necesarias para que los adaptadores de red privada admitan direcciones de red pública IPv6 para servicios de datos escalables, se obtienen a partir de las direcciones MAC locales.

• Adaptadores de VLAN etiquetadas: el software Oracle Solaris Cluster admite redes de área local virtuales (VLAN) etiquetadas para compartir un adaptador entre la interconexión del cluster privada y la red pública. Debe usar el comando dladm create-vlan para configurar el adaptador como adaptador de VLAN etiquetadas antes de configurarlo con el cluster.

  Para configurar el adaptador VLAN con etiquetas para la interconexión del cluster, especifique el adaptador por su nombre de dispositivo virtual VLAN. Este nombre está compuesto por el nombre del adaptador más el número de instancia de VLAN. El número de instancia de VLAN se obtiene mediante la fórmula (1000*V)+N, siendo V el número de VID y N el PPA.

  Por ejemplo, para VID 73 en el adaptador net2, el número de instancia de VLAN se calcula de la siguiente manera: (1000*73)+2. Por lo tanto, especificará net73002 como nombre del adaptador para indicar que forma parte de una LAN virtual compartida.

  Para obtener información sobre cómo configurar una VLAN en un clúster, consulte Configuring VLANs as Private Interconnect Networks de Oracle Solaris Cluster Hardware Administration Manual. Para obtener información sobre la creación y la administración de VLAN, consulte la página del comando man dladm(1M) y el Capítulo 3, Configuración de redes virtuales mediante redes de área local virtuales de Gestión de enlaces de datos de red de Oracle Solaris 11.3.

• SPARC: dominios invitados de Oracle VM Server para SPARC: para los dominios invitados de Oracle VM Server para SPARC que se configuran como nodos de cluster, especifique los nombres de los adaptadores mediante su nombre virtual, vnetN, por ejemplo vnet0 y vnet1. Los nombres de adaptadores virtuales se registran en el archivo /etc/path_to_inst.

• Interfaces de red lógicas: las interfaces de red lógicas se reservan para que las utilice el software Oracle Solaris Cluster.

Conmutadores de transporte

Si utiliza conmutadores de transporte como, por ejemplo, un conmutador de red, especifique uno para cada interconexión. Puede utilizar el nombre por defecto switchN, donde N hace referencia al número asignado automáticamente durante la configuración o, si lo prefiere, cree otro nombre.

Especifique también el nombre del puerto de conmutación o acepte el nombre por defecto. El nombre de puerto por defecto es idéntico al nombre de ID de nodo interno del host de Oracle Solaris que aloja el extremo del cable del adaptador. Sin embargo, para ciertos tipos de adaptadores el nombre de puerto por defecto no es válido.

Los clusters con tres o más nodos deben utilizar conmutadores de transporte. Sólo se admite la conexión directa entre los nodos de cluster para los clusters con dos hosts. Si se realiza una conexión directa en un cluster con dos hosts, aún puede especificar un conmutador de transporte para la interconexión.

Aislamiento global

El aislamiento es un mecanismo utilizado por el cluster para proteger la integridad de los datos de un disco compartido durante las situaciones en las que una partición del cluster cree que la otra partición está inactiva ("cerebro dividido"). En el modo típico, la utilidad scinstall deja activado por defecto el aislamiento global, y cada disco compartido de la configuración utiliza la opción por defecto de aislamiento global prefer3. Con la configuración prefer3, se usa el protocolo SCSI-3.

Si algún dispositivo no puede usar el protocolo SCSI-3, se debe usar la configuración pathcount, en la que el protocolo de aislamiento para los discos compartidos se eligen en función del número de rutas DID que se conectan con el disco. Los dispositivos que no pueden usar SCSI-3 sólo pueden tener dos rutas de dispositivo DID en el cluster. El aislamiento se puede desactivar para los dispositivos que no admiten el aislamiento SCSI-3 o SCSI-2. Sin embargo, la integridad de los datos para estos dispositivos no se puede garantizar en situaciones de "cerebro dividido".

En el modo personalizado, la utilidad scinstall le pregunta si desea desactivar el aislamiento global. En la mayoría de los casos, debe responder No para mantener activado el aislamiento global. Sin embargo, puede desactivar el aislamiento global en determinadas situaciones.

Las situaciones en las que puede desactivar el aislamiento global son las siguientes:

• El almacenamiento compartido no admite las reservas SCSI.

  Si desactiva el aislamiento para un disco compartido que configura a continuación como dispositivo del quórum, este dispositivo utilizará el protocolo de quórum del software. Esta acción se lleva a cabo independientemente de si el disco admite el protocolo SCSI-2 o SCSI-3. El quórum del software es un protocolo de Oracle Solaris Cluster que emula un formato de Reservas de grupo persistente (PGR) SCSI.

• Desea activar sistemas que se encuentran fuera del cluster para obtener acceso al almacenamiento conectado al cluster.

Si desactiva el aislamiento global durante la configuración del cluster, esta función se desactivará para todos los discos compartidos del cluster. Una vez configurado el cluster, puede cambiar el protocolo de aislamiento global o anular el protocolo de aislamiento de discos compartidos individuales. Sin embargo, para cambiar el protocolo de aislamiento de un dispositivo del quórum, debe configurar primero este dispositivo. A continuación, establezca el nuevo protocolo de aislamiento del disco y vuelva a configurarlo en un dispositivo del quórum.

Para obtener más información sobre el comportamiento de aislamiento, consulte Failfast Mechanism de Oracle Solaris Cluster 4.3 Concepts Guide. Para obtener más información sobre cómo establecer el protocolo de aislamiento de discos compartidos individuales, consulte la página del comando man cldevice(1CL). Para obtener más información sobre la configuración del aislamiento global, consulte la página del comando man cluster(1CL).

Dispositivos de quórum

Las configuraciones de Oracle Solaris Cluster usan dispositivos del quórum para mantener la integridad de los datos y de los recursos. Si el cluster pierde temporalmente la conexión con un nodo, el dispositivo del quórum evita los problemas de "amnesia" o "cerebro divido" cuando el nodo intenta unirse de nuevo al cluster. Para obtener más información sobre el objetivo y la función de los dispositivos de quórum, consulte Quorum and Quorum Devices de Oracle Solaris Cluster 4.3 Concepts Guide.

Durante la instalación de Oracle Solaris Cluster de un cluster con dos hosts, puede optar por permitir que la utilidad scinstall configure automáticamente como dispositivo de quórum un disco compartido disponible en la configuración. La utilidad scinstall presupone que todos los discos de almacenamiento compartido disponibles son aptos para convertirse en dispositivos de quórum.

Si desea usar un servidor de quórum o un dispositivo NAS de Oracle ZFS Storage Appliance como dispositivo de quórum, debe configurarlo después de que finalice el procesamiento de scinstall.

Después de la instalación, también puede configurar dispositivos de quórum adicionales con la utilidad clsetup.

Si la configuración del cluster incluye dispositivos de almacenamiento compartido de terceros que no se pueden utilizar como dispositivos del quórum, debe usar la utilidad clsetup para configurar el quórum manualmente.

Tenga en cuenta los siguientes puntos al planificar los dispositivos de quórum:

• Mínimo: un cluster con dos nodos debe tener como mínimo un dispositivo del quórum, que puede ser un disco compartido, un servidor de quórum o un dispositivo NAS. Para las demás topologías, los dispositivos del quórum son opcionales.

• Regla del número impar: si se configura más de un dispositivo de quórum en un cluster con dos hosts o en un par de hosts conectados directamente al dispositivo de quórum, configure un número impar de dispositivos del quórum. Esta configuración garantiza que los dispositivos del quórum presenten rutas de error completamente independientes.

• Distribución de los votos del quórum: para obtener la mayor disponibilidad del cluster, asegúrese de que el número total de votos proporcionados por los dispositivos del quórum sea inferior al número de votos proporcionados por los nodos. De lo contrario, los nodos no pueden formar un cluster si todos los dispositivos de quórum no están disponibles, aunque todos los nodos estén funcionando.

• Conexión: debe conectar un dispositivo del quórum a, como mínimo, dos nodos.

• Protocolo de aislamiento SCSI: al configurar un dispositivo del quórum de discos compartidos SCSI, su protocolo de aislamiento se establece automáticamente en SCSI-2 en un cluster con dos hosts o en SCSI-3 en un cluster con tres o más nodos.

• Cambio del protocolo de aislamiento de los dispositivos del quórum: para los discos SCSI configurados como dispositivos del quórum, debe anular la configuración de estos dispositivos antes de activar o desactivar su protocolo de aislamiento SCSI.

• Protocolo del quórum del software: puede configurar como dispositivos del quórum discos compartidos compatibles que no admitan el protocolo SCSI como, por ejemplo, discos SATA. Debe desactivar el aislamiento para estos discos. En ese caso, los discos utilizan el protocolo de quórum del software, que emula las PGR SCSI.

  Los discos compartidos SCSI utilizan también el protocolo de quórum del software si se ha desactivado el aislamiento para estos discos.

• Dispositivos repetidos: el software Oracle Solaris Cluster no admite dispositivos repetidos como dispositivos del quórum.

• Agrupaciones de almacenamiento ZFS: no agregue un dispositivo de quórum configurado a una agrupación de almacenamiento ZFS. Si se agrega un dispositivo del quórum a un grupo de almacenamiento ZFS, el disco se reetiqueta como disco EFI y se pierde la información de configuración del quórum. El disco ya no podrá proporcionar un voto del quórum al cluster.

  Una vez que haya un disco en el grupo de almacenamiento, puede configurarlo como dispositivo del quórum. También puede anular la configuración del dispositivo del quórum, agregar el disco al grupo de almacenamiento y, a continuación, volver a configurarlo como dispositivo del quórum.

Para obtener más información sobre los dispositivos de quórum, consulte Quorum and Quorum Devices de Oracle Solaris Cluster 4.3 Concepts Guide.

SPARC: directrices para dominios lógicos de Oracle VM Server para SPARC como nodos de cluster

Tenga en cuenta los siguientes puntos al crear un dominio lógico de Oracle VM Server para SPARC en una máquina agrupada físicamente en clusters que sea compatible con el hipervisor SPARC para usarlo como nodo de cluster:

• Tipos de dominios admitidos: puede configurar los dominios invitados, dominios de E/S y dominios de control de Oracle VM Server para SPARC como nodos de cluster.

• Dispositivos SR-IOV: un dispositivo SR-IOV admite un dominio lógico configurado para ejecutarse como un nodo del cluster. Consulte Oracle Solaris Cluster 4 Compatibility Guide (Guía de compatibilidad de Oracle Solaris Cluster 4) para obtener información sobre los dispositivos SR-IOV admitidos.

• Requisito de LUN SCSI: el dispositivo de almacenamiento virtual o backend de disco virtual de un dominio invitado de Oracle VM Server para SPARC debe ser un LUN SCSI completo en el dominio de E/S. No se puede utilizar un dispositivo virtual arbitrario.

• Aislamiento: no exporte un LUN de almacenamiento a más de un dominio invitado en la misma máquina física a menos que desactive también el aislamiento para ese dispositivo. De lo contrario, si dos dominios invitados diferentes se encuentran en una misma máquina y los dos están visibles para un dispositivo, este dispositivo se aislará cada vez que se detenga uno de los dominios invitados. El aislamiento del dispositivo generará un error grave en los demás dominios invitados que intenten acceder posteriormente al dispositivo.

• Aislamiento de red: los dominios invitados que residen en el mismo equipo físico, pero que se configuran en clusters diferentes, deben encontrarse en la red aislados entre sí. Utilice uno de los métodos siguientes:

  • Configure los clusters para que utilicen diferentes interfaces de red en el dominio de E/S de la red privada.

  • Use direcciones de red distintas para cada uno de los clusters cuando realice la configuración inicial de los clusters.

• Funciones de red en los dominios invitados: los paquetes de red que se transfieren a los dominios invitados y que proceden de ellos deben atravesar los dominios de servicios para acceder a los controladores de red mediante los conmutadores virtuales. Los conmutadores virtuales utilizan subprocesos del núcleo que se ejecutan con prioridad del sistema. Los subprocesos de conmutadores virtuales deben poder adquirir los recursos de CPU necesarios para realizar operaciones vitales del cluster, incluidos los puntos de control, las respuestas, la pertenencia, etc. Al configurar los conmutadores virtuales con la opción mode=sc, se activa la administración acelerada de los paquetes de respuestas del cluster. Sin embargo, la fiabilidad de las demás operaciones vitales del cluster pueden mejorarse añadiendo más recursos de CPU al dominio de servicios bajo las siguientes cargas de trabajo:

  • Carga de alta interrupción, por ejemplo, por E/S de disco o red. Con carga extrema, los conmutadores virtuales pueden evitar que los subprocesos del sistema se ejecuten durante mucho tiempo, incluso los subprocesos de conmutadores virtuales.

  • Subprocesos en tiempo real que presentan un comportamiento excesivamente agresivo al conservar los recursos de CPU. Los subprocesos en tiempo real se ejecutan con una prioridad superior a los subprocesos de conmutadores virtuales, lo que puede limitar los recursos de CPU de los subprocesos de conmutadores virtuales durante un amplio periodo de tiempo.

• Almacenamiento no compartido: para el almacenamiento no compartido, como las imágenes de sistema operativo de dominios invitados de Oracle VM Server para SPARC, se puede utilizar cualquier clase de dispositivo virtual. Puede usar estos dispositivos virtuales con cualquier elemento del dominio de E/S como, por ejemplo, los archivos o los volúmenes. No obstante, no copie archivos ni clone volúmenes en el dominio de E/S para asignarlos a diferentes dominios invitados del mismo cluster. Estas acciones provocarían problemas, ya que los dispositivos virtuales resultantes presentarían la misma identidad de dispositivo en dominios invitados diferentes. Cree siempre un nuevo archivo o dispositivo en el dominio de E/S, que recibirá una identidad de dispositivo exclusiva, y, a continuación, asígnelo a un dominio invitado diferente.

• Exportación del almacenamiento desde dispositivos de E/S: si configura un cluster formado por dominios de E/S de Oracle VM Server para SPARC, no exporte sus dispositivos de almacenamiento a otros dominios invitados que ejecuten también el software Oracle Solaris Cluster.

• Multirruta de E/S de Solaris de Oracle: no ejecute el software Multirruta de E/S de Solaris de Oracle (MPxIO) desde los dominios invitados o los dominios de control. En su lugar, ejecute el software de rutas múltiples de E/S de Oracle Solaris en el dominio de E/S o el dominio de control y expórtelo a los dominios invitados.

• Rutas múltiples de disco virtual: no configure la función de rutas múltiples de disco virtual de Oracle VM Server para SPARC en un dominio lógico configurado como un nodo de cluster.

• Restricción de migración en vivo: la migración en vivo no se admite para dominios lógicos que están configurados para ejecutarse como nodos de cluster. Sin embargo, los dominios lógicos que se han configurado para ser gestionados por el servicio de datos HA para Oracle VM Server para SPARC pueden usar la migración en vivo.

Para obtener más información sobre , consulte la Guía de administración para Oracle VM Server for SPARC 3.1.

Clusters de zona

Un cluster de zona es un cluster de una zona no global de Oracle Solaris. Puede usar la utilidad clsetup o la interfaz de explorador de Oracle Solaris Cluster Manager para crear un cluster de zona y agregar una dirección de red, un sistema de archivos, una agrupación de almacenamiento ZFS o un dispositivo de almacenamiento. También puede utilizar una interfaz de línea de comandos (la utilidad clzonecluster) para crear un cluster de zona, realizar cambios en la configuración y eliminar un cluster de zona. Para obtener más información sobre el uso de la utilidad clzonecluster, consulte la página del comando man clzonecluster(1CL). Para obtener más información sobre Oracle Solaris Cluster Manager, consulte el Capítulo 13, Uso de la interfaz de explorador de Oracle Solaris Cluster Manager de Guía de administración del sistema de Oracle Solaris Cluster 4.3.

Las marcas compatibles para clusters de zona son solaris, solaris10 y labeled. La marca labeled se utiliza exclusivamente en un entorno de Trusted Extensions. Para utilizar la función Trusted Extensions de Oracle Solaris, debe configurar la función Trusted Extensions para su uso en un cluster de zona. No se admite ningún otro uso de Trusted Extensions en una configuración de Oracle Solaris Cluster.

También puede especificar un cluster de zona de IP compartida o de IP exclusiva al ejecutar la utilidad clsetup.

• Los clusters de zona de IP compartida funcionan con zonas de marcas solaris o solaris10. Un cluster de zona de IP compartida comparte una sola pila IP entre todas las zonas del nodo, y se asigna una dirección IP a cada zona.

• Los clusters de zona de IP exclusiva funcionan con zonas con marca solaris o solaris10. Un cluster de zona de IP exclusiva admite una pila de instancia IP separada.

Tenga en cuenta los siguientes puntos cuando planifique la creación de un cluster de zona:

• Requisitos y directrices del cluster global

• Requisitos y directrices de los clusters de zona

• Directrices para Trusted Extensions en un cluster de zona

Requisitos y directrices del cluster global

• Cluster global: el cluster de zona debe establecerse en una configuración de Oracle Solaris Cluster global. Un cluster de zona puede configurarse sin un cluster global subyacente.

• Modo de cluster: el nodo de cluster global desde el que se crea o modifica un cluster de zona se debe encontrar en el modo de cluster. Si, al administrar un cluster de zona, los demás nodos se encuentran en el modo sin cluster, los cambios realizados se propagarán a esos nodos al volver al modo de cluster.

• Direcciones IP privadas adecuadas: el rango de direcciones IP privadas del cluster global debe disponer de suficientes subredes de direcciones IP libres para el nuevo cluster de zona. Si el número de subredes disponibles es insuficiente, la creación del cluster de zona presentará errores.

• Cambios en el intervalo de direcciones IP privadas: las subredes IP privadas y sus correspondientes direcciones IP privadas disponibles para los clusters de zona se actualizan automáticamente si se modifica el intervalo de direcciones IP privadas del cluster global. Si se suprime un cluster de zona, la infraestructura de cluster libera las direcciones IP privadas utilizadas por éste, lo que permite que las direcciones estén disponibles para su uso en el cluster global y por parte de los demás clusters de zona que dependan del cluster global.

• Dispositivos admitidos: los dispositivos compatibles con las zonas de Oracle Solaris pueden exportarse a un cluster de zona. Entre estos dispositivos, se incluyen los siguientes:

  • Dispositivos de disco de Oracle Solaris (cNtXdYsZ)

  • Dispositivos DID (/dev/did/*dsk/dN)

  • Conjuntos de discos de propietarios múltiples de Solaris Volume Manager y Solaris Volume Manager para Sun Cluster (/dev/md/setname/*dsk/dN)

Requisitos y directrices de los clusters de zona

• Distribución de los nodos: no se pueden alojar varios nodos del mismo cluster de zona en el mismo equipo del nodo. Un host puede admitir varios nodos de cluster de zona siempre y cuando cada cluster de zona de ese host sea miembro de un cluster de zona diferente.

• Creación de nodos: debe crear, al menos, un nodo durante la creación del cluster de zona. Puede usar la utilidad clsetup o el comando clzonecluster para crear el cluster de zona. El nombre del nodo de cluster de zona debe ser exclusivo en el cluster de zona. La infraestructura crea automáticamente una zona no global subyacente en cada host que admite el cluster de zona. Cada zona no global recibe el mismo nombre, que se obtiene del nombre asignado al cluster de zona durante la creación del cluster, por lo que es idéntico a éste. Por ejemplo, si crea un cluster de zona con el nombre zc1, el nombre de la zona no global correspondiente en cada host que admite el cluster de zona también es zc1.

• Nombre de cluster: cada nombre de cluster de zona debe ser exclusivo en todo el cluster de máquinas que alojan el cluster global. Este nombre de cluster de zona no puede utilizarse para ninguna zona global en ninguna parte del cluster de equipos. Tampoco puede ser idéntico al de un nodo del cluster global. No se pueden utilizar "all" (todos) o "global" como nombres del cluster de zona ya que están reservados.

• Direcciones IP de red pública: puede asignar una dirección IP de red pública específica a cada nodo del cluster de zona.

  ---

  Notas -  Si no configura una dirección IP para cada nodo de cluster de zona, ocurrirán dos cosas:

  • Ese cluster de zona específico no podrá configurar dispositivos NAS para utilizar en el cluster de zona. El cluster utiliza la dirección IP del nodo de cluster de zona para comunicarse con el dispositivo NAS, por lo que no tener una dirección IP impide la admisión de clusters para el aislamiento de dispositivos NAS.

  • El software del cluster activará cualquier dirección IP de host lógico en cualquier NIC.

  ---

• Nombres de host privados: durante la creación del cluster de zona, se crea automáticamente un nombre de host privado para cada nodo del cluster de zona, de la misma forma que se crean nombres de host en clusters globales. Actualmente no se puede cambiar el nombre de host de un nodo de cluster de zona. Para obtener más información sobre los nombres de host privados, consulte la sección Nombres de host privados.

• Marcas de Oracle Solaris Zones: todos los nodos de un cluster de zona se configuran como zonas no globales de las marcas solaris, solaris10 o labeled que se establecen con el atributo cluster. No se permite ningún otro tipo de marca en un cluster de zona.

  Para Trusted Extensions, debe utilizar sólo la marca labeled.

• Restricción de la propiedad de Zonas invariables para file-mac-profile: la propiedad de zonas de Oracle Solaris file-mac-profile actualmente no es soportada por el comando clzonecluster.

  Además, no intente utilizar el comando zonecfg de Oracle Solaris para configurar la propiedad file-mac-profile en ninguna zona no global subyacente de un cluster de zona. Esta acción puede provocar un comportamiento inesperado de los servicios de cluster de ese cluster de zona.

• Tipo de IP: puede crear un cluster de zona ya sea con el tipo de IP shared o el exclusive. Si el tipo de IP no se ha especificado, un cluster de zona de IP compartida se crea por defecto.

• Propiedad de tipo de recurso Global_zone=TRUE: para registrar un tipo de recurso que utiliza la propiedad de tipo de recurso Global_zone=TRUE, el archivo de tipo de recurso debe ubicarse en el directorio /usr/cluster/global/rgm/rtreg/ del cluster de zona. Si ese archivo de tipo de recurso se encuentra en otra ubicación, se rechaza el comando para registrar el tipo de recurso.

• Sistemas de archivos: puede usar la utilidad clsetup o el comando clzonecluster para agregar los siguientes tipos de sistemas de archivos para que los use el cluster de zona. Un sistema de archivos se exporta a un cluster de zona mediante un montaje directo o un montaje en bucle invertido. La agregación de un sistema de archivos con la utilidad clsetup se realiza en el ámbito del cluster, lo que afecta a todo el cluster de zona.

  • Por montaje directo:

    • Sistema local de archivos UFS

    • Sistema de archivos independiente StorageTek QFS

    • Sistema de archivos compartidos StorageTek QFS, solamente cuando se utiliza para admitir Oracle RAC

    • Oracle Solaris ZFS (exportado como conjunto de datos)

    • NFS desde dispositivos NAS admitidos

  • Por montaje en bucle de retorno:

    • Sistema local de archivos UFS

    • Sistema de archivos independiente StorageTek QFS

    • Sistema de archivos compartidos StorageTek QFS, solamente cuando se utiliza para admitir Oracle RAC

    • Sistema de archivos de cluster de UFS

  Puede configurar un recurso de HAStoragePlus o ScalMountPoint para gestionar el montaje del sistema de archivos.

Directrices para Trusted Extensions en un cluster de zona

Tenga en cuenta los puntos siguientes al utilizar la función Trusted Extensions de Oracle Solaris en un cluster de zona:

• Compatibilidad sólo con cluster de zona: en una configuración de Oracle Solaris Cluster con Trusted Extensions activada, las aplicaciones se deben ejecutar sólo en un cluster de zona. Otras zonas no globales no se pueden utilizar en el cluster. Para crear un cluster de zona, se debe utilizar solamente el comando clzonecluster. No utilice el comando txzonemgr para crear una zona no global en un cluster que tiene Trusted Extensions activado.

• Ámbito de Trusted Extensions: puede activar o desactivar Trusted Extensions para toda la configuración del cluster. Cuando Trusted Extensions está activada, todas las zonas no globales de la configuración del cluster deben pertenecer a uno de los clusters de zona. No puede configurar ningún otro tipo de zona no global sin poner en peligro la seguridad.

• Direcciones IP: cada cluster de zona que utiliza Trusted Extensions debe utilizar sus propias direcciones IP. La función de red especial en Trusted Extensions que permite que una dirección IP se comparta entre varias zonas no globales no es compatible con el software de Oracle Solaris Cluster.

• Montajes de bucle de retorno: no puede utilizar montajes de bucle de retorno que tienen permisos de escritura en un cluster de zona utiliza Trusted Extensions. Utilice sólo montajes directos de sistemas de archivos que permiten el acceso de escritura o utilice montajes de bucle de retorno que sólo tienen permisos de lectura.

• Sistemas de archivos: no configure en el cluster de zona el dispositivo global subyacente a un sistema de archivos. Configure sólo el sistema de archivos en el cluster de zona.

• Nombre de dispositivo de almacenamiento: no agregue un segmento individual de un dispositivo de almacenamiento a un cluster de zona. Debe agregar todo el dispositivo a un único cluster de zona. El uso de segmentos del mismo dispositivo de almacenamiento en diferentes clusters de zona pone en riesgo la seguridad de esos clusters.

• Instalación de aplicaciones: instale aplicaciones sólo en el cluster de zona o en el cluster global, y luego exporte al cluster de zona mediante el uso de montajes de bucle de retorno de sólo lectura.

• Aislamiento de cluster de zona: cuando se utiliza Trusted Extensions, el nombre de un cluster de zona es una etiqueta de seguridad. En algunos casos, la etiqueta de seguridad puede ser información que no puede ser divulgada, y el nombre de un recurso o un grupo de recursos puede ser un fragmento de información confidencial que no puede ser revelada. Cuando se configura una dependencia de recurso entre clusters o una afinidad de grupo de recursos entre clusters, el nombre del otro cluster se vuelve visible, así como el nombre de los recursos o el grupo de recursos afectados. Por lo tanto, antes de que se establezca cualquier relación entre clusters, evalúe si esta información puede estar visible en función de los requisitos.