Configuration Manual UDC Data Durability
Ericsson Dynamic Activation 1

Contents

1Introduction
1.1Purpose and Scope
1.2Target Group
1.3Typographic Conventions
1.4Prerequisites

2
Configuration for UDC Data Durability
2.1Network Element - Network Element Group Configuration
2.2Replay User
2.3RESTful Notification Interface
2.4Replay Service
2.5Disable Log Obfuscation
2.6Connection Robustness Tuning

Reference List

1   Introduction

The information in this document is targeted to System and Network administrators. Use this document after installing Ericsson Dynamic Activation (EDA) system.

1.1   Purpose and Scope

The purpose of this document is to describe how to configure, and tune automatic replay of LDAP operations towards CUDB in a layered (UDC) architecture.

As part of UDC Data Durability solution, Dynamic Activation enables automatic replay of LDAP operations in the event of a temporary outage in CUDB.

1.2   Target Group

The target group for this document is as follows:

For detailed information about the target groups, see Library Overview, Reference [1].

1.3   Typographic Conventions

Typographic conventions are described in Library Overview, Reference [1].

For information about abbreviations used throughout this document refer to Glossary of Terms and Acronyms, Reference [2].

1.4   Prerequisites

To make full use of this document, the following prerequisites must be met:

2   Configuration for UDC Data Durability

This section includes information on the different parts that need to be configured and tuned, to establish a complete UDC Data Durability setup.

2.1   Network Element - Network Element Group Configuration

Network Element

One CUDB (LDAP) NE must be created for each LDAP NE used for normal provisioning operation (Primary, Secondary, and Tertiary), where Replay user-dn is used instead of Provisioning user-dn.

Primary, secondary and tertiary CUDB node should be configured as separate NEs.

Network Element Group

The configured primary, secondary, and tertiary NEs are grouped in an NE Group configured in Failover mode.

The CUDB (LDAP) NEs must be assigned to the CUDB-AUTO-REPLAY-GROUP NE Group.

NE configuration and NE Group configuration is performed in the Network Elements > Network Elements, and Network Elements > Network Element Groups submenus in the Dynamic Activation GUI. For more detailed information about NE configuration, refer to User Guide for Resource Activation, Reference [3].

The following is an example on how to configure NEs assigned to CUDB-AUTO-REPLAY-GROUP NE Group, for the Replay solution:

  1. Navigate to the Network Elements > Network Elements submenu in the Dynamic Activation GUI.
  2. Click Add.

    Enter the name of the NE in the Name field, and select the protocol for the NE from the drop-down list.

    For example:

  3. Click Next and specify the protocol parameters.

    For example:

  4. Click Apply.

    A verification page is displayed. The page shows all the parameters defined for the NE. Users can continue to edit the parameters as needed by clicking appropriate icons. If the parameters are correctly set, click Done.

    Note:  
    Add one CUDB (LDAP) NE for each normal provisioning LDAP NE.

  5. Navigate to the Network Elements > Network Element Groups submenu in the Dynamic Activation GUI.
  6. In Network Element Groups - Change - CUDB-AUTO-REPLAY-GROUP, select the NEs to include in the group. Assign Order to the selected NEs.

    For the Failover group type, the order number is used to decide in which order the group should try the different NEs.

  7. Click Apply.

2.2   Replay User

A Replay user needs to be created to be able to start a Replay job, and poll the current state of the Replay service. The user needs to be assigned to the default Replay Administrator role.

  1. Navigate to the Access Control > Users submenu in the Dynamic Activation GUI.
  2. Add a new user.
  3. Configure the user accordingly:
    • Configuration Management Authorities - Authority Level/Roles

      Authority Level > Customize authorities

      Role > Replay Administrator

      Access Type > Full

    • Provisioning Authorities - Authority Level

      Authority Level > No authorities

For more information about how to add, modify and delete users, see User Guide for Resource Activation, Reference [3].

2.3   RESTful Notification Interface

Replay requests towards Dynamic Activation are sent as RESTful notifications from CUDB, indicating an absolute time stamp (POSIX time) from when to start replaying.

The time stamp is configurable for the RESTful notification interface by use of the @MAX_REPLAY_TIME_SPAN@ parameter. This parameter defines how many seconds back in time the Replay accepts a request, when validating its time stamp.

To configure the time stamp, follow the step-list:

  1. Log in as an administrator on one of the System Control (SC) nodes (SC1, or SC2).
  2. Run the following command:

    $ bootloader.py config set --parameter @MAX_REPLAY_TIME_SPAN@ --value <time_in_seconds>

    Note:  
    Default is set to 45 seconds.

    It is not recommended to use a value smaller than 45 seconds, since, in a worse case scenario, CUDB will not be able to request Dynamic Activation to replay the logs.


  3. Activate the modification for both SC nodes, one by one:

    $ bootloader.py node activate --host <hostname>

    <hostname> is the hostname of the SC node that is to be activated.

2.4   Replay Service

Depending on the characteristics of the solution, for example pre-processing and actual time spent for replay operations – limitations apply for which replay requests that can be accepted and which ones that must be rejected.

There are different parameters (time-out/retry attempt/retry factor) defined in Dynamic Activation that can be configured to suit the operator’s preferences.

The following parameters are configurable:

To configure these parameters, follow the step-list:

  1. Log in as an administrator on one of the SC nodes (SC1, or SC2).
  2. From the logged on SC node, run the following commands to modify the parameters:

    $ bootloader.py config set --parameter @REPLAY_TIME_OUT@ --value <time_in_seconds>

    $ bootloader.py config set --parameter @REPLAY_LDAP_RETRY_DELAY@ --value <time_in_milliseconds>

    $ bootloader.py config set --parameter @REPLAY_LDAP_RETRY_FACTOR@ --value <factor>

    $ bootloader.py config set --parameter @REPLAY_LDAP_MAX_SEND_ATTEMPTS@ --value <number_of_attempts>

  3. From the logged on SC node, run the following command, for all nodes, one by one, to activate the change:
    Attention!

    Wait for each node to be activated before starting with the next one, otherwise traffic disturbances occur. The all parameter should only be used when no provisioning traffic is running.

    $ bootloader.py node activate --host <hostname>

    <hostname> is the hostname of the node that is to be activated.

2.5   Disable Log Obfuscation

Log obfuscation for sensitive attribute values must be disabled to support replay operations, which otherwise would be represented by asterisks (******) in the processing log.

To disable log obfuscation, follow the step-list:

  1. Log in as an administrator on one of the SC nodes (SC1, or SC2).
  2. Run the following command:

    $ bootloader.py config set --parameter @LOG_OBFUSCATION_OFF@ --value true

  3. From the logged on SC node, run the following command, for all Payload (PL) nodes, one by one, to activate the modification:
    Attention!

    Wait for each PL node to be activated before starting with the next one, otherwise traffic disturbances occur. The all parameter should only be used when no provisioning traffic is running.

    $ bootloader.py node activate --host <hostname>

    <hostname> is the hostname of the PL node that is to be activated.

2.6   Connection Robustness Tuning

Depending on provisioning rate, Customer Service Order (CSOs)/second, and length of accepted replay time span, the execution time for a replay operation differs.

To avoid response time-outs in the Customer Administration System (CAS) for ongoing, and new provisioning orders during a replay operation – while at the same time, be able to quickly resume provisioning operations upon completing a replay job – it is recommended to configure Network Element Group Retry parameters for LDAP, accordingly.

The following parameter values are recommended for a typical setup with 60 seconds as CAS response time-out:

This configuration allows for resuming a provisioning operation when a replay job is completed, and also keep ongoing and new provisioning orders pending for up to 40 seconds before sending response back to CAS.

For more information about Retry parameters, see Configuration Manual for Resource Activation, Reference [4].

To configure these parameters, follow the step-list:

  1. Log in as an administrator on one of the SC nodes (SC1, or SC2).
  2. From the logged on SC node, run the following commands to modify the parameters:

    $ bootloader.py config set --parameter @IndividualLDAPRetryDelay@ --value <time_in_milliseconds>

    $ bootloader.py config set --parameter @IndividualLDAPRetryFactor@ --value <factor>

    $ bootloader.py config set --parameter @MAX_SEND_ATTEMPTS@ --value <number_of_attempts>

  3. From the logged on SC node, run the following command, for all nodes, one by one, to activate the change:
    Attention!

    Wait for each node to be activated before starting with the next one, otherwise traffic disturbances occur. The all parameter should only be used when no provisioning traffic is running.

    $ bootloader.py node activate --host <hostname>

    <hostname> is the hostname of the node that is to be activated.


Reference List

[1] Library Overview, 18/1553-CSH 109 628 Uen
[2] Glossary of Terms and Acronyms, 0033-CSH 109 628 Uen
[3] User Guide for Resource Activation, 1/1553-CSH 109 628 Uen
[4] Configuration Manual for Resource Activation, 2/1543-CSH 109 628 Uen


Copyright

© Ericsson AB 2017. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    Configuration Manual UDC Data Durability         Ericsson Dynamic Activation 1