Guida Semplice infrastruttura con DR

iltizio

Utente Emerald
1 Novembre 2009
927
60
533
598
Ultima modifica da un moderatore:
cloud-gaf77dcf6d_1920.jpg


Una semplice ed economica infrastruttura basata sulle moderne soluzioni cloud dei più comuni ed economici cloud provider.





1    Introduzione



Da sempre abbiamo visto progetti di Metin2 andare, talvolta letteralmente, in fumo per mancanza di un infrastruttura decente. Si potrebbe incolpare la sfiga, ma la realtà è che si poteva prevenire senza dover spendere cifre molto più alte del normale, per cui la colpa rimane ai gestori dei server privati di Metin2, che per ignoranza più che per questioni economiche non hanno messo in sicurezza il loro lavoro.

In questa guida vi propongo una semplice ed economica infrastruttura che cerca di prevedere la maggior parte dei problemi infrastrutturali, con una predisposizione nel permettere di ripartire in pochi minuti anche quando il danno è elevato.

1.1    Il mondo Cloud



Ad eccezione degli ormai obsoleti server Hamachi e No-IP e pochi eventuali rarissime alternative, da sempre i progetti metin2 "seri" si appoggiano ad un'infrastruttura cloud.
Per definizione, un'infrastruttura cloud non è altro che un'infrastruttura remota accessibile in rete, spesso gestita per grossa parte da un cloud provider.
L'idea del cloud nasce per semplificare la gestione dell'infrastruttura da parte degli utenti, aziende o privati, concentrandosi prevalentemente sulle applicazioni, nel nostro caso il server di Metin2.
Storicamente quindi le aziende che avevano un esigenza informatica piccola o grande necessitavano di uno o più datacenter con il relativo hardware e personale. I costi per una soluzione del genere potevano essere alti.
Con il cloud chiunque può acquistare o affittare il singolo componente che gli interessa, come una macchina virtuale FreeBSD, senza preoccuparsi di tutto quello che sta dietro, pagando una cifra prestabilita o comunque facilmente calcolabile, spesso mensile.

Essendoci un grande guadagno economico, questa metodologia ha riscosso un enorme successo e sempre più realtà stanno costruendo la propria infrastruttura su cloud o migrandola dai loro datacenter. Questo quindi genera una grande e variegata domanda, con conseguente investimento sull'offerta.
Ora esistono tantissime aziende che offrono questi tipi di servizi, chiamati cloud provider. La concorrenza ha spinto sempre di più ad investire nella ricerca e nelle diversificazione delle offerte, con lo scopo primario di ridurre i costi per gli utenti finali.

Da qui nascono varie forme di prodotti cloud, che permettono all'utente di acquistare persino la sola componente software che gli interessa, senza doversi preoccupare dei server che lo eseguono.

Inoltre anche i piani di fatturazione si sono evoluti, permettendo all'utente di pagare il reale utilizzo delle risorse cloud fino ad emettere fatture sui reali minuti di utilizzo delle componenti.



2    L'infrastruttura moderna cloud based



Voglio quindi proporvi un esempio di infrastruttura basata sui moderni servizi cloud proposti dai cloud provider più utilizzati in ambito Metin2.


2.1    Premessa


Questa che vi propongo è solo un esempio tra le tante combinazioni che il mondo cloud ci offre. Ritengo che questa soluzione sia sufficientemente semplice da realizzare ed economica per quasi tutti i progetti di Metin2 e allo stesso tempo un gran guadagno in termini di sicurezza comparato alla classica soluzione del server dedicato.

Inoltre, data la grande evoluzione che il mondo cloud continua a sostenere, la soluzione proposta potrebbe essere obsoleta quando leggerete questa guida.

Si presuppone che i vostri file siano aggiornati per l'utilizzo delle nuove versioni di sistema operativo, librerie, MySQL ecc.

Non verranno trattati i sistemi di monitoraggio, web host e server per autopatcher.

E' comunque consigliabile affidarsi ad un esperto per creare l'infrastruttura su misura per voi con il meglio che il progresso offre in quel momento.


2.2    Cloud Provider


Questo esempio si basa su OVH per quanto riguarda la parte di frontend dove verrà eseguito il server di Metin2, mentre la componente database si appoggerà su Scaleway.

La scelta di OVH è per l'ottimo rapporto qualità prezzo e sopratutto per un buon sistema Anti-DDoS incluso in tutta la gamma OVH senza maggiorazione di prezzo. Per questo motivo OVH viene spesso scelto per molti progetti Metin2 sia italiani che internazionali.

Per quanto riguarda Scaleway, la scelta è per una grande proposta a costo abbordabile di servizi managed MySQL. Anche OVH ha una gamma di managed database MySQL, ma partono da proposte piuttosto grosse in termini di risorse dedicate e quindi costose, almeno per la maggior parte dei progetti Metin2. Con Scaleway quindi possiamo utilizzare dei piani di istanze managed MySQL anche molto piccole, da usare sia per test che per produzione di varie entità.
Nulla vi vieta di utilizzare solo OVH, ma a livello tecnico con ci sono grossi problemi.


2.3    Definizione


metin2dr-Prod.drawio (1).png

Abbiamo quindi:
  • 2 cloud provider: OVH e Scaleway
  • 4 region o datacenter, 2 per ogni cloud provier:
    • OVH Region 1: per la macchina attiva di Metin2
    • OVH Region 2: Per la macchina in standby di Metin2 da usare in caso di Disaster Recovery
    • Scaleway Region 1: Per il cluster MySQL managed
    • Scaleway Region 2: Per i backup di MySQL
  • 2 Virtual Machine OVH di tipo public cloud compute instance (modello a scelta):
    • 1 in Region 1 per il server di metin2 (Game Prod) normalmente attiva, dove i player si connetteranno
    • 1 in Region 2 per il server di metin2 (Game DR) normalmente spenta, preinstallata e tenuta aggiornata, pronta per essere avviata in caso di problemi con l'istanza attiva
  • 1 Floating IP per l'utilizzo di un IP comune tra le due VM, che verrà spostato da un'istanza all'altra in caso di necessità, senza dover cambiare l'ip nel client. Maggiori informazioni: Documentazione OVH
  • 1 Managed MySQL HA in Region 1 formato da almeno 2 nodi:
    • Master: per le operazioni di lettura e scrittura
    • Slave: Istanza clone che in caso di switch, quando il Master viene spento, diventa il nuovo Master.
  • 1 sistema di backup MySQL automatico in Region 2
  • Opzionale: 1 repository GIT dove tracciare le modifiche ai vostri file (sorgenti, file server, client, quest) da utilizzare per installare/aggiornare il game sulle istanze di prod e DR. Potete usare GitHub o Gitlab che sono gratuiti e completi.

2.4    Disaster Recovery game server


Nel caso in cui la nostra istanza primaria (Game prod) ha problemi o dobbiamo fare manutenzione, ci basterà accendere l'istanza in standby (Game DR) e sincronizzare i nostri file da GIT. Una volta pronto ci basterà eseguire lo switch del floating IP sull'istanza di DR e i player potranno collegarsi nuovamente.

L'istanza MySQL, se non impattata, rimarrà la stessa e non dovremmo aver bisogno di ripristinare i backup o fare delle reconfigurazioni.

metin2dr-DR.drawio.png

Una volta ripristinato il servizio possiamo sistemare con calma l'istanza primaria, cercando le cause del problema e/o distruggendo e ricreando l'istanza.

Per i player il disservizio sarà simile a quello di un crash con riavvio entro pochi minuti:
  • Se il game ha subito un crash, i player potrebbero notare delle perdite di dati degli ultimi istanti, a seconda delle configurazioni e modifiche che avete apportato al game.
  • I player non saranno in grado di collegarsi fino a quando il riavvio sul nodo di standby non sarà completato, quindi qualche minuto o più a seconda della preparazione e disponibilità dello staff e correttezza nell'implementazione e manutenzione dell'infrastruttura.

2.5    Disaster Recovery MySQL


In caso in cui doveste aver problemi con entrambe le istanze MySQL, la procedura di DR sarà quella di creare un nuovo cluster mysql importando i backup automatici. In sostanza è una nuova installazione, caricando i backup che volete. Probabilmente dovrete modificare l'IP di connessione a MySQL del vostro sito e dei file server.

Può sembrare un metodo un po' drastico, ma è un modo molto comune in ambito cloud: se qualcosa non va, distruggi e ricrea da 0.

