HA кластер - как сейчас с софтом?

Про Openstack не скажу, не пинал. Proxmox для HA вроде как требует внешний сторадж, что логично. В ту же кучу еще можно OracleVM, но тоже внешний сторадж.

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

В общем случае, HA == shared storage.

Если делать его из самих же серверов на основе drbd или gluster, то отказоустойчивость под сомнением. Сам так не пробовал, но вендорами такие вещи не поддерживаются.

Если устраивает, можешь собрать общий сторадж через реплицируемый gluster, подключить его к proxmox и будет тебе HA.

Коллеги кому-то продали кластер с glusterfs. На отказоустойчивость жалоб нет, а вот на производительность время от времени появляются.

Кластер будет разворачиваться на своих мощностях или где-то на хостинге? В Digital Ocean есть шикарная штука - floating ip. Но я не знаю, как у них с Виндой. Вроде была в наличии.

Кстати в инструкции как настроить floating ip в DO описано как настроить heart beat, всё предельно просто.

Proxmox + локальный ceph с replica x2.

Но скорость ceph будет малой при такой конфигурации.

Дрбд работает, но сплитбрейн надо разрешать руками.

вендорами

Вендорами вообще мало что поддерживается, ведь если всё будет опенсорсное - кто тогда будет платить за MegaSuperFailoverSystem?

gluster как по мне не для того. Тут только DRBD + iscsi поверх.

gluster как по мне не для того

Почему?

На своих мощностях ессно. На хостинге с этим заморачиваться смысла нет, проще на амазоне или прочих облачных сервисах купить виртуалки.

Медленно будет ИМХО. Сейчас guster для постгревых WAL крутится - там оно пойдет ввиду гибкости и малых требований, но под виртуалки - я бы не стал...

openstack не замена pacemaker'а. Что бы openstack сам работал в режиме HA испльзуют pacemaker.

Я может, чего-то не понимаю, но... В такой ситуации, как у ТС, развернуть HA, не возможно в принципе. Ну пусть имеется три машины. Одну отдаём под исполненине виртуалок, две другие через drbd + iscsi - отдают образы. Навернулась машинка, которая крутила виртуалки - всё. Сливай воду же.

Кстати, а как в такой ситуации: drbd + iscsi жить будет? Это надо как-то делать мультимастер? Или что? При выходе из строя одной ноды, чтобы виртуалки, ничего не заметили...

Дык 3 хоста, n+1, само не умеет, не?
зы у оракула есть поддерживаемые конфигурации с drbd.

виртуалки будут крутиться там же где и сторедж.

повторюсь - прерывание сервиса на 5 минут не критично. главное - чтобы оно потом взлетело нормально, и работало.

к слову, proxmox умеет сугубо контейнеры/виртуалки гонять? нативные ресурсы не умеет? (в принципе, при наличии контейнеров совершенно некритично, оверхид минимальный, но все же).

Вендорами вообще мало что поддерживается, ведь если всё будет опенсорсное - кто тогда будет платить за MegaSuperFailoverSystem?

Опенсорсными вендорами тоже не поддерживается. Да и поддерживаемых приетарных аналогов я не знаю. Мб и hyper-v есть?

Ну так, не колоти мозг! Зачем ты усложняешь. Простой, в пять минут, это не HA, вообще. Это называется «горячая замена», или даже «тёплая замена».

Купи три одинаковых железки. На любые две поставь любой гипервизор. Третью железку, идентичную первым двум - держи на подмену. Если тебя физически не будет рядом, ну можешь настроить drbd с первых двух, на третью, и в случае чего поднимишься на ней. Но, всё это... Кхм... drbd - Медленно. По этому дисковые полки такие дорогие, ты берёшь нормальную полку (а там, у тебя будет два БП, два RAID контроллера, и т.д. - всё всё дублировано), и цепляешь на неё ноды, которые будут у тебя выполнять твои образы. Всякие штуки, вроде drbd - в самом то деле, тоже будут стоить тебе хороших денег! drbd, чтобы хорошо работало, надо жамбофреймс, быстрые диски, и т.д. - И даже, если ты всё это сотворишь, HA, не получится. Получится горячая замена. Ну это моё имхо, конечно. :)

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

Опенстек под такую задачу однозначно перебор. Простой ХА у ксенсервера, но хранилище все равно общее потребуется. Но ксен не умеет контейнеры.

Есть опыт использования pacemaker + gluster под относительно малонагруженные виртуалки. Сказать могу что работа лобзиком с pacemaker'ом имеет обыкновение затягиваться. Если контейнеры устроят и фенсинг не нужен то можно посмотреть к примеру fleet.

gluster как по мне не для того. Тут только DRBD + iscsi поверх.

