Nextcloud auf zwei Servern über zwei Internetleitungen?


Recommended Posts

Ich möchte gerne für 100 Nutzer eine Nextcloud bereitstellen. Da Nextcloud von Haus aus kein Load-Balancing mitbringt, hatte ich andere Ideen:

 

A) WebDAV Einbindung

- Zwei Server an unterschiedlichen Standorten

- Eine Nextcloud Oberfläche

- in dieser wird Server2 zB per WebDAV (?) eingebunden

- die Dateien werden auf den zwei Servern verteilt

- /server1/datei1 wird von server1.example.com geladen

- /webdav/server2/datei2 wird über server2.example.com geladen

 

Ziel wäre also, dass je nach Datei, der Upload des entsprechenden Standorts genutzt wird. Allerdings weiß ich nicht ob Nextcloud bei eingebundenen Shares auch die externe Domain an den Nutzer publiziert oder das intern durch einen Proxy jagt. Weiß das jemand?

 

 

B) DNS "Load"-Balancing

- Nextcloud wird auf server1 und server2 installiert und beide nutzen die Datenbank auf server1

- server1 und server2 werden permanent synchron gehalten (rsync)

- die Domain nextcloud.example.com bekommt eine TTL von 5 Minuten und erhält im Wechsel die öffentliche IP von server1 und server2

 

Es wäre also reiner Zufall wo sich der Nutzer anmeldet und man hätte eine Art Load Balancing. Logins etc muss man nicht doppelt pflegen, weil es ja nur eine Datenbank gibt. In wie weit das bei Uploads ein Problem geben könnte (da server2 die auf server1 hochgeladene Datei ja auch erst mal abholen muss), kann ich nicht sagen. Was meint Ihr?

 

Link to comment

...unabhängig von nextcloud, die Frage ob das die richtige Architektur für so einen usecase ist?

 

ich bin a auch schon etwas eingerostet ;-)

 

 

1 hour ago, mgutt said:

A) WebDAV Einbindung

- Zwei Server an unterschiedlichen Standorten

- Eine Nextcloud Oberfläche

- in dieser wird Server2 zB per WebDAV (?) eingebunden

- die Dateien werden auf den zwei Servern verteilt

- /server1/datei1 wird von server1.example.com geladen

- /webdav/server2/datei2 wird über server2.example.com geladen

 

...warum nicht eine verteilte DB im Hintergrund?

Gibt es da nicht was im Cloud-Baukasten?

 

1 hour ago, mgutt said:

B) DNS "Load"-Balancing

Eine andere Idee wäre es, wenn man die Datenbank nur auf server1 hat und die Dateien zwischen server1 und server2 dauerhaft synchron hält. Nun greift der Nutzer über nextcloud.example.com zu, wobei diese Domain alle 5 Minuten die IP wechselt. 

...der client cached das lokal ausserhalb Deiner Kontrolle...erst wenn die IP nicht mehr funktioniert, stürzt er entweder ab oder fragt nochmal nach (und bekommt dann erst eine neue IP zurück).

 

Muss es nicht vereinfacht so aussehen? ->

 

- eine Domain als Zugang, ein Webserver/Proxy.

- dieser Webserver macht das Loadbalancing auf HTTP-Instanzen die einzelnen Sites

- die DB im Hintergrund synchronisiert sich eigenständig..spätestens wenn File A noch in Site B steckt, wenn in Site A dann zugegriffen wird, wird die Datei über den Interlink ge-synct.

Link to comment
16 minutes ago, Ford Prefect said:

...unabhängig von nextcloud, die Frage ob das die richtige Architektur für so einen usecase ist?

 

Ich kenne sonst keine Alternative, die man selbst hosten kann (DSGVO + Datenhoheit).

 

10 minutes ago, Ford Prefect said:

...warum nicht eine verteilte DB im Hintergrund?

 

?

 

11 minutes ago, Ford Prefect said:

..der client cached das lokal ausserhalb Deiner Kontrolle...erst wenn die IP nicht mehr funktioniert, stürzt er entweder ab oder fragt nochmal nach

