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

Производительность одна из ключевых характеристик качественного программного обеспечения: прочие характеристики систем хранения данных не будут оценены по достоинству, если она работает медленно или нестабильно. Сегодня мы беседуем с Сергеем Качкиным kachini руководителем отдела технической экспертизы департамента прикладных исследований и технической экспертизы компании YADRO.

У его профессии несколько названий: аналитик производительности, performance engineer, performance tester. И все они достаточно мало распространены в России. Между тем инжиниринг производительности помогает создавать эффективные компьютерные системы, которые работают быстро и надежно. Его задача изучить, почему система функционирует не так, как хотелось бы, разобраться в причинах медленной или не соответствующей целевым параметрам работы, выявлять и находить проблемные места, помогать их устранять.

Сергей Качкин рассказал о поиске узких мест в программном стеке и оптимизации производительности СХД, о том, чем занимается его команда.

Сергей, как вы пришли в компанию YADRO? Был ли у вас уже опыт работы с OpenPOWER?
До этого я работал у другого вендора, занимался поддержкой проприетарной версией ОС UNIX на IA64 (не путать с x86) процессорах в части производительности ядра. Архитектура EPIC не похожа на RISC, она совсем другая. Так что опыт работы с OpenPOWER в компании YADRO у меня первый, и перестройка заняла какое-то время. Но идея у OpenPOWER, несмотря на некоторый минимализм, та же самая, поэтому всё можно освоить.

Чем занимаются performanceинженеры? Какие методы применяют в работе? Сложно ли вам набирать новых сотрудников?
Основная специализация нашей команды инжиниринг производительности или performance engineering. Это отдельная дисциплина, нацеленная на то, чтобы убедиться: разрабатываемое решение удовлетворяет нефункциональным требованиям, в частности производительности. Она включает в себя набор практик, знаний, методов и техник, которые могут применяться на разных этапах разработки программного обеспечения: подготовительном, этапе программирования, тестирования и эксплуатации системы.

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

Как вы обеспечиваете контроль качества и выявление узких мест в стеке программного обеспечения?
Методы можно разделить на два подвида. Первый это системно-ориентированный подход (system centric approach). Он ориентирован на ресурсы: мы анализируем загрузку отдельных компонентов системы и на основании полученных результатов делаем предположение, где имеется узкое место.

Второй это подход, ориентированный на приложение (application centric approach), когда объектом исследования становятся приложения целиком или отдельные процессы в Linux. Мы смотрим, что делает приложение, какую работу выполняет. Полезная эта работа, или оно делает что-то бесполезное, то есть попусту тратит время. Если приложение в состоянии ожидания, мы смотрим, чего оно ждёт. Обычно это аппаратные или программные ресурсы, механизмы синхронизации.

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

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

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

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

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

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

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

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

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

Каковы должны быть масштабы оптимизации СХД? Охватывает ли она также ПО/оборудование серверов, инфраструктуру (SAN)? Предполагает ли обязательную тесную интеграцию программного и аппаратного стеков?
С точки зрения performance engineering система рассматривается целиком, в комплексе, то есть приложение, хост (сервер), инфраструктура хранения данных, (SAN), СХД. Важно представлять, как работает приложение, потому что именно оно генерирует запросы к СХД. Всё это, конечно, учитывается и используется.

Считается, что самый оптимальный вариант использования накопителей разных типов в СХД многоуровневое хранение данных. Можно ли тиринг рассматривать как средство увеличения производительности системы хранения?
Вообще говоря, тиринг похож на кэширование у них есть общие элементы. Разница лишь в том, что при кэшировании данные дублируются, то есть они находятся и на SSD (в кэше), и на диске, а при тиринге хранятся только в одном месте. То есть, если кэширование это способ оптимизации производительности, то и тиринг тоже можно рассматривать как метод оптимизации.

В чем вы видите преимущества/недостатки программно-определяемых СХД (SDS) с точки зрения анализа производительности и оптимизации системы? Может быть, это более простые, более гибкие решения?

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

Одна из целей компании разработка оптимизированных продуктов для искусственного интеллекта, интернета вещей и сетей пятого поколения. Как вы считаете, насколько сложная это задача? Что будут представлять собой такие продукты?
На данный момент для хранения сырых данных в ИИ часто используют файловые хранилища, для тренинга и построения моделей SDS, то есть это почти всегда распределенные решения. По моему ощущению, во многих компаниях ИИ сейчас используется как некий эксперимент, на него смотрят и пытаются понять, чем он может быть полезен. Поэтому и требования к железу не очень жесткие. Если работает хорошо, не работает можно подождать день-другой. По мере того, как работа ИИ в компаниях будет более критичной, возрастут и требования к дисковым подсистемам. Мы увидим новые СХД решения для ИИ и интернета вещей уже mission critical-класса.

Какую роль в оптимизации ПО играет партнерство YADRO с мировыми технологическими компаниями?
С точки зрения технического специалиста оно, конечно, помогает. Такое сотрудничество способствует общению инженеров друг с другом, их доступу к информации, готовым разработкам, и не приходится каждый раз изобретать велосипед.

Как вам видится роль виртуализации в СХД? Способствует ли она устранению узких мест в ПО или наоборот?И как взаимосвязаны производительность и надежность системы? Можно ли сохранить надежность, увеличивая производительность?
Конечно, виртуализация добавляет сложности, но она может быть полезна для изоляции одной функциональности СХД от другой. В целом это дополнительные издержки и усложнения, поэтому рассматривать ее следует критически, с осторожностью.

Что касается увеличения производительности, то на этом пути, в самом деле, легко потерять надежность. Это своего рода дуализм. Например, когда мы говорим о серверах, то для высокопроизводительного сервера (HPC) надежность обычно на втором месте. Системы хранения, как правило, должны в первую очередь обеспечивать высокую доступность, обладать соответствующей функциональностью и приемлемой производительностью. При увеличении надежности уровня резервирования, система становится сложнее. Возникает необходимость синхронизации элементов. При этом производительность системы неизбежно будет страдать. Задача разработки, свести этот эффект к минимуму.

Сейчас появляются новые классы памяти типа Storage Class Memory, Persistent Memory, совершенствуются флэш-накопители. Как это влияет на архитектуру систем? Успевает ли программное обеспечение за этими изменениями?
Ну, по крайней мере, старается. Вообще, появление быстрой памяти в значительной степени изменило работу performance-инженеров вообще в отрасли. До появления SSD подавляющее большинство проблем с производительностью ИТ систем были связаны с вводом-выводом систем хранения. Потому что есть быстрые процессоры и диски (HDD) с механическими элементами, которые на много порядков медленнее процессора. Поэтому приходилось за счёт алгоритмов пытаться сгладить задержки от медленных дисков.

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

Поменяет ли это архитектуру системы хранения? И да, и нет. Потому что никуда не делись диски. С одной стороны, код должен уметь работать с SSD, то есть быть очень быстрым. С другой, механические диски используются нагрузок, которые они хорошо выдерживают, типа потоковых. При этом размер дисков многократно вырос, а скорость осталась, как и 10 лет назад.

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

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

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



На зимний сезон у нас запланированы четыре технические сессии: по две в декабре и январе.

1. Модернизация глобальной сети предприятия с решением Dell EMC SD-WAN
Сессия прошла 3 декабря, и её можно посмотреть в записи

На вебинаре мы подробно рассказывали о том, как с помощью решения Dell EMC SD-WAN на базе VMware увеличить производительность приложений и обеспечить высокое качество их обслуживания. Сейчас это наиболее актуально для голосовой и видеосвязи, а также виртуальных рабочих столов. И в 2021 году тренд на удалённую работу явно никуда не денется. Также в ходе технической сессии мы подробно изучили преимущества и компоненты решения и познакомили слушателей с облачным оркестратором для управления SD-WAN.

2. DCCS новые возможности по администрированию
24 декабря, 11:00 (МСК)

На этой технической сессии мы сфокусируем внимание слушателей на двух важных компонентах Dell Client Command Suite. Напомним, что это наше фирменное решение для гибкого и удобного управления компьютерным парком организации. Сначала подробно поговорим о Dell Repository Manager приложении, которое позволяет создавать настраиваемые пакеты и репозитории на компьютерах под управлением операционных систем Windows и Linux. Затем перейдем к обсуждению возможностей Dell Display Manager. Это комплексный инструмент для управления (в том числе удалённого) одним монитором или группой мониторов со множеством полезных функций.

3. Инновационные подходы к организации и управлению защитой данных с помощью решения Dell EMC PowerProtect
14 января, 11:00 (МСК)

Этот вебинар подробный и глубокий разговор о платформе Dell EMC PowerProtect. Вести его будет Константин Комаров, один из наших наиболее опытных системных инженеров и настоящий эксперт по платформе. Можно смело заранее готовить самые сложные вопросы непременно разберёмся с каждым из них. Ну и, конечно, обсудим возможности решения, коснемся различных сценариев, связанных не только с организацией резервного копирования в физических, виртуальных и облачных средах, но и особенностями защиты данных в контейнерах. В том числе защиты от кибератак.

4. Как современные проекты по видеонаблюдению меняют требования к СХД
21 января, 11:00 (МСК)

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

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



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

• CloudIQ интеллектуальная система мониторинга и предиктивного анализа
• DCCS администрирование компьютерного парка организации
• Dell EMC ECS внутри объектной СХД
• Портфолио продуктов Dell EMC OpenManage для упрощения управления серверной инфраструктурой
• Автоматизация сетевой фабрики Dell EMC для решений Dell Technologies
• WorkspaceONE универсальное средство управления цифровым рабочим местом

На этом на сегодня всё. Спасибо за внимание и ждём вас на технических сессиях Dell Technologies!

P.S. Кстати, записи прошедшего недавно Dell Technologies Forum 2020 мы тоже выложили в открытый доступ: регистрируйтесь и смотрите в удобное время.

Эксплуатация технически сложного оборудования, типа систем хранения данных, подразумевает наличие у администратора определенных навыков. Однако высокие технологии шагают в массы. И, соответственно, растет число пользователей, впервые столкнувшиеся с ними. Уверены, что статьи в стиле How To являются отличным способом пополнить багаж знаний как для новичков, так и узнать нюансы и особенности для опытных пользователей.

В данной статье мы рассмотрим порядок подключения СХД Qsan к гипервизору VMware ESXi, а также по возможности дадим практические советы по тюнингу настроек для достижения максимальной эффективности использования оборудования.

В рамках данной статьи мы рассмотрим процессы подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Условно в процессе подключения можно выделить несколько основных этапов:

1. Физическая и логическая коммутация
2. Действия на стороне СХД
3. Действия на стороне хоста(ов)

В статье приведены скриншоты настройки гипервизоров ESXi 6.7 под управлением vSphere. В случае Standalone ESXi пункты меню могут называться чуть иначе и ряд настроек отсутствовать.

Физическая и логическая коммутация

Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.

В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).

Важные замечания по поводу параметров SAN сети:

• Фабрики между собой не соединяются для изоляции в случае возникновения ошибок в сети;
• Если протокол iSCSI делит использование коммутаторов с другими сервисами, то весь трафик iSCSI должен быть помещен в изолированный VLAN;
• Для протокола Fibre Channel необходимо настроить в коммутаторах зонирование по принципу один инициатор один или несколько таргетов для исключения взаимовлияния серверов друг на друга;
• Для iSCSI соединений со скоростью 10G и выше рекомендуется включить поддержку кадров большого размера (MTU=9000) с целью увеличения производительности. Важно помнить, что необходимо изменить MTU у всех участников сети: порты контроллера СХД, физические коммутаторы, виртуальные коммутаторы vSwitch, порты vKernel.

Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports

Для ESXi параметр MTU меняется у vSwitch: хост Configure Virtual Switches Edit для конкретного коммутатора

Для vKernel параметр MTU меняется хост Configure Virtual Switches Edit Settings для конкретного порта

Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.

Действия на стороне СХД

Необходимые настройки на СХД можно разделить на два этапа:

• Настройка интерфейсов
• Настройка пространства хранения

Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.

В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.

Далее необходимо создать пространство хранения. Сначала создается пул группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools Create Pool, где запускается пошаговый мастер.

