- При росте нагрузки на сайт его можно практически неограниченно масштабировать, обеспечивая нужную производительность.
- Сайт максимально доступен для посетителей. В случае выхода из строя одного или нескольких серверов веб-кластера система продолжает беспрерывно обслуживать клиентов на остальных работающих машинах.
[spoiler]Именно поэтому мы решили подробно описать процесс запуска веб-кластера на виртуальных машинах в "облаке" . Наш эксперимент может повторить любой желающий.
Итак: для того, чтобы получить собранный работающий веб-кластер, нам понадобится 1-3 часа свободного времени (зависит от квалификации и наличия навыков администрирования)... и все! Полнофункциональная демо-версия "1С-Битрикс: Управление сайтом" работает бесплатно в течение 30 дней, "Оверсан-Скалакси" при регистрации дает 250 рублей - этой суммы вполне достаточно для выполнения всех работ.
Так что, на первом этапе - никаких первоначальных вложений. Решение о покупке (как хостинга, так и лицензии) можно принять позже, сначала все попробовав и оценив на практике.
* * *
Наш первый шаг - заходим на сайт , выбираем "Сервер Битрикс" и нажимаем кнопку "Заказать".
"Сервер Битрикс" - это специально подготовленный техническими специалистами "Оверсан-Скалакси" образ виртуальной машины, основанный на бесплатном продукте .
В такой виртуальной машине уже сконфигурированы и оптимально настроены MySQL, Apache, PHP и другое ПО, необходимое для работы сайтов, разработанных на платформе "1С-Битрикс".
После заказа сервера мы попадаем на простую форму регистрации: логин (e-mail), пароль и капча.
Заполняем поля, ссылка на подтверждение регистрации приходит на указанный нами e-mail.
Следующий шаг - заполнение регистрационных данных. Если вы планируете стать постоянным клиентом "Скалакси", заполните их. Мы же в своих тестах пока пропустим этот шаг и сразу перейдем в панель управления.
Приступаем непосредственно к созданию нового сервера. Эта процедура достаточно простая, всего два шага. Первый - выбор операционной системы и задание пароля root'а:
Второй шаг - настройка параметров сервера.
Мы выбрали простую конфигурацию:
- 512 Мб RAM (без возможности масштабирования "на лету", жестко зафиксировав этот параметр)
- 1 Гб swap
- внешний канал - 5 Мбит с возможностью расширения до 30 Мбит
- купили внешний IP-адрес
Для реального "живого" проекта, конечно же, параметры могут быть иными.
Здесь же, на втором шаге создания сервера при необходимости можно добавить диски и разделы (корневой раздел создается по умолчанию).
Задаем имя для нашего сервера. Например, www1.
Ждем запуска виртуальной машины - она стартует несколько секунд.
Когда все готово (сервер "зеленый", в логе операций написано, что "сервер запущен" ), мы можем открыть полученный IP-адрес в браузере и увидеть стандартный, привычный для многих интерфейс виртуальной машины "1С-Битрикс":
Выбираем новую установку, из списка доступных для установки продуктов выбираем "Управление сайтом" - редакцию "Бизнес веб-кластер".
Проходим все стандартные шаги установки и получаем готовый работающий сайт (мы для экспериментов выбрали типовой интернет-магазин).
Пора приступать к созданию второго сервера.
Можно было бы просто повторить всю процедуру еще раз, но это - неинтересно. У "Скалакси" есть замечательная возможность - клонирование виртуальных машин. Воспользуемся ей:
После того, как мы выбрали нужный сервер (он, правда, у нас пока только один), его необходимо выключить, а затем в меню "Еще действия" кликнуть на пункт "Клонировать".
Новый сервер называем, например, www2.
Хоть это и не очень необходимо, но просто для удобства - покупаем еще один IP в панели управления в разделе "IP & DNS" и привязываем его к новому серверу.
Включаем оба сервера.
Теперь у нас есть два независимых друг от друга сервера/сайта, никак не объединенные друг с другом. Начнем делать из них один кластер.
Предварительная подготовка
Для синхронизации файлов мы будем использовать утилиту . Для ее работы требуются фиксированные имена (hostname) у всех серверов, которые участвуют в синхронизации.
Для двух наших виртуальных машин в Scalaxy были выделены внутренние IP-адреса: 10.1.1.1 и 10.1.1.2. Будем использовать именно их.
На первом сервере зададим hostname:
# hostname www1.local |
На втором:
# hostname www2.local |
На каждом сервере в файле /etc/hosts пропишем:
10.1.1.1 www1.local 10.1.1.2 www2.local |
Теперь мы можем использовать не только внутренние IP, но и имена www1.local и www2.local. При работе с этими адресами весь трафик будет идти по внутренним интерфейсам, что дает ряд преимуществ:
- более высокая скорость передачи данных между серверами
- в общем случае (не только в "Скалакси", а, например, еще в Amazon и других подобных сервисах) внутренний траффик не тарифицируется.
Для кэша мы будем использовать пул серверов memcached. (Подробно о .)
Параметры запуска демона memcached на каждой виртуальной машине можно задать в файле /etc/sysconfig/memcached. Мы оставим их такими, как они заданы по умолчанию.
На каждом сервере необходимо выполнить команды:
# service memcached start # chkconfig memcached on |
В административном интерфейсе "1С-Битрикс" в разделе "Настройки" - "Веб-кластер" - "Memcached" добавляем оба сервера:
После того, как оба сервера добавлены, в контекстном меню выбираем "начать использовать".
После этого вся система кэширования начинает использовать для хранения и получения данных не файловую систему сервера, а весь пул серверов memcached. В нашем случае их два, но на практике можно использовать любое количество.
Firewall
Мы запустили сервисы memcached на машинах, и они у нас "открыты всем ветрам". На порт memcached - 11211 - может обратиться кто угодно и откуда угодно. Что, конечно же, неправильно.
Добавим несколько правил в iptables, которые будут разрешать коннекты к нужным сервисам только с наших собственных IP (при чем - с внутренних интерфейсов), и ни с каких других.
На первом сервере (www1, 10.1.1.1):
# iptables -A INPUT -p tcp -d 10.1.1.1 -s 10.1.1.1 --dport 3306 -j ACCEPT # iptables -A INPUT -p tcp -d 10.1.1.1 -s 10.1.1.2 --dport 3306 -j ACCEPT # iptables -A INPUT -p tcp --dport 3306 -j DROP # iptables -A INPUT -p tcp -d 10.1.1.1 -s 10.1.1.1 --dport 11211 -j ACCEPT # iptables -A INPUT -p tcp -d 10.1.1.1 -s 10.1.1.2 --dport 11211 -j ACCEPT # iptables -A INPUT -p tcp --dport 11211 -j DROP # iptables -A INPUT -p tcp -d 10.1.1.1 -s 10.1.1.1 --dport 30865 -j ACCEPT # iptables -A INPUT -p tcp -d 10.1.1.1 -s 10.1.1.2 --dport 30865 -j ACCEPT # iptables -A INPUT -p tcp --dport 30865 -j DROP |
На втором (www2, 10.1.1.2):
# iptables -A INPUT -p tcp -d 10.1.1.2 -s 10.1.1.1 --dport 3306 -j ACCEPT # iptables -A INPUT -p tcp -d 10.1.1.2 -s 10.1.1.2 --dport 3306 -j ACCEPT # iptables -A INPUT -p tcp --dport 3306 -j DROP # iptables -A INPUT -p tcp -d 10.1.1.2 -s 10.1.1.1 --dport 11211 -j ACCEPT # iptables -A INPUT -p tcp -d 10.1.1.2 -s 10.1.1.2 --dport 11211 -j ACCEPT # iptables -A INPUT -p tcp --dport 11211 -j DROP # iptables -A INPUT -p tcp -d 10.1.1.2 -s 10.1.1.1 --dport 30865 -j ACCEPT # iptables -A INPUT -p tcp -d 10.1.1.2 -s 10.1.1.2 --dport 30865 -j ACCEPT # iptables -A INPUT -p tcp --dport 30865 -j DROP |
Что мы сделали?
Разрешили соединения на порты 3306 (MySQL), 11211 (memcached), 30865 (csync2) только с локальных машин. С других адресов - запретили.
Обратите внимание, такие команды для iptables - только пример. На "живом" проекте вся конфигурация файрволла может быть иной.
Синхронизация файлов
Подробно о способах хранения контента и вариантах синхронизации данных .
Мы же на практике будем использовать достаточно простую схему: на каждой виртуальной машине мы будем использовать локальное хранилище, а для синхронизации файлов на наших двух серверах мы будем использовать утилиту csync2.
К сожалению, ее нет в стандартных репозиториях CentOS (именно эта система используется в качестве основы виртуальной машины "1С-Битрикс" ). Поэтому стандартный путь установки ("yum install" ) не подойдет.
Можно устанавливать csync2 по-разному (например, собрав из исходников). Мы поставим эту утилиту следующим образом.
1. Устанавливаем необходимые доступные пакеты (библиотеки rsync используются в csync2, из xinetd будет запускаться серверная часть csync2):
# yum install rsync librsync-devel xinetd |
2. Устанавливаем libtasn1 - библиотеку для работы с X.509 (требуется для csync2):
# wget http://ftp.freshrpms.net/pub/freshrpms/redhat/testing/EL5/cluster/x86_64/libtasn1-1.1-1.el5/libtasn1-1.1-1.el5.x86_64.rpm # wget http://ftp.freshrpms.net/pub/freshrpms/redhat/testing/EL5/cluster/x86_64/libtasn1-1.1-1.el5/libtasn1-devel-1.1-1.el5.x86_64.rpm # wget http://ftp.freshrpms.net/pub/freshrpms/redhat/testing/EL5/cluster/x86_64/libtasn1-1.1-1.el5/libtasn1-tools-1.1-1.el5.x86_64.rpm # rpm -ihv libtasn1-1.1-1.el5.x86_64.rpm libtasn1-devel-1.1-1.el5.x86_64.rpm libtasn1-tools-1.1-1.el5.x86_64.rpm |
3. Устанавливаем sqlite (2-ой версии) - именно эта версия используется в csync2:
# wget http://ftp.freshrpms.net/pub/freshrpms/redhat/testing/EL5/cluster/x86_64/sqlite2-2.8.17-1.el5/sqlite2-2.8.17-1.el5.x86_64.rpm # wget http://ftp.freshrpms.net/pub/freshrpms/redhat/testing/EL5/cluster/x86_64/sqlite2-2.8.17-1.el5/sqlite2-devel-2.8.17-1.el5.x86_64.rpm # rpm -ihv sqlite2-2.8.17-1.el5.x86_64.rpm sqlite2-devel-2.8.17-1.el5.x86_64.rpm |
4. Устанавливаем непосредственно csync2:
# wget http://ftp.freshrpms.net/pub/freshrpms/redhat/testing/EL5/cluster/x86_64/csync2-1.34-4.el5/csync2-1.34-4.el5.x86_64.rpm # rpm -ihv csync2-1.34-4.el5.x86_64.rpm |
Необходимо сгенерировать файл ключей. На машине www1 выполняем:
# csync2 -k /etc/csync2/csync2.cluster.key |
...и копируем полученный файл на машину www2.
Создаем одинаковые конфигурационные файлы - /etc/csync2/csync2.cfg - на обоих серверах:
group cluster {
host www1.local www2.local;
key /etc/csync2/csync2.cluster.key;
include /home/bitrix/www;
exclude /home/bitrix/www/bitrix/cache;
exclude /home/bitrix/www/bitrix/managed_cache;
exclude /home/bitrix/www/bitrix/php_interface/dbconn.php;
auto younger;
} |
Теперь построим локальную базу всех файлов проекта, с которой работает csync2.
Если данные на серверах идентичны, можно использовать команду:
# csync2 -cIr / |
Мы выполняем именно ее, так как второй сервер клонирован из первого.
Если есть какие-либо различия (например, данные на второй сервер копировали с первого по сети, и при этом в это же время на первом сервере могли быть изменены какие-либо данные), лучше использовать:
# csync2 -cr / |
Эта команда будет работать дольше, и при первом запуске синхронизации будут проверены на актуальность все данные (что тоже для первого раза будет работать достаточно долго, несколько минут).
Работа csync2 на каждом хосте состоит из двух частей - серверной и клиентской. Для запуска серверной части необходимо закомментировать (символом #) в файле /etc/xinetd.d/csync2 строку "disable = yes", перезапустить сервис xinetd и разрешить его запуск при загрузке системы:
# service xinetd restart # chkconfig xinetd on |
Клиентская часть - запуск csync2 с ключом "-x".
Можно определить (в зависимости от объема данных) необходимую частоту обновлений и прописать запуск csync2, например, через cron. Строка в /etc/crontab:
*/5 * * * * root /usr/sbin/csync2 -x >/dev/null 2>&1 |
...означает запуск csync2 каждые 5 минут.
Что мы получили в итоге? На каждом сервере используется локальное хранилище (локальные диски). При этом все изменения (создание, удаление, редактирования файлов) на каждом сервере с достаточно высокой частотой синхронизируются на втором сервере.
На "живом" сайте может использоваться любое количество серверов, а не только два (как в нашем примере).
Переходим к MySQL
Механизм репликации в MySQL существует достаточно давно и используется на многих проектах.
Что дает поддержка этого механизма в веб-кластере "1С-Битрикс"?
- Во-первых, возможность гибкого распределения нагрузки между разными серверами, участвующими в репликации (для каждого сервера можно задать "вес" ).
- Во-вторых, вся нагрузка распределяется "по-умному" (запросы на запись - на master, запросы на чтение - на slave; если произошло важное изменения данных, а slave "отстает" (такое бывает, это - вполне штатная ситуация), запросы на чтение тоже будут идти на master; если отставание slave слишком велико, он временно отключается из схемы балансировки нагрузки).
- В-третьих, поддержка репликации реализована на уровне API платформы "1С-Битрикс". Это значит, что разработчикам не требуется переделывать приложения или использовать какую-то новую сложную логику.
С теорией - ознакомились. Приступаем к практической реализации.
Комментируем в файле /etc/my.cnf строку:
#bind-address = 127.0.0.1 |
Перезапускаем mysqld:
# service mysqld restart |
Создаем на обоих серверах в MySQL новых пользователей, которым будут разрешены соединения снаружи. В консоли mysql выполняем:
mysql> USE mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> INSERT INTO `user` VALUES ('10.1.1.%','root',PASSWORD('TutNashSekretnyjParol'),'Y','Y','Y','Y','Y','Y','Y','
Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','','','','',0,0,0,0);
Query OK, 1 row affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
|
В реальном проекте можно использовать меньший набор привилегий, но для тестов мы дадим их все.
На обоих серверах изменяем параметры соединения с базой - в файле /home/bitrix/www/bitrix/php_interface/dbconn.php указываем первый сервер:
$DBType = "mysql"; $DBHost = "10.1.1.1"; $DBLogin = "root"; $DBPassword = "TutNashSekretnyjParol"; $DBName = "sitemanager0"; |
В административном интерфейсе "1С-Битрикс" в разделе "Настройки" - "Веб-кластер" - "Репликация" добавляем новый сервер через мастер подключения.
Он проверяет корректность всех настроек, необходимых для правильной работы MySQL в режими репликации. При первом запуске мы видим ряд замечаний:
Исправляем их все и повторно подключаем второй сервер. Все проверки проходят. Задаем параметры подключения:
В контекстном меню для второго сервера выбираем "Начать использование".
Новый мастер автоматически перенесет все данные из первой базы во вторую. В момент переноса будет остановлена публичная часть сайта:
После того, как перенос закончен, все запросы, создаваемые скриптами сайта, распределяются между двумя серверами (на "живом" проекте их может быть любое количество). Критерии распределения нагрузки можно задать для каждого сервера отдельно:
И что теперь?
Наш веб-кластер практически готов.
Последний шаг - нам нужно добиться того, чтобы все обращения посетителей на наш сайт распределялись между двумя серверами.
Самый простой и "дешевый" способ решить эту задачу - использовать механизм .
Для одного адреса (например, можно прописать несколько IN A записей:
www IN A xx.xx.xx.1 www IN A xx.xx.xx.2 |
В этом случае DNS сервер в ответ на запрос разрешения имени в IP-адрес будет выдавать не один адрес, а весь список:
# host www.site.ru www.site.ru has address xx.xx.xx.1 www.site.ru has address xx.xx.xx.2 |
При этом с каждым новым запросом последовательность адресов в списке в ответе будет меняться. Таким образом клиентские запросы будут распределяться между разными адресами и будут попадать на разные серверы.
Использование round robin DNS - самый простой способ балансировки нагрузки, не требующий никаких дополнительных средств, однако он обладает целым рядом недостатков:
- нет четкого критерия выбора IP из списка клиентом (может выбираться первый элемент, может кэшироваться последнее выбранное значение, возможны иные варианты) - все зависит от реализации конкретного клиента;
- нет механизмов определения доступности узлов и возможности задания их "весов" - в случае аварии на одном или нескольких узлах кластера нагрузка будет продолжать распределяться между рабочими и вышедшими из строя нодами;
- длительное время кэширования ответов DNS - в случае аварии и изменении тех или иных записей в DNS потребуется некоторое время (зависит от настроек DNS) для обновления данных на всех клиентах.
Для этого можно использовать централизованное хранилище для данных сессий. В нашем случае - база данных. Включается хранение данных сессий в базе в разделе "Настройки" - "Веб-кластер" - "Сессии":
Если же мы хотим распределять нагрузку между узлами кластера "по-взрослому", мы можем, например, добавить еще одну виртуальную машину в панели управления "Скалакси", выбрать любой (знакомый и удобный для нас) дистрибутив Linux и установить один-единственный сервис - nginx. Например:
# yum install nginx |
Именно он хорошо и эффективно может выполнять роль балансировщика (а именно - для этих целей используется модуль ngx_http_upstream).
Если балансировка будет осуществляться средствами nginx, то в "Скалакси" можно использовать только один реальный (внешний) IP. Он должен быть привязан к серверу-балансировщику. А все обращения к нодам кластера будут осуществляться по внутренним адресам.
В простейшем примере конфигурационный файл nginx /etc/nginx/nginx.conf (помимо стандартных директив, определяющих, например, пути и формат log-файлов и т.п.) может быть таким:
http {
upstream backend {
ip_hash;
server www1.local;
server www2.local;
}
server {
listen 80;
server_name load_balancer;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host:80;
proxy_pass http://backend;
}
}
}
|
В секции "upstream" задаются адреса серверов, между которыми будет распределяться нагрузка.
В DNS имя сайта указывается на тот IP, на котором работает сервер с nginx, распределяющем нагрузку.
Обратите внимание: мы указали директиву ip_hash. Она означает, что распределение между серверами будет основано на IP-адресах посетителей. Это будет гарантировать то, что все обращения от одного клиента будут попадать на один и тот же сервер.
Чем это может быть полезно? Например, тем, что в такой конфигурации можно отключить хранение сессий в базе (мы включили эту опцию при балансировании нагрузки с помощью DNS) и тем самым - снизить нагрузку на базу.
Итог
Мы с вами запустили наш веб-сайт на кластере из двух машин.
Что дает нам это на практике? Кластер только ради самого кластера не очень интересен. Важно понимать, какие практические задачи мы можем решить...
1. Хоть мы и собрали наш кластер только из двух машин, на самом деле мы научились "горизонтально" масштабировать наш проект на любое количество серверов.
В Scalaxy есть возможность "вертикального" масштабирования виртуальной машины до 64 слотов (32 Гб оперативной памяти), но и этого может оказаться мало для крупного серьезного проекта.
Если возможности "вертикального" масштабирования себя исчерпали, мы теперь можно просто добавлять к проекту нужное нам количество новых серверов. При чем можем размещать на них именно те ресурсы которые нам нужны: становится "узким" местом работа с базой - добавляем сервер под MySQL, не хватает application server'ов - добавляем машины под Apache+PHP. Необязательно на каждой машине дублировать всю конфигурацию.
2. Мы свели к минимуму вероятность (и время) простоя нашего сайта из-за какого-либо сбоя.
Если выходит из строя одна (или несколько) машин веб-кластера, все продолжает работать на оставшихся работающих серверах.
Некоторым "узким" местом остается выход из строя узла, на котором запущен master MySQL. В этом случае потребуется вручную перевести один из slave'ов в режим master и изменить параметры подключения к базе в файле dbconn.php. Однако даже в этом случае время "простоя" проекта будет сведено к минимуму (все операции можно выполнить в считанные минуты, что на порядки быстрее, например, восстановления из бэкапа). И даже эти операции можно автоматизировать (об этом постараемся подробнее написать в одном из следующих постов).
3. Любой толковый системный администратор знает, насколько важно регулярно создавать резервные копии всех данных. При этом важно помнить о массе нюансов: бэкапы должны быть максимально "свежими" (никому не хочется потерять результаты работы даже за несколько часов, например, если речь идет о заказах в интернет-магазине); резервные копии файлов и базы должны быть "синхроннными" и т.п.
В веб-кластере мы можем добавить в конфигурацию еще одну машину (достаточно слабой конфигурации) - бэкап-сервер. Реплицировать на него все данные (файлы, базу) так же, как на другие машины кластера. Но не включать его при этом в балансировку нагрузки.
Таким образом мы получим максимально актуальный бэкап всего веб-проекта.
* * *
Резюмируя, скажу еще об одной важной особенности веб-кластера "1С-Битрикс".
В нашем примере мы построили надежную производительную кластерную систему без использования дорогостоящих решений типа Oracle RAC (Real Application Cluster). Наше решение получилось дешевым за счет использования свободного ПО (Apache, PHP, MySQL), но при этом - эффективным. И, что не менее важно, вся конфигурация веб-системы получилась достаточно простой, и ее администрирование не требует специальных узкоспециализированных навыков.
Александр, спасибо за подробное описание.
В очередной раз убедился что платформу правильно выбрал
Чтобы "завести сайт", хватит нормального хостинга за 300 рублей. Или вирт. машины/VPS с 512 Мб RAM (для вполне комфортной работы, а минимум - 256).
А вот когда вам понадобится отказоустойчивость и производительность под миллионы хитов - пожалуйста, вот поддержка кластера "прямо из коробки".
Как будет после этого происходить синхронизация?
Используется ли репликация в memcached ?
Если упадет master, потребуется некоторое количество ручных операций (в посте все описано).
Репликация в memcached... А зачем? В memcached у нас хранятся не критичные (возобновляемые) данные. Дублировать их между разными серверами memcached нет необходимости. Лучше использовать весь объем доступной (суммарной) памяти на всех серверах.
Да хотя бы для сессий, зареплицировал два memcache на разных серверах, и у вас теряющиеся в случае падения одного из серверов сессии. Чтобы у посетителя не складывалось впечатление - "Ложечки нашлись, но осадок остался".
2. Сейчас пока сессии хранятся или на файловой системе, или в базе. Не в memcached. Там - только кэш.
Все же это вторая важная составляющая веб-кластера, если не ошибаюсь
Когда собирали тестовый кластер, получали примерно в 1.5 раза бОльшую суммарную производительность при добавлении аналогичного сервера.
В планах - сделать полноценные нагрузочные тесты. Как будут готовы, цифры обязательно покажем.
1. Удобство добавления хостов. Что мы делаем со схемой ssh+rsync, если у нас становится 3, 5, N машин?
2. Больше гибкости при разрешении конфликтов (изменение одних и тех же файлов на разных нодах).
3. Актуализация данных при удалении файлов/директорий.
=========================
#!/bin/sh
USER=sync1c
DIR="/var/www/bitrix"
EXCLUDE="cache/"
HOSTS=" host1 host2 host3 "
LOG="/tmp/log.sync"
MAIL=main@email.me
KEY="/etc/cluster.key"
rm $LOG
for HOST in $HOSTS; do
rsync --exclude=$EXCLUDE -avuzt -e "ssh -i $KEY" $DIR $USER@$HOST:$DIR 2>$LOG
done
if [ -s "$LOG" ]; then
cat $LOG | mail -s "AHTUNG!!!" $MAIL
fi
==========================
2. Решение конфликтов как-то не видно - просто перезаписывается файл последним
rsync -u = csync2 auto younger
3. Не очень понял, что имелось в виду...
Такой скрипт так же в кроне повесить, делать будет тоже самое но без sqllite и остального + еще и емайл будет приходить, если что накрылось...
ИМХО не претендует на решение, просто не понял зачем так сложно было с установкой rpm'ок и зависимости такие тянуть за собой для простой задачи...
Хотя спасибо, буду знать что есть csync, для расширения кругозора.
3. Если мы удаляем файл на одном из хостов, как реплицировать эти изменения на остальные ноды?
disable=yes в конфигах /etc/xinetd.d/csync2 нужно закоментировать на всех нодах, иначе мастер не может отдать файлы слейвам, т.к. они попросту выключены.
Спасибо за замечание.
Теперь yum install -y csync2. И не надо руками качать пакеты.Вопрос, как в 6 ставить, оно есть где-то штатно? Нет под рукой 6...
Подскажите в чем может быть проблема, на обеих нодах говорит, что нет прав
ERROR from peer local2.server.ru: Permission denied!
и так обе, каких прав не хватает, где это настроить?