Разработка гипермасштабируемой структуры сетевой аналитики

Разработка гипермасштабируемой структуры сетевой аналитики, которая называется Pаспределенная архитектура Flowmon (Flowmon Distributed Architecture), была одним из самых больших технологических вызовов, с которыми мы сталкивались до настоящего времени. Каковы были движущие силы разработки этого ресурсозатратного проекта?

Сценарий развертывания, в котором несколько коллекторов Flowmon могут действовать по отдельности в качестве устройств по обработке и хранению, управляемые одним или несколькими master units, требует создания обширных процессов организации и управления коммуникациями. В целом, теперь мы можем не только генерировать flow-поток в 100G сетях, но также можем обрабатывать и анализировать миллионы flow-потоков в секунду в режиме реального времени, что еще раз подтверждает нашу позицию мирового лидера по производительности на данном рынке.

Меня спрашивали, почему мы решили инвестировать в такой ресурсозатратный проект, когда в мире насчитывается только несколько организаций, производительность сетей которых достигает миллионов flow-потоков в секунду. Но действительно ли их так мало? И только ли для клиентов с несколькими соединениями в 100G требуется распределенная архитектура? Чтобы ответить, давайте рассмотрим некоторые из вопросов, которые убедили нас в разработке Распределенной архитектуры Flowmon.

Вопрос №1: Сегодня мы используем пакетный анализ для мониторинга только критически важных приложений. Благодаря flow-мониторингу мы можем расширить область задач для мониторинга. Но ваш самый мощный Flowmon Collector поддерживает 400 тыс. flow/сек. Наш единый центр обработки данных генерирует более миллиона в секунду.

Ответ: Наши коллекторы уже обновлены, с учетом современных технологических ограничений. Таким образом, вместо того, чтобы через два-три заниматься внедрением более мощных устройств и сталкиваться с одной и той же проблемой, мы полагали, что такие клиенты могут извлечь выгоду из того, что несколько коллекторов Flowmon объединят свою производительность, чтобы действовать как единое мощное устройство.

Вопрос № 2: У нас есть несколько центров обработки данных и нам требуется не менее двух месяцев хранения данных. Один коллектор предоставил бы только 3 недели.

Ответ: В дополнение к тому, что мы поддерживаем резервное копирование первичных данных за пределами устройств Flowmon,и, когда это необходимо, эти данные можно восстановить, чтобы они были доступны для анализа в любое время, мы решили расширить хранилище с помощью Распределенной архитектуры.

Вопрос № 3: Мы предоставляем профессиональные услуги Flowmon и должны обеспечить 100% время безотказной работы. Как мы можем провести эффективное развертывание Распределенной архитектуры?

Ответ: Действительно, некоторые наши клиенты просто не могут позволить себе время простоя, поскольку Flowmon - это критически важный для бизнеса сервис. До Распределенной архитектуры они могли использовать только дополнительные устройства, каждое из которых собирало одну и ту же информацию. Каждое из них настраивалось и управлялось отдельно. Теперь это делается через единый интерфейс. Любая конфигурация или настройка, применяемая к “master unit”, автоматически синхронизируются со “slave unit”. Это включает в себя обновления, отчеты, оповещения, профили и многое другое.

Вопрос № 4: У нас есть разные инструменты NPMD (Network Performance Monitoring and Diagnostics) в каждом центре обработки данных и отдельные IT-подразделения, поддерживающие исполнение операций в каждой локации. Теперь мы хотим передать эти функции единой глобальной IT-команде. Мы хотим, чтобы было возможным распознавать все источники постоянного flow в каждой локации, но при этом использовать только одно устройство для мониторинга всех объектов.

Ответ: Некоторые наши клиенты пытались сконцентрировать данные из разных решений в SIEM. Для отдельных случаев это работает. Но, чтобы выполнить поиск неисправностей, инженерам все равно нужно перейти от SIEM к соответствующим инструментам и проводить исследования там. Эта проблема также проявляется в кросс-командных операциях. Чтобы снизить операционные издержки и рационализировать сотрудничество в области устранения неполадок, компании ищут общие инструменты и общие пулы данных.

Тенденции, такие как Cloud-centric Architecture (облачная архитектура), Hyperconverged Infrastructure (гиперконверсированная инфраструктура) или Software Defined Networking (программное обеспечение, определяемые сетью),  позволяют предприятиям сопоставлять свои данные и услуги. Это по своей сути должно было бы привести к перегрузке полос пропускания горизонтального трафика в рамках одной локации, призывая к гипер-масштабируемому анализу сетевого трафика. Как ни странно, это же относится к распределению нагрузки с помощью Edge computing. Поскольку в таком сценарии нам приходится иметь дело с несколькими центрами обработки данных, каждый из которых требует ресурсов, но мы хотим достичь решения прозрачности для одной панели. И те же требования по вертикальной масштабируемости применяются к поставщикам SaaS. Компании ищут гибкие решения для обеспечения видимости сети, которые могут масштабироваться с учетом их потребностей и инфраструктуры, и которые поддержали бы их гибридную IT-среду. И это именно то, что вы получаете с Распределенной архитектурой. Стандартизация набора инструментов по аналитике, а также стандартизация источника данных, используемого для NetOps, приводит к существенному сокращению затрат, поскольку для этого требуется меньше усилий и времени, необходимых для внедрения и использования нескольких решений.

Более подробную информацию можно найти в этом обзоре продукта (PDF).

Источник ►