Las configuraciones de alta disponibilidad de Oracle Hierarchical Storage Manager and StorageTek QFS Software están diseñadas para mantener servicios de archivado y sistemas de archivos ininterrumpidos. En una solución de alta disponibilidad, el software Oracle Hierarchical Storage Manager o QFS está integrado con software de Oracle Solaris Cluster, hardware redundante y comunicaciones redundantes. De modo que si falla un sistema de host o un componente, o si los administradores lo retiran de servicio, los servicios de Oracle HSM iniciarán automáticamente el failover en un host alternativo al que puedan acceder los usuarios y las aplicaciones. Por lo tanto, las configuraciones de alta disponibilidad minimizan los tiempos de inactividad debido a errores del sistema y del equipo.
Sin embargo, las configuraciones de alta disponibilidad son complejas y se deben diseñar e implementar cuidadosamente para evitar interacciones imprevistas y, posiblemente, daños en los datos. Este capítulo comienza con una explicación de las configuraciones admitidas. Estudie esta sección y seleccione la configuración que mejor se ajuste a sus requisitos de disponibilidad. En las secciones subsiguientes, se explicará cómo realizar la configuración seleccionada.
Tenga en cuenta que no puede mezclar arquitecturas de software en una configuración de Oracle Solaris Cluster. Todos los nodos deben usar la arquitectura SPARC, la arquitectura x86-64(únicamente en Solaris 11.1) o la arquitectura x86 de 32 bits (Solaris 10 y anteriores).
En soluciones multihost en clusters, las interacciones entre los sistemas de archivos, las aplicaciones, los sistemas operativos, el software de agrupación en clusters y el almacenamiento deben ser controlados cuidadosamente para garantizar la integridad de los datos almacenados. Para minimizar la complejidad y los riesgos potenciales, las configuraciones de alta disponibilidad admitidas de Oracle HSM se adaptan a cuatro conjuntos específicos de requisitos de implementación:
HA-COTC, un sistema de archivos compartido QFS con servidores de metadatos de alta disponibilidad
HA-SAM, una configuración de sistemas de archivos compartidos QFS de archivado y alta disponibilidad
La configuración de QFS de alta disponibilidad (HA-QFS) garantiza que un sistema de archivos QFS independiente y no compartido, permanezca accesible en caso de un error del host. El sistema de archivos está configurado en un cluster de dos nodos que el software de Solaris Cluster gestiona como recurso de tipo SUNW.HAStoragePlus. En cualquier momento determinado, un solo nodo monta el sistema de archivos QFS. Si el nodo que monta el sistema de archivos falla, el software de agrupación en clusters inicia automáticamente el failover y vuelve a montar el sistema de archivos en el nodo restante.
Los clientes acceden a los datos mediante recursos compartidos de SMB/CIFS, NFS de alta disponibilidad (HA-NFS) o sistemas de archivos de red (NFS), con el nodo de cluster activo que actúa como servidor de archivos.
Para obtener instrucciones de implementación, consulte Sistemas de archivos QFS no compartidos y de alta disponibilidad.
La configuración de clientes de alta disponibilidad fuera del cluster (HA-COTC) mantiene la disponibilidad de un servidor de metadatos QFS de modo que los clientes del sistema de archivos QFS puedan continuar accediendo a los datos, incluso si falla el servidor. El sistema de archivos se comparte. Los servidores de metadatos QFS activos y posibles están alojados en un cluster de dos nodos gestionado por el software Solaris Cluster. Un recurso de alta disponibilidad de Oracle HSM del tipo SUNW.qfs gestiona el failover para los servidores del sistema de archivos compartido dentro del cluster. Todos los clientes se alojan fuera del cluster. Los servidores en clusters garantizan la disponibilidad de los metadatos, emiten licencias de E/S y mantienen la coherencia del sistema de archivos.
Si el nodo que aloja el servidor de metadatos activo falla, el software Solaris Cluster activa automáticamente el MDS posible en el nodo activo e inicia el failover. El sistema de archivos QFS es compartido, de modo que ya está montado en el nodo del servidor de metadatos recientemente activado y permanece montado en los clientes. Los clientes continúan recibiendo actualizaciones de metadatos y concesiones de E/S, de modo que el sistema de archivos puede continuar sin interrupciones.
Las configuraciones de HA-COTC deben usar sistemas de archivos ma de alto rendimiento con dispositivos de metadatos mm físicamente separados y dispositivos de datos mr. No se admiten los sistemas de archivos ms de propósito general ni los dispositivos md.
Puede utilizar estándar un sistema de archivos de red (NFS) o SMB/CIFS para compartir sistemas de archivos HA-COTC con clientes que no ejecutan Oracle HSM. No obstante, HA-NFS no se admite.
Para obtener instrucciones de implementación, consulte Sistemas de archivos compartidos QFS de alta disponibilidad, clientes fuera del cluster.
La configuración de Oracle Hierarchical Storage Manager de alta disponibilidad (HA-SAM) mantiene la disponibilidad de un sistema de archivos de almacenamiento mediante la garantía de que el servidor de metadatos de QFS y la aplicación Oracle Hierarchical Storage Manager continuarán funcionando, incluso si falla el host del servidor. El sistema de archivos se comparte entre servidores de metadatos QFS activos y posibles alojados en un cluster de dos nodos gestionado por el software Solaris Cluster. Un recurso de alta disponibilidad de Oracle HSM del tipo SUNW.qfs gestiona el failover para los servidores.
Si el nodo de metadatos activo de Oracle HSM falla, el software de agrupación en clusters activa automáticamente el nodo del servidor de metadatos e inicia el failover. Dado que el sistema de archivos QFS es compartido y ya está montado en todos los nodos, el acceso a los datos y a los metadatos permanece ininterrumpido.
Los clientes acceden a los datos mediante recursos compartidos de SMB/CIFS, NFS o sistemas de archivos de red de alta disponibilidad (HA-NFS), con el nodo de cluster activo que actúa como servidor de archivos.
Para obtener instrucciones, consulte Sistemas de archivado compartidos de Oracle HSM de alta disponibilidad,.
La configuración de Solaris Cluster-Oracle Real Application Cluster (SC-RAC) admite soluciones de bases de datos de alta disponibilidad que usan sistemas de archivos QFS. El software RAC coordina las solicitudes de E/S, distribuye la carga de trabajo y mantiene un conjunto único y coherente de archivos de base de datos para varias instancias de Oracle Database que se ejecutan en los nodos de un cluster. En una configuración de SC-RAC, Oracle Database, Oracle Real Application Cluster (RAC) y el software QFS se ejecutan en dos o más nodos del cluster. El software Solaris Cluster gestiona el cluster como recurso de tipo SUNW.qfs. Un nodo está configurado como servidor de metadatos (MDS) de un sistema de archivos compartido QFS. Los nodos restantes están configurados como servidores posibles de metadatos que comparten el sistema de archivos como clientes. Si el nodo de metadatos activo falla, el software Solaris Cluster activa automáticamente un servidor de metadatos posible en un nodo activo e inicia el failover. Dado que el sistema de archivos QFS es compartido y ya está montado en todos los nodos, el acceso a los datos permanece ininterrumpido.
Para configurar un sistema de archivos QFS de alta disponibilidad (HA-QFS), deberá configurar dos hosts idénticos en un cluster de Solaris de dos nodos, gestionado como recurso de tipo SUNW.HAStoragePlus. A continuación, deberá configurar un sistema de archivos QFS no compartido en ambos nodos. Solamente un nodo montará el sistema de archivos en un determinado momento. Sin embargo, si falla un nodo, el software de agrupación en clusters iniciará automáticamente el failover y volverá a montar el sistema de archivos en el nodo superviviente.
Para configurar un sistema de archivos QFS de alta disponibilidad (HA-QFS), realice lo siguiente:
Creación de sistemas de archivos QFS no compartidos en ambos nodos del cluster
Configuración del sistema de archivos QFS de alta disponibilidad
Si es necesario, configure el uso compartido del sistema de archivos de red de alta disponibilidad (HA-NFS)
En la Guía del servicio de datos de Oracle Solaris Cluster Data para el sistema de archivos de red (NFS)que se incluye en la biblioteca de documentación en línea Oracle Solaris Cluster se incluyen los procedimientos detallados para configurar HA-NFS.
Inicie sesión en uno de los nodos del cluster como root.
En el ejemplo, los hosts son qfs1mds-node1 y qfs1mds-node2. Iniciamos sesión en el host qfs1mds-node1:
[qfs1mds-node1]root@solaris:~#
Configure el sistema de archivos QFS deseado en el host, pero no lo monte.
Para configurar el sistema de archivos siga las instrucciones en Configurar un sistema de archivos ms de propósito general o Configurar un sistema de archivos ma de alto rendimiento. La configuración de HA-QFS no admite sistemas de archivos compartidos QFS.
Inicie sesión en el nodo de cluster restante como root.
En el ejemplo, iniciamos sesión en el host qfs1mds-node2 mediante el uso de ssh:
[qfs1mds-node1]root@solaris:~# ssh root@qfs1mds-node2 Password: [qfs1mds-node2]root@solaris:~#
Configure un sistema de archivos QFS idéntico en el segundo nodo.
A continuación, configure el sistema de archivos QFS de alta disponibilidad.
Siga estos pasos:
Inicie sesión en uno de los nodos del cluster como root.
En el ejemplo, los hosts son qfs1mds-node1 y qfs1mds-node2. Iniciamos sesión en el host qfs1mds-node1:
[qfs1mds-node1]root@solaris:~#
Si aún no lo ha hecho, defina el tipo de recurso SUNW.HAStoragePlus para el software Solaris Cluster. Use el comando clresourcetype register SUNW.HAStoragePlus.
HAStoragePlus es el tipo de recurso de Solaris Cluster que define y gestiona las dependencias entre grupos de dispositivos de disco, sistemas de archivos en clusters y sistemas de archivos locales. Coordina el inicio de los servicios de datos posteriores a los failovers, de modo que todos los componentes estén listos cuando el servicio intente reiniciarse. Para obtener más información, consulte la página del comando man SUNW.HAStoragePlus.
[qfs1mds-node1]root@solaris:~# clresourcetype register SUNW.HAStoragePlus [qfs1mds-node1]root@solaris:~#
Cree un nuevo recurso de Solaris Cluster del tipo SUNW.HAStoragePlus y un nuevo grupo de recursos que lo contenga. Use el comando /usr/global/bin/clresource create -g resource-group -t SUNW.HAStoragePlus -x FilesystemMountPoints=/global/mount-point -x FilesystemCheckCommand=/bin/true QFS-resource, donde:
resource-group es el nombre que eligió para el grupo de recursos del sistema de archivos.
mount-point es el directorios donde está montado el sistema de archivos QFS.
QFS-resource es el nombre que eligió para el recurso SUNW.HAStoragePlus.
En el ejemplo, creamos el grupo de recursos qfsrg con el directorio de punto de montaje /global/qfs1 y el recurso SUNW.HAStoragePlus haqfs (tenga en cuenta que el siguiente comando se introduce como una sola línea, los saltos de línea se identifican por el carácter de barra diagonal inversa):
[qfs1mds-node1]root@solaris:~# clresource create -g qfsrg -t SUNW.HAStoragePlus \ -x FilesystemMountPoints=/global/hsmqfs1/qfs1 \ -x FilesystemCheckCommand=/bin/true haqfs [qfs1mds-node1]root@solaris:~#
Muestre los nodos en el cluster. Use el comando clresourcegroup status.
En el ejemplo, los nodos del host del sistema de archivos QFS son qfs1mds-1 y qfs1mds-2. El nodo qfs1mds-1 es Online, de modo que es el nodo principal que monta el sistema de archivos y aloja el grupo de recursos qfsrg:
[qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- --------- --------- ------ qfsrg qfs1mds-1 No Online qfs1mds-2 No Offline [qfs1mds-node1]root@solaris:~#
Asegúrese de que el grupo de recursos realice el failover correctamente mediante el movimiento del grupo de recursos al nodo secundario. Use el comando de Solaris Cluster clresourcegroup switch -n node2 group-name, donde node2 es el nombre del nodo secundario y group-name es el nombre que eligió para el grupo de recursos de HA-QFS. A continuación, use clresourcegroup status para comprobar el resultado.
En el ejemplo, movemos el grupo de recursos haqfs a qfs1mds-node2 y confirmamos que el grupo de recursos estará en línea en el nodo especificado:
[qfs1mds-node1]root@solaris:~# clresourcegroup switch -n qfs1mds-node2 qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- --------- --------- ------ qfsrg qfs1mds-1 No Offline qfs1mds-2 No Online [qfs1mds-node1]root@solaris:~#
Mueva el grupo de recursos nuevamente al nodo principal. Use el comando de Solaris Cluster clresourcegroup switch -n node1 group-name, donde node1 es el nombre del nodo principal y group-name es el nombre que eligió para el grupo de recursos de HA-QFS. A continuación, use clresourcegroup status para comprobar el resultado.
En el ejemplo, movemos correctamente el grupo de recursos qfsrg nuevamente a qfs1mds-node1:
[qfs1mds-node1]root@solaris:~# clresourcegroup switch -n qfs1mds-node1 qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsrg qfs1mds-node1 No Online qfs1mds-node2 No Offline [qfs1mds-node1]root@solaris:~#
Si necesita configurar el uso compartido de un sistema de archivos de red de alta disponibilidad (HA-NFS), hágalo ahora. Para obtener instrucciones, consulte la Guía del servicio de datos de Oracle Solaris Cluster para el sistema de archivos de red (NFS) que se incluye en la biblioteca de la documentación en línea de Oracle Solaris Cluster.
Si planea usar la función de base de datos de banda lateral, vaya a Configuración de la base de datos de informes.
En caso contrario, vaya a Configuración de notificaciones y registro.
La configuración de los clientes de alta disponibilidad fuera del cluster (HA-COTC) es un sistema de archivos compartido QFS no de almacenamiento que aloja el servidor de metadatos (MDS) crucial en los nodos de un cluster de alta disponibilidad gestionado por el software de Solaris Cluster. Esto proporciona protección contra failover para metadatos de QFS y concesiones de acceso a archivos, de modo que los clientes del sistema de archivos no pierdan el acceso a los datos si un servidor falla. Sin embargo, los clientes del sistema de archivos y los dispositivos de datos permanecen fuera del cluster, de modo que Solaris Cluster no compite con el software QFS por el control de los datos compartidos de QFS.
Para configurar un sistema de archivos HA-COTC, realice las siguientes tareas:
Creación de archivos de hosts locales en servidores QFS y clientes fuera del cluster HA-COTC
Configuración de un servidor de metadatos QFS activo en el nodo de cluster HA-COTC principal
Configuración de un servidor de metadatos QFS posible en el nodo de cluster HA-COTC secundario
Configurar el failover de los servidores de metadatos HA-COTC
Si es necesario, configure los recursos compartidos del sistema de archivos de red (NFS), como se describe en Acceso a sistemas de archivos desde varios hosts mediante el uso de NFS y SMB/CIFS. El NFS de alta disponibilidad (HA-NFS) no se admite.
En un sistema de archivos compartido QFS, debe configurar un archivo de hosts en los servidores de metadatos, de modo que todos los hosts puedan acceder a los metadatos para el sistema de archivos. El archivo de hosts se almacena junto con el archivo mcf en el directorio /etc/opt/SUNWsamfs/. Durante la creación inicial de un sistema de archivos compartido, el comando sammkfs -S configura el uso compartido mediante los parámetros de configuración almacenados en este archivo. Por lo tanto, créelo ahora, utilizando el procedimiento que se indica a continuación.
Inicie sesión en el nodo principal del cluster HA-COTC como root.
En el ejemplo, los hosts son qfs1mds-node1 y qfs1mds-node2. Iniciamos sesión en el host qfs1mds-node1:
[qfs1mds-node1]root@solaris:~#
Muestre la configuración del cluster. Use el comando /usr/global/bin/cluster show. Ubique el registro para cada Node Name y, a continuación, observe privatehostname, el nombre de Transport Adapter y la propiedad ip_address de cada adaptador de red.
Los resultados de los comandos pueden ser muy largos, por lo tanto, en los ejemplos de abajo, las visualizaciones largas se abrevian mediante marcas de elipsis de tres puntos (...).
En los ejemplos, cada nodo tiene dos interfaces de red, qfe3 y hme0:
Los adaptadores hme0 tienen direcciones IP en la red privada que usa el cluster para comunicaciones internas entre nodos. El software Solaris Cluster asigna un nombre de host privado que corresponde a cada dirección privada.
De forma predeterminada, el nombre del host privado del nodo principal es clusternode1-priv y el nombre del host privado del nodo secundario es clusternode2-priv.
Los adaptadores qfe3 tienen direcciones IP públicas y nombres de host públicos, qfs1mds-node1 and qfs1mds-node2, que el cluster usa para transporte de datos.
[qfs1mds-node1]root@solaris:~# cluster show ... === Cluster Nodes === Node Name: qfs1mds-node1... privatehostname: clusternode1-priv... Transport Adapter List: qfe3, hme0... Transport Adapter: qfe3... Adapter Property(ip_address): 172.16.0.12... Transport Adapter: hme0... Adapter Property(ip_address): 10.0.0.129... Node Name: qfs1mds-node2... privatehostname: clusternode2-priv... Transport Adapter List: qfe3, hme0... Adapter Property(ip_address): 172.16.0.13... Transport Adapter: hme0 Adapter Property(ip_address): 10.0.0.122
Con un editor de texto, cree el archivo /etc/opt/SUNWsamfs/hosts.family-set-name en el servidor de metadatos, donde family-set-name es el nombre del conjunto de familias del sistema de archivos.
En el ejemplo, creamos el archivo hosts.qfs1 mediante el editor de texto vi. Agregamos algunos encabezados opcionales para mostrar las columnas en la tabla de hosts, cada línea comienza con un signo de numeral (#), lo que indica un comentario:
[qfs1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1 # /etc/opt/SUNWsamfs/hosts.qfs1 # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ----------
En la primera columna de la tabla, introduzca los nombres de host de los nodos de servidor de metadatos principal y secundario, seguidos de algunos espacios. Coloque cada entrada en una línea separada.
En un archivo de hosts, las líneas son filas (registros) y los espacios son separadores de columnas (campos). En el ejemplo, la columna Host Name de las primeras dos filas contiene los valores qfs1mds-node1 y qfs1mds-node2, los nombres de host de los nodos de cluster que alojan los servidores de metadatos para el sistema de archivos:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 qfs1mds-node2
En la segunda columna de cada línea, comience proporcionando información de Network Interface para el host Host Name. Introduzca cada nombre de host privado de Solaris Cluster del nodo de cluster HA-COTC o la dirección de red privada seguida de una coma.
Los nodos de servidor HA-COTC usan nombres de host privados para comunicaciones de servidor a servidor dentro del cluster de alta disponibilidad. En el ejemplo, usamos los nombres de host privados clusternode1-priv y clusternode2-priv, que son los nombres predeterminados asignados por el software Solaris Cluster:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv, qfs1mds-node2 clusternode2-priv,
Después de la coma que aparece en la segunda columna de cada línea, introduzca un nombre de host público virtual para el servidor de metadatos activo, seguido por espacios.
Los nodos del servidor HA-COTC usan una red de datos públicos para comunicarse con los clientes, todos residen fuera del cluster. Dado que la dirección IP y el nombre de host del servidor de metadatos activo cambia durante el failover (de qfs1mds-node1 a qfs1mds-node2 y viceversa), usamos un nombre de host virtual, qfs1mds, para ambos. Posteriormente, configuraremos el software de Solaris Cluster para que siempre enrute las solicitudes de qfs1mds al servidor de metadatos activo:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv,qfs1mds qfs1mds-node2 clusternode2-priv,qfs1mds
En la tercera columna de cada línea, introduzca el número ordinal del servidor (1 para el servidor de metadatos activo y 2 para el servidor de metadatos posible), seguido por espacios.
En este ejemplo, hay solamente un servidor de metadatos, el nodo principal, qfs1mds-node1, es el servidor de metadatos activo, de modo que es el ordinal 1 y el nodo secundario, qfs1mds-node2, es el ordinal 2:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv,qfs1mds 1 qfs1mds-node2 clusternode2-priv,qfs1mds 2
En la cuarta columna de cada línea, introduzca 0 (cero), seguido por espacios.
El valor 0 (cero), - (guión) o en blanco en la cuarta columna indica que el host está on, es decir, configurado con acceso al sistema de archivos compartido. El valor 1 (numeral uno) indica que el host está off, es decir, configurado pero sin acceso al sistema de archivos (para obtener información sobre el uso de estos valores para administrar sistemas de archivos compartidos, consulte la página del comando man samsharefs).
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv,qfs1mds 1 0 qfs1mds-node2 clusternode2-priv,qfs1mds 2 0
En la quinta columna de la línea del nodo principal, introduzca la palabra clave server.
La palabra clave server identifica el servidor de metadatos activo predeterminado:
# Server On/ Additional
#Host Name Network Interface Ordinal Off Parameters
#------------ ----------------------------- ------- --- ----------
qfs1mds-node1 clusternode1-priv,qfs1mds 1 0 server
qfs1mds-node2 clusternode2-priv,qfs1mds 2 0
Agregue una línea para cada host de cliente; para ello, configure el valor Server Ordinal en 0. Luego, guarde el archivo y cierre el editor.
El ordinal de servidor 0 identifica el host como cliente en lugar de como servidor. Los clientes HA-COTC no son miembros del cluster y, por lo tanto, se comunican únicamente por la red de datos pública del cluster. Solamente tienen direcciones IP públicas. En el ejemplo, agregamos dos clientes, qfs1client1 y qfs1client2, mediante el uso de sus direcciones IP públicas, 172.16.0.133 y 172.16.0.147 en lugar de nombres de host:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv,qfs1mds 1 0 server qfs1mds-node2 clusternode2-priv,qfs1mds 2 0 qfs1client1 172.16.0.133 0 0 qfs1client2 172.16.0.147 0 0 :wq [qfs1mds-node1]root@solaris:~#
Coloque una copia del archivo /etc/opt/SUNWsamfs/hosts.family-set-name global en el servidor de metadatos posible QFS (el segundo nodo del cluster HA-COTC).
A continuación, cree archivos de hosts locales en los servidores QFS y en los clientes que están fuera del cluster HA-COTC.
En una configuración de alta disponibilidad que comparte un sistema de archivos con clientes fuera del cluster, debe garantizar que los clientes solamente se comuniquen con los servidores de sistemas de archivos mediante el uso de la red de datos pública, definida por el software Solaris Cluster. Para ello, se usan los archivos de host locales de QFS especialmente configurados para enrutar el tráfico de red de forma selectiva entre clientes y múltiples interfaces de red en el servidor.
Cada host del sistema de archivos identifica las interfaces de red para otros hosts; para ello, comprueban primero el archivo /etc/opt/SUNWsamfs/hosts.family-set-name en el servidor de metadatos. Luego, verifica su propio y específico archivo /etc/opt/SUNWsamfs/hosts.family-set-name.local. Si no hay un archivo de hosts local, el host utiliza las direcciones de interfaz especificadas en el archivo de hosts global en el orden especificado en el archivo global. Pero, si hay un archivo de hosts local, el host lo compara con el archivo global y utiliza sólo aquellas interfaces que aparecen en ambos archivos en el orden especificado en el archivo local. Al utilizar direcciones diferentes en organizaciones diferentes en cada archivo, puede controlar las interfaces utilizadas por los diferentes hosts.
Para configurar archivos de hosts locales, utilice el procedimiento que se describe a continuación:
Inicie sesión en el nodo principal del cluster HA-COTC como root.
En el ejemplo, los hosts son qfs1mds-node1 y qfs1mds-node2. Iniciamos sesión en el host qfs1mds-node1:
[qfs1mds-node1]root@solaris:~#
Cree un archivo de hosts local en cada uno de los servidores de metadatos activos y posibles. Utilice la ruta y el nombre de archivo /etc/opt/SUNWsamfs/hosts.family-set-name.local, donde family-set-name es el identificador del equipo del sistema de archivos compartido. Sólo incluya las interfaces de las redes que desea que utilicen los servidores activo y posible.
En nuestro ejemplo, deseamos que los servidores de metadatos activos y posibles se comuniquen entre sí por la red privada y con los clientes mediante la red pública. De modo que el archivo de hosts local en los servidores activos y posibles, hosts.qfs1.local, muestra solamente las direcciones de cluster privadas para los servidores activos y posibles:
[qfs1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1.local # /etc/opt/SUNWsamfs/hosts.qfs1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv 1 0 server qfs1mds-node2 clusternode2-priv 2 0 qfs1client1 172.16.0.133 0 0 qfs1client2 172.16.0.147 0 0 :wq [qfs1mds-node1]root@solaris:~# ssh root@qfs1mds-node2 Password:
[qfs1mds-node2]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1.local # /etc/opt/SUNWsamfs/hosts.qfs1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds-node1 clusternode1-priv 1 0 server qfs1mds-node2 clusternode2-priv 2 0 qfs1client1 172.16.0.133 0 0 qfs1client2 172.16.0.147 0 0 :wq [qfs1mds-node2]root@solaris:~# exit [qfs1mds-node1]root@solaris:~#
Mediante un editor de texto, cree un archivo de hosts local en cada uno de los clientes. Utilice la ruta y el nombre de archivo /etc/opt/SUNWsamfs/hosts.family-set-name.local, donde family-set-name es el identificador del equipo del sistema de archivos compartido. Sólo incluya las interfaces de las redes que desea que utilicen los clientes. Luego, guarde el archivo y cierre el editor.
En el ejemplo, utilizamos el editor vi. Deseamos que los clientes se comuniquen solamente con los servidores u únicamente mediante la red de datos pública. De modo que el archivo incluye únicamente el nombre de host virtual para el servidor de metadatos activo, qfs1mds. El software Solaris Cluster enrutará las solicitudes para qfs1mds a cualquier nodo de servidor activo:
[qfs1mds-node1]root@solaris:~# ssh root@qfsclient1 Password: [qfs1client1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1.local # /etc/opt/SUNWsamfs/hosts.qfs1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds qfs1mds 1 0 server :wq qfs1client1]root@solaris:~# exit [qfs1mds-node1]root@solaris:~# ssh root@qfs1client2 Password: [qfs1client2]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1.local # /etc/opt/SUNWsamfs/hosts.qfs1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- qfs1mds qfs1mds 1 0 server :wq [qfs1client2]root@solaris:~# exit [qfs1mds-node1]root@solaris:~#
Luego, configure un servidor de metadatos QFS activo en el nodo principal del cluster HA-COTC.
Para configurar el servidor de metadatos activo, realice las siguientes tareas:
Creación de un sistema de archivos QFS de alto rendimiento en el nodo HA-COTC principal
Montaje del sistema de archivos QFS en el nodo HA-COTC principal
Seleccione el nodo de cluster que actuará como nodo principal para el cluster HA-COTC y el servidor de metadatos activo para el sistema de archivos compartido QFS. Inicie sesión como usuario root.
En el ejemplo, qfs1mds-node1 es el nodo principal y el servidor de metadatos activo:
[qfs1mds-node1]root@solaris:~#
Seleccione los dispositivos de almacenamiento global que se usarán para el sistema de archivos QFS. Use el comando de Solaris Cluster /usr/global/bin/cldevice list -v.
El software Solaris Cluster asigna identificadores de dispositivo (DID) únicos a todos los dispositivos que se conectan a los nodos de cluster. Se puede acceder a los dispositivos globales desde todos los nodos del cluster, y se puede acceder a los dispositivos locales únicamente desde los hosts que los montan. Los dispositivos globales permanecen accesibles después del failover. Los dispositivos locales no.
En el ejemplo, tenga en cuenta que no se puede acceder a los dispositivos d1, d2, d7 y d8 desde ambos nodos. Por lo tanto, seleccionamos entre los dispositivos d3, d4 y d5 cuando se configura el sistema de archivos compartido QFS de alta disponibilidad:
[qfs1mds-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 qfs1mds-node1:/dev/rdsk/c0t0d0 d2 qfs1mds-node1:/dev/rdsk/c0t6d0 d3 qfs1mds-node1:/dev/rdsk/c1t1d0 d3 qfs1mds-node2:/dev/rdsk/c1t1d0 d4 qfs1mds-node1:/dev/rdsk/c1t2d0 d4 qfs1mds-node2:/dev/rdsk/c1t2d0 d5 qfs1mds-node1:/dev/rdsk/c1t3d0 d5 qfs1mds-node2:/dev/rdsk/c1t3d0 d6 qfs1mds-node2:/dev/rdsk/c0t0d0 d7 qfs1mds-node2:/dev/rdsk/c0t1d0
En el nodo principal seleccionado, creamos un sistema de archivos ma de alto rendimiento que usa dispositivos de datos md o mr. En un editor de texto, abra el archivo /etc/opt/SUNWsamfs/mcf.
En el ejemplo, configuramos el sistema de archivos qfs1. Configuramos el dispositivo d3 como dispositivo de metadatos (tipo de equipo mm) y usamos d4 y d5 como dispositivos de datos (tipo de equipo mr):
[qfs1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ---------------- qfs1 100 ma qfs1 - /dev/did/dsk/d3s0 101 mm qfs1 - /dev/did/dsk/d4s0 102 mr qfs1 - /dev/did/dsk/d5s1 103 mr qfs1 -
En el archivo /etc/opt/SUNWsamfs/mcf, introduzca el parámetro shared en la columna Additional Parameters de la entrada del sistema de archivos. Guarde el archivo.
[qfs1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ---------------- qfs1 100 ma qfs1 - shared /dev/did/dsk/d3s0 101 mm qfs1 - /dev/did/dsk/d4s0 102 mr qfs1 - /dev/did/dsk/d5s1 103 mr qfs1 - :wq [qfs1mds-node1]root@solaris:~#
Revise el archivo mcf para detectar errores. Use el comando /opt/SUNWsamfs/sbin/sam-fsd y corrija los errores que encuentre.
El comando sam-fsd lee los archivos de configuración de Oracle HSM e inicializa los sistemas de archivos. Se detendrá si detecta un error. En el ejemplo, comprobamos el archivo mcf en el host qfs1mds-node1:
[qfs1mds-node1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1mds-node1]root@solaris:~#
Cree el sistema de archivos. Use el comando /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, donde family-set-name es el identificador de equipo del sistema de archivos.
El comando sammkfs lee los archivos hosts.family-set-name y mcf en el nodo principal, qfs1mds-node1, y crea un sistema de archivos compartido con las propiedades especificadas.
[qfs1mds-node1]root@solaris:~# sammkfs -S qfs1 Building 'qfs1' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [qfs1mds-node1]root@solaris:~#
Ahora excluya los dispositivos de datos del control del cluster.
De forma predeterminada, el software Solaris Cluster aísla los dispositivos de disco para uso exclusivo del cluster. Sin embargo, en configuraciones HA-COTC, únicamente los dispositivos de metadatos (mm) son parte del cluster. Los dispositivos de datos (mr) se comparten con los clientes del sistema de archivos fuera del cluster y están conectados directamente con los hosts de clientes. De modo que debe colocar los dispositivos de datos (mr) fuera del control del software del cluster. Esto se puede realizar de dos maneras:
Inicie sesión en el nodo principal del cluster HA-COTC y en el servidor de metadatos activo para el sistema de archivos compartido QFS. Inicie sesión como usuario root.
En el ejemplo, qfs1mds-node1 es el nodo principal y el servidor de metadatos activo:
[qfs1mds-node1]root@solaris:~#
Para cada dispositivo de datos (mr) definido en el archivo /etc/opt/SUNWsamfs/mcf, desactive el aislamiento. Use el comando cldevice set -p default_fencing=nofencing-noscrub device-identifier, donde device-identifier es el identificador de dispositivo que se muestra para el dispositivo en la primera columna del archivo mcf.
No desactive el aislamiento para los dispositivos de metadatos (mm). En las configuraciones HA-COTC, los dispositivos de metadatos QFS (mm) son parte del cluster, pero los dispositivos de datos QFS compartidos (mr) no lo son. Los dispositivos de datos están directamente conectados a los clientes fuera del cluster. Por este motivo, los dispositivos de datos HA-COTC (mr) se deben gestionar como dispositivos locales no gestionados por el software Solaris Cluster. De lo contrario, el software Solaris Cluster y QFS podrían trabajar con propósitos cruzados y dañar datos.
En los ejemplos de arriba, configuramos los dispositivos d4 y d5 como dispositivos de datos para el sistema de archivos qfs1. Por lo tanto, desactivamos el aislamiento de forma global para estos dispositivos (tenga en cuenta que los comandos a continuación se introducen como una sola línea, los saltos de línea se identifican por el carácter de barra diagonal inversa):
[qfs1mds-node1]root@solaris:~# cldevice set -p \ default_fencing=nofencing-noscrub d4 [qfs1mds-node1]root@solaris:~# cldevice set -p \ default_fencing=nofencing-noscrub d5
Luego, monte un sistema de archivos QFS en el nodo principal del cluster HA-COTC.
Inicie sesión en el nodo principal del cluster HA-COTC y en el servidor de metadatos activo para el sistema de archivos compartido QFS. Inicie sesión como usuario root.
En el ejemplo, qfs1mds-node1 es el nodo principal y el servidor de metadatos activo:
[qfs1mds-node1]root@solaris:~#
Coloque todos los dispositivos de datos (mr) que forman parte del sistema de archivos en un grupo de dispositivos localonly. Use el comando cldevicegroup set -d device-identifier-list -p localonly=true -n active-mds-node device-group, donde device-list es una lista de identificadores de dispositivos delimitada por comas, active-mds-node es el nodo principal donde reside normalmente el servidor de metadatos activo y device-group es el nombre que elige para el grupo de dispositivos.
En el siguiente ejemplo, colocamos los dispositivos de datos d4 y d5 (números de equipos mcf 102 y 103) en el grupo de dispositivos locales mdsdevgrp del nodo principal (tenga en cuenta que el comando a continuación se introduce como una sola línea, los saltos de línea se identifican por el carácter de barra diagonal inversa):
[qfs1mds-node1]root@solaris:~# cldevicegroup set -d d4,d5 -p localonly=true \ -n node1mds mdsdevgrp [qfs1mds-node1]root@solaris:~#
Luego, monte un sistema de archivos QFS en el nodo principal del cluster HA-COTC.
Inicie sesión en el nodo principal del cluster HA-COTC y en el servidor de metadatos activo para el sistema de archivos compartido QFS. Inicie sesión como usuario root.
En el ejemplo, qfs1mds-node1 es el nodo principal y el servidor de metadatos activo:
[qfs1mds-node1]root@solaris:~#
Realice una copia de seguridad del archivo /etc/vfstab del sistema operativo.
[qfs1mds-node1]root@solaris:~# cp /etc/vfstab /etc/vfstab.backup
Abra el archivo /etc/vfstab del sistema operativo en un editor de texto e inicie una línea para el nuevos sistema de archivos. Introduzca el nombre del sistema de archivos en la primera columna (Device to Mount), seguido de uno o más espacios.
En el ejemplo, usamos el editor de texto vi. Iniciamos una línea para el sistema de archivos qfs1:
[qfs1mds-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------ ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1 -
En la segunda columna del archivo /etc/vfstab (Device to fsck), escriba un guion (-) seguido de uno o más espacios.
El guion le indica al sistema operativo que omita la comprobación de integridad del sistema de archivos. Estas comprobaciones están diseñadas para sistemas de archivos UFS, en lugar de para sistemas de archivos SAMFS.
[qfs1mds-node1]root@solaris:~# vi /etc/vfstab
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ------------ ------ ---- ------- ---------------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs1 -
En la tercera columna del archivo /etc/vfstab, introduzca el punto de montaje del sistema de archivos relacionado con el cluster. Seleccione un subdirectorio que no se encuentre debajo del directorio raíz del sistema.
El montaje de un sistema de archivos QFS compartido inmediatamente debajo de la raíz puede ocasionar problemas de failover si se usa el tipo de recurso SUNW.qfs. En el ejemplo, definimos el punto de montaje en el cluster en /global/ha-cotc/qfs1:
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- -------------------- ------ ---- ------- --------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs1 - /global/ha-cotc/qfs1
Complete los campos restantes del registro de archivo /etc/vfstab tal como lo haría con cualquier sistema de archivos QFS compartido. Luego, guarde el archivo y cierre el editor.
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------------------- ------ ---- ------- -------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1 - /global/ha-cotc/qfs1 samfs - no shared :wq [qfs1mds-node1]root@solaris:~#
Cree un punto de montaje para el sistema de archivos compartido de alta disponibilidad.
El comando mkdir con la opción -p (parents) crea el directorio /global si aún no existe:
[qfs1mds-node1]root@solaris:~# mkdir -p /global/ha-cotc/qfs1
Monte el sistema de archivos compartido de alta disponibilidad en el nodo principal.
[qfs1mds-node1]root@solaris:~# mount /global/ha-cotc/qfs1
Luego, configure un servidor de metadatos QFS posible en el nodo secundario del cluster HA-COTC.
El nodo secundario del cluster de dos nodos actúa como servidor de metadatos posible. Un servidor de metadatos posible es un host que puede acceder a los dispositivos de metadatos y, por lo tanto, puede asumir las tareas de un servidor de metadatos. Por lo tanto, si el servidor de metadatos activo en el nodo principal falla, el software Solaris Cluster puede realizar el failover en el nodo secundario y activar el servidor de metadatos posible. Para configurar el servidor de metadatos posible, realice las siguientes tareas:
Creación de un sistema de archivos QFS de alto rendimiento en el nodo HA-COTC secundario
Montaje del sistema de archivos QFS en el nodo HA-COTC secundario
Inicie sesión en el nodo secundario del cluster HA-COTC como root.
En el ejemplo, qfs1mds-node2 es el nodo secundario y el servidor de metadatos posible:
[qfs1mds-node2]root@solaris:~#
Copie el archivo /etc/opt/SUNWsamfs/mcf del nodo principal en el nodo secundario.
Revise el archivo mcf para detectar errores. Use el comando /opt/SUNWsamfs/sbin/sam-fsd y corrija los errores que encuentre.
El comando sam-fsd lee los archivos de configuración de Oracle HSM e inicializa los sistemas de archivos. Se detendrá si detecta un error. En el ejemplo, comprobamos el archivo mcf en el host qfs1mds-node1:
[qfs1mds-node2]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1mds-node2]root@solaris:~#
Luego, monte el sistema de archivos QFS en el nodo secundario del cluster HA-COTC.
Inicie sesión en el nodo secundario del cluster HA-COTC como root.
En el ejemplo, qfs1mds-node2 es el nodo secundario:
[qfs1mds-node2]root@solaris:~#
Realice una copia de seguridad del archivo /etc/vfstab del sistema operativo.
[qfs1mds-node2]root@solaris:~# cp /etc/vfstab /etc/vfstab.backup
Abra el archivo /etc/vfstab del sistema operativo en un editor de texto y agregue una línea para el nuevo sistema de archivos. Luego, guarde el archivo y cierre el editor.
En el ejemplo, utilizamos el editor vi:
[qfs1mds-node2]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------------------- ------ ---- ------- ------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1 - /global/ha-cotc/qfs1 samfs - no shared :wq [qfs1mds-node2]root@solaris:~#
Cree el punto de montaje para el sistema de archivos compartido de alta disponibilidad en el nodo secundario.
[qfs1mds-node2]root@solaris:~# mkdir -p /global/ha-cotc/qfs1 [qfs1mds-node2]root@solaris:~#
Monte el sistema de archivos compartido de alta disponibilidad en el nodo secundario.
[qfs1mds-node2]root@solaris:~# mount /global/ha-cotc/qfs1 [qfs1mds-node2]root@solaris:~#
Ahora configure el failover de los servidores de metadatos HA-COTC.
Cuando aloja un sistema de archivos compartido Oracle HSM en un cluster gestionado por el software Solaris Cluster, configura el failover de los servidores de metadatos mediante la creación de un recurso de clusters SUNW.qfs, un tipo de recurso definido por el software Oracle HSM (consulte la página del comando man SUNW.qfs para obtener más información). Para crear y configurar el recurso para una configuración de HA-COTC, realice lo siguiente:
Inicie sesión en el nodo principal del cluster HA-COTC como root.
En el ejemplo, qfs1mds-node1 es el nodo principal:
[qfs1mds-node1]root@solaris:~#
Defina el tipo de recurso QFS, SUNW.qfs, para el software Solaris Cluster. Use el comando clresourcetype register SUNW.HAStoragePlus.
[qfs1mds-node1]root@solaris:~# clresourcetype register SUNW.qfs [qfs1mds-node1]root@solaris:~#
Si el registro falla porque no se puede encontrar el archivo de registro, coloque un enlace simbólico al directorio /opt/SUNWsamfs/sc/etc/, en el directorio donde Solaris Cluster mantiene los archivos de registro de tipo de recurso, /opt/cluster/lib/rgm/rtreg/.
No instaló el software Oracle Solaris Cluster antes de instalar el software Oracle HSM. Normalmente, Oracle HSM proporciona automáticamente la ubicación del archivo de registro SUNW.qfs cuando detecta a Solaris Cluster durante la instalación. Deberá crear un enlace manualmente.
[qfs1mds-node1]root@solaris:~# cd /opt/cluster/lib/rgm/rtreg/ [qfs1mds-node1]root@solaris:~# ln -s /opt/SUNWsamfs/sc/etc/SUNW.qfs SUNW.qfs [qfs1mds-node1]root@solaris:~#
Cree un grupo de recursos para el servidor de metadatos de QFS. Use el comando de Solaris Cluster clresourcegroup create -n node-list group-name, donde node-list es una lista delimitada por comas de los dos nombres de nodo de cluster y group-name es el nombre que deseamos usar para el grupo de recursos.
En el ejemplo, se crea el grupo de recursos qfsrg con los nodos de servidor HA-COTC como miembros (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa).
[qfs1mds-node1]root@solaris:~# clresourcegroup create -n \ qfs1mds-node1,qfs1mds-node2 qfsrg [qfs1mds-node1]root@solaris:~#
En el nuevo grupo de recursos, configuramos un nombre de host virtual para el servidor de metadatos activo. Use el comando de Solaris Cluster clreslogicalhostname create -g group-name virtualMDS, donde group-name es el nombre del grupo de recursos de QFS y virtualMDS es el nombre del host virtual.
Use el mismo nombre de host virtual que usó en los archivos de host para el sistema de archivos compartido. En el ejemplo, creamos el host virtual qfs1mds en el grupo de recursos qfsr:
[qfs1mds-node1]root@solaris:~# clreslogicalhostname create -g qfsrg qfs1mds
Agregue los recursos del sistema de archivos QFS al grupo de recursos. Utilice el comando clresource create -g group-name -t SUNW.qfs -x QFSFileSystem=mount-point -y Resource_dependencies=virtualMDS resource-name, donde:
group-name es el nombre del grupo de recursos de QFS.
mount-point es el punto de montaje para el sistema de archivos en el cluster, un subdirectorio que no está directamente debajo del directorio raíz del sistema.
El montaje de un sistema de archivos QFS compartido inmediatamente debajo de la raíz puede ocasionar problemas de failover si se usa el tipo de recurso SUNW.qfs.
virtualMDS es el nombre del host virtual del servidor de metadatos activo.
resource-name es el nombre que desea otorgar al recurso.
En el ejemplo, creamos un recurso denominado hasqfs del tipo SUNW.qfs en el grupo de recursos qfsrg. Se establece la propiedad de extensión SUNW.qfs de QFSFileSystem en el punto de montaje /global/ha-cotc/qfs1 y se define la propiedad estándar Resource_dependencies en el host lógico para el servidor de metadatos activo, qfs1mds (tenga en cuenta que el siguiente comando se introduce como una sola línea, los saltos de línea se identifican por el carácter de barra diagonal inversa):
[qfs1mds-node1]root@solaris:~# clresource create -g qfsrg -t SUNW.qfs \ -x QFSFileSystem=/global/ha-cotc/qfs1 -y Resource_dependencies=qfs1mds hasqfs
Establezca en línea el grupo de recursos. Utilice el comando clresourcegroup online -emM group-name, donde group-name es el nombre del grupo de recursos de QFS.
En el ejemplo, ponemos el grupo de recursos qfsr en línea:
[qfs1mds-node1]root@solaris:~# clresourcegroup manage qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup online -emM qfsrg
Asegúrese de que el grupo de recursos de QFS esté en línea. Use el comando clresourcegroup status de Solaris Cluster.
En el ejemplo, el grupo de recursos qfsrg está online en el nodo principal, sam1mds-node1:
[qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsrg qfs1mds-node1 No Online qfs1mds-node2 No Offline
Asegúrese de que el grupo de recursos realice el failover correctamente mediante el movimiento del grupo de recursos al nodo secundario. Use el comando de Solaris Cluster clresourcegroup switch -n node2 group-name, donde node2 es el nombre del nodo secundario y group-name es el nombre que eligió para el grupo de recursos de HA-QFS. A continuación, use clresourcegroup status para comprobar el resultado.
En el ejemplo, movemos el grupo de recursos qfsrg a qfs1mds-node2 y confirmamos que el grupo de recursos estará en línea en el nodo especificado:
[qfs1mds-node1]root@solaris:~# clresourcegroup switch -n qfs1mds-node2 qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsrg qfs1mds-node1 No Offline qfs1mds-node2 No Online
Mueva el grupo de recursos nuevamente al nodo principal. Use el comando de Solaris Cluster clresourcegroup switch -n node1 group-name, donde node1 es el nombre del nodo principal y group-name es el nombre que eligió para el grupo de recursos de HA-QFS. A continuación, use clresourcegroup status para comprobar el resultado.
En el ejemplo, movemos correctamente el grupo de recursos qfsrg nuevamente a qfs1mds-node1:
[qfs1mds-node1]root@solaris:~# clresourcegroup switch -n qfs1mds-node1 qfsrg [qfs1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsrg qfs1mds-node1 No Online qfs1mds-node2 No Offline
A continuación, configure los hosts que estarán fuera del cluster HA-COTC como clientes del sistema de archivos compartido QFS.
Configure cada host como cliente QFS que no tenga acceso a los dispositivos de metadatos del sistema de archivos, de modo que los clientes no interfieran con la configuración de alta disponibilidad de los servidores de metadatos que se encuentran dentro del cluster.
Para cada cliente del sistema de archivos compartido HA-COTC, realice lo siguiente:
Inicie sesión en el nodo primario en el cluster HA-COTC. Inicie sesión como usuario root.
[qfs1mds-node1]root@solaris:~#
Muestre la configuración del dispositivo para el cluster. Use el comando de Solaris Cluster /usr/global/bin/cldevice list -v.
[qfs1mds-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 qfs1mds-node1:/dev/rdsk/c0t0d0 d2 qfs1mds-node1:/dev/rdsk/c0t6d0 ... d7 qfs1mds-node2:/dev/rdsk/c0t1d0 [qfs1mds-node1]root@solaris:~#
Examine la salida del comando cldevice list -v. Anote la ruta de acceso /dev/rdsk/ al identificador del dispositivo para cada dispositivo de datos (mr) de QFS.
En el ejemplo, los dispositivos de datos QFS son d4 y d5:
[qfs1mds-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 qfs1mds-node1:/dev/rdsk/c0t0d0 d2 qfs1mds-node1:/dev/rdsk/c0t6d0 d3 qfs1mds-node1:/dev/rdsk/c1t1d0 d3 qfs1mds-node2:/dev/rdsk/c1t1d0 d4 qfs1mds-node1:/dev/rdsk/c1t2d0 d4 qfs1mds-node2:/dev/rdsk/c1t2d0 d5 qfs1mds-node1:/dev/rdsk/c1t3d0 d5 qfs1mds-node2:/dev/rdsk/c1t3d0 d6 qfs1mds-node2:/dev/rdsk/c0t0d0 d7 qfs1mds-node2:/dev/rdsk/c0t1d0 [qfs1mds-node1]root@solaris:~#
Inicie sesión en el host de cliente del cluster HA-COTC como root.
En el ejemplo, qfs1client1 es el host de cliente:
[qfs1mds-node1]root@solaris:~# ssh root@qfs1client1 [qfs1client1]root@solaris:~#
En el host del cliente, recupere la información de configuración para el sistema de archivos compartido. Utilice el comando samfsconfig /dev/rdsk/*.
El comando samfsconfig /dev/rdsk/* busca la ruta especificada para los dispositivos conectados que pertenecen a un sistema de archivos QFS. En el ejemplo, el comando encuentra las rutas a los datos de los dispositivos qfs1 (mr). Como se espera, no encuentran los dispositivos de metadatos (mm), de modo que devuelve los mensajes Missing slices y Ordinal 0 antes de mostrar los dispositivos de datos compartidos:
[qfs1client1]root@solaris:~# samfsconfig /dev/rdsk/* # Family Set 'qfs1' Created Thu Dec 21 07:17:00 2013 # Missing slices # Ordinal 0 # /dev/rdsk/c1t2d0s0 102 mr qfs1 - # /dev/rdsk/c1t3d0s1 103 mr qfs1 -
Comparar la salida del comando samfsconfig con la salida del comando de Solaris Cluster cldevice list en el servidor. Asegúrese de que ambos informen las mismas rutas de dispositivos para los dispositivos de datos mr.
Los comandos samfsconfig y cldevice list deben indicar los mismos dispositivos, aunque es posible que los números de controlador (cN) difieran. En el ejemplo, los comandos samfsconfig y cldevice list no apuntan a los mismos dispositivos.
En el nodo del servidor de metadatos, el archivo /etc/opt/SUNWsamfs/mcf identifica los dispositivos de datos mr compartidos 102 y 103 mediante el uso de los identificadores de dispositivo de cluster d4 y d5:
/dev/did/dsk/d4s0 102 mr qfs1 - /dev/did/dsk/d5s1 103 mr qfs1 -
El comando cldevice list del nodo del servidor de metadatos asigna identificadores de dispositivos de cluster d4 y d5 a las rutas /dev/rdisk/c1t2d0 y /dev/rdisk/c1t3d0:
d4 qfs1mds-node1:/dev/rdsk/c1t2d0 d5 qfs1mds-node1:/dev/rdsk/c1t3d0
En el nodo de cliente, el comando samfsconfig también identifica dispositivos de datos mr compartidos 102 y 103 con las rutas /dev/rdisk/c1t2d0 y /dev/rdisk/c1t3d0:
/dev/rdsk/c1t2d0s0 102 mr qfs1 - /dev/rdsk/c1t3d0s1 103 mr qfs1 -
Abra el archivo /etc/opt/SUNWsamfs/mcf del cliente en un editor de texto. Agregue una entrada para el sistema de archivos compartido HA-COTC. La entrada debe coincidir exactamente con las entradas correspondientes en el servidor de metadatos de archivos mcf.
En el ejemplo, usamos el editor vi para crear una entrada para el sistema de archivos QFS qfs1 (número ordinal de equipo 100):
[qfs1client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ---------------- qfs1 100 ma qfs1 - shared
En una nueva línea, inicie una entrada para los dispositivos de metadatos del sistema de archivos compartido HA-COTC (mm). En la primera columna (Equipment Identifier), escriba nodev.
# Equipment Equipment Equipment Family Device Additional
# Identifier Ordinal Type Set State Parameters
#------------------ --------- --------- ------- ------ ----------------
qfs1 100 ma qfs1 - shared
nodev
Complete los campos restantes para los dispositivos de metadatos (mm) del sistema de archivos HA-COTC con los mismos números ordinales de equipo, el mismo conjunto de familias y los mismos parámetros de estado de dispositivos que se usan en los archivos mcf del servidor de metadatos.
# Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ---------------- qfs1 100 ma qfs1 - shared nodev 101 mm qfs1 -
Copiar las entradas completas para los dispositivos de datos (mr) desde la salida de samfsconfig. Pegue las entradas en el archivo /etc/opt/SUNWsamfs/mcf del cliente. Quite las marcas del comentario de inicio (#) que inserta samfsconfig. Luego, guarde el archivo y cierre el editor.
# Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ----------------- qfs1 100 ma qfs1 - shared nodev 101 mm qfs1 - /dev/rdsk/c1t2d0s0 102 mr qfs1 - /dev/rdsk/c1t3d0s1 103 mr qfs1 - :wq [qfs1client1]root@solaris:~#
Revise el archivo mcf para detectar errores. Use el comando /opt/SUNWsamfs/sbin/sam-fsd y corrija los errores que encuentre.
El comando sam-fsd lee los archivos de configuración de Oracle HSM e inicializa los sistemas de archivos. Se detendrá si detecta un error. En el ejemplo, comprobamos el archivo mcf en el host qfs1client1:
[qfs1client1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1client1]root@solaris:~#
Abra el archivo /etc/vfstab del sistema operativo del cliente en un editor de texto y agregue una entrada para el nuevo sistema de archivos con los mismos parámetros que se utilizan en el servidor. Luego, guarde el archivo y cierre el editor.
En el ejemplo, utilizamos el editor vi:
[qfs1client1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------------------- ------ ---- ------- ------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1 - /global/ha-cotc/qfs1 samfs - no shared :wq [qfs1client1]root@solaris:~#
Cree el punto de montaje para el sistema de archivos compartido de alta disponibilidad en el cliente.
[qfs1client1]root@solaris:~# mkdir -p /global/qfs1 [qfs1client1]root@solaris:~#
Monte el sistema de archivos compartido de alta disponibilidad en el cliente.
En el ejemplo:
[qfs1client1]root@solaris:~# mount /global/qfs1 [qfs1client1]root@solaris:~#
Repita este procedimiento hasta que se hayan configurado todos los clientes HA-COTC.
Si planea usar la función de base de datos de banda lateral, vaya a Configuración de la base de datos de informes.
En caso contrario, vaya a Configuración de notificaciones y registro.
La configuración de Oracle Hierarchical Storage Manager de alta disponibilidad (HA-SAM) mantiene la disponibilidad de un sistema de archivos de almacenamiento mediante la garantía de que el servidor de metadatos de QFS y la aplicación Oracle Hierarchical Storage Manager continuarán funcionando, incluso si falla el host del servidor. El sistema de archivos se comparte entre servidores de metadatos QFS activos y posibles alojados en un cluster de dos nodos gestionado por el software Solaris Cluster. Si el nodo de cluster activo falla, el software de agrupación en clusters automáticamente activa el servidor posible de Oracle HSM en el nodo superviviente y transfiere el control por las operaciones en ejecución. Dado que el sistema de archivos QFS y los directorios de almacenamiento local de la aplicación Oracle HSM son compartidos y ya están montados, el acceso a los datos y los metadatos permanece ininterrumpido.
La configuración de HA-SAM garantiza la coherencia del sistema de archivos en un entorno de cluster mediante el envío de todas las E/S a través del servidor de metadatos activo. Puede compartir el sistema de archivos de HA-SAM meramente para motivos de accesibilidad. No puede utilizar el servidor de metadatos posible como cliente del sistema de archivos, como lo haría en otras configuraciones del sistema de archivos SAM-QFS compartidos. El servidor de metadatos posible no realiza la E/S, a menos que se active durante el failover del nodo. Puede compartir un sistema de archivos HA-SAM con los clientes que usan NFS. Sin embargo, debe garantizar que los archivos compartidos se exporten exclusivamente desde el nodo de servidor de metadatos activo.
Los sistemas de archivado de alta disponibilidad dependen de tres tipos de recursos de Solaris Cluster:
SUNW.hasam
Si el host primario falla, el recurso de SUNW.hasam administra el failover de la aplicación Oracle Hierarchical Storage Manager. El software de SUNW.hasam se incluye con la distribución de software Oracle HSM.
SUNW.qfs
Si el host primario falla, el recurso de SUNW.qfs administra el failover del servidor de metadatos de QFS. El software SUNW.qfs se incluye con la distribución de software de Oracle HSM (para obtener más información, consulte la página del comando man SUNW.qfs).
SUNW.HAStoragePlus
Si el host primario falla, el recurso de SUNW.HAStoragePlus administra el failover del almacenamiento local de Oracle Hierarchical Storage Manager. La aplicación Oracle HSM mantiene la información de archivado volátil (las colas de trabajos y los catálogos de medios extraíbles) en el sistema de archivos local del servidor host. SUNW.HAStoragePlus se incluye en el software Solaris Cluster como tipo de recurso estándar (para obtener más información, consulte la documentación de Administración y planificación de servicios de datos de la biblioteca de documentación de Oracle Solaris Cluster).
Para configurar instancias de los componentes requeridos e integrarlas en una configuración de archivado HA-SAM en funcionamiento, realice las siguientes tareas:
Creación de un archivo de hosts global en ambos nodos del cluster de HA-SAM
Creación de archivos de hosts locales en ambos nodos del cluster HA-SAM
Configuración de un servidor de metadatos QFS activo en el nodo de cluster HA-SAM principal
Configuración de un servidor de metadatos QFS posible en el nodo de cluster HA-SAM secundario
Configuración del cluster para utilizar el sistema de archivos local de alta disponibilidad HA-SAM
Configuración del failover del servidor de metadatos del sistema de archivos QFS
Configuración del failover de la aplicación Oracle Hierarchical Storage Manager
Definición de las dependencias de recursos del cluster para la solución HA-SAM
Colocación del grupo de recursos de HA-SAM en línea y prueba de la configuración
Si es necesario, configure el uso compartido del sistema de archivos de red de alta disponibilidad (HA-NFS).
En la Guía del servicio de datos de Oracle Solaris Cluster Data para el sistema de archivos de red (NFS)que se incluye en la biblioteca de documentación en línea Oracle Solaris Cluster se incluyen los procedimientos detallados para configurar HA-NFS.
En un sistema de archivado compartido de Oracle HSM, debe configurar un archivo de hosts en los servidores de metadatos, de modo que los hosts de ambos nodos puedan acceder a los metadatos para el sistema de archivos. El archivo de hosts se almacena junto con el archivo mcf en el directorio /etc/opt/SUNWsamfs/. Durante la creación inicial de un sistema de archivos compartido, el comando sammkfs -S configura el uso compartido mediante los parámetros de configuración almacenados en este archivo. Por lo tanto, créelo ahora, utilizando el procedimiento que se indica a continuación.
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
Muestre la configuración del cluster. Use el comando /usr/global/bin/cluster show. En la salida, ubique el registro de cada Node Name y observe los nombres privatehostname y Transport Adapter, y la propiedad ip_address de cada adaptador de red.
En los ejemplos, cada nodo tiene dos interfaces de red, hme0 y qfe3:
Los adaptadores hme0 tienen direcciones IP en la red privada que usa el cluster para comunicaciones internas entre nodos. El software Solaris Cluster asigna un privatehostname correspondiente a cada dirección privada.
De forma predeterminada, el nombre del host privado del nodo principal es clusternode1-priv y el nombre del host privado del nodo secundario es clusternode2-priv.
Los adaptadores qfe3 tienen direcciones IP públicas y nombres de host públicos, sam1mds-node1 y sam1mds-node2, que el cluster usa para transporte de datos.
Observe que la visualización ha sido abreviada mediante el uso de marcas de elipsis (...):
[sam1mds-node1]root@solaris:~# cluster show ... === Cluster Nodes === Node Name: sam1mds-node1... privatehostname: clusternode1-priv... Transport Adapter List: qfe3, hme0... Transport Adapter: qfe3... Adapter Property(ip_address): 172.16.0.12... Transport Adapter: hme0... Adapter Property(ip_address): 10.0.0.129... Node Name: sam1mds-node2... privatehostname: clusternode2-priv... Transport Adapter List: qfe3, hme0... Adapter Property(ip_address): 172.16.0.13... Transport Adapter: hme0... Adapter Property(ip_address): 10.0.0.122
Mediante el uso del editor de texto, cree el archivo /etc/opt/SUNWsamfs/hosts.family-set-name, donde family-set-name es el nombre del conjunto de familias que el archivo /etc/opt/SUNWsamfs/mcf asigna al equipo del sistema de archivos.
En el ejemplo, creamos el archivo hosts.sam1 mediante el editor de texto vi. Agregamos algunos encabezados opcionales para mostrar las columnas en la tabla de hosts, comenzando cada línea con el signo de numeral (#) para indicar un comentario:
[sam1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.sam1 # /etc/opt/SUNWsamfs/hosts.sam1 # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ----------
En la primera columna de la tabla, introduzca los nombres de host de los nodos de servidor de metadatos principal y secundario, seguidos de algunos espacios, con cada entrada en una línea separada.
En un archivo de hosts, las líneas son filas (registros) y los espacios son separadores de columnas (campos). En el ejemplo, la columna Host Name de las primeras dos filas contiene los valores sam1mds-node1 y sam1mds-node2, los nombres de host de los nodos de cluster que alojan los servidores de metadatos para el sistema de archivos:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 sam1mds-node2
En la segunda columna de cada línea, comience por suministrar información de Network Interface para los hosts que se muestran en la columna Host Name. Introduzca cada nombre de host privado de Solaris Cluster del nodo de cluster HA-SAM o la dirección de red privada seguida por una coma.
Los nodos de servidor HA-SAM usan nombres de host privados para comunicaciones de servidor a servidor dentro del cluster de alta disponibilidad. En el ejemplo, usamos los nombres de host privados clusternode1-priv y clusternode2-priv, que son los nombres predeterminados asignados por el software Solaris Cluster:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv, sam1mds-node2 clusternode2-priv,
Después de la coma que aparece en la segunda columna de cada línea, introduzca un nombre de host público para el servidor de metadatos activo, seguido por espacios.
Los nodos de servidor HA-SAM usan la red de datos públicos para comunicarse con los hosts fuera del cluster. Dado que la dirección IP y el nombre de host del servidor de metadatos activo cambia durante el failover (de sam1mds-node1 a sam1mds-node2 y viceversa), usamos un nombre de host virtual sam1mds para ambos. Posteriormente, configuraremos el software de Solaris Cluster para que siempre enrute las solicitudes de sam1mds al servidor de metadatos activo:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv,sam1mds sam1mds-node2 clusternode2-priv,sam1mds
En la tercera columna de cada línea, introduzca el número ordinal del servidor (1 para el servidor de metadatos activo y 2 para el servidor de metadatos posible), seguido por espacios.
En este ejemplo, hay solamente un servidor de metadatos, el nodo principal, sam1mds-node1, es el servidor de metadatos activo, de modo que es el ordinal 1 y el nodo secundario, sam1mds-node2, es el ordinal 2:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv,sam1mds 1 sam1mds-node2 clusternode2-priv,sam1mds 2
En la cuarta columna de cada línea, introduzca 0 (cero), seguido por espacios.
El valor 0, - (guión) o en blanco en la cuarta columna indica que el host está on, es decir, configurado con acceso al sistema de archivos compartido. El valor 1 (numeral uno) indica que el host está off, es decir, configurado pero sin acceso al sistema de archivos (para obtener información sobre el uso de estos valores para administrar sistemas de archivos compartidos, consulte la página del comando man samsharefs).
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv,sam1mds 1 0 sam1mds-node2 clusternode2-priv,sam1mds 2 0
En la quinta columna de la línea del nodo principal, introduzca la palabra clave server. Luego, guarde el archivo y cierre el editor.
La palabra clave del servidor identifica el servidor de metadatos activo predeterminado:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv,sam1mds 1 0 server sam1mds-node2 clusternode2-priv,sam1mds 2 0 :wq [sam1mds-node1]root@solaris:~#
Coloque una copia del archivo global /etc/opt/SUNWsamfs/hosts.family-set-name en el servidor de metadatos posible.
Ahora, cree archivos de hosts locales en ambos nodos del cluster HA-SAM.
En un sistema de archivado compartido de alta disponibilidad, deberá garantizar que los servidores se comuniquen entre sí mediante el uso de la red privada definida por el software Solaris Cluster. Para ello, se usan los archivos de host locales especialmente configurados para enrutar el tráfico de red de forma selectiva entre las interfaces de red de los servidores.
Cada host del sistema de archivos identifica las interfaces de red para otros hosts; para ello, comprueban primero el archivo /etc/opt/SUNWsamfs/hosts.family-set-name en el servidor de metadatos. Luego, verifica su propio y específico archivo /etc/opt/SUNWsamfs/hosts.family-set-name.local. Si no hay un archivo de hosts local, el host utiliza las direcciones de interfaz especificadas en el archivo de hosts global en el orden especificado en el archivo global. Pero, si hay un archivo de hosts local, el host lo compara con el archivo global y utiliza sólo aquellas interfaces que aparecen en ambos archivos en el orden especificado en el archivo local. Al utilizar direcciones diferentes en organizaciones diferentes en cada archivo, puede controlar las interfaces utilizadas por los diferentes hosts.
Para configurar archivos de hosts locales, utilice el procedimiento que se describe a continuación:
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
Mediante el uso de un editor de texto, cree un archivo de hosts local en el servidor de metadatos activo, mediante el uso de la ruta y el nombre de archivo /etc/opt/SUNWsamfs/hosts.family-set-name.local, donde family-set-name es el nombre del conjunto de familias que el archivo /etc/opt/SUNWsamfs/mcf asigna al equipo del sistema de archivos. Incluya únicamente interfaces de red que desea que use el servidor activo cuando se comunica con el servidor posible. Luego, guarde el archivo y cierre el editor.
En nuestro ejemplo, deseamos que los servidores de metadatos activo y posible se comuniquen entre sí por la red privada. De modo que el archivo de hosts local en el servidor de metadatos, hosts.sam1.local, muestra solamente las direcciones privadas de cluster de los servidores activo y posible:
[sam1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.sam1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv 1 0 server sam1mds-node2 clusternode2-priv 2 0 :wq [sam1mds-node1]root@solaris:~#
Inicie sesión en el nodo de cluster secundario como root.
En el ejemplo, sam1mds-node2 es el nodo secundario:
[sam1mds-node1]root@solaris:~# ssh root@sam1mds-node2 Password: [sam1mds-node2]root@solaris:~#
Mediante un editor de texto, cree un archivo de hosts local en el servidor de metadatos posible. Use la ruta y el nombre del archivo /etc/opt/SUNWsamfs/hosts.family-set-name.local, donde family-set-name es el nombre del conjunto de familias que el archivo /etc/opt/SUNWsamfs/mcf asigna al equipo del sistema de archivos. Incluya únicamente interfaces de red que desea que use el servidor posible cuando se comunica con el servidor activo. Luego, guarde el archivo y cierre el editor.
En nuestro ejemplo, deseamos que los servidores de metadatos activo y posible se comuniquen entre sí por la red privada. De modo que el archivo de hosts local en el servidor de metadatos posible, hosts.sam1.local, muestra solamente las direcciones privadas del cluster para los servidores activo y posible:
[sam1mds-node2]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.sam1.local # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ ----------------------------- ------- --- ---------- sam1mds-node1 clusternode1-priv 1 0 server sam1mds-node2 clusternode2-priv 2 0 :wq [sam1mds-node2]root@solaris:~# exit [sam1mds-node1]root@solaris:~#
Luego, configure un servidor de metadatos QFS activo en el nodo principal del cluster HA-SAM.
Seleccione el nodo de cluster que actuará como nodo principal para el cluster HA-SAM y el servidor de metadatos activo para el sistema de archivos compartido QFS. Inicie sesión como usuario root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
Seleccione los dispositivos de almacenamiento global que se usarán para el sistema de archivos QFS. Use el comando /usr/global/bin/cldevice list -v.
El software Solaris Cluster asigna identificadores de dispositivo (DID) únicos a todos los dispositivos que se conectan a los nodos de cluster. Se puede acceder a los dispositivos globales desde todos los nodos del cluster, y se puede acceder a los dispositivos locales únicamente desde los hosts que los montan. Los dispositivos globales permanecen accesibles después del failover. Los dispositivos locales no.
En el ejemplo, tenga en cuenta que no se puede acceder a los dispositivos d1, d2, d7 y d8 desde ambos nodos. Por lo tanto, seleccionamos entre los dispositivos d3, d4 y d5 cuando se configura el sistema de archivos compartido QFS de alta disponibilidad:
[sam1mds-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 sam1mds-node1:/dev/rdsk/c0t0d0 d2 sam1mds-node1:/dev/rdsk/c0t6d0 d3 sam1mds-node1:/dev/rdsk/c1t1d0 d3 sam1mds-node2:/dev/rdsk/c1t1d0 d4 sam1mds-node1:/dev/rdsk/c1t2d0 d4 sam1mds-node2:/dev/rdsk/c1t2d0 d5 sam1mds-node1:/dev/rdsk/c1t3d0 d5 sam1mds-node2:/dev/rdsk/c1t3d0 d6 sam1mds-node2:/dev/rdsk/c0t0d0 d7 sam1mds-node2:/dev/rdsk/c0t1d0
En el nodo principal seleccionado, cree un sistema de archivos ma de alto rendimiento que use dispositivos de datos mr. En un editor de texto, abra el archivo /etc/opt/SUNWsamfs/mcf.
En el ejemplo, configuramos el sistema de archivos sam1. Configuramos el dispositivo d3 como dispositivo de metadatos (tipo de equipo mm) y usamos d4 y d5 como dispositivos de datos (tipo de equipo mr):
[sam1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ----------------- sam1 100 ma sam1 - /dev/did/dsk/d3s0 101 mm sam1 - /dev/did/dsk/d4s0 102 mr sam1 - /dev/did/dsk/d5s1 103 mr sam1 -
En el archivo /etc/opt/SUNWsamfs/mcf, introduzca el parámetro shared en la columna Additional Parameters de la entrada del sistema de archivos. Guarde el archivo.
[sam1mds-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ ----------------- sam1 100 ma sam1 - shared /dev/did/dsk/d3s0 101 mm sam1 - /dev/did/dsk/d4s0 102 mr sam1 - /dev/did/dsk/d5s1 103 mr sam1 - :wq [sam1mds-node1]root@solaris:~#
Revise el archivo mcf para detectar errores. Use el comando /opt/SUNWsamfs/sbin/sam-fsd y corrija los errores que encuentre.
El comando sam-fsd lee los archivos de configuración de Oracle HSM e inicializa los sistemas de archivos. Se detendrá si detecta un error. En el ejemplo, comprobamos el archivo mcf en el host sam1mds-node1:
[sam1mds-node1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[sam1mds-node1]root@solaris:~#
Cree el sistema de archivos. Use el comando /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, donde family-set-name es el nombre del conjunto de familias que el archivo /etc/opt/SUNWsamfs/mcf asigna al equipo del sistema de archivos.
El comando sammkfs lee los archivos hosts.family-set-name y mcf y crea un sistema de archivos Oracle HSM con las propiedades especificadas.
[sam1mds-node1]root@solaris:~# sammkfs -S sam1 Building 'sam1' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [sam1mds-node1]root@solaris:~#
Abra el archivo /etc/vfstab del sistema operativo en un editor de texto e inicie una línea para el nuevos sistema de archivos. Introduzca el nombre del sistema de archivos en la primera columna, espacios, un guión en la segunda columna y más espacios.
En el ejemplo, utilizamos el editor de texto vi. Iniciamos una línea para el sistema de archivos sam1. El guión evita que el sistema operativo intente comprobar la integridad del sistema de archivos mediante las herramientas del UFS:
[sam1mds-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------ ------ ---- ------- --------------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 -
En la tercera columna del archivo /etc/vfstab, introduzca el punto de montaje del sistema de archivos relacionado con el cluster. Seleccione un subdirectorio que no se encuentre debajo del directorio raíz del sistema.
El montaje de un sistema de archivos QFS compartido inmediatamente debajo de la raíz puede ocasionar problemas de failover si se usa el tipo de recurso SUNW.qfs. En el ejemplo, definimos el punto de montaje en el cluster en /global/ha-sam/sam1:
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ------------------- ------ ---- ------- ---------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
sam1 - /global/ha-sam/sam1
Complete los campos restantes del registro de archivo /etc/vfstab tal como lo haría con cualquier sistema de archivos compartido de Oracle HSM. Luego, guarde el archivo y cierre el editor.
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------------- ------ ---- ------- --------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 - /global/ha-sam/sam1 samfs - no shared :wq [sam1mds-node1]root@solaris:~#
Cree un punto de montaje para el sistema de archivo de alta disponibilidad.
El comando mkdir con la opción -p (parents) crea el directorio /global si aún no existe:
[sam1mds-node1]root@solaris:~# mkdir -p /global/ha-sam/sam1
Monte el sistema de archivos compartido de alta disponibilidad en el nodo principal.
[sam1mds-node1]root@solaris:~# mount /global/ha-sam/sam1
Luego, configure un servidor de metadatos QFS posible en el nodo secundario del cluster HA-SAM.
El nodo secundario del cluster de dos nodos actúa como servidor de metadatos posible. Un servidor de metadatos posible es un host que puede acceder a los dispositivos de metadatos y, por lo tanto, puede asumir las tareas de un servidor de metadatos. Por lo tanto, si el servidor de metadatos activo en el nodo principal falla, el software Solaris Cluster puede realizar el failover en el nodo secundario y activar el servidor de metadatos posible.
Inicie sesión en el nodo secundario del cluster HA-SAM como root.
En el ejemplo, sam1mds-node2 es el nodo secundario:
[sam1mds-node2]root@solaris:~#
Copie el archivo /etc/opt/SUNWsamfs/mcf del nodo principal en el nodo secundario.
Revise el archivo mcf para detectar errores. Use el comando /opt/SUNWsamfs/sbin/sam-fsd y corrija los errores que encuentre.
El comando sam-fsd lee los archivos de configuración de Oracle HSM e inicializa los sistemas de archivos. Se detendrá si detecta un error. En el ejemplo, comprobamos el archivo mcf en el host sam1mds-node1:
[sam1mds-node2]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[sam1mds-node2]root@solaris:~#
Cree el sistema de archivos. Use el comando /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, donde family-set-name es el nombre del conjunto de familias que el archivo /etc/opt/SUNWsamfs/mcf asigna al equipo del sistema de archivos.
El comando sammkfs lee los archivos hosts.family-set-name y mcf y crea un sistema de archivos Oracle HSM con las propiedades especificadas.
[sam1mds-node2]root@solaris:~# sammkfs sam1 Building 'sam1' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [sam1mds-node2]root@solaris:~#
Abra el archivo /etc/vfstab del sistema operativo en un editor de texto y agregue una línea para el nuevo sistema de archivos. Luego, guarde el archivo y cierre el editor.
En el ejemplo, utilizamos el editor vi:
[sam1mds-node2]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------------- ------ ---- ------- -------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 - /global/ha-sam/sam1 samfs - no shared :wq [sam1mds-node2]root@solaris:~#
Cree el punto de montaje para el sistema de archivos compartido de alta disponibilidad en el nodo secundario.
[sam1mds-node2]root@solaris:~# mkdir -p /global/ha-sam/sam1
Monte el sistema de archivos compartido de alta disponibilidad en el nodo secundario.
[sam1mds-node2]root@solaris:~# mount /global/ha-sam/sam1
Cree el grupo de recursos para gestionar la alta disponibilidad de recursos para la solución HA-SAM .
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
Cree un grupo de recursos de Solaris Cluster para gestionar los recursos de la solución HA-SAM. Utilice el comando clresourcegroup create -n node1,node2 groupname, donde:
node1 es el nombre de host del nodo de cluster primario.
node2 es el nombre de host del nodo de cluster secundario.
groupname es el nombre que eligió para el grupo de recursos de HA-SAM.
En el ejemplo, se crea un grupo de recursos con el nombre has-rg y se incluyen hosts sam1mds-node1 y sam1mds-node2 (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# clresourcegroup create \ -n sam1mds-node1,sam1mds-node2 has-rg
A continuación, configure un sistema de archivos local de alta disponibilidad para contener los archivos de configuración de Oracle HSM.
Para recuperarse correctamente después de un failover, el software Oracle HSM debe reiniciar las operaciones de archivado que se estaban ejecutando cuando ocurrió el failover. Para reiniciar las operaciones de archivado, el software debe tener acceso a la configuración del sistema y a la información de estado que, normalmente, se almacena en el sistema de archivos local del servidor de metadatos activo. Por lo tanto, debe mover la información necesaria a un sistema de archivos local de alta disponibilidad que siempre permanezca accesible desde ambos nodos del cluster.
Para crear el sistema de archivos necesario, realice lo siguiente:
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
En el nodo de cluster primario libre, cree un sistema de archivos UFS en un segmento libre de un dispositivo global. Utilice el comando newfs /dev/global/dsk/dXsY, donde X es el número de identificador de dispositivos (DID) del dispositivo global y Y es el número de segmento.
En el ejemplo, se crea el nuevo sistema de archivos en /dev/global/dsk/d10s0:
[sam1mds-node1]root@solaris:~# newfs /dev/global/dsk/d10s0 newfs: construct a new file system /dev/global/dsk/d10s0: (y/n)? y /dev/global/dsk/d10s0: 1112940 sectors in 1374 cylinders of 15 tracks, 54 sectors 569.8MB in 86 cyl groups (16 c/g, 6.64MB/g, 3072 i/g) super-block backups(for fsck -b #) at: 32, 13056, 26080, 39104, 52128, 65152, 78176, 91200, 104224, . . . [sam1mds-node1]root@solaris:~#
En el nodo de cluster primario, abra el archivo /etc/vfstab del sistema operativo en un editor de texto. Agregue una línea para el nuevo sistema de archivos UFS. Guarde el archivo y cierre el editor.
La nueva línea debe ser una lista delimitada por espacios con el formato /dev/global/dsk/dXsY /dev/global/dsk/dXsY /global/mount_point ufs 5 no global, donde:
X es el número de identificador de dispositivos (DID) del dispositivo global que contiene el sistema de archivos.
Y es el número del segmento que contiene el sistema de archivos.
/dev/global/dsk/dXsY es el nombre del dispositivo del sistema de archivos que se montará.
/dev/global/dsk/dXsY es el nombre del dispositivo del sistema de archivos que verificará el comando fsck.
mount_point es el nombre del subdirectorio en el que se va a montar el archivo UFS.
ufs es el tipo del sistema de archivos.
5 es el número de pase fsck recomendado.
no indica al sistema operativo que no debe montar el sistema de archivos al iniciar.
global monta el sistema de archivos de modo que ambos nodos tengan acceso.
En el ejemplo, utilizamos el editor vi. El nombre del sistema de archivos es /dev/global/dsk/d10s0 y el punto de montaje es /global/hasam_cfg (tenga en cuenta que la entrada del sistema de archivos es una sola línea, para ajustarse a la página, se inserta un salto de línea que se identifica por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------------- ------ ---- ------- -------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 - /global/ha-samsam1 samfs - no shared /dev/global/dsk/d10s0 /dev/global/rdsk/d10s0 /global/hasam_cfg ufs 5 \ no global :wq [sam1mds-node2]root@solaris:~#
En el nodo de cluster primario, cree el punto de montaje para el sistema de archivos local de alta disponibilidad. Utilice el comando mkdir -p /global/mount_point, donde mount_point es el directorio del punto de montaje seleccionado.
En el ejemplo, se crea el directorio /global/hasam_cfg:
[sam1mds-node1]root@solaris:~# mkdir -p /global/hasam_cfg
Inicie sesión en el nodo de cluster secundario como root.
En el ejemplo, el nodo secundario es sam1mds-node2. Se inicia sesión con ssh:
[sam1mds-node1]root@solaris:~# ssh root@sam1mds-node2 Password: [sam1mds-node2]root@solaris:~#
En el nodo de cluster secundario, abra el archivo /etc/vfstab del sistema operativo en un editor de texto. Agregue una entrada idéntica para el nuevo sistema de archivos UFS. Guarde el archivo y cierre el editor.
[sam1mds-node1]root@solaris:~# ssh root@sam1mds-node2 Password: [sam1mds-node2]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ------------------- ------ ---- ------- -------------- /devices - /devices devfs - no - /proc - /proc proc - no - ... sam1 - /global/ha-samsam1 samfs - no shared /dev/global/dsk/d10s0 /dev/global/rdsk/d10s0 /global/hasam_cfg ufs 5 \ no global :wq [sam1mds-node1]root@solaris:~#
En el nodo secundario, cree el mismo punto de montaje.
En el ejemplo, se crea el directorio /global/hasam_cfg. A continuación, se cierra la sesión ssh y se reanuda el trabajo en el nodo primario:
[sam1mds-node2]root@solaris:~# mkdir -p /global/hasam_cfg [sam1mds-node2]root@solaris:~# exit [sam1mds-node1]root@solaris:~#
En el nodo primario, monte el sistema de archivos local de alta disponibilidad. Utilice el comando mount /global/mount_point, donde mount_point es el directorio de punto de montaje seleccionado.
El comando monta el sistema de archivos UFS en ambos nodos. En el ejemplo, se monta el sistema de archivos en /global/hasam_cfg:
[sam1mds-node1]root@solaris:~# mount /global/hasam_cfg [sam1mds-node1]root@solaris:~#
En el nodo primario, cree un subdirectorio para alojar la información de almacenamiento provisional de Oracle HSM. Utilice el comando mkdir -p /global/mount_point/catalog, donde mount_point es el directorio de punto de montaje seleccionado.
[sam1mds-node1]root@solaris:~# mkdir /global/hasam_cfg/catalog [sam1mds-node1]root@solaris:~#
En el nodo primario, cree un subdirectorio para alojar los catálogos de archivo de Oracle HSM. Utilice el comando mkdir -p /global/mount_point/stager, donde mount_point es el directorio de punto de montaje seleccionado.
[sam1mds-node1]root@solaris:~# mkdir /global/hasam_cfg/stager [sam1mds-node1]root@solaris:~#
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
En el nodo principal, copie los directorios catalog/ y stager/ desde sus ubicaciones predeterminadas en /var/opt/SUNWsamfs/ a una ubicación temporal.
En el ejemplo, se copian de forma recursiva los directorios en /var/tmp/ (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# cp -r /var/opt/SUNWsamfs/catalog \ /var/tmp/catalog [sam1mds-node1]root@solaris:~# cp -r /var/opt/SUNWsamfs/stager /var/tmp/stager [sam1mds-node1]root@solaris:~#
En el nodo primario, suprima los directorios catalog/ y stager/ de /var/opt/SUNWsamfs/.
[sam1mds-node1]root@solaris:~# rm -rf /var/opt/SUNWsamfs/catalog [sam1mds-node1]root@solaris:~# rm -rf /var/opt/SUNWsamfs/stager [sam1mds-node1]root@solaris:~#
En el nodo primario, cree un enlace simbólico desde la ubicación por defecto de la información del catálogo a la nueva ubicación en el sistema de archivos UFS local de alta disponibilidad. Utilice el comando ln -s /global/mount_point/catalog /var/opt/SUNWsamfs/catalog, donde:
mount_point es el nombre del subdirectorio donde se adjunta el sistema de archivos local de alta disponibilidad al sistema de archivos raíz del nodo.
/var/opt/SUNWsamfs/catalog es la ubicación por defecto.
El enlace simbólico redirigirá automáticamente solicitudes de información del catálogo a la nueva ubicación. En el siguiente ejemplo, se crea un enlace catalog que apunta a la nueva ubicación /global/hasam_cfg/catalog (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# ln -s /global/hasam_cfg/catalog \ /var/opt/SUNWsamfs/catalog [sam1mds-node1]root@solaris:~#
En el nodo primario, cree un enlace simbólico desde la ubicación por defecto de la información de almacenamiento provisional a la nueva ubicación en el sistema de archivos UFS local de alta disponibilidad. Utilice el comando ln -s /global/mount_point/stager /var/opt/SUNWsamfs/stager, donde:
mount_point es el nombre del subdirectorio donde se adjunta el sistema de archivos local de alta disponibilidad al sistema de archivos raíz del nodo.
/var/opt/SUNWsamfs/stager es la ubicación por defecto.
El enlace simbólico redirigirá automáticamente solicitudes de información del proceso de almacenamiento provisional a la nueva ubicación. En el siguiente ejemplo, se crea un enlace stager que apunta a la nueva ubicación /global/hasam_cfg/stager (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# ln -s /global/hasam_cfg/stager \ /var/opt/SUNWsamfs/stager [sam1mds-node1]root@solaris:~#
En el nodo primario, asegúrese de que los enlaces simbólicos hayan reemplazado los directorios /var/opt/SUNWsamfs/catalog y /var/opt/SUNWsamfs/stager por defecto. Asegúrese de que los enlaces apunten a las nuevas ubicaciones en el sistema de archivos de alta disponibilidad.
En el ejemplo, los enlaces son correctos:
[sam1mds-node1]root@solaris:~# ls -l /var/opt/SUNWsamfs/catalog lrwxrwxrwx 1 root other ... /var/opt/SUNWsamfs/catalog -> /global/hasam_cfg/catalog [sam1mds-node1]root@solaris:~# ls -l /var/opt/SUNWsamfs/stager lrwxrwxrwx 1 root other ... /var/opt/SUNWsamfs/stager -> /global/hasam_cfg/stager [sam1mds-node1]root@solaris:~#
Copie el contenido de los directorios catalog/ y stager/ desde la ubicación temporaria al sistema de archivos de alta disponibilidad.
En el ejemplo, se copian los directorios catalog/ y stager/ desde /var/tmp/ a la nueva ubicación, /global/hasam_cfg/stager (tenga en cuenta que los comandos a continuación se introducen como una sola línea, los saltos de línea se identifican por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# cp -rp /var/tmp/catalog/* \ /var/opt/SUNWsamfs/catalog [sam1mds-node1]root@solaris:~# cp -rp /var/tmp/stager/* \ /var/opt/SUNWsamfs/stager [sam1mds-node1]root@solaris:~#
Inicie sesión en el nodo secundario del cluster HA-SAM como root.
En el ejemplo, utilizamos ssh (shell seguro) para conectarse a sam1mds-node2, el nodo secundario:
[sam1mds-node1]root@solaris:~# ssh root@sam1mds-node2 Password: [sam1mds-node2]root@solaris:~#
En el nodo secundario, cree un enlace simbólico desde la ubicación por defecto de la información del catálogo a la nueva ubicación en el sistema de archivos UFS local de alta disponibilidad. Utilice el comando ln -s /global/mount_point/catalog /var/opt/SUNWsamfs/catalog, donde:
mount_point es el nombre del subdirectorio donde se adjunta el sistema de archivos local de alta disponibilidad al sistema de archivos raíz del nodo.
/var/opt/SUNWsamfs/catalog es la ubicación por defecto.
El enlace simbólico redirigirá automáticamente solicitudes de información del catálogo a la nueva ubicación. En el siguiente ejemplo, se crea un enlace catalog que apunta a la nueva ubicación /global/hasam_cfg/catalog (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node2]root@solaris:~# ln -s /global/hasam_cfg/catalog \ /var/opt/SUNWsamfs/catalog [sam1mds-node2]root@solaris:~#
En el nodo secundario, cree un enlace simbólico desde la ubicación por defecto de la información de almacenamiento provisional a la nueva ubicación en el sistema de archivos UFS local de alta disponibilidad. Utilice el comando ln -s /global/mount_point/stager /var/opt/SUNWsamfs/stager, donde:
mount_point es el nombre del subdirectorio donde se adjunta el sistema de archivos local de alta disponibilidad al sistema de archivos raíz del nodo.
/var/opt/SUNWsamfs/stager es la ubicación por defecto.
El enlace simbólico redirigirá automáticamente solicitudes de información del proceso de almacenamiento provisional a la nueva ubicación. En el siguiente ejemplo, se crea un enlace stager que apunta a la nueva ubicación /global/hasam_cfg/stager (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node2]root@solaris:~# ln -s /global/hasam_cfg/stager \ /var/opt/SUNWsamfs/stager [sam1mds-node2]root@solaris:~#
En el nodo secundario, asegúrese de que los enlaces simbólicos hayan reemplazado los directorios /var/opt/SUNWsamfs/catalog y /var/opt/SUNWsamfs/stager por defecto. Asegúrese de que los enlaces apunten a las nuevas ubicaciones en el sistema de archivos de alta disponibilidad.
En el ejemplo, los enlaces son correctos. A continuación, se cierra la sesión ssh y se reanuda el trabajo en el nodo primario:
[sam1mds-node2]root@solaris:~# ls -l /var/opt/SUNWsamfs/catalog lrwxrwxrwx 1 root other ... /var/opt/SUNWsamfs/catalog -> /global/hasam_cfg/catalog [sam1mds-node2]root@solaris:~# ls -l /var/opt/SUNWsamfs/stager lrwxrwxrwx 1 root other ... /var/opt/SUNWsamfs/stager -> /global/hasam_cfg/stager [sam1mds-node2]root@solaris:~# exit [sam1mds-node1]root@solaris:~#
Luego, configure el cluster HA-SAM para que use el sistema de archivos local de alta disponibilidad.
En el nodo primario del cluster de HA-SAM, registre el tipo de recurso SUNW.HAStoragePlus como parte de la configuración del cluster. Use el comando Solaris Cluster clresourcetype register SUNW.HAStoragePlus.
[sam1mds-node1]root@solaris:~# clresourcetype register SUNW.HAStoragePlus [sam1mds-node1]root@solaris:~#
En el nodo primario, cree una nueva instancia del tipo de recurso SUNW.HAStoragePlus y asóciela a con un grupo de recursos de Solaris Cluster. Utilice el comando clresource create -g groupname -t SUNW.HAStoragePlus -x FilesystemMountPoints=mountpoint -x AffinityOn=TRUE resourcename, donde:
groupname es el nombre que eligió para el grupo de recursos de HA-SAM.
SUNW.HAStoragePlus es el tipo de recurso de Solaris Cluster que admite el failover de los sistemas de archivos locales.
mountpoint es el punto de montaje del sistema de archivos local de alta disponibilidad que aloja los catálogos y los archivos del proceso de almacenamiento provisional.
resourcename es el nombre que eligió para el recurso.
En el ejemplo, se crea un recurso denominado has-cfg de tipo SUNW.HAStoragePlus. Se agrega el nuevo recurso al grupo de recursos has-rg. A continuación, se configuran las propiedades de extensión de recursos. Se establece FilesystemMountPoints en /global/hasam_cfg y AffinityOn en TRUE (tenga en cuenta que los comandos a continuación se introducen como una sola línea, los saltos de línea se identifican por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# clresource create -g has-rg \ -t SUNW.HAStoragePlus -x FilesystemMountPoints=/global/hasam_cfg \ -x AffinityOn=TRUE has-cfg [sam1mds-node1]root@solaris:~#
A continuación, configure el failover del servidor de metadatos del sistema de archivos QFS.
Configure el failover de los servidores de metadatos mediante la creación de un recurso de cluster SUNW.qfs, un tipo de recurso definido por el software Oracle HSM (consulte la página de comando man SUNW.qfs para obtener más información). Para crear y configurar el recurso para una configuración de HA-SAM, realice lo siguiente:
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
Defina el tipo de recurso SUNW.qfs para el software Solaris Cluster. Use el comando clresourcetype register SUNW.HAStoragePlus.
[sam1mds-node1]root@solaris:~# clresourcetype register SUNW.qfs [qfs1mds-node1]root@solaris:~#
Si el registro falla porque no se puede encontrar el archivo de registro, coloque un enlace simbólico al directorio /opt/SUNWsamfs/sc/etc/, en el directorio donde Solaris Cluster mantiene los archivos de registro de tipo de recurso, /opt/cluster/lib/rgm/rtreg/.
El registro no se realizará si no instaló el software Oracle Solaris Cluster antes de instalar el software Oracle HSM. Normalmente, Oracle HSM proporciona automáticamente la ubicación del archivo de registro SUNW.qfs cuando detecta a Solaris Cluster durante la instalación. En el ejemplo, se crea el enlace manualmente.
[qfs1mds-node1]root@solaris:~# cd /opt/cluster/lib/rgm/rtreg/ [qfs1mds-node1]root@solaris:~# ln -s /opt/SUNWsamfs/sc/etc/SUNW.qfs SUNW.qfs [qfs1mds-node1]root@solaris:~#
En el nuevo grupo de recursos, configuramos un nombre de host virtual para el servidor de metadatos activo. Use el comando de Solaris Cluster clreslogicalhostname create -g group-name virtualMDS, donde:
group-name es el nombre del grupo de recursos de QFS.
virtualMDS es el nombre de host virtual.
Use el mismo nombre de host virtual que usó en los archivos de host para el sistema de archivos compartido. En el ejemplo, agregamos el nombre de host virtual sam1mds al grupo de recursos has-rg:
[sam1mds-node1]root@solaris:~# clreslogicalhostname create -g has-rg sam1mds [qfs1mds-node1]root@solaris:~#
Agregue los recursos del sistema de archivos Oracle HSM al grupo de recursos. Utilice el comando clresource create -g groupname -t SUNW.qfs -x QFSFileSystem=mount-point, donde:
groupname es el nombre que eligió para el grupo de recursos de HA-SAM.
SUNW.qfs es el tipo de recurso de Solaris Cluster que admite el failover de los servidores de metadatos del sistema de archivos QFS.
mount-point es el punto de montaje para el sistema de archivos en el cluster, un subdirectorio que no está directamente debajo del directorio raíz del sistema.
El montaje de un sistema de archivos QFS compartido inmediatamente debajo de la raíz puede ocasionar problemas de failover si se usa el tipo de recurso SUNW.qfs.
resource-name es el nombre que eligió para el recurso.
En el ejemplo, creamos un recurso denominado has-qfs del tipo SUNW.qfs en el grupo de recursos has-rg. Se establece la propiedad de extensión SUNW.qfs de QFSFileSystem en el punto de montaje /global/ha-sam/sam1. Se establece la propiedad estándar Resource_dependencies en sam1mds, el nombre de host virtual que representa el servidor de metadatos activo (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# clresource create -g has-rg -t SUNW.qfs \ -x QFSFileSystem=/global/ha-sam/sam1 -y Resource_dependencies=sam1mds has-qfs [sam1mds-node1]root@solaris:~#
A continuación, configure el failover de la aplicación Oracle Hierarchical Storage Manager.
Para configurar el failover de la aplicación Oracle Hierarchical Storage Manager, cree un recurso SUNW.hasam de Oracle HSM. Este tipo de recurso coordina el cierre ordenado y el reinicio de los procesos de Oracle HSM.
Para configurar el failover de la aplicación Oracle HSM, siga estos pasos:
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
Defina el tipo de recurso SUNW.hasam para el software Solaris Cluster. Utilice el comando clresourcetype register SUNW.hasam.
[sam1mds-node1]root@solaris:~# clresourcetype register SUNW.hasam [sam1mds-node1]root@solaris:~#
Agregue el recurso SUNW.hasam de Oracle HSM al grupo de recursos. Utilice el comando clresource create -g groupname -t SUNW.hasam -x QFSName=fs-name -x CatalogFileSystem=mount-point resource-name, donde:
groupname es el nombre que eligió para el grupo de recursos de HA-SAM.
SUNW.hasam es el tipo de recurso de Solaris Cluster que admite el failover de la aplicación Oracle Hierarchical Storage Manager.
mount-point es el punto de montaje del sistema de archivos global que aloja los catálogos de archivo de Oracle HSM.
resource-name es el nombre que eligió para el recurso.
En el ejemplo, creamos un recurso denominado has-sam del tipo SUNW.hasam en el grupo de recursos has-rg. Se establece la propiedad de extensión SUNW.hasam de QFSName en el nombre del sistema de archivos QFS especificado en el archivo mcf, sam1. Se establece la propiedad de extensión SUNW.hasam de CatalogFileSystem en el punto de montaje /global/hasam_cfg:
[sam1mds-node1]root@solaris:~# clresource create -g has-rg -t SUNW.hasam \ -x QFSName=sam1 -x CatalogFileSystem=/global/hasam_cfg has-sam [sam1mds-node1]root@solaris:~#
Luego, defina las dependencias del recurso del cluster para la solución HA-SAM.
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
El sistema de archivos QFS no se debe iniciar, a menos que el sistema de archivos local de alta disponibilidad está disponible. Por lo tanto, el recurso SUNW.qfs depende del recurso SUNW.HAStoragePlus. Utilice el comando de Solaris Cluster clresource set -p Resource_dependencies=dependency resource-name, donde:
dependency es el nombre del recurso SUNW.HAStoragePlus.
resource-name es el nombre del recurso SUNW.qfs.
En el ejemplo, el recurso SUNW.qfs depende del recurso SUNW.HAStoragePlus, has-cfg (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# clresource set \ -p Resource_dependencies=has-cfg has-qfs [sam1mds-node1]root@solaris:~#
El cluster no debe permitir que se acceda a un nombre de host virtual, a menos que el servidor de metadatos activo de QFS esté en línea. De manera que el nombre de host virtual depende del recurso SUNW.qfs. Utilice el comando de Solaris Cluster clresource set -p Resource_dependencies=virtualMDS resource-name, donde:
virtualMDS es el nombre de host virtual que representa el servidor de metadatos activo de Oracle HSM.
resource-name es el nombre del recurso SUNW.qfs.
En el ejemplo, el nombre de host virtual que se crea cuando se configura el recurso SUNW.qfs es sam1mds. El recurso propiamente dicho se denomina has-qfs (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[sam1mds-node1]root@solaris:~# clresource set \ -p Resource_dependencies=sam1mds has-qfs [sam1mds-node1]root@solaris:~#
Luego, ponga el grupo de recursos de HA-SAM en línea y pruebe la configuración.
Inicie sesión en el nodo principal del cluster HA-SAM como root.
En el ejemplo, sam1mds-node1 es el nodo principal:
[sam1mds-node1]root@solaris:~#
Establezca en línea el grupo de recursos. Utilice los comandos de Solaris Cluster clresourcegroup manage groupname y clresourcegroup online -emM groupname, donde groupname es el nombre del grupo de recursos de HA-SAM.
En el ejemplo, ponemos el grupo de recursos has-rg en línea:
[sam1mds-node1]root@solaris:~# clresourcegroup manage has-rg [sam1mds-node1]root@solaris:~# clresourcegroup online -emM has-rg [sam1mds-node1]root@solaris:~#
Asegúrese de que el grupo de recursos de HA-SAM esté en línea. Use el comando clresourcegroup status de Solaris Cluster.
En el ejemplo, el grupo de recursos has-rg está online en el nodo principal, sam1mds-node1:
[sam1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ has-rg sam1mds-node1 No Online sam1mds-node2 No Offline [sam1mds-node1]root@solaris:~#
A continuación, asegúrese de que el grupo de recursos realice el failover correctamente. Mueva el grupo de recursos al nodo secundario. Use el comando de Solaris Cluster clresourcegroup switch -n node2 groupname, donde node2 es el nombre del nodo secundario y groupname es el nombre que eligió para el grupo de recursos de HA-SAM. A continuación, use clresourcegroup status para comprobar el resultado.
En el ejemplo, movemos el grupo de recursos has-rg a sam1mds-node2 y confirmamos que el grupo de recursos quedará en línea en el nodo especificado:
[sam1mds-node1]root@solaris:~# clresourcegroup switch -n sam1mds-node2 has-rg [sam1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ has-rg sam1mds-node1 No Offline sam1mds-node2 No Online [sam1mds-node1]root@solaris:~#
Mueva el grupo de recursos nuevamente al nodo principal. Use el comando de Solaris Cluster clresourcegroup switch -n node1 groupname, donde node1 es el nombre del nodo principal y groupname es el nombre que eligió para el grupo de recursos de HA-SAM. A continuación, use clresourcegroup status para comprobar el resultado.
En el ejemplo, movemos correctamente el grupo de recursos has-rg nuevamente a sam1mds-node1:
[sam1mds-node1]root@solaris:~# clresourcegroup switch -n sam1mds-node1 has-rg [sam1mds-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ has-rg sam1mds-node1 No Online sam1mds-node2 No Offline [sam1mds-node1]root@solaris:~#
Si es necesario, configure el uso compartido del sistema de archivos de red de alta disponibilidad (HA-NFS).
En la Guía del servicio de datos de Oracle Solaris Cluster Data para el sistema de archivos de red (NFS)que se incluye en la biblioteca de documentación en línea Oracle Solaris Cluster se incluyen los procedimientos detallados para configurar HA-NFS.
Si planea usar la función de base de datos de banda lateral, vaya a Configuración de la base de datos de informes.
En caso contrario, vaya a Configuración de notificaciones y registro.
En la configuración de Solaris Cluster-Oracle Real Application Cluster (SC-RAC), el software de Solaris Cluster gestiona un sistema de archivos compartido QFS como recurso SUNW.qfs montado en los nodos que también alojan el software Oracle Database y Oracle Real Application Cluster (RAC). Todos los nodos están configurados como servidores de QFS, uno como servidor de metadatos activo y el resto como servidores de metadatos posibles. Si el nodo de metadatos activo falla, el software Solaris Cluster activa automáticamente un servidor de metadatos posible en un nodo activo e inicia el failover. La E/S se coordina mediante Oracle RAC y el sistema de archivos QFS se comparte y ya está montado en todos los nodos. Por lo tanto, el acceso a los datos permanece sin interrupciones.
En la configuración de SC-RAC, el software RAC coordina las solicitudes de E/S, distribuye la carga de trabajo y mantiene un conjunto único y coherente de archivos de base de datos para varias instancias de Oracle Database que se ejecutan en los nodos de un cluster. Dado que la integridad del sistema de archivos se garantiza según RAC, los servidores de metadatos posibles de QFS pueden realizar la E/S como clientes del sistema de archivos compartido. Para obtener información adicional, consulte la documentación de Oracle Solaris Cluster Data Service para Oracle Real Application Clusters en la biblioteca de documentación en línea de Oracle Solaris Cluster.
Para configurar un sistema de archivos SC-RAC, realice las siguientes tareas:
Creación de archivos de hosts locales en servidores QFS y clientes fuera del cluster HA-COTC
Configuración de un servidor de metadatos activo de QFS en el nodo de cluster SC-RAC principal o Configuración de servidores de metadatos de QFS en nodos SC-RAC mediante el uso del almacenamiento RAID
Configuración de un servidor de metadatos posible de QFS en los nodos de cluster SC-RAC restantes
Configurar el failover de los servidores de metadatos HA-RAC
Si es necesario, configure los recursos compartidos del sistema de archivos de red (NFS), como se describe en Acceso a sistemas de archivos desde varios hosts mediante el uso de NFS y SMB/CIFS. El NFS de alta disponibilidad (HA-NFS) no se admite.
En un sistema de archivos compartido QFS, debe configurar un archivo de hosts en los servidores de metadatos, de modo que todos los hosts puedan acceder a los metadatos para el sistema de archivos. El archivo de hosts se almacena junto con el archivo mcf en el directorio /etc/opt/SUNWsamfs/. Durante la creación inicial de un sistema de archivos compartido, el comando sammkfs -S configura el uso compartido mediante los parámetros de configuración almacenados en este archivo. Por lo tanto, créelo ahora, utilizando el procedimiento que se indica a continuación.
Inicie sesión en el nodo principal del cluster SC-RAC como root.
En el ejemplo, el nodo principal es qfs1rac-node1:
[qfs1rac-node1]root@solaris:~#
Muestre la configuración del cluster. Use el comando /usr/global/bin/cluster show. En la salida, ubique el registro de cada Node Name y observe los nombres privatehostname y Transport Adapter y la propiedad ip_address de cada adaptador de red.
En los ejemplos, cada nodo tiene dos interfaces de red, qfe3 y hme0:
Los adaptadores hme0 tienen direcciones IP en la red privada que usa el cluster para comunicaciones internas entre nodos. El software Solaris Cluster asigna un privatehostname correspondiente a cada dirección privada.
De forma predeterminada, el nombre del host privado del nodo principal es clusternode1-priv y el nombre del host privado del nodo secundario es clusternode2-priv.
Los adaptadores qfe3 tienen direcciones IP públicas y nombres de host públicos, qfs1rac-node1 y qfs1rac-node2, que el cluster usa para transporte de datos.
Observe que la visualización ha sido abreviada mediante el uso de marcas de elipsis (...):
[qfs1rac-node1]root@solaris:~# cluster show
...
=== Cluster Nodes ===
Node Name: qfs1rac-node1...
privatehostname: clusternode1-priv...
Transport Adapter List: qfe3, hme0...
Transport Adapter: qfe3...
Adapter Property(ip_address): 172.16.0.12...
Transport Adapter: hme0...
Adapter Property(ip_address): 10.0.0.129...
Node Name: qfs1rac-node2...
privatehostname: clusternode2-priv...
Transport Adapter List: qfe3, hme0...
Adapter Property(ip_address): 172.16.0.13...
Transport Adapter: hme0
Adapter Property(ip_address): 10.0.0.122...
Node Name: qfs1rac-node3...
privatehostname: clusternod3-priv...
Transport Adapter List: qfe3, hme0...
Adapter Property(ip_address): 172.16.0.33...
Transport Adapter: hme0
Adapter Property(ip_address): 10.0.0.092
Mediante el uso del editor de texto, cree el archivo /etc/opt/SUNWsamfs/hosts.family-set-name, donde family-set-name es el nombre del conjunto de familias que el archivo /etc/opt/SUNWsamfs/mcf asigna al equipo del sistema de archivos.
En el ejemplo, creamos el archivo hosts.qfs1rac mediante el editor de texto vi. Agregamos algunos encabezados opcionales para mostrar las columnas en la tabla de hosts, comenzando cada línea con el signo de numeral (#) para indicar un comentario:
[qfs1rac-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/hosts.qfs1rac # /etc/opt/SUNWsamfs/hosts.qfs1rac # Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ----------
En la primera columna de la tabla, introduzca los nombres de host de los nodos de servidor de metadatos principal y secundario, seguidos de algunos espacios. Coloque cada entrada en una línea separada.
En un archivo de hosts, las líneas son filas (registros) y los espacios son separadores de columnas (campos). En el ejemplo, la columna Host Name de las dos primeras filas muestra los nombres de host de los nodos de cluster qfs1rac-node1, qfs1rac-node2 y qfs1rac-node3.
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 qfs1rac-node2 qfs1rac-node3
En la segunda columna de cada línea, comience proporcionando información de Network Interface para el host Host Name. Introduzca cada nombre de host privado de Solaris Cluster del nodo de cluster SC-RAC o la dirección de red privada seguida por una coma.
Los nodos de servidor SC-RAC usan nombres de host privados para comunicaciones de servidor a servidor dentro del cluster de alta disponibilidad. En el ejemplo, usamos los nombres de host privados clusternode1-priv, clusternode2-priv y clusternode3-priv, que son los nombres predeterminados asignados por el software Solaris Cluster:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv, qfs1rac-node2 clusternode2-priv, qfs1rac-node3 clusternode3-priv,
Después de la coma que aparece en la segunda columna de cada línea, introduzca un nombre de host público para el servidor de metadatos activo, seguido por espacios.
Los nodos del servidor SC-RAC usan una red de datos públicos para comunicarse con los clientes, todos residen fuera del cluster. Dado que la dirección IP y el nombre de host del servidor de metadatos activo cambian durante el failover (de qfs1rac-node1 a qfs1rac-node2, por ejemplo), representamos el servidor activo con un nombre de host virtual, qfs1rac-mds. Posteriormente, configuraremos el software Solaris Cluster para que siempre enrute las solicitudes para qfs1rac-mds al nodo que actualmente aloja el servidor de metadatos activo:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv,qfs1rac-mds qfs1rac-node2 clusternode2-priv,qfs1rac-mds qfs1rac-node3 clusternode3-priv,qfs1rac-mds
En la tercera columna de cada línea, introduzca el número ordinal del servidor (1 para el servidor de metadatos activo y 2 para el servidor de metadatos posible), seguido por espacios.
En el ejemplo, el nodo principal, qfs1rac-node1, es el servidor de metadatos activo: Por lo tanto, es el ordinal 1. El segundo nodo, qfs1rac-node2 es el ordinal 2, etc.:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv,qfs1rac-mds 1 qfs1rac-node2 clusternode2-priv,qfs1rac-mds 2 qfs1rac-node3 clusternode3-priv,qfs1rac-mds 3
En la cuarta columna de cada línea, introduzca 0 (cero), seguido por espacios.
El valor 0, - (guión) o en blanco en la cuarta columna indica que el host está on, es decir, configurado con acceso al sistema de archivos compartido. El valor 1 (numeral uno) indica que el host está off, es decir, configurado pero sin acceso al sistema de archivos (para obtener información sobre el uso de estos valores para administrar sistemas de archivos compartidos, consulte la página del comando man samsharefs).
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv,qfs1rac-mds 1 0 qfs1rac-node2 clusternode2-priv,qfs1rac-mds 2 0 qfs1rac-node3 clusternode3-priv,qfs1rac-mds 3 0
En la quinta columna de la línea del nodo principal, introduzca la palabra clave server. Guarde el archivo y cierre el editor.
La palabra clave del servidor identifica el servidor de metadatos activo predeterminado:
# Server On/ Additional #Host Name Network Interface Ordinal Off Parameters #------------ -------------------------------- ------- --- ---------- qfs1rac-node1 clusternode1-priv,qfs1rac-mds 1 0 server qfs1rac-node2 clusternode2-priv,qfs1rac-mds 2 0 qfs1rac-node3 clusternode3-priv,qfs1rac-mds 2 0 :wq [qfs1rac-node1]root@solaris:~#
Coloque una copia del archivo /etc/opt/SUNWsamfs/hosts.family-set-name global en cada nodo del cluster SC-RAC.
Ahora configure un servidor de metadatos QFS activo en el nodo principal del cluster SC-RAC.
Seleccione el nodo de cluster que actuará como nodo principal para el cluster SC-RAC y el servidor de metadatos activo para el sistema de archivos compartido QFS. Inicie sesión como usuario root.
En el ejemplo, el nodo principal es qfs1rac-node1:
[qfs1rac-node1]root@solaris:~#
Seleccione los dispositivos de almacenamiento global que se usarán para el sistema de archivos QFS. Use el comando /usr/global/bin/cldevice list -v.
El software Solaris Cluster asigna identificadores de dispositivo (DID) únicos a todos los dispositivos que se conectan a los nodos de cluster. Se puede acceder a los dispositivos globales desde todos los nodos del cluster, y se puede acceder a los dispositivos locales únicamente desde los hosts que los montan. Los dispositivos globales permanecen accesibles después del failover. Los dispositivos locales no.
En el ejemplo, tenga en cuenta que no se puede acceder a los dispositivos d1, d2, d6, d7 o d8 desde todos los nodos. Por lo tanto, seleccionamos entre los dispositivos d3, d4 y d5 cuando se configura el sistema de archivos compartido QFS de alta disponibilidad:
[qfs1rac-node1]root@solaris:~# cldevice list -v DID Device Full Device Path ---------- ---------------- d1 qfs1rac-node1:/dev/rdsk/c0t0d0 d2 qfs1rac-node1:/dev/rdsk/c0t6d0 d3 qfs1rac-node1:/dev/rdsk/c1t1d0 d3 qfs1rac-node2:/dev/rdsk/c1t1d0 d3 qfs1rac-node3:/dev/rdsk/c1t1d0 d4 qfs1rac-node1:/dev/rdsk/c1t2d0 d4 qfs1rac-node2:/dev/rdsk/c1t2d0 d4 qfs1rac-node3:/dev/rdsk/c1t2d0 d5 qfs1rac-node1:/dev/rdsk/c1t3d0 d5 qfs1rac-node2:/dev/rdsk/c1t3d0 d5 qfs1rac-node3:/dev/rdsk/c1t3d0 d6 qfs1rac-node2:/dev/rdsk/c0t0d0 d7 qfs1rac-node2:/dev/rdsk/c0t1d0 d8 qfs1rac-node3:/dev/rdsk/c0t1d0
Cree un sistema de archivos compartido ma de alto rendimiento que use dispositivos de datos mr. En un editor de texto, abra el archivo /etc/opt/SUNWsamfs/mcf.
En el ejemplo, configuramos el sistema de archivos qfs1rac. Configuramos el dispositivo d3 como dispositivo de metadatos (tipo de equipo mm) y usamos d4 y d5 como dispositivos de datos (tipo de equipo mr):
[qfs1rac-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ -------------- qfs1rac 100 ma qfs1rac - /dev/did/dsk/d3s0 101 mm qfs1rac - /dev/did/dsk/d4s0 102 mr qfs1rac - /dev/did/dsk/d5s0 103 mr qfs1rac - ...
En el archivo /etc/opt/SUNWsamfs/mcf, introduzca el parámetro shared en la columna Additional Parameters de la entrada del sistema de archivos. Guarde el archivo.
[qfs1rac-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters #------------------ --------- --------- ------- ------ -------------- qfs1rac 100 ma qfs1rac - shared /dev/did/dsk/d3s0 101 mm qfs1rac - /dev/did/dsk/d4s0 102 mr qfs1rac - /dev/did/dsk/d5s0 103 mr qfs1rac - ... :wq [qfs1rac-node1]root@solaris:~#
Revise el archivo mcf para detectar errores. Use el comando /opt/SUNWsamfs/sbin/sam-fsd y corrija los errores que encuentre.
El comando sam-fsd lee los archivos de configuración de Oracle HSM e inicializa los sistemas de archivos. Se detendrá si detecta un error. En el ejemplo, comprobamos el archivo mcf en el host qfs1rac-node1:
[qfs1rac-node1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1rac-node1]root@solaris:~#
Cree el sistema de archivos. Use el comando /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, donde family-set-name es el identificador de equipo del sistema de archivos.
El comando sammkfs lee los archivos hosts.family-set-name y mcf y crea un sistema de archivos compartido con las propiedades especificadas.
[qfs1rac-node1]root@solaris:~# sammkfs -S qfs1rac Building 'qfs1rac' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [qfs1rac-node1]root@solaris:~#
Abra el archivo /etc/vfstab del sistema operativo en un editor de texto e inicie una línea para el nuevos sistema de archivos. Introduzca el nombre del sistema de archivos en la primera columna, espacios, un guión en la segunda columna y más espacios.
En el ejemplo, utilizamos el editor de texto vi. Iniciamos una línea para el sistema de archivos qfs1rac. El guión evita que el sistema operativo intente comprobar la integridad del sistema de archivos mediante las herramientas del UFS:
[qfs1rac-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- --------------- ------ ---- ------- ------------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac -
En la tercera columna del archivo /etc/vfstab, introduzca el punto de montaje del sistema de archivos relacionado con el cluster. Especifique un subdirectorio que no se encuentre debajo del directorio raíz del sistema.
El montaje de un sistema de archivos QFS compartido inmediatamente debajo de la raíz puede ocasionar problemas de failover si se usa el tipo de recurso SUNW.qfs. En el ejemplo, el punto de montaje del sistema de archivos qfs1rac es /global/sc-rac/qfs1rac:
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ----------------------- ------ ---- ------- ----------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs1rac - /global/sc-rac/qfs1rac
Introduzca el tipo de sistema de archivos, samfs, en la cuarta columna, - (guion) en la quinta columna y no en la sexta columna.
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ----------------------- ------ ---- ------- ---------- /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac - /global/sc-rac/qfs1rac samfs - no :wq [qfs1rac-node1]root@solaris:~#
En la séptima columna del archivo /etc/vfstab, introduzca las siguientes opciones de montaje. Luego, guarde el archivo y cierre el editor.
Las siguientes opciones de montaje se recomiendan para la configuración de cluster de SC-RAC. Se pueden especificar aquí, en /etc/vfstab o en el archivo /etc/opt/SUNWsamfs/samfs.cmd, si es más conveniente:
shared
stripe=1
sync_meta=1
mh_write
qwrite
forcedirectio
notrace
rdlease=300
wrlease=300
aplease=300
En el ejemplo, se ha abreviado la lista para que se ajuste al diseño de la página:
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- -------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac - /global/sc-rac/qfs1rac samfs - no shared,...=300 :wq [qfs1rac-node1]root@solaris:~#
Cree el punto de montaje para el sistema de archivos compartido de alta disponibilidad.
[qfs1rac-node1]root@solaris:~# mkdir -p /global/sc-rac/qfs1rac [qfs1rac-node1]root@solaris:~#
Monte el sistema de archivos compartido de alta disponibilidad en el nodo principal.
[qfs1rac-node1]root@solaris:~# mount /global/sc-rac/qfs1rac [qfs1rac-node1]root@solaris:~#
Luego, configure un servidor de metadatos QFS posible en los nodos del cluster SC-RAC restantes.
Los nodos restantes del cluster funcionan como servidores de metadatos posibles. Un servidor de metadatos posible es un host que puede acceder a los dispositivos de metadatos y, por lo tanto, puede asumir las tareas de un servidor de metadatos. Por lo tanto, si el servidor de metadatos activo en el nodo principal falla, el software Solaris Cluster puede realizar el failover en el nodo secundario y activar el servidor de metadatos posible.
Para cada nodo restante en el cluster SC-RAC, realice lo siguiente:
Inicie sesión en el nodo como root.
En el ejemplo, el nodo actual es qfs1rac-node2:
[qfs1rac-node2]root@solaris:~#
Copie el archivo /etc/opt/SUNWsamfs/mcf del nodo principal en el nodo actual.
Revise el archivo mcf para detectar errores. Ejecute del comando /opt/SUNWsamfs/sbin/sam-fsd y corrija los errores que encuentre.
El comando sam-fsd lee los archivos de configuración de Oracle HSM e inicializa los sistemas de archivos. Se detendrá si detecta un error. En el ejemplo, comprobamos el archivo mcf en el host qfs1rac-node2:
[qfs1rac-node2]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs1rac-node2]root@solaris:~#
Abra el archivo /etc/vfstab del sistema operativo en un editor de texto e inicie una línea para el nuevos sistema de archivos.
En el ejemplo, utilizamos el editor vi:
[qfs1rac-node2]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac - /global/sc-rac/qfs1rac samfs - no
En la séptima columna del archivo /etc/vfstab, introduzca las siguientes opciones de montaje. Luego, guarde el archivo y cierre el editor.
Las siguientes opciones de montaje se recomiendan para la configuración de cluster de SC-RAC. Se pueden especificar aquí, en /etc/vfstab o en el archivo /etc/opt/SUNWsamfs/samfs.cmd, si es más conveniente:
shared
stripe=1
sync_meta=1
mh_write
qwrite
forcedirectio
notrace
rdlease=300
wrlease=300
aplease=300
En el ejemplo, se ha abreviado la lista para que se ajuste al diseño de la página:
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs1rac - /global/sc-rac/qfs1rac samfs - no shared,...=300 :wq [qfs1rac-node2]root@solaris:~#
Cree el punto de montaje para el sistema de archivos compartido de alta disponibilidad en el nodo secundario.
[qfs1rac-node2]root@solaris:~# mkdir -p /global/sc-rac/qfs1rac [qfs1rac-node2]root@solaris:~#
Monte el sistema de archivos compartido de alta disponibilidad en el nodo secundario.
[qfs1rac-node2]root@solaris:~# mount /global/sc-rac/qfs1rac [qfs1rac-node2]root@solaris:~#
Ahora configure el failover de los servidores de metadatos SC-RAC.
Cuando aloja un sistema de archivos compartido Oracle HSM en un cluster gestionado por el software Solaris Cluster, configura el failover de los servidores de metadatos mediante la creación de un recurso de clusters SUNW.qfs, un tipo de recurso definido por el software Oracle HSM (consulte la página del comando man SUNW.qfs para obtener más información). Para crear y configurar el recurso para una configuración de SC-RAC, realice lo siguiente:
Inicie sesión en el nodo principal del cluster SC-RAC como root.
En el ejemplo, el nodo principal es qfs1rac-node1:
[qfs1rac-node1]root@solaris:~#
Defina el tipo de recurso QFS, SUNW.qfs, para el software Solaris Cluster. Use el comando clresourcetype registerSUNW.qfs.
[qfs1rac-node1]root@solaris:~# clresourcetype registerSUNW.qfs [qfs1rac-node1]root@solaris:~#
Si el registro falla porque no se puede encontrar el archivo de registro, coloque un enlace simbólico al directorio /opt/SUNWsamfs/sc/etc/, en el directorio donde Solaris Cluster mantiene los archivos de registro de tipo de recurso, /opt/cluster/lib/rgm/rtreg/.
No instaló el software Oracle Solaris Cluster antes de instalar el software Oracle HSM. Normalmente, Oracle HSM proporciona automáticamente la ubicación del archivo de registro SUNW.qfs cuando detecta a Solaris Cluster durante la instalación. Deberá crear un enlace manualmente.
[qfs1rac-node1]root@solaris:~# cd /opt/cluster/lib/rgm/rtreg/ [qfs1rac-node1]root@solaris:~# ln -s /opt/SUNWsamfs/sc/etc/SUNW.qfs SUNW.qfs [qfs1rac-node1]root@solaris:~#
Cree un grupo de recursos para el servidor de metadatos de QFS. Use el comando de Solaris Cluster clresourcegroup create -n node-list group-name, donde node-list es una lista delimitada por comas de los nombres de nodo de cluster y group-name es el nombre que deseamos usar para el grupo de recursos.
En el ejemplo, se crea el grupo de recursos qfsracrg con los nodos de servidor de SC-RAC como miembros (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa).
[qfs1rac-node1]root@solaris:~# clresourcegroup create \ -n qfs1rac-node1,qfs1rac-node2 qfsracrg [qfs1rac-node1]root@solaris:~#
En el nuevo grupo de recursos, configuramos un nombre de host virtual para el servidor de metadatos activo. Use el comando de Solaris Cluster clreslogicalhostname create -g group-name, donde group-name es el nombre del grupo de recursos de QFS y virtualMDS es el nombre de host virtual.
Use el mismo nombre de host virtual que usó en los archivos de host para el sistema de archivos compartido. En el ejemplo, se crea el host virtual qfs1rac-mds en el grupo de recursos qfsracrg (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[qfs1rac-node1]root@solaris:~# clreslogicalhostname create \ -g qfsracrg qfs1rac-mds [qfs1rac-node1]root@solaris:~#
Agregue los recursos del sistema de archivos QFS al grupo de recursos. Utilice el comando clresource create -g group-name -t SUNW.qfs -x QFSFileSystem=mount-point -y Resource_dependencies=virtualMDS resource-name, donde:
group-name es el nombre del grupo de recursos de QFS.
mount-point es el punto de montaje para el sistema de archivos en el cluster, un subdirectorio que no está directamente debajo del directorio raíz del sistema.
El montaje de un sistema de archivos QFS compartido inmediatamente debajo de la raíz puede ocasionar problemas de failover si se usa el tipo de recurso SUNW.qfs.
virtualMDS es el nombre del host virtual del servidor de metadatos activo.
resource-name es el nombre que desea otorgar al recurso.
En el ejemplo, creamos un recurso denominado scrac del tipo SUNW.qfs en el grupo de recursos qfsracrg. Se establece la propiedad de extensión SUNW.qfs de QFSFileSystem en el punto de montaje /global/sc-rac/qfs1rac. Se establece la propiedad estándar Resource_dependencies en el host lógico para el servidor de metadatos activo, qfs1rac-mds (tenga en cuenta que el siguiente comando se introduce como una sola línea, los saltos de línea se identifican por el carácter de barra diagonal inversa):
[qfs1rac-node1]root@solaris:~# create -g qfsracrg -t SUNW.qfs \ -x QFSFileSystem=/global/sc-rac/qfs1rac \ -y Resource_dependencies=qfs1rac-mds scrac [qfs1rac-node1]root@solaris:~#
Establezca en línea el grupo de recursos. Use los comandos de Solaris Cluster clresourcegroup manage group-name and clresourcegroup online -emM group-name, donde group-name es el nombre del grupo de recursos de QFS.
En el ejemplo, ponemos el grupo de recursos qfsracrg en línea:
[qfs1rac-node1]root@solaris:~# clresourcegroup manage qfsracrg [qfs1rac-node1]root@solaris:~# clresourcegroup online -emM qfsracrg [qfs1rac-node1]root@solaris:~#
Asegúrese de que el grupo de recursos de QFS esté en línea. Use el comando clresourcegroup status de Solaris Cluster.
En el ejemplo, el grupo de recursos qfsracrg está online en el nodo principal, qfs1rac-node1:
[qfs1rac-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsracrg qfs1rac-node1 No Online qfs1rac-node2 No Offline qfs1rac-node3 No Offline [qfs1rac-node1]root@solaris:~#
Asegúrese de que el grupo de recursos realice el failover correctamente. Mueva el grupo de recursos al nodo secundario. Use el comando de Solaris Cluster clresourcegroup switch -n node2 group-name, donde node2 es el nombre del nodo secundario y group-name es el nombre que eligió para el grupo de recursos de HA-SAM. A continuación, use clresourcegroup status para comprobar el resultado.
En el ejemplo, movemos el grupo de recursos qfsracrg a qfs1rac-node2 y qfs1rac-node3, y confirmamos que el grupo de recursos estará en línea en el nodo especificado:
[qfs1rac-node1]root@solaris:~# clresourcegroup switch -n qfs1rac-node2 qfsracrg [qfs1rac-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsracrg qfs1rac-node1 No Offline qfs1rac-node2 No Online qfs1rac-node3 No Offline [qfs1rac-node1]root@solaris:~# clresourcegroup switch -n qfs1rac-node3 qfsracrg [qfs1rac-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ qfsracrg qfs1rac-node1 No Offline qfs1rac-node2 No Offline qfs1rac-node3 No Online [qfs1rac-node1]root@solaris:~#
Mueva el grupo de recursos nuevamente al nodo principal. Use el comando de Solaris Cluster clresourcegroup switch -n node1 group-name, donde node1 es el nombre del nodo principal y group-name es el nombre que eligió para el grupo de recursos de HA-SAM. A continuación, use clresourcegroup status para comprobar el resultado.
En el ejemplo, movemos correctamente el grupo de recursos qfsracrg nuevamente a qfs1rac-node1:
[qfs1rac-node1]root@solaris:~# clresourcegroup switch -n qfs1rac-node1 qfsracrg [qfs1rac-node1]root@solaris:~# clresourcegroup status === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- ------------- --------- ------ samr qfs1rac-node1 No Online qfs1rac-node2 No Offline qfs1rac-node3 No Offline [qfs1rac-node1]root@solaris:~#
Si planea usar la función de base de datos de banda lateral, vaya a Configuración de la base de datos de informes.
En caso contrario, vaya a Configuración de notificaciones y registro.
Un sistema de archivos de alta disponibilidad debe almacenar datos y metadatos en los dispositivos de almacenamiento principales redundantes. El hardware de matriz de disco redundante puede proporcionar esta redundancia mediante el uso de RAID-1 o RAID-10 para metadatos y RAID-5 para datos. Sin embargo, si necesita usar dispositivos de disco SCSI simples de dos puertos o una matriz de JBOD (solo un grupo de discos) como almacenamiento principal, deberá proporcionar la redundancia necesaria en el software.
Por este motivo, la configuración de SC-RAC admite configuraciones RAID basadas en conjuntos de discos de múltiples propietarios de Oracle Solaris Volume Manager (SVM). En esta sección, se describen los pasos básicos que deberá llevar a cabo cuando configure esta variante de la configuración del sistema de archivos SC-RAC.
Tenga en cuenta que deberá usar Solaris Volume Manager exclusivamente para gestión de la matriz de almacenamiento redundante. No concatene el almacenamiento en dispositivos separados. Esto distribuye la E/S a los dispositivos de componentes de manera ineficiente y degrada el rendimiento del sistema de archivos QFS.
Lleve a cabo las siguientes tareas:
Crear grupos de discos de múltiples propietarios de Solaris Volume Manager
Creación de volúmenes reflejados para los datos y metadatos de QFS
Solaris Volume Manager (SVM) ya no se incluye con Solaris a partir de Solaris 11. Pero el software de Solaris Cluster 4 sigue admitiendo Solaris Volume Manager. De modo que, para usar el software, deberá descargar e instalar la versión que se incluía en la versión de Solaris 10 9/10. Para cada nodo del cluster, realice lo siguiente:
Inicie sesión en el nodo como root.
En los siguientes ejemplos, se configura el nodo de cluster qfs2rac-node1 mediante Solaris Image Packaging System (IPS):
[qfs2rac-node1]root@solaris:~#
Compruebe si existen paquetes Solaris Volume Manager (SVM) disponibles de forma local. Use el comando pkg info svm.
[qfs2rac-node1]root@solaris:~# pkg info svm pkg: info: no packages matching the following patterns you specified are installed on the system. Try specifying -r to query remotely: svm [qfs2rac-node1]root@solaris:~#
Si no se encuentran paquetes locales, compruebe el repositorio de Solaris Image Packaging System (IPS). Use el comando pkg -r svm.
[qfs2rac-node1]root@solaris:~# pkg -r svm Name: storage/svm Summary: Solaris Volume Manager Description: Solaris Volume Manager commands Category: System/Core State: Not installed Publisher: solaris Version: 0.5.11 Build Release: 5.11 Branch: 0.175.0.0.0.2.1 Packaging Date: October 19, 2011 06:42:14 AM Size: 3.48 MB FMRI: pkg://solaris/storage/svm@0.5.11,5.11-0.175.0.0.0.2.1:20111019T064214Z [qfs2rac-node1]root@solaris:~#
Instale el paquete. Utilice el comando pkg install storage/svm:
[qfs2rac-node1]root@solaris:~# pkg install storage/svm Packages to install: 1 Create boot environment: No Create backup boot environment: Yes Services to change: 1 DOWNLOAD PKGS FILES XFER (MB) Completed 1/1 104/104 1.6/1.6 PHASE ACTIONS Install Phase 168/168 PHASEITEMS Package State Update Phase 1/1 Image State Update Phase 2/2 [qfs2rac-node1]root@solaris:~#
Cuando finalice la instalación, compruebe la ubicación de metadb. Use el comando which metadb.
[qfs2rac-node1]root@solaris:~# which metadb /usr/sbin/metadb [qfs2rac-node1]root@solaris:~#
Compruebe la instalación. Use el comando metadb.
[qfs2rac-node1]root@solaris:~# metadb
[qfs2rac-node1]root@solaris:~#
Si metadb devuelve un error, consulte si el archivo kernel/drv/md.conf existe.
[qfs2rac-node1]root@solaris:~# metadb metadb: <HOST>: /dev/md/admin: No such file or directory [qfs2rac-node1]root@solaris:~# ls -l /kernel/drv/md.conf -rw-r--r-- 1 root sys 295 Apr 26 15:07 /kernel/drv/md.conf [qfs2rac-node1]root@solaris:~#
Si el archivo kernel/drv/md.conf no existe, créelo. Otorgue a root la propiedad del archivo y a sys la propiedad del grupo. Establezca los permisos en 644.
En el ejemplo, cremamos el archivo con el editor vi. El contenido del archivo será similar a esto:
[qfs2rac-node1]root@solaris:~# vi kernel/drv/md.conf ################################################### #pragma ident "@(#)md.conf 2.1 00/07/07 SMI" # # Copyright (c) 1992-1999 by Sun Microsystems, Inc. # All rights reserved. # name="md" parent="pseudo" nmd=128 md_nsets=4; #################################################### :wq [qfs2rac-node1]root@solaris:~# chown root:sys kernel/drv/md.conf [qfs2rac-node1]root@solaris:~# chmod 644 [qfs2rac-node1]root@solaris:~#
Vuelva a examinar de forma dinámica el archivo md.conf y asegúrese de que el árbol del dispositivo esté actualizado. Use el comando update_drv -f md:
En el ejemplo, se ha actualizado el árbol del dispositivo. De modo que Solaris Volume Manager está instalado:
[qfs2rac-node1]root@solaris:~# update_drv -f md [qfs2rac-node1]root@solaris:~# ls -l /dev/md/admin lrwxrwxrwx 1 root root 31 Apr 20 10:12 /dev/md/admin -> ../../devices/pseudo/md@0:admin [qfs2rac-node1]root@solaris:~#
Luego, cree grupos de discos de múltiples propietarios de Solaris Volume Manager (SVM).
Inicie sesión en todos los nodos en la configuración de SC-RAC como root.
En el ejemplo, iniciamos sesión en el nodo qfs2rac-node1. A continuación, abrimos las ventanas del terminal y usamos ssh para iniciar sesión en los nodos qfs2rac-node2 y qfs2rac-node3:
[qfs2rac-node1]root@solaris:~# [qfs2rac-node1]root@solaris:~# ssh root@qfs2rac-node2 Password: [qfs2rac-node2]root@solaris:~# [qfs2rac-node1]root@solaris:~# ssh root@qfs2rac-node3 Password: [qfs2rac-node3]root@solaris:~#
Si está usando Oracle Solaris Cluster 4.x en Solaris 11.x o posterior y todavía no lo ha hecho, instale Solaris Volume Manager en cada nodo antes de continuar.
A partir de Solaris 11, Solaris Volume Manager no está instalado por defecto.
En cada nodo, conecte un nuevo dispositivo de base de datos de estado y cree tres réplicas de base de datos de estado. Utilice el comando metadb -a -f -c3 device-name, donde device-name es el nombre de un dispositivo físico en el formato cXtYdYsZ.
No use identificadores de dispositivos (DID) de Solaris Cluster. Use el nombre del dispositivo físico. En el ejemplo, creamos dispositivos de base de datos de estado en los tres nodos de cluster:
[qfs2rac-node1]root@solaris:~# metadb -a -f -c3 /dev/rdsk/c0t0d0 [qfs2rac-node2]root@solaris:~# metadb -a -f -c3 /dev/rdsk/c0t6d0 [qfs2rac-node3]root@solaris:~# metadb -a -f -c3 /dev/rdsk/c0t4d0
Cree un grupo de discos de múltiples propietarios de Solaris Volume Manager en un nodo. Utilice el comando metaset -sdiskset -M -a -h host-list, donde host-list es una lista de propietarios delimitada por espacios.
Solaris Volume Manager admite hasta cuatro hosts por conjunto de discos. En el ejemplo, se crea el grupo de discos datadisks en qfs2rac-node1 y se especifican los tres nodos qfs2rac-node1, qfs2rac-node2 y qfs2rac-node3 como propietarios (tenga en cuenta que el siguiente comando se introduce como una sola línea, el salto de línea se identifica por el carácter de barra diagonal inversa):
[qfs2rac-node1]root@solaris:~# metaset -s datadisks -M -a -h qfs2rac-node1 \ qfs2rac-node2 qfs2rac-node3
Enumere los dispositivos en uno de los nodos. Use el comando de Solaris Cluster cldevice list -n -v.
[qfs2rac-node1]root@solaris:~# cldevice list -n -v DID Device Full Device Path ---------- ---------------- d13 qfs2rac-node1:/dev/rdsk/c6t600C0FF00000000000332B62CF3A6B00d0 d14 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E950F1FD9600d0 d15 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E9124FAF9C00d0 ... [qfs2rac-node1]root@solaris:~#
En la salida del comando cldevice list -n -v, seleccione los dispositivos que se reflejarán.
En el ejemplo, seleccionamos cuatro pares de dispositivos para cuatro reflejos: d21 y d13, d14 y d17, d23 y d16, y d15 y d19.
[qfs2rac-node1]root@solaris:~# cldevice list -n -v DID Device Full Device Path ---------- ---------------- d13 qfs2rac-node1:/dev/rdsk/c6t600C0FF00000000000332B62CF3A6B00d0 d14 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E950F1FD9600d0 d15 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E9124FAF9C00d0 d16 qfs2rac-node1:/dev/rdsk/c6t600C0FF00000000000332B28488B5700d0 d17 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000086DB474EC5DE900d0 d18 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E975EDA6A000d0 d19 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000086DB47E331ACF00d0 d20 qfs2rac-node1:/dev/rdsk/c6t600C0FF0000000000876E9780ECA8100d0 d21 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000004CAD5B68A7A100d0 d22 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000086DB43CF85DA800d0 d23 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000004CAD7CC3CDE500d0 d24 qfs2rac-node1:/dev/rdsk/c6t600C0FF000000000086DB4259B272300d0 .... [qfs2rac-node1]root@solaris:~#
Agregue los dispositivos seleccionados al conjunto de discos en el mismo nodo. Use el comando metaset -a devicelist, donde devicelist es una lista delimitada por espacios de uno o más identificadores de dispositivos de cluster.
En el ejemplo, se agregan los discos enumerados a un conjunto de discos de múltiples propietarios dataset1 (tenga en cuenta que el siguiente comando se introduce como una sola línea, los saltos de línea se identifican por el carácter de barra diagonal inversa):
[qfs2rac-node1]root@solaris:~# metaset -s dataset1 -M -a -h /dev/did/rdsk/d21 \ /dev/did/rdsk/d13 /dev/did/rdsk/d14 /dev/did/rdsk/d17 /dev/did/rdsk/d23 \ /dev/did/rdsk/d16 /dev/did/rdsk/d15 /dev/did/rdsk/d19 [qfs2rac-node1]root@solaris:~#
A continuación, cree volúmenes reflejados para los datos y metadatos de QFS.
Para mantener claras las relaciones entre los componentes, decida un esquema de asignación de nombres para los volúmenes lógicos RAID-0 y los reflejos RAID-1 que creará.
Generalmente, los reflejos RAID-1 se denominan dn, donde n es un número entero. Los volúmenes de RAID-0 que componen los reflejos de RAID-1 se denominan dnX, donde X es un número entero que representa la posición del dispositivo en el reflejo (generalmente, 0 o 1 para un reflejo de dos vías).
En los ejemplos de este procedimiento, creamos reflejos RAID-1 de dos vías desde los pares de volúmenes lógicos RAID-0. De modo que denominamos a los reflejos d1, d2, d3, d4 y así sucesivamente. A continuación, asignamos un nombre a cada par de volúmenes RAID-0 para el reflejo de RAID-1 que lo incluye: d10 y d11, d20 y d21, d30 y d31, d40 y d41, etc.
Inicie sesión en el nodo en el que creó el conjunto de discos de múltiples propietarios. Inicie sesión como usuario root.
En los ejemplos anteriores, creamos el conjunto de discos en qfs2rac-node1:
[qfs2rac-node1]root@solaris:~#
Cree el primer volumen lógico RAID-0. Use el comando metainit -s diskset-name device-name number-of-stripes components-per-stripe component-names, donde:
diskset-name es el nombre que eligió para el conjunto de discos.
device-name es el nombre que eligió para el volumen lógico RAID-0.
number-of-stripes es 1.
components-per-stripe es 1.
component-name es el nombre de dispositivo del componente del conjunto de discos que se usará en el volumen RAID-0.
En ejemplo, usamos el dispositivo de cluster (DID) /dev/did/dsk/d21s0 en un conjunto de discos de propietarios múltiples dataset1 para crear el volumen lógico RAID-0 d10:
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d10 1 1 /dev/did/dsk/d21s0 [qfs2rac-node1]root@solaris:~#
Cree los volúmenes lógicos RAID-0 restantes.
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d11 1 1 /dev/did/dsk/d13s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d20 1 1 /dev/did/dsk/d14s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d21 1 1 /dev/did/dsk/d17s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d30 1 1 /dev/did/dsk/d23s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d31 1 1 /dev/did/dsk/d16s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d40 1 1 /dev/did/dsk/d15s0 [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d41 1 1 /dev/did/dsk/d19s0 ... [qfs2rac-node1]root@solaris:~#
Cree el primer reflejo RAID-1. Use el comando metainit -s diskset-name RAID-1-mirrorname -m RAID-0-volume0, donde:
diskset-name es el nombre del conjunto de discos de múltiples propietarios.
RAID-1-mirrorname es el nombre del volumen reflejado RAID-1.
RAID-0-volume0 es el primer volumen lógico RAID-0 que agrega al reflejo.
En el ejemplo, creamos el reflejo d1 y agregamos el primer volumen RAID-0 al reflejo, d10:
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d1 -m d10 [qfs2rac-node1]root@solaris:~#
Agregue los volúmenes RAID-0 restantes al primer reflejo RAID-1. Use el comando metattach -s diskset-name RAID-1-mirrorname RAID-0-volume, donde:
diskset-name es el nombre del conjunto de discos de múltiples propietarios.
RAID-1-mirrorname es el nombre del volumen reflejado RAID-1.
RAID-0-volume es el volumen lógico RAID-0 que agrega al reflejo.
En el ejemplo, d1 es un reflejo de dos vías, de modo que agregamos un único volumen RAID-0, d11:
[qfs2rac-node1]root@solaris:~# metattach -s dataset1 d11 d1 [qfs2rac-node1]root@solaris:~#
Cree los reflejos restantes.
En el ejemplo, creamos reflejos, d2, d3, d4, etc.
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d2 -m d20 [qfs2rac-node1]root@solaris:~# metattach -s dataset1 d21 d2 [qfs2rac-node1]root@solaris:~# metainit -s dataset2 d3 -m d30 [qfs2rac-node1]root@solaris:~# metattach -s dataset2 d31 d3 [qfs2rac-node1]root@solaris:~# metainit -s dataset2 d4 -m d40 [qfs2rac-node1]root@solaris:~# metattach -s dataset2 d41 d4 ... [qfs2rac-node1]root@solaris:~#
Seleccione los reflejos que alojarán los metadatos del sistema de archivos QFS.
Para los siguientes ejemplos, elegimos los reflejos d1 y d2.
En los reflejos seleccionados, cree particiones de software para alojar los metadatos de QFS. Para cada reflejo, use el comando metainit -s diskset-name partition-name -p RAID-1-mirrorname size, donde:
diskset-name es el nombre del conjunto de discos de múltiples propietarios.
partition-name es el nombre de la nueva partición.
RAID-1-mirrorname es el nombre del reflejo.
size es el tamaño de la partición.
En el ejemplo, se crean dos particiones de 500 gigabytes: d53 en el reflejo d1 y d63 en el reflejo d2:
[qfs2rac-node1]root@solaris:~# metainit -s dataset1 d53 -p d1 500g [qfs2rac-node1]root@solaris:~# metainit -s dataset1 d63 -p d2 500g
Luego, cree un sistema de archivos compartido QFS en el cluster SC-RAC mediante los volúmenes reflejados.
Si aún no lo ha hecho, lleve a cabo el procedimiento indicado en Creación de un archivo de hosts del sistema de archivos compartido QFS en todos los nodos de cluster SC-RAC. Cuando finalice, regrese aquí.
Seleccione el nodo de cluster que actuará como nodo principal para el cluster SC-RAC y el servidor de metadatos activo para el sistema de archivos compartido QFS. Inicie sesión como usuario root.
En el ejemplo, seleccionamos el nodo qfs2rac-node1:
[qfs2rac-node1]root@solaris:~#
En el nodo principal, cree un sistema de archivos ma compartido, de alto rendimiento. Use los volúmenes de disco reflejados de Solaris Volume Manager como dispositivos de metadatos mm y dispositivos de datos mr. En un editor de texto, abra el archivo /etc/opt/SUNWsamfs/mcf, realice las ediciones necesarias y guarde el archivo.
En el ejemplo, usamos el editor de texto vi para crear el sistema de archivos qfs2rac. Las particiones de los volúmenes reflejados d1 y d2 actúan como los dos dispositivos de metadatos mm del sistema de archivos, 110 y 120. Los volúmenes reflejados d3 y d4 actúan como los dos dispositivos de datos mr del sistema de archivos, 130 y 140.
[qfs2rac-node1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf # /etc/opt/SUNWsamfs/mcf file: # # Equipment Equipment Equipment Family Device Additional # Identifier Ordinal Type Set State Parameters # ----------------------- --------- -------- ------- ------ ---------- qfs2rac 100 ma qfs2rac on shared /dev/md/dataset1/dsk/d53 110 mm qfs2rac on /dev/md/dataset1/dsk/d63 120 mm qfs2rac on /dev/md/dataset1/dsk/d3 130 mr qfs2rac on /dev/md/dataset1/dsk/d4 140 mr qfs2rac on :wq [qfs2rac-node1]root@solaris:~#
Revise el archivo mcf para detectar errores. Use el comando /opt/SUNWsamfs/sbin/sam-fsd y corrija los errores que encuentre.
El comando sam-fsd lee los archivos de configuración de Oracle HSM e inicializa los sistemas de archivos. Se detendrá si detecta un error. En el ejemplo, comprobamos el archivo mcf en el host qfs2rac-node1:
[qfs2rac-node1]root@solaris:~# sam-fsd
...
Would start sam-archiverd()
Would start sam-stagealld()
Would start sam-stagerd()
Would start sam-amld()
[qfs2rac-node1]root@solaris:~#
Cree el sistema de archivos. Use el comando /opt/SUNWsamfs/sbin/sammkfs -S family-set-name, donde family-set-name es el identificador de equipo del sistema de archivos.
El comando sammkfs lee los archivos hosts.family-set-name y mcf y crea un sistema de archivos compartido con las propiedades especificadas.
[qfs2rac-node1]root@solaris:~# sammkfs -S qfs2rac Building 'qfs2rac' will destroy the contents of devices: ... Do you wish to continue? [y/N]yes ... [qfs2rac-node1]root@solaris:~#
Abra el archivo /etc/vfstab del sistema operativo en un editor de texto e inicie una línea para el nuevos sistema de archivos. Introduzca el nombre del sistema de archivos en la primera columna, espacios, un guión en la segunda columna y más espacios.
En el ejemplo, usamos el editor de texto vi. Iniciamos una línea para el sistema de archivos qfs2rac. El guión evita que el sistema operativo intente comprobar la integridad del sistema de archivos mediante las herramientas del UFS:
[qfs2rac-node1]root@solaris:~# vi /etc/vfstab #File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs2rac -
En la tercera columna del archivo /etc/vfstab, introduzca el punto de montaje del sistema de archivos relacionado con el cluster. Especifique un subdirectorio de punto de montaje que no se encuentre debajo del directorio raíz del sistema.
El montaje de un sistema de archivos QFS compartido inmediatamente debajo de la raíz puede ocasionar problemas de failover si se usa el tipo de recurso SUNW.qfs. En el ejemplo, el punto de montaje del sistema de archivos qfs2rac es /global/sc-rac/qfs2rac:
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs2rac - /global/sc-rac/qfs2rac samfs - no
En la cuarta columna del archivo /etc/vfstab, introduzca el tipo de sistema de archivos (samfs).
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ---------------------- ------ ---- ------- ------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs2rac - /global/sc-rac/qfs2rac samfs
En la quinta columna del archivo /etc/vfstab, introduzca la opción de transferencia fsck (-).
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ---------------------- ------ ---- ------- ------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs2rac - /global/sc-rac/qfs2rac samfs -
En la sexta columna del archivo /etc/vfstab, introduzca la opción de montaje en el inicio (no).
#File
#Device Device Mount System fsck Mount Mount
#to Mount to fsck Point Type Pass at Boot Options
#-------- ------- ---------------------- ------ ---- ------- ------------
/devices - /devices devfs - no -
/proc - /proc proc - no -
...
qfs2rac - /global/sc-rac/qfs2rac samfs - no
En la séptima columna del archivo /etc/vfstab, introduzca la opción de montaje sw_raid y las opciones de montaje recomendadas para la configuración de SC-RAC. Luego, guarde el archivo y cierre el editor.
Se recomiendan las siguientes opciones de montaje. Se pueden especificar aquí, en /etc/vfstab o en el archivo /etc/opt/SUNWsamfs/samfs.cmd, si es más conveniente:
shared
stripe=1
sync_meta=1
mh_write
qwrite
forcedirectio
notrace
rdlease=300
wrlease=300
aplease=300
En el ejemplo, se ha abreviado la lista de opciones de montaje para que se ajuste al diseño de la página:
#File #Device Device Mount System fsck Mount Mount #to Mount to fsck Point Type Pass at Boot Options #-------- ------- ---------------------- ------ ---- ------- ------------ /devices - /devices devfs - no - /proc - /proc proc - no - ... qfs2rac - /global/sc-rac/qfs2rac samfs - no shared,...sw_raid :wq [qfs2rac-node1]root@solaris:~#
Cree el punto de montaje para el sistema de archivos compartido de alta disponibilidad.
[qfs2rac-node1]root@solaris:~# mkdir -p /global/sc-rac/qfs2rac [qfs2rac-node1]root@solaris:~#
Monte el sistema de archivos compartido de alta disponibilidad en el nodo principal.
[qfs2rac-node1]root@solaris:~# mount /global/sc-rac/qfs2rac [qfs2rac-node1]root@solaris:~#
Configure el segundo nodo. Utilice el procedimiento Configuración de un servidor de metadatos posible de QFS en los nodos de cluster SC-RAC restantes.
Configure el failover. Utilice el procedimiento Configurar el failover de los servidores de metadatos HA-RAC. Luego regrese aquí.
Ha realizado correctamente una configuración de SC-RAC mediante los volúmenes reflejados de Solaris Volume Manager.
Si planea usar la función de base de datos de banda lateral, vaya a Configuración de la base de datos de informes.
En caso contrario, vaya a Configuración de notificaciones y registro.