.........

device carp # поддержка carp

.........

И выставить нужные опции sysctl:

# sysctl net.inet.carp.arpbalance=1

А также поправить конфиг sysctl.conf:

echo "net.inet.carp.arpbalance=1" >> /etc/sysctl.conf

И всё это нужно сделать на обеих машинах!

Теперь рисуем два скрипта - по одному для каждой машины,например для первой cl0, и кладём по адресу со следующим названием:
/usr/local/etc/rc.d/ucarp.up.sh

#!/bin/sh ifconfig carp0 create ifconfig carp1 create ifconfig carp0 vhid 1 pass password 192.168.224.13/24 advskew 0 ifconfig carp1 vhid 2 pass password 192.168.224.13/24 advskew 100

А для второй машины cl1 с таким же название и по такому же пути рисуем вот такой скрипт:

#!/bin/sh ifconfig carp0 create ifconfig carp1 create ifconfig carp0 vhid 1 pass password 192.168.224.13/24 advskew 100 ifconfig carp1 vhid 2 pass password 192.168.224.13/24 advskew 0

Поясняю только то, что Вам придётся изменить:
password – это секретное слово вроде пароля (можете вставить своё)
192.168.224.13 – это наш виртуальный ip (который будет переходить от одной машины к другой, как переходящее знамя, во время аварии ведущей машины посредством протокола arp)
Больше Вам ничего не придётся менять, но могу пояснить, что carp0 и carp1 - это псевдо-дивайзы, advskew –  это приоритеты, но они в данной ситуации настроены симметрично…

Выставляем правильные права доступа на оба скрипта:

chmod 755 /usr/local/etc/rc.d/ucarp.up.sh

Теперь можно либо запустить эти скрипты, либо сделать перезагрузку, и мы увидим следующее, выполнив команду ifconfig:

.......... carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.168.224.13 netmask 0xffffff00 carp: MASTER vhid 1 advbase 1 advskew 100 carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.168.224.13 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 0

На обеих машинах единственное различие то, что на ведущей MASTER пометка, а на ведомойBECKUP, если мы MASTER отправим в перезагрузку или выключим вообще, то BACKUPавтоматически через секунду станет MASTER! И когда бывший MASTER вновь загрузится, то он уже будет BECKUP! Можете проверить, работает ли это, к примеру, по ssh подключиться к своему виртуальному IP (в моём случае 192.168.224.13), а затем отправить MASTER в перезагрузку и вновь подключиться к этому IP, то мы уже должны будем подключиться ко второй машине, которая только что была BECKUP.

2. Настройка репликации данных посредством HAST.
Рисуем два одинаковых конфига /etc/hast.conf на обеих машинах следующего вида:

resource clfox { on cl0 { local /dev/ad6 remote 192.168.24.20 } on cl1 { local /dev/ad6 remote 192.168.24.10 } }

Поясняю:
сlfox – это  вымышленное мною слово, можете подставить любое своё (что-то вроде названия ресурса)
cl0 и cl1 – это hostname первой и второй машины (разумеется, у Вас свои имена)
local /dev/ad6 – это и есть путь к дополнительному харду, который я выбрал в роли ресурса для репликации.
remote – здесь мы указываем IP-адрес противоположной машины (для обмена трафика репликации мы будем использовать кроссовер).

Теперь делаем на обеих машинах вот такие нехитрые манипуляции:

#hastctl create clfox

Где clfox, как мы уже договорились, имя ресурса.
Затем добавляем необходимые строки в rc.conf:

#echo 'hastd_enable="YES"' >> /etc/rc.conf

И запускаем демона:

#/etc/rc.d/hastd start

Выполнив команду на обеих машинах:

#hastctl status

Мы увидим следующее:

clfox: role: init provname: clfox localpath: /dev/ad6 extentsize: 0 keepdirty: 0 remoteaddr: 192.168.24.20 replication: memsync dirty: 0 bytes

Всё должно быть идентичное на обеих машинах, кроме строки "remoteaddr:" на каждой машине будет указан противоположный адрес.
Теперь раздадим роли, пока вручную, чтобы проверить и задействовать файловую систему.
На той машине, где carp – дивайзы MASTER, мы присвоим роль primary, то есть ведущий!
Для этого сделаем: 

#hastctl role primary clfox

И увидим:

#hastctl status clfox: role: primary provname: clfox localpath: /dev/ad6 extentsize: 0 keepdirty: 0 remoteaddr: 192.168.24.20 replication: memsync dirty: 0 bytes

А на ведомой машине назначим роль secondary:

#hastctl role secondary clfox

И увидим примерно следующее:

#hastctl status clfox: role: secondary provname: clfox localpath: /dev/ad6 extentsize: 2097152 keepdirty: 64 remoteaddr: 192.168.24.10 replication: memsync status: complete dirty: 0 bytes

Главное, чтобы на ведущем сервере строка "status:" стала в режим "complete", если не стала, то нужно разобраться в чём дело, иначе дальше двигаться нельзя!!!

3. ZFS в роли файловой системы.
Итак, теперь у нас появился девайз на primary машине:

#ls /dev/hast/ clfox

Я выбрал ZFS - с ней проще хотя бы по той причине, что не придётся пользоваться чеколкой fsck, и ZFS более гибок в настройках в дальнейшем!
Создаём точку монтирования на обеих машинах:

#mkdir /usr/hastfs

Вы можете свою точку создать со своим названием - таким же именем назвать не принципиально!
Создадим пул на ведущей машине:

#zpool create -m /usr/hastfs zfox /dev/hast/clfox

Проверяем:

#zpool status pool: zfox state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zfox ONLINE 0 0 0 hast/clfox ONLINE 0 0 0

Если пул появился, можно добавить на своё усмотрение дополнительные опции или разбить на дата-сетинги или ещё что-либо сделать с ZFS, к примеру я добавил пару опций:

#zfs set checksum=fletcher4 zfox

Это контрольные суммы.
И:

#zfs set atime=off zfox

Это тоже не помешает в моём случае.
Теоретически репликация уже работает, если мы проверим командой:

#hastctl status

И увидим, что параметр status будет complete!
Можно даже не испытывать, отправив MASTER в перезагрузку, а secondary поставить вprimary, затем сделать на новоиспечённом MASTERE 

#zpool import –f clfox

Всё это можно сделать из любопытства, но если статус complete! тогда я уверен, что проблем нет, и не стоит тратить время!

4. Автоматизируем наш кластер.
Для того, чтобы заставить это всё хозяйство работать автоматически, я много размышлял: вначале я думал написать свой скрипт, но потом я понял, что нужно учесть много НО, а времени в обрез… Готовый вариант в инете мне не понравился - он вообще кривой до ужаса. Поэтому я сделал оптимально-минимальную свою сборную солянку. За основу был взят демон из портов ucarp, скрипты из  /usr/share/examples/hast/ плюс свои корректировки. И вот, что получилось (правда я нашёл минимум два существенных бага, о них расскажу далее…)
Обновляем порты, а затем идём по пути:

#cd /usr/ports/net/ucarp

И устанавливаем порт, зависимостей он за собой не тянет, в чём его и прелесть, в отличии от Heartbeat!

#make install clean

Далее...
Создаём директорию на обеих машинах:

#mkdir -p /usr/local/etc/ucarp

Заливаем сюда 4 конфига, которые можно скачать прямо отсюда и поправить строки под себя:

Скрипты мною поправлены, скачать и поправить под себя! файл скачан размер размещён примечание 2 8.5kb 2011-02-18 ucarp_my_scripts

В файле ucarp_up.sh нужно поправить следующие строки:

# Resource name as defined in /etc/hast.conf. resource="clfox" #Имя ресурса hast, то что мы вводили в hast.conf # Supported file system types: UFS, ZFS fstype="ZFS" #Тип файловой системы в моём случае это ZFS! # ZFS pool name. Required only when fstype == ZFS. pool="zfox" #Имя пула ZFS # File system mount point. Required only when fstype == UFS. mountpoint="/usr/hastfs" #И точка монтирования пула

И аналогично правим файл ucarp_down.sh:

# Resource name as defined in /etc/hast.conf. resource="clfox" #Имя ресурса hast, то что мы вводили в hast.conf # Supported file system types: UFS, ZFS fstype="ZFS" #Тип файловой системы в моём случае это ZFS! # ZFS pool name. Required only when fstype == ZFS. pool="zfox" #Имя пула ZFS # File system mount point. Required only when fstype == UFS. mountpoint="/usr/hastfs" #И точка монтирования пула

Это мы проделываем на обеих машинах и придаём нужные права файлам:

#chmod -R 755 /usr/local/etc/ucarp/*

Добавляем строки в rc.conf, на обеих машинах:
На cl0:

zfs_enable="YES" ucarp_enable="YES" ucarp_addr="192.168.224.13" #Виртуальный IP ucarp_if="rl0" #Интерфейс куда смотрит виртуальный IP ucarp_src="192.168.224.12" # Реальный IP ucarp_pass="password" #Наше секретное слово для псевдо-девайзов carp ucarp_upscript="/usr/local/etc/ucarp/vip-up.sh" ucarp_downscript="/usr/local/etc/ucarp/vip-down.sh"

На cl1:


zfs_enable="YES" ucarp_enable="YES" ucarp_addr="192.168.224.13" #Виртуальный IP ucarp_if="rl0" #Интерфейс куда смотрит виртуальный IP ucarp_src="192.168.224.14" # Реальный IP ucarp_pass="password" #Наше секретное слово для псевдо-девайзов carp ucarp_upscript="/usr/local/etc/ucarp/vip-up.sh" ucarp_downscript="/usr/local/etc/ucarp/vip-down.sh"

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

#/usr/local/etc/rc.d/ucarp start

Или

#shutdown -r now

Примечания!
- Может быть такое, что при старте статус будет не complete, тогда на secondary нужно сделать вот такие манипуляции:


#hastctl create clfox

Таким образом, мы заставим включиться в дело и начать синхронизацию ведомого ресурса!
Очень важно не перезагружать ни одну из машин до тех пор, пока не пройдёт синхронизация, свидетельство этого будет на машине primary в поле  dirty: стоять показатель 0 bytes, если же был какой-то диссонанс и мы вернули на путь истинный нашегоsecondary, то будет синхронизация и в поле dirty: будет обратный отсчёт байт!

- Ещё важно с какой машины стартовать, нужно всегда стартовать с primary, то есть та машина, которая была в последний раз primary, это на случай, если обе машины были остановлены в случае падения primary! Secondary автоматически станет primary и всё будет без проблем работать! Или если secondary упадёт и вновь поднимется, то это тоже всё безболезненно, опасность лишь в том, что если обе машины упали и потом их пришлось запустить, тогда придётся выяснять, кто был последним primary. Они могут стать обеprimary, что нужно проконтролировать, и если такое случилось, посмотреть в ручную, где новее информация. Машину с последней информацией оставить в primary, а вторую перевести в secondary командой:

#hastctl role secondary clfox

И, разумеется, удостовериться, что статус complete, если нет, то смотреть первый пункт примечаний!

Заключение:
Данная система очень удобна и надёжна, если не считать 2 серьёзных недостатка. Возможно, в будущем я напишу скрипт, который даст возможность максимальной автономии при минимальном вмешательстве администратора! Но там, где действительно требуетсяcluster, такая связка оправдывает себя. Я испытал такие службы, как apache,
squid, openvpn, mpd5, postfix, и даже samba - в целом работает пока надёжно, между машинами было пару переключений и они уже по несколько раз менялись ролями, а  юзверы при этом ничего не заметили!

Возможно, Вы сможете развить эту тему намного дальше и глубже, будет интересно обменяться опытом!

Спасибо за внимание! :-)