Meilleures pratiques en matière d'optimisation et de performance du FIM

Pour commencer, suivez les meilleures pratiques de votre plateforme de virtualisation. Les meilleures pratiques permettent généralement d'améliorer les performances et la stabilité. Les liens suivants vous guideront vers des recommandations de bonnes pratiques :

• Performance Best Practices for VMware vSphere™ 5.5 (Meilleures pratiques de performance pour VMware vSphere 5.5)
• Performance Best Practices for VMware vSphere™ 5.0 (Meilleures pratiques de performance pour VMware vSphere™ 5.0)
• Windows Server 2012 Hyper-V Best Practices (sous forme de liste de contrôle facile) (Windows Server 2012 Hyper-V Best Practices)

• Les services d'intégration doivent être installés sur chaque machine virtuelle invitée
• Les services d'intégration doivent être de la bonne version pour l'hyperviseur.

• L'engagement excessif de processeurs virtuels (l'affectation à l'invité d'un nombre de cœurs de processeur supérieur à celui qui peut être mis à disposition en permanence en raison de l'utilisation d'autres processus) peut créer un temps de latence dans l'exécution des requêtes dans les systèmes de performance. Par exemple, avoir quatre (4) machines virtuelles avec quatre (4) processeurs alors qu'il n'y a que huit (8) cœurs.

Si vous devez surcharger les processeurs, lisez le point suivant (Temps de disponibilité du processeur) pour savoir comment détecter un blocage.

• Réviser le Temps de préparation de l'unité centrale (VMWare) ou Processeur virtuel Temps d'attente de l'UCP par envoi (Hyper-V) sur une base régulière pour s'assurer que la solution n'est pas bloquée en attendant le temps du processeur.
  • Ce billet fournit les indications suivantes sur la signification du compteur CPU Ready Time :

• • L'équivalent Hyper-V du temps de disponibilité du processeur de VMware (Kehayias, Hyper-V Equivalent to VMware CPU Ready Time, 2013)

• Les articles suivants fournissent des informations supplémentaires sur le sujet et sont intéressants à lire :
  • Le surengagement du processeur et son impact sur les performances du serveur SQL sur VMware (Klee, 2012)
  • SQL SERVER - vCPUs - Combien sont trop de CPU pour la virtualisation de SQL Server ? - Notes from the Field #003 (SQL SERVER - vCPUs - Combien y a-t-il de CPU en trop pour la virtualisation de SQL Server ? - Notes de terrain #003)

• Le surengagement de la mémoire est une fonction de virtualisation utile lorsqu'elle est utilisée correctement. Le surengagement doit être évité dans les situations où les invités de la VM ont régulièrement des périodes prolongées pendant lesquelles ils ont besoin de la RAM pour des applications. Cependant, le serveur SQL est une application susceptible d'utiliser la mémoire pendant des périodes prolongées et de subir des pertes de performances dues au swapping.

Une configuration adéquate du client antivirus peut réduire considérablement le temps de blocage des ressources pendant l'analyse en temps réel. Utilisez les informations de configuration suivantes pour améliorer les performances en réduisant les temps d'attente pour les ressources bloquées :

Les recommandations suivantes pour la configuration du client antivirus pour le rôle Hyper-V sont tirées de WINDOWS ANTIVIRUS EXCLUSION RECOMMENDATIONS (Helmick, 2014).

• Vmms.exe
• Vmwp.exe

• Tous les fichiers VHD, VHDX, AVHD, VSV et ISO
  • *.vhd
  • *.vhdx
  • *.avhd
  • *.vsv
  • *.iso

• Répertoire de configuration par défaut de la machine virtuelle : C:\NProgramData\NMicrosoft\NWindows\NHyper-V
• Répertoires de configuration personnalisés pour les machines virtuelles
• Répertoire du disque dur virtuel par défaut : C:\NUsers\NPublic\NDocuments\NHyper-V\NDisques durs virtuels
• Répertoires de disques durs virtuels personnalisés
• Répertoires de données de réplication personnalisés, si vous utilisez Hyper-V Replica
• Répertoires d'instantanés
• C:\NClusterstorage et tous les sous-répertoires (si vous utilisez Live Migration avec Cluster Shared Volumes)

Note : Les chemins d'accès indiqués ci-dessous sont des chemins d'accès par défaut et peuvent avoir été modifiés dans votre installation.

