3 Resource Requirement

This chapter provides information about the resource requirements to install and run Oracle Communications Network Analytics Data Director (OCNADD) with the desired Message Per Second (MPS) profiles.

Cluster Details

The following tables provides information about the types of servers and the number of servers used in the test environment:

Table 3-1 Test Bed 1 - CNE on BareMetal

Type of Server X9 Server and NVME
Master node 3
Worker node 19
Storage Class Standard
LB Type LBVM/CNLB

Table 3-2 Test Bed 2 - vCNE on OpenStack

Type of Server X9 Server and NVME
Master node 3
Worker node 44
Storage Class Standard
LB Type LBVM/CNLB

Resource Requirements for OCI Environment

  • OCI block volume is attached to the PVC with auto-tune based performance from balanced to high performance. To change block volume to auto-tune based performance (Balance to High Performance), see Changing the Performance of a Volume.
  • All tests are performed with the default round-robin based ordering.
  • Resource requirements may vary after enabling key or custom based ordering and running traffic with actual NFs.

Table 3-3 Test Bed 3 - OKE on OCI

Type of Server OCI Hardware
Worker nodes 6
Instance Shape VM.Standard.E4.Flex
OCPUs in worker node 50 (CPU: 100)
Memory in worker node 194 GB

3.1 Profile Resource Requirements

This section provides information about the profile resource requirements to install and run Oracle Communications Network Analytics Data Director (OCNADD) with the desired Message Per Second (MPS) profiles.

Note:

It is recommended to have the following configurations for CNE Baremetal/vCNE setup to achieve the required throughput:
  • Jumbo frames should be enabled.
  • Ring buffer size should be increased to avoid packet drop at interfaces.(not applicable for vCNE)
  • FluentD pods should not be in "CrashLoopBackOff" state due to Out of Memory error. For more information see "High Latency in adapter feeds due to high disk latency" section in Oracle Communications Network Analytics Data Director Troubleshooting Guide.
  • The benchmark tests were performed with round trip latency of up to 5ms from third-party consumer applications. In case the latency is more than 5ms then the resource profile footprint and the E2E latency will be higher.

3.1.1 Resource Profile for Database

This section provides information about the database profile resource requirements to install and run Oracle Communications Network Analytics Data Director (OCNADD) with the desired Message Per Second (MPS) profiles.

Table 3-4 Resource Requirement

cnDBTier Pods Min vCPU Max vCPU Min Memory Max Memory Total Replica

SQL (ndbmysqld)

Kubernetes Resource Type: StatefulSet

1 1 1Gi 1Gi 2

SQL (ndbappmysqld)

Kubernetes Resource Type: Statefulset

1 1 1Gi 1Gi 2

MGMT (ndbmgmd)

Kubernetes Resource Type: StatefulSet

1 1 1Gi 1Gi 2

Database (ndbmtd)

Kubernetes Resource Type: StatefulSet

1 1 4Gi 4Gi 2

Backup Manager Service

(db-backup-manager-svc)

Kubernetes Resource Type: Deployment

0.1 0.1 128Mi 128Mi 1

Monitor Service

(db-monitor-svc)

Kubernetes Resource Type: Deployment

0.2 0.2 500Mi 500Mi 1

EXTENDED STORAGE is ENABLED in CORRELATION Feed(Per Correlation Feed)

Rate Supported in current release: 1K MPS rate with 24 hours retention

Update "global.ndb.datamemory=96G" in custom-value.yaml of cndbTier

PVC of ndbmtd= 150GB

Database (ndbmtd)

Kubernetes Resource Type: StatefulSet

8 8 128Gi 128Gi 4

Note:

Configure "datamemory: 1G" under "ndbmtd" section while deploying the CnDbTier for OCNADD. For more details on cnDBTier resource profile, see "cnDBTier Small Profile" section in cnDBTier Resource Models Guide.

3.1.2 Resource Profile for 500K MPS

3.1.2.1 Resource Profile for OCNADD OAM Services

The following profile is used for management group services in all the performance scenarios.

Table 3-5 Resource Requirement

Service Name vCPU Memory Required (Gi) Total Replica Description
ocnaddconfiguration 1 1 1 -
ocnaddalarm 1 1 1 -
ocnaddhealthmonitoring 1 1 1 -
ocnaddgui 1 1 1 -
ocnadduirouter 1 1 1 -
ocnaddexport 0.5 1 1 Resource requirement will increase when export is configured.
ocnaddredundancyagent 1 1 1 Required only when Georedundancy is enabled for OCNADD.
3.1.2.2 Resource Profile for OCNADD Worker Group Services

The following profile shall be used for worker group services. The resource profile for worker group services will vary based on the scenario to be executed.

Note:

To support the increased throughput, first the number of Kafka instances must be increased followed by the number of topic partition changes based on the recommended MPS profile. For more details on this, see "Adding Partitions to an Existing Topic" in the Oracle Communications Network Analytics Data Director User Guide.

Note:

For more details about various supported MPS resource profiles, refer to the Oracle Communications Network Analytics Data Director Benchmarking Guide of previous or respective releases.
3.1.2.2.1 Egress 500K MPS Synthetic (TCP) Feed

Note:

Test conducted using separate clusters: One is dedicated to OCNADD services, while the other is shared by SCP NF services and third-party consumer.
  • Replication Factor: 1
  • Message Size: 3500
  • Feed Type: 2-TCP feeds
  • FILTER: Egress filter ON for second Feed with 1% data
  • Message Sequencing/Metadata: OFF
  • Test bed: LBVM-CNE Bare Metal Cluster Environment
  • Storage Type: Ceph

500K MPS SCP Profile(Ingress to DD)

Table 3-6 500K MPS SCP Profile (Ingress to DD)

Service vCPU Memory Required (Gi) Total Replica Topic Partitions
kraft-controller 1 2 3 -
ocnaddkafka (kafkaBroker) 5 96 17 -
ocnaddscpaggregation 2 4 20 SCP =120 (Each instance 6 partition)
ocnaddadapter-1(TCP)

(consumeradapter, without any filter)

3 6 28 MAIN=168 (Each instance 6 partition)
ocnaddadapter-2(TCP)

(consumeradapter, 500K MPS ingress and 5K MPS egress with Filter)

3 10 9 No partition change as MAIN topic already has 168 partition.
ocnaddadminservice 1 1 1 Admin Service moved to Worker-Group from release 25.2.100

Note:

  • Additional memory and/or replicas are required for the aggregation service if the Metadata Cache feature is enabled and the values of the properties METADATA_MAP_CACHE_EXPIRY_TIME_MS and METADATA_MAP_CACHE_SCHEDULER_TIME_MS are increased to higher values.
  • The end-to-end latency may increase based on:
    • Higher values of METADATA_MAP_CACHE_EXPIRY_TIME_MS and METADATA_MAP_CACHE_SCHEDULER_TIME_MS.
    • Timer Expiry Value + Processing Time + RF2/RF1 Processing Time + Third-party Response Time (for HTTP2 feed).
  • Resource requirements may vary for the consumeradapter service based on the percentage of data allowed after filtering and the number of filter conditions along with their values.
  • If ramDriveStorage is enabled, then the KafkaBroker Pod memory requirement will be:Memory Required for KafkaBroker + Memory Required for Data Retention

    Example: If the KafkaBroker requires 48Gi of memory and data retention for the topic requires 200Gi, the total memory required will be 248Gi.

    It is recommended to configure a replication factor of 2 for the Kafka internal topics (offsetTopicReplicationFactor and transactionStateReplicationFactor) to improve cluster durability. This configuration may enhance data availability and resilience.

  • Depending on cluster performance, more instances of the KafkaBroker may be required when running with RF=2, and end-to-end latency may also increase if disk I/O is slow.
  • For DISK I/O, see Disk Throughput Requirements.
  • For Kafka PVC-Storage, see Kafka PVC Storage Requirements.

3.2 Pod Affinity (or Anti-affinity) Rules

In the Data Director, support for node affinity has been added. The rules are currently defined for the services mentioned in the table below. The rules are currently disabled; however, the user can enable them for the supported services. The rules are provided to control the deployment of certain traffic processing services on a particular set of identified nodes.

Services name:
  • Consumer Adapter
  • Kafka
  • ocnaddnrfaggregation
  • ocnaddscpaggregation
  • ocnaddseppaggregation
  • ocnaddnonoracleaggregation
  • ocnaddbsfaggregation
  • ocnaddpcfaggregation

Node Affinity Rules

  1. Update the "affinity" section in the ocnadd-custom-values.yaml file
    affinity: {}
                    # Node Affinity Configuration:
                    #
                    # To enable node affinity, remove the empty curly braces ({}) above and un-comment the nodeAffinity section below.
                    # This allows you to specify rules for scheduling pods on specific nodes.
                    #
                    # Example Configuration:
                    ###################################   
                    # nodeAffinity:
                    #   requiredDuringSchedulingIgnoredDuringExecution:
                    #     nodeSelectorTerms:
                    #     - matchExpressions:
                    #       - key: kubernetes.io/hostname
                    #         operator: NotIn
                    #         values:
                    #         - k8s-node-26
                    #         - k8s-node-24
                    #       - key: kubernetes.io/hostname
                    #         operator: In
                    #         values:
                    #         - k8s-node-2
                    #         - k8s-node-3   
                    ###########################################
                    # Explanation:
                    #
                    # - The 'NotIn' expression prevents pods from being scheduled on nodes k8s-node-26 and k8s-node-24.
                    # - The 'In' expression ensures pods are scheduled on nodes k8s-node-2 and k8s-node-3.
                    #
                    # To customize, modify the 'key', 'operator', and 'values' fields according to your needs.
                    # You can add or remove 'matchExpressions' to create more complex scheduling rules.
                    #
                    # Remember to remove the empty 'affinity: {}' and un-comment the desired nodeAffinity configuration to enable it.
  2. Helm upgrade the corresponding worker group or the default group
    helm upgrade <source-release-name> -f ocnadd-custom-values-<worker-group>.yaml --namespace <source-release-namespace> <target-release-helm-chart>

    Where,

    • <source-release-name> is the release name of the source release deployment.
    • ocnadd-custom-values-<worker-group>.yaml is the custom values file created for default-worker-group or the Worker Group in separate namespace.
    • <source-release-namespace> is the OCNADD namespace of the source release.
    • <target-release-helm-chart> is the location of the Helm chart of the target release.
    For example:
    helm upgrade ocnadd -f ocnadd-custom-values-wg.yaml --namespace ocnadd-deploy ocnadd_wg
  3. Verify that PODs of the modified services have been deployed as per the configured affinity rules.

3.3 Ephemeral Storage Requirements

The following table describes the Ephemeral Storage requirements for OCNADD:

Table 3-7 Ephemeral Storage Requirements

Service Name Ephemeral Storage (Request) in Mi Ephemeral Storage (Limit) in Mi Description
OAM Services
ocnaddalarm 100 500 -
ocnaddhealthmonitoring 100 500 -
ocnaddconfiguration 100 500 -
ocnadduirouter 500 500 -
ocnaddexport 1000 2000 -
ocnaddredundancyagent 100 500 Required only when Geo Redundancy is enabled for OCNADD
Worker Group Services
<app-name>-adapter

(consumeradapter)

1000 1000 -
ocnaddscpaggregation 100 500 -
ocnaddseppaggregation 100 500 -
ocnaddnrfaggregation 100 500 -
ocnaddbsfaggregation 100 500 -
ocnaddpcfaggregation 100 500 -
ocnaddnonoracleaggregation 100 500 Required only when Data processing is enabled from Non-oracle NFs
ocnaddcorrelation 400 800 -
ocnaddstorageadapter 400 800 -
ocnaddingressadapter 400 800 -
ocnaddfilter 100 800 Required only when "Filtered" or "Correlated Filtered" feed is created
ocnaddadminservice 200 200 Admin Service moved to Worker-Group from release 25.2.100

3.4 Disk Throughput Requirements

The following table describes the disk throughput requirements in OCNADD:

Table 3-8 Disk Throughput Requirements

Avg Size (in Bytes) Rate RF (Kafka Replication Factor) Topic (NF+MAIN) Consumer Feed Total Write Throughput (MB/s) Total Read Throughput (MB/s) No. of Broker Per Broker Write Throughput (MB/s) Per Broker Read Throughput (MB/s) Total per Broker Throughput (MB/s) with 10% buffer Total Disk Throughput (MB/s) for the Cluster with 10% Buffer
1941 39000 1 2 1 145 145 3 54 54 108 324
1941 39000 2 2 1 289 289 3 106 106 212 636
3769 39000 1 2 1 281 281 3 104 104 208 624
3769 39000 2 2 1 561 561 3 206 206 412 1236

Note:

  • The average size of OCNADD Ingress message captured in the table includes the size of metadata list + header list of original 5G HTTP2 header frame + 5G-SBI-Message.
  • Currently, it is recommended to set the Replication Factor (RF) value to 1 with the assumption that the underlying storage provides data redundancy. RF value of "2" will be supported in a future release.
The disk throughput calculations are as follows:

Writes: W * RF * T    
Reads: ((RF*T)+C- 1) * W    
Disk Throughput (Write + Read): (W * RF *T) + (L * W)
W -> MB/sec of data that will be written                
RF -> Replication factor                
T   -> No of topics to which data copied. As of now, each message will be copied into two topics.                
C   -> Number of consumer groups, that is the number of readers for each write                
L   -> (RF*T) + C -1

Average Message in Table:

Average Message Size= (a1b1+a2b2+..+a(n)b(n))/(a1+a2+..+a(n))  
a1   -> SCP MPS    
b1   -> SCP message size    
a2   -> NRF MPS    
b2   -> NRF message size    
a(n) -> NF(n) MPS    
b(n) -> NF(n) message size    

Example:

Average message size for row 1 = ((1624*30000)+(3000*9000))/(30000+9000) = 1941 Bytes (approx)

Average message size for row 4 = ((4000*30000)+(3000*9000))/(30000+9000) = 3769 Bytes (approx)

The following table describes the disk throughput for SCP and NRF:

Table 3-9 SCP, NRF, and SEPP Disk Throughput

SCP Message NRF Message SEPP Message RF (Kafka Replication Factor) Topic (NF+MAIN) Consumer Feed Total Write Throughput (MB/s) Total Read Throughput (MB/s) No.of Broker Per Broker Write Throughput (MB/s) Per Broker Read Throughput (MB/s) Total per Broker Throughput (MB/s) with 10% buffer Total Disk Throughput (MB/s) for Cluster with 10% Buffer
Avg Size (Bytes) Rate Avg Size (Bytes) Rate Avg Size (Bytes) Rate
1624 30000 3000 9000 3000 15000 1 2 1 145 145 3 54 54 108 324
1624 30000 3000 9000 3000 15000 2 2 1 289 289 3 106 106 212 636
4000 30000 3000 9000 3000 15000 1 2 1 281 281 3 104 104 208 624
4000 30000 3000 9000 3000 15000 2 2 1 561 561 3 206 206 412 1236

Note:

  • The average size of OCNADD Ingress message captured in the table includes the size of metadata list + header list of original 5G HTTP2 header frame + 5G-SBI-Message.
  • Currently, it is recommended to set the Replication Factor (RF) value to 1 with the assumption that the underlying storage provides data redundancy.

3.5 Kafka PVC Storage Requirements

The following table describes the retention period per topic for different NFs:

Table 3-10 Retention Period Per Topic

Topic Name Retention Period
SCP 5 Minutes
NRF 5 Minutes
SEPP 5 Minutes
BSF 5 Minutes
PCF 5 Minutes
MAIN 6 Hours (Max)
The following calculation is for storage requirements for a topic:

Important:

For the 6 hrs storage in the MAIN topic, the storage requirement must be calculated using the following information:
Storage Requirement for a topic = MPS * Retention Period * RF * Average Message Size

Where,

MPS is "Message Per Second"

RF is "Replication Factor"

Examples:
  1. Average Message Size = 1941 Bytes

    The following example uses the values from the first row of the Table 3-9 table. For more information about the table, see Disk Throughput Requirements:

    Storage Requirement for SCP and NRF Topics = MPS * Retention Period * RF * Message Size = 39000 * 5 Minutes * 3 * 1941
                                                                                   = 39000 * 5 * 60 * 3 * 1941
                                                                                   = ~ 63.45 GB
    Storage Requirement for MAIN = MPS * Retention Period * RF * Message Size  =  39000 * 6 Hours * 3 * 1941
                                                                                   =  39000 * 6 * 60 * 60 * 3 * 1941
                                                                                   =  ~ 4.46 TB
    Total Storage Requirement for the Broker Cluster = Storage for SCP + Storage for NRF + Storage for MAIN
                                                                                   = 63.45 GB + 4.46 TB
                                                                                   = ~ 4.53 TB
    Total Storage for each broker = (4.53/Number of Brokers) TB = (4.53/3) TB = ~ 1.51 TB [Assuming 3 Broker cluster]
  2. Average Message Size = 3769 Bytes

    The following example uses the values from the fourth row of the Table 3-9 table. For more information about the table, see Disk Throughput Requirements:

    Storage Requirement for SCP and NRF Topics = MPS * Retention Period * RF * Message Size = 39000 * 5 Minutes * 3 * 3769
                                                                                            = 39000 * 5 * 60 * 3 * 3769
                                                                                            = ~ 123.20 GB
    
    Storage Requirement for MAIN = MPS * Retention Period * RF * Message Size  =  39000 * 6 Hours * 3 * 3769
                                                                                            =  39000 * 6 * 60 * 60 * 3 * 3769
                                                                                            = ~ 8.66 TB
    Total Storage Requirement for the Broker Cluster = Storage for SCP + Storage for NRF + Storage for MAIN
                                                                                            = 123.20 GB + 8.66 TB
                                                                                            = ~ 8.79 TB
    Total Storage for each broker = (8.79/Number of Brokers) TB = (8.79/3) TB = ~ 2.93 TB [Assuming 3 Broker cluster]