Облачное масштабирование: Часть 1. Создание приложения уровня вычислительного узла или небольшого кластера и его масштабирование при помощи технологий HPC

Использование вычислительных ресурсов уровня датацентра по мере необходимости

Познакомьтесь с методами и инструментами создания приложений масштаба вычислительного узла или небольшого кластера, которые можно масштабировать по требованию с помощью технологий высокопроизводительных вычислений (high performance computing – HPC), используя облачную среду. В этой серии статей мы подробно рассмотрим решение уникальных задач с использованием HPC-технологий масштаба датацентра по требованию. Этот подход позволяет архитектору создавать систему локально для ожидаемой рабочей нагрузки, а при пиковых нагрузках использовать по мере необходимости облачные высокопроизводительные вычислительные ресурсы. В части 1 мы сосредоточимся на возможностях разработчиков систем и HPC-приложений максимально эффективно масштабировать свои системы и приложения.

Сэм Б. Сиверт, старший преподаватель, University of Alaska Anchorage

Сэм Сиверт – фотографияДоктор Сэм Сиверт (Sam B. Siewert) работает старшим преподавателем на факультете информатики и вычислительной техники в Университете Аляски, Анкоридж. Он также является приглашенным старшим преподавателем в Университете Колорадо, Боулдер, где читает несколько летних курсов на факультетах электротехники, вычислительной техники и энергетики. С 1988 года доктор Сиверт работал инженером-разработчиком компьютерных систем в аэрокосмической и телекоммуникационной отраслях, а также в отрасли хранения информации. В сферу его интересов как исследователя и консультанта входят масштабируемые системы, компьютерное и машинное зрение, гибридная реконфигурируемая архитектура и операционные системы. Он также интересуется теорией систем реального времени, цифровыми медиа и фундаментальными вопросами компьютерной архитектуры.



25.10.2013

На смену экзотическим архитектурам HPC, основанным на специально масштабированных процессорных ядрах и сетях межсоединений с общей памятью приходят кластеры по требованию используют серийные векторные сопроцессоры общего назначения, конвергентные Ethernet-сети со скоростью передачи данных 40 Гбит/с и более на канал, а также автономные многоядерные серверы. Эти новые облачные HPC-ресурсы по требованию похожи на так называемые вычисления масштаба датацентра, где все узлы являются однородными и автономными, а главный акцент делается на совокупной стоимости владения и на эффективности энергопотребления. Однако HPC-вычисления имеют уникальные возможности, не ограничивающиеся социальными сетями, Web-поиском и другими типичными вычислительными решениями масштаба датацентра. Мы сосредоточимся на возможностях разработчиков систем и HPC-приложений максимально эффективно масштабировать свои системы и приложения.

Переход к высокопроизводительным вычислениям

Начиная с 1994 года, суперкомпьютеры, фигурирующие в рейтингах TOP500 и Green500 (см. раздел Ресурсы), все чаще строятся не как уникальные машины, а путем интеграции имеющихся автономных серверов, кластерных соединений на основе конвергентного Ethernet и InfiniBand и графических сопроцессоров общего назначения (GPGPU), которые используются не для графики, а для обработки нагрузок методом SPMD (единая программа, множество данных). Экзотические специализированные межсоединения процессоров с памятью больше не являются доминирующей тенденцией в области высокопроизводительных вычислений (HPC). На смену им пришли вычислительные системы масштаба датацентра, основанные на серийных аппаратных решениях и нацеленные на сокращение совокупной стоимости владения, повышение энергоэффективности и оптимизацию текущих (OpEx) и капитальных (CapEx) затрат как для разрабатываемых, так и для существующих HPC-решений. Это означает, что можно создать свой собственный небольшой кластер и по мере необходимости использовать HPC-ресурсы масштаба датацентра по требованию.