• Необходимо выбрать тип пула: thick (место выделяется сразу) или thin (место выделяется по мере заполнения). Отметим, что thick пулы являются более производительными.
• Выбрать конкретные диски
• Уровень RAID
• Указать параметры физических накопителей, влияющие на их производительность. Рекомендуется использовать установки по умолчанию для максимальной скорости:
  • Enable Disk Write Cache
  • Enable Disk Read-ahead
  • Enable Disk Command Queuing
  • Disable Disk Standby
  
  
  
  
  
  
  
  
  
  
  
  
  
  

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

  
  

  После создания пула(ов) необходимо создать тома (volume): Volumes Create volumes. Также запустится пошаговый мастер создания тома.

  
  
  
  
  
  
  
  

  Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. На свойствах остановимся подробнее.

  
  
  • Block Size размер блока, который будет эмулироваться для хоста. Для ESXi он должен быть 512 байт в силу требований VMware. В противном случае такой диск нельзя будет подключить к ESXi. СХД не сможет установить размер блока меньше, чем у физических накопителей. Поэтому нельзя использовать в СХД диски с разметкой 4Kn (блок 4КБ) совместно с VMware. Требуются накопители 512n или 512e.
  • Background I/O Priority приоритет фоновых задач (расширение, миграция и пр.)
  • Erase Volume Data необходимость зануления создаваемого тома. Значение Fast Erase соответствует записи нулей в первый гигабайт пространства, может быть полезно при повторном использовании дисков с целью удалить остатки предыдущих данных (стереть таблицы размещения). Full Erase запись нулей по всему объему, полезно для достижения максимальной производительности в случае использования RAID 1/10.
  • Enable Cache Mode (Write-back Cache) включение кэша СХД. Очень сильно влияет на производительность.
  • Enable Video Editing Mode снижение производительности ради более стабильных результатов. Для использования совместно с VMware лучше выключить.
  • Enable Read-ahead включение упреждающего чтения. Положительно влияет на производительность.
  • Enable Fast RAID Rebuild при активации данной настройки система будет вести трекинг всех записываемых блоков, чтобы понимать, сколько реальных данных записано на том. В случае выхода из строя диска в составе RAID группы во время ребилда не будут копироваться пустые блоки, что может ускорить данный процесс. Однако стоит помнить, что использование Fast Rebuild снижает производительность при случайном доступе.
  
  

  Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping Map LUN.

  
  
  
  
  
  
  
  
  • Необходимо выбрать протокол доступа: FCP (Fibre Channel) или iSCSI. Доступ к одному и тому же тому может быть только через один протокол.
  • Allowed Host список хостов, которым разрешен доступ к тому. По умолчанию разрешено всем (*). Однако рекомендуется всегда явно указывать разрешения для исключения конфликтов доступа и, соответственно, повреждения файловой системы. Для Fibre Channel указываются WWPN хостов (с возможностью выбора из всех доступных в SAN сети). Для iSCSI указываются IQN хостов. В случае нескольких хостов они добавляются по кнопке Add Host. Со стороны ESXi значения WWPN и IQN можно узнать на вкладке Хост Configure Storage adapters
  
  
  
  
  
  • LUN ID с которым том будет виден хостам. Также по этому идентификатору легко опознать том со стороны сервера. Для корректной работы кластера VMware LUN ID должен быть одинаковым для одного и того же тома для всех узлов кластера.
  
  

  Действия на стороне хоста

  
  

  При использовании протокола iSCSI необходимо выполнить:

  
  
  • один раз добавить Software iSCSI адаптер, если этого не было сделано ранее: Хост Configure Storage adapters Add Software Adapter.
  • Создать отдельные vKernel для работы с iSCSI (минимум два для связи с каждым контроллером СХД). Можно подключить их на существующий vSwitch, но желательно подключить на отдельный, не имеющий Port Group с виртуальными машинами с целью упрощения администрирования. У данного vSwitch должно быть минимум 2 физических линка для отказоустойчивости. vKernel следует назначить IP адреса из разных подсетей, чтобы хост мог однозначно маршрутизировать трафик. Также очень важно для каждого vKernel изменить параметр Failover таким образом, чтобы он использовал только один физический линк, т.к. VMware не поддерживает Teaming для iSCSI. В итоге должно получиться следующее:
  
  

  VMkernel Adapter (vmk#)	Physical Network Adapter (vmnic#)
  iSCSI-1 (СХД Контроллер 1)	Active Adapters vmnic1 Unused Adapters vmnic3
  iSCSI-2 (СХД Контроллер 2)	Active Adapters vmnic3 Unused Adapters vmnic1

  
  

  Установки Failover меняются через изменение настроек Port Group

  
  
  
  
  
  
  
  
  • В свойствах Software iSCSI Initiator необходимо указать адреса таргетов, т.е. СХД на вкладке Dynamic Discovery должны быть введены все используемые IP адреса контроллеров СХД
  
  
  
  
  
  • После любого изменения параметров СХД и SAN сети необходимо выполнить Rescan: Хост Storage Adapter Rescan Storage. Итогом будет появление (т.к. мы добавляем новый том) нового устройства, доступного по 4 путям (согласно топологии подключения через два коммутатора в Dynamic Discovery указано 4 IP адреса портов СХД) с LUN ID = 0, как мы и задавали при публикации на СХД.
  
  
  
  
  

  При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN ID = 1, доступный по 4 путям (по 2 на каждом порту HBA).

  
  
  
  
  

  Следующим шагом будет создание Datastore на новом томе: Хост Actions Storage New Datastore.

  
  

  По умолчанию VMware использует политику работы с многопутевыми устройствами как Most Recently User (MRU). Для большей эффективности и повышения производительности необходимо для каждого Datastore изменить политику на Round Robin, при которой все доступные пути до СХД будут использоваться равномерно. Политика меняется в меню Хост Storage Devices Наше Устройство Properties Edit Multi-Path. После применения политики Round Robin все пути будут использоваться для ввода/вывода (Active I/O).

  
  
  
  
  
  
  
  

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

  
  

  В рамках данной статьи конечно же были рассмотрены далеко не все операции, необходимые для каждодневного взаимодействия серверов ESXi и СХД Qsan. Более полная информация содержится в обязательных для ознакомления руководствах пользователей обоих вендоров.

Мы продолжаем цикл публикаций из серии How To для пользователей СХД Qsan. В данной статье пойдет речь о подключении СХД к серверам на базе Windows Server, в том числе при использовании функционала виртуализации Hyper-V.

В статье мы будем рассматривать подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Сам процесс подключения можно разделить на несколько основных этапов:

1. Физическая и логическая коммутация
2. Действия на стороне СХД
3. Действия на стороне хоста(ов)

В статье приведены скриншоты настройки операционной системы Windows Server 2016/2019 с нелокализованным интерфейсом. Часть описания, не относящаяся напрямую к ОС, взята из нашего предыдущего обзора по настройке ESXi.

Физическая и логическая коммутация

Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.

В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).

Важные замечания по поводу параметров SAN сети:

• Фабрики между собой не соединяются для изоляции в случае возникновения ошибок в сети;
• Если протокол iSCSI делит использование коммутаторов с другими сервисами, то весь трафик iSCSI должен быть помещен в изолированный VLAN;
• Для протокола Fibre Channel необходимо настроить в коммутаторах зонирование по принципу один инициатор один или несколько таргетов для исключения влияния серверов друг на друга;
• Для iSCSI соединений со скоростью 10G и выше рекомендуется включить поддержку кадров большого размера (MTU=9000) с целью увеличения производительности. Важно помнить, что необходимо изменить MTU у всех участников сети: порты контроллера СХД, физические коммутаторы, физические и виртуальные порты сетевых карт серверов.

Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports

В Windows Server параметр MTU меняется в настройках драйвера адаптера:
Control Panel\Network and Internet\Network Connections Свойства конкретного адаптера Configure Advanced Jumbo Packet (у некоторых адаптеров этот пункт может называться что-то типа Large Packets)

Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.

Действия на стороне СХД

Необходимые настройки на СХД можно разделить на два этапа:

• Настройка интерфейсов
• Настройка пространства хранения

Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.

В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.

Далее необходимо создать пространство хранения. Сначала создается пул группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools Create Pool, где запускается пошаговый мастер.

• Необходимо выбрать тип пула: thick (место выделяется сразу) или thin (место выделяется по мере заполнения). Отметим, что thick пулы являются более производительными.
• Выбрать конкретные диски
• Уровень RAID
• Указать параметры физических накопителей, влияющие на их производительность.
  Рекомендуется использовать установки по умолчанию для максимальной скорости:
  
  • Enable Disk Write Cache
  • Enable Disk Read-ahead
  • Enable Disk Command Queuing
  • Disable Disk Standby

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

После создания пула(ов) необходимо создать тома (volume): Volumes Create volumes. Также запустится пошаговый мастер создания тома.

Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. Рассмотрим их более подробно.

• Block Size размер блока, который будет эмулироваться для хоста. Для Windows Server рекомендуется задать значение 4КБ как наиболее оптимальное.
• Background I/O Priority приоритет фоновых задач (расширение, миграция и пр.)
• Erase Volume Data необходимость зануления создаваемого тома. Значение Fast Erase соответствует записи нулей в первый гигабайт пространства, может быть полезно при повторном использовании дисков с целью удалить остатки предыдущих данных (стереть таблицы размещения). Full Erase запись нулей по всему объему, полезно для достижения максимальной производительности в случае использования RAID 1/10.
• Enable Cache Mode (Write-back Cache) включение кэша СХД. Очень сильно влияет на производительность.
• Enable Video Editing Mode снижение производительности ради более стабильных результатов. Если не предполагается использование тома в системах видеонаблюдения, лучше выключить данный параметр.
• Enable Read-ahead включение упреждающего чтения. Положительно влияет на производительность.
• Enable Fast RAID Rebuild при активации данной настройки система будет вести трекинг всех записываемых блоков, чтобы понимать, сколько реальных данных записано на том. В случае выхода из строя диска в составе RAID группы во время ребилда не будут копироваться пустые блоки, что может ускорить данный процесс. Однако стоит помнить, что использование Fast Rebuild снижает производительность при случайном доступе.

Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping Map LUN.

• Необходимо выбрать протокол доступа: FCP (Fibre Channel) или iSCSI. Доступ к одному и тому же тому может быть только через один протокол.
• Allowed Host список хостов, которым разрешен доступ к тому. По умолчанию разрешено всем (*). Однако рекомендуется всегда явно указывать разрешения для исключения конфликтов доступа и, соответственно, повреждения файловой системы. Для Fibre Channel указываются WWPN хостов (с возможностью выбора из всех доступных в SAN сети). Для iSCSI указываются IQN хостов. В случае нескольких хостов они добавляются по кнопке Add Host. Со стороны Windows значения WWPN и IQN можно узнать через консольную (PowerShell) команду Get-InitiatorPort

• LUN ID с которым том будет виден хостам. Также по этому идентификатору легко опознать том со стороны сервера. В случае использования Windows Cluster для корректной работы LUN ID должен быть одинаковым для одного и того же тома для всех узлов кластера.

Действия на стороне хоста

Первоначально необходимо один раз установить на сервере компонент Multipath IO, который обеспечивает работу многопутевого ввода/вывода. Данное действие производится через стандартный диалог Add Roles and Features

При использовании протокола iSCSI необходимо выполнить:

• В свойствах Software iSCSI Initiator необходимо указать адреса таргетов, т.е. СХД на вкладке Discovery должны быть введены все используемые IP адреса контроллеров СХД
• После обнаружение таргетов к ним необходимо подключиться при помощи кнопки Connect. Отметим важные детали:
  
  • Необходимо добавить подключаемые таргеты в список Избранных, чтобы в случае разрыва соединения происходило автоматическое переподключение
  • Необходимо включить поддержку MPIO
  • Хотя автоматическое определение маршрутизации в большинстве случаев работает корректно, мы все же рекомендуем не пренебрегать явным указанием с какого сетевого интерфейса сервера необходимо подключаться к конкретному таргету (Advanced Settings)
  • Если через один и тот же сетевой интерфейс сервера производится работа с нескольким портами СХД, то подключение через Connect нужно проделать для каждого пути

• После любого изменения параметров СХД и SAN сети необходимо выполнить Rescan в стандартной оснастке управления дисками или в Device Manager. Итогом будет появление (т.к. мы добавляем новый том) нового устройства, доступного в нашем конкретном примере по 4 путям (согласно топологии подключения через два коммутатора в Discovery указано 4 IP адреса портов СХД) с LUN ID = 0, как мы и задавали при публикации на СХД. Также следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.

При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN ID = 1, доступный по 4 путям. Как и в случае с iSCSI следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.

Важное замечание касательно конфигурирования MPIO. По умолчанию Windows видит дисковые устройства по отдельности, т.е. каждый путь к устройству это отдельный диск.

Чтобы ОС склеила все одинаковые диски в единое устройство, необходимо в стандартной оснастке MPIO добавить новое устройство как многопутевое. Для iSCSI устройств устанавливается отдельное разрешение. По окончании настройки потребуется перезагрузить сервер. Данную настройку необходимо произвести однократно для каждой СХД. После чего все вновь презентованные диски будут опознаваться ОС как многопутевые.

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

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

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

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

Преимущества новых систем хранения:

• Современная микросервисная архитектура. Система базируется на контейнерной архитектуре, когда отдельные компоненты ОС выделяются в отдельные микросервисы. Микросервисная архитектура обеспечивает переносимость функций и быстрое внедрение нового функционала. Такая архитектура позволяет быстро адаптировать ранее написанный функционал на новую платформу т.к. микросервисы автономны и не влияют друг на друга, микросервисная архитектура позволяет обеспечить более высокую надежность работы всей системы по сравнению с монолитной архитектурой. Например, обновление микрокода часто затрагивает только отдельные модули, а не всю систему (или ее ядро) и, как следствие, проходит более гладко.
• Использование передовых технологий хранения данных. Поддержка памяти Storage Class Memory (SCM) Intel Optane и NVMe All-Flash позволяет устранить узкие места в системе и существенно увеличить производительности и сократить время отклика системы.
• Непрерывное сокращение объема данных на лету. Всегда включенные механизмы компрессии и дедупликации данных, позволяют уменьшить объёмы, занимаемые данными внутри системы и оптимизировать хранение. Это позволяет сократить затраты на приобретение и эксплуатацию системы и повысить эффективность работы.
• Гибкая масштабируемость решения. Архитектура решений Dell EMC PowerStore поддерживает как вертикальное, так и горизонтальное масштабирование, благодаря чему вы можете эффективно планировать расширение инфраструктуры наращивая ёмкость или вычислительные ресурсы независимо друг от друга.
• Встроенные механизмы защиты данных. Системы PowerStore обладают широким спектром встроенных механизмов защиты данных от мгновенных снимков и репликации до шифрования данных и интеграции с антивирусными программами. Система также широко интегрируется с внешними решениями, как от Dell Technologies, так и от других производителей.
• AppsON. Благодаря интегрированному в систему гипервизору VMware ESX заказчики могут запускать пользовательские виртуальные машины непосредственно внутри системы.
• Интеграция с VMware. PowerStore предназначен для глубокой интеграции с VMware vSphere. Интеграция включает поддержку VAAI и VASA, уведомления о событиях, управление снимками, vVols, а также обнаружение и мониторинг виртуальных машин в PowerStore Manager.
• Унифицированный доступ к данным. PowerStore обеспечивает хранение данных приложений в различных форматах, от физических и виртуальных томов до контейнеров и традиционных файлов благодаря возможности работы по множеству протоколов блочных, файловых и VMware vSphere Virtual Volumes (vVols). Эта способность обеспечивает высокую гибкость данной системы и позволяет ИТ-отделам упростить и консолидировать инфраструктуру.
• Простой, современный интерфейс управления. Интерфейс управления системой PowerStore Manager разрабатывался на основе требований наших заказчиков к простоте управления системой. Это web-интерфейс, запускающийся на контроллерах системы PowerStore. Доступен по протоколу HTML5 и не требует установки дополнительных плагинов.
• Программируемая инфраструктура. Упрощает разработку приложений и сокращает сроки их развёртывания с нескольких дней до нескольких секунд благодаря интеграции с VMware и поддержке ведущих сред управления и оркестрации, включая Kubernetes, Ansible и VMware vRealize Orchestrator.
• Интеллектуальная автоматизация. Встроенные алгоритмы машинного обучения автоматизируют трудоемкие рабочие процессы: такие как начальное планирование и размещение томов, миграция данных, балансирование нагрузки и устранение проблем
• Аналитическая информация об инфраструктуре. Программное обеспечение Dell EMC CloudIQ для мониторинга и анализа хранилищ сочетает в себе преимущества машинного обучения и человеческого интеллекта для анализа производительности и ёмкости систем в режиме реального времени, а также хранения исторических данных, чтобы получить единое представление об инфраструктуре Dell EMC. Компания Dell Technologies планирует интегрировать CloudIQ с полным портфелем своих решений для еще более глубокой аналитики.

Платформа представлена двумя типами систем:

1. PowerStore T выступает в качестве классической СХД.
2. PowerStore X выступает как гиперконвергентное решение, позволяющее запускать виртуальные машины заказчика, совмещенное с выделенной, классической СХД.

Благодаря интегрированным возможностям VMware ESXi, модели PowerStore X предоставляют возможность размещать приложения с интенсивным вводом-выводом непосредственно внутри системы PowerStore. При использовании встроенных механизмов VMware (vMotion) обеспечивается возможность перемещения приложений между системой хранения PowerStore и внешними решениями. Встроенный гипервизор VMware ESXi запускает приложения заказчиков вместе с операционной системой PowerStore в виде виртуальных машин VMware. Этот инновационный дизайн идеально подходит для приложений с большим объёмом хранилища, обеспечивая дополнительные вычислительные и высокопроизводительные хранилища для существующей среды или любого сценария, в котором плотность, производительность и доступность являются основными факторами.

Явными примерами, когда AppsON идеально решает задачи наших заказчиков, являются:

• Выделенная инфраструктура для одного приложения. Например, для базы данных, которой требуется выделенный сервер, СХД, а также какая-то дополнительная обвязка, например, для резервного копирования. В этом случае вы можете купить одну единственную систему PowerStore которая закроет все задачи, т.к. само приложение и сервер резервного копирования можно развернуть в рамках узла PowerStore без необходимости в дополнительной инфраструктуре.
• ROBO (удаленные филиалы и офисы). Многие заказчики сталкиваются с задачей в каком-то виде реплицировать инфраструктуру основного ЦОД на периферию, чтобы обеспечить работу удаленных филиалов своих компаний. Раньше приходилось для этого покупать отдельные сервера, СХД, коммутаторы для их соединения, а также ломать голову на тему того, как защитить инфраструктуру и самое главное данные. Мы предлагаем, как и в предыдущем примере, пойти по пути консолидации инфраструктуры в рамках одного решения Dell EMC PowerStore. Вы получите полностью готовую инфраструктуру в рамках шасси в 2U, состоящую из пары отказоустойчивых серверов, соединенных с высокоскоростной СХД.

Оба типа систем представлены в виде линейки моделей с разными техническими характеристиками:



Важной особенностью систем PowerStore является возможность модернизации уже купленной системы в будущем. Вот как это можно сделать.

• Традиционный апгрейд младших моделей до старших позволяет избегать лишних инвестиций на этапе закупки системы: нет необходимости сразу покупать дорогое решение, потенциал которого в полной мере раскроется только через несколько лет. Процедура апгрейда это штатная замена одних контроллеров на другие, она выполняется без остановки доступа к данным.
• Благодаря правильно выбранной архитектуре систему можно будет модернизировать до нового поколения, что позволит поддерживать её в актуальном состоянии и увеличить срок эксплуатации.
• Есть способ заложить возможность модернизации системы на этапе закупки. Для этого существует специальная опция Anytime Upgrade, которая позволяет либо актуализировать систему за счёт модернизации её до нового поколения, либо модернизировать систему до более старшей и более производительной модели.

Лицензирование

Dell EMC PowerStore лицензируется по модели Всё включено. Весь доступный функционал заказчик получает вместе с системой без дополнительных инвестиций. По мере выхода нового функционала массива он также станет доступен заказчикам после модернизации микрокода.

Оптимизация физического объема данных

Dell EMC PowerStore включает несколько методов повышения эффективности хранения данных за счёт сокращения используемого данными физического объёма:

• тонкое выделение пространства;
• компрессия имеет аппаратную реализацию и выполняется при помощи отдельного физического чипа, вследствие чего процесс не оказывает влияния на производительность системы;
• дедупликация данных позволяет не хранить только уникальные данные, без повторов.

Динамические пулы

Dell EMC PowerStore оснащается системой RAID на основе экстентов для обработки сбоев дисков. Большое количество элементов RAID представляет собой единое логическое пространство, формирующее пул, с которым работает конечный пользователь.

Архитектура динамический RAID обеспечивает 5 основных преимуществ:

• сокращение времени восстановления после сбоя диска путем параллельного восстановления с множества дисков;
• равномерное распределение запросов записи на все диски;
• возможность смешивать диски разного объема в одном пуле;
• возможность расширения емкости системы путем добавления дисков по одному и более;
• возможность отказаться от физически выделенного диска горячего резерва позволяет системе перестраивать блоки данных с использованием всех исправных дисков.

High availability

СХД Dell EMC PowerStore полностью защищена от сбоев и включает ряд методов обеспечения высокой доступности. Данные методы предназначены для противостояния сбоям компонентов в самой системе и во внешней инфраструктуре, таких как перебои в сети или отключение питания. В случае сбоя отдельного компонента система хранения продолжает обслуживать данные. Система также может противостоять нескольким сбоям, если они происходят в отдельных наборах компонентов. После того, как администратор получит уведомление о сбое, он может заказать и заменить неисправный компонент без последствий.

NVMe SCM

Носители хранения данных SCM (Storage Class Memory) это высокопроизводительные энергонезависимые накопители, созданные на основе технологии Intel Optane. Накопители NVMe SCM имеют меньшую задержку и улучшенную производительность по сравнению с другими SSD. NVMe это протокол, который позволяет осуществлять доступ напрямую через шину PCIe. NVMe разработан с учетом низкой задержки высокопроизводительных носителей. Накопители NVMe SCM служат уровнем хранения для PowerStore, используются для пользовательских данных или метаданных. На данный момент доступны объёмы в 375 и 750 ГБ.

NVMе NVRAM

NVMe NVRAM это высокопроизводительные накопители, используемые для улучшения системы кэширования PowerStore. Они доступны с обоих контроллеров системы и позволяют системе легко кэшировать входящие записи. Накопители работают на скоростях DRAM по PCIe, обеспечивая исключительную производительность. Их конструкция позволяет им функционировать как энергонезависимые носители, и PowerStore может быстро сохранять входящие записи и подтверждать операции хосту без оповещения второго контроллера. Хранилища данных устанавливаются парами для зеркалирования данных между собой на случай аппаратного сбоя.

Данный подход позволил существенным образом ускорить работу системы хранения данных:

• во-первых, контроллерам не надо тратить такты своих ЦП на синхронизацию данных кэш-памяти друг с другом;
• во-вторых, вся запись на накопители происходит блоком в 2 МБ, т.к. система копит этот объем данных перед тем, как записать данные на диски. Таким образом, запись из случайной превратилась в последовательную. Как вы сами понимаете, такой подход существенным образом снижает нагрузку на хранилища данных и сами контроллеры.

Кластеризация

Каждое устройство Dell EMC PowerStore развёртывается в виде одного из узлов кластера, т.к. кластеризация является частью архитектуры данной платформы. На текущий момент в единый кластер можно объединить не более четырех узлов PowerStore. При развертывании кластера с несколькими устройствами эту задачу можно выполнить во время процесса начальной настройки или в будущем добавить устройства в уже существующий кластер. Кластер PowerStore можно уменьшить, удалив устройства из существующего кластера, фактически разделив один большой кластер на два более маленьких.



Кластеризация устройств Dell EMC PowerStore даёт много преимуществ.

• Scale-Out масштабирование для увеличения количества ресурсов системы за счёт добавления дополнительных вычислительных узлов процессора, памяти, ёмкости и интерфейсов подключения к хостам.
• Независимое увеличение ресурсов хранения или вычислительных ресурсов.
• Централизованное управление много узлового кластера.
• Автоматическая балансировка нагрузки между узлами кластера.
• Повышенная надёжность и отказоустойчивость.

PowerStore Manager

PowerStore Manager предоставляет администраторам СХД простой и интуитивно понятный интерфейс для настройки и управления кластером. Он основан на HTML5, не требует установки дополнительного программного обеспечения на клиенте и помогает выполнить следующие задачи:

• Начальная настройка нового узла PowerStore.
• Добавление или удаление узлов из существующего кластера.
• Управление ресурсами кластера.

мкость кластера является агрегацией ёмкостей отдельных узлов кластера. Статистика по экономии доступна для всего кластера целиком.

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

Вместо заключения

На этом краткий рассказ о Dell EMC PowerStore мы завершаем. В данной статье мы разобрали основные моменты, относящиеся к технике и экономике, которые надо понимать при планировании закупки систем PowerStore от кластеризации до лицензирования и планирования будущих апгрейдов. Много технических моментов осталось за кадром, и мы с удовольствием вам про них расскажем либо в следующих статьях, либо при общении со специалистами отдела продаж.

В заключении статьи хочется отметить, что первые проданные системы уже развернуты в ЦОД-ах наших заказчиков, дистрибьюторы и партнеры закупили демо-системы и готовы показывать их вам. Если система вызывала у вас интерес смело обращайтесь к нашим партнёрам и представителям для проработки ваших проектов.

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

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

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

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

• Объем
• Производительность
• Надежность

Объем определяется из количества камер и их типа (считай, разрешения и применяемым ими кодеком), а также глубиной хранения. Любые вменяемые производители камер, а уж тем более вендоры ПО по работе с ними, имеют в открытом доступе калькуляторы для расчета необходимой емкости в зависимости от ваших потребностей. Но в любом случае даже скромный десяток камер с временем хранения в две недели затребует нескольких ТБ дискового пространства. С ростом количества камер и глубины архива потребность в хранилище легко может идти на сотни ТБ и даже ПБ.

С производительностью несколько сложнее. Более 95% времени на хранилище осуществляется запись данных в последовательном режиме (т.е. в максимально комфортном для накопителей). Вместе с тем, периодически происходит поиск по индексной базе и воспроизведение материала. Конечно же на показатель производительности напрямую влияет количество и тип камер. Но современный софт давно научился кэшировать входящие потоки на стороне сервера прежде всего с целью индексации событий и объектов, попавших в объективы камер. Поэтому непосредственная запись на устройство хранения осуществляется крупными порциями по несколько ГБ. Отсюда и требования к хранилищу по части скорости записи относительно невелики: лишь бы успеть записать подготовленный материал за то время, пока набирается следующий. Однако итоговая производительность должна учитывать конкурентные запросы на поиск и воспроизведение, из-за чего массив должен содержать в себе достаточное количество HDD для этого.

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

Внутренние диски сервера могут обеспечить все указанные выше требования лишь отчасти. Так емкость можно нарастить при помощи внешних полок расширения, если требуется обеспечить бОльшую глубину архива. Да и с производительностью дисковой подсистемы едва ли возникнут проблемы при той нагрузке, которую сможет обеспечить сам сервер (точнее ПО видеонаблюдения). А вот с надежностью могут возникнуть вопросы. Ведь будет единая точка отказа в виде самого сервера.

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

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

Практические советы по построению систем видеонаблюдения

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

Если масштаб системы видеонаблюдения таков, что достаточно 1-2 серверов по обработке потоков, то абсолютно нерентабельно использовать в данной конфигурации внешние СХД (кроме случаев с требованиями к повышенной отказоустойчивости). Достаточно использовать внутренние RAID контроллеры и диски. При большем количестве серверов наличие СХД как раз, наоборот, позволит снизить стоимость решения за счет консолидации дисковых ресурсов.

При планировании построения дискового пространства в СХД стоит отказаться от желания сделать один большой массив на все случаи жизни из-за потенциальных проблем с производительностью и надежностью:

• Производительность в RAID массивах хоть и масштабируется с увеличением количества HDD в группе, но постоянная конкурентная запись видеопотоков от множества серверов не всегда позволит получать требуемые скоростные показатели для каждого из них. Разумным решением будет создание отдельных RAID массивов для групп из 2-4 серверов.
• С точки зрения надежности, при использовании HDD большой емкости необходимо использовать как минимум RAID6 с количеством дисков в группе не более 12-14. В случае использования большего числа дисков необходимо объединять такие группы в RAID60. Также следует учитывать, что, при постоянной записи на массив, ребилд для диска емкостью 10-14ТБ легко может занять 2 и более недели. И различные технологии ускорения вроде Fast Rebuild здесь, увы, не помогут. Если позволяют бюджеты, то для повышения надежности все же стоит рассматривать RAID10.

Интерфейс подключения СХД к серверам не играет большой роли с точки зрения производительности. Поэтому чаще всего используется максимально бюджетный вариант с iSCSI. Более того, в случае прямого подключения сервера к СХД вполне достаточно даже скорости 1GbE, благо дополнительные карты расширения с таким интерфейсом для СХД Qsan стоят дешевле портов 10GbE на коммутаторах. Но если подключение происходит все же с использованием коммутатора(ов), то 10GbE, конечно же, является предпочтительным.

В случае использования двухконтроллерных моделей СХД следует учитывать, что на стороне серверов должна быть поддержка MPIO. Акцент на этом моменте сделан не случайно: достаточно часто с целью удешевления на стороне видеосерверов используются клиентские версии ОС (Windows 7-10 и т.п.), которые не могут работать с MPIO.

Также не следует забывать, что блочный доступ подразумевает монопольное использование дискового ресурса конкретным сервером (кроме случаев кластеризации видеосерверов в виртуальных средах). Поэтому необходимо обязательно со стороны СХД настроить контроль доступа к публикуемым томам при помощи LUN Masking. В случае плановой или аварийной замены видеосервера будет достаточно изменить параметры LUN Masking для продолжения работы.

Если рассматривать выбор конкретной СХД для целей видеонаблюдения, то на эту роль вполне подойдут младшие модели (например, серию XCubeSAN XS12xx), поскольку предполагается работа с обычными HDD, latency которых просто несоизмеримы с производительностью контроллеров. При большом количестве дисков особенно выигрышно будут смотреться конфигурации с использованием полок высокой плотности сторонних производителей, благо Qsan официально поддерживает подобное. Переход на старшие линейки СХД оправдан лишь в тех случаях, когда суммарная потоковая запись на СХД предполагается выше, чем 3 ГБ/с, что характерно для очень больших инсталляций с несколькими десятками видеосерверов.

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

Бывает, что нужно получить полную копию тома в рамках одной системы хранения данных (СХД), не снимок, клон, а именно полноценный том. Но не всегда СХД дает это сделать внутри себя собственными средствами. Вроде единственный вариант копировать через сервер, но при этом весь объем данных будет гоняться через сам сервер, сеть до СХД и порты СХД, нагружая все эти компоненты. Но есть SCSI команды, которые могут позволить сделать все в рамках самой СХД и если ваша система поддерживает VAAI от VMware, то практически 100%, что поддерживается команда XCOPY (EXTENDED COPY), которая и говорит массиву что и куда скопировать, не вовлекая в этот процесс сервер и сеть.

Вроде как все должно быть просто, но так сходу я готовых скриптов не нашел, пришлось изобретать велосипед. Для ОС сервера был выбран Linux, а в качестве средства копирования команда ddpt (http://personeltest.ru/away/sg.danny.cz/sg/ddpt.html). Копировать с помощью такой комбинации можно любые тома от любой ОС, поскольку копирование идет поблочно на стороне СХД. Поскольку надо копировать поблочно, а количество блоков надо посчитать, то для подсчета количества таких итераций использовалась команда blockdev. Максимальный размер блока был получен опытным путем, с большим блоком ddpt не работал по факту. В итоге получился следующий довольно простой скрипт:

#!/bin/bash
# first parameter = input device
# second parameter = output device
# device size must be the same
# changing bs variable can reduce speed, max speed should be at bs=32768. 32768 is max setting, lower settings should be calculated dividing by 2

bs=32768
s=`blockdev --getsz $1`
i=0
while [ $i -le $s ]
do
ddpt of=$2 bs=512 oflag=xcopy,direct if=$1 iflag=xcopy,direct count=$bs verbose=-1 skip=$i seek=$i
i=$(( $i+$bs ))
done

Давайте сделаем небольшую проверку! Ну как небольшую, 1ТБ файл создавался небыстро :)

