Научная статья на тему 'Опыт разработки программ для кластеров на механико-математическом факультете МГУ'

Опыт разработки программ для кластеров на механико-математическом факультете МГУ Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
68
46
i Надоели баннеры? Вы всегда можете отключить рекламу.
i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Опыт разработки программ для кластеров на механико-математическом факультете МГУ»

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

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

Литература

1. Современные проблемы хаоса и нелинейности / К. Симо [и др.]. Ижевск: Ин-т компьютер. исследований, 2002.

2. Жаботинский А.М., Отмер Х., Филд Р. Колебания и бегущие волны в химических системах. М.: Мир, 1988.

3. Самарский А.А., Гулин А.В. Теория разностных схем. М.: Наука, 1989.

ОПЫТ РАЗРАБОТКИ ПРОГРАММ ДЛЯ КЛАСТЕРОВ НА МЕХАНИКО-МАТЕМАТИЧЕСКОМ ФАКУЛЬТЕТЕ МГУ

А.А. Ошемков

(Московский государственный университет им. М.В. Ломоносова, oshemkov@gmail.com)

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

На механико-математическом факультете МГУ им. М.В. Ломоносова большое внимание уделяется параллельному программированию для всевозможных видов систем: все студенты обучаются написанию многопроцессных и многопоточных (multithread) программ и МР!-приложений для кластеров с общей памятью. Кроме того, на кафедре вычислительной математики в рамках научной деятельности разрабатываются параллельное системное программное обеспечение для организации очереди заданий на кластерах с общей памятью и распределенных кластерах без общей памяти, системы мониторинга, программное обеспечение для управления кластерными системами и обеспечения их безопасности.

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

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

R т-тимг1 11 и-1 f TTT.xiijig УЗЛЫ

Pur 1

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

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

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

В последнее время появилось достаточно много продуктов для виртуализации; рассмотрим три основных принципиально разных гипервизора -VMware, Microsoft Hyper-Vи Xen [1, 2].

У каждого из этих пакетов, помимо коммерческих реализаций, есть бесплатные версии: VMware Server - отдельная программа под Linux и Windows; VMware ESXi - самостоятельная мини-ОС; Microsoft Virtual PC - отдельная программа под Mac OS, OS/2, Linux и Windows; Microsoft Hyper-V Server Core - самостоятельная урезанная ОС на основе Windows 2008 Server; гипервизор Xen был изначально бесплатным, и продолжает поддерживаться его свободно распространяемая версия с открытым исходным кодом.

Гипервизор Xen работает в так называемом паравиртуальном режиме, когда гостевая ОС должна быть адаптирована для Xen [3]. Это накладывает определенные ограничения на список ОС, которые можно запустить под управлением Xen, в частности, нельзя было адаптировать ОС с закрытым исходным кодом, такие как Windows, но в 2005 году Intel и AMD реализовали в своих новых процессорах технологии Intel VT и AMD SVM соответственно, и, начиная с версии 3.0, Xen под-

держивает аппаратную виртуализацию, что позволяет запускать большинство ОС в качестве гостевых. После этого на основе бесплатного Xen появилось множество коммерческих гипервизоров от лидеров рынка программного обеспечения, таких как Citrix, Oracle, Sun и некоторых других.

Гипервизоры Hyper-V и Virtual PC от корпорации Microsoft используют полную виртуализацию, то есть не требуют модифицированных версий ОС, но при этом набор официально поддерживаемых ОС сильно ограничен в текущей версии. В Hyper-V из полноценной поддержки Linux заявлено только SUSE Enterprise Linux Server 10. В отличие от Xen, который устанавливается как Linux-приложение, Hyper-V Server Core является отдельной ОС, поэтому установить ее на тестовый сервер, параллельно используемый для других целей, невозможно. Более того, несмотря на бесплатность самой Hyper-V Server Core, управление сервером подразумевается только удаленно при помощи полноценного Windows Server 2008 либо утилиты Hyper-V Manager, которая работает лишь под управлением Windows Vista, то есть без платных продуктов от Microsoft все равно не обойтись; их стоит использовать для тестовых комплексов, где в качестве гостевой ОС планируется одна из семейства Windows.

Наиболее гибкими и полнофункциональными для тестовых целей являются решения от VMware [4]. Поддержка полной виртуализации и максимального набора гостевых ОС позволяет создать виртуальный кластер практически любой конфигурации. Недавнее появление двух абсолютно бесплатных продуктов VMware Server и ESXi сделало виртуализацию от VMware максимально доступной для тестовых целей. Все платные решения VMware направлены в основном на обеспечение отказоустойчивой работы и возможности масштабирования инфраструктуры сетей крупных компаний. При разработке кластерного программного обеспечения такие задачи не возникают.

Этапы разработки и внедрения кластерного ПО более подробно рассмотрим на примере.

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

ходим. В некоторых случаях можно обойтись несколькими рабочими станциями, подключенными к сети так, чтобы процесс отладки не мешал основному функционированию этих компьютеров. Но достаточно сложная структура рабочего кластера не позволила бы сделать тестовый комплекс, обладающий всеми особенностями реального, без монопольного использования нескольких физических компьютеров в одном месте, настроенных специально для разработки проекта. Благодаря виртуализации на VMware Server удалось построить очень простое решение из пяти виртуальных машин, работающих на одном ноутбуке (Pentium M, 1Gb RAM), причем с возможностью выполнения на нем других задач. Этого было достаточно для основного этапа разработки сетевых модулей и мониторинга.

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

Для моделирования процесса внедрения было решено использовать более мощный тестовый комплекс, на который можно было бы переносить все серверы вычислительной сети без потери их работоспособности и смоделировать достаточное количество вычислительных узлов, чтобы протестировать работу в условиях большого числа сетевых соединений и нагрузки от реальных вычислительных задач, то есть в условиях, максимально приближенных к реальным. Для того чтобы при тестах вычислительные узлы не нарушали работу серверов кластера (ведь в реальных условиях они не могут это делать), нужна была возможность балансировки нагрузки и гарантирования ресурсов процессорного времени и памяти. Такая возможность есть в VMware ESXi, на основе которой был развернут новый тестовый комплекс (рис. 2), фактически ничем уже не отличающийся от реального кластера (кофигурация: 2 x CPU Intel Xeon, 8 Gb RAM, без затрат на программное обеспечение). Благодаря родственности продуктов VMware ESXi и VMware Server, инфраструктура старого тестового комплекса была автоматически перемещена на новый стандартными средствами VMware - при помощи бесплатного VMware vCenter Converter Standalone.

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

Рис. 2

программное обеспечение виртуального кластера при обновлениях на физическом.

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

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

• постоянный доступ к локальной консоли любого узла позволяет экспериментировать с настройками сети, не боясь потерять к нему доступ;

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

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

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

Литература

1. Виртуализация. URL: http://www.vm4.ru/ (дата обращения: 01.07.2009).

2. Статьи о виртуализации. URL: http://www.vmgu.ru/ (дата обращения: 01.07.2009).

3. David Chisnall, The Definitive Guide to the Xen Hypervisor; Prentice Hall Publ., 2008, 320 p.

4. Understanding Full Virtualization, Paravirtualization, and Hardware Assist, 2007. URL: http://www.vmware.com/re-sources/techresources/1008 (дата обращения: 10.07.2009).

i Надоели баннеры? Вы всегда можете отключить рекламу.