Автомонтировщик

Автомонтировщик — это любая программа или программное средство, которое автоматически монтирует файловые системы в ответ на операции доступа пользовательских программ. Системная утилита автомонтировщика ( демон в Unix ) , будучи уведомленной о попытках доступа к файлам и каталогам в выборочно контролируемых деревьях подкаталогов, динамически и прозрачно делает локальные или удаленные устройства доступными.

Целью автомонтирования является сохранение локальных системных ресурсов и уменьшение связи между системами, которые совместно используют файловые системы с несколькими серверами. Например, в крупной или средней организации могут быть сотни файловых серверов и тысячи рабочих станций или других узлов, получающих доступ к файлам с любого количества этих серверов в любое время. Обычно только относительно небольшое количество удаленных файловых систем ( экспортов ) будет активным на любом данном узле в любой момент времени. Отсрочка монтирования такой файловой системы до тех пор, пока процессу действительно не понадобится доступ к ней, снижает необходимость отслеживать такие монтирования, повышая надежность, гибкость и производительность.

Часто один или несколько файловых серверов становятся недоступными (выходят из строя для обслуживания, находятся в удаленной и временно отключенной сети или к ним осуществляется доступ по перегруженному каналу). Администраторы также часто сталкиваются с необходимостью переноса данных с одного файлового сервера на другой — для решения проблем с емкостью и балансировки нагрузки. Автоматизация точек монтирования данных упрощает перенастройку клиентских систем в таких случаях.

Эти факторы в совокупности создают проблемы для старых "статических" методов управления таблицами монтирования файловой системы ( fstabфайлами в системах Unix). Утилиты Automounter решают эти проблемы и позволяют системным администраторам консолидировать и централизовать ассоциации точек монтирования (имен каталогов) с экспортами. При правильном выполнении пользователи могут прозрачно получать доступ к файлам и каталогам, как если бы все их рабочие станции и другие узлы были подключены к единой файловой системе всего предприятия.

Можно также использовать автомонтирование для определения нескольких репозиториев для данных, доступных только для чтения; клиентские системы могут автоматически выбирать, какой репозиторий монтировать, в зависимости от доступности, нагрузки на файловый сервер или близости в сети.

Во многих учреждениях будет несколько файловых серверов, на которых будут размещены домашние каталоги различных пользователей. Все рабочие станции и другие узлы внутри таких организаций (обычно все те, что находятся за общим брандмауэром, отделяющим их от Интернета ) будут настроены с помощью служб автомонтирования, так что любой пользователь, входящий в любой узел, неявно инициирует доступ к своему собственному домашнему каталогу, который, следовательно, монтируется в общей точке монтирования, например . Это позволяет пользователям получать доступ к своим собственным файлам из любой точки предприятия, что чрезвычайно полезно в средах UNIX, где пользователи могут часто вызывать команды на многих удаленных системах с помощью различных команд диспетчеризации заданий, таких как , , или , или через протоколы X11 или VNC ./home/usersshtelnetrshrlogin

Очень распространенный локальный путь автомонтирования по умолчанию имеет вид, где — имя хоста удаленной машины, а — путь, который экспортируется через NFS на удаленной машине. Эта нотация обычно освобождает системного менеджера от необходимости явно управлять каждым экспортированным путем через центральную карту автомонтирования./net/hostname/nfspathhostnamenfspath

В некоторых вычислительных средах рабочие станции пользователей и вычислительные узлы не размещают установки всего спектра программного обеспечения, к которому пользователи могут захотеть получить доступ. Системы могут быть «образованы» с минимальным или типичным поперечным сечением наиболее часто используемого программного обеспечения. Кроме того, в некоторых средах пользователям может потребоваться специализированный или случайный доступ к более старым версиям программного обеспечения (например, разработчикам может потребоваться выполнить исправление ошибок и регрессионное тестирование, или некоторым пользователям может потребоваться доступ к архивным данным с использованием устаревших инструментов).

Обычно организации предоставляют репозитории или «хранилища» такого программного обеспечения, готовые к установке по мере необходимости. Они также могут включать полные копии образов системы, с которых изначально устанавливались операционные системы на машины, или доступные для восстановления любых системных файлов, которые могут быть повреждены в течение жизненного цикла машины.

Некоторое программное обеспечение может требовать довольно значительного дискового пространства или может находиться в процессе быстрой (возможно, внутренней) разработки. В этих случаях программное обеспечение может быть установлено и настроено для запуска непосредственно с файловых серверов.

В простейшем случае файловый сервер хранит данные и, возможно, скрипты, к которым может получить доступ любая система в среде. Однако некоторые типы файлов (исполняемые двоичные файлы и разделяемые библиотеки, в частности) могут использоваться только определенными типами оборудования или определенными версиями определенных операционных систем.

Для подобных ситуаций утилиты автомонтирования обычно поддерживают некоторые средства «отображения» или «интерполяции» переменных данных в аргументы монтирования.

