Informationen zu zuverlässigen und resilienten Cloud-Topologiepraktiken

Die Architektur einer zuverlässigen Anwendung in der Cloud unterscheidet sich in der Regel von einer herkömmlichen Anwendungsarchitektur. Während Sie in der Vergangenheit möglicherweise redundante High-End-Hardware erworben haben, um das Risiko eines Ausfalls einer gesamten Anwendungsplattform zu minimieren, ist es in der Cloud wichtig, im Voraus zu bestätigen, dass Fehler auftreten. Anstatt zu versuchen, Ausfälle vollständig zu verhindern, besteht das Ziel darin, die Auswirkungen einer einzelnen fehlerhaften Komponente (Single Point of Failure oder SPOF) zu minimieren. Befolgen Sie diese Best Practices, um die Zuverlässigkeit in jedem Schritt Ihres Designprozesses zu erhöhen.

Zuverlässige Anwendungen sind:

  • Resilient und ordnungsgemäße Wiederherstellung nach Ausfällen, und sie funktionieren weiterhin mit minimalen Ausfallzeiten und Datenverlust vor der vollständigen Wiederherstellung.
  • Hochverfügbar (HA) und läuft wie in einem gesunden Zustand ohne signifikante Ausfallzeiten entwickelt.
  • Vor Regionsausfällen durch gutes Disaster Recovery-(DR-)Design geschützt.

Um eine zuverlässige Anwendung zu erstellen, ist es unerlässlich, zu verstehen, wie diese Elemente zusammenarbeiten und wie sie sich auf die Kosten auswirken. Es kann Ihnen helfen zu bestimmen, wie viele Ausfallzeiten akzeptabel sind, welche potenziellen Kosten für Ihr Unternehmen anfallen und welche Funktionen während einer Wiederherstellung erforderlich sind.

Architekt für Zuverlässigkeit

Verwenden Sie beim Erstellen einer Cloud-Anwendung Folgendes, um die Zuverlässigkeit zu erhöhen.

  1. Definieren Sie die Anforderungen.

    Definieren Sie Ihre Verfügbarkeits- und Recovery-Anforderungen basierend auf den Workloads, die Sie in die Cloud und die Geschäftsanforderungen bringen.

  2. Wenden Sie Best Practices für die Architektur an.

    Befolgen Sie bewährte Vorgehensweisen, identifizieren Sie mögliche Fehlerpunkte in der Architektur, und bestimmen Sie, wie die Anwendung auf Fehler reagiert.

  3. Testen Sie mit Simulationen und erzwungenen Failovers.

    Simulieren Sie Fehler, lösen Sie erzwungene Failover aus, und testen Sie die Erkennung und Wiederherstellung nach diesen Fehlern.

  4. Stellen Sie Anwendungen konsistent bereit.

    Freigabe in die Produktion mit zuverlässigen und wiederholbaren Prozessen und nach Möglichkeit Automatisierung.

  5. Überwachen Sie den Anwendungszustand.

    Erkennen Sie Fehler, überwachen Sie Indikatoren potenzieller Fehler, und messen Sie den Zustand Ihrer Anwendungen.

  6. Managen Sie Misserfolge und Katastrophen.

    Ermitteln Sie, wann ein Fehler auftritt, und legen Sie anhand der festgelegten Strategien fest, wie er behoben werden soll.

Anforderungen definieren

Definieren Sie Ihre Verfügbarkeits- und Recovery-Anforderungen basierend auf den Workloads, die Sie in die Cloud und die Geschäftsanforderungen bringen.

Berücksichtigen Sie Folgendes, wenn Sie Ihre Geschäftsanforderungen ermitteln, und passen Sie Ihren Zuverlässigkeitsplan an diese an:

  • Identifizieren von Workloads und deren Anforderungen

    Eine Workload ist eine eindeutige Funktion oder Aufgabe, die in Bezug auf Geschäftslogik und Datenspeicheranforderungen logisch von anderen Workloads getrennt ist. Jede Workload hat unterschiedliche Anforderungen an Verfügbarkeit, Skalierbarkeit, Datenkonsistenz und Disaster Recovery.

  • Verwendungsmuster bestimmen

    Die Verwendung einer Anwendung spielt bei den Anforderungen eine Rolle. Ermitteln Sie Unterschiede bei den Anforderungen in kritischen und nicht kritischen Perioden. Beispiel: Eine Anwendung, die eine Verarbeitung am Monatsende verarbeitet, kann während des Monatsendes nicht erfolgreich verlaufen, kann jedoch zu anderen Zeiten einen Fehler verarbeiten. Um die Betriebszeit zu gewährleisten, können während kritischer Zeiträume zusätzliche Komponenten oder Redundanzen hinzugefügt und entfernt werden, wenn sie keinen Mehrwert mehr bieten.

  • Wichtige Komponenten und Pfade identifizieren

    Nicht alle Komponenten Ihres Systems sind möglicherweise so wichtig wie andere. Beispiel: Sie verfügen über eine optionale Komponente, die einen inkrementellen Wert hinzufügt, die Workload jedoch bei Bedarf ohne Ausführung ausgeführt werden kann. Verstehen Sie, wo sich diese Komponenten befinden, und umgekehrt, wo sich die kritischen Teile Ihrer Workload befinden. Dadurch können Sie Ihre Verfügbarkeits- und Zuverlässigkeitsmetriken eingrenzen und Ihre Wiederherstellungsstrategien so planen, dass die wichtigsten Komponenten priorisiert werden.

  • Externe Abhängigkeiten und die Auswirkungen von Downstream-Ausfällen identifizieren

    Wenn Ihre Workload von externen Services abhängt, kann sich ein Ausfall dieser Abhängigkeiten negativ auf die Verfügbarkeit der Workload auswirken. Implementieren Sie Methoden zur Entkopplung der Integration, um nachgelagerte Ausfälle zu isolieren.

  • Anforderungen an die Workload-Verfügbarkeit bestimmen

    High Availability (HA) wird in der Regel als Ziel für die Betriebszeit definiert. Ein HA-Ziel von 99% bedeutet beispielsweise, dass eine bestimmte Ressource 3,65 Tage im Jahr nicht verfügbar sein kann. Oracle Cloud Infrastructure (OCI) ist so konzipiert, dass Sie eine hochverfügbare Umgebung erhalten. OCI veröffentlicht ein Service Level Agreement (SLA) für jeden seiner Services, das die Verpflichtungen von Oracle hinsichtlich Verfügbarkeit und Konnektivität zu diesen Services beschreibt, und Sie sollten diese prüfen, um zu sehen, wie sie Ihren Anforderungen entsprechen. Einige Services auf OCI verfügen über ein hohes HA-Niveau, insbesondere von Oracle verwaltete Services wie die autonome Datenbank. Um sicherzustellen, dass eine Anwendungsarchitektur Ihre Geschäftsanforderungen erfüllt, definieren Sie Ziel-SLAs für jede Workload, einschließlich externer Abhängigkeiten. Berücksichtigen Sie neben den Anwendungsabhängigkeiten die Kosten und die Komplexität der Erfüllung der Verfügbarkeitsanforderungen.

  • Legen Sie Ihre Recovery-Metriken fest – Recovery Time Ziel (RTO) und Recovery Point Ziel (RPO)

    RTO ist die maximal zulässige Zeit, die eine Anwendung nach einem Katastrophenvorfall nicht verfügbar sein kann.

    RPO ist die maximale Dauer des Datenverlusts, die bei einer Katastrophe akzeptabel ist.

    Um diese Werte abzuleiten, führen Sie eine Risikobewertung durch und stellen Sie sicher, dass Sie die Kosten und das Risiko von Ausfallzeiten oder Datenverlust in Ihrem Unternehmen verstehen.

    Inkrementelle Backups für Speicher bieten Sicherheit vor Datenverlust über Recovery Points. Der Zeitraum zwischen den einzelnen Backups begrenzt die maximale Datenmenge, die nach der Wiederherstellung aus einem Backup verloren geht.

    Beispiel: Sie können eine der vordefinierten Backup-Policys von Oracle für den OCI Block Volumes-Speicher verwenden: Bronze, Silber und Gold. Jede Backup-Policy besteht aus Zeitplänen mit einer festgelegten inkrementellen Backuphäufigkeit, wie monatlich, wöchentlich oder täglich, und einem definierten Aufbewahrungszeitraum.

  • Eine Katastrophe definieren

    Gut dokumentierte Disaster Recovery-Pläne und -Anforderungen sind wichtig, aber die chaotische Natur eines solchen Ereignisses kann Verwirrung stiften. Verstehen Sie, was eine Katastrophe für Ihr Unternehmen darstellt, identifizieren Sie Schlüsselrollen, die während einer Katastrophe benötigt werden, und erstellen Sie einen klar definierten Kommunikationsplan, um eine Katastrophenreaktion einzuleiten.

  • Kosten berücksichtigen

    Aus der Perspektive von FinOps betrachten Sie die Kostenauswirkungen verschiedener Zuverlässigkeitsstrategien. Auf diese Weise können Sie fundierte Entscheidungen über Ihre Verfügbarkeits- und Wiederherstellungsanforderungen treffen.

