Pro Architektur

Ihre Adobe Commerce on Cloud Infrastructure Pro-Architektur unterstützt mehrere Umgebungen, mit denen Sie Ihren Store entwickeln, testen und starten können.

Die folgende Tabelle fasst die Unterschiede zwischen Umgebungen zusammen:

Umgebungsarchitektur

Ihr Projekt ist ein einzelnes Git-Repository mit drei Hauptumgebungszweigen: integration, staging, und production. Das folgende Diagramm zeigt die hierarchische Beziehung von Pro-Umgebungen:

Master-Umgebung

Bei Pro-Projekten wird die master -Verzweigung bietet eine aktive PaaS-Umgebung für Ihre Produktionsumgebung. Pushen Sie stets eine Kopie des Produktionscodes an die master -Umgebung, sodass Sie die Produktionsumgebung debuggen können, ohne die Dienste zu unterbrechen.

Einschränkungen:

Integrationsumgebung

Die Integrationsumgebung wird in einem Linux-Container (LXC) auf einem als "PaaS"bekannten Serverraster ausgeführt. Jede Umgebung enthält einen Webserver und eine Datenbank zum Testen Ihrer Site. Siehe Regionale IP-Adressen für eine Liste von AWS- und Azure-IP-Adressen.

Empfohlene Anwendungsfälle:

Integrationsumgebungen sind für begrenzte Tests und Entwicklung ausgelegt, bevor Änderungen in Staging- und Produktionsumgebungen verschoben werden. Beispielsweise können Sie die Integrationsumgebung verwenden, um die folgenden Aufgaben auszuführen:

Befolgen Sie die folgenden Best Practices, um eine optimale Leistung in der Integrationsumgebung zu erzielen:

Einschränkungen:

Staging-Umgebung

Die Staging-Umgebung bietet eine nahezu produktionsorientierte Umgebung zum Testen Ihrer Site. Diese Umgebung, die auf dedizierter IaaS-Hardware gehostet wird, umfasst alle Dienste wie Fastly CDN, New Relic APM und Search.

Empfohlene Anwendungsfälle:

Die Umgebung entspricht der Produktionsarchitektur und ist für UAT, Content Staging und endgültige Überprüfung konzipiert, bevor Funktionen an die production Umgebung. Sie können beispielsweise die staging Umgebung, um die folgenden Aufgaben auszuführen:

Siehe Bereitstellungsarbeitsablauf und Testen der Bereitstellung.

Einschränkungen:

Produktionsumgebung

In der Produktionsumgebung werden Ihre öffentlichen Storefronts mit einzelnen und mehreren Sites ausgeführt. Diese Umgebung wird auf dedizierter iOS-Hardware mit redundanten Hochverfügbarkeitsknoten ausgeführt, die einen kontinuierlichen Zugriff und Failover-Schutz für Ihre Kunden ermöglichen. Die Produktionsumgebung umfasst alle Dienste in der Staging-Umgebung sowie die New Relic Infrastructure (NRI) -Dienst, der automatisch eine Verbindung zu den Anwendungsdaten und Leistungsanalysen herstellt, um eine dynamische Server-Überwachung zu ermöglichen.

Warnung:

Sie können eine Verzweigung nicht über die production -Verzweigung. Stattdessen können Sie Codeänderungen über die staging -Verzweigung production -Verzweigung.

Produktionstechnologie-Stapel

Die Produktionsumgebung verfügt über drei virtuelle Maschinen (VMs) hinter einem Elastic Load Balancer, der von einem HAProxy pro VM verwaltet wird. Jede VM umfasst die folgenden Technologien:

Die folgende Abbildung zeigt die in der Produktionsumgebung verwendeten Technologien:

Redundante Hardware

Anstatt ein traditionelles, aktives Passiv zu betreiben master oder bei einem primären sekundären Setup führt Adobe Commerce in der Cloud-Infrastruktur einen redundante Architektur wobei alle drei Instanzen Lese- und Schreibvorgänge akzeptieren. Diese Architektur bietet keine Ausfallzeiten bei der Skalierung und garantiert Transaktionsintegrität.

Aufgrund der einzigartigen, redundanten Hardware kann Adobe drei Gateway-Server bereitstellen. Die meisten externen Dienste ermöglichen es Ihnen, mehrere IP-Adressen zu einer Zulassungsliste hinzuzufügen, sodass es kein Problem darstellt, mehr als eine feste IP-Adresse zu haben. Die drei Gateways ordnen die drei Server im Cluster der Produktionsumgebung zu und behalten statische IP-Adressen bei. Sie ist vollständig redundant und auf allen Ebenen verfügbar:

Sicherung und Wiederherstellung nach Katastrophen

Adobe Commerce on Cloud Infrastructure verwendet eine Hochverfügbarkeitsarchitektur, die jedes Pro-Projekt in drei separaten AWS- oder Azure-Verfügbarkeitszonen repliziert, wobei jede Zone über ein eigenes Rechenzentrum verfügt. Zusätzlich zu dieser Redundanz erhalten die Staging- und Produktionsumgebungen von Pro regelmäßige Live-Backups, die für die Verwendung in Fällen von Katastrophenversagen.

Automatische Backups enthalten persistente Daten aus allen laufenden Diensten, wie z. B. der MySQL-Datenbank und Dateien, die auf den bereitgestellten Volumes gespeichert sind. Die Sicherungen werden in verschlüsselter Elastic Block Storage (EBS) in derselben Region wie die Produktionsumgebung gespeichert. Die automatischen Sicherungen sind nicht öffentlich zugänglich, da sie in einem separaten System gespeichert sind.

Sie können eine manuelles Backup der Datenbank für Ihre Staging- und Produktionsumgebungen mithilfe von CLI-Befehlen. Siehe Datenbank sichern. Für integration -Umgebungen, empfiehlt Adobe die Erstellung eines Backups als ersten Schritt nach dem Zugriff auf Ihr Adobe Commerce-Projekt in der Cloud-Infrastruktur und vor der Anwendung größerer Änderungen. Siehe Backup-Management.

Ziel des Rückgewinnungspunkts

RPO ist eine maximale Zeitdauer von sechs Stunden bis zum letzten Backup (z. B. um 06:00 Uhr, dann um 12:00 Uhr, dann um 18:00 Uhr). Die Häufigkeit der Backups hängt vom Backup-Zeitplan Ihres Plans und dem Volumen der Änderungen ab, die in den Speicherdienst geschrieben werden sollen.

Bindungsrichtlinie

Adobe behält automatische Sicherungen gemäß der folgenden Datenaufbewahrungsrichtlinie bei:

Diese Richtlinie kann je nach Ihrem Cloud-Infrastrukturplan variieren.

Recovery Time Objective

RTO hängt von der Speichergröße ab. Die Wiederherstellung großer EBS-Volumina nimmt mehr Zeit in Anspruch. Die Wiederherstellungszeiten variieren je nach Größe Ihrer Datenbank:

Pro Cluster-Skalierung

Die Clustergröße von Pro und berechnen -Konfigurationen variieren je nach gewähltem Cloud-Anbieter (AWS, Azure), Region und Service-Abhängigkeiten. Adobe Cloud-Infrastruktur kann Pro-Cluster skalieren, um Verkehrserwartungen und Service-Anforderungen bei sich ändernden Anforderungen gerecht zu werden.

Die redundante Architektur ermöglicht das Hochskalieren der Adobe-Cloud-Infrastruktur ohne Ausfallzeiten. Beim Hochskalieren rotiert jede der drei Instanzen auf die Upgrade-Kapazität, ohne dass sich dies auf den Betrieb des Standorts auswirkt. Beispielsweise können Sie einem vorhandenen Cluster zusätzliche Webserver hinzufügen, wenn die Beschränkung auf PHP-Ebene und nicht auf Datenbankebene erfolgt. Diese horizontale Skalierung um die vertikale Skalierung zu ergänzen, die von zusätzlichen CPUs auf Datenbankebene bereitgestellt wird. Siehe Skalierte Architektur.

Wenn Sie aus einem Ereignis oder aus anderen Gründen einen signifikanten Anstieg des Traffics erwarten, können Sie eine vorübergehende Erhöhung der Kapazität anfordern. Siehe Anfordern einer temporären Größe im Commerce Help Center.