Deadlocks vermeiden

Application Package Depot Product automation / Pipelines
1

Hallo zusammen

Wir beziehen ca. 40 Empirum-Pakete aus dem neo42 APC. Für eine einfache Handhabung und kurze Update-Zeit haben wir den Trigger aller Pakete auf die gleiche Uhrzeit gesetzt. Leider hat das zu etlichen Deadlocks beim produktiven Rollout geführt. Pakete wurden nicht ausgetauscht oder nur teilweise. Manche Zuweisungen fehlten auch komplett. Verteilungsoptionen wurden nicht richtig gesetzt.

Wir mussten alle Pakete auf einen Abstand von 5 Minuten umstellen, was ziemlich aufwändig war. Außerdem dauert der gesamte Updatevorgang nun 3 Stunden. Weil auch Pakete dazwischen sind, die gar keine Updates ausstehend haben.

Ist hier in Zukunft eine Optimierung angedacht?
Dass eventuell globale Trigger erstellt werden können, die dann wiederum diversen Paketen zugewiesen werden können. Die zugewiesenen Pakete werden nach und nach abgearbeitet, um Deadlocks zu vermeiden.
Oder falls es bei den einzelnen Triggern pro Paket bleibt, könnte man im Falle eines Deadlocks 5/10/20 Minuten später nochmal einen neuen Versuch starten.

1 „Gefällt mir“
2

Hallo @Benjamin

Eine spezielle Planung haben wir für das Thema noch nicht. Spontan finde ich die Idee gut verschiedene PAs in Gruppen zusammenzufassen und die Gruppe über einen Trigger seriell abzuarbeiten.

Wir nehmen das in unsere Überlegungen für den PA Rework auf.

Danke für das Feedback und Gruß
Marco

3

das Problem haben wir auch, aber es erledigt sich in der Regel am Folgetag; damit dauern natürlich die Rollouts länger und es tauchen vermeidbare Fehler in den Pipelines auf. Allerdings haben wir schon verschiedene Triggerzeiten aber manchmal laufen die Pakete so lange dass sie sich überschneiden.

Evtl. wäre es hilfreich eine Pause-Funktionm (ideal mit der Möglichkeit die Dauer anzugeben) zum Einfügen in die Pipelines einzuarbeiten. Dann könnte man die Laufzeit variabel gestalten?

4

Guten Morgen @AReinel

Die Idee finde ich als Zwischenlösung auch sehr gut. Bis wir einen Sleep Task haben würde ich es wie folgt lösen:

  1. Pipeline öffnen
  2. Eine neue Phasenvariable “SleepSeconds“ anlegen - am besten mit einem Defaultwert von 1
  3. Der Pipeline vor dem Deploy Task einen neuen “Inline-Skript ausführen“ Task für ein PowerShell Skript hinzufügen
  4. In den Argumenten “-Seconds <Phase.SleepSeconds>“ eingeben (ohne ““)
  5. Unter Skript dann folgende Zeilen:
param (
    [int]$Seconds
)

Start-Sleep -Seconds $Seconds
  1. Pipeline speichern
  2. Auf Produktautomatisierungen ¶ wechseln
  3. Rechte Maustaste auf die anzupassende PA → Bearbeiten
  4. Weiter bis zu den Variablen → SleepSeconds anpassen
  5. 8 + 9 für alle PAs mit unterschiedlichen Werten wiederholen

Gruß

Marco

1 „Gefällt mir“
5

Hallo Herr Altmann, vielen Dank für die schnelle Info. Das mache ich dann am Besten in der jeweiligen Pipeline direkt nach “Smart Update (Finden und Herunterladen der neuesten Paketversion eines Produkts.)”, oder?

6

Wie beschrieben würde ich es vor den jeweiligen Deploy Task legen.

1 „Gefällt mir“
7

Ah, danke für die Klarstellung, das hatte ich so nicht gelesen. Dann wird’s mehr Arbeit :-).
ein schönes Wochende.

8

Hallo, wir haben ebenfalls dieses Problem, dass sich laufende Pipelines überschneiden, und es dadurch zu Fehlern kommt. Wir haben aktuell 89 Produktautomatisierungen (2 Bridges - SCCM und Intune) mit Customized Logo’s, Dateien und Scripten in den Pipelines implementiert, auf die dann teilweise nicht zugriffen werden kann, weil sie durch die noch laufende Pipeline in Benutzung sind etc.
Ich habe es aktuell auch so gelöst, dass ich die Trigger im Abstand von 10 Minuten gesetzt habe. Dauert aber ein Pipelinelauf länger, kann es dennoch zum Überschneiden der Läufe kommen.
Mittlerweile lasse ich die PA’s nicht mehr jeden Tag laufen, sondern nur noch alle 2 Tage, da es sonst zu lange dauert, alle Pakete in einer Nacht durchlaufen zu lassen.

Mir erschließt sich daher der Sinn der in den vorherigen Beitragen genannten Pause innerhalb der Pipeline nicht. Dadurch verlängert sich ja nur der Lauf der PA aber nicht, dass ggf. eine weitere PA startet, während die vorher gestartete noch läuft?

Meines Erachtens bräuchte es eine Queue, in der die PA nacheinander gestartet werden. Vielleicht auch mehrere Queues oder Gruppen von “PAen”, welche ggf. , weil sie sich nicht gegenseitig behindern, parallel laufen können.

9

Hallo @Shirkan

Im Falle von @AReinel und @Benjamin handelt es sich um SQL Deadlocks in der Empirum Datenbank die dann auftreten, wenn sehr viele gleichzeitige Operationen in den Zuweisungs- und Konfigurationsgruppen durchgeführt werden. Da diese Operationen nur durchgeführt werden, wenn es tatsächlich eine neue Version gibt können theoretisch einige Pipelines sehr dicht nacheinander gestartet werden - gibt es dann eine neue Version im Portal, dann können individuelle Pausen vor den Deadlock Aktionen das Problem verhindern. Zusatz: Um dem Thema noch besser zu begegnen kann ich ankündigen, dass in der Version 4.5 ein Retry-Mechanismus für die betreffenden SQL Operationen implementiert ist. Das Problem ist damit zwar nicht aus der Welt, aber sollte es doch mal zu Überschneidungen kommen, dann sinkt die Wahrscheinlichkeit, dass der Task abbricht.

Da es bei dir scheinbar andere Ursachen hat müsste man individuell prüfen, ob man die Zugriffsprobleme anders lösen kann.

Grundsätzlich ist aber immer zu beachten, dass gleichzeitig gestartete Pipelines…

  1. beim Download die Netzwerkleitung überfordern können,
  2. beim Entpacken und Prüfen der Hashwerte die Festplatten und CPUs ans Limit gehen
  3. und der Upload ins Zielsystem dieses (und wieder das Netzwerk) überfordern könnte.

Das wir zukünftig PAs in Gruppen sammeln sollten, habe ich oben ja schon erwähnt.

Gruß
Marco

1 „Gefällt mir“