Problème▲
On dispose d'un serveur SQL Server à demeure non redondé, sur un serveur que nous appelons ici « dans-mes-murs ». Il peut s'agir par exemple d'un des serveurs de la plateforme de tests d'intégration. Dans cet exemple, il est installé en SQL Server 2014 CTP2 sur un Windows Server 2012 R2, mais ce qui est expliqué ici fonctionne dans bon nombre de versions antérieures à la fois de SQL Server et de Windows.
On souhaite faire en sorte que la base de données soit redondée dans le nuage de façon à disposer d'une solution de secours si la machine « dans-mes-murs » tombe en panne.
Dans l'exemple, la base de données est AdventureWorksLT.
Choix de la solution▲
L'article suivant propose un certain nombre de solutions.
Étant donné que cet article s'adresse principalement à des développeurs, on choisit une solution qui ne nécessite pas de VPN, et une configuration réseau simple. On prend donc la solution à base de database mirroring qui est expliquée plus en détail à cette adresse :
On s'inspirera librement de cet article.
La solution mise en place aura pour principe le schéma suivant :
Le serveur à demeure établit une relation avec une autre instance SQL Server dans une machine virtuelle (VM) dans le datacenter d'Europe du Nord (North Europe, NE) de Windows Azure. Cette machine virtuelle a elle-même ses disques OS et des données dans un compte de stockage répliqué sur un autre datacenter. Pour l'Europe du Nord (NE), la réplication est en Europe de l'Ouest (West Europe, WE). Ainsi, même dans le cas où le datacenter NE serait inaccessible durablement, les équipes Windows Azure rendraient les données du blob storage disponible dans le datacenter de l'Europe de l'Ouest où l'on pourrait remonter une VM avec la base de données.
Mise en œuvre de la solution▲
Comme les développeurs aiment le code, la mise en place de la solution s'appuie sur du code !
Les copies d'écrans seront ici principalement pour montrer le résultat de ce que le code a généré, mais en général les modifications sont faites par le code. Donc du code, du code, du code.
Avertissement▲
Dans les exemples de code donnés ci-dessous, les noms de compte de stockage, de service Windows Azure, les mots de passe… doivent être changés. Vous êtes encouragés à relire le code et le modifier avant de l'utiliser dans votre environnement.
Téléchargement et installation du module PowerShell pour gérer Windows Azure▲
Pour manipuler l'environnement Windows Azure depuis du code et depuis une machine Windows, PowerShell est un excellent environnement. PowerShell lui-même fait partie de Windows depuis déjà un certain nombre d'années. En revanche, le module de gestion de Windows Azure doit être téléchargé. Depuis la machine « dans-mes-murs », on se rend donc à l'adresse suivante :
http://www.windowsazure.com/fr-fr/downloads/#cmd-line-tools
On télécharge et installe ce module :
Puis on exécute Windows PowerShell :
Et l'on tape les commandes suivantes :
Import-module azure
Get-command -module azure
Ensuite, on ajoute le compte avec lequel on peut se connecter au portail Windows Azure (http://manage.windowsazure.com) de façon à pouvoir disposer des mêmes ressources depuis PowerShell.
N.B. Si vous n'avez pas de compte Windows Azure, vous pouvez vous en procurer un avec l'offre d'essai gratuite. Rendez-vous par exemple à http://aka.ms/tester-mon-azure.
Tapez en PowerShell :
Add-AzureAccount
Puis laissez-vous guider :
Une façon de vérifier que tout est correct est de taper :
Get-AzureSubscription
Cela doit vous donner la liste des abonnements auxquels votre compte entré ci-dessus a droit.
La suite des opérations dans PowerShell se fera dans l'IDE de PowerShell appelé ISE. On le démarre de la façon suivante :
Le bouton (ou F5) permet d'exécuter tout le script saisi.
Le bouton (ou F8) permet d'exécuter uniquement le code sélectionné.
Si on dispose de plusieurs abonnements Azure, comme c'est mon cas, on peut choisir l'abonnement par défaut de la façon suivante :
Select-AzureSubscription -Default "Azdem169A44055X"
Dans votre cas, remplacez Azdem169A44055X par le nom de votre propre abonnement.
Configuration de l'instance SQL Server locale▲
Commençons par configurer l'instance SQL Server locale, comme précisé dans le document [2] référencé ci-dessus.
N.B. On ne renomme pas le serveur ni l'instance SQL Server. Les deux s'appellent « dans-mes-murs », et on a adapté le code de l'article [2].
Commençons par le firewall :
netsh advfirewall firewall add rule `
name='SQL Server (TCP-In)' `
program='C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Binn\sqlservr.exe' `
dir=in `
action=allow `
protocol=TCP
Ensuite, on active le protocole TCP et on redémarre SQL Server :
[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo")
[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.SqlWmiManagement")
$wmi = new-object ("Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer") $env:COMPUTERNAME
$wmi.ServerInstances['MSSQLSERVER'].ServerProtocols['Tcp'].IsEnabled = "True"
$wmi.ServerInstances['MSSQLSERVER'].ServerProtocols['Tcp'].Alter()
$svc = Get-Service -Name 'MSSQLSERVER'
$timeout = New-Object System.TimeSpan -ArgumentList 0, 0, 30
$svc.Stop();
$svc.WaitForStatus([System.ServiceProcess.ServiceControllerStatus]::Stopped,$timeout)
$svc.Start();
$svc.WaitForStatus([System.ServiceProcess.ServiceControllerStatus]::Stopped,$timeout)
Le timeout de 30 secondes peut se révéler insuffisant, mais cela est peu important. Vous pouvez revérifier l'état du service en sélectionnant le code suivant et en tapant F8 :
Ce qui vous montrera, par exemple, que le service a bien redémarré :
De même, en sélectionnant :
$wmi.ServerInstances['MSSQLSERVER'].ServerProtocols['Tcp'].IsEnabled
Vous verrez si TCP est bien disponible :
Instanciation d'une machine virtuelle dans Windows Azure▲
Il est ensuite temps de créer une machine virtuelle Windows Azure avec SQL Server.
On commence par positionner les différentes variables dont nous aurons besoin :
$workingDir = "C:\workingDirectory\"
$location = "North Europe"
$affinityGroupName = "ContosoAG"
$affinityGroupDescription = "Contoso SQL HADR Affinity Group"
$affinityGroupLabel = "IaaS SQL Affinity Group"
$virtualNetworkName = "ContosoNET"
$localNetworkName = "ContosoNETLocal"
$networkConfigPath = $workingDir + "NetworkConfig.xml"
$storageAccountName = "sqlnuage"
$storageAccountLabel = "Contoso SQL HADR Storage Account"
$storageAccountContainer = "https://$storageAccountName.blob.core.windows.net/vhds/"
$sqlImageName = (Get-AzureVMImage | where {$_.ImageFamily -EQ "SQL Server 2014 on WS 2012 R2"} | sort PublishedDate -Descending)[0].ImageName
$serviceName = "sqlnuage"
$sqlServerName = "sqlnuage"
$vmAdminUser = "AzureAdmin"
$vmAdminPassword = "BXkikovn14_____"
$subnetName = "Back"
L'exécution de cela positionne les variables qui restent disponibles dans la session PowserShell ISE, même depuis du code venant de différents onglets.
Pour élaborer la ligne suivante :
Get-AzureVMImage | where {$_.ImageFamily -EQ "SQL Server 2014 on WS 2012 R2"
Il faut connaître les familles d'images disponibles. Tout d'abord, les images sont celles que l'on trouve dans le portail :
Pour avoir la liste des familles d'images, il suffit d'exécuter le code suivant :
Get-AzureVMImage | select -unique ImageFamily | sort -Property ImageFamily
Ce qui donne par exemple au moment de l'écriture de cet article le résultat suivant :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
PS C:\Windows\system32> Get-AzureVMImage | select -unique ImageFamily | sort -Property ImageFamily
ImageFamily
-----------
Java Platform, Standard Edition 6 on WS 2012 (Preview)
Java Platform, Standard Edition 7 on WS 2012 (Preview)
openSUSE 12.3
Oracle Database
Oracle Database 12c and WebLogic Server 12c Enterprise Edition on WS 2012 (Preview)
Oracle Database 12c and WebLogic Server 12c Standard Edition on WS 2012 (Preview)
Oracle Database 12c Enterprise Edition on WS 2012 (Preview)
Oracle Database 12c Standard Edition on WS 2012 (Preview)
Oracle Database Standard
Oracle Linux
Oracle Weblogic
Oracle WebLogic Server 11g Enterprise Edition on WS 2008 R2 (Preview)
Oracle WebLogic Server 11g Standard Edition on WS 2008 R2 (Preview)
Oracle WebLogic Server 12c Enterprise Edition on WS 2012 (Preview)
Oracle WebLogic Server 12c Standard Edition on WS 2012 (Preview)
RightScale Linux v13
RightScale Windows v13
SharePoint Server 2013 Trial
SQL Server 2008 R2 SP2 Enterprise on WS 2008 R2
SQL Server 2008 R2 SP2 Standard on WS 2008 R2
SQL Server 2008 R2 SP2 Web on WS 2008 R2
SQL Server 2012 SP1 Enterprise on WS 2008 R2
SQL Server 2012 SP1 Enterprise on WS 2012
SQL Server 2012 SP1 for data warehousing on WS 2012
SQL Server 2012 SP1 Standard on WS 2008 R2
SQL Server 2012 SP1 Standard on WS 2012
SQL Server 2012 SP1 Web on WS 2008 R2
SQL Server 2014 CTP2 Evaluation for Data Warehousing on WS 2012
SQL Server 2014 on WS 2012
SQL Server 2014 on WS 2012 R2
SUSE Linux Enterprise Server 11 SP2
SUSE Linux Enterprise Server 11 SP3
Ubuntu Server 12.04 LTS
Ubuntu Server 12.04 LTS DAILY
Ubuntu Server 12.10
Ubuntu Server 12.10 DAILY
Ubuntu Server 13.04
Ubuntu Server 13.04 DAILY
Ubuntu Server 13.10
Ubuntu Server 13.10 DAILY
Ubuntu Server 14.04 LTS DAILY
Visual Studio Premium 2013
Visual Studio Professional 2013
Visual Studio Ultimate 2013
Windows Server 2008 R2 SP1
Windows Server 2012 Datacenter
Windows Server 2012 R2 Datacenter
Windows Server Essentials Experience on WS 2012 R2
La famille sélectionnée sera : SQL Server 2014 on WS 2012 R2 (ligne 36).
L'image que nous utiliserons ici est la suivante :
Les variables étant positionnées, on peut créer un groupe d'affinité :
New-AzureAffinityGroup `
-Name $affinityGroupName `
-Location $location `
-Description $affinityGroupDescription `
-Label $affinityGroupLabel
Et l'on peut vérifier l'effet dans le portail :
Pour créer le réseau virtuel, on crée un dossier et un fichier texte C:\WorkingDirectory\NetworkConfig.xml :
Encodé en UTF-8 (« save as » dans Notepad) qui contient le code suivant :
<NetworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
<VirtualNetworkConfiguration>
<Dns />
<VirtualNetworkSites>
<VirtualNetworkSite name="ContosoNET" AffinityGroup="ContosoAG">
<AddressSpace>
<AddressPrefix>10.10.0.0/16</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Back">
<AddressPrefix>10.10.1.0/24</AddressPrefix>
</Subnet>
</Subnets>
</VirtualNetworkSite>
</VirtualNetworkSites>
</VirtualNetworkConfiguration>
</NetworkConfiguration>
La machine virtuelle sera dans le sous-réseau 10.10.1.*.
N.B. L'utilisation d'un réseau n'est pas indispensable dans ce scénario, mais l'exemple de l'article [2] l'utilise, donc on a gardé cela. Cela ne complique pas beaucoup et permet une meilleure évolutivité.
L'utilisation de ce fichier se fait en PowerShell :
Set-AzureVNetConfig `
-ConfigurationPath $networkConfigPath
Ce qui donne ce résultat dans le portail :
Ensuite, on crée un compte de stockage dans le groupe d'affinité, et on définit ce compte de stockage comme étant celui par défaut, pour l'abonnement par défaut, dans lequel on travaille dans cette session PowserShell ISE :
New-AzureStorageAccount `
-StorageAccountName $storageAccountName `
-Label $storageAccountLabel `
-AffinityGroup $affinityGroupName
Set-AzureSubscription -SubscriptionName (Get-AzureSubscription -Default).SubscriptionName `
-CurrentStorageAccountName $storageAccountName
On notera que le compte de stockage a son option de géo-réplication activée, ce qui correspond à cette partie de ce que nous voulions :
New-AzureVMConfig `
-Name $sqlServerName `
-InstanceSize Large `
-ImageName $sqlImageName `
-MediaLocation "$storageAccountContainer$sqlServerName.vhd" `
-DiskLabel "OS" |
Add-AzureProvisioningConfig `
-Windows `
-Password $vmAdminPassword `
-AdminUserName $vmAdminUser `
-DisableAutomaticUpdates ` |
Set-AzureSubnet `
-SubnetNames $subnetName |
Add-AzureEndpoint `
-Name "SQL" `
-Protocol "tcp" `
-PublicPort 1433 `
-LocalPort 1433 |
Add-AzureEndpoint `
-Name "mirroring" `
-Protocol "tcp" `
-PublicPort 5022 `
-LocalPort 5022 |
New-AzureVM `
-ServiceName $serviceName `
-AffinityGroup $affinityGroupName `
-VNetName $virtualNetworkName
N.B. Dans l'exemple de création de base de données ci-dessus, on n'ajoute pas de disque de données pour simplifier l'explication, mais pour des questions de performances, ce serait mieux. On trouvera la façon de le faire dans ce billet par exemple :
On peut attendre de façon automatique la création de la VM, puis télécharger le fichier permettant de se connecter en RDP avec le code suivant :
$VMStatus = Get-AzureVM -ServiceName $serviceName -Name $sqlServerName
While ($VMStatus.InstanceStatus -ne "ReadyRole")
{
write-host "Waiting...Current Status = " $VMStatus.Status
Start-Sleep -Seconds 15
$VMStatus = Get-AzureVM -ServiceName $serviceName -Name $sqlServerName
}
Get-AzureRemoteDesktopFile `
-ServiceName $serviceName `
-Name $sqlServerName `
-LocalPath "$workingDir$sqlServerName.rdp"
Quand cela est fini, cela génère la VM suivante :
Se connecter à la machine virtuelle Windows Azure▲
On dispose aussi du fichier RDP :
Que l'on utilise tout de suite :
Les crédentités à utiliser sont dans les scripts plus haut. Il s'agit de :
$vmAdminUser = "AzureAdmin"
$vmAdminPassword = "BXkikovn14_____"
Exécuter une première fois PowerShell pour pouvoir ensuite lancer l'ISE :
Configuration sur SQLNUAGE▲
La configuration du pare-feu est similaire à ce qu'on avait fait sur la machine à demeure :
netsh advfirewall firewall add rule name='SQL Server (TCP-In)' program='C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Binn\sqlservr.exe' dir=in action=allow protocol=TCP
Établissement du database mirroring entre les deux instances SQL Server▲
Sur « dans-mes-murs », depuis SQL Server Management Studio.
N.B. Pour lancer SQL Server Management Studio, une possibilité est d'appuyer sur la touche Windows + S et de taper SQL Server Management Studio :
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'USclsmdlymlanokgxw96';
GO
CREATE CERTIFICATE SQLOnPrem_cert WITH SUBJECT = 'SQLOnPrem certificate';
GO
CREATE ENDPOINT Endpoint_Mirroring
STATE = STARTED
AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
FOR DATABASE_MIRRORING (AUTHENTICATION = CERTIFICATE SQLOnPrem_cert, ENCRYPTION = REQUIRED ALGORITHM AES, ROLE = ALL);
GO
BACKUP CERTIFICATE SQLOnPrem_cert TO FILE = 'SQLOnPrem_cert.cer';
GO
De même sur la machine SQLNUAGE :
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'RNaqkzndqdastyzial12';
GO
CREATE CERTIFICATE SQLInCloud_cert WITH SUBJECT = 'SQLInCloud certificate for database mirroring';
GO
CREATE ENDPOINT Endpoint_Mirroring
STATE = STARTED
AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
FOR DATABASE_MIRRORING (AUTHENTICATION = CERTIFICATE SQLInCloud_cert, ENCRYPTION = REQUIRED ALGORITHM AES, ROLE = ALL);
GO
BACKUP CERTIFICATE SQLInCloud_cert TO FILE = 'SQLInCloud_cert.cer';
GO
Cela a généré un certificat de chaque côté qu'on va copier sur l'autre machine de façon à ce que les deux instances SQL Server se connaissent.
Les certificats sont, sur chacune des machines à :
C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA
Pour copier les fichiers, on utilise le copier/coller de Remote Desktop :
Inversement, on copie SQLOnPrem_cert.cer vers SQLNUAGE :
Puis on utilise les certificats de l'autre machine sur chacun des serveurs
Sur « dans-mes-murs » :
CREATE LOGIN DBMirroringLogin WITH PASSWORD = 'SGyqzzsjrbvih83';
GO
CREATE USER DBMirroringLogin FOR LOGIN DBMirroringLogin;
GO
CREATE CERTIFICATE SQLInCloud_cert AUTHORIZATION DBMirroringLogin FROM FILE = 'SQLInCloud_cert.cer';
GO
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [DBMirroringLogin];
GO
Et sur SQLNUAGE :
CREATE LOGIN DBMirroringLogin WITH PASSWORD = 'QNcgppjwrziim85';
GO
CREATE USER DBMirroringLogin FOR LOGIN DBMirroringLogin;
GO
CREATE CERTIFICATE SQLOnPrem_cert AUTHORIZATION DBMirroringLogin FROM FILE = 'SQLOnPrem_cert.cer'
GO
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [DBMirroringLogin];
GO
Ensuite, il faut sur la machine « dans-mes-murs » effectuer un backup de la base que l'on va restaurer dans SQLNUAGE. Sur « dans-mes-murs » :
ALTER DATABASE AdventureWorksLT set recovery FULL
GO
BACKUP DATABASE AdventureWorksLT TO DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\BACKUP\AdventureWorksLT.bak';
GO
BACKUP LOG AdventureWorksLT TO DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\BACKUP\AdventureWorksLT.log';
GO
Cela génère deux fichiers à :
C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Backup
Que l'on copie sur sqlnuage (copier /coller RDP, car ils sont petits ici, sinon, on peut passer par le blob storage par exemple) dans le même chemin :
C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Backup
Pour restaurer la base de données dans SQLNUAGE, et comme on n'a pas créé de disque F: alors que « dans-mes-murs » a ses données dans le disque F:, on utilise le script suivant :
RESTORE DATABASE AdventureWorksLT FROM DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\BACKUP\AdventureWorksLT.bak' WITH NORECOVERY
, MOVE 'AdventureWorksLT2008_Data' TO 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\AdventureWorksLT_Data.mdf'
, MOVE 'AdventureWorksLT2008_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\AdventureWorksLT_Log.ldf'
GO
RESTORE LOG AdventureWorksLT FROM DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\BACKUP\AdventureWorksLT.log' WITH NORECOVERY
, MOVE 'AdventureWorksLT2008_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\AdventureWorksLT_Log.ldf'
, MOVE 'AdventureWorksLT2008_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\AdventureWorksLT_Log.ldf'
GO
Puis on indique où se trouve sur Internet l'instance source pour le database mirroring. Dans mon cas, la machine « dans-mes-murs » est accessible à l'adresse dans-mes-murs.compiouting.fr :
ALTER DATABASE AdventureWorksLT SET PARTNER = 'TCP://dans-mes-murs.compiouting.fr:5022';
GO
On fait l'opération similaire sur la machine « dans-mes-murs » :
ALTER DATABASE AdventureWorksLT SET PARTNER = 'TCP://sqlnuage.cloudapp.net:5022';
GO
Test de la solution▲
On ne peut pas accéder directement à la base de données miroir :
En revanche, on peut en faire des snapshots et consulter ces données :
create database AdventureWorksLT_2 ON
(NAME = 'AdventureWorksLT2008_Data',
FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\AdventureWorksLT_Data_2.mdf'
)
as snapshot of AdventureWorksLT
GO
Modifions des données à demeure et regardons si les données sont disponibles dans le nuage. Tout d'abord, qu'avons-nous dans le snapshot de destination :
use AdventureWorksLT_2
go
select FirstName, LastName from SalesLT.Customer where CustomerID = 1
go
Sur la base à demeure, on modifie la donnée :
use AdventureWorksLT
go
select FirstName, LastName from SalesLT.Customer where CustomerID = 1
go
update SalesLT.Customer set LastName = 'Smith' where CustomerID = 1
go
select FirstName, LastName from SalesLT.Customer where CustomerID = 1
go
Puis on regarde côté SQLNUAGE, en recréant un snapshot :
use master
go
drop database AdventureWorksLT_2
GO
create database AdventureWorksLT_2 ON
(NAME = 'AdventureWorksLT2008_Data',
FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\AdventureWorksLT_Data_2.mdf'
)
as snapshot of AdventureWorksLT
GO
use AdventureWorksLT_2
go
select FirstName, LastName from SalesLT.Customer where CustomerID = 1
go
Crash test▲
On peut également tester ce que cela donne, quand la base de données principale n'est plus disponible :
Combien ça coûte ?▲
Avant de terminer cet article, voyons combien une telle solution peut coûter. La page de référence sur le sujet est http://www.windowsazure.com/pricing. On y trouve principalement deux types de ressources pour calculer le prix :
- une calculatrice ;
- des pages de référence qui expliquent dans le détail sous quelles conditions et à quels prix sont facturés les différents composants.
Dans notre cas, on utilise les ressources suivantes :
- Calcul : http://www.windowsazure.com/fr-fr/pricing/details/virtual-machines/
- Stockage : http://www.windowsazure.com/fr-fr/pricing/details/storage/
- Réseau : http://www.windowsazure.com/fr-fr/pricing/details/data-transfers/ et http://www.windowsazure.com/fr-fr/pricing/details/virtual-network/
- Assistance : http://www.windowsazure.com/fr-fr/support/plans/
Les machines virtuelles utilisent le stockage, puisque les disques virtuels sont stockés de façon durable dans le service de stockage de blobs. Le stockage est facturé en fonction des IO (transactions) et de la quantité de données stockées. Dans la pratique, les transactions mesurent surtout un « fair use » du compte de stockage. Le réseau mesure ce qui entre et sort du datacenter, ainsi que la location du réseau virtuel ; cependant, pour ce dernier point, seule la passerelle VPN qu'on n'utilise pas ici est payante. Pour le premier point, ce qui entre est gratuit, seules les données sortantes sont payantes. Dans un scénario comme celui envisagé où les données vont essentiellement vers Windows Azure, c'est plutôt intéressant ! Enfin, pour pouvoir soumettre un incident technique au-delà des forums, il faut souscrire une offre de support.
Si l'on prend pour exemple une base de destination SQL Server Entreprise dans le nuage de 100 Go sur un serveur de taille L (quatre CPU, 7 Go de RAM), qu'on fait sortir 10 Go de données par mois, et que l'on prend un support développeur, cela donne dans la calculatrice (http://www.windowsazure.com/fr-fr/pricing/calculator/?scenario=full) :
On a arrondi le stockage à 300 Go (127 Go de disque OS, 100 Go de données, logs…).
L'essentiel du coût vient de la location de la licence SQL Server. Celle-ci peut aussi venir de l'entreprise (licence au volume avec portabilité vers le cloud venant de la Software Assurance). En développement/test, également, les abonnés MSDN ne paient pas cette licence puisqu'elle fait déjà partie de leur abonnement.
Si l'on prend une machine virtuelle de type M (deux CPU, 3,5 Go de RAM) au lieu de L, que l'on prend du stockage redondé uniquement dans un datacenter, et qu'on considère que la licence est amenée par ailleurs, cela donne, toujours avec le support développeur :
Conclusion▲
Peut-être aviez-vous entendu parler de Cloud hybride sans voir ce que cela pouvait être dans la pratique ? Dans cet exemple, nous avons vu comment, pour une base de données à demeure, mettre en place une base de données miroir dans le nuage. Quelques scripts suffisent à mettre la solution en place.
Le Cloud hybride, ce n'est pas si compliqué !