Configuration Manager recommandations en matière de performances et de taille de site
S’applique à : Gestionnaire de Configuration (branche actuelle)
Configuration Manager chef de file du secteur en matière de mise à l’échelle et de performances. D’autres documents couvrent les limites de mise à l’échelle maximales prises en charge et les instructions matérielles pour l’exécution de sites avec les plus grandes tailles d’environnement. Cet article fournit des conseils supplémentaires sur les performances pour les environnements de toutes tailles. Ces conseils peuvent vous aider à estimer plus précisément le matériel dont vous avez besoin pour déployer Configuration Manager.
Cet article se concentre sur le plus grand contributeur à Configuration Manager goulots d’étranglement des performances : le sous-système d’entrée/sortie du disque ou les IOPS.
- Présente les détails et les résultats des tests axés sur les IOPS
- Explique comment reproduire les tests avec vos propres environnements et matériels
- Suggère des exigences d’IOPS de disque pour les environnements de différentes tailles
Méthodologie de test de performances
Vous pouvez déployer Configuration Manager de nombreuses façons uniques, mais il est important de comprendre quelques variables dans toutes les discussions de dimensionnement. Une variable est l’intervalle des caractéristiques, comme un cycle d’inventaire. Une autre variable est le nombre d’utilisateurs, de déploiements de logiciels ou d’autres objets que le système référence ou déploie. Les tests de performances appliquent ces variables dans le cadre d’une charge. La charge génère des objets à un rythme standard pour les clients d’entreprise utilisant des déploiements de production dans des environnements de taille différente.
Remarque
Les données d’utilisation des clients permettent de tester les builds Current Branch avec les scénarios, configurations et paramètres les plus courants pour la plupart des clients. Les recommandations de cet article sont basées sur ces moyennes. Vos expériences peuvent varier en fonction de la taille et de la configuration de votre environnement. En général, Configuration Manager nécessite du bon sens en ce qui concerne les objets et les intervalles. Le fait que vous pouvez collecter chaque fichier sur un système ou définir l’intervalle d’un cycle sur une minute ne signifie pas que vous devez le faire.
Les sections suivantes mettent en évidence certains paramètres et configurations clés à utiliser lors du test et de la modélisation des besoins de traitement pour les grandes entreprises. Ces instructions vous aident à définir des attentes de base en matière de performances système pour les tailles matérielles suggérées.
Paramètres des intervalles de fonctionnalité
La plupart des tests doivent utiliser des intervalles par défaut pour les cycles clés dans le système. Par exemple, les tests d’inventaire matériel se produisent une fois par semaine avec un fichier .mof supérieur à la valeur par défaut. Certains intervalles de fonctionnalités récurrents, en particulier les cycles d’inventaire matériel et logiciel, peuvent avoir des effets significatifs sur les caractéristiques de performances d’un environnement. Les environnements qui activent des intervalles par défaut agressifs pour la collecte de données ont besoin d’un matériel surdimensionné en proportion directe de l’augmentation de l’activité. Par exemple, supposons que vous avez 25 000 clients de bureau et que vous souhaitez collecter l’inventaire matériel deux fois plus rapidement que l’intervalle par défaut. Commencez par dimensionner le matériel de votre site comme si vous aviez 50 000 clients.
Objets
Les tests doivent utiliser la moyenne supérieure des objets que les grandes entreprises ont tendance à utiliser avec le système. Les valeurs classiques sont des milliers de collections et d’applications, qui sont déployées sur des centaines de milliers d’utilisateurs ou de systèmes. Les tests doivent s’exécuter simultanément sur tous les objets du système à ces limites. De nombreux clients utilisent plusieurs fonctionnalités, mais n’utilisent généralement pas toutes les fonctionnalités du produit à ces limites supérieures. Les tests avec toutes les fonctionnalités du produit permettent de garantir les meilleures performances possibles à l’échelle du système et permettent une mémoire tampon pour les fonctionnalités que certains clients peuvent utiliser au-dessus de la moyenne.
Charges
Les tests doivent également s’exécuter sur des charges quotidiennes supérieures à la moyenne standard, en effectuant des simulations qui génèrent des pics d’utilisation sur le système. Un exemple est la simulation des déploiements patch Tuesday, pour s’assurer que le système peut retourner rapidement les données de conformité de mise à jour pendant ces jours de pic d’activité. Un autre exemple est la simulation de l’activité du site lors d’une épidémie de programmes malveillants à grande échelle, pour garantir la possibilité d’une notification et d’une réponse en temps opportun. Bien que les machines déployées de la taille recommandée puissent être sous-utilisées un jour donné, des situations plus extrêmes nécessitent une mémoire tampon de traitement.
Configurations
Exécutez des tests sur une gamme de matériel physique, Hyper-V et Azure, avec un mélange de systèmes d’exploitation pris en charge et de versions SQL Server. Validez toujours les pires cas pour la configuration prise en charge. En général, Hyper-V et Azure retournent des résultats de performances comparables à du matériel physique équivalent lorsqu’ils sont configurés de la même façon. Les systèmes d’exploitation serveur actuels ont tendance à avoir des performances égales ou supérieures à celles des versions antérieures du système d’exploitation. Bien que toutes les plateformes prises en charge répondent à la configuration minimale requise, les dernières versions des produits de prise en charge tels que Windows et SQL Server produire de meilleures performances.
La plus grande variation provient des versions SQL Server en cours d’utilisation. Pour plus d’informations sur SQL Server versions, consultez Quelle version de SQL Server dois-je exécuter ?.
Déterminants clés du rendement
Vous pouvez tester et mesurer Configuration Manager performances avec différents types de paramètres, de différentes manières et à différentes tailles de site. Les paramètres et objets suivants peuvent affecter considérablement les performances. Veillez à les prendre en compte lors du test et de la modélisation des performances dans votre environnement.
Attention
Bien que peu d’aspects de Configuration Manager aient des limites d’interface utilisateur ou maximales officielles qui empêchent une utilisation excessive, aller au-delà des recommandations peut avoir des effets négatifs importants sur les performances d’un site. Le dépassement des niveaux recommandés ou l’ignorance des instructions de dimensionnement nécessitent généralement un matériel plus volumineux et peuvent rendre votre environnement inaccessible jusqu’à ce que vous réduisez la fréquence ou le nombre d’objets.
Inventaire du matériel
Pour tester les performances de base, définissez collection d’inventaire matériel sur une fois par semaine, avec la taille de fichier .mof par défaut plus environ 20 % d’autres propriétés. N’activez pas toutes les propriétés et collectez uniquement les propriétés dont vous avez réellement besoin. Portez une attention particulière lors de la collecte des propriétés, telles que la mémoire virtuelle disponible, qui changent toujours à chaque cycle d’inventaire. La collecte de ces propriétés peut entraîner une évolution excessive à chaque cycle d’inventaire de chaque client.
Inventaire de logiciels
Pour tester les performances de base, définissez la collecte de l’inventaire logiciel sur une fois par semaine, avec uniquement les détails du produit . La collecte de nombreux fichiers peut mettre à rude épreuve le sous-système d’inventaire. Évitez de spécifier des filtres susceptibles de collecter des milliers de fichiers sur de nombreux clients, tels que *.exe ou *.dll.
Collections
Les tests de performances de base peuvent inclure plusieurs milliers de collections avec différents types de paramètres d’étendue, de taille, de complexité et de mise à jour. Les performances du site ne sont pas une fonction directe du nombre de collections sur un site. Les performances sont également un produit croisé de la complexité des requêtes des collections, des mises à jour complètes et incrémentielles et de la fréquence des modifications, des dépendances entre les collections et du nombre de clients dans les collections.
Dans la mesure du possible, réduisez au minimum les regroupements qui ont des requêtes de règles dynamiques coûteuses ou complexes. Pour les regroupements qui nécessitent ces types de règles, définissez des intervalles de mise à jour et des durées de mise à jour appropriés afin de réduire l’impact de la réévaluation des regroupements sur le système. Par exemple, mettez à jour à minuit au lieu de 8h00.
L’activation des mises à jour incrémentielles sur les regroupements garantit des mises à jour rapides et rapides de l’appartenance au regroupement. Mais même si les mises à jour incrémentielles sont efficaces, elles continuent de charger le système. Équilibrez la fréquence de modification attendue avec la nécessité de mises à jour en quasi-temps réel sur l’appartenance. Par exemple, supposons que vous vous attendiez à une forte activité dans les membres du regroupement, mais que vous n’avez pas besoin de mises à jour d’appartenance en quasi-temps réel. Il est plus efficace et génère moins de charge sur le système pour mettre à jour le regroupement avec une mise à jour complète planifiée à un certain intervalle, que pour activer les mises à jour incrémentielles.
Lorsque vous activez les mises à jour incrémentielles, réduisez toutes les mises à jour complètes planifiées sur les mêmes regroupements. Il ne s’agit que d’une méthode d’évaluation de sauvegarde, car les mises à jour incrémentielles doivent maintenir l’appartenance à votre collection à jour en quasi-temps réel. Les meilleures pratiques pour les regroupements recommandent un nombre maximal de regroupements pour les mises à jour incrémentielles, mais comme le souligne l’article, votre expérience peut varier en fonction de nombreux facteurs.
Les regroupements avec uniquement des règles d’appartenance directe et avec un regroupement limitant qui n’effectue pas de mises à jour incrémentielles n’ont pas besoin de mises à jour complètes planifiées. Désactivez les planifications de mise à jour pour ces types de regroupements afin d’éviter une charge inutile sur le système. Si la limitation du regroupement utilise des mises à jour incrémentielles, les regroupements avec uniquement des règles d’appartenance directe peuvent ne pas refléter les mises à jour d’appartenance pendant jusqu’à 24 heures ou jusqu’à ce qu’une actualisation planifiée ait lieu.
Bien que ce ne soit pas une bonne pratique, certaines organisations créent des centaines, voire des milliers de collections dans le cadre de divers processus métier. Si vous utilisez l’automatisation pour créer des regroupements, il est important d’activer correctement toutes les mises à jour incrémentielles nécessaires. Réduisez et répartissez toutes les planifications de mise à jour complètes pour éviter les points chauds de l’évaluation du regroupement pendant une seule période. Établissez un processus de nettoyage régulier pour supprimer les collections inutilisées, en particulier si vous créez automatiquement des regroupements dont vous n’avez plus besoin après un certain temps.
N’oubliez pas que Configuration Manager crée des stratégies pour tous les objets de vos collections lorsque vous ciblez des tâches telles que des déploiements. Les changements d’appartenance, par le biais d’une actualisation planifiée ou de mises à jour incrémentielles, peuvent créer beaucoup plus de travail pour l’ensemble du système. Les dernières builds Current Branch ont des optimisations de stratégie spéciales pour les collections Tous les systèmes et Tous les utilisateurs. Lorsque vous ciblez l’ensemble de votre entreprise, utilisez les collections intégrées au lieu d’un clone de ces collections intégrées.
Pour examiner encore plus en détail les performances des regroupements, consultez l’évaluation du regroupement dans la console. Pour plus d’informations, consultez Guide pratique pour afficher l’évaluation des regroupements.
Méthodes de découverte
Pour les tests de performances de base, exécutez des méthodes de découverte basées sur le serveur une fois par semaine, en activant la découverte delta, le cas échéant, pour maintenir les données à jour pendant la semaine. Les tests doivent découvrir une quantité d’objets proportionnelle à la taille de l’entreprise simulée. Le test de la base de référence des performances pour la découverte de pulsations doit également s’exécuter une fois par semaine.
Les données de découverte sont des données globales. Un problème courant lié aux performances consiste à mal configurer les méthodes de découverte basées sur un serveur dans une hiérarchie, ce qui entraîne la détection en double des mêmes ressources à partir de plusieurs sites principaux. Configurez soigneusement les méthodes de découverte pour optimiser la communication avec le service cible, comme les contrôleurs de domaine Active Directory, tout en évitant la duplication de la même étendue de découverte sur plusieurs sites principaux.
Instructions générales sur le dimensionnement
Sur la base de la méthodologie de test de performances précédente, le tableau suivant fournit des instructions générales relatives à la configuration matérielle minimale pour un nombre spécifique de clients managés. Ces valeurs doivent permettre à la plupart des clients avec le nombre spécifié de clients de traiter des objets assez rapidement pour administrer le site spécifié. La puissance de calcul continue de diminuer en prix chaque année, et certaines des exigences ci-dessous sont faibles pour les configurations matérielles de serveur modernes. Le matériel qui dépasse les recommandations suivantes augmente proportionnellement les performances pour les sites qui nécessitent plus de puissance de traitement ou qui ont des modèles d’utilisation de produits spéciaux.
| Clients de bureau | Type/rôle de site | Cores Note 1 | Mémoire (Go) | allocation de mémoire SQL Server Remarque 2 | IOPS : Boîtes de réception Note 3 | IOPS : SQL Server Note 3 | Espace de stockage requis (Go) Remarque 4 |
|---|---|---|---|---|---|---|---|
| 25k | Principal ou site d’administration centrale avec le rôle de site de base de données sur le même serveur | 6 | 24 | 65% | 600 | 1700 | 350 |
| 25k | Principal ou SITE d’administration centrale | 4 | 8 | 600 | 100 | ||
| SQL Server à distance | 4 | 16 | 70% | 1700 | 250 | ||
| 50 000 | Principal ou site d’administration centrale avec le rôle de site de base de données sur le même serveur | 8 | 32 | 70% | 1200 | 2800 | 600 |
| 50 000 | Principal ou SITE d’administration centrale | 4 | 8 | 1200 | 200 | ||
| SQL Server à distance | 8 | 24 | 70% | 2800 | 400 | ||
| 100 000 | Principal ou site d’administration centrale avec le rôle de site de base de données sur le même serveur | 12 | 64 | 70% | 1200 | 5000 | 1100 |
| 100 000 | Principal ou SITE d’administration centrale | 6 | 12 | 1200 | 300 | ||
| SQL Server à distance | 12 | 48 | 80 % | 5000 | 800 | ||
| 150k | Principal ou site d’administration centrale avec le rôle de site de base de données sur le même serveur | 16 | 96 | 70% | 1800 | 7400 | 1600 |
| 150k | Principal ou SITE d’administration centrale | 8 | 16 | 1800 | 400 | ||
| SQL Server à distance | 16 | 72 | 90 % | 7400 | 1200 | ||
| 700k | Site d’administration centrale avec le rôle de site de base de données sur le même serveur | 20+ | 128+ | 80 % | 1800+ | 9000+ | 5000+ |
| 700k | CAS | 8+ | 16+ | 1800+ | 500+ | ||
| SQL Server à distance | 16+ | 96+ | 90 % | 9000+ | 4500+ | ||
| 5k | Site secondaire | 4 | 8 | 500 | - | 200 | |
| 15k | Site secondaire | 8 | 16 | 500 | - | 300 |
Remarques sur les instructions générales de dimensionnement
Remarque 1 : Cœurs
Configuration Manager exécute de nombreux processus simultanés, il a donc besoin d’un certain nombre minimal de cœurs de processeur pour différentes tailles de site. Bien que les cœurs soient plus rapides chaque année, il est important de s’assurer qu’un certain nombre minimal de cœurs fonctionnent en parallèle. En général, tout processeur de niveau serveur produit après 2015 répond aux besoins de performances de base pour les cœurs spécifiés dans le tableau. Configuration Manager tire parti d’autres cœurs au-delà des recommandations. Une fois que vous avez le minimum de cœurs suggérés, hiérarchisez l’investissement en ressources processeur pour augmenter la vitesse des cœurs existants. N’ajoutez pas de cœurs plus lents. Par exemple, Configuration Manager offre de meilleures performances sur les tâches de traitement clés avec 16 cœurs rapides qu’avec 24 cœurs plus lents. Ces performances supposent qu’il existe suffisamment d’autres ressources système telles que les IOPS de disque.
La relation entre les cœurs et la mémoire est également importante. En général, le fait d’avoir moins de 3 à 4 Go de RAM par cœur réduit la capacité de traitement totale sur vos serveurs SQL Server. Vous avez besoin de plus de RAM par cœur lorsque SQL Server est colocalisé avec les composants du serveur de site.
Remarque
Tous les tests définissent les plans d’alimentation de la machine pour permettre une consommation et des performances maximales de l’UC.
Remarque 2 : allocation de mémoire SQL Server
Utilisez cette valeur pour configurer la mémoire maximale du serveur (en Mo) dans les propriétés du SQL Server. Il s’agit du pourcentage de la quantité totale de mémoire disponible sur le serveur.
Ne configurez pas les valeurs minimale et maximale de la même façon. Ces conseils concernent spécifiquement la mémoire maximale que vous devez autoriser SQL Server à allouer.
Remarque 3 : IOPS : Boîtes de réception et IOPS : SQL
Ces valeurs font référence aux besoins en IOPS pour les lecteurs logiques Configuration Manager et SQL Server. La colonne IOPS : Boîtes de réception affiche les exigences d’IOPS pour le lecteur logique avec les répertoires de boîte de réception Configuration Manager. La colonne IOPS : SQL indique le nombre total d’IOPS nécessaires pour le ou les lecteurs logiques utilisés par différents fichiers SQL Server. Ces colonnes sont différentes, car les deux lecteurs doivent avoir une mise en forme différente. Pour plus d’informations et pour obtenir des exemples sur les configurations de disque SQL Server suggérées et les meilleures pratiques en matière de fichiers, notamment pour plus d’informations sur le fractionnement des fichiers sur plusieurs volumes, consultez le FAQ sur le dimensionnement et les performances du site.
Ces deux colonnes d’IOPS utilisent les données de l’outil standard diskspd. Pour obtenir des instructions sur la duplication de ces mesures, consultez Comment mesurer les performances du disque . En général, une fois que vous répondez aux exigences de base en matière de processeur et de mémoire, le sous-système de stockage a le plus grand impact sur les performances du site, et les améliorations apportées ici donnent le plus de retour sur investissement.
Remarque 4 : Espace de stockage requis
Ces valeurs réelles peuvent différer des autres recommandations documentées. Nous fournissons ces chiffres uniquement à titre indicatif; les exigences individuelles peuvent varier considérablement. Planifiez soigneusement les besoins en espace disque avant l’installation du site. Supposons qu’une certaine quantité de ce stockage reste sous forme d’espace disque libre la plupart du temps. Vous pouvez utiliser cet espace de mémoire tampon dans un scénario de récupération ou pour les scénarios de mise à niveau qui nécessitent de l’espace disque libre pour l’extension du package d’installation. Votre site peut nécessiter davantage de stockage pour de grandes quantités de collecte de données, des périodes plus longues de conservation des données et de grandes quantités de contenu de distribution de logiciels. Vous pouvez également stocker ces éléments sur des volumes distincts à débit inférieur.
Comment mesurer les performances du disque
Vous pouvez utiliser l’outil standard Diskspd pour fournir des suggestions standardisées pour les E/S par seconde nécessaires aux environnements de Configuration Manager de différentes tailles. Bien que non exhaustives, les étapes de test et les lignes de commande suivantes fournissent un moyen simple et reproductible d’estimer le débit du sous-système de disque de vos serveurs. Vous pouvez comparer vos résultats aux IOPS minimales recommandées dans la table des instructions de dimensionnement général .
Pour obtenir les résultats des tests de différents types de configurations matérielles dans des environnements de laboratoire, consultez Exemples de configurations de disque. Vous pouvez utiliser les données pour un point de départ approximatif lors de la conception du sous-système de stockage pour un nouvel environnement à partir de zéro.
Guide pratique pour tester les IOPS de disque
Téléchargez l’utilitaire Diskspd.
Vérifiez que vous disposez d’au moins 100 Go d’espace disque libre. Désactivez les applications susceptibles d’interférer ou d’entraîner une charge supplémentaire sur le disque, comme l’analyse antivirus active du répertoire, SQL ou SMSExec.
Exécutez Diskspd à partir d’une invite de commandes avec élévation de privilèges.
Exécutez l’outil deux fois dans l’ordre pour le volume que vous souhaitez tester. Le premier test à une taille de 64k avec des opérations d’écriture aléatoires pendant une minute. Ce test valide le chargement du cache du contrôleur et l’allocation d’espace disque, au cas où le volume se développe dynamiquement. Ignorez les résultats du premier test. Le deuxième test doit immédiatement suivre le premier test et effectuer le même chargement pendant cinq minutes.
Par exemple, utilisez les lignes de commande spécifiques suivantes pour tester le
G:volume.DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat del G:\\test\testfile.dat DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.datPassez en revue la sortie du deuxième test pour trouver le nombre total d’E/S par seconde dans la colonne E/S par seconde. Dans l’exemple suivant, le nombre total d’IOPS est de 3929,18.
Total IO | thread | bytes | I/Os | MB/s | I/O per s | AvgLat | LatStdDev | |--------|-------------|---------|--------|-----------|--------|-----------| | 1 | 9651814400 | 147275 | 30.68 | 490.92 | 16.294 | 10.210 | | 2 | 9676652544 | 147654 | 30.76 | 492.18 | 16.252 | 9.998 | | 3 | 9638248448 | 147068 | 30.64 | 490.23 | 16.317 | 10.295 | | 4 | 9686089728 | 147798 | 30.79 | 492.66 | 16.236 | 10.072 | | 5 | 9590931456 | 146346 | 30.49 | 487.82 | 16.398 | 10.384 | | 6 | 9677242368 | 147663 | 30.76 | 492.21 | 16.251 | 10.067 | | 7 | 9637330944 | 147054 | 30.64 | 490.18 | 16.319 | 10.249 | | 8 | 9692577792 | 147897 | 30.81 | 492.99 | 16.225 | 10.125 | | Total: | 77250887680 | 1178755 | 245.57 | 3929.18 | 16.286 | 10.176 |
Exemples de configurations de disque
Les tableaux suivants présentent les résultats de l’exécution des étapes de test dans Comment mesurer les performances du disque avec différentes configurations de laboratoire de test. Utilisez ces données pour un point de départ approximatif lors de la conception du sous-système de stockage pour un nouvel environnement à partir de zéro.
Machines physiques et Hyper-V
Le matériel s’améliore constamment. Attendez-vous à ce que les nouvelles générations de matériel et différentes combinaisons matérielles, comme les DISQUES SSD et les SAN, dépassent les performances indiquées ci-dessous. Ces résultats constituent un point de départ de base à prendre en compte lors de la conception d’un serveur ou de la discussion avec votre fournisseur de matériel.
Le tableau suivant présente les résultats des tests sur différents sous-systèmes de disque, y compris les disques durs basés sur une broche et un disque SSD, dans différentes configurations de laboratoire de test. Toutes les configurations formatent les disques avec des clusters de 64 Ko et les attachent à un contrôleur de disque de classe entreprise. En plus du nombre de disques de la matrice RAID, ils ont chacun au moins un disque de rechange.
| Type de disque | Nombre de disques, sans compter +1 disque de rechange | RAID | IOPS mesurées |
|---|---|---|---|
| 15 000 SAS | 2 | 1 | 620 |
| 15 000 SAS | 4 | 10 | 1206 |
| 15 000 SAS | 6 | 10 | 1751 |
| 15 000 SAS | 8 | 10 | 2322 |
| 15 000 SAS | 10 | 10 | 2882 |
| 15 000 SAS | 12 | 10 | 3476 |
| 15 000 SAS | 16 | 10 | 4236 |
| 15 000 SAS | 20 | 10 | 5148 |
| 15 000 SAS | 30 | 10 | 7398 |
| 15 000 SAS | 40 | 10 | 9913 |
| SSD SATA | 2 | 1 | 3300 |
| SSD SATA | 4 | 10 | 5542 |
| SSD SATA | 6 | 10 | 7201 |
| SSD SAS | 2 | 1 | 7539 |
| SSD SAS | 4 | 10 | 14346 |
| SSD SAS | 6 | 10 | 15607 |
Le tableau suivant répertorie les appareils spécifiques utilisés dans cet exemple. Ces informations ne sont pas recommandées pour un modèle matériel ou un fabricant spécifique.
| Type de disque | Modèle | Contrôleur RAID | Mémoire et configuration du cache |
|---|---|---|---|
| 15 k RPM SAS HD | HP EH0300JDYTH | Smart Array P822 | 2 Go, 20 % lecture / 80 % écriture |
| SSD SATA | ATA MK0200GCTYV | Smart Array P420i | 1 Go, 20 % lecture / 80 % écriture |
| SSD SAS | HP MO0800 JEFPB | Smart Array P420i | 1 Go, 20 % lecture / 80 % écriture |
Performances des machines et des disques Azure
Les performances des disques Azure dépendent de plusieurs facteurs, tels que la taille de la machine virtuelle Azure, ainsi que le nombre et le type de disques qu’elle utilise. Azure ajoute également constamment de nouveaux types de machines et de nouvelles vitesses de disque qui diffèrent du graphique suivant. Pour plus d’informations sur Configuration Manager s’exécutant sur Azure et sur la compréhension des E/S de disque sur Azure, consultez Configuration Manager forum aux questions sur Azure.
Tous les disques sont formatés avec une taille de cluster NTFS 64 Ko, et les lignes avec plusieurs disques sont configurées en tant que volumes entrelacés via l’utilitaire Gestion des disques Windows.
| Machine virtuelle Azure | Disque Azure | Nombre de disques | Espace disponible | IOPS mesurées | Facteur de limitation |
|---|---|---|---|---|---|
| DS2/DS11 | P20 | 1 | 512 Go | 965 | Taille de machine virtuelle Azure |
| DS2/DS11 | P20 | 2 | 1 024 Go | 996 | Taille de machine virtuelle Azure |
| DS2/DS11 | P30 | 1 | 1 024 Go | 996 | Taille de machine virtuelle Azure |
| DS2/DS11 | P30 | 2 | 2 048 Go | 996 | Taille de machine virtuelle Azure |
| DS3/DS12/F4S | P20 | 1 | 512 Go | 1994 | Taille de machine virtuelle Azure |
| DS3/DS12/F4S | P20 | 2 | 1 024 Go | 1992 | Taille de machine virtuelle Azure |
| DS3/DS12/F4S | P30 | 1 | 1 024 Go | 1993 | Taille de machine virtuelle Azure |
| DS3/DS12/F4S | P30 | 2 | 2 048 Go | 1992 | Taille de machine virtuelle Azure |
| DS4/DS13/F8S | P20 | 1 | 512 Go | 2334 | Disque P20 |
| DS4/DS13/F8S | P20 | 2 | 1 024 Go | 3984 | Taille de machine virtuelle Azure |
| DS4/DS13/F8S | P20 | 3 | 1536 Go | 3984 | Taille de machine virtuelle Azure |
| DS4/DS13/F8S | P30 | 1 | 1 024 Go | 3112 | Disque P30 |
| DS4/DS13/F8S | P30 | 2 | 2 048 Go | 3984 | Taille de machine virtuelle Azure |
| DS4/DS13/F8S | P30 | 3 | 3 072 Go | 3996 | Taille de machine virtuelle Azure |
| DS5/DS14/F16S | P20 | 1 | 512 Go | 2335 | Disque P20 |
| DS5/DS14/F16S | P20 | 2 | 1 024 Go | 4639 | Disque P20 |
| DS5/DS14/F16S | P20 | 3 | 1536 Go | 6913 | Disque P20 |
| DS5/DS14/F16S | P20 | 4 | 2 048 Go | 7966 | Taille de machine virtuelle Azure |
| DS5/DS14/F16S | P30 | 1 | 1 024 Go | 3112 | Disque P30 |
| DS5/DS14/F16S | P30 | 2 | 2 048 Go | 6182 | Disque P30 |
| DS5/DS14/F16S | P30 | 3 | 3 072 Go | 7963 | Taille de machine virtuelle Azure |
| DS5/DS14/F16S | P30 | 4 | 4096 Go | 7968 | Taille de machine virtuelle Azure |
| DS15 | P30 | 1 | 1 024 Go | 3113 | Disque P30 |
| DS15 | P30 | 2 | 2 048 Go | 6184 | Disque P30 |
| DS15 | P30 | 3 | 3 072 Go | 9225 | Disque P30 |
| DS15 | P30 | 4 | 4096 Go | 10200 | Taille de machine virtuelle Azure |
Pour plus d’informations sur les disques actuellement disponibles, consultez Sélectionner un type de disque pour les machines virtuelles IaaS Azure.