Me han pedido que reconstruya nuestra infraestructura de equilibrio de carga en el centro de datos.
La solicitud original era equilibrar la carga de los servidores FTP. Intenté hacerlo usando el equilibrador de carga actual ( Piranha / LVS), pero no lo puse en funcionamiento. No solo porque hay poca o ninguna documentación para este software. Dado que Piranhase considera obsoleto, fui HAProxydespués de un par de días intentándolo, lo que hizo el trabajo en una fracción del tiempo dedicado Piranha.
Así que tengo el equilibrio de carga FTP (modo pasivo) en su lugar. Ahora, me pidieron que reemplazara todo el equilibrador de carga de Piranha en el centro de datos. En la configuración actual de Piranha, tenemos varios servidores web, servidores IIS ... aaa y DNS .
No, aquí está la cosa:
HAProxyparece ser un LB de uso común, pero no es capaz de manejarUDP load balancing . Esto es un fastidio, ya que me gusta cómo HAProxyfunciona. Así que busqué mucho en Google y encontré varias cosas. La mayoría de las personas parecen usar LVScomo LB para DNS (TCP / UDP). Algunos usan dlbDNS, algunos usan lbnamedy algunos usan netfilter / iptables.
Como me gustaría seguir con los HAProxyservidores FTP, HTTP, IIS, me confundí al usarlo junto con LVS.
Requisitos:
2 instancias de LB con conmutación por error
2 servidores DNS (ya existentes) con conmutación por error
Múltiples servidores de fondo (http, aplicación, etc.)
Preguntas:
¿Es esto posible? ¿Es necesario el equilibrio de carga UDP en los servidores DNS? ¿Hay algún tipo de recurso que pueda mostrarme cómo comenzar con eso? ¿O hay una solución LB que es capaz de manejar no solo TCP / HTTP, sino también el equilibrio de carga UDP?
PD: La solución LB debe ser sin hardware y de código abierto / licencia GPL / sin costo.
Cualquier ayuda o conducir a los recursos respectivos es muy apreciada!
fuente
Respuestas:
No cargue el equilibrio de su DNS.
Es un protocolo increíblemente liviano: necesitaría una enorme cantidad de tráfico para necesitar más de una casilla (en cuyo caso, de todos modos, se quedará con un cuello de botella en su equilibrador de carga), y hay resistencia incorporada porque puede usar múltiples registros NS en su delegación (se usarán otros servidores si uno está caído).
fuente
Me siento incómodo con estas preguntas y respuestas porque realmente no se ha establecido de qué tipo de servidor DNS está hablando. Hay algunos conceptos erróneos significativos cuando se trata de la resistencia del DNS recursivo y es importante que las personas que navegan a través de los motores de búsqueda no se salgan de esta discusión con una falsa sensación de seguridad.
DNS autorizado: para servidores DNS autorizados, el conocimiento común sobre la resistencia del DNS es bastante acertado. Siempre que tenga varios servidores DNS autorizados que sean geo-redundantes, estará bien. La razón principal para agregar alta disponibilidad para IP individuales es si aloja muchas zonas autorizadas. Esto le permite aumentar su número de servidores sin tener que cambiar la configuración del registrador para cada dominio alojado.
DNS recursivo : utilice siempre alguna forma de solución de alta disponibilidad. (BGP, electrodomésticos, etc.) Aquí es donde puede meterse en problemas serios. Todas las bibliotecas de resolución no se crean de la misma manera: los clientes DNS de Windows utilizarán el servidor inicial utilizado entre consultas, pero la mayoría de los sistemas basados en Unix siempre recorrerán la lista secuencialmente. Lo que es aún menos conocido es que estas bibliotecas de Unix tendrán que agotar el tiempo de espera en cada combinación de dominio de búsqueda antes de pasar al siguiente servidor. Si tiene múltiples dominios de búsqueda configurados y el primer servidor en el orden de búsqueda de resolución está muerto, esto puede crear retrasos significativos en la resolución de DNS para cada solicitud: más que suficiente para causar problemas dentro de sus aplicaciones críticas.
Cuando se trata de DNS recursivo, recuerde que la infraestructura de su servidor es tan resistente como la configuración del cliente más inteligente. A medida que su empresa crece, esto es algo sobre lo que nunca tiene control. No haga suposiciones de diseño basadas en un entorno de sistema operativo de servidor homogéneo, ya que las cosas rara vez permanecen igual en una empresa en crecimiento. Esto definitivamente morderá a alguien si no planeas con anticipación.
fuente
En estos días puedes usar
dnsdistPowerDNSDesde el README
https://github.com/PowerDNS/pdns/tree/master/pdns/dnsdistdist
Proporcionan repositorios para sistemas operativos comunes: https://repo.powerdns.com/
fuente