5.3 Sizing Guidance for eDirectory Deployment on AWS

This guide recommends the best suited AWS EC2 Instance and EBS Volume for eDirectory deployment on AWS VPC. To help you estimate your sizing requirements, we have provided the most useful estimation factors along with various performance scenarios, which are tested under the controlled lab environment with specific configuration parameters in place.

5.3.1 Get Started with the AWS EC2 Instance Selection

Before deploying eDirectory on AWS, you must determine the EC2 Instance and EBS Volume types for achieving the optimal performance out of your eDirectory server. The performance of eDirectory depends on multiple resources regarding how an enterprise plans to use it. Some of the resources to take into consideration for your estimation are:

  • AWS EC2 Instance Category: You must select the appropriate instance category required for your environment. We’ve considered the following Instance categories for the various performance scenarios in our lab environment:

    • General Purpose

    • Memory Optimized

    • Compute Optimized

    It is also recommended to use EBS-optimized EC2 instances for deploying eDirectory to avail a dedicated bandwidth between the EC2 instance and the attached EBS volume. It also enables an effective use of the IOPS which is provisioned on an EBS volume. For some instances, EBS optimization is not enabled by default. In such scenario, You must enable it manually.

  • AWS EC2 Instance Type: After selecting the appropriate instance category for your environment, an instance type needs to be selected as per the business need or expected load. AWS provides a wide selection of EC2 Instance Types under each Instance Category. There are sub-categories under each category depending on various parameters, such as the type of processors or network throughput. The number of CPU cores, volume of RAM, network capacity and the cost depend on the instance type that is selected. For more information on Instance Types, see Amazon EC2 Instance Types.

  • AWS EBS Volume Types: Since the root volume or the local storage in the EC2 instance is perishable, you must attach an AWS Elastic Block Storage (EBS) Volume to your EC2 instance to store eDirectory DIB and other server files that need to be persisted. EBS volumes allow you to persist the stored data even after the AWS EC2 instance is terminated, which helps in data recovery scenarios. Data stored in the EBS volume is replicated by default within the same Availability Zone. For more information, see EBS Volume Types.

    eDirectory being a read intensive directory service, the selection of the EBS Volume type will depend on high disk I/O. Due to this, it is recommended to use SSD volume types over HDD volume types because the SSD volume types handle small or random disk I/O more efficiently than the HDD volume types, which is basically used for streaming the disk I/O.

    Provisioned IOPS SSD volume type (io1 and io2) allow you to specify a consistent IOPS rate while creating the volume types when compared to General Purpose SSD volume type (gp2) where performance might be inconsistent. Also, the General Purpose SSD will tie up configuration of IOPS with the disk size which does not exist with the Provisioned IOPS SSD volume types.

5.3.2 Details of Performance Test Environments

In this section, we explain the various configuration parameters, instance categories and types that have been used in our controlled lab environment.

EC2 Instance Types:

The following instance types have been used during the performance tests:

Table 5-3 Instance Type 4xLarge

Category

Type

CPU

Memory

EBS Optimized

EBS Bandwidth

Compute optimized

c5a.4xlarge

16 CPU, 3.3 GHz

32 GB

Yes

3,170 Mbps

Table 5-4 Instance Type 2xLarge

Category

Type

CPU

Memory

EBS Optimized

EBS Bandwidth

General Purpose

m5a.2xlarge

8 CPU, 2.5 GHz

32 GB

Yes

2,880 Mbps

Memory optimized

r5a.2xlarge

8 CPU, 2.5 GHz

64 GB

Yes

2,880 Mbps

Compute optimized

c5a.2xlarge

8 CPU, 3.3 GHz

16 GB

Yes

3,170 Mbps

Table 5-5 Instance Type xLarge

Category

Type

CPU

Memory

EBS Optimized

EBS Bandwidth

General Purpose

m5a.xlarge

4 CPU, 2.5 GHz

16 GB

Yes

2,880 Mbps

Memory optimized

r5a.xlarge

4 CPU, 2.5 GHz

64 GB

Yes

2,880 Mbps

Compute optimized

c5a.xlarge

4 CPU, 3.3 GHz

