CC BY
26Б.М. Захир, А. С. Грачева
МОДЕЛИРОВАНИЕ ПОВЕДЕНИЯ СЕТИ, ПОСТРОЕННОЙ НА ГРАФЕ С НЕСТАНДАРТНОЙ ДОСТИЖИМОСТЬЮ И С ПРИМЕНЕНИЕМ АЛГОРИТМА ТЕКУЧЕГО ВЕДРА
В статье рассматриваются разработанная модель телекоммуникационной сети, построенной на графе с нестандартной достижимостью. Реализован вариант оптимизации работы сети методом внедрения узлов с потерями в оную, параметры и позиция которых должны рассчитываться на основании моделирования сети с повышенными нагрузками.
Ключевые слова: модель, анализ, графы с нестандартной достижимостью, информационно-телекоммуникационные сети, алгоритм текучего ведра, программный комплекс, нагрузочное моделирование, python.
Проблематика. 12 апреля 2018 года Правительство РФ приняло постановление № 445 «Об утверждении Правил хранения операторами связи текстовых сообщений пользователей услугами связи, голосовой информации, изображений, звуков, видео- и иных сообщений пользователей услугами связи». Согласно этим правилам, к операторам связи, действующим на территории России, будет применяться ряд требований касательно хранения данных, которыми они оперируют. В рамках этой работы нас интересуют следующий пункты требований:
1.Операторы телефонной связи и услуг передачи данных для целей передачи голосовой информации хранят голосовой трафик и текстовые сообщения в полном объёме в течение 6 месяцев.
2.Интернет-провайдеры с 1 июля 2018 года хранят трафик в нулевом объёме, а с 1 октября 2018 года — в полном объёме. Ёмкость системы хранения данных должна равняться объёму трафика, переданному за 30 суток, предшествующих дате ввода в эксплуатацию технических средств накопления информации. То есть провайдер обязан сохранять весь трафик пользователей в течение всего срока, пока хватает ёмкости установленных накопителей.
Соответственно, весь трафик, проходящий по ИТС, должен быть скопирован и транспортирован в системы хранения. При создании такой системы, безусловно, встанет вопрос об оптимальности тех или иных решений. Например, вопрос о размещении в сети программно-аппаратных средств копирования данных. Сколько их сделать по всей сети? На каждую базовую станцию, отвечающую за распределение трафика непосредственно абонентам, данное оборудование не поставить - таких станций очень много. Однако это и не требуется - можно решить проблему математически, определив узлы, на которых будет происходить копирование. При наличии модели информационно-телекоммуникационной сети (ИТС), которая может просчитать ресурсозатратность того или иного варианта размещения узлов копирования данных, можно определить критерии и свести затраты ресурсов при размещении к минимуму. Наша модель позволяет провести такое моделирование посредством алгоритмов поиска пути в графе с нестандартной достижимостью вершин. Здесь граф, являющийся ориентированным и взвешенным, представляет собой ИТС, а его вершины - узлы сети. На данный момент реализовано два вида алгоритмов поиска пути - на графе с вентильной достижимостью и с магнитной. Путем установки порога достижимости равным 1 можно получить путь, который обязательно проходит только один узел из тех, что специализированы для копирования данных.
Также данная модель позволяет решить другую проблему - получения избыточного количества данных. Так как мы знаем, что пакет попадет на узел копирования один раз, мы можем быть уверены, что и дубликатов в хранилище данных не появится.
Естественно, при появлении таких специальных узлов, объем трафика, который они через себя будут пропускать, станет больше. И эти нагрузки надо будет, во-первых, посчитать, а во-вторых - попробовать избежать перегрузок, которые могут появится. Это третья проблема, которую мы решаем посредством моделирования в данной научной работе. В нашей модели реализована одна из самых простых и в то же время популярных мер борьбы с избыточными нагрузками - алгоритм дырявого ведра.
О графах с нестандартной достижимостью
Программная модель, используемая в рамках данного исследование, берет начало своей разработки в нашей предыдущей работе [1]. В ней сделан акцент на математической части модели: дан теоретический
© Б.М. Захир, А.С. Грачева, 2022.
базис по графам с нестандартной достижимостью, описана реализация алгоритмов поиска путей и приведены выкладки по вычислению параметров маршрутов на рассматриваемых графах.
К текущей работе программа претерпела множество архитектурных изменений, но математическое ядро осталось неизменным.
Теория. Область применения теории графов достаточно широка, особенно сильно она используется в инфокоммуникационных сетях, моделях заражения и т.д. Во многом такие задачи требуют разработки алгоритмов анализа процессов случайного блуждания по графу и случайного распределения ресурса на графе. Задачи распространения спама оказались родственными задачам распространения инфекций (медицина) или распространению слухов (социология). Объединяют эти задачи общая математическая модель - ориентированный граф, лежащая в их основе, а также алгоритмы, которые используются для решения этих задач. Построение имитационной модели таких сетей является более простым, чем построение математической.
Ориентированные графы с нестандартной достижимостью являются орграфами, в которых множество допустимых путей может не совпадать с множеством всех путей на графе. Допустимые пути определяются некоторыми дополнительными условиями на их формирование, называемыми типом ограничений на достижимость.
При этом одной из главных проблем в области телекоммуникации является проблема управления трафиком с целью обеспечения заданных норм качества (QoS) по каждой предоставленной услуге большинству абонентов, в частности, для тех, кто находится в роуминге.
При передаче данных с гарантированной скоростью передающее устройство должно управлять ресурсами в динамическом режиме. Параметры классов QoS 1,2, 3 и 7 - это сервисы, предоставляемые абоненту в реальном времени. Основным ограничивающим фактором при их применении является допустимая задержка в доставке пакетов.
Значение показателя надежности передачи пакета - скорость потери пакетов PERL оценивается только при доставке пакетов с помощью протокола TCP/IP. Поэтому при значении допустимых потерь меньше 10-6, используется передача с подтверждением. Наибольший приоритет (1 класс) имеет наименьший параметр, к нему относится трафик по управлению сетью. Класс 9 применяется по умолчанию при доставке IP-трафика (чтение файлов из Интернета, E-mail, видео) непривилегированным пользователям.
Таким образом, для обеспечения заданного качества обслуживания всех пользователей канала передачи, необходимо вводить пороги или использовать механизм «текучего ведра» для разгрузки в определенных узлах сети.
Для правильного определения мест, где надо установить «ведро» порогов, необходимо ввести функцию потерь, которая будет характеризовать потери трафика при несоблюдении допустимой задержки (leaky bucket algorithm).
Рис. 2.
Каждый хост, принадлежащий сети, может соединяться через интерфейс, содержащий дырявое ведро, то есть конечную внутреннюю очередь. Если пакет появляется в очереди, когда очередь полная, пакет игнорируется. То есть, если несколько процессов хоста пытаются послать пакеты, когда в очереди
уже стоит максимально допустимое число пакетов, новый пакет игнорируется. Такой интерфейс реализуется либо аппаратно, либо программно, операционной системой хоста. По сути это не что иное, как однолинейная система массового обслуживания с постоянным временем обслуживания.
Гипотеза: хосту разрешается посылать в сеть один пакет за один такт. В зависимости от передаваемых сообщений можно ограничивать либо количество пакетов (когда кадр постоянной длины), либо количество байт (когда кадр переменной длины). Во втором случае, если правилом установлена передача 1024 байт за тактовый интервал, то за этот период могут быть переданы в сеть либо один пакет размером 1024 байта, либо два пакета по 512 байт, либо четыре пакета по 256 байт и т. д. Если оставшееся количество байт меньше размера следующего пакета, следующий пакет должен ждать начала следующего такта.
Само дырявое ведро состоит из конечной очереди. Когда прибывает пакет и в очереди есть место, пакет добавляется к очереди, в противном случае пакет игнорируется. Если очередь не пуста, то в течение каждого тактового интервала в сеть передается по одному пакету или количеству байт, в зависимости от алгоритма.
То же самое можно представить себе по-другому: в виде ведра, которое в данный момент наполняется. Вода вытекает из хоста со скоростью R, а объем ведра, равен B. Чтобы отправить пакет, необходимо, чтобы из ведра можно было «вылить» накопившуюся информацию, или маркеры (так обычно называют содержимое ведра), а не налить ее туда. В ведре может содержаться ограниченное число маркеров (не более B); если ведро пустое, для отправки пакета необходимо подождать, пока не появятся новые маркеры. Этот алгоритм называется алгоритмом маркерного ведра (token bucket algorithm).
При расчете длительности максимальной выходной пачки (до тех пор, пока ведро не станет пустым) нужно учитывать, что пока ведро опустошается, появляются новые пакеты на передачу. При длительности пачки S с, емкости маркерного ведра B байт, скорости появления маркеров R байт/с и максимальной выходной скорости M байт/с очевидно, что максимальное количество переданных байтов в пачке будет равно B + RS байт. Мы также знаем, что количество байтов, переданных в пачке с максимальной скоростью, равно MS. Таким образом,
B + RS = MS.
После прохождения алгоритма «текучего ведра» сети продолжает работу по алгоритмам с различными видами достижимостей.
1.Управление ведром
Для описания процесса управления длиной буферной очереди в «ведре» рациональным видится использование дифференциального уравнения Риккати, которое в общем случае не имеет решения в квадратурах:
y(t)+a p(t)y2(t)=p R-1(1-p(t)) (1)
где, y(t) - скорость передачи данных (пакеты/с); p(t) - функция вероятности потери пакетов; R -задержка (с); а - параметр мультипликативного уменьшения размера «вытекающей части ведра» передачи данных при потере пакета; р - параметр аддитивного увеличения размера «вытекающей части ведра».
В процессе моделирования трафика беспроводной сети целесообразно предусмотреть возможность изменения топологии (реконфигурации) сети, поэтому, для оптимального выбора структуры следует задать оценку эффективности передачи данных. Для этой цели пригодно соотношение
E=Wk/(Wk+Ws) (2)
где, Wk - количество переданных полезных данных; Ws - количество служебной информации.
Объем служебного трафика можно представить, как функцию Vs=f(Fr,Vo) частоты реконфигурации сети Fr и количества узлов nVi в кластере V0. Поэтому, для уменьшения служебного трафика в сети частота реконфигураций на заданном промежутке времени ДТ и количество кластеров сети должны быть сведены к минимуму. Тогда оптимальный размер сети можно охарактеризовать с помощью коэффициента k
k = Fr * —, к ^ min r AT
Для проверки полученной модели достаточно сравнить величину модельного трафика со значениями, выбранными в качестве эталона. Удобным инструментом для решения этой задачи может служить показатель конкордации p(tk) модельных и эталонных значений трафика на заданном временном интервале
, л _ 2m(tk)M(tk)
P(tk) = m(tk)2+M(tk)2 (3)
где, tk - к-й момент времени контроля трафика; m(tk) - математическое ожидание эталонного трафика; M(tk) - математическое ожидание модельного трафика.
Описание и исследование модели
В ходе работы была создана программная модель, позволяющая проводить расчет параметров прохождения трафика по ИТС при наличии на ней нестандартной достижимости вентильного или магнитного типов; или при их отсутствии. Модель создана на языке Python и программно представляет собой модульный проект.
2.Архитектура и схема
Модульность позволяет обеспечить удобное масштабирование и развитие программы, а так же упрощает понимание деталей ее работы. Это достигается путем использования принципа разделения ответственности. Сегодня этот принцип также называют разработкой, основанной на компонентах (Component Driven Development, CDD).
Компонент - это ограниченный участок проекта, или программа, грубо говоря, который имеет четко поставленный ряд задач. Или, в идеале, одну задачу. Иначе сказать - свою зону ответственности.
Далее будут описаны основные модули программы.
1.Название: Packets
Содержание: BasePacket.
Класс, описывающий модель пакета. Имеет состоит из заголовков и данных. В заголовках хранится такая информация, как протокол, по которому осуществляется передача, адрес точки отправления пакета и точки его назначения и прочее. Раздел данных содержит часть информационного сообщения, что решил отправить пользователь сети. Помимо заголовков и данных, каждый пакет имеет собственный уникальный программный идентификатор и идентификатор потока данных, частью которого он и является. Тип пакета и содержание его заголовочной части определяется именно его потоком. Пакетов вне потока в модели существовать не может.
2.Название: Streams
Содержание: BaseStream, TCPStream, UDPStream.
Классы, моделирующие потоки данных в сети. В терминах данной модели поток - это носитель информационного сообщения пользователя сети, представляющий собой множество пакетов данных. Сообщение разбивается на пакеты, каждый из которых доставляется до точки назначения индивидуально. Пакеты потока, для которого определен протокол TCP, отправляются по очереди с ожиданием сообщения о том, что предыдущий пакет успешно доставлен. UDP отправляются независимо друг от друга.
3.Название: Nodes
Содержание: BaseNode, TBLoadBasedNode.
Модуль содержит два класса, которые описывают строительную единицу сети - узел. Узел имеет три хранилища пакетов - queue (очередь - то есть хранилище пакетов, которые будут перемещаться дальше), awaiting (хранилище образов пакетов TCP, которые были отправлены с этой вершины - на случай, если пакет придется отправлять заново, из-за того что с предыдущей попытки он не дойдет) и successful (пакеты, для которых данный узел - точка назначения). Моделью узла данный класс, помимо упомянутого выше, делает симуляция случайных временных задержек при обработке данных, повышения временных задержек на обращение к памяти при повышенной загрузке узла, а также возможных повреждений данных при обработке. Подробно о том, как рассчитывается загрузка узла, как рассчитывается коэффициент замедления обработки данных, уровень случайных повреждений данных и другие параметры, будет сказано ниже. TBLoadBasedNode - вершина, на которой реализован алгоритм дырявого ведра. Подробности тоже будут приведены ниже.
4.Название: Networks
Содержание: BaseNetwork, TBNetwork.
Данный модуль - сердце данного программного проекта. А если точнее - им является класс BaseNetwork, который и представляет собой модель сети. Грубо говоря, модель сети суть совокупность трех объектов - набора узлов, объекта оператора сети и объекта трафика сети, то есть той сущности, что порождает нагрузку на сеть. Оператор в данном случае - тот, кто управляет этой нагрузкой. Например, производит действия по перемещению пакетов с вершины на вершину. Подробнее о том, как работает данная модель - в частности, как происходит моделирование движения информации по сети - также будет сказано ниже в отдельном разделе. TBNetwork - модели сети, в которой присутствуют узлы с внедренным алгоритмом дырявого ведра.
5.Название: NetworksSupport
Содержание: Jitter, RandomJitter, Traffic, TCPStreamData, UDPStreamData, Operator, BaseRe-portAnalyzer.
Часть программного комплекса, содержащая классы, несущие вспомогательный для работы модели сети функционал. Jitter и RandomJitter, например, отвечают за создание значений случайной задержки об-
работки данных. Traffic -класс тот самого объекта трафика, составляющего часть класса сети. Строго говоря, трафик - это совокупность потоков данных с некоторыми особенными методами, что и отличает этот объект от простого списка, к примеру.
TCPStreamData и UDPStreamData - своего рода обертки вокруг объектов потока данных, призванные упростить программу. Они сделаны из тех соображений, что поток данных можно отправить откуда угодно и куда угодно, а вот конкретная имплементация этого потока, то есть совмещение его с информацией, что отправка происходит по таким-то маршрутам - это и есть объект данного класса.
Operator - еще один класса объекта, формирующего модель сети. Относительно него тоже можно сказать что, в общих чертах, это совокупность объектов данных о потоках - StreamData.
BaseReportAnalyzer - класс объектов, чье предназначение - определить на основе отчетов о проведенном моделировании сети узлы сети, на которых требуется применить алгоритм дырявого ведра.
6.Название: NetworksReports
Содержание: BaseReport, TrafficReport, MaintenanceReport.
Модуль, содержащий классы объектов, осуществляющих анализ прошедшего моделирования. Здесь BaseReport - интерфейс.
TrafficReport - отчет о состоянии трафика, который шел по сети в рассматриваемом сеансе моделирования. В этом отчете показывается, какие пакеты были утеряны, каковы были искажения данных при обработке на узлах и какое время ушло на доставку. Эта информация предоставляется как в разрезе отдельных пакетов, так и с точки зрения отправляемых сообщений.
MaintenanceReport описывает то, как вела себя сеть на протяжении моделирования. Где были недогрузы, где перегрузки; какие вершины достигали наивысших перегрузок, а какие были дольше всего перегружены; и тому подобные вопросы освещает данный отчет.
3. Алгоритмы функционирования и устройство моделей узлов
В модели узла, как уже было сказано выше, фигурирует некое хранилище пакетов, разделенное на три части - для пакетов к отправлению (queue), TCP-пакетов, ждущих подтверждения (awaiting) и для доставленных (successful). В зависимости от заполненности хранилища менялась его скорость обработки пакетов. Чем сильнее узел загружен - тем ниже скорость. Однако тут есть один нюанс. С аппаратной точки зрения нет смысла хранить доставленные пакеты в кратковременной памяти - то есть в оперативной, и поэтому логично под загрузкой узла понимать именно суммарный вес пакетов, находящихся в queue и awaiting. Нет смысла потому, что, по сути, доставленные пакеты уже выведены из сети - их клиенты (абоненты) сети начинают хранить на собственных компьютерах после получения.
В формуле, рассчитывающей коэффициент замедления, фигурирует отношения емкости узла (то есть объема ее оперативной памяти) к суммарному размеру пакетов в queue и awaiting. График зависимости коэффициента от загрузки индивидуален для каждой вершины. Его определяют три параметра: коэффициент при нулевой загрузке, коэффициент при загрузке в 100% и коэффициент, на который будет выходить узел при превышении допустимой нагрузки.
Про превышение допустимой нагрузки стоит сказать отдельно. Очевидно, что в реальности превышения нагрузки случится не может. На текущий момент пакеты в программной модели следуют тем маршрутам, что были рассчитаны при их нахождении в точке отправления. По сути - происходит следование по пути виртуального пакета, который посылается перед началом передачи информации по сети. Изменение маршрутов пакетов в зависимости от нагрузки сети находится в разработке.
Это значит, что для того, чтобы определить узкие с точки зрения пропускной способности места сети, нужно дать возможность процессу моделирования закончиться. Ведь если следовать реальному поведению сети и перегруженного узла, то узел встанет и перестанет пропускать трафик через себя, а сеть перебросит этот трафик на другие узлы. В нашем же случае целесообразно посмотреть, какая емкость узла была бы достаточной, чтобы не привести узел к остановке функционирования при рассматриваемом трафике. А посмотреть это можно именно при помощи предоставления возможности узлу хоть с какой-то скоростью обрабатывать информацию.
Можно объяснить такое поведение модели также и тем, что сеть при обнаружении критически высоких нагрузок на узел выделяет тому дополнительные резервные мощности.
В общем виде функция зависимости коэффициента замедления ks = f(l) от относительной загрузки узла I выглядит следующим образом: ff(l) = 1,1 = 0
U(i) = b, iem\[0}vb>fp b = i-el--i*(fh-fl), [f(i) = fp, iern\[0}vb<fp
где I - значение относительной загрузки, от 0 до 1; fi - коэффициент при нулевой загрузке, fh -коэффициент при загрузке в 100%; fp - коэффициент, на который будет выходить узел при превышении допустимой нагрузки.
В качестве примера приводится график данной функции для узла с /¿ = 1, fh = 0.65, fp = 0.08.
Коэффициент замедления к,
1.05 1.00^-0.95 0.90 0.85 0.80 0.75 0.70 0.65--0.60 0.55 0.50: 0.45 0.40 0.35 0.30 0.25 0.20 0.15 0.10.. 0.05" 0.00-5
Относителная загрузка узла I
Рис. 3. График функции зависимости коэффициента замедления ks от относительной загрузки узла l
Рассмотренный аспект моделирования применяется как в обычных узлах, так и в узлах с применением алгоритма дырявого ведра.
В текущей версии программы реализован алгоритм дырявого ведра, который принимает решение о выбросе пакета на основе данных о загрузке вершины, на которую этот пакет поступает. Условие выброса - значение относительной загрузки превышает некоторый порог, установленный на этой вершине.
4. Алгоритмы функционирования и устройство моделей сетей
Модель передачи пакетов по сети реализована как событийная. Время в ней фигурирует только при расчете длительности путешествия того или иного пакета. Таким образом, программа позволяет производить моделирование не в режиме реального времени, а со скоростью, что зависела только от характеристик того компьютера, на котором будет запущена программа. Такую модель можно сравнить с формулой, которая меняется в зависимости от заданных параметров моделирования.
В модели сети пакеты появляются тогда, когда появляются в каком-либо из её узлов. При чем они не могут появится там одномоментно - емкость узлов не бесконечна. Для того обеспечения данного процесса существует сущность трафика. Объект данного класса у сети один и он объединяет в себе потоки. Потоками в программе называются множества пакетов, и каждый поток представляет собой одно сообщение. Пакеты из трафика забираются по мере освобождения узлов сети, которые для данных потоков обозначены как стартовые. Освобождение узлов происходит благодаря движению пакетов.
Передвижение пакетов по сети происходит путем повторяющегося перебора всех вершин сети до тех пор, пока все пакеты не окажутся в своих пунктах назначения. Во время перебора алгоритм обрабатывает каждый пакет, содержащийся на вершине и перемещает его в какую-либо другую в случае, если для данного пакета текущая вершина промежуточная.
Чтобы время путешествия пакетов не зависело от того, в каком порядке происходит перебор вершин, была введена сущность оператора. Объект этого класса у модели сети один единственный. Благодаря нему сеть узнает, сколько времени на данный момент пакет находится в пути и изменяет это время. Помимо операций со временем, с помощью оператора сеть узнает, какой следующий узел пакета и какая у него точка назначения.
5. Алгоритм проведения моделирования
Ниже приведена блок-схема вида «диаграмма последовательности» с описанием сценариев работы программы.
Рис. 4. Блок-схема базового сценария работы модели
Стоит сразу сказать, что это только один из сценариев использования данной программы. Он выбран по причине того, что в полной мере отражает её нынешний функционал и позволяет провести законченное исследование заданной сети.
Данный сценарий разбивается в простейшем случае на две основных стадии - первичного моделирования и целевого моделирования. Цель первой стадии - найти в сети такие точки, где трафик в условиях конкретной нагрузки наивысший и приводит к перегрузкам. Далее проводится анализ и в сеть вводятся узлы, на которых действует алгоритм текучего ведра. После чего моделирование производится повторно, а результаты сравниваются. При необходимости, вторую стадию можно повторять неоднократно.
На диаграмме мы видим 6 этапов работы модели. Рассмотрим их по порядку.
1.На первом этапе пользователю необходимо создать входные данные для программы. В первую очередь это математическое описание графа, на котором базируется сеть. Для этого шага выбрана таблица смежности графа как довольно простой и наиболее удобный с программной точки зрения вариант представления графа. Пользователь создает файл с данной таблицей в формате csv, после чего переходит к созданию конфигурационного файла. В нем указываются такие данные, как путь до файла с графом, тип
достижимости сети, соответствующие данному типу дополнительные множества вершин, а так же опции, связанные непосредственно с телекоммуникационной сутью модели. То есть емкость узлов, скорость обработки данных, параметры перегрузки (/о^,^) и прочее.
С другой стороны - для каждого отдельного запуска нужны, собственно, данные для передачи. Для этого выбран стандартный текстовый файл - txt. Однако сеть имеет дело не с сообщениями напрямую, а с трафиком. Соответственно, для этого необходим и файл трафика. В нем указаны узлы отправки и назначения, размер пакета, протокол передачи и некоторые другие данные.
2.После создания всех этих файлов происходит чтение данных из этих файлов. Создается объект графа, из графа создается сеть.
3.Имея инициализированную сеть, пользователь может проводить моделирование. Для этого внутри сети создаются объект оператора и объект трафика, после чего трафик из файла вводится в сеть и запускается. Начинается процесс моделирования.
4.В результате первичного моделирования объект сети возвращает два отчета. Один - эксплуатационный, в котором описывается, как сеть перенесла работу с данным трафиком. Здесь содержится информация, какие вершины как были загружены, где происходили перегрузки и как долго длились.
Второй - информационный, где содержится оценка качества передачи информации по сети. Насколько велики помехи, как быстро была доставлена информация и прочее.
Рассмотрим пример выкладки из эксплуатационного отчета, полученного при исследовании модели ИТС по описываемому алгоритму.
Ниже представлены графики относительной загрузки узлов от моментов времени. Под временем подразумеваются итерации расчета программы.
Относителная загрузка узла I
2.220
2.109 1 998 1.887 1.776 1.665 1.554 1.443 1.332 1.221
1.110 0.999 0.888 0.777 0.666 0.555 0.444 0.333 0.222 0.111 0.000
1 11 21 31 41 51 61 71 81 91 101 111 121 131 141 151161 171 181 191 201211221231241251261271281291301311321331341351 361371381391401
Моменты Г
Рис. 5. График зависимости относительной загрузки узлов от моментов, базовый эксплуатационный отчет
На данном графике видно, что узел 14 подвергается слишком высокой нагрузке при передаче данного трафика. Нагрузка выходит далеко за 100% его вместимости. Также можно заметить пилообразный вид линий на графике. Эта особенность линий объясняется порядком совершения действий при расчете: сначала прибывающие на узел пакеты в узел добавляются, а потом убывающие с узла пакеты из хранилища узла удаляются.
При помощи отдельной сущности - анализатора - создается рекомендация о том, на каких вершинах установить алгоритм текучего ведра. Анализ производится на основе эксплуатационного отчета.
Исходя из того, что в примере все узлы, кроме 14, не показывают критических значений загрузки, анализатор сделает вывод, что алгоритм текучего ведра необходимо применить только на узле 14.
5.На данном этапе производится повторное моделирование сети с тем же самым трафиком, но с измененной конфигурацией. Производится сравнение отчетов, после чего в случае получения удовлетворительных результатов исследование заканчивается. По итогам данного исследования будет получена информация о том, как располагать на конкретной сети в конкретном случае узлы с текучим ведром, чтобы получить наивысшую скорость доставки информации и качество передачи при наименьших изменениях сети.
Рассмотрим график загрузки, аналогичный графику N. На новом графике видно два важных отличия: значения загрузки на узле 14 не превышают 100% и количество моментов сократилось вдвое. Такие изменения позволяют наглядно увидеть, что применение алгоритма текучего ведра оказывает существенный положительный эффект на качество работы сети.
Относителнаязагрузка узла I
1.00 0.95 0.90 0.85 0.80 0.75 0.70 0.65 0.60 0.55 0.50 0.45 0.40 0.35 0.30 0.25 0.20 0.15 0.10 0.05 0.00
— oode 1
- node 2
- node 4
- node 6
- - node 7 - node 8 node 9 - node 10 - node 11 — node 12
- node 13
- node 15
- node 17
/ ЧУЛ! [я W\\Y node 18
1 11 21 31 41 51 61 71 81 91 101 111 121 131 141 151 161 171 181 191 201
Моменты Г
Рис. 6. График зависимости относительной загрузки узлов от моментов, вторичный эксплуатационный отчет
6.Анализ дополнительных выкладок
Эффективность работы алгоритма в рассматриваемом примере также хорошо показывает график общей загруженности сети от моментов. Общая загруженность высчитывается как результат деления суммы величин загруженности всех узлов на емкость всех узлов.
Относителнаязагрузка сети I
0.0000360 0.0000342 0.0000324 0.0000306 0.0000288 0.0000270 0.0000252 0.0000234 0.0000216 0.0000198 0.0000180 0.0000162 0.0000144 0.0000126 0.0000108 0.0000090 0.0000072 0.0000054 0.0000036 0.0000018 0.0000000
- Базовый
- Нтпичный
1 21 41 61 81 101 121 141 161 181 2C 1 221 24 1 261 281 301 321 341 361 381 401
Моменты Г
Рис. 7. График зависимости относительной загрузки всей сети от моментов, оба эксплуатационных отчета
На данных эксплуатационных отчетов можно построить и отображение изменения средней загрузки узлов. Столбец с положительным значением обозначает увеличение загрузки на узле после применения алгоритма текучего ведра на узле 14, а с отрицательным - уменьшение загрузки.
Рис. 8. Относительное изменение средней нагрузки на узлах (вторичный относительно базового)
Как видно на графике выше, после введения оптимизационных мер загрузка на узле 14, как и ожидалось, сократилась. Остальная картина, показываемая графиком, тоже достаточно предсказуема. Произошло повышение средней загрузки на различных узлах сети, причем достаточно равномерно. Любопытным является падение загрузки на узле 9 - достаточно контринтуитивное изменение.
Для оценки качества передаваемой информации можно воспользоваться информационными отчетами. Достаточно показательным будет следующий график.
[20-30) (30-40) [46-50) [50-60) [6075) [76-80) [80-90)
Рис. 9. Количество доставленных пакетов в распределении по расчитанному времени (оба отчета)
Здесь можно видеть рассчитанное время доставки отдельных пакетов, на которые были разбиты сообщения - от 30 до 120 секунд (результат является искусственным в известной степени; величины скоростей обработки на узлах, емкостей узлов и прочих параметров подобраны довольно небольшими). На графике указано количество пакетов, дошедшее до получателя в определенный отрезок времени при отсчете с момента начала транспортировки трафика по сети.
По этому графику легко заметить, что все потерянные в результате работы текучего ведра пакеты -это наиболее долгие в плане доставки. Быстрые же все дошли.
Заключение. В данной работе была проведена теоретическая подготовка, проектирование и создание программной модели информационно-телекоммуникационной системы на основе графов с нелинейной достижимостью, в которой дополнительно была заложена функция добавления узлов с нестандартной достижимостью. Помимо этого, был проведен анализ работы модели, на основании которого получилось доказать возможность решения определенных проблем при эксплуатации реальных ИТС. В частности, проблемы избыточного копирования пакетов при хранении и оптимального размещения узлов копирования с точки зрения нагрузки на сеть. В качестве меры противодействия повышенной нагрузке была выбрана и исследована мера по введению на некоторые узлы алгоритма текучего ведра.
Библиографический список
1.Антонова В.М., Захир Б.М., Кузнецов Н.А. «Моделирование графов с различными видами достижимости с помощью языка Python», Информационные процессы, Том 19, № 2, 2019, стр. 159-169.
2.Постановление Правительства Российской Федерации от 12.04.2018 № 445 "Об утверждении Правил хранения операторами связи текстовых сообщений пользователей услугами связи, голосовой информации, изображений, звуков, видео- и иных сообщений пользователей услугами связи".
3.«О правилах хранения информации по «Закону Яровой», Алексейчук Андрей, юрист практики по интеллектуальной собственности/информационным технологиям АБ «Качкин и Партнеры»
4.«Закон Яровой и последствия для телеком-отрасли. 10 триллионов убытков», Эльдар Муртазин, издание «Mobile-Review».
ЗАХИР БОРИС МАКСИМОВИЧ - студент, Московский государственный университет им. Н.Э. Баумана, Россия.
ГРАЧЕВА АЛЕКСАНДРА СЕРГЕЕВНА - студент, Московский государственный университет им. Н.Э. Баумана, Россия.
