Skip to main content

Going highly available

Except for Redis that has only 1 instance for each resource for now, Spider is designed for High Availability.
And even if Redis fails, it is not a big issue: you might lose 10-15s of communications during the time Redis is down.

Sending queues on Whisperers​

Whisperers are limited - by configuration - in the count of parallel requests that they can issue to Spider.

When the count is reached, Whisperers are stacking their packets or TCP sessions to send in queues.
As soon as a slot is available, the next item in the queue gets sent. In FIFO mode.

The queue size is limited by configuration.

PcapSending.png

Circuit breakers​

Circuit breakers are used in all services and for all dependencies call.
Their thresholds cannot be configured in setup.yml, but could be changed in the templates.

Pollers retrial​

When a poller fails to save to Elasticsearch, it will retry.

Replicate Elasticsearch indices​

Elasticsearch supports setting up replicas of its indices. It is recommended to replicates the configuration indices, but it is not necessary for communications or monitoring.

This is managed in setup.yml.

    operations:
      replicas: 1
    config:
      replicas: 1
    utils:
      replicas: 1
    monitoring:
      replicas: 0

Replicate Spider services​

Whether you are using Spider on Swarm or Kubernetes, the cluster scheduler will restart any service that would fail. You may also define a minimum set of replicas for any services that you see fit.

This is managed in setup.yml.

services:
  whisp:
    replicas:
      min: 2
  customer:
    replicas:
      min:  2
  #...

Backup configuration​

When you activate backup in configuration (and the related S3 storage), Spider will backup all configuration every day.
The configuration is saved as ndjson, in Elasticsearch bulk API format. Ready to be injected.