Использование кластерной системы ''OpenMosix'' для построения распределённых вычислений

ИСПОЛЬЗОВАНИЕ КЛАСТЕРНОЙ СИСТЕМЫ “OPENMOSIX” ДЛЯ ПОСТРОЕНИЯ РАСПРЕДЕЛЁННЫХ ВЫЧИСЛЕНИЙ

КАЦУБО ДМИТРИЙ ВЛАДИМИРОВИЧ

Минск 2003

2

СОДЕРЖАНИЕ 1. Введение в openMosix.................................................................................................................9 1.1. Что тако е openMosix............................................................................................................9 1.2. Прозрачно с т ь местопол ожения ....................................................................................9 1.3. Файлова я сис т ем а прямого доступ а (DFSA)...........................................................11 1.4. Масштабиру емос т ь ...........................................................................................................12 2. Алгоритмы миграции и ра зд е л е ни я ресур с о в ..............................................................13 2.1. Алгоритм миграции ..........................................................................................................13 2.1.1. Сбор информации о проце с с е ................................................................................17 2.1.2. Ограничения на миграцию......................................................................................17 2.2. Алгоритмы разд е л е ни я ресур с о в ...............................................................................17 2.3. Метод оценив ани я стоимос ти для назн а ч е ни я и перена з н а ч е н и я зад аний . 19 2.3.1. Построени е модели ...................................................................................................19 2.3.2. Основные опред е л е ни я ............................................................................................20 2.3.3. Идентичные и свя з а н ные машины.........................................................................20 2.3.4. Несвя з а н ные Машины.................................................................................................21 2.3.5. Online маршрути з а ци я вирту а л ьных канало в ..................................................22 2.3.6. Методика практич е с к о г о иссл е д о в а ни я .........................................................23 2.3.7. Эксперимент а л ь ные рез ул ь т а ты .........................................................................24 2.3.8. Резул ь т а ты эмуляции Java......................................................................................25 2.3.9. Выполнение на реал ьной сист ем е .......................................................................29 2.3.10. Заключение .................................................................................................................30 2.4. Алгоритм распр е д е л е ни я памяти ...............................................................................31 2.4.1. Чем поле з е н алгори тм распр е д е л е ни я памяти ..............................................31 2.4.2. Эмуляция ал гори тмов распр е д е л е ни я проце с с о в ........................................32 2.4.3. Статич е с к о е и динамиче с ко е размещение процес с о в ...............................33 2.4.4. Адаптивно е размещение проце с с о в ...................................................................34 2.4.5. Масштабиру емый ал гори тм ра змещения с децен тр а л и з и р о в а нным управл ением ..........................................................................................................................35 2.4.6. Реали з а ци я ал гори тма распр е д е л е ни я памяти ............................................36 2.4.7. Активи з а ци я ал гори тма ..........................................................................................37 2.4.8. Выбор процес с а ..........................................................................................................37 2.4.9. Узел назн а ч е ни я ........................................................................................................38 3. Масштабиру емые клас т е рные файловые сис т емы openMosix для Linux..................39 3.1. Задачи клас т е р ных файловых сис т ем ......................................................................39 3.2. Файлова я сис т ем а прямого доступ а (DFSA)...........................................................40 3.2.1. Принцип работы DFSA...............................................................................................40 3.2.2. Требов ания DFSA.......................................................................................................41 3.3. Файлова я сис т ем а openMosix (oMFS)............................................................................42 3.4. Производи т е л ь но с т ь ......................................................................................................43 3.5. Заключение .........................................................................................................................45

3 4. Мигрируемая разд е л я ем а я памят ь ...................................................................................46 4.1. Цели проек т а ......................................................................................................................46 4.2. Sys V раз д е л я ем а я память .............................................................................................46 4.3. Легков е с ные и тяжелов е с ные проце с сы в Linux....................................................47 4.4. Требов ани я к приложению.............................................................................................50 4.5. Исполь з о в а ни е многопот о чных приложений .........................................................55 5. Инсталл я ци я openMosix...........................................................................................................57 5.1. Требов ани я к аппар а т н ой и прогр аммной час ти .................................................57 5.2. Планировк а клас т е р а .....................................................................................................57 5.3. Сборка openMosix................................................................................................................58 5.3.1. Исполь з о в а н и е репо з и т о ри я ................................................................................58 5.3.2. Исполь з о в а н и е ста бил ьно г о патч а ...................................................................59 5.3.3. Исполь з о в а н и е собранных паке т о в ...................................................................59 5.4. Установ к а поль з о в а т е л ь с к и х утилит .....................................................................60 5.5. Файл карты узлов ..............................................................................................................60 5.6. Файл локал ьн о монтиру емых файловых сист ем .....................................................61 6. Настройк а и админис триро в а ни е openMosix..................................................................62 6.1. openMosix API........................................................................................................................62 6.1.1. Proc интерфей с .............................................................................................................62 6.1.2. Интерфейс MFS............................................................................................................64 6.1.3. Функционал ьно с т ь поль з о в а т е л ь с к о й библиот е ки libmosix.....................65 6.2. Оптимиз ация работы openMosix.....................................................................................67 7. Тестиров а ни е клас т е р а .......................................................................................................68 7.1. Функционал ьно е тес т и ро в а ни е ..................................................................................68 7.2. Тестиров а ни е общей произ в оди т е л ь н о с т и ...........................................................70

4

СПИСОК СОКРАЩЕНИЙ 1. SISD (Single Instruction – Single Data) – одиночный поток команд, одиночный поток данных 2. SIMD (Single Instruction – Multiple Data) – одиночный поток команд, множеств е нный поток данных 3. MISD (Multiple Instruction – Single Data) – множест в е нный поток команд, одиночный поток данных 4. MIMD (Multiple Instruction – Multiple Data) – множеств е нный поток множеств е нный поток данных

команд,

5. SMP (Symmetric Multi Processors) – симметричные мультипроц е с с о ры 6. MPP – сис т емы с массовым паралл е ли змом 7. SCC (Scalable Computing Clusters) – масштабиру емые вычислит е л ь ные кла с т е ры 8. SSI (Single System (однообра з н а я)

Image)

–

сис т ем а,

сос т о ящая

из

одного

обра з а

9. COW (Cluster of Workstations) – кла с т е ры из рабочих станций 10. MPI (Message Passing Interface) – интерфейс для перед а чи сообщений 11. PVM (Parallel Virtual Machine) – парал л е л ь н а я вирту ал ь н а я машина 12. openMosix (Open Multicomputer Operating System for UNIX) мультикомпьютерн а я операционна я сис т ем а для UNIX.

–

13. IPC (Inter Process Communication) – межпроце с с но е вз аимод ейс т в и е 14. LWP (Light Weight Process) – лег ко в е с ный проце с с 15. HWP (Heavy Weight Processes) – тяжелов е с ный проце с с 16. PPM (Preemptive Process Migration) – приорит е т н а я миграция процес с о в 17. UHN (Unique Home Node) – уникал ьный домашний узел 18. oMFS (openMosix File System) – файлов а я сист ем а openMosix 19. DFSA (Direct File System Access) – файлова я сис т ем а прямого дост уп а

открыта я

5

ВВЕДЕНИЕ В одной из наибол е е изв е с т ных клас с ифик аций паралл е л ь ных ЭВМ, предложенной Филлином, вводя т с я поняти я “поток команд” и “поток данных”. Согла сно этой кла с с ификации имеет с я четыре больших кла с с а ЭВМ: 1. SISD (Single Instruction – Single Data) – это посл ед о в а т е л ь ные ЭВМ, в которых выполня е т с я единс т в е нн а я прогр амма 2. SIMD (Single Instruction – Multiple Data) – выполняе т с я единс т в е нн а я прогр амма, но каждая команда обраб а тыв а е т массив данных (век торн а я форма паралл е ли зм а) 3. MISD (Multiple Instruction – Single Data) – нескол ь к о рабо т ают с одним элементом данных

команд одновр еменно

4. MIMD (Multiple Instruction – Multiple Data) – одновр ем енно и нез а ви с имо дру г от дру г а выполняе т с я нескол ь к о прогр аммных вет в е й, которые в опред ел ё нные промежутки времени обменив аютс я данными Существующие паралл е л ь ные сред с т в а кла с с а MIMD обра з уют три технич е с ки х подкла с с а : симметричные мультипроц е с с о ры (SMP), сис т емы с массо вым паралл е л и змом (MPP) и клас т е ры. Симметричные мультипроцес с оры исполь з уют принцип разд е л я емой памяти. В этом случа е сис т ем а сос то и т из нескол ь ких однородных проце с с о р о в и массив а общей памяти. Все проце с с о ры имеют дост уп к любой точк е памяти с одинако в ой скоро с т ью. Процес с оры подключены к памяти с помощью общей шины или коммута то р а. Аппаратно поддержива е т с я ког е р е н т н о с т ь кэшей. Наличие общей памяти сильно упрощает взаимод ей с т в и е процес с о р о в между собой, однако накл адыва е т сильное огранич ени е на их число – не боле е 32 в реал ьных сис т ем ах. Системы с массовым параллелизмом содержат множест в о проце с с о р о в (обычно RISC) с индивиду а л ь н ой памятью в каждом из них (прямой дос ту п к памяти дру гих узлов нево зможен), коммуникационный проце с с о р или се т е в о й адап т е р, иногд а – жёсткие диски и/или другие устройс т в а ввод а- вывода. Узлы свя з а ны чере з некоторую коммуникационную среду, например, высоко с к о ро с т н ую сет ь. Общее число проце с с о ро в в реал ьных сис т ем ах дости г а е т нескол ь ких тысяч. Кластерные сист емы – боле е дешёвый вариан т MPP сист ем, поскол ь ку они также исполь з уют принцип перед а чи сообщений, но строя т с я из компоненто в высокой степ ени гото вно с т и. Вычислите л ь ный кла с т е р – это совокупно с т ь компьютеров, объединённых в рамках некоторой се ти для решения одной зад а чи. В каче с т в е вычислит е л ь ных узлов обычно испол ь з уютс я доступные на рынке однопроце с с о рные компьютеры, одно- , двух- или четырёхпроц е с с о р ные SMP-серв е ры. В нас то ящее время малос т о ящие клас т е р ные сис т емы традиционные суперкомпьютеры и мэйнфреймы, потому что

вытесн яют они могу т

6 предо с т а в и т ь хорошие решения для требов а т е л ь ных приложений. Компьютерные клас т е ры особ енно подходя т для маленьких и средних органи з а ций, которые не могу т позволи т ь себ е дорогих сис т ем. Класт е ры выполнены из обычных компонент, и поэтому их пост еп е нный рост легко подс тр а и в а е т с я под бюджет и потребно с т и. Чаще все г о по количе с т в у устано в л е нных сис т ем выделяют три типа кла с т е р о в: клас т е ры с защитой от сбоев, кла с т е ры с балан сиро в кой нагру з к и и высокопрои з в о д и т е л ь ные вычислит е л ь ные кла с т е ры. Кластеры с защитой от сбоев сос т о я т из двух или боле е компьютеро в, соедин ённых се т ью и отдел ьным синхрони з ирующим соединением, которо е испол ь з у е т с я для мониторин г а тог о, что все службы зад ей с т в о в а ны, и в том случа е если одна из служб даё т сбой, другой узе л перенимае т её выполнение. Для класт еров с балансировкой нагрузки концеп ту а л ь ным явля е т с я то, что когд а узел станови т с я дост упным, клас т е р пров ер я е т, какой из узлов явл я е т с я наимене е за г р уженным, и посылае т запро с к этому узлу. Фактич е с ки, большую час т ь времени клас т е р с балан сиро в к ой нагру з к и дейс т в у е т как клас т е р с защитой от сбое в, но с дополнит е л ь н ой балансирующей функционал ьн о с т ью, и, как правило, содержит меньшее число узло в. Последним типом клас т е р о в являются высокопроизводит ельные вычислительные класт еры, сконфигуриров а нные специа л ьно для того, чтобы обесп е чив а т ь центр ам обрабо т к и данных крайне высокую произ в о ди т е л ь но с т ь , которую они требуют. Этот тип кла с т е р о в также облад а е т некоторыми свойс т в ами бал ан сиро в к и нагру з ки, так как клас т е р пытае т с я распр е д е л и т ь проце с сы по узл ам для увелич ени я произ в о ди т е л ь но с т и. И гла вным след с т в и ем из это г о явл я е т с я то, что в случа е когд а проце с с распа р а л л е л и в а е т с я , то подпроце с сы могут быть распр е д е л е ны по раз л ичным узл ам, вмес то того, чтобы выполня т ь с я один за дру гим. Сегодня сущест в уют две основные паради гмы для клас т е р ных Linux окружений: openMosix (клон Mosix) (см. [MOSIX] и [oMosix]) и Beowulf (основ ан на MPI). В то время как парал л е л и з а ц и я в решениях, основ а нных на MPI, требу е т явно го кодиров ани я с исполь з о в а ни ем специал ьных библ иотек или дирек ти в, в openMosix можно придержива т ь с я обычного Unix прогр аммиров ани я, потому что клас т е р н а я функционал ьно с т ь обесп е чив а е т с я прозр ач ным обра з ом ядром операционной сис т емы. Чем более мощным станови т ь с я клас т е р из рабочих ст анций, тем боле е важным явля е т с я мудрое испол ь з о в а н и е его ресур с о в. Плохая стра т е г и я назна ч ения зад аний может вызва т ь сильно неура вно в ешенные нагру з ки и своппинг машин, что наноси т вред вычислит е л ь н ой мощности кла с т е р а . Ресур сы могут исполь з о в а т ь с я боле е эффективно, если кла с т е р может за с т а в и т ь зад ани я мигриров а т ь – перемещать с я проз р а чно от одной машины к дру гой. Однако даже уравнов ешенные сист емы, которые могут перен а з н а ч а т ь

7 зад ани я, всё равно могу т извл е ч ь выгоду от тщател ьно выбранной стра т е г и и назна ч ения. Миграция зад а ний привл е к а т е л ь н а, потому что время посту пл ени я и количе с т в о запро с о в на ресур сы от прибывающих зад а ний непр ед с к а з у емы. Из-за этой непред с к а з у ем о с т и зад а ния иногд а буду т назна ч а т ь с я на неоптимал ьную машину, и перен а з н а ч е ни е даё т сист ем е ещё один шанс исправи т ь такую ошибку. Интуитивно понятно, что способно с т ь мигриров а т ь зад ани я может приве с т и к лучшей эффективно с т и – то ес т ь боле е быстро е время за в е ршения для средне г о зад ани я. Так как не изв е с т н о, гд е должно выполнят ь с я зад ани е в любое зад анно е время, то стра т е г и я перена з н а ч е ни я также может дела т ь ошибки. Например, расширение openMosix для ядра Linux позв ол я е т такой вид прозр а чной миграции зад аний. Таким обра з ом, openMosix включае т в себ я технол о г ии, реали з ующие ал го ри тмы миграции зад аний (см. [BAR1]). Класт е р openMosix, сос т о ящий из компьютеров под управл е ни ем OC Linux, ес т ь то, что называ е т с я одноóбра з н ой сис т емой (SSI). В ра з личных ста т ь я х неоднокр а т н о обсуждало с ь, что нель з я получить нас т о ящий кла с т е р до тех пор, пока вы не построи т е SSI. В SSI клас т е р е поль з о в а т е л ь не забо ти т с я о том, на каком узл е он выполняе т команды, и любая прогр амма, которую он запу с к а е т , буде т запущена на том узл е, который сможет удовл е т в о р и т ь потр ебно с т и прогр аммы наилучшим обра з ом. openMosix – это расширение ядра Linux. Поэтому для того, чтобы проинс т а л л иро в а т ь openMosix, необходимо запу с т и т ь специал ьный инст а л л я ционный скрипт, который применит всё необходимые изменени я к исходным кодам ядра Linux. Такой скрипт в дальнейшем будем называ т ь «патч» (от англ. patch). Изменения кас ают с я 3% все г о исходно г о кода ядра, что не очень много (см. гл. 5.3). Замеча т е л ь н ой особ енно с т ью openMosix явля е т с я то, что поль з о в а т е л ь толь ко запу с к а е т прогр амму, а клас т е р решает, гд е её выполнить (если не огово р е но обра тно е). Разр а б о т ч и ки openMosix называют это свойс т в о «раз в е т в и с ь- и-забу д ь» (fork-and-forget). openMosix вносит новые мерки в масштабиров а ни е кла с т е р ных вычисл ений с испол ь з о в а н и ем Linux. openMosix дел а е т возможным конс тру иро в а ни е высокопрои з в о д и т е л ь ных масштабиру емых клас т е р ных сис т ем из компьютеров широкого исполь з о в а ни я, причём масштабиров ани е не приводит к за т р а т ам прои зв од и т е л ь н о с т и. Главным преимуществ ом openMosix перед дру гими клас т е р ными сист ем ами явля е т с я её возможнос т ь отве ч а т ь во время выполнения на непред с к а з у емые и нест а н д а р т ные запро сы многих поль з о в а т е л е й к ресур с ам. Отличител ь ными свойс т в ами выполнения приложений на openMosix являютс я адап тивн а я политик а распр е д е л е н и я ресурс о в, симметрия и гибко с т ь конфигу р ации. Комбиниров анный эффект этих свойс т в подра з ум е в а е т то, что поль з о в а т е л ь не должен зна т ь текущего сос то яни я испол ь з о в а н и я ресу р с о в на ра з личных узл а х и даже их количе с т в а. Паралл е л ь ные приложения могу т выполня т ь с я , позв ол я я openMosix назна ч а т ь и перена з н а ч а т ь процес сы на

8 наилучшие из возможных узлов, почти так же, как и SMP. Тем не менее, ес т ь обла с т и, в которых openMosix не сможет принес ти хоть какую-то поль з у. Так, например, приложения, исполь з ующие потоки, должны ост а в а т ь с я в преде л а х одног о узл а. Проект openMosix раз ви в а е т с я в нескол ь ки х напра в л ени я х. Уже за конч е ны рабо ты по реали з а ции мигриру емых сок е т о в (migratable sockets), которые должны снизи т ь за т р а ты на межпроце с с но е вз аимод ей с т в и е. Похожей оптимиз аци ей явл я е т с я мигриру емые временные файлы, которые позвол я т удал ённым процес с ам (например, компилятор ам) соз д а в а т ь временные файлы на удал ённых узл ах. Основной концепцией этих оптимиз аций явл я е т с я миграция большего числ а ресур с о в вмес т е с проце с с ом для снижения за т р а т на удал ённый доступ. Также веду т с я разр а б о т к и се т е в ой RAM, с помощью которой проце с с сможет испол ь з о в а т ь памят ь, доступную на нескол ь к их узл ах. Идея сос т ои т в том, чтобы распре д е л и т ь данные процес с а среди неско л ь ких узлов и мигриро в а т ь (обычно маленьки е) проце с сы к данным, нежели перемещать данные к процес с ам. Активно раз ви в а е т с я проек т по реали з а ции мигриру емой разд е л я емой памяти (см. гл. 4). В данной работ е провед ен о иссл ед о в а ни е основных принципов рабо ты openMosix и основ постро е ни я распре д е л ё нных сис т ем с её испол ь з о в а н и ем.

9

1. ВВЕДЕНИЕ В OPENMOSIX 1.1. Что такое openMosix openMosix – это прогр аммное обесп е ч е ни е, которо е было раз р а б о т а н о для то г о, чтобы расширить ядро Linux возможнос т ями клас т е р ных вычисл ений. openMosix расшифровывае т с я как Open Multicomputer Operating System for UNIX. Ядром openMosix являются адап тивные интер а к т и в ные алго ри тмы, балансирующие нагру з к у, управл яющие памятью и файловым вводом- выводом. Они реа ги руют на изменения в исполь з о в а нии ресур с о в клас т е р а, например, неравномерную распр е д е л ё нн ую нагру з к у или чре змерный обмен с диском изза недос т а т к а свободной памяти на одном из узлов (см. [BAR5]). В таких случа я х, openMosix иницииру е т перемещение процес с а от одног о узл а к дру гому, чтобы сбал ан с иро в а т ь нагру з к у, или перемещение процес с а на узел, который имеет дост а т о ч но свободной памяти, или уменьшение числа удал ённых файловых операций ввод а- вывода. openMosix работ а е т нез аме т но – его операции прозр а чны для прикл адных прогр амм. Это означ а е т, что поль з о в а т е л и могу т выполня т ь посл ед о в а т е л ь ные и паралл е л ь ные прикладные прогр аммы точно так же, как на SMP. Пользов а т е л и не должны заб о т и т ь с я о том, гд е процес сы выполняются, ни беспокои т ь с я о том, что делают другие поль з о в а т е л и. Вскоре посл е со зд а ни я нового проце с с а, openMosix пытае т с я назн а ч а т ь его лучшему дост упному узлу на это т момент. openMosix контролиру е т все проце с сы, и, в случа е необходимос ти, мигриру е т процес сы между узл ами, чтобы максимизиров а т ь общую эффекти вно с т ь. Все это дел а е т с я бе з изменения интерфейс а Linux. Это означ а е т, что вы продолжае т е виде т ь (и контролиро в а т ь) все ваши проце с сы, как будто они выполняются на узл е, с которо г о вы вошли сис т ему. Алгоритмы openMosix децент р а л и з о в а ны – каждый узел явля е т с я и хоз яином для процес с о в, которые были созд а ны локал ьн о, и серв е р ом для удал ённых процес с о в, которые мигриров а л и с дру гих узлов. Это озна ч а е т , что узлы могу т быть добавл е ны или удал ены из кла с т е р а в любое время с минимальными беспокой с т в ом выполняющихся проце с с о в. Другое поле зн о е свой с т в о openMosix – его алг ори тмы для мониторин г а, которые опред е л яют быстрод ей с т в и е каждого узл а, его нагру з к у и свободную память, также как и произ в о ди т е л ь но с т ь IPC и сист емы ввод а- вывода для каждого проце с с а. Эта информация испол ь з у е т с я , чтобы принимат ь решения для распре д е л е ни я процес с о в, близки е к оптимал ьным (см. [BAR4]).

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

10 эффективно с т ь и сдел а т ь кла с т е р боле е удобным для испол ь з о в а н и я. Системна я модель обра з а openMosix основ а н а на модели “домашнего узл а” (UHN), в которой кажет с я, что все поль з о в а т е л ь с к и е проце с сы выполняютс я на узл е, с которо г о поль з о в а т е л ь вошёл в сис т ему. Каждый новый проце с с со зд а ё т с я на том же самом узл е, что и его родите л ь с к ий процес с. Процес сы, которые мигриров а л и, взаимод ей с т в уют с поль з о в а т е л ь с к о й средой окружения чере з домашний узе л поль з о в а т е л я, но там, где возможно, испол ь з уют локал ь ные ресур сы. Пока нагру з к а узл а, с котор о г о поль з о в а т е л ь вошёл в сис т ему, ост а ё т с я ниже порого в о г о знач ения, все поль з о в а т е л ь с к и е процес сы огранич ены этим узлом. Однако когд а эта нагру з к а начина е т превышать порогов о г о знач е ния, некоторые процес сы могу т мигриров а т ь к другим узл ам (см. рис. 1). Уз е л #1

Уз е л #2 IPC

A

B

D

C

Произ в ол ь ное пол оже ние – ра с ходы на IPC Уз е л #1

Уз е л #2 IPC

A B

D C

Опт има л ь ное на з на че ние – не т ра с ходов на IPC Рис. 1. Интелл е к т у а л ь н а я бал ансиро в к а нагру з ки Миграция происходи т следующим обра з ом. Процес с ра зби в а е т с я на две час ти: поль з о в а т е л ь с к а я час т ь и сис т емна я час т ь. Пользов а т е л ь с к а я час т ь перено си т с я на удал ённый узел, в то время как сист емна я час т ь должна ост а в а т ь с я на домашнем узл е, уникал ьном для все г о кла с т е р а (UHN). Системную час т ь иногд а называют пред с т а в и т е л ь с к о й (deputy), поскол ь к у она отве ч а е т за ра з р ешение большинств а сист емных вызовов (syscalls). openMosix берё т на себ я зад а ч у обесп е ч е ния взаимодей с т в и я между этими двумя час т ями (см. рис. 2).

11

Re m ot

M os op зь Св я

D ep u

ty

en

ca l Lo

e

Прос т ра нс т в о проце с с а ix

Прос т ра нс т в о проце с с а

Прос т ра нс т в о Прос т ра нс т в о я дра я дра • Пользов а т е л ь с к ий конте к с т (Remote) не за ви с им от узл а – может мигриров а т ь • Системный конте к с т (Deputy) за ви сим от узл а – должен ост а в а т ь с я на домашнем узл е • Связ ь для синхронных (syscalls) и асинхронных (сигна лы, события) вызово в Рис. 2. Разби ение проце с с а и приорит е т н а я миграция Определ ени е оптимал ьно г о местоположения для зад ани я – сложная проблема. Наибольшая сложнос т ь сос т ои т в том, что ресур сы, доступные на рабочих станциях клас т е р а, являютс я ге т е р о г е н ными. В дейс т в и т е л ь н о с т и, за тр а ты на памят ь, CPU, вз аимод ей с т в и е между проце с с ами и т.д. не сравнимы. Они даже не измеримы в одних и тех же единицах: ресур сы вз аимод ей с т в и я измеряютс я в терминах пропускной способно с т и, память – в терминах размерно с т и, а CPU – в терминах циклов. Есте с т в е н н а я “жадная” стра т е г и я, балансирующая ресур сы среди всех машин, также точно не опред е л ен а. В [AMIR1] пред с т а в л е н а новая стра т е г и я назн ач е ни я зад аний, основ анн а я на “экономиче с ких” принципах и конкурен тн ом анали з е. Эта стра т е г и я даё т возможнос т ь управл я т ь ге т е р о г е н ными ресурс ами способ ом, близким к оптимал ьному. Ключева я идея этой стра т е г и и сос т ои т в том, чтобы преобр а з о в а т ь общее испол ь з о в а н и е нескол ь к их ге т е р о г е нных ресу р с о в, таких как память и CPU, в единую гомог енную “стоимос т ь”. Тогд а зад ания назна ч аютс я на ту машину, гд е они имеют самую низкую стоимос т ь.

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

12

•

Файлова я сис т ем а(- ы) смонтиров а н а в той же точке монтиров ания всеми узл ами;

•

Идентифика т о ры поль з о в а т е л е й/ г р упп являютс я идентичными среди всех узло в кла с т е р а .

В нас то ящее время GFS и файлов а я сис т ем а openMosix (oMFS) отв еч ают станд а р т ам DFSA (см. [AMAR1]). Обе файловые сис т емы дел ают все кат ал о г и и обычные файлы доступными для всех узлов по всему клас т е р у openMosix, обесп е чив а я согл а с о в а нн о с т ь во время просмотр а файлов с раз личных узло в, то ес т ь, такую же согл а с о в а нн о с т ь, как если бы вес ь дос туп к файлу был произ в е д ё н с того же самого узл а. В гл. 3.4 привед ено сравн е ни е клас т е р ных файловых сис т ем с традиционными.

1.4. Масштабируемость openMosix может поддержива т ь конфигур ации с большим числом компьютеро в с минимальными накл а дными расход ами на масштабиров а ни е, ухудшающих эффективно с т ь. Low-end конфигур ация может включат ь нескол ь к о PC, которые свя з а ны локал ьной сет ью Ethernet, в то время как большая конфигур ация может включат ь автома ти з и р о в а нные рабочие мест а и серв е р а, которые свя з а ны боле е высокос к оро с т н ой локал ьной се т ью, например, FastEthernet. High-end конфигу р аци я может включат ь большое количе с т в о SMP и не- SMP автома ти з и р о в а нных рабочих мест и серв е р о в, которые свя з а ны высоко эффективной локал ьной вычислит е л ь ной се т ью, например, GigabitEthernet (или Myrinet).

13

2. АЛГОРИТМЫ МИГРАЦИИ И РАЗДЕЛЕНИЯ РЕСУРСОВ 2.1. Алгоритм миграции openMosix – это инструмен т для ядер Linux, включающий в себя адап тивные ал го ри тмы раз д е л е ни я ресур с о в. Он позв ол я е т нескол ь ким одно- и мультипроце с с о р ным узл ам работ а т ь в тесном вз аимод ей с т в ии. Адаптивные ал го ри тмы спроек тиро в а ны так, чтобы отве ч а т ь ежеминутным вариациям при испол ь з о в а н ии ресурс о в всеми узл ами. Это дос ти г а е т с я за счё т миграции процес с о в от одног о узл а к другому, приорит е т н о и проз р а чно, для балансир о в ки нагру з к и и предот в р ащения своппин г а памяти. Их целью явл я е т с я улучшение общекла с т е р н ой произ в оди т е л ь н о с т и и созд а ни е удобной мультипол ь з о в а т е л ь с к о й среды с раз д е л е ни ем времени для выполнения как послед о в а т е л ь ных, так и парал л е л ь ных приложений. Стандар т ным окружением времени выполнения openMosix явля е т с я SCC, в котором общекла с т е р ные ресур сы дос тупны всем узл ам. Отключая автома тич е с к ую миграцию проце с с о в, поль з о в а т е л ь может переключить с я на обычный SCC или однопол ь з о в а т е л ь с к и й режим (см. гл. 5.2). Техноло ги я openMosix сос т ои т из двух час т е й: механизм приорит е т н о й миграции проце с с о в (PPM) и набор механи змов для адап тивно г о раз д е л е ни я ресу р с о в. Обе част и реали з о в а ны на уровн е ядра и поэтому явл яютс я полнос т ью прозр а чными для уровня приложения, что позв ол я е т созд а в а т ь распр е д е л ё нные приложения без необходимос т и исполь з о в а ни я сторонних библио т е к или техноло гий, а также даё т возможнос т ь исполь з о в а т ь ресу р сы кла с т е р а уже напис анными прогр аммами, не спрое к т и ро в а нных специа л ьно для рабо ты на кла с т е р е, бе з их модификации и/или перек омпиляции. PPM может мигриров а т ь любой проце с с в любое время на любой дос ту пный узе л. Обычно миграция ба зиру е т с я на информации, обесп е чив а емой одним из ал го ри тмов ра зд е л е ни я ресур с о в, но поль з о в а т е л ь может переопр е д е л и т ь эту автома тич е с к ую сист емную миграционную политику и мигриров а т ь процес сы самос то я т е л ь н о. Такая ручная миграция может быть иницииров а н а синхронно самим проце с с ом или явным запро с ом от дру го г о проце с с а то го же поль з о в а т е л я или суперпол ь з о в а т е л я. Ручная миграция проце с с о в может быть поле з н а для реали з а ц ии специфичес к ой политики миграции или для тес ти р о в а ни я планировочных ал гори тмов. Также суперпол ь з о в а т е л ь имеет дополнит е л ь ные привил е ги и кас а т е л ь н о PPM, такие как тонка я нас тр ойк а балансир о в ки и нас тройк а подси с т емы огранич ений (loadlimit, miggroup, – см. гл 6.1.1). С каждым проце с с ом ассоцииров ан идентифика т ор уникал ьно г о домашнего узл а (UHN), на котором он был запущен. Обычно, это ест ь узел, с которо г о поль з о в а т е л ь вошёл в сис т ему. Для PVM это ес т ь узел, где была порождена зад а ч а демоном PVM. Стандар тной моделью openMosix явля е т с я однообр а з н а я модель SCC, в которой кажет с я, что каждый проце с с выполняе т с я на сво ём домашнем узл е, и все процес сы одной се с с ии поль з о в а т е л я разд е л яют

14 окружение времени выполнения домашнего узл а. Мигрированный процес с по возможнос ти исполь з у е т ресур сы удал ённо г о узл а, но взаимодей с т в у е т со средой выполнения чере з домашний узел. Так, например, предположим, что поль з о в а т е л ь запу с ти л неско л ь к о процес с о в, и час т ь из них мигриро в а л а. Тогда если поль з о в а т е л ь просмотри т вывод команды ps, то он увидит все процес сы, включая те, которые выполняются удал ённо. При этом суммарное испол ь з о в а н и е проце с с о р а может ока з а т ь с я больше 100%, а исполь з о в а ни е памяти – больше, чем размер физиче с ки устано в л е нной на узе л памяти. Если один из мигриров а вших процес с о в прочит а е т текущее время, то ес т ь, вызов е т gettimeofday(), то он получит знач ени е текущего времени на UHN. PPM – гл а вный инструмен т алгори тмов управл ения ресур с ами. Его гл а вой целью явля е т с я максимизиров а т ь произ в оди т е л ь н о с т ь за счё т эффективно г о испол ь з о в а н и я общесе т е вых ресур с о в. Уровнем дет а л и з а ц ии сет е в о г о распр е д е л е ни я openMosix явля е т с я проце с с. Пользов а т е л ь может выполнят ь паралл е л ь ные приложения, инициируя запу с к нескол ь ких процес с о в на узл е, и за т ем позвол я я сист ем е назна ч а т ь эти процес сы на лучшие дос тупные узлы на данный момент. Если во время выполнения проце с с а станов я т с я дост упными новые ресур сы, то ал гори тмы разд е л е ни я ресу р с о в спрое к т иро в а ны таким обра з ом, чтобы воспол ь з о в а т ь с я этими новыми ресу р с ами за счё т перен а з н а ч е ни я процес с о в между узл ами. Эта возможност ь назна ч ения и перен а з н а ч е ни я зад а ний явля е т с я особ енно важной для прос то ты исполь з о в а н и я и для обесп е ч е ния эффективной мультипол ь з о в а т е л ь с к о й среды выполнения с ра зд е л е ни ем времени. openMosix не имеет центр а л ь но г о места управл ения или отношений управл яющий/подчинённый между узл ами: каждый узел может опериров а т ь как автономна я сист ем а и принимать управл енч е с к и е решения нез а в и с имо. Эта схема дел а е т возможным созд а ни е динамичес к ой конфигур ации, в которой узлы могут присоединя т ь с я и покида т ь сет ь с минимальными сложност ями. Дополнит е л ь но это увеличив а е т масштабиру емос т ь и гар ан ти ру е т , что сис т ем а будет работ а т ь хорошо в больших конфигураци ях точно так же, как и в маленьких, а также исключае т принцип “единой точки сбоя” (single point of failure). Масштабиру емос т ь дос ти г а е т с я за счёт внедрени я фактор а случайно с ти в алг ори тмы управл е ни я сис т емой, когд а каждый узел принимае т решения, ба зиру я с ь на час ти чном знании сос т о я ния других узлов, и не пытае т с я опред е ли т ь сос т о я ни е всех узлов клас т е р а или клас т е р а в целом. Например, согл а с н о вероя тн о с т н ому ал гори тму расс е и в а ни я информации, каждый узел клас т е р а посылае т чере з регу л ярные интерв а лы времени информацию о своих (локал ьно) доступных ресур с а х случайному подмножес т в у всех узлов. В то же время, он поддержива е т небольшое окно недавно полученной информации. Эта схема поддержива е т масштабиро в а ни е, равномерное рас с е и в а ни е информации и динамиче ск ую конфигур ацию (см. т.ж. гл. 2.4.6). Как было ска з а н о выше, для миграции проце с с ра зби в а е т с я на две час ти: поль з о в а т е л ь с к ий конте к с т и сист емный конт е к с т. Пользов а т е л ь с к и й

15 конте к с т сос т ои т из кода прогр аммы, ст ек а, данных, карт памяти и реги с т р о в процес с а. Таким обра з ом он инкап су лиру е т проце с с, выполняющийся на уровне поль з о в а т е л я . Системный конте к с т сод ержит опис ание ресу р с о в, которые закр е пл ены за данным процес с ом, и ст ек ядра для выполнения сис т емных вызовов. Таким обра з ом он инкапсу лиру е т процес с, когд а тот выполня е т с я на уровне ядра. Так как он содержит машинно- за ви симую час т ь сис т емно г о конте к с т а процес с а, то, следов а т е л ь н о, он должен ост а в а т ь с я на UHN проце с с а. Посколь ку вся памят ь прос тр ан с т в а поль з о в а т е л я находит с я на удал ённом узл е, пред с т а в и т е л ь с к и й конте к с т не имеет своей кар ты памяти. Вместо это г о он раз д е л я е т карту памяти ядра таким же обра з ом, как и поток ядра. Интерфейс между поль з о в а т е л ь с к им конт е к с т ом и сис т емным конте к с т ом ядра хорошо опред е л ё н, а следов а т е л ь н о, можно вмешать с я в каждое тако е взаимод ей с т в и е и перенапр а в и т ь его посред с т в ом сети. Это реали з о в а н о на уровне свя з и (link layer) как специал ьно г о коммуникационно г о канал а для взаимод ей с т в и я. На рис. 2 пока з а ны два процес с а, которые ра зд е л яют UHN: левый проце с с – это обычный Linux проце с с, в то время как правый проце с с разд е л ё н, и удал ённый конте к с т мигриров а л на другой узел. Время миграции сос тои т из фиксиров анной компонен ты для уст ано в ки ново го кадра проце с с а на удал ённом узл е, и линейной компонен ты, пропорциона л ьной количе с т в у страниц памяти для перемещения. Для уменьшения накл адных расход ов на миграцию перемещаются только таблицы стр аниц и “гря з ные” страницы процес с а. Остал ьные страницы перемещаются по тому же принципу, что и страницы, выгруженные в обла с т ь подкач ки: в случа е, если при выполнении проце с с а требу ема я страница отсу т с т в у е т, то возник а е т исключение, страница пере сыла е т с я удал ённому узлу, и выполнение процес с а продолжае т с я с прерв анной точки. Таки обра з ом, при выполнении проце с с а в openMosix прозр а чно с т ь расположения дости г а е т с я за счё т перен апр а в л е ни я машинноз а в и симых сис т емных вызовов на UHN. Системные вызовы являются синхронной формой взаимод ей с т в и я между двумя конт е к с т ами процес с а. Все сис т емные вызовы, произ в о д ящиес я проце с с ом, прерываютс я и, если они явл яютс я машинноне з а в и с имыми, выполняютс я локал ьно (на удал ённом узл е). В противном случа е они направ л яютс я на UHN, где выполняютс я от имени приложения. Резул ь т а т выполнения воз в р ащае т с я на удал ённый узе л, который за т ем продолжае т выполнят ь код на уровне поль з о в а т е л я. Другой формой вз аимод ей с т в и я между конт е к с т ами проце с с а являютс я дост а в к а сигна л о в и события пробуждения проце с с а, такие как прибытие се т е вых данных. Эти события требуют асинхронно г о взаимодей с т в и я между пред с т а в и т е л ь с к им и удал ённым конт е к с т ами. В типичном сцена рии ядро на UHN информируе т пред с т а в и т е л ь с к ий конт е к с т о событии, который прове р я е т, необходимо ли предприня т ь какие- либо дейс т в и я, и, если да, то информируе т удал ённый. Удалённый конте к с т провер я е т коммуникационный канал на наличие сообщений об асинхронных событиях перед тем, как

16 продолжат ь выполнение на уровне поль з о в а т е л я (т.е. каждый ра з, когд а планировщик перек люча е т с я на выполнение это г о процес с а). При многих дейс т ви я х с ядром, таких как выполнение сис т емных вызово в, необходимо перемещать данные между прос тр а н с т в ом поль з о в а т е л я и ядра. Обычно это происходи т при помощи примитив ядра copy_to_user(), copy_from_user(). В openMosix любые операции с памят ью ядра, которые за т р а г и в ают дос ту п к прос тр ан с т в у поль з о в а т е л я, требуют взаимод ей с т в и я предс т а в и т е л ь с к о г о и удал ённо г о конте к с т о в для пере сылки необходимых данных. Затр а ты на вз аимод ейс т в и е из- за удал ённых операций копиро в ани я, которые могу т повтор я т с я нескол ь к о ра з в пред ел а х одного сист емно г о вызов а, могут быть дос т а т о чн о существ е нными в основном из- за зад ержек се ти. Для тог о чтобы уменьшить чре з вычайное количе с т в о удал ённых опер аций копиров ани я, был реали з о в а н специал ьный кэш, который уменьшае т число вз аимод ей с т в ий посред с т в ом предвыборки наибол ьшего количе с т в а данных во время первона ч а л ь н о г о запро с а на сис т емный вызов, в то же время буферизиру я час ти чные данные на UHN для перед а чи удал ённому конт е к с т у при зав е ршении сис т емно го вызов а. Для то го, чтобы предот в р а т и т ь удаление или пере крытие отображённых в память файлов (для за г р у з к и страниц по требов а нию), пред с т а в и т е л ь с к ий конте к с т , в отсу т с т в и е карты памяти, содержит специа л ьную таблицу таких файлов, которые отображены на удал ённую памят ь. Пользо в а т е л ь с к и е реги с т ры удалённо г о проце с с а обычно подот в е т с т в е н ны удал ённому конте к с т у, тем не менее, любой реги с т р или их комбинация может временно перейти в принадл ежнос т ь предс т а в и т е л ь с к ому для манипуляций. Удалённые процес сы не дост упны другим проце с с ам, выполняющимся на этом узл е (локал ьно или мигриров а вших с дру гих узлов) и наоборо т. Они не принадл ежа т какому- либо опред е л ё нн ому поль з о в а т е лю на удал ённом узл е, гд е они выполняются, и не могут посыла т ь сигна лы или каким- либо иным обра з ом манипулиров а т ь локал ьными проце с с ами. Единств енно е, что админис тр а т о р может за с т а в и т ь мигриров а т ь данный процес с с это г о узл а. Иногда процес с у нужно выполнить некот орые фукнции openMosix, в то время как он находит с я в логич е с к ом сос т о янии ост ан о в а или сна. Такие проце с сы выполня т функции openMosix “в сос т о я нии сна”, посл е чего продолжат сон, если тем времен ем не произошло события, которо г о они ждали. Примером явл я е т с я миграция процес с а, возможно происход ящая, когд а процес с спит. Для этих целей openMosix сохран я е т логич е с к о е сос т о я ни е, описывающее, как дру гие проце с сы будут виде т ь это т проце с с, которо е явля е т с я противопол ожным его непоср е д с т в е н н ому сос т о я нию. Подход, описанный в этой гла в е, явл я е т с я устойчивым, и даже большие изменения в ядре не влияют на него. Он прак тич е с к и не пола г а е т с я на машинноз а в и с имые свойс т в а ядра, и поэтому ничто не мешает перен е с т и его на дру ги е архит е к т у ры. Недост а т к ом это г о подход а явл яютс я, очевидно, дополнит е л ь ные накл адные расходы на выполнение сис т емных вызово в.

17 Дополнит е л ь ные расходы возникают при файловых и се т е вых операция х. Так, например, все се т е вые соке ты соз д аютс я на UHN, что явл яе т с я причиной усиления вз аимод ейс т в и я, если проце с с мигриру е т с UHN. Для преодол е ния этой проблемы ра з р а б а тыв аютс я мигриру емые сок е ты, которые могу т перемещать с я вмес т е с проце с с ом, дела я возможным прямое соединени е с мигриров а вшим проце с с ом. В нас т о ящее время эти расходы могут быть существ е нно уменьшены за счё т первонач а л ь но г о распр е д е л е ни я взаимод ей с т в ующих проце с с о в на раз личные узлы, например, при помощи PVM. Если сис т ем а станови т с я несб ал а н с иро в а н ной, ал гори тмы openMosix перена з н а ч ают процес сы для увелич ения произ в оди т е л ь н о с т и (см. [BAR6]).

2.1.1. Сбор информации о процессе Стати с т ик а о повед ении процес с а собира е т с я периодич е с ки, например, при сис т емных вызов а х и каждый раз, когд а процес с получа е т досту п к поль з о в а т е л ь с к им данным. Эта информация исполь з у е т с я для оценки то го, что проце с с должен мигриров а т ь с UHN. Эта ста ти с т и к а уст а р е в а е т чер е з неко то р о е время для тог о, чтобы приспособи т ь с я к проце с с ам, изменяющих свой профиль выполнения. Она также полнос т ью очищает с я при сис т емном вызов е execve() (который замещает процес с новым), потому что, скоре е все г о, процес с изменит свой хара к т е р. Каждый процес с имеет некоторый контрол ь над сбором и уст а р е в а н и ем сво ей ста ти с т и ки. Например, процес с может приос т а но ви т ь своё выполнение, зна я, что его хара к т е р и с т и к и должны вот- вот изменит ь с я, или он может цикличе с к и перек люча т ь с я, комбинируя вычисл ения и ввод- вывод.

2.1.2. Ограничения на миграцию Некоторые функции ядра не совмес тимы с ра зд е л е н и ем конте к с т а проце с с а. Очевидными примерами являютс я непоср е д с т в е н н о е манипулиро в а ни е устройс т в ами ввод а- вывода, вз аимод ейс т в и е напрямую при помощи привил е ги р о в а нных инстру кций с шиной или прямой дост уп к устрой с т в у памяти. Другие примеры включают в себ я испол ь з о в а н и е потоко в или приложений реал ьно г о времени (в посл едн ем случа е нево зможно гар ан т ир о в а т ь их корре к т но е функциониров ание после миграции). Процес сы, которые исполь з уют эти механизмы, автома тич е с к и замыкаютс я на домашнем узл е. Если проце с с уже мигриров а л, то он высылае т с я обра тно на UHN. При этом /proc/[PID]/cantmove содержит имя конфликтно г о сист емно г о вызов а (см. гл. 6.1.1).

2.2. Алгоритмы разделения ресурсов Основными ал гори тмами ра зд е л ен и я ресур с о в openMosix являютс я ал го ри тмы балан си ро в ки нагру з к и и ал гори тмы распр е д е л е ни я памяти 1 (или 1 Не имеет ниче г о общего с проблемой распр е д е л ё нной ра з д е л я емой памяти (distributed shared memory)

18 предо т в р ащения своппин г а памяти). Динамиче ский ал гори тм балансиров ки нагру з к и непрерывно пытае т с я уменьшить разно с т ь нагру з к и между парами узлов, мигрируя проце с сы от боле е за г р уженных узлов к менее за г р уженным. Эта схема явл я е т с я децен тр а л и з и р о в а нной: на всех узл ах работ а е т один и тот же алг ори тм, и уменьшение разно с т и за г ру з к и выполняе т с я нез а в и с имо любой парой узло в. Количес т в о выполня емых проце с с о в и быстрод ей с т в и е узл а являютс я важными фактор ами ал гори тма балан сиро в ки нагру з к и. Этот ал гори тм отв е ч а е т на изменения нагру з ки узл а или на изменени е хара к т е ри с т и к времени выполнения проце с с а. Он ост а ё т с я преобл ад ающим то тех пор, пока сис т ем а не испытывае т чре зм е рно г о недос т а т к а других ресурс о в, таких как свободна я память или свободные слоты для процес с о в. Второй ал гори тм – ал гори тм распр е д е л е ни я (предот в р ащения истощения) памяти – приспособ л е н для тог о, чтобы размещать максимально е число процес с о в в общекла с т е р ной RAM для избежания, наскол ь к о возможно, за с о р е ния памяти или выгру з ки страниц памяти в обла с т ь подкач ки. Этот ал го ри тм включае т с я, когд а узел начина е т интенси вный обмен страницами с обла с т ью подкачки из- за нехв а т ки памяти. В этом случа е, это т ал го ри тм перекрыва е т ал гори тм бал ансиров ки нагру з к и и пытае т с я мигриров а т ь процес с на узел с дост а т о ч ным количе с т в ом свободной памяти, даже если эт а миграция привед ё т к неура вно в ешенному распре д е л е нию. Нескол ько позже в openMosix был внедрён новый ал гори тм для выбора узл а, на котором должен выполнят ь с я проце с с. Математич е с к а я модель это г о планиров очно г о ал гори тма пришла из обла с ти экономиче с ких иссл е д о в а ний. Этот ал гори тм пытае т с я уравнов е с и т ь раз л ичи я между ра зличными ресу р с ами основывая с ь на экономиче с ких принципах и конкурен т ном анали з е. Эта экономиче с к а я стра т е г и я обеспе чив а е т унифициров анную ал гори тмиче с к ую основу для распр е д е л е ни я вычислит е л ь ных, коммуникационных ресу р с о в, памяти и ресур с о в ввод а- вывода. Она позвол я е т ра з р а б а тыв а т ь близки е к оптимал ьным online алг ори тмы для распре д е л е ни я и совме с т но г о испол ь з о в а н и я этих ресур с о в.

19

2.3. Метод оценивания стоимости для назначения и переназначения заданий 2.3.1. Построение модели Сформулируем цель как улучшение произ води т е л ь н о с т и клас т е р а из n машин, гд е машина i имеет процес с о рные ресур сы скоро с т ью rc(i) и ресу р сы памяти ра змером rm(i). Мы абс т р а г и р у ем с я от других ресу р с о в, ас социиров а нных с машиной, хотя эт а стру к т у р а может быть расширена для управл е ни я дополнит е л ь ными ресур с ами. Есть некот ор а я посл ед о в а т е л ь н о с т ь поступ ающих зад а ний, которые должны быть назна ч е ны этим машинам. Каждое j зад ани е опред е л я е т с я тремя парамет р ами: •

время прибытия a(j);

•

количе с т в о процес с о рн о г о времени t(j), которо е требу е т с я для него;

•

количе с т в о памяти m(j), которо е требу е т с я для него.

Предпола г а ем, что m(j) изв е с т н о, когд а поступ а е т зад а ние, а t(j) – нет. Задани е должно быть назн ач е но машине непоср е д с т в е н но посл е поступл ения и может быть позже перемещено от одной машины к другой. Пусть J(t,i) – множеств о зад аний на машине i в момент времени t. Тогда за г ру з к а процес с о р а и памяти на этой машине соот в е т с т в е н н о равны: l c t ,i =∣J t , i∣ l m t , i=

