2016-03-15 48 views
5

Attualmente, ho diversi nodi Elasticsearch in esecuzione su diverse macchine bare metal contenenti indici delle dimensioni di TB. Stiamo ristrutturando la nostra infrastruttura e non sono sicuro che sia il modo migliore.Qual è l'impostazione consigliata per un cluster Elasticsearch che contiene dati alla scala di TB e superiori?

Ho guardato Docker, Mesos e Vagrant come alternative, ma non sono sicuro che siano nemmeno possibili. Ci sono quattro situazioni penso che sono rilevanti (insieme con il problema che ho avuto):

  1. Mesos-Elasticsearch: Questo pacchetto viene eseguito su elasticsearch Mesos. Questo sembra fantastico, ma sembra che consenta solo il ridimensionamento dei nodi di dati a dimensioni ridotte del disco. Inoltre, non ci sono nodi master/client. Il pacchetto è piuttosto alpha su Github al momento - ho ricevuto un errore 'No route to Host' e MasterNotDiscoveredException sulla loro configurazione predefinita. Qualcuno ha esperienza con questo?
  2. Docker: Non ho molta familiarità con i contenitori, ma Dockerhub ha diversi contenitori per Elasticsearch. Inoltre, Mesos consente di eseguire i contenitori su di esso. Sono preoccupato per il basso spazio su disco in ogni contenitore poiché i miei dati sono nella scala dei TB. Inoltre, i dati sono persistenti. È possibile ridimensionare il disco del contenitore o esiste una configurazione diversa per i contenitori Docker?
  3. VM Vagrant: Immagino di avere una VM per ciascun nodo ES adatto per allocare risorse. C'è qualche vantaggio sostanziale in questo rispetto alla corsa su metallo nudo? Questo non sembra essere compatibile con Mesos.
  4. Bare-metal: questa è l'impostazione corrente.

Vorrei sapere quale delle quattro è la configurazione preferita per un cluster Elasticsearch a livello di TB. Pro e contro di ciascuna opzione?

+0

Non sicuro, ma avete familiarità con http: // elasticsearch .mesosframeworks.com forse? –

+0

Sì, quella è in realtà la pagina del prodotto per http://mesos-elasticsearch.readthedocs.org/en/latest/, che è la prima opzione. – CaptainMcChinchillas

+0

Giusto, questo è quello che sospettavo, ma poiché non ci sono collegamenti, volevo essere sicuro al 100%;) –

risposta

5

Sono l'autore di Apache Mesos Elasticsearch Framework. Consiglierei di provare tutti questi approcci e scegliere quale sia la migliore esperienza. E quando si tratta di prestazioni, assicurarsi di avere a mente i requisiti di prestazione e quindi eseguire i test. Ci sono anche altre cose da considerare. Che tratterò nelle domande.

  1. Il Elasticsearch Framework per mesos è il più resistente di queste quattro opzioni. I nodi Elasticsearch vengono eseguiti come task Mesos. Se una delle attività non riesce (errore hardware o software), vengono riavviate da qualche altra parte all'interno del cluster Mesos. Se si desidera aggiungere nodi (per aumentare le prestazioni) o rimuovere nodi (per ridurre l'utilizzo delle risorse), è semplice come inviare una richiesta di arricciatura su una riga. I dati sono molto sicuri. La configurazione predefinita (che può essere sostituita) replica tutti i dati su tutti i nodi. Quindi il cluster può subire un evento catastrofico e rimanere con un singolo nodo e non perdere alcun dato. È anche possibile utilizzare qualsiasi plug-in del volume di Docker per scrivere i dati su un volume esterno, in modo che, se i compiti muoiono, i dati siano ancora contenuti nei volumi del cloud. Ci sono anche alcune altre funzionalità, controlla il sito web. Controlla anche i video su Container Solutions youtube channel. Stiamo anche sviluppando strumenti per semplificare lo sviluppo, vedere minimesos.

  2. Questo è perfettamente ragionevole, ma devi pensare a come orchestrare il tuo cluster. E cosa succederebbe se uno o più dei contenitori morissero? Puoi subire quella perdita? In tal caso, questa potrebbe essere l'opzione migliore per DevOps (ad esempio, è possibile replicare e testare un cluster che assomiglia alla realtà).

  3. Questa è l'unica opzione contro cui starei. Sarebbe perfetto per lo sviluppo, ma vedresti un problema di prestazioni significativo nella produzione. Potresti, potenzialmente, avere una VM completa (vagante) all'interno di un'altra VM (cloud). Il sovraccarico non è necessario. Link 1, Link 2.

  4. Questo è il metodo consigliato da Elastic ufficiale e probabilmente fornirà le massime prestazioni per una determinata configurazione hardware. Ma poiché si tratta di distribuzioni statiche a) molte delle risorse delle macchine sarebbero sprecate (RAM/CPU/ecc. Inutilizzate), b) c'è un ritardo significativo (soprattutto nelle grandi aziende!) Nel provisioning di nuove istanze (confrontare con un singolo api call) ec) se un'istanza fallisce, non verrà sostituita e non verrà risolta finché qualcuno non la risolverà (confronta con failover automatico). Se i tuoi requisiti per Elasticsearch sono corretti, non hai bisogno di flessibilità tipo DevOps e non ti preoccupa un po 'di downtime, allora questo è probabilmente il metodo più semplice (ma assicurati di avere la tua configurazione ES giusta!).