root@sales-demo-05:/home/vasilyk# blockdev --getsz /dev/mapper/mpathfs
2516582400
root@sales-demo-05:/home/vasilyk# blockdev --getsz /dev/mapper/mpathfr
2516582400
root@sales-demo-05:/home/vasilyk# mount /dev/mapper/mpathfs /xcopy_source/
mount: /xcopy_source: wrong fs type, bad option, bad superblock on /dev/mapper/mpathfs, missing codepage or helper program, or other error.
root@sales-demo-05:/home/vasilyk# mkfs /dev/mapper/mpathfs
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 314572800 4k blocks and 78643200 inodes
Filesystem UUID: bed3ea00-c181-4b4e-b52e-d9bb498be756
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

root@sales-demo-05:/home/vasilyk# mount /dev/mapper/mpathfs /xcopy_source/
root@sales-demo-05:/home/vasilyk# ls -l /xcopy_source/
total 16
drwx------ 2 root root 16384 Aug 19 15:35 lost+found
root@sales-demo-05:/home/vasilyk# head -c 1T </dev/urandom > /xcopy_source/1TB_file
root@sales-demo-05:/home/vasilyk# ls -l /xcopy_source/
total 1074791444
-rw-r--r-- 1 root root 1099511627776 Aug 19 17:25 1TB_file
drwx------ 2 root root 16384 Aug 19 15:35 lost+found
root@sales-demo-05:/home/vasilyk# umount /xcopy_source
root@sales-demo-05:/home/vasilyk# mount /dev/mapper/mpathfr /xcopy_dest/
mount: /xcopy_dest: wrong fs type, bad option, bad superblock on /dev/mapper/mpathfr, missing codepage or helper program, or other error.
root@sales-demo-05:/home/vasilyk# cat xcopy.sh
#!/bin/bash
# first parameter = input device
# second parameter = output device
# device size must be the same
# changing bs variable can reduce speed, max speed should be at bs=32768. 32768 is max setting, lower settings should be calculated dividing by 2

bs=32768
s=`blockdev --getsz $1`
i=0
while [ $i -le $s ]
do
ddpt of=$2 bs=512 oflag=xcopy,direct if=$1 iflag=xcopy,direct count=$bs verbose=-1 skip=$i seek=$i
i=$(( $i+$bs ))
done
root@sales-demo-05:/home/vasilyk# time ./xcopy.sh /dev/mapper/mpathfs /dev/mapper/mpathfr
real 11m30.878s
user 2m3.000s
sys 1m11.657s

Что в этот момент происходило на СХД:

Продолжим с Линуксом.

