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
# vblade 0 1 eth0 /dev/sdb1
Здесь:
Первая цифра - условный номер "шасси" (или компьютера);
Вторая цифра - условный номер "слота" (или интерфейса диска);
eth0 - имя сетевого интерфейса, через который будет экспортироваться блочное устройство;
/dev/sda1 - непосредственно имя экспортируемого локального блочного устройства.
Вторая цифра - условный номер "слота" (или интерфейса диска);
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
# 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
e0.1 1000.204GB eth0 up
Просмотр обнаруженных устройств на локальном хосте, инициаторе экспорта:
# aoe-stat
e0.0 1000.202GB lo up
e0.1 1000.204GB 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
....
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
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
eth: eth0
shelf: 0
slot: 0
Alarm clock
Сразу предупреждаю о том, что корректная проверка доступности AoE устройства с помощью утилиты aoeping возможна только применительно к удалённым интерфейсам, вроде "eth0", но не к локальному "хосту" ("lo"). То есть, доступность устройства на разнесённых компьютерах можно проверить, а вот с того компьютера, на котором, собственно, и расположено устройство - невозможно, вывод утилиты откровенно некорректен и не представляется возможности опираться на его данные.
Команда aoe-flush отключает публикацию блочного устройства и зачищает список доступных по сети блочных устройств AoE:
# aoe-flush -a
После зачистки необходимо произвести повторное сканирование сети и создание списка доступных блочных устройств:
# aoe-discover
# aoe-stat
# aoe-stat
Переход к настройке контроля за экспортом блочных устройств AoE.