Les recommandations suivantes pour la configuration du client antivirus pour l'application SQL sont extraites de RECOMMANDATIONS D'EXCLUSION DE L'ANTIVIRUS WINDOWS (Helmick, 2014).

• %ProgramFiles%\Microsoft SQL Server\MSSQL11.<Instance Name>\MSSQL\Binn\SQLServr.exe

• %ProgramFiles%\Microsoft SQL Server\MSRS11.<Instance Name>\Reporting Services\ReportServer\Bin\ReportingServicesService.exe

• %ProgramFiles%\Microsoft SQL Server\MSAS11.<Instance Name>\OLAP\Bin\MSMDSrv.exe

Si vous utilisez un cluster Windows, il convient d'appliquer les meilleures pratiques suivantes (un antivirus software qui n'est pas compatible avec les clusters peut causer des problèmes avec les services de clusters, 2012)

• L'antivirus software doit tenir compte des clusters
• A l'exclusion des lieux suivants :
  • Q:\ (lecteur Quorum)
  • C:\NWindows\NCluster
  • Répertoire temporaire du compte de service du cluster SQL

• Fichiers de données SQL Server
  • *.mdf
  • *.ldf
  • *.ndf

• Fichiers de sauvegarde du serveur SQL
  • *.bak
  • *.trn

• Emplacement des fichiers du catalogue en texte intégral : (Emplacement des fichiers pour les instances par défaut et nommées de SQL Server)
  • Instance par défaut : Program Files\Microsoft SQL Server\MSSQL\FTDATA
  • Instance nommée : Program Files\Microsoft SQL Server\MSSQL$instancename\FTDATA

• Fichiers de trace
  • *.trc - ces fichiers peuvent être générés soit lorsque vous configurez manuellement le traçage du profileur, soit lorsque vous activez l'audit C2 pour le serveur.

• Fichiers d'audit SQL (pour SQL Server 2008 ou versions ultérieures)
  • *.sqlaudit

• Fichiers de requêtes SQL
  • *.sql

• Données des services d'analyse
  • L'emplacement par défaut est C:\NProgram Files\NMicrosoft SQL Server\NMSSQL.X\NOLAP\NData.

• Fichiers temporaires d'Analysis Services
  • L'emplacement par défaut est C:\NProgram Files\NMicrosoft SQL Server\NMSSQL.X\NOLAP\NData.

• Fichiers de sauvegarde d'Analysis Services
  • L'emplacement par défaut est C:\NProgram Files\NMicrosoft SQL Server\NMSSQL.X\NOLAP\NBackup

• Fichiers journaux des services d'analyse
  • L'emplacement par défaut est C:\NProgram Files\NMicrosoft SQL Server\NMSSQL.X\NOLAP\NLog.

• Fichiers de données Filestream (SQL 2008 et versions ultérieures)
• Fichiers de stockage Blob à distance (SQL 2008 et versions ultérieures)
• Fichiers temporaires et journaux de Reporting Services (RSTempFiles et LogFiles)

Note : Les chemins d'accès indiqués ci-dessus sont des chemins d'accès par défaut et peuvent avoir été modifiés dans votre installation.

Les recommandations suivantes pour la configuration du client antivirus pour le rôle IIS sont tirées de RECOMMANDATIONS D'EXCLUSION DE L'ANTIVIRUS WINDOWS (Helmick, 2014).

• %systemroot%\system32\inetsrv\w3wp.exe
• %systemroot%\SysWOW64\inetsrv\w3wp.exe

• Répertoire de compression IIS : %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files

Les recommandations suivantes pour la configuration du client antivirus pour l'application SharePoint sont tirées de RECOMMANDATIONS D'EXCLUSION DE L'ANTIVIRUS WINDOWS (Helmick, 2014).

• Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
• Si vous ne souhaitez pas exclure l'ensemble du dossier Web Server Extensions de l'analyse antivirus, vous pouvez exclure uniquement les deux dossiers suivants :
  • * Drive:\NProgram Files\NCommon Files\NMicrosoft Shared\NWeb Server Extensions\N15\NLogs
  • * Drive:\NProgram Files\NCommon Files\NMicrosoft Shared\NWeb Server Extensions\N15\NData\NApplications

