CC BY
3ДОСЯГНЕННЯ ЕФЕКТИВНОГО РОЗПОД1ЛЕНОГО ПЛАНУВАННЯ ЗА ДОПОМОГОЮ ЧЕРГ ПОВ1ДОМЛЕНЬ У ХМАР1 ДЛЯ БАГАТОЗАДАЧНИХ ОБЧИСЛЕНЬ ТА ВИСОКОПРОДУКТИВНИХ ОБЧИСЛЕНЬ
Старовойтенко Олексш Володимирович,
Нац1ональний техмчний университет Украгни "Кигвський полШехтчний институт 1мен11горя Сжорського", ORCID ID: https://orcid.org/0000-0001-7365-3940
DOI: https://doi.org/10.31435/rsglobal_wos/30122020/7323
ARTICLE INFO
Received: 26 October 2020 Accepted: 14 December 2020 Published: 30 December 2020
KEYWORDS
FlexQueue, multitasking, cloud message queues, high-performance system, data consistency.
ABSTRACT
Due to the growth of data and the number of computational tasks, it is necessary to ensure the required level of system performance. Performance can be achieved by scaling the system horizontally / vertically, but even increasing the amount of computing resources does not solve all the problems. For example, a complex computational problem should be decomposed into smaller subtasks, the computation time of which is much shorter. However, the number of such tasks may be constantly increasing, due to which the processing on the services is delayed or even certain messages will not be processed. In many cases, message processing should be coordinated, for example, message A should be processed only after messages B and C. Given the problems of processing a large number of subtasks, we aim in this work - to design a mechanism for effective distributed scheduling through message queues. As services we will choose cloud services Amazon Webservices such as Amazon EC2, SQS and DynamoDB. Our FlexQueue solution can compete with state-of-the-art systems such as Sparrow and MATRIX. Distributed systems are quite complex and require complex algorithms and control units, so the solution of this problem requires detailed research.
Citation: Starovoitenko O. V. (2020) Achieve Efficient Distributed Scheduling with Cloud Message Queuing for Multitasking and High-Performance Computing. International Academy Journal Web of Scholar. 8(50). doi: 10.31435/rsglobal_wos/30122020/7323
Copyright: © 2020 Starovoitenko O. V. This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) or licensor are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.
Вступ. Метою системи планування завдань е ефективне управлшня розподшеною обчислювальною потужшстю робочих станцш, cepBepiB та cynepKOMn^TepiB з метою максимзацп пропускно! здатност роботи та використання системи. Прогнозуеться, що до кшця цього десятилггтя ми матимемо систему масштабування з мшьйонами вyзлiв i мшьярдами потоюв виконання [1].
На жаль, сучаст планувальт системи мають центрашзовану архитектуру Master/Slaves (наприклад, Slurm [2], Condor [3, 4], PBS [5], SGE [6]), де центрашзований сервер вщповщае за надання ресурав та виконання завдань. Ця архитектура добре працювала в масштабах обчислювальних мереж та грубих гранульованих робочих навантаженнях [7], але вона мае погану масштабовашсть при екстремальних масштабах систем iз дабнозернистими робочими навантаженнями [8, 9]. Ршенням ще! проблеми е перехщ до децентралiзованих архитектур, яю уникають використання одного компонента в якост менеджера. Розподшеш планувальт системи, як правило, реалiзyються в iерархiчнiй [10] або повтстю розподшенш архiтектyрi [31] для виршення проблеми масштабованосп. Використання нових архитектур може виршити потенцшну
едину точку вщмови та покращити загальну продуктивнiсть системи до певного piB^, але можуть виникнути проблеми при pозподiлi завдань та балансуванш навантаження мiж вузлами [25].
1дея використання хмарних сервгав для високопродуктивних обчислень iснуе вже кшька pокiв, але вона не набула популярносп в першу чергу через багато проблем. Маючи велик ресурси, публiчнi хмари можна використовувати для виконання завдань в екстремальних масштабах pозподiленим способом. Наша мета у цьому пpоектi - забезпечити компактну та легку pозподiлену структуру виконання завдань, яка працюе на Amazon Elastic Compute Cloud (EC2) [17], використовуючи складш pозподiленi бущвельш блоки, таю як Amazon Simple Queuing Service (SQS) [18] та Amazon, розподшений NoSQL ключ/значення сховища (DynamoDB) [33].
Було багато дослшницьких pобiт з використання загальнодоступного хмарного середовища для наукових обчислень та високопродуктивних обчислень (HPC). Бшьшють цих робгг показують, що хмара не могла виконувати добре пpацюючi науковi програми [11, 12, 13, 14]. Бшьшють юнуючих дослiдницьких pобiт використовували тдхвд використання публiчноl хмари як подiбний ресурс до тpадицiйних кластеpiв та супеpкомп'ютеpiв. Використання спiльних ресуршв та технологiй вipтуалiзацil робить загальнодоступш хмари зовсiм iншими, нiж традицшш системи HPC. Замiсть того, щоб запускати однi й тi ж традицшш програми на iншiй шфраструктур^ ми пропонуемо використовувати публiчнi хмарш сеpвiснi програми, якi оптимiзованi для хмарного середовища. Використання загальнодоступних хмар, таких як Amazon, як ресурсу для виконання завдань може бути складним для кшцевих коpистувачiв, якщо воно надае лише необроблену IaaS [34]. Було б дуже корисно, якби коpистувачi могли лише увшти в свою систему та надюлати завдання, не турбуючись про управлшня ресурсами.
Ще однiею перевагою хмарних служб е те, що користуючись цими службами, коpистувачi можуть впродовж короткого пеpiоду впровадити поpiвняно складш системи з дуже короткою базою коду. Наша мета - показати докази того, що користуючись цими послугами, ми можемо надати систему, яка надае високоякюш послуги, як вщповщають сучасним системам, iз значно меншою базою коду. У цт po6omi ми розробляемо та впроваджуемо масштабовану структуру виконання завдань на хмарi Amazon, використовуючирiзнi хмарш сервти AWS, i спрямовуемо ii на тдтримку обчислень i3 багатьма завданнями та високопродуктивнихробочих навантажень.
Найважлившим компонентом нашо! системи е служба просто! черги Amazon (SQS), яка дiе як служба доставки вмюту для виконання завдань, дозволяючи ктентам ефективно, асинхронно та масштабовано спшкуватися з сервюами. Amazon DynamoDB - це ще один хмарний сервю, який використовуеться, щоб переконатися, що завдання виконуються piвно один раз (це потpiбно, оскшьки Amazon SQS не гарантуе семантику доставки точно один раз). Ми також використовуемо Amazon Elastic Compute Cloud (EC2) для управлшня вipтуальними ресурсами. Завдяки можливост SQS одночасно доставляти надзвичайно велику кшькють повщомлень великш кшькосп коpистувачiв, система планування може забезпечити високу пропускну здатнють навт у бiльших масштабах.
Сучасна анаттика даних направлена до iнтеpактивних коротших завдань iз бiльшою пропускною здатнютю та меншою затримкою [35][10]. Бшьше програм використовуеться до запуску бшьшо! кiлькостi завдань з метою покращення пропускно! здатностi та пpодуктивностi програм. Хорошим прикладом для цього типу програм е багатозадачш обчислення (MTC) [15, 16, 39, 40]. Додатки MTC часто вимагають короткого часу для виршення i можуть вимагати значних комушкацш або даних [41].
Розподшеш системи управлшня роботою мають проблему низького використання через !х погану стратепю балансування навантаження. Ми пропонуемо FlexQueue як систему управлшня робочими мЩями, яка забезпечуе гарне балансування навантаження та велике використання системи у великих масштабах. Замють використання таких методiв, як випадкова вибipка, FlexQueue використовуе розподшеш черги, щоб коректно доставити завдання сервюам, не вимагаючи при цьому системи вибору мiж вузлами. Розподшена черга служить великим пулом завдань, як е високодоступними. Сервю виршуе коли отримати нове повшомлення. Такий шдхш забезпечуе простоту та ефективнiсть дизайну. Бшьше того, застосовуючи такий шдхщ, компоненти системи нещшьно зв'язанi мiж собою. Тому система буде високо масштабованою, надтною та простою в оновлент. Хоча мотивашею ще! роботи е пiдтpимка завдань MTC, вона також забезпечуе шдтримку pозподiленого планування HPC. Це дозволяе FlexQueue бути ще бшьш гнучким, одночасно виконуючи piзнi типи робочих навантажень.
Основним внеском ще! роботи е:
1. Спроектувати та впровадити просту та легку структуру виконання завдань за допомогою сервiсiв Amazon Cloud (EC2, SQS та DynamoDB), що тдтримуе як навантаження MTC, так i HPC
3. Оцтка продуктивностi до масштабу 1024 екземплярiв порiвняно з Sparrow та MATRIX: FlexQueue здатний перевершити iншi двi системи тсля масштабування 64 екземплярiв з точки зору пропускног здатностi та ефективностi.
Решта роздшв ще! статп е такими. В Роздш II продемонстровано деталi проектування та реатзацп FlexQueue. Роздш III оцшюе ефективнють FlexQueue у piзних аспектах, використовуючи piзнi показники. Роздш IV вивчае вшповшну роботу в галузi систем виконання завдань. Нарешп, роздш V обговорюе обмеження поточно! роботи та висв^люе майбутш напрямки ще! роботи.
Розробка та впровадження flexqueue.
Метою ше! роботи е впровадження системи планування/управлшня сервюами, яка вшповшае чотирьом основним цшям:
• Масштаб: пропонуемо збтьшити пропускну спроможтсть iз бтьшими масштабами через розподшет послуги
• Баланс навантаження: пропонуемо балансування навантаження у великих масштабах при неоднорiдних робочих навантаженнях
• Слабко зв 'язана: виршальне значення для того, щоб зробити систему стткою до несправностей i простою в обслуговувант
Для досягнення масштабованост FlexQueue використовуе SQS, який е розподшеним та дуже масштабованим. Як основний елемент FlexQueue, SQS може завантажувати та завантажувати велику юльюсть повшомлень одночасно. Незалежнють сервгав та ктенпв забезпечуе зручнють роботи системи в бшьших масштабах. Для забезпечення шших функцюнальних можливостей, таких як мошторинг або послшовшсть виконання завдань, FlexQueue також використовуе таю хмарш сервюи, як DynamoDB, яю е повнютю pозподiленими та масштабованими.
Рис. 1. Огляд архтектури FlexQueue Через використання хмарних служб витрати на обробку FlexQueue дуже низью. Багато програмних виклиюв у FlexQueue - це виклики до хмарних служб. Маючи абсолютно незалежш сервюи i ктенпв, FlexQueue не потpiбно збеpiгати будь-яку шформашю про сво! вузли, таку як IP-адреса або будь-який шший стан сво!х вузлiв.
Компоненти FlexQueue можуть працювати незалежно вiд компонента SQS посередиш, щоб вiдокpемити piзнi частини фреймворку один вiд одного. Це робить наш дизайн компактним, надшним i легко розширюваним.
Система планування може працювати в мiжплатфоpменнiй системi з можливiстю обслуговування в неодноршному сеpедовищi, яке мае системи з piзними типами вузлiв з piзними платформами та конфiгуpацiями. Використання розподшених черг також допомагае зменшити залежнють мiж клiентами та сервюами. Клiенти та сеpвiси можуть самостшно змiнювати свою швидкiсть pub/sub без будь-яких змiн у системi.
Yci вищезазначенi переваги покладаються на розподшену чергу, яка може забезпечити хорошу продуктивнють у будь-якому масштабi. Amazon SQS - це високошвидюсна хмарна
служба, яка може надати Bei функцп, необхщш для реалiзацiï масштабовано1' системи планування завдань. Використовуючи цей eepBie, ми можемо досягти мети - мати систему, яка щеально вписуеться в загальнодоступне хмарне середовище та оптимально працюе на своïх ресурсах.
Система полегшуе користувачам розподшену роботу над хмарними ресурсами, просто використовуючи ктентський iнтерфейс, без необхщносп знати деталi базових ресуршв, а також налаштовувати кластер.
А. Архтектура.
У цьому роздш пояснюеться системний дизайн FlexQueue. Ми використали дизайн на основi компонентiв для цього проекту з двох причин. (1) Дизайн на основi компонента краще шдходить для хмарного середовища. Це також допомагае розробити проект у вшьному поеднаннi. (2) Полшшити впровадження в майбутньому буде проспше.
У наступних роздiлах пояснюеться архтектура системи як для навантажень MTC, так i для HPC. FlexQueue мае можливють запускати робочi навантаження за допомогою сумiшi обох титв завдань. Перший роздiл показуе арх1тектуру системи на випадок виконання виключно завдань MTC. Другий роздiл описуе процес у разi запуску завдань HPC.
1) Управлшня завданнями MTC.
На Рис. 1. показаш рiзнi компоненти FlexQueue, яю беруть участь лише у запуску завдань MTC. Завдання MTC визначаеться як завдання, яке вимагае обчислювальних ресурсiв, як може задовольнити один cервiс (наприклад, там, де сервiс керуе ядром або вузлом). Ктентський вузол працюе як штерфейс для користувачiв для подання своïх завдань. SQS мае обмеження в 256 КБ для розмiру повщомлень, якого достатньо для розмiру завдання FlexQueue. Для надсилання завдань через SQS нам потрiбно використовувати ефективний протокол серiалiзацiï з низькими накладними витратами на обробку. З цiеï причини ми використовуемо буфер протоколу Google. Завдання збертае системний журнал тд час процесу, передаючи рiзнi компоненти. Таким чином, ми можемо повнютю зрозумiти рiзнi компоненти, використовуючи докладнi журнали.
Основними компонентами FlexQueue для запуску завдань MTC е Клiент, Сервю, Глобальна черга запита та Черги вщповщей ^ента. Система також мае динамiчний провайзер для управлiння ресурсами. Вш також використовуе DynamoDB для забезпечення монiторингу. Для кожного сервiса запущений пота мошторингу, який перiодично повщомляе про використання кожного сервiса до сховища значень ключа DynamoDB.
Клiентський компонент не залежить вiд шших частин системи. Вiн може почати виконувати та подавати завдання без необхщносп рееструватися в система Наявност адреси глобально!' черги достатньо, щоб компонент Клiента приеднався до системи. Ктентська програма багатопоточна. Тож вш може подавати кiлька завдань паралельно. Перед вщправкою будь-яких завдань Клiент створюе для себе чергу вщповщей. Усi поданi завдання мiстять адресу черги вщповщей Клiента. Клiент також мае можливють використовувати групування завдань, щоб зменшити накладш витрати на зв'язок.
З метою тдвищення продуктивност та ефективностi системи ми виршили встановити два режими. Якщо в системi виконуються завдання MTC, ус сервiси працюють як звичайнi сервюи. Але у випадку запуску навантажень HPC або навантажень iз комбшащею завдань HPC та MTC, ^м звичайних сервiсiв, сервiси також можуть стати або менеджерами сервюами, яю керують сервiсам HPC, або субсервюами, якi виконують завдання HPC.
Подiбно до компонента Клiент, компонент Сервю самостшно працюе в системi. Що стосуеться пiдтримки MTC, робоча функцюнальнють е вiдносно простою i прямою. Маючи загальну чергу запитiв, Сервюи можуть приеднатися до системи та вийти з не1' в будь-який час тд час виконання. Глобальна черга запита дiе як великий пул завдань. Ктенти можуть подавати сво1' завдання до цiеï черги, а сервю можуть витягувати iз не1' завдання. Використовуючи такий шдхщ, масштабованiсть системи залежить лише вщ масштабованостi Глобально1' черги, i це не призведе до додаткового навантаження на сервюв у бiльших масштабах. Код сервюа також е багатопотоковим i може паралельно отримувати кшька завдань. Кожен пота може об'еднати до 10 об'еднаних завдань. Знову ж таки, ця функщя зроблена для зменшення великих накладних витрат на зв'язок. Пюля отримання завдання робочий пота перевiряе дублювання завдання, а по^м перевiряе тип завдання. У разi запуску завдань MTC це одразу ж це зробить. По^м вш помiщае результати в завдання i використовуючи заздалепдь
задану адресу всередиш завдання, вiдправляe завдання назад в чергу вщповщ Клieнта. Як тiльки черга вщповщей отримуе завдання, вiдповiдний потш клieнта витягуе результати. Процес закшчуеться, коли Клieнт отримуе всi результати сво!х завдань.
2) Управлшня завданнями НРС.
На Рис. 2 показаш додатковi компоненти для запуску завдань HPC. Як зазначалося вище, у разi запуску поеднання завдань HPC та MTC кожен сервiс може виконувати рiзнi ролi. У разi отримання завдання MTC сервiс приступае до виконання завдання самостiйно. DynamoDB використовуеться для пiдтримки статусу системи, щоб сервiси могли приймати ршення про життездатнiсть виконання завдання HPC. По сутi, у DynamoDB ми збершаемо поточну кiлькiсть дiючих менеджерiв та пiдпорядкованих сервiсiв, якi зайнят виконанням завдань HPC, що дае шшим сервiсам уявлення про те, скшьки наявних ресурсiв iснуе.
Якщо сервiс отримуе роботу HPC. DynamoDB перевiряеться, щоб переконатися, що в системi достатньо доступних вузлiв, що iмiтують для виконання завдання HPC. Якщо це задоволено, сервiс (який тепер називаеться менеджером робочих) розмщуе п повiдомлень у другому SQS (Черга завдань HPC), п - кiлькiсть робочих мiсць, необхiдних робочому менеджеру для виконання завдання. Якщо недостатньо доступних ресуршв, вузол не може виконувати функцп менеджера сервюв; натомють цей вузол перевiрить Чергу завдань HPC та виступить у ролi допомiжного сервiса. Якщо в черзi HPC е повiдомлення, субсервю повiдомить менеджера, використовуючи IP-адресу робочого менеджера. Менеджер сервюа та субсервю використовують RMI для спiлкування. Пюля виконання менеджер сервiсiв надсилае результат до черги вщповщей, яку повинен забрати ктент.
Рис. 2. Огляд арх1тектури FlexQueue-HPC
Б. Питання узгодженостi виконання завдання.
Основним обмеженням SQS е те, що черга гарантуе доставку повщомлень принаймш один раз. Це означае, що можуть юнувати дублшати повiдомлень, що передаються сервюам. 1снування дублiкатiв повiдомлень походить вщ того, що цi повiдомлення кошюються на кiлька серверiв з метою забезпечення високо! доступностi та збшьшення можливостi паралельного доступу. Нам потрiбно запропонувати методику, яка запобiгае запуску дублшапв завдань, якi доставляе SQS. У багатьох типах навантажень виконання завдання бшьше одного разу неприйнятно. Для того, щоб бути сумюним для таких тишв програм, FlexQueue повинен гарантувати рiвномiрне виконання завдань.
Для того, щоб мати можливють перевiрити дублювання, ми використовуемо DynamoDB. Отримавши завдання, робочий потiк перевiряе, чи виконуеться завдання вперше. Робочий потш робить умовний запис у таблицю DynamoDB, додаючи унiкальний щентифшатор завдання, який е комбiнацiею щентифшатора завдання та iдентифiкатора клiента. Операщя завершуеться успiшно, якщо iдентифiкатор не був записаний рашше. В шшому випадку служба видае виняток для сервюа, i сервiс скидае дублшат завдання, не запускаючи його. Ця операцiя е атомарною операцiею.
Як ми вже згадували вище, рiвно один раз доставка необхiдна для багатьох тишв програм, таких як науковi програми. Але е деяю програми, якi мають меншi вимоги до послщовносп i все ще можуть функцiонувати без ще! вимоги. Наша програма мае можливють вимкнути цю функщю для цих програм, щоб зменшити затримку та збшьшити загальну
npogyKTHBHicTb. Mh bhbhhmo HaKnagHi BHTpaTH Ha цro ^yHKmro ^ogo 3aranbHOi npogyKTHBHocri CHCTeMH b po3gini оцiнкн.
C. fluHaMMHe 3a6e3neneHHR.
Ogmero 3 ronoBHux ^neö y ny6ninHOMy xMapHOMy cepegoBH^i e eKOHOMinHa e^eKTHBHicTb. flocTynHa BapTicTb pecypciB e ogmero 3 ronoBHux oco6nHBocTeö ny6ninHOi xMapu gna 3anyneHHa KopucTyBaniB. flna TaKOi cucreMH, ^o nigipuMye xMapy, gy^e Ba^nuBO nigTpHMyBaTH BHTpaTH Ha HaÖHH^noMy piBHi. flna gocarHeHHa eKOHOMinHOi e^eKTHBHocTi mh BnpoBagunu guHaMinHy CHCTeMy 3a6e3neneHHa. fluHaMinHuM nocTananbHHK BignoBigae 3a npu3HaneHHa Ta 3anycK hobhx cepBiciB go CHCTeMH, ^o6 He BigcTaBaTH Big BxigHoro HaBama^eHHa.
KoMnoHeHT guHaMinHoro nocTananbHHKa BignoBigae 3a 3anycK hobhx eK3eMnnapiB cepBiciB y pa3i Hecrani pecypciB. flogaTOK nepiogunHO nepeBipae 06'eM rno6anbHoi' nepru 3anmiB Ta nopiBHroe goB^HHy nepru 3 nonepegHiM po3MipoM. ^k^o mBugKicTb 36inbmeHHa nepeBH^ye go3BoneHy Me^y, BiH 3anycKae hobhh cepBic. ^k TinbKH 3any^eHHK, cepBic aBTOMaTHHHO npuegHyeTbca go cucTeMH. I irn-epBan nepeBipKH, i nopir po3Mipy HanamTOByroTbca KopucTyBaneM.
flna Toro, ^o6 3anponoHyBaTH pimeHHa gna guHaMinHoro 3MeHmeHHa MacmTa6y cucreMH, ^o6 yTpuMaTH HH3bKi BHTpaT mh goganu nporpaMy, ^o6 cepBicu Mornu npunuHHTH eK3eMnnap aK^o BHKOHyroTbca gBi yMOBH. Цe TpannaeTbca nume b TOMy BunagKy, aK^o cepBic Ha geaKHM nac nepexoguTb y pe^HM oniKyBaHHa, a TaKO^ aK^o eK3eMnnap Ha6nu^aeTbca go noHOBneHHa. EK3eMnnapu b Amazon EC2 cTaryroTbca ^oroguHH, i bohh 6ygyTb noHOBnroBaraca ^oroguHH, Konu KopucTyBan He BHMHKae ix. ^h MexaHi3M gonoMarae HamiM cucreMi aBTOMaTHHHO 3MeHmyBaTH MacmTa6u 6e3 Heo6xigHocTi OTpuMyBaTH 6ygb-aKHM 3anuT Big K0Mn0HeHTa. BuKopucTOByronu цi MexaHi3MH, cucreMa 3gaTHa guHaMinHO MacmTa6yBaTH Bropy i bhh3.
Puc. 3. Bapmicmb 36 '%3Ky
D. Bumpamu Ha cmnKyeaHHX.
3aTpuMKa Mepe^i m™ eK3eMnnapaMH b 3aranbHogoCTynmK xMapi nopiBHaHO BucoKa y nopiBHaHHi 3 cucTeMaMH HPC [36, 37]. flna gocarHeHHa po3yMHoi' nponycKHOi 3gaTH0cTi Ta
3aTpuMKH HaM n0Tpi6H0 MimMi3yBaTH HaKnagHi BHTpaTH Ha 3B'a30K Mm pi3HHMH KOMnoHemaMH
cucTeMH. Ha Puc. 3 n0Ka3aH0 KinbKicTb 3B'a3KiB, Heo6xigHux gna 3aBepmeHHa noBHoro цнкny 3anycKy 3aBgaHHa. flna BHKOHaHHa 3aBgaHHa icHye 5 KpoKiB. FlexQueue TaKO^ 3a6e3nenye rpynyBaHHa 3aBgaHb nig nac KpoKiB. KnieHT MO^e HagcunaTH KinbKa 3aBgaHb pa30M. MaKcuManbHHM po3Mip naKeTa noBigoMneHb y SQS cTaHOBHTb 256 KE a6o 10 noBigoMneHb.
E. Ee3neKa ma HadiÜHicmb.
^o cTocyeTbca cucTeMHOi 6e3neKH FlexQueue, mh noKnagaeMocb Ha 6e3neKy SQS. SQS 3a6e3nenye Hag3BHnaÖHO 6e3nenHy cucreMy, ^o BHKopucTOBye MexaHi3M aBTeHTH^iKami. Hume aBTopu3OBaHi KopuciyBani MO^yTb OTpuMaTH gocTyn go BMicTy Hepr. ^o6 36eperTH HH3bKy 3aTpuMKy, mh He gogaeMO ^ogHoro mu^pyBaHHa go noBigoMneHb. SQS 3a6e3nenye HagiÖHicTb, HagnumKOBO 36epiraronu noBigoMneHHa Ha geKinbKOx cepBepax i b geKinbKOx цeнтpaх o6po6KH gaHux [18].
F. flemanipeani3auiii.
Mh BnpoBagunu Bci KOMnoHeHTH FlexQueue b Node.js. Hama peaniзaцia 6araTonoTOKOBa aK b KOMnoHeHTax KnieHTa, TaK i b CepBicax. EaraTO ^yHK^M b o6ox цнх cucTeMax, TaKux aK MomTopum, y3rog^emcTb, KinbKicTb noTOKiB Ta po3Mip po36uTTa 3aBgaHb, MO^Ha HanamTyBaTH aK apryMeHT BBegeHHa nporpaMH.
O^HKa e^eKTHBHOCTi. Mh o^HroeMO npogyKTHBHicTb FlexQueue i nopiBHroeMO ii 3 gBOMa iHmuMH po3nogineHHMH cucTeMaMH ynpaBniHHa po6oToro, a caMe Sparrow Ta MATRIX. CnonaTKy mh o6roBopuMO ix oco6nHBocri BucoKoro piBHa Ta ocHOBHi BigMiHHocri. noTiM mh nopiBHroeMO ix
ефектившсть з точки зору пропускно! здатносп та ефективностi. Ми також оцшюемо затримку FlexQueue.
A. Порiвняння FlexQueue з шшими системами планування.
Нам було достатньо поpiвняти нашу систему з Sparrow та MATRIX, оскшьки щ двi системи представляють найкpащi у своему pодi pозподiленi системи упpавлiння завданнями з вщкритим кодом.
Sparrow був розроблений для досягнення мети управлшня мшюекундними сеpвiсами у шиpокомасштабнiй pозподiленiй система Вiн використовуе децентpалiзований пiдхiд pандомiзовано! вибipки для планування завдань на робочих вузлах. У системi е кшька планувальникiв, кожен iз яких мае список сервюв i розподшяе pобочi мiсця мiж сеpвiсами, приймаючи piшення на основi довжини черги робочих мюць.
У MATRIX на кожному комп'ютерному вузлi працюе планувальник, виконавець та сервер ZHT. Виконавець може бути окремим ланцюжком у планувальнику. Вс планувальники повнiстю пов'язаш з кожним, знаючи всi rnmi. Клiент - це iнстpумент стендово! pозмiтки, який видае запит на генеращю набору завдань i передае завдання будь-якому планувальнику. Виконавець продовжуе виконувати завдання планувальника. Кожного разу, коли планувальник не мае виконувати бшьше завдань, вш шщюе адаптивний алгоритм, щоб забрати завдання у планувальниюв-сусщв-кандпдапв. ZHT - це DKVS, який використовуеться для збереження метаданих задачi розподшеним, масштабованим та вшмовостшким способом.
Однiею з головних вшмшностей мiж Sparrow та FlexQueue або MATRIX е те, що Sparrow розподшяе завдання, тдштовхуючи !х до сервюв, тодi як FlexQueue та MATRIX використовують шдтягуючий шдхш. Кpiм того, в FlexQueue система надсилае клiентам результати виконання завдань. Але як у Sparrow, так i в MATRIX, система не надсилае будь-який тип повшомлень назад ктентам. Це може дозволити Sparrow та MATRIX працювати швидше, оскiльки це дозволяе уникнути ще одного кроку спiлкування, але також ускладнюе для клiентiв з'ясування, чи усшшно виконувались !х завдання.
B. Тестовий стенд.
Ми розгортаемо та запускаемо вш три системи на Amazon EC2. Ми використовували екземпляри t3.large на Amazon EC2. Ми провели вш нашi експерименти в ^rnpi обробки даних Amazon (us.eastl). Ми масштабували експерименти до 1024 вузлiв. Для того, щоб зробити експерименти ефективними, клiентський та робочий вузли запускаються на кожному вузль Ус екземпляри мали опеpацiйнi системи Linux. Наш фреймворк повинен працювати на будь-якш ОС, що мае Node12+, включаючи Ubuntu.
C. Пропускна здатшсть.
1) Завдання MTC.
Для того, щоб вимipяти пропускну здатшсть нашо! системи, ми запускаемо задачi sleep 0. Ми також поpiвняли пропускну здатнiсть FlexQueue iз Sparrow та MATRIX. У кожному екземпляpi запущено 2 потоки ктента та 4 pобочi потоки. Кожен екземпляр подае 16000 завдань. Рис. 4 поpiвнюе пропускну здатшсть FlexQueue iз Sparrow та MATRIX у piзних масштабах. Кожен екземпляр подае 16000 завдань iз загальним обсягом до 16.38 мшьйошв завдань у найбшьшому масштабi.
Пропускна здатнiсть MATRIX значно вища, шж FlexQueue та Sparrow у 1 екземпляри Причина полягае в тому, що MATRIX може виконувати багато детальних завдань локально, будь-яке планування або накладш витрати на мережу. Але на FlexQueue завдання повинш проходити через мережу, навiть якщо в OT^^i запущений один вузол. Розрив мiж пропускною здатнiстю систем зменшуеться, оскшьки накладш витрати на мережу додаються до двох шших систем. Планувальники MATRIX синхрошзуються мiж собою, використовуючи загальний метод синхрошзацп. Маючи занадто багато вiдкpитих TCP-з'еднань мiж сеpвiсами та планувальниками у масштабi 256 екземпляpiв, MATRIX стае нестабшьним. Пpодуктивнiсть мереж в хмаpi EC2 значно нижча, нiж у системах HPC, де MATRIX усшшно запущений у масштабах 1024 вузли.
too
i 4 W 04 Z1Q in;«
п 1ПНВПГТТ
Рис. 4. Пропускна здатшсть FlexQueue, Sparrow та MATRIX (завдання MTC)
Sparrow e найповшьшшою серед трьох систем з точки зору пропускно! здатносп. Вона демонструе стабiльну пропускну здатшсть з майже лiнiйним прискоренням до 64 e^eMraapiB. Оскiльки кiлькiсть eкзeмпляpiв збiльшуeться бiльшe нiж на 64, список eкзeмпляpiв для вибору для кожного планувальника на Sparrow збшьшуеться. Тому багато сервюв залишаються без роботи, а пропускна спроможшсть не збшьшиться, як очiкувалося. Ми не змогли запустити Sparrow у масштабi 128 або 256 пpимipникiв, оскшьки у планувальникiв було вiдкpито занадто багато сокенв, що призвело до збо!в системи.
FlexQueue досягае хорошого прискорення в 500 pазiв, починаючи з 238 завдань на секунду на 1 eкзeмпляpi до 119 тис. Завдань на секунду на 1024 екземплярах. На вiдмiну вщ шших двох систем, процес планування на FlexQueue не виконуеться екземплярами. Оскшьки управлшня завданнями здiйснюe SQS, продуктившсть системи в основному залежить вщ ще! послуги. Ми прогнозуемо, що пропускна здатшсть буде продовжувати масштабуватися, поки не досягне обмежень продуктивносн SQS (яких ми не змогли досягти до 1024 eкзeмпляpiв). Через бюджетш обмеження ми не змогли розширити наш масштаб понад 1024 екземпляри, хоча ми плануемо подати заявку на додатковi кредити Amazon AWS та перенести нашу ощнку на шкали eкзeмпляpiв 10K, найбшьшу допустиму кiлькiсть eкзeмпляpiв на користувача без попереднього резервування.
2) Завдання HPC.
Ми демонструемо пропускну здатшсть FlexQueue шд робочим навантаженням завдань HPC. Запуск завдань HPC додае систем бшьше накладних витрат, оскiльки буде виконано бшьше кpокiв для !х виконання. Замiсть того, щоб виконувати завдання вщразу, менеджеру сepвiса потpiбно пройти кшька кpокiв i почекати, щоб отримати достатньо peсуpсiв для запуску роботи. Використання DynamoDB сповiльнюe проботу системи та знижуе eфeктивнiсть робот. Але це не впливае на масштабовашсть. Використання FlexQueue може значно покращити час роботи робочих навантажень HPC, паралельно виконуючи завдання, яке зазвичай виконуеться послiдовно. Ми вибрали сepвiси з 4, 8 та 16 завданнями. На кожному eкзeмпляpi запущено 4 сервюш потоки. Кшьюсть виконаних завдань за кожною шкалою для piзних сepвiсiв однакова.
Рис. 5 поpiвнюe пропускну здатнiсть системи у випадку запуску завдань HPC з piзною кiлькiстю пiдзавдань на завдання. Результати показують, що пропускна здатшсть iмiтацiйних завдань iз бшьшою кiлькiстю завдань на одне завдання менша. На робочих мiсцях iз бiльшою кiлькiстю завдань потpiбно чекати, поки бшьше сервюв почнуть процес вимирання. Це додае бiльшe затримок i уповiльнюe роботу системи. Ми бачимо, що FlexQueue здатний досягти високо! пропускно! здатносп в 205 сервюах в секунду. Результати також показують хорошу масштабовашсть, оскшьки ми додаемо бшьше пpимipникiв.
1Л И U 4* U Н С'
Рис. 5. Пропускна здатшсть FlexQueue (завдання HPC)
D. Латентшсть.
Для точного вимiрювання затримки система повинна записати запит i вщповюти на позначки часу кожного завдання. Проблема Sparrow та MATRIX полягае в тому, що в процес виконання робочого часу сервюи не надсилають сповщення клiентам. Тому неможливо вимiряти затримку кожного завдання, порiвнюючи мiтки часу з рiзних вузлiв. У цьому роздiлi ми вимiряли латентнiсть FlexQueue та проаналiзували латентнiсть рiзних еташв процесу штампа.
На Рис. 6 показана затримка FlexQueue для режиму сну 0 мс, масштабування вщ 1 до 1024 екземплярiв. Кожен екземпляр запускае 1 клiентський потш i 2 робочi потоки i надсилае 16000 завдань на екземпляр.
IX)
1И ф
I»
Г м
j 4il
20
О
i
Рис. 6. Затримка завдань FlexQueue sleep 0 ms
Час затримки системи на 1 вузлi е вщносно високим, показуючи накладш витрати 95 мс, доданi системою. Але це буде прийнятно у бшьших масштабах. Той факт, що затримка не збшьшуеться бiльше 10 мс при збшьшенш кiлькостi екземплярiв з 1 екземпляра до 1024, свщчить про стабiльнiсть FlexQueue. SQS як пул завдань - це надзвичайно масштабований вiдправник, резервне кошювання якого складаеться з декiлькох серверiв, що забезпечуе вiдправника дуже масштабованим. Таким чином, масштабування системи шляхом додавання потоюв та збiльшення кшькосп завдань не впливае на продуктивнють SQS. Клiентський та сервiсний вузли завжди обробляють однакову кiлькiсть завдань у рiзних масштабах. Тому масштабування не впливае на екземпляри. FlexQueue включае кшька компонентiв, i його продуктивнють та затримка залежать вщ рiзних компонентiв. Результат затримки на Рис. 6 не показуе нам жодних подробиць щодо продуктивностi системи. Для того, щоб проаналiзувати ефективнють рiзних компонентiв, ми вимiрюемо час, який кожне завдання витрачае на рiзнi компоненти системи, рееструючи час шд час процесу виконання.
Рис. 7, 8 та 9 вщповщно показують сукупний розподiл етапу завдання доставки, етапу результату доставки та етапу виконання завдань на FlexQueue. Кожен етап спшкування мае три етапи: надсилання, чергу та отримання. Час затримки виклиюв API SQS, включаючи send-task та receive-task для обох, досить високий у порiвняннi з часом виконання завдань на FlexQueue. Причиною цього е дорога вартють дзвшюв API веб-служби, яка використовуе формат XML для зв'язку. Обробка сервюом займае 16 мс бшьше 50% випадюв. Сюди входить DynamoDB на який вiдводиться 8 мс у понад 50% випадюв. Це свiдчить, що гiпотетично затримка FlexQueue може значно покращитись, якщо ми використовуемо низьку розподiлену чергу повщомлень, яка може гарантувати рiвну доставку завдань. Ми розглянемо це докладшше в наступному роздiлi роботи.
Затримка (мс)
Рис. 7. Кумулятивний розподы затримки на emani виконання завдання
Затримка (мс)
Рис. 8. Кумулятивний розподш затримки на emani подання завдання 1ншим поманим моментом е рiзниця мiж часом виконання завдання та результатом доставки як у 4ep3i, так i при отриманш назад, навiть якщо вони мають однаковi виклики API. Час, витрачений завданнями на чергу вщповщей, перевищуе час, витрачений на чергу запипв. Причина полягае в тому, що у кожному екземплярi е два потоки сервюв i лише один потш клiента. Тому частота виконання завдань вища, коли завдання тягнуть робочi нитки.
0.9 0.8 0.7 _0.6 а? 0.5 ? 0.4 i 0.3
сг £ 0.2 LL
0.1
jj r1"1"^ rT*^"*^^
—queue time
10
35 40 45 50
15 20 25 30
Затримка (мс)
Рис. 9. Кумулятивний розподш затримки на етат доставки результату
E. Ефектившсть FlexQueue.
Для системи дуже важливо ефективно керувати системами. Досягнення високо! ефективност в розподшених системах планування сервюв не е тривiальним. Важко справедливо розподiлити навантаження на вшх сервсiах i зайняти вс вузли пiд час виконання у бшьших масштабах.
Для того, щоб показати ефективнiсть системи, ми розробили два набори експерименпв. Ми перевiряемо ефективнiсть системи на випадок однорщних та неоднорiдних завдань. Однорiднi завдання мають певну тривалють. Тому !х легше розподiлити, оскiльки планувальник передбачае, що для !х запуску потрiбен однаковий час. Це може дати нам хороший вщгук про ефектившсть системи у випадку запуску рiзних типiв завдань з рiзною деталiзацiею. Ми також можемо оцiнити здатшсть системи виконувати дуже довгi завдання. Проблема першого експерименту полягае в тому, що для виконання вшх завдань потрiбна однакова кiлькiсть часу. Це може суттево вплинути на ефектившсть системи, якщо планувальник не бере до уваги об'ем завдань. Випадкове робоче навантаження може показати, як планувальник працюватиме у випадку запуску реальних додатюв.
1) OdHopidHi навантаження.
У цьому роздш ми порiвнюемо ефектившсть FlexQueue iз Sparrow та MATRIX щодо допомiжних завдань. На Рис. 10 показана ефектившсть завдань на системи 1, 16 та 128 мс. Ефектившсть FlexQueue при виконанш завдань на 1 мс нижча, шж у шших двох системах. Як ми вже згадували рашше, затримка FlexQueue велика для дуже коротких завдань через значш накладш витрати мереж^ додаш в циклi виконання. Матриця мае кращу ефективнiсть на менших масштабах, але, як показуе тенденцiя, ефектившсть надзвичайно падае, доки система не вийде з ладу через занадто велику кiлькiсть компiляцiй TCP на масштабах 128 екземплярiв або бшьше. Для завдань сну 16 мс ефектившсть FlexQueue становить близько 40%, що е низьким (у
ropiBMHHi з шшими системами). Ефективнють MATRIX починаеться з бшьш шж 93% на одному екземпляр^ але знову ж вона падае до нижчо. ефективностi, нiж FlexQueue у бшьшш кiлькостi екземплярiв. Ми можемо пом^ити, що ефективнiсть FlexQueue дуже стабшьна в порiвняннi з двома шшими системами в рiзних масштабах. Це показуе, що FlexQueue досягае кращо. масштабованосп. У завданнях 128 мс для сну ефективнють FlexQueue сягае 88%. Знову ж таки, результати показують, що ефективнють MATRIX падае у бшьших масштабах.
Sparrow демонструе дуже хорошу та стабшьну ефективнють, виконуючи одноршш завдання до 64 екземплярiв. Ефективнiсть падае шсля цiеï шкали для коротших завдань. Маючи занадто багато сервюв для розподiлу завдань, планувальник не може мати шеального балансу навантаження, а деякi сервiси залишаються без обробки. Тому система буде недостатньо використана, а ефективнють знизиться. Система аваршно завершуе роботу на масштабах 128 або бшьше через те, що в планувальниках надто багато сокеив
1 4 16 64 256
Рис. 10. Ефективтсть FlexQueue, Sparrow та MATRIX, що виконують odnopidni робоч1 навантаження pi3noï тривалостi завдань (завдання 1, 16, 128 мс)
2) HeodHopidrn навантаження.
Для того, щоб вимiряти ефективнють, ми дослшили найбшьший доступний стд реальних робочих навантажень MTC [38] та вшфшьтрували журнали, щоб видшити лише допомiжнi завдання, яю об'еднали близько 2,07 млн завдань з дiапазоном часу роботи вш 1 мiлiсекунди до 1 секунди. Завдання були подаш випадковим чином. Середня тривалiсть завдання рiзних екземплярiв вiдрiзняеться одна вiд одно].'.
Кожен екземпляр виконуе в середньому 2K завдань. Порiвняння ефективностi на Рис. 9 показуе подiбнi тенденци щодо FlexQueue та MATRIX. В обох системах сервю тягне завдання лише тод^ коли у нього е доступш ресурси для запуску завдання. Тому той факт, що тривалють виконання завдань рiзний, не впливае на ефективнють системи. З шшого боку, у Sparrow планувальник розподшяе завдання, надсилаючи ]х сервюам, у яких менше черги завдань для виконання в черзь Той факт, що завдання мають рiзний час виконання, вплине на ефективнють системи. Деяю з сервiсiв можуть мати багато довгих завдань, а багато шших сервюв можуть виконувати коротю завдання.
# Екземпляри
Рис. 11. Ефективтсть систем, що використовують nеодnорiдni навантаження.
Будучи недостатньо використаним, ефективнють Sparrow мае найбшьше падшня з 1 примiрника до 64 примiрникiв. Система не працювала в 128 випадках i бiльше. Подiбним чином ефективнють MATRIX почалася з високо! ефективностi, але почала суттево падати через занадто багато вiдкритих соке^в на TCP-з'еднаннях. Ефективнiсть FlexQueue не така висока, як у двох шших системах, але вона е бшьш стабшьною, оскiльки зменшуеться лише на 6% вщ 1 до 64 примiрникiв порiвняно з MATRIX на 19% i Sparrow, що падае на 23%. Знову ж таки, FlexQueue була единою функцюнальною системою на 256 екземплярах iз 77% ефективнютю.
F. Накладт витрати на по^довшсть.
У цьому роздш ми ощнюемо вплив узгодженостi виконання завдань на FlexQueue. На Рис. 10 показана система запуску для 16мс сну з контролером дублювання вмикаеться i вимикаеться. Витрати на iншi завдання зi сну були подiбнi до цього експерименту. Отже, ми включили лише один iз експерименпв у цю роботу.
■■Overhead
—*— Exec. Consistency Disabled
-■-Exec. Consistency Enabled *
--- ................— ......
■— —.——■ ——"
■
_ щи
II111 1 1..... .......■.......■
# Екземпляри
Рис. 12. Виконайте накладт витрати на по^довтсть виконання завдань на FlexQueue Накладш показники консистенцн збшьшуються зi збiльшенням масштабу. Невiдповiднiсть у рiзних масштабах е результатом змiнноï кшькосп повторюваних повiдомлень при кожному запуску. Це призводить до бiльш випадково. продуктивностi системи в рiзних експериментах, загалом накладнi витрати за шкалою менше 10 становлять менше 15%. Ц накладш витрати служать здебшьшого для усшшних операцiй запису на DynamoDB. Ймовiрнiсть отримати дублiкати завдань зростае у бшьших масштабах. Тому винятюв буде бiльше. Це призводить до вищих накладних витрат. Накладш витрати у бшьших масштабах сягають до 35%. Однак ставка накладних витрат стабшьна i не перевищуе цю ставку. Використання розподшено. черги повщомлень, яка гарантуе доставку точно один раз, може значно покращити продуктивнють.
Пов'язана робота. Планувальники завдань можуть бути централiзованими, де единий диспетчер керуе поданням роботи та оновленням стану виконання; або iерархiчний, де кшька диспетчерiв органiзованi в топологи на основi дерева; або розподшений, де кожен обчислювальний вузол тдтримуе власну структуру виконання завдань.
Condor [3] був реалiзований для використання невикористаних циклiв процесора на робочих станцiях для тривалих пакетних робiт. Slurm [2] - це менеджер ресуршв, призначений для кластерiв Linux усiх розмiрiв. Вiн надае користувачам ексклюзивний та/або невиключний доступ до ресуршв протягом певного перюду часу, щоб вони могли виконувати роботу, i забезпечуе основу для початку, виконання та мошторинг роботи над набором видшених вузлiв. Портативна пакетна система (PBS) [5] була спочатку розроблена для задоволення потреб HPC. Вона може керувати пакетними та взаемоактивними робочими мюцями, а також додавати можливють сигналiзацiï, повторного запуску та змши завдань. LSF Batch [19] - це компонент розподшу навантаження та черги пакетiв у наборi iнструментiв управлiння навантаженням.
Висновки та майбутня робота. Широкомасштабш розподiленi системи вимагають ефективно. системи планування завдань для досягнення високо. пропускно. здатносп та використання системи. Важливо, щоб система планування забезпечувала високу пропускну здатнiсть та низьку затримку на бшьших масштабах та додавала мшмальну накладну витрату до робочого процесу. FlexQueue - це розподiлена програма виконання завдань, що пiдтримуе хмару,
яка працюе в xMapi Amazon AWS. Це ушкальна система з точки зору виконання робочих навантажень HPC та MTC у загальнодоступному хмарному середовищi. Використання служби SQS дае FlexQueue перевагу масштабованосп. Оцiнкa FlexQueue доводить, що вона е дуже масштабованою та забезпечуе стaбiльну продуктивнiсть у рiзних масштабах. Ми протестували нашу систему до 1024 екземплярiв. FlexQueue змiг перевершити iншi системи, таю як Sparrow та MATRIX, у масштабах 128 екземплярiв або бшьше з точки зору пропускно! здатносп. FlexQueue досягае ефективносп до 87%, виконуючи однорщш та неоднорiднi дрiбнозернистi завдання на секунду. У порiвняннi з шшими системами, такими як Sparrow, вш забезпечуе меншу ефективнiсть на менших масштабах. Але у бiльших масштабах вш досягае значно вищо! ефективносп.
1снуе багато нaпрямкiв для подальшо! роботи. Один iз нaпрямкiв - зробити систему повшстю незалежною та протестувати ïï на рiзних державних та приватних хмарах. Ми збираемось впровадити послугу, подiбну до SQS, з високою пропускною здaтнiстю на бшьших масштабах доступу. За допомогою шших систем, таких як розподшена хеш-таблиця ZHT [32], ми зможемо реaлiзувaти таку послугу. 1ншим майбутшм напрямком цiеï роботи е впровадження бшьш тiсно пов'язaноï версiï FlexQueue i тестування ïï на суперкомп'ютерах та середовищах HPC пiд час запуску завдань HPC розподшеним способом та порiвняння безпосередньо з Slurm та Slurm++ в тому ж середовищь
Л1ТЕРАТУРА
1. P. Kogge, et. al., "Exascale computing study: Technology challenges in achieving exascale systems," 2008.
2. M. A. Jette et. al, "Slurm: Simple linux utility for resource management". In Lecture Notes in Computer Sicence: Proceedings of Job Scheduling Strategies for Prarallel Procesing (JSSPP) 2003 (2002), SpringerVerlag, pp. 44-60.
3. D. Thain, T. Tannenbaum, M. Livny, "Distributed Computing in Practice: The Condor Experience" Concurrency and Computation: Practice and Experience 17 (2-4), pp. 323-356, 2005.
4. J. Frey, T. Tannenbaum, I. Foster, M. Frey, S. Tuecke. "Condor-G: A Computation Management Agent for Multi-Institutional Grids," Cluster Computing, 2002.
5. B. Bode et. al. "The Portable Batch Scheduler and the Maui Scheduler on Linux Clusters," Usenix, 4th Annual Linux Showcase & Conference, 2000.
6. W. Gentzsch, et. al. "Sun Grid Engine: Towards Creating a Compute Power Grid," 1st International Symposium on Cluster Computing and the Grid (CCGRID'01), 2001.
7. C. Dumitrescu, I. Raicu, I. Foster. "Experiences in Running Workloads over Grid3", The 4th International Conference on Grid and Cooperative Computing (GCC 2005), 2005.
8. I. Raicu, et. al. "Toward Loosely Coupled Programming on Petascale Systems," IEEE/ACM Super Computing Conference (SC'08), 2008.
9. I. Raicu, et. al. "Falkon: A Fast and Light-weight tasK executiON Framework," IEEE/ACM SC 2007.
10. S. Melnik, A. Gubarev, J. J. Long, G. Romer, S. Shivakumar, M. Tolton, and T. Vassilakis. "Dremel: Interactive Analysis of Web-Scale Datasets. Proc." VLDB Endow., 2010.
11. L. Ramakrishnan, et. al. "Evaluating Interconnect and virtualization performance for high performance computing", ACM Performance Evaluation Review, 40(2), 2012.
12. P. Mehrotra, et. al. "Performance evaluation of Amazon EC2 for NASA HPC applications". In Proceedings of the 3rd workshop on Scientific Cloud Computing (ScienceCloud '12). ACM, NY, USA, pp. 41-50, 2012.
13. Q. He, S. Zhou, B. Kobler, D. Duffy, and T. McGlynn. "Case study for running HPC applications in public clouds," In Proc. of ACM Symposium on High Performance Distributed Computing, 2010.
14. G. Wang and T. S. Eugene. "The Impact of Virtualization on Network Performance of Amazon EC2 Data Center". In IEEEINFOCOM, 2010.
15. I. Raicu, Y. Zhao, I. Foster, "Many-Task Computing for Grids and Supercomputers," 1st IEEE Workshop on Many-Task Computing on Grids and Supercomputers (MTAGS) 2008.
16. I. Raicu. "Many-Task Computing: Bridging the Gap between High Throughput Computing and High Performance Computing", Computer Science Dept., University of Chicago, Doctorate Dissertation, March 2009
17. Amazon Elastic Compute Cloud (Amazon EC2), Amazon Web Services, [online] 2013, http://aws.amazon.com/ec2/
18. Amazon SQS, [online] 2013, Retrieved from http://aws.amazon.com/sqs/
19. LSF: http://platform.com/Products/TheLSFSuite/Batch, 2012.
20. L. V. Kal'e et. al. "Comparing the performance of two dynamic load distribution methods," In Proceedings of the 1988 International Conference on Parallel Processing, pages 8-11, August 1988.
21. W. W. Shu and L. V. Kal'e, "A dynamic load balancing strategy for the Chare Kernel system," In Proceedings of Supercomputing '89, pages 389-398, November 1989.
22. A. Sinha and L.V. Kal'e, "A load balancing strategy for prioritized execution of tasks," In International Parallel Processing Symposium, pages 230-237, April 1993.
23. M.H. Willebeek-LeMair, A.P. Reeves, "Strategies for dynamic load balancing on highly parallel computers," In IEEE Transactions on Parallel and Distributed Systems, volume 4, September 1993.
24. G. Zhang, et. al, "Hierarchical Load Balancing for Charm++ Applications on Large Supercomputers," In Proceedings of the 2010 39th International Conference on Parallel Processing Workshops, ICPPW 10, pages 436-444, Washington, DC, USA, 2010.
25. K. Ousterhout, P. Wendell, M. Zaharia, and I. Stoica. "Sparrow: distributed, low latency scheduling". In Proceedings of the TwentyFourth ACM Symposium on Operating Systems Principles (SOSP '13). ACM, New York, NY, USA, 69-84.
26. M. Schwarzkopf, A Konwinski, M. Abd-el-malek, and J. Wilkes, Omega: Flexible, scalable schedulers for large compute clusters. In Proc. EuroSys (2013).
27. Frigo, et. al, "The implementation of the Cilk-5 multithreaded language," In Proc. Conf. on Prog. Language Design and Implementation (PLDI), pages 212-223. ACM SIGPLAN, 1998.
28. R. D. Blumofe, et. al. "Scheduling multithreaded computations by work stealing," In Proc. 35th FOCS, pages 356-368, Nov. 1994.
29. V. Kumar, et. al. "Scalable load balancing techniques for parallel computers," J. Parallel Distrib. Comput., 22(1):60-79, 1994.
30. J. Dinan et. al. "Scalable work stealing," In Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis, 2009.
31. A. Rajendran, loan Raicu. "MATRIX: Many-Task Computing Execution Fabric for Extreme Scales", Department of Computer Science, Illinois Institute of Technology, MS Thesis, 2013.
32. T. Li, et al., "ZHT: A light-weight reliable persistent dynamic scalable zero-hop distributed hash table," in IEEE International Parallel & Distributed Processing Symposium (IPDPS '13), 2013.
33. Amazon DynamoDB (beta), Amazon Web Services, [online] 2013, http://aws.amazon.com/dynamodb
34. P. Mell and T. Grance. "NIST definition of cloud computing." National Institute of Standards and Technology. October 7, 2009.
35. M. Zaharia, M. Chowdhury, M. J. Franklin, S. Shenker, and I. Stoica, "Spark: Cluster Computing with Working Sets," in Proceedings of the 2nd USENIX Conference on Hot topics in Cloud Computing, Boston, MA, June 2010.
36. P. Mehrotra, et al. 2012. "Performance evaluation of Amazon EC2 for NASA HPC applications" In (ScienceCloud '12). ACM, New York, NY, pp. 41-50.
37. I. Sadooghi, et al. "Understanding the cost of cloud computing". Illinois Institute of Technology, Technical report. 2013.
38. I. Raicu, et al. "The Quest for Scalable Support of Data Intensive Workloads in Distributed Systems," ACM HPDC 2009.
39. I. Raicu, et al. "Middleware Support for Many-Task Computing", Cluster Computing, The Journal of Networks, Software Tools and Applications, 2010.
40. Y. Zhao, et al. "Realizing Fast, Scalable and Reliable Scientific Computations in Grid Environments", book chapter in Grid Computing Research Progress, Nova Publisher 2008.
41. I. Raicu, et al. "Towards Data Intensive Many-Task Computing", book chapter in "Data Intensive Distributed Computing: Challenges and Solutions for Large-Scale Information Management", IGI Global Publishers, 2009.
42. Y. Zhao, et al. "Opportunities and Challenges in Running Scientific Workflows on the Cloud", IEEE CyberC 2011.
43. M. Wilde, et al. "Extreme-scale scripting: Opportunities for large task-parallel applications on petascale computers", SciDAC 2009.
