У некоторых компаний сеть продолжает разрастаться. Что же делать в этом случае? Об этом продолжает рассказ Павел Денисов, системный инженер московской компании Extreme Networks. Чем же сможет помочь Fabric Connect.
Fabric Connect
У нас, как и раньше два здания, но появилась некоторая конкретика. Здесь есть 10-й пользовательский VLAN в левой части, есть 20-й пользовательский VLAN в правой части и 100-й VLAN в ЦОДе.
Если нужно в такой инфраструктуре сделать сервис для клиентов, например, объединить синие VLANы в разных частях между собой, так, чтобы пользователи из синего 10-го VLAN в здании слева имели доступ к серверу в VLANе 100-м, и к тому же серверу имели доступ пользователи в VLAN 20-м из здания, расположенного в правой части слайда, нужно сделать одинаковый набор конфигураций на обоих сайтах.
Здесь создан 10-й VLAN в здании слева, в здании справа - 20-й VLAN. Дальше мы пируем VLAN к I-SID. I-SID - это сервис ID, это идентификатор сервиса, который работает внутри фабрики, в данном случае это L2-сервис. Т.е. это сервис, который обеспечивает связанность между хостами, которые подключены к данному сервису по протоколу Ethernet на уровне MAC-адресов, т.е. на втором уровне. И ровно такую же команду мы должны будем дать в здании слева.
Альтернатива созданию связанности между хостами на втором уровне это маршрутизация, т.е. построение сервисов третьего уровня между различными сетевыми устройствами. Третий уровень позволяет добиться большей масштабируемости в сетевой инфраструктуре. Схемы маршрутизации всегда проще масштабируются, однако в ряде случаев по тем или иным причинам нет возможности использовать маршрутизацию. Обычно это связано со спецификой оконечных устройств, которые используются в сетевой инфраструктуре. До сих пор еще встречаются клиенты, которые не умеют работать через шлюз по умолчанию и стек SPIP на них реализован не очень правильно. Именно для таких клиентов как правило и приходится делать L2-сервисы, объединяющие разные площадки между собой. В классической архитектуре мы вынуждены растягивать ее VLANом, в случае фабрики мы делаем I-SID 2-го уровня и подключаем клиентов.
Итак, маршрутизация. Похожая схема. Мы можем делать несколько виртуальных сервисов, внутри которых будет работать маршрутизация. На этой схеме показано несколько VLANов. Красные VLAN есть и слева, и в правой части слайда. Они подключаются к красному L3VSN, он же I-SID, который создает сервис третьего уровня для клиентов и аналогичный I-SID создан для серверов. Настраивается это чуть сложнее, чем в случае L2 сервиса.
Единственное отличие, пожалуй, заключается в том, что здесь нужно создать еще и IP VRF (Virtual Routing and Forwarding), сделать VRF Instance, в которые будут заниматься маршрутизацией IP пакетов для данного виртуального контекста, и после создания этого Instance мы должны подключить в него наши пользовательские VLAN и создать сервис, а затем привязать его к созданному VRF.
С пользователями все достаточно просто происходит. Теперь нужно оценить, что будет с серверами, с миграцией виртуальных машин и с маршрутизацией в такой сети. Итак, опять те же два сайта. У нас есть серверный сегмент в левом здании и есть серверный сегмент в правом здании.
Для того, чтобы работала миграция виртуальных машин, нужна связанность на втором уровне между обоими серверными сегментами, так, как это показано в нижней части слайда. Здесь есть два subnet, один и тот же VLAN, с одной и той же схемой адресации. Есть синий и зеленый subnet. Есть серверы в том и в другом subnet они в двух ЦОДах расположены. И теперь стоит задача сделать эффективную систему маршрутизации для таких сайтов.
Нужно зарезервировать шлюзы по умолчанию, и первое, что приходит в голову это использовать протокол VRRP, но классическая реализация VRRP не очень удобна, потому что в VRRP-группе есть только один активный маршрутизатор. И где бы он ни располагался в данной схеме, мы всегда рискуем получить не самое эффективное использование межсайтовых линков. Если, например, синий сервер должен «поговорить» с зеленым сервером, расположенном в том же здании, например, в соседней стойке, а, например, VRRP-мастер будет расположен на этом устройстве, трафик будет вынужден пройти межсайтовый канал в одну сторону и потом вернуться, маршрутизироваться и попасть в зеленый VLAN и прийти сюда. Это и есть неэффективное использование link, увеличение задержек и т. д.
Distributed Virtual Routing
Однако, есть способ лучше, который предлагает фабрика. В случае использования фабрики можно всю ту же инфраструктуру реализовать с использованием дополнительной технологии. Внутри технологии Extrim Fabric Connect есть отдельный вид сервиса, называется этот Distributed Virtual Routing (DVR).
У нас опять чуть-чуть изменилась схема, но смысл ее остался тот же. Есть два здания в левой и в правой частях слайда. По-прежнему есть VLANы с серверами, расположенными в левой и в правой части здания. Есть растянутые L2 сегменты между зданиями. И мы хотим теперь оптимизировать пути передачи трафика. Посмотрим, как технология DVR в этом поможет.
В архитектуре DVR выполняет две роли: контроллера и пограничного устройства, так называемый DVR Leaf. Есть DVR контроллер, их обычно два (для резервирования) и есть DVR Leaf. Кроме того, коммутаторы внутри архитектуры DVR объединяются в DVR-группы. И делается это на основе их территориальной принадлежности к сайтам. Вот так, применительно к нашему случаю, мы создаем две DVR-группы или DVR домены. В здании слева DVR Domain #1. В здании справа DVR Domain #2. И внутри каждого домена есть пары маршрутизаторов, выполняющие роль контроллеров, и группы маршрутизаторов, выполняющие роль пограничных устройств DVR Leaf. Справа и слева схемы абсолютно симметричные. К Leaf подключают серверы, те самые, которые могут быть в левом и правом здании и связанность между которыми нужно обеспечивать. Каждое здание это отдельный DVR Domain. А домены между собой связываются через DVR Backbone. Настраивается это достаточно просто.
Мы создаем DVR Instance и говорим, к какому DVR Instance привязываются Leaf.
А на контроллерах мы создаем похожую конфигурацию. Мы там же создаем VLANы, там же настраиваем шлюзы по умолчанию. Мы используем на контроллерах протокол VRRP для резервирования шлюзов по умолчанию, причем оба маршрутизатора являются участниками VRRP-групп. Это настраивается, как настраивается VRRP. Но на самом деле мы используем не классический VRRP, а за счет использования DVR используем модифицированную логику работы. Использование DVR и фабрики позволяет чуть-чуть по-другому решить задачу. Итак, маршрутизатор выполняет роль маршрутизаторов по умолчанию всех подключений, но они же после настройки, после того, как мы на них настроили VLANы и шлюзы по умолчанию, они эту информацию о VLANах и о шлюзах по умолчанию для этих VLANов передают на все пограничные устройства. Т.е. на каждом пограничном коммутаторе DVR Leaf будет информация о том, что в нашем зеленом VLANе есть шлюз по умолчанию с адресом 101. И он является шлюзом по умолчанию для этого сегмента. И то же самое мы настраиваем на втором маршрутизаторе для резервирования, чтобы роль DVR контроллера была резервирована. Симметричный config настраивается на втором устройстве.
И в здании справа создаем похожую конфигурацию. Единственное отличие в том, что домен DVR здесь другой. А с точки зрения IPV четвертой адресации мы используем одну и ту же схему. Точно также, как мы бы делали в случае настройки по протоколу VRRP, если бы хотели эти четыре маршрутизатора объединить в один виртуальный Instance протокола VRRP, то мы должны бы были указать на них один и тот же виртуальный IP адрес, который бы являлся основным шлюзом по умолчанию для этого VLANа. И мог бы мигрировать между всеми четырьмя маршрутизаторами. Похожая схема с точки зрения настройки IPV четвертого, отличается только логика по тому, как работают маршрутизаторы в данной схеме и как обеспечивается обработка трафика.
Мы сделали симметричные настройки для зеленого и синего VLANов, и теперь создали два DVR домена, настроили контроллеры, настроили DVR Leaf. У нас все пограничные устройства знают про VLANы и шлюзы по умолчанию. Теперь посмотрим, как трафик будет ходить в этом случае.
Предположим, у нас хост из синего VLANа отправляет пакет на DVR Leaf. Тот видит, что это пакет принадлежит синему VLANу и изучает его MAC-адрес и информирует все другие маршрутизаторы, которые принадлежат данному DVR домену о том, что хост с таким IP MAC-адресом находится в синем VLANе DVR домена. Об этом будет знать каждый DVR Leaf устройства в домене. Об этом будет знать DVR контроллер. DVR контроллеры также обменяются этой информацией между собой, т.е. DVR контроллеры в домене #1 сообщат об этом DVR контроллерам о наличии MAC-адреса в своем домене DVR контроллеру, принадлежащему другому домену. Т.е. внутри сайта, внутри DVR домена все устройства знают о наличии сервера в синем VLANе. И знают, за каким VLANом они находятся. Весь домен имеет одинаковую информацию про свои подключения. DVR контроллер в другом домене знает, что путь к этому хосту лежит через DVR контроллеры второго домена.
Локальный трафик пойдет уже таким образом. Если нам нужно обработать, отправить пакет с сервера, расположенного в одном VLANе в сервер, расположенный в другом VLANе, у нас все маршрутизаторы внутри нашей схемы знают про то, где эти хосты расположены.
В данном случае трафик не пойдет до DVR контроллеров, которые формально с точки зрения конфигурации являются у нас шлюзами по умолчанию для сетей, а первый же DVR Leaf на пути нашего пакета сделает маршрутизацию, переложит пакет в VLAN назначения и отправит его в сторону получателя.
А как пойдет трафик между хостами, расположенными в разных доменах? Как говорилось выше, информация о хостах, расположенных в другом DVR домене неизвестна DVR Leaf. Про нее знает только контроллер. В этой схеме нужно обеспечить взаимодействие VM-3 с VM-6, который расположен в другом домене. Поэтому VM-3 пакет доходит до DVR контроллера, который его отправляет через DVR линк на контроллер другой группы, которая в свою очередь имеет полное визибилити внутри себя и отправляет его на конечную станцию.
Для того, чтобы у нас корректно работала VM-технология при миграции виртуальных машин между сайтами, когда машина подключается к хосту, хост активируется, отправляется специальный пакет для того, чтобы сеть «выучила» MAC-адрес и все Leaf-ноды внутри домена. И DVR контроллер узнал про то, что появилась новая станция, о чем он уведомит и другие DVR домены.
И если у нас происходит миграция машин, то анонс об этом по похожей схеме по сети распространяется и сеть может адекватно реагировать, зная о том, что хост переместился, зная о том, что теперь обновит все свои таблицы и все устройства в сети будут знать за каким оконечным коммутатором новый хост расположен.
DVR архитектура позволяет достаточно эффективно решить задачу по оптимизации сложных трафиков в архитектурах, в том числе с распределенными VLANми и L-2 доменами между сайтами. И несмотря на это она обладает достаточно большим запасом по масштабированию, т.е. у нас может быть до восьми контроллеров в каждом домене для обеспечения задачи по резервированию этих контроллеров. До 250-ти пограничных маршрутизаторов может быть в домене. Ну и до 40 тысяч хостов в каждом домене и до 16 доменов. С использованием этой технологии можно собрать достаточно большую систему, которая позволит эффективно решать задачи по маршрутизации трафика в таких архитектурах.
Расширение до удаленного офиса
Часто появляется необходимость развивать сеть за границы одного офиса, подключать удаленные объекты. Для решения такой задачи есть несколько путей. Похожую задачу мы решали при объединении вот этих двух сайтов. Самый простой вариант - использование темной оптики (dark fibre).
Тёмное волокно (англ. dark fiber) — неиспользуемые для передачи данных волокна оптического кабеля, прокладываемые в качестве резерва на случай выхода из строя основных волокон.
Термин применяется, в частности, при описании незадействованного потенциала глобальной системы связи. Компании, занимающиеся строительством/укладкой оптического волокна, часто укладывают дополнительные волокна в расчете на будущий рост трафика, так как затраты ресурсов на расширение существующих ВОЛС слишком велики. Тёмное волокно лежит в бездействии до тех пор, пока владелец сети не использует его для собственных нужд или не сдаст в аренду другой компании. Согласно эмпирическому правилу, в оптическом кабеле на каждые шесть пар задействованных волокон рекомендуется укладка одной резервной пары. Например, по регламентам Ростелекома в магистральном кабеле допускается закладывать до 15% резервных волокон для GPON или до 10% для FTTB, но не менее двух.
Далее применяется система оптического уплотнения с использованием цветной оптики SVDM, через которую можно подключать удаленные сайты, но у вас должны быть доступны такие каналы связи. Часто это бывает не так, особенно когда сайт может быть в другом городе. Оптику для такого сайта организовать можно, но это скорее всего будет очень дорого и не всегда экономически оправдано. Однако есть другие, более экономичные пути. Например, использовать услугу L-2 или L-3 VPN от операторов услуг связи, либо просто построить такое взаимодействие через Интернет с использованием IP VPN сервисов.
Если мы идем любым из этих путей, у нас по-прежнему сохраняется возможность растянуть наши виртуальные контексты, те самые I-SID, которые мы создавали и которые у нас успешно работали в рамках основного и резервного первого и второго сайта в двухсайтовой архитектуре. Мы создавали в них какой-нибудь L-2 или L-3 контексты для решения различных задач. Здесь у нас появилась возможность растянуть сеть, добавить к сетевой инфраструктуре удаленное подразделение, расположенное в другом городе, использовать для этого сеть операторов услуг связи. IPLS или IP VPN решения, мы можем сохранить виртуальные контексты и сохранить принадлежность хостов к виртуальным контекстам при передаче трафика из удаленного сайта в центр и в обратную сторону.
Но для этого следует использовать технологию Fabric Extend, которая также является частью архитектуры для кампусной фабрики. Fabric Extend - это технология, которая использует VXLAN туннели для передачи SPB трафика между разными сайтами, при этом природа межсайтовых каналов не важна. Это может быть L3 VPN. Здесь каждый удаленный сайт имеет IP-адрес в отдельной подсети, это такая как бы «хабенспоктопология» с L3 VPN, это может быть L2 VPN, как в правой части данного слайда. LPLS-технология, которую вам оператор продает. Независимо от того, как выглядит канальная инфраструктура между сайтами, технология Fabric Extend позволит растянуть сервисы между удаленными площадками, сохранив их сегментацию.
Единственное, на что следует обратить особое внимание, то это на тот факт, что за счет дополнительного туннелирования появляются дополнительные заголовки и размер кадров увеличивается. Про это нужно помнить. Если мы хотим растягивать I-SID фабрики через сети операторов, с использованием технологии Fabric Extend, мы должны уточнить у оператора, позволяет ли его сеть передавать пакеты с большим MTU. На слайде показано, что за счет использования VXLAN заголовка, размер пакета становится равным 1594 байта. Обычно операторы поддерживают это. Но это нужно уточнять.
Использование Fabric Extend позволяет, как это показано в нижней части слайда, не просто связывать удаленные здания, но и сохранять принадлежность оконечных устройств и трафик этих оконечных устройств изолировать, устройств, ближайших к I-SID даже при переходе между сайтами. Если бы мы не использовали технологию Fabric Extend, а использовали, например, классический MPLS, нам нужно было бы создавать несколько VRF, по одному VRF для каждого I-SID, что делало бы эту конструкцию более громоздкой и менее удобной в эксплуатации.
Fabric Extend позволяет решить эту задачу, подключать удаленные сайты с сохранением сегментации и сетевой виртуализации.
Для того, чтобы решить эту задачу, у вендора недавно появилось новое устройство - XA1400, которая может быть использована в удаленных сайтах. Это такой пограничный маршрутизатор с поддержкой технологии Fabric Extend для того, чтобы обеспечивать выносы фабрики за пределы одного офиса. При этом это устройство поддерживает не только технологию Fabric Extend, но и маршрутизацию. И можно ее использовать для построения выносов через инфраструктуру операторов услуг связи, через L2, L3 VPN с и без всяких VPN с другой стороны.
Настраивается все достаточно просто. Сейчас не будем на этом заострять внимание.
Операционные модели
А сейчас несколько слов про систему управления. По мере роста нашего сетевого решения становится сложно управлять возросшим парком оборудования через консоль.
Нужны какие-то дополнительные средства, которые бы позволили делать это просто и эффективно. Система Extreme Management Center и предназначена для того, чтобы помочь в решении этой задачи. Система состоит из нескольких модулей. Прежде всего это все, что связано с сетевым управлением, отображением карт, сбором конфигураций, управления конфигурациями, управления файлами ПО, сбором логов и анализом этих логов. Другая компонента обеспечивает автоматизацию подключения пользователей к сети, назначение и регулирование политик доступа пользователей при сетевых подключениях. И еще одна компонента отвечает за сбор аналитики о сетевом трафике пользователей. И при этом все эти три компоненты работают с любыми из коммутаторов вендора.
Одна из компонент этой системы управления называется Fabric Manager. Эта компонента позволяет визуализировать фабрику. Данная компонента доступна в самом простом basic-уровне лицензии системы управления. Лицензия позволяет визуализировать фабрику, смотреть, какие устройства являются ее участниками, отображать состояние этой фабрики, смотреть, какие сервисы в ней активны и какими путями они идут. Если вы хотите заниматься настройкой вашей фабрики через этот графический инструмент, то вам будет необходимо приобрести Edvance уровень лицензии на систему Extreme Managment Center.