В принципе, после этого контейнер уже можно запускать, но для лучшей совместимости с LXC необходимо содержимое доработать. Как пример, я использовал шаблон для создания контейнера centos (/usr/share/lxc/templates/lxc-centos), а именно содержание функций configure_centos и configure_centos_init с небольшой доработкой. Особое внимание обратите на создание скрипта etc/init/power-status-changed.conf , без него контейнер не сможет корректно завершать работу. Либо inittab контейнера должен содержать правило вида: "p0::powerfail:/sbin/init 0" (зависит от дистрибутива).

/etc/init/power-status-changed.conf

# power-status-changed - shutdown on SIGPWR
#
start on power-status-changed

Exec /sbin/shutdown -h now «SIGPWR received»

/etc/init/start-ttys.conf

#
# This service starts the configured number of gettys.
#

# please create a file start-ttys.override and put your changes there.

Env ACTIVE_CONSOLES=/dev/tty
env X_TTY=/dev/tty1
task
script
. /etc/sysconfig/init
for tty in $(echo $ACTIVE_CONSOLES); do
[ "$RUNLEVEL" = «5» -a "$tty" = "$X_TTY" ] && continue
initctl start tty TTY=$tty
done
end script

/etc/init/console.conf

# console - getty
#
# This service maintains a getty on the console from the point the system is
# started until it is shut down again.

Start on stopped rc RUNLEVEL=
stop on runlevel [!2345]
env container

Respawn
#exec /sbin/mingetty --nohangup --noclear /dev/console
exec /sbin/agetty -8 38400 /dev/console

/etc/init/tty.conf

# tty - getty
#
# This service maintains a getty on the specified device.
#
# Do not edit this file directly. If you want to change the behaviour,
# please create a file tty.override and put your changes there.

Stop on runlevel

Respawn
instance $TTY
#exec /sbin/mingetty --nohangup $TTY
exec /sbin/agetty -8 38400 $TTY
usage "tty TTY=/dev/ttyX - where X is console id"

Я пробовал использовать mingetty в перенесённом контейнере с CentOS 6.6, но он отказался работать с ошибкой в логах:
# /sbin/mingetty --nohangup /dev/console console: no controlling tty: Operation not permitted

С LXC можно работать через libvrt , используя драйвер lxc:/// , но этот способ опасен и RedHat грозится удалить его поддержку из дистрибутива.
Для управлением через libvrt в Pacemaker-е существует ресурс-скрипт ocf:heartbeat:VirtualDomain , который может управлять любой VM, в зависимости от драйвера. Возможности включают в себя и живую миграцию для KVM. Думаю, использование Pacemaker-а для управления KVM, будет аналогичным, но мне это не было нужным.

Работа с Docker-ом в кластере

Запускаем docker-storage-setup:
# docker-storage-setup Rounding up size to full physical extent 716.00 MiB Logical volume "docker-poolmeta" created. Logical volume "docker-pool" created. WARNING: Converting logical volume shared_vg-ex/docker-pool and shared_vg-ex/docker-poolmeta to pools data and metadata volumes. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Converted shared_vg-ex/docker-pool to thin pool. Logical volume "docker-pool" changed. # lvs | grep docker-pool docker-pool shared_vg-ex twi-aot--- 17.98g 14.41 2.54
Docker использует разреженный том (thin provisioned), это накладывает ограничение на использование в кластере. Такой том не может быть активным на нескольких узлах одновременно. Настроим LVM так, чтобы тома в группе shared_vg-ex не активировалась автоматически. Для этого необходимо явно указать группы (или тома по отдельности) которые будут активироваться автоматически в файле /etc/lvm/lvm.conf (на всех узлах):
auto_activation_volume_list = [ "shared_vg" ]
Передадим управление этим томом Pacemaker-у:
# pcs resource create lvm-docker-pool LVM volgrpname=shared_vg-ex exclusive=yes # pcs constraint order start clvmd-clone then lvm-docker-pool # pcs constraint colocation add lvm-docker-pool with clvmd-clone Теперь тома группы shared_vg-ex будут активироваться на том узле, где запущен ресурс lvm-docker-pool .

