Русский
Русский
English
Статистика
Реклама

Sdn

Автоматизация сетевых сервисов или как собрать виртуальную лабораторию при помощи OpenDaylight, Postman и Vrnetlab

07.07.2020 18:11:11 | Автор: admin


В этой статье я расскажу, как настроить OpenDaylight для работы с сетевым оборудованием, а также покажу, как с помощью Postman и простых RESTCONF запросов этим оборудованием можно управлять. Работать с железом мы не будем, а вместо этого развернем небольшие виртуальные лаборатории с одним-единственным роутером с помощью Vrnetlab поверх Ubuntu 20.04 LTS.


Подробную настройку я покажу сначала на примере роутера Juniper vMX 20.1R1.11, а затем мы сравним ее с настройкой Cisco xRV9000 7.0.2.


Содержание


  • Необходимые знания
  • Часть 1: кратко обсуждаем OpenDaylight (далее по тексту ODL), Postman и Vrnetlab и зачем они нам потребуются
  • Часть 2: описание виртуальной лаборатории
  • Часть 3: настраиваем OpenDaylight
  • Часть 4: настраиваем Vrnetlab
  • Часть 5: с помощью Postman подключаем виртуальный роутер (Juniper vMX) к ODL
  • Часть 6: получаем и изменяем конфигурацию роутера с помощью Postman и ODL
  • Часть 7: добавляем Cisco xRV9000
  • Заключение
  • P.S.
  • Список Литературы

Необходимые знания


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



Часть 1: немного теории



  • Открытая SDN платформа для управления и автоматизации всевозможных сетей, поддерживаемая Linux Foundation
  • Java inside
  • Основан на Model-Driven Service Abstraction Level (MD-SAL)
  • Использует YANG модели для автоматического создания RESTCONF API сетевых устройств

Основной модуль для управления сетью. Именно через него мы будем общаться с подключенными устройствами. Управляется через свой собственный API.
Более подробно про OpenDaylight можно прочитать здесь.



  • Инструмент для тестирования API
  • Простой и удобный для использования интерфейс

В нашем случае он нам интересен как средство для отправки REST запросов на API OpenDaylight'а. Можно, конечно, и вручную запросы отправлять, но в Postman все выглядит очень наглядно и для наших целей подходит как нельзя лучше.
Для желающих покопаться: по нему написано много обучающих материалов (например).



  • Инструмент для развертывания виртуальных роутеров в Docker'е
  • Поддерживает: Cisco XRv, Juniper vMX, Arista vEOS, Nokia VSR и др.
  • Open Source

Очень интересный, но малоизвестный инструмент. В нашем случае с его помощью мы запустим Juniper vMX и Cisco xRV9000 на обычной Ubuntu 20.04 LTS.
Прочитать подробнее о нем можно на странице проекта.


Часть 2: лабораторная работа


В рамках этого туториала мы будем настраиваить следующую систему:


Как это работает


  • Juniper vMX поднимается в Docker контейнере (средствами Vrnetlab) и функционирует как самый обычный виртуальный роутер.
  • ODL подключен к роутеру и позволяет управлять им.
  • Postman запущен на отдельной машине и через него мы отправляем команды ODL: на подключение/удаление роутера, изменение конфигурации и тп.

Комментарий к устройству системы

Juniper vMX и ODL требуют довольно много ресурсов для своей стабильной работы. Один только vMX просит 6 Gb оперативной памяти и 4 ядра. Поэтому было принято решение вынести всех "тяжеловесов" на отдельную машину (Heulett Packard Enterprise MicroServer ProLiant Gen8, Ubuntu 20.04 LTS). Роутер, конечно, на ней не "летает", но для небольших экспериментов производительности хватает.


Часть 3: настраиваем OpenDaylight



Актуальная версия ODL на момент написания статьи Magnesium SR1
1) Устанавливаем Java OpenJDK 11 (за более подробной установкой сюда)


ubuntu:~$ sudo apt install default-jdk

2) Находим и скачиваем свежую сборку ODL отсюда
3) Разархивируем скачанный архив
4) Переходим в полученную директорию
5) Запускаем ./bin/karaf


На этом шаге ODL должен запуститься и мы окажемся в консоли (Для доступа извне используется порт 8181, чем мы воспользуемся далее).


Далее устанавливаем ODL Features, предназначенные для работы с протоколами NETCONF и RESTCONF. Для этого в консоли ODL выполняем:


opendaylight-user@root> feature:install odl-netconf-topology odl-restconf-all

На этом простейшая настройка ODL завершена. (Более подробно можно прочитать здесь).


Часть 4: настраиваем Vrnetlab



Подготовка системы


Перед установкой Vrnetlab необходимо поставить требуемые для его работы пакеты. Такие как Docker, git, sshpass:


ubuntu:~$ sudo apt updateubuntu:~$ sudo apt -y install python3-bs4 sshpass makeubuntu:~$ sudo apt -y install gitubuntu:~$ sudo apt install -y \    apt-transport-https ca-certificates \    curl gnupg-agent software-properties-commonubuntu:~$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -ubuntu:~$ sudo add-apt-repository \   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \   $(lsb_release -cs) \   stable"ubuntu:~$ sudo apt updateubuntu:~$ sudo apt install -y docker-ce docker-ce-cli containerd.io

Установка Vrnetlab


Для установки Vrnetlab клонируем соответствующий репозиторий с github:


ubuntu:~$ cd ~ubuntu:~$ git clone https://github.com/plajjan/vrnetlab.git

Переходим в директорию vrnetlab:


ubuntu:~$ cd ~/vrnetlab

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


