Stratus Panel - Autoscaling

Auto-scaling is one of the most powerful features of Webscale STRATUS. Auto-scaling keeps a store functioning even during periods of higher than usual traffic.

Configuration of Webscale STRATUS Autoscaling does require some initial configuration. In order to fully benefit from this feature, we recommend that you contact Stratus support for assistance.

How does autoscaling work?

When high traffic occurs on a Magento store, the code that is processed by PHP — the core Magento code — quickly becomes the bottleneck. Autoscaling resolves these bottlenecks by replicating the PHP code as “containers” across additional physical hardware instances in the AWS cloud.

Certain directories, such as /media/ and /var/ are not replicated, as these are generally static files that require greater consistency. These directories are shared across all the PHP containers.

STRATUS Autoscaling only applies to the PHP-FPM code. Except in certain special cases — where MageMojo creates custom autoscaling configurations — STRATUS Autoscaling does not automatically scale MySQL, Redis, Memcache, Elasticsearch, Varnish, or Nginx. Scaling these resources are not normally required.

Enabling Autoscaling

NOTE: Symlinks must use absolute paths in order for autoscaling to work properly.

  1. Go to Autoscaling in the STRATUS sidebar menu.

    • Autoscaling with Zero Downtime Deployments Enabled — Select Autoscaling with Zero Downtime Deployments Enabled This is also splits a cron container to a separate dedicated services node to reduce load.

    • Make Code Immutable — Select Make Code Immutable. This option makes replicated Magento code in PHP-FPM containers immutable, by that, enhancing security compliance. Autoscaling must be enabled to use this feature.

      Note: Enabling these options will cause a redeploy of services.

    • Directories to Include — by default this includes the common directories for Magento 1 or 2 based on the setting chosen under the Magento > STRATUS Template panel. Generally, this includes all core code that does not experience changes during normal production operation. These directories will be copied out to additional physical nodes during a scaling event. This should include files and folders that will not be written to during normal operation. Static theme files and code are included by default. If you have extra frameworks like Wordpress or custom scripts, you should include those directories.

    • Directories to Exclude — this section is either empty or contains pub/media as a Magento default. Large directories containing extraneous files or code not required by the Production environment should be included in this field. Excludes should match the shared folders, especially if you are including part of them in the Includes section. Any large media directories should be excluded. Otherwise scaling will take a very long time as those assets are copied over our network to additional hardware. And you should exclude large subfolders if the parent folder is in the include list. For example, you want to include pub/ for a Magento 2 store, but not include pub/media since it is very large. The exclusion ensures the subfolder is not copied but the rest of the parent folder is copied.

    • Shared Mounts — by default this is var/ and media/ (or pub/media on Magento 2) directories. Both of these directories experience writes such as cache images or logs during production operation and need to be accessed by all running PHP-FPM containers. Shared mounts are mounted over the network from the home node for your environment. The Magento media folder is the primary folder you need and var, since both folders experience frequent writes (log files or media cache). And most media folders are too large copy out and duplicating media would lead to split brain i.e. a captcha image can be generated on one node but not appear on another if the directory is not shared.

  2. Click DEPLOY CODE to apply the change. This may result in 1-2 minutes of downtime.

Updating Code

If Autoscaling is enabled, you can click DEPLOY CODE to relaunch services and refresh any scaled containers. For a Zero Downtime use the STRATUS CLI commands zerodowntime.init and zerodowntime.switch.

Our general recommendation is to never change production code during high volume traffic/sales except in emergencies.

Troubleshooting

  • Some pages are not loading or showing a 404 — check your includes to be sure the code is properly copied to additional services.
  • Weird behavior or PHP errors — check the PHP error and Magento error logs; there is likely some code that not being included and causing an error. This can also be related to using relative symlinks instead of absolute. You can correct those with the following command: find ./ -type l -execdir bash -c 'ln -sfn "$(readlink -f "$0")" "$0"' {} \;
  • Images are not showing with Autoscaling and Mirasvit SEO — Under Stores > Configuration > Mirasvit in the Magento Admin, set Enable SEO-friendly URLs for product images to Disabled. (seo/image/is_enable_image_friendly_url = 0)
  • CSS is missing or page structure is not rendering correctly Check the following:
    1. Under Stores > Configuration > Advanced > Developer > Template Settings in the Magento Admin, set Minify HTML to No. (dev/css/minify_html = 0)
    2. Under Stores > Configuration > Advanced > Developer, in Developer mode, set Allow Symlinks to Yes. (dev/template/allow_symlink = 1 (true))
    3. If you use the module Aitoc_Compressor, make sure that you exclude & share the folder pub/static/_aitoc_compressor
    4. If you use the module Potato_Compressor, make sure that you exclude & share the folder pub/static/_po_compressor
  • Environment takes longer than expected to redeploy services — Make sure there are no large dumps or backups stored in the Magento root directory. Every time php-fpm containers are redeployed, all files, including dumps and backups, are copied and will extend boot time and the ability of your environment to scale on demand quickly.
  • Crons stop running after deployment - When using a deployment tool such as Jenkins, Capistrano, Deployer or similar where deployment changes/recreates a new symlink, please note that you should clear the var/cron directory afterward and empty the cron_schedule table in the database.

 

 


Last modified January 1, 0001