Manutenzione del server MMORPG

Sembra che la maggior parte dei giochi mmorpg abbia una manutenzione regolare del server, alcuni ogni giorno, altri una volta alla settimana. Cosa devono fare realmente e perché è necessario?

Se inizi con un progetto del genere, cosa puoi fare per evitarlo?

Sospetto che stiano distribuendo l'ultima versione del loro codice, il che richiede che riavviino l'applicazione (e si spera che eseguano alcuni test prima di riattivare l'accesso). Da quel punto di vista, è più un problema StackOverflow e meno di ServerFault.

Penso che sia possibile creare un sistema di hot patching, ma sarebbe necessariamente incredibilmente complicato. Da quello che ho capito, una "applicazione" server MMO è composta da diversi componenti -

• Server di accesso : gestisce l'autenticazione e funge da "hub" tra i server di gioco. Una volta che un client è in gioco, non interagisce più con il server di accesso. In un tale sistema potresti applicare patch e riavviare il server di accesso senza interferire con il gameplay (anche se avrai un periodo di tempo in cui le persone non saranno in grado di accedere).

• Server di gioco : cluster di macchine raggruppate in unità logiche indipendenti ("mondi", ecc.). Si presume che ciascun cluster di gioco utilizzi una sorta di protocollo di comunicazione interna per corrispondere lo stato tra loro; probabilmente dovrai rattoppare tutti i cluster contemporaneamente. Un modo possibile per eseguire questa operazione è correggere un failover a caldo. Dovresti quindi essere in grado di entrambi

  1. Segnala al client di connettersi al failover caldo e disconnettersi dal vecchio cluster.
  2. Mantenere lo stato sincronizzato tra il failover e il server delle applicazioni obsoleto mentre tutti i client trasferiscono.

• Server di database : un tipo di archivio dati persistente, come un RDBMS. Spero che non apporti modifiche al datastore così spesso. Presumibilmente ogni server / cluster di gioco ha un archivio dati indipendente. Potresti essere in grado di utilizzare lo stesso trucco con un caldo failover (e dire ai server di gioco di disconnettersi, attendere la sincronizzazione dei database vecchi e di failover, quindi riconnettersi al failover) ma questo mi sembra abbastanza rischioso.

Tutti i casi di cui sopra aggiungono un'incredibile quantità di complessità a un sistema già complesso e introducono un sacco di luoghi in cui un errore del codice può causare la perdita o la corruzione dei dati.

Un'altra soluzione è quella di utilizzare un linguaggio progettato per il 100% di uptime e dotato di funzionalità integrate per l'esecuzione a caldo del codice in esecuzione. Erlang è una buona scelta ( esempio di hotpatching ) e Java ha funzionalità simili .

Nessun altro ha esperienza nel gestire qualcosa del genere? Huh.

Ci sono diverse ragioni che collegano sia il codice che i sistemi. Innanzitutto, ricorda che la maggior parte degli attuali "grandi" motori MMO sono stati programmati diversi anni fa e, nonostante gli aggiornamenti di grafica e tecnologia da allora, dipendono ancora dal modo in cui molti di questi sistemi sono stati scritti nel 2000 o giù di lì. Eve-Online, ad esempio, funziona ancora su un'enorme istanza di Microsoft SQL Server, motivo per cui cercano sempre di tirarne fuori di più aggiornando l'hardware.

Un esempio di miglioramento da quando WoW ed EVE sono iniziati è il lavoro svolto in database chiave / valore distribuiti come MapReduce di Google (e la sua implementazione open source, Hadoop), servizi di code di elaborazione delle risposte affermative estremamente veloci (Amazon SQS) e altri " cloud "tecnologie orientate.

Ho la maggior esperienza con EVE (sono più un tipo di laser che un ragazzo di stele), quindi alcuni di questi esempi sono più orientati all'EVE.

Per quanto riguarda i motivi del sistema:

• I nodi fisici falliscono su base coerente. Quando un nodo fallisce, in genere la sua attività viene migrata altrove usando un numero qualsiasi di mezzi. Tuttavia, il nodo deve essere rimesso in servizio il più rapidamente possibile. Nel caso di EVE, usano sia un linguaggio di elaborazione stackless che server virtuali; Non sono sicuro di come sia l'architettura di Blizzard.
• La coerenza del database deve essere verificata, i log devono essere svuotati e gli indici e le cache dei dati devono essere ricostruiti. Ciò è particolarmente importante in un sistema come EVE con una sola istanza di database "live".
• Le patch del sistema operativo devono essere applicate in un momento in cui possono riavviare i nodi senza dover eseguire troppe attività migrando altrove. La migrazione occupa molte risorse di rete che potrebbero altrimenti essere dedicate all'elaborazione online.
• Gli MMO basati su RDBMS hanno enormi problemi con il blocco dei dati e l'integrità referenziale. I tempi di inattività vengono utilizzati per ripulire i blocchi non aggiornati e le interruzioni di integrità dai registri delle attività.
• La maggior parte dei giochi implementa cache di dati situati geograficamente per informazioni statiche o semi-statiche (vedere i dati di riepilogo della cache di seguito) in aree ad uso intensivo, vale a dire la costa orientale e la costa occidentale degli Stati Uniti. Queste cache vengono aggiornate manualmente durante i tempi di inattività.

Per quanto riguarda i motivi del software:

• I giochi, durante il funzionamento, utilizzano molto OLTP, ovvero Elaborazione delle transazioni online, tipo di letture / scritture nei database. Tuttavia, a volte vuoi un rapporto di sintesi ... come quante di una particolare bestia hai ucciso negli ultimi 3 anni di macinazione. È gestito al meglio da un report OLAP, ovvero elaborazione analitica in linea, che contiene informazioni di riepilogo basate su molte righe in un set di dati gigante. In realtà, i giochi implementano sistemi che utilizzano OLAP per creare una cache per limitare il numero di query che devono essere lette - ovvero, costruiscono un totale a partire da una certa data, quindi quando pongono la domanda leggono solo le righe dal negozio OLTP che riassume il periodo di tempo dalla data determinata. Unisci i due e puoi effettivamente quantificare quanto è diventata inutile la tua vita.
• Il suddetto hot-patching, che vedo come un problema software, ma gli sviluppatori software vedono come un problema di sistema. ;)
• Rifornimenti di articoli: a Eva, le cinture degli asteroidi vengono rinfrescate ogni notte e anche alcuni complessi vengono riciclati. Questo può essere fatto in linea mentre in linea, ma alcuni degli algoritmi sono troppo complessi e devono essere eseguiti in modalità off-line perché mettono brevemente il database in ginocchio mentre riassumono l'attività economica del giorno precedente.

