Мы — долго запрягаем, быстро ездим, и сильно тормозим.
|
||||||||||||||||||||||||||||||||
www.lissyara.su
—> статьи
—> FreeBSD
|
|
Перезагружаем системы или загружаем модули руками, если то позволяет текущий securelevel:
|
Предположим, что обе машины имеют два сетевых интерфейса:
fxp0 - для взаимодействия с внешним миром (мастер узел имеет IP 172.16.100.1, а slave - 172.16.100.2).
fxp1 - для зеркалирования дисков между узлами (master - 192.168.100.1, slave - 192.168.100.2).
На fxp0 мастера также поднят через алиас 172.16.100.12, который будет использоваться
для предоставления публичных сервисов и в случа краха мастера будет перехвачен на slave узле.
Для переключения на slave в случае сбоя будем использовать freevrrpd, установленный
из порта /usr/ports/net/freevrrpd
Пример конфигурации freevrrpd:
Мастер узел:
|
Резервный узел, который перехватит инициативу в случае краха мастера:
|
Экспорт дисковых разделов.
На мастер узле прописываем параметры экспортируемого со slave диска в /etc/gg.exports:
|
А на slave-е параметры диска на мастр-узле (в случае краха мастера, slave возмет на себя роль мастера):
|
На запасной машине запускаем процесс ggated (только на slave, не на мастере !).
|
Демон будет запущен в режиме отладки.
После того как все заработает нужно прописать запуск ggated в стартовый скрипт слейва.
Импортирование удаленного блочного устройства на мастер-узле осуществляется командой:
|
которая вернет имя нового устройства, как правило это будет ggate0
В дальнейшем на мастере нужно осуществлять дисковые операции с /dev/ggate0
Запускаем ggatec только на мастере !
При сбое мастера freevrrpd скрипт become_master завершит выполнение ggated на slave узле и выполнит ggatec,
а после восстановления старого мастера поднимет на нем ggated через скрипт become_standby
Настройка заркалирования.
На мастер-узле создаем RAID-1 из локального и удаленного дисков:
|
Алгоритм балансировки "prefer" важен для минимизации нагрузки на вторичный диск,
все операции чтения будут производится с локального диска, которому выставлен более высокий приоритет 100.
Перестраиваем массив:
|
Для включения опции автосинхронизации слайсов выполняем:
|
После завершения синхронизации массива в логе увидим:
|
Далее /dev/gm0 можно отформатировать стандартным образом через newfs и примонтировать на мастер сервере.
Переключение на резевный (slave) сервер в случае краха основного сервера.
Проведем эксперимент - отключим линк у мастер-сервера, симулировав его крах.
Ниже описана логика работы скрипта become_master
На slave завершим ggated процесс. Зеркало должно автоматически заработать на запасном узле:
|
Далее выполним fsck на случай нарушения целостности ФС и примонтируем раздел:
|
После того как раздел заработал на slave-сервере, попытаемся восстановить работу мастера,
который должен после краза занять роль запасной машины.
После включения мастер-узла, займемся восстановления его статуса первичного узла.
На местере останавливаем работу зеркала gmirror для перевода его в подчиненный режим.
|
Запускаем ggated для приема репликаций от бывшего слейва, теперь ставшего основным сервером
|
Подключаем локальный диск /dev/da0s1e в зеркало в качестве неприоритетного раздела.
Для этого выполняем автоконфигурацию:
|
Оформляем экспорт локального диска /dev/da0s1e:
|
И ставим экспортируемому диску наименьший приоритет.
|
Включаем автоконфигурацию зеркала:
|
Перестраиваем зеркало:
|
После завершения перестроения в логе наблюдаем:
|
Удаляем раздел /dev/ad0s1d из зеркала и вновь добавляем его с повышенным приоритетом,
для восстановления функций основного сервера:
|
Ситуация краха запасного сервера, при работающей мастере.
После восстановления работы слейва, на мастер хосте временно отключаем импорт диска:
|
в логе
|
На слейв узле останавливаем зеркалирование:
|
Запускаем на слейве экспорт ggated
|
На мастер узле подключаем удаленный диск:
|
На мастере автоматически должен быть обнаружен подключенный внешний диск:
|
Запускаем перестроение raid и ждем его завершения:
|
Замечания по поводу сохранения целостности данных:
- нельзя экспортировать через ggated физические разделы, если они уже добавлены в зеркало;
- не нужно предпринимать попытки создания мастер-мастер репликации, это невозможно;
- нельзя монтировать экспортируемый раздел на активном слейв сервере. Монтирование экспортируемого раздела слейва возможно только на мастер-узле;
- После сбоя необходимо выполнить fsck для зеркала;
- Обязательно ведение резервного копирования зеркала.
размещено: 2009-04-09,
последнее обновление: 2009-04-09,
автор: texnotronic
Morty, 2009-04-09 в 18:18:15
Отличный материал !! Автору спасибо
MetiS, 2009-04-10 в 2:35:17
Весчь!!! Надо бы реализовать на практике. Спасибо.
MarvinFS, 2009-04-10 в 5:35:44
Может я что-то не понимаю? о какой крастерности идет речь если переключение меджу нодами происходит в ручном режиме??? более того - необходимо присутствие администратора который это производит? неговоря уже о потере сетевых соединений и о разных IP адресах на каждой из внешних сетевых карт серверов.
Рассмотрим ситуацию выхода из строя внешней сетевой карты master сервера. при этом разделы будут успешно синхриться но мастер сервер перестанет быть доступным извне. Какой это кластер??? это извините более другое! :)
не вижу никакого принципиального отличия от просто cold reserve машины и регулярных бекапов + системный винт в raid1.
настолько я в курсе дела, HA cluster в классическом смысле на freebsd вещь несовсем очевидная и freevrrpd это только часть конфигурации, хотя на мой взгляд не очень удачный пример - я бы лучше использовал iSCSI, потому как это постоянное GEOM синхронизация просто утомляет.. а попробуй ка поработай во время прохождения mirror синхронизации! :)
www2, 2009-04-10 в 8:24:40
Слово "машина" - женского рода, поэтому говорить "на обоих машинах" - не грамотно.
"который должен после краза занять роль запасной машины." - краха.
Это две машинки с холодным резервированием, но кластером называть их я бы не стал.
Kolesya, 2009-04-10 в 8:50:20
Камрад texnotronic указал в начале статьи
>Размер зеркалируемых дисковых разделов должен быть
>минимально возможным для решаемой задачи
По поводу автоматического переключения (в т.ч.) и выход карты - скрипт напишите.
2texnotronic
+5 стиль написания легкочитаемый :)
nikll, 2009-04-10 в 10:29:09
хорошая заметка, но на кластер никак не тянет. смысла не вижу в таких изгалениях, год назад у мну была подобная задача, решал через carp+corba т.к. оно должно само работать без постоянного обслуживанния одмином, оно не должно грузить тяжело и надолго оба сервера, корба ведет журнал изменений благодоря чему о полной синхронизации 500гб разделов можно забыть как о страшном сне....
nikll, 2009-04-10 в 10:30:47
Кстати я тут в комментах услышал одно интересное слово iscsi, по состоянию год назад это чудо в продакшен на фре негодилось вообще никак, я игрался с zfs+iscsi
arksu, 2009-04-10 в 14:46:04
холодное резервирование можно было организовать и более простыми вещами
Voron, 2009-04-10 в 16:50:38
В принципі стаття гарна. Правда, можна поставити під сумнів наскільки коректно буде працювати такий тип мірорінгу дисків по мережі при великих навантаженнях. У перспективі на FreeBSD запрацює, по нормальному, ZFS. Тоді можна буде будувати НА кластери без проблем:) Хотів би добавити, для того, щоб дві ноди "грамотно" функціонували добре використовувати /usr/ports/sysutils/heartbeat. Він дозволить контролювати крах будь-якого мережного інтерфейсу, сервісу чи ресурсу.
P.S. При бажанні можна організувати кластер за принципом Активний-Активний
arksu, 2009-04-10 в 16:57:06
а по русски-то никак? сайт написан на русском если вы не заметили... и сообщество русскоговорящее...
да и Вы я все таки думаю тоже знаете русский раз прочитали статью....
Хохлосрач, 2009-04-12 в 1:57:09
Хохлосрач тред го!
m0ps, 2009-04-12 в 21:44:04
arksu, для тебя есть принципиальная разница?
Dark, 2009-04-13 в 9:56:43
20Гб раздел будет синхронизирован при 100Мбит линке за 30 минут, а 500Гб - за 11 часов.
Боюсь, что мой веб-сервер с биллингом в аккурат попадут под последний случай с 11 часами... ИМХО, в продакшн нельзя с такими цифрами (даже для 20Гб)
www2, 2009-04-13 в 10:55:05
>Боюсь, что мой веб-сервер с биллингом в аккурат попадут под последний случай с 11 часами... ИМХО, в продакшн нельзя с такими цифрами (даже для 20Гб)
Это только первый раз. Первый раз нужно скопировать всё блоки, а потом будут копироваться только изменённые.
RomanoN, 2009-04-13 в 11:48:17
По моему статья отсюда
http://phaq.phunsites.net/2006/08/11/realtime-file-system-replication-on-freebsd/
Но спасибо за перевод.
Sava, 2009-04-14 в 10:29:20
Товарищи, а что такое этот Cobra? В портах нету, гугл тоже не колется особо.
const, 2009-04-16 в 10:18:06
> Товарищи, а что такое этот Cobra? В портах нету, гугл тоже не колется особо.
Если правильно понял, то это: [url=http://ru.wikipedia.org/wiki/CORBA]
Хотя лучше бы nikll написал статью и дал на нее ссылку... ;))
const, 2009-04-16 в 10:42:07
Из статьи совсем не ясно, что должно быть в скриптах?
masterscript = /usr/local/bin/become_master
backupscript = /usr/local/bin/become_standby
drurus, 2009-04-17 в 11:27:07
А можно-ли через geom_gate экспортировать зеркало (gm0) и зеркалить с зеркалом второго сервера?
xara, 2009-11-27 в 11:08:04
очепятка:
использованы в качестве вешнего диска
правильно - внешнего.
Этот информационный блок появился по той простой причине,
что многие считают нормальным, брать чужую информацию не уведомляя автора
(что не так страшно), и не оставляя линк на оригинал и автора — что более существенно.
Я не против распространения информации — только за. Только условие простое — извольте
подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой,
незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.
© lissyara 2006-10-24 08:47 MSK
Комментарии пользователей [20 шт.]