∑

(мощность множест в а J(t,i)) и

m j

j ∈J t , i

Предпола г а ем, что когд а у машины зак а нчив а е т с я память, то она замедл я е т с я на некот орый мультиплика т и в ный фактор s из- за сброс а стр аниц на диск. Тогд а эффективн а я процес с о рн а я нагру з к а машины i в момент t: L t ,i ={

l c t ,i =∣J t ,i ∣, если l m t ,ir m i  l c t ,i ∗s , если l m t ,ir m i

Для прост о ты также предпол а г а ем, что все машины выполняют зад а ния “справ е д л и в о”, то ес т ь в момент времени t каждое зад ани е на машине i получит 1/L(t,i) проце с с о рн о г о времени. Поэтому время за в е ршения зад ани я c(j) удовл е т в о р я е т следующему уравнению: c  j

∫

a j

r c i dt=t  j  , гд е i – это номер машины, на которой выполня е т с я L t ,i 

зад ани е в данный момент времени t. Если L(t, i) = 1, то из последн е г о выражения t  j следу е т, что c  j −a  j = , то ес т ь, если на проце с с о р е выполняе т с я r c i единс т в е нно е зад а ние, то реал ьно е время его выполнения совпад а е т с временем выполнения на проце с с о р е. Нетрудно виде т ь, что если L(t, i) > 1 , то

20

c  j −a  j 

t  j . r c i 

Величина

c  j −a  j  t  j

называ е т с я

замедл ени ем

зад а ния.

Необходимо

разр а б о т а т ь метод назн а ч е ни я зад аний и/или перена з н а ч е н и я, минимизиру е т средне е замедл ени е по всем зад ани ям.

который

Будем оценива т ь эффективно с т ь наших online ал гори тмов их сра вни т е л ь ным коэффициентом, измеренно г о по отношению к произ в оди т е л ь но с т и оптимал ьно г о offline ал гори тма. Online ал гори тм ALG называ е т с я c-сравнимым, если для любой входной посл ед ов а т е л ь н о с т и I следу е т, что ALG(I) < c OPT(I) + α, гд е OPT – оптимал ьный offline алгори тм, α явл я е т с я конс т а н т ой.

2.3.2. Основные определения Теоре т ич е с к а я час т ь это г о ра зд е л а соср е д о т о ч и т с я на том, как минимизиров а т ь максимал ьно е исполь з о в а ни е раз личных ресур с о в сис т емы, дру гими слов ами, как наилучшим способом сбал а н с и ро в а т ь нагру з к у сист емы. Один ал гори тм для выполнения это г о, описанный в [AWER1], дока зыв а е т свою прак тич е с к ую поле з но с т ь даже тогд а, когд а наша цель сос тои т в том, чтобы минимизиров а т ь средне е квадр а т и чно е замедл е ние, которо е соот в е т с т в у е т уменьшению суммы квадр а т о в нагру з о к. В подго т о в к е к обсуждению ал гори тма иссл е д у ем проблему минимизации с тремя различными моделями машин и двумя различными видами зад аний. Три модели машин: 1. Идентичные машины. Все машины идентичны, и скоро с т ь выполнения зад ания на данной машине опред е л ен а тольк о нагру з к ой машины. 2. Связ анные машины. Машины идентичны за исключением того, что неко то рые из них имеют ра зличные скоро с ти – в модели выше они имеют ра з личные знач ени я rс , и память, свя з а нн а я с этими машинами, игнориру е т с я . 3. Несвя з а нные машины. Много ра з личных факторов могут влия т ь на эффективную нагру з к у машины и время зав е ршения зад аний, выполняющихся на них. Эти факторы изв е с т ны. Два возможных вида зад аний: 1. Посто янные зад а ния. Как тольк о ост ан е т с я там навс е г д а .

зад ание

поступ а е т

на

машину, оно

2. Временные зад ани я. Задания покидают сис т ему, когд а они получили неко то ро е количе с т в о проце с с о рно г о времени. Также иссл е д у ем свя з а нную проблему, называ емую проблемой online маршрутиз а ции.

2.3.3. Идентичные и связанные машины Сейчас предположим, что никаки е перен а з н а ч е ни я не возможны, и что единс т в е нный ресур с явля е т с я проце с с о рно е время. Наша цель поэ тому

21 сос т ои т в том, чтобы минимизиров а т ь максимал ьную нагру з к у CPU. Когда машины идентичны и никакие другие ресурсы не сущест в е нны, жадный ал го ри тм работ а е т хорошо. Этот ал гори тм для назн а ч ения зад аний назна ч а е т следующее зад ание на машину с минимальной текущей нагру з к ой CPU. Если машины идентичны, и никакие дру гие ресур сы не существ е нны, жадный 1 ал го ри тм имеет сра внит е л ь ный коэффициент с=2 – (см. [BART1]). n Когда машины свя з а ны, зад ани я постоянны, и никаки е другие ресур сы не существ е нны, эффектив е н ал гори тм Аспнес а (см. [ASPN1]). Определим OPT как нагру з к у оптимально г о offline алг ори тма; аппроксимация OPT даё т с я в [ASPN1]. Этот алгори тм назн а ч а е т каждое прибывающее зад ание на самую медленную машину с резу л ь т и рующей нагру з к ой ниже 2 * OPT. Если OPT изве с т н а, это т ал гори тм имее т конкурен т ный коэффициент 2. Чтобы аппроксимиров а т ь OPT, можно исполь з о в а т ь методику дублиров ани я. Для несв я з а н ных машин и временных зад аний бе з перена з н а ч е ний не изве с т н о никако г о ал гори тм а с конкурен тным коэффициентом лучше, чем n.

2.3.4. Несвязанные Машины Рассма т ри в а емый ал гори тм – это ал гори тм для несв я з а нных машин и посто янно г о назн ач е ни я зад аний, основ анный на пока з а т е л ь н ой функции от “стоимос ти” машины с данной нагру з к ой. Этот ал гори тм назн ач а е т каждое зад ани е на машину, чтобы минимизиров а т ь общую стоимос т ь всех машин в кла с т е р е . Более точно, положим: •

a – конс т а н т а, 1 < a < 2;

•

li(j) – нагру з к а машины i перед назна ч е ни ем зад ани я j;

•

pi(j) – зад ани е j для нагру з ки, которо е буде т добав л е но к машине i.

Online ал гори тм назна чи т стоимос т ь: H i  j =a

l i  j  p i  j

−a

j на машину i, что минимизиру е т

граничную

li  j 

Этот ал гори тм сравним с O(log n) для несв я з а н ных машин и посто янных зад аний. Работ а, предс т а в л е н н а я в [AWER2], расширяе т это т алгори тм и коэффициент сравне ния на временные зад ания, исполь з у я до O(log n) перена з н а ч е ний на зад ание. Перена з н а ч е ни е перемещае т зад ани е с его предв а ри т е л ь н о назн а ч е нной машины на новую машину. При наличии перена з н а ч е ний положим: •

hi(j) – нагру з к а машины i перед тем, как j было в посл едний ра з назн ач ено на i.

Когда все зад ания за в е ршилис ь, ал гори тм в [AWER2] провер я е т “условие устойчиво с т и” для каждого зад а ния j и каждой машины M. Это услови е устойчиво с т и, гд е i озна ч а е т машину, на которой в нас то ящее время находит с я зад ани е j, ес т ь: a

h i  j p i  j 

−a

hi  j 

2 a

l M  j p M  j 

−a

lM  j 



22 Если это услови е устойчиво с т и не удовл е т в о р е но некоторым зад анием j, ал го ри тм перена з н а ч а е т j на машину М, что минимизиру е т HM(j).

2.3.5. Online маршрутизация виртуальных каналов Рассма т ри в а емый алг ори тм минимизиру е т максимал ьно е исполь з о в а ни е единс т в е нно г о ресур с а. Чтобы расширить это т ал гори тм на нескол ь к о ресу р с о в, мы иссл е ду ем свя з а н ную с данной проблему online маршрутиз а ции вирту а л ь ных канало в. Коротко привед ём объясн ение того, что эт а пробл ема явл я е т с я соот в е т с т в ующей данной. В этой проблеме нам даны: •

взв ешенный граф G(V, E), с объёмом u(e) для каждого ребра e;

•

пред ел ь но допус тима я нагру з к а mx;

•

посл ед о в а т е л ь н о с т ь нез а в и с имых запро с о в (sj, tj, pj: E→[0, mx]), прибыва емых в произ в ол ь но е время; sj и tj – исход ящий и приёмный узлы, p(j) – требу ема я ширина пропус к а ни я.

Запро с, который назн ач е н на некоторый путь P от источник а к приёмнику, p j увеличив а е т нагру з к у le на каждом ребре e из P на величину pe  j = . u e Наша цель сос т ои т в том, чтобы минимизиров а т ь максимал ьную пере г р у з к у свя з е й, котор а я явл я е т с я отношением ширины пропуск а ния, выделенной на свя з ь, к её объёму. Минимизация максимал ьно г о исполь з о в а н и я CPU и памяти, где испол ь з о в а н и е памяти измеря е т с я в доле исполь з у емой памяти, может быть свед ено к проблеме online маршрути з ации. Это свед ени е произ во ди т с я следующим обра з ом: созд а д им два узл а {s, t} и n непер е с е к ающихся путей, сос т о ящих из одного ребра , с двумя вершинами из s в t (см. рис. 3). Каждая машина i пред с т а в л я е т собой некот орый путь e с ребром 1 памяти объёмом rm(i) и ребром CPU с объёмом rc(i). Каждое 2 зад ани е j ест ь запро с с источником s, сливом t и 3 s t функцией p, котор а я отображае т рёбра памяти на n треб о в ания к памяти для зад а ния и рёбра CPU – на 1. Рис. 3. Граф Максимальна я пере г р у з к а свя з и ес т ь большее из маршрутов максимальной нагру з ки CPU и максимально г о испол ь з о в а н и я памяти. Рассма т ри в а емый ал гори тм расширен в [ASPN1], чтобы обращать с я к проблеме online маршрутиз а ции. Алгоритм вычисля е т граничную стоимос т ь для каждо го возможного пути P от sj к tj следующим обра з ом: H p  j =∑ a

l e  pe  j 

и назна ч а е т стоимос т ь.

le

−a , ∀ e∈P

запрос j на путь P, который даё т минимальную граничную

Этот алгори тм сравним с O(log n) (см. [ASPN1]). При помощи свед е ния это т ал го ри тм порождае т ал гори тм для управл е ни я ге т е р о г е нными ресу р с ами,

23 который явл я е т с я каждо го ресур с а.

сра внимым с O(log n) при максимал ьном исполь з о в а нии

2.3.6. Методика практического исследования Для каждой машины в клас т е р е из n машин, с ресур с ами r1 ... rk, мы опред е л я ем стоимос т ь это машины как: k

∑ f n , использование r i  i=1

гд е f – некотор а я функция. На прак тик е выберем f так, чтобы эт а сумма была равна: k

∑n

использованное r i макс.использование r i

i=1

Гранична я стоимост ь назн а ч е ни я зад ани я на данную машину – это количе с т в о, на которо е эта сумма увеличив а е т с я , когд а зад ани е назн ач ен о на эту машину. Подход “стоимос ти возможнос ти” (“opportunity cost”) для распр е д е л е ни я ресур с о в назн а ч а е т зад ани я на машины способом, который минимизиру е т эту граничную стоимос т ь. В этом раз д е л е мы заин т е р е с о в а ны только двумя ресур с ами, CPU и памятью, и мы игнориру ем другие рас с уждения. Следов а т е л ь н о, вышеупомяну т а я теория подра з уме в а е т , что при лога рифмиче ски большем количе с т в е памяти, чем у оптимал ьно г о online алг ори тма, данный ал гори тм дос ти г н е т максимально г о замедл ени я в пред ел а х O(log n) от максимал ьно г о замедл ения оптимал ьно г о ал го ри тма. Это не гара н тиру е т, что алг ори тм, основ анный на данном, буде т конкур ен тным в его среднем замедл ении по всем проце с с ам. Это также не гар ан т ир у е т, что такой ал гори тм буде т сов е ршенне е, чем сущест в ующие методы. Следующим шагом мы должны прове ри т ь, что это т ал гори тм фактич е с к и сов ершенне е, чем существ ующие методы, на практик е. Ресур с памяти легк о тран слиру е т с я в модель ресур с о в данног о ал гори тма. Стоимост ь исполь з о в а н и я некоторо г о объёма памяти на машине ес т ь nu, гд е u используемая память – пропорционал ьно е исполь з о в а ни е памяти ( u= ). Для всего памяти ресу р с а CPU мы должны зна т ь максимал ьную возможную нагр у з к у . Предположим, что L – самая маленьк а я целочис л е нн а я степ ен ь двойки, большая, чем самая большая нагру з к а, которую мы наблюдали в любое зад анно е время, – явля е т с я максимал ьно возможной нагру з к о й. Это предположение, будучи неточным, не меняе т сравни т е л ь ный коэффициент ал го ри тма. Стоимост ь CPU и нагру з ки памяти для зад анной машины, испол ь з у я наш метод, ес т ь:

24

n

использованная память всего памяти

n

загрузка CPU L

Будем назна ч а т ь или перен а з н а ч а т ь зад ани я так, чтобы минимизиро в а т ь сумму за тр а т на всех машинах в кла с т е р е . Для того, чтобы иссл е д о в а т ь повед е ни е это г о подход а “стоимос ти возможнос ти”, оценим четыре различных метод а для назн а ч е ни я зад а ния: 1. PVM. PVM – очень популярна я сис т ем а метавычисл е ний для сис т ем без приорит е т н о г о перемещения проце с с о в. Если поль з о в а т е л ь сис т емы специа л ьн о не вмешивае т с я, PVM назн а ч а е т зад ания машинам, испол ь з ующих стро г ую цикличе с к ую стра т е г ию. Она не перен а з н а ч а е т зад ани я посл е тог о, как они начинают выполнение. 2. Усовершенс т в о в а нный PVM. Усовершенс т в о в а нный PVM исполь з у е т стр а т е г ию, основ анную на стоимос ти возможнос ти, котор а я назна ч а е т каждое зад ани е на машину, для которой зад ани е имее т самую маленькую граничную стоимос т ь. Как и для PVM, начал ьные назн а ч ени я посто янны. 3. openMosix. openMosix – расширение для ядра Linux, позвол яющее сист ем е перемещать проце с сы от одной машины к дру гой без прерывания их рабо ты. openMosix испол ь з у е т усов е ршенс т в о в а н ную стра т е г ию бал ан сир о в ки нагру з ки, котор а я также пытае т с я сохрани т ь некоторую память свободной на всех машинах. openMosix не все з н ающий: когд а сис т ем а обменива е т с я информацией о проце с с е при подго т о в к е к возможному перен а з н а ч е нию проце с с а, каждая машина конта к т иру е т с огранич енным набором дру гих машин (см. гл. 2.1). 4. Усовершенс т в о в а нный openMosix. Усовершенс т в о в а нный openMosix – это стр а т е г и я, основ анн а я на стоимос ти возможнос ти, предна з н а ч е н н а я для испол ь з о в а н и я на сис т ем ах (таких как клас т е ры openMosix), которые могу т приорит е т н о перемещать проце с сы. Она назн ач а е т или перен а з н а ч а е т зад ани я, чтобы минимизиров а т ь сумму за т р а т на всех машинах. Расширенный openMosix имеет те же самые огранич е ния на свои “знания”, как нера сширенный openMosix.

2.3.7. Экспериментальные результаты Первое испытани е данног о ал гори тма было эмуляция Java зад а ч для четырёх методо в (пере)на з н а ч е ни я зад аний, упомянутых выше. Были сдел а ны следующие предположения: 1. Класт е р сод ержит шесть машин со следующими хара к т е р и с т и к ами:

25

Тип машины

Количество таких машин

Скорость обработки

Установленная память

Pentiom Pro

3

200 МГц

64 Мб

Pentium

2

133 МГц

32 Мб

Laptop, Pentium

1

90 МГц

24 Мб

Таблица 1. Машины в эмулиру емом клас т е р е 2. Для каждого входящего зад ани я, положим, что r и m – нез а в и с имо сген е ри ро в а н ные случайные числ а между 0 и 1. Типичный проце с с буде т треб о в а т ь 2/r секунд CPU и (1/m)% памяти Pentium Pro. Распред е л е н и е основ а но на наблюдениях за процес с ами в реал ьной жизни. Приблизи т е л ь н о 95% всех зад аний – зад ани я с единст в е нным проце с с ом, соотв е т с т в ующие этой конфигур ации. Поскольк у данна я сис т ем а – сис т ем а метавычисл ений, предпол а г а е т с я , что 5% всех зад аний – большие паралл е л ь ные зад а ния, испол ь з ующие мощност ь метавычисл е ний. Эти зад ания сод ержат от 1 до 20 идентичных проце с с о в, требующих 20/r секунд CPU и (1/m)% памяти Pentium Pro. Чтобы сдел а т ь эмуляцию полной, предпол а г а е т с я , что никакой проце с с не требу е т больше чем 100% памяти Pentium Pro, никакой проце с с из числ а зад аний с единс т в е нным проце с с ом не требу е т больше чем 1,000 секунд CPU, и никакой проце с с из числ а больших паралл е л ь ных зад а ний не требу е т больше чем 10,000 секунд CPU. 3. Задани я прибывают в произ в ол ь ном порядк е в теч ение первых 1,000 моделиру емых секунд. Приблизи т е л ь н о одно зад ани е прибывае т каждые 10 секунд. Можно наблюдат ь, что для каждого из этих четырёх методо в имеются примеры эмуляций, когд а сист ем а была пере г р ужена, недогр ужена и за г р ужена как обычно, и примеры, гд е сист ем а переходил а из любого из этих сос т о я ний в любое друго е. 4. Когда исполь з о в а ни е памяти машины превышает объём памяти, предпол а г а е т с я что эт а машина находит с я в режиме интенсивной подкачки. Это замедл я е т машину на коэффициент t, который был аппрок симиро в а н посто янным множител ем, равным 10. То ес т ь, при эмуляции каждое зад ание треб о в а л о в 10 ра з больше времени на машине с интен си вной подкачко й, как это бы потреб о в а л о с ь на машине со свободной памятью. При каждом выполнении все четыре метод а испол ь з о в а л и один и то т же сценарий, в котором те же самые зад ани я прибывали с той же самой скоро с т ью.

2.3.8. Результаты эмуляции Java Каждое выполнение воз в р ащало средне е замедл е ни е по всем зад ани ям, также как и некоторую информацию относи т е л ь н о непоср е д с т в е нн о сценария. Эти резу л ь т а ты были оценены двумя различными способ ами. Самый важный интере с пред с т а в л я е т общее замедл ени е, испытанное каждым из этих четырёх методов. Средне е замедл ени е при выполнении – это нев з в ешенное средне е число всех рез ул ь т а т о в эмуляции, нез а в и симо от

26 числ а зад а ний при каждом выполнении. Средне е замедл ени е зад а ния – это средне е замедл ени е по всем зад аниям во всех запу с к а х эмуляции. Эти резу л ь т а ты, объединяющие 3000 выполнений, даются в таблице 2. Поведени е усов е ршенс т в о в а н но г о PVM и усов е ршенс т в о в а н но г о openMosix различно в сле г к а за г р уженных и тяжело за г руженных сценариях. Это повед ени е иллюстриров а но на рис. 4 – рис. 7, дет а ли з и рующих первые 1000 выполнений эмуляции. Замедление

PVM

Усовершенствованный PVM

oMosix

Усовершенствованный oMosix

средне е для выполнения

14.3338

9.79463

8.55676

7.47886

средн е е для зад а ни я

15.4044

10.7007

9.4208

8.20262

Таблица 2. Средне е замедл ени е в эмуляции Java для ра зличных методо в Каждая точка на рисунке пред с т а в л я е т собой отдел ьн о е выполнение эмуляции для двух наз в а нных методов. На рис. 4 ось X – средн е е замедл ени е для PVM, а ось Y – средне е замедл ени е для усов е ршенс т в о в а нно г о PVM. Точно так же на рис. 5 ось X – средне е замедл е ни е для openMosix, а ось Y – средне е замедл ени е для усов е ршенс т в о в а нно г о openMosix.

Ус ов е рше нс т в ов а нный PVM

Светл а я линия опред е л е н а как “x = y”. Выше этой линии неу со в е ршенс т в о в а нный алг ори тм работ а е т лучше, чем усов е ршенс т в о в а нный ал го ри тм. Усовершенс т в о в а нный PVM, как пока з а н о в таблице 2, рабо т а е т

Ре з ульт аты э муляции Линия раве нс т ва

PVM

Рис. 4. PVM против усов е ршенс т в о в а нн о г о PVM

27

Ус ов е рше нс т в ов а нный openMosix

значи т е л ь н о лучше, чем обычный PVM почти в каждом случа е. Боле е интер е с ным, однако, явля е т с я повед ени е усов е ршенс т в о в а нн о г о openMosix по сра вн ению с openMosix. Чем больше было средне е замедл е ни е у openMosix на данном выполнении, тем больше улучшений дало вед ённо е усов е ршенс т в о в а н и е. Интуитивно понятно, что когд а выполнение было напряжённым для всех четырёх моделей, усов е ршенс т в о в а нный openMosix рабо т а л намного лучше, чем неусов е ршенс т в о в а н ный openMosix. Если данное выполнение было относи т е л ь н о лёгким, и сис т ем а не была тяжело за г р ужена, усов е ршенс т в о в а н и е имело меньше положител ьно г о эффект а.

Ре з ультаты э муляции Линия раве нс тва

openMosix

Рис. 5. openMosix против усов е ршенс т в о в а нно г о openMosix Это можно объясн я т ь следующим обра з ом. Когда машина станови т с я тяжело за г р уженной или начина е т интенси вную подкачку, это за т р а г и в а е т не только время за в е ршения для зад аний, уже назна ч е нных сис т ем е. Если машина не стан е т раз г р уженной прежде, чем следующий набор больших зад а ний будет назна ч ен сис т ем е, то эта машина станови т с я эффективно недос т у пной для них, увеличив а я нагру з к у на всех дру гих машинах. Если много машин начина е т интен си вную подкачку или станов я т с я тяжело за г руженными, это т эффект буде т испол ь з о в а т ь сам себ я. Каждое входящее зад ание займё т ресу р сы сис т емы на намного боле е длинный промежуток времени, увеличив а я замедл ени е зад аний, которые прибывают, в то время как вычисл я е т с я это зад ани е. Из-за это г о эффект а пирамиды, “мудрое” начал ьн о е назн ач е ни е зад аний и осторожное вос с т а н о в л е ни е равнов е с и я может приве с т и (в экс т р ем а л ь ных случ а я х) к сущест в е нным улучшениям над станд а р т ным openMosix, как пока з а н о при некоторых выполнениях на рис. 5.

Ус ов е рше нс т в ов а нный PVM

28

Ре з ультат ы э муляции Линия раве нс тва

openMosix

Ус ов е рше нс т в ов а нный openMosix

Рис. 6. openMosix против усов е ршенс т в о в а нно г о PVM

Ре з ульт аты э муляции Линия раве нс т ва

Ус ов е рше нс т в ов а нный PVM

Рис. 7. Усовершенс т в о в а нный openMosix против усов е ршенс т в о в а нно г о PVM Особенно интер е с н о обра ти т ь внимание на то, что, как видно из таблицы 2 и рис. 6, усов е ршенс т в о в а н ный PVM метод, который не дела е т никаких перена з н а ч е ний вообще, умеет дос ти г а т ь приличной (хотя и худшей)

29 произ в о ди т е л ь но с т и по сравн ению с openMosix. Это подчёрки в а е т мощность подход а стоимос ти возможности: его произ в оди т е л ь н о с т ь на нормальной сис т ем е не подавл ено произ в оди т е л ь н о с т ью боле е прево с х од ящей сис т емы, котор а я может исправл я т ь ошибки первона ч а л ь н о г о назна ч ения. Важност ь миграции демонс триру е т с я на рис. 7. Даже при исполь з о в а нии ал го ри тма стоимос ти возможнос ти все ещё очень поле з но иметь способно с т ь миграции в сист ем е. Фактиче с ки, усов е ршенс т в о в а нный openMosix прево с х о д я т по быстрод ей с т в ию усов е ршенс т в о в а нный PVM во всех случа ях, иногд а значи т е л ь н о.

2.3.9. Выполнение на реальной системе Алгоритмы были также прове р е ны на реал ьном кла с т е р е . Исполь з о в а л а с ь та же самая модель для входящих зад аний, и зад ани я назна ч а л и с ь, испол ь з у я PVM, усов е ршенс т в о в а н ный PVM и openMosix стра т е г и и. Резу л ь т а ты следующие: Замедление

PVM

Усовершенство ванный PVM

openMosix

средне е для выполнения

29.98788

16.29643

13.67707

средне е для зад ания

33.31620

16.76646

14.00990

Таблиц а 3. Средне е замедл ени е на реал ьном клас т е р е для 3-х методов (пере- ) назна ч е ния Эти начал ьные резу л ь т а ты подра з ум е в ают, что пере г р у з к и в реал ьной жизни, меньший размер клас т е р а и други е разнооб р а з ные факторы увеличили средне е замедл ени е, что говори т о том, что мы были слишком конс е р в а т и в ны в выборе параме тро в для эмуляции. Однако рез ул ь т а ты не изменяют существ е нно относи т е л ь ные знач ени я. Фактиче с ки, усов е ршенс т в о в а н ные методы пока з а л и себ я ещё лучше в реал ьной жизни по сравн ению с их оригин ал ь ными версиями, чем то, что пред ск а з а л а Java эмуляция. Предположите л ьно, это ест ь прове рк а правил ьно с т и начал ьной Java эмуляции и сильно е подтв е рждение кач е с т в а данного подход а оценки возможнос ти. Замедление в реальной си стеме

PVM / oMosix

Enh PVM / oMosix

PVM / Enh PVM

средн е е для выполнения

2.19257

1.20416

1.84015

средн е е для зад ани я

2.37804

1.20946

1.98707

Замедление при эмуляции

PVM / oMosix

Enh PVM / oMosix

PVM / Enh PVM

средн е е для выполнения

1.67514

1.14467

1.46346

средн е е для зад ани я

1.63515

1.13585

1.43957

Таблица 4. Средние относи т е л ь ные замедл ения для 3-х методов (пере- ) назн а ч е ни я зад а ний

30

2.3.10. Заключение Рассмо тр е нн а я экономная стра т е г и я обесп ечи в а е т объединённую ал го ри тмиче с к ую стру к т у ру для распре д е л е ни я вычисл ений, взаимод ей с т в ий, памяти и ресур с о в ввод а- вывода. Это позвол я е т ра з р а б о т а т ь почти оптимал ьные интер а к т и вные ал гори тмы для распр е д е л е ни я и совме с т но г о испол ь з о в а н и я этих ресур с о в. Исследов а нн а я стра т е г и я гар ан т иру е т почти оптимал ьную непрерывную эффективно с т ь для всей сист емы в целом в каждом отдел ьном случ а е порождения зад а ния и дос тупно с т и ресур с а. Это дости г а е т с я при помощи испол ь з о в а н и я интер а к т и в ных ал гори тмов, которые ниче г о не знают о будущем и предпол а г ают, что между прошлым и будущим нет никакой корре л яции, а только осв е д омлены о текущем сос т о я нии. Несмотря на это, можно стро г о дока зыв а т ь, что их эффективно с т ь будет все г д а сопос т а в има с оптимал ьной предвид ящей стра т е г и е й. Этот ра зд е л пока з а л, что унифициров анный подход стоимос ти возможнос ти предл а г а е т хорошую прак тич е с к ую эффекти внос т ь. Сначал а были выполнены испытания, исполь з ующие моделиру емый кла с т е р и “типичный” ряд посту пающих зад аний. Данный метод, с и бе з возможнос ти перена з н а ч е н и я зад аний, был сра вн ён с метод ами PVM, доминирующей ста т ич е с к о й стра т е г и е й назна ч ения зад а ний. Каждому методу предложили идентичные потоки рабо т. Когда все перена з н а ч е ни я были запр ещены, метод пока з а л себ я печал ьным усов е ршенс т в о в а н и ем PVM. Когда перена з н а ч е н и я позвол ял и с ь, метод был существ е нно лучше, чем хорошо нас тро е нн а я PVM стра т е г и я. Вторая серия испытаний была выполнена на реал ьной сис т ем е для подтв е рждения это г о моделиров ания. Реал ьна я сис т ем а была постро е н а на UNIX машинах с Pentium 133, Pentium Pro 200 и Pentium II, с ра з личным объёмом памяти, свя з а нных Fast Ethernet се т ью на основ е протокол а CSMA-CD. Физиче с кий клас т е р и моделиру емый кла с т е р были сле г к а раз личны, но пропорциона л ьн а я эффекти вно с т ь различных стра т е г и й была очень близк а к той, котор а я была получен а моделиров ани ем. Это пока зыв а е т, что моделиро в а ни е соот в е т с т в ующим обра з ом отражае т события на реал ьной сис т ем е. Подход стоимос т и возможнос ти – универ с а л ь ный карк а с для эффективно г о распр е д е л е ни я ге т е р о г е н ных ресур с о в. Теоре тич е с к и е гар ан тии слабы: можно тольк о дока з а т ь лога рифмиче ский пред ел отс т а в а ни я ал гори тм а от оптимал ьно г о offline планировщика. Однако оптимум offline планировщика не явл я е т с я реал ьной аль т е рн а т и в ой; в дейс т в и т е л ь н о с т и этот алг о ри тм конкуриру е т с наивной online эврис ти к ой. На практи к е, это т подход уступа е т прос тым ал гори тмам, которые значи т е л ь н о прево с х од я т по быстрод ей с т в ию широко исполь з у емые и тщател ьн о оптимизиров а нные методы. Заключаем, что теор е т ич е с к и е гар ан т ии лог арифмиче с кой оптимал ьно с т и – хороший пока з а т е л ь того, что ал го ри тм будет хорошо работ а т ь и прак тич е с к и.

31

2.4. Алгоритм распределения памяти Этот ал гори тм позвол яют узлу, который исчерпа л свою основную памят ь, испол ь з о в а т ь доступную свободную память на других узл ах мигриру я процес сы, вмес то того, чтобы выгружат ь страницы в обла с т ь подкачки. Алгоритм распр ед е л е н и я памяти наибол е е поле з е н в случа я х, когд а памят ь испол ь з у е т с я нера вномерно, или когд а узлы имеют ра зличные объёмы памяти. Другим случа ем, когд а это т ал гори тм может быть поле з е н, явля е т с я случай, когд а со зд а н большой процес с, не вмещающийся в свободную памят ь любого узл а. Тем не менее, это т проце с с может помес ти т ь с я в памят ь некот о р о г о узл а при условии, что текущие выполняющиеся процес сы мигрируют с это г о узл а. Нужно подчеркну т ь, что алгори тм не предна з н а ч е н для рабо ты с процес с ом, большим, чем объём устано в л е нной памяти на любом отдел ьно взя т ом узл е. В этом разд е л е мы рас смот рим эмуляцию нескол ь ки х ал гори тмов для размещения проце с с о в в SCC, включая Round-robin (цикличе с кий), Best-fit (лучшего соотв е т с т в и я) и нескол ь к о адапти вных схем. Далее буде т пока з а н о, что Round-robin в комбинации с миграцией проце с с о в приносит наилучшие резу л ь т а ты среди всех эмулиру емых ал гори тмов, подтв е ржда я резу л ь т а ты [BAL1]. Так же изв е с т н о, что эта комбиниров а нн а я схема хорошо масштабиру е т с я вмес т е с размером кла с т е р а . На основ е этих резу л ь т а т о в реали з о в а н ал гори тм распр е д е л е ни я памяти для openMosix. Показ а н а также взаимос в я з ь это г о ал гори тм а с ал гори тмом балансиро в ки нагру з ки, который также явл я е т с я час т ью общей политики разд е л е ни я ресур с о в. Произв е д ённые измер ения ал гори тм а пока зыв ают уменьшение времени выполнения тес т о в на 175%.

2.4.1. Чем полезен алгоритм распределения памяти Существу е т нескол ь к о алгори тмов назна ч е ния проце с с о в на узлы SCC. Статич е с к о е назн а ч е ни е исполь з у е т предопре д е л ё нную схему распр е д е л е ни я внов ь прибывших проце с с о в, не исполь з у я никакой информации времени выполнения. Динамиче с ко е размещение, напро ти в, испол ь з у е т сис т емную информацию о сос т о янии на момент назн ач е ни я. Для обоих методов, если процес с назна ч е н, он ост а ё т с я на узл е назна ч е ния до за в е ршения выполнения. В противопол оженнос т ь выше ска з а нн ому, алг о ри тмы адап тивно г о ра змещения процес с о в перен а з н а ч ают процес сы между узл ами в отве т на изменение сос т о я ния сис т емы. Формально проблема распр е д е л е ни я между узл ами может быть опред е л е н а следующим обра з ом: для данног о набора проце с с о в с изв е с т ными ра змер ами памяти, временем прибытия и выполнения, расположить максимально е число процес с о в в основной памяти всех узлов. Целесооб р а з ным явля е т с я изб ежание своппинг а наскол ь к о возможно, поскол ь к у дос туп к странице на диске на четыре порядк а медленне е, нежели дост уп к страниц е основной памяти. Проблема может иметь дос т а т о ч н о много вариаций в за ви симос ти от

32 порядк а прибытия и расположения проце с с о в, требов а ний на время выполнения, и т.п. К сожалению, в большинств е случа е в проблема явл я е т с я NPтрудной.

2.4.2. Эмуляция алгоритмов распределения процессов В каждом случ а е будем измеря т ь максимал ьно е заполнение памяти в тот момент, когд а ал гори тм отк а зыв а е т, то ест ь процент исполь з у емой памяти в момент, когд а алг ори тм не может разме с т и т ь следующий проце с с в посл ед о в а т е л ь н о с т и в основной памяти любых узлов назна ч е ни я. Предположим, что любой проце с с не меняе т с я во время свое г о выполнения. Это справ е д л ив о, так как наблюдения пока зыв ают, что большинст во процес с о в дости г ают боле е менее фиксиров анно г о размер а чере з коро т кий период после за г р у з к и и инициали з а ции . Любые значи т е л ь ные изменения размер а проце с с а могу т быть рас смотр е ны как зав е ршение одного процес с а и инициация дру го г о. Следов а т е л ь н о, данный ал гори тм выполняе т с я только по прибытии нового процес с а. Решение о местоположении не за ви с и т от неиз в е с т н о г о оста вшег о с я времени выполнения проце с с а. Поэтому предположим, что время выполнения процес с а бескон ечно. Для дальн ейшего упрощения ситу ации также предположим, что: •

ра змер процес с а изв е с т е н во время прибытия

•

проце с сы назна ч аютс я в порядк е свое г о прибытия

•

проце с с не может быть ра зби т между нескол ь кими узл ами

•

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

Эмулируемое окружение сос т ои т из некот оро г о числ а узлов с 128Мб памяти. Новые проце с сы прибывают согл а с н о случ айно предопре д е л ё нной посл ед о в а т е л ь н о с т и. Размеры процес с о в выбираются с распре д е л е ни ем p  x =e−x , со средним ра змером от 1Мб до 16Мб.

33

2.4.3. Статическое и динамическое размещение процессов

На рис. 8 пред с т а в л е ны ре зу л ь т а ты эмуляции этих трёх ал гори тмов размещения для набора проце с с о в со средним размером 1Мб. Этот набор эмулиру е т распр е д е л е ни е проце с с о в по сер в е р ам за месяц на реал ьной сис т ем е. Резу л ь т а ты пред с т а в л е ны для воз р а с т ающего по лог а рифмиче с к ой шкале числ а узлов. Каждое измерение пред с т а в л я е т собой средн е е по 500 различным запу с к ам.

Ис по л ь з о в а ние па мя т и (%)

Провед ём эмуляцию трёх ал гори тмов распр ед е л е н и я проце с с о в. Основным мотивом явля е т с я раскрытие повед ения каждого алгори тма, когд а общекла с т е р н а я памят ь почти исполь з о в а н а, и созд аютс я новые проце с сы. Первый ал гори тм – это цикличе с к о е размещение (Round-robin; RR), например, как в PVM. Второй – схема лучшего соот в е т с т в и я (Best-fit; BF), в которой новый процес с назн ач а е т с я на узе л с большим объёмом свободной памяти. Третий ал го ри тм исполь з у е т политику цикличе с к о г о размещения с посл ед ующим соот в е т с т в и ем (Round-robin Next-fit; NF), в которой все узлы сканируютс я цикличе с к им обра з ом, и процес с назн а ч а е т с я на первый же узел, который имеет дос т а т о ч н о свободной памяти. Можно также было рас смот р е т ь и политику перво г о соот в е т с т в и я (First-fit; FF). Тем не менее, так как эт а политик а имеет тенд енцию неравномерно распре д е л я т ь нагру з к у, его нель з я счит а т ь реалис ти чной аль т е рн а т и в ой.

Чис л о у з л о в

Рис. 8. Производи т е л ь но с т ь ал гори тмов ра змещения процес с о в

Их рисунка видно, что NF имеет заполнение памяти, близ ко е к оптимал ьному, для любого числ а узлов. Это может быть объясн ено его гибко с т ью пропус к а т ь узлы, которые истощили всю свою свободную памят ь. Соотве т с т в ующие резу л ь т а ты для алг ори тма RR пока зыв ают уменьшение максимально г о заполнения памяти с 93% для четырёх узлов до 80% для 512 узло в. Причиной таких низких знач ений явл я е т с я то, что RR ал го ри тм отк а зыв а е т, как только он получа е т процес с, не вмещающийся в памят ь следующего узл а. Можно наблюдат ь также, что произ в оди т е л ь н о с т ь RR пада е т линейно по лога рифмичес к ой шкале. Производи т е л ь н о с т ь ал гори тма BF нескол ь к о ниже, чем NF, с лога рифмичес ким отс т а в а н и ем до 4% от NF. Поведение BF может быть объясн ен о тем фактом, что этот ал гори тм имеет тенденцию распре д е л я т ь память равномерно между всеми узл ами. Следов а т е л ь н о, он откажет боле е веро я тн е й, чем NF, когд а прибывае т большой процес с, всё ещё получа я большую выгоду от свободы дейс т в ий, чем RR. Для то го, чтобы подчеркну т ь уменьшение произ в оди т е л ь н о с т и RR и BF ал го ри тмов, вспомним, что размеры проце с с о в выбираются случайным обра з ом

34 из фиксиров анно г о распре д е л е ни я с зад анным средним ра змером. Следова т е л ь н о, с ростом числ а узлов пропорциона л ьно увеличив а е т с я объём кла с т е р н ой RAM, таким обра з ом, требу я созд а ни я большего числ а процес с о в для то го, чтобы заполнит ь эту память. Тем не менее, соз д ание проце с с о в подра з уме в а е т , что число больших проце с с о в также увеличи т с я. Эти большие процес сы боле е трудно разме с т и т ь , что, соот в е т с т в е н н о, явл я е т с я гла вной причиной отка з а этих двух ал гори тмов.

Ис по л ь з о в а ние па мя т и (%)

Ис по л ь з о в а ние па мя т и (%)

Для того, чтобы выделит ь эти посл едни е наблюдения, съэмулиру ем те же самые три ал гори тм а размещения, исполь з у я средние размеры процес с о в 8 и 16Мб. Отметим, что такие ра змеры проце с с о в могу т отражат ь научные вычислит е л ь ные среды. Резу л ь т а ты эмуляции пока з а ны на рис. 9. На рисунке пока з а н о, что произ в оди т е л ь н о с т ь ал гори тма RR уменьшилас ь с 75% до 40% для средн е г о ра змер а проце с с а 8Мб и до 20% для средне г о размер а процес с а 16Мб. Соотв е т с т в ующая произ в оди т е л ь н о с т ь ал гори тма NF ост а л а с ь в районе 95% для 8Мб, и пост е п е нно уменьшилас ь с 90% до 85% для 16Мб.

Чис л о у з л о в

а ) Сре дний ра з ме р проце с с а 8Мб

