Архитектура распределенных вычислений: от облака к туману и росе

Независимые вычисления, совместимые с облачными, называются росистыми (прости, Хабр, но другого хорошего определения Dew Computing на русском языке мы не нашли). Основной принцип росистых вычислений в том, что они восполняют основной недостаток облачных вычислений — требование к стабильному интернет-подключению. Хотя росистые вычисления и будут обеспечивать сервисы и функции в режиме оффлайн, по-прежнему вызывает недоверие длительность промежутка времени, в течение которого будет недоступно облако. Здесь поможет дополнительный уровень — туманные вычисления, который является своеобразной прослойкой между облачными и росистыми вычислениями. В этой статье, собранной из нескольких источников, мы рассмотрим данный концепт подробнее.

Введение

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

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

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

Иерархия распределенных вычислений

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

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

Архитектура на уровне устройств

Выше на рисунке показаны три слоя: слой пользователей, слой сообщества и слой облаков. Пользовательский слой состоит из устройств пользователей (персональных компьютеров, ноутбуков или мобильных устройств). Ноутбук и мобильные устройства подключены к серверу сообщества через беспроводные интерфейсы. Рабочий стол может быть подключен к серверу сообщества через серийный интерфейс или беспроводной интерфейс. При этом нет необходимости в активном подключении к интернету на устройствах пользователя, и они подключены к серверу сообщества через интерфейс, А с Wi-Fi или подключением по локальной сети. Однако другой интерфейс сервер, интерфейс B, будет подключен к интернету. Это делает возможным активную синхронизацию с облачными серверами.



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

Уровень приложений на примере системы оценки фильма

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



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

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

Архитектура уровня приложений

Обсудим два сценария, позволяющих лучше продемонстрировать концепт.

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

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

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

Вместо заключения

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