Создание Надежного Хранилища Iscsi В Linux, Часть 2

Первая часть



Давай продолжим

Продолжаем создание начатого кластера первая часть .

На этот раз я расскажу о настройке кластера.

В прошлый раз мы закончили запуском синхронизации DRBD. Если мы выбрали один и тот же сервер в качестве Основного для обоих ресурсов, то после завершения синхронизации необходимо /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 , что означает, что как локальная, так и удаленная копии являются текущими.

После этого переведем ресурсы во вторичный режим — тогда ими будет управлять кластер:

# drbdadm secondary VM_STORAGE_1 # drbdadm secondary VM_STORAGE_2



Кардиостимулятор

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

Короче говоря, это мозг всей системы, который управляет абстракциями, называемыми ресурсами.

Ресурсом кластера в принципе может быть что угодно: IP-адреса, файловые системы, DRBD-устройства, сервисные программы и так далее.

Создать собственный ресурс довольно легко, именно это мне и пришлось сделать для управления целями iSCSI и LUN, подробнее об этом позже.

Давайте установим:

# apt-get install pacemaker



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

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

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

Приступим к настройке Сначала вам необходимо сгенерировать ключ авторизации:

# corosync-keygen

Его нужно поставить под названием /etc/corosync/ключ аутентификации на оба сервера.

Далее создадим конфиг, он должен быть одинаковым на обеих нодах: /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 } }

Здесь описываем два кольца для связи - внутреннее (через порты репликации) и внешнее (через свитчи), выбираем протокол удпу (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. В свое время я нашел их где-то в Интернете, доработал под свои нужды и выложил на Гитхаб .

Отсюда нам понадобятся два файла:

  • 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="игнорировать" И ожидаемые-кворум-голоса = "2" — у нас кластер из 2-х серверов и кворума здесь быть не может, поэтому игнорируем его.

Ресурсы Обычно ресурс может иметь два состояния — включено или выключено, запущено/остановлено.

Например, ocf:heartbeat:IPaddr2 поднимает и удаляет IP-адреса на интерфейсах, а также отправляет бесплатный ARP для обновления таблиц ARP. Указываем IP-адрес, маску и интерфейс для этого ресурса.

Также есть специальные ресурсы, например DRBD ( ocf:linbit:drbd ), которые имеют режимы Главный/Подчиненный .

Когда узел переходит в активный режим, менеджер кластера переводит ресурс в режим мастера и наоборот. DRBD переключится со вторичного на первичный.

Для него указываем имя ресурса и путь к конфигу DRBD (наверное можно не указывать, точно не помню).

Далее идут наши самописные ресурсы.

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

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

Среди интересных:

  • диск - по сути это просто прямая переадресация SCSI-команд от инициатора к SCSI-устройству, самый простой режим, но он работает только с реальными SCSI-устройствами, нам он не подходит, т.к.

    экспорт DRBD-устройства

  • vdisk_blockio — открывает устройство как блочное, минуя страничный кэш операционной системы.

    Используется, если вам не нужно кэшировать ввод-вывод.

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

Этот параметр указывает SCST игнорировать команды инициатора для очистки кэша на устройстве.

Потенциально это может привести к потере данных в случае сбоя хранилища, потому что.

инициатор будет думать, что данные находятся на диске, но они все еще находятся в памяти.

Так что используйте на свой страх и риск.

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

Директивы, отвечающие за поведение кластера при запуске и остановке ресурсов:

  • группа объединяет ресурсы в группу для работы с ними как с единым целым.

    Ресурсы в группе запускаются последовательно

  • расположение указывает, на каком узле мы хотим видеть этот ресурс по умолчанию
  • колокейшн указывает, какие ресурсы должны быть расположены вместе на одном узле
  • заказ сообщает менеджеру кластера порядок запуска ресурсов
После настройки ресурсов выйдите из редактора и примените изменения:

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

Запуская этот ресурс, мы также вызываем запуск других ресурсов, поскольку они указаны как зависимые ( колокейшн ), и они будут запускаться в строго определенном порядке ( заказ ): сначала устройства DRBD перейдут в основной режим, затем будут повышены 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 ]

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

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



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

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

Теги: #linux #*nix #Хранилище данных #Виртуализация #vmware #Хранилище данных #Конфигурация Linux #Target #vsphere #DRBD #iscsi #fault #SCST #tolerance #tolerance

Вместе с данным постом часто просматривают: