Согласитесь, статей описывающих настройку svnsync миллион с хвостиком. Плодить энтропию не цель этой статьи. Руководства по первоначальной настройке приведены в конце заметки.

    Сконцентрируем внимание на подходах связанных с необходимостью регулярного запуска svnsync sync для поддержания нашего зеркала в актуальном состоянии. Здесь можно выделить два основных лагеря:

• первый: периодический запуск svnsync sync из crond;
• второй: запуск svnsync из post-commit hook(a).

    Минус первого подхода заключается в том, что изменения попадают на зеркало с некоторой задержкой. В самом лучшем случае регулярность обновлений будет кратна одной минуте. Что в свою очередь создаст дополнительные нагрузки на жесткие диски и выброс дополнительного тепловой энергии в атмосферу.
    Минус большинства реализаций второго подхода синхронность запуска. post-commit hook выполняется в рамках svn commit(а). Другими словами svn commit вернет управление только по завершении выполнения всех операций в post-commit hook(e). Получается чем дольше будет работать post-commit hook, тем дольше разработчик будет ждать выполнения svn commit(a). Соответственно теряются драгоценные человеко-минуты.

    Асинхронность второго подхода - это очевидный ответ. Более того, все что потребуется для реализации есть в любом современном дистрибутиве: xinetd и nc.

    Подход предельно прост. В момент выполнения svn commit(a) разработчиком, вызывается post-commit hook, единственная задача которого отправить UDP пакет на заданный порт зеркала SVN. На зеркале SVN(a) указанный порт прослушивает демон xinetd с зарегистрированным обработчиком svnsync sync. Подход дает неоспоримый плюс - в момент commit(a) время отработки post-commit hook(a) минимальны.

    Реализуем теорию на бумаге. Условимся, для UDP пакетов использовать порт 8383, адрес мастер сервера 1.2.3.4, адрес зеркалирующего сервера 5.6.7.8. В мастер репозитории вашего хранилища необходимо создать скрипт hooks/post-commit следующего содержания:

#!/bin/sh

host=5.6.7.8 # Адрес зеркалирующего сервера
port=8383

echo '1' | nc -w 1 -u $host $port

И сделать его исполняемым

chmod +x hooks/post-commit

На зеркалирующем сервере создаем файл /etc/xinetd.d/svnsync следующего содержания:

service svnsync
{
        type                    = UNLISTED
        disable                 = no
        socket_type             = dgram
        port                    = 8383
        wait                    = yes
        user                    = nobody
        passenv                 = PATH
        server                  = /usr/bin/svnsync
        server_args             = sync file:///srv/svn
        only_from               = 127.0.0.1 1.2.3.4  # Адреса, с которых дозволено получать UDP пакеты
}

Описание сервиса предполагает, что зеркало хранилища расположено в директории file:///srv/svn и владельцем файлов является пользователь nobody. Разумеется, не забываем перезапустить/запустить службу xinetd.

Документация:
1. Краткое и емкое руководство о настройке зеркалирования с использованием svnsync;
2. Русскоязычное руководство.

Небольшие жизненные зарисовки.

$ uptime
 16:34:47 up 1039 days,  6:06,  1 user,  load average: 1.48, 1.37, 1.29
$ uname -rs
Linux 2.6.20-19.35.bbel4
$

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

    Однако такое сравнение имеет место быть, т.к. использование дисковых образов очень удобно для размещения разделов для виртуальных машин XEN или KVM. Выделение места на обычном диске в случае частых изменений, как правило, чревато сильной фрагментацией последнего. Рассмотрим на примере. Сначала нам потребовалось 3_и виртуальные машины с объемами диска: 8GB, 16GB, 24GB. Ответственный инженер создал 3-и раздела на физическом диске в 100GB следующую таблицу

/dev/sdx1 - 8GB
/dev/sdx2 - 16GB
/dev/sdx3 - 24GB
free 52Gb

    Спустя месяц у нас появилась еще одна виртуальная машина с разделом в 24 GB, а второй раздел был удален вместе с занимаемой виртуальной машиной

