Для будущих поколений и для тех, кто думает запустить CHR в виртуальной среде и собрать кластер с High Available с трафиком больше 1 Гбит / сек.
Вдохновившись опытом своих коллег, решил собрать RouterOS в качестве BRAS на базе сервера. Как раз освободился из дата-центра сервер Asus z8nr-d12.
Поставил: 2 карты Intel x520 (оригинал и китайский оригинал), последние камни для сокета этой серверной платформы Xeon x5690 (2 шт. по 12 ядер с Hyper Threading, в сумме 24 ядра), оригинальные Intel DAC SFP+. И начал проводить тесты в разных средах.
Честно говоря, тут должна быть подробная статья с описанием тестирования, но, честно - влом. Все тесты проводились с реальным трафиком, с утилитой hping3 и встроенными в mikrotik тестами.
Какие были тесты и на чем:
- на гипервизорах: Xen + XCP-NG, Vmware, Proxmox. Hyper-V не рассматривал, т.к. это, на мой взгляд, перебор - RouterOS на Widows Server с ночными аптейтами :)
- CHR и X86 RouterOS;
- CCR1072 / CCR 1036.
- с использованием SR-IOV;
- с использованием PCI-Passthrough;
- с использованием паравиртуальных сетевых картах.
- гонял реальный трафик
Выводы №1 по виртуальной среде:
- SR-IOV не поддерживается RouterOS от слова вообще.
- худшие результаты были на гипервизорах с использованием паравиртуальных сетевых драйверов (Vmxnet3). В ~4-6 раз хуже самых лучших результатов + куча дропов.
- средние результаты были на гипервизорах с проброшенной X520 прямо в виртуалку (PCI-Passthrough). В ~2-3 раз хуже самых лучших результатов. Дропов почти нет.
- самые лучшие результаты были получены на чистом RouterOS для х86.
Выводы №2 по виртуальной среде:
- рассматривать CHR в качестве решения для BRAS, с трафиком больше 1G, не стоит.
- CHR с PCI-Passthrough рабочий вариант, но преимуществ в себе никаких не несет, т.к. нельзя использовать фишки виртуализации: миграция, кластеры, High Available. Ну и излишнее расточительство ресурсов имеет место быть.
- Никакие другие тесты даже близко не подходят к возможностям чистого RouterOS на Х86.
- CHR чисто для Дата-центров и какого-то количества виртуальных машин, чтобы рулить: роутингом, шейпером, НАТом, bgp/ospf; с аплинком не более 1 Gbps
Выводы по CCR 1072 / 1036:
В связи с тем, что эти маршрутизаторы стояли и стоят в продакшн давно, могу делать однозначные выводы, с которыми меня никто не переубедит:
- для чистого forward / mpls трафика очень годное решение (гоняю 4-5 Gbps)
- c использованием очередей (queue), получаем повышенный jitter и нагрузку на CPU, небольшие дропы. Про шейпинг при > 2 Gbps трафика лучше забыть.
- динамическая маршрутизация использует 1 ядро, поэтому 1-3 FV-таблицы не больше. Если BGP-Peer будет флапать, то получите конкретный трэш из-за того, что префиксы не будут успевать удалятся и добавляться.
- Ядра 1-1.2 Ghz. Даже самый лёгкий DoS/DDoS укладывает CCR на лопатки так, что тот не успевает ничего понять. Я перепробовал всё: tcp syn cookie, детекцию с занесением в raw и прочие правила в firewall. RAW эффективен, но и он не всегда спасает.
DDoS влияет на работу сервисов динамической маршрутизации (ospf/bgp), те, в свою очередь, не могут поддерживать сессии из-за высокой нагрузки CPU и падают. x86 c двумя Xeon X5690 держался очень достойно и смолотил всё, чем я его ддосил.
PS:
Еще тестировал PfSense и VyOS на X86.
- Понравился VyOS, но для решения пограничного маршрутизатор (bgp/ospf).
- PfSense рабочая лошадка с аналогичными возможностями RouterOS, но ТАКОЕ управление через WEB меня просто вгоняло в ступор. Кстати у PfSense есть крутое решения для High Available. Ни разу не VRRP, а полная синхронизация.
К вопросу, насчет китайской и оригинальной карты: по результатам тестов разницы никакой. Только физический различия в качестве сборки и пайки. Чип в китайской такой же.
