Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Focus sur SQL Azure

5 Commentaires

Un petit focus sur SQL Azure du point de vue d’un administrateur. Pas mal de choses ont bougé depuis que j’ai enregistré cette vidéo et notamment des outils sophistiqués pour la mise en place de stratégies BC/DR (Business Continuity and Disaster Recovery) sont arrivés et d’autres sont encore en prévisualisation. Une autre différence significative est le modèle de facturation qui passe d’une facturation au stockage à une facturation à la performance attendue.

Le programme:

  • Architecture
  • Nouveau modèle de facturation, bounding box et DTU
  • Création d’une base
  • Géo restauration
  • Restauration d’un état
  • Géo-réplication
  • Géo-réplication active
  • Copier une base
  • Import/Export
  • Export automatique
  • Audit
  • Monitoring
  • Support PowerShell

Architecture

On a besoin de créer deux ressources:

  1. un serveur pour héberger la base
  2. la base SQL Azure dans ce serveur

L’architecture mis en place est la suivante (j’emprunte le schéma sur ce blog).

2015-05-12_09-23-22

Votre compte Microsoft Azure peut disposer de plusieurs abonnements. On peut rattacher un ou plusieurs serveurs SQL à chaque abonnement. Le serveur SQL n’est pas une VM au sens où vous ne pouvez pas y accéder en RDP par exemple. Le serveur est pour vous juste un point de terminaison qui fournit le protocole TDS.

Lorsque l’on créé un serveur SQL, Azure déploie également une base SQL Azure avec une base Master. Ce master est fournit gratuitement, on ne paye que pour les bases de données additionnelles et c’est d’ailleurs à ce moment là que l’on choisit le niveau de facturation. On ne doit pas chercher à mettre des données dans master qui n’est là que pour gérer les logins et les audits.

 

Plusieurs niveaux de facturation sont disponibles.

2015-05-11_23-30-22

Note: Les anciens niveaux Web et Business sont obsolètes, on verra pourquoi plus bas.

Selon le niveau choisit on dispose de 2 Go jusqu’à 500 Go pour s’épanouir. Notez que le service SQL Azure Federation est lui aussi déprécié. Ce n’est pas qu’il était très utilisé, mais c’était un moyen de faire de la partition horizontale et donc d’aller au delà de la limite. Je ne suis pas allé voir en détail, mais le service encore en preview Elastic Scale semble proposer un SDK facilitant la mise en place de partitionnement horizontal de la base de données.

Pourquoi ce redécoupage des niveaux de facturations?

Un des reproches qui pouvaient être fait à SQL Azure est le problème du voisin bruyant. Dans les modèles Web et Business les différentes bases se disputent les ressources d’un même serveur:

2015-05-16_18-14-42

Il suffit qu’une des charges augmentent subitement ses exigences pour que toutes les autres soient impactées. Afin de protéger le serveur d’une surcharge Azure est alors obligé de refuser des requêtes ce qui pour les applications clientes se traduit par une baisse imprévisible des performances.

Le nouveau modèle de facturation n’est plus basé sur le stockage utilisé, mais sur les performances consommées. Il s’appuie sur une autre organisation des ressources basées sur des boîtes frontières (bounding box) qui encadrent strictement les ressources allouées à une charge.

2015-05-16_18-24-11

Ainsi si une charge devient un peu plus bruyante, Azure se chargera de limiter sa consommation au niveau de facturation choisit ce qui résout le problème du voisin un peu tapageur et assure une meilleure prédictibilité des performances.

On mesure les performances avec un indicateur appelé DTU (Database Throughput Unit). Il s’agit d’un mélange de mesures de CPU, d’utilisation de la mémoire et de taux de lecture/écriture. Il correspond à une mesure de performances relatives. Je dis bien relatives, on ne peux donc pas le convertir facilement en IOPS par exemple. Pour fixer les idées, on peut voir la DTU comme l’équivalent de la taille d’un tuyau d’arrosage. Plus le diamètre est important, plus il sera facile et rapide d’arroser le jardin. Il ne s’agit pas de fermer des sessions ou refuser des requêtes comme dans l’ancien modèle, mais d’empiler les requêtes et les traiter au débit permit par la DTU offerte par le niveau de facturation choisit. On sait que l’on atteint son plafond de ressource en voyant les performances diminuer, c’est à dire que l’on devient son propre voisin bruyant!

 

Il y a des quotas d’utilisation dont on devra tenir compte:

  • Serveurs:
    6 par abonnement
  • base de données, par serveur
    1600 DTU
    150 bases

Le quota de DTU peut parfaitement être panaché entre niveau de facturation tant. Par exemple les situations suivantes sont licites:

2 P3 = 2*800 DTU = 1600 DTU

150 S0 = 150 * 10 = 1500 DTU

1P3, 14 S2, 10 S0 = 800 + 14*50 + 10*10 = 1600 DTU

 

Mais on ne peut pas faire:

160 S0 = 1600 DTU parce que l’on dépasse le quota de 150 bases par serveur

Pour conclure là-dessus, il devient essentiel dans ce modèle de monitorer la façon dont on exploite les ressources du serveur. La question sera abordée dans les chapitres suivants.

 

S’il n’est pas aisé de parler de performances absolues, j’ai tout de même trouvé des indices ici:

http://stackoverflow.com/questions/24915593/translate-sql-azure-dtu-to-iops

