\section{ATA over Ethernet}

Описываемая технология построения хранилищ даёт возможность строить дисковые массивы
для архивов, резервных копий или традиционного использования
на базе обычных дисков ATA, которые дешевле даже чем лента.
Эта технология может оказаться особенно интересной для тех, 
кто использует виртуализированные системы на базе Xen.

Технология является альтернативой для iSCSI, но с более узким 
спектром задач, где она может использоваться. Подробнее об этом ниже,
в разделе \textit{\dq{}Преимущества и недостатки AoE\dq{}}.

\subsection{Введение}
Данные некоторых видов огромны просто в силу своей природы.
Видео, например, как правило занимает большой объём диска.
В связи с широким распространением видеонаблюдения
потребность в хранении видео-данных становится ещё более актуальной.

Резервное копирование и избыточность данных
имеет существенное значение для любого дела,
в котором используются компьютеры.
Похоже, не важно, какой объём хранилища -- всегда хочется иметь больше.
Даже почта может вырасти за пределы контейнера, в котором она лежит.
Это хорошо известно провайдерам Интернет-услуг.

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

Наиболее известный пример хранилищ, работающих из коробки это, наверное, SAN (storage area network).
Когда SAN\rq{}ы только появились вокруг них был большой шум и переполох.
Сложно было выяснить, что же это в действительности такое.
А когда в итоге это всё-таки получилось, выяснилось что это нечто 
сложное, проприетарное и дорогое.

