tcp/ip connection data play

ru_programming — 01.12.2010 Предыстория
Расширяю тулзу для стресс-тестирования mysql-сервера.
Текущая бета-версия умеет парсить slow-query-log, и проигрывать запросы из него на указанный mysql-сервер.
Чем это может быть полезно?
Допустим, есть у нас production-сервер, что задыхается под нагрузкой. Ложить его нельзя, выключать тоже, случайно заваливать - тем более.t
Задача: оптимизировать mysql/базу, либо протестировать как поведёт себя под нагрузкой сервер на новом железе
Решение: берём тулзу типа mysqldump или xtrabackup, поднимаем клон сервака, берём тулзу, она прогирывает запросы ASAP и выводит статистику, время выполнения.
Играемся с настройками железа, сервака, mysql, наблюдаем за поведением.

Что требуется
Теперь требуется делать тоже самое, но опираясь не на slow-query-log, а на tcpdump/libpcap/аналоги в качестве источника.
Мне требуется:
1) Иметь возможность записать все tcp/ip пакеты, проходящие через определённый интерфейс, отправленные на host:port, при этом host:port - адрес сокета в listen-mode (сокет сервера, которому был сделан socket & bind & listen и accept'ы в цикле), а также пакеты всех tcp/ip сессий, принятых на данный сокет (после accept'а на стороне сервера назначается временный порт на host, через который уже идёт отдельнео клиентское подключение. Вот про такие подключения и идёт речь. Если где заблуждаюсь вдруг - поправьте).
2) Используя (1) мне нужно вычленить отдельные tcp/ip подключения (разбить пакеты по группам, критерий разбиения - tcp/ip сессии - т.е. отдельное подключение)
3) После (2) мне требует разделить сессию на каналы "туда" и канал "обратно". очень важно с привязкой по времени - когда какой пакет проходил (timestamp к каждому ip-пакету)
4) После (3) мне требуется "пересобрать" ip-пакеты в виде списка пакетов с данными + timestamp'ы
in: [timestamp][data length][data buffer], [timestamp][data length][data buffer]
out: ... аналогично ...
В чём отличие от просто записанного tcp/ip дампа - нету системных пакетов типа SYN, ACK, RESET, нету ISN, SN, нету checksum, нету повторной посылки пакетов, в общем, нету системной информации TCP/IP упакованной в IP-пакеты.

Фактически, я хочу получить аргументы команд "send" на стороне клиента и "send" на стороне сервера, с указанием времени вызова.
(timestamp когда вызвали, buffer данные, length длины)
с тем предположением, что "будто бы" эти send всегда отправляли данные целиком.

Требования по памяти и производительности
Мне требутся "на лету" вычленять такие потоки, и потом делать их анализ (параллельно, ясен пень). В tcp/ip подключениях будет mysql binary protocol, мне его нужно парсить, и сразу "проигрывать" на второй сервер (тестовый). Это самый сложный case в данной задаче - фактически, real-time система.
Помимо on-the-fly processing также будет более умеренный case - запись этого счастья в некотором своём формате файл для дальнейшего воспроизведения "проигрывателем".

Надеюсь, не сильно запутал, надеюсь, описал всё корректно .

Неработающие решения
1) Построить tcp-ip прокси. Не выдержит нагрузки - раз, сложно - два, требует интеграции в инфраструктуру - три, начальство отсекло такой вариант - четыре.
2) "просто записать ip-пакеты при помощи tcpdump и не придумывать себе проблемы" - опять не работает. Как минимум, требуется перерабывать данную запись в некоторый формат, для максимально быстрого воспроизведения. Также требуется некоторый анализ, типа указания какие запросы дропать, запросы на какую базу интересует, в сколько подключений запускать (иногда требует "точное" воспроизведение, в том числе с привязкой по каждому подключения и времени - иногда - стессовое, фигачить без разбора ЧЕРЕЗ УКАЗАННОЕ ИЗВНЕ ЧИСЛО ПОДКЛЮЧЕНИЙ). Без пересборки tcp-сессий не обойтись.
3) Написать свой tcp-ip стек (его кусочек) - слишком долго, сложно, и не верю что такого уже нету
4) Взять готовый tcp/ip стек, выдрать кусочек, использовать в задаче. Боюсь, слишком сложно, да ещё и поди привязано к особенностям конкретного стека.
5) Взять PostgreSQL!

Потенциальное решение
Взять tshark, разобраться как оно работает внутре, отпилить ненужное, заюзать. В процессе.

В чём вообще вопрос
Нету ли решения проще? Как решается данная задача? Не верю, что никому не было нужно.

Заранее спасибо.

Оставить комментарий

Популярные посты:

• Архив