Schaalbare architectuur

De Cloud-infrastructuur wordt geschaald op basis van uw vereisten voor bronnen voor een hogere efficiëntie. De Adobe Commerce op cloudinfrastructuur bewaakt uw toepassingen en kan de capaciteit aanpassen om stabiele, voorspelbare prestaties te behouden. Het omzetten in deze architectuur helpt om problemen, zoals latentie of grote pieken in verkeer te verlichten.

Architectuur op gesplitste niveaus

De Pro-architectuur bestond uit drie knooppunten, die elk een volledige technologiestapel bevatten. Nu, is er een scalable infrastructuur die een gelaagde architectuur met een minimum van zes knopen verstrekt: drie knopen voor het kerngegevensbestand en de diensten en drie knopen voor de Webserver. Deze gesplitste architectuur biedt de mogelijkheid om lagen onafhankelijk te schalen om een optimale balans van prestaties te bereiken.

Serviceniveau

Er zijn drie de dienstknopen voor gegevensopslag, geheime voorgeheugen, en de diensten: OpenSearch of Elasticsearch, MariaDB, Redis, en meer. Wanneer de servicelaag de capaciteit nadert, kunt u alleen schalen door de grootte van de server te vergroten, bijvoorbeeld door de CPU-stroom en het geheugen op te voeren. De capaciteit is beperkt tot de grootte van de knoop die beschikbaar is. Omdat de gegevensbestandcluster voor hoge beschikbaarheid wordt ontworpen, kunt u niet horizontaal met de gebruikte technologieën schrapen.

Overweeg een voorbeeld dat het de instantietype van de de dienstknoop m5.2xlarge met 32-Gb RAM is. Een service, zoals de database, gebruikt een aanzienlijke hoeveelheid geheugen (30 Gb). Het schrapen aan de volgende beschikbare instantiegrootte m5.4xlarge verstrekt 64-Gb RAM, die het geheugen verdubbelt en de groeiende behoeften van het gegevensbestand aanpast.

U kunt de prestaties van de de dienstrij verder optimaliseren door verkeer te verpletteren dat op het knooptype wordt gebaseerd. Door gebrek, wordt de gegevensbestandknoop geïsoleerd van het Webverkeer. Als voorbeeld kunt u ervoor kiezen om het webverkeer op het databaseknooppunt te bedienen.

Weblaag

Er zijn drie Webknopen voor verwerkingsverzoeken en Webverkeer: php-fpm en NGINX. Naast verticale schaling door meer stroom en geheugen te gebruiken, kan de weblaag ook horizontaal worden geschaald door webservers toe te voegen aan een bestaande cluster wanneer deze beperkt zijn op PHP-niveau. Zie Auto het schrapenleren hoe de Webknopen automatisch schrapen.

Dit vult de verticale schaling aan die door de de dienstrij wordt verstrekt. Aangezien de de dienstrij in grootte en macht schrapt om een groeiend gegevensbestand en de dienstgebruik aan te passen, de Webrijschaal in grootte, macht, en instanties om een toename van procesverzoeken en hogere verkeersvereisten aan te passen.

Overweeg een voorbeeld dat het de instantietype van de Webknoop C5.2xlarge met acht cpu en 16-Gb RAM is. Het aantal verzoeken aan de plaats nam sterk toe. U kunt een C5.2xlarge knoop toevoegen om de toename in php-fpm processen te behandelen of u kunt elk instantietype in C5.4xlarge met 16 cpu en 32-Gb RAM veranderen. Als u een knooppunt toevoegt, neemt het risico van onvoldoende piekcapaciteit af.

Projectstructuur

Minimaal, hebben de Pro projecten met de Schaalde architectuur zes beschikbare knopen.

Elk project is echter uniek en vereist prestatiebewaking om het beheer van bronnen correct te analyseren. Elke rekening omvat de dienst van New Relic, die automatisch met de toepassingsgegevens en prestatiesanalyses verbindt om dynamische servercontrole te verstrekken. Specifiek, kunt u de dienst van New Relic gebruiken om het gebruik van cpu en van RAM te controleren om te bepalen welke knopen extra middelen vereisen. Wanneer een bron capaciteit bereikt of wanneer de prestaties achteruitgaan op basis van de analyse, kunt u een verzoek maken om uw infrastructuur te schalen om aan de vraag te voldoen.

SSH-toegang

Bepaalde bestanden en logbestanden, zoals de map /app/<project-id>/var/log , worden niet gedeeld tussen knooppunten. Elk knooppunt heeft een unieke SSH-toegang. U kunt de CLI van magento-cloud niet gebruiken om zich aan te melden bij de dienst of de Webknopen, maar u kunt de knoopadressen in de lijst van de Toegang van SSH in uw Cloud Console vinden.

ssh <node>.<project-ID>-<environment>-<user-ID>@ssh.<region>.magento.com

De reactie van het voorbeeld aangezien u login aan a de dienstknoop omvat verenigde rol:

 __  __                   _          ___ _             _
|  \/  |__ _ __ _ ___ _ _| |_ ___   / __| |___ _  _ __| |
| |\/| / _` / _` / -_) ' \  _/ _ \ | (__| / _ \ || / _` |
|_|  |_\__,_\__, \___|_||_\__\___/  \___|_\___/\_,_\__,_|
            |___/

 Welcome to Magento Cloud.

 This is server unique-server-id, role project-id:unified.

project-id@server-id:~$

De reactie van het voorbeeld aangezien u login aan a Webknoop omvat de Web rol:

 __  __                   _          ___ _             _
|  \/  |__ _ __ _ ___ _ _| |_ ___   / __| |___ _  _ __| |
| |\/| / _` / _` / -_) ' \  _/ _ \ | (__| / _ \ || / _` |
|_|  |_\__,_\__, \___|_||_\__\___/  \___|_\___/\_,_\__,_|
            |___/

 Welcome to Magento Cloud.

 This is server unique-server-id, role project-id:web.

project-id@server-id:~$

Loglocaties

De logboekplaatsen variëren lichtjes afhankelijk van de knoop. Bijvoorbeeld, is een gegevensbestandlogboek, zoals het MySQL foutenlogboek, beschikbaar op een de dienstknoop (/var/log/mysql/mysql-error.log), maar het is niet beschikbaar op een Webknoop.

Elke Pro rekening omvat de dienst van Logboeken van New Relic, die automatisch met logboekgegevens van de toepassing verbindt om dynamisch logboekbeheer te verstrekken. Samengevoegde loggegevens van alle knooppunten worden weergegeven in de toepassing New Relic Logs, zodat u problemen met de prestaties van specifieke knooppunten op één dashboard kunt oplossen.