Operating Instructions 14/1543-HDA 104 03/10 Uen A
[ Topics hidden with current filter selection ]

Creating New DSG

Contents


1 Overview

This document provides help to perform the expansion by creating new DS Unit Group (DSG) in the Ericsson Centralized User Database (CUDB) system.

1.1 Description

This document describes the procedure to create a new DSG to a CUDB system.

1.2 Revision Information

Rev. A

Initial release.

1.3 Typographic Conventions

Typographic Conventions can be found in the following document:

2 Prerequisites

Manual scale-out procedure, as well as some steps required to meet the preconditions, which are part of the scale-out policy, can be performed by Ericsson personnel only. Contact the next level of maintenance support if new DSG(s) must be created in the CUDB system.

Before creating new DSG(s), a proper capacity license is required for the number of installed payload blades or VMs on every node hosting the newly created DSG(s).

Perform software and configuration backup and system data backup before creating new DSG(s). Follow the procedures to run backups as specified in CUDB Backup and Restore Procedures.

Do!

In case a network level scale-out is needed, CUDB must be expanded previous to any application Front End (FE) expansion. Otherwise, the new FE connections will not be balanced in the expanded CUDB system.

3 Procedure

If more storage capacity is needed in a CUDB system, new DSGs must be added, which can be done manually as described in Creating a New DSG Manually or using workflow as described in CUDB VNF Lifecycle Management. Manual procedure is only applicable scale-out procedure for native environments, but it can be used for vCUDB environments as well. Workflow procedure for scale-out is only applicable for vCUDB environments. In either way, first check Scale-out Policy, to see if scale-out is the appropriate action.

Note: A drop in Lightweight Directory Access Protocol (LDAP) FE node and server counters may be observed until the procedure has been fully completed.

3.1 Scale-out Policy

Scale-out policy describes the context under which a scale-out action must be applied and the magnitude of the scaling step. Applying the scale-out policy is recommended whenever, on a regular basis, Key Performance Indicator (KPI) thresholds are exceeded, or alarms show up.

Note: Regular basis means repeatedly exceeding thresholds and on similar conditions (for example on traffic peaks or under specific events or seasons). In all cases overload symptoms may be caused by traffic or capacity unbalance on different levels, or both.

Scale-out procedure (DSG expansion) is executed if certain preconditions are met. Prerequisite for scale-out procedure is that the system is in correct state, meaning that the health check procedure does not show any issues that need to be addressed, besides relevant storage and LDAP processing alarms.

3.1.1 Scale-out Preconditions, Prerequisites and Magnitude of the Scaling for the DS Layer

The state of the following alarms and counters must be examined:

If problems persist after the corrective actions have been executed, scale-out is required to obtain additional storage capacity.

Preconditions:

  • The memory usage of DS units in the node is balanced (differences between usage percentage of all DSs are less than kpiDsMemoryUsageUnbalance threshold) before DS scale-out. Memory usage unbalance can be checked from kpiDsMemoryUsageUnbalance counter where corrective actions are also given.

As many additional Ds Units are necessary as suggested by memoryUsage indicator.

Desired low load level may be achieved with N AdditonalBlades = 2 x N DSs x(HighKpi/LowKpi - 1)}, where KPI refers to memoryUsage values, and HighKPI and LowKPI stand for, respectively, current overload condition and lowest (desired target) values for memoryUsage . N DSs is the number of existing DSs in node.

3.1.2 Scale-out Preconditions, Prerequisites and Magnitude of the Scaling for the LDAP Layer

The state of the following alarms and counters must be examined:

If the high LDAP FE load persists after the proper corrective actions have been performed, scale-out is needed to obtain additional LDAP FE processing capacity.

Preconditions:

  • All LDAP FE show similar traffic (differences between traffic of all LDAP FEs are less than kpiLdapFeLoadUnbalance threshold), which can be seen in kpiLdapFeLoadUnbalance indicator, where corrective actions are also given.

If the preconditions are met, additional DS units are needed in the node, as well as in other nodes that will host the replicas of the added DS units.

The number of additional payloads blades or Virtual Machines (VMs) that is needed can be calculated based on the value of the kpiLdapFeLoad:

N AdditionalBlades VMs= N Blades VMs * (HighKPI/ LowKPI -1), where N Additional Blades VMs are required to drop load below threshold; additional DS units must be added to at least cover that number. Since DS units are composed of payload blade or VM pairs, the number of additional DS units can be calculated as:

N additional DS = N AdditionalBlades VMs /2.

HighKPI and LowKPI stand for, respectively, the highest (on overload condition) and lowest (desired target) values for a (percentage) KPI indicator; in this case it applies to kpiLdapFeLoad, so if it reaches 85% and the desired value is 60% (to be below threshold ), and the node already has 12 LDAP FE units, then the scale out step is N VMs = 12 x (85% / 60% -1) = 12 x 0,417 = 5, which must be rounded up to six VMs (or three new DS units).

kpiRatioDroppedLdap exceeded: DS two VMs (one additional DSG).

Do!

N additional VMs must be always rounded up to the next higher even number.

Attention!

If the target node(s) do not have remaining capacity (they eventually reached maximum size), system expansion is necessary. In that case contact the next level of maintenance support.

3.2 Creating a New DSG Manually

Manual scale-out procedure can be performed by Ericsson personnel only. Contact the next level of maintenance support if new DSG(s) must be created in the CUDB system.

Reference List

CUDB Documents

  1. CUDB Backup and Restore Procedures

  2. CUDB VNF Lifecycle Management

  3. Storage Engine, Memory Usage Too High In DS, Warning Threshold Reached

  4. Storage Engine, Memory Usage Too High In DS, Full Threshold Reached

  5. Storage Engine, Out Of Memory In DS

  6. LDAP Front End, High Load in LDAP Processing Layer

Legal |© Ericsson AB 2018