Escrito por Juanga Covas (SoNNy) y Toni Pomar (Sobakus) en 2009

Este es el aspecto real que tenían todos los sistemas que conformaban La Prisión en el año 2009. Los textos se escribieron entonces y esperamos que sirva como idea general de la interacción entre los distintos servidores, destacando los distintos proveedores que participan (o sea, proveedores a los que hay que pagar cada mes para tener el servicio en funcionamiento).

Por supuesto, teóricamente podría servirse TODO el sistema desde un solo PC / Servidor montado sobre un ADSL residencial. Eso no se puede hacer si pretendes cobrar a tus clientes por un buen servicio. Nosotros hemos distribuido el sistema para tratar de minimizar los daños en caso de que falle alguna de las “piezas del puzzle”. Si lo concentras todo en un PC: servidor web, servidor de juego, servidor de correo, … no esperes regalos ni flores cuando ese PC deje de funcionar por el motivo que sea. Los jugadores no podrán ver la web, ni jugar, ni podrás responderle al correo electrónico.

Las nubecitas con una letra pintada se detallan a continuación:

El poder acceder o no a la página web es importante, ya que permite la creación de cuentas de juego, permite realizar los pagos de nuevas suscripciones al servicio y se gestiona la caducidad de dichas suscripciones. Además ofrece servicios a los clientes como la descarga del juego, “enciclopedias” de contenidos, manual de juego y noticias.

Si fallara el acceso al servidor de la web y la base de datos de cuentas, los servidores del juego están diseñados para funcionar de manera autónoma, con lo que el acceso al juego estaría garantizado para quien ya tuviera creada una cuenta en el sistema. Esto es posible gracias a que el servidor de login gestiona su propia lista de cuentas, que se mantiene al día a través del servidor web (por ejemplo cuando alguien crea una cuenta nueva, o renueva una suscripción). La premisa era: si cobras por jugar, deja que la gente juegue aunque se estropee una parte del sistema.

El servidor de correo está separado geográficamente del servidor web y de los servidores de juego. Incluso si se produjera una avería en la web y también en los servidores de juego al mismo tiempo, podríamos seguir atendiendo a los clientes por correo electrónico.

Además, a nivel DNS existen 2 servidores MX. El principal, y uno de respaldo. Nuestro proveedor DNS es quien proporciona este servicio. En caso de que sea nuestro servidor de correo principal el que sufre una avería durante varias horas, o incluso días completos, el correo podría seguir llegando al servidor alternativo, a modo de “cola”. De esa manera, una vez solucionada la avería, se vacía la cola enviándose al servidor de correo principal cuando este vuelve a funcionar.

Utilizamos un “sistema de gestión de correo para atención al cliente”, en inglés conocido como “ticket system”. Un robot en el servidor web se encarga de “recoger” el correo desde el servidor de correo y lo introduce en una base de datos bajo nuestro control. El sistema se come el 90% del SPAM y el resto lo almacena en una base de datos para tener centralizado todo el correo, asignando a cada asunto o incidencia un número de ticket.

A esta base de datos de correo, se accede mediante una página web multi-usuario que permite ver las incidencias abiertas, responder, seguir el hilo de los problemas y mantener un historial de las consultas realizadas por los clientes en ocasiones anteriores.

Así, este sistema de tickets permite que varias personas pueden acceder al mismo tiempo “a un mismo buzón de correo”, mediante un sistema de usuarios. Esto nos permite trabajar de forma coordinada y ahorrarle tiempo a los clientes. Varias personas se pueden repartir el trabajo para responder a todo el mundo. Por supuesto todos los que usan el sistema saben qué asuntos están pendientes, resueltos, o si hay alguna otra persona trabajando en ello. Por ejemplo yo solicito más datos a un cliente. Este responde cuando ya no estoy conectado, de forma que otro compañero más tarde puede ver todo el hilo del mensaje y terminar de solucionar el problema.

El servidor web está separado geográficamente del servidor de correo y de los servidores de juego. De esta forma “si falla todo menos la web”, podríamos colgar una noticia en la página para informar a los clientes.

En este caso albergamos el servicio web y la base de datos en el mismo servidor, aunque en discos físicos independientes (para aumentar el rendimiento). Por otra parte usamos XCACHE para PHP y otros truquillos habituales de optimización de Apache para poder servir las páginas lo más rápido posible.

Si el nº de visitas se convirtiera en un problema de sobrecarga para el servidor, y según fuera el origen de dicha sobrecarga (pueden ser diversos problemas y cada web es un mundo), como primer paso podríamos separar la web de la base de datos -tener en el mismo proveedor, 2 servidores-, y como segundo paso hacer “reparto de carga”, con lo que tendríamos un mínimo de 3 servidores mediante LVM.

Si de todo el sistema es sólo el servidor web el que sufre una avería:

• En unos minutos, a través de DNS y automáticamente, se redirecciona a una página informativa “mantenimiento” que informa de la avería. Esto se hace mediante una técnica de “failover” a nivel de DNS, que monitoriza que el dominio responde peticiones web y redirecciona en caso de fallo a otra página en otro lugar que sí funcione.

• Para poder hacer Atención al Cliente es necesario albergar el “sistema de tickets” en otro lugar de forma manual, si bien lo normal es que las averías del servidor web se resuelvan en poco tiempo. Los clientes pueden enviar correo sin problemas al staff.

• Los clientes pueden jugar al juego, pero los servidores de juego no pueden enviar información estadística al servidor web.

• Los clientes no pueden comprar suscripciones, ni se pueden realizar nuevas cuentas.

Los servidores de juego y el servidor web se comunican entre sí para intercambiar algunos datos. Los más importantes son las cuentas de usuario, pero no los únicos.

Esta dependencia no puede ser permanente. Debe permitirse que uno de los dos sistemas pueda fallar durante largos periodos de tiempo (las averías pueden ocurrir y ocurren, y no siempre se solucionan en pocas horas y muchos menos en minutos). Es decir, si se crea una nueva cuenta de usuario en el sistema porque la web funciona, no se debe notificar en tiempo real a los servidores de juego confiando en que siempre esté en marcha y funcionando correctamente. Al mismo tiempo, los servidores de juego deben ser lo bastante listos como para dejar que los usuarios puedan jugar en caso de que se produzca una avería en la web.

Nosotros resolvimos esto de forma muy simple. Es el servidor de login quien “le pide cosas” a la web: ¿me pasas una lista actualizada de los usuarios que pueden entrar a jugar? Si el servidor web no contesta… bueno, no pasa nada. Seguirá funcionando con la lista de usuarios que tenga en ese momento.

Inconveniente: esta lista debe actualizarse de forma frecuente y por tanto no es “en tiempo real”. Yo creo una cuenta nueva y debo esperar unos pocos minutos para poder entrar a jugar al juego (es decir, esperar a que los servidores de juego reciban una lista actualizada que incluya mi nueva cuenta).

Ventajas: El usuario puede jugar incluso si el servidor web deja de funcionar y está completamente averiado el sistema de cuentas (léase: base de datos). Esto es bastante importante sobre todo si pretendes cobrar una suscripción a tus usuarios para poder jugar.

Este servidor es el núcleo central de todo el sistema de juego. Las tareas que tiene asignadas el sistema de Login son:

• Este servidor es el punto de entrada para las actualizaciones automáticas, suministrándole a los clientes que se conectan una lista detallada de los ficheros necesarios para poder entrar en el sistema de juego. De esta forma el cliente de actualizaciones comprueba si el sistema del usuario contiene la versión correcta de dichos ficheros y, de no ser así, solicita acceso a traves del servidor de login a la red distribuida de servidores de descarga. Por tanto el servidor de login es el responsable de distribuir la carga de trabajo de forma equitativa entre dichos servidores de descarga.

• Obviamente, también es el punto de entrada del cliente de juego, o sea, el que comprueba que el login / password tecleados por el usuario se corresponden a una cuenta existente en el sistema y que dicha cuenta está autorizada a acceder al juego (que tiene una suscripción vigente). Una vez comprobado esto, se le da acceso al cliente a los personajes que le corresponden desde la base de datos de cuentas y a la lista de servidores de juego disponibles en ese momento.

• Este servidor también se mantiene en comunicación permanente con los servidores de juego (las distintas cárceles) para monitorizar su estado, dar paso a los jugadores hacia el servidor correspondiente al personaje que quieren jugar, y para establecer rutas de comunicación entre los propios servidores de juego para cuestiones de mensajeria instantánea y diferida entre jugadores (por ejemplo el sistema de correo interno de mensajes y objetos del juego).

• Por último, aquí es donde se encuentran las bases de datos principales del juego, la base de datos de cuentas / personajes y la base de datos de correos (mensajeria diferida). Los servidores de juego le comunican continuamente al servidor de login cualquier cambio en los personajes de juego actualmente activos y en los correos entre personajes para que éste mantenga y actualice el estado de las bases de datos.

En resumen, este es el auténtico corazon de todo el sistema de juego, y todo lo que pasa dentro y alrededor de éste es inevitablemente gestionado, monitorizado y almacenado por el sevidor de login, sin excepciones.

Estos son los servidores donde se conectan los clientes de juego tras ser validados y autorizados por el servidor de login. Cada uno de estos servidores representa un mundo de juego independiente (una “cárcel” o “prisión”).

Las misiones principales de estos servidores son:

• Gestión de la interaccion entre los personajes de los jugadores y el entorno de juego, ya sean elementos estáticos del juego (zonas del mapa y sus accesos, elementos manipulables del entorno, etc), como elementos dinámicos del juego (personajes no jugadores, o PNJ, controlados por el sistema).

• La serialización de todas las acciones que se realizan en el juego, para evitar así que se puedan hacer al mismo tiempo acciones que pudieran entrar en conflicto.

• Gestión y control del comportamiento de los personajes no jugadores del juego (PNJs o “Bots”), tanto para moverse por el mundo de juego, como para interactuar o incluso combatir entre ellos y contra los propios jugadores. Se encarga además de la desaparición y reaparición de dichos PNJs cuando son derrotados en combate y cuando se producen las circunstancias adecuadas para su reinserción en el mundo de juego.

• Permite y controla la interacción entre los jugadores, tanto a nivel de peleas como de comunicación entre ellos mediante textos, acciones visuales de sus avatares, intercambio de objetos del juego, colaboración entre jugadores para completar cualquier tipo de misiones o tareas, etc…

• Y por último una misión fundamental: la comunicación constante con el servidor de login para informar de cualquier acción realizada por el jugador que suponga algún cambio en el personaje o en sus objetos, correos, equipamiento, etc. para que dicha información sea almacenada en su cuenta.

La descarga de la instalación del juego y las actualizaciones posteriores (parches, añadidos) se reparte entre varios servidores para servir los archivos de la mejor manera posible en casos de muchas descargas simultáneas. Por supuesto esto también nos permite tolerar averías esporádicas de alguno de los sitios de descarga, de forma transparente: si un servidor no funciona, la descarga se intenta desde el resto de servidores “en pie”.

Para poder dormir tranquilos por las noches, existe siempre una réplica remota, en otro proveedor y de otra ciudad, de la base de datos (cuentas de usuario, correos de atención al cliente, estado de suscripciones, facturas, …) y de los archivos web (que incluyen fotos que suben los usuarios y otros archivos dinámicos).

Esta réplica se realiza rápida y automáticamente mediante sincronización de datos cada 30 minutos utilizando rsync.

En caso de desastre total (por ejemplo, muerte de algún disco duro, lo cual nos ha pasado alguna vez), como mucho habremos perdido 30 minutos de actividad (por ejemplo, “cambios en la base de datos de cuentas”) y podremos volver a ponernos en marcha después de una recuperación manual en 24 horas o menos. Un banco no podría permitirse eso, pero no somos un banco y tampoco cobramos tarifas abusivas. Arreglar un desaguisado de 30 minutos es un mal menor.