Например, организация со смесью систем Linux и Solaris может организовать размещение своих репозиториев пакетов программного обеспечения для каждого из них на общем файловом сервере, используя имена экспорта, такие как depot:/export/linuxи depot:/export/solarisсоответственно. В соответствии с этим они могут иметь каталоги для каждой из поддерживаемых ими версий ОС. Используя функции динамического изменения в своем автомонтировании, они могут затем настроить все свои системы так, чтобы любой администратор на любой машине в их предприятии мог получить доступ к доступным обновлениям программного обеспечения в /software/updates. Пользователь в системе Solaris найдет скомпилированные пакеты Solaris в /software, в то время как пользователь Linux найдет RPM , DEB или другие пакеты для своей конкретной версии ОС в них. Более того, пользователь Solaris на рабочей станции SPARC будет сопоставлен /software/updatesс соответствующим экспортом для архитектуры этой системы, в то время как пользователь Solaris на ПК x86 прозрачно найдет свой /software/updatesкаталог, содержащий пакеты, подходящие для его системы. Некоторое программное обеспечение (написанное на языках сценариев, таких как Perl или Python ) может быть установлено и/или запущено на любой поддерживаемой платформе без портирования, перекомпиляции или переупаковки любого рода. Системный администратор вполне мог бы обнаружить такое программное обеспечение в /software/commonэкспорте.

В некоторых случаях организации могут также использовать региональные или основанные на местоположении переменные/динамические сопоставления, чтобы пользователи в одном здании или на одном объекте направлялись на более близкий файловый сервер, на котором размещаются копии ресурсов, размещенных в других местах.

Во всех этих случаях утилиты автомонтирования позволяют пользователям получать доступ к файлам и каталогам независимо от их фактического физического расположения. Используя автомонтирование, пользователи и системные администраторы обычно могут получить доступ к файлам там, где они «должны быть», и обнаружить, что они там и есть.

Том Лион разработал оригинальное программное обеспечение для автоматического монтирования в Sun Microsystems : SunOS 4.0 сделала автоматическое монтирование доступным в 1988 году. ^[1] В конечном итоге Sun Microsystems лицензировала эту реализацию для других коммерческих дистрибутивов UNIX. Solaris 2.0, впервые выпущенный в 1992 году, реализовал свой автомонтировщик с псевдофайловой системой под названием autofs, которая взаимодействует с демоном пользовательского режима, выполняющим монтирование. ^{[2] [3]} Другие Unix-подобные системы переняли эту реализацию автомонтировщика, включая AIX , HP-UX и Mac OS X 10.5 и более поздние версии.

В декабре 1989 года Ян-Симон Пендри выпустил Amd , автомонтировщик, «основанный на духе» программы автомонтирования SunOS. ^[4] Amd также стал известен как Berkeley Automounter .

В Linux имеется независимая реализация автомонтирования на основе autofs; версия 5 этого автомонтирования в целом совместима с автомонтированием Solaris.

FreeBSD использовалась для предоставления Amd ; начиная с версии 10.1 в ней появился новый автомонтировщик, очень похожий на тот, что есть в Solaris. ^[5] Впоследствии он был портирован на DragonFly BSD ^[6] и NetBSD . ^[7]

Некоторые операционные системы также поддерживают автоматическое монтирование внешних дисков (например, дисководов или флэш-накопителей, использующих FireWire или USB -подключения) и сменных носителей (например, CD и DVD ). Эта технология отличается от описанного здесь автоматического монтирования; она подразумевает монтирование локальных носителей, когда пользователь подключает их или вставляет в систему, а не монтирование каталогов с удаленных файловых серверов, когда на них делается ссылка. В настоящее время Linux (начиная с Linux 2.6) использует пользовательскую программу udev для этой формы автоматического монтирования. Некоторые функции автоматического монтирования были реализованы в отдельной программе HAL , но с 2010 года ^{[обновлять]}они были объединены ^{[ кем? ]} в udev. В OpenBSD есть hotplugd(8), который запускает специальные скрипты при подключении или отключении сменных устройств, так что пользователь может легко добавлять монтирование сменных дисков. В macOS diskarbitrationdвыполняет эту форму автоматического монтирования. В FreeBSD сменные носители могут обрабатываться автомонтировщиком, как и сетевые папки. ^{[8] [9]}

Хотя утилиты автомонтирования (и удаленные файловые системы в целом) могут обеспечить централизованно управляемый, последовательный и в значительной степени прозрачный доступ к службам хранения данных организации, они также могут иметь свои недостатки:

• Доступ к автоматически смонтированным каталогам может вызвать задержки, пока автомонтировщик разрешит сопоставление и смонтирует экспорт на место.
• Истечение времени ожидания может привести к размонтированию смонтированных каталогов (что впоследствии может привести к задержкам монтирования при следующей попытке доступа).
• Сопоставление точки монтирования с аргументами экспорта обычно выполняется через некоторую службу каталогов, например LDAP или NIS , что представляет собой еще одну зависимость (потенциальную точку отказа).
• Когда некоторые системы требуют частого доступа к некоторым ресурсам, а другим — только эпизодического, это может вызвать сложные или невыполнимые проблемы при реализации согласованной общекорпоративной смеси локально «зеркальных» (реплицированных) и автоматически монтируемых каталогов.
• При переносе данных с одного файлового сервера (экспорте) на другой может оказаться неопределенное количество систем, которые по разным причинам все еще имеют активное монтирование в старом расположении («устаревшие монтирования NFS »); это может вызвать проблемы, которые могут даже потребовать перезагрузки в остальном совершенно стабильных хостов.
• Организации могут обнаружить, что они создали «спагетти» сопоставлений, что может повлечь за собой значительные накладные расходы на управление, а иногда и значительную путаницу среди пользователей и администраторов.
• Пользователи могут настолько привыкнуть к прозрачности автоматически монтируемых ресурсов, что они пренебрегают некоторыми различиями в семантике доступа, которые могут применяться к сетевым файловым системам по сравнению с локально монтируемыми устройствами. В частности, программисты могут попытаться использовать методы «блокировки», которые безопасны и обеспечивают желаемые гарантии атомарности на локальных файловых системах, но которые документированы как изначально уязвимые к условиям гонки при использовании на NFS.