CloudOpera Orchestrator SDN V200R002C10 Backup and Restoration Guide 01

CloudOpera Orchestrator SDN
V200R002C10
Backup and Restoration Guide
Issue 01
Date 2018-01-10
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2018. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: [email protected]
Issue 01 (2018-01-10) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Backup and Restoration Guide Preface
Preface
Purpose
This document provides guidance for backing up and restoring the CloudOpera Orchestrator
SDN service instances.
Intended Audience
This document is intended for system maintenance engineers who are familiar with:
l Live network
l Service maintenance
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Conventions
Symbol Description
Indicates an imminently hazardous situation which, if

not avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to
personal injury.
Issue 01 (2018-01-10) Huawei Proprietary and Confidential ii

Symbol Description
Calls attention to important information, best practices

and tips.
NOTE is used to address information not related to
personal injury, equipment damage, and environment
deterioration.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Convention Description
Boldface Buttons, menus, parameters, tabs, window, and dialog

titles are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the

">" sings. For example, choose File > Create > Folder.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italic.
[] Items (keywords or arguments) in square brackets [ ] are

optional.
{ x | y | ... } Alternative items are grouped in braces and separated by

vertical bars. One is selected.
[ x | y | ... ] Optional alternative items are grouped in square brackets

and separated by vertical bars. One or none is selected.
{ x | y | ... } * Alternative items are grouped in braces and separated by

vertical bars. A minimum of one or a maximum of all
can be selected.
[ x | y | ... ] * Optional alternative items are grouped in square brackets

and separated by vertical bars. A maximum of all or
none can be selected.
Issue 01 (2018-01-10) Huawei Proprietary and Confidential iii

Change History
Issue Date Description
01 2018-01-10 This issue is the first official release.
Issue 01 (2018-01-10) Huawei Proprietary and Confidential iv

Backup and Restoration Guide Contents
Contents
Preface................................................................................................................................................ ii
1 Overview......................................................................................................................................... 1
1.1 Backup and Restoration Scenarios................................................................................................................................. 1
1.2 Backup and Restoration Policies.................................................................................................................................... 3
1.2.1 Concepts...................................................................................................................................................................... 4
1.2.2 Backup Policies........................................................................................................................................................... 6
1.2.3 Restoration Policies..................................................................................................................................................... 8
1.3 Backup Server Requirements....................................................................................................................................... 12
2 Data Backup..................................................................................................................................14
2.1 Setting Global Backup Parameters............................................................................................................................... 15
2.2 Backing Up Dynamic Data...........................................................................................................................................18
2.2.1 Logical Backup..........................................................................................................................................................18
2.2.1.1 Backing Up Dynamic Data on Scheduled.............................................................................................................. 18
2.2.1.2 Backing Up Dynamic Data in Real Time............................................................................................................... 20
2.2.2 Physical Backup........................................................................................................................................................ 22
2.3 Backing Up Product Application Software.................................................................................................................. 28
2.4 Backing Up Database Software.................................................................................................................................... 28
2.5 Backing Up OS Data.................................................................................................................................................... 29
2.6 Backing Up Management Plane................................................................................................................................... 30
3 Local Data Restoration................................................................................................................32

3.1 Restoring Dynamic Data.............................................................................................................................................. 32
3.2 Restoring Product Application Software...................................................................................................................... 34
3.3 Restoring Database Software........................................................................................................................................35
3.4 Restoring OS Data........................................................................................................................................................ 37
3.4.1 Restoring Service Node OS Data.............................................................................................................................. 37
3.4.2 Restoring Management Node OS Data..................................................................................................................... 39
3.5 Restoring Management Plane....................................................................................................................................... 42
4 Remote Cold Backup and Restoration.................................................................................... 46

5 Remote Warm Backup and Restoration.................................................................................. 51
5.1 Remote Disaster Recovery System Overview..............................................................................................................51
5.1.1 Positioning................................................................................................................................................................. 51
Issue 01 (2018-01-10) Huawei Proprietary and Confidential v

5.1.2 Benefits...................................................................................................................................................................... 51
5.1.3 Solution Overview..................................................................................................................................................... 52
5.2 Establishing a Remote DR System............................................................................................................................... 53
5.2.1 Node Introduction......................................................................................................................................................53
5.2.2 Environment Requirements....................................................................................................................................... 55
5.2.3 Process Overview...................................................................................................................................................... 57
5.2.4 Installing the Primary and Secondary Site................................................................................................................ 59
5.2.5 Configuring Services of the Primary Site..................................................................................................................61
5.2.6 Security Hardening.................................................................................................................................................... 61
5.2.6.1 Overview................................................................................................................................................................ 61
5.2.6.2 Uploading Node Data Files and Tools....................................................................................................................62
5.2.6.3 MySQL Database Hardening..................................................................................................................................64
5.2.6.4 Remote SSH Security Hardening........................................................................................................................... 66
5.2.6.5 OS Port Hardening..................................................................................................................................................68
5.2.6.6 Security Hardening Requirements..........................................................................................................................72
5.2.7 Configuring the DR System...................................................................................................................................... 72
5.2.7.1 Updating Certificates for the Management Plane and Service Plane..................................................................... 72
5.2.7.2 Backing up the Primary and Secondary Sites.........................................................................................................76
5.2.7.3 Associating the Primary and Secondary Sites........................................................................................................ 76
5.2.8 Migrating the DR System.......................................................................................................................................... 77
5.2.9 Configuring Services of the Secondary Site..............................................................................................................78
5.3 Remote DR System Common Operations.................................................................................................................... 79
5.3.1 Disaster Recovery Scenarios..................................................................................................................................... 79
5.3.2 Disaster Recovery System Drill................................................................................................................................ 80
5.3.3 Taking Over Services from the Faulty Site................................................................................................................81
5.3.4 Forcibly Synchronizing Data Between Sites............................................................................................................. 82
5.3.5 Deleting the Data Synchronization Relationship Between the Active and Standby Sites........................................ 84
5.3.6 Separating the Primary and Secondary Sites............................................................................................................. 85
5.3.7 Updating Certificates for the Disaster Recovery System.......................................................................................... 86
5.3.8 Changing the Encryption Key of DR Certificates..................................................................................................... 88
5.3.9 Manually Synchronizing DR Certificates..................................................................................................................89
5.4 Remote DR System Alarms..........................................................................................................................................91
5.4.1 ALM-100000 Certificate of the Remote DR System About to Expire..................................................................... 91
5.4.2 ALM-101200 Abnormal Replication........................................................................................................................ 92
5.4.3 ALM-101201 Abnormal Heartbeat........................................................................................................................... 93
5.4.4 ALM-101203 Migration Failure................................................................................................................................96
5.4.5 ALM-101204 Abnormal Deployment of the Primary and Secondary Sites..............................................................97
6 Common Operations.................................................................................................................100
6.1 Configuring SFTP Fingerprint Authentication...........................................................................................................100
6.2 How Do I Start a Service?.......................................................................................................................................... 102
6.3 How Do I Stop a Service?.......................................................................................................................................... 102
6.4 Starting a DB Instance................................................................................................................................................ 103
Issue 01 (2018-01-10) Huawei Proprietary and Confidential vi

6.5 Stopping a DB Instance.............................................................................................................................................. 104

6.6 Selecting One or Multiple Backup Objects................................................................................................................ 104
7 FAQ.............................................................................................................................................. 106
7.1 Failed to Create Dynamic Data Backup Tasks........................................................................................................... 106
7.2 Failed to Create Service Restoration Tasks................................................................................................................ 107
7.3 OS Security Hardening Items..................................................................................................................................... 107
7.4 MySQL Database Security Hardening Items..............................................................................................................119
7.5 How to Upload Files to a Specified Directory After OS Security Hardening Is Performed...................................... 122
7.6 Updating Certificates of Active and Standby Sites Manually.................................................................................... 123
7.6.1 Updating CA Certificates of Management Nodes................................................................................................... 123
7.6.2 Updating CA Certificates of Non-Management Nodes...........................................................................................125
7.6.3 Updating the Certificate Password.......................................................................................................................... 127
7.7 Changing Passwords for Backup Server User............................................................................................................ 127
Issue 01 (2018-01-10) Huawei Proprietary and Confidential vii

Backup and Restoration Guide 1 Overview
1 Overview
The product data should be backed up in a timely manner so that when the product
malfunctions, backup files can be used to restore data so that the product can be fast restored.
Before performing backup and restoration operations, understand backup and restoration
scenarios and policies.
1.1 Backup and Restoration Scenarios

Understanding backup and restoration scenarios helps you back up and restore databases in a
timely manner to ensure stable running of CloudOpera Orchestrator SDN.
1.2 Backup and Restoration Policies
Before using the backup and restoration function, you are advised to learn the backup and
restoration policies. A backup policy specifies the backup information, such as the backup
mode, the backup path, and other information to ensure that users can create backup tasks
successfully. A restoration policy specifies the data restoration sequence to ensure that users
can restore data successfully.
1.3 Backup Server Requirements
1.1 Backup and Restoration Scenarios

Understanding backup and restoration scenarios helps you back up and restore databases in a
timely manner to ensure stable running of CloudOpera Orchestrator SDN.
User Password Modification Impact

After data restoration is complete, the passwords of CloudOpera Orchestrator SDN users
(users except the OS user) are restored to those saved in backup data. Therefore, keep your
old password safe after periodic password change. If you have changed user passwords after
data backup and before data restoration, change the user passwords again after data
restoration.
Requirement on the Backup Directory Space

A backup task can be successfully executed only when the backup directory has sufficient
space. You are advised to run the df -h command weekly to check whether the backup
directory has sufficient space.
Issue 01 (2018-01-10) Huawei Proprietary and Confidential 1

Backup Scenarios
To fast restore data, backup is required in the following scenarios. Table 1-1 lists common
backup scenarios. Ensure that no system or service provisioning operation that takes much
time is performed.
Table 1-1 Backup scenarios
Scenario Backup Scheme
Periodical backup of service instance data Periodically dynamic back up data.
Before or after service upgrade 1. Real-time dynamic back up

data.
2. Back up the product
application software.
Before or after database upgrade or patch installation 1. Real-time dynamic back up

data.
2. Back up database software.
Before or after OS upgrade or patch installation 1. Real-time dynamic back up

data.
2. Back up the product
application software.
3. Back up database software.
4. Back up the OS data.
5. Back up the management
plane.
After initial installation of CloudOpera Orchestrator Back up the management plane.

SDN, before or after CloudOpera Orchestrator SDN
upgrade or patch installation, or before major
business adjustment
Restoration Scenarios
To restore a service instance whose database instances are running properly but the service
instance is unavailable because of data errors, select the corresponding backup files and
restore data. Table 1-2 lists common restoration scenarios.
Table 1-2 Restoration scenarios
Scenario Backup File
Generally, if the service instance cannot be used Periodically dynamic back up data.
because the database instance is running properly, but
the service instance data is abnormal, you can restore
the service instance data to the state in a certain time
point.

Scenario Backup File
l If the service instance fails to be upgraded and 1. Product application software

needs to be rolled back to the state before the backup files
upgrade, you can use the backup data to restore 2. Dynamic data backup files
the service instance to the data before the upgrade.
l If the service instance is upgraded successfully or
patch installation is successful, but the system is
abnormal, you can use the backup data to restore
the service to the state after the upgrade or patch
installation.
l If the database upgrade or patch installation fails, 1. Database software backup files
database files are damaged, but the OS still runs 2. Dynamic data backup files
properly, you can use the backup data to restore
the database to the state before the upgrade or
patch installation.
l If database upgrade or patch installation is
successful, CloudOpera Orchestrator SDN is
abnormal, the database files are damaged, but the
OS still runs properly, you can use the backup
data to restore the database to the state after the
upgrade or patch installation.
l If the OS upgrade or patch installation fails and l Restoring Service Node OS

the OS cannot start, you can use the backup data Data:
to restore the OS to the state before the upgrade or 1. OS backup files
patch installation.
2. Database software backup
l If the OS upgrade or patch installation is files
successful, but CloudOpera Orchestrator SDN is
abnormal and the OS cannot start, you can use the 3. Product application
backup data to restore the OS to the state after the software backup files
upgrade or patch installation. 4. Dynamic data backup files
l Restoring Management Node
OS Data:
1. OS backup files
2. Management-plane backup
files
The management plane cannot be accessed normally. Management-plane backup files
Restore the management-plane backup data of site A Management-plane backup files

on site B so that site B becomes the backup site of and dynamic data of site A
site A.
1.2 Backup and Restoration Policies

Before using the backup and restoration function, you are advised to learn the backup and
restoration policies. A backup policy specifies the backup information, such as the backup
mode, the backup path, and other information to ensure that users can create backup tasks

successfully. A restoration policy specifies the data restoration sequence to ensure that users
can restore data successfully.
1.2.1 Concepts
Understanding common concepts of the backup and restore operations will help you
understand the backup and restoration scenarios and policies.
Product
A product contains multiple services.
Service
A service is a set of on-demand, dynamic, and scalable software that is provided for
applications (and third-party applications).
Database Instance
A database instance is a process and the database files it controls. A database instance is a set
of multiple databases.
Service Instance
A service instance contains multiple microservice instances. One database corresponds to one
or more microservice instances.
Figure 1-1 illustrates the relationship between service instances and database instances.
Figure 1-1 Relationship between service instances and database instances

Associated Service
When multiple service instances share the same database, these service instances are
associated services. One of the associated service instances is selected, all the associated
service instances are also selected. These associated service instances are backed up or
restored as a whole.
In Figure 1-2, service 1 and service 2 are associated services (sharing database A). If you
select service instance 1 or service instance 2, the other service instance will also be selected.
That is, service instance 1 and service instance 2 are both selected. Service instance 1 and
service instance 2 are backed up or restored.
Figure 1-2 Microservice instance 1 and microservice instance 2 sharing database A
Data Description
Data Type Data Description
OS data Indicates the operating system data of all product nodes,

that is, the data when you back up the OS.
Static data Indicates the data that will not change in real time when
the system runs, that is, the data when you back up the
product application software and database software.
Dynamic data Indicates the data that changes in real time when the
system runs, that is, the service instance data.
Full Backup
All the selected data and files of a time point are completed backed up. The backup mode
provided in this document supports only full backup.
Incremental Backup
Compared with the last backup, data and files that have changed will be backed up. The
backup mode provided in this document does not support incremental backup.

Management Node
Log in to the IP address of the management plane of CloudOpera Orchestrator SDN. The
management node is the node whose name ends with Deploy in the node plan.
1.2.2 Backup Policies

Before backing up data, understand the backup policies. CloudOpera Orchestrator SDN backs
up service instances based on service backup policies and stores data to specified directories.
Backup Parameters
Table 1-3 describes backup parameters.
Table 1-3 Backup parameters
Item Description
Transmission mode CloudOpera Orchestrator SDN supports the Secure File

Transfer Protocol(SFTP) transfer mode.
Backup file storage threshold The maximum number of latest backup files that
CloudOpera Orchestrator SDN can store is limited. If the
number of backup files exceeds seven, the earliest
backup files will be deleted automatically.
The default number of latest backup files that can be
stored is as follows:
l Dynamic data: 15.
l Product application software: 1.
l Database software: 5.
l OS: 3.
l Management plane: 3.
The threshold for storing backup files of dynamic data
can be modified by referring to 2.1 Setting Global
Backup Parameters. The threshold for storing backup
files of the management plane can be modified by
referring to 3.5 Restoring Management Plane. The
product application software, database software, and OS
are not often backed up and restored. The default backup
file storage threshold for these three types of data is
already the recommended value in CloudOpera
Orchestrator SDN. You do not need to manually change
the threshold.
Backup Mode
l Scheduled backup: Data is automatically backed up to a backup server at scheduled time.
There are three types of scheduled backup: one-time backup, periodic scheduled backup,
and default scheduled backup.

– One-time backup: Data of a service is backed up once at a specific time point.

– Periodic backup: Data of a service is backed up periodically at a specific time point.
NOTE
For periodic scheduled backup, you are advised to set the backup interval to one day.
Although the interval can be user-defined, a long interval is not recommended because data
backup at long intervals may result in data loss during data restoration.
– Default scheduled backup: After CloudOpera Orchestrator SDN is successfully
installed and the backup server parameters are set, the system automatically creates
a default scheduled backup task which will be executed at 01:00:00 every day.
l Manual backup: Data of a service instance is manually backed up to a backup server.
Figure 1-3 shows the backup modes supported by various types of data.
Figure 1-3 Backup modes supported by various types of data
Common Backup Schemes

In the 1.1 Backup and Restoration Scenarios section, some common backup scenarios are
described. Table 1-4 lists the corresponding backup schemes for the common backup
scenarios. The backup of the three types of data is independent from each other.
Table 1-4 Backup scenarios
During the normal running of the product, Periodically dynamic back up data. It is
the dynamic data changes in real time. recommended that the backup period is set to
Therefore, you need to obtain the latest 1 day.
dynamic data to restore the product when
the product is faulty.
Before or after service application software l Backing up dynamic data manually.

upgrade. l Back up the product application software.
After the database user password is Back up the management plane.

changed.

After OS upgrade or patch installation. l Backing up dynamic data manually.

l Back up the product application software.
l Back up database software.
l Back up the OS data.
l Back up the management plane.
l After the IP address of the product node Back up the OS data.

is changed.
l After the host name of the product node
is changed.
l After the password for the OS user of
the product node is changed.
l CloudOpera Orchestrator SDN is Back up the management plane.

installed and commissioned. Services
are running properly.
l After upgrade or patch installation of
CloudOpera Orchestrator SDN.
Backup Task Execution Strategy

When multiple backup tasks need to be executed at the same time (for example, 01:00:00), the
system performs the backup tasks based on the following strategies:
l The same type of backup tasks of the same product cannot be executed at the same time.
The system executes the backup tasks in sequence based on the creation time of the
backup tasks.
For example, if the system needs to execute two dynamic data backup tasks of product A
at 01:00:00, the task that is created earlier is executed first.
l Different types of backup tasks of the same product can be executed at the same time.
For example, if the system needs to execute the dynamic data backup task and product
application software backup task of product A at 01:00:00, the backup tasks will be
executed at the same time.
l Backup tasks of different products can be executed at the same time.
1.2.3 Restoration Policies

Data Restoration Dependency
In the 1.2.1 Concepts section, the three types of data in CloudOpera Orchestrator SDN have
been described. The three types of data are dependent on each other for data restoration, as
shown in Figure 1-4.

Figure 1-4 Data restoration dependency
l If you need to restore all the three types of data, restore operating system data, static
data, and dynamic data in sequence.
l If you need to restore static data and dynamic data, restore static data first.
Common Restoration Scheme

In the 1.1 Backup and Restoration Scenarios section, some common restoration scenarios
are described. Table 1-5 lists the corresponding restoration schemes for the common
restoration scenarios.
Table 1-5 Restoration scenarios

Scenario Restoration Backup File
Scheme
Generally, if the product cannot be used Restoring Periodical backup files

because the database instance is running dynamic data
properly, but the dynamic data is
abnormal, you can restore the product
data to the state in a certain time point.


Scheme
If the product fails to be upgraded and Perform the 1. Product application

needs to be rolled back to the state following software backup files
before the upgrade, you can use the operations in 2. Dynamic data backup
backup data to restore the product to the sequence: files
data before the upgrade. 1. Restoring
product
application
software
2. Restoring
dynamic
data
CloudOpera Orchestrator SDN is Perform the 1. Database software

abnormal, the database files are following backup files
damaged, but the OS still runs properly, operations in 2. Dynamic data backup
you can use the backup data to restore sequence: files
the database to the state after the 1. Restoring
upgrade or patch installation. database
software
2. Restoring
dynamic
data


Scheme
l CloudOpera Orchestrator SDN is To restore the l Restoring service node

initially installed. An exception OS of a service OS data:
occurs on the VM OS. The backup node, perform 1. OS backup files
files can be used to restore the VM the following
OS to the initial installation status. operations in 2. Database software
sequence: backup files
l CloudOpera Orchestrator SDN is
abnormal and the OS cannot start, 1. Restoring 3. Product application
you can use the backup data to OS data software backup files
restore the OS to the state after the 2. Restoring 4. Dynamic data backup
upgrade or patch installation. database files
software l Restoring management
3. Restoring node OS data:
product 1. OS backup files
application 2. Management-plane
software backup files
4. Restoring
dynamic
data
To restore the
OS of a
management
node, perform
the following
operations in
sequence:
1. Restoring
OS data
2. Restoring
management
Plane
An exception occurs on the Restoring Management-plane backup

management-plane services or the management package. A management-
database. As a result, the management plane plane backup package
plane cannot be accessed. The contains the application
management-plane backup package can software packages, database
be used to restore the management plane software packages, and
to the status before the exception occurs. dynamic data backup files of
the management plane.


Scheme
Restore the management-plane backup Remote Management-plane backup

data of site A on site B so that site B Restoration files and dynamic data of site
becomes the backup site of site A. For A
example, in a DR scenario, you can
restore data at the active site to the
standby site by using the remote
recovery function. In this way, data at
the standby site is manually
synchronized to the active site.
1.3 Backup Server Requirements

Indicates the server that stores remote backup data. Virtual machine (VM) that meets the
following requirements functions as the backup server:
Table 1-6 BackupServer Requirements

Requirement Description
Operating system SuSE12SP2 or SuSE11SP3.
SFTP l The VM supports SFTP. You have

obtained the user name and password of
the SFTP protocol.
l Users who log in to the backup server in
SFTP mode have access rights to the
SFTP shared directory.
l The number of SFTP concurrent
connections of the backup server should
not be fewer than 50.
User Name l Cannot be empty.

l Contains a maximum of 32 characters.
l Cannot contain newline characters,
carriage return characters, tab characters,
form feeds, and the following special
characters < > & " ' , ; @

Requirement Description
Password l Cannot be empty.

l Contain 8 to 30 characters.
l Be a combination of the following four
types of characters:
– At least one uppercase letter.
– At least one lowercase letter.
– At least one digit.
– At least one of the following special
characters ~ @ # ^ * - _ +
[{}]:./?
l Not be the same as or the reverse of the
user name.
l Not contain more than two consecutive
identical characters.
Connectivity l The VM can communicate with all

