Pour les bases de données critiques, il est indispensable de mettre en place des solutions de haute disponibilité et de reprise d’activités en cas de défaillance du site de production.

SQL Server propose plusieurs technologies à partir desquelles il est possible de construire des solutions de haute disponibilité et de reprise d’activités adaptées aux différents besoins et contraintes des entreprises.

Problématique

  • Comment appréhender l’ensemble des technologies HA-DR SQL Server ?

  • Comment choisir une solution HA-DR SQL Server adaptée aux besoins et contraintes de l’entreprise ?

  • HA-DR SQL Server et la virtualisation, quelle intégration et complémentarité ?

Solutions/Bénéfices

  • Une présentation comparative complète

  • Une démarche méthodique de choix de la solution

  • Des recommandations pratiques basées sur nos expériences de projets chez nos clients

  • Le but de cet article est de vous apporter des éléments de réponse à ces questions dans le cadre spécifique de la mise en œuvre de SQL Server.

 

 

Après une définition de quelques acronymes, nous commençerons par une discussion générale et comparative des caractéristiques des différentes technologies HA-DR proposées par SQL Server.

A partir de ces éléments de base, nous présenterons une démarche générale permettant d’aboutir à un choix de solution technique.

Nous ferons ensuite un focus particulier sur les évolutions récentes du Windows Server (2012 et 2012 R2) en matière de service cluster (« WSFC ») et de virtualisation. Nous discuterons de leurs apports dans la construction des solutions HA-DR SQL Server les plus avancées.

Enfin, basé sur nos expériences de mise en œuvre chez les clients, nous proposerons quelques recommandations pratiques concernant le choix et la mise en œuvre de solutions HA-DR SQL Server en environnement virtualisé.

 

Petit lexique des acronymes

Avant d’entrer dans les détails de notre discussion, faisons quelques clarifications préalables de terminologies et d’acronymes.

« HA-DR » ou « High Availability and Disaster Recovery » 

Nous utiliserons dans la suite de notre discussion ce sigle compact à la place de « Haute Disponibilité et Reprise d’Activités après perte d’un site de production ».

« HA » et « DR » désigne respectivement les 2 aspects / segments distincts de la problématique générale de la continuité de services informatiques.

  • « HA » :
    • RTO de l’ordre de minutes ;
    • RPO : zéro perte de données ou proche de zéro ;
    • Pas ou peu d’intervention humaine ;
    • Routage automatique des utilisateurs / applications clientes.
  • « DR » :
    • RTO de l’ordre d’une à plusieurs heures, voire de jours ;
    • RPO : pertes de données tolérées en fonction de la criticité de la plate-forme cible,
    • Interventions humaines nécessaires, voire voulues :
      • Le basculement d’un site vers l’autre pouvant être une opération lourde, il sera décidé après évaluation plus approfondie de la situation … 
      • Opérations manuelles pour basculer les clients vers le site de secours.

 

« WSFC » (Windows Server Failover Cluster)

Il s'agit du service de clustering intégré à Windows Server. Cette technologie est à la base de toutes les solutions « SQL Server AlwaysOn ».

 

« AlwaysOn »

Correspond à un terme marketing qui désigne l’ensemble des technologies « HA-DR » disponibles avec SQL Server.

En particulier, depuis la version SQL Server 2012, ce terme englobe 2 solutions technologiques distinctes :

  • « AlwaysOn FCI » (Failover Clustered Instance) » que nous désignerons par « FCI » dans la suite. Il s’agit de la solution « Instance Clusterisée » de SQL Server basée sur le service « WSFC » de Windows (ou « MSCS » sur les versions plus anciennes de Windows).
  •  « AlwaysOn AG » (Availability Group) que nous désignerons par « AG » dans la suite. Il s’agit de la solution « Availability Group », nouveauté introduite avec SQL Server 2012, appelée à remplacer le « Database Mirroring ».

 

Caractéristiques comparatives des techniques "HA-DR" SQL Server et Démarche pour le choix d'une solution

Les techniques « HA-DR » SQL Server que nous allons discuter dans cet article sont les suivantes :

- Instance clusterisée (FCI)

- « Availability Group » (AG)

- « Database Mirroring » (DBM)

- « Log Shipping »

 

Remarque :

Certaines déclinaisons de la Réplication, en particulier « Transactionnelle », « Peer-to-Peer » et « Merge » (Fusion), peuvent aussi, sous certaines conditions, remplir les fonctions de haute disponibilité ou servir à la reprise d’activités. Mais il s’agit souvent d’un « produit dérivé » d’une solution avant tout conçue pour répondre à des besoins de propagation de données applicatives.

Pour la simplicité de notre discussion, nous excluons la Réplication de la liste des solutions HA-DR « pure players ».

Sans entrer dans leur description détaillée, voici la liste des technologies « HA-DR » disponibles avec SQL Server que nous allons discuter dans cet article :

 

Tableau 1,  Technologie HA-DR SQL Server et les pré-requis Version / Edition

   Pré-requis Version / Edition

Instance Clusterisée (FCI)

"Availability Group" (AG)

"Database Mirroring"

Log Shipping

   Version

2000
ou plus

2012
ou plus

2008 et
2008 R2
annoncé "obsolète" avec 2012

2000
ou plus

   Edition Entreprise ou plus

Oui

Oui

Oui

Oui

   Edition Standard

Oui (limité à 2 noeuds)

Non

Oui

Oui

 

Pour déterminer l’architecture d’une solution HA-DR SQL Server, notre démarche part des éléments suivants :

- Sans surprise, arrivent en première place les Besoins et les Contraintes ; Plus précisément, cela concerne les termes de SLA, les exigences RTO et RPO, les contraintes liés à l’environnement cible, etc.

Sans préjuger du contenu exact de vos besoins et contraintes, une bonne pratique générale consiste à les classer selon leur importance / criticité.

 

- Ensuite, nous nous appuyons sur les informations synthétisées dans les 4 tableaux suivants pour dégager une liste de solutions candidates :

1. Le tableau des « Usages typiques » indique pour chaque technologie, ses domaines d’application les plus appropriés ;

2. Le tableau des « Caractéristiques et Fonctionnalités » permet de confronter les besoins avec les caractéristiques et les fonctionnalités et de faire un premier tri parmi les différentes techniques, et obtenir ainsi une 1ère liste de solutions potentielles.

3. La « Matrice de compatibilité et d’interopérabilité » complète le tableau des « Caractéristiques et Fonctionnalités ». En effet, il est souvent nécessaire de combiner plusieurs des techniques présentées pour aboutir à une solution finale répondant à l’ensemble des besoins exprimés. La Matrice de compatibilité et d’interopérabilité permet de vérifier plus en avant la validité d’une solution envisagée.

La « compatibilité » doit être comprise ici de la manière suivante : 2 technologies sont considérées comme compatibles ou interopérables si et seulement si une base de données peut être présente en même temps dans 2 instances d’implémentation de ces 2 technologies. Par exemple :

    • La « FCI » (en tant que solution technique) n’est pas compatible avec elle-même, car une base de données ne peut faire partie de 2 FCI en même temps.
    • De la même manière, l’« AG » (en tant que solution technique) n’est pas compatible avec elle-même, car une base de données ne peut faire partie de 2 AG en même temps.
    • La « FCI » est compatible avec l’« AG », car une base de données peut faire partie d’une FCI et d’un AG. En fait, dans ce cas précis, c’est la FCI toute entière qui fait partie du AG.

4. Le tableau des « Principales Conditions et Contraintes de Mise en œuvre » permet d’affiner la liste précédente avec la prise en compte des conditions et contraintes de mise en œuvre, et d’aboutir à une liste de solutions candidates compatibles avec les contraintes de leur environnement cible.

 

- Enfin, nous intégrons les éléments de débits et de volumétries, ainsi que les différents niveaux de services attendus (nominal et en cas de défaillance de certains serveurs) pour dimensionner la plate-forme finale.

 

Tableau 2, Usages typiques

   Type d'usage

Instance Clusterisée (FCI)

"Availability Group" (AG)

"Database Mirroring"

Log Shipping

   Hautre disponibilité (HA)

Oui

Oui

Oui

Non

   Reprise d'activités (DR)

Oui
(nécessite une réplication au niveau stockage)

Oui

Oui

Oui

 

 

Tableau 3, Caractéristiques et Fonctionnalités  

   Caractéristiques et Fonctionnalités

Instance Clusterisée (FCI)

"Availability Group" (AG)

"Database Mirroring"

Log Shipping

 

  Principe de fonctionnement

 

 

Redémarrage du service DBMS sur un autre serveur

 

 

Transfert et Application en continue des journaux de transactions (Transaction Logs) sur les secondaires

 

 Transfert des journaux des transactions (Transaction Log) par "backup & copy" et Application sur les secondaires par "Restore"

 

  Reprise automatique des access aux données

 

 

Oui

 

 

Oui
(sur réplicat en mode synchrone)

 

 

Oui
(sur réplicat en mode synchrone)

 

 

Non

 

  

  Temps de reprise

 

de plusieurs dizaines de secondes à plusieurs minutes

 de l'ordre de quelques secondes

 de l'ordre de quelques secondes

 de quelques secondes à quelques minutes, en fonction du volume de log à restaurer

  

  Perte de données (transactions commitées)

 

 

Non

 

 Non, en mode synchrone;
Oui, en mode asynchrone
 

 

Non, en mode synchrone;
Oui, en mode asynchrone

 

 Oui, en fonction du volume de log non récupéré 

  

  Routage automatique des clients

 

 

Oui

 

 Oui
(vers un réplicat en mode synchrone, si un listner est configuré)

 Oui
(si le réplicat est en mode synchrone et un témoin est configuré)

Non

  

  Support de transactions "inter bases"

 

 

Oui

 

Non

 

Non

 

 

Non

 

  

  Compatibilité MSDTC

 

Oui

Non

 

Non

 

 

Non

 

  

  Périmètre de basculement / reprise

 

Instance SQL Server

 

Bases de données faisant partie du même AG

 

Base de données 

 

Base de données

 

  

  Copie(s) secondaire(s) accessible(s) en lecture

 

 

N/A

 

 

Oui

 

Non
(un access en lecture au réplicat est possible par l'intermédiaire de snapshots)
 

Non, si le secondaire est en mode "Restore";
Partiellement (en dehors des opérations de "restore"), si le secondaire est en mode "Stand By"

  

  Nombre de copies secondaires

 

 

N/A

 

 

4 en 2012
8 en 2014

 

 

1

 

 

1 à plusieurs, sans limite théorique

 

  

Possibilité de "delayed restore" (pour faciliter la récupération de données suite à une erreur d'utilisateur)

 

N/A

Non

Non

Oui

 

 

Tableau 4, « Matrice de compatibilité et d’interopérabilité »*

 

FCI

AG

DBM

Réplication

Réplication

FCI

Non

Oui

Oui

Oui

Oui

AG

Oui

Non

Non

Oui

Oui

DBM

Oui

Non

Non

Oui

Oui

Log Shipping

Oui

Oui

Oui

Non

Oui

Réplication

Oui

Oui

Oui

Oui

Oui

* La « compatibilité » est décidée selon la réponse à la question « est-ce qu’une même bases de données (logique) peut être impliquée en même temps dans les instances de mise en œuvre de 2 technologies ? »

 

 

Tableau 5, Principales Conditions et Contraintes de mise en oeuvre 

 

Principales Conditions et Contraintes de mise en oeuvre

 

Instance Clusterisée (FCI)

"Availability Group" (AG)

"Database Mirroring"

Log Shipping

  

Nécessite disques à access partagés (Shared Storage)

 

 

Oui

 

Non

Non

Non

 

Nécessite espaces disques supplémentaires

 

 Non, si cluster mono site;
Oui, si cluster multi-site avec réplication au niveau stockage
 

 

Oui
(x nb de réplicats)

 

Oui

 

Oui
(x nb de secondaires)

 

 

Nécessite Cluster Windows (WSFC)

 

Oui

 

Oui

 

 

Non

 

 

Non

 

 

Nécessite AD

 

Oui*

 Oui* 

 

Non

 

 

Oui**

 

* Avec Windows 2012, AD est nécessaire pour former un cluster WSFC, mais une fois formé, un cluster WSFC peut démarrer et fonctionner sans AD (AD-less Cluster Bootstrapping).

Avec Windows 2012 R2, il sera en plus possible de former un cluster WSFC sans AD (AD detached cluster). Mais cette configuration sera accompagnée de restrictions importantes (Authentification
Kerberos non disponible, SQL Server FCI avec authentification SQL Server, etc.), et elle est irréversible dans le sens que si le besoin de rejoindre le domaine se fait sentir plus tard, il faudra supprimer le cluster et le recréer complètement.

** Pour configurer la sécurité d'accès au partage des fichiers des journaux de transactions, l'utilisation de comptes domaine est recommandée.

("How to configure security for SQL Server log shipping": http://support.microsoft.com/kb/321247 ).

 

Les évolutions récentes du cluster Windows « WFSC »

 Etant donné l’importance fondamentale du service « WSFC » dans la construction d’une solution SQL Server «AlwaysOn » (FCI et/ou AG), les évolutions récentes de WSFC ont des impacts positifs directs sur les capacités des solutions SQL Server « AlwaysOn ».

Les évolutions récentes les plus significatives de WSFC sont les suivantes :

-          Cluster multi-site sans contrainte de « VLAN étendu » (avec Windows 2008) (SQL Server FCI et AG supportent les déploiements Multi-site sans contrainte de « VLAN étendu » depuis la version SQL Server 2012) ;

-          « Cluster Shared Volume » (avec Windows 2008 R2) (SQL Server FCI supportera les CSV avec la prochaine version SQL Server 2014);

-          Cluster à stockage asymétrique (avec Windows 2008 R2 SP1) (SQL Server FCI et AG supportent les volumes partagés asymétriques depuis la version SQL Server 2012) ;

-          Quorum statique avec nombre de vote configurable pour chaque nœud (Windows 2008 R2 Hotfix 348347)

-          Quorum dynamique (Windows 2012 et 2012 R2)

En ce qui concerne SQL Server AlwaysOn (FCI et AG) qui, rappelons-nous, sont entièrement basés sur le WSFC, l’évolution du modèle de quorum est particulièrement importante et intéressante.   

 

Quorum dynamique (et Témoin dynamique)

Avant Windows 2012, le modèle de quorum d’un cluster WSFC est statique dans le sens que le vote d’un membre du cluster est déterminé par la configuration et ne peut être modifié sans un arrêt du cluster.

Pour éviter le « split brain » et les risques de corruptions de données qui s’en suivent, un cluster doit s’assurer que le quorum de la majorité des nœuds est atteint pour continuer à fonctionner et dans le cas contraire, de s’éteindre automatiquement, plutôt que d’essayer de se maintenir au risque de tomber dans la situation de « split brain ».

Le caractère statique du model de quorum de WSFC (jusqu’à Windows 2008 R2) induisait des contraintes de mise en œuvre et impactait sur le niveau de disponibilité globale des clusters WSFC.

En effet, avec un modèle de quorum statique,

-          Un cluster Windows ne peut survivre à la défaillance de plus de 50% de ses nœuds (sauf si le modèle de quorum est configuré à « Disk seul », ce qui n’est pas recommandé à cause de son aspect « Single Point of Failure ») ;

-          Dans le cas d’un cluster WSFC multi-site (de plus en plus de clients déploient ce type de solution pour leur besoin en HA-DR), un cluster ayant le même nombre de nœuds sur les 2 sites ne pourra survivre à la coupure de connexion entre les 2 sites.

Pour dépasser ces contraintes et proposer à configuration matérielle équivalente, un niveau d’efficacité et de disponibilité plus élevé, Windows 2012 introduit le modèle de quorum dynamique. Windows 2012 R2 apportera prochainement des améliorations significatives à ce modèle et il nous sera alors possible de construire des clusters multi-nœuds et multi-site plus robustes, pouvant résister

-          A la perte simultanée de 50% de ses nœuds ;

-          A la perte progressive de plus de 50% de ses nœuds, voire aller jusqu’au « last man standing ».

Le quorum dynamique est une option de configuration à la création d’un cluster (par défaut, l’option est activée).

Avec l’option « Dynamic Quorum » activée, un cluster WSFC réévalue le vote à accorder à chaque nœud en fonction de son état. Cette réévaluation a lieu à la suite d’un changement d’état d’un nœud membre du cluster, à condition que le quorum reste atteint :

-          Au démarrage du cluster, un vote dynamique (dynamicWeight = 1) est attribué à chaque nœud en service ayant un vote par configuration (nodeWeight = 1) ;

-          Le vote dynamique est retiré (dynamicWeight = 0) à un nœud venant d’être hors service, quel que soit l’origine de cette perte (arrêt planifié ou accidentel), et le quorum dynamique est calculé sur la base des votes dynamiques des nœuds en service ;

-          Inversement, si un nœud hors service (avec 1 vote par configuration, nodeWeight = 1) redevient opérationnel et réintègre le cluster, le vote dynamique lui sera rendu (dynamicWeight = 1).

-           Si un vote a été explicitement accordé à un nœud (nodeWeight = 1), son vote dynamique (dynamicWeight) sera 0 ou 1 en fonction de son état ; Si le vote a été explicitement retiré à un nœud (nodeWeight = 0), son vote dynamique (dynamicWeight) restera 0 quel que soit son état.

En Windows 2012, la réévaluation du quorum dynamique supprime le vote « dynamique » du nœud perdu quel que soit la parité du nombre total de votes dynamiques restant (pair ou impair), ce qui peut être problématique si la connexion vient à être coupée entre les 2 sites ayant le même nombre de nœuds restant opérationnels : dans ce cas, le cluster tombe à cause de la perte du quorum, dommage pour la disponibilité du service applicatif !

En Windows 2012 R2,  la réévaluation du quorum dynamique maintient le nombre total de votes à un chiffre impair. Pour cela, 2 actions sont possibles :

-          Si un témoin est configuré et disponible (par défaut, le Wizard de création du cluster nous invite à en configurer un), supprimer ou ajouter le vote « dynamique » du témoin ;

-          Si aucun témoin n’est disponible, supprimer le vote dynamique de l’un des nœuds restant opérationnels. Le choix du nœud à qui on va supprimer le vote dynamique est aléatoire et non configurable.

La figure suivante illustre par un exemple simple, le fonctionnement du quorum dynamique avec les améliorations apportées par Windows 2012 R2 (témoin dynamique et maintien du nombre total de votes dynamiques à un chiffre impair) et montre la situation du « Last man standing » où le cluster reste actif jusqu’au dernier nœud opérationnel.

  

La virtualisation et Les solutions HA-DR SQL Server

De nos jours, avec la montée en puissance des technologies de virtualisation et de « Private Cloude », d’autres questions apparaissent aussi naturellement dans l’esprit des architectes et responsables techniques des SI entreprise :

-  Les solutions HA-DR apportées par les technologies de virtualisation sont-elles compatibles, dans le sens de la coexistence, de l’interopérabilité et de la complémentarité, avec celles plus classiques / natives, des environnements physiques ? 

-  Quelle approche globale adopter pour les solutions HA-DR SQL Server dans un environnement virtualisé ou de type « Private-Cloud » ?

La discussion qui suit utilise les termes propres à Hyper-V, mais une grande partie d’entre eux ont leur équivalent dans les autres environnements hyperviseurs et les principes de mise en œuvre de solutions que nous formulons ici peuvent donc aussi s’appliquer, avec les précautions nécessaires liées à la politique de support de chaque fournisseur de technologie de virtualisation.

La virtualisation de SQL Server est officiellement supportée par Microsoft depuis la version SQL Server 2008. Avec les progrès en matière de montée en charge des plates-formes hyperviseur, une part de plus en plus important de traitements SQL Server peut être virtualisé, ceci au moins du point de vu de la performance et de la montée en charges, lorsque les allocations de ressources des VM sont garanties.

En termes de haute disponibilité et de reprise d’activités, la virtualisation apporte de solutions innovantes pour assurer la continuité de service des VM :

- Hyper-V cluster avec Cluster Shared Volume (CSV)

- Live-Migration

- Storage-Migration

- Hyper-V Replicat

Ces solutions sont compatibles et complémentaires avec les solutions HA-DR de SQL Server discutées précédemment.

Ainsi, avec les solutions HA-DR Hyper-V, les arrêts de services dus aux maintenances et défaillances matérielles des serveurs physiques sont couverts.

Restent à couvrir les arrêts dus aux maintenances ou défaillances de la VM (OS essentiellement) et de l’instance SQL Server. Pour cela, les dispositifs de type WSFC, SQL Server FCI ou AG doivent être mis en place au niveau des VM et des instances SQL Server.

 

Mise en oeuvre de WSFC au niveau des VMs (guest clustering)

Avant Hyper-V 3 (Windows 2012), les WSFC sur les VM ne peuvent être configurés qu’avec des stockages iSCSI. Hyper-V 3 propose le support de l’adaptateur vSAN qui permet aux nœuds (VM) d’un cluster WSFC d’accéder aux volumes SAN configurés au niveau du host Hyper-V.

Cependant, ces 2 approches présentent l’inconvénient d’exposer aux VM la structure du stockage « physique ». Cet inconvénient (le mélange de genre entre virtuel et physique) reste supportable dans un environnement virtualisé privé et de faible complexité. Mais elles deviennent beaucoup moins envisageables pour un environnement partagé (multi-tenant) de type « cloud » privé ou public.

Windows 2012 R2 (CTP1) proposera le support de Shared VHD (SVHD). Les Guest Clusters pourront se passer des insterfaces iSCSI et vSAN et utiliser les SVHD en tant que volumes partages.

 

Recommandations

Pour les instances SQL Server hébergeant des bases de données les plus critiques et les plus exigeantes en termes de performance et de disponibilité, nous recommandons le déploiement de SQL Server AlwaysOn (FCI et/ou AG) sur serveurs physiques.

Pour les instances SQL Server hébergeant des bases de données critiques en termes de performance et moyennement critique en termes de disponibilité, nous recommandons le déploiement de SQL Server en environnement virtualisé avec Hyper-V 3 (Windows 2012 ou plus), sans FCI, ni AG ; limité à 1 seule instance par VM afin de simplifier les procédures de déploiement / provisionning et d’exploitation.

 

Si la virtualisation des instances SQL Server est un choix non négociable de l’entreprise, pour les instances SQL Server hébergeant des bases de données les plus critiques en termes de disponibilité, il est possible d’envisager le déploiement de cluster WSFC au niveau des VM (guest cluster) et SQL Server AlwaysOn (FCI ou AG) sur le « guest cluster ». Dans ce cas, utiliser iSCSI, vSAN ou SVHD en fonction des autres considérations telles que : infrastructure d’IO existante; prédictibilité des performances des IO ; l’isolation des environnements VM ; etc.

Dans ce dernier cas, nous recommandons aussi la plus grande prudence avant la mise en œuvre, et que la plus grande clarté soit faite sur

-  les SLA de la solution et des sous-systèmes (Hypervisuer, IO, réseaux, VM et SQL Server …)

-  les responsabilités respectives des administrateurs système et des DBA.

 

Nous ne recommandons pas la mise en œuvre de solutions complexes combinant la virtualisation et plus d’une technologie HA-DR SQL Server, par exemple FCI et AG sur un cluster VM multi-site.

En effet, cette dernière solution implique une très grande complexité de mise en œuvre. Cette grande complexité peut elle-même être à l’origine de défaillances. En cas de problème grave, cette grande complexité augmente la difficulté technique de diagnostic et de résolution d’incident, sans oublier les efforts nécessaires pour coordonner les interventions des experts Hyper-V, WSFC et SQL Server « AlwaysOn » …

Tout ceci peut finalement conduire à une solution dont le niveau de disponibilité effective sera plus faible  qu’une solution plus simple.

 

L’expertise Microsoft Consulting Services en matière de Haute Disponibilité SQL Server et de Recouvrement de désastre

Les consultants et architectes de l’équipe MCS SQL/BI sont dotés d’une solide expérience en matière de conception, de déploiement et d’audit de solutions de Haute Disponibilité SQL Server et de Recouvrement de désastre (PRA).

Cette expertise mise au service des clients MCS permet le déploiement d’applications critiques des entreprises (« Business Mission Critical ») avec l’assurance des niveaux de performance et de disponibilité attendus.

L’accompagnement Microsoft Consulting Services peut se faire à travers :

Une conception et un déploiement de solution de bout en bout

Un transfert de compétences vers les Equipes IT du client

Des missions d’audit

Voici quelques exemples de réalisation :

  • Banques, Média, Télécom : Consolidation financière & Reporting
  • Grande Distribution : Système complet de gestion Front Office & Back Office
  • Industrie de luxe : ERP d’entreprise

 

 

Pour plus d’informations sur les offres packagées Microsoft Consulting Services, rendez-vous sur http://www.microsoft.com/france/services

Plus d’informations sur les blogs « SQL Server chez les clients ».


 

Xiaozhao Li, Consultant SQL Server, Microsoft Consulting Services

J’ai rejoint MCS en 1999, d’abord en tant que consultant en développement et architecture applicative. Je me suis ensuite spécialisé en SQL Server pour accompagner nos clients dans la conception, la mise en œuvre et l’optimisation des bases de données critiques.