Создание надёжного iSCSI-хранилища на Linux, часть 2

  • Tutorial
Часть первая

Продолжаем


Продолжаем создание кластера, начатое первой части.
На этот раз я расскажу про настройку кластера.

В прошлый раз мы закончили на том, что началась синхронизация DRBD.
Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:
# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013-04-30 07:43:49
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны.

После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:
# drbdadm secondary VM_STORAGE_1
# drbdadm secondary VM_STORAGE_2

Pacemaker


Итак, менеджер кластера.

Если коротко, то это мозг всей системы, который управляет абстракциями, называемыми ресурсами.
Ресурсом кластера может быть, в принципе, что угодно: IP-адреса, файловые системы, DRBD-устройства, программы-службы и так далее. Довольно просто создать свой ресурс, что мне и пришлось сделать для управления iSCSI таргетами и LUN-ами, об этом далее.

Установим:
# apt-get install pacemaker

Corosync

Pacemaker использует инфраструктуру Corosync для взаимодействия между узлами кластера, поэтому для начала нужно будет настроить её.

Corosync имеет достаточно широкий функционал и несколько режимов для поддержки связи между нодами (unicast, multicast, broadcast), имеет поддержку RRP (Redundant Ring Protocol), которая позволяет использовать несколько разных путей для общения между нодами кластера для минимизации риска получить Split-brain, то есть ситуации, когда связь между нодами полностью пропадает, и они обе считают что сосед умер. В результате обе ноды переходят в рабочий режим и начинается хаос :)

Поэтому мы будем использовать как репликационный, так и внешний интерфейсы для обеспечения связности кластера.

Приступим к настройке

Для начала нужно сгенерировать ключ авторизации:
# corosync-keygen

Его нужно положить под именем /etc/corosync/authkey на оба сервера.

Далее создадим конфиг, он должен быть идентичен на обоих нодах:

/etc/corosync/corosync.conf
compatibility: none

totem {
    version: 2
    
    secauth: on
    threads: 3
    
    rrp_mode: active
    
    transport: udpu
    
    interface {
        member {
            memberaddr: 10.1.0.100
        }

        member {
            memberaddr: 10.1.0.200
        }

        ringnumber: 0
        bindnetaddr: 10.1.0.0
        mcastport: 5405
        ttl: 1
    }
    
    interface {
        member {
            memberaddr: 192.168.123.100
        }

        member {
            memberaddr: 192.168.123.200
        }

        ringnumber: 1
        bindnetaddr: 192.168.123.0
        mcastport: 5407
        ttl: 1
    }
}

amf {
    mode: disabled
}

service {
    ver:       1
    name:      pacemaker
}

aisexec {
    user:   root
    group:  root
}

logging {
    syslog_priority: warning
    
    fileline: off
    to_stderr: yes
    to_logfile: no
    to_syslog: yes
    syslog_facility: daemon
    debug: off
    timestamp: on
    
    logger_subsys {
        subsys: AMF
        debug: off
        tags: enter|leave|trace1|trace2|trace3|trace4|trace6
    }
}

Тут мы описываем два кольца для связи — внутреннее (через порты репликации) и внешнее (через коммутаторы), выбираем протокол udpu (UDP Unicast) и указываем IP-адреса нод в каждом кольце. У меня еще была идея соединить ноды нуль-модемным кабелем, поднять PPP-соединение и пустить через него третье кольцо, но здравый смысл вовремя подсказал что и так сойдёт.

Всё, можно запускать Pacemaker (он запустит Corosync предварительно).
# /etc/init.d/pacemaker start

Вся настройка Pacemaker происходит через утилиту crm, причем запускать её можно на любом сервере в кластере — он автоматически обновит конфигурацию на всех нодах после изменения.

Посмотрим текущий статус:
# crm status
============
Last updated: Mon Jan 20 15:33:29 2014
Last change: Fri Jan 17 18:30:48 2014 via cibadmin on server1
Stack: openais
Current DC: server1 - partition WITHOUT quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ server1 server2 ]

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

Теперь нам понадобятся ресурсы для управления SCST.
Я в свое время нашел их где-то на просторах интернета, модифицировал под свои нужды и выложил на Github.

