Pourquoi un routeur matériel fonctionne-t-il mieux qu'un routeur Linux avec de meilleures spécifications (RAM et CPU)?
J'ai un CentOS 6.3 minimal, 64 bits agissant comme passerelle avec 4 NIC (1 Gbps), chacun lié ensemble pour le trafic public et l'autre pour le privé, qui effectue le NATing. Il a 6 Go = RAM et 4 cœurs logiques. Nous l'utilisons depuis deux ans sans aucun problème.
Je n'ai aucune expérience avec les routeurs matériels, mais j'ai entendu dire qu'ils ont moins RAM et CPU et utilisent des disques flash. Comment une boîte avec une configuration matérielle faible peut-elle mieux fonctionner (comme dans, gérer plus de connexions simultanées) qu'une machine avec plus RAM et CPU?
Quels sont les facteurs limitants, autres que IOS utilisant différentes méthodes pour gérer cela?
ASIC .
Au lieu d'utiliser un processeur généraliste et un logiciel spécifique à une tâche, vous pouvez ignorer le logiciel et simplement faire en sorte que le silicium gère directement la tâche.
Le matériel de mise en réseau hautes performances utilise des ASIC au lieu de logiciels pour les tâches de calcul lourdes (mais relativement logiquement simples) de quelque chose comme comparer une adresse IP à une énorme table de routage Internet, vérifier une table CAM pour une décision de commutation ou vérifier un paquet par rapport à une ACL . Cela fait une énorme différence dans la vitesse de ces opérations sensibles au temps, offrant un avantage significatif par rapport à un CPU à usage général.
Un routeur dédié haut de gamme peut surpasser un PC avec un processeur plus rapide et plus RAM car il peut faire plus de routage dans le matériel.
C'est la même raison pour laquelle un commutateur Ethernet Gigabit à 60 $ peut surpasser un PC à 2000 $ avec 4 cartes GigE à deux ports agissant comme un commutateur Ethernet. Le commutateur est construit à partir du sol pour être un commutateur.
"Autre que IOS"?
IOS fait presque toute la différence. CentOS est un système d'exploitation à usage général. Il est conçu pour fonctionner suffisamment bien dans un très large éventail de scénarios, en utilisant un large éventail de configurations matérielles différentes. IOS d'autre part est extrêmement finement réglé pour gérer uniquement le type de charges de travail que vous attendez d'un équipement réseau, en utilisant les types de matériel très spécifiques que vous trouverez dans l'équipement Cisco.
Savoir exactement pour quels composants matériels vous programmez vous prendra beaucoup de temps en termes de performances par rapport à la compatibilité.
Les logiciels et le matériel ont quelque chose à dire. J'ai la comparaison d'Intel et de TP-Link NIC (qui utilise une puce Realtek en son cœur) sur du matériel serveur générique, ainsi que des logiciels spécialement conçus et génériques pour le routage.
Côté matériel, si le ASIC à bord peut gérer le trafic IP, la charge du processeur peut être plus faible et donc plus rapide. J'ai remarqué les deux INtel intégrés NIC puces communiquant directement par DMA, contournant le processeur principal lors de la gestion du transfert de paquets; pendant ce temps, la puce Realtek interrompt chaque fois qu'un paquet arrive.
Du côté logiciel, si le logiciel est conçu pour être utilisé dans le routage, il peut être rendu plus efficace. J'ai utilisé à la fois pfSense + PF (un FreeBSD modifié destiné à être utilisé comme routeur) et Ubuntu 12.04 + iptables à usage générique comme logiciel de routage et le premier a clairement changé le trafic beaucoup plus rapidement. (Ubuntu 14.04 est maintenant presque aussi rapide, grâce aux nouveaux nftables du noyau Linux 3.13.)
Cependant, le routeur dédié présente un inconvénient majeur: il ne peut pas faire beaucoup plus que de commuter le trafic et il ne peut pas être virtualisé. Mon routeur Edge actuel est une machine virtuelle à l'intérieur de mon cluster ESXi exécutant Ubuntu 14.04, et il agit également comme un système de détection d'intrusion et un équilibreur de charge.
AFAIK, c'est la surcharge d'un système d'exploitation à usage général; quelle que soit la vitesse de vos connexions, les paquets sont traités paquet par paquet dans le contexte du noyau, ce qui augmente la latence et la pression sur le système. Je crois que cela a déjà été expliqué dans les autres réponses mieux que je ne pourrais le faire.
Cela dit, il existe de nouvelles technologies "ish" prometteuses qui gagnent en popularité et en faisabilité, ce qui pourrait créer un concurrent plus redoutable des systèmes Linux dans ce domaine ainsi qu'à d'autres égards; c'est-à-dire InfiniBand
Jetez un œil aux questions/réponses suivantes sur StackOverflow: Comment est TCP Kernel-bypass Implemented
Lectures complémentaires:
C'est généralement dû au manque de configuration de pile/périphériques réseau prête à l'emploi sous Linux. Dans près de 90% des cas, votre trafic réseau est traité par CPU0 tandis que d'autres sont inactifs. Si vous résolvez ce problème, la différence avec les routeurs matériels ne sera pas aussi radicale que vous ne le pensez. Vous devez configurer au moins RSS ou RPS (distribution de traitement des paquets basée sur les pilotes/piles entre les CPU).
Si vous vous souciez vraiment des performances de votre routeur linux et que vous avez suffisamment de temps, je vous recommande de lire ceci article dans le blog packagecloud (il y a aussi un article sur la transmission de paquets).
Si vous devez jeter un œil à la distribution et que vous pensez que regarder while sleep 1; do cat $some_file_in_procfs; done, Évaluation du masque CPU et manuel smp_affinity l'écriture est ennuyeuse, vous auriez probablement trouvé mon animal de compagnie netutils-linux extrêmement utile.