В массивы Primera и серверы встраиваются те же самые технологии, что есть у массивов HPE Nimble Storage и 3PAR Storage, они начинают не просто передавать статистические логи, которые облегчают решение сервисных проблем вендору, но и начинают передавать большее количество данных с виртуальных сенсоров, которые включены в каждый модуль программного кода, который работает на этих платформах.

О выходе этого нового продукта HPE Primera было объявлено примерно два месяца назад на конференции в Лас-Вегасе. По словам Владислава Логвиненко, менеджера по системам хранения Hewlett Packard Enterprise главная идея этой системы хранения заключается в том, чтобы упростить работу сотрудников ИТ-подразделения для сопровождения ИТ-инфраструктуры. ИТ-инфраструктура с каждым годом становится все более сложной, состоящей из массы компонентов и бизнес-приложений, соответственно администраторам, которые занимаются их сопровождением, становится достаточно тяжело этим заниматься. Они постоянно решают проблемы, возникающие при эксплуатации оборудования, и на это уходит много сил и времени. В последнее время ИТ рассматриваются как поставщик ресурсов для приложений с искусственным интеллектом, так почему бы этот ИИ не использовать внутри серверной для упрощения сопровождения оборудования. По словам Владислава Логвиненко получается, что ИТ выступает у нас в качестве сапожника без сапог и этот массив СХД предлагает вернуть сапоги сапожнику, чтобы он использовал ИИ для своих целей.

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

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

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

Часть этих проблем можно переложить на ИИ, и InfoSight этим и загружают. Как работает InfoSight?

Рис. 1.

В массивы Primera и серверы встраиваются те же самые технологии, что есть у массивов HPE Nimble Storage и 3PAR Storage, они начинают не просто передавать статистические логи, которые облегчают решение сервисных проблем вендору, но и начинают передавать большее количество данных с виртуальных сенсоров, которые включены в каждый модуль программного кода, который работает на этих платформах. Благодаря этому в облако InfoSight передается не только логи, но и гораздо больше информации, из которой с помощью статистических механизмов, с помощью ИИ и машинного обучения можно сделать некие выводы не только о самой СХД, но и том, что происходит вокруг нее. InfoSight предназначен для того, чтобы проблема, которая проявилась на каком-то оборудовании, не проявилась заново.

Как это происходит. Если раньше у нас в СХД появилась проблема, обычно мы открывали сервисный кейс и начинали взаимодействовать с 1-м и 2-м уровнем поддержки. Это не очень удобно, поскольку требует общение с инженерами этих уровней поддержки на иностранном языке согласно их рабочему графику. Это итерационный процесс: какие-то логи отправлены, которые они проанализировали, запросили что-то еще, на такое общение тратится много времени. В случае с InfoSight такие данные передавать не нужно, поскольку они есть в облаке. InfoSight самостоятельно создает сигнатуру проблемы – хэш код, который в дальнейшем можно использовать при работе с таким стечением обстоятельств, т.е. версия ОС с бизнес-приложениями, которая работает на этой СХД, серверах и т.д. Все это «сваливается» инженеру поддержки 3-го уровня, а это уже квалифицированный инженер близкий к разработчикам, который реально понимает как работает массив.

Если инженер понимает, как решить эту проблему, тогда скорее всего будет создан патч, который и закроет эту проблему. Этот патч будет отправлен туда, где эта проблема произошла, применен и проблема будет решена. Но на этом все не заканчивается: у нас есть сигнатура проблемы и хэш код, мы по всей инсталлированной базе СХД можем сравнить данные и понять, существует ли вероятность аналогичного сбоя на всех СХД и серверах, которые подключены к InfoSight. Если это так, то тот же патч будет рекомендовано применить всем, у кого есть такое же сочетание аппаратных и программных ресурсов. Таким образом аналогичная проблема на другом массиве уже не повторится.

Рис. 2.

На рис. 2 представлен пример. Реальное сочетание аппаратного и программного обеспечения привело к тому, что при работе с данными один массив не освобождал память, недостаток памяти накапливался, когда память закончилась пришлось контроллер перезапустить. Решение было найдено и отправлен патч, но в базе было обнаружено еще 47 массивов и им было предложено также поставить этот же патч.

В результате разработчики, которые работали над созданием СХД Primera, решили объединить лучшее, что есть из технологий, чтобы СХД решала проблемы сама, чтобы не было сложностей с настройкой, с выделением ресурсов, чтобы массив работал автономно.

Рис. 3.

Из массива 3PAR Storage пришло в СХД Primera возможность консолидации приложений без риска для данных. Потом на все это была наложена новая платформа и добавлен искусственный интеллект не только в облаке, но и внутри массива. В результате была получена система хранения данных Primera.

Рис. 4.

Этот массив способен автоматически подстраиваться под бизнес-процессы распределяя данные оптимальным образом для той рабочей нагрузки, которая на массиве работает, выставляя необходимые уровни сервиса. Причем, этот массив дает не 5-6 «девяток» надежности, а 100%-ную доступность данных, т.е. массив не должен непредсказуемо останавливаться.

Рис. 5.

На рис. 5 приведена архитектура СХД Primera, важное ее свойство в том, что она всегда “all-active”, т.е. в массиве нет компонентов, которые простаивают в ожидании, когда их коллега, который дублируют их операции, сломается. Для обеспечения максимальной производительности все компоненты массива постоянно активны, каждый логический том доступен со всех контроллеров массива, все порты тоже активны, это то же самое, что было реализовано в СХД 3PAR Storage, здесь есть и виртуализация емкости, здесь нет «железных» рейдов, есть рейды виртуальные, вся емкость массива разбивается на маленькие «кусочки», из которых по мере необходимости строятся логические тома с определенным уровнем защиты. Также как в 3PAR Storage здесь используются специализированные микросхемы для того чтобы разгрузить центральны процессор контроллера от рутинных задач, например таких как расчет RAID, расчет дедупликации, эти задачи ресурсоемкие, они не очень эффективно выполняются на процессоре Intel. Соответственно есть возможность реализовать эти функции в «железе», в старших моделях может быть до четырех ASIC Gen 6 на контроллер, три из которых отвечают за связь контроллеров между собой. Это позволяет создать очень быстрое соединение между контроллерами и в результате получается единая система, которая обеспечивает максимальную производительность. Контроллеры в данном массиве могут использовать технологию Intel QAT, что позволяет еще дополнительно перераспределить нагрузку, например, обеспечивая шифрование или компрессию не на центральном процессоре, а на этих специализированных микросхемах. Это массив, в которых используется до 4-х контроллеров (обычно их используется два) и эти 4 контроллера прекрасно ложатся на переход на NVMe. Здесь можно распараллеливать итерации и каждое ядро может работать непосредственно с данными и здесь нет между ядром и накопителем каких-то адаптеров, получается, что чем больше ядер, тем больше возможностей для распараллеливания операций и в четыре контроллера можно поставить ядер много больше, чем в двухконтроллерный массив.

Кроме того, ИИ у нас существует не только в облаке в виде InfoSight, но его можно использовать внутри серверной и внутри контроллеров.

Рис. 6.

Массив обладает важными архитектурными преимуществами под NVMe и SCM. Кэш-память, не смотря на то, что она привязана к конкретному контроллеру, выступает в качестве единого ресурса и здесь было принято решение совместить подходы конструирования аппаратного обеспечения, которые были в NVMe и 3PAR. Последний – это массив с не самым мощным железом, но благодаря архитектуре, он работает быстрее и надежнее своих конкурентов. В NVMe подход другой, не меняя операционную систему при выходе новых процессоров Intel можно просто аппаратную платформу поменять и сразу достигается большая производительность. В СХД Primera есть и продвинутая архитектура и было принято решение не экономить на аппаратных компонентах.

Также в этом массиве реализована технология Memory-Driven Flash. Она представлена на рынке в виде Intel Optanе. Это энергонезависимая память нового поколения, она на порядок быстрее традиционной флеш-памяти. Полностью построить массив на таких элементах не представляется возможным по двум причинам: первое – хотя она в 10 раз быстрее, но в тоже время и в 10 раз дороже традиционной флеш-памяти и главное, что нет коммерчески доступных накопителей Intel Optanе или другого вендора, другой реализации, которое бы было двухпортовой, поэтому невозможно сделать резервный путь к данным и надежность системы, если мы сделаем его только на базе Intel Optanе, будет недостаточной. Соответственно Memory-Driven Flash позволяет реализовать кеширование на Storage Class Memory, не ставя большой объем Intel Optanе в каждый контроллер и ускорить All Flash массивы, чтобы получить бОльшую производительность.

Рис. 7.

При консолидации данных Memory Flash очень сильно помогает. Зачастую по мере консолидации бинес-приложений у нас начинает расти время доступа latency гораздо быстрее, чем растут IOPs, это связано с неправильной архитектурой массивов, которая может быть у конкурентов, они не были рассчитаны на использование флеш-памяти, либо она была реализована не очень эффективно. Кроме того, флеш-память обладает неприятным свойством, что касается latency, то, если у нас происходит запись в пустую ячейку, то это происходит за единицу времени, а если происходит запись в занятую ячейку, ранее используемую, а сейчас помеченную как неиспользуемую, то надо сначала информацию в этой ячейке стереть, проверить ее на работоспособность и только потом записывать в нее информацию. Здесь времени может понадобиться в три раза больше чтобы пройти ту же самую транзакцию. Массив начинает себя вести не очень предсказуемо, если посмотреть на кривую распределения latency в зависимости от нагрузки, мы увидим, что она выглядит не как нормальное распределение, а у нее длинный правый хвост, значит не все транзакции попадают в ту скорость отклика, которую мы предполагаем исходя из наших справочных данных о массиве. При использовании Memory-Driven Flash ситуация меняется, массив начинает себя вести более предсказуемо и latency растет у нас параллельно с ростом числа операций ввода-вывода, соответственно консолидировать бизнес-приложения на таком массиве становится гораздо легче.

Рис. 8.

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

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

Рис. 9.

Модельный ряд HPE Primera выглядит как показано на рис. 9. Это двухконтроллерный младший массив HPE Primera 630, это старший массив HPE Primera 670 и между ними находится HPE Primera 650. Два последних массива могут быть как двухконтроллерными, так и четырехконтроллерными. Массив изначально создавался для конфигурации All Flash, но для отчетов о продажах, по словам Владислава Логвиненко, очень хорошо, когда мы показываем аналитикам типа компании IDC, что у нас есть платформа All Flash. У нас есть модели с индексом «А» и с индексом «С». «А» - это All Flash, а «С» - это гибридная модель массива. С аппаратной точки зрения и с точки зрения ОС они ничем не отличаются, но некоторые конфигурации позволяют использовать и жесткие диски тоже.

Во всех справочных данных у нас на SSD указывается емкость не сырая и не полезная, а указывается емкость с учетом дедупликации, которая называется эффективной емкостью.

Сейчас на главной