nodes in the system.
l The communication between the IP
address of the backup server and the IP
address of the service database node is
normal.
Disk space More than 600GB.
Bandwidth Recommended requirements: 1.5Gbit/s.

Minimum requirements: 1Gbit/s.

Backup and Restoration Guide 2 Data Backup
2 Data Backup
After global backup parameters are set successfully, in order to ensure the safety and stability
of CloudOpera Orchestrator SDN, you need to back up the data. When CloudOpera
Orchestrator SDN is abnormal, you can use the backup data to restore CloudOpera
Orchestrator SDN.
NOTICE
The backup data may contain some personal information (such as names, mobile numbers,
and email addresses) as well as the names and passwords of all users configured on
CloudOpera Orchestrator SDN. You must follow the applicable laws in your country or the
privacy policies of your company and take effective measures to fully protect customer
privacy.
2.1 Setting Global Backup Parameters

Backup files are backed up to the corresponding backup server through a specified backup
path. Therefore, if global backup parameters are not set, set backup server parameters and
backup file storage policies before backing up data through CloudOpera Orchestrator SDN.
2.2 Backing Up Dynamic Data
The service deployment system provides the operation UI and supports logical and physical
backup of service instance data. These two backup modes apply to different scenarios. You
are advised to periodically use both of them to back up service instance data.
2.3 Backing Up Product Application Software
This section describes how to back up product application software through CloudOpera
Orchestrator SDN.
2.4 Backing Up Database Software
This section describes how to back up database software through CloudOpera Orchestrator
SDN.
2.5 Backing Up OS Data
This section describes how to back up OS data through CloudOpera Orchestrator SDN.
2.6 Backing Up Management Plane
After patches are installed on product service applications or database software or after the
first installation or upgrade of a product, you are advised to back up the management plane.

You can manually back up the management-plane applications and service instance data
through CloudOpera Orchestrator SDN.
2.1 Setting Global Backup Parameters

Backup files are backed up to the corresponding backup server through a specified backup
path. Therefore, if global backup parameters are not set, set backup server parameters and
backup file storage policies before backing up data through CloudOpera Orchestrator SDN.
Prerequisites
You have obtained the IP address of the backup server, the user name and password of the
SFTP protocol, and the storage path for the backup files.
Context
If multiple backup servers are configured in the same region, the same backup data is stored
on all backup servers in the region. Backup servers in this region work in redundancy mode.
When a backup server is faulty, other backup servers can provide backup data.
Setting Backup Server Parameters

Step 1 You have logged in to the service deployment system of CloudOpera Orchestrator SDN with
the floating IP address of the primary and secondary management nodes:31943) using a
browser.
Step 2 Choose Backup and Restore > Configurations > Configure Global Backup Parameters
from the main menu.
NOTE
Due to data cache, it takes about 20 seconds to open the page for the first time. The waiting time
depends on the number of services in the system and the server performance.
Step 3 In the Configure Backup Server Parameters area, click Add Backup Servers and set
backup server parameters. For details about how to set server parameters, see Table Table
2-1.
Table 2-1 Backup Server Parameters
Parameter Description
Transmission Mode The transmission mode between server and the backup server.
Only the SFTP mode is supported.

Backup server IP l If there is a planned backup server, enter the IP address of

address the backup server, for example, 10.10.10.20.
l If the management node is used as the backup server, enter
the IP address of the management node, for example,
10.10.10.233.
NOTICE
If the management node is used as the backup server, the management
node space may be insufficient and the system performance may be
affected. Therefore, exercise caution when you perform this operation.
Parameters User name and corresponding password for the SFTP protocol.
Enter the user name and password according to the actual
situation.
If the primary and secondary management node serves as a
backup server, the corresponding user account is backupuser.
The default password of backupuser is Changeme_123.
NOTE
l In security hardening scenarios, the root user does not support SFTP.
Therefore, you are advised to use the backupuser user, not the root
user, as the backup server user.
l If changing the password for the backup server user, you need to
change the password for the backup server in the global backup
parameters. If you do not change the password, CloudOpera
Orchestrator SDN cannot access the backup server. As a result, the
backup and restore function cannot be used.
Region Select the region where the backup server is deployed.
Server Connectivity Click Validate to verify that fingerprint authentication for all
nodes are added and connectivity for the backup server is tested.
l If the Warning dialog box is displayed, click OK to add
fingerprint authentication. Otherwise, fingerprint
authentication is not added to the node. The node cannot
connect to the backup server, which will result in data
backup failure.
l If the Warning dialog box is not displayed, fingerprint
authentication has been added for all nodes.
NOTE
The execution duration of verification varies depending on the number
of nodes in the system and the machine performance. The execution
duration is about 30 seconds.

Backup Path Click Browse to set the backup path for the backup server.
l If the planned backup server is used, select a path based on
the site requirements.
NOTE
l The system has automatically associated with this backup path. You
can choose a desired one based on site requirements.
l The backup path must be subfolders under the SFTP shared
directory, such as bin.
l A backup task can be successfully executed only when the backup
directory has sufficient space. You are advised to run the df -h
command to check whether the backup directory has sufficient
space.
l If the management node is used as the backup server, select
the dev directory.
Step 4 Click in the row of the newly added backup server to save information about it.
----End
Setting the Storage Strategy of the Dynamic Data Backup File

l Set the storage threshold for backup files of a single product or service instance.
a. In the Configure Storage Strategy of the Dynamic Data Backup File area, select
the product to be backed up and click in the Details column.
b. Select service instances of the product that need to be backed up, enter the number
of backup files in the Backup File Storage Threshold column and click OK.
NOTE
If the target service is associated with other services, when the target service is selected, the
associated services are also selected. If the storage threshold of the target service is
modified, the modification also applies to the associated services. For details about the
association relationship between services, see section 1.2.1 Concepts.
c. In the displayed dialog box, click OK.
l Set the storage threshold for backup files of products or service instances in batches.
a. In the Configure Storage Strategy of the Dynamic Data Backup File area, select
the product to be backed up and click in the Details column.
b. Select the target product or the service instance under the product.
c. Enter the number of backup files in Batch Modifying Selected Threshold and
click Apply.
d. In the Warning dialog box, click OK.
e. At the bottom of the page, click OK.
f. In the dialog box that is displayed, click OK.

2.2 Backing Up Dynamic Data

The service deployment system provides the operation UI and supports logical and physical
backup of service instance data. These two backup modes apply to different scenarios. You
are advised to periodically use both of them to back up service instance data.
Context
Logical backup and physical backup have different definitions and application scenarios. For
details, see Table 2-2.
Table 2-2 Backup modes
Backup Mode Definition Application Scenario
Logical backup Run structured query language 1.1 Backup and Restoration
(SQL) statements to export data Scenarios
from the database and save the
exported data in a file. If the status
of a task is not Succeeded during
logical backup of a database
instance in the service deployment
system, data of the task cannot be
restored during logical restoration
of the database instance.
Physical backup Copy operating system files If the master and slave database
included in the database from a instances are abnormal, you are
directory to another. advised to use this mode to back
up database configuration files.
2.2.1 Logical Backup

Logical backup: Run SQL statements to export data from the database and save the exported
data in a file.
2.2.1.1 Backing Up Dynamic Data on Scheduled

CloudOpera Orchestrator SDN allows you to create scheduled backup tasks for service
instance. The scheduled tasks can be performed once or periodically.
Prerequisites
l Global backup parameters have been set. For details, see 2.1 Setting Global Backup
Parameters.
l Service instance whose database instances are running properly.

Context
l Before creating a backup task, ensure that no system or service provisioning operation
that takes much time is performed, preventing the backup task from affecting other
operations.
l 24 hours after CloudOpera Orchestrator SDN is successfully installed, the system
automatically enables scheduled backup and automatically backs up all the current
services data at 01:00:00 every day (excluding the new added or deleted service
instances). If you want to create another scheduled backup task, see the following
procedure.
Procedure
Step 1 Open a web browser, input https://IP address with the floating IP address of the primary and
secondary management nodes:31943 in the address box and press Enter.
Step 2 Input the user name admin and password on the login page, and click Log In.
Step 3 Choose Backup and Restore > Configurations > Schedule Backup Data from the main
menu.
NOTE
Step 4 Click Create.
Step 5 On the Select backup object page, set the backup object.
1. Set the scheduled task type. The options are One-Time Task and Periodic Task.
2. Select the product to be backed up and click in the Detail Information column.
3. Select service instances of the product that need to be backed up and deselect SMS/
WAN.

NOTE
If the service instance to be backed up is associated with other service instances, when the service
instance is selected, the associated service instances will also be selected. For details about the
association relationship between service instances, see 1.2.1 Concepts.
4. Click Next.
Step 6 On the Set schedule parameters page, set the relevant parameters and click Next.
Step 7 (Optional) On the Set the backup reason page, enter descriptions of the current backup task
in the Backup reason text box to differentiate the current task from other backup tasks.
Step 8 Click Next. In the displayed Warning dialog box, click OK.
l The task is created successfully. After the task starts, click Task Information List to
view the task execution results.
l If the task fails, contact Huawei technical support.
----End
Related Tasks
After a scheduled backup task is created, you can click Modify to modify the created
scheduled backup task.
2.2.1.2 Backing Up Dynamic Data in Real Time

After service instances are installed, you can manually back up service data through
CloudOpera Orchestrator SDN before modifying configuration files that will affect functions
and upgrading tasks and after the service deployment system certificates are updated.

Prerequisites
l You have set global backup parameters. For details, see 2.1 Setting Global Backup
Parameters.
l Service instance whose database instances are running properly.
Context
Ensure that no system or service provisioning operation that takes much time is performed.
Procedure
Step 3 Choose Backup and Restore > Backup data > Backup Dynamic Data from the main menu.
NOTE
Step 4 On the Select backup object page, select the product to be backed up and click in the
Detail Information column. Select services of the product that need to be backed up, deselect
SMS/WAN, and click Next.
NOTE
If the service instance to be backed up is associated with other service instances, when the service
instance is selected, the associated service instances will also be selected. For details about the
association relationship between service instances, see section 1.2.1 Concepts.

Step 5 (Optional) On the Set the backup reason page, enter the name of the current backup task in
the Backup reason text box to differentiate the current task from other backup tasks.
l The task is created successfully. To view the task execution results, click Task
Information List.
----End
2.2.2 Physical Backup

To ensure that a physical backup file is available to restore the database configuration file
when the master and slave database instances both are abnormal and a fault occurs, you are
advised to perform physical backup periodically.
Prerequisites
Ensure that fingerprint authentication is added to the master and slave database nodes and
primary and secondary management nodes. For details, see 6.1 Configuring SFTP
Fingerprint Authentication.
Procedure
Step 1 Log in to the service deployment system (https://IP address with the floating IP address of the
primary and secondary management nodes:31943).
Step 2 Modify the backup policy.

1. On the main menu, choose Deployment > Database > Backup Policy. The Backup
Policy page is displayed.
2. Select the backup policy whose Policy Name is default, click in the Operation
column, and modify the backup policy.
NOTE
The backup policy whose Policy Name is default is the default backup policy. Directly modify it
to facilitate physical backup.
Set Backup mode to Physical backup, and set other backup policy parameters with
reference to Table 2-3.

Table 2-3 Backup policy parameter description

Paramete Explanation Setting Method Recommend
r ed Value
Backup You are advised to For example: default

policy uniformly plan this – Deploy-Day-Physical
name parameter to facilitate
the use of backup – Deploy-Day-Logic
policy names during
database backup.
Descriptio This parameter For example: -

n indicates the – 1Day Physical+1Hour
description of a backup Increment Backup
policy.
– 1Day Logic Backup


r ed Value
Scheduled – OFF: Scheduled Set the following Scheduled

Backup backup is disabled. parameters when the Backup:ON
– ON: Scheduled scheduled backup is Backup
backup is enabled. enabled: Mode:Physical
– Start time: includes date backup
and time.
– Backup period:
includes day, week or
month. If the backup
period is one day, set the
incremental backup for
the physical backup. You
can select one of the
following values from
the Incremental backup
period drop-down list:
n 0: Do not implement
incremental backup.
n 30: Implement
incremental backup
at an interval of 30
minutes.
NOTICE
Implementing
incremental backup at
an interval of 30
minutes causes
frequent backups and
high resource usage.
The server must
complete backup
within 30 minutes.
Exercise caution when
performing this
operation.
n 60: Implement
incremental backup
at an interval of 1
hour.
n 240: Implement
incremental backup
at an interval of 4
hours.


r ed Value
NOTICE
If the incremental backup
is set, data is
incrementally backed up at
an interval specified by
Incremental Backup
Period after the first
physical full backup was
successful. (Backup
results can be queried in
Backup History).
– Backup Mode: logical
backup or physical
backup. Select a backup
mode according to the
backup policy. Normally,
if database instances are
abnormal, select physical
backup.


r ed Value
Backup – Back up to local - Back up to

Path server: By default, remote server
backup files are
saved to
the /opt/pub/
backup_local
directory on the
server where the
database instance is
located. The owner
of the backup files is
dbuser:dbgroup. If
the /opt/pub/
backup_local
directory does not
exist, manually
create the directory
and set the owner of
the directory to
dbuser:dbgroup
and permission on
the directory to 750.
– Back up to remote
server: Backup files
are saved to a
remote server based
on the configured
protocol. Backup
files are saved to a
remote server based
on the configured
protocol. The path
for physical backup
must be different
than the path for
logical backup
configured in Step 3
NOTE
For physical backup,
only Back up to remote
server can be selected. If
no remote backup server
is planned and available,
you are advised to use
the primary management
node as the remote
backup server.


r ed Value
Backup Backup times: When - 7

file the backup frequency
exceeds the value
specified by Backup
times, the earliest
backup file will be
deleted.
NOTE
– If Scheduled Backup is enabled, the system completes physical backup when the specified
time arrives.
– If Scheduled Backup is disabled, manually perform physical backup with reference to Step 3.
Step 3 (Optional) Manually back up data.

1. On the Deployment > Database > RDBMS page, select all database instances, and click
Manual Backup.
NOTE
When you select all database instances, only the database instances on the current page can be
selected by default. If the database instances occupy more than one page, select all database
instances on each page in sequence.
2. On the Manual Backup page, select the backup policy whose Backup mode is set to
Physical backup and Policy Name is selected as described in Step 2.2.
3. Click OK. Manual backup is successfully issued. When the manual physical backup
policy is successfully issued, the Deployment > Microservices Deployment > Tasks
page is displayed.
4. On the displayed Task List page, view Progress and Status information of each task of
database instance physical backup.

When the progress of each database instance physical backup task reaches 100% and
Status is successful, physical backup is successful.
----End
2.3 Backing Up Product Application Software

This section describes how to back up product application software through CloudOpera
Orchestrator SDN.
Prerequisites
You have set global backup parameters. For details, see 2.1 Setting Global Backup
Parameters.
Procedure
Step 3 Choose Backup and Restore > Backup data > Backup Product Application Software
from the main menu.
Step 4 On the Select backup object page, select the object product and click Next.
Step 5 (Optional) On the Set the backup reason page, enter the backup task name for Backup
reason to distinguish it from other backup tasks.
l The system has created a task successfully. Click Task Information List to view the
task execution status.
l If the task execution fails, rectify the failure based on detailed information about the task.
----End
2.4 Backing Up Database Software

This section describes how to back up database software through CloudOpera Orchestrator
SDN.

Prerequisites
Parameters.
Procedure
Step 3 Choose Backup and Restore > Backup data > Backup Database Software from the main
menu.
Step 4 On the Select backup object page, select the object product and click Next.
----End
2.5 Backing Up OS Data

This section describes how to back up OS data through CloudOpera Orchestrator SDN.
Prerequisites
Parameters.
Procedure
Step 3 Choose Backup and Restore > Backup data > Backup Backup Operating System from
the main menu.
Step 4 On the Select backup object page, select the object node and click Next.

----End
2.6 Backing Up Management Plane

After patches are installed on product service applications or database software or after the
first installation or upgrade of a product, you are advised to back up the management plane.
You can manually back up the management-plane applications and service instance data
through CloudOpera Orchestrator SDN.
Prerequisites
Parameters.
Procedure
Step 1 Choose Backup and Restore > Backup data >Backup Management from the main menu.
Step 2 (Optional) Enter the number of backup files in the Backup File Storage Threshold row.
Step 3 Create corresponding backup tasks as required, including the manual task and the timed task.

Table 2-4 Manual task and timed task

Task Operation
Manual Task 1. On the Manual Task tab, click Backup.

2. In the Warning dialog box, click OK.
3. Choose System > Task Manager > Task
Information List to view the task status. If the
task failed to be executed, rectify the failure based
on detailed information about the task.
Timed Task Create a task. 1. On the Timed Task tab, click Create.
2. Set parameters according to the plan, and then
click Save.
After the timed task is created successfully,
choose System > Task Manager > Task
Information List to view the task status.
– If the task is successfully executed, no further
operation is required.
– If the task failed to be executed, choose
System > Task Manager > Task Information
List to view the task status and rectify the
failure based on detailed information about the
task.
Modify a task. 1. On the Timed Task tab, select the task to be

modified and click Modify.
2. Set parameters based on site requirements, and
click Save.
NOTE
If you need to exit the editing mode during the
modification, click Refresh. This operation will clear
the selected or edited data.
Delete a task. 1. On the Timed Task tab, select the task to be

deleted and click Delete.
Refresh tasks. On the Timed Task tab, click Refresh to refresh the
timed task list.
----End

Backup and Restoration Guide 3 Local Data Restoration
3 Local Data Restoration
When CloudOpera Orchestrator SDN is abnormal, you can use the backup data to restore
CloudOpera Orchestrator SDN.
3.1 Restoring Dynamic Data

To restore a service instance whose data instances are running properly but the service
instance is unavailable because of data errors, restore data through CloudOpera Orchestrator
SDN based on the restoration scenario.
3.2 Restoring Product Application Software
This section describes how to restore product application software through CloudOpera
Orchestrator SDN.
3.3 Restoring Database Software
This section describes how to restore database software through CloudOpera Orchestrator
SDN.
3.4 Restoring OS Data
If the OS upgrade or patch installation fails and the OS cannot start, you can use the backup
data to restore the OS to the state before the upgrade or patch installation.
3.5 Restoring Management Plane
If the management plane cannot be accessed normally due to management service or
management-plane database errors, restore the management plane by performing the
following operations.
3.1 Restoring Dynamic Data

To restore a service instance whose data instances are running properly but the service
instance is unavailable because of data errors, restore data through CloudOpera Orchestrator
SDN based on the restoration scenario.
Prerequisites
l Data of the service instances to be restored has been backup up. For details, see 2.2.1.1
Backing Up Dynamic Data on Scheduled or 2.2.1.2 Backing Up Dynamic Data in
Real Time.
l Service instances to be restored are in the stopped state, and database instances are
running properly. For details, see 6.3 How Do I Stop a Service?.

Context
The system automatically checks the file integrity. If the files are complete, the system starts
restoration.
Procedure
Step 3 Choose Backup and Restore > Restore Data > Restore Dynamic Data from the main
menu.
NOTE
Step 4 On the Restore Dynamic Data page, select the backup server.
Step 5 Select the product to be restored and click in the Detail Information column.
NOTE
Selecting Product restores a service on the service or O&M node.
Step 6 Select service instances of the product that need to be restored and deselect SMS/WAN.
Select corresponding backup files in the Backup File column based on the restoration
scenario and click Restore at the bottom of the page.

NOTE
If the service instance to be restored is associated with other service instances, when the service instance
is selected, the associated service instances will also be selected. For details about the association
relationship between service instances, see section 1.2.1 Concepts.
NOTICE
If the SMS/WAN service instance is restored, no data are displayed for each host IP address
after you choose Service Monitor > Service Monitoring > Hosts. For details about service
monitoring, see "Viewing Monitoring Data" in Maintenance Guide.
Step 7 In the displayed Warning dialog box, click OK.

----End
Follow-up Procedure
Start the restored service instances. For details, see section 6.2 How Do I Start a Service?.
3.2 Restoring Product Application Software

This section describes how to restore product application software through CloudOpera
Orchestrator SDN.

Prerequisites
l Data of the service instances to be restored has been backup up. For details, see 2.2.1.1
Backing Up Dynamic Data on Scheduled or 2.2.1.2 Backing Up Dynamic Data in
Real Time.
l Service instances are in the stopped. For details, see 6.3 How Do I Stop a Service?.
Procedure
Step 3 Choose Backup and Restore > Restore Data > Restore Product Application Software
from the main menu.
NOTE
Step 4 Restore product application software on the Restore Product Application Software page.
1. Select the backup server.
2. Select the object product and click in the Node Information column.
3. Select the node whose product application software is to be restored.
4. Click Restore.
5. In the displayed Warning dialog box, click OK.
The system has created a task successfully. Click Task Information List to view the
task execution status. If the task execution fails, rectify the failure based on detailed
information about the task.
6. Start the restored product application software. For details, see section 6.2 How Do I
Start a Service?.
----End
Follow-up Procedure
1. Restore a service instance data. For details, see 3.1 Restoring Dynamic Data.
2. Start the service. For details, see section 6.2 How Do I Start a Service?.
3.3 Restoring Database Software

This section describes how to restore database software through CloudOpera Orchestrator
SDN.

Prerequisites
l Database software, product application software, and service instance data have been
backed up.
l Service Instances are in the stopped. For details, see section 5.3-Stoping a Service.
l Database services are in the stopped. For details, see section 6.5 Stopping a DB
Instance.
Procedure
Step 1 Log in to the management plane of CloudOpera Orchestrator SDN.
1. Open a web browser, input https://IP address:31943 in the address box and press Enter.
– In a two-node cluster, replace IP address with the floating IP address of the primary
and secondary management nodes.
– In a single node system, replace IP address with the IP address of the management
node.
2. Input the user name admin and password on the login page, and click Log In.
Step 4 Choose Backup and Restore > Restore Data > Restore Database Software from the main
menu.
NOTE
Step 5 On the Restore Database Software page, select the backup server.
Step 6 Select the product to be restored and click in the Detail Information column.
Step 7 Select the node whose database application is to be restored.
Step 8 Click Restore.
Step 9 In the displayed Warning dialog box, click OK.

----End

Follow-up Procedure
1. Start the database service. For details, see section 6.4 Starting a DB Instance.
2. Start the restored service instances. For details, see section 5.2-Start a Service.
3. Restore the service instance data. For details, see section 4.1-Restoring Service
Instance Data.
3.4 Restoring OS Data

If the OS upgrade or patch installation fails and the OS cannot start, you can use the backup
data to restore the OS to the state before the upgrade or patch installation.
3.4.1 Restoring Service Node OS Data

If you cannot log in to a service node (a non-management node except eSight) because the OS
of the service node is damaged, perform the following operations to resolve the problem:
Prerequisites
The OS data, database software, product application software, and service instances data have
been backed up.
Procedure
Step 1 Choose Backup and Restore > Restore Data > Restore Operating System from the main
menu.
NOTE
Step 2 On the Restore Operating System page, select the backup server. For details about how to
select nodes or service instances, see 6.6 Selecting One or Multiple Backup Objects.
Step 3 Select the object node and select the backup file in the Backup File column. Then click
Restore.
Step 4 In the select restore mode and continue dialog, select a restoration mode based on the
virtualization scenario and box, click OK.
l If the VM on which the service node is deployed is created in the FusionSphere
OpenStack+KVM scenario, select ISO.
l If the VM on which the service node is deployed is created in the VMWare,
FusionCompute, or OpenStack+FusionCompute scenario, select PXE.

Step 5 In the displayed Warning box, select Are you sure you have finished configuring and
starting VMs? and click OK.
The system has created a task successfully. In the displayed Prompt dialog box, click Task
Information List to view the task execution result.
NOTICE
After the task is created, wait about 10 minutes. The system will report the task execution
progress in Task Information List. When the task execution progress is displayed as 1% in
Task Information List, you can proceed with the next step.
Step 6 Set the VM startup mode based on the OS restoration mode.
Restoration Procedure
Mode
NOTE
You have
selected ISO in If there are primary and secondary management nodes, the ISO image file of the
OS exists only on one of the management nodes. Log in to any one of the
Step 4.
management nodes to check whether the ISO file exists. If the file does not exist,
log in to the other management node. In the following part, operations on
management nodes only need to be performed on the management node which
contains the ISO file.
1. Use FileZilla to log in to the management node as the ossadm user.
2. Obtain the generated ISO image file of the OS, for example,
restoreos_20171201162234.iso, from the /opt/oss/manager/agent/
BackupService/tools/q_deployer/tftpboot/pxelinux.cfg/ directory.
3. Contact the lab O&M personnel to upload the ISO file to the server on
which the node with the OS to be restored is deployed.
4. Contact the lab O&M personnel to set the VM to boot from a CD-
ROM drive in the virtualization management software in use (for
example, vCenter or FusionManager).
5. Log in to the management node through the VNC console in the
virtualization management software, and choose Restore OS.
The OS restoration task will continue. Otherwise, the restoration task
will be canceled two hours later.
6. After the OS is restored, go to Step 7.

Restoration Procedure
Mode
NOTICE
You have
selected PXE in The DHCP service is started on the maintenance network of the CloudOpera
Orchestrator SDN when you restore OS data. Ensure that there is no MAC-
Step 4.
restricted DHCP server in the maintenance network plane. Otherwise, the boot
process of the OS restoration will be affected, causing the OS restoration failure.
1. Contact the lab O&M personnel to set the VM to boot from the
network.
The OS restoration task will continue. Otherwise, the restoration task
will be canceled two hours later.
2. After the OS is restored, go to Step 7.
Step 7 Use PuTTY to log in to the node with the OS restored as the ossadm user.
l If you can successfully log in to the node, the node is normal. In this case, go to Step 8.
l If the login fails or no response is returned, the node is abnormal. In this case, go to Step
8 and contact Huawei technical support.
Step 8 Contact the lab O&M personnel to set the VM to boot from a boot disk.
----End
Follow-up Procedure
1. Restore database software. For details, see 3.3 Restoring Database Software.
2. Restore product application software. For details, see 3.2 Restoring Product
Application Software.
3. Restore service instances data. For details, see 3.1 Restoring Dynamic Data.
3.4.2 Restoring Management Node OS Data

If the OS file is damaged and the management node OS cannot be logged in to, you need to
perform the following operations to restore the OS of the management node.
Prerequisites
The DHCP service is started on the maintenance network of the CloudOpera Orchestrator
SDN when you restore OS data.
NOTE
When restoring the OS data, ensure that there is no MAC-restricted DHCP server in the maintenance
network plane. Otherwise, the boot process of the OS restoration will be affected, causing the OS
restoration failure.
Procedure
Step 1 Use PuTTY to log in to the faulty node as user sopuser
l If you can successfully log in to the faulty node, go to Step 2.
l If you cannot log in to the faulty node, go to Step 4.

Step 2 Run the following command to check whether the network connection is normal.
su - sopuser
Ping management plane IP address
Ensure that the network connection is normal. If it is abnormal, contact the network
administrator.
Step 3 Contact the IT administrator to check whether the VM of the management node is normally
running. Ensure that the VM of the management node is not powered off or is not deleted.
If the VM is running normally, go to Step 4.
Step 4 Log in to any non-management node in the same area as the management plane as the
sopuser user.
Step 5 Run the following commands to restore the OS of the management plane:
su - ossadm
cd /opt/oss/manager/agent/BackupService/tools/backuprestore/restoreOS
./restoreManagerOS.sh
Step 6 Enter the following in sequence: the IP address of the faulty management node, the IP address
of the node you have logged in to, the IP address of the remote SFTP backup server, backup
path, and the user name and password of the backup server. Then press Enter.
Please enter manager ip:10.10.10.1
Please enter local machine ip:10.10.10.3
Please enter backup server ip:10.10.10.2
Please enter backup file path:bin/management/static/
20170713174525181/10.10.10.1/OS/20170713174525181.tar.gz
Please enter backup server username:sopuser
Please enter backup server passwd:
Please enter manager ip IP address of the faulty management node.
Please enter local machine IP address of the node that you have logged in to.
ip
Please enter backup server IP address of the remote SFTP backup server.
ip NOTE
The value of this parameter must be the same as the value set in
Setting Global Backup Parameters for backup and restoration.

Please enter backup file Backup path of the OS files of the management plane.
path The format of the backup path is as follows:
Path configured during global parameter setting/
management/static/Timestamp/IP address of the management
node to be restored/OS/Backup file to be restored
For example, if the path is set to bin during global parameter
setting, then the backup path is bin/management/static/
20170713174525181/10.10.10.1/OS/
20170713174525181.tar.gz.
In this path:
management/static/20170713174525181/10.10.10.1/OS/
20170713174525181.tar.gz is the specific file backup path,
and the actual path prevails.
Please enter backup server Username for logging in to the server.

username NOTE
Please enter backup server Password for logging in to the server.

passwd NOTE
Step 7 When the following information is displayed, enter the mode for restoring the OS of the
management node:
Which restoration mode do you want? [ISO/PXE]:
l If the VM is created in the OpenStack+KVM scenario, enter ISO and press Enter.
l If the VM is created in the VMWare, FusionCompute, or OpenStack+FusionCompute
scenario, enter PXE and press Enter.
The following information is displayed:
Are you sure you have finished configuring and starting VMs? [y/n]:
Step 8 Perform operations based on the configured OS restoration mode.

Configured Procedure
Restoration
Mode
You have entered 1. Use FileZilla to log in to the non-management node in Step 4 as the
ISO in Step 7. ossadm user.
2. Obtain the generated ISO image file of the OS, for example,
restoreos_20171201162234.iso, from the /opt/oss/manager/agent/
BackupService/tools/q_deployer/tftpboot/pxelinux.cfg/directory.
3. Contact the lab O&M personnel to upload the ISO file to the server
on which the management node with the OS to be restored is
deployed.
4. Contact the lab O&M personnel to set the VM to boot from a CD-
ROM drive in the virtualization management software in use (for
example, vCenter or FusionManager).
5. Log in to the management node through the VNC console in the
virtualization management software, and choose Restore OS.
6. Go to Step 9.
NOTICE
You have entered
PXE in Step 7. The DHCP service is started on the any one a non-management which is in the
same area with management plane of the when you restore OS data. Ensure that
there is no MAC-restricted DHCP server in the maintenance network plane.
Otherwise, the boot process of the OS restoration will be affected, causing the OS
restoration failure.
1. Contact the lab O&M personnel to set the VM to boot from the
network.
2. Go to Step 9.
Step 9 Enter y in the command output in Step 7 and press Enter.

If the following information is displayed, the OS of the management node is restored
successfully:
Exec restoreManagerOS.sh successfully.
Step 10 Use PuTTY to log in to the node with the OS restored as the ossadm user.
l If you can successfully log in to the node, the node is normal. In this case, go to Step 11.
l If the login fails or no response is returned, the node is abnormal. In this case, go to Step
11 and contact Huawei technical support.
Step 11 Contact the lab O&M personnel to set the VM to boot from a boot disk.
----End
3.5 Restoring Management Plane

If the management plane cannot be accessed normally due to management service or
management-plane database errors, restore the management plane by performing the
following operations.

Prerequisites
l The management plane has been backed up.
l You have contacted Huawei technical support to obtain the third-party integrity check
tool package BKSigntool_1.0.1_SLES_x86_64.tar.gz.
l Log in to the management plane of CloudOpera Orchestrator SDN. The OS of the
management node is running properly. If the OS of the management node is faulty, refer
to 3.4.2 Restoring Management Node OS Data to rectify the fault.
l You have obtained the passwords of user ossadm and user root.
Procedure
NOTICE
you need to perform Step 1 to Step 3 on the primary and secondary management nodes.
Step 1 Synchronize the backup data packages of the backup server to the management node to be
restored.
1. Use FileZilla to log in to the backup server.
NOTE
For the user name and password, see 2.1 Setting Global Backup Parameters.
2. Obtain the management-plane backup data packages management.tar.gz and
management.tar.gz.sign from the backup file directory of the backup server.
NOTE
The backup file path is Root directory of the backup server/Globalparameter configuration path/
management/management/Timestamp/IPaddress of the management node to be restored.
3. Use PuTTY to log in to the primary management node as the sopuser user and run the
following command to change to the root user.
su - root
Password:
4. Run the following command to create the /opt/backupManagement directory:

mkdir -p /opt/backupManagement
5. Use FileZilla to log in to the management node to be restored as the sopuser user.
6. Upload the backup data packages and files obtained in step Step 1.2 to the /tmp
directory of the to-be-restored management node.
NOTE
If OS security hardening is performed, upload the backup data packages and files with reference to
7.5 How to Upload Files to a Specified Directory After OS Security Hardening Is Performed.
7. Use PuTTY to log in to the primary management node on site B as the sopuser user, run
the following command to change to the root user.
su - root
Password:
8. Run the following command to copy the backup data packages and files obtained in step
Step 1.2 and the third-party integrity check tool package

BKSigntool_1.0.1_SLES_x86_64.tar.gz to the /opt/backupManagement directory of

the to-be-restored management node.
mv /tmp/management.tar.gz /opt/backupManagement
mv /tmp/management.tar.gz.sign /opt/backupManagement
mv /tmp/BKSigntool_1.0.1_SLES_x86_64.tar.gz /opt/backupManagement
Step 2 Run the following commands to check the integrity of the backup data package:
cd /opt/backupManagement
gunzip BKSigntool_1.0.1_SLES_x86_64.tar.gz
tar -xvf BKSigntool_1.0.1_SLES_x86_64.tar
cd /opt/backupManagement/BKSigntool
bash bksigntool.sh -input /opt/backupManagement/management.tar.gz
l If the following information is displayed, the check succeeds. You can restore the
management plane.
The backup data package is successfully verified and can be used for
restoration.
l If the following information is displayed, the check fails. In this case, contact Huawei
technical support.
The backup data package verification failed. The backup data package may have
been tampered with. You are not advised to use the data package for
restoration.
Step 3 Restore the management plane.

1. Use PuTTY to log in to the primary management node as the sopuser user, run the
following command to change to the root user.
su - root
Password:
2. Run the following commands to decompress the software package:

cd /opt/backupManagement
tar -xvf management.tar.gz
3. Run the following command to restore the management plane:
bash /opt/backupManagement/restoreManagement.sh
– If the following information is displayed, the command is successfully executed.
Restore management successfully.
– If the following information is displayed, the command execution fails. Contact

Huawei technical support engineers.
Please check if the dbInstance status is ok, if its not ok, please
recovery the dbInstance first, and then try to start management.
n If the management-plane database instance statuses are normal, it indicates

that the management-plane service startup failure is not caused by abnormal
management-plane database instance. Contact Huawei technical support for
troubleshooting assistance.
n If the management-plane database instance statuses are abnormal, restore the
database by referring to "Database Restoration" in CloudOpera Orchestrator
SDN Troubleshooting. After the management-plane database is restored,
manually start all microservices of the management-plane service. Run the
bash ipmc_adm -cmd statusapp -tenant manager command to view all

management plane microservices on the current node. then see "Starting a

Micro Service" in CloudOpera Orchestrator SDN Maintenance Guide to start
all microservices.
1. Open a web browser, input https://IP address:31943 in the address box and press Enter.
– In a two-node cluster, replace IP address with the floating IP address of the primary
and secondary management nodes.
– In a single node system, replace IP address with the IP address of the management
node.
Step 5 If the management plane can be accessed normally, the management plane is successfully
restored. Otherwise, contact Huawei technical support engineers.
----End
Follow-up Procedure
After the management plane is successfully restored, you must clear backup data packages in
the directory to reduce disk space occupation.
1. Use PuTTY to log in to the primary management node on site B as the ossadm user, run
su - root
Password:
2. Run the following command to clear the /opt/backupManagement directory:

rm -rf /opt/backupManagement

Backup and Restoration Guide 4 Remote Cold Backup and Restoration
4 Remote Cold Backup and Restoration
The management-plane dynamic backup data of site A can be restored on site B through
CloudOpera Orchestrator SDN. In this manner, site B becomes the mirror site of site A.
NOTE
The following takes sites A and B as an example to describe how to remotely restore the management
plane.
Site A: Service data on site A is damaged due to incidents such as fire or power failure. The site is
running improperly.
Site B: The running status of site B is normal. After backup data on site A is restored on site B, site B
becomes a backup site of site A.
Prerequisites
l Products, regions, planes, and services on sites A and B are the same.
l The site that provides backup data is running properly.
l Trust relationship has been built at sites A and B.
l Data has been synchronized at sites A and B.
l The dynamic backup data and management plane of site A have been backed up, and the
management plane backup is later than the dynamic data backup.
Context
After product installation is completed on sites A and B, the two sites have established a trust
relationship and synchronized data between them.
Procedure
Step 1 Synchronize the backup files and dynamic data of site A to site B.
1. Use FileZilla to log in to the backup server on site A as the backup server user.
NOTE
For the user name and password, see Setting Backup Server Parameters.
2. Obtain the management-plane backup data packages management.tar.gz and
management.tar.gz.sgin from the backup path of the backup server on site A.

Table 4-1 Backup file path

Backup File Path
management.tar.gz The backup file path is Root directory of

the backup server/Global parameter
configuration path/management/
management/Timestamp/IP address of
the active management node of site A.
For example, the login user of the backup
server is ossadm, the directory is /home/
ossadm/bin/management/management/
20170829002834588/10.10.10.8
management.tar.gz.sgin The path is the same as that of

management.tar.gz.
All files in the Root directory of the The backup file path is Root directory of
backup server/Global parameter the backup server/Global parameter
configuration path/Product name/ configuration path/Product name/
dynamic/ directory dynamic/
For example, the login user of the backup
server is ossadm, the directory is /home/
ossadm/bin/product/dynamic.
3. Use FileZilla to log in to the backup server of site B as the backup server user. Copy all
files in the Root directory of the backup server/Global parameter configuration path/
Product name/dynamic/ directory on site A to the same directory on site B.
NOTE
– For the user name and password, see Setting Backup Server Parameters.
– Ensure that the user who logs in to the backup server of site B has permission to access to the
copied files.
4. Use PuTTY to log in to the primary management node on site B as the sopuser user, run
su - root
Password:
5. Run the following command to create the /opt/remoteRecovery directory:

mkdir -p /opt/remoteRecovery
chown ossadm:ossgroup /opt/remoteRecovery
chmod 750 /opt/remoteRecovery
6. Use FileZilla to log in to the primary management node on site B as the ossadm user.
7. Upload the management.tar.gz and management.tar.gz.sgin backup data packages
obtained in Step 1.2 to the /opt/remoteRecovery directory of the primary management
node on site B.
NOTE
If OS security hardening is performed, upload files with reference to 7.5 How to Upload Files to
a Specified Directory After OS Security Hardening Is Performed. Then run the following
commands to change the directory owner and permission:
chown ossadm:ossgroup /opt/remoteRecovery/management.tar.gz*

Step 2 Perform remote restoration.

1. Use PuTTY to log in to the primary management node on site B as the ossadm user.
2. Run the following commands to decompress the software package:
cd /opt/remoteRecovery
tar -xvf management.tar.gz
3. Run the following commands to configure the input.json file:
cd /opt/remoteRecovery
vi input.json
The vi editor is opened by running the preceding commands. Press i and enter the
following information by referring to Table 4-2.
[
{
"region_name": {
"old_region": "cn-global-0",
"new_region": "cn-global-1"
},
"product": "Product",
"bss_list": [
{
"transmisson_mode": "sftp",
"old_bss": {
"ip": "10.67.197.116",
"username": "root",
"backup_path": "backupdata"
},
"new_bss": {
"ip": "10.67.197.116",
"username": "root",
"backup_path": "backupdata88"
}
}
],
"regionAlias":
{
"old_regionAlias":"SIG",
"new_regionAlias":"TLF"
},
"node_list": [
{
"old_ip": "10.22.34.183",
"new_ip": "10.93.39.51"
},
{
"old_ip": "10.22.35.48",
"new_ip": "10.93.39.170"
},
{
"old_ip": "10.22.20.246",
"new_ip": "10.64.173.95"
},
{
"old_ip": "10.22.21.218",
"new_ip": "10.64.173.87"
},
{
"old_ip": "10.167.210.233",
"new_ip": "10.176.192.160"
},
{
"old_ip": "10.167.210.234",
"new_ip": "10.176.192.161"
},
{

"old_ip": "10.167.210.235",
"new_ip": "10.176.192.162"
},
{
"old_ip": "10.167.210.236",
"new_ip": "10.176.192.163"
}
]
}
]
After the modification, press Esc, and enter :wq! to save the configuration file and exit
the vi editor.
Table 4-2 Parameter description
Parameter Example Description
region cn-single-1 Indicates the region name.
product Product Indicates the product.
zone service Indicates the plane.
transmissonmode sftp Indicates the transmission mode.
bsslist oldBS ip 10.10.10.11 Indicates the IP address of the backup

S server on site A.
usernam root Indicates the user name used for logging

e in to the backup server on site A.
backupp bin Indicates the backup path configured

ath when global parameters are set for the
backup server on site A.
newBSS Same as Indicates parameters of the backup server

oldBSS on site B.
NOTE
One backup server on site A maps multiple
backup servers on site B.
nodeli oldIP 10.10.10.13 Indicates the IP address of the node on

st site A.
oldIP and newIP indicate the IP
addresses of the nodes with the same
name on site A and site B, respectively.
oldIP and newIP are configured in pairs.
The number of pairs is consistent with
the number of nodes on site A or site B.
newIP 10.10.10.14 Indicates the IP address of the node on

site B.
4. Run the following commands to modify the permission of the input.json file:
chmod 600 /opt/remoteRecovery/input.json
chown ossadm:ossgroup /opt/remoteRecovery/input.json

5. Run the following command to perform remote restoration as the ossadm user:
bash /opt/remoteRecovery/restoreData.sh input.json
6. When the following information is displayed, determine whether to configure the SFTP
fingerprint authentication between the primary management node of site B and the
backup server of site A.
Are you sure to continue [Default:n]? [y/n]:
– If you want to configure the SFTP fingerprint authentication, input y and press
Enter.
If the following information is displayed, the command is successfully executed.
Otherwise, contact Huawei technical support engineers.
Execution successful.
– If you do not want to configure the SFTP fingerprint authentication, input n and
press Enter. The command execution fails, restoration aborts.
Step 3 View the restoration result.

1. Start your browser, enter https://Management-plane IP address of CloudOpera
Orchestrator SDN:31943 in the address box, and press Enter.
NOTE
In a two-node cluster, replace IP address with the floating IP address of the primary and secondary
management nodes.
2. Choose Backup and Restore > Manual Restoration > Restore Dynamic Data from
the main menu.
3. On the Restore Dynamic Data page, check whether the backup file on site B is the same
as that on site A in the Backup File column.
– If the file is the same, perform Step 3.4.
– If the file is not the same, contact Huawei technical support engineers.
4. Perform the restoration task and check whether the restoration task is executed
successfully. For details, see 3.1 Restoring Dynamic Data.
– If the task is successful, remote restoration is successful.
– If the task fails, contact Huawei technical support engineers.
----End
Follow-up Procedure
After the remote restoration is successful, you must clear backup data packages in the
directory to reduce disk space consumption.
1. Use PuTTY to log in to the primary management node on site B as the ossadm user, Run
the following command to switch to the root user:
su - root
Password:
2. Run the following command to clear the /opt/remoteRecovery directory:

rm -rf /opt/remoteRecovery

Backup and Restoration Guide 5 Remote Warm Backup and Restoration
5 Remote Warm Backup and Restoration
The remote DR system uses warm backup for data restoration.
5.1 Remote Disaster Recovery System Overview

This chapter describes the positioning, benefits, and networking scheme of the CloudOpera
Orchestrator SDN remote disaster recovery (DR) system.
5.2 Establishing a Remote DR System
5.3 Remote DR System Common Operations
This chapter describes maintenance operations related to the remote DR system, which
facilitates the management of the DR system.
5.4 Remote DR System Alarms
This chapter describes alarms related to the remote DR system and the troubleshooting
methods.
5.1 Remote Disaster Recovery System Overview

