CC BY
17
ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКИЕ
АСПЕКТЫ СЕРВИСА
УДК 338
ВНЕДРЕНИЕ ОБЛАЧНЫХ ХРАНИЛИЩ ДАННЫХ КАК ЭКОНОМИЧЕСКИЙ СПОСОБ ПОВЫШЕНИЯ КОНКУРЕНТОСПОСОБНОСТИ ОРГАНИЗАЦИИ
С.В. Мишина1, И.С. Иванников2, М.С. Тихомирова3
12Елецкий государственный университет им. И.А. Бунина, Россия, 399770, Липецкая область, Елец, ул. Коммунаров, д. 28;
3Санкт-Петербургский государственный архитектурно-строительный университет, Россия, 190005, г. Санкт-Петербург, 2-я Красноармейская ул., д. 4.
В работе проведен анализ проблем внедрения и функционирования облачных хранилищ данных на предприятиях и решена актуальная научная задача разработки моделей и методов повышения пропускной способности распределенных телекоммуникационных систем высокодоступных облачных хранилищ данных на основе новых протоколов доступа. В процессе изучения выделены технологические, функциональные и финансовые проблемы внедрения облачных хранилищ данных в организациях. Реализована архитектура системы на основе предложенных и смоделированных методов организации доступа к облачному хранилищу.
Ключевые слова: экономика, организация, облачные хранилища, защита.
THE INTRODUCTION OF CLOUD DATA STORAGE AS AN ECONOMIC WAY TO INCREASE THE COMPETITIVENESS OF THE ORGANIZATION
S.V. Mishina, I.S. Ivannikov, M.S. Tikhomirova
Yelets State University named after I.A. Bunin, Russia, 399770, Lipetsk region, Yelets, Kommunarov str., 28;
St. Petersburg State University of Architecture and Construction, Russia, 190005, St. Petersburg, 2nd Krasnoarmeyskaya str., 4.
The paper analyzes the problems of implementation and operation of cloud data storages at enterprises and solves an urgent scientific problem of developing models and methods for increasing the throughput of distributed telecommunication systems of highly available cloud data storages based on new access protocols. In the process of studying, the technological, functional and financial problems of implementing cloud data storages in organizations are highlighted. The architecture of the system is implemented based on the proposed and modeled methods for organizing access to the cloud storage.
Keywords: economics, organization, cloud storage, protection.
Введение
На современном этапе развития информационных систем весьма важную роль для организации стали играть облачные технологии. Огромное количество предприятий рассматривают возможность перехода к облачным технологиям, которые имеют большой потенциал для
повышения эффективности без ущерба для производительности.
Однако для того, чтобы реализовать все преимущества и получить наибольшую отдачу от вложенных инвестиций, организации должны принимать во внимание различные проблемы и особенности внедрения облачных технологий, уникальные для каждой конкретной ситуации.
1Мишина Светлана Викторовна - старший преподаватель кафедры экономики и управления им. Н.Г. Нечаева, тел.: +7 960-140-02-29, e-mail: svmishina2011@mail.ru;
2Иванников Илья Сергеевич - аспирант кафедры математического моделирования, компьютерных технологий и информационной безопасности, тел.: +7 915 555-39-15, e-mail: ivannikov.work@yandex.ru;
3Тихомирова Мария Сергеевна - кандидат юридических наук, доцент Архитектурно-строительного университета, e-mail: MariaKalini@yandex.ru.
Облачная система хранения данных, или хранения данных как услуга - это абстрактное понятие, которое соответствует системе хранения данных, которую можно администрировать по требованию через специальный интерфейс [1-3]. Этот интерфейс абстрагирует местонахождение системы, так что локальная она либо удаленная, либо гибридная - не имеет значения. Облачные инфраструктуры хранения данных образуют новые архитектуры, которые поддерживают различные уровни обслуживания поверх потенциально большой группы пользователей и географически распределенных накопителей. Важное значение имеет способность клиента контролировать и управлять тем, как хранятся его данные и, связанными с этим, расходами. Многочисленные поставщики облачных услуг предлагают средства управления, которые обеспечивают пользователям повышенный контроль над расходами.
Эффективность хранения данных - важная характеристика облачной инфраструктуры хранения, особенно учитывая ее акцент на общую экономию. Чтобы сделать систему хранения более эффективной, нужно хранить больше данных. Общим решением является сокращение объема исходных данных, чтобы они занимали меньше физического пространства. Два способа достижения этой цели: сжатие - упаковка данных путем их кодирования с использованием различных представлений - и дедупликация -исключение всех дубликатов данных [4; 5]. Хотя оба метода полезны, сжатие предполагает обработку (перекодирование данных в инфраструктуру и из нее), а дедупликация - вычисление сигнатур для поиска дубликатов.
Одна из наиболее особенностей облачного хранения данных - способность обеспечить экономию. Это экономия на приобретении накопителей, их энергоснабжении, ремонте, а также на управлении хранением. Если рассматривать облачное хранение с этой точки зрения (включая Service Level Agreement и повышенную эффективность хранения), оно может оказаться выгодным при определенных моделях использования. API (application programming interface) доступа к хранилищу является важнейшим компонентом услуг. Многие приложения требуют доступа к хранилищу услуг с использованием API, который оптимизирован для этой конкретной системы хранения данных, либо на собственном оборудовании или облачным. Так облачная система хранения Amazon S3 API предоставляет разработчикам SDK (software development kit) для .NET и Java, а также библиотеки для дополнительных платформ и язы-
ков. Эти интерфейсы обычно используют протоколы веб-сервисов передачи репрезентативного состояния (REST) и/или простой протокол доступа к объектам (SOAP) [6-8].
При рассмотрении архитектуры нужно учитывать ее рабочие параметры. Под ними понимают различные характеристики архитектуры, учитывая стоимость, производительность, возможность удаленного доступа и т.п. Архитектура облачного хранения данных - это прежде всего доставка ресурсов хранения данных по требованию в высоко-масштабируемой и мультиагентной среде. Обобщенно архитектура облачного хранения данных представляет собой внешний интерфейс, который предоставляет API для доступа к накопителям. В традиционных системах хранения данных это протокол SCSI (Small Computer System Interface), но в облачке появляются новые протоколы. Среди них можно найти внешние протоколы Web-сервисов, файловые протоколы и, даже, более традиционные внешние интерфейсы (Internet SCSI, iSCSI и др.). За внешним интерфейсом располагается уровень промежуточного программного обеспечения - логика хранения данных. Этот уровень реализует ряд функций, таких как репликация данных и сокращение объема данных, по традиционным алгоритмам размещения данных с учетом географического расположения. Наконец, внутренний интерфейс организует физическое хранение данных. Это может быть внутренний протокол, реализующий специфические функции, или традиционный сервер с физическими дисками.
Теоретический обзор
Быстрое увеличение пропускной способности компьютерных сетей позволило разрабатывать многочисленные приложения, которые предусматривают интенсивную обработку данных [1]. Эти новые приложения могут выполнять задачи, начиная от массовой передачи данных (SDSS (Sloan Digital Sky Surve) и electronic Very Long Baseline Interferometry), до интерактивных систем высокой пропускной способности (GeoWall) [2]. Однако, различные программы ставят различные требования к услугам передачи данных [3]. Например, приложение GeoWall может отдать предпочтение в плавном изменении скорости передачи данных, тогда как для приложения SDSS желательно, чтобы данные передавались с максимально возможной скоростью в частных сетях [4]. Тем не менее, нынешняя система интернет предназначена для обеспечения поддержки целого множества различного типа приложений. Эта философия дизайна Интернета оказывает большое влияние на
развитие транспортных протоколов. Большинство трафика в Интернете формируется за счет потоков TCP (Transmission Control Protocol), но существуют приложения, для которых протокол TCP не обеспечивает достаточного уровня эффективности. В контексте высокопроизводительных вычислений TCP хорошо известен своей низкой эффективностью и справедливым разделением ресурсов в сетях с высокой задержкой пропускной способности [5; 6].
Модификации сетевого стека ядра протокола (например, новые варианты TCP) обычно требуют нескольких лет для стандартизации, внедрения и широкого развертывания. В самом деле, со времен появления протокола TCP, около трех десятилетий назад, только его четыре версии были широко развернуты, а именно Ta-hoe, Reno, NewReno, и SACK [7]. Хотя на сегодняшний день все больше сетей получают скорость передачи данных 1 Гбит/с и выше, но по-прежнему актуальной проблемой для веб-приложений остается использование широкой полосы пропускной способности, из-за ограничения существующих транспортных протоколов сети. Ограничения внедренных сетевых транспортных протоколов является одной из главных причин, по которой так трудно масштабировать приложения с интенсивным использованием сетевых соединений от местных кластеров до глобальных сетей [8].
Протокол управления передачей (TCP) успешно используется в течение десятилетий, как основной протокол транспортного уровня стека сетевых протоколов. Однако в последнее время было показано, что TCP имеет некоторые потери производительности при его использовании для высокоскоростных сетей Wide Area, особенно для географически удаленных сетей. Алгоритм управления перегрузкой Additive increase/multiplicative decrease, который используется протоколом TCP, является довольно «бедным» в раскрытии доступной полосы пропускной способности и в случае большой потери пакетов в высокопроизводительных сетях с достаточно большими временами задержки [9].
Исследователи компьютерных сетей работают над новыми транспортными протоколами и алгоритмами контроля насыщения для поддержки высокоскоростных сетей следующего поколения. Многие работы, в том числе вариантов TCP (FAST, BiC, Scalable, и HighSpeed) и XCP показали более высокую производительность при их моделировании [10]. Однако практическое использование в реальных приложениях этих протоколов все еще очень ограничено из-за трудностей их реализации, установки и
ограничения технического уровня [11]. Пользователи сети, которым нужно передавать большие массивы данных обычно обращаются к решениям уровня приложений, среди которых очень популярные протоколы на основе UDP (User Datagram Protocol), например, SABUL, UDT (Data Transfer Protocol), Tsunami, RBUDP (Reliable Blast UDP), FOBS и GTP [12]. Протоколы на основе UDP обеспечивают гораздо лучшую переносимость и просты при их установке. Однако, несмотря на простоту внедрения протоколов на уровне пользователя достаточно трудно настроить их в ядре, чтобы сделать их максимально эффективными [13]. Поскольку реализации уровня пользователь не могут изменить код ядра, могут быть дополнительные переключения контекста и копированием участков памяти - между уровнем пользователя и уровнем ядра. На высоких скоростях передачи данных эти операции очень чувствительны к загрузке процессора и производительности протокола [14].
Материалы и методы
Для практического применения разработанных методов необходимо спроектировать и разработать распределенную систему хранения данных. Специфика современных хранилищ данных в переходе их к распределенным системам. В таких условиях необходимым условием является обеспечение резервирования критических узлов сети. Также важным условием является то, чтобы узлы сети владели информацией о наличии других узлов и данных на них. В условиях распределенной работы, необходимым функционалом работы является обеспечение своевременное выявление неработоспособного узла обмена/хранения данных и извлечения их с работы. Также после восстановления работы узла, он должен как можно скорее присоединиться к обмену / сохранению данных. Проектирование такой системы требует предварительного анализа требований и планирования ее внутренних процессов.
Программное обеспечение системы должно обеспечивать выполнение всех функций и иметь средства организации всех требуемых процессов обработки, передачи и хранения данных во всех регламентированных режимах функционирования. Программное обеспечение системы должно быть: универсальным; функционально достаточным; надежным; адаптивным; подходит для модернизации и масштабирования; иметь интуитивно понятный пользовательский интерфейс; защищенным от внешних воздействий; осуществлять документирование всех
действий пользователей программного обеспечения. Программное обеспечение должно разрабатываться с применением принципов структурного и модульного программирования. Каждая из задач, которая входит в систему должна быть максимально независимой от других.
Контроль качества программных средств, которые разрабатываются, должен быть обеспечен тестированием и проведением опытной эксплуатации. Архитектура системы должна базироваться на принципах высоко-нагруженных и отказоустойчивых систем. Она должна отвечать следующим основным требованиям: система должна поддерживать горизонтальное масштабирование серверов для увеличения производительности системы в целом (как узлов для хранения данных, так и сателлитов для улучшения эффективности доступа к данным); система должна иметь возможность дублирования всех критически важных узлов сети и хранения данных для обеспечения отказоустойчивости системы.
В состав системы должны входить следующие функциональные компоненты:
1. Хранилище данных как компонент информационной системы, который обеспечивает хранение данных для решения следующих задач: хранение данных; доступа к данным; учет действий пользователей.
2. Сателлит-компонент информационной системы, который обеспечивает быстрое информационное и техническое взаимодействие системы с пользователями системы.
3. Адаптивный DNS (Domain Name System) сервер - компонент системы, который обеспечивает логистику запросов от пользователя к системе.
Общими требованиями к надежности системы:
1. Программно-технический комплекс должен функционировать круглосуточно, в непрерывном режиме, кроме форс-мажорных обстоятельств.
2. Должно проводиться регулярное (не реже одного раза в сутки) резервное копирование баз данных. Необходимо наличие как минимум двух резервных копий всех данных. Резервные копии должны храниться в физически удаленных местах.
3. Отказы и сбои в работе рабочих станций и сетевых устройств не должны приводить к разрушению данных и сказываться на работоспособности системы в целом.
4. Выход из строя одной из подсистем не должен приводить к прекращению функционирования других подсистем, то есть при этом
должна обеспечиваться возможность выполнения функций всех других подсистем.
5. Плановая остановка или сбой информационного ресурса не должны приводить к сбою в работе программного обеспечения.
6. Неправильные действия пользователей не должны приводить к возникновению аварийной ситуации.
7. Должны быть минимизированы ошибки технического персонала, в том числе путем четкого разграничения прав доступа к системе, а также ведение журнала событий системы.
Под надежностью информационной системы понимают комплексное свойство системы сохранять во времени их основные свойства системы определены в установленных нормативно-технических документах. При таком понимании программное обеспечение должно: быть устойчивым к ошибочным действиям пользователя (ошибки в действиях персонала не должны приводить к сбоям (отказам) в работе программного обеспечения информационной системы); обеспечивать гарантированный контроль входящей и исходящей информации; обеспечивать быстрое восстановление после отказа (сбоев).
Программное обеспечение разрабатывается на основе распространенных операционных систем, инструментальных средств программирования и СУБД (система управления базами данных). Система должна использовать стандартные решения, основанные на применении типовых протоколов и интерфейсов взаимодействия, которые предусматривают возможность сопряжения и совместной работы оборудования и программного обеспечения различных производителей, а также для сопряжения с информационными системами других организаций. Все технические решения, используемые в проекте системы, должны соответствовать требованиям национальных стандартов или (при отсутствии) международных стандартов. Технические средства, применяемые в составе ИС, должны иметь сертификаты или другие документы предприятия-поставщика, подтверждающие их соответствие техническим условиям.
В силу большой социальной значимости проекта, и сжатых сроков ввода в эксплуатацию предпочтение следует отдавать унифицированным решением. Такие решения должны иметь следующие свойства: доступ к системе должен предоставляться с помощью глобальной сети Internet; модульность (компонентное решение); иметь возможность интеграции с внешними автоматизированными системами. Система должна обеспечивать выполнение следующих
функций: регистрация клиентов системы: o создание облачной записи компании в системе; o создание учетной записи администратора для компании; административная часть: o регистрация пользователей системы для компании; o редактирование профиля пользователя; обеспечение доступа к данным по протоколам: HTTP (HyperText Transfer Protocol); HTTPS (HyperText Transfer Protocol Secure); FTP (File Transfer Protocol); FTPS (File Transfer Protocol + SSL); SFTP (Secure File Transfer Protocol); обработка ошибок: ошибки хранилища; ошибки сателлитов; ошибки сценария; обрывы связи; большая нагрузка; регистрация действий пользователей.
Результаты и обсуждение
Проанализировав перечень необходимых функций и взаимосвязи между ними, целесообразно выполнить их представление в виде вариантов использования системы (рис. 1, 2). Система должна обеспечивать эффективную организацию обмена информацией между внутренними компонентами. Информационный обмен между компонентами системы должен осуществляться с использованием локальных вычислительных сетей и глобальных сетей передачи данных [15; 16]. Состав, структура, объем и частота передачи сообщений должны определяться соответствующими протоколами информационного обмена, определенными на стадии технического проектирования. В протоколах информационного обмена должны быть предусмотрены меры по исключению возможности несанкционированного доступа к данным.
Также должны быть предусмотрены средства контроля передаваемых входных / выходных данных и средства по контролю информации в базах данных. Требования к информационному обмену между компонентами системы должны быть определены на этапе разработки, исходя из возможностей платформы реализации [17; 18].
Общая архитектура системы состоит из адаптивного DNS сервера, нескольких хранилищ данных (DC) и многих сателлитов (рис. 3). Каждое хранилище данных должно определяться наличием (рис. 4): двух брандмауэров; двух серверов приложений; двух хранилищ с дисками. Такая архитектура необходима для обеспечения отказоустойчивости системы в случае потери физического узла сети [19; 20]. На первом этапе запросы приходят на уровень брандмауэров, которые для внешних узлов отображаются с одним и тем же IP (Internet Protocol)-адресом с индексами 0 и 1. В случае выхода устройства с индексом 0, то все запросы начинают попадать на устройство с индексом 1.
Рисунок 1 - Варианты использования системы с точки зрения Пользователя и Клиента системы
Рисунок 2 - Варианты использования системы с точки зрения Собственника системы
После получения запроса брандмауэром от пользователя, запрос попадает поочередно на доступный сервер приложений, статус доступности которого постоянно прослеживается на первом уровне. Два хранилища после аппаратного подключения, на аппаратном уровне подключаются как единое хранилище. Также на программном уровне настроена синхронизация данных между хранилищами, для обеспечения резервирования данных. Так, чрезвычайно быстро увеличивается быстродействие процес-
соров и объем оперативной памяти сервера программы без математически сложных алгоритмов не могут использовать полностью и упираются в количество пользователей, целесообразным является использование контейнеров (виртуализация на уровне операционной системы). Тогда, структурно сервер приложения будет состоять из нескольких контейнеров и балансировщика нагрузки (рис. 5).
Рисунок 3 - Общая архитектура системы
Рисунок 4 - Общая архитектура единичного хранилища
Рисунок 5 - Общая структура сервера приложения
Для мониторинга доступности сервисов в контейнерах существует несколько программных средств, самым популярным из которых является keepalived. Их недостатком при использовании в нашей архитектуре является отсутствие группировки сервисов. Поскольку одним из ключевых требований является возможность доступа к данным по FTP протоколу различных пользователей разных компаний (каждая компания имеет свой hostname), нам нужно для каждой компании иметь свой IP-адрес доступа (специфика использования FTP). FTP-server имеет возможность поддерживать одновременное использование многих IP-адресов. В таком случае keepalived на каждый IP-адрес будет пробовать создавать соединения и проверять доступность, а если их будет достаточное количество, то нагрузки на сервер для проверки доступности контейнеров будут увеличиваться в геометрической прогрессии. Для решения данной проблемы, спроектирована система, которая полностью заменяет функции keepalived, и имеет возможности:
- группировать IP-адреса и сервисы как один сервис (в случае недоступности, данный сервис перестает быть доступен по всем IP-адресам которые указаны. И наоборот, в случае повторной доступности сервиса, сервисы по всем IP-адресам становятся снова доступны);
- хранение статистики за всеми IP-адресами и сервисам с учетом: o количестве запросов; o передаваемых данных; o полученных данных; o потере работоспособности сервиса; o восстановлении работоспособности сервиса.
Архитектурно Сателлит соответствует архитектуре сервера приложения из хранилища данных. Ему не обходимо большого и надежного хранилища данных, поскольку он выступает исключительно «прокси-сервером» между клиентом и его данным. Также у нас нет необходимости его полностью дублировать, поскольку он не несет в себе критических данных и в случае выхода из строя, автоматически запросы, которые шли на него будут идти на ближние с ним другие сателлиты.
В работе современного облачного хранилища данных, которое использует информационные системы, должны быть обеспечены как можно более рациональная организация информационный потоков, так и существенное повышение их интенсивности, то есть ускорение передачи и обработки информации, поступающей от ее источника к потребителю. Для решения этих задач при проектировании информационной системы, прежде всего, проводится анализ информационных потоков, к:
- рассмотреть все звенья системы обработки и сохранения данных, начиная с получения исходных сведений, постепенное преобразование и формирование конечных данных, направляемых управляемой системе как команды в качестве отчетной и иной информации. При этом определяется роль каждого элемента системы в облачном хранилище данных, выполняемых системой и зафиксированных в схеме обработки данных, уточняется их структура и функции;
- построить схему информационных связей всех элементов системы между собой и внешней средой. В схеме могут оставаться сведения о конкретных формах информационных связей и указываются их количественные и временные характеристики;
- обнаружить первичные (выходные) для системы данные. Анализ потоков информации - важнейший этап в рационализации существующей системы хранилища данных, который должен обеспечить выполнение целевых задач проектирования.
Изучение потоков информации дает общее представление о функционировании системы и является первым шагом в анализе эффективного проектирования высоконагружен-ной системы обработки, хранения и передачи данных. Дальнейшее исследование информационных потоков позволяет выявить элементы информационного отображения объектов, отношения между ними, структуру и динамику потоков информации. Движение данных в системе, сопровождающееся соответствующими информационными потоками, является основой для обеспечения работы облачного хранилища данных. Между всеми элементами системы, функционирующие в среде хранилища данных, происходит непрерывное движение информационных потоков, которые обеспечивают поступления информационных данных, необходимых для осуществления анализа и передачи клиентских данных. Основными элементами системы являются (рис. 6):
1) хранилище данных - один из главных элементов системы, на котором физически и долгосрочно хранятся клиентские данные (рис.
7);
2) Сателлит доступа к данным - элемент доступа к данным в системе, который находится как можно ближе» к пользователям (потребителей данных), и имеет возможность временного хранения (кэширования) (рис. 8);
3) БК8-сервер - элемент системы, принимающий динамические обновления от других
элементов системы, и предоставляет достоверную и актуальную информацию пользователям данных.
Рисунок 6 - Диаграмма взаимодействия основных элементов системы
ЦТ>Т
я а
шт
ип|ут
ирт
»
щЬт
а
хДт
о
Рисунок 7 - Диаграмма размещения Сателлита
Рисунок 8 - Диаграмма размещения хранилища
Для актуализации информации о местонахождении доступных элементов системы и их доступности, используется DNS-сервер. Он выступает ключевым элементом информационного взаимодействия других элементов системы. Для этого каждый элемент системы с
определенной периодичностью присылает информацию о себе и авторизуется на DNS-сервере используя TCP соединение (рис. 6). В свою очередь, другие элементы системы обмениваются информационными данными с помощью протокола данных, который основывается на UDT (рис. 9). Хранилища данных, как элемент системы управления данными активно потребляет информационные ресурсы и, соответственно, является получателем и отправителем информационных потоков. Сателлит как элемент потребления данным также активно потребляет информационные ресурсы в двустороннем направлении. Для более детального анализа потоков данных, необходимо рассмотреть каждый элемент системы в разрезе данных и подсистем данного элемента.
Контейнер приложения - это полноценная копия программного приложения который обрабатывает запрос пользователя и возвращает ему результат работы. Контейнер хранилища данных (рис. 10) получает и выполняет запросы исключительно по протоколу UDT для чего в контейнере запущены независимые процессы UDT-сервер и UDT-клиент. С помощью данного протокола контейнер получает данные с других хранилищ даны или от клиентов через сателлиты, и отсылает данные другим хранилищам данных и клиентам с использованием сателлитов доступа к данным.
Рисунок 9 - Диаграмма взаимодействия хранилищ и сателлитов, разработана самостоятельно
Для максимального использования ресурсов системы, каждый физический сервер поделятся на максимально независимые блоки (контейнеры). Контейнеры - это система виртуализации на уровне операционной системы для запуска нескольких изолированных экземпляров ОС (operating system) Linux на одном компьютере. Они не используют виртуальные машины, а создают виртуальное окружение с собственным пространством процессов и сетевым стеком. Все экземпляры контейнеров используют один экземпляр ядра ОС, для максимальной эффективности их использования. Для обеспечения работы системы из нескольких контейнеров, в качестве одной системы использовано два типа (рис. 7, 8): контейнер «Балансер нагрузки»; контейнер приложения.
Балансер нагрузки выполняет роль прокси-сервера, который проверяет доступность контейнеров и переадресует полученные запросы в доступный контейнер для их обработки.
Рисунок 10 - Диаграмма размещения Контейнера хранилища
Контейнер приложения сателлита (рис. 11) содержит в себе:
1. UDT-сервер и UDT-клиент-для обмена данными с другими элементами глобальной системы хранилища данных.
2. Web-сервер для простого доступа к данным для пользователей.
3. Proftpd-сервер - предназначен для расширения функционала доступа к данным с помощью протоколов: FTP, FTPS, SFTP.
Рассмотрев функционал системы как отдельные бизнес-процессы системы, мы получим:
1. Поиск ближайшего сателлита доступа к данным.
2. Загрузка данных на хранилище.
3. Доступ к данным.
4. Репликация данных.
Поиск ближайшего сателлита доступа к данным изображен на рис. 12.
Рисунок 11 - Диаграмма размещения Контейнера сателлит
Рисунок 12 - Диаграмма последовательности поиска ближайшего сателлита
В случае, когда клиенту необходимо получить доступ к данным, программное приложение обращается к БК8-клиенту операционной системы с запросом получить 1Р-адрес системы используя доменное имя. В свою очередь DNS-клиент, используя сеть DNS-серверов, обращается к NS-серверам системы и он, используя 1Р-адресов клиента вычисляет оптимальный сателлит доступа к данным, который «ближайший» (минимальное количество шагов и максимальная скорость) к нему.
Рисунок 13 - Диаграмма последовательности загрузки данных
Загрузка данных на хранилище происходит согласно рис. 13. Получив IP адресов ближайшего сателлита, клиента авторизуется на сервисе и только после того, может получить доступ к данным. Когда клиенту необходимо загрузить документ, он с помощью программного приложения отправляет документ на сателлит с использование протокола TCP. Сателлит в свою очередь кэширует данные и отправляет данные на хранилище получения напрямую, или через ближайшее хранилище с использованием протокола UDT.
Рисунок 14 - Диаграмма последовательности доступа к данным
Доступ к данным демонстрирует рис. 14. В случае необходимости получения документа клиент с помощью программного приложения отправляет запрос на получение документа к сателлиту с использование протокола TCP. Сателлит в свою очередь получает документ из хранилища напрямую или через другое хранилище с использованием протокола UDT. Документ временно кэшируется на сателлите на присылается клиенту (TCP).
В концепции глобальной сети существуют два подхода к реализации обмена данными: последовательная передача данных - передача данных последовательно по одному каналу связи; параллельная передача данных - передача данных параллельно по нескольким каналам связи. Преимуществом параллельной передачи данных является скорость передачи данных. Данный метод используется в компьютерной периферии для обмена данными в шинах данных. Основным недостатком данного подхода является зависимость от качества и проводимости проводников, используемых в данной передаче. При различных свойствах проводников биты в передаче данных могут приходить с задержкой, что приводит к значительным ошибкам. В свою очередь последовательная передача данных является менее зависимой от проводников, поскольку передача данных идет исключительно по одному каналу связи, но, в свою очередь, является значительно более медленным, при нем параллельной передачи данных. Данный подход является наиболее распространенным в глобальных сетях.
Методы передачи данных также классифицируются на: синхронная передача данных; асинхронная передача данных. Асинхронный обмен является наиболее распространенной формой последовательного связи, что предполагает передача пакета данных в котором содержится информация о начале и конце передачи данных, информация для контроля ошибок и сами данные. Поскольку архитектура облачного хранилища данных предполагает, как одновременную передачу данных в разных направлениях, так и прием данных из разных источников данных, была выбрана асинхронная последовательная передача данных. Также для эффективного распределения ресурсов был выбран асинхронный подход к проектированию системы.
Модуль системы передачи данных можно представить, как систему состояний и переходов (рис. 15). При запуске процесса создается канал передачи данных, который переходит в статус «ожидания на события». Поскольку данный канал связи предусматривает, как передачу данных, так и прием данных, данный канал связи реагирует на следующие события:
1. Входное соединение - во время данного события системе необходимо аутентифициро-вать клиента и добавить данное соединение в пул соединений.
2. Входные данные - получить данные, расшифровать и выполнить действия, предусмотренные в данном пакете данных. В случае отсутствия данных у канала связи для чтения, и недополученные пакеты данных, данный пакет помещается в очередь недополученных пакетов данных, и система ожидает возможность получения данных по данному каналу связи.
3. Необходимость в передаче данных - проверка на существование соединения с удаленным клиентом, формирование пакетов данных, шифрования их и передачу их по каналу связи. В случае невозможности немедленно передать данные, пакеты данных перемещают в очередь пакетов и ожидают возможности передачи (освобождения выходного канала связи).
4. Ошибка соединения - в данном случае система оценивает данную ошибку, и принимает решение. Если система получила ложный пакет, или неожиданный для нее, система "просит" клиента повторно передать данные. Если произошел более крупный сбой системы, как сбой синхронизации шифрования данных, система разрывает соединение с данным клиентом, после чего клиент пересоздает соединение и повторно отправляет данные, на которые не получил подтверждения от сервера.
Поскольку клиентские данные хранят в облачном хранилище данных в виде файловой
структуры, передача данных в системе сводится к передаче файлов. Передачу отдельного файла можно представить, как передачу отдельных пакетов данных (рис. 16).
Рисунок 15 - Диаграмма состояний канала передачи данных
Во время передачи любого количества данных система формирует пакеты передачи данных и добавляет их в очередь передачи данных. После чего система выполняет ряд функции:
1. Проверка на существование соединения с пунктом назначения данных.
2. Если соединение отсутствует: создание соединения с пунктом назначения; аутентификация на пункте назначения;
3. Поочередное шифрования па передача пакетов данных (из очереди) по данному каналу связи.
4. В случае заполнения выходного кэша система переходит в ожидание других событий.
Рисунок 16 - Диаграмма состояний файла для передачи
После удачной отправки пакета данных система замечает в очереди передачи данных пакет, как отправленный. После удачного получения клиентом пакета данных, он отправляет пакет подтверждения. Серверная часть, получив данный пакет удаляет пакет из очереди передачи
данных. В случае разрыва соединения с получателем данных, система автоматически меняет статус отправленных пакетов данных, на новые, для повторной передачи данных (рис. 17). Логическую модель системы передачи данных в облачном хранилище данных можно представить в виде диаграммы классов (рис. 18). Из диаграммы классов очевидно, что концептуальная модель системы передачи данных в хранилище данных и сателлите аналогичны. Данный подход упрощает построение систем такого характера. Также из данной структуры очевидно, что «Соединение» является абстрактным классом и может использоваться протоколами, как ТСР или UDT, для транспортировки данных. Такой подход дает существенные преимущества в случаях существования единого ограниченного канала связи, что является весьма актуальным для современного состояния связи в 1С системах.
Рисунок 17 - Диаграмма состояний передачи пакета данных
Рисунок 18 - Диаграмма классов системы
При необходимости передачи данных (файла) система выполняет ряд простых действий:
1. Создание экземпляра класса «Файл».
2. Добавление его к «Очереди Исходных Файлов».
3. Получение ссылки на соединения (в случае, если отсутствует - создать).
4. Создание экземпляров класса «Пакет» в рамках свободного размера окна для соединения.
5. В случае готовности соединения для предо - получение «Пакета» из «Очереди Исходящих Пакетов», шифрование и передача по каналу связи.
6. Получение подтверждения окончания файла.
7. Удаление экземпляра класса «Файл».
С другой стороны, получатель данных (файла), выполняет следующие действия:
1. Получение пакета данных с данными о данных (файл) и его расшифровка
2. Создание экземпляра «Файл».
3. Добавление его к «Очереди Входной Файлов».
4. Создания физического файла.
5. Получение пакетов с данными, расшифровка и наполнение ими физический файл, отправки подтверждения получения пакетов данных.
6. Получение пакета завершения файла.
7. Закрытие файла.
8. Удаление экземпляра класса «Файл».
9. Отправка подтверждения получения полного файла.
Процесс получения пакета данных можно разбить на два этапа:
- получение заголовка пакета;
- получение основного тела пакета.
В заголовке сообщения содержится информация о:
1) Канал связи - для мультиплексной передачи данных нескольких файлов в один момент времени;
2) Размер тела пакета данных;
3) Команда - тип данных, которые передаются в теле пакета (создание каталога, файла, данные из файла, подтверждение получения пакета...); также может содержаться дополнительная информация в зависимости от команды.
Выводы
Учитывая затруднения и недостатки существующего состояния передачи данных большого объема через высокопроизводительные регионально-распределенные сети, которые были выявлены в процессе изучения проблемы, был разработан протокол сеансового уровня для таких сетей. Новый протокол сеансового уровня совместим со стандартными протоколами стека протоколов OSI TCP и UDP. Кроме того, он адаптирован для современных сетей, то есть имеет функционал для эффективного использования пропускной способности сети, не зависимо от ее характеристик. При использовании такого протокола не увеличиваются задержки при переходе передачи между различными типами сетей. Тем самым протокол обеспечивает
эффективное использование ресурсов крайних узлов сети. В вопросе защищенности он поддерживает шифрование данных, то есть он способен разрешать подключение протоколов шифрования. Была проведена оптимизация эффективности реализации протокола на базе UDP и было показано, что по этим идеям можно реализовать эффективные и практические приложения на базе протоколов UDP. Например, использование среды протокола UDT (основанный на UDP), может легко поддерживать различные алгоритмы управления перегрузкой, например, высокоскоростные TCP или взрывное RBUDP.
Использование данного подхода позволило увеличить производительность как элемента передачи данных, так и системы в целом. Использование многоканальной связи позволило одновременной передачи данных по одному каналу связи, а универсализация архитектуры позволило использование различных протоколов обмена данных на различных участках сети, в зависимости от эффективности.
Литература
1. A reference Cong, W., Zheng, Y., Zhang, Z., Kang, Q., Wang, X. (2017). Distributed Storage and Management Method for Topology Information of Smart Distribution Network. Dianli Xitong Zidonghua/Automation of Electric Power Systems, 41(13), 111-118. https://doi.org/10.7500/AEPS20161228008
2. Benbelgacem, S., Guezouli, L., Seghir, R. (2020). A Distributed Information Retrieval Approach for Copyright Protection. In: ACM International Conference Proceeding Series. Piscataway: Institute of Electrical and Electronics Engineers. https://doi.org/10.1145/3386723.3387882
3. Tong, B. B., Zou, G. B., Shi, M. L. (2013). A distributed protection and control scheme for distribution network with DG. Advanced Materials Research, 732733, 628-633. https://doi.org/10.4028/www.scientific.net/AMR.732-733.628
4. Jiao, J., Yang, Y., Feng, B., Wu, S., Li, Y., Zhang, Q. (2017). Distributed rateless codes with unequal error protection property for space information networks. Entropy, 19(1), article number 38. https://doi.org/10.3390/e19010038
5. Mishina S.V., Kornienko D.V. (2021). Setting up data exchange between information systems that automate accounting at the enterprise. Journal of Physics: Conference Series, 2094(3), article number 032018.
6. Zhu, X., Ning, Z., Fei, H., Li, Q., Li, D. (2013). Study on protection scheme for low-voltage distribution network with distributed generation. Information Technology Journal, 12(16), 3655-3659. https://doi.org/10.3923/itj.2013.3655.3659
7. Tian, J., Gao, H., Hou, M., Liang, J., Zhao, Y. (2010).
A fast-current protection scheme for distribution network with distributed generation. In: IET Conference Publications. Piscataway: Institute of Electrical and Electronics Engineers
https://doi.org/10.1049/cp.2010.0319
8. Zhong, S., Liu, C., Yang, Z., Yan, D. (2009). Privacy protection model for distributed service system in converged network. In: International Conference on EBusiness and Information System Security. Piscataway: Institute of Electrical and Electronics Engineers. https://doi.org/10.1109/EBISS.2009.5138026
9. Chen, X., Li, Y., Zhao, M., Wen, A., Liu, N. (2014). A coordinated strategy of protection and control based on wide-area information for distribution network with the
DG. In: International Conference on Power System Technology: Towards Green, Efficient and Smart Power System, Proceedings (pp. 2517-2521). Piscataway: Institute of Electrical and Electronics Engineers. https://doi.org/10.1109/POWERCON.2014.6993803
10. Song, X., Zhang, Y., Zhang, S., Song, S., Ma, J., Zhang, W. (2018). Active distribution network protection mode based on coordination of distributed and centralized protection. In: Proceedings of 2017 China International Electrical and Energy Conference (pp. 180-183). Piscataway: Institute of Electrical and Electronics Engineers https://doi.org/10.1109/CIEEC.2017.8388442
11. Kornienko, D.V., Mishina, S.V., Shcherbatykh, S.V. and Melnikov M.O. (2021). Principles of securing RESTful API web services developed with python frameworks. Journal of Physics: Conference Series, 2094(3), article number 032016.
12. Abbaspour, E., Fani, B., Heydarian-Forushani, E. (2019). A bi-level multi agent-based protection scheme for distribution networks with distributed generation. International Journal of Electrical Power and Energy Systems, 112, 209-220. https://doi.org/10.1016/j.ijepes.2019.05.001
13. Kornienko, D.V., Mishina, S.V., Melnikov, M.O. (2021). The Single Page Application architecture when developing secure Web services // Journal of Physics: Conference Series, 2091(1), article number 012065.
14. Zhou, C., Zou, G., Yang, J., Lu, X. (2019). Principle of Pilot Protection based on Positive Sequence Fault Component in Distribution Networks with Inverter-interfaced Distributed Generators. In: IEEE PES GTD Grand International Conference and Exposition Asia (pp. 998-1003). Piscataway: Institute of Electrical and Electronics Engineers. https://doi.org/10.1109/GTDAsia.2019.8716011
15. Maximov, R.V., Ivanov, I.I., Sharifullin, S.R. (2017). Network topology masking in distributed information systems. CEUR Workshop Proceedings, 2081, 83-87.
16. Kornienko, D.V. (2020). Organization of a system of digital education practices in the municipal sphere of general education. Journal of Physics: Conference Series, 1691(1), article number 012108.
17. Kornienko, D.V., Shcherbatykh, S.V., Mishina, S.V., Popov, S.E. (2020). The effectiveness of the pedagogical conditions for organizing the educational process using
distance educational technologies at the university.
Journal of Physics: Conference Series, 1691(1), article number 012090.
18. Ruan, W., Zhan, H. (2014). A new protection algorithm for distribution network with distributed generation based on intelligent electronic device information. Lecture Notes in Electrical Engineering, 237 LNEE, 275-282. https://doi.org/10.1007/978-3-319-01273-5_30
19. Al Sukhni, E. M., Mouftah, H. T. (2008). Availability-guaranteed distributed provisioning framework for differentiated protection services in
optical mesh networks. In: IEEE Globecom Workshops. Piscataway: Institute of Electrical and Electronics Engineers.
https://doi.org/10.1109/GLOCOMW.2008.ECP.46 20. Alexandrovich, G. P. (2006). The applying sets graph protection model to the detection information threats in distributed networks and data base management systems.
In: 8th International Conference on Actual Problems of Electronic Instrument Engineering Proceedings (pp. 126-128). Piscataway: Institute of Electrical and Electronics Engineers.
https://doi.org/10.1109/APEIE.2006.4292398
УДК 658.64
ЦИФРОВИЗАЦИЯ РАЗРАБОТКИ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ
СЕРВИСНОЙ КОМПАНИИ
М.В.Сикорская1, О.П.Дмитриченко2, Г.В.Алексеев3
1 Государственный институт экономики, финансов, права и технологий, Россия, 188300, Ленинградская обл. г. Гатчина, Рощинская ул., 5; 2Санкт-Петербургский государственный экономический университет, Россия, 191023, Санкт-Петербург, наб. канала Грибоедова, д. 30-32, литер А;
3 Университет при Межпарламентской ассамблее ЕврАзЭС, Россия, 194044, г.Санкт-Петербург, Смолячковаул., д. 14, корп.1 лит. Б.
Настоящая статья посвящена вопросам повышения качества обслуживания населения на основе сбалансированных управленческих решений, основанных на анализе текущей экономической ситуации. Такие решения, в частности, особенно необходимы в инфраструктуре крупных городов, которые предполагают развитие самого широкого спектра предприятий питания. Большую популярность в таких городах, имеющих развитую сеть офисных компаний с большим количеством работающих в них сотрудников в последнее время приобретает кейтеринг.
Ключевые слова: качества обслуживания, сбалансированные управленческие решения, анализ экономической ситуации.
DIGITALIZATION OF THE DEVELOPMENT OF MANAGEMENT SOLUTIONS OF A
SERVICE COMPANY
M.V. Sikorskaya, O.P. Dmitrichenko, G.V. Alekseev
State Institute of Economics, Finance, Law and Technology, Russia, 188300, Leningrad region , Gatchina, Roshchinskaya str., 5;
St. Petersburg State University of Economics, Russia, 191023, St. Petersburg, nab. Griboyedov Canal, 30-32, letter A; University under the Inter-Parliamentary Assembly of the EurAsEC, Russia, 194044, St. Petersburg, Smolyachkova st., 14, building 1 lit. B This article is devoted to the issues of improving the quality of public services based on balanced management decisions based on an analysis of the current economic situation. Such solutions, in particular, are especially needed in the infrastructure of large cities, which involve the development of the widest range of catering enterprises. Catering has recently gained great popularity in such cities with a developed network of office companies with a large number of employees working in them.
Keywords: quality of service, balanced management decisions, analysis of the economic situation.
1Сикорская Виктория Мирославовна - студентка 3 курса, тел:. +79004633793,
e-mail: viktoriasikorskaa13175@gmail.com;
2Дмитриченко Ольга Павловна - кандидат экономических наук, преподаватель, , тел.:+79215802633, e-mail: dmi-l943@yandex.ru;
3Алексеев Геннадий Валентинович - доктор технических наук, профессор, заведующий лабораторией «Инновационные технологии», тел..+79213350796, e-mail: gva2003@mail.ru.