Da habe ich meine Idee wohl nicht gut erklärt. Es gibt kein "IP funktioniert nicht mehr". Ich möchte nur ständig zwischen der öffentlichen IP von server1 und server2 wechseln. Die TTL der Domain wird ja bis zum Client durchgeleitet und er muss entsprechend nach Ablauf der Zeit die Domain neu auflösen. 

 

Löst also jemand um 10:00 die Domain auf, bekommt er die IP von server1. Um 10:05 ist er gezwungen die Domain noch mal aufzulösen und bekommt die IP von server2. Das Balancing entsteht nun dadurch, dass ein anderer Nutzer um 10:09 die Domain auflöst (server2 IP) und die nächste Auflösung erst um 10:14 erfolgt (server1 IP). Man hat also ein, natürlich völlig unkontrolliertes, Balancing. Bei 100 Nutzern verspreche ich mir aber immer noch eine gute Verteilung von sagen wir mal im Worst Case von 70 zu 30.

 

15 minutes ago, Ford Prefect said:

- eine Domain als Zugang, ein Webserver/Proxy.

- dieser Webserver macht das Loadbalancing auf HTTP-Instanzen die einzelnen Sites

Das funktioniert nicht, weil dann die Internetleitung des Proxies der Flaschenhals ist. In dem Fall müsste also der Proxy in einem Rechenzentrum stehen, was aber wegen DSGVO/Datenhoheit unerwünscht ist.

Link to comment
47 minutes ago, mgutt said:

Ich kenne sonst keine Alternative, die man selbst hosten kann (DSGVO + Datenhoheit).

...ob nextcloud oder was Anderes spielt für das Prinzip erstmal ekien Rolle...auch ob es zwei oder n Sites sind.

Das meinte ich damit. Di Aufgabe erstmal agnostisch zu nextcloud betrachten  Storage - Application - Webservice/Proxy....egal wie die App heisst.

Quote

?

Du willst, egal von wo Du kommst, das alle resourcen/Files verfügbar sind.

Also Storage und Verweis - der in der DB  steckt - syncen über alle Sites/Nodes/Storage-Pools, oder?

Sowas -> https://mariadb.org/fest2020/kubernetes/  ?

 

Quote

Da habe ich meine Idee wohl nicht gut erklärt. Es gibt kein "IP funktioniert nicht mehr". Ich möchte nur ständig zwischen der öffentlichen IP von server1 und server2 wechseln. Die TTL der Domain wird ja bis zum Client durchgeleitet und er muss entsprechend nach Ablauf der Zeit die Domain neu auflösen.

...ne, ich hab es nicht richtig erklärt...niemand sagt, das Clients die TTL beachten....ist nur Theorie bzw. ausserhalb Deiner Kontrolle.

Aber versuchen kannst Du es so.

 

Quote

Das funktioniert nicht, weil dann die Internetleitung des Proxies der Flaschenhals ist. In dem Fall müsste also der Proxy in einem Rechenzentrum stehen, was aber wegen DSGVO/Datenhoheit unerwünscht ist.

...kann ein Proxy kein Referal  - Edit: es müsste eher redirect heissen-  auf eine externe IP oder URL machen und der Client macht dann selbst einen neuen Request dorthin auf (dort ist dann der Nextcloud-Proxy der Instanz A, B, C...)? dann wird nur für den Referal  Redirect die Bandbreite der Proxy-Site benutzt, da die Daten selbst nicht durch den Proxy durchmüssen.

Der Referal  Redirect könnte eben einer Rule folgen...abwechselnd oder je nach Zugriffs-Quelle.

 

Edited by Ford Prefect
Link to comment
37 minutes ago, Ford Prefect said:

Also Storage und Verweis - der in der DB  steckt - syncen über alle Sites/Nodes/Storage-Pools, oder?

 

Brauche ich ja nicht, wenn ich die DB nur auf server1 habe. Ich trage bei server1 in der config.php also localhost:3306 ein und auf server2 stattdessen server1.example.com:3306. Der Traffic der DB ist ja gering und sollte daher kein Loadbalancing erfordern.

 

37 minutes ago, Ford Prefect said:

