От серверов ждут бесперебойной работы с файлами круглые сутки. Вынужденный простой оборудования означает уже не просто неудобство, а значительные финансовые потери.
Еще не так давно, если сервер выходил из строя, большинство пользователей, интересуясь, как скоро его восстановят, невесело усмехались и терпеливо ожидали, когда файлы вновь появятся на сетевых устройствах хранения информации. Извинения, вроде «простите, я не могу вам ответить на этот вопрос, потому что компьютер завис», принимались клиентами как само собой разумеющееся, а позже все повторялось снова. Такое это было время. Теперь, если ваш сервер Web недоступен из-за неисправности файлового сервера, мало кто будет терпеливо ждать, пока его восстановят. Люди просто переведут свой бизнес и деньги в какое-нибудь другое место. Поэтому для повышения надежности систем производители стали прибегать к разнообразным хитростям, чтобы при отказе какого-либо отдельного компонента система в целом продолжала функционировать.
Данной проблемой занялись разработчики аппаратных средств, в результате чего появились модели, где реализованы дублирование компонентов и возможность оперативной замены, благодаря чему аппаратную неисправность стало возможным выявить и устранить без отключения сервера. Чтобы использовать новые аппаратные возможности по обеспечению отказоустойчивости, операционные системы, установленные на этом оборудовании, требуется модифицировать. Сложность заключается в том, что одни современные устройства обычно связаны через сеть с другими, в результате чего все эти аппаратные и программные меры не спасают в случае отказа файлового сервера. Для предотвращения такой ситуации необходима система, способная определить, когда файловый сервер выйдет из строя, и предпринять надлежащие действия для оперативного восстановления работы, если подобный сбой все же произошел.
ОПЕРАТИВНОЕ ВОССТАНОВЛЕНИЕ С ПОМОЩЬЮ CACHEFS
Трудности, связанные с отказом файлового сервера, можно решить различными способами. В этой статье рассматриваются некоторые из них, причем с ориентацией на Sun Solaris, с которой преимущественно работал автор. Сначала речь пойдет об организации оперативного восстановления после сбоя (failover) с помощью не очень известной возможности cachefs в специфической реализации Sun. Она позволяет клиентам файловой системы не прерывать работу даже при потере связи с файловым сервером.
ОС Solaris 2, так же как и amd под Solaris 2, имеет файловую систему, называемую cachefs. Она использует локальные диски клиентов для кэширования копий файлов, взятых с удаленного сервера. Идея состоит в том, чтобы повысить производительность за счет размещения наиболее часто запрашиваемых файлов на локальном диске для ускорения доступа, но при этом по-прежнему иметь возможность получать файлы из централизованного хранилища. Хотя amd поддерживает систему cachefs под Solaris 2, она не обладает всеми преимуществами реализации Sun, а потому не столь полезна для оперативного восстановления после сбоя. В первой части этой публикации будут рассматриваться особенности реализации системы cachefs в Sun, во второй — более традиционный подход к проблеме обеспечения бесперебойной работы в ситуации с отказавшим сервером.
Интересной особенностью cachefs является то, что, как только клиент обратится к файлу, он оказывается на локальном диске клиента. Поэтому если систему cachefs настроить для работы с файлом (быть может, устаревшим) из кэша, когда исходный сервер в текущий момент недоступен, то она могла бы по-прежнему монтировать файлы с центрального сервера, а если на сервере происходит сбой, брать их из локального кэша клиента. Выставляя соответствующие флажки, систему caсhefs можно настроить должным образом. В терминах cachefs файловая система, монтируемая на сервере, называется файловой системой сервера (Back File System, BFS), а локальная файловая система cachefs — файловой системой клиента (Front File System, FFS). Чтобы выполнить монтирование системы cachefs, прежде всего на клиентском устройстве необходимо инициализировать память FFS с помощью cfadmin следующим образом:
cfadmin -c /var/cache
Эта команда создаст и заполнит кэш файловой системы в каталоге /var/cache. Кэш системы cachefs может размещаться в произвольно выбранном каталоге, ниже для примеров будет использоваться /var/cache. Содержимым этого каталога можно манипулировать только посредством команд cachefs и cfsadmin. Любые попытки редактирования или переименования файлов в каталоге кэша, скорее всего, приведут к порче файловой системы кэша. После того как файловая система клиента создана, на cachefs можно монтировать файловую систему сервера:
mount -F cachefs -o backfstype=nfs,
cachedir=/var/cache
server1:/file/tree /file/tree
Опции этой команды указывают cachefs, что файловая система сервера размещается на сервере сетевой файловой системы (Network File System, NFS), а каталог кэша находится в /var/cache. Теперь клиент будет кэшировать файлы с server1 на локальный диск в каталог /var/cache. Сам процесс совершенно прозрачен для пользователя файловой системы; все, что видит пользователь, — это обычный каталог, и он даже не догадывается, что файлы поступают к нему не с сервера. Однако с помощью приведенной команды невозможно вручную справиться с ситуацией, когда происходит аварийное отключение сервера. В этом случае при попытке подтвердить наличие файла на сервере процесс монтирования cachefs просто зависнет.
К счастью, cachefs имеет некоторые опции, помогающие все это преодолеть. Одна из них — опция монтирования cachefs под названием «локальный доступ». Она позволяет cachefs использовать файловые атрибуты кэшированной копии файла вместо того, чтобы проверять их на сервере BFS. Эта возможность была придумана для исключения обращений к серверу при каждой проверке атрибутов файла, но она же может быть востребована и для того, чтобы сделать cachefs более независимой от сервера BFS. Теперь нет необходимости полагаться на работоспособность сервера, чтобы получить атрибуты находящихся в кэше файлов.
Две другие полезные опции, demandconst и noconst, определяют способ проверки системой cachefs соответствия данных в кэше и на сервере BFS. Как правило, cachefs периодически проверяет согласованность данных кэша и сервера BFS в автоматическом режиме. Используя флажок монтирования demandconst, cachefs можно указать, что такая проверка будет выполняться вручную командой cfsadmin -s. Опция noconst устанавливает, что кэш вообще не будет проверяться на согласованность с сервером BFS.
Обе опции монтирования полезны, если файлы BFS изменяются нечасто. При использовании demandconst необходимо помнить, что каждый раз, внося изменения в файлы, расположенные на сервере, клиенты должны проверять свои кэши на соответствие. Когда применяется noconst, система cachefs на клиенте должна очищать кэш в целях обновления файлов. Интересно, что если при проверке объекта кэша сервер BFS вышел из строя, то cachefs удалит этот объект из кэша (это касается как автоматической проверки, так и опции монтирования demandconst). Конечно, подобное нежелательно, тем более что система cachefs призвана обеспечить некоторую устойчивость при монтировании сервера. Решить эту проблему можно с помощью опции монтирования demandcost на клиенте, и либо запустить команду ping NFS еще до запроса на обновление, чтобы убедиться, что проверка состоится, либо обязать сервер выдать клиентам сигнал о дополнительном согласовании их кэшируемых файлов. К счастью, это необязательно.
Sun встроила в cachefs так называемую опцию отключения (disconnectable), которая доступна только в том случае, когда в качестве файловой системы сервера используется NFS. Документация к этой опции очень скудна — ее нет на страницах man для mount_cachefs, и мне не удалось найти описание демона cachefsd (прим. ред.: man — это встроенная в UNIX система помощи, состоящая из набора страниц (экранов) по каждой встроенной в shell команде). Совершенно случайно упоминание о таком режиме обнаружилось во время просмотра материалов компании Sun в поисках заплат для моей системы. Документ infodoc под номером 21701 дает представление о том, как установить cachefs в режиме отключения. Процедура чрезвычайно проста. Вы создаете каталог:
/etc/fs/cachefs
и добавляете опцию монтирования disconnectable в команду монтирования cachefs. Теперь команда монтирования выглядит так:
mont -F cachefs -o backfstype=nfs,
cachedir=/var/cache,diconnectable
server1:/file/tree /file/tree
Или, если вы хотите, чтобы файловая система монтировалась автоматически, при запуске машины в конец файла /etc/vfstab необходимо добавить следующую строку:
server1:/file tree /var/cache /
file/tree cachefs -yes
backfstype=nfs,cachedir=/var/cache,
disconnectable,local -access
Те, кто знаком с синтаксисом команды vfstab, отметят, что на том месте, где обычно стоит имя устройства, теперь указан каталог /var/cache. Это поле используется во время начальной загрузки файловой системы в fsck, поэтому файловая система cachefs должна выделить под кэш каталог в fsck_cachefs для дальнейшей работы. Для того чтобы правильно применить режим отключения, понадобится сделать запись в /etc/vfstab и либо запустить сценарии cachefs, находящиеся в /etc/init.d, либо просто перегрузить систему, чтобы подключить поддерживающий этот режим демон cachefsd.
РАЗБИРАЕМСЯ С РЕЖИМОМ ОТКЛЮЧЕНИЯ
Этот метод регулирует работу cachefs с помощью некоторых хитрых приемов. Во-первых, BFS монтируется в специальном режиме, который Sun называет «полупрограммным» (semi-soft). Он позволяет прерывать доступ к BFS без зависаний подобно тому, как это делается при монтировании программного обеспечения NFS. Однако если файл, к которому осуществляется доступ, присутствует в кэше, то в результате запроса будет получена кэшированная копия файла вместо ошибки, как это бывает в случае обычного монтирования программного обеспечения NFS. В режиме отключения cachefs будет блокировать запись в файловую систему как обычное жесткое монтирование NFS. Во-вторых, операционная система запускает демон cachefsd при первом же обращении к файловой системе cachefs. Он отслеживает связь с сервером BFS и управляет процессом синхронизации клиентского кэша с файлами сервера BFS.
Использование опции отключения также вносит изменения в процесс получения атрибутов файлов. Если сервер BFS выходит из строя, cachefs будет ждать тайм-аута вызова удаленных процедур (Remote Procedure Call, RPC), но вместо того, чтобы выдать сообщение об ошибке, система обнаружит аварийную ситуацию и предложит взамен атрибуты файлов из кэшированного объекта.
Вы можете ускорить выполнение процесса с помощью режима отключения, используя флажок монтирования для локального доступа, чтобы cachefs не проверяла атрибуты файла на сервере. Это удобно, если сервер выходит из строя. Другое преимущество работы cachefs в режиме отключения состоит в том, что она поддерживает запись в файловую систему, даже когда BFS недоступна, но только в том случае, если в cachefs применяется опция эксклюзивного монтирования (non-shared). Эта опция означает, что лишь один клиент будет модифицировать файлы на сервере. Таким способом Sun гибко избежала проблемы с модификацией файла множеством клиентов, поскольку они отключаются от сервера ввиду ограничений на модификацию файлов. Если флажок эксклюзивного монтирования не выставлен, то попытки сделать запись в файловую систему, когда сервер BFS выходит из строя, блокируют записи, пока сервер вновь не начнет работу.
НА ЧТО ОБРАТИТЬ ВНИМАНИЕ
Как и любая другая система, cachefs не лишена недостатков. Если в тот момент, когда сервер вышел из строя, интересующие вас файлы находятся не в локальном кэше, вы не сумеете их прочесть. И что еще печальнее, сообщить cachefs, какие файлы желательно иметь в кэше клиента, можно одним-единственным способом — выполнить чтение каждого файла, который, по вашему мнению, является важным. Кроме того, на клиентском устройстве должен быть достаточный объем памяти, чтобы там могли разместиться все файлы, которые могут понадобиться во время возможного аварийного отключения сервера. Как правило, нет необходимости сопоставлять побайтно память сервера и память клиента. Обычный клиент работает лишь с небольшим подмножеством файлов сервера, и некоторые объекты в системе cachefs могут быть удалены, чтобы освободить место для новых. Если cachefs используется как хранилище на случай аварийного отказа сервера, следует убедиться в том, что клиент располагает достаточной памятью для кэша cachefs, чтобы в нем могли поместиться все файлы, необходимые в тот момент, когда сервер выйдет из строя. К тому же ограничение числа клиентов с правом обновления файловой системы (хотя это позволяет избежать проблем с конфликтующими обновлениями) при определенных обстоятельствах может оказаться проблематичным. Обратите также внимание на ограничение размера по умолчанию для кэшируемых файлов в системе cachefs. Оно составляет 3 Мбайт, однако возможно его увеличение с помощью команды cfsadmin, например:
cfsadmin -maxfilesize=5/var/cache
После выполнения этой команды максимальный размер кэшируемых cachefs файлов будет ограничен 5 Мбайт. Этот лимит можно увеличить, если придется работать с очень крупным файлом, который нужно кэшировать, чтобы при аварийном отключении сервера он был доступен. Кроме того, команда cfsadmin предусматривает множество опций для контроля использования ресурсов cachefs. Их подробное описание в данной статье не приводится, но если вы собираетесь кэшировать большое количество файлов, то я советую заглянуть на страницу man для cfsadmin, чтобы убедиться, что все необходимые файлы могут быть кэшированы без увеличения выделяемого по умолчанию лимита ресурсов. Наконец, когда cachefs находится в режиме отключения, она ведет себя, как предписывает флажок монтирования demandcost. Т. е. изменения в BFS будут распространяться только в том случае, если вы выполните следующую команду:
cfsadmin -s all
Такой режим предназначен не для регулярной работы, но проблему можно снять, если утилите cron на системе клиента дать задание периодически запускать команду cfsadmin (прим. ред.: утилита cron — демон в системе UNIX, исполняющий команды в строго определенные дни и часы, указанные в файле crontab). Если сервер выходит из строя, команда cfsadmin завершит сеанс, не предпринимая никаких действий. Отметим характерные особенности режима отключения для данного случая: если вы используете demandcost и запускаете команду cfsadmin -s, когда сервер выходит из строя, то содержимое cachefs будет потеряно, а в режиме отключения файлы сохраняют свою целостность.
Все, о чем до сих пор шла речь, касается cachefs, предоставляющей возможность использовать некоторые локальные ресурсы машины, чтобы не потерять доступа файлов при сбое на сервере. Этот метод более всего подходит для тех случаев, когда для операций на локальном компьютере требуется небольшое количество файлов. При работе с крупными по объему файловыми деревьями на проверку содержимого cachefs уходит гораздо больше времени. К тому же в процессе такой проверки возрастает сетевой трафик, и в результате может оказаться, что cachefs — совсем не то средство, которое будет вам полезно. Более того, необходимо учесть, что cachefs стала доступна начиная с версии Solaris 2.3, а режим отключения был добавлен впоследствии, поэтому, если вы планируете установить cachefs, проверьте наличие соответствующих заплат для вашей версии Solaris.
ТРАДИЦИОННЫЙ ПОДХОД
Бесперебойная работа в случае отказа сервера может быть обеспечена и более традиционным способом: данные дублируются на нескольких серверах, и, если первоначальный сервер, с которым клиентские машины обменивались данными, не отвечает, они обращаются к другому серверу.
Процесс, когда клиент автоматически монтирует файловую систему с сервера, называется автомонтированием. Эта процедура является демоном, который запускается на клиентской машине и отслеживает заданный набор путей к каталогам. При обращении к одному из таких отслеживаемых путей демон монтирует соответствующую часть файловой системы с удаленного сервера с использованием NFS, создавая впечатление, будто данный путь был здесь всегда. Если в течение некоторого времени процессы не активизируются, то демон размонтирует путь, чтобы защитить систему от накопления вновь созданных файловых систем. В системах Sun эта процедура называется автомонтирование, в других системах имеется эквивалент — открытый исходный код amd. И автомонтирование, и amd позволяют множеству серверов обслуживать одну файловую систему. В версиях, предшествующих Solaris 2.6, привязка клиента к индивидуальному серверу допускалась только во время монтирования. Поэтому ситуация, когда сервер, с которого клиент автоматически смонтировал файловую систему, выходил из строя, была очень неприятной, поскольку клиента требовалось запустить заново, чтобы он смонтировал файловую систему с другого сервера.
Для amd и процедуры автомонтирования Sun под ОС Solaris 2.6 и более поздними версиями демон автомонтирования отслеживает соединения с сервером. Если такое соединение разорвано, этот демон пытается соединиться с другими серверами из соответствующего списка, так что клиент может продолжить работу.
АВТОМОНТИРОВАНИЕ SUN
Чтобы запустить процедуру автомонтирования Sun, требуются два файла: один называется файл прямых назначений (direct map), другой — файл косвенных назначений (indirect map). Файл прямых назначений может содержать команды конфигурации для автомонтирования, но на практике это не очень удобно, поскольку любое изменение файла прямых назначений требует, чтобы процедура автомонтирования была запущена заново до того, как изменения вступят в силу. Обычно файл прямых назначений процедуры автомонтирования содержит имена файлов. Такие файлы называются файлами косвенных назначений и, как правило, используются для хранения конфигурации автомонтирования, потому что файл косвенных назначений можно обновлять, и такие обновления вступают в силу без повторного запуска процедуры автомонтирования.
Обычно файл прямых назначений называется /ect/auto/_master и содержит такие строки:
/file /usr/automount/file_map
Они указывают местоположение файла косвенных назначений. В приведенном выше примере автоматически монтируемый каталог /file контролируется файлом косвенных назначений /usr/automount/file_map, который можно хранить везде, где есть доступ к демону автомонтирования. Я предпочитаю поместить все файлы косвенных назначений в один каталог, доступный всем клиентам. Как уже говорилось, содержимое файла косвенных назначений можно поместить в файлы прямых назначений, но после этого могут возникнуть трудности при внесении изменений в собственный файл косвенных назначений. Для обычного автомонтируемого каталога файл косвенных назначений содержит строки:
tree server1:/share/file/tree,
указывающие процедуре автомонтирования, что она должна смонтировать файловую систему /share/file/tree с машины server1 как /file/tree при обращении к каталогу /file/tree. Приведенные примеры не предоставляют средств оперативного восстановления. Если сервер отказал, клиент зависнет. Синтаксис команды автомонтирования для спецификации серверов на случай аварии представляет собой список имен файловых серверов и каталогов, разделенных пробелами:
tree server1:/share/file/tree
tree server2:/share/file/tree
В этом случае (для автомонтирования в случае Solaris 2.6 и более поздних версий), если server1 вышел из строя, процедура автомонтирования автоматически заменит его на server2 для дальнейшей обработки файлов. Как уже говорилось, в ситуациях, когда автомонтирование выполняется под OC более ранней версии, чем Solaris 2.6, компьютеры потребуется перезагрузить при смене файлового сервера.
AMD
amd уже может быть инсталлирована в вашей системе. Однако очень немногие разработчики включают amd в состав операционной системы либо поставляют ее как пакет дистрибутивов на CD. В операционной системе Red Hat Linux, например, amd присутствует в виде пакета дистрибутивов на CD самой последней версии. Обратитесь к страницам помощи man, чтобы проверить, обладает ли установленная у вас операционная система такой возможностью. Если это не так, то скачайте пакет с сайта разработчика.
Концепция amd напоминает концепцию автомонтирования Sun, но синтаксис для назначений amd другой. Она не предусматривает прямых назначений, как это принято в Sun. Установление соответствия корневых каталогов и других операций выполняется либо в командной строке в простых случаях, либо путем создания файла amd.conf. Чтобы выполнить ту же функцию, что и файл /ect/auto_master, как показано в одном из предыдущих примеров, в конец командной строки amd следует добавить следующую запись:
/file /ect/amd/file_map
Как и в случае с автомонтированием Sun, файл назначений amd должен быть помещен в общий каталог, чтобы облегчить задачу управления. Синтаксис amd для файла file_map будет таким:
tree -opts:-ro;
type:=nfs;
rfs:=/share/file/tree rhost:=server1
Все это предписывает amd монтировать совместно используемую файловую систему /share/file/tree с server1 как подкаталог каталога верхнего уровня /file. Файловая система будет смонтирована только на чтение.
Однако подобные действия не обеспечивают защиту на случай выхода сервера из строя. Если server1 аварийно прекратил работу, то клиент зависнет до тех пор, пока server1 не возобновит работу. amd может монтировать файловую систему с множества серверов и будет отслеживать их состояние, как и в случае с автомонтированием Sun. Чтобы указать избыточные файловые серверы в amd, в команду нужно добавить дополнительные параметры удаленного хоста (rhost). Таким образом, запись файла назначений amd для двух серверов, server1 и server2, обслуживающих идентичные файловые системы на клиентах, должна выглядить так:
tree -opts:=ro, soft, intr;
type:=nfs;
rfs:=/share/file/tree rhost:=
server1 rhost:=server2
Теперь, если server1 выходит из строя, а файловая система еще не смонтирована, клиент автоматически переключается на server2 для получения файлов. К сожалению, в отличие от автомонтирования Sun, в особом случае, когда сервер выходит из строя в процессе монтирования, такой процесс зависает. Последующие процессы при обращении к дереву файлов пройдут нормально, потому что amd сможет переключиться на другой работающий сервер, но первый так и останется в подвешенном состоянии. Используя флажок intr в опциях монтирования, зависшие процессы можно удалить, а опция soft позволяет без осложнений прервать файловые операции из-за ошибки сервера без зависания. По этой причине при сбое на сервере любые процессы доступа к файловой системе, рассчитанные на длительное исполнение, придется запускать заново. Это может быть сделано с помощью простого сценария для мониторинга доступности сервера и рестарта в случае критических процессов.
Я обратил внимание на еще одну особенность amd (в случае am-utils версии 6.0.1s11 на машине с операционной системой NetBSD 1.5). При использовании множества серверов для монтирования, как только amd регистрирует отказ сервера, она не будет обращаться к этому серверу, даже если он вновь станет работоспособным. Таким образом, если необходимо более равномерно распределить трафик NFS, на amd не следует рассчитывать, поскольку все клиенты автоматически переместятся на наиболее надежный сервер.
СИНХРОНИЗАЦИЯ СЕРВЕРОВ
Для оперативного восстановления работы множество серверов должно содержать полные копии экспортируемых файловых систем. Один сервер выделяется в качестве основного хранилища для файловой системы, при этом, когда вносятся какие-нибудь изменения, периодически запускается задание на обновление файлов на подчиненных серверах с использованием таких команд, как rdist, rsyn, unison. rdist входит в стандартный дистрибутив системы UNIX и предназначается для обновления деревьев файлов на подчиненных серверах в соответствии с главным деревом. Команда для выполнения обновлений выглядит следующим образом:
rdist -R c /share/file/tree/ server2
С ее помощью происходит обновление дерева каталога /file/tree на server2 в соответствии с файловой системой того сервера, на котором она выполняется. Хотя данный процесс достаточно прозрачный, все же использование команды rdist имеет некоторые особенности. Раньше она отличалась рядом пробелов в защите, а поскольку rdist была по умолчанию программой задания идентификатора пользователя (setuid), злоумышленники нередко пытались применять ее для получения доступа к корневому каталогу. По этой причине она может быть удалена либо блокирована. Еще одна проблема команды rdist связана с тем, что она требует эквивалентного доступа к удаленной машине, а это означает, что пользователь, выполняющий rdist на основной машине, имеет доступ к другим машинам без пароля. В определенных условиях это может привести к нарушению безопасности.
Другой метод синхронизации файловых деревьев состоит в использовании свободно распространяемого программного средства, называемого rsyn. Оно было написано Анрэ Триджелом (автором Samba) и разработано для эффективного копирования файлов с одного сервера на другой. rsyn действительно эффективное средство, поскольку передает лишь различия в файлах на основной и подчиненной машине, а это существенно сокращает объем трафика. rsyn позволяет не только эффективно использовать пропускную способность сети, но и вручную выбрать способ взаимодействия с удаленным компьютером. По умолчанию для этого rsyn применяет rsh, но можно воспользоваться чем-нибудь наподобие ssh или openssh. Это не только поможет проверить учетные записи с удаленного устройства, но и зашифровать трафик между двумя машинами. Чтобы выполнить те же функции, которые обеспечивала команда rdist, только с ssh в качестве механизма передачи, команда rsyn должна выглядеть следующим образом:
rsyn -va —rsh /usr/local/bin/ssh -delete /share/file/tree/ server2:/share/file/tree/
Одно предупреждение относительно rsyn — косая черта в конце путей к каталогам обязательна. Если эти знаки отсутствуют, команда rsyn может «съесть» содержимое необходимого вам каталога. Поэтому было бы разумно проверить команду rsyn на пробном каталоге, чтобы убедиться, что случайным образом не уничтожится что-то важное.
Следующая проблема, связанная с командами rdist и rsyn, состоит в том, что и та и другая предполагают наличие исходных мастер-файлов на одной машине, поэтому обновления могут быть сделаны не везде. Если файлы на подчиненной машине обновляются без мастер-файлов, то в следующий раз обновления на подчиненной машине будут стерты, когда главный сервер начнет рассылать файлы на подчиненные компьютеры. Чтобы справиться с этой ситуацией, надо либо установить правило, по которому обновлять можно лишь основную файловую систему, либо использовать программу, например unison, с помощью которой можно обновлять файлы на многих серверах и синхронизировать их между серверами автоматически.
unison в настоящее время находится на стадии разработки и, с точки зрения авторов, представляет собой бета-версию. Вопреки статусу «бета», возможности unison весьма многообещающи, особенно в тех случаях, когда по каким-либо причинам правило обновления только главного сервера не введено для исполнения. unison обнаружит различия между двумя файловыми деревьями, а как поступать далее — дело администратора. Если файл на одном из компьютеров был модифицирован, но при этом не изменен на удаленном, то два файла просто приводятся в соответствие. По умолчанию unison использует ssh в качестве средства передачи, поэтому данные в открытой форме по канные в открытой форме по каналу передачи не пересылаются. Относительная новизна unison вносит элемент риска в работу с ней по сравнению с rdist или rsyn, но если вы готовы оказать помощь в отладке кода либо мириться с проблемами на начальном этапе, unison — это как раз то, что вам нужно.
Хотя метод использования множества серверов достаточно прост, он также не идеален. Его стоит применять, если файловая система будет смонтирована на клиентских компьютерах только для чтения. К тому же любое обновление дерева файлов может быть выполнено только на главной машине, за исключением тех случаев, когда для обновления серверов используется программа наподобие unison. Наконец, существует опасность того, что главный сервер выйдет из строя как раз в тот момент, когда происходит обновление. Если у вас несколько подчиненных устройств, вы можете столкнуться с ситуацией, в которой одно из них имеет усеченную версию файла (из-за того, что сервер вышел из строя в процессе копирования), либо некоторые из подчиненных серверов содержат устаревшие версии некоторых файлов (из-за того, что главный сервер вышел из строя, когда процесс обновления не был завершен). Если подчиненные серверы обновляются часто, а копируемая файловая система невелика, то вероятность возникновения несоответствия становится еще меньше. Но всякий раз любое несоответствие может вызвать большую путаницу. Обратите внимание также на необходимость копирования всех ресурсов, требуемых для поддержки дублированной файловой системы. Сюда входят все машины и дисковая память, а это сказывается на стоимости оперативного восстановления. Кроме того, следует учесть всплески сетевого трафика в процессе согласования файлов, когда серверы копируют данные между собой, что может существенно повлиять на сеть клиента. Для решения этой проблемы достаточно организовать отдельную сеть между серверами, чтобы трафик при копировании не проходил по сети, где находятся клиенты.
Бретт Лимн работает в крупной компании и отвечает за работу группы машин на базе UNIX.
Ресурсы Internet
Информацию об rsyn вы можете найти по адресу: http://www.samba.org/.
Информация о ssh предлагается по адресу: http://www.cs.hut.fi/ssh.
Свободно доступна следующая информация, касающаяся ssh: http://www.openssh.com/.
Информация о unison размещена по адресу: http://www.uti.net/unison/unison.html.