Вы анекдот-то прочитайте, осмыслите. Скоро будет — задержан человек с АППАРАТОМ, подозревается в изнасиловании.
Ну или шагнет техника чуть дальше — научатся со зрительного нерва картинку снимать, так и томографию будут делать прям перед входом в кинозал! Мало ли, имплант какой, на пару петабайт.
Защита авторских прав — это хорошо, но и для задержания должны быть веские основания, а не просто наличие аппарата. Так можно вообще кого угодно с мобильником задержать.
Немного похоже на рекламу, но интересно, спасибо!
Правда, я думаю, это в конечном итоге мало влияет на стратегию защиты данных — RAID+бэкап никто не отменял…
Презумпция невиновсности с каждым днём всё более и более призрачна.
Сразу вспоминается анекдот:
В селе менты ворвались в дом к деду, нашли самогонный аппарат, и начали деда допрашивать.
Менты: Ну че, дед, рассказывай сколько литров самогона в день у тебя выходит.
Дед: Да вы че, окозлели, я никогда в жизни самогонщиком не был.
Менты: Да ладно тебе, дед, мы ж тебя с поличным поймали. Все, будут тебя судить. У тебя ж в доме самогонный аппарат!
Дед: А, ну тогда и за изнасилование судите.
Менты: А ты че, изнасиловал кого-то?
Дед: Нет, но АППАРАТ ЖЕ ЕСТЬ!
где я упоминал что использую рейд? мой контроллер не работает в режиме рейда, а всего лишь дает мне нужную скорость
В чем разница между контроллером, «дающим нужную скорость» и просто прямым подключением дисков к контроллеру на материнской плате или еще где-то?
Может вы просто не умеете готовить raidz?
Может и не умею, тут есть какая-то секретная магия, поделитесь?
Что мерить да операции в секунду что еще.
Где? На скольки дисках? На 2, 5, 7, 10, 30? На каком уровне RAID? Или может на SSD? Какое отношение записи\чтения?
Неужели непонятно что факторов, влияющих на результат, очень много. У меня несколько разных хранилищ с разными дисковыми системами и разными технологиями подключения (iSCSI 1Gb/10Gb, FC) и результаты у всех очень разные.
что вам не ясно?
Вы сами подумайте, прямое соединение или соединение через контроллер который может обрабатывать на «большой» скорости объемы данных.
Дело в том, что 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.
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)
Приведите хотя бы сравнительный синтетический тест, не dd. А допустим инсертом пару миллионов строк. Если Вам интересно могу свои данные привести. Меня начали минусовать просто так, забавно. Критика и свое мнение уже не приветствуется?
Я могу потестировать через fio, но какой в этом смысл? Чтобы сравнивать показания нужно иметь идентичные с железной точки зрения системы, чтобы это сравнение было справедливым. Я могу потестировать бэкенд SCST_NULLIO безотносительно дисковой подсистемы, но тогда непонятно что мы меряем.
Репликации разваливаются и вы получите сплит брейн,, что уже провал
Смелое утверждение, с чего ей разваливаться? У меня тоже уже 2 года живет и ничего, не развалилась. Чтобы получить сплитбрейн нужно, по сути, убить все почти все 10 интерфейсов и оба свича, что статистически почти невозможно. Если параноя — то STONITH + третья нода для особого мнения и кворума.
Ваше решение вообще чревато, тестировали, потери на записи ужасные.
Пруф? Мое тестирование показывает что скорость записи упирается в интерфейс репликации, который, если ее не хватает, можно сделать 10Гбит или вообще 40G Infiniband — никто не мешает.
Ни кеширования тебе не всех прелестей zfs собраного в raidz с кешем на ssd.
Та ви что? Кто мешает кешировать на SSD средствами рейд-контроллера (смотри LSI Cachecade)? Кто мешает кэшировать на SSD через ядро Linux используя bcache/dm-cache/flashcache на уровне ниже DRBD?
Я ZFS люблю всей душой (особенно за клоны-снапшоты и контрольные суммы), юзаю его дома, но по производительности он до обычных рейдов не дотягивает, плавали, знаем. А если отключить в нем все плюшки, снижающие производительность, то он получается ничем не лучше традиционных методов — чудес не бывает.
Через ZFS send/receive?
Да еще и с сохранением дерева снапшотов? Боюсь производительность такого решения будет так себе.
И никакой репликации в реальном времени — в лучшем случае получим откат во времени до последнего снапшота.
На отказоустойчивое решения, в общем, не тянет.
Кстати, такой же функционал есть и в VMWare — vSphere Replication.
1. На данный момент он работает так, как написано в документации — если падает хоть один ресурс, то все ресурсы переезжают на запасную ноду.
Я в общем-то и не предоставляю сервис — я делаю высокодоступное хранилище для своего же vSphere кластера, не более того.
Я понимаю, что можно много чего навертеть и добавить еще пару девяток к доступности, но мне хватает и того, что есть :)
А предоставление сервиса и все прочие параметры (состояние дисков, массивов, DRBD, сети и т.п.) у меня мониторятся отдельно Zabbix-ом и если что-то происходит не предусмотренное конфигом кластера, то я буду реагировать уже сам.
Насчет STONITH я думал (на основе IPMI), но решил, что это избыточно.
А третью witness-ноду да, смысл сделать имеет, только вот в Pacemaker нет простого сбособа добавить просто ноду-свидетеля.
Можно сделать третьей ноде standby=on, но на ней должны быть все те же ресурсы (DRBD по крайней мере), т.к. кластер будет их пытаться мониторить. Второй способ — не запускать вообще Pacemaker, а оставить только Corosync, но я не уверен что это хорошая идея, нужно проверять. Но скорее всего этот способ самый оптимальный.
2. Что значит — отваливается? Глюк в софте? Тогда ядро уйдёт в резет сразу, это настраивается в sysctl (kernel.panic)
Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?
А в чем проблема? Во всех распространенных ОСях таймаут на I/O к диску гораздо выше (в линуксе минута, в винде тоже вроде) и его всегда можно задрать при необходимости.
Я специально делал виртуалку, которая во всю прыть писала на диск и убивал активную ноду по питанию — никакой ругани со стороны гостевой ОС не было, всё продолжало работать как надо.
DRBD добавили таки в ядро? Ну надо же. Клёво.
Да, добавили, но это ничего не меняет.
Модулем оно или в ядро интегрировано — разницы с точки зрения работы никакой.
Я, как видно, собираю его модулем т.к. в ядре более старая версия.
3.
Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала?
Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?
Нет, тьфу тьфу, всё работает пока чётко. Но перед продакшеном я, как писал выше, всякое симулировал и вело оно себя предсказуемо.
Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.
Я согласен, что в моей конфигурации не всё предусмотрено, но для конкретно моих требований этого более чем достаточно.
И я постарался поведение кластера проверить во всех более или менее реальных ситуациях.
Чтобы иметь отказоустойчивое хранилище конечно, зачем же еще?
Клиенты подключаются к общим IP-адресам по iSCSI, которые в один момент времени подняты на одной из нод.
При отказе одной из нод всю работу берёт на себя вторая прозрачно для клиентов.
1. У каждого нормального ресурса есть API-команда Monitor, которую Pacemaker использует для проверки состояния ресурса. Ее вызов активируется параметров monitor у ресурса, можно задать действие при ошибке. По умолчанию кластер рестартует ресурс, но можно поставить режим standby, который вызовет миграцию всех ресурсов со сбоящей ноды. Можно указать количество ошибок перезапуска, после которых пройдёт миграция.
Перед запуском кластера я систему очень долго мучал, и стабильность софтовой части меня более чем устроила, поэтому я пока не стал активировать этот режим — если кому-то это нужно, то делается это в два счета.
Вообще, у Pacemaker очень много возможностей — интересующиеся могут заглянуть в документацию, это не тема одной или даже нескольких статей.
Что такое «проверка по шатдауну» не понял. Да, и drbd живет в ядре, его kill -9 не возьмешь.
2. Какого рода тесты, например? Сеть выдёргивалась, питание одной из нод вырубалось, свитч один вырубался. Всё отрабатывало как надо.
И еще, так как практически весь рабочий софт находится в ядре (SCST, DRBD), то его сбой приведёт к краху ядра (особенно если включить дополнительно panic_on_oops) и нода, по сути, будет мертва, что обнаружит вторая нода.
Переброс IP-шника для ESXi проходит гладко, таймаут Corosync по умолчанию — 4 секунды, таймаут iSCSI в ESXi — 10 секунд.
Так что всё проходит очень быстро и практически незаметно для ВМ.
Если нет возможности что-то еще поднимать — то это системные проблемы в инфраструктуре.
«У меня в сети» много Powershell-скриптов, еще больше Bash- и Perl-скриптов и вообще чего только нет — для каждой задачи свое оптимальное решение. Я веду к тому, что проблемы нужно решать системно и если эта задача уже была давно кем-то решена, то лучше использовать готовое решение, а не писать костыли и велосипеды.
То есть, по-вашему, два собственноручно написаных скрипта являются более оттестированым решением, нежели очень давно и успешно используемый в продакшене продукт? Забавно
То, что бюджет заморозят — я могу представить.
А вот что мне может помешать вместо двух Win2008R2 поставить два Linux я представить не могу. Разве что самодурство начальства или отсутствие свободного железа. Учитывая что для DHCP сервера можно использовать абсолютной любой сервер или даже (свят-свят) десктоп, последнее видится маловероятным.
А можно не изобретать велосипед и установить пару виртуальных машин, а лучше — ВМ + физический сервер с каким-нибудь *nix и ISC DHCP Server, в котором уже встроен режим failover и отлично работает. Настраивается всё за полчаса вместе с установкой операционной системы. Дополнительный бонус — распределение нагрузки между нодами, они обе активны и обслуживают клиентов.
Ну или шагнет техника чуть дальше — научатся со зрительного нерва картинку снимать, так и томографию будут делать прям перед входом в кинозал! Мало ли, имплант какой, на пару петабайт.
Защита авторских прав — это хорошо, но и для задержания должны быть веские основания, а не просто наличие аппарата. Так можно вообще кого угодно с мобильником задержать.
Это мне сразу Сколково напомнило и прочие Роснано. «Только у нас смогли изобрести нанофотоны!»
Правда, я думаю, это в конечном итоге мало влияет на стратегию защиты данных — RAID+бэкап никто не отменял…
Сразу вспоминается анекдот:
В чем разница между контроллером, «дающим нужную скорость» и просто прямым подключением дисков к контроллеру на материнской плате или еще где-то?
Может и не умею, тут есть какая-то секретная магия, поделитесь?
Где? На скольки дисках? На 2, 5, 7, 10, 30? На каком уровне RAID? Или может на SSD? Какое отношение записи\чтения?
Неужели непонятно что факторов, влияющих на результат, очень много. У меня несколько разных хранилищ с разными дисковыми системами и разными технологиями подключения (iSCSI 1Gb/10Gb, FC) и результаты у всех очень разные.
Дело в том, что ZFS сам себе RAID-контроллер и лишняя прослойка между ним и диском в виде аппаратного RAID-контроллера только увеличивает задержки. Лучший выбор для ZFS — это набортные SAS/SATA порты или HBA-адаптер без RAID-функционала.
И с какой это стати контроллер обрабатывает данные на «большой» скорости мне не ясно совсем. Скорее наоборот, он вносит задержки в поток данных.
Вот пару цитат из интернетов, если этот момент не очевиден:
© zfsguru.com/forum/buildingyourownzfsserver/21
(с) blog.zorinaq.com/?e=10
Я могу потестировать через fio, но какой в этом смысл? Чтобы сравнивать показания нужно иметь идентичные с железной точки зрения системы, чтобы это сравнение было справедливым. Я могу потестировать бэкенд SCST_NULLIO безотносительно дисковой подсистемы, но тогда непонятно что мы меряем.
При чём тут контроллер совершенно не ясно, особенно в плане ZFS, которому контроллер вообще противопоказан.
Тестов ZFS у меня под рукой нет, могу погонять свободное пока хранилище с RAID10 массивами на LSI 9271, но там никаких сюрпризов, я думаю, не будет.
Смелое утверждение, с чего ей разваливаться? У меня тоже уже 2 года живет и ничего, не развалилась. Чтобы получить сплитбрейн нужно, по сути, убить все почти все 10 интерфейсов и оба свича, что статистически почти невозможно. Если параноя — то STONITH + третья нода для особого мнения и кворума.
Пруф? Мое тестирование показывает что скорость записи упирается в интерфейс репликации, который, если ее не хватает, можно сделать 10Гбит или вообще 40G Infiniband — никто не мешает.
Та ви что? Кто мешает кешировать на SSD средствами рейд-контроллера (смотри LSI Cachecade)? Кто мешает кэшировать на SSD через ядро Linux используя bcache/dm-cache/flashcache на уровне ниже DRBD?
Я ZFS люблю всей душой (особенно за клоны-снапшоты и контрольные суммы), юзаю его дома, но по производительности он до обычных рейдов не дотягивает, плавали, знаем. А если отключить в нем все плюшки, снижающие производительность, то он получается ничем не лучше традиционных методов — чудес не бывает.
Да еще и с сохранением дерева снапшотов? Боюсь производительность такого решения будет так себе.
И никакой репликации в реальном времени — в лучшем случае получим откат во времени до последнего снапшота.
На отказоустойчивое решения, в общем, не тянет.
Кстати, такой же функционал есть и в VMWare — vSphere Replication.
Я в общем-то и не предоставляю сервис — я делаю высокодоступное хранилище для своего же vSphere кластера, не более того.
Я понимаю, что можно много чего навертеть и добавить еще пару девяток к доступности, но мне хватает и того, что есть :)
А предоставление сервиса и все прочие параметры (состояние дисков, массивов, DRBD, сети и т.п.) у меня мониторятся отдельно Zabbix-ом и если что-то происходит не предусмотренное конфигом кластера, то я буду реагировать уже сам.
Насчет STONITH я думал (на основе IPMI), но решил, что это избыточно.
А третью witness-ноду да, смысл сделать имеет, только вот в Pacemaker нет простого сбособа добавить просто ноду-свидетеля.
Можно сделать третьей ноде standby=on, но на ней должны быть все те же ресурсы (DRBD по крайней мере), т.к. кластер будет их пытаться мониторить. Второй способ — не запускать вообще Pacemaker, а оставить только Corosync, но я не уверен что это хорошая идея, нужно проверять. Но скорее всего этот способ самый оптимальный.
2. Что значит — отваливается? Глюк в софте? Тогда ядро уйдёт в резет сразу, это настраивается в sysctl (kernel.panic)
А в чем проблема? Во всех распространенных ОСях таймаут на I/O к диску гораздо выше (в линуксе минута, в винде тоже вроде) и его всегда можно задрать при необходимости.
Я специально делал виртуалку, которая во всю прыть писала на диск и убивал активную ноду по питанию — никакой ругани со стороны гостевой ОС не было, всё продолжало работать как надо.
Да, добавили, но это ничего не меняет.
Модулем оно или в ядро интегрировано — разницы с точки зрения работы никакой.
Я, как видно, собираю его модулем т.к. в ядре более старая версия.
3.
Нет, тьфу тьфу, всё работает пока чётко. Но перед продакшеном я, как писал выше, всякое симулировал и вело оно себя предсказуемо.
Я согласен, что в моей конфигурации не всё предусмотрено, но для конкретно моих требований этого более чем достаточно.
И я постарался поведение кластера проверить во всех более или менее реальных ситуациях.
Клиенты подключаются к общим IP-адресам по iSCSI, которые в один момент времени подняты на одной из нод.
При отказе одной из нод всю работу берёт на себя вторая прозрачно для клиентов.
Перед запуском кластера я систему очень долго мучал, и стабильность софтовой части меня более чем устроила, поэтому я пока не стал активировать этот режим — если кому-то это нужно, то делается это в два счета.
Вообще, у Pacemaker очень много возможностей — интересующиеся могут заглянуть в документацию, это не тема одной или даже нескольких статей.
Что такое «проверка по шатдауну» не понял. Да, и drbd живет в ядре, его kill -9 не возьмешь.
2. Какого рода тесты, например? Сеть выдёргивалась, питание одной из нод вырубалось, свитч один вырубался. Всё отрабатывало как надо.
И еще, так как практически весь рабочий софт находится в ядре (SCST, DRBD), то его сбой приведёт к краху ядра (особенно если включить дополнительно panic_on_oops) и нода, по сути, будет мертва, что обнаружит вторая нода.
Переброс IP-шника для ESXi проходит гладко, таймаут Corosync по умолчанию — 4 секунды, таймаут iSCSI в ESXi — 10 секунд.
Так что всё проходит очень быстро и практически незаметно для ВМ.
«У меня в сети» много Powershell-скриптов, еще больше Bash- и Perl-скриптов и вообще чего только нет — для каждой задачи свое оптимальное решение. Я веду к тому, что проблемы нужно решать системно и если эта задача уже была давно кем-то решена, то лучше использовать готовое решение, а не писать костыли и велосипеды.
Если для общего развития — я только за.
А вот что мне может помешать вместо двух Win2008R2 поставить два Linux я представить не могу. Разве что самодурство начальства или отсутствие свободного железа. Учитывая что для DHCP сервера можно использовать абсолютной любой сервер или даже (свят-свят) десктоп, последнее видится маловероятным.