Ata over ethernet настройка

Обновлено: 15.01.2025

Задача современных систем обработки информации – надежное хранение данных. Сегодня мы поговорим о SAN (Storage Area Networks), а если быть точнее, то о протоколах, которые обеспечивают их надежность и безопасность обрабатываемых данных.

В крупных компаниях SAN соединяет многочисленные сервера к централизованному пулу дисков хранения. По сравнению с администрированием сотни серверов, где каждый из них имеет собственное дисковое хранилище, сети SAN упрощают эксплуатацию и обслуживание. Однако есть недостаток в использовании SAN – каждое устройство (дисковый массив) «принадлежит» серверу, который инициировал соединение. В отличие от SAN этого недостатка нет у NAS (Network Attached Storage), где доступ от многих серверов к одному файлу не блокируется и информация от такого взаимодействия не теряется. Впрочем, превратить SAN в NAS просто – следует использовать кластерные файловые системы – GFS (Global File System) [2], OCFS2 (Oracle Cluster File System) [3] и аналогичные.

На каких технологиях строятся современные SAN-сети? Широкоизвестным видом является FiberChannel (оптический канал передачи данных). Название FiberChannel не должно вас пугать – этот тип соединения может быть реализован и на основе витой пары (см. Wikipedia [1]). Типичная сеть состоит из нескольких оптических коммутаторов, которые соединены между собой и посредством HBA (Host Bus Adapter) подключены к дискам. Передача данных основана на протоколе SCSI. Не стоит говорить, что это самое дорогое решение.

Конкурентом технологии FiberChannel является iSCSI-протокол. Передача данных в этом случае производится не по оптическим каналам, а по витой паре (ethernet). Сеть в данном случае представлена ethernet-коммутатороми и UTP-кабелями категории 5e/6. Работа протокола iSCSI полагается на функционирование TCP/IP-протокола.

Следующим протоколом, который используется при разработке SAN-сетей, является AoE (ATA over Ethernet). ATA-протокол инкапсулируется в ethernet-кадры и в отличие от iSCSI не предусмотрен для маршрутизации. Однако AoE обладает интересной реализацией обнаружения AoE-устройств.

Наиболее перспективной и проработанной технологией можно считать протокол HyperSCSI, который в некоторой степени похож на iSCSI, но не использует TCP/IP в качестве своей основы. В заключительной части этого цикла статей я приведу результаты измерения скоростных характеристик, а сейчас немного вас заинтригую – как оказалось, AoE не самый быстрый протокол.

Сегодняшняя статья посвящена, пожалуй, самому молодому и амбициозно продвигаемому протоколу – AoE (ATA over Ethernet). Впервые о нем широко заговорили в 2004 году. Компания – разработчик протокола и на сегодняшний день единственный производитель устройств хранения информации, работающих с этим протоколом – Coraid Inc. [4]. Коротко охарактеризовать данный протокол можно фразой – «ATA-команды инкапсулируются в ethernet-кадры». Протокол уже получил свой номер в организации IANA, поэтому включение его поддержки в маршрутизаторы – дело ближайшего времени. Хотя было бы наивно думать, что сам по себе протокол будет поддержан всеми производителями коммуникационного оборудования. Впрочем, немало зависит и от настойчивости самой фирмы Coraid.

Краткий экскурс в основу протокола AoE

Рассмотрим заголовок ethernet-пакета для протокола AoE (см. рис. 1). Первые 14 байт в заголовке типичны для ethernet-пакета. Что же касается полей Ver, Flags, Error, то они детально расписаны в документации на протокол AoE [5].

Рисунок 1. Заголовок ethernet-пакета для протокола AoE

Содержимое поля Arg зависит от того, какую команду передали в поле Command. Существует два варианта – «Выполнить ATA-команду» (Command 0) и «Запросить конфигурационную информацию» (Command 1). Первая команда передается на сторону сервера, и ATA-устройство сервера исполняет ATA-команды, которые скомпонованы в блоке Arg. Ethernet-пакет для протокола AoE запрещается разбивать на более мелкие фрагменты. Вторая команда предназначена для обнаружения и управления AoE-устройствами. Вот такой простой протокол получился.

