Leitfaden zur Betriebsbaseline für Azure Red Hat OpenShift

Azure Red Hat OpenShift stellt bei Bedarf hochverfügbare, vollständig verwaltete OpenShift-Cluster zur Verfügung. Wenn Sie Ihre Lösung korrekt entwerfen und dabei die Verwaltung und Überwachung im Hinterkopf behalten, sind Sie auf einem guten Weg zu einem optimalen Betrieb und Kundenerfolg.

Überlegungen zum Entwurf

Berücksichtigen Sie die folgenden Faktoren:

• Sehen Sie sich die Azure Red Hat OpenShift-Zuständigkeitsmatrix an, um zu verstehen, wie Zuständigkeiten für Cluster zwischen Microsoft, Red Hat und Kunden geteilt werden.
• Beachten Sie die Grenzwerte für Azure-VMs und die unterstützten Regionen. Stellen Sie sicher, dass Sie über Kapazität zum Bereitstellen von Ressourcen verfügen.
• Informieren Sie sich, wie Sie Workloads logisch in einem Cluster und physisch in separaten Clustern isolieren können.
• Informieren Sie sich, wie Sie sicherstellen können, dass Kubernetes die Integrität Ihrer Workloads bewerten kann.
• Informieren Sie sich über die verschiedenen VM-Größen und die Auswirkungen ihrer Verwendung.
• Prüfen Sie Möglichkeiten zum Überwachen und Protokollieren von Azure Red Hat OpenShift, um Einblick in die Integrität Ihrer Ressourcen zu erhalten und potenzielle Probleme vorherzusehen. Sowohl der Cluster als auch die darauf ausgeführten Anwendungen können viele Ereignisse generieren. Verwenden Sie Warnungen, damit Sie besser zwischen verlaufsbezogenen Protokolleinträgen und Einträgen, die sofortige Maßnahmen erfordern, unterscheiden können.
• Achten Sie auf wichtige Systemupdates und -upgrades. Kritische Patchupdates werden von Azure Red Hat OpenShift Site Reliability Engineers (SRE) automatisch auf Cluster angewendet. Kunden, die Patchupdates vorab installieren möchten, können dies tun.
• Informieren Sie sich über Ressourcenbeschränkungen des Clusters und einzelner Workloads.
• Machen Sie sich mit den Unterschieden zwischen der horizontalen automatischen Podskalierung und der automatischen Clusterskalierung vertraut.
• Überprüfen Sie den Supportlebenszyklus, und machen Sie sich mit der Richtlinie zur Versionsunterstützung vertraut. Azure Red Hat OpenShift unterstützt nur die aktuellen und vorherigen allgemein verfügbaren Nebenversionen von Red Hat OpenShift Container Platform. Supportanfragen erfordern, dass eine unterstützte Version für den Cluster verwendet wird.
• Überprüfen Sie die Clusterkonfigurationsanforderungen, um die Unterstützung des Clusters sicherzustellen.
• Überprüfen Sie das namespaceübergreifende Netzwerk, um den Datenverkehr innerhalb des Clusters mithilfe einer Netzwerkrichtlinie zu sichern.

Entwurfsempfehlungen

