Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
Guía de instalación del software de Oracle Solaris Cluster Oracle Solaris Cluster 3.3 3/13 (Español) |
1. Planificación de la configuración de Oracle Solaris Cluster
Búsqueda de tareas de instalación de Oracle Solaris Cluster
Planificación del sistema operativo Oracle Solaris
Directrices para seleccionar el método de instalación de Solaris
Restricciones de las funciones del sistema operativo Oracle Solaris
Consideraciones del grupo de software de Oracle Solaris
Particiones de disco del sistema
Directrices para el sistema de archivos raíz (/)
Directrices para el sistema de archivos /globaldevices
Requisitos del administrador de volúmenes
Ejemplos de asignaciones del sistema de archivos
Directrices para zonas no globales en un cluster global
SPARC: Directrices para Oracle VM Server para SPARC en un cluster
Planificación del entorno de Oracle Solaris Cluster
Dispositivos de acceso a la consola
Configuración del servidor de quórum
Protocolo de tiempo de red (NTP)
Componentes configurables de Oracle Solaris Cluster
Nombres de los nodos de votación de cluster global e identificadores de nodos
Requisitos y directrices del cluster global
Requisitos y directrices de los clusters de zona
Directrices para Trusted Extensions en un cluster de zona
Planificación de los dispositivos globales
Grupos de dispositivos de planificación
Planificación de sistemas de archivos del cluster
Elección de opciones de montaje para sistemas de archivos del cluster UFS
Información de montaje para los sistemas de archivos del cluster
Planificación de la administración de volúmenes
Directrices del software del administrador de volúmenes
Directrices para el software de Solaris Volume Manager
Registro del sistema de archivos
Directrices de creación de reflejos
Directrices para la creación de reflejos de discos multihost
2. Instalación del software en los nodos del cluster global
3. Establecimiento del cluster global
4. Configuración del software de Solaris Volume Manager
5. Creación de un sistema de archivos del cluster
6. Creación de zonas no globales y clusters de zona
En esta sección se proporcionan las siguientes directrices para planificar la administración de volúmenes de la configuración del cluster:
El software de Oracle Solaris Cluster utiliza software de administrador de volúmenes para agrupar discos en grupos de dispositivos que luego se pueden administrar como una unidad. El software de Oracle Solaris Cluster admite el software de Solaris Volume Manager. Debe instalar el software de Solaris Volume Manager en todos los nodos con voto del cluster.
Consulte la documentación del administrador de volúmenes y Configuración del software de Solaris Volume Manager para obtener instrucciones sobre cómo instalar y configurar el software de administrador de volúmenes. Para obtener más información sobre el uso de la administración de volúmenes en una configuración de cluster, consulte Multihost Devices de Oracle Solaris Cluster Concepts Guide y Device Groups de Oracle Solaris Cluster Concepts Guide.
Tenga en cuenta las siguientes directrices generales al configurar los discos con el software del administrador de volúmenes:
RAID de software: el software de Oracle Solaris Cluster no admite el sistema RAID 5 de software.
Discos multihost reflejados: debe crear reflejos de todos los discos multihost en las unidades de expansión de discos. Consulte la sección Directrices para la creación de reflejos de discos multihost para obtener directrices sobre cómo crear reflejos de discos multihost. No es necesario que utilice el relfejo del software si el dispositivo de almacenamiento proporciona RAID de hardware, así como rutas redundantes a los dispositivos.
Raíz reflejada: el reflejo del disco raíz garantiza una alta disponibilidad, aunque no es necesario. Consulte la sección Directrices de creación de reflejos para obtener directrices sobre si se deben crear reflejos del disco raíz.
Denominación exclusiva: es posible que tenga volúmenes locales de Solaris Volume Manager que se usen como dispositivos en los que se montan los sistemas de archivos /global/.devices/node@ nodeid. En tal caso, el nombre de cada volumen local en el que se vaya a montar un sistema de archivos /global/.devices/node@ nodeid debe ser exclusivo en todo el cluster.
Listas de nodos: para garantizar la alta disponibilidad de un grupo de dispositivos, consiga que las listas de nodos de posibles maestros y su directiva de migración tras error sean idénticas a cualquier grupo de recursos asociado. O bien, si un grupo de recursos escalable utiliza más nodos que su grupo de dispositivos asociado, convierta la lista de nodos del grupo de recursos escalables en un superconjunto de la lista de nodos del grupo de dispositivos. Consulte la información de planificación de grupos de recursos de Oracle Solaris Cluster Data Services Planning and Administration Guide para obtener información sobre las listas de nodos.
Discos multihost: debe conectar (asignar a un puerto) todos los dispositivos que se usan para construir un grupo de dispositivos para todos los nodos que se configuran en la lista de nodos para ese grupo de dispositivos. El software de Solaris Volume Manager puede verificar esta conexión automáticamente cuando se agregan los dispositivos a un conjunto de discos.
Discos de reserva activa: puede utilizar este tipo de discos para aumentar la disponibilidad, aunque su uso no es necesario.
Consulte la documentación del administrador de volúmenes para obtener recomendaciones acerca del diseño de disco y restricciones adicionales.
Tenga en cuenta los siguientes puntos al planificar las configuraciones de Solaris Volume Manager:
Nombres de volúmenes locales: el nombre de cada volumen local de Solaris Volume Manager en el que se monta un sistema de archivos de dispositivos globales, /global/.devices/node@nodeid, debe ser único en todo el cluster. Además, el nombre no puede ser un nombre de ID de dispositivo.
Mediadores de dos cadenas: una cadena de disco está formada por un contenedor de discos, sus discos físicos, cables del contenedor al host o los hosts, y las tarjetas del adaptador de interfaz. Cada conjunto de discos configurado con exactamente dos cadenas de discos y controlado exactamente por dos hosts de Oracle Solaris se denomina conjunto de discos de dos cadenas. Un conjunto de discos de este tipo debe tener configurados mediadores de dos cadenas de Solaris Volume Manager. Tenga en cuenta las siguientes reglas al configurar mediadores de dos cadenas:
Debe configurar cada conjunto de discos con dos o tres hosts que actúen como mediadores.
Debe utilizar los hosts que puedan controlar un conjunto de discos como mediadores de ese conjunto de discos. Si dispone de un cluster de campus, también puede configurar un tercer nodo o un host que no esté en cluster en la red de clusters como tercer host mediador para mejorar la disponibilidad.
No se pueden configurar mediadores para los conjuntos de discos que no cumplan los requisitos de dos cadenas y dos hosts.
Consulte la página del comando man mediator(7D) para obtener más información.
Se requiere el registro para los sistemas de archivos del cluster UFS. El software de Oracle Solaris Cluster admite el registro de Oracle Solaris UFS.Consulte la página del comando man mount_ufs(1M) para obtener más información.
Solaris Volume Manager admite ambos tipos de registros de archivos del sistema.
En esta sección se proporcionan las siguientes directrices para planificar la creación de reflejos de la configuración del cluster:
La creación de reflejos de todos los discos multihost en la configuración de Oracle Solaris Cluster permite que la configuración tolere errores de un solo dispositivo. El software de Oracle Solaris Cluster requiere la creación de reflejos de todos los discos multihost en todas las unidades de expansión. No es necesario que utilice el relfejo del software si el dispositivo de almacenamiento proporciona RAID de hardware, así como rutas redundantes a los dispositivos.
Tenga en cuenta los siguientes puntos al crear reflejos de discos multihost:
Unidades de expansión de discos independientes: cada subreflejo de un determinado reflejo debe residir en una unidad de expansión multihost diferente.
Espacio en el disco: el reflejo dobla la cantidad necesaria de espacio en el disco.
Reflejos en tres direcciones: el software de Solaris Volume Manager admite los reflejos en tres direcciones. Sin embargo, Oracle Solaris Cluster sólo requiere reflejos bidireccionales.
Diferencia en el tamaño de los dispositivos: si crea reflejos de un dispositivo con un tamaño diferente, la capacidad de creación de reflejos se limita al tamaño del subreflejo más pequeño.
Para obtener más información sobre los discos multisistema, consulte Multihost Devices de Oracle Solaris Cluster Concepts Guide.
Para obtener la máxima disponibilidad, cree reflejos de root (/), /usr, /var, /opt y swap en los discos locales. Sin embargo, no es necesario crear reflejos del disco raíz para el software de Oracle Solaris Cluster.
Antes de decidir si crear un reflejo del disco raíz, tenga en cuenta los riesgos, la complejidad, los costos y el tiempo de servicio de varias alternativas que tratan sobre del disco raíz. Ninguna estrategia de creación de un único reflejo funciona para todas las configuraciones. Puede que desee tener en cuenta la solución preferida de su representante local de servicio de Oracle en el momento de decidir si crea un reflejo del disco raíz.
Consulte la documentación de administradores de volúmenes y Configuración del software de Solaris Volume Manager para obtener instrucciones acerca de cómo crear un reflejo del disco raíz.
Tenga en cuenta los siguientes puntos al decidir si desea crear reflejos del disco raíz.
Disco de inicio: puede configurar el reflejo para que sea un disco raíz de inicio. A continuación, puede efectuar el inicio desde el disco raíz cuando el disco raíz principal presente errores.
Complejidad: crear un reflejo del disco raíz agrega complejidad a la administración del sistema. Crear un reflejo del disco raíz también complica el inicio en el modo de un solo usuario.
Copias de seguridad: independientemente de si se crean reflejos del disco raíz, también debe efectuar copias de seguridad de la raíz con frecuencia. La creación de reflejos no basta para protegerle de los errores de administración. Sólo un plan de copia de seguridad permite restaurar los archivos que se hayan modificado o eliminado accidentalmente.
Dispositivos de quórum: no utilice un disco que se haya configurado como dispositivo de quórum para crear reflejos de un disco raíz.
Quórum: en el software de Solaris Volume Manager, en situaciones de error en las que se pierde el quórum de bases de datos de estado, no puede reiniciar el sistema hasta que se lleve a cabo el mantenimiento. Consulte la documentación de Solaris Volume Manager para obtener más información sobre las bases de datos de estado y las réplicas de las bases de datos de estado.
Controladores independientes: para obtener la más alta disponibilidad, es necesario crear reflejos del disco raíz en un controlador independiente.
Disco raíz secundarios: con un disco raíz reflejado, el disco raíz principal puede fallar, pero el trabajo puede continuar en el disco raíz secundario (reflejo). Más adelante, es posible que el disco raíz principal vuelva a funcionar, por ejemplo, después de un ciclo de energía o de errores transitorios de E/S. Luego, los inicios subsiguientes se realizan mediante el uso del disco raíz principal que se especifica para el parámetro eeprom(1M) boot-device. En esta situación, no se produce ninguna reparación manual de tareas, pero la unidad empieza a funcionar lo suficientemente bien como para iniciar. Con el software de Solaris Volume Manager, se produce una nueva sincronización. La nueva sincronización requiere un paso manual cuando la unidad vuelve a estar en funcionamiento.
Si se han realizado cambios en algunos archivos del disco raíz secundario (reflejo), éstos no se reflejan en el disco raíz principal durante el inicio. Esta condición genera un subreflejo obsoleto. Por ejemplo, se perderían los cambios en el archivo /etc/system. Con el software de Solaris Volume Manager, es posible que algunos de los comandos administrativos hayan cambiado el archivo /etc/system durante el período en que el disco raíz principal estuvo fuera de servicio.
El programa de inicio no comprueba si el sistema se está iniciando desde un reflejo o desde un dispositivo físico subyacente. La creación de reflejos se vuelve activa en una parte del proceso de inicio, una vez que se cargan los volúmenes. Por lo tanto, antes de este punto, el sistema puede padecer problemas por subreflejos obsoletos.