sql >> Database teknologi >  >> RDS >> MariaDB

Implementering af en meget tilgængelig Nextcloud med MySQL Galera Cluster og GlusterFS

Nextcloud er en open source filsynkroniserings- og deleapplikation, der tilbyder gratis, sikker og let tilgængelig cloud-fillagring samt en række værktøjer, der udvider dets funktionssæt. Det minder meget om den populære Dropbox, iCloud og Google Drive, men i modsætning til Dropbox tilbyder Nextcloud ikke hosting af fillager udenfor det lokale marked.

I dette blogindlæg vil vi implementere en høj-tilgængelig opsætning til vores private "Dropbox" infrastruktur ved hjælp af Nextcloud, GlusterFS, Percona XtraDB Cluster (MySQL Galera Cluster), ProxySQL med ClusterControl som automatiseringsværktøjet til at styre og overvåge databasen og load balancer-lagene.

Bemærk:Du kan også bruge MariaDB Cluster, som bruger det samme underliggende replikeringsbibliotek som i Percona XtraDB Cluster. Fra et load balancer-perspektiv opfører ProxySQL sig på samme måde som MaxScale, idet den kan forstå SQL-trafikken og har finmasket kontrol over, hvordan trafikken dirigeres.

Databasearkitektur til Nexcloud

I dette blogindlæg brugte vi i alt 6 noder.

  • 2 x proxyservere 
  • 3 x database + applikationsservere
  • 1 x controllerserver (ClusterControl)

Følgende diagram illustrerer vores endelige opsætning:

For Percona XtraDB Cluster kræves et minimum af 3 noder for en solid multi-master replikering. Nextcloud-applikationer er co-placeret i databaseserverne, så GlusterFS skal også konfigureres på disse værter.

Load balancer tier består af 2 noder til redundansformål. Vi vil bruge ClusterControl til at implementere databaseniveauet og load balancer-lagene. Alle servere kører på CentOS 7 med følgende /etc/hosts-definition på hver node:

192.168.0.21 nextcloud1 db1

192.168.0.22 nextcloud2 db2

192.168.0.23 nextcloud3 db3

192.168.0.10 vip db

192.168.0.11 proxy1 lb1 proxysql1

192.168.0.12 proxy2 lb2 proxysql2

Bemærk, at GlusterFS og MySQL er meget intensive processer. Hvis du følger denne opsætning (GlusterFS og MySQL findes på en enkelt server), skal du sikre dig, at du har anstændige hardwarespecifikationer til serverne.

Nextcloud-databaseimplementering

Vi starter med databaseimplementering for vores tre-node Percona XtraDB Cluster ved hjælp af ClusterControl. Installer ClusterControl, og opsæt derefter adgangskodefri SSH til alle noder, der skal administreres af ClusterControl (3 PXC + 2 proxyer). På ClusterControl-noden skal du gøre:

$ whoami

root

$ ssh-copy-id 192.168.0.11

$ ssh-copy-id 192.168.0.12

$ ssh-copy-id 192.168.0.21

$ ssh-copy-id 192.168.0.22

$ ssh-copy-id 192.168.0.23

**Indtast root-adgangskoden for den respektive vært, når du bliver bedt om det.

Åbn en webbrowser og gå til https://{ClusterControl-IP-address}/clustercontrol og opret en superbruger. Gå derefter til Deploy -> MySQL Galera. Følg implementeringsguiden i overensstemmelse hermed. På det andet trin 'Definer MySQL-servere' skal du vælge Percona XtraDB 5.7 og angive IP-adressen for hver databasenode. Sørg for, at du får et grønt flueben efter indtastning af databasenodens detaljer, som vist nedenfor:

Klik på "Deploy" for at starte installationen. Databaseklyngen vil være klar om 15~20 minutter. Du kan følge implementeringsforløbet under Aktivitet -> Jobs -> Opret klynge -> Fuld jobdetaljer. Klyngen vil blive vist under Databaseklyngens dashboard, når den er implementeret.

Vi kan nu fortsætte til implementering af databasebelastningsbalancer.

Implementering af Nextcloud Database Load Balancer

Nextcloud anbefales at køre på en enkelt-skriver opsætning, hvor skrivninger vil blive behandlet af en master ad gangen, og læsningerne kan distribueres til andre noder. Vi kan bruge ProxySQL 2.0 til at opnå denne konfiguration, da den kan dirigere skriveforespørgslerne til en enkelt master.

For at implementere en ProxySQL skal du klikke på Cluster Actions> Add Load Balancer> ProxySQL> Implementer ProxySQL. Indtast de nødvendige oplysninger som fremhævet med de røde pile:

