WikiDer > Автомонтер

Automounter

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

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

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

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

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

Домашние каталоги

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

/сеть

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

Совместное использование программного обеспечения и репозитории

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

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

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

Динамически вариантные автомонты

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

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

Например, организация со смесью Linux и Солярис системы могут организовать размещение своих пакет программного обеспечения репозитории для каждого на общем файловом сервере, используя имена экспорта, такие как депо: / экспорт / Linux и депо: / экспорт / солярис соответственно. Таким образом, у них могут быть каталоги для каждой из поддерживаемых версий ОС. Используя функции динамического изменения в своем устройстве автомонтирования, они могут затем настроить все свои системы так, чтобы любой администратор на любом компьютере на своем предприятии мог получить доступ к доступным обновлениям программного обеспечения в разделе /программные обновления. Пользователь в системе Solaris найдет скомпилированные пакеты Solaris в /программного обеспечения, а Linux пользователь найдет RPMs, ДОЛГ, или другие пакеты для их конкретной версии ОС. Более того, пользователь Solaris на SPARC рабочая станция будет его /программные обновления сопоставлен с соответствующим экспортом для архитектуры этой системы, в то время как пользователь Solaris на x86 ПК прозрачно найдет его /программные обновления каталог, содержащий пакеты, подходящие для его системы. Некоторое программное обеспечение (написанное на языках сценариев, таких как Perl или Python) можно установить и / или запустить на любой поддерживаемой платформе без переноса, перекомпиляции или переупаковки любого вида. Системный администратор может разместить такое программное обеспечение в / программное обеспечение / общие экспорт.

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

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

Программного обеспечения

Том Лайон разработал оригинальное программное обеспечение для автомонтирования в 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 также стал известен как Беркли Автомонтер.

Linux имеет независимую реализацию автомонтирования на основе autofs; Версия 5 этого автомонтирования обычно совместима с автомонтирующим устройством Solaris.

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

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

Недостатки и предостережения

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

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

Рекомендации

  1. ^ Каллаган, Брент (2000) [1999]. NFS проиллюстрировано. Эддисон-Уэсли. С. 322–323. ISBN 0-201-32570-5. Получено 2007-12-23.
  2. ^ Каллаган, Брент; Сингх, Сатиндер (21-25 июня 1993 г.). Autofs Automounter. Летняя техническая конференция USENIX 1993 г. Цинциннати, Огайо.CS1 maint: формат даты (ссылка на сайт)
  3. ^ Лабиага, Рикардо (7–12 ноября 1999 г.). Улучшения Autofs Automounter. 1999 LISA XIII. Сиэтл, Вашингтон.CS1 maint: формат даты (ссылка на сайт)
  4. ^ Ян-Саймон Пендри (1989-12-01). "'Amd' '- автомонтажник". Группа новостей: comp.unix.wizards. Получено 2007-12-23.
  5. ^ Эдвард Томаш Наперала (30.07.2014). "Автофс" (PDF).
  6. ^ Томохиро Кусуми (02.06.2016). "git: autofs: порт autofs из FreeBSD". [email protected] (Список рассылки). DragonFly BSD. Получено 2019-11-13.
  7. ^ «Новый автомонтажник». NetBSD Wiki.
  8. ^ «Справочник FreeBSD, раздел 17.4.2. Автоматическое монтирование съемных носителей».
  9. ^ Дикисон, Энн (13 марта 2015). «FreeBSD From the Trenches: Использование autofs (5) для монтирования съемных носителей». Фонд FreeBSD. Получено 2019-11-13.