Отказоустойчивый iSCSI

multipath это решение на стороне инициатора

Если у тебя два-три таргета, то городить цеф смысла ну никакого нет, юзай дрбд9, там многое поменялось.

Плюс, iscsi / ceph та еще тормозная компания.

В итоге, если очень хочется - можно и multipath поднять, но как оно будет работать...

Делать с менеджером кластера имеет смысл только если делаешь active/passive или alua топологии. И учти что scsi резервации не будут с ноды на ноду реплицироваться.

отказоустойчивый iSCSI

бери два target-а с разных физических SAN-ов и объединяй их в зеркало raid1

будет работать при гибели одного из таргетов

будет

drbd

глючная штука

heartbeat (устарел)

но по прежнему прекрасно работает.

бери два target-а с разных физических SAN-ов и объединяй их в зеркало raid1

Угу, особенно учитывая что используя инициаторы вроде ESXi это в принципе невозможно.

глючная штука

Аргументы? У меня другие данные на основе многолетней эксплуатации.

но по прежнему прекрасно работает

Из двух спиц и буханки хлеба можно сделать троллейбус - но зачем? Если ты строишь решения, которые нужно поддерживать какое-то продолжительное время, то какой смысл юзать deprecated софт, в котором самому придётся решать проблемы? Да и удобство работы в pacemaker гораздо выше.

У нас так сделано(ceph-multipath iscsi), и если честно, то не очень. Все от того, что ксен не умеет нативный ceph.

А зачем вам вообще городить такой огород?

Аргументы? У меня другие данные на основе многолетней эксплуатации.

одно расщепление разума чего стоит.

ESXi

поделками VMware не пользуюсь.

удобство работы в pacemaker гораздо выше

не заметил.

одно расщепление разума чего стоит.

Чтобы добиться сплит-брейна нужно очень и очень захотеть выстрелить себе в ногу (не юзать фенсинг, убить все каналы связи). Я слабо себе представляю как это можно устроить. Да и в DRBD9 уже до 32 нод в кластере, сплит брейн получить стало ещё сложнее.

поделками VMware не пользуюсь.

Это не значит что стоит свои комплексы на других проецировать. Есть много тех, кто пользуется.

не заметил.

Да? А то что в хартбите кластер ограничен двумя нодами - это ок? Плюс:

No detection of resource-level failures
Resources organized into independent groups with a strictly linear start/stop order

Чтобы добиться сплит-брейна нужно очень и очень захотеть выстрелить себе в ногу

да запросто, выдергиваем шнурки из сетевух активной ноды и радуемся

ограничен двумя нодами

в курсе, более и не нужно в подавляющем числе задач.

Это не значит что стоит свои комплексы на других проецировать. Есть много тех, кто пользуется.

флаг им в руки, как бы тока лицуху не изменили на платную, а так все норм.

да запросто, выдергиваем шнурки из сетевух активной ноды и радуемся

Вот я и говорю про выстрелы в ногу.

При правильной архитектуре это не приведёт к split-brain - кластер убьёт эту ноду фенсингом (вырубит питание через PDU или IPMI, сработает self-fencing на ноде - она отключит все свои ресурсы при отсутствии связи с другими нодами, и так далее)

Так что не надо придумывать проблемы, которые, на самом деле, не существуют.

в курсе, более и не нужно в подавляющем числе задач.

Для нормальной работы нужен кворум. А кворум двумя нодами не сделаешь.

Так что не надо придумывать проблемы, которые, на самом деле, не существуют.

она есть и это факт.

не надо придумывать проблемы

т.е. что у drbd проблемы с мозгами это мои фантазии? эти проблемы есть и не надо их скрывать.

т.е. что у drbd проблемы с мозгами это мои фантазии?

Какие конкретно проблемы-то? Что если вынуть провода из ноды, то будет сплит-брейн? Это не у DRBD проблемы, а у того, кто криво спроектировал систему.

У *любого* кластера из двух нод при потере связности будет сплит-брейн, это, по-моему, очевидно.

нативный ceph

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

А зачем... Ну просто есть некоторое количество разных невостребованных дисков общим объёмом терабайт около 16, и я ничего интеререснее ceph-а не придумал. Цель у этого мероприятия - «пригодится в хозяйстве» (усилить файлопомойку, сделать ещё одно хранилище бэкапов, тестовые виртуалки...), поэтому нужно что-то универсальное типа iSCSI.

бери два target-а с разных физических SAN-ов и объединяй их в зеркало raid1

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

Если опенсурс - это не самоцель, то можно поставить EMC ScaleIO.

Он делает как раз то, что тебе нужно - берёт кучу серверов с локальными хранилками, объединяет их и экспортирует по iSCSI. Бесплатный.

Там не так всё сложно, у страха глаза велики. Я недавно ковырялся - всё достаточно прозрачно работает. С правами там сложнее, это всё таки распределённое объектное хранилище, а не ФС. Поэтому особых прав как таковых там вроде бы нет - толлько чтение и чтение\запись с какими-то вариациями.

Бесплатный.

Админка бесплатная?.. :) Вот Крок пишет:

Политика лицензирования ScaleIO — оплата только за сырую ёмкость.

распределённое объектное хранилище, а не ФС

Что это вообще, как с ним работать? Это же не файловая система (да и cephfs вроде не для продакшена ещё), и не блочное устройство. Как мне туда данные положить? Или для этого надо быть программистом и поддержку ceph запиливать прямо в прикладуху?

Для нормальной работы нужен кворум. А кворум двумя нодами не сделаешь.

А массив кворумом не может быть в хартбите?

Админка бесплатная?.. :) Вот Крок пишет:

Нет, вся бесплатная. Совсем. Пишут что вроде как «for non-production use», но на деле это означает что нет поддержки, а так - юзай сколько влезет:

EMC isn’t going to police this, but don’t expect us to provide support

Это хранилище неких абстрактных объектов (как диски - набор секторов). Из них можно собрать ФС, блочное устройство (через rados-rbd) и прочая.

Чтобы экспортировать часть CEPH по iSCSI нужно создать в нём образ (rbd image), подключить его на какой-либо ноде, имеющей доступ к Ceph (создастся /dev/rbdX) и уже его через iSCSI таргет отдавать. Работает всё это так себе, процессор грузит прилично.

Общее хранилище может быть Fencing-механизмом, но не может обеспечивать кворум. В любом случае, с DRBD хранилище на самом деле не общее, а реплицируемое, поэтому использовать его для Fencing-а не получится.

В любом случае, с DRBD хранилище на самом деле не общее, а реплицируемое, поэтому использовать его для Fencing-а не получится.

Ну это-то понятно.

Общее хранилище может быть Fencing-механизмом, но не может обеспечивать кворум.

Интересно из каких соображений. В наших степях обычное дело когда, в 2-нодовом кластере с массивом, отдельный lun является кворумом.

В наших степях обычное дело когда, в 2-нодовом кластере с массивом, отдельный lun является кворумом.

Технически, конечно, можно использовать общий лун для общения между нодами. Даже есть демон для этого - http://linux.die.net/man/5/qdisk Но в Pacemaker он, вроде бы, не поддерживается.

На деле я не видел чтобы кто-то его юзал. Фенсинга через LUN, по-моему, вполне достаточно.

это всё таки распределённое объектное хранилище, а не ФС

Эммм, mount -t ceph не работает? Это типа новость прямо вдруг внезапно.

Эммм, mount -t ceph не работает?

Не путай Ceph и CephFS. Ceph это general-purpose object storage. А CephFS уже работает поверх него и не является, по сути, самим Ceph. Внезапно, да.

The Ceph Filesystem (Ceph FS) is a POSIX-compliant filesystem that uses a Ceph Storage Cluster to store its data. The Ceph filesystem uses the same Ceph Storage Cluster system as Ceph Block Devices, Ceph Object Storage with its S3 and Swift APIs, or native bindings (librados).

Ну дык это понятно. Но с радосом ты все равно будешь работать из api, а у ТС такой задачи не стоит, ему надо либо блочный сторадж, с чем справится rbd, либо любая фс которая посиксосовместима и может быть расшарена любым способм, от ftp и до nfs или smb. А поскольку она посиксовая, то на ней он получит нормальный ugo*rwx, этого в большинстве случаев хватит

создать в нём образ (rbd image), подключить его на какой-либо ноде, имеющей доступ к Ceph (создастся /dev/rbdX) и уже его через iSCSI таргет отдавать

Вот у меня примерно такая же цепочка получилась, поэтому сабж.

Работает всё это так себе

Первые тесты ceph+iscsi у меня показали не оч, завтра заюзать cephfs, но даже если будет сильно лучше, в продакшен он не пойдёт, печаль. Но вроде простор для улучшательства есть.

Короче, если у тебя не овердофига нод, то юзай DRBD, цеф не для этого.

А оно умеет держать нужное количество реплик объекта, или всё реплицируется на всё?

Единицей управления в DRBD является реплицируемый диск (ресурс в их терминологии). Его ты, начиная с DRBD9, можешь реплицировать на 1-32 ноды в синхронном или асинхронном режимах.

То есть, если у тебя есть 3 сервера, то ты можешь завести, например, на каждом из них по три диска, которые будут иметь копии на двух других серверах в перекрёстном режиме.

То есть:

сервер1: диск1 оригинал. диск2 реплика1, диск3 реплика1.
сервер2: диск1 реплика1. диск2 оригинал, диск3 реплика2.
сервер3: диск1 реплика2. диск2 реплика2, диск3 оригинал.

Конечно, можно её вертеть как угодно - больше\меньше нод и дисков. Работает, по крайней мере DRBD8, очень стабильно - у меня было у серверов в кластере под два года аптайма без единого глюка.

Так что для небольшого количества серверов оно гораздо проще и быстрее Ceph, ибо работает оно целиком и полностью в ядре и напрямую с дисками минуя всякие абстракции вроде RBD.

Понятно, спасибо, внесу в планы. Пока всё-таки постараюсь ceph допинать, интересно всё-таки, а DRBD у меня уже был, только двухнодовый.

поверх тестового Ceph сконструировать тестовый же отказоустойчивый iSCSI

Линкусовый iSCSI-target сам умеет экспортировать Ceph: https://github.com/fujita/tgt/blob/master/doc/README.rbd