Итак, на данный момент доступны GPL-драйвера для Linux 2.4, 2.6. В пакет ПО входят как модули (aoe-2.4.XX/aoe2.6.YY), так и утилиты (aoetools) с виртуальным наносервером (vblade). С января этого года AoE-драйверы включены в поставку Linux-ядер версии 2.6. Поэтому, в случае когда вы пересобираете Linux-ядро версии 2.6, можете смело выбрать компиляцию AoE – подсистемы. Также на сегодняшний день готовы порты для BSD-систем. В планах компании стоит выпуск драйверов и под Windows-платформу. Что касается остальных UNIX-систем, то для них готовых драйверов нет, по крайней мере сейчас.

Ядро дистрибутива, на котором будут проводиться сегодняшние испытания, – это Linux Kernel серии 2.4.

Примерный вывод должен быть таким:

Found kernel version 2.4.26

Install directory is /lib/modules/2.4.26/kernel/net/aoe

mkdir -p /lib/modules/2.4.26/kernel/net/aoe

install -m 644 aoe.o /lib/modules/2.4.26/kernel/net/aoe

Directory /dev/etherd exists, skipping devnode installation.

Подготовка AoE-модулей завершена. В /etc/modules.conf прописаны параметры для устройств на основе AoE-протокола и созданы файлы устройств в директории /dev/etherd/.

alias block-major-152 aoe

alias char-major-152 aoe

Следующий наш шаг – это подготовка виртуального наносервера (vblade). Дело в том, что Coraid Inc., помимо раздачи под GPL-лицензией драйверов для AoE, является и единственным производителем устройств хранения информации EtherBlade, которые пока представлены только на рынке США и сопредельных государств. Однако, судя по информации с сайта компании, идет процесс создания дистрибьюторской сети.

Что из себя представляет EtherBlade?

EtherBlade сегодня представлен двумя продуктами – это шасси размеров 3U и 2U. В первом варианте «лезвия» хранятся 10 жестких дисков формата 3,5 дюйма. Во втором варианте уже используются 18 жестких дисков меньшего формата, а именно 2,5 дюйма. Если в самом начале карьеры EtherBlade использовались PATA-диски, то сегодня выпускаются модификации для SATA-дисков. Внутри отдельного лезвия находится контроллер памяти, процессор, ethernet-порт (см. рис. 2). Каждое такое лезвие потребляет около 12 Ватт, и гигабайт его стоимости начинается от 1,75 $. Для более тонкого варианта EtherBlade данные соответственно следующие: 5,5 Вт и 7,06 $. Лезвия подключаются во внешний 1-гигабитный свитч, который в свою очередь может быть подключен в более скоростной 10-гигабитный. Таким образом достигается масштабирование данного решения.

Рисунок 2. Структура единичного «лезвия»

Рисунок 3. EtherBlade

Чтобы не ждать поставки аппаратного «лезвия», можно воспользоваться его виртуальным аналогом – программным vblade.

Настройка наносервера vblade.

Получились 2 исполняемых файла – vblade и vbladed. Последний является обычным скриптом, который запускает vblade. Его конструкция напоминает нижеследующий вариант (параметры изменены):

где «9» – номер шасси, «0» – номер слота (диска или лезвия), «eth0» – название интерфейса, по которому будет происходить обмен данными и «/dev/hda» – собственно устройство, которое в формате «AoE» делается доступным по ethernet.

С другой машины, запустив там предварительно процесс инсталляции драйвера AoE, мы увидим в /var/log/messages следующее:

aoe: aoe_init: AoE v2.4-3 initialised.

aoe: 000c6e784408 e9.0 v4000 has 80418240 sectors

То есть устройство распознано драйвером AoE. Здорово. Теперь запустив fdisk, мы увидим, что на нем находится:

Command (m for help): p

Disk /dev/etherd/e9.0: 41.1 GB, 41174138880 bytes

255 heads, 63 sectors/track, 5005 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

/dev/etherd/e9.0p1 * 1 924 7421998+ b W95 FAT32

/dev/etherd/e9.0p2 925 1217 2353491 7 HPFS/NTFS

/dev/etherd/e9.0p3 1218 1439 1783183+ c W95 FAT32 (LBA)

/dev/etherd/e9.0p4 2493 4865 19061122+ f W95 Ext"d (LBA)