Docker будет использовать для NAT-а контейнеров из внешней сети выделенный IP. Зафиксируем его в конфигурации:
# cat /etc/sysconfig/docker-network DOCKER_NETWORK_OPTIONS="--ip=10.1.2.10 -fixed-cidr=172.17.0.0/16" Отдельный мост настраивать не будем, пусть использует по умолчанию docker0 , только зафиксируем сеть для контейнеров. Я пробовал указывать мне удобную сеть для контейнеров, но наткнулся на какие-то не внятные ошибки. Гугл подсказал, что не я один, по этому удовлетворился просто зафиксировав сеть, которую Docker сам себе выбрал. Docker так же не останавливает мост при своём выключении и не убирает ip-адрес, но так как мост не соединён ни с одним физическим интерфейсом, то это не проблема. В других конфигурациях это надо учитывать.

Чтобы Docker ходил в интернет через прокси-сервер, настроим ему переменные окружения. Для этого создаём директорию и файл /etc/systemd/system/docker.service.d/http-proxy.conf с содержанием:
Environment="http_proxy=http://ip_proxy:port" "https_proxy=http://ip_proxy:port" "NO_PROXY=localhost,127.0.0.0/8,dregistry"

Базовая настройка завершена, будем наполнять кластер соответствующими ресурсами. Так как за Docker будет отвечать набор ресурсов, то удобно их собрать в группу. Все ресурсы группы запускаются на одном узле и запускаются последовательно, согласно порядку в группе. Но нужно учитывать, что при сбое одного из ресурсов группы, вся группа соберётся мигрировать на другой узел. А так же, при выключении какого-либо ресурса группы, все последующие ресурсы тоже выключатся. Первым ресурсом группы будет созданный LVM том:
# pcs resource group add docker lvm-docker-pool
Создаём ресурс - IP адрес, выданный Docker-у:
# pcs resource create dockerIP IPaddr2 --group docker --after lvm-docker-pool ip=10.1.2.10 cidr_netmask=24 nic=br0.12
Кроме LVM тома Docker так же использует файловую систему для хранения своих данных. По этому нужно завести ещё один раздел под управлением Pacemaker-а. Так как эти данные нужны только работающему Dokcer-у, то и ресурс будет обычным.
# lvcreate -L 500M -n docker-db shared_vg # mkfs.xfs /dev/shared_vg/docker-db # pcs resource create fs-docker-db Filesystem fstype=xfs device=/dev/shared_vg/docker-db directory=/var/lib/docker --group docker --after dockerIP
Теперь можно добавлять сам Docker-демон:
# pcs resource create dockerd systemd:docker --group docker --after fs-docker-db
После успешного запуска ресурсов группы, на узле, где поселился Docker смотрим его статус и убеждаемся, что всё хорошо.

docker info:

# docker info Containers: 5 Images: 42 Storage Driver: devicemapper Pool Name: shared_vg--ex-docker--pool Pool Blocksize: 524.3 kB Backing Filesystem: xfs Data file: Metadata file: Data Space Used: 2.781 GB Data Space Total: 19.3 GB Data Space Available: 16.52 GB Metadata Space Used: 852 kB Metadata Space Total: 33.55 MB Metadata Space Available: 32.7 MB Udev Sync Supported: true Library Version: 1.02.93-RHEL7 (2015-01-28) Execution Driver: native-0.2 Kernel Version: 3.10.0-229.7.2.el7.x86_64 Operating System: CentOS Linux 7 (Core) CPUs: 4 Total Memory: 3.703 GiB Name: cluster-2

Можно уже работать с Docker-ом в обычном порядке. Но для полноты картины, заведём и поселим в наш кластер Docker-реестр. Для реестра будем использовать отдельный IP и имя 10.1.2.11 (dregistry), а файловое хранилище образов вынесем в отдельный раздел.
# lvcreate -L 10G -n docker-registry shared_vg # mkfs.ext4 /dev/shared_vg/docker-registry # mkdir /mnt/docker-registry # pcs resource create docker-registry Filesystem fstype=ext4 device=/dev/shared_vg/docker-registry directory=/mnt/docker-registry --group=docker –after=dockerd # pcs resource create registryIP IPaddr2 --group docker --after docker-registry ip=10.1.2.11 cidr_netmask=24 nic=br0.12
Создаём контейнер-реестр на узле, где запущен Docker:
# docker create -p 10.1.2.11:80:5000 -e REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/var/lib/registry -v /mnt/docker-registry:/var/lib/registry -h dregistry --name=dregistry registry:2 Задаём проброс порта в контейнер (10.1.2.11:80 → 5000). Подключаемую директорию /mnt/docker-registry . Имя хоста и имя контейнера.
Вывод docker ps -a покажет созданный контейнер, готовый к запуску.

Отдадим управление им Pacemaker-у. Для начала скачиваем свежий ресурс-скрипт:
# wget -O /usr/lib/ocf/resource.d/heartbeat/docker https://raw.githubusercontent.com/ClusterLabs/resource-agents/master/heartbeat/docker # chmod +x /usr/lib/ocf/resource.d/heartbeat/docker
Важно следить за идентичностью ресурс-скриптов на всех узлах, а то могут быть неожиданности. Ресурс-скрипт «docker» сам умеет создавать требуемые контейнера с заданными параметрами, скачивая их из реестра. По этому можно просто использовать постоянно запущенные Docker-а на узлах кластера с общим реестром и личными хранилищами. А Pacemaker-ом только контролировать отдельные контейнера, но это не так интересно, да и избыточно. Я и с одним то Docker-ом ещё не придумал, что делать.
Итак, передадим управление готовым контейнером Pacemaker-у.
# pcs resource create dregistry docker reuse=true image="docker.io/registry:2" --group docker --after registryIP reuse=true – важный параметр, иначе контейнер будет удалён после остановки. image необходимо указать полные координаты контейнера, включая реестр и тэг. Ресурс-скрипт подхватит готовый контейнер по имени dregistry и запустит.
Пропишем наш локальный реестр в конфигурацию Docker-а на узлах кластера (/etc/sysconfig/docker).
ADD_REGISTRY="--add-registry dregistry" INSECURE_REGISTRY="--insecure-registry dregistry" HTTPS нам не нужен, потому отключаем для локального реестра.

После этого перезапускаем службу Docker-а systemctl restart docker на узле, где он живёт или pcs resource restart dockerd на любом узле кластера. И можем пользоваться возможностями нашего личного реестра по адресу 10.1.2.11 (dregistry).

Теперь на примере Docker-контейнеров я покажу, как работать с шаблонами в Pacemaker-е. К сожалению, возможности утилиты pcs тут сильно ограничены. Шаблоны как таковые она не умеет вообще, а для constraint позволяет создать некоторые объединения, но работать с ними через pcs не удобно. Благо, на помощь приходит возможность править конфигурацию кластера на прямую в xml файле:
# pcs cluster cib > /tmp/cluster.xml # правим, что нужно # pcs cluster cib-push /tmp/cluster.xml

Docker-ресурсы должны отвечать следующим требованиям:

• находится на одном узле с ресурсами группы docker
• запускаться после всех ресурсов группы docker
• контейнера должны быть не зависимы от статуса друг друга

Для начала создадим три подопытных контейнера, в качестве которых я использовал контейнер с Nginx-ом. Контейнер предварительно скачивается и выкладывается в локальный реестр:
# docker pull nginx:latest # docker push nginx:latest # pcs resource create doc-test3 docker reuse=false image="dregistry/nginx:latest" --disabled # pcs resource create doc-test2 docker reuse=true image="dregistry/nginx:latest" --disabled # pcs resource create doc-test docker reuse=true image="dregistry/nginx:latest" --disabled Ресурсы создаются выключенными, иначе они попробуют запустится и тут как повезёт с узлом.

В свежевыгруженный xml добавляем объединение ресурсов. Определяющее совместное расположение (секция):
Здесь заводится общее объединение (colocation set , id="docker-col" ) с требованием совместного проживания на одном узле ( score="INFINITY" ). Первое объединение ресурсов ( id="docker-col-0" ) со свойствами:

• одновременный запуск ресурсов ( sequential="false" )
• не зависимость ресурсов от статуса друг друга ( require-all="false" )
• роль ресурсов ( role="Started" )

Ordering set , определяющий порядок запуска ресурсов:
Здесь прозрачнее, сначала запускаем ресурсы группы docker , затем скопом и не зависимо все контейнера.

После загрузки изменённой конфигурации, контейнера можно безбоязненно включать/выключать и удалять. Это не повлияет на работу других ресурсов. Но требование совместного расположение заставит переместится на другой узел кластера все связанные ресурсы, в случае переноса какого-либо ресурса. В выводе pcs эти настройки выглядят следующим образом:
# pcs constraint --full | grep -i set Resource Sets: set docker (id:order_doc-0) set doc-test doc-test2 doc-test3 sequential=false require-all=false (id:order_doc-1) (id:order_doc) Resource Sets: set doc-test doc-test2 doc-test3 role=Started sequential=false require-all=false (id:docker-col-0) set docker (id:docker-col-1) setoptions score=INFINITY (id:docker-col)

Работа с шаблонами ресурсов осуществляется сходным образом. Создадим шаблон для LXC контейнера (в секции):

В котором пропишем основные параметры ресурса. И перепишем настройки ресурса на использование этого шаблона:

После обновления конфигурации вывод свойств ресурса стал совсем короток:
# pcs resource show lxc-racktables Resource: lxc-racktables (template=lxc-template) Attributes: container=lxc-racktables config=/var/lib/lxc/lxc-racktables/config
Правда создавать новые ресурсы средствами pcs с использованием шаблонов пока не получится.
Осталось зафиксировать порядок запуска контейнеров LXC аналогичным объединением, как с Docker-ом.

Для управления Pacemaker-ом можно поставить пакет crmsh из репозитория

, Децентрализованные сети

Хочу рассказать вам еще об одном способе балансировки нагрузки. Про Pacemaker и IPaddr (ресурс-агент) и настройке его для Active/Passive кластера сказано уже и так достаточно много, но информации по организации полноценного Active/Active кластера, используя этот модуль я нашел крайне мало. Постараюсь исправить эту ситуацию.

Для начала расскажу подробнее чем такой метод балансировки примечателен:

• Отсутсвие внешнего балансировщика - На всех нодах в кластере настраивается один общий виртуальный IP-адрес. Все запросы отправляются на него. Ноды отвечают на запросы на этот адрес случайно и по договоренности между ссобой.
• Высокая доступность - Если одна нода падает ее обязаности подхватывает другая.
• Простота настройки - Настройка осуществляется всего в 3-5 команд.

Вводные данные

Давайте посмотрим на картинку в начале статьи, мы увидим следующие устройства:

• Gateway - IP: 192.168.100.1
• HostA - IP: 192.168.100.101
• HostB - IP: 192.168.100.102
• HostC - IP: 192.168.100.103

Клиенты будут обращаться на внешний адрес нашего шлюза, тот будет перенаправлять все запросы на виртуальный IP 192.168.100.100, который будет настроен на всех трех нодах нашего кластера.

Подготовка

Для начала нам нужно убедиться в том, что все наши ноды могут обращаться друг к другу по single hostname, для надежности лучше сразу добавить адреса нод в /etc/hosts:

Установим все необходимые пакеты:

При установке pcs создает пользователя hacluster , давайте зададим ему пароль:

Создаём и запускаем кластер “Cluster” из трех узлов:

