УДК 004.422.833 А.А. ЛУПАНДИН A.A. LUPANDIN

УДК 004.422.833
А.А. ЛУПАНДИН
A.A. LUPANDIN
ПОСТРОЕНИЕ ВЗАИМОДЕЙСТВИЯ ПОЛЬЗОВАТЕЛЯ С СЕРВИСОМ
ОБЛАЧНОГО ХРАНЕНИЯ ДАННЫХ
CONSTRUCTING USER INTERACTION WITH THE CLOUD STORAGE SERVICE
В данной статье автор освещает проблему построения взаимодействия пользователя с сервисом,
предоставляющим услуги облачного хранения данных, анализирует возможные методы его осуществления,
формирует общую схему построения взаимодействия и описывает зависимость системы взаимодействия от
требований, предъявляемых к целевому сервису облачного хранения данных.
Ключевые слова: облачные технологии, STaaS, интерфейс взаимодействия, методы обеспечения
взаимодействия, общая схема.
In given article the author highlights a problem of constructing a user's interaction with the service, which
provides services to cloud storage, analyzes the possible methods for its implementation, forms a common scheme for
constructing interactions and describes the dependence of the interaction with the requirements of the target cloud
storage service.
Keywords: cloud computing, STaaS, interaction interface, methods to ensure interaction, a common scheme.
Сервис облачного хранения данных (ОХД) позиционируется как STaaS (Storage as a
Service) решение, т.е. это бизнес модель, при которой провайдер предоставляет некоторое
пространство инфраструктуры хранения цифровой информации на основе подписки на
услугу. Таким образом, целью данного сервиса является хранение данных и обеспечение
доступа к ним.
Доступ к данным не возможен как в случае отсутствия или выхода из строя каналов и
вычислительных средств доступа, так и в случае отсутствия необходимых
производительности для выполнения прикладных задач. А поскольку отсутствие доступа к
данным для конечного пользователя равноценно отсутствию самих данных, то на средства
взаимодействия с сервисом ОХД ложится весь груз ответственности за успех сервиса среди
пользователей. Выбранные методы построения взаимодействия при этом имеют прямую
зависимость с надежностью и отказоустойчивостью конечного результата.
На основе произведенного анализа средств взаимодействия пользователей с
существующими сервисами ОХД можно выделить следующие методы их построения:
 построение взаимодействие на основе архитектуры «тонкого клиента»;
 построение взаимодействия на основе архитектуры «толстого клиента» с
применением технологий встроенных в ОС и прикладные приложения;
 построение взаимодействия на основе архитектуры «толстого клиента» с
применением специально разработанного драйвера или приложения без
жесткой интеграции сервиса ОХД в файловую систему ОС;
 построение взаимодействия на основе архитектуры «толстого клиента» с