Mais également cette vidéo de Microsoft Virtual Academy  qui explique comment sont obtenus les benchmarks:

http://www.microsoftvirtualacademy.com/training-courses/azure-sql-database-for-business-critical-cloud-applications?m=11358

Et je ne résiste pas au plaisir de commenter un des résultats présenté:

2015-05-17_13-21-32Le benchmark est un panel de 9 types de transactions effectuées sur la base. On commence par se fixer une contrainte (dernière colonne).

Plus on monte en gamme dans l’offre, plus celle-ci est sévère et donc plus les performances sont stables. Par exemple pour P3, la cible est que 95% des transactions répondent dans la seconde.

On fait tourner le bench en augmentant le taux de transactions jusqu’à atteindre le seuil au-delà duquel la contrainte n’est plus atteinte. Pour P3 toujours, on mesure 735 transactions par secondes, soit plus de 2.6 millions de transactions sur 1 heure! Je ne suis pas trop expert dans ce domaine, mais cela me semble énorme.

Il y a 3 ans j’ai abandonné SQL Azure sur un projet pour des questions de performances, pas certain qu’on le ferai aujourd’hui.

 

Terminons sur ce petit tableau qui récapitule quelques informations importantes:

BASIC STANDARD PREMIUM
SLA 99.99% 99.99% 99.99%
Limite DB (Go) 2 250 500
Objectifs de performance Taux de transaction prédictible à l’heure Taux de transaction prédictible à la minute Taux de transaction prédictible à la seconde
Niveau Basic S0, S1, S2 P1, P2, P3
Facturation A l’heure A l’heure A l’heure
Restauration jusqu’à 7 jours 14 jours 35 jours
En cas de désastre Géo-Restauration Géo-Réplication standard Géo-réplication active

Création d’une base

Commençons depuis le portail. Comme toujours on clique sur NEW puis SQL DATABASE:

2015-05-11_23-24-30

On choisit le nom de la base amethystedata:

2015-05-11_23-28-18

On va laisser le niveau de facturation Standard qui nous permettra de mettre en place la géo-réplication tout à l’heure. Notez rapidement qu’à ce stade d’autres paramètres sont accessibles comme la collation.

 

On va sélectionner un serveur pour héberger notre base en cliquant sur SERVER:

2015-05-11_23-33-06

Il n’y en a pas, on va donc le créer en cliquant sur CREATE:

2015-05-11_23-34-59

Dans cet exemple le serveur sera localisé sur West Europe. Faire OK. On revient au menu principal. On va cliquer sur SELECT SOURCE pour modifier le choix par défaut afin de faire quelques tests plus tard:

2015-05-11_23-37-18

Il y a 3 options:

  1. Blank Data base
    Une base de données vide
  2. Sample
    Une base de données de démo, très pratique pour faire … des démos
  3. Backup
    Depuis le backup d’une base

 

On choisit SAMPLE, ce menu permet de sélectionner une version de ADVENTUREWORK la base que l’on ne présente plus:

2015-05-11_23-39-41

Dernière étape, on clique sur CREATE et on laisse Azure créer sa base. Si tout se passe bien la page d’accueil du portail doit ressembler à ceci:

2015-05-11_23-46-42

 

Vous mourrez d’impatience de vous connecter à cette base, surtout qu’elle est déjà pré remplie. Où est la chaîne de connexion? Cliquez sur la tuile:

2015-05-11_23-49-08

Le lien encadré permet de récupérer la chaîne de connexion. Si on tente de se connecter avec Management Studio une surprise vous attend:

2015-05-11_23-51-41

Il y a une formalité, l’accès externe d’un serveur SQL Azure n’est pas protégé par un point de terminaison, mais par une règle dans le pare feu que l’on doit créer.

Allons dans le menu SQL Server et sélectionnons notre serveur:

2015-05-11_23-54-18

Cliquer sur FIREWALL:

2015-05-11_23-56-41

On a juste à créer une règle portant sur son IP publique et cette fois:

2015-05-11_23-58-19

Tout va bien.

Continuité d’activité

La continuité d’activité est la capacité que l’on a à poursuivre le travail en cas de sinistre. Azure propose plusieurs mécanismes pour vous y aider.

Tout d’abord, chaque base de données est répliquée sur 2 ou 3 serveurs physiques différents pour assurer de la haute disponibilité en cas de défaillance matérielle sur un serveur ou une baie. Si le serveur qui héberge la base primaire a un problème, celui-ci est immédiatement détecté par Azure. Le processus est alors de sélectionner une base secondaire, la transformer en base primaire, dérouter le trafic et recréer un nouveau réplica secondaire. L’opération prend moins de 30 secondes.

Ce n’est pas tout, d’autres mécanismes moins locaux peuvent également être activés selon le niveau de facturation. Quatre options s’offrent alors à nous:

  1. Restauration dans le temps (point-in-time restore)
  2. Géo restauration (Geo-restore)
  3. Géo-réplication standard (standard geo-replication)
  4. Géo-réplication active (active geo-replication)

 

Avant d’aller plus dans les détails, examinez cette synthèse:

BASIC STANDARD PREMIUM
Restauration dans le temps N’importe quel point de restauration dans les 7 jours N’importe quel point de restauration dans les 14 jours N’importe quel point de restauration dans les 35 jours
Géo restauration RTO < 24 heures
RPO < 24 heures
RTO < 24 heures
RPO < 24 heures
RTO < 24 heures
RPO < 24 heures
géo-réplication standard Non disponible RTO < 2 heures
RPO < 30 min
RTO < 2 heures
RPO < 30 min
géo-réplication active Non disponible Non disponible RPO < 1 heure
RPO < 5 min
  • RTO (Recovery Time Objective) est l’objectif de délai de récupération, c’est à dire le temps d’arrêt minimal avant que l’application redevienne fonctionnelle
  • RPO (Recovery Point Objective) est l’objectif de point de récupération, c’est à dire la quantité maximale des dernières modifications de données que l’application pourrait perdre avant de redevenir fonctionnelle

La restauration dans le temps est une option simple puisqu’elle est automatiquement fournie par chaque niveau. Son usage est de VOUS permettre de restaurer une base dans un état antérieur au cas où vous avez fait une fausse manipulation par exemple. Trois types de sauvegarde sont réalisés:

  1. Une sauvegarde complète chaque semaine
  2. Une sauvegarde différentielle chaque jour
  3. sauvegarde des logs de transaction toutes les 5 minutes

En cas de restauration Azure retrouve la base complète la plus récente, applique la sauvegarde différentielle quotidienne puis les transactions jusqu’à la date de restauration demandée qui peut être précise à la milliseconde.

La durée de sauvegarde des points de restauration varie de 7 à 35 jours selon le niveau de facturation. On peut également restaurer une base de données effacée, mais dans ce cas seule la dernière version est disponible.
Notez que si on supprime non pas une base, mais le serveur, alors c’est tout l’historique qui est perdu. On ne peut pas restaurer un serveur.
Un dernier point à noter est que les points de restauration sont géo-répliqués dans différentes zones.

 

La géo restauration permet de récupérer la sauvegarde la plus récente d’une base de données. Elle est automatiquement disponible pour tous les niveaux.

Son fonctionnement est similaire à la restauration dans le temps et utilise d’ailleurs la même infrastructure. On retrouve donc les même caractéristiques techniques développées au paragraphe précédent.

La principale différence est que l’on peut recréer la base sur n’importe quel serveur et dans n’importe quelle région. On trouvera des informations plus détaillées ici:

http://azure.microsoft.com/blog/2014/09/13/azure-sql-database-geo-restore/

 

La géo-réplication standard est un moyen de se protéger d’un data center défaillant. Il s’agit de créer un réplica (appelé base de données secondaire) de la base de données dans un data center situé dans une autre région.

La base de données secondaire est mise à jour à chaque transaction de la base de données primaire. Cette mise à jour est effectuée en asynchrone. Cela signifie qu’il y a un risque de perte de données.

La géo-réplication n’est disponible qu’à partir des niveaux de facturation STANDARD. Normalement si le centre primaire est déclaré perdu par Microsoft, le trafic est redirigé vers la base secondaire. En fait c’est plus compliqué. Le comportement par défaut est de VOUS laisser le choix entre attendre que Microsoft répare le problème et faire vous-même une bascule sur la base secondaire. Ce choix ne peut être fait automatiquement car vous seul en connaissez l’impact et pouvez évaluer quel est le meilleur équilibre entre perte de données et disponibilité. Toutefois si au bout de 24 heures Microsoft décide qu’il est définitivement impossible de récupérer les données (trop coûteux, trop long…) il déclenchera une bascule forcée sur le serveur secondaire.

Une différence importante avec la géo-restauration et que cette fois la base de secours est déjà créée et prête à l’emploi. En cas de défaillance d’un data center, vous n’aurez donc pas besoin de restaurer une sauvegarde en situation de compétition avec des milliers d’autres clients, la base est prête, les ressources sont déjà allouées.
L’autre atout est que les données sont mise à jour en continue et seront donc beaucoup plus fraiches que dans le cas de la géo-restauration.

 

La géo-réplication active est très similaire à la géo-réplication, mais on va cette fois créer jusqu’à 4 bases secondaires dans plusieurs régions y compris celle de la base primaire. Cette fois ces bases seront accessibles, mais en lecture seule.
Contrairement à la géo-réplication les bases restent donc accessibles. On peut donc les utiliser également pour des tâches annexes comme réduire la latence pour des clients internationaux ou bien effectuer des opérations de reporting sans charger la base principale.

On peut parfaitement combiner géo-réplication et géo-réplication active, ce qui compte est que l’on a pas plus de 4 copies au total.

Cette option n’est disponible qu’à partir du niveau PREMIUM.

Restauration dans le temps

On sélectionne dans le portail la base que l’on souhaite restaurer. On clique sur RESTORE.

2015-05-15_22-57-08

On sélectionne un point de restauration de deux manières:

  • en faisant glisser le slider
  • en cliquant sur la date pour ouvrir un calendrier

Cette fois aussi on constate qu’une nouvelle base est créée dans le serveur en cours et donnant lieu bien entendu à une facturation de la part de Microsoft.

Geo-restauration

On sélectionne le serveur concerné et on va dans l’onglet BACKUP. Le résultat affiché dépend bien sûr de votre situation, mais il ressemblera à celui-ci:

2015-05-15_22-47-43

On sélectionne la base qui nous intéresse et on clique sur le menu RESTORE:

2015-05-15_22-49-41

On sélectionne un serveur ou bien on en créée un nouveau, puis OK. L’opération peut être relativement longue, mais au final:

2015-05-15_22-54-22

On constate que la base active n’est pas écrasée, une nouvelle base est créée.

 

On peut aussi récupérer une base effacée:

2015-05-17_16-05-48

On clique sur RESTORE:

2015-05-17_16-08-37

Nous n’avons pas le choix du serveur cette fois et seule la dernière version est disponible.

 

Géo-réplication

On pourrait le faire depuis le portail traditionnel, mais je trouve le nouveau portail plus esthétique avec sa carte!

Sélectionnons notre base de données, si on fait défiler le panneau on devrait rencontrer ceci:

2015-05-12_00-06-20

On clique sur la carte pour configurer la géo réplication:

2015-05-12_00-07-44

En bleu le centre où se trouve notre base de données, en violet le centre conseillé, mais on peut sélectionner n’importe lequel. prenons le centre conseillé:

2015-05-12_00-09-35

On laisse SECONDARY TYPE à NON-READABLE, on sélectionne un serveur qui devra être situé dans le data center sélectionné. Le panneau et la procédure est la même que tout à l’heure:

2015-05-12_00-12-09

On clique sur OK puis CREATE. Une petite animation apparaît sur la carte:

2015-05-12_00-13-18

L’hexagone rayé vert/blanc indique que le réplica est en cours de création. Une fois terminé:

2015-05-12_00-15-16

Le trait plein indique que la réplication est active.

Je lance ensuite la procédure SQL suivante pour créer une transaction:

update [SalesLT].[Product]
set name = ‘Sport-100 Helmet, COLOR: Red’
where [ProductID] = 707

On déclare ensuite une entrée dans le pare feu du nouveau serveur (comme tout à l’heure) et on ouvre la base de données secondaire:

2015-05-12_00-22-22

On constate que cette base n’est pas disponible, le compte dont on dispose n’a pas accès aux tables de la base de données lorsque la réplication est en cours.

Note: c’est un point très important à avoir en tête. La base de données secondaire ne peut pas servir par exemple à faire du reporting.

 

Il est tout de même possible de valider que cela fonctionne afin de mettre au oint votre plan de restauration en cas de défaillance sur Azure. Depuis le portail on lance la commande STOP NOW du menu GEO REPLICATION:

2015-05-12_00-25-08

On sélectionne la base de données secondaire puis on clique sur STOP. La commande n’attend pas que les transactions en cours se terminent, elle arrête la réplication.

2015-05-12_00-07-44

Si on revient à Management Studio:

2015-05-12_00-27-53

Et on constate que la transaction réalisée a été répliquée correctement:

2015-05-12_00-29-05

Il faut surtout avoir en tête que cette réplication ne garantit pas l’intégrité des données. Elle est asynchrone et son arrêt ne tient pas compte des transactions en cours. Les tests que j’ai pu réaliser montrent toutefois qu’elle se fait dans la seconde (mesure faite à vue d’œil) en pratique, pas dans la minute. Je ne sais pas si Microsoft fournit des SLA.

Une fois le service arrêté il faudra bien entendu que vos applications clientes utilisent la chaîne de connexion de la base de données secondaire pour s’y connecter, ce n’est pas automatique. Le service de géo-réplication n’est pas un service de haute dispo ou plutôt de la haute dispo du pauvre.

Géo-réplication active

Je suis un très chaud partisan de systématiquement tester tout ce qu’on lit dans les blogs, mais j’attire votre attention sur ceci:

2015-05-12_14-30-37

C’est le moins cher et on le multiplie par le nombre de base!
Donc ne vous endormez pas sur vos tests et n’oubliez pas de tout supprimer une fois que vous avez effectivement constaté que ça marche et fait deux/trois expériences…

 

On se rend dans le menu GEO REPLICATION:

2015-05-12_14-48-22

Sélectionnons deux emplacements:

2015-05-12_14-54-17

Active géo-réplication est l’option par défaut, mais on peut faire une autre sélection ici:

2015-05-12_14-50-28

Et au final:

2015-05-12_14-57-46

Faisons quelques expériences après avoir paramétré les pare-feu de nos serveurs.

Si on se connecte via Management Studio sur une base secondaire:

2015-05-12_15-03-45

Les tables sont bien accessibles et disponibles, mais en lecture seule.

2015-05-12_15-05-34

 

Regardons les options d’arrêt. On se rend dans le menu GEO REPLICATION, on sélectionne le centre concerné dans la liste et un panneau s’ouvre:

2015-05-12_19-51-37

On reconnaît STOP NOW qui a été vu tout à l’heure, mais une option STOP AFTER SYNC est maintenant active.

Cette option correspond au cas d’un arrêt programmé. Dans ce cas toutes l’arrêt se produira lorsque les transactions en cours sur la base primaire auront commitées sur notre base secondaire. La copie continue est arrêtée et la base devient accessible en stand alone.

Archiver

Nous avons la possibilité d’importer/exporter une base de données au format BACPAC. Il s’agit d’un fichier qui encapsule tous les objets nécessaires à reconstruire la base de données (tables, vues, procédures stockées…). L’export fonctionne entre un storage et une base de données.

 

Le menu d’export est le suivant:

2015-05-13_22-47-15

Je ne suis pas parvenu à faire l’export depuis le nouveau portail, mais ça marche parfaitement sur l’ancien:

2015-05-13_23-07-25

  1. En 1 le nom du fichier BACPAC
  2. En 2 on sélectionne un storage ou bien on en créée un autre
  3. En 3 on saisit le mot de passe administratif

Disons que l’on choisit l’option NEW STORAGE. Un deuxième formulaire apparaît:

2015-05-13_23-10-18

Il ne reste plus qu’à faire OK. L’opération peut être assez longue.

On peut importer un BACPAC:

2015-05-13_23-40-05

Le formulaire d’import est celui-ci:

2015-05-13_23-42-06

On peut cliquer sur l’icône pour naviguer dans le storage afin de récupérer facilement l’url d’un BACPAC dans les storages.

On notera un point intéressant: il est possible de sélectionner un abonnement. Les menus Export/Import sont un moyen simple de déplacer une base de données d’un abonnement vers un autre.

 

Le formulaire suivant dépend du choix fait avec SERVER. Une fois terminé la nouvelle base doit apparaître parmi les bases de données SQL Azure.

 

L’export effectue une copie des tables sans garantir l’intégrité transactionnelle. Une possibilité est de faire une copie de la base:

2015-05-13_23-29-46

Un clic ouvre le formulaire:

2015-05-13_23-32-11

On donne un nom à la copie, on sélectionne le serveur cible où créer la copie. Au bout d’un moment:

2015-05-13_23-33-37

On effectue ensuite un export de la base ainsi copiée comme précédemment.

Export automatique

Il s’agit d’une fonctionnalité encore en preview:

2015-05-13_23-13-51

Cliquons sur AUTOMATIC:

2015-05-13_23-54-31

On peut effectuer des copies planifiées de la base et définir une période de rétention. La copie à lieu dans un storage.

Audit

L’audit effectue un relevé des événements de base de données dans un journal situé sur un storage Azure. Nous pouvons suivre:

  • les accès aux données
  • les modifications de schéma
  • les modifications de données
  • les comptes, rôles et autorisations
  • exceptions de sécurité

La fonction d’audit est accessible depuis tout niveau de facturation.

Dans le nouveau portail on sélectionne la base que l’on souhaite auditer:

2015-05-17_11-06-59

On clique sur la tuile d’audit:

2015-05-17_11-09-32

Commençons par STORAGE DETAILS:

2015-05-17_11-12-42

On sélectionne une durée de rétention puis on configure son compte de stockage, on termine avec OK.

On laisse coché tous les événements à journaliser.

On peut aussi décider que ces paramètres seront les valeurs par défaut pour toutes les bases situées sur ce serveur, nous allons le faire.

Cliquez ensuite ici:

2015-05-17_11-17-29

Il s’ouvre:

2015-05-17_11-18-48

Récupérez sur ce formulaire la chaîne de connexion sécurisée adaptée à votre application. Seules les applications clients utilisant la chaîne sécurisée verront leur activité journalisée. La syntaxe est la suivante:

Chaîne classique:

<nom du serveur>.database.windows.net

Chaîne sécurisée:

<nom du serveur>.database.secure.windows.net

Dans un environnement de production il est judicieux de basculer à REQUIRED l’option de sécurité:

2015-05-17_11-24-41

Il ne sera alors plus possible d’accéder à la base sans utiliser la chaîne sécurisée.

 

Enregistrez la configuration de l’audit. Vous devriez voir apparaître dans le stockage une TABLE appelée:

SQLDBAuditLogsAmethysteserverAmethysteData<DATE CREATION>

Est-ce que ça fonctionne?

 

Effectuez quelques opérations, vous devriez y voir apparaître des événements:

2015-05-17_11-36-27

Tandis que le nouveau portail affiche une synthèse:

2015-05-17_11-56-19

Microsoft fournit des modèles de feuilles Excel plus adaptées que le log brut pour analyser ces journaux:

http://go.microsoft.com/fwlink/?linkid=403540&clcid=0x40c

Il faudra ensuite installer PowerQuery pour requêter depuis Excel la TABLE. J’ai déjà rédigé un tutoriel:

https://amethyste16.wordpress.com/2014/10/21/importez-vos-fichiers-blob-ou-table-depuis-azure-vers-excel-avec-powerquery/

Un rapport d’audit peut ressembler à ceci:

2015-05-17_11-42-16

La documentation de ce rapport se trouve ici:

http://go.microsoft.com/fwlink/?linkid=506731&clcid=0x40c

 

Le nouveau portail nous facilite toutefois la vie:

2015-05-17_11-57-22

Qui ouvre le modèle de document Excel précédemment téléchargé. Il faudra l’alimenter avec PowerShell, peut être qu’une future version le fera pour nous…

 

A titre de dernière expérience, créez une deuxième base dans le même serveur:

Une fois terminé on constate ceci:

2015-05-17_11-53-11

Un audit est déjà configuré. C’est parce que nous avons coché ceci tout à l’heure:

2015-05-17_11-54-53

 

Pour en savoir plus et notamment la configuration depuis le portail classique:

http://azure.microsoft.com/fr-fr/documentation/articles/sql-database-auditing-get-started/

Surveillance

De nouvelles DMV spécifiques à Azure SQL Database sont proposées pour surveiller l’utilisation des ressources.

Dans la base Master:

select * from master.sys.resource_stats

Affiche des statistiques basées sur les 5 dernières minutes:

2015-05-16_19-29-12

On peut avoir une granularité sur 15 secondes, mais au niveau de UserDB cette fois en consultant la vue sys.dm_db_resource_stats.

2015-05-16_19-43-20

Bien entendu les DMV disponibles pour les bases on premises restent disponibles.

La principale action que l’on peut faire pour ajuster les métriques à sa situation est de modifier le niveau de facturation. On peut le faire depuis le portail, PowerShell ou bien T-SQL. Par exemple ma base qui est actuellement en STANDARD pourrait passer en PREMIUM ainsi:

ALTER DATABASE amethystedata MODIFY (EDITION = ‘Premium’)

 

Le temps pris est assez variable. Si on descend de niveau c’est assez rapide, autrement pour peu que les ressources natives du serveur ne suffisent pas il faudra déplacer la base (ou peut être une autre) ce qui prend un peu de temps.

 

Côté portail on peut surveiller et placer des alertes.

2015-05-16_20-24-15

Le panneau de surveillance est placé dans l’onglet MONITORING. Plusieurs indicateurs sont activés par défaut, mais on peut en sélectionner d’autres en cliquant sur ADD METRICS:

2015-05-16_20-25-59

Qui ouvre:

2015-05-16_20-27-31

Une fois que l’affichage est rafraîchit les nouveaux indicateurs sont affichés:

2015-05-16_20-28-54

Pour les activer et générer un affichage on doit cliquer sur le petit bouton gris à la gauche de chaque indicateur. Les valeurs sont générées avec une granularité de 5 minutes.

On peut fixer une alerte en cas de dépassement d’une métrique. Pour cela on sélectionne un indicateur, le menu se transforme:

2015-05-16_20-31-52

Si on clique sur ADD RULE:

2015-05-16_20-33-06

On fournit au moins le nom, puis OK:

2015-05-16_20-34-31

On définit les conditions de déclenchement de la règle (CPU > 80%) et l’action en cas de déplacement (émission d’un courriel).

Support PowerShell

Création d’une base

Voici un script complet qui créée une base SQL Azure, active les pare-feu et installe la géo réplication standard. Je le commente ensuite.

$sqldb= »amethystedata »
$user= »admin12345″
$pwd= »admin@55″
$location1 = « West Europe »
$location2 = « North Europe »
$ip = « VOTRE IP »

# création du serveur primaire
# —————————–

# création du serveur SQL Server version 12.0
$primaryServer = New-AzureSqlDatabaseServer -AdministratorLogin $user -AdministratorLoginPassword $pwd -Location $location1 –Version « 12.0 » -Force
# active le pare feu pour le serveur
New-AzureSqlDatabaseServerFirewallRule -RuleName « amethyste » -ServerName $primaryServer.ServerName -StartIpAddress $ip -EndIpAddress $ip
#attache une base à notre serveur avec les paramètres par défaut (par défaut Edition Standard)
New-AzureSqlDatabase -ServerName $primaryServer.ServerName -DatabaseName $sqldb

Start-Sleep -s 180

# mise en place de la géo réplication
# —————————————-

# création du serveur secondaire, dans une autre région
$secondaryServer = New-AzureSqlDatabaseServer -AdministratorLogin $user -AdministratorLoginPassword $pwd -Location $location2 –Version « 12.0 » -Force
# active le pare feu pour le serveur
New-AzureSqlDatabaseServerFirewallRule -RuleName « amethyste » -ServerName $secondaryServer.ServerName -StartIpAddress $ip -EndIpAddress $ip

# copie de la base sur le serveur secondaire et activation de la géo-réplication
Start-AzureSqlDatabaseCopy -ServerName $primaryServer.ServerName -DatabaseName $sqldb -PartnerServer $secondaryserver.ServerName -ContinuousCopy -OfflineSecondary

 

Le script est composé de deux parties. La première créé le serveur et la base primaire ainsi que les règles de pare-feu. La deuxième construit le serveur, la base secondaire et active la géo réplication.

New-AzureSqlDatabaseServer est au cœur des opérations. Cette cmdlet construit un serveur SQL Azure et lui affecte automatiquement un nom. D’autres paramètres existent, mais nous garderons les valeurs par défaut qui correspondent à un abonnement Standard qui nous convient. Nous verrons au chapitre suivant comment sélectionner un abonnement Premium.

On pourrait vouloir choisir son propre nom comme dans le portail bien entendu. On dispose pour cela d’une autre cmdlet: New-AzureSqlServer.

 

La commande New-AzureSqlDatabaseServerFirewallRule construit une règle dans le pare-feu, elle ne présente aucune difficulté.

La deuxième partie commence comme la première, ce sont les valeurs des paramètres qui diffèrent et en particulier Location. La partie intéressante est Start-AzureSqlDatabaseCopy.

Cette cmdlet effectue une copie de la base de données définie par ServerName et DataBaseName vers le serveur PartnerServer. On ne peut pas changer d’abonnement. La façon dont s’effectue la copie dépend de la combinaisons ContinuousCopy et OfflineSecondary.

La présence de ContinuousCopy indique qu’un lien de mise à jour sera maintenu avec la base de données primaire. En son absence on effectue une copie one time.

Les combinaisons possibles prise en charge sont les suivantes:

  • ContinuousCopy NON spécifié, OfflineSecondary NON spécifié

Copie one time de la base de donnée. On doit ajouter PartnerDatabase pour préciser le nom de la base cible.

Start-AzureSqlDatabaseCopy -ServerName $serverNameSource -DatabaseName $dbSource-PartnerServer $serverNameCible -ParnerDatabase $dbCible

  • ContinuousCopy spécifié, OfflineSecondary spécifié

C’est le cas vu dans le script. La géo-réplication est activée sur la base secondaire dont le nom doit être identique à la base primaire.

  • ContinuousCopy spécifié, OfflineSecondary NON spécifié

Similaire au cas précédent, mais on active la géo-réplication active cette fois.

Toutes autres combinaisons renvoient un message d’erreur.

Vous avez peut-être remarqué le Start-Sleep dans le script. Vous en aurez ou non besoin, la valeur devra peut-être être augmentée. C’est un des problèmes que je rencontre avec Azure SQL: la fabrique Azure pose des verrous sur certaines ressources en attendant de les supprimer ou bien de les activer, mais ne donne aucun moyen de le signaler à un script. Start-Sleep est là pour attendre que la base primaire soit prête. Pendant ce temps on récupère une exception:

New-AzureSqlDatabaseServer : InternalError: The server encountered an internal error. Please retry the request.

 

On a terminé, on peut ensuite obtenir la liste des serveurs SQL:

Get-AzureSqlDatabaseServer

2015-05-12_14-10-44

Ou bien des bases sur un serveur donné:

Get-AzureSqlDatabase -ServerName $primaryServer.ServerName

2015-05-12_14-12-12

On voit apparaître deux bases. La base Master et la base amethystedata.

 

Le workflow n’est toutefois pas complet. Vous avez perdu dans l’affaire une base secondaire qu’il faut donc recréer dans une autre région que celle qui est perdue.

Géo-réplication active

On vient de voir comment activer la géo-réplication standard. Examinons le cas de la géo-réplication active.

Le script est assez peu différent de celui vu précédemment.

$sqldb= »amethystedata »
$user= »admin12345″
$pwd= »admin@55″
$location1 = « West Europe »
$location2 = « North Europe »
$location3 = « East US 2 »
$ip = « MON IP »

# création du serveur primaire
# —————————–
$primaryServer = New-AzureSqlDatabaseServer -AdministratorLogin $user -AdministratorLoginPassword $pwd -Location $location1 –Version « 12.0 » -Force
# active le pare feu pour le serveur
New-AzureSqlDatabaseServerFirewallRule -RuleName « amethyste » -ServerName $primaryServer.ServerName -StartIpAddress $ip -EndIpAddress $ip

#attache une base primaire à notre serveur
# —————————————-
$ServerCredential = Get-Credential -UserName $user -Message « Votre mot de passe »
$primaryServerName = $primaryServer.ServerName
$ctx = New-AzureSqlDatabaseServerContext -ManageUrl “https://$primaryServerName.database.windows.net” -Credential $ServerCredential
$PerformanceLevel = Get-AzureSqlDatabaseServiceObjective -Context $ctx -ServiceObjectiveName « P1 »

New-AzureSqlDatabase -ServerName $primaryServer.ServerName -DatabaseName $sqldb –Edition Premium -ServiceObjective $PerformanceLevel

Start-Sleep -s 180
# création de deux serveurs secondaires + règle pare-feu
# ——————————————————
$secondaryServer1 = New-AzureSqlDatabaseServer -AdministratorLogin $user -AdministratorLoginPassword $pwd -Location $location2 –Version « 12.0 » -Force
New-AzureSqlDatabaseServerFirewallRule -RuleName « amethyste » -ServerName $secondaryServer1.ServerName -StartIpAddress $ip -EndIpAddress $ip

Start-Sleep -s 180

$secondaryServer2 = New-AzureSqlDatabaseServer -AdministratorLogin $user -AdministratorLoginPassword $pwd -Location $location3 –Version « 12.0 » -Force
New-AzureSqlDatabaseServerFirewallRule -RuleName « amethyste » -ServerName $secondaryServer2.ServerName -StartIpAddress $ip -EndIpAddress $ip

# mise en place de la géo réplication active
# ——————————————
Start-AzureSqlDatabaseCopy -ServerName $primaryServer.ServerName -DatabaseName $sqldb -PartnerServer $secondaryserver1.ServerName -ContinuousCopy
Start-AzureSqlDatabaseCopy -ServerName $primaryServer.ServerName -DatabaseName $sqldb -PartnerServer $secondaryServer2.ServerName -ContinuousCopy

On remarque la méthode (un peu compliquée) pour sélectionner le niveau de facturation Premium P1. Le reste est conforme aux commentaires du chapitre qui précède.

Autres restaurations

On peut obtenir la date de la dernière version récupérable des bases de données dans un serveur:

Get-AzureSqlRecoverableDatabase -ServerName « amethysteserver »

Qui chez moi a affiché:

2015-05-17_15-57-55

Une fois identifié les bases récupérables, on peut lancer l’opération avec une des deux cmdlets:

  1. Start-AzureSqlDatabaseRecovery
    Ne restaure que la dernière version d’une base effacée
  2. Start-AzureSqlDatabaseRestore
    Restaure une base effacée ou bien une effectue une restauration dans le temps

Voyons voir.

$sqlserver= »amethysteserver »
$sqldbSource = »amethystedata »
$sqldbSource = »$sqldbSource-restore »
$recoverypoint = »2015-05-13 20:50″
$op = Start-AzureSqlDatabaseRestore -SourceServerName $sqlserver -SourceDatabaseName $sqldb -TargetDatabaseName $sqldbSource

Le script restaure un point à une date donnée. Si on est dans un script on peut vouloir monitorer l’opération:

$context = New-AzureSqlDatabaseServerContext -ServerName $sqlserver -UseSubscription
Get-AzureSqlDatabaseOperation -ConnectionContext $context –OperationGuid $op.RequestID

 

2015-05-17_16-27-29

 

 

Publicités

5 réflexions sur “Focus sur SQL Azure

  1. Super cet article très complet qui va sûrement nous servir.
    Mais j’ai une question, je n’arrive plus a faire des scripts du schéma et des données de la BD par Management Studio depuis le mois de Mai justement en date de nouvelle politique d’Azure.
    Y a t il une restriction de la part de Microsoft ?

    Merci beaucoup.

  2. Je n’ai rien entendu de tel
    Mais dites moi quel scripts vous essayez, je ferai un essai de mon côté pour voir

    • Bonjour,
      Par le biais de management studio 2014, j’ai la possibilité de télécharger le schéma de la BD ainsi que les données afin de faire soit une sauvegarde perso ou reprendre les données pour les remettre dans ma BD en local pour le développement.
      Pour cela on clique droit sur la BD et on fait « Générer un script …. », ensuite on défini les tables ou la BD complète à insérer dans le script en prenant bien soin de choisir « Schéma et Données » dans « Avancer » et valider.
      et au bout de quelques secondes il nous sort une erreur : « Obtention de la liste des objets impossible »
      Dans le script de l’erreur :
      Obtention de la liste des objets à partir de « martin3d_test ».
      Échec
      Microsoft.SqlServer.Management.SqlScriptPublish.SqlScriptPublishException: Une erreur s’est produite lors de la génération de scripts des objets. —> System.InvalidCastException: Le cast spécifié n’est pas valide.
      à Microsoft.SqlServer.Management.Smo.Table.Microsoft.SqlServer.Management.Smo.IPropertyDataDispatch.SetPropertyValue(Int32 index, Object value)
      à Microsoft.SqlServer.Management.Smo.PropertyDispatcher.SetValue(Int32 index, Object value)
      à Microsoft.SqlServer.Management.Smo.PropertyCollection.SetValue(Int32 index, Object value)
      à Microsoft.SqlServer.Management.Smo.SqlSmoObject.AddObjectPropsFromDataReader(IDataReader reader, Boolean skipIfDirty, Int32 startColIdx, Int32 endColIdx)
      à Microsoft.SqlServer.Management.Smo.SqlSmoObject.ImplInitialize(String[] fields, OrderBy[] orderby)
      à Microsoft.SqlServer.Management.Smo.SqlSmoObject.OnPropertyMissing(String propname, Boolean useDefaultValue)
      à Microsoft.SqlServer.Management.Smo.PropertyCollection.RetrieveProperty(Int32 index, Boolean useDefaultOnMissingValue)
      à Microsoft.SqlServer.Management.Smo.PropertyCollection.GetPropertyObject(Int32 index)
      à Microsoft.SqlServer.Management.Smo.SqlSmoObject.GetPropertyOptional(String propName)
      à Microsoft.SqlServer.Management.Smo.Column.EmbedDefaultConstraints()
      à Microsoft.SqlServer.Management.Smo.Column.GetPropagateInfo(PropagateAction action)
      à Microsoft.SqlServer.Management.Smo.SqlSmoObject.GetPropagateInfoForDiscovery(PropagateAction action)
      à Microsoft.SqlServer.Management.Smo.SmoDependencyDiscoverer.GetScriptableChildren(List`1 propInfoList, PropagateAction propagateAction)
      à Microsoft.SqlServer.Management.Smo.SmoDependencyDiscoverer.SfcChildrenDiscovery(HashSet`1 discoveredUrns)
      à Microsoft.SqlServer.Management.Smo.SmoDependencyDiscoverer.Discover(IEnumerable`1 urns)
      à Microsoft.SqlServer.Management.Smo.ScriptMaker.Discover(IEnumerable`1 urns)
      à Microsoft.SqlServer.Management.Smo.ScriptMaker.DiscoverOrderScript(IEnumerable`1 urns)
      à Microsoft.SqlServer.Management.Smo.ScriptMaker.ScriptWorker(List`1 urns, ISmoScriptWriter writer)
      à Microsoft.SqlServer.Management.Smo.ScriptMaker.Script(Urn[] urns, ISmoScriptWriter writer)
      à Microsoft.SqlServer.Management.SqlScriptPublish.SqlScriptGenerator.DoScript(ScriptOutputOptions outputOptions)
      — Fin de la trace de la pile d’exception interne —
      à Microsoft.SqlServer.Management.SqlScriptPublish.GeneratePublishPage.worker_DoWork(Object sender, DoWorkEventArgs e)
      à System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
      à System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

      Merci de votre réponse

  3. je viens de faire un essai et tout se passe bien. J’utilise par ailleurs SSDT de façon systématique sur tous mes projets et n’ai jamais rencontré de problème

    Est-ce que par hasard la base n’est pas une ancienne base on premises qui a été poussée dans SQL Azure. On pourrait penser qu’il y a quelque chose d’incompatible avec le schéma SQL Azure même si je ne vois pas comment la base a été créée initialement

    Ce que je vous suggère est d’essayer d’identifier la ressource SQL qui pose problème puis de poser la question sur StackOverflow. Peut être que quelqu’un aura rencontré le problème

    • Merci pour votre aide.

      Donc il doit y avoir un problème au niveau des données insérées dans la BD je pense.

      Je crois que ça va être long et fastidieux à trouver.

      à bientôt.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s