Quindi, se mi fosse, allora vorrei prendere in considerazione la messa a punto dockerized per i test, le attività di produzione di piccole POC e forse molto piccoli. Qualunque cosa in più allora opterei per l'opzione Mesos Elasticsearch ogni volta.

+0

Grazie per l'ottima scrittura e il lavoro con il framework ES. Non sono l'OP, ma sarei particolarmente interessato a come utilizzare i volumi RBD come [contiv/volplugin] (https://github.com/contiv/volplugin) per esempio. Se ho capito bene, hai lavorato sul supporto ancora mancante per i driver di volume Docker dei volumi persistenti di Mesos, la comprensione è corretta? – Tobi

+0

Grazie! Quando ho provato Elasticsearch Framework, ho visto tutti i vantaggi che hai elencato. I problemi che ho con esso sono 1) quando ho provato la configurazione demo, poteva solo far apparire un executor; gli altri due continuavano a fallire e ripartire, 2) non ero sicuro di come sostituire l'elasticsearch di default.configurazione yml nel pacchetto (non è un grosso problema - basta sfogliare il codice per vedere come), 3) Non sembrava possibile creare master/nodi client (potrebbe essere correlato a 2 o irrilevante dal momento che gestito da mesos ?), e 4) non è possibile uccidere facilmente gli esecutori (ma penso che questo sia un problema noto). – CaptainMcChinchillas

+0

@Tobi: Sì, hai ragione! Controlla: https://github.com/mesos/elasticsearch/blob/master/docs/index.md#external-volumes CaptainMcChinchillas: Si prega di sollevare un problema, o e-mail [email protected] per il supporto. –

1

La mia azienda ha più o meno le stesse domande, ma forse è un pò più in basso la strada quando si tratta di avere un POC ecc

Attualmente, stiamo correndo un 3 nodo di cluster su ES Mesos 0,27 .1 via Marathon con un custom Docker image. Montiamo i volumi host (percorsi) nei contenitori, il che significa che è possibile montare ad esempio un volume Ceph sull'host del Mesos Slave. Ma questo è in qualche modo un processo abbastanza manuale. Il problema più grande è ai miei occhi la sicurezza dei dati, perché per impostazione predefinita i dati vengono memorizzati solo sull'host stesso e il comportamento quando l'applicazione viene ridimensionata in Marathon (devono essere utilizzati i vincoli, in modo che venga eseguito un solo nodo per Mesos Schiavo ecc.).

Abbiamo anche provato il menzionato Mesos ES framework alcuni mesi fa, ma non eravamo soddisfatti dello stato del framework. Da quello che vedo su docs è migliorato molto durante gli ultimi mesi, ma alcune caratteristiche importanti sono ancora mancanti da Mesos (supporto dei volumi persistenti per i driver di volume Docker, ad esempio) ... Ma questo non è un problema del framework, ma con Mesos.

Darò un altro tentativo al framework Mesos. Mi piace soprattutto la possibilità di impostare --externalVolumeDriver, il che significherebbe che ora possiamo probabilmente utilizzare il driver del volume Docker RBD (dato che stiamo usando Ceph) ...

+0

Tobi, il mesos ES framework supporta volumi esterni. Vedi https://github.com/mesos/elasticsearch/blob/master/docs/index.md#external-volumes. Più feedback significa più funzionalità. Fatemi sapere cosa ne pensate. Grazie! –

+0

@PhilWinder Grazie per il vostro feedback. Quello che non ho capito è se/come i volumi vengono quindi mappati nel contenitore del nodo. È fatto automaticamente? – Tobi

+0

Sì, questo viene fatto automaticamente. Solo la directory dei dati è mappata al volume. –