Multiprocessing

Aufträge an eine ROBAR-SV-Instanz werden asynchron und parallel bearbeitet (Multiprocessing).

Das Multiprocessing-Konzept von ROBAR-SV ermöglicht die intensive Auslastung des Archivsystems. Während z.B. ein Prozess bei einer normalen Bandverarbeitung auf die Auftragsausführung wartet, können parallel dazu Aufträge von anderen Prozessen, z.B. ein Auftrag an das Archivsystem, ausgeführt werden. Eine ROBAR-SV-Instanz kann gleichzeitig bis zu 10 Aufträge pro Archivsystem und Roboterarm verarbeiten.

Die Anzahl der parallelen Prozesse legen Sie in der Schnittstellen-spezifischen Konfigurationsdatei von ROBAR-SV fest. Als Mindestwert können Sie einen Prozess, maximal zehn Prozesse festlegen. Als Voreinstellung sind zehn Prozesse festgelegt (siehe Hinweis auf „Multiprocessing“).

Die parallele Verarbeitung verbessert die Systemperformance, wenn die aktuelle Auftragsbearbeitung von ROBAR-SV erst dann fortgesetzt werden kann, wenn ein bestimmtes Ereignis eingetreten ist (z.B. warten auf NKVT097 UNLOAD INITIATED).

Aufräumen eines Volumes nach Benutzung

Abhängig von der Bandposition liegt zwischen den Zeitpunkten UNLOAD INITIATED und Volume ready (zum Aufräumen) eine unbestimmte Zeit. ROBAR-SV hat deshalb in relativ kurzen Intervallen KEEP-Aufträge zum Aufräumen eines benutzten Volumes gegeben. Mit der Verfügbarkeit des DISMOUNT MANAGERS (siehe Reference Guides der Archivsysteme) hat sich das Verfahren geändert. Der DISMOUNT MANAGER empfängt den KEEP-Auftrag und steuert entsprechend den voreingestellten Werten den KEEP-Zyklus.

Der folgende Abschnitt ist nur relevant für Archivsysteme ohne DISMOUNT MANAGER:

KEEP-Anforderungen können verzögert werden durch Wartezeiten, die in der ROBAR-Rule-File eingestellt werden können. Dadurch lässt sich verhindern, dass der Roboter durch permanente KEEP-Anforderungen blockiert wird. Als Folge daraus können längere Wartezeiten festgelegt werden, ohne dass die Roboterverarbeitung unterbrochen wird. Die längeren Wartezeiten können mit folgenden Optionen eingestellt werden:

• MRV01 für das Exportieren nach normaler UNLOAD-Meldung

• MRVFi und MRVGi für das Demontieren nach Notentladen (Fehlerfall)

• MRVAi für das Reinigen des MBK-Geräts

  i = 3 für Gerätetyp LTO-Ux

  i = 4 für ETERNUS CS

Einstellungshinweise für Wartezeiten

Das Verstellen der Wartezeiten in Richtung der maximalen MBK-Rückspulzeiten gewährleistet zwar höchste Roboterverfügbarkeit (keine Unterbrechung durch erfolglose UNMOUNT-Versuche), die Verfügbarkeit der MBK-Geräte und der Kassetten ist jedoch häufig nicht zufriedenstellend. Solche Einstellungen sind deshalb nur sinnvoll, wenn eine große Anzahl von MBK-Geräten zur Verfügung stehen und dieselbe Kassette nur in seltenen Fällen von direkt folgenden Anforderungen betroffen ist.
Durch Beobachten des Roboterverhaltens lassen sich die optimalen Werte für die Einstellungen ermitteln.

Die folgende Tabelle informiert, mit welchen Einstellungen sich die beschriebenen Probleme beseitigen lassen.

Problem	Option	Maßnahme
Rückspulzeit der Kassetten ist zu lang	MRV01	Wert erhöhen
MBK-Gerät nicht verfügbar, da Roboter die Kassette erst lange nach dem Entladen aus dem MBK-Gerät entnimmt	MRV01	Wert vermindern
Roboter wartet auf Entladen der Reinigungskassette	MRVAi1	Wert erhöhen
MBK-Gerät nicht verfügbar, da Roboter die Reinigungskassette erst lange nach dem Entladen aus dem MBK-Gerät entnimmt	MRVAi1	Wert vermindern
Archivsystem-Timeout (Meldung N206) nach Auftreten der Meldung NKVT097	MRV01	Wert erhöhen
Archivsystem-Timeout (Meldung N206) nach KEEP für Reinigungskassette	MRVAi1	Wert erhöhen
Nach Gerätefehler (Meldung EXC0858) bleibt der Roboter vor dem betroffenen MBK-Gerät stehen	MRVFi1 MRVGi1	Wert erhöhen2 Wert vermindern2
Nach Gerätefehler (Meldung EXC0858) entnimmt der Roboter die Kassette nicht sofort aus dem betroffenen MBK-Gerät	MRVFi1 MRVGi1	Wert vermindern2 Wert erhöhen2

1	i = 3: Gerätetyp LTO-Ux; i = 4: ETERNUS CS
2	jeweils um denselben Wert

Der wohl häufigste Grund für Zeitverlust im Archivsystem ist das Anfordern einer Roboter-KEEP-Operation für ein MBK-Gerät, obwohl das Band tatsächlich wenige Sekunden später entladen wird. Diese Situation tritt in folgenden Fällen auf:

• Eine BS2000-Task gibt eine Kassette frei, NDM informiert daraufhin über die Konsol-Meldung NKVT097, dass die Kassette entladen wird und weist das MBK-Gerät an, die Kassette zurückzuspulen und zu entladen. Auf die Meldung NKVT097 reagiert ROBAR mit dem Anfordern einer Roboter-KEEP-Operation für dieses MBK-Gerät. Ab diesem Zeitpunkt ist das Archivsystem solange blockiert, bis die Kassette entladen ist oder ein Archivsystem-Timeout auftritt.

• Bei bestimmten MBK-Geräte- oder Kassettenfehlern (z.B. Bandspannungsverlust) wird (von ROBAR mittels Roboter-Kommando ULU oder durch das Operator-Kommando /UNLOAD) für das betroffene MBK-Gerät der Notentladevorgang eingeleitet. Dabei wird die Kassette langsam zurückgespult und anschließend entladen. Wird während dieser Phase eine KEEP-Operation angefordert, so wird dadurch der Roboter für die Rückspulzeit (die durchaus mehrere Minuten betragen kann) blockiert.

• Entsprechend der Parametrisierung, aber auch bei der Behebung bestimmter MBK-Gerätefehler, veranlasst ROBAR das Montieren einer Reinigungskassette. Wird für diese Reinigungskassette unmittelbar nach MOUNT CLEAN eine KEEP-Operation angefordert, so wird der Roboter dadurch bis zur Beendigung des Reinigungsvorgangs blockiert.

Die im Konfigurationsparameter multiprocessing_level festgelegte Voreinstellung von zehn Prozessen (Maximalwert) müssen Sie nur beim Auftreten einer Speichersättigung auf dem ROBAR-Server durch einen niedrigeren Wert ersetzen.