/dev/etherd/e9.0p5 2493 4865 19061091 b W95 FAT32

Все так и обстоит на самом деле – это действительно структура удаленного хранилища, в нашем случае ATA-диска. Для получения статистики воспользуемся утилитой aoe-stat из пакета aoetools.

И это правильно, т.к. sysfs разработан в ядрах серии 2.6. Однако данный факт не помешает нам вручную узнать состояние наносервера.

Досадной мелочью (по крайней мере в драйверах 2.4) является невозможность использовать отдельные разделы в случае, когда наносервер предоставляет для целей хранения весь диск. Чтобы обойти это ограничение, создадим один раздел занимающий весь объем диска. Командная строка для vblade будет выглядеть, например, так:

В этом случае монтирование «лезвия» на удаленной машине не отличается от монтирования локального диска.

У данного решения есть и минусы. За счет простоты реализации протокола увеличивается нагрузка на подсистему ввода/вывода. Не проработана система шифрования трафика, передаваемого по сети. Как уже отмечалось выше, на рынке представлены только аппаратные продукты одной компании.

В следующей части мы познакомимся с протоколом iSCSI, узнаем, что такое «инициатор» и «iSCSI-target», попробуем подключить Windows- и Linux-клиенты к серверу с хранилищем данных по iSCSI-протоколу.

SAN (Storage Area Network) – сеть, спроектированная для подключения устройств хранения (дисковых массивов и магнитных лент) к серверам. Характерно, что SAN отличается от других способов сетевого хранения информации за счет использования методики блочного доступа. Фактически сервер запрашивает информацию типа «блок X с диска Y». Передаваемая информация в SAN-сетях очень похожа на ту, что циркулирует по шине данных в дисках ATA и SCSI.

ATA over Ethernet (AoE) - Протокол для предоставления доступа к блочным устройствам по L2 сети. Подходит для построения недорогих производительных сетевых хранилищ.

Содержание

Target (Цель) - Сервер AoE, предоставляющий доступ к блочным устройствам по соответствующему протоколу;
Initiator (Инициатор) - Клиент AoE;
Shelf (полка) - логическая группа слотов (блочных устройств) AoE;
Slot (слот) - блочное устройство AoE;

В ALT Linux требуемое ПО для работы с данным протоколом представлено пакетами:

aoetools - вспомогательные утилиты для диагностики AoE;
vblade - наиболее популярный демон AoE;
ggaoed - также демон реализующий AoE;

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

Данный модуль можно прописать в ОС для автоматической загрузки при старте:

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

vblade использует RAW sockets для осуществления сетевого взаимодействия. В том случае, когда нежелательно запускать vblade от администратора, возможно использовать filesystem capabilities для предоставления необходимого доступа:

Предоставить блочное устройство (или файл) можно простой командой:

Таким образом vblade начнёт отдавать локальное блочное устройство /dev/sdc с интерфейса eth1 как устройство 1 в слоте 9.

Для штатного включения демона необходимо выполнить команды:

ggaoed - Функциональный современный демон AoE, но написан с расчётом на системные примитивы Linux и потому не является мультиплатформенным. В комплекте с демоном поставляется утилита ggaoectl, которая отображает текущие параметры и статистику.

Для настройки демона необходимо отредактировать конфигурационный файл /etc/ggaoed.conf , который может выглядеть так:

Для штатного включения демона необходимо выполнить команды:

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

Затем можно просмотреть найденные в сети устройства:

В случае, если команда aoe-stat не показывает желаемый результат, необходимо провести диагностику проблем сетевой связности.

После подгрузки модуля aoe в ОС появится директория /dev/etherd с файлами устройств. Возможно запустить процедуру обнаружения AoE устройств также с помощью простейшей команды:

В случае с текущим примером мы обнаружим файл блочного устройства /dev/etherd/e1.1 .

ATA over Ethernet ( AoE ) - это сетевой протокол, разработанный компанией Brantley Coile и предназначенный для простого и высокопроизводительного доступа к блочным устройствам хранения данных по сетям Ethernet . Он используется для построения сетей хранения данных (SAN) с использованием недорогих стандартных технологий.

СОДЕРЖАНИЕ

