Производительность СХД: как определить, какая система подходит бизнесу?

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

Итак, с точки зрения ИТ-специалиста, производительность СХД — это в первую очередь количество операций ввода-вывода в секунду (IOPS) и объем переданных мегабайтов в секунду (Мбайт/с), которые система хранения способна обеспечить при чтении и записи данных. Производительность СХД в IOPS используется для оценки нагрузки транзакционных приложений: баз данных Online Transaction Processing (OLTP), файловых хранилищ, почтовых систем и прочего. Другой технический параметр, тесно связанный с транзакционной нагрузкой, — время отклика при операциях ввода-вывода (response time). Иными словами, это время, затраченное СХД на обработку одной операции ввода-вывода и передачу ее результатов хосту.

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

Для оценки производительности приложений, у которых профиль нагрузки на СХД представляет собой последовательный доступ к данным, принято использовать объем передаваемых данных, выраженный в мегабайтах в секунду (Мбайт/с). Пример таких приложений — базы данных в конфигурации «хранилище данных» (Data Warehouse, DWH), приложения для обработки видеоконтента и резервного копирования.

ИЗ ЧЕГО СКЛАДЫВАЕТСЯ ПРОИЗВОДИТЕЛЬНОСТЬ

Производительность ИТ-системы в целом определяется производительностью ее отдельных компонентов: приложений, операционной системы, физического или виртуального сервера, сети передачи данных между сервером и СХД и самой СХД (см. рис. 1). Любой из этих компонентов, как правило, состоит из множества отдельных подсистем, каждая из которых способна оказывать влияние на общую производительность ИТ-системы. Так, недостаток оперативной памяти в сервере даже при наличии 100 высокопроизводительных процессорных ядер может привести к заметному снижению общей производительности ИТ-системы. Или, к примеру, неверно выбранная конфигурация дисковой подсистемы СХД старшего класса будет «тормозить» всю ИТ-систему, несмотря на то что такая СХД способна выдержать очень большую нагрузку.

Рис. 1. Производительность ИТ-системы в целом определяется производительностью ее отдельных компонентов

Очевидно, что производительность ИТ-системы — это не сумма показателей всех ее компонентов. Зачастую она зависит от характеристик наиболее «слабого звена». Поэтому если ставится задача повысить производительность ИТ-системы, то не всегда необходимо покупать новую СХД, устанавливать новые серверы с процессорами последнего поколения и т. п. Гораздо важнее выявить узкое место в текущей конфигурации ИТ-системы и понять, можно ли исправить ситуацию, используя имеющиеся ресурсы. Например, замена СХД на флеш-массив (All-Flash Array, AFA) может дать прирост производительности ИТ-системы на несколько десятков процентов, тогда как простая оптимизация SQL-запроса к СУБД позволит увеличить эту производительность многократно.

Если же покупка новой СХД неизбежна, нужно тщательно продумать все детали. Чтобы правильно выбрать новую СХД или спланировать модернизацию существующей, необходимо собрать все требования, предъявляемые ИТ-системой к хранению данных, основные из которых — емкость и производительность. И если вопрос «Сколько терабайтов полезной емкости вам нужно?», как правило, не вызывает проблем, то просьба указать величину необходимой производительности может многих поставить в тупик.

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

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

С ЧЕГО НАЧАТЬ ОЦЕНКУ ПРОИЗВОДИТЕЛЬНОСТИ?

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

Внедрение нового решения тоже, как правило, не вызывает особых трудностей: поставщики программного обеспечения обычно уже имеют готовые рекомендации по развертыванию своих систем. К примеру, у компании VMware существует понятие «шаблонного пользователя» применительно к решениям по виртуализации рабочих мест (VDI). В принятой классификации все пользователи делятся на три категории: light-пользователи несильно нагружают систему, тогда как medium- и heavy-пользователи более требовательны к ресурсам. По каждой категории подготовлены количественные характеристики: рекомендуемая емкость памяти, число процессорных ядер, IOPS, объем передаваемых мегабайтов в секунду и так далее (см. таблицу). Таким образом, зная, что необходимо развернуть VDI-систему на 1000 пользователей, специалисты заранее могут оценить, какие ИТ-ресурсы для этого потребуются.

Требования к вычислительным ресурсам для различных категорий пользователей VDI

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

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

КАК ИСПОЛЬЗОВАТЬ ДИСКОВЫЕ РЕСУРСЫ СХД С УМОМ

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

Каким образом достигается экономия? В основу многоуровневого хранения положен следующий факт: данные, хранящиеся на СХД, в большинстве случаев востребованы неравномерно. Так, в приложении, которое собирает и накапливает, скажем, данные о погоде, активно используемых — или, в терминологии многоуровневого хранения, «горячих» — не более 5–15% от общего объема. Это связано с тем, что свежие данные запрашиваются намного чаще, чем, например, данные пятилетней давности.

Для хранения «горячих» данных всегда рекомендуется использовать высокопроизводительные диски. Обращение к оставшимся «холодным» данным происходит гораздо реже, и потому для их хранения лучше задействовать более дешевые и емкие, но менее производительные диски SAS или NL-SAS. При этом система хранения автоматически перераспределяет активные и неактивные данные между соответствующими быстрыми и медленными уровнями хранения (см. рис. 3).

Рис. 3. Многоуровневое хранение

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

ДЛЯ КАКИХ ЗАДАЧ ПОДОЙДУТ МНОГОУРОВНЕВЫЕ ПУЛЫ?

Основной критерий выбора многоуровневого хранения, как уже было сказано, — неравномерность использования данных. Наиболее часто многоуровневое хранение используется с базами данных OLTP и виртуальными средами, построенными на основе VMware и Microsoft Hyper-V. Однако необходимо отметить, что универсальных рецептов, гарантирующих, что этот подход будет эффективным абсолютно для всех решений, не существует. Если у компании есть сомнения в правильности применения многоуровневого хранения, она всегда может протестировать свою ИТ-систему на конкретной системе хранения данных и оценить ее эффективность.

Алексей Силин, консультант-эксперт компании Hitachi Data Systems