применением специально разработанного приложения и драйвера,
обеспечивающего жесткую интеграцию ОХД в файловую систему ОС.
Как отмечается в [1]: «Сейчас под «тонким клиентом» подразумевается персональный
компьютер (ПК), подключаемый к локальной вычислительной сети, не выполняющий
никаких вычислительных задач, за исключением отображения экрана и передачи вводимой
информации от клавиатуры и мыши к серверу, на котором исполняется виртуальная
операционная система». В отношении веб-сервисов данному понятию можно дать немного
другую интерпретацию: «тонкий клиент» - это компьютер или программа-клиент в сетях с
клиент-серверной или терминальной архитектурой, который переносит все или основную
(большую) часть задач по выполнению операций обработке информации на сервер.
В случае использования сервисом ОХД метода взаимодействия на основе
архитектуры «тонкого клиента» от пользовательской системы не требуется ничего кроме
отправки и получения данных с сервера-шлюза, отображения иерархии (структуры)
хранящейся информации и предоставления пользователю возможности манипулирования её.
Данные задачи можно реализовать в полной мере и только средствами браузера
пользовательской системы.
Преимуществами использования метода построения взаимодействия, основанного на
архитектуре «тонкий клиент», являются отсутствие требований к высокой
производительности пользовательской системы и отсутствие необходимости в установке
дополнительного программного обеспечения. В качестве его недостатков можно выделить
отсутствие гибкости в выборе транспорта передачи данных, в силу чего, например,
безопасность передаваемой информации может быть обеспечена в лучшем случаем
стандартным средствами HTTPS, но в общем случае она вообще отсутствует и данные
передаются в открытом виде.
Остальные методы построения взаимодействия с сервисами ОХД основываются на
применении архитектуры «толстого клиента», являющейся полной противоположностью
рассмотренной. В общем случае данной технологией понимается использование специально
разработанного программного обеспечения, обеспечивающего полную функциональность и
независимость (своей работы) от центрального сервера. В данном случае практически всегда
сервер является только хранилищем пользовательских данных, а вся работа по обработке и
представлению информации переносится на пользовательскую систему.
Построение взаимодействия с применением технологий встроенных в ОС и
прикладные программы также как взаимодействие, основанное на архитектуре тонкого
клиента, не потребует от пользователя установку дополнительного программного
обеспечения. Кроме того, возможно производство обработки информации на стороне
клиента, с помощью которой возможно обеспечение кэширования, дополнительного
шифрования и других дополнительных механизмов. Однако список встроенных технологий
взаимодействия весьма ограничен, и он различается в зависимости от выбранных ОС и
прикладных программ. Среди доступных практически на всех ОС можно выделить
протоколы WebDAV, NFS и SMB(CIFS) для взаимодействия с облачным сервисом ОХД.
Каждый из них обладает своими особенностями, достоинствами и недостатками. Обобщая
данный метод взаимодействия с ОХД его можно охарактеризоваться отсутствием
необходимости в установке дополнительного программного обеспечения и возможностью
организации дополнительной обработки информации. Однако данная обработка возможна
только исключительно в рамках, предусмотренных выбранным протоколом. Например,
WebDAV поддерживает шифрование данных, но оно обеспечивается средствами HTTPS, на
основе которого он реализован. Следовательно, безопасность такого взаимодействия
абсолютно идентична варианту, построенному согласно архитектуре «тонкого клиента» с
применением протокола HTTPS. Но при этом существует и ряд неудобств для конечного
пользователя. Например, ему будет необходимо произвести дополнительную настройку
встроенных в ОС технологий для обеспечения взаимодействия по сравнению с методом
взаимодействия на основе архитектуры «тонкий клиент».
Для преодоления ограничений данного метода взаимодействия с сервисом ОХД
возможна его организация средствами специально разработанного приложения или
драйвера, включающего в себя весь необходимый функционал и требуемые методы
обработки информации. В таком случае конечно пользователю придётся произвести
установку необходимого программного обеспечения, но дополнительные настройки будут
минимальны.
Построение взаимодействия с сервисом ОХД с применением специально
разработанного программного обеспечения может сильно отличаться для конечного
пользователя. Оно может иметь жесткую или мягкую интеграцию в файловую систему
пользовательской ОС. В первом случае имеющиеся данные сервиса ОХД подключаются в
качестве узлов существующей файловой структуры. Данный подход хорошо знаком
пользователям ОС Unix, в котором для обозначения подключаемых узлов вводится понятие
«точка монтирования». Под ним понимается каталог, принадлежащий дереву каталогов
файловой системы и используемый для реализации возможности динамического
присоединения/отсоединения разделов диска во время работы операционной системы.
В Unix-подобных ОС данный механизм обеспечивается самим ядром системы. Для
остальных ОС требуется разработка специального драйвера для этого. В противном случае
для решения задач обеспечений взаимодействия с сервисом ОХД можно обойтись без
встраивания в пользовательскую файловую систему. При этом информация, хранимая на
сервисе ОХД, будет доступна по средством синхронизации хранящейся у пользователя
копии данных с серверной.
Поскольку некоторый дополнительный функционал (например, кэширование,
механизм дедупликации, шифрование и т.п.) может не требоваться при реализации средства
обеспечения взаимодействия с сервисом ОХД, то наиболее приемлем структурный подход к
анализу информационной системы. Его сущность заключается в декомпозиции (разбиении)
рассматриваемой системы на функциональные подсистемы, которые в свою очередь делятся
на подфункции, подразделяемые на задачи и т.д. При этом целость системы сохраняет свое
представление, в котором все составляющие компоненты взаимосвязаны.
Обобщив системы-аналоги и проанализировав их методы обеспечения
взаимодействия, можно сформировать общую модель функционирования данного вида
активностей. Рисунок 1 в полной мере отразил все предъявляемые требования к средствам
обеспечения взаимодействия с ОХД. В соответствии со структурным подходом в
представленной модели функционал системы представлен в качестве отдельных блоков,
выполняющих только заданную задачу.
Рисунок 1 – Общая модель обеспечения взаимодействия пользователя
с системой облачного хранения данных
Сервер, являющийся также шлюзом доступа при организации инфраструктуры
хранения в виде распределённых элементов, отвечает только за надежное хранение данных.
Для системы, обеспечивающей взаимодействие, требуется от него только интерфейс доступа,
с использованием которого возможно получение, изменение и отправка пользовательских
данных. В качестве такового, например, может выступать специально разработанное API,
WebDAV или CDMI. Они соответствуют наиболее распространенным интерфейсам доступа
и при этом базируются на основе протока HTTP, поэтому в общей модели, представленной
на рисунке 1, данные, передаваемые/получаемые сервером-шлюзом, указаны HTTPтрафиком.
Следующим функциональным блоком является транспорт. Он обеспечивает
преобразование данных к виду, определённому в соответствии с выбранным интерфейсом, и
их передачу или получение. При отсутствии дополнительной обработки обмениваемыми
блоками данных транспорт связывается непосредственно с механизмом представления,
иначе блоки подвергаются дополнительной обработке.
Блок механизма представления обеспечивает отображение полученных данных
пользователю и возможность их изменения. Это единственный функциональный блок,
непосредственно взаимодействующий с пользователем, следовательно, только от его
удобства и естественности, а точней его соответствия ментальной модели пользователя,
определяет степень успешности средств взаимодействия с сервисом ОХД в целом. Кроме
того, поскольку функционал блока представления данных манипулирует блоками данным, а
не цельными файлами и структурой каталогов, то ему требуется обеспечить преобразование
данных пользовательской файловой системы в компактные блоки, полностью описывающие
исходную информацию с добавлением контрольных сумм для проверки выполнения
обратной операции.
Над блоками данных между представлением и транспортом возможно выполнение
дополнительных преобразований в зависимости от требований, предъявляемых
определённым сервисом ОХД. На рисунке 1 в качестве них представлено шифрование,
кэширование и дедупликация. Однако такой набор может сильно изменяться: добавляться
новые элементы (например, проверка на наличие сигнатур популярных вирусов), удаляться,
а также меняться местами. Опять же выбранная дополнительная обработка блоков данных
зависит исключительно от требований и особенностей сервиса ОХД, но стоит отметить, что
вносимый функционал увеличит нагрузку и требования к пользовательской системе, а также
время отклика может настолько вырасти, что оно может восприниматься в качестве
зависания. В [2, с. 264] приводится следующую категоризацию времени отклика,
основанную на произведенных исследованиях:
 до 0,1 секунды: отклик воспринимается как моментальный;
 до 1 секунды: пользователи чувствуют, что система реагирует; задержка заметна,