Возможно, Cray (производитель суперкомпьютеров) и другие компании никогда полностью не откажутся от технологии межсоединений с топологией трехмерного тора (сегодня треть компьютеров из списка TOP500 – это мультипроцессорные системы с массово параллельной архитектурой (MPP), а две трети используют кластерную архитектуру), но фокус на эффективности и новых OpEx-показателях, таких как FLOP/Вт (количество операций с плавающей точкой на ватт) стимулирует переход к высокопроизводительным вычислениям и кластерной архитектуре. Кроме того, сегодня многие приложения ориентированы на данные (например, анализ цифрового видео), поэтому многим системам требуется не только традиционное последовательное высокопроизводительное хранилище для контрольных точек HPC (сохраненное состояние продолжительной вычислительной работы), но и произвольный доступ к структурированным (базы данных) и неструктурированным (файлы) большим наборам данных. Доступ к большим объемам данных – это общая потребность традиционных вычислений масштаба датацентра для облачных сервисов, а также обычных и критических рабочих HPC-нагрузок. Итак, вычисления масштаба датацентра – это не высокопроизводительные вычисления (HPC), но HPC-приложения могут использовать технологию центральной обработки данных для облачных высокопроизводительных вычислений по требованию, если они изначально разрабатывались для этого.

Энергозатраты вычислений

Энергозатраты вычислений можно выразить как отношение производительности в общепринятых единицах к мощности в ваттах (например, FLOP на ватт для вычислений и операций ввода/вывода в секунду на ватт для ввода/вывода). Кроме того, любое вычислительное средство можно представить себе в виде объекта, преобразующего энергию в вычисления, а валовым показателем хорошо спроектированного объекта является коэффициент эффективности использования энергии (PUE) – отношение общей потребляемой мощности установки к мощности, потребляемой вычислительным оборудованием. В настоящее время хорошим считается отношение 1,2 и менее. Причинами высоких коэффициентов PUE являются неэффективное охлаждение, административные расходы, а также использование неприспособленных зданий и помещений в сравнении с облачными датацентрами (см. раздел Ресурсы).