...ne, ich hab es nicht richtig erklärt...niemand sagt, das Clients die TTL beachten....ist nur Theorie bzw. ausserhalb Deiner Kontrolle.

 

Die TTL muss jeder beachten. Ansonsten könnte ja niemals jemand seine Nextcloud über eine DDNS verfügbar machen. Die wäre dann für Stunden/Tage offline, sobald man eine neue IP vom Provider bekommt. Ich hatte den Fall jedenfalls noch nie und es ist auch extrem selten der Fall. Das würde ich also nicht als Problem sehen. Schon gar nicht, wenn es nur 1 von 100 Usern ist. Hängt der eben dauerhaft auf server2. Schadet ja nicht, solange nicht alle 100 auf server2 festhängen.

 

37 minutes ago, Ford Prefect said:

...kann ein Proxy kein Referal auf eine externe IP oder URL machen

Dann würde aber der Nutzer im Browser server1.example.com sehen. Das als Favorit gespeichert und schon war es das mit Balancing.

 

Allerdings wäre es denkbar nur die Downloads per 307 weiterzuleiten. Bei Nextcloud werden ja Dateizugriffe immer über die "remote.php" geregelt. Ein GET auf eine URL mit "remote.php" und per Zufall kommt ein 307 auf einen anderen Server. Uploads, also POST ginge dann grundsätzlich auf server1, was aber vertretbar wäre, weil die Downloadbandbreite des Servers ja eh größer ist.

 

Es gibt dabei aber auch ein Problem. Und zwar das Login-Cookie funktioniert nur auf nextcloud.example.com und nicht auf server2.example.com. Ein Klick auf den Download würde also die erneute Eingabe der Login-Daten erfordern. Im Browser ist das ok, aber was im Client passiert, kann ich nicht sagen. Ich vermute mal, dass das schlicht nicht geht, weil man da ja gar kein separates Login-Fenster hat. Oder der Client ist clever und überträgt den Login dann noch mal automatisch?!

Link to comment
23 minutes ago, mgutt said:

Brauche ich ja nicht, wenn ich die DB nur auf server1 habe. Ich trage bei server1 in der config.php also localhost:3306 ein und auf server2 stattdessen server1.example.com:3306. Der Traffic der DB ist ja gering und sollte daher kein Loadbalancing erfordern.

...ok, oben hatte mich Dein Statement "...die Dateien werden auf den zwei Servern verteilt" in die andere Richtung denken lassen.

 

Quote

Die TTL muss jeder beachten. Ansonsten könnte ja niemals jemand seine Nextcloud über eine DDNS verfügbar machen. Die wäre dann für Stunden/Tage offline, sobald man eine neue IP vom Provider bekommt. Ich hatte den Fall jedenfalls noch nie und es ist auch extrem selten der Fall. Das würde ich also nicht als Problem sehen. Schon gar nicht, wenn es nur 1 von 100 Usern ist. Hängt der eben dauerhaft auf server2. Schadet ja nicht, solange nicht alle 100 auf server2 festhängen.

Wie gesagt...kann funktionieren.

 

Quote

Dann würde aber der Nutzer im Browser server1.example.com sehen. Das als Favorit gespeichert und schon war es das mit Balancing.

...sowas wie ein "silent redirect" müsste es geben. 🤔

 

Edit: ...und den nexcloud.example.com auf einem VPS hosten? In der dortigen Instanz kannst Du die URL-rewrites /den proxy ja machen ohne die Bandbreiten von server1.example.com und server2.example.com "doppelt anzuknabbern".

 

Quote

Allerdings wäre es denkbar nur die Downloads per 307 weiterzuleiten. Bei Nextcloud werden ja Dateizugriffe immer über die "remote.php" geregelt. Ein GET auf eine URL mit "remote.php" und per Zufall kommt ein 307 auf einen anderen Server.

 

Es gibt dabei aber auch ein Problem. Und zwar das Login-Cookie funktioniert nur auf nextcloud.example.com und nicht auf server2.example.com.

ein auth token oder sowas, wie beim SSO gibt es bei nextcloud in der API nicht?

 

Edited by Ford Prefect
Link to comment

Abend

Der Tip vom Smolo mit seafile ist interessant und wäre auch mein Ansatz.

Vor Nextcloud habe ich mit Seafile experimentiert.

Es ging schneller als Nextcloud hatte aber eine Funktion die für mich ein Nachteil war.

Die Daten liegen verschlüsselt am Server. Das wollte ich nicht.

Ich wollte eine Festplatte die auf jedem Pc lesbar ist und das funktioniert gut mit Nextcloud.

Cu mfg Chrisu

 

 

Link to comment
37 minutes ago, Smolo said:

Wie wäre es mit seafile?

 

Das Konzept verteilt die Last auf mehrere Server. Ich will aber die Internetverbindung mehrerer Server nutzen. Das geht nicht, wenn alle Nutzer durch einen Proxy (eine Internetleitung) laufen.

 

38 minutes ago, Ford Prefect said:

Edit: ...und den nexcloud.example.com auf einem VPS hosten? In der dortigen Instanz kannst Du die URL-rewrites /den proxy ja machen ohne die Bandbreiten von server1.example.com und server2.example.com "doppelt anzuknabbern".

Ja das geht, nur dann laufen alle Nutzer beim Rechenzentrum eines Dritten auf, was eigentlich als Vorgabe ausgeschlossen ist und du zahlst doppelten Traffic (Upload zum Proxy + Forward zu server1 bzw auch andersherum), aber das könnte sich im überschaubaren Rahmen bewegen. Also die Option würde ich nur in Betracht ziehen, wenn es gar nicht anders lösbar ist.

 

44 minutes ago, Ford Prefect said:

ein auth token oder sowas, wie beim SSO gibt es bei nextcloud in der API nicht?

 

Der "Token" ist beim Surfen ja im Cookie und der Browser überträgt das Cookie nur auf die Subdomain, von der das Cookie kam. Bei den Clients bin ich überfragt ob die das Cookie auf die Subdomain binden, aber ich denke mal schon.

 

Link to comment
12 minutes ago, mgutt said:

Ja das geht, nur dann laufen alle Nutzer beim Rechenzentrum eines Dritten auf,

...die User-DB muss nicht auf dem RZ des VPS liegen, nur der App-Server/Proxy.

 

Quote

und du zahlst doppelten Traffic (Upload zum Proxy + Forward zu server1 bzw auch andersherum), aber das könnte sich im überschaubaren Rahmen bewegen.

...suchen und rechnen...ich hatte mal nen VPS bei netcup mit echtem unlimited Traffic (OK, fair use) ... aktuell sind die caps da wohl bei 80TB pro Monat (fangen bei einem 2vCore, 8GB und 6EUR/Monat an).

Edit: der 12vCore/48GB hat 1.2TB SSD raid 10 für 30EUR/Monat...da kannste noch nen schönen 1TB Cache drauf aufbauen um den Traffik zu minimieren (encrypted, latürnich).

Edited by Ford Prefect
Link to comment
2 hours ago, mgutt said:

Das Konzept verteilt die Last auf mehrere Server. Ich will aber die Internetverbindung mehrerer Server nutzen. Das geht nicht, wenn alle Nutzer durch einen Proxy (eine Internetleitung) laufen.

Du müsstest doch sowieso einen Proxy vorschalten? Entweder direkt Cloudflare oder du machst das über einen Server bei NetCup?

Link to comment
2 hours ago, Ford Prefect said:

...die User-DB muss nicht auf dem RZ des VPS liegen, nur der App-Server/Proxy.

 

Schon klar. Aber das ist völlig egal. Wenn sich ein Nutzer einloggt, wird dessen Passwort über das SSL Zertifikat der Proxy Domain verschlüsselt und dann an den Proxy gesendet. Dieser entschlüsselt das Passwort und nutzt nun das SSL Zertifikat von der Server Domain um es erneut zu verschlüsseln und an diesen weiterzuleiten. Wenn es nicht Proxy heißen würde, könnte man es auch Man-in-the-Middle nennen ;)

 

 

Link to comment

