Привет, Хабр!
Ранее в нашем блоге мы подробно разбирали особенности и возможности VMware SD-WAN, а также тестировали решение. Сегодня мы хотим поделиться реальным кейсом внедрения сервиса.
Речь пойдет о компании Business Car — владельце крупнейшей сети официальных дилерских центров по продаже и обслуживанию автомобилей Toyota и Lexus в Европе. Здесь будет все — устаревшие технологии, неоднородная конфигурация инфраструктуры, ограниченный бюджет и другиедраконы сложности. Но обо всем по порядку.
Чтобы вы представляли масштаб задач. Группа компаний «БИЗНЕС КАР» представлена на российском автомобильном рынке более 30 лет. В структуру группы входят 23 дилерских центра в Москве, регионах России и Казахстане. Основные направления деятельности — продажа новых автомобилей и авто с пробегом, сервисное обслуживание, лизинг, страховые и кредитные программы, корпоративные и дипломатические продажи.
Остановимся на истории с распределенными офисами продаж в Москве. Изначально это 5 точек и 2 дата-центра с устаревшим парком сетевого оборудования на каждой площадке. К одному ЦОДу подключались внешние каналы связи, в том числе региональные филиалы, во втором дата-центре была развернута база 1С. Московским и другим удаленным офисам был нужен круглосуточный доступ к сервису 1С. Сеть клиента была непрозрачна (SD-WAN же еще не внедрили!) и отслеживать источники проблем былону просто нереально крайне затруднительно. К тому же клиенту требовалась унификация настроек сетевого оборудования и инструменты для повышения безопасности сетевой инфраструктуры.
Обсуждая спецификацию, мы предложили несколько вариантов реализации проекта:
С учетом опыта архитекторов #CloudMTS и VMware по проектированию, развертыванию и поддержке SD-WAN инсталляций любых масштабов и сложности, а также пожеланий заказчика, было принято решение использовать схему на оборудовании провайдера. Мы полностью проработали сетевую топологию, подготовили документ, который включал в себя этапы аудита текущей инфраструктуры заказчика, рекомендации по корректной сетевой схеме, движению потоков трафика и необходимым настройкам на оборудовании.
После этапа проработки перешли к этапу внедрения. Он начался спустя месяц после заказа оборудования (а это довольно быстро). На этом этапе мы провели анализ конфигурации на старом оборудовании, адаптировали ее под новое железо и внесли необходимые изменения, чтобы получить корректную схему. Все эти работы полностью взяла на себя команда #CloudMTS. На основе анализа собранной информации, а также понимая конечного состояния сети после миграции, заказчику было предложено техническое решение. План миграции предполагал поэтапный переход с текущей Legacy-инфраструктуры на SD-WAN, при этом такая гибридная сеть должна была продолжить работу в бесшовном режиме для пользователей и приложений. Для эффективной утилизации ресурсов часть заменяемого оборудования перенесли на уровень локальной сети, уступив каналообразующую роль современным SD-WAN-маршрутизаторам. Для увеличения отказоустойчивости центральной точки обмена трафиком предложили парную схему установки маршрутизаторов с горячим резервированием, а также виртуальный маршрутизатор в ЦОД, где располагались приложения.
Наверняка вы и так знаете, каким может быть сетевой трафик, но на всякий случай напомним. Когда вы заходите в интернет, чтобы заказать доставку, посмотреть видео с котиками — это некритичный трафик. Но если речь касается VOIP, подключения клиентов к сервису 1С, от доступности которого зависит работа всей компании, — такой трафик смело претендует на звание «Critical».
В случае с Business Car провайдерские VPN-каналы связывали SD-WAN-фабрику между собой, но возникала проблема — клиентский менее значимый интернет-трафик вытеснял все важные бизнес-сервисы. Это приводило к тому, что каналы были постоянно перегружены, а приоритетные сервисы деградировали. С помощью мониторинга SD-WAN по источнику трафика мы увидели хост, который потреблял очень много трафика на upload. Спойлер — это был сервер видеонаблюдения. Проблему удалось вовремя обнаружить и дать рекомендации по ее устранению.
Но это ещё не все, была и другая проблема. Обращения, направленные в сторону 1С-облака, шифровались не полностью. Такая картина нарушала правила безопасности компании. После внедрения SD-WAN шифрование обеспечивается SD-WAN-тоннелем поверх существующего канала связи.
Если клиент привык потреблять сервис по арендной модели, позже он вряд ли изменит своим привычкам. У Business Car уже был опыт использования провайдерских услуг. К тому же хотелось избавиться от устаревших маршрутизаторов, которые все еще числились на балансе. Чем позже происходит замена, тем больше появляется проблем. В отсутствие поддержки и свежих версий ПО увеличиваются риски безопасности. Возросшие требования к пропускной способности делают такое оборудование бутылочным горлышком всей сети либо ее части.
Со старым сетевым оборудованием на руках у клиента было два пути:
Поскольку Business Car не хватало экспертных кадров, а любой крупный проект по обновлению оборудования требует больших инженерных ресурсов на этапе внедрения, решили пойти наиболее простым путем — выбрать провайдерское решение по арендной модели предоставления услуги.
Любой комплексный проект, связанный с SD-WAN, подразумевает не только обновление парка сетевых устройств и модернизацию сети, но и смену подхода к ее эксплуатации. Например, построение оверлейной сети даже поверх существующего MPLS VPN позволит скрыть трафик от underlay-уровня, зашифровать его, а также повысить прозрачность сети.
Большинство проектов имеют свой жизненный цикл, и внедрение программно-определяемых технологий не исключение. Такие понятия, как Day 0/Day 1/Day 2 operations, также можно применить и в отношении миграции на SD-WAN с Legacy инфраструктуры. В этом проекте мы выделяем фазы планирования (дизайна), интеграции (развертывания) и постинсталляционный тюнинг. Рассмотрим их подробнее.
Когда определены цели проекта, желаемое конечное состояние сети в результате миграции на SD-WAN и перечень площадок, наступает фаза планирования. Кульминация этого этапа – готовое техническое решение, на основе которого и будет производиться внедрение.
Итак, какие данные мы собрали и как потом их использовали.
Прежде всего мы собрали информацию о каналах передачи данных (их количество, тип и пропускная способность), проанализировали паттерны трафика в мигрируемой сети, нагрузку на каналы связи и как площадки «общаются» между собой. После этого нам предстояло изучить конфигурацию существующих продуктивных маршрутизаторов, адаптировать ее к новому решению, а также оптимизировать, удалив ненужное и сократив этим размер конфигурации.
С топологической точки зрения сеть представляла собой Full Mesh с выделением таких ролей, как стандартный филиал и ЦОД. ЦОДы имели собственный выход в Интернет, а площадки, объединенные провайдерским VPN (и в контексте SD-WAN не имеет значения L2 это или L3) получали доступ к префиксам друг друга, а также к сетям ЦОДов и Интернет. Для распространения маршрутной информации использовался классический IGP-протокол.
Для снижения времени простоя сети при миграции и упрощения процесса реализации в целом проект был разбит на несколько этапов, подразумевающих переход на SD-WAN группами площадок. Также был составлен адресный план, описывающий линковые подсети, подсети филиалов и другие соглашения об адресации.
При модернизации существующей сети важно помнить о минимизации простоя сервисов и не допустить деградации того, что не должно быть затронуто миграцией. Эта простая истина работает и в случае с SD-WAN. Пока сеть полностью не переведена на SD-WAN, она существует в двух плоскостях, взаимодействие которых никак не должно отразиться на пользователях.
Создание и настройка SD-WAN фабрики
SD-WAN от VMware начинается с Оркестратора. Оркестратор предоставляет доступ к тенанту, в котором создается и эксплуатируется наложенная сеть.
На этапе планирования мы собрали всю необходимую информацию, на основе которой были созданы площадки, конфигурационные профили для каждого типа площадок и выполнены специфичные настройки для каждой площадки. Были перенесены либо адаптированы к VMware SD-WAN следующие категории конфигурации:
Филиалы условно были разделены на две группы – с частичным сохранением текущего оборудования и с полным переносом его функционала на SD-WAN Edge. Это позволило гибко разделить конфигурацию площадок – на те, где пользовательские VLAN терминируются на SD-WAN Edge и где Edge является пограничным маршрутизатором, а VLAN терминируются на нижестоящем оборудовании. Такой подход позволил не только гибко настроить филиалы, но и эффективно использовать парк существующего сетевого оборудования.
Активация площадок
Как было упомянуто ранее, активация площадок производилась в несколько этапов. На первом этапе были мигрированы филиалы, где SD-WAN Edge является не только пограничным маршрутизатором, но и точкой терминации пользовательских VLAN. Благодаря проработке архитектуры и корректной настройке всех элементов сети после развертывания площадок первого этапа у заказчика появились филиалы, связанные SD-WAN тоннелями, построенными поверх существующего транспорта. В то же время остальная часть сети работала по старым правилам и взаимодействовала с небольшим «островком» SD-WAN незаметно для пользователей.
Архитектура VMware SD-WAN предусматривает инструменты и технологии для взаимодействия с non-SD-WAN сетями в процессе миграции и позволяет совмещать overlay и underlay маршрутизацию. Если изобразить такую площадку в соответствии с рекомендациями вендора, то получится следующая схема размещения, за исключением того, что канал Интернет не подключается напрямую, а доступен через центральную площадку (ЦОД), так как основными каналами в филиалах являются MPLS VPN.
Референсная модель размещения SD-WAN Edge c гибридным подключением и L2 коммутатором.
Вторым этапом была запланирована миграция филиалов, где SD-WAN Edge выступал в роли пограничного маршрутизатора и как nexthop для коммутатора, терминирующего пользовательские broadcast-домены. В качестве промежуточного этапа можно отметить активацию виртуального SD-WAN Edge на площадке одного из двух ЦОД, в котором обрабатывается трафик приложений, в том числе 1С.
Схема включения площадки отображена на рисунке ниже, при этом канал Интернет не подключается напрямую, а доступен через центральную площадку (ЦОД), так как основными каналами в филиалах являются MPLS VPN.
Референсная модель размещения SD-WAN Edge c гибридным подключением и L3 коммутатором.
Последней из площадок мигрировали основной ЦОД, и его конфигурация вызывает наибольший интерес. На этой площадке были установлены два высокопроизводительных устройства, объединенных в отказоустойчивый кластер по технологии High Availability Pair. Отказоустойчивая пара выступает в роли пограничного маршрутизатора, подключенного к L3-коммутатору, отделяя тем самым домен SD-WAN от остальной части сети. HA Pair позволяет ведомому устройству перенять на себя роль ведущего не более чем за секунду, при этом часть сессий приложений сохраняется, а конфигурация обоих устройств всегда одинаковая. Уникальной особенностью также является то, что и к ведущему, и к ведомому (Active/Standby) могут быть подключены каналы связи от разных провайдеров, и трафик может передаваться по HA Link каналу между двумя устройствами (bypass). Также основной ЦОД является демаркатором VPN и Интернет, и благодаря встроенным механизмам управления трафиком филиалы получают доступ в Интернет через наложенную сеть.
Для данной реализации вендор в качестве best practice рекомендует следующую схему подключения (см ниже). Следует отметить, что референсная модель по тем или иным причинам может быть избыточна. Например, L3 коммутатор может быть один, но стекируемый, и доступ в Интернет может осуществляться через него же, только в другом VLAN, нежели пользовательский трафик, если мы имеем схему, при которой площадка выполняет не только роль ЦОД или агрегатора трафика, но берет на себя обработку пользовательского трафика терминируемых локально сетей.
Референсная модель размещения SD-WAN Edge c гибридным подключением, HA Pair и L3 коммутатором.
Изменения в маршрутизации после миграции
Здесь хотелось бы упомянуть не столько о глобальных преимуществах (например, network visibility), сколько о более специфических вещах, таких как обмен маршрутной информацией. В традиционных корпоративных сетях передачи данных маршрутизация осуществляется IGP-протоколами (за исключением небольших инсталляций, где допустима статика), которые требуют ручной настройки самих процессов, фильтрации маршрутов, контроль за редистрибуцией маршрутов и настройками смежности. К тому же, если речь идет о маршрутизации внутри тоннелей, эти тоннели надо сначала настроить, что существенно усложняет администрирование всей маршрутизации сети заказчика.
В VMware SD-WAN тоннели строятся автоматически в соответствии с заданной на уровне L3 сегмента (расширенный аналог VRF в масштабах всей SD-WAN фабрики) политикой, а маршрутизация централизованная и распределенная. Это значит, что не нужно строить пиринговые сессии с соседями, маршруты с каждого SD-WAN Edge передаются на SD-WAN Gateway (VCG), который распределяет их по другим узлам, если это допустимо (есть SD-WAN тоннель до первоначального источника маршрута). Анонсировать тот или иной маршрут решает администратор, отметив соответствующий чек-бокс в настройках интерфейса. Редистрибуция из overlay в underlay происходит также автоматически, а Оркестратор позволяет визуализировать всю таблицу маршрутизации вашей фабрики.
Схематичное изображение топологий SD-WAN.
После реализации проекта
В рамках реализации проекта Cloud SD-WAN в соответствии с техническим решением мы провели итоговый аудит и дали рекомендации по дальнейшему тюнингу SD-WAN фабрики. Так, в случае наличия двух георазнесенных площадок и независимыми Интернет-каналами, их также можно соединить SD-WAN тоннелем, но использовать его только тогда, когда недоступны каналы через MPLS VPN (если они основные). Помимо этого, для снижения нагрузки на основной канал Интернет типовой рекомендацией является подключения к MPLS only сайту выделенного канала Интернет для создания политики управления трафиком, которая будет помогать разбалансировать конкретный трафик. Приоритетный трафик продолжит маршрутизироваться через центральную точку, а низкоприоритетный и потребляющий широкую полосу трафику будет передаваться через Интернет. Кроме этого, через Интернет-каналы также будут строиться SD-WAN тоннели, повышая отказоусточивость площадок к возможной потере связности с SD-WAN фабрикой и бизнес-приложениями из-за отказа каналов связи.
Изменена логика настройки маршрута по умолчанию. В отличие от традиционных сетей теперь на площадке не нужно принимать дефолт, достаточно объявить один из узлов как Backhaul Hub — это позволит создавать гранулярные правила, передавая через такой Hub только трафик определенных приложений с определенной адресацией или иными заданными паттернами.
Помимо прочего, клиент пользуется услугами передачи данных — интернет, VPN-каналы — получая сервис в едином окне. Business Car использует смешанные гибридные каналы как от МТС, так и от другого поставщика. Но поскольку большая их часть приходится на МТС — клиент получает максимум преимуществ, потребляя сервис по провайдерской схеме.
На сегодняшний день клиент уже больше года пользуется решением Cloud SD-WAN. Сеть заказчика работает стабильно без перебоев, несмотря на то, что каналы не расширялись, при этом они не рассчитаны на используемый объем трафика. За счет правильного распределения нагрузки проблема была решена. К тому же удалось снизить затраты и сократить время на эксплуатацию инфраструктуры.
Фраза про ответственность в услугах нередко вызывает страх и опасение со стороны клиента. Заказчики не до конца понимают, в какой момент и на чьей стороне мяч.
Рассмотрим на примере Cloud SD-WAN. Мы как провайдер отвечаем за работу
SD-WAN-фабрики, в частности, за работу и доступность VCO (оркестратора, который находится в облаке), за элементы VCG (которые являются распределенными шлюзами и хранят в себе таблицу маршрутизации SD-WAN-фабрики), а также за работу программного обеспечения и функционирование физического оборудования SD-WAN Edges на локациях заказчика. К сказанному — проводим консультации, отвечаем на вопросы клиентов, связанные с работоспособностью программной и аппаратной части комплекса. В случае выхода из строя оборудования выполняем замену.
Функционал Cloud SD-WAN можно протестировать двумя способами: упрощенным или более комплексным.
Упрощенное тестирование
Если вы хотите легко и быстро оценить возможности сервис без существенных работ на своей рабочей сети, проверить функционал систем мониторинга, управления, траблшутинга— выбирайте упрощенный вариант тестирования. Такой формат подойдет и тем, кто в целом понимает, зачем нужен SD-WAN, либо если у вас небольшое количество филиалов и вы сможете «попробовать» Оркестратор и виртуальную SD-WAN фабрику online.
В таком сценарии мы предоставляем доступ к выделенному аккаунту (тенанту) на оркестраторе и сконфигурированным ресурсам облака, где уже развернуты виртуальные узлы SD-WAN Edge. Вы получаете ссылку на образ виртуального Edge, который можно развернуть у себя в офисе и проверяете функционал, который ничем не отличается от реального SD-WAN. Вы сможете выполнить нагрузочное тестирование, проверить, как работает сбор метрик, приоритезация трафика, переключение между каналами, за исключением того, что здесь не получится использовать физическое оборудование.
Комплексное тестирование
Если вы хотите понять, как применять решение SD-WAN в рамках вашей инфраструктуры, вы крупный заказчик и для вас важно проверить аппаратную часть — используйте комплексный подход. Так вы сможете определить, какие использовать порты, модули, как будет вести себя трафик, следуя с физического рабочего места в сеть. Комплексное тестирование предполагает установку физического оборудования на стороне заказчика. Для такого формата рекомендуем выбирать площадки, на которых есть «узкие» места, либо те, где проще обнаружить или имитировать проблему, с которой вы периодически сталкиваетесь.
Как это работает? Вы выбираете площадку, где работает значимое для вас бизнес-приложение, которое чаще всего принимает на себя обращения клиентов с различных филиалов. Провайдер устанавливает 1-2 физических SD-WAN Edges, как пример — разворачивает ВМ у клиента в облаке и проводит весь этап тестирования. Для тестов используется ПМИ (Программа и методики тестирования), а также документация, где пошагово в виде лабораторной работы описано, какие тесты можно запускать, какие настройки необходимо выполнить, что нужно проверять и какие результаты должны получить клиенты. Это даст понимание, подходит ли вашей компании решение SD-WAN.
Таблица. Варианты тестирования Cloud SD-WAN.
Если перед вами стоит задача построить защищенную филиальную сеть с централизованным управлением, сохранив качество передачи данных, рекомендуем попробовать Cloud SD-WAN. В рамках 30-дневного пилота специалисты #CloudMTS подберут оптимальную конфигурацию, предоставят VMware SD-WAN Edge и сопроводят в течение всего процесса пилотирования. Оставить заявку на подключение можно на странице сервиса.
Ранее в нашем блоге мы подробно разбирали особенности и возможности VMware SD-WAN, а также тестировали решение. Сегодня мы хотим поделиться реальным кейсом внедрения сервиса.
Речь пойдет о компании Business Car — владельце крупнейшей сети официальных дилерских центров по продаже и обслуживанию автомобилей Toyota и Lexus в Европе. Здесь будет все — устаревшие технологии, неоднородная конфигурация инфраструктуры, ограниченный бюджет и другие
С чем пришел клиент
Чтобы вы представляли масштаб задач. Группа компаний «БИЗНЕС КАР» представлена на российском автомобильном рынке более 30 лет. В структуру группы входят 23 дилерских центра в Москве, регионах России и Казахстане. Основные направления деятельности — продажа новых автомобилей и авто с пробегом, сервисное обслуживание, лизинг, страховые и кредитные программы, корпоративные и дипломатические продажи.
Остановимся на истории с распределенными офисами продаж в Москве. Изначально это 5 точек и 2 дата-центра с устаревшим парком сетевого оборудования на каждой площадке. К одному ЦОДу подключались внешние каналы связи, в том числе региональные филиалы, во втором дата-центре была развернута база 1С. Московским и другим удаленным офисам был нужен круглосуточный доступ к сервису 1С. Сеть клиента была непрозрачна (SD-WAN же еще не внедрили!) и отслеживать источники проблем было
В переговорах рождается истина
Обсуждая спецификацию, мы предложили несколько вариантов реализации проекта:
- установка оборудования SD-WAN рядом с текущим сетевым оборудованием заказчика;
- полная его замена на SD-WAN.
С учетом опыта архитекторов #CloudMTS и VMware по проектированию, развертыванию и поддержке SD-WAN инсталляций любых масштабов и сложности, а также пожеланий заказчика, было принято решение использовать схему на оборудовании провайдера. Мы полностью проработали сетевую топологию, подготовили документ, который включал в себя этапы аудита текущей инфраструктуры заказчика, рекомендации по корректной сетевой схеме, движению потоков трафика и необходимым настройкам на оборудовании.
После этапа проработки перешли к этапу внедрения. Он начался спустя месяц после заказа оборудования (а это довольно быстро). На этом этапе мы провели анализ конфигурации на старом оборудовании, адаптировали ее под новое железо и внесли необходимые изменения, чтобы получить корректную схему. Все эти работы полностью взяла на себя команда #CloudMTS. На основе анализа собранной информации, а также понимая конечного состояния сети после миграции, заказчику было предложено техническое решение. План миграции предполагал поэтапный переход с текущей Legacy-инфраструктуры на SD-WAN, при этом такая гибридная сеть должна была продолжить работу в бесшовном режиме для пользователей и приложений. Для эффективной утилизации ресурсов часть заменяемого оборудования перенесли на уровень локальной сети, уступив каналообразующую роль современным SD-WAN-маршрутизаторам. Для увеличения отказоустойчивости центральной точки обмена трафиком предложили парную схему установки маршрутизаторов с горячим резервированием, а также виртуальный маршрутизатор в ЦОД, где располагались приложения.
Пара слов о трафике
Наверняка вы и так знаете, каким может быть сетевой трафик, но на всякий случай напомним. Когда вы заходите в интернет, чтобы заказать доставку, посмотреть видео с котиками — это некритичный трафик. Но если речь касается VOIP, подключения клиентов к сервису 1С, от доступности которого зависит работа всей компании, — такой трафик смело претендует на звание «Critical».
В случае с Business Car провайдерские VPN-каналы связывали SD-WAN-фабрику между собой, но возникала проблема — клиентский менее значимый интернет-трафик вытеснял все важные бизнес-сервисы. Это приводило к тому, что каналы были постоянно перегружены, а приоритетные сервисы деградировали. С помощью мониторинга SD-WAN по источнику трафика мы увидели хост, который потреблял очень много трафика на upload. Спойлер — это был сервер видеонаблюдения. Проблему удалось вовремя обнаружить и дать рекомендации по ее устранению.
Но это ещё не все, была и другая проблема. Обращения, направленные в сторону 1С-облака, шифровались не полностью. Такая картина нарушала правила безопасности компании. После внедрения SD-WAN шифрование обеспечивается SD-WAN-тоннелем поверх существующего канала связи.
Почему провайдерское решение, а не собственное
Если клиент привык потреблять сервис по арендной модели, позже он вряд ли изменит своим привычкам. У Business Car уже был опыт использования провайдерских услуг. К тому же хотелось избавиться от устаревших маршрутизаторов, которые все еще числились на балансе. Чем позже происходит замена, тем больше появляется проблем. В отсутствие поддержки и свежих версий ПО увеличиваются риски безопасности. Возросшие требования к пропускной способности делают такое оборудование бутылочным горлышком всей сети либо ее части.
Со старым сетевым оборудованием на руках у клиента было два пути:
- уйти в закупку (тут вопрос усложнялся длительными этапами согласования выбора поставщиков);
- использовать сервис провайдера.
Поскольку Business Car не хватало экспертных кадров, а любой крупный проект по обновлению оборудования требует больших инженерных ресурсов на этапе внедрения, решили пойти наиболее простым путем — выбрать провайдерское решение по арендной модели предоставления услуги.
От Legacy к Software Driven
Любой комплексный проект, связанный с SD-WAN, подразумевает не только обновление парка сетевых устройств и модернизацию сети, но и смену подхода к ее эксплуатации. Например, построение оверлейной сети даже поверх существующего MPLS VPN позволит скрыть трафик от underlay-уровня, зашифровать его, а также повысить прозрачность сети.
Большинство проектов имеют свой жизненный цикл, и внедрение программно-определяемых технологий не исключение. Такие понятия, как Day 0/Day 1/Day 2 operations, также можно применить и в отношении миграции на SD-WAN с Legacy инфраструктуры. В этом проекте мы выделяем фазы планирования (дизайна), интеграции (развертывания) и постинсталляционный тюнинг. Рассмотрим их подробнее.
Планирование
Когда определены цели проекта, желаемое конечное состояние сети в результате миграции на SD-WAN и перечень площадок, наступает фаза планирования. Кульминация этого этапа – готовое техническое решение, на основе которого и будет производиться внедрение.
Итак, какие данные мы собрали и как потом их использовали.
Прежде всего мы собрали информацию о каналах передачи данных (их количество, тип и пропускная способность), проанализировали паттерны трафика в мигрируемой сети, нагрузку на каналы связи и как площадки «общаются» между собой. После этого нам предстояло изучить конфигурацию существующих продуктивных маршрутизаторов, адаптировать ее к новому решению, а также оптимизировать, удалив ненужное и сократив этим размер конфигурации.
С топологической точки зрения сеть представляла собой Full Mesh с выделением таких ролей, как стандартный филиал и ЦОД. ЦОДы имели собственный выход в Интернет, а площадки, объединенные провайдерским VPN (и в контексте SD-WAN не имеет значения L2 это или L3) получали доступ к префиксам друг друга, а также к сетям ЦОДов и Интернет. Для распространения маршрутной информации использовался классический IGP-протокол.
Для снижения времени простоя сети при миграции и упрощения процесса реализации в целом проект был разбит на несколько этапов, подразумевающих переход на SD-WAN группами площадок. Также был составлен адресный план, описывающий линковые подсети, подсети филиалов и другие соглашения об адресации.
Развертывание
При модернизации существующей сети важно помнить о минимизации простоя сервисов и не допустить деградации того, что не должно быть затронуто миграцией. Эта простая истина работает и в случае с SD-WAN. Пока сеть полностью не переведена на SD-WAN, она существует в двух плоскостях, взаимодействие которых никак не должно отразиться на пользователях.
Создание и настройка SD-WAN фабрики
SD-WAN от VMware начинается с Оркестратора. Оркестратор предоставляет доступ к тенанту, в котором создается и эксплуатируется наложенная сеть.
На этапе планирования мы собрали всю необходимую информацию, на основе которой были созданы площадки, конфигурационные профили для каждого типа площадок и выполнены специфичные настройки для каждой площадки. Были перенесены либо адаптированы к VMware SD-WAN следующие категории конфигурации:
- политики управления трафиком и качества обслуживания;
- политики безопасности (как глобальные, так и локальные),
- адресация и VLAN;
- настройки логирования, служебных протоколов и прочее.
Филиалы условно были разделены на две группы – с частичным сохранением текущего оборудования и с полным переносом его функционала на SD-WAN Edge. Это позволило гибко разделить конфигурацию площадок – на те, где пользовательские VLAN терминируются на SD-WAN Edge и где Edge является пограничным маршрутизатором, а VLAN терминируются на нижестоящем оборудовании. Такой подход позволил не только гибко настроить филиалы, но и эффективно использовать парк существующего сетевого оборудования.
Активация площадок
Как было упомянуто ранее, активация площадок производилась в несколько этапов. На первом этапе были мигрированы филиалы, где SD-WAN Edge является не только пограничным маршрутизатором, но и точкой терминации пользовательских VLAN. Благодаря проработке архитектуры и корректной настройке всех элементов сети после развертывания площадок первого этапа у заказчика появились филиалы, связанные SD-WAN тоннелями, построенными поверх существующего транспорта. В то же время остальная часть сети работала по старым правилам и взаимодействовала с небольшим «островком» SD-WAN незаметно для пользователей.
Архитектура VMware SD-WAN предусматривает инструменты и технологии для взаимодействия с non-SD-WAN сетями в процессе миграции и позволяет совмещать overlay и underlay маршрутизацию. Если изобразить такую площадку в соответствии с рекомендациями вендора, то получится следующая схема размещения, за исключением того, что канал Интернет не подключается напрямую, а доступен через центральную площадку (ЦОД), так как основными каналами в филиалах являются MPLS VPN.
Референсная модель размещения SD-WAN Edge c гибридным подключением и L2 коммутатором.
Вторым этапом была запланирована миграция филиалов, где SD-WAN Edge выступал в роли пограничного маршрутизатора и как nexthop для коммутатора, терминирующего пользовательские broadcast-домены. В качестве промежуточного этапа можно отметить активацию виртуального SD-WAN Edge на площадке одного из двух ЦОД, в котором обрабатывается трафик приложений, в том числе 1С.
Схема включения площадки отображена на рисунке ниже, при этом канал Интернет не подключается напрямую, а доступен через центральную площадку (ЦОД), так как основными каналами в филиалах являются MPLS VPN.
Референсная модель размещения SD-WAN Edge c гибридным подключением и L3 коммутатором.
Последней из площадок мигрировали основной ЦОД, и его конфигурация вызывает наибольший интерес. На этой площадке были установлены два высокопроизводительных устройства, объединенных в отказоустойчивый кластер по технологии High Availability Pair. Отказоустойчивая пара выступает в роли пограничного маршрутизатора, подключенного к L3-коммутатору, отделяя тем самым домен SD-WAN от остальной части сети. HA Pair позволяет ведомому устройству перенять на себя роль ведущего не более чем за секунду, при этом часть сессий приложений сохраняется, а конфигурация обоих устройств всегда одинаковая. Уникальной особенностью также является то, что и к ведущему, и к ведомому (Active/Standby) могут быть подключены каналы связи от разных провайдеров, и трафик может передаваться по HA Link каналу между двумя устройствами (bypass). Также основной ЦОД является демаркатором VPN и Интернет, и благодаря встроенным механизмам управления трафиком филиалы получают доступ в Интернет через наложенную сеть.
Для данной реализации вендор в качестве best practice рекомендует следующую схему подключения (см ниже). Следует отметить, что референсная модель по тем или иным причинам может быть избыточна. Например, L3 коммутатор может быть один, но стекируемый, и доступ в Интернет может осуществляться через него же, только в другом VLAN, нежели пользовательский трафик, если мы имеем схему, при которой площадка выполняет не только роль ЦОД или агрегатора трафика, но берет на себя обработку пользовательского трафика терминируемых локально сетей.
Референсная модель размещения SD-WAN Edge c гибридным подключением, HA Pair и L3 коммутатором.
Изменения в маршрутизации после миграции
Здесь хотелось бы упомянуть не столько о глобальных преимуществах (например, network visibility), сколько о более специфических вещах, таких как обмен маршрутной информацией. В традиционных корпоративных сетях передачи данных маршрутизация осуществляется IGP-протоколами (за исключением небольших инсталляций, где допустима статика), которые требуют ручной настройки самих процессов, фильтрации маршрутов, контроль за редистрибуцией маршрутов и настройками смежности. К тому же, если речь идет о маршрутизации внутри тоннелей, эти тоннели надо сначала настроить, что существенно усложняет администрирование всей маршрутизации сети заказчика.
В VMware SD-WAN тоннели строятся автоматически в соответствии с заданной на уровне L3 сегмента (расширенный аналог VRF в масштабах всей SD-WAN фабрики) политикой, а маршрутизация централизованная и распределенная. Это значит, что не нужно строить пиринговые сессии с соседями, маршруты с каждого SD-WAN Edge передаются на SD-WAN Gateway (VCG), который распределяет их по другим узлам, если это допустимо (есть SD-WAN тоннель до первоначального источника маршрута). Анонсировать тот или иной маршрут решает администратор, отметив соответствующий чек-бокс в настройках интерфейса. Редистрибуция из overlay в underlay происходит также автоматически, а Оркестратор позволяет визуализировать всю таблицу маршрутизации вашей фабрики.
Схематичное изображение топологий SD-WAN.
После реализации проекта
В рамках реализации проекта Cloud SD-WAN в соответствии с техническим решением мы провели итоговый аудит и дали рекомендации по дальнейшему тюнингу SD-WAN фабрики. Так, в случае наличия двух георазнесенных площадок и независимыми Интернет-каналами, их также можно соединить SD-WAN тоннелем, но использовать его только тогда, когда недоступны каналы через MPLS VPN (если они основные). Помимо этого, для снижения нагрузки на основной канал Интернет типовой рекомендацией является подключения к MPLS only сайту выделенного канала Интернет для создания политики управления трафиком, которая будет помогать разбалансировать конкретный трафик. Приоритетный трафик продолжит маршрутизироваться через центральную точку, а низкоприоритетный и потребляющий широкую полосу трафику будет передаваться через Интернет. Кроме этого, через Интернет-каналы также будут строиться SD-WAN тоннели, повышая отказоусточивость площадок к возможной потере связности с SD-WAN фабрикой и бизнес-приложениями из-за отказа каналов связи.
Изменена логика настройки маршрута по умолчанию. В отличие от традиционных сетей теперь на площадке не нужно принимать дефолт, достаточно объявить один из узлов как Backhaul Hub — это позволит создавать гранулярные правила, передавая через такой Hub только трафик определенных приложений с определенной адресацией или иными заданными паттернами.
Результаты использования Cloud SD-WAN
- Решение SD-WAN внедрили в пяти точках продаж и в двух дата-центрах в Москве.
- Проверили полный рефакторинг организации связности между площадками — помогло повысить надежность сети.
- Настроили приоритизацию трафика между SD-WAN Edges.
- Организовали шифрованные VPN-каналы.
- Убрали из схемы старое оборудование (там где это было возможно).
- Пересмотрели схему подключения оборудования файервола в сегменте облака 1С.
- Изменили схемы подключения, чтобы трафик корректно проходил через SD-WAN Edges и дальше направлялся на файерволл для дополнительной фильтрации.
- Создали унифицированные политики безопасности для филиалов.
- Упростили процесс настройки и управления маршрутизацией.
- Повысили прозрачность сети за счет встроенных в SD-WAN технологий телеметрии.
- После внедрения SD-WAN оптимизировали передачу трафика для утилизации дополнительных каналов.
Помимо прочего, клиент пользуется услугами передачи данных — интернет, VPN-каналы — получая сервис в едином окне. Business Car использует смешанные гибридные каналы как от МТС, так и от другого поставщика. Но поскольку большая их часть приходится на МТС — клиент получает максимум преимуществ, потребляя сервис по провайдерской схеме.
На сегодняшний день клиент уже больше года пользуется решением Cloud SD-WAN. Сеть заказчика работает стабильно без перебоев, несмотря на то, что каналы не расширялись, при этом они не рассчитаны на используемый объем трафика. За счет правильного распределения нагрузки проблема была решена. К тому же удалось снизить затраты и сократить время на эксплуатацию инфраструктуры.
Cloud SD-WAN: распределение зон ответственности
Фраза про ответственность в услугах нередко вызывает страх и опасение со стороны клиента. Заказчики не до конца понимают, в какой момент и на чьей стороне мяч.
Рассмотрим на примере Cloud SD-WAN. Мы как провайдер отвечаем за работу
SD-WAN-фабрики, в частности, за работу и доступность VCO (оркестратора, который находится в облаке), за элементы VCG (которые являются распределенными шлюзами и хранят в себе таблицу маршрутизации SD-WAN-фабрики), а также за работу программного обеспечения и функционирование физического оборудования SD-WAN Edges на локациях заказчика. К сказанному — проводим консультации, отвечаем на вопросы клиентов, связанные с работоспособностью программной и аппаратной части комплекса. В случае выхода из строя оборудования выполняем замену.
Как протестировать Cloud SD-WAN
Функционал Cloud SD-WAN можно протестировать двумя способами: упрощенным или более комплексным.
Упрощенное тестирование
Если вы хотите легко и быстро оценить возможности сервис без существенных работ на своей рабочей сети, проверить функционал систем мониторинга, управления, траблшутинга— выбирайте упрощенный вариант тестирования. Такой формат подойдет и тем, кто в целом понимает, зачем нужен SD-WAN, либо если у вас небольшое количество филиалов и вы сможете «попробовать» Оркестратор и виртуальную SD-WAN фабрику online.
В таком сценарии мы предоставляем доступ к выделенному аккаунту (тенанту) на оркестраторе и сконфигурированным ресурсам облака, где уже развернуты виртуальные узлы SD-WAN Edge. Вы получаете ссылку на образ виртуального Edge, который можно развернуть у себя в офисе и проверяете функционал, который ничем не отличается от реального SD-WAN. Вы сможете выполнить нагрузочное тестирование, проверить, как работает сбор метрик, приоритезация трафика, переключение между каналами, за исключением того, что здесь не получится использовать физическое оборудование.
Комплексное тестирование
Если вы хотите понять, как применять решение SD-WAN в рамках вашей инфраструктуры, вы крупный заказчик и для вас важно проверить аппаратную часть — используйте комплексный подход. Так вы сможете определить, какие использовать порты, модули, как будет вести себя трафик, следуя с физического рабочего места в сеть. Комплексное тестирование предполагает установку физического оборудования на стороне заказчика. Для такого формата рекомендуем выбирать площадки, на которых есть «узкие» места, либо те, где проще обнаружить или имитировать проблему, с которой вы периодически сталкиваетесь.
Как это работает? Вы выбираете площадку, где работает значимое для вас бизнес-приложение, которое чаще всего принимает на себя обращения клиентов с различных филиалов. Провайдер устанавливает 1-2 физических SD-WAN Edges, как пример — разворачивает ВМ у клиента в облаке и проводит весь этап тестирования. Для тестов используется ПМИ (Программа и методики тестирования), а также документация, где пошагово в виде лабораторной работы описано, какие тесты можно запускать, какие настройки необходимо выполнить, что нужно проверять и какие результаты должны получить клиенты. Это даст понимание, подходит ли вашей компании решение SD-WAN.
Таблица. Варианты тестирования Cloud SD-WAN.
Если перед вами стоит задача построить защищенную филиальную сеть с централизованным управлением, сохранив качество передачи данных, рекомендуем попробовать Cloud SD-WAN. В рамках 30-дневного пилота специалисты #CloudMTS подберут оптимальную конфигурацию, предоставят VMware SD-WAN Edge и сопроводят в течение всего процесса пилотирования. Оставить заявку на подключение можно на странице сервиса.