С течением времени в архитектуре масштабируемых вычислений произошли существенные изменения:

  • Раньше ставка делалась на единственный быстрый процессор (однопроцессорная архитектура), чтобы арифметическая логика выполнялась с максимально возможными тактовой частотой и скоростью исполнения инструкций:
    • Джон фон Нейман, Алан Тьюринг, Роберт Нойс (основатель Intel), Тед Хофф (идеолог универсальных процессоров Intel) и Гордон Мур рассматривали первоначальное масштабирование как задачу масштабирования цифровой логики и максимального увеличения тактовой частоты процессора.
    • По крайней мере, до 1984 года (а может и после) общим правилом было утверждение "главное в компьютере - процессор ".
    • Компания Cray Computer разрабатывает для специализированных MPP-машин векторные процессоры (они установлены в суперкомпьютерах X-MP и Y-MP) и мультипроцессоры с распределенной памятью, связанные в топологии трехмерного тора по шести направлениям. Но этот подход применяется исключительно в мире суперкомпьютеров.
    • Корпорация IBM изначально тоже уделяла основное внимание масштабированию мэйнфреймов и быстрым однопроцессорным системам, но в 1999 году она представила архитектуру IBM® Blue Gene®, использовавшую концепцию системы на кристалле (system-on-a-chip) с многоядерной архитектурой IBM® POWER® и межсоединениями с топологией трехмерного тора. В сегодняшнем списке TOP500 много суперкомпьютеров Blue Gene, которые часто занимают первые места по данным теста LINPACK.
  • Начиная с 1994 года в секторе высокопроизводительных вычислений остается несколько специализированных MPP-архитектур и ряд основанных преимущественно на серийных компонентах кластерных архитектур, использующих как специализированные межсоединения (например, Blue Gene и Cray), так и конвергентные Ethernet-каналы (10G, 40G) и InfiniBand:
    • В TOP500 стали преобладать кластеры, составляющие на сегодня большинство (две трети) самых эффективных решений для высокопроизводительных вычислений.
    • Диаграмма архитектур, входивших в TOP500 с 1994 года, показывает, что на сегодняшний день преобладают кластеры и MPP-архитектуры (в сравнении с векторными SIMD-системами, быстрыми однопроцессорными системами, симметричными многопроцессорными системами (SMP) с общей памятью, а также другими менее распространенными архитектурами).
    • Джон Гейдж (John Gage) из компании Sun Microsystems (в настоящее время Oracle) заявил, что "компьютер – это сеть", подразумевая распределенные системы и Интернет, но сети с малыми задержками в кластерах также становятся важнейшей основой масштабирования.
    • Для ускорения обработки специальных рабочих нагрузок на каждом узле кластера используются сопроцессоры, связанные с узлами кластера посредством отображаемого в память ввода/вывода, в том числе графические GPGPU-сопроцессоры и даже гибридные FPGA-процессоры (FPGA – программируемая пользователем вентильная матрица).
  • Современные вычислительные среды уровня датацентра и облачные среды все больше ориентируются на MapReduce и приложениях с высочайшей для HPC степенью параллелизма:
    • Критерием для попадания в TOP500 являются показатели теста LINPACK и производительность операций с плавающей точкой, а текущие затраты (например, FLOP/Вт) или скорость доступа к данным не учитываются. Доступ к памяти имеет решающее значение, но доступ к хранилищу не столь важен, за исключением контрольных точек задания (чтобы можно было перезапустить задание при необходимости).
    • В новом тысячелетии появилось много управляемых данными приложений, таких как социальные сети, Интернет-поиск, глобальные географические информационные системы и средства аналитики, работающие более чем с миллиардом пользователей Интернета. Это не HPC-вычисления в традиционном смысле, а вычисления уровня датацентра в массовом масштабе.
    • Луис Андре Баррозо (Luiz Andre Barroso) сделал второй шаг от процессорной модели, заявив, что "компьютер – это датацентр". Центр обработки данных основное внимание уделяет текущим и капитальным затратам, а потому лучше подходит для HPC-вычислений, где важны показатели FLOP/Вт и доступ к данным. Датацентры Google имеют PUE (отношение общей потребляемой мощности оборудования к мощности, используемой для вычислений) менее 1.2. (Большинство предприятий, выполняющих вычисления, до этого имело PUE 2.0 и выше, так что 1.2 – действительно очень низкий показатель. См. раздел Ресурсы.)
    • Компания Amazon запустила среду Amazon Elastic Compute Cloud (Amazon EC2), которая лучше всего подходит для Web-сервисов, но имеет некоторые возможности масштабируемых или как минимум высокопроизводительных вычислений (см. раздел Ресурсы).
  • Все большее распространение получают облачные HPC-сервисы по требованию, в первую очередь с ориентацией на кластеры, память, сопроцессоры и гибкое масштабирование:
    • Многие частные и общедоступные HPC-кластеры, входящие в TOP500, работают на Linux® и используют общие инструментальные средства с открытым исходным кодом, позволяя пользователям создавать и масштабировать приложения на небольшие кластеры и переносить их в облачную среду для обработки большой нагрузки по требованию. Компании, подобные Penguin Computing, предлагающей HPC-сервис Penguin On-Demand, используют готовые кластеры (на основе InfiniBand и конвергентного Ethernet 10G/40G), многоядерные автономные узлы Intel или AMD, графические GPGPU-сопроцессоры и масштабируемые RAID-хранилища.
    • Платформа IBM Platform Computing предоставляет вычислительные ресурсы по требованию на базе серверов IBM xSeries® и zSeries® с инструментами и функциями управления рабочей нагрузкой.
    • Многочисленные университеты и стартапы в дополнение к своим собственным сервисам используют HPC-вычисления по требованию с помощью облачных сервисов или серийных кластеров. Мне, в частности, хорошо известны суперкомпьютерный центр Arctic Region Supercomputing Center (ARSC) Pacman (Penguin Computing) Университета Аляски и кластерный суперкомпьютер JANUS Университета Колорадо. Общий набор инструментов с открытым исходным кодом на базе Red Hat Enterprise Linux (RHEL) и открытая архитектура позволяют переносить приложения с закрытых систем на открытые облачные HPC-системы.

На рисунке 1 показана эволюция систем TOP500 к кластерам и MPP-системам начиная с середины 90-х годов.

Рисунок 1. Эволюция TOP500 к кластерам и MPP-системам начиная с 1994 года
Рисунок 1. Эволюция TOP500 к кластерам и MPP-системам начиная с 1994 года

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


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

Большинство из нас имеет дело со сжатым цифровым видео, зачастую в формате MPEG4, и не задумывается о масштабности задачи даже простого анализа изображений, отснятых Web-камерой высокой четкости (HD), с точки зрения скорости передачи и обработки данных. Специалистам в области цифрового кинематографа и пост-продакшн эти проблемы знакомы очень хорошо. Они работают с отдельными кадрами, имеющими разрешение 4К (примерно 4 мегапиксела) или намного выше. Эти кадры могут быть сжаты, но без применения группового сжатия, как это делается в формате MPEG, и часто с использованием сжатия без потерь.

