Таблица 18. Коэффициенты готовности участков
|
Участок |
Коэффициент готовности ПУ |
Коэффициент готовности РУ |
Коэффициент готовности участка |
|
Севастополь |
9,9999999969E-01 |
9,9999998021E-01 |
9,9999997991E-01 |
|
Ялта |
9,9999999703E-01 |
9,9999994993E-01 |
9,9999994697E-01 |
|
Алушта |
9,9999999457E-01 |
9,9999993502E-01 |
9,9999992959E-01 |
|
Судак |
9,9999998096E-01 |
9,9999989592E-01 |
9,9999987688E-01 |
|
Феодосия |
9,9999996438E-01 |
9,9999987186E-01 |
9,9999983624E-01 |
|
Керчь |
9,9999991246E-01 |
9,9999989685E-01 |
9,9999980931E-01 |
|
Джанкой |
9,9999997447E-01 |
9,9999988693E-01 |
9,9999986140E-01 |
|
Красноперекопск |
9,9999998515E-01 |
9,9999990586E-01 |
9,9999989100E-01 |
|
Евпатория |
9,9999999980E-01 |
9,9999998430E-01 |
9,9999998410E-01 |
Поскольку коэффициент готовности каждого участка сети представляет собой вероятностную оценку того, что конкретный участок окажется в работоспособном состоянии в произвольный момент времени, необходимо учитывать тот факт, что участок сети работоспособен в двух вариантах: прямой организации трассы (кратчайшей) и резервной (обратной). Для этого коэффициент готовности был посчитан для двух вариантах.
Вероятность того, что участок сети будет не работоспособен определена формулой 17.
, (17)
для прямого участка и для обратного участка, однако участок будет
неработоспособен если оба пути будут недоступны, вероятность чего можно
посчитать как вероятность несвязанных событий или просто сумму вероятностей по
формуле 18.
(18)
Вычитая получившуюся сумму из единицы, получаем значения готовности
участка. Поскольку работоспособность всей сети сохраняется только при условии
работоспособности всех участков, итоговая готовность получается из формулы 20.
(20)
где M - количество элементарных участков
сети. Таким образом, из формулы 20 получаем, что коэффициент готовности всей
сети равен:
Подобный уровень готовности сети обеспечивает порядка полуминуты
недоступности сети в год, что является прекрасным показателем для отрасли, а
также удовлетворяет поставленному техническому заданию.
Поскольку техническим заданием проектирования определены максимальные
параметры задержки на прохождение пакета по сети, необходимо провести
соответствующий расчет данного параметра. Для этого воспользуемся формулой
определения оптической составляющей задержки 21. Так как оптические элементы не
используют каких-либо дополнительных компонентов при прохождении сигнала кроме
кварцевого волокна и светового пучка, то
, (21)
где с - скорость светового потока, а
- максимально возможная длина
оптического участка сети. Таким участком является участок полного кольца,
составляющий не более 1000 км исходя из таблиц, представленных в Приложении Б.
Максимальная задержка на коммутацию рассчитывается исходя из числа устройств, через которые проходит пакет, проходящих по сети и составляет не более 10 устройств в наихудшем случае, то есть в случае отказа абсолютно всех основных каналов и устройств сети. Каждое устройство вносит задержку:
мкс - маршрутизаторы ядра,
мкс - коммутаторы доступа,
мкс - коммутаторы агрегации,
что внесёт в худшем случае не более чем 1,2мс задержки. Таким образом
общая максимальная задержка по сети равняется сумме максимимальной
коммутационной и оптической задержек:
Параметры расчетов удовлетворяют техническому заданию дипломного проекта.
Проведённые математические расчеты параметров сети передачи данных позволяют выделить основные тезисы, относительно построенной сети передачи данных.
· Общий коэффициент надежности составляет
, что обеспечивает не более 30 секунд
недоступности услуг связи в год на сети датацентров.
· Параметры надежности и отказоустойчивости удовлетворяют требованиям, которые заложены в задание на дипломное проектирование.
· Максимальная задержка при передаче трафика по сети составляет не более 3,2 мс при учёте выхода из строя основных путей следования, а также обрывов кабельной трассы. Данный параметр удовлетворяет максимуму, который согласно техническому заданию составляет 20мс.
· Длина элементарного участка не может составлять более 120 км вследствие необходимости усиления сигнала, что напрямую соотносится с проектным решением. На местах отсутствия активных узлов установлены усилители на эффекте рассеяния Рамана.
· Величина дисперсии, расчёт которой произведён в главе 3 для каждого участка сети, не превышает допустимых порядков для выбранного оборудования организации сети передачи центров обработки данных.
· Техническое решение соответствует нормам и параметрам, которые определены в ТЗ проекта.
Основу взаимодействия между центрами обработки данных составляет выбранный протокол маршрутизации. Достоинства и недостатки существующих протоколов маршрутизации были описаны ранее в пункте 3.3 аналитической части проекта, исходя из выводов которой в качестве протокола внутренней маршрутизации был выбран OSPF. В кратком виде достоинства протокола, которые позволили предпочесть его над другими следующие.
· Маршрутизация осуществляется на основе состояния каналов передачи данных.
· Существуют возможности тонкой настройки таймеров протокола.
· Реализована поддержка протокола MPLS.
· Иерархическая структура построения основных компонентов протокола маршрутизации.
Согласно стандарту RFC2328, в котором описан вышеуказанный протокол, необходимо разделить всё пространство логических связей внутри и между центрами обработки данных на зоны. Зоны представляют собой сегменты, состоящие из интерфейсов третьего уровня и маршрутизаторов, по заранее выбранной логике, чаще по территориальному или функциональному признаку.
В сети датацентров единственным решением является разделение на зоны по
признаку отношения к центру обработки данных. Нумерация зон ведется в
произвольном, однако заранее определённом порядке. Порядок зонирования
представлен в таблице 19.
Таблица 19. Распределение устройств и интерфейсов сети по зонам OSPF
|
Номер зоны |
Включённые интерфейсы |
|
Area 0 |
Каналы между маршрутизаторами ядра, петлевые интерфейсы маршрутизаторов ядра. Все маршрутизаторы точек обмена трафиком, петлевые интерфейсы маршрутизаторов точек обмена трафиком. |
|
Area 1 |
Все интерфейсы третьего уровня коммутаторов агрегации ЦОД Симферополь, включая петлевые. Каналы связи между маршрутизаторами ядра и коммутаторами центров обработки данных г. Симферополь. |
|
Area 2 |
Все интерфейсы третьего уровня коммутаторов агрегации ЦОД Севастополь, включая интерфейсы обратной петли. Каналы связи между маршрутизаторами ядра и коммутаторами центров обработки данных г. Севастополь. |
|
Area 10 |
Все интерфейсы третьего уровня двух коммутаторов агрегации резервного ЦОД Феодосия, включая интерфейсы обратной петли. Каналы связи между маршрутизаторами ядра и коммутаторами центров обработки данных г. Феодосия. |
|
Area 11 |
Все интерфейсы третьего уровня двух коммутаторов агрегации резервного ЦОД Джанкой, включая петлевые. Каналы связи между маршрутизаторами ядра и коммутаторами центров обработки данных г. Джанкой. |
|
Area 21 |
Каналы связи между устройствами ядра сети в г. Феодосия и маршрутизатором в г. Судак |
|
Area 22 |
Каналы связи между устройствами ядра сети в г. Феодосия и г. Севастополь и маршрутизатором в г. Алушта |
|
Area 23 |
Каналы связи между устройствами ядра сети в г. Симферополь и г. Севастополь и маршрутизатором в г. Евпатория |
В случае внедрения дополнительных точек включения, номер зоны для
образующих центров обработки данных берётся по порядку из первого десятка, для
резервных датацентров из второго десятка, для узлов связи и других включений из
третьего десятка. Внешний вид иерархического разбиения можно показать на схеме
(см. Рисунок 24).
Рисунок
22. Схема согласования зон протокола OSPF
Для обеспечения доставки маршрутной информации от точек обмена трафиком в
г. Керчь и г. Красноперекопск, на сети внедряется также протокол iBGP, который позволяет передать наиболее
выгодный маршрут до сети во внешней сети в центры обработки данных. Протокол iBGP устанавливает сессию по TCP:79 порту, при этом обязательным не
является осуществление непосредственного подключения двух устройств друг к
другу. Система реализована таким образом, что решение о выборе лучшего маршрута
принимают устройства, которые осуществляют маршрутизацию в центрах обработки
данных, при этом перенаправляя маршрутные обновления далее агрегирующим сетевым
коммутаторам. Вследствие включения LDP/MPLS на всех каналах передачи данных,
использование полносвязной топологии BGP в пределах сети не требуется (см. Рисунок 25).
Рисунок
25. Организация BGP-связности между объектами сети
Как видно из представленной схемы организации BGP, организуется четыре типа сессий:
· классическая iBGP-сессия, для передачи маршрутной информации до ЦОД;
· iBGP-сессия с использования зеркалирования маршрутных данных Route-Reflect, используется для передачи iBGP-маршрутов iBGP соседям;
· классические eBGP сессим, для передачи маршрутных данных от других сетей;
· MP-BGP или многопротокольная BGP сессия, для передачи маршрутных данных в отличных от IPv4 семействах и группах протоколов, например multicast или RT:IPv4 (L3VPN).
Для осуществления возможности приема и передачи трафика в сеть Интернет, предприятие, осуществляющее обслуживание ЦОД и узлов связи имеет статус LIR [Local Internet Register] и выданный блок адресов IPv4 и IPv6 для предоставления сервисов конечным клиентам, а также под инфраструктуру сети передачи данных. На этапе проектирования, данную функцию взяла на себя компания ЗАО «Диджитал Нетворк», выдав блок адресов на инфраструктуру сети центров обработки данных, а также блоки для документирования порядка предоставления тестовых сервисов. В рамках проекта используется частная автономная система ASN 65500, поскольку выдача реальной автономной системы регистрируется негосударственной некоммерческой организацией RIPE NCC уже по факту физического наличия оборудования и свидетельств о регистрации юридического лица.
Под инфраструктурные нужды была выдана подсеть из 256 адресов
213.248.0.0/24, которые были распределены на подсети в бесклассовой нотации в
соответствии с таблицей 20.
Таблица 20. План разбиения адресного пространства сети
|
Сеть |
Начальный адрес |
Конечный адрес |
Назначение |
|
213.248.0.0/27 |
213.248.0.0 |
213.248.0.31 |
Идентифицирующие адреса каждого устройства сети, адрес локальной петли. |
|
213.248.0.128/25 |
213.248.0.128 |
213.248.0.255 |
Адреса интерфейсов типа точка-точка на всех интерфейсах третьего уровня, осуществляющих маршрутизацию трафика, либо коммутацию трафика по меткам. |
|
213.248.0.64/27 |
213.248.0.64 |
213.248.0.95 |
Vlan управления коммутаторами узлов связи |
|
213.248.0.96/27 |
213.248.0.96 |
213.248.0.112 |
Интерфейсы точка-точка для подключения пиринговых каналов на точках обмена трафиком |
|
213.248.0.32/27 |
213.248.0.32 |
213.248.0.63 |
Интерфейсы точка-точка для подключения клиентов с собственными автономными системами, включая локальных провайдеров. |
Таблица соответствия сетевых адресов внутреннего использования приведена
в Приложении В. Для работы с интересами частных лиц в четыре центра обработки
данных выданы равными блоками по 256 адресов сети, которые представлены в
таблице 21.
Таблица 21. Клиентское адресное пространство сети
|
Сеть |
Начальный адрес |
Конечный адрес |
Назначение |
|
213.248.1.0/24 |
213.248.1.0 |
213.248.1.255 |
Доступно для использования розничными клиентами в ЦОД Симферополь |
|
213.248.2.0/24 |
213.248.2.0 |
213.248.2.255 |
Доступно для использования розничными клиентами в ЦОД Севастополь |
|
213.248.3.0/24 |
213.248.3.0 |
213.248.3.255 |
Доступно для использования розничными в резервном ЦОД Феодосия |
|
213.248.4.0/24 |
213.248.4.0 |
213.248.4.255 |
Доступно для использования розничными клиентами в резервном ЦОД Джанкой |
Все ресурсы были разделены с точки зрения максимальной экономии ресурсов адресного пространства, поскольку современный рынок услуг всё больше и больше сталкивается с исчерпанием адресов IPv4.
Весной 2012 года европейский регистратор RIPE NCC, который ведёт распределение адресного пространства IPv4 в Европе, сообщил что адреса четвертой версии протокола IP закончились и более не выдаются. В связи с этим, в последние годы видна положительная тенденция предоставлении сервисов по протоколу IP шестой версии. Для реализации возможности предоставления подобных услуг клиентам ЦОД и узлов связи, возможно использование т.н. Native Ipv6, либо 6PE технологии на датацентровой сети.