Файл: Облачные сервисы (МОДЕЛИРОВАНИЕ ОБЛАЧНОЙ СРЕДЫ ДАННЫХ И АНАЛИЗ МЕТОДОВ ИХ ПЕРЕДАЧИ).pdf

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

Так для целей облачных хранилищ данных необходимо:

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

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

В реляционных базах данных основным примитивом являются таблицы. Таблица заполняется записями, каждая из которых имеет один и тот же тип записи, задается несколькими именуемыми строго типизированными столбцами. В середине записей отсутствует какой-либо внутренний порядок столбцов. При выполнении запросов, которые обычно представляются на языке SQL, выбираются записи из одной или нескольких таблиц, и они превращаются с использованием небольшого набора мощных реляционных операций.При использовании метода обработки запросов над потоковыми данными соответствующими примитивами уже выступают потоки. Как и в таблице, в потоке есть некоторый тип записи, но записи не сохраняются, а поступают в потоке. В поточной системе записи упорядочены естественным образом, и в каждой записи есть временная метка, указывающая, когда эта запись была создана. Для реляционных операций, поддерживаемых в реляционных базах данных, аналоги и в потоковых системах, и эти аналоги достаточно похожи на реляционные операции, чтобы для формулировки потоковых запросов можно было использовать SQL. Аналогичный подход, но уже не с использованием языка структурированных запросов, а «языка передачи и обработки файлов в хмаркових хранилищах» позволяет использовать все преимущества потокового подхода, который, как показала практика использования, намного эффективнее.

То есть, процесс передачи файла F от одного абонента другому заключается в

разделении его на K блоков

F  F1 ,, FK  и последовательной передачи этих блоков через

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

---

Рис. 2.1. Последовательная передача файла.

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

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

Все системы для работы в сети используют аналогичный принцип передачи. И изменить этот принцип – означает изменение всего программного обеспечения, выглядит абсурдным.

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

• • • разрешали получать последовательный поток блоков файлов для

приема от передающего абонента;

• • • генерировали соответствующий последовательный поток блоков файлов для приемного абонента.

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

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

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

То есть, между двумя точками сети передача данных осуществляется через N TCP-соединений.

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

1. Создание цикла IOLOOP.
2. Создание необходимых соединений (sockets).
3. Назначить события каждого socket с указанием, какие именно события интересуют (чтение / запись / ошибка сокета).
4. Обращение к IOLOOP (с указанием таймаута), чтобы получить доступный сокет, который соответствует предназначенным условиям.
5. Если в течение определенного времени (таймаута) ни один socket не соответствует условиям, управление возвращается к программе. Если какой-то готов, то IOLOOP вместе с управления возвращает список готовых соединений и с указанием условия (чтение и / или запись и / или ошибка сокета).

---

Такой принцип достаточно легко реализовать по структуре (рис. 2.2).

Рис. 2.2. Метод получения доступа к асинхронной передачи.

Используя этот подход, позволяет реализовать метод мультипротокольного доступа к потоковым данным.

1. Обращение к циклу IOLOOP, которое возвращает готовность к чтению с управляющего сокета (сокет управления программой).
2. Считывание сокета управления и получение команды отправки файла.
3. Считывание из файла M байт.
4. Упаковка данных в пакет.
5. Добавление пакета в очередь.
6. Если очередь не заполнена – вернуться к пункту 2.
7. Проверка на существование N соединений. Если они закрыты, не созданы – то создать и выполнить необходимые действия для соединения. После соединения сокеты добавляются в цикл IOLOOP с указанием ожидания: «готовности записи», «готовности чтения», «ошибки сокета».
8. Обращение к IOLOOP по списку «готовых» сокетов.
9. Если ошибка сокета: закрывают сокет, удаляют его из IOLOOP, замечают пакеты, переданные этим сокетом и не подтверждены, как отправленные, создают новый сокет, образуют новый сокет и добавляют его в IOLOOP.
10. Если готовность сокета к записи, для каждого из сокетов: получить пакет из очереди, шифрование его и запись в буфер обмена сокета, а сам пакет замечает, как отправлен через данный сокет.
11. Если готовность сокета к чтению, тогда для каждого сокета: прочитать пакет, расшифровать, получить подтверждение пакета; удалить данный пакет из очереди.
12. Если файл еще не весь прочитан, и есть место в очереди, тогда перейти

к 3.

1. Если файл прочитан и очередь пуска, закрыть соединения и удалить их з IOLOOP та перейти до 1.
2. Перейти к 8.

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

Обобщенная схема работы этого метода может быть представлена графически (рис. 2.3).

К основному преимуществу предложенного метода следует отнести то, что транспортировка данных используется более быстрый протокол UDP, а для обеспечения доставки – TCP.

Рис. 2.3. Диаграмма последовательности мультипротокольного доступа к потоковым данным.

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

---

Учитывая все вышеизложенное, можно сказать, что преимуществами такого модифицированного метода является:

• • • Возможность потоковой передачи данных через N-узлов (серверов) облачных хранилищ, не дожидаясь завершения передачи одиночного файла.
    • Однако предложенный подход имеет определенные недостатки:
    • Динамичное увеличение кэша, при ожидании правильной последовательности блоков файла для дальнейшей потоковой записи;
    • Синхронное подтверждения завершения записи файла.

Разработка метода мультиплексирования различных источников данных для одновременной передачи.

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

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

Мультиплексирование документов необходимо для одновременного получения нескольких документов из одного источника. При использовании последовательного получения документов, пользователь может столкнуться с проблемой, когда получение достаточно малых рабочих документов, может отложиться на большой промежуток времени из-за попадания в очередь больших документов [1].

Существуют несколько видов обеспечения мультиплексирования:

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

точками передачи данных создается столько соединений, сколько нужно одновременно передавать документы.

---

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

Существует два подхода к обеспечению данного режима работы:

1. Получение одного файла с одного узла – клиентское программное обеспечение делает запросы к узлу для получения целого документа (рис. 2.4). Таким образом документы приходят целостно. Данный метод эффективен когда на хранилище расположено много файлов небольшого размера.
2. Получение одного документа с разных узлов – в данном случае клиентское программное обеспечение же решает какую часть документа с какого узла получить (рис. 2.5). Таким образом с «близких» (с которыми лучший / быстрая связь) узлов можно получить большие части документа. Данный метод эффективен в случае, когда необходимо получить один достаточно большой файл, а пропускная способность входящего канала передачи данных значительно превышает передачу данных с одним узлом.

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

d1 fi  { d1 , c1 , fi , d1 , c2 , fi ,, d1 , cn , fi }  . { c1 , p1 , c2 , p2 ,, cn , pm }  { p1 , p2 ,, pm }  d2 fi

(2.1)

Рис. 2.4. Мультиплексирование с одним узлом.

Для решения данной проблемы без мультиплексирования данных существуют следующие варианты реализации:

• • • Создание многих каналов связи, создает накладные ресурсы и

потери быстродействия системы.

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

{ d1 , fi , d2 , fi ,, dl , fi }  { d1 , c1 , fi , d1 , c2 , fi ,, dl , cn , fi }  . { d1 , c1 , p1 , d1 , c2 , p2 ,, dl , cn , pm } { p1 , p2 ,, pm }  dk , fi

(2.2)

---