Dimensionner les serveurs pour une grande migration

Ce que gère l'application
Le serveur Nextcloud
Limitation : 429 Too Many Requests
Où sont conservées les données au niveau des fichiers
Le serveur PostgreSQL
L'ordinateur Power BI
Le service Power BI
Dimensionner avant les grandes vagues

Ce que l'application prend en charge

L'application conserve une ligne par tâche et une ligne par exécution, chacune avec les décomptes de l'exécution (fichiers, versions, volume, problèmes), et non une ligne par fichier. Une exécution qui a déplacé un million de fichiers occupe une seule ligne dans Historique d'exécution. Le nombre de fichiers ne change donc rien pour l'application : 100 millions de fichiers et plus sont comptés sans qu'elle grossisse.

Ses tableaux sont filtrés, triés et paginés sur le serveur, et les chiffres du Tableau de bord sont calculés par la base de données. Chaque écran reste donc rapide, quelle que soit la taille de la migration. Ces performances ont été mesurées à cette échelle sur un petit serveur, doté de 2 processeurs virtuels et de 512 Mo pour PHP :

Élément	Mesuré avec
Tâches	25 000, réparties en 100 groupes et avec 50 étiquettes
Lignes de l'Historique d'exécution	75 000, et 225 000 pour la mémoire PHP nécessaire à un affichage
Problèmes de fichiers	200 000 et plus
Fichiers comptés par les exécutions	Au moins 100 millions ; seuls leurs décomptes sont stockés dans l'application
Jobs exécutés en même temps	4, le maximum que le serveur SMART Migration exécute
Mémoire PHP nécessaire par requête	Environ 140 Mo au maximum, pour l'onglet Tâches ; de 45 à 95 Mo pour les autres onglets. Voir Mémoire PHP par requête

L'application gère un nombre illimité de tâches, mais une tâche ne doit pas être trop volumineuse : une bibliothèque de plusieurs centaines de milliers ou de millions de fichiers doit être répartie en plusieurs tâches par dossier. Sinon, la tâche est lente et risque de ne pas aboutir. Voir Sources

Le serveur Nextcloud sur lequel les fichiers sont écrits se dimensionne en fonction des fichiers eux-mêmes, comme l'explique la section suivante.

Le serveur Nextcloud

SMART Migration écrit chaque fichier directement dans Nextcloud Files via WebDAV, en s'authentifiant avec un mot de passe d'application. L'application ne contient que les tâches et leurs résultats : les fichiers ne transitent donc jamais par elle. Chaque fichier, et chacune de ses versions, constitue une requête distincte. Le serveur Nextcloud se dimensionne donc en fonction du nombre de fichiers par heure que quatre tâches écrivent simultanément, et pas seulement du volume.

Élément	Pourquoi c'est important
Workers PHP	Chaque envoi mobilise un worker PHP pendant son écriture. S'il y en a trop peu, les requêtes s'accumulent dans une file d'attente : la migration ralentit, tout comme les pages de Nextcloud pour tous les autres utilisateurs
Redis	Nextcloud verrouille chaque fichier qu'il écrit. Si Redis assure le verrouillage des fichiers et la mise en cache, les verrous ne sollicitent pas la base de données
La base de données	Chaque fichier correspond à une ligne dans le cache de fichiers de Nextcloud, écrite à l'arrivée du fichier. Une base de données rapide sur SSD suit le rythme de nombreux petits fichiers
Stockage	Des disques rapides avec assez d'espace pour toute la migration, versions comprises, et des quotas sur les comptes de destination et les dossiers d'équipe qui laissent la place nécessaire
Limites de taille	Les limites de PHP, et celles de tout proxy placé devant Nextcloud, sur la taille et la durée d'une requête doivent permettre le passage des fichiers les plus volumineux
Mémoire PHP	Conservez `memory_limit` à 512 Mo, comme le recommande Nextcloud. La requête la plus lourde de l'application, l'onglet Tâches, en utilise environ 140 Mo, et Historique d'exécution lit ses exécutions par tranches, de sorte que ses affichages restent légers à mesure qu'il s'étoffe. Voir Performances et charge sur le serveur Nextcloud
Traitements à chaque envoi	L'analyse antivirus, le chiffrement côté serveur et les règles de contrôle d'accès aux fichiers allongent le temps de traitement de chaque fichier. Testez la vitesse avec ces fonctions activées, comme elles le seront pendant la migration

