MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Bereitstellung einer hochverfügbaren Nextcloud mit MySQL Galera Cluster und GlusterFS

Nextcloud ist eine Open-Source-Anwendung zum Synchronisieren und Teilen von Dateien, die kostenlosen, sicheren und leicht zugänglichen Cloud-Dateispeicher sowie eine Reihe von Tools bietet, die ihren Funktionsumfang erweitern. Es ist dem beliebten Dropbox, iCloud und Google Drive sehr ähnlich, aber im Gegensatz zu Dropbox bietet Nextcloud kein externes Dateispeicher-Hosting an.

In diesem Blogbeitrag stellen wir ein hochverfügbares Setup bereit für unsere private "Dropbox"-Infrastruktur mit Nextcloud, GlusterFS, Percona XtraDB Cluster (MySQL Galera Cluster), ProxySQL mit ClusterControl als Automatisierungstool zur Verwaltung und Überwachung der Datenbank- und Load-Balancer-Tiers.

Hinweis:Sie können auch MariaDB Cluster verwenden, das dieselbe zugrunde liegende Replikationsbibliothek wie in Percona XtraDB Cluster verwendet. Aus Sicht des Lastenausgleichs verhält sich ProxySQL ähnlich wie MaxScale, da es den SQL-Datenverkehr verstehen kann und eine feinkörnige Kontrolle darüber hat, wie der Datenverkehr weitergeleitet wird.

Datenbankarchitektur für Nexcloud

In diesem Blogbeitrag haben wir insgesamt 6 Knoten verwendet.

  • 2 x Proxy-Server 
  • 3 Datenbank- und Anwendungsserver
  • 1 Controller-Server (ClusterControl)

Das folgende Diagramm veranschaulicht unsere endgültige Einrichtung:

Für Percona XtraDB-Cluster sind mindestens 3 Knoten für einen Solid erforderlich Multi-Master-Replikation. Nextcloud-Anwendungen befinden sich auf den Datenbankservern, daher muss GlusterFS auch auf diesen Hosts konfiguriert werden.

Load Balancer Tier besteht aus 2 Knoten für Redundanzzwecke. Wir werden ClusterControl verwenden, um die Datenbankebene und die Lastausgleichsebenen bereitzustellen. Alle Server laufen auf CentOS 7 mit der folgenden /etc/hosts-Definition auf jedem Knoten:

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

Beachten Sie, dass GlusterFS und MySQL sehr intensive Prozesse sind. Wenn Sie diesem Setup folgen (GlusterFS und MySQL befinden sich auf einem einzigen Server), stellen Sie sicher, dass Sie über angemessene Hardwarespezifikationen für die Server verfügen.

Bereitstellung der Nextcloud-Datenbank

Wir beginnen mit der Datenbankbereitstellung für unseren Percona XtraDB-Cluster mit drei Knoten unter Verwendung von ClusterControl. Installieren Sie ClusterControl und richten Sie dann passwortloses SSH für alle Knoten ein, die von ClusterControl verwaltet werden sollen (3 PXC + 2 Proxys). Führen Sie auf dem ClusterControl-Knoten Folgendes aus:

$ 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

**Geben Sie das Root-Passwort für den entsprechenden Host ein, wenn Sie dazu aufgefordert werden.

Öffnen Sie einen Webbrowser und gehen Sie zu https://{ClusterControl-IP-Adresse}/clustercontrol und erstellen Sie einen Superuser. Gehen Sie dann zu Bereitstellen -> MySQL Galera. Folgen Sie dem Bereitstellungsassistenten entsprechend. Wählen Sie im zweiten Schritt „MySQL-Server definieren“ Percona XtraDB 5.7 und geben Sie die IP-Adresse für jeden Datenbankknoten an. Stellen Sie sicher, dass Sie ein grünes Häkchen erhalten, nachdem Sie die Details des Datenbankknotens eingegeben haben, wie unten gezeigt:

Klicken Sie auf „Bereitstellen“, um die Bereitstellung zu starten. Der Datenbankcluster ist in 15 bis 20 Minuten bereit. Sie können den Bereitstellungsfortschritt unter Aktivität -> Jobs -> Cluster erstellen -> Vollständige Jobdetails verfolgen. Der Cluster wird nach der Bereitstellung unter dem Datenbank-Cluster-Dashboard aufgelistet.

Wir können jetzt mit der Bereitstellung des Datenbank-Load-Balancers fortfahren.

Nextcloud Database Load Balancer-Bereitstellung

Es wird empfohlen, Nextcloud auf einem Single-Writer-Setup auszuführen, bei dem Schreibvorgänge jeweils von einem Master verarbeitet werden und die Lesevorgänge auf andere Knoten verteilt werden können. Wir können ProxySQL 2.0 verwenden, um diese Konfiguration zu erreichen, da es die Schreibabfragen an einen einzelnen Master weiterleiten kann.

Um ein ProxySQL bereitzustellen, klicken Sie auf Clusteraktionen> Load Balancer hinzufügen> ProxySQL> ProxySQL bereitstellen. Geben Sie die erforderlichen Informationen ein, die durch die roten Pfeile hervorgehoben sind:

Füllen Sie alle erforderlichen Details aus, wie durch die Pfeile oben hervorgehoben. Die Serveradresse ist der lb1-Server, 192.168.0.11. Weiter unten geben wir das Passwort des ProxySQL-Administrators und der Überwachungsbenutzer an. Nehmen Sie dann alle MySQL-Server in das Load-Balancing-Set auf und wählen Sie dann „No“ im Bereich „Implicit Transactions“. Klicken Sie auf „ProxySQL bereitstellen“, um die Bereitstellung zu starten.

Wiederholen Sie dieselben Schritte wie oben für den sekundären Load Balancer, lb2 (ändern Sie jedoch die „Serveradresse“ in die IP-Adresse von lb2). Andernfalls hätten wir in dieser Schicht keine Redundanz.

Unsere ProxySQL-Knoten sind jetzt installiert und mit zwei Hostgruppen für Galera Cluster konfiguriert. Eine für die Single-Master-Gruppe (Hostgruppe 10), bei der alle Verbindungen an einen Galera-Knoten weitergeleitet werden (dies ist nützlich, um Multi-Master-Deadlocks zu verhindern) und die Multi-Master-Gruppe (Hostgruppe 20) für alle Nur-Lese-Workloads, die wird auf alle Backend-MySQL-Server verteilt.

Als Nächstes müssen wir eine virtuelle IP-Adresse bereitstellen, um einen einzigen Endpunkt für unsere ProxySQL-Knoten bereitzustellen, sodass Ihre Anwendung nicht zwei verschiedene ProxySQL-Hosts definieren muss. Dies bietet auch automatische Failover-Funktionen, da die virtuelle IP-Adresse vom Backup-ProxySQL-Knoten übernommen wird, falls beim primären ProxySQL-Knoten etwas schief geht.

Gehen Sie zu ClusterControl -> Manage -> Load Balancers -> Keepalived -> Keepalived bereitstellen. Wählen Sie „ProxySQL“ als Load-Balancer-Typ und wählen Sie zwei unterschiedliche ProxySQL-Server aus der Dropdown-Liste aus. Geben Sie dann die virtuelle IP-Adresse sowie die zu überwachende Netzwerkschnittstelle an, wie im folgenden Beispiel gezeigt:

Sobald die Bereitstellung abgeschlossen ist, sollten Sie die folgenden Details in der Zusammenfassungsleiste des Clusters sehen:

Erstellen Sie schließlich eine neue Datenbank für unsere Anwendung, indem Sie zu ClusterControl -> Manage -> Schemas and Users -> Create Database gehen und "nextcloud" angeben. ClusterControl erstellt diese Datenbank auf jedem Galera-Knoten. Unsere Load-Balancer-Ebene ist jetzt vollständig.

GlusterFS-Bereitstellung für Nextcloud

Die folgenden Schritte sollten auf nextcloud1, nextcloud2, nextcloud3 durchgeführt werden, sofern nicht anders angegeben.

Schritt Eins

