Skip to content

Ghid de administrare


Cuprins

1. ElasticSearch Clustering

ElasticSearch este construit pentru a fi întotdeauna disponibil și pentru a vă adapta la nevoile dvs. Scala poate proveni de la cumpărarea de servere mai mari (scală verticală sau scalare în sus) sau de la cumpărarea mai multor servere (scară orizontală sau scalare). În timp ce ElasticSearch poate beneficia de hardware mai puternic, scara verticală are limitele sale. Scalabilitatea reală vine de la scara orizontală - capacitatea de a adăuga mai multe noduri la cluster și de a împrăștia încărcătura și fiabilitatea între ele. Cu cele mai multe baze de date, scalarea pe orizontală necesită, de obicei, o revizuire majoră a aplicației dvs. pentru a profita de aceste cutii extra. În schimb, ElasticSearch este distribuit prin natură: știe cum să gestioneze mai multe noduri pentru a oferi o scală și o disponibilitate ridicată. Acest lucru înseamnă, de asemenea, că aplicația dvs. nu trebuie să aibă grijă de aceasta. Un nod este o instanță care rulează ElasticSearch, în timp ce un cluster constă dintr-unul sau mai multe noduri cu același nume de cluster.name care lucrează împreună pentru a-și împărtăși datele și volumul de lucru. Pe măsură ce nodurile sunt adăugate sau eliminate din cluster, clusterul se reorganizează pentru a împrăștia în mod egal datele. Un nod din cluster este ales să fie nodul principal, care are sarcina de a gestiona modificări la nivel de cluster cum ar fi crearea sau ștergerea unui index sau adăugarea sau eliminarea unui nod din cluster. Nodul principal nu trebuie să fie implicat în modificări sau căutări la nivel de document, ceea ce înseamnă că numai un singur nod principal nu va deveni un obstacol în calea creșterii traficului. Orice nod poate deveni master. Fiecare nod știe unde exista fiecare document și poate transmite cererea noastră direct către nodurile care dețin datele de care suntem interesați. Indiferent de nodul de interes, gestionăm procesul de colectare a răspunsului din nod sau noduri care dețin datele și returnează răspunsul final la client. Totul este gestionat transparent de către Elasticsearch. CyberQuest profită de aceast tehnologie, indiferent dacă baza de date este cluster sau un singur nod de desfășurare si nu este necesară nici o configurație suplimentară a CyberQuest.

1.1. Verificarea stari clusterului

CyberQuest vine instalat cu pluginul ElasticSearch Kopf pentru o reprezentare vizuală a bazei de date. Acesta poate fi accesat de pe un browser web de pe portul 9000 al CyberQuest IP adresat:

http://CyberQuest:9000/

! Implicit, portul 9000 este securizat de utilitarul local iptables Debian, pentru a fi accesibil numai de pe localhost.

Acest lucru poate fi verificat din interfața chitului executând următoarea comandă:

iptables -L

Alt text

Pentru a putea utiliza pluginul Kopf, această regulă trebuie să fie ștersă și schimbată cu următoarele comenzi:

iptables -X

Alt text

iptables -F

Alt text

Verificați modificările cu comanda anterioară:

iptables -L

Alt text

Aceasta înseamnă că pluginul poate fi lansat și poate comunica cu baza de date.

Într-un browser web, tastați următorul link in bara de navigare:

http://CyberQuestIP:9000/

Rezultatele ar trebui să fie: Alt text

Pentru o instalare a unui singur nod sau: Alt text Pentru două sau mai multe noduri grupate.

1.2. Adăugarea de noduri ale cluster-ului

ElasticSearch este configurat să utilizeze descoperirea unicast din cutie pentru a împiedica nodurile să se unească accidental cu un cluster. Numai nodurile care rulează pe aceeași mașină vor forma automat cluster.

Pentru a utiliza unicast, oferiți ElasticSearch-ului o listă de noduri pe care ar trebui să încerce să faca legatura. Atunci când un nod contactează un membru al listei unicast, primește o stare de cluster completă care listează toate nodurile din cluster. Apoi contactează master și se alătură clusterului.

Aceasta înseamnă că lista dvs. unicast nu trebuie să includă toate nodurile din cluster. Pur și simplu are nevoie de noduri suficiente pentru ca un nou nod să poată găsi pe cineva cu care să comunice. Dacă folosiți maeștrii dedicați, listați doar trei maeștri dedicați și numiți o zi. Această setare este configurată în elasticsearch.yml: Alt text

