SQL Server 2014 : AlwaysOn, chiffrement TDE et chiffrement des sauvegardes

Mis en avant

SQL Server 2014 commence à pointer le bout de son nez avec la CTP2. Cette nouvelle version va apporter pas mal de nouveautés côté moteur notamment la plus attendue Hekaton mais d’autres seront également de la partie comme une amélioration continue de la haute disponibilité avec SQL Server AlwaysOn, la sécurité avec le chiffrement des sauvegardes ou encore la limitation des actions possibles pour un administrateur de bases de données, les index columstore index pouvant être mis à jour et bien d’autres. Dans ce billet j’ai choisi de parler de SQL Server AlwaysOn et du chiffrement des bases de données et des sauvegardes. Un premier billet sur la possibilité de chiffrer les sauvegardes avec SQL14 a déjà par Christophe Laporte. Je vous invite à le lire si vous voulez en savoir un peu plus sur cette fonctionnalité.

En testant SQL Server 2014, AlwaysOn et le chiffrement certaines questions me sont venus à l’esprit.  Ces questions sont les suivantes :

  • Est-ce qu’une table Hekaton (In memory) est chiffrée si la base de données qui l’héberge utilise TDE ?
  • Est-ce qu’il est possible d’implémenter TDE avec une base de données déjà membre d’un groupe de disponibilité ?
  • Quel avantage à avoir du chiffrement de sauvegardes de bases de données si celles-ci le sont déjà avec TDE ?

 

icon_arrow Est-ce qu’une table Hekaton (In memory) est chiffrée si la base de données qui l’héberge utilise TDE ?

Tout dépend ici de quoi l’on parle. Une table Hekaton réside en mémoire mais selon sa durabilité les données la concernant peuvent être stockées sur disque. TDE chiffre les données sur disque et pas en mémoire. Un processus de chiffrement et déchiffrement opère en temps réel sur les fichiers de données et journaux de transactions (cf la BOL) . Donc ici on peut se demander si le chiffrement s’effectue pour les tables Hekaton durables car celles-ci utilisent des fichiers de données et des fichiers delta afin de pouvoir remonter les données en cas de problème.

 

alwayson_tde_0

Activons maintenant TDE sur la base de données AdventureWorks2012.

alwayson_tde_01

… et là SQL Server nous donne rapidement la réponse attendue :

alwayson_tde_03

Les tables Hekaton durables en réalité reposent sur un stockage de type filestream. On peut le voir sur l’image ci-dessous :

alwayson_tde_04

Un coup d’œil sur la documentation en ligne de SQL Server à propos de TDE nous permet de confirmer que le chiffrement n’est pas valable pour ce type de conteneur. Cela est également confirmé par ce lien pour SQL14. –> TDE n’est donc pas supporté avec l’utilisation des tables Hekaton.

 

icon_arrow  Est-ce qu’il est possible d’implémenter TDE avec une base de données déjà membre d’un groupe de disponibilité ?

Nous avons implémenté une belle architecture AlwaysOn et une des bases de données d’un groupe de disponibilité requiert maintenant d’être chiffré pour des raisons de sécurité. Comment dois je procéder dans ce cas ? Est-ce qu’il suffit d’activer TDE sur la base de données située sur le réplica primaire ? Dois-je effectuer des manipulations sur les secondaires ? Dois-je repartir de zéro en supprimant cette base de données du groupe de disponibilité, chiffrer la base de données et refaire tout le processus d’ajout à un groupe de disponibilité (backup, restauration sur les secondaires et ajout au groupe de disponibilité) ?

Soyons un peu feignant et partons du principe que tout est à faire depuis le réplica primaire et que tout sera répliqué par la suite par AlwaysOn .. après tout ca sert à cela la réplication non ? :-) . Précédemment nous avons implémenté TDE sur la base de données AdventureWorks2012 qui faisait parti d’un groupe de disponibilité lst_adv. On pourrait conclure que tout est fini mais si l’on jette un rapide coup d’œil à l’état de synchronisation de notre groupe de disponibilité on s’aperçoit vite qu’un problème est survenu suite à la mise en place de TDE et que la base de données Adventureworks2012 est même dans un état suspect sur les serveurs secondaires sur SSMS.

alwayson_tde_1

 

Parfait … on active TDE et on se retrouve avec une base de données suspecte !! Bravo TDE !! :-) Ne paniquons pas et regardons un peu plus loin dans les logs d’erreurs SQL on peut voir ceci :

alwayson_tde_2

La cause du problème est la suivante : après avoir chiffré notre base de données sur le réplica primaire, les réplicas secondaires ne trouvent pas le certificat dont l’emprunte correspond à celle utilisé par le certificat créé initialement pour le chiffrement TDE. Dans ce cas la réplication du flux de données du réplica primaire vers réplicas secondaires est donc naturellement suspendue. Ce comportement est tout à fait normal puisque nous essayons de répliquer une base de données chiffrée vers une base de données qui ne peut pas être chiffrée. Ce fameux certificat est hébergé dans la base de données master et n’est pas répliqué automatiquement par AlwaysOn contrairement à la clé de chiffrement de bases de données située dans la base de données AdventureWorks2012. Il ne nous reste plus qu’à sauvegarder ce certificat, le restaurer sur les réplicas secondaires et relancer la réplication des données pour AdventureWorks2012 :

alwayson_tde_05

Après quelques secondes ou minutes (en fonction de la quantité de données à répliquer car l’état de synchronisation est suspendue) on peut voir sur le dashbord du groupe de disponibilité lst_adv que tout est rentré dans l’ordre :

alwayson_tde_3 

Pour résumé, il est possible d’implémenter TDE sur une topologie AlwaysOn existante à condition de bien penser à restaurer le certificat servant au chiffrement de la clé de chiffrement de la base de données pour TDE. Le mode feignant est donc à proscrire :-)

 

icon_arrow Quel avantage à avoir du chiffrement de sauvegardes de bases de données si celles-ci le sont déjà avec TDE ?

La documentation en ligne concernant TDE explique qu’une sauvegarde provenant d’une base chiffrée par TDE est également chiffrée par le même certificat de serveur. Quel intérêt à chiffrer de nouveau le média de backup par la nouvelle fonctionnalité de chiffrement proposée avec SQL Server 14 si celle-ci est déjà initialement chiffrée par TDE ? Je me suis posé la question en pensant qu’une fois qu’une base était chiffrée par TDE, le chiffrement des sauvegardes n’avaient aucun effet. Mais je me trompais bien sûr : le chiffrement des sauvegardes avec SQL14 agit indépendamment de TDE et chiffrera une seconde fois le média de sauvegarde. Cela nous permet d’ajouter une protection supplémentaire au média de sauvegarde à savoir que chaque chiffrement peut utiliser un algorithme différent. Voyons comment cela se passe.

On commence donc par créer un certificat dédié aux chiffrement des sauvegardes dans la base de données master :

image

On effectue une sauvegarde de notre base de données AdventureWorks2012 avec le nouveau mot clé ENCRYTION pour la commande BACKUP :

image

On a maintenant un média de sauvegarde doublement chiffré. Si maintenant on tente de lire le contenu de ce média depuis une nouvelle instance SQL on se retrouve avec le message d’erreur suivant :

alwayson_tde_6

La lecture de l’entête du média de sauvegarde est impossible si le serveur SQL ne possède pas un certain certificat avec l’emprunte décrite ci-dessus. Par déduction, on peut aussi affirmer que la restauration ne sera pas impossible pour le moment.

Restaurons le certificat utilisé pour le chiffrement des sauvegardes dans la base de données master de la nouvelle instance SQL et essayons à nouveau de lire le contenu du média de sauvegarde :

alwayson_tde_7

Cela ne fonctionne toujours pas … on peut remarquer que l’emprunte du certificat manquant est différent cette fois. Il correspond en réalité à celle du certificat créé initialement pour activer TDE sur AdventureWorks2012. Après avoir restauré ce certificat il est possible de lire le contenu du média de sauvegarde et donc de restaurer notre base de données :

alwayson_tde_4 

Pour un nouveau réplica AlwaysOn, il faudra donc bien penser à restaurer tous les certificats nécessaires à la restauration d’une base de données avant de la joindre au groupe de disponibilité concerné.

Bon chiffrement !!

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server FCI et AlwaysOn et configuration quorum … de Windows 2008 à Windows 2012 R2

Mis en avant

Après quelques missions d’architecture sur l’implémentation d’architectures AlwaysOn chez divers clients il est temps de faire un point sur les possibilités de configuration du quorum du cluster Windows. En effet, pour rappel SQL Server AlwaysOn ou SQL Server FCI  se basent tous les 2 sur une couche Windows Failover Cluster Service (WFCS). Par conséquent le bon fonctionnement des groupes de disponibilités AlwaysOn ou des instances en cluster SQL reposent en quelque sorte sur celui du cluster Windows. Lorsqu’on parle de cluster Windows on arrive très vite à parler de quorum. La notion même de quorum n’est d’ailleurs pas uniquement associée au cluster. On peut la retrouver également lorsqu’on parle d’architecture en miroir avec SQL Server en mode synchrone et basculement automatique. Le but de ce billet est simplement de parcourir un peu les différentes possibilités de configuration du quorum avec WFSC à partir de 2008 R2 et de faire un focus sur les dernières innovations proposées par Windows Server 2012 et Windows Server 2012 R2.

 

icon_arrow Windows Server 2008 R2

Au fur et à mesure des versions Microsoft a fait évoluer ses modèles de quorum dans un processus continue d’amélioration de disponibilité du cluster Windows dans des scénarios de plus en plus divers. Par exemple on est passé de 2 modèles de quorum avec Windows 2003 à 4  à partir de Windows 2008. Windows 2008 a plus tard introduit la notion de paramétrage des poids de vote (avec l’application du KB2494036) qui peut s’avérer très utile dans des scénarios de type  “géo-cluster”. Cependant si le paramétrage du poids de vote se révèle très utile dans certains cas il n’en reste pas moins que celui-ci reste statique. En fonction de la situation c’est à l’administrateur de cluster de changer la configuration des poids de vote afin de garantir le quorum lors de la défaillances de nœuds.

L’image suivante montre 3 scénarios pour une architecture cluster Windows et pourquoi la nature statique du paramétrage du poids de vote peut poser problème :

 

quorum_1

 

Dans cette architecture le nœud 4 est sur un site distant. Comme nous ne voulons pas que ce nœud influence le vote du quorum en cas de coupure réseau entre les 2 sites nous pouvons lui supprimer la possibilité de voter dans l’établissement du quorum.

Scénario 1 :

Dans ce scénario il nous reste donc 3  nœuds qui peuvent voter (node 1, node 2 et node 3). Dans ce cas nous avons la possibilité d’utiliser le modèle de quorum “nœuds majoritaire” parce que le nombre de nœuds est impair ici. Dans cette configuration nous pouvons perdre jusqu’à 2 nœuds : le nœud 4 qui n’influence pas le vote du quorum via notre configuration et un des nœuds restants. Dans le cas où le nœud 4 aurait un vote nous ne pourrions perdre qu’un seul nœud.

Scénario 2 :

Dans ce scénario nous perdons le nœud 2 suite à une défaillance matérielle. Dans ce cas le cluster reste en ligne puisqu’il faut au minimum 2 nœuds pour effectuer le quorum. Cependant la perte d’un autre nœud risque à ce moment de compromettre la disponibilité du cluster. Dans ce cas l’administrateur du cluster Windows a 2 plusieurs possibilités :

  • Changer le quorum en ajoutant un témoin pour augmenter le nombre de votes possibles afin d’avoir la majorité en cas de défaillance d’un nœud
  • changer le nombre de votes possible à 1 seul nœud et en cas de défaillance du nœud 1 le cluster resterait en ligne (Dans notre exemple le nœud 3 perd sa possibilité de voter lors du quorum).

Scénario 3 :

Le nœud 2 a été réparé et est à nouveau opérationnel. Il faut de nouveau changer la configuration de poids de vote des nœuds pour augmenter la disponibilité du cluster en cas défaillance. En effet le vote étant ciblé uniquement sur un seul nœud, il devient le SPOF de cette topologie haute disponibilité. L’administrateur du cluster doit à nouveau activer le vote pour les nœuds 2 et 3 afin de garder en ligne le cluster Windows.

Pour résumer, le but du jeu ici est de jouer avec le poids de votes des nœuds tout en gardant à l’esprit qu’il faut garder plus 50% des votes pour garder le quorum en ligne !!

 

icon_arrow Windows Server 2012

Windows Server 2012 a changé la donne et a introduit le concept de quorum dynamique. Cette nouvelle fonctionnalité est intéressante car elle permet au cluster de recalculer à la volée le nombre de votes nécessaires pour que le cluster reste au maximum disponible. Ainsi il est possible d’avoir un cluster en ligne avec moins de 50% des nœuds restants.  A noter qu’il est toujours possible d’exclure des nœuds dans le vote du quorum avec un recalcul automatique qui ne tiendra compte uniquement que des nœuds restants.

En reprenant les scénarios décrits précédemment :

Scénario 1 :

quorum_2

On peut voir qu’il existe une nouvelle propriété appelée DynamicWeight. Le nœud 4 ne dispose pas de poids de vote (NodeWeight = 0) et par conséquent celui-ci ne sera pas pris en compte dans le calcul dynamique du quorum (dynamicweight=0) contrairement aux autres nœuds (NodeWeight et Dynamicweight = 1).

Scénario 2 :

quorum_3

On voit ici que le nœud 2 a subit une défaillance (State = Down) et que le calcul dynamique du quorum a été effectué par le cluster Windows. Par conséquent seul le nœud 3 possède un poids de vote ce qui permettra de garder en ligne le cluster en cas de défaillance d’un autre nœud de la topologie (nœud 1 ou 3).

quorum_4

L’arrêt du nœud 3 a déclenché à nouveau le recalcul du quorum par le cluster Windows. Ce dernier a transféré le poids de vote au seul nœud restant en ligne (nœud 1).

quorum_5

Les nœuds 2 et 3 ont été remis en ligne et à nouveau le cluster Windows a recalculé le poids de vote des nœuds pour le quorum.

Même si cette fonctionnalité présente des avantages certains, elle n’est cependant pas parfaite. En effet pour que le quorum se recalcule correctement, il faut que la défaillance des nœuds soit séquentielle dans le temps et que le recalcul du quorum ait eu le temps de s’effectuer. De plus l’introduction d’une ressource témoin avec Windows Server 2012 reste inchangé par rapport à Windows Server 2008 R2 à savoir que le témoin possède un poids de vote statique dans tous les cas ce qui diminue paradoxalement la disponibilité du cluster dans certains cas. Modifions notre architecture en y ajoutant un nœud supplémentaire de la façon suivante :

 

quorum_6

L’ajout d’un nœud pose ici un problème quant à l’établissement du quorum en cas de défaillance d’un des nœuds autre que nœud 5. Celui-ci comme dans l’architecture précédente n’est pas pris en compte dans le vote du quorum, ce qui laisse un nombre pair de nœuds qui peuvent voter. Dans cette configuration et sans quorum dynamique la défaillance de 2 nœuds ferait tomber à coup sûr l’ensemble du cluster Windows. En d’autres termes, la défaillance d’un seul nœud est supportée dans cette configuration. L’ajout d’une ressource témoin permet de pallier ce problème en ajoutant un vote supplémentaire afin d’augmenter le nombre de nœuds qui peuvent être défaillants à 2. Cependant avec l’utilisation du quorum dynamique, le recalcul se fera en tenant compte uniquement les nœuds du cluster restants en ligne. Le nombre de vote final sera donc composé de celui des nœuds restants + celui de la ressource témoin. Que se passera-t-il au moment où il restera un seul nœud en ligne et si l’on perd notre ressource témoin ? Malheureusement le quorum ne pourra être établi car il faudrait avoir au minimum 2 votes.

 

quorum_7

 

Ci-dessous un extrait de ce que l’on peut retrouver dans les logs du cluster Windows dans le cas où l’on perd une ressource témoin et par la suite le dernier nœud permettant au cluster Windows de rester en ligne.

Ici la ressource témoin est un dossier partagé qui n’est plus accessible ([RES] File Share Witness … Failed to create / Failed to validate etc …). Cependant le cluster peut encore rester en ligne puisque 2 nœuds sont encore présents pour faire le quorum (2 votes sur 3).

quorum_10

Cependant si l’on perd le dernier nœud (ici SQL122) comme montré ci-dessous …

quorum_11

… le début des problèmes commence puisque le cluster, malgré l’utilisation du quorum dynamique, se base encore sur le vote de la ressource témoin comme montré ci-dessous (File Share Witness is quorum and we’re one off quorum …). En effet à ce moment il n’existe plus qu’un seul vote sur 3 pour réaliser le quorum ce qui n’est plus suffisant. Après quelques secondes le cluster Windows

quorum_8

quorum_9

 

icon_arrow Windows Server 2012 R2

C’est ici que Windows Server 2012 R2 va avoir toute son utilité avec l’utilisation du témoin dynamique. Cette fonctionnalité permet de pallier au problème que nous venons de voir précédemment. Le vote du témoin est maintenant lui aussi dynamique et le cluster Windows recalcule le nombre de votes en fonction de la situation en tenant compte de ce nouvel élément.

L’image suivante montre la même situation que précédemment avec une topologie SQL Server 2014 décrite-dessus avec 5 nœuds dont un qui n’aura pas de vote pendant l’établissement du quorum. Au final nous avons 4 nœuds avec un poids de vote à 1.

image

On a également une ressource témoin de type FileShareWitness mais avec une nouvelle propriété WitnessDynamicWeight reflétant le caractère dynamique de la ressource témoin.

quorum_13

quorum_14

Que se passe-t-il si l’on perd la ressource témoin ?

quorum_15

On peut voir que la répartition des votes octroyés aux nœuds du cluster a changé dynamiquement. Premièrement le système a supprimé le vote de la ressource témoin et il a ensuite recalculé les votes de chaque nœud en supprimant celui octroyé au nœud 2 (SQL142). Cette nouvelle configuration prend en compte le fait que le nombre de nœuds restants pouvant voter est devenu pair et qu’il faut supprimer un vote à un des nœuds pour que celui-ci devienne impair.

quorum_16

En arrêtant successivement les nœuds 2 et 4 le quorum est de nouveau recalculé comme avec Windows 2012. Le nœud 3 est le seul à posséder un poids de vote car il possède le groupe de ressource système (nom réseau + IP du cluster Windows). Cela permet également en cas de défaillance du nœud 1 (ou éventuellement du nœud 3) de garder le cluster Windows en ligne

 

quorum_17

 

L’utilisation du témoin dynamique est également intéressante dans des configurations géo-clusters où le nombre de nœuds sur chaque site est équivalent. Prenons par exemple la configuration suivante :

quorum_18

Le cluster Windows possède 4 nœuds répartis par pair sur chaque site. Tous les nœuds du cluster peuvent voter et comme nous sommes dans une configuration où le nombre de nœuds par site est pair une ressource témoin a été ajouté sur le 1er site pour augmenter la disponibilité du cluster en cas de défaillance du lien réseau inter-sites. En effet sans cette ressource témoin, si une défaillance survenait sur ce lien réseau  nous pourrions être dans un cas de “split brain” avec l’apparition d’un partitionnement du cluster Windows en 2 parties. De plus le nombre de votes dans ce cas ne suffirait plus puisque la perte d’un seul nœud ne serait plus acceptable. Avec l’introduction du témoin nous éliminons du coup ce phénomène de “split brain” et nous augmentons en même temps le nombre global  de nœuds qui pouvant être défaillants soit 2 nœuds. Cependant la perte de cette ressource témoin en mode statique nous ramènerait au problème décrit un peu plus haut dans le billet . L’utilisation du témoin dynamique plus une nouvelle fonctionnalité de Windows Server 2012 R2 appelée “tie breaker” permet de garder le nombre de noeuds restants pouvant voter impair. C’est ce que nous pouvons voir ici après la perte du témoin :

quorum_19

Cependant si ce recalcul dynamique est bénéfique ici il serait intéressant aussi de pouvoir contrôler quels nœuds auront la priorité sur les autres pendant le recalcul. Dans notre cas nous voudrions par exemple garder un maximum de disponibilité sur le site A et donc donner la priorité aux serveurs correspondants. Heureusement pour nous il est possible de configurer des priorités par nœud avec la propriété de cluster  LowerQuorumPriorityNodeID.

quorum_20

quorum_21

On voit ici que l’assignement des poids de vote a changé en fonction de notre paramétrage.

image

Maintenant si nous perdons totalement le site 2 nous pourrons garantir que le cluster Windows sera encore en ligne.

Bonne configuration de quorum !!

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

Cas d’utilisation d’un groupe de disponibilité multi-listeners

Mis en avant

Pour ceux qui ont déjà installé SQL Server AlwaysOn vous avez pu sans doute remarquer qu’il est possible d’avoir uniquement un seul listener pour un groupe de disponibilité. Sur le principe cela n’est pas gênant dans la plupart des configurations mais comment dans le cas où un client cherche absolument à décomissionner un serveur SQL avec une multitude d’application et qu’il est difficile de changer le nom de serveur dans la chaîne de connexion de ces applications.

Prenons un cas concret que j’ai pu rencontrer chez un client lors d’une migration et qui aurait pu poser problème lors du passage à une architecture haute disponibilité SQL Server AlwaysOn :

  • Plusieurs applications installées sur une centaine de postes clients depuis longtemps et qui ne sont plus supportées par les différents éditeurs La chaîne de connexion des applications est codée en dur (pas de chance …) et l’intervention des différents consultants peut coûter cher d’autant plus que ces derniers proposent de mettre à jour l’application pour résoudre le problème. hors le client n’a pas forcément le budget pour cela car il n’a pas pu anticiper ce problème … bref le changement du nom de serveur pour cette application n’est pas envisageable et pourtant il nous faut migrer les bases de données pour décomissionner au plus vite notre ancien serveur SQL vers une infrastructure AlwaysOn

Quelles solutions avons-nous à disposition ?

–> Nous pouvons créer un listener avec l’ancien nom du serveur SQL et son ancienne adresse IP mais deux problèmes se posent :

  • le but est à l’origine est de pouvoir décomissionner l’ancien nom de serveur qui n’est plus conforme à la nouvelle nomenclature générale de nommage et doit être absolument changé dès que possible.
  • le planning de migration nous impose de migrer les applications en douceur et nous impose de garder de migrer les applications facilement modifiables au départ et garder les applications statiques pour la fin. Cette option n’est donc pas envisageable.

–> Nous pouvons utiliser un alias CNAME avec l’ancien nom de serveur qui pointe vers le nouveau listener. Cela suppose que notre ancien serveur soit complètement décomissionné pour pouvoir utiliser notre nouveau listener mais notre planning de migration nous impose encore une fois de garder l’ancien serveur pendant la phase de migration jusqu’à la fin. 

Dans ce cas cas comment faire ? He bien une solution (parmi quelques autres) serait de créer un second listener pour notre groupe de disponibilité. Comment ? En fait l’astuce consiste à passer par le gestionnaire de cluster et de créer un nouveau point d’accès client (Client Access Point) pour le rôle associé au groupe de disponibilité concerné avec un nom réseau et une adresse IP :

aag_new_cllient_access_point

aag_new_cllient_access_point_2

Une fois la ressource associé au nouveau point d’accès client créé il suffit de le mettre en ligne et de configurer les dépendances associées au groupe de disponibilité. L’utilisation d’une logique de dépendance à base de AND est possible mais il est préférable d’utiliser une logique de dépendance à base de OR pour garder le groupe de disponibilité en ligne autant que possible.

aag_new_cllient_access_point_3

Une fois le tout configuré on peut avoir apparaître un nouveau listener dans SQL Server Management Studio.

aag_new_cllient_access_point_4

L’utilisation de la vue système sys.availability_group_listeners nous montre également que le groupe aag possède bien 2 listeners :

image

La colonne is_conformant indique que le listener peut être managé depuis SQL Server. On voit également que pour le moment le listener n’est pas encore exploitable car aucun port d’écoute est configuré. Puisque le listener est configurable depuis SQL Server nous pouvons changer facilement son port depuis SQL Server Management Studio.

image

image

Un test de connexion et le tout fonctionne !!

image 

 

Merci à Qiang Wang pour l’astruce

David BARBARIN (Mikedavem)
MVP et MCM SQL Server