К. Ю. Войтиков, П. Н. Тумаев
Филиал Кемеровского государственного университета в г. Анжеро-Судженске, Российская Федерация
Работа посвящена проектированию клиентского приложения для работы с сервером распределенных расчетов. Рассматриваются вопросы внутреннего устройства компонента, организация работы приложения по расписанию, реализация механизма модульного расширения системы, а также интерфейс веб-службы сервера, с которым будет работать данное приложение.
Рост вычислительной мощности современных компьютеров – не только непрерывный, но и постоянно ускоряющийся процесс. Растущие возможности суперкомпьютеров каждый год позволяют решать все более сложные задачи. Но помимо промышленных суперкомпьютеров не менее быстрыми темпами развивается сектор ПК и компьютерных сетей общего назначения. И существует целый пласт задач, также нуждающихся в огромных вычислительных мощностях, но практически решаемых при помощи задействования свободного времени обычных ПК.
В [1] была представлена архитектура сервера распределенных расчетов для объектно-ориентированной системы имитационного моделирования [2]. Задачами сервера являются получение и хранение заданий для системы, разделения их на сегменты, передача их «Удаленным калькуляторам» - компьютерам, непосредственно использующимся для выполнения расчетов, сбор и хранение результатов.
В свою очередь за сам процесс выполнения расчетов и отправку результатов на сервер отвечает компонент «Клиент».
Рассмотрим интерфейс веб-службы [3] сервера распределенных расчетов, с которым придется работать данному клиенту. Очевидно, что набор сервисов, предоставляемых службой, напрямую зависит от принципов взаимодействия с ее помощью клиента и сервера. Так как принципиально сервер расчетов является пассивным хранилищем заданий и результатов, основными действиями клиента по отношению к нему будут запрос и получение доступных заданий, а также отправка результатов их выполнения. Однако набор необходимых действий этим не ограничивается. Прежде всего, каждый новый клиент должен быть зарегистрирован в системе. Сервер расчетов хранит коллекцию данных обо всех зарегистрированных клиентах, их производительности и скорости сетевого соединения, ведет статистику их работы и на основе этих данных составляет наиболее оптимальные для каждого клиента списки заданий. Из этого также следует, что каждый клиент должен как минимум однажды провести тест производительности компьютера, на котором он установлен и скорость сетевого соединения с сервером, после чего передать эти данные серверу. В дальнейшем при необходимости возможно повторное проведение таких тестов и обновление сведений на сервере. Таким образом, основными методами службы сервера являются:
- RegisterClient() – регистрация клиента;
- SendRatings() – отправка данных о производительности;
- GetGridTasks() – получение заданий;
- SendGridResults() – отправка результатов.
Кроме этого служба предоставляет еще несколько методов вспомогательного назначения для проверки, нуждаются ли какие-то результаты в повторной отправке, и для получения журнала выполненных клиентом заданий и «списка ожидания» сервера. Эти методы существуют для обеспечения отказоустойчивости системы в непредвиденных случаях.
Внутреннее устройство компонента «клиент» представлено на рис. 1.
Рис 1. Структура компонента «клиент».
Подобно компоненту «сервер» задания и результаты их выполнения хранятся в виде экземпляров классов GridTask и GridResult соответственно. Подобно GridTaskRepository на сервере, здесь интерфейсом внешнего взаимодействия с данными коллекциями служит экземпляр класса ClientGridTaskRepository, немного отличающийся от первого набором предоставляемых функций.
Для координации работы всего компонента предназначен класс Controller. Экземпляр класса непосредственно совершает вызовы методов веб-службы сервера, диспетчеризирует получение новых заданий и отправку результатов, инициирует выполнение заданий и запуск тестов.
В организации сеансов связи с сервером важную роль играет то, что к работе системы планируется привлечь так называемый "volunteer computing" – предоставление сторонними пользователями свободного времени личных ПК для нужд распределенных расчетов. В этом случае каждый пользователь, и только он, должен иметь контроль над временем и условиями как совершения самих расчетов, так и передачи данных по сети. Для этой цели служит класс Scheduler (рис. 2), хранящий в виде коллекции объектов :Schedule заданные пользователем временные расписания работы или другие условия ее автоматического запуска/остановки (например, определенное время простоя ЦП). Объект Controller, в свою очередь, с заданным промежутком времени выполняет проверку, существует ли условие, согласно которому, в данный момент нужно совершить то или иное действие.
Рис 2. Реализация расписания работы компонента
Представленный в [1] механизм модульного расширения системы на стороне клиента реализуется следующим образом. Объекты GridResult, Calculator, а также TaskContent, инкапсулированные в GridTask, не являются прямыми экземплярами этих абстрактных классов, вместо этого объекты инстанцируют конкретные классы-потомки, описанные в подключаемом модуле. Так TaskContent имеет структуру и набор свойств, характерных для конкретного класса задач, GridResult представляет собой объект для хранения результатов, специфичных для такой задачи, а Calculator является непосредственным исполнителем необходимых для получения результата расчетов.
Итак, в ходе работы спроектирована архитектура клиентского компонента системы распределенных расчетов, отвечающая всем требованиям, характерным для такого рода задач. Предоставляемая пользователю возможность лично контролировать процесс использования времени компьютера призвана привлечь к работе системы большое количество добровольцев. А использование для связи компонентов системы технологии Microsoft WCF [3] облегчает требования к конфигурации сети на стороне клиента, что значительно увеличивает количество ПК, потенциально доступных для привлечения.
Литература
1. Войтиков К. Ю., Тумаев П. Н. Построение архитектуры сервера распределенных вычислений // Научное творчество молодёжи: материалы XIV Всероссийской научно-практической конференции (15-16 апреля 2010 г.). – Томск: Изд-во Том. ун-та, 2010. – Ч. 1. – С. 115-118
2. Войтиков К. Ю., Моисеев А .Н., Тумаев П. Н. Компонентная модель распределенной объектно-ориентированной системы имитационного моделирования // Вестник Томского государственного университета. Управление, вычислительная техника и информатика - 2010, N 1, С. 78-83
3. Резник С., Крейн Р., Боуэн К. Основы Windows Communication Foundation для .NET Framework 3.5: Пер с англ. – М.: ДМК Пресс, 2008. – 480 с.
Комментариев нет:
Отправить комментарий