Powershell Funktion Pipeline oder nicht
Hi@All,
ich steh grad vor der Entscheidung ob pipeline oder nicht.
Momentan führe ich Scripte immer Blockweise aus den Servern aus und das nacheinander bis die Farm durch ist.
Jetzt bin ich dabei das schick zu machen inkl. zu parallelisieren, also die ersten 5 Server, dann die nächsten usw..
Ablauf:
- Server 1-5 führen Script aus
- lesen Dienste
- lesen platten ein
- parsen spezielle Logfiles
- liefern zusammengebautes PSCustomObject zurück
- schreibe die erhaltenen Daten in XML, SQL whatever
- fange von vorn an, wenn noch Server übrig
Macht es Generell Sinn Funktionen zu pipelinen?
VG
ich steh grad vor der Entscheidung ob pipeline oder nicht.
Momentan führe ich Scripte immer Blockweise aus den Servern aus und das nacheinander bis die Farm durch ist.
Jetzt bin ich dabei das schick zu machen inkl. zu parallelisieren, also die ersten 5 Server, dann die nächsten usw..
Ablauf:
- Server 1-5 führen Script aus
- lesen Dienste
- lesen platten ein
- parsen spezielle Logfiles
- liefern zusammengebautes PSCustomObject zurück
- schreibe die erhaltenen Daten in XML, SQL whatever
- fange von vorn an, wenn noch Server übrig
Macht es Generell Sinn Funktionen zu pipelinen?
VG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 338997
Url: https://administrator.de/forum/powershell-funktion-pipeline-oder-nicht-338997.html
Ausgedruckt am: 16.04.2025 um 10:04 Uhr
12 Kommentare
Neuester Kommentar
Servus.
.
Schau dir mal Workflows an. Ein schönes Beispiel zum parallelen Abfragen der Eventlogs aller Server der Domain findest du hier mit einem Workflow:
An- und Abmelde Ereignisse mit Powershell auslesen
Grüße Uwe
Macht es Generell Sinn Funktionen zu pipelinen?
Wenn es Aufgaben sind die lange laufen und sich eine Beschleunigung durch Parallelisierung lohnt, sicher. Wieso 5 mal länger warten wenn 5 Server gleichzeitig die Aufgabe in einem 5tel der Zeit erledigen können Schau dir mal Workflows an. Ein schönes Beispiel zum parallelen Abfragen der Eventlogs aller Server der Domain findest du hier mit einem Workflow:
An- und Abmelde Ereignisse mit Powershell auslesen
Grüße Uwe
Dann viel Spaß
, aber nicht verzweifeln hier gibt es einige Fallstricke die einen echt Nerven kosten können.
Das ThrottleLimit ist nur begrenzt durch die Ressourcen der Maschine auf der das Script gestartet wird?
Das ist abhängig davon was das Script so alles macht, mehr Threads wie Prozessorkerne macht oftmals keinen Sinn, mit 5 Threads habe ich hier mit einem etwas älteren 8-Kerner die besten Erfahrungen gemacht, ist für den Anfang ein guter Start mit dem du nicht viel falsch machen kannst, das kann bei dir aber ganz anders aussehen. Mehr Threads sind nicht immer die beste Wahl das musst du bei dir evaluieren und ausprobieren was für eure Aufgaben am effektivsten ist.Müsste er nicht an der Stelle was ausgeben?
Ja.Oder wird ein PSCustomObject innerhalb des bInlineScriptes enötigt?
Nein das ist keine Bedingung.Das was du im Workflow in den Outputstream ausgibst ohne das du es in einer Variablen zwischenspeicherst landet im Output des Workflows.
Btw. würde hier ein
Get-Service -Name '*OSD PXE*'
auch reichen.Wenn es bei solch kurzen Aktionen bleibt brauchst du keinen Workflow, da würde eigentlich auch ein
Invoke-Command
mit den Servernamen als Array und dem Parameter -AsJob als Einzeiler reichen.Invoke-Command -ComputerName "Server1","Server2" -ScriptBlock {Get-Service -Name '*OSD PXE*'} -AsJob | Receive-Job -Wait -AutoRemoveJob
Grüße Uwe
Wenn ich das nun in dem inneren foreach aufdrieseln möchte bekomme ich immer die Meldung das er _DienstName nicht hinzufügen kann weil es bereits vorhanden sei.
Klar, weil es schon einen Member mit dem Eigenschaften-Namen im Custom-Object gibt, ein angehängtes -Force beseitigt die Meldung. Normalerweise erstellt man einmal zu Beginn die Member des Objects ausserhalb der Schleife und fügt dann nur noch die custom Objects hinzu, oder man erstellt eben ein leeres Array und fügt die Customobjects mit [pscustomobject] und einer Hashtable dem Array hinzu.