Основы облачного хранилища данных Ceph. Часть 2. Установка кластера

My next article about Ceph published in Russian magazine Samag 12/2015, pp 07-11. The hands-on guide to installation of Ceph cluster with ceph-deploy and manual. The third article in January issue will discuss OpenStack integration. The announcement is here http://samag.ru/archive/article/3084

Советы по оптимизации производительности

С удовольствием читаю интересный технический блог «about NetApp», в основном посвященный софтверной компании NetApp. На днях там появилась заметка с рекомендациями по оптимизации производительности, которые равно применимы к любой ИТ-системе. Хотя казалось бы советы очевидны, нередко ими пренебрегают что вызывает только деградацию производительности. Читаем тут.

Работа с образами дисков виртуальных машин через libguestfs

В Fedora 11 включен ряд инструментов, значительно упрощающих работу с образами дисков виртуальных машин из операционной системы хоста. Утилиты, разработанные в рамках libguestfs, используют код ядра Linux и qemu и, соответственно, позволяют получить доступ к файловым системам, с которыми умеют работать Linux и qemu, включая ext2/3/4, btrfs, FAT, NTFS, тома LVM и различные варианты схем хранения разделов Virtual Machine DisK format (vmdk) и qcow1/2. Также библиотека корректно работает с метками SELinux.

Для установки в Fedora 11, Rawhide или RHEL, использующем репозиторий EPEL, необходимо набрать команду:

yum install '*guestfs*' guestfish

Библиотека и утилиты распространяются по лицензии GNU GPL. Есть сборки и для других дистрибутивов, включая Debian.

guestfish - интерактивный командный интерпретатор, работающий с гостевой файловой системой. Включает в себя более двух сотен команд для работы с файлами, каталогами и файловой системой. Полностью задействует всю функциональность guestfs API.

virt-cat - Просмотр файла внутри ФС гостя

virt-edit - Редактирование файла внутри ФС гостя

virt-rescue - Аналог rescue mode при загрузке с установочного диска Fedora/RHEL. Во время использования гостевая ВМ должна быть выключена.

virt-inspector - Отображает версию ОС, ядра, драйвера, точки монтирования, приложения и другую информацию о виртуальной машине. Для доступа к информации ВМ Windows используется reged.

virt-df - Отображает объем свободного места на ФС ВМ

В разработке находятся и другие утилиты, например, v2v-snapshot - создает snapshot дисков ВМ или virt-v2v для конвертации ВМ из других гипервизоров в KVM c libvirt.

На страничке приведен ряд примеров скриптов, использующих libguestfs, например: клонирования виртуальных машин, экспорта домашнего каталога пользователя ВМ в архив tar, список RPM-пакетов внутри ВМ, список устройств, разделов и слоев абстракции LVM, и другие.

Упрощенная настройка iSCSI target при помощи targets.conf

Около года назад я писал в блоге про настройку iSCSI target и initiator в RHEL5. Начиная с версии 5.3 настройка target значительно упростилась. Теперь не нужно прописывать несколько команд tgtadm в /etc/rc.local, а достаточно создать файл /etc/tgt/targets.conf вида:

<target iqn.2003-12.net.markelov:disk1>
backing-store /dev/xvda5
</target>

и запустить tgtd. Подробнее — в man tgt-admin.

Приоритет ввода/вывода процесса и ionice

В планировщике ввода/вывода CFQ (подробнее о планировщиках ввода/вывода можно почитать тут), который используется по умолчанию, начиная с ядра версии 2.6.18 (кстати, в последнем издании Understanding the Linux Kernel описано ядро 2.6.11, и там в соответствующей главе пишут про упреждающий конвейер - Anticipatory) есть интересная возможность вручную присваивать приоритет ввода/вывода конкретному процессу. На практике эти манипуляции осуществляются при помощи утилиты ionice.

Можно задать три класса ввода/вывода:

3. Idle - получает доступ к диску только тогда, когда другие процессы не требуют ввода/вывода. При "нормальной" работе системы такой процесс не должен испытывать проблем с производительностью.

2. Best effort - класс "по умолчанию". Для вычисления приоритета ввода/вывода используется соответствующее значение nice планировщика ЦП для этого процесса. Таким образом, при помощи команд nice и renice вы, помимо косвенного изменения приоритета процесса в планировщике ЦП, косвенно же влияете на планировщик ввода/вывода.

