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.

• Licencias

• Parches de software

• Direcciones IP de red pública

• Dispositivos de acceso a la consola

• Direcciones lógicas

• Redes públicas

• 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

• Clusters de zona

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

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

Parches de software

Después de instalar los productos de software, debe instalar también los parches necesarios. Para garantizar el correcto funcionamiento del cluster, asegúrese de que todos los nodos del cluster mantengan el mismo nivel de parche.

• Para obtener más información sobre los parches necesarios, consulte Parches y niveles de firmware requeridos de Notas de la versión de Oracle Solaris Cluster 3.3 3/13 o comuníquese con su proveedor de servicios Oracle.

• Para obtener directrices y procedimientos para aplicar los parches, consulte el Capítulo 11, Aplicación de parches de software y firmware de Oracle Solaris Cluster de Guía de administración del sistema de Oracle Solaris Cluster.

Direcciones IP de red pública

Para obtener información sobre el uso de redes públicas por el cluster, consulte Public Network Adapters and IP Network Multipathing de Oracle Solaris Cluster Concepts Guide.

Debe configurar varias direcciones IP de red pública para los diferentes componentes de Oracle Solaris Cluster en función de 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 1-3 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 (Sun Fire 15000) 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 acerca de la planificación de direcciones IP, consulte el Capítulo 2, Planificación de la red TCP/IP (tareas) de Administración de Oracle Solaris: servicios IP.

Dispositivos de acceso a la consola

Debe disponer de acceso a la consola en todos los nodos del cluster. Si instala el software de Cluster Control Panel en una consola de administración, debe proporcionar el nombre de host y el número de puerto del dispositivo de la consola de acceso utilizado para comunicarse con los nodos del cluster.

• Se utiliza un concentrador de terminales para establecer la comunicación entre la consola de administración y las consolas de los nodos del cluster global.

• Un servidor Sun Fire utiliza un controlador de sistema, en lugar de un concentrador de terminal.

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

Como alternativa, si conecta directamente una consola administrativa a nodos del cluster o mediante una red de administración, debe proporcionar el nombre de host de cada nodo de cluster global y el número de puerto de serie que se utilizan para conectarse a la consola de administración o a la red de administración.

Direcciones lógicas

En cada grupo de recursos de servicios de datos que utilice una dirección lógica, se debe especificar un nombre del sistema para cada red pública desde la que se puede acceder a la dirección lógica.

Para obtener más información, consulte la Oracle Solaris Cluster Data Services Planning and Administration Guide . Para obtener más información sobre los recursos y los servicios de datos, también consulte la Oracle Solaris Cluster Concepts Guide.

Redes públicas

Las redes públicas se comunican fuera del cluster. Tenga en cuenta los siguientes aspectos al planificar 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.

• 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í.

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

• IPv6: el software Oracle Solaris Cluster admite direcciones IPv6 en la red pública para servicios de datos escalables y de migración tras error.

• Grupos IPMP: cada adaptador de red pública utilizado para el tráfico de servicios de datos debe pertenecer a un grupo Varias rutas de red IP (IPMP). 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 grupo IPMP.

  La utilidad scinstall configura automáticamente un grupo IPMP de varios adaptadores para cada conjunto de adaptadores de la red pública en el cluster que utiliza la misma subred. Estos grupos se basan en sondeos.

  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. No obstante, 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 instrucciones y directrices de configuración de grupos de IPMP, siga los procedimientos descritos en Parte V, IPMP de Administración de Oracle Solaris: servicios IP. Para modificar grupos IPMP después de la instalación del cluster, siga las directrices de 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 y los procedimientos del Capítulo 28, Administración de IPMP (tareas) de Administración de Oracle Solaris: servicios IP.

• 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 predeterminado true para los adaptadores Ethernet. El software de 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 Concepts Guide.

Configuración del servidor de quórum

Puede utilizar el software de servidor de quórum de Oracle Solaris Cluster 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 se conecta al cluster mediante la red pública.

• 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.

• Servicio para varios clusters: puede configurar un servidor de quórum que se instala con el software de servidor de quórum Oracle Solaris Cluster 3.3 3/13 como dispositivo de 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 el cluster o los clusters para los que se proporciona el quórum. Por ejemplo, una máquina basado en SPARC que ejecute el SO Oracle Solaris 10 se puede configurar como servidor de quórum para un cluster basado en x86 que ejecute el SO Oracle Solaris 10.

  Además, un cluster que ejecuta el software de Oracle Solaris Cluster 3.3 3/13 puede usar un servidor de quórum que ejecuta una versión distinta del software que el cluster. Consulte la tabla de interoperabilidad del servidor de quórum en la Oracle Solaris Cluster 4 Compatibility Guide para obtener más información sobre las versiones de software combinadas.

