К выходу UC3200 компания готовилась очень долго, поскольку устройство относится уже не к классическим NAS, а к SAN. Да, пока в относительно простом iSCSI-варианте, но это уже шанс побороться с более крупными игроками хотя бы в плане цены. И именно «двухголового» контроллера в режиме «активный — активный» для этого и не хватало.

Технические характеристики

2U-шасси контроллера имеет габариты 88 × 431 × 692 мм и весит почти 20 кг. Спереди UC3200 ничем особенным не отличается от любой другой «хранилки» — 12 лотков для SAS-дисков, ушки и вынесенные элементы управления: кнопка питания и кнопка отключения звукового оповещения. Но, помимо индикаторов питания и уведомления о проблемах, тут есть ещё один, сообщающий о работе обоих контроллеров. Из других мелочей отметим защёлки на дисковых лотках, которые не позволят случайно вытащить их.

А вот при взгляде на заднюю часть шасси сразу становится понятно, что это не простая СХД. В нише слева, как обычно, друг над другом расположились два (1+1) блока питания, мощностью 500 Вт каждый. Если БП вставлен, но не подключён к электросети или имеет какие-то проблемы, то будет звучать звуковой сигнал (громкий писк, проще говоря), который можно отключить упомянутой выше кнопкой на передней панели.

Правая же часть корпуса занята двумя одинаковыми контроллерами. На задней панели у каждого из них следующие порты: два RJ-45 1GbE и один 10GbE, COM и SAS для подключения дисковых полок. Там же находятся индикаторы питания, состояния и уведомления о проблемах, а также индикатор извлечения контроллера. Для защиты разъёмов между контроллером и корзиной предусмотрен рычаг со ступором, так что резко и до упора блок в шасси затолкать невозможно. Для доводки придётся нажать на рычаг, а затем закрутить винт.

Внутри модуль контроллера устроен довольно просто. Два крупных вентилятора делят его на две неравные части. На одном конце находятся разъёмы для подключения к шасси, рядом с которыми располагается собственное хранилище контроллера на базе SATADOM. Отдельно подчёркивается, что ОС не задействует для своих нужд диски в корзине. Естественно, контроллеры могут иметь разные версии ОС, что важно для безопасного поэтапного обновления ПО.

В другой части находятся четыре слота для модулей памяти DDR4-2133 ECC (до 64 Гбайт суммарно), райзер-карта PCIe 3.0 x8 для установки сетевых адаптеров 10/25GbE и других карт расширения половинной длины, а также процессор Intel Xeon D-1521 (4/8 ядра/потоков, 2,4-2,7 ГГц, L3 6 Мбайт, TDP 45 Вт). Между собой контроллеры объединены посредством NTB. Все закешированные данные синхронизируются между ними. Такая схема позволяет в случае сбоя одного из них перенести нагрузку на второй и не потерять при этом информацию.

Технические характеристики Synology UC3200
Контроллер × 2
Накопители	12 × 3,5/2,5" SAS-12 HDD или SSD
	1 × полка RXD1219sas (12 × 3,5/2,5" SAS-12 HDD или SSD)
Файловая система	внутренние жёсткие диски: Btrfs
RAID	SHR F1, Basic, JBOD, RAID 0, 1, 5, 6, 10
Процессор	Intel Xeon D-1521 (4/8, 2,4/2,7 ГГц, 6 Мбайт, TDP 45 Вт)
Оперативная память	8 Гбайт DDR4 ECC UDIMM (расширение до 4 × 16 Гбайт)
Сетевые интерфейсы	2 × 1 GbE RJ-45; 1 × 10 GbE RJ-45
Дополнительные интерфейсы	1 × консоль; 1 × PCI-E 3.0 x8 HHHL; 1 × полка
Протоколы	iSCSI (MPIO/ALUA); IPv6; Telnet, SSH, SNMP
Клиенты	Не младше Windows Server 2008, VMware 5, Citrix XenServer 7.2, RHEL ES 6.1, SUSE Linux ES 11; vSphere 6.5, Hyper-V, Citrix, OpenStack
Система охлаждения	2 × вентилятора 60 × 60 мм
Шасси
Питание	2 (1+1) × БП: AC 100-240 В 50-60 Гц 500 Вт
Энергопотребление, Вт	в режиме доступа: 417,48
	в режиме гибернации: 274,38
Условия работы	5-35 °C; 5-95% отн. вл.; до 5000 метров над уровнем моря
Габариты, мм	88 × 431 × 692
Масса, кг	19,7 (без HDD)
Гарантия, мес.	60
Ориентировочная цена, руб.	480 000

Возможности

Работает Synology UC3200 под управлением специальной версии DiskStation Manager (DSM) UC. Строго говоря, от обычной DSM тут осталось совсем немного. Интерфейс и логика его работы прежние, но приложений почти нет, а новые (во всяком случае пока) установить нельзя. Настройки и базовые функции в целом те же самые, что и у обычных СХД Synology, лишь некоторые дублируются. Например, параметры сети у каждого контроллера, конечно, свои, но есть функция аварийного переключения интерфейсов. Она, правда, требует статические IP-адреса и одинаковую подсеть для обоих узлов, что не очень интересно для SAN. В любом случае веб-интерфейс доступен с каждого из них. А вот агрегация портов доступна только в пределах одного узла.

Контроллеры можно выключать поодиночке. При этом они не являются полностью равноправными. При создании пула хранения для его обслуживания выбирается один из контроллеров, второй же работает параллельно с первым. Схема работы стандартная: диски объединяются в пулы, в пулах создаются тома, на томах размещаются LUN’ы. Максимальный размер тома составляет 108 Тбайт, а число томов не может быть больше 32. Диспетчер хранения предоставляет все те же стандартные функции: RAID-массивы, Hot Spare, кеширование на SSD и так далее. Дело несколько облегчается тем, что из файловых систем UC3200 поддерживает только Btrfs. LUN’ы могут быть, как обычно, толстыми (thick), для лучшей производительности, или тонкими (thin), для более гибкого управления пространством и возможности дефрагментации.

Для последних также доступно создание и удаление снапшотов вручную и по расписанию или по заданному шаблону. Всего в системе может храниться до 4096 моментальных снимков и может существовать до 32 заданий репликаций. Для пущего удобства в DSM UC есть отдельное приложение Snaphot Replication. В нём доступно и создание, и восстановление, и репликация снимков на локальное или удалённое хранилище, и возможность быстро подменить LUN одной из его локальных реплик. Компаньоном для него является приложение Synology Snapshot Manager для Windows и VMware vCenter Server (для Windows Server), которое перед созданием снимка отправляет системе уведомление о необходимости сбросить данные на диск.

В iSCSI Manager отметим лишь несколько настроек. Можно глобально задать глубину очереди запросов: 1, 16 (по умолчанию), 64 или 128. Большая глубина пригодится для быстрых сетей или для пула из SSD. Для LUN’ов можно включить буферизацию ввода/вывода, что положительно скажется на длинных последовательных операциях. А для Target’ов есть возможность привязки к конкретным сетевым интерфейсам.

Наконец, ещё одно приложение, которое и встречает пользователя при входе в веб-интерфейс, называется High Availability Manager. Именно оно позволяет отслеживать работу обоих контроллеров. В нём можно посмотреть текущее состояние обоих контроллеров, полюбоваться на графики нагрузки на различные компоненты и подсистемы, пролистать список запущенных процессов и настроить уведомления о превышении порогового значения того или иного параметра. Причём уведомления эти доступны и для системы в целом, и для отдельных служб, и для томов, и для LUN’ов.

Тестирование

На тест нам досталась версия с 8 Гбайт памяти в каждом узле. Seagate предоставила четыре 16-Тбайт накопителя Exos X16 (ST16000NM002G) корпоративного класса: гелий, 9 пластин, 18 головок, 7200 RPM, 256 Мбайт кеша, MTBF 2,5 млн часов, пятилетняя ограниченная гарантия. И самое главное, двухпортовый интерфейс SAS-12. Заявленная максимальная устоявшаяся скорость передачи данных составляет 261 Мбайт/с, произвольные 4K-чтение/запись с глубиной очереди 16 достигают 170 и 440 IOPS соответственно, типовая задержка — 4,16 мс. Энергопотребление в простое составляет в среднем 5 Вт, а во время работы не превышает 10,2 Вт. В отличие от SATA-версий той же серии, у SAS-моделей есть дополнительная технология защиты целостности данных Protection Information (T10 DIF) и варианты с шифрованием по стандартам FIPS. В общем, Seagate Exos X16 — современный nearline-накопитель, идеально подходящий для наших задач.

Накопители были собраны в массив RAID-10 под управлением первого контроллера (A). На массиве было создано два тома, а на томах — два LUN’а, толстый и тонкий. Каждый LUN был ассоциирован с одним Target’ом. А сами Target’ы были привязаны к 10GbE-интерфейсам с включёнными Jumbo-кадрами 9k. Причём интерфейсы эти были в разных подсетях, то есть получилась маленькая SAN, что дало возможность проверить корректность работы Multipath I/O (MPIO) с точки зрения надёжности. Защита от Spectre/Meltdown — есть теперь в настройках СХД и такой пункт — была отключена.

Конфигурация клиентской Windows-машины осталась неизменной: Intel Core i5-6600K, 32 Гбайт RAM, NVMe SSD GOODRAM IRDM Ultimate, Intel X540-T2. На сетевых интерфейсах также были включены Jumbo-кадры 9k. На ней же был поднят и хост VMware ESXi 6.7u3. В обоих случаях использовались штатные средства работы с iSCSI. В Windows для оценки производительности был подключен толстый LUN, на котором был создан единственный раздел, отформатированный в NTFS. В ESXi также был создан один том VMFS, на котором «жила» виртуальная машина с Ubuntu 18.04. По соседству разместился vCenter, через который и можно настроить MPIO.

Тест проводился в двух режимах. Для начала — с настройками iSCSI по умолчанию, то есть с глубиной очереди 16 и непосредственным обращением к дисковому массиву. В скорость которого, судя по всему, всё и упиралось. Неудивительно, что производитель рекомендует этот режим для SSD-массивов. Ну а потом, в режиме буферизации и с глубиной очереди 128 — в этом случае скорость последовательного чтения приближается к пропускной способности 10GbE-сети. Случайное чтение также получает большой выигрыш, однако при этом сильно страдают операции записи.

Наконец, о главном — о работе СХД в режиме аварийных ситуаций. Схема тестирования очень проста. Для начала даём длительную нагрузку — копирование файлов суммарным объёмом нескольких десятков гигабайт в Windows и stress-ng (--hdd) в ВМ с Ubuntu. Затем отключаем сетевой кабель контроллера A и через некоторое время возвращаем его обратно, а потом вытаскиваем из шасси узел целиком и вставляем его обратно.

В обоих случаях система ведёт себя одинаково. Первым делом, конечно, предупреждает всеми возможными способами о том, что произошёл сбой сети или питания. На клиенте (а он у нас один) все операции зависают примерно на одну минуту, после чего возобновляются, хотя и с меньшей скоростью. Второй контроллер принимает всю нагрузку на себя, и на восстановление исходной производительности уходит до нескольких минут. Возврат в строй первого контроллера или его сетевого подключения приводит к обратному переключению всей нагрузки на него, на что также уходит около минуты. И тоже со скачками производительности.

Более наглядная демонстрация работы Synology UC 3200 в аварийном режиме представлена на видео выше. Примерно в 0:15 происходит отключение сетевого интерфейса на A, что отлично видно на графиках нагрузки на контроллер, диск, сеть и iSCSI. При этом основной контроллер продолжает работать, а второй лишь передаёт данные к нему. В начале второй минуты сеть к A возвращается, но уже на третьей он физически отключается от шасси и возвращается к работе приблизительно в 5:45, забирая всю нагрузку на себя и переходя в нормальный режим в течение ещё пары минут.

Заключение

Synology UC3200 — недорогая «хранилка» IP SAN с базовой функциональностью, что позволяет использовать её в корпоративной среде: в первую очередь для различных сред виртуализации, но она подходит и для любых других типовых multipath-сценариев вроде рендеринга, почтовых систем и баз данных, в том числе тех, что используются ПО для бухучёта и менеджмента. В общем везде, где важна надёжность и доступность данных.

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