Distribuisci Elasticsearch e Kibana
Elasticsearch è un motore di ricerca open source di livello enterprise. Accessibile tramite un'ampia API, Elasticsearch può alimentare ricerche rapide che supportano le applicazioni di ricerca dati. Può scalare migliaia di server e ospitare petabyte di dati. La sua grande capacità deriva direttamente dalla sua architettura elaborata e distribuita.
I casi d'uso più comuni per Elasticsearch sono le analisi che utilizzano estratti di dati superveloci da origini dati strutturate e non strutturate e la ricerca full-text alimentata da un ampio linguaggio di query e completamento automatico.
Architettura
Questa architettura di riferimento mostra una distribuzione in cluster di Elasticsearch e Kibana.
Descrizione dell'immagine elk-oci.png
Questa architettura ha i seguenti componenti:
- Domini di disponibilità
I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono infrastrutture quali l'alimentazione o il raffreddamento o la rete di dominio di disponibilità interna. È quindi improbabile che un errore a un dominio di disponibilità influenzi gli altri domini di disponibilità nell'area.
- Domini di errore
Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità ha tre domini di guasto con alimentazione e hardware indipendenti. Quando si distribuiscono risorse su più domini di errore, le applicazioni possono tollerare errori fisici del server, la manutenzione del sistema e gli errori di alimentazione all'interno di un dominio di errore.
- Host di base
L'host bastion è un'istanza di calcolo che funge da punto di accesso sicuro e controllato alla topologia dall'esterno del cloud. L'host bastione viene eseguito in genere in una zona demilitarizzata (DMZ). Consente di proteggere le risorse sensibili inserendole in reti private a cui non è possibile accedere direttamente dall'esterno del cloud. La topologia dispone di un singolo punto di accesso noto che è possibile monitorare e controllare regolarmente. Così, è possibile evitare di esporre i componenti più sensibili della topologia senza compromettere l'accesso a loro.
- Load balancer
Il load balancer bilancia le operazioni di indice sui nodi dati e l'accesso Kibana ai nodi principali. Utilizza due listener, uno per Kibana e uno per l'accesso ai dati di indice, utilizzando le backend del nodo principale e le backend del nodo dati. Il load balancer si trova in una subnet pubblica con un indirizzo IP pubblico.
- Nodi principali
I nodi principali eseguono task di gestione cluster, ad esempio la creazione di indici e il ribilanciamento delle partizioni. Non memorizzano dati. Tre nodi principali (consigliati per cluster più grandi) vengono distribuiti su tre domini di errore per garantire un'elevata disponibilità.
- Nodi dati
Tre nodi di dati vengono distribuiti su tre domini di errore per un'elevata disponibilità. Si consiglia di calcolare le istanze ottimizzate per la memoria perché Elasticsearch dipende dalla quantità di memoria disponibile. Ogni nodo dati è configurato con una memorizzazione a blocchi GiB 200. Oltre alle VM, Oracle Cloud Infrastructure offre potenti istanze Bare Metal collegate nei cluster a un'infrastruttura di rete da 25 Gb senza sovrascrittura. Questa configurazione garantisce una bassa latenza e un throughput elevato, che garantiscono carichi di lavoro distribuiti in streaming ad alte prestazioni.
- Kibana
Come i nodi principali, Kibana dispone di requisiti di risorse relativamente leggeri. La maggior parte dei calcoli viene spinta a Elasticsearch. In questa distribuzione, Kibana viene eseguito sui nodi principali.
Suggerimenti
Le vostre esigenze potrebbero differire dall'architettura descritta qui. Utilizzare i suggerimenti riportati di seguito come punto di partenza.
- VCN
Quando si crea un VCN, determinare il numero di blocchi CIDR richiesti e la dimensione di ciascun blocco in base al numero di risorse che si prevede di associare alle subnet in VCN. Utilizzare blocchi CIDR che si trovano all'interno dello spazio degli indirizzi IP privati standard.
Dopo aver creato un VCN, è possibile modificare, aggiungere e rimuovere i blocchi CIDR.
Quando si progettano le subnet, prendere in considerazione il flusso di traffico e i requisiti di sicurezza. Allegare tutte le risorse all'interno di uno specifico livello o ruolo alla stessa subnet, che può fungere da limite di sicurezza.
Utilizzare subnet regionali.
- Gruppi di sicurezza di rete (NSG)
È possibile utilizzare NSG per definire un set di regole di ingresso e di uscita applicabili a VNIC specifiche. Si consiglia di utilizzare NSG anziché liste di sicurezza, poiché NSG consentono di separare l'architettura di subnet di VCN dai requisiti di sicurezza dell'applicazione. Nell'architettura di riferimento, tutta la comunicazione di rete è controllata tramite NSG.
- Memorizzazione a blocchi
Questa architettura utilizza 200 GB di memorizzazione a blocchi. Si consiglia di configurare un volume manager logico (LVM) per consentire la crescita del volume se si ha bisogno di più spazio. Ogni volume a blocchi è configurato per utilizzare prestazioni bilanciate e fornisce IOPS 35K e MBps 480 di throughput.
- Calcola forme
Questa architettura utilizza una forma di virtual machine (VM.Standard2.24) per tutti i nodi di dati. Queste istanze di calcolo possono eseguire il push del traffico a 25 Gbps e fornire 320 GB di RAM.
Considerazioni
- Prestazioni
Elasticsearch dipende dalla quantità di memoria disponibile. Per ottenere le migliori prestazioni, utilizzare forme di calcolo che forniscono una buona quantità di memoria. È possibile utilizzare forme Bare Metal, dove è possibile ottenere fino a 768 GB di RAM.
- Disponibilità
I domini di errore forniscono la migliore resilienza all'interno di un dominio di disponibilità. Se è necessaria una maggiore disponibilità, prendere in considerazione l'utilizzo di più domini di disponibilità o più aree per la distribuzione.
- Scalabilità
Sebbene sia possibile scalare manualmente i nodi master e dati in entrata e in uscita, si consiglia di utilizzare il ridimensionamento automatico per ridurre al minimo la possibilità che i servizi diventino affamati per le risorse con carichi elevati. Una strategia di ridimensionamento automatico deve considerare sia i nodi master che i nodi dati.
- Costo
Il costo della distribuzione Elasticsearch dipende dalle esigenze di memoria e disponibilità. Le forme di calcolo scelte hanno un impatto maggiore sui costi associati a questa architettura.
Distribuisci
Il codice richiesto per distribuire questa architettura di riferimento è disponibile in GitHub. È possibile estrarre il codice in Oracle Cloud Infrastructure Resource Manager con un solo clic, creare lo stack e distribuirlo. In alternativa, scaricare il codice da GitHub nel computer, personalizzare il codice e distribuire l'architettura utilizzando Terraform CLI.
- Distribuisci utilizzando Oracle Cloud Infrastructure Resource Manager:
- Fare clic su
Se non si è già connessi, immettere la tenancy e le credenziali utente.
- Rivedere e accettare i termini e le condizioni.
- Selezionare l'area in cui distribuire lo stack.
- Seguire le istruzioni e i prompt sullo schermo per creare lo stack.
- Dopo aver creato lo stack, fare clic su Azioni Terraform e selezionare Piano.
- Attendere il completamento del job e rivedere il piano.
Per apportare eventuali modifiche, tornare alla pagina Dettagli stack, fare clic su Modifica stack e apportare le modifiche necessarie. Eseguire di nuovo l'azione Piano.
- Se non sono necessarie ulteriori modifiche, tornare alla pagina Dettagli stack, fare clic su Azioni Terraform e selezionare Applica.
- Fare clic su
- Distribuire utilizzando Terraform CLI:
- Andare a GitHub.
- Scaricare o clonare il codice sul computer locale.
- Seguire le istruzioni riportate in
cluster/single-ad/README.md.
Log modifiche
Questo log elenca solo le modifiche significative:
| 9 dicembre 2020 | Aggiunte istruzioni per distribuire l'architettura utilizzando Oracle Cloud Infrastructure Resource Manager. |
| Maggio 29, 2021 | Aggiunto il pulsante Distribuisci in Oracle Cloud. |
| Giugno 21, 2021 | Collegamento al pulsante Distribuisci in Oracle Cloud aggiornato. |