По скорости drbd должен быть лучше, но остаётся вопрос масштабируемости и надёжности. Что там с надёжностью у drbd9 не вкурсе, 8 в продакшн пускать не рекомендовали. Да и на три ноды смасштабируется только через костыли.

Если будет ha только на 2 хостах, а третий будет выступать арбитром, то прокатит, иначе стоит рассмотреть gluster, или ceph.

Я бы не стал городить прохмохи всякие - это делается через DRBD и пейсмейкер в два счёта, благо ресурсы в пейсмейкере почти подо всё есть. А подо что нет - можно самому написать :) Если поделить сторадж на три части, то можно получить кластер с 3 активными нодами, где каждая часть стораджа активна на одном из серверов и реплицируется ДРБДой на два других (в 9 версии добавили вроде до 32 нод).

8 в продакшн пускать не рекомендовали.

Это фантазии какие-то. Работает в продакшене у овердохуа компаний. В том числе у меня отпахало три года в качестве отказоустойчивого iSCSI таргета под приличной нагрузкой, причём года два - непрерывно, без ребутов.

Кстати, выше упомянули про фенсинг. Если хочешь использовать проксмокс, то для ha он обязателен. Чем фенсить (управляемый свитч/ибп) есть?

Мопед не мой. Сам drbd не пользовался.

непрерывно, без ребутов.

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

Нативные? Вряд ли.

Фенсинг вещь конечно полезная, но я бы не сказал что крайне обязательная. В современных серверах, в принципе, во всех есть IPMI и фенсить через него проще всего.

Ну, перед передачей в продакшен я его насиловал и так и эдак (убивал ноды разными способами, дергал несколько патчкордов) - нестандартного поведения не заметил...

Тоже долго мучал все эти прокмоксы с опенстеками и то что ниже уровнем, в итоге пришёл к тому, что «отказоустойчивость» проще и надёжнее реализовать на уровне приложения. Репликация базы, несколько application-серверов, самодельный велосипед для управления nginx, который передёргивает апстримы по результатам heartbeat, аналогичный скрипт для баз, меняющий мастера со слейвом, приложение, умеющее переключаться на запасную базу данных и следящее за тем, чтобы не наткнуться на слейв-базу. Дело в том, что все эти красивые решения с фенсингом и прочим энтерпрайзом можно реализовать либо на своём железе, которое стоит прямо у тебя под попой, либо за много денег в датацентре. Если надо дёшево и сердито, то приходится извращаться подобным образом. С другой стороны, бонусом можно получить независимость инфраструктуры от вендора, провайдера и даже чёрта лысого, а также возможность разносить сервисы географически по разным датацентрам, если задержки не критичны. Для DRBD ты не поставишь одну ноду в Питере, другую в Москве, а третью на Камчатке. Минус: если твой софт не умеет так работать, то либо дорабатывать напильником, либо смириться и идти по первому пути.

Он везде обязателен. IPMI будет.

Сейчас ты вроде в VMWare свалился? Твоя статья про сторадж на хабре, была лучшей в своём жанре!

Горячая/теплая замена подразумевает вмешательство извне. Мне же нужно, чтобы оно работало в случае нежданчиков. Перерыв сервиса даже на несколько минут - неприятно, но не критично. А вот отказ до утра/до приезда на объект - печаль.

К слову, MySQL/PostgreSQL поверх DRBD - насколько большая вероятность краша БД при краше в процессе записи?

Не озвучен бюджет, по крайней мере стоимость железяк, требуемое количество iops и прочие latency. Простой в 5 минут как уже упоминалось выше - ни разу не HA.

Если денег есть - собрать на солярке zfs + pnfs из трех узлов, и поставить kvm и какой-либо gui для управления kvm. Контейнеры можно создавать нативные солярковские, но если планируется и винда - удобнее и проще использовать будет именно виртуалки на kvm с nfs в качестве бэкэнда.

Если денег нету - взять nutanix community edition, там вроде обычный линукс + ndfs + перепиленный kvm и симпатичная морда навроде опенстека.

нищебродский вариант - запилить пару серверов в drbd, а на третий сервак сливать реплику drbd и потом рвать волосню на жопе если drbd ноды хапнут splitbrain, ну и лагающее хоронилище если честно этот drbd.

Все становится гораздо более идеологически верным и более шустрым, если сделать два сервера для хранения данных (ставится солярка + zfs + rsf-1 плагин), а два оставшихся пустить под виртуальные машины в кластере (рекомендую xenserver - у него более удобный и логичный на мой взгляд вариант организации кластера + кэширование I/O из коробки вменяемое на shared storage). Для удобства управления можно развернуть к примеру cloudstack, там помышевозить и получить почти digital ocean ( если будет еще и подсетка с реальными ip :) ).

Ну уже отписал же - бюджета на 3 обычных сервера.

С «особенностями» соляры разбираться особо желания нет.