/dev/sdx1 - 8GB
/dev/sdx2 - free
/dev/sdx3 - 24GB
/dev/sdx4 - 24GB
free 44GB

    Таким образом мы пришли к ситуации, что между разделами 1 и 3-и есть 16GB свободного пространства, которое отделено от основной свободной области. И в общем случае не может быть использовано.

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

    Однако и в этой ситуация есть красивое решение. Изначально диск разбить на равного размера разделы. Например, 16GB. Объединяя через LVM нужно количество разделов в виртуальной машине, получаем требуемую дисковую область. Более продвинутый вариант, комбинированная разбивка. Например, 8GB...8GB, 16GB...16GB, 32GB...32GB, 64GB...

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

    В сравнении будет принимать, полюбившаяся всем, платформа SuperMicro SYS-1025W: 2x 2.83 GHz Quad Core Xeon (E5440), 32GB ECC RAM, 3Ware/LSI 9690SA-8I (512MB Memory, BBU). Из 8_ми накопителей SEAGATE ST9146802SS собран программный RAID10 c far размещением блоков:

cat /proc/mdstat
...
md3 : active raid10 sdh3[7] sdg3[6] sdf3[5] sde3[4] sdd3[3] sdc3[2] sdb3[1] sda3[0]
      3950592 blocks 256K chunks 2 far-copies [8/8] [UUUUUUUU]

    Для /dev/md3 используется файловая система ext3 с stride равным 64. Дисковый образ создан командой

dd if=/dev/zero of=128GB.img bs=1GB count=128

Файловая система в нём создана обычным вызовом mkfs.ext3. Тестирование производится 5_и кратным прогоном bonnie++ -x 5 -b.

    CSV файлы для обычной файловой системы и дискового образа. Сводная таблица

+---------------------+-----------+---------+-----------+-------+
|                     | put_block | rewrite | get_block | seeks |
+---------------------+-----------+---------+-----------+-------+
| дисковый накопитель |    209176 |  111778 |    389820 |   772 |
+---------------------+-----------+---------+-----------+-------+
|      дисковый образ |    124299 |  100490 |    391176 |    72 |
+---------------------+-----------+---------+-----------+-------+

    После серого повествования немного рассуждений и выводов. Файловая система в дисковом образе почти в половину уступила файловой системе на дисковом накопителе в блочной записи. В данном виде теста bonnie++ активно выделяет блоки, а данный вид активности удваивается для дискового образа. Что полностью доказывает наши предположения в начале статьи. В rewrite оба претендента держатся на равных. Выделение блоков не требуется, а операции read(2)/write(2)/lseek(2) проходят достаточно прозрачно. В тесте get_block дисковый образ немного превзошел оппонента, сложно предположить как это получилось. Возможно, погрешность тестирования. В тесте seeks безоговорочная победа файловой системы на накопителе. Она практически растоптала оппонента вырвавшись вперед более чем на порядок.

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

При загрузке Debian Lenny в домене domU возникает ошибка

Loading, please wait...
FATAL: Error inserting fan (/lib/modules/2.6.26-2-686-bigmem/kernel/drivers/acpi
/fan.ko): No such device
WARNING: Error inserting processor (/lib/modules/2.6.26-2-686-bigmem/kernel/driv
ers/acpi/processor.ko): No such device
FATAL: Error inserting thermal (/lib/modules/2.6.26-2-686-bigmem/kernel/drivers/acpi/thermal.ko): Unknown symbol in module, or unknown parameter (see dmesg)
kinit: name_to_dev_t(/dev/xvda5) = xvda5(202,5)

В виртуальном окружении управление охлаждением и датчиками температуры не требуется. Избавляемся от их инициализации выполнением набора команд:

install -m 0755 /dev/null /etc/initramfs-tools/hooks/thermal
install -m 0755 /dev/null /etc/initramfs-tools/scripts/init-premount/thermal
update-initramfs -u

В очередную загрузку ядро порадует нас приятным глазу набором информационных сообщений

Loading, please wait...
kinit: name_to_dev_t(/dev/xvda5) = xvda5(202,5)
kinit: trying to resume from /dev/xvda5
kinit: No resume image, doing normal boot...
INIT: version 2.86 booting

Опрашивая модуль Zyxel AAM1212-53 snmpwalk(ом), можно получить много-много букв не говорящих ровным счетом ни о чем:

...
SNMPv2-SMI::transmission.94.1.1.2.1.4.1 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.2 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.3 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.4 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.5 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.6 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.7 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.8 = INTEGER: 298
SNMPv2-SMI::transmission.94.1.1.2.1.4.9 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.10 = INTEGER: 310
SNMPv2-SMI::transmission.94.1.1.2.1.4.11 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.4.12 = INTEGER: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.1 = Gauge32: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.2 = Gauge32: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.3 = Gauge32: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.4 = Gauge32: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.5 = Gauge32: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.6 = Gauge32: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.7 = Gauge32: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.8 = Gauge32: 180
SNMPv2-SMI::transmission.94.1.1.2.1.5.9 = Gauge32: 0
SNMPv2-SMI::transmission.94.1.1.2.1.5.10 = Gauge32: 161

Разумеется, для расшифровки требуется набор MIB файлов:

• Основной набор MIB файлов;
• PerfHist-TC-MIB (зависимость).

И инструкция по подключению дополнительных MIB-файлов к набору программного обеспечения net-snmp.

После размещения MIB-файлов в $HOME/.snmp/mibs отклик от модуля Zyxel AAM1212-53 приобретает следующий вид:

> snmpwalk -m +ADSL-LINE-MIB  -c public -v 2c 192.168.0.57
....
ADSL-LINE-MIB::adslAturCurrOutputPwr.1 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.2 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.3 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.4 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.5 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.6 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.7 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.8 = INTEGER: 122 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.9 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.10 = INTEGER: 123 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.11 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrOutputPwr.12 = INTEGER: 0 tenth dBm
ADSL-LINE-MIB::adslAturCurrAttainableRate.1 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.2 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.3 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.4 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.5 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.6 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.7 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.8 = Gauge32: 1419000 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.9 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.10 = Gauge32: 1057000 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.11 = Gauge32: 0 bps
ADSL-LINE-MIB::adslAturCurrAttainableRate.12 = Gauge32: 0 bps
...
>

Элегантное решение удаления модулей perl, установленных из CPAN в ручную.

Установка Sun StorageTek Common Array Manager Software прервалась сообщением

SEVERE: Error: This user does not have privilege to run this software.

Штудирование показало, что для корректной установки, необходимо установить пакет ksh

yum install ksh

Ответ на этот вопрос можно найти в статье iostat and disk utilization monitoring nirvana. Вычисление параметра %util iostat производит по формуле:

( (r/s + w/s) * svctm / 1000 ms ) * 100

Говоря обывательским языком, суммарное количество записей и чтений инициированных за секунду (1000 ms) умноженное на среднее время обслуживания запроса. Именование колонок соответствует формату команды iostat -x.

В обычной ситуации достаточно указать в /etc/sysctl.conf параметры

kernel.core_uses_pid = 1
kernel.core_pattern = /var/tmp/core.%p.%e.%s
fs.suid_dumpable = 1

Выполнить

sysctl -p;
ulimit -c unlimited

Перезапустить интересуйщий нас процесс командой service и убидиться в том, что параметры успешно применились командой

cat /proc/`pgrep process_name`/limits

Как показала практика описанного набора действий бывает не всегда достаточно. В частности, если SysV скрипт использует функцию daemon(), описанную в /etc/rc.d/init.d/functions, то заданный ранее явно лимит переопределяется следющей строкой

        corelimit="ulimit -S -c ${DAEMON_COREFILE_LIMIT:-0}"

Полагаясь на ее описание, необходимо для сервисов, использующих для запуска функцию daemon(), дополнительно определять в их SysV конфигурационном файле, обычно расположенном в /etc/sysconfig, директивку

DAEMON_COREFILE_LIMIT=unlimited

Например, одним из сервисов, использующий подход с daemon(), является httpd. Согласно его init-скрипту конфигурационный файл расположен в /etc/sysconfig/httpd. Результирующий набор команд будет выглядеть

cat <<EOF >> /etc/sysconfig/httpd
DAEMON_COREFILE_LIMIT=unlimited
EOF
service httpd restart

Исчерпывающее руководство о установке CentOS с использованием встроенного в сетевую карту PXE загрузчика.

Восстановить дату последней модификации файла из базы rpmdb позволяет команда:

touch -m --date="`rpm -q --qf '%{FILEMTIMES:date}' -f <filename>`" <filename>

Например, рассмотрим ситуацию

# rpm -V postgresql-server
.......T  c /var/lib/pgsql/.bash_profile
#

У файла поменялась дата модификации в связи с внесением в него временных изменений. Восстановим дату модификации на хранимую в rpmdb

