Un montador automático es cualquier programa o instalación de software que monta automáticamente sistemas de archivos en respuesta a las operaciones de acceso de los programas de usuario. Una utilidad del sistema de montador automático ( demonio en Unix ), cuando se le notifica de intentos de acceso a archivos y directorios bajo árboles de subdirectorios monitoreados selectivamente, hace que los dispositivos locales o remotos sean accesibles de manera dinámica y transparente.
El montador automático tiene el propósito de conservar los recursos del sistema local y de reducir el acoplamiento entre sistemas que comparten sistemas de archivos con varios servidores. Por ejemplo, una organización grande o mediana puede tener cientos de servidores de archivos y miles de estaciones de trabajo u otros nodos que acceden a archivos desde cualquier número de esos servidores en cualquier momento. Por lo general, solo un número relativamente pequeño de sistemas de archivos remotos ( exportaciones ) estarán activos en cualquier nodo en un momento dado. Aplazar el montaje de dicho sistema de archivos hasta que un proceso realmente necesite acceder a él reduce la necesidad de realizar un seguimiento de dichos montajes, lo que aumenta la fiabilidad, la flexibilidad y el rendimiento.
Con frecuencia, uno o más servidores de archivos se volverán inaccesibles (inactivos por mantenimiento, en una red remota y desconectada temporalmente, o se accede a ellos a través de un enlace congestionado). Los administradores también suelen tener que trasladar los datos de un servidor de archivos a otro para resolver problemas de capacidad y equilibrar la carga. Tener los puntos de montaje de datos automatizados facilita la reconfiguración de los sistemas cliente en tales casos.
Estos factores se combinan para plantear desafíos a los métodos de administración "estáticos" más antiguos de las tablas de montaje del sistema de archivos (los fstab
archivos en los sistemas Unix). Las utilidades de automounter abordan estos desafíos y permiten a los administradores de sistemas consolidar y centralizar las asociaciones de puntos de montaje (nombres de directorio) a las exportaciones. Cuando se hace correctamente, los usuarios pueden acceder de forma transparente a los archivos y directorios como si todas sus estaciones de trabajo y otros nodos estuvieran conectados a un único sistema de archivos en toda la empresa.
También se pueden utilizar montadores automáticos para definir varios repositorios para datos de solo lectura; Los sistemas cliente pueden elegir automáticamente qué repositorio montar en función de la disponibilidad, la carga del servidor de archivos o la proximidad en la red.
Directorios de inicio
Muchos establecimientos tendrán varios servidores de archivos que albergan los directorios de inicio de varios usuarios. Todas las estaciones de trabajo y otros nodos internos de dichas organizaciones (por lo general, todos los que están detrás de un firewall común que los separa de Internet ) se configurarán con servicios de montaje automático para que cualquier usuario que inicie sesión en cualquier nodo active implícitamente el acceso a su propio directorio de inicio que, en consecuencia, , se monta en un punto de montaje común, como . Esto permite a los usuarios acceder a sus propios archivos desde cualquier parte de la empresa, que es extremadamente útil en entornos UNIX, donde los usuarios pueden frecuencia invocar comandos en muchos sistemas remotos a través de varios comandos de trabajo de despacho, tales como , , o , oa través de la X11 o VNC protocolos./home/user
ssh
telnet
rsh
rlogin
/neto
Una ruta local predeterminada muy común del montador automático tiene el formato donde es el nombre de host de la máquina remota y es la ruta que se exporta a través de NFS en la máquina remota. Esta notación generalmente libera al administrador del sistema de tener que administrar cada ruta exportada explícitamente a través de un mapa central de montadores automáticos./net/hostname/nfspath
hostname
nfspath
En algunos entornos informáticos, las estaciones de trabajo de los usuarios y los nodos informáticos no albergan instalaciones de la gama completa de software al que los usuarios pueden querer acceder. Los sistemas pueden tener una "imagen" con una sección transversal mínima o típica del software más comúnmente utilizado. Además, en algunos entornos, los usuarios pueden requerir acceso especializado u ocasional a versiones anteriores de software (por ejemplo, los desarrolladores pueden necesitar realizar correcciones de errores y pruebas de regresión, o algunos usuarios pueden necesitar acceso a datos archivados usando herramientas desactualizadas).
Por lo general, las organizaciones proporcionarán repositorios o "depósitos" de dicho software, listos para su instalación según sea necesario. Estos también pueden incluir copias completas de las imágenes del sistema desde las que las máquinas tienen sus sistemas operativos inicialmente instalados o disponibles para la reparación de cualquier archivo del sistema que pueda corromperse durante el ciclo de vida de una máquina.
Algunos programas pueden requerir un espacio de almacenamiento bastante considerable o pueden estar experimentando un desarrollo rápido (quizás interno). En esos casos, el software puede instalarse y configurarse para ejecutarse directamente desde los servidores de archivos.
Montajes automáticos dinámicamente variantes
En el caso más simple, un servidor de archivos aloja datos y quizás scripts a los que puede acceder cualquier sistema en un entorno. Sin embargo, ciertos tipos de archivos (binarios ejecutables y bibliotecas compartidas, en particular) solo pueden ser utilizados por tipos específicos de hardware o versiones específicas de sistemas operativos específicos.
Para situaciones como esta, las utilidades de montador automático generalmente admiten algunos medios de "mapeo" o "interpolación" de datos variables en los argumentos de montaje.
Por ejemplo, una organización con una combinación de sistemas Linux y Solaris podría organizar el hospedaje de sus repositorios de paquetes de software para cada uno en un servidor de archivos común usando nombres de exportación como depot:/export/linux
y depot:/export/solaris
respectivamente. A continuación, pueden tener directorios para cada una de las versiones del sistema operativo que admiten. Utilizando las funciones de variación dinámica en su montador automático, pueden configurar todos sus sistemas para que cualquier administrador de cualquier máquina de su empresa pueda acceder a las actualizaciones de software disponibles en /software/updates
. Un usuario de un sistema Solaris encontraría los paquetes compilados de Solaris debajo /software
, mientras que un usuario de Linux encontraría RPM , DEB u otros paquetes para su versión de sistema operativo particular debajo. Además, un usuario de Solaris en una estación de trabajo SPARC tendría su /software/updates
mapa asignado a una exportación apropiada para la arquitectura de ese sistema, mientras que un usuario de Solaris en una PC x86 encontraría de forma transparente su /software/updates
directorio que contiene paquetes adecuados para su sistema. Cierto software (escrito en lenguajes de secuencias de comandos como Perl o Python ) se puede instalar y / o ejecutar en cualquier plataforma compatible sin portar, recompilar o volver a empaquetar de ningún tipo. Un administrador de sistemas podría posiblemente ubicar dicho software en una /software/common
exportación.
En algunos casos, las organizaciones también pueden usar asignaciones variables / dinámicas regionales o basadas en la ubicación, de modo que los usuarios de un edificio o sitio sean dirigidos a un servidor de archivos más cercano que alberga réplicas de los recursos que están alojados en otras ubicaciones.
En todos estos casos, las utilidades del montador automático permiten a los usuarios acceder a archivos y directorios sin tener en cuenta la ubicación física real. Utilizando un montador automático, los usuarios y administradores de sistemas generalmente pueden acceder a los archivos donde "se supone que deben estar" y encontrar que parecen estar allí.
Software
Tom Lyon desarrolló el software de montaje automático original en Sun Microsystems : SunOS 4.0 puso a disposición el montaje automático en 1988. [1] Sun Microsystems finalmente concedió la licencia de esta implementación a otras distribuciones comerciales de UNIX. Solaris 2.0, lanzado por primera vez en 1992, implementó su montador automático con un pseudofilesystem llamado autofs
, que se comunica con un demonio en modo de usuario que realiza montajes. [2] [3] Otros sistemas similares a Unix han adoptado esa implementación del montador automático, incluidos AIX , HP-UX y Mac OS X 10.5 y posteriores.
En diciembre de 1989, Jan-Simon Pendry lanzó Amd , un montador automático "basado en el espíritu" del programa de montaje automático SunOS. [4] Amd también se conoce como Berkeley Automounter .
Linux tiene una implementación independiente de un montador automático basado en autofs; la versión 5 de ese montador automático generalmente funciona de manera compatible con el montador automático Solaris.
FreeBSD solía proporcionar Amd ; a partir de 10.1 tiene un nuevo montador automático muy similar al de Solaris. [5] Posteriormente se ha adaptado a DragonFly BSD [6] y NetBSD . [7]
Algunos sistemas operativos también admiten el montaje automático de unidades externas (como unidades de disco o unidades flash que utilizan conexiones FireWire o USB ) y medios extraíbles (como CD y DVD ). Esta tecnología se diferencia del montaje automático descrito aquí; implica montar medios locales cuando el usuario los adjunta o inserta en el sistema, en lugar de montar directorios desde servidores de archivos remotos cuando se hace una referencia a ellos. Linux actualmente (a partir de Linux 2.6) usa el programa de espacio de usuario udev para esta forma de montaje automático. Algunas funciones de montaje automático se han implementado en el programa independiente HAL , pero a partir de 2010[actualizar]están siendo fusionados [¿ por quién? ] en udev. OpenBSD tiene hotplugd (8) que activa scripts especiales al conectar o desconectar dispositivos extraíbles, para que el usuario pueda agregar fácilmente el montaje de unidades extraíbles. En macOS, diskarbitrationd
lleva a cabo esta forma de montaje automático. En FreeBSD , los medios extraíbles pueden ser manejados por el montador automático, al igual que los recursos compartidos de red. [8] [9]
Desventajas y advertencias
Si bien las utilidades del montador automático (y los sistemas de archivos remotos en general) pueden proporcionar acceso administrado centralmente, consistente y en gran parte transparente a los servicios de almacenamiento de una organización, también pueden tener sus desventajas:
- El acceso a los directorios montados automáticamente puede provocar retrasos mientras el montador automático resuelve el mapeo y monta la exportación en su lugar.
- Los tiempos de espera pueden provocar el desmontaje de los directorios montados (situación que posteriormente puede provocar retrasos en el montaje en el próximo intento de acceso).
- El mapeo del punto de montaje para exportar argumentos generalmente se realiza a través de algún servicio de directorio como LDAP o NIS , que constituye otra dependencia (punto potencial de falla).
- Cuando algunos sistemas requieren acceso frecuente a algunos recursos, mientras que otros solo necesitan acceso ocasional, esto puede causar problemas difíciles o imposibles al implementar una combinación consistente en toda la empresa de directorios localmente "reflejados" (replicados) y montados automáticamente.
- Cuando los datos se migran de un servidor de archivos (exportación) a otro, puede haber un número indeterminado de sistemas que, por diversas razones, todavía tienen un montaje activo en la ubicación anterior (" montajes NFS obsoletos "); estos pueden causar problemas que incluso pueden requerir el reinicio de hosts perfectamente estables.
- Las organizaciones pueden encontrar que han creado un "espagueti" de asignaciones que pueden implicar una sobrecarga de administración considerable y, a veces, bastante confusión entre los usuarios y administradores.
- Los usuarios pueden acostumbrarse tanto a la transparencia de los recursos montados automáticamente que olvidan considerar algunas de las diferencias en la semántica de acceso que pueden aplicarse a los sistemas de archivos en red, en comparación con los dispositivos montados localmente. En particular, los programadores pueden intentar utilizar técnicas de "bloqueo" que son seguras y proporcionan las garantías de atomicidad deseadas en los sistemas de archivos locales, pero que están documentadas como inherentemente vulnerables a las condiciones de carrera cuando se utilizan en NFS.
Referencias
- ^ Callaghan, Brent (2000) [1999]. NFS ilustrado . Addison-Wesley . págs. 322–323. ISBN 0-201-32570-5. Consultado el 23 de diciembre de 2007 .
- ^ Callaghan, Brent; Singh, Satinder (21 al 25 de junio de 1993). El Autofs Automounter . Conferencia técnica de verano de 1993 de USENIX. Cincinnati, Ohio.
- ^ Labiaga, Ricardo (7 a 12 de noviembre de 1999). Mejoras en el Autofs Automounter . 1999 LISA XIII. Seattle, Washington.
- ^ Jan-Simon Pendry (1 de diciembre de 1989). "'' Amd '' - Un automovilista" . Grupo de noticias : comp.unix.wizards . Consultado el 23 de diciembre de 2007 .
- ^ Edward Tomasz Napierała (30 de julio de 2014). "Autofs" (PDF) . Archivado (PDF) desde el original el 7 de junio de 2021.
- ^ Tomohiro Kusumi (2 de junio de 2016). "git: autofs: Port autofs desde FreeBSD" . [email protected] (lista de correo). DragonFly BSD . Consultado el 13 de noviembre de 2019 .
- ^ "Nuevo automontador" . Wiki de NetBSD . Archivado desde el original el 7 de junio de 2021.
- ^ "Manual de FreeBSD, sección 17.4.2. Montaje automático de medios extraíbles" . Archivado desde el original el 7 de junio de 2021.
- ^ Dickison, Anne (13 de marzo de 2015). "FreeBSD desde las trincheras: uso de autofs (5) para montar medios extraíbles" . Fundación FreeBSD . Archivado desde el original el 7 de junio de 2021 . Consultado el 13 de noviembre de 2019 .