Описание протокола

AoE работает на уровне 2 Ethernet . AoE не использует интернет-протокол (IP); к нему нельзя получить доступ через Интернет или другие IP-сети. В этом отношении он больше похож на Fibre Channel over Ethernet, чем на iSCSI .

Благодаря меньшему количеству уровней протокола этот подход делает AoE быстрым и легким. Это также делает протокол относительно простым в реализации и предлагает линейную масштабируемость с высокой производительностью. Спецификация AoE составляет 12 страниц по сравнению с 257 страницами iSCSI.

Формат заголовка AoE:

AoE имеет присвоенный IEEE EtherType 0x88A2.

Инкапсуляция ATA

Жесткие диски SATA (и более старые PATA) используют протокол Advanced Technology Attachment (ATA) для выдачи команд, таких как чтение, запись и состояние. AoE инкапсулирует эти команды в кадры Ethernet и позволяет им перемещаться по сети Ethernet вместо SATA или 40-контактного ленточного кабеля. Хотя внутри AoE используется протокол ATA, он представляет диски операционной системе как SCSI. Также фактические диски могут быть SCSI или любого другого типа, AoE не ограничивается дисками, которые используют набор команд ATA. Используя драйвер AoE, операционная система хоста может получить доступ к удаленному диску, как если бы он был напрямую подключен.

Инкапсуляция ATA, обеспечиваемая AoE, является простой и низкоуровневой, что позволяет выполнять преобразование либо с высокой производительностью, либо внутри небольшого встроенного устройства, либо и то, и другое.

Возможность маршрутизации

AoE - это протокол уровня 2, работающий на уровне канала передачи данных, в отличие от некоторых других протоколов SAN, которые работают поверх уровня 3 с использованием IP. Хотя это снижает значительные накладные расходы на обработку TCP / IP, это означает, что маршрутизаторы не могут маршрутизировать данные AoE по разнородным сетям (например, университетской сети или Интернету). Вместо этого пакеты AoE могут перемещаться только в пределах одной локальной сети хранения данных Ethernet (например, набор компьютеров, подключенных к одному коммутатору или в одной подсети LAN или VLAN ).

Безопасность

Отсутствие маршрутизации AoE - единственный механизм безопасности (т. Е. Злоумышленник не может подключиться через маршрутизатор - он должен физически подключиться к локальному коммутатору Ethernet, где туннелирование кадров Ethernet по маршрутизируемым сетям не используется). Однако не существует специальных механизмов AoE для проверки или шифрования пароля. Протокол обеспечивает цели AoE, такие как устройства хранения Coraid , vblade и GGAOED, для создания списков доступа («масок»), разрешающих соединения только с определенных MAC-адресов (хотя они могут быть подделаны). Самый безопасный AoE за счет использования сетей Ethernet VLAN.

Строка конфигурации

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

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

Поддержка операционной системы

Следующие операционные системы обеспечивают поддержку ATA через Ethernet (AoE):

Операционные системы	Служба поддержки	Сторонние драйверы
Linux	Родной (2.6.11+)	Coraid
Окна	Сторонний	StarWind Software AoE-инициатор, WinAoE, WinVBlock
Mac OS X 10.4 и выше	Сторонний	С 2006 по 2010 год 2ºFrost Technologies разрабатывала собственное программное обеспечение и продавала решения для хранения данных AoE на рынках Windows и Mac. Реализация для Mac была собственной, а версия для Windows была изготовлена OEM-производителем StarWind Software.
Mac OS X 10.5 и 10.6	Сторонний	Небольшое дерево коммуникаций
Солярис	Сторонний	Coraid
FreeBSD	Сторонний	Coraid (устаревший)
OpenBSD	Родной (от 4,5 до 5,6)
VMware	Сторонний	Coraid
План 9 от Bell Labs	Родной

Аппаратная поддержка

Компания Coraid предложила ряд устройств AoE SAN под брендом EtherDrive , а также бездисковые шлюзы, которые добавляют функциональность сетевого хранилища с использованием протоколов NFS или SMB для одного или нескольких устройств AoE. Бренд Coraid теперь принадлежит SouthSuite, Inc., копии, основанной Брантли Койлом, который основал Coraid .