Оттуда нам понадобятся два файла:
  • SCSTLun — управляет созданием устройств
  • SCSTTarget — управляет созданием iSCSI таргетов

Это, по сути, обычные bash-скрипты, реализующие несложный API Pacemaker.
Положить их следует в /usr/lib/ocf/resource.d/heartbeat, чтобы менеджер кластера их увидел.

Далее запускаем crm и входим в режим настройки:
# crm
crm(live)# configure
crm(live)configure# edit

Открывается текстовый редактор (обычно — nano) и можно приступить к описанию ресурсов и их взаимодействия.

Приведу пример конфигурации:
node server1
node server2

primitive DRBD_VM_STORAGE_1 ocf:linbit:drbd \
        params drbd_resource="VM_STORAGE_1" drbdconf="/etc/drbd.conf" \
        op monitor interval="29" role="Master" \
        op monitor interval="31" role="Slave"
primitive DRBD_VM_STORAGE_2 ocf:linbit:drbd \
        params drbd_resource="VM_STORAGE_2" drbdconf="/etc/drbd.conf" \
        op monitor interval="29" role="Master" \
        op monitor interval="31" role="Slave"

primitive IP_iSCSI_1_1 ocf:heartbeat:IPaddr2 \
        params ip="10.1.24.10" cidr_netmask="24" nic="int1.24" \
        op monitor interval="10s"
primitive IP_iSCSI_1_2 ocf:heartbeat:IPaddr2 \
        params ip="10.1.25.10" cidr_netmask="24" nic="int2.25" \
        op monitor interval="10s"
primitive IP_iSCSI_1_3 ocf:heartbeat:IPaddr2 \
        params ip="10.1.26.10" cidr_netmask="24" nic="int3.26" \
        op monitor interval="10s"
primitive IP_iSCSI_1_4 ocf:heartbeat:IPaddr2 \
        params ip="10.1.27.10" cidr_netmask="24" nic="int4.27" \
        op monitor interval="10s"
primitive IP_iSCSI_1_5 ocf:heartbeat:IPaddr2 \
        params ip="10.1.28.10" cidr_netmask="24" nic="int5.28" \
        op monitor interval="10s"
primitive IP_iSCSI_1_6 ocf:heartbeat:IPaddr2 \
        params ip="10.1.29.10" cidr_netmask="24" nic="int6.29" \
        op monitor interval="10s"

primitive IP_iSCSI_2_1 ocf:heartbeat:IPaddr2 \
        params ip="10.1.24.20" cidr_netmask="24" nic="int1.24" \
        op monitor interval="10s"
primitive IP_iSCSI_2_2 ocf:heartbeat:IPaddr2 \
        params ip="10.1.25.20" cidr_netmask="24" nic="int2.25" \
        op monitor interval="10s"
primitive IP_iSCSI_2_3 ocf:heartbeat:IPaddr2 \
        params ip="10.1.26.20" cidr_netmask="24" nic="int3.26" \
        op monitor interval="10s"
primitive IP_iSCSI_2_4 ocf:heartbeat:IPaddr2 \
        params ip="10.1.27.20" cidr_netmask="24" nic="int4.27" \
        op monitor interval="10s"
primitive IP_iSCSI_2_5 ocf:heartbeat:IPaddr2 \
        params ip="10.1.28.20" cidr_netmask="24" nic="int5.28" \
        op monitor interval="10s"
primitive IP_iSCSI_2_6 ocf:heartbeat:IPaddr2 \
        params ip="10.1.29.20" cidr_netmask="24" nic="int6.29" \
        op monitor interval="10s"

primitive ISCSI_LUN_VM_STORAGE_1 ocf:heartbeat:SCSTLun \
        params iqn="iqn.2011-04.ru.domain:VM_STORAGE_1" device_name="VM_STORAGE_1" \
        lun="0" path="/dev/drbd0" handler="vdisk_fileio"
primitive ISCSI_LUN_VM_STORAGE_2 ocf:heartbeat:SCSTLun \
        params iqn="iqn.2011-04.ru.domain:VM_STORAGE_2" device_name="VM_STORAGE_2" \
        lun="0" path="/dev/drbd1" handler="vdisk_fileio"

