Как Вы уже увидели на рисунке, имеется сегмент локальной сети 192.168.224.0 и кроссовер 192.168.24.0. IP серверов, смотрящие в локальный сегмент 192.168.224.12 и 192.168.224.14. И самое интересное то, что Вы заметили виртуальный IP 192.168.224.13.
Что это такое? Это интересное решение, которое будет решать проблему общего IP для нескольких серверов посредством CARP…

1. Настройка виртуального IP.
Для включение CARP нам понадобится пересобрать наше ядро с псевдо-дивайзом carp:
kernel config



......... 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 carp0 vhid 1 pass password 192.168.224.13/24 advskew 0

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


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

Поясняю только то, что Вам придётся изменить:
password – это секретное слово вроде пароля (можете вставить своё)
192.168.224.13 – это наш виртуальный ip (который будет переходить от одной машины к другой, как переходящее знамя, во время аварии ведущей машины посредством протокола arp)
Больше Вам ничего не придётся менять, но могу пояснить, что carp0 это псевдо-дивайc, 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

На обеих машинах единственное различие то, что на ведущей 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 конфига, которые можно скачать прямо отсюда и поправить строки под себя:


Скрипты мною поправлены, скачать и поправить под себя! файл скачан размер размещён примечание 764 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 - в целом работает пока надёжно, между машинами было пару переключений и они уже по несколько раз менялись ролями, а  юзверы при этом ничего не заметили!

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

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