ubuntu:~/vrnetlab$ lsCODE_OF_CONDUCT.md  config-engine-lite        openwrt           vr-bgpCONTRIBUTING.md     csr                       routeros          vr-xconLICENSE             git-lfs-repo.sh           sros              vrnetlab.shMakefile            makefile-install.include  topology-machine  vrpREADME.md           makefile-sanity.include   veos              vsr1000ci-builder-image    makefile.include          vmx               xrvcommon              nxos                      vqfx              xrv9k

Создаем image роутера


Каждый роутер, который поддерживается Vrnetlab, имеет свою уникальную процедуру настройки. В случае Juniper vMX нам достаточно закинуть .tgz архив с роутером (скачать его можно с официального сайта) в директорию vmx и выполнить команду make:


ubuntu:~$ cd ~/vrnetlab/vmxubuntu:~$ # Копируем в эту директорию .tgz архив с роутеромubuntu:~$ sudo make

Сборка образа vMX займет порядка 10-20 минут. Самое время сходить заварить кофе!


Почему же так долго, спросите вы?

Перевод ответа автора на этот вопрос:


"Это связано с тем, что при первом запуске VCP (Control Plane) считывает файл конфигурации, который определяет, будет ли он работать в качестве VRR VCP в vMX. Ранее этот запуск выполнялся во время запуска Docker, но это означало, что VCP всегда перезапускался один раз, прежде чем виртуальный маршрутизатор становился доступным, что приводило к длительному времени загрузки (около 5 минут). Теперь первый запуск VCP выполняется во время сборки образа Docker, и поскольку сборка Docker не может быть запущена с параметром --privileged, это означает, что qemu работает без аппаратного ускорения KVM и, таким образом, сборка занимает очень много времени. Во время этого процесса выводится много логов, так что, по крайней мере, вы сможете увидеть, что происходит. Я думаю, что длительная сборка не так страшна, потому что образ мы создаем один раз, а запускаем множество."


После можно будет увидеть image нашего роутера в Docker:


ubuntu:~$ sudo docker image listREPOSITORY          TAG                 IMAGE ID            CREATED             SIZEvrnetlab/vr-vmx     20.1R1.11           b1b2369b453c        3 weeks ago         4.43GBdebian              stretch             614bb74b620e        7 weeks ago         101MB

Запускаем контейнер vr-vmx


Запускаем командой:


ubuntu:~$ sudo docker run -d --privileged --name jun01 b1b2369b453c

Далее можем посмотреть информацию об активных контейнерах:


ubuntu:~$ sudo docker container listCONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                     PORTS                                                 NAMES120f882c8712        b1b2369b453c        "/launch.py"        2 minutes ago       Up 2 minutes (unhealthy)   22/tcp, 830/tcp, 5000/tcp, 10000-10099/tcp, 161/udp   jun01

Подключаемся к роутеру


IP-адрес сетевого интерфейса роутера можно получить следующей командой:


ubuntu:~$ sudo docker inspect --format '{{.NetworkSettings.IPAddress}}' jun01172.17.0.2

По умолчанию, Vrnetlab создает у роутера пользователя vrnetlab/VR-netlab9. Подключаемся с помощью ssh:


ubuntu:~$ ssh vrnetlab@172.17.0.2The authenticity of host '172.17.0.2 (172.17.0.2)' can't be established.ECDSA key fingerprint is SHA256:g9Sfg/k5qGBTOX96WiCWyoJJO9FxjzXYspRoDPv+C0Y.Are you sure you want to continue connecting (yes/no/[fingerprint])? yesWarning: Permanently added '172.17.0.2' (ECDSA) to the list of known hosts.Password:--- JUNOS 20.1R1.11 Kernel 64-bit  JNPR-11.0-20200219.fb120e7_builvrnetlab> show versionModel: vmxJunos: 20.1R1.11

На этом настройка роутера завершена.
Рекомендации по установке для роутеров различных вендоров можно найти на github проекта в соответствующих директориях.


Часть 5: Postman подключаем роутер к OpenDaylight


Установка Postman


Для установки достаточно скачать приложение отсюда.


Подключение роутера к ODL


Создадим PUT запрос:


  1. Строка запроса:
    PUT http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01
    
  2. Тело запроса (вкладка Body):
    <node xmlns="urn:TBD:params:xml:ns:yang:network-topology"><node-id>jun01</node-id><host xmlns="urn:opendaylight:netconf-node-topology">172.17.0.2</host><port xmlns="urn:opendaylight:netconf-node-topology">22</port><username xmlns="urn:opendaylight:netconf-node-topology">vrnetlab</username><password xmlns="urn:opendaylight:netconf-node-topology">VR-netlab9</password><tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only><schema-cache-directory xmlns="urn:opendaylight:netconf-node-topology">jun01_cache</schema-cache-directory></node>
    
  3. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin. Это необходимо для доступа к ODL:
  4. На вкладке Headers необходимо добавить два заголовка:
    • Accept application/xml
    • Content-Type application/xml

Наш запрос сформирован. Отправляем. Если все было настроено правильно, то нам должен вернуться статус "201 Created":


Что делает этот запрос?

Мы создаем node внутри ODL с параметрами реального роутера, к которому мы хотим получить доступ.


xmlns="urn:TBD:params:xml:ns:yang:network-topology"xmlns="urn:opendaylight:netconf-node-topology"

Это внутренние пространства имен XML (XML namespace) для ODL в соответствии с которыми он создает node.
Далее, соответственно, имя роутера это node-id, адрес роутера host и тд.
Самая интересная строчка последняя. Schema-cache-directory создает директорию, в которую выкачиваются все файлы YANG Schema подключенного роутера. Найти их можно в $ODL_ROOT/cache/jun01_cache.