root@sales-demo-05:/home/vasilyk# mount /dev/mapper/mpathfr /xcopy_dest/
root@sales-demo-05:/home/vasilyk# ls -l /xcopy_dest/
total 1074791444
-rw-r--r-- 1 root root 1099511627776 Aug 19 17:25 1TB_file
drwx------ 2 root root 16384 Aug 19 15:35 lost+found
root@sales-demo-05:/home/vasilyk# mount /dev/mapper/mpathfs /xcopy_source/
root@sales-demo-05:/home/vasilyk# tail /xcopy_dest/1TB_file | strings
.;Dj
FcSxz
DHIW
~oz(
Eiok
5+9k
gG7PZ
BukF{IQ
?HW%Y
pt[c$
|Xe,
jV{a
o:a'
H<qD
@5:]
IeEr
f(:H
^;xr
v3F'
NQ|E
\t)?m
ErKP
[7zQB
[\?ut
tme@
w=zO
*T3!
root@sales-demo-05:/home/vasilyk# tail /xcopy_source/1TB_file | strings
.;Dj
FcSxz
DHIW
~oz(
Eiok
5+9k
gG7PZ
BukF{IQ
?HW%Y
pt[c$
|Xe,
jV{a
o:a'
H<qD
@5:]
IeEr
f(:H
^;xr
v3F'
NQ|E
\t)?m
ErKP
[7zQB
[\?ut
tme@
w=zO
*T3!
root@sales-demo-05:/home/vasilyk#

Все получилось, но тестируйте и используйте на свой страх и риск! Как исходный том лучше брать снепшоты, для начала.

Поначалу история звучит довольно просто: СХД хорошо работает три года на расширенной гарантии, относительно нормально живёт четвёртый, а на пятый покупается новая вместо устаревшей. Вендоры выжимают из вас деньги повышением стоимости поддержки и всякими платными фичами вроде поддержки VDI. Можно поломать эту схему? Наверное, да.

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

Собственно, первое, что вы видите в стойке это ручки с названием модели, за которые можно и нужно дёргать контроллеры из массива.



Делается это без выключения, наживую, и запас производительности такой, чтобы банковские системы не тормозили во время замены. Чтобы так получилось, понадобилось написать собственную файловую систему (точнее, аналог RAID), собрать внутри кластер и сделать ещё пару улучшений, заодно выкидывая оверхед, доставшийся от жёстких дисков.

Давайте посмотрим, что получилось и как получилось. Начнём с архитектуры.

Для начала процедура работы с массивом не предусматривает кнопок питания. Совсем. Не понадобится. Для выключения достаточно просто выдернуть кабели из PDU.

Архитектура Pure Storage

Компания начинала с того, что разработала с нуля очень хорошую архитектуру, заточенную под флеш (c 2017 года NVMe), и эффективные алгоритмы дедупликации и компрессии данных. Расчёт был такой: на рынке тогда были массивы из жёстких дисков, гибридные решения и SSD all-flash. Флешовые были дорогие, а дисковые медленные. Соответственно, они ворвались в конкурентное окружение с флешовыми массивами по цене владения дисковых.



Сделали вот что:

1. Написали собственную ОС для дисков. Главная особенность быстрое сжатие данных перед записью, а потом постпроцессинг с мощным дедупом, который позволяет утрамбовать их ещё плотнее и точнее.
2. Взяли только флешовые диски (сейчас это вообще строго NVMе) и мощное железо для вычислений.

Первые внедрения были под VDI-среды, поскольку данные там очень хорошо сжимаются. Алгоритмы дедупликации и сжатия давали выигрыш в шестьдевять раз по используемому месту, то есть при всех преимуществах all-flash скидывали цены примерно на порядок. Плюс подкупала экономическая модель: фиксированная стоимость на поддержку и возможность не менять железку. Тогда я увидел первые замены двух стоек на трёх или шестиюнитовые исполнения, но всё ещё не верил, что эта железяка будет использоваться где-то за пределами VDI.

И тут LinkedIn начал хранить на этих железках. Подключился AT&T. Топ банков и телекомов в США тоже закупил в прод.

Оказалось, алгоритмы сжатия достаточно хорошо подходят для сред разработки и тестирования. После замены SSD на NVME внезапно началась конкуренция в обычных транзакционных базах данных в банковском сегменте. Потому что массив получался быстрым и надёжным из-за своей архитектуры в любой момент можем потерять два любых флеш-модуля. Потом вышел флеш-массив на более дешёвых чипах (QLC) со временем отклика 24 мс, а не 1 мс как в топовых моделях, и я начал наблюдать вынос тех же VNX и Compellent. Стало понятно, что железка вполне себе конкурентоспособная.

Естественно, стоимость ТБ будет по-прежнему высокой там, где есть несжимаемые данные: это шифрование, хранение архивов, видеопотоки (видеонаблюдение) и библиотеки изображений, но иногда и такие внедрения случаются, когда клиенту требуется большая производительность. Знаю случай, когда сжали видео (казалось бы, сжатые данные) дополнительно на 10 %.

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

И вот тут-то начала подкупать модель вечнозелёной СХД.

Постоянный апгрейд

За пять лет в железке из старого остаётся только шасси и блоки питания, по сути. Можно переезжать рывками с переносами, а можно менять комплектующие как в кластере. Собственно, это и есть кластер, только собранный в одной трёхюнитовой (или шестиюнитовой) коробке. Железо делали с нуля для себя. Сначала давайте посмотрим на архитектуру, а потом перейдём к тому, почему удобно менять её по кускам.



Интересные решения такие:

• Вычислительная мощность всегда в два раза избыточная: это нужно для замены контроллера без деградации производительности. При этом на фронте работают оба контроллера, а на бэкенде для записи на флеш-модули используется один контроллер.
• RAID-массив заложен на уровне ОС контроллеров, он N + 2, то есть можно без остановки вытаскивать два любых диска. Что самое смешное, как вытаскиваешь можно поменять их местами и воткнуть обратно, и всё продолжит работать. Это я на тестах проверил.
• Поскольку дисков N + 2, всегда можно восстанавливать данные, используя наименее занятые диски. То есть если данные хранятся на пяти дисках, то достаточно трёх из них для полноценного чтения. И RAID, собственно, читает с трёх дисков, потому что восстановить данные, используя процессорную мощность второго контроллера (который стоит в запасе фактически) быстрее, чем прочесть полный набор.
• И можно выбирать для чтения наименее занятые диски! То есть если в нашем примере данные на пяти дисках, то мы будем читать с тех, куда не идёт запись. Система приоритетов тоже на уровне ОС контроллера, и это какая-то чёртова магия.
• Как вы помните, кэша контроллера нет! Есть буфер на запись, установленный отдельно в шасси, он маленький (несколько ГБ), и он задействуется доли секунды во время онлайн-сжатия данных. Защищён он, кстати, большими конденсаторами, которые позволяют успеть записать всё из буфера при отключении питания. Это я тоже несколько раз проверил. Буфер защищён зеркалированием двойным, там четыре модуля в RAID 10.
• Вместо кэша контроллера на чтение сами NVMe-диски, на запись модули NVRAM. Дополнительно возможна установка модулей Optane. Архитектура не похожа на мидрейндж не зеркалирует кэш, нет классического кэша (но есть SCM-память), нет накладных расходов на это.
• Вместо кнопки питания просто гнездо кабеля. Если его вдруг нужно куда-то перевозить, то есть процедура выключения, но можно просто дёрнуть кабель. Страшно, но работает.
• На первичной записи в буфере лёгкая компрессия примерно уровня 3:1, дальше данные пишутся на диск и потом на постпроцессинге прогоняются тяжёлыми алгоритмами и дедупом. Гранулярность блока 512 байт при том, что норма в индустрии 8 КБ. Если блоки повторяются они плавающие, то есть на повторах границы раздвигаются. Это даёт лучшие коэффициенты сжатия по сравнению с другими вендорами. Старые архитектуры заточены на HDD, новые же позволяют менять время процессоров на более плотную упаковку.
• Приложение может прозрачно переезжать без переключения томов на другие такие же устройства (это для удалённой репликации). Весь софт входит в базовую поставку, апдейты приходят в виде обновлений прошивки.

Но компании оказалось мало собрать свою архитектуру и написать к ней фактически серверную ОС. Они залезли ещё в низкий уровень самих флеш-чипов и выпустили свои. Но при этом совместимые со стандартами. Сверху интерфейс NVMe, внутри чипы своей разработки.



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



Если в обычной дисковой полке каждый SSD или NVMe-модуль это маленький чёрный ящик для контроллера, то тут он видит вообще всё. Понадобилось это при решении проблемы большого адресуемого объёма, потому что проблемы flash-массивов всё те же: управление износом, сбор мусора и т. п. Это делается прошивкой контроллеров.





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

Дальше приходит маркетинг и предлагает громкое заявление нестареющая СХД. Фиксированный ценник поддержки, включено всё ПО, никаких дополнительных бандлов. За счёт отдельного уровня сервиса можно делать замену контроллеров бесплатно раз в три года (Evergreen GOLD-уровень). Есть апгрейды по мере повышения требований: я видел, как XR2 поменяли на XR3. Поработал год, потом пришёл бизнес, сказал, нам нужно новое. У вендора есть вариант сдать старые контроллеры трейд-ином и получить новые раньше времени. Хороший апгрейд. Контроллеры просто меняются по одному.

Апгрейд дисков интереснее. Приходит сервисная полка дополнительная с дисками с завода. На полку мигрируются данные без остановки все данные с тех носителей, что подлежат замене. Полка работает с основными контроллерами (у неё есть и свои). Фактически это юнит-датапак, временное хранилище. Когда миграция кончается, диски помечаются как ОК, инженер их вынимает из шасси. На место старых вставляет новые и запускает обратную миграцию. Это занимает день и больше, но приложения и сервера не замечают. Поскольку эти СХД часто стоят у сервис-провайдеров, есть возможность одновременной замены и апгрейда: в рамках Evergreen GOLD можно старые диски поменять на несколько новых ёмких и быстрых, плюс докупить таких же.

Так, хорош заливать, слабое место всегда компрессия!

Это мы привыкли слышать от пользователей дисковых СХД. Там история стандартная функционал не предусматривался при разработке архитектуры включили сжатие, приложение остановилось, дальше потратили много времени на то, чтобы всё заново восстановить под ругань руководства. Как уже говорили, в Pure Storage пошли другим путём дедупликацию с компрессией сделали базовым неотключаемым функционалом. Результат сейчас Pure Storage cтоит более чем в 15 тысячах инсталляциях. Во время инициализации можно поставить галочку давать обезличенную статистику, и тогда ваша СХД будет отправлять в систему мониторинга Pure 1. Гарантия для баз данных, например, 3,5:1. Есть конкретные особенности тот же VDI от 7:1 и выше. Массивы продаются не по сырому месту, а по полезной ёмкости с гарантией допоставки, то есть если у вас при миграции окажется уровень сжатия ниже гарантируемого, вендор ставит больше физических дисков бесплатно. Вендор говорит, что диски доставляются в примерно 9-10 % случаях, и ошибка редко превышает пару накопителей. В России я такое ещё не видел, коэффициенты совпадали на всех инсталляциях кроме случая, когда вскрываются шифрованные данные, про которые заказчик не сказал, что они шифрованные.

Из-за особенностей снапшотов тестовые среды получаются очень эффективными. Есть пример клиента, который делал сайзинг 7:1 в расчёте, а получил 14 с копейками к одному.

Вендор заявляет следующее:

• 3,5:1 базы данных (Oracle, MS SQL).
• 4,2:1 виртуализация серверов (VMware, Hyper-V).
• 7,1:1 VDI (Citrix, VMware).
• 5:1 средний коэффициент по всей инсталлированной базе.

Также из интересного функционала: автоматизация и интеграция с модными молодёжными штуками типа Kubernetes, а также полная поддержка VMware vvol. Здесь всё просто большая часть западных клиентов Pure Storage облачные провайдеры типа ServiceNow, кейс по которым, кстати, выложен на сайте. Они привыкли всё максимально автоматизировать.

Итого

Получилась интересная штука, которая сначала выглядит странно, а потом всё радостнее и радостнее. Пять лет в Гартнере:



Конечно, экономическая модель Evergreen не такая, что прямо дёшево-дёшево, но от ряда геморроев спасает и при расчёте стоимости владения на несколько лет выглядит вполне конкурентоспособно.

P.S. По ссылке доступен онлайн-митап: Системы хранения данных по подписке: правда или вымысел.

Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.

В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас никакая, и чтобы догнать топовых производителей потребуются десятилетия (т.е. в условиях нынешней реальности никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем догнать и перегнать ведущих мировых производителей процессоров.

Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.

Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.

РЕГИСТРАЦИЯ НА ВЕБИНАР

Тестовый стенд

Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).

Схематично стенд выглядит следующим образом.

Стенд 1 e2k (Эльбрус)

Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16 G 2 шт.
• СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Стенд 2 amd64 (Intel)

Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16 G 2 шт.
• СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.

Методика тестирования

Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).

Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.

Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).

Выполняться будут основные и популярные сценарии использования СХД, в частности:

первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.

1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random

2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random

вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.

3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

третья группа тестов эмулирует работу потокового чтения (пример онлайн трансляции, восстановление резервных копий) и потоковой записи (пример видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.

5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.

Результаты тестов

Результаты тестов сведены в две таблицы.

Эльбрус 8С (СХД Аэродиск Восток 2-Э12)

Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)

Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.

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

Если говорить о случайной нагрузке небольшими блоками, то:

• с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
• с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.

В последовательной нагрузке небольшими блоками картина другая:

• и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

А вот в последовательной нагрузке большими блоками картина прямо противоположная:

• оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.

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

Выводы и ближайшее будущее

Сравнительные тесты процессоров среднего уровня Эльбрус и Intel для задач хранения данных показали примерно равные и одинаково достойные результаты, при этом каждый процессор показал свои интересные особенности.

Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.

При случайной записи небольшими блоками оба процессора показывают равные результаты.

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

Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:

• информационные системы с преобладанием операций записи;
• файловый доступ;
• онлайн-трансляции;
• видеонаблюдение;
• резервное копирование;
• медиа-контент.

Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.

Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.

Мы ожидаем выхода версии Аэродиск ВОСТОК на базе ядра 5.4 ближе к концу года, и как только работа над новой версией будет завершена, мы обновим результаты тестирования и также опубликуем их здесь.

Если теперь вернуться к началу статьи и ответить на вопрос, кто же прав: пессимисты, которые говорят, что Эльбрус никакой и никогда не догонит ведущих производителей процессоров, или все-таки оптимисты, которые говорят, что уже почти догнали и скоро перегоним? Если исходить не из стереотипов и религиозных предубеждений, а из реальных тестов, то, однозначно, правы оптимисты.

Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.

Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар ОколоИТ, чтобы в прямом эфире на эти вопросы дать ответы.

В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.

РЕГИСТРАЦИЯ НА ВЕБИНАР

Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

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




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

40 лет развития распределённых СХД

Первые сетевые хранилища в привычном нам виде появились в 1980-х. Многие из вас сталкивались с NFS (Network File System), AFS (Andrew File System) или Coda. Спустя десятилетие мода и технологии изменились, а распределённые файловые системы уступили место кластерным СХД на основе GPFS (General Parallel File System), CFS (Clustered File Systems) и StorNext. В качестве базиса использовались блочные хранилища классической архитектуры, поверх которых с помощью программного слоя создавалась единая файловая система. Эти и подобные решения до сих пор применяются, занимают свою нишу и вполне востребованы.

На рубеже тысячелетий парадигма распределённых хранилищ несколько поменялась, и на лидирующие позиции вышли системы с архитектурой SN (Shared-Nothing). Произошёл переход от кластерного хранения к хранению на отдельных узлах, в качестве которых, как правило, выступали классические серверы с обеспечивающим надёжное хранение ПО; на таких принципах построены, скажем, HDFS (Hadoop Distributed File System) и GFS (Global File System).

Ближе к 2010-м заложенные в основу распределённых систем хранения концепции всё чаще стали находить отражение в полноценных коммерческих продуктах, таких как VMware vSAN, Dell EMC Isilon и наша Huawei OceanStor. За упомянутыми платформами стоит уже не сообщество энтузиастов, а конкретные вендоры, которые отвечают за функциональность, поддержку, сервисное обслуживание продукта и гарантируют его дальнейшее развитие. Такие решения наиболее востребованы в нескольких сферах.

Операторы связи

Пожалуй, одними из старейших потребителей распределённых систем хранения являются операторы связи. На схеме видно, какие группы приложений производят основной объём данных. OSS (Operations Support Systems), MSS (Management Support Services) и BSS (Business Support Systems) представляют собой три дополняющих друг друга программных слоя, необходимых для предоставления сервиса абонентам, финансовой отчётности провайдеру и эксплуатационной поддержки инженерам оператора.

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

Наши расчёты показывают, что переход от классических СХД к блочным позволяет сэкономить до 70% бюджета только за счёт отказа от выделенных СХД класса hi-end и использования обычных серверов классической архитектуры (обычно x86), работающих в связке со специализированным ПО. Сотовые операторы уже довольно давно начали приобретать подобные решения в серьезных объёмах. В частности, российское операторы используют такие продукты от Huawei более шести лет.

Да, ряд задач с помощью распределённых систем выполнить не получится. Например, при повышенных требованиях к производительности или к совместимости со старыми протоколами. Но не менее 70% данных, которые обрабатывает оператор, вполне можно расположить в распределённом пуле.

Банковская сфера

В любом банке соседствует множество разношёрстных IT-систем, начиная с процессинга и заканчивая автоматизированной банковской системой. Эта инфраструктура тоже работает с огромным объёмом информации, при этом большая часть задач не требует повышенной производительности и надёжности систем хранения, например разработка, тестирование, автоматизация офисных процессов и пр. Здесь применение классических СХД возможно, но с каждым годом всё менее выгодно. К тому же в этом случае отсутствует гибкость расходования ресурсов СХД, производительность которой рассчитывается из пиковой нагрузки.

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

Озёра данных

На схеме выше приведён перечень типичных потребителей сервисов data lake. Это могут быть службы электронного правительства (допустим, Госуслуги), прошедшие цифровизацию предприятия, финансовые структуры и др. Всем им необходимо работать с большими объёмами разнородной информации.

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

Генераторы новой информации

Количество хранимой в мире информации растёт примерно на 30% в год. Это хорошие новости для поставщиков систем хранения, но что же является и будет являться основным источником этих данных?

Десять лет назад такими генераторами стали социальные сети, это потребовало создания большого количества новых алгоритмов, аппаратных решений и т. д. Сейчас выделяются три главных драйвера роста объёмов хранения. Первый cloud computing. В настоящее время примерно 70% компаний так или иначе используют облачные сервисы. Это могут быть электронные почтовые системы, резервные копии и другие виртуализированные сущности.
Вторым драйвером становятся сети пятого поколения. Это новые скорости и новые объёмы передачи данных. По нашим прогнозам, широкое распространение 5G приведёт к падению спроса на карточки флеш-памяти. Сколько бы ни было памяти в телефоне, она всё равно кончается, а при наличии в гаджете 100-мегабитного канала нет никакой необходимости хранить фотографии локально.

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

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

Океан неструктурированных данных

Какие же проблемы влечет за собой появление новых данных? Первейшая среди них, конечно, сам объём информации и расчётные сроки её хранения. Один только современный автономный автомобиль без водителя каждый день генерирует до 60 Тбайт данных, поступающих со всех его датчиков и механизмов. Для разработки новых алгоритмов движения эту информацию необходимо обработать за те же сутки, иначе она начнёт накапливаться. При этом храниться она должна очень долго десятки лет. Только тогда в будущем можно будет делать выводы на основе больших аналитических выборок.

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

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

Всё это требует выработки новых подходов и алгоритмов хранения и обработки информации. И такие подходы появляются.

Технологии новой эпохи

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



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

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



Теперь об эволюции носителей данных. Первые флеш-накопители были выполнены по технологии SLC (Single-Level Cell). Основанные на ней устройства были быстрыми, надёжными, стабильными, но имели небольшую ёмкость и стоили очень дорого. Роста объёма и снижения цены удалось добиться путём определённых технических уступок, из-за которых скорость, надёжность и срок службы накопителей сократились. Тем не менее тренд не повлиял на сами СХД, которые за счёт различных архитектурных ухищрений в целом стали и более производительными, и более надёжными.

Но почему понадобились СХД класса All-Flash? Разве недостаточно было просто заменить в уже эксплуатируемой системе старые HDD на новые SSD того же форм-фактора? Потребовалось это для того, чтобы эффективно использовать все ресурсы новых твердотельных накопителей, что в старых системах было попросту невозможно.

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

Интеллектуальная идентификация дала возможность разложить данные на несколько потоков и справиться с рядом нежелательных явлений, таких как WA (write amplification). Вместе с тем новые алгоритмы восстановления, в частности RAID 2.0+, повысили скорость ребилда, сократив его время до совершенно незначительных величин.

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



А ещё блочные хранилища данных готовятся встретить NVMe. Напомним, что классическая схема организации доступа к данным работала так: процессор обращался к RAID-контроллеру по шине PCI Express. Тот, в свою очередь, взаимодействовал с механическими дисками по SCSI или SAS. Применение NVMe на бэкенде заметно ускорило весь процесс, однако несло в себе один недостаток: накопители должны были иметь непосредственное подключение к процессору, чтобы обеспечить тому прямой доступ в память.

Следующей фазой развития технологии, которую мы наблюдаем сейчас, стало применение NVMe-oF (NVMe over Fabrics). Что касается блочных технологий Huawei, они уже сейчас поддерживают FC-NVMe (NVMe over Fibre Channel), и на подходе NVMe over RoCE (RDMA over Converged Ethernet). Тестовые модели вполне функциональны, до официальной их презентации осталось несколько месяцев. Заметим, что всё это появится и в распределённых системах, где Ethernet без потерь будет весьма востребован.



Дополнительным способом оптимизации работы именно распределённых хранилищ стал полный отказ от зеркалирования данных. Решения Huawei больше не используют n копий, как в привычном RAID 1, и полностью переходят на механизм EC (Erasure coding). Специальный математический пакет с определённой периодичностью вычисляет контрольные блоки, которые позволяют восстановить промежуточные данные в случае их потери.

Механизмы дедупликации и сжатия становятся обязательными. Если в классических СХД мы ограничены количеством установленных в контроллеры процессоров, то в распределённых горизонтально масштабируемых системах хранения каждый узел содержит всё необходимое: диски, память, процессоры и интерконнект. Этих ресурсов достаточно, чтобы дедупликация и компрессия оказывали на производительность минимальное влияние.

И об аппаратных методах оптимизации. Здесь снизить нагрузку на центральные процессоры удалось с помощью дополнительных выделенных микросхем (или выделенных блоков в самом процессоре), играющих роль TOE (TCP/IP Offload Engine) или берущих на себя математические задачи EC, дедупликации и компрессии.



Новые подходы к хранению данных нашли воплощение в дезагрегированной (распределённой) архитектуре. В системах централизованного хранения имеется фабрика серверов, по Fibre Channel подключённая к SAN с большим количеством массивов. Недостатками такого подхода являются трудности с масштабированием и обеспечением гарантированного уровня услуги (по производительности или задержкам). Гиперконвергентные системы используют одни и те же хосты как для хранения, так и для обработки информации. Это даёт практически неограниченный простор масштабирования, но влечёт за собой высокие затраты на поддержание целостности данных.

В отличие от обеих вышеперечисленных, дезагрегированная архитектура подразумевает разделение системы на вычислительную фабрику и горизонтальную систему хранения. Это обеспечивает преимущества обеих архитектур и позволяет практически неограниченно масштабировать только тот элемент, производительности которого не хватает.

От интеграции к конвергенции

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

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

Самый совершенный из доступных нам сейчас методов конвергенции подразумевает создание универсальной гибридной системы. Именно такой, какой должна стать наша OceanStor 100D. Универсальный доступ использует те же самые аппаратные ресурсы, логически разделённые на разные пулы, но допускающие миграцию нагрузки. Всё это можно сделать через единую консоль управления. Таким способом нам удалось реализовать концепцию один ЦОД одна СХД.



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

Массовая СХД нового поколения

OceanStor Pacific отвечает требованиям надёжности на уровне шести девяток (99,9999%) и может использоваться для создания ЦОД класса HyperMetro. При расстоянии между двумя дата-центрами до 100 км системы демонстрируют добавочную задержку на уровне 2 мс, что позволяет строить на их основе любые катастрофоустойчивые решения, в том числе и с кворум-серверами.



Продукты новой серии демонстрируют универсальность по протоколам. Уже сейчас OceanStor 100D поддерживает блочный доступ, объектовый доступ и доступ Hadoop. В ближайшее время будет реализован и файловый доступ. Нет нужды хранить несколько копий данных, если их можно выдавать через разные протоколы.



Казалось бы, какое отношение концепция сеть без потерь имеет к СХД? Дело в том, что распределённые системы хранения данных строятся на основе быстрой сети, поддерживающей соответствующие алгоритмы и механизм RoCE. Дополнительно увеличить скорость сети и снизить задержки помогает поддерживаемая нашими коммутаторами система искусственного интеллекта AI Fabric. Выигрыш производительности СХД при активации AI Fabric может достигать 20%.



Что же представляет собой новый узел распределённой СХД OceanStor Pacific? Решение форм-фактора 5U включает в себя 120 накопителей и может заменить три классических узла, что даёт более чем двукратную экономию места в стойке. За счёт отказа от хранения копий КПД накопителей ощутимо возрастает (до +92%).

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



Эти серверы мало подходят для гиперконвергентных решений. Во-первых, приложений для ARM достаточно мало, а во-вторых, трудно соблюсти баланс нагрузки. Мы предлагаем перейти к раздельному хранению: вычислительный кластер, представленный классическими или rack-серверами, функционирует отдельно, но подключается к узлам хранения OceanStor Pacific, которые также выполняют свои прямые задачи. И это себя оправдывает.

Для примера возьмём классическое решение для хранения больших данных с гиперконвергентной системой, занимающее 15 серверных стоек. Если распределить нагрузку между отдельными вычислительными серверами и узлами СХД OceanStor Pacific, отделив их друг от друга, количество необходимых стоек сократится в два раза! Это снижает затраты на эксплуатацию дата-центра и уменьшает совокупную стоимость владения. В мире, где объём хранимой информации растет на 30% в год, подобными преимуществами не разбрасываются.

***

Больше информации о решениях Huawei и сценариях их применения вы можете получить на нашем сайте или обратившись непосредственно к представителям компании.

В данной статье мы немного поговорим о мониторинге СХД IBM Storwize и других СХД, поддерживающих протоколы CIM/WBEM. Необходимость такого мониторинга оставлена за скобками, будем считать это аксиомой. В качестве системы мониторинга будем использовать Zabbix.

В последних версиях Zabbix компания стала уделять шаблонам гораздо больше внимания стали появляться шаблоны для мониторинга сервисов, СУБД, Servers hardware (IMM/iBMC) через IPMI. Мониторинг СХД пока остаётся вне шаблонов из коробки, поэтому для интеграции в Zabbix информации о статусе и производительности компонентов СХД нужно использовать кастомные шаблоны. Один из таких шаблонов я предлагаю вашему вниманию.


Сначала немного теории.
Для доступа к статусу и статистике СХД IBM Storwize можно использовать:
1) Протоколы CIM/WBEM;
2) RESTful API (в IBM Storwize поддерживается, начиная с ПО версии 8.1.3);
3) SNMP Traps (ограниченный набор trap'ов, нет статистики);
4) Подключение по SSH с последующим удаленным подходит для неторопливого bash-скриптинга.

Интересующиеся могут подробнее ознакомиться с различными методами мониторинга в соответствующих разделах вендорской документации, а также в документе IBM Spectrum Virtualize scripting.

Мы будем использовать протоколы CIM/WBEM, позволяющие получать параметры работы СХД без значительных изменений ПО для различных СХД. Протоколы CIM/WBEM работают в соответствии со Storage Management Initiative Specification (SMI-S). Storage Management Initiative Specification основана на открытых стандартах CIM (Common Information Model) и WBEM (Web-Based Enterprise Management), определяемых Distributed Management Task Force.

WBEM работает поверх протокола HTTP. Через WBEM можно работать не только с СХД, но и с HBA, коммутаторами и ленточными библиотеками.

Согласно SMI Architecture и Determine Infrastructure, основным компонентом реализации SMI является WBEM-сервер, обрабатывающий CIM-XML запросы от WBEM-клиентов (в нашем случае от скриптов мониторинга)

CIM объектно-ориентированная модель, основанная на Unified Modeling Language (UML). Управляемые элементы определяются в виде CIM-классов, у которых есть свойства и методы для представления управляемых данных и функций.

Согласно www.snia.org/pywbem, для доступа к СХД через CIM/WBEM можно использовать PyWBEM open source библиотеку, написанную на Python, и обеспечивающую разработчикам и системным администраторам реализацию протокола CIM для доступа к CIM-объектам и проведения различных операций с WBEM-сервером, работающим согласно SMI-S или другим CIM-спецификациям.
Для соединения с WBEM-сервером используем конструктор класса WBEMConnection:

conn = pywbem.WBEMConnection(server_uri, (self.login, self.password),            namespace, no_verification=True)

Это виртуальное соединение, поскольку CIM-XML/WBEM работает поверх HTTP, реальное соединение происходит в момент вызова методов для экземпляра класса WBEMConnection. В соответствии с IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (Example C-8, стр. 412), в качестве CIM namespace для СХД IBM Storwize будем использовать root/ibm.

Обратите внимание, что для сбора статистики по протоколу CIM-XML/WBEM, необходимо включить пользователя в соответствующую группу безопасности. В противном случае при выполнении WBEM-запросов, вывод атрибутов экземпляра класса будет пустым.

Для доступа к статистике СХД пользователь, под которым осуществляется вызов конструктора WBEMConnection(), должен обладать правами по крайней мере RestrictedAdmin (есть для code_level > 7.8.0) или Administrator (не рекомендую по соображениям безопасности). Подключаемся к СХД через SSH и смотрим номера групп:
> lsusergrp
id name role remote
0 SecurityAdmin SecurityAdmin no
1 Administrator Administrator no
2 CopyOperator CopyOperator no
3 Service Service no
4 Monitor Monitor no
5 RestrictedAdmin RestrictedAdmin no

Добавляем пользователя zabbix в нужную группу:

> chuser -usergrp 5 zabbix

Кроме того, в соответствии с IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (стр. 415) нужно включить сбор статистики на СХД. Так, для сбора статистики каждую минуту:
> startstats -interval 1

Проверяем:
> lssystem | grep statistics
statistics_status on
statistics_frequency 1


Чтобы получить все существующие классы СХД, необходимо использовать метод EnumerateClassNames().
Пример:

classnames = conn.EnumerateClassNames(namespace='root/ibm', DeepInheritance=True)for classname in classnames:     print (classname)

Для получения значений параметров СХД предназначен метод EnumerateInstances() класса WBEMConnection, возвращающий список экземпляров CIMInstance().
Пример:

instances = conn.EnumerateInstances(classname,                   namespace=nd_parameters['name_space'])for instance in instances:     for prop_name, prop_value in instance.items():          print('  %s: %r' % (prop_name, prop_value))

Для некоторых классов, содержащих большое множество экземпляров, таких как IBMTSSVC_StorageVolume, полный запрос всех экземпляров может быть довольно медленным. Он может генерировать большие объемы данных, которые должны быть подготовлены СХД, переданы по сети и обработаны скриптом. На такой случай есть метод ExecQuery(), позволяющий получить только интересующие нас свойства экземпляра класса. Этот метод предполагает использование языка запросов, подобного SQL либо CIM Query Language (DMTF:CQL), либо WBEM Query Language (WQL), для опроса CIM-объектов СХД:

request = 'SELECT Name FROM IBMTSSVC_StorageVolumeStatistics'objects_perfs_cim = wbem_connection.ExecQuery('DMTF:CQL', request)

Чтобы определить, какие классы нам нужны для получения параметров объектов СХД, читаем документацию, например How system concepts map to CIM concepts.
Так, для получения параметров (не счётчиков производительности) физических дисков (Disk Drives) будем опрашивать Class IBMTSSVC_DiskDrive, для получения параметров Volumes Class IBMTSSVC_StorageVolume, для получения параметров массивов Class IBMTSSVC_Array, для получения параметров MDisks Class IBMTSSVC_BackendVolume и т.д.

По производительности можно почитать Functional diagrams of the Common Information Model agent (конкретно Block server performance subprofile) и IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines (Example C-11, стр. 415).
Для получения статистики СХД по Volumes, необходимо в качестве значения параметра ClassName указать IBMTSSVC_StorageVolumeStatistics. Необходимые для сбора статистики свойства класса IBMTSSVC_StorageVolumeStatistics можно посмотреть в Node Statistics.
Также, для анализа производительности можно использовать классы IBMTSSVC_BackendVolumeStatistics, IBMTSSVC_DiskDriveStatistics, IBMTSSVC_NodeStatistics.

Для записи данных в систему мониторинга будем использовать механизм zabbix traps, реализованный на python в модуле py-zabbix. Структуру классов СХД и их свойств расположим в словаре в формате JSON.

Загружаем шаблон на сервер Zabbix, убеждаемся что с сервера мониторинга есть доступ к СХД по протоколу WEB (TCP/5989), размещаем конфигурационные файлы, скрипты обнаружения и мониторинга на сервере мониторинга. Далее добавляем в планировщик запуск скриптов. В итоге: мы обнаруживаем объекты СХД (массивы, физические и виртуальные диски, enclosures и многое другое), передаём их в Zabbix discoveries, считываем статус их параметров, считываем статистику производительности (perfomance counters), передаём всё это в соответствующие Zabbix Items нашего шаблона.

Шаблон Zabbix, python-скрипты, структуру классов СХД и их свойств, а также примеры конфигурационных файлов, можно найти здесь: github.com/pavlovdo/pystormon.

Мы продолжаем цикл статей о нашей новой линейке систем хранения данных PowerStore. Этот материал посвящен уникальному функционалу, позволяющему запускать на борту системы пользовательские приложения AppsON.

Для начала вкратце напомним основные особенности PowerStore. Система имеет микроконтейнерную архитектуру. Разные компоненты ОС выделяются в отдельные, изолированные функциональные элементы (контейнеры). Это обеспечивает простую переносимость функций, стандартизацию и быстрое внедрение нового функционала, а также максимальную гибкость развёртывания.



Как вы наверняка помните из предыдущей статьи, платформа PowerStore представлена двумя типами систем:

• PowerStore T традиционная внешняя СХД, которая подключается к серверам для обеспечения потребностей в хранении информации.
• PowerStore X гиперконвергентное решение на базе гипервизора VMware ESXi, который стал признанным фундаментом для большинства HCI решений. Забегая вперед, отметим, что гипервизор ESXi загружается на каждый из двух контроллеров, работающих в режиме active-active, а PowerStore OS работает как виртуальная машина на каждом узле.

Важно понимать, что после выбора типа системы PowerStore T или X, пользователи не cмогут переключаться между ними в силу архитектурных особенностей, которые мы и рассмотрим ниже.

Размещение гипервизора на борту PowerStore X позволяет одновременно запускать приложения пользователя и функционально организовать внешнюю дисковую систему хранения данных со всем привычным нам функционалом. Этот подход получил название AppsON.

Независимо от того, какую модель PowerStore выберет заказчик, он получает в части СХД одни и те же возможности, службы по работе с данными и полную отказоустойчивость.

Виртуализация функционала СХД обеспечивает не только дополнительную изоляцию и абстракцию операционной системы, но и предполагает в недалёком будущем новые варианты развёртывания платформы, в которых ПО хранения данных может быть развёрнуто на серверах заказчиков либо в облаке, причём без привязки к специально разработанным для этого аппаратным устройствам. С таким подходом мы уже сталкивались на примере Unity VSA (Unity Virtual Storage Appliance), когда заказчик на своем сервере мог развернуть полнофункциональную систему хранения данных.



В PowerStore X, как было отмечено выше, ОС запускается внутри виртуальной машины. Каждый физический узел содержит один экземпляр виртуальной машины с PowerStore OS Controller VM. Этот вариант ничем не отличается от PowerStore OS, работающей непосредственно на физических узлах PowerStore T, но в данном случае 50% аппаратных ресурсов зарезервированы для этой виртуальной машины. Остальные ресурсы доступны для клиентских виртуальных машин.

Для минимизации влияния на производительность СХД совместно с компанией VMware была разработана специальная технология проброса ключевых аппаратных ресурсов PowerStore (диски, чип сжатия и т.д.) напрямую в виртуальную машину PowerStore OS Controller VM. На выходе подобный механизм позволил получить сопоставимое время отклика от дисковой подсистемы с моделью PowerStore T.



Идеальным вариантом использования подобного решения являются рабочие нагрузки с интенсивным вводом-выводом (в отличие от нагрузок с интенсивным вычислением): например, базы данных. Ещё одним вариантом является консолидация, когда надо развернуть инфраструктуру, где фактически нет ЦОД или очень мало места. Кроме того, одновременно с запуском виртуальных машин, PowerStore X может выступать в роли внешней СХД и предоставлять ресурсы хранения серверам через FC или ISCSi.

Таким образом, мы получаем новый уровень унификации решения, а термин Unified Storage играет новыми красками.

Тезисно резюмируем вышесказанное перед тем, как идти дальше:

• ESXi устанавливается непосредственно на каждый из контроллеров PowerStore X.
• PowerStoreOS работает внутри виртуальной машины на каждом из контроллеров. Эта виртуальная машина называется Controller VM (контроллером виртуальной машины).
• PowerStore X может предоставлять традиционные ресурсы хранения (такие как SAN/NAS/vVOl) внешним серверам и вместе с тем выполнять приложения пользователя.
• Независимо от модели X или T, PowerStore разработан с использованием архитектуры Active/Active, оба узла имеют доступ ко всем дискам и ресурсам хранения.
• Как и многие наши продукты, PowerStoreOS основана на операционной системе Linux, которая обеспечивает весь необходимый программный стек: API функции и точки интеграции, размещает веб-браузер для управления системой.
• PowerStoreOS реализована в виде контейнеров Docker. Контейнерная реализация упрощает обслуживание и развитие платформы, поскольку новые сервисы (контейнеры) можно легко и быстро добавить, а затем и перевести в оперативный режим. Если контейнер необходимо перезагрузить или изменить, то для этого не нужно останавливать весь стек. Это также обеспечивает больший потенциал для интеграции в портфель продуктов Dell Technologies, поскольку новые функции могут быть легко развёрнуты в среде докеров для PowerStore для использования.
• В модели PowerStore T 100% системного ЦП и памяти используются PowerStoreOS.
• В модели PowerStore X 50% ЦП и памяти зарезервированы для PowerStoreOS, что гарантирует наличие ресурсов для служб хранения данных, а остальные 50% доступны для запуска виртуальных машин пользователей.

На рисунке представлено наглядное сравнение двух подходов:

• Отдельный физический сервер, на котором запущен ESXi, подключается через FC или iSCSI к внешнему массиву хранения (в данном примере Unity). На сервере работает приложение (внутри виртуальной машины), которое получает доступ к ресурсам хранения данных.
• PowerStore X содержит одновременно вычислительные компоненты и компоненты хранения данных. Два отдельных хоста ESXi (оба контроллера) образуют единый вычислительный кластер. Виртуальная машина Controller VM запускает PowerStoreOS, которая предоставляет доступ к внутреннему хранилищу для любых встроенных приложений или (при необходимости) предоставляет ресурсы хранения для внешних хостов.
• PowerStore X может предоставлять ресурсы хранения внешним потребителям так же, как это делает обычная СХД.
• PowerStore X может выполнять приложения пользователей и обеспечивать их потребности в ресурсах хранения через внутренний интерконнект.
• PowerStore X может быть легко интегрирована в вашу виртуальную ферму. Одно из преимуществ, которое вскоре станет доступно, vMotion для бесшовной миграции ВМ между вашими системами.

Сценарии использования

Консолидация рабочих нагрузок

Очевидным сценарием использования возможностей функционала AppsON является консолидация рабочих нагрузок в рамках одной PowerStore X. Практика внедрения и использования систем PowerStore показала востребованность такого подхода, что подтверждается статистикой продаж. Нашим заказчикам пришлась по вкусу возможность иметь одну систему взамен комплекса различных устройств сервер, SAN-коммутаторы, СХД. Для бизнеса малого и среднего размера, а также для задач не требовательных к большому объему оперативной памяти, такой подход оказался экономически и технически интересным.

Удалённые филиалы (ROBO)

Интересный сценарий применения PowerStore X размещение системы в удалённых филиалах, где не требуется мощная инфраструктура, используются типовые офисные приложения, а технический персонал состоит из одного или двух администраторов-многостаночников. В такой ситуации минимизация нагрузки на сотрудников и упрощение применяемых решений один из важнейших критериев при выборе решения.
При таком подходе компактный форм-фактор 2U, простота развёртывания, гибкая архитектура, способность поддерживать несколько типов данных, централизованное управление и расширенная репликация в основные центры обработки данных делают PowerStore идеальным решением для периферии. Филиалы компаний и магазины розничной торговли, распределительные центры и склады, поликлиники и больницы, где пространство и ресурсы ограничены и где нет узкоспециализированных специалистов, смогут воспользоваться преимуществами простой системы, способной заменить собой целый комплекс различного оборудования и программного обеспечения.

Гиперконвергенция

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

Управление кластером PowerStore в сочетании с инструментами VMware, включая vMotion, обеспечивает беспрепятственную мобильность приложений между PowerStore и другими узлами VMware. Приложения можно развернуть, например, на серверах, гиперконвергентной инфраструктуре или на самом PowerStore, а затем прозрачно для приложения переносить его между этими системами.

Аналитика

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

Интеграция с vCenter

Многие наши заказчики используют VMware vSphere в качестве основной платформы виртуализации для всех своих IT-систем. Таким заказчикам важно понимать, что PowerStore X глубоко интегрирован с VMware vCenter, а следовательно создание виртуальных машин и управление ими ничем не отличается от управления простым внешним сервером ESXi.

Известно, что для взаимодействия VMware и систем хранения данных используется VSI провайдер (Virtual Storage Integrator), который обеспечивает возможности выделения ресурсов хранения, управления и мониторинга непосредственно из интерфейса клиента VMware vSphere.

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



PowerStore поддерживает простую настройку виртуальных машин с использованием vVol, а также отображает много полезной информации о них. Таким образом, заказчики, сделавшие выбор в пользу семейства PowerStore, получают систему с простым управлением и мониторингом, нативной интеграцией с продуктами VMware и возможностью размещения виртуальных машин на самом массиве. В статье мы привели несколько практических примеров использования данного функционала, основанных на реальном опыте эксплуатации AppsON у наших заказчиков. Уверены, что со временем их станет ещё больше, и нам будет о чём рассказать в следующих статьях, посвященных системам PowerStore.

Всем привет. Этой статьей мы начинаем знакомить вас с новой версией российской гиперконвергентной системы AERODISK vAIR v2, в частности, со встроенным гипервизором АИСТ, который сейчас получил возможность работать автономно от vAIR, используя внешние СХД.

Изначально мы хотели рассказать о функциональности новой версии vAIR в одной статье, но материала получилось очень много, и мы встали перед выбором: либо сократить материал, либо разбить его на три части. Мы выбрали второй вариант и разбили материал следующим образом:

• Управление кластером и гипервизор АИСТ
• Файловая система ARDFS
• Аппаратные платформы, лицензирование и поддержка

Соответственно, в первой части мы расскажем о функциях управления vAIR v2 и более подробно о подсистеме виртуализации. Но сначала хотелось бы сказать пару слов об архитектурных изменениях в версии vAIR v2.

Коротко об архитектуре. Основные отличия между первой и второй версией

С момента выхода первой версии в 2019 году архитектура vAIR претерпела ряд изменений. Связано это в первую очередь с борьбой за стабильность, ресурсоемкость и производительность. Однако обо всем по порядку.

Описывать полностью архитектуру с нуля мы рамках этой статьи не будем. Коснёмся лишь тех отличий, которые существуют в настоящий момент между первой и второй версией. Для более глубокого знакомства с изначальной архитектурой vAIR v1 рекомендуем ознакомиться с нашими предыдущими статьями на эту тему:

• Принцип работы файловой системы ARDFS
• Архитектура vAIR

На уровне большой картинки на данный момент архитектура vAIR v2 выглядит следующим образом:

Ну а теперь переходим к деталям.

Косметические изменения

Незаметное внешнему глазу, но при этом важное и трудоемкое событие произошло в распределенной базе конфигураций (ConfigDB), которая отвечает за одновременное хранение конфигураций всех компонентов решения на всех нодах кластера. Мы полностью её переработали и, соответственно, оптимизировали. В итоге ConfigDB стала значительно стабильнее и минимизировала пожирание бесценных аппаратных ресурсов. Если говорить о цифрах, то за счёт переработки полезную производительность решения удалось увеличить примерно на 30%, что, очевидно, хорошо.

Стандартный блок данных, которым оперирует ARDFS, изменился с 4МБ до 64 МБ. Сделано это было также с целью увеличения производительности ввода-вывода.

Ещё одним маленьким, но приятным бонусом, который получился в результате оптимизации ARDFS и ConfigDB, стало снижение минимальных системных требований по количеству нод в кластере. Первая версия vAIR требовала не менее четырех нод, во второй-же версии начинать можно с трёх нод. Мелочь, но тоже приятно.

АИСТ покинул гнездо

Теперь перейдем к главному архитектурному изменению, с которого и начнем рассказ про подсистему виртуализации. Гипервизор АИСТ, который раньше умел работать только внутри vAIR, научился летать работать автономно и, соответственно, может поставляться отдельным продуктом по отдельной лицензии.

Для справки: и АИСТ, и vAIR как два отдельных продукта прошли всю необходимую экспертизу регуляторов и, соответственно, добавлены во всех необходимые гос. реестры Минцифры и Роспатента, чтобы по-честному считаться российским ПО.

Чтобы не было путаницы, поясним. По факту АИСТ и vAIR не являются разными продуктами. Гипервизор АИСТ это составная и обязательная часть гиперконвергентной системы vAIR, при этом АИСТ может использоваться в качестве самостоятельного решения, а также АИСТ может всегда быть обновлен до полноценного vAIR-а.

Данное архитектурное изменение не только позволяет импортозаместить зарубежную виртуализацию на российских предприятиях, но и открывает ряд крайне полезных сценариев использования vAIR. Разберем их:

Сценарий 1. Просто гиперконвергент

Тут все просто. АИСТ используется как составная часть vAIR и работает с хранилищем ARDFS. Это то, что было в первой версии, и остается сейчас.

Виртуальные машины, сеть и хранилище работают в рамках одной отказоустойчивой аппаратной платформы (3 ноды+).

Сценарий 2. Просто виртуализация

Классическая серверная виртуализация. На локальные диски физических серверов устанавливается АИСТ, к АИСТу пригоняются сторонние СХД по файловым или блочным протоколам, и на базе этих СХД хранятся виртуальные машины.

При этом в этой схеме всегда остается возможность добавить локальных дисков во все физические серверы, объединить их быстрым (от 10 Гбит/сек) интерконнектом и обновить лицензию АИСТа до vAIR, получив в итоге гибридный сценарий (см. ниже).

Сценарий 3. Гибридный сценарий

Самый интересный сценарий. Мы одновременно с гиперконвергентом используем в качестве хранилища виртуальных машин сторонние СХД (например ENGINE или ВОСТОК :-)). Полезным является то, что к любой виртуалке, которая хранится на ARDFS, мы можем легко прицепить дополнительные виртуальные диски с СХД. И наоборот, к любой виртуалке, которая лежит на СХД, мы можем прицепить виртуальные диски с ARDFS. Это открывает очень много возможностей, начиная с задач постепенной и бесшовной миграции инфраструктуры между разными хранилищами, заканчивая полезным использованием старых СХД и серверов хранения, которые и выкинуть жалко, и подарить некому.

В итоге, когда мы пишем vAIR, мы имеем ввиду большой продукт в целом гиперконвергентную систему, которая включает в себя гипервизор АИСТ и файловую систему ARDFS. А если мы пишем АИСТ, то имеем в виду только компонент, который отвечает за серверную виртуализацию и виртуальную сеть. Чтобы внести ещё больше ясности, приводим ниже таблицу с разбивкой функционала по компонентам.

Обзор функционала. Что нового и для чего

Функции управления

Управление системой осуществляется при помощи web-консоли на русском языке (поддерживаются любые браузеры) или командной строки. Важной и полезной плюшкой является то, что за счёт распределённого хранения конфигураций для осуществления управления всем кластером можно подключиться к любой ноде по IP или DNS-имени. Специальных серверов управления разворачивать не нужно. При этом это не запрещено.

Предусмотрен сценарий развертывания управляющей виртуальной машины (УВМ), которая через RestfulAPI может осуществлять полноценное управление всем кластером.

Кстати RestfulAPI, как понятно выше, есть, он описан и работает (по нему будет отдельная статья). Его спокойно можно использовать для автоматизации операций и интеграции со смежными системами. К примеру, уже сейчас есть интеграция (и, кстати, есть внедрение в продуктив) с российским VDI-решением Термидеск, как раз реализованная на базе нашего API. Плюс ещё несколько продуктов вендоров-партнеров на подходе.

Для управления виртуальными машинами изнутри гостевой ОС используется на выбор два протокола: VNC (по умолчанию) или Spice. На уровне отдельных ВМ администратор может задавать разные варианты подключений.

Сам интерфейс разбит на несколько логических частей.

1) Основная область управления, в которой выполняются почти все операции

2) Основное меню, которое выдвигается наведением курсора

3) Панель действий, на которой отображаются доступные для выбранного объекта действия.

4) Панель задач, которая показывает, какие задачи выполняются или были выполнены над выбранным объектом, вызывается выбором объекта и последующим кликом по кнопке задачи.

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

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

Лирическое отступление: когда я эту функцию показал моему старому товарищу, который является тру-админом (то есть он админил системы в те славные времена, когда систем ещё не существовало) он воскликнул:
Вы нормальные там??!!! Нельзя админить серьезные системы через мобилу!!!
Хочу отметить, что во втором своём высказывании он, безусловно прав, лазить по серьезным кластерам через мобилку опасно, можно ткнуть не туда и всё как обычно упадёт, но всегда есть НО
Я напомнил ему ситуацию, в которую он попал несколько лет назад, когда потратил примерно 40 минут времени и 10 тонн мата на то, чтобы перезагрузить пару зависших виртуалок на известном гипервизоре, используя свой смартфон. Ноутбука у него с собой не было, а его заказчик с паром из ушей требовал устранить проблему здесь и сейчас.
Вспомнив об этом случае, мой товарищ тру-админ перестал сомневаться в нашей нормальности :-).

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

Гипервизор АИСТ

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

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

Если параметр HAVM активен, то в случае отказа ноды кластера, ВМ автоматически перезапуститься на другой ноде.

Для отдельных ВМ или для групп ВМ предусмотрены приоритеты обслуживания (QOS) из libvirt-а, где в свою очередь предусмотрены шаблоны популярных конфигураций.

Для защиты данных на уровне ВМ, а также для большей гибкости администрирования предусмотрены мгновенные снимки и клоны (которые можно превратить в шаблоны ВМ соответственно). Важной доработкой и одновременно крайне большой радостью является то, что снэпшоты делаются на горячую (при работающей ВМ) и полностью поддерживают консистентность файловых систем гостевых ОС (Linux, Solaris, Windows, BSD) и ряда поддерживаемых СУБД (пока только PostgreSQL и MySQL). При этом с помощью RestfulAPI никто не мешает реализовать консистентные снимки для других систем внутри гостевой ОС самостоятельно.

