Согласно недавнему исследованию Flexera, 92% предприятий имеют стратегию мультиоблачных вычислений. Однако, по данным Cisco, сетевые команды с трудом поспевают за темпами изменений в облаке, причем 73% из них тратят больше времени на поддержание статус-кво, чем на развертывание мультиоблачных решений. Джубил Мэтью, технический инженер компании LiveAction, обсуждает на портале NetworkComputing, как можно обеспечить видимость в мультиоблачных развертываниях и преодолеть некоторые его ключевые проблемы, и рассматривает шесть сценариев мониторинга, включающих видимость облачной сети, гибридные ИТ, реагирование на инциденты безопасности, расход средств, миграцию в облако и контроль видимости приложений.

Во-первых, давайте начнем с некоторых проблем публичного облака. Сетевым инженерам традиционно трудно визуализировать, как трафик проходит через облачные сети. Это нелегко отобразить в типичной ментальной модели. Не хватает сквозной видимости в едином представлении, чтобы понять трафик приложений из локальной сети в облако и наоборот. Например, сетевым инженерам необходимо понимать, как экземпляры облачных структур взаимодействуют друг с другом в одной и той же подсети. Есть и другие проблемы, связанные с трафиком Inter-Availability Zone, мешающие понять, как внутреннее приложение взаимодействует с облачными службами баз данных в другой зоне доступности.

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

Давайте рассмотрим некоторые сценарии более подробно.

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

2) Гибридные ИТ. Сложно обеспечить сквозной путь для приложения, которое переходит из локальной сети в облако и наоборот. Пользователям нужно решение, которое позволяет анализировать сквозной путь приложений из локальной сети в облако на одном экране и при этом может сортировать проблемы и фокусировать усилия по устранению неполадок онпремис, в облаке или между ними. Решения для мониторинга, обеспечивающие hop-by-hop-анализ сквозных приложений для изучения пути, очень важны, наряду с анализом KPI, таких как задержка приложений и сети, загруженность, потеря пакетов, конфигурация QoS и производительность VoIP. Решение также должно поддерживать операции «второго дня», такие как устранение неполадок сети и мониторинг поведения приложений.

3) Реагирование на инциденты безопасности. Часто бывает неясно, какой трафик принимается или отклоняется из-за несоответствия ментальной модели. Пользователям требуется решение, которое может определить происхождение и назначение трафика в VPC и между ними и визуально определить, принимается или отклоняется определенный трафик. Это позволяет менеджерам сетевых операций анализировать свои определения безопасности сети с точки зрения необходимого и несанкционированного трафика и получать отчеты и предупреждения о нежелательных приложениях, которые могут проходить через сеть. После обнаружения вторжения сетевым администраторам потребуется запись активности сетевых пакетов для определения следов и масштабов вторжения. Решения мониторинга, которые могут обеспечить дополнительную возможность захвата и хранения каждого пакета, очень полезны. Вооружившись данными о пакетах, администраторы могут реагировать быстро и уверенно.

4) Расходование средств. Отсутствие возможности нарезать сетевой трафик в n-мерном масштабе для глубокого анализа выливается в финансовые и временные затраты. Пользователи должны рассмотреть решение, которое измеряет использование полосы пропускания приложениями, сервисами и интернет-шлюзами и может вычислять базовые показатели и тенденции. Это позволяет службам сетевых операций управлять типами облачных сервисов (почтовые серверы, решения для конференций и т. д.), которые используют бóльшую часть пропускной способности облака. Затем можно проводить сравнение с наименее используемыми службами и перепроектировать сервисные решения на основе загруженности. Это позволяет ИТ-командам измерять базовые показатели производительности и использования облачных приложений и сервисов и сопоставлять с тенденциями во времени для облегчения планирования и оптимизации ресурсов приложений и сервисов.

5) Облачная миграция. Отсутствие понимания KPI до и после миграции, исторических базовых показателей и возможности их точного измерения влияет на миграцию в облако. Пользователям требуется решение, которое обеспечивает видимость приложений и сервисов, измеряет использование полосы пропускания и базовые показатели производительности приложений до развертывания, а также проверяет пропускную способность и производительность после развертывания. Миграция в облако сильно зависит от потребностей и целей компании. Независимо от того, мигрируют ли ограниченные части корпоративных систем (например, несколько конкретных баз данных или серверов), весь стек приложений или дата-центр, команды NetOps должны иметь четкое представление о KPI до и после миграции. Ключом к пониманию этого являются решения сетевого мониторинга, которые обеспечивают возможность точного измерения исторических базовых показателей и изменений с течением времени.

6) Контроль видимости приложений. Перенос приложений из базовой сети в облако часто является сложной задачей. Командам NetOps необходимо глубокое понимание текущего состояния приложения перед проектированием или перепроектированием сети, а также необходимо подтверждение того, что после миграции все будет работать так, как задумано. Решения сетевого мониторинга, обеспечивающие видимость приложений и сервисов, позволяют командам измерять использование полосы пропускания до развертывания (пока приложение или сервис еще находится онпремис) и используют визуализацию топологии для определения путей приложения, чтобы помочь эффективно спланировать миграцию.

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