Backend Services

Overview

This section defines the Services that Reblaze will protect. In other words, these are the destinations to which Reblaze will send the (legitimate) traffic it receives.

Each Service can receive traffic for multiple web applications, and for multiple resources/locations within each web application. These assignments are made on the Web Proxy page.

Service Administration

At the top of the window, the title on the left displays the Service currently being displayed for editing. The pulldown on the right allows the selection of a different Service.

Adding a Service

To add a Service, click on the "Add" button (the plus sign).

Saving and Publishing Edits

When editing is complete, click on the Save button and then publish your changes.

Deleting a Service

To remove a Service from Reblaze, click on the Delete Service button at the bottom of the window.

Endpoint Definitions

For a single Service, you can define multiple endpoints. Within them you can:

• Enable and configure load balancing, weighting and distributing traffic across your primary endpoints.

• Define backups hosts, to which Reblaze will failover your traffic when your primary hosts aren’t available.

• Take hosts offline for maintenance by ticking a single box in the interface.

Adding and deleting endpoints from this list is straightforward. To add an endpoint, click on the Add button (the plus sign) and fill out the new entry. To delete an existing entry, click on the delete link next to that entry.

The settings for each endpoint in the list are as follows.

Attribute	Description
Host	The name or IP address for each endpoint that Reblaze protects. This can be a normal web server, or it can be a load-balancer. Note that Reblaze also provides load-balancing capabilities in its own right, as discussed below.
HTTP Port	The HTTP port for the server.
HTTPS Port	The HTTPS port for the server.
Weight	The relative weight of each server for load-balancing purposes. Reblaze distributes traffic with a round-robin sequence, according to these weights. For example, if two servers are both set to 'weight=1', they will receive equal amounts of traffic. If the first is set to 'weight=3' while the second is set to 'weight=1', the first server will receive three visitors for every single visitor that the second server receives.
Max Fails	The maximum number of failed communication attempts that are allowed for this server. Once this number of failures occurs, Reblaze will consider the server to be inactive. If other servers are available, Reblaze will failover the traffic to them. If this was the only server available, Reblaze will return an error to the client (either 504 Timeout, or 502 Bad Gateway).
Fail Timeout	When a server fails, this is the length of time that Reblaze will wait before trying to send traffic to it again. Example: "10s" indicates a fail timeout of 10 seconds. This field uses TTL Expression Syntax.
Is Down	When this box is checked, Reblaze will not attempt to communicate with this server. This allows you to easily take a server offline for temporary maintenance or some other purpose.

General Settings

The Name field defines the description for this Service within Reblaze.

Use HTTP/1.1: selecting this can speed up communication, via the use of connection pooling.

Transport Protocol: this configures the communication between Reblaze and the backend.

Option	Value
Per Request	This is the default mode. Incoming HTTP requests will go over HTTP, and incoming HTTPS requests will go over HTTPS.
HTTP Always	All communication between Reblaze and the backend will be over HTTP. (This mode should not be used unless Reblaze runs within the same cloud as the backend.)
HTTPS Always	All communication between Reblaze and the backend will be over HTTPS.
Port Bridge Mode	Reblaze will use the same port as the incoming request. This is not limited to ports 80 and 443; Reblaze will use whatever port was specified. Note: this mode is not available when more than one host is defined.

Load Balancing

Sometimes an application requires a user to be connected to the same Reblaze instance and backend endpoint throughout the session. Reblaze can ensure that this occurs, and can do so using a variety of methods.

Stickiness Model	Action
None	This is the default. Requests will be distributed across the endpoints in a round-robin fashion, according to the Weights assigned to them (described above in the Endpoint Definitions).
Auto Cookie	Reblaze will automatically generate a cookie to maintain the session on the same endpoint.
Custom Cookie	You can provide the name of the cookie that Reblaze will use to track the session, e.g. one generated by an AWS or GCP load balancer.
IP Hash	Routing will be determined from a hash of the client and destination IP addresses.
Least Connection	Requests will be sent to the endpoint with the fewest number of connections.