Чис л о у з л о в

б) Сре дний ра з ме р проце с с а 16Мб

Рис. 9. Производи т е л ь н о с т ь ал гори тмов ра змещения проце с с о в с большим средним размером проце с с а Сравнение ре зу л ь т а т о в на рис. 8 и рис. 9 дока зыв а е т наше утве рждение что, чем больше созд а ё т с я больших процес с о в, чем боле е увеличив а е т с я спад произ в о ди т е л ь но с т и RR и BF ал гори тмов по мере увелич ения числ а узлов.

2.4.4. Адаптивное размещение процессов Далее будем тес ти ро в а т ь вариацию RR ал гори тма, исполь з ующего адап тивно е размещение процес с о в, называ емо г о “мигрирующий наименьший процес с” (Migrate the Smallest process; MS). Алгоритм MS цикличе с ки сканиру е т узлы и все г д а помещает процес с на следующий узел. В отличие от RR, если на узл е зак а нчив а е т с я память, то MS мигриру е т некоторый проце с с с это г о узл а. Выбранный проце с с явл я е т с я наименьшим среди всех проце с с о в, которые дост а т о ч но велики, чтобы аннулиров а т ь переполн ени е памяти, вызванно е прибывшим процес с ом, и может быть размещён на некотором дру гом узл е. Согла сно этому, миграция подве р г а е т се т ь наименьшим за т р а т ам. Если тако г о проце с с а не сущест ву е т (потому что все проце с сы слишком велики или все дру гие узлы переполнены), то алгори тм отка зыв а е т .

Ис по л ь з о в а ние па мя т и (%)

Ис по л ь з о в а ние па мя т и (%)

35

Чис л о у з л о в

а ) Сре дний ра з ме р проце с с а 8Мб

Чис л о у з л о в

б) Сре дний ра з ме р проце с с а 16Мб

Рис. 10. Произво ди т е л ь но с т ь алгори тмов MS и NF На рис. 10 пока з а ны эмуляции ал гори тмов NF и MS со средним размером процес с а от 8Мб до 16Мб. Отметим, что для средне г о размера процес с а в 1Мб произ в о ди т е л ь но с т ь обоих ал гори тмов близ к а к 100% заполнению памяти. Из рис. 10 а) видно, что произ в од и т е л ь н о с т ь MS от 3% до 4% выше, чем NF. Можно наблюдат ь также, что произ в оди т е л ь н о с т ь ал гори тм а MS увеличив а е т с я с числом узлов и не изменя е т с я для ал гори тма NF. Это может быть объяснено большим выбором процес с о в для миграции для MS при увелич ении числ а узло в. Улучшенная масштабиру емос т ь MS подчёркну т а при эмуляции со средним размером процес с о в 16Мб на рис. 10 б). Отметим, что также были провед е ны иссл е д о в а ни я двух вариан то в ал го ри тмов NF и MS, в которых выбранный проце с с помещался на узел с наибольшим объёмом свободной памяти. Тем не менее, оба вариан т а пока з а л и намного худшую произ в оди т е л ь н о с т ь и большее уменьшение произ в о ди т е л ь но с т и при увелич ении числ а узлов.

2.4.5. Масштабируемый алгоритм размещения с децентрализированным управлением Все выше описанные ал гори тмы исполь з о в а л и центр а л и з ир о в а нные схемы, которые пола г а л и с ь на глоб а л ь н ую информацию для приняти я решения о размещении. Эти центр а ли з ир о в а нные механи змы не масштабиру емы и не могу т быть эффективно реали з о в а ны на кла с т е р а х с большим числом узлов. Упрощённая децент р а л и з и р о в а н н а я схема для размещения процес с о в может основыва т ь с я на алгори тм е MS, в которой мигриру емый процес с ра змещае т с я на узл е, выбранным из информационно г о окна (см. гл. 2.1). Существ е нными парамет р ами это г о ал гори тм а являютс я ра змер окна и час т о т а рас с е и в а ни я информации. Эмуляция вышеописанной схемы, называ емой “оконный MS”, пока з а н а на рис. 11.

Ис по л ь з о в а ние па мя т и (%)

Ис по л ь з о в а ние па мя т и (%)

36

Чис л о у з л о в

Чис л о у з л о в

а ) Сре дний ра з ме р проце с с а 1Мб

б) Сре дний ра з ме р проце с с а 8Мб

Рис. 11. Производи т е л ь но с т ь оконно г о MS ал гори тм а для ра з личных размеров окна Показ а ны ре зу л ь т а ты для размеров окон с 8, 16 и 32 элемент ами. Как и ожидало с ь, произ води т е л ь н о с т ь пада е т при увелич ении числ а узлов и при уменьшении ра змер а окна. Это происходи т из- за огранич е нно с т и информации, дост упной ал гори тму, что препя т с т в у е т глоб а л ь н ой оптимиз ации. Несмотря на уменьшение произ в оди т е л ь н о с т и, ал гори тм работ а е т хорошо: более чем 96% запо лн ени е памяти для проце с с о в со средним ра змером 1Мб, и боле е 90% для 8Мб процес с о в вплоть до 32 узлов. Алгоритм лег ко реали з у ем и не требу е т никакой глоб ал ь ной информации.

2.4.6. Реализация алгоритма распределения памяти В этом ра зд е л е буду т рас смотр е ны дета л и реали з а ции ал гори тма распр е д е л е ни я памяти в сис т ем е openMosix. Этот алг ори тм отве т с т в е н е н за приняти е решений кас а т е л ь н о миграции процес с о в с узл а, исчерп а вшег о свою свободную память, так же как и предот в р ащение миграции на это т узел. Этот ал го ри тм должен решать, какой процес с мигриров а т ь , когд а его мигриров а т ь , и где его разме с ти т ь. В дополнени е к этому, ал гори тм должен решать, позв о ли т ь ли удал ённым проце с с ам мигриров а т ь на этот узе л из- за истощения памяти на других узл ах. Для достижения решения ал гори тм испол ь з у е т индекс свободной памяти, обесп е чив а емый ал гори тмом рас с е и в а ни я информации. Этот индекс ес т ь объём измеренной свободной памяти узл а, который может быть распре д е л ё н между удал ёнными проце с с ами. Строго говор я, это ес т ь сумма дейс т в и т е л ь н ой свободной памяти за вычетом порог о в о г о знач ени я свободной памяти, то ес т ь памяти, зар е з е р в и р о в а нн ой для локал ь ных процес с о в и памяти, уже перед а нной прибываемым процес с ам. Это знач е ние замер я е т с я нескол ь к о ра з в секунду для ослаб л е ни я кра тк о в р ем енных флукту аций. Индекс свободной памяти рас сыла е т с я чере з периодиче с к и е интер в а лы другим узл ам, исполь з у я вероя т н о с т ный алгори тм рас с еи в а ни я информации. Последний ал гори тм предна з н а ч е н для того, чтобы обесп ечи т ь каждый узел дос т а т о ч н ой информацией о дост упных ресур с а х на дру гих узл ах, бе з провед е ни я опрос а или довери я удал ённой информации (см. [BAR3]). Ниже рас смот р е ны

основные

час ти

алгори тм а

распр е д е л е ни я

памяти:

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

2.4.7. Активизация алгоритма Алгоритм распр ед е л е н и я памяти сраб а тыв а е т, когд а свободна я память узл а станови т с я ниже порогов о г о знач ени я, что может вызва т ь выгру з к у ценных страниц памяти. Порогово е знач ени е – это объём памяти, зар е з е р в и р о в а нной для локал ьных проце с с о в в то время, как принимае т с я решение о выборе и миграции проце с с а. В идеал е, объём зар е з е р в и р о в а нной памяти должен быть динамиче с ким знач е нием, которо е соот в е т с т в у е т час т о т е распр е д е л е ни я свободной памяти. Это знач ени е должно увеличив а т ь с я, когд а увеличив а е т с я интенсивно с т ь распре д е л е ни я стр аниц и наоборо т, чтобы быть уверенным, что алг ори тм распр е д е л е ни я памяти выбере т и, если необходимо, мигриру е т проце с с перед тем, как срабо т а е т процес с выгру з к и страниц. В то же время, размер зар е з е р в и р о в а нн ой памяти не должен быть слишком большим. Это нужно для избежания ранних и ненужных миграций проце с с о в с узл а, а также блокиров ки миграций на узе л. В нас то ящей реали з а ц ии порог о в о е знач ени е уст ано в л е н о в фиксиров анную величину: на 1/4Мб больше уровня сраб а тыв ания механи зма выгру з ки стр аниц.

2.4.8. Выбор процесса Выбор проце с с а для миграции проходит в нескол ь к о эт апо в в за ви симос ти от объёма недос т ающей памяти (переполн ения) и объёма свободной памяти на дру гих узл а х. Прежде все г о, выясня е т с я размер переполнения как разно с т ь между нас т о ящими требов а ниями к памяти и дост упной памятью. Значение переполнения памяти наблюдае т с я и обновл я е т с я регу л ярн о для опред е л е ни я то г о, явл я е т с я ли это кра тк о в р ем енным явл ением или посто янным. На первой стадии проце с сы сортируютс я по числу своих “гря зных” стр аниц. Выбирае т с я проце с с с наименьшими за т р а т а ми на миграцию из числа процес с о в, для которых число “гря з ных” страниц превышает знач ени е переполнения. Если эт а стади я за в е ршае т с я неудач ей, то ли из- за отсу т с т в и я узл а с дост а т о ч ным объёмом свободной памяти для предо с т а в л е н и я выбранному процес с у, то ли потому что все процес сы высылающего узл а меньше знач ени я переполн ени я памяти, то алго ри тм перехо ди т ко второй стадии. На второй стадии алгори тм пытае т с я мигриров а т ь наибол ьший возможный процес с, который ра змещае т с я на удал ённом узл е, не за с т а в л я я тот узе л превысит ь своё порого в о е знач ение памяти. Сначал а алг ори тм выбира е т узе л с наибол ьшим изве с т ным индек сом свободной памяти. Потом он находит наибольший проце с с, который помещает с я на это т узе л. Потом алго ри тм прове р я е т, помес ти т с я ли выбранный проце с с в память других узлов. Среди

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

