Open Source: Nextcloud im harten IT-Alltag
Vor sechs Jahren hat meine Firma sich für eine selbst gehostete Filesharing-Lösung entschieden. Wie es uns damit ergangen ist.

Die Gründung der eigenen Firma für IT-Dienstleistungen verlief unerwartet unkompliziert. Es waren viele Entscheidungen zu treffen, auch die, wie die eigene IT-Infrastruktur aufgebaut werden sollte. Mit der DSGVO am Horizont und in der Erwartung, sensible Daten mit unseren Kunden und Lieferanten auszutauschen, widmeten wir uns intensiv der Risikoanalyse, um später ein böses Erwachen zu vermeiden.
- Open Source: Nextcloud im harten IT-Alltag
- Wie genau sieht der Einsatz von Nextcloud aus?
- Daily Business mit Nextcloud
Unsere wichtigsten Anforderungen waren: komplette Kontrolle über die Zugriffe (User-Anlage, Berechtigungen, Logging und die damit verbundene Nachvollziehbarkeit), Verschlüsselung der gespeicherten Daten und rechtliche Absicherung der Nutzung. Da keiner der großen Anbieter unsere Anforderungen erfüllte und intern entsprechendes Know-how für den Betrieb einer selbst gehosteten Lösung vorhanden war, entschieden wir uns für eine Single-Server-Owncloud-Lösung.
Von Single-Server Owncloud zur hochverfügbaren Multi-Tier-Nextcloud-Instanz
Unsere Owncloud-Instanz bewährte sich sofort im praktischen Einsatz. Als jedoch im Frühjahr 2016 Gründer Frank Karlitschek Owncloud verließ, kamen uns leise Zweifel an der Zukunftssicherheit unserer Lösung. Nach dem Fork von Owncloud und der Bekanntgabe, dass Nextcloud in einer FOSS-Kollaborationsplattform weiterentwickeln werde, war für uns klar, dass wir zukünftig Nextcloud einsetzen wollten. Und ein in Flammen aufgehendes Netzteil ließ uns unsere Entscheidung schnell von "wollen" in "werden" wandeln - aber dazu später mehr.
Unsere aktuelle Architektur, auf der (nicht nur) Nextcloud läuft, ist eine klassische 3-Tier-Architektur und basiert komplett auf freier Software: Die eingehenden Verbindungen werden vom Loadbalancer (realisiert mit HAProxy) entschlüsselt ("TLS-Terminierung") und an die Applikationsserver weitergereicht.
Der Datenbank- (MariaDB & Redis) und File-Layer (GlusterFS) basieren jeweils auf einem Dreipunkt-Cluster, um das Risiko von Split-Brain-Situationen zu minimieren. MariaDB und GlusterFS laufen active-active (das heißt, jede Node kann jederzeit gelesen und beschrieben werden), Redis hingegen läuft active-standby, also kann nur die aktive Node beschrieben werden. Die beiden Loadbalancer sind active-standby konfiguriert und die virtuellen IP-Adressen werden mittels keepalived zwischen den beiden Nodes geschaltet.
MariaDB, Redis und HAProxy nutzen wir als "Container as a Deamon" (so nennen wir den Einsatz von Docker-Containern als RPM-Ersatz ohne jegliche weitere Orchestration), wobei das HAProxy Image selbstgebacken ist.
Die einzelnen Nodes laufen als virtuelle Server (qemu/libvirt) auf insgesamt sechs Servern, verteilt auf drei Rechenzentren. Sämtliche Filesysteme inklusive Swap sind verschlüsselt, die Kommunikation zwischen den Servern ist zusätzlich mittels Point-to-Point-IPSec abgesichert. Die offiziellen TLS-Zertifikate übernimmt das Let's-Encrypt-Projekt, intern wird eine private PKI eingesetzt.
Als Betriebssystem nutzten wir zu Beginn CentOS, der Umstieg auf Alma Linux beziehungsweise Rocky Linux ist bereits vollzogen.
Die Überwachung der Plattform sowie der darauf laufenden Applikationen wird von einer externen Zabbix-Installation übernommen. OS und Applikations-Logs werden mittels Syslog zentral gesammelt und täglich ausgewertet. Die Größe unserer Nextcloud-Instanz umfasst aktuell 31 angelegte User, davon 17 aktiv, mit rund 25.000 Dateien (ohne Applikations-Cache). Die Gesamtgröße der abgelegten Dateien beträgt 13 GByte, die zugehörige Datenbank ist 180 MByte groß.
Und wozu der ganze Aufwand?
Einerseits: Als unsere Single-Server Lösung aus unserem Arbeitsalltag nicht mehr wegzudenken war, verlagerten sich die Updates aus der Kernarbeitszeit in die Abendstunden und die Downtime wurde mehr und mehr von internen und externen Nutzern als unangenehm empfunden (Zitat Kunde: "Eine Cloud ist schließlich immer rund um die Uhr verfügbar!").
Andererseits: Den einmaligen Aufwand beim Aufbau der Plattform außen vor gelassen, ergibt sich durch hochgradige Automatisierung durch Ansible kein spürbarer Mehraufwand bei der Administration. Die Einspielung von OS- und Applikationsupdates erfolgt durch diverse Ansible Playbooks rollierend, einzig bei Applikationsupdates kommt es bei den jeweiligen Datenbank-Schema-Updates zu kurzen Unterbrechungen. Die Loadbalancer schalten hier automatisch Ausfallseiten. Ebenso können einzelne Server oder auch ein kompletter Standort ausfallen beziehungsweise tagsüber Patches eingespielt werden.
Rückwirkend betrachtet war die Entscheidung zur hochverfügbaren Multi-Tier-Plattform absolut spot-on, auch wenn sie im ersten Moment vielleicht übertrieben wirkte. So tief, wie Nextcloud als Applikation nun in unsere Geschäftsprozesse integriert ist, wäre der Betrieb auf einem einzigen Server als unverantwortlich zu bezeichnen.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Wie genau sieht der Einsatz von Nextcloud aus? |
Manche benutzen auch Dropbox und OneDrive. Es gibt immer viele gute Lösungen für ein...
Meine Theorie ist da das wegen Portweiterleitung direkt auf VM der VM-Host nicht im...
Proxmox erledigt das bei mir auch sehr zufriedenstellend... Gibt halt ne Menge Lösungen...
Ich hätte auch mal eine Frage. Warum kommt in der Aufzählung eigentlich nie SUSE vor?