nutanix - вроде как по описанию интересная вещь, жаль контейнеры не поддерживает. Ну и инфы не особо много - по книге все красиво, а как на деле - хз.

Отдельные стораджи - это и сеть десяткой по-хорошему нужно к ним делать, чтобы профит был...

А что, если, купить всего два сервера, но помощнее и надёжнее. Один обозвать мастер, другой слейв. Один будет на себе всё крутить. Другой будет на себе реплику drbd держать в ro. Мониторить реплику drbd. Если реплика пропала - вырубить через ILO, мастер сервер. Забанить его. Перевести drbd в режим записи, и работать на слейве. Потом руками всё вернёшь обратно, когда мастер починишь.

Не энтерпрайзно (впрочем, всё что хочешь творить ты, тоже особо энтерпрайзом не пахнет :)). Примитивно, зато просто и надёжно. :) ИМХО, построить что-либо вменяемое без общего стораджа - затея весьма стрёмная.

Новый proxmox 4 умеет для LXC (нативных) контейнеров HA, openvz выкинули. Использую drbd в proxmox 3 для двух нод для kvm виртуалок с НА. Сбоев нод пока не было. как работает НА не испытал в бою. НА стенде не тестил.
Был сбой на диске drbd на основной ноде. В онлайне мигрировал виртуалки KVM с первой на вторую ноду. Остановил первую ноду. Заменил в ней диск. Запустил DRBD среплицировалась. После вернул виртуалки обратно. В консоли что то делал минимально. Время простоя сервисов KVM виртуалок минимально (точно уже не помню), зависит от скорости сети - не рвутся ssh сессии для KVM c linux. Для мелких виртуалок (которые в памяти места мало занимают) потери ping во время миграции - 1-2 пакета. Если для DRBD сделать RAID, то думаю вообще будет очень надежно. Если сделать 10ГБит/с сеть (для копирования виртуалок из RAM В RAM) и быстрый RAID для DRBD, то будет вообще хорошо. Это я все про свой единственный случай.
Запарка с fenced устройствами если нет поддержки IPMI в proxmox 3 была, был конфиг с заглушками. Рекомендуют кластер на трех нодах
proxmox 4 недавно вышел, необкатан как по мне. Но думаю к нему присматриваться.
разрабы proxmox давно склоняют к платным обновлениям и поддержке. Но пока и бесплатные релизы вполне работают.
Поставьте, потестируйте.

innodb движок MySQL критичен для аварий по типу крэш ОС или выключения сервера. здесь только мастер-мастер режим поможет. Думаю даже iSCSI шары всякие не помогут. т.е. два отдельных сервера/кластера для БД MySQL нужно (ИМХО).

А как они память KVM, в онлайне переносят? Средствами самого kvm/virsh? Или свои механизмы?

Дрбд работает, но сплитбрейн надо разрешать руками.

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

На таком небольшом объёме проще выпилить лобзиком из Pacemaker.

Если всё настроено с умом - транзакционность, флаш на диск в иннодб (это всё и так по дефолту вроде), протокол С в дрбд - то вероятность практически нулевая. Будет так называемое crash-consistent состояние перед подъемом на второй ноде. Ну и фс с data=journal не помешает.

Откуда такой негатив к дрбд? Может многие просто как-то не так его готовят?..

Вендорами вообще мало что поддерживается, ведь если всё будет опенсорсное - кто тогда будет платить за MegaSuperFailoverSystem?

Платят за то, что к тебе прилетят добрые дяди на вертолете и разве что попку не подотрут.

я сейчас как раз тыкаю Pacemaker. проблема в том, что наблюдаются некоторые глюки =(

Откуда такой негатив к дрбд? Может многие просто как-то не так его готовят?..

Тем же вопросом задаюсь!

ага, руками. каждый долбаный день.

Три года пахал двухнодовый HA-кластер на DRBD, где сервисами были виртуальные машины KVM. В этой конфигурации лучше руками, но что бы каждый день... Это что-то не так настроено.

Не, дрбд на активные сервисы лучше не пихать

Были как раз активные сервисы разделенные по машинам: База данных Postgres, Бизнес-логика, Asterisk. Работало круглосуточно, это было автоматизированное городское такси.

drbd - тормоз, плюс он страдает расщеплением разума

drbd - тормоз

Хуже gluster'а или cepha чтоли? В особенности, учитывая, что поверх дрбд можно создавать lvm-разделы под виртуалки, а не qcow/raw.

плюс он страдает расщеплением разума

Насколько я понимаю, если всё в одном свитче + настроен фенсинг, это не страшно. По крайней мере, если не делать того, чего делать не стоит.

если не делать того, чего делать не стоит.

просто при тестах вынимал из сетевух кабельки на активной ноде и оно дрбд с 90% вероятностью валилось в сплит