Введение
В последние годы доля облачных сервисов в отраслях промышленности Китая растет. Технологические компании воспользовались возможностью нового витка технологической революции, активно проводили цифровую трансформацию, увеличили исследования и применение новых технологий, таких как облачные вычисления, большие данные, искусственный интеллект, блокчейн и Интернет вещей, и улучшили свои научно-технические возможности обслуживания. С непрерывным развитием облачных и виртуализационных технологий все больше и больше прикладных систем в центрах обработки данных мигрируют из исходного физического кампуса на облачную платформу, а трафик «восток-запад» в облачной среде центров обработки данных значительно растет. Однако традиционная физическая сеть сбора трафика не может напрямую собирать трафик «восток-запад» в облачной среде, в результате чего бизнес-трафик в облачной среде становится первой областью. Стало неизбежной тенденцией реализовывать извлечение данных трафика «восток-запад» в облачной среде. Внедрение новой технологии сбора трафика «восток-запад» в облачной среде делает прикладную систему, развернутую в облачной среде, также идеальной поддержкой мониторинга, и при возникновении проблем и сбоев анализ захвата пакетов может использоваться для анализа проблемы и отслеживания потока данных.
1. Трафик «восток-запад» облачной среды не может быть собран напрямую, поэтому система приложений в облачной среде не может развернуть обнаружение мониторинга на основе потока бизнес-данных в реальном времени, а персонал по эксплуатации и обслуживанию не может своевременно обнаружить реальную работу системы приложений в облачной среде, что дает определенные скрытые преимущества для здоровой и стабильной работы системы приложений в облачной среде.
2. Восточный и западный трафик в облачной среде не может быть собран напрямую, что делает невозможным прямое извлечение пакетов данных для анализа при возникновении проблем в бизнес-приложениях в облачной среде, что создает определенные трудности при локализации неисправностей.
3. С учетом все более строгих требований к сетевой безопасности и различных аудитов, таких как мониторинг транзакций приложений BPC, система обнаружения вторжений IDS, система аудита регистрации электронной почты и обслуживания клиентов, спрос на сбор трафика «восток-запад» в облачной среде также становится все более и более насущным. На основе вышеприведенного анализа стало неизбежной тенденцией реализовать извлечение данных трафика «восток-запад» в облачной среде и внедрить новую технологию сбора трафика «восток-запад» в облачной среде, чтобы прикладная система, развернутая в облачной среде, также могла иметь идеальную поддержку мониторинга. При возникновении проблем и сбоев можно использовать анализ захвата пакетов для анализа проблемы и отслеживания потока данных. Реализация извлечения и анализа трафика «восток-запад» в облачной среде является мощным магическим оружием для обеспечения стабильной работы прикладных систем, развернутых в облачной среде.
Ключевые показатели для захвата трафика виртуальной сети
1. Производительность захвата сетевого трафика
Трафик «восток-запад» составляет более половины трафика центра обработки данных, и для реализации полного сбора данных необходима высокопроизводительная технология сбора данных. В то же время сбора данных необходимо выполнить другие задачи предварительной обработки, такие как дедупликация, усечение и десенсибилизация для различных служб, что еще больше повышает требования к производительности.
2. Накладные расходы ресурсов
Большинство методов сбора трафика «восток-запад» должны занимать вычислительные, сетевые ресурсы и ресурсы хранения, которые можно было бы применить к сервису. Помимо того, чтобы потреблять эти ресурсы как можно меньше, все еще необходимо учитывать накладные расходы на реализацию управления технологией сбора данных. Особенно, когда масштаб узлов расширяется, если стоимость управления также показывает линейную тенденцию к росту.
3. Уровень вторжения
Текущие общие технологии приобретения часто требуют добавления дополнительной конфигурации политики приобретения на гипервизор или связанные компоненты. Помимо потенциальных конфликтов с бизнес-политиками, эти политики часто еще больше увеличивают нагрузку на гипервизор или другие бизнес-компоненты и влияют на SLA обслуживания.
Из вышеприведенного описания видно, что захват трафика в облачной среде должен быть сосредоточен на захвате трафика «восток-запад» между виртуальными машинами и проблемах производительности. В то же время, ввиду динамических характеристик облачной платформы, сбор трафика в облачной среде должен выйти за рамки существующего режима традиционного зеркала коммутатора и реализовать гибкое и автоматическое развертывание сбора и мониторинга, чтобы соответствовать цели автоматической эксплуатации и обслуживания облачной сети. Сбор трафика в облачной среде должен достигать следующих целей:
1) Реализовать функцию захвата трафика «восток-запад» между виртуальными машинами.
2) Захват развертывается на вычислительном узле, а распределенная архитектура сбора используется для избежания проблем с производительностью и стабильностью, вызванных зеркалом коммутатора.
3) Он может динамически определять изменения ресурсов виртуальной машины в облачной среде, а стратегия сбора может автоматически корректироваться в соответствии с изменениями ресурсов виртуальной машины.
4) Инструмент захвата должен иметь механизм защиты от перегрузки, чтобы минимизировать воздействие на сервер.
5) Сам инструмент захвата имеет функцию оптимизации трафика
6) Платформа захвата может отслеживать собранный трафик виртуальной машины.
Выбор режима захвата трафика виртуальной машины в облачной среде
Для захвата трафика виртуальной машины в облачной среде необходимо развернуть зонд сбора на вычислительном узле. В зависимости от расположения точки сбора, которая может быть развернута на вычислительном узле, режим захвата трафика виртуальной машины в облачной среде можно разделить на три режима:Режим агента, Режим виртуальной машиныиРежим хоста.
Режим виртуальной машины: унифицированная виртуальная машина захвата устанавливается на каждом физическом хосте в облачной среде, а программный зонд захвата развертывается на виртуальной машине захвата. Трафик хоста зеркалируется на виртуальную машину захвата путем зеркалирования трафика виртуальной сетевой карты на виртуальном коммутаторе, а затем виртуальная машина захвата передается на традиционную физическую платформу захвата трафика через выделенную сетевую карту. А затем распределяется на каждую платформу мониторинга и анализа. Преимущество заключается в том, что обходное зеркалирование программного коммутатора, которое не имеет вторжения в существующую сетевую карту и виртуальную машину компании, также может реализовать восприятие изменений виртуальной машины и автоматическую миграцию политик с помощью определенных средств. Недостатком является то, что невозможно добиться механизма защиты от перегрузки путем пассивного получения трафика виртуальной машиной, а размер трафика, который может быть зеркалирован, определяется производительностью виртуального коммутатора, что оказывает определенное влияние на стабильность виртуального коммутатора. В среде KVM облачная платформа должна единообразно выдавать таблицу потоков изображений, что сложно в управлении и обслуживании. Особенно в случае отказа хост-машины виртуальная машина захвата совпадает с бизнес-виртуальной машиной и также будет мигрировать на другие хосты с другими виртуальными машинами.
Режим агента: Установите захватывающий программный зонд (агент-агент) на каждой виртуальной машине, которой необходимо захватывать трафик в облачной среде, и извлекайте восточный и западный трафик облачной среды с помощью программного обеспечения агента-агента и распределяйте его по каждой аналитической платформе. Преимущества заключаются в том, что он не зависит от платформы виртуализации, не влияет на производительность виртуального коммутатора, может мигрировать с виртуальной машиной и может выполнять фильтрацию трафика. Недостатки заключаются в том, что необходимо управлять слишком большим количеством агентов, и нельзя исключить влияние самого агента при возникновении сбоя. Существующая производственная сетевая карта должна быть общей для распределения трафика, что может повлиять на взаимодействие бизнеса.
Режим хоста: развертывая независимый сбор мягкого зонда на каждом физическом хосте в облачной среде, он работает в режиме процесса на хосте и передает захваченный трафик на традиционную физическую платформу захвата трафика. Преимуществами являются полный механизм обхода, отсутствие вторжения в виртуальную машину, сетевую карту компании и коммутатор виртуальной машины, простой метод захвата, удобное управление, отсутствие необходимости поддерживать независимую виртуальную машину, легкое и мягкое получение зонда может обеспечить защиту от перегрузки. Как процесс хоста, он может контролировать ресурсы и производительность хоста и виртуальной машины, чтобы руководить развертыванием стратегии зеркалирования. Недостатками являются то, что он должен потреблять определенное количество ресурсов хоста, и необходимо обращать внимание на влияние на производительность. Кроме того, некоторые виртуальные платформы могут не поддерживать развертывание зондов программного обеспечения захвата на хосте.
Исходя из текущей ситуации в отрасли, режим виртуальной машины имеет приложения в публичном облаке, а режим агента и режим хоста имеют некоторых пользователей в частном облаке.
Время публикации: 06.11.2024
