Maintenance du serveur MMORPG

Il semble que la plupart des jeux mmorpg nécessitent une maintenance régulière du serveur, certains tous les jours, certains une fois par semaine. Qu'est-ce qu'ils doivent réellement faire et pourquoi est-ce nécessaire?

Si vous commencez avec un tel projet, que pouvez-vous faire pour éviter cela?

Je soupçonne qu'ils déploient la dernière version de leur code, ce qui nécessite qu'ils redémarrent l'application (et, espérons-le, exécutent des tests avant de réactiver l'accès). De ce point de vue, il s'agit davantage d'un problème StackOverflow que d'un problème ServerFault.

Je pense qu'il est possible de créer un système de patch à chaud, mais ce serait nécessairement incroyablement compliqué. D'après ce que je comprends, une "application" de serveur MMO se compose de plusieurs composants différents -

• Serveur de connexion - Gère l'authentification et agit comme un «hub» entre les serveurs de jeu. Une fois qu'un client est en jeu, il n'interagit plus avec le serveur de connexion. Dans un tel système, vous pouvez appliquer des correctifs et redémarrer le serveur de connexion sans interférer avec le gameplay (même si vous aurez une période de temps où les gens ne pourront pas se connecter).

• Serveurs de jeu - Grappes de machines regroupées en unités logiques indépendantes ("mondes", etc.). Il est supposé que chaque cluster de gameplay utilise une sorte de protocole de communication interne pour correspondre entre eux; vous devrez probablement patcher chaque cluster à la fois. Une façon possible de le faire est de corriger un basculement à chaud. Il faudrait alors pouvoir à la fois

  1. Signalez au client de se connecter au basculement à chaud et de se déconnecter de l'ancien cluster.
  2. Gardez l'état synchronisé entre le basculement et le serveur d'applications obsolète pendant le transfert de tous les clients.

