O implementare Nextcloud cu disponibilitate ridicată cu Galera este un sistem coordonat, nu doar trei servere de baze de date. De asemenea, aveți nevoie de noduri de aplicație Nextcloud redundante, un strat fișier-date partajat și durabil, cache distribuit și blocare a fișierelor, echilibrare a încărcării, monitorizare și copii de rezervă testate. Galera poate menține serviciul bazei de date disponibil după o eroare a nodului bazei de date atunci când cvorumul este prezent, dar nu poate face ca celelalte componente să fie disponibile pentru dvs.
Acest ghid utilizează un design Linux neutru față de furnizori cu MariaDB Galera și un proxy invers sau un echilibrator de încărcare. Numele pachetelor, numele serviciilor, căile furnizorilor Galera, comenzile bootstrap și integrările proxy pentru verificarea stării de funcționare variază în funcție de distribuție și de versiunea MariaDB. Confirmați-le cu documentația exactă a versiunii înainte de implementare. Manualul actual de administrare stabilă al Nextcloud listează PostgreSQL și MariaDB ca motoare de baze de date recomandate și avertizează că versiunile acceptate variază; verificați cerințele de sistem Nextcloud pentru versiunea pe care intenționați să o rulați. Acest articol a fost verificat în raport cu manualul stabil Nextcloud 35 pe 6 octombrie 2026.
Galera este o replicare sincronă, multi-primară, pentru serverele compatibile cu MySQL. O tranzacție este certificată în întregul cluster, ceea ce ajută la menținerea consecvenței membrilor, dar adaugă costuri suplimentare de coordonare, iar tranzacțiile care intră în conflict pot fi respinse. Adăugarea de noduri ale bazei de date nu multiplică automat debitul Nextcloud. Ghidul pentru dezvoltatori Nextcloud menționează că clusterele au un cost de performanță și că baza de date și stocarea rămân resurse partajate critice.
| Alegerea designului | Potrivire bună | Compromisul principal |
|---|---|---|
| Un server MariaDB sau PostgreSQL | Implementări mici care necesită cele mai simple operațiuni | Întreținerea sau defecțiunea bazei de date poate întrerupe serviciul |
| MariaDB cu Galera | Echipe care au nevoie de redundanță a nodurilor bazei de date și pot opera proceduri de cvorum, rețea, proxy și recuperare | Mai multe componente mobile, coordonare a scrierii, gestionarea conflictelor și complexitate a recuperării |
| Două noduri ale bazei de date plus un arbitru | Site-uri cu exact două gazde de baze de date, dar un domeniu separat de eșec pentru un vot de cvorum | Arbitrul ajută la stabilirea cvorumului; nu stochează date și nu înlocuiește o a treia copie a bazei de date. |
| Galera în spatele unui proxy bazat pe baze de date | Implementări care necesită un punct final de conexiune stabil și o rutare controlată | Verificările de sănătate ale proxy-ului și regulile de rutare devin un alt serviciu de operat |
Pentru o instalare nouă, un cluster Galera cu trei noduri de date pe gazde independente este un punct de plecare obișnuit atunci când echipa operațională îl poate susține. Cvorumul Galera necesită o majoritate: un cluster cu două noduri nu poate face automat o eroare în siguranță după pierderea unui membru. Trei noduri pot tolera un membru indisponibil, în timp ce celelalte două rămân conectate. Plasați nodurile în domenii de eroare acolo unde este practic, dar nu întindeți replicarea sincronă pe legături cu latență ridicată fără testare. Pentru un mediu cu complexitate mai mică, preferați o bază de date unică acceptată, plus un plan de backup și recuperare bine testat.
Notează erorile pe care intenționezi să le reușești: un proces web, o gazdă web, o gazdă a bazei de date, un echilibrator de sarcină, un punct final de stocare, o cale de rețea sau un site complet. Stabilește obiective de recuperare pentru fiecare. Un design cu trei noduri de bază de date și un echilibrator de sarcină nu este complet redundant. Nici un cluster de aplicații ale cărui fișiere de utilizator există doar pe discul local al unui server web.
Folosește o versiune Nextcloud consistentă, un runtime PHP, un set de aplicații și o configurație pe fiecare nod de aplicație. Selectează versiuni MariaDB și Galera care sunt compatibile între ele și acceptate de versiunea Nextcloud aleasă. Cerințele bazei de date Nextcloud includ InnoDB, izolarea tranzacțiilor READ COMMITTED și dezactivarea înregistrării binare sau a formatului ROW; nu copiază valorile de reglare dintr-o versiune diferită fără a verifica cerințele actuale.
Creați nume DNS private sau adrese stabile pentru fiecare membru al bazei de date, fiecare nod web, serviciul de cache, spațiul de stocare partajat și endpoint-ul web public. Rezervați un endpoint de bază de date stabil separat pentru nodurile PHP Nextcloud. Păstrați aplicațiile, replicarea și traficul public pe căi de rețea separate corespunzător, acolo unde infrastructura permite. Un nume de nod trebuie să fie unic, iar fiecare membru al clusterului trebuie să rezolve consecvent colegii Galera.
Instalați MariaDB Server și furnizorul Galera utilizând depozitul furnizorului recomandat pentru sistemul dvs. de operare. Păstrați același server principal și aceeași familie de furnizori pe toți membrii. Nu combinați pachete comunitare arbitrare cu o bibliotecă de furnizori descărcată separat. Înainte de a continua, confirmați calea de actualizare acceptată, metoda SST, unitatea de service și directorul de includere a configurației pentru acel set de pachete.
Setați serverul să utilizeze InnoDB și nivelul de izolare a tranzacțiilor READ COMMITTED. Folosiți înregistrarea binară ROW dacă este activată înregistrarea binară. Verificați valorile efective după repornire în loc să presupuneți că a fost inclus un fișier de configurare. Nextcloud documentează aceste cerințe în ghidul său de configurare a bazei de date și în cerințele de sistem .
Folosește referința de configurare a furnizorului tău pentru a seta numele clusterului, lista de adrese peer, numele și adresa unice ale fiecărui nod, biblioteca furnizorului și metoda de transfer a instantaneelor de stare (SST). SST este procesul care furnizează unui nod care se alătură starea bazei de date. O configurație tipică a clusterului MariaDB conține opțiuni din această familie:
[mariadb]
wsrep_on=ON
wsrep_cluster_name=nextcloud-cluster
wsrep_cluster_address=gcomm://db1.example.net,db2.example.net,db3.example.net
wsrep_node_name=db1
wsrep_node_address=db1.example.net
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
transaction_isolation=READ-COMMITTEDModificați valorile specifice nodului pe fiecare server. Căile furnizorului și metodele SST acceptate depind de pachetele instalate; utilizați metoda și acreditările documentate pentru versiunea dvs. Protejați acreditările SST, certificatele și parolele bazei de date ca secrete. Nu utilizați niciodată o adresă de cluster goală ca setare permanentă: MariaDB documentează faptul că poate determina un server să pornească un cluster nou în loc să se reunească la cel existent.
Permiteți nivelului web să ajungă doar la punctul final al serviciului bazei de date și permiteți membrilor bazei de date să se conecteze între ei pe porturile de replicare și transfer de stare Galera, necesare furnizorului și metodei SST alese. Implementările Galera obișnuite utilizează TCP și, în funcție de setările furnizorului, UDP pentru comunicarea de grup; valorile implicite relevante includ adesea 4567 pentru replicare, 4568 pentru transfer incremental de stare și 4444 pentru transferul instantaneelor de stare. Tratați acestea ca pe o listă de verificare pentru a verifica în funcție de versiunea și configurația dvs., nu ca pe un motiv pentru a deschide fiecare port pe scară largă. Păstrați portul SQL privat și refuzați accesul public.
Inițializați clusterul o singură dată folosind procedura de bootstrap documentată de pachetul MariaDB al distribuției dvs. După confirmarea faptului că primul membru formează componenta principală, porniți membrii rămași normal, astfel încât să se alăture acestuia și să primească starea prin IST sau SST. IST transferă seturile de scriere lipsă atunci când sunt disponibile; SST efectuează un transfer complet de stare. Nu bootați fiecare gazdă independent și nu tratați o repornire ca o acțiune de bootstrap.
Executați această interogare pe fiecare membru al bazei de date după ce se alătură:
SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
'wsrep_connected','wsrep_local_state_comment');Confirmați că fiecare nod este conectat și pregătit, aparține componentei primare, raportează dimensiunea așteptată a clusterului și a atins o stare sincronizată. MariaDB explică acești indicatori în ghidul său de monitorizare Galera .
Creați baza de date cu setul de caractere și colaționarea necesare în ghidul de instalare Nextcloud curent. Creați un utilizator dedicat bazei de date, restricționat la rețeaua aplicației, și acordați doar privilegiile necesare pentru configurarea și funcționarea normală a Nextcloud. Utilizați TLS pentru conexiunile care traversează gazde sau segmente de rețea neîncredute și validați certificatele acolo unde implementarea dvs. o acceptă. Nu introduceți acreditări root în config.php.
Instalați aceeași versiune de cod Nextcloud, extensii PHP, aplicații activate și configurație de server pe fiecare nod web. Configurați un endpoint de bază de date partajat, nu gazde de bază de date diferite în fișierele per nod. Toate nodurile trebuie să utilizeze același ID de instanță, secret, săruri, politică de domeniu de încredere și alte setări la nivel de instanță. Stocați configurația într-un proces de implementare partajat controlat sau distribuiți-o în siguranță, astfel încât actualizările să rămână identice.
Stratul fișier-date al utilizatorului trebuie să fie, de asemenea, comun nodurilor aplicației. Utilizați un sistem de fișiere partajat acceptat sau un design de stocare a obiectelor primare acceptat care să corespundă versiunii Nextcloud și cerințelor operaționale. Datele utilizatorului doar locale de pe o gazdă web elimină failover-ul: o solicitare direcționată către o altă gazdă nu ar vedea aceleași fișiere. Păstrați codul aplicației și căile de date inscriptibile distincte și validați semantica blocării fișierelor și a stocării înainte de producție.
Nextcloud își creează în mod normal setările bazei de date în timpul instalării. Odată ce endpoint-ul bazei de date și spațiul de stocare partajat sunt gata, verificați dacă fiecare nod rezolvă aceleași valori. Un fragment de configurare reprezentativ arată astfel; păstrați acreditările reale într-un flux de lucru protejat pentru gestionarea secretelor și nu lipiți acest fragment peste o configurație de producție existentă:
'dbtype' => 'mysql',
'dbname' => 'nextcloud',
'dbhost' => 'db-vip.internal:3306',
'dbuser' => 'nextcloud',
'dbpassword' => 'REPLACE_WITH_SECRET',
'datadirectory' => '/srv/nextcloud-data',
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'redis.internal',
'port' => 6379,
'password' => 'REPLACE_WITH_SECRET',
],Adaptați backend-ul cache și directorul de date la opțiunile acceptate pentru versiunea Nextcloud. Instalați și configurați extensiile PHP necesare, acolo unde este cazul.
Folosiți APCu pentru cache-ul local per gazdă, dacă este cazul, și un serviciu partajat compatibil cu Redis, cum ar fi Redis sau Valkey, pentru cache-ul distribuit și blocarea fișierelor tranzacționale. Toate nodurile web trebuie să se refere la același serviciu de cache sau la același cluster de cache acceptat, nu la localhost. Nextcloud documentează configurația clusterului Redis pentru configurațiile în cluster și notează că blocarea fișierelor tranzacționale se bazează în mod implicit pe baza de date. Securizați memoria cache cu restricții de rețea, autentificare și TLS, acolo unde este cazul; disponibilitatea memoriei cache și comportamentul de failover necesită propriul design.
Indică Nextcloud către un endpoint stabil furnizat de un proxy de bază de date sau de un alt strat de rutare acceptat. Proxy-ul ar trebui să înceteze să trimită conexiuni noi către noduri care nu se află în componenta principală, nu sunt sincronizate sau nu sunt pregătite. O verificare de bază a portului TCP dovedește doar că un socket acceptă conexiuni; nu dovedește că Galera poate servi în siguranță aplicația. Examinează comportamentul verificării stării de funcționare și modurile de eșec ale proxy-ului ales. Dacă folosești un echilibrator de încărcare TCP simplu, asociază-l cu o verificare fiabilă a pregătirii Galera și reguli de rutare conservatoare.
Nu adăugați divizarea citirii/scrierii sau rutarea round-robin în mod superficial. Manualul pentru dezvoltatori Nextcloud descrie suportul pentru conexiuni primare/replică și avertizează că rutarea citirilor într-un cluster poate crea probleme de consistență dacă datele nu s-au propagat sau dacă un proxy nu poate păstra citirile tranzacționale pe nodul corect. Începeți cu un endpoint stabil cu capacitate de scriere, măsurați-l și introduceți rutare specializată numai atunci când înțelegeți implicațiile privind consistența și suportul.
Plasați cel puțin două noduri web în spatele unui echilibrator de încărcare și utilizați un mecanism de disponibilitate separat pentru echilibratorul de încărcare în sine, cum ar fi un serviciu gestionat, o pereche redundantă sau un design testat de IP virtual. Configurați terminarea TLS, dimensiunea cererii și comportamentul de timeout, precum și cerințele de sesiune remanentă în funcție de implementarea dvs. Verificați documentația proxy-ului invers Nextcloud și setați trusted_proxiesla adresele proxy reale; încrederea în intervalele arbitrare de clienți slăbește gestionarea IP-urilor clientului.
Testați mai întâi actualizările pe o copie de testare cu aceeași topologie. Puneți Nextcloud în modul de întreținere atunci când este necesar în procedura de actualizare, aplicați aceeași versiune a aplicației fiecărui nod și repuneți nodurile în funcțiune numai după ce verificările de sănătate trec. Pentru întreținerea de rutină a gazdei, goliți câte un nod web pe rând și confirmați că capacitatea rămasă este suficientă. Aplicați actualizările bazei de date utilizând procesul de actualizare continuă MariaDB/Galera acceptat pentru versiunile exacte implicate; nu inventați o comandă dintr-un tutorial generic.
Faceți copii de rezervă ale bazei de date și ale stratului de fișiere-date al utilizatorului utilizând o procedură documentată și consistentă în aplicație. Păstrați configurația, materialul de criptare și secretele disponibile operatorilor de recuperare autorizați. O replică Galera nu este o copie de rezervă: ștergerea accidentală și coruperea logică se pot replica la fiecare membru. Stocați copii de rezervă în afara domeniului de eroare al clusterului și efectuați repetiții regulate de restaurare. Galera documentează considerațiile privind transferul de stare și copierea de rezervă în ghidul său privind copierea de rezervă a clusterului ; validați dacă orice procedură pe care o adoptați este compatibilă cu versiunea dvs. MariaDB.
Galera este o alegere practică atunci când aveți nevoie de redundanță a nodurilor bazei de date, aveți mai multe domenii de eroare și puteți monitoriza cvorumul și practica recuperarea controlată. Poate fi o alegere nepotrivită atunci când obiectivul principal este reprezentat de operațiuni mai simple, când volumul de lucru al bazei de date este dominat de scrieri conflictuale sau când echipa nu poate răspunde în siguranță la pierderea cvorumului. În aceste cazuri, o implementare mai simplă a bazei de date cu suport, cu copii de rezervă robuste sau un serviciu de baze de date gestionate, poate produce o fiabilitate operațională mai bună.
Pentru un serviciu auto-găzduit mai mic, mai întâi faceți nodurile aplicației interschimbabile, mutați fișierele utilizatorilor într-un spațiu de stocare partajat durabil, configurați blocarea Redis partajată și testați copiile de rezervă. Adăugați Galera numai după ce măsurătorile arată că eroarea unui singur nod al bazei de date sau fereastra de întreținere reprezintă un risc inacceptabil și organizația poate menține stratul suplimentar. Testul de succes semnificativ nu este „toate cele trei servere de baze de date rulează”; ci este ca adresa URL Nextcloud să rămână utilizabilă în timpul unei pierderi planificate de nod, încărcările și descărcările să funcționeze pe nodurile web, baza de date să își păstreze cvorumul și echipa să poată restaura atât datele bazei de date, cât și cele ale fișierelor din copie de rezervă.
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