Для внешнего хранения из коробки поддерживается NFS, то есть хранить виртуалки можно на распределенном хранилище ARDFS (доступно в vAIR) или на внешней СХД по протоколу NFS. Опционально предусмотрена поддержка блочных внешних СХД по протоколам iSCSI и FC.

Миграция виртуальных машин со сторонних гипервизоров

Миграция, причем неважно откуда и куда, всегда стоит особняком во всей ИТ-жизни. За время полутора лет эксплуатации нашими заказчиками первой версии vAIR они (и мы автоматически) регулярно сталкивались с проблемами миграции виртуальных машин со сторонних гипервизоров в АИСТ. Штатный конвертер KVM штука хорошая, но крайне капризная. Поэтому в vAIR v2 (и в АИСТе соответственно) мы предусмотрели человеческий конвертер ВМ из VMware/Hyper-V прямо в интерфейсе vAIR/АИСТ.

Для конвертации администратор выбирает шару NFS (пока только NFS), где лежат файлы виртуальных машин VMware или Hyper-V. Далее vAIR сам сканирует шару на наличие нужных ему файлов и формирует доступный список для миграции. Далее выбираем целевой пул ARDFS (или внешнюю СХД), то есть куда будем конвертировать, выбираем нужные файлы ВМ (можно несколько, они будут конвертироваться по очереди) запускаем и идём пить пиво.

Когда пиво выпито, новые, уже сконвертированные, виртуалки ждут нас уже внутри vAIR-а в выключенном состоянии.

Мониторинг и логирование

Функции мониторинга реализованы как локально, так и удаленно. Администратор может работать со счетчиками утилизации ресурсов CPU, RAM, сетевых интерфейсов и подсистемой ввода-вывода (IOPS, MB/s, latency), как на уровне отдельных нод, так и на уровне кластера в целом.

Всё то же самое доступно и для удаленной системы мониторинга на базе Grafana.

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

Кроме описанных выше возможностей гипервизор АИСТ позволяет выполнять функционал, который мы считаем must have, поэтому сильно его разрисовывать не будем, а просто перечислим:

• Обновление ПО без остановки и миграции виртуальных машин
• Живая миграция ВМ, а в ближайшем будущем с возможностью динамичного распределения ресурсов (а-ля DRS)
• Распределённые виртуальные коммутаторы с поддержкой VLAN-ов
• Расширение кластера без остановки виртуальных машин
• Автоподдержка (автоматическое оповещение производителя и заведение тикетов в тех. поддержку, при согласии заказчика, само собой)
• Метрокластер (отдельная большая функция, которой мы посветим позже отдельную статью)

Детально ознакомиться с особенностями функционала можно в технической документации, которая есть у нас на сайте:

https://aerodisk.ru/upload/Datasheet_AIST_final_11042021.pdf

В завершение первой части

В процессе разработки vAIR и АИСТ собственных решений в области виртуализации многие наши доверенные партнеры (которые допущены к раннему доступу), глядя на это, утверждали, что это плохая идея, потому что ВМварь и Нутаникс не догнать, они слишком крутые и великие, у них тысячи программистов по всей планете, бороды длиннее и свитера в два раза толще.

На подобные утверждения мы всегда задавали вопрос.

А эти компании сразу появились на свет с тысячей бородатых разрабов в толстых свитерах?

ИЛИ другой вариант

А вы когда родились вам сразу было 35 лет, у вас была машина, семья, дача, работа и образование? Это в комплекте вам врачи в роддоме выдавали?

В продолжении этой мысли позволим себе процитировать нашу же старую статью:

притча на эту тему.

Однажды странник попал в город, где шло грандиозное строительство. Мужчины ворочали большие камни под палящим солнцем. Что ты делаешь? спросил наш герой у одного из рабочих, который медленно тащил булыжник. Ты что, не видишь камни таскаю! зло ответил тот. Тут странник заметил другого рабочего, который волок телегу с большими камнями, и спросил: Что ты делаешь? Я зарабатываю на еду для своей семьи, получил он ответ. Странник подошел к третьему рабочему, который занимался тем же, но работал энергичнее и быстрее. Что делаешь ты? Я строю храм, улыбнулся тот.

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

В жизни это совсем не так. Практически всегда (за редким исключением), новый серьезный продукт создается небольшим коллективом до 10 человек (а обычно 2-3). При этом на этапе создания закладывается 80% всего функционала продукта. Далее продукт силами этого маленького коллектива выходит на рынок (или как-то еще громко заявляет о себе), и там его уже подхватывают инвесторы (фонды, холдинги или крупные производители).

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

На этом мы завершаем первую часть цикла статей про vAIR v2. В следующей статье подробно расскажем о функционале файловой системы ARDFS.

Также в ближайшее время мы планируем организовать очередной вебинар ОколоИТ, где в прямом эфире поговорим про vAIR и все что его окружает. Тем вебинара есть несколько, от выбора темы зависит, кого мы позовём на вебинар. Поэтому мы хотим право выбора темы отдать в руки ИТ-сообщества и по этой причине запускаем голосование по темам следующего ОколоИТ.

Голосование доступно тут, на Хабре, а также в нашем телеграм-чате https://t.me/aerodisk

Всем спасибо за внимание, как обычно ждем конструктивной критики и интересных вопросов.

Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.

По этому прекрасному поводу мы в Аэродиске, предварительно обновив боевую версию встроенного Альт-Линукса в СХД ВОСТОК до ядра 5.4, повторно выполнили нагрузочное тестирование СХД, которое мы публиковали полгода назад. С прошлым отчетом можно ознакомиться по данной ссылке.

