Открытые системы :: Современные архитектуры

Кластерная система Condor

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

Дмитрий Владимиров

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

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

Другой пример успешного применения сообщества временно простаивающих компьютеров продемонстрировал национальный вычислительный альянс, объединяющий партнеров университета шт. Айова и Арагонской Национальной лаборатории. В рамках структуры PACI (Advanced Computational Infrastructure) удалось решить проблему «nug30» из группы задач QAP (quadratic assignment problem) типа известной проблемы коммивояжера, возникшей еще в 1968 году при решении задачи тестирования в прикладной теории размещений. Имеется множество точек куда должно быть доставлено какое-либо воздействие и требуется определить стоимость передачи этих воздействий для каждой пары точек. Поток воздействий между каждой парой умножается на расстояние между точками и так для всех пар. В задаче «nug30» имеется 30 воздействий, каждое из которых должно быть доставлено в 30 фиксированных точек. Требуется минимизировать стоимость передачи воздействий между точками, иначе говоря, найти оптимальный маршрут. Задача имеет массу практических применений от планирования сети госпиталей или заводов до проектирования микропроцессоров. Однако несмотря на простоту постановки ее оптимальное решение весьма нетривиально.

В рамках проекта PACI над решением задачи «nug30» работало в среднем 650 процессоров (в пиковые периоды их число составляло 1009), установленных на компьютерах пяти различных платформ, физически расположенных в восьми разных местах по всему миру (несколько штатов США плюс компьютерный центр в Италии). Счет шел в течение семи дней, что составило 96 тыс. часов процессорного времени. Без использования метакомпьютера процесс решения затянулся бы на многие годы. Инструментальным средством, позволившим выполнить такой огромный объем работ был тандем из системы Condor и Globus [1].

Основные возможности Condor

Кластерная система Condor (www.cs.wisc.edu/condor/downloads) была создана группой разработчиков Университета Wisconsin-Madison где и была более 10 лет назад развернута первая конфигурация. На сегодняшний день в университете имеется 350 настольных UNIX станций, которые включены в сеть Condor и предоставляют доступ для работы пользователям со всего мира. Система свободно распространяется в загрузочных модулях для следующих платформ:

HP PA-RISC (PA7000 и PA8000) HPUX 10.20;
Sun SPARC Sun4m,c, Sun UltraSPARC Solaris 2.5.x, 2.6, Solaris 2.7 («с ограничениями»);
Silicon Graphics MIPS (R4400, R4600, R8000, R10000) IRIX 6.2, 6.3, 6.4, 6.5;
Intel x86, Pentium Linux 2.0.x, 2.2.x, glibc20, glibc21, libc5, Solaris 2.5.x, 2.6, Windows NT 4.0 («с ограничениями»);
Digital ALPHA OSF/1 (Digital Unix) 4.x, Linux 2.0.x, Linux 2.2.x («с ограничениями»).

Для некоторых платформ Condor имеет ограничения - не поддерживает контрольные точки (checkpoint) и удаленные системные вызовы (работа только в режиме «Vanilla»).

Во многих случаях, особенно если речь идет о расчетных задачах, пользователям намного важнее не быстрота выполнения одного задания, а число заданий, которые можно выполнить за достаточно продолжительное время. Иначе говоря, число операций в месяц или год. Такой постулат лежит в основе технологии эффективного использования имеющихся компьютерных ресурсов - High Throughput Computing (HTC). Система Condor - это ПО для поддержки среды HTC, образованной станциями на платформе UNIX и NT. Несмотря на то, что Condor может управлять специализированными кластерами из рабочих станций, его ключевое преимущество - способность распределять обычные компьютерные ресурсы, доступные в любой лаборатории или офисе. Иногда еще Condor называют «охотник за свободными станциями» - вместо того чтобы запускать задания на своей машине, пользователь обращается к системе, которая ищет временно свободные машины в сети и запускает на них задания. Когда машина перестанет быть свободной (вернувшийся с обеда пользователь нажал клавишу или кнопку мыши, либо машина получила команду выгрузки ОС), Condor прерывает выполнение заданий, осуществляет миграцию на другую свободную машину и перезапускает задание на ней с прерванного места. Если нет свободных машин, то задание помещается в очередь и ждет свободных ресурсов. Предусмотренный в Condor механизм управления заданиями, предполагает ведение очередей, составление расписаний, схему приоритетов и классификацию ресурсов позволяет пользователю быть в курсе дел о состоянии своих заданий, не заботясь об их дальнейшей судьбе.

