Horizontal Scaling inside the Cloud: Multi Nodes

With the platform, hosting of your applications becomes truly flexible. In addition to automatic vertical scaling, the platform also lets you increase/decrease the number of servers in your environment manually or automatically.

The process of manual scaling is fairly simple - open the environment topology wizard and use the appropriate “+” and “-” buttons or type the required number in the central panel. Also, you can use the slider, which automatically appears upon making any adjustment.

Next, you can select the required scaling mode from the appropriate drop-down list. Also, for additional details refer to the horizontal scaling specifics section below.

Scaling Modes

Starting with the 5.5 platform version, the preferred scaling mode can be selected for new environments during creation, as well as adjusted for the existing ones through the topology wizard:

• Stateless - simultaneously creates all new nodes from the base image template
• Stateful - sequentially copies file system of the master container into the new nodes

The first option is comparatively faster, while the second one automatically copies all custom configurations. Herewith, during the initial layer creation, all of the nodes are created simultaneously to speed up the process (even for the stateful mode, as no customization has been applied yet).

While using the stateless mode, be aware of the following features absence on the new nodes within the layer:

• deployments - the existing project contexts won’t be transferred
• custom SSL - SSL certificates and configs won’t be copied
• mount points - custom mounts will be moved only if the appropriate volume is configured
• add-ons - any add-ons installed on the layer won’t be available

Based on these peculiarities, the platform recommends (and applies by default) the stateful scaling mode for the load balancer, application server, and VPS stacks. In case of necessity, you can manually redefine the scaling mode for your nodes at any time via topology wizard.

Horizontal Scaling Specifics

The maximum number of the same-type servers within a single environment layer depends on a particular hosting provider settings (usually this limit stands for 16 nodes). You can check the exact value within the Quotas & Pricing > Account Limits information frame.

All newly added servers are created at different hardware nodes, providing advanced reliability and high-availability.

Each environment node group (layer) is provided with the dedicated name, which, if needed, can be manually adjusted. In case there are several instances inside, layer name will be complemented with the xN label (where N is the actual nodes number).

Having several same-type nodes within a layer enables their synchronous management. Thus, all containers can be simultaneously configured, inspected for logs and statistics, restarted or redeployed through the corresponding icons.

In order to operate with a particular container separately, expand the layer’s string to see the full list of its nodes. Each of these containers is an isolated instance, which has a unique Node ID and can be accessed/configured apart from others. Herewith, the layer master node can be easily located due to the dedicated icon.

To facilitate interaction with numerous servers of the same type, the platform also allows marking a particular node with the appropriate label, e.g. to define master and slave instances in a DB cluster.

Just double-click at the default Node ID: xxx value (or hover over it to reveal a special pencil icon) and specify the desired alternative name.

More information on this labeling feature can be found in the Environment Aliases document.

While scaling different types of stacks, consider the following specifics:

• upon scaling the application server instance, the load balancer node will be automatically added to the environment topology
• if enabling the high-availability option for application server, the obligatory required NGINX load balancer cannot be scaled horizontally (if several nodes of NGINX were available before, they will be automatically downscaled to a single instance)
• upon scaling VPS nodes, each one is provided with a separate public IP address attached
• Maven is the only node, which cannot be scaled horizontally (as there is no point in such operation)

Now, you know how easy it is to horizontally scale instances in the platform and aware of the operation specifics. Also, feel free to configure an automatic nodes scaling to smoothly overcome high load spikes without overpaying for unused resources.

Managing Nodes within Layer

The platform provides a simple nodes management, where you just need to specify the required number of containers in a layer. Herewith, the removal process is done in the order opposite to the addition - i.e. the most recent containers are removed first. In case you need to delete some specific node, you can select the required one via:

• the Horizontal Scaling section in topology wizard - accessible using the Change Environment Topology button next to the required environment

• the dedicated Scaling Nodes form in the dashboard - accessible using the Additionally > Scaling Nodes option next to the layer or Additionally > Delete next to the particular node

In the Scaling Nodes window, you can perform the following actions:

1. Add new nodes to the layer, using the + or Add New Node buttons.

2. Remove instances with the - and Delete (upon hovering over particular node) buttons.

3. At the bottom of the frame, a redirect to the Automatic Horizontal Scaling section can be found.

If any adjustments are made in the form, you’ll need to confirm the redirect via pop-up (as any unsaved changes are discarded).

4. When applying changes, the platform automatically notify you about all the potentially harmful actions that will be performed with your environment (if any). The list includes:

• nodes restart notice
• layers and separate nodes removal reminder
• impact on existing NFS mounts

Before proceeding, ensure that the listed points won’t affect your application, and any crucial data (from the removed nodes) is safely backed up.

What’s next?

• Automatic Horizontal Scaling
• Automatic Vertical Scaling
• Container Configuration Tools
• Environment Aliases
• Public IP