Recientemente, he ayudado a una estación de comercio electrónico para hacer frente al problema de conmutación de nodo de CDN de alta defensa, y su negocio casi se derrumbó debido a la latencia de nodo pico. Eché un vistazo a los antecedentes en el feliz - este amigo en realidad la conmutación de nodos como una operación de luz del interruptor, corte duro manual directo, el resultado es que las quejas de los usuarios como copos de nieve volando en.
Cambio de nodo en una CDN de alta defensa no es simplemente una cuestión de "cambiar la carretera", es más como cambiar los neumáticos cuando estás corriendo por la autopista. Usted tiene que considerar el tráfico de negocios, mantenimiento de sesiones, caché de DNS, volver a la política de origen de estas cosas, un poco descuidado es 500 pantalla de error.
¿Por qué los nodos se convierten en cuellos de botella empresariales?Descubrí que el 80% del problema reside en la "excesiva confianza en la configuración por defecto". Muchos equipos piensan que comprar una CDN de alta defensa está bien, pero cuando el nodo es penetrado por DDoS, no hay alternativa. No hay que olvidar que hoy en día incluso las CDN tienen que "prevenir a los compañeros de equipo": la monitorización de nodos de algunos proveedores de servicios es simplemente para aparentar.
Empecemos con un escenario típico de conmutación manual. Cuando descubres que el tiempo de respuesta de un nodo se dispara de 50ms a 2000ms, tu primera reacción es sin duda "cortar por lo sano". Pero si desconecta directamente el nodo, la conexión TCP establecida se interrumpirá de repente, y el pedido a medio pagar del usuario se perderá.
La conmutación manual fiable tiene que pasar por el proceso de escala de grises: primero el peso del nuevo nodo a 5%, observar 15 minutos de estabilidad y luego aumentar gradualmente la proporción. Utilicé la API CDN5 para hacer experimentos, la tasa de fallos de la conmutación instantánea forzada llega a 37%, mientras que la tasa de fallos de la conmutación a escala de grises es casi nula.
Para mostrarle un ejemplo de configuración en vivo, aquí tiene el script para el cambio de escala de grises utilizando la API de CDN5:
Pero la conmutación manual es, en última instancia, cosa de bomberos. Lo realmente fiable es el sistema de conmutación automática. Una buena conmutación automática debería ser como el piloto automático: cambiar de carril antes de detectar el peligro.
He comparado las soluciones de los tres principales proveedores de servicios: el enrutamiento inteligente de CDN5 se basa en el análisis de firmas de ataques en tiempo real, CDN07 se basa en la supervisión global de sondas y 08Host ha desarrollado un algoritmo de predicción de tráfico propio. Para ser sinceros, no existe una solución perfecta, la clave depende de las características del negocio.
No te creas la propaganda de que "no hace falta configuración".. ¿Recuerdan el fallo de conmutación automática de un proveedor de nube el año pasado? Debido a un error de apreciación de las características del tráfico, las peticiones normales de los usuarios se transfirieron todas al nodo en espera y, como resultado, el nodo en espera fue directamente perforado. Una buena conmutación automática debe configurarse con un mecanismo de fusión:
Aquí hay una lección que aprender: debes configurar una política de retroceso para la conmutación automática. Una vez no configuré las condiciones de rollback, el tráfico de recuperación del nodo se cortó automáticamente, y entonces se desencadenó un segundo fallo. Ahora mi práctica estándar es observar al menos 2 horas de estabilidad antes de hacer un rollback automático.
Cuando se trata de la conmutación DNS, el pozo es aún más profundo. La fijación del valor TTL es un arte, algunos equipos lo fijan en 60 segundos por rapidez, y el resultado es que las consultas DNS se disparan y arrastran a los servidores autorizados. Se recomienda utilizar un TTL de 300 segundos durante las horas punta, y bajarlo a 60 segundos durante el mantenimiento nocturno. No olvides que también existe el problema de la validez local, la actualización de la caché DNS en algunas zonas puede ser tan lenta que dudes de tu vida.
Hace poco estuve ayudando a un cliente financiero a diseñar una solución de doble actividad y descubrí que la conmutación automática basada en Anycast es la solución definitiva. Aunque el coste es tan elevado que hace sufrir a la gente, se trata realmente de una conmutación sin percepción por parte del usuario. Especialmente contra los ataques DDoS, Anycast puede distribuir el tráfico a nodos globales, mucho más fiable que un único punto de defensa.
Por último, una sugerencia sólida: debes hacer un simulacro de fallo cada mes. Desenchufa directamente el cable de alimentación del nodo maestro para ver si la conmutación automática puede realmente llevarse a cabo. He visto demasiados equipos configurarlos y luego tirarlos a un lado, y cuando algo va realmente mal, descubren que la monitorización y las alertas no están configuradas correctamente.
Cambiar de nodo es esencialmente hacer un balance de riesgos. Demasiado rápido puede desencadenar una reacción en cadena, demasiado lento ampliará el impacto del fracaso. Después de tantas paradas en boxes prácticos, mi principio es: la prioridad del pico de negocio con la estabilidad con la conmutación a escala gris, mantenimiento nocturno puede tratar de recuperación automática de desastres, las principales actividades se deben hacer antes de la prueba de presión de enlace completo.
Comprueba ahora la configuración de tu CDN y comprueba si la estrategia de conmutación de nodos sigue anclada en la edad de piedra. No olvides que la mejor conmutación es siempre la que los usuarios ni siquiera sienten.