Gestire un'economia con circuiti sia chiusi che aperti è un problema per gli operatori MMO - se non mi credi, leggi alcuni dei documenti accademici che sono stati scritti sulle economie di gioco e alcuni degli studi di giochi più vecchi come Ultima Online che aveva economie relativamente primitive. L'analisi che deve avvenire per ricostituire i loop aperti e identificare truffe e altre attività economiche negative deve avvenire offline con un'istantanea dei dati, che a volte può essere presa solo mentre il database è completamente bloccato.

Se noterai, la manutenzione di Eva avviene quando è mezzogiorno in Inghilterra, dove si trova il centro dati principale.

Ho il sospetto che il tempo totale che Blizzard (sto deducendo dal fatto che è un martedì mattina che stai pubblicando la tua domanda) le quotazioni per la manutenzione sia per l'intero cluster; non tutti i server impiegano così tanto tempo per eseguire il lavoro.

Mentre potrebbe essere possibile ripristinare i singoli server più rapidamente, ciò implicherebbe grida illecite di favoritismo nei confronti dei giocatori i cui regni sono caduti prima nel programma. In quanto tali, tengono tutto giù fino a quando tutto il lavoro è finito; con centinaia di regni su cui lavorare, probabilmente svolgono gran parte del lavoro in parallelo, ma continuano a serializzare un controllo finale prima di riportare le cose online. Se stai eseguendo un aggiornamento hardware, questo è probabilmente serializzato su tutti i data center che hanno.

Per quanto riguarda il motivo per cui eseguono la manutenzione, in parte potrebbe essere solo un riavvio delle prestazioni. Sebbene sarebbe fantastico se tali riavvii non fossero necessari, il costo di farlo rispetto all'impatto di non farlo potrebbe essere quello di dirigere la loro scelta qui.

Quando si guarda al motivo per cui non possono raggruppare i processi ed eseguire la manutenzione progressiva, ciò che i pochi conoscono dell'infrastruttura di WoW suggerisce che più macchine forniscono servizi per ogni regno (cioè uno per il mondo, uno per istanze e raid, uno per campi di battaglia , ecc.) non utilizzano un'impostazione di processo attiva-attiva condivisa dallo stato. Non esiste condivisione dello stato in tempo reale, ma solo di dati persistenti tramite un database.

Alla fine, i meccanismi di fornitura di un servizio online con stato a una base di abbonati così ampia sfidano alcune delle migliori pratiche che potremmo sposare quando parliamo di un sito Web o di altri servizi tradizionali basati su Internet.

Alcuni dei tempi di inattività prolungati più recenti in EvE Online riguardano l'installazione di nuovo hardware come una SAN più veloce. Mentre è possibile spostare tecnicamente la maggior parte dei dati creando un nuovo filegroup sulla nuova unità e quindi svuotando quello principale, ciò avrebbe comportato un periodo prolungato di prestazioni ridotte a causa dell'I / O costante. Così hanno deciso di staccare il database da 1,1 TB e spostarlo in una volta sola.

La risposta a questa domanda si basa anche sull'applicazione specifica. Ad esempio, un server che gestisce uno specifico sistema a stella non può essere scambiato a caldo senza interrompere il gioco, quindi i tempi di inattività vengono utilizzati per riassegnare server più potenti a potenziali hotspot. Inoltre, vengono calcolati i calcoli della proprietà (sovranità) dei sistemi stellari. Questo dipende dalle decine di variabili diverse, che possono cambiare a seconda delle azioni del giocatore. Inutile dire che farlo dal vivo può causare blocchi eccessivi e / o altri problemi di concorrenza. Ma affrontare questi è meglio lasciare allo stackoverflow .

presumibilmente qualcosa che non è stato possibile affrontare tramite il clustering / il bilanciamento del carico, come le principali modifiche dello schema del DB.

In un argomento recente Quante volte devo riavviare i server Linux sono stati menzionati un altro punto positivo, verificando che tutto si avvii correttamente al riavvio o dopo qualsiasi (grande) modifica della configurazione.

Un semplice aggiornamento dell'hardware (o sostituzione dell'hardware) viene anche presentato come "manutenzione del server" dai giochi MMORPG. Così banale che spesso ci dimentichiamo di questo.

Ho implementato un'architettura MMO in Erlang che supporta gli aggiornamenti e la distribuzione di hot code. Ad esempio, un "GamePlay Server" può essere eseguito su un numero arbitrario di macchine, se uno ha bisogno di un aggiornamento hardware i suoi oggetti possono essere trasferiti (in tempo reale) su altre macchine. Ciò consente aggiornamenti dell'hardware del software senza tempi di inattività.

Puoi visitare il mio sito all'indirizzo http://www.next-gen.cc .

Sono indotto a credere che la finestra di manutenzione consenta anche la sostituzione ordinaria dell'hardware per garantire che i componenti non si guastino.