Pro-architectuur

Uw Adobe Commerce on cloud Infrastructure Pro-architectuur ondersteunt meerdere omgevingen die u kunt gebruiken om uw winkel te ontwikkelen, te testen en te starten.

De volgende tabel geeft een overzicht van de verschillen tussen omgevingen:

Omgevingsarchitectuur

Uw project is één Git-opslagplaats met drie belangrijke omgevingsvertakkingen: integration, staging en production . Het volgende diagram toont de hiërarchische verhouding van Pro milieu's:

Hoofdomgeving

Bij Pro-projecten biedt de master -vertakking een actieve PaaS-omgeving met uw productieomgeving. Duw altijd een exemplaar van de productiecode aan het master milieu zodat u het productiemilieu kunt zuiveren zonder de diensten te onderbreken.

beveats:

Integratieomgeving

De integratieomgeving wordt uitgevoerd in een Linux-container (LXC) op een raster met servers die PaaS wordt genoemd. Elke omgeving bevat een webserver en database waarmee u uw site kunt testen. Zie Regionale IP Adressenvoor een lijst van AWS en Azure IP adressen.

Aanbevolen gebruiksgevallen:

De milieu's van de integratie worden ontworpen voor beperkte test en ontwikkeling alvorens veranderingen in het opvoeren en productiemilieu's te bewegen. U kunt bijvoorbeeld de integratieomgeving gebruiken om de volgende taken uit te voeren:

Voor de beste prestaties in de integratieomgeving volgt u de volgende aanbevolen procedures:

beveats:

Stationele omgeving

De testomgeving biedt een omgeving voor bijna-productie om uw site te testen. Deze omgeving, die wordt gehost op toegewezen IaaS-hardware, omvat alle services, zoals Fastly CDN, New Relic APM en zoeken.

Aanbevolen gebruiksgevallen:

De omgeving komt overeen met de productiearchitectuur en is ontworpen voor UAT, inhoudstaging en definitieve revisie voordat de functies naar de production -omgeving worden verplaatst. U kunt bijvoorbeeld de staging -omgeving gebruiken om de volgende taken uit te voeren:

Zie het werkschema van de Plaatsingen plaatsing van de Test.

beveats:

Productieomgeving

De productieomgeving voert uw openbare, naar wens enkelvoudige en multisite winkels uit. Deze omgeving wordt uitgevoerd op toegewezen IaaS-hardware met redundante knooppunten met hoge beschikbaarheid voor continue toegang en failover-beveiliging voor uw klanten. Het productiemilieu omvat alle diensten in het opvoeren milieu, plus de dienst van de Infrastructuur van New Relic (NRI), die automatisch met de toepassingsgegevens en prestatiesanalyses verbindt om dynamische servercontrole te verstrekken.

Beveat:

U kunt geen vertakking maken van de production -vertakking. In plaats daarvan verandert de code van de staging -vertakking in de production -vertakking.

Stapel productietechnologie

De productieomgeving heeft drie virtuele machines (VM's) achter een Elastic Load Balancer die wordt beheerd door een HAProxy per VM. Elke VM bevat de volgende technologieën:

De volgende afbeelding toont de technologieën die in de productieomgeving worden gebruikt:

Redundante hardware

Eerder dan het in werking stellen van een traditioneel, actief-passief master of een primair-secundaire opstelling, stelt Adobe Commerce op wolkeninfrastructuur a overtollige architectuur in werking waar alle drie instanties lezen en schrijven goedkeuren. Deze architectuur biedt geen onderbreking wanneer het schrapen aan en verstrekt gewaarborgde transactionele integriteit.

Vanwege de unieke, redundante hardware kan Adobe drie gatewayservers leveren. De meeste externe diensten laten u toe om veelvoudige IP adressen aan een lijst van gewenste personen toe te voegen, zodat heeft meer dan één vast IP adres geen probleem is. De drie gateways wijzen aan de drie servers in uw cluster van het productiemilieu toe en behouden statische IP adressen. Het is volledig overtollig en hoogst beschikbaar op elk niveau:

Back-up en noodherstel

Adobe Commerce op cloudinfrastructuur maakt gebruik van een architectuur met hoge beschikbaarheid die elk Pro-project repliceert op drie aparte AWS- of Azure-beschikbaarheidszones, elke zone met een afzonderlijk datacenter. Naast deze overtolligheid, ontvangen de Pro het opvoeren en productiemilieu's regelmatige, levende steunen die voor gebruik in gevallen van catastrofale mislukking worden ontworpen.

Automatische steunen omvatten blijvende gegevens van alle lopende diensten, zoals het gegevensbestand MySQL en dossiers die op de opgezette volumes worden opgeslagen. De back-ups worden opgeslagen in gecodeerde EBS (Elastic Block Storage) in hetzelfde gebied als de productieomgeving. De automatische steunen zijn niet openbaar toegankelijk omdat zij in een afzonderlijk systeem worden opgeslagen.

U kunt a handsteun van het gegevensbestand voor uw het Opvoeren en milieu's van de Productie tot stand brengen gebruikend bevelen CLI. Zie file het gegevensbestand. Voor integration -omgevingen raadt de Adobe aan een back-up te maken als eerste stap nadat ze uw Adobe Commerce hebben benaderd voor een cloud-infrastructuurproject en voordat ze belangrijke wijzigingen aanbrengen. Zie Reservekopiebeheer.

Doelstelling herstelpunt

RPO is zes uren maximumtijd aan laatste steun (bijvoorbeeld bij 06:00, toen 12:00, toen 18:00). De frequentie van back-ups is afhankelijk van het back-upschema van uw abonnement en het volume van de wijzigingen dat naar de opslagservice moet worden geschreven.

Retentiebeleid

Met Adobe blijven automatische back-ups behouden volgens het volgende beleid voor gegevensopslag:

Dit beleid kan afhankelijk van uw plan van de wolkeninfrastructuur variëren.

Doelstelling hersteltijd

RTO is afhankelijk van de grootte van de opslag. Grote EBS-volumes hebben meer tijd nodig om te herstellen. De hersteltijden kunnen variëren afhankelijk van de grootte van uw database:

Schalen in Pro-clusters

Het Pro cluster rangschikken en verwerkt configuraties afhankelijk van de gekozen wolkenleverancier (AWS, Azure), gebied, en de dienstgebiedsdelen. De de wolkeninfrastructuur van de Adobe kan Pro clusters schrapen om verkeersverwachtingen en de dienstvereisten aan te passen aangezien de vraag verandert.

De overtollige architectuur laat de Adobe wolkeninfrastructuur toe om zonder onderbreking te verhogen. Bij upscaling roteert elk van de drie instanties om de capaciteit te upgraden zonder dat dit invloed heeft op de sitebewerking. U kunt bijvoorbeeld extra webservers toevoegen aan een bestaande cluster als de beperking zich op PHP-niveau bevindt in plaats van op databaseniveau. Dit verstrekt horizontaal schrapen om het verticale schrapen aan te vullen die door extra CPUs op het gegevensbestandniveau wordt verstrekt. Zie Schaalde architectuur.

Als u een significante toename van verkeer voor een gebeurtenis of een andere reden verwacht, kunt u om een tijdelijke verhoging van capaciteit verzoeken. Zie hoe te om een tijdelijke upsizein het Centrum van de Hulp van Commerce te verzoeken.