Die Server für eine große Migration dimensionieren

Was die App bewältigt
Der Nextcloud-Server
Drosselung: 429 Too Many Requests
Wo die Daten auf Dateiebene gespeichert werden
Der PostgreSQL-Server
Der Power BI-Computer
Der Power BI-Dienst
Vor den großen Wellen dimensionieren

Was die App verarbeitet

Die App führt eine Zeile pro Job und eine Zeile pro Lauf, jeweils mit den Zählwerten des Laufs – Dateien, Versionen, Volumen, Probleme – und keine Zeile pro Datei. Ein Lauf, der eine Million Dateien übertragen hat, ist eine einzige Zeile im Laufverlauf. Die Anzahl der Dateien spielt für die App daher keine Rolle: 100 Millionen Dateien und mehr werden gezählt, ohne dass die App wächst.

Ihre Tabellen werden auf dem Server gefiltert, sortiert und seitenweise geladen, und die Kennzahlen der Übersicht zählt die Datenbank. Dadurch bleibt jede Ansicht schnell, wie groß die Migration auch wird. Gemessen wurde in dieser Größenordnung auf einem kleinen Server mit 2 virtuellen CPUs und 512 MB für PHP:

Was	Gemessen mit
Jobs	25.000, in 100 Gruppen und mit 50 Tags
Zeilen im Laufverlauf	75.000 – und 225.000 für den PHP-Speicher, den eine Ansicht benötigt
Dateiprobleme	200.000 und mehr
Von den Läufen gezählte Dateien	Mindestens 100 Millionen – in der App stehen nur ihre Zählwerte
Gleichzeitig laufende Jobs	4, die Höchstzahl, die der SMART-Migration-Server ausführt
PHP-Speicher, den eine Anfrage benötigt	Höchstens etwa 140 MB für den Tab Aufträge; 45 bis 95 MB für die anderen Tabs. Siehe PHP-Speicher pro Anfrage

Die App verarbeitet beliebig viele Jobs, ein einzelner Job sollte jedoch nicht zu groß sein: Eine Bibliothek mit Hunderttausenden oder Millionen von Dateien wird nach Ordnern auf mehrere Jobs aufgeteilt. Andernfalls ist der Job langsam und wird möglicherweise nicht abgeschlossen. Siehe Quellen

Der Nextcloud-Server, auf den die Dateien geschrieben werden, wird für die Dateien selbst dimensioniert, wie der nächste Abschnitt erläutert.

Der Nextcloud-Server

SMART Migration schreibt jede Datei direkt per WebDAV in Nextcloud Files und meldet sich dabei mit einem App-Passwort an. Die App enthält nur die Jobs und ihre Ergebnisse, die Dateien laufen also nie über sie. Jede Datei und jede ihrer Versionen ist eine eigene Anfrage. Der Nextcloud-Server wird daher für die Anzahl der Dateien pro Stunde dimensioniert, die vier Jobs gleichzeitig schreiben, und nicht nur für das Volumen.

Was	Warum es wichtig ist
PHP-Worker	Jeder Upload belegt einen PHP-Worker, während er geschrieben wird. Sind es zu wenige, stauen sich die Anfragen: Die Migration wird langsamer, und ebenso die Seiten von Nextcloud für alle anderen Benutzer
Redis	Nextcloud sperrt jede Datei, die es schreibt. Mit Redis für Dateisperren und Caching bleiben die Sperren außerhalb der Datenbank
Die Datenbank	Jede Datei ist eine Zeile im Datei-Cache von Nextcloud, die beim Eintreffen der Datei geschrieben wird. Eine schnelle Datenbank auf SSD hält mit vielen kleinen Dateien Schritt
Speicher	Schnelle Datenträger mit Platz für die gesamte Migration einschließlich der Versionen sowie Kontingente für die Zielkonten und Team-Ordner, die dafür Platz lassen
Größenbeschränkungen	Die Grenzwerte von PHP und eines etwaigen Proxys vor Nextcloud für Größe und Dauer einer Anfrage müssen die größten Dateien zulassen
PHP-Speicher	Belassen Sie `memory_limit` bei 512 MB, wie von Nextcloud empfohlen. Die größte Anfrage der App, der Tab Aufträge, benötigt davon etwa 140 MB, und der Laufverlauf liest seine Läufe abschnittsweise, sodass seine Ansichten auch bei wachsendem Umfang klein bleiben. Siehe Leistung und Last auf dem Nextcloud-Server
Verarbeitung bei jedem Upload	Virenscans, serverseitige Verschlüsselung und Regeln der Dateizugriffskontrolle verlängern die Verarbeitung jeder Datei. Testen Sie die Geschwindigkeit mit diesen Funktionen eingeschaltet, so wie sie es während der Migration sein werden

