Автомонтер - Automounter
Автомоунтер любой программы или программное средство , которое автоматически монтирует файловые системы в ответ на операцию доступа с помощью пользовательских программ. Системная утилита автомонтирования ( демон в 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 пользователь найдет RPMs , Деб или другие пакеты для их конкретной версии ОС по этому законодательству. Более того, пользователю Solaris на рабочей станции SPARC будет /software/updatesназначен соответствующий экспорт для архитектуры этой системы, в то время как пользователь Solaris на ПК x86 прозрачно найдет свой /software/updatesкаталог, содержащий пакеты, подходящие для его системы. Некоторое программное обеспечение (написанное на языках сценариев, таких как Perl или Python ) можно установить и / или запустить на любой поддерживаемой платформе без переноса, перекомпиляции или переупаковки любого вида. Системный администратор может найти такое программное обеспечение в /software/commonэкспорте.
В некоторых случаях организации могут также использовать региональные или основанные на местоположении сопоставления переменных / динамических параметров, чтобы пользователи в одном здании или на площадке были направлены на более близкий файловый сервер, на котором размещены репликации ресурсов, размещенных в других местах.
Во всех этих случаях утилиты автомонтирования позволяют пользователям получать доступ к файлам и каталогам независимо от их фактического физического расположения. Используя автомонтирование, пользователи и системные администраторы обычно могут получить доступ к файлам там, где они «должны быть», и обнаружить, что они там находятся.
Программное обеспечение
Том Лайон разработал оригинальное программное обеспечение для автоматического монтирования в Sun Microsystems : SunOS 4.0 сделала автоматическое монтирование доступным в 1988 году. В конечном итоге Sun Microsystems предоставила лицензию на эту реализацию другим коммерческим дистрибутивам UNIX. Solaris 2.0, впервые выпущенный в 1992 году, реализовал автоматическое монтирование с помощью псевдофайловой системы autofs, которая взаимодействует с демоном пользовательского режима, выполняющим монтирование. Эта реализация автомонтирования была принята в других Unix-подобных системах, включая AIX , HP-UX и Mac OS X 10.5 и новее.
В декабре 1989 года Ян-Саймон Пендри выпустил Amd , средство автомонтирования, «основанное на духе» программы автомонтирования SunOS. Amd также стал известен как Berkeley Automounter .
В Linux есть независимая реализация автомонтирования на основе autofs; Версия 5 этого автомонтирования обычно совместима с автомонтирующим устройством Solaris.
FreeBSD использовалась для предоставления Amd ; начиная с версии 10.1 в нем есть новый автомонтаж, очень похожий на Solaris. Впоследствии он был перенесен на DragonFly BSD и NetBSD .
Некоторые операционные системы также поддерживают автоматическое подключение внешних накопителей (например, дисководов или флэш-накопителей, использующих FireWire или USB- соединения) и съемных носителей (например, компакт-дисков и DVD-дисков ). Эта технология отличается от описанного здесь автоматического монтажа; он включает в себя монтирование локальных носителей, когда пользователь присоединяет их к системе или вставляет их в систему, а не монтирование каталогов с удаленных файловых серверов, когда на них делается ссылка. В настоящее время Linux (начиная с Linux 2.6) для этой формы автоматического монтирования использует программу пользовательского пространства udev . Некоторые функции автоматического монтирования были реализованы в отдельной программе HAL , но с 2010 года они объединены в udev. OpenBSD имеет hotplugd (8), который запускает специальные сценарии при подключении или отключении съемных устройств, так что пользователь может легко добавить установку съемных дисков. В macOS diskarbitrationdвыполняется эта форма автоматического монтирования. В FreeBSD съемный носитель может обрабатываться автоматом монтирования, как и общие сетевые ресурсы.
Недостатки и предостережения
Хотя утилиты автомонтирования (и удаленные файловые системы в целом) могут предоставлять централизованно управляемый, согласованный и в значительной степени прозрачный доступ к службам хранения организации, у них также могут быть свои недостатки:
- Доступ к автоматически смонтированным каталогам может вызвать задержки, пока средство автоматического монтирования разрешает сопоставление и монтирует экспорт на место.
- Тайм-ауты могут вызвать размонтирование смонтированных каталогов (что впоследствии может привести к задержкам монтирования при следующей попытке доступа).
- Сопоставление точки монтирования с аргументами экспорта обычно выполняется через некоторую службу каталогов, такую как LDAP или NIS , которая составляет другую зависимость (потенциальную точку отказа).
- Когда некоторым системам требуется частый доступ к некоторым ресурсам, тогда как другим нужен только случайный доступ, это может вызвать трудные или невозможные проблемы при реализации согласованного, общекорпоративного сочетания локально «зеркальных» (реплицированных) и автоматически смонтированных каталогов.
- Когда данные переносятся с одного файлового сервера (экспорт) на другой, может существовать неопределенное количество систем, которые по разным причинам все еще имеют активное монтирование в старом местоположении («устаревшие монтирования NFS »); они могут вызвать проблемы, которые могут даже потребовать перезагрузки совершенно стабильных хостов.
- Организации могут обнаружить, что они создали «спагетти» сопоставлений, что может повлечь за собой значительные затраты на управление, а иногда и небольшую путаницу среди пользователей и администраторов.
- Пользователи могут настолько привыкнуть к прозрачности автоматически смонтированных ресурсов, что они не будут учитывать некоторые различия в семантике доступа, которые могут применяться к сетевым файловым системам, по сравнению с локально смонтированными устройствами. В частности, программисты могут попытаться использовать методы «блокировки», которые являются безопасными и обеспечивают желаемые гарантии атомарности в локальных файловых системах, но которые задокументированы как уязвимые по своей природе для условий гонки при использовании в NFS.