General Concepts

Hardware Requirements: General Concepts

The Virtuozzo Application Management platform is built as a layered PaaS cluster. Each layer has a distinct responsibility, from the end-user interface down to the physical servers, networking, and storage used to supply resources.

The simplified platform architecture can be viewed as a top-to-bottom model that connects the user-facing services, platform infrastructure, compute provisioning layer, and underlying hardware.

Virtuozzo PaaS cluster architecture
Virtuozzo Application Management cluster architecture

Cluster Levels

User Experience LevelContains the platform services and interfaces used by developers, administrators, and end users.
Application Management Infrastructure LevelIncludes infrastructure hosts together with the hosts that run user containers and virtual machines.
Compute Provisioning LevelRepresents the service provider or cloud platform that supplies bare-metal servers or VMs and connects them through internal and external networks.
Hardware LevelCovers the underlying physical servers and networking used for resource provisioning.

Infrastructure and User Hosts

  • Infrastructure hosts (infra nodes): servers that run internal PaaS services.
  • User hosts (user nodes): servers that run customer applications inside containers or virtual machines.

Cluster Components

In addition to compute hosts, the cluster requires networking, DNS, and security resources that connect all layers into one operational platform.

  • An external network, normally reachable from the Internet, with one or more routable public IP ranges.
  • An isolated internal network dedicated exclusively to the PaaS cluster and using private IP addresses.
  • A DNS zone controlled by the platform, including the platform and region domains.
  • Wildcard SSL certificates for infrastructure and end-user domains.
Note: Before selecting a hardware provider, verify that the chosen server vendor and virtualization solution are supported by the platform.

High-Level Requirements

The following resources are required for an initial Virtuozzo Application Management deployment. These values are intended for launch and early workloads; additional capacity may be required as the platform grows.

1. Hosts

Provide bare-metal servers or virtual machines according to the selected installation scenario.

CPU requirement: The CPU presented to a virtual machine must support the x86-64-v2 instruction set or a newer version.

2. External Network

  • Provide an external or pseudo-external NAT network accessible to platform customers and visitors.
  • Assign one or more routable public IP ranges.
  • Ensure fast access to external repositories such as Docker Hub and Virtuozzo repositories.
  • Verify that the service provider can supply at least 300 Mbit/s of Internet bandwidth for installation and normal platform operations.

3. Internal Network

  • Use a private network isolated for platform traffic only.
  • Provide one or more routable private IP ranges.
  • A single /8 or /16 address space is preferred.

4. DNS Subdomains

Configure short DNS domains that are controlled by the platform:

  • *.{platformDomain} — the main platform domain, separate from the company website domain. Typical examples include app.{platformDomain} for the user dashboard and jca.{platformDomain} for the administration panel.
  • *.{regionDomain} — a unique domain for each platform region. End-user environments are automatically assigned names in the form {envName}.{regionDomain}.

Use a different domain for the platform and for each region. This reduces the risk that abuse originating from one customer environment could affect the reputation or availability of the entire platform domain.

Example Domain Structure

Platform domain: mypaas.com
Dashboard: app.mypaas.com
Cluster admin: jca.mypaas.com

First region: euregion.com
Environment example: awesomesite.euregion.com

Second region: usregion.com
Environment example: supershop.usregion.com
Hostname length: Linux limits a container hostname to 64 characters. Short region domains are recommended because the hostname also contains the container ID, environment name, separators, and region domain.
  • {nodeId} — the container identifier, such as node12345.
  • {envName} — the environment name selected by the user.
  • {regionDomain} — the domain assigned to the region.

As a practical planning value, the node ID can use up to 10 characters, the region domain should remain within approximately 25 characters, and two separators are required. This leaves up to 27 characters for the environment name in a 64-character hostname.

5. Wildcard SSL Certificate

  • *.{platformDomain} as a Subject Alternative Name (SAN).
  • *.{regionDomain} as the Common Name (CN).

6. Uploader Storage

Provide storage for user-uploaded content. This storage can be shared with the Docker template cache.

  • An external NFS mount is recommended.
  • A shared SCSI LUN connected to infrastructure hosts can also be used.

7. Docker Storage

Provide storage for the Docker template cache. It can be combined with uploader storage.

  • A shared external SCSI LUN across infrastructure hosts is recommended.

8. SMTP Server

An SMTP server is required for automatic platform notifications. An SMTP relay is optional but recommended for more reliable message delivery.

9. Docker Hub Account

Configure a Docker Hub billing account as the default registry account in the administration panel under Templates > Docker Registries.

  • Use an account with unlimited image pulls so that customer deployments are not restricted by registry pull limits.

10. Supported Kernel Versions

Keep the host kernel current in accordance with the Virtuozzo support policy. The latest supported updates include important fixes required for stable and correct platform operation.

Virtuozzo supports the currently documented product versions and the latest released user-space update. For kernel support, maintain one of the two latest released kernels.

Backup Server

A backup server can use shared storage connected to an existing host through NFS, iSCSI, or a similar protocol. A dedicated server with local disks can also be used. The selected storage must provide adequate redundancy, reliability, and capacity.

  • Minimum disk capacity should equal the combined capacity of the /vz or /vz/private directories on all protected hosts; twice that amount is recommended.
  • The backup server must be located on the same network as the protected hosts.
  • Minimum network bandwidth: 1 Gbit/s.
  • Recommended production bandwidth: 10 Gbit/s.
  • CPU: x86_64, 8 or more cores / 16 or more threads.
  • Memory: 16 GB RAM or more.

Installation Scenarios

Two installation approaches are available for public beta and commercial deployments:

  • Local Storage Server
  • Cloud Storage Cluster

Review the scenario-specific documentation for detailed hardware, networking, and operating-system requirements.

Cloud Storage note: The cloud-storage scenario adds a separate internal network for storage traffic and requires two or more network interfaces per server.

System Settings

The installation process applies required operating-system settings. These settings must remain unchanged after deployment because the platform depends on them for stable operation and supportability.

  • Do not make unsupported changes to system configuration files.
  • Do not remove or overwrite configuration files added or updated by the platform installation.
  • Do not alter the kernel modules configured for preloading.
  • Do not modify the TCP stack settings applied during installation.
  • Do not remove or overwrite platform-specific iptables rules.
  • Allow the required platform infrastructure IP addresses through the firewall.
  • Keep the approved operations-team SSH keys on every required host for emergency access.
  • Keep the server timezone set to UTC.
  • Keep SELinux disabled.
Contact the Support or Operations team before changing any setting that conflicts with internal maintenance or security practices.

What’s next?

Continue with the detailed requirements for: