Pregunta de configuración global de alta disponibilidad

Soy propietario y opero visualwebsiteoptimizer.com /. La aplicación proporciona un fragmento de código que mis clientes insertan en sus sitios web para rastrear ciertas métricas. Dado que el fragmento de código es JavaScript externo (en la parte superior del código del sitio), antes de mostrar el sitio web de un cliente, el navegador de un visitante se pone en contacto con nuestro servidor de aplicaciones. En caso de que nuestro servidor de aplicaciones se caiga, el navegador seguirá intentando establecer la conexión antes de que se agote el tiempo de espera (generalmente 60 segundos). Como puede imaginar, no podemos permitirnos tener nuestro servidor de aplicaciones inactivo en cualquier escenario porque afectará negativamente la experiencia no solo de los visitantes de nuestro sitio web, sino también de los visitantes de nuestros clientes.

Actualmente estamos utilizando un mecanismo de conmutación por error de DNS con un servidor de respaldo ubicado en un centro de datos diferente (en realidad, en un continente diferente). Es decir, monitoreamos nuestro servidor de aplicaciones desde 3 ubicaciones separadas y tan pronto como se detecta que está inactivo, cambiamos un registro A para apuntar a la IP del servidor de respaldo. Esto funciona bien para la mayoría de los navegadores (ya que nuestro TTL es de 2 minutos), pero IE almacena en caché el DNS durante 30 minutos, lo que podría ser un factor decisivo. Vea esta reciente publicación nuestra visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

Entonces, ¿qué tipo de configuración podemos usar para garantizar una conmutación por error casi instantánea en caso de que el centro de datos de la aplicación sufra una interrupción importante? Leí aquí www.tenereillo.com/GSLBPageOfShame.htm que tener múltiples registros A es una solución, pero no podemos permitirnos la sincronización de sesiones (todavía). Otra estrategia que estamos explorando es tener dos registros A, uno que apunta al servidor de aplicaciones y el segundo a un proxy inverso (ubicado en un centro de datos diferente) que resuelve al servidor de aplicaciones principal si está activo y al servidor de respaldo si está activo. ¿Crees que esta estrategia es razonable?

Solo para estar seguros de nuestras prioridades, podemos permitirnos mantener nuestro propio sitio web o aplicación inactiva, pero no podemos permitir que el sitio web de los clientes se desacelere debido a nuestro tiempo de inactividad. Entonces, en caso de que nuestros servidores de aplicaciones estén caídos, no tenemos la intención de responder con la respuesta predeterminada de la aplicación. Incluso una respuesta en blanco será suficiente, solo necesitamos que el navegador complete esa conexión HTTP (y nada más).

Referencia: leí este hilo que fue útil serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure

Tu situación es bastante similar a la nuestra. Queremos centros de datos divididos y conmutación por error de tipo de capa de red.

Si tiene el presupuesto para hacerlo, entonces lo que quiere es dos centros de datos, múltiples tránsitos IP a cada uno, un par de enrutadores de borde que realizan sesiones BGP a sus proveedores de tránsito, anunciando sus direcciones IP a Internet global.

Esta es la única forma de hacer una verdadera conmutación por error. Cuando los enrutadores notan que la ruta a sus servidores ya no es válida (lo que puede hacer de varias maneras), dejan de anunciar esa ruta y el tráfico va al otro sitio.

El problema es que, para un par de enrutadores de borde, inicialmente está buscando un costo bastante alto para configurarlo.
Luego, debe configurar la red detrás de todo esto, y es posible que desee considerar algún tipo de conectividad Layer2 entre sus sitios como un enlace punto a punto para que pueda enrutar el tráfico entrante a un centro de datos, directamente al otro en caso de falla parcial de su sitio primario.

¿Mejores prácticas de BGP Multihomed / Multi-location y la mejor manera de mejorar la resiliencia? son preguntas que hice sobre temas similares.

La página de vergüenza de GSLB plantea algunos puntos importantes, por eso, personalmente nunca elegiría voluntariamente un GSLB para hacer el trabajo de enrutamiento BGP.

También debe mirar los otros puntos de falla en su red. Asegúrese de que todos los servidores tengan 2 NIC (conectados a 2 conmutadores separados), 2 unidades de suministro de energía y que su servicio esté compuesto por varios servidores de back-end, como pares redundantes o clústeres con equilibrio de carga.

Básicamente, el "equilibrio de carga" de DNS a través de múltiples registros A es solo "compartir carga" ya que el servidor DNS no tiene idea de cuánta carga hay en cada servidor. Esto es barato (gratis).

Un servicio GSLB tiene un concepto de qué tan cargados están los servidores y su disponibilidad, y proporciona una mayor resistencia a fallas, pero aún está plagado de problemas relacionados con el almacenamiento en caché y la vinculación de DNS. Esto es menos barato, pero un poco mejor.

Una red enrutada BGP, respaldada por una infraestructura sólida, es en mi humilde opinión, la única forma de garantizar realmente un buen tiempo de actividad. Puede ahorrar algo de dinero utilizando servidores de ruta en lugar de enrutadores Cisco / Juniper / etc., pero al final del día, debe administrar estos servidores con mucho cuidado. De ninguna manera es una opción barata, o algo que se emprenda a la ligera, pero es una solución muy gratificante y lo lleva a Internet como proveedor, en lugar de solo como consumidor.

Bien, esto fue preguntado hace un tiempo, pero ahora lo veo por primera vez.

el fragmento de código es JavaScript externo (en la parte superior del código del sitio), antes de mostrar el sitio web de un cliente, el navegador de un visitante se pone en contacto con nuestro servidor de aplicaciones.

Debieras:

1. Coloque su archivo Javascript en una buena y profesional red de entrega de contenido, es decir, compre HTTP (S) de alta disponibilidad que sirve el Javascript de alguien que ya tiene esa experiencia.
2. Programe su Javascript para que haya un buen estado de recuperación, es decir, si su servidor de aplicaciones no responde rápidamente, el usuario final ve una página normal y sin modificaciones.

Hacer cualquier otra cosa es irresponsable, de verdad. Supongo que ya tienes esto en su lugar.

Usted debe no basar su servicio en BGP trucos de enrutamiento menos que tenga u obtener el know-how para hacerlo. Los escenarios de enrutamiento BGP complejos son decididamente no triviales de implementar; no lo haga usted mismo si no tiene el conocimiento específico del dominio.

Tu pregunta en sí está un poco confundida. El análisis de cómo crear un servicio altamente disponible comienza con los datos de la aplicación , porque ese es su "estado". Las partes sin estado son fáciles de hacer altamente disponibles, las partes con estado completo no lo son. Entonces, en lugar de enfocarse en sus servidores y DNS, observe dónde mantiene el estado su aplicación . Comience optimizando allí y posiblemente pidiendo asesoramiento sobre algoritmos sobre Stack Overflow. ¿Podría implementar una noción de transacciones y reintento de servidor inteligente en su archivo Javascript fx?

En realidad, lo que desea podría actualizarse para ayudar a sus actividades de prueba divididas también si combina geodns y dns failover.

Enviar el grupo A a la ip 1 y el grupo B a la ip 2, incluso si estuvieran en el mismo servidor, le permitiría separar sus grupos de prueba. El Grupo A y el Grupo B son de diferentes regiones geográficas. Para ser justos, al día siguiente / semana / mes, voltea los grupos para asegurarse de que permite diferencias geográficas. Solo para ser riguroso en su metodología.

El servicio geodns / failover dns en http://edgedirector.com puede hacer esto

divulgación: estoy asociado con el enlace anterior, me encontré aquí investigando un artículo sobre la aplicación de trucos estúpidos de DNS para dividir las pruebas.