8 GB

Yes

3,170 Mbps

Common Parameters

Table 5-6 Explanation of Common Parameters

Parameter

Description

AWS VPC Details

One Public Subnet and one Private Subnet. Both Client and eDirectory are in VPC Private subnet.

eDirectory EC2 Instance Details

  • Operating System: SUSE Linux Enterprise Server 15 SP2 (HVM), SSD Volume Type

  • eDirectory build: eDirectory 9.2.3

  • Elastic Block Storage: Provisioned IOPS SSD io2, 100 GB, IOPS – 1000

  • Dib: 3 GB, Over 2 million users

Operations

  • Operation: LDAPS (636) Search and Modify operations

  • Percentage: 80% Read 20% Write operations.

  • Search scope: subtree search

  • Search base: ou=users,o=novell

  • Search filter: Random user under Search base

  • Attributes: sn;title

eDirectory Tuning

eDirectory Flaim DB setting:

preallocatecache=true

cache=4000000000cpinterval=360

LDAP Client EC2 Instance

  • Operating System: RHEL8.0

  • LDAP Client tool: JMeter 5.1

  • EC2 Instance type: m5d.4xlarge, 16 CPU, 64 GB RAM

  • TCP Port range: 1024-65534

5.3.3 Determining the Sizing Requirement

In this section, we present our recommendations based on performance data for commonly used scenarios. This data will help you to determine the optimal AWS EC2 Instance for your environment. Before you start with the appropriate sizing estimation for your eDirectory deployment, you must identify the best suited Instance Category for your deployment.

Scenario # 1 - Identifying the AWS EC2 Instance Category

In this performance scenario, we’ll determine the appropriate AWS EC2 Instance Category for eDirectory deployment and operations.

The below graphs depict a measurement of Average Response Time (in milliseconds) and Operations per second respectively against the number of Threads. Measurement has been taken from three instance categories i.e., General Purpose, Memory Optimized and Compute Optimized that belong to 2xlarge Instance Type.

Figure 5-2 Change in average response time based on number of threads performed concurrently for m5a vs r5a vs c5a

Figure 5-3 Change in number of operations performed concurrently based on the number of threads

The below graphs depict a measurement of Average Response time (in milliseconds) and Operations per second respectively against number of Threads. Measurement was taken from three instance categories i.e., General Purpose, Memory Optimized and Compute Optimized that belongs to xlarge type.

Figure 5-4 Change in average response time based on number of threads performed concurrently for m5a vs r5a vs c5a

Figure 5-5 Change in number of operations performed concurrently based on the number of threads

Recommendation

As per the above test scenario, you must use the Compute Optimized instances along with EBS Volume to get the best eDirectory performance when deployed in an AWS environment. Instance type must be chosen initially based on the expected load. You can always resize the Instance type if it doesn’t meet the resource requirements. You must also attach the Provisioned IOPS SSD volume to the EC2 instance for optimal IO and throughput performance.

Scenario # 2 - Identifying the AWS EC2 Sizing Requirement

In the previous performance scenario, we determined that Compute Optimized is the appropriate AWS EC2 Instance Category for eDirectory deployment and operations.

In this performance test scenario, the data has been collected from three different Compute Optimized instance types, i.e., xlarge, 2xlarge and 4xlarge to help you with the best suited sizing guidenace.

The below graphs depict a measurement of Average Response time (in milliseconds) and Operations per second respectively against the number of Threads. For this test, 500 milliseconds were considered as the maximum acceptable average response time.

Figure 5-6 Change in average response time based on number of threads performed concurrently for xlarge vs 2xlarge vs 4xlarge

Figure 5-7 Change in number of operations performed concurrently based on the number of threads

Recommendation

The following table shows the measured maximum number of threads and the corresponding operations per second possible, to keep the average response time within the acceptable limit of 500 milliseconds for each of the specified EC2 instances.

Instance Type

Threads

Operations per Second

c5a.xlarge

1200

2300

c5a.2xlarge

1500

2900

c5a.4xlarge

1750

3500

You can select the best suited Compute instance size based on their expected Thread and throughput values as explained above.