Sizing hardware

This topic describes the platform sizing that applies to the Appliance/VM deployment method. You can use this deployment both in standalone or High Availability (HA) mode.

This topic helps you choose the right hardware resource sizing for your IoT deployment. You can assess how much a ThingPark Enterprise platform can cost you prior to purchasing your equipment.

Case 1 - You want to purchase some hardware resources for a target IoT deployment for the first time. To learn more, see Case 1 - Determining the hardware sizing for a target IoT deployment.

Case 2 - You already have some hardware and want to know if the sizing fulfills the requirements of your new target IoT deployment. To learn more, see Case 2 - Determining the maximum deployment capacity of the current (or target) hardware sizing.

Standalone deployment

The next table describes the hardware sizing requirements according to your IoT deployment for each hardware sizing segment (S up to XXL). It gives you the number of base stations and devices, and the LoRaWAN® uplink/downlink traffic rate.

	Small (S)	Medium (M)	Large (L)	Extra-Large (XL)	Double-Extra-Large (XXL)
Base stations	Up to 10	Up to 50	Up to 100	Up to 200	Up to 1,000
Devices	Up to 2,000	Up to 10,000	Up to 20,000	Up to 50,000	Up to 300,000
Average Traffic Rate (uplink + downlink, msg/sec)	0.6	3	6	15	90
Peak Traffic Rate (msg/sec) (1)	3	15	30	60	180
HW req. Minimum CPU score (2)	16,000	23,000	30,000	46,000	113,000
HW req. Minimum CPU mark (indicative) (3)	2,280	2,840	3,400	4,680	10,040
HW req. RAM (GB)	7.5	12	16	32	128
HW req. Disk write operations/sec (average/peak)	45/100	60/200	80/300	140/500	650/1,500
HW req. Disk read operations/sec (average/peak)	20/500	30/1,000	40/1,500	70/2,500	325/7,500
HW req. Storage size (GB) (4)	90	110	130	170	520
HW req. TBW (5) over 5 years	1	5	10	25	150
Example of AWS EC2 sizing category	m5.large + gp2 volume	m5.xlarge + gp2 volume	m5.xlarge + gp2 volume	m5.2xlarge + gp3 volume	m5.8xlarge + gp3 volume
Example of Azure VM sizing category	D2sv4 + premium SSD	D4sv4 / D4sv5 + premium SSD	D4sv4 / D5sv5 + premium SSD	D8sv4 / D8sv5 + premium SSD	D32sv4 / D32sv5 + premium SSD
Example of vCPU sizing (6)	2 vCPU	4 vCPU	4 vCPU	8 vCPU	32 vCPU

(1) The peak load (uplink and downlink packets per second) cannot be sustained over more than one minute.

(2) The CPU score can be assessed through the ThingPark HW benchmark script which is included in self-hosted TPE image distribution.

(3) The indicative CPU mark refers to the PassMark "Average CPU Mark" shown in the PassMark CPU list. This value is given as an indication to the range of CPU models required on a standalone appliance for each platform sizing segment. The definite CPU sizing must be validated against the ThingPark's minimal CPU score assessed through the HW benchmark script.

(4) Refers to the available storage space. For instance, if RAID1 is used for a Small Segment, the platform must have two disks of 90GB each.

(5) TeraBytes Written (TBW) is a reliability metric used to evaluate the SSD lifetime.

(6) Assuming a Intel Xeon Platinum 8175M or 8259CL @ 2.50GHz processor.

High Availability deployment

Deploying self-hosted ThingPark Enterprise in High-Availability mode requires a 3-node cluster:

• Two identical nodes (called PRIMARY nodes) sized according to the targeted capacity. Each PRIMARY node must respect the sizing segments presented in the preceding table.

• A third tiny node (called arbiter node) acting as database arbiter to prevent split brain issues. The sizing of arbiter node is fixed whatever the target capacity and the underlying sizing segment.

Inter-node requirements

While it is strongly recommended to deploy the three nodes in three different geographical locations to mitigate the risk of accidents (fires) or natural disasters, the following requirements must be ensured between the different nodes of the high availability cluster:

• Latency must be less than 10 milliseconds.
• Inter-server bandwidth must be at least 1 Gbps.

The following table provides the sizing requirement of the arbiter node:

Hardware requirement	All sizing segments
Minimum CPU score (1)	9,700
Minimum CPU mark (indicative) (2)	1,776
RAM (GB)	2
Disk write operations/sec (average/peak)	20/100
Disk read operations/sec (average/peak)	20/100
Storage size (GB) (3)	70
TBW (4) over 5 years	0.1
Example of AWS EC2 sizing category	c5.large + gp2 volume
Example of Azure VM sizing category	F2sv2 + premium SSD
Example of vCPU sizing (5)	2 vCPU

(1) CPU score can be assessed through ThingPark HW benchmark script, included in the self-hosted TPE image distribution.

(2) Indicative CPU mark refers to the PassMark "Average CPU" Mark referenced by PassMark Software - CPU Benchmarks.

(3) Refers to available storage space. If RAID1 is used, the node must have two disks of 20GB each.

(4) TeraBytes Written (TBW) is a reliability metric used to evaluate the SSD lifetime.

(5) Assuming a Intel Xeon Platinum 8175M or 8259CL @ 2.50GHz processor.

Determining the hardware sizing for a target IoT deployment

1. Determine the target number of base stations and devices for your IoT deployment.

2. Based on the expected traffic profile of your devices derive the total average number of messages per second expected for your deployment. The expected traffic profile corresponds to the average number of uplink/downlink messages exchanged per day between the device and the ThingPark core network).

3. From the target design parameters defined in the preceding steps 1 and 2, choose the minimum sizing segment fulfilling all design targets:

   • For a deployment having four base stations, 1200 devices and 0.6 messages per second, the minimum sizing segment must be Small (S).

   • For a deployment having 50 base stations, 8000 devices and two messages per second, the minimum sizing segment must be Medium (M).

4. Read the minimum hardware resources required for the target sizing segment in Hardware sizing requirements shown in the preceding table:

   • If you have access to the target appliance / deployment environment, we recommend that you run a hardware benchmark to assess the effective CPU performance of your deployment server. To learn more, see Running a benchmark of the hardware.

   • If you cannot run the hardware benchmark on your target appliance / deployment environment, use the Minimum CPU mark to determine which CPU models fits for each segment. To do this, compare the "Minimum CPU mark (indicative)" defined in tables above with the "Average CPU Mark" referenced by the PassMark CPU list.

Determining the maximum deployment capacity of the current (or target) hardware sizing

1. Determine your sizing segment:

   • Either by running the hardware benchmark. To learn more, see Running a benchmark of the hardware.

   • Or by comparing your hardware capacity against the Case 1 - Determining the hardware sizing for a target IoT deployment shown in the preceding table. Your hardware capacity corresponds to the CPU through "Average CPU Mark" referenced by the PassMark CPU list, the RAM, the disk write operations per second and the storage capacity.

2. Read the first four rows shown from the preceding table to determine the maximum number of base stations, devices and traffic load supported by your sizing segment.

3. If the current sizing does not fulfill your target deployment requirements, upgrade your hardware to the right sizing segment. For instance, if your current sizing segment is "S" while you have an average of 2 messages per second, the right sizing segment is "M".

Running a benchmark of the hardware

You can benchmark your hardware resource at any time:

• After you have purchased your hardware equipment to verify that it fulfills the IoT deployment requirements that you want to put in place.

• If you want to verify that your existing IoT deployment has the proper hardware sizing.

To do this, you can use one of the following procedures:

Using the ThingPark Enterprise benchmark script

1. Install the ThingPark Enterprise ISO on the targeted server.

2. Open an SSH session using the support user.

3. Ensure that Docker is stopped: systemctl stop docker.

4. Run tpebench.sh for a ThingPark Enterprise OCP standalone or tpebench.sh -p <IP tpe_node2> -a <IP tpe_node3> for a ThingPark Enterprise OCP with High Availability. The support password for each node could be asked during the execution.

IMPORTANT

The bench must not be executed from the Cockpit Terminal.

The following capture shows an example of the script output:

$ tpe-bench.sh -p 192.168.250.17 -a 192.168.250.18
TPE-Bench on node 2. The support password could be required
Connection to 192.168.250.17 closed.
TPE-Bench on node 2 : Download report. The support password could be required
tpe-bench.out.yaml                                                                                                                                                       100%   81KB  18.6MB/s   00:00    
TPE-Bench on arbiter. The support password could be required
Connection to 192.168.250.18 closed.
TPE-Bench on node 2 : Download report. The support password could be required
tpe-bench.out.yaml                                                                                                                                                       100%   51KB  19.6MB/s   00:00    
##################################################################################################
#
#  Node 1 bench
#
##################################################################################################
Get the meta informations

Get the hardware informations

Get the sysbench informations

CPU model:  Intel(R) Xeon(R) Gold 6226R CPU @ 2.90GHz
CPU score:  XL (46315)
RAM:        M(15.7 G)
Disk size:  M (112 G)
Disk write score: XXL(4488 w/s)
Disk read score: XL(4977 r/s)

Server segment is M
Detailed result: tpe-bench.out-node1.yaml
##################################################################################################
#
#  Node 2 bench
#
##################################################################################################
Get the meta informations

Get the hardware informations

Get the sysbench informations

CPU model:  Intel(R) Xeon(R) Gold 6226R CPU @ 2.90GHz
CPU score:  XL (46399)
RAM:        M(15.7 G)
Disk size:  M (112 G)
Disk write score: XXL(5054 w/s)
Disk read score: XL(5695 r/s)

Server segment is M
Detailed result: tpe-bench.out-node2.yaml
##################################################################################################
#
#  Node 3 bench (arbiter)
#
##################################################################################################
Get the meta informations

Get the hardware informations

Get the sysbench informations

CPU model:  Intel(R) Xeon(R) Gold 6226R CPU @ 2.90GHz
CPU score:  ARBITER (46816)
RAM:        ARBITER (2.0 G)
Disk size:  ARBITER (72 G)
Disk write score: ARBITER(4972 w/s)
Disk read score: ARBITER(5516 r/s)

Server segment is ARBITER
Detailed result: tpe-bench.out-arbiter.yaml

For each node, the server segment is shown. When a server hardware sizing is downsized, the message is "Server segment is not compatible". See Sizing hardware for more information.

Using sysbench without installing ThingPark Enterprise

You can benchmark your server without installing the ThingPark Enterprise ISO.

Note The server must be running a Linux distribution and sysbench must be installed.

For example, on Debian/Ubuntu: apt install sysbench.

1. Ensure no other workload is running on the server.

2. CPU bench:

   1. Run the following command: sysbench --threads=50 --time=10 --events=0 cpu run

   2. Compare the Minimum CPU score shown in the preceding table with the "total number of events" value (in the "General statistics" section) from the sysbench output.

3. IO bench:

   1. Go in a directory in the targeted device with enough disk space.

   2. Prepare the bench by running sysbench fileio --file-total-size=10G prepare.

   3. Run sysbench --threads=50 --time=10 --events=0 --file-total-size=1G --file-test-mode=rndwr --file-extra-flags=direct --file-fsync-all=on fileio run

   4. Compare the "Disk OPS (write/s)" from the table above with the "writes/s" value (in the "File operations" section) from the sysbench output.

   5. Cleanup: sysbench fileio --file-total-size=10G cleanup