наименьший нагру з к ой и мигриру е т доступн а я свободн а я память всё ещё ждёт некоторо е время для прибытия воз в р ащае т с я к первой стадии. В

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

39

3. МАСШТАБИРУЕМЫЕ КЛАСТЕРНЫЕ ФАЙЛОВЫЕ СИСТЕМЫ OPENMOSIX ДЛЯ LINUX 3.1. Задачи кластерных файловых систем Недавние успехи в клас т е р ных вычисл ени ях и способно с т и ген ериро в а т ь и мигриров а т ь парал л е л ь ные проце с сы на нескол ь к о машин со зд а л и потр ебно с т ь ра зр а б о т ки масштабиру емых кла с т е рных файловых сис т ем, которые не тольк о поддерживают паралл е л ь ный доступ ко многим файлам, но также и сог л а с о в а н но с т ь кэшей между проце с с ами, которые обращаются к тому же самому файлу. Наиболе е традиционные се т е вые файловые сис т емы типа NFS, AFS и Coda не отвеч ают требов а ни ям паралл е л ь ной обрабо т ки, потому что они за ви с я т от центр а л ь ных файловых серв е р о в. Новое покол ение файловых сист ем, типа GFS, xFS и Frangipani, соот в е т с т в уют клас т е р ам в большей степе ни, потому что эти сис т емы распре д е л яют памят ь, кэш и управл е ни е между ст анци ями клас т е р а, а также обесп е чив ают сред с т в а для паралл е л ь н о г о доступ а к файлу и сог л а с о в а н но с т и кэшей. Масштабиру емос т ь этих файловых сис т ем всё ещё не изве с т н а. В этом раз д е л е рас см а т рив а е т с я новый пример для масштабиру емых клас т е р ных вычисл ений, который объединя е т клас т е р ные файловые сис т емы с динамичес к им распре д е л е ни ем зад аний. Целевой кла с т е р сос т ои т из множест в а гомог енных узлов (с одним CPU и/или SMP компьютеров), которые работ ают совме с т но, позвол я я общим ресу р с ам клас т е р а быть дос тупными каждому проце с с у, и дел а я возможным любому узлу обра ти т ь с я к любому файлу или выполнит ь любой процес с. Класт е р н а я файлов а я сис т ем а сос т ои т из нескол ь к их поддер е в ь е в, которые размещены на ра зличных узл а х, чтобы раз р ешить паралл е л ь ные операции с различными файлами. Главна я особ енно с т ь в диз айне кла с т е рных файловых сис т ем – способно с т ь мигриров а т ь проце с с к файлу вмес т о того, чтобы традиционным способом перен е с т и данные файла к процес с у. Эта возможнос т ь, котор а я уже поддержива е т с я openMosix для Linux для балансир о в ки нагру з к и, созд а ё т новый подход в клас т е рных вычисл ениях, который обеспе чив а е т “удобную для исполь з о в а ни я” среду для улучшения произ в о ди т е л ь но с т и и масштабиру емос ти. Обратим внимание на то, что большинств о сущест в ующих паке т о в для распр е д е л е ни я работ, такие как PVM или MPI, не соот в е т с т в уют нашим требов а ни ям, потому что они испол ь з уют ста ти ч е с к о е (фиксиров анно е) распр ед е л е ни е проце с с о в по узл ам. openMosix особ енно эффектив е н для распр е д е л е ни я и выполнения процес с о в, огр анич енных только испол ь з о в а н и ем CPU (CPU-limited jobs). Однако из- за совме с т имос т и с Linux, схема openMosix распре д е л е ни я проце с с о в была неэффек тивн а при выполнении процес с о в с существ е нным количе с т в ом опер аций ввод а- вывода и/или файловых операций. Для преодол ения этой неэффек тивно с т и openMosix был расширен поддержкой DFSA для лучшей обрабо т ки процес с о в, огранич енных только операциями ввод а- вывода (I/O

40 limited jobs). С DFSA большинст в о сис т емных вызовов мигриров а вшег о проце с с а, ориентир о в а нно г о на ввод- вывод, может быть выполнено локал ь но – на узл е, гд е это т процес с в нас то ящее время расположен. Основное преимуществ о DFSA сос т ои т в том, что она позвол я е т проце с с у с умеренным или большим объёмом ввода- вывода мигриров а т ь на узе л, на котором он выполняе т большинст во операций ввод а- вывода, и воспол ь з о в а т ь с я преимуществом локал ьно г о дос тупа к данным. Друго е преимуществ о – уменьшение накл а дных расход ов на взаимодей с т в и е, таких как меньшее количе с т в о операций ввод а- вывода, произ в од ящихс я по се ти. Для правил ьной работы DFSA требу е т с я согл а с о в а н но с т ь каждого файла между проце с с ами, работ ающих на ра з личных узл ах, которую в наст о ящее время обе сп ечи в ают толь ко нескол ь к о файловых сис т ем. Одна така я файлова я сис т ем а – GFS, которую планиру е т с я испол ь з о в а т ь , как только она стане т полнос т ью работ о с по с о б ной. В каче с т в е другой аль т е рн а т и вы ра зр а б о т а н прото тип файловой сист емы, называ емой oMFS, котор а я рас см а т ри в а е т все файлы и кат а л о г и в преде л а х клас т е р а openMosix как единую файловую сис т ему. Интере сн ой иссл е д о в а т е л ь с к о й пробл емой явля е т с я проблема, гд е разме с ти т ь проце с с, когд а он выполняе т операции ввод а- вывода с файлами, расположенных на различных узл ах. Простое решение сос т ои т в том, чтобы мигриров а т ь проце с с к узлу, для которо г о выполнено большинст во опер аций ввод а- вывода. Эта пробл ема нескол ь к о усложняе т с я, если также хоче т с я сбал ан с иро в а т ь нагру з к у, или если модели операций ввод а- вывода изменяютс я во времени, или когд а вовл е ч е н о нескол ь к о проце с с о в. Адаптивн а я политик а распре д е л е ни я процес с о в openMosix пытае т с я разр ешить все это случаи.

3.2. Файловая система прямого доступа (DFSA) 3.2.1. Принцип работы DFSA DFSA – прогр аммное обесп е ч е ни е, которо е решает, выполнить ли сист емные вызовы файловых операций ввод а- вывода мигриров а вшег о проце с с а на текущем узл е или на его домашнем узл е. Для корре к т но г о функциониров ани я DFSA требу е т, чтобы выбранные файловые сис т емы (и символиче с ки е ссылки) были идентично смонтиров аны на одноимённые точки монтиров ани я. Кроме то г о подра з ум е в а е т с я , что схема идентифика т о р о в поль з о в а т е л е й/ г р у пп явл я е т с я или идентичной по всему клас т е р у, или дост а т о ч но безопа с но й, чтобы не возник а л о никаких нарушений прав доступ а, когд а к одной и той же файловой сис т ем е обращаются поль з о в а т е л и с идентифика т о р ами, назна ч енными на ра зличных узл ах. DFSA провер я е т, что данные файловые сис т емы смонтиров а ны с теми же самыми флагами монтиров а ния, и их типы поддерживаютс я DFSA. Тогда она перенапр а в л я е т большинст в о обращений к операционной сист еме для

41 выполнения локал ьно (на текущем узл е), в то же время всё ещё напр ав л я я неко то рые (сомнител ьные) сис т емные вызовы, например, при совмес тном испол ь з о в а н ии открытых файлов с другими проце с с ами, к домашнему узлу процес с а. DFSA непрерывно синхрони зиру е т сос т о яни е файла, например, открытие, закрытие, позицию в файле и т.д. между мигриров а вшим процес с ом и его домашним узлом.

3.2.2. Требования DFSA DFSA может работ а т ь с любой файловой сис т емой, котор а я удовл е т в о р я е т следующим свойс т в ам: •

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

•

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

•

Файлова я сис т ем а должна гар ан т иро в а т ь, что файлы/кат а л о г и не освобождаютс я при удал ении до тех пор, пока существ у е т проце с с в кла с т е р е , который держит их открытыми. Есть нескол ь к о возможных методо в для достижения это г о, например, некот ор а я модель сборки “мусор а”.

•

Поддержка нескол ь ки х дополнит е л ь ных функций файловой сис т емы, которые в Linux считаютс я операциями с супер- блоком, например, “идентифициров а т ь” – сформиров а т ь конечную идентификационную информацию по “d-вхождению (dentry)” таким обра з ом, чтобы её было дост а т о ч но для вос с т а н о в л е ни я это г о открыто г о файла/ка т а л о г а на дру гом узл е.

Поддерживаютс я следующие сис т емные вызовы, которые могу т выполнены локал ьно, без миграции процес с а на домашний узе л (UHN):

быть

read, readv, write, writev, readahead, lseek, llseek, open, creat, close, dup, dup2, fcntl, fcntl64, getdents, getdents64, old_readdir, fsync, fdatasync, chdir, fchdir, getcwd, stat, stat64, newstat, lstat, lstat64, newlstat, fstat, fstat64, newfstat, access, truncate, truncate64, ftruncate, ftruncate64, chmod, chown, chown16, lchown, lchown16, fchmod, fchown, fchown16, utime, utimes, symlink, readlink, mkdir, rmdir, link, unlink, rename В следующих ситу аци ях сист емные вызовы на смонтиров а нной с поддержкой

42 DFSA файловой сис т ем е могут не работ а т ь : •

ра з личн а я конфигур ация неко то рых не включена ра з личными опциями)

MFS/DFSA на узл а х клас т е р а (например, на поддержка DFSA или MFS смонтиров а н а с

•

dup2() вызывае т с я со вторым файловым дескрип т ором вне поддер е в а DFSA

•

вызов chdir()/fchdir() в случа е, если родите л ь с к ий кат а л о г не DFSA

•

пути выходя т за пред елы поддер е в а DFSA

•

проце с с, дел ающий сис т емный вызов из привед ённо г о находит с я в сос т о я нии отлад ки/тр а с с и р о в к и

выше

списк а,

3.3. Файловая система openMosix (oMFS) openMosix требу е т согл а с о в а нно с т и файлов и кэшей между процес с ами, которые выполняются на ра зличных узл а х, поскол ь ку может ока з а т ь с я , что даже один и тот же проце с с (или группа вз аимод ейс т в ующих свя з а нных процес с о в) опериру е т с ра з личных узлов. Чтобы воспол ь з о в а т ь с я DFSA, был реали з о в а н прототип файловой сист емы, называ емой файловой сист емой openMosix (oMFS). oMFS обе сп е чи в а е т унифициров анно е пред с т а в л е ни е всех файлов на всех устано в л е нных файловых сис т ем ах (любого типа) на всех узл а х клас т е р а openMosix, как будто они все наход я т с я в пред ел а х единс т в е н ной файловой сис т емы. Например, если MFS смонтиров а н а на точку монтиров ани я /mfs, то файл / mfs/1456/usr/tmp/myfile относи т с я к файлу на узл е #1456. Это дел а е т oMFS и универ с а л ь ной, так как /usr/tmp может иметь любой тип файловой сис т емы, и масштабиру емой, так как каждый узел в клас т е р е openMosix потенциа л ь н о и сер в е р, и клиен т. В отличие от других файловых сис т ем, oMFS обесп ечив а е т согл а с о в а нн о с т ь кэшей, поддержива я тол ько один кэш – на серв е р е. Чтобы реали з о в а т ь это, станд а р т ные кэши дисков и дирек то рий Linux исполь з уютс я тольк о на серв е р е и игнорируются на клиент а х. Основное преимущест в о тако г о подход а сос т ои т в том, что это обеспе чи в а е т прос т ую, всё ещё масштабиру емую схему со гл а с о в а н но с т и кэшей между любым числом процес с о в. Другое преимуществ о подход а oMFS сос т ои т в том, что она позв ол я е т поднят ь клиент- серв е р но е взаимод ей с т в и е на уровен ь обращений к операционной сис т ем е, который явл я е т с я лучшим для боле е общих, больших и сложных операций ввод а- вывода (открытие файлов, ввод- вывод блоков большого размера). Очевидно, отсу т с т в и е кэша на клиент е – гл а вный недос т а т о к для операций ввод авывода с блоками меньшего размер а.

43

3.4. Производительность Этот разд е л демонс триру е т произ в оди т е л ь н о с т ь , полученную при испол ь з о в а н и я DFSA. Так как DFSA – не файлова я сист ем а, то её можно оценить, сра внив а я произ в оди т е л ь н о с т ь MFS с и бе з DFSA. Для сра вн ени я также оценены произ в оди т е л ь н о с т ь локал ьных операций ввод а- вывода и NFS. Исполь з о в а л с я тес т PostMark, который моделиру е т тяжёлые нагр у з к и файловой сист емы, например, как на большом серв е р е эле к т р онной почты Internet. PostMark соз д а ё т большой пул тек с т о вых файлов произ в ол ь н о г о размер а и за т ем исполня е т множеств о тран з а к ций, гд е каждая тран з а к ций сос т ои т из пар меньших тран з а к ций. Это выполня е т с я до тех пор, пока не буде т получен а предопред е л ё н н а я рабоч а я нагру з к а. Все запу с ки были выполнены на клас т е р е с openMosix 2.4.18 для Linux. Тест был выполнен между парой идентичных (Pentium 550 MHz PC с дисками IDE) машин, исполь з у я 4 различных метод а дост уп а к файлу и ра змеры блоков пред ел а х от 64б до 16Кб. Резу л ь т а ты те с т а пока з а ны в таблице 5, гд е каждое измер ение пред с т а в л я е т собой средне е время 10 запу с к о в в секунд а х. Первая строк а в таблице пока зыв а е т время выполнения на локал ьной машине, при котором процес с и файлы были на серв е рном узл е. Вторая строк а пока зыв а е т время MFS с DFSA. В этом случа е те с т, запущенный на клиент с к ом узл е, мигриров а л на узел серв е р а. Треть я строк а пока зыв а е т время NFS между клиент с к им узлом и серв е рным узлом. Последня я строк а пока зыв а е т время MFS без DFSA, в котором все файловые операции были выполнены с клиент с к о г о узл а к узлу сер в е р а чере з MFS с забл окиров а нной DFSA. Метод доступа

Размер блока данных при передаче 64б

512б

1Кб

2Кб

4Кб

8Кб

16Кб

Локал ьный (на серв е р е)

102.6

102.1

100.0

102.2

100.2

100.2

101.0

MFS с DFSA

104.8

104.0

103.9

104.1

104.9

105.5

104.4

NFS

184.3

169.1

158.0

161.3

156.0

159.5

157.5

MFS бе з DFSA

1711.0

382.1

277.2

202.9

153.3

136.1

124.5

Таблица 5. Резул ь т а ты тес т иро в а н и я PostMark Из таблицы 5 следу е т, что время выполнения MFS с DFSA на 1.8-4.9% медленне е, чем время локал ьно г о выполнения для каждого из измер енных размеро в блоков, и со средним замедл е нием 3.7% для всех измеренных размеро в блоков. Также время выполнения MFS с DFSA на 51-76% быстре е, чем NFS, со средним ускор ением 59% для всех измеренных размеров блоко в. Заметим, что NFS на 56-80% медленне е, чем локал ь н а я файлов а я сист ем а. Как ожидало с ь, MFS без DFSA (четв ё р т а я строк а) медленне е, чем NFS для малень ких размеров блоков. Однако, для ра змеров блоков 4КБ и больше, MFS имеет лучшую произ в оди т е л ь н о с т ь , чем NFS. Это дел а е т MFS раз умной аль т е р н а т и в ой для клас т е р н ой файловой сист емы, котор а я поддержива е т

44 со гл а с о в а н но с т ь кэшей. В таблице 6 пока з а н о, что “DFSA+MFS” имее т произ в оди т е л ь н о с т ь , сра внимую с “Local FS” (при тес тиро в а н ии исполь з о в а л с я подходящий файл размером 1Гб, буфериз ация чтения/ з а пи си включена). Тип

Последоват ельный вывод (блочная запись) (Кб/с )

Последоват ельный ввод (блочное чтение) (Кб/с )

Local FS

22155

27476

NFS

10176

9372

MFS

8203

8235

DFSA+MFS

21997

28176

Таблица 6. Производи т е л ь н о с т ь согл а с н о тес т ам Bonnie Второй тес т пока зыва е т выполнение файловых операций ввод а- вывода между множест вом клиент с к их проце с с о в, каждый из которых выполня е т на своём собс т в е нном узл е паралл е л ь н о е файлово е приложение, которо е взаимод ей с т в у е т с общим файловым серв е р ом. Боле е опред ел ённо, эт а паралл е л ь н а я прогр амма чита е т общую баз у данных ра змером 200Мб из Рис. 12. Средне е время считывания общего опер а ти в ной памяти файла с четырёхпроце с с о р но г о файлово г о четырёхпроце с с о рн о г о (Xeon серв е р а 550 МГц) файлово г о серв е р а. Приложение было запущено на различных файловых сис т ем ах, как пока з а н о на рис. 12, исполь з у я размер блока 4Кб. Для сра вн ени я тес т был также выполнен локал ьн о на серв е рн ом узл е. Приложение было запущено одновр ем енно на всех узл ах (Pentium 550 МГц), и было зафиксиров ан о время, необходимое для за в е ршения посл едн е г о процес с а. Резу л ь т а ты это г о тес т а усреднены по трём ра зличным запу с к ам и пока з а ны на рис. 12. Из рисунка можно заме ти т ь, что время выполнения MFS с DFSA очень близко к локал ьному времени. Фактиче с ки, MFS с DFSA был в средн ем на 6% медленне е, чем локал ь н а я файлова я сис т ем а. Заметим, что эти накл адные за тр а ты возник ают из- за дополнит е л ь н о г о прогр аммного уровня в MFS. Из рисунка может также быть замеч ено, что NFS и MFS без DFSA почти идентичны, причём NFS обе сп е чи в а е т в среднем на 4% лучшую произ в оди т е л ь н о с т ь, чем MFS без DFSA. Из полученных рез ул ь т а т о в следу е т, что MFS с DFSA от 6.1 до 11.4 раз быстре е, чем NFS, и от 6.9 до 11.8 ра з быстре е, чем MFS без DFSA. Из этих резу л ь т а т о в ясно, что MFS с DFSA обесп е чив а е т лучшую

45 масштабиру емос т ь, чем NFS или MFS без DFSA.

3.5. Заключение Правильно е опериров а ни е этой схемы требу е т согл а с о в а нно с т и файлов между проце с с ами, которые работ ают на раз личных узл ах. Ещё одна подходящая файлов а я сист ем а для нашей схемы – глоб а л ь н а я файлова я сис т ем а (GFS), котор а я поз вол я е т множеств у узлов Linux совме с тн о испол ь з о в а т ь се т е вые устройс т в а для хранения. В GFS каждый узел видит се т е вые диски как локал ь ные, и сама GFS проявл я е т себя как локал ь н а я файлова я сис т ем а. Друга я привле к а т е л ь н а я особ енно с т ь GFS – то, что она испол ь з у е т современные интерфейсы, такие как оптовол оконный канал, для испол ь з о в а н и я присоединённых се т е вых устрой с т в хранения. Один из посл ед ующих проек т о в сос т ои т в том, чтобы приспос оби т ь GFS к openMosix и DFSA. Подобные расширения могли быть ра з р а б о т а ны для дру гих файловых сис т ем, которые удовл е т в о р яют треб ов а ния DFSA. Кроме того, было бы интере с но иссл е д о в а т ь сред с т в а комбиниров ани я MFS с локал ьными се т е выми устройс т в ами хранени я, чтобы обесп ечи т ь согл а с о в а н но с т ь и большее количе с т в о вариан т о в вз аимод ейс т в и я между масштабиру емым кла с т е р ом и устройс т в ами хранения.

46

4. МИГРИРУЕМАЯ РАЗДЕЛЯЕМАЯ ПАМЯТЬ 4.1. Цели проекта Целью проек т а явл яе т с я сдел а т ь возможным миграцию проце с с о в с явным разд е л е ни ем памяти и миграцию мультипо то к о вых приложений бе з поте ри произ в о ди т е л ь но с т и и с гар ан т иро в а нном сохран ени ем работо с по с об но с т и на клас т е р е openMosix. openMosix – это расширение ядра Linux, которо е предос т а в л я е т вычислит е л ь н о е клас т е р н о е окружение с автома тич е с к ой бал ан сир о в к о й нагру з ки между узл ами клас т е р а. Миграция проце с с о в с раз д е л я емой памятью не обраб а тыв а е т с я в текущей версии openMosix. Следова т е л ь н о, таки е приложения как Web серв е р а, серв е р а баз данных, некот орые инструменты ренд ерин г а, которые исполь з уют разд е л я емую память, не могу т получит ь выгоду от клас т е р а openMosix. Данный проек т преодол е в а е т это огранич ени е openMosix. При этом возможна миграция проце с с о в, которые явно исполь з уют разд е л я емую память посред с т в ом таких сис т емных вызовов, как shmget(), shmat() и shmctl(), так же, как и потоков, созд а нных с испол ь з о в а н и ем сис т емно г о вызов а clone(). Поддержание согл а с о в а нн о с т и ра зд е л я емой памяти, к которой обращаются проце с сы, распр ед е л ё нные по клас т е р у, обесп е чив а е т с я прозр а чной политикой согл а с о в а нн о с т и “желающего освобождени я” (“Eager Release” transparent consistency policy). В дополнени е сама разд е л я ем а я памят ь мигрируе т основыва я с ь на час т о т е испол ь з о в а н и я разд е л я емой памяти и нагру з к и по клас т е р у. Миграция раз д е л я емой памяти уменьшае т число удал ённых обращений к ней. Данная реали з а ци я позвол я е т миграцию Apache Web серв е р а на кла с т е р е openMosix, что было ране е нево зможно. В Linux раз д е л я ем а я памят ь реали з о в а н а двумя путями: •

Sys V разд е л я ем а я памят ь межпроцес сн о г о вз аимод ей с т в и я

•

потоки (легков е с ные проце с сы Linux)

4.2. Sys V разделяемая память Sys V раз д е л я ем а я памят ь – самое быстро е и самое удобное сред с т в о IPC. Она позв ол я е т двум и боле е проце с с ам получа т ь доступ к общим струк т у р ам данных, помещая их в се гмент раз д е л я емой памяти. Разд е л я ем а я памят ь реали з о в а н а как файл в вирту а л ь ной файловой сис т ем е памяти (tmpfs или бывшая shmfs). Разд е л я ем а я вызово в:

память

управл я е т с я

при

помощи

следующих

сис т емных

• shmget()

Функция shmget() вызыва е т с я для получени я идентифика т о р а IPC сегмен т а ра зд е л я емой памяти, опционал ьно созд а в а я его, если он не существ у е т.

47 • shmat()

Функция shmat() вызыва е т с я для присоединения се гмен т а ра зд е л я емой памяти к проце с с у. В каче с т в е параме тр а она получа е т идентифика т о р IPC и пытае т с я добави т ь регион раз д е л я емой памяти к адре сному прос тр ан с т в у вызывающего процес с а. Вызывающий процес с может за т р е б о в а т ь специфиче с кий ста р т о вый линейный адре с для ре гиона памяти, но обычно адре с не важен, и каждый проце с с, который получа е т дост у п к се гмен ту ра зд е л я емой памяти, может испол ь з о в а т ь отличный от дру гих адре с в своём адре сном прос тр а н с т в е. Таблицы страниц проце с с а ост аютс я неизменными посл е shmat(). • shmdt()

Функция shmdt() вызыва е т с я для отсо е динения се гм ен т а ра зд е л я емой памяти, зад анно г о своим идентифика т о р ом IPC, то ест ь для удал ения соо тв е т с т в ующего региона памяти из адре сно г о прос тр ан с т в а проце с с а. IPC ре гион разд е л я емой памяти явля е т с я посто я нным: даже если никакой проце с с его не исполь з у е т , соотв е т с т в ующие вирту а л ь ные страницы не могу т быть освобождены, хотя они могут быть выгружены в обла с т ь подкачки. • shmctl()

Функция shmctl() позвол я е т поль з о в а т е лю получит ь информацию о се гмен т е ра зд е л я емой памяти, устано ви т ь влад е л ь ц а, групповые прав а дост уп а, или ра з рушить се гмен т. Пользов а т е л ь должен убедит ь с я, что се гмент в конце концов раз рушен, иначе его страницы будут ост а в а т ь с я в памяти или в обла с ти подкачки. Страницы, добавл я емые к процес с у при shmat(), являютс я фиктивными; функция добав л я е т регион памяти к адре сному прос тр а н с т в у процес с а, но не изменяе т таблицы ст аниц процес с а. Поэтому когд а процес с пытае т с я получит ь доступ к адре с у се гмен т а разд е л я емой памяти, возник а е т “ошибка при обращении к странице”. Соотв е т с т в ующий обрабо т чик прерывания опред ел я е т, что сбойный адре с находи т с я внутри адре сно г о прост р а н с т в а процес с а, и соот в е т с т в ующая запис ь в таблице станиц проце с с а NULL; он вызывае т функцию do_no_page(). В свою очере д ь эта функция провер я е т, опред ел ён ли метод no_page() для это г о ре гион а памяти. Вызывае т с я это т метод, и запи с ь в таблице станиц уст ан а в л и в а е т с я в адре с, воз в р ащённый этим методом.

4.3. Легковесные и тяжеловесные процессы в Linux Потоки – это лег ко в е с ные проце с сы (light weight processes (LWPs)). Идея в том, что проце с с сос т ои т из пяти фундамент а л ь ных час т е й: код, данные, сте к, файловый ввод- вывод и таблица сигн ал о в. Тяжелов е сные проце с сы (heavy-weight processes (HWP)) имеют значи т е л ь ные накл а дные расходы при переключении между проце с с ами: все таблицы должны быть сброшены из проце с с о р а при каждом пере ключении. Также единс т в е нным способом достич ь разд е л е ни я информации между HWP явл я е т с я испол ь з о в а н и е канало в и ра зд е л я емой

48 памяти. Если HWP порождае т дочерний HWP исполь з у я fork(), единс т в е нной разд е л я емой час т ью явл яютс я данные. Потоки уменьшают накл адные расходы исполь з у я разд е л е ни е фундамент а л ь ных час т е й. При совмес т ном исполь з о в а нии этих час т е й перек лючение происходи т гор а з д о боле е эффективно. Существу е т два типа потоков: потоки прос тр а н с т в а поль з о в а т е л я и прос тр ан с т в а ядра.

P1

Куча родителя Регистры Указатель стека Указатель кода

Окна стека (поток1)

T1

Регистры Указатель стека Указатель кода

Окна стека (поток2)

T2

Код программы Глобальные/ статические

•

Потоки прос тр ан с т в а переменные поль з о в а т е л я (user-space threads) Рис. 13. Легков е с ные проце с сы (потоки) Простр ан с т в о поль з о в а т е л я не испол ь з у е т ядро и управл я е т таблиц ами самос т о я т е л ь н о. Часто это называ е т с я “коопер а т и вн ой много з а д а ч но с т ью”, когд а зад а ч а опред е л я е т набор подпро гр амм, на которые происходи т перек лючение при манипуляции ука з а т е л ем сте к а. Типично каждый поток отка зыв а е т с я от выполнения явно вызыва я переключение, посылая сигн ал или выполня я операцию, котор а я приводит к перек лючению. Пользов а т е л ь с к и е потоки обычно могу т пере ключа т ь с я быстре е, чем потоки ядра.

•

Потоки прос тр ан с т в а ядра (kernel-space threads) Потоки прост р ан с т в а ядра чаще все г о реали з уютс я в ядре, исполь з у я нескол ь к о таблиц (каждая зад а ч а получа е т таблицу потоков). В этом случа е ядро планиру е т каждый поток с тем же кван том времени, что и проце с с. При этом существ уют нескол ь к о большие накл адные расходы при пере ключении из конте к с т а поль з о в а т е л я в ядро и обра тн о и при за г р у з к е больших конте к с т о в, но первона ч а л ь ные измерения произ в оди т е л ь н о с т и пока з а л и ничтожное увелич ени е времени. Так как тик часов опред е л я е т время переключения, то менее вероя т но, что зад а ч а заб е р ё т кван т времени у дру гих потоков в пред е л а х зад а чи.

Linux поддержива е т мультипо т ок о в о с т ь сис т емный вызов clone():

прос т р а н с т в а

ядра,

испол ь з у я

int clone(int (*fn)(void *), void *child_stack, int flags, void *arg);

гд е fn – подпро г р амма поток а, child_stack – ука з а т е л ь на сте к потока, flags см. в man clone, arg – параме т ры, ожидаемые потоком clone() – это библиот е ч н а я

функция, в основ е которой лежит сист емный вызов clone(). Она исполь з у е т с я для реали з а ции нескол ь ких потоко в управл е ни я в прогр амме, которые выполняются одновр еменно в раз д е л я емом адре сном прос тр а н с т в е . Когда дочерний процес с порождае т с я при помощи clone(), она вызыва е т

49 функцию приложения fn(arg). Аргумент child_stack опред е л я е т местоположение сте к а, исполь з у емо г о дочерним потоком. Так как поток и вызывающий проце с с могу т раз д е л я т ь память, для дочерне г о потока нево зможно выполнение на том же сте к е, что и вызывающий процес с. Поэтому посл едний должен уст ано ви т ь обла с т ь памяти для дочерне г о сте к а и перед а т ь ука з а т е л ь на эту обла с т ь. Стек рас т ё т вниз, поэ тому дочерний сте к обычно ука зыва е т на самый верхний адре с облас т и памяти, уст ан о в л енной для дочерне г о ст ек а. Обычно он выделя е т с я из секции кучи родит е л ь с к о г о процес с а испол ь з у я malloc(). Функционал ьн а я диаг р амма На рис. 14 пред с т а в л е н а общая прогр аммная взаимод ей с т в и е между элемент ами сис т емы.

струк т у р а

migshm

и

Функционал ьно е описани е каждого модуля сис т емы: •

Миграция проце с с о в с ра зд е л я емой памятью Этот модуль позвол я е т проце с с у быть выбранным для миграции в любое время свое г о выполнения, до или посл е присоединения к региону ра зд е л я емой памяти.

•

Модуль взаимодей с т в и я Этот модуль управл я е т всей функционал ьно с т ью по взаимодей с т в ию между проце с с ами с ра зд е л я емой памятью, распр е д е л ё нных по ра з личным узл ам кла с т е р а .

•

Модуль согл а с о в а н но с т и Этот модуль поддержива е т согл а с о в а нн о с т ь между реплициров а нными стр аниц ами ра зд е л я емой памяти, существ ующих на ра зличных узл а х

•

Журналиров ани е обращений и решение о миграции Этот модуль управл я е т пере сылкой региона ра зд е л я емой памяти. Он также реали з у е т политику сбоя страниц.

•

Миграция потоков Этот модуль управл я е т миграцией LWP в клас т е р е

50

Создан

Завершён

Выполняется Пространство процесса Пространство ядра

Выбран для миграции

Журналирование обращений к памяти

Мигрирован Получить частоту обращений

Анализ шаблонов обращений

Сильносвязанный

Компонента миграции разделяемой памяти

Слабосвязанный

Сбой Страница страницы semop() flush()

Возврат

Компонента включения миграции

Страница

Коммуникационная компонента

Компонента сбоя страниц SHM_PAGE обратная запись/ инвалидация

Компонент а согласованности

Рис. 14. Диаграмма функционал ьно г о проце с с а

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

4.4. Требования к приложению К приложению предъяв л яютс я следующие требов а ни я: •

Приложения реал ьно г о времени не должны исполь з о в а т ь migshm. Производи т е л ь н о с т ь приложений, которые произ в од я т интенсивный вводвывод может упас т ь.

•

Приложение с ра зд е л я емой памятью должно испол ь з о в а т ь семафоры для синхрони з а ции между процес с ами, испол ь з ующих ра зд е л я емую память.

•

В любой момент выполнения проце с с может быть присоединён толь ко к одной облас т и ра зд е л я емой памяти.

•

При миграции потоков проце с с- родит е л ь должен ост а в а т ь с я на домашнем узл е (буде т заб л окиро в а н), в то время как проце с сы- потомки могу т мигриров а т ь.

•

Родит ел ь с к и е и дочерние проце с сы не могут воспол ь з о в а т ь с я сис т емным вызовом malloc() посл е вызов а clone(); процес с- родит е л ь может исполь з о в а т ь malloc() до clone().

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

51 со гл а с о в а н но с т ь разд е л я емых данных. Также вед ё т с я ста т и с т и к а по час т о т е обращения к раз д е л я емой памяти. Таким обра з ом, в за ви симос ти от испол ь з о в а н и я ра зд е л я емой памяти и общей нагру з к и кла с т е р а, migshm самос т о я т е л ь н о мигриру е т разд е л я емую памят ь и группы процес с о в. Включение миграции проце с с о в с ра зд е л я емой памятью Балансиро вщик нагру з к и openMosix не рас сма т рив а е т все типы приложений для миграции. Например, демоны; проце с с init; проце с сы, исполь з ующие kiobuf; процес сы, исполь з ующие планиров ание реал ьно г о времени; проце с сы, испол ь з ующие ра зд е л я емую памят ь; LWP (потоки) и т.п. не мигрируют. Для включение миграции проце с с о в с раз д е л я емой памятью, мы должны убедит ь с я, что openMosix рас см а т ри в а е т эти проце с сы для миграции. openMosix должен быть осв ед омлён об этих процес с а х. Должна быть сохран ен а следующая информация о проце с с е с разд е л я емой памятью: •

уникал ьный идентифика т о р для идентификации проце с с а

•

информация о вирту а л ьн ом адре с е региона раз д е л я емой памяти, к которому присо единён процес с

•

флаг для идентификации, явля е т с я ли проце с с сильно или слабо свя з а нным

Должны быть зафиксиров а ны памяти, такие как:

некоторые

атрибу ты

самой

•

уникал ьный идентифика т о р ре гиона ра зд е л я емой памяти

•

счё т чики обращений присо единённых к ней

•

поро г миграции ра зд е л я емой памяти

к

раз д е л я емой

памяти

всеми

ра зд е л я емой

процес с ами,

Всякий раз, когд а проце с с вызыва е т shmget(), инициали з и ру е т с я информация о раз д е л я емой памяти, и всякий раз, когд а проце с с присо единя т с я к ра зд е л я емой памяти, инициали з иру е т с я информация о процес с е. Управл ение памятью Есть два основных положения по управл ению памятью: 1. openMosix регу лиру е т управл е ни ем памят ью только для приложений, не испол ь з ующих ра зд е л я емую память. Когда проце с с мигриру е т на удал ённый узел, его карты памяти и страницы, вызва вшие “сбой страницы” уничтожаются на UNH и вос с т а н а в л и в ают с я на удал ённом узл е. Это управл ени е памятью не дос т а т о ч н о для процес с о в с ра зд е л я емой памятью. Когда мигрируе т такой проце с с, нель з я уничтожат ь страницы ра зд е л я емой памяти на UNH, потому что могу т быть дру гие проце с сы, присо единённые к той же раз д е л я емой памяти. Управл ение памятью должно быть изменено для того, чтобы openMosix сохран ял информацию об этих

52 стр аниц ах ра зд е л я емой памяти. 2. Когда два проце с с а с раз д е л я емой памятью наход я т с я на одном узл е, они ра зд е л яют те же физиче с ки е страницы раз д е л я емой памяти. То ест ь, когд а эти проце с сы мигрируют на один и тот же удал ённый узе л, openMosix уст ан а в л и в а е т новые страницы для каждого мигриров а вше го процес с а. Вместо это г о проце с сы, присоединённые к региону ра зд е л я емой памяти, должны раз д е л я т ь физиче с ки е страницы ра зд е л я емой памяти также и на удал ённом узл е. Миграция страниц ра зд е л я емой памяти приводит файловой сис т емы tmpfs.

к “краже” страниц у

Миграция процес с о в с раз д е л я емой памятью в любой момент выполнения прогр аммы Реали з а ци я сис т емных вызовов ра зд е л я емой памяти Sys V IPC выполнен а для сис т ем с одним процес с о р ом. После миграции процес с а, посл е дний должен иметь во зможност ь выполнить вся свя з а нные с ра зд е л я емой памят ью функции на удал ённом узл е, поскол ь к у на этом узл е уже устано в л е н а карт а памяти. Можно убедит ь с я, что вызовы функций shmget(), shmat(), shmdt() могу т быть выполнены удал ённо проз р а чным обра з ом: shmget(). shmget() – это

сис т емный вызов, который выполня е т с я на UNH: со зд а ё т с я запис ь в массив е IPC, резу л ь т и рующий идентифика т о р ра зд е л я емой памяти воз в р ащае т с я на удал ённый узе л. • shmat().

После миграции карт а памяти процес с а находит с я на удал ённом узл е. В теч ени е выполнения shmat() вся информация, свя з а н н а я с файлами, ассоцииров а нными с вновь созд а в а емым регионом, извл е к а е т с я из UNH. Исполь з у я это, регион памяти фактиче с ки созд а ё т с я на удал ённом узл е и стано ви т с я час т ью адре сн о г о прос тр ан с т в а проце с с а.

• shmdt().

Регион разд е л я емой памяти отсое диня е т с я от адре сно г о прос тр ан с т в а процес с а на удал ённом узл е. Также на UNH перед а ё т с я информация о проце с с е для тог о, чтобы отсл ежива т ь количе с т в о присо единённых проце с с о в. Коммуникационный модуль

Для миграции процес с ами в клас т е р е openMosix, необходим коммуникационный канал между предс т а в и т е л ь с к им (deputy) и удал ённым (remote) конте к с т ом. Это осущест в л я е т с я уст ано вл е ни ем специал ьно г о TCP соедин ения. Тем не менее, когд а необходимо взаимод ей с т в и е двух проце с с о в на раз личных узл ах, это т коммуникационный канал не может быть испол ь з о в а н. Для преодол е ния этой проблемы был реали з о в а н демон MigSharedMemD. Этот демон активи з иру е т с я на каждом узл е клас т е р а посл е включения openMosix и слушает на порту 0x3418. Он отве т с т в е н е н за приняти е сообщений, которые

53 идентифицируются при помощи типа за г о л о в к а: Тип за г о л о в к а

Модуль

WRITEBACK, INVALIDATE

Согла с о в а н но с т и

SHM_OWNER_BROADCAST

Миграции раз д е л я емой памяти

SHM_PAGE

Сбоя страниц

SYNC_DATA

Миграции потоков

Модели согл а с о в а нно с т и Когда проце с сы, испол ь з ующие раз д е ляемую память, мигрируют на различные узлы, они работ ают с локал ьными копиями ра зд е л я емой памяти. Поэтому должна поддержива т ь с я согл а с о в а нн о с т ь между ра з личными локал ьными копиями одной и той же разд е л я емой памяти. Итак, если проце с сы с ра зд е л я емой памят ью мигрируют и будут разб ро с а ны по клас т е р у openMosix, возникну т конфликты между удал ёнными проце с с ами. Мы должны быть увер ены, что чита т е л ь все г д а прочита е т самую посл еднюю копию данных, а модификации, сдел анные писа т е л ями, перед аютс я всем удал ённым чита т е л ям/пис а т е л ям. Далее следуют подходы, рас сма т ри в а емые для согл а с о в а н но с т и : 1. Строг а я согл а с о в а н но с т ь Наиболе е жёстк а я модель согл а с о в а н но с т и называ е т с я стро г о й со гл а с о в а н но с т ью. Она опред е л я е т с я следующим услови ем: “Любое чтение из ячейки памяти X воз в р ащае т наибол е е недавнюю операцию записи в X”. Это опред е л е ни е неявно подра з ум е в а е т существ о в а ни е абсолютно г о глоб ал ьно г о времени, для того, чтобы опред е л е ни е “наиболе е неда вн е г о” не было неодно зн а ч ным. Следов а т е л ь н о, когд а памят ь стро г о согл а с о в а н а все записи мгновенно видны всем процес с ам и поддержива е т с я упорядоч енно с т ь согл а с н о абсолютному глоб а л ь ному времени. Если изменяе т с я ячейк а памяти, все посл едующие чтения из этой ячейки видя т новое знач ени е, не важно, как скоро посл е изменени я выполнены эти чтения и не важно, какой проце с с выполня е т чтение, и где он расположен. Анало гично, если выполнено чтение, оно получа е т текущее знач ени е, не важно, как быстро произ ошла следующая запис ь. 2. Причинная согл а с о в а н но с т ь (causal consistency) Модель причинной согл а с о в а нн о с т и пред с т а в л я е т собой осл аб л е нную посл ед о в а т е л ь н ую согл а с о в а н но с т ь в том плане, что она ра з лич а е т события, потенциал ь но причинно свя з а н ные, и нет. Рассмотрим на примере памяти. Предположим, что проце с с P1 пишет переменную X. После это г о P2 чита е т X и пишет Y. Здес ь чтение X и запис ь Y потенциал ь но причинно свя з а нны, потому что вычисление Y может зави с е т ь от знач ения X, прочит анно г о P2 (т.е. от знач ени я, запис а нно г о P1). С другой стороны, если два проце с с а спонт анно и одновр ем енно пишут два знач ени я, они не

54 причинно свя з а ны. Если ес т ь чтение, за которым следу е т запис ь, то эти два события потенциал ь но причинно свя з а ны. Аналогично, чтение причинно свя з а н о с запис ью, котор а я обесп е чил а чтение полученными данными. Операции, которые не являютс я причинно свя з а нными, называютс я одновр ем енными. Для того, чтобы память была причинно согл а с о в а нн ой, необходимо чтобы память подчинял а с ь следующим условиям: •

Записи, которые потенциал ьно причинно свя з а нны, должны быть видимы всеми проце с с ами в том же порядк е.

•

Одновременные записи могу т быть видны в ра з личном порядке на ра зных узл а х. Согла с о в а нно с т ь желающего освобождения (eager release consistency)

Процес с зад е ржив а е т распро с т р а н е ни е своих изменений в ра зд е л я емых данных, пока он не подойд ё т к освобождению. Получение и освобождение – две явные операции для синхрони з а ции, необходимые в модели согл а с о в а нн о с т и освобождения, которые соот в е т с т в уют блокирующему получению и блокирующему освобождению. Таким обра з ом, при освобождении он распро с т р а н я е т модификации среди других проце с с о ро в, которые кэшируют модифициров анные страницы. Для протокол а инвалид ации это влеч ё т за собой рас сылку инвалид аций всех модифицированных страниц другим проце с с ам, которые кэшируют эти страницы. Для того, чтобы уменьшить количе с т в о обменива емых данных, протокол обновл ения высылае т ра зницу (diff) для каждой модифициров анной страницы дру гим кэшам. Разница описыва е т модификации, сдел а нные в странице, которые за т ем объединяютс я с дру гими зак эширов анными копиями. В любом случа е освобождени е блокиру е т с я до получения подтв е рждения от других кешей. Изменения, произ в е д ё нные писа т е л ем, сбра сыв аютс я в копию влад е л ь ц а толь ко при освобождении блокиров ки на ра зд е л я емую памят ь. Согла с о в а нно с т ь лениво г о освобождения (lazy release consistency) Наиболе е обесп е ч ении инвалид ации как в модели

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

В migshm исполь з о в а н а модель согл а с о в а нн о с т и желающего освобождения. Это модель, в которой писа т е л ь прота л ки в а е т локал ьные копии модифициров анных страниц ре гион а раз д е л я емой памяти её влад е л ь цу тольк о то г д а, когд а он освобожда е т блокиров ку на памят ь, а не при каждой записи. Эта модел ь гар ан ти ру е т то, что узе л- влад ел е ц ра зд е л я емой памяти все г д а имеет посл е днюю копию разд е л я емой памяти. Таким обра з ом, когд а дру гой удал ённый проце с с произ в оди т посл е дующий доступ к разд е л я емой памяти,

55 выраб а тыва е т с я сбой страницы, и он получа е т с узл а- влад е л ь ц а новейшие стр аницы. Для достижения согл а с о в а н но с т и были исполь з о в а ны баз о вые опер ации обра т н а я запи с ь и инвалид аци я: •

Обратна я запис ь

Обратна я запис ь инициируе т с я на удал ённом узл е, когд а пишущий проце с с на удал ённом узл е освобожда е т блокиров ку. Обратна я запис ь приводит к посылке” г з я з ных” страниц раз д е л я емой памяти, запис а нных удал ённым узлом, узлу- влад е л ь цу ра зд е л я емой памяти как раз перед тем. как удалённый писа т е л ь освобожда е т блокировку. На узл е- влад ел ь ц е полученные данные синхрони зи руютс я с соот в е т с т в ующим адре с ом памяти. Это гар ан т иру е т то, что влад ел е ц имее т самую последнюю копию разд е л я емой памяти. Следова т е л ь н о, копии узл а, на котором выполня е т с я писа т е л ь и узл авлад е л ь ц а имеют новейшие данные. Когда удалённый писа т е л ь пишет в страницу ра зд е л я емой памяти, он отпра в л я е т следующую информацию узлу- влад е л ь цу: 1. Содержимое ра зд е л я емой памяти для синхрони з а ц ии. 2. Информацию, свя з а н ную с адре с ом памяти страницы ра зд е л я емой памяти для её синхрони з а ц ии по правил ьному местоположению. 3. Идентифика т о р и UHN раз д е л я емой памяти для уникал ьной идентификации её на UNH. Узел- влад е л е ц получа е т страницу и син хронизиру е т её по правил ьному местоположению в памяти. •

Инвалид ация

Операция инвалид ации инициируе т с я памяти при следующих событиях:

на

узл е- влад е л ь ц е

раз д е л я емой

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

4.5. Использование многопоточных приложений Поддержка многопоточных приложений явля е т с я одним из важных дост оинс т в любой кла с т е рн ой сис т емы. Эта поддержка особ енно важна для тяжелов е с ных приложений, какими явл яютс я приложения Java, испол ь з о в а н и е которых в произ в од с т в е н ных масштаб ах явно подра з ум ев а е т испол ь з о в а н и е сис т ем распр ед е л ё н ных вычисл ений для обесп еч е ни я требу емо г о уровня надёжнос т и и произ в оди т е л ь н о с т и. В нас то ящее время существ у е т неско л ь к о

56 реали з а ций потоков в Java: “native threads”, “classic threads” и “green threads”. Только при исполь з о в а н ии последн е г о типа потоков приложение может получит ь выгоду от выполнения в сред е openMosix. Две первых реали з а ции явно или неявно испол ь з уют сис т емную библиот е ку pthread. Причиной нево зможнос ти уменьшения степе ни дет а ли з а ц ии выполнения зад а чи до потоков, как это дела е т планировщик зад а ч Linux, явл я е т с я опред е л ени е окружения, в котором выполня е т с я проце с с и поток. Например, посл е выполнения сис т емно г о вызов а fork() проце с с- потомок не может произ вод и т ь запис ь в обла с т ь данных потомка, в то время как нескол ь к о потоков в преде л а х одног о приложения могу т иметь общие переменные для чтения/ з а пи си. Следова т е л ь н о, проблема дет а ли з а ц ии до уровня потоков анало ги чн а проблеме реали з а ции разд е л я емой памяти, поддержка которой в openMosix вес ьм а огранич ен а. Поэтому все попытки испол ь з о в а т ь потоки в сред е openMosix оканчив аютс я неудач ей.

57

5. ИНСТАЛЛЯЦИЯ OPENMOSIX 5.1. Требования к аппаратной и программной части Для соединения узлов клас т е р а можно воспол ь з о в а т ь с я любой техноло г и е й (Ethernet, ATM, Token Ring), поддержива емой ядром Linux. Чаще все г о испол ь з уют 100Мб Ethernet (в силу прос то ты установ ки и дешевизны), что будет дос т а т о ч н о для клас т е р о в из небол ьшого числ а узлов. Однако, чем произ в оди т е л ь н е е буде т се т ь, тем быстре е буде т работ а т ь ваш кла с т е р. Конечно же, можно уст ан о ви т ь нескол ь к о се т е вых адап т е р о в на ключевые узлы клас т е р а, увеличив а я тем самым суммарную пропус кную способно с т ь, тем не менее, испол ь з о в а н и е Gigabit Ethernet явл я е т с я боле е предпоч ти т е л ь ным. Так же понадоб я т с я высокопрои з в о д и т е л ь ные коммута т о ры и источники бесп ер е б ойно г о питания. Самым оптимал ьным вариан т ом явл я е т с я испол ь з о в а н и е бе зди с к о вых клиенто в с возможнос т ью за г ру з к и по NFS (при этом NFS-серв е р желате л ьн о не включать в клас т е р для надёжнос ти). Для устано в к и необходим любой современный дистрибу ти в Linux, основ анный на ядре 2.4.x. Понадобит с я дос т а т о чн о е место под ра зд е л подкачки (swap) на жёстком диск е.

5.2. Планировка кластера Существу е т нескол ь к о типов пулов серв е р о в и рабочих станций, которые можно построи т ь на баз е openMosix: •

Одиночный пул: все серв е р а и рабочие станции исполь з уютс я в едином кла с т е р е . В этом случа е кар т а узлов буде т одинаков ой на всех ст анци ях. Преимущество/недо с т а т о к: рабоч а я станция – час т ь кла с т е р а , и любой узе л кла с т е р а может исполь з о в а т ь все вычисли т е л ь ные ресур сы рабоч ей станции (при условии, что не зад е й с т в о в а н механизм огранич ений loadlimit или фильтра ции miggroup).

•

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

•

Адаптивный пул : серв е р а являются совме с тн о исполь з у емыми, в то время как рабочие станции могут присоединя т ь с я к кла с т е р у и покида т ь его. Рабочие станции поль з о в а т е л е й могут испол ь з о в а т ь с я в кач е с т в е узло в кла с т е р а , например, ночью и в выходные дни. Системы тако г о типа иногд а называют COW (Cluster of Workstations).

•

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

58

5.3. Сборка openMosix Возможны следующие способы уст анов ки openMosix: •

•

самос т о я т е л ь н а я сборка из исходных тек с т о в ядра •

исполь з о в а ни е репо зи т о ри я, который уже содержит ядро Linux 2.4.20 с внес ёнными раз р а б о т ч и к ами openMosix изменениями

•

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

испол ь з о в а н и е уже собранных паке т о в

Каждый вариан т имеет как свои плюсы, так и недос т а т к и. Так, например, если вам необходима неординарна я конфигурация ядра, либо вы хотит е воспол ь з о в а т ь с я другими расширениями ядра, пост а в л я емых в виде патч ей к ядру сторонними раз р а б о т ч и к ами, либо вы хотит е собра т ь монолитно е ядро, то самос т о я т е л ь н а я сборк а – единс т в е нный возможный путь. Однако он требу е т понимания процес с а сборки, и вы можете столкну т ь с я с трудно с т ями при конфигуриров а нии ядра под имеющуюся аппара т у р у. Исполь з у я репо зи т о рий, вы можете получит ь выгоду от испол ь з о в а н и я дополнит е л ь н ой функционал ьно с т и, дост упной только в раз р а б а тыв а емой вер сии. Однако, эта функционал ьно с т ь не явля е т с я хорошо отлаженной и пред с к а з у емой, поэтому может работ а т ь непра вил ьно и нег а т и в но возд е й с т в о в а т ь на други е подсис т емы openMosix и стабил ьно с т ь сис т емы в целом. Исполь з о в а ни е стабил ьн о г о патч а явля е т с я наибол е е оптимал ьным и бе зоп а с ным вариан т ом, поскол ь к у вся функционал ь но с т ь была хорошо проте с т и р о в а н а перед выходом новой версии. Патч можно применит ь как к оригин ал ь ному ядру, исходные коды которо г о можно взя т ь с сайт а http://www.kernel.org, так и к ядру, пост а в л я емому произ в оди т е л ем дистрибу ти в а. В посл едн ем случ а е не исключено возникнов е ни е конфликто в между патч ем openMosix и модификациями, которые внёс произ в оди т е л ь. Однако если проце с с пере с б ор к и ядра явля е т с я для вас за т ру д ни т е л ь ным, вы можете воспол ь з о в а т ь с я уже скомпилиров анным ядром. Этот вариан т явл я е т с я самым быстрым и приемлемым в большинств е случа е в.

5.3.1. Использование репозитория Здес ь и дале е значок '#' подра з ум е в а е т, что команды выполняются под админис тр а т о р ом (root), значок '$' – под обычным поль з о в а т е л ем, значо к '\' – перено с на следующую строку. ~# cd /usr/src /usr/src# export CVSROOT= pserver:[email protected]:\ / cvsroot/openmosix /usr/src# cvs login /usr/src# cvs -z3 co linux-openmosix /usr/src# ln -s linux-openmosix/linux-openmosix linux

59

/usr/src# cd linux /usr/src/linux# make menuconfig

Тепер ь необходимо акти ви з и р о в а т ь необходимую функционал ьн о с т ь ядра, а также следующие опции: •

CONFIG_MOSIX=y

•

CONFIG_MOSIX_SECUREPORTS=y

•

CONFIG_MOSIX_DISCLOSURE=1

•

CONFIG_MOSIX_FS=y

•

CONFIG_MOSIX_DFSA=y

для

вас

Тепер ь можно непоср е д с т в е н но собра т ь и устано ви т ь ядро, предв а ри т е л ь н о изменив параме т р INSTALL_PATH= в /usr/src/linux/Makefile на сво ё усмотрение: /usr/src/openmosix/linux-openmosix# make dep bzImage install \ modules modules_install

После это г о необходимо отред а к т и р о в а т ь файл /etc/lilo.conf, доба ви т ь в него новую секцию с путём к новому ядру и пере з а п у с т и т ь lilo.

5.3.2. Использование стабильного патча Вам понадоб я т с я следующее файлы: •

исходные коды ядра Linux: ftp://ftp.kernel.org/pub/kernel/v2.4/linux-2.4.20.tar.bz2

•

посл едн я я верси я стабил ьно г о патч а для данной версии ядра: http://sourceforge.net/project/showfiles.php?group_id=46729&release_id=136769. Предположим, что данные файлы наход я т с я в кат а л о г е /usr/src:

~# cd /usr/src /usr/src# tar -xjf linux-2.4.20.tar.bz2 /usr/src# mv linux-2.4.20 linux-2.4.20-mosix /usr/src# ln -s linux-2.4.20-mosix linux /usr/src# cd linux /usr/src/linux# zcat ../openMosix-2.4.20-2.gz | patch –p1 patching file arch/i386/config.in patching file arch/i386/defconfig patching file arch/i386/kernel/entry.S patching file arch/i386/kernel/i387.c patching file arch/i386/kernel/ioport.c ... /usr/src/linux# make menuconfig

Необходимо обра ти т ь внимание на то, чтобы в выводе команды patch не было строк, сод ержащих слово FAILED. Далее посл ед о в а т е л ь н о с т ь шагов анало г ичн а предыдущему ра зд е л у.

5.3.3. Использование собранных пакетов Понадоб я т с я собранные паке ты с: http://sourceforge.net/project/showfiles.php?group_id=46729&release_id=136769

60 Инсталл я ция очень прос т а: ~# cd /usr/src /usr/src# rpm -ivh openmosix-kernel-2.4.20.i386.rpm

После это г о необходимо дополнит ь конфигур ацию менеджера за г р у з к и.

5.4. Установка пользовательских утилит Анало гично, как и при уст анов к е ядра, возможный следующие варианты: •

сборк а из исходных кодов, взя тых их репо зи т о ри я

•

сборк а из исходных кодов, взя тых с сайт а

•

уст ано в к а зар ан е е собранно г о паке т а

Перед сборкой из исходных кодов убеди т е с ь, что /usr/include/linux содержит акту а л ь ные за г о л о в о чные файлы ядра openMosix или явля е т с я ссылкой на поддер е в о /usr/src/linux/include/linux: ~# cd /usr/include /usr/include# mv linux linux-old /usr/include# ln -s /usr/src/linux/include/linux

Далее необходимо получи т ь версию из репо зи т о ри я: ~# cd /usr/src /usr/src# export CVSROOT= pserver:[email protected]:\ / cvsroot/openmosix /usr/src# cvs login /usr/src# cvs -z3 co userspace-tools /usr/src# cd userspace-tools

Внести изменения в файл /usr/src/userspace-tools/configuration (параме т р OPENMOSIX должен ука зыв а т ь на дирек то рию с исходными кодами ядра, например, OPENMOSIX = /usr/src/linux; параме т р DESTDIR изменит е на сво ё усмотр ени е) /usr/src/userspace-tools# make all install

Инсталл я ция из исходных кодов анало г ичн а. Для это г о потреб у е т с я архив openmosix-tools-0.3.tgz с http://sourceforge.net/project/showfiles.php?group_id=46729&release_id=152286: ~# cd /usr/src /usr/src# tar -xzf openmosix-tools-0.3.tgz /usr/src# cd openmosix-tools-0.3 /usr/src/openmosix-tools-0.3# make all install

5.5. Файл карты узлов Файл карты узлов /etc/hpc.map испол ь з у е т с я утилитой mospe при инициали з а ции openMosix. Каждая строк а это г о файла сос т ои т из следующих

61 полей: openMosix_ID имя_машины количе с т в о_по с л е д о в а т е л ь ных_у з л о в Например, следующий файл: 1 10 51

192.168.1.1 192.168.1.10 192.168.1.50

2 1 3

конфигуриру е т узлы: 1 192.168.1.1 2 192.168.1.2 10 192.168.1.10 50 102.168.1.50 51 192.168.1.51 52 192.168.1.52 Задани е вместо это г о файла строки вида: 1

192.168.1.1

250

нежела т е л ь н о, так как будет вызыва т ь продолжите л ьные тайм- ауты при опрос е отсу т с т в ующих узлов. Дополните л ь но в этом файле можно ука зыв а т ь IP адре с а, которые являются синонимами узлов, с нескол ь кими имеющимися сконфигу риров а нными IP адр е с ами (для узлов с нескол ь кими се т е выми интерфейс ами) (см. man mospe). В будущем планиру е т с я исключить исполь з о в а ни е это г о файла и полнос т ью перейти на автообн а ружение.

5.6. Файл локально монтируемых файловых систем Общесист емный файл /etc/fstab содержит список файловых сис т ем. В прос т ейшем случа е он имеет вид: /dev/hda2 devpts proc usbdevfs mosix

/ /dev/pts /proc /proc/bus/usb /mfs

reiserfs devpts proc usbdevfs mfs

defaults defaults defaults noauto dfsa=1

1 0 0 0 0

локал ь но- монтиру емых

2 0 0 0 0

Задани е атрибу т а dfsa=1 ра з р ешае т возможнос т ь исполь з о в а ни я DFSA.

62

6. НАСТРОЙКА И АДМИНИСТРИРОВАНИЕ OPENMOSIX 6.1. openMosix API 6.1.1. Proc интерфейс Так как openMosix явля е т с я расширением ядра Linux, то почти вся функционал ьн о с т ь находит с я в ядре. Для того чтобы конфигуриро в а т ь , админис триро в а т ь и получа т ь ст а т и с т и ч е с к ую информацию из яд ра, необходим хорошо опред ел ё нный интерфейс. Наиболе е час т о испол ь з у емым способом обеспе ч е ни я это г о явля е т с я так называ емый proc-интерфейс (или sysctl-интерфейс). Этот интерфейс позв ол я е т получа т ь и уст ан а в л и в а т ь знач ени я ядра с уровня приложения. Для получения боле е полной информации о файловой сист ем е /proc см. документ ацию к ядру Linux в кат а л о г е Documentation/filesystems/proc.txt. Аналогичным обра з ом дирек то ри я /proc/hpc обесп е чив а е т доступ к струк т у р ам openMosix в ядре. Она содержит файлы, которые исполь з уютс я для локал ьно г о конфигуриров а ни я, так и информацию об удал ённых узл ах. Вся информация в /proc/hpc обновл я е т с я по исте ч ению интер в а л а уста р е в а ни я (decay-interval), который можно уст ан о ви т ь в любое время. Таким обра з ом, каждый узе л в кла с т е р е зна е т сос т о я ни е удал ённых узло в. Это необходимо для вычисл ения того, как бал ансиров а т ь нагру з к у и процес сы по кла с т е р у. Так как эти ал г ори тмы органи з о в а ны децен тр а л и з о в а нным обра з ом, каждый узе л решае т сам, должен ли процес с мигриров а т ь к другому узлу. Это уменьшает за т р а ты и обесп е чив а е т линейную масштабиру емос т ь вплот ь до 1000 узлов. Пользов а т е л и и прогр аммы могу т напрямую вз аимод ейс т в о в а т ь с openMosix чере з это т интерфейс, так как большинств о файлов явл яютс я тек с т о выми. Локальна я информация, доступн а я чере з /proc/hpc/admin/: •

block – раз р ешить/ з а пр е т и т ь миграцию удал ённых проце с с о в на данный узел

•

bring – верну т ь все мигриров а вшие c данного узл а проце с сы (переме с ти т ь проце с сы наз а д на домашний узе л)

•

dfsalinks – список текущих ссылок DFSA

•

expel – переме с т и т ь все мигриров а вшие на данный узел проце с сы обра тно на свои домашние узлы

•

gateways – максимал ьно е число шлюзов

•

lstay – локал ьные проце с сы должны ост а т ь с я (запре т и т ь миграцию)

•

mospe – содержит ID узл а openMosix (см. гл. 5.5)

•

nomfs – раз р ешить/ з а пр е т и т ь MFS

•

overheads – для нас тройки оптимиз а ции (см. гл. 6.2)

•

quiet – прекр а т и т ь сбор информации для балан си ро в ки нагру з к и

•

decayinterval – интерв а л для сбора информации для бал ансиро в ки нагру з к и

63

•

slowdecay – по-умолчанию 975

•

fastdecay – по-умолчанию 926

•

speed – скоро с т ь относи т е л ь н о PentuimIII/1ГГц

•

stay – разр ешить/ з а пр е т и т ь авт ома ти ч е с к ую миграцию процес с о в

•

loadlimit – огранич ени е нагру з к и (если 0, то функция отключена)

•

llimitmode – режим огранич ения нагру з к и; может принимат ь знач е ни я 0, 1, 2: 0 – общая нагру з к а не может быть больше чем loadlimit; это значи т, что если общая нагру з к а станови т с я больше loadlimit, то удал ённые проце с сы не могу т мигриров а т ь на данный узе л, а уже мигриров а нные проце с сы буду т высылать с я на свои домашние узлы (UHN) до те пор, пока общая нагру з к а не стан е т меньше порог о в о г о знач ени я loadlimit 1 – удал ённа я нагру з к а, то ес т ь суммарна я нагру з к а всех удал ённых проце с с о в, не может быть больше loadlimit 2 – локал ьн а я нагру з к а , то ес т ь суммарна я нагру з к а всех локал ьных проце с с о в, не может быть больше loadlimit

•

cpulimit – огранич ени е исполь з о в а ни я проце с с о р а (если 0, то функция отключена, 100 – максимал ьно е знач ени е для однопроце с с о рной сис т емы)

•

cpulimitmode – режим огранич ения исполь з о в а ни я процес с о р а; принимат ь знач ени я 0, 1, 2 (анало ги чно, как и для llimitmode)

•

config – (двоичный файл) основной конфигур ационный файл, запис а нный утили той mospe.

может

Информация о локал ьных узл а х, дост упн а я чере з /proc/hpc/nodes/[ID], гд е ID – это идентифика т о р узл а openMosix, зад анный при инициали з а ции (см. гл. 5.5): •

cpus – количе с т в о процес с о р о в на узл е

•

load – нагру з к а openMosix для это г о узл а

•

mem – дос тупн а я память, как это кажет с я openMosix

•

rmem – дост упн а я память, как это кажет с я Linux

•

speed – скоро с т ь узл а относи т е л ь н о PIII/1ГГц

•

status – ста т у с узл а

•

tmem – доступна я памят ь

•

util – исполь з о в а н и е узл а

•

loadlocal – общая нагру з к а всех локал ьных проце с с о в

•

loadremote – общая нагру з к а всех удал ённых проце с с о в

•

loadlimit – текущее знач ение огранич ения нагру з к и

•

llimitmode – текущее знач ение режима огранич ения нагру з к и

•

cpulocal – общее исполь з о в а ни ем проце с с о р а всеми локал ь ными проце с с ами

•

cpuremote – проце с с ами

общее

исполь з о в а ни ем

проце с с о р а

всеми

удал ёнными

64

•

cpulimit – текущее знач ени е огранич е ния исполь з о в а н и я проце с с о р а

•

cpulimitmode – текущее проце с с о р а

знач ение

режима

огранич е ния

исполь з о в а ни я

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

что

Дополнит е л ь н а я информация о локал ьных проце с с а х, дост упн а я чере з / proc/[PID]/: Доступные для чтения: •

cantmove – причина, почему проце с с не может мигриров а т ь

•

lock – уст анов л е но, если процес с забл окиро в а н на своём домашнем узл е

•

nmigs – сколь ко ра з проце с с мигриров а л

•

where – ID узл а, на котором проце с с в данное время выполняе т с я Доступные для записи:

•

lock – если вы хотит е забл окиро в а т ь проце с с на домашнем узл е, запишите сюда 1; для того, чтобы процес с мог мигриров а т ь, он должен быть ра зб л о киров ан (запис а т ь 0)

•

goto – запишите ID узл а, на который следу е т мигриров а т ь проце с с

•

migrate – то же самое, что и goto

•

migfilter – запис а т ь 1 для включения механи зм а фильтр ации на основ е миграционных групп (miggroup)

•

mignodes – битов а я маска идентифика т о р о в узлов (равно сумме 2^(ID-1), где ID – идентифика т о р узл а openMosix)

•

migpolicy – зад ани е политики фильтр ации; может принимать знач ения 0 или 1: 0 – запр е т и т ь: проце с с может мигриров а т ь на все узлы за исключением тех, для которых установ л е н в единицу соотв е т с т в ующий бит в mignodes 1 – раз р ешить: проце с с может мигриров а т ь на все узлы, для которых уст ано в л е н в единицу соотв е т с т в ующий бит в mignodes Информация об удал ённых проце с с а х, дост упн а я чере з /proc/hpc/remote/:

•

from – домашний узел проце с с а

•

identity – дополнит е л ь н а я информация о процес с е

•

statm – ста ти с т и к а проце с с а по исполь з о в а нию памяти

•

stats – ста ти с т и к а проце с с а по исполь з о в а н ию CPU

6.1.2. Интерфейс MFS Кроме proc-интерфей с а, поль з о в а т е л ь или прогр амма может получа т ь дост уп к файловой сис т ем е любого узл а в кла с т е р е , если смонтиров а н а MFS (см. гл. 5.6). В этой дирек т ории доступно нескол ь к о ссылок, имеющих следующее знач ения: •

here – ука зыв а е т на корневую файловую сист ему текущего узл а, на котором

65 выполня е т с я данный проце с с •

home – ука зыв а е т на корне вую файловую сис т ему домашнего узл а

•

magic – ука зыв а е т на корнев ую файловую сис т ему узл а, испол ь з у емо г о в посл едн ем сис т емном вызов е create() (или open() с опцией "O_CREAT"); в противном случа е, ука зыв а е т на посл е дний узел, на котором был успешно со зд а н «магич е с кий» файл MFS (явля е т с я поле з ным при соз д ании файла и немедл енном его удал ении)

•

lastexec – ука зыв а е т на корне вую файловую сис т ему узл а, на котором проце с с успешно выполнил сис т емный вызов execve()

•

selected – ука зыв а е т на корнев ую файловую сис т ему узл а, котор а я была выбрана в самом приложении или в каком- либо его предк е (перед вызовом fork())

6.1.3. Функциональность пользовательской библиотеки libmosix openMosix также обесп е чив а е т функционал ьно с т ь чере з libmosix, котор а я входи т в сос т а в поль з о в а т е л ь с к и х утилит:

библио т е к у

•

int msx_readval(char *path, int *val); прочит а т ь 'val' из 'path' ('path' все г д а путь для чтения/ з а пи си в /proc/hpc интерфейс е)

•

int msx_readval2(char *path, int *val1, int *val2); прочит а т ь 'val1' и 'val2' из 'path'

•

int msx_write(char *path, int val); запис а т ь 'val' в 'path'

•

int msx_write2(char *path, int val1, int val2); запис а т ь 'val1' и 'val2' в 'path'

•

int msx_readnode(int node, char *item); прочит а т ь 'item' из 'node' ('item' можеть быть load, speed, cpus, util, status, mem, rmem, tmem)

•

int msx_readproc(int pid, char *item); прочит а т ь 'item' для специфиче с ко г о 'pid' (эта функция чита е т информацию для 'pid' из /proc/[PID]/[item], 'item' может быть block, bring, stay…)

•

int msx_read(char *path); прочит а т ь знач ени е из 'path'

•

int msx_writeproc(int pid, char *item, int val); запис а т ь 'val' в 'item' для проце с с а 'pid'

•

int msx_readdata(char *fn, void *into, int max, int size);

•

int msx_writedata(char *fn, char *from, int size);

•

int msx_replace(char *fn, int val);

•

int msx_count_ints(char *fn);

•

int msx_fill_ints(char *fn, int *, int);

66 API libmosix также сод ержит функцию для контрол я и изменения повед ени я openMosix: •

int msxctl(msx_cmd_t cmd, int arg, void *resp, int len); #define msxctl1(x) (msxctl((x), 0, NULL, 0)) #define msxctl2(x,y) (msxctl((x), (y), NULL, 0)) #define msxctl3(x,y,z) (msxctl((x), (y), (z), sizeof(*(z)))) Возможные команды для cmd:

•

D_STAY, /* Разрешить автома тич е с к ую миграцию проце с с о в с это г о узл а */

•

D_NOSTAY, /* Запре т и т ь автома тич е с к ую миграцию процес с о в с это г о узл а */

•

D_LSTAY, /* Разр ешить автома тич е с к ую миграцию локал ь ных процес с о в */

•

D_NOLSTAY, /* Запре т и т ь автома тич е с к ую миграцию локал ьных проце с с о в */

•

D_BLOCK, /* Заблокиров а т ь автома тич е с к ую миграцию к этому узлу */

•

D_NOBLOCK, /* Разр ешить автомат ич е с к ую миграцию к этому узлу */

•

D_EXPEL, /* Перемес ти т ь все удал ённые проце с сы с это г о узл а */

•

D_BRING, /* Вернут ь все проце с сы на это т (домашний) узе л */

•

D_GETLOAD, /* Получить текущую нагру з к у */

•

D_QUIET, /* Остановит ь внутре ннюю активно с т ь по балан сиро в к е нагру з к и */

•

D_NOQUIET, /* Возобнови т ь нагру з ки */

•

D_TUNE, /* Войти в режим наст ройки */

•

D_NOTUNE, /* Выйти из режима нас т рой ки */

•

D_NOMFS, /* Запре т и т ь MFS доступ к этому узлу */

•

D_MFS, /* Разр ешить MFS дост уп к этому узлу */

•

D_SETSSPEED, /* Установи т ь станд а р т ную скоро с т ь, влияе т на D_GETLOAD */

•

D_GETSSPEED, /* Получит ь станд а р тн ую скоро с т ь (по-умолчанию=1000) */

•

D_GETSPEED, /* Получить скоро с т ь машины */

•

D_SETSPEED, /* Установи т ь скоро с т ь машины */

•

D_MOSIX_TO_IP, /* Сконвер тиро в а т ь из openMosix ID в IP адре с */

•

D_IP_TO_MOSIX, /* Сконвер тиро в а т ь из IP адре с а в openMosix ID */

•

D_GETNTUNE, /* Получить число нас тр а и в а емых параме тро в ядра */

•

D_GETTUNE, /* Получит ь нас т р а и в а емые параме тры ядра */

•

D_GETSTAT, /* Получить ст а т у с openMosix */

•

D_GETMEM, /* Получить текущие знач ени я памяти (все г о и свободной) */

•

D_GETDECAY, /* Получит ь параме т ры уст а р е в а ни я */

•

D_SETDECAY, /* Установи т ь парамет ры уст а р е в а н и я */

•

D_GETRMEM, /* Получить пред с т а в л е ни е ОС о памяти (свободной и все г о) */

внутр еннюю активно с т ь

по

балан сиро в к е

67

•

D_GETUTIL, /* Получить испол ь з о в а н и е процес с о р а в % */

•

D_SETWHERETO, /* Отправит ь проце с с куда- нибудь */

•

D_GETPE, /* Получит ь ID узл а */

•

D_GETCPUS, /* Получить количе с т в о процес с о р о в */

6.2. Оптимизация работы openMosix В наст о ящее время данна я функционал ьно с т ь не доступн а, функционал ьн о с т ь утили т переписыва е т с я под лицен зию GPL.

т.к.

openMosix содержит боле е 14 параме тро в для тонкой наст р ойки. Есте с т в е н но, ручна я наст ройк а этих параме тро в утомит ел ь н а для каждо го узл а. Для автома ти з а ц ии проце с с а служат утилиты prep_tune, котор а я запу с к а е т с я на одном узл е, и tune_kernel, котор а я запу с к а е т с я на втором. В теч ение нескол ь ки х минут их работы не стои т нагружа т ь узлы и/или се т ь, иначе выходные параме тры буду т некорр е к т ны. После окончания работы будет со зд а н файл /tmp/overheads, готовый для испол ь з о в а ни я: ~# cat /tmp/overheads > /proc/hpc/admin/overheads

Есте с т в е н но, данную команду необходимо вст а ви т ь в один из за г р у з о ч ных скрипто в (например, /etc/init.d/openmosix), чтобы инициали з а ци я параме тр о в имела место при каждой за г ру з к е .

68

7. ТЕСТИРОВАНИЕ КЛАСТЕРА 7.1. Функциональное тестирование •

Тест с испол ь з о в а ни ем прогр аммы расч ё т а распр е д е л ё нных ключей RC5-72 (dnetc) Для запу с к а приложений воспол ь з у ем с я следующей командой:

/usr/local/bin$ for i in 1 2 3 4 5 6 7 8; do ./dnetc -numcpu 0; done

Процес с выполнения пред с т а в л е н на рис. 15. Для получения информации по испол ь з о в а н ию утилит openMosix см. [HOWTO]. Наблюдаем,

что

все

проце с сы

распр е д е л ил ис ь

равномерно

большей по

узл ам

Рис. 15. Выполнение прогр аммы dnetc кла с т е р а . •

Тест на ввод- вывод

Для провед е ни я тес т а скопиру ем дос т а т о ч н о большой файл на все узлы кла с т е р а : /tmp# for i in 10 51 52; do cp 1.wav /mfs/$i/tmp & done

69

Рис. 16. Процес с выполнения команды cp Процес с выполнения этих команд пред с т а в л е н на рис. 16: Как видно из рисунка, проце с сы cp были мигриров аны к тем узл ам клас т е р а, на которые произ в одил о с ь копиров ани е. Это не уменьшило нагру з к у сети, но позв о лил о раз г р у з и т ь процес с о р на узл е 1. •

Тест с испол ь з о в а ни ем прогр аммы для кодиров ани я аудио (lame)

Для провед е ни я тес т а воспол ь з у ем с я уже скопиров анными файлами и сконв е р т и ру ем их из wav в mp3 при помощи команды lame: ~# for i in 1 1 10 10 51 52 > do > lame -v -h -S /mfs/here/tmp/1.wav - &> /dev/null & > done

70

Рис. 17. Процес с выполнения команд lame Процес с выполнения этих команд пред с т а в л е н на рис. 17. Из рисунка видно, что процес сы мигриров а л и к соот в е т с т в ующим узл ам.

7.2. Тестирование общей производительности В иссл ед о в а т е л ь с к ом центр е NASA Ames Research Center был раз р а б о т а н комплек с тес т о в, позвол яющий оценив а т ь произ в оди т е л ь н о с т ь супер к омпьютеров. Комплекс тес т о в NAS сос т ои т из пяти тес т о в NAS kernel benchmark и трёх те с т о в, основ анных на реал ьных зад а ч а х гидро- и аэродинамиче с к о г о моделиров а ни я. Этот круг зад а ч не покрыва е т все г о спек т р а возможных приложений, однако на се годн яшний день NAS Benchmarks явл я е т с я лучшим общепризна нным комплек с ом тес т о в для оценки паралл е л ь ных многопроце с с о рных сист ем, что, собс т в е нн о, и подтв е ржда е т с я прак тич е с к ими наблюдениями – резу л ь т а т а ми ТОР500. Комплекс зад а чи:

тес т о в

NAS Benchmarks kernel включае т

следующие расч ё тные

1. ЕР (Embarrasingly Parallel). Вычисление инте г р а л а методом Монте- Карло – тес т “усложнённог о паралл е л и зм а” для измерени я первичной вычислит е л ь н о й произ в од и т е л ь н о с т и плав ающей арифметики. Это – те с т минимально г о межпроцес с о рн о г о взаимод ей с т в и я, который фактич е с ки опред е л я е т чисто вычислит е л ь ные хара к т е ри с т и к а узл а при работ е с вещест в е н ной арифметикой. 2. MG (3D Multigrid). Тест

по решению уравн ения

Пуассон а

(“трёхмерна я

71 решётка”) в час тных произ в одных – требу е т высокос т р у к т у ри ро в а н ной органи з а ции вз аимод ей с т в и я проце с с о р о в. Тестиру е т возможнос ти сис т емы выполня т ь как дальние, так и корот ки е перед а чи данных. 3. CG (Conjugate Gradient). Вычисление наименьшего соб с т в е н но г о знач е ния больших, разр ежённых матриц методом сопряжённых гради ен т о в. Это типичное нест ру к т у риро в а нно е вычисл ение на решётке, и поэт ому тес т применя е т с я для оценки скоро с т и перед ачи данных на длинные рас с т о я ни я при отсу т с т в и и какой- либо ре гул я рно с т и. 4. FT (fast Fourier Transformation). Вычисление методом быстро г о преобр а з о в а н и я Фурье трёхмерно г о уравнени я в час тных произ в од ных. Данная зад а ч а испол ь з у е т с я как “серь ё з ный” тес т для оценки эффективно с т и вз аимод ей с т в и я по перед а ч е данных между удал ёнными проце с с о р ами. При со зд а нии прогр аммы, реали з ующей данный те с т, могут испол ь з о в а т ь с я библиот е чные модули преобр а з о в а н и я Фурье ра з личной ра змерно с т и. 5. IS (Integer Sort). Тест выполняе т сортиров ку целых чисел и исполь з у е т с я как для оценки возможнос т е й работы сис т емы с целочис л е нной арифметикой (главным обра з ом одног о узл а), так и для выявл ения потенциа л а компьютера по выполнению межпроце с с о рн о г о вз аимод ейс т в и я. Комплекс те с т о в NAS Benchmarks по модельным зад а ч ам включае т следующие модули: 1. LU (LU Solver). Тест выполняе т вычисл ения, свя з а н ные с опред е л ё нным кла с с ом ал гори тмов (INS3D-LU по клас с ификации центр а NASA Ames), в которых решает с я сист ем а уравн ений с равномерно- раз р ежённой блочной треу г о л ь н ой матрицей 5х5. 2. SP (Scalar Pentadiagonal). Тест выполняе т решение нескол ь к их нез а в и с имых сис т ем скал я рных уравн ений – пентад и а г он а л ь ные матрицы с преобл а д а ни ем недиа г он а л ь ных членов. 3. ВТ (Block Tridiagonal). Решение серии нез а в и симых сис т ем уравнений – блочные трёхдиа г о н а л ь ные матрицы 5х5 с преобл ад а ни ем недиа г он а л ь ных элементо в. Для уст ано в ки нужно зар е г и с т р и ро в а т ь с я на сайт е The NAS Parallel Benchmarks (http://www.nas.nasa.gov/Software/NPB/) и скач а т ь файл с исходными тек с т ами те с т о в NPB2.4.tar.gz. $ tar -xzf NPB2.4.tar.gz $ cd ./NPB2.4/NPB2.4-MPI

После это г о отред а к т и р о в а т ь анало ги ч е н следующему: MPIF77 = mpif77 FLINK = mpif77 #FMPI_LIB = #FMPI_INC = FFLAGS = -O3 FLINKFLAGS =

файл ./config/make.def так, чтобы он был

72

MPICC = mpicc CLINK = mpicc #CMPI_LIB = #CMPI_INC = CFLAGS = -O3 CLINKFLAGS = # include ../config/make.dummy CC = cc -g BINDIR = ../bin RAND = randdp

Убедит е с ь, что mpif77 и mpicc доступны из вашего $PATH. В противном случа е нужно выполнит ь: $ export PATH=$PATH:/opt/mpich/bin

Для удобс т в а содержания: # Use bt ep cg is lu mg sp

tabs W W W W W W W

можно

соз д а т ь

файл

./config/suite.def

следующего

9 9 9 9 9 9 9

Этот файл буде т испол ь з о в а т ь с я для сборки паке т а тес т о в. Последний этап – компиляция и запу с к тес т о в (см. приложение 1): $ make suite $ mpirun -v -np 9 -machinefile machines bt.W.9

Для оценки потенци ал ь ных возможнос т е й тес т иру емой конфигу р ации вычисля е т с я относи т е л ь н а я прои зв од и т е л ь н о с т ь по сравне нию с пока з а т е л ями традиционно г о век торно г о суперк омпьютер а, в кач е с т в е которо г о обычно выступ а е т одна из моделей Cray. Для NAS kernel benchmark опред ел яютс я четыре клас с а тес т о в: клас с S, клас с A, клас с B и кла с с C, которые фактич е с ки отличаютс я “размерно с т ью” вычисл ений. Размер зад а ч из кла с с а В превос х оди т размер зад а ч из клас с а А примерно в четыре ра з а. Резу л ь т а ты те с т иро в а н и я в клас с е А нормируются на прои зв од и т е л ь н о с т ь однопроце с с о рно г о компьютера Cray Y-MP, а клас с а В – на однопроце с с о р ный Cray C90. Тестиров а ни е произ в одил о с ь на кла с т е р е со следующей конфигур ацие й: Узел Pilot

73

cpu: AMD Athlon(tm) processor, 952.189 MHz (1900.54 bogomips), 256 KB cache mem: 1536676 KB, 453716 KB used, 1082960 KB free via: South Bridge: VIA vt82c686b, highest DMA rate: UDMA100, PCI clock: 33.3MHz hda: ST340016A, 38166 GB (78165360 sectors), CHS=4865/255/63, 2048 KB cache hda: buffered disk read timings: 27.83 MB/sec hda: buffer-cache read timings: 64.65 MB/sec Узел Windows

cpu: AMD Athlon(tm) processor, 949.991 MHz (1893.99 bogomips), 256 KB cache mem: 247908 KB, 21252 KB used, 226656 KB free via: South Bridge: VIA vt82c686b, highest DMA rate: UDMA100, PCI clock: 33.3MHz hda: ST340016A, 38166 GB (78165360 sectors), CHS=4865/255/63, 2048 KB cache hda: buffered disk read timings: 40.51 MB/sec hda: buffer-cache read timings: 168.42 MB/sec Узел Mech

cpu: AMD Athlon(tm) processor, 952.194 MHz (1900.54 bogomips), 256 KB cache mem: 770200 KB, 74848 KB used, 695352 KB free via: South Bridge: VIA vt82c686b, highest DMA rate: UDMA100, PCI clock: 33.3MHz hda: ST320011A, 19092 GB (39102336 sectors), CHS=2434/255/63, 2048 KB cache hda: buffered disk read timings: 41.03 MB/sec hda: buffer-cache read timings: 162.03 MB/sec Узел Term1

cpu: Celeron (Mendocino), 300.018 MHz (598.01 bogomips), 128 KB cache mem: 449084 KB, 18512 KB used, 430572 KB free hda: FUJITSU MPC3032AT, 3093 GB (6335280 sectors), CHS=785/128/63, 0 KB cache hda: buffered disk read timings: 12.01 MB/sec hda: buffer-cache read timings: 98.46 MB/sec Узел Term2

cpu: Celeron (Mendocino), 300.017 MHz (598.01 bogomips), 128 KB cache mem: 449084 KB, 31928 KB used, 417156 KB free hda: FUJITSU MPC3032AT LP, 3093 GB (6335280 sectors), CHS=785/128/63, 0 KB cache hda: buffered disk read timings: 11.70 MB/sec hda: buffer-cache read timings: 97.71 MB/sec Для те с т иро в а ни я данного кла с т е р а применяли с ь те с ты кла с с а A. Все тес ты были скомпилиров аны для запу с к а на четырёх и восьми узл ах. В каче с т в е коммуникационной среды испол ь з о в а л с я Fast Ethernet. Резул ь т а ты тес т о в и их сравн е ние пред с т а в л е ны в таблиц е 7. В приложении 1 пред с т а в л е н сценарий, испол ь з о в а н ный для запу с к а всех тес т о в.

MPI

MPI+OpenMosix

MPI

MPI+OpenMosix

MPI

MPI+OpenMosix

74

Класс S, 4 процесса Имя Размерность теста Время выполнения, с. задачи bt 12x12x12 2,15 3,7% cg 1400 1,96 5,1% ep 33554432 8,15 -24,7% is 65536 0,12 -133,3% lu 12x12x12 3,70 78,1% mg 32x32x32 0,17 -23,5% sp 12x12x12 1,75 -20,0% 18,00 2,8% bt 12x12x12 2,07 -3,9% cg 1400 1,86 -5,4% ep 33554432 10,16 19,8% is 65536 0,28 57,1% lu 12x12x12 0,81 -356,8% mg 32x32x32 0,21 19,0% sp 12x12x12 2,10 16,7% 17,49 -2,9%

Всего Mop/с. 106,11 33,96 4,11 5,69 27,66 44,18 55,13 276,84 110,13 35,86 3,30 2,38 128,22 36,88 47,21 363,98

3,8% 5,6% -19,7% -58,2% 363,6% -16,5% -14,4% 31,5% -3,7% -5,3% 24,5% 139,1% -78,4% 19,8% 16,8% -23,9%

Класс S, 8/9 процессов Имя Размерность теста Время выполнения, с. Всего Mop/с. задачи bt 12x12x12 3,48 -9,5% 65,56 -8,6% cg 1400 3,03 -11,6% 22,00 -10,4% ep 33554432 10,96 53,6% 3,06 115,7% is 65536 0,18 -83,3% 3,63 -44,6% mg 32x32x32 0,28 -21,4% 27,24 -17,5% sp 12x12x12 3,40 -9,7% 28,46 -9,0% 21,33 21,8% 149,95 -8,9% bt 12x12x12 3,81 8,7% 59,89 9,5% cg 1400 3,38 10,4% 19,71 11,6% ep 33554432 5,08 -115,7% 6,60 -53,6% is 65536 0,33 45,5% 2,01 80,6% mg 32x32x32 0,34 17,6% 22,48 21,2% sp 12x12x12 3,73 8,8% 25,90 9,9% 16,67 -28,0% 136,59 9,8% Класс A, 4 процесса Имя Размерность теста Время выполнения, с. задачи bt 64x64x64 2104,01 -246,2% cg 14000 39,82 35,3% ep 536870912 72,96 -122,6% is 8388608 17,03 -91,4% lu 64x64x64 946,47 33,6% mg 256x256x256 75,78 -4583,3% sp 64x64x64 1079,64 24,0% 4335,71 -188,3% bt 64x64x64 7283,12 71,1% cg 14000 25,78 -54,5% ep 536870912 162,43 55,1% is 8388608 32,59 47,7% lu 64x64x64 628,36 -50,6% mg 256x256x256 3549,02 97,9% sp 64x64x64 820,71 -31,5% 12502,01 65,3%

Всего Mop/с. 79,98 37,58 7,36 4,93 126,04 51,37 78,74 386,00 4,53 58,05 3,31 2,57 189,86 2,47 103,58 364,37

-94,3% 54,5% -55,0% -47,9% 50,6% -95,2% 31,5% -5,6% 1665,6% -35,3% 122,4% 91,8% -33,6% 1979,8% -24,0% 5,9%

Таблица 7. Резул ь т а ты те с т о в NAS Из ре зу л ь т а т о в видно, что отс т а в а ни е алг ори тмов балансиро в ки нагру з ки

75 openMosix от цикличе с к ой стра т е г и и распр е д е л е ни я незн ачи т е л ь н о для процес с о в, средне е время выполнения которых меньше минуты. openMosix значи т е л ь н о выигрыва е т при распр ед е л е нии долго в р еменных и треб о в а т е л ь ных зад аний между ге т е р о г е нными узл ами клас т е р а . Далее провед ём тес т с испол ь з о в а ни ем прогр аммы из приложения 2. Тест компилиру е т с я командой: $ mpicc mm.c -lm -o mm

Усреднённые ре зу л ь т а ты те с т о в по 10 запу с к ам привед ены в таблице 8. MPI+OpenMosix MPI

4 процесса Время выполнения, с. 35,26 -34,88% 47,57 25,86%

8 процессов Время выполнения, с. 158,56 54,64% 71,93 -120,46%

Таблица 8. Резул ь т а ты тес т а прогр аммы перемножения матриц

76

ВЫВОДЫ В данной работ е была пред с т а в л е н а мультикомпьютерн а я сис т ем а openMosix для масштабиру емых кла с т е р о в из PC и её эффективно с т ь при выполнении неско л ь ких больших паралл е л ь ных прикл адных прогр амм. В гл. 5.3 привед ён пример пост ро ения вычислит е л ь н о г о клас т е р а на её основ е. Основной паради гмой openMosix явл я е т с я то, что при напис ании паралл е л ь ных прогр амм можно придержива т ь с я обычного Unix прогр аммиров ания. В то же время, прогр аммы, исполь з ующие такие библиот е к и, как PVM и MPI, могут получит ь значи т е л ь н о е преимуществ о при испол ь з о в а н ии в ге т е р о г е нных кла с т е р а х. В гл. 7.2 раз р а б о т а н а методик а тес ти ро в а ни я и произ в е д е ны тес ты на основ е тес т о в NAS Benchmark. Исследов а ни я пока з а л и целе с ооб р а з н о с т ь испол ь з о в а н и я openMosix в каче с т в е аль т е рн а т и вы дорогих SMP-сис т ем за счё т сво ей открытос т и и дос тупно с т и. Производи т е л ь н о с т ь компьютерно г о кла с т е р а openMosix демонс триру е т хорошее испол ь з о в а н и е ресу р с о в, относи т е л ь н о хорошее увелич ение быстрод ей с т в и я при масштабиров а нии конфигу р ации и конкурен т о с п о с о б ные резу л ь т а ты при сра вн ении с дру гими сис т ем ами [BAR2]. Главный резу л ь т а т проек т а openMosix – это то, что возможно постр ои т ь дешёвый, масштабиру емый компьютерный кла с т е р из потреби т е л ь с к и х компонен т типа PC, UNIX и PVM, как аль т е рн а т и в у традиционных универ с а л ь ных ЭВМ (mainframes) и MPP. Главное преимущест в о openMosix по сра вн ению с дру гими компьютерными клас т е р ными сред ами – его способно с т ь отве ч а т ь во время выполнения на непред с к а з у емые и беспоряд о чные запро сы/треб о в а ни я к ресур с ам от многих поль з о в а т е л е й, например, время выполнения, исполь з о в а ни е памяти или число проце с с о в, – openMosix хорошо адап тиру е т с я ко всем таким случа ям. Также openMosix предл а г а е т удобную среду общего назна ч е ни я для выполнения крупномасштабных требов а т е л ь ных посл ед о в а т е л ь ных и паралл е л ь ных прикладных прогр амм. Проект openMosix расширяе т с я в нескол ь к их напра в л ени я х. Во-первых, разр а б а тыв аютс я новые конкурен т ные ал гори тмы для адапти вно г о управл е ни я ресур с ами, которые могут работ а т ь с различным видом ресу р с о в, например, нагру з к ой, памят ью, IPC и вводом – выводом. Также иссл ед уютс я ал го ри тмы для сет е в ой RAM, в которых большой проце с с может испол ь з о в а т ь дост упную память на нескол ь к их узл а х. Дополнит е л ь н о разр а б а тыв аютс я расширения к JAVA для поддержки адап тивной миграции объек т о в подобно ал го ри тмам openMosix. Кроме того, рас сма т ри в а е т с я перено с openMosix на различные OS (FreeBSD, MacOS).

77

СПИСОК ЛИТЕРАТУРЫ 3. MOSIX: MOSIX official web site, http://www.mosix.cs.huji.ac.il/ 4. oMosix: openMosix official web site, http://www.openmosix.org/ 5. BAR1: A. Barak, MOSIX – Scalable Cluster Computing for Linux, http://www.mosix.cs.huji.ac.il/slides/index.htm 6. BAR5: Barak A. and Braverman A., Memory Ushering in a Scalable Computing Cluster, http://www.mosix.cs.huji.ac.il/ftps/usher.ps.gz 7. BAR4: Barak A., La'adan O. and Shiloh A., Scalable Cluster Computing with MOSIX for LINUX, http://www.mosix.cs.huji.ac.il/ftps/mosix4linux.ps.gz 8. AMIR1: Amir Y., Awerbuch B., Barak A., Borgstrom R.S. and Keren A., An Opportunity Cost Approach for Job Assignment in a Scalable Computing Cluster, http://www.mosix.cs.huji.ac.il/ftps/opc.ps.gz 9. AMAR1: Amar L., Barak A., Eizenberg A. and Shiloh A., The MOSIX Scalable Cluster File Systems for LINUX, http://www.mosix.cs.huji.ac.il/ftps/mfs.ps.gz 10. BAR6: A. Barak, A. Braverman, I. Gilderman, and O. Laden, Performance of PVM with the MOSIX Preemptive Process Migration, June 1996 11. AWER1: B. Awerbuch, Y. Azar and A. Fiat, Packet Routing via Min-Cost Circuit Routing, 1996 12. BART1: Y. Bartal, A. Fiat, H. Karloff and R. Vohra, New algorithms for an ancient scheduling problem, 1992 13. ASPN1: J. Aspnes, Y. Azar, A. Fiat, S. Plotkin and O. Waarts, On-Line Machine Scheduling with Applications to Load Balancing and Virtual Circuit Routing, May 1993 14. AWER2: B. Awerbuch, Y. Azar, S. Plotkin and O. Waarts, Competitive Routing of Virtual Circuits with Unknown Duration, January 1994 15. BAL1: M. Harchol-Balter and A.B.Downey, Exploring Process Lifetime Distributions for Dynamic Load Balancing, May 1996 16. BAR3: A. Barak, S. Guday, and R.G. Wheeler, The MOSIX Distributed Operating System, Load Balancing for UNIX, 1992 17. HOWTO: Kris Buytaert et.al., openMosix-HOWTO, http://howto.ipng.be/openMosixHOWTO/ 18. BAR2: Barak A. and La'adan O., The MOSIX Multicomputer Operating System for High Performance Cluster Computing, March 1998

78

ПРИЛОЖЕНИЕ 1 Сценарий для провед е ни я тес т о в NAS benchmark #!/bin/bash function cleanup() { for node in `cat machines` do ssh root@$node "killall mpirun $cmd 2> /dev/null" done } function openmosix() { mode=0 if [ $1 = "stop" ]; then mode=1; fi for node in `cat machines` do ssh root@$node /dev/null #/etc/init.d/openmosix $* echo $mode > /proc/hpc/admin/lstay EOM done } function run_bench() { echo "Benching class \"$CLASS\", $PROC procs, $RUN run" >> nas_$RUN.out for cmd in bt.$CLASS.$PROC mg.$CLASS.$PROC do CMD="mpirun -np $PROC $* $cmd" echo -n "Running \"$CMD\"... " $CMD &> ${cmd}_$RUN.out echo -ne "${cmd:0:2}\t" >> nas_$RUN.out perl -ne ' $found ||= /Benchmark Completed/; next if !$found; /^ Size\s+=\s+(.*)$/ && (($s = $1) =~ s/\s+//g && print("$s\t") || print ("$s\t")) && next; /^ Time in seconds\s+=\s+([.\d]*)$/ && print("$1\t") && next; /^ Mop\/s total\s+=\s+([.\d]*)$/ && print("$1\n") && next; /^Version\s+=\s+(\w+)$/ && ($1 ne "SUCCESSFUL" && die || exit); ' < ${cmd}_$RUN.out >> nas_$RUN.out echo "ok" cleanup done } function run_suite() { #PROC=1 CLASS=S run_bench $* PROC=4 CLASS=S run_bench $* PROC=8 CLASS=S run_bench $* PROC=9 CLASS=S run_bench $* PROC=4 CLASS=A run_bench $* } function run_all_benches() { openmosix start run_suite openmosix stop run_suite "-machinefile machines" } function run_mm_bench() { openmosix start time mpirun -np 4 mm

79

time mpirun -np 8 mm openmosix stop time mpirun -np 4 -machinefile machines mm time mpirun -np 8 -machinefile machines mm } for RUN in 0 1 2 3 4 5 6 7 8 9 do run_mm_bench &> all_mm_$RUN.out done for RUN in 1 do run_all_benches done

80

ПРИЛОЖЕНИЕ 2 Программа перемножения матриц с испол ь з о в а н и ем MPI /****************************************************************************** * FILE: mm.c * DESCRIPTION: * In this template code, the master task distributes a matrix multiply * operation to numtasks-1 worker tasks. ******************************************************************************/ #include <stdio.h> #include <math.h> #include "mpi.h" #define NRA 600 #define NCA 670 #define NCB 500 #define MASTER 0 #define FROM_MASTER 1 #define FROM_WORKER 2 MPI_Status status; main(int argc, char **argv) { int numtasks, taskid, numworkers, source, dest, nbytes, mtype, intsize, dbsize, rows, averow, extra, offset, i, j, k, count; double a[NRA][NCA], b[NCA][NCB], c[NRA][NCB];

/* /* /* /* /* /*

number of number of number of taskid of setting a setting a

rows in matrix A */ columns in matrix A */ columns in matrix B */ first task */ message type */ message type */

/* /* /* /* /* /* /* /* /* /* /* /*

number of tasks in partition */ a task identifier */ number of worker tasks */ task id of message source */ task id of message destination */ number of bytes in message */ message type */ size of an integer in bytes */ size of a double float in bytes */ rows of matrix A sent to each worker */ used to determine rows sent to each worker */ misc */

/* matrix A to be multiplied */ /* matrix B to be multiplied */ /* result matrix C */

intsize = sizeof(int); dbsize = sizeof(double); MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &taskid); MPI_Comm_size(MPI_COMM_WORLD, &numtasks); numworkers = numtasks-1; /**************************** master task ************************************/ if (taskid == MASTER) { printf("Number of worker tasks = %d\n",numworkers); for (i=0; i