primitive ISCSI_TGT_VM_STORAGE_1 ocf:heartbeat:SCSTTarget \
        params iqn="iqn.2011-04.ru.domain:VM_STORAGE_1" \
        portals="10.1.24.10 10.1.25.10 10.1.26.10 10.1.27.10 10.1.28.10 10.1.29.10" \
        tgtoptions="InitialR2T=No ImmediateData=Yes MaxRecvDataSegmentLength=1048576 MaxXmitDataSegmentLength=1048576 MaxBurstLength=1048576 FirstBurstLength=524284 MaxOutstandingR2T=32 HeaderDigest=CRC32C DataDigest=CRC32C QueuedCommands=32 io_grouping_type=never" \
        op monitor interval="10s" timeout="60s"
primitive ISCSI_TGT_VM_STORAGE_2 ocf:heartbeat:SCSTTarget \
        params iqn="iqn.2011-04.ru.domain:VM_STORAGE_2" \
        portals="10.1.24.20 10.1.25.20 10.1.26.20 10.1.27.20 10.1.28.20 10.1.29.20" \
        tgtoptions="InitialR2T=No ImmediateData=Yes MaxRecvDataSegmentLength=1048576 MaxXmitDataSegmentLength=1048576 MaxBurstLength=1048576 FirstBurstLength=524284 MaxOutstandingR2T=32 HeaderDigest=CRC32C DataDigest=CRC32C QueuedCommands=32 io_grouping_type=never" \
        op monitor interval="10s" timeout="60s"

group GROUP_ISCSI_1 IP_iSCSI_1_1 IP_iSCSI_1_2 IP_iSCSI_1_3 IP_iSCSI_1_4 \
            IP_iSCSI_1_5 IP_iSCSI_1_6 ISCSI_TGT_VM_STORAGE_1 ISCSI_LUN_VM_STORAGE_1
group GROUP_ISCSI_2 IP_iSCSI_2_1 IP_iSCSI_2_2 IP_iSCSI_2_3 IP_iSCSI_2_4 \
            IP_iSCSI_2_5 IP_iSCSI_2_6 ISCSI_TGT_VM_STORAGE_2 ISCSI_LUN_VM_STORAGE_2

ms MS_DRBD_VM_STORAGE_1 DRBD_VM_STORAGE_1 \
        meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" \
        notify="true" target-role="Master"
ms MS_DRBD_VM_STORAGE_2 DRBD_VM_STORAGE_2 \
        meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" \
        notify="true" target-role="Master"

location PREFER-1 MS_DRBD_VM_STORAGE_1 50: server1
location PREFER-2 MS_DRBD_VM_STORAGE_2 50: server2

colocation COLOC_ALL_1 inf: GROUP_ISCSI_1 MS_DRBD_VM_STORAGE_1:Master
colocation COLOC_ALL_2 inf: GROUP_ISCSI_2 MS_DRBD_VM_STORAGE_2:Master

order ORDER_ALL_1 inf: MS_DRBD_VM_STORAGE_1:promote GROUP_ISCSI_1:start
order ORDER_ALL_2 inf: MS_DRBD_VM_STORAGE_2:promote GROUP_ISCSI_2:start

property $id="cib-bootstrap-options" \
        dc-version="1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff" \
        cluster-infrastructure="openais" \
        expected-quorum-votes="2" \
        stonith-enabled="false" \
        no-quorum-policy="ignore" \
        default-action-timeout="240" \
        last-lrm-refresh="1367942459"
rsc_defaults $id="rsc-options" \
        resource-stickiness="100"

Общие настройки кластера

Они находятся в самом низу. Из важных тут no-quorum-policy=«ignore» и expected-quorum-votes=«2» — у нас кластер из 2 серверов и кворума тут быть не может ну никак, поэтому игнорируем его.

Ресурсы

Обычно ресурс может иметь два состояния — включен или выключен, Started/Stopped.
Например, ocf:heartbeat:IPaddr2 поднимает на интерфейсах IP-адреса и снимает их, а также рассылает gratious arp для обновления arp-таблиц. Этому ресурсу мы указываем IP адрес, маску и интерфейс.

