Dimensionnement et performances de la base de données

Date de publication : mars 2016

S’applique à : System Center 2012 SP1 - Orchestrator, System Center 2012 - Orchestrator, System Center 2012 R2 Orchestrator

Le dimensionnement de la base de données est essentiel à la compréhension des performances de System Center 2012 - 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 au déploiement d'Orchestrator peuvent être la résultante d'une mauvaise compréhension des types de données dans 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'intervention de l'opérateur Orchestrator s'appuie 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 Orchestration dépendent tous deux 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 :

• Des 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 croissance de la base de données, car les besoins en matière de stockage pour ce type de données sont réduits.

• Des données de journaux

  Orchestrator crée différents types de données de journaux, qui peuvent tous être affichés et gérés dans Runbook Designer. Les besoins en matière de stockage de ces données peuvent varier en taille et être importants.

  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 des données dans des fichiers journaux séparés (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 Journaux Orchestrator.

  Type de données de journaux	Emplacement dans Runbook Designer	Géré par Purge des journaux ?
  Journaux Runbook	Onglets Journal et Historique des journaux	Oui
  Événements d'activités (plate-forme)	Onglet Événements	Non
  Historique des audits	Onglet Historique des audits	Non

Code de plate-forme et code de domaine

Les activités du Runbook Orchestrator contiennent deux types de code :

• Le code de plate-forme

  Il s'agit du code commun partagé par la plupart des activités, utilisé pour exécuter des tâches courantes effectuées par les activités d'Orchestrator. Le code de plate-forme génère des données publiées communes.

• Le code de domaine

  Exécute diverses tâches spécifiques aux actions pour chaque activité, qui ne sont généralement pas associées à la plate-forme Orchestrator. Il peut éventuellement exister un écart important entre le code de plate-forme 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. Lors du premier appel d'un Runbook, celui-ci consiste en un thread unique. 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 communes

  Le jeu d'éléments de données communs à toutes les activités. Pour en obtenir la liste, voir la section Options du journal du Runbook dans Journaux 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.

  Astuce
  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.

Purge des journaux

Les options par défaut spécifiées pour la fonctionnalité Purge des journaux dans Runbook Designer permettent à l'utilisateur d'optimiser le déploiement initial d'Orchestrator. La modification de ces valeurs peut changer les caractéristiques des performances de l'environnement et doit être implémentée progressivement et avec une limite supérieure, afin que l'impact de la modification puisse être évalué.

Pour plus d'informations sur la purge automatique et manuelle des journaux, voir la section Purge des journaux de Runbook de Journaux Runbook.

Pour créer un simple Runbook pour tester l'augmentation de la journalisation, vous pouvez utiliser l'activité standard Comparer des valeurs pour créer des bancs d'essai d'un environnement Orchestrator.

La procédure suivante crée un simple Runbook qui exécute une activité Comparer des valeurs 10 000 fois.Comparer des valeurs est une activité très simple dont le code de domaine est relativement réduit. Ce Runbook peut être appelé dans différentes circonstances pour caractériser les performances globales d'un environnement d'exécution Orchestrator donné.

Pour créer un Runbook à utiliser pour effectuer un banc d'essai de votre environnement Orchestrator

1. Créez un nouveau Runbook.

2. Ajoutez une activité Compare Values à partir de la palette d'activités standard. Double-cliquez sur l'activité pour la configurer.

3. Cliquez sur l'onglet Général et configurez cette activité pour comparer des chaînes (la valeur par défaut).

4. Cliquez sur l'onglet Détails, tapez la valeur STRING dans la zone Test puis sélectionnez est vide.

5. Cliquez sur Terminer pour enregistrer les mises à jour de l'activité.

6. Cliquez avec le bouton droit sur l'activité et sélectionnez Boucle.

7. Cochez la case Activer et entrez le chiffre 0 (zéro) pour Délai entre les tentatives.

8. Cliquez sur l'onglet Quitter.

9. Modifiez la condition de sortie par défaut. Cliquez sur Comparer des valeurs, activez la case à cocher Afficher les données publiées communes, puis sélectionnez Boucle : Nombre de tentatives. Cliquez sur OK pour enregistrer cette modification.

10. Sélectionnez valeur dans la condition de sortie mise à jour et tapez le nombre 10000 (dix mille). Cliquez sur OK pour enregistrer cette modification.

11. Cliquez sur Terminer pour enregistrer ces mises à jour.

12. Cliquez sur Enregistrer 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.

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 exécutions de code de domaine peuvent être beaucoup plus longues. 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. Pour poursuivre avec l'exemple précédent, envisageons les coûts de code de plate-forme sur une activité de Runbook qui prend une minute à s'exécuter (1 minute = 60 000 millisecondes), indépendamment de son emplacement.

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, même si vous avez supprimé totalement les coûts du code de plate-forme, vous constatez des améliorations dans les performances du Runbook uniquement dans une fourchette comprise entre 1,4 % et 7,4 %.

Bien entendu, dans la plupart des cas, les scénarios réels sont différents. Le comportement des activités peut varier en fonction des instructions que reçoit le code de domaine. Par exemple, une activité Cloner un ordinateur virtuel à partir d'un modèle peut prendre une minute pour cloner un ordinateur virtuel à partir d'un modèle de serveur A, mais prendre 5 minutes pour cloner un ordinateur virtuel à partir d'un modèle de serveur B. En outre, les serveurs Runbook peuvent être hébergés sur des réseaux différents dotés de caractéristiques de performances différentes, qui peuvent potentiellement avoir un impact sur les performances du code de domaine ainsi que sur les performances de journalisation des données Orchestrator.

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 règle générale, les fichiers de base de données n'augmenteront pas leur taille à chaque fois qu'un Runbook est appelé. 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 exécution d'une activité de Runbook, celle-ci doit être répertoriée individuellement. Cela doit être pris en compte pour les fonctionnalités de boucle qui peuvent exécuter une même activité plusieurs fois.

• Pour déterminer la quantité de stockage nécessaire pour chaque appel du Runbook, multipliez le nombre d'activités du 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.

Exemple 1

Le tableau suivant présente les considérations en termes de dimensionnement de la base de données pour le déploiement d'Orchestrator.

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.

Cet exemple illustre clairement l'importance de la prise de décisions avisées pour la journalisation des données. Le Runbook 4 contient seulement huit activités, mais lorsqu'il est configuré au niveau de la journalisation des données publiées communes, il consomme la majeure partie du stockage dans la base de données en raison de la forte fréquence d'appel. D'après ces résultats, vous pouvez préférer réduire le niveau de journalisation du R‏unbook 4 à la configuration de journalisation par défaut.

Exemple 2

Le tableau suivant présente les considérations en termes de dimensionnement de la base de données pour un autre déploiement d'Orchestrator.

Le fait de recalculer les chiffres de stockage pour la configuration mise à jour produit des résultats très différents.

Bien que la valeur de configuration de la journalisation par défaut (500 entrées de journal par Runbook) change très peu, les besoins en termes de stockage pendant 30 jours ont considérablement changé. Il semble évident que le coût en termes de stockage de l'utilisation de la journalisation des données publiées communes pour le Runbook 4 doit être pris en compte, puisque ce changement entraîne une réduction de 76 % des besoins en stockage de base de données pour 30 jours de données.

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 comptant un petit nombre d'activités exécutées plusieurs fois peut engendrer un plus grand volume de journalisation des données qu'un Runbook plus important exécuté un nombre de fois moindre.

• N'activez pas la journalisation des données publiées spécifiques à l'activité dans des environnements de production. Utilisez-la uniquement à 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.

Journaux Orchestrator
Journaux Runbook
Architecture d'Orchestrator