Презентация с конференции HighLoad-2013 об архитектуре новой DPI платформы Петер-Сервис.
http://www.highload.ru/2013/abstracts/1178.html
Представлен обзор архитектуры многоцелевой DPI-платформы, на основе которой могут строиться как "шпионские" приложения класса СОРМ/PRISM, так и коммерческие системы PCEF/TDF (Traffic Shaping), безопасного Интернета (интеллектуальная фильтрация содержимого), таргетирования рекламы и т. д. К особенностям рассматриваемого решения можно отнести мультитерабитное масштабирование, способ балансировки, обработку "роем" (Swarm Intelligence) и аварийного восстановления (failover) посредством репликации конечных автоматов.
Roadmap:
- offtopic: кому и зачем нужен DPI?
- offtopic: законность и морально-этические вопросы.
- на какую "луну" нужно сесть, что мы хотим сделать?
- распределение трафика за счет использования коммутаторов и MAC rewrite.
- роевой интеллект (Swarm Intellegence) для управления балансировкой и обработкой данных.
- репликация конечных автоматов (виртуальных микромашин).
- распределенное "Табло" как оперативное хранилище с элементами key-value и eventual consistency, lockfree в shared memory.
- транспортный фасад, унифицирующий DPDK, netmap, Infiniband (RDMA), 0mq и zerocopy и lockfree обмен через shared memory.
2. Леонид Юрьев
•
•
20 лет программирую
изобретаю, иногда не велосипеды
leo@yuriev.ru
leonid.yuriev@billing.ru
3. Петер-Сервис
– HighLoad c 1992 года
– принципы: взялись → дожимаем, качество, модульность
• решения для крупных операторов связи – BSS, Telco, BigData,
High Availability & High Load
• полный цикл – разработка, внедрение и обслуживание
• более 100 миллионов абонентов – при участии наших систем
• 900 сотрудников, из них – 400 разработка, 250 внедрение и
саппорт
• 450 фич/год
4. Agenda
• Что такое и для чего DPI?
• TopGun – зачем и почему?
25
СЛАЙДОВ
• Основные плюшки 3+1
• Круто!
• Будет Event…
• Вопросы
5. Agenda
• Что такое и для чего DPI?
• TopGun – зачем и почему?
25
СЛАЙДОВ
• Основные плюшки 3+1
• Круто!
• Будет Event…
• Вопросы
6. Что такое DPI?
– Технология анализа полного содержимого трафика выше L2 по OSI
http://ru.wikipedia.org/wiki/Deep_packet_inspection
Сеть
•
•
•
•
DPI
Интернет
устанавливается у оператора
работает с «сырыми» пакетами
включение «в разрыв» – может вмешиваться в трафик
подключение «на копию» – просто наблюдает
FLOW – примерно/грубо соответствует соединению TCP/UDP
7. Кому и зачем нужен DPI?
– Государству и Бизнесу, Usecases очень много…
Защита
• Блокировка вторжений (IDS, IPS)
• Отсечение DoS-атак
Качество обслуживания,
Гибкие тарифы
• QoS и шейпинг с управлением
потоком (торренты не мешают)
• Subscriber Management
Фильтрация
• Родительский контроль, Антивирус
• РОСКОМНАДЗОР
Информативность
• Customer Experience Management
• Данные для таргетирования
рекламы
• Статистика и оперативный
Мониторинг сети
Требования законодательства
и регулирование
• В мире: СОРМ и PRISM
• В России: 114-ФЗ, 139-ФЗ, ПП-538
• Предотвращение утечек (DLP)
+100500…
8. Насколько законно и этично?
– Зависит от usecase, а они очень разные…
Законно, если…
• Госорганы – в соответствии с
законами:
114-ФЗ, 139-ФЗ, ПП-538
• Бизнес – в соответствии с
договором с пользователем
• Бизнес – в соответствии с
договором с работником (DLP)
• Если заказана соответствующая
услуга
Этично, когда…
• Открыто, не подпольно
• Анализирует машина, не
человек
• Важно как используется
результат
• Обеспечить корректное
использование – задача
государства и общества
9. Сложность задачи
– Какие проблемы, Captain?
1. Wire Speed
• 14.8 × 2 миллионов пакетов в секунду на каждые 10Gb
2. Отказоустойчивость
• иначе «интернет не работает» и потеря денег
3. Много N×10 GbE
• требуется масштабирование и балансировка
• миллионы flow, сотни тысяч каждую секунду
• защита от DDoS, родительский контроль,
тарифы «торренты в фоне»
4. Готовность к разным задачам
• иначе переделывать или отказываться
– Аaaа… but the Challenge!
11. Зачем нужен 101-й DPI?
– у конкурентов есть проблемы
1. Зависимость от оборудования
• hardware vendor lock-in
– выгодно вендору, но не оператору
• не-тиражная электроника
– стоимость, риски незаменимости и уникальности
• нет маневра от закладок
– выше риски их обнаружить (shit happens)
12. Зачем нужен 101-й DPI?
– у конкурентов есть проблемы
1. Зависимость от оборудования
• hardware vendor lock-in
– выгодно вендору, но не оператору
• не-тиражная электроника
– стоимость, риски незаменимости и уникальности
• нет маневра от закладок
– выше риски их обнаружить (shit happens)
2. Нет готовности к «разным задачам»
• сложно/невозможно доработать систему под новые задачи
– как пример, добавить распаковку gzip к акселератору regex
• нет эластичности вычислительной сложности обработки
– дальше поясню
13. Зачем нужен 101-й DPI?
– у конкурентов есть проблемы
1. Зависимость от оборудования
• «просто так» никто
не сознается
• hardware vendor lock-in
– выгодно вендору, но не оператору
• аппаратный DPI
• не-тиражная электроника
х
–
– стоимость, риски незаменимости и уникальностиэто ерунда из 90
• нет маневра от закладок
– выше риски их обнаружить (shit happens)
2. Нет готовности к «разным задачам»
• сложно/невозможно доработать систему под новые задачи
– как пример, добавить распаковку gzip к акселератору regex
• нет эластичности вычислительной сложности обработки
– дальше поясню
15. Нет эластичности вычислительной сложности
– де-факто имеем два варианта «софтверной архитектуры»
OLD SCHOOL
•
•
•
•
generic interface & large i/o overhead
от наших 5 копеек ничего не зависит
делаем гибко и удобно, это навсегда
подходит для задач где,
много вычислений
• иначе – 90% в накладных расходах
≈ 500`000
попугаев в секунду
16. Нет эластичности вычислительной сложности
– де-факто имеем два варианта «софтверной архитектуры»
OLD SCHOOL
А ТЕПЕРЬ PPS
•
•
•
•
•
•
•
•
generic interface & large i/o overhead
от наших 5 копеек ничего не зависит
делаем гибко и удобно, это навсегда
подходит для задач где,
много вычислений
• иначе – 90% в накладных расходах
≈ 500`000
попугаев в секунду
работаем с DMA-RING или рядом
считаем такты, рекордный PPS
hardcode, трудно и неудобно
подходит для задач где,
мало вычислений
• иначе – экономия на спичках
≈ 50`000`000
попугаев в секунду
17. Нет эластичности вычислительной сложности
– де-факто имеем два варианта «софтверной архитектуры»
OLD SCHOOL
А ТЕПЕРЬ PPS
•
•
•
•
generic interface & large i/o overhead • работаем с DMA-RING или рядом
– выбрать один из вариантов
от наших 5 копеек ничего не зависит • считаем такты, рекордный PPS
делаем гибко ии не посягать на задачи другогои неудобно
удобно, это навсегда • hardcode, трудно ?
подходит для задач где,
• подходит для задач где,
много вычислений
мало вычислений
• иначе – 90% в накладных расходах
• иначе – экономия на спичках
≈ 500`000
попугаев в секунду
≈ 50`000`000
попугаев в секунду
18. Наши цели, что хотим сделать?
– JFK: Американец, Первым, на Луне, Вернуться, Живой
Свободно
• без привязки к конкретному
«железу»
• на оборудовании максимально
широкого спектра
Эластично
• чтобы просто «добавлять
серверы», без революций в коде
• масштабируемо,
без неустранимых внутренних
ограничений
Эффективно
• с потерей на универсальности
порядка 10%
Конкурентно
• с отказоустойчивостью
• с низкой стоимостью владения
Платформа
• для DPI-приложений широкого
спектра
19. Что сделано, каков продукт?
– запилили прототип и решили поделиться мыслями
Скромничаем…
А если померяться?
• 90% зависит от usecase/FL
• ширина канала ≈ сколько потребуется
• раскрывать детали не готовы
• пакетов в секунду ≈ wire speed
• приходите, расскажем подробнее
• задержка ≈ 100 μs
• простые метрики – для простых
задач
• на ядро ≈ 90% от рекордов:
– платим 10% за совершенство архитектуры
– в сравнении с Intel DPDK
– без prefetch, спрашивайте почему…
21. Scope платформы
Платформа = TopGun
Не входит:
• Переключатель (bypass)
• Управление и мониторинг
• Внешние подсистемы
FUSE
Управление
и
мониторинг
TOPGUN
Внешние
системы
22. Основные слагаемые: 3+1=4
– плюшек больше, некоторые успеем распробовать
Распределение трафика
• mac rewrite и раздаем коммутаторами
• управляется роем
Рой обработчиков
• оцениваем здоровье и связанность
• виртуальные микро-машины
Табло
• контексты как наборы key-value
• контролируем объем трафика и размер реплик
Транспорт событий
• замысел и что внутри
23. Анатомия скелета
1
– что-куда подключено
ПЕРЕКЛЮЧАТЕЛЬ
Схеме около 50 лет…
ВКЛЮЧЕНО
1. Переключатель
2
РАСПРЕДЕЛЕНИЕ
РАСПРЕДЕЛЕНИЕ
3
DATA PLANE
DATA PLANE
2. Распределение трафика
3. Data Plane (Switch)
ГОРЯЧИЙ РЕЗЕРВ
6. Супервизор
7. Перешеек для репликации
между копиями – наш addition
5
7
CONTROL PLANE
6
ЗЕРКАЛИРОВАНИЕ требуется ТОЛЬКО
для failover «СОВСЕМ БЕЗ ПОТЕРЬ»
CONTROL PLANE
SUPERVISOR
BLADE
BLADE
BLADE
BLADE
BLADE
BLADE
BLADE
BLADE
4
BLADE
5. Control Plane (Switch)
BLADE
4. Обрабатывающие серверы
25. Распределение трафика
ПЕРЕКЛЮЧАТЕЛЬ
– MAC rewrite + коммутаторы
лучше раздавать коммутаторами,
они быстрые и…
•
ассоциативная таблица MAC → ПОРТ
отлично подходит
?
MAC → PORT#
?
BLADE
DATA PLANE
(Коммутатор)
BLADE
•
РАСПРЕДЕЛЕНИЕ
BLADE
для балансировки трафик нужно нарезать
BLADE
•
BLADE
Замысел
26. Распределение трафика
ПЕРЕКЛЮЧАТЕЛЬ
– MAC rewrite + коммутаторы
Замысел
ассоциативная таблица MAC → ПОРТ
отлично подходит
Магия
1.
посчитаем HASH от IP и запишем два
байта в MAC, получаем 65536 сегментов
трафика
2.
распределим сегменты по обработчикам
3.
пусть обработчики пингуют DATA PLANE
от имени MAC нужных им сегментов
MAC → PORT#
SEG #
BLADE
DATA PLANE
(Коммутатор)
BLADE
•
dst-MAC[0,1,2,3] = 0x77
dst-MAC[4,5] = Hash(IP)
BLADE
лучше раздавать коммутаторами,
они быстрые и…
BLADE
•
РАСПРЕДЕЛЕНИЕ
для балансировки трафик нужно нарезать
BLADE
•
27. Распределение трафика
ПЕРЕКЛЮЧАТЕЛЬ
– MAC rewrite + коммутаторы
Плюсы
• молниеносная управляемость
при статической конфигурации
РАСПРЕДЕЛЕНИЕ
dst-MAC[0,1,2,3] = 0x77
dst-MAC[4,5] = Hash(IP)
• мгновенный failover
– при сбое broadcast и активация
BLADE
BLADE
BLADE
SEG #
DATA PLANE
(Коммутатор)
BLADE
• на нас работает весь Ethernet:
– Pause Frame, Spanning Tree, LAG…
MAC → PORT#
BLADE
• простое расширение
– достаточно подключить оборудование
29. MAC rewrite
– есть подводные камни
OpenFlow
• Таблица вместо Hash и не везде есть SetField
• Требуются ACL и TCAM
• Вместо 65K получаем порядка 1000
30. MAC rewrite
– есть подводные камни
OpenFlow
• Таблица вместо Hash и не везде есть SetField
• Требуются ACL и TCAM
• Вместо 65K получаем порядка 1000
Arista 7124FX и всяческие FPGA
• Да, но не удобно и vendor lock-in
31. MAC rewrite
– есть подводные камни
OpenFlow
• Таблица вместо Hash и не везде есть SetField
• Требуются ACL и TCAM
• Вместо 65K получаем порядка 1000
Arista 7124FX и всяческие FPGA
• Да, но не удобно и vendor lock-in
POF – серебряная пуля?
• Предложения по расширению OpenFlow
• Позволяет посчитать CRC и записать в MAC
• Protocol-Oblivious Forwarding, http://www.poforwarding.org/
32. MAC rewrite
– есть подводные камни
OpenFlow
• Таблица вместо Hash и не везде есть SetField
• Требуются ACL и TCAM
• Вместо 65K получаем порядка 1000
Arista 7124FX и всяческие FPGA
• Да, но не удобно и vendor lock-in
POF – серебряная пуля?
• Предложения по расширению OpenFlow
• Позволяет посчитать CRC и записать в MAC
• Protocol-Oblivious Forwarding, http://www.poforwarding.org/
– продержаться
можно, ожидаем
подкрепление
33. Swarm Arrives!
Роевой Интеллект – эффект коллективного поведения
децентрализованной самоорганизующейся системы
Цель общая, действия локальны
• все получают одну инструкцию, но действуют
самостоятельно
• избавляемся от микро-менеджмента
Каждый знает о каждом
• информация для согласованных решений
• пример – поезда и смена расписания
• можем балансировать децентрализовано
Один ничто, рой все
• потеря единицы не должна влиять на результат
• не храним ценного внутри, реплицируем
• идеальный failover
34. Балансировка – управляем роем
ПЕРЕКЛЮЧАТЕЛЬ
Оцениваем обработчики
РАСПРЕДЕЛЕНИЕ
• производим перекрестную оценку каждого
• оцениваем здоровье и связанность с роем
?
BLADE
BLADE
BLADE
SEG#
DATA PLANE
BLADE
MAC → PORT#
MAC → PORT#
BLADE
• проверяем Data Plane и Control Plane
SEG#
SEG#
SEG#
SEG#
?
?
?
?
CONTROL PLANE
(Коммутатор)
35. Балансировка – управляем роем
ПЕРЕКЛЮЧАТЕЛЬ
Оцениваем обработчики
РАСПРЕДЕЛЕНИЕ
• производим перекрестную оценку каждого
• оцениваем здоровье и связанность с роем
BLADE
• используем NTP и timestamps
SEG#
• много деталей и know how
LIST
BLADE
• у каждого обработчика свой список роя
BLADE
Ведем перепись
DATA PLANE
BLADE
MAC → PORT#
MAC → PORT#
BLADE
• проверяем Data Plane и Control Plane
SEG#
SEG#
SEG#
SEG#
LIST
LIST
LIST
LIST
CONTROL PLANE
(Коммутатор)
36. Балансировка – управляем роем
ПЕРЕКЛЮЧАТЕЛЬ
Оцениваем обработчики
РАСПРЕДЕЛЕНИЕ
• производим перекрестную оценку каждого
• оцениваем здоровье и связанность с роем
BLADE
• используем NTP и timestamps
SEG#
• много деталей и know how
LIST
SEG#
SEG#
SEG#
SEG#
LIST
LIST
LIST
LIST
Балансирует каждый !
• по своему списку выбирает себе Сегменты
• hash ring не используем – мало Сегментов
• балансируем по ядрам, не по серверам
BLADE
• у каждого обработчика свой список роя
BLADE
Ведем перепись
DATA PLANE
BLADE
MAC → PORT#
MAC → PORT#
BLADE
• проверяем Data Plane и Control Plane
CONTROL PLANE
(Коммутатор)
37. Балансировка – управляем роем
ПЕРЕКЛЮЧАТЕЛЬ
Плюсы
• Легко мониторить и интегрировать
– просто слушаем Control Plane
LIST
BLADE
SEG#
BLADE
BLADE
DATA PLANE
BLADE
• Отказоустойчиво
– децентрализовано
– нет единой точки отказа
MAC → PORT#
MAC → PORT#
BLADE
• Самодиагностика
– постоянная и встроенная
РАСПРЕДЕЛЕНИЕ
SEG#
SEG#
SEG#
SEG#
LIST
LIST
LIST
LIST
CONTROL PLANE
(Коммутатор)
38. Табло для роя
ПЕРЕКЛЮЧАТЕЛЬ
– оперативное общедоступное хранилище
Табло
РАСПРЕДЕЛЕНИЕ
• простое key-value хранилище
реплика
ТАБЛО
CONTROL PLANE
BLADE
BLADE
• unordered map + shared memory + lockfree
key1 = value + version
key2 = value + version
…
key# = value + version
BLADE
• заточено под zerocopy & DMA
BLADE
• как-то все записи версионированы
BLADE
DATA PLANE
39. Табло для роя
ПЕРЕКЛЮЧАТЕЛЬ
– оперативное общедоступное хранилище
Табло
РАСПРЕДЕЛЕНИЕ
• простое key-value хранилище
Реплицируем
• реплика на каждом сервере
реплика
ТАБЛО
• при локальном изменении
отправляется уведомление в Control Plane
• получаемые обновления вливаются
с учетом версионности
• нет единого формата версии, зависит от
данных и задачи
CONTROL PLANE
BLADE
BLADE
• unordered map + shared memory + lockfree
key1 = value + version
key2 = value + version
…
key# = value + version
BLADE
• заточено под zerocopy & DMA
BLADE
• как-то все записи версионированы
BLADE
DATA PLANE
40. Обработка роем
ПЕРЕКЛЮЧАТЕЛЬ
– это и есть самое главное
Трансформируем задачи
РАСПРЕДЕЛЕНИЕ
• сводим к виртуальной микро-машине
from=10.0.0.1:4629
to=199.32.42.3:80
…
реплика
ТАБЛО
CONTROL PLANE
BLADE
BLADE
ОБРАБОТЧИК
BLADE
BLADE
• состояние представляем как набор key-value
BLADE
DATA PLANE
41. Обработка роем
ПЕРЕКЛЮЧАТЕЛЬ
– это и есть самое главное
Трансформируем задачи
РАСПРЕДЕЛЕНИЕ
• сводим к виртуальной микро-машине
• находим способ версионировать
СОСТОЯНИЕ
from=10.0.0.1:4629
to=199.32.42.3:80
node={A.5, Green}
…
inbound=200
outbound=6346
реплика
ТАБЛО
CONTROL PLANE
BLADE
BLADE
BLADE
ОБРАБОТЧИК
Версионируем состояние
• пакеты – события,
обработка которых меняет состояние
BLADE
• состояние представляем как набор key-value
BLADE
DATA PLANE
42. Обработка роем
ПЕРЕКЛЮЧАТЕЛЬ
– это и есть самое главное
Трансформируем задачи
РАСПРЕДЕЛЕНИЕ
• сводим к виртуальной микро-машине
• находим способ версионировать
Обработчики – Stateless
• хранят состояние на Табло
СОСТОЯНИЕ
from=10.0.0.1:4629
to=199.32.42.3:80
node={A.5, Green}
…
inbound=200
outbound=6346
• не хранят ценного внутри, только кэшируют
• работают в цикле
– receive event, get state, handle, put state
реплика
ТАБЛО
CONTROL PLANE
BLADE
BLADE
BLADE
ОБРАБОТЧИК
Версионируем состояние
• пакеты – события,
обработка которых меняет состояние
BLADE
• состояние представляем как набор key-value
BLADE
DATA PLANE
43. Рой – обработка и «Табло»
ПЕРЕКЛЮЧАТЕЛЬ
Tradeoff
РАСПРЕДЕЛЕНИЕ
• Уменьшаем трафик по Control Plane
отправляя оповещения реже
Тонкости
• TCP Window – носим «чемодан с
батарейками»
• TCP Sequences – дуплексный маркер
направления потока данных
from=10.0.0.1:4629
to=199.32.42.3:80
node={A.5, Green}
…
inbound=200
outbound=6346
• у обработчика локальный writeback
cache, запись в реплику через отдельную
очередь
WRITEBACK
FIFO
реплика
ТАБЛО
CONTROL PLANE
BLADE
BLADE
BLADE
ОБРАБОТЧИК
BLADE
• Уменьшаем объем реплик,
храня только свое или 1-ю линию failover
BLADE
DATA PLANE
44. Свой «Транспорт»
C/C++
Неплохо бы…
POD
Java
PAIR LIST
• единообразно: in-process, in-server,
over-network, плюс со-процессоры
• мега-эффективный обмен сообщениями
Go
D
STREAMING
MQ
Erlang
safemode
zerocopy
• автоматические запятые – копировать
нельзя шарить DMA
priority
inheritance
КАКАЯ-ТО МАГИЯ
lockfree
…
DMA
Дизайн
• zerocopy + shared memory + lockfee + PI
• разные «транспорты» под один фасад
• операции со «строками» и итераторы
• ensure & asserts, safemode…
• сложности – в отдельный процесс
DPDK
MPI
ØMQ
netmap
SHARED RAM
NETWORK
CONTROL PLANE
DATA PLANE
IPC
45. Свой «Транспорт»
C/C++
Внутри
POD
• действительно эффективные итераторы и
операции с цепочками
PAIR LIST
Планы
• LGPL ≈ 1Hippeus, this is SPARTA!
• Думаем о Erlang, Go, D, Java, Xeon Phi, CUDA,
Tilera…
STREAMING
MQ
MESSAGE = a list of chunks
chunk
chunk
DATA
INPLACE
• очередь сообщений и диспетчер с пулом
потоков
• providers: Intel DPDK, netmap, 0mq, MPI...
D
FIFO
• чистый lockfree (CAS & retry-on-fail),
либо checked busyloop с выходом на PI-futex
Go
Erlang
chunk
WEAK
• концепт буфера как куска памяти и
offset_ptr (для сопроцессоров…)
Java
external
data
PROVIDER INTERFACE
DPDK
MPI
ØMQ
netmap
SHARED RAM
NETWORK
CONTROL PLANE
DATA PLANE
IPC
46. Свой «Транспорт»
C/C++
Внутри
POD
Java
PAIR LIST
• концепт буфера как куска памяти и
offset_ptr (для сопроцессоров…)
• чистый lockfree (CAS & retry-on-fail),
либо checked busyloop с выходом на PI-futex
• действительно эффективные итераторы и
операции с цепочками
Go
D
STREAMING
MQ
Erlang
to be continued…
HighLoad++
2014
• очередь сообщений и диспетчер с пулом
потоков
• providers: Intel DPDK, netmap, 0mq, MPI...
Планы
• LGPL ≈ 1Hippeus, this is SPARTA!
• Думаем о Erlang, Go, D, Java, Xeon Phi, CUDA,
Tilera…
DPDK
MPI
ØMQ
netmap
SHARED RAM
NETWORK
CONTROL PLANE
DATA PLANE
IPC
47. У нас получается, круто!
Масштабируемость
Эластичность и эффективность
• распределение коммутаторами
• «транспорт» дает гибкость за 10%
• MAC rewrite – OpenFlow & Arista,
на подходе POF
• при нехватке CPU/RAM можем просто
подключить еще
• децентрализованное управление
распределением трафика
• доступен safemode или непосредственно
shared memory
Надежность / Стоимость
Платформа
• нет единой точки отказа
• распределенное Табло для данных
• прореживаем репликации Табло –
уменьшаем трафик Control Plane
• микро-машины с версионируемым
состоянием
• храним в репликах Табло меньше чужих
данных – уменьшаем требования RAM
• обмен сообщениями
вне зависимости от среды передачи
• нужна полная гарантия «без потерь» –
ставим зеркало
48. Checkpoint: Подведем итоги
DPI нужен – как Бизнесу, так и Государству
TopGun – интересная и сложная задача
• Масштабируемо с роевым интеллектом
• Эластично и независимо от «железа»
• Стоимость/надежность – можно балансировать
• Легко развивать, терабит, задержка 100 μs
49. Много нераскрытых тем,
будет семинар 03.12.2013
• Законность и этика, конфиденциальность, сетевой нейтралитет
• Технология как стратегическое преимущество
• Больше usecases и Бизнеса
• Что уже сделано, пилотные проекты и внедрения
• Больше технических подробностей
• http://www.billing.ru/events/560
50. TopGun: Вопросы?
Сейчас – HighLoad
• Предпосылки и цели TopGun
• MAC rewrite и распределение
трафика
• Рой – управление
балансировкой
• Рой – обработчики
• Рой – поддержка Табло
• Транспорт, zerocopy, lockfree, PI,
диспетчеризация
На встрече
в Петер-Сервис
•
•
•
•
Usecases и Бизнес
http://www.billing.ru/events/560
Когда релиз?
Законность и этика
Свобода и конфиденциальность,
компромисс с реальностью
• Технология как стратегическое
преимущество
• Поддерживаемые протоколы
• Пилотные проекты и внедрения