Hardware per un ambiente MongoDB sharded + ridondante

Question

Sto provando a pianificare un nuovo ambiente di database da zero e mi chiedo quanti server sono necessari e quante prestazioni dovrebbero fornire.

Dal momento che voglio che sia veloce, sto considerando l'utilizzo di memoria SSD e carichi di RAM. Tuttavia, la memoria flash è costosa e costituisce la parte più grande del costo di un server. Pertanto, l'intero sistema dovrebbe essere impostato per il ridimensionamento orizzontale dall'inizio, quindi posso aggiungere più nodi quando ho bisogno di più spazio di archiviazione/prestazioni.

Per iniziare, sto pensando di utilizzare 2 frammenti, ciascuno costituito da un master e uno slave di replica per la ridondanza. La documentazione di MongoDB suggerisce l'utilizzo di 1 master e 2 slave, ma temo che non sia nel budget disponibile, poiché ciascuno di questi server sarà dotato di circa 200 GB di RAM e SSD 6x400 GB come Raid 10.

Quando si usano i frammenti, si suggerisce anche di utilizzare 3 server di configurazione per la sicurezza/alta disponibilità. Come sopra, sto pensando a 1 padrone e 1 schiavo come inizio.

• Quale tipo di hardware suggeriresti di installare i server di configurazione ? Dovrebbero essere alquanto performanti come i nodi shard nei termini di cpu/memory/harddisk? O posso metterli su virtualizzazione o su hardware più economico?
• La configurazione che ho descritto ha senso? Come circa il rapporto tra RAM e hard disk sui nodi shard? Al momento sarebbe probabilmente più semplice ed economico mettere solo il doppio del numero di dischi in 1 frammento (1 master, 1 slave) e saltare il sharding fino a quando non ne ho davvero bisogno. Tuttavia (come detto sopra) - il sistema dovrebbe essere pronto per la condivisione dall'inizio, perché i bisogni di storage possono cambiare durante la notte. O è possibile impostare tutto, ma per ora è in esecuzione su 1 frammento?
• Dal momento che sto solo pensando di utilizzare 2 anziché 3 server per la massima disponibilità/fail safe probabilmente ho bisogno anche di arbitri. Hanno anche l'hardware dedicato ? Oppure posso usare un arbitro in un mashine virtuale che serve server di configurazione e nodi shard? O si sta utilizzando 3 server separati per la ridondanza assolutamente necessario?

Answer 1

Rock on. Sembra un setup fantastico. Viste le tue scelte di configurazione, non potevo immaginare un budget che limitasse troppo le tue scelte.

• Non è necessario un server fisico dedicato per i server di configurazione. Questi funzionano abbastanza alla leggera. Avrai bisogno di una bassa latenza tra il tuo mongos ei tuoi server di configurazione. Dovrai sempre assicurarti che gli host siano affidabili e preparati per il disastro. Assicurati di ricontrollare le procedure di backup per un ambiente più semplice. I backup richiedono il coordinamento tra i pezzi mobili di un cluster più grande. Se possibile, eseguire i server di configurazione su server virtuali nello stesso datacenter.

• Sì, l'hardware descritto ha senso se si eseguono più frammenti su una singola macchina. Un singolo MongoDB su quella potente macchina lascerà la macchina per lo più inattiva. Un singolo processo mongod non può utilizzare molta RAM, I/O o CPU. Vorrete "core shard" l'host. In MongoHQ, facciamo ciò eseguendo ogni mongod in un contenitore, che possiamo isolare dalle altre istanze sulla stessa macchina. Con le tue specifiche, puoi eseguire fino a 10 frammenti su un singolo host, o più, se vuoi allungare gli host.

• È possibile avviarlo con un singolo frammento e migrare successivamente in un cluster più grande. Questo è il nostro approccio raccomandato alla sharding: non tagliare fino a quando non è necessario. Ritardando la condivisione, aumenti la tua flessibilità per apportare modifiche al tuo sistema. Quando la sharding è a posto, ti sei impegnato in un particolare percorso, senza flessibilità (che va bene quando conosci il futuro). Ritardando la condivisione, non ci sono compromessi.

• Gli arbitri non hanno bisogno di hardware dedicato. È possibile eseguire quelli su macchine virtuali. Questi non richiedono lo stesso livello di requisiti di backup, ma dovrebbero avere tempi di attività ottimali.

