Системы хранения VNXe образуют у EMC линейку систем хранения младшего уровня. Недавно линейка пополнилась новой моделью — VNXe1600, которая и станет предметом нашего пристального внимания.
VNXe1600 — модель начального уровня с максимально простой установкой и настройкой. Система позиционируется как единое хранилище для небольших инфраструктур, на котором могут быть размещены типовые современные задачи: базы данных, почтовые системы Exchange, виртуальные сервера VMware и Microsoft или выделенное хранилище под проект. Из протоколов доступа предлагаются только Fibre Channel и iSCSI – никакого файлового функционала. По крайней мере, на текущей момент.
Сразу отмечу, что обзор сделан на основе доступной документации и другой информации – система до нас ещё не доехала, чтобы потрогать её руками в полной мере. И начнём с исторического экскурса — кому интересна только актуальная техническая суть, может его безболезненно пропустить.
Исторический экскурс, чтобы понять родословную: откуда растут корни и возможные рудименты.
Исторически компания EMC выпускает линейку мощных блочных midrange систем хранения (хотя это не главная их гордость: флагманом является линейка high-end продуктов EMC Symmetrix), которые на протяжении нескольких поколений назывались EMC CLARiiON. Их прямые наследники сменили название на EMC VNX Unified Storage, и сейчас актуально их второе поколение.
На протяжении многих лет это одна из основных линеек midrange СХД на рынке, задающая и формирующая тренды для отрасли в целом. В частности, к таковым относится активное развитие протокола Fibre Channel и RAID5.
Правда, слово «исторически», с которого был начата эта часть, применимо с оговорками. Изначально CLARiiON был разработан компанией Data General, тогда же были заложены некоторые архитектурные концепции, сохранившиеся до сих пор. Data General даже пыталась конкурировать своим инновационным продуктом CLARiiON с флагманским продуктом EMC Symmetrix (ныне EMC Symmetrix VMAX или просто VMAX). По воспоминаниям, оставленным в блогах людьми, стоявшими у истоков архитектуры CLARiiON, некоторые архитектурные решения этой конкуренцией с EMC и были обоснованы. Но впоследствии, и уже давно, Data General была куплена компанией EMC. На сегодня визуально корни происхождения систем VNX можно увидеть в том, что тома (LUN-ы) систем CLARiiON/VNX многие системы распознают как DGC RAID или DGC LUNZ, где DGC — аббревиатура Data General Corporation.
Рисунок 1. Приблизительно так выглядел первый CLARiiON
Продолжительное время у EMC также существовала линейка NAS-систем под названием EMC Celerra. Архитектурно эти системы были NAS-шлюзом, подключаемым к блочным системам хранения (в какие-то моменты, если не ошибаюсь, заявлялась поддержка сторонних массивов, но в основном эти блочные системы должны были быть производства EMC). NAS-шлюз не имел собственной ёмкости – использовал ёмкость этих систем и добавлял функционал доступа по файловым протоколам: CIFS, NFS, iSCSI и др. Строгости для: iSCSI – это, конечно, блочный протокол и вообще-то это SAN, но поддержка iSCSI характерна для NAS-систем, как систем хранения с доступом по Ethernet.
Рисунок 2. Вот так выглядела high-end СХД, предоставлявшая функционал NAS, в районе 2000 года. Настоящий суровый промышленный вид – никакой синей подсветки. Зато шины питания были окрашены в разные цвета.
Существовали также и интегрированные модели, в которые входили компоненты и Celerra, и CLARiiON, но управление блочным и файловым функционалом было разделено. Т.е. во многом это были две системы в одной коробке стойке. Активное объединение началось с появлением интерфейса управления Unisphere на системах поколения CLARiiON CX4, который свёл воедино управление файловым и блочным функционалом, и утвердилось с появлением линейки EMC VNX Unified Storage. В системах VNX блочные и файловые контроллеры по-прежнему реализованы аппаратно отдельно, но полностью интегрированы по управлению и аутентификации.
Для меня эти системы (CLARiiON, Celerra и VNX) являются прямыми наследниками, и, оговорившись, легко могу назвать VNX кларионом, а говоря о файловом функционале, и вовсе обозвать целерой.
Всего через месяц-другой после выхода VNX появилась система поколения VNXe – VNXe3100, в которой наоборот присутствовал только сетевой функционал и никакого Fibre Channel наружу. То есть в небольшой коробочке на базе имеющегося опыта и программных наработок был собран функционал и блочных, и NAS-систем, реализованный на одном и том же контроллере, а наружу выставлен только NAS функционал. Причём функционал был несколько ограничен, а управление значительно упрощено. Система представляла собой попытку войти в дешёвый сегмент, для заказчиков, у которых нет и не планируется никакого Fibre Channel, и нет особого желания учить что-то о RAID-группах (в интерфейсе системы нет понятия Raid Group).
Дальнейшим развитием и пока апогеем серии VNXe стала система VNXe3200, предоставившая уже и файловый, и блочный функционал, включая все основные «продвинутые» функции старших собратьев. То есть почти как VNX Unified, но в рамках единой аппаратной коробки. Модель, надо сказать, и вправду получилась очень достойная. К спорным решениям в модели, на мой взгляд, можно отнести лишь две вещи: встроенные порты 10 GE Base-T – не очень удобны для тех, у кого 10 GE по оптике (нужно ставить интерфейсные модули), и ограничение возможностей конфигурирования дисковой подсистемы определёнными шаблонами, которые были не очень явно описаны в спецификациях и маркетинговых материалах.
Рисунок 3. Предлагаемое портфолио VNX и VNXe на текущий момент
Недавно на рынок был выведен младший собрат системы VNXe3200 – система VNXe1600, которую мы и рассмотрим, предоставляющая на текущий момент только блочный функционал.
На протяжении многих лет это одна из основных линеек midrange СХД на рынке, задающая и формирующая тренды для отрасли в целом. В частности, к таковым относится активное развитие протокола Fibre Channel и RAID5.
Правда, слово «исторически», с которого был начата эта часть, применимо с оговорками. Изначально CLARiiON был разработан компанией Data General, тогда же были заложены некоторые архитектурные концепции, сохранившиеся до сих пор. Data General даже пыталась конкурировать своим инновационным продуктом CLARiiON с флагманским продуктом EMC Symmetrix (ныне EMC Symmetrix VMAX или просто VMAX). По воспоминаниям, оставленным в блогах людьми, стоявшими у истоков архитектуры CLARiiON, некоторые архитектурные решения этой конкуренцией с EMC и были обоснованы. Но впоследствии, и уже давно, Data General была куплена компанией EMC. На сегодня визуально корни происхождения систем VNX можно увидеть в том, что тома (LUN-ы) систем CLARiiON/VNX многие системы распознают как DGC RAID или DGC LUNZ, где DGC — аббревиатура Data General Corporation.
Рисунок 1. Приблизительно так выглядел первый CLARiiON
Продолжительное время у EMC также существовала линейка NAS-систем под названием EMC Celerra. Архитектурно эти системы были NAS-шлюзом, подключаемым к блочным системам хранения (в какие-то моменты, если не ошибаюсь, заявлялась поддержка сторонних массивов, но в основном эти блочные системы должны были быть производства EMC). NAS-шлюз не имел собственной ёмкости – использовал ёмкость этих систем и добавлял функционал доступа по файловым протоколам: CIFS, NFS, iSCSI и др. Строгости для: iSCSI – это, конечно, блочный протокол и вообще-то это SAN, но поддержка iSCSI характерна для NAS-систем, как систем хранения с доступом по Ethernet.
Рисунок 2. Вот так выглядела high-end СХД, предоставлявшая функционал NAS, в районе 2000 года. Настоящий суровый промышленный вид – никакой синей подсветки. Зато шины питания были окрашены в разные цвета.
Существовали также и интегрированные модели, в которые входили компоненты и Celerra, и CLARiiON, но управление блочным и файловым функционалом было разделено. Т.е. во многом это были две системы в одной коробке стойке. Активное объединение началось с появлением интерфейса управления Unisphere на системах поколения CLARiiON CX4, который свёл воедино управление файловым и блочным функционалом, и утвердилось с появлением линейки EMC VNX Unified Storage. В системах VNX блочные и файловые контроллеры по-прежнему реализованы аппаратно отдельно, но полностью интегрированы по управлению и аутентификации.
Для меня эти системы (CLARiiON, Celerra и VNX) являются прямыми наследниками, и, оговорившись, легко могу назвать VNX кларионом, а говоря о файловом функционале, и вовсе обозвать целерой.
Всего через месяц-другой после выхода VNX появилась система поколения VNXe – VNXe3100, в которой наоборот присутствовал только сетевой функционал и никакого Fibre Channel наружу. То есть в небольшой коробочке на базе имеющегося опыта и программных наработок был собран функционал и блочных, и NAS-систем, реализованный на одном и том же контроллере, а наружу выставлен только NAS функционал. Причём функционал был несколько ограничен, а управление значительно упрощено. Система представляла собой попытку войти в дешёвый сегмент, для заказчиков, у которых нет и не планируется никакого Fibre Channel, и нет особого желания учить что-то о RAID-группах (в интерфейсе системы нет понятия Raid Group).
Дальнейшим развитием и пока апогеем серии VNXe стала система VNXe3200, предоставившая уже и файловый, и блочный функционал, включая все основные «продвинутые» функции старших собратьев. То есть почти как VNX Unified, но в рамках единой аппаратной коробки. Модель, надо сказать, и вправду получилась очень достойная. К спорным решениям в модели, на мой взгляд, можно отнести лишь две вещи: встроенные порты 10 GE Base-T – не очень удобны для тех, у кого 10 GE по оптике (нужно ставить интерфейсные модули), и ограничение возможностей конфигурирования дисковой подсистемы определёнными шаблонами, которые были не очень явно описаны в спецификациях и маркетинговых материалах.
Рисунок 3. Предлагаемое портфолио VNX и VNXe на текущий момент
Недавно на рынок был выведен младший собрат системы VNXe3200 – система VNXe1600, которую мы и рассмотрим, предоставляющая на текущий момент только блочный функционал.
Семейство систем VNXe
Чтобы прояснить отличия именно в рамках семейства VNXe, коротко перечислим основные модули и вехи:
VNXe3100 – GA март 2011. Чисто сетевая система хранения. Поддерживает только Ethernet: NAS- протоколы и iSCSI.
VNXe3300 – GA март 2011. Чисто сетевая система хранения. То есть поддерживает только Ethernet: NAS протоколы и iSCSI. Существенно более мощный вариант, чем VNXe3100.
VNXe3150 – GA август 2012. «Улучшенная» версия VNXe3100 с большим количеством памяти и дальнейшей проработкой функционала. Также только Ethernet: NAS протоколы и iSCSI.
VNXe3200 – GA май 2014. Логичный вариант развития серии и пока её апофеоз. В дополнение к NAS и iSCSI по Ethernet получила возможность Fibre Channel, продвинутый функционал старших собратьев.
VNXe1600 – новая модель GA август 2015, в настоящий момент только блочный функционал: Fibre Channel или iSCSI по Ethernet.
VNXe1600
Архитектура системы является традиционной: контроллерная полка с дисками (DPE) в формате 2U, к которой по SAS подключаются дополнительные дисковые полки (DAE) тоже 2U. И контроллерная полка, и дополнительные могут иметь вариант как на 12 дисков 3.5 дюйма (то, что некоторые называют LFF), так и на 25 дисков 2.5 дюйма (то, что некоторые называют SFF).
Характеристики системы в сравнении со старшим собратом:
Таблица 1 Технические характеристики VNXe1600 в сравнении с VNXe3200
В этой таблице не отражено, что принципиальным отличием является наличие у VNXe1600 только блочного функционала. Это, возможно, чуть компенсирует разницу в оперативной памяти, которой у VNXe1600 в три раза меньше: не нужно держать файловый код и служебные данные в памяти. Но тем не менее памяти существенно меньше: по 8 ГБ на контроллер, и меньшее количество ядер.
Из характеристик можно отметить, что система позволяет установить даже большее число дисков, чем старший собрат VNXe3200: 200 против 150 у VNXe3200. Вместе с тем с учётом меньшего количества памяти и ядер – на единицу ёмкости приходится меньше вычислительной мощности. Вообще, с выходом линейки VNX EMC серьёзно ограничили максимально поддерживаемое количество дисков – ограничение не техническое, а разумно маркетинговое (здесь маркетинг – как правильное позиционирование, т.е. в хорошем смысле). Данный аспект сделал сравнение моделей с решениями других вендоров по этому признаку лишенным смысла. Обратной стороной явилось то, что для младших моделей серии достигался почти линейный рост производительности по мере добавления дисков: при максимальном числе дисков точка насыщения не превышалась. 200 дисков – это всего 7 дополнительных к контроллерной полок, если все они по 25 дисков 2.5” – т.е. суммарно 16U.
Есть и дополнительное ограничение – в спецификации по сноске указано, что максимальный «сырой» объём — 400 ТБ. Т.е. забить систему под завязку 4 ТБ дисками не получится. Стоит учесть, что ограничение в реальности не по числу дисков, а по числу дисковых слотов. Т.е. если в системе уже стоит 16 полок по 12 дисков (16х12 = 192), добавить ещё одну полку, даже если в ней будет менее 8 дисков, не выйдет – будет превышено число дисковых слотов (192 +12 = 204; 192+25 =217).
По интерфейсам: в новой системе в одной из первых у EMC появилась поддержка 16 Gb/s Fibre Channel, и отсутствует поддержка 10 GE BASE-T, в то время как у VNXe3200 такие порты были встроенными.
Посмотрим на железо подробнее.
Вот так выглядит контроллерная полка (DPE – Disk Processor Enclosure) сзади. Спереди ничего особо интересного, кроме фальш-панели с синей подсветкой, за которой скрывается 12 дисков 3.5” или 25 по 2.5”:
Рисунок 4. Вид на контроллерную полку (DPE) сзади
Видим, что систему можно разделить на две части, компоненты, располагаемые в которых будут называться A и B – справа и слева, если смотреть сзади, соответственно. На системе это промаркировано стрелочками.
В верхней части полки находятся блок питания и охлаждения, состоящий из трёх вентиляторных модулей (1) и собственно блока питания (2), а нижняя часть –контроллер с портами. Каждый из блоков питания способен питать всю полку. Для того, чтобы система не пыталась спасти кэш и выключиться, должен работать как минимум один из блоков питания и не менее чем по два вентиляторных модуля на контроллере.
Как и для других систем VNXe-серии, защита кэш-памяти осуществляется с помощью батареек (BBU), установленных в сам контроллер. Задача такой батарейки не поддерживать работу и не поддерживать энергопитание памяти при отключении, а дать системе сбросить содержимое кэш-памяти на встроенный твердотельный накопитель (с него же система загружается).
Рисунок 5. Компоненты DPE (показана половина системы)
Каждый контроллер имеет два встроенных SFP+ порта, обозначенных как CNA (3) – т.е. порты универсальны и могут быть сконфигурированы как Fibre Channel 8 или 16 Gb/s или 10 GE. И в них установлены соответствующие SFP-трансиверы. Эта конфигурация делается при заказе – т.е. на месте поменять нельзя (заказчику, по крайней мере, и в настоящий момент).
Присутствует возможность установки дополнительного интерфейсного модуля (10), в базовой конфигурации вместо него стоит заглушка. Точнее и корректнее будет сказать не «дополнительного», а «дополнительных» – так как при расширении устанавливается пара идентичных модулей в оба контроллера.
На старте доступен выбор из трёх модулей, все являются 4-х портовыми: Fibre Channel 8 Gb/s или Ethernet 10 GE Optical или GE Base-T. Модуль может быть выбран как изначально, так и добавлен позднее в качестве апгрейда. Для установки модулей требуется извлечение контроллера, но благо их два – можно организовать это как non-disruptive upgrade, с точки зрения доступности данных.
Два квадратных порта (4) – это SAS порты 6 Gb/s — т.е. система имеет две шины для подключения дисковых полок (BE). Сама системная полка является полкой #0 на шине #0. Разъёмы имеют форм-фактор SAS HD.
Набор светоиндикаторов (подробно рассматривать нет смысла) включает значок перечёркнутой руки (Unsafe to Remove), загорающийся, когда нельзя извлекать контроллер, чтобы не потерять данные кэш – т.е., например, если предварительно извлечь второй контроллер, или при процессах старта и сохранения кэша. Можно отметить, что в VNXe1600 отказались от того, чтобы предлагать «одноголовые» конфигурации, что было возможно для предыдущих систем из самой младшей линейки.
Присутствует Ethernet порт для управления и сервисный порт. Как и в VNXe3200, нет аппаратного serial-порта, и при необходимости сервисного вмешательства используется виртуальная консоль поверх Ethernet.
Дисковая подсистема
Дисковые полки, как и системная, могут быть двух типов:
- На 25 дисков форм-фактора 2.5”
- На 12 дисков форм-фактора 12”
Рисунок 6. Полка на 25 дисков 2.5"
Рисунок 7. Полка на 12 дисков 3.5"
Дисковые полки подключаются к контроллерной по SAS с равномерным распределением по двум BE-шинам. Сама системная полка с точки зрения адресации является полкой # 0 на шине # 0.
Таблица 2. Максимальные конфигурации дисковых полок и количество дисков для них
Доступны диски SAS, NL_SAS или Flash. По сути-то все эти накопители имеют интерфейс SAS для подключения к дисковым полкам, но каждый вендор чуть-чуть стремится научить людей разговаривать в своих терминах. Чтобы было проще понимать:
SAS – это 10K или 15K оборотистые диски.
NL_SAS – высокоёмкие диски со скоростью вращения 7200 об/мин. Доступны только в форм-факторе 3.5”
Flash – твердотельные накопители. Бывают двух типов: с возможностью использования их как FAST Cache (это SLC накопители, имеющие больший ресурс и надёжность) и не поддерживающие это, но несколько менее дорогие (FAST VP Flash). Накопители, поддерживающие FAST Cache, при желании могут быть использованы и для формирования пула.
Таблица 3 Поддерживаемые типы накопителей
Из таблицы можно увидеть, что высокоёмкие диски доступны только в форм-факторе 3.5 дюйма, а остальные — в любых. Оно и понятно: сейчас зачастую 3.5 дюймовый диск это 2.5 дюймовый в соответствующих салазках.
Конфигурация дисковой подсистемы сводится к конфигурированию пулов. Пул – это набор дисков одного типа (т.к. система не поддерживает FAST VP), на котором впоследствии создаются виртуальные тома — LUN. Т.е. при создании пула система нарежет внутри себя одну или несколько RAID-групп с заданным типом защиты, а пользователю представит это как единое пространство для размещения томов (LUN). В рамках пула также может быть зарезервирована ёмкость для создания снэпшотов.
Политика для дисков горячей замены не является настраиваемой, а следует обычным рекомендациям EMC: 1 hot-spare на 30 дисков соответствующего типа.
Целевые размеры RAID групп – т.е. число дисков, которое рекомендуется объединять в пул при его создании:
- RAID 5: 4+1, 8+1, 12+1
- RAID 6: 6+2, 8+2, 10+2, 14+2
- RAID 1/0: 1+1, 2+2, 3+3, 4+4
При создании пула можно указать желаемый размер. Из описания пока не до конца понятно, будет ли это жёстким ограничением, как на собратьях VNXe, или, если число дисков будет некратно, то система создаст немного неровные RAID-группы, как на старших VNX. Пока похоже, что можно задавать только кратные размеры. На системах VNXe такое ограничение шаблонами, по-видимому, было вызвано оптимизацией под работу файлового функционала. Тонкости здесь расписывать не буду – тем более, как именно на VNXe работает на 100% не знаю, но суть в том, что эти ограничения – не блажь, а техническая оптимизация.
Можно отметить унаследованную особенность, о которой важно знать: первые четыре диска являются системными — на них часть ёмкости используется для служебных нужд, и при некоторых операциях эти диски также ведут себя немного по-другому чем остальные. Полезная ёмкость системных дисков будет меньше. Если они будут объединены в одну RAID-группу (именно группу, а не пул, хотя идеология VNXe и предлагает не думать о группах) с другими дисками – на тех «потеряется» такая же ёмкость. На этих дисках «отъедается» приблизительно по 82.7 ГБ c диска. Для примера, если первые 4 диска будут 900 GB номинального объёма (около 818.1 полезного) и сконфигурированы как RAID 1/0– то полезный объём будет 1470.8 (736.4 ГБ на системный диск), а на такой же группе не на системных мы получим около 1636.2 (818.1 ГБ на диск). Если, например, у нас в системе всего 14 дисков по 900 GB, и мы выберем для пула RAID5 12+1 + hot-spare, то получим 8824.80 полезного объёма, потеряв по 82.7 ГБ и на девяти несистемных дисках. Зачем нужен такой резерв, если система грузится с твердотельного накопителя и на него же сохраняет кэш — понятно не до конца. Возможно, это дополнительное резервирование, и разработчики решили пока не ломать до конца существовавшую модель.
Hint: при продумывании конфигурации системы попросить поставщика посчитать требуемую разбивку. У партнёров имеется capacity calculator, где можно задать требуемые наборы дисков и групп, выдающий на выходе pdf, где детально подсчитано, что и как, и сколько места будет доступно.
Рисунок 8. Capacity Calculator и нарисует, и посчитает полезную ёмкость и высоту в стойке
Доступен FAST Cache – функционал, реализующий расширение кэш-памяти за счёт твердотельных накопителей, но конфигурация ограничена максимум двумя твердотельными накопителями. Для этого функционала создаётся отдельная группа RAID 1/0 (1 в случае двух накопителей). Т.е. с учётом зеркалирования ёмкость может быть 100 или 200 GB номинального объёма. «Номинального», т.к. накопитель, маркированный как 100 GB, даёт около 91.69 двоичных GB, а 200 GB – около 183.41 GB. Честные соотношения ёмкостей есть в specification sheet на модель.
Функционал
Отразим некоторые из ключевых возможностей системы. Вообще, для многих систем хранения EMC значительная часть функционала появляется спустя определённое время после запуска самой системы хранения. Не знаю, будет ли это справедливо и для VNXe1600 – roadmap-ы не смотрел, а если бы и смотрел – сказать бы не мог.
Рисунок 9. Функционал системы VNXe1600
Перечисленный ниже функционал включён в базовую поставку системы. Из дополнительного функционала на текущий момент можно выбрать EMC PowerPath – устанавливаемое на сервера ПО для обеспечения multipathing (аварийного переключения путей и балансировки нагрузки).
Протоколы для доступа к данным: iSCSI и Fibre Channel.
Unisphere – управление системой возможно как средствами встроенного web-интерфейса, так и через командную строку Unisphere CLI (для желающих что-то заскриптовать, например). Интерфейс управления схож с другими VNXe, да и вообще довольно прост. В интерфейсе, помимо управления, реализованы и возможности мониторинга использования и характеристик производительности. Для управления большими инфраструктурами поддерживается централизованное управление разнородными системами (VNX, VNXe, CLARiiON CX4) с помощью Unisphere Central – отдельного сервера управления, разворачиваемого как appliance в виртуализованной среде.
Рисунок 10. Web-интерфейс управления Unisphere
Управление системой использует RBAC модель с набором предопределённых ролей. Возможна интеграция с LDAP для аутентификации пользователей при доступе к интерфейсу управления.
FAST Cache – функционал по использованию твердотельных накопителей как расширения кэш-памяти. Поддержка ограничена использованием только двух твердотельных накопителей SLC – т.е. максимум до 200 номинальных ГБ.
Thin Provisioning – возможность создавать «тонкие» тома, для которых фактическое выделение ёмкости происходит по мере её использования, и организовывать переподписку. Вещь уже более чем стандартная для современных СХД.
Snapshots – возможность создания копий томов в виде моментальных снимков. Работают по технологии ROW (Redirect on Write) – т.е. само наличие снэпшотов не тормозит основной LUN. Присутствует встроенный функционал по обеспечению консистентного создания снэпшотов для группы томов.
Asynchronous Replication — поддерживается асинхронная репликация на уровне LUN-ов или VMFS Datastores (это те же LUN-ы, но выделены особо) между системами хранения VNXe1600 и VNXe3200. Механизм асинхронной репликации фактически задействует механизм снэпшотов и передачу разницы между ними. Соответственно, есть возможность использования и групп консистентности. Есть возможность задать автоматическую синхронизацию с определённым интервалом, или же проводить её по команде пользователя.
Поддержка виртуальных сред – в лучших традициях система VNXe наиболее полно поддерживает интеграцию с VMware, включая: VMware Aware Integration (VAI) – возможность видеть из интерфейса VNXe данные VMware – о том, какой datastore лежит на LUN, какие виртуальные машины на нём лежат и т.д.; Virtual Storage Integrator (VSI) – есть дополнительный плагин для клиента VMware vSphere, позволяющий наоборот — удобнее видеть из интерфейса VMware данные об объектах СХД и управлять ими; VMware API for Array Integration (VAAI) – взаимодействие с СХД для переноса выполнения части задач, таких как копирование виртуальных машин, обнуление блоков, блокировки, взаимопонимания в области thin provisioning с сервера на внутренние процессы СХД.
Быстрый старт
После того как система смонтирована, она должна быть инициализирована с помощью специальной утилиты – Connection Utility, поставляемой с системой или доступной на сайте поддержки вендора. Утилита бродкастом (потому надо подключиться в тот же сетевой сегмент) находит и устанавливает связь с СХД и позволяет задать управляющий IP.
После этого настройка системы может быть продолжена через Web-интерфейс по назначенному ip-адресу. При первом запуске будет запущен wizard, который пошагово спросит про большинство инфраструктурных настроек и поможет быстро сконфигурировать основные вещи.
Мудрёных настроек нет: достаточно сконфигурировать пулы и создать на них ресурсы хранения. Причём при использовании wizard-ов, система, например, может сразу после создания автоматически подцепить новый создаваемый LUN как VMware datastore – не потребуется отдельно сканировать адаптеры и сопоставлять номера LUN из интерфейса управления vSphere.
Глобальная поддержка
Для своевременного оказания поддержки система хранения должна быть зарегистрирована и корректно отображаться на портале поддержки производителя support.emc.com. Если это первый продукт EMC – потребуется дополнительно регистрация на портале. Если всё сделано верно, и система имеет маршрут до Internet – то большая часть информации может быть доступна прямо из интерфейса системы хранения, включая HowTo видео и доступ к форумам.
Практически для всех своих продуктов EMC считает, что штатно должны быть настроены Call-home и Dial-In, чтобы обеспечить своевременную реакцию на проблемы. Call-home – отправка сообщений от системы в глобальный центр поддержки EMC. Dial-In – возможность удалённого подключения специалистов глобальной поддержки для диагностики и решения проблем. В минимальном варианте Call-Home — это отправка e-mail сообщений, а Dial-In реализуется через систему web-конференций Webex. Рекомендованный вариант — это использование EMC Secure Remote Support Gateway (ESRS) – специального продукта EMC, реализующего защищённый туннель по https между инфраструктурой заказчика и инфраструктурой глобальной поддержки. В общем случае сейчас такой сервер реализуется в виде виртуального appliance, но на системах VNXe есть встроенный компонент – ничего доставлять не нужно, достаточно разрешить на firewall установку https соединений вовне на адреса серверов поддержки EMC.
Выводы и возможные сферы применения
Новая система хранения заполняет определённую нишу в линейке продуктов EMC – чисто блочная СХД начального уровня от EMC. Ранее эту нишу у EMC занимали системы CLARiiON AX4-5 и VNX5100. Запрос на такие СХД регулярно есть – востребована будет. Система была официально объявлена 10 августа, но мы её пока руками не трогали и feedback-а от заказчиков ещё не имеем.
Приличный запас по масштабированию и ассортимент дисков позволяет решать достаточно широкий круг задач, где нет требований к продвинутому функционалу на уроне СХД. Из возможных сфер применения на первый взгляд видны:
• Блочная система начального уровня – хороший вариант для замены существующих блочных СХД предыдущих поколений, на которые закончилась поддержка, и где не требуется продвинутый функционал;
• Неплохой вариант для новой системы начального уровня для консолидации данных, где нет необходимости в файловых протоколах, или их считается более удобным реализовывать самостоятельно на файловых серверах.
• Возможно и просто back-end хранилище для файлового сервера.
• Относительно недорогое решение для построения кластеров, в том числе и в первую очередь, для виртуальных инфраструктур.
• Хранилище для систем видеонаблюдения (на практике часто его всё-таки строят с подключением по блочному SAN, а не NAS) из-за возможности набрать высокоёмких дисков, а возможно и быстрых (если архитектура системы подразумевает и базу или каталог).
• Возможно, будут интересные конфигурации All-Flash хранилищ, которые актуальнее для NAS, чем для SAN.
• Возможный вариант хранилища Backup to Disk для подключения к серверу резервного копирования. Хотя мы в первую очередь за EMC Data Domain и client-direct, но это другая история.
Ссылки на ресурсы вендора:
White Paper: Introduction to the EMC VNXe1600. A detailed Review
Specification Sheet: EMC VNXe1600 Block Storage System