Mantenimiento del servidor MMORPG

Parece que la mayoría de los juegos de mmorpg tienen un mantenimiento regular del servidor, algunos todos los días, algunos una vez a la semana. ¿Qué es lo que realmente tienen que hacer y por qué es necesario?

Si comienzas con un proyecto así, ¿qué puedes hacer para evitarlo?

Sospecho que están implementando la última versión de su código, lo que requiere que reinicien la aplicación (y con suerte ejecuten algunas pruebas antes de volver a habilitar el acceso). Desde ese punto de vista, es más un problema de StackOverflow y menos un problema de ServerFault.

Creo que es posible crear un sistema de parches en caliente, pero necesariamente sería increíblemente complicado. Por lo que entiendo, una "aplicación" del servidor MMO consta de varios componentes diferentes:

• Servidor de inicio de sesión : maneja la autenticación y actúa como un "centro" entre los servidores de juego. Una vez que un cliente está en el juego, ya no interactúa con el servidor de inicio de sesión. En dicho sistema, podría aplicar parches y reiniciar el servidor de inicio de sesión sin interferir con el juego (aunque tendrá un período de tiempo en el que las personas no podrán iniciar sesión).

• Servidores de juego : grupos de máquinas agrupadas en unidades lógicas independientes ("mundos", etc.). Se supone que cada grupo de juego utiliza algún tipo de protocolo de comunicación interna para corresponder el estado entre sí; probablemente tendrá que parchear cada grupo de una vez. Una posible forma de hacerlo es parchear una conmutación por error en caliente. Entonces necesitarías poder ambas

  1. Indique al cliente que se conecte a la conmutación por error en caliente y desconéctese del clúster anterior.
  2. Mantenga el estado sincronizado entre la conmutación por error y el servidor de aplicaciones desactualizado mientras se transfieren todos los clientes.

• Servidores de bases de datos : algún tipo de almacén de datos persistente, como un RDBMS. Esperemos que no realice cambios en el almacén de datos con tanta frecuencia. Presumiblemente, cada servidor / clúster de juego tiene un almacén de datos independiente. Es posible que pueda usar el mismo truco con una conmutación por error cálida (y decirle a los servidores del juego que se desconecten, esperen a que se sincronicen las bases de datos antiguas y de conmutación por error, luego vuelva a conectarse a la conmutación por error), pero eso me parece bastante arriesgado.

Todos los casos anteriores agregan una increíble cantidad de complejidad a un sistema ya complejo e introducen un montón de lugares donde una falla en el código puede causar pérdida de datos o corrupción.

Otra solución es utilizar un lenguaje que esté diseñado para un tiempo de actividad del 100% y que tenga capacidades incorporadas para ejecutar código en caliente. Erlang es una buena opción ( ejemplo de hotpatching ), y Java tiene una funcionalidad similar .

¿Nadie más tiene experiencia realmente ejecutando algo como esto? Huh

Hay varias razones que unen tanto el código como los sistemas. Primero, recuerde que la mayoría de los motores MMO 'grandes' actuales se programaron hace varios años, y a pesar de las actualizaciones de gráficos y tecnología desde entonces, todavía dependen de la forma en que se escribieron muchos de estos sistemas en el año 2000 más o menos. Eve-Online, por ejemplo, todavía se ejecuta en una gran instancia de Microsoft SQL Server, por lo que siempre están tratando de sacar más provecho actualizando el hardware.

Un ejemplo de una mejora desde que WoW y EVE comenzaron es el trabajo realizado en bases de datos distribuidas de clave / valor como MapReduce de Google (y su implementación de código abierto, Hadoop), servicios de cola de procesamiento de respuesta afirmativa extremadamente rápidos (Amazon SQS) y otros " tecnologías orientadas a la nube ".

Tengo la mayor experiencia con EVE (soy más un tipo de láser que un tipo de hachas de batalla), por lo que algunos de estos ejemplos están más orientados a EVE.

En cuanto a las razones de los Sistemas:

• Los nodos físicos fallan de manera consistente. Cuando un nodo falla, generalmente su actividad se migra a otra parte utilizando cualquier cantidad de medios. Sin embargo, el nodo debe volver a ponerse en servicio lo más rápido posible. En el caso de EVE, utilizan un lenguaje de procesamiento sin pila y servidores virtuales; No estoy seguro de cómo es la arquitectura de Blizzard.
• La coherencia de la base de datos debe verificarse, los registros deben vaciarse y los índices y las memorias caché de datos deben reconstruirse. Esto es especialmente importante en un sistema como EVE con una sola instancia de base de datos "en vivo".
• Los parches del sistema operativo deben aplicarse en un momento en que puedan reiniciar los nodos sin tener que tener demasiada actividad migrando a otra parte. La migración ocupa muchos recursos de red que, de lo contrario, podrían dedicarse al procesamiento en línea.
• Los MMO basados ​​en RDBMS tienen grandes problemas con el bloqueo de datos y la integridad referencial. El tiempo de inactividad se utiliza para limpiar bloqueos obsoletos e interrupciones de integridad de los registros de actividad.
• La mayoría de los juegos implementan cachés de datos ubicados geográficamente para obtener información estática o semiestática (consulte los datos resumidos de almacenamiento en caché a continuación) en áreas de uso intensivo, es decir, la costa este frente a la costa oeste de EE. UU. Estas memorias caché se actualizan manualmente durante el tiempo de inactividad.

En cuanto a las razones del software:

• Los juegos, cuando funcionan, utilizan una gran cantidad de OLTP, que es el procesamiento de transacciones en línea, tipo de lecturas / escrituras en bases de datos. Sin embargo, a veces quieres un informe resumido ... como cuántas de una bestia en particular has matado en los últimos 3 años de molienda. Eso se maneja mejor con un informe OLAP, que es el procesamiento analítico en línea, que contiene información de resumen basada en muchas filas en un conjunto de datos gigante. En realidad, los juegos implementan sistemas que usan OLAP para construir un caché para limitar el número de consultas que deben leerse, es decir, generan un total a partir de una fecha determinada, y luego, cuando haces la pregunta, solo leen las filas de la tienda OLTP que resumen el período de tiempo desde la fecha determinada. Fusiona los dos y podrás cuantificar lo inútil que se ha vuelto tu vida.
• El parcheo en caliente mencionado anteriormente, que veo como un problema de software, pero los desarrolladores de software lo ven como un problema de sistemas. ;)
• Reponer las tiendas de artículos: en Eve, los cinturones de asteroides se renuevan todas las noches y también se reciclan ciertos complejos. Esto se puede hacer hasta cierto punto mientras está en línea, pero algunos de los algoritmos son demasiado complejos y deben hacerse en modo fuera de línea porque ponen brevemente la base de datos de rodillas mientras resumen la actividad económica del día anterior.

Manejar una economía con bucles cerrados y abiertos es un problema para los operadores de MMO: si no me cree, lea algunos de los documentos académicos que se han escrito sobre las economías de juegos y algunos de los estudios de juegos más antiguos como Ultima Online que tuvo economías relativamente primitivas. El análisis que debe realizarse para reponer los bucles abiertos e identificar trampas y otras actividades económicas negativas debe realizarse fuera de línea con una instantánea de los datos, que a veces solo se puede tomar mientras la base de datos está completamente bloqueada.

Si observa, el mantenimiento de Eve ocurre cuando es mediodía en Inglaterra, donde se encuentra el centro de datos principal.

Sospecho que el tiempo total que Blizzard (deduzco que dado que es un martes por la mañana que está publicando su pregunta) cotiza para el mantenimiento es para todo el clúster; No todos los servidores tardan tanto en realizar el trabajo.

Si bien es posible que los servidores individuales vuelvan a funcionar más rápidamente, eso provocaría gritos de favoritismo hacia los jugadores cuyos dominios cayeron antes en el calendario. Como tal, mantienen todo bajo hasta que se realiza todo el trabajo; Con cientos de reinos en los que trabajar, probablemente hagan gran parte del trabajo en paralelo, pero aún así serializan una verificación final antes de volver a poner las cosas en línea. Si está realizando una actualización de hardware, esto probablemente se serializa en tantos centros de datos como lo hayan hecho.

En cuanto a por qué realizan el mantenimiento, parte de esto podría ser solo un reinicio del rendimiento. Si bien sería genial si no se requirieran tales reinicios, el costo de hacerlo frente al impacto de no hacerlo podría estar dirigiendo su elección aquí.

Cuando observas por qué no pueden agrupar los procesos y realizar un mantenimiento continuo, lo que poca gente sabe de la infraestructura de WoW sugiere que varias máquinas brindan servicio para cada reino (es decir, una para el mundo, una para instancias y redadas, una para campos de batalla). , etc.) no utilizan una configuración de proceso activo-activo de estado compartido. No se comparte el estado en vivo, solo los datos persistentes a través de una base de datos.

Al final, la mecánica de proporcionar un servicio en línea con estado a una base de suscriptores tan grande desafía algunas de las mejores prácticas que podríamos adoptar al hablar de un sitio web u otro servicio tradicional basado en Internet.

Algunos de los tiempos de inactividad extendidos más recientes en EvE Online han sido sobre la instalación de nuevo hardware como una SAN más rápida. Si bien uno puede mover técnicamente la mayor parte de los datos creando un nuevo grupo de archivos en la nueva unidad y luego vaciando el principal, eso habría resultado en un período prolongado de rendimiento reducido debido a la constante E / S. Entonces optaron por separar la base de datos 1.1TB y moverla de una vez.

La respuesta a esta pregunta también se basa en la aplicación específica. Por ejemplo, un servidor que maneja un sistema estelar específico no se puede cambiar sin interrumpir el juego, por lo que el tiempo de inactividad se utiliza para reasignar servidores más potentes en puntos de acceso potenciales. Además, se calculan los cálculos de propiedad (soberanía) de los sistemas estelares. Esto depende de las decenas de diferentes variables, todas las cuales pueden cambiar según las acciones del jugador. No hace falta decir que hacer eso en vivo puede causar un bloqueo excesivo y / u otros problemas de concurrencia. Pero abordarlos es mejor dejarlo en stackoverflow .

presumiblemente algo con lo que no podría lidiar a través de la agrupación / equilibrio de carga, como los principales cambios de esquema de base de datos.

En un tema reciente ¿Con qué frecuencia debo reiniciar los servidores de Linux? Se mencionó otro buen punto, verificando que todo se inicia correctamente en un reinicio o después de cualquier cambio de configuración (importante).

Los juegos MMORPG también presentan una actualización simple de hardware (o reemplazo de hardware) como "mantenimiento del servidor". Tan trivial que a menudo lo olvidamos.

He implementado una arquitectura MMO en Erlang que admite actualizaciones y distribución de código activo. Por ejemplo, un "Servidor GamePlay" puede ejecutarse en un número arbitrario de máquinas, si uno necesita una actualización de hardware, sus objetos pueden transferirse (en tiempo real) a las otras máquinas. Esto permite actualizaciones en el hardware del software sin ningún tiempo de inactividad.

Puede visitar mi sitio en http://www.next-gen.cc .

Me hacen creer que la ventana de mantenimiento también permite el reemplazo de hardware de rutina para garantizar que los componentes no fallen.