Journal influence
Bookmark
Next issue
Experience in cluster software development in the faculty of mechanics and mathematics of msu
The article was published in issue no. № 1, 2010Abstract:In this article I describe an approach and experience of the faculty of mechanics and mathematics of MSU in developing and testing system software for clusters without shared memory. The focus of this paper is the solution using virtualization and virtualization overview.
Аннотация:В статье рассматривается опыт разработки и тестирования программного обеспечения для кластеров без общей памяти на механико-математическом факультете МГУ. Описываются общие проблемы, связанные с этой задачей, и методы их решения при помощи виртуализации, а также делается обзор современных средств виртуализации.
Author: (oshemkov@gmail.com) - | |
Keywords: system software, network programming, virtualization, cluster without shared memory |
|
Page views: 12703 |
Print version Full issue in PDF (4.03Mb) Download the cover in PDF (1.25Мб) |
На механико-математическом факультете МГУ им. М.В. Ломоносова большое внимание уделяется параллельному программированию для всевозможных видов систем: все студенты обучаются написанию многопроцессных и многопоточных (multithread) программ и MPI-приложений для кластеров с общей памятью. Кроме того, на кафедре вычислительной математики в рамках научной деятельности разрабатываются параллельное системное программное обеспечение для организации очереди заданий на кластерах с общей памятью и распределенных кластерах без общей памяти, системы мониторинга, программное обеспечение для управления кластерными системами и обеспечения их безопасности. Задача тестирования программного обеспечения для кластеров без общей памяти возникает всегда при разработке прикладных систем для параллельных вычислений или непосредственно самих вычислительных задач. Под кластером без общей памяти будем понимать группу компьютеров, объединенных в локальной или глобальной сети и представляющих, с точки зрения пользователя, единый аппаратный ресурс (рис. 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 удалось построить очень простое решение из пяти виртуальных машин, работающих на одном ноутбуке (Pen- tium M, 1Gb RAM), причем с возможностью выполнения на нем других задач. Этого было достаточно для основного этапа разработки сетевых модулей и мониторинга. Подготовка проекта к промышленной эксплуатации потребовала дополнительного этапа тестирования и настройки. В случае, когда вычислительная сеть устанавливается не с нуля, важной задачей является обеспечение совместимости существующего программного обеспечения кластера с новым. Для моделирования процесса внедрения было решено использовать более мощный тестовый комплекс, на который можно было бы переносить все серверы вычислительной сети без потери их работоспособности и смоделировать достаточное количество вычислительных узлов, чтобы протестировать работу в условиях большого числа сетевых соединений и нагрузки от реальных вычислительных задач, то есть в условиях, максимально приближенных к реальным. Для того чтобы при тестах вычислительные узлы не нарушали работу серверов кластера (ведь в реальных условиях они не могут это делать), нужна была возможность балансировки нагрузки и гарантирования ресурсов процессорного времени и памяти. Такая возможность есть в VMware ESXi, на основе которой был развернут новый тестовый комплекс (рис. 2), фактически ничем уже не отличающийся от реального кластера (кофигурация: 2 x CPU Intel Xeon, 8 Gb RAM, без затрат на программное обеспечение). Благодаря родственности продуктов VMware ESXi и VMware Server, инфраструктура старого тестового комплекса была автоматически перемещена на новый стандартными средствами VMware – при помощи бесплатного VMware vCenter Converter Standalone. В дальнейшем наличие тестового комплекса, в точности повторяющего физический кластер, позволит безболезненно дорабатывать программное обеспечение, не вмешиваясь в работу стабильной версии и не боясь отказа новых версий после внедрения из-за конфликтов программного обеспечения. Главное – не забывать синхронизировать программное обеспечение виртуального кластера при обновлениях на физическом. В заключение перечислим несколько полезных функций, которые выгодно отличают виртуальный тестовый комплекс для разработки и отладки сетевого программного обеспечения даже при наличии доступного реального кластера: · при помощи виртуализации можно смоделировать сколь угодно сложную сетевую архитектуру, используя виртуальные сетевые интерфейсы и 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). |
Permanent link: http://swsys.ru/index.php?page=article&id=2423&lang=en |
Print version Full issue in PDF (4.03Mb) Download the cover in PDF (1.25Мб) |
The article was published in issue no. № 1, 2010 |
Perhaps, you might be interested in the following articles of similar topics:
- Метод планирования размещения группы виртуальных машин с перераспределением ресурсов
- Эволюция и особенности гиперконвергентных инфраструктур
- Модель надежности отказоустойчивого кластера с миграцией виртуальных машин
- Использование технологий виртуализации вычислительных и графических серверов при проектировании тренажеров, тренажерно-моделирующих комплексов и систем обучения операторов
- Экспериментальная среда облачных вычислений в институте математики и механики УрО РАН
Back to the list of articles