UMGUM.COM 

AoE ( Экспорт и импорт блочных устройств. )

1 августа 2010  (обновлено 2 ноября 2014)

Эта публикация отнесена в архив. Она неактуальна.
Ресурс по следующей ссылке является преемником: Построение простейшей распределённой расширяемой сетевой горизонтальной файловой системы с использованием технологий MDADM, LVM, NFS и MHDDFS.

OS: Debian Linux.

AoE инкапсулирует команды ATA прямо в Ethernet пакеты. Что из этого следует? То, что никакого контроля целостности нет. Никакого контроля доступа нет. Никакого восстановления повреждённых при передачи данных нет. Потому - применяем только качественное и современное оборудование для передачи данных между узлами сети с контролем целостности пакетов. Потому - выделяем все узлы нашей распределённой сетевой файловой системы в отдельный VLAN или подключаем к выделенному коммутатору, что, в свою очередь, включён в выделенный VLAN или в порт маршрутизатора с контролем доступа. Естественно, для работы AoE не нужен IP адрес на сетевом интерфейсе; естественно, для доступа к компьютеру по протоколу TCP/IP IP адрес мы все таки назначим, но можно было бы и не назначать.

Итак, оценив плюсы и минусы применения AoE в нашей схеме - приступим.

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

# aptitude install vblade

Никаких средств автоматического управления утилита не имеет, и это к лучшему.


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

# aptitude install aoetools

Инсталлятор пакета aoetools создает файл автоматического запуска сканирования доступных ресурсов и вообще создает ненужную суету. Считаю необходимым устранить эту активность путём блокирования файла в "авто-запуске":

# chmod ugo-x /etc/init.d/aoetools

Модуль ядра AoE в Debian Lenny уже имеется, его инсталлировать нет необходимости, просто инициируем его:

# modprobe aoe

Иногда (по правде говоря, частенько) приходится элементарно выгружать модуль AoE для устранения последствий сбоя в работе драйвера:

# rmmod -f aoe

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

# vblade 0 0 eth0 /dev/sda1
# vblade 0 1 eth0 /dev/sdb1

Здесь:

Первая цифра - условный номер "шасси" (или компьютера);
Вторая цифра - условный номер "слота" (или интерфейса диска);
eth0         - имя сетевого интерфейса, через который будет экспортироваться блочное устройство;
/dev/sda1    - непосредственно имя экспортируемого локального блочного устройства.

Сочетание номеров "шасси" и "слота" для каждого экспортируемого блочного устройства должно быть уникальным в рамках используемого сегмента Ethernet сети, так как это естественный идентификатор блочного устройства при его передаче на удалённый хост и его применении. При экспортировании можно ограничить доступ к блочному устройству только тем хостам, MAC адрес которых указан в такой дополнительной опции команды vblade как "-m mac,mac,...,mac".

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

# vblade 0 0 eth0 /dev/sda1
# vblade 0 0 lo /dev/sda1
# vblade 0 1 eth0 /dev/sdb1
# vblade 0 1 lo /dev/sda1

Таким образом, устройство доступно в едином стиле адресации как на локальном хосте, так и удалённым хостам.

На принимающей стороне отдаем команду обзора доступных в сети блочных устройств:

# aoe-discover

Просмотр обнаруженных устройств на удалённом хосте:

# aoe-stat

e0.0    1000.202GB   eth0 up
e0.1    1000.204GB   eth0 up

Просмотр обнаруженных устройств на локальном хосте, инициаторе экспорта:

# aoe-stat

e0.0    1000.202GB   lo up
e0.1    1000.204GB   lo up

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

После того, как устройство обнаружено, ссылка на него автоматически прописывается в директории "/dev/etherd/" и может быть использована как обычное локальное блочное устройство:

# ls -l /dev/etherd/ | grep b

....
brw-rw−−−− 1 root disk 152,   0 2010-05-13 15:28 e0.0
brw-rw−−−− 1 root disk 152,  16 2010-05-13 15:41 e0.1
....

В связи с использованием блочных устройств доставляемых по сети возникает естественный вопрос о том, что будет в случае потери связи между узлами сети. В таком случае драйвер AoE блокирует запрос чтения/записи на устройство и ждет разрешения ситуации с течении указанной при конфигурировании задержки (в Debian Lenny эта задержка "бесконечна", как указанно в документации в пакету aoetools). Сразу после восстановления связи устройство снова становится доступным и, если приложение, чью попытку чтения/записи заблокировал драйвер AoE, само не отказалось от операции (в связи с собственными параметрами задержки при осуществлении операций), работа продолжится с того места, где была приостановлена. Практически это выглядит следующим образом: вынимаем кабель из порта Ethernet интерфейса - драйвер AoE блокирует операции чтения/записи, все замирает, - подключаем кабель - диск снова доступен и работа продолжается с того места, где была прервана.

В том случае, если установлена какая-то определённая задержка до признания удалённого блочного устройства недоступным, по истечению задержки драйвер AoE выдает приложению, запрашивающему операцию чтения/записи сообщение "IO Error". После восстановления доступности удалённого блочного устройства работа восстанавливается. С учётом того, что операции записи были прерваны и не завершены, рекомендуется провести проверку файловой системы и устранение возможных повреждений (провести fsck не помешает).

Кстати, в связи с тем, что по умолчанию драйвер AoE ждет ответа от исчезнувшего из вида устройства неограниченно долго, то таковое не исчезает из списка доступных при просмотре состояния с помощью утилиты aoe-stat. То есть, полагаться на неё при мониторинге состояния подсистемы публикуемых блочных устройств нет никакой возможности. Если нужно узнать о состоянии AoE устройства - необходимо использовать утилиту aoeping из пакета aoe-tools. Например, на запрос с тайм-аутов в пять секунда на обнаружение устройства с индексом "0 0" доступного через интерфейс eth0:

# aoeping -v -s 5 0 0 eth0

... получим следующий говорящий ответ:

tag: 80000000
eth: eth0
shelf: 0
slot: 0
config query response:
00 24 1d 7f 0e 87 00 24 1d 7e 25 92 88 a2 18 00
00 00 00 01 80 00 00 00 00 10 40 10 02 10 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
found e0.0 with mac 00241d7e2592

А в том случае, если устройство по сети недоступно:

tag: 80000000
eth: eth0
shelf: 0
slot: 0
Alarm clock

Сразу предупреждаю о том, что корректная проверка доступности AoE устройства с помощью утилиты aoeping возможна только применительно к удалённым интерфейсам, вроде "eth0", но не к локальному "хосту" ("lo"). То есть, доступность устройства на разнесённых компьютерах можно проверить, а вот с того компьютера, на котором, собственно, и расположено устройство - невозможно, вывод утилиты откровенно некорректен и не представляется возможности опираться на его данные.

Команда aoe-flush отключает публикацию блочного устройства и зачищает список доступных по сети блочных устройств AoE:

# aoe-flush -a

После зачистки необходимо произвести повторное сканирование сети и создание списка доступных блочных устройств:

# aoe-discover
# aoe-stat

Переход к настройке контроля за экспортом блочных устройств AoE.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )