View Full Version : Inkrementelle Sicherung
Klar werden Spoolfiles gesichert. Gestern haben wir einen Umschalttest durchgeführt bei der Westspiel Entertainment GmbH, die 6 Spielcasionos und etliche Automatenspielsäle betreiben. U.a. auch das Casino Hohensyburg in Dortmund.
Wehe wenn sich der Kessel nicht dreht, dann hat Eichel noch ein Problem mehr. Selbst die Drehtüren für das Betreten der Automatenspielsäle werden über die iSeries kontrolliert. Und funktionierten auch. Ach ja, Tests sollten regelmäßig durchgeführt werden, damit man weiß, wo man steht.
Wer kennt ICNet nicht? Schaut einmal in die letzte Ausgabe der News. Gruß Wolfgang Stirnnagel
Noch haben wir sie nicht. Wir haben uns lediglich aufgrund des letzten Crashes dafür entschieden. Es ist bei uns nicht möglich längere Zeit ohne die AS/400 zu überleben. Zur Zeit ist bei uns die/eine Lösung von MIMIX oder Software Solutions im Gespräch.
ICNet kannte ich vorher nicht, werde mir das aber mal anschauen.
Sichern werden wir vermutlich auf dem Backup Rechner aber es ist zur Zeit noch nicht klar, ob wir wirklich eine 1 : 1 Abbildung anstreben oder ob wir gewisse Teilbereiche nicht auf den Backup Rechner bringen. Diese Entscheidung wird leider durch Kostenfatoren bestimmt.
Denke bei deiner inkrmentellen Sicherung auch daran, daß der Zeitbedarf unbekannt ist. Zumeist schüttet man das gewonnene Zeitfenster sofort mit anderen Aktionen voll.
Weiterhin ist bei der inkrementellen Sicherung immer das Problem vorhanden, daß man nicht weiss auf welchem Datenträger welche Daten stehen. Ein Umstand der mir persönlich nicht behagt.
Hi Wuntvor,
du hast Recht, das Zeitfenster kann nie klein genug sein.
Wir haben die Hochverfügbarkeit seit 3 Jahren und kennen schon sehr viele Probleme der Datenspiegelung, deshalb betrachte ich die überschwänglichen e-mails von "wosti" als reine Werbung im Forum für seine eigene Firma.
MfG
samik
Schildere bitte mal die Probleme. Das wäre sehr nett. Ich fürchte wir gehen da sehr blauäugig ran
Hei Frau/Herr Samik,
nur kein Neid. Was heißt eigentlich "überschwänglich"? Wenn's funktioniert? Gruß Wolfgang Stirnnagel
Hallo Wuntvor,
Es ist ein sehr großes Thema....
Der Backuprechner sollte die gleiche Konfiguration wie der Source-Rechner haben (z.B. es müssen alle Anschlussmöglichkeiten ans Netz innerhalb und außerhalb der Firma vorhanden sein).
Ich nehme an, dass es ein hot – Backuprechner wird und die Datenspiegelung permanent läuft. Das bedeutet aber, dass man für alle IBM Lizenzprogramme auf dem Backuprechner nochmal zahlen muss. Deshalb sollte man für beide Rechner Softwaresubscription + natürlich Wartungvertrag haben.
Man muß BatchJournalCaching Programm von IBM für die performante Block-Journalisierung verwenden (BJC wird für jedes Journal auf *ON gesetzt.), ansonsten bleibt der Rechner stehen, weil er nichts anderes als Journalisierung macht. So war es bei uns, wir haben OS/400 V4R4.
Man braucht auf jeden Fall mehr Speicherplatz. Es wird ein 2.ASP für die Receiver angelegt und zwar so groß, dass man vielleicht 2 Tage die Receiver aufbewahren kann (so ist es bei uns), falls die Sourcemaschine so lange ausfällt.
Man sollte sich sehr gut überlegen was man spiegeln will und wie man die Bibliotheken gruppiert - am besten nach Themen.
Für die schnelle Datenübertragung sorgen, am besten mit >=2 Kanälen (FiberChannel, Ethernet..) Die Verbindung muss redundant sein und schnell damit kein Datenstau entsteht.
Die Datenübertragung min. auf 2 Kanäle aufteilen.
Man schließt aus der Spiegelung die Objekte aus, die nur temporär auf dem Rechner sind – sie werden unnötig von der Spiegelung gelockt und es werden Unmengen an LOGs erstellt.
Es kann passieren, dass manche Software umgestellt werden soll, weil nach jeder Änderung eines Objektes wird es zuerst von der Spiegelung gelockt.
Die Spoolfiles werden gespiegelt, nur wenn sie den Status *RDY haben. Wenn man sie in eine andere OUTQ überträgt, werden sie nicht gespiegelt. Die Spiegelung der Spoolfiles ist so umständlich, dass wir darauf verzichtet haben.
Normalerweise werden die Receiver regelmäßig gelöscht, aber wie immer gibt es Ausnahmen in denen die Receiver eine bestimmte Zeit für interne Auswertungen aufbewahrt werden müssen. Es ist ein sehr großes Problem für den Neustart der Spiegelung, weil man nicht gleich merkt, dass die Spiegelung ab dem falschen Receiver gestartet ist. Es führt dazu, dass die alten Änderungen wieder bearbeitet werden. Wenn die Anzahl der Sätze einer Datei auf beiden Anlagen gleich ist – bedeutet es noch lange nicht, dass sie auch inhaltlich gleich sind Rollback ist nicht möglich.
Den Befehl zum Löschen der Receiver unbedingt anpassen, weil er alle Receiver löscht (auch die man eigentlich aufbewahren muss).
Änderungen der Attribute der PF werden nicht gespiegelt.
Unbedingt einen Wartungsvertrag abschließen, weil man ansonsten keine Hilfe + Updates bekommt. Am Anfang hat man sehr viel zu tun, bis man den ganzen Ablauf verstanden hat und braucht viel Unterstützung. Unsere Hotline ist in London, also man muss englisch sprechen und schreiben können.
Man muss den Ablauf der Testumschaltungen (geplanten und ungeplanten) sehr gut überlegen und oft testen – am besten Sonn- oder Feiertags und am Anfang nur die Spiegelung der Testbibliotheken starten.
Später ist alles nur Routine:-)
Ich habe bestimmt Vieles vergessen, aber für den Anfang ist es ausreichend ;-)
Viel Erfolg!
samik
In jedem Falle danke ich schonmal recht herzlich für deine Mühen
Hallo Samik, hallo Wuntvor,
ich hätte noch zwei Anmerkungen:
@samik:
Warum sichert Ihr eure Daten nicht auf dem Backup-Rechner, wenn Ihr schon seit drei Jahren eine Hochverfügbarkeit im Einsatz habt. Dort sollte doch eine Sicherung möglich sein. Ich würde die APLY-Jobs beenden; die notwendigen Daten sichern und dann die APLY-Jobs wieder starten.
@ Wuntvor:
Bevor ich mich für eine Hochverfügbarkeitslösung entscheide, würde ich auf jeden Fall prüfen, welche Kosten im Falle eines Wechsels auf eine neue iSeries bezahlt werden müssen!
Hallo Jo400,
bei einer Umschaltung auf den Backuprechner wurde die Spiegelung für eine Gruppe ab den falschen Receiver gestartet :-(
Bei uns gibt es nur ein Journal, dessen Receiver längere Zeit aufbewahrt werden müssen und beim Start hat das Programm den ersten besten Receiver genommen in dem es die Startposition gefunden hat. Wir haben es nicht gleich gemerkt, weil die Anzahl der Sätze sich nicht verändert hat, aber inhaltlich waren sie falsch.
Nach diesem Vorfall prüfe ich jedes mal, ob die Startposition und der Receivername(!!!) korrekt sind.
Man möchte auf die Nummer sicher gehen und will nicht auf dem Backuprechner sichern - also ein totes Projekt :-(
Wir führen regelmässig den Datenabgleich aus (für die wichtigsten Dateien), aber damit kann man jetzt keinen mehr beeindrucken und überzeugen, dass die Daten auf beiden Maschinen wirklich identisch sind. Traurig aber wahr.
Die Backupmaschine läuft und läuft. Wenn der Sourcerechner eines Tages wirklich den Geist aufgibt, dann muss man auf dem Backuprechner arbeiten, aber ansonsten nicht.
MfG
samik