Предложенная в Condor дисциплина работы ориентирована на выполнение продолжительных заданий, время счета которых исчисляется часами. Например, если необходимо 5 часов счета, то задание может начать работу на машине «A» и после 3 часов мигрировать на машину «B» где, через два часа задание завершится, о чем пользователь будет оповещен. Возможно и более глубокое деление общего времени выполнения, например на 250 различных квантов. При этом Condor не требует включения машин в состав сетевых файловых систем, таких как NFS или AFS, а все станции могут размещаться на разных доменах. Кроме обычного режима обработки контрольных точек с запоминанием состояния Condor может периодически сохранять текущее состояние, что особенно полезно для обеспечения надежности работы в случае сбоя компьютеров из пула или страховки от более прозаических вещей типа непроизвольного выключения станции без операции «shutdown».

Кроме выполнения миграции на свободные машины Condor обеспечивает управление распределенными ресурсами. В отличие от других систем СУПО, в которых администратору или пользователю требуется вручную редактировать реквизиты задания в очереди, чтобы удовлетворить требованиям выполняющего компьютера и протолкнуть задание на счет, Condor полностью автоматизирует процесс распределения заданий, используя для этого объектную технологию ClassAds. Данная технология работает подобно газетному рекламному классификатору. Все машины, доступные пулу Condor объявляют (рекламируют) свои возможности в рубрике «Предложение»: объем памяти на диске, тип и быстродействие процессора, объем виртуальной памяти, средняя загрузка и т.п. С другой стороны, пользователь описывает потребности своего задания в рубрике «Запрос ресурсов». Condor работает в роли брокера, удовлетворяющего заявки из рубрики «Запрос ресурсов» ресурсами, представленными в рубрике «Предложение». Одновременно система обеспечивает ведение дисциплины нескольких уровней приоритетов рассмотрения заявок: приоритет назначения ресурсов, приоритет использования и приоритет среди машин, удовлетворяющих одинаковым заявкам.

При работе Condor от пользователя не требуется специальной регистрации (account или login) на машинах где будет выполняться его задание - система сама выполняет регистрацию с помощью технологии удаленного вызова RSC (Remote System Call), позволяющей перехватывать вызовы ОС при выполнении операций чтения/записи файлов и пересылать их на машину откуда было запущено задание. Таким образом, пользователь может не волноваться о доступности файлов на удаленной машине или получении для себя account. Система не требует использовать какой-либо специальный ПО и способна выполнять обычные UNIX и NT программы, а пользователю нужно только пересобрать свою задачу с библиотеками Condor. Права хозяев рабочих станций, включенных в пул Condor ни в коей мере не ущемляются - они могут использовать свои машины без каких-либо ограничений и при этом с их стороны не требуется специальных усилий по дополнительному администрированию.

Архитектура Condor

Аппаратная структура

Аппаратная архитектура системы включает три типа компьютеров (рис. 1), объединенных в единый пул Condor: центральный менеджер (Central Manager), выполняющие машины (Execute Machine), запускающие машины (Submit Machine).

Рис. 1. Архитектура Condor

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

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

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

Кроме этих машин в пуле может быть «Сервер контрольных точек» (Checkpoint Server), на котором хранятся все рабочие файлы для обработки контрольных точек прерванных заданий.

Программная архитектура

Condor_master. Демон, контролирующий работу всех демонов Condor, запущенных на каждой машине пула и выполняющий административные команды системы. Данный демон должен быть запушен на каждой машине из пула.

16.07.2000г

