Comments 21
1.Это что же, отвал кластера фиксируется только если нода становится недоступной?
Вы тесты проводили какие нибудь, типа kill -9 *drbd*?
Нода то может жить, но не быть функциональной.
В таких системах нужно делать проверку которая изменяет веса на основании — получилось записать что-то в хранилище или нет. Не получилось — правим вес, перетягиваем мастера на другую ноду.
А у вас — вроде и ресурсы заведены, а проверка по шатдауну. Это как-то совсем круто.
2. Были сбои/тесты с такой системой кроме выключения питания одной из нод?
А переброс ip шника с ноды на ноду не заставляет ESXi вылетать по какому-нибудь таймауту? Там, насколько я помню большой довольно таймаут (в сравнении, конечно) прежде чем нода решает перетянуть на себя ресурсы если другая нода недоступна.
Вы тесты проводили какие нибудь, типа kill -9 *drbd*?
Нода то может жить, но не быть функциональной.
В таких системах нужно делать проверку которая изменяет веса на основании — получилось записать что-то в хранилище или нет. Не получилось — правим вес, перетягиваем мастера на другую ноду.
А у вас — вроде и ресурсы заведены, а проверка по шатдауну. Это как-то совсем круто.
2. Были сбои/тесты с такой системой кроме выключения питания одной из нод?
А переброс ip шника с ноды на ноду не заставляет ESXi вылетать по какому-нибудь таймауту? Там, насколько я помню большой довольно таймаут (в сравнении, конечно) прежде чем нода решает перетянуть на себя ресурсы если другая нода недоступна.
1. У каждого нормального ресурса есть API-команда Monitor, которую Pacemaker использует для проверки состояния ресурса. Ее вызов активируется параметров monitor у ресурса, можно задать действие при ошибке. По умолчанию кластер рестартует ресурс, но можно поставить режим standby, который вызовет миграцию всех ресурсов со сбоящей ноды. Можно указать количество ошибок перезапуска, после которых пройдёт миграция.
Перед запуском кластера я систему очень долго мучал, и стабильность софтовой части меня более чем устроила, поэтому я пока не стал активировать этот режим — если кому-то это нужно, то делается это в два счета.
Вообще, у Pacemaker очень много возможностей — интересующиеся могут заглянуть в документацию, это не тема одной или даже нескольких статей.
Что такое «проверка по шатдауну» не понял. Да, и drbd живет в ядре, его kill -9 не возьмешь.
2. Какого рода тесты, например? Сеть выдёргивалась, питание одной из нод вырубалось, свитч один вырубался. Всё отрабатывало как надо.
И еще, так как практически весь рабочий софт находится в ядре (SCST, DRBD), то его сбой приведёт к краху ядра (особенно если включить дополнительно panic_on_oops) и нода, по сути, будет мертва, что обнаружит вторая нода.
Переброс IP-шника для ESXi проходит гладко, таймаут Corosync по умолчанию — 4 секунды, таймаут iSCSI в ESXi — 10 секунд.
Так что всё проходит очень быстро и практически незаметно для ВМ.
Перед запуском кластера я систему очень долго мучал, и стабильность софтовой части меня более чем устроила, поэтому я пока не стал активировать этот режим — если кому-то это нужно, то делается это в два счета.
Вообще, у Pacemaker очень много возможностей — интересующиеся могут заглянуть в документацию, это не тема одной или даже нескольких статей.
Что такое «проверка по шатдауну» не понял. Да, и drbd живет в ядре, его kill -9 не возьмешь.
2. Какого рода тесты, например? Сеть выдёргивалась, питание одной из нод вырубалось, свитч один вырубался. Всё отрабатывало как надо.
И еще, так как практически весь рабочий софт находится в ядре (SCST, DRBD), то его сбой приведёт к краху ядра (особенно если включить дополнительно panic_on_oops) и нода, по сути, будет мертва, что обнаружит вторая нода.
Переброс IP-шника для ESXi проходит гладко, таймаут Corosync по умолчанию — 4 секунды, таймаут iSCSI в ESXi — 10 секунд.
Так что всё проходит очень быстро и практически незаметно для ВМ.
1. Хм. On-fail=standby? Когда я пробовал, — он работал совсем не так, как надо. Не помню правда что именно было не так. И предсказывать веса, то есть планировать работу кластера по весам — толком не получается. В итоге веса мы стали менять правилом которое смотрело на параметр для самодельного ocf ресурса.
Вообще, конечно, тут скорее важен подход — ваш кластер предоставляет определенный сервис. И именно предоставление этого сервиса надо мониторить, лучше всего тем же паттерном (или максимально приближенным к нему) который используют пользователи этого сервиса. Для примера — если у вас там http сервер то нужно тягать страничку с кластерного ip адреса и проверять не изменился ли ее md5 хеш, например.
Проверкой по shutdown — в данном контексте, это когда проверка работоспособности ресурсов кластера напрямую не производится, а считается, что ресурс всегда доступен — пока нода жива. Нода умерла — значит ресурс не доступен.
К слову, в двухнодовой конфигурации так же хорошо бы настроить stonith. А лучше сделать третью ноду (в комментариях к предыдущей статье об этом писали), можно только с арбитром и кворумом — по всем канонам так бцдет верно.
2. Смотрите, гипотетически, у вас отваливается DRBD на одной из нод.
Во-первых, вполне возможно что вся pacemaker нода не уйдет в ребут по kernel panic сразу.
Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?
DRBD добавили таки в ядро? Ну надо же. Клёво.
3. Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала? Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?
Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.
Вообще статья, супер, конечно, спасибо.
Вообще, конечно, тут скорее важен подход — ваш кластер предоставляет определенный сервис. И именно предоставление этого сервиса надо мониторить, лучше всего тем же паттерном (или максимально приближенным к нему) который используют пользователи этого сервиса. Для примера — если у вас там http сервер то нужно тягать страничку с кластерного ip адреса и проверять не изменился ли ее md5 хеш, например.
Проверкой по shutdown — в данном контексте, это когда проверка работоспособности ресурсов кластера напрямую не производится, а считается, что ресурс всегда доступен — пока нода жива. Нода умерла — значит ресурс не доступен.
К слову, в двухнодовой конфигурации так же хорошо бы настроить stonith. А лучше сделать третью ноду (в комментариях к предыдущей статье об этом писали), можно только с арбитром и кворумом — по всем канонам так бцдет верно.
2. Смотрите, гипотетически, у вас отваливается DRBD на одной из нод.
Во-первых, вполне возможно что вся pacemaker нода не уйдет в ребут по kernel panic сразу.
Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?
DRBD добавили таки в ядро? Ну надо же. Клёво.
3. Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала? Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?
Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.
Вообще статья, супер, конечно, спасибо.
1. На данный момент он работает так, как написано в документации — если падает хоть один ресурс, то все ресурсы переезжают на запасную ноду.
Я в общем-то и не предоставляю сервис — я делаю высокодоступное хранилище для своего же vSphere кластера, не более того.
Я понимаю, что можно много чего навертеть и добавить еще пару девяток к доступности, но мне хватает и того, что есть :)
А предоставление сервиса и все прочие параметры (состояние дисков, массивов, DRBD, сети и т.п.) у меня мониторятся отдельно Zabbix-ом и если что-то происходит не предусмотренное конфигом кластера, то я буду реагировать уже сам.
Насчет STONITH я думал (на основе IPMI), но решил, что это избыточно.
А третью witness-ноду да, смысл сделать имеет, только вот в Pacemaker нет простого сбособа добавить просто ноду-свидетеля.
Можно сделать третьей ноде standby=on, но на ней должны быть все те же ресурсы (DRBD по крайней мере), т.к. кластер будет их пытаться мониторить. Второй способ — не запускать вообще Pacemaker, а оставить только Corosync, но я не уверен что это хорошая идея, нужно проверять. Но скорее всего этот способ самый оптимальный.
2. Что значит — отваливается? Глюк в софте? Тогда ядро уйдёт в резет сразу, это настраивается в sysctl (kernel.panic)
А в чем проблема? Во всех распространенных ОСях таймаут на I/O к диску гораздо выше (в линуксе минута, в винде тоже вроде) и его всегда можно задрать при необходимости.
Я специально делал виртуалку, которая во всю прыть писала на диск и убивал активную ноду по питанию — никакой ругани со стороны гостевой ОС не было, всё продолжало работать как надо.
Да, добавили, но это ничего не меняет.
Модулем оно или в ядро интегрировано — разницы с точки зрения работы никакой.
Я, как видно, собираю его модулем т.к. в ядре более старая версия.
3.
Нет, тьфу тьфу, всё работает пока чётко. Но перед продакшеном я, как писал выше, всякое симулировал и вело оно себя предсказуемо.
Я согласен, что в моей конфигурации не всё предусмотрено, но для конкретно моих требований этого более чем достаточно.
И я постарался поведение кластера проверить во всех более или менее реальных ситуациях.
Я в общем-то и не предоставляю сервис — я делаю высокодоступное хранилище для своего же vSphere кластера, не более того.
Я понимаю, что можно много чего навертеть и добавить еще пару девяток к доступности, но мне хватает и того, что есть :)
А предоставление сервиса и все прочие параметры (состояние дисков, массивов, DRBD, сети и т.п.) у меня мониторятся отдельно Zabbix-ом и если что-то происходит не предусмотренное конфигом кластера, то я буду реагировать уже сам.
Насчет STONITH я думал (на основе IPMI), но решил, что это избыточно.
А третью witness-ноду да, смысл сделать имеет, только вот в Pacemaker нет простого сбособа добавить просто ноду-свидетеля.
Можно сделать третьей ноде standby=on, но на ней должны быть все те же ресурсы (DRBD по крайней мере), т.к. кластер будет их пытаться мониторить. Второй способ — не запускать вообще Pacemaker, а оставить только Corosync, но я не уверен что это хорошая идея, нужно проверять. Но скорее всего этот способ самый оптимальный.
2. Что значит — отваливается? Глюк в софте? Тогда ядро уйдёт в резет сразу, это настраивается в sysctl (kernel.panic)
Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?
А в чем проблема? Во всех распространенных ОСях таймаут на I/O к диску гораздо выше (в линуксе минута, в винде тоже вроде) и его всегда можно задрать при необходимости.
Я специально делал виртуалку, которая во всю прыть писала на диск и убивал активную ноду по питанию — никакой ругани со стороны гостевой ОС не было, всё продолжало работать как надо.
DRBD добавили таки в ядро? Ну надо же. Клёво.
Да, добавили, но это ничего не меняет.
Модулем оно или в ядро интегрировано — разницы с точки зрения работы никакой.
Я, как видно, собираю его модулем т.к. в ядре более старая версия.
3.
Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала?
Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?
Нет, тьфу тьфу, всё работает пока чётко. Но перед продакшеном я, как писал выше, всякое симулировал и вело оно себя предсказуемо.
Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.
Я согласен, что в моей конфигурации не всё предусмотрено, но для конкретно моих требований этого более чем достаточно.
И я постарался поведение кластера проверить во всех более или менее реальных ситуациях.
Обидно, что какой нибудь пост об очередной, никчемной железке собирает толпы народу, а тут такое изыскание остаётся практически не замеченным.
Извиняюсь за оффтоп.
Извиняюсь за оффтоп.
Интересно все, только непонятно зачем кластер? Для централизованного управления iSCSI/DRBD?
А клиенты в из всего этого что получают? Блочное устройство с одной точкой входа?
А клиенты в из всего этого что получают? Блочное устройство с одной точкой входа?
Чтобы иметь отказоустойчивое хранилище конечно, зачем же еще?
Клиенты подключаются к общим IP-адресам по iSCSI, которые в один момент времени подняты на одной из нод.
При отказе одной из нод всю работу берёт на себя вторая прозрачно для клиентов.
Клиенты подключаются к общим IP-адресам по iSCSI, которые в один момент времени подняты на одной из нод.
При отказе одной из нод всю работу берёт на себя вторая прозрачно для клиентов.
я реализовал по другому, имеем freebsd+zfs+carp и два идентичных сервера, все это дело работает как мастер слейв, при отвале мастера поднимается слейв, слей забирает с мастера снепшоты и накатывает себе храня дерево снепшотов, при назначение слейва мастером, накатка снепшотов прекращается, и можно в обратном порядке накатить.
Через ZFS send/receive?
Да еще и с сохранением дерева снапшотов? Боюсь производительность такого решения будет так себе.
И никакой репликации в реальном времени — в лучшем случае получим откат во времени до последнего снапшота.
На отказоустойчивое решения, в общем, не тянет.
Кстати, такой же функционал есть и в VMWare — vSphere Replication.
Да еще и с сохранением дерева снапшотов? Боюсь производительность такого решения будет так себе.
И никакой репликации в реальном времени — в лучшем случае получим откат во времени до последнего снапшота.
На отказоустойчивое решения, в общем, не тянет.
Кстати, такой же функционал есть и в VMWare — vSphere Replication.
Да через него, решение уже живет 2 года и прошло сбои, так я и не писал репликации в реальном времени.
Репликации разваливаются и вы получите сплит брейн,, что уже провал. Весь служебный трафик гоняется во внутренней сети порты объеденены в LACP.
Ваше решение вообще чревато, тестировали, потери на записи ужасные. Ни кеширования тебе не всех прелестей zfs собраного в raidz с кешем на ssd.
В тестовой группе был и zfs с использованием импорта, но на 18ТБ хранилище это утопия.
Репликации разваливаются и вы получите сплит брейн,, что уже провал. Весь служебный трафик гоняется во внутренней сети порты объеденены в LACP.
Ваше решение вообще чревато, тестировали, потери на записи ужасные. Ни кеширования тебе не всех прелестей zfs собраного в raidz с кешем на ssd.
В тестовой группе был и zfs с использованием импорта, но на 18ТБ хранилище это утопия.
Репликации разваливаются и вы получите сплит брейн,, что уже провал
Смелое утверждение, с чего ей разваливаться? У меня тоже уже 2 года живет и ничего, не развалилась. Чтобы получить сплитбрейн нужно, по сути, убить все почти все 10 интерфейсов и оба свича, что статистически почти невозможно. Если параноя — то STONITH + третья нода для особого мнения и кворума.
Ваше решение вообще чревато, тестировали, потери на записи ужасные.
Пруф? Мое тестирование показывает что скорость записи упирается в интерфейс репликации, который, если ее не хватает, можно сделать 10Гбит или вообще 40G Infiniband — никто не мешает.
Ни кеширования тебе не всех прелестей zfs собраного в raidz с кешем на ssd.
Та ви что? Кто мешает кешировать на SSD средствами рейд-контроллера (смотри LSI Cachecade)? Кто мешает кэшировать на SSD через ядро Linux используя bcache/dm-cache/flashcache на уровне ниже DRBD?
Я ZFS люблю всей душой (особенно за клоны-снапшоты и контрольные суммы), юзаю его дома, но по производительности он до обычных рейдов не дотягивает, плавали, знаем. А если отключить в нем все плюшки, снижающие производительность, то он получается ничем не лучше традиционных методов — чудес не бывает.
Я ZFS люблю всей душой (особенно за клоны-снапшоты и контрольные суммы), юзаю его дома, но по производительности он до обычных рейдов не дотягивает, плавали, знаем. А если отключить в нем все плюшки, снижающие производительность, то он получается ничем не лучше традиционных методов — чудес не бывает.
на 6Гб контролере прекрасно себя чувствует.
Приведите пожалуйста тесты вашего решения(запись, чтение, рендомная запись)
на 6Гб контролере прекрасно себя чувствует.
Приведите пожалуйста тесты вашего решения(запись, чтение, рендомная запись)
При чём тут контроллер совершенно не ясно, особенно в плане ZFS, которому контроллер вообще противопоказан.
Тестов ZFS у меня под рукой нет, могу погонять свободное пока хранилище с RAID10 массивами на LSI 9271, но там никаких сюрпризов, я думаю, не будет.
что вам не ясно?
Вы сами подумайте, прямое соединение или соединение через контроллер который может обрабатывать на «большой» скорости объемы данных.
Приведите хотя бы сравнительный синтетический тест, не dd. А допустим инсертом пару миллионов строк. Если Вам интересно могу свои данные привести. Меня начали минусовать просто так, забавно. Критика и свое мнение уже не приветствуется?
Вы сами подумайте, прямое соединение или соединение через контроллер который может обрабатывать на «большой» скорости объемы данных.
Приведите хотя бы сравнительный синтетический тест, не dd. А допустим инсертом пару миллионов строк. Если Вам интересно могу свои данные привести. Меня начали минусовать просто так, забавно. Критика и свое мнение уже не приветствуется?
что вам не ясно?
Вы сами подумайте, прямое соединение или соединение через контроллер который может обрабатывать на «большой» скорости объемы данных.
Дело в том, что ZFS сам себе RAID-контроллер и лишняя прослойка между ним и диском в виде аппаратного RAID-контроллера только увеличивает задержки. Лучший выбор для ZFS — это набортные SAS/SATA порты или HBA-адаптер без RAID-функционала.
И с какой это стати контроллер обрабатывает данные на «большой» скорости мне не ясно совсем. Скорее наоборот, он вносит задержки в поток данных.
Вот пару цитат из интернетов, если этот момент не очевиден:
Modern motherboards have onboard SATA ports. These are supplied by the chipset and should be regarded as the best possible SATA ports when doing software RAID like with ZFS.
Hardware RAID means ZFS cannot access the redundant information and has no knowledge about how the data is organised. The result: about half the features that make ZFS so cool would be vaporized if you opt for Hardware RAID. No more self-healing, useless copies=2 option and possibly unsafe writes if the Hardware RAID doesn't have a BBU and properly designed firmware that never exposes the disks to a condition in which a power failure at that moment would cause corruption. As far as ZFS goes, you have a single-disk RAID0 array.
© zfsguru.com/forum/buildingyourownzfsserver/21
Consequently, many ZFS and Linux MD RAID users, such as me, look for non-RAID controllers that are simply reliable, fast, cheap, and otherwise come with no bells and whistles. Most motherboards have up to 4 or 6 onboard ports (be sure to always enable AHCI mode in the BIOS as it is the best designed hardware interface that a chip can present to the OS to enable maximum performance)
(с) blog.zorinaq.com/?e=10
Приведите хотя бы сравнительный синтетический тест, не dd. А допустим инсертом пару миллионов строк. Если Вам интересно могу свои данные привести. Меня начали минусовать просто так, забавно. Критика и свое мнение уже не приветствуется?
Я могу потестировать через fio, но какой в этом смысл? Чтобы сравнивать показания нужно иметь идентичные с железной точки зрения системы, чтобы это сравнение было справедливым. Я могу потестировать бэкенд SCST_NULLIO безотносительно дисковой подсистемы, но тогда непонятно что мы меряем.
где я упоминал что использую рейд? мой контроллер не работает в режиме рейда, а всего лишь дает мне нужную скорость. Причем так включен как указано в одной из Ваших ссылок. Может вы просто не умеете готовить raidz? На сколько мне известно один из Российских cdn используют в таком же режиме как и я и выдерживают серьезные нагрузки.
Что мерить да операции в секунду что еще.
Я вам говорил приведи ВАши цифры по тестам своей системы, допустим подключите лун и туда базу разверните, допустим я тестировал развернул туда базу Диасофта, рядом с нагруженным луном разместил инкрементные бекапы postgres,
Что мерить да операции в секунду что еще.
Я вам говорил приведи ВАши цифры по тестам своей системы, допустим подключите лун и туда базу разверните, допустим я тестировал развернул туда базу Диасофта, рядом с нагруженным луном разместил инкрементные бекапы postgres,
где я упоминал что использую рейд? мой контроллер не работает в режиме рейда, а всего лишь дает мне нужную скорость
В чем разница между контроллером, «дающим нужную скорость» и просто прямым подключением дисков к контроллеру на материнской плате или еще где-то?
Может вы просто не умеете готовить raidz?
Может и не умею, тут есть какая-то секретная магия, поделитесь?
Что мерить да операции в секунду что еще.
Где? На скольки дисках? На 2, 5, 7, 10, 30? На каком уровне RAID? Или может на SSD? Какое отношение записи\чтения?
Неужели непонятно что факторов, влияющих на результат, очень много. У меня несколько разных хранилищ с разными дисковыми системами и разными технологиями подключения (iSCSI 1Gb/10Gb, FC) и результаты у всех очень разные.
raidz собран из 16 дисков по 2ТБ +1 диск для спера+кеши на двух ssd. Без дополнительного контроллера никак не обойтись и плюс дополнительные настройки. Вот так я готовлю zfs для продакшена.
Мерить именно на пуле zpool iostat. По поводу канала говорил же, видимо не внимательно читали гигабитные порты собранные в lacp.
Тем самым резервирую канал еще. Если вы используете zfs в linux тогда к Вам вопросов больше нет.
Мерить именно на пуле zpool iostat. По поводу канала говорил же, видимо не внимательно читали гигабитные порты собранные в lacp.
Тем самым резервирую канал еще. Если вы используете zfs в linux тогда к Вам вопросов больше нет.
Sign up to leave a comment.
Создание надёжного iSCSI-хранилища на Linux, часть 2