УДК 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: [email protected]
