Performance scalability

This section provides information about improving the performance of your SA Core and its components..

You can vertically scale the SA Core Components, by adding additional CPUs and memory, or horizontally, by distributing the Core Components to multiple servers.

The Small-to-Medium SA deployment (SA 7.80 and later) and Medium-to-Large SA deployment (SA 7.80 and later) tables list the recommended distribution of SA components across multiple servers. In both tables, the bundled SA Core Components are distributed in the following way:

• MR: Model Repository
• INFRA: Infrastructure Component
  • Model Repository Multimaster Component
  • Management Gateway
  • Primary Data Access Engine
• Slice(x):
  • Agent Gateway
  • Core Gateway
  • Command Engine
  • Software Repository
  • Command Center
  • Build Manager
  • Web Services Data Access Engine
  • Secondary Data Access engine)
  • Global File System
  • Software Repository Accelerator (tsunami)
  • Memcache

Core component distribution

The introduction of bundled components requires that you consider how to distribute the SA Core components based on the hardware and memory you have available. A typical SA 7.5 or later installation now has three main components. The Model Repository, the Infrastructure Component bundle and one Slice Component bundle in addition to the Media Server and Boot Server. Since the Media Server and Boot Server do not generate much load and often have environmental dependencies they are not listed in the tables below.

There is no infallible way to select hardware for an SA installation. However, below are some recommended SA Core Component layouts that should perform well. As you can see, scaling a core requires adding slices. Each slice adds highly available UI, API, OGFS, Build Manager and Gateway resources. Consider that, when you have a small number of core servers, it may be best to begin with two larger servers, then grow the capacity of the core by adding additional slices. The following abbreviations are in the tables listed below:

• MR — Model Repository
• INFRA — Infrastructure Component bundle
• Slice <X> — Slice Component bundle
• OS Prov — Operating System Provisioning Component bundle. :

Small-to-Medium SA deployment (SA 7.80 and later)

Managed Servers	SA Component Distribution by Server
	Server 1	Server 2
500	MR, Infra, Slice 0, OS Prov	N/A
1000	MR	Infra, Slice 0, OS Prov
Server Configuration: 4 CPU cores, 16 GB RAM, 1 GB/s network

Medium-to-Large SA deployment (SA 7.80 and later)

Managed Servers	SA Component Distribution by Server
	Server 1**	Server 2*	Server 3*	Server 4*	Server 5*
2000	MR	Infra, Slice 0, OS Prov	N/A	N/A	N/A
4000	MR	Infra, Slice 0, OS Prov	Slice 1	N/A	N/A
6000	MR	Infra, Slice 0, OS Prov	Slice 1	Slice 2	N/A
8000	MR	Infra, Slice 0, OS Prov	Slice 1	Slice 2	Slice 3
* Server Configuration: 8 CPU Cores, 16 GB RAM, 1 GB/s network ** Server Configuration: 12 CPU Cores, 32 GB RAM, 1 GB/s network

Factors affecting core performance

• The hardware requirements for SA vary based on these factors:
• The number of servers that SA manages
• The number and complexity of concurrent operations
• The number of concurrent users accessing the Command Center
• The number of facilities in which SA operates

Multimaster Mesh scalability

To support global scalability, you can install an SA Core in each major facility, linking the cores in a Multimaster Mesh. The size of the SA Core in each facility can be scaled according to local requirements.

Multimaster Mesh availability

In addition to Model Repository replication, a Multimaster Mesh supports the replication and caching of the packages stored in the Software Repository. Typically, the core in each facility owns the software that is uploaded to the core’s Software Repository. To support availability, multiple copies of the packages can be maintained in remote Software Repositories. See the SA 10.51 Administer section for more information.

The bundling of the Software Repository with the Slice Component bundle and the Software Repository Store with the Infrastructure Component bundle does not affect availability. The Software Repository reads the replicator configuration file to determine how to serve files from backed up directories.

Satellite Core CPU/Memory requirements

Servers hosting SA Satellite Core installations must meet the following minimum requirement:

• 2 CPUs and 2 GB RAM per 1,500 managed servers per Satellite Core up to 4 CPUs and
  4 GB RAM for 3000 managed servers per Satellite Core

The capacity of a server hosting an SA Satellite can be increased to support additional managed servers as indicated above. Workload characteristics across SA environments can vary dramatically and the carrying capacity of a given SA satellite under those workloads can vary as well. For deployments that require more than 3,000 devices behind an SA Satellite, HPE recommends that you consider deploying additional SA satellites in the same realm. This solution provides increased redundancy and additionally avoids reaching the point of diminishing return from a single SA Satellite host server which requires you to continuously increase its capacity in order to support increasing load demands.

Load balancing additional instances of core components

If SA must support a larger operational environment, you can improve performance by installing additional instances of the Slice Component bundle which provides you with these additional components per installation:

• Agent Gateway
• Core Gateway
• Command Center
• Software Repository
• Build Manager
• Web Services Data Access Engine
• Secondary Data Access engine
• Software Repository Accelerator (tsunami)
• Memcache

If you have installed multiple instances of the Slice Component bundle, load balancing between the instances occurs automatically as requests for load services are received by the Core Gateway. The Core Gateway handles incoming client connections and load balances them across the Slice Component bundles in the core.

You can also deploy a hardware load balancer for the servers that run additional instances of the Slice Component bundle. You can configure the load balancer for SSL session persistence (stickiness) with the least connections algorithm.

You can also put a load balancer in front of the Core Gateways, however, this will only load balance the Gateways, but with the added benefit that clients would have only one address to connect to and would failover gracefully in the event of a Slice Component bundle host failure.

Load Balancing does not affect validation of httpProxy certificates since the identity of the core is based on the address the clients use to connect, not the identity of the server that ultimately serves the request. All Slice Component bundles should be issued the same certificate and the hostname referenced in the certificate should match the DNS hostname that external clients use to connect. If a load balancer is used, this should be the hostname of the load balancer.