В сфере высокочастотной торговли зачастую борются за любое уменьшение сетевой задержки, ведь это дает возможность получить информацию об изменении цены инструмента раньше остальных и отправить заявку на исполнение быстрее конкурентов по более выгодным условиям. Нередко можно встретить такие решения, как отказ от промежуточного сетевого оборудования в виде сетевого коммутатора, который мог бы обеспечить использование торгового подключения несколькими серверами сразу. Но зачем подключать каждый сервер напрямую к инфраструктуре биржи, если можно платить за один аплинк и подключить его в классический ToR(Top-of-rack) коммутатор? Конечно для уменьшения сетевой задержки, ведь современный сетевой коммутатор внесет лишние 200-500 наносекунд задержки.
Конечно можно обратиться к low-latency коммутаторам, базирующимся на FPGA матрицах, таким как серия Cisco Nexus 3550 Fusion (в прошлом Exablaze ExaLINK Fusion) или Arista 7130 Series (в прошлом Metamako MetaMux). За счет использования коммутации на уровне layer 1 (модели OSI) отходящей от канонов классических сетевых протоколов, можно добиться понижения сетевой задержки коммутатора до единиц нс (3-5нс) в случае fan-out, то есть раздачи поступающей биржевой информации на коммутатор сразу в несколько исходящих портов, или десятков нс (~39нс) в случае мультиплексирования (Muxing) входящих сообщений на постановку заявок на биржу со стороны торговых серверов для их отправки в один исходящий аплинк в сторону биржи. Однако такое решение может стоить вам до нескольких десятков тысяч долларов на каждую стойку. Стоит упомянуть что каждый лишний метр оптического кабеля добавит вам еще порядка ~5нс. А, ну и на каждый оптический SFP трансивер вам добавит еще по ~500 пикосекунд.
Безусловно стоит обратиться к правилам конкретной биржи, она может явно запрещать вам подключение биржевого линка напрямую в ваш торговый сервер, кое где явного запрета нет, и разрешенное оборудование к подключению ограничивается формулировками «сетевое оборудование». Мне кажется PCI сетевой адаптер может быть категоризован как «сетевое оборудование», да? Конечно тут стоит задать прямой вопрос вашему брокеру или представителю биржи, ведь за нарушение правил могут последовать совсем нешуточные санкции. Однако, есть биржи, которые явно не запрещают такого подключения.
В таком случае единственным нюансом будет являться необходимость настроить на стороне вашего торгового сервера общение через один физический сетевой интерфейс с разных IP адресов, чтобы ближайший к вам L3 коммутатор биржи мог обменяться с вами маршрутами (например по BGP протоколу) и поддерживать вашу BGP сессию в Established статусе, удерживая соседство с коммутатором биржи, а торговый IP адрес мог быть использован вашим торговым алгоритмом. Эту ситуацию мы и рассмотрим в статье на примере настройки сетевого стека Ubuntu Server 20.04, netplan и BGP демона bird v.1.6.8.
С помощью netplan добавить несколько IP адресов довольно просто, для этого в файле конфигурации /etc/netplan/01-netcfg.yaml для интерфейса enp1s0d1 достаточно перечислить их:
network:
version: 2
renderer: networkd
ethernets:
...
enp1s0d1:
addresses:
- 10.2.2.42/30 # адрес, который был дан для свича с нашей стороны
- 10.1.1.2/26 # наш торговый IP адрес
То что касается конфигурации IP роутинг демона bird с исходным открытым кодом, тут обычно нужна примерно следующая конфигурация в файле конфигурации /etc/bird/bird.conf для конфигурации BGP:
router id 10.2.2.42; # адрес, который был дан для свича с нашей стороны
protocol kernel {
scan time 20;
export all; # Actually insert routes into the kernel routing table
}
...
protocol static static_bgp {
route 10.1.1.2:255.255.255.255 via 10.2.2.42; # Роут который мы передаем соседу по BGP к нашему торговому IP 10.1.1.2 через наш адрес свича
}
protocol bgp {
import all;
export where proto = "static_bgp";
local as 65001; # Номер АС который нам дала биржа
neighbor 10.2.2.41 as 64512; # IP адрес соседского свича и его АС номер.
password "%your_password_here%"; # используем данный нам пароль для установления BGP сессии
}
Для проверки состояния bird нужно открыть консоль управления демона birdc , и проверить статус сессии bgp1 с помощью команды show protocols, он должен быть Established:
bird> show protocols
name proto table state since info
kernel1 Kernel master up 2022-12-10
device1 Device master up 2022-12-10
static_bgp Static master up 2022-12-10
bgp1 BGP master up 2022-12-10 Established
Ну и конечно команда show route должна показывать маршрут который мы отдаем соседу, а также маршруты, которые приезжают от него:
bird> show route
10.1.1.2/32 via 10.2.2.42 on enp1s0d1 [static_bgp 2022-12-10] ! (200)
172.16.21.0/23 via 10.2.2.41 on enp1s0d1 [bgp1 2022-12-10] * (100) [AS65xxx?]
172.16.22.0/23 via 10.2.2.41 on enp1s0d1 [bgp1 2022-12-10] * (100) [AS65xxx?]
...
Так как в случае если бы у нас действительно был свич, исходящие пакеты, перенаправляемые им с торговых IP адресов на выходе в сторону биржи имели бы source MAC адрес порта коммутатора, в который подключен аплинк до биржи, то никакого конфликта быть не должно. Единственное что, стоит помнить, что все пакеты, отправляемые в сторону сетей, которые известны нам благодаря работе BGP, по умолчанию, без указания source IP, используя правила маршрутизации из таблицы main, будут отсылаться с IP нашего «виртуального» коммутатора. Поэтому в ПО, которое должно слать заявки на биржу, нужно в явном виде будет указывать source IP, и чтобы собрать корректный исходящий пакет нам также потребуется MAC адрес соседнего биржевого свича, но его легко посмотреть в нашей ARP табличке, ведь наш виртуальный свич уже корректно коммуницирует с ним.
Похожую настройку придется делать и для варианта с установкой промежуточного L1 свича от Cisco, но в таком случае для отправки корректных пакетов там придется узнать MAC-адрес порта свича, который смотрит в сторону биржи. Тогда как на свичах Arista 7130 Series в мультиплексор (коммутирующую матрицу) подключен логический интерфейс коммутатора, который может осуществлять BGP пиринг и также подписываться по PIM (Protocol Independent Multicast) на интересующие вас потоки биржевых данных. Что в некоторых случаях может быть удобно, учитывая заявленную задержку мультиплексирования от 39нс у обоих производителей.