• Note : Si vous utilisez un compte spécifique pour les services SharePoint ou les identités des pools d'applications, vous devrez peut-être aussi exclure les dossiers suivants :
  • * Drive:\NUsers\NServiceAccount\NAppData\NLocal\NTemp
  • * Drive:\NUsers\NDefault\NAppData\NLocal\NTemp

Les exclusions de répertoire suivantes peuvent être utilisées pour minimiser l'analyse des fichiers de solution pendant le traitement de la FIM :

• Exclure les binaires FIM : C:\NProgram Files\NMicrosoft Forefront Identity Manager\N2010\NSynchronization Service\N
• Exclure les clients nécessaires aux agents de gestion :
  • Notes Client : E:\NNotes
  • Binaires Oracle : E:\NOracle

• Exclure les binaires FIM : C:\NProgram Files\NMicrosoft Forefront Identity Manager\N2010\NService

La configuration et l'optimisation correctes du serveur SQL sont essentielles pour obtenir les meilleures performances possibles de FIM. En cas de problèmes de performances, je validerais d'abord la configuration du serveur SQL. Les éléments énumérés ci-dessous ne sont pas classés par ordre de priorité. Chaque élément doit être pris en compte lors de la validation de la configuration du serveur SQL.

• Suivez les meilleures pratiques mentionnées dans le réglage du client antivirus du serveur SQL dans la section précédente.

• Toutes les partitions de disque doivent être validées pour les problèmes de décalage d'alignement de disque avant d'effectuer toute installation. Ceci est particulièrement vrai pour toutes les partitions créées par un système d'exploitation Windows antérieur à Windows 2008. Le document Disk Partition Alignment Best Practices for SQL Server (May & Lee, 2009) fournit des conseils sur la manière de détecter et de résoudre ce problème. Bien que ce document ait été rédigé pour SQL 2008, les conseils sont toujours valables pour les versions plus récentes de SQL.
• Sous les partitions de disques logiques se cachent des éléments ayant un impact sur les performances, tels que la taille des blocs RAID et la taille des secteurs physiques des disques durs. Les conseils varient selon les fournisseurs de RAID et les fabricants de disques durs. Consultez les fournisseurs appropriés pour vous assurer que l'implémentation physique de votre espace disque logique est optimisée.

• Les entrées/sorties disque par seconde (IOP) doivent faire l'objet d'une réflexion approfondie et d'une conception adéquate. Ne partez pas du principe que le SAN offre un nombre illimité d'E/S ou que sa configuration est idéale pour les besoins de la conception.
• Le sous-système de disque sous-jacent et les niveaux RAID sont extrêmement importants pour optimiser les performances du disque. Cette affirmation est particulièrement vraie lorsque l'on utilise des serveurs physiques avec un système de stockage local. Les fournisseurs de SAN fournissent généralement des conseils de réglage pour la configuration du SAN afin de prendre en charge de manière optimale des applications telles que le serveur SQL.
• Un serveur SQL a différents modèles d'utilisation des entrées-sorties. Ces schémas d'utilisation peuvent bénéficier de l'utilisation de différents niveaux de performance des disques. SQL SERVER - Virtualized SQL Server Performance and Storage System - Notes from the Field #013 suggère de séparer les composants SQL sur différents disques virtuels avec différentes caractéristiques de stockage. (par exemple, la base de données SQL a besoin d'un disque rapide, alors que la sauvegarde SQL n'a pas besoin d'un disque rapide mais a besoin de beaucoup d'espace disque).
• Les compteurs suivants sont utiles pour détecter les problèmes de diskIO :
  • Disque logique - Longueur moyenne de la file d'attente du disque > 1 indique une accumulation soutenue de demandes d'E/S. Disk Queue Length > 1 indique une accumulation soutenue de demandes d'E/S
  • Disque logique - E/S fractionnées - utile pour détecter la fragmentation
  • Disque logique - %Disk Time >= 80%

• Défragmenter les disques de l'hôte virtuel et de l'invité virtuel pour réduire la fragmentation.
• Utilisez un utilitaire de défragmentation de disque commercial capable de défragmenter les fichiers volumineux. La défragmentation par défaut du système d'exploitation software n'est pas en mesure d'effectuer une défragmentation des fichiers volumineux (> 64 Mo), ce qui peut laisser des fichiers volumineux, tels qu'une base de données, dispersés dans un espace non contigu.
• Disque physique (hôte virtuel)
  • Les disques physiques peuvent se fragmenter lorsque des fichiers volumineux tels que des disques durs virtuels (VHD) sont développés.
  • Prédimensionnez les fichiers de disque virtuel à la taille prévue. N'autorisez pas la croissance automatique des VHD.
  • Défragmenter les volumes physiques si les disques durs virtuels sont redimensionnés pour maintenir une utilisation contiguë du disque.
  • Ne pas placer de disques virtuels sur des partitions système

• Disque virtuel
  • Planifiez la défragmentation pendant les heures creuses, lorsque les sauvegardes ne sont pas effectuées.
  • Limiter le nombre de disques virtuels pour une défragmentation simultanée afin de réduire la charge d'E/S sur le sous-système de disque.
  • Défragmenter les volumes avant l'installation, après l'installation et après la prédimensionnement de la base de données.
  • Évitez de défragmenter les hôtes VM qui ont un instantané. La défragmentation peut faire grossir l'instantané.
  • Les fichiers de pages doivent être placés sur leur propre disque virtuel afin de réduire la fragmentation de la partition du système.

• Fragmentation du fichier de base de données
  • Les fichiers de base de données sont généralement des fichiers plus volumineux qui sont placés sur des volumes d'unités physiques ou logiques et qui ne peuvent pas être facilement défragmentés à l'aide des outils de défragmentation du système d'exploitation. Si ces fichiers grossissent, il est possible que les bases de données elles-mêmes soient divisées dans un espace disque non contigu, ce qui ralentit les performances. Dans ce cas, il est recommandé d'utiliser un logiciel de défragmentation de qualité commerciale ( software ) pour réduire la fragmentation. Pour réduire la fragmentation causée par la croissance de la base de données, voir "Prédimensionnement des bases de données" pour plus d'informations.

• Prédimensionnez les bases de données FIM avec la taille initiale de l'environnement de laboratoire. Prédimensionner la base de données à la taille prévue permet de réduire la fragmentation future du disque lorsque d'autres fichiers existent sur le même volume. Par exemple, si deux bases de données se trouvent sur le même volume, la croissance de l'une d'entre elles peut nécessiter l'utilisation d'un espace non contigu. Le pré-dimensionnement permet aux bases de données d'atteindre la taille prévue sans avoir besoin d'utiliser de l'espace non contigu.
• Dans l'idéal, une base de données prédimensionnée ne devrait pas croître, mais des événements conspirent souvent pour nous empêcher de rester dans les limites fixées lors du dimensionnement initial. Il est recommandé à l'administrateur de bases de données d'autoriser la croissance par blocs plus importants (500 Mo) afin d'éviter que la base de données n'augmente constamment au cours des cycles de traitement. Cette pratique permet également de réduire la fragmentation du disque.
• Les commandes suivantes peuvent être utilisées pour augmenter la taille des bases de données et des fichiers journaux, ainsi que pour modifier les modèles de croissance :

• Consultez le DBA pour déterminer la taille et le nombre appropriés de fichiers DB temporaires à ajouter à la solution. La règle générale est d'ajouter une base de données temporaire par cœur de processeur, à condition que le sous-système de disque puisse prendre en charge efficacement les demandes d'entrée-sortie de plusieurs fichiers. L'idée est de maximiser le débit de la BD temporaire afin d'augmenter les performances de l'application.
• Les bases de données temporaires doivent être placées sur un disque rapide car elles sont fortement utilisées par le service FIM.
• Normaliser la taille de la base de données temporaire par défaut en fonction de la taille des bases de données temporaires supplémentaires qui seront créées. N'oubliez pas d'adapter la taille à des modèles de taille et de croissance typiques.

• Ajouter des bases de données temporaires supplémentaires selon les recommandations de l'administrateur de bases de données.

• Dans un cluster SQL, utiliser les disques locaux pour les bases de données temporaires (nouvelle fonctionnalité dans SQL 2012).

La fragmentation SQL se produit lorsque les index et les catalogues sont fortement fragmentés. SQL utilise cette fragmentation pour améliorer les performances des requêtes. Pour que les performances de SQL restent optimales, il est conseillé de reconstruire régulièrement les index et les catalogues en texte intégral.

• Fragmentation de l'index
  • Créer un plan de maintenance hebdomadaire pour reconstruire les index et mettre à jour les statistiques pour toutes les bases de données des utilisateurs.

• Texte intégral Fragmentation du catalogue
  • Programmer la réorganisation du catalogue de textes intégraux en dehors des heures de pointe. L'article suivant fournit des conseils sur la façon de procéder : How to Automate the Rebuilding of FIM Full Text Indexes (Bradley, 2014).
  • L'article suivant explique comment déterminer le niveau de fragmentation des catalogues de textes intégraux : Fragmentation du texte intégral (iFTS)

• S'assurer que tous les composants FIM utilisent les mêmes niveaux de version dans l'ensemble de la solution. (Moteur de synchronisation FIM, Service FIM, Client FIM, etc...)

• Installer et exécuter le FIM Best Practice Analyzer (FIM Best Practice Analyzer for FIM 2010 R2, n.d.)

• S'assurer que tous les attributs utilisés dans les "Joints" ou les recherches dans le métavers sont correctement indexés dans la configuration du métavers pour l'attribut.
• Supprimer l'indexation de tous les attributs du métavers qui ne sont pas actifs en les utilisant dans les jointures ou les recherches dans le métavers.
• Évaluer les activités de codage "hors bande". Les appels aux systèmes à l'intérieur du code de provisionnement du FIM vers des ressources externes (AD, base de données SQL) sont coûteux en termes de latence. Même de petits retards (10 millisecondes) s'additionnent lorsqu'ils sont effectués sur des milliers d'objets. Utiliser judicieusement les activités "hors bande". Envisager l'utilisation de flux de travail personnalisés pour fournir la fonctionnalité réalisée dans le cadre de l'activité "out of band".
• Si des ressources externes (par exemple une base de données SQL) doivent être appelées au cours d'une activité de codage "hors bande", l'établissement et la suppression des connexions à ces ressources externes doivent être effectués dans les méthodes "Initialize" et "Terminate" de l'extension, et non dans les méthodes "Provision" ou "Flow". Pour le code qui n'est pas à l'abri des threads, il convient de mettre en œuvre le pooling ou la mise en cache.
• Évaluer les performances de la logique "in bound". Un code .NET mal réglé (même s'il ne quitte jamais le contexte du processus du moteur de synchronisation) a un impact important. Même des choses simples comme l'utilisation d'indicateurs de chaîne ("Y"/"N") au lieu de valeurs booléennes peuvent faire une grande différence dans les performances globales.
• S'il y a un grand nombre de déconnecteurs valides, utilisez la fonction de filtrage Déclaré (Filtre d'importation) au lieu de la fonction de filtrage Déclaré. Cela peut accélérer considérablement les temps de synchronisation car les objets n'ont pas besoin d'être traités pendant le cycle. De plus amples informations sur ce sujet sont disponibles ici (Drewes, 2012).

• Supprimer le service de recherche de SharePoint Foundation
• N'activez que les MPR nécessaires à la solution. Désactiver les MPR qui ne sont pas nécessaires à la solution, comme un "MPR tout puissant" qui peut avoir été créé pour résoudre un problème de permissions FIM, car ces MPR créeront des demandes multiples pour chaque transaction.
• Supprimer les Sets inutiles de la solution
• S'assurer qu'il n'y a pas de TPM circulaire en veillant à ce que les filtres de TPM soient aussi étroitement définis que possible afin d'éviter tout chevauchement susceptible d'entraîner une boucle circulaire.
• Veillez à ce que les demandes de mise à jour des clients ne mettent à jour que les attributs qui changent réellement. Par exemple, le fait de donner à un attribut la valeur qu'il a déjà déclenchera des MPR qu'il n'est probablement pas nécessaire d'exécuter.
• Veiller à ce que le nombre minimal de demandes nécessaires pour résoudre le problème commercial soit utilisé (combiner plusieurs mises à jour d'attributs pour le même objet en une seule demande).
• Combiner plusieurs mises à jour d'attributs en une seule demande. Cela signifie que l'évaluateur de fonctions intégré doit être évité lors de la mise à jour de plusieurs attributs d'un même objet. Utilisez plutôt le WAL, une autre activité tierce ou écrivez votre propre activité.
• Envisager l'utilisation de partitions du service FIM pour répartir la charge de la demande sur plusieurs instances du service FIM.
• Pour les opérations en masse, envisagez d'utiliser un client de services web pour communiquer directement avec le service FIM au lieu d'utiliser les cmdlets PowerShell.

• Dans certains cas, il est judicieux de séparer les bases de données du moteur de synchronisation et du service FIM sur des serveurs distincts. Il convient de noter que les données d'une base de données entrent ou sortent de l'autre base de données. Si des contraintes de ressources surviennent dans une base de données, cela entraînera des problèmes de performance dans l'autre base de données.
• Les bases de données SCSM devraient idéalement être placées sur un serveur SQL différent de la base de données du service FIM en raison des problèmes potentiels de contraintes de ressources mentionnés dans la discussion sur la base de données FIM Sync/FIM Service ci-dessus.
• Si vous virtualisez les serveurs, vous devez prêter une attention particulière à l'infrastructure sous-jacente hardware. Par exemple, si vous avez trois serveurs SQL distincts sur le même hôte physique ou utilisant les mêmes disques, vous risquez de ne pas obtenir les performances escomptées en raison de contraintes de ressources.

L'antivirus software qui n'est pas compatible avec les clusters peut causer des problèmes avec les services de clusters. (2012, 17 août). Extrait de https://support.microsoft.com/kb/250355

Bradley, B. (2014, Jan 1). Comment automatiser la reconstruction des index en texte intégral du FIM. Extrait de https://social.technet.microsoft.com/wiki/contents/articles/5701.how-to-automate-the-rebuilding-of-fim-full-text-indexes.aspx

Drewes, F. (2012, Jan 8). Filtrage avant importation des objets AD dans FIM 2010 R2. Extrait de https://social.technet.microsoft.com/wiki/contents/articles/6600.pre-import-filtering-of-ad-objects-in-fim-2010-r2.aspx

Emplacement des fichiers pour les instances par défaut et nommées de SQL Server. (n.d.). Extrait de https://msdn.microsoft.com/en-us/library/ms143547%28v=sql.110%29.aspx

FIM Best Practice Analyzer pour FIM 2010 R2. (s.d.). Extrait de https://technet.microsoft.com/en-us/library/jj203402%28v=ws.10%29.aspx

Helmick, B. (2014, 16 janvier). Document d'exclusion globale de l'audiovisuel. Extrait de https://sdrv.ms/LES7gB

Kehayias, J. (2012, 29 novembre). CPU Ready Time in VMware and How to Interpret its Real Meaning (Temps de disponibilité du processeur dans VMware et comment interpréter sa signification réelle). Extrait de https://www.sqlskills.com/blogs/jonathan/cpu-ready-time-in-vmware-and-how-to-interpret-its-real-meaning/

Kehayias, J. (2013, 13 novembre). Hyper-V Equivalent to VMware CPU Ready Time. Extrait de https://www.sqlskills.com/blogs/jonathan/hyper-v-equivalent-to-vmware-cpu-ready-time/

Klee, D. (2012, 12 décembre 17). Surcommissionnement du processeur et son impact sur les performances du serveur SQL sur VMware. Extrait de https://www.davidklee.net/2012/12/17/cpu-overcommitment-and-its-impact-on-sql-server-performance-on-vmware/

May, J. et Lee, D. (2009, mai). Disk Partition Alignment Best Practices for SQL Server (Meilleures pratiques d'alignement des partitions de disque pour SQL Server). Extrait de https://msdn.microsoft.com/en-us/library/dd758814.aspx

Performance Best Practices for VMware vSphere 5.5. (n.d.). Extrait de https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf

Performance Best Practices for VMware vSphere™ 5.0. (n.d.). Extrait de https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

Pinal, D. (2014, janvier). SQL SERVER - Système virtualisé de performance et de stockage de SQL Server - Notes de terrain #013. Extrait de https://blog.sqlauthority.com/2014/01/30/sql-server-virtualized-sql-server-performance-and-storage-system-notes-from-the-field-013/

SQL SERVER - vCPUs - Combien de CPU sont trop nombreux pour la virtualisation de SQL Server ? - Notes de terrain #003. (n.d.). Extrait de https://blog.sqlauthority.com/2013/11/21/sql-server-vcpus-how-many-are-too-many-cpu-for-sql-server-virtualization-notes-from-the-field-003/

Windows Server 2012 Hyper-V Best Practices. (n.d.). Extrait de https://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx

SQL SERVER - Système virtualisé de performance et de stockage de SQL Server - Notes de terrain #013 (Pinal, 2014)

Nous remercions Rex Wheeler et Sami Van Vliet pour leur aide dans la rédaction de ce guide.