Groupe de disponibilité AlwaysOn Microsoft SQL Server dans Google Cloud

Last reviewed 2026-08-12 UTC

Ce document fournit une architecture de référence pour le déploiement de bases de données Microsoft SQL Server à haute disponibilité (HA) dans Google Cloud à l'aide d'un groupe de disponibilité Always On. Le document inclut également des éléments de conception pour la haute disponibilité et la reprise après sinistre, des options de déploiement, des recommandations d'automatisation et des conseils pour les opérations de sauvegarde et de reprise après sinistre. Ce document est destiné aux professionnels techniques qui évaluent Google Cloud en tant que plate-forme pour exécuter des bases de données SQL Server. Nous partons du principe que vous possédez des connaissances de base sur Compute Engine et SQL Server.

Google Cloud fournit des solutions économiques, fiables, sécurisées et performantes pour exécuter des bases de données SQL Server. Pour obtenir une présentation des solutions SQL Server compatibles dans Google Cloud, consultez SQL Server sur Google Cloud.

Pour exécuter un déploiement SQL Server non destiné au développement dans Google Cloud, utilisez l'une des options de licence suivantes :

La section Déploiement de ce document fournit des ressources pour vous aider à déployer cette architecture de référence.

Architecture

Le schéma suivant illustre une architecture de référence pour un déploiement SQL Server configuré pour la haute disponibilité dans Google Cloud :

Architecture montrant un déploiement SQL Server avec un groupe de disponibilité Always On couvrant des VM Compute Engine dans différentes zones et régions.

L'architecture précédente montre un groupe de disponibilité Always On avec trois nœuds dans un cluster de basculement Windows Server (WSFC). Chaque nœud est une VM Compute Engine qui exécute SQL Server.

Un groupe de disponibilité Always On est un modèle de déploiement standard du secteur permettant d'atteindre les objectifs de fiabilité pour les bases de données SQL Server critiques. Les groupes de disponibilité Always On offrent une haute disponibilité locale (basculement dans une région) et un basculement interrégional pour la reprise après sinistre. Ce modèle de déploiement est une alternative de niveau entreprise à la mise en miroir de bases de données. Un groupe de disponibilité Always On offre les avantages suivants :

  • Pas besoin de composants d'infrastructure spécialisés : SQL Server gère la réplication sur toutes les répliques de base de données configurées.
  • Configuration avec le contrat de niveau de service le plus élevé pour SQL Server : objectif de temps de récupération (RTO) inférieur à une minute et objectif de point de récupération (RPO) proche de zéro.
  • Possibilité de décharger les charges de travail en lecture seule sur des répliques secondaires : faites évoluer efficacement votre déploiement pour l'analyse et d'autres cas d'utilisation courants.
  • Nœuds dans des régions supplémentaires pour la reprise après sinistre : déployez une instance répliquée principale et jusqu'à huit instances répliquées secondaires.
  • Déployable sur Windows et Linux : vous pouvez utiliser un outil tiers tel que Pacemaker comme gestionnaire de cluster pour les déploiements Linux.

Dans l'architecture précédente, les nœuds SQL Server principal et secondaire se trouvent dans des zones distinctes d'une même région. Le nœud de reprise après sinistre se trouve dans une région géographiquement éloignée. Les données du nœud principal sont répliquées de manière synchrone sur le nœud secondaire et de manière asynchrone sur le nœud de reprise après sinistre.

Pour distribuer le trafic de la couche Application aux nœuds de base de données principaux et secondaires d'une région, vous pouvez utiliser l'une des approches suivantes :

Produits utilisés

L'architecture utilise les produits et composants Google Cloud et Microsoft suivants.

Google Cloud  produits

  • Compute Engine : service de calcul sécurisé et personnalisable qui vous permet de créer et d'exécuter des machines virtuelles au sein de l'infrastructure de Google.
  • Google Cloud Hyperdisk : service de stockage réseau que vous pouvez utiliser pour provisionner et mettre à l'échelle de manière dynamique des volumes de stockage de blocs avec des performances configurables et prévisibles.
  • Cloud privé virtuel (VPC) : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos charges de travail Google Cloud . Le VPC inclut l'appairage de réseaux VPC, Private Service Connect, l'accès aux services privés et le VPC partagé.
  • Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.

Produits et composants Microsoft

Les composants suivants sont inclus ou activés sur les nœuds SQL Server :

  • Windows Server (version 2019 ou ultérieure)
  • WSFC : groupe d'instances SQL Server installées sur plusieurs nœuds de cluster Windows Server ou sur plusieurs sous-réseaux.
  • Groupe de disponibilité Always On : alternative à la mise en miroir de base de données pour la haute disponibilité et la reprise après sinistre de niveau Enterprise.
  • Écouteur de groupe de disponibilité : nom de réseau virtuel (VNN) que les clients peuvent utiliser pour accéder à une base de données dans un réplica principal ou secondaire d'un groupe de disponibilité Always On. Les clients n'ont pas besoin de connaître le nom d'instance physique des réplicas. Étant donné que l'écouteur achemine le trafic, il n'est pas nécessaire de modifier la chaîne de connexion du client après un basculement.

Les composants supplémentaires suivants sont requis pour déployer cette architecture :

Considérations de conception

Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations de conception à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie qui répond à vos exigences en termes de fiabilité, d'efficacité opérationnelle, de sécurité, de coût et de performances.

Fiabilité

Cette section décrit les considérations de conception et les recommandations pour créer et exploiter une infrastructure fiable pour votre déploiement SQL Server dansGoogle Cloud.

Choisir une stratégie de haute disponibilité et de reprise après sinistre

Pour déployer des bases de données SQL Server fiables dans Google Cloud, vous avez besoin d'une stratégie qui combine l'infrastructure robuste de Google Cloud avec les capacités de haute disponibilité et de reprise après sinistre de SQL Server. Cette combinaison protège vos bases de données contre les défaillances, qu'il s'agisse de pannes zonales ou de catastrophes régionales.

Lorsque vous concevez la stratégie de haute disponibilité et de reprise après sinistre pour votre déploiement SQL Server, tenez compte des facteurs suivants :

  • RPO : quelle quantité de données peut être perdue en cas de défaillance ?
  • RTO : après une défaillance, dans quel délai la base de données doit-elle redevenir opérationnelle ?
    • Pour obtenir un RTO faible, utilisez un groupe de disponibilité Always On.
    • Si un certain temps d'arrêt est acceptable, restaurez les bases de données à partir de sauvegardes ou utilisez la copie des journaux de transaction avec basculement manuel.
  • Budget : réfléchissez au compromis à faire entre coût et fiabilité.
    • Coût élevé, mais fiable : utilisez un groupe de disponibilité Always On avec réplication asynchrone vers des nœuds supplémentaires dans une région de reprise après sinistre. Planifiez une infrastructure et des licences redondantes.
    • Coût moyen : implémentez la réplication asynchrone des disques dans une autre région ou utilisez le service Backup and DR.
    • Faible coût, mais temps de récupération élevé : sauvegardez les bases de données dans un bucket Cloud Storage multirégional.
  • Types de défaillances : quels types de défaillances devez-vous gérer ?
    • Pour gérer les défaillances au niveau du matériel, des instances et des zones, vous pouvez utiliser des groupes de disponibilité.
    • Pour vous remettre d'une panne ou d'une catastrophe sur l'ensemble du site, vous avez besoin d'une solution de reprise après sinistre géographiquement dispersée, comme la copie des journaux de transaction ou les groupes de disponibilité Always On avec réplication asynchrone de la base de données.
  • Criticité métier : dans quelle mesure l'application est-elle essentielle à votre activité ?
    • Les applications critiques ont besoin d'une stratégie qui offre le plus haut niveau de disponibilité, une perte de données minimale et une reprise rapide.
    • Pour les systèmes moins critiques, envisagez une stratégie qui suppose un temps d'arrêt acceptable ou une perte de données.

Utilisez le questionnaire suivant pour choisir une stratégie de fiabilité optimale pour votre base de données SQL Server. Les options de stratégie vont d'un groupe de disponibilité AlwaysOn qui offre une perte de données quasi nulle à une sauvegarde hors site économique.

  1. Les sauvegardes hors site répondent-elles à vos objectifs de RPO et de RTO ?
    • Oui : utilisez des sauvegardes hors site ou la livraison des journaux.
    • Non : passez à la question suivante.
  2. Votre RTO ou RPO est-il inférieur à une minute ?
    • Oui (RPO quasi nul) : utilisez un groupe de disponibilité Always On SQL Server avec une instance répliquée de base de données de reprise après sinistre.
    • Non : passez à la question suivante.
  3. Quel est votre RTO ?
    • Moins de cinq minutes : utilisez un groupe de disponibilité Always On SQL Server avec une réplique de disque asynchrone.
    • Une heure ou plus : passez à la question suivante.
  4. Quel est votre RPO ?
    • Moins de deux heures : utilisez un groupe de disponibilité Always On SQL Server avec le service Backup and DR.
    • Huit heures ou plus : utilisez des sauvegardes hors site ou la livraison des journaux.

Choisir les options de sauvegarde appropriées

Si votre stratégie de fiabilité inclut des sauvegardes de bases de données, choisissez une méthode de sauvegarde qui répond à vos besoins. Google Cloud propose les options flexibles et adaptées aux entreprises suivantes pour sauvegarder les bases de données SQL Server :

  • Sauvegarde directe dans un bucket Cloud Storage : écrivez les sauvegardes de base de données directement dans Cloud Storage à l'aide de la commande BACKUP TO URL et du connecteur S3 dans SQL Server (version 2022 ou ultérieure). Pour les environnements de production, vous pouvez utiliser une clé d'accès HMAC (Hash-based Message Authentication Code). Cette option de sauvegarde offre une protection économique pour les bases de données et les journaux sans nécessiter de stockage local intermédiaire.
  • Instantanés instantanés Compute Engine : capturez des instantanés simultanés sur plusieurs disques (par exemple, sur des disques Hyperdisk Balanced) en moins d'une seconde à l'aide d'opérations de gel/dégel Transact-SQL (T-SQL) combinées à des groupes de cohérence Compute Engine. Cette option permet d'effectuer des sauvegardes de VM hautes performances pour les bases de données multidisk et ne nécessite pratiquement aucune période de gel d'écriture.
  • Backup and DR : orchestrez des instantanés cohérents avec les applications à l'aide des fournisseurs Microsoft VSS et des groupes de cohérence. Cette option de sauvegarde est adaptée lorsque vous avez besoin d'une récupération à un moment précis (PITR) précise et multidatabase, et que vous souhaitez utiliser les journaux pour faire avancer les bases de données.
  • Google Cloud NetApp Volumes : créez des instantanés et des sauvegardes asynchrones dans des coffres-forts distants à l'aide du moteur de stockage ONTAP. Nous recommandons NetApp Volumes pour les applications d'entreprise sensibles à la latence qui nécessitent une atténuation rapide des rançongiciels et des clones peu gourmands en espace.

Pour les déploiements multicloud et hybrides qui nécessitent des règles de protection des données unifiées, vous pouvez choisir un produit de sauvegarde tiers tel que Veeam, Veritas NetBackup ou Cohesity.

Opérations

Pour garantir la haute disponibilité et les performances optimales des bases de données SQL Server déployées sur des VM Compute Engine, configurez un système complet de surveillance et d'alertes à l'aide de Cloud Monitoring et Cloud Logging.

  • Suivez en permanence les métriques des ressources principales, telles que l'utilisation du processeur et la charge mémoire. Configurez des alertes de référence pour détecter la pression exercée sur les ressources avant que les requêtes ne commencent à se dégrader.
  • Pour éviter les arrêts d'écriture dans la base de données, surveillez en permanence l'utilisation de l'espace disque. Surveillez l'état général du service et configurez des alertes pour recevoir des notifications lorsque des bases de données s'arrêtent de manière inattendue.
  • Pour les déploiements à haute disponibilité, suivez les basculements imprévus et assurez-vous d'avoir une visibilité complète lors des événements de reprise après sinistre automatisés.
  • En plus de la télémétrie au niveau du système, Google Cloud fournit une suite complète de métriques spécifiques aux bases de données, telles que les limites de connexion des utilisateurs actifs, le délai avant réplication et les taux de transaction. Suivez ces métriques pour surveiller la disponibilité et les performances de vos bases de données SQL Server.
  • Pour capturer les erreurs au niveau de l'application, comme les blocages, la corruption de la base de données et les échecs de tâches de l'agent, directement à partir des journaux d'erreurs SQL Server, configurez des alertes personnalisées basées sur les journaux dans Logging.

Sécurité

Cette section décrit les considérations de conception et les recommandations pour concevoir un déploiement SQL Server dans Google Cloud qui répond aux exigences de sécurité de votre charge de travail.

Sécurité et isolation du réseau

  • Pour éviter l'exposition externe des bases de données, déployez les instances SQL Server avec des adresses IP privées dans un VPC. Utilisez l'accès aux services privés pour acheminer le trafic en interne. Cette approche permet de s'assurer que le trafic de votre base de données ne transite jamais par l'Internet public.
  • Limitez davantage l'accès aux bases de données en configurant des règles de pare-feu VPC strictes qui n'autorisent le trafic qu'à partir de sous-réseaux d'application autorisés ou de blocs CIDR spécifiques.
  • Pour protéger les données en transit contre l'écoute clandestine et l'interception, implémentez une connectivité chiffrée en appliquant TLS/SSL pour toutes les connexions à la base de données.

Chiffrement et contrôle des clés

  • Par défaut, Google Cloud utilise des clés AES-256 gérées par Google pour chiffrer automatiquement toutes les données au repos dans les disques de base de données, les fichiers temporaires et les sauvegardes. Pour vous aider à respecter les environnements de conformité, vous pouvez implémenter le chiffrement au niveau de la base de données à l'aide de la fonctionnalité Transparent Data Encryption (TDE) de SQL Server.
  • Pour garantir la souveraineté des données, vous pouvez utiliser des clés de chiffrement gérées par le client (CMEK) dans Cloud Key Management Service. Les clés CMEK vous offrent un contrôle cryptographique total. Vous gérez les cycles de vie des clés, définissez des plannings de rotation automatique et révoquez instantanément l'accès à la base de données et à ses sauvegardes si nécessaire.

Authentification et autorisation

  • Intégrez votre base de données à Microsoft Active Directory ou centralisez la gestion des identités dans vos bases de données SQL Server et d'autres ressourcesGoogle Cloud à l'aide d'Identity and Access Management (IAM).
  • Une fois les identités établies, appliquez le principe du moindre privilège afin que les comptes utilisateur et de service d'application ne disposent que des autorisations nécessaires à l'exécution de leurs fonctions. Mappez les identités à des rôles précis de base de données SQL Server.

Optimisation des coûts

Cette section fournit des conseils pour optimiser les coûts de configuration et d'exploitation d'un déploiement SQL Server que vous créez à l'aide de cette architecture de référence. L'optimisation des coûts permet de s'assurer que le déploiement répond aux exigences de fiabilité et de performances de votre charge de travail dans les limites de votre budget.

