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