Dimensionnement et performances de la base de données
Le dimensionnement de la base de données est la clé pour comprendre les performances de System Center - Orchestrator. Les serveurs Runbook, le serveur management et les composants Web dépendent tous de la base de données Orchestrator pour leurs opérations. Les problèmes liés aux déploiements Orchestrator peuvent provenir d’une compréhension incomplète des types de données de la base de données et de leur gestion.
Puisque Runbook Designer communique avec la base de données Orchestrator (via le serveur management), les performances médiocres de la base de données font obstacle à cette communication.
L’expérience de l’opérateur Orchestrator est basée sur deux composants : la console Orchestration et le service web. La console Orchestration est une application Silverlight qui dépend du service Web pour sa connexion à la base de données Orchestrator. Le service Web est une application IIS qui se connecte à la base de données. Par conséquent, le service web et la console d’orchestration dépendent des performances de la base de données Orchestrator.
En outre, même si la console Orchestration dépend du service Web, elle possède aussi une logique unique à sa fonction d'interface utilisateur dotée de ses propres caractéristiques en termes de performances.
Données de configuration et données de journaux
À un niveau élevé, la base de données Orchestrator contient deux types de données :
Données de configuration
L’infrastructure Orchestrator contient des données de configuration. Ces données ne sont pas un problème dans le contexte de la croissance de la base de données, car les exigences de stockage pour ce type de données sont petites.
Des données de journaux
Orchestrator crée différents types de données de journal, qui peuvent toutes être consultées et gérées dans le Runbook Designer. Les exigences de stockage pour ces données peuvent varier en taille et peuvent être volumineuses.
Le tableau suivant répertorie les types de données de journal qui peuvent être stockées dans la base de données Orchestrator. Orchestrator stocke également les données dans des fichiers journaux distincts (en dehors de la base de données) pour les pistes d’audit et le suivi. Pour plus d'informations sur tous les types de données de journaux, voir Orchestrator Logs.
| Type de données de journaux | Emplacement dans Runbook Designer | Géré par Purge des journaux ? |
|---|---|---|
| Journaux Runbook | OngletsJournal et Journal History | Oui |
| Événements d'activités (plate-forme) | OngletÉvénements | Non |
| Historique d’audit | OngletHistorique des audits | Non |
Code de plate-forme et code de domaine
Les activités de runbook Orchestrator contiennent deux types de code distincts :
Code de plateforme
Il s’agit du code commun partagé par la plupart des activités et utilisé pour exécuter les tâches courantes effectuées par les activités Orchestrator. Le code de plate-forme génère des données publiées communes.
Code de domaine
Exécute différentes tâches spécifiques aux actions de chaque activité, qui ne sont généralement pas associées à la plateforme Orchestrator elle-même. Potentiellement, il peut y avoir une grande variation entre le code de plateforme et le code de domaine.
La journalisation des données générées pour une activité donnée peut contenir des éléments de données à valeur unique ou à valeurs multiples. Chaque activité génère un seul enregistrement de données à valeur unique. Le code de domaine peut générer plusieurs enregistrements de données à valeurs multiples ; il détermine par conséquent ce que fait l'activité des données publiées communes qu'elle a reçues d'activités précédentes.
Les Runbook Orchestrator sont essentiellement conçus pour transmettre des données entre des éléments distincts du code de domaine. En outre, le code de domaine peut éventuellement générer des données publiées spécifiques à une activité.
Tous les Runbook présentent des similarités dans la mesure où ils exécutent des activités composées de code de domaine et de code de plate-forme, ils analysent en boucle les flux de travail et créent une branche. La création de branche se produit lorsqu'un Runbook appelle d'autres Runbook pour effectuer une tâche spécifique. Lorsqu’un runbook est appelé pour la première fois, il se compose d’un seul thread. Lorsque ce thread rencontre une activité de Runbook dont les liens nécessitent une branche, des threads supplémentaires sont créés, un pour chaque branche. Chaque thread prend comme entrée les données publiées communes à partir de l'activité qui a créé la branche. Ces données sont corrélées avec les activités précédentes dans le Runbook pour mettre à jour les données publiées communes auxquelles les activités s'abonnent.
Le code de domaine affecte potentiellement les performances de la base de données davantage que le multithreading généré par la création de branche. La raison en est que le code de domaine peut générer potentiellement de grandes quantités de données publiées spécifiques à l'activité.
Options de journalisation
L'onglet Journalisation des Propriétés d'un Runbook permet éventuellement de stocker les entrées de journalisation. Le terme journalisation par défaut désigne le fait de n'avoir sélectionné aucune des deux options de données publiées, ce qui correspond à générer 524 octets par activité. Les options de journalisation prévoient deux catégories de données publiées communes :
Données publiées courantes
Le jeu d'éléments de données communs à toutes les activités. Pour obtenir une liste, consultez les options du journal du Runbook.
Cette option de journalisation génère 6 082 octets pour chaque activité.
Données publiées spécifiques à l’activité
Il s'agit du jeu de données spécifiques à l'activité qui est éventuellement créé par le code de domaine.
Cette option de journalisation génère 6 082 octets en plus des octets journalisés par des activités spécifiques.
Conseil
Cette option est sélectionnée principalement à des fins de débogage. Laissez-la désactivée pour limiter l'augmentation de la journalisation.
La définition des options de journalisation peut considérablement réduire les performances et accentuer la croissance de la base de données. Prenons un scénario dans lequel la même activité de Runbook est exécutée deux fois, une première avec la journalisation des données au niveau par défaut (aucune option de données publiées sélectionnée), une deuxième avec les données publiées communes sélectionnées. Le code de domaine doit prendre le même temps pour aboutir. Cependant, le code de plate-forme prendra plus longtemps à s'exécuter car il doit prendre en charge 12 fois la quantité de journalisation des données publiées communes qu'avec simplement la journalisation par défaut.
Vider les journaux
Les options par défaut spécifiées pour la fonctionnalité purge de journal dans le Runbook Designer sont configurées pour fournir la meilleure expérience utilisateur pour un déploiement Orchestrator prête à l’emploi. La modification de ces valeurs peut modifier les caractéristiques de performances de l’environnement et doit être implémentée progressivement et en filigrane élevé afin que l’effet de la modification puisse être évalué.
Pour plus d’informations sur la purge automatique et manuelle des journaux, consultez les journaux de runbook purgant.
Créer des benchmarks de performances
Pour créer un runbook simple pour tester la croissance de la journalisation, vous pouvez utiliser les valeurs de comparaison d’activités standard pour créer des benchmarks d’un environnement Orchestrator.
La procédure suivante crée un runbook qui exécute une activité Comparer les valeurs 10 000 fois. Compare Values est une activité simple dont le code de domaine est minimal. Ce runbook peut être appelé dans différentes circonstances pour caractériser les performances globales d’un environnement d’exécution Orchestrator donné.
Créer un runbook qui peut être utilisé pour évaluer votre environnement Orchestrator
Créez un nouveau Runbook.
Ajoutez une activité Compare Values à partir de la palette d'activités standard. Double-cliquez sur l'activité pour la configurer.
Sélectionnez l’onglet Général et configurez cette activité pour comparer les chaînes (la valeur par défaut).
Sélectionnez l’onglet Détails , entrez la valeur STRING dans la zone Test , puis sélectionnez vide.
Sélectionnez Terminer pour enregistrer les mises à jour de l’activité.
Cliquez avec le bouton droit sur l'activité et sélectionnez Boucle.
Cochez la case Activer et entrez le nombre 0 (zéro) pour le délai entre les tentatives.
Sélectionnez l’onglet Quitter .
Modifiez la condition de sortie par défaut. Sélectionnez Comparer les valeurs, cochez la case Afficher les données publiées courantes, puis sélectionnez Boucle : nombre de tentatives. Sélectionnez OK pour enregistrer cette modification.
Sélectionnez la valeur dans la condition de sortie mise à jour et entrez le nombre 10000 (dix mille). Sélectionnez OK pour enregistrer cette modification.
Sélectionnez Terminer pour enregistrer ces mises à jour.
Sélectionnez Point pour enregistrer les modifications apportées à la base de données Orchestrator.
Ce Runbook peut servir à tester différentes configurations d'Orchestrator. Par exemple, vous pouvez créer les Runbook de banc d'essai pour déterminer les performances de quatre serveurs Runbook déployés sur différents centres de données.
| Centre de données | Configuration de la journalisation | Temps d'exécution du code de plate-forme (millisecondes) | Millisecondes par activité | Facteur d'échelle |
|---|---|---|---|---|
| Emplacement 1 | journalisation par défaut | 819 | 82 | 1,0 (référence) |
| Emplacement 1 | Journalisation des données publiées communes | 2012 | 201 | 2.5 |
| Emplacement 2 | journalisation par défaut | 1229 | 123 | 1.5 |
| Emplacement 2 | Journalisation des données publiées communes | 3686 | 369 | 4.5 |
| Emplacement 3 | journalisation par défaut | 2457 | 426 | 3.0 |
| Emplacement 3 | Journalisation des données publiées communes | 4422 | 442 | 5.4 |
| Emplacement 4 | journalisation par défaut | 1474 | 147 | 1.8 |
| Emplacement 4 | Journalisation des données publiées communes | 2654 | 265 | 3.2 |
Remarquez la diminution considérable des performances de la plate-forme provoquée par la journalisation des données publiées communes. Le pire scénario semble être la journalisation des données publiées communes à l'emplacement 2. À première vue, cela semble être une conclusion claire et pertinente.
Toutefois, il convient de noter que ces chiffres correspondent à la surcharge du code de plate-forme, pas du code de domaine. Les runtimes de code de domaine peuvent être plus longs. Par exemple, l'activité Créer un ordinateur virtuel à partir d'un modèle du pack d'intégration de Virtual Machine Manager peut s'exécuter pendant plusieurs minutes lors de la création de l'ordinateur virtuel. En développant l’exemple précédent, considérez les coûts de code de plateforme sur une activité de runbook qui prend 1 minute pour s’exécuter (1 minute = 60 000 millisecondes), quel que soit l’emplacement.
| Centre de données | Configuration de la journalisation | Temps d'exécution du code de plate-forme (millisecondes) | % de code de domaine | % de code de plate-forme |
|---|---|---|---|---|
| Emplacement 1 | journalisation par défaut | 819 | 98,6 % | 1,4 % |
| Emplacement 1 | Journalisation des données publiées communes | 2012 | 96,7 % | 3,3 % |
| Emplacement 2 | journalisation par défaut | 1229 | 98,0 % | 2,0 % |
| Emplacement 2 | Journalisation des données publiées communes | 3686 | 93,9 % | 6,1 % |
| Emplacement 3 | journalisation par défaut | 2457 | 95,9 % | 4,1 % |
| Emplacement 3 | Journalisation des données publiées communes | 4422 | 92,6 % | 7,4 % |
| Emplacement 4 | journalisation par défaut | 1474 | 97,5 % | 2,5 % |
| Emplacement 4 | Journalisation des données publiées communes | 2654 | 95,6 % | 4,4 % |
Une image plus claire commence à émerger des données. Le scénario selon lequel la journalisation des données publiées communes est activée à l'emplacement 2 continue de présenter les pires performances. Toutefois, le code de la plate-forme et la journalisation représentent seulement 6 % du temps total d'exécution. Même si ce chiffre est intéressant, le scénario idéal est de 1,4 %. Essentiellement, le temps passé dans le code de domaine dans l'exemple compense largement le temps passé à exécuter le code de plate-forme. Pour mettre cela en perspective, si vous étiez en mesure d’éliminer complètement les coûts de code de la plateforme, vous ne verrez que les améliorations des performances des runbooks dans la plage de 1,4 % à 7,4 %.
La plupart des scénarios réels seront différents. Le comportement des activités peut varier en fonction des instructions que reçoit le code de domaine. Par exemple, une machine virtuelle clone à partir d’une activité de modèle peut prendre une minute pour cloner une machine virtuelle à partir du modèle de serveur A, mais prendre 5 minutes pour cloner une machine virtuelle à partir du modèle de serveur B. En outre, les serveurs Runbook peuvent résider sur différents réseaux avec différentes caractéristiques de performances, ce qui peut affecter les performances du code de domaine et les performances de journalisation des données Orchestrator.
Déterminer la croissance de la base de données
L'administrateur de votre base de données Orchestrator peut suivre les instructions suivantes pour déterminer la stratégie de croissance du fichier de base de données :
En général, les fichiers de base de données ne augmenteront pas de taille avec chaque appel d’un runbook. Les fichiers augmentent lorsque les données qu'ils contiennent atteignent la limite supérieure configurée par l'administrateur de la base de données, moment auquel la taille du fichier est généralement augmentée.
Chaque fois qu’une activité de runbook s’exécute, elle doit être comptabilisée individuellement, ce qui doit être pris en compte lorsque les fonctionnalités de bouclage peuvent entraîner l’exécution d’une seule activité plusieurs fois.
Pour déterminer le stockage nécessaire pour chaque appel du runbook, multipliez le nombre d’activités dans le runbook par le nombre d’octets ajoutés à la base de données en fonction du niveau de journalisation sélectionné. Ces valeurs sont les suivantes :
524 octets
Configuration de la journalisation par défaut.
6082 octets
Niveau de journalisation des données publiées communes.
6 082 octets + données journalisées par activité
Niveau de journalisation des données publiées spécifiques à l'activité.
Par défaut, Orchestrator purge tous les journaux sauf les 500 plus récents pour chaque runbook chaque nuit à 2 h 00. Pour déterminer le stockage requis pour chaque appel du runbook, multipliez le stockage pour chaque appel du runbook par 500. Si vous modifiez le paramètre Purge des journaux, multipliez chaque appel par le nombre estimé d'appels par jour, semaine ou mois en fonction des besoins.
Le tableau suivant présente les estimations en termes de croissance et de performances pour les configurations de niveau de journalisation.
| Niveau de journalisation | Facteur de croissance de la base de données | Facteur de performances | Recommandé pour la production |
|---|---|---|---|
| Par défaut | 1 | 1 | Oui |
| Données publiées communes | x 11,6 | x2,5 | Utilisation limitée avec la planification |
| Données publiées spécifiques à l'activité | Supérieur à x 11,6 | Supérieur à x 2,5 | Non |
Exemples
Exemple 1
Le tableau suivant décrit les considérations relatives au dimensionnement de la base de données pour un déploiement d’Orchestrator.
| Nom du Runbook | Nombre d'activités | Niveau de journalisation | Appels par jour |
|---|---|---|---|
| Runbook 1 | 50 | Par défaut | 100 |
| Runbook 2 | 25 | Par défaut | 50 |
| Runbook 3 | 12 | Données publiées communes | 24 |
| Runbook | 8 | Données publiées communes | 500 |
Si vous utilisez le dimensionnement de la taille de la base de données décrit ci-dessus, vous pouvez estimer les besoins de stockage pour les Runbook.
| Nom du Runbook | Octets par appel | Stockage en Mo Purge des journaux par défaut (500 appels) |
Appels par mois | Stockage en Mo Un mois (Pas la purge des journaux par défaut) |
% de stockage de base de données après 30 jours |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3 000 | 74,5 | %9 |
| Runbook 2 | 13 100 | 6.2 | 1 500 | 18,7 | %2 |
| Runbook 3 | 72 984 | 34,8 | 720 | 50,1 | %6 |
| Runbook | 48,656 | 23.2 | 15,000 | 696,0 | 83 % |
| Total : 76,7 Mo | Total : 839,3 Mo |
Cet exemple illustre clairement l'importance de la prise de décisions avisées pour la journalisation des données. Le Runbook 4 ne contient que huit activités, mais lorsqu’il est configuré au niveau de journalisation des données publiées commune, il consomme la plupart du stockage dans la base de données en raison de la fréquence élevée d’appel. En fonction de ces résultats, vous pouvez préférer réduire le niveau de journalisation du Runbook 4 à la configuration de journalisation par défaut.
Exemple 2
Le tableau suivant décrit les considérations relatives au dimensionnement de la base de données pour un autre déploiement d’Orchestrator.
| Nom du Runbook | Nombre d'activités | Niveau de journalisation | Appels par jour |
|---|---|---|---|
| Runbook 1 | 50 | Par défaut | 100 |
| Runbook 2 | 25 | Par défaut | 50 |
| Runbook 3 | 12 | Données publiées communes | 24 |
| Runbook | 8 | Par défaut | 500 |
Le fait de recalculer les chiffres de stockage pour la configuration mise à jour produit des résultats très différents.
| Nom du Runbook | Octets par appel | Stockage en Mo Purge des journaux par défaut (500 appels) |
Appels par mois | Stockage en Mo Un mois (Pas la purge des journaux par défaut) |
% de stockage de base de données après 30 jours |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3 000 | 74,5 | 37 % |
| Runbook 2 | 13 100 | 6.2 | 1 500 | 18,7 | %9 |
| Runbook 3 | 72 984 | 34,8 | 720 | 50,1 | 25% |
| Runbook | 4 192 | 2.0 | 15,000 | 60,0 | 29 % |
| Total : 55,5 Mo | Total : 203,3 Mo |
Bien qu’il y ait peu de modifications dans la configuration de journalisation par défaut (500 entrées de journal par runbook), les exigences de stockage de 30 jours ont changé considérablement. Clairement, le coût de stockage de l’utilisation de la journalisation commune des données publiées pour Runbook 4 doit être soigneusement pris en compte, car cette modification entraîne une réduction de 76 % des exigences de stockage de base de données pendant 30 jours de données.
Résumé
Tenez compte des conseils suivants pour gérer les performances et le dimensionnement de la base de données :
Activez la journalisation des données publiées communes uniquement si c'est indispensable.
N'oubliez pas que le nombre d'exécutions d'activités détermine le volume des données journalisées. Un petit runbook avec quelques activités exécutées plusieurs fois peut entraîner plus de journalisation des données qu’un runbook plus grand exécuter un nombre inférieur de fois.
N’activez pas la journalisation des données publiées spécifiques à l’activité dans les environnements de production et ne doivent être utilisées qu’à des fins de débogage.
Comprenez bien le temps que passent vos Runbook à exécuter du code de domaine par rapport au code de plate-forme.
Estimez les coûts en termes de code de plate-forme en utilisant les techniques décrites dans ce document. Utilisez-les comme référence pour décider où apporter des améliorations aux performances des Runbook.
Identifiez les opportunités d'amélioration du produit par des comparaisons normalisées de vos mesures.
Voir aussi
- Journaux d’activité d’orchestrateur.
- Architecture Orchestrator.