Geplante und ungeplante Ausfalllösungen

Geplante und ungeplante Ausfälle können in der PeopleSoft-Umgebung auftreten. Erfahren Sie mehr über die Oracle-Lösungen, mit denen Sie Ausfallzeiten von Anwendungen minimieren können. Die Minimierung der Ausfallzeit Ihrer PeopleSoft-Anwendung basiert auf der Anwendung und nicht auf der Ausfallzeit einer einzelnen Komponente.

Lösungen für ungeplante Ausfälle

Im Folgenden finden Sie Typen ungeplanter Ausfälle, die durch System- oder Humanausfälle in einer PeopleSoft-Umgebung verursacht werden können, sowie die Technologielösungen, mit denen Sie die Ausfallzeit wiederherstellen und auf ein Minimum reduzieren können.

Wir empfehlen Ihnen, die folgenden Basisszenarien zu testen, um sicherzustellen, dass sie in Ihrer Umgebung korrekt konfiguriert sind, und um sicherzustellen, dass Sie bereit sind, im Notfall zu handeln.

Ausfalltyp Oracle-Lösung Vorteile Uhrzeit für das Recovery
Load Balancer Software-Load Balancer, Konfiguration lokal repliziert Verbindungen werden nahtlos in den überlebenden Load Balancer migriert Keine Ausfallzeit.
PeopleSoft Fehler bei Knoten oder Komponente des PIA-Webservers Redundante Webserver ohne Coherence*Web-Cacheservercluster Verbindungen werden auf verbleibende Knoten neu verteilt. Die Verarbeitung der überlebenden Knoten wird fortgesetzt. Keine Ausfallzeit. Eine erneute Authentifizierung und erneute Einreichung der Arbeit kann erforderlich sein.
PeopleSoft Fehler bei Knoten oder Komponente des PIA-Webservers Redundante Webserver mit Coherence*Web-Cacheservercluster Verbindungen werden auf verbleibende Knoten neu verteilt, wobei der Sessionzustand beibehalten wird. Die Verarbeitung der überlebenden Knoten wird fortgesetzt. Keine Ausfallzeit und keine erneute Authentifizierung oder erneute Weiterleitung der Arbeit.
PeopleSoft Application Domain Server-Knoten oder Komponentenfehler

Redundante Anwendungsdomainserver

Bei PIA-Servern, die mit aktiven Verbindungen konfiguriert sind, wird die Last über Anwendungsserver verteilt, und die Arbeit wird erneut an einen überlebenden App-Server weitergeleitet.

Verbindungen werden auf verbleibende Knoten neu verteilt. Überlebende Knoten nehmen die Anforderungen auf, kein Kontextverlust Keine Ausfallzeit.
Datenbankserver oder Instanzfehler Oracle RAC, Application Continuity, FAN-Veranstaltungen Automatisches Recovery der Arbeit an ausgefallenen Instanzen – Sessions führen transparentes Failover aus, Updates werden automatisch erneut weitergeleitet Sekunden bis Minuten.
Sitefehler Oracle Data Guard, rsync Vollständiges Site-Failover mit minimalem bis keinem Datenverlust Weniger als 10 Minuten nach der Entscheidung für den Übergang der Datenbankrolle, das Mounten des Dateisystems und den Start der Anwendung PeopleSoft.
Speicherfehler ASM Spiegelung und automatisches Rebalancing. Keine Ausfallzeit.
Speicherfehler Oracle RMAN mit Flash Recovery-Bereich. Vollständig verwaltetes Datenbank-Recovery und Backups auf Datenträger. Minuten bis Stunden.
Speicherfehler Regionaler Oracle-Objektspeicher Cloud-verwaltetes Datenbank-Recovery und Backups auf Datenträger Minuten bis Stunden.
Speicherfehler Oracle Data Guard, rsync Vollständiges Site-Failover mit minimalem bis keinem Datenverlust. Weniger als 10 Minuten nach der Entscheidung für den Übergang der Datenbankrolle, das Mounten des Dateisystems und den Start der Anwendung PeopleSoft.
Menschlicher Fehler Oracle Data Guard mit Flashback Database. Recherche zum Thema Copy (Standby) Stunden (Forschung durch Datenkorrektur).
Datenbeschädigung Oracle RMAN mit Fast Recovery-Bereich. Online Block Media Recovery und verwaltete datenträgerbasierte Backups. Minuten bis Stunden.
Datenbeschädigung Oracle Active Data Guard Erkennt und repariert fehlerhafte Blöcke automatisch mit der physischen Standbydatenbank. Keine Ausfallzeit, transparent für die Anwendung.
Datenbeschädigung Oracle Data Guard Automatische Validierung und erneute Übertragung beschädigter Redo-Blöcke Keine Ausfallzeit, transparent für die Anwendung.
Datenbeschädigung Oracle Data Guard Broker Schneller Failover zu einer lokalen Standbydatenbank oder vollständiger Site-Failover zu einer DR-Site.

Lokale Standbydatenbank: Weniger als 5 Minuten nach der Entscheidung für den Übergang der Datenbankrolle, das Mounten des Dateisystems und den Start der Anwendung PeopleSoft.

Vollständiges Site-Failover: Weniger als 10 Minuten nach der Entscheidung für Datenbankrollenübergang, Dateisystem-Mount und PeopleSoft.

Hinweis:

Es kann möglich sein, sich schnell von einem Fehler am primären Standort zu erholen und dort den Betrieb wieder aufzunehmen, was für den Gesamtbetrieb weniger störend sein kann als der Wechsel zum sekundären Standort. Daher haben wir in der obigen Tabelle erwähnt, dass wir die Entscheidung getroffen haben, das Failover durchzuführen, und wie lange es voraussichtlich dauern wird, um einen skriptgesteuerten Übergang durchzuführen, sobald die Entscheidung getroffen wurde. Wenn Sie vor einem Failover zu einer DR-Site keine menschliche Entscheidung treffen müssen, konfigurieren Sie Fast-Start Failover in der Datenbank.

Wenn Fast-Start Failover konfiguriert ist und der Apply Lag der Standbydatenbank innerhalb des Fast-Start Failover Lag-Limits liegt, wird durch die Zeit zum Hochfahren der DR-Site nur der Schwellenwert für den Fast-Start Failover-Timeout zur Gesamtzeit für den Übergang zur Standbydatenbank hinzugefügt.

Unabhängig davon, ob die Aktion automatisch ausgeführt wird oder nicht, sollte der Failover-Prozess vollständig skriptiert werden, um eine schnelle und genaue Ausführung sicherzustellen.

Geplante Wartungslösungen

Im Folgenden finden Sie eine Zusammenfassung der geplanten Wartungsaktivitäten, die in der Regel in einer PeopleSoft-Umgebung stattfinden, sowie der empfohlenen Technologielösungen, um Ausfallzeiten auf ein Minimum zu reduzieren.

Wartungsaktivität Lösung PeopleSoft Ausfall
Mid-Tier-Betriebssystem- oder Hardwareupgrade Load Balancing, redundante Services über Web- und Tuxedo-Anwendungsserver hinweg. Keine Ausfallzeit, vorausgesetzt, Coherence*Web wird ausgeführt.
PeopleSoft (Anwendung und PeopleTools) PeopleSoft Out-of-Place Patching. Minuten (keine Schemaänderungen) bis Stunden (Schemaänderungen erforderlich)
PeopleSoft Änderung der Anwendungskonfiguration Rollender Neustart der PeopleSoft-Anwendung. Kein Ausfallzeit
PeopleSoft-Upgrades PeopleSoft-Upgrades an anderer Stelle. Stunden bis Tage (Schemaänderungen sind erforderlich; Zeit hängt von der Datenbankgröße ab)*
Patching oder Hardwarewartung des Betriebssystems der Datenbankebene Oracle RAC rollierend, Standby-First. Kein Ausfallzeit
Patching von Oracle Database-Releaseupdates Oracle RAC rollierend, Standby-First. Kein Ausfallzeit
Oracle Database-Upgrades Transientes logisches Rolling Upgrade von Data Guard. Siehe: Ausfallzeit von PeopleSoft mit einer lokalen Standbydatenbank reduzieren. Sekunden bis Minuten
Oracle Grid und Oracle Clusterware Upgrades und Patches Oracle RAC rollierend, Standby-First. Kein Ausfallzeit

* In der Praxis gibt es Möglichkeiten, die Auswirkungen von erweiterten Upgrade-Ausfallzeiten zu mindern – beispielsweise durch die Bereitstellung eines schreibgeschützten Replikats. Mit Oracle Consulting Services können Sie das Upgrade planen und ausführen.