Еще есть специальные ресурсы, например DRBD (ocf:linbit:drbd), которые имеют режимы Master/Slave.
При переходе ноды в активный режим менеджер кластера будет переводить ресурс в режим мастер и наоборот. DRBD при этом будет переключаться из Secondary в Primary. Для него мы указываем имя ресурса и путь до конфига DRBD (наверное, его можно опустить, точно не помню).

Далее идут наши самописные ресурсы.
Для ocf:heartbeat:SCSTLun мы указываем IQN таргета, в который он будет добавлен, имя устройства, номер LUN-а (у таргета обязательно должен быть LUN 0, иначе у некоторых инициаторов сносит крышу), путь до экспортируемого устройства и обработчик (handler).

На обработчике нужно остановится подробнее — это способ, которым SCST будет работать с нашим устройством.

Из интересных это:
  • disk — по сути это просто прямой проброс SCSI команд от инициатора к SCSI устройству, самый простой режим, но работает только с реальными SCSI устройствами, нам не подходит, т.к. экспортируем DRBD-устройство
  • vdisk_blockio — открывает устройство как блочное, обходя page-cache операционной системы. Используется, если не нужно кэшировать ввод-вывод
  • vdisk_fileio — открывает устройство как файл, позволяя использовать page-cache операционной системы, самый производительный режим, его и выберем

У vdisk_fileio есть важный параметр, влияющий на скорость — nv_cache=1, он прописан жестко в SCSTLun.
Этот параметр говорит SCST игнорировать команды инициатора для сброса кэша на устройство. Потенциально, это может привести к потере данных в случае аварийного отключения хранилища т.к. инициатор будет думать, что данные на диске, а они еще в памяти. Так что используйте на свой страх и риск.

Далее идёт ресурс ocf:heartbeat:SCSTTarget, которому мы присваиваем IQN, portals — это список IP-адресов, через которые будет доступен этот таргет, tgtoptions — опции iSCSI, про них можно много где почитать.

Директивы, ответственные за поведение кластера при запуске и остановке ресурсов:
  • group объединяет ресурсы в группу для работы с ними как с единым целым. Ресурсы в группе запускаются последовательно
  • location указывает на какой ноде мы по умолчанию хотим видеть этот ресурс
  • colocation задает какие ресурсы должны находиться вместе на одной ноде
  • order сообщает менеджеру кластера порядок запуска ресурсов

После настройки ресурсов выходим из редактора и применяем изменения:
crm(live)configure# commit
crm(live)configure# exit

После этого можно посмотреть текущую ситуацию:
# crm status
============
Last updated: Mon Jan 20 17:04:04 2014
Last change: Thu Jul 25 13:59:27 2013 via crm_resource on server1
Stack: openais
Current DC: server1 - partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
20 Resources configured.
============

Online: [ server1 server2 ]

 Resource Group: GROUP_ISCSI_1
     IP_iSCSI_1_1       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_1_2       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_1_3       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_1_4       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_1_5       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_1_6       (ocf::heartbeat:IPaddr2):       Stopped
     ISCSI_TGT_VM_STORAGE_1    (ocf::heartbeat:SCSTTarget):    Stopped
     ISCSI_LUN_VM_STORAGE_1    (ocf::heartbeat:SCSTLun):       Stopped
 Resource Group: GROUP_ISCSI_2
     IP_iSCSI_2_1       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_2_2       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_2_3       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_2_4       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_2_5       (ocf::heartbeat:IPaddr2):       Stopped
     IP_iSCSI_2_6       (ocf::heartbeat:IPaddr2):       Stopped
     ISCSI_TGT_VM_STORAGE_2    (ocf::heartbeat:SCSTTarget):    Stopped
     ISCSI_LUN_VM_STORAGE_2    (ocf::heartbeat:SCSTLun):       Stopped
 Master/Slave Set: MS_DRBD_VM_STORAGE_1 [DRBD_VM_STORAGE_1]
     Slaves: [ server1 server2 ]
 Master/Slave Set: MS_DRBD_VM_STORAGE_2 [DRBD_VM_STORAGE_2]
     Slaves: [ server1 server2 ]

Мы видим, что ресурсы в неактивном состоянии, DRBD в режиме Slave (Secondary).

Теперь можно попробовать их активировать:
# crm resource start MS_DRBD_VM_STORAGE_1
# crm resource start MS_DRBD_VM_STORAGE_2

