|
Líneas de backup y jaleo asociado
|
|
Por luchonidas
departamento Preguntemos-a-Libertonia , Sección Diarios
Puesto a las Fri Jan 2nd, 2004 at 11:50:27 AM CET
|
 |
Año nuevo, diario nuevo, así que... vamos a estrenar el diario y que mejor método que contar con lo que uno está liado.
|
Bueno, esta entrada del diario, aunque parece una pregunta a la comunidad de Libertonia (bastante aletargada con esto de las navidades [nada malo, disfrutad, disfrutad ;) ]) es lo que parece. Hala, hala, este recién comienza y ya está preguntando :) Bueno, llevo bastante tiempo leyendo Libertonia, casi desde que me enteré que existía, por Barrapunto, menos tiempo registrado, y menos colaborando. Así que desde ya un saludo y un gracias a todos los libertonianos que algún momento dado han dado su ayuda.
Nota aclaratoria... no estoy pidiendo que "hagan mi tarea", solamente estoy lanzando una idea al aire para ver si es posible o si hay algo mejor que lo que se me ha ocurrido. Ya conozco la madurez de la gente que normalmente lee Libertonia, pero mejor prevenir que curar.
Estoy trabajando actualmente en una empresa que ofrece los clásicos servicios de housing y hosting. La conectividad a internet nos la da Uni2, a través de una línea DSL (no estoy seguro, tengo que revisar la documentación), y tenemos 256 IP. Bueno ¿pero este que problema tiene? os preguntaréis. Mi problema es que los de Uni2 no nos garantizan la conectividad y a veces la línea se ha ido de paseo un sabado, domingo, u otra fiesta de guardar, incluso entre semana, y no tenemos una línea de backup...
Entonces se me ocurrió la idea: Por qué no usar el adsl de la oficina como línea de backup... si, ya se que es más fácil el contratar otra línea con otro proveedor y hacer de alguna forma para que nuestro rango de IP's sean accesibles por la otra línea, como supongo que harán los proveedores con un data center decente, pero como la pela es la pela, tengo que apañármelas con lo que tengo.
Volviendo a la idea genial, comencé a ponderar las posibles soluciones, y dado que en internet no he encontrado casi nada (casi todo lo que he encontrado está relacionado con balanceo de carga, que no me viene mal, o con líneas de backup con ADSL+RDSI), he comenzado a ponderar mis propias soluciones. Por el momento he llegado a tres posibles soluciones, cada una con su parte buena y su parte mala.
Nota: En estas soluciones solo se habla del enrutamiento de los paquetes, sobre como tratar los servicios ya hablaré en otra entrada.
La estructura actual de la red es la siguiente (a ver si sale bonita): /\__/\__
+----| INET \-------+
| \/\___/\/ |
| |
| |
|256 IP's | UNA SOLA IP
+-----+-------+ +------+------+
| Router Uni2 | | Router ADSL |
+-----+-------+ +------+------+
| |
| |
+----------+ +-------+ /\__/\__
| Firewall | | Proxy +--------| LAN \
+----------+ +-------+ \/\___/\/
| |
| |
+---------+-----------+
|
|
SERVIDORES
Decididamente el arte ASCII no es lo mío :). ¿Cómo se hace para que me respete la fuente en el <pre>, ya que pasa de mi?
Antes de poner las soluciones, añadir que tenemos tres servidores DNS, dos en la red de servidores, saliendo por la línea de UNI2 y un tercero en el proxy, saliendo por el ADSL normal.
Soluciones:
- Si se cae la línea de UNI2, entonces el DNS del proxy cambia las resoluciones de los dominios, y los servidores cambian la ruta de salida (por aquello del correo pendiente de salir). Es la solución más fácil, pero depende demasiado del tiempo de vida del DNS, y de que el DNS lo tengamos nosotros, cosa que no ocurre con todos los dominios.
- En el DNS, por cada dominio, aparecen dos entradas, una con la IP del servidor, y otra con la de la línea de backup. Cada petición se responde por la línea que llega. Es una solución fácil también, pero los paquetes que vienen y van por la línea de backup irán más lentos (no olvidemos que es una ADSL 256/128) y pueden saturar la conexión de la LAN a Internet (ahí entra el balanceo de carga y el QOS). Si cae alguna de las líneas entonces fallan la mitad de los servicios.
- Esta solución es parecida a la anterior, pero si funciona la línea de uni2 y el firewall, entonces el proxy reenvía todo lo que le llega de los servidores y que es una respuesta de una petición anterior para que salga por la línea de Uni2, pero enmascarando el origen (cambia la IP de origen del paquete). Es una solución más difícil, que necesita alterar paquetes, pero es más efectiva, ya que la línea de backup solo está ocupada la mitad (paquetes entrantes, no salientes), y la salida es más rápida. Si cae una de las líneas nos encontramos con el mismo problema que en la solución anterior, fallan la mitad de las peticiones.
Supongo que una buena solución incluye combinar parte de la solución uno con la tres, pero mi duda es si es posible realizar la tercera solución con las posibilidades estandar de un núcleo linux 2.4, o será necesario currarme algún programa que me modifique y re-enrute los paquetes por la otra red (el proxy es la salida de la WAN). Según he podido averiguar, hay alguna posibilidad de hacerlo usando iptables ([1] [2]) + iproute2, pero me gustaría saber si hay alguna solución más fácil, algo que ya haya hecho alguien (por aquello de no reinventar la rueda), o con otro S.O. (free a ser posible).
Bueno, acabo ya esta entrada a mi diario, dejándo reposar todas estas ideas todo el fin de semana. Intentaré probar alguna de las ideas que he tenido, a ver que resultado me dan. Desde ya muchas gracias a todas las posibles ideas que surjan, y cuando tenga algo funcional prometo sacar una entrada en mi diario o enviar una explicación detallada.
Por cierto... ¿Alguien conoce alguna web o proyecto que haya centralizado (o tenga ganas) la búsqueda de documentación sobre linux y otros S.O.?. Porque la búsqueda con Google da buenos resultados, pero en ocasiones los resultados son un poco confusos.
Un saludo a todos, y feliz año nuevo. |
|
|