Проверяем подключение роутера


Создадим GET запрос:


  1. Строка запроса:
    GET http://10.132.1.202:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/
    
  2. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.

Отправляем. Должны получить статус "200 OK" и список всех поддерживаемых устройством YANG Schema:


Комментарий: Чтобы увидеть последнее, в моем случае необходимо было подождать порядка 10 минут после выполнения PUT, пока все YANG sсhema выгрузятся на ODL. До этого момента при выполнении данного GET запроса будет выведено следующее:


Удаляем роутер


Создадим DELETE запрос:


  1. Строка запроса:
    DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01
    
  2. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.

Часть 6: Изменяем конфигурацию роутера


Получаем конфигурацию


Создадим GET запрос:


  1. Строка запроса:
    GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/
    
  2. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.

Отправляем. Должны получить статус "200 OK" и конфигурацию роутера:


Создаем конфигурацию


В качестве примера создадим следующую конфигурацию и поизменяем ее:


protocols {    bgp {        disable;        shutdown;    }}

Создадим POST запрос:


  1. Строка запроса:
    POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols
    
  2. Тело запроса (вкладка Body):
    <bgp xmlns="http://personeltest.ru/away/yang.juniper.net/junos/conf/protocols"><disable/><shutdown></shutdown></bgp>
    
  3. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.
  4. На вкладке Headers необходимо добавить два заголовка:
    • Accept application/xml
    • Content-Type application/xml

После отправки должны получить статус "204 No Content"


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


  1. Строка запроса:
    GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols
    
  2. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.

После выполнения запроса увидим следующее:


Изменяем конфигурацию


Изменим информацию о протоколе BGP. После наших действий она будет выглядеть следующим образом:


protocols {    bgp {        disable;    }}

Создадим PUT запрос:


  1. Строка запроса:
    PUT http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols
    
  2. Тело запроса (вкладка Body):
    <protocols xmlns="http://personeltest.ru/away/yang.juniper.net/junos/conf/protocols"><bgp>    <disable/></bgp></protocols>
    
  3. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.
  4. На вкладке Headers необходимо добавить два заголовка:
    • Accept application/xml
    • Content-Type application/xml

Используя предыдущий GET запрос, видим изменения:


Удаляем конфигурацию


Создадим DELETE запрос:


  1. Строка запроса:
    DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols
    
  2. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.

При вызове GET запроса с информацией о протоколах увидим следующее:


Дополнение:


Для того, чтобы изменить конфигурацию, не обязательно отправлять тело запроса в формате XML. Это можно сделать и в формате JSON.
Для этого, например, в запросе PUT на изменение конфигурации заменим тело запроса на:


{    "junos-conf-protocols:protocols": {        "bgp": {            "description" : "Changed in postman"         }    }}

Не забудьте поменять на вкладке Headers заголовки на:


  • Accept application/json
  • Content-Type application/json

После отправки получим следующий результат (Ответ смотрим используя GET запрос):


Часть 7: добавляем Cisco xRV9000


Что мы все о Джунипере, да о Джунипере? Давайте о Cisco поговорим!
У меня нашелся xRV9000 версии 7.0.2 (зверюга, которому нужны 8Gb RAM и 4 ядра. В свободном доступе не лежит, поэтому обращайтесь в Cisco) его и запустим.


Запуск контейнера


Процесс создания Docker контейнера практически ничем не отличается от Juniper. Аналогично, закидываем .qcow2 файл с роутером в директорию, соответствующую его названию, (в данном случае xrv9k) и выполняем команду make docker-image.
Через несколько минут видим, что образ создался:


ubuntu:~$ sudo docker image lsREPOSITORY          TAG                 IMAGE ID            CREATED             SIZEvrnetlab/vr-xrv9k   7.0.2               54debc7973fc        4 hours ago         1.7GBvrnetlab/vr-vmx     20.1R1.11           b1b2369b453c        4 weeks ago         4.43GBdebian              stretch             614bb74b620e        7 weeks ago         101MB

Производим запуск контейнера:


ubuntu:~$ sudo docker run -d --privileged --name xrv01 54debc7973fc

Через некоторое время смотрим, что контейнер запустился:


ubuntu:~$ sudo docker psCONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                 PORTS                                                      NAMES058c5ecddae3        54debc7973fc        "/launch.py"        4 hours ago         Up 4 hours (healthy)   22/tcp, 830/tcp, 5000-5003/tcp, 10000-10099/tcp, 161/udp   xrv01

Подключаемся по ssh:


ubuntu@ubuntu:~$ ssh vrnetlab@172.17.0.2Password:RP/0/RP0/CPU0:ios#show versionMon Jul  6 12:19:28.036 UTCCisco IOS XR Software, Version 7.0.2Copyright (c) 2013-2020 by Cisco Systems, Inc.Build Information: Built By     : ahoang Built On     : Fri Mar 13 22:27:54 PDT 2020 Built Host   : iox-ucs-029 Workspace    : /auto/srcarchive15/prod/7.0.2/xrv9k/ws Version      : 7.0.2 Location     : /opt/cisco/XR/packages/ Label        : 7.0.2cisco IOS-XRv 9000 () processorSystem uptime is 3 hours 22 minutes

Подключаем роутер к OpenDaylight


Добавление происходит совершенно аналогичным с vMX образом. Нужно только названия поменять.
PUT запрос:


Через некоторое время вызываем GET запрос, чтобы проверить, что все подключилось:


Изменяем конфигурацию


Настроим следующую конфигурацию:


!router ospf LAB mpls ldp auto-config!

Создадим POST запрос:


  1. Строка запроса:
    POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf
    
  2. Тело запроса (вкладка Body):
    {    "processes": {        "process": [            {                "process-name": "LAB",                "default-vrf": {                    "process-scope": {                        "ldp-auto-config": [                            null                        ]                    }                }            }        ]    }}
    
  3. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.
  4. На вкладке Headers необходимо добавить два заголовка:
    • Accept application/json
    • Content-Type application/json

После его выполнения должны получить статус "204 No Content".


Проверим, что у нас получилось.
Для этого создадим GET запрос:


  1. Строка запроса:
    GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf
    
  2. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.

После выполнения должны увидеть следующее:


Для удаления конфигурации используем DELETE:


  1. Строка запроса:
    DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf
    
  2. На вкладке Authorization необходимо выставить параметр Basic Auth и логин/пароль: admin/admin.

Заключение


Итого, как вы могли заметить, процедуры подключения Cisco и Juniper к OpenDaylight не отличаются это открывает довольно широкий простор для творчества. Начиная от управления конфигурациями всех компонентов сети и заканчивая созданием собственных сетевых политик.
В этом туториале я привел простейшие примеры того, как можно взаимодействовать с сетевым оборудованием при помощи OpenDaylight. Без сомнения, запросы из приведенных примеров можно сделать сильно сложнее и настраивать целые сервисы одним кликом мыши все ограничено только вашей фантазией*


Продолжение следует...


P.S.


Если вы вдруг все это уже знаете или, наоборот, прошли и вам запал в душу ODL, то рекомендую посмотреть в сторону разработки приложений на контроллере ODL. Начать можно отсюда.
Успешных экспериментов!


Список литературы


  1. Vrnetlab: Emulate networks using KVM and Docker / Brian Linkletter
  2. OpenDaylight Cookbook / Mathieu Lemay, Alexis de Talhouet, Et al
  3. Network Programmability with YANG / Benot Claise, Loe Clarke, Jan Lindblad
  4. Learning XML, Second Edition / Erik T. Ray
  5. Effective DevOps / Jennifer Davis, Ryn Daniels
Подробнее..

Huawei ADN первая в индустрии сеть с автономным управлением третьего уровня

28.04.2021 16:12:49 | Автор: admin
Что такое автономно управляемая сеть и чем она отличается от SDN? Huawei совместно с консалтинговой компанией IDC изучила критерии оценки сетевой инфраструктуры по уровню её способности поддерживать собственную работу без помощи администратора.



Какой заказчики хотят видеть сетевую инфраструктуру ЦОДа? Она, конечно, должна быть эффективной, надёжной и простой в обслуживании. Совсем чудесно было бы, если бы сеть настраивала и обслуживала себя сама. Современные SDN-контроллеры умеют всё больше, но как оценить уровень их автоматизации? Как классифицировать эту автономность?

Чтобы ответить на эти вопросы, мы обратились в консалтинговую компанию IDC и попросили её провести исследование, по результатам которого можно было бы понять, как охарактеризовать автономность управления той или иной сетью и как оценить эффективность подобного внедрения. Коллеги из IDC откликнулись на наше предложение и пришли к интересным выводам.



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

Между тем не следует рассматривать облако просто как место выполнения рабочих нагрузок. Это ещё и особые подходы к работе, подразумевающие высокий уровень автоматизации. По мнению аналитиков IDC, мы вступаем в эпоху множества инноваций. Компании инвестируют в такие технологии, как искусственный интеллект, интернет вещей, блокчейн и интерфейсы естественного взаимодействия. Но конечная цель это именно автономность систем и инфраструктур. В таком контексте и следует оценивать перспективы развития сетей ЦОД.



На схеме изображён процесс автоматизации сетей, который делится на несколько последовательных этапов. Он начинается с интерфейса командной строки и создания скриптов. На следующем этапе появляются сетевые фабрики, позволяющие повысить скорость и производительность. Далее наступает пора SDN-контроллеров и средств виртуализации. На этом этапе также внедряются инструменты оркестрации и автоматизации сетей ЦОД.

Качественно новым уровнем является переход к сетям, управляемым на основе намерений (intent-based networking). Но целью этого прогресса является создание полностью автономной сети, управляемой искусственным интеллектом. Все участники рынка так или иначе рассматривают эту задачу.

Что же такое автономность сети и как её оценить? Компания IDC предложила шестиуровневую модель, позволяющую точно отнести конкретное решение к тому или иному уровню автономности.

  • Level 0. На этом этапе управление сетью осуществляется только через ручные процессы на протяжении всего жизненного цикла сети. Сеть не является автоматизированной.
  • Level 1. Управление сетью всё ещё преимущественно ручное на протяжении всего жизненного цикла сети.
  • Level 2. В некоторых сценариях появляется частичная автоматизация, которая сочетается со стандартными инструментами анализа и управления политиками.
  • Level 3. Условная автоматизация. Система уже умеет выдавать рекомендации и указания, принимаемые или отклоняемые оператором.
  • Level 4. Сеть в значительной мере автоматизирована и автономна. Управляется она декларативными методами на основе намерений. Оператор лишь получает уведомления о событиях и принимает решения о принятии или отклонении рекомендаций сети.
  • Level 5. Сеть полностью автоматизирована и автономна на протяжении всего жизненного цикла. Она способна самостоятельно применять политики, устранять неисправности и восстанавливать сервисы.




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

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

Исследование IDC показывает, что автономное управление сетью является остроактуальным трендом, в который так или иначе вовлечено до половины всех компаний, занимающихся развитием своей IT-инфраструктуры.



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

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



Вместе с тем инновации в работе с клиентами повлекли за собой повышение сложности IT-инфраструктуры и увеличение частоты вносимых в неё изменений. До 50% сложных проблем, регистрируемых сейчас в ЦОДах, в той или иной мере обусловлены ограниченностью как самих сетевых ресурсов, так и ресурсов команды администраторов.

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

Пожалуй, это объясняет следующую цифру: до 40% сложных проблем в ЦОДах вызваны человеческими ошибками. Любые изменения в сети, как то: запуски новых приложений, развёртывание сервисов и т. д., требуют большого внимания и многочисленных проверок, на которые далеко не всегда хватает рабочего времени. Итогом может стать серьёзная авария в ЦОДе.

А сколько времени тратится на разрешение той или иной проблемы? Наши данные говорят о том, что в среднем для одного только обнаружения неисправности требуется почти 80 минут. И неисправности эти далеко не всегда связаны с физическими устройствами. Они могут происходить на уровне протоколов, доступности сервисов и пр.

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



Вернёмся к классификации уровней автономности, предложенной IDC. Перед вами перечень возможностей, которые сеть должна демонстрировать на каждом из этих уровней. Решение Huawei Autonomous Driving Network отвечает всем требованиям третьего уровня. Она умеет в полностью автоматическом режиме поддерживать свою работу, включая запуск и остановку процессов, настройку оборудования и пр. Кроме того, наша ADN в полной мере соответствует критерию осведомлённости, в реальном времени получая информацию о состоянии устройств, процессов, приложений и сервисов.

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

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

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



Каким же будет эффект от внедрения автономного управления сетью? Начнём с проектирования сети. В случае использования Huawei Autonomous Driving Network заказчику нет необходимости вручную создавать архитектуру или дизайн, а также настраивать устройства. Система лишь просит указать, какое количество устройств и линков определенной пропускной способности должно быть задействовано. Затем она автоматически собирает сетевую инфраструктуру и предлагает её в виде готового решения. Заказчик сразу же получает полностью работоспособную фабрику дата-центра.

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

В процессе эксплуатации ADN постоянно проверяет прохождение трафика, среди прочего выявляя и взаимное влияние различных сервисов друг на друга. Это позволяет в реальном времени повышать качество функционирования сети, ликвидируя возникающие узкие места.

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

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



Сила Huawei Autonomous Driving Network в том, что это не просто программное обеспечение, которое можно проинсталлировать и получать сервис. В системе реализована трёхуровневая модель, базовый уровень которой расположен уже на уровне процессоров конечных устройств коммутации и маршрутизации. Эти программно-аппаратные элементы выполняют задачи по сбору и анализу данных, а также коммутации потоков и кадров. Оснащённый таким процессором коммутатор в режиме реального времени передаёт информацию в направлении программной платформы, в качестве которой в нашем случае выступает iMaster NCE.

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

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

Подходы, использованные при создании ADN, позволяют в очередной раз вспомнить наш принцип 1-3-5: любая проблема в сети должна быть выявлена за одну минуту, локализована за три минуты и исправлена за пять минут.



Подведём итог. Конечно, ADN является преемницей решений, заложенных в SDN. Это был необходимый этап развития технологии, но в нём крылись некоторые недостатки. Во-первых, использование программно-определяемых сетей подразумевало ручную первичную настройку устройств. Во-вторых, выявление ошибок также ложилось на плечи специалистов по поддержке сети. В-третьих, в случае с SDN, конечно, не шла речь об автоматическом применении сценариев восстановления, полученных из облачной базы знаний. Создавая своё ADN-решение, Huawei стремилась к тому, чтобы наши клиенты освободились от этих задач, сосредоточившись на том, что действительно требует внимания.
Подробнее..

VMware SD-WAN обзор решения

03.04.2021 18:14:06 | Автор: admin

Этим материалом мы начинаем цикл статей о решении VMware SD-WAN. Сегодня поговорим о том, какие рыночные предпосылки сформировали его появление, какие задачи решает SD-WAN и каковы технические особенности решения VMware.

Появление SD-WAN

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

Чуть позже компании, наконец, распробовали облачные технологии. Бизнес стал размещать свои приложения в облаках, а доступ к ним организовывать через интернет, без использования выделенных каналов. Требования к пропускной полосе и скорости обмена информацией постоянно росли. Если со старыми корпоративными приложениями, не относящимися к медиа или ПО реального времени, традиционный подход еще работал, то по мере появления видеохостингов и сервисов видеосвязи, взрывной рост популярности которых пришелся на начало 2010-х, стало очевидно: нужно что-то менять.

Выделенные MPLS-каналы со своей низкой пропускной способностью и высокой стоимостью (за 1 Мбит на MPLS приходилось платить иногда в десятки раз больше, чем за такой же канал в интернет) банально перестали отвечать требованиям рынка.

Казалось бы, почему не перейти на интернет? Это дешево и сердито, а скорость доступа к облакам выше. Ответ прост: в случае с интернетом невозможно гарантировать качество сервиса. Да, MPLS дорогой и неудобный, но провайдеры как минимум на уровне контракта гарантируют качество. А в случае с интернетом обещать, что приложения, физически находящиеся бог знает где, через конкретного провайдера будут хорошо работать, нельзя. Сами сервисы находятся вне зоны ответственности провайдера.

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