# touch -m --date="`rpm -q --qf '%{FILEMTIMES:date}' -f /var/lib/pgsql/.bash_profile`" /var/lib/pgsql/.bash_profile

Проверим, что изменения имели место быть

# rpm -V postgresql-server
#

Проверка прошла успешно.

Основная часть заметки была написана в 4_ом часу утра 31 марта 2009 непосредственно в момент описываемых событий.

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

HARDWARE ERROR
CPU 5: Machine Check Exception:                     5 Bank 0: b200004000000800
RIP !INEXACT! 10:<ffffffff8006ad64> {default_idle+0x29/0x50}
TSC 1d24d355f8839d
This is not a sotware problem!
Run through mcelog --acsii to decode and contact your hardare vendor

Полагаясь на диагностику операционной системы, а именно сообщение о том, что проблема связана с железом я погрузился в поиски. Как оказалось существуют 2_а подмножества ошибок:

• исправимых (warning error);
• неисправимых (nonrecoverable, fatal exception).

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

Привлек внимание факт, что сбой произошел в «Bank 0». Согласно презентации Bank с нулевого по третий соответствуют процессорам.

Banks
 0-3 CPU internal (DC, IC, BU, LS)
 4 Northbridge: only really interesting one

С другой стороны аналогичные сообщения возникают из-за внутренней несовместимости оборудования. Например, материнская плата SuperMicro X7DB8+ и дисковый контроллер Adaptec не уживаются вместе.

Днем 31 марта 2009 рассматриваемый сервер был выведен из эксплуатации и начались процедуры тестирования. Неоценимую помощь оказал дистрибутив breakin, который позволил нагрузить систему и воспроизвести сбой. Причина была в недостатке охлаждения. При продолжительной работе в пиковых нагрузках система не справлялась с отводом тепла, что вызывало перегрев процессоров. Проблема скрывалась в аппаратной платформе SuperMicro SYS-1025W, в которую необходимо устанавливать процессоры с меньшим тепловыделением и дополнительные вентиляторы для охлаждения. После этого случая вся используемая нами линейка SYS-1025W была модернизирована описанным способом.

Заметка первоначально была начата 08 июля 2007 года, но, к сожалению, так и не получила завершения. Позволю себе опубликовать ее в незаконченном виде, возможно, кто-то подчерпнет для себя полезную информацию.

Исходные данные:

• HP ProLiant DL360 G5 (дисковый контролер HP SmartArray P400i)
• HP ProLiant DL320 G5 (дисковый контролер HP SmartArray E200)
• HP ProLiant DL320s (дисковый контролер HP SmartArray P400)
• HP ProLiant DL380 G4 (дисковый контролер HP Smart Array 6i)
• Red Hat Enterprise Linux AS 4 (Update 4)

Задача: реализация возможности просмотра/изменения в online параметров и статуса аппаратного дискового массива/контроллера
Для настройки массивов компания HP предлагает 4-е прикладных набора:

• ORCA - A simple ROM-based configuration utility
• ACU - Array Configuration Utility
• ACU CLI - Array Configuration Utility Command Line Interface
• CPQONLIN - A menu-based configuration utility specifically for servers using Novell NetWare

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

Доступ к ORCA возможен только на начальной стадии загрузки сервера (during POST). Разумеется, в production environments это не оправданный простой сервиса. К тому же сам интерфейс достаточно ограничен в возможностях (ряд возможностей в нём просто отсутствует). Соответственно его ниша сильно ограничена первоначальной настройкой системы.
CPQONLIN существует для Novell NetWare. В связи с отсутствием в ближайшем окружении систем с NetWare можно судить лишь по описанию. По возможностям повторяет своих собратьев ACU и ACU CLI.
Основное внимание будет сконцентрировано в эпсилон окрестности ACU и ACU CLI. Обе охватывают весь функционал дисковых контроллеров на заданной платформе Red Hat Enterprise Linux.

HP ACU CLI распространяется как отдельно в виде RPM-пакета, так и в составе ProLiant Support Pack (архив, содержащий в себе актуальные на момент его выхода пакеты различных сетевых, локальных служб и описания к ним). Оба варианта доступны через раздел сайта HP Support & Drivers.

