Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
Exporter (0) Imprimer
Développer tout

Didacticiel : Configuration d'un écouteur pour les groupes de disponibilité AlwaysOn

Mis à jour: juin 2015

Cette rubrique explique comment configurer un écouteur pour un groupe de disponibilité AlwaysOn. Votre groupe de disponibilité peut contenir des réplicas locaux uniquement, Azure uniquement, ou locaux et Azure pour les configurations hybrides. Les réplicas Azure peuvent résider dans une même région ou dans plusieurs régions grâce à plusieurs réseaux virtuels.

Les étapes suivantes supposent que vous avez déjà configuré un groupe de disponibilité sans écouteur. Notez les limitations suivantes sur l'écouteur du groupe de disponibilité dans Azure :

  • L'écouteur du groupe de disponibilité est pris en charge sur Windows Server 2008 R2, Windows Server 2012 et Windows Server 2012 R2.

  • Lorsque vous déployez un écouteur à l'aide de l'adresse IP virtuelle (VIP), l'application cliente doit résider sur un service cloud différent que celui qui contient vos machines virtuelles de groupe de disponibilité. Azure ne prend pas en charge le retour au serveur direct avec un client et un serveur résidant dans le même service cloud.

  • Un seul écouteur du groupe de disponibilité est pris en charge par le service cloud, car l'écouteur est configuré pour utiliser l'adresse IP du service cloud ou l'adresse IP virtuelle (VIP) de l'équilibrage de charge interne.

    ImportantImportant
    Cette limitation est toujours en vigueur, même si Azure prend désormais en charge la création de plusieurs adresses IP virtuelles dans un service cloud donné.

  • Si vous créez un écouteur pour un environnement hybride, le réseau local doit disposer de la connectivité à l'Internet public en plus du VPN de site à site avec le réseau virtuel Azure. Dans le sous-réseau Azure, l'écouteur du groupe de disponibilité est accessible uniquement par l'adresse IP publique du service cloud respectif.

ImportantImportant
Ce didacticiel porte sur l'utilisation de PowerShell pour créer un écouteur pour un groupe de disponibilité incluant des réplicas Azure. Pour plus d'informations sur la configuration des écouteurs à l'aide de SSMS ou Transact-SQL, consultez Création ou configuration d'un écouteur de groupe de disponibilité.

Vous devez commencer par décider s'il faut utiliser un équilibrage de charge externe (public) ou interne (privé) pour l'écouteur. Si le serveur de base de données doit être accessible en dehors du réseau virtuel (VNet) qui contient le groupe de disponibilité, vous devez utiliser un public load balancing avec une adresse IP publique accessible à partir d'Internet. En revanche, si vous accédez uniquement à l'écouteur dans le réseau virtuel (y compris les VPN de site à site dans des scénarios hybrides), vous devez utiliser un Internal Load Balancing (ILB) avec une adresse IP privée pour l'écouteur. Étant donné que l'équilibrage de charge interne n'est pas accessible depuis l'extérieur du réseau virtuel Azure, cela offre une autre couche de sécurité. Dans le reste de ce didacticiel, certaines sections décrivent des différentes étapes pour les configurations d'public load balancing et d'Internal Load Balancing. Veuillez suivre les instructions relatives à l'approche sélectionnée.

noteRemarque
L'équilibrage de charge interne peut être configuré uniquement sur des réseaux virtuels d'une étendue régionale. Les réseaux virtuels existants qui ont été configurés pour un groupe d'affinités ne peuvent pas utiliser l'équilibrage de charge interne. Pour plus d'informations, consultez Équilibrage de charge interne.

Pour l'équilibrage de charge interne, vous devez commencer par créer le système d'équilibrage de charge interne. Pour ce faire, utilisez le script ci-dessous. Dans l'équilibrage de charge interne et l'équilibrage de charge public, vous devez créer un point de terminaison avec équilibrage de charge pour chaque machine virtuelle qui héberge un réplica Azure. Si vous avez des réplicas dans plusieurs régions, chaque réplica de cette région doit se trouver dans le même service cloud sur le même réseau virtuel. La création de réplicas de groupe de disponibilité couvrant plusieurs régions Azure nécessite de configurer plusieurs réseaux virtuels. Pour plus d'informations sur la configuration de la connectivité de réseau virtuel intersites, consultez Configuration de la connectivité de réseau virtuel à réseau virtuel.

  1. Dans le portail Azure, accédez à chaque machine virtuelle hébergeant un réplica et consultez les détails.

  2. Cliquez sur l'onglet Points de terminaison de chacune des machines virtuelles.

  3. Vérifiez que le Nom et le Port public du point de terminaison de l'écouteur ne sont pas déjà utilisés. Dans l'exemple ci-dessous, le nom est « MyEndpoint » et le port est « 1433 ».

  4. Sur votre client local, téléchargez et installez le dernier module PowerShell.

  5. Démarrez Azure PowerShell. Une nouvelle session PowerShell s'ouvre avec les modules d'administration Azure chargés.

  6. Exécutez Get-AzurePublishSettingsFile. Cette applet de commande vous dirige vers un navigateur de façon à télécharger un fichier de paramètres de publication dans un répertoire local. Vous serez peut-être invité à entrer vos informations d'identification de connexion pour votre abonnement Azure.

  7. Exécutez la commande Import-AzurePublishSettingsFile avec le chemin d'accès du fichier de paramètres de publication que vous avez téléchargé :

    Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
    

    Une fois le fichier de paramètres de publication importé, gérez votre abonnement Azure dans la session PowerShell.

  8. Si vous utilisez public load balancing, poursuivez cette étape. Si vous utilisez Internal Load Balancing (ILB), passez à l'étape suivante. Copiez le script PowerShell ci-dessous dans un éditeur de texte et définissez les valeurs de variables adaptées à votre environnement. Notez que, si votre groupe de disponibilité s'étend sur plusieurs régions Azure, vous devez exécuter le script une fois dans chaque centre de données pour le service cloud et les nœuds qui résident dans ce centre de données.

    # Define variables
    $ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
    $AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
    $EndpointName = "MyEndpoint" # name of the endpoint
    $EndpointPort = "1433" # public port to use for the endpoint
    
    # Configure a load balanced endpoint for each node in $AGNodes, with direct server return enabled
    ForEach ($node in $AGNodes)
    {
        Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -Protocol "TCP" -PublicPort $EndpointPort -LocalPort $EndpointPort -LBSetName "$EndpointName-LB" -ProbePort 59999 -ProbeProtocol "TCP" -DirectServerReturn $true | Update-AzureVM
    }
    
  9. Si vous utilisez Internal Load Balancing (ILB), poursuivez cette étape. Si vous utilisez public load balancing, passez à l'étape suivante. Pour un ILB, vous devez attribuer une adresse IP statique. Commencez par examiner la configuration du réseau en exécutant la commande suivante :

    (Get-AzureVNetConfig).XMLConfiguration
    

    Notez d'abord le nom Subnet du sous-réseau qui contient les machines virtuelles qui hébergent les réplicas. Celui-ci sera utilisé dans le paramètre $SubnetName du script. Notez ensuite le nom VirtualNetworkSite et la valeur AddressPrefix pour le sous-réseau contenant les machines virtuelles qui hébergent les réplicas. Recherchez ensuite une adresse IP disponible en passant les deux valeurs à la commande Test-AzureStaticVNetIP, et en examinant la valeur AvailableAddresses. Par exemple, si le réseau virtuel est nommé MyVNet et a une plage d'adresses de sous-réseau démarrant à 172.16.0.128, la commande suivante répertorie les adresses disponibles :

    (Test-AzureStaticVNetIP -VNetName "MyVNet" -IPAddress 172.16.0.128).AvailableAddresses
    

    Choisissez une des adresses disponibles et utilisez-la dans le paramètre $ILBStaticIP du script suivant.

    Copiez le script PowerShell ci-dessous dans un éditeur de texte et définissez les valeurs de variables adaptées à votre environnement. Notez que des déploiements existants qui utilisent des groupes d'affinités ne peuvent pas ajouter un équilibrage de charge interne. Pour plus d'informations sur les exigences d'équilibrage de charge interne, consultez Équilibrage de charge interne. Notez que, si votre groupe de disponibilité s'étend sur plusieurs régions Azure, vous devez exécuter le script une fois dans chaque centre de données pour le service cloud et les nœuds qui résident dans ce centre de données.

    # Define variables
    $ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
    $AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
    $EndpointName = "<MyEndpoint>" # name of the endpoint
    $EndpointPort = "1433" # public port to use for the endpoint
    $ILBName = "<MyInternalLoadBalancer>" # chosen name for the new ILB
    $SubnetName = "<MySubnetName>" # subnet name that the replicas use in the VNet
    $ILBStaticIP = "<MyILBStaticIPAddress>" # static IP address for the ILB in the subnet
    
    Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP
    
    # Configure a load balanced endpoint for each node in $AGNodes using ILB
    ForEach ($node in $AGNodes)
    {
    Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -LBSetName "$EndpointName-LB" -Protocol tcp -LocalPort $EndpointPort -PublicPort $EndpointPort -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM 
    }
    
  10. Après avoir défini les variables, copiez le script de l'éditeur de texte dans votre session Azure PowerShell pour l'exécuter. Si l'invite affiche >>, appuyez sur Entrée pour vous assurer que le script s'exécute.

    noteRemarque
    Le portail de gestion Azure ne prend pas en charge l'équilibrage de charge interne actuellement. Vous ne verrez donc pas l'équilibrage de charge interne ou les points de terminaison dans le portail. En revanche, Get-AzureEndpoint renvoie une adresse IP interne si l'équilibrage de charge s'exécute sur cette commande. Sinon, la valeur renvoyée est null.

Ensuite, si tous les serveurs du cluster exécutent Windows Server 2008 R2 ou Windows Server 2012, vous devez installer le correctif logiciel KB2854082 sur chaque du serveur local ou machine virtuelle Azure faisant partie du cluster. Ce correctif logiciel doit également être installé pour tous les serveurs ou toutes les machines virtuelles qui font partie du cluster, mais pas du groupe de disponibilité.

Dans la session Bureau à distance de chacun des nœuds du cluster, téléchargez le correctif logiciel KB2854082 dans un répertoire local. Ensuite, installez le correctif logiciel sur chacun des nœuds du cluster de manière séquentielle. Si le service de cluster est en cours d'exécution sur le nœud du cluster, le serveur redémarre à l'issue de l'installation du correctif logiciel.

WarningAvertissement
L'arrêt du service de cluster ou le redémarrage du serveur affecte l'intégrité du quorum de votre cluster et le groupe de disponibilité, et peut entraîner la mise hors connexion du cluster. Pour assurer la haute disponibilité du cluster lors de l'installation, veillez à ce que :

  • le cluster soit dans une intégrité de quorum optimale,

  • tous les nœuds de cluster soient en ligne avant d'installer le correctif logiciel sur un nœud, et

  • l'installation du correctif logiciel s'exécute jusqu'à achèvement sur un nœud, notamment redémarrage du serveur, avant installation sur un autre nœud du cluster.

Au cours de cette étape, vous allez créer une règle de pare-feu pour ouvrir le port de la sonde du point de terminaison à charge équilibrée (59999, tel que cela est indiqué précédemment), et une autre règle pour ouvrir le port de l'écouteur du groupe de disponibilité. Étant donné que vous avez créé le point de terminaison à charge équilibrée sur chacune des machines virtuelles Azure qui contiennent des réplicas du groupe de disponibilité, vous devez ouvrir le port de la sonde et le port de l'écouteur sur les machines virtuelles Azure respectives.

  1. Sur les machines virtuelles hébergeant les réplicas, démarrez le Pare-feu Windows avec fonctions avancées de sécurité.

  2. Cliquez avec le bouton droit sur Règles de trafic entrant et sélectionnez Nouvelle règle.

  3. Dans la page Type de règle, sélectionnez Port, puis cliquez sur Suivant.

  4. Dans la page Protocole et ports, sélectionnez TCP et tapez 59999 dans la zone Ports locaux spécifiques. Ensuite, cliquez sur Suivant.

  5. Dans la page Action, sélectionnez Autoriser la connexion et cliquez sur Suivant.

  6. Dans la page Profil, acceptez les paramètres par défaut et cliquez sur Suivant.

  7. Dans la page Nom, spécifiez un nom pour la règle, comme Port de la sonde d'écouteur AlwaysOn dans la zone de texte Nom, puis cliquez sur Terminer.

  8. Répétez les étapes ci-dessus pour le port de l'écouteur du groupe de disponibilité (comme spécifié précédemment à l'aide du paramètre $EndpointPort du script), puis spécifiez un nom de règle approprié, tel que Port de l'écouteur AlwaysOn.

Au cours de cette étape, vous allez créer manuellement l'écouteur du groupe de disponibilité dans le Gestionnaire du cluster de basculement et SQL Server Management Studio (SSMS).

  1. Ouvrez le Gestionnaire du cluster de basculement à partir du nœud hébergeant le réplica principal.

  2. Sélectionnez le nœud Networks, puis notez le nom réseau du cluster. Celui-ci sera utilisé dans la variable $ClusterNetworkName du script PowerShell.

  3. Développez le nom du cluster, puis cliquez sur Rôles.

  4. Dans le volet Rôles, cliquez avec le bouton droit sur le nom du groupe de disponibilité, puis sélectionnez Ajouter une ressource > Point d'accès client.

    Ajouter un point d'accès client pour un groupe de disponibilité

  5. Dans la zone Nom, tapez un nom pour ce nouvel écouteur, cliquez sur Suivant à deux reprises, puis cliquez sur Terminer. Ne mettez pas l'écouteur ou la ressource en ligne à ce stade.

  6. Cliquez sur l'onglet Ressources, puis développez le point d'accès client que vous venez de créer. Vous verrez la ressource Adresse IP pour chacun des réseaux de votre cluster. S'il s'agit d'une solution uniquement Azure, une seule ressource d'adresse IP s'affiche.

  7. Si vous configurez une solution hybride, continuez avec cette étape. Si vous configurez une solution Azure uniquement, passez à l'étape suivante.

    1. Cliquez avec le bouton droit sur la ressource d'adresse IP qui correspond à votre sous-réseau local, puis sélectionnez Propriétés. Notez le nom de l'adresse IP et le nom du réseau.

    2. Sélectionnez Adresse IP statique, affectez une adresse IP inutilisée, puis cliquez sur OK.



  8. Cliquez avec le bouton droit sur la ressource IP qui correspond à votre sous-réseau Azure, puis sélectionnez Propriétés.

    TipConseil
    Si l'écouteur ne parvient pas à se mettre en ligne en raison de la sélection d'une adresse IP conflictuelle par DHCP, vous pouvez configurer une adresse IP statique valide dans cette fenêtre de propriétés.

  9. Dans la même fenêtre de propriétés Adresse IP, modifiez le Nom de l'adresse IP. Celui-ci sera utilisé dans la variable $IPResourceName du script PowerShell. Répétez cette étape pour chaque ressource IP si votre solution englobe plusieurs réseaux virtuels Azure.

  10. Si vous utilisez public load balancing, poursuivez cette étape. Si vous utilisez Internal Load Balancing, passez à l'étape suivante. Pour public load balancing, vous devez obtenir l'adresse IP virtuelle publique du service cloud qui contient vos réplicas. Connectez-vous au portail Azure. Accédez au service cloud qui contient les machines virtuelles du groupe de disponibilité. Ouvrez le Tableau de bord. Notez l'adresse affichée sous Adresse IP virtuelle (VIP) publique. Si votre solution couvre des réseaux virtuels, répétez cette étape pour chaque service cloud contenant une machine virtuelle qui héberge un réplica.

    Sur chaque machine virtuelle, copiez le script PowerShell ci-dessous dans un éditeur de texte, et affectez aux variables aux valeurs notées précédemment.

    # Define variables
    $ClusterNetworkName = "<ClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
    $IPResourceName = "<IPResourceName>" # the IP Address resource name 
    $CloudServiceIP = "<X.X.X.X>" # Public Virtual IP (VIP) address of your cloud service
    
    Import-Module FailoverClusters
    
    # If you are using Windows Server 2012 or higher, use the Get-Cluster Resource command. If you are using Windows Server 2008 R2, use the cluster res command. Both commands are commented out. Choose the one applicable to your environment and remove the # at the beginning of the line to convert the comment to an executable line of code. 
    
    # Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$CloudServiceIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}
    # cluster res $IPResourceName /priv enabledhcp=0 overrideaddressmatch=1 address=$CloudServiceIP probeport=59999  subnetmask=255.255.255.255
    
  11. Si vous utilisez Internal Load Balancing (ILB), poursuivez cette étape. Si vous utilisez public load balancing, passez à l'étape suivante. Pour l'équilibrage de charge interne, vous devez utiliser l'adresse IP de l'équilibrage de charge interne créé précédemment. Utilisez le script suivant pour obtenir cette adresse IP dans PowerShell.

    # Define variables
    $ServiceName = "<MyServiceName>" # the name of the cloud service that contains the AG nodes
    (Get-AzureInternalLoadBalancer -ServiceName $ServiceName).IPAddress
    

    Sur chaque machine virtuelle, copiez le script PowerShell ci-dessous dans un éditeur de texte, et affectez aux variables aux valeurs notées précédemment.

    # Define variables
    $ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
    $IPResourceName = "<IPResourceName>" # the IP Address resource name 
    $ILBIP = “<X.X.X.X># the IP Address of the Internal Load Balancer (ILB)
    
    Import-Module FailoverClusters
    
    # If you are using Windows Server 2012 or higher, use the Get-Cluster Resource command. If you are using Windows Server 2008 R2, use the cluster res command. Both commands are commented out. Choose the one applicable to your environment and remove the # at the beginning of the line to convert the comment to an executable line of code. 
    
    # Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}
    # cluster res $IPResourceName /priv enabledhcp=0 overrideaddressmatch=1 address=$ILBIP probeport=59999  subnetmask=255.255.255.255
    
  12. Une fois que vous avez défini les variables, ouvrez une fenêtre Windows PowerShell avec élévation de privilèges, copiez le script de l'éditeur de texte et collez-le dans votre session Azure PowerShell pour l'exécuter. Si l'invite affiche >>, appuyez sur Entrée pour vous assurer que le script s'exécute. Répétez cette opération sur chaque machine virtuelle.

    Ce script configure la ressource Adresse IP avec l'adresse IP du service cloud et définit d'autres paramètres, tels que le port de la sonde. Lorsqu'une ressource Adresse IP est mise en ligne, elle répond à l'interrogation sur le port de la sonde du point de terminaison à charge équilibrée créé précédemment dans ce didacticiel.

  13. Revenez au Gestionnaire du cluster de basculement. Développez Rôles, puis sélectionnez votre groupe de disponibilité. Sous l'onglet Ressources, cliquez avec le bouton droit sur le nom de l'écouteur, puis cliquez sur Propriétés.

  14. Cliquez sur l'onglet Dépendances. Si plusieurs ressources sont répertoriées, vérifiez que les adresses IP ont des dépendances OR et non AND. Cliquez sur OK.

  15. Cliquez avec le bouton droit sur le nom de l'écouteur, puis cliquez sur Mettre en ligne.

  16. Une fois l'écouteur en ligne, sous l'onglet Ressources, cliquez avec le bouton droit sur le groupe de disponibilité, puis cliquez sur Propriétés.

    Configurer la ressource de groupe de disponibilité

  17. Créez une dépendance sur la ressource de nom d'écouteur (pas sur le nom des ressources d'adresse IP). Cliquez sur OK.

    Ajouter une dépendance au nom d'écouteur

  18. Lancez SQL Server Management Studio et connectez-vous au réplica principal.

  19. Accédez à Haute disponibilité AlwaysOn | Groupes de disponibilité | <AvailabilityGroupName> | Écouteurs de groupe de disponibilité. L'écouteur créé dans le Gestionnaire du cluster de basculement doit s'afficher. Cliquez avec le bouton droit sur le nom de l'écouteur, puis cliquez sur Propriétés.

  20. Dans le champ Port, spécifiez le numéro de port de l'écouteur du groupe de disponibilité à l'aide du paramètre $EndpointPort utilisé précédemment (dans ce didacticiel, 1433 était suggéré), puis cliquez sur OK.

Une fois l'écouteur du groupe de disponibilité créé, il peut être nécessaire d'ajuster les paramètres de cluster RegisterAllProvidersIP et HostRecordTTL pour la ressource d'écouteur. Ces paramètres peuvent réduire le délai de reconnexion après un basculement, ce qui peut empêcher l'application des délais d'expiration de connexion. Pour plus d'informations sur ces paramètres et obtenir un exemple de code, consultez Création ou configuration d'un écouteur de groupe de disponibilité.

Au cours de cette étape, vous allez tester l'écouteur du groupe de disponibilité à l'aide d'une application cliente s'exécutant sur le même réseau.

Pour la connectivité client, veuillez noter les exigences suivantes :

  • Les connexions client à l'écouteur doivent provenir de machines qui résident dans un service cloud différent de celui qui héberge les réplicas de disponibilité AlwaysOn.

  • Si les réplicas AlwaysOn se situent dans des sous-réseaux différents, les clients doivent spécifier « MultisubnetFailover = True » dans la chaîne de connexion. Cela entraîne des tentatives parallèles de connexion aux réplicas dans les différents sous-réseaux. Notez que ce scénario inclut un déploiement de groupe de disponibilité AlwaysOn sur plusieurs régions.

Un exemple serait de se connecter à l'écouteur à partir de l'une des machines virtuelles qui se situent dans le même réseau virtuel Azure (mais n'hébergeant pas de réplica). Un moyen simple d'effectuer ce test consiste à connecter SSMS à l'écouteur du groupe de disponibilité. Une autre méthode simple consiste à exécuter SQLCMD.exe comme suit :

sqlcmd -S "<ListenerName>,<EndpointPort>" -d "<DatabaseName>" -Q "select @@servername, db_name()" -l 15
TipConseil
Notez que, si la valeur EndpointPort est 1433, il n'est pas nécessaire de la spécifier dans l'appel. L'appel précédent suppose également que la machine cliente est jointe au même domaine, et que l'appelant a reçu des autorisations sur la base de données à l'aide de l'authentification Windows.

Lorsque vous testez l'écouteur, procédez au basculement du groupe de disponibilité pour vérifier que les clients se connectent à l'écouteur d'un basculement à un autre.

En cas de public load balancing, le test précédent ne fonctionne pas en dehors du réseau virtuel Azure. Pour accéder à l'écouteur à partir de l'extérieur du réseau virtuel, vous devez spécifier le nom du service cloud. Pour un service cloud nommé mycloudservice, l'instruction sqlcmd se présente comme suit :

sqlcmd -S "mycloudservice.cloudapp.net,<EndpointPort>" -d "<DatabaseName>" -U "<LoginId>" -P "<Password>"  -Q "select @@servername, db_name()" -l 15

Contrairement à l'exemple précédent, l'authentification SQL est nécessaire, car l'appelant ne peut pas utiliser l'authentification Windows sur Internet. Pour plus d'informations, consultez la page Groupe de disponibilité AlwaysOn dans les machines virtuelles Microsoft Azure : scénarios de connectivité client. En cas d'utilisation d'une authentification SQL, veillez à créer la même connexion sur les deux réplicas. Pour plus d'informations sur le dépannage des connexions avec des groupes de disponibilité, consultez comment mapper des connexions ou utiliser une base de données SQL à relation contenant-contenu pour se connecter à d'autres réplicas et mapper aux bases de données de disponibilité.

Si les réplicas AlwaysOn se situent dans des sous-réseaux différents, les clients doivent spécifier « MultisubnetFailover = True » dans la chaîne de connexion. Cela entraîne des tentatives parallèles de connexion aux réplicas dans les différents sous-réseaux. Notez que ce scénario inclut un déploiement de groupe de disponibilité AlwaysOn sur plusieurs régions.

noteRemarque
Le test décrit dans cette étape ne fonctionne pas avec un équilibrage de charge interne, car l'équilibrage de charge interne est inaccessible à partir de l'extérieur du réseau virtuel Azure.

Voir aussi

Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2015 Microsoft