Bases relationnelles : Azure SQL, instance managée, machine virtuelle

Le registre des manifestes

Sur un terminal à conteneurs, la marchandise ne vaut rien sans son registre. Chaque boîte y a sa ligne : numéro, propriétaire, contenu déclaré, date d'entrée, position sur le parc.

Perds un portique, tu perds une journée de cadence. Perds le registre, et tu as quarante mille conteneurs empilés devant toi dont plus personne ne sait à qui ils appartiennent.

Ce registre est tenu ligne à ligne, avec des colonnes fixes et des règles qui ne se négocient pas : pas de conteneur sans propriétaire connu, pas de sortie sans entrée correspondante. C'est le contrat d'une base relationnelle, et c'est pour cela qu'on continue d'en poser au centre des systèmes.

Reste la vraie question du locataire de quai : qui tient le registre, et dans quels locaux. Le bureau du terminal peut s'en charger entièrement. Tu peux aussi installer ton propre bureau dans l'enceinte du port. Ou monter tes armoires dans un hangar que tu loues vide.

Azure propose ces trois formules, et le choix se tranche sur une seule question : de quelle compatibilité et de quel contrôle as-tu réellement besoin ? Vient ensuite le modèle d'achat, qui décide de la facture, puis le dispositif de continuité, qui décide de ce qui se passe le jour où la région tombe. La sécurité se pose à la fin, et elle se pose à peu près pareil dans les trois cas.

Le service qui héberge ta base fige deux choses difficiles à reprendre : ce que le moteur sait faire, et ce que ton équipe devra exploiter tous les jours.

Trois façons de tenir le registre

Le bureau du terminal tient le registre pour tout le monde, avec ses procédures et ses horaires : rien à recruter, mais tu ne décides ni du format des colonnes ni de l'heure de la clôture. Ton propre bureau dans l'enceinte du port garde tes habitudes et ton personnel, en profitant des services communs. Le hangar loué vide, lui, ne t'impose rien et ne te fournit rien.

Les trois formules Azure suivent exactement cette pente.

La base managée

Azure SQL Database héberge une base, pas un serveur. La plateforme applique les correctifs, sauvegarde, surveille et bascule sans te prévenir, et tu n'as accès ni au système d'exploitation ni à l'instance.

Ce que tu perds est précis, et c'est ce qui fait échouer les migrations menées sans inventaire : pas d'agent SQL Server pour planifier des travaux, pas de requêtes entre bases sur le même serveur logique, pas de serveurs liés, pas de messagerie de base de données, pas de code CLR, pas de restauration native d'un fichier de sauvegarde .bak.

Pour une application écrite pour le cloud, ces absences ne se remarquent pas : la planification passe dans une automatisation externe, les échanges entre bases passent par l'application. Pour un existant de quinze ans, chacune peut être un chantier.

L'instance managée

Azure SQL Managed Instance expose une instance complète, déployée dans un sous-réseau de ton réseau virtuel. La surface du moteur y est presque celle d'un SQL Server installé à la main : agent, requêtes et transactions entre bases, serveurs liés, Service Broker, CLR, réplication transactionnelle, et surtout la restauration native d'une sauvegarde déposée dans un stockage d'objets.

C'est la formule des reprises d'existant, pour cette dernière raison autant que pour les autres. Le prix à payer se voit dans l'exploitation : les opérations de création et de redimensionnement d'une instance se comptent en dizaines de minutes, pas en secondes, et l'instance consomme un plan d'adressage dans ton réseau virtuel.

Le moteur sur machine virtuelle

Tu installes SQL Server sur une machine virtuelle et tu hérites de tout : la version exacte, les composants tiers sur la même machine, les fonctionnalités que les deux formules précédentes ne portent pas.

Tu hérites aussi du reste. Les correctifs du système et du moteur, le dimensionnement des disques, la haute disponibilité à construire toi-même avec des groupes de disponibilité ou une instance de cluster de basculement, la sauvegarde à planifier et à vérifier. L'extension d'agent SQL pour machines virtuelles automatise une partie de ce travail, elle ne le supprime pas.

Un détail qui décide de la moitié des performances observées : les disques. Fichiers de données et journal des transactions sur des disques distincts, mise en cache de l'hôte en lecture seule pour les données et désactivée pour le journal, et surtout ne jamais poser un fichier de base sur le disque temporaire de la machine, dont le contenu ne survit pas à un déplacement de l'hôte.

La compatibilité ne se devine pas, elle s'inventorie. Liste les travaux planifiés, les serveurs liés et les requêtes inter-bases avant de choisir la formule, pas après la première migration de test.

Le modèle d'achat

Une concession portuaire se paie soit au forfait, soit au détail des moyens mobilisés. Le forfait est simple à signer et impossible à discuter ligne par ligne. Le détail demande de savoir ce qu'on consomme, et permet de négocier.

Azure SQL propose les deux, et le second est devenu la voie normale.

Unités de transaction ou cœurs virtuels

Le modèle en unités de transaction achète un forfait qui mêle processeur, mémoire et entrées-sorties dans une seule valeur, avec des niveaux nommés de base à premium. Simple à commander, opaque à diagnostiquer : quand la base sature, la métrique ne te dit pas laquelle des trois ressources manque.

Le modèle en cœurs virtuels sépare les postes. Tu choisis la configuration matérielle et le nombre de cœurs, tu dimensionnes le stockage à part, et les sauvegardes apparaissent comme une ligne distincte.

L'instance managée n'existe qu'en cœurs virtuels. Si tu comptes migrer un jour dans cette direction, commencer en unités de transaction ajoute une conversion inutile.

Les niveaux de service

Le niveau de service décide d'où vivent les fichiers, et donc du comportement en cas de panne.

La conséquence pratique est dans la colonne des réplicas. En usage général, une bascule consiste à réattacher le stockage distant à un nouveau nœud, ce qui prend un moment pendant lequel la base ne répond pas. En critique pour l'entreprise, un réplica déjà chaud prend la main bien plus vite, et le réplica lisible inclus permet de sortir les rapports de la base d'écriture sans payer une seconde base.

Le niveau à très grande échelle change la nature du stockage : le fichier n'est plus un fichier, il est servi par une couche distribuée. Les sauvegardes et les restaurations reposent sur des instantanés, donc leur durée dépend beaucoup moins du volume, ce qui est exactement le problème qu'on rencontre à plusieurs téraoctets.

Provisionné ou sans serveur

Le calcul provisionné réserve des cœurs et les facture qu'ils travaillent ou non. Le calcul sans serveur facture à la seconde de cœur consommée, met la base en veille après un délai d'inactivité que tu fixes, et ne facture plus que le stockage pendant la veille. Le réveil coûte de l'ordre d'une minute de latence à la première connexion, parfois moins.

Le pool élastique répond à un autre cas : beaucoup de bases, chacune petite, dont les pointes ne tombent pas au même moment. Elles partagent une réserve commune au lieu de réserver chacune la sienne. C'est le modèle des plateformes multi-clients, et le levier le plus simple pour faire tomber la facture d'un parc de petites bases.

Dimensionner sur des mesures, pas sur des impressions

Le dimensionnement se lit dans le moteur. Sur Azure SQL Database, deux vues suffisent à commencer.

-- Consommation récente, échantillonnée finement
SELECT end_time, avg_cpu_percent, avg_data_io_percent,
       avg_log_write_percent, max_worker_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

-- Historique sur plusieurs jours, dans la base master
SELECT start_time, database_name, avg_cpu_percent, avg_storage_percent
FROM sys.resource_stats
WHERE database_name = 'registre'
ORDER BY start_time DESC;

Posons le calcul sur un cas. Une base de production en usage général, huit cœurs virtuels, mesurée sur quatorze jours : 12 % de processeur en moyenne, une pointe à 55 % entre 8 h et 10 h, moins de 5 % la nuit et le week-end.

La pointe consomme donc l'équivalent de 4,4 cœurs. Descendre à six porte la pointe à 73 %, ce qui laisse de la marge pour la croissance et pour la fenêtre de maintenance. Descendre à quatre mettrait la pointe au-delà du plafond : l'économie se paierait en temps de réponse tous les matins, au pire moment de la journée.

