Мы — долго запрягаем, быстро ездим, и сильно тормозим.
www.lissyara.su —> статьи —> FreeBSD —> настройка —> hast carp zfs ucarp cluster

hast cluster

Автор: fox.


                                         

HAST Cluster



      Я вас приветствую. Хотел бы поделится опытом настройки HAST в режиме сервер повышенной надёжности! Но на самом дели эта статья написана из эгоистических побуждений, чтобы не забыть, как я это делал на случай, если придётся вновь повторить что-нибудь подобное! :-)))

Пролог:
   Есть некая организация, которая содержит свой IT-отдел, и не понятно зачем он им нужен,если их по подряду по IT-вопросом обслуживает другая организация. У первой организации (клиенты) имеется свой мини-хостер для корпоративных нужд (они занимаются крупной торговлей и имеют кучу филиалов). И всё было хорошо до недавних времён, когда вдруг в неподходящий момент упал сервер с их веб-делами. Прозаичная ситуация - сдох блок питания. На устранение проблемы средствами их внутренней IT-службы ушло менее часа. В целом ничего криминального! Но начальник службы попал под горячую руку первых руководителей за то, что в самый неподходящий момент лежал веб-сервер, ну и получил нужный пистон. Вследствии этого было принято решение сделать минимум два машинных веб-сервера. Для решении данной проблемы они обратились к своим подрядчикам.  Вот тогда кураторы этого объекта обратились ко мне, поскольку я работаю в организации номер два (подрядчики) в роли консультанта по FreeBSD!
Меня спросили, можно ли такое сделать? Чтобы две машины работали взаимозаменяемыми с одной и той же службой для одной и той-же задачи? Я ответил, что это вполне реально… Так как речь шла о Веб-сервере, я вначале думал просто сделать связку MySQL Master+Master как и в ранней моей статье:
MySQL Master+Master
И одинаково настроить два апачя и использовать alias ip, управляемый скриптом из под cron, или поднять демона monit и заставить следить за первым сервером, и принимать нужные действия в случае краха!
Но задача обернулась несколько иным образом: детально ознакомившись с проблемой, я понял, что так просто мне не выкрутиться, потому что юзверами заливаются файлы по http, htpps, и ftp протоколу, и ко всему еще имеется поднятый кем-то другим почтовик на postfix с прилегающими службами. И тут я понял, что задача значительно усложняется! Первое, что пришло в голову, это применить rsync, однако это не лучший вариант - всё равно могут быть траблы. Нужно было что-то более элегантное и масштабное! Погуглив, я не нашёл ничего интересного, кроме rdbd + heartbeat, и то под линупсятинкой (как-то в лом)! Затем на меня навалилась куча проблем, которые не терпели отлагательства, и этот вопрос был задвинут на пару недель по причине того, что он мог терпеть ещё не один месяц, если надо! Пока не случилось чудо - я заболел))) И у меня появилось немного свободного времени…
   Как-то в промежутках времени я интернетил на замечательном ресурсе www.lissyara.su, и была у меня полемика на форуме на тему кластеры. Многие ссылались на hast, прочитал ман...
Я отметил, что идея неплохая, но ещё сырая и не отработанная…
Ну что ж, придётся разбираться, хотя вначале я к этому относился очень скептично...

Приступим:
   Имеется - два сервера (cl0 и cl1), для надёжности было на каждый добавлено по харду (ad6).
На обоих были идентичные материнки Gigabyte UD5, которые имели 2 сетевых интерфейса: один смотрит в сеть компании, а другой я решил задействовать с умом, объединив их в crossover. И вот получилась следующая схема:



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

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

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



размещено: 2011-02-16,
последнее обновление: 2011-03-10,
автор: fox


alik1c, 2011-02-19 в 12:56:30

Пробовал как-то CARP, но дальше развить все это времени не хватало. Думаю, статья заслуживает высокой оценки, молодец.
Как раз завтра начну почту таким методом дублировать.

ждем продолжения.

Максим, 2011-02-19 в 13:20:02

Юзаю CARP - отличная штука, а вот с синхронизацией всегда во что-то упирался. Спасибо Вам за статью - идея  очень интересная, думаю попробовать синхронизироваться таким же образом
Насчет выяснения "какой сервер был последним в primary", первое что пришло в голову - решение влоб: поставьте по крону раз в 5-10 сек запись в файлик инфы "время-статус(например с ifconfig)", сервер вряд ли нагрузит, а вот определить легко будет.
Возможно если подумать, найдется решение по-элегантней :)
Удачи

hangover, 2011-02-19 в 13:24:29

