Groupe de disponibilité Always On Microsoft SQL Server dans Google Cloud

Last reviewed 2026-08-12 UTC

Ce document fournit une architecture de référence pour déployer des 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 considérations 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 disposez des connaissances de base sur Compute Engine et SQL Server.

Google Cloud fournit des solutions économiques, fiables, sécurisées et hautes performances pour l'exécution de bases de données SQL Server. Pour obtenir un aperçu des solutions SQL Server compatibles dans Google Cloud, consultez SQL Server sur Google Cloud.

Pour exploiter un déploiement SQL Server hors développement dans Google Cloud, utilisez l'une des options de licence suivantes :

• Bring Your Own License (BYOL) : utilisez vos licences Microsoft SQL Server existantes sur Google Cloud. Vous devez utiliser des nœuds à locataire unique ou Software Assurance avec License Mobility.

• Utiliser des licences à la demande : utilisez des images SQL Server prédéfinies dans Google Cloud et payez des frais qui incluent le coût de calcul et le coût de la licence Microsoft. Google gère les contrats de licence et la facturation Microsoft.

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 :

L'architecture précédente montre un groupe de disponibilité AlwaysOn 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é AlwaysOn est un modèle de déploiement standard permettant d'atteindre les objectifs de fiabilité des bases de données SQL Server critiques. Les groupes de disponibilité AlwaysOn fournissent une haute disponibilité locale (basculement au sein d'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 :

• Aucun composant d'infrastructure spécialisé n'est requis : SQL Server gère la réplication sur toutes les instances dupliquées de base de données configurées.
• Configuration de SLA la plus élevée 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 vers des instances répliquées secondaires : effectuez un scaling efficace de 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 région. Le nœud de DR 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 répartir le trafic de la couche d'application vers les nœuds de base de données principaux et secondaires d'une région, vous pouvez utiliser l'une des approches suivantes :

• Un équilibreur de charge interne, comme illustré dans le diagramme de l'architecture.
• Un écouteur de nom de réseau distribué (DNN) et un serveur DNS.

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 faire évoluer 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 de niveau entreprise à la mise en miroir de bases de données pour la haute disponibilité et la reprise après sinistre.
• É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 une instance répliquée principale ou secondaire d'un groupe de disponibilité Always On. Les clients n'ont pas besoin de connaître le nom de l'instance physique des instances répliquées. É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 :

• Active Directory Domain Services : service d'annuaire Windows Server permettant de gérer les ressources communes à un domaine, telles que les ordinateurs, les rôles et les utilisateurs.
• DNS : serveur qui résout les noms de domaine en adresses IP correspondantes.
• Témoin de quorum : il peut s'agir d'un partage de fichiers SMB (Server Message Block) ou d'un disque partagé associé localement.

Considérations de conception

Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations de conception que vous devez prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie répondant à 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 fonctionnalité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 ?
  • Pour obtenir un RPO faible (perte de données quasi nulle), utilisez un groupe de disponibilité Always On avec réplication synchrone.
  • Si vous pouvez tolérer une perte de données, utilisez l'une des approches suivantes : réplication asynchrone, service Backup and DR, sauvegarde dans un bucket Cloud Storage ou envoi de journaux.
• RTO : après une défaillance, dans quel délai la base de données doit-elle être à nouveau 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 l'envoi de journaux avec un basculement manuel.
• Budget : tenez compte des compromis entre coût et fiabilité.
  • Coût élevé, mais fiable : utilisez un groupe de disponibilité Always On avec une réplication asynchrone vers des nœuds supplémentaires dans une région de reprise après sinistre. Prévoyez une infrastructure et des licences redondantes.
  • Coût moyen : implémentez la réplication asynchrone des disques vers une autre région ou utilisez 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, de l'instance et de la zone, vous pouvez utiliser des groupes de disponibilité.
  • Pour récupérer après une panne ou un sinistre à l'échelle du site, vous avez besoin d'une solution de reprise après sinistre géographiquement dispersée, telle que l'envoi de journaux ou les groupes de disponibilité Always On avec réplication asynchrone de la base de données.
• Importance pour l'entreprise : quelle est l'importance de l'application pour votre entreprise ?
  • Les applications critiques nécessitent une stratégie offrant le plus haut niveau de disponibilité, une perte de données minimale et une récupération 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 de flux de décision 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é Always On, 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 l'envoi de journaux.
   • Non : passez à la question suivante.
2. Votre RTO ou votre RPO est-il inférieur à une minute ?
   • Oui (RPO proche de zéro) : 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 instance répliquée 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é AlwaysOn SQL Server avec Backup and DR.
   • Huit heures ou plus : utilisez des sauvegardes hors site ou l'envoi de 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 prêtes pour l'entreprise suivantes pour sauvegarder des 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 immédiats Compute Engine : capturez des instantanés simultanés sur plusieurs disques (par exemple, sur des disques Google Cloud 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 hautes performances au niveau de la VM pour les bases de données multidisques, et ne nécessite pratiquement aucun gel des écritures.
• Backup and DR : orchestrez des instantanés cohérents avec les applications à l'aide de fournisseurs Microsoft VSS et de 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) granulaire et multibases de données, et de la possibilité d'utiliser des journaux pour effectuer un roll-forward des bases de données.
• Google Cloud NetApp Volumes : créez des instantanés et des sauvegardes asynchrones dans des coffres 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 encombrants.

Pour les déploiements multicloud et hybrides nécessitant 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'alerte à l'aide de Cloud Monitoring et de Cloud Logging.

• Suivez en continu les métriques des ressources principales, telles que l'utilisation du processeur et la charge de mémoire. Configurez des alertes de référence pour détecter la pression 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 global du service et configurez des alertes pour recevoir des notifications lorsque les bases de données s'arrêtent de manière inattendue.
• Pour les déploiements à haute disponibilité, suivez les basculements non planifiés et assurez 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 à la base de données, telles que les limites de connexion des utilisateurs actifs, le délai de 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, telles que les blocages, la corruption de la base de données et les échecs de jobs 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é réseau et isolation

• Pour empêcher l'exposition externe des bases de données, déployez les instances SQL Server avec des adresses IP privées au sein d'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, mettez en œuvre une connectivité chiffrée en appliquant TLS/SSL à toutes les connexions de 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 sur les disques de base de données, les fichiers temporaires et les sauvegardes. Pour répondre aux exigences de conformité, vous pouvez mettre en œuvre un chiffrement au niveau de la base de données à l'aide de la fonctionnalité de chiffrement transparent des données (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 planifications 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 utilisateurs et les comptes de service d'application ne disposent que des autorisations nécessaires pour exécuter leurs fonctions. Mappez les identités à des rôles de base de données SQL Server précis.

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, tout en respectant vos contraintes budgétaires.

Tenez compte des recommandations suivantes :

• Désactiver le multithreading simultané (SMT) : en désactivant le SMT, vous pouvez réduire de 50 % le nombre de cœurs indiqué pour les licences. En surprovisionnant vos processeurs de 20 %, puis en désactivant le SMT, vous pouvez réaliser des économies substantielles sur les coûts de licence sans sacrifier les performances. Pour en savoir plus, consultez la section Définir le nombre de threads par cœur.
• Utilisez SQL Server Standard Edition : en fonction de vos exigences de haute disponibilité et de reprise après sinistre, vous pouvez réduire les coûts de licence en utilisant l'édition SQL Server Standard au lieu de l'édition Enterprise. Pour en savoir plus, consultez Éditions et fonctionnalités compatibles de SQL Server.
• Optimiser le stockage : Google Cloud 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 équilibre entre coût 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, afin 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 bénéficiez d'un contrôle total sur 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 trouver le bon équilibre entre performances, coût et fiabilité, vous devez prendre des décisions éclairées concernant la famille de machines de VM et le type de disque pour les nœuds de base de données.

Choisir une famille de machines de 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 une incidence sur les performances de vos bases de données.

Choisissez une famille de machines de 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 ressources de processeur, choisissez un type de machine de la famille de machines optimisées pour le calcul. Si votre base de données SQL Server affiche des lectures lentes à partir du disque, choisissez un type de machine à mémoire optimisée.

Le tableau suivant compare les familles de machines de 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)	Équilibre entre prix et performances	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 le temps d'exécution des requêtes.
À mémoire optimisée (série 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 de disques. Avec des bases de données ou des entrepôts de données très volumineux pour le traitement analytique en ligne (OLAP), les requêtes analysent généralement des tables et des ensembles de données volumineux. Pour de tels cas d'utilisation, une mémoire plus élevée 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 de l'application. 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 essentiels pour les charges de travail OLTP qui impliquent de nombreuses petites opérations de lecture et d'écriture aléatoires, comme la mise à jour des fiches client ou le traitement des commandes.
• Débit : quantité totale de données pouvant être déplacé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, telles que l'exécution de rapports, l'entreposage de données ou la réalisation de sauvegardes.

Le tableau suivant compare les types de disques Google Cloud 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 en fonction du type de machine de la VM et de 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 de données et fichiers journaux 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.
Google Cloud Hyperdisk Extreme	Performances très élevées avec IOPS configurables	Charges de travail OLTP critiques haut de gamme nécessitant un nombre maximal d'IOPS et une latence minimale, telles que 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 physiquement associés aux VM.

Adapter l'infrastructure aux exigences de performances

Choisissez les 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 d'e-commerce à transactions élevées pour OLTP	IOPS élevées pour gérer des milliers de petites opérations de lecture et d'écriture simultanées	Type de machine de VM : choisissez un type de machine optimisé pour le calcul (par exemple, de la série de machines C4) pour un traitement efficace des transactions. Disques de données et de journaux : utilisez des disques Hyperdisk Balanced. Provisionnez un niveau élevé d'IOPS 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	Haut débit pour analyser et agréger des téraoctets de données pour les rapports	Type de machine de la VM : choisissez un type de machine à mémoire optimisée (par exemple, de la série de machines M4) afin de pouvoir mettre en cache autant de données que possible de l'ensemble de données volumineux. 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 optimales	Type de machine de VM : choisissez un type de machine à usage général de petite taille dans la série 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 :

• Infrastructure as Code (IaC) : utilisez une configuration Terraform pour provisionner des clusters SQL Server dans Google Cloud. La configuration inclut une configuration d'état souhaité (DSC) PowerShell et des scripts Bash pour configurer les composants nécessaires. Vous pouvez télécharger et modifier le code en fonction de vos besoins de configuration.
• Workflow guidé : déployez SQL Server dans une configuration à un seul nœud ou en cluster à l'aide de Workload Manager.
• Tutoriel : suivez les instructions détaillées pour configurer des groupes de disponibilité AlwaysOn SQL Server avec commit synchrone à l'aide d'un équilibreur de charge interne.

Étapes suivantes

• Découvrez les options de licence et d'image pour SQL Server sur Google Cloud.
• Consultez le Guide de planification de reprise après sinistre.
• Découvrez la reprise après sinistre pour Microsoft SQL Server.
• Découvrez comment déployer Microsoft SQL Server pour la reprise après sinistre multirégionale.
• Découvrez comment partager des disques entre des instances Compute Engine.
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.

Contributeurs

Auteurs :

• Tom Niedzielak | Ingénieur en développement de systèmes
• Sung Baek | Ingénieur logiciel

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