This chapter describes the positioning, benefits, and networking scheme of the CloudOpera
Orchestrator SDN remote disaster recovery (DR) system.
5.1.1 Positioning
The remote DR solution can effectively reduce losses caused by disastrous incidents and
further improve DR capabilities of the server to defend against various security risks.
In a remote DR system, two sets of CloudOpera Orchestrator SDN systems with the same
functions are established in two remote areas. One site is specified to provide services for
external systems. The other site is used to protect the site. When natural disasters such as fire,
flood, and earthquake occur, or hardware power failure, network exception, software and
hardware error, or manual operation error occurs on the site that provides services for external
systems, services on the site can be taken over by the other site quickly. This effectively
prevents data loss, data damage, and service interruption and ensures normal system running.
5.1.2 Benefits
This section describes the advantages of the remote DR solution.

The remote DR solution has the following features:
l Virtualization DR. DR for FusionSphere and VMware virtual machines (VMs) makes up
for the deficiency of virtualization platform DR in traditional DR solutions.
l Stability and reliability. The multi-instance service design is used. Each instance works
independently and is mutually backed up.
l Diversified data replication. Data replication can be configured for different types of
data. For example, you can customize data replication for the following types of data:
Massively Parallel Processing Database (MPPDB), Hadoop Distributed File System
(HDFS), MySQL, Catalog, ElasticSearch (ES), and Reliable High Message (RHM).
l Rapid service takeover. When the site that provides services for external systems is
faulty, the other site takes over services from the faulty site to continue providing
services, ensuring service continuity.
l Visualized operation interfaces. You can manage and maintain the remote DR system on
the web user interfaces. Compared with the command operation mode, the ease of use is
improved.
5.1.3 Solution Overview

Before installing CloudOpera Orchestrator SDN remote DR system, read this section to
understand the overall CloudOpera Orchestrator SDN remote DR system.
Remote DR solution can effectively reduce losses caused by disastrous incidents such as
earthquakes, fires, and power failures, and further improves DR capabilities of the server to
defend against various security risks.
CloudOpera Orchestrator SDN remote DR solution provides 1:1 DR capability. The solution
comprises two CloudOpera Orchestrator SDN systems: one serves as the primary site and the
other serves as the secondary site. The two sites are redundant for each other. When the
primary site is faulty, the secondary site takes over services from the primary site.
Figure 5-1 Networking diagram
Some common terms are described as follows to facilitate the installation of the CloudOpera
Orchestrator SDN remote DR system.

Primary Site Indicates the physical primary site. The primary site is determined during
the installation and will not change with the active/standby switchover. The
primary site is active at most time.
Secondary Site Indicates the physical secondary site. The secondary site is determined
during the installation and will not change with the active/standby
switchover. The secondary site is standby at most time and provides
protection for the primary site.
Active Site Indicates the site that provides services.
Standby Site Indicates the site that provides protection for the active site.
The remote DR system networking requirements and mechanism are as follows:
l The primary site and secondary site deployment schemes must be the same, that is,
certificates, number of nodes and the CloudOpera Orchestrator SDN version must be the
same.
l Internal communication and synchronous data replication between the OM planes of the
primary and secondary sites is performed through the physical link between layer-3
switches on the primary and secondary sites as marked by the yellow bidirectional lines
in networking diagram figure.
l If the primary site is faulty, you can manually switch the service data from the primary
site to the secondary site. After the primary site is recovered, manually switch the service
data from the secondary site to the primary site.
l The remote DR system uses remote replication as the data replication mode. Remote
replication requires SSL security communication such as VPN. The requirements for the
network bandwidth are as follows:
– The network between the two sites must meet the following requirements:
n Bandwidth >= Gigabit Ethernet (GE)
n Delay < 50 ms
n Packet loss rate < 0.1%
– Network redundancy switchover < 50 ms
5.2 Establishing a Remote DR System
5.2.1 Node Introduction

Before installing CloudOpera Orchestrator SDN, be familiar with nodes to be deployed on
CloudOpera Orchestrator SDN through node overview.
Figure 5-2 shows the node deployment plan of CloudOpera Orchestrator SDN.

NOTE
For information about the specifications of resources (vCPU, memory, and data disk) on CloudOpera
Orchestrator SDN nodes, see "VM Resources" section in the CloudOpera Orchestrator SDN Planning
Guide.
Figure 5-2 VM deployment
Table 5-1 provides the function descriptions of CloudOpera Orchestrator SDN VM nodes.
Table 5-1 VM nodes description

Node Name Description
<regionAlias>-OM-Global-Deploy01 Management nodes (service deployment

<regionAlias>-OM-Global-Deploy02 system)
The two management nodes use an active-
standby mechanism to ensure the reliability of
the service deployment system.
The service deployment system (web UI) is
used to manage server resources and deploy
services on specified servers. This system is
used in installation, restoration using data
backed up, and upgrade.

Node Name Description
<regionAlias>-OM-Global-Service01 Service nodes (O&M plane)

<regionAlias>-OM-Global-Service02 Two service nodes are deployed in a cluster
and provide the load balancing capability.
Users are provided with the O&M plane (web
UI) to perform one-stop operations such as
resource management, flexible service design,
and agile service provisioning. The O&M
plane is used in service management and
routine system maintenance.
<regionAlias>-OM-Global-DB01 Database nodes

<regionAlias>-OM-Global-DB02 The two database nodes use a master-slave
mechanism to ensure the reliability of the
database.
<regionAlias>-OM-Global-OM01 O&M nodes

<regionAlias>-OM-Global-OM02 Two O&M nodes are deployed in a cluster and
provide the load balancing capability.
O&M assurance services including alarm
monitoring, service monitoring, service
inspection, log analysis are provided.
5.2.2 Environment Requirements

This section describes the software and hardware configuration requirements for VMs and
clients, and network bandwidth requirements.
VM Configuration
Table 5-2 lists the software configuration requirements for the CloudOpera Orchestrator SDN
server.
Table 5-2 Configuration requirements for CloudOpera Orchestrator SDN VM software

Software Type Version Description
SUSE Linux SUSE Linux Enterprise SUSE Linux operating

Server 12 SP2 (64-bit) system (OS) used by
CloudOpera Orchestrator
SDN
MySQL 5.6.38 Relational database used by

SDN
Redis 3.0.7.8 Cache database used by

SDN

Client
Table 5-3 lists the software configuration requirements for the CloudOpera Orchestrator SDN
DR system clients.
Table 5-3 Configuration requirements for the CloudOpera Orchestrator SDN remote DR
system clients
Software Type Requirements
Browser l The recommended resolution is 1280 × 768 px or higher.

l Supported browser versions:
– Internet Explorer 10 or later
– Google Chrome 40 or later
– Mozilla Firefox 35 or later
OS Windows Server 2008, Windows 7, and later versions are

supported.
Table 5-4 lists the minimum hardware configuration requirements for CloudOpera
Orchestrator SDN clients.
Table 5-4 Minimum hardware configuration requirements for CloudOpera Orchestrator SDN
clients
Configuration Item Requirements
CPU 2.4 GHz
Hard disk space 320 GB
RAM 4 GB
Network adapter 100 Mbit/s
Other hardware 17 in monitor, DVD-ROM (optional), keyboard, mouse,

video card, sound card
Network Bandwidth
Table 5-5 lists the requirements for the network status based on various data replication
modes.

Table 5-5 Remote DR system network requirements

Data Replication Mode Requirements
Synchronous Replication l Data loss recovery point objective (RPO) ≤ 1 minute

l The network between the two sites must meet the
following requirements:
– Bandwidth ≥ Gigabit Ethernet (GE)
– Delay < 2 ms
– Packet loss rate < 0.1%
– Distance < 50 km
l Network redundancy switchover < 10 ms
Asynchronous Replication l Data loss RPO ≤ 10 minutes

l The network between the two sites must meet the
following requirements:
– Bandwidth ≥ Gigabit Ethernet (GE)
– Delay < 50 ms
– Packet loss rate < 0.1%
– Distance < 50 km
l Network redundancy switchover < 50 ms
5.2.3 Process Overview

The installation and commissioning processes help you understand the task execution
sequence and the required time.
Figure 5-3 shows the installation and commissioning processes of CloudOpera Orchestrator
SDN. The installation and commissioning processes for the primary site are the same as those
for the secondary site.

Figure 5-3 Installation and commissioning processes of CloudOpera Orchestrator SDN
Table 5-6 describes tasks in each phase during installation and commissioning of CloudOpera
Orchestrator SDN remote DR system.
Table 5-6 Process implementation

Task Description
Install the primary site. Install CloudOpera Orchestrator SDN on the primary and
secondary sites separately.
Install the secondary site.
NOTE
If CloudOpera Orchestrator SDN installed on the primary and
secondary sites is not the latest version, it needs to be upgraded.
For details, see the upgrade guide of the corresponding version.
Commission services at the Perform initial configuration including the interconnection

primary site. configuration, initial service configuration, system security
hardening, and health check at the primary site, to ensure
that CloudOpera Orchestrator SDN and basic service
functions of the primary site are working properly.
Back up data at the primary Back up data at the primary site so that data can be restored
site in case of a fault.
Create a DR relationship. Create a remote DR system between the primary and

secondary sites.

Task Description
Commission services of the Perform initial configuration including the interconnection

secondary site. configuration, initial service configuration, system security
hardening, and health check at the secondary site, to ensure
that CloudOpera Orchestrator SDN and basic service
functions of the secondary site are working properly.
There is no need to perform MySQL database hardening
and OS hardening of the secondary site, because they have
been completed during commissioning of services of the
primary site.
5.2.4 Installing the Primary and Secondary Site

This section describes how to install the active site and standby site.
Precautions
When Installing the active site and standby site, you have to write Region Name in the
planning tool. Region Values of Region Name at the active and standby sites must be
different.
NOTE
The naming rule of Region Name is as follows: Country name abbreviation-Region-No.-Letter. for
example, cn-global1-1-a.
Procedure
Step 1 Check whether the time of deploy node on the active site and standby site is correct and
consistent.
You are advised to run the date command to check the correctness and consistency. If the time
is inconsistent or incorrect, run the following command as the root user and change the OS
time of these VM node as prompted:
bash /usr/local/tools/maintain_tools/maintain_tools.sh
Step 2 Understand the planning and networking of active and standby site nodes. For details, see
section Networking Solution in CloudOpera Orchestrator SDN Installation and
Commissioning Guide.
Step 3 Install the active site and standby site. Perform operations in Table 5-7.
Table 5-7 Description of operations about installing the active site and standby site
Operation Reference Document
Creating a Virtualization Creating a Virtualization Environment in

Environment CloudOpera Orchestrator SDN V200R002C10
Installation and Commissioning Guide.

Operation Reference Document
Preparing for the Installation Preparing for the Installation in CloudOpera

Orchestrator SDN V200R002C10 Installation and
NOTICE
This step involves Region Name in the planning tool.
Values of Region Name at the active and standby sites must
be different.
Installing CloudOpera Installing CloudOpera Orchestrator SDN in

Orchestrator SDN CloudOpera Orchestrator SDN V200R002C10
Step 4 Verify the installation at the active and standby sites separately. For details, see section
Verifying the Installation in CloudOpera Orchestrator SDN V200R002C10 Installation and
Step 5 Apply for and load the applied license at the active and standby sites separately. For details,
see section Follow-up Operations in CloudOpera Orchestrator SDN V200R002C10
----End
Follow-up Procedure
After the active site and standby site are installed, perform the following procedure to copy
the CA certificate to the secondary management node:
NOTE
Perform the following steps at the active and standby sites separately:
Step 1 Use PuTTY to log in to the secondary management node as the sopuser user and switch to
the root user.
su - root
Step 2 Run the following commands to copy the CA certificate from the primary management node
to the secondary management node:
cd /opt/oss/manager/var/
scp IP address of the primary management node:/opt/oss/manager/var/ca/ca.cer ./
scp IP address of the primary management node:/opt/oss/manager/var/ca/ca_key.pem ./
Step 3 Run the following command to set the owner of the CA certificate of the secondary
management node:
chown -R ossadm:ossgroup ca/
Step 4 Run the following commands to check whether the ca.cer and ca_key.pem files exist:
cd /opt/oss/manager/var/ca/
ll

l If the files exist, no further action is required.

l If the files do not exist, contact Huawei technical support engineers.
----End
5.2.5 Configuring Services of the Primary Site

After installing the active site successfully, log in to the OM plane of the active site to
commission related services.
Procedure
Step 1 Open a web browser, input https://Floating IP address of the management node of the
primary site:31943 in the address box, input the user name admin and password, and press
Enter.
Step 2 Commission services at the active site. For details, see section Interconnecting with
External Systems (TSDN) and Interconnecting with External Systems (IP WAN) in
CloudOpera Orchestrator SDN V200R002C10 Installation and Commissioning Guide.
----End
5.2.6 Security Hardening

The default configurations of the OS and databases do not meet the security requirements of
the telecommunications management system. To ensure the security of the OS, databases, and
CloudOpera Orchestrator SDN, perform security hardening for the OS, and install antivirus
software as recommended.
5.2.6.1 Overview
This section describes the purpose, impact, and precautions of performing security hardening
on CloudOpera Orchestrator SDN.
Purpose
Security hardening aims to defend the OS and database from hacker and virus attacks,
improving the system and network security.
l The default configurations of the SUSE Linux OS usually do not meet security
requirements of the telecommunications management system.
The default configurations include but are not limited to the following items:
– Redundant services are installed and running.
– Weak passwords and anonymous access are configured.
– Unnecessary external communication ports are opened.
– Vulnerable Transmission Control Protocol/Internet Protocol (TCP/IP) parameters
are set.
Therefore, OSs are a weakness in daily operation and management. To ensure secure and
stable OS operation, you are advised to perform security hardening for the OS on
servers.
l Databases have security risks.

For example, the database provides default accounts and shared accounts and uses
simple login passwords, increasing the probabilities of being attacked. Therefore, you
need to harden the database to enhance its resistance to threats.
l Antivirus software must be deployed to defend from virus attacks.
Antivirus software protects the system and network by defending them against malware
and network risks.
Impact
l For OS: Some OS parameters and user rights will be adjusted after the security
hardening.
l For database: If the MySQL database is used, database services may be unavailable
during security hardening. Perform security hardening at a proper time.
Precautions
l Precautions before security hardening include:
– Ensure that the power supply is uninterrupted during security hardening.
– If any operation fails or any error occurs during security hardening, contact Huawei
technical support engineers.
l To securely use the Redis database, comply with the following requirements:
– Redis databases must be deployed on independent nodes.
– After the installation and deployment are complete on the live network, you must
change the password for the database administrator.
– Do not use redis-cli to connect to the database on the live network.
– When you connect to the database using redis-cli, do not enter a password in
commands. The interaction method is recommended.
l You are advised to use the certificates applied from a CA to replace the default ER
certificates. To reduce the risk of being cracked, replace certificates periodically. For
details, see CloudOpera Orchestrator SDN Maintenance Guide of the corresponding
version.
5.2.6.2 Uploading Node Data Files and Tools

This section describes how to upload node data files and the batch processing tool to the
management node. They can be used in future installation such as VM data disk initialization
and batch node initialization.
Prerequisites
l Node data files have been generated by the planning tool in the data planning tool
package. For details, see section Generating the Plan Data in CloudOpera Orchestrator
SDN V200R002C10 Installation and Commissioning Guide.
l 7-Zip has been installed on the PC.
Procedure
Step 1 Decompress the remote batch processing tool package
CloudOpera_Orchestrator_RemoteTool_x.x.x_SLES_Linux.7z to PC with the 7-Zip
software.

After the package is decompressed, the following files become available.
l Batch processing tool package: CloudOpera_DeploySystem_SLES_Linux.zip

l Digital certificate file: CloudOpera_DeploySystem_SLES_Linux.zip.asc
Step 2 Use FileZilla to upload the following files to the /usr/local/tools directory on the primary
management node as the root user:
l Batch processing tool package: CloudOpera_DeploySystem_SLES_Linux.zip
l Digital certificate file: CloudOpera_DeploySystem_SLES_Linux.zip.asc
Step 3 Use PuTTY to log in to the primary management node as the root user.
Step 4 Run the following commands to verify the integrity of the batch processing tool package:
cd /usr/local/tools
[ -d /usr/local/tools/CloudOpera_DeploySystem_SLES_Linux ] && rm -rf /usr/local/tools/

CloudOpera_DeploySystem_SLES_Linux
gpg --verify CloudOpera_DeploySystem_SLES_Linux.zip.asc
The tool package is integral if the following information is displayed. Otherwise, contact
gpg: Good signature from "OpenPGP signature key for Huawei software (created on
30th Dec,2013) <[email protected]>"[ultimate]
Step 5 Run the following command to decompress the batch processing tool package to the
CloudOpera_DeploySystem_SLES_Linux directory:
unzip CloudOpera_DeploySystem_SLES_Linux.zip -d
CloudOpera_DeploySystem_SLES_Linux
Step 6 Run the following command to create the directory to stored node data files. The directory
name is the value of Region Name which is setted when CloudOpera Orchestrator SDN is
installed.
mkdir -p /usr/local/tools/CloudOpera_DeploySystem_SLES_Linux/cn-global-1-a
Step 7 Use FileZilla to upload the node data files in .csv format to the /usr/local/tools/
CloudOpera_DeploySystem_SLES_Linux/cn-global-1-a directory on the primary
management node as the root user:
NOTE
Node data files in .csv format are the ones generated in Generating the Plan Data in CloudOpera
Orchestrator SDN V200R002C10 Installation and Commissioning Guide.
Step 8 On the primary management node, run the following commands to specify the regions to be
initialized as the root user.
cd /usr/local/tools/CloudOpera_DeploySystem_SLES_Linux
bash designateRegion.sh

Please input the region:
Step 9 Input the region name, that is the value of Region Name which is set when CloudOpera
Orchestrator SDN is installed, for example, cn-global-1-a, and press Enter.

NOTE
If the input information is incorrect, press Ctrl+Backspace to delete the incorrect information. This
method can also be used to delete incorrect input information when .sh scripts are executed.
The configuration is successful if the following information is displayed. Otherwise, contact

Designate Region cn-global-1-a successfully.
----End
5.2.6.3 MySQL Database Hardening

You can set a whitelist for the active and standby sites to control access to the host, reducing
the risk of an attack. The following describes how to perform hardening on the databases of
the active and standby sites both.
Prerequisites
l The passwords for the sopuser and root users are the same on all nodes respectively, the
password is available, and the sopuser, root and ossadm users can use the password to
remotely log in to all the nodes.
l Ensure that the allNodes.csv file exists in the /usr/local/tools/
CloudOpera_DeploySystem_SLES_Linux/cn-global-1-a directory on the primary
management node of the active and standby sites and the file contents are consistent with
the actual network plan.
Context
To ensure the security of CloudOpera Orchestrator SDN, security hardening must be
performed on the database. Some database items are automatically hardened during the
installation of the database on VMs. For details, see section 7.4 MySQL Database Security
Hardening Items.
Procedure
Step 1 Check the database status.
1. Open a web browser, input https://Floating IP address of the CloudOpera Orchestrator
SDN management node of the active site:31943 in the address box and press Enter.
3. Choose Deployment > Database > RDBMS from the main menu.
4. Check whether the status of all database instances is normal.
– The database status is normal if the Instance Type and Status relationship is as
follows. Perform Step 2.
n When Instance Type is primary, the status is .

n When Instance Type is single, the status is --.
– If the database status is , restore the database. For details, see "Database Fault" in
CloudOpera Orchestrator SDN Troubleshooting and perform Step 2.
Step 2 Obtain the .json configuration file of the active and standby sites.

1. Use PuTTY to log in to the primary management node of the active site as the sopuser.
2. Run the following command to switch to the root user:
su - root
3. Run the following command to run the database hardening scripts:
bash hardenDBDRBase.sh
Are you sure you want to continue(y/n):
4. Input y and press Enter.

Input the default password of ossadm for all hosts:
5. Input the password for the ossadm and press Enter.

Input the opreation[getacl/setacl]:
NOTE
The default password of user ossadm is ZJE%JLq5qx.

6. Input getacl to generate the .json configuration file for the site.
7. Use PuTTY to log in to the primary management node of the standby site as the sopuser.
8. Perform Step 2.2 to Step 2.6 to generate the .json configuration file for the standby site.
Step 3 Download the .json configuration file of the active and standby sites to a local PC.
1. Use FileZilla to log in to the primary management node of the active site as the root
user.
2. Download the dbInfoMap-IP address of the primary management node oftheactivey
site.json configuration file in the /usr/local/tools/
CloudOpera_DeploySystem_SLES_Linux/harden/ directory to a local PC.
3. Use FileZilla to log in to the primary management node of the standby site as the root
user.
4. Download the dbInfoMap-IP address of the active management node of the standby
site.json configuration file in the /usr/local/tools/
CloudOpera_DeploySystem_SLES_Linux/harden/ directory to a local PC.
Step 4 Upload the .json configuration files of the active and standby sites that have saved locally to
the peer sites respectively.
1. Use FileZilla to log in to the primary management node of the active site as the root
user.
2. Upload the dbInfoMap-IP address of the active management node of the standby
site.json to the /usr/local/tools/CloudOpera_DeploySystem_SLES_Linux/harden/
directory to the primary management node of theactivey site.
3. Use FileZilla to log in to the primary management node of the standby site as the root
user.
4. Upload the dbInfoMap-IP address of theprimary management node of the active
site.json to the /usr/local/tools/CloudOpera_DeploySystem_SLES_Linux/ directory to
the primary management node of the standby site.
Step 5 Harden the MySQL database on the active and standby sites.

2. Run the following command to switch to the root user.
su - root
3. Run the following command to execute the database hardening scripts:
bash hardenDBDRBase.sh

Input the default password of ossadm for all hosts:
5. Input the password for the ossadm and press Enter.

Input the opreation[getacl/setacl]:
NOTE
The default password of user ossadm is ZJE%JLq5qx.

6. Input setacl to harden the database.

NOTE
It takes 5 to 10 minutes to perform harden the database.

Check the node execution condition.
– If the value of Failed Hosts Count is 0 in the command output, the security
hardening is successful.
– If the value of Failed Hosts Count is not 0 in the command output, security
hardening has failed on some nodes. The Failed Hosts row displays the IP
addresses of nodes on which security hardening failed. Contact Huawei technical
support for troubleshooting.
9. Perform Step 5.2 to Step 5.7 to harden the database on the standby site.
----End
5.2.6.4 Remote SSH Security Hardening

Basic OS security hardening for VMs is performed by default. This section describes how to
perform security hardening the second time to reduce security risks and improve the anti-
attack capability of the OS, and how to create the ftpuser on the primary and secondary
management node for remote file transfer.
Prerequisites
l The password for the root user is the same on all nodes, the password is available, and
the root user can use the password to log in to all the nodes.

l The .csv node data files and remote batch processing tool have been uploaded to the
primary management node. For details, see 5.2.6.2 Uploading Node Data Files and
Tools.
Context
To ensure the security of CloudOpera Orchestrator SDN, security hardening must be
performed for the OS. For details about all the OS items to be hardened, see section 5.2.6.5
OS Port Hardening.
You can perform this task using the remote batch processing tool package, which can be used
to verify the environment of multiple VMs simultaneously. The file used in this task has been
generated during the installation of CloudOpera Orchestrator SDN.
NOTICE
l After remote SSH security hardening is enforced, you cannot log in to the server as the
root user. Therefore, log in as the sopuser user and switch to the root user to perform
operations.
l After remote SSH security hardening is enforced, you cannot use the root user to upload
files to a specified directory on the server using FileZilla. Instead, you must use the
ftpuser user to upload the files to the /opt/pub/upload/ftproot directory using FileZilla,
and use the root user to copy files from the /opt/pub/upload/ftproot directory to the
specified directory.
Procedure
Step 1 Set the ftpuse user password based on the password complexity requirements in Step 5. Log
in to the primary management node as the root user and run the following command to check
whether the password meets the OS requirements:
echo "ftpuser user password" | cracklib-check
l If OK is displayed, the password meets the OS requirements.
ftpuser user password: OK
l If other information is displayed, the password does not meet the OS requirements. Set
and check the password again.
ftpuser user password: it is based on a dictionary word
Step 2 Log in the primary management node as the root user, and run the following commands to
remote SSH security hardening:
bash hardenSSH.sh
Step 3 Enter y and press Enter when prompted as follows:
Step 4 Enter the password for the root user and press Enter when prompted as follows:
Input the default password for all hosts:
Step 5 Enter the password for the ftpuser by following the password complexity requirements, and
press Enter when prompted as follows:

Input a user-defined password for ftpuser:
To improve security of users' passwords, set passwords based on the following rules:
l Cannot contain the user name or the user name in reverse order.
l Contain 8 to 32 characters.
l Cannot contain over 2 consecutive occurrences of a character or string.
l Contain at least one uppercase letter (A to Z), one lowercase letter (a to z), and one digit
(0 to 9).
l Contain at least one special character such as ~@#^*-_+[{}]:./?%=
l Cannot be the same as the recent twelve passwords.
l Cannot be changed at an interval less than 7 days.
Step 6 Enter the password for the ftpuser again and press Enter when prompted as follows:
Comfirm the password for ftpuser:
l The Successful Hosts row displays the IP addresses of nodes on which operations
succeeded.
l The Failed Hosts row displays the IP addresses of nodes on which operations failed.
Contact Huawei technical support engineers for to troubleshoot the problem.
----End
5.2.6.5 OS Port Hardening

OS hardening can improve product security.
Prerequisites
l The SSH client version requirements are met: Xshell 5 or later and PuTTY 0.68 or later.
l You have obtained OS security hardening package
CloudOpera_OSHardening_SLES_x86_64.zip and its signature file. For details, see
Obtaining and Verifying Software Packages in CloudOpera Orchestrator SDN
V200R002C10 Installation and Commissioning Guide.
Context
Perform the following steps on all CloudOpera Orchestrator SDN nodes.
Procedure
Step 1 Upload the OS security hardening package and its signature file to all nodes of active site
separately.
1. Upload the security hardening package and its signature file to the /opt/pub/upload/
ftproot directory on the primary management node and secondary management node of
active site by using FileZilla as the ftpuser. Use the password of the ftpuser user that is
configured in performing 5.2.6.4 Remote SSH Security Hardening.

NOTE
– The primary management node and the secondary management node refer to <regionAlias>-
OM-Global-Deploy01 and <regionAlias>-OM-Global-Deploy02 respectively.
– To ensure system security, the root directory is automatically changed when the ftpuser user
uses the FileZilla to log in to the VM node. On the FileZilla, /opt/pub/upload/ftproot is
displayed as /ftproot.
Therefore, upload the software package to /ftproot.
2. Log in to the primary management node and secondary management node in active site
as the sopuser user, and copy the security hardening package and its signature file from
the /opt/pub/upload/ftproot directory to the /usr/local directory.
NOTE
– The initial password of the sopuser user is D4I$awOD7k.

– The initial password of the root user is Changeme_123.
– If the password has been changed, use the new password to log in. Changing passwords
periodically prevents password leaks and unauthorized access.
su - root
cp /opt/pub/upload/ftproot/CloudOpera_OSHardening_SLES_x86_64.zip* /usr/
local
3. Log in to the primary management node as the sopuser user. Copy the security
hardening package and its signature file from the primary management node to /var/tmp
of all other nodes except the primary and secondary management nodes.
NOTE
To ease the operation, you can use the sopuser users to log in to all other nodes except the primary
and secondary management nodes using FileZilla, and upload the files to the /var/tmp directory of
each node.
su - root
cd /opt/pub/upload/ftproot
scp CloudOpera_OSHardening_SLES_x86_64.zip* sopuser@<IP address of another
to-be-hardened node>:/var/tmp
Information similar to the following is displayed for initial file transferring. Input yes:
The authenticity of host '10.167.211.86 (10.167.211.86)' can't be established.
ECDSA key fingerprint is SHA256:k4jIHWEbMXGPC+eyZhIrbCxR73cS6Dt1twXoSkfsg7w.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Enter the password of the sopuser user for the node to which the files are to be uploaded.

Warning: Permanently added '10.167.211.86' (ECDSA) to the list of known hosts.
Authorized users only. All activity may be monitored and reported.
[email protected]'s password:
If the following information is displayed, the files are transferred successfully.

CloudOpera_OSHardening_SLES_x84_64.zip
100% 7548 0.1KB/s 00:00
CloudOpera_OSHardening_SLES_x84_64.zip.asc
100% 20 0.1KB/s 00:00
4. Log in to all nodes except the primary and secondary management nodes as the sopuser
user and copy the security hardening package and its signature file the /var/tmp
directory to the /usr/local directory.
su - root
cp /var/tmp/CloudOpera_OSHardening_SLES_x86_64.zip* /usr/local
Step 2 Verify the integrity of the security hardening package.
For details about how to verify software package, see Verifying Software Packages in
Step 3 Set the IP address whitelist of secondary site on all nodes of active site.
1. Log in to the OS requiring security hardening as user sopuser user and then switch to
root user. Decompress the package.
su - root
cd /usr/local
unzip -q CloudOpera_OSHardening_SLES_x86_64.zip -d harden
Run the following command to check whether the decompression is successful:
ls /usr/local/harden
The package is decompressed successfully if information similar to the following is
displayed.
master:~ # ls /usr/local/harden/
bootstrap.sh iptables scriptISO scriptOS
CloudSOP log.txt scriptIT version
2. Add physical IP addresses of all nodes at standby site and floating IP address
information of secondary site to the IP whitelist of active site.
bash /usr/local/harden/iptables/custom/add_backup_cluster_ip.sh <IP address of the
Deploy01 node of standby site> <IP address of the Deploy02 node of standby site> <IP
address of the Service01 node of standbysite> <IP address of the Service02 node of
standby site> <IP address of the DB01 node of standby site> <IP address of the DB01
node of standby site> <IP address of the OM01 node of standby site><IP address of the
OM01 of standby site> <floating IP address of the Deploy node of standby site>
<floating IP address of the Service node of standby site>
For example: bash /usr/local/harden/iptables/custom/add_backup_cluster_ip.sh
10.19.3.31 10.19.3.32 10.19.3.33 10.19.3.34 10.19.3.35 10.19.3.36 10.19.3.37 10.19.3.38
10.19.3.39 10.19.3.30
The commands are successfully run if the following message is displayed:
[2017-10-15 17:51:08] [10359] [INFO] successful to add the backup cluster IPs.
NOTE
If secondary site includes a capacity expansion node, you also need to add the physical IP address
of this capacity expansion node to the whitelist of active site.

3. Set the IP address whitelist of standby site.

bash /usr/local/harden/bootstrap.sh
The IP address whitelist is set successfully if information similar to the following is
displayed:
Execute hardenSSH.sh successfully
Executing OS harden based on CloudSOP complete.
Executing preConfig for iptables...
Executing preConfig for iptables complete.
Executing iptables...
Executing iptables complete.
Execute OS basic harden successful.
4. Retain the session for setting the IP address whitelist and create a session. Log in to the
server as the sopuser user, and check whether the IP address whitelist is set successfully.
Step 4 Refer to Step 1 to Step 3 to perform the security hardening operations on all nodes of standby
site, and set the IP address whitelist of active site on all nodes of standby site.
Step 5 Verify the integrity of the security hardening package.
For details about how to verify software package, see Verifying Software Packages in
Step 6 Use the sopuser user to log in to the hardened server and check whether iptables whitelist
hardening is successful.
su - root
iptables -nL
If information similar to the following is displayed, the hardening is successful.

...
ACCEPT tcp -- 10.176.245.87 0.0.0.0/0 tcp spt:23861
Chain FORWARD (policy ACCEPT)

target prot opt source destination
Chain OUTPUT (policy ACCEPT)

target prot opt source destination
DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 5
DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 14
Step 7 (Optional) The audit service is disabled, and the related audit rules have been configured after
the OS harden because enable the audit service will affect the performance. If there is a higher
security need, you can run the following commands to enable the audit service.
su root
chkconfig auditd on
/etc/init.d/auditd restart
----End

5.2.6.6 Security Hardening Requirements

For system security reasons, you need to configure security hardening on your environment
according to requirements in this chapter.
Restrictions on NTP Service Port 123

Standard NTP service port 123 cannot be bound to fixed IP addresses. To ensure system
security, use iptables provided by the OS to set an IP address whitelist. Only the IP addresses
in this whitelist can access port 123 that in the NTP service network segment.
If the network segment of the NTP service changes, modify the iptables settings accordingly.
Antivirus Requirements
Antivirus software is not preinstalled on CloudOpera Orchestrator SDN. To ensure the system
security, you are advised to deploy the antivirus software provided by Trend Micro on VMs
run on Linux OS. You need to purchase, install, and deploy antivirus software, and upgrade or
install patches on a scheduled basis.
Do not install or run non-standard software, such as the firewall, antivirus, game, or pirated
software, on the key servers. Otherwise, unpredictable consequences may be produced.
Huawei will not be liable for any loss caused thereby.
5.2.7 Configuring the DR System

CloudOpera Orchestrator SDN is able to check whether basic requirements for creating the
DR system are met.
When a remote DR system is created, the following checks and operations will be performed:
l Check whether the heartbeat IP addresses of the primary and secondary sites can
communicate with each other.
l Check whether the number of nodes deployed on the primary and secondary sites is
consistent.
l Check whether services and service versions deployed on the primary and secondary
sites are consistent respectively.
l Check whether a backup policy can be created successfully.
Prerequisites
Security hardening has been performed on the primary and secondary sites. For details, see
5.2.6 Security Hardening.
5.2.7.1 Updating Certificates for the Management Plane and Service Plane
Before creating a remote DR system, you can use the same CA certificate to update the
certificates of both the active and standby sites. This operation ensures that the active and
standby sites use the same CA certificate for normal communication between the sites. The
following describes how to the CA certificates of the management plane and service plane of
sites.

Prerequisites
You have obtained the following CA certificates from the certificate authority, stored the
certificates to the PC, and obtained certificate passwords:
l ca.cer: certificate of identify of the root certificate
l ca_key.pem: private key for the certificate of identify of the root certificate
Context
NOTICE
l During CA certificate update, services on all nodes need to be restarted so that the
certificate becomes valid. Therefore, perform the following operations at a time when the
service volume is small.
l Before roll back, Ensure that CA certificate has been backed up to /tmp/cert directory.
Procedure
Step 1 Disabling database failover.
1. Log in to the primary management node as the sopuser user, Run the following
commands to switch to the ossadm user.
su - ossadm
2. Run the following command to disable the failover function:
cd /opt/oss/manager/apps/DBHASwitchService/bin
./switchtool.sh -cmd set-ignore-nodes -nodes all
If the following command output is displayed, the failover function is successfully
disabled:
Successful
Step 2 Check whether the PC has CA certificates that are applied from the certificate authority.
If… Then…
The CA 1. Use FileZilla to upload the ca.cer and ca_key.pem certificates to the /
certificates exist ftproot directory of the primary management node of the active site as
the ftpuser.
NOTE
The absolute directory of /ftproot is /opt/pub/upload/ftproot/.
2. On the primary management node of the active site, perform Step 3 to
Step 9.

If… Then…
The CA 1. Use FileZilla to download the on the ca.cerand ca_key.pem

