Variable Store High Availability

High Availability

The Storage Server (aka Variable Store) is a stateless, extendable storage API application that officially supports a file system directory path and AWS S3 backend implementations. This section describes the different ways to achieve high availability in both the application and the data tier.

Data Tier

Path Backend (default)

For high availability, mount the storage directory on all hosts running the Variable Store using the local NAS or any other distributed file system solution.
By default, the storage directory is located in /opt/takipi-storage/storage, and alternative locations are configured in the settings.yml file in /opt/takipi-storage.

AWS S3 Backend

High availability is provided with AWS S3. S3 behaves like NAS, and allows multiple Variable Stores to access the same data by using the same S3 region and bucket. The code can be found at: https://github.com/takipi/takipi-storage/tree/s3-storage

Other backends

To add your own elastic file system implementation, extend the takipi-storage project, from https://github.com/takipi/takipi-storage.

Application Tier

The Variable Store can be deployed on multiple hosts running behind a load balancer, enabling both scale and redundancy. The HTTPS (TLS) can be terminated either at the load balancer or at the Variable Stores as described in section Enabling HTTPS .

Nginx Configuration Examples

Use the following examples to configure application tier high availability:

HTTP only, using multiple Variable Stores:

http {
  upstream storage {
    server storage1.example.com:8080;
    server storage2.example.com:8080;
    server 10.84.0.109:8080;
  }
  
  server {
    listen 80;
    server_name loadbalancer.example.com;

    location / {
      proxy_set_header       Host $host;
      proxy_set_header       X-Real-IP $remote_addr;
      proxy_pass             http://storage;
    } 
  }
}

#####HTTP/HTTPS using multiple Variable Stores, terminating TLS on the load balancer:

http {
  upstream storage {
    server storage1.example.com:8080;
    server storage2.example.com:8080;
  }
  
  server {
    listen 80;
    server_name loadbalancer.example.com;
    return 301 https://$host$request_uri;
  }
  
  server {
    listen 443;
    server_name loadbalancer.example.com;
    
    ssl on;
    ssl_certificate /etc/nginx/storage.crt;
    ssl_certificate_key /etc/nginx/storage.key;
    
    ssl_session_timeout  5m;
    ssl_prefer_server_ciphers On;
		ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGC
M:RSA+AES:!aNULL:!MD5:!DSS;
    
    location / {
      proxy_set_header		Host $host;
      proxy_set_header		X-Real-IP $remote_addr;
      proxy_set_header		X-Forwarded-Proto https;
      proxy_set_header		X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_redirect		http:// https://;
      proxy_pass		http://storage;
    } 
  }
}

HTTP/HTTPS using multiple Variable Stores, terminating TLS on the Variable Stores:

http {
  upstream storage-http {
    server storage1.example.com:8080;
    server storage2.example.com:8080;
  }
  
  upstream storage-https {
    server storage1.example.com:8443;
    server storage2.example.com:8443;
  }
  
  server {
    listen 80;
    listen 443;
    server_name loadbalancer.example.com;
    location / {
      proxy_set_header		Host $host;
      proxy_set_header		X-Real-IP $remote_addr;
      proxy_set_header		X-Forwarded-Proto $scheme;
      proxy_set_header		X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass		http://storage-$scheme;
      proxy_redirect		off;
    }
  }
}

Updated over 4 years ago