Мониторинг Сетевого Трафика На Серверах В Облаке

В Mars IS я отвечаю за мониторинг производительности приложений.

Основной принцип, на котором основан мониторинг производительности, — детальный централизованный анализ сетевого трафика между конечными пользователями и серверами, расположенными в наших дата-центрах.

Оно осуществляется в режиме реального времени и позволяет увидеть объективную картину производительности как отдельных пользователей, так и приложений в целом.

Вы можете узнать больше о наших методах мониторинга и анализа.

Здесь .

Однако мир не стоит на месте и наша компания, следуя общей тенденции, начинает активно использовать облачные решения.

В частности, многие приложения перемещаются на серверы в облачном центре обработки данных.

Это движение вызывает определенные трудности в моей области и даже ставит под угрозу перспективу своего существования.

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

Думаю, результат может быть полезен и в других областях ИТ, где есть потребность в централизованном сборе и анализе сетевого трафика.

Базовая конфигурация мониторинга

рисунок 1).

Изображение 1 Порт SPAN отражает весь пользовательский трафик по указанным VLAN на сервер сбора статистики.

Там распознаются отдельные приложения, пользовательские операции и сами пользователи, а также измеряются многие параметры их работы.

Собранные данные агрегируются и передаются на серверы для последующего анализа.

Эти же серверы предоставляют доступ к статистике группам поддержки и отвечают за создание оповещений о неприемлемой производительности конкретного приложения.

Мониторинг конфигурации серверов в облаке

Метод перестает работать, как только приложение перемещается в облако.

Установка физических серверов сбора статистики в облаке и настройка SPAN-портов там — дорогая и сложная в координации задача.

При этом службы поддержки предпочитают иметь дело с единой системой мониторинга как приложений внутри дата-центра, так и тех, которые расположены в облаке.

Оценив стандартные методы решения проблемы, предоставленные сторонними компаниями, я понял, что ни один из них меня не устраивает. Стандартно предлагается собирать конструкцию, показанную на рисунке 2.



фигура 2 Агенты VTAP (виртуальные сетевые перехватные устройства) устанавливаются на виртуальные интерфейсные серверы, которые считывают и отправляют весь трафик на сервер сбора статистики через туннели GRE. Существует еще одно стандартное решение, основанное на самой виртуальной среде (например, с использованием технологии Hyper-V).

Это правильные подходы, но они очень далеки от оптимального решения.

Во-первых , вам необходимо установить дополнительный сервер сбора статистики на виртуальную машину в облаке, при этом существующие серверы сбора статистики внутри наших дата-центров имеют значительный запас неиспользуемых мощностей.

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

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

Во-вторых, вам необходимо создать отдельный туннель для каждого сервера приложений.

Управление большим количеством туннелей GRE представляет собой дополнительную проблему и потребует значительного внимания со стороны службы поддержки.

Третий, Системные требования для установки агентов vTAP удивляют. Один из ведущих производителей требует 4 ГБ оперативной памяти и занимает одно ядро процессора.

Эти требования несопоставимы со сложностью решаемой задачи.

Кроме того, вам необходимо позаботиться о хостинге сервера для управления этим решением.

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

Наш метод

Потратив около двух недель на разработку, мне удалось создать свой аналог vTAP — легкий, удобный, а главное способный контролировать генерируемый поток данных.

Я назвал его ivTAP: интеллектуальное виртуальное устройство TAP. Принцип работы ivTAP показан на рисунке 3.



Рисунок 3 На каждом из серверов, где необходимо анализировать сетевую статистику, установлена клиентская часть приложения — ivTAPclient. Он выполняет довольно простую работу.

С помощью сетевого драйвера BPF и библиотеки libpcap/winpcap он сканирует сетевые пакеты заданным фильтром и пересылает их на серверную часть приложения — ivTAPsrv, предварительно упаковав их в UDP-канал.

Каждый канал контролируется на предмет превышения максимально допустимой скорости.

Серверная часть приложения извлекает пакеты из UDP-канала и «подсовывает» их любому из уже используемых интерфейсов SPAN-порта.

Сервер сбора сетевой статистики получает и обрабатывает эти пакеты вместе с теми, которые были собраны из SPAN-порта коммутатора обычным способом.

В результате получается продукт, который решает поставленную задачу и соответствует нашим требованиям:

• Продукт не создает дополнительной угрозы ни серверам приложений, ни системе сбора сетевой статистики: он не потребляет значительных ресурсов (процессор<1%; RAM <=512Mb) and does not create uncontrolled load surges on WAN communication lines;
• Этот метод сбора статистики не добавляет значительной погрешности к измерениям производительности.

  В каждый момент времени максимальная ошибка определяется значением джиттера сети + 10мс на стороне ivTAPclient;

• Программа работает стабильно долгое время;
• ivTAPclient работает как обычная служба на серверах Windows и не зависит от конфигурации среды фронтенд-сервера;
• Трафик, отраженный ivTAP, воспринимается сервером сбора статистики так же, как обычно поступает через SPAN-порт;
• Программа не нарушает никаких лицензионных соглашений: все манипуляции выполняются на уровне операционной системы, не затрагивая службу сбора и обработки сетевых пакетов;
• При создании программы использовались только те библиотеки, которые допускают бесплатное коммерческое использование — LGPL, MIT, Apache v2.

jnetpcap .

Я не вижу смысла переписывать здесь основные принципы работы с этой библиотекой или приводить полный листинг программы.

Разумнее было бы ограничить изложение несколькими наиболее важными и интересными отрывками.

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

В целом концепция выглядит так, как показано на рисунке 4:



Рисунок 4 Клиентская часть программы реализована классом :IVTAP. Первое, что он делает в void main(), — это проверяет наличие ключа «-l» в аргументах запуска.

Этот ключ используется только один раз для подготовки первого запуска программы.

Он отображает имена всех сетевых адаптеров, доступных на данном интерфейсном сервере.

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

Этот метод представляет собой небольшую модификацию примера, приведенного на сайте jnetpcap (см.

листинг 1).

   

 private static void listDevices() {
 
   List<PcapIf> alldevs = new ArrayList<PcapIf>(); // Will be filled with NICs  
   StringBuilder errbuf = new StringBuilder(); // For any error msgs 
   int r = Pcap.findAllDevs(alldevs, errbuf); 
 
   System.out.println("List available interfaces and exit");
 
   if (r == -1 || alldevs.isEmpty()) {  
     System.err.printf("Can't read list of devices, error is %s", errbuf.toString());  
     return;  
   }
 
   Iterator<PcapIf> itrdev = alldevs.iterator();
   while(itrdev.hasNext()) {
     PcapIf device = (PcapIf)itrdev.next();
     StringBuilder sb = new StringBuilder();
 
     sb.append(device.getName());
     sb.append(";");
     sb.append((device.getDescription() != null) ? device.getDescription() : "No description available");
     sb.append("; MAC address:");
     try {
       if (device.getHardwareAddress() != null) {
         byte[] mac = device.getHardwareAddress();
         for (int i = 0; i < mac.length; i++) {
           sb.append(String.format("X%s", mac[i], (i < mac.length - 1) ? "-" : ""));
         }
         } else {
           sb.append("No MAC address");
         }
     } catch (IOException e) {
        System.err.printf("Can't read MAC address");
     }
     sb.append("; IP address(es):");
     List<PcapAddr>  addrs = device.getAddresses();
     Iterator<PcapAddr> itraddr = addrs.iterator();
     while(itraddr.hasNext()) {
       PcapAddr pcapAddr = (PcapAddr)itraddr.next();
       sb.append(pcapAddr.getAddr().

toString());
     }
     System.out.printf("%s\n", sb.toString());
   }      

   

• Социально-Ориентированные It-Технологии Для Людей, Потерявших Способность Говорить

  19 Oct, 24

• Почему Пользователи Отказываются От Push-Уведомлений И Как Этого Избежать – Опыт Хоппера

  19 Oct, 24

• Рабочая Среда: Какие Гаджеты Использует Дизайнер Pebble Александр Киров?

  19 Oct, 24

• Умеют Ли В России Проектировать И Изготавливать Электрогитары?

  19 Oct, 24

• Как Сервисной Компании Обеспечить Рост Бизнеса На Высококонкурентном Рынке Систем Безопасности?

  19 Oct, 24

• Беспроводная Камера Или Глушитель Wi-Fi?

  19 Oct, 24

• Как Работают It-Специалисты? Андрей Гажарига, Руководитель Отдела Развития И Развития, Orange Business Services

  19 Oct, 24

• Субъективно О Медиацентре E-Great M32B

  19 Oct, 24

• Что Делать С Разгневанными Клиентами

  19 Oct, 24

• Двухуровневая Организация Исходного Кода. Неизбежно Или Бессмысленно?

  19 Oct, 24