Статья хорошая, спасибо, пригодится. Но от количества восклицательных знаков рябит в глазах, уж извините за граммарнацизьм.

dvg_lab, 2011-02-20 в 11:48:08

самое главное - синхронизация сессий, допустим в том же apache, если чел заливает файло и в этот момент мастер падает, что произойдет? Файло придется заливать поновой, ведь про текущую сессию апача на мастере, апач на слейве понятия не имеет.

На днях сам буду реализовать нечто подобное в связке с tomcat + apache mod_jk или nginx в качестве балансера.

fox, 2011-02-20 в 14:43:14

о какой сессии речь идёт?

ponyol, 2011-02-21 в 10:42:37

Статья замечательная, как раз собирался что-то в этом духе реализовать. Теперь есть прекрасное решение, спасибо. Только вот не очень понял зачем нужен ad6 и как туда синхронизируются данные с другого винта. Можно в статье немного об этом подробнее?

fox, 2011-02-21 в 12:47:35

Для удобства ad6 два идентичных винта находятся постоянно в реплекации, а уже средствами ZFS точки монтируем куда надо...

ponyol, 2011-02-21 в 13:01:32

ага, понятно... т.е. /usr и /var монтируем на этот винт )

fox, 2011-02-21 в 15:19:52

Ну /usr и /var это грубо... К примеру если речь об apach то можно точку монтирования /usr/local/www на этот винт...
Аналогично с почтой или ещё чем то подобным... Смысл ненужной репликации, для максимальной скорости синхронизации нужно подвергать репликации только полезную информацию!

Dominator, 2011-02-22 в 19:49:32

Автор молодец! Меня бы не хватило на такую усидчивость.

ш, 2011-03-04 в 11:04:33

Про carp, автору, нужно читать и читать.
Кол-во грамматических ошибок зашкаливает. И если писать английские слова по русски, то не: "дивайзом", а: "дивайсом", не: "два апачя", но: "два апача" ну и т.д.

valeria, 2011-03-04 в 17:05:04

Уважаемый ш!
"По русски" пишется "по-русски", а девайс - это девайс, то, что Вы заметили (апачя и девайз) - это опечатки из-за желания как можно быстрее познакомить общественность с прогрессивной и мегаактуальной статьей. Разве Вас не тронула глубина мысли и широта взглядов автора?! Что конкретного Вы можете сказать именно о работе кластеров?! А для изучения carp советую посмотреть прилагаемую в статье ссылку! Успехов!  

fox, 2011-03-04 в 19:16:26

Уважаемый!
Не "дивайсом" а "девайсом", а в моём случае з перепутать с «с» это в полнее правда подобно, так что перед тем как других поправлять учи сам язык!
Конструктивно Вы не чего не сказали а для тех нужд вполне достаточно описания о carp! И есть ссылка на оригинальный манн так что вперёд дерзайте!
Спасибо Валерии за рассудительность!

ш, 2011-03-04 в 21:28:57

пункт а:
rc.conf|grep
cloned_interfaces="carp0"
ifconfig_carp0="vhid 1 pass password 192.168.2.1/24 advskew 100"
+два дивайса только дурочек мог запихать
если уж давать ссылки на маны, то можно и без статей обойтись, нового тут ничего нет.

пункт б:
"опечаток" столько, что опен офис плачет горючими слезами, спелчекер в руки, ага. и, да, за намеки на кривость произношения слов поблагодарили бы, а не выпячивали пивной живот.

fox, 2011-03-04 в 22:24:47

Во первых: два девайса это обдуманный шаг, ты испытай вначале эту схему и первую и вторую, и про экспериментируй создай аварийную ситуацию!
Во вторых: ссылки это необходимый дополнительный материал для развития темы!
И тут не кто не говорит, что что то новее будет это опыт автора, и его право а для большей отчётности по данному вопросу читать внимательно тот факт, что статья написана для того что бы не забыть а не для развода троллей!
И в третьих: я пиво не пью, так что судишь ты парень по себе!
Тролить пиши на форум и с фактами а не с зыбкими доводами…
И в заключение: Сам дурак!

valeria, 2011-03-05 в 0:13:21

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

gx, 2011-03-05 в 20:51:06

закомитили статью про HAST в handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-hast.html

konstantine, 2011-03-09 в 7:18:20

Вопрос уважаемому fox. Скажите, а зачем на каждой машине подымать два CARP ифа с одинаковыи IPами и с разными advskew ???? Мож моя фантазия скудна, но я понять никак не могу этого и тем более не додумался бы до токого....

fox, 2011-03-10 в 4:29:20

Пофиксел очипятку, с CARP...