Drosselung: 429 Too Many Requests

Nextcloud begrenzt nicht, wie viele Dateien ein angemeldetes Konto schreibt. Sein Brute-Force-Schutz richtet sich stattdessen gegen das Erraten von Passwörtern. Jede fehlgeschlagene Anmeldung von einer Adresse verlangsamt die nächsten Anfragen von dieser Adresse, auch die gültigen. Nach zu vielen Fehlversuchen lehnt Nextcloud sie stundenlang mit 429 Too Many Requests ab. Da sich der SMART Migration-Server von einer einzigen Adresse aus anmeldet, stoppt dies jeden Job, und die App zeigt Offline an, weil der Server auch die API der App nicht mehr erreicht.

Eine fehlgeschlagene Anmeldung während einer Migration bedeutet meist ein Passwort, das nicht mehr funktioniert: ein unter Einstellungen → Sicherheit widerrufenes App-Passwort, ein geändertes Passwort des Dienstkontos oder das App-Passwort, das die App für einen Lauf in die Dateien eines Benutzers ausgestellt hat und das nach dem Ende des Laufs verwendet wurde. So beugen Sie dem vor und beheben es:

Zuerst das Passwort korrigieren
Geben Sie dem SMART Migration-Server ein funktionierendes App-Passwort. Solange er weiterhin eines sendet, das fehlschlägt, drosselt Nextcloud ihn weiter.
Die Adresse des Servers auf die Zulassungsliste setzen
Fügen Sie in Nextcloud unter Verwaltungseinstellungen → Sicherheit die Adresse des SMART Migration-Servers zur Brute-Force-Zulassungsliste hinzu und aktivieren Sie Ratenbegrenzung für zugelassene IPs umgehen. Eine Adresse auf der Liste kann Passwörter ausprobieren, ohne gedrosselt zu werden. Fügen Sie daher nur diese eine feste Adresse hinzu.
Eine bereits gedrosselte Adresse freigeben
occ security:bruteforce:attempts <address> zeigt, wie weit die Drosselung fortgeschritten ist, und occ security:bruteforce:reset <address> hebt sie sofort auf.

Hinter einem Proxy teilen sich alle Clients eine Adresse

Steht Nextcloud hinter einem Reverse Proxy, ohne dass trusted_proxies in der Konfiguration gesetzt ist, sieht es jeden Client mit der Adresse des Proxys. Ein falsches Passwort, das irgendein Benutzer eingibt, drosselt dann alle, auch den SMART Migration-Server. Setzen Sie trusted_proxies, damit Nextcloud die eigene Adresse jedes Clients sieht.

Ein 429 kann auch von einer Komponente vor Nextcloud stammen: einem Reverse Proxy, einer Firewall oder einem Schutzmechanismus des Hosting-Anbieters, der Anfragen pro Adresse begrenzt. Lassen Sie die Adresse des SMART Migration-Servers auch dort durch. Ein 503 Service Unavailable bedeutet, dass Nextcloud überlastet ist oder sich im Wartungsmodus befindet. Siehe Was eine Migration umfasst und was ihre Geschwindigkeit bestimmt

Wo die Daten auf Dateiebene gespeichert werden

Jede Datei, die ein Analyse- oder Migrationslauf verarbeitet, wird in der PostgreSQL-Berichtsdatenbank erfasst: wo sie liegt, ihre Größe, Versionen, Datumsangaben, Bezeichnungen, Metadaten und was mit ihr geschehen ist. Das sind die Daten, die SMART BI.pbix liest, und die Daten, die mit der Migration wachsen.

Sie wachsen mit jedem Lauf, nicht nur mit jeder Datei

Eine Datei, die analysiert, dann in einem Test migriert und noch einmal endgültig migriert wird, wird von jedem dieser Läufe erfasst. Auch wiederkehrende Nachhol-Läufe tragen dazu bei. Planen Sie die Berichtsdatenbank für die Läufe, die das Projekt durchführen wird, und nicht nur für die Dateien in der Quelle.

Der PostgreSQL-Server

Bei zig Millionen Dateien ist die Berichtsdatenbank ein eigener Server und keine Nebenaufgabe des SMART Migration-Servers. Jeder Lauf schreibt während der Migration in sie, und eine Aktualisierung in Power BI liest das gesamte Dateiinventar auf einmal aus ihr.

	Ausgangspunkt bei 100 Millionen Dateien	Warum