1. Real time - процессы с этим классом имеют приоритетный доступ к жесткому диску вне зависимости от того, что происходит в системе. Вместе с классом 1 как и с классом 2 можно передать и параметр-приоритет (0-7).

Первое, что приходит в голову глядя на классы - запуск некоторых задач в cron с пониженным приоритетом ionice -c3. Приоритет наследуется от родительского процесса, таким образом, все, что вы напишете после

#!/bin/bash
ionice -c3 -p$$

будет работать с приоритетом ввода/вывода Idle. Видимо, наилучшего прироста производительности можно добиться экспериментируя с ionice, когда вы вынуждены запускать одновременно несколько процессов с разными требованиями к дисковой подсистеме.

Подробнее:

• man-страница ionice(1)
• /usr/share/doc/kernel-doc-*/Documentation/block/ioprio.txt
  

Хотя не существует однозначного ответа на вопрос "Какой планировщик лучше?", и каждый раз необходимо тестировать конкретное приложение/систему, в общем случае ionice и конвейер CFQ не стоит применять для работы с /dev/xvdX в виртуальных машинах, где рекомендуется использовать планировщик NOOP, предоставив заботиться о планировании операций ввода/вывода Dom0. Для этого нужно добавить elevator=noop в строку параметров ядра grub:

title Red Hat Enterprise Linux Server (2.6.18-53.el5xen)
root (hd0,0)
kernel /vmlinuz-2.6.18-53.el5xen ro root=/dev/vol0/root rhgb quiet elevator=noop
initrd /initrd-2.6.18-53.el5xen.img

В итоге:

[root@vm02 ~]# dmesg | grep schedule
io scheduler noop registered (default)
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered

Впрочем, если вы помимо виртуальных дисков работаете с внешним хранилищем, где оптимальнее использовать планировщик "по умолчанию", то можно обойтись и /etc/rc.d/rc.local, меняя планировщик на уровне устройства:

echo noop > /sys/block/xvdX/queue/scheduler

I am RHCDS

Пришли результаты EX436, а вместе с ними сертификат Red Hat Certified Datacenter Specialist :) До RHCA остался всего один экзамен, но это уже на следующий год. :)

Построение HA-кластера с использованием RHCS и GFS в RHEL 5

Цель поста - продемонстрировать создание тестовой конфигурации кластера высокой доступности с использованием Red Hat Cluster Suite и кластерной файловой системы Global File System.

При создании HA-кластера используем следующее ПО/технологии. Все они являются полностью открытыми и для них доступен исходный код:

- Red Hat Enterprise Linux Advanced Platform 5.1
-- Red Hat Cluster Suite (в том числе web-интерфейс Conga, qdiskd и clvmd);
-- Global File System;
-- udev.

Вместо RHEL можно использовать CentOS, Scientific Linux и другие подобные.

Для создания демо-стенда использовались два физических сервера с внешним дисковым массивом, подключенным через FC, и одна управляющая станция, на которой была установлена web-консоль luci (проект Conga). Данная конфигурация избыточна, и все эти шаги можно повторить с использованием одного физического сервера, предоставляющего доступ к разделу по iSCSI двум виртуальным машинам, которые работают на том же сервере. В этом случае luci также можно было бы запускать на хост-системе или, в зависимости от числа доступных ресурсов, на сервере "поднять" третью виртуальную машину. Использование физических серверов критично в случае, если вы в качестве серверного ресурса планируете запускать виртуальные машины - HA + "живая миграция" (т.е. примерно то, что обеспечивает VMWareHA, и чего ждем в Windows Server 2008 R2). В этом случае рекомендую помимо официальной документации Red Hat ознакомиться со статьей в Red Hat Magazine и workaround на тему живой миграции виртуальных машин, описанном в блоге Андрея Мартынова.

