Résolution des problèmes de test du serveur système
Pour résoudre les problèmes qui se produisent avec les tests System.Server du Kit de laboratoire matériel Windows (Windows HLK), suivez les étapes décrites dans cet article.
Contenu de cet article :
Résolution générale des problèmes de serveur système
Consultez les rubriques suivantes pour obtenir de l’aide sur les tests de serveur :
Rubriques Windows HLK spécifiques au test du périphérique, du pilote ou du système.
LoadGen Server Stress - Exécuter en premier - Définir des stratégies d’ordinateur
LoadGen Server Stress - Dernière exécution - Réinitialiser les stratégies d’ordinateur
Pour les tests de pilotes et de périphériques serveur, assurez-vous que le système testé (SUT) est configuré comme suit :
La version correcte de Windows est installée.
L’option Server Core est installée.
Le SUT a au moins quatre cœurs\processeurs logiques.
Au minimum 6 Go de RAM sont installés sur le SUT.
Pour les tests de périphérique de stockage, vous pouvez avoir besoin de deux instances d’appareil qui ont des lecteurs de stockage si le périphérique de stockage est un périphérique de démarrage.
Si vous obtenez une erreur indiquant que Windows HLK Studio n’a pas pu ajouter des cibles au projet, réélectionnez la cible, fermez Windows HLK Studio, puis redémarrez Windows HLK Studio. L’erreur signifie que les données ne sont pas actualisées.
Le processus Sysparse exécute directement les DLL du rassembleur. Un deuxième processus, Asset Configuration Manager Engine (ACME), surveille les modifications matérielles et alerte le système si une ou plusieurs modifications matérielles se produisent. ACME attend qu’un délai d’expiration se produise ou que les rapports de modifications matérielles fréquents s’arrêtent avant de lancer les rassembleurs abonnés.
Certains tests entraînent des modifications matérielles tout au long de la série de tests. Sysparse s’exécute alors régulièrement. Sysparse peut consommer de grandes quantités de mémoire, ce qui est dû aux rassembleurs qui exécutent et collectent des données. Sysparse ne doit pas interférer avec les tests, car dans la plupart des cas, les tests ne vérifient pas les performances.
Assurez-vous que le système sur lequel le contrôleur Windows HLK est installé dispose de fonctionnalités matérielles adéquates pour répondre aux demandes de test. Pour obtenir une description de ces configurations matérielles requises, consultez Conditions préalables pour Windows HLK . À mesure que le nombre d’appareils et de systèmes testés augmente, vous devrez peut-être ajouter davantage de processeurs, de mémoire ou de stockage.
Résolution des échecs de tests de serveur système
Si un test échoue, procédez comme suit :
Si l’échec se produit dans les minutes qui suivent le démarrage du test, cela signifie généralement que quelque chose n’a pas été correctement configuré. Reconfirmez la configuration de l’environnement de test.
Si le test s’est exécuté, il doit y avoir un fichier journal appelé Srvlog.xml dans le contrôleur Windows HLK. Procédez comme suit :
Dans Windows HLK Studio, ouvrez Moniteur de travaux.
Accédez au pool d’ordinateurs du test planifié.
Dans le volet État de l’exécution du travail, sélectionnez Loadgen Server Stress - Start Test for Server.
Dans le volet État de l’exécution de la tâche, cliquez avec le bouton droit sur RunJob -Launch Server Logo Kit et sélectionnez Résultat du travail enfant.
Revenez au volet État de l’exécution du travail et sélectionnez Lancer le kit de logo du serveur.
Dans le volet État d’exécution de la tâche, cliquez avec le bouton droit sur Démarrer la tâche LogGen et sélectionnez Afficher le journal des tâches. Le journal est analysé à partir du journal Loadgen d’origine et contient uniquement des erreurs et des passes.
Pour récupérer le journal texte Loadgen d’origine, répétez les étapes 1 à 5, puis cliquez avec le bouton droit sur Lancer le kit de logo du serveur et sélectionnez Parcourir les journaux des travaux. Le partage de journaux s’ouvre sur le contrôleur HLK Windows ; le fichier journal Loadgen srv.log se trouve dans le partage.
Faites glisser et déposez le fichier srv.log dans le Bloc-notes.
Dans le Bloc-notes, faites défiler jusqu’au bas du fichier.
De bas en haut, recherchez la chaîne « Error - ». Le texte de la même ligne décrit l’échec. Vous devrez peut-être effectuer plusieurs recherches pour trouver la cause de l’échec. Les informations contenues dans le fichier journal fournissent uniquement un indicateur de haut niveau de l’échec.
Loadgen demande plus de clients
Si les clients existants ne peuvent pas générer suffisamment de stress par rapport au SUT, Loadgen demande davantage de clients stressants (SC). Cette fonctionnalité est destinée à prendre en charge les serveurs volumineux et la possibilité que certains contrôleurs de sécurité échouent au milieu d’une exécution. En général, vous devez commencer par huit contrôleurs de domaine. Le niveau de contrainte doit se stabiliser au cours des trois à quatre premières heures du test. Si davantage de clients sont nécessaires, vous verrez généralement la fenêtre contextuelle dans le contrôleur master (MC) dans cette période. Vous aurez soixante minutes pour ajouter un nouveau client ou le test se terminera et échouera.
Notes
Vous ne pouvez pas ajouter d’autres machines à un pool de machines après le démarrage d’une soumission. Si vous démarrez le test à l’aide de moins de huit clients, assurez-vous que vous avez des clients supplémentaires dans le pool d’ordinateurs avant de commencer à tester.
Si Loadgen demande plus de clients après quatre heures de test, cela signifie probablement que quelque chose a échoué. Un ou plusieurs des clients existants ont été supprimés, des problèmes de connectivité réseau se sont produits ou un autre problème empêche le SUT de détecter la charge d’utilisation requise de 40 %. Il peut s’agir d’un problème lié au pilote de carte réseau en combinaison avec la vitesse du réseau, ou à l’implémentation par le pilote de compteurs d’analyseur de performances dont dépend la mc Loadgen.
Dans ce cas, essayez les étapes de résolution des problèmes suivantes :
Pour exclure une défaillance matérielle temporaire dans la carte réseau, utilisez une carte réseau différente qui est le même modèle et le même fabricant.
Utilisez une carte réseau de modèle différente du même fabricant, mais qui utilise le même pilote.
Utilisez une carte réseau et un pilote d’un autre fabricant.
Si une ou plusieurs cartes réseau sont installées directement sur la carte système, accédez à la configuration du système matériel et désactivez la carte réseau à ce niveau afin que Windows ne la détecte pas ; utilisez ensuite un autre périphérique et un autre pilote pour le test.
Si plusieurs cartes réseau sont installées directement sur la carte système et que vous ne pouvez pas installer un appareil supplémentaire dans un emplacement PCI Express, accédez à la configuration du système matériel et désactivez toutes les cartes d’interface réseau, sauf une, afin que Windows ne les détecte pas.
Notes
Chaque carte réseau détectée doit être stressée pendant le test. Pour cela, chaque carte réseau doit avoir des contrôleurs de sécurité sur un segment de réseau physique distinct.
Les commutateurs qui ont des fonctionnalités avancées intégrées peuvent interférer avec le test de différentes façons. Par exemple :
Un commutateur peut avoir la possibilité de ralentir les ports du commutateur s’il détecte des paquets supprimés ou d’autres erreurs sur un port. Si une carte réseau 10GigE sur le SUT est destinée à recevoir le trafic résultant du ralentissement de tous les ports à 1 GigE, le test Loadgen ne peut pas atteindre le niveau d’utilisation de la bande passante réseau de 40 % requis pour réussir le test.
Un commutateur peut acheminer le trafic ou segmenter le réseau en réponse à des règles et une logique internes au commutateur (comme l’équilibrage de charge, la redondance, la qualité de service (QoS), la mise en miroir, le duplex et . opération simplex, pontage adaptatif ou intelligent, hiérarchisation des ports ou filtrage MAC), qui peut avoir un impact sur le niveau d’utilisation de la bande passante réseau sur une carte réseau.
Error=0x80004005
Si vous recevez l’erreur suivante : Main::RunMain:: Test Check, Spsrv s’est arrêté et n’a pas réussi le pourcentage de réussite requis (100) (Error=0x80004005). Dans ce cas, procédez comme suit :
Fermez Windows HLK Studio.
Remplacez le nom de l’ordinateur SUT par 15 caractères ou moins.
Redémarrez le SUT.
Ouvrez Windows HLK Studio et réexécutez le test LoadGen Server Stress - Start Test for Server .
Tests de contrainte du serveur
Lorsque vous effectuez des tests de contrainte du serveur, assurez-vous que l’infrastructure réseau qui connecte le SUT aux contrôleurs de domaine et à la mc peut s’exécuter au niveau de l’interface réseau carte (NIC) dans le SUT. Si un SUT a une ou plusieurs cartes réseau 10GigE, les contrôleurs de sécurité et l’infrastructure réseau doivent respecter ce niveau de performances.
Assurez-vous que l’infrastructure réseau qui connecte dhcp, DNS, Active Directory, contrôleur Windows HLK, Windows HLK Studio, SUT, SCS et MC fonctionne correctement. Tous les systèmes doivent communiquer entre eux à l’aide d’un nom d’hôte ou d’une adresse IP. Cela peut être confirmé à l’aide d’un test ping simple.
Assurez-vous que le ou les serveurs DHCP, DNS et Active Directory fonctionnent correctement. Il ne doit y avoir aucun enregistrement DNS obsolète. Le serveur DHCP doit être autorisé à fonctionner sur le réseau, la configuration doit être correcte, les étendues DHCP doivent être correctes, il ne doit pas y avoir de multihébergement incorrect et il ne doit y avoir aucune erreur dans le journal des événements système DHCP. Le contrôleur de domaine Active Directory ne doit signaler aucune erreur et le service de temps doit être synchronisé sur tous les systèmes.
Utilisation de machines virtuelles dans l’environnement de test
Il n’y a aucun problème connu par les systèmes DHCP, DNS, AD et d’autres systèmes qui se trouvent dans une machine virtuelle. Des problèmes peuvent se produire si des contrôleurs de sécurité s’exécutent sur une machine virtuelle. Ces problèmes sont généralement liés à la génération de charge de bande passante réseau. Pour éviter les problèmes, vérifiez que la configuration suivante est configurée :
Chaque machine virtuelle SC doit disposer d’une carte réseau physique dédiée pour placer la charge sur le réseau connecté à la carte réseau SUT.
Au minimum, vous devez avoir des cartes réseau physiques qui sont affinités avec les machines virtuelles SC qui sont capables d’au moins deux fois la bande passante maximale de la carte réseau SUT.
Assurez-vous que le ou les systèmes physiques utilisés pour les machines virtuelles SC ne sont pas surtressés par des niveaux élevés d’utilisation du processeur et qu’il existe suffisamment de mémoire physique pour toutes les machines virtuelles.