Создание отказоустойчивого проекта добровольных распределенных вычислений

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Правительство Российской Федерации

Федеральное государственное автономное образовательное учреждение высшего образования

«Национальный исследовательский университет «Высшая школа экономики»

Факультет компьютерных наук

Основная образовательная программа

Прикладная математика и информатика

Выпускная квалификационная работа

Создание отказоустойчивого проекта добровольных распределенных вычислений

Выполнил

студент группы 155, 4 курса,

Ефимов Даниил Леонидович

Научный руководитель:

с.н.с. ИППИ РАН, к.т.н.

Курочкин Илья Ильич

Москва 2019



Оглавление

сервер масштабирование распределенный вычисление

Введение

1. Обзор аналогичного ПО для распределенных вычислений

1.1 Discovery Net

1.2 HTCondor

1.3 Oracle Grid Engine

1.4 Архитектура серверов других BOINC проектов

2. Архитектура BOINC

2.1 Клиентская часть

2.2 Серверная часть

3. Риски отказа сервера проекта

4. Методы решения

4.1 Масштабирование

4.1.1 Вертикальное масштабирование

4.1.2 Горизонтальное масштабирование

4.2 Микросервисная архитектура

4.3 Репликация, шардирование и секционирование базы данных

4.3.1 Репликация

4.3.2 Шардирование

4.3.3 Секционирование

4.4 Балансировка нагрузки

5. Описание решения

5.1 Компоненты

5.1.1 Haproxy

5.1.2 Веб-сервер Apache и BOINC демоны

5.1.3 База данных MySQL

5.1.4 Обработчик и визуализатор логов ELK

5.1.5 Поставщик логов Metricbeat

5.2 Описание схемы

6. Развертывание

7. Тестирование

7.1 Нагрузочное тестирование

7.2 Моделирование отказа сервера

7.3 Моделирование отказа базы данных

Выводы

Список используемой литературы

Приложения



Глоссарий

Батч - набор данных.

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

Контейнер - изолированный экземпляр пространства пользователя, идентичный отдельному экземпляру операционной системы.

Инстанс - виртуальная машина, запускаемая и работающая в облаке.

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

Реплика - одна из копий базы данных, расположенная на отдельная сервере.

Скрипт - программный файл, предназначенный для автоматизации некоторой задачи.

Ключевые слова

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



Введение

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

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

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

Добровольные распределенные вычисления - сеть связанных между собой вычислительных устройств различной мощности (обычно настольных ПК, ноутбуков и телефонов), предоставляющих безвозмездно свои ресурсы для решения конкретных научных задач.

Одной из самых распространенных на данный момент платформ для добровольных вычислений является BOINC ^[1] - (Berkeley Open Infrastructure for Network Computing). Изначально её создавали разработчики Калифорнийского университета в Беркли для крупнейшего проекта - SETI@home^[2], но потом платформу сделали открытой для сторонних разработчиков, чтобы каждый научный проект смог воспользоваться ей и провести вычисления в различных областях науки - математике, физике, химии, биологии, астрономии, медицине и других. Проекты могут быть как публичными, с открытым участием добровольцев, так и внутренними, использующими только авторизованные устройства.

Актуальность

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



1. Обзор аналогичного ПО для распределенных вычислений

Возможность создания связанной сети компьютерных узлов для вычисления одной задачи было придумано человечеством еще в прошлом веке^[3]. Со временем появлялось все больше и больше реализаций данной идее как отдельными разработчиками, так и большими компаниями, и научными сообществами. Рассмотрим похожие на BOINC платформы для добровольных вычислений, такие как: Discovery Net^[4], HTCondor^[5][6], Oracle Grid Engine^[7].

1.1 Discovery Net

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

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

Граф описывается и хранится как DPML (Discovery Process Markup Language - XML-подобный язык). Его можно задавать как вручную с помощью данного языка, так и с помощью графического интерфейса методом drag-and-drop. В вершине графа хранится метаинформация о типах принимаемых и передаваемых данных, а также набор параметров, которые пользователь может менять в данной компоненте. Ребра графа показывают соединения компонент всей системы.

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

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