Стартуя этот ресурс мы вызываем в том числе и запуск других ресурсов т.к. они указаны у нас как зависимые (colocation), причем запускаться они будут в строго определенном порядке (order): сначала DRBD устройства перейдут в режим Primary, затем поднимутся IP-адреса, создадутся LUN-ы и в конце уже создадутся iSCSI таргеты.

Смотрим результат:
# crm status
============
Last updated: Tue Jan 21 11:54:46 2014
Last change: Thu Jul 25 13:59:27 2013 via crm_resource on server1
Stack: openais
Current DC: server1 - partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, 2 expected votes
20 Resources configured.
============

Online: [ server1 server2 ]

 Resource Group: GROUP_ISCSI_1
     IP_iSCSI_1_1       (ocf::heartbeat:IPaddr2):       Started server1
     IP_iSCSI_1_2       (ocf::heartbeat:IPaddr2):       Started server1
     IP_iSCSI_1_3       (ocf::heartbeat:IPaddr2):       Started server1
     IP_iSCSI_1_4       (ocf::heartbeat:IPaddr2):       Started server1
     IP_iSCSI_1_5       (ocf::heartbeat:IPaddr2):       Started server1
     IP_iSCSI_1_6       (ocf::heartbeat:IPaddr2):       Started server1
     ISCSI_TGT_VM_STORAGE_1    (ocf::heartbeat:SCSTTarget):    Started server1
     ISCSI_LUN_VM_STORAGE_1    (ocf::heartbeat:SCSTLun):       Started server1
 Resource Group: GROUP_ISCSI_2
     IP_iSCSI_2_1       (ocf::heartbeat:IPaddr2):       Started server2
     IP_iSCSI_2_2       (ocf::heartbeat:IPaddr2):       Started server2
     IP_iSCSI_2_3       (ocf::heartbeat:IPaddr2):       Started server2
     IP_iSCSI_2_4       (ocf::heartbeat:IPaddr2):       Started server2
     IP_iSCSI_2_5       (ocf::heartbeat:IPaddr2):       Started server2
     IP_iSCSI_2_6       (ocf::heartbeat:IPaddr2):       Started server2
     ISCSI_TGT_VM_STORAGE_2    (ocf::heartbeat:SCSTTarget):    Started server2
     ISCSI_LUN_VM_STORAGE_2    (ocf::heartbeat:SCSTLun):       Started server2
 Master/Slave Set: MS_DRBD_VM_STORAGE_1 [DRBD_VM_STORAGE_1]
     Masters: [ server1 ]
     Slaves: [ server2 ]
 Master/Slave Set: MS_DRBD_VM_STORAGE_2 [DRBD_VM_STORAGE_2]
     Masters: [ server2 ]
     Slaves: [ server1 ]

Если всё так, то можно себя поздравить — кластер запущен!
Каждая группа ресурсов запущена на своем сервере, как это указано в конфиге директивой location.

Для подтверждения можно посмотреть лог ядра — dmesg — туда DRBD и SCST выводят свою диагностику.

Конец второй части


В третьей, заключительной, части я покажу как настроить сервера ESXi на оптимальную работу с этим кластером.
Share post

Similar posts

