СИСТЕМА И СПОСОБ ВЗАИМОДЕЙСТВИЯ ПОЛЬЗОВАТЕЛЕЙ С ОБЛАЧНЫМИ ОБЪЕКТНЫМИ ХРАНИЛИЩАМИ ДАННЫХ

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

H04L 29/02 - управление передачей данных; обработка данных, поступающих с линий связи;

H04L 29/06 - отличающиеся процедурой регистрации и коммутации сообщений;

H04L 12/00 - сети переключения сигналов (передачи данных);

H04L 12/54 - коммутационные системы с промежуточным хранением;

H04L 12/66 - межсетевые соединительные устройства, использующие различные типы систем коммутации, например, межсетевой интерфейс.

Исследован и выявлен уровень техники по базам данных РФ и зарубежным базам данных на дату подачи заявочных материалов, проанализированы наиболее близкие аналоги:

- Патент №US 20150012495;

- Патент №US 20130212214;

- Патент №US 2014019755;

Патент №US 20150012495: «Операции по хранению данных, включая индексирование контента, контейнерную дедупликацию, политико-ориентированное хранение, выполняются в пределах облачной среды». Системы поддерживают большое количество клиентов и множество облачных хранилищ, которые в облачной среде могут подсоединяться к системе, требуют передачи данных по глобальным сетям, таким как Интернет, с заметным временем ожидания и/или возможной потерей пакета, используя различные сетевые протоколы, включая HTTP и FTP. Раскрываются методы индексирования контента хранимой в облачной среде информации направленные на облегчение дальнейшего (в том числе и совместного) поиска. Также раскрываются методы выполнения контейнерной дедупликации, направленные на уменьшение нагрузки на систему пространства имен, снижение затрат, и т.д. Раскрываются методы идентификации подходящих мест хранения, включая подходящие облачные хранилища данных, для файлов с данными с учетом политики хранения. Наряду с другими особенностями раскрыты системы и методы учета облачных шлюзов и масштабируемых хранилищ объектов данных в пределах облачной среды.»

Наименование патента: «Сервер и хранение объектов данных в среде облачного хранения, включая устранение избыточности данных и управление данными через несколько узлов облачных хранилищ данных» от патентообладателя Commvault Systems, Inc.

Признаки, которые совпадают с объектом. Наличие шлюза, к которому с одной стороны подключены компьютеры пользователей, а с другой - облачные хранилища. При поступлении данных для сохранения в облачном хранилище, шлюз выполняет следующие действия: сравнивает блоки данных с содержимым кэша; выполняет дедупликацию данных на уровне блоков; осуществляет выбор облачных хранилищ на основании политик хранения; сохраняет блоки данных в выбранном облачном хранилище. Для обмена данными используется протокол Amazon S3, работающий поверх HTTP

Отличительные признаки объекта разработки от аналога. Помимо кеширования данных, их дедупликации и выбора облачного хранилища, на шлюзе также осуществляется шифрование данных и их расщепление. Таким образом, блоки зашифрованных данных сохраняются в облачных хранилищах не целиком, а фрагментами, что повышает конфиденциальность сохраняемых данных и скорость доступа к ним. Кроме того, шлюз имеет модульную внутреннюю структуру, что существенно расширяет возможности конфигурирования системы.

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

Наименование патента: «Облачный шлюз для данных промышленной автоматизации и систем управления» от патентообладателя Rockwell Automation Technologies, Inc.

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

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

Патента №US 2014019755: «Облачные хранилища данных большой емкости могут быть созданы из отдельных облачных хранилищ данных. Файлы могут быть разбиты на части и храниться в отдельных облачных хранилищах данных, а затем извлекаться из них для объединения с исходным. При разделении файлов данные для дополнительной безопасности могут быть зашифрованы. Кроме того, избыточность можно получить при дублировании данных на многократных облачных хранилищах, например, как в конфигурации избыточного массива независимых дисков 5 уровня. Сервер может располагаться между клиентским устройством и облачными хранилищами данных для разделения данных файла, шифрования и выполнения функций административного управления. Таким образом, клиентский доступ к избыточному облачному хранилищу данных может использоваться, как и любой другой сетевой накопитель».

