В настоящее время комплексы выскопроизводительных вычислений востребованы во многих отраслях, в том числе весьма далеких от «чистой» науки. Однако при создании и эксплуатации таких систем имеется масса проблем и тонкостей, не всегда заметных с первого взгляда. И подсистемы хранения данных — в их числе.

Наша компания образовалась в результате реорганизации хорошо известной в геофизической отрасли компании Paradigm, которая решила прекратить сервисный бизнес по обработке и интерпретации сейсмических данных и сосредоточиться исключительно на разработке программного обеспечения в этой области. Таким образом, наша команда (на сегодня в ней более 40 высокопрофессиональных специалистов, работающих вместе более 10 лет) продолжает заниматься сервисными услугами по обработке и интерпретации данных сейсморазведки в новой компании PetroTrace Global, которая существует на рынке уже больше года.

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

Подобные расчеты требуют больших объемов вычислений. Так что с высокопроизводительными вычислениями наша деятельность была связана всегда. Менялось только оборудование. Когда я начинал работу, применялись в основном системы от Silicon Graphics и Sun. Сейчас мы используем кластерные решения на базе систем стандартной архитектуры, работающие под управлением Linux. Наши рабочие станции также работают на Linux.

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

Но общей характеристикой является большой объем данных. Исходные данные для площади в несколько сотен квадратных километров занимают около 0,5 —1 терабайта. Это зависит от условий задачи: специфики самой площади, требуемой точности расчета, плотности зарядов и датчиков. В ходе работы над проектом его объем увеличивается еще в три — пять раз.

Естественно, все это налагает определенные требования к подсистеме хранения данных. Прежде всего, по объему хранимых данных. Нужно, чтобы все нужные нам данные на СХД помещались. Также решение многих задач требует параллельного доступа к системе хранения с нескольких расчетных узлов. А вот с этим возникают серьезные проблемы у большинства классических СХД, будь то системы, подключенные к какой‑то конкретной системе или к сети NAS. Такая архитектура не в состоянии обеспечить необходимую скорость обмена данными, из‑за чего производительность существенно снижается. И все потому, что не справляется подсистема ввода/вывода, которая не успевает считывать и записывать данные.

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

Что касается использования всяческих технических и технологических новинок, то многие из них также вполне востребованы на СХД, предназначенных для высокопроизводительных вычислений. Например, SSD-диски. Уже появляются кластеры, где вся подсистема хранения данных построена на их базе. И действительно, прирост по быстродействию впечатляющий. Однако для наших задач сдерживающим фактором стала высокая цена. Не будем забывать, что нам приходится работать с большими объемами данных. Будем надеяться, что по мере совершенствования технологий цена будет снижаться. Вспомним, сколько стоили привычные теперь магнитные диски еще совсем недавно и сколько они стоят теперь.

Однако для многих задач высокопроизводительных вычислений SSD-диски вполне применимы уже сейчас. Ведь далеко не везде приходится оперировать с большими объемами данных, как, например, в большей части технических расчетов. Иногда, в частности при рендеринге видео, первостепенной задачей является обеспечить высокую скорость ввода/вывода, для чего приходится создавать многоуровневые RAID-массивы из большого числа накопителей. Тут использование высокоскоростных SSD-дисков позволяет даже снизить затраты. Популярно применение SSD-дисков и в качестве кэша, но для высокопроизводительных вычислений необходимо хорошее понимание задач. Если данные не помещаются в этот кэш, то никакого выигрыша не будет, а если они существенно больше, то придется много переплачивать за дорогостоящие диски. А понимание это появляется не сразу, иногда даже далеко не сразу. Что касается внедрения элементов иерархического хранения, то о них говорят уже много лет, только названия технологий постоянно меняются по мере усложнения.

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

Другой популярной технологией в последнее время стала дедупликация. Мы в свое время пытались экспериментировать с ПО компании NetApp, которое оценивало возможную выгоду от использования данной технологии. Но наши данные практически не повторяются, и потому, что вполне естественно, никакого результата мы не достигли. Результат колебался на уровне 5—10% экономии на объеме хранения, хотя в общем дедупликация продвигается на рынок для того, чтобы сокращать эти объемы по крайней мере в разы. Ведь выигрыш возникает не на пустом месте. Он требует приложения вычислительных ресурсов и ведет к снижению производительности, а у многих вендоров требует затрат на лицензирование или приобретения ПО от сторонних вендоров. Учитывая это, мы сочли, что игра не стоит свеч.

Другая «модная» технология, ThinProvisioning, дает результаты только при активном использовании виртуализации. Только в этом случае имеет смысл говорить о каком‑то усреднении производительности и выделяемых ресурсов, в том числе и дисковой емкости. В нашем случае приходится давать ровно столько ресурсов, сколько необходимо.

Что касается проблемы больших данных, то она в полной мере относится к анализу данных, причем относящихся по большей части к категории неструктурируемых. К ним неприменим простой алгоритм «взял базу данных — сделал выборку — получил результат». Речь идет о больших объемах данных, получаемых из разных источников, которые нужно каким‑то образом анализировать. В объемах и алгоритмах анализа (точнее, их отсутствия или сложности) и состоит суть проблемы больших данных. В нашем случае приходится иметь дело ровно с теми данными, структура и методы обработки которых хорошо известны. Да, специфика площади может вносить некоторые коррективы в алгоритмы обработки данных, но не более того. Так что проблема больших данных для нас не актуальна.

Популярные технологии не всегда эффективны

Александр Акишин,
технологический консультант представительства Fujitsu в России и СНГ

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

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

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