DAT303 Rationalisation de vos infrastructures Windows / SQL Server

Présentation au sujet: "DAT303 Rationalisation de vos infrastructures Windows / SQL Server"— Transcription de la présentation:

1

2 DAT303 Rationalisation de vos infrastructures Windows / SQL Server
Laurent Marzouk Architecte solutions SQL Server / BI Microsoft France 9 février 2011

3 Descriptif de la session
Titre: Scenarii de rationalisation des architectures Windows Server et SQL Server  (DAT303) Speaker: Laurent Marzouk Horaire: Mercredi 9 février 2011, 17: :30 URL: Description: Perspectives et enjeux d'un projet de rationalisation d'infrastructures SQL Server, démarche et outils, scenarii de consolidation et/ou de virtualisation d'instances SQL Server, outils et techniques pour garantir les SLA

4 Agenda Perspectives et enjeux Démarche et outils
Scenarii de consolidation et de virtualisation Outils et techniques pour garantir les SLA Etude de cas Ressources Questions

5 Rationalisation, kesako ?
Définition Wikipédia: « Réorganisation pour accroitre l’efficacité économique »

6 Observations classiques des DSI
Rationaliser l’organisation de la Production Informatique “J’ai trois fois plus de serveurs qu’il y a deux ans; chaque opération sur ces serveurs me coûte temps et argent ». (DSI) Baisser Le TCO “Il revient trop cher d’exploiter un nombre aussi grand et croissant de serveurs. » (Directeur Financier) Harmoniser et Mettre à jour L’Architecture Augmenter les SLA : Performances, Disponibilité, Continuité de service… “La mise à jour de tous les serveurs est trop longue, d’autant que les versions sont très disparates. » (Responsable informatique) Diminuer les temps de déploiements « time to market ». “Le déploiement de nouvelles applications prend trop de temps dans notre infrastructure actuelle. » (Responsable informatique) Les objectifs des Projets de consolidations Gartner : 50% des 2000 plus grandes entreprises ont démarré la consolidation de leurs serveurs; 30% de plus entameront la consolidation dans les 5 ans à venir.

7 Facteurs motivant un projet de consolidation
Réduction du CAPEX Homogénéiser le parc matériel & logiciel Réduire le nombre de serveurs Réduire les besoins d’espace, de puissance et de chaleur (approche Green-IT) Réduction de l’ OPEX Améliorer le taux d’utilisation des matériels Améliorer l’efficacité des opérations d’administration et d’exploitation Diminuer les coûts et la complexité induits par les besoins de Haute Disponibilité Agilité de l’infrastructure Répartition de charge & Provisioning Dynamique Standardisation des services Capacité de calcul des matéirels Matériels sous-utilisés Nombre de bases de données Administrateurs surchargés Nombre de DBA 1990 2000 2010

8 Agenda Perspectives et enjeux Démarche et outils
Scenarii de consolidation et de virtualisation Outils et techniques pour garantir les SLA Etude de cas Ressources Questions

9 Scenarii de consolidation
Plusieurs approches de consolidation existent et peuvent être combinées Typiquement, au fur et à mesure que le niveau d’isolation croît, la densité décroît et les coûts d’exploitation augmentent Plus forte isolation  Coûts plus élevés Plus forte densité  Coûts plus faibles Environnements gérés par l’IT Machines virtuelles Instances Bases de données Schémas Sales_1 Marketing_1 Online_Sales ERP_10 DB_1 DB_2 DB_3 Consolidate_1

10 Bases de données Consolidation au niveau Bases de Données
Plusieurs bases sont regroupées dans une seule instance Modèles communs de sécurité, de compatibilité et de gestion requis Peut nécessiter des changements au niveau des applications et scripts existants Permet de réduire les coûts de gestion Meilleure isolation & allocation des ressources via le Resource Governor Plus forte isolation  Coûts plus élevés Plus forte densité  Coûts plus faibles Machines virtuelles Instances Bases de données Sales_1 Marketing_1 Online_Sales ERP_10 DB_1 DB_2 DB_3 Consolidate_1

11 Instances Consolidation au niveau Instance
Plusieurs instances s’exécutent sur un système Isolation complète au niveau schéma et en termes de sécurité Isolation partielle des ressources systèmes & des OPE Conflits potentiels dans les Namespace, les ressources et les rôles systèmes IO, System Memory and CPU are typical density limiters Plus forte isolation  Coûts plus élevés Plus forte densité  Coûts plus faibles Machines virtuelles Instances Bases de données Sales_1 Marketing_1 Online_Sales ERP_10 DB_1 DB_2 DB_3 Consolidate_1

12 Virtualisation Plus forte densité  Coûts plus faibles
Consolidation de Machines Virtuelles Isolation forte entre les applications Possibilité de capturer et déplacer aisément les charges d’exécution Configuration de la Haute Disponibilité au niveau de la VM Gestion flexible du stockage Moins de systèmes, mais autant d’OS à gérer Utilisation accrue des ressources Plus forte isolation  Coûts plus élevés Plus forte densité  Coûts plus faibles Machines virtuelles Instances Bases de données Sales_1 Marketing_1 Online_Sales ERP_10 DB_1 DB_2 DB_3 Consolidate_1

13 Agenda Perspectives et enjeux Démarche et outils
Scenarii de consolidation et de virtualisation Outils et techniques pour garantir les SLA Etude de cas Ressources Questions

14 Quelle approche de consolidation choisir ?
Evaluer les paramètres clés pour votre environnement Isolation entre les applications Isolation en terme de sécurité Prédictibilité des Performances : Isolation des Ressources Haute disponibilité (HA) : Isolation des pannes Densité des applications Performances : Efficacité de l’utilisation des Ressources Impact sur la l’exploitabilité HA : Atténuer les points de défaillance (SPoF) Time to Market Combien de temps faut-il pour consolider ? Est-ce que ma solution peut monter en charge ? Réduire le CAPEX Réduire l’OPEX IT Agile

15 Fonctions & outils pour la consolidation et la virtualisation d’instances SQL Server
Resource Governor Windows Server Resource Manager (WSRM) Microsoft Assessment and Planning (MAP) + MS Consolidation Planning Tool for SQL (CPT) Cluster Failover entre VMs invités System Center Virtual Machine Manager Live Migration Hyper-V Sysprep pour SQL setup Data Tier App Utilitaire de Points de Contrôles and Instances Managées > 64 processeurs logiques Nouveauté de SQL 2008 R2 ® Forte Isolation Faible Densité Instances Machines Virtuelles Bases de données Forte Densité Faible Isolation date

16 Consolidation vs. Virtualisation
Critères Consolidation Virtualisation Identiques Réduction du nombre de serveurs Economie d’énergie, sur les licences et les opérations de maintenance Problèmes de garantie des performances Différents Moins d’OS Même nombre d’OS Plus de bases / instances Mêmes bases / instance Moins d’instances / serveurs Même nombre d’instances / serveurs Possibilité de MAJ Windows / SQL Pas de MAJ Windows / SQL Server Charges suppl. d’étude et tests Approche de type « boite noire » Mixité + importante des workloads Couche technologique suppl. Forte intégration avec le matériel Abstraction de la couche matérielle Les approches de Consolidation et de Virtualisation ne sont donc pas exclusives mais complémentaires

17 Licensing Windows Server 2008 R2 1 licence = Edition Standard
1 serveur hôte + 1 machine virtuelle (VM) Edition Entreprise 1 serveur hôte + jusqu’à 4 VM Edition Datacenter 1 serveur hôte + nombre de VM illimité SQL Server 2008 R2 1 licence = Edition Standard Jusqu’à 4 instances consolidées sur le serveur hôte et/ou 1 VM par licence CPU Edition Entreprise (*) Jusqu’à 50 instances consolidées sur le serveur hôte (25 instances clusterisées) et/ou 4 VM par licence CPU Edition Datacenter Nombre de VM illimité (*) SQL Server 2008 R2 Edition Entreprise est limité à 8 sockets et 2 To de RAM

18 Facteurs de risque pour les projets de virtualisation
Objectifs du projet non / mal définis Profils d’activité SQL et critères de performance non connus et/ou compris Combinaison de différents types d’activité (OLTP / Reporting / OLAP) Virtualisation de serveurs présentant une activité CPU et/ou mémoire intensive Tests insuffisants Mauvaise configuration du stockage et/ou des disques virtuels Point de défaillance unique (SPoF)

19 Planification d’un projet de rationalisation
Définir les objectifs du projet Gains attendus en terme de stockage, d’espace, de réduction de serveurs, d’’économie d’énergie, etc. Ratio de consolidation souhaité ROI Réaliser une Cartographie de l’existant Serveurs & VM Instances SQL Server, Oracle, MySQL, Sybase.. Bases de données (volumes, workloads…) Mesurer les Données de Performance Batch requests / sec Consommation Mémoire / CPU / Disque Définir une stratégie de rationalisation adaptée Critères de choix entre une approche par Consolidation ou Virtualisation Catégorisation des serveurs / VM en fonctions des workloads observés Ratio maximum par catégorie Développer une stratégie de tests Ne pas allouer les ressources Mémoire / CPU au-delà des capacité du serveur hôte Démarrer avec un ratio de consolidation « raisonnable » (ne pas chercher à maximiser le ratio d’emblée) Identifier les ratios offrant le meilleur rapport performance / Engager le processus de rationalisation Migration des bases d’anciennes versions de SQL Server vers SQL Server 2008 R2 après analyse d’impact (SQL Server 2008 R2 Upgrade Advisor) Migration de bases Oracle, Sybase, MySQL & Access vers SQL Server 2008 R2 (SSMA = SQL Server Migration Assistant) Virtualisation de serveurs existants (opérations de conversion P2V à l’aide de SCVMM 2008 R2) Conversion de Machines Virtuelles Vmware sous Hyper-V (opération de type V2V à l’aide de SCVMM 2008 R2)

20 Virtualisation : P2V & V2V à l’aide de System Center Virtual Machine Manager 2008 R2
SCVMM permet de convertir automatiquement des ordinateurs physiques en machines virtuelles sans interruption de service du serveur source (via VSC) La conversion des VM Vmware ESX nécessite leur arrêt préalable Processus également pilotable par script (PowerShell) pour des migration à grande échelle

21 Virtualisation : P2V & V2V à l’aide de System Center Virtual Machine Manager 2008 R2
SCVMM peut tirer partie d’une infrastructure System Center Operation Manager (SCOM) et vous aider à identifier les serveurs candidats à la virtualisation en : Analysant les données de performances collectées par SCOM pour les serveurs identifiés Générant un rapport affichant : Les valeurs moyennes des compteurs de performance Processeur, Mémoire et Disque… Les caractéristiques techniques des serveurs (nombre et fréquence des CPU, quantité de mémoire…)

22 Virtualisation : P2V & V2V Hiérarchisation des candidats à la virtualisation
Ordre de conversion recommandé: Serveurs sous-utilisés non critiques (commencer par les serveurs les moins utilisés et non critiques permet de se familiariser avec le processus P2V en prenant relativement peu de risques) Serveurs équipés de matériel périmé ou non pris en charge et qui doivent être remplacés Serveurs peu utilisés et hébergeant des applications internes moins critiques Serveurs plus utilisés et hébergeant des applications moins critiques Autres serveurs sous-utilisés NB: En règle générale, les serveurs hébergeant les bases de données d’applications critiques utilisées de façon intensive ne devraient être virtualisés que sur la plate-forme Hyper-V dans le système d'exploitation Windows Server 2008 (64 bits). Les plus fortement sollicités en terme d’E/S disque

23 Migration de bases avec SSMA De Oracle, Sybase, MySQL & Access vers SQL Server 2008 R2
Dans cet exemple, 98,65% des tables de la base Oracle sélectionnée ont été migrées avec succès 23 tables sur 247 n’ont pas pu être migrées à cause de problèmes de types sur les clés étrangères (erreur de conception), dont le détail est fourni dans la zone du bas, ce qui facilite leur identification et leur correction

24 Conception et implémentation
Recommandations générales (Consolidation) Le dimensionnement matériel est critique La bonne configuration du stockage est critique Utiliser les versions 64 bits de Windows et SQL Server (gains significatifs en termes de performances et de gestion des ressources matérielles) Eviter de sur-allouer les ressources Mémoire et CPU disponibles sur le serveur hôte aux instances Définir des seuils de mémoire Min et MAX pour chaque instance Stockage : Configurer le pilote MPIO (utiliser de préférence celui du constructeur) Optimiser la longueur de file d’attente des cartes HBA (HBA queue length) Ne pas mutualiser les E/S disques de nature concurrente (OLTP & DW/Reporting) Limitations Win2K8 R2 EE / SQL2K8 R2: Cluster jusqu’à 16 nœuds 50 instances par serveur (25 sur un cluster) 8 processeurs maximum au niveau du serveur hôte 2 To de mémoire pour le serveur hôte

25 Conception et implémentation
Recommandations générales (virtualisation) Le dimensionnement matériel est critique La bonne configuration du stockage est critique Utiliser les versions 64 bits de Windows et SQL Server (gains significatifs en termes de performances) Eviter de sur-allouer les ressources Mémoire et CPU disponibles sur le serveur hôte aux VM hébergées (memory overcommit) Stockage : Utiliser des disques de tailles fixe pour les VM, ou idéalement des disques en mode pass-thru (éviter les disques dynamiques) Eviter l’utilisation des disques dynamiques au niveau du système Configurer le pilote MPIO (utiliser de préférence celui du constructeur) Optimiser la longueur de file d’attente des cartes HBA (HBA queue length) Limitations Hyper-V sous Win2K8R2 EE: 4 processeurs virtuels (vcpu) par VM Hyper-V (guests) 64 cœurs maximum au niveau du serveur hôte 1 To de mémoire pour le serveur hôte

26 Exemple d’architecture SQL Server consolidée (par instance)
Principes: Il est possible d’ajouter simplement des nœuds supplémentaire dans un cluster, et de mixer différents types d’activités (OLTP, chargement batchs, reporting, etc.) pour faire évoluer sa capacité de traitement ou son niveau de disponibilité; Dans l’exemple illustré ci-contre : Les instances SQL1, SQL2 & SQL3 hébergent diverses bases OLTP alimentées en mode transactionnel ; L’instance SQL4 héberge une base OLTP très sollicitée et se voit donc dédier un noeud ; Les instance SQL5 & SQL6 hébergent chacune leur propre copie d’une base de reporting almentée en // par ETL, interrogée depuis un WS qui assure le Load Balacing des requêtes entre les deux instances ; Le nœud passif du cluster permet de conserver le même niveau de performance qu’en mode nominal lorsqu’une instance SQL Server bascule Il est possible d’introduire d’autres nœuds passifs afin d’augmenter le niveau de disponibilité tout en conservant le même niveau de performances

27 Exemple d’architecture SQL Server consolidée (par VM)
Principes: Les couches logicielles HA et DRS de VMware ESX permettent de basculer (redémarrer) les VM portées par un nœud défaillant sur un (ou plusieurs) autre(s) nœud(s) du cluster en fonction de leur charge respectives. VMware Vmotion permet quant à lui de migrer de manière planifiée (à chaud et sans interruption de service) une VM vers un autre nœud du cluster, afin d’assurer une répartition statique de la charge des VM ou à des fin de maintenance du serveur hôte. NB: Le même type d’architecture peut être mis en œuvre avec Microsoft Hyper-V sur un cluster Windows Server 2008 R2. Live Migration permet de déplacer à chaud (de manière non plannifée) une VM d’un nœud à l’autre du cluster sans interruption de service.

28 Agenda Perspectives et enjeux Démarche et outils
Scenarii de consolidation et de virtualisation Outils et techniques pour garantir les SLA Etude de cas Ressources Questions

29 Comment garantir les SLA
Comment garantir les SLA ? Solutions de Haute Disponibilité dans SQL Server Failover Clustering (Granularité = instance SQL) Jusqu’à 16 nœuds dans un cluster Jusqu’à 25 instances SQL Server par cluster Win2K8 R2 Répartition statique de la charge en affectant 1 ou plusieurs instances à un nœud par défaut Possibilité de conserver un ou plusieurs nœuds en mode Passif au sein du cluster afin de conserver le même niveau de performance en cas de bascule d’un nœud actif Possibilité de définir une stratégie de bascule tenant compte des éventuelles incompatibilités de workloads entre 2 instances Clusters géographiques pour la résilience inter-sites (s’appuie sur les mécanismes de réplication synchrone des baies proposées par les constructeurs: EMC SRDF/CE ou MV/CE, Hitachi TrueCopy, …) Interruption de service de qq sec. à qq dizaines de sec en cas de bascule non planifiée Compatible Hyper-V pour le support de Live Migration (pas d’interruption de service perçue par les applications ou les utilisateurs) Session de réplication asynchrone ou synchrone entre une base de Production et une base miroir, rejouant toute transaction appliquée sur la base source sur la base cible Possibilité de faire basculer automatiquement les applications clientes vers la base miroir en cas d’indisponibilité de la base principale (nécessite une 3ème instance SQL Server faisant office de témoin) Ne nécessite pas d’infrastructure particulière Temps de bascule < 10s Database Mirroring (granularité = base de donnée)

30 Comment garantir les SLA
Comment garantir les SLA ? Contrôler l’utilisation des Ressources matérielles Conception de l’architecture Stockage mutualisé vs. Dédié Pas de réponse évidente : Très dépendant du mode de virtualisation du stockage de l’architecture SAN et de ses capacités intrinsèques en terme de débit et/ou d’E/S Il est important de calibrer le SAN afin de connaître ses performances En règle générale, placer les bases OLTP et DW / Reporting sur des volumes distincts (la nature des E/S disques générées étant très différentes) Mutualisation micro technique des CPU Consolidation: OK tant que le niveau d’activité CPU du serveur hôte reste inférieur à 85%, et que le Context Switching n’est pas trop important (au-delà, affecter des cœurs dédiés à chaque instance SQL Server) Virtualisation: Généralement, il est préférable de dédier des cœurs à chaque VM hébergeant une instance SQL Server Réseau Envisager l’utilisation de plusieurs cartes réseau en teaming afin de supprimer le SPoF matériel et augmenter le débit Utiliser des multi VLAN pour isoler les flux de différentes instances ou VM si nécessaire

31 Comment garantir les SLA
Comment garantir les SLA ? Contrôler l’utilisation des Ressources matérielles Outils et fonctionnalités Windows System Resource Manager (WSRM)  Outil de Windows Server 2008 R2 Entreprise permettant de spécifier des limites sur l'utilisation de la quantité d'UC et de mémoire par processus Resource Governor  Fonctionnalité de SQL Server 2008 R2 Entreprise permettant de spécifier des limites sur l'utilisation de la quantité d'UC et de mémoire par les demandes d'application entrantes SoftNUMA  Configuration SQL Server spécifique permettant de scinder logiquement les ressources CPU du serveur hôte en plusieurs groupes (chacun affecté à virtuelle), et d’affecter les ressources CPU d’un groupe donné pour l’activité des applications en fonction de utilisée pour la connexion Data Collector  Fonctionnalité SQL Server permettant de collecter automatiquement les performances d’instances SQL Server, et de les restituer dans des rapports d’analyse (assistance à la consolidation / virtualisation et suivi des performances) Utilitaire de Point de contrôle (Utility Control Point)  Utilitaire SQL Server s’appuyant sur le Data Collector, permettant de collecter le taux d’utilisation des ressources matérielles (CPU, RAM, Disque…) des serveurs hébergeant les instances SQL Server, et afficher les résultats sous forme de rapports de tendance (utilie pour construire un Capacity Planning)

32 Hyper-V Live Migration
Machine Virtuelle Machine Virtuelle SYNCHRO MEMOIRE CONTENU MEMOIRE CONFIGURATION DONNEES Cluster (Noeud 1) Cluster (Noeud 2) Utilisateur VHD Stockage réseau

33 Comment garantir les SLA
Comment garantir les SLA ? Contrôler l’utilisation des Ressources matérielles WSRM (Windows System Resource Management) permet de définir des règles d’allocation des ressources matérielles (mémoire et CPU) applicables au niveau des processus Windows Les règles définies permettent de garantir que les processus concernés disposeront toujours de la quantité minimum des ressources spécifiées en cas de saturation Disponible dans les version Entreprise et Développeur de Windows Server 2008 (R2) Intègre une fonction d’Accounting permettant de refacturer l’utilisation des ressources à l’usage (mode ASP)

34 Comment garantir les SLA ? Resource Governor (1/3)
Executive Reports Backup OLTP Activity Possibilité de différencier les charges de travail Ex: app_name, login Limitation par requête Max memory % Max CPU time Grant timeout Max Requests Moniteur de ressources Admin Tasks Ad-hoc Reports Admin Workload OLTP Workload Report Workload Memory, CPU, Threads, … Resources

35 Comment garantir les SLA ? Resource Governor (2/3)
Executive Reports Backup OLTP Activity Admin Tasks Ad-hoc Reports Un workload peut avoir un niveau d’importance Faible Moyen Elevé Le moteur de base de données va fournir du temps de ressources basé sur le niveau d’important configuré High Admin Workload OLTP Workload Report Workload Memory, CPU, Threads, … Resources

36 Comment garantir les SLA ? Resource Governor (3/3)
Plusieurs Workload peuvent être affectés à un même pool de ressources (n:1) Prise en compte à chaud des modifications faites sur les Workloads/Pools Important: Resource Governor n’est activé que si l’une des ressources matérielle est saturée Executive Reports Backup OLTP Activity Admin Tasks Ad-hoc Reports High Admin Workload OLTP Workload Report Workload Min Memory 10% Max Memory 20% Max CPU 20% Max CPU 90% Admin Pool Application Pool

37 Agenda Perspectives et enjeux Démarche et outils
Scenarii de consolidation et de virtualisation Outils et techniques pour garantir les SLA Etude de cas Questions

38 Etude de cas Consolidation SQL Server chez MS IT
Avant Consolidation ~2,700 Applications dans le Portfolio MSIT ~4797 Instances SQL Server ~100,000 bases de données ~20% des matériels en fin de vie par an ~10% d’utilisation CPU en moyenne sur l’ensemble des serveurs hôtes Approche de Consolidation Microsoft IT a évalué l’ensemble des scenarii de consolidation : base de données, instances and serveur Gestion des Ressources Définition de plans de contingence afin de pallier les différents problèmes critiques pouvant potentiellement survenir Infrastructure Microsoft

39 Etude de cas Consolidation SQL Server chez MS IT
Stratégie de Consolidation Consolidation des serveur en utilisant Hyper-V Ratio cible de consolidation de 6 pour 1 Utilisation des Disque Virtuels Fixes (VHDs) plutôt que Dynamiques ou Pass-Thru Approche de Consolidation La décision initiale était de partir sur la consolidation d’instances Après une phase d’évaluation, le choix s’est porté sur la consolidation de serveurs sous Hyper-V Simplicité de mise en œuvre et de déploiement Conclusions relative au projet de consolidation par MSIT

40 Etude de cas Consolidation SQL Server chez MS IT
Résultats opérationels

41 Agenda Perspectives et enjeux Démarche et outils
Scenarii de consolidation et de virtualisation Outils et techniques pour garantir les SLA Etude de cas Ressources Questions

42 Liens et ressources (1/2)
Articles & White Papers Running SQL Server 2008 in a Hyper-V Environment – Best Practices and Performance Recommendations SQL Server Performance in a VMWare 3 environment P2V : conversion d’ordinateurs physiques en ordinateurs virtuels dans VMM V2V : conversion d’ordinateurs virtuels dans VMM

43 Liens et Ressources (2/2)
Outils Microsoft Assessment Planning ToolKit 5.5 (MAPS) Microsoft Consolidation Planning Tool for SQL Server (CPT) Microsoft SQL Server 2008 R2 Upgrade Advisor (SSUA) Microsoft SQL Server Migration Assistant(s) (SSMA)

44 Agenda Perspectives et enjeux Démarche et outils
Scenarii de consolidation et de virtualisation Outils et techniques pour garantir les SLA Etude de cas Ressources Questions

45 Questions / Réponses

46