• Serveurs de base de données - Une sorte de banque de données persistante, comme un SGBDR. J'espère que vous n'apportez pas de modifications au magasin de données aussi souvent. Vraisemblablement, chaque serveur / cluster de gameplay possède une banque de données indépendante. Vous pourriez peut-être utiliser la même astuce avec un basculement à chaud (et dire aux serveurs de jeu de se déconnecter, d'attendre que les anciennes bases de données et le basculement se synchronisent, puis de se reconnecter au basculement), mais cela me semble assez risqué.

Tous les cas ci-dessus ajoutent une quantité incroyable de complexité à un système déjà complexe et introduisent un tas d'endroits où une défaillance de code peut entraîner la perte ou la corruption de données.

Une autre solution consiste à utiliser un langage conçu pour une disponibilité à 100% et doté de capacités intégrées pour la correction à chaud du code en cours d'exécution. Erlang est un bon choix ( exemple de hotpatching ), et Java a des fonctionnalités similaires .

Personne d'autre n'a l'expérience de faire quelque chose comme ça? Huh.

Il y a plusieurs raisons qui font le pont entre le code et les systèmes. Tout d'abord, rappelez-vous que la plupart des `` gros '' moteurs MMO actuels ont été programmés il y a plusieurs années, et malgré les mises à niveau graphiques et technologiques depuis, dépendent toujours de la façon dont beaucoup de ces systèmes ont été écrits en 2000 environ. Eve-Online, par exemple, fonctionne toujours sur une énorme instance de Microsoft SQL Server, c'est pourquoi ils essaient toujours d'en tirer davantage en mettant à niveau le matériel.

Un exemple d'amélioration depuis le démarrage de WoW et EVE est le travail effectué dans les bases de données de clés / valeurs distribuées comme MapReduce de Google (et son implémentation open-source, Hadoop), les services de file d'attente de traitement des réponses affirmatives extrêmement rapides (Amazon SQS), etc. " technologies orientées cloud.

J'ai le plus d'expérience avec EVE (je suis plus un gars de lasers qu'un gars de battleaxes), donc certains de ces exemples sont plus orientés EVE.

En ce qui concerne les raisons des systèmes:

• Les nœuds physiques échouent de manière cohérente. Lorsqu'un nœud tombe en panne, son activité est généralement migrée ailleurs à l'aide de n'importe quel nombre de moyens. Cependant, le nœud doit être remis en service le plus rapidement possible. Dans le cas d'EVE, ils utilisent à la fois un langage de traitement sans pile et des serveurs virtuels; Je ne sais pas à quoi ressemble l'architecture de Blizzard.
• La cohérence de la base de données doit être vérifiée, les journaux doivent être vidés et les index et les caches de données doivent être reconstruits. Ceci est particulièrement important dans un système comme EVE avec une seule instance de base de données "active".
• Les correctifs du système d'exploitation doivent être appliqués à un moment où ils peuvent redémarrer les nœuds sans avoir trop d'activité à migrer ailleurs. La migration prend beaucoup de ressources réseau qui pourraient autrement être consacrées au traitement en ligne.
• Les MMO basés sur RDBMS ont d'énormes problèmes avec le verrouillage des données et l'intégrité référentielle. Les temps d'arrêt sont utilisés pour nettoyer les verrous périmés et les ruptures d'intégrité des journaux d'activité.
• La plupart des jeux implémentent des caches de données géographiquement localisés pour des informations statiques ou semi-statiques (voir les données récapitulatives de mise en cache ci-dessous) dans les zones à forte utilisation, c'est-à-dire côte est vs côte ouest USA. Ces caches sont mis à jour manuellement pendant le temps d'arrêt.

En ce qui concerne les raisons logicielles:

• Les jeux, lorsqu'ils fonctionnent, utilisent beaucoup de type OLTP - c'est-à-dire le traitement des transactions en ligne - de type lecture / écriture dans les bases de données. Cependant, parfois, vous voulez un rapport de synthèse ... comme le nombre d'une bête particulière que vous avez tuée au cours des 3 dernières années de broyage. Cela est mieux géré par un rapport OLAP - c'est le traitement analytique en ligne - qui contient des informations récapitulatives basées sur un grand nombre de lignes dans un ensemble de données géant. En réalité, les jeux implémentent des systèmes qui utilisent OLAP pour créer un cache pour limiter le nombre de requêtes qui doivent être lues - c'est-à-dire qu'ils construisent un total à partir d'une certaine date, puis lorsque vous posez la question, ils lisent simplement les lignes à partir du magasin OLTP qui résument la période écoulée depuis la certaine date. Fusionnez les deux, et vous pouvez réellement quantifier à quel point votre vie est devenue sans valeur.
• Le patch à chaud susmentionné, que je considère comme un problème logiciel, mais que les développeurs de logiciels considèrent comme un problème système. ;)
• Réapprovisionnement des magasins d'articles - à Eve, les ceintures d'astéroïdes sont rafraîchies chaque nuit et certains complexes sont également recyclés. Cela peut être fait dans une certaine mesure en ligne, mais certains algorithmes sont trop complexes et doivent être effectués en mode hors ligne, car ils mettent brièvement la base de données à genoux pendant qu'ils résument l'activité économique de la veille.

Faire fonctionner une économie avec des boucles fermées et ouvertes est un problème pour les opérateurs de MMO - si vous ne me croyez pas, lisez certains des articles académiques qui ont été écrits sur les économies de jeu et certaines des études de jeux plus anciens comme Ultima Online qui avaient des économies relativement primitives. L'analyse qui doit se produire pour reconstituer les boucles ouvertes et identifier la tricherie et d'autres activités économiques négatives doit se produire hors ligne avec un instantané des données, qui ne peut parfois être pris que lorsque la base de données est entièrement verrouillée.

Si vous notez, la maintenance d'Eve se produit quand il est midi en Angleterre, où se trouve le centre de données principal.

Je soupçonne que le temps total que Blizzard (j'en déduis étant donné que c'est un mardi matin que vous postez votre question) soumet à la maintenance est pour l'ensemble du cluster; tous les serveurs ne prennent pas autant de temps pour effectuer des travaux.

Bien qu'il soit possible de faire remonter des serveurs individuels plus rapidement, ce serait des cris de favoritisme illicites envers les joueurs dont les royaumes sont tombés plus tôt dans le calendrier. En tant que tels, ils gardent tout en bas jusqu'à ce que tout le travail soit fait; Avec des centaines de domaines sur lesquels travailler, ils font probablement une grande partie du travail en parallèle, mais sérialisent toujours une vérification finale avant de remettre les choses en ligne. Si vous effectuez une mise à niveau matérielle, celle-ci est probablement sérialisée sur autant de centres de données qu'ils le font.

Quant à la raison pour laquelle ils effectuent la maintenance, certains pourraient simplement être un redémarrage des performances. Bien que ce serait formidable si de tels redémarrages n'étaient pas nécessaires, le coût de le faire par rapport à l'impact de ne pas le faire pourrait orienter leur choix ici.

Lorsque vous regardez pourquoi ils ne peuvent pas regrouper les processus et effectuer une maintenance continue, ce que peu de gens connaissent de l'infrastructure WoW suggère que plusieurs machines fournissent un service pour chaque domaine (c'est-à-dire une pour le monde, une pour les instances et les raids, une pour les champs de bataille) , etc.), ils n'utilisent pas de configuration de processus actif-actif partagé par état. Il n'y a pas de partage de l'état en direct, seulement des données persistantes via une base de données.

