Serveurs de bases de données en Allemagne

Héberger une base de données sur Wolkra, c'est faire tourner PostgreSQL, MySQL, MariaDB, Redis ou une autre base de données sur votre propre serveur cloud à Francfort, idéalement une offre optimisée mémoire dans un réseau privé, avec des données qui ne quittent jamais l'Allemagne.

Vous maîtrisez la version, la configuration et les extensions, et vous payez un prix de serveur horaire fixe.

Usages adaptés

• Bases de données applicatives pour sites web, produits SaaS et outils internes.
• Caches et files d'attente avec Redis ou équivalent.
• Moteurs de recherche et d'analyse qui ont besoin de beaucoup de mémoire.
• Réplicas pour le reporting ou la bascule.

Toute base de données qui tourne sous Linux tourne sur un VPS KVM. Partez d'Ubuntu, Debian, AlmaLinux ou Rocky Linux et installez-la depuis les paquets officiels du projet, ou faites-la tourner dans un conteneur avec l'application Docker.

Choisir une offre

Les bases de données aiment la mémoire. Quand les données que vous interrogez le plus tiennent en RAM, les lectures se font depuis la mémoire plutôt que depuis le disque.

• Optimisée mémoire (m) : le choix par défaut pour les bases de données de production.
• Standard (s) : petites bases de données applicatives, développement et préproduction.
• Optimisée CPU (c) : charges riches en requêtes avec un petit jeu de données.

La facturation se fait par heure entamée, avec un plafond mensuel égal au prix mensuel. Passez à une offre supérieure pour plus de mémoire à mesure que vos données grandissent. Le disque peut grandir, jamais rétrécir.

Une architecture de base de données sécurisée

Réseau privé uniquement

Créez un réseau privé et rattachez-y la base de données et les serveurs d'application. La base de données n'écoute que sur son adresse privée et n'a pas d'IP publique. Les serveurs d'application s'y connectent en privé. Les administrateurs y accèdent via un VPN WireGuard ou un tunnel SSH.

Quand le serveur de base de données a besoin de paquets et de mises à jour, une passerelle NAT lui donne un accès Internet sortant sans l'ouvrir au trafic entrant.

Pare-feu

Attachez un pare-feu gratuit avec état qui n'autorise le port de la base de données que depuis vos serveurs d'application. Les règles de pare-feu peuvent cibler des sélecteurs de labels : les nouveaux serveurs d'application sont donc autorisés automatiquement dès que vous leur attribuez le label.

Chiffrement et comptes

• Utilisez TLS pour les connexions entre serveurs si vos exigences de conformité l'imposent.
• Créez un utilisateur de base de données par application, avec uniquement les droits nécessaires.
• N'utilisez jamais le superutilisateur de la base de données depuis une application.

Stockage

Placez le répertoire de données sur un volume de stockage en bloc :

• Tailles de 10 GB à 10 TB, facturées au GB et par mois.
• Agrandissez-le à chaud lorsqu'il se remplit.
• Détachez-le et attachez-le à un nouveau serveur plus puissant lors d'une mise à niveau.
• Il peut être formaté et monté pour vous lors de l'attachement.

Des sauvegardes qui se restaurent vraiment

Une sauvegarde de base de données ne vaut que par votre dernier test de restauration. Procédez par couches :

1. Sauvegardes quotidiennes du serveur pour 20 % du prix du serveur, avec 7 points de restauration. Voir sauvegardes et instantanés.
2. Dumps logiques avec pg_dump, mysqldump ou l'outil propre à votre base de données, à intervalles réguliers.
3. Copies hors du serveur de ces dumps, pour qu'une seule panne de serveur ne puisse pas tout emporter.
4. Instantanés avant les mises à jour du moteur de base de données ou les migrations de schéma.
5. Tests de restauration réguliers sur un serveur temporaire, supprimé ensuite. La facturation à l'heure rend cela peu coûteux.

Notre guide de stratégie de sauvegarde va plus loin.

Haute disponibilité

Pour plus d'un serveur de base de données :

• Faites tourner un primaire et des réplicas avec la réplication native de la base de données.
• Utilisez des groupes de placement pour les garder sur des hôtes différents.
• Déplacez une IP flottante vers le nouveau primaire lors d'une bascule, ou faites pointer les applications vers un répartiteur de charge dont les health checks atteignent les serveurs purement privés.

Données en Allemagne

Votre base de données, vos volumes, vos sauvegardes et vos instantanés restent à Francfort. Pour les données personnelles, le stockage reste ainsi dans l'UE et votre registre RGPD s'en trouve simplifié. Voir VPS européen et RGPD et hébergement conforme au RGPD en Allemagne.

Suivre les performances

La console affiche des graphiques CPU, disque et réseau pour chaque serveur. Une activité disque croissante à trafic constant signifie souvent que le jeu de données de travail ne tient plus en mémoire et qu'il est temps de passer à une offre plus grande. Voir supervision.

Bases de l'optimisation

Réglez les paramètres mémoire de la base de données en fonction de l'offre, y compris après un changement d'offre. Activez la journalisation des requêtes lentes et ajoutez des index avant d'ajouter du matériel.

Trafic

La réplication, les sauvegardes vers d'autres emplacements et les exports volumineux déplacent beaucoup de données. Le trafic est non mesuré avec usage raisonnable, sur des ports jusqu'à 10 Gbit/s, partagés : rien de tout cela n'entraîne de frais au GB. Voir réseau.

Lancez un serveur de base de données

Créez un compte, créez un réseau privé et lancez un serveur optimisé mémoire à Francfort pour vos données.