Scalabilité de SQL Server dans le Cloud
L’un des fondements du Cloud est l’élasticité qui lui permet de s’adapter à la demande. Nombreux sont les services de la plateforme Azure qui illustrent cette caractéristique. Ainsi, les fonctions d’AutoScaling proposées nativement pour les WebSites, Cloud Services, Machines Virtuelles ou Mobiles Services d’Azure permettent de définir des seuils d’alerte ou d’évolution du nombre d’instances de machines virtuelles en fonction de paramètres tels que l'utilisation du processeur ou de la mémoire.
Peut-on également parler de scalabilité voire d’élasticité lorsqu’il s’agit de service ou de serveur de base de données ?
Si l’on opte pour l’offre PaaS, le service SQL Database propose un modèle de base de données Premium qui permet le choix de différentes configurations fondé sur le niveau d'isolement souhaité pour un client. Ces paramètres permettent de ne payer que la capacité réservée et d’adapter cette capacité à la charge anticipée sur le serveur.
Si l’on souhaite tirer parti du IaaS, les possibilités offertes par le déploiement d’un ou plusieurs serveurs de base de données SQL Server dans Azure nous amènent à considérer les différents scénarios suivants :
· « Scale-up, scale-down d’un serveur SQL standalone s’exécutant dans Azure»
· « Allègement d’un serveur SQL standalone s’exécutant dans Azure par le déploiement de réplicas dans Azure »
· « Scale-up, Scale-down d’un cluster de serveurs SQL AlwaysOn s’exécutant dans Azure »
· « Allègement d’un serveur SQL standalone ou en cluster s’exécutant à demeure par le déploiement de réplicas dans Azure »
« Scale-up, Scale-down d’un Serveur SQL standalone s’exécutant dans Azure »
Supposons que le dimensionnement du serveur SQL ne soit pas adapté à son usage. Il est alors très simple de faire du « scale-up » ou du « scale-down » en modifiant directement la taille de la machine virtuelle hébergeant le serveur SQL, soit depuis le portail Azure (cf copie d’écran), soit avec la Cmdlet Set-AzureVMSize + Update-AzureVM.
Le changement des dimensions de la machine virtuelle entraîne le renouvellement de son deploiement et dans le cas d’un serveur SQL standalone, une interruption de service. Il est très probable que la machine nouvellement provisionnée prenne alors une nouvelle adresse IP. Si la ou les bases de données sont localisées sur un disque attaché, ce disque sera lié à la nouvelle instance et les bases de données seront donc remontées sans difficulté sur la nouvelle instance de machine virtuelle.
« Allègement d’un Serveur SQL standalone s’exécutant dans Azure par le déploiement de réplicas »
En déployant dans le Cloud des réplicas secondaires au sein d’un groupe de disponibilité SQL AlwaysOn, ce scénario permet de décharger le serveur SQL de la production de rapports et des sauvegardes. Cette démarche présente en outre l’avantage de garantir la haute disponibilité du service SQL.
« Availability Set »
Tous les réplicas de disponibilité s’exécutant dans les machines virtuelles Windows Azure doivent être déployés dans le même DataCenter. De plus, les nœuds de haute disponibilité doivent être placés dans un ensemble de disponibilité (« availability set ») permettant de les répartir dans des domaines de faute et de mise à niveau distincts. L’appartenance à un même ensemble de disponibilité requiert un déploiement des machines virtuelles dans le même service de Cloud.
Topologie et configuration
En complément des machines virtuelles hébergeant SQL Server, ce scénario présuppose la configuration de plusieurs éléments pour bâtir la topologie cible:
· Un réseau virtuel contenant plusieurs sous-réseaux : frontend, backend,…
· Un cluster WSFC (Windows Server Failover Clustering), qui, pour fonctionner dans Windows Azure, requiert le déploiement d'un correctif de Windows Server 2012, qu’il faut installer à l'intérieur de chaque machine virtuelle Azure du Cluster WSFC.
· Un contrôleur de domaine et un domaine Active Directory requis par le service WSFC.
· Le déploiement des serveurs SQL dans le sous-réseau backend et leur inscription dans le domaine.
· Un groupe de disponibilité avec le réplica synchrone des bases de données.
L’évolution d’un serveur SQL standalone vers une configuration hautement disponible AlwaysOn peut être réalisée manuellement par la création d’un groupe de disponibilité et la configuration d’un écouteur de groupe de disponibilité (« Availability Group Listener ») ou automatisée par un script PowerShell. Cette deuxième approche se fonde sur l’import de modules PowerShell ciblant directement SQL Server (« sqlps ») et Windows Server Manager («ServerManager Add-WindowsFeature Failover-Clustering»).
Création d’un groupe de disponibilité
La création d’un groupe de disponibilité est détaillée dans la page publiée à l’adresse suivante : AlwaysOn Availability Groups in Windows Azure PowerShell. Cette opération dépend de la configuration d’un cluster WSFC, ce qui présente une difficulté dans Windows Azure.
En effet, il n’est pas possible aujourd’hui d’assigner plusieurs adresses IP à une machine virtuelle, ou de permettre aux adresses IP de basculer d’une machine virtuelle à l'autre. Après avoir créé un cluster WSFC en utilisant deux machines virtuelles Windows Azure, le cluster ne peut pas démarrer car il ne peut pas acquérir une adresse IP virtuelle unique via le service DHCP. Au lieu de cela, l'adresse IP attribuée au cluster est l’adresse de l'un des nœuds, ce qui provoque fatalement la mise en échec du quorum de cluster car les nœuds sont dans l’impossibilité de se connecter correctement les uns aux autres. Cette limite constitue un problème bloquant pour l’implémentation de groupes de disponibilité AlwaysOn.
L'équipe WSFC a donc fourni le script de création du cluster WSFC «CreateAzureFailoverCluster.ps1» qui permet de résoudre cette problématique. Il est téléchargeable depuis l’adresse suivante : Create WSFC Cluster for AlwaysOn Availability Groups in Windows Azure machine virtuelle. Le principe de ce script est d’attribuer au cluster WSFC une adresse IP statique non utilisée, telle que 169.254.1.1, de façon à pouvoir mettre le nom de réseau du cluster en ligne. Par la suite, le nom de réseau du cluster peut être supprimé car il n'est pas utilisé par les groupes de disponibilité.
Configuration d’un écouteur de groupe de disponibilité
La configuration d’un écouteur de groupe de disponibilité est détaillée dans la page publiée à l’adresse suivante : Tutorial: Listener Configuration for AlwaysOn Availability Groups in Windows Azure. Cette fonction n’est aujourd’hui supportée que sur Windows Server 2012. De plus, l'application cliente doit résider sur un service de Cloud différent de celui qui contient le groupe de disponibilité.
En effet, Windows Azure ne supporte pas le retour direct du serveur (« direct server return » : DSR) pour un client et un serveur qui s’exécuteraient dans le même service de Cloud. Ce mode permet au serveur de répondre directement au client sans faire transiter les paquets réseau par le Load Balancer. La configuration du DSR ne peut être réalisée via le Portail Azure. Depuis la sortie du SDK 2.1, elle peut s’effectuer en PowerShell de la façon suivante :
ForEach ($node in $AGNodes)
{
Write-Host "Configuring $node..."
# Create public endpoint on each availability group node
Write-Host " Creating a load-balanced endpoint with DSR enabled..."
Get-AzureVM -ServiceName $ServiceName -Name $node -ErrorAction Stop |
Add-AzureEndpoint `
-Name $EndpointName `
-Protocol "TCP" `
-PublicPort $EndpointPort `
-LocalPort 1433 `
-LBSetName "$EndpointName-LB" `
-ProbePort 59999 `
-ProbeProtocol "TCP" `
-DirectServerReturn$true `
-ErrorAction Stop |
Update-AzureVM -ErrorAction Stop | Out-Null
…. }
Cette configuration est disponible dans le script «ConfigureAGListenerCloudOnly.ps1» téléchargeable depuis l’adresse suivante : Create Availability Group Listener in Windows Azure machine virtuelles (Cloud-Only)
« Scale-up, Scale-down d’un cluster SQL AlwaysOn s’exécutant dans Azure »
De même que pour le redimensionnement du serveur SQL Server standalone, il est très simple de faire du « scale-up » ou du « scale-down » sur les nœuds du cluster WSFC en modifiant directement la taille des machines virtuelles du cluster. A la différence du premier scénario, ce redimensionnement s’effectue sans interruption de service.
« Allègement d’un serveur SQL standalone ou en cluster s’exécutant à demeure par le déploiement de réplicas dans Azure »
Il est possible de créer un réplica de disponibilité d’un serveur SQL à demeure afin qu’il s’exécute sur une machine virtuelle Windows Azure. Ce scénario permet de décharger l’infrastructure à demeure de la production de rapports et des sauvegardes. Cette démarche présente surtout l’avantage de garantir la haute disponibilité du service SQL et la reprise d'activité en multi-sites.
Comme tous les réplicas de disponibilité doivent être dans le même cluster WSFC, celui-ci doit être établi à travers les deux réseaux. Cette configuration nécessite une connexion VPN entre Windows Azure et le réseau à demeure. Pour garantir la reprise d’activité, il faut également installer un contrôleur de domaine dans Azure sur le site de reprise après sinistre.
Ce scénario est décrit à l’adresse suivante : AlwaysOn Availability Groups in Hybrid IT (PowerShell).
Il y aurait sans doute bien d’autres scénarios à détailler pour enrichir cette liste de possibilités qu’offre Azure en termes de scalabilité et de haute disponibilité pour SQL Server. N’hésitez pas à compléter ce premier aperçu par vos suggestions et remarques…