11 DBA DAY - Consolidation et virtualisation des bases de données Code Session : DBM303 8 février 2010 Nadia Ben El Kadi, Architecte Microsoft

Présentation au sujet: "11 DBA DAY - Consolidation et virtualisation des bases de données Code Session : DBM303 8 février 2010 Nadia Ben El Kadi, Architecte Microsoft"— Transcription de la présentation:

1 11 DBA DAY - Consolidation et virtualisation des bases de données Code Session : DBM303 8 février 2010 Nadia Ben El Kadi, Architecte Microsoft nadiab @microsoft.com Bertrand Audras, baudras@microsoft.com Olivier Tolon, Architecte Microsoft otolon@microsoft.com

2 22 Les drivers de la consolidation Optimisation des ressources et des coûts Acheter moins de serveurs (réutilisation) Économiser l’énergie face à la saturation des onduleurs Standardisation de l’administration Supervision, sauvegarde, haute disponibilité pour tous Rationalisation des outils utilisés Flexibilité de gestion applicatives Montée en charge Saisonalité Réduction des coûts (hardware, licenses)

3 33 Consolider avec SQL Server Critères de sélection Étanchéité Mutualisation des ressources Optimisation de l’administration

4 44 Agenda  Introduction Comment identifier les candidats à la consolidation Préparer sa consolidation Outils et méthodes de collecte Méthodes d’analyse Les solutions pour consolider SQL Server Multi-databases Multi-instances Virtualisation, démo du Live Migration Outillage de la migration : SQL Server 2008R2 AMM Retours d’expérience du MTC sur la virtualisation Quel impact sur les licences Synthèse

5 55 Préparer sa consolidation L’aspect technique de la consolidation est la préparation/planification La 1ère chose à faire est de collecter les informations sur l’éxistant car sans cela, il sera difficile de faire un choix d’architecture du nouvel environnement Informations de configuration Informations de performance sur le serveur, l’instance et les Bases de données Le but n’est pas de collecter une multitude d’information ni de collecter tous les compteurs de performance mais juste un minimum d’éléments

6 66 Que collecter ? Informations windows et celles du serveur physique Informations SQL Server Informations sur les application Informations de performance

7 77 Informations windows et serveur physique AttributeComments Server name The server name will be referenced throughout planning and implementation. Operating system version, service pack level, and build number, 32- bit or 64-bit The version of the server will help quantify not only what versions of Windows are deployed, but also any specific considerations that may need to be taken into account during consolidation. Main purpose for the server It is important to note what the server is actually being used for. For example, is it a development, test, staging, or QA server, and what application is using it? If possible, list of all updates applied Similar to knowing the version of the Windows, there may have been specific updates applied to resolve a particular issue that will need to be applied after consolidation. Updates include, but are not limited to, hotfixes, service packs, and other critical updates (including security). Domain affiliation This will tell what domain(s) the server belongs to. Full networking/TCP/IP information Networking information is important for configuration. Memory configuration This is the total amount of memory in the server. Processor type and speed This documents the current processor to map to a target platform. Drive configuration Knowing how the disks are configured is important, because if nothing is known about the server, drive configuration provides a map of where to get started looking for databases and backups. It also helps during the implementation plan to know the locations of where things are located to ensure they are migrated to the new environment. List of all drivers on the system, including versions This will document what drivers are in use, and it may impact the configuration and supportability. Stand-alone or cluster node Tells whether the server is part of a Windows failover cluster or not. List of all software (including SQL Server) and utilities/administration tools (such as antivirus) installed This is an inventory of what is configured besides Windows on the server. Hardware vendor, physical server model number, serial number Documents the vendor-specific information.

8 88 Informations SQL Server AttributeComments Instance name This name will be a major reference point for the consolidation effort, whether the instance is being consolidated, or it is just the location of specific databases. If this is SQL Server 2000 or later, indicate whether it is the default instance or a named instance. SQL Server major version, service pack level, and build number This will help determine the best way to migrate, upgrade, or consolidate, because those tasks depend on the starting version. List of all instance-level configuration parameters and current values (sp_configure, mixed mode or Windows authentication, collation, and so on) Helps to determine incompatibilities for combining objects and databases from multiple instances. List of all databases and each one’s configuration parameters (recovery model, compatibility mode, file configuration and sizes, free space, collation, and so on) Gets all database-related information; similar to instance-level information. This information helps quantify what is in the environment and the best paths to consolidation. List of all instance-level logins and their rights and permissions; distinguish between SQL Server logins and Windows logins Supports analysis of the security of the instance. List of all database-level users, their rights and permissions, and what login they map to Supports analysis of the security of the databases. List of any and all DTS or SSIS packages and their purposes This will document and quantify Integration Services and DTS, and it will help the assessment of how much work will be needed to possibly convert them. List of all jobs and their details, including job history This will form the basis for any administration and maintenance that will be configured post-consolidation, if SQL Server Agent jobs are being used. List of all maintenance plans and their details This will form the basis for any administration and maintenance that will be configured post-consolidation. List of all special configurations (database mirroring, log shipping, replication, linked servers, and so on) To ensure that configurations are re-created (if necessary) post- consolidation, they must be documented. List of any third-party utilities, their versions, and support contact information This is an inventory of any SQL Server-related tools used for administration, such as backup compression utilities. Clustered or stand-alone; if clustered, name of the Windows cluster it is joined to as well as drive configuration and list of all nodes Information specific to a failover clustering instance.

9 99 Informations sur applications AttributeComments Application name Like an instance of SQL Server, this application name will be referenced throughout the consolidation effort. What the application does (summary) It always helps to know what the application is used for and, at a high level, how it works. In-house developed or purchased Was this application made by a third-party vendor or coded by developers? If the application was coded in-house, note the status of the code, who owns it, and where it is stored in the event it would need to be updated for SQL Server 2008. Performance and availability service-level agreements (SLAs) These will help in determining what can be mixed together, because mixed SLAs can be a bad thing in a consolidated environment depending on where databases and applications are consolidated. Version(s) of SQL Server the deployed application version supports For the currently deployed version (not one that is yet to be deployed or not purchased), what versions of SQL Server does it support? Type of workload (OLTP, DSS, and so on) for this application The application workload is important when planning consolidation, because it will determine what can and cannot be combined. It is also important to note the tempdb usage of the application. List of SQL Server databases the application uses along with the instance where each database is located Allows mapping of applications to SQL Server instances and databases. Any known special requirements for the application deployment (such as patch levels for Windows and/or SQL Server) Documents any specific application requirements that may be needed in the target environment. Any known restrictions that may affect the timing of the actual consolidation of the database(s) and/or instance(s) for that application For example, different departments may have short windows for doing the work. An accounting department may have month-end, quarterly, or year-end closing activities that prevent any work from being done during specific dates. This will impact the schedule. Current support status for the application Documents whether or not the server is currently supported by vendors (if third-party software). SQL Server features used by the application Lists any features such as replication that the application leverages.

10 10 Informations de performance Principaux Compteurs windows et SQL server Activité SQL Serveur

11 11 Outils/méthodes de collecte Pour la configuration Tables/Vues/procédures/systèmes SQLDIAG MPSReport Autres logiciels d’inventaire : le DBA pourra utiliser ces infos si elles existent MAP (MS Assessment & Planning Toolkit) Permet de collecter les serveurs de votre réseau. Utile pour détecter les serveurs inconnus. C’est le 1 ier outil souvent utilisé lors des souhaits de consolidation. Pour les performances DMV, Performances Dashbord inclus dans SSMS Performance Monitor Les outils de monitoring si vous en avez Collecte les infos de performance. Si ces données existent le DBA peut s’en servir afin d’éviter des collectes déjà existantes Si besoin, pensez au RML tools : readtrace ; reporter Pensez aussi à Codeplex : PAL, Nexus

12 12 Méthode d’analyze Les données statiques définieront quoi et comment les choses seront consolidées Ne pas mélanger OLTP et OLAP Mêmes versions OS et SQL Instances en HA Les données de performance auront elles une part importante lors du capacity planning. Ces données seront la base de ce qui peut être consolider ensemble d’un point de vue performance. Sizing des serveurs : Ram, CPU, IO Regroupement d’instances Regroupement de Bases Si vous disposez d’éléments d’historique de l’évolution des DB, servez vous en pour tailler vos serveurs en conséquence. Important : il sera bon d’envisager une phase de tunning des instances les plus consommatrices afin d’optimiser d’éventuelles requêtes si besoin. Veillez à éviter les conflits (même nom de DB) Profitez en pour vous assurer que les Best Practices sont suivies : 2 outils : BPA si SQL Serveur 2005 et antérieur PBM en 2008

13 13 Agenda  Introduction  Comment identifier les candidats à la consolidation  Préparer sa consolidation  Outils et méthodes de collecte  Méthodes d’analyse Les solutions pour consolider SQL Server Multi-databases Multi-instances Virtualisation, démo du Live Migration Outillage de la migration : SQL Server 2008R2 AMM Retours d’expérience du MTC sur la virtualisation Quel impact sur les licences Synthèse

14 14 Les choix possibles Cas 1) Plusieurs schémas dans une même base de données : pas très acceptable par les DBA car moins sécurisée, nécessite souvent de modifier l’application, peut impacter les perfs.Ce choix est à traiter avec prudence Cas 2) Plusieurs DBs au sein d’une même instance : on garde une isolation au niveau de la DB mais il subsiste un risque en terme de conflit de sécurité ou autre problème de collation. Cas 3) Plusieurs instances au sein d’un même serveur (ou cluster) : cette méthode permet d’optimiser les ressources d’un serveur physique en mutualisant plusieurs instances sur le même serveur (ou cluster). Cas 4) La virtualisation : est une méthode relativement récente de consolidation qui était plutôt utilisée pour des serveurs autres que ceux hébergeant des BDs. Cette méthode est celle qui offre l’isolation la plus importante car chaque serveur virtuel équivaudra à un serveur physique. Mais les serveurs virtuels seront hébergés par un Host donc les ressources sous jacentes seront quand même partagées par toutes les VMs. On pourra aussi dans ce scénario avoir plusieurs instances dans une même VM.

15 15 Cas 2 : Mutualisation au sein d’une même instance 1 instance héberge N bases applicatives Ressources Mémoire, Cpu seront communes TEMPDB commune Arrêt de l’instance  Arrêt de toutes les bases applicatives Attention : ne pas mélanger les instances gourmandes avec les petites instances Depuis SQL 2008 : le « resource governor » permet de gérer une affinité au niveau mémoire et cpu

16 16 Cas 3 : Consolidation physique - Instances multiples Prise en charge de plusieurs instances SQL Server sur une même machine En standalone : 50 instances En cluster : 25 instances Prévoir un serveur physique avec des ressources suffisantes Intérêt :  Différentes versions (build) de SQL, par exemple pour la compatibilité de certaines applications  Hébergement d’applications par instance  Collation différentes  Assignation de ressources par instance (mémoire/CPU)  Isolation de l’impact d‘une application sur une autre

17 17 Cas 4 : la virtualisation Machine « Host » qui héberge plusieurs VM « guest » Possibilité d’utiliser un cluster pour assurer la HA Chaque VM peut être vu comme une machine individuelle avec ses propres ressources Voir KB : « SQL Server support policy for virtualization » : http://support.microsoft.com/kb/956893/en-us SQL Server 2005 et 2008 Guest clustering avec Windows 2008 et 2008 R2 White paper « Best Practices & Performance considerations running SQL 2008 on HyperV » http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa- a026-5bfcf076d9b9/SQL2008inHyperV2008.docx Extraits : There are ways to optimize a VM, such as using pass-through disks to talk directly to a disk subsystem, but remember that the I/O is still being shared with the rest of the VMs through the hypervisor. The key to success with virtualization in production is testing. Do not put a deployment in jeopardy by just assuming virtualization will work. If the deployment does not succeed, you will have to pull it out of virtualization and onto physical hardware.

18 18 Démo Live Migration d’une VM SQL Server

19 19 Windows 2008 R2 Hyper-V Live Migration Step 1: Snapshot VM memory Copy partition memory from source VM to Destination Root Partition Hypervisor Hardware Physical Server Source Child Partition Partition Memory Network Connections Hypervisor Hardware Changed Pages Storage Connections Root Partition Physical Server Destination Child Partition Partition Memory Shared Storage LUN 2LUN 1 Network Connections

20 20 Windows 2008 R2 Hyper-V Live Migration Step 2: Copy changed pages from source VM to destination Root Partition Hypervisor Hardware Physical Server Source Child Partition Partition Memory Network Connections Hypervisor Hardware Changed Pages Storage Connections Root Partition Physical Server Destination Child Partition Partition Memory Shared Storage LUN 2LUN 1 Network Connections Changed Pages

21 21 Windows 2008 R2 Hyper-V Live Migration Step 3: Storage connections are migrated from the source VM to the destination VM Root Partition Hypervisor Hardware Physical Server Source Child Partition Partition Memory Network Connections Hypervisor Hardware Changed Pages Storage Connections Root Partition Physical Server Destination Child Partition Partition Memory Shared Storage LUN 1 Network Connections Changed Pages Storage Connections LUN 2

22 22 Windows 2008 R2 Hyper-V Live Migration Step 4: Network connections are migrated from source VM to destination VM Root Partition Hypervisor Hardware Physical Server Source Child Partition Partition Memory Network Connections Hypervisor Hardware Changed Pages Storage Connections Root Partition Physical Server Destination Child Partition Partition Memory Shared Storage LUN 1 Changed Pages Storage Connections Network Connections LUN 2

23 23 Windows 2008 R2 Hyper-V Live Migration Step 5: Destination VM is brought online Source VM is taken off line Source Child Partition Root Partition Hypervisor Hardware Physical Server Destination Child Partition Hypervisor Hardware Root Partition Physical Server Partition Memory Shared Storage LUN 1 Changed Pages Storage Connections Network Connections LUN 2

24 24 Comparatif FunctionalityMultiple instancesVirtual machines IsolationShared Windows installation Dedicated Windows installation (virtual machine acts like a physical server) Processor resources All processors available to Windows Possible hot-add Maximum allowed by the hypervisor May need to power down the VM to change processor configuration (hypervisor-dependent) Memory All memory available to Windows Standard management in SQL Server Possible hot-add Limited both by maximum seen by the hypervisor as well as limitations for maximum memory that can be configured on a VM Statically allocated to a VM May need to power down the VM to change memory configuration (hypervisor-dependent) StorageConnected to physical disks Pass-through/direct access from a VM to physical disks Virtual disks Resource management Process level SQL Server Resource Governor Hypervisor tools for VM SQL Server Resource Governor (for SQL Server in the VM) Number of instances/virtual machines25 (cluster), 50 (stand-alone)Determined by available resources SupportNormal support rules Hypervisor must be Hyper-V or part of the SVVP Only supports SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 High availabilityNormal availability techniquesHost-level: Failover clustering (Windows), Live Migration, other vendor specific (such as V-motion for VMware) VM-level: failover clustering Database Level: database mirroring, log shipping

25 25 Quelle édition choisir pour la consolidation ? Edition Entreprise vous permettra de faire Compression Resource Governor 50 instances Pas de limite de CPU (OS maximum) Online reindex Hot-add cpu et Hot –add memory Parallel index operations Voir BOL pour plud de détails

26 26 Consolidation & Performance Best Practices Préférer une architecture 64 bits Coté CPU : se baser sur les collectes réalisées. Prendre le temps de tester pour trouver le bon nombre de CPU/Core Mémoire : les DBA doivent travailler avec les administrateurs systèmes pour évaluer la mémoire à laisser à l’OS (process, antivirus, outil monitoring, backup utility etc…) Bien positionner le « max server memory » surtout en Multi- instance et en environnement cluster. Disques : 2 aspects: espace nécessaire et besoin en I/O Coté stockage : prévoir espace nécessaire pour les Data, les logs; les backup et les déploiements/évolutions futures Performance disk : utiliser les informations collectées pour analyser les IO et optimiser la répartition disque : plusieurs axes, séparer Data et Log TEMPDB : http://technet.microsoft.com/en-us/library/cc966545.aspx Bien tailler les enveloppes des bases de données et autogrow

27 27 Agenda  Introduction  Comment identifier les candidats à la consolidation  Préparer sa consolidation  Outils et méthodes de collecte  Méthodes d’analyse  Les solutions pour consolider SQL Server  Multi-databases  Multi-instances  Virtualisation, démo du Live Migration Outillage de la migration : SQL Server 2008R2 AMM Retours d’expérience du MTC sur la virtualisation Quel impact sur les licences Synthèse

28 28 AMM : Application & MultiServers Management Fonctionnalité Management Multiserveurs Gérer de manière proactive et efficace les environnements de base de données grâce à une visibilité centralisée sur l’utilisation des ressources Simplifier la consolidation Permet aux DBA de gagner en visibilité et en contrôle sur leur environnement de base de données grâce aux extensions de SSMS d’identifier rapidement des opportunités de consolidation et de réduction des coûts grâce aux dashboard viewpoints, à l’utilisation de tendances (par l’intermédiaire de politiques ajustables), etc. D’éliminer les serveurs sous-exploités

29 29 AMM - Démo Utility Control Point: sorte de remplaçant du central management server qu’on avait en 2008 C’est une instance qui centralise les infos de plusieurs instances SQL Server. Ce n’est pas du real time dashboard monitoring car la collecte se fait 1 fois toute les 15 minutes C’est une extension du management datawarehouse de SQL server 2008 Donne une image de l’activité des systèmes

30 30 Démo Application & Multi-server Management

31 31 Agenda  Introduction  Comment identifier les candidats à la consolidation  Préparer sa consolidation  Outils et méthodes de collecte  Méthodes d’analyse  Les solutions pour consolider SQL Server  Multi-databases  Multi-instances  Virtualisation, démo du Live Migration  Outillage de la migration : SQL Server 2008R2 AMM Retours d’expérience du MTC sur la virtualisation Quel impact sur les licences Synthèse

32 32 Ressources utilisées par SQL Server Forte activité disques en lecture et écriture Workload (OLTP, DW, BI, repository, web…) Volumétrie des données La ressource la plus importante pour la performance de SQL Server Mémoire (à partir de 2GB, généralement OS en 64bit) Utilisation CPU variable Activité utilisateur OLTP, reporting Batchs quotidien Import par batch Utilisation de procédures stockées et de fonctions Compression des données (SQL2008+) Traffic réseau Chargements Reporting et extractions Nombre d’utilisateurs concurrents

33 33 SQL – cas d’usage de la virtualisation Consolidation d’instances faiblement utilisées Repository, warm-up db, test & développement Faible nombre d’utilisateurs Faible fréquence d’utilisation Infrastructure BI Datamart, OLAP, Reporting Services, Data Staging Area Solution de haute disponibilité et de flexibilité Utilisation du Live Migration pour la maintenance Dynamic provisionning, architecture web Consolidation de base stand by (Database Mirroring) Infrastructure Sharepoint rationnalisée Moins de 100 utilisateurs et moins de 100GB de données

34 34 Ne pas virtualiser SQL si on doit… Utiliser plus de 4 cores et 8GB de RAM Limites de hyper-V à 4 vCPU Au delà de 8GB, le ROI diminue (lié au cout de la RAM) Servir plus de 50 utilisateurs simultanés Contention sur les accès disque et la bande passante réseau Obtenir les meilleurs performances Overhead constaté de 15% sur les temps de réponse Garantir la stabilité des performances Partage des ressources CPU, réseau et accès disques Et surtout si on ne connait pas bien l’activité de l’instance SQL Mettre en place un monitoring, SCOM ou Multi-Server Mgt

35 35 Best practices Stockage Disques VHD de taille fixe Mapping VHD-LUN, attention au LOG et à TEMPDB Disques en mode pass-through A tester avec SQLIO! Limiter la surallocation CPU En mode nominal, bien répartir les VM sur les serveurs Utiliser les private Virtual Network Entre un serveur IIS et SQL, SSIS et un DW, amélioration des performances en mode virtuel Adapter la stratégie de sauvegarde et de haute disponibilité Utilisation de VSS Remplacement d’un cluster par du Live Migration Utiliser le Database Mirroring asynchrone

36 36 Références clients Indiana University Réduction de 150 à 32 serveurs Réduction du temps de déploiement (facteur 10) Amélioration des performances et de la qualité de service Microsoft IT 100.000 bases de données, 5.000 instances SQL Server Moyenne CPU < 10% Ratio final de 6:1 Index Multimédia Virtualisation des développements et de la pré-production Jusqu’à 4 instances SQL Server par VM (4 vCPU-8GB-64bit) LASCOM (ISV) Mode hébergement, garantie d’étanchéité entre les clients

37 37 Agenda  Introduction  Comment identifier les candidats à la consolidation  Préparer sa consolidation  Outils et méthodes de collecte  Méthodes d’analyse  Les solutions pour consolider SQL Server  Multi-databases  Multi-instances  Virtualisation, démo du Live Migration  Outillage de la migration : SQL Server 2008R2 AMM  Retours d’expérience du MTC sur la virtualisation Quel impact sur les licences Synthèse

38 38 Licences pour SQL Server en VM Attention: la visrtualisation des instances SQL impose de contrôler les droits de licences Windows (OEM ou software assurance) et SQL Server (boite ou sa) SQL Server 2008 R2 apporte un nouveau mode de pricing qui sera annoncé lors de la sortie officielle (H1-2010) Le pricing restera au processeur physique Nouvelle édition “datacenter” dédiée à la virtualisation

39 39 Licences pour SQL Server en VM Pour SQL Server Standard : En mode server/CAL : il faut une licence SQL Standard par machine virtuelle qui exécute SQL Server, En mode par processeur : il faut une licence SQL Standard par processeur virtuel qui exécute SQL Server Pour SQL Server Enterprise : En mode server/CAL : une licence SQL Server Enterprise couvre l’ensemble des machines virtuelles sur un même serveur physique de façon illimitée, En mode par processeur : en achetant une licence SQL Server Enterprise par processeur physique du serveur, l’ensemble des machines virtuelles sont couvertes de façon illimitée sur un même serveur physique

40 40 SQL Server 2008: cas pratique Exemple de scénario de virtualisation : Une machine physique avec 4 processeurs de 4 cœurs, Elle contient 30 serveurs virtuels sous Windows Server exécutant SQL Server 2008. Licences Windows nécessaires : 30 Windows Standard ou 8 Windows Enterprise ou 4 Windows Datacenter, La solution la plus économique : 4 Datacenter. Licences SQL nécessaires : Standard : 1 licence SQL Server Standard 2008 par processeur virtuel : 30 licences si les 30 machines virtuelles exécutant SQL Server 2008 sont mono-processeur, 60 licences si les 30 machines virtuelles sont bi-processeurs, Enterprise : 4 licences SQL Server Entreprise 2008 par Processeur (1 par processeur physique) qui couvrent un nombre illimité de machines virtuelles.

41 41 Agenda  Introduction  Comment identifier les candidats à la consolidation  Préparer sa consolidation  Outils et méthodes de collecte  Méthodes d’analyse  Les solutions pour consolider SQL Server  Multi-databases  Multi-instances  Virtualisation, démo du Live Migration  Outillage de la migration : SQL Server 2008R2 AMM  Retours d’expérience du MTC sur la virtualisation  Quel impact sur les licences Synthèse

42 42 Synthèse Il n’y a pas de solution universelle Le pré-requis, c’est de bien connaitre les ressources consommées Superviser pour éventuellement revenir en arrière Best practice CPU: gestion fine des processeurs Avec Hyper-V CPU management tool au niveau d’une VM Avec WSRM en mode multi-instance Avec Resource Governor au sein d’une instance Best practice RAM: ne pas sous-dimensionner la mémoire Contentions entre SQL et SSAS/SSIS au sein d’un même Windows Best practice SAN: la garantie des performances Règles habituelles: LUN dédiées, capacité HBA suffisante… Tester avec SQLIO ! La virtualisation avec Hyper-V ouvre de nouveaux horizons !

43 43 Pour aller plus loin – SQL Server Executer SQL 2008 en environnement Hyper-V http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026- 5bfcf076d9b9/SQL2008inHyperV2008.docx Consolidation SQL Server: un case study Microsoft IT http://download.microsoft.com/download/4/8/0/48030820-12A4-4FE9-B001- C2CF56BC42A5/AJ18_EN.zip http://msdn.microsoft.com/en-us/architecture/dd393309.aspx Politique de support de SQL Server en environnement virtualisé http://support.microsoft.com/?id=956893 http://blogs.msdn.com/psssql/archive/2008/10/08/sql-server-support-in-a-hardware- virtualization-environment.aspx Blog de Bertrand Audras: SQL Server, Hyper-V, Green IT http://blogs.technet.com/baudras/

44