Смотрим результат:

Вывод

Cluster Status: Last updated: Thu Jan 19 12:11:49 2017 Last change: Tue Jan 17 21:19:05 2017 by hacluster via crmd on hostA Stack: corosync Current DC: hostA (version 1.1.14-70404b0) - partition with quorum 3 nodes and 0 resources configured Online: [ hostA hostB hostC ] PCSD Status: hostA: Online hostB: Online hostC: Online

Некоторые шаги были позаимствованы из статьи Lelik13a , спасибо ему за это.

В нашем конкретном случае ни кворум ни stonith нашему кластеру не требуется, так что смело отключаем и то и другое:

В дальнейшем, если у вас появятся ресурсы для которых это необходимо, вы можете обратиться к статье Silvar .

Пара слов о MAC-адресах

Прежде чем мы приступим, нам нужно понимать что на всех наших нодах будет настроен одинаковый IP и одинаковый mac-адрес, по запросу на который они будут поочередно давать ответы.

Проблема в том, что каждый коммутатор работает таким образом, что во время работы он составляет свою таблицу коммутации, в которой каждый mac-адрес связывается с определенным физическим портом. Таблица коммутации составляется автоматически, и служит для разгрузки сети от "ненужных" L2-пакетов.

Так вот, если mac-адрес есть в таблице коммутации, то пакеты будут отправляться только в один порт за которым и закреплен этот самый mac-адрес.

К сожалению, нам это не подходит и нам необходимо удостовериться в том, что бы все наши хосты в кластере одновременно "видели" все эти пакеты. В противном случае эта схема работать не будет.

Для начала нам нужно удостовериться в том, что используемый нами mac-адрес является multicast -адресом. То есть находится в диапазоне 01:00:5E:00:00:00 - 01:00:5E:7F:FF:FF . Получив пакет для такого адреса наш коммутатор будет передавать его во все остальные порты, кроме порта источника. Кроме того, некоторые управляемые коммутаторы позволяют настроить и определить несколько портов для конткретного MAC-адреса.

Также вам вероятно придется отключить функцию Dynamic ARP Inspection , если она поддерживается вашим коммутатором, так как она может стать причиной блокировки arp-ответов от ваших хостов.

Настройка IPaddr-ресурса

Вот мы и добрались до самого интересного.

На данный момент существует две версии IPaddr с поддержкой клонирования:

IPaddr2 (ocf:heartbeat:IPaddr2) - Стандартный ресурс-агент для создания и работы виртуального IP-адреса. Как правило устанавливается вместе со стандартным пакетом resource-agents .

• IPaddr3 (ocf:percona:IPaddr3) - Улучшенная версия IPaddr2 от Percona.
  В эту версию включены исправления ориентированные на работу именно в режиме clone.
  Требуется отдельная установка.

Для установки IPaadr3 выполните эти команды на каждом хосте:

Создадим ресурс для нашего виртуального IP-адреса:

clusterip_hash - здесь нужно указать желаемый тип распределения запросов.
Всего может быть три варианта:

• sourceip - распределение только по IP-адресу источника, это гарантирует что все запросы от одного источника всегда будут попадать на один и тот же хост.
• sourceip-sourceport - распределение по IP-адресу источника и исходящему порту. Каждое новое соединение будет попадать на новый хост. Оптимальный вариант.
• sourceip-sourceport-destport - распределение по IP-адресу источника исходящему порту и порту назначения. Обеспечивает наилучшее распределение, актуально если у вас работает несколько сервисов на разных портах.

Для IPaddr2 обязательно нужно указать параметр mac=01:00:5E:XX:XX:XX с mac-адресом из multicast-диапазона. IPaddr3 устанавливает его автоматически.

Теперь склонируем наш ресурс:

Это действие создаст следующее правило в iptables:

Как вы можете заметить, здесь используется модуль CLUSTERIP .

Работает он следующим образом:

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

Подробнее об этом написанно в этой