Die Betriebssystem-Agenten haben die Fähigkeit Dateien zu übertragen. Dazu muss sowohl auf dem Quell- als auch auf dem Zielrechner ein Agent installiert sein. Die Dateiübertragung erfolgt selbstverständlich gesichert und verschlüsselt.
Mit Automation Engine Version 9.00A wurde der Ablauf von FileTransfers optimiert und verbessert. Dieses neue Protokoll kommt jedoch nur dann zum Einsatz, wenn die beteiligten Agenten die Version 9.00A (oder höher) aufweisen. Weist einer der Agenten eine niedrigere Version auf, so wird aus Kompatibilitätsgründen das alte Verfahren verwendet.
Bevor die Dateiübertragung starten kann, benötigen die beiden Agenten eine Verbindung. Einer der Arbeitsprozesse wendet sich daher an den Kommunikationsprozess, der mit dem Quell-Agenten verbunden ist, und teilt ihm die Verbindungsanforderung mit. Der Kommunikationsprozess leitet die Nachricht an den Agenten weiter. Mit den darin enthaltenen Informationen versucht der Agent sich mit dem Ziel-Agenten zu verbinden.
Gelingt der Verbindungsaufbau beispielsweise auf Grund von Firewall-Einstellungen nicht, so nimmt die Automation Engine mit der gleichen Methode Kontakt zum Ziel-Agenten auf. Dieser versucht nun, ob er eine Verbindung zum Quell-Agenten aufbauen kann.
Sobald die beiden Agenten miteinander verbunden sind, kann die Dateiübertragung beginnen. Status-Nachrichten werden regelmäßig an die Automation Engine geschickt, damit der Fortschritt verfolgt werden kann. Im UserInterface sehen Sie im Detailfenster der FileTransfer-Aufgabe die bereits übertragenen Bytes der Datei.
Im Gegensatz zum neuen FT-Protokoll, werden die Dateien aller FileTransfers über eine Verbindung (FT-Verbindung) gesendet. Dabei kann es auch vorkommen, dass abwechselnd Blöcke von unterschiedlichen Dateien übertragen werden. Die Automation Engine überwacht den kompletten FileTransfer-Vorgang und weist den Quell-Agenten für jede einzelne Datei an, diese zu senden.
Ob die Verbindung zwischen den beiden Agenten nach der Dateiübertragung wieder abgebaut werden soll, kann der Administrator mit der Einstellung DISCONNECT_AFTER_FT in der Variable UC_HOSTCHAR_DEFAULT bestimmen.
Ab AE-Version 9 sendet die Automation Engine dem Quell-Agenten den kompletten FileTransfer-Auftrag (inklusive Wildcard-Angaben bei teilqualifizierten FileTransfers). Die Auflösung des Auftrages (Ermittlung der Dateien) übernimmt der Sender-Agent.
Verbindungsaufbau
Der Sender-Agent versucht eine Verbindung zum Empfänger aufzubauen. Gelingt ihm dies zum Beispiel auf Grund von Firewall-Einstellungen nicht, so benachrichtigt er die Automation Engine. Der FT-Auftrag wird daraufhin an den Empfänger gesendet, der nun einen Verbindungsaufbau zum Sender versucht. Nach erfolgreicher Verbindung überträgt der Empfänger-Agent den FT-Auftrag an den Sender.
Speicherplatz-Prüfung
Vor dem Beginn eines FileTransfers wird abhängig vom Betriebssystem eine Überprüfung durchgeführt, ob genügend Platz auf der Zielplattform verfügbar ist bzw. dieser allokiert.
Abwicklung von FileTransfers
Beim neuen Protokoll wird für jeden FileTransfer eine eigene Verbindung zwischen den Agenten aufgebaut. Die Dateien werden immer hintereinander durch eine Verbindung gesendet. Wenn der Agent dies unterstützt, wird jeder FileTransfer in einem eigenen Thread bzw. Prozess abgewickelt. Dadurch laufen mehrere FileTransfers komplett unabhängig voneinander.
Da die Verbindungen nach Abschluss der FileTransfers selbstständig wieder abgebaut werden, hat die Einstellung DISCONNECT_AFTER_FT in der Variable UC_HOSTCHAR_DEFAULT beim neuen Protokoll keine Wirkung.
Threads werden von den Agenten folgender Betriebssysteme unterstützt:
Bei NSK wird jeder FileTransfer über einen eigenen Prozess abgewickelt. Um dies zu ermöglichen besitzt der NSK-Agent einen zweiten Port speziell für FileTransfers.
Wenn es zu Verbindungsfehler zwischen Automation Engine und Agenten kommt, werden die FileTransfers trotzdem unbeeinflusst fortgesetzt. Wenn die Verbindung wieder hergestellt werden konnte, wird der tatsächliche Status des FileTransfers an die Automation Engine übermittelt.
Bei FileTransfers mit UNIX-Agenten führt die NFS-Sicherheitseinstellung "root squash" zu Problemen, wenn das alte FT-Protokoll eingesetzt wird.Der Grund dafür ist, dass FileTransfers immer unter dem UNIX-Benutzer "root" durchgeführt werden. Im neuen Protokoll tritt dieser Fehler nicht mehr auf, da FileTransfers unter UNIX immer unter dem Benutzer laufen, der im Login-Objekt angegeben wurde.
Um eine zuverlässige Übertragung von Dateien zu gewährleisten, stehen folgende Verfahren bei FileTransfers zur Verfügung:
Übertragungssicherheit
Die Richtigkeit der übertragenen Daten wird durch einer im Datenstrom enthaltenen MD5-Prüfsumme sichergestellt. Dabei werden die Daten paketweise geprüft.
Konsistenzprüfung beim FileTransfer-Wiederanlauf
Im Gegensatz zum alten Protokoll können einzelne Dateien eines FileTransfers nicht gezielt wiederholt werden. Es besteht jedoch die Möglichkeit, fehlerhafte FileTransfers ab dem letzten Wiederanlaufpunkt zu wiederholen.
Wiederanlaufpunkte werden vom Agenten während der Dateiübertragung in einem bestimmten Zeitintervall erstellt (Einstellung FT_RESTARTINFO_INTERVAL in der Variable UC_HOSTCHAR_DEFAULT).Diese Informationen speichert der Agent in sogenannte StatusStore-Dateien lokal auf seinem Rechner. Bricht der FileTransfer aus irgendeinem Grund ab, so haben Sie die Möglichkeit, diesen ab der Dateiposition des letzten Wiederanlaufpunktes zu wiederholen (Wiederanlauf - Option: "Ab letzter Restartposition"). Durch diese Funktion kann Zeit gespart werden, wenn zum Beispiel die Hälfte einer großen Datei bereits übertragen wurde.
Mit FT_RESTARTINFO_LIFETIME und FT_RESTARTINFO_CHECK (UC_HOSTCHAR_DEFAULT) stellen Sie ein, wann StatusStore-Dateien gelöscht werden sollen.
Um sicherzustellen, dass die Zieldatei nach einem erfolgreichen Wiederanlauf der Quelldatei entspricht, werden die bereits übertragenen Daten davor mit einer MD5-Prüfsumme verglichen.Bei der Erstellung eines Wiederanlauf-Punktes wird auch die MD5-Prüfsumme ermittelt und in der StatusStore-Datei abgelegt. Wurde die teilweise übertragene Datei beispielsweise am Rechner des Empfänger-Agenten verändert, würde sich die Prüfsumme unterscheiden und es zum Fehler beim Wiederanlauf kommen.
Um Übertragungszeit zu sparen, werden für Dateien, die kleiner als 1MB sind, nie MD5-Prüfsummen berechnet!
Das MD5-Verfahren kann mit der Einstellung FT_USE_MD5 in der Variable UC_HOSTCHAR_DEFAULT deaktiviert werden.
Die StatusStore-Dateien werden abhängig von der Agenten-Plattform in folgende Verzeichnisse abgelegt:
Plattform | Verzeichnis | Dateiname | Besonderheit |
---|---|---|---|
Windows | Temp-Verzeichnis des Agenten |
FTNNNNNNN.sts Bei NNNNNNN handelt es sich um die RunID des FileTransfers, umgewandelt in eine 7-stellige Buchstabenfolge. Diese kann mit dem Sprachmittel ALPHA2RUNNR in die normale 10-stellige RunID umgewandelt werden. |
StatusStore-Datei pro FileTransfer |
BS2000 | Temp-Verzeichnis des Agenten | FTNNNNNNN.sts | StatusStore-Datei pro FileTransfer |
Unix/VMS | Temp-Verzeichnis des Agenten | FTNNNNNNN.sts | StatusStore-Datei pro FileTransfer |
OS/400 | IFS: FTNNNNNNN.sts QSYS: Objekt mit dem Namen FTNNNNNNN und dem Typ USRSPC |
StatusStore-Datei pro FileTransfer | |
NSK |
Subvolume in der Konfigurationsdatei angegeben (siehe Installation des NSK-Agenten) |
INI-Datei des Agenten: Sektion [FT-STATUS-STORE] |
4 StatusStore-Dateien für alle Wiederanlauf-Informationen |
z/OS |
Status-Store Dataset |
Ein StatusStore-Dataset für alle Wiederanlauf-Informationen |
Siehe auch:
FileTransfer
FileTransfer - Ausführen
Mehr-Server-Betrieb
Verbindungsaufbau
Automic Documentation - Tutorials - Automic Blog - Resources - Training & Services - Automic YouTube Channel - Download Center - Support |
Copyright © 2016 Automic Software GmbH |