Comments 21

    +3
    1.Это что же, отвал кластера фиксируется только если нода становится недоступной?

    Вы тесты проводили какие нибудь, типа kill -9 *drbd*?

    Нода то может жить, но не быть функциональной.

    В таких системах нужно делать проверку которая изменяет веса на основании — получилось записать что-то в хранилище или нет. Не получилось — правим вес, перетягиваем мастера на другую ноду.

    А у вас — вроде и ресурсы заведены, а проверка по шатдауну. Это как-то совсем круто.

    2. Были сбои/тесты с такой системой кроме выключения питания одной из нод?
    А переброс ip шника с ноды на ноду не заставляет ESXi вылетать по какому-нибудь таймауту? Там, насколько я помню большой довольно таймаут (в сравнении, конечно) прежде чем нода решает перетянуть на себя ресурсы если другая нода недоступна.
      +4
      1. У каждого нормального ресурса есть API-команда Monitor, которую Pacemaker использует для проверки состояния ресурса. Ее вызов активируется параметров monitor у ресурса, можно задать действие при ошибке. По умолчанию кластер рестартует ресурс, но можно поставить режим standby, который вызовет миграцию всех ресурсов со сбоящей ноды. Можно указать количество ошибок перезапуска, после которых пройдёт миграция.

      Перед запуском кластера я систему очень долго мучал, и стабильность софтовой части меня более чем устроила, поэтому я пока не стал активировать этот режим — если кому-то это нужно, то делается это в два счета.

      Вообще, у Pacemaker очень много возможностей — интересующиеся могут заглянуть в документацию, это не тема одной или даже нескольких статей.

      Что такое «проверка по шатдауну» не понял. Да, и drbd живет в ядре, его kill -9 не возьмешь.

      2. Какого рода тесты, например? Сеть выдёргивалась, питание одной из нод вырубалось, свитч один вырубался. Всё отрабатывало как надо.

      И еще, так как практически весь рабочий софт находится в ядре (SCST, DRBD), то его сбой приведёт к краху ядра (особенно если включить дополнительно panic_on_oops) и нода, по сути, будет мертва, что обнаружит вторая нода.

      Переброс IP-шника для ESXi проходит гладко, таймаут Corosync по умолчанию — 4 секунды, таймаут iSCSI в ESXi — 10 секунд.
      Так что всё проходит очень быстро и практически незаметно для ВМ.
        +1
        1. Хм. On-fail=standby? Когда я пробовал, — он работал совсем не так, как надо. Не помню правда что именно было не так. И предсказывать веса, то есть планировать работу кластера по весам — толком не получается. В итоге веса мы стали менять правилом которое смотрело на параметр для самодельного ocf ресурса.

        Вообще, конечно, тут скорее важен подход — ваш кластер предоставляет определенный сервис. И именно предоставление этого сервиса надо мониторить, лучше всего тем же паттерном (или максимально приближенным к нему) который используют пользователи этого сервиса. Для примера — если у вас там http сервер то нужно тягать страничку с кластерного ip адреса и проверять не изменился ли ее md5 хеш, например.

        Проверкой по shutdown — в данном контексте, это когда проверка работоспособности ресурсов кластера напрямую не производится, а считается, что ресурс всегда доступен — пока нода жива. Нода умерла — значит ресурс не доступен.

        К слову, в двухнодовой конфигурации так же хорошо бы настроить stonith. А лучше сделать третью ноду (в комментариях к предыдущей статье об этом писали), можно только с арбитром и кворумом — по всем канонам так бцдет верно.

        2. Смотрите, гипотетически, у вас отваливается DRBD на одной из нод.
        Во-первых, вполне возможно что вся pacemaker нода не уйдет в ребут по kernel panic сразу.
        Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?

        DRBD добавили таки в ядро? Ну надо же. Клёво.

        3. Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала? Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?

        Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.

        Вообще статья, супер, конечно, спасибо.
          0
          1. На данный момент он работает так, как написано в документации — если падает хоть один ресурс, то все ресурсы переезжают на запасную ноду.

          Я в общем-то и не предоставляю сервис — я делаю высокодоступное хранилище для своего же vSphere кластера, не более того.
          Я понимаю, что можно много чего навертеть и добавить еще пару девяток к доступности, но мне хватает и того, что есть :)

          А предоставление сервиса и все прочие параметры (состояние дисков, массивов, DRBD, сети и т.п.) у меня мониторятся отдельно Zabbix-ом и если что-то происходит не предусмотренное конфигом кластера, то я буду реагировать уже сам.

          Насчет STONITH я думал (на основе IPMI), но решил, что это избыточно.

          А третью witness-ноду да, смысл сделать имеет, только вот в Pacemaker нет простого сбособа добавить просто ноду-свидетеля.
          Можно сделать третьей ноде standby=on, но на ней должны быть все те же ресурсы (DRBD по крайней мере), т.к. кластер будет их пытаться мониторить. Второй способ — не запускать вообще Pacemaker, а оставить только Corosync, но я не уверен что это хорошая идея, нужно проверять. Но скорее всего этот способ самый оптимальный.

          2. Что значит — отваливается? Глюк в софте? Тогда ядро уйдёт в резет сразу, это настраивается в sysctl (kernel.panic)
          Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?

          А в чем проблема? Во всех распространенных ОСях таймаут на I/O к диску гораздо выше (в линуксе минута, в винде тоже вроде) и его всегда можно задрать при необходимости.
          Я специально делал виртуалку, которая во всю прыть писала на диск и убивал активную ноду по питанию — никакой ругани со стороны гостевой ОС не было, всё продолжало работать как надо.

          DRBD добавили таки в ядро? Ну надо же. Клёво.

          Да, добавили, но это ничего не меняет.
          Модулем оно или в ядро интегрировано — разницы с точки зрения работы никакой.
          Я, как видно, собираю его модулем т.к. в ядре более старая версия.

          3.
          Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала?
          Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?

          Нет, тьфу тьфу, всё работает пока чётко. Но перед продакшеном я, как писал выше, всякое симулировал и вело оно себя предсказуемо.

          Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.

          Я согласен, что в моей конфигурации не всё предусмотрено, но для конкретно моих требований этого более чем достаточно.
          И я постарался поведение кластера проверить во всех более или менее реальных ситуациях.
      +8
      Обидно, что какой нибудь пост об очередной, никчемной железке собирает толпы народу, а тут такое изыскание остаётся практически не замеченным.
      Извиняюсь за оффтоп.
        +3
        Ну, народу подавай хлеба, зрелищ, новых айфонов, побольше жаваскрипта на 30 строк и новую модную фенечку на CSS, ничего не поделаешь :)
          +1
          Удел любого узкоспециализированного поста, к сожалению. Аудитория существенно меньше, чем у телефонов, котиков и т. п. =)
            +2
            Эх, был бы что ли вес у голосов, для равновесия. Что бы для профильных хабов выше, для бесполезных постов ниже.
        –1
        Интересно все, только непонятно зачем кластер? Для централизованного управления iSCSI/DRBD?
        А клиенты в из всего этого что получают? Блочное устройство с одной точкой входа?
          0
          Чтобы иметь отказоустойчивое хранилище конечно, зачем же еще?

          Клиенты подключаются к общим IP-адресам по iSCSI, которые в один момент времени подняты на одной из нод.
          При отказе одной из нод всю работу берёт на себя вторая прозрачно для клиентов.
            0
            я реализовал по другому, имеем freebsd+zfs+carp и два идентичных сервера, все это дело работает как мастер слейв, при отвале мастера поднимается слейв, слей забирает с мастера снепшоты и накатывает себе храня дерево снепшотов, при назначение слейва мастером, накатка снепшотов прекращается, и можно в обратном порядке накатить.
              0
              Через ZFS send/receive?
              Да еще и с сохранением дерева снапшотов? Боюсь производительность такого решения будет так себе.
              И никакой репликации в реальном времени — в лучшем случае получим откат во времени до последнего снапшота.

              На отказоустойчивое решения, в общем, не тянет.

              Кстати, такой же функционал есть и в VMWare — vSphere Replication.
                –1
                Да через него, решение уже живет 2 года и прошло сбои, так я и не писал репликации в реальном времени.
                Репликации разваливаются и вы получите сплит брейн,, что уже провал. Весь служебный трафик гоняется во внутренней сети порты объеденены в LACP.

                Ваше решение вообще чревато, тестировали, потери на записи ужасные. Ни кеширования тебе не всех прелестей zfs собраного в raidz с кешем на ssd.

                В тестовой группе был и zfs с использованием импорта, но на 18ТБ хранилище это утопия.
              0
              Репликации разваливаются и вы получите сплит брейн,, что уже провал

              Смелое утверждение, с чего ей разваливаться? У меня тоже уже 2 года живет и ничего, не развалилась. Чтобы получить сплитбрейн нужно, по сути, убить все почти все 10 интерфейсов и оба свича, что статистически почти невозможно. Если параноя — то STONITH + третья нода для особого мнения и кворума.

              Ваше решение вообще чревато, тестировали, потери на записи ужасные.

              Пруф? Мое тестирование показывает что скорость записи упирается в интерфейс репликации, который, если ее не хватает, можно сделать 10Гбит или вообще 40G Infiniband — никто не мешает.

              Ни кеширования тебе не всех прелестей zfs собраного в raidz с кешем на ssd.

              Та ви что? Кто мешает кешировать на SSD средствами рейд-контроллера (смотри LSI Cachecade)? Кто мешает кэшировать на SSD через ядро Linux используя bcache/dm-cache/flashcache на уровне ниже DRBD?

              Я ZFS люблю всей душой (особенно за клоны-снапшоты и контрольные суммы), юзаю его дома, но по производительности он до обычных рейдов не дотягивает, плавали, знаем. А если отключить в нем все плюшки, снижающие производительность, то он получается ничем не лучше традиционных методов — чудес не бывает.
                –1
                Я ZFS люблю всей душой (особенно за клоны-снапшоты и контрольные суммы), юзаю его дома, но по производительности он до обычных рейдов не дотягивает, плавали, знаем. А если отключить в нем все плюшки, снижающие производительность, то он получается ничем не лучше традиционных методов — чудес не бывает.


                на 6Гб контролере прекрасно себя чувствует.
                Приведите пожалуйста тесты вашего решения(запись, чтение, рендомная запись)
                  0
                  на 6Гб контролере прекрасно себя чувствует.
                  Приведите пожалуйста тесты вашего решения(запись, чтение, рендомная запись)

                  При чём тут контроллер совершенно не ясно, особенно в плане ZFS, которому контроллер вообще противопоказан.

                  Тестов ZFS у меня под рукой нет, могу погонять свободное пока хранилище с RAID10 массивами на LSI 9271, но там никаких сюрпризов, я думаю, не будет.
                    –2
                    что вам не ясно?
                    Вы сами подумайте, прямое соединение или соединение через контроллер который может обрабатывать на «большой» скорости объемы данных.
                    Приведите хотя бы сравнительный синтетический тест, не dd. А допустим инсертом пару миллионов строк. Если Вам интересно могу свои данные привести. Меня начали минусовать просто так, забавно. Критика и свое мнение уже не приветствуется?
                  0
                  что вам не ясно?
                  Вы сами подумайте, прямое соединение или соединение через контроллер который может обрабатывать на «большой» скорости объемы данных.

                  Дело в том, что 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 безотносительно дисковой подсистемы, но тогда непонятно что мы меряем.
                    –1
                    где я упоминал что использую рейд? мой контроллер не работает в режиме рейда, а всего лишь дает мне нужную скорость. Причем так включен как указано в одной из Ваших ссылок. Может вы просто не умеете готовить raidz? На сколько мне известно один из Российских cdn используют в таком же режиме как и я и выдерживают серьезные нагрузки.
                    Что мерить да операции в секунду что еще.
                    Я вам говорил приведи ВАши цифры по тестам своей системы, допустим подключите лун и туда базу разверните, допустим я тестировал развернул туда базу Диасофта, рядом с нагруженным луном разместил инкрементные бекапы postgres,
                      +1
                      где я упоминал что использую рейд? мой контроллер не работает в режиме рейда, а всего лишь дает мне нужную скорость

                      В чем разница между контроллером, «дающим нужную скорость» и просто прямым подключением дисков к контроллеру на материнской плате или еще где-то?

                      Может вы просто не умеете готовить raidz?

                      Может и не умею, тут есть какая-то секретная магия, поделитесь?

                      Что мерить да операции в секунду что еще.

                      Где? На скольки дисках? На 2, 5, 7, 10, 30? На каком уровне RAID? Или может на SSD? Какое отношение записи\чтения?
                      Неужели непонятно что факторов, влияющих на результат, очень много. У меня несколько разных хранилищ с разными дисковыми системами и разными технологиями подключения (iSCSI 1Gb/10Gb, FC) и результаты у всех очень разные.
                        –1
                        raidz собран из 16 дисков по 2ТБ +1 диск для спера+кеши на двух ssd. Без дополнительного контроллера никак не обойтись и плюс дополнительные настройки. Вот так я готовлю zfs для продакшена.
                        Мерить именно на пуле zpool iostat. По поводу канала говорил же, видимо не внимательно читали гигабитные порты собранные в lacp.
                        Тем самым резервирую канал еще. Если вы используете zfs в linux тогда к Вам вопросов больше нет.

                  Only users with full accounts can post comments. Log in, please.