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

Рис. 1.5. Модель несимметричной передачи данных через дата-центр.

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

Поэтому можно рассмотреть такой подход, как модель одноточечной дистрибуции.

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

Использование такой модели доставки данных сокращает количество хостов, что значительно увеличивает скорость загрузки контента из Интернета. Хоп (hop, прыжок) – название процесса передачи сетевого пакета (или datagrams) между хостами (узлами) сети. Обычно он используется для определения «расстояния» между узлами (чем больше узлов – тем сложнее путь маршрутизации и «следующий» — это узлы друг от друга) [6].

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

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

Рис. 1.6. Модель многоточечной дистрибуции данных через дата-центр.

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

Размещение серверов в непосредственной близости от конечных пользователей может увеличить выходную мощность всей системы. Например, наличие единого порта 100 Мбит/с не означает такой скорости на всех участках сети, так как свободная пропускная способность магистрального канала на момент передачи может сойти всего 10 Мбит/с. В случае использования 10 распределенных серверов общая пропускная способность может составят 10-100 Мбит/с.

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

---

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

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

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

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

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

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

Структурно сателлит состоит из трех частей (Рис. 1.7):

1. Firewall – защитный барьер.
2. Nginx – веб сервер для обработки запросов и перенаправления их на программную аппликацию сателлита.
3. Application – Программная реализация сателлита – программа которая обеспечивает определение на каком из серверов физически находятся файлы пользователя и предоставляет доступ к ним.

---

Рис. 1.7. Модель сателлита.

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

В основе модели хранилища данных целесообразно использовать модель хранилища данных, предложенную Робинсоном:

S  F, D,G,C, L ,

(1.1)

де F  f , f ,..., f  - множество элементов данных,

1 2 n

f  p , p

1

2

,..., pm

 – множество пакетов данных,

D  d , d ,...,d  – множество устройств хранения,

1 2 k

G : F  D C : D  Z L : D  Z

• размещение устройств хранения,
• емкость устройств хранения,
• загруженность устройств хранения.

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

Sm  F, D(t),G,C, L .

(1.2)

Тогда модель облачного хранилища данных подана как:

Scloud  D, Dfree , Sms ,

(1.3)

де Dfree  D

• подмножество свободных устройств хранения,

S  S , S ,..., S  – множество масштабируемых хранилищ.

ms m1 m 2 ml

Масштабируемые устройства в данном случае - это устройства из множества общих устройств, которые не включают в себя подмножество свободных устройств Di (t)  D \ Dfree . Масштабируемые устройства не имеют общих устройств

хранения: t,i, j,i 

j  Di (t)  Dj (t)   .

Усовершенствована модель облачного хранилища как алгебраическую систему:

Cdw  Scloud _ m ;Y ; L ,

Scloud _ m  D, Dfree , Sms , PR ,

Y  I I , I , cc, mpp mpd

де Icc

• метод выбора шлюза по сложности запроса,

---

Impp

• метод мультипротокольной передачи потоковых данных,

Impd

передачи,

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

PR – протокол передачи данных,

L – предикат загруженности

Scloud .

Элемент даних

f i  St  SemSt  UnSt

может быть представленный

структурированными, слабоструктурированными и неструктурированными данными [15].

Предикат загруженности облачного хранилища представлен как отношение

загруженности облачного хранилища данных в моменты вр.

t1 та

t2 . Для ее

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

LS , S  Z . cloud _ mt 1 cloud _ mt 2

(1.4)

Параметры облачного хранилища данных

Scloud _ m : входной/выходной

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

Организация доступа к облачному хранилищу.

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

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

---

d1 fi { d1 p1 , d1 p2 ,, d1 pm }  { c1 , p1 , pr1 , c2 , p2 , pr1 ,, cn , pm , pr1 }  { d2 p1 , d2 p2 ,, d2 pm } { d2 p1 , d2 p2 ,, d2 pm } , { c1 , p1 , pr2 , c2 , p2 , pr2 ,, cn , pm , pr2 }  { d3 p1 , d3 p2 ,, d3 pm }  d3 fi

(1.5)

где C {c1 ,c2 ,...,cm } — множество каналов передачи данных.

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

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

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

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

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

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

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

---