Architettura Pro
L'architettura Pro di Adobe Commerce su infrastruttura cloud supporta più ambienti che è possibile utilizzare per sviluppare, testare e avviare lo store.
- Master - Fornisce un ramo
masterdistribuito nei contenitori Platform as a Service (PaaS). - Integrazione - Fornisce un singolo ramo
integrationper lo sviluppo, anche se è possibile creare un ramo aggiuntivo. Ciò consente di distribuire fino a due rami attivi in Platform as a Service (PaaS). - Gestione temporanea - Fornisce un singolo ramo
stagingdistribuito nei contenitori IaaS (Infrastructure as a Service) dedicati. - Produzione - Fornisce un singolo ramo
productiondistribuito nei contenitori IaaS (Infrastructure as a Service) dedicati.
La tabella seguente riepiloga le differenze tra gli ambienti:
Architettura dell’ambiente
Il progetto è un singolo archivio Git con tre rami dell'ambiente principale: integration, staging e production. Il diagramma seguente mostra la relazione gerarchica degli ambienti Pro:
Ambiente principale
Nei progetti Pro, il ramo master fornisce un ambiente PaaS attivo con l'ambiente di produzione. Inviare sempre una copia del codice di produzione all'ambiente master in modo da poter eseguire il debug dell'ambiente di produzione senza interrompere i servizi.
Avvertenze:
-
non creare un ramo basato sul ramo
master. Utilizza l’ambiente di integrazione per creare rami attivi da sviluppare. -
Non utilizzare l'ambiente
masterper sviluppo, UAT o test delle prestazioni
Ambiente di integrazione
L’ambiente di integrazione viene eseguito in un contenitore Linux (LXC) su una griglia di server noti come PaaS. Ogni ambiente include un server web e un database per testare il sito. Per un elenco degli indirizzi IP di AWS e Azure, vedere Indirizzi IP regionali.
Casi d'uso consigliati:
Gli ambienti di integrazione sono progettati per test e sviluppo limitati prima di spostare le modifiche negli ambienti di staging e produzione. Ad esempio, puoi utilizzare l’ambiente di integrazione per completare le seguenti attività:
-
Assicurati che le modifiche ai processi di integrazione continua (CI) siano compatibili con cloud
-
Verifica i flussi di lavoro critici su pagine chiave come Home, Categoria, Pagina dettagli prodotto (PDP), Pagamento e Amministratore
Per ottenere le migliori prestazioni nell’ambiente di integrazione, segui queste best practice:
-
Limita la dimensione del catalogo: per riferimento, i dati di esempio contengono circa 2.048 prodotti. Prova a ridurre la dimensione del catalogo a circa 4.000-5.000 prodotti.
Per verificare il numero di prodotti nel catalogo, eseguire la seguente query MySQL:code language-sql select distinct count(entity_id) from catalog_product_entity; -
Riduci il numero di gruppi di clienti: troppi gruppi di clienti possono influire sulle prestazioni di indicizzazione e sulle prestazioni complessive.
-
Limita l'utilizzo a uno o due utenti simultanei
-
Disabilita i processi cron ed esegui manualmente in base alle esigenze
Avvertenze:
-
I servizi Fastly CDN e New Relic non sono accessibili in un ambiente di integrazione
-
L’architettura dell’ambiente di integrazione non corrisponde a quella di staging e produzione
-
Non utilizzare l'ambiente
integrationper test di sviluppo, test delle prestazioni o test di accettazione utente (UAT) -
Non utilizzare l'ambiente
integrationper testare la funzionalità B2B per Adobe Commerce -
Impossibile ripristinare il database nell'ambiente di integrazione dalla produzione o dalla gestione temporanea del database
Ambiente di staging
L’ambiente di staging fornisce un ambiente vicino alla produzione per testare il sito. Questo ambiente, ospitato su hardware IaaS dedicato, include tutti i servizi, come Fastly CDN, New Relic APM e search.
Casi d'uso consigliati:
L'ambiente corrisponde all'architettura di produzione ed è progettato per UAT, staging dei contenuti e revisione finale prima di inviare le funzionalità all'ambiente production. È ad esempio possibile utilizzare l'ambiente staging per completare le attività seguenti:
-
Test di regressione rispetto ai dati di produzione
-
Test delle prestazioni con Fastly caching abilitato
-
Testare nuove build invece di applicare patch in Produzione
-
Test UAT per nuove build
-
Test B2B per Adobe Commerce
-
Personalizzare la configurazione cron e testare i processi cron
Vedi Flusso di lavoro di distribuzione e Distribuzione di prova.
Avvertenze:
-
Dopo aver avviato il sito di produzione, utilizza l’ambiente di staging principalmente per testare le patch per le correzioni di bug critici per la produzione.
-
Impossibile creare un ramo dal ramo
staging. È invece possibile inviare le modifiche al codice dal ramointegrational ramostaging.
Ambiente di produzione
L’ambiente di produzione esegue le vetrine singole e multisito rivolte al pubblico. Questo ambiente viene eseguito su hardware IaaS dedicato con nodi ridondanti ad alta disponibilità per garantire ai clienti accesso continuo e protezione da failover. L'ambiente di produzione include tutti i servizi dell'ambiente di staging, oltre al servizio Infrastruttura New Relic (NRI), che si connette automaticamente ai dati dell'applicazione e all'analisi delle prestazioni per fornire un monitoraggio dinamico del server.
Avviso:
Impossibile creare un ramo dal ramo production. È invece possibile inviare le modifiche al codice dal ramo staging al ramo production.
Stack di tecnologia di produzione
L'ambiente di produzione dispone di tre macchine virtuali (VM) dietro un load balancer elastico gestito da un HAProxy per VM. Ogni VM include le seguenti tecnologie:
-
Fastly CDN: cache HTTP e CDN
-
NGINX: server Web che utilizza PHP-FPM, un'istanza con più processi di lavoro
-
GlusterFS—file server per la gestione di tutte le distribuzioni di file statici e la sincronizzazione con quattro mount di directory:
varpub/mediapub/staticapp/etc
-
Redis: un server per macchina virtuale con un solo server attivo e gli altri due come repliche
-
Elasticsearch: ricerca di Adobe Commerce nell'infrastruttura cloud da 2.2 a 2.4.3-p2
-
OpenSearch—cerca Adobe Commerce nell'infrastruttura cloud 2.3.7-p3, 2.4.3-p2, 2.4.4 e versioni successive
-
Galera—cluster di database con un database MySQL MariaDB per nodo con un'impostazione di incremento automatico di tre per ID univoci in ogni database
La figura seguente mostra le tecnologie utilizzate nell’ambiente di produzione:
Hardware ridondante
Anziché eseguire un'installazione tradizionale di tipo attivo-passivo master o primario-secondario, Adobe Commerce su infrastruttura cloud esegue un'architettura ridondante in cui tutte e tre le istanze accettano operazioni di lettura e scrittura. Questa architettura non comporta tempi di inattività durante la scalabilità e garantisce l'integrità delle transazioni.
Grazie all'hardware unico e ridondante, Adobe può fornire tre server gateway. La maggior parte dei servizi esterni consente di aggiungere più indirizzi IP a un inserisco nell'elenco Consentiti di, pertanto la presenza di più indirizzi IP fissi non costituisce un problema. I tre gateway si associano ai tre server del cluster dell’ambiente di produzione e conservano gli indirizzi IP statici. È completamente ridondante e ad alta disponibilità a tutti i livelli:
- DNS
- Rete per la distribuzione dei contenuti (CDN)
- Bilanciatore di carico elastico (ELB)
- Cluster a tre server che comprende tutti i servizi Adobe Commerce, inclusi il database e il server web
Backup e disaster recovery
Adobe Commerce sull’infrastruttura cloud utilizza un’architettura ad alta disponibilità che replica ogni progetto Pro in tre aree di disponibilità di AWS o Azure separate, ciascuna con un centro dati separato. Oltre a questa ridondanza, gli ambienti di staging e produzione Pro ricevono backup regolari e live progettati per essere utilizzati in caso di errore irreversibile.
I backup automatici includono dati persistenti provenienti da tutti i servizi in esecuzione, quali il database MySQL e i file archiviati nei volumi montati. I backup vengono salvati in EBS (Elastic Block Storage) crittografato nella stessa area dell’ambiente di produzione. I backup automatici non sono accessibili pubblicamente perché sono archiviati in un sistema separato.
app/. Per quanto riguarda gli altri file, questi vengono creati/generati dal processo di compilazione e distribuzione e sarà inoltre necessario controllare l'archivio Git per i file rimanenti.Puoi creare un backup manuale del database per gli ambienti di staging e produzione utilizzando i comandi CLI. Vedere Backup del database. Per gli ambienti integration, Adobe consiglia di creare un backup come primo passo dopo aver effettuato l'accesso al progetto Adobe Commerce on Cloud Infrastructure e prima di applicare modifiche importanti. Consulta Gestione backup.
Obiettivo punto di ripristino
L’RPO corrisponde a un tempo massimo di sei ore per l’ultimo backup (ad esempio alle 06:00, quindi alle 12:00, quindi alle 18:00). La frequenza dei backup dipende dalla pianificazione del backup e dal volume di modifiche da scrivere nel servizio di storage.
Criterio di conservazione
Adobe mantiene i backup automatici in base ai seguenti criteri di conservazione dei dati:
Questo criterio può variare a seconda del piano dell’infrastruttura cloud.
Obiettivo del tempo di ripristino
RTO dipende dalle dimensioni dello storage. Il ripristino di volumi EBS di grandi dimensioni richiede più tempo. I tempi di ripristino possono variare a seconda delle dimensioni del database:
- Un database di grandi dimensioni (oltre 200 GB) può richiedere 5 ore
- Un database di medie dimensioni (150 GB) può richiedere 2 ore e mezza
- Un database di piccole dimensioni (60 GB) può richiedere 1 ora
Scalabilità del cluster Pro
Le configurazioni di ridimensionamento del cluster Pro e calcolo variano a seconda delle dipendenze del provider cloud scelto (AWS, Azure), dell'area geografica e del servizio. L’infrastruttura cloud Adobe può scalare i cluster Pro per soddisfare le aspettative di traffico e i requisiti di servizio in base al cambiamento delle richieste.
L’architettura ridondante consente all’infrastruttura cloud Adobe di eseguire l’upscale senza tempi di inattività. Durante l'upscaling, ciascuna delle tre istanze ruota per aggiornare la capacità senza influire sul funzionamento del sito. Ad esempio, puoi aggiungere altri server web a un cluster esistente se la restrizione si trova a livello PHP anziché a livello di database. In questo modo viene fornita la scalabilità orizzontale per integrare la scalabilità verticale fornita dalle CPU aggiuntive a livello di database. Vedi Architettura scalata.
Se prevedi un aumento significativo del traffico per un evento o per un altro motivo, puoi richiedere un aumento temporaneo della capacità. Vedi Come richiedere un upsize temporaneo nel Centro assistenza Commerce.