Наименование патента: «Облачные хранилища данных», патентообладателем является компания UNISYS CORPORATION.

Признаки, совпадающие с объектом разработки. Получение файла для удаленного хранения; разбиение файла на две части; шифрование первой и второй частей; загрузка первой зашифрованной части на первое облачное хранилище; загрузка второй зашифрованной части на второе облачное хранилище.

Отличительные признаками объекта разработки от аналога. Применяется избыточное кодирование: блок данных расщепляется на N частей в то время, как для восстановления блока достаточно К частей при K<N. Это позволяет восстановить данные в случае потерь фрагментов. Кроме того, это позволяет увеличить скорость получения данных за счет параллельного считывания К фрагментов из К облачных хранилищ, подключенных на максимальной скорости.

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

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

Представлены рисунки, поясняющие изобретение:

Фиг. 1 - структура объекта и его размещение в объектном хранилище

Фиг. 2 - облачная архитектура хранения данных

Фиг. 3 - методы доступа к облачным системам хранения данных

Фиг. 4 - облачные модели хранения данных

Фиг. 5 - структура облачной системы

Фиг. 6 - структура шлюза

Фиг. 7 - вариант исполнения системы

Задача, для решения которой предлагается изобретение, заключается в эффективном безопасном хранении неструктурированных данных в виде объектов, расщепленных на несколько частей по (n,k)-схеме и размещаемых на серверах сторонних провайдеров облачных сервисов хранения данных. Техническое решение заключается во взаимодействии шлюзового сервера или сервиса, установленного в доверенной среде пользователя, с облачным хранилищем, по средством локальной сети или сети интернет, и с использованием метода расщепления данных по (n,k)-схеме.

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

Отличительной особенностью объектных хранилищ является, во-первых, возможность хранения практически неограниченного количества объектов в рамках одного пространства имен, что позволяет использовать их для построения высоконагруженных сервисов (см. Фиг. 1).

Поскольку метаданные объекта могут, среди прочего, содержать и указатели на другие связанные с ним объекты или традиционные файлы, объект можно рассматривать как агрегатор, объединяющий распределенные данные. В этом смысле он имеет сходство с URL. Каждый объект однозначно определяется с помощью Object ID (OID) - числовым идентификатором, служащим уникальным указателем на объект. Наличие OID позволяет программному обеспечению объектного хранилища сохранять объекты в обширной (зависит от разрядности OID) области простой адресации, исключая необходимость иерархической структуры каталогов. Фактически объекты могут перемещаться программным обеспечением объектного хранилища, не прерывая работы приложений и пользовательского доступа.

Облачная архитектура хранения данных (см. Фиг. 2) - это прежде всего предоставление ресурсов хранения данных по требованию в высокомасштабируемой и мультитенантной среде. Обобщенно облачная архитектура хранения данных предоставляет внешний интерфейс, который представляет собой API для доступа к накопителям. В традиционных системах хранения данных это протокол SCSI, но в облаке появляются новые протоколы. Среди них можно найти внешние протоколы Web-сервисов, файловые протоколы и даже более традиционные внешние интерфейсы (Internet SCSI, iSCSI и др.). За внешним интерфейсом располагается уровень промежуточного ПО, который называют логикой хранения данных. Этот уровень реализует ряд функций, таких как репликация данных и сокращение объема данных, по традиционным алгоритмам размещения данных (с учетом географического расположения). Наконец, внутренний интерфейс организует физическое хранение данных. Это может быть внутренний протокол, который реализует специфические функции, или традиционный сервер с физическими дисками.

Одним из самых ярких различий между облачной и традиционной системами хранения являются средства доступа к ним. Большинство поставщиков предлагает разные методы доступа, однако общепринятыми являются API Web-сервисов. Многие из них реализованы на принципах REST, что подразумевает объектно-ориентированную схему, разработанную поверх HTTP (с использованием HTTP в качестве транспорта). REST-API без запоминания состояния просты и эффективны. REST-API реализуют многие поставщики облачных услуг хранения, включая Amazon Simple Storage Service (Amazon S3), Windows Azure™ и Mezeo Cloud Storage Platform.