Однако, поддерживая SAN\rq{}ы Linux-сообщество сделало несколько полезных изменений в ядре.
Сегодня в ядрах Linux есть возможности, которых ещё несколько лет назад очень не хватало.
Они могут использоваться как гигантские блочные устройства, выходящие далеко
за старые пределы в два терабайта (именно терабайта! подробности, например, в \url{http://lkml.org/lkml/2002/5/9/217} и \url{http://kerneltrap.org/node/186}). Они поддерживают намного больше 
одновременно подключённых дисков. Также появились богатые возможности управления томами.
В дополнение ко всему прочему, файловые системы могут теперь расширяться до огромных размеров,
даже когда они смонтированы и используются.

Здесь рассматриваются новые пути использования эти возможности ядра:
диски выносятся из компьютера старые пределы ёмкости преодолеваются.
Можно воспринимать ATA over Ethernet как способ заменить IDE-кабель
сетью Ethernet. Когда хранилище и компьютер развязаны и между ними стоит такая гибкая вещь
как Ethernet, возможности ограничены только воображением и желанием изучать новые вещи.

\subsection{Что такое AoE}
ATA over Ethernet (AoE) — это сетевой протокол, зарегистрированный IEEE как Ethernet-протокол 
номер 0x88a2. AoE это низкоуровневый протокол, намного более простой чем TCP/IP или даже просто IP. 
TCP/IP и IP нужны обязательно, если требуется организовать (надёжную) передачу данных через Интернет,
но на компьютер в этом случае ложится намного большая нагрузка, для того чтобы 
обеспечить ту сложность, которая присуща этим протоколам.

Особенно хорошо это известно пользователям iSCSI.
iSCSI позволяет перенаправить ввод/вывод поверх TCP/IP,
что в свою очередь даёт возможность заменить дорогое оборудование Fibre Channel на значительно
более дешёвое Ethernet и IP.
Зачастую iSCSI используется совместно с устройствами для разгрузки TCP (TCP offload engines, TOE).
Эти устройства довольно дорогие, но они снимают часть нагрузки TCP/IP
с центрального процессора машин, использующих iSCSI.

Интересно, что в большинстве своём iSCSI не используется поверх собственно сети Интернет.
Чаще всего пакеты просто передаются на машину, стоящую в соседней серверной стойке,
и в этом случае вся мощь TCP/IP оказывается просто избыточной.

Резонный вопрос, почему бы вместо того что разгружать TCP/IP вообще от него не избавиться?
Протокол AoE именно это и делает.
И вместо того чтобы полагаться на TCP/IP, он полагается на возможности современных коммутаторов,
у которых не бывает коллизий, есть возможность управления потоком и
постоянно растёт производительность.
В локальной сети сохраняется последовательность пакетов
и для каждого пакеты сетевым оборудованием вычисляется контрольная сумма.

В каждом AoE пакете находится команда для ATA-диска или ответ от ATA-диска.
Драйвер AoE в ядре Linux выполняется AoE и делает диск доступным как обычное
блочное устройство, такое, например, как \texttt{/dev/etherd/e0.0} -- точно также
как IDE-драйвер делает диск, подключённый к концу IDE-кабеля, доступным как \texttt{/dev/hda}.
Драйвер, если нужно, ретранслирует пакеты, так что AoE-устройство выглядит для остального ядра как обычный диск.

В дополнение к ATA командам, у AoE есть простая возможность идентификации
доступных устройств с помощью конфигурационных опросных пакетов (query config packets).
Это всё: ATA команды и конфигурационных опросные пакеты.

Возникает вопрос:
если все диски находятся в сети, тогда как я могу ограничить доступ к дискам?
Как можно быть уверенным что, даже если машину А взломали, что диски машины B в безопасности?

Ответ в том, что AoE немаршрутизируемый протокол. Можно легко определить какой компьютер 
будет видеть какие диски путём конфигурирования Ethernet-сети.
Поскольку AoE-устройствам не нужны IP-адреса, создать изолированные
Ethernet-сети несложно.
Большинство современных коммутаторов имеют возможность организации
VLAN\rq{}ов, что позволяет легко разделить коммутатор на несколько широковещательных доменов.

Протокол AoE настолько легковесный, что его может использовать даже самое недорогое железо
(существует как минимум один производитель оборудования, поддерживаеющего ATA over Ethernet — Coraid).
Описание спецификаций AoE помещается на 8 страниц. Простота протокола выглядит контрастно
по отношению к iSCSI, который описывается на сотнях страниц,
включая спецификации по шифрованию, маршрутизации, контролю доступа
и множеству других вопросов.

Простые примитивы могут быть очень мощными.

\subsection{Стэн-архиватор}
Эта история основана на реальных событиях, случившихся с гражданином
одного другого государства.

Стэн — вымышленный админ, работающий на государственной службе.
В соответствии с новым государственным законом той страны все официальные
документы должны архивироваться. Любой гражданин государства
может потребовать показать любой документ в любое время.
Из-за этого Стэну понадобилось огромное хранилище, которое может расти
без всяких ограничений. Производительность хранилища может не быть 
больше производительности локального диска. Любые данные из хранилища
должны доставаться легко и мгновенно.

Стэн уверенно чувствует себя в системном администрировании Linux и Ethernet сетях,
и из-за этого он решает попробовать для своей задачи ATA over Ethernet.
Он покупает кое-какое оборудование, потратив на это меньше \$6.5K:
\begin{itemize}
\item  Одна двухпортовая гигабитная Ethernet-карта, вместо старой 100-мегабитной карты.
\item  Один 26-портовый коммутатор с двумя гигабитными портами.
\item  Одну полку Coraid EtherDrive и десять блэйдов EtherDrive.
\item  Десять 400GB ATA жестких дисков.
\end{itemize}

Оборудование может быть объединеное в программный RAID-10 — чередование поверх зеркалированных пар.
Хотя этак конфигурация не даёт столько ёмкости как конфигурация RAID 5,
она максимизирует отказоустойчивость, надёжность, снижает нагрузку
на процессор и время реинициализации диска при замене.

Имеет смысл поверх AoE-дисков использовать 
LVM и файловые системы с возможностью online-расширения, такие например,
как ext3, XFS или JFS.
Это даст возможность в дальнейшем, при необходимости купить новую заполненную 
полку, создать ещё один RAID 10, превратить его в физический том, 
и использовать этот том для расширения
объёма логических томов с файловыми системами.

Для старых систем нужно скомпилировать драйвер
AoE с AOE\_PARTITIONS=1 (в частности, sarge не поддерживал большие минорные номера),
поэтому он выключает поддержку разделов, для того чтобы использовать побольше дисков.

\begin{verbatim}
%# # Настройка хоста для работы с AOE 

%# # Сборка и инсталляция драйвера aoe
%# tar xvfz aoe-2.6-5.tar.gz
%# cd aoe-2.6-5
%# make AOE_PARTITIONS=1 install

%# # Настройка сети
%# # Для AoE IP-адрес не нужен
%# ifconfig eth1 up

%# # Чтобы быть уверенным что интерфейс успел подняться, нужно подождать какое-то время
%# # И после этого загрузить драйвер aoe
%# sleep 5
%# modprobe aoe

%# # Теперь можно посмотреть какие AoE-устройства есть в сети
%# aoe-stat
\end{verbatim}

\subsection{Минорные номера устройств}
Программы, которые хотят использовать устройство, как правило, обращаются к нему
через специальный файл, соответствующий ему. Типичный пример -- файл \texttt{/dev/hda}.
Команда \texttt{ls -l} покажет для этого устройства, \texttt{/dev/hda}, номера 3 и 0.
Мажорный номер 3 и минорный номер 0. А у устройства \texttt{/dev/hda1} минорный номер 1,
в то время как мажорный номер тоже 3.

До ядра 2.6 минорный номер был 8битный, ограничивая возможное количество номеров от 0 до 255.
Ни у кого и не было столько устройств, поэтому ограничение не имело существенного значения.
Теперь, когда диски могут быть отвязаны от серверов, ограничение стало важным --
в настоящее время ядро 2.6 использует до 20 бит для минорного номера устройства.

Иметь 1048576 разных  значений для минорного номера это большая помощь для систем, в которых 
много устройств, но не всякое программное обеспечение может с этим разобраться.
Если glibc или другая программа всё ещё думает, что минорные номера 8-битные,
будет проблематично заставить её использовать номера превышающие 255.

Для облегчения перехода, драйвер AoE может быть скомипилирован 
без поддержки разделов.
Это позволит вместо 16 номеров на диск использовать только один.
Так что, даже на системах, которые до сих пор не поддерживают большие
минорные номера как ядро 2.6, можно использовать до 256 AoE дисков.

Команды для создания файловой системы и логических томов показаны на листинге 2.
Стэн решил назвать группу ben и логический том franklin.
После этого нужно сделать небольшие изменения в конфигурации LVM2.
Во-первых, нужно добавить строку с типом = [\dq{}aoe\dq{}, 16],
так чтобы LVM распознал AoE-диски. Во-вторых, нужно указать md\_component\_detection = 1,
чтобы диски внутри RAID 10 игнорировались, как только весь RAID 10 
стал физическим томом.

\begin{verbatim}
%# # ускорить инициализацию массива
%# for f in `find /proc | grep speed`; do echo 100000 > $f done

%# создать массив (mdadm will manage hot spares)
%# mdadm -C /dev/md1 -l 1 -n 2 /dev/etherd/e0.0 /dev/etherd/e0.1
%# mdadm -C /dev/md2 -l 1 -n 2 /dev/etherd/e0.2 /dev/etherd/e0.3
%# mdadm -C /dev/md3 -l 1 -n 2 /dev/etherd/e0.4 /dev/etherd/e0.5
%# mdadm -C /dev/md4 -l 1 -n 2 -x 2 \
          /dev/etherd/e0.6 /dev/etherd/e0.7 \
          /dev/etherd/e0.8 /dev/etherd/e0.9
%# sleep 1

%# распределение по зеркалам
%# mdadm -C /dev/md0 -l 0 -n 4 \
           /dev/md1 /dev/md2 /dev/md3 /dev/md4

%# # превращаем RAID10 в физический том, и добавляем его в группу
%# pvcreate /dev/md0
%# vgcreate TURBO /dev/md0

%# # смотрим количество экстентов
%# vgdisplay TURBO | grep -i 'free.*PE'

%## создаём том, занимающий всё свободное пространство
%# lvcreate --extents 88349 --name vol1 TURBO
%# modprobe jfs
%# mkfs -t jfs /dev/TURBO/vol1
%# mkdir /vol1
%# mount /dev/TURBO/vol1 /vol1
\end{verbatim}

На системе Debian Sarge с двумя процессорами
Athlon MP, 1 GB памяти, сетевой картой Intel PRO/1000MT и 40GB дисками
и коммутатором Netgear FS526T
с RAID 10 работающим поверх 8 блэйдов EtherDrive в полке Coraid
была зафиксирована произодвительность 23.58MB/s на чтение 
и 17.45MB/s на запись.
Измерения делались  
путём копирования 1GB файла в /dev/null после сброса кэша.
Во время копирования включена также команда sync.

RAID 10 в данном случае состоит из четырёх stripe\rq{}ов,
каждый из которых это пара зеркалированных дисков.
Вообще, можно вычислить производительность
набора блэйдов EtherDrive исходя только из количества stripe\rq{}ов в нём.
Для RAID 10 stripe\rq{}ов будет в два раза меньше чем дисков, 
поскольку каждый диск зеркалируется на другой диск.
Для RAID 5 один диск выделяется под чётность, оставляя остальные диски для stripe\rq{}ов.

Ожидаемая пропускная способность чтения равна количеству stripe\rq{}ов умножить на 6MB/s.
Это означает, что если Стэн изначальное купил бы две полки 
и собрал бы из них 18-блэйдный RAID 10 вместо своего 8-блэйдного, он мог ожидать 
прироста производительности более чем в два раза.
Стэну не нужна такая большая производительность и он хочет начать с маленькой файловой системы, 
размером 1.6TB.

Ниже показано как можно расширить файловую систему. 

На листинге не показан файл \#mdadm-aoe.conf\# и стартовые/стоповые скрипты. 
Конфигурационный файл mdadm указывает процессу mdadm, работающему в режиме монитора,
как выполнять горячую замену, чтобы можно было заменить сбойный диск в зеркале.
Подробности о группах резервирования (spare groups) можно прочитать на man-странице
по mdadm.

Увеличить файловую систему без размонтирования, установить массив RAID 10, добавить его в группу томов и затем увеличить файловую систему:

\begin{verbatim}
%# # когда для второй полки сделан RAID10, добавляем его в группу томов
%# vgextend TURBO /dev/md5
%# vgdisplay TURBO | grep -i 'free.*PE'

%# # увеличиваем логический том и файловую систему
%# lvextend --extents +88349 /dev/TURBO/vol1
%# mount -o remount,resize /vol1
\end{verbatim}

Стартовый и стоповый скрипты легко создать.
Стартовый скрипт просто собирает зеркалированные пары RAID 1,
собирает все RAID 0 и запускает процесс мониторинга mdadm.
Стоповый скрипт останавливает монитор mdadm,
останавливает RAID 0 и, в последнюю очередь,
останавливает RAID 1.

\subsection{Совместный доступ к блочным хранилищам}
Теперь, после того как мы увидели конкретный пример ATA over Ethernet в действии, 
может возникнуть вопрос: \dq{}А что произойдёт, если другой хост попытается получить
доступ к данным, когда с ними уже работает какой-то хост в сети?\dq{}
Сможет ли этот второй хост подмонтировать файловую систему JFS и получить доступ
к тем же данным? Короткий ответ такой: \dq{}Да, но это не безопасно!\dq{}.
JFS, как и ext3, как и многие другие файловые системы спроектированы
для использования на отдельном хосте. И для таких файловых систем
одновременный доступ с нескольких хостов приведёт к повреждениям.
Причина -- в кэш-буфере, который унифицирован с кэшем страниц в ядре 2.6.

Linux кэширует данные файловых систем в оперативной памяти 
везде, где это только возможно, дабы избежать использования
медленного блочного устройства и добиться хорошего прироста производительности.
Вы могли видеть результат наглядно, 
когда, например, запускали \textbf{find} дважды
поверх одного и того же каталога.

Некоторые файловые системы спроектированы так, что они могут использоваться одновременно 
несколькими хостами — такие файловые системы называют \textit{кластерными}.
Они имеют механизмы для проверки, синхронизирован ли кэш на всех
машинах с нижележащей файловой системой. 
Отличный пример такой системы с открытым кодом это GFS.
GFS использует кластерное программное обеспечение 
для того чтобы отследить, кто из группы хостов
работает с файловой системой.
Для того чтобы убедиться,
что разные хосты договариваются друг с другом
при совместном доступе к файловой системе,
в GFS используются блокировки.

Когда используются кластерные файловые системы, такие как GFS,
становится возможным совместный доступ множества хостов
к одному и тому же блочному устройству по сети.
Не нужно ничего типа NFS-сервера, поскольку
каждый хост работает с хранилищем непосредственно.

Но есть одна загвоздка.
Чем больше дисков вы используете, тем выше шансы, 
что один из дисков засбоит.
В этой ситуации обычно используется RAID, 
который добавляет избыточность.
К сожалению, программный RAID Linux
пока что не умеет работать с кластерными файловыми системами.
Это означает, что каждый хост 
в сети не сможет запускать mdadm.

Кластерное программное обеспечение для Linux развивается 
с большой скоростью. Есть надежда что рано или поздно RAID будет поддерживать кластерные файловые системы.
До этого момента мало вариантов использования AoE в кластерных системах.
Основная идея — централизовать функциональность RAID.
Можно купить один или два Coraid RAIDblade
и сделать чтобы кластерные узлы использовали их.
RAIDblade\rq{}ы будут управлять EtherDrive\rq{}ами, 
которые должны подключаться за них.
Или тоже самое можно сделать на обычной Linux-системе,
которая подключит массивы, сделает на них RAID
и с помощью ATA over Ethernet экспортирует его как готовое устройство.
Это может сделать, например, программа [vblade].

\subsection{Резервное копирование}
Поскольку AoE выводит недорогие диски в Ethernet-сеть, многие админы
могут заинтересоваться в использовании AoE для создания резервных копий.
Часто в стратегиях резервного копирования используются двухуровневые хранилища,
которые не такие быстрые как on-line хранилища, но и не такие медленные для доступа как лента.
ATA over Ethernet даёт возможность легко использовать дешёвые ATA-диски как хранилище второго уровня.

Но вообще говоря, с такими дешёвыми жёсткими дисками и стабильным программным RAID, 
почему бы не использовать диски как носитель для хранения резервных копий?
В такой системе резервного копирования, в отличие от ленточной,
есть возможность непосредственного доступа к заархивированным файлам.

В нескольких программах резервного копирования при создании резервных копий
используются преимущества возможностей файловых систем.
Например, используя жёсткие ссылки они могут делать полные бэкапы
с эффективностью инкрементальных. Подробности 
здесь ([rsync Backups http://www.mikerubel.org/computers/rsync\_snapshots])
и здесь ([Backup PC http://backuppc.sourceforge.net/]).

\subsection{Заключение}
Размещение недорогих дисков в локальной сети это одна из тех идей, 
которая заставляет подумать \dq{}Почему это интересно раньше никто не сделал?\dq{}.
С помощью простого сетевого протокола можно развязать хранилища 
и сервера, не используя при этом дорогого аппаратного обеспечения
и сложной сетевой инфраструктуры. В простой Ethernet сети нет необходимости
в сложном, развитом но требовательном к ресурсам стеке протоколов TCP/IP.

Если вы используете хранилища в локальной сети, и если настройки
доступа к хранилищу путём конфигурирование сети Ethernet достаточно, 
тогда ATA over Ethernet подойдёт вас лучше всего.
Если вас интересуют такие вещи как шифрование, возможность маршрутизации
и контроль доступа, посмотрите iSCSI.

С AoE появляется простое альтернативное решение для организации хранилищ на Linux, 
которой ранее явно не хватало. С простотой появляются и возможности.
AoE может использоваться как строительный блок в любом решении для хранения.
Дальше уже ваша фантазия.

\subsection{Преимущества и недостатки AoE}
Преимущества и недостатки AoE в сравнении с iSCSI.

Преимущества:
\begin{itemize}
\item  Низкая стоимость 
\item  Высокая производительность
\item  Простота
\end{itemize}

Недостатки:
\begin{itemize}
\item  Низкая масштабируемость, возможность использования только в пределах одной Ethernet-сети
\item  Отсутствие механизмов обеспечения безопасности
\item  Отсутствие механизмов контроля ошибок передачи данных, за исключением тех, что есть у самой сети Ethernet (см, например \url{http://lists.xensource.com/archives/html/xen-devel/2005-05/msg00832.html})
\end{itemize}

\subsection{Дополнительная информация}
\begin{itemize}
\item \htmladdnormallinkfoot{ATA over Ethernet}{http://xgu.ru/wiki/aoe} (рус.)
\item \htmladdnormallinkfoot{ATA over Ethernet}{http://en.wikipedia.org/wiki/ATA\_over\_Ethernet}(англ.) в Wikipedia
\item \htmladdnormallinkfoot{ATA Over Ethernet: Putting Hard Drives on the LAN}{http://www.linuxjournal.com/article/8149} — статья в Linux Journal
\item \htmladdnormallinkfoot{Resources for "ATA Over Ethernet: Putting Hard Drives on the LAN"}{http://www.linuxjournal.com/article/8201} (англ.)
\item \htmladdnormallinkfoot{Resources for "ATA Over Ethernet: Putting Hard Drives on the LAN"}{http://www.linuxjournal.com/article/8201} (англ.) — дополнительные ссылки в Linux Journal
\item \htmladdnormallinkfoot{The ATA over Ethernet (AoE) Protocol}{http://www.linux-mag.com/index.php?option=com\_content\&task=view\&id=2069\&Itemid=2307} (англ.) — статья на Linux Magazine (требуется регистрация)
\item \htmladdnormallinkfoot{Using AoE in FreeBSD}{http://www.coraid.com/support/freebsd/usingaoe.html} — Поддержка AoE в FreeBSD
\item \htmladdnormallinkfoot{Протоколы сетей хранения данных. Часть I — ATA over Ethernet}{http://www.samag.ru/cgi-bin/go.pl?q=articles;n=09.2005;a=15} — статья в журнале Системный администратор
\item \htmladdnormallinkfoot{The Coraid Linux NAS HOWTO}{http://www.coraid.com/support/cln/CLN-HOWTO.html} (англ.) — HOWTO по разворачиванию NAS на базе ATA over Ethernet
\item \htmladdnormallinkfoot{(Xen-users) HOWTO: AOE in domU and boot from it.}{http://lists.xensource.com/archives/html/xen-users/2006-07/msg00595.html} (англ.
\item \htmladdnormallinkfoot{Access over Ethernet Insecurities in AoE SLIDES}{http://www.slideshare.net/amiable\_indian/access-over-ethernet-insecurites-in-aoe/} (англ.)
\item \htmladdnormallinkfoot{"iSCSI killer" Native in Linux}{http://hardware.slashdot.org/article.pl?sid=06/07/31/1143230} (англ.) — обсуждение AoE на Slashdot
\item \htmladdnormallinkfoot{OpenNews: ATA over Ethernet в Linux}{http://www.opennet.ru/openforum/vsluhforumID3/36130.html} — обсуждение статьи на OpenNet
\item \htmladdnormallinkfoot{OpenNews: Построение SAN для Xen на основе DRBD, LVM и GNBD" }{http://www.opennet.ru/openforum/vsluhforumID3/36804.html} — другое обсуждение на OpenNet, где затрагиваются вопросы сравнения AoE и iSCSI
\end{itemize}


