Автомонтёр
Автомонтировщик — это любая программа или программный объект, который автоматически монтирует файловые системы в ответ на операции доступа пользовательских программ. Системная утилита автомонтирования ( демон в Unix ), получив уведомление о попытках доступа к файлам и каталогам в выборочно отслеживаемых деревьях подкаталогов, динамически и прозрачно делает локальные или удаленные устройства доступными.
Целью автомонтирования является сохранение локальных системных ресурсов и уменьшение связи между системами, которые используют файловые системы совместно с несколькими серверами. Например, организация крупного и среднего размера может иметь сотни файловых серверов и тысячи рабочих станций или других узлов, имеющих доступ к файлам с любого количества этих серверов в любое время. только относительно небольшое количество удаленных файловых систем ( экспортов Обычно на любом узле в любой момент времени будет активно ). Отсрочка монтирования такой файловой системы до тех пор, пока процессу действительно не понадобится доступ к ней, снижает необходимость отслеживать такие монтирования, повышая надежность, гибкость и производительность.
Часто один или несколько файловых серверов становятся недоступными (выключаются на техническое обслуживание, находятся в удаленной и временно отключенной сети или доступны по перегруженному каналу). Администраторы также часто считают необходимым переместить данные с одного файлового сервера на другой — для решения проблем с емкостью и балансировки нагрузки. Автоматизация точек монтирования данных упрощает перенастройку клиентских систем в таких случаях.
В совокупности эти факторы создают проблемы для старых «статических» методов управления таблицами монтирования файловой системы ( fstab
файлы в системах Unix). Утилиты Automounter решают эти проблемы и позволяют системным администраторам консолидировать и централизовать ассоциации точек монтирования (имен каталогов) с экспортами. Если все сделано правильно, пользователи могут прозрачно получать доступ к файлам и каталогам, как если бы все их рабочие станции и другие узлы были подключены к одной файловой системе в масштабе предприятия.
Можно также использовать средства автомонтирования для определения нескольких репозиториев для данных, доступных только для чтения; Клиентские системы могут автоматически выбирать, какой репозиторий монтировать, в зависимости от доступности, загрузки файлового сервера или близости к сети.
Домашние каталоги
[ редактировать ]Многие учреждения имеют несколько файловых серверов, на которых размещаются домашние каталоги различных пользователей. Все рабочие станции и другие внутренние узлы таких организаций (обычно все те, кто находится за общим брандмауэром, отделяющим их от Интернета ) будут настроены с помощью служб автомонтирования, так что любой пользователь, входящий в любой узел, неявно инициирует доступ к своему собственному домашнему каталогу, что, следовательно, , монтируется в общую точку монтирования, например /home/user
. Это позволяет пользователям получать доступ к своим файлам из любой точки предприятия, что чрезвычайно полезно в средах UNIX, где пользователи могут часто вызывать команды во многих удаленных системах с помощью различных команд диспетчеризации заданий, таких как ssh
, telnet
, rsh
или rlogin
или через протоколы X11 или VNC .
/сеть
[ редактировать ]Очень распространенный локальный путь автомонтирования по умолчанию имеет вид /net/hostname/nfspath
где hostname
это имя хоста удаленного компьютера и nfspath
это путь, который экспортируется через NFS на удаленном компьютере. Эта нотация обычно освобождает системного менеджера от необходимости явно управлять каждым экспортируемым путем через центральную карту автомонтирования.
Общие ресурсы и репозитории программного обеспечения
[ редактировать ]В некоторых вычислительных средах на пользовательских рабочих станциях и вычислительных узлах не установлен полный набор программного обеспечения, к которому пользователи могут захотеть получить доступ. Системы могут быть «изображены» с минимальным или типичным срезом наиболее часто используемого программного обеспечения. Кроме того, в некоторых средах пользователям может потребоваться специализированный или периодический доступ к более старым версиям программного обеспечения (например, разработчикам может потребоваться выполнить исправление ошибок и регрессионное тестирование, или некоторым пользователям может потребоваться доступ к архивным данным с использованием устаревших инструментов).
Обычно организации предоставляют репозитории или «хранилища» такого программного обеспечения, готовые к установке по мере необходимости. Они также могут включать полные копии системных образов, из которых на машинах изначально установлены операционные системы, или доступные для восстановления любые системные файлы, которые могут быть повреждены в течение жизненного цикла машины.
Некоторому программному обеспечению может потребоваться довольно значительное пространство для хранения или оно может находиться в стадии быстрой (возможно, внутренней) разработки. В этих случаях программное обеспечение может быть установлено и настроено для запуска непосредственно с файловых серверов.
Динамически варианты автомонтирования
[ редактировать ]В простейшем случае файловый сервер хранит данные и, возможно, сценарии, к которым может получить доступ любая система в среде. Однако определенные типы файлов (в частности, исполняемые двоичные файлы и общие библиотеки) могут использоваться только определенными типами оборудования или определенными версиями определенных операционных систем.
В подобных ситуациях утилиты автомонтирования обычно поддерживают некоторые средства «отображения» или «интерполяции» переменных данных в аргументы монтирования.
Например, организация, в которой используются системы 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] и НетБСД . [7]
Некоторые операционные системы также поддерживают автоматическое монтирование внешних накопителей (например, дисковых накопителей или флэш-накопителей, использующих соединения FireWire или USB ) и съемных носителей (например, компакт-дисков и DVD-дисков ). Эта технология отличается от описанного здесь автомонтажа; он предполагает монтирование локальных носителей, когда пользователь подключает их или вставляет в систему, а не монтирует каталоги с удаленных файловых серверов, когда на них делается ссылка. В настоящее время Linux (начиная с Linux 2.6) использует программу пользовательского пространства udev для этой формы автоматического монтирования. Некоторые функции автомонтирования реализованы в отдельной программе HAL , но по состоянию на 2010 г. [update] объединяются [ кем? ] в удев. OpenBSD имеет hotplugd(8), который запускает специальные сценарии при подключении или отключении съемных устройств, так что пользователь может легко добавить подключение съемных дисков. В macOS diskarbitrationd
осуществляет эту форму автоматического монтажа. Во FreeBSD съемные носители могут обрабатываться автомонтером так же, как и общие сетевые ресурсы. [8] [9]
Недостатки и предостережения
[ редактировать ]Хотя утилиты автомонтирования (и удаленные файловые системы в целом) могут обеспечить централизованно управляемый, согласованный и в значительной степени прозрачный доступ к службам хранения организации, они также могут иметь свои недостатки:
- Доступ к автоматически монтируемым каталогам может вызвать задержки, пока автомонтировщик разрешает сопоставление и монтирует экспорт на место.
- Таймауты могут привести к размонтированию смонтированных каталогов (что впоследствии может привести к задержкам монтирования при следующей попытке доступа).
- Сопоставление точки монтирования с аргументами экспорта обычно выполняется через какую-либо службу каталогов, такую как LDAP или NIS , что представляет собой еще одну зависимость (потенциальную точку сбоя).
- Когда некоторым системам требуется частый доступ к некоторым ресурсам, в то время как другим нужен лишь периодический доступ, это может вызвать трудные или невозможные проблемы при реализации согласованной, общекорпоративной смеси локально «зеркальных» (реплицируемых) и автоматически монтируемых каталогов.
- Когда данные переносятся с одного файлового сервера (экспорт) на другой, может существовать неопределенное количество систем, которые по разным причинам все еще имеют активное монтирование в старом расположении («устаревшие монтирования NFS »); это может вызвать проблемы, которые могут даже потребовать перезагрузки совершенно стабильных хостов.
- Организации могут обнаружить, что создали «спагетти» сопоставлений, что может повлечь за собой значительные затраты на управление, а иногда и некоторую путаницу среди пользователей и администраторов.
- Пользователи могут настолько привыкнуть к прозрачности автоматически монтируемых ресурсов, что забывают учитывать некоторые различия в семантике доступа, которые могут применяться к сетевым файловым системам по сравнению с локально монтируемыми устройствами. В частности, программисты могут попытаться использовать методы «блокировки», которые безопасны и обеспечивают желаемые гарантии атомарности в локальных файловых системах, но которые задокументированы как уязвимые к условиям гонки при использовании в NFS.
Ссылки
[ редактировать ]- ^ Каллаган, Брент (2000) [1999]. НФС в иллюстрациях . Аддисон-Уэсли . стр. 322–323. ISBN 0-201-32570-5 . Проверено 23 декабря 2007 г.
- ^ Каллаган, Брент; Сингх, Сатиндер (21–25 июня 1993 г.). Autofs Automounter . Техническая конференция USENIX летом 1993 г. Цинциннати, Огайо.
- ^ Лабиага, Рикардо (7–12 ноября 1999 г.). Улучшения в Autofs Automounter . 1999 ЛИЗА XIII. Сиэтл, Вашингтон.
- ^ Ян-Саймон Пендри (1 декабря 1989 г.). «''Amd'' - автомонтировщик» . Группа новостей : comp.unix.wizards . Проверено 23 декабря 2007 г.
- ^ Эдвард Томаш Наперала (30 июля 2014 г.). «Автофс» (PDF) . Архивировано (PDF) из оригинала 7 июня 2021 года.
- ^ Томохиро Кусуми (2 июня 2016 г.). «git: autofs: Портировать autofs из FreeBSD» . [электронная почта защищена] (список рассылки). Драгонфлай БСД . Проверено 13 ноября 2019 г.
- ^ «Новый автомонтёр» . NetBSD Wiki . Архивировано из оригинала 7 июня 2021 года.
- ^ «Справочник FreeBSD, раздел 17.4.2. Автоматическое монтирование съемных носителей» . Архивировано из оригинала 7 июня 2021 года.
- ^ Дикисон, Энн (13 марта 2015 г.). «FreeBSD из окопов: использование autofs(5) для монтирования съемных носителей» . Фонд FreeBSD . Архивировано из оригинала 7 июня 2021 года . Проверено 13 ноября 2019 г.