En fin de compte, la mécanique de la fourniture d'un service en ligne avec état à cette large base d'abonnés remet en question certaines des meilleures pratiques que nous pourrions adopter lorsque nous parlons d'un site Web ou d'un autre service Internet traditionnel.

Certains des temps d'arrêt prolongés les plus récents dans EvE Online concernaient l'installation de nouveau matériel comme un SAN plus rapide. Bien que l'on puisse techniquement déplacer la majeure partie des données en créant un nouveau groupe de fichiers sur le nouveau lecteur puis en vidant le principal, cela aurait entraîné une période prolongée de performances réduites en raison d'E / S constantes. Ils ont donc choisi de détacher la base de données de 1,1 To et de la déplacer en une seule fois.

La réponse à cette question repose également sur l'application spécifique. Par exemple, un serveur gérant un système stellaire spécifique ne peut pas être échangé sans perturber le jeu, donc le temps d'arrêt est utilisé pour réaffecter des serveurs plus puissants dans des hotspots potentiels. De plus, les calculs de propriété (souveraineté) des systèmes stellaires sont calculés. Cela dépend des dizaines de variables différentes, qui peuvent toutes changer en fonction des actions des joueurs. Inutile de dire que le faire en direct peut entraîner un verrouillage excessif et / ou d'autres problèmes de concurrence. Mais il vaut mieux laisser ces problèmes à stackoverflow .

probablement quelque chose que vous ne pouviez pas gérer via le clustering / équilibrage de charge, comme les modifications majeures du schéma de base de données.

Dans une rubrique récente À quelle fréquence dois-je redémarrer les serveurs linux, un autre bon point a été mentionné, vérifier que tout démarre correctement lors d'un redémarrage ou après un changement de configuration (majeur).

Une simple mise à niveau du matériel (ou remplacement du matériel) est également présentée comme «maintenance du serveur» par les jeux MMORPG. C'est si banal qu'on l'oublie souvent.

J'ai implémenté une architecture MMO à Erlang qui prend en charge les mises à niveau et la distribution de code à chaud. Par exemple, un "GamePlay Server" peut fonctionner sur un nombre arbitraire de machines, si l'on a besoin d'une mise à niveau matérielle, ses objets peuvent être transférés (en temps réel) vers les autres machines. Cela permet des mises à niveau du matériel logiciel sans aucun temps d'arrêt.

Vous pouvez consulter mon site à http://www.next-gen.cc .

Je suis amené à croire que la fenêtre de maintenance permet également de remplacer régulièrement le matériel pour garantir que les composants ne tombent pas en panne.