Когда используются протоколы туннелирования, такие как IPSec (в туннельном режиме) или GTP, они помещают несколько IP-потоков в один поток. Поскольку существует только один поток, как нам увеличить пропускную способность? Назначение большего количества ядер процессора не поможет, поскольку пакеты из одного потока могут поступать только на одно ядро. Есть ли способ обойти эту проблему? В моем случае проблема в GTP. Узлы eNodeB помещают все IP-потоки от UE в туннель GTP, для которого все 5-кортежи будут одинаковыми. Поскольку у нас всего от 5 до 10 eNodeB, это приводит к тому же количеству IP-потоков. Следовательно, использование ядер становится очень неравномерным: ядра используются> 80%, а некоторые - <10%. Каждый поток обрабатывается одним ядром, поэтому переупорядочение пакетов не происходит. Поскольку тысячи IP-потоков туннелируются всего в 5-10 IP-потоков, случайность хеш-функции RSS каким-то образом становится неравномерной, в результате чего несколько ядер перегружаются, а некоторые все еще простаивают.
Было бы правильно назвать это проблемой, присущей любому протоколу туннелирования? Есть ли способ обойти это? Кроме того, какова максимальная пропускная способность одного потока? Я просто ищу здесь контрольные цифры для любого оборудования. Вы даже можете поделиться результатами IPSec в туннельном режиме. Какой пропускной способности вы можете достичь с помощью одного туннеля IPSec и что обычно делают администраторы для увеличения пропускной способности?
Сеть может быть узким местом с протоколом туннелирования или без него. В какой-то момент скорость передачи объединительной платы не может поспевать за скоростью передачи данных по сети. Обычно весь трафик направляется через один сетевой интерфейс, который объединяет несколько соединений.
Должна быть предусмотрена возможность параллельного выполнения шифрования / дешифрования отдельных потоков. За исключением дополнительного трафика объединительной платы, использование зашифрованного туннеля не должно значительно ограничивать пропускную способность сети с несколькими сетевыми потоками.
Аппаратные ускорители шифрования могут помочь, если накладные расходы на шифрование являются проблемой. Однако похоже, что у вас достаточно ЦП, что не должно быть проблемой.
Если ваше приложение перегружает сетевой канал, можно связать несколько интерфейсов для увеличения пропускной способности. Коммутатор, к которому подключен ваш сервер, должен поддерживать связывание каналов.
Использование более быстрой сетевой карты может помочь, но в конечном итоге вы достигнете скорости, с которой ваша объединительная плата не сможет справиться.
Сетевые устройства также имеют ограничения по емкости, и ваши требования превышают эту емкость. В этом случае ваша сетевая инфраструктура становится узким местом.
Из-за кэширования памяти может не иметь смысла равномерно распределять нагрузку между несколькими процессорами. Приложение часто будет работать быстрее, если оно будет продолжать работать на одном процессоре, чем если оно часто планируется на разных процессорах.
Проблема, которую вы описываете, не связана с протоколами туннелирования. Скорее, это больше связано с наличием шифрования, чем с туннелированием.
Существует приоритет для реализаций ECMP, проверяющих поля на более высоких уровнях протокола, чем это работает. Например, ECMP, работающий на уровне IP, часто проверяет номера портов UDP и TCP. Реализация ECMP не будет отличаться от проверки IP-адресов во внутреннем IP-заголовке туннелированного пакета.
Однако из-за шифрования эта информация недоступна без расшифровки пакета. А возможность различать потоки, не зная ключа шифрования, обычно считается недостатком безопасности в алгоритме шифрования. Это важный момент, о котором следует помнить, поскольку вам, возможно, придется пойти на компромисс между производительностью и безопасностью.
Возможные решения, о которых я могу думать, включают:
Скопируйте метку потока из внутреннего заголовка IP во внешний заголовок IP во время шифрования. Это, очевидно, приведет к утечке информации о содержимом метки потока.
Настройте несколько туннелей и выполните ECMP через туннели. Реализация ECMP на отправляющем конце соединения будет пытаться равномерно распределить трафик по туннелям. Однако в зависимости от шаблонов трафика может оказаться невозможным равномерное распределение трафика по туннелям. Такое неравномерное распределение по туннелям проблематично не только потому, что оно может привести к неоптимальному использованию базовой сети, но и потому, что оно приводит к утечке некоторой информации о характеристиках незашифрованного трафика. Однако утечка в этом случае будет намного менее значительной, чем раскрытие частей внутреннего IP-заголовка.
Разрешить дешифрование произвольных пакетов параллельно, но вернуть их в исходный порядок после дешифрования. В очень простой реализации есть один поток, отвечающий за циклическую отправку пакетов нескольким потокам дешифрования. После дешифрования другой поток будет забирать расшифрованные пакеты циклически из потоков дешифрования, возвращая их в исходный порядок.
Этот подход возможен только в том случае, если вы считаете, что все ваши потоки являются доменом с единичным отказом, и связь между потоками не подвержена потере пакетов. Другими словами, использование этого подхода для распределения пакетов по циклическому алгоритму между различными сетевыми устройствами не сработает.
Расшифровать в промежуточный незашифрованный формат, который содержит незашифрованные данные и порядковый номер IPSec. Расшифровка может выполняться параллельно, после чего пакеты передаются компоненту, который буферизует ограниченное количество пакетов и пытается вернуть пакеты обратно в исходном порядке на основе максимальных усилий.
Перепроектируйте протоколы более высокого уровня, чтобы они были более терпимыми к изменению порядка.