На текущий момент Discovery Net используется в научных проектах по биологии и физике, спонсируемых британской академией наук, и, например, в Biological Atlas of Insulin Resistance^[8], спонсируемом биомедицинским фондом Welcome Trust. Кроме того платформа была улучшена и доработана компанией InforSence для применения в коммерческих проектах.

1.2 HTCondor

HTCondor (до 2012 г - Condor) был разработан в университете Висконсина Мироном Ливни. Предпосылкой создания данного фреймворка послужило понимание научного сообщества, что использование большого количества маломощных компьютеров гораздо дешевле и легче в обслуживании, чем небольшого количества производительных машин или суперкомпьютеров эквивалентной мощности. На момент создания уникальность платформы состояла в возможности каждого участника вносить как большой, так и малый вклад в общее дело.

HTCondor - программное обеспечение с открытым исходным кодом для крупномасштабного распределенного распараллеливания вычислительных задач.^[6] Фреймворк имеет механизм управления заданиями, планировщик заданий, схему приоритетов, мониторинг и управление ресурсами. HTCondor можно запускать на большинстве популярных операционных системах и использовать как выделенные ресурсы, так и не выделенные (простаивающие настольные компьютеры) в одну вычислительную среду.

Фреймворк эффективно реализует следующие парадигмы: высокопроизводительные и оппортунистические вычисления. То есть позволяет производить большое количество длительных отказоустойчивых вычислений, используя все имеющиеся ресурсы, а также производить вычисления, не требуя доступности всех зарегистрированных ресурсов, соответственно. Для этого HTCondor имеет следующие инструменты:

ClassAd - гибкий и выразительный язык, предоставляющий структуру для сопоставления запросов ресурсов - задач, и предложений - вычислительных устройств. Он позволяет выбирать практически любую политику аллокации и планирования ресурсов.

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

Удаленные системные вызовы - позволяют сохранять локальную среду выполнения и перенаправлять потоки ввода/вывода на компьютер, отправивший задание.

Кроме того, планировщик заданий HTCondor может использоваться как один из компонент Globus Toolkit.

В итоге,

На текущий момент платформа активно развивается и обновляется раз в несколько месяцев. Она используется в NASA Advanced Supercomputing Division, который использует несколько суперкомпьютеров и хранилище в несколько десятков петабайт.

1.3 Oracle Grid Engine

Данное программное обеспечение также предназначено для гетерогенных распределенных вычислений. Клиентское приложение может работать на Linux, FreeBSD, MacOs и других unix-подобных системах.

Oracle Grid Engine позволяет проще регистрировать новые задачи, не привязываясь к отдельным проектам, в отличие от Boinc. Достаточно зарегистрироваться в системе, отправить на сервер задание с метаданными. Далее планировщик положит задание в очередь, где оно будет ожидать освобождения ресурсов. Когда ресурсы освободятся, планировщик отправит задание на удаленную машину, отследит выполнение задания и примет результат.

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

Shadow master - некоторое количество неактивных хостов, которые отслеживают состояние основного мастера и заменяет его в случае ошибок или сетевой недоступности.

Execution Daemon - клиент сети, получающий задания от мастера и выполняющий их.

ARCo - Accouting and Reporing Console позволяет в реальном времени собирать данные из системы и сохранять их в базу данных для дальнейшего анализа.

DRMAA - Distributed Resource Management Applictaion API - автоматизирует функции Grid Engine путем написания скриптов для запуска команд и обработки результатов.

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

Таким образом, Oracle Grid Engine больше подходит для вычислений заданий, полученных от большого числа независимых пользователей, в отличие от Boinc, которому требуется регистрация проекта и создание заданий от его администраторов.

В 2013 году Oracle продала все права на продукт компании Univa, развивающая продукт по настоящее время. Данное программное обеспечение используют: суперкомпьютер Tsubame в Токийском технологическом институте, суперкомпьютер Ranger в Техасском центре высокоскоростных вычислений, кластеры в Суперкомпьютерном центре в Сан-Диего и Геофизической лаборатории динамики жидкости. Кроме того летом 2018 года Univa продемонстрировала возможности масштабирования система на кластере AWS с 1 миллионом ядер. ^[8]

1.4 Архитектура серверов других BOINC проектов

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

В исследовании ^[5] авторы написали сообщения всем достаточно крупным BOINC проектам, чтобы узнать, вносили ли они изменения в исходный код серверной или клиентской части платформы, какие схемы развертывания они используют, с каким проблемами столкнулись в процессе эксплуатации.

Были опрошены такие проекты, как SETI@home, COSMOLOGY@home, MILKIWAY@home, WEATHER@home и другие.

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

Так, проект SETI@home имеет несколько серверов, на которых реализуется ручное масштабирование как горизонтальное, так и вертикальное. Для предотвращения потери данных используется репликация базы данных. Таблицы, отвечающие за взаимодействие с пользователями вынесены в оперативную память для ускорения доступа к ним.



2. Архитектура BOINC

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

2.1 Клиентская часть

Клиент - сервис, работающий на большинстве операционных систем, предназначенный для взаимодействия с BOINC-совместимыми проектами добровольных вычислений. Он использует протокол TCP/IP и может одновременно вычислять задачи от нескольких проектов.

Алгоритм работы клиента с сервером состоит из следующих действий:

Подключение к проекту и получение список URL планировщиков.

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

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

Завершение вычислений и отправление результатов планировщику.

Получение ответа от планировщика и запрос очередных задания и данных.

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

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

Следует упомянуть, что клиент на любой операционной системе позволяет настроить условия вычисления задач. Например, производить вычисления только при бездействии компьютера или при работе персонального устройства только от сети. Также пользователь может установить максимальный процент используемого процессорного времени или период времени, в течение которого BOINC-клиент будет активен, например, ночью.

2.2 Серверная часть

Сервер опять же состоит из нескольких компонент: HTTP веб-сервера, базы данных MySQL и набора демонов, осуществляющих основной функционал сервера.

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

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

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

Демоны -- это программы, написанные на С/С++, работающие в фоновом режиме и выполняющие все основные функции сервера распределенных вычислений.

Генератор заданий - создает из xml файла и необходимых входных файлов рабочие модули для отправки клиентам. Он существует в единственном экземпляре для всего проекта.

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

Служба подачи - загружает входные данные подзадач в разделяемую память. Может быть совмещена с планировщиком.

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

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

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

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

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

Мост - обеспечивает интеграцию фреймворка BOINC и грид-системы, например, Globus Toolkit.



3. Риски отказа сервера проекта

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

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

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

Цель

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

Задачи

Реализовать отказоустойчивость проекта с помощью микросервисной архитектуры.

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

Применить балансер сетевого трафика для постоянной доступности проекта.

Собирать системную и сетевую информацию для постоянного мониторинга состояния проекта.



4. Методы решения

Серверная часть Boinc обеспечивает работу всей сети, поэтому очень важно, чтобы этот компонент системы работал без отказов, а также имел возможность масштабирования. Для это может применяться несколько техник.

4.1 Масштабирование

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

Существует 2 принципиально разных способа масштабирования системы.

4.1.1 Вертикальное масштабирование

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

Преимущества:

Простата. Улучшение серверных компонент не требует изменения архитектуры.

Дешевизна и быстрота на начальных этапах.

Отсутствие программных проблем.

Недостатки:

При достижении определенного предела становится очень дорогостоящим.

Существует предел технических возможностей увеличения производительности аппаратных компонент.

4.1.2 Горизонтальное масштабирование

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

Преимущества:

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

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

Недостатки:

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

Согласно CAP ^[9] теореме, необходимо жертвовать согласованностью данных, доступностью или устойчивостью к разделению.

4.2 Микросервисная архитектура

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

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



Рис. 1. Монолит VS Микросервисы

В отличие от монолита микросервисы предоставляют следующие преимущества:

Модули легко заменяются и обновляются, независимо друг от друга. Они быстро масштабируются в зависимости от ситуации, в том числе и автоматическими средствами.

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

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

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

Стоит упомянуть также некоторые недостатки данной архитектуры:

Взаимодействие модулей происходит по сети, что очевидным образом приводит к задержкам и возможной порче данных.

Необходимость согласовывать формат сообщений и API (application programming interface) приводит к потенциальным ошибками, особенно с ростом количества сервисов.

Согласно CAP теореме необходимо выбрать 2 из 3 выполняемых свойств - согласованность данных в один момент времени, доступность системы и устойчивость к расщеплению системы на несколько изолированных секций.

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

4.3 Репликация, шардирование и секционирование базы данных

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

4.3.1 Репликация

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

Недостатком данного метода является необходимость увеличения количества дискового пространства для одного и того же количества уникальных данных.

Существует 2 типа репликации.

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

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

Master-Master. Данный тип репликации позволяет выполнять как операции чтения, так и записи на любом сервере. Но выход из строя одной из реплик практически всегда приводит к потере данных, что делает данный тип непривлекательным.

Рис. 2. Виды репликации

4.3.2 Шардирование

Данная техника позволяет разделять базу данных на отдельные части, чтобы их можно было вынести на отдельные серверы. Существует 2 типа шардирования.

Вертикальный - суть его заключается в вынесении таблицы или группы таблиц одной базы данных на отдельные серверы.

Горизонтальный - это разделение одной таблицы на несколько серверов по определенному принципу, например, по остатку от деления uuid объекта. Данная техника актуальна для очень больших таблиц, не умещающихся на одном сервере или количество запросов к которой превышает некоторое критическое значение.



Рис. 3. Виды шардирования

4.3.3 Секционирование

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

В отличие от шардирования, доступ к секциям контролируется одним экземпляром СУБД.

4.4 Балансировка нагрузки

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

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

Балансирующий узел - один или несколько серверов, отдельных или совмещенных с рабочей функциональностью, перенаправляющий (проксирующий) запросы на один из внутренних серверов.

Рис. 4. Схема балансировки нагрузки

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

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

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



5. Описание решения

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

Docker - программное обеспечение, позволяющее развертывать контейнеры в Linux среде с поддержкой cgroups и управлять ими в ручном или автоматическом режиме. Контейнеры описываются в Dockerfile в декларативном стиле и формате yaml. С помощью инструмента docker-compose можно настраивать и запускать несколько контейнеров одновременно, конфигурируя их взаимодействие между собой, например, общую сеть или хранилище, доступные порты и сокеты, последовательность запуска.

Архитектура реализованного отказоустойчивого BOINC проекта состоит из нескольких контейнеров:

Balancer Haproxy

Веб-сервер Apache и BOINC демоны

База данных MySQL

Обработчик и визуализатор логов ELK (Elasticsearch, Logstash, Kibana)

Поставщик логов Metricbeat

Рассмотрим данные контейнеры, а также их компоновку на развернутых виртуальных машинах подробнее.



5.1 Компоненты

5.1.1 Haproxy

Данный балансер предназначен для перенаправления трафика на веб-серверы для уменьшения нагрузки на проект и перераспределения трафика с недоступного на рабочие инстансы. Он размещается параллельно с обработчиком логов, так как сам по себе не требует больших вычислительных ресурсов, в отличие от обработчика. Конфигурирование данной контейнера можно увидеть в приложении 1.

5.1.2 Веб-сервер Apache и BOINC демоны

Веб-сервер предоставляет доступ к файлам заданий и веб-сайту проекта, а также позволяет загружать результаты заданий. Веб-сайт необходим создателям проекта для взаимодействия с пользователями, отображения статистики о подключенных хостах, их аппаратном обеспечении, запланированных и уже выполненных заданиях, количестве пользователей. Он позволяет зарегистрированным пользователям объединяться в группы для совместного участия в рейтинге. Конфигурирование данной контейнера можно увидеть в приложении 2.

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

Данные контейнеры были созданы и поддерживаются на данный момент пользователем marius311 на github.com. Совместно с MySQL они входят в репозиторий https://github.com/marius311/boinc-server-docker. Данные контейнеры разработаны так, что контейнер make_project выполняет все необходимые действия по компиляции и сборке сервера BOINC, после чего записывает все файлы в Apache-контейнер.



5.1.3 База данных MySQL

Она является одной из главных компонент всего проекта. В ней хранятся данные о пользователях, связанные с ними хосты, версии приложений, информация о заданиях, готовые входные данные для подзадач, результаты выполнения вычислений. База данных - одна из самых нагруженных компонент, поэтому необходимо конфигурировать её так, чтобы она не стала узким местом в системе. Конфигурирование данной контейнера можно увидеть в приложении 3.

5.1.4 Обработчик и визуализатор логов ELK

Данный открытый фреймворк включает в себя множество различных компонент.

Logstash - механизм сбора и обработки данных, который позволяет по пользовательским правилам нормализовать и фильтровать различные текстовые данные и отправлять их в Elasticsearch.

Elasticsearch - свободная программная поисковая система, обрабатывающая запросы от клиентов, доступных на многих языках программирования, а также от Kibana.

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

5.1.5 Поставщик логов Metricbeat

Одна из платформ Elastic стека для поставки данных в Logstash и Elasticsearch на ряду с Filebeat, Packetbeat, Auditbeat и другими. В нем реализовано несколько модулей для самых популярных программных обеспечений для корректной агрегации логов, например, Apache, MySQL, Haproxy, Nginx, Docker и другие. Соответственно, для всех используемых в данной работе ПО существуют модули по сбору данных. Конфигурирование данной контейнера можно увидеть в приложении 1, 2 и 3.

5.2 Описание схемы

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

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

На каждом инстансе также поднят контейнер Metricbeat с соответствующим модулем Apace, MySQL или Haproxy. Он отправляет все данные на инстанс с контейнером Elastic, к которому есть доступ через интернет.

Каждый из 3 типов комбинаций контейнеров разворачивается с помощью одной команды: “docker-compose up -d”. Не считая предварительной установки docker и скачивания нужных файлов из репозиториев на Github. Тем не менее это демонстрирует несомненное преимущество контейнеризации над обычными способами установки. Также стоит заметить, что дополнительные накладные расходы на виртуализацию не приносится, так как и основная, и внутренняя операционные системы построены на базе Linux.

Рис. 5. Архитектурная схема отказоустойчивого проекта BOINC



6. Развертывание

Архитектура разработанного отказоустойчивого проекта подразумевает создание как минимум 5 виртуальных машин: одна для балансера, две для веб-сервера и демонов и две для базы данных. По две машины нужно, чтобы протестировать работоспособность системы при отказе одной из них. Для удобного администрирования они были созданы в облаке Amazon, см. Рис. 6.

4 инстанса с 1 виртуальным ЦПУ и 0.5 Гб оперативной памяти для 2 серверов с Apache и BOINC демонами

1 инстанс с 1 виртуальным ЦПУ и 2 ГБ оперативной памяти для сервера с балансером и Elastic стеком. Последний требует повышенное количество оперативной памяти.

Рис. 6. Развернутые инстансы в облаке Amazon

Из внешней сети виден только балансер, на котором открыты порты 80 для HTTP и 5601 для Kibana. Все остальные виртуальные машины видны только и внутренней сети и только для своей безопасной группы (Security Groups).



Рис. 7. Пример дашборда Haproxy - балансировщика нагрузки

Рис. 8. Пример дашборда количества запросов по типам к базам MySQL

Настройки были вынесены в файл “.env” для единого конфигурирования развертываемых контейнеров и представляют из себя переменные окружения: URL баз данных, серверов Kibana и Elasticsearch, настройки BOINC сервера и другие.

Все 3 типа комбинаций контейнеров были вынесены в отдельные открытые репозитории Github:

Apache и BOINC демоны

https://github.com/Daniel-ef/boinc-server-docker

База данных MySQL

https://github.com/Daniel-ef/boinc_mysql

Балансер

https://github.com/Daniel-ef/boinc_balancer

Скачав их и изменив только URL компонент, указанных выше, можно запустить работающий отказоустойчивый BOINC сервер.



7. Тестирование

Тестирование развернутого проекта проверялось с помощью 3 виртуальных машин c 4 ядрами Intel Xeon E5620 и 1.5 Гб оперативной памяти. Мощностей данных машин хватит, чтобы провести функциональное и нагрузочное тестирование. Всего было проведено 3 теста на предельную нагрузку, отказ одного сервера и отказ одного инстанса базы данных.

7.1 Нагрузочное тестирование

Данное тестирование проводилось с помощью параллельных запросов на сервер к различным URL сервера, чтобы исключить кэширование повторяющихся запросов.

Конфигурация периодичности запросов:

Количество потоков: 10

Периодичность отсылаемых сообщений: 0.1 c

Рис. 9. Нагрузочное тестирование



Описание тестирования

Сначала были запущены скрипты, написанные на Python, посылаемые на веб-сервер проекта на 2 тестирующих виртуальных машинах. Далее постепенно увеличивалось количество потоков на 3 машине до 6 штук. После чего в 22:32:00 время ответа сервера начало сильно варьироваться, появился пик в 22:32:50 во время которого сервер обработал большой батч запросов. После чего количество соединений начало ещё сильнее флуктуировать и оба сервера полностью отказали (docker-сервис аварийно завершил работу, не выдержав нагрузки). Приблизительный RPS при котором серверы начали нестабильно работать - 45-50 запросов в секунду.

Результаты

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

7.2 Моделирование отказа сервера

Для тестирования отказоустойчивости на каждой из 3 виртуальных машин были развернуты клиенты BOINC. Для этого использовался готовый образ клиента из общедоступного репозитория и docker swarm.

Docker swarm - входящий в состав docker инструмент для развертывания контейнеров на кластере в автоматическом режиме. Он позволяет управлять масштабированием всей системы и управлением всем запущенными контейнерами с одного инстанса кластера.

Docker swarm позволяет используя несколько команд развернуть нужное количество клиентов BOINC на нескольких виртуальных машинах.

Описание тестирования

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

Рис. 10. Два сервера BOINC в рабочем состоянии

Рис. 11. Один из серверов выведен из строя

Видно, что с 13:51:40 по 13:56 оба сервера принимали одинаковое количество нагрузки, идущую от балансировщика. В 13:56 один из серверов был выключен, после чего, как и предполагалось, вся нагрузка перешла на второй сервер.

Рис. 12. Количество активных соединений с серверами

Кроме того, время ответа проекта от стабильного, примерно 12 мс, после отключения одного из серверов выросло практически в 4 раза до 50-70 мс и было нестабильным.



Рис. 13. Время ответа проекта BOINC

Результаты

Развернутый проект сохраняет работоспособность при отказе одного из серверов. При этом время ответа увеличивается более чем в 2 раза, но остается на достаточно стабильном уровне.

7.3 Моделирование отказа базы данных

Тестирование отказа одного из инстансов базы данных проводилось аналогично с тестированием отказа сервера. На 3 виртуальных машинах были запущены по 3 клиента BOINC. После чего реплика была выключена. Как и ожидалось, вся нагрузка по чтения перешла на мастер-сервер. На рисунке 10 показано, что до отключения реплики количество запросов на чтение было порядко 35-40 за 10 секунд, то есть порядка 3-4 запросов в секнуду. После отключения реплики RPS SELECT-запросов вырос в 2 раза до 7-8 запросов в секунду.



Рис. 14. Тестирование отказа истанса базы данных

Рис. 15. Количество запросов после отключения реплики.

Результаты

Отказ одной из реплик базы данных не ведет к прекращению работы всей системы. BOINC сервер автоматически переходит на работающий инстанс базы данных и продолжает работать в штатном режиме.

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



Выводы

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

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



Список используемой литературы

1. Официальный сайт BOINC - URL: https://boinc.berkeley.edu.

2. Официальный сайт SETI@home - URL: https://setiathome.berkeley.edu.

3. Ian Foster, Carl Kasselman “The grid: blueprint for a new computing infrastructure”, Morgan Kaufmann Publishers Inc. San Francisco, CA, USA ©1999.

4. Жurиin, V; Ghanem, M; Guo, Y; Kцhler, M; Rowe, A; Syed, J; Wendel, P (2002). "Discovery net". Proceedings of the eighth ACM SIGKDD international conference on Knowledge discovery and data mining - KDD '02. pp. 658-663.

5. M.J. Litzkow, M. Livny, M.W. Mutka “Condor-a hunter of idle workstations”, Distributed Computing Systems, IEEE, 1988.

6. Thain, Douglas; Tannenbaum, Todd; Livny, Miron (2005). "Distributed Computing in Practice: the Condor Experience".

7. http://wiki.gridengine.info/wiki/index.php/Main_Page.

8. Jack Dongarra, Thomas Herault1, Yves Robert “Fault tolerance techniques for high-performance computing”, Springer Verlag, May 2015.

9. Brewer, Eric A. Towards robust distributed systems (англ.) // Proceedings of the XIX annual ACM symposium on Principles of distributed computing. -- Portland, OR:ACM, 2000. -- Vol. 19, no. 7.

10. Bruno L. C. Ramos, Black Hat Europe 2007, “Challenging Malicious Inputs with Fault Tolerance Techniques”.

11. Robert Lovas. Orchestrated service deployment, maintenance and debugging in IaaS clouds for crowd computing // Institute for Computer Science and Control, Hungarian Academy of Sciences.

12. Armin Balalaie, Abbas Heydarnoori, Pooyan Jamshidi “Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture” EEE Software (Volume: 33, Issue: 3, May-June 2016).

13. Prabhjot Kaur1, Mr. Karan Mahajan “Various Techniques for Fault Tolerance in Distributed Computing System- A Review”, IJCSMC, Vol. 4, Issue. 5, May 2015, pg. 754-759.

14. "Univa Demonstrates Extreme Scale Automation by Deploying More Than One Million Cores in a Single Univa Grid Engine Cluster using AWS". Univa. 2018-06-24. Retrieved June 24, 2018.

15. Desktop grid computing: Cristophe Cerin, Giles Fedak. -Boca Raton: CRC Press, 2012.

16. Computer sharing loses momentum // Nature. -- URL: http://www.nature.com/news/computer-sharing-loses-momentum-1.14666 (дата обращения: 07.05.2016).

17. Е.Е. Ивашко. Desktop Grid корпоративного уровня // Программные системы: теория и приложения - 2014. -V. 19 -P. 183-190.

18. A.Cs. Marosi, Z. Balaton, P. Kacsuk, D. Drуtos. SZTAKI Desktop Grid: Adapting Clusters for Desktop Grids // Remote Instrumentation and Virtual Laboratories -2010. P. 133-144.

19. Diogo Ferreira, Filipe Araujo, Patricio Domingues. Custom execution environments in the BOINC middleware // Iberian Grid Infrastructure Conference -2010. -V. 4.

20. Balaton, Z. Farkas, G. Gombбs, P. Kacsuk, R. Lovas, A.C. Marosi, A. Emmen, G. Terstyбnszky, T. Kiss, I. Kelley, I. Taylor, O. Lodygensky, M. Cardenas-Montes, G. Fedak, F. Araujo. EDGeS: The common boundary between service and desktop grids // CoreGRID Integration Workshop -2008.

21. Franck Cappello, Samir Djilali, Gilles Fedak, Thomas Herault, Frйdйric Magniette, Vincent Nйri, Oleg Lodygensky. Computing on large-scale distributed systems: XtremWeb architecture, programming models, security, tests and convergence with grid // Future Generation Computer Systems -2005. -V. 21 -I. 3.

22. Franзoise Baude, Mireille Bossy, Viet Dung Doan, Ludovic Henrio, INRIA Sophia Antipolis. A Fault Tolerant and Multi-Paradigm Grid Architecture for Time Constrained Problems. Application to Option Pricing in Finance // IEEE International Conference -2006. -V. 2.

23. P. Kacsuk, Z. Farkas. Towards making BOINC and EGEE interoperable // IEEE International Conference -2008. -V. 4.

24. Antonio Amorim, Jaime Villate, Pedro Andrade. HEP@Home - A distributed computing system based on BOINC // Cornell university library -2004.



Приложение 1

version:'3'

services:

elk:

image: sebp/elk

ports:

- "5601:5601" #kibana

- "9200:9200" #elastic

- "5044:5044" #logstash beats filebeat

haproxy:

image: haproxy:latest

build:

context: ./haproxy/

ports:

- "80:80"

- "14567:14567"

- "1936:1936"

metricbeat:

build:

context: ./metricbeat

args:

- METRICBEAT_FILE=metricbeat.yml

- ELK_HOST=$ELK_HOST

- STAT_IP=$STAT_IP

container_name: metricbeat

depends_on:

- haproxy

- elk

volumes:

- /var/run/docker.sock:/var/run/docker.sock

environment:

- WAIT_FOR_HOSTS='${ELK_HOST}:9200 ${ELK_HOST}:5601'

- HOST_ELASTICSEARCH=$ELK_HOST:9200

- HOST_KIBANA=$ELK_HOST:5601



Приложение 2

version:"3.4"

volumes:

project:

results:

secrets:

logs:

services:

makeproject:

image: boinc/server_makeproject:$VERSION$TAG$DEFAULTARGS

build:

context: images/makeproject

target: makeproject$DEFAULTARGS

args:

- TAG

- BOINC_USER

- PROJECT_ROOT

- DB_HOST

- DB_REPLICA_HOST

volumes:

- "project:$PROJECT_ROOT.dst"

- "secrets:/run/secrets"

hostname: makeproject

environment:

- URL_BASE

- PROJECT

apache:

image: boinc/server_apache:$VERSION$TAG$DEFAULTARGS

build:

context: images/apache

target: apache$DEFAULTARGS

args:

- TAG

- BOINC_USER

- PROJECT_ROOT

- DB_HOST

- DB_REPLICA_HOST

hostname: $PROJECT

volumes:

- "project:$PROJECT_ROOT"

- "results:/results"

- "secrets:/run/secrets"

- "/dev/null:/run/secrets/keys/code_sign_private"

- "/var/run/docker.sock:/var/run/docker.sock"

- "logs:/var/log/apache2"

ports:

- "80:80"

tty: true

environment:

- URL_BASE

- PROJECT

metricbeat-host:

build:

context: ./metricbeat

args:

- METRICBEAT_FILE=metricbeat.yml

container_name: metricbeat

command: -system.hostfs=/hostfs

volumes:

- /proc:/hostfs/proc:ro

- /sys/fs/cgroup:/hostfs/sys/fs/cgroup:ro

- /:/hostfs:ro

- /var/run/docker.sock:/var/run/docker.sock

environment:

- "WAIT_FOR_HOSTS=172.31.44.103:9200 172.31.44.103:5601"

- "HOST_ELASTICSEARCH=172.31.44.103:9200"

- "HOST_KIBANA=172.31.44.103:5601"

extra_hosts:

- "172.31.44.103:172.17.0.1" # The IP of docker0 interface to access host from container

network_mode: host # Mandatory to monitor HOST filesystem, memory, processes,...



Приложение 3

version: "3.4"

volumes:

mysql:

services:

mysql:

image: boinc/server_mysql:latest

build:

context: ./

target: mysql

volumes:

- "mysql:/var/lib/mysql"

ports:

- "3306:3306"

metricbeat:

build:

context: ./metricbeat

args:

- METRICBEAT_FILE=metricbeat.yml

- ELK_HOST=$ELK_HOST

- HOST_IP=$HOST_IP

container_name: metricbeat

depends_on:

- mysql

volumes:

- /var/run/docker.sock:/var/run/docker.sock

environment:

- WAIT_FOR_HOSTS='${ELK_HOST}:9200 ${ELK_HOST}:5601'

- HOST_ELASTICSEARCH=$ELK_HOST:9200

- HOST_KIBANA=$ELK_HOST:5601

Размещено на Allbest.ru

...