La disponibilità del database è uno degli aspetti più importanti dell'architettura dell'applicazione. Anche se prevenire i tempi di inattività del data center è un dato di fatto, alla fine succederà a tutti. Anche i data center con le migliori prestazioni di tanto in tanto andranno completamente in crash. Ad esempio, le interruzioni di Amazon AWS del 26/08/13 e del 13/09/13. La domanda importante da porsi è se questo è accettabile per la tua applicazione? La maggior parte delle applicazioni può tollerare alcuni tempi di inattività di tanto in tanto, tuttavia, alcune applicazioni richiedono un tempo di attività vicino al 100% e l'architettura del database di queste applicazioni richiede un approccio di progettazione più ponderato. Le latenze tra i data center tendono ad essere abbastanza grandi, quindi è necessario riflettere attentamente nella progettazione della distribuzione dell'hosting MongoDB.
Obiettivi di disponibilità di MongoDB
- Il tuo database dovrebbe essere attivo e scrivibile, anche se un intero datacenter non funziona.
- Il failover del database dovrebbe essere automatico in caso di guasto del server/datacenter.
- Un singolo errore del server non dovrebbe causare il passaggio del server primario a un data center diverso.
Progettazione di data center
Per soddisfare i nostri obiettivi, abbiamo ideato tre progetti di data center che utilizzano un set di repliche 4+1:
- Centro dati 1: Primaria (Priorità 10), Secondaria 0 (Primaria 9)
- Centro dati 2: Secondaria 1 (Priorità 8), Secondaria 2 (Priorità 7)
- Centro dati 3: Arbitro
Posizioniamo due membri a pieno titolo in ciascuno dei primi due data center e un arbitro nel terzo data center. Abbiamo anche configurato la priorità per ciascun server in modo da poter controllare quale membro diventa primario in caso di guasto del server.
Ci sono un paio di aspetti negativi di questo geo- architettura distribuita:
- Se si dispone di un'applicazione pesante in scrittura, i secondari in un data center diverso rimarranno sempre indietro a causa della maggiore latenza. Se alcuni dati sono cruciali, potresti voler utilizzare un problema di scrittura MongoDB di "Maggioranza" per assicurarti che tutti i nodi effettuino il commit dei dati.
- Le build della community di MongoDB non hanno SSL abilitato. Potresti voler creare una build con SSL abilitato o utilizzare MongoDB DBaaS su ScaleGrid in modo che i dati che scorrono tra le regioni siano crittografati.
Disponibilità Amazon AWS/EC2
Se stai distribuendo MongoDB su AWS, ogni data center in questa immagine corrisponde a una regione Amazon e non a una zona di disponibilità. Amazon non fornisce garanzie di disponibilità in una singola zona di disponibilità, gli SLA sono per l'intera regione. Se esegui la distribuzione in più zone di disponibilità, il tuo SLA è del 99,95%, il che è comunque un ottimo SLA, tuttavia, se un'intera regione si interrompe, il database si interrompe. Inoltre, alcune regioni AWS hanno solo due zone di disponibilità, quindi è necessario prestare particolare attenzione a posizionare il terzo nodo in una regione diversa in modo che il tempo di inattività di una singola regione non interrompa l'intero database.
Disponibilità a basso costo in tutte le aree geografiche
Una versione più semplice della stessa architettura utilizza solo tre server e posiziona solo una replica in ciascun data center. Lo svantaggio di questo approccio è che un singolo errore del server causerà lo spostamento del server primario tra i data center. Tuttavia, questa architettura costa meno della prima architettura. A seconda del tuo scenario, potrebbe funzionare per te.
Ci sono molti modi per ottenere tempi di attività elevati con MongoDB, e questo è proprio il modo che funziona per le nostre esigenze. Se hai altre architetture interessanti, inviaci un'e-mail a [email protected]. Ci piacerebbe sentire i tuoi pensieri!
