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

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

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

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

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

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

Можно представить такую модель облачного хранилища в виде графовой модели. Пусть облачное хранилище данных включает N серверов данных D ={d1 ,...,d N }, которые объединены между собой каналами связи. Специфика организации надежных хранилищ данных предполагает, что все серверы хранилища имеют непосредственную связь с любым другим. Таким образом такая сеть

серверов хранилища представляет собой полносвязный граф

GD = (D, LD ) , в

Котором LD представляют дуги графа, которые символизируют каналы связи между серверами данных.

Кроме серверов данных к облачному хранилищу принадлежат также K

---

Сателлитов St ={St1 ,..., StK }, которые также объединены между собою каналами связи. И, как в случае с серверами, все сателлиты имеют непосредственные связи с каждым сателлитом ( LSt ). Кроме того, все сателлиты связаны отдельными связями ( LZ ) из серверами данных, образуя полную модель сети хранилища данных, которая также представляет собой полносвязный граф

L = LD  LSt  LZ .

G = (P, L), в котором

P = St  D ,

Для пользователя облачное хранилище данных представлено, как сеть

сателлитов данных.GSt

 G GD , через которые он может получать доступ к хранилищу

Данная модель представления облачного хранилища данных не ограничивается его типом – частная, публичная или гибридная. Она позволяет абстрагироваться от типа хранилища, а сконцентрироваться на организации доступа к нему.

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

Решением данной проблемы может быть два варианта.

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

Хотя данный подход достаточно прост, его сложно обслуживать. Администратор должен постоянно заботиться о том, чтобы все серверы данных имели одинаковое содержание – проводить репликацию на N серверов данных. Это достаточно сложно с технической точки зрения. Кроме того, это приводит к дополнительным затратам долгосрочной памяти, так как копия каждого ресурса должна присутствовать на каждом сервере данных. Еще одним недостатком такого подхода является то, что он не позволяет его масштабировать на регионально-распределенные хранилища данных, учитывать удаленность клиентов от сателлитов и серверов данных.

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

---

Используя данную модель можно оценить эффективное время обмена между пользователями и хранилищем данных.

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

T ( f )  F , down V ( f ) down _ k

(1.6)

где k – пользователь данных,

Tdown

• время загрузки,

F – размер файла данных f .

Скорость получения файла f пользователем Vdown _ k ( f )

Vdown _ k ( f )  min(Vdown _ k ,Vdown _ St ( f )) ,

j

определяется:

де Vdown _ k

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

Vdown _ St ( f )

j

• скорость передачи файла f из хранилища к сателлиту

St j .

А скорость передачи файла f из хранилища к сателиту

St j

определяется

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

K Vdown _ St ( f )  min{Vupl _ St ,Vdown _ St ,Vdown _ d (St j , f )}, j j j i i1

(1.7)

где S

t

j

• сателлит j ,

d j – хранилище i ,

Vupl _ St

i

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

Vdown _ St

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

Итак, суммарная формула времени получения файла из хранилища будет определяться:

i

T ( f )  F . down K min{Vdown _ k ,Vupl _ St ,Vdown _ St , Vdown _ d (St j , f )} j j i i1

(1.8)

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

T ( f )  F . upl V ( f ) upl _ k

(1.9)

Скорость загрузки данных от k-го клиента:

Vupl _ k ( f )  min{Vupl _ k ,Vupl _ St ( f )}, j	(1.10)
Vupl _ St ( f )  min{Vdown _ St ,Vupl _ St , max(Vdown _ d (Sti , f ))}. j j j i

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

---

T ( f )  F . upl min{V ,V ,V , max{V (St , f )}} upl _ k down _ St j upl _ St j down _ di j

(1.11)

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

Заключение к 1-ой главе.

В результате работы в данном разделе:

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

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

Основные результаты раздела опубликованы в трудах [4, 5, 6, 10, 15, 16].

ГЛАВА 2.

РАЗРАБОТКА МЕТОДОВ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ РАСПРЕДЕЛЕННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ СИСТЕМ ОБЛАЧНЫХ ХРАНИЛИЩ ДАННЫХ

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

---

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

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

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

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

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

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

---