• 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 del 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) 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 Oracle Solaris Cluster HA para NFS (HA para NFS) que se esté supervisando en un nodo del mismo cluster. Esta clase de montaje cruzado de HA para NFS no está permitido. 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 podrían 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(3UCB) o fcntl(2)) podría interferir en la capacidad para reiniciar el administrador de bloqueos (lockd(1M)). Durante el reinicio, se puede conceder a un proceso local bloqueado un bloqueo destinado a que un cliente remoto lo solicite. Esto 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 Oracle Solaris Cluster sí admite las siguientes funciones de seguridad de 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. Para obtener más información, consulte Securing HA for NFS With Kerberos V5 de Oracle Solaris Cluster Data Service for Network File System (NFS) Guide.

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

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 la migración tras error 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 inicio e instalación: no utilice una configuración de Oracle Solaris Cluster para proporcionar un servicio de inicio o 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 del programa RPC: si instala un servicio RPC en el cluster, éste 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.

• Mensajes de error acerca de nodos que no existen: salvo que haya instalado su propio archivo /etc/inet/ntp.conf, el comando scinstall instala por usted un archivo ntp.conf predeterminado. El archivo predeterminado se envía con referencias a el número máximo de nodos. Por lo tanto, el daemon xntpd(1M) puede emitir mensajes de error sobre algunas de estas referencias en el momento del inicio. Puede pasar por alto estos mensajes. Consulte Configuración de Network Time Protocol (NTP) para obtener más información sobre cómo suprimir estos mensajes en condiciones de cluster normales.

Consulte la Oracle Solaris Cluster Concepts Guide para obtener más información sobre la hora del cluster. Consulte el archivo de plantilla /etc/inet/ntp.cluster para obtener directrices adicionales acerca de cómo configurar NTP para una configuración de Oracle Solaris Cluster.

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 los nodos de votación de cluster global e identificadores de nodos

• Los nombres de zona

• Configuración de red privada

• Nombres de host privados

• Interconexión del 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 los nodos de votación de cluster global e identificadores de nodos

El nombre de un nodo de votación de un 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 solo nodo, el nombre de cluster predeterminado es el nombre del nodo con voto.

Durante la configuración de Oracle Solaris Cluster, debe especificar los nombres de todos los nodos de votación que va a instalar en el cluster global.

Se asigna un número de ID de nodo a cada nodo del cluster para el uso entre clusters, 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 de 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.

Los nombres de zona

Una zona no global con la marca native puede ser un posible nodo válido de una lista de nodos de grupo de recursos. Utilice la convención de denominación nodename:zonename para especificar una zona no global para un comando de Oracle Solaris Cluster.

• nodename es el nombre del host de Oracle Solaris.

• zonename es el nombre que se asigna a la zona no global al crear la zona en el nodo con voto. El nombre de zona debe ser único en el nodo. Sin embargo, puede utilizar el mismo nombre de zona en diferentes nodos con voto. Los distintos nombres de nodo en nodename:zonename hacen que toda la zona no global tenga asignado un nombre único en el cluster.

Para especificar la zona global, sólo tiene que especificar el nombre del nodo con voto.

Para obtener información sobre un cluster de las zonas no globales, consulte Clusters de zona.

Puede desactivar la función de cluster para una zona no global seleccionada. Un usuario root que ha iniciado sesión en una de estas zonas no puede detectar el funcionamiento del cluster ni tampoco interrumpirlo. Para obtener instrucciones, consulte Denying Cluster Services for a Non-Global Zone de Oracle Solaris Cluster Data Service for Solaris Containers Guide.

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) predeterminadas. Este rango de direcciones IP admite un máximo combinado de 64 nodos de votación y zonas no globales, un máximo de 12 clusters de zona y un máximo de 10 redes privadas.

  ---

  Nota - El número máximo de nodos de votación que puede admitir un intervalo de direcciones IP no refleja el número máximo de nodos de votación 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 predeterminada.

• Acepte la dirección de red privada predeterminada 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 rango 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 predeterminada, ésta 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.

  En el caso de los dominios invitados de Oracle VM Server para SPARC creados en una misma máquina física y que se conectan al mismo conmutador virtual, todos estos dominios comparten la red privada y pueden verla. 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. No obstante, limitar el uso de una VLAN a un solo cluster ofrece mejor capacidad de aislamiento de errores y una interconexión más resiliente.

• 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 el Capítulo 2, Planificación de la red TCP/IP (tareas) de Administración de Oracle Solaris: servicios IP 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 siguen la siguiente convención de denominación: clusternodenodeid -priv, donde nodeid hace referencia al 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 a cada nodo de votación cuando éste se convierte en miembro del cluster. Un nodo de votación 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 del 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 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 del cluster adicionales (hasta seis en total), una vez establecido el cluster mediante la utilidad clsetup(1CL).

Para obtener directrices sobre el hardware de interconexión del cluster, consulte Interconnect Requirements and Restrictions de Oracle Solaris Cluster 3.3 3/13 Hardware Administration Manual. Para obtener información general sobre la interconexión del cluster, consulte Cluster Interconnect de Oracle Solaris Cluster 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 de Oracle Solaris Cluster no admite las comunicaciones IPv6 por medio 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, se obtienen a partir de las direcciones MAC locales.