Для рассмотрения был взял актуальный на момент написания RPM-пакет hpacucli-7.80-6.linux.rpm. Для его работы потребовался дополнительный пакет compat-libstdc++-296, входящий в репозиторий дистрибутива. Его установка была произведена командой:

yum -y install compat-libstdc++-296 && rpm -Uvh /path/to/hpacucli-7.80-6.linux.rpm

Первой командой, которую мы настоятельно рекомендуем выполнить hpacucli help и hpacucli shorthand. Последняя отобразит список принятых сокращений. А обе они поведают о всех своим возможностях. Легко заметить простоту синтаксиса:

 <target> <command> [parameter=value]

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

[root@savecore ~]# hpacucli ctrl all show status

Smart Array 6i in Slot 0
   Controller Status: OK
   Cache Status: OK
   Battery Status: OK

[root@savecore ~]# 

Контроллер HP Smart Array 6i расположен в слоте с номером 0. Запрос информации непосредственно о данном контроллере производится явным заданием параметра slot=0:

[root@savecore ~]# hpacucli ctrl slot=0 show detail

Smart Array 6i in Slot 0
   Bus Interface: PCI
   Slot: 0
   Cache Serial Number: P75B20C9SS017I
   RAID 6 (ADG) Status: Disabled
   Controller Status: OK
   Chassis Slot: 
   Hardware Revision: Rev B
   Firmware Version: 2.36
   Rebuild Priority: Low
   Expand Priority: Low
   Surface Scan Delay: 15 sec
   Cache Board Present: True
   Cache Status: OK
   Accelerator Ratio: 50% Read / 50% Write
   Total Cache Size: 192 MB
   Battery Pack Count: 1
   Battery Status: OK
   SATA NCQ Supported: False

[root@savecore ~]# 

Поддерживаемые схемы адресации:

      [controller all|slot=#|wwn=#|chassisname="AAA"|serialnumber=#|chassisserialnumber=#|ctrlpath=#:# 

Централизованная аутентификация с использованием NIS+, LDAP, ... - замечательная штука, товарищи, если реализована со следующими оговорками:

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

Однако любое положительное начало в реальной жизни подпортит небольшая ложка дегтя - NFS. Рассмотрим ситуацию, когда LDAP используется для аутентификации shell-пользователей. В таком постановке задачи сразу назревает вопрос: "как обеспечить централизованное создание домашней директории пользователю, предположим, на десятке серверов? и как обеспечить централизованную синхронизацию информации в домашней директории между машинами?"

Наименее дешевым вариантом оказывается выбор NFS в качестве мастер хранилища и autofs в качестве средства автоматического монтирования. В этом случае пользователь заводится централизованно в каталоге LDAP и одновременно создается его домашняя директория с требуемыми правами. При подключении пользователя к машине по ssh или через getty она автоматически аутентифицирует его через LDAP и с помощью autofs монтирует соответствующую домашнюю директорию.

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

Оглянувшись по сторонам на существующие решения можно заметить NBD. Для полноценной эксплуатации потребуется задействование кластерной файловой системы OCFS2 или GFS. И на выходе получится решение аналогичное NFS только вид сбоку.

Подводя промежуточный итог, получаем, что нам необходимо хранение домашних директорий локальной на каждой машине. Только в этом раскладе удастся уйти от единой точки отказа в случае отказа мастер-узла.

Приходим к проверенному решению с использованием rsync. Файлы по прежнему хранятся на мастер-ноде, но каждая машина с некоторым интервалом забирает их к себе в /home, обеспечивая единое пространство домашних директорий с необходимыми правами.

Из неудобств для пользователей выделяются:

• файлы, хранящиеся на мастер-узле всегда будут перезатирать локальные модификации. Например, если пользователь изменил файл локально и не изменил его на мастер-узле последующий запуск rsync благополучно затрет измения;
• файлы историй, вытекающие плавно из первого пункта. Например, если на мастер-узле по каким-либо причинам остался файл истории .bash_history вся локальная история вызовов будет уходить в пустоту;
• централизованные модификации синхронизируемых файлов необходимо производить на мастер-узле.

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

    Изначально предполагал, что оформлю статью в виде стандартного XHTML, однако в последний момент перемудрил с форматированием, написал все в OpenOffice и экспортировал в PDF.
    На растерзание представляется новый опус Hardware RAID vs Linux Software RAID в схватке за симпатии PostgreSQL (PDF).
    Комментарии в ветке приветствуются.