Limitation : 429 Too Many Requests

Nextcloud ne limite pas le nombre de fichiers qu'écrit un compte connecté. Sa protection contre la force brute vise plutôt à empêcher la devinette de mots de passe. Chaque échec de connexion depuis une adresse ralentit les requêtes suivantes provenant de cette adresse, y compris les requêtes valides. Au-delà d'un certain nombre, Nextcloud les refuse avec 429 Too Many Requests, pendant des heures. Comme le serveur SMART Migration se connecte depuis une seule adresse, cela arrête toutes les tâches, et l'application affiche Hors ligne, car le serveur ne peut plus joindre non plus l'API de l'application.

Un échec de connexion pendant une migration signifie généralement qu'un mot de passe ne fonctionne plus : un mot de passe d'application révoqué sous Paramètres → Sécurité, un mot de passe modifié pour le compte de service, ou le mot de passe d'application que l'application a émis pour une exécution dans les fichiers d'un utilisateur, utilisé après la fin de cette exécution. Voici comment l'éviter, et comment y remédier :

Corrigez d'abord le mot de passe
Donnez au serveur SMART Migration un mot de passe d'application valide. Tant qu'il continue d'en envoyer un qui échoue, Nextcloud continue de le limiter.
Ajoutez l'adresse du serveur à la liste d'autorisation
Dans Paramètres d'administration → Sécurité de Nextcloud, ajoutez l'adresse du serveur SMART Migration à la Liste d'autorisation anti-force brute et cochez Ignorer la limitation de débit pour les IP autorisées. Une adresse figurant sur la liste peut essayer des mots de passe sans être limitée : n'ajoutez donc que cette seule adresse fixe.
Débloquez une adresse déjà limitée
occ security:bruteforce:attempts <address> indique où en est la limitation, et occ security:bruteforce:reset <address> la supprime immédiatement.

Derrière un proxy, tous les clients partagent une même adresse

Lorsque Nextcloud se trouve derrière un proxy inverse sans que trusted_proxies soit défini dans sa configuration, il voit chaque client avec l'adresse du proxy. Un mauvais mot de passe saisi par n'importe quel utilisateur limite alors tout le monde, y compris le serveur SMART Migration. Définissez trusted_proxies, afin que Nextcloud voie l'adresse propre à chaque client.

Une erreur 429 peut aussi venir d'un élément placé devant Nextcloud : un proxy inverse, un pare-feu ou la protection d'un hébergeur qui limite les requêtes par adresse. Laissez-y également passer l'adresse du serveur SMART Migration. Une erreur 503 Service Unavailable signifie que Nextcloud est surchargé ou en mode maintenance. Voir Ce qu'implique une migration, et ce qui détermine sa vitesse

Où sont conservées les données au niveau des fichiers

Chaque fichier traité par une exécution d'Analyse ou de migration est enregistré dans la base de données de reporting PostgreSQL : son emplacement, sa taille, ses versions, ses dates, ses étiquettes, ses métadonnées et ce qu'il est advenu de lui. Ce sont les données que lit SMART BI.pbix, et celles qui augmentent avec la migration.

Elles augmentent à chaque exécution, et pas seulement à chaque fichier

Un fichier analysé, puis migré lors d'un test et une nouvelle fois pour de bon, est enregistré par chacune de ces exécutions. Les exécutions de rattrapage récurrentes s'y ajoutent également. Prévoyez la base de données de reporting pour les exécutions que le projet effectuera, et pas seulement pour les fichiers de la source.

Le serveur PostgreSQL

À partir de dizaines de millions de fichiers, la base de données de reporting constitue un serveur à part entière, et non un coin du serveur SMART Migration. Chaque exécution y écrit pendant toute la migration, et une actualisation dans Power BI y lit tout l'inventaire des fichiers en une seule fois.

	Point de départ pour 100 millions de fichiers	Pourquoi
