Fournir le nom du serveur explicitement dans les noms d'utilisateur Partie 2: alias DNS pour Azure SQL Database – Microsoft Tech Community – Serveur d’impression

Publié sur MSDN le 5 juin 2018

Dans la continuité du

blog précédent

sur la nécessité de fournir le nom du serveur dans votre nom d'utilisateur lors de la connexion, il existe d'autres scénarios et de nouvelles fonctionnalités où cela devra être pris en considération ou devenir inutile!

Souvent, les utilisateurs voudront utiliser des domaines personnalisés pour se connecter à leurs serveurs, par exemple:

sqlprod01.database.windows.net

est notre serveur SQL Azure DB

sql.mycompany.com

est un enregistrement CNAME qui pointe vers l'enregistrement sqlprod01.database.windows.net pour notre serveur.

Cela, comme le scénario de blog précédent, entraînera une erreur lors de la tentative de connexion si nous ne fournissons pas le nom de notre serveur à l'utilisateur.

Lorsque nous nous connectons à 'sql.mycompany.com', il est considéré comme 'sql' pour le nom de serveur (niveau le plus élevé du nom d'hôte fourni). Ainsi, alors qu'il peut atteindre le

passerelle

dans Azure, nous ne pouvons pas trouver le serveur 'sql' car nous voulons nous connecter à sqlprod01. Bien sûr, nous pouvons ajouter @ sqlprod01 à notre nom d'utilisateur, myuser @ sqlprod01, mais cela à bien des égards va à l'encontre du but du nom d'hôte que nous utilisons en premier lieu.

Avec l'une des nouvelles options disponibles pour Azure SQL DB Server, nous sommes en mesure de créer un nom d'alias DNS pour notre serveur, ce qui peut éliminer ce besoin.

https://docs.microsoft.com/en-us/azure/sql-database/dns-alias-overview

Nous pouvons créer un alias facilement mappable qui peut être à la fois un nom de serveur plus facile à lire mais également permettre à une application d'avoir un nom d'hôte en utilisant l'alias qui ne nécessitera pas de changement même si la base de données correspondante a été déplacée vers un nouveau serveur.

Prenons un scénario où nous avons trois serveurs:

eastusserver001.database.windows.net

eastusserver002.database.windows.net

eastusserver003.database.windows.net

Ces serveurs hébergent de nombreuses bases de données pour de nombreux clients différents. Nous déplacerons souvent les bases de données pour équilibrer nos besoins, mais ne voudrons peut-être pas non plus donner ce nom à nos clients qui souhaitent se connecter à partir d'outils tels que SSMS ou leurs applications. En utilisant Powershell, nous pouvons ajouter et gérer des alias pour ces serveurs afin de créer des alias personnalisés pour chaque locataire.

Voici un exemple de script

à ce sujet, mais suivra la

applets de commande répertoriées ici

.

Processus #Login ici

New-AzureRmSqlServerDnsAlias ​​-ResourceGroupname 'myresourcegroup' -ServerName eastusserver001 -DnsAliasName customer01

New-AzureRmSqlServerDnsAlias ​​-ResourceGroupname 'myresourcegroup -ServerName eastusserver001 -DnsAliasName customer02

New-AzureRmSqlServerDnsAlias ​​-ResourceGroupname 'myresourcegroup' -ServerName eastusserver001 -DnsAliasName customer03

Nous listons ensuite les alias du serveur et voyons chacun assigné au serveur eastusserver001.

Get-AzureRmSqlServerDnsAlias ​​-ResourceGroupname 'nilop-eastus-rg' -ServerName eastusserver001 | Sélectionnez DnsAliasName, ServerName, ResourceGroupName

DnsAliasName ServerName ResourceGroupName

———— ———- —————–

customer01 eastusserver001 myresourcegroup

customer02 eastusserver001 myresourcegroup

customer03 eastusserver001 myresourcegroup

Avec cela, je peux maintenant avoir des entrées de domaine personnalisées qui sont non seulement plus faciles à lire, mais peuvent éviter d'avoir à mettre le nom du serveur dans notre chaîne de connexion.

Maintenant, si pour une raison quelconque, nous devions déplacer la base de données du client vers eastusserver002, l'alias peut être attribué au serveur eastusserver002 à l'aide du

Set-AzureRmSqlServerDnsAlias

applet de commande. Ils peuvent conserver l'alias facile à lire et n'ont pas besoin de mettre à jour leurs chaînes de connexion.