Важно. Хотя, по информации, приведенной в этом посте, можно повторить все шаги и по аналогии настроить свой кластер, но информации будет явно не достаточно для понимания всех деталей работы, команд и планирования развертывания кластера. Для дальнейшего изучения материала рекомендую обратиться к официальной документации Red Hat, свободно доступной на сайте Red Hat как в виде PDF, так и HTML. Пост в блоге не заменяет чтения сотен страниц документации. Также нужно заметить, что решение задействовать GFS и использование кластера именно из двух узлов не является необходимым/оптимальным решением для рассмотренной задачи (отказоустойчивый web-сервер). Решение продиктовано желанием продемонстрировать использование большего числа технологий (GFS и кворумный диск). Более того, использование web-сервера как кластерной службы выбрано исключительно для демонстрации и из-за простоты базовой настройки. Для достижения результата в каждом конкретном шаге также, как правило, возможно воспользоваться разными инструментами: system-config-cluster, Conga или командная строка.

Создаем кластер, используя web-интерфейс (проект Conga)

Наиболее простой способ создать кластер - использовать Conga. Также стоит использовать данный интерфейс, когда мы хотим управлять из одной точки несколькими кластерами. Для того чтобы избежать некоторых "шероховатостей" в дальнейшем, убедимся, что на всех кластерах в /etc/hosts имя узла не присутствует в одной строчке с localhost, как это прописывает по умолчанию Anaconda. Кроме того, для независимости кластера от работы службы DNS лучше всего также прописать в hosts все остальные узлы и машину, где будет установлена luci. Кроме того, предполагается, что всем машинам доступны группы Cluster и Cluster Storage через RHN, Satellite или локальный репозиторий.

На управляющей станции устанавливаем web-консоль:

[root@server1 ~]# yum -y install luci
[root@server1 ~]# luci_admin init

Задаем пароль администратора luci.

[root@server1 ~]# service luci restart
Shutting down luci: [ OK ]
Starting luci: [ OK ]

Point your web browser to https://server1.example.com:8084 to access luci

А на обоих узлах кластера агента, который работает в паре c luci:

[root@node1 ~]# yum -y install ricci
[root@node1 ~]# service ricci restart; chkconfig ricci on

Теперь можно как нам и предложили зайти в web-интерфейс server1.example.com:8084. Со вкладки Clucter выбираем создание нового кластера:

После нажатия кнопки Submit узлы кластера скачивают и устанавливают соответствующие пакеты. По окончании процесса мы должны увидеть такую картину:

Настраиваем постоянные имена для разделов на дисковом массиве

Данный шаг необходим в ряде случаев, например, когда мы не можем гарантировать, что после перезагрузки каждый раздел будет иметь то же имя, что и перед прошлым циклом перезагрузки (iSCSI), или, например, в случае различного числа дисков на узлах кластера, когда один и тот же LUN будет выглядеть на узлах по-разному:

[root@node1 ~]# fdisk -l
...
Disk /dev/sdc: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 13 104391 83 Linux
...
[root@node2 ~]# fdisk -l
...
Disk /dev/sdd: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdd1 1 13 104391 83 Linux
...

В первом случае наш рабочий LUN на массиве - это sdc, а во втором - sdd. Данную проблему можно решить при помощи правила udev. В качестве альтернативы при использовании LVM и ext3 можно было бы воспользоваться UUID или метками ФС. Однако, правило udev более универсально.

Получим идентификатор нашего рабочего диска:

[root@node2 ~]# scsi_id -g -s /block/sdd
3600805f3001d3200a1e3ff9f259f0003

На каждом из узлов напишем правило udev (за подробностями - к документации):

[root@node1 ~]# cat /etc/udev/rules.d/75-custom.rules
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -s %p",RESULT=="3600805f3001d3200a1e3ff9f259f0003", SYMLINK+="mydata%n"

В итоге на обоих узлах получаем картину:

[root@node1 ~]# ls -l /dev/my*
lrwxrwxrwx 1 root root 3 Dec 2 12:54 /dev/mydata -> sdc
lrwxrwxrwx 1 root root 4 Dec 2 12:54 /dev/mydata1 -> sdc1

[root@node2 ~]# ls -l /dev/my*
lrwxrwxrwx 1 root root 3 Aug 1 13:58 /dev/mydata -> sdd
lrwxrwxrwx 1 root root 4 Aug 1 13:58 /dev/mydata1 -> sdd1