• Azure Red Hat OpenShift verfügt über ein umfassendes Ökosystem für Operatoren und sollte verwendet werden, um operative Aktivitäten effizient und genau durchzuführen und zu automatisieren.
• Fügen Sie Ihren Pods Integritätstests hinzu, um die Anwendungsintegrität zu überwachen. Stellen Sie sicher, dass Pods livenessProbe und readinessProbe enthalten. Verwenden Sie Starttests, um den Punkt zu ermitteln, an dem die Anwendung gestartet wurde.
• Verwenden Sie VM-Größen, die groß genug sind, um mehrere Containerinstanzen zu enthalten, damit Sie von erhöhter Dichte profitieren können. Sie sollten jedoch nicht so groß sein, dass Ihr Cluster die Workload eines fehlerhaften Knotens nicht bewältigen kann.
• Steuern Sie Clusterfunktionen mithilfe von Zugangs-Plug-Ins, die häufig verwendet werden, um Sicherheitsrichtlinien, Ressourcenbeschränkungen oder Konfigurationsanforderungen zu erzwingen.
• Verwenden Sie Podanforderungen und -grenzwerte, um die Computeressourcen in einem Cluster zu verwalten. Podanforderungen und -grenzwerte informieren den Kubernetes-Scheduler darüber, welche Computeressourcen einem Pod zugewiesen werden sollen. Schränken Sie den Ressourcenverbrauch in einem Projekt mithilfe von Grenzwertbereichen ein.
• Optimieren Sie die CPU- und Speicheranforderungswerte, und maximieren Sie die Effizienz der Clusterressourcen mit der vertikalen automatischen Podskalierung.
• Die OpenShift-Webkonsole enthält alle Metriken auf Knotenebene. Richten Sie mithilfe der integrierten Prometheus- oder Container Insights-Integration einen Überwachungsprozess ein.
  • Prometheus ist vorinstalliert und für Azure Red Hat OpenShift 4.x-Cluster konfiguriert.
  • Container Insights kann durch Onboarding des Clusters in Kubernetes mit Azure Arc-Unterstützung aktiviert werden.
  • Die OpenShift-Protokollierung stellt Protokollaggregatoren, Speicher und Visualisierungskomponenten bereit.
• Automatisieren Sie den Anwendungsbereitstellungsprozess mithilfe von DevOps-Methoden und CI/CD-Lösungen (Continuous Integration und Continuous Delivery), z. B. Pipelines/GitOps von OpenShift Container Platform.
• Definieren Sie ClusterAutoScaler und MachineAutoScaler, um Computer zu skalieren, wenn in Ihrem Cluster nicht mehr genügend Ressourcen für weitere Bereitstellungen verfügbar sind.
• Stellen Sie Integritätsprüfungen für Computer bereit, um beschädigte Computer in einem Computerpool automatisch zu reparieren.
• Skalieren Sie Pods, um den Bedarf mithilfe der horizontalen automatischen Podskalierung zu erfüllen.
• Verwenden Sie ein Warnungssystem, um Benachrichtigungen bereitzustellen, wenn sofortige Maßnahmen erforderlich sind: Metrikwarnungen von Container Insights oder die integrierte Alerting UI.

Geschäftskontinuität und Notfallwiederherstellung (Business Continuity Disaster Recovery, BCDR)

Ihre Organisation muss geeignete Azure Red Hat OpenShift-Funktionen auf Plattformebene entwickeln, um ihre spezifischen Anforderungen zu erfüllen. Diese Anwendungsdienste weisen Anforderungen in Bezug auf Recovery Time Objective (RTO) und Recovery Point Objective (RPO) auf. Im Zusammenhang mit der Notfallwiederherstellung müssen mehrere Überlegungen angestellt werden. Ihr erster Schritt besteht darin, eine Vereinbarung zum Servicelevel (SLA) für Ihre Infrastruktur und Anwendung zu definieren. Erfahren Sie mehr über die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) für Azure Red Hat OpenShift. Informationen zu monatlichen Uptimeberechnungen finden Sie im Abschnitt SLA-Details.

Überlegungen zum Entwurf für Business Continuity & Disaster Recovery (BCDR)

Berücksichtigen Sie die folgenden Faktoren:

• Der Azure Red Hat OpenShift-Cluster sollte mehrere Computergruppen verwenden, um die Mindestverfügbarkeit für Ihre Anwendung sicherzustellen.
• Legen Sie Podanforderungen und -grenzwerte fest. Das Festlegen dieser Grenzen ermöglicht Kubernetes Folgendes:
  • Effizientes Zuweisen von CPU- und Arbeitsspeicherressourcen für die Pods
  • Verwendung einer höheren Containerdichte auf einem Knoten.
  • Verbessern der Zuverlässigkeit mit geringeren Kosten durch bessere Hardwarenutzung
• Verteilen von Knoten auf alle verfügbaren Zonen, um die Verfügbarkeit zu verbessern
  • Wählen Sie eine Region, die Verfügbarkeitszonen unterstützt.
  • Um alle Vorteile aus den Zonen schöpfen zu können, müssen alle Dienstabhängigkeiten ebenfalls Zonen unterstützen. Wenn ein abhängiger Dienst keine Zonen unterstützt, kann ein Zonenausfall dazu führen, dass bei diesem Dienst ein Fehler auftritt. Überprüfen Sie die Datenträgertypen, die beim Verteilen der Workload auf Zonen verwendet werden.
  • Führen Sie für eine höhere Verfügbarkeit, die über die Möglichkeiten von Verfügbarkeitszonen hinausgeht, mehrere Cluster in verschiedenen Regionspaaren aus. Wenn eine Azure-Ressource Georedundanz unterstützt, geben Sie den Standort an, an dem der redundante Dienst seine sekundäre Region aufweisen wird.
• Erstellen Sie beständig Sicherungen für Anwendungen und Daten.
  • Ein nicht zustandsbehafteter Dienst kann effizient repliziert werden.
  • Wenn Sie den Zustand im Cluster speichern müssen, sichern Sie die Daten häufig in der gekoppelten Region.
• Aktualisieren und warten Sie Ihre Cluster.
  • Halten Sie Ihren Cluster immer auf dem neuesten Stand. Überprüfen Sie, ob Clusterupgrades verfügbar sind.
  • Beachten Sie den Release- und Einstellungsprozess.
  • Steuern sie Upgrades mithilfe von Zeitplänen.
  • Überprüfen Sie die Notwendigkeit eines Canary-Rolloutupdates für kritische Workloads.
• Netzwerkkonnektivität bei einem Failover:
  • Wenn Sie Datenverkehr über Regionen hinweg verteilen müssen, sollten Sie Azure Front Door in Erwägung ziehen.
• Geplante und ungeplante Failover:
  • Wählen Sie bei der Einrichtung der einzelnen Azure-Dienste Features aus, die die Notfallwiederherstellung unterstützen. Wenn beispielsweise Azure Container Registry (ACR) ausgewählt wird, aktivieren Sie den ACR-Dienst für die Georeplikation. Wenn eine Region ausfällt, können Sie weiterhin Images aus dem replizierten Bereich pullen.
• Verwalten Sie DevOps-Entwicklungsfunktionen, um Ziele für den Servicelevel zu erreichen.

Entwurfsempfehlungen für Business Continuity & Disaster Recovery (BCDR)

Im Folgenden finden Sie bewährte Methoden für Ihren Entwurf:

• Azure Red Hat OpenShift-Cluster werden mit drei Knoten auf Steuerungsebene und mindestens drei Workerknoten bereitgestellt. Stellen Sie sicher, dass der Cluster in einer Region erstellt wird, die Verfügbarkeitszonen unterstützt, damit die Knoten auf die Zonen verteilt werden.
• Stellen Sie diese Knoten für Hochverfügbarkeit in verschiedenen Verfügbarkeitszonen bereit. Da Sie für jede Verfügbarkeitszone unterschiedliche Computergruppen benötigen, erstellen Sie mindestens drei Computergruppen.
• Führen Sie keine zusätzlichen Workloads auf den Knoten auf Steuerungsebene aus. Sie können zwar auf den Knoten der Steuerungsebene geplant werden, dies führt aber zu zusätzlicher Ressourcenauslastung sowie Stabilitätsproblemen, die sich auf den gesamten Cluster auswirken können.
• Erstellen Sie Infrastrukturcomputergruppen für Infrastrukturkomponenten. Wenden Sie spezifische Kubernetes-Bezeichnungen auf diese Computer an, und aktualisieren Sie dann die Infrastrukturkomponenten, sodass sie nur auf diesen Computern ausgeführt werden.
• Entfernen Sie nach Möglichkeit den Dienststatus aus Containern. Verwenden Sie stattdessen einen Azure-Platform-as-a-Service (PaaS), der die Replikation in mehreren Regionen unterstützt.
• In Bereitstellungen sollten Podressourcenanforderungen angegeben werden. Der Planer kann den Pod dann ordnungsgemäß planen. Die Zuverlässigkeit nimmt deutlich ab, wenn Pods nicht geplant sind.
• Richten Sie mehrere Replikate in der Bereitstellung ein, um Unterbrechungen wie Hardwarefehler zu behandeln. Bei geplanten Ereignissen wie Updates und Upgrades kann ein Unterbrechungsbudget sicherstellen, dass die erforderliche Anzahl von Podreplikaten für die erwartete Anwendungslast vorhanden ist.
• Verwenden Sie Einschränkungen der Podtopologie, um Pods auf Knoten im gesamten Cluster automatisch zu planen.
• Ihre Anwendungen verwenden möglicherweise Speicher für ihre Daten und sollten bei Bedarf die Verfügbarkeit in allen Regionen sicherstellen:
  • Mithilfe von RWX-Speicher mit der integrierten Azure Files-Speicherklasse
  • Mithilfe von CSI-Treibern für die Speicherbereitstellung
• Erstellen Sie Anwendungssicherungen, und planen Sie die Wiederherstellung:
  • Schließen Sie persistente Volumes in die Sicherung ein.
• Schätzen Sie Podressourcengrenzwerte ab. Testen und erstellen Sie eine Baseline. Beginnen Sie mit gleichen Werten für Anforderungen und Grenzwerte. Optimieren Sie diese Werte dann nach und nach, bis Sie einen Schwellenwert festgelegt haben, der eine Instabilität im Cluster verursachen kann. Podgrenzwerte können in Ihren Bereitstellungsmanifesten angegeben werden. Die vertikale automatische Podskalierung optimiert die CPU- und Arbeitsspeicheranforderungswerte und kann die Effizienz von Clusterressourcen maximieren.
  • Die integrierten Features können Fehler und Unterbrechungen in der Dienstarchitektur behandeln. Diese Konfigurationen tragen dazu bei, sowohl den Entwurf als auch die Bereitstellung zu automatisieren. Wenn eine Organisation einen Standard für SLA, RTO (Recovery Time Objective) und RPO (Recovery Point Objective) definiert hat, kann sie in Kubernetes und Azure integrierte Dienste verwenden, um Geschäftsziele zu erreichen.
• Erwägen Sie Blau-Grün- oder Canary-Strategien, um neue Releases von Anwendungen bereitzustellen.
• Legen Sie zum Sicherstellen der Verfügbarkeit die Podpriorität/Budgets für die Unterbrechung von Pods fest, um die Anzahl von Podreplikaten zu beschränken, die der Cluster für Wartungsvorgänge herunterfahren kann.
• Erzwingen Sie Ressourcenkontingente für Dienstnamespaces. Das Ressourcenkontingent für einen Namespace stellt sicher, dass Podanforderungen und -grenzwerte für eine Bereitstellung ordnungsgemäß festgelegt werden.
  • Das Festlegen von Ressourcenkontingenten auf Clusterebene kann Probleme beim Bereitstellen von Partnerdiensten verursachen, die nicht über angemessene Anforderungen und Grenzwerte verfügen.
• Speichern Sie Ihre Containerimages in Azure Container Registry, und replizieren Sie die Registrierung per Georeplikation in jeder Region.
• Verwenden Sie mehrere Regionen und Peeringstandorte für Azure ExpressRoute-Verbindungen. Eine redundante hybride Netzwerkarchitektur kann bei einem Ausfall einer Azure-Region oder eines Peering-Anbieterstandorts dazu beitragen, eine unterbrechungsfreie, standortübergreifende Konnektivität zu gewährleisten.
• Verbinden Sie Regionen mit globalem Peering virtueller Netzwerke. Wenn die Cluster miteinander kommunizieren müssen, verbinden Sie die beiden virtuellen Netzwerke über Peering virtueller Netzwerken miteinander. Diese Technologie verbindet virtuelle Netzwerke miteinander und bietet auch über geografische Regionen hinweg eine hohe Bandbreite im Backbonenetzwerk von Microsoft.
• Verwenden Sie das Split TCP-basierte Anycast-Protokoll Azure Front Door Service, um Ihre Endbenutzer mit dem nächstgelegenen Front Door-POP (Point of Presence) zu verbinden. Weitere Features von Azure Front Door sind:
  • TLS-Terminierung
  • Benutzerdefinierte Domäne
  • Web Application Firewall
  • URL Rewrite
  • Sitzungsaffinität

Nächste Schritte

Erfahren Sie mehr über Überlegungen und Empfehlungen zum Entwurf für die Plattformautomatisierung und DevOps in Ihren Azure-Zielzonen.