ALPHA, 2011-04-14 в 17:19:29

konstantine advskew нужен для рекламации, и интервал соответственно тут должен быть разным, То что fox указал на интерфейсе CARP "advskew 0 " нормально, ибо в мане сказано

advskew interval
            Specifies the skew to add to the base advertisement interval to
            make one host advertise slower than another host.  It is speci-
            fied in 1/256 of seconds.  The acceptable values are 1 to 254.
            The default value is 0.

То есть fox просто написал дефолтное значение, так почему же вы не смогли додуматься konstantine?

Mox, 2011-08-25 в 11:13:08

Аффтар, не вводи людей в заблуждение. uCARP в таком конфиге нафиг не нужен. Он вообще сам по себе может юзаться.
Вместо этого нужен carp(4)+devd(8). Такая связка описана в хендбуке в секции HAST. Статья уже устарела, можно сказать.

Mox, 2011-08-25 в 11:15:03

Да и ядро для carp(4) пересобирать не надо, оно грузится модулем.

fox, 2011-08-29 в 13:34:09

Кончай тролить, я тут не маны пишу а описываю как было решена та или иная проблема и решение работа-способное. И ядро пересобрать или подгружать модуль это тоже дело каждого! А вот что ты добиваешься? Хочешь показать как надо с твоей точки зрения, пиши рядом свою статью мы почитаем, оценим…
Или тебе сыкотно?

Mox, 2011-08-29 в 15:12:40

Сколько пены у рта) Ну раз уж мы на личности уже перешли...
"работа-способное" - как в школе учились? И кстати, давно закончили? Вообще, тон и способ изложения мыслей, как бы, подсказывает.

А по делу:
Я разве не конструктив пишу? И где троллинг?

fox, 2011-08-29 в 16:36:29

Ты о своей пене?)
Это тебе что то неймётся я выше всё сказал. И тема закрыта!

ziggi, 2011-11-24 в 11:42:21

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

В freebsd 9 можно (и нужно :) включить журналирование метаинформации
tunefs -j enable /dev/ufs/some_label

И fsck будет пролетать пулей (время прооверки на порядок меньше). Все-таки иногда ufs бывает предпочтительней.




щщи! Это поля для ввода комментариев к статье, а не для вопросов. Сюда пишите найденные баги, или какие-то фичи :)
Для вопросов есть форум!

Abr, 2012-01-17 в 9:23:51

Плюс статьи в том, что сразу находится Гуглем.
Еще один плюс - приложены готовые скрипты для ucarp.
Однако все описаное не содержит новизны.
Еще весной 2010 года В.А. Лохтуров из Бауманки в своих лекциях рассказывал о том же, но для FreeBSD 7.X, в которой не было HAST, а репликация дисков на двух разных машинах производилась через GEOM-овские ggatec и ggated. В 8.х появился HAST и стало чуток проще это настраивать, используя готовые скрипты HAST-a.
Из недостатков метода следует отметить неоправданное сочетание родного CARP и юзерландовского UCARP - один из них здесь излишен. Более того. Для подключения CARP требуется пересборка ядра, а UCARP заработает и без пересборки ядра и выполнит те же функции.
Вдействительности, нативный CARP имеет то приеимущество, что выполняется на уровне ядра и за счет этого корректно работает с pfsync, чего лишен ucarp.
Но, поскольку о настройке pfsync здесь ничего нет, то мы и получаем ненужное нагромождение.
Смысл же наличия pfsyns (желательно на отдельных фейсах, соединенных напрямую) в том, что когда правильно сделан pfsync, при внезапном останове мастера сессии сохраняются. В свою очередь, это значит, что ползателю, заливающему большой файл в тот момент, когда произошла смена ролей машин, при наличии pfsync-a не придется устанавливать ноую сессию.
Автору: молодец, хорошая работа. Но обилие восклицательных знаков в тексте вызывает желание язвить и придираться. Так что извиняйте...

Еще один, 2012-07-17 в 17:10:32

2Abr
Ну кто, кто вам сказал, что для родного carp(4) надо ядро пересобирать?! Модули вдруг стали некомильфо?

jb, 2012-10-19 в 11:28:19

Юзать ядерный карп для решения этой задачи? Омг.

Махуяр Интриганович, 2013-02-05 в 10:27:56

s/BECKUP/BACKUP/
поправьте



 

  Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
  Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

© lissyara 2006-10-24 08:47 MSK

Время генерации страницы 0.0529 секунд
Из них PHP: 38%; SQL: 62%; Число SQL-запросов: 79 шт.
Исходный размер: 81135; Сжатая: 19229