• Adaptadores de VLAN etiquetadas: el software de 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. Para configurar un adaptador de VLAN etiquetada para la interconexión del cluster, especifique el nombre del adaptador y el ID de VLAN (VID) de una de las siguientes maneras:

  • Especifique el nombre de adaptador habitual, que es el nombre de dispositivo más el número de instancia o punto físico de conexión (PPA). Por ejemplo, el nombre de instancia 2 de un adaptador Cassini Gigabit Ethernet sería ce2. Si la utilidad scinstall le pregunta si el adaptador forma parte de una LAN virtual compartida, responda yes (sí) y especifique el número de VID del adaptador.

  • 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 ce2, el número de instancia de VLAN se calcula de la siguiente manera: (1000*73)+2. Por lo tanto, especificará ce73002 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 cluster, consulte Configuring VLANs as Private Interconnect Networks de Oracle Solaris Cluster 3.3 3/13 Hardware Administration Manual. Para obtener información general sobre VLAN, consulte Administración de redes de área local virtuales de Administración de Oracle Solaris: servicios IP.

• Dominios invitados de SPARC: Oracle VM Server para SPARC: especifique los nombres de los adaptadores mediante su nombre virtual, vnetN, como 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.

Consulte la familia de páginas del comando man scconf_trans_adap_*(1M) para obtener información sobre un determinado adaptador de transporte.

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 predeterminado 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 predeterminado. El nombre de puerto predeterminado 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 predeterminado no es válido.

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 de manera predeterminada el aislamiento global, y cada disco compartido de la configuración utiliza la opción predeterminada de aislamiento global prefer3. Con la configuración prefer3, se usa el protocolo SCSI-3.

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

Las situaciones en las que puede deshabilitar 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 habilitar sistemas que se encuentran fuera del cluster para obtener acceso al almacenamiento conectado al cluster.

Si inhabilita 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 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 de votación, el dispositivo del quórum evita los problemas de "amnesia" o "cerebro divido" cuando el nodo intente 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 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. Entre los discos compartidos se incluye cualquier dispositivo NAS de Sun que se haya configurado para utilizarse como un disco compartido. La utilidad scinstall presupone que todos los discos de almacenamiento compartido disponibles son aptos para convertirse en dispositivos de quórum.

Si desea utilizar un servidor de quórum como dispositivo de quórum, debe agregarlo a la configuración del cluster una vez que haya finalizado el procesamiento de scinstall. Para obtener más información acerca de los servidores de quórum, consulte Configuración del servidor de quórum.

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 del 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 configuran varios dispositivos 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 de 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 ninguno de los dispositivos de quórum está disponible aunque todos los nodos estén funcionando.

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

• Protocolo de aislamiento SCSI: al configurar un dispositivo de 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 con voto.

• 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 habilitar o inhabilitar su protocolo de aislamiento SCSI.

• Protocolo de quórum de software: puede configurar como dispositivos de quórum discos compartidos compatibles que no admiten el protocolo SCSI, como, por ejemplo, discos SATA. Debe habilitar el aislamiento para estos discos. A continuación, los discos utilizarán el protocolo del quórum del software, que emula las reservas PGR SCSI.

  Los discos compartidos SCSI utilizarán también el protocolo del 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.

• Grupos de almacenamiento ZFS: no agregue un dispositivo del quórum configurado a un grupo 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 Concepts Guide.

Clusters de zona

Un cluster de zona es un cluster de una zona no global de Oracle Solaris. Todos los nodos de un cluster de zona se configuran como zonas no globales de la marca cluster. No se permite ningún otro tipo de marca en un cluster de zona. Puede ejecutar servicios compatibles en el cluster de zona del mismo modo que en un cluster global, con el aislamiento proporcionado por las zonas de Oracle Solaris.

Puede usar la utilidad clsetup 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)

Tenga en cuenta los siguientes puntos al planificar 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 votación de cluster global desde el que se crea o modifica un cluster de zona debe encontrarse en el modo de cluster. Si, al administrar un cluster de zona, los demás nodos de votación 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 elimina 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 (cNt XdYsZ)

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

  • Conjuntos de discos de Solaris Volume Manager y Solaris Volume Manager para Sun Cluster para varios propietarios (/dev/md/setname/*dsk/d N)

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.

  ---

  Nota - 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 zonas de Oracle Solaris: todos los nodos de un cluster de zona se configuran como zonas no globales de la marca cluster. No se permite ningún otro tipo de marca en un cluster de zona.

• 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.

• Conversión a un nodo de cluster de zona: no se puede agregar a un cluster de zona una zona no global que se encuentre fuera de ese cluster de zona. Se debe usar solamente el comando clzonecluster para agregar nodos nuevos a un cluster de zona.

• 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 un 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 independientes QFS

    • Sistema de archivos compartidos QFS, sólo cuando se utiliza para admitir el uso de Oracle Real Application Clusters

    • ZFS (exportado como un conjunto de datos)

    • NFS desde dispositivos NAS admitidos

  • Por montaje en bucle de retorno:

    • Sistema local de archivos UFS

    • Sistema de archivos independientes QFS

    • Sistema de archivos compartidos QFS, sólo cuando se utiliza para admitir sistema de archivos

    • UFS del cluster de Oracle Real Application Clusters

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

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

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 usar 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.