Numéro spécial : Windows Server 2008
Au cœur des modifications du noyau de Windows Server 2008
Mark Russinovich
Vue d'ensemble:
- Gestion de la mémoire et SMB 2.0
- Réparation spontanée de NTFS, Architecture WHEA (Windows Hardware Error Architecture) et vérificateur de pilote
- Évolutivité avec les ports de terminaison d'E/S, pools de threads et NUMA
- Virtualisation Hyper-V
Windows Server 2008 est la dernière version de la plate-forme de serveur de Microsoft. Il inclut des modifications au niveau du système qui couvrent toutes les zones fonctionnelles du système d'exploitation, de la gestion de la mémoire
à la planification des threads en passant par le réseau et la sécurité, pour n'en citer que quelques-unes.
Comme Windows Server® 2008 partage le même noyau que Windows Vista® SP1, il inclut de nombreuses améliorations que j'ai abordées dans mes articles TechNet Magazine précédents : « Dans le noyau de Windows Vista, » parties 1 à 3 (février, mars et avril 2007) et « Au cœur du contrôle de compte d'utilisateur de Windows Vista » (juin 2007). Seule une poignée des fonctionnalités que j'ai décrites dans ces articles est exclusivement orientée client et n'est pas incluse dans Windows Server 2008, comme SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot et le service Planificateur de classes multimédias (MMCSS).
Plutôt que de répéter l'analyse des modifications de noyau importantes introduites présentes dans Windows Vista et Windows Server 2008, telles que les définitions de priorité d'E/S, la nouvelle architecture de démarrage, BitLockerTM, l'intégrité du code et les niveaux d'intégrité obligatoires, je vais me concentrer principalement sur les modifications clés que je n'ai pas couvertes dans ces articles, dont celles liées à la fiabilité, aux performances, à l'évolutivité, ainsi qu'à la nouvelle technologie de virtualisation d'ordinateur hyperviseur de Microsoft, Hyper-VTM.
En outre, comme dans les articles précédents, l'étendue de cet article est limitée au noyau du système d'exploitation, Ntoskrnl.exe, ainsi qu'aux composants système étroitement associés. Il ne couvre par exemple pas les modifications de l'installation (WIM, ou Windows® Imaging Format et les services de composants), l'administration (améliorations de la Stratégie de groupe et d'Active Directory®), les diagnostics généraux et l'analyse (Windows Diagnostic Infrastructure), le noyau réseau (le nouveau pare-feu et l'implémentation de TCP/IP), le noyau du serveur ou les rôles de serveur.
Utilisation de systèmes multiprocesseurs
L'une des modifications de bas niveau du système est que Windows Server 2008 inclut uniquement une version du noyau conçue pour fonctionner sur les systèmes multiprocesseurs. Dans le passé, Windows utilisait une version pour ordinateurs monoprocesseur, car cette version permettait d'obtenir des performances légèrement meilleures en omettant le code de synchronisation requis uniquement dans les environnements multiprocesseurs. Comme le matériel est devenu plus rapide, les avantages en termes de performances des optimisations sont devenus négligeables et la plupart des systèmes serveurs incluent de nos jours plus d'un processeur, ce qui rend la version monoprocesseur inutile.
La figure 1 illustre les variantes du noyau de Windows Server 2008, dans lesquelles la version utilisée sur un système dépend de la version du système d'exploitation, débogage (vérifié) ou commerciale, d'une installation 32 bits ou 64 bits (Itanium, Intel 64 ou AMD64) et, s'il s'agit d'une installation 32 bits, si le système compte plus de 4 Go de mémoire physique ou prend en charge la prévention de l'exécution des données. Windows Server 2008 est également la dernière version du système d'exploitation Windows Server prévue pour proposer une version 32 bits.
Figure 1 Variantes de noyau de Windows Server 2008
| Noyau | 32 bits | 64 bits |
| Multiprocesseurs | Oui | Oui |
| Ordinateur multiprocesseurs vérifié | Oui | Oui |
| Extension d'adresse physique d'ordinateur multiprocesseurs (PAE) | Oui | Non |
| Ordinateur multiprocesseurs PAE vérifié | Oui | Non |
Chaque version de Windows Server a pour objectif d'améliorer les performances des scénarios de serveur clés tels que serveur de fichiers, E/S réseau et gestion de la mémoire. De plus, Windows Server 2008 compte plusieurs modifications et nouvelles fonctionnalités qui permettent à Windows de profiter des nouvelles architectures matérielles, de s'adapter aux réseaux à latence élevée et supprime les goulots d'étranglement qui affectaient les performances dans les versions précédentes de Windows. Cette section passe également en revue les améliorations du gestionnaire de mémoire, du système d'E/S et l'introduction d'un nouveau système de fichiers, SMB 2.0.
Gestion de la mémoire
Expérience : E/S disque importantes
Vous pouvez utiliser un outil d'analyse de système de fichiers tel que Sysinternals Process Monitor de TechNet (technet.microsoft.com/sysinternals/bb896645.aspx) pour rechercher les opérations d'E/S de fichier importantes sur un système Windows Server 2008.
Il existe plusieurs façons de générer d'importantes E/S. Si vous disposez d'un deuxième système exécutant Windows Vista Service Pack 1 ou Windows Server 2008, vous pouvez exécuter le moniteur de processus sur le serveur et analyser les copies de fichiers sur le deuxième système. Vous pouvez généralement produire d'importantes E/S de fichier d'échange en exécutant un programme requérant beaucoup de mémoire et provoquant l'écriture par le gestionnaire de mémoire de pages hors du fichier d'échange.
La figure A montre le moniteur de processus après l'exécution d'un programme demandant beaucoup de mémoire sur un système Windows XP, avec l'option Enable Advanced Output (Activer la sortie avancée) cochée dans le menu Options du moniteur de processus et un filtre défini pour afficher uniquement les écritures dans le fichier d'échange, pagefile.sys. La colonne Détail montre que les écritures ont une taille de 64 Ko.
Figure A (Cliquer sur l'image pour l'agrandir)
Si vous suivez les mêmes étapes dans Windows Server 2008, vous verrez très probablement quelque chose de similaire à ce qui est affiché dans la figure B, qui montre que la plupart des écritures ont une taille approximative de 1 Mo.
Figure B (Cliquer sur l'image pour l'agrandir)
Le gestionnaire de mémoire inclut plusieurs améliorations de performances dans Windows Server 2008. Par exemple, il crée, par rapport à Windows Server 2003, un nombre réduit d'E/S disque, celles-ci étant de taille plus importante, lors de l'extraction de données du fichier d'échange ou d'E/S de lecture anticipée sur des fichiers mappés. Les E/S de fichier de taille plus importante sont possibles grâce à des modifications du système d'E/S supprimant la limite de 64 Ko qui était présente depuis la première version de Windows NT®.
En outre, il est important de noter que les lectures de données pour les lectures anticipées (lectures spéculatives) depuis les fichiers mappés par le gestionnaire de cache sont généralement deux fois plus grandes dans Windows Server 2008 qu'elles n'étaient dans Windows Server 2003 et passent directement dans la liste En attente (le code du système et le cache de données). Ce comportement se produit au lieu de demander au gestionnaire de cache de mapper la mémoire virtuelle et de lire les données dans la plage de travail du système (la mémoire affectée au système par le gestionnaire de mémoire), ce qui pourrait autrement provoquer l'éviction d'autres données ou de code en cours d'utilisation de la plage de travail.
Le gestionnaire de mémoire exécute également des E/S de taille plus importante lors de l'écriture de données dans le fichier d'échange. Alors que Windows Server 2003 effectuait souvent des écritures de moins de 64 Ko, dans Windows Server 2008, le gestionnaire de mémoire effectue couramment des écritures de 1 Mo.
Outre l'amélioration des performances grâce à la réduction du nombre d'écritures dans le fichier d'échange, les écritures de taille plus importante réduisent également la fragmentation dans le fichier d'échange. Ceci provoque à son tour une réduction du nombre de lectures et de recherches sur disque nécessaires pour lire plusieurs pages précédentes, car elles sont le plus souvent adjacentes.
Le gestionnaire de mémoire essaie également d'écrire d'autres pages modifiées proches de celle qui est écrite dans l'espace d'adressage du processus propriétaire, et cible la zone du fichier d'échange dans laquelle résident d'autres pages voisines. Ceci réduit également la fragmentation et peut améliorer les performances car les pages qui pourraient être en fin de compte écrites dans le fichier d'échange y ont déjà été écrites. En outre, ceci réduit le nombre de demandes de lectures de fichier d'échange nécessaires pour extraire une plage de pages de processus adjacentes. Examinez l'encadré « Expérience : E/S disque importantes » pour plus d'informations sur l'utilisation d'E/S importantes par le gestionnaire de mémoire.
SMB 2.0
Le protocole de système de fichiers distant SMB (Server Message Block), qui porte également le nom de CIFS (Common Internet File System) a constitué la base du service de fichiers Windows depuis que cette fonctionnalité a été introduite dans Windows. Au cours des dernières années, plusieurs restrictions de conception de SMB ont limité les performances du service de fichiers de Windows et sa capacité à tirer parti des nouvelles fonctionnalités de système de fichiers local. Par exemple, la taille de tampon maximale qui peut être transmise dans un message unique est environ 60 Ko et SMB 1.0 n'était pas conscient des liens symboliques NTFS côté client qui ont été ajoutés dans Windows Vista et Windows Server 2008.
Avec Windows Vista et Windows Server 2008 a été introduit SMB 2.0, un nouveau protocole de système de serveur de fichiers distant que Windows utilise lorsque le client et le serveur le prennent en charge. Outre le traitement approprié des liens symboliques côté client et d'autres améliorations de NTFS, SMB 2.0 utilise le traitement par lots pour réduire le nombre de messages échangés entre un client et un serveur. Le traitement par lots peut améliorer le débit sur les réseaux de latence élevée comme les réseaux étendus (WAN) car il permet à un plus grand nombre de données d'être utilisées simultanément.
Alors que SMB 1.0 émettait des E/S pour un fichier unique de façon séquentielle, SMB 2.0 implémente le traitement en pipeline des E/S, ce qui lui permet d'émettre de multiples E/S simultanées pour le même fichier. Il mesure la quantité de mémoire de serveur utilisée par un client pour les E/S en attente afin de déterminer la profondeur du pipeline.
En raison des modifications du gestionnaire de mémoire d'E/S et du système d'E/S de Windows, du réglage automatique de la fenêtre de réception TCP/IP et des améliorations du moteur de copie de fichier, SMB 2.0 permet d'obtenir des améliorations de débit significatives et une réduction des temps de copie de fichier pour les transferts de taille importante. Puisque les deux systèmes d'exploitation mettent en œuvre SMB 2.0, le déploiement de serveurs de fichiers Windows Server 2008 avec les clients Windows Vista permet d'utiliser SMB 2.0 et de tirer parti de ses avantages en termes de performances.
Fiabilité avec le rétablissement automatique de NTFS
La fiabilité est un attribut de serveur essentiel et Windows Server 2008 apporte diverses améliorations aidant les administrateurs à continuer à exécuter leurs serveurs sans perturbations, notamment grâce à la réparation de cohérence en ligne de NTFS, à une nouvelle infrastructure de signalement d'erreurs de matériel et aux extensions du vérificateur de pilote.
Avec les périphériques de stockage de plusieurs téraoctets d'aujourd'hui, la mise hors connexion d'un volume pour une vérification de cohérence peut avoir pour résultat une interruption de service de plusieurs heures. En reconnaissant que de nombreuses altérations de disque sont localisées dans un seul fichier ou une portion des métadonnées, Windows Server 2008 met en œuvre une nouvelle fonction de rétablissement automatique de NTFS pour réparer les dommages pendant qu'un volume reste en ligne.
Lorsque NTFS détecte l'altération, il empêche l'accès au fichier ou aux fichiers endommagés et crée un thread de travail système qui exécute des corrections similaires à celles de Chkdsk sur les structures de données corrompues, permettant d'accéder aux fichiers réparés une fois l'opération terminée. L'accès aux autres fichiers continue normalement pendant cette opération, diminuant le risque d'interruption de service.
Infrastructure WHEA
L'architecture WHEA incluse dans Windows Server 2008 permet de simplifier la gestion des défaillances matérielles et d'obtenir une réponse dynamique aux erreurs non fatales. Les serveurs possèdent souvent des garanties de fonctionnement strictes. Par conséquent, l'identification des erreurs et la réponse à celles-ci dans un délai opportun sur de tels systèmes sont essentielles.
L'analyse des incidents soumise à Microsoft via le site Web Online Crash Analysis montre qu'à peu près 10 % des incidents de système d'exploitation étaient dus à une défaillance matérielle, mais la détermination de la cause initiale de ces incidents a été difficile ou impossible en raison d'informations sur les erreurs insuffisantes fournies par le matériel pour la capture durant un incident. En outre, avant Windows Server 2008, Windows ne fournissait pas de prise en charge intégrée pour le contrôle de l'état des périphériques, de correction implémentée ou de notification de défaillance imminente. Ceci s'explique par le fait que les périphériques matériels n'utilisent pas de format d'erreur commun et ne fournissent pas de prise en charge pour les logiciels de gestion d'erreurs.
WHEA fournit un mécanisme unifié pour la découverte et le signalement d'erreur-source pour les périphériques de plate-forme, y compris les processeurs, la mémoire, les caches et les bus tels que PCI et PCI Express. Ceci est effectué en mettant en œuvre l'architecture indiquée dans la figure 2, dans laquelle le cœur est une API noyau qu'appellent les sources d'erreur pour signaler des erreurs. L'API nécessite que toutes les erreurs possèdent une mise en forme commune et enregistre les erreurs en utilisant des événements Suivi d’événements pour Windows (ETW) (les erreurs irréparables sont enregistrées après le redémarrage).
Figure 2** Infrastructure de signalement d'erreurs WHEA **(Cliquer sur l'image pour l'agrandir)
ETW a été introduit dans Windows 2000, et l'utilisation de ETW par WHEA facilite le développement par les fabricants de matériel et les fournisseurs de logiciels d'applications de gestion de diagnostic de périphérique qui consomment des événements WHEA. Si un événement est suffisamment grave pour provoquer un arrêt du système, WHEA s'assure que l'enregistrement d'erreur irréparable est enregistré dans le fichier de l'image mémoire des incidents pour que les administrateurs puissent déterminer la cause initiale de l'incident.
Le pilote d’erreurs matérielles spécifiques à une plate-forme (PSHED) est un autre élément clé de WHEA dans %Systemroot%\System32\Pshed.dll. Le noyau est lié à PSHED et s'interface avec le matériel et le microprogramme de la plate-forme, servant essentiellement de couche de traduction entre leurs notifications d'erreur et l'API de signalement d'erreurs de WHEA. Il existe un pilote d’erreurs matérielles fourni par Microsoft pour chaque architecture de plate-forme (x86, x64, Itanium) et le pilote expose un modèle enfichable pour que les fournisseurs et les fabricants de matériel puissent remplacer les comportements par défaut par des comportements spécifiques à leurs plates-formes.
Enfin, les composants du système qui s'interfacent avec d'autres sources d'erreur, y compris les pilotes de périphériques, la couche d'abstraction matérielle (HAL), et le noyau peuvent implémenter des gestionnaires d'erreur de matériel de bas niveau (Low-Level Hardware Error Handlers, LLHEL) qui gèrent initialement une condition d'erreur. La tâche d'un LLHEL est d'extraire les informations d'erreur du périphérique, de notifier le pilote d’erreurs matérielles pour lui permettre de recueillir les informations d'erreur de plate-forme supplémentaires et d'appeler ensuite l'API de signalement d'erreurs WHEA du noyau.
Vérificateur de pilotes
Le vérificateur de pilotes, un outil puissant pour le dépistage des pilotes de périphérique bogués et le matériel défectueux, a été inclus dans chacune des versions de Windows depuis Windows 2000. Les administrateurs configurent habituellement le vérificateur de pilotes (%Systemroot%\System32\Verifier.exe) pour qu'il surveille étroitement le comportement des pilotes présumés à l'origine d'arrêts du système. Le vérificateur de pilotes capture les opérations de pilote illégales afin qu'un fichier de l'image mémoire des incidents pointe directement sur l'élément coupable.
Les implémentations précédentes du vérificateur de pilotes avaient un inconvénient : la plupart des modifications de configuration nécessitaient de redémarrer le système, ce qui n'est évidemment pas souhaitable sur un serveur de production. L'implémentation du vérificateur de pilotes dans Windows Server 2008 améliore ce processus en supprimant la nécessité de redémarrer pour les vérifications les plus utiles, permettant ainsi de dépanner un serveur problématique sans avoir à le redémarrer.
De plus, le vérificateur de pilotes comprend trois nouvelles vérifications, illustrées dans la figure 3. Les vérifications de sécurité permettent de s'assurer que les pilotes de périphériques définissent des autorisations sécurisées sur les objets qu'ils utilisent pour s'interfacer avec les applications. Le forçage des requêtes d'E/S en attente teste la résistance d'un pilote aux opérations d'E/S asynchrones qui s'achèvent immédiatement plutôt qu'après un délai. Les vérifications diverses recherchent les pilotes libérant incorrectement des ressources utilisées, utilisant de manière incorrecte les API d'inscription de WMI (Windows Management Instrumentation) et provoquant des fuites de descripteurs de ressources.
Figure 3** Vérificateur de pilotes avec options pour Windows Server 2008 activées **(Cliquer sur l'image pour l'agrandir)
Évolutivité
L'évolutivité fait référence à la capacité d'un système d'exploitation ou d'une application à utiliser efficacement des processeurs multiples et de grandes quantités de mémoire. Chaque version de Windows améliore l'évolutivité en réduisant ou en éliminant l'utilisation de verrous qui réduisent le parallélisme sur les systèmes multiprocesseurs et Windows Server 2008 ne fait pas exception.
Une amélioration relativement réduite tout en étant significative a été apportée au code qui exécute l'expiration de minuteur, qui n'acquiert plus le verrou de répartiteur, un verrou de planificateur à l'échelle du système utilisé par toutes les opérations de synchronisation de bas niveau. La réduction qui en résulte en termes de synchronisation d'UC indirecte permet aux systèmes Terminal Services Windows Server 2008 de prendre en charge environ 30 % d'utilisateurs simultanés de plus que Windows Server 2003.
Les autres améliorations d'évolutivité de Windows Server 2008 incluent les améliorations de port de terminaison, une nouvelle implémentation de pool de threads, l'utilisation plus efficace du matériel NUMA (Non-Uniform Memory Access) et le partitionnement dynamique de système.
Gestion améliorée de port de terminaison d'E/S
La plupart des applications serveur Windows évolutives, y compris IIS, SQL Server® et Exchange Server, dépendent d'une API de synchronisation Windows appelée port de terminaison d'E/S pour réduire la commutation entre les threads d'exécution multiples pendant l'exécution d'opérations d'E/S. Elles effectuent ceci en associant premièrement des notifications aux nouvelles arrivées de requêtes, telles que les connexions de serveur Web, avec un port de terminaison et en dédiant un pool de threads à l'attente de notifications. Lorsqu'une requête arrive, Windows planifie un thread, qui exécute alors habituellement d'autres opérations d'E/S telles que la lecture d'une page Web depuis le disque et l'envoi au client pour terminer la requête.
Pour que le même thread puisse revenir en attente d'autres requêtes de client aussi rapidement que possible, le thread émet les E/S de manière asynchrone et associe les terminaisons d'E/S avec le port de terminaison. Le thread retourne alors en attente sur le port de terminaison, qui planifiera le thread lorsqu'une nouvelle requête arrivera ou qu'une des E/S se terminera. Ainsi, le même thread reste actif sur une UC en effectuant le traitement des requêtes du client et ou en étant en attente sur le port de terminaison.
Dans les versions précédentes de Windows, l'inconvénient de l'implémentation du port de terminaison était que, lorsqu'une E/S était terminée, le système d'E/S faisait en sorte que le thread qui avait émis l'E/S effectuait immédiatement un traitement de terminaison, sans tenir compte de ce qu'il était en train de faire. Si d'autres threads étaient actifs, le planificateur forçait souvent un basculement de thread actif et de contexte de l'émetteur.
Windows Server 2008 évite ces basculements de contexte en différant le traitement de terminaison jusqu'au prochain thread en attente sur le port de terminaison auquel l'E/S est associée. Ainsi, même si un thread différent est le prochain à attendre sur le port de terminaison, il exécutera le traitement de terminaison avant d'exécuter un autre code et le planificateur ne nécessitera pas de basculer vers le thread émetteur. Cette réduction du basculement de contexte peut améliorer de façon spectaculaire l'évolutivité des applications serveurs de charge importante.
Pools de threads plus efficaces
L'écriture d'applications qui tirent parti d'UC multiples peut être difficile. Windows XP a donc introduit les pools de thread de travail, une infrastructure et une API associée qui effectue l'abstraction des détails d'exécution de petites unités de travail sur les UC. Une application spécifie les éléments de travail à l'API de pool de threads, qui les exécute alors sur l'un des threads qu'elle crée et gère pour chaque UC dans le système.
L'objectif du pool de threads est de réduire les basculements de contexte en utilisant les mêmes threads pour exécuter successivement des articles de travail multiples. Lorsque cela n'est pas possible car l'un de ses threads est déjà occupé à exécuter un autre travail, il exécute l'article de travail en utilisant un thread différent sur une UC différente.
L'implémentation de pool de thread de Windows Server 2008 utilise mieux les UC de manière indirecte car elle profite des améliorations de port de terminaison et directement en optimisant la gestion de thread afin que les threads de travail se succèdent selon les besoins pour la gestion de la charge d'une application. De plus, le cœur de l'infrastructure est passé en mode noyau, ce qui réduit le nombre d'appels système effectués par les applications qui utilisent l'API. Enfin, la nouvelle API facilite l'exécution de certaines opérations par les applications, telles que l'abandon d'unités de travail mises en file d'attente pendant l'arrêt de l'application.
Optimisations pour NUMA
Windows Server 2003 a introduit des optimisations pour les ordinateurs NUMA dans le planificateur de threads et le gestionnaire de mémoire, mais Windows Server 2008 a ajouté des optimisations pour NUMA dans le gestionnaire d'E/S et étendu les optimisations pour NUMA du gestionnaire de mémoire.
Les systèmes NUMA sont généralement des systèmes multiprocesseurs dont la mémoire possède une latence différente en fonction du processeur qui y accède (voir la figure 4). La mémoire est divisée en nœuds, les latences entre les UC et les nœuds pouvant varier et chaque UC étant considérée comme une partie du nœud pour lequel elle dispose de l'accès le plus rapide.
Figure 4** Exemple de système NUMA **(Cliquer sur l'image pour l'agrandir)
Les systèmes NUMA, en particulier ceux disposant de plus de huit UC, sont souvent plus efficaces en termes de coût et de performances que les systèmes à accès mémoire uniforme. Alors qu'un système à accès mémoire uniforme doit rendre la mémoire également disponible pour toutes les UC, un système NUMA peut mettre en œuvre des connexions ultra-rapides pour la mémoire directement connectée à une UC et des connexions moins onéreuses et de latence plus élevée pour les UC et la mémoire qui sont plus distantes.
Pour une évolutivité efficace sur un système NUMA, le système d'exploitation ou l'application doit être conscient de la topologie du nœud afin que le calcul s'exécute près de la mémoire contenant les données et le code du calcul. Par exemple, le planificateur Windows affecte chaque thread à un « processeur idéal », qui est l'UC sur laquelle le planificateur essaie de toujours exécuter le thread. Ceci permet d'augmenter la probabilité que les données que le thread place dans le cache de l'UC seront disponibles pour le thread chaque fois qu'il s'exécute.
Dans Windows Server 2003, le planificateur étend ce concept en considérant le nœud contenant le processeur idéal comme étant le nœud idéal du thread et il essaie de planifier le thread sur une autre UC dans le nœud idéal lorsque le processeur idéal est occupé à exécuter un thread différent. Le gestionnaire de mémoire de Windows Server 2003 est également devenu compatible NUMA et, lorsque c'est possible, il dirige les allocations de mémoire du thread vers la mémoire du nœud sur lequel le thread exécute.
Dans Windows Server 2008, le gestionnaire de mémoire divise les tampons de mémoire non paginée du noyau (la mémoire utilisée par le noyau et les pilotes de périphérique pour enregistrer des données garanties de rester en RAM) entre les nœuds afin que les allocations viennent de la mémoire sur le nœud duquel l'allocation provient. Les entrées de la table de page système (PTE) sont allouées depuis le nœud duquel provient l'allocation, si l'allocation nécessite une nouvelle table de page pour la satisfaire, au lieu de n'importe quel nœud, comme c'est le cas dans Windows Server 2003.
Dans Windows Server 2003, lorsqu'un thread effectue une allocation de mémoire, le gestionnaire de mémoire préfère le nœud sur lequel le thread s'exécute lors de l'allocation. Si le thread était temporairement planifié sur un nœud non idéal, toute allocation exécutée pendant ce temps proviendrait du nœud non idéal. Par conséquent, lorsque le thread s'exécute finalement sur son nœud idéal, il n'est pas aussi près qu'il pourrait l'être des données ou du code enregistré dans la mémoire allouée.
Pour y remédier, le gestionnaire de mémoire Windows Server 2008 préfère le nœud idéal du thread pour toutes les allocations du thread, même lorsque le thread s'exécute près d'un nœud différent. Le gestionnaire de mémoire comprend également automatiquement les latences entre les processeurs et les nœuds et, si le nœud idéal ne dispose pas de mémoire disponible, il vérifie ensuite le nœud le plus proche du nœud idéal. De plus, le gestionnaire de mémoire migre les pages de sa liste En attente vers le nœud idéal du thread lorsqu'un thread fait référence au code ou aux données.
Les applications qui veulent contrôler l'emplacement de leurs allocations peuvent utiliser les nouvelles API de mémoire NUMA qui leur permettent de spécifier un nœud préféré pour les allocations de mémoire, les affichages de mappage de fichier et les objets de mappage de fichier. Pour une allocation liée à un mappage de fichier, le gestionnaire de mémoire vérifie si l'opération de mappage spécifie un nœud, puis vérifie si l'objet de mappage de fichier en spécifie un et a finalement recours au nœud du thread idéal si aucun ne correspond.
Avant Windows Server 2008, l'interruption et l'appel de procédure différé associé (Deferred Procedure Call, DPC) d'une E/S de stockage ou réseau pouvait s'exécuter sur n'importe quelle UC, y compris celles d'un nœud différent de celui sur lequel l'E/S avait été établie, causant potentiellement l'écriture ou la lecture de données de l'opération d'E/S dans la mémoire d'un nœud différent de celui sur lequel l'accès aux données avait lieu.
Pour éviter ceci, le système d'E/S de Windows Server 2008 dirige l'exécution de DPC à une UC dans le nœud qui a établi l'E/S et les systèmes qui possèdent des périphériques qui prennent en charge le bus MSI-X PCI (une extension du standard Message Signaled Interrupt) peuvent localiser davantage l'opération d'E/S en utilisant des pilotes de périphériques qui tirent parti des API de Windows Server 2008 pour diriger une interruption d'E/S vers le processeur qui a établi l'E/S.
Partitionnement dynamique
La prise en charge de l'ajout dynamique de ressources matérielles telles que la mémoire et les UC est l'une des moyens permettant de rendre un système plus évolutif. Cette même prise en charge peut rendre le système plus disponible lorsque ces ressources peuvent être remplacées sans nécessiter un redémarrage du système.
Windows Server 2003 permet l'ajout de mémoire à chaud, ce qui confère aux serveurs une prise en charge de mémoire dynamique afin d'utiliser la RAM lorsque l'administrateur l'ajoute. Windows Server 2008 étend la prise en charge de mémoire dynamique en permettant le remplacement de la mémoire.
La RAM devenant plus dépendante des corrections ECC (Error Correcting Code) est susceptible de tomber totalement en panne. Par conséquent, sur un serveur avec prise en charge de remplacement à chaud, Windows Server 2008 peut migrer de manière transparente des données des banques de mémoire défectueuses sur celles qui les remplacent. Ceci est effectué en migrant tout d'abord les données qui sont sous le contrôle du système d'exploitation, en arrêtant des périphériques matériels en les plaçant dans un état basse puissance, en migrant le reste des données de la mémoire et en remettant sous alimentation les périphériques pour poursuivre les activités normales.
Windows Server 2008 prend également en charge l'ajout à chaud et le remplacement à chaud des processeurs. Pour un remplacement à chaud, le matériel doit prendre en charge le concept d'UC de rechange, qui peut être mise en connexion ou ajoutée de manière dynamique lorsqu'une UC existante produit des indications de défaillance, ce qui est actuellement uniquement disponible sur les systèmes haut de gamme. Le planificateur Windows Server 2008 ralentit l'activité sur l'UC défectueuse et migre le travail sur l'UC de rechange, après quoi l'UC défectueuse peut être enlevée et remplacée par une UC de rechange.
Windows Server 2008 prend en charge l'ajout de processeur à chaud, permettant ainsi à un administrateur de mettre à niveau les capacités de traitement d'un serveur sans temps mort du serveur. Cependant, le planificateur et le système d'E/S rendront uniquement une nouvelle UC disponible aux pilotes de périphériques et aux applications qui demandent la notification d'arrivée d'UC via les nouvelles API car certaines applications incorporent la supposition que le nombre d'UC est fixe pour une session de démarrage. Par exemple, une application pourrait allouer un ensemble de files de travail correspondant à chaque UC, dans laquelle un thread utilise la file associée à l'UC sur laquelle il exécute. Si le planificateur met l'un des threads de l'application sur une nouvelle UC, il essaie de référencer une file inexistante et peut corrompre les données de l'application et provoquer l'arrêt de l'application.
Les applications serveurs de Microsoft telles que SQL Server et Exchange Server prennent en charge l'ajout d'UC, comme plusieurs processus Windows fondamentaux, dont le processus Système, le Gestionnaire de session (%SystemRoot%\System32\Smss.exe,) et les processus d'hébergement de service génériques (%Systemroot%\System32\Svchost.exe). Les autres processus peuvent également demander la notification d'arrivée de nouvelle UC en utilisant une API Windows. Lorsqu'une nouvelle UC arrive, Windows notifie les pilotes de périphériques de l'arrivée imminente, démarre l'UC et notifie alors les pilotes de périphériques et les applications écrites pour tirer parti de nouvelles UC afin qu'ils allouent des structures de données afin de suivre l'activité de la nouvelle UC, si nécessaire.
Virtualisation d'ordinateur
Avant Windows Server 2008, les produits de virtualisation de Microsoft, dont Virtual Server 2005, étaient implémentés en utilisant la virtualisation hébergée, comme indiqué à la figure 5. Dans la virtualisation hébergée, les ordinateurs virtuels sont implémentés par un Moniteur d'ordinateur virtuel (VMM) s'exécutant à côté d'un système d'exploitation d'hôte, généralement comme pilote de périphérique. Le VMM s'appuie sur la gestion des ressources et les pilotes de périphériques du système d'exploitation d'hôte et, lorsque le système d'exploitation hôte le planifie pour l'exécuter, il effectue un découpage temporel de l'UC entre les ordinateurs virtuels actifs.
Figure 5** Virtualisation hébergée d'ordinateur **(Cliquer sur l'image pour l'agrandir)
Hyper-V (anciennement « Viridian ») est implémenté avec la virtualisation hyperviseur. L'hyperviseur possède le contrôle complet de toutes les ressources matérielles et même le système d'exploitation Windows Server 2008, qui démarre le système et au travers duquel vous contrôlez les ordinateurs virtuels, s'exécute essentiellement dans un ordinateur virtuel, comme indiqué à la figure 6.
Figure 6** Architecture Hyper-V **(Cliquer sur l'image pour l'agrandir)
L'hyperviseur peut partitionner le système en plusieurs ordinateurs virtuels et traite l'instance démarrant Windows Server 2008 comme maître, racine ou partition, lui conférant l'accès direct aux périphériques matériels tels que le disque, les cartes réseau et les processeurs graphiques. L'hyperviseur s'attend à ce que la racine effectue la gestion de l'alimentation et réponde aux événements plug-and-play du matériel. Il intercepte les E/S de périphérique matériel établies dans une partition enfante et les route dans la racine, qui utilise des pilotes de périphériques Windows Server 2008 pour exécuter l'accès au matériel. Ainsi, les serveurs exécutant Hyper-V peuvent profiter entièrement de la prise en charge de Windows pour les périphériques matériels.
Lorsque vous configurez Windows Server 2008 avec le rôle de serveur Hyper-V, Windows définit le paramètre de base de données de configuration de démarrage (Boot Configuration Database, BCD) hypervisorimagelaunchtypeboot sur auto et configure le pilote de périphérique Hvboot.sys pour qu'il démarre plus tôt dans le processus de démarrage. Si l'option est configurée, Hvboot.sys prépare le système pour la virtualisation et charge ensuite soit %Systemroot%\System32\Hvax64.exe soit %Systemroot%\System32\Hvix64.exe en mémoire, en fonction de l'implémentation des extensions de virtualisation d'UC (AMD-V ou Intel VT, respectivement).
Une fois chargé, l'hyperviseur utilise les extensions de virtualisation pour s'insérer sous Windows Server 2008. Les applications en mode utilisateur utilisent le niveau de privilège Ring 3 du processeur x64 et le code en mode noyau s'exécute en Ring 0, l'hyperviseur fonctionnant donc au niveau de privilège conceptuel Ring -1, puisqu'il peut contrôler l'environnement d'exécution de code s'exécutant au Ring 0.
Lorsque vous utilisez la console d'administration Hyper-V pour créer ou démarrer une partition enfante, elle communique avec l'hyperviseur en utilisant le pilote %Systemroot%\System32\Drivers\Winhv.sys, qui utilise l'API hypercall décrite publiquement pour ordonner à l'hyperviseur de créer une nouvelle partition à la taille de mémoire physique et aux caractéristiques d'exécution spécifiées. Le service VM (%Systemroot%\System32\Vmms.exe) dans la racine est responsable de la création du processus de travail d'ordinateur virtuel (%Systemroot%\System32\Vmwp.exe) pour que chaque partition enfante gère l'état de l'enfant.
L'une des manières dont Windows améliore les performances des systèmes d'exploitation des ordinateurs virtuels est l'implémentation, par Windows Server 2008 comme Windows Vista, des « enlightments », qui sont des séquences de code qui s'activent seulement lorsque le système d'exploitation s'exécute sur un hyperviseur qui implémente l'API hypercall de Microsoft. En demandant directement des services auprès de l'hyperviseur, l'ordinateur virtuel enfant évite le code de virtualisation indirect qui serait utilisé si l'hyperviseur avait à deviner les intentions du système d'exploitation enfant.
Par exemple, un système d'exploitation invité qui n'implémente pas les enlightments pour les verrouillages spinlock, qui exécute une synchronisation multiprocesseur de bas niveau, tournerait dans une boucle étroite en attendant qu'un verrouillage spinlock soit libéré par un autre processeur virtuel. Le verrouillage pourrait monopoliser l'une des UC matérielles jusqu'à ce que l'hyperviseur planifie le deuxième processeur virtuel. Sur les systèmes d'exploitation compatibles avec les enlightments, le code de verrouillage spinlock notifierait l'hyperviseur via un appel hypercall lorsqu'il devrait tourner en boucle, afin que l'hyperviseur puisse immédiatement planifier un autre processeur virtuel et réduire l'utilisation de processeur inutile.
L'accélération de l'accès aux périphériques par les ordinateurs virtuels est une autre avancée de Windows Server 2008 en matière de performances des ordinateurs virtuels. Les performances sont améliorées en installant des composants, appelés « composants d'intégration d'ordinateur virtuel », dans le système d'exploitation enfant.
Si vous exécutez un ordinateur virtuel sans installer les composants d'intégration, le système d'exploitation enfant configure les pilotes de périphériques matériels pour les périphériques émulés que l'hyperviseur lui présente. L'hyperviseur doit intervenir lorsqu'un pilote de périphérique essaie d'accéder à une ressource matérielle afin d'informer la partition racine, qui exécute les E/S de périphérique en utilisant les pilotes de périphérique de Windows standard de la part du système d'exploitation de l'ordinateur virtuel enfant. Puisqu'une simple opération d'E/S de haut niveau, telle que la lecture depuis le disque, peut impliquer de nombreux accès matériels discrets, elle peut provoquer de nombreuses transitions, appelées interceptions, dans l'hyperviseur et la partition racine.
Windows Server 2008 réduit le nombre d'interceptions grâce à trois composants : Le pilote de bus d'ordinateur virtuel (%Systemroot%\System32\Drivers\Vmbus.sys), les clients de services virtuels (VSC) et les fournisseurs de services virtuels (VSP). Lorsque vous installez les composants d'intégration dans un ordinateur virtuel avec un système d'exploitation pris en charge, les VSC prennent le rôle de pilotes de périphériques et utilisent les services du pilote Vmbus.sys dans l'ordinateur virtuel enfant pour envoyer des requêtes d'E/S de haut niveau au pilote de bus d'ordinateur virtuel dans la partition racine, via l'appel hypercall et les services de partage de mémoire de l'hyperviseur. Dans la partition racine, Vmbus.sys transfère la requête au VSP correspondant, qui établit alors des requêtes d'E/S Windows standard via les pilotes de périphériques de la racine.
Comme vous pouvez le constater, Windows Server 2008 joue un rôle essentiel dans la stratégie de virtualisation d'ordinateur de Microsoft avec l'introduction de la virtualisation Hyper-V basée sur hyperviseur. Vous trouverez plus d'informations sur le sujet, comme sur d'autres fonctionnalités, dans la prochaine version de mon livre, Microsoft Windows Internals, qui sera publié dans le courant de cette année.
Mark Russinovich est technicien dans le service responsable des plates-formes et services chez Microsoft. Il est coauteur de Microsoft Windows Internals (Microsoft Press, 2004) et intervient fréquemment lors de conférences informatiques, y compris Microsoft TechEd et le symposium PDC. Il a rejoint nos équipes lorsque Microsoft a racheté Winternals Software, la société dont il était le cofondateur. Il a également créé Sysinternals, où il a publié de nombreux utilitaires populaires, notamment Process Explorer, Filemon et Regmon.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.