Link11 WAAP
v2.16
v2.16
  • Link11 WAAP v2.16 Portal
  • Introduction
  • Getting Started
  • Setup Checklists
  • Marketplace onboarding
  • Console UI Walkthrough
    • General UI flow
    • Traffic
      • Traffic Concepts
      • Dashboard
      • View Log
    • Security
      • Security Section Concepts
      • Dynamic Rules
      • Quarantined
      • Profiles
        • Profile Concepts
        • Profiles
        • ACL Policies
        • WAF/IPS Policies
        • Custom Signature
      • Args Analysis
      • Tag Rules
      • Rate Limiting
      • Cloud Functions
    • Settings
      • Web Proxy
      • Backend Services
      • Error Pages
      • SSL
      • DNS
      • Planet Overview
      • Account
  • Using the product
    • Best Practices
      • Saving and Publishing Your Changes
      • Enabling Passive Challenges
      • Using the Reblaze Query Box
      • Understanding and Diagnosing Traffic Issues
    • How Do I...
      • Ban, Unban, and Whitelist Traffic Sources
      • Bypass Rate Limits for Loadtesting
      • Control Caching Behavior
      • Filter by Content
      • Quickly Block an Attacker
      • Secure Traffic from a Third-Party Page
      • Set Rate Limits and Exemptions
      • Set up SIEM/SOC integration
      • Video Tutorials
        • DNS Training
    • API
      • Reblaze REST API
      • Mobile SDK
  • Reference Information
    • Access log-structure
    • Acronyms
    • Deployment Terminology
    • Hostile Bot Detection / RCSI
      • Environmental detection and browser verification
      • Client authentication
      • Biometric behavioral verification
    • HTTP Response Codes
    • Pattern Matching Syntax
    • Signatures
    • Tags
    • TTL Expression Syntax
  • Support
Powered by GitBook
On this page

Was this helpful?

Export as PDF
  1. Reference Information

Deployment Terminology

This page provides information that will be helpful when setting up a Reblaze deployment. A basic Reblaze deployment can be created without changing these parameters.

Upstream Servers: The list is where you define the servers that Reblaze will protect. In other words, these are the servers to which Reblaze will send the (scrubbed) web traffic it receives.

This list provides robust capabilities for managing your traffic. You can enable and configure load balancing, which will weight and distribute traffic across your primary servers. You can define backup servers, to which Reblaze will failover your traffic when your primary servers aren’t available. You can take servers offline for maintenance by ticking a single box in the interface. You can even tell Reblaze to keep individual users connected to the same server throughout their sessions.

Adding and deleting servers from this list is straightforward. To add a server, enter its IP in the “New Server” box and click Add, then fill out the rest of the information in the new entry. To delete an existing entry, click on the Delete link next to that entry.

Here are explanations for each field in this list.

Host is the IP/FQDN for each server that Reblaze protects. This can be a normal web server, or it can be a load-balancing server. Note that Reblaze also provides load-balancing capabilities in its own right, as seen in the next field.

Weight is the relative weight of each server for load balancing purposes. Reblaze distributes traffic with a round-robin sequence, according to these weights.

For example, let’s say there are two servers in the list, with the weight of each servers set to one. Therefore, these servers will receive equal amounts of traffic. Suppose instead that the first server was set to three, while the second was set to one. This would mean that the first server would receive three visitors for every visitor sent to the second server.

Max Fails is 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. In the example, the timeout is ten seconds.

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.

Is Backup: when this box is checked, Reblaze will treat this server as a backup. In other words, Reblaze will not attempt to communicate with it unless all the primary servers (i.e., those for which this box is not checked) are unavailable.

PreviousAcronymsNextHostile Bot Detection / RCSI

Last updated 3 years ago

Was this helpful?