Еще один вариант - это воспользоваться стандартно создаваемыми симлинками в /dev/disk/by-id/.

Fencing

В Red Hat Cluster Suite поддерживается большое число агентов, в том числе для ряда ИБП APC, что радует - HP iLO и IBM Blade Center, виртуальных машин Xen, коммутаторов McData, Brocade. Однако, например, Cisco MDS, насколько я знаю, "родными" средствами "гасить" нельзя. В luci настройка fencing производится на вкладке Cluster в свойствах кластера и пункте меню Shared Fence Devices. Снимки с экрана пропустим :)

Добавляем кворумный диск

Получившийся кластер состоит из двух узлов. Чтобы разрешить проблему разделения кластера на две независимые части, когда каждый из узлов думает что он единственный уцелевший и продолжает изменять данные на диске, добавим кворумный диск. Просмотрим состояние нашего кластера. Два узла, флаг специального двух-узлового режима и ни одного сервиса:

[root@node1 ~]# clustat
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local

[root@node1 ~]# cman_tool status
Version: 6.0.1
Config Version: 1
Cluster Name: cluster0
Cluster Id: 26776
Cluster Member: Yes
Cluster Generation: 140
Membership state: Cluster-Member
Nodes: 2
Expected votes: 1
Total votes: 2
Quorum: 1
Active subsystems: 8
Flags: 2node
Ports Bound: 0 11 177
Node name: node1.example.com
Node ID: 2
Multicast addresses: 239.192.104.1
Node addresses: 192.168.50.140

В качестве кластерного диска используем первый раздел на общем диске:

[root@node1 ~]# mkqdisk -c /dev/mydata1 -l myqdisk
mkqdisk v0.5.1
Writing new quorum disk label 'myqdisk' to /dev/mydata1.
WARNING: About to destroy all data on /dev/mydata1; proceed [N/y] ? y
Initializing status block for node 1...
...
[root@node1 ~]# mkqdisk -L
mkqdisk v0.5.1
/dev/sdc1:
Magic: eb7a62c2
Label: myqdisk
Created: Tue Dec 2 13:12:29 2008
Host: node1.example.com

Теперь необходимо вручную на одном из узлов убрать флаг, говорящий о том, что кластер в особой двухнодовой конфигурации (luci ставит этот флаг автоматом), и увеличить число голосов на один. Кроме того, необходимо увеличить версию конфигурационного файла:

[root@node1 ~]# vi /etc/cluster/cluster.conf

cluster alias="cluster0" config_version="3" name="cluster0"
...
cman expected_votes="3" two_node="0"/

Даем команду узлам кластера обновить конфигурацию:

[root@node1 ~]# ccs_tool update /etc/cluster/cluster.conf
Config file updated from version 2 to 3

Update complete.

Стартуем сервис qdiskd, который уже привнесен нам на узлы пакетом cman:

[root@node2 ~]# chkconfig qdiskd on; service qdiskd start
Starting the Quorum Disk Daemon: [ OK ]

Теперь в luci добавляем кворумный раздел. В качестве проверки будем пинговать шлюз по умолчанию:

За объяснением параметров идем к документации. В итоге в clustat мы получаем следующую картину:

[root@node1 ~]# clustat
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local
/dev/mydata1 0 Online, Quorum Disk


Раздел GFS

Если в двух словах, то про сетевые файловые системы, в том числе и GFS, Андрей Меганов писал в блоге. А дальше, традиционно, читаем документацию.

К настоящему моменту Conga уже должна была установить все необходимые пакеты. Для гарантии того, что тип блокировок LVM2 сменен с stand-alone на cluster-wide, отдадим команду:

[root@node2 ~]# lvmconf --enable-cluster

После чего (пере)запустим clvmd. Далее создадим на общем диске раздел под GFS:

[root@node1 ~]# fdisk /dev/mydata

На обоих узлах перечитаем таблицу разделов:

[root@node1 ~]# partprobe
[root@node1 ~]# fdisk -l

Disk /dev/sdc: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 * 1 13 104391 83 Linux
/dev/sdc2 14 6093 48837600 8e Linux LVM

На новом разделе создадим логический том, который, благодаря clvmd, будет доступен на всех узлах кластера:

[root@node1 ~]# pvcreate /dev/mydata2
Physical volume "/dev/mydata2" successfully created
[root@node1 ~]# vgcreate vgcluster /dev/mydata2
Volume group "vgcluster" successfully created
[root@node1 ~]# vgdisplay | grep Free
Free PE / Size 11923 / 46.57 GB
Free PE / Size 0 / 0
[root@node1 ~]# lvcreate -l 11923 -n gfsvol vgcluster

В случае, если последняя команда отработает с ошибкой, workaround:

[root@node2 ~]# service clvmd stop
Stopping clvm: [ OK ]
[root@node2 ~]# rm /etc/lvm/cache/.cache
rm: remove regular file `/etc/lvm/cache/.cache'? y
[root@node2 ~]# pvscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
PV /dev/mydata2 VG vgcluster lvm2 [46.57 GB / 0 free]
PV /dev/sdb1 VG VolGroup00 lvm2 [149.03 GB / 0 free]
PV /dev/sda2 VG VolGroup00 lvm2 [74.41 GB / 0 free]
Total: 3 [270.01 GB] / in use: 3 [270.01 GB] / in no VG: 0 [0 ]
[root@node2 ~]# vgscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
Reading all physical volumes. This may take a while...
Skipping clustered volume group vgcluster
Found volume group "VolGroup00" using metadata type lvm2
[root@node2 ~]# lvscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
Skipping clustered volume group vgcluster
ACTIVE '/dev/VolGroup00/LogVol00' [221.50 GB] inherit
ACTIVE '/dev/VolGroup00/LogVol01' [1.94 GB] inherit

[root@node1 ~]# service clvmd start
Starting clvmd: [ OK ]
Activating VGs: 1 logical volume(s) in volume group "vgcluster" now active
2 logical volume(s) in volume group "VolGroup00" now active
[ OK ]

Создаем файловую систему (один лишний журнал "про запас"):

[root@node1 ~]# gfs_mkfs -p lock_dlm -t cluster0:share -j 3 /dev/vgcluster/gfsvol

Пробуем смонтировать:

[root@node1 ~]# mount /dev/vgcluster/gfsvol /var/www/html
[root@node1 ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/vgcluster-gfsvol on /var/www/html type gfs (rw,hostdata=jid=0:id=131074:first=1)

Информация о файловой системе:

[root@node1 ~]# gfs_tool df /var/www/html
/var/lib/xen/images:
SB lock proto = "lock_dlm"
SB lock table = "cluster0:share"
SB ondisk format = 1309
SB multihost format = 1401
Block size = 4096
Journals = 3
Resource Groups = 186
Mounted lock proto = "lock_dlm"
Mounted lock table = "cluster0:share"
Mounted host data = "jid=0:id=131074:first=1"
Journal number = 0
Lock module flags = 0
Local flocks = FALSE
Local caching = FALSE
Oopses OK = FALSE

Type Total Used Free use%
------------------------------------------------------------------------
inodes 5 5 0 100%
metadata 5 5 0 100%
data 12109426 0 12109426 0%

Добавляем строчку в /etc/fstab:

/dev/vgcluster/gfsvol /var/www/html gfs defaults 0 0

Создание кластерного ресурса

Остался последний шаг - создаем службу, которая будет хранить, и, если необходимо, изменять данные на GFS. С httpd пример не очень хороший, зато делается просто. На всех узлах:

[root@node2 ~]# yum -y install httpd

На одном из узлов:

[root@node2 ~]# vi /var/www/html/index.html

Теперь в web-интерфейсе:

Проверяем:

[root@server1 ~]# elinks -dump http://192.168.50.146
My web Service!

И с любого из узлов:

[root@node1 ~]# clustat
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local
/dev/mydata1 0 Online, Quorum Disk

Service Name Owner (Last) State
------- ---- ----- ------ -----
service:webservice node2.example.com started

Теперь можно через web-интерфейс или из командной строки поперекидывать сервис с узла на узел, сымитировать падение узла, добавить скрипт, который будет каким-то образом менять данные, или добавить более интересный сервис в созданный HA-кластер.

Настройка Device-Mapper Multipath в RHEL 5

В данном посте я хочу описать шаги для настройки Multipath при помощи dm-multipath. Device Mapper Multipathing (DM-Multipath) позволяет "собрать" несколько маршрутов ввода/вывода между сервером и дисковым массивом в единое целое, и рассматривать доступный по нескольким путям массив как одно мета-устройство. Например, если сервер с двумя двух-портовыми HBA подключен к одному и тому же массиву, то сервер, в самом простейшем случае, будет "видеть" четыре устройства /dev/sd{a,b,c,d}. При помощи dm-multipath можно собрать из них агрегирующее все четыре пути мета-устройство /dev/dm-N, обеспечив прозрачную для операционной системы и приложений конфигурацию, отказоустойчивую в случае выхода из строя HBA, кабеля или коммутатора (если каждый HBA подключен через свой коммутатор).

Хотя, по информации, приведенной в этом посте, можно повторить все шаги и настроить dm-multipath, но информация будет явно не достаточна для понимания всех деталей работы и команд. Для дальнейшего изучения материала рекомендую обратиться к официальной документации Red Hat - книге "Device-Mapper Multipath Configuration and Administration", доступной на сайте Red Hat как в виде PDF, так и HTML.

Далее рассмотрим настройку dm-multipath для конфигурации представленной на рисунке:Имеется iSCSI-target, доступная по двум интерфейсам в двух сетях: 192.168.0.0/24 и 192.168.1.0/24. Соответственно на сервере vm01 есть два сетевых интерфейса, каждый из которых подключен к одной из двух сетей. На сервере установлен iSCSI-инициатор, и сервер может обращаться к доступному ему целевому устройству по двум различным путям. Попробуем организовать конфигурацию, устойчивую к отказу одного из путей, при помощи dm-multipath.

Для начала убедимся, что на vm01 установлен пакет device-mapper-multipath, и загружены модули ядра dm_multipath и dm_round_robin:

[root@vm01 ~]# rpm -qa | grep multipath
device-mapper-multipath-0.4.7-12.el5
[root@vm01 ~]# lsmod | grep dm_
dm_round_robin 7617 0
dm_multipath 21577 1 dm_round_robin
dm_snapshot 20709 0
dm_zero 6209 0
dm_mirror 28869 0
dm_mod 58201 9 dm_multipath,dm_snapshot,dm_zero,dm_mirror

При необходимости установите пакет. Если модули не загружены, то воспользуйтесь командой modprobe. Далее запускаем процесс обзора для поиска iSCSI-целей. При необходимости можно обратиться к моему посту "Настройка iSCSI target и initiator в RHEL/Fedora" или к любой другой доступной документации.

[root@vm01 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.114:3260
192.168.0.114:3260,1 iqn.2003-12.net.markelov:disk1
[root@vm01 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.1.114:3260
192.168.1.114:3260,1 iqn.2003-12.net.markelov:disk1

Перезапускаем демон iscsi и проверяем вывод команды fdisk -l для того, чтобы убедиться, что сервер "видит" подключенную цель:

[root@vm01 ~]# service iscsi restart
[root@vm01 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes
255 heads, 63 sectors/track, 2088 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

...

Disk /dev/sda: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Disk /dev/sda doesn't contain a valid partition table

Disk /dev/sdb: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Disk /dev/sdb doesn't contain a valid partition table

Как видно, помимо локального /dev/xvda, появились два новых устройства - /dev/sda и /dev/sdb - одинакового размера. Можно убедиться, что это одно и тоже устройство, сравнив идентификаторы:

[root@vm01 ~]# scsi_id -g -s /block/sda
16465616462656166313a3100000000000000000000000000
[root@vm01 ~]# scsi_id -g -s /block/sdb
16465616462656166313a3100000000000000000000000000

Теперь приступаем к правке конфигурационного файла демона multipathd - /etc/multipath.conf. Необходимо закомментировать секцию, определяющую, для каких устройств multipathing выключен:

#blacklist {
# devnode "*"
#}

По умолчанию он был выключен для всех устройств - devnode "*". Далее необходимо раскомментировать секцию с комментариями:
## This is a template multipath-tools configuration file
## Uncomment the lines relevent to your environment
В этом шаблоне есть практически все, что нам нужно. Единственное, что мы изменим, это в path_grouping_policy пропишем failover. В следующей секции описан blacklist, который определяет такие устройства, как floppy-дисководы и IDE-диски. Его также можно раскомментировать. При необходимости добавьте свои устройства. Теперь можно запустить демон multipathd:

[root@vm01 ~]# chkconfig multipathd on
[root@vm01 ~]# service multipathd start

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

[root@vm01 ~]# fdisk -l

...

Disk /dev/dm-2: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-2 doesn't contain a valid partition table

Цель iqn.2003-12.net.markelov:disk1, очевидно, не содержит таблицы разделов. Создадим ее. Однако, команду fdisk нельзя использовать для работы с разделами на устройствах /dev/dm-*. Вместо этого мы создадим разделы на /dev/sda или /dev/sdb:

[root@vm01 ~]# fdisk /dev/sda
... создаем, например, два раздела...
[root@vm01 ~]# partprobe
[root@vm01 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes

...

Disk /dev/sda: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 509 2619283 83 Linux
/dev/sda2 510 1018 2619314 83 Linux

Disk /dev/sdb: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 509 2619283 83 Linux
/dev/sdb2 510 1018 2619314 83 Linux

Disk /dev/dm-2: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/dm-2p1 1 509 2619283 83 Linux
/dev/dm-2p2 510 1018 2619314 83 Linux
[root@vm01 ~]#

Наконец осталось создать из наших разделов устройства /dev/dm-*, для того, чтобы с ними далее можно было работать:

[root@vm01 ~]# kpartx -a /dev/dm-2

После этого появятся два новых устройства - /dev/dm-3 и /dev/dm-4, - которые и являются нашими двумя ранее созданными разделами. Можно создать файловую систему и смонтировать ее:

[root@vm01 ~]# mkfs.ext3 /dev/dm-3
[root@vm01 ~]# mkdir /mnt/dm3
[root@vm01 ~]# mount /dev/dm-3 /mnt/dm3/

Далее можно работать с разделом /dev/dm-3 обычным образом. Просмотреть состояние multipathed-устройств можно командой:

[root@vm01 ~]# multipath -ll
mpath0 (16465616462656166313a3100000000000000000000000000) dm-2 IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 0:0:0:1 sda 8:0 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:1 sdb 8:16 [active][ready]

По выводу:

[root@vm01 ~]# dmsetup ls --target multipath
mpath0 (253, 2)

можно сопоставить устройство /dev/mapper/mpath0 и /dev/dm-2. Теперь промоделируем выход из строя одного из маршрутов:

[root@vm01 ~]# multipath -ll
sdb: checker msg is "readsector0 checker reports path is down"
mpath0 (16465616462656166313a3100000000000000000000000000) dm-2 IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 0:0:0:1 sda 8:0 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:1 sdb 8:16 [failed][faulty]

Тем не менее наше устройство доступно, что легко проверить, записав какую-нибудь информацию в /mnt/dm3. После этого можно "поднять" интерфейс eth1 и провести тот же эксперимент с eth0.

Настройка iSCSI target и initiator в RHEL/Fedora

Как известно, при использовании существующей сетевой инфраструктуры iSCSI представляет собой недорогую альтернативу FC, а для целей обучения и тестирования вообще не заменим, поскольку, в ряде случаев, можно обойтись без дорогостоящего оборудования. Безусловно, существует и множество "боевых" конфигураций, когда по тем или иным причинам стоит отдать предпочтение iSCSI. В этом посте я хочу кратко описать настройку iSCSI target и iSCSI initiator в Red Hat Enterprise Linux и Fedora. Нужно отметить, что до версии RHEL 5.2 поддержка iSCSI target присутствовала в статусе Technology Preview. Поддержка же iSCSI initiator присутствует в полном объеме еще с Red Hat Enterprise Linux 4.

Для тестов используем две машины: vm01, которая будет экспортировать раздел /dev/xvda5, и vm02, на которой настроим инициатор.

1) Настройка iSCSI target

Для начала устанавливаем пакет scsi-target-utils и запускаем демон tgtd:

[root@vm01 ~]# yum install scsi-target-utils
...
[root@vm01 ~]# service tgtd start
[root@vm01 ~]# chkconfig tgtd on

Теперь создаем наше целевое устройство. В качестве имени я выбрал iqn.2003-12.net.markelov:disk1

[root@vm01 ~]# tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2003-12.net.markelov:disk1

В моем случае я добавляю к целевому устройству свежесозданный раздел /dev/xvda5:

[root@vm01 ~]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/xvda5

Теперь разрешим доступ хосту vm02 с IP-адресом 192.168.0.109:

[root@vm01 ~]# tgtadm --lld iscsi --op bind --mode target --tid 1 -I 192.168.0.109

Проверяем:

[root@vm01 ~]# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2003-12.net.markelov:disk1
System information:
Driver: iscsi
Status: running
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: deadbeaf1:0
SCSI SN: beaf10
Size: 0
Backing store: No backing store
LUN: 1
Type: disk
SCSI ID: deadbeaf1:1
SCSI SN: beaf11
Size: 964M
Backing store: /dev/xvda5
Account information:
ACL information:
192.168.0.109
[root@vm01 ~]#

Под конец не забудьте прорубить "дырку" в брандмауэре для порта 3260/tcp, который используется по умолчанию.

2) Настройка iSCSI initiator

Устанавливаем пакет iscsi-initiator-utils и запускаем демон iscsi:
[root@vm02 ~]# yum install iscsi-initiator-utils
...
[root@vm02 ~]# service iscsi start
iscsid is stopped
Turning off network shutdown. Starting iSCSI daemon: [ OK ]
[ OK ]
Setting up iSCSI targets: iscsiadm: No records found!
[ OK ]
[root@vm02 ~]# chkconfig iscsi on

При запуске мы получаем совершенно справедливое сообщение, что не сконфигурирована ни одна из целей. Запускаем процесс обзора для поиска целей на хосте vm01 c IP-адресом 192.168.0.100:

[root@vm02 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.100:3260
192.168.0.100:3260,1 iqn.2003-12.net.markelov:disk1

В итоге будут созданны две поддиректории с информацией о цели и хосте:

[root@vm02 ~]# ls /var/lib/iscsi/nodes/
iqn.2003-12.net.markelov:disk1
[root@vm02 ~]# ls /var/lib/iscsi/send_targets/
192.168.0.100,3260

Просмотреть информацию можно командой:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260
node.name = iqn.2003-12.net.markelov:disk1
node.tpgt = 1
...

Теперь, используя содержимое /var/lib/iscsi/nodes/ и /var/lib/iscsi/send_targets/, демон iscsi при каждом перезапуске будет подключать наши ранее обнаруженные цели. Также процессом подключения/отключения можно управлять при помощи утилиты iscsiadm:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -l
Login session [iface: default, target: iqn.2003-12.net.markelov:disk1, portal: 192.168.0.100,3260]
[root@vm02 ~]#

Теперь команда fdisk покажет наш раздел /dev/sda, экспортированный с vm01:

[root@vm02 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes
255 heads, 63 sectors/track, 2088 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
...
Disk /dev/sda: 1011 MB, 1011677184 bytes
32 heads, 61 sectors/track, 1012 cylinders
Units = cylinders of 1952 * 512 = 999424 bytes

Disk /dev/sda doesn't contain a valid partition table

После команды

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -u
Logout session [sid: 2, target: iqn.2003-12.net.markelov:disk1, portal: 192.168.0.100,3260]

в выводе fdisk мы увидим только /dev/xvda. Однако, после рестарта демона iscsi, цель снова появиться в списке устройств. Для удаления всей информации о цели воспользуйтесь командой:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -o delete
[root@vm02 ~]# ls /var/lib/iscsi/nodes/
[root@vm02 ~]#

Если у вас несколько целей, то вы не можете заранее знать, под каким именем после следующей перезагрузки/рестарта сервиса будет доступна конкретная цель. Для того, чтобы каждая цель всегда была доступна под одним и тем же именем устройства, вы можете написать соответствующее правило udev или воспользоваться монтированием по метке и UUID файловой системы ext3. При монтировании файловых систем не забывайте использовать опцию _netdev.

Для того, чтобы лучше понять лог выполненных команд, рекомендую ознакомиться со следующими источниками:

• /usr/share/doc/scsi-target-utils-*
• tgtadm(8)
• iscsiadm(8)