Host Guidance
AMPS can run on physical hardware, virtual machines, or containers. The right hosting model depends on the performance, latency, and deployment flexibility needed by the application.
Use the Capacity Planning section to size memory, storage, CPU, and network resources for an AMPS deployment. Use this section to plan how those resources are provided by the host environment.
Physical Servers, Virtual Machines, Containers
Although AMPS is designed to be highly adaptive to hardware on which it runs, AMPS does not require a dedicated physical server. AMPS can be successfully deployed on physical hardware, virtual machines, or containers. In any deployment model, 60East recommends tuning Linux for best performance rather than accepting the distribution defaults, which are typically tuned for interactive use rather than for a high performance server.
Typically, installations that require the highest level of performance and lowest levels of latency deploy on physical hardware, with a single AMPS instance per server. Installations that are willing to trade predictable performance for ease and flexibility of deployment often use virtual machines or containers.
Virtual machines and containers both add a layer between AMPS and the physical host resources. Plan capacity, monitoring, and performance testing for the underlying host as well as for the virtual machine or container that runs AMPS.
Virtual Machines
When deploying in a virtual machine, it is important to consider the capacity of both the virtual machine itself and the underlying host hardware. In other words, the total memory needed by all virtual machines -- with all applications hosted by those machines running at peak traffic simultaneously -- should not exceed the physical memory of the hardware. Likewise, the total number of CPUs specified in all of the virtual machines on the host should not exceed the number of CPUs on the host hardware, the network bandwidth needed should not exceed the bandwidth allocated to the host, the traffic to the storage device should not exceed the throughput that the storage device is capable of, and so on. In an enterprise environment, it is not unusual for a wide variety of applications to all see peak loads at the same time, so the system should be provisioned to provide enough capacity that every hosted application can meet peak throughput requirements at the same time.
For x86-64 cloud deployments, the best starting point is a balanced general-purpose instance.
| Cloud provider | Recommended starting point | Alternatives and notes |
|---|---|---|
| AWS EC2 | M-family x86-64 instances, such as M8i or M8a where available. | Use M7i or M7a where M8 instances are not available. |
| Google Cloud | General-purpose C4 standard machines. | Use N4 standard or N2 standard based on regional availability and storage or network requirements. |
| Azure | D-family x86-64 instances, such as Dsv7 or Ddsv7 where available. | Use Dsv5 or Dv5 where Dsv7 or Ddsv7 instances are not available. |
Choose the initial VM size from the CPU, memory, network, and storage requirements identified during capacity planning. Start with a balanced instance type, then use workload testing to decide whether the AMPS use case benefits from moving to a more specialized instance family.
Use workload testing to choose the next direction: expand toward compute-optimized instances when CPU is the limiting resource, memory-optimized instances when memory capacity or memory bandwidth is limiting, network-optimized instances when message throughput or replication traffic is limited by networking, and storage-optimized instances when persistence, transaction log, or SOW activity is limited by storage throughput or latency.
On virtual machines, disable AMPS-level NUMA tuning in the AMPS configuration file.
<AMPSConfig>
...
<Tuning>
<NUMA>
<Enabled>disabled</Enabled>
</NUMA>
</Tuning>
...
</AMPSConfig>
For applications requiring low latency and predictable response times, 60East does not recommend using virtualization systems that dynamically move running virtual machines for load-balancing purposes. Although these systems work well for their intended purpose, a machine migration will cause a period where AMPS isn't delivering messages or responding to queries, while also having a gap in observability (Galvanometer, Admin statistics, or logging).
Containers
When deploying in a container, ensure that the host system has the capacity to support all of the containers running on the host at peak capacity. This capacity includes CPU, memory, networking, storage capacity, and storage throughput.
60East tests and certifies AMPS within Podman containers. Containers can provide density and compute-efficiency advantages by allowing multiple AMPS instances or related services to share host resources, provided that the host is sized and managed for the combined peak load of all containers.
AMPS can perform NUMA tuning within a container when the physical host is a NUMA system and the container has access to the relevant host topology. This section provides guidance for AMPS-level NUMA tuning in containers. Leave AMPS-level NUMA tuning enabled in a container only when all of the following are true:
- The AMPS container is the only significant CPU-intensive workload on the host. This is typically a dedicated host, but a host that also runs lightweight supporting containers or processes can qualify when they do not materially compete for CPU or memory locality.
- The host NUMA topology is visible inside the container.
- The container runtime or orchestrator is not using CPU pinning, CPU quotas, memory limits, or memory placement policies that conflict with the topology AMPS detects.
- Performance testing of the complete container and host environment shows that AMPS NUMA tuning improves or preserves the required performance for the workload.
Disable AMPS-level NUMA tuning when any of these conditions is not true. This includes hosts that run multiple significant AMPS instances, containers, tenants, or CPU-intensive applications, and containers where the runtime restricts CPU or memory placement. In these deployments, the host and container runtime are responsible for allocating CPU and memory resources across workloads. Before leaving AMPS-level NUMA tuning enabled in a container, verify the topology visible from inside the container, review the runtime CPU and memory constraints, and compare workload performance with AMPS NUMA tuning enabled and disabled.
AMPS supports a wide variety of use cases with different CPU, networking, storage, and memory profiles. For high-performance computing (HPC) use cases, test the complete container and host environment for acceptable performance for each AMPS workload, rather than assuming that results from one workload or host configuration apply to another.
For best networking performance in a container, 60East recommends using host networking to remove network address translation (NAT) and virtual bridge interfaces from the message path.
Host networking makes AMPS listeners use the host network namespace. Use host networking only with intended bind addresses configured for Transports and the Admin interface, host firewalls or cloud security groups limiting access to the required peers, and Securing AMPS controls such as TLS, authentication, and entitlement configured before the container is exposed.
Monitoring and Virtualization Considerations
For virtualized hosting or deployment in a container, develop a plan for monitoring the physical hardware as well as the environment that runs AMPS. If possible, the monitoring plan should include a method for correlating the activity in a virtualized or containerized environment with the activity on the physical host. For example, it is important to be able to correlate CPU saturation on a virtual machine to CPU saturation on the physical host.