Udfyld alle nødvendige detaljer som fremhævet af pilene ovenfor. Serveradressen er lb1-serveren, 192.168.0.11. Længere nede angiver vi ProxySQL admin og overvågningsbrugeres adgangskode. Inkluder derefter alle MySQL-servere i belastningsbalanceringssættet, og vælg derefter "Nej" i afsnittet Implicitte transaktioner. Klik på "Deploy ProxySQL" for at starte implementeringen.

Gentag de samme trin som ovenfor for den sekundære load balancer, lb2 (men skift "Serveradressen" til lb2s IP-adresse). Ellers ville vi ikke have nogen redundans i dette lag.

Vores ProxySQL-noder er nu installeret og konfigureret med to værtsgrupper til Galera Cluster. En for single-master-gruppen (værtsgruppe 10), hvor alle forbindelser vil blive videresendt til én Galera-node (dette er nyttigt for at forhindre multi-master-deadlocks) og multi-master-gruppen (værtsgruppe 20) for alle skrivebeskyttede arbejdsbelastninger, som vil være afbalanceret til alle backend MySQL-servere.

Dernæst skal vi implementere en virtuel IP-adresse for at levere et enkelt slutpunkt til vores ProxySQL-noder, så din applikation ikke behøver at definere to forskellige ProxySQL-værter. Dette vil også give automatiske failover-funktioner, fordi den virtuelle IP-adresse vil blive overtaget af backup ProxySQL-knuden, hvis noget går galt med den primære ProxySQL-knude.

Gå til ClusterControl -> Administrer -> Load Balancers -> Keepalived -> Implementer Keepalived. Vælg "ProxySQL" som load balancer-type og vælg to forskellige ProxySQL-servere fra rullemenuen. Angiv derefter den virtuelle IP-adresse samt netværksgrænsefladen, som den vil lytte til, som vist i følgende eksempel:

Når implementeringen er fuldført, bør du se følgende detaljer på klyngens oversigtslinje:

Til sidst skal du oprette en ny database til vores applikation ved at gå til ClusterControl -> Administrer -> Skemaer og brugere -> Opret database og angiv "nextcloud". ClusterControl vil oprette denne database på hver Galera-knude. Vores belastningsbalancer er nu færdig.

GlusterFS-implementering til Nextcloud

Følgende trin skal udføres på nextcloud1, nextcloud2, nextcloud3, medmindre andet er angivet.

Trin et

Det anbefales at have en separat denne til GlusterFS-lagring, så vi vil tilføje yderligere disk under /dev/sdb og oprette en ny partition:

$ fdisk /dev/sdb

Følg guiden til oprettelse af fdisk-partitioner ved at trykke på følgende tast:

n > p > Enter > Enter > Enter > w

Trin to

Bekræft, om /dev/sdb1 er blevet oprettet:

$ fdisk -l /dev/sdb1

Disk /dev/sdb1: 8588 MB, 8588886016 bytes, 16775168 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Trin tre

Formater partitionen med XFS:

$ mkfs.xfs /dev/sdb1

Trin fire

Monter partitionen som /storage/brick:

$ mkdir /glusterfs

$ mount /dev/sdb1 /glusterfs

Bekræft, at alle noder har følgende layout:

$ lsblk

NAME   MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sda      8:0 0 40G  0 disk

└─sda1   8:1 0 40G  0 part /

sdb      8:16 0   8G 0 disk

└─sdb1   8:17 0   8G 0 part /glusterfs

Trin fem

Opret en undermappe kaldet mursten under /glusterfs:

$ mkdir /glusterfs/brick

Trin seks

For applikationsredundans kan vi bruge GlusterFS til filreplikering mellem værterne. Installer først GlusterFS-lageret til CentOS:

$ yum install centos-release-gluster -y

$ yum install epel-release -y

Trin syv

Installer GlusterFS-server

$ yum install glusterfs-server -y

Trin otte

Aktiver og start gluster daemon:

$ systemctl enable glusterd

$ systemctl start glusterd

Trin ni

På nextcloud1 skal du undersøge de andre noder:

(nextcloud1)$ gluster peer probe 192.168.0.22

(nextcloud1)$ gluster peer probe 192.168.0.23

Du kan bekræfte peer-statussen med følgende kommando:

(nextcloud1)$ gluster peer status

Number of Peers: 2



Hostname: 192.168.0.22

Uuid: f9d2928a-6b64-455a-9e0e-654a1ebbc320

State: Peer in Cluster (Connected)



Hostname: 192.168.0.23

Uuid: 100b7778-459d-4c48-9ea8-bb8fe33d9493

State: Peer in Cluster (Connected)

Trin ti

På nextcloud1 skal du oprette en replikeret volumen på sonderede noder:

(nextcloud1)$ gluster volume create rep-volume replica 3 192.168.0.21:/glusterfs/brick 192.168.0.22:/glusterfs/brick 192.168.0.23:/glusterfs/brick

volume create: rep-volume: success: please start the volume to access data

Trin elleve

Start den replikerede lydstyrke på nextcloud1:

(nextcloud1)$ gluster volume start rep-volume

volume start: rep-volume: success

Bekræft, at den replikerede mængde og processer er online:

$ gluster volume status

Status of volume: rep-volume

Gluster process                             TCP Port RDMA Port Online Pid

------------------------------------------------------------------------------

Brick 192.168.0.21:/glusterfs/brick         49152 0 Y 32570

Brick 192.168.0.22:/glusterfs/brick         49152 0 Y 27175

Brick 192.168.0.23:/glusterfs/brick         49152 0 Y 25799

Self-heal Daemon on localhost               N/A N/A Y 32591

Self-heal Daemon on 192.168.0.22            N/A N/A Y 27196

Self-heal Daemon on 192.168.0.23            N/A N/A Y 25820



Task Status of Volume rep-volume

------------------------------------------------------------------------------

There are no active volume tasks

Trin tolv

Monter det replikerede volumen på /var/www/html. Opret mappen:

$ mkdir -p /var/www/html

Trettende trin

13) Tilføj følgende linje i /etc/fstab for at tillade automatisk montering:

/dev/sdb1 /glusterfs xfs defaults,defaults 0 0

localhost:/rep-volume /var/www/html   glusterfs defaults,_netdev 0 0

Trin fjorten

Monter GlusterFS til /var/www/html:

$ mount -a

Og bekræft med:

$ mount | grep gluster

/dev/sdb1 on /glusterfs type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

localhost:/rep-volume on /var/www/html type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)

Det replikerede volumen er nu klar og monteret i hver knude. Vi kan nu fortsætte med at implementere applikationen.

Nextcloud Application Deployment

Følgende trin skal udføres på nextcloud1, nextcloud2 og nextcloud3, medmindre andet er angivet.

Nextcloud kræver PHP 7.2 og nyere, og for CentOS-distribution skal vi aktivere en række arkiver som EPEL og Remi for at forenkle installationsprocessen.

Trin et

Hvis SELinux er aktiveret, deaktiver det først:

$ setenforce 0

$ sed -i 's/^SELINUX=.*/SELINUX=permissive/g' /etc/selinux/config

Du kan også køre Nextcloud med SELinux aktiveret ved at følge denne vejledning.

Trin to

Installer Nextcloud-krav og aktiver Remi-lager til PHP 7.2:

$ yum install -y epel-release yum-utils unzip curl wget bash-completion policycoreutils-python mlocate bzip2

$ yum install -y http://rpms.remirepo.net/enterprise/remi-release-7.rpm

$ yum-config-manager --enable remi-php72

Trin tre

Installer Nextcloud-afhængigheder, for det meste Apache- og PHP 7.2-relaterede pakker:

$ yum install -y httpd php72-php php72-php-gd php72-php-intl php72-php-mbstring php72-php-mysqlnd php72-php-opcache php72-php-pecl-redis php72-php-pecl-apcu php72-php-pecl-imagick php72-php-xml php72-php-pecl-zip

Trin fire

Aktiver Apache og start den op:

$ systemctl enable httpd.service

$ systemctl start httpd.service

Trin fem

Lav et symbolsk link til PHP for at bruge PHP 7.2 binær:

$ ln -sf /bin/php72 /bin/php

Trin seks

På nextcloud1, download Nextcloud Server herfra og udpak den:

$ wget https://download.nextcloud.com/server/releases/nextcloud-17.0.0.zip

$ unzip nextcloud*

Trin syv

På nextcloud1 skal du kopiere mappen til /var/www/html og tildele korrekt ejerskab:

$ cp -Rf nextcloud /var/www/html

$ chown -Rf apache:apache /var/www/html

**Bemærk, at kopieringsprocessen til /var/www/html vil tage noget tid på grund af GlusterFS-volumenreplikering.

Trin otte