Stockage	SSD ou NVMe rapide, avec plusieurs centaines de Go pour les données, leurs index et une marge de croissance	Les lignes de fichiers contiennent de longs chemins et des métadonnées ; des disques lents font attendre chaque actualisation et les écritures de chaque exécution
Mémoire	32 à 64 Go	Pour que les index et les données les plus lues restent en mémoire
Processeur	8 cœurs ou plus	Les exécutions écrivent pendant que les actualisations lisent
Réseau	Une liaison rapide vers le serveur SMART Migration et vers les ordinateurs qui actualisent le rapport	Une actualisation y fait transiter tout l'inventaire

Il s'agit de points de départ : le besoin réel dépend des métadonnées que portent les sources et du nombre d'exécutions par fichier. Un service PostgreSQL hébergé convient aussi, dimensionné de la même façon. Sauvegardez la base de données comme toute base de production : c'est l'historique de la migration.

L'ordinateur Power BI

Power BI Desktop importe les données du rapport dans la mémoire de l'ordinateur : tant que SMART BI.pbix est ouvert, tout l'inventaire des fichiers qu'il contient se trouve en RAM, et une actualisation nécessite jusqu'au double, le temps que la nouvelle copie soit construite à côté de l'ancienne. Les longues colonnes de texte (chemins et noms de fichiers) se compressent le moins bien et en occupent la plus grande part.

Le minimum de Microsoft concerne le programme, pas ces données

Microsoft demande 2 Go de mémoire, 4 Go recommandés, pour exécuter Power BI Desktop. Cela permet d'ouvrir le programme, pas de contenir un inventaire de fichiers de dizaines de millions de lignes. Pour une migration de cette taille, un ordinateur doté de 64 à 96 Go de mémoire n'a rien d'inhabituel.

Fichiers dans le rapport	Mémoire, comme point de départ approximatif
Quelques millions	16 à 32 Go
Des dizaines de millions	64 Go
100 millions et plus	64 à 96 Go, ou plus

Windows 64 bits et Power BI Desktop 64 bits, un processeur rapide doté de nombreux cœurs, et un SSD.
Actualisez là où se trouve la mémoire : un seul ordinateur bien équipé, ou une machine virtuelle dimensionnée en conséquence, actualise le rapport et le téléverse dans Nextcloud ; tous les autres ouvrent le fichier téléversé. L'ouverture demande moins de ressources que l'actualisation.
Limitez le rapport à ce dont vous avez besoin : omettez les colonnes qu'aucune page n'utilise, ou filtrez les données sur les vagues ou les sites concernés. Voir Adapter le rapport SMART BI à vos besoins

Le service Power BI

Une fois publié dans le service Power BI, le modèle sémantique du rapport a le même appétit, et la licence en fixe le plafond. Avec Power BI Pro, un modèle sémantique peut contenir au maximum 1 Go. Sur une capacité Premium ou Fabric, avec le format de stockage des grands modèles sémantiques, un modèle peut atteindre la mémoire de la capacité :

Capacité Fabric	Mémoire maximale pour un modèle sémantique
F32	10 Go
F64	25 Go
F128	50 Go
F256	100 Go

Une actualisation peut nécessiter le double de la taille du modèle : un modèle proche de la moitié de la mémoire de la capacité risque donc de ne pas pouvoir être actualisé. Les limites de Microsoft évoluent : vérifiez-les dans sa documentation avant de choisir une capacité. Rien dans SMART Migration ne nécessite le service ; Power BI Desktop est gratuit pour tous. Voir Power BI pour les débutants

Dimensionner avant les grandes vagues

Les chiffres ci-dessus sont indicatifs. La taille qui compte est la vôtre, et un pilote permet de la connaître :

Analysez une partie représentative
Lancez une Analyse sur quelques sites, OneDrive et partages qui ressemblent au reste, et pas seulement sur les plus petits.
Actualisez le rapport et mesurez
Actualisez SMART BI.pbix dans Power BI Desktop et notez la mémoire qu'il occupe dans le Gestionnaire des tâches de Windows, la taille du fichier et celle de la base de données de reporting.
Extrapolez à l'ensemble de la migration
Multipliez par le nombre de fichiers de l'ensemble de la migration, en tenant compte des exécutions que chaque fichier connaîtra, et dimensionnez le serveur PostgreSQL et l'ordinateur Power BI avant le début des grandes vagues.

Voir aussi