Expertise
Haute disponibilité SQL Server & architecture
Architecte et DBA SQL Server, je conçois et fiabilise des architectures haute disponibilité : AlwaysOn Availability Groups et Failover Cluster Instance. Une HA qui tient le jour du failover réel, pas seulement sur le schéma.
La haute disponibilité SQL Server ne se juge pas sur un diagramme : elle se juge le jour où un nœud tombe. J'ai conçu, déployé et opéré des architectures HA SQL Server sur des environnements critiques 24/7 — typiquement une vingtaine d'instances, avec des bases de plusieurs téraoctets, au sein de parcs multi-datacenters.
Les technologies que je maîtrise
- AlwaysOn Availability Groups : réplicas synchrones/asynchrones, lecture sur secondaire, multi-sites, listeners.
- Failover Cluster Instance (FCI) : protection de l'instance, stockage partagé, intégration WSFC.
- Industrialisation : déploiement de clusters automatisé via Ansible et PowerShell DSC, idempotent.
Concevoir, mais surtout prouver
Une architecture HA qui n'a jamais été testée en conditions réelles est une hypothèse, pas une garantie. Mon approche :
- Cadrer les vrais objectifs : RPO/RTO mesurés (pas théoriques), criticité réelle, fenêtres de maintenance.
- Confronter la topologie réelle à la topologie documentée.
- Tester le failover : état des réplicas, latence, dernier basculement réussi, procédure exécutable par vos équipes.
- Documenter : runbooks de bascule clairs, pour ne pas dépendre d'une seule personne en cas de crise.
La sauvegarde, socle de toute HA
La haute disponibilité ne remplace pas la sauvegarde : un DELETE
malheureux se réplique aussi. Je vérifie systématiquement la couverture
(FULL/DIFF/LOG en chaîne continue), l'existence d'un test de restauration
récent sur une autre instance, et les RPO/RTO réellement atteignables.
Une sauvegarde non testée n'est pas une sauvegarde.
Un exemple à l'échelle
Sur un groupe de gestion d'actifs : architecture HA multi-sites de ~20 instances SQL Server (bases jusqu'à 4 To) plus un cluster NoSQL MarkLogic HA, industrialisée en infrastructure as code (PowerShell DSC orchestré par Ansible), avec intégration réseau F5 et Palo Alto.
Questions fréquentes
- AlwaysOn Availability Groups ou Failover Cluster Instance ?
- FCI protège l'instance (stockage partagé, bascule complète) ; AlwaysOn AG protège la base (réplicas, lecture secondaire, multi-sites). Le choix dépend de votre RTO/RPO, de votre tolérance à la perte de données et de votre topologie réseau. On tranche sur vos contraintes réelles, pas sur la mode.
- Comment savoir si mon architecture HA tient vraiment ?
- En testant le failover, pas en lisant la documentation. L'écart entre la topologie documentée et la topologie réelle fait souvent peur. Je vérifie l'état des réplicas, la latence de synchronisation, la date du dernier failover réussi, et l'existence d'une procédure testée par une personne identifiée.
- Faites-vous de la haute disponibilité sur Azure ?
- Oui : VM Azure avec AlwaysOn et architectures hybrides on-premise / Azure. J'ai industrialisé des déploiements de clusters via Ansible et PowerShell DSC.
- Pouvez-vous concevoir l’architecture depuis zéro ?
- Oui. J'ai conçu et opéré des architectures HA SQL Server multi-sites — une vingtaine d'instances, plus un cluster NoSQL MarkLogic — avec conception, mise en place, tests de bascule et procédures documentées.
- Le NoSQL fait-il partie du périmètre ?
- J'ai opéré un cluster MarkLogic HA en complément d'un parc SQL Server, donc oui dans ce cadre. En revanche, sur du NoSQL pur (MongoDB, Cassandra) comme cœur de mission, un spécialiste sera plus pertinent.
Une mission sur ce périmètre ?
30 minutes pour cadrer le besoin, premier échange offert. Réponse dans la journée. Missions critiques : 1000-1400 €/jour selon périmètre et durée.