Меню

Что такое svi как настроить svi

Создание отказоустойчивой ИТ инфраструктуры. Часть 4. Внедрение коммутаторов Cisco 3850 для межсетевой маршрутизации

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

Вводная часть

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

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

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

Чтобы не быть голословным, можно просто привести пример из реального практического опыта.
Один виртуальный маршрутизатор на базе VyOS с 2 vCPU и 1 Gb vRAM, вполне справлялся с трафиком от 20 (двадцати) железных хостов, на которых работало примерно 220 виртуальных машин.
Этот маршрутизатор обслуживал:

  • межсетевой трафик от 5 внутренних сетей;
  • основной канал в Интернет 500 Мбит/сек;
  • приватную линию 200 Мбит/сек, для связи с главным офисом и складами.

BGP full view в этой схеме оказался не нужен, но если добавить ещё памяти и процессоров для VyOS, то он и его смог бы «пережевать».

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

В любом случае, была проанализирована причина такого поведения:

  • рост числа хостов с 10 до 20;
  • увеличение числа ВМ с

220;

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

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

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

    Сеть нашего датацентра с самого начала проектировалась под следующие условия и оборудование:

    • два коммутатора Cisco 2960RX;
    • два физических хоста с

    20-30 ВМ;

  • две внутренние сети, которые необходимо выпустить в Интернет;
  • внутренняя сеть для управления всеми сетевыми устройствами.
  • Исходя из этих данных, было принято решение о создании сетевой инфраструктуры с двумя виртуальными маршрутизаторами VyOS, на которые была возложена дополнительная задача по маршрутизации трафика между внутренними сетями. До заказчика было доведено, что это не совсем правильная схема, и, хотя до поры до времени такая сетевая инфраструктура вполне будет удовлетворять требованиям по пропускной способности, но при условии дальнейшего роста проекта, придётся решать вопрос с организацией внутренней маршрутизации на специализированном оборудовании.

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

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

    Время шло, наш виртуальный датацентр постепенно расширялся – увеличивались объёмы прокачиваемого трафика между внутренними сетями через виртуальные маршрутизаторы и также постепенно на них росла постоянная утилизация vCPU. Поэтому было принято решение всё-таки задействовать коммутаторы Cisco 3850 по их прямому предназначению – для маршрутизации внутреннего трафика. Тем более, что в дальнейшем была запланирована модернизация сети нашего датацентра с 1 Гбит/с до 10 Гбит/с и коммутаторы Cisco 3850 в этот план тоже прекрасно вписались, благодаря неплохой пропускной способности стека на уровне 480 Гбит/с, наличию 10 Гбит/с портов, и другого не менее полезного функционала.

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

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

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

    • Схема сети с межсетевой маршрутизацией на Cisco 3850
    • Подготовительные работы
    • Установка и настройка стека коммутаторов Cisco 3850
    • Подключение стека коммутаторов Cisco 2960RХ к стеку Cisco 3850
    • Принципы настройки маршрутизации между внутренними и внешними сетями
    • Организация маршрутизации между внутренними и внешними сетями с использованием PBR
    • Перевод внутренней межсетевой маршрутизации с VyOS’ов на стек Cisco 3850
    • Организация маршрутизации между внутренними и внешними сетями с использованием OSPF

    Схема сети с межсетевой маршрутизацией на Cisco 3850

    Вариант 1
    Схема сети с использованием source-based маршрутизации на основе PBR

    Представленная схема немного видоизменена по сравнению со схемой сети из предыдущей статьи – на ней добавлен логический коммутатор L3, две новые внутренние сети VLAN34 и VLAN35, а также с целью экономии места на схеме, урезан условный Интернет до одной сети – 172.16.3.0/24.

    В составе тестового стенда будут использованы следующие сети:

    • VLAN17 – сеть 172.20.1.0/24, приватные адреса для хостов в датацентре (IPMI, management)
    • VLAN30 – сеть 172.16.1.0/24, «публичная» сеть, связь между VyOS1, VyOS2 и Provider-1
    • VLAN31 – сеть 172.16.2.0/24, «публичная» сеть, связь между VyOS2, VyOS1 и Provider-2
    • VLAN32 – сеть 172.20.32.0/23, приватные адреса для хостов в датацентре – PROD
    • VLAN34 – сеть 172.20.34.0/24, приватные адреса для хостов в датацентре – DEV
    • VLAN35 – сеть 172.20.35.0/24, приватные адреса для хостов в датацентре – DMZ
    • VLAN36 – сеть 172.16.10.8/30, «публичная» P2P сеть, связь между роутерами Provider-1 и Provider-3
    • VLAN37 – сеть 172.16.10.12/30, «публичная» P2P сеть, связь между роутерами Provider-2 и Provider-3
    • VLAN38 – сеть 172.16.3.0/24, «публичная» сеть для внешних хостов, эмуляция Интернет
    • VLAN40 – сеть 172.20.40.0/23, приватные адреса для хостов в датацентре – TEST

    Вариант 2
    Схема сети с использованием destination-based маршрутизации на основе протокола OSPF

    На этой схеме добавлен логический коммутатор L3, две новые внутренние сети VLAN34 и VLAN35 для клиентов, и внутренняя сеть VLAN33 для связи между роутерами VyOS и стеком коммутаторов L3. Также из целей экономии места на схеме, урезан условный Интернет до одной сети – 172.16.3.0/24.

    В составе тестового стенда будут использованы следующие сети:

    • VLAN17 – сеть 172.20.1.0/24, приватные адреса для хостов в датацентре (IPMI, management)
    • VLAN30 – сеть 172.16.1.0/24, «публичная» сеть, связь между VyOS1, VyOS2 и Provider-1
    • VLAN31 – сеть 172.16.2.0/24, «публичная» сеть, связь между VyOS2, VyOS1 и Provider-2
    • VLAN32 – сеть 172.20.32.0/23, приватные адреса для хостов в датацентре – PROD
    • VLAN33 – сеть 172.20.133.0/24, приватные адреса для связи между VyOS2, VyOS1 и 3850
    • VLAN34 – сеть 172.20.34.0/24, приватные адреса для хостов в датацентре – DEV
    • VLAN35 – сеть 172.20.35.0/24, приватные адреса для хостов в датацентре – DMZ
    • VLAN36 – сеть 172.16.10.8/30, «публичная» P2P сеть, связь между роутерами Provider-1 и Provider-3
    • VLAN37 – сеть 172.16.10.12/30, «публичная» P2P сеть, связь между роутерами Provider-2 и Provider-3
    • VLAN38 – сеть 172.16.3.0/24, «публичная» сеть для внешних хостов, эмуляция Интернет
    • VLAN40 – сеть 172.20.40.0/23, приватные адреса для хостов в датацентре – TEST-

    Подготовительные работы

    Для тестирования межсетевого взаимодействия, на кластере oVirt понадобится создать три новые логические сети – VLAN33, VLAN34, VLAN35, а также виртуальные машины с CentOS 7 x86/64 1810 Minimal (можно более свежую):

    1. test-IM34 – 1 Gb RAM, 1 CPU, 10 Gb HDD
      • VLAN34, IP – 172.20.34.239/24, Gateway – 172.20.34.1
    2. test-IM35 – 1 Gb RAM, 1 CPU, 10 Gb HDD
      • VLAN35, IP – 172.20.35.239/24, Gateway – 172.20.35.1

    После подключения этих двух ВМ к соответствующим логическим сетям, устанавливаем на них ОС, и настраиваем IP адреса и шлюзы.

    На маршрутизаторах VyOS должны быть добавлены новые сетевые интерфейсы для работы с VLAN34 и VLAN35, а также настроен vrrp и HAIP для этих новых сетей.

    Установка и настройка стека коммутаторов Cisco 3850

    Основной интерес на схеме выше, для нас представляет Cisco 3850, который является логическим устройством, состоящим из двух физических коммутаторов – WS-C3850-24T-E, 24 x 1 GE, 350 W no PoE, 4 x 1 GE, 2 x 10 GE, соединённых:

    • посредством двух кабелей STACK-T1-50CM= в кольцо StackWise, с общей пропускной способностью стека в 480 Гбит/сек,
    • посредством двух кабелей CAB-SPWR-30CM= в кольцо StackPower, в котором мощность всех четырёх БП может или суммироваться для создания одного виртуального блока питания и разделения общей нагрузки, или же резервируется мощность одного из БП, для увеличения отказоустойчивости.

    Последовательность действий по начальной установке и настройке стека коммутаторов Cisco 3850

    1) Монтаж коммутаторов в стойку, коммутация между собой для создания стека.

    Как установить коммутаторы в стойку, подключить к ним питание и соединить между собой специальными кабелями для создания стека посредством StackWise и StackPower, подробно и наглядно описано в официальной документации – Catalyst 3850 Switch Getting Started Guide.

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

    • использование (желательное) в стеке одинаковых моделей коммутаторов;
    • использование одинаковых версий ПО и лицензий на коммутаторах.

    Также для того, чтобы задействовать для стека полнофункциональные сервисы на уровне L3, необходимо иметь определённый тип лицензии. В нашем случае будет использоваться PBR (policy based routing), поэтому на оба коммутатора была заранее установлена постоянная лицензия типа IP Services.

    • LAN Base
      Функции коммутации второго уровня;
      Статическая маршрутизация;
      Базовая поддержка средств безопасности: порт ACL, 802.1x, DHCP snooping, DAI, IPSG;
      Базовая поддержка качества обслуживания: Ingress policing, AutoQoS, Trust Boundary, DSCP mapping.
    • IP Base
      Все функции коммутации второго уровня;
      Статическая маршрутизация;
      Полная поддержка средств безопасности;
      Полная поддержка качества обслуживания;
      Mobility controller и Flexible NetFlow (доступно для 3650/3850);
      StackPower и EEM.
    • IP Services
      Все функции коммутации второго уровня;
      Динамическая и статическая маршрутизация (PBR, EIGRP, OSPF, BGP, VRF-lite и т.д.);
      Полная поддержка средств безопасности;
      Полная поддержка качества обслуживания;
      Mobility controller и Flexible NetFlow (доступно для 3650/3850);
      StackPower, EEM, IPSLA.

    2) Подключение к коммутатору 3850 через консольный порт и выполнение начальной настройки.

    Вся информация по приводимым в статье настройкам, командам и их функциям, доступна в основных справочных руководствах:

    Подключиться к консольному порту коммутатора можно через специальные USB или RJ-45 порты, настройки программы для эмуляции терминала должны быть такими: 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control.
    Если ПК администратора работает под Windows, то для эмуляции терминала можно использовать Putty, если под Linux, то minicom.

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

    На этом создание стека коммутаторов Cisco 3850 и его начальная настройка выполнены.

    Подключение стека коммутаторов Cisco 2960RХ к стеку Cisco 3850

    Чтобы обеспечить связность на уровне L2 между стеком коммутаторов Cisco 2960RХ и стеком Cisco 3850, подключаем их друг к другу патч-кордами нужной длины, и далее настраиваем Etherchannel:

    2960X Gi1/0/42 3850-stack Gi1/0/21
    2960X Gi2/0/42 3850-stack Gi1/0/23
    2960X Gi1/0/44 3850-stack Gi2/0/21
    2960X Gi2/0/44 3850-stack Gi2/0/23

    Если имеются какие-то проблемы, то обязательно смотрим логи на обоих коммутаторах:

    После того, как поднимется Etherchanel между коммутаторами, к Cisco 3850 можно будет подключиться, например, с любого маршрутизатора VyOS на IP адрес 172.20.1.2 по ssh.

    Принципы настройки маршрутизации между внутренними и внешними сетями

    Для настройки маршрутизации между внутренними и внешними сетями, у нас имеется как минимум два варианта.

    Вариант 1

    Реализуется с помощью destination-based маршрутизации, т.е. решение о том, куда трафик будет направлен, принимается на основании имеющихся маршрутов в таблице маршрутизации коммутатора 3-го уровня. В таблицу маршрутизации данные маршруты (или маршрут по умолчанию) могут попадать или из статически настроенных маршрутов, или из динамических протоколов маршрутизации.

    Для его внедрения придётся переделывать внутреннюю маршрутизацию на роутерах VyOS:

    • убирать интерфейсы к внутренним сетям,
    • настраивать связь между VyOS и внутренними сетями, или с помощью протокола динамической маршрутизации, или используя статический маршрут к ним через Cisco 3850.

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

    Вариант 2

    Реализация происходит с помощью source-based маршрутизации, т.е. решение о том, куда трафик будет направлен, принимается в первую очередь на основании информации об источнике трафика, а далее уже определяется пункт назначения, куда конкретно этот трафик направляется. Здесь на VyOS практически ничего менять не надо, а вся внутренняя маршрутизация будет происходить на стеке Cisco 3850 с помощью PBR (policy based routing). Помимо относительной простоты реализации, этот вариант позволит исключить полный отказ стека Cisco 3850, когда трафик между внутренними сетями может быть переброшен обратно на роутеры VyOS.

    Организация маршрутизации между внутренними и внешними сетями с использованием PBR (policy based routing)

    Ссылки на справочную документацию:

    Если мы сейчас подключим хосты к вышеуказанным сетям, и назначим у них шлюзами соответствующие адреса SVI, то между хостами в разных сетях сразу же пойдёт трафик. Но из этих сетей нам также нужно выходить в Интернет и подключаться к внешним сетям, что мы и реализуем далее с помощью PBR (policy-based routing).

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

    • перенести обработку внутреннего межсетевого трафика на стек 3850, не переделывая схему работы роутеров VyOS с внутренними сетями;
    • в случае полного отказа стека 3850 возможно перенести обработку внутреннего межсетевого трафика обратно на роутеры VyOS, изменив для этого только их HAIP адреса для vrrp.

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

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

    Если после прочтения этого disclaimer’а вас всё устраивает, то переходим к реализации межсетевой маршрутизации между внутренними и внешними сетями, настраиваемого с помощью PBR на стеке 3850. Если не устраивает, то можно перейти в конец статьи, к примечанию, и далее настраивать классический вариант маршрутизации с использованием протокола OSPF.

    Как видно, из списка доступа Access_to_External, были исключены внутренние сети:

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

    Не забываем, что мы ранее создали пять тестовых ВМ, подключенных ко всем пяти внутренним сетям, и поэтому на них рекомендуется изменить шлюзы по умолчанию на адреса SVI на Cisco 3850, и протестировать прохождение трафика как между самими ВМ, так и выход трафика наружу.

    При желании, можно также настроить списки доступа на Cisco 3850, для ограничения прохождения трафика между внутренними сетями, но нужно иметь в виду, что существуют определённые ограничения для количества записей в списках ACL, PBR, QoS и др., которые можно увидеть из следующего вывода:

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

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

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

    Перевод внутренней межсетевой маршрутизации с VyOS’ов на стек Cisco 3850

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

    Если в сети имеется большое количество ВМ и хостов, то как вариант, можно массово изменить на них адреса шлюзов по умолчанию, используя, например, Ansible, или даже исполняя команды на хостах и ВМ удалённо через ssh.

    Но наиболее простым и быстрым способом, является изменение IP адресов на SVI коммутатора Сisco 3850 и HAIP адресов, привязанных к внутренним интерфейсам на роутерах VyOS.

    Для перехода на межсетевую маршрутизацию через Сisco 3850, без изменения адресов шлюзов на хостах и ВМ, нужно просто поочередно перенести IP адреса шлюзов сетей VLAN 17, 32, 34, 35, 40 (или 172.20.1.1, 172.20.32.1, 172.20.34.1, 172.20.35.1, 172.20.40.1) с роутеров VyOS на Сisco 3850.
    Соответственно, адреса 172.20.1.2, 172.20.32.2, 172.20.34.2, 172.20.35.2, 172.20.40.2 с Сisco 3850 должны быть перенесены на роутеры VyOS.

    Как это делается, можно увидеть на примере одной сети – 172.20.1.0/24, или VLAN 17, для этого необходимо лишь последовательно выполнить определённый набор команд на устройствах.

    Итак, выполняем перевод IP адреса шлюза 172.20.1.1 с VyOS на Сisco 3850, сеть VLAN17.

    При определенной сноровке, за время выполнения этих трёх действий, пропадёт не более 10-15 пингов с хоста в сети VLAN 17, до шлюза по умолчанию 172.20.1.1, который теперь будет работать на Сisco 3850.

    Ровно таким же способом переводим остальные адреса – 172.20.32.2, 172.20.34.2, 172.20.35.2 и 172.20.40.2 с Сisco 3850, на роутеры VyOS. В итоге, получаем обновлённую сетевую схему, в которой вся маршрутизация между внутренними сетями, происходит на специализированном устройстве – Сisco 3850. При этом, как мы видим, практически никаких глобальных изменений в сетевой схеме не произошло – кроме добавления Сisco 3850, на роутерах VyOS изменения делаются минимальные, на хостах и виртуальных машинах вообще ничего не надо делать. Сам переход на обновлённую сетевую схему внутренней маршрутизации, занимает пару-тройку минут, и самое главное, практически без простоя.

    Одним из явных преимуществ именно такой схемы с интеграцией стека Сisco 3850 в сетевую инфраструктуру, является то, что при его фатальном отказе, можно всегда перевести внутреннюю маршрутизацию обратно на роутеры VyOS, всего лишь выполнив пару команд на них, как в этом примере для сети 172.20.1.0/24 или VLAN 17:

    В результате, адреса шлюзов по умолчанию переносятся обратно на роутеры VyOS, внутренние сети в датацентре продолжают работать, а мы спокойно и не спеша разбираемся с отказом Сisco 3850.

    Заключение

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

    Например, для этого проекта можно было бы приобрести 4 лицензии (на процессор) для Vmware vSphere Enterprise Plus, одну лицензию Vcenter Server Standard, и 4 лицензии (на процессор) для резервного копирования и репликации виртуальной инфраструктуры – Veeam B&R Enterprise. В связке с оборудованием, у нас получилась бы весьма неплохая, функциональная, гибкая и надёжная платформа виртуализации, но при этом дополнительные затраты без учёта стоимости оборудования, составили бы примерно 44.000 USD за VMware и 10.000 USD за Veeam (цены указаны вместе со стоимостью стандартной годовой поддержки).

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

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

    Что касается дальнейшей судьбы проекта по созданию отказоустойчивой IT инфраструктуры, в части относящейся к кластеру oVirt, то у нас имеется как минимум два варианта по организации работы с ним:

    • классический – это когда администратор по заявке выделяет требуемые ресурсы на кластере виртуализации, создаёт виртуальные машины, устанавливает на них системное ПО и производит их настройки в соответствии с определёнными требованиями;
    • применение к проекту практик DevOps, относящихся к IaaС (Infrastructure as a Code) – это описание с помощью кода требуемой инфраструктуры, в виде автоматического создания ВМ для БД, узлов для Docker Swarm, веб-серверов, серверов для хранения логов, аналитики и т.п., с последующей их автоматической настройкой и предоставлением ресурсов для команды.

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

    oVirt/RHEV в полной мере поддерживает IaaС, для чего имеется соответствующий провайдер для Terraform, а также модуль для Ansible.
    Если есть необходимость развёртывания ОС с нуля из установочного образа, например, для его дальнейшего использования в Terraform или Ansible, то можно использовать Cobbler, для автоматизации установки ОС по сети.

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

    Помимо этого, возможно, будет выпущен новый цикл статей с уклоном в сторону DevOps, в части касающейся IaaС, где в качестве базовой платформы будет использоваться отказоустойчивый кластер oVirt и/или VMware vSphere.

    P.S.
    Если имеются какие-то замечания, предложения или уточнения по статьям, то добро пожаловать в комментарии.

    Примечание

    Исходя из обсуждений в комментариях, для тех, кто не хочет / не может использовать PBR на Cisco 3850 для роутинга внутренних сетей наружу (т.н. source-based маршрутизацию), предлагается использовать «классический» вариант настройки роутинга, на основе destination-based маршрутизации.

    Про этот вариант в статье уже упоминалось, но без особых подробностей, и если его будете настраивать, то нужно иметь в виду следующее:

    • для его реализации придётся перенастраивать схему работы VyOS с внутренними сетями;
    • полный отказ стека Cisco 3850 отразится гораздо больнее на работе сети, чем если бы использовался PBR.

    Организация маршрутизации между внутренними и внешними сетями с использованием OSPF

    Настройка Cisco 3850

    Если ранее были сделаны настройки для работы коммутатора с PBR, то:

    • удаляем привязку route-map’ов с интерфейсов: VLAN17, VLAN32, VLAN34, VLAN35, VLAN40
    • удаляем route-map’ы: VLAN17PBR, VLAN32PBR, VLAN34PBR, VLAN35PBR, VLAN40PBR
    • удаляем access-list Access_to_External
    • для взаимодействия с роутерами VyOS по протоколу OSPF, настраиваем новый интерфейс VLAN33, чтобы обеспечить связь внутренних сетей с внешними.

    Настройка маршрутизаторов VyOS

    Если на роутерах ранее были сделаны настройки для работы с Cisco 3850 на котором был настроен PBR, то:

    • удаляем настройку vrrp для всех интерфейсов;
    • удаляем балансировку нагрузки для выхода в Интернет, с сетевых интерфейсов VLAN32, VLAN34, VLAN35, VLAN40;
    • удаляем адреса с интерфейсов: VLAN17, VLAN32, VLAN34, VLAN35, VLAN40;
    • отключаем эти интерфейсы в настройках виртуальной машины через административный портал oVirt;
    • для взаимодействия с Cisco 3850 по протоколу OSPF, настраиваем интерфейс eth0, подключенный к сети с идентификатором VLAN33, чтобы обеспечить связь внутренних сетей с внешними.

    Для проверки результатов работы протокола OSPF, можно использовать эти команды:

    Источник

    Команда svi

    Успешно сдайте бесплатный сертификационный экзамен в Академии «Инфинет» и получите статус сертифицированного инженера Инфинет.

    Содержание

    Описание

    Интерфейс SVI является виртуальным интерфейсом третьего уровня (L3). Может быть назначен группе коммутации для получения доступа к устройству и управления им через данную группу коммутации. Система поддерживает до 5000 виртуальных интерфейсов «sviN« (диапазон от 0 до 4999).

    Интерфейс SVI обладает следующими характеристиками:

    • Может быть назначен какой-либо одной группе коммутации, после чего интерфейс становится частью данной группы коммутации и может участвовать в обмене информацией с другими участниками группы. Любые пакеты, принятые данной группой коммутации в соответствии с ее правилами и адресованные интерфейсу «sviN», а также копии пакетов multicast и broadcast, будут приниматься устройством от имени интерфейса «sviN».
    • На интерфейс может быть назначен один или несколько IP-адресов.
    • Может выступать в качестве родительского интерфейса для VLANинтерфейсов. В этом случае VLANинтерфейс становится частью группы коммутации.
    • Интерфейс SVI и ни один из интерфейсов, использующих его в качестве родительского, не может быть непосредственно включен в какую-либо группу коммутации.
    • Может использоваться для агрегации каналов с помощью интерфейса LAG.
    • Интерфейс SVI считается активным, если он был создан и назначен группе коммутации.

    Для создания интерфейса SVI используется команда:

    Для установления связи между устройством «Инфинет» и другим сетевым устройством по протоколу, использующему пакеты broadcast/multicast (например, OSPF, RIP, DHCP и т.д.), следует воспользоваться одним из двух вариантов настройки:

    • Использовать только IP-адрес, назначенный интерфейсу SVI, если трафик попадает в группу коммутации, в которой имеется интерфейс SVI.
    • Допускается использовать IP-адрес, назначенный физическому интерфейсу (радиоинтерфейсу или Ethernet), если данный интерфейс не включен в группу коммутации, либо в группе коммутации отсутствует интерфейс SVI.

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

    Источник

    

    Расширение файла SVI

    В таблице ниже предоставляет полезную информацию о расширение файла .svi. Он отвечает на вопросы такие, как:

    • Что такое файл .svi?
    • Какое программное обеспечение мне нужно открыть файл .svi?
    • Как файл .svi быть открыты, отредактированы или напечатано?
    • Как конвертировать .svi файлов в другой формат?

    Оглавление

    Мы надеемся, что вы найдете на этой странице полезный и ценный ресурс!

    1 расширений и 0 псевдонимы, найденных в базе данных

    ✅ Samsung Video File

    Другие типы файлов могут также использовать расширение файла .svi.

    🚫 Расширение файла .svi часто дается неправильно!

    По данным Поиск на нашем сайте эти опечатки были наиболее распространенными в прошлом году:

    Это возможно, что расширение имени файла указано неправильно?

    Мы нашли следующие аналогичные расширений файлов в нашей базе данных:

    🔴 Не удается открыть файл .svi?

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

    Windows не удается открыть этот файл:

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

    Если вы не знаете как настроить сопоставления файлов .svi, проверьте FAQ.

    🔴 Можно ли изменить расширение файлов?

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

    Если у вас есть полезная информация о расширение файла .svi, напишите нам!

    Источник

    VLAN + DHCP + VoIP = Cisco

    В продолжение темы настройки DHCP на оборудовании Cisco с учетом VLAN, предлагаю рассмотреть вопрос вглубь: давайте скрестим описанный функционал с VoIP технологией. Что если мы решили внедрить в нашу сеть VoIP со всеми вытекающими последствиями: отдельным устройством с Communication Manager Express, VoIP телефонами и необходимостью приоретизации трафика?

    Для начала коротко об изображенной здесь архитектуре Cisco VoIP. Начнем с телефонов. В VoIP телефоны Cisco встроен минисвич на два порта, который позволяет подключить телефон к розетке, а компьютер к телефону. Этим мы экономим розетки и порты на свиче, но этим же и создаем себе дополнительную проблему: VoIP трафик должен быть изолирован от трафика, предназначенного компьютеру. Во имя приоретизации, что для VoIP критично, и безопасности.

    Для решения этой проблемы Cisco использует, говоря заумными словами, технологию 802.1q транков, а проще – VLAN. VoIP телефон добавляет в свой трафик тег, по которому свич распознает, что фрейм принадлежит VoIP трафику, и ему надо оказать особое внимание.
    На портах свича предусмотрен отдельная команда, чтобы задать VLAN для телефона, который подключен к нему. Теперь настройка порта будет выглядеть вот так:

    После этого свич по CDP передаст телефону номер его VLAN и он сможет помечать фреймы правильным тегом.

    «Ага, — скажет внимательный и хитрый читатель, — но ведь весь VoIP трафик всей сети сконцентрирован в одном VLAN? Значит, наш компьютер может отключить телефон, прикинуться им и слушать все разговоры по сети?»

    «И зачем вообще этот костыль c switchport voice vlan? – спросит внимательный и умный читатель, — ведь можно настроить порт на свиче как trunk, указав ему allowed vlan 10 и native vlan 50?»

    Ответ на оба эти вопроса один: Cisco предусмотрела механизм, который не позволяет чужому устройству прикинуться VoIP телефоном. Именно этот механизм включается командой switchport voice vlan. Второй внимательный читатель прав, его конфигурация верна и будет работать, но она сделает правым и первого внимательного читателя. А этого нам совершенно не нужно.

    Детальный рассказ про механизм Voice VLAN – это тема для отдельного поста. Те, кто заинтересовался и хочет узнать о нем прямо сейчас, могут почитать об этом на сайте Циско и, кто знает, может, в процессе заинтересоваться еще чем-то из цисковского VoIP.

    Но вернемся к нашей задаче. В IP адресе нуждаются не только рабочие станции, но и IP телефоны. Однако доступ к DHCP серверу имеют только устройства из VLAN 50, то есть, компьютеры. Что же делать телефонам?

    А для телефонов мы используем два интересных механизма DHCP: команду helper-address и принцип, по которому DHCP выделяет адреса.

    Настроим сам DHCP сервер на маршрутизаторе с двумя пулами:

    Команда network в настройке DHCP на Циско – одна из немногих, где мы можем задать маску подсети через слеш. А можем и вовсе не задавать, тогда она будет определена автоматически, в зависимости от класса сети.
    Команда default-router задает шлюз по умолчанию для сети, а dns-server – соответственно, DNS сервер. 4.2.2.2 – это адрес публичного NDS сервера, который поддерживается университетом Беркли, и является надежной альтернативой, если по какой-то причине вы не доверяете DNS вашего провайдера.
    Буквально парой предложений про еще одну особенность DHCP в VoIP: с его помощью телефоны получают адрес TFTP сервера, на котором хранится образ операционной системы для них. Эта функциональность известна как опция 150 и задается командой:

    Если углубляться в DHCP еще больше, то все функции этого замечательного протокола являют собой опции. Так, шлюз по умолчанию можно задать как default-router, а можно как option 3. Под такими опциями скрыто множество интересной дополнительной функциональности, которая, к сожалению, тоже в один пост не поместится.

    Все-все, уже заканчиваю отвлекаться: таким же образом настроим пул IP адресов для рабочих станций:

    Дальше идем на сабинтерфейсы CME роутера (предполагаю, что вы знакомы с маршрутизацией между VLAN и уже настроили их самостоятельно). Все широковещательные пакеты, при помощи которых наши телефоны будут обращаться к широкой общественности: «эй, кто здесь DHCP сервер, мне нужен IP адрес» придут на сабинтерфейс Fa0/0.10 – потому что телефоны находятся во VLAN 10. Тут бы этим крикам о помощи и погибнуть – в VLAN 10 нет DHCP сервера – но это не выход. Выход – команда ip helper-address:

    Этой командой мы говорим CME маршрутизатору: когда ты получаешь широковещательный DHCP пакет, отправляй его DHCP серверу по адресу 172.16.2.5. Этот сервер ответит тебе, и тогда ты передашь его тому, кто прислал тебе запрос.

    «Подождите, — скажут наши внимательные читатели, — но ведь телефоны передают широковещательными пакетами «эй, дай нам IP адрес» точно так же, как и компьютеры – все эти устройства не имеют адресов. Как DHCP сервер узнает, что телефонам он доложен выдавать адреса из пула VOICE, а компьютерам – из пула DATA?”

    Тут мы подходим ко второму интересному моменту: на самом деле DHCP сервер не знает. Если бы все телефоны и компьютеры были в одном VLAN, он бы сказал: «Я не знаю, кто вы такие. Все ваши запросы пришли ко мне через интерфейс 172.16.2.5, потому я выдам всем вам адреса из сети, к которой относится этот интерфейс, то есть 172.16.2.0/24».

    Но мы использовали helper-address! Смотрите, как это работает сейчас: компьютеры шлют запрос «эй, дай мне IP адрес». Запрос попадает к DHCP серверу через интерфейс 172.16.2.5 – сервер находится в том же VLAN, что и компьютеры. И он выдает им адреса из сети 172.16.2.0/24 – нашего DATA пула. Но широковещательные пакеты телефонов идут в другом VLAN. Они приходят на сабинтерфейс Fa0/0.10, который для них является шлюзом по умолчанию, и CME шлет их на ip helper-address — 172.16.2.5.

    И когда CME пересылает запросы телефонов, он не посылает их как broadcast. Он шлет их как unicast. А unicast IP пакет имеет адреса источника и получателя. И в нашем случае IP адресом источника DHCP запроса будет адрес сабинтерфейс Fa0/0.10, потому что там эти фреймы впервые вышли на третий уровень, там они впервые вообще узнали, что в мире бывают IP адреса!

    Итак, DHCP сервер получает unicast запрос, source address которого значится 172.16.1.1. «Ага, — говорит сервер, — значит, источник запроса имеет связь с этим адресом. Значит, надо выдавать ему IP адрес из сети, к которой этот адрес относится». И отвечает на запрос выдачей адреса из сети 172.16.1.1/24 – нашого VOICE пула!

    Таким образом, мы получаем как раз то, что хотели: все наши телефоны получили IP адреса из нужной подсети, они изолированы от VLAN с данными и имеют связь только с CME, который может соединять их с другими телефонами через PSTN или VoIP посредством Интернет. Компьютеры же получили адреса из другой сети, они теперь могут обмениваться данными с филиалами компании, server farm или чем угодно еще. Мы получили гибкую в настройке сеть, возможность приоретизации трафика на втором и третьем уровне и экономию пропускной способности и ресурсов за счет использования одного DHCP сервера для нескольких изолированных VLAN.

    Источник

    Читайте также:  Андроид авто как настроить ютуб