.\" Man page generated from reStructuredText.
.
.TH VMOD_DIRECTORS 3 "" "" ""
.SH NAME
vmod_directors \- Varnish Directors Module
.
.nr rst2man-indent-level 0
.
.de1 rstReportMargin
\\$1 \\n[an-margin]
level \\n[rst2man-indent-level]
level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
-
\\n[rst2man-indent0]
\\n[rst2man-indent1]
\\n[rst2man-indent2]
..
.de1 INDENT
.\" .rstReportMargin pre:
. RS \\$1
. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
. nr rst2man-indent-level +1
.\" .rstReportMargin post:
..
.de UNINDENT
. RE
.\" indent \\n[an-margin]
.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
.nr rst2man-indent-level -1
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
..
.\" 
.
.\" NB:  This file is machine generated, DO NOT EDIT!
.
.\" 
.
.\" Edit vmod.vcc and run make instead
.
.\" 
.
.SH SYNOPSIS
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
import directors [from "path"] ;

new xround_robin = directors.round_robin()

   VOID xround_robin.add_backend(BACKEND)

   VOID xround_robin.remove_backend(BACKEND)

   BACKEND xround_robin.backend()

new xfallback = directors.fallback(BOOL sticky)

   VOID xfallback.add_backend(BACKEND)

   VOID xfallback.remove_backend(BACKEND)

   BACKEND xfallback.backend()

new xrandom = directors.random()

   VOID xrandom.add_backend(BACKEND, REAL)

   VOID xrandom.remove_backend(BACKEND)

   BACKEND xrandom.backend()

new xhash = directors.hash()

   VOID xhash.add_backend(BACKEND, REAL)

   VOID xhash.remove_backend(BACKEND)

   BACKEND xhash.backend(STRING)

new xshard = directors.shard()

   VOID xshard.set_warmup(REAL probability)

   VOID xshard.set_rampup(DURATION duration)

   VOID xshard.associate(BLOB param)

   BOOL xshard.add_backend(BACKEND backend, [STRING ident], [DURATION rampup])

   BOOL xshard.remove_backend([BACKEND backend], [STRING ident])

   BOOL xshard.clear()

   BOOL xshard.reconfigure(INT replicas)

   INT xshard.key(STRING)

   BACKEND xshard.backend([ENUM by], [INT key], [BLOB key_blob], [INT alt], [REAL warmup], [BOOL rampup], [ENUM healthy], [BLOB param], [ENUM resolve])

   VOID xshard.debug(INT)

new xshard_param = directors.shard_param()

   VOID xshard_param.clear()

   VOID xshard_param.set([ENUM by], [INT key], [BLOB key_blob], [INT alt], [REAL warmup], [BOOL rampup], [ENUM healthy])

   STRING xshard_param.get_by()

   INT xshard_param.get_key()

   INT xshard_param.get_alt()

   REAL xshard_param.get_warmup()

   BOOL xshard_param.get_rampup()

   STRING xshard_param.get_healthy()

   BLOB xshard_param.use()
.ft P
.fi
.UNINDENT
.UNINDENT
.SH DESCRIPTION
.sp
\fIvmod_directors\fP enables backend load balancing in Varnish.
.sp
The module implements load balancing techniques, and also serves as an
example on how one could extend the load balancing capabilities of
Varnish.
.sp
To enable load balancing you must import this vmod (directors).
.sp
Then you define your backends. Once you have the backends declared you
can add them to a director. This happens in executed VCL code. If you
want to emulate the previous behavior of Varnish 3.0 you can just
initialize the directors in vcl_init, like this:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
sub vcl_init {
    new vdir = directors.round_robin();
    vdir.add_backend(backend1);
    vdir.add_backend(backend2);
}
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
As you can see there is nothing keeping you from manipulating the
directors elsewhere in VCL. So, you could have VCL code that would
add more backends to a director when a certain URL is called.
.sp
Note that directors can use other directors as backends.
.SS new xround_robin = directors.round_robin()
.INDENT 0.0
.TP
.B Description
Create a round robin director.
.sp
This director will pick backends in a round robin fashion.
.TP
.B Example
new vdir = directors.round_robin();
.UNINDENT
.SS VOID xround_robin.add_backend(BACKEND)
.INDENT 0.0
.TP
.B Description
Add a backend to the round\-robin director.
.TP
.B Example
vdir.add_backend(backend1);
.UNINDENT
.SS VOID xround_robin.remove_backend(BACKEND)
.INDENT 0.0
.TP
.B Description
Remove a backend from the round\-robin director.
.TP
.B Example
vdir.remove_backend(backend1);
.UNINDENT
.SS BACKEND xround_robin.backend()
.INDENT 0.0
.TP
.B Description
Pick a backend from the director.
.TP
.B Example
set req.backend_hint = vdir.backend();
.UNINDENT
.SS new xfallback = directors.fallback(BOOL sticky=0)
.INDENT 0.0
.TP
.B Description
Create a fallback director.
.sp
A fallback director will try each of the added backends in turn,
and return the first one that is healthy.
.sp
If \fBsticky\fP is set to true, the director will keep using the healthy
backend, even if a higher\-priority backend becomes available. Once the
whole backend list is exhausted, it\(aqll start over at the beginning.
.TP
.B Example
new vdir = directors.fallback();
.UNINDENT
.SS VOID xfallback.add_backend(BACKEND)
.INDENT 0.0
.TP
.B Description
Add a backend to the director.
.sp
Note that the order in which this is done matters for the fallback
director.
.TP
.B Example
vdir.add_backend(backend1);
.UNINDENT
.SS VOID xfallback.remove_backend(BACKEND)
.INDENT 0.0
.TP
.B Description
Remove a backend from the director.
.TP
.B Example
vdir.remove_backend(backend1);
.UNINDENT
.SS BACKEND xfallback.backend()
.INDENT 0.0
.TP
.B Description
Pick a backend from the director.
.TP
.B Example
set req.backend_hint = vdir.backend();
.UNINDENT
.SS new xrandom = directors.random()
.INDENT 0.0
.TP
.B Description
Create a random backend director.
.sp
The random director distributes load over the backends using
a weighted random probability distribution.
The "testable" random generator in varnishd is used, which
enables deterministic tests to be run (See: d00004.vtc).
.TP
.B Example
new vdir = directors.random();
.UNINDENT
.SS VOID xrandom.add_backend(BACKEND, REAL)
.INDENT 0.0
.TP
.B Description
Add a backend to the director with a given weight.
.sp
Each backend will receive approximately 100 * (weight /
(sum(all_added_weights))) per cent of the traffic sent to this
director.
.TP
.B Example
.nf
# 2/3 to backend1, 1/3 to backend2.
vdir.add_backend(backend1, 10.0);
vdir.add_backend(backend2, 5.0);
.fi
.sp
.UNINDENT
.SS VOID xrandom.remove_backend(BACKEND)
.INDENT 0.0
.TP
.B Description
Remove a backend from the director.
.TP
.B Example
vdir.remove_backend(backend1);
.UNINDENT
.SS BACKEND xrandom.backend()
.INDENT 0.0
.TP
.B Description
Pick a backend from the director.
.TP
.B Example
set req.backend_hint = vdir.backend();
.UNINDENT
.SS new xhash = directors.hash()
.INDENT 0.0
.TP
.B Description
Create a hashing backend director.
.sp
The director chooses the backend server by computing a hash/digest
of the string given to .backend().
.sp
Commonly used with \fBclient.ip\fP or a session cookie to get
sticky sessions.
.TP
.B Example
new vdir = directors.hash();
.UNINDENT
.SS VOID xhash.add_backend(BACKEND, REAL)
.INDENT 0.0
.TP
.B Description
Add a backend to the director with a certain weight.
.sp
Weight is used as in the random director. Recommended value is
1.0 unless you have special needs.
.TP
.B Example
vdir.add_backend(backend1, 1.0);
.UNINDENT
.SS VOID xhash.remove_backend(BACKEND)
.INDENT 0.0
.TP
.B Description
Remove a backend from the director.
.TP
.B Example
vdir.remove_backend(backend1);
.UNINDENT
.SS BACKEND xhash.backend(STRING)
.INDENT 0.0
.TP
.B Description
Pick a backend from the backend director.
.sp
Use the string or list of strings provided to pick the backend.
.TP
.B Example
.nf
# pick a backend based on the cookie header from the client
set req.backend_hint = vdir.backend(req.http.cookie);
.fi
.sp
.UNINDENT
.SS new xshard = directors.shard()
.sp
Create a shard director.
.sp
Note that the shard director needs to be configured using at least one
\fBshard.add_backend()\fP call(s) \fBfollowed by a\fP
\fBshard.reconfigure()\fP \fBcall\fP before it can hand out backends.
.sp
_Note_ that due to various restrictions (documented below), it is
recommended to use the shard director on the backend side.
.SS Introduction
.sp
The shard director selects backends by a key, which can be provided
directly or derived from strings. For the same key, the shard director
will always return the same backend, unless the backend configuration
or health state changes. Conversely, for differing keys, the shard
director will likely choose different backends. In the default
configuration, unhealthy backends are not selected.
.sp
The shard director resembles the hash director, but its main advantage
is that, when the backend configuration or health states change, the
association of keys to backends remains as stable as possible.
.sp
In addition, the rampup and warmup features can help to further
improve user\-perceived response times.
.SS Sharding
.sp
This basic technique allows for numerous applications like optimizing
backend server cache efficiency, Varnish clustering or persisting
sessions to servers without keeping any state, and, in particular,
without the need to synchronize state between nodes of a cluster of
Varnish servers:
.INDENT 0.0
.IP \(bu 2
Many applications use caches for data objects, so, in a cluster of
application servers, requesting similar objects from the same server
may help to optimize efficiency of such caches.
.sp
For example, sharding by URL or some \fIid\fP component of the url has
been shown to drastically improve the efficiency of many content
management systems.
.IP \(bu 2
As special case of the previous example, in clusters of Varnish
servers without additional request distribution logic, each cache
will need store all hot objects, so the effective cache size is
approximately the smallest cache size of any server in the cluster.
.sp
Sharding allows to segregate objects within the cluster such that
each object is only cached on one of the servers (or on one primary
and one backup, on a primary for long and others for short
etc...). Effectively, this will lead to a cache size in the order of
the sum of all individual caches, with the potential to drastically
increase efficiency (scales by the number of servers).
.IP \(bu 2
Another application is to implement persistence of backend requests,
such that all requests sharing a certain criterion (such as an IP
address or session ID) get forwarded to the same backend server.
.UNINDENT
.sp
When used with clusters of varnish servers, the shard director will,
if otherwise configured equally, make the same decision on all
servers. In other words, requests sharing a common criterion used as
the shard key will be balanced onto the same backend server(s) no
matter which Varnish server handles the request.
.sp
The drawbacks are:
.INDENT 0.0
.IP \(bu 2
the distribution of requests depends on the number of requests per
key and the uniformity of the distribution of key values. In short,
while this technique may lead to much better efficiency overall, it
may also lead to less good load balancing for specific cases.
.IP \(bu 2
When a backend server becomes unavailable, every persistence
technique has to reselect a new backend server, but this technique
will also switch back to the preferred server once it becomes
healthy again, so when used for persistence, it is generally less
stable compared to stateful techniques (which would continue to use
a selected server for as long as possible (or dictated by a TTL)).
.UNINDENT
.SS Method
.sp
When \fB\&.reconfigure()\fP is called, a consistent hashing circular data
structure gets built from the last 32 bits of SHA256 hash values of
\fI<ident>\fP\fI<n>\fP (default \fIident\fP being the backend name) for each
backend and for a running number \fIn\fP from 1 to \fIreplicas\fP\&. Hashing
creates the seemingly random order for placement of backends on the
consistent hashing ring.
.sp
When \fB\&.backend()\fP is called, a load balancing key gets generated
unless provided. The smallest hash value in the circle is looked up
that is larger than the key (searching clockwise and wrapping around
as necessary). The backend for this hash value is the preferred
backend for the given key.
.sp
If a healthy backend is requested, the search is continued linearly on
the ring as long as backends found are unhealthy or all backends have
been checked. The order of these "alternative backends" on the ring
is likely to differ for different keys. Alternative backends can also
be selected explicitly.
.sp
On consistent hashing see:
.INDENT 0.0
.IP \(bu 2
\fI\%http://www8.org/w8\-papers/2a\-webserver/caching/paper2.html\fP
.IP \(bu 2
\fI\%http://www.audioscrobbler.net/development/ketama/\fP
.IP \(bu 2
svn://svn.audioscrobbler.net/misc/ketama
.IP \(bu 2
\fI\%http://en.wikipedia.org/wiki/Consistent_hashing\fP
.UNINDENT
.SS Error Reporting
.sp
Failing methods should report errors to VSL with the Error tag, so
when configuring the shard director, you are advised to check:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
varnishlog \-I Error:^shard
.ft P
.fi
.UNINDENT
.UNINDENT
.SS VOID xshard.set_warmup(REAL probability=0.0)
.sp
Set the default warmup probability. See the \fIwarmup\fP parameter of
\fBshard.backend()\fP\&. If probability is 0.0 (default), warmup is
disabled.
.SS VOID xshard.set_rampup(DURATION duration=0)
.sp
Set the default rampup duration. See \fIrampup\fP parameter of
\fIshard.backend()\fP\&. If duration is 0 (default), rampup is disabled.
.SS VOID xshard.associate(BLOB param=0)
.sp
Associate a default \fI\%obj_shard_param\fP object or clear an association.
.sp
The value of the \fIparam\fP argument must be a call to the
\fI\%func_shard_param.use\fP method. No argument clears the association.
.sp
The association can be changed per backend request using the \fIparam\fP
argument of \fI\%func_shard.backend\fP\&.
.SS shard.add_backend(...)
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
BOOL xshard.add_backend(
      BACKEND backend,
      [STRING ident],
      [DURATION rampup]
)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Add a backend \fIbackend\fP to the director.
.sp
\fIident\fP: Optionally specify an identification string for this backend,
which will be hashed by \fIshard.reconfigure()\fP to construct the
consistent hashing ring. The identification string defaults to the
backend name.
.sp
\fIident\fP allows to add multiple instances of the same backend.
.sp
\fIrampup\fP: Optionally specify a specific rampup time for this
backend. Otherwise, the per\-director rampup time is used (see
\fIfunc_shard.set_rampup\fP).
.sp
NOTE: Backend changes need to be finalized with \fIshard.reconfigure()\fP
and are only supported on one shard director at a time.
.SS shard.remove_backend(...)
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
BOOL xshard.remove_backend(
      [BACKEND backend=0],
      [STRING ident=0]
)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Remove backend(s) from the director. Either \fIbackend\fP or \fIident\fP must
be specified. \fIident\fP removes a specific instance. If \fIbackend\fP is
given without \fIident\fP, all instances of this backend are removed.
.sp
NOTE: Backend changes need to be finalized with \fIshard.reconfigure()\fP
and are only supported on one shard director at a time.
.SS BOOL xshard.clear()
.sp
Remove all backends from the director.
.sp
NOTE: Backend changes need to be finalized with \fIshard.reconfigure()\fP
and are only supported on one shard director at a time.
.SS BOOL xshard.reconfigure(INT replicas=67)
.sp
Reconfigure the consistent hashing ring to reflect backend changes.
.sp
This method must be called at least once before the director can be
used.
.SS INT xshard.key(STRING)
.sp
Convenience method to generate a sharding key for use with the \fIkey\fP
argument to the \fBshard.backend()\fP method by hashing the given string
with SHA256.
.sp
To generate sharding keys using other hashes, use a custom vmod like
\fI\%vmod blobdigest\fP with the \fIkey_blob\fP argument of the
\fBshard.backend()\fP method.
.SS shard.backend(...)
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
BACKEND xshard.backend(
      [ENUM {HASH, URL, KEY, BLOB} by=HASH],
      [INT key],
      [BLOB key_blob],
      [INT alt=0],
      [REAL warmup=\-1],
      [BOOL rampup=1],
      [ENUM {CHOSEN, IGNORE, ALL} healthy=CHOSEN],
      [BLOB param],
      [ENUM {NOW, LAZY} resolve]
)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Lookup a backend on the consistent hashing ring.
.sp
This documentation uses the notion of an order of backends for a
particular shard key. This order is deterministic but seemingly random
as determined by the consistent hashing algorithm and is likely to
differ for different keys, depending on the number of backends and the
number of replicas. In particular, the backend order referred to here
is _not_ the order given when backends are added.
.INDENT 0.0
.IP \(bu 2
\fIby\fP how to determine the sharding key
.INDENT 2.0
.IP \(bu 2
\fIHASH\fP:
.INDENT 2.0
.IP \(bu 2
when called in backend context: Use the varnish hash value as
set by \fIvcl_hash\fP
.IP \(bu 2
when called in client context: hash \fIreq.url\fP
.UNINDENT
.IP \(bu 2
\fIURL\fP: hash req.url / bereq.url
.IP \(bu 2
\fIKEY\fP: use the \fIkey\fP argument
.IP \(bu 2
\fIBLOB\fP: use the \fIkey_blob\fP argument
.UNINDENT
.IP \(bu 2
\fIkey\fP lookup key with \fIby=KEY\fP
.sp
the \fIshard.key()\fP function may come handy to generate a sharding
key from custom strings.
.IP \(bu 2
\fIkey_blob\fP lookup key with \fIby=BLOB\fP
.sp
Currently, this uses the first 4 bytes from the given blob in
network byte order (big endian), left\-padded with zeros for blobs
smaller than 4 bytes.
.IP \(bu 2
\fIalt\fP alternative backend selection
.sp
Select the \fIalt\fP\-th alternative backend for the given \fIkey\fP\&.
.sp
This is particularly useful for retries / restarts due to backend
errors: By setting \fIalt=req.restarts\fP or \fIalt=bereq.retries\fP with
healthy=ALL, another server gets selected.
.sp
The rampup and warmup features are only active for \fIalt==0\fP
.IP \(bu 2
\fIrampup\fP slow start for servers which just went healthy
.sp
If \fIalt==0\fP and the chosen backend is in its rampup period, with a
probability proportional to the fraction of time since the backup
became healthy to the rampup period, return the next alternative
backend, unless this is also in its rampup period.
.sp
The default rampup interval can be set per shard director using the
\fIset_rampup()\fP method or specifically per backend with the
\fIset_backend()\fP method.
.IP \(bu 2
\fIwarmup\fP probabilistic alternative server selection
.sp
possible values: \-1, 0..1
.sp
\fI\-1\fP: use the warmup probability from the director definition
.sp
Only used for \fIalt==0\fP: Sets the ratio of requests (0.0 to 1.0) that
goes to the next alternate backend to warm it up when the preferred
backend is healthy. Not active if any of the preferred or
alternative backend are in rampup.
.sp
\fIwarmup=0.5\fP is a convenient way to spread the load for each key
over two backends under normal operating conditions.
.IP \(bu 2
\fIhealthy\fP
.INDENT 2.0
.IP \(bu 2
CHOSEN: Return a healthy backend if possible.
.sp
For \fIalt==0\fP, return the first healthy backend or none.
.sp
For \fIalt > 0\fP, ignore the health state of backends skipped for
alternative backend selection, then return the next healthy
backend. If this does not exist, return the last healthy backend
of those skipped or none.
.IP \(bu 2
IGNORE: Completely ignore backend health state
.sp
Just return the first or \fIalt\fP\-th alternative backend, ignoring
health state. Ignore \fIrampup\fP and \fIwarmup\fP\&.
.IP \(bu 2
ALL: Check health state also for alternative backend selection
.sp
For \fIalt > 0\fP, return the \fIalt\fP\-th alternative backend of all
those healthy, the last healthy backend found or none.
.UNINDENT
.IP \(bu 2
\fIresolve\fP
.sp
default: \fILAZY\fP in \fBvcl_init{}\fP, \fINOW\fP otherwise
.INDENT 2.0
.IP \(bu 2
\fBNOW\fP: look up a backend and return it.
.sp
Can not be used in \fBvcl_init{}\fP\&.
.IP \(bu 2
\fBLAZY\fP: return an instance of this director for later backend resolution.
.sp
\fBLAZY\fP mode is required for referencing shard director instances,
for example as backends for other directors (director layering).
.sp
In \fBvcl_init{}\fP and on the client side, \fBLAZY\fP mode can not be
used with any other argument.
.sp
On the backend side, parameters from arguments or an associated
parameter set affect the shard director instance for the backend
request irrespective of where it is referenced.
.UNINDENT
.IP \(bu 2
\fIparam\fP
.sp
Use or associate a parameter set. The value of the \fIparam\fP argument
must be a call to the \fI\%func_shard_param.use\fP method.
.sp
default: as set by \fI\%func_shard.associate\fP or unset.
.INDENT 2.0
.IP \(bu 2
for \fBresolve=NOW\fP take parameter defaults from the
\fI\%obj_shard_param\fP parameter set
.IP \(bu 2
for \fBresolve=LAZY\fP associate the \fI\%obj_shard_param\fP parameter
set for this backend request
.sp
Implementation notes for use of parameter sets with
\fBresolve=LAZY\fP:
.INDENT 2.0
.IP \(bu 2
A \fIparam\fP argument remains associated and any changes to the
associated parameter set affect the sharding decision once the
director resolves to an actual backend.
.IP \(bu 2
If other parameter arguments are also given, they have preference
and are kept even if the parameter set given by the \fIparam\fP
argument is subsequently changed within the same backend request.
.IP \(bu 2
Each call to \fI\%func_shard.backend\fP overrides any previous call.
.UNINDENT
.UNINDENT
.UNINDENT
.SS VOID xshard.debug(INT)
.sp
\fIintentionally undocumented\fP
.SS new xshard_param = directors.shard_param()
.sp
Create a shard parameter set.
.sp
A parameter set allows for re\-use of \fI\%func_shard.backend\fP arguments
across many shard director instances and simplifies advanced use cases
(e.g. shard director with custom parameters layered below other
directors).
.sp
Parameter sets have two scopes:
.INDENT 0.0
.IP \(bu 2
per\-VCL scope defined in \fBvcl_init{}\fP
.IP \(bu 2
per backend request scope
.UNINDENT
.sp
The per\-VCL scope defines defaults for the per backend scope. Any
changes to a parameter set in backend context only affect the
respective backend request.
.sp
Parameter sets can not be used in client context.
.SS VOID xshard_param.clear()
.sp
Reset the parameter set to default values as documented for
\fI\%func_shard.backend\fP\&.
.INDENT 0.0
.IP \(bu 2
in \fBvcl_init{}\fP, resets the parameter set default for this VCL
.IP \(bu 2
in backend context, resets the parameter set for this backend
request to the VCL defaults
.UNINDENT
.sp
This method may not be used in client context
.SS shard_param.set(...)
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
VOID xshard_param.set(
      [ENUM {HASH, URL, KEY, BLOB} by],
      [INT key],
      [BLOB key_blob],
      [INT alt],
      [REAL warmup],
      [BOOL rampup],
      [ENUM {CHOSEN, IGNORE, ALL} healthy]
)
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
Change the given parameters of a parameter set as documented for
\fI\%func_shard.backend\fP\&.
.INDENT 0.0
.IP \(bu 2
in \fBvcl_init{}\fP, changes the parameter set default for this VCL
.IP \(bu 2
in backend context, changes the parameter set for this backend
request, keeping the defaults set for this VCL for unspecified
arguments.
.UNINDENT
.sp
This method may not be used in client context
.SS STRING xshard_param.get_by()
.sp
Get a string representation of the \fIby\fP enum argument which denotes
how a shard director using this parameter object would derive the
shard key. See \fI\%func_shard.backend\fP\&.
.SS INT xshard_param.get_key()
.sp
Get the key which a shard director using this parameter object would
use. See \fI\%func_shard.backend\fP\&.
.SS INT xshard_param.get_alt()
.sp
Get the \fIalt\fP parameter which a shard director using this parameter
object would use. See \fI\%func_shard.backend\fP\&.
.SS REAL xshard_param.get_warmup()
.sp
Get the \fIwarmup\fP parameter which a shard director using this parameter
object would use. See \fI\%func_shard.backend\fP\&.
.SS BOOL xshard_param.get_rampup()
.sp
Get the \fIrampup\fP parameter which a shard director using this parameter
object would use. See \fI\%func_shard.backend\fP\&.
.SS STRING xshard_param.get_healthy()
.sp
Get a string representation of the \fIhealthy\fP enum argument which a
shard director using this parameter object would use. See
\fI\%func_shard.backend\fP\&.
.SS BLOB xshard_param.use()
.sp
This method may only be used in backend context.
.sp
For use with the \fIparam\fP argument of \fI\%func_shard.backend\fP to associate
this shard parameter set with a shard director.
.SH ACKNOWLEDGEMENTS
.sp
Development of a previous version of the shard director was partly
sponsored by Deutsche Telekom AG \- Products & Innovation.
.sp
Development of a previous version of the shard director was partly
sponsored by BILD GmbH & Co KG.
.SH COPYRIGHT
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
This document is licensed under the same licence as Varnish
itself. See LICENCE for details.

Copyright (c) 2013\-2015 Varnish Software AS
Copyright 2009\-2018 UPLEX \- Nils Goroll Systemoptimierung
All rights reserved.

Authors: Poul\-Henning Kamp <phk@FreeBSD.org>
         Julian Wiesener <jw@uplex.de>
         Nils Goroll <slink@uplex.de>
         Geoffrey Simmons <geoff@uplex.de>

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS \(ga\(gaAS IS\(aq\(aq AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
.ft P
.fi
.UNINDENT
.UNINDENT
.\" Generated by docutils manpage writer.
.