Описание и анализ технологий для реализации задачи моделирования алгоритма

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

Среди различных форм организации и предоставления таких услуг, к которым относятся Saas (Software as a Service), Paas (Platform as a Service) и Iaas (Infrastructure as a Service), последняя является наиболее гибким решением, позволяющие разворачивать распределены «виртуальные офисы» и формировать программное окружение аналогичное тому, которое установлено на персональном компьютере или локальном сервере. Фундаментальный сдвиг в самой природе обработки информации. Она смещается в сторону модели Utility Computing, то есть предоставление вычислительных ресурсов по принципу коммунальных услуг, предполагает, во-первых, выполнение большинства вычислительных задач в специализированных дата-центрах, и, во-вторых, доставку полученных результатов по каналам Internet аналогично электрической энергии.

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

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

Традиционные архитектуры облачных систем предусматривают их построение на базе многоуровневой сетевой инфраструктуры виртуальных центров обработки данных (ЦОД) [8] и поддержки в виде программной платформы с набором сервисов. Типичная архитектура любого облачного ЦОД имеет иерархическую структуру, состоящую из 3 основных уровней:

Уровня ядра (Core). На этом уровне работают маршрутизаторы или коммутаторы 3 уровня, которые составляют основу всей сети дата-центра с высокоскоростными портами (10/40/100 GbЕ) для маршрутизации потоков между WAN и сети дата-центра.

Уровня агрегации (Aggregation или Distribution). На этом уровне также функционируют коммутаторы 3 уровня, основное назначение которых - распределение нагрузки между локальными сетями дата-центра.

Уровня доступа (Access). На этом уровне располагаются конечные точки (сервера, рабочие станции и др.) И сетевое оборудование, связывает конечные точки с уровнем агрегации. На уровне доступа функционируют кластера дата-центров, состоящих из множества физических серверов и большого количества виртуальных машин на каждом из них. На этом же уровне чаще всего располагается общая сеть хранения данных SAN (Storage Area Network). Группа, состоящая из взаимосвязанных компонентов хранения данных, вычислительных и сетевых ресурсов, которые работают совместно на уровне доступа, чтобы предоставить сервис или приложение клиенту называется точкой доставки или POD (Point of delivery).

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

Компоненты низкого уровня - сервера, которые объединяются в кластер. На каждом физическом сервере функционирует несколько виртуальных машин, то есть на одном физическом сетевом интерфейсе есть несколько виртуальных, обменом между которыми управляет программный компонент гипервизор (Virtual Machine Monitor / Hypervisor).

Облачные IT-инфраструктуры учебного заведения включают в себя следующие компоненты:

· ядро облака - ядро всей IT-инфраструктуры;

· персональные компьютеры в лабораториях, являются узлами облака.

Ожидаемая эволюция портала имеет две составляющие: развитие функционала и привлечения участников. Даже не прикасаясь финансовой, имеем многое реализовать. В общем, планируются следующие уровни использования и возможностей:

· социальная сеть для коммуникаций и поиска контактов;

· обменник идеями и проектами (онлайн-платформа по поиску работы);

· рабочее место для планирования и координации работы;

· база примеров коопераций и проектов, которая прогнозирует успех и дает советы.

Главным примером портала онлайн-общество GeoNet [15], которое объединяю разработчиков, исследователей, студентов, просто всех заинтересованных в развитии географически информационных технологий. Такое общество, направленное на информационные технологии и компьютерные науки, может быть даже более масштабным. В то же время, есть цель развить функционал профессиональных социальных сетей как LinkedIn [16] для построения резюме участников, добавить функциональность по трудоустройству на примере фрилансерских платформы oDesk [17], обеспечить облачный проектной и конфигурационный менеджмент как в YouTrack [18], так GitHub [19] соответственно.

Кроме того, уверенность в безопасности и приватности базируется на примере Telegram Messenger [1]. Конечно, все указанные веб-ресурсы являются лишь примерами и окончательный функционал должен соответствовать обобщенной группе участников: ученые и практики. Привлечение участников и определение приоритетов функций планируется через конференции, семинары (вебинары) и другие мероприятия.

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

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

В качестве хранилища было выбрано решение от Firebase, которое позволяет пользователю размещать файлы на удаленных серверах с помощью клиента или с использованием веб-интерфейса через браузер. При установке клиентского программного обеспечения Firebase на компьютере создается папка, синхронизированная с сервисом. Хотя главный акцент технологии делается на синхронизации и обмене информацией, Firebase ведёт историю загрузок, чтобы после удаления файлов с сервера была возможность восстановить данные [14]. Также ведется история изменения файлов, которая доступна на период последних 30 дней, кроме этого доступна функция бессрочной истории изменения файлов «PackRat».

История изменения файлов ведется по принципу diff-кодирование, чтобы сэкономить место, занимаемое файлами. В истории изменения записывается только отличие одной версии файла от другой. Файлы, загруженные через клиента, не имеют ограничения на размер, но файлы, загруженные через веб-интерфейс, ограниченные 300 МБ. Есть также возможность выкладывать файлы для общего доступа через папку «Public», что позволяет использовать сервис в качестве файлообменника. В версиях 0.8.x также появилась возможность предоставления в общий доступ любой папки в «My Firebase» для дальнейшего доступа через так называемый «shareable link», то есть через веб-интерфейс. Для совместной работы над проектами сервис имеет возможность создания «Shared» папок для общего доступа лиц, имеющих разные учетные записи на сервисе. Доступна автоматическая синхронизация файлов и папок и хранения версий с возможностью отката.

Для использования вышеупомянутых технологий от Firebase в приложениях был использован Firebase Cоre API. Защищенное соединение устанавливается с помощью токена и требует подтверждения от пользователя при использовании сервиса в приложении впервые.

Чтобы избежать постоянных подтверждений при передаче или загрузке файла, токен сохраняется в SharedPreferences [3] классе программы. Для работы синхронизации фоне был использован интерфейс AssyncTask [6]. Он дает возможность асинхронно выполнить код, не нарушая при этом работу потока графического интерфейса и рекомендован производителем для использования в задачах, требующих время исполнения не более 20-30 секунд для достижения оптимальной производительности интерфейса. Этот же интерфейс используется также в методах загрузки и закачки программы.

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

Облачные операционные системы представляют собой среду для выполнения программного кода на различных языках программирования. Corezoid обеспечивает поддержку JavaScript и Erlang.

Структура система представлена в виде набора конечных автоматов, каждый из которых имеет свои состояния. Такие состояния описываются следующей терминологией системы: «Ожидание», «Выполнение», «Ошибка».

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

В Corezoid API существует несколько способов сохранять настройки пользователей и информацию в зависимости от их назначения и использования.

SharedPreferences - класс для хранения настроек и небольших объемов информации другого типа [7]. Получить доступ к нему можно с любого класса, связанного с Activity или View. Минус - завязан на графический интерфейс и не подходит для хранения больших объемов информации. Класс SharedPreferences по умолчанию используется в классе PreferenceActivity для всех его параметров. В приложении от SHome SharedPreferences используется для хранения веб токена сервиса Firebase, настроек и лога системы при сбое. Пример использования:

SharedPreferences prefs = context.getSharedPreferences (FIREBASE_NAME, 0);

SharedPreferences.Editor edit = prefs.edit (); edit.putString ("KEY_TOKEN_PAIR", tokenPair) edit.commit ();

SQL Сonnector - класс, для развертывания и доступа к встроенной в систему Android базы данных SQL lite. Используется для хранения и последующей обработки больших объемов информации в базе SQL типа. В приложении SHome используется для хранения истории прогноз погоды, показаний с датчиков. Временные файлы или TempFile - файлы, которые будут удалены после закрытия программы. Используются для хранения временной информации.В системе SHome временные файлы используются для записи данных из БД для отправки в облачное хранилище. Также в бета-версии программы лог краш записывается во временный файл и отправляется на почту разработчиков.

В рамках бакаларвской работы предусматривается создание приложения, с помощью которого будет проводиться моделирование. Программа создается на языке программирования ActionScript 3 с помощью программного пакета Adobe Flash Builder 4.1 и Adobe Flash Professional CS5. Такой выбор обусловлен возможностями API Twitter и удобством интерфейса создает моего приложения благодаря технологии Adobe Flash.

Структура программы включает 10 классов, реализующих предусмотренную функциональность. Функции программы:

• Регистрация пользователя;

• Получение информации из профиля с помощью API «Twitter»;

• Отложенный постинг («Мои Заметки» → «Отложенный постинг»);

• Обработка информации с помощью «Corezoid» и «Twitter»;

• Вывод информации пользователю («База данных» → «Форма результатов»);

• Вывод информации администратору («XML База данных» → «Администратор») (рисунок 8).

Рисунок 8 – Схема работы приложения