Un développeur doit-il garder les bases de données sur le nœud de calcul ou sur le nœud de stockage ?
Par défaut, conservez les fichiers actifs de la base de données sur un stockage à faible latence, à proximité des ressources de calcul, puis utilisez le nœud de stockage pour les sauvegardes, les vidages, les réplicas et les archives.
Cette règle par défaut change si le nœud de stockage fournit un chemin de stockage bloc conçu à cet effet, avec une latence mesurée, des garanties de durabilité correctes et un avantage en matière de reprise qui justifie la dépendance supplémentaire. Le choix ne se résume pas à opposer capacité locale et capacité réseau : les journaux de transactions, les fichiers de données, les sauvegardes, les téléversements de l’application et les bases de données de test temporaires ont des profils d’écriture et des conséquences en cas de panne différents.
Séparer l’état de la base de données des vidages et des sauvegardes
Cartographiez tous les chemins liés aux bases de données avant de choisir un nœud. Le répertoire de données principal et le journal des transactions contiennent l’état actif ; ils nécessitent un ordre d’écriture cohérent et une latence prévisible. Les vidages logiques, les sauvegardes de base, les journaux archivés, les exportations et les fichiers téléversés par l’application ont des profils d’accès différents et peuvent souvent transiter par le réseau sans risque.
Ne montez pas un seul partage NAS pour tout y placer. Séparez le volume de base de données actif des destinations de sauvegarde et des données applicatives volumineuses. Vous pourrez ainsi régler, surveiller, remplir, créer des instantanés, restaurer et migrer chaque rôle indépendamment, sans prétendre que tous les octets persistants nécessitent le même support.
Pour les bases de données de branche éphémères ou les tests CI, le temps de reconstruction peut compter davantage que la durabilité. Placez-les sur un stockage local temporaire rapide et recréez-les à partir des migrations ou de jeux de données initiaux expurgés. Pour la base de données de service quotidienne d’un développeur, considérez la panne d’un SSD local comme un incident nécessitant une restauration et veillez à ce que la copie distante soit suffisamment à jour pour respecter l’objectif de point de reprise déclaré.
Mesurer le chemin d’écriture avant de choisir un nœud
Les performances d’une base de données dépendent de bien plus que du débit séquentiel. Mesurez la latence des validations synchrones, les lectures et écritures aléatoires, la profondeur de file d’attente pendant les sauvegardes et le comportement en cas de blocage du chemin réseau. Une liaison 10GbE peut transférer rapidement de gros fichiers tout en ajoutant de la latence et un point de défaillance supplémentaire à chaque transaction.
Une comparaison publiée de PostgreSQL a montré que le NVMe local offrait une latence plus faible et plus prévisible que les services infonuagiques testés de stockage connecté au réseau, tout en soulignant les avantages de ce dernier en matière d’élasticité et de durabilité. Ces benchmarks PostgreSQL en local et sur stockage connecté au réseau ne garantissent pas les mêmes résultats dans un laboratoire domestique, mais ils montrent pourquoi le choix de l’emplacement d’une base de données doit s’appuyer sur des mesures de charge de travail plutôt que sur le seul débit de l’interface.
Effectuez un test représentatif avec le même système de fichiers, les mêmes paramètres de synchronisation, la même version de la base de données, le même jeu de données et le même niveau de concurrence que ceux prévus pour le service. Pendant le test, lancez une sauvegarde volumineuse ou un transfert de fichiers multimédias sur le réseau de stockage. Si la latence de queue ou la durée des commits devient erratique, la capacité centralisée ne compense pas le partage du chemin d’accès.
Par défaut, placez les fichiers principaux de la base de données près du nœud de calcul
Pour un développeur, un nœud de calcul et des bases de données modestes, des SSD locaux en miroir ou un volume local récupérable offrent généralement la gestion la plus claire. Le processus de la base de données, ses fichiers de données et son journal de préécriture tombent en panne ensemble, tandis que le nœud de stockage reçoit les sauvegardes via un processus adapté aux bases de données, au lieu d’héberger à distance un système de fichiers constamment ouvert.
Un stockage local ne signifie pas qu’il faille utiliser un unique lecteur de démarrage sans protection. Dans la mesure du possible, séparez le volume de la base de données du système d’exploitation, surveillez l’espace libre et l’état des lecteurs, réservez de la capacité pour les opérations de maintenance et exportez les sauvegardes avant les mises à niveau. Fixez l’emplacement des conteneurs ou des machines virtuelles afin qu’un ordonnanceur ne démarre pas la base de données sur un autre nœud sans son état.
N’utilisez le stockage local que si le processus de récupération est bien défini. Si le remplacement du nœud de calcul vous oblige à vous rabattre sur une copie obsolète, le stockage centralisé risque de mettre au jour une défaillance existante des sauvegardes plutôt que de la provoquer. Corrigez le processus de sauvegarde et de restauration avant d’optimiser le chemin d’accès aux données.
Utilisez le nœud de stockage pour les sauvegardes, les répliques et les archives
Un nœud de stockage est utile lorsqu’il reçoit des exports cohérents avec les applications, des sauvegardes de base, des journaux de transactions archivés, des instantanés immuables ou une réplique de base de données ayant son propre objectif de récupération. Il peut également héberger de volumineuses pièces jointes ou des exports analytiques, tandis que le catalogue et les journaux de la base de données, sensibles à la latence, restent en local.
| Rôle des données | Emplacement par défaut | Pourquoi | Test requis |
|---|---|---|---|
| Données principales et journal des transactions | SSD du nœud de calcul | Chemin d’écriture le plus rapide et le plus prévisible | Latence des commits et récupération après incident |
| Sauvegardes logiques | Nœud de stockage | Source de restauration portable et tenant compte des versions | Restaurer dans une base de données vide |
| Sauvegarde de base et journaux archivés | Nœud de stockage | Récupération à un instant précis | Récupérer à un horodatage précis |
| Réplique en lecture | Nœud choisi, avec son propre volume | Mise à l’échelle en lecture ou option de reprise | Procédure de retard et de promotion |
| Téléversements, exportations et analyses à froid | Nœud de stockage | La capacité compte davantage que la latence des transactions | Impact des transferts simultanés |
Les tests de la communauté de PostgreSQL sur NFS sur un serveur de stockage ont donné des résultats contre-intuitifs et soulevé des questions de configuration, plutôt que d’apporter une réponse universelle. C’est pourquoi le stockage distant principal doit être considéré comme une exception conçue à dessein : validez le comportement synchrone, la gestion des pannes, les options de montage, la sémantique du cache et la reprise sur la pile exacte.
Valider la reprise après incident et le seuil de migration
Testez quatre événements : redémarrez la base de données proprement, faites planter le nœud de calcul pendant des écritures, interrompez la liaison de stockage pendant une sauvegarde et restaurez sur un hôte vierge. Vérifiez le point de reprise, le délai de reprise, les contrôles d’intégrité de la base de données et le comportement de reconnexion de l’application. Un benchmark rapide en fonctionnement normal ne garantit pas la sûreté du chemin d’écriture en cas d’interruption.
La configuration est validée si les données actives bénéficient d’une latence prévisible, si les sauvegardes ne peuvent ni écraser le système principal ni le bloquer, et si un nœud de calcul de remplacement peut être restauré sans dépendre d’hypothèses de stockage non documentées. Déplacez les fichiers principaux vers un service de stockage conçu à cet effet uniquement si les avantages mesurés en matière de reprise ou de mobilité l’emportent sur la dépendance au réseau ; rapatriez-les en local si la latence de queue ou les interruptions de liaison deviennent la principale source d’incidents.
Pour choisir l’architecture générale, la comparaison ZimaSpace entre un NAS axé sur le stockage et un serveur domestique axé sur le calcul aide à déterminer quel rôle doit rester stable malgré l’évolution des charges de travail des développeurs.
Règle finale de configuration
Par défaut, utilisez un SSD local protégé pour les fichiers de base de données actifs et le nœud de stockage pour les sauvegardes vérifiées, les archives et les répliques sélectionnées. N’optez pour un stockage distant principal qu’après avoir mesuré sa sémantique d’écriture, sa latence de queue, son comportement en cas de panne et ses avantages en matière de reprise.
Produits recommandés
Configuration de NAS et de serveur
À lire aussi
Un serveur de dortoir peut-il fonctionner assez silencieusement pour dormir, étudier et passer des appels vidéo ?
Oui, un serveur dans une chambre universitaire peut rester discret si le matériel consomme peu, si les vibrations des disques de stockage sont maîtrisées,...
Un homelab étudiant qui passe de la chambre universitaire au premier appartement
Gardez un homelab étudiant portable en séparant les services du réseau propre à chaque pièce, en réduisant le matériel au minimum, en sauvegardant son...
Comment partager un serveur domestique avec des colocataires sans partager de comptes ni de fichiers privés
Attribuez à chaque colocataire une identité nominative, un espace de stockage privé et uniquement les rôles partagés dont il a besoin ; séparez l’administration,...
