В качестве ОС для хост-систем сгодится любая популярная ОС на базе современных ядер Linux и GNU окружения. Однако в моём случае, данная схема была опробована только на Debian и Gentoo.
Не рекомендую использовать LVM, ибо ничего кроме overhead-ов в данной ситуации вы от этого не получите, IMHO. В качестве ФС, нами были опробованы BtrFS, XFS, Ceph и ext4, и лучше всего прижился ext4, хоть и в нём не хватает возможности устанавливать квоты по директориям, а не по uid-ам. BtrFS был плох тем, что при любой отладке связанной как-то с ФС мы в первую очередь винили его, что отнимало немало времени :). Однако мы планируем миграцию назад на BtrFS, когда он будет признан достаточно стабильным в свободном сообществе. А XFS был плох своей производительностью для наших use case-ов.
В качестве ОС для хост-систем применима любая популярная ОС на базе современных ядер Linux и GNU окружения. Однако данная схема была опробована нами только на базе Debian и Gentoo.
Мы использовали /opt для директорий реплицируемых скриптов, а /srv/lxc для контейнеров.
++ Репликация конфигураций хост-систем
Допустим, что вам необходимо делать большое множество vlan-ов для эффективной изоляции различных сервисов. В таких зачастую случаях возникают определённые неприятности, например:
Допустим, что необходимо большое множество vlan-ов для эффективной изоляции сервисов друг от друга. В таких ситуациях могут возникнуть определённые сложности, например:
** Долго загружается ОС, особенно Gentoo с "rc_parallel=yes" и hangup-ами (загружаться может часами).
** Огромные конфигурационные файлы, что постоянно вызывает ошибки по "человеческому фактору".
** Иногда нельзя синхронизировать конфигурационные файлы, так как необходимо использовать разные IP-адреса.
Данные проблемы можно решить используя [[https://gitlab.ut.mephi.ru/ut/ipw ipw]], вместо стандартных init.d-скриптов настройки сети.
Данные проблемы возможно решить используя [[https://gitlab.ut.mephi.ru/ut/ipw ipw]], вместо стандартных init.d-скриптов настройки сети.
Все приведённые далее команды необходимо выполнять на обоих рабочих узлах.
...
...
@@ -102,7 +100,7 @@ srv-1 — seth
ip addr add 10.0.5.2/24 dev control
ip addr route add default via 10.0.5.1 dev control
В рамках предложенной конфигурации csync2, файл /etc/ipw.conf будет синхронизироваться между узлами кластера, а /etc/ipw.conf.local не будет.
В рамках предложенной ниже конфигурации csync2, файл /etc/ipw.conf будет синхронизироваться между узлами кластера, а /etc/ipw.conf.local не будет.
Устанавливаем сам ipw.
...
...
@@ -168,7 +166,7 @@ srv-1 — seth
++ Окружение для работы с LXC
Для удобной работы с LXC в HA-кластерах наподобие предлагаемого в данной статье, вы можете использовать набор скриптов из репозитория [[https://github.com/mephi-ut/lxc-ha mephi-ut/lxc-ha на GitHub.com]]:
Для удобной работы с LXC в HA-кластерах имеется возможность использовать набор скриптов из репозитория [[https://github.com/mephi-ut/lxc-ha mephi-ut/lxc-ha на GitHub.com]]:
** Для дедупликации конфигураций осуществляется завязка на конфигурационный файл lxctl, который находится по пути «/etc/lxctl/lxctl.yaml». Если такой файл у вас отсутствует, то необходимо его создать и настроить. Пример настройки:
cat > /etc/lxctl/lxctl.yaml << EOF
...
...
@@ -208,7 +206,7 @@ srv-1 — seth
IFNAME: 'ip'
list:
COLUMNS: 'name,disk_free_mb,status,ip,hostname'
** Настройка ssh/sshd. Вы уже к этому моменту настроили csync2, что должно слегка упростить задачу:
** Настройка ssh/sshd. К этому моменту csync2 уже настроен и упрощает дальнейшую задачу: