virtuelle Maschine für den Betrieb einer NextCloud Instanz zur Dateiablage nutzen

In einem Gespräch wurde ich zuletzt auf den Bedarf für eine moderne, sichere und private Datenablage hin angesprochen. Neben vielen Cloud Alternativen hat sich NextCloud als private und kostengünstige Alternative als Lösung ergeben. In diesem Artikel beschreibe ich den zügigen und sicheren Aufbau einer eigenen internen Instanz.

Rahmenbedingungen

Der Aufbau soll als virtuelle Maschine erfolgen. Diese Instanz soll für alle Office Endgeräte vor Ort, als auch via VPN verwendet werden können. Alle Daten sollen lokal im Büro auf einer Synology Diskstation liegen, damit das aktuelle Datensicherungskonzept weiterhin Bestand hat.

Es wird somit eine interne alternative für Dropbox und andere Cloud Dateiablagen geschaffen werden.

Was aus Datenschutz und Kostengründen nicht verwendet werden soll

• Dropbox
• HiDrive
• Microsoft OneDrive
• Google Drive
• iCloud Drive
• Box.com
• Amazon Drive
• SecureSafe
• Your Secure Cloud
• Citrix ShareFile

Office Anforderungen zur Dateiablage (NextCloud Instanz)

Alle internen Clients sollen diese Lösung als DropBox Ersatz verwenden.

Interne Betriebssysteme:

• Microsoft Windows (diverse)
• MacOS (diverse)
• Mobiltelefone (iOS und Android)
• HP & Samsung Drucker für Dokumenten Scan

Nutzungsanforderungen:

• Gemeinsame Dateiablage für unterschiedliche Benutzergruppen
  • Abteilungsübergreifend
  • Selbstverwaltet
• Schneller Upload von Dokumenten und Bildern, für
  • klassische vor Ort Computer
  • Arbeitsplätze via VPN
  • Mobiltelefone (Bilder Dokumentation; Upload der Baustellenfotos)
• Einfache und DSGVO konforme Datenablage

Aufbau der virtuellen NextCloud Instanz

Nachfolgend werden die Schritte für den Aufbau einer neuen virtuellen Maschine beschrieben.

Zieldesign der Lösung

Erstellen eines neuen virtuellen Containers

Als Hostsystem wird ein veralteter Computer mit Proxmox verwendet.

Zum Betrieb der NextCloud Instanz sind folgende Ressourcen ausreichend:

• 2 vCPU
• 4 GB RAM
• 32 GB Festplatte (8 GB reichen für das nachfolgende Setup auch aus)

Ich habe mich bei diesem Aufbau für eine virtuelle Maschine und nicht für einen LCX Container entschieden. Ein LCX Container wäre jedoch auch ausreichend. Weitere Details zu Proxmox können hier in Erfahrung gebracht werden.

Hintergrundwissen: Die freigegebenen Ordner der Synology Diskstation sollen mittels NFS anstatt SMB eingebunden werden. Meine persönliche Präferenz tendierte dabei weg von LCX Containern zu einer vollständigen virtuellen Maschine. Denkbar wären jedoch beide Ansätze.

Installation von Ubuntu 22.04.2 als live ISO

Nach der Bereitstellung der ISO-Datei auf dem Proxmox-Host, einfach als minimaler Server installieren. Wir installieren alles weitere später manuell über die Konsole.

• ISO Datei
• Installationsanleitung
• Handbuch

Erste Anpassungen nach der Installation

root Zugriff via SSH aktivieren (optional)

Nachdem ich noch eigene ältere Monitoring Skripte aktiv laufen habe, habe ich mich für die Aktivierung des SSH Root Zugriffs entschieden. Dieser erspart mir beim weiteren Vorgehen die Eingabe und Nutzung von SUDO. (Klarstellung: meine Persönliche Faulheit spricht hier aus mir heraus)

Anmelden als Linux Benutzer
sudo passwd root
Kennwort für root Benutzer festlegen

modifizieren der sshd.conf
PermitRootLogin yes
/etc/init.d/ssh reload oder systemctl reload sshd
test -> OK

Damit wir mehr Geschwindigkeit und Performance in das virtuelle System bringen, habe ich mich für frühes Tuning der Kernelparameter entschieden.

Tuning Kernel Parameter

Im Leerlauf hat das System 40% RAM-Nutzung bei 2 GB RAM

cat /proc/sys/vm/swappiness

Standardwert: 60

Bedeutet: gute Balance zwischen RAM und auslagern in den SWAP Bereich

echo 5 > /proc/sys/vm/swappiness

Testen -> nimmt gleich mehr Arbeitsspeicher

Permanentes anpassen der SWAP-Nutzung

vi /etc/sysctl.conf
vm.swappiness=5

Nebeninformation: Prozesse auf Basis des Speicherverbrauchs auflisten

ps aux --sort –rss

Damit lagert das System permanent weniger aus und nimmt dadurch mehr Arbeitsspeicher, wodurch der lokale Zugriff auf Daten und Dateien schneller wird.

Arbeitsspeicher Tuning für langsame Festplatten

Der Kernel verwendet einen RAM-Cache für den Zugriff auf Dateien.

cat /proc/sys/vm/vfs_cache_pressure                  

Standardwert: 100

Bedeutet: Datei wird nach dem Zugriff wieder an das Dateisystem zurückgegeben

0 bedeutet alles im RAM – das wollen wir auch nicht

Wir probieren es mal mit 50

echo 50 > /proc/sys/vm/vfs_cache_pressure

testen -> fühlt sich „geschmeidiger“ an

Permanentes anpassen der CACHE Nutzung

vi /etc/sysctl.conf

vm.vfs_cache_pressure=50

Nebeninformation: Festplatten Performance Messung

Schreiben:

dd if=/dev/zero of=/media/perfcheck/testfile bs=16k count=128k

Lesen:

dd if=//media/perfcheck/testfile of=/dev/null bs=16k

Anpassen von Ubuntu für den NextCloud Betrieb

Der Betrieb von NextCloud erfordert generell nur einen Webserver mit PHP-Interpreter. Wir wollen aber Geschwindigkeit & Performance und brauchen somit etwas mehr.

Notwendige Pakete Installieren

Wir brauchen

• Webserver = Apache
• PHP als FastCGI (FPM)
• REDIS & APCu für lokales Caching
• Einige zusätzliche Bibliotheken

Umsetzung in der Konsole als root

apt-get update
apt-get install apache2 cron php-apcu redis-server php-redis mlocate imagemagick rsync
apt-get install php-common, php8.1-{fpm,gd,curl,xml,zip,intl,mbstring,bz2,ldap,apcu,bcmath,gmp,imagick,igbinary,mysql,redis,smbclient,cli,common,opcache,readline}
systemctl restart apache2

Ab diesem Zeitpunkt begrüßt uns das System mit der Ubuntu Apache2 Startseite.

Mount Points auf Synology Diskstation erstellen

Damit auf dem virtuellen System lokal nur die notwendigsten Daten gespeichert werden, nutze ich die Synology Diskstation als HTML- als auch als DATEN-Verzeichnis. Dadurch wird die Datenhaltung auf die Synology begrenzt. Zusätzlich kann dadurch das Update der NextCloud Webserververzeichnisse über einen anderen Computer erfolgen.

mkdir /media/NextCloud_html
mkdir /media/NextCloud_html_local
mkdir /media/NextCloud_data
                 

Anpassen der fstab für das automatische verbinden ab dem Systemstart

vi /etc/fstab

Hinzufügen der nachfolgenden Zeilen:

172.16.42.12:/volume1/web/NextCloud/html               /media/NextCloud_html      nfs               noatime,nodiratime,relatime,async,tcp
172.16.42.12:/volume1/web/NextCloud/data               /media/NextCloud_data      nfs               async,tcp

Dadurch wird sichergestellt, dass alle notwendigen Daten ausschließlich auf der Synology Diskstation abgelegt sind. Die zusätzlichen Optionen im HTML-Mount bewirken, dass keine unnötigen Dateiupdates der einzelnen HTML oder PHP-Dateien beim Zugriff auf diese erfolgen. Dadurch wird im Betrieb die Netzwerklast verringert.

Sicherheitskopien der Konfigurationen anlegen

Ich habe gerne meine Backups gerne etwas strukturierter Beisammen. Daher habe ich mir ein kleines Skript für alle Dateien geschrieben. Das Skript findet ihr hier.

Folgende Dateien sollten gesichert werden:

• /etc/fstab
• /etc/ssh/sshd_config
• /etc/sysctl.conf
• /etc/apache2/apache2.conf
• /etc/apache2/sites-enabled/000-default.conf
• /etc/redis/redis.conf
• /etc/crontab
• /etc/php/8.1/fpm/php-fpm.conf
• /etc/php/8.1/mods-available/apcu.ini
• /etc/php/8.1/fpm/conf.d/20-apcu.ini
• /etc/php/8.1/fpm/pool.d/www.conf
• /etc/php/8.1/fpm/php-fpm.conf
• /etc/php/8.1/cli/php.ini
• /etc/php/8.1/fpm/php.ini
• /etc/ImageMagick-6/policy.xml

Anpassungen für den NextCloud Betrieb

Apache2

vi /etc/apache2/apache2.conf

<Directory /media/NextCloud_html/>

        Options Indexes FollowSymLinks

        AllowOverride None

        Require all granted

</Directory>

vi /etc/apache2/sites-enabled/000-default.conf

 #DocumentRoot /var/www/html

 DocumentRoot /media/NextCloud_html_local/

Zusätzlich deaktivieren wir für den gesamten Apachen gleich das WEBDAV-Modul und setzen passende NextCloud Header.

      <IfModule mod_dav.c>

        Dav off

      </IfModule>

     <IfModule mod_headers.c>

          Header always set Strict-Transport-Security “max-age=15768000; preload”

     </IfModule>

REDIS Server

vi /etc/redis/redis.conf

           port 0

           unixsocket /var/run/redis/redis.sock

           unixsocketperm 770

Hinzufügen des REDIS Servers zur Gruppe www-data

usermod -a -G redis www-data
service redis-server restart
service apache2 restart

Testen inwieweit REDIS verwendet wird

http://172.16.42.24/redis.php

Die PHP Datei kann unter https://github.com/tessus/redis-stats heruntergeladen werden. Dort befinden sich auch die passenden Beschreibungen und Details.

Anpassen der NextCloud Konfiguration

  'memcache.local' => '\OC\Memcache\APCu',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => '/var/run/redis/redis-server.sock',
    'port' => 0,
    'dbindex' => 0,
    'password' => 'b8a611bce4771f8f7b2ec4b01d1ca09e43c62a5ffb7441572080b08910805439',
    'timeout' => 1.5,
  ),

PHP APCu Einstellungen

vi /etc/php/8.1/fpm/conf.d/20-apcu.ini

Hinzufügen der nachfolgenden Zeilen:

apc.enable_cli=1
apc.enable=1
apc.shm_segments=1
apc.shm_size=32M
apc.ttl=3600
apc.user_ttl=7200
apc.gc_ttl=3600
apc.max_file_size=6M
apc.stat=0

Testen ob apcu verwendet wird

http://172.16.42.24/apcu.php

Das Skript kann unter https://github.com/krakjoe/apcu/blob/master/apc.php heruntergeladen werden.

PHP FPM Einstellungen

vi /etc/php/8.1/fpm/php.ini

Verändern der Einstellungen für Timeout und Arbeitsspeichernutzung

;max_execution_time = 30
max_execution_time = 3000
 
;max_input_time = 60
max_input_time = 3000
 
 
#memory_limit = 128M
memory_limit = 512M

Diese werden nach dem Neueinlesen aktiv.

/etc/init.d/php8.1-fpm reload 

NextClouid Cron jobs

8  *    * * *   root    sudo -u www-data php /media/NextCloud_html/NextCloud/occ preview:pre-generate -vvv
 
# apache bei Bedarf täglich neu starten
#15 0    * * *   root    service apache2 restart

# täglicher Sync des lokalen WWW-Root Verzeichnisses (Optimierung 3)
16 0    * * *   root    rsync -a -P --ignore-existing -E --delete --stats --progress -h /media/NextCloud_html/ /media/NextCloud_html_local/

# NextCloud cronjob regelmaessig ausführen
0   *    * * *   root    sudo -u www-data php /media/NextCloud_html/NextCloud/cron.php
15  *    * * *   root    sudo -u www-data php /media/NextCloud_html/NextCloud/cron.php
30  *    * * *   root    sudo -u www-data php /media/NextCloud_html/NextCloud/cron.php
45  *    * * *   root    sudo -u www-data php /media/NextCloud_html/NextCloud/cron.php

Danach läuft alles wie am Schnürchen. Es könnte nur noch etwas schneller sein …

Weiteres Performance Tuning

CIFS vs. NFS Mount

Sowohl CIFS als auch der NFS Mount lassen sich noch weiter tunen. Ich habe meine NFS Parameter bereits in den ersten Mount eingebaut und auf CIFS in Ubuntu verzichte ich aktuell. Technische Details kann ich gerne bei Bedarf genauer ausführen.

FS-Cache für Netzwerk Datei Cache

Damit ales über Caches – also auch der Netzwerkdateizugriff wie bei einem Dateiserver – beschleunigt wird, wird hier die Verwendung von FS-Cache beschrieben.

apt install cachefilesd
systemctl enable --now cachefilesd
systemctl status cachefilesd

Danach sollte der FS-Cache bereits laufen. Wir aktivieren diesen permanent:

vi /etc/default/cachefilesd
RUN="yes"

Damit der FS-Cache auch im laufenden System verwendet wird, ist eine Anpassung an den Mountpoints notwendig.

Anpassung fstab für html und data -> hinzufügen von “fsc” in den mount Optionen

Nach einem Neustart -> checken ob FS-Cache genutzt wird

cat /proc/fs/nfsfs/volumes

FS-Cache Statistiken abrufen

cat /proc/fs/fscache/stats

Größe des caches checken

df -h /var/cache/fscache

Hinweis: FS-Cache hat nicht die erhoffte Verbesserung der Performance für den PHP-FPM Prozess geliefert. Zwar ist die Netzwerkauslastung gesunken und Belastung der lokalen Festplatte als auch des Arbeitsspeichers gestiegen, jedoch geht es noch besser. (Zumal der DocumentRoot incl. NextCloud nicht all zu umfangreich ist).

Apache2 DocumentRoot auf lokales System umziehen

Eine Überlastung der NextCloud führte immer wieder mal dazu, dass der PHP Prozess nicht rechtzeitig seine Daten über das Netzwerk einholen konnte. Die Folge: NextCloud ist für alle Offline.

Im Monitoring war dies in der durchgehenden Belastung des Netzwerks ersichtlich:

Im Bild sind leider die 0-Punkte nicht zu sehen, in welchen der PHP-FPM Prozess temporär vollständig zum erliegen gekommen ist. Mit dem Befehl „top“ konnte jedoch die Wait-Zeit auf IO-Wait der Netzwerkanbindung zurückgeführt werden. Die lokale Festplatte hingegen hatte kaum etwas zu tun.

Damit das ein Ende hat -> kurzentschlossen den Apache2 DocumentRoot angepasst und auf die lokale Festplatte umgezogen. Für ersten Test zunächst manuell:

cp -R NextCloud_html/ NextCloud_html_local
chown -R www-data:www-data NextCloud_html_local/

Damit der Apache das richtige Verzeichnis nutzt:

vi /etc/apache2/apache2.conf

Hinzufügen des neuen Verzeichnisses

<Directory /media/NextCloud_html_local/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>
  

Als auch Anpassung des Document Root in /etc/apache2/sites-enabled/000-default.conf

#DocumentRoot /media/NextCloud_html
DocumentRoot /media/NextCloud_html_local

Dadurch konnte der Kernel viele der laufend benötigten Dateien in den Arbeitsspeicher nehmen. Der Zugriff beschleunigte sich signifikant. Die NextCloud Webseite konnte dadurch durchgehend trotz massiver Datenverschiebungen und Up- und Downloads schnell aufgerufen werden. Die Installierten Clients zugleich zügig und ohne Fehler Synchronisieren.

Die Dateisync automatisiert (wg. zukünftigen Nextcloud Updates) mittels rync

src="/media/NextCloud_html/"
dst="/media/NextCloud_html_local/"
chown -R www-data:www-data $dst
rsync -a -P --ignore-existing -E --delete --stats --progress -h $src $dst

Ergebnis

Läuft – Performant und stabil. Vollständig intern und inklusive zwischen den Benutzern geteilter Dateiablage. Für alle Endgeräte im lokalen Netzwerk und via VPN.

Der Arbeitsspeicher ist dabei fast durchgehend am oberen Limit, ohne Paging:

Dokumente, Bilder und Videouploads laufen sowohl von den Handys als auch den Computern durchgehend sauber und ohne nennenswerte Ausfälle durch.

Die Festplattenbelastung ist weiterhin gering – die Reaktionsfähigkeit der Webanwendung und der WebDAV Schnittstelle konstant stabil:

Die CPU-Auslastung der VM hält sich laufend in Grenzen.

Damit konte genau das erreicht werden was notwendig war. ein Ersatz für Dropbox ohne zusätzliche Kosten bei gleichzeitiger Nutzung der bestehenden Ressourcen. Gerne unterstütze ich dich dabei auch für Dich die Ideale Lösung zu finden. Damit du deinen individuellen Weg in der IT-Abteilung von heute nutzen und finden kannst.

Bist du bereit Kosten, Aufwand und Nutzen in Einklang zu bringen?

Hinterlasse mir eine Nachricht oder kontaktiere mich direkt via Mail, LinkedIn oder XING.

Über den Autor

Gregor Tomitzek – IT Berater, Coach und Mentor

Seit über 25 Jahren berate ich Firmen und private Personen in allen Belangen der Computertechnik. Als Leiter eines Infrastrukturteams bringe ich die technischen Anforderungen der Kunden zu Lösungen, und ermögliche dadurch ein besseres und schnelleres Arbeiten.

Durch meine langjährige Erfahrung, die Ausbindungen und der Nähe zu allen Unternehmensprozessen, unterstütze ich Leistungsträger, Teamleiter und Vorstände dabei, die Überlastung in IT-Abteilung zu senken und zugleich die Leistungsfähigkeit und Zufriedenheit von IT-Teams wahrnehmbar zu steigern.

Änderungshistorie