Pull to refresh

Comments 32

ух, полезный ништячок. Закинул в закладки.
Мда, только тема похоже мало кому интересна :)
2 комментария, а уже 43 человека добавили в закладки… совсем не интересна
Ну просто обычно хотя бы дискуссии завязываются, а тут просто 1 коммент долгое время и все :)
если много комментариев это не признак полезности статьи, а вот если много людей добавили в закладки статью вот это действительно полезная статья — это исключительно мое мнение
Чего обсуждать то? Инструмент класссный! За те же деньги лучше не найдешь!)))
А лишний раз писать как это круто никто не рискует из-за боязни метания кала в карму)
Есть вещи по поводу которых желания дискутировать не появляется.
Pacemaker — одна из таких.
Штука весьма удобная в плане ввода/замены узлов кластера.
Но в продакшн я ее так и не ввел.
Все крутится на hb & drbd.
Почему не ввели бы в продакт?
Интересна обратная сторона медали.
Дело было не в минусах pacemaker, а в управленческом решении.
drbd работает пока не упадет.
проверено 2 раза в большом продакшене.
3ий раз не стал ждать.
Потрясающая новость, никогда не слышал об этой технологии. Куда я смотрел?
UFO just landed and posted this here
UFO just landed and posted this here
Без кворума pacemaker скорее опасен, чем полезен. Нужны 3 ноды минимум. Или 100500 раз проверенный STONITH не на ipmitool, а на PDU.
А через шасси блэйд-центров не пробовали? Подумываю над…
А что эта штука вообще делает, кроме как синхронизирует дельтами свой собственный конфиг?

Из статьи немного непонятно, в чем заключается кластеризация — http она проксирует или данные синхронизирует или что?
Эта штука управляет сервисами кластера — поднимает или опускает их в зависимости от внутренних и внешних условий. Напрямую она ничего не делает. Как вы будете проксировать http или синхронизировать данные — это ваша проблема (посмотрите упоминаемую вначале предыдущую статью).
Ясно. Стоило бы написать об этом в начале статьи.

Для каких конфигураций эта штука вообще актуально?

Допустим у меня есть кластер из двух серверов, на них веб и mysql, и они друг друга резервируют.
Если любой из сервисов падает, мне приходит смс от нагиоса и я его поднимаю.

Куда тут присунуть эту вундервафлю?
> Стоило бы написать об этом в начале статьи.
> Для каких конфигураций эта штука вообще актуально?
Про это и написано в начале статьи — для любых конфигураций. Active/Passive, Active/Active и т.д.

> Куда тут присунуть эту вундервафлю?
Посмотрите Cluster From Scratch, ссылка в конце статьи. Там примерно ваша задача и рассматривается. Ставите на оба сервера, назначаете ресурсы — httpd, mysqld и т.п., включаете их мониторинг, и настраиваете привязки. И будет у вас при падении сервиса на одной машине, подниматься на другой. Уведомления тоже можно отсылать.
UFO just landed and posted this here
Вы немного не поняли. Самой инфраструктуре pacemaker не требуется общее хранилище или выделенный раздел, как например у IBM HA MS — там нужен раздел где-нибудь на SAN, который монтируется активной нодой.
Если вашему кластеру требуется общее хранилище, вы сами можете выбрать каким образом его организовать и каким образом переносить между узлами. Так, мы, например, для этого IBM GPFS используем. Какой-либо нужды специальным образом связывать Pacemaker и GPFS нет.
UFO just landed and posted this here
Ну, очень грубо говоря, Pacemaker это продвинутый heartbeat, с бОльшим набором фич.
Я полагаю что при портировании основной проблемой будет несоответствие идеологий стартовых скриптов FreeBSD и LSB. В остальном привязки к ядру вроде бы нет, специальных драйверов (кроме STONITH) не требуется.
UFO just landed and posted this here
UFO just landed and posted this here
К сожалению ссылка на «предыдущую статью» (https://habrahabr.ru/blogs/sysadm/104621/) не работает.
Sign up to leave a comment.

Articles