Tenez compte des recommandations suivantes :

  • Désactivez le multithreading simultané (SMT) : en désactivant le SMT, vous pouvez réduire de 50 % le nombre de cœurs indiqué à des fins de licence. En surprovisionnant vos CPU de 20% et en désactivant le SMT, vous pouvez réaliser des économies considérables sur les coûts de licence sans sacrifier les performances. Pour en savoir plus, consultez Définir le nombre de threads par cœur.
  • Utilisez SQL Server Standard Edition : en fonction de vos exigences en matière de haute disponibilité et de reprise après sinistre, vous pouvez réduire les coûts de licence en utilisant SQL Server Standard Edition au lieu de l'édition Enterprise. Pour en savoir plus, consultez Éditions et fonctionnalités compatibles de SQL Server.
  • Optimiser le stockage : Hyperdisk propose différentes options de disque que vous pouvez choisir en fonction des besoins de votre déploiement SQL Server. Hyperdisk Balanced offre un bon équilibre entre coûts et performances. Vous pouvez faire évoluer le débit et les opérations d'entrée/de sortie par seconde (IOPS) de manière indépendante, de sorte que vos dépenses d'infrastructure correspondent précisément aux besoins de la charge de travail. Pour en savoir plus, consultez la section Choisir un type de disque de stockage approprié.

Optimisation des performances

Cette section décrit les considérations de conception et les recommandations pour un déploiement SQL Server qui répond à vos exigences de performances.

En déployant SQL Server sur des VM Compute Engine, vous contrôlez entièrement la base de données et l'infrastructure sous-jacente. Les performances de votre charge de travail dépendent de l'infrastructure que vous choisissez. Pour équilibrer les performances, les coûts et la fiabilité, vous devez prendre des décisions éclairées concernant la famille de machines de la VM et le type de disque pour les nœuds de base de données.

Choisir une famille de machines VM appropriée

La famille de machines que vous choisissez pour les VM Compute Engine détermine la puissance de traitement (vCPU) et la mémoire (RAM) disponibles pour vos nœuds SQL Server. Ces ressources ont un impact sur les performances de vos bases de données.

Choisissez une famille de machines VM qui résout votre principal goulot d'étranglement des performances. Par exemple, si votre base de données SQL Server utilise constamment beaucoup de processeurs, choisissez un type de machine de la famille de machines optimisée pour le calcul. Si votre base de données SQL Server présente des lectures lentes à partir du disque, choisissez un type de machine à mémoire optimisée.

Le tableau suivant compare les familles de machines VM fournies par Compute Engine, le cas d'utilisation principal de chaque famille de machines et l'impact sur les performances des bases de données SQL Server :

Famille et série de machines Cas d'utilisation principal Impact sur les performances de SQL Server
Usage général (série de machines N4) Rapport prix/performances équilibré Utilisez cette famille de machines comme point de départ pour la plupart des charges de travail. La série de machines N4 offre un équilibre optimal entre processeur et mémoire pour les bases de données à usage mixte, les applications Web et les environnements de développement ou de test.
Optimisé pour le calcul (séries de machines C3 ou C4) Performances les plus élevées par cœur Utilisez cette famille de machines pour les charges de travail liées au processeur. Pour les bases de données qui exécutent des requêtes complexes, traitent de grands volumes de données ou gèrent un grand nombre d'opérations de traitement des transactions en ligne (OLTP), utilisez les séries de machines C3 et C4. Les types de machines de ces séries permettent de réduire considérablement la durée d'exécution des requêtes.
Mémoire optimisée (séries de machines M3 ou M4) Ratios mémoire/vCPU élevés Cette famille de machines est idéale pour les applications gourmandes en mémoire. SQL Server met en cache les données et les plans d'exécution en mémoire, ce qui offre de meilleures performances que la lecture à partir des disques. Avec les très grandes bases de données ou les entrepôts de données pour le traitement analytique en ligne (OLAP), les requêtes analysent généralement de grands tableaux et ensembles de données. Pour de tels cas d'utilisation, une mémoire plus importante permet d'améliorer les performances.

Pour en savoir plus, consultez le Guide des ressources de familles de machines et guide comparatif.

Choisir un type de disque de stockage approprié

Les performances du disque sont un facteur important pour la réactivité de la base de données, qui est essentielle pour les performances des applications. Pour les types de disques proposés par Google Cloud, les capacités de performances sont indiquées à l'aide des métriques suivantes :

  • IOPS : nombre de requêtes de lecture et d'écriture qu'un disque peut traiter par seconde. Les IOPS sont essentielles pour les charges de travail OLTP qui impliquent de nombreuses opérations de lecture et d'écriture aléatoires de petite taille, comme la mise à jour des fiches client ou le traitement des commandes.
  • Débit : quantité totale de données pouvant être transférées vers ou depuis le disque par seconde. Le débit est essentiel pour les charges de travail OLAP qui impliquent l'analyse de grandes quantités de données, comme l'exécution de rapports, l'entreposage de données ou les sauvegardes.

Le tableau suivant compare les Google Cloud types de disques que vous pouvez choisir :

Type de disque Caractéristiques de performances Adéquation de la charge de travail
Disque persistant SSD (pd-ssd) Performances moyennes à élevées selon le type de machine de la VM et la taille du disque Charges de travail nécessitant des performances évolutives en fonction de la taille du disque et des processeurs virtuels de la VM. Pour en savoir plus, consultez Présentation des performances des disques persistants.
Hyperdisk Balanced Hautes performances avec IOPS et débit configurables Fichiers journaux et de données SQL Server de production. Hyperdisk Balanced vous permet de configurer les IOPS et le débit indépendamment de la taille du disque et en fonction des besoins de la charge de travail.
Hyperdisk Extreme Très hautes performances avec des IOPS configurables Charges de travail OLTP critiques et haut de gamme nécessitant un nombre maximal d'IOPS et la latence la plus faible, comme les systèmes financiers ou d'e-commerce à grande échelle.
SSD local IOPS et débit les plus élevés par rapport aux autres types de disques Données temporaires qui n'ont pas besoin de la durabilité des disques persistants. Pour les données telles que la base de données système tempdb et le fichier d'échange Windows, les disques SSD locaux offrent la latence la plus faible, car ils sont associés physiquement aux VM.

Adapter l'infrastructure aux exigences de performances

Choisissez des types de machines et de disques de VM en fonction des exigences de performances de votre charge de travail. Le tableau suivant recommande des configurations d'infrastructure pour différents scénarios de charge de travail :

Scénario Exigences en termes de performances Type de machine et configuration de disque recommandés
Base de données e-commerce à volume de transactions élevé pour OLTP IOPS élevés pour gérer des milliers de petites opérations de lecture et d'écriture simultanées

Type de machine de la VM : choisissez un type de machine optimisé pour le calcul (par exemple, de la série de machines C4) pour traiter efficacement les transactions.

Disques de données et de journaux : utilisez des disques Hyperdisk Balanced. Provisionnez un niveau d'IOPS élevé pour répondre à la demande transactionnelle. Utilisez des disques distincts pour les données et les journaux.

tempdb : utilisez des disques SSD locaux pour décharger les opérations temporaires et maximiser les performances.
Entrepôt de données d'entreprise pour OLAP Débit élevé pour analyser et agréger des téraoctets de données pour les rapports

Type de machine virtuelle : choisissez un type de machine à mémoire optimisée (par exemple, de la série de machines M4) pour pouvoir mettre en cache la plus grande partie possible du grand ensemble de données.

Disque de données : utilisez des disques Hyperdisk Balanced. Provisionnez un débit élevé pour accélérer les analyses de données volumineuses.
Serveur de développement ou de préproduction Rentabilité plutôt que performances maximales

Type de machine de la VM : choisissez un type de machine à usage général avec une petite taille de machine dans les séries de machines E2 ou N4.

Disques : utilisez un disque persistant avec équilibrage (pd-balanced) pour tous les fichiers de base de données afin d'obtenir des performances acceptables à faible coût.

Déploiement

Pour déployer cette architecture de référence, utilisez l'une des ressources suivantes :

Étapes suivantes

Contributeurs

Auteurs :

Autre contributeur : Kumar Dhanagopal | Développeur de solutions multi-produits