General Resource Requirements for Kubernetes and Default Port Configuration

This section lists the various resources required to run advanced event mesh for SAP Integration Suite in a Kubernetes environment. The resources consumed by event broker services are provided by worker nodes, which are part of the Kubernetes cluster. SAP recommends that you run only one pod per worker node.

The resources for each pod must be sufficient for the type of service it is running:

  • messaging—the pod is running a software event broker in messaging mode. In a high-availability (HA) configuration, the event broker takes either the primary or backup role.
  • monitoring—the pod is running a software event broker in monitoring mode (applies only to HA configurations)
  • Mission Control Agent—the pod is running the Mission Control Agent, which communicates with the Home Cloud to configure and manage event broker services. For more information, see Mission Control Agent.

When sizing worker nodes, it is important to provision more RAM than listed in the table. The table below lists the RAM required by pods and doesn't take into account the overhead taken by Kubernetes. Typically, this overhead is less than 2 GB but can reach 4 GB.

The Standard class use a single messaging node (requires one pod for messaging). Broker 250 and larger Service Classes are High-Availability groups that require two messaging pods (Primary and Backup) and one monitoring pod. .

Multiple Mission Control Agents per Kubernetes Cluster

It is also possible to run more than one Mission Control Agent in one Kubernetes cluster. A customer may wish to have a single cluster serve multiple environments such as development, QA, production, and so on. Installing multiple Mission Control Agents in the same Kubernetes cluster allows these customer environments to reside together in the same cluster.

The Mission Control Agent requires one namespace to be fully dedicated to it. Thus to run multiple Mission Control Agents, multiple namespaces are required.

Each Mission Control Agent represents one data center in advanced event mesh, which means that a Kubernetes cluster with multiple Mission Control Agents is hosting multiple data centers from the Cloud Console point of view. The worker nodes are shared amongst these Mission Control Agents, therefore it is important to have enough resources provided by the worker nodes to be able to schedule all the services created by the different Mission Control Agents. When worker nodes are sized so they can run multiple software broker pods, it is also possible for pods from different Mission Control Agents to get scheduled on the same node.

Dynamic Volume Provisioning

Advanced event mesh requires dynamic volume provisioning, which is requested through Persistent Volume Claims managed by Kubernetes StatefulSets. This requirement requires that the infrastructure provide a storage backend that is supported by one of the Kubernetes' storage plugins. In addition, advanced event mesh requires a block storage backend for dynamic volume provisioning (we do not support filesystem-based backends).

  • You must format your disks with XFS.

  • SAP does not support the Network File System (NFS) protocol as part of your storage solution with advanced event mesh

  • To accomplish data encryption at rest for the software event broker messages and configuration, the storage backend must provide encrypted volumes. The event broker service itself does not provide data encryption at rest.

If you are deploying advanced event mesh to an on-premises Customer-Controlled Region, you must consider the supported storage solutions and volume performance requirements. For more information, see Dynamic Volume Provisioning in Resource Requirements for Kubernetes for On-Premises Deployments in Customer-Controlled Regions .

Compute Resource Requirements

The term Allocatable Core refers to the CPU capacity that the Kubernetes/Openshift clusters must be able to provide to the pods used for advanced event mesh. For example, an m5.xlarge instance in AWS has 4000 mCore of CPU capacity. However, only 3500 mCore of CPU can be requested by pods. It is important to account for this when you are planning the capacity for a Kubernetes cluster.

Compute Resources for Event Broker Services

The CPU Request and CPU Limit numbers in the table below include a 200 mCore requirement per monitoring agent. Each high-availability event broker service has three monitoring agents, one per broker that compose the service (primary, backup, monitoring). The standard service has a single monitoring agent.

Service Class Pod Type
(High-Availability Role)		 CPU Request
(mCores)		 Total CPU Request
(mCores) 		CPU Limit
(mCores) 		Total CPU Limit
(mCores)

Standard

Messaging

1,250

1,250

2,200

2,200

Broker 250

Primary Messaging

1,250

2800

2,200

5,600

Backup Messaging

1,250

2,200

Monitoring

300

1,200

Broker 1K

Primary Messaging

1,250

2800

2,200

5,600

Backup Messaging

1,250

2,200

Monitoring

300

1,200

Broker 5K

Primary Messaging

3,200

6,700

4,200

9,600

Backup Messaging

3,200

4,200

Monitoring

300

1,200

Broker 10K

Primary Messaging

3,200

6,700

4,200

9,600

Backup Messaging

3,200

4,200

Monitoring

300

1,200

Broker 50K

Primary Messaging

7,200

14,700

8,200

17,600

Backup Messaging

7,200

8,200

Monitoring

300

1,200

Broker 100K

Primary Messaging

7,200

14,700

8,200

17,600

Backup Messaging

7,200

8,200

Monitoring

300

1,200

Memory Resource Requirements

The term Allocatable RAM refers to the amounts of memory that the Kubernetes/Openshift clusters must be able to provide to the pods used for advanced event mesh. For example, an m5.xlarge instance in AWS has 16220452 KiB of RAM capacity. However, only 15069476 KiB of RAM can be allocated toward pods. It is important to account for this when you are planning the capacity for a Kubernetes cluster.

Enabling the Message Retain feature with a 2 GB memory buffer increases the memory requirement of each service class by 2048 MiB.

Memory Resources for Event Broker Services

The memory request and memory limit numbers in the following table include memory requirements for the monitoring agent. High-availability event broker services have three monitoring agents, one per broker that compose the service (primary, backup, monitoring). The standard service has a single monitoring agent. The monitoring agent requirements are:

  • Memory request for all versions: 256 MiB

  • Memory limit for versions 10.5 and earlier: 256 MiB

  • Memory limit for versions 10.6 and later: 512 MiB

Service Class Pod Type
(High-Availability Role)		 Instance Type Without Retain
Memory Request (MiB) Total Memory Request (MiB) Memory Limit (MiB) Total Memory Limit (MiB) Ephemeral

Storage

Request

and Limit per service (GiB) 		 Total
Ephemeral
Storage
Request
and Limit (GiB) 
Version 10.4
and Earlier		 Version 10.5 Version 10.6
and Later		 Version 10.4
and Earlier		 Version
10.5		 Version 10.6
and Later		 Version
10.4
and Earlier		 Version
10.5		 Version
10.6
and Later		 Version
10.4
and Earlier		 Version
10.5		 Version
10.6
and Later

Standard

Messaging

6,912.0

7,471.0

6,912.0

7,471.0

6,912.0

 7,727.0

6,912.0

 7,727.0 2.25

2.25

Broker 250

Primary Messaging

6,912.0

7,471.0

16,128

17,246.0

6,912.0

7,727.0

16,128

18,014.0

 2.25

6.75

Backup Messaging

6,912.0

7,471.0

6,912.0

7,727.0

2.25

Monitoring

2,304.0

2,304.0

2,560.0

 2.25

Broker 1K

Primary Messaging

6,912.0

7,471.0

16,128

17,246.0

6,912.0

7,727.0

16,128

18,014.0

 2.25

6.75

Backup Messaging

6,912.0

7,471.0

6,912.0

7,727.0

 2.25

Monitoring

2,304.0

2,304.0

2,560.0

 2.25

Broker 5K

Primary Messaging

14,489.6

21,555.2

24,985.0

31,283.2

47,871.24

52,274.0

14,489.6

21,555.2

25,241.0

31,283.2

47,871.24

53,042.0

 2.25

6.75

Backup Messaging

14,489.6

21,555.2

24,985.0

14,489.6

21,555.2

25,241.0

 2.25

Monitoring

2,304.0

2,304.0

2,560.0

 2.25

Broker 10K

Primary Messaging

14,489.6

21,555.2

24,985.0

31,283.2

47,871.24

52,274.0

14,489.6

21,555.2

25,241.0

31,283.2

47,871.24

53,042.0

 2.25

6.75

Backup Messaging

14,489.6

21,555.2

24,985.0

14,489.6

21,555.2

25,241.0

2.25

Monitoring

2,304.0

2,304.0

2,560.0

2.25

Broker 50K

Primary Messaging

31,283.2

40,396.8

43,475.0

64,870.4

81,458.4

89,254.0

31,283.2

40,396.8

43,731.0

64,870.4

81,458.4

90,022.0

2.25

6.75

Backup Messaging

31,283.2

40,396.8

43,475.0

31,283.2

40,396.8

43,731.0

 2.25

Monitoring

2,304.0

2,304.0

2,560.0

 2.25

Broker 100K

Primary Messaging

31,283.2

40,396.8

43,475.0

64,870.4

81,458.4

89,254.0

31,283.2

40,396.8

43,731.0

64,870.4

81,458.4

90,022.0

 2.25

6.75

Backup Messaging

31,283.2

40,396.8

43,475.0

31,283.2

40,396.8

43,731.0

 2.25

Monitoring

2,304.0

2,304.0

2,560.0

 2.25

Message Spool Size Requirements

The following table lists the default message spool sizes for each service class and the resulting persistent disk space required:

The Standard service class is a standalone messaging node (requires one pod). The Broker 250 High Availability and all larger High Availability Service Classes are HA groups, which require two messaging pods (Primary and Backup) and one monitoring pod.

Volume Size for High-Availability Event Broker Services

Service Class High-Availability (HA) Redundancy? Message Spool
Size 		Persistent Disk
Space Requirement
Version 10.6.1 and earlier Version 10.7.1 and later Version 10.6.1 and earlier Version 10.7.1 and later
Standard No 10 GB 25 GB 40 GB 35 GiB
Broker 250 Yes 25 GB 50 GB 70 GiB x 2 65 GiB x2
Broker 1K Yes 50 GB 200 GB 120 GiB x 2 260 GiB x2
Broker 5K Yes 200 GB 400 GB 420 GiB x 2 520 GiB x2
Broker 10K Yes 300 GB 600 GB 620 GiB x 2 780 GiB x2
Broker 50K Yes 500 GB 800 GB 1,020 GiB x 2 1040 GiB x2
Broker 100K Yes 500 GB 1000 GB 1,020 GiB x 2 1300 GiB x2

Mission Control Agent Pod

The Mission Control Agent has the following resource requirements:

Type Request Limit
CPU 750m 750m
Memory 1024MiB 1024MiB

Approximately once per week, SAP upgrades the Mission Control Agent using a rolling upgrade. The upgrade operation requires double the resources listed above to run successfully. When deployed in an auto-scaling environment, Kubernetes provides these resources as required. Deployments to non-auto-scaling environments must ensure they account for the additional resources required during the upgrade process. This includes ensuring that resource quotas applied to the namespace account for the rolling upgrade requirements.

Load Balancer Rules Per Service (Default Protocols and Port Configuration)

If you choose to use NodePort, the port numbers may not map accordingly to the listed ports in the table. To see the ports, you must look at the service's connection information in the Cloud Console

By default, there are nine rules available per service when plain-text protocols are disabled. The nine protocol rules include all non-plain-text messaging protocols and management protocols (SEMP, SEMP-TLS, and SSH). With all plain-text protocols enabled, the number of protocols enabled per service can be up to sixteen.

After the deployment of advanced event mesh for SAP Integration Suite, the customer can modify the rules when they a create an event broker service (either via Cluster Manager in the Cloud Console or via the REST API). The customer can disable protocols/ports, change the ports numbers that are used, or enable additional protocols (such as the plain-text variants). For example, the customer can choose to enable plain-text REST (9000) and only that service has that port enabled. For more information, see Configuring Client and Management Ports.

Management Connectivity Protocols and Ports

The following table lists the protocol ports, indicates whether the port is enabled by default when a event broker service is created, the protocol used for Management Connectivity (management traffic).

Port for Each Protocol Enabled by Default for an Event Broker Service Protocol and Description
8080

Yes/No (See note)

SEMP (plain-text)

This port is disabled by default on event broker services created after December 2020.
22 Yes

Secured Shell

943

 Yes

SEMP over TLS
Messaging Connectivity Protocols and Ports

The following table lists the protocol ports, indicates whether the port is enabled by default when a event broker service is created, the protocol used for Messaging Connectivity (Data traffic).

Port for Each Protocol Enabled by Default for an Event Broker Service Protocol and Description

443

 Yes

Secured Web Transport TLS/SSL

5671

 Yes

Secured AMQP

8443

 Yes

WebSocket Secured MQTT

8883

 Yes

Secured MQTT TLS/SSL

9443

 Yes

Secured REST TLS / SSL

55443

 Yes

Secured SMF TLS/ SSL (without compression)

80

 No

Web Transport

1883

 No

MQTT (plain-text)

5672

 No

AMQP (plain-text)

8000

 No

MQTT / WebSockets (plain-text)

9000

 No

REST (plain-text)

55003

 No

SMF-compressed

55555

 No

Solace Message Format (SMF) - plaintext