В 2007 году LayerWalker анонсировал оборудование AoE под названием miniSAN, работающее как в Fast, так и в Gigabit Ethernet. Семейство продуктов miniSAN предлагает стандартные функции сервера AoE, а также другие функции управления, предназначенные для ПК, потребительского рынка , а также малого и среднего бизнеса .

Связанные понятия

Хотя AoE - простой сетевой протокол, он открывает сложную область возможностей хранения. Чтобы понять и оценить эти сценарии хранения, полезно знать несколько концепций.

Сети хранения данных

SAN позволяет удалить физический жесткий диск с сервера, который его использует, и разместить в сети. Интерфейс SAN в принципе аналогичен несетевым интерфейсам, таким как SATA или SCSI. Большинство пользователей не будут использовать интерфейс SAN напрямую. Вместо этого они будут подключаться к серверу, который использует диск SAN вместо локального. Однако также можно использовать прямое соединение.

При использовании сети SAN для доступа к хранилищу существует несколько потенциальных преимуществ перед локальным диском:

Увеличить емкость хранилища проще, и объем хранилища практически неограничен.
Легче перераспределить емкость хранилища.
Данные могут быть переданы.
Кроме того, по сравнению с другими формами сетевого хранения SAN низкоуровневые и высокопроизводительные.

Использование сетей хранения данных

Чтобы использовать диск SAN, хост должен отформатировать его в файловой системе. Однако, в отличие от диска SATA или SCSI, к жесткому диску SAN могут обращаться несколько машин. Это источник опасности и возможностей.

Традиционные файловые системы (такие как FAT или ext3 ) предназначены для доступа с одного хоста и вызывают непредсказуемое поведение при доступе с нескольких машин. Такие файловые системы могут использоваться, и AoE предоставляет механизмы, с помощью которых цель AoE может быть защищена от одновременного доступа (см .: Config String).

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

Однажды один из клиентов компании-интегратора, где я работал, попросил оперативно нарисовать проект небольшой системы хранения данных. Как назло, специальный человек по SAN оказался недоступен и задачу поручили мне. На тот момент мои знания по СХД сводились к непробиваемой идее "Fibre Channel – это круто, а iSCSI – не очень".

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

Если инженер не особенно знаком с сетями хранения данных (СХД), то выбор подходящего устройства часто начинается с изучения рынка в преломлении собственных стереотипов. Например, я в свое время обычно останавливался на простых DAS-системах, что удивительно дополняло своей нелогичностью тезис про "крутость" Fibre Channel. Зато DAS был понятным и не требовал чтения длинных руководств администратора и погружения в темный мир сетей хранения.

Если в организации просто заканчивается место на общем сетевом диске, то хватит и недорогого сервера с относительно высокой плотностью дисков, в качестве задела на будущее. Из специализированных систем неплохо подойдет сетевое файловое хранилище (NAS), вроде Synology DS414 SLim. На нем и общие папки создавать удобно, и права гибко настраиваются, и с Active Directory интеграция есть.

Чем мне нравятся хранилища Synology, так это удобным интерфейсом с множеством плагинов на любые сценарии использования. Но поведение у них бывает весьма странным. Например, у одного заказчика был Synology DS411+II. Работал прекрасно до очередной перезагрузки, после которой не включился. Не спрашивайте, как я до этого дошел, но алгоритм запуска после сбоя был следующий:

1. Вынуть все диски, включить устройство, выключить устройство;

2. Воткнуть один диск, включить устройство, выключить устройство;

3. Воткнуть второй диск, включить устройство, выключить устройство;

4. Повторить для третьего и четвертого диска. После установки четвертого диска, устройство включается и работает.

Способ был опубликован на форуме Synology и оказалось, что я не один такой везучий. С тех пор предпочитаю небольшие серверы с GNU\Linux на борту, у них хотя бы с диагностикой проще.

Из сборок для NAS могу порекомендовать Openmediavault.

Все усложняется когда нужно нарастить дисковый объем имеющихся серверов или появляются мысли о высокой доступности. Тут-то и возникает соблазн построить полноценную NAS или впасть в другую крайность, ограничившись простой дисковой полкой DAS.

Пара слов о том, что такое SAN и DAS. Просто освежить память.

