SD-WAN: От обещаний к реальности — что ИТ-команды должны знать

Нельзя отрицать, что рынок SD-WAN в центре внимания. После попадания в Яму разочарования на Hype Cycle Gartner 2017 года, SD-WAN вошел в Склон просвещения в 2018 году и теперь стабильно набирает импульс и адвокацию по мере приближения конца десятилетия.

Один из ключевых аргументов продажи SD-WAN — его гибкость: он не заставляет команды полагаться исключительно на прямой интернет-доступ (DIA) для всего трафика. Вместо этого организации могут сохранять MPLS-линии для задержко-чувствительных рабочих нагрузок — таких как VoIP — в то время как маршрутизируют массовый трафик через DIA-туннели, балансируя поддержку облака и SaaS миграций без жертвования производительностью для критических сервисов.

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

Большинство вендоров SD-WAN предлагают только базовые метрики производительности приложений, запускающие политику-базированные корректировки маршрутизации. Пока полезно для перенаправления трафика, эти метрики часто лишены гранулярной, hop-by-hop видимости, требуемой для истинного troubleshooting. Без более глубокого инсайта ИТ не может определить, исходит ли проблема с производительностью от удаленного AS, конкретного маршрутизатора или внешнего ISP.

Где SD-WAN недостает

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

Отсутствие «локальной» перспективы

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

Следовательно, команды редко получают истинный end-to-end вид, полагаясь исключительно на SD-WAN. Чтобы замостить этот разрыв, мониторинг должен выходить за пределы пользовательского трафика, чтобы охватывать базовые ссылки, поддерживающие ткань SD-WAN. Этот подход дает ИТ контекст, необходимый для проактивного ремедиации вместо ожидания разрешения ISP.

Минимум, ИТ требует инструмент, измеряющий производительность hop-by-hop по каждому пути, превращающий бинарный сигнал «хорошо/плохо» от контроллера SD-WAN в действенные данные. Не менее важна способность копать вглубь от филиальных файрволов в LAN, захватывая как WAN, так и LAN производительность с перспективы конечного пользователя.