Før vi fortsætter med at åbne installationsguiden, skal vi deaktivere pxc_strict_mode-variablen til andet end "ENFORCING" (standardværdien). Dette skyldes, at Nextcloud-databaseimporten vil have et antal tabeller uden defineret primærnøgle, som ikke anbefales at køre på Galera Cluster. Dette er forklaret yderligere detaljer under Tuning sektionen længere nede.

For at ændre konfigurationen med ClusterControl skal du blot gå til Administrer -> Konfigurationer -> Skift/indstil parametre:

Vælg alle databaseforekomster fra listen, og indtast:

  • Gruppe:MYSQLD
  • Parameter:pxc_strict_mode
  • Ny værdi:TILLADENDE

ClusterControl udfører de nødvendige ændringer på hver databasenode automatisk. Hvis værdien kan ændres under kørsel, træder den i kraft med det samme. ClusterControl konfigurerer også værdien inde i MySQL-konfigurationsfilen for persistens. Du bør se følgende resultat:

Trin ni

Nu er vi klar til at konfigurere vores Nextcloud-installation. Åbn browseren og gå til nextcloud1s HTTP-server på http://192.168.0.21/nextcloud/, og du vil blive præsenteret for følgende konfigurationsguide:

Konfigurer sektionen "Lagring og database" med følgende værdi:

  • Datamappe:/var/www/html/nextcloud/data
  • Konfigurer databasen:MySQL/MariaDB
  • Brugernavn:nextcloud
  • Adgangskode:(adgangskoden til brugeren nextcloud)
  • Database:nextcloud
  • Vært:192.168.0.10:6603 (Den virtuelle IP-adresse med ProxySQL-port)

Klik på "Afslut opsætning" for at starte konfigurationsprocessen. Vent, indtil det er færdigt, og du vil blive omdirigeret til Nextcloud dashboard for brugeren "admin". Installationen er nu færdig. Næste afsnit giver nogle tuning tips til at køre effektivt med Galera Cluster.

Nextcloud Database Tuning

Primær nøgle

At have en primær nøgle på hver tabel er afgørende for Galera Cluster skrivesæt-replikering. For et relativt stort bord uden primær nøgle vil en stor opdatering eller sletning blokere din klynge fuldstændigt i meget lang tid. For at undgå særheder og kanttilfælde skal du blot sørge for, at alle tabeller bruger InnoDB-lagringsmotor med en eksplicit primærnøgle (entydig nøgle tæller ikke).

Standardinstallationen af ​​Nextcloud vil skabe en masse tabeller under den angivne database, og nogle af dem overholder ikke denne regel. For at kontrollere, om tabellerne er kompatible med Galera, kan vi køre følgende sætning:

mysql> SELECT DISTINCT CONCAT(t.table_schema,'.',t.table_name) as tbl, t.engine, IF(ISNULL(c.constraint_name),'NOPK','') AS nopk, IF(s.index_type = 'FULLTEXT','FULLTEXT','') as ftidx, IF(s.index_type = 'SPATIAL','SPATIAL','') as gisidx FROM information_schema.tables AS t LEFT JOIN information_schema.key_column_usage AS c ON (t.table_schema = c.constraint_schema AND t.table_name = c.table_name AND c.constraint_name = 'PRIMARY') LEFT JOIN information_schema.statistics AS s ON (t.table_schema = s.table_schema AND t.table_name = s.table_name AND s.index_type IN ('FULLTEXT','SPATIAL'))   WHERE t.table_schema NOT IN ('information_schema','performance_schema','mysql') AND t.table_type = 'BASE TABLE' AND (t.engine <> 'InnoDB' OR c.constraint_name IS NULL OR s.index_type IN ('FULLTEXT','SPATIAL')) ORDER BY t.table_schema,t.table_name;

+---------------------------------------+--------+------+-------+--------+

| tbl                                   | engine | nopk | ftidx | gisidx |

+---------------------------------------+--------+------+-------+--------+

| nextcloud.oc_collres_accesscache      | InnoDB | NOPK | | |

| nextcloud.oc_collres_resources        | InnoDB | NOPK | | |

| nextcloud.oc_comments_read_markers    | InnoDB | NOPK | | |

| nextcloud.oc_federated_reshares       | InnoDB | NOPK | | |

| nextcloud.oc_filecache_extended       | InnoDB | NOPK | | |

| nextcloud.oc_notifications_pushtokens | InnoDB | NOPK |       | |

| nextcloud.oc_systemtag_object_mapping | InnoDB | NOPK |       | |

+---------------------------------------+--------+------+-------+--------+

Ovenstående output viser, at der er 7 tabeller, der ikke har en primær nøgle defineret. For at rette op på ovenstående skal du blot tilføje en primær nøgle med automatisk stigningskolonne. Kør følgende kommandoer på en af ​​databaseserverne, for eksempel nexcloud1:

(nextcloud1)$ mysql -uroot -p

mysql> ALTER TABLE nextcloud.oc_collres_accesscache ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;

mysql> ALTER TABLE nextcloud.oc_collres_resources ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;

mysql> ALTER TABLE nextcloud.oc_comments_read_markers ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;

mysql> ALTER TABLE nextcloud.oc_federated_reshares ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;

mysql> ALTER TABLE nextcloud.oc_filecache_extended ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;

mysql> ALTER TABLE nextcloud.oc_notifications_pushtokens ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;

mysql> ALTER TABLE nextcloud.oc_systemtag_object_mapping ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;

Når ovenstående ændringer er blevet anvendt, kan vi genkonfigurere pxc_strict_mode til den anbefalede værdi, "ENFORCING". Gentag trin #8 under afsnittet "Application Deployment" med den tilsvarende værdi.

LÆS-KOMMITTERET isolationsniveau

Det anbefalede transaktionsisoleringsniveau som anbefalet af Nextcloud er at bruge READ-COMMITTED, mens Galera Cluster er standard til et strengere REPEATABLE-READ isolationsniveau. Brug af READ-COMMITTED kan undgå datatab under scenarier med høj belastning (f.eks. ved at bruge synkroniseringsklienten med mange klienter/brugere og mange parallelle operationer).

For at ændre transaktionsniveauet skal du gå til ClusterControl -> Administrer -> Konfigurationer -> Skift/indstil parameter og angiv følgende:

Klik på "Fortsæt", og ClusterControl vil anvende konfigurationsændringerne med det samme. Der kræves ingen genstart af databasen.

Multi-Instance Nextcloud

Da vi udførte installationen på nextcloud1, da vi fik adgang til URL'en, tilføjes denne IP-adresse automatisk til variabelen 'trusted_domains' inde i Nextcloud. Når du forsøgte at få adgang til andre servere, f.eks. den sekundære server, http://192.168.0.22/nextcloud, ville du se en fejl om, at denne vært ikke er autoriseret og skal tilføjes til variablen Trusted_domain.

Derfor skal du tilføje alle værternes IP-adresser under "trusted_domain" array inde i /var/www/html/nextcloud/config/config.php, som eksempel nedenfor:

  'trusted_domains' =>

  array (

    0 => '192.168.0.21',

    1 => '192.168.0.22',

    2 => '192.168.0.23'

  ),

Ovenstående konfiguration tillader brugere at få adgang til alle tre applikationsservere via følgende URL'er:

  • http://192.168.0.21/nextcloud (nextcloud1)
  • http://192.168.0.22/nextcloud (nextcloud2)
  • http://192.168.0.23/nextcloud (nextcloud3)

Bemærk:Du kan tilføje et belastningsbalanceringsniveau oven på disse tre Nextcloud-forekomster for at opnå høj tilgængelighed for applikationsniveauet ved at bruge HTTP omvendte proxyer, der er tilgængelige på markedet som HAProxy eller nginx. Det er uden for dette blogindlægs omfang.

Brug af Redis til fillåsning

Nextclouds Transactional File Locking-mekanisme låser filer for at undgå filkorruption under normal drift. Det anbefales at installere Redis for at tage sig af transaktionsfillåsning (dette er aktiveret som standard), hvilket vil aflaste databaseklyngen fra at håndtere dette tunge job.

For at installere Redis skal du blot:

$ yum install -y redis

$ systemctl enable redis.service

$ systemctl start redis.service

Tilføj følgende linjer i /var/www/html/nextcloud/config/config.php:

  'filelocking.enabled' => true,

  'memcache.locking' => '\OC\Memcache\Redis',

  'redis' => array(

     'host' => '192.168.0.21',

     'port' => 6379,

     'timeout' => 0.0,

   ),

For flere detaljer, tjek denne dokumentation, Transactional File Locking.

Konklusion

Nextcloud kan konfigureres til at være en skalerbar og yderst tilgængelig fil-hosting-tjeneste for at imødekomme dine private fildelingskrav. I denne blog viste vi, hvordan du kan bringe redundans i Nextcloud, filsystem og databaselag.


  1. Indsættelse af DEFAULT-værdi i en kolonne, når en parameter er NULL

  2. Hvordan får man script af SQL Server-data?

  3. Sådan fungerer DB_NAME() i SQL Server

  4. Sådan fungerer Access 2019, og hvordan du arbejder med det