Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
Gestión de sistemas de archivos de red en Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Español) |
1. Gestión de sistemas de archivos de red (descripción general)
2. Administración de sistema de archivos de red (tareas)
3. Acceso a los sistemas de archivos de red (referencia)
Archivos de configuración y nfsmapid
Comando nfsmapid y registros DNS TXT
Comprobación del dominio NFS versión 4
Configuración del dominio predeterminado NFS versión 4
Configuración de un dominio predeterminado NFS versión 4 en la versión Oracle Solaris 11
Configuración de un dominio predeterminado NFS versión 4 en la versión Solaris 10
Información adicional sobre nfsmapid
Opciones mount para sistemas de archivos NFS
Opciones share no específicas del sistema de archivos
Opciones share específicas de NFS
Configuración de listas de acceso con el comando share
Comandos para resolución de problemas de NFS
Anular el uso compartido y volver a compartir un sistema de archivos en NFS versión 4
Espacio de nombre de sistema de archivos en NFS versión 4
Identificadores de archivos volátiles en NFS versión 4
Recuperación de cliente en NFS versión 4
Compatibilidad de uso compartido OPEN en NFS versión 4
ACL y nfsmapid en NFS versión 4
Motivos de falla de la asignación de ID
Cómo evitar problemas de asignación de ID con las ACL
Comprobación de ID de usuario o de grupo sin asignar
Información adicional sobre las ACL o nfsmapid
Negociación de tamaño de transferencia de archivos
Cómo se montan los sistemas de archivos
Efectos de la opción -public y direcciones URL NFS al montar
Conmutación por error por parte del cliente
Terminología de conmutación por error
¿Qué es un sistema de archivos replicado?
Conmutación por error y bloqueo NFS
Conmutación por error por parte del cliente en NFS versión 4
Cómo funciona el registro del servidor NFS
Cómo funciona el servicio WebNFS
Cómo funciona la negociación de seguridad WebNFS
Limitaciones WebNFS con uso de explorador web
Cómo funcionan los montajes de reflejo
Cuándo utilizar montajes de reflejo
Montaje de un sistema de archivos mediante montajes de reflejo
Desmontaje de un sistema de archivos mediante montajes de reflejo
Cómo funcionan las referencias de NFS
¿Cuándo utilizar referencias NFS?
Creación de una referencia NFS
Eliminación de una referencia NFS
Cómo navega autofs por la red (mapas)
Cómo Autofs inicia el proceso de navegación (mapa maestro)
Variables en una entrada de mapa Autofs
Mapas que hacen referencia a otros mapas
Modificar cómo navega autofs por la red (modificación de mapas)
Comportamiento predeterminado de autofs con los servicios de nombres
Autofs es un servicio por parte del cliente que monta automáticamente el sistema de archivos adecuado. Los componentes que trabajan juntos para lograr el montaje automático son los siguientes:
El comando automount
El sistema de archivos autofs
El daemon automountd
El servicio automount, svc:/system/filesystem/autofs, que se invoca en el momento de inicio del sistema, lee el archivo de mapa maestro auto_master para crear el conjunto inicial de montajes de autofs. Estos montajes de autofs no se montan automáticamente en momento de inicio. Estos montajes son puntos en los que los sistemas de archivos se montan en el futuro. Estos puntos también se conocen como nodos desencadenadores.
Después de que los montajes autofs están configurados, estos montajes puede desencadenar sistemas de archivos para que se monten en ellos. Por ejemplo, cuando autofs recibe una solicitud para acceder a un sistema de archivos que no está montado en la actualidad, autofs invoca el comando automountd, que monta el sistema de archivos solicitado.
Después del montaje inicial de autofs, se utiliza el comando automount para actualizar los montajes autofs según sea necesario. El comando compara la lista de los montajes en el mapa auto_master con la lista de sistemas de archivos montados en el archivo de tabla de montaje /etc/mnttab (anteriormente /etc/mtab). automount realiza los cambios adecuados. Este proceso les permite a los administradores del sistema cambiar la información de montaje dentro de auto_master y que los procesos autofs utilicen esos cambios sin detener y reiniciar el daemon autofs. Una vez que el sistema de archivos está montado, no es necesario que automountd realice ninguna acción hasta que el sistema de archivos se desmonte automáticamente.
A diferencia de mount, automount no lee el archivo /etc/vfstab (que es específico para cada equipo) para obtener una lista de sistemas de archivos para montar. El comando automount se controla dentro de un dominio y en los equipos a través de espacio de nombres o archivos locales.
A continuación se muestra una descripción general simplificada de cómo funciona autofs.
El daemon automountd se inicia en el momento del inicio mediante el servicio svc:/system/filesystem/autofs. Consulte la Figura 3-3. Este servicio también ejecuta el comando automount, que lee el mapa maestro e instala los puntos de montaje de autofs. Consulte Cómo Autofs inicia el proceso de navegación (mapa maestro) para obtener más información.
Figura 3-3 El servicio svc:/system/filesystem/autofs inicia automount
Autofs es un sistema de archivos de núcleos que admite montaje y desmontaje automático.
Cuando se realiza una solicitud para acceder a un sistema de archivos en un punto de montaje autofs, se produce lo siguiente:
Autofs intercepta la solicitud.
Autofs envía un mensaje al comando automountd para el sistema de archivos solicitado que se montará.
automountd localiza la información del sistema de archivos en un mapa, crea el nodo desencadenador y realiza el montaje.
Autofs permite que continue la solicitud interceptada.
Autofs desmonta el sistema de archivos después de un período de inactividad.
Nota - Los montajes que se administran a través de los servicios autofs no deben montarse ni desmontarse manualmente. Aunque la operación se realizara correctamente, el servicio autofs no comprueba que el objeto se haya desmontado, lo que da como resultado posibles incoherencias. Si se reinicia, se eliminan todos los puntos de montaje de autofs.
Autofs busca una serie de mapas para navegar a través de la red. Los mapas son archivos que contienen información como las entradas de las contraseñas de todos los usuarios en una red o los nombres de todos los equipos de una red. De hecho, los mapas contienen equivalentes para toda la red de los archivos de administración de UNIX. Los mapas están disponibles localmente o a través de un servicio de nombres de red, como NIS. Consulte Modificar cómo navega autofs por la red (modificación de mapas).
El comando automount lee el mapa maestro en el inicio del sistema. Cada entrada del mapa maestro es un nombre de mapa directo o un nombre de mapa indirecto, su ruta de acceso y sus opciones de montaje, como se muestra en la Figura 3-4. El orden específico de las entradas no es importante. automount compara las entradas del mapa maestro con las entradas en la tabla de montaje para generar una lista actual.
Figura 3-4 Navegación por el mapa maestro
Lo que hace el servicio autofs cuando se desencadena una solicitud de montaje depende de cómo estén configurados los mapas del montador automático. El proceso de montaje normalmente es el mismo para todos los montajes. Sin embargo, el resultado final cambia según el punto de montaje que se especifica y la complejidad de los mapas. El proceso de montaje incluye la creación de nodos desencadenadores.
Para ayudar a explicar el proceso de montaje autofs, supongamos que los siguientes archivos están instalados.
$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /share auto_share $ cat /etc/auto_share # share directory map for automounter # ws gumbo:/export/share/ws
Cuando se accede al directorio /share, el servicio autofs crea un nodo desencadenador para /share/ws, que es una entrada de /etc/mnttab que se parece a la siguiente entrada:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=###
Cuando se accede al directorio /share/ws, el servicio autofs completa el proceso con estos pasos:
Comprueba la disponibilidad del servicio de montaje del servidor.
Monta el sistema de archivos solicitados en /share. Ahora el archivo /etc/mnttab contiene las siguientes entradas.
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### #####
Cuando se definen varias capas en los archivos del montador automático, el proceso de montaje se hace más complejo. Por ejemplo, si amplía el archivo /etc/auto_shared del ejemplo anterior para incluir lo siguiente:
# share directory map for automounter # ws / gumbo:/export/share/ws /usr gumbo:/export/share/ws/usr
El proceso de montaje es básicamente igual que el ejemplo anterior en el que se accede al punto de montaje /share/ws. Además, se crea un nodo desencadenador hacia el siguiente nivel (/usr) en el sistema de archivos /share/ws de forma que el siguiente nivel se puede montar si es que se accede a él. En este ejemplo, /export/share/ws/usr debe existir en el servidor NFS para que se cree el nodo desencadenador.
Precaución - No utilice la opción -soft al especificar capas jerárquicas. Consulte Desmontaje de autofs para obtener una explicación de esta limitación. |
El desmontaje que se produce después de un cierto tiempo de inactividad es ascendente (orden inverso de montaje). Si uno de los directorios en un nivel superior en la jerarquía está ocupado, sólo los sistemas de archivos debajo de ese directorio se desmontan. Durante el proceso de desmontaje, se eliminan todos los nodos desencadenadores y se desmonta el sistema de archivos. Si el sistema de archivos está ocupado, el desmontaje falla y los nodos desencadenadores se vuelven a instalar.
Precaución - No utilice la opción -soft al especificar capas jerárquicas. Si se utiliza la opción -soft, las solicitudes para volver a instalar los nodos desencadenadores se ponen en tiempo de espera. Si no se vuelven a instalar los nodos desencadenadores, no se obtiene acceso al siguiente nivel de montajes. La única forma para eliminar este problema es que el montador automático desmonte todos los componentes de la jerarquía. El montador automático puede completar el desmontaje si espera que los sistemas de archivos se desmonten automáticamente o si reinicia el sistema. |
El mapa directo de ejemplo contiene lo siguiente:
/usr/local -ro \ /bin ivy:/export/local/sun4\ /share ivy:/export/local/share\ /src ivy:/export/local/src /usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news
Los puntos de montaje /usr/man y /usr/spool/news muestran más de una ubicación, tres ubicaciones para el primer punto de montaje y dos ubicaciones para el segundo punto de montaje. Cualquiera de las ubicaciones replicadas puede proporcionar el mismo servicio para cualquier usuario. Este procedimiento sólo es necesario cuando se monta un sistema de archivos de sólo lectura, ya que debe tener algún control sobre las ubicaciones de los archivos que escribe o modifica. Debe evitar modificar archivos en un servidor en un momento y, minutos más tarde, modificar el "mismo" archivo en otro servidor. El beneficio es que se utiliza automáticamente el mejor servidor disponible sin esfuerzo por parte del usuario.
Si los sistemas de archivos están configurados como réplicas (consulte ¿Qué es un sistema de archivos replicado?), los clientes tienen la ventaja de utilizar conmutación por error. No sólo se determina automáticamente el mejor servidor, sino que si el servidor deja de estar disponible, el cliente utiliza automáticamente el siguiente mejor servidor.
Un ejemplo de un buen sistema de archivos para configurar como una réplica son las páginas del comando man. En una red grande, más de un servidor puede exportar el conjunto actual de páginas del comando man. No importa desde qué servidor se montan las páginas del comando man si el servidor ejecuta y exporta sus sistemas de archivos. En el ejemplo anterior, se expresan varias ubicaciones de montaje como una lista de ubicaciones de montaje en la entrada de mapa.
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man
En este ejemplo, puede montar las páginas del comando man de los servidores oak, rose o willow. El mejor servidor depende de una serie de factores, incluidos los siguientes:
El número de servidores que admiten un nivel de protocolo NFS particular
La proximidad del servidor
La ponderación
Durante el proceso de ordenación, se realiza un recuento del número de servidores que admiten cada versión del protocolo NFS. La versión del protocolo compatible con la mayoría de los servidores se convierte en el protocolo que se utiliza de manera predeterminada. Esta selección proporciona al cliente el número máximo de servidores de los que puede depender.
Una vez que se encuentra el mayor subconjunto de servidores con la misma versión del protocolo, esa lista de servidores se ordena por proximidad. Para determinar la proximidad, se inspeccionan las direcciones IPv4. Las direcciones IPv4 muestran qué servidores se incluyen en cada subred. Los servidores en una subred local obtienen preferencia sobre los servidores en una subred remota. La preferencia del servidor más cercano reduce la latencia y el tráfico en la red.
Nota - La proximidad no se puede determinar para réplicas que utilizan direcciones IPv6.
La Figura 3-5 ilustra la proximidad de servidor.
Figura 3-5 Proximidad de servidor
Si varios servidores que admiten el mismo protocolo se encuentran en la subred local, se determina el tiempo de conexión de cada servidor y se utiliza el servidor más rápido. El proceso de ordenación también puede estar influido por el uso de ponderación (consulte Autofs y ponderación).
Por ejemplo, si hay más servidores versión 4, la versión 4 pasa a ser el protocolo que se utiliza de manera predeterminada. Sin embargo, ahora el proceso de ordenación es más complejo. A continuación se exponen algunos ejemplos de cómo la funciona el proceso de ordenación:
Los servidores en una subred local obtienen preferencia sobre los servidores en una subred remota. Por lo tanto, si un servidor versión 3 está en la subred local y el servidor versión 4 más próximo se encuentra en una subred remota, el servidor versión 3 tiene preferencia. Del mismo modo, si la subred local tiene servidores versión 2, éstos tienen preferencia sobre las subredes remotas con servidores versión 3 y versión 4.
Si la subred local tiene un número variado de servidores versión 2, versión 3 y versión 4, es necesario seguir realizando el proceso de ordenación. El montador automático prefiere la versión más alta de la subred local. En este ejemplo, la versión 4 es la versión más alta. Sin embargo, si la subred local tiene más servidores versión 3 o versión 2 que servidores versión 4, el montador automático “disminuye” de la versión más alta en la subred local de a una versión. Por ejemplo, si la subred local dispone de tres servidores con la versión 4, tres servidores con la versión 3 y diez servidores con la versión 2, se selecciona un servidor versión 3.
De igual forma, si la subred local tiene un número variado de servidores versión 2 y versión 3, el montador automático primero busca qué versión representa la versión más alta de la subred local. A continuación, el montador automático recuenta el número de servidores que ejecuta cada versión. Si la versión más alta en la subred local también representa a la mayoría de los servidores, se selecciona la versión más alta. Si una versión más baja tiene más servidores, el montador automático disminuye de la versión más alta en la subred local de a una versión. Por ejemplo, si hay más servidores versión 2 en la subred local que servidores versión 3, se selecciona un servidor versión 2.
Nota - La ponderación también se ve influida por los parámetros almacenados en el repositorio de SMF. Específicamente, los valores de server_versmin, client_versmin, server_versmax y client_versmax pueden hacer que algunas versiones se excluyan del proceso de ordenación. Para obtener más información sobre estos parámetros, consulte Daemon mountd and Daemon nfsd.
Con la conmutación por errores, la ordenación se comprueba en el momento del montaje cuando se selecciona un servidor. Es útil contar con varias ubicaciones en un entorno donde los servidores individuales no puedan exportar sus sistemas de archivos temporalmente.
La conmutación por errores es especialmente útil en una red grande con muchas subredes. Autofs elige el servidor adecuado y es capaz de confinar el tráfico de red NFS a un segmento de la red local. Si un servidor tiene varias interfaces de red, puede mostrar el nombre de host que está asociado con cada una de las interfaces de red si la interfaz fuera otro servidor. Autofs selecciona la interfaz más próxima al cliente.
Nota - No se realizan comprobaciones de ponderación ni de proximidad con los montajes manuales. El comando mount prioriza los servidores que se muestran de izquierda a derecha.
Para obtener más información, consulte la página del comando man automount(1M).
Puede influir en la selección de los servidores con el mismo nivel de proximidad si agrega un valor de ponderación al mapa autofs. Por ejemplo:
/usr/man -ro oak,rose(1),willow(2):/usr/man
Los números entre paréntesis indican una ponderación. Los servidores sin una ponderación tienen un valor de cero y, por lo tanto, es más probable que se seleccionen. Cuanto mayor sea el valor de ponderación, menos probabilidades hay de que se seleccione ese servidor.
Nota - Todos los demás factores de selección de servidor son más importantes que la ponderación. La ponderación sólo se tiene en cuenta al seleccionar entre los servidores con la misma proximidad de red.
Puede crear una variable específica del cliente si agrega un signo de dólar ($) a su nombre. La variable le ayuda a acomodar diferentes tipos de arquitecturas que están accediendo a la misma ubicación del sistema de archivos. También puede utilizar llaves para delimitar el nombre de la variable de las letras o dígitos agregados. La Tabla 3-3 muestra las variables de mapa predefinidas.
Tabla 3-3 Variables de mapa predefinidas
|
Puede utilizar variables en cualquier parte de una línea de entrada excepto como clave. Por ejemplo, suponga que tiene un servidor de archivos que exporta binarios para SPARC y arquitecturas x86 de /usr/local/bin/sparc y /usr/local/bin/x86 respectivamente. Los clientes pueden montarse mediante una entrada de mapa como la siguiente:
/usr/local/bin -ro server:/usr/local/bin/$CPU
La misma entrada para todos los clientes se aplica a todas las arquitecturas.
Nota - La mayoría de las aplicaciones escritas para cualquiera de las arquitecturas sun4 puede ejecutarse en todas las plataformas sun4. La variable -ARCH está codificada de forma rígida en sun4.
Una entrada de mapa +nombre_mapa que se usa en un mapa de archivos hace que automount lea el mapa especificado como si estuviera incluido en el archivo actual. Si nombre_mapa no está precedido por una barra diagonal, autofs trata el nombre de mapa como una cadena de caracteres y utiliza la política de conmutación de nombre y servicio para buscar el nombre del mapa. Si el nombre de ruta es un nombre de ruta absoluto, automount comprueba un mapa local de dicho nombre. Si el nombre del mapa comienza con un guión (-), automount consulta el mapa integrado adecuado, como hosts.
El servicio svc:system/name-service/switch contiene el orden de búsqueda de los servicios de nombres. La propiedad automount en el grupo de propiedades config especifica el orden en el que se lleva a cabo la búsqueda en bases de datos de servicios de nombres al buscar entradas de automount. Si no hay una propiedad config/automount especificada, se utiliza el orden definido en la propiedad config/default. Por ejemplo:
# svcprop -p config svc:/system/name-service/switch config/value_authorization astring solaris.smf.value.name-service.switch config/printer astring user\ files config/default astring files\ nis config/automount astring files\ nis
En este ejemplo, los mapas en los archivos locales se buscan antes que los mapas NIS. Lo mismo puede decirse si la propiedad config/automount no estuviera especificada, ya que se usaría la entrada config/default. Por lo tanto, puede tener unas pocas entradas en su mapa /etc/auto_home local para los directorios principales a los que se accede con más frecuencia. A continuación, puede utilizar el conmutador a fin de volver al mapa NIS para las otras entradas.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny
Después de consultar el mapa incluido, si no se encuentra ninguna coincidencia, automount continúa la exploración del mapa actual. Por lo tanto, puede agregar más entradas después de una entrada +.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny +auto_home
El mapa que se incluye puede ser un archivo local o un mapa integrado. Recuerde, sólo los archivos locales pueden contener entradas +.
+/etc/auto_mystuff # local map +auto_home # NIS map +-hosts # built-in hosts map
Puede crear un mapa autofs que ejecute algunos comandos para generar puntos de montaje autofs. Puede beneficiarse del uso de un mapa autofs ejecutable si necesita poder crear la estructura autofs desde una base de datos o un archivo plano. El inconveniente que presenta el uso de un mapa ejecutable es que el mapa debe instalarse en cada host. Un mapa ejecutable no puede incluirse en el servicio de nombres NIS.
El mapa ejecutable debe contener una entrada en el archivo auto_master.
/execute auto_execute
A continuación se muestra un ejemplo de mapa ejecutable:
#!/bin/ksh # # executable map for autofs # case $1 in src) echo '-nosuid,hard bee:/export1' ;; esac
Para que este ejemplo funcione, el archivo debe ser instalado como /etc/auto_execute y debe disponer de un conjunto de bits ejecutable. Establezca los permisos en 744. En estas circunstancias, si ejecuta el siguiente comando, hace que se monte el sistema de archivos /export1 de bee:
% ls /execute/src
Puede modificar, suprimir o agregar entradas a mapas para satisfacer las necesidades de su entorno. Cuando las aplicaciones y otros sistemas de archivos que los usuarios necesitan cambian su ubicación, los mapas deben reflejar los cambios. Puede modificar los mapas autofs en cualquier momento. Que las modificaciones sean efectivas la próxima vez que automountd monte un sistema de archivos depende de qué mapa se modifique y de qué tipo de cambios realice.
En el momento del inicio, el servicio svc:/system/filesystem/autofs invoca a autofs, y autofs comprueba el mapa maestro auto_master. Autofs está sujeto a las reglas que se tratan más adelante.
Autofs utiliza el orden del servicio de nombres especificado en la propiedad config/automount del servicio svc:/system/name-service/switch. Si la propiedad config/automount no está definida, se usa la propiedad config/default. Si se selecciona NIS y autofs no puede encontrar un mapa que necesita autofs pero encuentra un mapa de nombres que contiene uno o más guiones bajos, los guiones bajos se cambian por puntos. Este cambio permite que los antiguos nombres NIS funcionen. A continuación, autofs vuelve a comprobar el mapa, como se muestra en la Figura 3-6.
Figura 3-6 Cómo utiliza autofs el servicio de nombres
La actividad de la pantalla para esta sesión se asemeja al ejemplo siguiente.
$ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can't match key brent in map auto_home. Reason: no such map in server's domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/&
Si selecciona "archivos" como servicio de nombres, se asume que todos los mapas serán archivos locales en el directorio /etc. Autofs interpreta un nombre de mapa que comienza con una barra diagonal (/) como local, independientemente de qué servicio de nombres utilice autofs.