Hochverfügbarkeit

[helion60]

Hallo,

hat schon einer von euch mit dem Thema Hochverfügbarkeit zu tun gehabt.

Hab jetzt speziell 2 Lösung in Augenschein genommen: iASP und noMax als Softwarelösung.

Wenn jemand diese Lösungen im Einsatz hat, würde ich mich über ein Feedback freuen.

[csupp]

Hallo,

ich kann dir als "Unabhängiger" Berater folgendes Berichten:
iASP mit Cross-Side-Mirroring (ich gehe davon aus, das hast du gemeint) ist eine reine Hardwarelösung mit single point of failure. Ich persönlich bin davon nicht ganz so überzeugt. Die IBM verkauft dies als das non plus ultra!!

Ich bin ein Fan von Softwarelösungen. Und da ist *noMax schon eine sehr gute Wahl. Wenngleich wir eine andere Lösung anbieten. Die Modularität der Anwendung ist sehr gut und die Kundenzufriedenheit zeigt, dass dieses Produkt wohl nicht so schlecht sein kann. Einrichtung und performance der Anwendung sind gut und es gibt auch namhafte Referenzen.

Solltest du auch noch an anderen Softwarelösungen interessiert sein, beraten wir gern. Wir vertreiben hier in Deutschland ein Produkt aus USA. Wenn es interessiert, können wir gern in einem Telefonat fachsimpeln.

Gruß

[h_u_d]

Gern teile ich hier unsere besten Erfahrungen mit den beiden Produkten HA- Suite und iCluster von DataMirror mit.

[BenderD]

Hallo,

die Geschmäcker sind verschieden und das hängt natürlich auch von den Anforderungen im Kleingedruckten ab, aber ich würde da die Hardware Variante iASP favorisieren, wenn die denn nun das endlich kann, was jede andere Büchse schon lange kann.

mfg

Dieter Bender

Hallo,

hat schon einer von euch mit dem Thema Hochverfügbarkeit zu tun gehabt.

Hab jetzt speziell 2 Lösung in Augenschein genommen: iASP und noMax als Softwarelösung.

Wenn jemand diese Lösungen im Einsatz hat, würde ich mich über ein Feedback freuen.

[DVE]

Gebe Dieter Bender vollkommen recht.
Das Problem der Softwarelösung ist in meinen Augen, die Tatsache das irgendwelche Programme über Journale versuchen die Daten/Objekte vom Quellsystem auf dem Zielsystem zu bringen. Das kostet auf der Quellmaschine Performance, weil alle Dateien journalisiert werden müssen und außerdem können nicht alle Objektarten "gespiegelt" werden müssen. Tip: Verlass dich nicht auf den Versprechungen der Verkäufer. Der Verlust ist deutlich höher als "versprochen".
Fragen zum Spiegeln vom IFS oder dem Webserver tauchen erst dann auf, wenn man merkt, dass auf der Zielmaschine was fehlt.
Und ob die Dateieninhalte übereinstimmen ? Bei den Produkten bei deren Vorstellung ich anwesend war, wurde immer mit den Schultern gezuckt. Die Prüfung, das Objekte auf beiden Rechner (Quelle und Ziel) vorhanden sind
kein Problem. Die Prüfung ob z.B. zwei Dateien den selben Inhalt haben, dass könnte man (eventuell), dauert aber sehr lange.

Wenn du die Möglichkeit hast eine Hardwarelösung zu realisieren, dann tue es. Auch wenn es teuerer erschent.

Gruß
DVE

[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

[BenderD]

Hallo,

ich muss da doch nochmal präzisieren:
- die Kosten für die Hardware Lösung sind in der Summe niedriger (die HA Software bekomme ich ja nicht geschenkt und 100% Redundanz in der Hardware brauche ich immer, wenn das funzen soll)
- ein Haken an der Software Lösung ist der Resync und das starten des ganzen, was bei großen Datenmengen und/oder hohem Transaktionsvolumen Tage dauern kann!!! Also gerade dann, wenn man das wirklich braucht, hilft es nix!!!
- ein weiterer Haken ist, dass man bei Teilspiegelungen, oder bei Sync Problemen einzelner Objekte (können auch durch Satzsperren oder Schreiboperationen auf die replizierten Bestände auftreten), inkonsistente Daten hat und auf die dann im Falle der Katastrophe mit einer Applikation losgeht und dann die Katastrophe langsam ausbaut.
- schließlich und endlich sehe man sich mal die Entwicklung des Marktes von HA Software in den letzten 15 Jahren an, da wechseln Produkte und die dahinter stehenden Firmen und die davor stehenden Distributoren - da würde ich mir mal so meine Gedanken machen über die Höhe der Verfügbarkeit der Software Lösungen für Hochverfügbarkeit...

mfg

Dieter Bender

Gebe Dieter Bender vollkommen recht.
Das Problem der Softwarelösung ist in meinen Augen, die Tatsache das irgendwelche Programme über Journale versuchen die Daten/Objekte vom Quellsystem auf dem Zielsystem zu bringen. Das kostet auf der Quellmaschine Performance, weil alle Dateien journalisiert werden müssen und außerdem können nicht alle Objektarten "gespiegelt" werden müssen. Tip: Verlass dich nicht auf den Versprechungen der Verkäufer. Der Verlust ist deutlich höher als "versprochen".
Fragen zum Spiegeln vom IFS oder dem Webserver tauchen erst dann auf, wenn man merkt, dass auf der Zielmaschine was fehlt.
Und ob die Dateieninhalte übereinstimmen ? Bei den Produkten bei deren Vorstellung ich anwesend war, wurde immer mit den Schultern gezuckt. Die Prüfung, das Objekte auf beiden Rechner (Quelle und Ziel) vorhanden sind
kein Problem. Die Prüfung ob z.B. zwei Dateien den selben Inhalt haben, dass könnte man (eventuell), dauert aber sehr lange.

Wenn du die Möglichkeit hast eine Hardwarelösung zu realisieren, dann tue es. Auch wenn es teuerer erschent.

Gruß
DVE

[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

[mk]

Hallo zusammen,

ich bin jetzt nicht der absolute Spiegelungsexperte.

Bei einem Kunden ist aber auch eine Softwarelösung im Einsatz
und manchmal gibt es kuriose Dinge.

Beispielsweise bringt auf einmal ein RPG Programm das täglich
mehrfach läuft eine Fehlermeldung das Objekte für eine
Datei nicht zugeordnet werden können obwohl die Datei
nur mit Input geöffent wird.

Oder das Objekte die temporär im IFS abgelegt werden
bei einer Schleife auf einmal nicht gelöscht werden
können.

Nur als Hinweis

Gruss an alle

Michael