Вышеупомянутые протоколы являются наиболее распространенными, однако для облачного хранения подходят и другие. Один из самых интересных - Web-based Distributed Authoring and Versioning (WebDAV). WebDAV также основан на HTTP и позволяет использовать Web в качестве ресурса для чтения и записи. В число поставщиков, использующих WebDAV, входят Zetta, Cleversafe и другие (см. Фиг. 3).

Можно найти и такие решения, которые поддерживают несколько протоколов доступа. Например, IBM® Smart Business Storage Cloud позволяет использовать протоколы на основе файлов (NFS и CIFS) и протоколы на основе SAN в одной и той же инфраструктуре виртуализации систем хранения данных.

Облачное хранение развивается в трех направлениях (см. Фиг. 4), два из которых можно назвать независимыми, а третье представляет собой слияние первых двух в целях достижения экономической эффективности и безопасности:

- Общедоступные облачные системы хранения данных, которые предоставляют инфраструктуру на условиях аренды (ресурсы для долгосрочного или краткосрочного хранения данных и полосу пропускания сети).

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

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

В число поставщиков общедоступных облаков хранения данных входят Amazon и Nirvanix (которые предлагают хранение данных как услуги). Примерами поставщиков частных систем хранения служат IBM, Parascale и Cleversafe (которая предлагает программное обеспечение и/или оборудование для внутреннего облака). Наконец, поставщики гибридных облаков - это Nirvanix, Egnyte и др.

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

1. Пользователь приобретает место хранения в центре хранения и обработки данных и разворачивает на этом месте собственную инфраструктуру, реализующую облачное хранение;

2. Пользователь приобретает услугу хранения данных в облачной системе хранения у уже существующего сервиса.

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

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

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

Описанные эффекты достигаются за счет реализации структуры, состоящей из множества различных облачных сервисов хранения данных (Cloud Service 1, …, Cloud Service Ν), шлюза (Gateway), находящегося в доверенной среде, и терминала пользователя - User Terminal (см. Фиг. 5).

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

Особенностью описываемого технического решения является внутренняя структура шлюза. Он включает в себя три блока, последовательно соединенных между собой (см. Фиг. 6).

При этом первый блок Block 1 предназначен для осуществления взаимодействия шлюза с пользовательским терминалом. Таким образом, связь пользовательского терминала со шлюзом реализуется за счет связи первого блока с терминалом пользователя. Второй блок Block 2 предназначен для обработки запросов и данных, поступающих от пользовательского терминала в первый блок, а также обработки данных, полученных из облачных хранилищ, и формирования ответов на эти запросы. Таким образом, второй блок, с одной стороны, связан с первым блоком, а с другой стороны - с третьим блоком Block 3, предназначенным для реализации взаимодействия с облачными службами хранения данных. Соответственно, третий блок имеет взаимосвязи с входящими в систему облачными сервисами, чем достигается связь шлюза с облачными системами хранения данных.

Для обеспечения возможности гибкой настройки описываемой системы под нужды конкретной реализации, каждый из описанных блоков имеет внутреннюю модульную структуру. Каждый модуль (Module 1, …, Module Ni) осуществляет определенное действие (связанное с преобразованием или анализом полученной информации) над запросом или ответом на запрос, поступающим на вход модуля, и, выполнив данное действие, передает блок информации (возможно, измененный, если действия модуля связаны с преобразованием информации) на выход модуля, откуда он попадает на вход другого модуля. Таким образом, модули могут быть соединены между собой последовательно внутри формируемого ими блока. Такое соединение модулей позволяет осуществлять последовательные преобразования запросов и ответов на запросы согласно требованиям, к конкретной реализации описываемой системы. При этом, в случае возникновения необходимости внесения изменений в конкретную реализацию системы, это может быть выполнено за счет добавления, замены и/или удаления определенных модулей без необходимости замены всей системы. Следует также отметить, что описываемая система допускает параллельное соединение модулей, например, в целях реализации многопоточной обработки и передачи информации.

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

- Между блоком интерфейса взаимодействия с облачными хранилищами Block 3 шлюза и службами облачного хранения данных Cloud Service 1, …, Cloud Service N устанавливаются соединения, предпочтительно под управлением протокола Amazon Simple Storage Service Protocol (Amazon S3 Protocol).

- Далее устанавливается соединение между терминалом пользователя и блоком интерфейса взаимодействия с пользовательским терминалом Block 1 шлюза, например, также по протоколу S3.

- При поступлении запроса на сохранение данных и самих данных от терминала к шлюзу, Block 1 получает данный запрос, форматирует его и передает в блок обработки запросов и данных Block 2 шлюза в виде сообщения.

- Block 2 выполняет преобразование (например, шифрование и кодирование) поступивших данных и передает их в виде сообщения в блок интерфейса взаимодействия с облачными хранилищами Block 3.

- Block 3 осуществляет распределение и сохранение преобразованных данных на облачных хранилищах, с которыми у шлюза установлено соединение.

- При поступлении от терминала в Block 1 шлюза запроса на считывание сохраненных данных, запрос форматируется и последовательно передается в соответствующий модуль третьего блока шлюза, который осуществляет сбор запрошенных данных из облачных хранилищ.

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

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

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

Еще одной особенностью описываемого технического решения является применение метода расщепления данных по (n,k)-схеме для дальнейшего сохранения на множестве облачных хранилищ данных. Для реализации данного метода в блок обработки запросов и данных внесен модуль избыточного кодирования/декодирования данных по (n,k)-схеме. При поступлении запроса на сохранение данных от терминала κ шлюзу, последний, помимо шифрования поступивших данных, осуществляет их фрагментацию согласно заранее определенным параметрам (n,k)-схемы. Далее осуществляется распределение фрагментов по объектным хранилищам, с которыми у шлюза установлено соединение, и их сохранение. При поступлении от терминала к шлюзу запроса на считывание сохраненных данных, шлюз осуществляет сбор зашифрованных фрагментов запрошенных данных из облачных хранилищ, их восстановление, расшифровку и передачу пользовательскому терминалу.

Рассмотрим один из частных вариантов исполнения описанной системы (см. Фиг. 7).

Пользовательский терминал User Terminal представляет собой подключенный к сети Интернет персональный компьютер, с установленным на нем программным обеспечением, включающим операционную систему и Web-браузер. Шлюз Gateway выполнен в виде подключенного к сети Интернет аппаратного сервера, с установленной на нем операционной системой Unix (Linux) и дополнительным программным обеспечением, составляющим блоки и модули шлюза. В качестве облачных сервисов хранения данных выбраны Microsoft Azure (Cloud Service 1), Amazon Simple Storage Service (Cloud Service 2) и Ceph (Cloud Service 3).

Блок интерфейса взаимодействия с пользовательским терминалом Block 1 сформирован двумя модулями: Module 1 и Module 2. Module 1 представляет собой общедоступный программный Web-сервер, связанный с терминалом пользователя через сеть Интернет по протоколу HTTP, а связанный с ним Module 2 является интерфейсным модулем взаимодействия с Web-сервером, предназначенным для непосредственного получения запросов клиента и отправки ответов на них через Web-сервер на программном уровне. Блок обработки запросов и данных Block 2 включает 5 модулей: модуль шифрования/дешифрования данных Module 1, связанный с Module 2 из Block 1; модуль сжатия/восстановления данных Module 2, связанный с Module 1; модуль кеширования данных Module 3, связанный с Module 2; модуль дедупликации данных Module 4, связанный с Module 3, и модуль избыточного кодирования/декодирования данных по (n,k)-схеме Module 5, связанный с Module 4. Блок интерфейса взаимодействия с облачными системами хранения данных Block 3 составляют два модуля: модуль многопоточной передачи данных Module 1, связанный с Module 5 из Block 2, и интерфейсный модуль взаимодействия с облачными хранилищами Module 2, связанный с Module 1. Между Module 2 из Block 3 и облачными сервисами хранения данных установлены соединения через сеть Интернет, подчиняющиеся протоколу Amazon S3 Protocol.

Описанная конкретная реализация системы функционирует следующим образом. Пользователь, посредством Web-браузера пользовательского терминала, направляет в шлюз запрос на сохранение некоторого объекта данных и сами данные. Запрос и данные форматируются и передаются в виде сообщения в модуль шифрования/дешифрования данных блока обработки запросов и данных, в котором выполняется шифрование полученных данных. Далее зашифрованные данные передаются в модуль сжатия/восстановления данных, в котором осуществляется сжатие зашифрованных данных. Сжатые данные передаются в модуль кеширования, в котором производится анализ статистики запросов и, на основании проведенного анализа, принимается решение о сохранении или не сохранении данных на локальном устройстве хранения данных, входящем в аппаратную конфигурацию шлюза. Из модуля кеширования данные передаются в модуль дедупликации, в котором производится анализ данных, уже сохраненных в облачных системах хранения, и, на основании проведенного анализа, принимается решение о сохранении поступивших зашифрованных данных в облачном хранилище, либо об их ассоциации с уже сохраненным в облачном хранилище объектом данных (в этом случае дальнейшая передача данных прекращается, а на пользовательский терминал посредством Module 2 и Module 1 из Block 1 передается подтверждение о выполнении запроса). Далее, зашифрованные данные передаются в модуль избыточного кодирования/декодирования данных по (n,k)-схеме, в котором выполняются их кодирование и фрагментация согласно известному алгоритму. Затем расщепленные данные передаются в модуль многопоточной передачи данных блока интерфейса взаимодействия с облачными хранилищами, в котором выполняется разделение поступивших данных на параллельные потоки, которые поступают в интерфейсный модуль взаимодействия с облачными хранилищами, который, в свою очередь, направляет потоки данных в подключенные к нему облачные системы хранения данных. По завершению сохранения переданных данных на облачных сервисах, Module 2 из Block 3 формирует сообщение, содержащее подтверждение о выполнении запроса, которое передается по вышеописанной цепи связей последовательно в обратном порядке в Block 1, откуда подтверждение о выполнении запроса поступает на терминал пользователя.

При направлении пользователем через Web-браузер пользовательского терминала запроса на считывание данных, запрос поступает через Module 1 из Block 1 в Module 2, где форматируется и передается в Module 1 из Block 2 в виде сообщения. Данное сообщение передается последовательно без изменений через Module 1 и Module 2 в Module 3, в котором осуществляется поиск запрошенной информации на локальном устройстве хранения данных шлюза. В случае, если запрошенные данные найдены, Module 3 формирует сообщение, содержащее запрошенные данные и подтверждение о выполнении запроса, затем сообщение передается по цепи последовательно в обратном порядке в Block 1, откуда запрошенные пользователем данные и подтверждение о выполнении запроса передаются в терминал пользователя. В случае, если запрошенные данные не найдены, сообщение с запросом передается через Module 4 и Module 5 из Block 2 и Module 1 из Block 3 в Module 2, который формирует соответствующие запросы на считывание фрагментов данных из подключенных систем облачного хранения данных. В случае, если запрошенные фрагменты данных отсутствуют, Module 2 формирует сообщение об ошибке, которое передается последовательно по цепи в обратном порядке на пользовательский терминал. Если запрошенные фрагменты данных найдены, они поступают параллельно из облачных хранилищ в Module 2 из Block 3, откуда потоки данных передаются в Module 1, который формирует из них одно сообщение и передает его в Module 5 из Block 2. В Module 5 выполняется декодирование расщепленных данных, после чего они передаются без изменений в виде сообщения в Module 3. Module 3 выполняет анализ статистики запросов пользователя и, на основании результатов анализа, принимает решение о сохранении или не сохранении полученных данных на локальном устройстве хранения данных шлюза. Далее сообщение с данными передается без изменений в Module 2, где осуществляется восстановление данных из сжатого состояния. Восстановленные данные поступают в Module 1, в котором осуществляется их дешифрование. Сообщение с дешифрованными данными и подтверждением о выполнении запроса пользователя передается в Module 2 из Block 1, в котором осуществляется форматирование данных и откуда через Module 1 данные и подтверждение о выполнении запроса передаются в пользовательский терминал.