У меня есть минимальная 64-разрядная CentOS 6.3, работающая как шлюз с 4 сетевыми адаптерами (1 Гбит / с), каждая из которых связана вместе, одна для публичного трафика, а другая для частного, которая выполняет NAT. Он имеет 6 ГБ оперативной памяти и 4 логических ядра. Последние два года мы пользуемся им без проблем.
У меня нет опыта работы с аппаратными маршрутизаторами, но я слышал, что у них меньше ОЗУ и ЦП и используются флэш-диски. Как компьютер с низкой конфигурацией оборудования может работать лучше (например, обрабатывать большее количество одновременных подключений), чем компьютер с большим объемом ОЗУ и ЦП?
Каковы ограничивающие факторы, кроме IOS, использующих другие методы для решения этой проблемы?
ASIC.
Вместо использования ЦП общего назначения и программного обеспечения для решения конкретных задач вы можете пропустить программное обеспечение и просто заставить микросхему выполнять задачу напрямую.
Высокопроизводительное сетевое оборудование использует ASIC вместо программного обеспечения для вычислительно тяжелых (но относительно логически простых) задач, таких как сравнение IP-адреса с огромной таблицей интернет-маршрутизации, проверка таблицы CAM для принятия решения о переключении или проверка пакета по ACL . Это дает огромную разницу в скорости этих чувствительных ко времени операций, обеспечивая значительное преимущество по сравнению с ЦП общего назначения.
Высокопроизводительный выделенный маршрутизатор может превзойти ПК с более быстрым процессором и большим объемом оперативной памяти, поскольку он может выполнять больше аппаратной маршрутизации.
По той же причине, по которой коммутатор Gigabit Ethernet за 60 долларов может превзойти ПК за 2000 долларов с 4 двухпортовыми картами GigE, выступающими в качестве коммутатора Ethernet. Коммутатор построен с нуля, чтобы быть переключателем.
«Кроме IOS»?
IOS имеет почти все значение. CentOS - это операционная система общего назначения. Он разработан, чтобы работать достаточно хорошо в очень широком диапазоне сценариев с использованием огромного количества различных конфигураций оборудования. IOS, с другой стороны, чрезвычайно тонко настроена для обработки только тех рабочих нагрузок, которые вы ожидаете от части сетевого оборудования, с использованием очень специфических типов оборудования, которые вы найдете в оборудовании Cisco.
Зная именно От того, для какого оборудования вы программируете, потребуется очень много времени с точки зрения производительности и совместимости.
И программному, и аппаратному обеспечению есть что сказать. У меня есть сравнение Intel и TP-Link NIC (в основе которого лежит чип Realtek) на обычном серверном оборудовании, а также на специализированном и универсальном программном обеспечении для маршрутизации.
Что касается оборудования, то если встроенная ASIC может выполнять некоторую обработку IP-трафика, загрузка процессора может быть ниже и, следовательно, быстрее. Я заметил два встроенных чипа INtel NIC, которые обмениваются данными напрямую через DMA, минуя основной ЦП при обработке пересылки пакетов; Между тем чип Realtek прерывает поступление пакета.
Что касается программного обеспечения, если программное обеспечение предназначено для использования в маршрутизации, его можно сделать более эффективным. Я использовал как pfSense + PF (модифицированный FreeBSD, предназначенный для использования в качестве маршрутизатора), так и универсальный Ubuntu 12.04 + iptables в качестве программного обеспечения для маршрутизации, и первый явно переключает трафик намного быстрее. (Ubuntu 14.04 теперь работает почти так же быстро, благодаря новым nftables в ядре Linux 3.13.)
Однако у выделенного маршрутизатора есть один серьезный недостаток: он не может выполнять ничего, кроме коммутации трафика, и его нельзя виртуализировать. Мой текущий граничный маршрутизатор - это виртуальная машина внутри моего кластера ESXi под управлением Ubuntu 14.04, которая также действует как система обнаружения вторжений и балансировщик нагрузки.
AFAIK, это накладные расходы на операционную систему общего назначения; Независимо от того, насколько быстро ваши соединения, пакеты обрабатываются по отдельности в контексте ядра, увеличивая задержку и нагрузку на систему. Я считаю, что в других ответах это уже объяснено лучше, чем я мог бы сделать.
Сказав это, появляются новые многообещающие технологии, которые набирают популярность и возможности, которые могут создать из систем Linux более грозного конкурента как в этом, так и в других отношениях; то есть InfiniBand
Взгляните на следующие вопросы и ответы на StackOverflow: Как реализован обход ядра TCP
Дальнейшее чтение:
Обычно это происходит из-за отсутствия готовой конфигурации сетевого стека / устройств в Linux. Почти в 90% случаев ваш сетевой трафик обрабатывается CPU0, в то время как остальные находятся в режиме ожидания. Если вы решите эту проблему, разница с аппаратными маршрутизаторами будет не такой существенной, как вы думаете. Вы должны настроить как минимум RSS или RPS (распределение обработки пакетов на основе драйверов / стека между процессорами).
Если вы действительно заботитесь о производительности вашего Linux-роутера и у вас достаточно времени, я рекомендую вам прочитать это статья в блоге packagecloud (есть еще статья о передаче пакетов).
Если вам нужно взглянуть на распределение, и вы думаете, что смотрите на while sleep 1; do cat $some_file_in_procfs; done, Оценка маски ЦП и руководство smp_affinity писать скучно, вы бы наверняка нашли мой любимый проект netutils-linux очень полезно.