SearchVarnish Enterprise
The Varnish Enterprise offering has Enterprise at its core, as most components interact with it in one way or another. Though installing Enterprise first is recommended, some other components (like the Varnish Administration Console) can be installed independently.
Varnish Enterprise packages are published to two Package Cloud repositories:
varnishplus/60-enterprise: public, no Package Cloud token required. Packages installed from this repository require a Varnish Enterprise license file on the server. This is the recommended path for new installations.varnishplus/60: token-enabled. Packages installed from this repository do not require a separate license file. Use this if your account already uses a Package Cloud token.Installing Varnish Enterprise is a two step process:
varnish-plus package with your distribution’s package manager.See the Packages page for a full and up-to-date list.
Varnish Enterprise is supported on 64-bit systems with Intel or AMD processors (x64).
The public varnishplus/60-enterprise repository is hosted on packagecloud.io, which provides detailed manual instructions for both deb-based and rpm-based systems.
The quickest way to get started is the install script:
curl -s https://packagecloud.io/install/repositories/varnishplus/60-enterprise/script.deb.sh | sudo bash
apt-get install varnish-plus
curl -s https://packagecloud.io/install/repositories/varnishplus/60-enterprise/script.rpm.sh | sudo bash
dnf install epel-release
dnf install varnish-plus
Packages installed from this repository require a Varnish Enterprise license file to start accepting traffic. See Managing your license file for how to install and manage the license, then continue to the After installation section.
If you don’t have a license yet, contact your account manager or use the contact us page.
If your account uses a Package Cloud token, see Token-based deb/rpm installation to generate the exact commands for your environment. Packages installed this way do not require a separate license file on the server.
Installations from the public repository require a license file. This section explains how to load, refresh and inspect it. (Installations from the token-enabled repository can skip this section.)
There are multiple ways to load a license file in Varnish Enterprise.
/etc/varnish/varnish-enterprise.licPlace the file at the path /etc/varnish/varnish-enterprise.lic prior to Varnish startup. With this method, Varnish will discover and load the file automatically.
$VARNISH_LICENSEA path to a license file may be provided in the environment variable VARNISH_LICENSE. Varnish will inspect this variable on startup and load the file from the provided path.
-L fileA license file may also be provided on the varnishd command line:
-L /path/to/license
If no license file is loaded, Varnish will start up and do all of its initialization, except for enabling its listen sockets for accepting traffic.
A license file may be loaded at runtime via varnishadm:
# varnishadm license.load /path/to/license
A new license file may be loaded without interrupting service. Issuing
# varnishadm license.load /path/to/new/file
will load the specified file.
It is also possible to issue varnishadm license.load without any file name argument, and the file will be reloaded from the same location as previously specified.
license.statusThe license.status CLI command outputs a simple JSON response giving the status of the currently loaded license:
# varnishadm license.status
{
"status": "valid"
}
license.showlicense.show outputs a JSON document containing all properties and the associated values for the currently loaded license:
# varnishadm license.show
{
"product": "Varnish Enterprise",
"company": "ACME Corporation",
"shortname": "acmecorp",
"shutdown": "2028-06-30",
"no_restart": "(null)",
"vtcmode": "(null)",
"version": "(null)",
"features": "(null)",
"expiration": "2028-03-30",
"signature": "QEErYDuY5chC"
}
varnishstat: LICENSE.expiryThe LICENSE.expiry counter in varnishstat shows the number of seconds until the license expires:
$ varnishstat -1 -f LICENSE.expiry
LICENSE.expiry 60970342 51978.13 Duration until license expires
This checks the installed Varnish version, which could be helpful to include when submitting a support request. Note: Version may have changed from example below
The -V argument will output the exact varnishd version installed on your system (which should be varnish-plus):
[root@Your-Machine ~]# varnishd -V
varnishd (varnish-plus-6.0.11r4 revision 676b15e5f7393eb5d5700df47ea504055db032d4)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2023 Varnish Software AS
Enable the service and verify that it’s running:
[root@Your-Machine ~]# systemctl enable --now varnish && systemctl status varnish
● varnish.service - Varnish Cache Plus, a high-performance HTTP accelerator
Loaded: loaded (/usr/lib/systemd/system/varnish.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2023-08-09 23:26:28 UTC; 13min ago
Process: 16004 ExecStart=/usr/sbin/varnishd -a :6081 -a
localhost:8443,proxy -T localhost:6082 -S /etc/varnish/secret -p feature=+http2 -r vcc_allow_inline_c -r allow_exec >
Main PID: 16005 (varnishd)
Tasks: 223
Memory: 156.4M
CGroup: /system.slice/varnish.service
├─16005 /usr/sbin/varnishd -a :6081 -a localhost:8443,proxy -T localhost:6082 -S /etc/varnish/secret -p feature=+http2 -r vcc_allow_inline_c -r allow_exec -f /etc/>
└─16015 /usr/sbin/varnishd -a :6081 -a localhost:8443,proxy -T localhost:6082 -S /etc/varnish/secret -p feature=+http2 -r vcc_allow_inline_c -r allow_exec -f /etc/>
Aug 09 23:26:28 AMSI-Machine varnishd[16005]: Debug: Version: varnish-plus-6.0.11r4 revision 676b15e5f7393eb5d5700df47ea504055db032d4
Aug 09 23:26:28 AMSI-Machine varnishd[16005]: Debug: Platform: Linux,4.18.0-477.10.1.el8_8.x86_64,x86_64,-junix,-smse,-hcritbit
Aug 09 23:26:28 AMSI-Machine varnishd[16005]: Version: varnish-plus-6.0.11r4 revision 676b15e5f7393eb5d5700df47ea504055db032d4
Aug 09 23:26:28 AMSI-Machine varnishd[16005]: Platform: Linux,4.18.0-477.10.1.el8_8.x86_64,x86_64,-junix,-smse,-hcritbit
Aug 09 23:26:28 AMSI-Machine varnishd[16005]: Debug: Child (16015) Started
Aug 09 23:26:28 AMSI-Machine varnishd[16005]: Child (16015) Started
Aug 09 23:26:28 AMSI-Machine varnishd[16005]: Child launched OK
Aug 09 23:26:28 AMSI-Machine varnishd[16005]: Child (16015) said
Child starts
Aug 09 23:26:28 AMSI-Machine systemd[1]: Started Varnish Cache Plus,
a high-performance HTTP accelerator.
Aug 09 23:26:28 AMSI-Machine; varnishd[16005]: Child (16015) said
Environment mse fully populated in 0.00 seconds. (0.00 0.00 0.00 0 0 0/1 0 0 0 0)
Using cURL against localhost at port 6081 indicates that Varnish is listening and responding to incoming traffic coming.
Run the following:
[root@Your-Machine ~]# curl -I localhost:6081
It should return something like this:
HTTP/1.1 503 Backend fetch failed
Date: Wed, 09 Aug 2023 23:29:22 GMT
Server: Varnish
Content-Type: text/html; charset=utf-8
Retry-After: 5
X-Varnish: 2
Age: 0
Via: 1.1 varnish (Varnish/6.0)
Content-Length: 278
Connection: keep-alive
The X-Varnish and Via headers confirm that we are, indeed, talking to Varnish.
To find out more about OS:
[root@Your-Machine ~]# cat /etc/os-release
Transparent Huge Pages is a Linux kernel feature to improve performance by more efficiently using a processors’ memory mapping hardware. This is a feature that is enabled by default on most recent Linux distributions.
The approach in Varnish is to assume no huge page is delivered by default and
it will explicitly request huge pages when it is a known benefit for
performance. It is therefore recommended to configure the system to disable
huge pages by default but to honor explicit huge page requests by setting the
policy to madvise.
Alternatively, setting the setting to never can be used safely but some
optimisations within Varnish will have no effect.
The procedure to configure THP will vary based on the distribution being used. Please consult with the manual for your distribution for the correct steps to take.
For example, on RHEL 7 and later to configure THP add or modify the
transparent_hugepage=madvise kernel parameter in /etc/default/grub.
The shared memory log contains files and directories used for Varnishd process logs and counters for consumers such as varnishncsa and
varnishlog. In some circumstances, writing these files to disk-based media (e.g. SSD and NVMe) will become a performance bottleneck.
We recommended mounting the /var/lib/varnish/ directory as a tmpfs
file system. The size of the tmpfs mount shall be, at least, three times the size of the varnishd parameter, vsl_space (default: 80 MB).
Stop any running Varnish processes before proceeding
Creating a (temporary) mount on a Linux system is accomplished by running this command
mount -t tmpfs -o mode=1777,size=240m vworkdir /var/lib/varnish/
To verify that the directory is properly mounted, run the command
findmnt /var/lib/varnish
The response should be as follows:
TARGET SOURCE FSTYPE OPTIONS
/var/lib/varnish vworkdir tmpfs rw,relatime,size=245760k,inode64
To make /var/lib/varnish a persistent tmpfs mount, run the following commands
echo "tmpfs /var/lib/varnish tmpfs rw,relatime,size=240m" >> /etc/fstab
systemctl daemon-reload
mount /var/lib/varnish
The Linux kernel has a global system-wide parameter controlling how many memory maps processes are allowed to use. When a process needs more maps than allowed the operation fails indicating no memory could be allocated. This will often result in a Varnish panic and crash even when there is plenty of physical memory available in the system.
The global parameter is changed using the sysctl value vm.max_map_count and
it should be configured at a value high enough for Varnish to operate,
a value of 262144 or above is highly recommended.
While some distributions have a default value that is much higher than what Varnish requires other distributions like RHEL leverage a very conservative value.
The currently enforced value on the system can be read in multiple ways:
[root@Your-Machine ~]# sysctl vm.max_map_count
vm.max_map_count = 262144
[root@Your-Machine ~]# cat /proc/sys/vm/max_map_count
262144
When the value is lower than 262144, the value must be changed using sysctl, and this change must be persisted or it will reset upon next server boot. The following commands persist the change, reload the sysctl configuration and verify the enforced value:
[root@Your-Machine ~]# echo "vm.max_map_count=262144" > /etc/sysctl.d/99-vm-max-map-count.conf
[root@Your-Machine ~]# sysctl --system
[root@Your-Machine ~]# sysctl vm.max_map_count
vm.max_map_count = 262144
[root@Your-Machine ~]# cat /proc/sys/vm/max_map_count
262144
For more detailed information please refer to the documentation of the Linux kernel and of your distribution.
In 6.0, many Varnish modules (VMODs) are embedded in the varnish-plus
package and no extra installation is required.
Modules with third-party package dependencies (libcurl, libmemcached) are
available in a separate package called varnish-plus-vmods-extra. This
package is not installed by default. In EL9, some of these dependencies are
satisfied by packages from the CodeReady Builder (CRB) repository. If you’d
like to install varnish-plus-vmods-extra, please enable the CRB repository first:
# Only needed if dnf config-manager is not installed
sudo dnf install -y 'dnf-command(config-manager)'
sudo dnf config-manager --set-enabled crb
sudo dnf install varnish-plus-vmods-extra
The CodeReady Builder repository has different name depending on what OS you
are using. In AlmaLinux 9 and Rocky Linux 9 its called crb. With Red Hat
Enterprise Linux 9 the actual name depends on the cloud provider but should
usually contain codeready-builder-for-rhel:
sudo dnf config-manager --set-enabled '*codeready-builder-for-rhel*'
The command dnf repolist --all will print the exact name of all available
repositories, including the CodeReady Builder repository.
The source code for some of these VMODs are available at https://github.com/varnish/varnish-modules/.