certificates do certificates from the primary management node on the active site to a
not exist local PC as the ftpuser.
2. Use FileZilla to upload the ca.cer and ca_key.pem certificates to the /
ftproot directory of the primary management node of the standby site
as the ftpuser.
NOTE
3. On the primary management node of the standby site, perform Step 3
to Step 8.
Step 3 Use PuTTY to log in to the primary management node on the active site as the sopuser, run
the following command to switch to user root:
su - root
Step 4 Run the following command to create a directory for store new certificates.
mkdir -p /tmp/CA
Step 5 Run the following commands to copy the uploaded CA certificate to the certificate save path
and modify the owner and permission of the certificate:
cp /ftproot/ca.cer /tmp/CA/
cp /ftproot/ca_key.pem /tmp/CA/
chown -R ossadm:ossgroup /tmp/CA
chmod 640 /tmp/CA/*
Step 6 Run the following commands to update the CA certificate.
The original CA certificate is automatically backed up to the /tmp/cert directory of the
management node.
su - ossadm
cd /opt/oss/management/apps/EngrCommonService/tools/common
bash replaceCaCert.sh -capath /tmp/CA
Password:
Step 7 Enter the password of the uploaded certificate, and press Enter.
When the system displays the following information, the CA certificate password is correct.
Otherwise, the password may be incorrect.
Successed to check input password.
l If the following information is displayed, the CA certificate on all nodes is successfully

updated. Otherwise, contact Huawei technical support.
success to replace ca certificate.
l If information similar to the following is displayed and the IP address of the node on
which the certificate fails to be updated is a service node, locate and rectify the fault.

And then, manually update the CA certificate on the service node where the certificate
fails to be updated. For details, see section 7.6 Updating Certificates of Active and
Standby Sites Manually.
ca certificate of service plane replace failed, ip list:
10.10.10.10,10.10.10.11
l If other information is displayed, locate and rectify the fault as prompted.
Step 8 Check whether the CA certificate has been successfully updated.

1. On the browser, enter https://IP address of the management node of the primary site:
31943 in the address box, and press Enter.
2. On the login page, enter the user name admin and its password and click Log in.
3. Create a backup task for a random service and check whether the backup is successful.
For details, see 2.2 Backing Up Dynamic Data.
– If the backup task is created successfully, the certificate is updated successfully and
you can run the following commands to delete the CA certificate that has been
backed up:
rm -rf /tmp/CA/*
rm -rf /tmp/cert/*
– If the backup task fails to be created, the certificate is unavailable or fails to be
updated. If you want to roll back to the certificate before the update, run a command
to roll back to the initial certificate as follows:
i. Use PuTTY to log in to the primary management node on the active site as the
sopuser, run the following command to switch to user ossadm:
su - ossadm
ii. Run the following commands to use the original CA certificate for a rollback:
cd /opt/oss/management/apps/EngrCommonService/tools/common
bash replaceCaCert.sh -capath /tmp/cert
Password:
iii. Enter the password of the original certificate and press Enter.
When the system displays the following information, the CA certificate
password is correct.
Successed to check input password.
iv. When the system displays information indicating that CA certificates of all
nodes are successfully updated, perform Step 8 to check the certificate
rollback result.
Step 9 Update the CA certificate of the standby site with reference to steps Step 2 to Step 8.
Step 10 Enabling database failover.

1. Log in to the primary management node as the sopuser user, Run the following
commands to switch to the ossadm user.
su - ossadm
2. Run the following command to enable the failover function:
cd /opt/oss/manager/apps/DBHASwitchService/bin
./switchtool.sh -cmd del-ignore-nodes

If the following command output is displayed, the failover function is successfully

enabled:
Successful.
----End
5.2.7.2 Backing up the Primary and Secondary Sites

Before establishing a DR relationship, set backup parameters to ensure that data can be
backed up properly during disaster recovery.
Procedure
Step 1 Set global backup parameters at the primary and secondary sites separately. For details, see
section 2.1 Setting Global Backup Parameters.
NOTICE
When you configure the backup server, ensure that the active and standby sites use the same
backup policy (The address, backup path, user name, and password of the backup server at the
primary site are the same as those at the secondary site).
Step 2 Back up data on the primary and secondary sites so that when a fault occurs, data can be
recovered in time. For details, see section 2.2 Backing Up Dynamic Data.
----End
5.2.7.3 Associating the Primary and Secondary Sites

After CloudOpera Orchestrator SDN is installed on the active and standby sites, the active and
standby sites must form a remote DR system to remotely synchronize data in real time. If the
active site encounters a fault, services can be migrated to the standby site to ensure the proper
running of services and improve product reliability.
Prerequisites
l You have configured the backup parameters on the active and standby sites and back up
data on the active site. For details, see CloudOpera Orchestrator SDN Backup and
Restoration.
NOTE
When you configure the backup server, ensure that the active and standby sites use the same
backup policy. That is, the backup path, user name, and password of backup servers of the active
site are the same as those of the standby site, so that the backup data can be transmitted between
the active and standby sites.
l You have obtained the following information for both the active and standby sites:
– Heartbeat IP address (IP addresses of the active management node and standby
management node)
– Site region

Context
If you need to modify the heartbeat IP address of the active and standby sites, you must delete
the existing disaster recovery system and create another one. For details, see section 5.3.6
Separating the Primary and Secondary Sites and this section.
Procedure
Step 1 Open a web browser, input https://Floating IP address of the CloudOpera Orchestrator SDN
management node of the primary site:31943 in the address box, input the user name admin
and password, and press Enter.
Step 2 Choose System > Remote DR System > Manage Remote DR System from the main menu.
Step 3 On the Disaster Recovery Management page, click Establish DR System.
Step 4 On the displayed page, set parameters according to the plan and click Precheck.
l If the check succeeds, in the displayed dialog box, click OK. And click OK on the page.
l If the check fails, resolve the problem as prompted and re-create the DR system.
Step 5 In the Warning dialog box, click OK, and then in the displayed dialog box, click OK.
Step 6 In the Prompt dialog box, click OK.
The system has created a task successfully. Click Task Information List to view the task
execution status. If the task execution fails, rectify the failure based on detailed information
about the task.
Step 7 On the Disaster Recovery Management page, check the statuses in the Heartbeat Status
and Data Synchronization Status columns.
l If the statuses all display , the remote DR system status is normal. Go to Step 8.
l If any status displays , contact Huawei technical support.
Step 8 Check whether the basic functions of the system are normal. For example, check whether the
menu options on the web page of the O&M plane are completely displayed and no abnormal
alarm information is displayed about DR on the O&M plane.
----End
Follow-up Procedure
If two sites form a remote DR system for the first time, you need to update the certificates of
the DR system to improve system security. For details, see 5.3.7 Updating Certificates for
the Disaster Recovery System.
5.2.8 Migrating the DR System

Manually synchronize the data of the active site to the standby site.

Context
Assume that services are successfully migrated from the active site to the standby site, the
active site becomes the standby site and the standby site becomes the active site. The data
replication direction between site changes accordingly.
If service migration fails, the active site still functions as the active site and the standby site
functions as the standby site.
Procedure
Figure 5-4 DR status
If the heartbeat status displays and the data synchronization status displays or , the
statuses are normal. Perform Step 4. Otherwise, contact Huawei technical support engineers.
Step 4 In the row of the to-be-drilled remote DR system, click .
execution status. If the task execution fails, rectify the failure based on detailed information
about the task.
Step 7 On the Disaster Recovery Management page, check the Primary and Secondary columns.
The migration is complete if the active/standby status of the original primary and secondary
sites has changed.
----End
5.2.9 Configuring Services of the Secondary Site

The commissioning operations for the standby site are the same as those for the active site.
Refer to this chapter to complete the commissioning on the standby site.

Procedure
Step 1 Open a web browser, input https://Floating IP address of the management node of the
primary site:31943 in the address box, input the user name admin and password, and press
Enter.
Step 2 Commission services at the active site. For details, see section Interconnecting with
External Systems (TSDN) and Interconnecting with External Systems (IP WAN) in
Step 3 Check whether the current active site is the primary site.
3. Choose System > Remote DR System > Manage Remote DR System from the main
menu.
4. On the Disaster Recovery Management page, check whether the IP address of the
active site is that of the primary site.
– If the active site is the primary site, no further operation is required.
– If the active site is not the primary site, migration the DR system on the secondary
site so that the active and standby sites are the same as planned. For details, see
5.2.8 Migrating the DR System.
----End
5.3 Remote DR System Common Operations

This chapter describes maintenance operations related to the remote DR system, which
facilitates the management of the DR system.
5.3.1 Disaster Recovery Scenarios

This section describes possible disaster recovery scenarios to help you understand operations
that may be involved when you use the remote DR system.
Table 5-8 DR scenarios and operation schemes
Scenario Scheme
During DR reconstruction, the newly created Associating the Active and Standby
secondary site and the currently running primary Sites
site are set up as a DR system.
l During DR reconstruction, the DR system is 1. Separating the Primary and

separated and a site of the original DR system Secondary Sites
forms a new DR system with another site. 2. Associating the Active and
l The heartbeat IP address is changed. Standby Sites

Scenario Scheme
Services at a site need to be upgraded. 1. Separating the Primary and

Secondary Sites
2. Upgrade services at the primary and
secondary sites by referring to the
upgrade guide of the corresponding
version.
3. Associating the Active and
Standby Sites
During routine maintenance, check whether the Disaster Recovery System Drill
secondary site can take over services from the NOTE
primary site. After the migration is complete at the
secondary site, perform a migration at the
primary site to migrate services back to the
primary site.
l The heartbeat network between the primary Forcibly Synchronizing Data

and secondary sites is abnormal. As a result, Between Sites
the secondary site takes over services and NOTE
becomes the active site. The system enters Specify a site as the active site for the dual-
the dual-active mode. active mode.
l The primary site is faulty. The secondary site
takes over services and becomes the active
site. As a result, the system enters the dual-
active mode.
l The data replication network is abnormal,
causing data inconsistency between the
primary and secondary sites. After the data
replication network recovers, the data is
forcibly synchronized between the primary
and secondary sites.
l After the data synchronization relationship
between the primary and secondary sites is
deleted, the data synchronization relationship
is abnormal.
l The secondary site is faulty. As a result, data
is inconsistent between the primary and
secondary sites and the data synchronization
status is abnormal.
The primary site is faulty. Taking Over Services from the

Faulty Site
5.3.2 Disaster Recovery System Drill

When the remote DR system is running properly, the DR drill function allows you to verify
the peer site status and migration capability. This helps ensure that the peer site status is
normal so that when the active site is faulty, the peer site can take over services and fast
become the active site. You are advised to perform the DR drill once every six months.

Context
Assume that services are successfully migrated from the active site to the standby site, the
active site becomes the standby site and the standby site becomes the active site. The data
replication direction between site changes accordingly.
If service migration fails, the active site still functions as the active site and the standby site
functions as the standby site.
Procedure
If the heartbeat status displays and the data synchronization status displays or , the
statuses are normal. Perform Step 4. Otherwise, contact Huawei technical support engineers.
Step 4 In the row of the to-be-drilled remote DR system, click .
The system has created a task successfully. Click System > Task Manager > Task Information
List to view the task execution status. If the task execution fails, rectify the failure based on
detailed information about the task.
Step 7 On the Disaster Recovery Management page, check the Primary and Secondary columns.
The migration is complete if the active/standby status of the original primary and secondary
sites has changed.
----End
5.3.3 Taking Over Services from the Faulty Site

When the active site is faulty and cannot provide services, you can perform operations in this
section to migrate services from the active site to the standby site.

Context
You can perform service takeover only on the secondary site which is running properly. After
the takeover is successful, the secondary site takes over services from the faulty primary site,
becomes the active site, and provides services for system.
Procedure
1. Open a web browser, input https://Floating IP address of the management node of the
standby site:31943 in the address box and press Enter.
Step 3 In the row of the remote DR system, click .

The task create successful. Click System > Task Manager > Task Information List to view
the task execution status. If the task execution fails, rectify the failure based on detailed
Step 6 On the Disaster Recovery Management page, changes to .

Step 7 Log in to the OM plane of CloudOpera Orchestrator SDN.
1. Open a web browser, input https://Floating IP address of the regionAlias-OM-Global-
Base01 node on the standby site:31943 in the address box and press Enter.
2. Input the user name and password on the login page, and click Log In.
If you can successfully log in to the OM plane, the services have been taken over by the
secondary site. Otherwise, contact Huawei technical support engineers.
menu options on the web page of the O&M plane are completely displayed.
----End
5.3.4 Forcibly Synchronizing Data Between Sites

When the data synchronization between the active and standby sites is abnormal. You can
perform this section to make the primary and secondary sites data consistent.
Context
NOTICE
If you forcibly synchronize data when data is inconsistent on the active and standby sites, the
full data will be synchronized from the specified site to the peer site after the synchronization
is successful. Data on the peer site will be overwritten.

The following scenarios need to be executed forcible data synchronization:
l The network for data replication between sites is interrupted for a long time and needs to
be restored.
l Data synchronization relationship between sites has been deleted.
Procedure
If the heartbeat status displays but the data synchronization status display , to Step 4.
Step 4 In the row of the remote DR system with data to be synchronized, click . Select the data
synchronization direction between the active and standby sites.
NOTE
You are advised to synchronize data from the currently active site to the standby site to reduce system
data loss. In a dual-active scenario, determine the synchronization direction based on actual conditions.
Step 7 On the Disaster Recovery Management page, check the status in the Data Synchronization
Status column.
If the status displays , the synchronization is successful. Otherwise, check whether the
network status is normal. If data synchronization still fails after the fault is rectified, contact
Huawei technical support.
----End

5.3.5 Deleting the Data Synchronization Relationship Between

the Active and Standby Sites
When you upgrade services on the active and standby sites, deleting the data synchronization
relationship between the two sites can prevent temporary data being synchronized from the
active site to the standby site. If temporary data is synchronized from the active site to the
standby site, the standby site cannot start and services on the standby site will fail to be
upgraded.
Prerequisites
Ensure that no service is being processed. If a service is being processed, wait until the
service processing is complete and perform the operations described in this section.
Procedure
Status column.
l If the data synchronization status displays or , perform Step 4.
l If the data synchronization status displays , the data synchronization relationship

between the active and standby sites cannot be deleted. After the system automatically
restores the data synchronization relationship between the active and standby sites, go to
Step 4.
Step 4 In the row of the remote DR system with data synchronization relationship to be deleted, click
.
execution status. If the task fails to be executed, wait for about five minutes and perform Step
4. If the task execution fails, rectify the failure based on detailed information about the task.
Status column.

Figure 5-8 Data synchronization status is abnormal
Click on the left to display details. If all data synchronization statuses that are displayed
are , the data synchronization relationship is successfully deleted. Otherwise, contact
Huawei technical support.
NOTE
For details about how to restore the data synchronization relationship between sites, see 5.3.4 Forcibly
Synchronizing Data Between Sites.
----End
5.3.6 Separating the Primary and Secondary Sites

When the remote DR system is no longer required or you need to create another remote DR
system and delete the original DR relationship, you can delete the existing remote DR system
and remove the DR relationship between the active and standby sites.
Context
After the inter-site disaster recovery relationship is successfully deleted, the inter-site data
replication relationship is also deleted. Services on each site are not affected. You can connect
the active and standby sites to compose a DR system. For details, see section 3.3.4-
Associating the Primary and Secondary Site for Disaster Recovery.
Procedure
Status column.
l If the data synchronization status displays or , perform Step 4.
l If the data synchronization status displays , the data synchronization relationship

between the active and standby sites cannot be deleted. After the system automatically
restores the data synchronization relationship between the active and standby sites, go to
Step 4.

Step 4 In the row of the to-be-deleted remote DR system, click .
Step 7 On the Disaster Recovery Management page, if the deleted DR system is no longer
displayed, it has been successfully deleted.
----End
5.3.7 Updating Certificates for the Disaster Recovery System

The services used by a remote DR system depend on the Secure Sockets Layer (SSL)
protocol. By default, digital certificates are preset when a DR system is installed. For security
purposes, replace the preset certificates with certificates applied from Certificate Authority
(CA).
Prerequisites
You have obtained the new SSL certificate and password from certificate authority:
l Identity certificate server.cer

l Private key of the identity certificate server_key.pem
l Trust certificate trust.cer
NOTE
Ensure that the identity certificate and the trust certificate are in the ASCII format. Other formats
are not supported.
Procedure
Step 2 Choose Disaster Recovery > Remote Disaster Recovery > Manage Remote DR System
from the main menu.
Check the heartbeat status between the active and standby sites.
l If the Heartbeat Status column displays , perform the following operation to update
the certificates.
l If the Heartbeat Status column displays , diagnose and rectify the fault, and then
perform the following operations to update the certificates.

Step 3 Use FileZilla as the ftpuser to upload the identity certificate, private key file of the identity
certificate, and trust certificate to the /ftproot directory on the primary management node.
NOTE
Step 4 Use PuTTY to log in to the primary management node of the active site as the sopuser.
Step 5 Run the following command to switch to the root user:
su - root
Step 6 Run the following command to create a backup directory for the certificates and press Enter:
mkdir -p /tmp/cert/DR
Step 7 Run the following command to back up the DR system certificates and press Enter:
cp -p /opt/oss/manager/etc/ssl/dr/* /tmp/cert/DR/
Step 8 Run the following command to create a directory to store the updated certificates:
mkdir -p /opt/updatecert
Step 9 Run the following command respectively to copy all the uploaded new certificates to the
corresponding directory:
cp /ftproot/Certificate name.Certificate format/opt/updatecert/
Step 10 Run the following commands on PuTTY to set the certificate group and permission:
chown ossadm:ossgroup -R /opt/updatecert
chmod 700 /opt/updatecert
find /opt/updatecert -type f| xargs chmod 600
Step 11 Run the following command to update the certificate:
su - ossadm -c '/opt/oss/manager/apps/DRMgrService/bin/cert_tool'

Please enter the certificate password:
Step 12 Enter the password for a new certificate and press Enter.

Please enter the certificate upload path:
Step 13 Enter the directory for storing the new certificates /opt/updatecert and press Enter.
If the following information is displayed, the certificates for the DR system are successfully
updated. Otherwise, contact Huawei technical support engineers.
Update the certificate task create successful.


Step 15 Choose System > Task Manager > Task Information list from the main menu to view the
execution status of the DR certificate update task.
l If the task is successfully executed, the certificates are updated successfully. Perform the
following operations:
Choose Disaster Recovery > Remote Disaster Recovery > Manage Remote DR
System from the main menu. Check the heartbeat status between the active and standby
sites.
– If the Heartbeat Status column displays , the certificate is successfully updated.
– If the Heartbeat Status column displays , the certificate fails to be updated.
Contact Huawei technical support engineers.
l If the task execution failure, the certificate update fails. If you want to roll back to the
certificates before the update, perform the following operations:
a. Run the following command to copy the backup initial DR certificates to the
directory for storing the updated certificates:
cp -p /tmp/cert/DR/* /opt/updatecert/
b. Perform Step 10 to Step 15 to roll back the DR certificates.
----End
5.3.8 Changing the Encryption Key of DR Certificates

For system security purposes, the default DR certificates password must be changed in a
timely manner.
Procedure
Step 1 Use PuTTY to log in to the IP address of the primary management node as the sopuser.
Step 2 Run the following command to switch to the ossadm user:
su - ossadm
Step 3 Run the following command to obtain the password ciphertext:
. /opt/oss/manager/bin/engr_profile.sh
cd /opt/oss/manager/agent/bin
./osskey -cmd encryptpasswd
Enter the new password and record the ciphertext of the new password when prompted as
follows:
New Password:
Reenter New Password:
Step 4 Run the following commands to modify the /opt/oss/manager/etc/ssl/dr/manifest.json file:
cd /opt/oss/manager/etc/ssl/dr
vi manifest.json
Change the values of storePass, keyStorePass, and trustStorePass to the ciphertext of the
new password in Step 3.

{
"server.jks": {
"storeType": "JKS",
"storePass": "ciphertext of the new password"
},
"port" : 31949,
"arbitrationPort" : 27321,
"keyStorePass": "ciphertext of the new password",
"trustStorePass": "ciphertext of the new password",
"trustStoreType": "SunX509"
}
Press Esc, enter :wq! to save the configuration and exit the vi editor.
Step 5 Perform the following operations to restart the DRMgrService service on the active and
standby sites.
su - root
3. Run the following commands to restart the DRMgrService service:
ipmc_adm -cmd restartapp -app DRMgrService
su - root
----End
5.3.9 Manually Synchronizing DR Certificates

The communication certificates on the active site need to be manually synchronized to the
standby site if the heartbeat is abnormal due to unmatched communication certificates.
Prerequisites
You have obtained the IP address of the node on which the active site DRMgrService service
is deployed.
Procedure
Step 1 Use FileZilla to log in to the IP address of the primary management node as the ftpuser.
Step 2 Use FileZilla to download the certificate in the /opt/oss/manager/etc/ssl/dr directory to any
directory on the local PC.
Certificate name:
l manifest.json
l server.csr
l server.jks

Step 3 Perform the following operations to query and record the IP addresses of the nodes on the
active and standby sites on which the DRMgrService database is deployed.
3. Choose Deployment > Database > RDBMS from the main menu.
4. On the RDBMS page, select All from the drop-down list in the upper right corner, input
DRMgr in the search box, and press Enter. The IP Address column displays the IP
addresses of the nodes on the active and standby sites on which the DRMgrService
database is deployed.
Step 4 Perform the following operations to delete certificates in the DRMgrService database on the
active site.
2. Run the following command to switch to the ossadm:
su - ossadm
3. Run the following command to query and record the IP address and port number of the
DRMgrService database instance.
NOTE
The following is one command. Copy the command to a Notepad and delete unnecessary line
breaks.
cd /opt/oss/manager/apps/DataMgmtService/bin;./dbsvc_adm -cmd query-db-instance -
tenant manager -type mysql|grep deploydbsvr |grep Master|awk '{print $7,$8}'
If information similar to the following is displayed, "10.22.90.209" is the IP address of
the DRMgrService database instance, "32081" is the port number.
10.22.90.209 32081
4. Run the following command to switch to the root:

su - root
5. Run the following commands to delete certificates in the DRMgrService database:
/opt/mysql/bin/mysql -udbuser -pPassword for the dbuser user -hIP address of the
DRMgrService database instance -PPort number of the DRMgrService database
instance -D drmgrdb
NOTE
The above is one command. Copy the command to a Notepad, replace the variables, and delete
unnecessary line breaks.
delete from tbl_certificate;commit;
exit
Step 5 Delete certificates in the DRMgrService database on the standby site by referring to Step 4.
Step 6 Use FileZilla to upload certificates obtained in Step 2 to the /opt/oss/manager/etc/ssl/dr

directory on the active and standby sites.
Step 7 Perform the following operations to restart the DRMgrService service on the active and
standby sites.

su - root
su - root
----End
5.4 Remote DR System Alarms

This chapter describes alarms related to the remote DR system and the troubleshooting
methods.
5.4.1 ALM-100000 Certificate of the Remote DR System About to

Expire
Alarm Description
If the remaining days before the communication certificates of the DR system are less than
30, the DR system reports a certificate about to expire alarm daily. After the communication
certificates are updated, the alarm will be automatically cleared.
Alarm Attribute
Alarm ID Alarm Severity Alarm Type
100000 Critical Software system
Alarm Parameters
Name Description
Primary Site; Region Indicates the region name of the primary

site.
Secondary Site; Region Indicates the region name of the secondary

site.

Impact on the System

If the communication certificates expire, communication between sites will fail.
Possible Causes
The remaining days before the communication certificates of the DR system are less than 30.
Procedure
Update the communication certificates of the DR system. For details, see 5.3.7 Updating
Certificates for the Disaster Recovery System.
Related Information
None
5.4.2 ALM-101200 Abnormal Replication
Description
The DR system periodically queries the data replication status between the active and standby
sites. If the replication status is abnormal, a replication error alarm is reported. If the DR
system confirms that the replication status is normal, the alarm is automatically cleared.
Attribute
Parameters
Name Description
Name Indicates the database instance name.
Type Indicates the database type.

l If the replication error is caused by network disconnection, all operations of the DR
system will fail.
l Data cannot be replicated between the active and standby sites.
l Migration and forcible synchronization are unavailable.
l Data loss occurs if the standby site forcibly takes over services from the active site when
the replication status is abnormal.

Possible Causes
l The network for data replication between the active and standby sites is abnormal.
l The data replication service is abnormal.
Procedure
Locate and clear the alarms according to the following scenarios.
Scenario Operation
Check the network connection The following describes how to check the heartbeat
of the DR system. connectivity between the active and standby sites.
1. Use PuTTY to log in to the active site management
node as the sopuser.
su - root
3. Run the following command to check the connectivity
between the active site management node and the
standby site management node:
ping IP address of the standby site management node
l If the IP address can be pinged, the network
connection is normal.
l If a request timeout or unreachable target host
message is returned, the network connection is
abnormal. Check and restore the network
connection.
Check the abnormal MySQL For details, see section Database Fault in CloudOpera
database scenarios and rectify Orchestrator SDN Troubleshooting.
the database faults.
If the alarm still exists after resolving the preceding possible causes, collect information
generated during alarm handling and contact Huawei technical support engineers.
Related Information
None
5.4.3 ALM-101201 Abnormal Heartbeat
Description
The DR system reports a heartbeat abnormal alarm if the active and standby sites do not
receive the heartbeat information from the peer end within the preset duration. The heartbeat
abnormal alarm is automatically cleared after the heartbeat information between the active
site and the standby site is normal.

Attribute
Parameters
Name Description
Site1 Indicates the name of the primary or

secondary site.
Site2 Indicates the name of the primary or

secondary site.

The manual service takeover and forcible data synchronization are unavailable.
Possible Causes
l The heartbeat network between the active and standby sites is abnormal.
l The disaster recovery service of the active or standby site is abnormal.
l The heartbeat communication certificates of the active site management node and the
standby site management node do not match or are invalid.
Procedure
Step 1 Check the heartbeat network connectivity between the active and standby sites.
1. Use PuTTY to log in to the active site management node as the sopuser.
su - root
3. Run the following command to check the connectivity between the active site
management node and the standby site management node:
ping IP address of the standby site management node
– If the IP address can be pinged, the network connection is normal. Perform Step 2.
– If a request timeout or unreachable target host message is returned, the network
connection is abnormal. Check and restore the network connection, and perform
Step 2.
Step 2 Check the disaster recovery process on the active site management node and standby site
management node.
1. Check the disaster recovery process on the active site management node.
a. Use PuTTY to log in to the management nodes as the sopuser.
b. Run the following command to switch to the root user:

su - root
c. Run the following command to check the disaster recovery process:
ps -ef|grep DRMgrService
If information similar to the following is displayed, the disaster recovery process
does not exist on the management node. Contact Huawei technical support.
Otherwise, the disaster recovery process exists on the management node, perform
Step 2.2.
ossadm 63211 1660 0 16:15 pts/1 00:00:00 grep DRMgrService
2. Similarly, check the DR process on the primary management node of the standby site.
Step 3 Check whether the communication certificates of the active site management node and
standby site management node match.
1. Use PuTTY to log in to the active site management node as the sopuser.
su - root
3. Run the following command to check the file size of the active site communication
certificate:
ls -l /opt/oss/manager/apps/DRMgrService/etc/ssl/server.jks
Information similar to the following is displayed. 4275 indicates the file size of the
communication certificate.
-rw-r----- 1 ossadm ossgroup 4275 Mar 16 19:20
4. Log in to the standby site management node and perform Step 3.1 to Step 3.3.
– If the file sizes of the three communication certificates are the same, the
communication certificates match with each other. Perform Step 4.
– If the file sizes of the three communication certificates are different, manually
synchronize the certificates and then restart the disaster recovery process. For
details, see 5.3.9 Manually Synchronizing DR Certificates.
5. After the certificates are manually synchronized, check whether the alarm is cleared.
– If yes, the alarm handling process is complete.
– If no, contact Huawei technical support.
Step 4 Check whether the communication certificates of the active site management node and
standby site management node are invalid.
1. Use PuTTY to log in to the primary site management node as the sopuser user.
su - root
3. Run the following commands to check the certificate validity:
NOTE
Ensure that you have obtained the DR Certificates password. The default password for the DR
Certificates is Changeme_123. You can change the password. For details, see 5.3.8 Changing the
Encryption Key of DR Certificates.
cd /opt/oss/manager/apps/DRMgrService/etc/ssl
/opt/oss/rtsp/jre-1.3.36/bin/keytool -list -v -keystore server.jks -storepass Password for
the DR Certificates
Information similar to the following is displayed. The date next to "until" is the
certificate validity.

Keystore type: JKS

Keystore provider: SUN
Your keystore contains 1 entry

......
......
......
Valid from: Tue Oct 18 21:45:04 CST 2016 until: Mon Jan 16 21:45:04 CST 2017
Certificate fingerprints:
– If the certificates will expire within 30 days, see 5.3.7 Updating Certificates for
the Disaster Recovery System to process this issue and then check whether the
alarm is cleared.
n If yes, the alarm handling process is complete.
n If no, contact Huawei technical support.
– If the certificates will expire in more than 30 days, contact Huawei technical
support engineers.
4. Perform the preceding operations on the primary management node of the standby site to
check the certificate validity.
----End
Related Information
None
5.4.4 ALM-101203 Migration Failure
Alarm Description
When a disaster recovery system performs automatic migration and the migration fails, a
migration failure alarm is reported. After the migration is performed again and is successful,
the disaster recovery system will automatically clear the migration failure alarm.
Alarm Attribute
Alarm Parameters
Name Description

site.

site.


None
Possible Causes
l Services at the active site cannot be stopped.
l Data synchronization direction cannot be reversed.
l Services at the standby site cannot be started.
Procedure
Collect the fault related information and contact Huawei technical support.
Related Information
None
5.4.5 ALM-101204 Abnormal Deployment of the Primary and

Secondary Sites
Alarm Description
This alarm is generated when nodes, service versions, or service instances deployed on the
active and standby sites are inconsistent.
Alarm Attribute
Alarm Parameters
Name Description

site.

site.

None

Possible Causes
l Nodes deployed on the active and standby sites are inconsistent.
l Service versions deployed on the active and standby sites are inconsistent.
l Service instances deployed on the active and standby sites are inconsistent.
Procedure
Locate and clear the alarm according to the following scenarios.
Scenario Operation
Check whether service versions 1. Open a web browser, input https://Floating IP

deployed on the active and standby address of the CloudOpera Orchestrator SDN
sites are consistent. management node of the active site:31943 in the
address box and press Enter.
2. Input the user name admin and password on the
login page, and click Log In.
3. Choose Deployment > Feature Deployment >
Services from the main menu.
4. On the Services page, check whether the
version of the same service is consistent.
For example, if the service name of
AuditLog/MG/GLO and AuditLog/MG/SHA
are both AuditLog-2.1.9, the service version is
consistent.
l If yes, the alarm handling process is
complete.
l If no, upgrade the service with an earlier
version according to the upgrade guide of the
corresponding version. And synchronize data
for the active and standby sites. For details,
see 5.3.4 Forcibly Synchronizing Data
Between Sites.

Scenario Operation
Check whether nodes deployed on the 1. Open a web browser, input https://Floating IP
active and standby sites are consistent. address of the CloudOpera Orchestrator SDN
management node of the active site:31943 in the
address box and press Enter.
2. Input the user name admin and password on the
login page, and click Log In.
3. Choose Resource > Server from the main
menu.
4. On the Server page, check the Name column.
Check whether the number of nodes deployed
on the active and standby sites is the same.
For example, GLO-Global-DB01 and SHA-
Global-DB01 are database nodes deployed on
the active and standby sites respectively.
l If yes, the alarm handling process is
complete.
l If no, add the same type of nodes according
to the expansion guide of corresponding
version. And synchronize data for the active
and standby sites. For details, see 5.3.4
Forcibly Synchronizing Data Between
Sites.
The alarm still exists after resolving Collect information generated during alarm
the preceding possible causes. handling and contact Huawei technical support
engineers.
Related Information
None

Backup and Restoration Guide 6 Common Operations
6 Common Operations
6.1 Configuring SFTP Fingerprint Authentication

Before backing up data to a remote SFTP server, you need to configure SFTP fingerprint
authentication between servers.
6.2 How Do I Start a Service?
This section describes how to start an O&M plane service. Starting a service automatically
starts all its microservices.
6.3 How Do I Stop a Service?
This section describes how to stop an O&M plane service. Stopping a service automatically
stops all its microservices.
6.4 Starting a DB Instance
When a database instance starts, all database instances on the node containing the database
will be started.
6.5 Stopping a DB Instance
6.6 Selecting One or Multiple Backup Objects
6.1 Configuring SFTP Fingerprint Authentication

Before backing up data to a remote SFTP server, you need to configure SFTP fingerprint
authentication between servers.
Prerequisites
You have obtained the initial password for the root user on the remote SFTP server. You have
obtained the initial password for the sopuser user of database nodes and the initial password
for the sopuser user of management node from Maintenance Guide.
Context
The SFTP protocol is used to back up databases to a remote server. To prevent phishing
attacks, SFTP fingerprint authentication must be enabled on the remote server. Manually add
the host key of the remote server to the known_hosts file on the local node.
Master/slave database nodes: Indicates the node whose node name ends with DB01 or DB02
in the node plan.

Procedure
Step 1 Log in to the remote SFTP server as the root user and run the following command to obtain
the host key to a local PC:
ssh-keyscan -t ecdsa IP address of the remote SFTP server
A host key is displayed, as follows:
IP address of the remote SFTP server ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS4AQHonYvoDJ
+k8cPPrWGgZWXHHu6yXlKeYG4adPdZOe0siBCMVYSJJuRpEHnbV8+34csE3kAzqEHxQKZRwMc=
NOTE
A complete host key contains IP address of the remote SFTP server.
Step 2 Log in to the DB01 node as the sopuser user.
Step 3 Run the following command to switch to the ossadm user.

su - ossadm
Step 4 Add the host key obtained in Step 1 to the ~/.ssh/known_hosts file on the current node.
1. Run the following command to check for the ~/.ssh/known_hosts file on the nodes:
ll ~/.ssh/known_hosts
2. (Optional) If the file does not exist, run the following command to create the ~/.ssh/
directory:
mkdir .ssh
3. Run the following command to edit the known_hosts file.
vi ~/.ssh/known_hosts
4. Press i to enter the edit mode, append the host key obtained in Step 1to the file.
5. Press Esc, enter :wq, and press Enter to save the settings and exits the vi editor.
6. Run the following command to verify the result:
cat ~/.ssh/known_hosts
The host key is successfully added if the following information is displayed.
IP address of the remote SFTP server ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS4AQHonYvoDJ
+k8cPPrWGgZWXHHu6yXlKeYG4adPdZOe0siBCMVYSJJuRpEHnbV8+34csE3kAzqEHxQKZRwMc=
7. Run the following command to set the permission of the file.

chmod 644 ~/.ssh/known_hosts
Step 5 Run the following command to check whether the host key takes effect:
ssh IP address of the remote server
Information similar to the following is displayed, enter the password as prompted. The
configuration has taken effect.
You are trying to access a restricted zone. Only Authorized Users
allowed.Password:
Step 6 Log in to all the other database node and the other management node respectively as the
sopuser user, repeat Step 4 to Step 5 to configure SFTP fingerprint authentication.
----End

Follow-up Procedure
Back up data to the remote SFTP server. For details, see 2 Data Backup.
6.2 How Do I Start a Service?

This section describes how to start an O&M plane service. Starting a service automatically
starts all its microservices.
Procedure
Step 1 Log in to the service deployment system (https:// Floating IP address of the management
nodes:31943) and choose Monitor > Service Management > Start and Stop Products.
Step 2 Click for Product in the Product Alias column to start a service on the service or O&M
nodes.
NOTE
Product corresponds to all services on the service and O&M nodes.
Step 3 On the Service tab for monitoring statuses, select one or more services to be started and click
Start. In the displayed dialog box, click OK to start the selected services.
NOTE
Due to data cache, it takes about 5 seconds to open the tab for the first time. The waiting time depends
on the number of services in the system and the server performance.
Step 4 Check the startup statuses of services in the Status column.

l If Status displays Running, starting the service succeeds.
l If Status displays Partially Running or Not Running, starting the service fails. Try to
start the service again and contact Huawei engineers if the failure persists.
----End
6.3 How Do I Stop a Service?

This section describes how to stop an O&M plane service. Stopping a service automatically
stops all its microservices.
Procedure
Step 1 Log in to the service deployment system (https:// Floating IP address of the management
nodes:31943) and choose Monitor > Service Management > Start and Stop Products.
Step 2 Click for Product in the Product Alias column to stop a service on the service or O&M
nodes.

NOTE
Product corresponds to all services on the service and O&M nodes.
Step 3 On the Service tab for monitoring statuses, select one or more services to be stopped and click
Stop. In the displayed dialog box, click OK to stop the selected services.
NOTE
Due to data cache, it takes about 5 seconds to open the tab for the first time. The waiting time depends
Step 4 Check the startup statuses of services in the Status column.

l If Status displays Not Running, stopping the service succeeds.
l If Status displays Partially Running or Running, stopping the service fails. Try to stop
the service again and contact Huawei engineers if the failure persists.
----End
6.4 Starting a DB Instance

When a database instance starts, all database instances on the node containing the database
will be started.
Procedure
Step 1 You have logged in to the Management-plane of CloudOpera Orchestrator SDN (https://the
floating IP address of the primary and secondary management nodes:31943) using a browser.
Step 2 Choose Monitor > Service Management > Start and Stop Products.
Step 3 Click in the column of the corresponding product.
Step 4 Select one or more nodes on which the databases need to be started and click in the
Operation column. Click Yes in the displayed dialog box to start the selected nodes.
NOTE
Due to data cache, it takes about 5 seconds to open the page for the first time. The waiting time depends
Step 5 Check the DB instances startup status in the Status column.

l If DB Status changes to Running, the DB instance is successfully started.

l If DB Status changes to Partially Running or Unknown, the DB instances fail to be

started. You can start the DB instances again. If the problem persists, contact Huawei
technical support engineers.
----End
6.5 Stopping a DB Instance

When a database stops, all databases on the node containing the database will be stopped.
Step 1 You have logged in to the Management-plane of CloudOpera Orchestrator SDN (https://the
floating IP address of the primary and secondary management nodes:31943) using a browser.
Step 2 Choose Monitor > Service Management > Start and Stop Products.
Step 3 Click in the column of the corresponding product.
Step 4 Select one or more nodes on which the databases need to be stopped and click in the
Operation column. Click Yes in the displayed dialog box to stop the selected nodes.
NOTE
Due to data cache, it takes about 5 seconds to open the page for the first time. The waiting time depends
Step 5 Check the DB instances startup status in the Status column.

l If DB Status changes to Not Running, the DB instance is successfully started.
l If DB Status changes to Running or Unknown, the DB instances fail to be started. You
can start the DB instances again. If the problem persists, contact Huawei technical
support engineers.
----End
6.6 Selecting One or Multiple Backup Objects

When performing operations such as dynamic data backup and OS backup, you may need to
select one or multiple specific backup objects from the backup objects. A backup object can
be a node or a service instance.
Procedure
Step 1 On the page that backs up dynamic data or operating system operations and so on, Click
and select 200 from the drop-down list to display the maximum number of backup objects
that is allowed on the current page.

Step 2 Clear the Instance Name check box.
NOTE
When you deselect the selected backup objects by clearing the Instance Name check box, only the
backup objects on the current page are deselected. The backup objects on other pages will not be
deselected.
All backup objects on the current page are not selected.
Step 3 Select the backup objects based on the site requirements.

NOTE
When you select all backup objects by selecting the Instance Name check box, only the backup objects
on the current page are selected. The backup objects on other pages will not be selected.
----End

Backup and Restoration Guide 7 FAQ
7 FAQ
7.1 Failed to Create Dynamic Data Backup Tasks

7.2 Failed to Create Service Restoration Tasks
7.3 OS Security Hardening Items
This section describes all OS items to be hardened in detail.
7.4 MySQL Database Security Hardening Items
This section describes all MySQL database items to be hardened in detail.
7.5 How to Upload Files to a Specified Directory After OS Security Hardening Is Performed
7.6 Updating Certificates of Active and Standby Sites Manually
If the active and standby sites have different certificates, the remote DR system does not work
properly.
7.7 Changing Passwords for Backup Server User
Before backup and restoration, you need to set the user name and password for the backup
server user in the global backup parameters. Backup server users are used for CloudOpera
Orchestrator SDN to access the backup server. After changing the password for the backup
server user, you need to change the password for the backup server in the global backup
parameters. If you do not change the password, CloudOpera Orchestrator SDN cannot access
the backup server. As a result, the backup and restore function cannot be used.
7.1 Failed to Create Dynamic Data Backup Tasks

Symptom
On the service deployment system, a user chooses Deployment > Backup and Restore >
Backup Date from the main menu. On the displayed page, the user selects services to be
backed up. However, the service backup tasks fail to be created because the database
instances of the selected service are abnormal.
Prerequisites
The global backup parameters have been set.

Solution
Step 1 Choose Monitor > Service Management > Start and Stop Products from the main menu.
l If the DB Status of the product shows Unknown or Not Running, restore the database
by referring to section Database Restoration in CloudOpera Orchestrator SDN
Troubleshooting.
l If the DB Status of the product shows Running, contact Huawei technical support
engineers.
Step 2 Create a dynamic data backup task. For details, see2.2 Backing Up Dynamic Data.
----End
7.2 Failed to Create Service Restoration Tasks

Symptom
On the service deployment system, a user chooses Backup and Restore > Restore Data >
Restore Dynamic Data from the main menu. On the displayed page, the user selects services
that require data restoration. However, the service restoration tasks fail to be created because
there are running microservices in the services to be restored.
Prerequisites
l The service database instances are running properly.
l The service instances to be backed up have been obtained and backup data for these
services are available.
l The names of the service instances to be stopped have been noted down when data
restoration fails.
Solution
Step 1 Stop the running service instances. 6.3 How Do I Stop a Service?.
Step 2 Create backup a task. For details, see 3 Local Data Restoration.
----End
7.3 OS Security Hardening Items

This section describes all OS items to be hardened in detail.

System Service
No. Hardening Description Hardening Method
1 Unnecessary OS services are The hardening tool automatically runs the

disabled. following commands to shut down the
NFS and rpcbind services:
systemctl disable nfs
systemctl disable rpcbind
systemctl disable nfsserver
File Permission
1 The permissions, users, and user groups l The file permission for /etc/shadow
for files /etc/shadow and /etc/passwd is set to 000 and the user and user
are set. group are set to root.
l The file permission for /etc/passwd
is set to 644 and the user and user
group are set to root.
Kernel Parameter
1 The buffer overflow protection is In the /etc/sysctl.conf file,

enabled. kernel.randomize_va_space is set to
2.
2 The maximum number of processes is In the /etc/security/limits.conf file, the

restricted. following information is added:
* soft nproc 50000
* hard nproc 50000
3 The maximum number of In the /etc/sysctl.conf file, the

asynchronous inputs and outputs (I/O) following information is added:
is restricted. fs.aio-max-nr = 1048576
Account and Password

1 The validity of OS account password is In the /etc/login.defs file,

set to 90 days. PASS_MAX_DAYS is set to 90.

2 A notification for password expiration is In the /etc/login.defs file,

set to 28 days before the OS account PASS_WARN_AGE is set to 28.
password expires.
3 The umask parameter for newly created In the /etc/login.defs file, umask is
OS accounts is set to 027. set to 027.
4 The root user is not allowed to log in to In the /etc/ssh/sshd_config file,

the OS in SSH mode by default. PermitRootLogin is set to no.
5 An account will be locked after five In the /etc/pam.d/common-auth file,

consecutive login failures. the following information is added:
auth required pam_tally2.so
onerr=fail audit silent deny=5
even_deny_root unlock_time=900
root_unlock_time=900
6 The system account password rules are In the /etc/pam.d/common-

set. password file, the following rules
are set:
password required pam_cracklib.so
retry=3 minlen=8 difok=2 dcredit=-1
ucredit=-1 ocredit=-1 lcredit=-1
enforce_for_root password required
pam_pwhistory.so remember=12
use_authtok use_first_pass
enforce_for_root crypt=sha256
password required pam_unix2.so
nullok use_authtok
NOTE
The field minlen indicates the minimum
character length of passwords, for
example, 8, 10, and 14. You can specify
it based on the actual security hardening
policy.
7 User password is required each time the The following command is run:
sudo commands are run. sed -i "/Defaults env_reset/c Defaults
env_reset,timestamp_timeout=0" /etc
/sudoers
8 Only users in the wheel group are In the /etc/pam.d/su and /etc/
allowed to run the su command. pam.d/su-l files, the following rules
are set:
auth required pam_wheel.so use_uid
group=wheel

9 The backupuser and ftpuser users are In the /etc/ssh/sshd_config file, the
required to log in to the OS by using only following rules are set:
SFTP and can only access directories that Match User backupuser
are available to them. ChrootDirectory /opt/backup
ForceCommand internal-sftp -l INFO
-u 007
Match User ftpuser
ChrootDirectory /opt/pub/upload
ForceCommand internal-sftp -l INFO
-u 007
10 Users who are allowed to access the OS In the /etc/ssh/sshd_config file, the
in SSH mode are set. following rule is set:
AllowUsers User name
For example, if the sopuser,
backupuser, ftpuser, and ossadm
users exist, the rule is AllowUsers
backupuser sopuser ftpuser ossadm.
11 The available Key Exchange (KEX) In the /etc/ssh/sshd_config file,

algorithms are set on the SSH server. KexAlgorithms is set to the
following:
KexAlgorithms ecdh-sha2-
nistp256,ecdh-sha2-nistp384,ecdh-
sha2-nistp521,diffie-hellman-
group14-sha1
12 The space limit of user disks is set. l If the ftpuser user exists, the
space size of the /opt partition is
limited to 10 GB.
l If the backupuser user exists, the
space size of the /opt partition is
limited to 40% of the total
partition size.
Log Audit
1 The grub is configured to audit In the /boot/grub2/grub.cfg file,

processes that have been started before "audit=1" is added to the row started
the auditd service is started. In this with linux.
manner malicious operations can be
detected.

2 Events of changing the system time are In the /etc/audit/audit.rules file, the
recorded. following information is added:
-a always,exit -F arch=b64 -S adjtimex -
S settimeofday -k time-change
-a always,exit -F arch=b32 -S adjtimex -
S settimeofday -S stime -k time-change
-a always,exit -F arch=b64 -S
clock_settime -k time-change
clock_settime -k time-change
-w /etc/localtime -p wa -k time-change
3 Events that affect the following items In the /etc/audit/audit.rules file, the
are recorded: following information is added:
l /etc/group -w /etc/group -p wa -k identity
l /etc/passwd (user ID) -w /etc/passwd -p wa -k identity
l /etc/shadow -w /etc/gshadow -p wa -k identity
l /etc/gshadow (password) -w /etc/shadow -p wa -k identity
l /etc/security/opasswd (old password -w /etc/security/opasswd -p wa -k
whose number depends on PAM- identity
based maximum password attempts)
4 Changes of network environment files In the /etc/audit/audit.rules file, the

and system invocation are recorded. following information is added:
-a exit,always -F arch=b64 -S
sethostname -S setdomainname -k
system-locale
-a exit,always -F arch=b32 -S
sethostname -S setdomainname -k
system-locale
-w /etc/issue -p wa -k system-locale
-w /etc/issue.net -p wa -k system-locale
-w /etc/hosts -p wa -k system-locale
-w /etc/sysconfig/network -p wa -k
system-locale
5 The SELinux mandatory access control In the /etc/audit/audit.rules file, the

is monitored. following information is added:
-w /etc/selinux/ -p wa -k MAC-policy
6 Login and logout events are monitored. In the /etc/audit/audit.rules file, the
following information is added:
-w /var/log/faillog -p wa -k logins
-w /var/log/lastlog -p wa -k logins
-w /var/log/tallylog -p wa -k logins

7 Session initiation events are monitored. In the /etc/audit/audit.rules file, the

-w /var/run/utmp -p wa -k session
-w /var/log/wtmp -p wa -k session
-w /var/log/btmp -p wa -k session
8 Changes of the file permission, In the /etc/audit/audit.rules file, the

attributes, ownership, and group files following information is added:
are monitored. -a always,exit -F arch=b64 -S chmod -S
fchmod -S fchmodat -F auid>=500 -F
auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S chmod -S
fchmod -S fchmodat -F auid>=500 -F
auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown -S
fchown -S fchownat -S lchown -F
auid>=500 -F auid!=4294967295 -k
perm_mod
-a always,exit -F arch=b32 -S chown -S
fchown -S fchownat -S lchown -F
auid>=500 -F auid!=4294967295 -k
perm_mod
-a always,exit -F arch=b64 -S setxattr -S
lsetxattr -S fsetxattr -S removexattr-S
lremovexattr -S fremovexattr -F
auid>=500 -F auid!=4294967295 -k
perm_mod
-a always,exit -F arch=b32 -S setxattr -S
lsetxattr -S fsetxattr -S removexattr -S
lremovexattr -S fremovexattr -F
auid>=500 -F auid!=4294967295 -k
perm_mod

9 Events of file access failure are In the /etc/audit/audit.rules file, the

monitored. following information is added:
-a always,exit -F arch=b64 -S creat -S
open -S openat -S truncate -S ftruncate -
F exit=-EACCES -F auid>=500 -F auid!
=4294967295 -k access
open -S openat -S truncate -S ftruncate-
F exit=-EACCES -F auid>=500 -F auid!
=4294967295 -k access
F exit=-EPERM -F auid>=500 -F auid!
=4294967295 -k access
F exit=-EPERM -F auid>=500 -F auid!
=4294967295 -k access
10 The invocation of the mount command In the /etc/audit/audit.rules file, the

is monitored. following information is added:
-a always,exit -F arch=b64 -S mount -F
auid>=500 -F auid!=4294967295 -k
mounts
-a always,exit -F arch=b32 -S mount -F
auid>=500 -F auid!=4294967295 -k
mounts
11 System invocation related to the In the /etc/audit/audit.rules file, the

deletion or rename of file and file following information is added:
attributes is monitored. -a always,exit -F arch=b64 -S unlink -S
unlinkat -S rename -S renameat -F
auid>=500 -F auid!=4294967295 -k
delete
-a always,exit -F arch=b32 -S unlink -S
unlinkat -S rename -S renameat -F
auid>=500 -F auid!=4294967295 -k
delete
12 Changes of the scope of administrator In the /etc/audit/audit.rules file, the

rights are monitored. following information is added:
-w /etc/sudoers -p wa -k scope
13 Sudo logs are monitored. In the /etc/audit/audit.rules file, the

-w /var/log/sudo.log -p wa -k actions

14 The installation and uninstallation of In the /etc/audit/audit.rules file, the

the kernel module are monitored. following information is added:
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
init_module -S delete_module -k
modules
15 The system audit parameter is set so In the /etc/audit/audit.rules file, the

that users cannot run the auditctl following information is added:
command to change the audit rules. -e 2
16 The permission of the rsyslog process In the /etc/rsyslog.conf file, the

for creating files is restricted. following information is added:
$FileCreateMode 0640
17 Logins in SSH mode are recorded l SSH logs are stored in the
independently. mkdir /var/log/sshd directory.
l SSH logs are stored in the
touch /var/log/sshd/sshd.log file.
l In the /etc/rsyslog.conf file, the
following information is added to the
end of the file:
if ($programname == 'sshd') \
then {
-/var/log/sshd/sshd.log
stop
}
l The SSH service is restarted by
running the service sshd restart
command.
l The syslog service is restarted by
running the systemctl restart
rsyslog.service command.
18 Logins in SSH mode are recorded in In the /etc/ssh/sshd_config file,

logs. LogLevel is set to VERBOSE.
19 The lack of the wtmp log on some The wtmp log is recreated by running
SUSE OSs is resolved. the following command:
touch /var/log/wtmp
chmod 664 /var/log/wtmp
chown root:utmp /var/log/wtmp

Network Connection
1 The ClientAliveInterval and In the /etc/ssh/sshd_config file,

ClientAliveCountMax parameters parameters are set as follows:
control the SSH session timeout period. ClientAliveInterval 300
When the ClientAliveInterval
parameter is set, sessions that are ClientAliveCountMax 0
inactive in a specified period will be
ended. When the ClientAliveCount-
Max parameter is set, the SSH server
sends the number of alive messages to
clients at the end of each timeout
period set in the ClientAliveInterval
parameter.
2 TCP forwarding is forbidden. In the /etc/ssh/sshd_config file,

AllowTcpForwarding is set to no.
3 Remote hosts are not allowed to In the /etc/ssh/sshd_config file,

connect to ports forwarded for the GatewayPorts is set to no.
server.
4 X11 forwarding is forbidden. In the /etc/ssh/sshd_config file,

X11Forwarding is set to no.
5 The ssh-agent forwarding is forbidden. In the /etc/ssh/sshd_config file,

AllowAgentForwarding is set to no.
6 The SSH tunnels are forbidden. In the /etc/ssh/sshd_config file,

PermitTunnel is set to no.
7 Remote hosts are not allowed to In the /etc/ssh/ssh_config file,

connect to ports forwarded for the GatewayPorts is set to no.
client.
8 Unnecessary network functions of the l /proc/sys/net/ipv4/ip_forward is

OS are forbidden. set to 0.
l /proc/sys/net/ipv4/
icmp_echo_ignore_broadcasts is
set to 1.
9 The rp_filter, arp_announce, and l /proc/sys/net/ipv4/conf/*/rp_filter

arp_ignore parameters are set. is set to 1.
l /proc/sys/net/ipv4/conf/*/
arp_announce is set to 2.
l /proc/sys/net/ipv4/conf/*/
arp_ignore is set to 1.

10 The option for allowing trusted hosts is l The /etc/hosts.equiv file is deleted
disabled. if any.
l The /root/.rhosts file is deleted if
any.
The following commands are run to
create a symbolic link:
ln -s /dev/null /etc/hosts.equiv
ln -s /dev/null /root/.rhosts
11 The timeout period after login is set. In the /etc/profile file, the following
information is added:
TMOUT=900
export TMOUT
12 The IPv6 protocol is forbidden. In the /etc/default/grub file, the

GRUB_CMDLINE_LINUX_DEFAUL
T="resume=/dev/sda2
crashkernel=384M,high
crashkernel=256M,low
security=selinux selinux=1 enforcing=0
ipv6.disable=1"
13 Unnecessary operations in ICMPv4 and The following commands are run:

ICMPv6 data packages are forbidden. iptables -A INPUT -p icmp --icmp-
type 5 -j DROP
iptables -A INPUT -p icmp --icmp-
type 14 -j DROP
type 18 -j DROP
type 16 -j DROP
iptables -A OUTPUT -p icmp --icmp-
type 5 -j DROP
type 14 -j DROP
type 18 -j DROP
type 16 -j DROP
iptables-save > /etc/telcoos-iptables-
save

14 The available message authentication In the /etc/ssh/sshd_config file, the

code (MAC) algorithms are set. algorithms are set as follows:
l Basic security hardening by default:
MACs hmac-sha2-256-
[email protected],hmac-sha2-512-
[email protected],hmac-
sha2-256,hmac-sha2-512
l After secondary security hardening
to perform hardenSSH.sh:
MACs hmac-md5,hmac-sha2-256-
[email protected],hmac-sha2-512-
[email protected],hmac-
sha2-256,hmac-sha2-512
15 The ciphers allowed for protocol In the /etc/ssh/sshd_config file,

version 2 are set. Ciphers is set to the following:
Ciphers aes128-ctr,aes192-ctr,aes256-
ctr
16 The SSH services use PAM instead of In the /etc/ssh/sshd_config file,

S/KEY authentication. ChallengeResponseAuthentication is
set to no.
17 The listening IP address of the SSH In the /etc/ssh/sshd_config file,

service is the local IP address. ListenAddress is set to the local IP
address.
18 Set an IP address whitelist. Run the iptables -nL command to

check whether the IP address whitelist
is set successfully.
The IP address whitelist is set
successfully if information similar to
the following is displayed:
Chain INPUT (policy DROP)
target prot opt
source destination
ACCEPT udp --
10.167.210.233 0.0.0.0/0
ACCEPT tcp --
10.167.210.233
0.0.0.0/0 tcp spt:
32088
ACCEPT tcp --
10.167.210.234
0.0.0.0/0 tcp spt:
32088
ACCEPT tcp --
10.167.210.235
0.0.0.0/0 tcp spt:32088

Disabled OS Users
No. User Name Description
1 bin bin is a user who has minimum permissions and is created

automatically by the system. The user is used for running
commands and has been prohibited. However, the user cannot
be deleted.
2 man man is a user who has minimum permissions and is created

automatically by the system. The user is used for the Man
reading tool and has been prohibited. However, the user cannot
be deleted.
3 nobody nobody is a user who has minimum permissions and is created

automatically by the system. The user has been prohibited and
cannot be deleted.
4 rpc rpc is a user who has minimum permissions and is created

automatically by the system. The user is used for remote
procedure calls and has been prohibited. However, the user
cannot be deleted.
5 systemd-bus- systemd-bus-proxy is a user who has minimum permissions

proxy and is created automatically by the system. The user is used for
systemd process communication calls and has been prohibited.
However, the user cannot be deleted.
6 systemd- systemd-timesync is a user who has minimum permissions and

timesync is created automatically by the system. The user is used for
systemd time synchronization call and has been prohibited.
7 at at is a user who has minimum permissions and is created

automatically by the system. The user is used when tasks are
scheduled in batches and has been prohibited. However, the
user cannot be deleted.
8 messagebus messagebus is a user who has minimum permissions and is

created automatically by the system. The user is used for inter-
process communication services and has been prohibited.
9 polkitd polkitd is a user who is automatically created when the system

is installed and services are started. The user is used for the
PolicyKit service daemon process and has been prohibited.
10 sshd sshd is a user who is automatically created when the system is

installed and services are started. The user is used for the sshd
service daemon process and has been prohibited. However, the

No. User Name Description
11 ntp ntp is a user who is automatically created when the system is

installed and services are started. The user is used for the ntp
12 nscd nscd is a user who is automatically created when the system is

installed and services are started. The user is used for the nscd
13 vnc vnc is a user who is automatically created when the system is

installed and services are started. The user is used for the vnc
14 dhcpd dhcpd is a user who is automatically created when the system is

installed and services are started. The user is used for the dhcpd
15 tftp tftp is a user who is automatically created when the system is

installed and services are started. The user is used for the tftp
7.4 MySQL Database Security Hardening Items

This section describes all MySQL database items to be hardened in detail.
System Settings
1 The OS and the database cannot reside The MySQL database is installed in
in the same partition. the /opt directory by default.
2 The MySQL database operating The hardening tool adds the sopuser or
account dbuser is not allowed to log in ossadm user to the following file
to the OS in SSH mode. according to the condition:
/etc/ssh/sshd_config
The MySQL database operating user
dbuser is not allowed to log in to the
OS.
3 The command history of the MySQL The hardening tool automatically runs
database is not allowed to be displayed. the following command is run:
ln -s /dev/null $HOME/.mysql_history

4 The environment variable The hardening tool automatically runs

MYSQL_PWD is disabled and does the following command is run:
not exist in the profiles file. sed -i '/MYSQL_PWD/d' /etc/profile
Account and Password

1 The database instance user root is not This security hardening item is
allowed to log in to the database. configured by default when the
database instance is created.
File Permission
1 Permission for the MySQL software The hardening tool automatically runs
installation directory is set. the following command is run:
chmod 750 /opt/mysql
2 Permission for the data file directory is The hardening tool automatically runs
set. the following command is run:
chmod 700 /opt/mysql/data/Instance
name>
3 Permission for the my.cnf file is set. The hardening tool automatically runs
the following command is run:
chmod 600 my.cnf
4 Permission for the log_bin file is set. The hardening tool automatically runs
chmod 600 log_bin
5 Permission for the relay_log file is set. The hardening tool automatically runs
chmod 600 relay_log
6 Permission for the innodb data The hardening tool automatically runs
directory is set. the following command is run:
name
7 Permission for the innodb log file The hardening tool automatically runs
directory is set. the following command is run:
name

8 Permission for the audit log file The hardening tool automatically runs
audit.log is set. the following command is run:
chmod 600 /opt/mysql/data/<nstance
name/audit.log
Operating Parameter Settings

1 The creation of user names for logging The hardening tool automatically runs
in to the MySQL database is restricted. the following command is added to the
database startup commands:
--safe-user-create
2 The MySQL client of an early version The following is added to the /opt/
cannot access the server of a later mysql/my_product.cnf file:
version in the old password secure_auth=on
authentication mode.
3 The directory for importing MySQL The following is added to the /opt/
data is fixed. The directory varies mysql/data/Instance name/my.cnf file:
according to database instance names. secure-file-priv=/opt/mysql/data/
Instance name
4 Soft links for database files are The hardening tool automatically runs
disabled. the following command is added to the
database startup commands:
--skip-symbolic-links
5 Data are not allowed to be imported to The following is added to the /opt/
the MySQL database in remote mode. mysql/data/Instance name/my.cnf file:
local-infile=0
6 Authorization-free login to the MySQL This configuration item is configured

database is disabled. by default when the database is
installed.
7 Access to the MySQL database by The following is added to the /opt/

using the domain name is disabled. mysql/data/Instance name/my.cnf file:
skip-name-resolve
8 Unauthorized users are not allowed to The following is added to the /opt/
view database names. mysql/data/Instance name/my.cnf file:
skip_show_database

9 The port number range used by the The following is added to the /opt/
MySQL database is restricted. The mysql/data/Instance name/my.cnf file:
default port number 3306 cannot be port=Port number used by the database
used. instance
10 The MySQL database character set The following is added to the /opt/
must be UTF8. mysql/data/Instance name/my.cnf file:
character-set-server=utf8
11 Strict syntax check is enforced for SQL In the /opt/mysql/my_product.cnf file,

statements. the sql_mode configuration item is
modified as follows:
sql_mode='STRICT_ALL_TABLES,N
O_AUTO_CREATE_USER,NO_ENGI
NE_SUBSTITUTION'
7.5 How to Upload Files to a Specified Directory After OS

Security Hardening Is Performed
Question
How to upload files to a specified directory after OS security hardening is performed?
Answer
This section uses the operation of uploading the client.crt file to /opt/oss/Product/apps/
MessagingLBService/nginx/conf/kafka/rest_ssl as an example to describe the detailed steps.
Step 1 Upload the client.crt file to the /opt/pub/upload/ftproot directory on the active management
node and standby management node by using SFTP as the ftpuser.

NOTE
l The initial password of the ftpuser user was set during SSH security hardening.
l If the password has been changed, use the new password to log in. Changing passwords periodically
prevents password leaks and unauthorized access.
l To ensure system security, the root directory is automatically changed when the ftpuser user uses
the FileZilla to log in to the VM node. On the FileZilla, /opt/pub/upload/ftproot is displayed as /
ftproot.
Therefore, upload the software package to /ftproot.
Step 2 Log in to the active management node and standby management node as the sopuser user,
and copy the client.crt file to the/opt/oss/Product/apps/MessagingLBService/nginx/conf/
kafka/rest_ssl directory.
su - root
cp /opt/pub/upload/opt/pub/client.crt /opt/oss/Product/apps/MessagingLBService/nginx/
conf/kafka/rest_ssl
Step 3 Log in to the standby management node as the sopuser user. Copy the client.crt file from the
standby management node to /var/tmp of the non-management node by running the scp
command.
su - root
scp /opt/pub/upload/ftproot/client.crt sopuser@<IP address of the data node>:/var/tmp
Enter the password of the sopuser user as prompted:
Authorized users only. All activity may be monitored and reported.
sopuser@<IP address of the data node>'s password:
The file is copied successfully if the following information is displayed:

client.crt 100% 818 0.8KB/s 00:00
Step 4 Log in to the non-management node as the sopuser user, and copy the client.crt file and its
signature file to the /opt/oss/Product/apps/MessagingLBService/nginx/conf/kafka/rest_ssl
directory.
su - root
cp /var/tmp/client.crt /opt/oss/Product/apps/MessagingLBService/nginx/conf/kafka/
rest_ssl
----End
7.6 Updating Certificates of Active and Standby Sites

Manually
If the active and standby sites have different certificates, the remote DR system does not work
properly.
7.6.1 Updating CA Certificates of Management Nodes

The IR certificate and CA Certificate are automatically generated after CloudOpera
Orchestrator SDN is installed.

Context
l IR certificates are saved in /opt/oss/manager/etc/ssl/internal.
l IR certificates include the following files:
– manifest.json: certificate configuration file
– server.cer: identity certificate file of the server
– server.p12: certificate in .p12 format
– server_key.pem: private key to the identity certificate file of the server
– trust.cer: trust certificate file of the server
– trust.jks: trust certificate file in .jks format
Precautions
l Certificate update takes effect after nodes are restarted. You are advised to perform this
operation during off-peak hours.
l You are advised to back up the certificate file before update. Compress the IR certificate
file and save it to a directory where the current certificate does not reside.
l IR certificates on the management plane are updated at the same time.
l If active and standby nodes exist, restart them in the following sequence to prevent an
active/standby switchover:
a. Stop the standby node.
b. Stop the active node.
c. Start the active node.
d. Start the standby node.
precedure
Step 1 (Optional) Update the certificate password. For details, see 7.6.3 Updating the Certificate
Password.
Step 2 Log in as the sopuser user to the primary and secondary management nodes of the standby
site separately.
Step 3 Upload CA certificate files ca.cer and ca_key.pem to the /tmp directory on the primary and
secondary management nodes of the standby site.
NOTE
You can obtain the certificates from the CA or the /opt/oss/manager/var/ca/ directory on the
management nodes of the active site.
Step 4 Run the following commands as the root user to replace the CA certificates.
su - root
cp /tmp/ca.cer /opt/oss/manager/var/ca/
cp /tmp/ca_key.pem /opt/oss/manager/var/ca/
chown ossadm:ossgroup /opt/oss/manager/var/ca/ca.cer /opt/oss/manager/var/ca/ca_key.pem
chmod 600 /opt/oss/manager/var/ca/ca.cer /opt/oss/manager/var/ca/ca_key.pem

Step 5 Update the certificates of the management nodes.

cd /opt/oss/manager/etc/ssl/internal
cp /opt/oss/manager/var/ca/ca.cer trust.cer
chown ossadm:ossgroup trust.cer
chmod 600 trust.cer
Step 6 Stop the secondary and primary management nodes in sequence.
su - ossadm
ipmc_adm -cmd stopnode
Step 7 Update IR certificates of the management nodes.
1. Log in to the primary management node as the sopuser user and run the following
commands to update the IR certificate:
su - ossadm
./osskey -cmd replace_ircerts [-force]
NOTE
During replacing the IR certificate, Y/N is displayed for you to confirm. The commands above
enable you to enter the parameter –force to skip this confirmation step.
2. Run the following commands to start the primary management node:
ipmc_adm -cmd startnode
Step 8 Update the IR certificate of the secondary management node.
1. Log in to the secondary management node as the sopuser user and run the following
commands to update the IR certificate:
su - ossadm
./osskey -cmd replace_ircerts [-force]
2. Run the following commands to start the secondary management node:
----End
7.6.2 Updating CA Certificates of Non-Management Nodes

The IR CA certificate is automatically generated after CloudOpera Orchestrator SDN is
installed.
Context
l IR CA certificates are saved in /opt/oss/manager/var/ca/. CA certificates exist only on
management nodes.

l IR CA certificates include the following files:

– ca.cer: identity certificate file of the root certificate
– ca.csr: request certificate file of the root certificate
– ca_key.pem: private key to the identity certificate of the root certificate
Precautions
l After a certificate is updated, CloudOpera Orchestrator SDN must be restarted to apply
the certificate. Therefore, update certificates in off-peak hours.
l Back up the original certificate files before updating certificates.
l If active and standby nodes exist, restart them in the following sequence to prevent an
active/standby switchover:
a. Stop the standby node.
b. Stop the active node.
c. Start the active node.
d. Start the standby node.
Procedure
Step 1 Log in as the sopuser user to non-management nodes (except the Deploy01 or Deploy02
nodes in the VM) in sequence and run the following command to switch to the ossadm user.
su - ossadm
Step 2 Run the following commands to stop the non-management nodes in sequence:
NOTE
Stop the secondary and primary non-management nodes in sequence.
ipmc_adm -cmd stopnode
Step 3 Run the following commands to update the IR CA certificates:
./osskey -cmd replace_ircacerts
Step 4 Run the following commands to start the nodes:
NOTE
Stop the secondary and primary non-management nodes in sequence.
Step 5 Run the following commands to check whether the time stamp of the certificate file is
updated.
cd /opt/oss/manager/etc/ssl/internal
ll
-rw------- 1 ossadm ossgroup 895 Sep 4 19:57 manifest.json
-rw------- 1 ossadm ossgroup 8122 Sep 4 19:57 server.cer

-rw------- 1 ossadm ossgroup 3326 Sep 4 19:57 server_key.pem

-rw------- 1 ossadm ossgroup 4549 Sep 4 19:57 server.p12
-rw------- 1 ossadm ossgroup 8015 Sep 4 19:57 trust.cer
-rw------- 1 ossadm ossgroup 1830 Sep 4 19:57 trust.jks
----End
7.6.3 Updating the Certificate Password

This section describes how to update the Certificate Password.
Procedure
Step 1 Log in to the primary management node as the sopuser user and run the following commands
to obtain the ciphertext for the new password:
su - ossadm
osskey -cmd encryptpasswd
NOTE
The password must meet the following requirements:

l The password consists of 10 to 32 characters.
l The password contains at least three of the following types of characters: uppercase letters,
lowercase letters, digits, and special characters (~@#$%^*()-_=+[{}]:,./?).
l The same character does not occur in the password in a consecutive manner.
l The same character does not occur in the password for three times or more.
Step 2 Open the /opt/oss/manager/agent/etc/mcagent.conf file and replace the value of

manifest_default_pass with the ciphertext generated in Step 1.
vi /opt/oss/manager/agent/etc/mcagent.conf
Step 3 Press Esc and run the :wq! command to save and exit from the edit mode.
Step 4 Log in to other nodes in sequence to perform Step 1 to Step 3.
----End
7.7 Changing Passwords for Backup Server User

Before backup and restoration, you need to set the user name and password for the backup
server user in the global backup parameters. Backup server users are used for CloudOpera
Orchestrator SDN to access the backup server. After changing the password for the backup
server user, you need to change the password for the backup server in the global backup
parameters. If you do not change the password, CloudOpera Orchestrator SDN cannot access
the backup server. As a result, the backup and restore function cannot be used.
Prerequisites
You have obtained the new password for the backup server user.

Procedure
1. Open a web browser, input https://floating IP address of the primary and secondary
management nodes:31943 in the address box and press Enter.
Step 2 Choose Backup and Restore > Configurations > Configure Global Backup Parameters
from the main menu.
Step 3 On the Configure Global Backup Parameters page, click in the Operation column of
the backup server with the password to be changed.
Step 4 Change the value of Password in the Parameters column to the new password for the backup
server user.
Step 5 Click Validate to verify that connectivity for the backup server is tested.
Step 6 The Validate Successfully dialog box is displayed, click OK.
Step 7 Click in the row of the backup server to save the new password.
Step 8 The Save Successfully dialog box is displayed, click OK.
----End


CloudOpera Orchestrator SDN V200R002C10 Backup and Restoration Guide 01

Uploaded by

Copyright:

Available Formats

CloudOpera Orchestrator SDN V200R002C10 Backup and Restoration Guide 01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CloudOpera Orchestrator SDN V200R002C10 Backup and Restoration Guide 01

Uploaded by

Copyright:

Available Formats

CloudOpera Orchestrator SDN

Backup and Restoration Guide

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2018-01-10) Huawei Proprietary and Confidential i

Indicates an imminently hazardous situation which, if

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Issue 01 (2018-01-10) Huawei Proprietary and Confidential ii

Calls attention to important information, best practices

Boldface Buttons, menus, parameters, tabs, window, and dialog

> Multi-level menus are in boldface and separated by the

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italic.

[] Items (keywords or arguments) in square brackets [ ] are

{ x | y | ... } Alternative items are grouped in braces and separated by

[ x | y | ... ] Optional alternative items are grouped in square brackets

{ x | y | ... } * Alternative items are grouped in braces and separated by

[ x | y | ... ] * Optional alternative items are grouped in square brackets

Issue 01 (2018-01-10) Huawei Proprietary and Confidential iii

01 2018-01-10 This issue is the first official release.

Issue 01 (2018-01-10) Huawei Proprietary and Confidential iv

3 Local Data Restoration................................................................................................................32

4 Remote Cold Backup and Restoration.................................................................................... 46

Issue 01 (2018-01-10) Huawei Proprietary and Confidential v

Issue 01 (2018-01-10) Huawei Proprietary and Confidential vi

6.5 Stopping a DB Instance.............................................................................................................................................. 104

Issue 01 (2018-01-10) Huawei Proprietary and Confidential vii

1.1 Backup and Restoration Scenarios

1.1 Backup and Restoration Scenarios

User Password Modification Impact

Requirement on the Backup Directory Space

Issue 01 (2018-01-10) Huawei Proprietary and Confidential 1

Table 1-1 Backup scenarios

Scenario Backup Scheme

Periodical backup of service instance data Periodically dynamic back up data.

Before or after service upgrade 1. Real-time dynamic back up

Before or after database upgrade or patch installation 1. Real-time dynamic back up

Before or after OS upgrade or patch installation 1. Real-time dynamic back up

After initial installation of CloudOpera Orchestrator Back up the management plane.

Table 1-2 Restoration scenarios

Scenario Backup File

Issue 01 (2018-01-10) Huawei Proprietary and Confidential 2

Scenario Backup File

l If the service instance fails to be upgraded and 1. Product application software

l If the OS upgrade or patch installation fails and l Restoring Service Node OS

The management plane cannot be accessed normally. Management-plane backup files

Restore the management-plane backup data of site A Management-plane backup files

1.2 Backup and Restoration Policies

Issue 01 (2018-01-10) Huawei Proprietary and Confidential 3

Figure 1-1 Relationship between service instances and database instances

Issue 01 (2018-01-10) Huawei Proprietary and Confidential 4

Figure 1-2 Microservice instance 1 and microservice instance 2 sharing database A

OS data Indicates the operating system data of all product nodes,

Issue 01 (2018-01-10) Huawei Proprietary and Confidential 5

1.2.2 Backup Policies

Table 1-3 Backup parameters

Transmission mode CloudOpera Orchestrator SDN supports the Secure File