td2010 dbm303 v1
TRANSCRIPT
11
DBA DAY - Consolidation et virtualisation des bases de donnéesCode Session : DBM3038 février 2010
Nadia Ben El Kadi, Architecte Microsoft nadiab @microsoft.comBertrand Audras, [email protected] Tolon, Architecte Microsoft [email protected]
22
Les drivers de la consolidation
Optimisation des ressources et des coûtsAcheter moins de serveurs (réutilisation)Économiser l’énergie face à la saturation des onduleurs
Standardisation de l’administrationSupervision, sauvegarde, haute disponibilité pour tousRationalisation des outils utilisés
Flexibilité de gestion applicativesMontée en chargeSaisonalitéRéduction des coûts
(hardware, licenses)
Power Sav-ings18%
Higher util and lower h/w costs
25%
Rack Space Savings18%
Ease of Manage-
ment21%
Reduced Li-censing Costs
18%
33
Consolider avec SQL Server
Critères de sélectionÉtanchéitéMutualisation des ressourcesOptimisation de l’administration
44
Agenda
IntroductionComment identifier les candidats à la consolidation
Préparer sa consolidationOutils et méthodes de collecteMéthodes d’analyse
Les solutions pour consolider SQL ServerMulti-databasesMulti-instancesVirtualisation, démo du Live MigrationOutillage de la migration : SQL Server 2008R2 AMM
Retours d’expérience du MTC sur la virtualisationQuel impact sur les licencesSynthèse
55
Préparer sa consolidation
L’aspect technique de la consolidation est la préparation/planificationLa 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 configurationInformations de performance sur le serveur, l’instance et
les Bases de donnéesLe 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
66
Que collecter ?
Informations windows et celles du serveur physiqueInformations SQL ServerInformations sur les applicationInformations de performance
77
Informations windows et serveur physiqueAttribute Comments
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.
88
Informations SQL ServerAttribute Comments
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.
99
Informations sur applications
Attribute Comments
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.
1010
Informations de performance
Principaux Compteurs windows et SQL serverActivité SQL Serveur
1111
Outils/méthodes de collecte
Pour la configurationTables/Vues/procédures/systèmesSQLDIAGMPSReportAutres 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 performancesDMV , Performances Dashbord inclus dans SSMSPerformance MonitorLes 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
1212
Méthode d’analyze Les données statiques définieront quoi et comment les choses seront consolidées
Ne pas mélanger OLTP et OLAPMêmes versions OS et SQLInstances 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, IORegroupement d’instancesRegroupement 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érieurPBM en 2008
1313
Agenda
Introduction Comment identifier les candidats à la consolidation
Préparer sa consolidation Outils et méthodes de collecte Méthodes d’analyseLes solutions pour consolider SQL Server
Multi-databasesMulti-instancesVirtualisation, démo du Live MigrationOutillage de la migration : SQL Server 2008R2 AMM
Retours d’expérience du MTC sur la virtualisationQuel impact sur les licencesSynthèse
1414
Les choix possiblesCas 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.
1515
Cas 2 : Mutualisation au sein d’une même instance
1 instance héberge N bases applicativesRessources Mémoire, Cpu seront communesTEMPDB commune Arrêt de l’instance Arrêt de toutes les bases applicativesAttention : ne pas mélanger les instances gourmandes avec les
petites instancesDepuis SQL 2008 : le « resource governor » permet de gérer
une affinité au niveau mémoire et cpu
1616
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
1717
Cas 4 : la virtualisation
Machine « Host » qui héberge plusieurs VM « guest »Possibilité d’utiliser un cluster pour assurer la HAChaque VM peut être vu comme une machine individuelle avec ses propres ressourcesVoir KB : « SQL Server support policy for virtualization » : http://support.microsoft.com/kb/956893/en-us
SQL Server 2005 et 2008Guest 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.docxExtraits :
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.
1818
DémoLive Migration d’une VM SQL Server
1919
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 ServerDestination Child Partition
Partition Memory
Shared StorageLUN 2LUN 1
Network Connections
2020
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 ServerDestination Child Partition
Partition Memory
Shared StorageLUN 2LUN 1
Network Connections
Changed Pages
2121
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 ServerDestination Child Partition
Partition Memory
Shared StorageLUN 1
Network Connections
Changed Pages
Storage Connections
LUN 2
2222
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 ServerDestination Child Partition
Partition Memory
Shared StorageLUN 1
Changed Pages
Storage Connections
Network Connections
Network ConnectionsLUN 2
2323
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 StorageLUN 1
Changed Pages
Storage Connections
Network Connections
Network ConnectionsLUN 2
2424
ComparatifFunctionality Multiple instances Virtual machinesIsolation Shared Windows installation Dedicated Windows installation (virtual machine acts like a
physical server)Processor resources All processors available to Windows
Possible hot-addMaximum allowed by the hypervisorMay need to power down the VM to change processor configuration (hypervisor-dependent)
Memory All memory available to WindowsStandard management in SQL ServerPossible hot-add
Limited both by maximum seen by the hypervisor as well as limitations for maximum memory that can be configured on a VMStatically allocated to a VMMay need to power down the VM to change memory configuration (hypervisor-dependent)
Storage Connected to physical disks Pass-through/direct access from a VM to physical disksVirtual disks
Resource management Process levelSQL Server Resource Governor
Hypervisor tools for VMSQL Server Resource Governor (for SQL Server in the VM)
Number of instances/virtual machines 25 (cluster), 50 (stand-alone) Determined by available resources
Support Normal support rules Hypervisor must be Hyper-V or part of the SVVPOnly supports SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2
High availability Normal availability techniques Host-level: Failover clustering (Windows), Live Migration, other vendor specific (such as V-motion for VMware)VM-level: failover clusteringDatabase Level: database mirroring, log shipping
2525
Quelle édition choisir pour la consolidation ?
Edition Entreprise vous permettra de faireCompressionResource Governor50 instancesPas de limite de CPU (OS maximum) Online reindexHot-add cpu et Hot –add memoryParallel index operationsVoir BOL pour plud de détails
2626
Consolidation & PerformanceBest Practices
Préférer une architecture 64 bitsCoté CPU : se baser sur les collectes réalisées. Prendre le temps de tester pour trouver le bon nombre de CPU/CoreMé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 futuresPerformance 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
2727
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 virtualisationQuel impact sur les licencesSynthèse
2828
AMM : Application & MultiServers Management
Fonctionnalité Management MultiserveursGé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 consolidationPermet aux DBA
de gagner en visibilité et en contrôle sur leur environnement de base de données grâce aux extensions de SSMSd’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
2929
AMM - Démo
Utility Control Point: sorte de remplaçant du central management server qu’on avait en 2008C’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 2008Donne une image de l’activité des systèmes
3030
DémoApplication & Multi-server Management
3131
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 AMMRetours d’expérience du MTC sur la virtualisationQuel impact sur les licencesSynthèse
3232
Ressources utilisées par SQL Server
Forte activité disques en lecture et écritureWorkload (OLTP, DW, BI, repository, web…)Volumétrie des donnéesLa 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, reportingBatchs quotidienImport par batchUtilisation de procédures stockées et de fonctionsCompression des données (SQL2008+)
Traffic réseauChargementsReporting et extractionsNombre d’utilisateurs concurrents
3333
SQL – cas d’usage de la virtualisation
Consolidation d’instances faiblement utiliséesRepository, warm-up db, test & développementFaible nombre d’utilisateursFaible fréquence d’utilisation
Infrastructure BIDatamart, OLAP, Reporting Services, Data Staging Area
Solution de haute disponibilité et de flexibilitéUtilisation du Live Migration pour la maintenanceDynamic provisionning, architecture webConsolidation de base stand by (Database Mirroring)
Infrastructure Sharepoint rationnaliséeMoins de 100 utilisateurs et moins de 100GB de données
3434
Ne pas virtualiser SQL si on doit…
Utiliser plus de 4 cores et 8GB de RAMLimites de hyper-V à 4 vCPUAu delà de 8GB, le ROI diminue (lié au cout de la RAM)
Servir plus de 50 utilisateurs simultanésContention sur les accès disque et la bande passante réseau
Obtenir les meilleurs performancesOverhead constaté de 15% sur les temps de réponse
Garantir la stabilité des performancesPartage des ressources CPU, réseau et accès disques
Et surtout si on ne connait pas bien l’activité de l’instance SQLMettre en place un monitoring, SCOM ou Multi-Server Mgt
3535
Best practices
StockageDisques VHD de taille fixeMapping VHD-LUN, attention au LOG et à TEMPDBDisques en mode pass-throughA tester avec SQLIO!
Limiter la surallocation CPUEn mode nominal, bien répartir les VM sur les serveurs
Utiliser les private Virtual NetworkEntre un serveur IIS et SQL, SSIS et un DW, amélioration des
performances en mode virtuelAdapter la stratégie de sauvegarde et de haute disponibilité
Utilisation de VSSRemplacement d’un cluster par du Live MigrationUtiliser le Database Mirroring asynchrone
3636
Références clients
Indiana UniversityRéduction de 150 à 32 serveursRéduction du temps de déploiement (facteur 10)Amélioration des performances et de la qualité de service
Microsoft IT100.000 bases de données, 5.000 instances SQL ServerMoyenne CPU < 10%Ratio final de 6:1
Index MultimédiaVirtualisation des développements et de la pré-productionJusqu’à 4 instances SQL Server par VM (4 vCPU-8GB-64bit)
LASCOM (ISV)Mode hébergement, garantie d’étanchéité entre les clients
3737
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 virtualisationQuel impact sur les licencesSynthèse
3838
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
4141
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
4242
Synthèse
Il n’y a pas de solution universelleLe pré-requis, c’est de bien connaitre les ressources consomméesSuperviser pour éventuellement revenir en arrière
Best practice CPU: gestion fine des processeursAvec Hyper-V CPU management tool au niveau d’une VMAvec WSRM en mode multi-instanceAvec 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 performancesRègles habituelles: LUN dédiées, capacité HBA suffisante…Tester avec SQLIO !
La virtualisation avec Hyper-V ouvre de nouveaux horizons !
4343
Pour aller plus loin – SQL Server
Executer SQL 2008 en environnement Hyper-Vhttp://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docx
Consolidation SQL Server: un case study Microsoft IThttp://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 IThttp://blogs.technet.com/baudras/