Мониторинг сети в гибридном мире: разговор с Крисом О'Брайеном из SolarWinds

Опубликовано: 15 Марта, 2023
Мониторинг сети в гибридном мире: разговор с Крисом О'Брайеном из SolarWinds

Мониторинг сети и устранение неполадок значительно изменились по сравнению со старыми днями, когда я прокручивал бесконечные события в файлах журналов или подключал Fluke к кабелю. Современные бизнес-сети часто используют гибридный подход, сочетающий локальные серверы с онлайн-приложениями и услугами, предоставляемыми из облака. А в связи с быстро меняющимися бизнес-требованиями и потребностью бизнеса в гибкости программно-определяемые сети (SDN) еще больше преобразовывают корпоративные сети, отделяя физическую сеть от ее логического наложения. Как можно лучше контролировать современные бизнес-сети, чтобы поддерживать оптимальную производительность и иметь возможность решать проблемы, когда они возникают? И куда движется сетевой мониторинг в будущем, поскольку ИТ-инфраструктура продолжает развиваться? Недавно я говорил об этом с Крисом О'Брайеном, менеджером по продукту SolarWinds Network Performance Monitor (NPM). Крис большую часть своей карьеры работал сетевым инженером. Он присоединился к SolarWinds в 2014 году, чтобы помочь построить будущее сетевого мониторинга.

МИТЧ: Спасибо, Крис, за то, что согласился дать мне интервью о вашей линейке продуктов для управления сетью там, в SolarWinds.

КРИС: Конечно. Я люблю говорить о мониторинге сети!

МИТЧ: Давайте начнем с чего-то общего. В сфере сетевого мониторинга много компаний. Не могли бы вы дать нам краткое представление о SolarWinds и о том, чем ваша компания отличается от других?

Изображение 4335
Шаттерсток

КРИС: Компания SolarWinds была основана в 1999 году двумя сетевыми инженерами, которые искали лучшие инструменты для выполнения своей работы, поэтому они их и создали. Они сосредоточились на создании простых, мощных инструментов, которые просто работали. Оказывается, это хорошая формула. Многие люди хотели эти инструменты, поэтому они создали SolarWinds.

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

МИТЧ: Из моих бесед с ИТ-специалистами, работающими как в корпоративных средах, так и с поставщиками облачных услуг, следует, что в наши дни программно-определяемые сети (SDN) становятся все более и более популярными. Каков наилучший способ мониторинга сред SDN?

КРИС: SDN определенно становится все более популярным, и это очень здорово. Меня спрашивают о SDN практически на каждом мероприятии, которое я посещаю, и особенно на Cisco Live! В результате я могу поговорить со многими людьми о том, как продвигается их внедрение SDN, что работает, а что нет, как они контролируют сегодня и как они хотели бы контролировать завтра. Вы можете представить мониторинг SDN в двух уровнях. Первый уровень — это физический уровень. Это такие вещи, как порты, процессоры, оперативная память, блоки питания и сетевые кабели. Это не гламурно, но ваши кадры и пакеты все еще проходят через эти части оборудования, и это оборудование все еще должно работать. Второй уровень — это логический уровень; наложение SDN. SDN организует подключение в логические компоненты, которые определяют, что в этой физической сети является логически связанным. На языке Cisco ACI это такие вещи, как арендаторы, EPG, структуры и контракты.

SDN определенно становится все более популярным, и это очень интересно. Меня спрашивают о SDN практически на каждом мероприятии, которое я посещаю.

Оба эти слоя очень важны. Если один из них выходит из строя, соединение не работает. Вы хотите убедиться, что вы контролируете каждый из них. У нас есть клиенты NPM для первого уровня уже довольно давно. В нашем последнем выпуске NPM 12.4 мы добавили поддержку второго уровня с помощью Cisco ACI. Мы будем запрашивать контроллер SDN, который Cisco называет APIC, через API для обнаружения и мониторинга логического уровня. Независимо от того, какое решение для мониторинга у вас есть, убедитесь, что оба слоя покрыты!

МИТЧ: Использование общедоступных облачных сервисов и внедрение гибридных облачных инфраструктур внесло много изменений в то, как большинство предприятий и организаций «занимаются ИТ». Как использование облака меняет способ мониторинга сети?

Изображение 4336
КРИС: Да, большинству ИТ-отделов сегодня приходится иметь дело как с локальной, так и с облачной инфраструктурой. По своей природе у вас меньше доступа и контроля над облачной инфраструктурой. Это и хорошо, и плохо. Если инфраструктура работает хорошо без вашего постоянного внимания, это здорово. Когда это не так, вы немного застряли. Клиенты, с которыми я разговариваю, говорят мне, что они несут ответственность за свои ИТ-услуги независимо от того, где они находятся. Это делает отсутствие контроля и даже простой видимости довольно болезненным во время простоя.

Мы много думали об этом последние пару лет. И Amazon, и Azure имеют API-интерфейсы для запроса информации мониторинга об этой инфраструктуре. SolarWinds Server & Application Monitor (SAM) поддерживает оба варианта. Агенты по-прежнему могут работать в IaaS на основе виртуальных машин, которые можно комбинировать с данными API для получения более полной картины. Это большое изменение по сравнению с преимущественно основанным на WMI мониторингом машин Windows и SNMP для Linux/Unix.

Сетевая сторона представляет собой другую проблему. Облачные среды обеспечивают практически нулевую видимость сетевой инфраструктуры. Это верно для приложений SaaS, IaaS и поставщиков услуг, которые являются вашим транзитом к ним. Исторически сложилось так, что traceroute был основным инструментом для исследования такого рода проблем, но он не пропускается через большинство брандмауэров и не работает с многопутевым доступом, которым сегодня пользуется большая часть Интернета. Чтобы попытаться решить эту проблему, мы создали собственную реализацию, использующую пакетный драйвер для создания пакетов и прослушивания ответов. Это то, что обеспечивает NetPath, функцию в NPM, которая обнаруживает сетевой путь от вашего источника к любому сетевому назначению, локальному или удаленному, вашему оборудованию или чьему-либо еще, а также производительность по каждому узлу. Нам придется продолжать придумывать новые технологии, подобные этой, по мере изменения инфраструктуры.

МИТЧ: Есть ли какие-либо другие тенденции, которые вы видите в сетевом мониторинге?

КРИС: Да, два: ориентация на пользователя и опрос API.

Становится ясно, что наша отрасль была слишком сосредоточена на инфраструктуре и недостаточно на пользователе. Это естественно, ведь мы все гики. Мне так же, как и всем, нравится смотреть на лампочки на переключателе шасси весом 300 фунтов. Если честно, отчасти я стал инженером потому, что предпочитал взаимодействовать с компьютерами, а не с людьми. Тем не менее, целью сети является подключение пользователей к приложениям, и это должно стать большей частью того, как мы оцениваем, предоставляет ли сеть хороший сервис или нет. Есть много способов сделать это. Для этого не обязательно покупать продукт. Это в основном о мышлении. Что волнует ваших пользователей? Как для них выглядит хорошая производительность? Как выглядит плохая производительность? Как вы можете это измерить? S в SLA — это сервис, а не инфраструктура. Проверьте NetPath для хорошего примера, но опять же, это изменение мышления, а не переключение инструментов.

Становится ясно, что наша отрасль была слишком сосредоточена на инфраструктуре и недостаточно на пользователе. Это естественно, ведь мы все гики. Мне нравится смотреть на огни на 300-фунтовом переключателе шасси не меньше, чем кому-либо другому.

SNMP в течение долгого времени обеспечивал тонну информации о системах, но становится все более устаревшим. SNMP не особенно надежен, не подходит для отправки больших объемов данных и поддерживает очень ограниченное взаимодействие. NETCONF великолепен, но я просто не вижу его принятия среди производителей, чтобы он был настолько полезным, насколько мог бы быть. API начинает завоевывать популярность. За последние пару лет мы потратили больше времени на создание мониторинга на основе API, чем на SNMP. API реализуется менее последовательно и имеет тенденцию быть сложным. В конце концов, мы получаем данные везде, где только можем, думая о производительности, масштабируемости, безопасности и усилиях, требуемых от пользователя. Все чаще оказывается, что API — это правильный способ получения данных.

МИТЧ: Я заметил, что SolarWinds много говорит о понимании сети. Что это такое?

КРИС: Сети 10 или 15 лет назад состояли преимущественно из коммутаторов и маршрутизаторов. Если ваши коммутаторы и маршрутизаторы работали нормально, вы выполняли свою работу сетевого инженера. Сегодня это не так. Расширенные сетевые устройства, такие как брандмауэры, балансировщики нагрузки, оптимизаторы WAN и веб-прокси, часто управляются сетевой командой и предоставляют абсолютно важные сетевые службы. К сожалению, большинство инструментов, в том числе инструменты SolarWinds несколько лет назад, знают, как хорошо справляться только с мониторингом маршрутизаторов, коммутаторов и, в последнее время, беспроводного оборудования. Данные, необходимые для понимания работоспособности и производительности маршрутизатора или коммутатора, отличаются от данных, необходимых для понимания работоспособности и производительности брандмауэра или балансировщика нагрузки. Добавление одной или двух метрик не исправит этого. Вы должны посмотреть на роль, которую устройство играет в сети, и спросить, как вы можете измерить производительность устройств в этой роли. Network Insight стремится к глубокому мониторингу этих недостаточно представленных устройств с нуля. Это отнимает много времени, но мы уже выпустили Network Insight для F5 LTM и GTM, Network Insight для Cisco ASA и Network Insight для Cisco Nexus. У нас еще много работы!

МИТЧ: Многие сетевые и системные администраторы все еще борются с усталостью от предупреждений. Что можно сделать, чтобы облегчить это состояние?

Изображение 4337
Шаттерсток

КРИС: Первое, что нужно сделать, это сделать шаг назад и понять, что это человеческая проблема. Это проблема не только вашей команды или только ИТ-проблемы. Например, мы видим бдительную усталость в больницах. Даже когда человеческая жизнь находится в опасности, шумные оповещения могут вызвать усталость от оповещения, что заставит людей игнорировать сигналы тревоги. Если люди не могут заставить себя всегда обращать внимание на шумные оповещения, когда человеческая жизнь находится в опасности, вы можете поспорить, что они не могут сделать это для сетевой инфраструктуры! Вы должны повысить качество своих оповещений. На эту тему написано и представлено много отличных материалов, поэтому я предлагаю провести онлайн-исследование. Тем не менее, я могу предоставить основу, которая поможет вам решить проблему. Усталость от предупреждений вызвана слишком большим количеством предупреждений и предупреждений, которые трудно использовать. Слишком много оповещений можно исправить, отправляя только предупреждающие оповещения (никаких информационных оповещений!), сокращая количество систем, производящих непропорционально большое количество оповещений, и вводя избыточность, которая делает срочные оповещения менее вероятными. Оповещения, которые трудно использовать, можно исправить, добавив в них контекстную информацию, автоматизировав действия по исправлению и убедившись, что оповещения предоставляют четкое объяснение проблемы. Здесь можно еще многое сказать, но по мере того, как вы разбиваете проблему на более мелкие части, становится легче придумывать идеи по улучшению.

МИТЧ: Еще один вопрос к вам. Если бы вы могли дать людям один совет о том, как они могут улучшить свою стратегию мониторинга сети, что бы это было?

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

МИТЧ: Крис, большое спасибо, что уделили нам немного своего драгоценного времени!

КРИС: С удовольствием! Спасибо, что пригласили меня.