...so war es nicht gemeint...

Der Angriffsvektor, das garnicht der UserA vor dem Gerät sitzt, dessen Verbindung auf einem SSL-Zertifikat order gar nur einer Benutzter/Passwort-Combo des UsersA basiert, ist doch bei 100Users viel wahrscheinlicher als dass (d)ein VPS in einem zertifizierten RZ in DE geknackt wird ohne dass Du es auch merkst.

Sprich, die Datenhoheit hast Du verloren, sobald Du User mit Zugang auf den Server ausstattest, die dabei nicht in Deiner lokalen Site und LAN sitzen.

 

Aber jetzt wird es philosophisch und OT 🤐

Link to comment
55 minutes ago, mgutt said:

Nein. Weder bei Idee A noch bei Idee B.

Ich bin bisher davon ausgegangen das NextCloud keinen Support bietet für 2 App Server und eine 1 DB bzw. würde ich bei solchen Themen wegen den Daten nicht rumexperimentieren da würde ich immer eine Clusterlösung vorziehen grad bei 100 Usern! Aber das gut es gibt noch andere die das probiert haben. 

 

Help needed to setup a NC14 cluster - 🚧 Installation - Nextcloud community

 

Dann wahrscheinlich Variante 2 von dir auch wenn ich das bissel heftig finde ;-)

Link to comment
2 hours ago, Smolo said:

Ich bin bisher davon ausgegangen das NextCloud keinen Support bietet für 2 App Server und eine 1 DB

 

Das ist das schöne daran, wenn man Software und Datenbank trennt. Du könntest auch 1000 Nextcloud-Installationen mit einer Datenbank nutzen. Das ist nichts anderes als hättest du 1000 Nutzer auf einer Installation.

 

Das einzige absehbare Problem wird sein, dass UserA eine Datei auf Server1 hochlädt und UserB diese neue Datei auf Server2 sieht, weil die Datenbank von Server1 die Datei kennt. Aber da sie noch nicht auf Server2 synchronisiert wurde, kann UserB sie nicht herunterladen. Da müsste man ein wenig den Nextcloud Quellcode anpassen und UserB über eine Wartezeit informieren ("Einen Moment bitte, die Datei wird für den Download vorbereitet...").

 

Das andere Problem könnte sein, wenn Nextcloud die Logins nicht mit der Datenbank regelt, sondern per PHP Sessions. Dann müsste man den Login-Mechanismus anpassen. Aber das werden die ja wohl nicht gemacht haben.

 

2 hours ago, Smolo said:

Ok, haben sie doch. ^^

 

Sollte aber einfach lösbar sein, in dem man das PHP Temp Verzeichnis, wo die Sessions drin liegen anpasst:

https://stackoverflow.com/a/4927969/318765

 

Und das dann auf dem 2. Server als Temp-Verzeichnis mountet. Das siehst auch im Screenshot von dem User "Finalls" unter "Php Session":

nx-bad.png.c2ceca59d7ca2af6427494c684944f8c.png

 

Sein Setup ist sogar etwas einfacher, weil er die Dateien nur auf einem einzigen Server liegen hat. 

Link to comment
24 minutes ago, mgutt said:

Das ist das schöne daran, wenn man Software und Datenbank trennt. Du könntest auch 1000 Nextcloud-Installationen mit einer Datenbank nutzen. Das ist nichts anderes als hättest du 1000 Nutzer auf einer Installation.

Naja das funktioniert nur bedingt gut, es hat schon einen Grund warum man dann ApplicationServer Cluster verwendet. Klar wenn die WebServer nur blöd die Daten persistieren ist das einfach aber sobald da etwas Logik mit ins Spiel kommst bist du da normalerweise raus aus so einer Nummer. Wir haben früher über das Prinzip Access Applicationen im Multiuser Betrieb gefahren, dass hat auch gut funktioniert aber machen würde ich das heute nicht mehr wollen. (Frontend Access + Backend AccessDB oder SQL bei 20-50 Usern relativ Problemlos und einfach) 

 

Kann man mal fragen was der Einsatzzweck ist Verein, Schule oder Firma?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.