Vorgänge in der Warteschlange für Anwendungen
CICD-APIs, die die instanzweite Sperre/den Mutex für die Aktualisierung abrufen müssen, um die angeforderten Vorgänge auszuführen, werden in die Warteschlange gestellt, anstatt abgelehnt zu werden, wenn die instanzweite Sperre/der Mutex für die Aktualisierung durch andere Vorgänge belegt ist.
Ab Tokyowerden die CICD-APIs, die zum Ausführen der angeforderten Vorgänge die instanzweite Sperre/den Mutex für die Aktualisierung abrufen müssen, nicht abgelehnt, wenn die instanzweite Sperre/der Mutex für die Aktualisierung durch andere Vorgänge belegt ist. Wenn eine CICD-Anforderung empfangen wird, erstellt der entsprechende CICD-Service eine NowMQ-Nachricht für einen Anwendungsvorgang (Now Message Queue) und fügt die Nachricht mithilfe von NowMQ-APIs in die Warteschlange ein. Die Nachrichten in der Warteschlange werden dann von der geplanten Aufgabe abgefragt und einzeln oder parallel verarbeitet, wenn die Parallelverarbeitung aktiviert ist und der Vorgang die erforderlichen Kriterien erfüllt.
NowMQ-Nachricht zum Anwendungsvorgang
Die NowMQ-Nachrichten zum Anwendungsvorgang haben einen gemeinsamen Betreff: „sys.applifecycle.operation“. Der Nachrichtentext der NowMQ-Nachricht zum Anwendungsvorgang enthält ein JSON-Objekt mit der sys_id des Ausführungstrackers (dies wird auch als Fortschritts-ID bezeichnet, die in der CICD-API-Antwort zurückgegeben wird) und kann einen der folgenden Vorgangstypen ausführen: app_install, „plugin_activation“, „batch_install“, „rollback“, „import_app“ und „apply_changes“. Es enthält auch die Informationen wie Plugin-ID für die Plugin-Aktivierung, App-ID oder Bereich für die Anwendungsinstallation.
Ausführungstracker für Anwendungsvorgänge
Wenn die NowMQ-Nachricht zum Anwendungsvorgang erstellt und eingefügt wird, wird der Ausführungstracker-Datensatz für die entsprechende CICD-Anforderung erstellt, und dessen sys_id wird dem Textkörper der NowMQ-Nachricht hinzugefügt. Der Ausführungstracker befindet sich zunächst im Status Ausstehend. Die Spalte „Details“ des Ausführungstrackers enthält Informationen über den Vorgangstyp und wichtige Eingabeparameter für die CICD-Anforderung. Die Spalte „Nachricht“ enthält Informationen zur Position der Warteschlange. Wenn die Warteschlange angehalten ist, wird der Nachricht das Präfix „[Warteschlange für App-Vorgänge ist angehalten]“ vorangestellt.
Beispiel für die Ausführungstracker von Anwendungsvorgängen, wenn die Warteschlange ausgeführt wird.
Beispiele für die Ausführung von Anwendungsvorgängen bei angehaltener Warteschlange.
Verwalten Sie die Warteschlange für Anwendungsvorgänge
Während die manuelle Installation von Produkten aus „Alle Anwendungen“ in die Warteschlange gestellt wird, wird die manuelle Installation einer Anwendung über eine Anwenderoberfläche wie „Alle Anwendungen“ oder „Anwendungsmanager“ nicht in die Warteschlange gestellt.
Manchmal empfängt die Instanz viele CICD-Anforderungen, stellt sie in die Warteschlange und verarbeitet sie, was dazu führen kann, dass die manuelle Installation über die Anwenderoberfläche nach der Aktualisierung der instanzweiten Sperre/des Mutex sucht. In diesem Fall kann der Administrator die Warteschlange für Anwendungsvorgänge vorübergehend anhalten.
Administratoren können die Warteschlange für Anwendungsvorgänge über die UI-Seite „Systemdiagnose -> Warteschlange für Anwendungsvorgänge“ verwalten. Im Bereich „Status der Vorgangswarteschlange“ kann der Administrator die Warteschlange anhalten oder fortsetzen. Administratoren können auch den Tracker für die ausstehende Ausführung abbrechen. Dadurch wird die entsprechende Nachricht in der Warteschlange durch den Auftrag zur Überwachung der Integrität der App-Vorgangswarteschlange aus NowMQ entfernt.
UI-Seite für die Warteschlange für Anwendungsvorgänge
Beispiel für eine UI-Seite für Anwendungsvorgänge. Der Administrator kann auf die Schaltfläche unter „Status der Vorgangswarteschlange“ klicken, um die Warteschlange anzuhalten oder fortzusetzen.
Klicken Sie auf das Listenelement „Ausführungstracker für Anwendungsvorgänge“. Das Formular „Ausführungstracker“ wird geöffnet. Wenn die Nachricht in der Warteschlange aussteht, aktualisieren Sie den Status des Ausführungstrackers in „Abgebrochen“, und speichern Sie die Änderung, um die entsprechende CICD-Anforderung in der Warteschlange abzubrechen. Hinweis: Wenn der Status des Ausführungstrackers „Wird ausgeführt“ ist, kann die CICD-Anforderung nicht abgebrochen werden.
Warteschlange für Anwendungsvorgänge und Upgrade-Zeitfenster
Standardmäßig werden 2 Stunden (kann über die Systemeigenschaft „com.glide.update_operation.queue_upgrade_window“ angepasst werden) vor dem geplanten Upgrade von der Warteschlange für Anwendungsvorgänge die Verarbeitung von Nachrichten in der Warteschlange beendet.
Der Status der Warteschlange für Anwendungsvorgänge wird in „Upgrade angehalten“ geändert. Während dieses Upgrade-Zeitfensters werden weiterhin neue CICD-Anforderungen in die Warteschlange gestellt.
Wenn das Upgrade abgeschlossen ist, nimmt die Warteschlange für Anwendungsvorgänge die Verarbeitung der Nachrichten in der Warteschlange automatisch wieder auf.
Auswirkung auf CICD-Pipeline
Die vorhandenen Anforderungs-/Antwortverträge für die CICD APIs werden nicht geändert. Der Vorgangsfehler aufgrund von instanzweiten Sperren-/Mutex -Konflikten, die in einem Release vor Tokyo beobachtet wurden, wird nicht angezeigt. Die Anforderung wird in die Warteschlange gestellt und je nach Auftragstyp einzeln oder parallel bearbeitet.
CICD-APIs, die Warteschlangen unterstützen
- api/sn_cicd/app_repo/install
- api/sn_cicd/v1/app_repo/install
- api/sn_cicd/v2/app_repo/install
- API/sn_cicd/app_repo/rollback
- api/sn_cicd/v1/app_repo/install
- API/sn_cicd/v2/app_repo/rollback
- API/sn_cicd/sc/apply_changes
- API/sn_cicd/v1/sc/apply_changes
- API/sn_cicd/v2/sc/apply_changes
- api/sn_cicd/app/batch/install
- api/sn_cicd/sc/import
- api/sn_cicd/plugin/{plugin_id}/activate
- api/sn_cicd/plugin/{plugin_id}/rollback
Anwendungsinstallationen und Plugin-Aktivierungen parallelisieren
- api/sn_cicd/app_repo/install
- api/sn_cicd/v1/app_repo/install
- api/sn_cicd/v2/app_repo/install
- api/sn_cicd/plugin/{plugin_id}/activate
Die gesamte Warteschlangenverarbeitung nimmt eine instanzweite Sperre/einen Mutex und hält diesen Mutex, bis ein Vorgang in der Warteschlange abgeschlossen ist. Diese Sperre wird als UpdateMutexbezeichnet, und ihr Status kann in der Tabelle „ sys_mutex “ eingesehen werden. Während dieser Zeit können Vorgänge, für die dieselbe Sperre gilt (App-Installationen, Plugin-Aktivierungen, Quellcodeverwaltungsvorgänge), nicht über die Anwenderoberfläche ausgeführt werden. Die Warteschlange kann weiterhin über die Seite „Warteschlange für Anwendungsvorgänge “ angehalten werden, um die Sperre freizugeben, nachdem aktuell ausgeführte Aufträge abgeschlossen wurden.
Die Parallelisierung ist standardmäßig aktiviert. Sie kann mithilfe der Eigenschaft com.glide.update_operation.parallel_operation_enabled deaktiviertwerden, und alle Vorgänge werden wie in vorherigen Releases nacheinander von der Warteschlange aus ausgeführt.
Grenzwerte für Parallelisierung
Der Warteschlangenprozessor bestimmt, ob ein Auftrag in der Warteschlange ausgeführt werden kann. Wenn ein Auftrag ausgeführt werden kann, wird er bei erster Verfügbarkeit von einem Instanzknoten übernommen. Andernfalls wird er an die Warteschlange zurückgegeben, und der Prozessor wertet den nächsten Auftrag in der Warteschlange zur Verarbeitung aus.
Die maximale Anzahl von Aufträgen, die parallel ausgeführt werden können, ist auf 2 festgelegt. Diese Eigenschaft kann über „glide.update.app_operation_queue.parallel.max “ umgeschaltet werden. Beachten Sie jedoch, dass es eine Obergrenze für die verfügbaren Threads gibt Um die Installation durchzuführen, und eine erhöhte Parallelisierung benötigen zusätzlichen Arbeitsspeicher, was die Instanz für aktive Benutzer verlangsamen kann.
Ressourcensperren werden abgerufen
- Zwei beliebige Vorgänge, die denselben Umfang teilen, einschließlich Anpassungen.
- Zwei beliebige Vorgänge, die Schemaänderungen verursachen.
- Zwei beliebige Vorgänge mit Korrekturskripts.
Die Warteschlangenverarbeitung ermittelt, ob diese Kriterien für Vorgänge in der Warteschlange erfüllt sind, und stellt ggf. nicht verarbeitbare Aufträge zurück. Die Fortschritts-ID des Auftrags wird aktualisiert, um anzuzeigen, ob der Vorgang auf das Abrufen entsprechender Ressourcensperren wartet. Ein ausführender Vorgang verwaltet eine Liste der Ressourcen (Umfänge, Schema, vorhandene Korrekturskripts) in der Tabelle „sys_padlock“, und das Einfügen und Freigeben dieser Sperren kann in dieser Tabelle anhand der Fortschritts-ID beobachtet werden. Wenn ein Auftrag in der Warteschlange zurückgestellt wird, weil die erforderlichen Ressourcensperren nicht abgerufen werden können, wird er in eine Abkühlphase versetzt, damit andere Nachrichten verarbeitet werden können. Die Abkühlphase kann mit der Eigenschaft com.glide.update_operation.job_cancel_timeout_minutesgeändert werden. Der Auftrag befindet sich noch in der Warteschlange und wird auf der Seite „Warteschlange für Anwendungsvorgänge “ angezeigt.
com.glide.update_operation.max_failure_count geändert werden.