En utilisant une base de données Microsoft SQL Server à haut niveau de disponibilité pour les données des services ArcGIS, vous évitez toute panne de vos services.
SQL Server propose plusieurs solutions pour assurer un haut niveau de disponibilité. ArcGIS prend en charge des connexions aux groupes de disponibilité AlwaysOn et aux instances de grappes de basculement.
Notez que Microsoft a déconseillé la mise en miroir de bases de données. Utilisez une solution AlwaysOn au lieu de la mise en miroir.
Les sections suivantes expliquent quelles informations sont nécessaires pour se connecter à des bases de données SQL Server à haut niveau de disponibilité à partir d'ArcGIS :
Groupes de disponibilité et instances de cluster de basculement AlwaysOn
Une instance de cluster de basculement fournit une instance SQL Server redondante à laquelle les clients peuvent se connecter si une instance échoue. Les groupes de disponibilité vous permettent de spécifier un ensemble de bases de données principales et jusqu'à quatre ensembles de bases de données secondaires en lecture seule réparties sur des instances de clusters de basculement. Lisez la documentation sur SQL Server AlwaysOn disponible sur le site Microsoft Developer Network avant de mettre en œuvre cette solution.
Une fois la solution AlwaysOn en place, vous pouvez vous y connecter à partir d'ArcGIS en indiquant le nom de l'écouteur du groupe de disponibilité au lieu du nom de l'instance SQL Server. Vous pouvez ajouter des conditions à l'écouteur du groupe en séparant le nom de l'écouteur du groupe et chaque paramètre par des points virgules (;). Vous pouvez ajouter les conditions suivantes :
- APPLICATIONINTENT=READONLY ou APPLICATIONINTENT=READWRITE
- MULTISUBNETFAILOVER=YES ou MULTISUBNETFAILOVER=NO
Si vous n'indiquez aucune valeur pour APPLICATIONINTENT et MULTISUBNETFAILOVER, les valeurs par défaut sont READWRITE et NO, respectivement.
Dans l'exemple suivant, une connexion à une base de données secondaire en lecture seule est établie via l'écouteur de groupe org_agl.
Mise en miroir de la bases de données
Comme indiqué ci-dessus, Microsoft a déconseillé la mise en miroir des bases de données dans SQL Server, mais si vous l'utilisez, vous pouvez fournir des informations de connexion à la fois sur la connexion principale et sur la connexion du serveur miroir pour les données source utilisées pour vos services. Saisissez les informations au format <principal>;MIRROR=<mirror>.
Si le serveur principal devient indisponible, ArcGIS for Server tente automatiquement de se reconnecter. A ce moment, si le serveur miroir est disponible, la connexion du service bascule sur l'utilisation des données qui résident sur le serveur miroir.
Différents scénarios de définition d'une mise en miroir des données sont exposés dans les sections suivantes :
Les ordinateurs de l'éditeur et du serveur utilisent la même base de données
Si la ressource SIG que vous partagez comme service utilise la même base de données que le service publié, et si cette base de données est mise en miroir, fournissez les informations d'instance du serveur principal et du serveur miroir dans le champ Instance de la connexion à la base de données partagée.
Par exemple, si vous créez votre connexion dans la boîte de dialogue Connexion à une base de données dans ArcMap, votre serveur principal est oak\prod, votre miroir est oak2\echo, les bases de données sont datasquared et la connexion ressemblera à ce qui suit :
Les ordinateurs de l'éditeur et du serveur utilisent différentes bases de données
Si votre ressource SIG et votre service publié sont voués à utiliser différentes bases de données pour leurs données source (des géodatabases répliquées ou une base de données gérée), deux connexions distinctes aux bases de données sont définies. Pour assurer une disponibilité élevée de votre service, assurez-vous que le fichier de connexion défini pour l'éditeur utilise la syntaxe de mise en miroir déjà décrite.
Par exemple, si votre service d'entités est destiné à pointer vers des données qui sont copiées dans votre base de données gérée gisdata, qui se trouve sur le serveur willow et est mise en miroir sur le serveur cottonwood, la connexion à votre géodatabase inscrite ressemblera à ce qui suit :
Comme cet exemple utilise des instances SQL Server par défaut, vous pouvez indiquer l'adresse IP de chaque serveur au lieu du nom d'instance SQL Server. Par exemple, si l'adresse IP du serveur willow est 10.10.100.10 et l'adresse IP du serveur cottonwood est 11.11.111.11, saisissez 10.10.100.10;MIRROR=11.11.111.11 dans la zone de texte Instance. Si aucune des instances SQL Server n'écoute sur un port autre que le port du moteur de la base de données par défaut 1433, incluez le numéro de port dans les informations sur la connexion. Par exemple, si l'instance willow écoute sur le port 50000, saisissez 10.10.100.10:50000;MIRROR=11.11.111.11 dans la zone de texte Instance.