SAN, Storage Area Network – архитектурное решение для подключения по сети внешних устройств хранения данных, вроде дисковых массивов и ленточных библиотек. Причем, подключить на блочном уровне, чтобы клиент работал с ними так же, как с обыкновенными локальными дисками. В русскоязычной литературе используется аббревиатура СХД (Сеть Хранения Данных) – не путайте с Системой Хранения Данных, которой может считаться любая дисковая полка.

В этой статье я не буду касаться программных реализаций, вроде Storage Spaces в среде Windows, а ограничусь железными и архитектурными нюансами СХД.

Начнем с типовых решений для хранения данных, которые предполагают использование специальных сетей и интерфейсов, так как с ними больше всего вопросов.

Самым недорогим способом организации SAN является интерфейс Serial Attached SCSI (SAS). Тот самый, с помощью которого подключаются диски в любом современном сервере. Используют SAS и для прямого подключения внешнего дискового массива к серверу.

Для массива DAS возможна организация отказоустойчивого подключения к нескольким серверам. Делается это с помощью Multipath, технологии коммутации клиента и СХД по нескольким маршрутам. Но большей популярностью пользуется разделение дисков между серверами, которые уже самостоятельно собирают из них группы RAID и делят на тома. Подобная схема называется "Разделяемый JBOD".

Для подключение к серверу используются адаптеры (HBA) под конкретный интерфейс, которые просто позволяют ОС увидеть готовые дисковые тома.

Стоит отметить, что SAS поддерживает три стандарта:

SAS-1, со скоростью 3 Гб/с на устройство;

SAS-2, со скоростью 6 Гб/с;

При планировании архитектуры стоит также иметь в виду отличия в разъемах SAS, что часто приводит к путанице при заказе кабелей. Самыми популярными при подключении внешнего оборудования являются SFF-8088 (mini-SAS) и SFF-8644 (mini-SAS HD).

Являясь частностью SCSI, SAS поддерживает экспандеры, что позволяет подключать до 65 535 устройств к одному контроллеру и порту. Конечно, цифра скорее теоретическая и не учитывает различные накладные расходы. Чаще всего встречаются контроллеры с реальным ограничением в 128 дисков, но масштабировать подобный SAN для двух и более серверов простыми экспандерами уже не так удобно. В качестве более адекватной альтернативы можно использовать коммутаторы SAS. По сути, это те же экспандеры, но с поддержкой распределения ресурсов по серверам, т.н "зонирование". Например, для стандарта SAS-2 наибольшей популярностью пользуется LSI 6160.

С помощью коммутаторов SAS возможна реализация отказоустойчивых схем для нескольких серверов без единой точки отказа.

Из плюсов использования SAS можно отметить:

Низкую стоимость решения;

Высокую пропускную способность – даже при использовании SAS-2 получится 24 Гб/с на каждый порт контроллера;

Не обошлось и без минусов:

Отсутствуют механизмы репликации средствами дискового массива;

В качестве типового решения для малых и средних организаций разберем создание небольшого отказоустойчивого кластера виртуальных машин. Под кластер выделим два узла с единственным дисковым массивом. В качестве условного среднего объема дискового тома выберем 1 ТБ.

Замечу, что программными решениями вроде StarWind Native SAN можно получить такой же кластер без отдельного дискового массива, или же с простыми JBOD. Кроме того, большинство гипервизоров поддерживают в качестве хранилищ сетевые ресурсы NFS или SMB 3.0. Но в программных реализациях больше нюансов и «слабых звеньев» из-за большей сложности системы. Да и производительность обычно ниже.

Для сборки такой системы понадобится:

HBA для серверов;

Дисковый массив возьмем для примера HP MSA 2040 с двенадцатью отсеками под HDD. Для подключения будем использовать SAS 3.0 на скорости 12 Гб/с. Посчитаем первым попавшимся

Каждый сервер будет соединятся с каждым контроллером СХД для Multipathing.

На мой взгляд, SAS 3.0 оптимален, если не нужны распределенные SAN-сети и не требуется детальное разграничение прав доступа к СХД. Для небольшой организации так можно достичь отличного баланса цены и производительности.

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

Традиционным выбором для построения SAN является Fibre Channel (FC) – интерфейс, связующий узлы сети по оптическому волокну.

