Scalr Server Architecture and Requirements

The information below is based on the standard Scalr deployment, if you have any questions or would like to make any changes please contact Scalr support.

Architecture

Scalr’s architecture consist of 8 modules (Proxy, App, Session, RabbitMQ, Worker, InfluxDB, Main DB, and Cost Analytics DB). The recommended Scalr HA deployment consists of 6 VMs (Instances) and is outlined in the following diagram:

../_images/Scalr_Arch.png

It is completely acceptable to group multiple components onto one virtual machine as the load for these services are minimal. The following are the recommended specs for the initial configuration:

  • Load Balancer of choice. The target should be the Scalr servers over 80 or 443 and 5671.
  • 1 VM for the Worker:
    • 4CPU, 8GB RAM
    • 50GB storage mounted on /opt/scalr-server on each server
    • NOTE: Worker should only be enabled on one server.
  • 1 VM for InfluxDB:
    • 4CPU, 16GB RAM
    • 100GB storage mounted on /opt/scalr-server on each server
  • 2 VMs for Proxy, Sessions, and App:
    • 4CPU, 8GB RAM
    • 50GB storage mounted on /opt/scalr-server on each server
  • 2 VMs for DB (active/passive):
    • 4CPU, 8GB RAM (A server is not required, this can be a cloud based database service like AWS RDS)
    • 750GB storage mounted on /opt/scalr-server on each server

Supported Operating Systems:

  • RedHat Enterprise Linux 6.x or 7.x
  • Centos Linux 6.x or 7.x
  • Debian 7.x or 8.x
  • Ubuntu 14.04, 16.04, 18.04

Network Requirements

When deploying Scalr you must ensure that all the necessary network configuration is in place to enable Scalr to connect to the instances it is managing. There are two options for this.

  1. Scalr can connect to the private/internal/local IP’s of instances that are within the same set of routed networks.
    1. Local VPC/VNet/Network within a region.
    2. Via peering connections to another VPC/VNet/network (inter and intra region).
  2. Scalr can connect to the Public IP’s of instances in any cloud.

Scalr can be configured to specify the connection option (Public or Local) or a per cloud basis, e.g. EC2, Azure etc. There is also the “auto” option which will use Public IP’s and will fallback to local IP’s if no public IP is available. If you wish to use private/local IP’s for connectivity then you must ensure the necessary network configurations are in place to enable this. By default Scalr will only have access to the local IP of instances that are in the same VPC/VNet in which it is deployed. For more details see the relevant page for your cloud(s) under Clouds - Configuring for Scalr

In both cases the firewall protecting instances must be opened to permit access to the required ports on the Scalr server and the managed instances as follows.

Scalarizr Network Requirements

Scalarizr needs to be able to communicate bi-directionally with the Scalr server. This table shows the ports that need to be open to enable this and also shows additional ports required to be open when Scalr is deployed on multiple hosts.

Port Protocol Direction Usage
80 TCP Cloud Instance > Scalr Server Scalarizr Agent
443 TCP Cloud Instance > Scalr Server Scalarizr Agent
5671 TCP Cloud Instance > Scalr Server Scalarizr Agent (rabbitmq)
6275 TCP Between Scalr Server Nodes (excluding DB) RabbitMQ
6276 TCP Between Scalr Server Nodes (excluding DB) RabbitMQ
6291 TCP Between Scalr Server Nodes (excluding DB) InfluxDB
8008 TCP Scalr Server > Cloud Instance Scalarizr Agent (update service)
8010 TCP Scalr Server > Cloud Instance Scalarizr Agent (API)
8013 TCP Scalr Server > Cloud Instance Scalarizr Agent (control)
15671 TCP Between Scalr Server Nodes (excluding DB) RabbitMQ