Orchestration multi-machines avec des tâches PowerShell et des espaces d'exécution

Quand tu commences à faire Automatisation à grande échelle avec PowerShellTôt ou tard, vous vous heurterez au même problème : les scripts séquentiels ont leurs limites. Arrêter des dizaines de machines, appliquer des correctifs à des centaines de serveurs ou traiter des téraoctets de fichiers dans un seul thread, c’est la garantie de perdre des heures… voire des jours.

La bonne nouvelle, c'est que PowerShell offre plusieurs façons de orchestrer le travail en parallèle sur plusieurs machinesTâches, espaces d'exécution, pools d'espaces d'exécution, flux de travail et manuels d'exécution sur des plateformes comme Service Management Automation ou Azure Automation : choisir le bon outil et savoir les combiner fait toute la différence. scénario qui « fonctionne » et une solution véritablement évolutive et robuste.

Pourquoi avez-vous besoin d'une orchestration multi-machines dans PowerShell ?

Dans des scénarios réels, tels que Appliquer un correctif et redémarrer un ensemble de serveurs Windows, désactiver les instances de plusieurs Machines virtuelles Exécuter les tâches une par une, que ce soit simultanément ou en analysant 10 To de données pour localiser des vidéos, revient à supposer que… le temps Peu importe. Avec une simple boucle, PowerShell fera l'affaire, certes, mais le goulot d'étranglement sera terrible.

Quand on parle de envoyer des commandes simultanées à plusieurs nœudsIl existe trois défis majeurs : comment lancer des tâches en parallèle sans se perdre dans la synchronisation, comment maintenir une bonne scalabilité sans surcharger le système d’orchestration, et comment filtrer les événements critiques et de nouvelles tentatives sans perdre l'état de ce que vous avez déjà fait.

Options de parallélisme dans PowerShell : tâches, espaces d’exécution et flux de travail

PowerShell offre plusieurs mécanismes pour exécuter le travail en parallèleChacune de ces options présente des avantages et des inconvénients. De manière générale, vous pouvez choisir des tâches traditionnelles, des espaces d'exécution (et des pools d'espaces d'exécution) ou des flux de travail PowerShell en fonction de Fenêtres Workflow Foundation, qui s'intègre à son tour aux manuels d'exécution d'automatisation.

Les emplois PowerShell Ils sont faciles à utiliser et très pratiques pour les tâches d'arrière-plan simples, mais ne constituent pas l'option la plus performante pour optimiser les performances. Pour les scénarios de concurrence plus exigeants, les espaces d'exécution et leurs pools permettent un contrôle précis des threads, tandis que les workflows et les runbooks ajoutent une orchestration avancée, une résilience accrue et une exécution distribuée.

Runspaces et RunspacePool : la base du parallélisme fin

Un espace d'exécution n'est rien de plus qu'un Environnement d'exécution PowerShell intégré à votre processus .NET. Vous pouvez en créer un, le charger commandesExécutez-les et fermez le contexte. Si vous créez de nombreux espaces d'exécution indépendants avec la même configuration, vous gaspillez des ressources en initialisations répétées.

Pour éviter ce gaspillage, il existe RunspacePool (System.Management.Automation.Runspaces.RunspacePool) est un groupe d'espaces d'exécution partageant des caractéristiques communes. Au lieu de générer des centaines d'espaces d'exécution « individuels », vous créez un pool et laissez PowerShell réutiliser efficacement ces contextes, ce qui améliore considérablement les performances dans les environnements à forte charge.

Exemple pratique d'utilisation de RunspacePool depuis C#

Imaginez que vous vouliez lancer une commande comme Obtenir-Process wmi* Depuis une application hôte C#, exécutez ces commandes de manière asynchrone en utilisant un pool d'espaces d'exécution. Le processus reste le même : créer le pool, l'ouvrir, y associer un objet PowerShell, ajouter des commandes, les exécuter de manière asynchrone et récupérer le résultat.

En C#, la logique serait basée sur Créez le pool avec RunspaceFactory.CreateRunspacePool()Ouvrez-le et montez un objet PowerShell auquel ce pool est attribué dans la propriété RunspacePool. Ajoutez ensuite la commande avec AddCommand("Get-Process").AddArgument("wmi*") et appelez BeginInvoke pour démarrer l'exécution asynchrone, puis collectez les résultats avec EndInvoke dans un objet PSDataCollection. .

Une fois cette collection constituée, vous pouvez parcourir chaque PSObject et extraire les propriétés tels que ProcessName et Id pour les afficher dans la console ou les traiter selon les besoins, par exemple pour gérer les processus et les tâches sous WindowsCette approche illustre comment utiliser le même pool d'espaces d'exécution pour différentes invocations, évitant ainsi la création et la destruction massives et inefficaces d'espaces d'exécution.

Parallélisation des tâches gourmandes en espace disque : exemple d’analyse de 10 To

Un cas très typique est celui d'une personne qui, avec une simple Obtenir-ChildItem -RécursivitéCe script parcourt un volume important (par exemple, Y:\ de 10 To) à la recherche de fichiers vidéo (.mp4, .avi, .mkv) et les filtre par extension. Il peut se limiter à parcourir l'intégralité du volume, à appliquer un filtrage avec Where-Object et à afficher le chemin complet.

Le problème survient lorsque ce même script est exécuté sur une arborescence de répertoires gigantesque : Le temps d'exploration devient inacceptablePour obtenir de meilleures performances, l'idée logique est de fragmenter le travail en plusieurs threads : par exemple, entre 5 et 10 threads, chacun analysant un sous-ensemble de dossiers ou de lecteurs réseau.

Une stratégie raisonnable consisterait à ce qu'un premier espace d'exécution gère collecter et stocker les dossiers Dans un tableau partagé, un deuxième espace d'exécution sera dédié au filtrage des fichiers vidéo contenus dans ces dossiers, et un troisième sera responsable de déplacer les fichiers déjà classifiés jusqu'à sa destination. Cette division en étapes (découverte des itinéraires, filtrage des types, déplacement du contenu) permet la modularisation et la parallélisation du flux.

Pour implémenter une telle chose en PowerShell pur, vous pouvez utiliser espaces d'exécution manuels ou modules comme PoshRSJob qui simplifient une partie de la complexité, mais le concept reste le même : diviser l’arborescence des répertoires en blocs, lancer plusieurs threads en parallèle et synchroniser le résultat sans chevauchement des ressources ni saturation du système de fichiers.

Exécuter des fonctions en parallèle pour arrêter plusieurs machines

Un autre scénario classique est celui d'un script qui arrête les instances sur plusieurs machines virtuellesCependant, l'opération se fait séquentiellement car chaque instance possède sa propre fonction et ses commandes spécifiques. Pendant qu'une machine virtuelle s'arrête, les autres attendent leur tour, ce qui prolonge inutilement la période de maintenance.

Pour éviter ce goulot d'étranglement, la solution idéale est lancer chaque fonction d'arrêt comme une tâche parallèle Vous pouvez aussi utiliser des espaces d'exécution qui appellent des fonctions en parallèle. La différence par rapport aux tâches traditionnelles réside dans le fait qu'avec les espaces d'exécution, vous pouvez mieux contrôler le nombre maximal de threads actifs et la manière dont les données sont partagées entre eux.

Si vous souhaitez uniquement une concurrence de base, vous pouvez utiliser Tâches PowerShell pour déclencher toutes les fonctions simultanément Il suffit ensuite d'attendre la fin de leur exécution. Pour un contrôle plus précis des performances et de la réutilisation du contexte, un RunspacePool permet, par exemple, d'exécuter cinq threads en parallèle pour arrêter des machines, au lieu de surcharger l'hôte avec des dizaines de processus indépendants.

Orchestration des correctifs et des redémarrages sur de nombreux serveurs Windows

Qui vient du monde Linux avec Ansible et Python Il a généralement une compréhension très claire du concept d'exécution massivement parallèle, mais lorsqu'il se penche sur PowerShell, il se retrouve face à plusieurs options éparses : flux de travail, tâches, espaces d'exécution, sans vraiment savoir par où commencer pour corriger et redémarrer simultanément un grand nombre de serveurs.

Le problème classique est un script qui gère un seul serveur par itérationCela implique d'appliquer des correctifs, de redémarrer et d'attendre le rétablissement du service. Si vous avez des dizaines ou des centaines de nœuds, cette approche séquentielle devient impraticable. Pour y remédier, vous pouvez utiliser le travail à distance, les espaces d'exécution ou directement les flux de travail PowerShell avec des constructions parallèles telles que ForEach -Parallel.

Lorsque vous travaillez également avec regroupements et dépendances entre les nœudsVous avez besoin non seulement de parallélisme, mais aussi d'une logique d'orchestration : par exemple, pour empêcher le redémarrage simultané de tous les nœuds d'un cluster. C'est là qu'un workflow bien conçu, ou un runbook dans Azure Automation ou Service Management Automation, peut vous simplifier la tâche en définissant clairement les séquences et le parallélisme.

Automatisez l'intégration en masse à Azure Arc avec Configuration Manager

Dans un environnement hybride, il est très fréquent de vouloir Connectez un grand nombre de serveurs Windows ou Linux à Azure Arc. L'utilisation de Configuration Manager (ConfigMgr / SCCM) permet, par défaut, d'exécuter des scripts PowerShell sur des groupes de périphériques, ce qui en fait un outil très utile pour l'orchestration multi-machines.

Avec un seul script PowerShell, vous pouvez Automatisez le processus d'intégration à Azure Arc sur tous les serveurs répondant aux exigences. Avant toute chose, il est conseillé de vérifier que votre abonnement et vos ressources respectent les conditions (régions prises en charge, limitations, etc.) et de consulter les recommandations de conception et de surveillance pour les déploiements à grande échelle sur Azure.

Un détail important est la fonction de La connexion automatique des instances SQL Server est activée pour Azure Arc.Si vous connectez un serveur compatible Arc sur lequel SQL Server est déjà installé, les instances SQL peuvent être automatiquement enregistrées auprès d'Arc, offrant ainsi des fonctionnalités avancées d'inventaire et de gestion. bases de données et moteur.

Dans le cadre de ce processus, déploie une extension sur le serveur connecté De nouveaux rôles et autorisations sont attribués à SQL Server et aux bases de données. Si vous préférez que ces serveurs SQL ne se connectent pas automatiquement, vous pouvez l'empêcher en ajoutant une étiquette au serveur Windows ou Linux nommé ArcSQLServerExtensionDeployment avec la valeur « Disabled » avant ou pendant l'intégration.

Prérequis pour l'exécution de scripts PowerShell à partir de Configuration Manager

Pour profiter de Exécution de scripts PowerShell via ConfigMgrPour ce faire, vous devez respecter certaines exigences de version et d'autorisation. Assurez-vous d'abord d'utiliser Configuration Manager 1706 ou une version ultérieure, car les versions antérieures ne disposent pas de cette fonctionnalité de script intégrée.

En matière de sécurité, le compte que vous utilisez doit avoir autorisations de création sur « Scripts SMS » Cela vous permet d'importer et de définir de nouveaux scripts. De plus, l'approbation des scripts est distincte de leur création : seuls les comptes disposant de l'autorisation « Approuver les scripts SMS » peuvent approuver ou refuser les scripts destinés à la production.

Pour enfin procéder à l'exécution des recouvrements, le compte a besoin Autorisations d'exécution de script pour « Collections »Un autre point clé consiste à examiner la configuration PowerShell par défaut dans l'agent d'équipe ConfigMgr, en vérifiant que la stratégie d'exécution est définie sur « Ignorer », afin que les scripts puissent s'exécuter sans blocage inutile.

Génération du principal de service et du script d'installation pour Azure Arc

Avant de lancer le script en masse depuis Configuration Manager vers ajouter des serveurs à Azure ArcVous devez préparer deux éléments : un principal de service disposant des autorisations appropriées et le script d’installation généré à partir du portail Azure.

Premièrement, vous devez suivre les étapes suivantes : Créer un service principal spécifique pour l'intégration de masseAttribuez-lui le rôle « Intégration de la machine connectée Azure » ​​et limitez son périmètre à la zone d’atterrissage correspondante dans Azure. Il est essentiel de sauvegarder le secret client du client principal, car vous devrez l’intégrer ou y faire référence ultérieurement dans le script d’installation.

Ensuite, dans le portail Azure, script d'installation de l'extension Azure Arc Pour les machines connectées. Ce script ne doit pas être exécuté directement dans PowerShell à ce stade, mais sera enregistré pour être importé ou collé dans l'assistant de configuration des scripts de Configuration Manager, où il sera adapté par l'ajout du secret du principal de service.

Créez, approuvez et exécutez le script dans Configuration Manager

Une fois votre script Azure Arc prêt, l'étape suivante est : Enregistrez le script dans ConfigMgrDepuis la console, dans la zone Bibliothèque de logiciels, vous pouvez accéder au nœud Scripts et utiliser l'option Créer un script pour démarrer l'assistant.

Dans cet assistant, vous définissez un nom reconnaissable pour le script (Par exemple, « Intégrer Azure Arc »), sélectionnez PowerShell comme langage et utilisez l’option d’importation pour charger le fichier généré sur le portail Azure ou collez directement son contenu. C’est ici que vous modifiez le texte du script pour y intégrer le secret du principal de service que vous avez créé précédemment.

Une fois l'assistant terminé, le script apparaîtra dans la liste avec le statut suivant : « En attente d’approbation »Avec un utilisateur autorisé à approuver les scripts, retournez au nœud Scripts, sélectionnez le script souhaité et choisissez Approuver ou Refuser. Dans la boîte de dialogue, sélectionnez Approuver, suivez les instructions de l'assistant et vérifiez que le statut du script passe à « Approuvé ».

Pour lancer le script sur un ensemble d'appareilsAccédez à la section Ressources et conformité, puis à Collections de périphériques. Sélectionnez la collection souhaitée (par exemple, « Tous les serveurs compatibles Arc ») et cliquez sur Exécuter le script. Dans l’assistant, choisissez le script que vous avez créé et approuvé. Une fois l’opération terminée, Configuration Manager exécutera le script sur tous les périphériques de la collection.

L'état de cette exécution peut contrôle à partir des vues de surveillance du scriptCela vous indiquera si l'agent de machine connectée a été correctement installé sur chaque serveur. Les machines qui se connectent avec succès apparaîtront ensuite dans le portail Azure en tant que serveurs compatibles avec Azure Arc.

Runbooks et flux de travail PowerShell dans Automation

Au-delà de ConfigMgr, de nombreuses organisations utilisent Automatisation de la gestion des services ou automatisation Azure Pour gérer des tâches d'orchestration complexes, les runbooks PowerShell Workflow constituent la pierre angulaire de ces environnements : des scripts écrits en syntaxe PowerShell, mais exécutés sur Windows Workflow Foundation.

La structure d'un manuel d'exécution d'automatisation basé sur un flux de travail est pratiquement identique pour SMA et pour Azure AutomationBien qu'ils fonctionnent généralement sur des ressources différentes (sur site ou dans le cloud), grâce à l'intégration avec Workflow Foundation, ces manuels d'exécution offrent un parallélisme natif, des points de contrôle avec persistance d'état et la possibilité de reprendre après des échecs.

Un flux de travail PowerShell est déclaré avec le mot-clé Flux de travail suivi du nomet encadre ses commandes d'accolades. Ce nom doit correspondre au nom du runbook et, s'il est importé d'un fichier, également au nom du fichier .ps1. La méthode habituelle consiste à suivre le modèle verbe-nom standard de PowerShell.

Structure, paramètres et limitations des flux de travail

Pour accepter les entrées, le flux de travail utilise un bloc Paramètre PowerShell traditionnelVous pouvez y définir les paramètres obligatoires ou facultatifs à l'aide de l'attribut suivi du type et du nom du paramètre. Ces valeurs seront demandées lors de l'exécution du runbook depuis le portail ou l'API.

Bien que le flux de travail soit écrit avec la même syntaxe de base qu'un script PowerShellL'exécution proprement dite est réalisée via Windows Workflow Foundation, ce qui introduit certaines limitations et différences de comportement. Il est important de consulter la documentation relative aux différences syntaxiques entre les workflows et les scripts afin d'éviter les mauvaises surprises liées à des commandes non prises en charge ou à des comportements particuliers.

De nombreuses cmdlets PowerShell standard sont Elles deviennent automatiquement des activités de workflow Lorsqu'elles sont exécutées dans un flux de travail, le moteur les intègre automatiquement dans une activité InlineScript pour celles qui ne disposent pas d'activité équivalente. Sinon, si elles figurent dans la liste des cmdlets exclues, vous devrez les placer explicitement sous un bloc InlineScript.

Activités, modules d'intégration et chargement automatique

Au sein d'un flux de travail, chaque L'activité représente une tâche spécifiqueDe la même manière qu'un script est composé d'une ou plusieurs cmdlets, Windows Workflow Foundation contrôle l'exécution de ces activités, permettant des fonctionnalités telles que la reprise après un échec, la nouvelle tentative et l'exécution parallèle.

Les activités partagent un ensemble de paramètres de flux de travail communs (about_WorkflowCommonParameters), qui servent à ajuster son comportement, sa reprise, la persistance de son état, etc. De plus, Automation vous permet d'importer des modules d'intégration, qui sont simplement des packages basés sur des modules PowerShell avec leurs cmdlets correspondantes.

Comment l'automatisation repose sur PowerShell 4.0 avec chargement automatique des modulesTout module d'intégration importé devient accessible depuis tous les runbooks sans avoir à appeler explicitement `Import-Module`. Toutefois, veuillez noter que les modules présentant des dépendances externes (registre, chemins non standard, etc.) peuvent nécessiter une installation supplémentaire sur les serveurs Worker pour fonctionner correctement.

Si vous avez un module avec de nombreuses dépendances externes, vous pouvez créer un module portable utilisant New-SmaPortableModuleCe processus génère des stubs pour chaque cmdlet, redirigeant l'appel vers le module réel installé sur les serveurs de production. Cela permet aux runbooks de détecter ces cmdlets à des fins de conception et de saisie semi-automatique, même si la logique sous-jacente réside ailleurs.

Exécution parallèle dans les flux de travail PowerShell

L'un des principaux avantages des flux de travail est leur capacité à exécuter des commandes en parallèle de manière déclarativeAu lieu de construire manuellement des structures d'espace d'exécution complexes, vous pouvez utiliser les blocs Parallel et ForEach-Parallel, qui sont idéaux pour orchestrer des tâches de longue durée sur plusieurs serveurs.

Avec le mot-clé Parallel crée un bloc de commandes qui sont exécutées simultanément.Vous pouvez y placer plusieurs activités, qui démarreront simultanément. Une fois terminées, le flux se poursuit avec les activités suivantes, situées à l'extérieur du bloc. Cette fonctionnalité est idéale pour lancer des actions gourmandes en ressources sur plusieurs ressources sans qu'elles ne se bloquent mutuellement.

Avec la construction ForEach - Parallel traite les éléments d'une collection en parallèleChaque élément possède sa propre instance des activités du bloc, qui s'exécutent en parallèle mais séquentiellement au sein de chaque élément. Ce modèle est idéal pour appliquer la même procédure (par exemple, la mise à jour et le redémarrage) à un grand nombre de serveurs simultanément.

De plus, vous pouvez utiliser le mot-clé Séquence permettant de regrouper des commandes séquentielles au sein d'un bloc parallèleDe cette manière, plusieurs séquences complètes peuvent s'exécuter en parallèle, garantissant ainsi le respect de la logique interne de chaque séquence tout en tirant parti du parallélisme global du manuel d'exécution.

Points de contrôle et suspension du manuel d'exploitation

Une autre fonctionnalité clé des flux de travail est de points de contrôleUn point de contrôle est comme un instantané de l'état actuel du flux de travail : valeurs des variables, progression et résultats générés jusqu'à ce point. Il est stocké dans la base de données Automation et permet la reprise de l'exécution là où elle s'est arrêtée en cas de problème.

Pour créer un point de contrôle, l'activité est utilisée Flux de travail du point de contrôleL'état est enregistré lors de l'exécution. Si le runbook rencontre une erreur ultérieurement et reprend son exécution, il redémarrera à partir du dernier point de contrôle exécuté avec succès, évitant ainsi de répéter les opérations déjà effectuées.

Dans les scénarios où une activité peut échouer mais est Il est sûr et souhaitable de le répéter en cas d'échec. (par exemple, une tentative de création de machine virtuelleIl est donc conseillé de placer des points de contrôle avant et après ces commandes critiques. En cas d'échec de la création, le manuel d'exécution peut répéter cette section ; en cas de succès et d'échec ultérieur, la ressource ne sera pas recréée.

Vous pouvez également forcer explicitement le Suspendre un runbook avec Suspend-WorkflowCette action crée automatiquement un point de contrôle et interrompt immédiatement le flux, permettant par exemple d'effectuer une intervention manuelle entre deux phases d'automatisation. Un opérateur peut ensuite reprendre le processus à partir de ce point précis.

InlineScript : lorsque vous avez besoin de PowerShell « pur » au sein d’un flux de travail

L'activité InlineScript vous permet d'exécuter un bloc de code PowerShell « normal ». Au sein d'un flux de travail, dans une session distincte non gérée par Workflow Foundation, cette fonctionnalité s'avère très utile pour utiliser des cmdlets non directement prises en charge en tant qu'activités, ou lorsqu'une action ne peut être exécutée que localement sur un ordinateur spécifique.

InlineScript accepte le Paramètres de flux de travail courants tels que PSComputerName et PSCredentialCela vous permet d'envoyer votre bloc à une autre machine distante à l'aide d'identifiants spécifiques. Le processus classique consiste à récupérer une connexion ou des identifiants depuis Automation, à créer un objet PSCredential et à transmettre ces données à InlineScript pour exécuter des commandes sur l'hôte cible.

Cependant, plusieurs limitations sont à prendre en compte : Il est impossible de définir des points de contrôle dans InlineScript.Par conséquent, en cas d'erreur dans le script, la reprise du flux de travail relancera le bloc depuis le début. De plus, le maintien d'InlineScript actif pendant une période prolongée a un impact sur l'évolutivité, car il consomme une session PowerShell pendant toute sa durée d'exécution.

Ils ne sont pas non plus directement disponibles dans InlineScript. Certaines activités d'automatisation telles que Get-AutomationVariable ou Get-AutomationPSCredentialPour transmettre des données générées en dehors d'InlineScript au bloc, le modificateur de portée $Using est utilisé (par exemple, $using:myVariable), et pour récupérer les données de sortie, le résultat d'InlineScript est affecté à une variable dans le flux de travail.

La recommandation générale est minimiser la portée d'InlineScriptDéplacez les boucles for/foreach en dehors de ces blocs, n'y définissez pas de flux de travail et limitez l'utilisation d'InlineScript aux portions de code nécessitant une exécution PowerShell « pure ». Cela permet au flux de travail de reprendre et de s'exécuter en parallèle sans surcharger le système.

En combinant intelligemment les tâches, les espaces d'exécution (et leurs pools), les scripts en masse avec Configuration Manager et les flux de travail ou runbooks d'automatisation, vous pouvez créer un stratégie d'orchestration multi-machines robuste avec PowerShell qui évolue de manière transparente, exploite le parallélisme de façon contrôlée et est capable de se remettre des erreurs sans perdre d'état ni dupliquer le travail, aussi bien dans les environnements sur site que dans le cloud hybride avec Azure Arc.