FC поддерживает несколько скоростей: от 1 до 128 Гб/с (стандарт 128GFC вышел как раз в 2016). В основном используются 4GFC, 8GFC и 16GFC.

Существенные различия по сравнению с SAS-системами проявляются при проектировании крупных SAN:

Расширение производится не за счет экспандеров, а возможностями топологии сети;

В небольших организациях обычно применяют структуру с одним коммутатором (single-switch), когда один сервер через один коммутатор подключается к дисковому массиву. Такая схема составляет основу остальных топологий: каскад (cascade), решетка (mesh) и кольцо (ring).

Наиболее масштабируемая и отказоустойчивая схема называется "центрально-распределенная" (core-edge). Она напоминает известную всем сетевую топологию “звезда”, но только в середине два центральных коммутатора, распределяющих трафик по периферийным. Частным случаем этой схемы является “коммутируемая архитектура” (switched fabric), без периферийных коммутаторов.

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

Есть два типа трансиверов:

Коротковолновые (Short Wave, SW, SX) – подходят только для многомодовых волокон;

К обоим типам кабель подключается разъемом LC, а вот SC-разъемы встречаются довольно редко.

Типичный HBA c двумя портами FC

При выборе оборудования для SAN не лишним будет проверить все компоненты по таблицам совместимости производителя железа. Активное сетевое оборудование всегда лучше выбирать одного бренда, чтобы избежать проблем совместимости даже в теории – это стандартная практика для подобных систем.

К плюсам решений на FC можно отнести:

Возможность построения территориально распределенной SAN;

Высокая скорость передачи данных;

На другой чаше весов традиционно лежит стоимость.

Системы хранения из раздела про SAS можно построить и на 16GFC, заменив лишь HBA и контроллер дисковой полки. Стоимость при этом вырастет уже до 1 845 790 ₽.

В своей практике я встречал у заказчика даже построенный на FC массив DAS, заполненным дисками менее, чем наполовину. Почему не использовали SAS? Самый оригинальный ответ был такой: «а что, можно было?».

В более сложной инфраструктуре FC становится структурно более похож на TCP\IP. У протокола также описаны уровни, как и у стека TCP\IP, существуют маршрутизаторы и коммутаторы, описано даже "тегирование" для изоляции сегментов на манер VLAN. Кроме того, на FC-коммутаторах исполняются службы разрешения имен и обнаружения устройств.

Не буду углубляться в тонкости, ведь на тему FC написано уже немало хороших статей. Обращу внимание лишь на то, что при выборе коммутаторов и маршрутизаторов для SAN нужно обращать внимание на логические типы портов. В разных моделях поддерживаются разные сочетания основных типов из таблицы:

Тип Устройства	Наименование	Описание
Сервер	N_Port (Node port)	Используется для подключения к коммутатору или конечному устройству.
NL_Port (Node Loop port)	Порт с поддержкой топологии «петля».
Коммутатор\ Маршрутизатор	F_Port (Fabric port	Для подключения N_Port, «петля» не поддерживается.
FL_Port (Fabric Loop port),	Порт с поддержкой «петли».
E_Port (Expansion port	Порт для соединения коммутаторов.
EX_port	Порт для соединения коммутатора и маршрутизатора.
TE_port (Trunking Expansion port)	E-port с поддержкой VSAN.
Общие	L_Port (Loop port)	Любой порт с поддержкой петли (NL_port или FL_port).
G_port (Generic port)	Любой незанятый порт устройства с авто определением.

Статья была бы неполной без упоминания варианта построения SAN на InfiniBand. Этот протокол позволяет достичь действительно высоких скоростей передачи данных, но по стоимости выходит далеко за рамки SMB.

Можно обойтись и без изучения новых видов сетей, используя старый добрый Ethernet.

Популярный протокол для создания SAN в Ethernet-сетях называется Internet Small Computer Systems Interface (iSCSI). Строится он поверх TCP\IP, и основной его плюс в приличной работе по обычной гигабитной сети. В обиходе такие решения часто называют "бесплатный SAN". Разумеется, гигабита под серьезные задачи не хватит, и к вашим услугам сети 10 Гб/с.

К безусловным плюсам можно отнести низкую стоимость базового оборудования. Так как iSCSI реализуется программно, можно установить соответствующие приложения на обычные серверы. Большинство NAS класса SOHO поддерживают этот протокол изначально.

У заказчика однажды остро встал вопрос перемещения Exchange 2003 с умирающего сервера. Решили виртуализировать его с минимальным простоем. Для этого подняли iSCSI-target на том самом NAS Synology DS411 из первой части статьи и подключили к Exchange. Далее перенесли туда БД и мигрировали на MS Virtual Server 2005 c помощью disk2vhd. После успешной миграции перенесли базу обратно. Позже такие операции проводились при переходе с MS Virtual Server на VMware.

Разумеется, для построения SAN на iSCSI, даже если для задач хватает и гигабитной сети, не стоит "выпускать" его в общий LAN. Работать оно будет, но широковещательные запросы и прочий служебный трафик непременно скажутся на скорости и создадут помехи пользователям. Лучше построить отдельную изолированную сеть со своим оборудованием. Или, в крайнем случае, хотя бы выделить подсеть с iSCSI в отдельный VLAN. Стоит отметить, что для достижения максимальной производительности таких систем необходимо включать поддержку Jumbo Frames на всем пути следования пакетов.

В качестве меры экономии бюджета может возникнуть мысль об объединении гигабитных портов при помощи агрегации каналов (LACP). Но, как правильно заметил VitalKoshalew в комментариях, реальной балансировки между отдельным сервером и хранилищем с помощью LACP не получится. Более правильным бюджетным решением будет использование технологий Multipath на верхних уровнях модели OSI.

К слову, совсем правильное iSCSI-решение на базе 10 Гб сети, с поддерживающими аппаратное ускорение iSCSI сетевыми картами и соответствующими коммутаторами приближается по стоимости к FC.

Подобная схема сети возможна благодаря тому, что iSCSI работает поверх TCP\IP.

Из интересных решений на базе iSCSI можно отметить работу тонких клиентов без сервера терминалов – вместо локальных дисков используется том iSCSI. Гигабитной сети вполне достаточно для такой работы, а реализовать что-либо подобное другими средствами не так просто.

Возможность построения территориально распределенной сети;

Задержки при обращении к данным могут быть существенными, особенно при работе с пулом виртуальных машин;

Есть и более "взрослая" альтернатива iSCSI. Можно использовать ту же сеть Ethernet, но протокол хранения завернуть непосредственно в кадры Ethernet, минуя TCP\IP. Протокол называется Fibre Channel over Ethernet (FCoE) и для работы использует Ethernet 10 Гб. Помимо традиционной оптики, можно использовать специальные медные кабели или витую пару категории 6a.

Важное отличие от FC в том, что порт Ethernet можно использовать совместно с TCP\IP. Для этого нужны специальные сетевые адаптеры, так называемые Converged Network Adapter (CNA) с поддержкой FC и FCoE, хотя есть и программные решения. Поскольку протокол работает ниже уровня TCP\IP, то простой коммутатор не подойдет. Кроме того, обязательно должна быть поддержка Jumbo Frames и Data Center Bridging (DCB, иногда встречается Data Center Ethernet). Подобные решения обычно стоят дороже (например, Cisco серии Nexus).

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

Если вернуться к нашему маленькому, но гордому кластеру виртуализации, то для него решения на 10 Гб/с iSCSI и FCoE будут практически одинаковыми по стоимости, но в случае с iSCSI можно использовать дешевые гигабитные сети.

Также стоит упомянуть и довольно экзотичный протокол ATA over Ethernet (AoE), схожий по своей работе с FCoE. Дисковые массивы с ним – редкость, обычно используются программные решения.

Выбор конкретной реализации системы хранения требует вдумчивого изучения конкретной ситуации. Не стоит подключать дисковый массив с помощью FC просто потому, что "оптика" звучит гордо. Решение на SAS даст аналогичную или даже большую производительность там, где оно архитектурно уместно. Если не брать в расчет стоимость и сложности обслуживания, то существенным отличием между всеми описанными технологиями подключения СХД будет дистанция соединений. Эту мысль хорошо иллюстрирует один из кадров презентации SNIA:

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

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

Читайте также: