Skip to content

Scalare orizontală prin serviciul NoSQL

Scalarea orizontală este o strategie pe care utilizatorii CYBERQUEST o pot utiliza pentru a îmbunătăți performanța nodului de server prin adăugarea mai multor instanțe ale serverului la grupul de servere existent, astfel încât sarcina să fie distribuită în mod egal. În cazul scalării orizontale, capacitatea serverului individual nu se modifică, dar sarcina pe server este diminuată. Scalabilitatea orizontală se realizează cu ajutorul unui sistem de fișiere distribuit, al clusterizării și al echilibrării sarcinii. Unele dintre motivele pentru care întreprinderile aleg să scaleze orizontal includ o creștere a concurenței I/O, necesitatea de a reduce sarcina pe nodurile existente și de a extinde capacitatea discului. Scalarea orizontală este considerabil de ușoară, deoarece puteți adăuga mai multe mașini la fondul existent. Ea urmează partiționarea datelor în care fiecare nod conține doar o parte a datelor. Pentru dispozitivul NoSQL care asigură scalarea orizontală, CYBERQUEST utilizează Online DataStorage.

Introducere la Clustering-ul de stocare a datelor online

Online DataStorage este construit pentru a fi disponibil în permanență și pentru a se adapta la nevoile dumneavoastră. Extinderea poate proveni din implementarea unor servere mai performante, în special în ceea ce privește considerentele legate de CPU și de memorie (extindere verticală, sau scalare în sus) sau din implementarea mai multor servere (extindere orizontală, sau scalare în jos). În timp ce Online DataStorage poate beneficia de un hardware mai puternic, scara verticală are limitele sale. Adevărata scalabilitate provine de la scara orizontală, capacitatea de a adăuga mai multe noduri la cluster și de a repartiza sarcina și fiabilitatea între acestea. În cazul majorității bazelor de date, extinderea pe orizontală necesită, de obicei, o mare revizuire a aplicației pentru a profita de aceste cutii suplimentare. Pe contrast, Online DataStorage este distribuit prin natura sa: știe cum să gestioneze mai multe noduri pentru a oferi scalabilitate și disponibilitate ridicată. Acest lucru înseamnă, de asemenea, că că aplicația dvs. nu trebuie să se preocupe de aceasta. Un nod este un instanță în curs de execuție a Online DataStorage, în timp ce un cluster este format dintrun sau mai multe noduri în același cluster.name, care lucrează împreună pentru a își împart datele și volumul de lucru. Pe măsură ce nodurile sunt adăugate la sau eliminate din cluster, clusterul se reorganizează pentru a distribui datele în mod egal.

Avantajele clusterelor Online DataStorage sunt:

  1. Date distribuite: În cluster, datele sunt distribuite, replicate la un alt server. Astfel, în caz de defecțiune a unui nod, datele pot fi restaurate de la nodul replică. Se evită astfel un singur punct de eșec.

  2. Roluri de nod dedicate: Fiecare nod are un rol dedicat care îi este atribuit, care asigură un rol specific și o distribuție a sarcinii bazată pe roluri, prin urmare creșterea performanței. Iată două roluri importante ale nodurilor

  3. Nodul de date: Aceste noduri stochează numai date și efectuează activități legate de date. operațiuni legate de date, căutare și manipulare de date.

  4. Nodul principal: Maestru al tuturor nodurilor, acesta deține responsabilitatea de a gestiona toate nodurile. clusterului, adăugarea și eliminarea nodurilor din cluster, ținerea evidenței a nodurilor în viață, reselectarea maestrului în cazurile adecvate.

  5. Scalabilitate: Modelul cluster este ușor de scalat la mai multe numere de noduri, crescând astfel performanța și fiabilitatea stocării online a datelor.

Unul dintre nodurile din cluster este ales să fie nodul master, fiind responsabil de gestionarea modificărilor la nivelul clusterului, cum ar fi crearea/eliminarea unui index sau adăugarea/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ă existența unui singur nod principal nu va deveni un blocaj pe măsură ce traficul crește. Orice nod poate deveni maestru.

Fiecare nod știe unde se află fiecare document și poate transmite cererea noastră. direct către nodurile care dețin datele care ne interesează. Oricare dintre ele nod cu care ne adresăm gestionează procesul de colectare a unui răspuns de la nodul sau nodurile care dețin datele și returnarea răspunsului final către client. Toate acestea sunt gestionate în mod transparent de Online DataStorage.

CYBERQUEST profită de această tehnologie, astfel încât, indiferent dacă baza de date subiacentă este o implementare în clustere sau cu un singur nod, nu este nevoie de o implementare suplimentară configurare suplimentară a CYBERQUEST.

Verificarea sănătății clusterului

CYBERQUEST vine instalat cu Online DataStorage. Cerebro pentru o reprezentare vizuală a bazei de date, prin accesarea adresei IP CYBERQUEST pe portul 9000 printr-un browser web.

Rezultatele sunt următoarele:

Alt Image

pentru o instalare cu un singur nod, sau:

Alt Image

pentru două sau mai multe noduri grupate.

Aducerea de noduri de cluster

În mod normal, Online DataStorage este configurat pentru a utiliza descoperirea unicast pentru a preveni aderarea accidentală a nodurilor la un cluster. Numai nodurile care rulează pe aceeași mașină vor forma automat un cluster. Pentru a utiliza unicast, furnizați Online DataStorage cu o listă de noduri pe care ar trebui să încerce să le contacteze. Atunci când un nod contactează un membru al listei unicast, primește o stare de cluster completă care enumeră toate nodurile din cluster. Acesta contactează apoi masterul și se alătură clusterului.

Acest lucru înseamnă că lista dvs. de unicast nu trebuie să includă toate nodurile din cluster. Este nevoie doar de suficiente noduri pentru ca un nou nod să poată găsi pe cineva cu care să vorbească. Dacă utilizați maeștrii dedicați, listați doar cei trei maeștrii dedicați și încheiați ziua. Această setare este definită în fișierul de configurare elasticsearch.yml:

Alt Image

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

După ce ați terminat, salvați și reporniți serviciul Online DataStorage:

systemctl restart opensearch.service

Documentație suplimentară online DataStorage

Documentația suplimentară privind bazele de date poate fi găsită aici:https://www.elastic.co/guide/en/elasticsearch/guide/master/index.html

Scalarea orizontală pe MariaDB

Introducere

CYBERQUEST utilizează baza de date MariaDB pentru datele de configurare a soluției.

În cazul arhitecturilor de înaltă disponibilitate, nodurile MariaDB sunt configurate într-un cluster.

Scopul acestui document este de a descrie din punct de vedere tehnic procesul de configurare a clusterului MariaDB. Pentru clusterizare se utilizează MariaDB Galera Cluster.

Configurarea clusterului MariaDB

1) Configurarea interfeței de rețea

Asigurați-vă că există ip-uri fixe pe toate nodurile

Alt Image

Ifdown ens192

Ifup ens192

Adăugați în/etc/hosts înregistrări de nod (pe toate nodurile, în acest caz db1 și db2) nano /etc/hosts

nano /etc/hosts

Alt Image

2) Configurarea fișierului 60-galera.conf

Fișierul de configurare a grupării 60-galera.cnf este specific fiecărui nod și se creează manual - dacă nu se află în fișierul/etc/mysql/mariadb.conf.d/

  • Fișier de configurare pentru mașina 192.168.200.139 (db1)
# * Galera-related settings 
# 
# See the examples of server wsrep.cnf files in /usr/share/mysql 
# and read more at https://mariadb.com/kb/en/galera-cluster/ 

[galera] 
# Mandatory settings 
#wsrep_on = ON 
#wsrep_provider = 
#wsrep_cluster_address = 
#binlog_format = row 
#default_storage_engine = InnoDB 
#innodb_autoinc_lock_mode = 2 

# Allow server to accept connections on all interfaces. 
#bind-address = 0.0.0.0 

# Optional settings 
#wsrep_slave_threads = 1 
#innodb_flush_log_at_trx_commit = 0 


[mysqld] 
binlog_format=ROW 
default-storage-engine=innodb 
innodb_autoinc_lock_mode=2 
bind-address=0.0.0.0 

# Galera Provider Configuration 
wsrep_on=ON 
wsrep_provider=/usr/lib/galera/libgalera_smm.so 

# Galera Cluster Configuration 
wsrep_cluster_name="CQ_CLUSTER" 
wsrep_cluster_address="gcomm://192.168.200.139,192.168.200.140" 

# Galera Synchronization Configuration 
wsrep_sst_method=rsync 

# Galera Node Configuration 
wsrep_node_address="192.168.200.139" 
wsrep_node_name="db1"
  • Configuration file for machine 192.168.200.140 (db2)
# * Galera-related settings 
# 
# See the examples of server wsrep.cnf files in /usr/share/mysql 
# and read more at https://mariadb.com/kb/en/galera-cluster/ 

[galera] 
# Mandatory settings 
#wsrep_on = ON 
#wsrep_provider = 
#wsrep_cluster_address = 
#binlog_format = row 
#default_storage_engine = InnoDB 
#innodb_autoinc_lock_mode = 2 

# Allow server to accept connections on all interfaces. 
#bind-address = 0.0.0.0 

# Optional settings 
#wsrep_slave_threads = 1 
#innodb_flush_log_at_trx_commit = 0 


[mysqld] 
binlog_format=ROW 
default-storage-engine=innodb 
innodb_autoinc_lock_mode=2 
bind-address=0.0.0.0 

# Galera Provider Configuration 
wsrep_on=ON 
wsrep_provider=/usr/lib/galera/libgalera_smm.so 

# Galera Cluster Configuration 
wsrep_cluster_name="CQ_CLUSTER" 
wsrep_cluster_address="gcomm://192.168.200.139,192.168.200.140" 

# Galera Synchronization Configuration 
wsrep_sst_method=rsync 

# Galera Node Configuration 
wsrep_node_address="192.168.200.140" 
wsrep_node_name="db2"

3) Configurație finală

  • Copiați fișierul de configurare în /home/superadmin pe ambele noduri

Alt Image

  • Serviciile Mariadb se opresc pe ambele noduri

Alt Image

  • Copiați fișierul de configurare pe fiecare nod
sudo cp /home/superadmin/60-galera.cnf /etc/mysql/mariadb.conf.d/ 

Verificarea clusterului

  1. Verificarea configurațiilor

Verificați configurația în fișier (pe fiecare nod)

Alt Image

Alt Image

Inițializați noul cluster (pe db1)

sudo galera_new_cluster

Alt Image

Porniți serviciul pe db2 (care este deja configurat):

sudo systemctl start mariadb.service

Verificați că declarația de bază de date a fost primită.

Alt Image

2) Verificare GUI

Verificați replicarea: la accesarea interfeței web, configurațiile trebuie să fie identice pentru cele două mașini CYBERQUEST.

db1:

Alt Image

db2:

Alt Image

Puteți observa configurația identică a grupurilor de instrumente: Events, Users, Asset Dashboards.

Această configurare poate fi folosită și în scopuri de preluare în caz de eșec. Atunci când un server de bază de date nu este disponibil, celălalt are o configurație identică.

HAProxy failover configuration

CYBERQUEST vine cu HAProxy preinstalat. Pentru a putea asigura înaltă disponibilitate, scenarii de redundanță geografică și configurații de failover, trebuie să efectuați setări suplimentare.

Scenariu de failover / balansor de sarcini:

1) Editați /etc/haproxy/haproxy.cfg fișierul trebuie editat pentru a include configurația de failover / balansor de sarcini (pe două noduri) pentru a o configura.

global
  log 127.0.0.1 local0 notice
  maxconn 10000
  user haproxy
  group haproxy
defaults
  timeout connect 5s
  timeout client 100s
  timeout server 100s
listen rabbitmq
  bind :5673
  mode tcp
  balance roundrobin
  server rabbitmq-01 <node1>:5672 check inter 5s rise 2 fall 3
  server rabbitmq-02 <node2>:5672 check inter 5s rise 2 fall 3
# optional, for proxying management site
frontend front_rabbitmq_management
  bind :15672
  default_backend back_rabbitmq_management
backend back_rabbitmq_management
  balance source
  server rabbitmq-mgmt-01 10.25.1.101:15673 check
  server rabbitmq-mgmt-02 10.25.1.102:15673 check
# optional, for monitoring
# listen stats :9000
#  mode http
#  stats enable
#  stats hide-version
# stats realm Haproxy\ Statistics
#  stats uri /
#  stats auth haproxy:haproxy

Configurați serviciile CQ pentru a utiliza punctul final de failover (consultați parametrii de configurare ai fiecărui serviciu).