Le sans serveur se décide avec la même arithmétique. Son tarif horaire de calcul est plus élevé que celui du provisionné. Si le rapport est de 1,5, l'équilibre tombe autour de 112 heures d'activité par semaine sur 168 : une base de recette utilisée aux heures ouvrées passe largement sous ce seuil, une base de production continue n'y arrive jamais. Prends le rapport réel sur la calculatrice de prix avant de trancher, il varie selon le niveau et la région.

Aucun dimensionnement ne se défend sans quatorze jours de mesures. La moyenne ne sert qu'à rassurer, c'est la pointe qui décide du calibre.

Les moteurs open source managés

Le port ne tient pas qu'un seul type de registre. Certains opérateurs arrivent avec leur propre système, et le terminal se contente de leur fournir le local, le courant et la sécurité.

Azure Database for PostgreSQL et Azure Database for MySQL, en déploiement de serveur flexible, jouent ce rôle. Le service prend en charge les correctifs, les sauvegardes, la supervision et la haute disponibilité, tout en laissant le moteur d'origine avec ses versions, ses extensions et ses outils.

Trois traits les rapprochent l'un de l'autre et les séparent du service SQL.

Le calcul se choisit par famille, avec un niveau économique pour les charges qui dorment la plupart du temps, et le stockage se dimensionne séparément avec ses entrées-sorties. La fenêtre de maintenance se choisit au lieu d'être subie. Le serveur peut être arrêté, ce qui interrompt la facturation du calcul, levier direct pour les environnements hors production.

La haute disponibilité s'active avec une instance de secours, placée dans une autre zone de disponibilité ou dans la même selon la région, et des réplicas de lecture se créent pour décharger les requêtes d'analyse.

Ce qui change vraiment par rapport à Azure SQL, c'est la nature de la question de compatibilité. Elle ne porte plus sur des fonctions d'instance mais sur les extensions autorisées et sur la version majeure disponible : une application PostgreSQL qui dépend d'une extension absente de la liste ne démarrera pas, et aucun niveau de service n'y changera rien.

Le service managé ne modifie pas le moteur, il modifie qui l'exploite. La compatibilité se vérifie extension par extension, avant la migration, sur la version exacte proposée.

Disponibilité et reprise

Un terminal sérieux prévoit un second poste d'amarrage dans un autre bassin, et un port de repli à cinquante kilomètres pour le jour où le bassin entier est fermé. Les deux ne servent pas au même incident, et aucun des deux ne remplace les archives du bureau.

Les mécanismes de continuité d'Azure SQL s'empilent dans le même ordre.

Zone, puis région

La redondance inter-zones répartit les réplicas d'une même base sur plusieurs zones de disponibilité de la région. Elle protège contre la perte d'un bâtiment, elle se demande à la création ou lors d'un changement de configuration, et elle n'est pas offerte partout ni sur tous les niveaux.

Au-delà, il faut sortir de la région. La réplication géographique active crée des secondaires lisibles dans d'autres régions, au niveau de la base, avec une bascule que tu déclenches. Le groupe de basculement automatique ajoute la couche qui manque : un point de terminaison d'écoute que l'application utilise à la place du nom du serveur, et une bascule déclenchée par la plateforme après un délai de grâce.

La bascule automatique s'appuie sur une réplication asynchrone. Elle peut donc perdre les dernières transactions confirmées, et c'est un arbitrage assumé, pas un défaut.

Le piège du groupe de basculement est ailleurs. Ce qui vit au niveau du serveur, connexions, règles de pare-feu, règles d'audit, ne suit pas forcément la base répliquée. Le basculement réussit, et l'application ne se connecte plus.

Les sauvegardes

Les sauvegardes automatiques existent dès la création de la base, sans rien activer. La plateforme prend une sauvegarde complète chaque semaine, des différentielles toutes les douze ou vingt-quatre heures, et une sauvegarde du journal des transactions environ toutes les dix minutes. C'est ce qui rend possible la restauration à un instant donné dans la fenêtre de rétention.

Trois réglages restent à ta charge, et ce sont eux qui définissent ton vrai point de restauration.

La durée de rétention pour la restauration dans le temps, qui se configure de quelques jours à plusieurs semaines. La rétention à long terme, qui conserve des sauvegardes hebdomadaires, mensuelles ou annuelles pendant des années, pour les besoins réglementaires. La redondance du stockage de sauvegarde, locale, inter-zones ou géographique, qui décide si tes sauvegardes survivent à la perte de la région.

Un point que tout le monde découvre au mauvais moment : la restauration ne réécrit pas la base existante, elle en crée une nouvelle.

az sql db restore \
  --resource-group rg-donnees \
  --server srv-manifestes \
  --name registre \
  --dest-name registre-restaure \
  --time "2026-03-14T09:20:00Z"

La procédure complète comprend donc la restauration, la vérification du contenu, puis la bascule des noms ou de la chaîne de connexion. Chronométrer l'ensemble sur le volume réel de production fait partie du travail, parce que c'est ce chiffre, et non la promesse du service, qui est ton objectif de reprise.

Les objectifs chiffrés de temps et de perte publiés par Microsoft pour chaque mécanisme évoluent. Va lire la valeur en vigueur dans la documentation de continuité d'activité avant de l'écrire dans un engagement de service.

Une réplication recopie fidèlement tes erreurs. Seule une sauvegarde permet de revenir avant la commande qui a tout effacé, et seulement si sa fenêtre de rétention couvre le moment où tu t'en aperçois.

Sécuriser l'accès à la donnée

Le registre du terminal ne se consulte pas depuis le quai. On passe par le bureau, avec un badge, et les documents sensibles dorment dans le coffre des douanes.

Quatre couches se combinent sur une base Azure SQL, et elles ne se remplacent pas.

L'authentification par annuaire d'entreprise, d'abord. Microsoft Entra ID remplace les identifiants stockés dans une chaîne de connexion, et l'application se présente avec une identité managée plutôt qu'avec un mot de passe. Le mode d'authentification exclusivement par annuaire ferme la porte aux connexions SQL locales, ce qui supprime d'un coup la famille des comptes partagés oubliés.

Le réseau, ensuite. Les règles de pare-feu du serveur logique filtrent par adresse, le point de terminaison privé sort la base de l'Internet public, et la désactivation de l'accès public rend le filtrage inutile parce qu'il n'y a plus rien à filtrer. Attention à l'option qui autorise les services Azure à joindre le serveur : elle ouvre bien plus large que ce que son intitulé laisse croire.

Le chiffrement, toujours actif au repos par chiffrement transparent. La question n'est pas de l'activer mais de savoir qui détient la clé : gérée par la plateforme par défaut, ou gérée par le client dans un coffre de clés. La seconde option apporte le contrôle et la révocation, avec la contrepartie exacte de ce contrôle, une clé rendue inaccessible rend la base inaccessible.

Les protections au niveau des colonnes, enfin, qu'on confond souvent. Le masquage dynamique cache une valeur dans le résultat renvoyé aux utilisateurs non privilégiés, mais la donnée reste en clair dans la base et un utilisateur qui peut écrire ses propres requêtes finit par la déduire. Always Encrypted chiffre côté client, avec des clés que le moteur ne voit jamais, au prix d'opérations limitées sur les colonnes chiffrées.

L'audit complète l'ensemble en envoyant les événements vers un espace de travail de journaux, et Microsoft Defender for SQL y ajoute la détection de comportements suspects et l'évaluation de vulnérabilités.

Une base managée n'est pas une base privée. Tant que l'accès public n'est pas désactivé, elle reste joignable depuis l'extérieur par quiconque satisfait au pare-feu.

Scénario B : GitLab, 31 janvier 2017

Ce soir-là, l'équipe d'infrastructure de GitLab lutte contre une charge anormale qui fait décrocher la réplication. Un ingénieur entreprend de réamorcer le secondaire et lance une commande de suppression du répertoire de données. Sur le mauvais serveur.

Le geste efface le répertoire de données de la base de production. L'ingénieur l'interrompt une ou deux secondes après avoir vu son erreur. Trop tard : sur environ 300 Go, il n'en reste que 4,5.

Vient alors la partie qui a rendu ce cas célèbre. L'entreprise a documenté l'incident en direct, dans un document public, puis a publié un compte rendu détaillé le 10 février. Ce compte rendu constate que cinq dispositifs de sauvegarde ou de réplication étaient censés couvrir cette situation, et qu'aucun ne fonctionnait de façon fiable ou n'était réellement en place.

Les exports logiques échouaient silencieusement, à cause d'un écart de version entre l'outil client et le serveur, produisant des fichiers pratiquement vides. Les alertes correspondantes partaient par courriel et étaient rejetées à la réception, personne ne les voyait donc. Les instantanés de disque étaient activés sur un autre serveur, pas sur ceux de la base. L'espace de stockage objet destiné aux sauvegardes était vide.

La récupération a finalement reposé sur un instantané pris six heures plus tôt pour un environnement de test, et sa copie a été lente. GitLab rapporte la perte d'environ six heures de données de base : de l'ordre de cinq mille projets, cinq mille commentaires et sept cents comptes créés dans cette fenêtre. Les dépôts Git eux-mêmes n'ont pas été touchés.

Quel rapport avec une base managée, puisque la plateforme sauvegarde toute seule ? Le rapport, c'est que la formule managée reprend la partie mécanique du problème et laisse intacte la partie que tu configures.

Ce qu'elle règle : le mécanisme de sauvegarde existe et s'exécute, et il ne peut pas être cassé par un écart de version d'outil client.

Ce qu'elle ne règle pas. La fenêtre de rétention, que tu configures et qui définit à elle seule jusqu'où tu peux remonter. La redondance du stockage de sauvegarde, qui décide si tes sauvegardes survivent au sinistre qui emporte la base. Et surtout la durée réelle de restauration sur ton volume, que personne ne connaît tant qu'elle n'a pas été chronométrée sur un jeu de production.

Il reste un dernier parallèle, plus désagréable. Le geste destructeur n'a pas disparu, il a changé de forme : une migration ratée, un DROP TABLE sur la mauvaise connexion, ou la suppression du serveur logique, qui emporte ce qui vit dessous. Les verrous de ressource et la séparation des rôles servent exactement à ça : mettre un obstacle entre ta production et une commande de trop.

Une base managée déplace le curseur, elle ne répond pas à ta place à la question : quel est mon point de restauration réel, et combien de temps prend le retour.

Points clés

• La compatibilité tranche la formule. Base managée pour une application adaptée, instance managée pour un existant SQL Server qui a besoin de l'instance, machine virtuelle quand le besoin sort du moteur. L'inventaire des travaux planifiés et des requêtes inter-bases se fait avant, pas pendant.
• Le modèle en cœurs virtuels rend la facture lisible. Il sépare calcul, stockage et sauvegardes, ouvre les réservations et l'avantage hybride, et c'est le seul modèle de l'instance managée.
• Le dimensionnement se lit dans les vues de ressources. Quatorze jours de mesures, la pointe comme référence, et une marge assumée. Le sans serveur se justifie par un taux d'inactivité, pas par une préférence.
• Zone, région et sauvegarde couvrent trois pannes différentes. La réplication recopie les erreurs humaines, seule la restauration dans le temps permet de revenir avant, dans la limite de la rétention configurée.
• Une restauration crée une nouvelle base. La procédure de bascule et sa durée réelle se chronomètrent sur un volume de production, sinon l'objectif de reprise n'est qu'une intention.

Dans la série

Palier 2 : Construire les terminaux. Domaine : Stockage & données.

• Précédent : Comptes de stockage : redondance, niveaux d'accès, cycle de vie
• Suivant : Cosmos DB : partitionnement, unités de requête et cohérence
• Vue d'ensemble : Concevoir sur Azure : par où commencer

Pour aller plus loin

• Compte rendu de GitLab sur l'incident de base de données du 31 janvier 2017
• Le billet publié en direct pendant l'incident, le 1er février 2017
• Azure SQL Database, vue d'ensemble du service
• Azure SQL Managed Instance, vue d'ensemble
• SQL Server sur machines virtuelles Azure
• Haute disponibilité et continuité d'activité Azure SQL
• Sauvegardes automatiques et restauration dans le temps
• Niveau de calcul sans serveur
• Azure Database for PostgreSQL, serveur flexible
• Sauvegarde et reprise : Azure Backup et Site Recovery