Ejecutamos exclusivamente enrutadores / cortafuegos de OpenBSD para servir FogBugz On Demand. A menos que esté operando en una función de tránsito y necesite el rendimiento pps extremadamente alto que puede proporcionar el hardware y el software integrado especialmente diseñados, OpenBSD en hardware sólido será una solución más manejable, escalable y económica.
Comparando OpenBSD con IOS o JUNOS (en mi experiencia):
Ventajas
- El cortafuegos pf no tiene comparación en términos de flexibilidad, configuración manejable e integración en otros servicios (funciona a la perfección con spam, ftp-proxy, etc.). Los ejemplos de configuración no le hacen justicia.
- Obtiene todas las herramientas de a * nix en su puerta de enlace: syslog, grep, netcat, tcpdump, systat, top, cron, etc.
- Puede agregar herramientas según sea necesario: iperf e iftop me han parecido muy útiles
- tcpdump. Basta de charla.
- Configuración intuitiva para veteranos de Unix
- Integración perfecta con la gestión de configuración existente (cfengine, puppet, scripts, lo que sea).
- Las características de la próxima generación son gratuitas y no requieren módulos adicionales.
- Agregar rendimiento es barato
- Sin contratos de soporte
Desventajas
- IOS / JUNOS simplifica el volcado / carga de una configuración completa. En ausencia de herramientas de administración de configuración, serán más fáciles de implementar una vez que se haya escrito su configuración.
- Algunas interfaces simplemente no están disponibles o son estables en OpenBSD (p. Ej., No conozco tarjetas ATM DS3 compatibles).
- Los dispositivos tipo Cisco / Juniper dedicados de alta gama manejarán pps más altos que el hardware del servidor
- Sin contratos de soporte
Siempre que no esté hablando de enrutadores de red troncal en un entorno similar a un ISP o enrutadores de borde que interactúan con conexiones de red especializadas, OpenBSD debería estar bien.
Hardware
Lo más importante para el rendimiento de su enrutador son sus NIC. Una CPU rápida se abrumará rápidamente con una carga moderada si tiene NIC de mierda que interrumpen por cada paquete que reciben. Busque NIC gigabit que admitan la mitigación / fusión de interrupciones al menos. He tenido buena suerte con los controladores Broadcom (bge, bnx) e Intel (em).
La velocidad de la CPU es más importante que en el hardware dedicado, pero no es algo de lo que preocuparse. Cualquier CPU moderna de clase de servidor manejará una tonelada de tráfico antes de mostrar cualquier tensión.
Consiga una CPU decente (los múltiples núcleos no ayudan mucho todavía, así que mire los GHz sin procesar), una buena RAM ECC, un disco duro confiable y un chasis sólido. Luego duplique todo y ejecute dos nodos como un clúster CARP activo / pasivo. Desde la actualización pfsync de 4.5 puede ejecutar active / active, pero no lo he probado.
Mis enrutadores se ejecutan lado a lado con nuestros equilibradores de carga en configuraciones de nodo doble de 1U. Cada nodo tiene:
- Chasis Supermicro SYS-1025TC-TB (NIC Intel Gigabit incorporadas)
- CPU Xeon Harpertown Quad Core 2GHz (mis equilibradores de carga usan los núcleos múltiples)
- 4 GB de RAM registrada Kingston ECC
- NIC de complemento Intel Gigabit de doble puerto
Han sido sólidos como una roca desde el despliegue. Todo sobre esto es excesivo para nuestra carga de tráfico, pero he probado un rendimiento de más de 800 Mbps (limitado por NIC, la CPU estaba inactiva en su mayoría). Hacemos un uso intensivo de las VLAN, por lo que estos enrutadores también deben manejar una gran cantidad de tráfico interno.
La eficiencia energética es fantástica ya que cada chasis de 1U tiene una sola fuente de alimentación de 700W que alimenta dos nodos. Hemos distribuido los enrutadores y equilibradores a través de múltiples chasis para que podamos perder un chasis completo y tener una conmutación por error prácticamente ininterrumpida (gracias pfsync y CARP).
Sistemas operativos
Algunos otros han mencionado el uso de Linux o FreeBSD en lugar de OpenBSD. La mayoría de mis servidores son FreeBSD, pero prefiero enrutadores OpenBSD por algunas razones:
- Un enfoque más estricto en seguridad y estabilidad que Linux y FreeBSD
- La mejor documentación de cualquier sistema operativo de código abierto
- Su innovación se centra en este tipo de implementación (consulte pfsync, ftp-proxy, carp, vlan management, ipsec, sasync, ifstated, pflogd, etc., todos los cuales están incluidos en la base)
- FreeBSD tiene varios lanzamientos atrás en su puerto de pf
- pf es más elegante y manejable que iptables, ipchains, ipfw o ipf
- Proceso de instalación / instalación más eficiente
Dicho esto, si está íntimamente familiarizado con Linux o FreeBSD y no tiene tiempo para invertir, probablemente sea una mejor idea ir con uno de ellos.