Новые тесты проводились на долгожданном ядре Линукс для e2k версии 5.4, которое появилось начале 2021 года, за что хотим сказать огромное спасибо коллективам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорину лично.

В ядре 5.4 изменений много, но нас интересуют только основные изменения с точки зрения СХД, а их можно разделить на следующие группы:

Общие обновления:

• переработан планировщик ввода-вывода, что позволяет лучше параллелить IO между дисками;
• много мелких оптимизаций под скоростные твердотельные накопители;
• и самое главное изменение новый компилятор от МЦСТ (LCC версии 1.25).

Обновления от Аэродиска:

• обновлённый таргет-драйвер, который позволяет лучше параллелить IO между процессорными ядрами;
• обновление логики работы связки ядро процессора диск для систем на Эльбрусе.

Тестовый стенд

Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.

Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16G 1 шт.
• СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.

Методика тестирования

Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).

СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).

Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.

В ходе тестирование будут выполняться следующие популярные сценарии использования СХД, в частности:

Последовательная нагрузка маленькими блоками 4k

• 100%_read_4k_sequential
• 100%_write_4k_sequential

Случайная нагрузка маленькими блоками 4k

• 100%_read_4k_random
• 100%_write_4k_random

Последовательная нагрузка большими блоками 128k

• 100%_read_128k_sequential
• 100%_write_128k_sequential

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

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

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

Результаты тестов

Последовательная нагрузка маленькими блоками 4k

100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.

Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).
Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.

Случайная нагрузка маленькими блоками 4k

100%_read_4k_random
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_random
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.

Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.

Также с прошлого ядра сохранилась приятная особенность. Если посмотреть на задержки при случайной нагрузке маленькими блоками, то внимание привлекает то, что задержки на запись ниже, чем на чтение (3 мс против 8 мс), когда мы все привыкли, что должно быть наоборот. Эльбрус с точки зрения случайного характера нагрузки по-прежнему любит запись больше чем чтение, что несомненно является отличным преимуществом, которое грех не использовать.

Последовательная нагрузка большими блоками 128k

100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 6 мс у аналогичного процессора архитектуры x-86).

При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).

А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).

Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4

Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые

Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19

Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые

Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все таки полтора миллиона IOPS это много.

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

Кроме того, Эльбрус отлично себя показывает в случайной нагрузке на запись, показывая минимальные задержки, что актуально для классических транзакционных СУБД.

Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.

В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).

Кстати о птичках! В течение этой недели мы определимся с датами следующего технического вебинара ОколоИТ про нашу систему виртуализации АИСТ и гиперконвергентную систему vAIR, ссылка на регистрацию появится в этой статье (следите за обновлением), а также в нашем телеграмм-чате.
Ну и само собой, не можем не напомнить о бесплатных курсах по системам Аэродиск, на которые можно записаться тут.

На этой позитивной ноте завершаем очередную статью про Эльбрус. Традиционно ждем каверзных вопросов, конструктивных споров и предложений.

Продолжаем рассказывать об эксплуатации Ceph. Сегодня поговорим о процессе восстановления данных и флагах, которые позволяют его контролировать: norebalance, nobackfill и norecover.

Статья подготовлена на основе лекции Александра Руденко, ведущего инженера в группе разработки Облака КРОК. Лекция доступна в рамках курса по Ceph в Слёрме.

Для полного понимания рекомендуем сначала прочесть статью о флагах для управления состояниями OSD.

rebuild и rebalance в Ceph

Если вы работали с СХД, то сталкивались с процессами rebuild и rebalance, где rebuild это восстановление утерянных копий данных, а rebalance перемещение существующих копий данных с места на место по тем или иным причинам.

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

В Ceph процессы rebuild и rebalance обозначены не так чётко: одна placement group может быть сразу в 6 статусах. Но с точки зрения восстановления и перемещения данных имеют значение два состояния объектов: degraded и misplaced.

Если объект в состоянии degraded, это означает, что какая-то placement group не имеет копий. Например, есть пул с тройной репликацией: у placement group три копии, одна из них в состоянии primary, другие синхронно получают от неё репликацию. Если какая-то из этих копий будет утеряна, объекты окажутся в состоянии degraded. Восстановление degraded объектов это процесс rebuild с точки зрения общепринятых условностей.

Напомню, что placement group в Ceph представлена несколькими placement groups на разных OSD. Состояние misplaced означает, что объекты перемещаются с места на место. Количество копий их placement group правильное, они все синхронны, но где-то создана новая placement group, которая должна заменить одну из существующих копий и ждёт окончания бэкфиллинга. Когда он закончится, старую копию placement group Ceph удалит. Это процесс rebalance в общем понимании.

Глядя на строки degraded и misplaced, вы понимаете, сколько у вас данных деградирует и нуждается в процессе rebuild, и сколько данных нуждается в перемещении с целью rebalance.

Останавливать процессы восстановления и перемещения данных позволяют следующие флаги:

• nobackfill и norecover,
• norebalance.

nobackfill и norecover

nobackfill и norecover делают одно и то же. В коде они отключают процесс recover немного по-разному, но результат один: полная остановка recovery io.

Посмотрим на примере.

Устанавливаем какой-то из флагов:

ceph osd set norecover

Теперь остановим одну из OSD и отправим её в out, чтобы запустился процесс recovery.

systemctl stop ceph-osd@0

ceph osd out 0

Проверяем результат и видим recovery, но это на этапе пиринга placement group. Он относится к recovery io, но по факту ничего не восстанавливает.

Прошло некоторое время и этот процесс закончился.

У нас есть объекты в состоянии degraded и множество статусов placement group, но они заморожены, потому что recovery остановлен.

Надо заметить, что флаг norecover работает не совсем так, как noout (о нём было в предыдущей статье).

Когда мы ставим noout, мы всё ещё можем вручную отправить OSD в out. Здесь не так: мы ставим norecover, тем самым останавливаем идущий прямо сейчас процесс recovery и блокируем любой возможный в будущем recovery.

Флаг norecover блокирует любой вид перемещения данных, будь то с целью восстановления объектов, будь то с целью перемещения неправильно лежащих объектов, которые сейчас в состоянии misplaced.

Теперь снимем флаг:

ceph osd unset norecover

Как результат: пошёл полноценный процесс recovery io.

Если установить флаг nobackfill, то recovery io так же прекратится. Эти флаги работают одинаково.

norebalance

Флаг norebalance отличается. Он позволяет процессу recovery io идти только в случае, если placement group находится в состоянии degraded.

Устанавливаем флаг norebalance:

Флаг установили, но процесс recovery всё равно идёт, потому что есть placement group и объекты в состоянии degraded.

Покажу ещё кое-что.

Вдобавок к установленному флагу norebalance снова установим флаг norecover (флаги можно ставить вместе, они друг другу не противоречат):

После этого выведем в out одну из OSD (под номером 1).

ceph osd out 1

Напомню, к этому моменту одна OSD уже отправлена в out и при этом выключена. Её данные недоступны, это degraded состояние для placement group и объектов.

При этом OSD 1 мы просто отправили в out. Она сейчас отдаёт с себя placement group другим OSD. Появился второй статус misplaced.

Теперь уберём флаг norecover и оставим только norebalance.

Таким образом мы заблокировали процессы переноса объектов в статусе misplaced, но разрешили процессы восстановления placement group в статусе degraded.

Это тот случай, когда нужно отдать максимальный приоритет именно восстановлению degraded объектов.

Случаи применения флагов norecover и norebalance

Общее замечание: не нужно ставить эти флаги просто для перезагрузки сервера. Если хотите перезапустить сервер, используйте флаг noout.

Авария. Бывают ситуации, когда по какой-то причине отключается целая стойка или отдельный сервер. Как и положено, Ceph обнаруживает потерю копий placement group и начинает восстанавливать их на других хостах. Если объём потерянных данных по-настоящему большой (а он может исчисляться сотнями терабайт), то процесс восстановления окажется губительным для всего кластера. В таком случае разумно установить флаг norecover, чтобы на некоторое время остановить recovery io.

Важно понимать, что речь идёт о ситуации, когда потеряна одна копия или домен данных. При этом все placement group находятся в состоянии active, то есть принимают запись и чтение.

Установив флаг norecover, администратор выясняет масштабы аварии. Если у стойки отошло питание или серверу требуется перезагрузка, то в течение короткого времени потерянные данные можно будет поднять, не гоняя их лишний раз по кластеру. Если проблемы серьёзнее и сервер действительно отказал, то флаг norecover нужно снять и позволить Ceph восстановить потерянные копии.

При этом флаг norebalance можно оставить, чтобы дать максимальный приоритет процессам восстановления данных. Особенно это актуально, если в момент потери хоста rebalance уже шёл (например, после добавления нескольких новых хостов).

Высокая нагрузка. Само recovery io может быть очень высокое, и из-за этого возникают проблемы: появляются slow ops, падает производительность. Тогда можно временно приостановить всё recovery io с помощью флага norecover, либо остановить перемещение объектов misplaced флагом norebalance. Опять же, до выяснения причин.

pause

Флаг pause по сути останавливает клиентское io. Никто из клиентов не сможет ни читать, ни писать из пулов Ceph.

ceph osd set pause

Обратите внимание, что Ceph не важно, это восстановление degraded объектов или перемещение misplaced объектов, всё io, которое занимается этим, называется recovery. Когда говорят остановить recovery io, имеют в виду остановить всё вместе.

После установки флага pause останавливается всё, кроме recovery io. Даже MDS не может закоммитить свои данные в пулы или считать данные.

Но восстановление продолжает идти.

Если у вас есть публичный пользовательский сервис, то устанавливать этот флаг нельзя. Его установка сродни катастрофе для бизнеса.

Но есть среды (например, на предприятиях), где можно сказать пользователям, что сервис не будет доступен для обслуживания 3-5-10 часов.

Это может быть полезно при тяжелой DDoS-атаке. Когда какое-нибудь io разрушает кластер, а вы не можете легитимно его отфильтровать или остановить. Чтобы разобраться в проблеме, можно остановить вообще всё с помощью флага pause.

Ещё один вариант использования pause: у вас пострадала значительная часть кластера, и вы хотели бы восстановить её как можно скорее, отдав максимальный приоритет recovery io и заблокировав пользователей, чтобы они не занимали полосу и не замедляли процесс.

Применять осторожно

В заключение скажу: все описанные флаги можно использовать только при внимательном контроле за кластером. Нельзя оставлять их и уходить спать. Они нужны для блокирования естественных процессов, протекающих в Ceph, а сами по себе эти процессы правильные. Система способна сама себя восстанавливать и балансировать. Поэтому блокировать естественные состояния Ceph можно только находясь у компьютера и контролируя процесс.

^{BITBLAZE Sirius 8022LH}
Не так давно мы публиковали новость о том, что отечественная компания разработала систему хранения данных на Эльбрусах с уровнем локализации >90%. Речь идет об омской компании Промобит, которой удалось добиться включения своей СХД Bitblaze Sirius серии 8000 в Единый реестр российской радиоэлектронной продукции при Минпромторге.

Материал вызвал дискуссию в комментариях. Читатели интересовались подробностями разработки системы, нюансами подсчета уровня локализации, историей создания СХД. Чтобы ответить на эти вопросы, мы взяли интервью у главы Промобит Максима Копосова.

Максим, расскажите, пожалуйста, когда и как у вас появилась идея создания отечественной СХД на базе российских процессоров Эльбрус?

Вы знаете, собственную систему хранения данных мы начали разрабатывать еще до появления Эльбрусов. Это была обычная СХД, которая работала на базе процессоров Intel. Подробнее об этом проекте можно почитать на РБК.

Примерно в 2013 году я увидел видеопрезентацию процессора Эльбрус, которую провел директор по маркетингу АО МЦСТ Константин Трушкин. О том, что эта компания разрабатывает отечественный процессор, я слышал еще в конце 90-х или начале 2000-х. Но тогда это была просто новость, я не думал, что проект будет реализован.


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

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


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


Так и получилось, правда, не сразу. Согласно постановлению Правительства РФ от 21 декабря 2019 года 1746 Об установлении запрета на допуск отдельных видов товаров, происходящих из иностранных государств, и внесении изменений в некоторые акты Правительства Российской Федерации, в целях обеспечения безопасности критической информационной инфраструктуры (КИИ) РФ, в том числе используемой при реализации национальных проектов, на два года вводится запрет на допуск к закупкам иностранных программно-аппаратных комплексов. А именно систем хранения данных (Устройства запоминающие и прочие устройства хранения данных).

Отмечу, что мы начали работу задолго до того, как все заговорили об импортозамещении. Более того, в 2011-2012-х годах с самых высоких трибун заявлялось о том, что импортозамещением в ряде отраслей, включая электронику, не стоит заниматься. Нужны инновации, а не повторение того, что уже пройдено другими. В то время термин импортозамещение носил негативную коннотацию, мы старались его не использовать.

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


Расскажите подробнее о процессе разработки

Работа над созданием СХД Bitblaze Sirius серии 8000 началась в 2016 году. Тогда мы подали заявку на конкурс Министерства промышленности и торговли. Постановление от 17 февраля 2016 года с описанием этого конкурса носит длинное название: Об организации работы в Министерстве промышленности и торговли Российской Федерации по проведению конкурсного отбора на право получения из федерального бюджета субсидий российскими организациями на возмещение части затрат на создание научно-технического задела по разработке базовых технологий производства приоритетных электронных компонентов и радиоэлектронной аппаратуры в рамках государственной программы Российской Федерации Развитие электронной и радиоэлектронной промышленности на 20132025 годы.

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

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

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

Наработки для остальных двух макетов тоже не пропали даром их используем в других проектах.

Какие сложности возникали в ходе реализации проекта по созданию отечественной СХД?

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

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

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

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

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

Кроме интегральных схем, мы используем и другие отечественные компоненты. Вот список:

• Процессор Эльбрус.
• Южный мост.
• Печатные платы.
• Материнская плата.
• Световоды.
• Корпус и металлические детали корпуса.
• Пластиковые детали и ряд элементов конструкции.

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

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

Как производился расчет уровня локализации?

Ответить на это просто. В постановлении от 17 июля 2015 года N 719 О подтверждении производства промышленной продукции на территории Российской Федерации приводятся формулы, согласно которым все это рассчитывается. Наш специалист по сертификации руководствовался именно этими формулами, запрашивая в случае необходимости дополнительную информацию.


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


В итоге винты, конденсаторы, светодиоды, резисторы, вентиляторы, блок питания комплектующие иностранного происхождения составляют 6,5% от стоимости СХД BITBLAZE Sirius 8000. В 94,5% стоимости входит корпус, печатные платы, материнская плата, процессор, световоды, произведенные в России.

Что случится, если доступ к иностранным компонентам закроют?

Закрыть могут доступ к той элементной базе, производители которой подконтрольны США. Если вдруг возникнет этот вопрос, то мы будем использовать компоненты, произведенные китайскими компаниями. Всегда будут компании, которые не обращают внимания на санкции.

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

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