30/05/2007 №04
Миражи интеграции Герман Хохлов ИТ-рынок наконец-то осознал необходимость интеграции приложений — интеграционные платформы сегодня на пике популярности, а еще пару лет назад приходилось убеждать, что интегрировать лучше «на шине», чем с помощью прямых интерфейсов. Однако сегодня ожидания от внедрения интеграционных платформ часто значительно превосходят их реальные возможности. Мало того, встречаются даже случаи, когда шины рассматриваются как волшебные палочки, решающие все проблемы автоматизации и бизнеса. Интеграция приложений и интеграционные платформы постепенно становятся существенной статьей ИТ-бюджета.
Виртуализация: за и против Александр Замятин Сегодня технологии виртуализации вызывают большой интерес со стороны всех участников ИТ-рынка — все больше заказчиков видят в ИТ реальный инструмент бизнеса и все меньше внимания потребители информационных услуг уделяют оборудованию и программным средствам, на которых будет выполняться интересующая их задача. ИТ-инфраструктура все чаще оценивается как единое информационное поле, позволяющее получать, структурировать, обрабатывать и хранить необходимую компании информацию. Концепции виртуализации, начавшие развиваться около 40 лет назад, стали ответом на эти требования, однако виртуализация таит в себе не только преимущества.
Scrum: гибкое управление разработкой Михаил Борисов В большинстве случаев программирование — сложный, слабо определенный процесс, требующий от разработчиков творческого подхода. Различные agile-технологии позволяют организовать процесс постепенного приближения к цели проекта путем проведения циклов испытаний с корректировкой последующих, основанных на анализе результатов предыдущих. Scrum — одна из первых методологий циклического наращивания функциональности и корректировки хода проекта на основе анализа обратной связи от пользователей. Методология Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения. Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта.
Метрики управления качеством защиты приложений Гуннар Петерсон, Элизабет Николс Функциональность Web-приложений и их пользовательская база развиваются одновременно с ростом угроз, и хотя специальное оборудование (например, сетевые экраны) играет важную роль в деле защиты приложений, для обеспечения их полной безопасности одного оборудования недостаточно. Все эти устройства обеспечивают защиту хостов и средств связи, но почти бессильны перед атаками на сами программные модули или дизайн (интерфейсные экраны) приложения, поэтому предприятия должны сосредоточиться на усилении защиты Web-приложений. Однако здесь сразу появляется ряд вопросов. Какие проблемы могут возникнуть у моих программ? Насколько установленные приложения уязвимы перед лицом наиболее общих угроз? Какие изменения в цикле разработки программного обеспечения могут повлиять на защиту этих уязвимых мест?
Комбайн автоматизации Александр Александров Корпоративные платформы управления бизнес-процессами претендуют на то, чтобы, отделив логику выполнения процессов от их программной реализации, включить в единый цикл взаимодействие людей, потоки документов, распределенные информационные системы и базы данных. Когда появился такой «комбайн» с возможностью объединения анализа и моделирования процессов, управления действиями людей и работой информационных систем при обеспечении мониторинга и оптимизации производительности на протяжении жизненного цикла процессов, потребовалось переосмысление организации системы управления бизнес-процессами.
BPM со всех сторон Наталья Дубова Ежегодная конференция «Управление бизнес-процессами на предприятии: интеграция в корпоративные системы» вновь собрала полную аудиторию. С чем связан повышенный интерес к BPM и какие решения в данной области предлагаются сегодня отечественному бизнесу? Дисциплина управления бизнес-процессами сложилась в последнее десятилетие в ответ на неэффективную организацию бизнеса по функциональным подразделениям и избыточную сложность предлагаемых подходов к реинжинирингу бизнес-процессов, обычно предписывающих полную и одномоментную перестройку процессов из состояния «как есть» в состояние «как должно быть».
Транзакционная память — первые шаги Леонид Черняк Память современных компьютеров в принципе отличается от легендарных ферритовых колечек только своей емкостью и быстродействием: она последовательна по своей природе. С появлением многоядерных процессоров возникает необходимость в альтернативных решениях. Возможно, таким решением станет транзакционная память.