Hochverfügbarkeit

[alexander may]

Wir haben seit längerem *noMAX im Einsatz. Sehr zufrieden. Bei Fragen -> Mailen....

Gruß

Alexander

[tfroehlich]

Hallo zusammen,

bei unserer damaligen Ausschreibung kam für uns nur eine Software-Lösung in Betracht.

Wir haben uns damals für Nomax entschieden.
a) sehr gute Performance
b) flexibel durch x-viele Gruppen (Journale)
(besser zu überprüfen bei Updates vom WWS oder Fibu)

c) Ansprechpartner ist ganz in unserer Nähe.

Gruss

[WE]

Hallo,

ich möchte nochmals zum Thema iASP zurückkommen, dessen Knackpunkte die Kollegen bisher nicht betrachtet haben: Der Einsatz von iASP steht und fällt letztlich damit, ob eine Anwendung überhaupt iASP-fähig ist oder gemacht werden kann. Bestimmte Objekte oder Objektarten können nicht in einem iASP stehen bzw. können nicht von dort aufgerufen werden. Hilfe dazu gibt es im Redbook SG24-6802. Der für mich größte Nachteil einer Lösung mit iASP und Cross Site Mirroring ist, daß die Daten auf der Backup-Seite nicht für eine Datensicherung in Zugriff gebracht werden können ohne den Spiegel zu unterbrechen. Das könnte man natürlich, aber die Strafe folgt auf dem Fuße durch eine stunden(tage)lange Resychronisation, während der im K-Fall nicht umgeschaltet werden kann.
Gruß
Wolfgang

[BenderD]

Hallo,

der Hinweis auf die Einschränkungen iASP ist wichtig, da die as400 (leider) immer noch nicht das darf, was die Hardware (pSeries) native eigentlich kann, nämlich konsequentes Hardware spiegeln ohne wenn und aber.

Das mit der Datensicherung, das halte ich für eine der größten N A C H T E I L E der Software Lösungen, die Datensicherung setzt Sperren und Synch Punkte, die die Replikation der Daten stören (mit SAV while active eher unkontrollierbarer) und aus dieser Ecke kommen doch gerade die Probleme dieser Lösungen: der Zustand der Sperren wird nicht synchronisiert und deshalb sind diese Lösungen in bestimmten Fällen überlastet. Hier sei auch noch am Rande erwähnt, dass die vollständige Journalisierung aller journalisierbaren Objekte die Save Szenarien entspannt, sodass man mit ein wenig Überlegung das auch anders hinkriegen sollte und Journalisierung ist bei iASP keineswegs verboten und empfiehlt sich ohnehin immer!

mfg

Dieter Bender

Hallo,

ich möchte nochmals zum Thema iASP zurückkommen, dessen Knackpunkte die Kollegen bisher nicht betrachtet haben: Der Einsatz von iASP steht und fällt letztlich damit, ob eine Anwendung überhaupt iASP-fähig ist oder gemacht werden kann. Bestimmte Objekte oder Objektarten können nicht in einem iASP stehen bzw. können nicht von dort aufgerufen werden. Hilfe dazu gibt es im Redbook SG24-6802. Der für mich größte Nachteil einer Lösung mit iASP und Cross Site Mirroring ist, daß die Daten auf der Backup-Seite nicht für eine Datensicherung in Zugriff gebracht werden können ohne den Spiegel zu unterbrechen. Das könnte man natürlich, aber die Strafe folgt auf dem Fuße durch eine stunden(tage)lange Resychronisation, während der im K-Fall nicht umgeschaltet werden kann.
Gruß
Wolfgang

[DVE]

Zur Softwarelösung. Die mir bekannten Lösungen waren/sind nicht in der Lage *JOBQ's zu spiegeln.
Jobs die hier auf die Ausführung warten, sind im Backup-Fall "weg". Fragen nach Lösungen waren seitens der Verkäufer einfach zu bewantworten: Kundensache. Der Kunde soll selbst "wie auch immer" dafür sorgen, dass diese Informationen auf dem Backup-Rechner landen, z.B. durch Kauf geeigneter Software.
Das die OUTQ's auch nicht gespiegelt werden/wurden auch kein Problem: Sache des Kunden.
Das heißt, zu den Kosten für die Softwarelösung kommen noch die Kosten für die Software in Bezug auf *JOBQ's und OUTQ's.
Letzendlich hat man mehr als ein Produkt um die Hochverfügbarkeit zu realisieren und damit noch mehr Baustellen, die im Falle eine Backup, bearbeitet werden müssen, bevor das Backupsystem zur Verfügung gestellt werden kann.

Gruß
DVE