Speicher	Schnelle SSD oder NVMe mit mehreren Hundert GB für die Daten, ihre Indizes und Reserve für Wachstum	Die Dateizeilen enthalten lange Pfade und Metadaten; langsame Datenträger lassen jede Aktualisierung und die Schreibvorgänge jedes Laufs warten
Arbeitsspeicher	32–64 GB	Damit die Indizes und die am häufigsten gelesenen Daten im Arbeitsspeicher bleiben
Prozessor	8 Kerne oder mehr	Läufe schreiben, während Aktualisierungen lesen
Netzwerk	Eine schnelle Verbindung zum SMART Migration-Server und zu den Computern, die den Bericht aktualisieren	Eine Aktualisierung überträgt das gesamte Inventar darüber

Dies sind Ausgangswerte: Der tatsächliche Bedarf hängt von den Metadaten der Quellen ab und davon, wie viele Läufe jede Datei durchläuft. Ein gehosteter PostgreSQL-Dienst eignet sich ebenso, gleich dimensioniert. Sichern Sie die Datenbank wie jede Produktivdatenbank: Sie ist die Dokumentation der Migration.

Der Power BI-Computer

Power BI Desktop importiert die Daten des Berichts in den Arbeitsspeicher des Computers: Solange SMART BI.pbix geöffnet ist, liegt das gesamte darin enthaltene Dateiinventar im RAM, und eine Aktualisierung benötigt bis zum Doppelten davon, während die neue Kopie neben der alten aufgebaut wird. Lange Textspalten – Pfade und Dateinamen – lassen sich am schlechtesten komprimieren und belegen den größten Teil davon.

Das Minimum von Microsoft gilt für das Programm, nicht für diese Daten

Microsoft verlangt für Power BI Desktop 2 GB Arbeitsspeicher, empfohlen sind 4 GB. Damit lässt sich das Programm öffnen; ein Dateiinventar mit zig Millionen Zeilen fasst es nicht. Für eine Migration dieser Größe ist ein Computer mit 64–96 GB Arbeitsspeicher nicht ungewöhnlich.

Dateien im Bericht	Arbeitsspeicher, als grober Ausgangswert
Einige Millionen	16–32 GB
Zig Millionen	64 GB
100 Millionen und mehr	64–96 GB oder mehr

64-Bit-Windows und das 64-Bit-Power BI Desktop, ein schneller Prozessor mit vielen Kernen und eine SSD.
Dort aktualisieren, wo der Arbeitsspeicher ist: Ein gut ausgestatteter Computer oder eine entsprechend dimensionierte virtuelle Maschine aktualisiert den Bericht und lädt ihn in Nextcloud hoch; alle anderen öffnen die hochgeladene Datei. Das Öffnen benötigt weniger als das Aktualisieren.
Den Bericht auf das Nötige beschränken: Lassen Sie Spalten weg, die keine Seite verwendet, oder filtern Sie die Daten auf die betreffenden Wellen oder Websites. Siehe Den SMART BI-Bericht an Ihre Bedürfnisse anpassen

Der Power BI-Dienst

Im Power BI-Dienst veröffentlicht, hat das semantische Modell des Berichts denselben Bedarf, und die Lizenz legt die Obergrenze fest. Mit Power BI Pro kann ein semantisches Modell höchstens 1 GB umfassen. Auf einer Premium- oder Fabric-Kapazität kann ein Modell mit dem Speicherformat für große semantische Modelle bis zum Arbeitsspeicher der Kapazität wachsen:

Fabric-Kapazität	Maximaler Arbeitsspeicher für ein semantisches Modell
F32	10 GB
F64	25 GB
F128	50 GB
F256	100 GB

Eine Aktualisierung kann das Doppelte der Modellgröße benötigen, sodass die Aktualisierung eines Modells, das sich der Hälfte des Arbeitsspeichers der Kapazität nähert, fehlschlagen kann. Die Grenzwerte von Microsoft ändern sich: Prüfen Sie sie in der Dokumentation von Microsoft, bevor Sie eine Kapazität wählen. SMART Migration benötigt den Dienst nicht; Power BI Desktop ist für alle kostenlos. Siehe Power BI für Einsteiger

Vor den großen Wellen dimensionieren

Die obigen Zahlen sind ein Richtwert. Entscheidend ist Ihre eigene Größenordnung, und ein Pilot zeigt sie:

Einen repräsentativen Teil analysieren
Führen Sie Analyse für einige Websites, OneDrives und Freigaben aus, die dem Rest ähneln – nicht nur für die kleinsten.
Den Bericht aktualisieren und messen
Aktualisieren Sie SMART BI.pbix in Power BI Desktop und notieren Sie den belegten Arbeitsspeicher im Windows-Task-Manager, die Größe der Datei und die Größe der Berichtsdatenbank.
Auf die gesamte Migration hochrechnen
Multiplizieren Sie mit den Dateien der gesamten Migration und den Läufen, die jede Datei durchlaufen wird, und dimensionieren Sie den PostgreSQL-Server und den Power BI-Computer, bevor die großen Wellen beginnen.

Siehe auch