но она недостаточно велика, чтобы прервать мыслительные процессы;
 до 10 секунд: пользователи замечают, что система работает медленно, и
отвлекаются, однако способны сохранить некоторое внимание к приложению;
 свыше 10 секунд: внимание пользователя полностью рассеивается, и он теряет
какой-либо интерес к системе; такие процессы лучше выполнять в фоновом для пользователя
режиме.
Таким образом, выбор метода обеспечения взаимодействия с сервисом ОХД зависит в
первую очередь цели использования. В случае простого временного и постоянного хранения
данных наилучшим вариантом, как для пользователей, так и для разработчиков является
построение взаимодействия на основе архитектуры тонкого клиента. Если необходима
дополнительная обработка информации (например, шифрование), вписывающаяся в рамки
стандарта какого-либо встроенного механизма, то – построение взаимодействия с
применением технологий интегрированных в ОС. Иначе потребуется разработка
дополнительного ПО, которое либо будет внедряться в пользовательскую ФС, либо
предоставлять пользователю копии хранящихся данных и возможность вносить изменения в
них. При этом наиболее универсальным является метод построения взаимодействия на
основе архитектуры «толстого клиента» с применением специально разработанного
приложения и драйвера, обеспечивающего жесткую интеграцию ОХД в файловую систему
ОС. Кроме того, формировать средства взаимодействия пользователя с сервисом ОХД
следует в соответствии с требованиями, предъявляемыми особенностями сервиса, и расчета
на максимальное время отклика на действие пользователя не превышающее 10 секунд.
СПИСОК ЛИТЕРАТУРЫ
1. Омельяненко, А. Технология «тонкий клиент» как инструмент повышения
эффективности инвестиций в ИТ-инфраструктуру [Электронный ресурс] // CIT Forum [сайт].
[2005]. URL: http://citforum.ru/nets/hard/thin_client/ (дата обращения 18.04.2014).
2. Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы
проектирования взаимодействия. – пер. с англ. СПб.: Символ-Плюс, 2009. 688с.
Лупандин Александр Александрович
ФГБОУ ВПО "Госуниверсистет - УНПК", г. Орёл
Магистрант кафедры «Информационные системы»
Тел.: +7 (920) 8097410
E-mail: shurik@skb-it.ru