Ovviamente i disservizi per i player saranno un po' più gravi, come:
  • Game e sito indisponibili fino alla fine del processo di DR
  • Perdita di dati di gioco dal momento del crash a quello dell'ultimo backup valido



3    Costi



Come da premessa, i costi possono variare nel tempo, in quanto è un settore in forte crescita. Inoltre le differenti proposte dei cloud provider vi permette di optare per istanze di diverse dimensioni e costi, per far fronte alle diverse esigenze che possono variare da progetto a progetto.

Inoltre, come anticipato, è possibile avere una fatturazione per le ore di effettivo utilizzo delle risorse, per cui la "bolletta" mensile potrebbe differire di mese in mese.

Di seguito una possibile stima di un mese di utilizzo dove non sono state eseguite procedure di DR. Inoltre prendo in esame un ipotetico progetto di metin2 italiano medio:

ElementoPrezzo mensile stimato in euro (iva inclusa)Note
b2-726,841x istanza Game Prod. Sempre accesa, fatturazione mensile
b2-70,611x istanza Game DR. Sempre spenta, fatturazione oraria. Il costo di quando è spenta è solo dello spazio disco utilizzato
Floating IP01x floating IP. Al momento è gratuito in quanto in fase Beta.
DB-DEV-S HA25,051 cluster a 2 nodi MySQL con spazio 10 GB, espandibile in un secondo momento.
Totale52,50



4    Bonus: Varianti



Come anticipato, questo è solo uno dei tanti modi. Esistono tanti cloud provider con diverse caratteristiche e diverse modalità per ognuno.

E' possibile utilizzare solamente OVH come unico cloud provider anche per i database. Come spiegato precedentemente, la gamma offerta di OVH per i Managed Databases attualmente ha solo configurazioni con un elevato uso di risorse, comparato ad un server metin2 classico.
Per una configurazione HA, si parte da €278,16/mese

Anche se sconsigliato, è comunque possibile utilizzare una soluzione ancora più semplice ed economica utilizzando la classica istanza mysql nella stessa macchina del game. Qui però dovrete gestire voi l'istanza, configurando la ridondanza e i backup, nonché tutto il resto della sicurezza. Se notate i sopra citati costi non andrete a risparmiare più di tanto.

Potete aumentare un po' la complessità e l'affidabilità con un cluster anche per il game server. Nella sopra descritta soluzione solo MySQL è in cluster, mentre il game ha solo un istanza attiva e l'altra preconfigurata ma spenta. E' quindi possibile creare un cluster tra le due (o più) macchine del game per tenerle attive e pronte ad eseguire lo switch in automatico, senza che lo staff debba collegarsi ed eseguire la procedura di DR manualmente. Questo vi garantisce un'autonomia maggiore, permettendo di ripartire in automatico in pochi minuti senza attività umana.

Uno step ulteriore basato sull'ultima versione descritta è quella di creare più istanze attive in cluster e suddividendo i processi del game su più macchine. Esempio CH1 su un server, CH2 su un altro, CH99 su un altro ancora ecc. Il cluster gestirà quindi il restart del processo fallito su una macchina funzionante in automatico.
Questo vi permette di avere una specie di scalabilità orizzontale, suddividendo il carico su più macchine uguali.

E' comunque possibile utilizzare istanze di gamme o addirittura provider differenti per il game. Potreste ad esempio acquistare un VPS contaboo economico per l'istanza principale del game, tenendo quella di DR spenta su OVH. Ovviamente in questo caso non potrete più usare il floating IP di OVH, che può essere configurato solo su alcune istanze OVH. Potete anche usare istanze OVH di differenti dimensioni, anche se avrebbe poco senso. In genere la regola è di configurare la seconda istanza il più possibile simile a quella principale, così da evitare differenze che possano causare problemi in caso di switch.

Al momento il floating IP di OVH è gratuito in quanto in fase beta. Prima o poi uscirà dalla beta e andrà pagato. Dovrebbero essere un paio di euro al mese. Se non volete o non potete utilizzare il floating IP potete sempre utilizzare gli IP base delle VM. Consiglio in questo caso di usare un nome a dominio, che molto probabilmente comunque acquisterete per il sito, per assegnare l'IP dell'istanza attiva, così da evitare di modificare l'ip di connessione nel client in caso di switch.