Решения SD-WAN долгое время оставались уделом стартапов. В стадию зрелости технология перешла всего несколько лет назад, когда крупные компании начали активно приобретать специализированные проекты. VMware выкупила стартап Velocloud, который делил первое место на рынке с аналогичным проектом Viptela, примерно в то же время купленным Cisco. Еще пару лет заняла консолидация: одни стартапы разорялись не всем удавалось сохранить нужные темпы роста и найти свое место на рынке, наиболее перспективные и успешные переходили под крыло крупных вендоров.

Чтобы нарастить конкурентные преимущества, каждой компании пришлось найти собственную уникальную нишу. Решение Velocloud создавалось для того, чтобы бизнес мог получать надежный и качественный доступ к приложениям независимо от того, где они находятся: в локальном дата-центре или в облаке, доступ в которое осуществляется через интернет. Спойлер: реализовать это удалось благодаря архитектурному компоненту решения SD-WAN Cloud Gateways. Идея состоит в том, что облачные технологии можно использовать и в мире сетевых подключений.

Как работает SD-WAN

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

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

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

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

Далее мы подробно рассмотрим все компоненты VMware SD-WAN и поговорим о каждом из них отдельно.

Компоненты решения

VMware SD-WAN Orchestrator

SD-WAN Orchestrator это облачный портал управления, мониторинга и диагностики сети. С его помощью можно буквально в один клик запустить виртуальные сетевые службы в филиале, облаке или в корпоративном ЦОДе. Фактически, это веб-портал управления сетью SD-WAN, который можно получить как SaaS или развернуть в локальном ЦОД.

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

  • Мониторинг. Данные о состоянии узлов сети, SLA по каналам, сетевая активность по приложениям и клиентам, а также продвинутая система построения отчетов

  • Zero-Touch Provisioning (ZTP). Активация оконечного устройства в филиале не требует выезда отдельного специалиста на площадку. Весь процесс укладывается в несколько простых шагов. Сотрудник в удаленном офисе подключает к устройству все кабели и включает его. Через интерфейс оркестратора создается новый Edge и высылается email со ссылкой для активации. Там зашиты нужные параметры для настройки WAN-интерфейса оборудования. Сотрудник в филиале, подключившись через провод или WiFi с планшета, переходит по этой ссылке, а устройство получает автоматически связность с оркестратором, вне зависимости от типа подключения к интернету.

  • Диагностика сети. В панели управления можно посмотреть состояние протоколов маршрутизации, портов, таблиц ARP и NAT, запустить Ping или Traceroute и многое другое без необходимости подключения к устройствам через CLI/SSH.

  • Журнал событий. Изменения и уведомления со всех устройств доступны для поиска и просмотра на SD-WAN Orchestrator.

  • Автоматизация через API. SD-WAN Orchestrator предоставляет REST API, примеры использования можно посмотреть на SD-WAN Dev Center.

Посмотрим, как это выглядит.

SD-WAN Dashboard общий вид на всю сеть:

Список филиалов и их расположение на карте:

Статистика по приложениям и клиентам:

Информация о качестве каналов Quality of Experience:

Детальные характеристики каналов:

VMware SD-WAN Gateway

SD-WAN Gateways это сетевые шлюзы, развернутые в высоконадежных ЦОД по всему миру. В первую очередь, они выполняют функцию Control Plane, но в зависимости от задачи могут брать на себя сразу обе плоскости и control plane, и data plane. Эти шлюзы позволяют соединить между собой разрозненные офисы и обеспечивают оптимальный путь от филиала к данным и приложениям в ЦОД и облаках. Потребность в установке мощных концентраторов или устройств координации непосредственно в филиалах отпадает.

На уровне Control Plane обеспечивается и обмен маршрутной информацией между филиалами, так как Gateway выполняет роль рефлектора маршрутов. Филиалы получают обновления маршрутов от Control Plane, благодаря чему настраивать протоколы маршрутизации между устройствами Edge не требуется.

Ещё одна важная роль SD-WAN Gateway помощь в определении характеристик каналов связи. При активации устройства Edge выполняется подключение к Gateway и замер полосы пропускания канала, также автоматически определяется MTU.

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

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

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

Хороший пример использование облачных сервисов совместной работы, например, Microsoft Office 365, Dropbox, Zoom, Skype for business и других. В месте их фактического расположения установить SD-WAN Edge невозможно,но получить преимущества SD-WAN Overlay (подробнее в разделе о протоколе VCMP) нужно. SD-WAN Gateway выполняет функцию шлюза в большой интернет с балансировкой между каналами, компенсацией ошибок и выбором наиболее оптимального канала для передачи пакетов конкретного приложения.

VMware SD-WAN Edges

VMware SD-WAN Edge это физическое или виртуальное устройство с функциями безопасности. Фактически, это маршрутизатор, который может как заменить уже размещенные в филиалах устройства, так и работать с ними в тандеме. Он поддерживает функции сетевого шлюза, Site-to-Site VPN, DHCP-сервера, NAT и файрвола, а также различные протоколы маршрутизации для интеграции с физической сетью.

SD-WAN Edge в виртуальном исполнении подойдет тем, кто планирует использовать концепцию Software-Defined Branch или обеспечивать доступ к своим приложениям в ЦОД через SD-WAN. Виртуальный Edge в ЦОД подходит как в качестве связующего звена ресурсов ЦОД и удаленных площадок, так и в роли хаба для агрегации и распределения трафика внутри сети SD-WAN.

SD-WAN Edge поддерживает основные варианты резервирования есть возможность объединения в отказоустойчивую пару или подключение по протоколу VRRP.

