Si consiglia di distribuire MongoDB su EC2 per la produzione?

Question

Mi piacerebbe distribuire mongoDB su EC2 per la mia produzione. Tuttavia, non sono riuscito a trovare abbastanza informazioni online per aiutare a rispondere alle mie domande di architettura.

1. In generale, quale dovrebbe essere il cluster iniziale con N shards?
2. Quale dovrebbe essere il piano di implementazione per aggiungere ulteriori shard?
3. Quale dovrebbe essere la strategia di failover (cosa succede quando uno o più nodi falliscono)?
4. Quale dovrebbe essere la strategia di ripristino di emergenza? Sto pensando di creare dei nodi nell'est degli Stati Uniti e altri nodi nell'ovest degli Stati Uniti come dice this powerpoint file.

Le risposte sono molto apprezzate.

Answer 1

1. Iniziare con lo sharding abilitato ma limitare la quantità di frammenti a ciò che è effettivamente necessario in . Iniziando con lo sharding abilitato significa avere i daemon mongos in posizione, selezionare le proprie chiavi shard per le relative raccolte e rendere le proprie query mirate al posto di globale quando possibile. Da quel momento in poi aggiungere i frammenti all'aumentare del carico. L'unica eccezione è quando ci si aspetta un grande afflusso di traffico al lancio , nel qual caso si desidera aggiungere altri frammenti e pre-split e pre-spostare i blocchi sui frammenti appropriati poiché il bilanciamento dei blocchi è un processo lento.
2. Nessun piano è necessario. Frammenti possono essere aggiunti e rimossi al volo. Si noti che la rimozione di frammenti comportava il ritiro di essi. A partire da questo punto, il tempo di attesa (significativo) prima che tutti i blocchi vengano spostati in altri frammenti in modo che l'istanza possa essere rimossa.
3. I set di repliche lo consentono.Se i requisiti di durabilità non sono super-critici, puoi ottenere un certo risparmio sui costi ospitando più arbitri in una singola istanza invece di eseguire repset di membri completi 3 membri. Si noti inoltre che i repset miglioreranno le prestazioni di lettura per le query compatibili coerenti con il flag "slaveOk" . Inoltre, è possibile considerare l'ottenimento di livelli simili di durata con un sovraccarico minore utilizzando il failover a livello di disco (ad esempio RAID10). Ovviamente questo non cattura i fallimenti di tutte le istanze.
4. Le divisioni dei datacenter geografici sono sempre una buona idea, ma si noti che le prestazioni di replica risentiranno in modo significativo. Le strategie per questo non sono diverse da qualsiasi altro database.

Altre note: livello di rete

• EC2 è limitata a 100k pacchetti al secondo. Per le query di piccole dimensioni e ad alto throughput questo diventerà un collo di bottiglia rapidamente.
• RAID i volumi EBS. L'esecuzione su un singolo volume EBS causerà prestazioni ESTREMAMENTE irrazionali. Questo diventa più stabile in quanto più volumi fanno parte della configurazione RAID. Deve avere!
• Utilizzare istanze di memoria elevate. Abbiamo notato miglioramenti significativi delle prestazioni in quanto c'è solo così tanto che puoi fare a destra con lo bilanciamento degli indici e conservare solo i dati rilevanti in memoria. Mantieni un occhio sui tuoi errori/sec in mongostat. Questi sono i pagefaults e quindi la quantità di volte che mongo deve colpire il disco per scambiare una pagina.

Answer 2

Winston, di Kristina Chodorow "Scaling MongoDB" è ciò che si vuole:

http://oreilly.com/catalog/0636920018308

Da quanto ho capito,

1) che si desidera set di repliche di 3 o più (un numero dispari) istanze per ogni frammento, più forse alcune istanze ritardate in ogni frammento per agire come backup

2) Semplicemente aggiungerli al cluster - Mongo muoverà lentamente i frammenti sui nuovi nodi finché il cluster non sarà riequilibrato

3) I set di replica generalmente gestiscono il failover in modo corretto; tuttavia, potresti voler aggiungere istanze di arbitraggio di Mongo ai server che eseguono il tuo frontend dell'applicazione - questi arbitri voteranno affinché le istanze rimanenti diventino primarie, nel caso in cui molti nodi siano andati giù, e aiuteranno a garantire che qualsiasi istanza di Mongo accessibile a i tuoi server frontend saranno in grado di assumere i ruoli primari

4) Aggiungere istanze ritardate a ogni serie di repliche è una buona idea, specialmente se (come dici tu) sono distribuite geograficamente, o se sono su diversi provider di hosting (ad esempio, se i tuoi server principali sono su Amazon, potresti mettere i backup su Rackspace). Se la maggior parte di un set di repliche scende, i nodi rimanenti non eleggeranno automaticamente un nuovo primario, ma puoi farlo manualmente in un disastro del genere.

Answer 3

myNoSQL, il mio blog NoSQL preferito, ha recentemente pubblicato un articolo chiamato Running MongoDB in the Cloud che elenca diversi articoli sulla distribuzione di MongoDB nel cloud Amazon.

• MongoDB su Amazon EC2 con EBS volumi
• MongoDB su EC2
• MongoDB nel Amazon cloud
• Impostazione MongoDB Replica Imposta su Amazon EC2
• MongoDB e Amazon: Perché EBS?
• Amazon EBS vs SSD: prezzo, performance, QoS
• Multi-tenancy e Cloud Storage prestazioni

Answer 4

1) Vorrei iniziare con un paio di frammenti a meno che non si sa assolutamente bisogno di più.
2) La parte più difficile dell'aggiunta di più frammenti è il tempo necessario per riequilibrare. A seconda dei dati e del carico, potrebbero essere necessari giorni per riequilibrare l'intero frammento. Pertanto, si desidera pianificare l'aggiunta di shard durante i periodi di basso carico
3) Ciascun frammento deve essere almeno un set di replica 2 + 1 con le repliche distribuite tra le zone di disponibilità.
4) Se si è interessati al ripristino di emergenza, è necessario distribuire le repliche tra le regioni anziché tra le zone di disponibilità. Maggiori informazioni qui - EC2 best practices. Ricordarsi inoltre di configurare correttamente la priorità dei set di repliche nel caso in cui si distribuiscano le repliche su aree geografiche.