Best Practices für Architekturen anwenden

Konzentrieren Sie sich beim Entwurf Ihrer Architektur auf Implementierungspraktiken, die Ihren Geschäftsanforderungen entsprechen, Fehlerpunkte identifizieren und den Umfang von Fehlern minimieren.

Beachten Sie die folgenden Best Practices:

  • Bestimmen, wo Fehler auftreten können

    Analysieren Sie Ihre Architektur, um die Arten von Fehlern zu identifizieren, die Ihre Anwendung möglicherweise hat, die potenziellen Auswirkungen jeder einzelnen Recovery-Strategie und mögliche Recovery-Strategien.

  • Ermitteln Sie den erforderlichen Redundanzgrad basierend auf Ihren HA- und DR-Anforderungen

    Die Redundanz, die für jede Workload erforderlich ist, hängt von Ihren Geschäftsanforderungen und den Gesamtkosten Ihrer Anwendung ab.

  • Design für Skalierbarkeit

    Eine Cloud-Anwendung muss skalierbar sein, um Änderungen bei der Nutzung gerecht zu werden. Beginnen Sie mit diskreten Komponenten, und entwerfen Sie die Anwendung so, dass sie nach Möglichkeit automatisch auf Ladeänderungen reagiert. Beachten Sie beim Design die Skalierungsgrenzen, damit Sie in Zukunft problemlos expandieren können.

  • Load Balancing zum Verteilen von Anforderungen verwenden

    Beim Load Balancing werden die Anforderungen Ihrer Anwendung an fehlerfreie Serviceinstanzen verteilt, indem fehlerhafte Instanzen aus der Rotation entfernt werden. Durch die Externalisierung von Statusinformationen wird die Backend-Skalierung für den Endbenutzer transparent. Wenn der Status in der Session verfolgt wird, ist möglicherweise eine Stickiness erforderlich.

  • Bauen Sie Verfügbarkeits- und Resilienzanforderungen in Ihrem Design auf

    Ausfallsicherheit ist die Fähigkeit eines Systems, nach Ausfällen wiederherzustellen und weiter zu funktionieren. Verfügbarkeit ist der Anteil der Zeit, die Ihr System funktionsfähig und funktionsfähig ist. Implementieren Sie Best Practices für High Availability, wie die Vermeidung einzelner Fehlerquellen und die Zersetzung von Workloads nach Service-Level-Ziel. Nutzen Sie die Standardfeatures Ihrer Datenebene, wie die Anwendungskontinuität und asynchrone Transaktionen, um sowohl Verfügbarkeit als auch Resilienz sicherzustellen.

  • DR implementieren

    Entwerfen Sie Ihre Lösung, um die angegebenen RTO- und RPO-Anforderungen zu erfüllen. Stellen Sie sicher, dass Sie alle Komponenten Ihrer DR-Lösung in Ihrem RTO online setzen können. Schützen Sie Ihre Daten, damit Sie Ihr RPO erfüllen können. Die Art und Weise, wie Daten gespeichert, gesichert und repliziert werden, ist von entscheidender Bedeutung.

    • Sichern Sie Ihre Daten

      Auch bei einer vollständig replizierten DR-Umgebung sind regelmäßige Backups nach wie vor von entscheidender Bedeutung. Sichern und validieren Sie Daten regelmäßig, und stellen Sie sicher, dass kein einziges Benutzerkonto Zugriff auf Produktions- und Backupdaten hat.

    • Replikationsmethoden für Ihre Anwendungsdaten auswählen

      Ihre Anwendungsdaten werden in verschiedenen Datenspeichern gespeichert und können unterschiedliche Verfügbarkeitsanforderungen haben. Bewerten Sie die Replikationsmethoden und Speicherorte für jeden Datenspeichertyp, um sicherzustellen, dass sie Ihren HA-Anforderungen und RPO entsprechen.

    • Verstehen Sie die Auswirkungen eines Failovers und dessen Auswirkungen auf die Katastrophenbereitschaft

      Müssen Sie eine andere Region für die Replikation instanziieren, um Ihre Workloads zu erfüllen? Müssen Sie sich beim Failback um die Datenkonsistenz kümmern?

    • Failover- und Failback-Prozesse dokumentieren und testen

      Dokumentieren Sie klare Anweisungen zum Failover zu einem neuen Datenspeicher, und testen Sie sie regelmäßig, um sicherzustellen, dass sie korrekt und einfach zu befolgen sind.

    • Stellen Sie sicher, dass der Datenwiederherstellungsplan Ihrem RTO entspricht

      Stellen Sie sicher, dass Ihre Backup- und Replikationsstrategie Datenwiederherstellungszeiten bereitstellt, die Ihrem RTO und Ihrem RPO entsprechen. Berücksichtigen Sie alle Arten von Daten, die Ihre Anwendung verwendet, einschließlich Referenzdaten, Dateien und Datenbanken.

Periodische Tests mit Simulationen und erzwungenen Failovers

Um auf Zuverlässigkeit zu testen, muss gemessen werden, wie die End-to-End-Workload unter Ausfallbedingungen abläuft, die nur intermittierend auftreten.

  • Testen Sie häufige Fehlerszenarios, indem Sie tatsächliche Fehler auslösen oder sie simulieren

    Verwenden Sie Fault-Injection-Tests, um häufige Szenarios (einschließlich Kombinationen von Fehlern) und Recovery-Zeit zu testen.

  • Fehler identifizieren, die nur unter Last auftreten

    Testen Sie mithilfe von Produktionsdaten oder synthetischen Daten, die möglichst nah an Produktionsdaten sind, auf Spitzenlast, um zu sehen, wie sich die Anwendung unter realen Bedingungen verhält.

  • Disaster Recovery-Drills ausführen

    Führen Sie einen Disaster Recovery-Plan durch, und testen Sie ihn regelmäßig, um sicherzustellen, dass er funktioniert.

  • Failover- und Failback-Tests ausführen

    Stellen Sie sicher, dass das Failover der abhängigen Services Ihrer Anwendung und das Failback in der richtigen Reihenfolge durchgeführt werden.

  • Simulationstests ausführen

    Das Testen von realen Szenarien kann Probleme hervorheben, die behoben werden müssen. Szenarios sollten steuerbar und für das Unternehmen unterbrechungsfrei sein. Informiert die Verwaltung von Simulationstestplänen.

  • Testzustandssonden

    Konfigurieren Sie Health Probes für Load Balancer und Traffic Manager, um kritische Systemkomponenten zu prüfen. Testen Sie sie, um sicherzustellen, dass sie angemessen reagieren.

  • Testüberwachungssysteme

    Stellen Sie sicher, dass Überwachungssysteme zuverlässig kritische Informationen und genaue Daten melden, um potenzielle Ausfälle zu identifizieren.

  • Drittanbieterservices in Testszenarios einschließen

    Testen Sie mögliche Fehlerquellen aufgrund von Serviceunterbrechungen von Drittanbietern zusätzlich zur Wiederherstellung.

  • Bei Tests aufgetretene Probleme

    Wenn Tests Probleme oder Lücken aufdecken, stellen Sie sicher, dass sie identifiziert und behoben werden, indem Sie zusätzliche Überwachungs- oder Anpassungsprozesse hinzufügen.

Anwendungen konsistent bereitstellen

Das Deployment umfasst das Provisioning von Oracle Cloud Infrastructure-(OCI-)Services und -Ressourcen, das Deployment von Anwendungscode und das Anwenden von Konfigurationseinstellungen. Ein Update kann alle drei Aufgaben oder eine Teilmenge davon umfassen.

  • Automatisieren Sie Ihren Anwendungsbereitstellungsprozess

    Automatisieren Sie so viele Prozesse wie möglich. Wenn möglich, sollten manuelle Bereitstellungen in der Produktion eliminiert werden, obwohl dies in niedrigeren Umgebungen akzeptabel sein kann, um Geschwindigkeit und Flexibilität zu fördern.

  • Nutzen Sie die Automatisierung, um Ihren Code vor der Bereitstellung zu testen

    Tests auf Bugs, Sicherheitslücken, Funktionalität, Performance und Integrationen sind von entscheidender Bedeutung, um Probleme zu minimieren, die Endbenutzer entdecken. Testfehler sollten verhindern, dass Code in die Produktion freigegeben wird.

  • Entwerfen Sie Ihren Freigabeprozess, um die Verfügbarkeit zu maximieren

    Wenn Ihr Releaseprozess erfordert, dass Services während des Deployments offline gesetzt werden, ist Ihre Anwendung nicht verfügbar, bis sie wieder online sind. Profitieren Sie von den Features für Plattform-Staging und -Produktion. Wenn möglich, geben Sie neue Deployments für eine Teilmenge von Benutzern frei, um Fehler in einer frühen Stunde zu überwachen.

  • Rollback-Plan für Deployment vorhanden

    Entwerfen Sie einen Rollback-Prozess, um zu einer letzten bekannten guten Version zurückzukehren und Ausfallzeiten zu minimieren, wenn ein Deployment nicht erfolgreich verläuft. Die Automatisierung des Rollbacks bei nicht erfolgreichem Deployment kann unnötige Ausfallzeiten verhindern.

  • Log- und Audit-Deployments

    Wenn Sie zwischengespeicherte Deployment-Techniken verwenden, werden mehrere Versionen Ihrer Anwendung in der Produktionsumgebung ausgeführt. Implementieren Sie eine robuste Loggingstrategie, um so viele versionsspezifische Informationen wie möglich zu erfassen.

  • Dokumentieren des Anwendungsfreigabeprozesses

    Definieren und dokumentieren Sie Ihren Freigabeprozess klar und stellen Sie sicher, dass er für das gesamte Operations-Team verfügbar ist.

Anwendungszustand überwachen

Implementieren Sie Best Practices für Überwachung und Alerts in Ihrer Anwendung, damit Sie Fehler erkennen und einen Operator warnen können, um sie zu beheben.

  • Tracing für Serviceaufrufe implementieren

    Baseline-Performancedaten können dazu beitragen, Trenddaten bereitzustellen, mit denen Performanceprobleme proaktiv identifiziert werden können, bevor sie sich auf Benutzer auswirken.

  • Health Probes implementieren

    Führen Sie sie regelmäßig von außerhalb der Anwendung aus, um eine Beeinträchtigung der Anwendungsintegrität und -performance zu ermitteln. Diese Sonden sollten mehr sein als nur statische Seitentests, sie sollten den ganzheitlichen Anwendungszustand widerspiegeln.

  • Workflows mit langer Ausführungszeit prüfen

    Das frühzeitige Abfangen von Problemen kann die Notwendigkeit minimieren, den gesamten Workflow zurückzusetzen oder mehrere Vergütungstransaktionen auszuführen.

  • System-, Anwendungs- und Auditlogs verwalten

    Verwenden Sie einen zentralen Logging-Service, um Ihre Logs zu speichern.

  • Frühwarnsystem einrichten

    Identifizieren Sie die Key Performance Indicators (KPIs) des Zustands einer Anwendung, z. B. vorübergehende Ausnahmen und Remote Call Latenz, und legen Sie für jede Anwendung geeignete Schwellenwerte fest. Senden Sie einen Alert an Vorgänge, wenn der Schwellenwert erreicht ist.

  • Mehrere Operatoren trainieren, um die Anwendung zu überwachen und manuelle Recovery-Schritte auszuführen

    Stellen Sie sicher, dass immer mindestens ein geschulter Operator aktiv ist.

Fehler und Katastrophen verwalten

Erstellen Sie einen Recovery-Plan, und stellen Sie sicher, dass er die Datenwiederherstellung, Netzwerkausfälle, abhängige Serviceausfälle und regionsweite Serviceunterbrechungen abdeckt. Berücksichtigen Sie Ihre VMs, Speicher, Datenbanken und andere OCI-Services in Ihrer Wiederherstellungsstrategie.

  • Planung für Incident Management

    Definieren Sie klare Rollen und Verantwortlichkeiten für das Incident Management, um Services am Laufen zu halten, oder stellen Sie sie so schnell wie möglich wieder her.

  • Notfallwiederherstellungsplan dokumentieren und testen

    Erstellen Sie einen Disaster Recovery-Plan, der die geschäftlichen Auswirkungen von Anwendungsfehlern widerspiegelt. Automatisieren Sie den Wiederherstellungsprozess so weit wie möglich und dokumentieren Sie alle manuellen Schritte. Testen Sie regelmäßig Ihren Disaster Recovery-Prozess, um den Plan zu validieren und zu verbessern.

  • Wichtige Rollen für die DR-Koordination kennen

    Stellen Sie sicher, dass die DR-Bemühungen gut koordiniert sind und Anwendungen basierend auf dem Geschäftswert priorisiert werden.

  • Auf Anwendungsfehler vorbereiten

    Bereiten Sie sich auf eine Reihe von Fehlern vor, darunter Fehler, die automatisch behandelt werden, Fehler, die zu einer verringerten Funktionalität führen, und Fehler, die dazu führen, dass die Anwendung nicht mehr verfügbar ist. Die Anwendung sollte Benutzer über vorübergehende Probleme informieren.

  • Datenbeschädigung überwinden

    Wenn ein Fehler in einem Datenspeicher auftritt, prüfen Sie auf Dateninkonsistenzen, wenn der Speicher wieder verfügbar wird, insbesondere wenn die Daten repliziert wurden. Stellen Sie beschädigte Daten aus einem Backup wieder her.

  • Netzausfall überwinden

    Möglicherweise können Sie gecachte Daten verwenden, um lokal mit reduzierter Anwendungsfunktionalität auszuführen. Wenn nicht, können Sie Ausfallzeiten von Anwendungen in Betracht ziehen oder ein Failover zu einer anderen Region vornehmen. Speichern Sie Ihre Daten an einem alternativen Speicherort, bis die Konnektivität wiederhergestellt ist.

  • Einen abhängigen Servicefehler überwinden

    Bestimmen Sie, welche Funktionalität noch verfügbar ist und wie die Anwendung reagieren soll.

  • Eine regionsweite Serviceunterbrechung überwinden

    Regionsweite Serviceunterbrechungen sind ungewöhnlich, aber Sie sollten eine Strategie haben, um sie zu beheben, insbesondere bei kritischen Anwendungen. Möglicherweise können Sie die Anwendung erneut in einer anderen Region bereitstellen oder Traffic neu verteilen.

  • Aus DR-Tests lernen und Prozesse verbessern

    Stellen Sie sicher, dass während des DR-Tests aufgetretene Probleme erfasst und Pläne zur Behebung dieser Probleme in zukünftigen Tests oder Failovers behoben werden.

Weitere Informationen