• L'utilizzo di 3 server non è un requisito per il tempo di attività solido. Tuttavia, quando un host di dati si interrompe per alcune ore, viene relegato in un singolo host di dati. Mentre retrocesso al singolo host di dati, il singolo host funzionerà correttamente. Poiché hai solo un secondo di dati in esecuzione, corri un rischio maggiore di interruzione. Detto questo, 2 nodi e un arbitro vanno bene per la maggior parte dei casi d'uso, e rimarranno su se uno dei nodi di dati fallisce.

Spero che questo aiuti! Gestiamo configurazioni simili a MongoHQ e siamo molto contenti del livello di prestazioni che otteniamo dagli host.

Answer 2

Ho intenzione di mettere alcuni pensieri qui.

Questa risposta è praticamente inutile senza conoscere il set di lavoro, tuttavia potrebbe creare alcuni indicatori.

Quale tipo di hardware consiglieresti per installare i server di configurazione?

I server di configurazione, nonostante il fatto di trovarsi sul proprio hardware (server, non una macchina virtuale) possono essere eseguiti facilmente sulla maggior parte dell'hardware di base, non è necessario nulla di particolare. Tutto ciò che fanno è archiviare la configurazione dei set, e anche in questo caso non vengono utilizzati in ogni momento, lo mongos s memorizzerà nella cache la configurazione dei cluster per gli intervalli.

Oppure posso metterli su virtualizzazione o su hardware più economico?

Non li metterei sulla virtualizzazione perché questo normalmente indica che sono fisicamente sullo stesso server o vicino. È necessario metterli su server ridondanti reali, tuttavia, si può ottenere hardware a basso costo per loro.

Assicurarsi di disporre di una rete decente tra i frammenti e i server di configurazione dovrebbe essere una conoscenza naturale.

La configurazione che ho descritto ha senso?

Non ne ho idea, senza una comprensione del vostro set di lavoro, tuttavia, dai suoni di esso si pensa MongoDB devono essere tutti in forma in memoria. Questo non è vero, solo il working set (http://docs.mongodb.org/manual/faq/storage/#what-is-the-working-set) può essere una parte assoluta dei tuoi dati in un intervallo di tempo specifico (normalmente 10 minuti) se giochi bene le tue carte.

E il rapporto tra RAM e disco rigido sui nodi shard?

Un po ', MongoDB può usare quel server ma scommetto che rimarrà inattivo la maggior parte del tempo, scommetto che non hai davvero calcolato correttamente il tuo working set.

Al momento sarebbe probabilmente più semplice ed economico mettere solo il doppio del numero di dischi in 1 frammento (1 master, 1 slave) e saltare il sharding finché non ne ho davvero bisogno.

Sì. Questa è una scommessa sicura se hai bisogno di quei dischi. Vado fino a dire che dovresti davvero capire se lo fai o no.

il sistema dovrebbe essere pronto per sharding dall'inizio

Come detto nella risposta precedente, è possibile creare un set sharded 1 membro e solo scalare da lì.

Dal momento che sto solo pensando di utilizzare 2 anziché 3 server per alta disponibilità/failsafe, probabilmente ho bisogno anche di arbitri.

Sì, l'utilizzo di 3 server è normalmente abbastanza solido per il failover automatico, che è la cosa importante qui. Se la maggior parte dei failover del server (50% o più), sarà necessario correggere manualmente il set di repliche.

Ciò significa che su un ambiente a due server per ogni frammento non si avrà alcun failover automatico e quindi MongoDB non comporterà uno riempimento completo di uno dei suoi principali vantaggi: failover automatico (questo è anche uno degli scopi principali degli insiemi repilica ...) .

Non solo questo, ma i tuoi utenti devono aspettare fino a quando non si risolve il problema con questo set, sono sicuro che questo, di per sé, ha dei problemi.

Hanno bisogno di hardware dedicato?

No, come detto nel mio commento (e nella documentazione), gli arbitri non hanno bisogno di eseguire su hardware dedicato. Tuttavia, detto questo può essere utile, specialmente se si desidera creare ridondanza di failover suddividendo gli arbitri in un altro data center.

L'arbitro può funzionare sulle ossa nude di un server, quindi se decidi di dividerlo non preoccuparti di 200 GB di RAM e SSD 6x400 GB. Basta avere un ... beh, un cellulare potrebbe tecnicamente eseguire un arbitro (se MongoDB supporta Android e iOS).

Oppure, per te, è necessario utilizzare 3 server separati per la ridondanza?

Non lo è, ma qualcosa di meno, come detto sopra, causerà problemi in caso di un failover.

Una buona opzione è quella di mettere effettivamente il tuo arbitro sui server delle applicazioni, magari anche con uno per server di applicazioni.