Чтобы разобраться в примере проблемы HPC, включающей в себя операции с плавающей запятой, несжатые данные и инструменты, которые можно использовать для масштабирования, рассмотрим простое преобразование для выделения границ в изображении. В файле transform-example.zip содержатся алгоритмы Open Computer Vision (OpenCV) для применения преобразований Собеля или Кэнни к видеопотоку Web-камеры в режиме реального времени с целью выделения границ в изображении (cм. рисунок 2).

Рисунок 2. Преобразование HD-видео с помощью фильтра Кэнни
Рисунок 2. Преобразование HD-видео с помощью фильтра Кэнни

Использование облачных HPC-вычислений для анализа видео позволяет разворачивать на смартфонах более интеллектуальные приложения. Возможно, процессоры телефонов когда-нибудь смогут в режиме реального времени распознавать лица на цифровом HD-видео, но сегодня в этом могут помочь облачные HPC-вычисления. Аналогичным образом для данных в датацентрах, таких как данные географических информационных систем, требуется интенсивная обработка, чтобы сегментировать сцены, создавать облака точек 3D-данных стереосъемки и распознавать интересующие объекты (например, достопримечательности).

Дополненная реальность и анализ видео

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

Иногда при получении цифрового видео в режиме реального времени данные необходимо передавать вычислительным ресурсам, но по возможности к перемещению цифрового видео следует прибегать только при необходимости, чтобы избежать кодирования при сжатии и декодирования при распаковке для просмотра. Существуют специализированные сопроцессоры(кодеки), выполняющие декодирование без использования программного обеспечения, и сопроцессоры для рендеринга графики (GPU), но до настоящего времени сопроцессоры для компьютерного зрения не являются общедоступными. Консорциум Khronos объявил инициативу по созданию спецификации аппаратного ускорения для OpenCV до конца 2012 года, но эта работа только началась (см. раздел Ресурсы). На сегодня компьютерное зрение в основном остается HPC-приложением, пользующимся вниманием главным образом цифрового кинематографа, но ситуация быстро меняется в связи с ростом интереса к использованию компьютерного зрения в мобильных телефонах и в облачных средах.

Хотя все мы понимаем, что компьютерное зрение может быть реализовано в мобильных роботах, в системах отображения на лобовом стекле для интеллектуальных транспортных средств и в ПО поиска по изображению (например, в Google Goggles) для личного пользования, все еще не ясно, должна ли выполняться обработка во встроенных устройствах, даже если это технически возможно. Причина в данных: без доступа к связанным данным датацентра информация компьютерного зрения значительно менее полезна. Например, зачем знать, где находишься, если нет дополнительных картографических и ГИС-данных, чтобы двигаться дальше? Компьютерное зрение и анализ видео в режиме реального времени делают успехи, но сталкиваются со многими проблемами, включая потребность в огромных емкостях хранения и в высокоскоростной передаче данных, а также серьезные требования к обработке для интерпретации данных. Независимо от того, кем осуществляется обработка - облачными HPC-кластерами или встроенными системами, - очевидно, что параллелизм и параллельная обработка будут играть огромную роль. Попробуйте выполнить простое линейное преобразование Хафа для фотографии кактуса с разрешением 12 мегапикселов, - и вы поймете, почему HPC-вычисления могут потребоваться даже для простого сегментирования видеоизображения со скоростью 60 кадров в секунду.


Задача распараллеливания алгоритмов

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

Мощь MapReduce

Концепция MapReduce в первую очередь ассоциируется с Google и проектом с открытым исходным кодом Hadoop (от Apache Software Foundation), но эта концепция полезна для увеличения скорости любых параллельных вычислительных приложений, будь то на уровне узла или кластера с использованием технологии Java™ или на уровне потоков в архитектурах с общей памятью с неоднородным доступом (NUMA). В приложениях цифрового анализа видео отображение требует обработки большого объема данных, поэтому имеет смысл переместить эту функцию ближе к данным (на этап отображения), но в любом случае данные, подлежащие обработке, должны быть отображены и обработаны, а результаты объединены. Продуманное отображение позволяет максимально избежать зависимости данных и необходимости синхронизации. При обработке изображений в системах компьютерного зрения отображение может выполняться в пределах кадра, на уровне кадра или на уровне групп изображений (см. раздел Ресурсы).

В число ключевых инструментов разработки масштабируемых кластерных приложений кластера для облачных HPC-вычислений по требованию входят:

  • Поточная обработка - одно приложение (или процесс Linux) использует одно адресное пространство на одном узле кластера и может быть спроектировано с расчетом на использование всех ядер процессора на этом узле. Обычно это делается с помощью набора интерфейсов поточной обработки POSIX Pthreads или такой библиотеки, как OpenMP, которая позволяет абстрагироваться от низкоуровневых деталей поточной обработки POSIX. Поточная обработка POSIX довольно проста, а пример типичного Pthread-кода содержится в файле hpc_cloud_grid.tar.gz. Этот пример отображает потоки на числовое пространство для поиска простых чисел.
  • MPI – библиотека, которую можно скомпоновать в параллельное кластерное приложение, выполняющее отображение обработки на каждый узел, синхронизацию и преобразование результатов. Хотя MPI можно использовать для реализации MapReduce, она, в отличие от Hadoop, обычно перемещает данные (в сообщениях) к программным функциям, выполняющимся на каждом узле, а не наоборот (код к данным). В завершающей статье этой серии, посвященной анализу видео, будут представлены поток и масштабируемая на кластер MPI-версия кода захвата и преобразования изображения. Здесь же в качестве примера приводится простой код для одного потока и узла. Выполните его одновременно с Linux-утилитой dstat, чтобы проследить использование процессора, устройств ввода/вывода и памяти. Это ресурсоемкая программа, которая применяет фильтры Собеля и Кэнни к изображению с разрешением 2560x1920 пикселов. Она должна работать на любой Linux-системе при наличии OpenCV и Web-камеры.
  • Векторную SIMD- и SPMD-обработку можно выполнять на узлах Intel и AMD, указав соответствующий ключ во время компиляции или, что требует больших усилий, путем создания с помощью CUDA или OpenCL ядер преобразования для переноса вычислений на графический процессор или сопроцессор GP-GPU.
  • Инфраструктура OpenCV весьма полезна для анализа видео, так как предоставляет не только удобные функции захвата, обработки и отображения изображений, но и большинство лучших алгоритмов преобразования, применяемых в системах компьютерного зрения.

Будущее облачных HPC-вычислений по требованию

В данной статье приводятся доводы в пользу облачных HPC-вычислений. Цель состоит в том, чтобы познакомить вас с идеей и некоторыми непростыми, но привлекательными применениями этой технологии (например, компьютерным зрением), а также с методами программирования приложений, которые могут масштабироваться на кластеры и MPP-машины. В следующих статьях я продолжу рассматривать пример приложения для компьютерного зрения и адаптирую его не только для поточной обработки, но и для интерфейсов передачи сообщений (MPI), чтобы проверить, насколько хорошо он масштабируется на облачные HPC-вычисления (в нашем случае на ARSC Pacman или JANUS). Для сравнения я рассматриваю тесно связанные сопроцессоры компьютерного зрения, которые я создаю с использованием Altera FPGA Stratix IV и называю процессорами обработки компьютерного зрения (computer vision processing unit – CVPU). Сравнение поможет выяснить, чего можно достичь с помощью суперкомпьютерного центра ARSC, и понять, как лучше обрабатывать данные зондирования окружающей среды и данные ГИС: как графику (с использованием сопроцессоров), на кластере или, возможно, комбинируя оба способа. Этим цели моего исследования не ограничиваются. В случае CVPU, с моей точки зрения, "тестом Тьюринга" для системы компьютерного зрения и графики мог бы быть вариант, в котором сцена, проанализированная процессором компьютерного зрения, отправляется на графический процессор для рендеринга. В идеале проанализированное и затем визуализированное изображение не должно отличаться от исходного цифрового видеопотока. Когда визуализированные сцены и способность анализировать их достигнут приемлемой точности, дополненная реальность, перцептивные вычисления и анализ видео приобретут удивительную силу, способную изменить нашу жизнь.


Загрузка

ОписаниеИмяРазмер
Образец кодаtransform-example.zip123КБ
Образец кодаhpc_cloud_grid.tar.gz3КБ
ДемоCactus-12mpixel.zip12288КБ

Ресурсы

Научиться

Получить продукты и технологии

  • Оцените продукты IBM наиболее подходящим способом: загрузите ознакомительную версию, попробуйте продукт в Интернете, используйте продукт в облачной среде или проведите несколько часов в SOA Sandbox, изучая эффективную реализацию сервис-ориентированной архитектуры.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=950114
ArticleTitle=Облачное масштабирование: Часть 1. Создание приложения уровня вычислительного узла или небольшого кластера и его масштабирование при помощи технологий HPC
publish-date=10252013