Es wird empfohlen, ein separates this für den GlusterFS-Speicher zu haben, also fügen wir eine zusätzliche Festplatte unter /dev/sdb hinzu und erstellen eine neue Partition:

$ fdisk /dev/sdb

Folgen Sie dem Assistenten zum Erstellen von fdisk-Partitionen, indem Sie die folgende Taste drücken:

n > p > Enter > Enter > Enter > w

Schritt Zwei

Überprüfen Sie, ob /dev/sdb1 erstellt wurde:

$ 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

Schritt Drei

Partition mit XFS formatieren:

$ mkfs.xfs /dev/sdb1

Schritt Vier

Mounten Sie die Partition als /storage/brick:

$ mkdir /glusterfs

$ mount /dev/sdb1 /glusterfs

Stellen Sie sicher, dass alle Knoten das folgende Layout haben:

$ 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

Schritt Fünf

Erstellen Sie ein Unterverzeichnis namens brick unter /glusterfs:

$ mkdir /glusterfs/brick

Schritt Sechs

Für Anwendungsredundanz können wir GlusterFS für die Dateireplikation zwischen den Hosts verwenden. Installieren Sie zunächst das GlusterFS-Repository für CentOS:

$ yum install centos-release-gluster -y

$ yum install epel-release -y

Schritt sieben

GlusterFS-Server installieren

$ yum install glusterfs-server -y

Achter Schritt

Gluster-Daemon aktivieren und starten:

$ systemctl enable glusterd

$ systemctl start glusterd

Schritt Neun

Prüfen Sie auf nextcloud1 die anderen Knoten:

(nextcloud1)$ gluster peer probe 192.168.0.22

(nextcloud1)$ gluster peer probe 192.168.0.23

Sie können den Peer-Status mit dem folgenden Befehl überprüfen:

(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)

Schritt Zehn

Erstellen Sie auf nextcloud1 ein repliziertes Volume auf geprüften Knoten:

(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

Schritt Elf

Starten Sie das replizierte Volume auf nextcloud1:

(nextcloud1)$ gluster volume start rep-volume

volume start: rep-volume: success

Vergewissern Sie sich, dass das replizierte Volume und die Prozesse online sind:

$ 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

Schritt zwölf

Mounten Sie das replizierte Volume auf /var/www/html. Erstellen Sie das Verzeichnis:

$ mkdir -p /var/www/html

Schritt Dreizehn

13) Fügen Sie folgende Zeile in /etc/fstab hinzu, um das automatische Mounten zu ermöglichen:

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

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

Schritt Vierzehn

Mounten Sie das GlusterFS nach /var/www/html:

$ mount -a

Und verifiziere mit:

$ 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)

Das replizierte Volume ist nun bereit und in jedem Knoten gemountet. Wir können jetzt mit der Bereitstellung der Anwendung fortfahren.

Nextcloud-Anwendungsbereitstellung

Die folgenden Schritte sollten auf nextcloud1, nextcloud2 und nextcloud3 durchgeführt werden, sofern nicht anders angegeben.

Nextcloud erfordert PHP 7.2 und höher und für die CentOS-Distribution müssen wir eine Reihe von Repositories wie EPEL und Remi aktivieren, um den Installationsprozess zu vereinfachen.

Schritt Eins

Wenn SELinux aktiviert ist, deaktivieren Sie es zuerst:

$ setenforce 0

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

Sie können Nextcloud auch mit aktiviertem SELinux ausführen, indem Sie dieser Anleitung folgen.

Schritt Zwei

Nextcloud-Anforderungen installieren und Remi-Repository für PHP 7.2 aktivieren:

$ 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

Schritt Drei

Installieren Sie Nextcloud-Abhängigkeiten, hauptsächlich Apache- und PHP 7.2-bezogene Pakete:

$ 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

Schritt Vier

Apache aktivieren und starten:

$ systemctl enable httpd.service

$ systemctl start httpd.service

Schritt Fünf

Erstellen Sie einen symbolischen Link für PHP, um die PHP 7.2-Binärdatei zu verwenden:

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

Schritt Sechs

Laden Sie auf nextcloud1 Nextcloud Server von hier herunter und extrahieren Sie es:

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

$ unzip nextcloud*

Schritt sieben

Kopieren Sie auf nextcloud1 das Verzeichnis nach /var/www/html und weisen Sie den korrekten Besitz zu:

$ cp -Rf nextcloud /var/www/html

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

**Beachten Sie, dass der Kopiervorgang nach /var/www/html aufgrund der GlusterFS-Volume-Replikation einige Zeit in Anspruch nehmen wird.

Achter Schritt

Bevor wir mit dem Öffnen des Installationsassistenten fortfahren, müssen wir die Variable pxc_strict_mode auf einen anderen Wert als "ENFORCING" (den Standardwert) deaktivieren. Dies liegt daran, dass der Nextcloud-Datenbankimport eine Reihe von Tabellen ohne definierten Primärschlüssel haben wird, was nicht für die Ausführung auf Galera Cluster empfohlen wird. Dies wird im Tuning-Abschnitt weiter unten näher erläutert.

Um die Konfiguration mit ClusterControl zu ändern, gehen Sie einfach zu Manage -> Configurations -> Change/Set Parameters:

Wählen Sie alle Datenbankinstanzen aus der Liste aus und geben Sie ein:

  • Gruppe:MYSQLD
  • Parameter:pxc_strict_mode
  • Neuer Wert:PERMISSIVE

ClusterControl führt die notwendigen Änderungen auf jedem Datenbankknoten automatisch durch. Wenn der Wert zur Laufzeit geändert werden kann, wird er sofort wirksam. ClusterControl konfiguriert auch den Wert in der MySQL-Konfigurationsdatei für Persistenz. Sie sollten das folgende Ergebnis sehen:

Schritt Neun

Jetzt können wir unsere Nextcloud-Installation konfigurieren. Öffnen Sie den Browser und gehen Sie zum HTTP-Server von nextcloud1 unter http://192.168.0.21/nextcloud/ und Ihnen wird der folgende Konfigurationsassistent angezeigt:

Konfigurieren Sie den Abschnitt "Storage &database" mit dem folgenden Wert:

  • Datenordner:/var/www/html/nextcloud/data
  • Datenbank konfigurieren:MySQL/MariaDB
  • Benutzername:nextcloud
  • Passwort:(das Passwort für den Benutzer nextcloud)
  • Datenbank:nextcloud
  • Host:192.168.0.10:6603 (Die virtuelle IP-Adresse mit ProxySQL-Port)

Klicken Sie auf „Setup beenden“, um den Konfigurationsprozess zu starten. Warten Sie, bis es fertig ist und Sie zum Nextcloud-Dashboard für den Benutzer „admin“ weitergeleitet werden. Die Installation ist nun abgeschlossen. Der nächste Abschnitt enthält einige Tuning-Tipps für einen effizienten Betrieb mit Galera Cluster.

Nextcloud-Datenbankoptimierung

Primärschlüssel

Das Vorhandensein eines Primärschlüssels für jede Tabelle ist für die Write-Set-Replikation des Galera-Clusters von entscheidender Bedeutung. Bei einer relativ großen Tabelle ohne Primärschlüssel würden große Aktualisierungs- oder Löschtransaktionen Ihren Cluster für sehr lange Zeit vollständig blockieren. Um Macken und Randfälle zu vermeiden, stellen Sie einfach sicher, dass alle Tabellen die InnoDB-Speicher-Engine mit einem expliziten Primärschlüssel verwenden (eindeutiger Schlüssel zählt nicht).

Die Standardinstallation von Nextcloud erstellt eine Reihe von Tabellen unter der angegebenen Datenbank und einige von ihnen entsprechen nicht dieser Regel. Um zu überprüfen, ob die Tabellen mit Galera kompatibel sind, können wir die folgende Anweisung ausführen:

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 |       | |

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

Die obige Ausgabe zeigt, dass es 7 Tabellen gibt, für die kein Primärschlüssel definiert ist. Um das oben Gesagte zu beheben, fügen Sie einfach einen Primärschlüssel mit der Spalte „Auto-Increment“ hinzu. Führen Sie die folgenden Befehle auf einem der Datenbankserver aus, zum Beispiel 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;

Sobald die obigen Änderungen angewendet wurden, können wir den pxc_strict_mode wieder auf den empfohlenen Wert "ENFORCING" zurückkonfigurieren. Wiederholen Sie Schritt 8 im Abschnitt "Anwendungsbereitstellung" mit dem entsprechenden Wert.

READ-COMMITTED-Isolationsstufe

Die von Nextcloud empfohlene Isolationsstufe für Transaktionen ist die Verwendung von READ-COMMITTED, während Galera Cluster standardmäßig auf die strengere Isolationsstufe REPEATABLE-READ eingestellt ist. Die Verwendung von READ-COMMITTED kann Datenverluste in Szenarien mit hoher Last vermeiden (z. B. durch Verwendung des Sync-Clients mit vielen Clients/Benutzern und vielen parallelen Operationen).

Um die Transaktionsebene zu ändern, gehen Sie zu ClusterControl -> Manage -> Configurations -> Change/Set Parameter und geben Sie Folgendes an:

Klicken Sie auf „Fortfahren“ und ClusterControl wendet die Konfigurationsänderungen sofort an. Es ist kein Neustart der Datenbank erforderlich.

Nextcloud mit mehreren Instanzen

Da wir die Installation auf nextcloud1 beim Zugriff auf die URL durchgeführt haben, wird diese IP-Adresse automatisch zur Variable „trusted_domains“ in Nextcloud hinzugefügt. Wenn Sie versuchten, auf andere Server zuzugreifen, z. B. auf den sekundären Server http://192.168.0.22/nextcloud, würden Sie eine Fehlermeldung sehen, dass dieser Host nicht autorisiert ist und in die trusted_domain-Variable hinzugefügt werden muss.

Fügen Sie daher alle IP-Adressen des Hosts unter dem Array "trusted_domain" in /var/www/html/nextcloud/config/config.php hinzu, wie im folgenden Beispiel:

  'trusted_domains' =>

  array (

    0 => '192.168.0.21',

    1 => '192.168.0.22',

    2 => '192.168.0.23'

  ),

Die obige Konfiguration ermöglicht Benutzern den Zugriff auf alle drei Anwendungsserver über die folgenden URLs:

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

Hinweis:Sie können diesen drei Nextcloud-Instanzen eine Load Balancer-Ebene hinzufügen, um Hochverfügbarkeit für die Anwendungsebene zu erreichen, indem Sie auf dem Markt erhältliche HTTP-Reverse-Proxys wie HAProxy oder nginx verwenden. Das würde den Rahmen dieses Blogposts sprengen.

Verwenden von Redis zum Sperren von Dateien

Der Transactional File Locking-Mechanismus von Nextcloud sperrt Dateien, um Dateibeschädigungen während des normalen Betriebs zu vermeiden. Es wird empfohlen, Redis zu installieren, um die Sperrung von Transaktionsdateien zu übernehmen (dies ist standardmäßig aktiviert), wodurch der Datenbankcluster von der Bearbeitung dieser schweren Aufgabe entlastet wird.

Um Redis zu installieren, einfach:

$ yum install -y redis

$ systemctl enable redis.service

$ systemctl start redis.service

Fügen Sie die folgenden Zeilen in /var/www/html/nextcloud/config/config.php ein:

  'filelocking.enabled' => true,

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

  'redis' => array(

     'host' => '192.168.0.21',

     'port' => 6379,

     'timeout' => 0.0,

   ),

Weitere Einzelheiten finden Sie in dieser Dokumentation, Transactional File Locking.

Fazit

Nextcloud kann als skalierbarer und hochverfügbarer Datei-Hosting-Dienst konfiguriert werden, um Ihren privaten Dateifreigabeanforderungen gerecht zu werden. In diesem Blog haben wir gezeigt, wie Sie Redundanz in die Nextcloud-, Dateisystem- und Datenbankschichten bringen können.