0

What is the best infrastructure setup for M2 with varnish on AWS with Auto Scaling Group

We have the following setup now

Cloudflare -> ELB -> AWS Auto scaling group EC2 (+ RDS database + media on EBS volumen )

Right now we have set maximum instances to 1 instance in the Auto scaling group, because when we set maximum instances higher we have issues, when AWS removes EC2 instances from the AWS auto Scaling Group, then some customers get varnish 503 backend fetch failed error.

How can we fix this, what is the proper setup?

Best regards, Jesper

1
  • the question - where is varnish in this setup??
    – MagenX
    Dec 9, 2020 at 20:21

1 Answer 1

1

I can only speak about Varnish here. The open source version of Varnish doesn't have autoscaling and clustering capabilities. However, Varnish Enterprise does offer this.

Normally you'd have to buy a license upfront to benefit from these features, but we also offer official AMIs of Varnish Enterprise, which do not require the upfront purchase of a license. The license fee is calculated by the hour and processed by AWS.

Setting up High Availability

Varnish Enterprise has High Availability capabilities, for which all dependencies are available on our official AMI.

One of which is the Varnish broadcaster. This is a tool that broadcasts HTTP traffic to various Varnish nodes. The inventory of nodes is stored in /etc/varnish/nodes.conf.

Here's a hypothetical example:

[group1]
node1 = http://1.2.3.4
node2 = http://1.2.3.5
node3 = http://1.2.3.6

[group2]
node4 = http://1.2.3.7
node5 = http://1.2.3.8
node6 = http://1.2.3.9

More information about nodes.conf can be found here.

Enabling the broadcaster happens as follows:

sudo systemctl enable broadcaster
sudo systemctl start broadcaster

Once the broadcaster knows what the Varnish inventory is, you can activate High Availability in your VCL:

include "vha6/vha_auto.vcl";

sub vcl_init {
    vha6_opts.set("token", "secret123");
    call vha6_token_init;
}

More information about the vha6_opts options can be found here. One example is narrowing down the replication scope by only using one group from nodes.conf. This is done by configurating vha6_opts.set("broadcaster_group", "group1"); for example.

Configuring autoscaling

Once objects are replicated throughout your Varnish cluster. It is important that the nodes.conf inventory stays up-to-date when your autoscaling group changes the number of active machines.

A utility we have to deal with this is Varnish Discovery. It is also installed within the official AMI for AWS. It runs as a systemd service

If you run sudo systemctl edit --full varnish-discovery, this is what you can get:

[Unit]
Description=Varnish Discovery
#After=network-online.target
#Requisite=network-online.target

[Service]
ExecStart=/usr/bin/varnish-discovery aws --group your-autoscaling-group --nodefile /etc/varnish/nodes.conf --warnpid /run/vha-agent/vha-agent.pid
[Install]
WantedBy=multi-user.target

Please modify the settings accordingly and run sudo systemctl restart varnish-discovery to activate the changes, and to have the discovery service monitor your autoscaling group.

Enabling and starting the service happens as follows:

sudo systemctl enable varnish-discovery
sudo systemctl start varnish-discovery

End result

And every time the AWS autoscaling group changes, varnish-discovery will notice this, it will modify nodes.conf and reload broadcaster by using the PID that is inside /run/varnish-broadcaster/broadcaster.pid.

This will make sure that broadcaster always has the right inventory. When a new object is inserted into Varnish, the Varnish High Availability tools will leverage the broadcaster to distribute this new object insertion across the cluster.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.