И если компоненты решения руки, ноги и голова технологии VMware SD-WAN, то его сердце технология DMPO. Именно она и позволяет реализовать уникальные фишки по обработке сетевых пакетов при передаче данных (между филиалами и ЦОД, филиалами и облаками) и обеспечивает высокое качество связи. Поговорим о ней подробнее.

Технология DMPO

Технология DMPO (Dynamic Multi-Path Optimization) позволяет нам за счет гибкого управления трафиком на уровне приложений агрегировать потоки и обеспечивать высокое качество связи. DMPO работает на уровне отдельных пакетов, однако учитывает, к каким приложениям эти пакеты относятся. Транзакционным приложениям, таким как веб-сайты, инструменты передачи файлов, не принципиально, придет пакет вовремя или чуть позже, главное, чтобы он вообще дошел. А приложениям реального времени (стриминговые сервисы, приложения для голосовых вызовов и т.п.) очередность пакетов важна. Из-за мелких неполадок может рассыпаться картинка на экране или собеседник не расслышит слово. Поэтому важно, чтобы SD-WAN устройства понимали, что это за приложение. В этом помогает движок распознавания приложений (Deep Application Recognition), работающий на каждом устройстве SD-WAN Edge.

Приложений существует огромное множество, 3000+ из них есть во встроенной базе DPI VMware SD-WAN. Кроме того, можно добавить и кастомные (самописные) сигнатуры, если вдруг какого-то приложения не хватает. Посмотрим, какие функции выполняет DMPO.

Непрерывный мониторинг качества каналов

Для мониторинга состояния WAN-каналов в реальном времени стандартные сетевые технологии вроде BFD или ICMP Probes не совсем подходят, т.к. тестовые пакеты отличаются от пользовательского трафика (другие классы DSCP, другой размер пакетов), а интервал проб слишком высок, чтобы достоверно и быстро определить ухудшение качества. Например, даже при замерах BFD или ICMP каждую секунду за время между этими замерами у обычного пользователя с ноутбуком передается 200+ пакетов (проверьте сами, сняв дамп трафика). Чтобы зафиксировать уровень потери в 2%, потребуется не менее 50 BFD пакетов (50 с). Если использовать более агрессивные значения, например, 100 мс, все равно потребуется не менее 5 секунд, чтобы обнаружить потери в 2% на канале. За это время тысячи пакетов с пользовательскими данными могут быть потеряны.

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

За точное время в сети отвечает Control Plane уже известные нам SD-WAN Gateways. Устройства SD-WAN Edge синхронизируют свое время с центром управления сетью. Таким образом можно гарантировать, что все временные метки будут достоверны. В стандартных сетевых протоколах такие возможности отсутствуют.

Состояние каналов отслеживается даже в том случае, если пользовательского трафика на данный момент нет. Ведь когда этот трафик появится, его нужно сразу же отправить по оптимальному пути. Для этого устройства SD-WAN Edge обмениваются служебными пакетами VCMP, только без User Payload, каждые 100 или 500 мс. Как только появляется пользовательский трафик, система снова начинает отслеживать SLA для каждого пакета.

Динамическая балансировка трафика и агрегация каналов

DMPO позволяет определять, какие приложения используют сеть, при помощи политик манипулировать поведением SD-WAN и настраивать приоритеты.

Решение VMware умеет автоматически (за счет работы overlay-протокола VCMP) выбирать наилучший способ обработки и доставки трафика приложений. К примеру, если конкретному приложению требуется ускорить передачу данных, то есть агрегировать несколько каналов, умное SD-WAN устройство начнет передавать данные сразу по нескольким путям. Для балансировки используются все доступные подключения.

В ряде случаев стандартная балансировка не имеет смысла, они сильно отличаются между собой по характеристикам: на одном задержка 5 мс, на другом 100). Соответственно, балансировать трафик между ними бесполезно. Однако если быстрый канал окажется забит под завязку и на нем скопится большая очередь из пакетов, система определит, что каналы сравнялись по времени доставки пакетов. В этом случае в рассылке пакетов будут задействованы оба канала таким образом, чтобы пакеты по обоим доходили до точки назначение в одно и то же время. На принимающей стороне пакеты выстраиваются в порядке очереди так, чтобы клиенту или серверу за пределами сети SD-WAN не приходилось пересобирать их в требуемой последовательности. Соответственно, еще одна из функций, которую способно обеспечить устройство SD-WAN автоматический реордеринг.

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

Из-за особенностей каналов связи трафик между точками А и В может идти неравномерно: в одну сторону с задержкой 10 мс, обратно 20 мс. В то же самое время канал работает наоборот: туда 20 мс, сюда 10 мс задержки. По сети VMware SD-WAN такая сессия будет передаваться по обоим каналам сразу, в одну сторону по каналу с задержкой 10 мс, и так же обратно по каналу с наилучшими характеристиками.

За счет того, что каждый пакет обрабатывается индивидуально алгоритмами DMPO, система выбирает наилучший путь для каждого пакета автоматически, принимая решения в реальном времени.

Раньше администраторам приходилось вручную определять эту логику, либо настраивать схемы вида: каждые N секунд проверяем, какой канал и в какую сторону работает лучше и перестраиваемся при необходимости. Реализовать такую схему без разрывов пользовательских сессий практически невозможно. Ценность SD-WAN заключается в том, что вся эта запутанная логика делегирована алгоритмам они быстрее и точнее, чем даже самые сложные проверочные скрипты. Логика VMware SD-WAN работает на разных типах сессий и на разных транспортных протоколах, никак не нарушая логику работы TCP/IP.

Технологии корректировки ошибок

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

Получатель: Так, к нам идут пакеты. Первый, второй, третий, пятый Стоп. Почему пятый? Требую выслать мне пакет 4 как можно скорее! Прием!

Отправитель: Посмотрим, к какому приложению относился этот ваш пакет. Ага, вот оно! Высылаю компенсацию, подтвердите получение!

В случае транзакционного приложения устройству-отправителю будет достаточно найти в буфере нужный пакет и повторить отправку так работает технология NACK (Negative Acknowledgement). В устройствах SD-WAN используется серверная память гораздо большего объема, чем в обычных маршрутизаторах. Самая младшая модель имеет на борту 4 Гб, на старших 32 Гб и выше. Это позволяет держать буфер данных и по необходимости досылать потерявшиеся пакеты.

С realtime-приложениями ситуация обстоит иначе. Повторно отправлять пакеты не имеет смысла, важно предотвратить потери в будущем. Поэтому устройство-отправитель включает упреждающую коррекцию ошибок (Forward Error Correction, FEC), и каждый пакет начинает передаваться в двух экземплярах. Таким образом повышается вероятность успешной доставки пакетов, а лишние автоматически отбрасываются на принимающей стороне. На практике это позволяет использовать телефонию и видеоконференции на каналах с потерями до 30-40%.

Под капотом у провайдера

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

Разделение зон ответственности

Первая задача, с которой столкнется компания при самостоятельном внедрении построение облачной инфраструктуры SD-WAN: деплой контроллеров, виртуальных машин, выделение ресурсов, администрирование и многое другое. Построение такой инфраструктуры повлечет за собой значительные расходы в виде выделения или покупки дополнительных серверов и ПО, а также обеспечения условий Disaster Recovery. Эти сложности и расходы особенно трудно обосновать при постепенном внедрении SD-WAN. Во-вторых, для построения надежной отказоустойчивой сетевой связности требуется детально проработать целевую схему подключения, определить движение потоков данных, настроить политики безопасности.

Когда вы обращаетесь к провайдеру, все эти задачи ложатся на него. Он обеспечивает инфраструктуру, круглосуточный мониторинг, администрирование сети и защищенных распределенных ЦОД, уровень доступности и выполнение SLA. Провайдер поможет выбрать оптимальное оборудование и даст рекомендации по модернизации сети, чтобы она соответствовала всем требованиям качества и надежности. При этом клиенту остается только запросить доступ к облачному порталу управления сетью и создать учетные записи для администраторов. На любые вопросы по использованию услуги и настройке сервисов SD-WAN поможет ответить круглосуточная русскоязычная техническая поддержка.

Оркестратор и сетевые шлюзы находятся в зоне ответственности провайдера и разворачиваются на его инфраструктуре. Заказчику понадобится только установить на своей стороне Edge. Арендовать его можно прямо у провайдера при необходимости он поможет и с установкой.

Распределенная инфраструктура провайдера

Общая инфраструктура ИТ-ГРАД и #CloudMTS насчитывает 10 ЦОД в СНГ и множество точек присутствия по всему миру. Где бы ни находился филиал, он будет подключен к ближайшему SD-WAN Gateway, что позволит минимизировать задержки и оптимизировать доступ к любым приложениям в локальных ЦОД и любых облаках. Наличие распределенной инфраструктуры также позволяет обеспечивать георезервирование для сети SD-WAN любого масштаба.

Инфраструктура ИТ-ГРАД и #CloudMTS на территории РФ

В каждом ЦОД резервируются каналы, обеспечивается высокопроизводительная связность шлюзов SD-WAN с внешним миром. Дата-центры подключены к глобальной опорно-магистральной сети МТС, которая обеспечивает доступ к мировым публичным точкам обмена трафиком DE-CIX (Франкфурт), AMS-IX (Амстердам), HK-IX (Гонконг), LINX (Лондон), Equinix, NY-IX и т.д.

Кроме того, в распоряжении наших заказчиков:

  • PNI (Private Network Interconnect) с гиперскейлерами и крупными генераторами трафика. Среди них Amazon AWS, Microsoft, Google Cloud, Apple, Facebook, Valve, Twitch, Netflix, Twitter и прочие.

  • CDN-сети: Akamai, Google Cash и Google CDN, Cloudflare, Gcore labs, Microsoft и прочие.

Интеграция с IaaS и другими сервисами

Использование SD-WAN позволяет получить надежный доступ к сервисам, расположенными в инфраструктуре облачного провайдера. Какие преимущества это дает:

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

  • Резервное копирование SD-WAN позволяет наладить максимально быструю и надежную транспортировку бэкапов по сети (с агрегацией каналов и обеспечением отказоустойчивости) по всем доступным каналам до облака.

  • S3 хранилище, облачный диск при использовании сервисов блочного, объектного и файлового хранилищ подключение по SD-WAN позволяет передавать большие файлы на максимальных скоростях. Это достигается за счет отсутствия ретрансмитов при передаче данных и агрегирования каналов связи, подключенных к устройству SD-WAN.

  • GPU Super Cloud высокоскоростная передача больших объемов данных для обработки в облачной среде.

Все чаще наши клиенты для подключения своих офисов к виртуальным дата-центрам ИТ-ГРАД и #CloudMTS вместо выделенных каналов выбирают SD-WAN и интернет-каналы. Клиенты, уже использующие выделенные каналы, применяют SD-WAN для агрегации существующих каналов, многократно повышая производительность и надежность подключения к облаку.

Будем рады пообщаться с вами в комментариях! В следующей статье мы проведем тестирование сервиса и на практике посмотрим, какие преимущества дают технология DMPO и протокол VCMP.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru