LINUX.ORG.RU
ФорумAdmin

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

 , ,


3

2

День добрый!

У меня такое дело, нужно поверх тестового Ceph сконструировать тестовый же отказоустойчивый iSCSI. Подскажите, как это делается в современном мире. В прочитанном обычно описываются drbd (ну это неважно) и два таргета, либо с heartbeat (устарел), либо с pacemaker+corosync. Вопросы возникли такие:

Если pacemaker, то его вроде надо сильно изучать и прикручивать проверки 'ресурсов', по которым он понимает, что его партнёр упал? Это затратно по времени? Это единственный механизм кластеризации, может, есть что-то нативное в самом iscsi? Максимальная производительность или очвысокая надёжность на время тестов мне не нужны, нужно просто посмотреть, что конструкция будет работать при гибели одного из таргетов.

Второе, неожиданно мало в этом контексте пишут про multipath. Это плохое решение? Чем чревато его использование вместо кластеризации?

★★★★

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

no-dashi ★★★★★ ()

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

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

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

blind_oracle ★★★★★ ()

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

blind_oracle ★★★★★ ()

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

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

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

будет

drbd

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

heartbeat (устарел)

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

axelroot ()
Ответ на: комментарий от axelroot

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

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

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

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

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

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

blind_oracle ★★★★★ ()

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

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

stave ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

ESXi

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

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

не заметил.

axelroot ()
Ответ на: комментарий от axelroot

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

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

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

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

не заметил.

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

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

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

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

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

axelroot ()
Ответ на: комментарий от axelroot

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

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

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

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

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

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

blind_oracle ★★★★★ ()
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

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

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

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

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

axelroot ()
Ответ на: комментарий от axelroot

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

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от stave

нативный ceph

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

muon ★★★★ ()
Ответ на: комментарий от stave

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

muon ★★★★ ()
Ответ на: комментарий от axelroot

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

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

muon ★★★★ ()
Ответ на: комментарий от muon

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

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

blind_oracle ★★★★★ ()
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от muon

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Бесплатный.

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

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

muon ★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

muon ★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

EvgGad_303 ★★★★★ ()
Ответ на: комментарий от muon

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

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от muon

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от EvgGad_303

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

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

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

EvgGad_303 ★★★★★ ()
Ответ на: комментарий от EvgGad_303

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

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

no-dashi ★★★★★ ()
Ответ на: комментарий от no-dashi

Эммм, 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).
blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

no-dashi ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

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

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

muon ★★★★ ()
Ответ на: комментарий от muon

Единицей управления в 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.

blind_oracle ★★★★★ ()
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

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

muon ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.