discovery.zen.ping.unicast.hosts: ["OtherEasticSearchHost1","OtherEasticSearchHost2"]

Salvați și reporniți serviciul ElasticSearch:

systemctl restart elasticsearch.service

2. Documentație suplimentară pentru ElasticSearch

2.1. Zen Discovery

Zen Discovery este modulul de descoperire pentru elasticsearch și este implicit. Oferă descoperire unicast, dar poate fi extinsă pentru a suporta mediile cloud și alte forme de descoperire.

Zen Discovery este integrată cu alte module, de exemplu, întreaga comunicare între noduri se face folosind modulul de transport.

Acesta este împărțit în mai multe module secundare, care sunt explicate mai jos:

Ping

Acesta este procesul în care un nod utilizează mecanismele de descoperire pentru a găsi alte noduri.

2.2. Unicast

Descoperirea Unicast necesită o listă de gazde care să fie utilizată ca al mod de distribuție a relațiilor de cluster. Aceste gazde pot fi specificate ca nume de gazdă sau adrese IP; gazdele specificate ca nume de gazde sunt rezolvate la adresele IP în timpul fiecărei runde de pinging. Rețineți că, odată cu gestionarea securității Java, JVM implicit implică rezolvarea definitivă a numelor gazdei pe termen nelimitat. Acest lucru poate fi modificat prin adăugare networkaddress.cache.ttl=<timeout> in Java security policy. Orice gazde care eşueaza vor fi înregistrate. Rețineți, de asemenea, că, cu ajutorul managerului de securitate Java, JVM implicit implică rezolvarea numerelor de gazdă negative pentru zece secunde. Acest lucru poate fi modificat prin adăugare:

networkaddress.cache.negative.ttl=<timeout> in Java security policy.

Descoperirea Unicast oferă următoarele setări cu prefixul discovery.zen.ping.unicast:

Setari Descriere
Gazde Fie o setare de matrice, fie o setare delimitată de virgulă. Fiecare valoare ar trebui să fie sub formă de gazdă: port sau host (unde portul este implicit la setarea transport.profiles.default.port care revine la transport.tcp.port dacă nu este setatRețineți că gazdele IPv6 trebuie să fie in paranteze. Implicit la 127.0.0.1, [:: 1]
hosts.resolve_timeout Timpul de așteptare pentru căutările DNS în fiecare rundă de pinging. Specificate ca unități de timp. Implicit la 5 secunde.

Descoperirea unicast utilizează modulul de transport pentru a efectua descoperirea.

2.3. Alegeri principale

Ca parte a procesului de ping, un master al cluster-ului este ales sau asociat. Acest lucru se face automat. Discovery.zen.ping_timeout (care implică 3 secunde) permite ajustarea timpului alegerilor pentru a trata cazurile de rețele lente sau congestionate (valorile mai ridicate asigură mai puține șanse de eșec). Odată ce un nod se va alătura, va trimite o cerere de conectare către master (discovery.zen.join_timeout), cu un timp de așteptare la 20 de ori mai mare decât ping timeout-ului.

Atunci când nodul principal se oprește sau a întâmpinat o problemă, nodurile clusterului încep să pâlpâie din nou și vor alege un master nou. Această rundă de ping, de asemenea, servește ca o protecție împotriva eșecurilor de rețea (parțiale) în care un nod ar putea crede pe nedrept că comandantul a eșuat. În acest caz, nodul va auzi pur și simplu de la alte noduri despre master-ul curent activ.

Dacă discovery.zen.master_election.ignore_non_master_pings este adevărat, ping-urile din nodurile care nu sunt eligibile pentru master (nodurile unde node.master este fals) sunt ignorate în timpul alegerilor principale; valoarea implicită este falsă.

Nodurile pot fi excluse de la a deveni un master prin setarea node.master la fals. Descoperirea.zen.minimum_master_nodes stabilește numărul minim de noduri eligibile pentru master care trebuie să se alăture unui master nou ales pentru a finaliza alegerile și pentru ca nodul ales să accepte masteratul. Aceeași setari controlează numărul minim de noduri eligibile master activ care ar trebui să facă parte din orice cluster activ. Dacă această cerință nu este îndeplinită, nodul principal activ va cadea și va începe o nouă alegere principală.

Această setare trebuie să fie setată la un quorum al nodurilor dvs. eligibile. Se recomandă să se evite numai două noduri eligibile, deoarece un cvorum de două este de două. Prin urmare, o pierdere a fiecărui nod eligibil principal va duce la un cluster inoperabil.

2.4. Detectarea defecțiunilor

Există două procese pentru detectarea erorilor de funcționare. Primul este maestrul, ‘’ping’’, toate celelalte noduri din cluster și verificând dacă sunt active. Iar la celălalt capăt, fiecare nod ‘’ping’’, pentru a verifica dacă este activ sau dacă trebuie inițiat un proces.

Următoarele setări controlează procesul de detectare a erorilor utilizând prefixul discovery.zen.fd:

Setari Descriere
ping_interval Cât de des devine un nod pinged. Valori prestabilite la 1s
ping_timeout Cât timp să așteptați un răspuns ping, este implicit la 30s
ping_retries Câte eșecuri / expirări ale ping-ului determină ca un nod să fie considerat eșuat. Valoare implicită la 3.

2.5. Actualizări status în cluster

Nodul principal este singurul nod dintr-un cluster care poate modifica starea clusterului. Nodul master procesează simultan o actualizare de stare a clusterului, aplică modificările necesare și publică starea cluster actualizată la toate celelalte noduri din cluster. Fiecare nod primește mesajul de publicare, îl recunoaște, dar nu îl aplică încă. Dacă comandantul nu primește confirmarea de la cel puțin nodurile discovery.zen.minimum_master_nodes într-un anumit timp (controlat de setarea discovery.zen.commit_timeout și implicit la 30 de secunde), modificarea stării clusterului este respinsă. Odată ce au răspuns suficiente noduri, starea clusterului este angajată și un mesaj va fi trimis tuturor nodurilor. Apoi, nodurile continuă să aplice noua stare a cluster-ului la starea lor internă. Nodul principal așteaptă ca toate nodurile să răspundă, până la un timp de expirare, înainte de a procesa următoarele actualizări din coadă. Discovery.zen.publish_timeout este setat, în mod implicit, la 30 de secunde și este măsurat din momentul lansării publicării. Ambele setări de timp pot fi modificate dinamic prin setările de actualizare a clusterului api.

2.6. Documentație extensivă

Documentația care cuprinde bazele de date poate fi găsită aici:

https://www.elastic.co/guide/en/elasticsearch/guide/index.html

3. Sistemul de backup

3.1. Mysql baza de date dump

Majoritatea configurațiilor din aplicație pentru CyberQuest sunt stocate în baza de date MySQL locală.

Acest lucru este susținut zilnic, folosind un script MySQL dump:

DATE=date +%Y-%m-%d

mkdir -p /data/mysqlbackups/

mysqldump -u [dbuser] -p[dbpass] --all-databases | gzip > /data/mysqlbackups/$DATE.sql.gz

Inlocuirea [dbuser] si [dbpass] cu numele de utilizator MySQL și respectiv parola.

Acest script este executat zilnic pe o bază de lucru cronjob.

Pentru a verifica dacă scriptul este adăugat la planificatorul crontab, utilizați următoarea comandă:
crontab –l

Alt text

Următoarea linie trebuie să fie prezentă: Alt text

Dacă nu este, poate fi adăugat cu:

crontab -e

utilizați linia de pe ultimul rând:

30 2 * * * /var/opt/cyberquest/dataacquisition/bin/mysql_full_backup.sh

Salvati și ieși.

În cele din urmă, verificație /data/mysqlbackups/ dosar pentru baza de date backup

3.2. Backup de date despre evenimente

În mod implicit, fiecare mesaj care este colectat de CyberQuest este trimis automat la depozitele de date configurate:

Default: /data/storage/default

Alt text

Evenimentele sunt normalizate (format JSON) comprimate, criptate și semnate digital.

Acestea pot fi importate ulterior prin crearea unei alte stocări de date din Setări Alt text > Stocări de date Alt text> Stocare de date noi Alt text Buton, copierea fișierelor în acest nou depozit de date și crearea unei noi lucrări de import din Setări Alt text> Jobs Alt text> New Job Buton.

Creați o lucrare nouă cu "Job Type" - lucrare de import: Alt text

Și selectați stocarea de date nou creată din meniul derulant "Datele de stocare" Alt text

3.3. Locațiile backup-lui

Locațiile de rezervă prestabilite pentru soluțiile de rezervă pentru terți sunt:

a. Setările bazei de date de configurare

Mod implicit: /data/mysqlbackups/ folder

b. Backup de date despre evenimente

Mod implicit: /data/storage/default/ folder

c. Curentul CyberQuest/Cyberquest fișiere de instalare:

Mod implicit: /var/opt/cyberquest/ folder