Все-таки система получается необновляемой. Неужели действительно тяжело собрать через rpmbuild нативно, и написать в спеке те опции сборки, что нравятся?
Автору большое спасибо, было интересно, хотя стоило бы написать больше подробностей про Cluster Suite и drbd.
>>Неприятно удивил способ установки ПО. >>Все-таки система получается необновляемой. > >Очень чудно обновляется . > >cvs up || svn up || git pull || make clean || >make install
А кто будет следить за _версиями_ (не коммитов, а ПО), за необходимостью обновления, и т д? Может быть, еще парсилку комментариев напишем, и внесем в скрипт, который будет по ssh в цикле обходить машины, проверять, и т д?
Чем это лучше LFS? Зачем вообще тогда брать какой-то дистрибутив?
Альтернатива, не изобретение велосипедов. Например, для RH платформы, использованной автором(CentOS, RHEL, Fedora и все остальные) есть очень и очень удобный инструмент для управления ПО:
(если закрыть глаза на Жабу и Оракл, каналы с ПО просто потрясающе удобно!)
У SLE (ZenWorks) и у Ubuntu (LaunchPad) есть аналогичные решения (я с ними не работала, и удобность, плюсы и минусы прокомментировать не могу)
Даже чистые rpm(что стоит только rpm -V), dpkg, yum, up2date, zypper, apt/aptitude, если не боятся ими пользоваться, умеют гораздо больше, и являются инструментами, созданными специально для этой цели. В конце концов, есть порты в той же Gentoo и FreeBSD, хотите все собирать, но ленитесь править спек rpm-а (а поправить строчку с configure в секции %build в vim можно парой-тройкой команд 🙂 ), мешает религия? Есть системы, которые ориентированы на source-бэйсед подход (что и там, особенно во фре, не мешает пользоваться бинарными пакетами)
Стоит еще представить что будет, когда такая система передается другому администратору или закачику, с этой горой костылей и скриптов, парсящих ревизии и матюки в комментариях коммитеров 🙂
>>>Неприятно удивил способ установки ПО. >>>Все-таки система получается необновляемой. >> >>Очень чудно обновляется . >> >>cvs up || svn up || git pull || make clean || >>make install > >А кто будет следить за версиями
А зачем? Работает — нетрож, глючит проверяй.
Вон блин, в Дебиане, grub самообновился до grub2, а я его с утра и не узнал.
>>А кто будет следить за версиями >А зачем? Работает — нетрож, глючит проверяй.
Записываем: за версиями будет следить друхх павлина Глючит-Проверяй! |-)
Причём если оно вдруг собралось и проинсталировалось с «какими есть» зависимостями, но — вдруг! — с этими же зависимостями не запустилось или, например, не работает «где-то там, иногда», то делать он это будет при упавшем-типа сервере. Но, у него всё получится — мы в него верим! :/
>[оверквотинг удален] >> make >> make install > >Вместо этого выполняем > ># cd /tmp ># wget http://samba.org/samba/ftp/stable/samba-3.4.5.tar.gz ># tar zxvf samba-3.4.5.tar.gz ># cd samba-3.4.5/packaging/RHEL ># sh makerpms.sh
8 * 4 = 32 Мбит — это скорость в хреновой сети на хабах, с сетевухами Realtek 8139
>Samba без CTDB >2,15 >2,16 >2,13 >2,09
см. выше >Samba + CTDB >24,73 >23,42 >23,26 >23,15 > Сервер был доступен по кналу 1 Гб/с, >поэтому суммарно использовано около 75% пропускной способности.
А по-моему 19.2% пропускной способности. 24,73 * 8 бит = 192 Mbit в сек.
Господа, у Вас проблемы с сетью.
> Скорость записи идентична, не намного уступает, определяется > скорее возможностями файловой системы.
Ну я решил внести и свои пять копеек, правда они автору ох как не понравятся. Вообще из заголовка следует что есть о чем новом почитать и узнать много нового. Но как-то странно я по тексту статьи так и не понял про что идет речь. Я конечно знаю что такое samba и даже знаю что такое кластер высокой готовности, и даже знаю что такое drbd, и heartbeat (кстати после его упоминания я что-то не нашел что про него еще что то дополнительно написано). Но я так и не понял что такое CTDB. Опять же я не понял почему используется именно то ПО которое указано в начале статьи. С чем связан их выбор? Почему использовался drbd если у Вас используется GFS, почему не стали использовать GNBD из поставки Red Hat? С чем связано использование DRBD именно в режиме master/master? Ну и самое главное для каких целей поднималась данная конфигурация? Про то как устанавливается ПО в дистрибутиве который имеет мощнейшие средства для управления/установки/удаления/сборки и т.п. я говорить не приходится. Я советую автору все таки статью переделать полностью. Хотя бы все то что указано в первом абзаце. Ну и тесты я думаю здесь если и нужно проводить то уже никак не копированием файлов.
http://ctdb.samba.org/ особенно это: — CTDB is the core component that provides pCIFS («parallel CIFS») with Samba3/4. — CTDB provides HA features such as node monitoring, node failover, and IP takeover. >Ну и тесты я думаю здесь если и нужно проводить то уже никак не копированием файлов.
а чем? и чем не устраивает?
зы: если есть что добавить к статье — ю а велком. блин, этож не кандидатская защищается, где любой может резко раскритиковать. с чего вообще взяли, что он должен объяснять, что такое CTDB?
Предполагается, что все кластерные службы, а так же службы обеспечения высокой готовности настроены и запущены. В моем случае, кластер состоит из 2-х узлов.
В данном случае использован следующий набор ПО для High-Aviability: Операционная система — CentOS 5.4 Кластерное ПО — все от RedHat (группы пакетов «Cluster» и «Cluster Storage») Файловая система для общего хранилища — GFS2. Репликация дисков DRBD8 (замечу, все узлы в режиме «primary») Механизм «сердцебиения» — опционально(далее поясню, почему) — HeartBeat.
автор, не могли бы вы перечислить вообще софт используемый для этого, а то из вашего текста выходит — что заведется это на любом дистре, стоит только там поставить самбу и ctdb.
пока же совершенно очевидно, что вы увидели в man smb.conf опции про clustering и решили об этом всем рассказать
я не автор. а автор итак уже поделился своей историей_успеха. собственно я предположил, что от него требовать что-то ещё, с разжёвыванием, на мой взгляд глупо (и нагло). спросить/уточнить/добавить — наверное приветствуется. я не прав? всё ПО перечислено. а для остального используется гугль и википедиа. >а то из вашего текста выходит — что заведется это на любом дистре, стоит только там поставить самбу и ctdb.
заведётся. и не обязательно с именно таким ПО. и в таком количестве. просто он описал именно свою конфигурацию. зы: надеюсь у автора местные аналитеги не отбили желание писать дальше.
а самому подрочиться очень тяжело, в качестве обзора статья хороша , только очень много всяких приложений проще на HA и drbd виртуализацию накрутить, а в случае в rhel + drbd + GFS2 ha-кластер средствами RHEL собрать , ни к чему так усложнять все.
Спасибо за статью — не знал про CTDB и обходился классической схемой с «бекапной» нодой. Все вполне понятно описано, а про rpmbuild и подобное — не слушайте эту ерунду, proof of concept тут есть, а уж статей по репозиториям для RHEL/CENTOS/Debian etc., и так хватает, кому надо красиво — сделает spec файлы.
а ниче что spec файл уже есть в исходниках, видать разработчики самбы для прикола его туда положили 🙂
> А зачем? Работает — нетрож, глючит проверяй.
> с чего вообще взяли, что он должен объяснять, что такое CTDB?
а какой тогда глубокий смысл в статье?
> Samba использует легковесную базу данных (TDB) для приведения соответствия Windows SID к Unix UID/GID
Источник
Clustered file server linux
В предыдущих статьях рассматривался вариант установки файлового сервера Samba в связке с доменом FreeIPA, разграничение прав доступа на каталоги и установка файлового сервера NFS в кластере высокой доступности. Сервер NFS прекрасно живет и работает в среде Linux (Unix). Но для клиентов Windows как правило возникают проблемы (отсутствие встроеного клиента NFS, проблемы с отработкой групповых политик и.т.д. и т.п.). Поэтому попробуем «скрестить бульдога с носорогом» и установить файловый сервер Samba в уже развернутый и настроенный кластер, который обслуживает доступ к файлам по NFS. Работы как всегда будут проводится в рамках «импортозамещения» на ОС Rosa Enterprise Linux Server 7.3 (RELS 7.3) (он же CentOS 7.3, он же RedHat 7.3)
Развернутые и настроенные два виртуальных хоста, объединенные в кластер (настройка кластера здесь).
Сетевое хранилище, на котором выделен кусок пространства для организации файлового сервера.
Имена узлов: fs-01.rpn.int — первый хост кластера fs-02.rpn.int — второй хост кластера smb.rpn.int — имя виртуального сервера, к которому будут подключаться клиенты
Процесс настройки настройки кластера Samba в режиме active/active состоит из нескольких шагов:
Создание кластера высокой доступности.
Создание и конфигурирования кластерной файловой системы GFS2.
Конфигурирование Samba на обоих узлах кластера
Ну тестирование всего того, что у нас получилось.
Создание кластера.
Как таковой кластер мы уже создали (смотрим здесь). Требуется только добавить один ресурс и немного изменить параметры кластера.
Так как хосты кластера будут располагаться в виртуальной среде Vmvare vSphere, то создаем ресурс, который будет отслеживать состояние виртуальной машины и в случае возникновения проблем с этой виртуальной машиной будет отключать ее от кластера:
vcenter-fence — имя ресурса ipaddr=XXX.XXX.XXX.XXX — IP адрес сервера управления vCenter Server ipport=9443 — порт для подключения к vCenter Server login=vcadmin — логин администратора vSphere passwd=XXXX — пароль администратора vSphere Так же указаны имена узлов файлового кластера
Для работы с GFS2 потребуется изменить глобальный параметр:
Кластерная файловая система GFS2.
Для работы Samba в кластере нам необходимо создать кластерный LVM том для совместной работы узлов кластера.
Подключаем общий диск к узлам кластера как описано здесь.
На всех узлах кластера устанавливаем необходимое ПО:
Далее работы проводятся на одном из узлов кластера.
Создаем dlm ресурс. Этот ресурс требуется для службы clvmd и файловой системы GFS2 .
Настраиваем сервис clvmd в качестве ресурса кластера:
Здесь агент ресурса ocf:heartbeat:clvm является частью процедуры запуска, устанавливает параметр lock_type в файле /etc/lvm/lvm.conf равным 3 и отключает демон lvmetad .
Устанавливаем зависимость clvmd и dlm. Настраиваем порядок запуска ресурсов. Ресурс clvmd должен запускаться после ресурса dlm и должен выполняться на том же узле, что и ресурс dlm .
Проверяем что ресурсы dlm и clvmd созданы и запущены на всех узлах:
Создание кластерного логического раздела.
Ранее мы создали и подключили общий диск ко всем узлам кластера. В устройствах он у нас виден как /dev/sdc . Создаем логический раздел на этом диске (работы производятся только на одном узле кластера):
Проверяем наличие созданного раздела:
Форматируем раздел с файловой системой GFS2. Используемые параметры: my_cluster — это имя кластера; -j 2 — указываем два журнала, поскольку количество настраиваемых журналов должно равняться количеству узлов в кластере.
Создаем в кластере ресурс файловой системы, который настраивает Pacemaker для монтирования и управления файловой системой. В этом примере создается ресурс файловой системы с именем fs_smb_cluster и создается точка монтирования /opt/smb_fs на обоих узлах кластера. Так же включается параметр, позволяющий использовать на файловой системе расширенные права доступа (ACL).
Настраиваем зависимость и порядок запуска файловой системы GFS2 и службы clvmd . GFS2 должен запускаться после clvmd и должен выполняться на том же узле, что и clvmd.
После создания ресурса файловой системы, ранее созданный раздел должен смонтироваться в точке /opt/smb_fs на всех узлах кластера.
Настраиваем Samba.
Далее настраиваем Samba для работы в кластере. Следующие шаги необходимо производить на всех узлах кластера. Т.е. конфигурационные файла должны быть одинаковыми на всех узлах.
Устанавливаем необходимое ПО:
Останавливаем и запрещаем автозапуск следующих служб:
Приводим файл /etc/samba/smb.conf к виду (здесь публикуется общая папка public ):
Здесь приведена конфигурация сервера Samba в режиме Standalone. Работа сервера в домене FreeIPA, а также авторизация пользователей из доверенного домена Windows Active Directory будет рассмотрена ниже.
Создаем файл /etc/ctdb/nodes :
В этот файл записываются IP адреса всех хостов кластера.
Для организации балансировки нагрузки между узлами кластера необходимо добавить два или более (в зависимости от числа узлов) IP-адреса, которые будут использоваться для доступа к файлам Samba, предоставляемым этим кластером, в файл /etc/ctdb/public_addresses . Эти IP-адреса, которые необходимо настроить в DNS для имени сервера Samba, являются адресами, к которым будут подключаться клиенты SMB. Нужно настроить имя сервера Samba как одну запись DNS типа A с несколькими IP-адресами. DNS-сервер распределяет клиентов по узлам кластера с соответствующим IP адресом. В этом примере:
Эти адреса не должны принадлежать никаким физическим адаптерам узлов кластера и являются «виртуальными». Т.е. клиенты, обращаясь к серверу по FQDN файлового сервера (в данном случае smb.rpn.int) будут оращаться именно по этим адресам.
Создаем файл /etc/public_addresses :
Где eth0 — имя физического интерфейса узла кластера. Оно может быть другим в зависимости от системы.
Создаем группу smbguest и пользователя smbguest для доступа к папке public :
Создаем каталог для работы ctdb и, если не отключен SeLinux , настраиваем его для корректной работы:
Далее необходимо проверить идентичность файлов настройки на всех узлах кластера (либо настроить синхронизацию необходимых файлов).
Следующие настройки производятся только на одном из узлов кластера.
Создаем каталоги для работы CTDB (ctdb lock) и общую папку public :
Назначаем права на каталоги и настраиваем их для работы с SELinux:
Создание ресурсов кластера Samba.
Настраивать кластер будем путем импорта текущих настроек в файл samba.cib, внесения изменений в это файл и окончательного экспорта настроек из этого файла в работающий кластер.
Импорт текущих настроек:
Создаем ресурс CTDB, необходимый для работы Samba. Ресурс создается клонированным, для того, что бы он работал одновременно на всех узлах кластера.:
Создаем клонированный сервер Samba:
Создаем ограничения и порядок размещения ресурсов кластера. Настраиваем порядок запуска ресурсов: в первую очередь запускается ресурс файловой системы, затем ресурс CTDB и в последнюю очередь запускается ресурс сервера Samba:
Загружаем измененный файл, содержащий новые настройки кластера, samba.cib в кластер:
Выводим статус кластера для того, что бы убедиться, что ресурсы созданы и запущены на всех узлах кластера.
Запуск ресурсов кластера может занять несколько минут. Если запустить вывод статуса кластера до того, как все ресурсы успешно стартуют, то будет выводиться сообщение об ошибке (например статус ресурса CTDB). После успешного старта всех ресурсов, сообщение об ошибке можно очистить командой pcs resource cleanup ctdb-clone
Если статус какого-либо ресурса говорит об ошибке, то можно запустить ресурс в режиме отладки командой resource debug-start resource . Эта команда запускает ресурс за пределами контроля кластера. Если ошибка устранена и ресурс успешно запускается, то необходимо запустить pcs cluster cleanup resource , для того, что бы кластер узнал об изменениях.
Если все ресурсы успешно запущены, то файловый сервер будет доступен по «виртуальному» адресу smb.rpn.int .
Настройка авторизованного доступа.
Мы успешно настроили и запустили файловый сервер Samba в отказоустойчевом кластере. Но т.к. мы используем доменную стуктуру, необходимо организовать авторизованный доступ на файловые ресурсы. В первую очередь все узлы кластера должны быть членами домена FreeIPA. Настройка самой Samba ничем не отличается от процедуры, описанной в этой статье, за исключением двух моментов: регистрация CIFS сервера в домене FreeIPA и создания файла samba.keytab.
Т.к. у нас в кластере находятся два физических узла и один виртуальный (имеется ввиду два узла кластера, использующие одно «виртуальное» имя сервера для доступа к ресурсу), то в домене необходимо зарегистрировать все три имени сервера: fs-01.rpn.int , fs-02.rpn.int и smb.rpn.int .
Не забываем, что все изменения в файле smb.conf должны быть одинаковыми на всех узлах кластера.
Так же есть тонкости в получении файла keytab.
Выполняем на любом сервере кластера:
Где dc.rpn.int — имя контроллера домена FreeIPA.
Тем самым мы создаем файл keytab для Samba и помещаем его в каталог на общем диске.
Настройка прав доступа на каталоги ничем не отличается от настроек, описанных в этой статье.
После того, как получен файл keytab и произведены настройки файла smb.conf, необходимо перестартовать ресурс сервера Samba:
После этого Samba перечитает свою новую конфигурацию на всех узлах кластера и вступит в силу авторизованный доступ к опубликованным ресурсам.
Если все нормально, то пользователям Active Directory можно создавать групповые политики для подключения к файловому серверу. С пользователями домена FreeIPA дело обстоит несколько иначе. Можно локально настроить сервис autofs на каждом ПК для подключения к этим ресурсам. Но если клиентов много, то это не вариант. FreeIPA умеет централизованно управлять автомонтированием сетевых ресурсов на клиентских ПК (аналог групповых политик Active Directory от Microsoft). Хотя во всех мануалах указано, что данная функция работает только с файловым сервером NFS, мне удалось настроить соответствующую политику для автомонтирования ресурсов Samba через политики FreeIPA.
Настройка политики автомонтирования.
Итак. Мы настроили файловый сервер Samba, работающий в кластере. Настроили авторизацию в домене FreeIPA согласно статье. Настроили разганичение прав доступа на разные папки согласно этой статье. В итоге имеем:
Файловый сервер отвечает по FQDN smb.rpn.int
Настроен общий ресурс «DST» для досупа пользователям домена FreeIPA (и пользователям доверенного домена Windows)
Необходимо настроить политику автомонтирования общего ресурса на клиентах FreeIPA.
Переходим в консоль контроллера домена FreeIPA.
Получаем билет администратора домена:
Создаем локацию, которая будет использоваться для управления точками подключения ресурсов файлового сервера:
Добавляем карту монтирования:
Добавляем ссылку на auto.smb в auto.master
Добавляем ключ монтирования в auto.smb:
В итоге после того, как на клиентах FreeIPA будет настроен механизм автомонтирования (на клиенте запускается команда ipa-client-automount —location FileServer ), у них (у клиентов) появится папка /home/NetFiles/DST к которой будет предоставлен доступ тому или иному пользователю в зависимости от настроек Samba.
Предполагается, что все кластерные службы, а так же службы обеспечения высокой готовности настроены и запущены. В моем случае, кластер состоит из 2-х узлов. 
а самому подрочиться очень тяжело, в качестве обзора статья хороша , только очень много всяких приложений проще на HA и drbd виртуализацию накрутить, а в случае в rhel + drbd + GFS2 ha-кластер средствами RHEL собрать , ни к чему так усложнять все. 
Спасибо за статью — не знал про CTDB и обходился классической схемой с «бекапной» нодой. Все вполне понятно описано, а про rpmbuild и подобное — не слушайте эту ерунду, proof of concept тут есть, а уж статей по репозиториям для RHEL/CENTOS/Debian etc., и так хватает, кому надо красиво — сделает spec файлы. 
